=== salem_ is now known as _salem | ||
hallyn | slangasek: i'm doing another fresh jessie install so i can test the proposed cgmanager (and systemd-shim and lxc whiel i'm at it). what will be the next step in getting cgmanager into experimental? | 00:32 |
---|---|---|
slangasek | hallyn: none; why would I upload it to experimental instead of unstable? ;) | 00:32 |
hallyn | slangasek: bc i originally tagged it with experimental? :) | 00:41 |
slangasek | pssh :) | 00:43 |
mbiebl_ | hallyn: please upload it directly to unstable | 00:46 |
hallyn | slangasek: should i change the changelog msg then? | 00:48 |
slangasek | hallyn: if you wish, though I figure it's fair game for me to adjust that during sponsorship | 00:48 |
=== _salem is now known as salem_ | ||
hallyn | hm. stgraber: do you think cgmanager in debian ought to mount name=systemd, or not? | 01:55 |
hallyn | i guess it should | 01:55 |
hallyn | (else lxc fails) | 01:56 |
stgraber | hallyn: yeah, it probably should. Maybe make this conditional to logind's presence? | 01:56 |
stgraber | hallyn: as in [ -e /lib/systemd/systemd-logind ] && args="$args -m name=systemd" | 01:57 |
stgraber | hallyn: hmm, actually, I think we want to do it unconditionaly | 01:58 |
hallyn | stgraber: mbiebl was talking about no longer having the logind start script mount the cgroups, so i think that could break | 01:58 |
hallyn | better to just always mount it | 01:58 |
stgraber | hallyn: because otherwise if you have a host without logind but a container with logind, things will fail due to lack of name=systemd | 01:59 |
hallyn | good point | 02:00 |
hallyn | all right lxc works fine in jessie with cgmanager; one more rebuild of systemd-shim to test that bit | 02:13 |
=== superm1_ is now known as superm1 | ||
hallyn | slangasek: had to update http://people.canonical.com/~serge/cgmanager-0.27.1/cgmanager_0.27-1.dsc anyway for one more one-line fix, so i changed release to unstable. works here with lxc and systemd-shim, so i'm now stepping back from it. | 03:20 |
=== hyperair is now known as Guest90316 | ||
=== maxb is now known as Guest41692 | ||
=== salem_ is now known as _salem | ||
pitti | Good morning | 04:06 |
pitti | infinity: ddeb deps> ah right; so I guess, time for a more intrusive rewrite then, and then I can avoid everything else which makes this thing so slow, and also avoid having to maintain the cronjobs every release | 04:07 |
pitti | doko_: did you see that the new twisted seems to break quite a number of rdeps? | 04:08 |
pitti | hallyn: I can have a look | 04:08 |
pitti | hallyn: is there a github pull request or similar for that? | 04:09 |
hallyn | pitti: hey! no pull request yet; waht would the pull request be to? desrt's tree? (he has a cgm.1 branch which i'm based off of) | 04:13 |
hallyn | for now it's just in github.com/hallyn/systemd-shim #cgm.2 | 04:13 |
pitti | hallyn: ah, ok, can look there | 04:14 |
hallyn | cool | 04:17 |
pitti | hallyn: might take a bit though, I'm currently swamped in requests/todos | 04:25 |
hallyn | pitti: understandable - going to bed now; I can look for review/sponsor in #debian-systemd tomorrow if need be. thanks in either case | 04:43 |
=== Aki-Thinkpad is now known as snakes | ||
=== snakes is now known as _snakes | ||
=== _snakes is now known as D8 | ||
=== D8 is now known as _8D | ||
=== _8D is now known as _8D[_] | ||
=== Lutin_ is now known as Lutin | ||
=== Guest41692 is now known as maxb | ||
Saviq | seb128, hey, will you guys have time to review https://code.launchpad.net/~mterry/ubuntu-system-settings/locking-hash/+merge/224346 ? | 08:06 |
seb128 | Saviq, I wouldn't mind a review from the security team on that one, they had lot of good reviews comments and specific notes on the first review (see the bug report) | 08:07 |
seb128 | Saviq, I can have a look today but I want a security ack before approving it | 08:07 |
Saviq | seb128, yeah sure | 08:07 |
Saviq | seb128, we're working on it on that front as well | 08:07 |
seb128 | great | 08:08 |
=== doko_ is now known as doko | ||
doko | pitti, yep, not unusual | 08:32 |
Tribaal | Hi all. I opened a branch against an ubuntu package and would appreciate it if someone could have a look at it (it's waiting for sponsorship - but I'd like to make sure I followed the process properly). | 09:27 |
Tribaal | Here's the bug: https://bugs.launchpad.net/ubuntu/+source/ubumirror/+bug/1341523 A "just wait" answer would be good enough :) | 09:28 |
ubottu | Ubuntu bug 1341523 in ubumirror (Ubuntu) "Update to upstream 0.4" [Undecided,In progress] | 09:28 |
jamespage | cjwatson, around? bug 1341618 just got bought to my attention | 09:34 |
ubottu | bug 1341618 in grub2 (Ubuntu) "grub 1.99-21ubuntu3.15 will not boot on some hardware" [Undecided,Confirmed] https://launchpad.net/bugs/1341618 | 09:34 |
cjwatson | jamespage: left a comment | 09:38 |
jamespage | cjwatson, ta - i'll poke Spads again | 09:38 |
sil2100 | @pilot in | 09:39 |
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100 | ||
Spads | cjwatson: I've asked the APAC folks who had first-hand experience to elaborate. thanks. | 09:41 |
zyga | hey, I'm back from holidays and my sbuild/schroot setup is now broken (all utopic), I seem to get a message saying that my chroots are not owned by root (they are owned by sbuild) | 10:25 |
zyga | googling didn't really help me much | 10:25 |
zyga | the exact message is: | 10:25 |
zyga | E: sid-amd64-sbuild-625b5676-4967-4132-b55e-cd4d95cb5fe5: Failed to lock chroot: /var/lib/sbuild/sid-amd64.tar.gz: File is not owned by user root | 10:25 |
darkxst | pitti, running a autopkgtest with build-needed, doesn't pick up the build depends from the main package? | 10:37 |
pitti | darkxst: it does | 10:37 |
pitti | darkxst: well, for building | 10:38 |
pitti | darkxst: not for the test | 10:38 |
darkxst | pitti, I have to use --disable-unit-tests on the main build or it fails (unless I override that with ||true) | 10:39 |
pitti | darkxst: that's not indended -- building the package should behave like on a buildd | 10:40 |
darkxst | pitti, tracker tests won't run in buildd | 10:40 |
pitti | darkxst: so tracker's debian/rules shoudl already use --disable-unit-tests during build? | 10:40 |
pitti | darkxst: sorry, I'm afraid I still don't understand the question/problem | 10:41 |
darkxst | pitti, yes it does, we want to run the unit-tests but they can't be run at build time | 10:41 |
darkxst | since they need the tracker dbus interfaces | 10:41 |
zyga | hmm | 10:41 |
* zyga digs through schroot code to understand what is causing the problem | 10:42 | |
pitti | darkxst: yeah, sounds like these unit tests are rather broken :/ (they ought to start a private D-BUS instance with the locally built tracker) | 10:42 |
darkxst | pitti, so right now I have a autopackage test with "make -c tests check" | 10:42 |
pitti | darkxst: ah, wrapped in a dbus-launch or so? | 10:42 |
darkxst | xvfb-run | 10:42 |
Saviq | jodh, hey, on bug #1222705, do you have a phone with Ubuntu on it by any chance? | 10:44 |
ubottu | bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed] https://launchpad.net/bugs/1222705 | 10:44 |
jodh | Saviq: I don't have a phone (still waiting ... :) | 10:45 |
Saviq | jodh, the most reproducible case is "restart unity8" on the phone for us, let me try and get you some logs | 10:45 |
jodh | Saviq: thanks | 10:45 |
Saviq | jodh, will try and reproduce on emulator, too | 10:45 |
zyga | hmm | 10:50 |
zyga | it seems that all chroot files need to be owned by root because of $reasons | 10:50 |
zyga | ok, let's try | 10:50 |
zyga | \o/ | 10:51 |
zyga | ok | 10:51 |
zyga | that worked | 10:51 |
* zyga looks at schroot changelog | 10:51 | |
darkxst | pitti, so the tests run in a fresh chroot? | 10:52 |
pitti | darkxst: yes, with only the test dependencies installed | 10:52 |
Saviq | jodh, https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1222705/comments/18 | 10:53 |
ubottu | Ubuntu bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed] | 10:53 |
jodh | Saviq: ta | 10:54 |
darkxst | pitti, so would be better to --enable-unit-tests and ignore test failure on build, then just run the tests from autopkgtest? | 10:55 |
darkxst | or add all the build-deps to the tests/control ? | 10:55 |
pitti | darkxst: you can do that, or you find a way to just build the tests (make -C tests) and run them against the installed tracker | 10:56 |
jodh | Saviq: could you also attach the /var/crash/_sbin_init.*.txt? | 10:56 |
pitti | darkxst: you can add @builddeps@ to the test dependencies if you want to build stuff in your test script | 10:56 |
Saviq | jodh, sure, let me get some symbols in it first | 10:56 |
jodh | Saviq: thanks, if you could also trigger the crash with the Session Init running as 'init --user --debug', that would also be fantastic. | 10:57 |
Saviq | jodh, hmm any idea how would I go about that with lightdm auto-starting the session? | 10:58 |
jodh | Saviq: well you could just 'initctl log-priority debug' before starting the tests. | 11:00 |
Saviq | jodh, oh yeah that'd work | 11:00 |
jodh | Saviq: last time I checked, lightdm runs the script /usr/bin/ubuntu-touch-session which you could hack to add '--debug' if you'd prefer. | 11:01 |
=== pete-woods is now known as pete-woods|lunch | ||
Saviq | jodh, added two attachments to the bug, not sure if there's any more useful info | 11:20 |
=== MacSlow is now known as MacSlow|lunch | ||
uki | Is there anyway I can easily have gdb with python2 support on ubuntu 13/14 instead of python3? | 11:53 |
uki | All my gdb scripts are broken as the newer gdb uses python3 | 11:53 |
darkxst | uki, you need to make your scripts python3 compatible | 11:57 |
uki | darkxst: any easier way to downgrade? | 11:58 |
darkxst | uki, only if you rebuild gdb against python2 | 11:58 |
darkxst | not possible with archive versions | 11:58 |
uki | ah i see, thats sounds good. so id have to "apt-get source", uncompress the deb and rebuild? | 11:59 |
uki | darkxst: ^^ | 12:00 |
darkxst | uki, I have never tried, its pretty easy to convert most scripts. but at the very least you would need to modify build-depends | 12:01 |
uki | darkxst: im comfortable with python3, yes, but im using an entire lib written for use within gdb thats written in python2. conversion isn't really desirable at this point. | 12:02 |
=== psivaa is now known as psivaa-off | ||
darkxst | uki, try run the scripts through 2to3 | 12:14 |
=== _salem is now known as salem_ | ||
sil2100 | @pilot out | 12:18 |
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
* sil2100 lunch | 12:18 | |
=== MacSlow|lunch is now known as MacSlow | ||
darkxst | pitti, will xvfb-run pass through test errors? or do I need to trap them somehow? | 12:40 |
pitti | darkxst: it passes through stdout/err and exit code, so no need for anything special | 12:41 |
sil2100 | @pilot in | 12:41 |
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100 | ||
darkxst | pitti, so this should be fine then? http://pastebin.com/ESPq5FNs | 12:45 |
Saviq | jodh, just reproduced the same crash under i386 emulator, do you know the steps to get one? | 12:45 |
pitti | darkxst: if that builds the unit tests and works, it looks fine | 12:45 |
darkxst | pitti, runs fine locally with adt-run | 12:45 |
pitti | darkxst: @builddeps@ because "make -C tests check" actually builds more stuff than what gets build with dpkg-buildpackage? | 12:46 |
LocutusOfBorg1 | xnox, did you read this? https://github.com/performous/performous/commit/79eff6c44b76f26366588e12a606a77bd6e97a83 | 12:46 |
LocutusOfBorg1 | :) | 12:46 |
darkxst | pitti, yes, as mentioned earlier main build has --disable-unit-tests | 12:48 |
pitti | darkxst: right, but the test doesn't call ./configure again, that's why I wondered; so if that make call does it, then fine :) | 12:48 |
pitti | darkxst: btw, if that works, the tests should also work during package build if you run them through xvfb-run in debian/rules override_dh_auto_test | 12:49 |
Saviq | jodh, https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1222705/comments/24 | 12:50 |
ubottu | Ubuntu bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [High,Confirmed] | 12:50 |
darkxst | pitti, no I tried that first, but they require the tracker dbus, which of course isn't installed (although I will file a bug upstream about fixing that) | 12:50 |
jodh | Saviq: thanks, I'll ping you if I need anything else. | 12:50 |
Saviq | jodh, cheers | 12:50 |
darkxst | pitti, they also require a utf-8 locale and $HOME set, fwiw | 12:52 |
pitti | darkxst: ah, ok; thanks! | 12:52 |
smb | xnox, It is a rather minor issue but I thought to document it anyway. Now what again would be the package related to current desktop installer? | 13:12 |
cjwatson | ubiquity | 13:15 |
sil2100 | @pilot out | 13:16 |
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
=== Sweetsha1k is now known as Sweetshark | ||
=== pete-woods|lunch is now known as pete-woods | ||
smb | cjwatson, thanks | 13:38 |
=== timrc-afk is now known as timrc | ||
kgunn | ChrisTownsend: hey there, i'd normally pester stephen on this... | 14:17 |
kgunn | but, we're getting darn close to landing qtcomp | 14:17 |
kgunn | but we need one mp (1 line change) | 14:17 |
kgunn | https://code.launchpad.net/~gerboland/unity8-desktop-session/qtcomp/+merge/225884 | 14:17 |
kgunn | reviewed | 14:18 |
kgunn | would you mind ? | 14:18 |
kgunn | there have been a few of us that have tested the silo against unity8-desktop | 14:18 |
kgunn | https://wiki.ubuntu.com/Unity8/QtComp | 14:18 |
kgunn | and it worked fine | 14:19 |
ChrisTownsend | kgunn: Hey. Sure, I can take a look. Is the suggestion that Stephen made been done? | 14:21 |
kgunn | ChrisTownsend: uh.... :P | 14:22 |
ChrisTownsend | kgunn: Also, that MP is marked WiP, but I assume it's ready for review since you are asking me:) | 14:23 |
kgunn | greyback: ^ yeah, can we flip the switch to review ? | 14:24 |
greyback | kgunn: done. Unsure what checklist to enter though | 14:24 |
ChrisTownsend | kgunn: And when you "tested in the silo", does that mean unity8-desktop-session is already in a silo and this just needs approved so it can be published? | 14:25 |
kgunn | greyback: something sensible....like, no api break, been tested as part of https://wiki.ubuntu.com/Unity8/QtComp | 14:25 |
kgunn | ChrisTownsend: yes, its a collection of MP's that all have to go at once...and its been under test by us & the community for over a week now | 14:26 |
kgunn | and something we need for rtm | 14:26 |
kgunn | hence my underwear being slightly wadded | 14:26 |
ChrisTownsend | kgunn: Ok, makes sense. I wasn't sure if a new silo, etc. needed to be set up. | 14:26 |
ChrisTownsend | kgunn: lol, we'll get it in. | 14:26 |
kgunn | ChrisTownsend: yeah, we're just in the process of collecting approvals....and will just flip the switch on that silo from testing to "attempt to land" | 14:28 |
ChrisTownsend | greyback: kgunn: So is bregma's comment about this also needing to be added to data/unity8-mir.conf legit. You say it works already, so maybe that's not necessary, but I'm just wondering if it still needs to be there just to be safe. | 14:29 |
greyback | ChrisTownsend: yep I just saw that. I'll do it to be safe | 14:29 |
ChrisTownsend | greyback: Cool, thanks. | 14:30 |
ChrisTownsend | greyback: Let me know when you have that pushed and I'll approve. | 14:33 |
greyback | ChrisTownsend: just pushed | 14:34 |
ChrisTownsend | greyback: Ok, thanks | 14:34 |
greyback | thank you! | 14:34 |
ChrisTownsend | kgunn: greyback: Approved | 14:35 |
greyback | one down.... | 14:35 |
kgunn | woohoo | 14:35 |
* ChrisTownsend Hopes kgunn's underwear is slightly less wadded. | 14:36 | |
kgunn | lol thanks ChrisTownsend | 14:37 |
ChrisTownsend | kgunn: np! | 14:38 |
=== Sweetsha1k is now known as Sweetshark | ||
Riddell | mvo_: ping, are you able to help debug an apt issue with me? | 14:58 |
mvo_ | Riddell: maybe, what is the issue you see? | 14:58 |
Riddell | mvo_: I'm making a new meta package | 14:59 |
Riddell | for kubuntu-plasma5-meta | 14:59 |
Riddell | it's in the kubuntu-ppa/next | 14:59 |
Riddell | but when I apt-get install kubuntu-plasma5-desktop it doesn't want to install because powerdevil says it breaks on kde-workspace-data | 14:59 |
Riddell | mvo_: how do I tell it it's fine to remove kde-workspace-data ? | 15:00 |
Riddell | if I explicitly apt-get install kubuntu-plasma5-desktop powerdevil it's fine with removing kde-workspace-data and anything else that's needed | 15:00 |
mvo_ | Riddell: this is against utopic? give me a sec to see what the resolver tells me | 15:00 |
Riddell | mvo_: yep | 15:00 |
Riddell | mvo_: sudo apt-add-repository ppa:kubuntu-ppa/next ; sudo apt-add-repository ppa:ci-train-ppa-service/landing-005 | 15:01 |
mvo_ | Riddell: ok, give me a minute to setup a chroot | 15:02 |
Riddell | mvo_: oh I have an ec2 if you give me your ssh key | 15:02 |
Riddell | mvo_: ssh ubuntu@ec2-54-91-220-158.compute-1.amazonaws.com | 15:03 |
hallyn | mbiebl: slangasek: pitti: so systemd-shim is nto useful in experimental as is anyway, so could we upload the patched version to experimental as soon as cgmanager goes into unstable, to make progress with systemd-208 after it gets some wider testing? | 15:04 |
mvo_ | Riddell: thanks, I will use that then | 15:05 |
mvo_ | Riddell: you have not added the ppa in the ec2 instance yet, is that correct? | 15:06 |
mvo_ | Riddell: unicorns eh :) ? | 15:06 |
Riddell | mvo_: I have, in /etc/apt/sources.list.d/ | 15:07 |
mvo_ | Riddell: aha, what is the binary package name I need to install to trigger the problem? | 15:07 |
Riddell | mvo_: I've only installed kubuntu-desktop, the issue is with kubuntu-plasma5-desktop | 15:07 |
mvo_ | Riddell: thanks, that was the name I missed | 15:07 |
mvo_ | Riddell: so apt tries to keep it because installing it would causing removals of a package with a higher "score", but there is something more going on it seems. with the ppa and the landing silo I can not install kubuntu-desktop ( kubuntu-desktop : Depends: plasma-desktop but it is not going to be installed) | 15:15 |
Riddell | mvo_: I don't think I've tried that, plasma 5 overlaps with the old stuff in various places so I'm not trying to support going back the way | 15:16 |
mvo_ | Riddell: which seems to come from a conflict of plasma-workspace against klipper | 15:16 |
mvo_ | Riddell: aha, ok | 15:16 |
Riddell | mvo_: so maybe I should just keep the name of the meta package the same as kubuntu-desktop | 15:17 |
mvo_ | Riddell: the breaks in powerdevil says "Breaks: kde-workspace-data (<< 4:4.98.0)" - would that be a option? a updated kde-workspace-data ? | 15:18 |
Riddell | mvo_: nah kde-workspace is going away in plasma5 land | 15:18 |
mvo_ | Riddell: that may well make sense, if kubuntu-desktop is going to vanish | 15:18 |
mvo_ | Riddell: ok, that is good to know, give me a sec then | 15:19 |
mvo_ | Riddell: if its going away then you may simply add a transitional package for those, I don't really know much about the way kde is packaged (or develooped :) so take my advice with a grain of salt. but if it is not co-installable, well :) | 15:21 |
Riddell | mvo_: hmm yes that's another idea | 15:23 |
mvo_ | Riddell: a direct conflict/break in the kubuntu-plasma5-desktop would also work | 15:23 |
Riddell | aah yes | 15:23 |
Riddell | good, I'll play around, thanks mvo_ | 15:24 |
mvo_ | Riddell: good luck and sorry that this is so complicated, I wonder/wondered if it would be worth to add/support a "obsoletes" tag just like in rpm | 15:24 |
sil2100 | didrocks: so, I was wondering... since in cu2d whenever, let's say, the cu2d-apps-head-2.1build job has finished with success, jenkins automatically started the cu2d-apps-head-2.2check job | 15:41 |
sil2100 | didrocks: while I didn't see any triggers configured from the jenkins side | 15:41 |
sil2100 | didrocks: nor in the cu2d scripts being executed | 15:41 |
didrocks | sil2100: there was master job IIRC | 15:41 |
didrocks | let me check | 15:42 |
sil2100 | Ah | 15:42 |
sil2100 | ! | 15:42 |
didrocks | https://wiki.ubuntu.com/DailyRelease/StackPublish#Different_phases_of_one_stack | 15:42 |
didrocks | this diagram can help | 15:42 |
sil2100 | didrocks: I see the job, hah, makes sense now | 15:43 |
didrocks | so… | 15:43 |
sil2100 | Thanks! | 15:43 |
didrocks | you have the master job | 15:43 |
didrocks | which triggers the prepare jobs | 15:43 |
didrocks | which was traking the prepare-project ones, one per project on that stack | 15:43 |
didrocks | then, master was chaining (once prepare finishes successfully or only having warnings) to 2 jobs in parallel | 15:44 |
didrocks | build and check | 15:44 |
didrocks | both were chaining to the publish one | 15:44 |
didrocks | this is a simplified case, there is the waitonstacks in reality, but not needed for that demonstration | 15:44 |
didrocks | sil2100: does that make sense? ^ | 15:44 |
sil2100 | didrocks: makes sense indeed, thanks :) | 15:47 |
didrocks | yw ;) | 15:47 |
=== lutostag_ is now known as lutostag | ||
bdmurray | xnox: did you have a look at the issue regarding Contents.gz or did we win the race condition? | 16:37 |
brendand | does anyone know how to use a binary from the build at build time? | 17:00 |
brendand | i want to use a binary provided by the package i'm writing tests for, in the tests | 17:00 |
cjwatson | mangle paths, or run the tests in question via autopkgtest | 17:01 |
xnox | bdmurray: no, not yet. will look into it today. | 17:17 |
xnox | LocutusOfBorg1: \o/ | 17:18 |
xnox | smb: so which bug did you file about ubiquity? | 17:19 |
=== roadmr is now known as roadmr_afk | ||
smb | xnox, bug 1342071 | 18:01 |
ubottu | bug 1342071 in ubiquity (Ubuntu) "Invisible installer dialog on VM iso installation" [Low,New] https://launchpad.net/bugs/1342071 | 18:01 |
smb | installer dialogue is a bot off as I mean the "eject media and press enter" back on the framebuffer | 18:02 |
=== alexisb is now known as alexisb_lunch | ||
xnox | smb: yeah. and i don't know how to make it more reliable. | 18:14 |
=== rpadovani_ is now known as rpadovani | ||
=== lubko is now known as zmok | ||
smb | xnox, Hm, ok. Probably I should investigate a bit more into it. I was not sure it ever really was brought up and I get surprised every cycle when I play around with VM installations :-P | 18:18 |
smb | At least as long as I do them manually and not through netinst | 18:19 |
xnox | smb: i think we should be doing systemd style pivot into a shutdown initramfs that shows that text.... | 18:20 |
xnox | smb: at the moment however it's a jumbo between kernel, plymouth messages and that text. | 18:20 |
smb | xnox, Yeah, this has been a pain in other senses as well (racing on the way up). Though I cannot help myself from being doubtful that systemd is less painful when taking over the world. | 18:22 |
xnox | smb: i haven't yet planned how to do ubiquity with systemd. | 18:33 |
xnox | smb: i believe we will have to conflict and/or replace targets. or something like that. | 18:33 |
smb | xnox, Its not so much knowledge that makes me doubtful. Though I cannot decide myself whether I should call it pessimistic or realistic. >:) | 18:36 |
=== roadmr_afk is now known as roadmr | ||
=== timrc is now known as timrc-afk | ||
brendand | is there any variable i can use in debian/rules to reference the directory like 'build-area/url-dispatcher-0.1+14.10.20140619/obj-x86_64-linux-gnu' | 19:24 |
brendand | i.e. the directory where binaries are built into | 19:24 |
* hallyn feels all accomplished now that he created a debian mentors account | 19:33 | |
hallyn | slangasek: dunno if it helps in anyway, but i pushed cgmanager to mentors.debian | 19:34 |
xnox | hallyn: \o/ | 19:53 |
xnox | hallyn: let me review that =) | 19:53 |
xnox | hallyn: well there are lintian errors already =) | 19:53 |
hallyn | xnox: the bad-distribution-in-changes-file unstable error? | 19:57 |
xnox | hallyn: nah, I'll comment on mentors, I see a few other issues. | 19:57 |
hallyn | cool, thanks | 19:57 |
=== timrc-afk is now known as timrc | ||
hallyn | xnox: when responding to feedback with a new pkg, do i bump the version as i would in archive/ppa, or do i just delete and re-upload? | 20:14 |
hallyn | (re-upload would be suboptimal as feedback-as-teaching is lost) | 20:14 |
xnox | hallyn: well, with mentors. | 20:17 |
xnox | hallyn: you would keep the version the same, but keep adding things in the changelog. | 20:17 |
xnox | e.g. * Fixed foobar and bar in jars. | 20:17 |
xnox | hallyn: and published a second comment about binaries. | 20:18 |
hallyn | xnox: i did look for an ITP bug to close, but didnt' see one. the, uh, other cgmanager upload didn't close one so i assumed that was an optional formality. is it not? | 20:24 |
xnox | hallyn: in Debian, the person who "Intends To Package" should open an "Intends To Package" bug against "WNNP" package. And close it on the first upload into debian. | 20:26 |
xnox | hallyn: I don't see any prior uploads in Debian. | 20:26 |
xnox | hallyn: there is no ITP bug equivalent in Ubuntu. | 20:26 |
xnox | https://www.debian.org/devel/wnpp/ | 20:27 |
hallyn | xnox: right, there is a cgmanager (0.20 version) upload to ftp.debian somewhere. that's the one i meant. | 20:27 |
hallyn | ok, will open that bug then | 20:27 |
xnox | hallyn: you may use $ report-bug or just construct email by hand. They are cc'ed to debian-devel by default, so you can see plenty of examples. | 20:28 |
xnox | hallyn: i really don't see cgmanager 0.20 upload, that got accepted. | 20:29 |
hallyn | it didn't get accepted | 20:30 |
=== alexisb_lunch is now known as alexisb | ||
hallyn | argh, i hate the symbols files :) | 20:38 |
doko | xnox, please don't revert gobjc back, won't help, and won't help for gfortran either. tvoss did promise to be ready today, so we can point to 4.9 again | 21:07 |
xnox | doko: why will it "won't help" ? | 21:10 |
xnox | doko: and it's not a revert, per se. At the moment a non-matching library was getting installed for the default compiler... Not sure how fortran operates, but it seems to be buildable. | 21:11 |
xnox | doko: unlike fortran, which is a binary in path, cc1obj is just an internal gcc private executable. one uses gcc to compile objc code. | 21:12 |
doko | xnox, same as f951 | 21:19 |
xnox | doko: ok, so when you/slangasek reverted to 4.8, why was it not done for gobjc, gojbc++ and fortran as well? given that it left those in complete FTBFS state. | 21:20 |
xnox | (in -proposed and -release) | 21:20 |
doko | xnox, because fortran is an ABI transition which already was in progress | 21:23 |
slangasek | xnox: because we were implementing an immediate short-term fix for a critical phone issue, leaving a few packages ftbfs in the short term is acceptable collateral damage in the general case | 21:23 |
doko | and I didn't want to investigate if it is safe to revert gobjc | 21:23 |
slangasek | xnox: and gcc-4.9 is supposed to be made the default again RSN | 21:23 |
doko | if you did investigate, then sure, that might be safe | 21:23 |
=== salem_ is now known as _salem | ||
hallyn | xnox: looking at the dpkg-gensymbols output for libcgmanager0, it gives me symbol@Base... with netcf it gives me symbol@NETCF_version. | 22:21 |
hallyn | problem with my .pc file? | 22:22 |
xnox | hallyn: not the .pc file -> that one just encode paths to your header files & which libraries to link/depend on. | 22:27 |
xnox | hallyn: if you want to version your symbols, you'd need to use libtool symbol versioning facilities. | 22:27 |
hallyn | xnox: and if i don't want to? | 22:28 |
* hallyn looks to see what doing that might entail | 22:29 | |
xnox | hallyn: you are fine just as it is. if later you want to update a symbol you would be able to provide two versions of the same symbol and mark one of them the default. | 22:30 |
xnox | hallyn: or like, just don't break you api/abi =) | 22:30 |
hallyn | xnox: but then how do i generate a symbols file, | 22:31 |
hallyn | i thought the "*@LIB_version package-version" was the whole point | 22:31 |
xnox | hallyn: the debian/libcgamanger0.sybmols? | 22:31 |
xnox | https://wiki.debian.org/UsingSymbolsFiles ? | 22:32 |
xnox | hallyn: the point of debian/*.symbols file to list _all_ symbols and when they were introduced. Such that you can catch if they change or get removed, and also get correct dependencies depending on which apis are used. | 22:37 |
hallyn | yeah that's where i'm looking. that gives me a huge list, which you seemed not to want for netcf | 22:37 |
hallyn | ok - i'll upload with the results of that- thanks | 22:38 |
xnox | hallyn: right, so netcf is special. Upstream has versioned all of their symbols very tightly, hence debian/libnetcf1.symbols is ok to use wildcards to get all symbols covered. | 22:38 |
xnox | hallyn: but that doesn't help to catch, if e.g. upstream make a mistake. | 22:39 |
xnox | hallyn: e.g. I like dbus-cpp symbols files the best. | 22:40 |
hallyn | netcf does that in src/netcf_public.syms? | 22:40 |
hallyn | dbus-cpp symbols? | 22:40 |
hallyn | the package? | 22:41 |
hallyn | nope | 22:42 |
xnox | hallyn: this symbols file for libcgmanager is correct one http://paste.ubuntu.com/7800703/ | 22:42 |
hallyn | xnox: ok, that's what i've got (except 0.27 :) | 22:43 |
xnox | hallyn: in libnih, we do version symbols using a libtool versioning script e.g. https://github.com/keybuk/libnih/blob/master/nih/libnih.ver hence they are not @Base. | 22:43 |
xnox | hallyn: so just stick that into debian/libcgmanager0.symbols and you are done. | 22:43 |
hallyn | xnox: thanks. | 22:43 |
hallyn | xnox: (still looking at dbus-cpp) | 22:45 |
xnox | hallyn: that one is c++ hence symbols are different per-platform and 32/64/big/little. | 22:45 |
mbiebl | cyphermox_: calestyo being pleasant as always (re that NM bug) | 23:00 |
mbiebl | anyway, since we basically all agree, I'll try to cook up a patch and run it by you | 23:00 |
cjwatson | brendand: "build-area/url-dispatcher-0.1+14.10.20140619" is almost certainly just your current directory; no need to put that together. For the rest of it you want "obj-$(DEB_HOST_GNU_TYPE)". You should normally put "DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)" near the top of debian/rules to make sure that variable is initialised. | 23:05 |
cjwatson | brendand: But "obj-$(DEB_HOST_GNU_TYPE)" is something that your package's own build system controls - it's not set by anything central. So if your package is buggy it's possible it's being set from something else, e.g. DEB_BUILD_GNU_TYPE. You should really grep your package's source code to find out where that's set. | 23:06 |
cjwatson | brendand: Or perhaps your package's build system. For instance some cdbs classes set $(DEB_BUILDDIR) to that. | 23:06 |
cjwatson | Or indeed some debhelper modes. | 23:07 |
infinity | robert_ancell: 1:2.8.3-0ubuntu1build1 really? | 23:30 |
infinity | robert_ancell: ITYM -0ubuntu2 ;) | 23:31 |
robert_ancell | infinity, which package? | 23:32 |
infinity | robert_ancell: That was calligra. I noticed it cause I was looking at the FTBFS. | 23:32 |
robert_ancell | Ah, I think I did that because I don't have access to lp:~kubuntu-packagers/kubuntu-packaging/calligra | 23:33 |
robert_ancell | but I'm not sure it's valid :) | 23:33 |
infinity | robert_ancell: For future reference, "dch -R" intelligently does the right thing (-NbuildN for unmodified Debian stuff, increments -NubuntuN for not) | 23:33 |
robert_ancell | ta, didn't know that | 23:33 |
infinity | robert_ancell: Oh, if it was intentional cause you expected them to throw it away, that sort of makes sense, ish. :) | 23:34 |
robert_ancell | yeah. | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!