| xnox | sarnold: excellent | 00:01 |
|---|---|---|
| sarnold | xnox: of course your little script provides a nice abstraction around when we eventually do that. :) heh | 00:02 |
| xnox | sarnold: it's a bit shame there is no definitive extension name for the profiles, thus stending time filtering out ".dpkg-new" et. al. | 00:04 |
| xnox | sarnold: and each location is processed in parallel, however one still does the loop twice =( | 00:05 |
| sarnold | xnox: heh, perhaps a decade or so back, we did have a .sd ('subdomain') extension on profiles, but we ditched that somewhere along the way as annoyingly redundant. heh. | 00:07 |
| jjohansen | sarnold, xnox: the parser isn't almost there, it is completely there. What it can't do yet is directly handle caching for multiple policy versions, so the old version is replaced when stale, and it doesn't handle profile removal on restart | 00:39 |
| jjohansen | it does the filtering for different extensions etc, you can point it at a directory and it loads the profiles from it | 00:40 |
| jjohansen | it handles the cache management, 90% of what the initscripts do could be dropped | 00:41 |
| jjohansen | oh I guess it doesn't do parallel compiles | 00:42 |
| jjohansen | but that is actually minor | 00:43 |
| jjohansen | when arekm ripped out the initscript stuff for pld it made things go something like 95% faster. /me would have to dig to get the actual figures | 00:44 |
| === vibhav is now known as Guest46468 | ||
| sarnold | jjohansen: cripes, that's impressive :) | 01:03 |
| === testing1209347 is now known as chase3023 | ||
| jjohansen | sarnold: found it, scrapping the bash scripting and doing direct cache load for his 4500 profiles reduced the time from 1m22s to 1.5s | 01:31 |
| sarnold | jjohansen: omg I want that | 01:32 |
| jjohansen | yeah, for a small profile count the bash scripting overhead is not so bad, but well its time to fix it | 01:33 |
| rajat_kapoor | Can anyone please help me , I have started getting "Segmentation fault (core dumped)" on 12.04 desktop terminal? | 02:46 |
| Unit193 | It would appear the auto importer isn't picking up network-manager, it would appear the last run was 2012. (Also would be nice to have the systemd services installed, but guessing that won't happen any time soon.) | 03:22 |
| darkxst | Unit193, you mean lp:debian branches? there are loads of branches in there that are pretty much broken | 03:26 |
| Unit193 | darkxst: No, I don't use those. https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/network-manager/trusty | 03:28 |
| TheMuso | B/c | 04:34 |
| pitti | Good morning | 05:24 |
| pitti | infinity, smoser: meh, doing daily reboot of wolfe-*; seems your magic from Friday didn't last long? | 05:36 |
| infinity | pitti: Yeah, I didn't expect it to fix it, I'd just hoped. :/ | 05:38 |
| infinity | pitti: If you get a VM in that wedged state and can live with it staying broken for a bit, apw said he'd like to have access to play/debug a bit. | 05:39 |
| pitti | infinity: sure; I'll take wolfe-05 offline in jenkins, and just reboot/fix the other three? | 05:40 |
| infinity | pitti: Sure, and give him ssh access to that one then, I guess. | 05:40 |
| infinity | pitti: I'm heading to bed, but I assume Andy will be up in an hour or two. | 05:40 |
| pitti | infinity: yep, will talk to him | 05:40 |
| infinity | pitti: Ta. | 05:40 |
| pitti | infinity: hmm, seems the other three don't come back from reboot | 05:46 |
| pitti | infinity: the host might need a reboot again, too? | 05:46 |
| * pitti sends his daily "screw you" jenkinswards | 05:58 | |
| pitti | @pilot in | 06:25 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges, pitti | ||
| dholbach | good morning | 06:26 |
| pitti | hey dholbach | 06:27 |
| mvo | hey dholbach & pitt, good morning | 06:28 |
| pitti | hallo mvo, wie gehts? | 06:28 |
| mvo | pitti: good, thanks! still not fully awake, but I'm hopeful the tea will help with that :) and you? | 06:30 |
| pitti | mvo: pretty much the same :) | 06:30 |
| dholbach | hey pitti, hey mvo | 06:32 |
| zyga | good morning | 06:41 |
| zyga | could someone enlighten me about the purpose of incoming.debian.org? I was under the impression that it's a place packages go to be built by all the arch builders | 06:42 |
| zyga | is my understanding correct? | 06:42 |
| pitti | zyga: not quite | 06:43 |
| pitti | zyga: it's the staging area where uploads and built packages are queued after accepting it from the upload queue, and publishing it into the archive | 06:43 |
| pitti | zyga: i. e. the publisher flushes incoming every 6 hours | 06:44 |
| pitti | zyga: but buildds look at incoming so that they don't need to wait for the publisher; but they also build sources which are already published | 06:44 |
| pitti | and then again upload the build (going through incoming again) | 06:44 |
| pitti | mvo: ah, are you already handling https://code.launchpad.net/~brian-murray/ubuntu-release-upgrader/bug-1302380/+merge/214349 ? | 06:49 |
| mvo | pitti: yeah, I have a slightly extended version of his branch, I hope he gets a chance to review that soon(ish) | 06:51 |
| zyga | pitti: so after a package gets accepted it goes to incoming, gets built by buildds, then gets back to incomin ? and then flushes to the archive? | 06:53 |
| zyga | pitti: and that happens four times a day | 06:53 |
| pitti | zyga: not "back" to incoming | 06:53 |
| pitti | zyga: upload -> accept (every 10 mins or so) -> incoming -> publisher -> archive | 06:54 |
| pitti | zyga: and buildds watch for new sources in incoming and archive -> build -> upload -> same as above | 06:54 |
| zyga | pitti: ah | 06:54 |
| zyga | pitti: I'm trying to understand when a few small packages that got uploaded there yesterday will make it into the archive | 06:55 |
| zyga | pitti: it's almost 24 hours now | 06:55 |
| pitti | that sounds like a bug | 06:55 |
| zyga | pitti: there are also packages from 7th of April | 06:55 |
| zyga | http://incoming.debian.org/ | 06:55 |
| zyga | or do I read that wrong? | 06:55 |
| pitti | hm; they might be NEW or something? | 06:56 |
| zyga | pitti: plainbox|checkbox packages aren't new | 06:56 |
| zyga | NEW I mean | 06:56 |
| zyga | and I cannot see them in https://ftp-master.debian.org/new.html | 06:56 |
| pitti | plainbox | 0.5.3-2 | sid | source, all | 06:56 |
| pitti | seems fine | 06:56 |
| zyga | oh! | 06:57 |
| pitti | zyga: so it seems incoming has some problems with cleaning up? | 06:57 |
| * zyga looks if requestsync sees that now | 06:57 | |
| pitti | zyga: it's also already on https://launchpad.net/debian/+source/plainbox | 06:57 |
| pitti | zyga: so yes, requestsync ought to see it | 06:57 |
| zyga | right, I see | 06:57 |
| zyga | great :) | 06:57 |
| * zyga just saw that versiontools got packaged for python :-) | 06:57 | |
| pitti | zyga: FYI: https://ftp-master.debian.org/dinstall.html | 06:57 |
| zyga | ohhh | 06:58 |
| pitti | zyga: dinstall is equivalent to what LP calls "publisher" | 06:58 |
| zyga | nice! | 06:58 |
| zyga | thanks | 06:58 |
| zyga | right | 06:58 |
| zyga | I know about it | 06:58 |
| pitti | zyga: after dinstall it usually takes about two hours to get imported into LP | 06:58 |
| darkxst | pitti, oh no! bug 1302077 will break high contrast theme | 06:59 |
| ubottu | bug 1302077 in nautilus (Ubuntu) "Hardcoded css style checks on GTK Theme instead of XGD_CURRENT_DESKTOP" [Undecided,Fix committed] https://launchpad.net/bugs/1302077 | 06:59 |
| darkxst | well mess it up | 06:59 |
| pitti | darkxst: hm, that previous list actually seemed incomplete | 06:59 |
| darkxst | (and Adwaita, but I doubt anyone uses that in unity) | 07:00 |
| pitti | darkxst: I thought we don't want the title bar under unity, period; not just under these two themes? | 07:00 |
| pitti | darkxst: but anyway, if this causes regressions I'm happy to reject from the queue and revert from the branch | 07:00 |
| pitti | darkxst: how does it cause regressions/ | 07:00 |
| pitti | ? | 07:00 |
| Noskcaj | pitti, blueman branch is fixed. I'd just committed without .pc/ last time | 07:01 |
| pitti | hate hate hate tracking .pc/ in UDD; this is just utterly wrong | 07:02 |
| pitti | Noskcaj: thanks | 07:02 |
| darkxst | pitti, that patch is overriding some theming issues with the ubuntu themes | 07:04 |
| maxb | I'd agree on the .pc/ thing - UDD on v3 source packages needs a serious rethink | 07:04 |
| darkxst | pitti, there is a seperate patch to bring back titlebar | 07:04 |
| pitti | darkxst: can you please explain that in bug 1302077 so that Leon can adjust? | 07:04 |
| ubottu | bug 1302077 in nautilus (Ubuntu) "Hardcoded css style checks on GTK Theme instead of XGD_CURRENT_DESKTOP" [Undecided,Fix committed] https://launchpad.net/bugs/1302077 | 07:05 |
| === maclin_ is now known as maclin | ||
| pitti | darkxst: I reject the upload | 07:05 |
| darkxst | pitti, ok | 07:06 |
| Noskcaj | maxb, My suggestion to fix it would be the ubuntu branches don't have stuff applied by default, and .pc/applied-patches is force added | 07:09 |
| maxb | force added? | 07:09 |
| Noskcaj | maxb, always there | 07:17 |
| Noskcaj | pitti, thanks for the sponsorings | 07:17 |
| pitti | meh, I sponsor as fast as I can, and yet the queue *increases* :) | 07:17 |
| Noskcaj | that's my goal. | 07:18 |
| pitti | 1 out of 1 hunk FAILED -- rejects in file blueman/plugins/applet/DhcpClient.py | 07:23 |
| pitti | Patch dhcpclient_priority can be reverse-applied | 07:23 |
| pitti | Noskcaj: ^ still no good :/ | 07:23 |
| Noskcaj | really? wow. | 07:23 |
| pitti | Noskcaj: nevermind; I got the orig.tar.gz from the failed bzr bd and now use plain debuild | 07:24 |
| Noskcaj | thanks | 07:24 |
| pitti | Noskcaj: I don't physically merge this anyway, I just upload and let the auto-importer sort it out | 07:24 |
| pitti | still, it's a pain | 07:25 |
| * pitti really prefers plain debdiffs on bugs | 07:25 | |
| Noskcaj | that seems to be the majority opinion. Maybe bzr could be hacked to give normal debdiffs | 07:25 |
| pitti | not sure if it's the majority; some folks seem to like it the way it is | 07:27 |
| pitti | zyga: can you handle https://code.launchpad.net/~brendan-donegan/ubuntu/trusty/checkbox/ffe_ui_custom_transport_ubuntu/+merge/214603 ? you seem to do this via debian and upstream | 07:28 |
| pitti | zyga: or, if you fine with an ubuntu upload, I can have a look at sponsoring, but maybe you'd like to cross-check | 07:29 |
| ricotz | pitti, good morning :), could you take a look at libcdr 0.0.15 which is/will be the version supported by libreoffice 4.2.4 -- http://people.ubuntu.com/~ricotz/packages/libcdr/ | 07:38 |
| pitti | ricotz: does that new version work with cdr2odg (source: writerperfect)? | 07:42 |
| zyga | pitti: hey, this is a coordinated ubuntu+debian package set | 07:43 |
| zyga | pitti: everything except for checkbox-gui is in debian | 07:43 |
| zyga | pitti: and is a sync of the new package | 07:43 |
| pitti | ricotz: the dh_autoreconf change is already in Ubuntu, could you mark this as "Merge with Debian unstable, remaining Ubuntu changes:"? | 07:43 |
| zyga | pitti: checkbox-gui is using ubuntu-sdk so it's not in debian | 07:44 |
| zyga | pitti: I'll have a sanity-check look but we've been working on that for the past two weeks :) | 07:44 |
| === oSoMoN_ is now known as oSoMoN | ||
| brainwash | anyone familiar with ubiquity? how can I easily test the installer mode? | 07:51 |
| brainwash | I want to debug bug 1284910 | 07:52 |
| ubottu | bug 1284910 in ubiquity (Ubuntu) "Xubuntu Beta 1 and Beta 2 installer has debian background wallpaper" [Critical,Confirmed] https://launchpad.net/bugs/1284910 | 07:52 |
| ricotz | pitti, yes cdr2odg runs and works, will update the changelog in a bit | 07:53 |
| mwhudson | hello | 07:54 |
| mwhudson | ah, +1 would be better for this | 07:54 |
| ricotz | pitti, updated | 07:55 |
| zyga | mwhudson: hey :) | 07:57 |
| zyga | pitti: thanks for syncing most of the checkbox stuff over | 08:04 |
| pitti | zyga: yw; doing your most recent sync now | 08:04 |
| zyga | pitti: are you also going to sync checkbox-support (ppc64el bugfix) and plainbox-provider-resource-generic (a few fixes) | 08:04 |
| pitti | zyga: I don't see the latter in the queue yet, but yes, I'll get to it | 08:05 |
| zyga | pitti: ok, thanks | 08:05 |
| pitti | zyga: please note that they are in unapproved, so the release team needs to ack those, too | 08:05 |
| zyga | ok | 08:05 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-resource-generic/+bug/1304850 is the critical one | 08:05 |
| ubottu | Launchpad bug 1304850 in plainbox-provider-resource-generic (Ubuntu) "Sync plainbox-provider-resource-generic 0.3-1 (main) from Debian unstable (main)" [Undecided,New] | 08:05 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/checkbox-support/+bug/1304191 less so | 08:06 |
| ubottu | Launchpad bug 1304191 in checkbox-support (Ubuntu) "Sync checkbox-support 0.2-1 (main) from Debian unstable (main)" [Undecided,New] | 08:06 |
| zyga | pitti: I'll be in #ubuntu-release, do I need anything else to assist in reviewing/landing those? | 08:06 |
| pitti | zyga: ah, sponsors aren't subscribed to teh former | 08:06 |
| zyga | oh, weird? thanks | 08:06 |
| pitti | zyga: I looked at the linked bugs lists, so it seems bug fix only; so it ought to be fine | 08:07 |
| pitti | zyga: but syncs don't have a debdiff attached to them, so the release team might have questions about where to see the changes/NEWS/changelog/etc. | 08:07 |
| zyga | pitti: I see, I'll try to produce those | 08:07 |
| pitti | zyga: which combinations did you test? the full stack of all new versions together? | 08:08 |
| zyga | pitti: yes, along with the chcekbox-gui merge request (directly to ubuntu) | 08:08 |
| * zyga works on debdiffs | 08:10 | |
| zyga | pitti: 'debdiff old.dsc new.dsc > pkg.debdiff' is sufficient? | 08:11 |
| pitti | zyga: yes | 08:11 |
| zyga | thanks | 08:12 |
| pitti | zyga: perhaps put them into a pastebin and point to that in #u-r? | 08:12 |
| zyga | right | 08:12 |
| pitti | probably helps to ask around who has time to review the whole stack | 08:12 |
| pitti | ricotz: uploaded libcdr | 08:13 |
| pitti | Noskcaj: so in bug 1300521 you said that both (i. e. also gnome-photos) just needs a new grilo-plugins dep, but your branch adds a gnome-online-miners dep? | 08:20 |
| ubottu | bug 1300521 in gnome-photos (Ubuntu) "gom-flickr-miner crashed with signal 5 in _start()" [Undecided,New] https://launchpad.net/bugs/1300521 | 08:20 |
| pitti | Noskcaj: is gnome-online-miners a too big dependency, or does it actually use the miners index? | 08:20 |
| Noskcaj | pitti, It was requested by darkxst | 08:25 |
| FourDollars | arges: pitti: Can you help me to do SRU for precise? https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 | 08:28 |
| ubottu | Launchpad bug 1303819 in bluez (Ubuntu Precise) "Bluetooth menu's content disappeared after resume." [Undecided,In progress] | 08:28 |
| pitti | FourDollars: too late, I already uploaded :) | 08:28 |
| pitti | (and updated the MP and bug) | 08:28 |
| FourDollars | pitti: haha. I see it. Thanks a lot. :D | 08:29 |
| jibel | pitti, upgrade to Trusty is still blocked on postgresql-server-dev removal even with the fix of krb5, bug 1304702 is the same on i386 | 08:29 |
| ubottu | bug 1304702 in ubuntu-release-upgrader (Ubuntu) "update-manager fails because of postgresql-server-dev-9.1" [Undecided,New] https://launchpad.net/bugs/1304702 | 08:29 |
| pitti | jibel: hm, that ^ bug is still with the previous krb5 | 08:30 |
| darkxst | pitti, right, gnome-photos does use gnome-online-miners now | 08:30 |
| pitti | jibel: oh wait, actually not | 08:30 |
| pitti | jibel: meh, that helped for me | 08:30 |
| jibel | pitti, 1.12+dfsg-2ubuntu3 is latest version right? | 08:30 |
| pitti | jibel: yes | 08:32 |
| pitti | so I'm afraid I ran out of ideas how to fix this; I might need to invoke the mvo joker card.. | 08:32 |
| ricotz | pitti, thanks! | 08:32 |
| pitti | darkxst: thanks for confirming | 08:32 |
| mvo | pitti: ok, I have a look (bug 1304702, correct?) | 08:34 |
| ubottu | bug 1304702 in ubuntu-release-upgrader (Ubuntu) "update-manager fails because of postgresql-server-dev-9.1" [Undecided,New] https://launchpad.net/bugs/1304702 | 08:34 |
| pitti | mvo: right; I tried to fix that yesterday in https://launchpad.net/ubuntu/+source/krb5/1.12+dfsg-2ubuntu3 by adding an additional Replaces: to the Breaks:, to nudge apt | 08:34 |
| pitti | mvo: that helped in a schroot, but apparenlty not for everyone still | 08:35 |
| jibel | mvo, 1304702 is from saucy to Trusty and 1304403 is from precise to trusty | 08:35 |
| jibel | I'll attach new logs for P->T | 08:35 |
| mvo | ok | 08:36 |
| pitti | jibel: oh, I missed that; so it does work for p->t now? | 08:39 |
| pitti | I didn't test s->t in a schroot | 08:39 |
| jibel | pitti, no it doesn't | 08:40 |
| jibel | pitti, but the format of apt.log changed, maybe it will be more clear | 08:41 |
| mvo | jibel: yeah, it should contain more debug info now | 08:42 |
| Noskcaj | pitti, Would you mind checking the sra-sdk merge i put up? | 08:43 |
| Noskcaj | Your review is wrong | 08:43 |
| pitti | Noskcaj: you mean a newer one than https://code.launchpad.net/~noskcaj/ubuntu/trusty/sra-sdk/ftbfs/+merge/214647 ? | 08:43 |
| pitti | that one is 2.3.3-4~dfsg-1ubuntu1 from Logan_, which is already in teh archive | 08:45 |
| Noskcaj | pitti, never mind. It didn't commit my changes. I'd tried to merge from debian | 08:45 |
| Noskcaj | which should fix ftbfs | 08:46 |
| mvo | jibel: if you get the chance could you run the upgrade with https://launchpad.net/~mvo/+archive/eglibc-trusty/+packages again? I uploaded a new version | 08:46 |
| pitti | apw: hey Andy | 08:46 |
| pitti | apw: infinity said you'd like to take a look at the dpkg segfaults on ppc64el? | 08:46 |
| pitti | apw: it keeps happening a few hours/a day after rebooting; I kept one box in that state (you can ssh) if you want to take a look | 08:47 |
| pitti | smoser: wolfe-{03,04,06} didn't come back after a reboot (needed to because of the dpkg segfaults); would you mind having a look? thanks! | 08:48 |
| pitti | @pilot out | 08:50 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges | ||
| jibel | mvo, in progress | 08:54 |
| mvo | jibel: \o/ | 08:54 |
| mvo | pitti: quick question - its ok to remove postgresql-server-dev-9.1 I assume? its no longer in the archive so it can be removed on a trusty upgrade? | 08:55 |
| pitti | mvo: for -server-dev, yes | 09:06 |
| pitti | mvo: but not for postgresql-9.1, postgresql-client-9.1, postgresql-pl*-9.1, and postgresql-9.1-<extensions> | 09:06 |
| pitti | mvo: our regexp catches -server-dev as well, we could also limit that to not catch that (but still catch extensions) | 09:06 |
| mvo | pitti: ok, I look at the krb-dev transition currently if we could get that under control that should fix the issue, but might still be worthwhile to relax the regexp a little bit | 09:07 |
| pitti | mvo: *nod* | 09:07 |
| apw | pitti, i would indeed | 09:09 |
| Laney | pitti: was your change to network-manager supposed to fix the tests? | 09:23 |
| pitti | Laney: for ppc64 and armhf at least, yes (and that worked) | 09:23 |
| pitti | Laney: as for the x86 test, it seems the ubuntu5 install broke them; I'm looking at them tnow | 09:26 |
| Laney | pitti: okay, thanks - interesting that the failures are x86 specific | 09:27 |
| pitti | Laney: it's not really about the arch, it's about runing in LXC (which doesn't work as the test needs to fiddle with the kenrel) vs. Qemu | 09:28 |
| pitti | Laney: the "isolation-machine" thing just skips the test on LXC instead of failing | 09:28 |
| === alkisg is now known as work_alkisg | ||
| jibel | mvo, no prompt with -0ubuntu4.1 | 09:30 |
| Laney | pitti: aha, so it passes on arm64/ppc64el because the tests aren't actually run there | 09:30 |
| mvo | jibel: \o/ | 09:30 |
| mvo | jibel: thanks a lot for the test | 09:30 |
| pitti | mvo: oh, you have an idea about the krb upgrade? | 09:32 |
| mvo | pitti: yeah, a transitional pkg fixes it, but I'm looking into the resolver right now, its a bit embarassing that it needs so much hand holding :/ | 09:34 |
| pitti | mvo: a transitional package for the old -8 library? eww; but thanks! | 09:34 |
| mvo | pitti: yes, exactly ewww :/ | 09:34 |
| mvo | pitti: it seems like it needs to penalize packages that disappear much stronger | 09:35 |
| cjwatson | pitti: UDD> let's not fix it and use git-dpm instead. :-) | 09:39 |
| * cjwatson trolls gently | 09:39 | |
| pitti | cjwatson: it can't possibly be any more complicated than gitpkg :) (I think I managed to check out the old debian systemd git once, but forgot all about it again) | 09:40 |
| cjwatson | Not a fan of what I've read of gitpkg's approach | 09:41 |
| pitti | cjwatson: yeah, I'm quite happy that they replaced it with a standard git-buildpackage tree now | 09:42 |
| pitti | (or, at least there is one now which is supposed to become "the" tree soon) | 09:43 |
| ev | pitti: what do we lose if we lose ProcMaps in error reports, post-submission? Isn't this what the Dependencies field ultimately provides? | 09:51 |
| ev | context: ProcMaps is 71% of all the data in the error tracker :) | 09:51 |
| pitti | ev: we must have it for retracing | 09:51 |
| pitti | ev: after we computed the stack trace and the duplicate signature (although that alreayd happens client-side), we can drop it | 09:52 |
| ev | cool, that seems easy enough to code | 09:52 |
| pitti | ev: for LP it's occasionally interesting to have it as an attachment, but we can surely kick it out of daisy's db | 09:52 |
| ev | after retrace, go back to the bucket and drop the ProcMaps in each OOPS | 09:52 |
| pitti | *nod* | 09:52 |
| ev | bdmurray: ^ | 09:52 |
| pitti | ev: effectively, you can treat ProcMaps.txt like the core dump; their lifetimes should be quite the same | 09:53 |
| mvo | pitti: I think I have some idea whats going wrong in the resolver, I will continue further after lunch | 09:55 |
| ev | pitti: interesting. I wonder if we should store them in much the same way then. | 09:55 |
| ev | ah, the client doesn't really allow that without some rearchitecting | 09:56 |
| ev | this aforementioned approach should do for now | 09:56 |
| pitti | ev: yes, that's what I thought; treat (CoreDump, ProcMaps) as one thing for conditional submitting, and clean them both up after retracing | 09:56 |
| ev | bdmurray: if you want to investigate both ^ | 09:56 |
| * ev creates an Asana task for this | 09:56 | |
| ev | https://app.asana.com/0/11345516654327/11523893065995 | 09:57 |
| rbasak | cjwatson: around? I'm concerned about bug 1302192. Seems like a critical issue to me, perhaps installer related? | 10:11 |
| ubottu | bug 1302192 in iputils (Ubuntu Trusty) "ping is not setuid root" [Undecided,Confirmed] https://launchpad.net/bugs/1302192 | 10:11 |
| rbasak | Or xnox maybe? ^^ | 10:12 |
| cjwatson | how would that be installer-related? | 10:12 |
| rbasak | It seems to be that the package is good, but an ISO based install mysteriously ends up with the file capability missing | 10:13 |
| === tkamppeter_ is now known as tkamppeter | ||
| cjwatson | well, maybe capabilities aren't preserved in squashfs | 10:13 |
| cjwatson | or maybe ubiquity doesn't copy them, I guess that's possible | 10:13 |
| cjwatson | let me check | 10:13 |
| rbasak | Ah. I didn't realise that ping switched from setuid to a file capability in Saucy -> Trusty | 10:18 |
| cjwatson | /usr/bin/gnome-keyring-daemon /usr/bin/arping /bin/ping /bin/ping6 <- potentially affected programs on my system | 10:25 |
| cjwatson | squashfs does seem to have xattr support though | 10:27 |
| cjwatson | and in particular supports the security namespace | 10:27 |
| cjwatson | so might just be that ubiquity's copying code needs to preserve xattrs | 10:28 |
| rbasak | I should probably know this, but does the server iso even use ubiquity? | 10:30 |
| Unit193 | Should be debian-installer. | 10:31 |
| rbasak | That's what I thought, but I am unsure. I use cloud images. | 10:31 |
| cjwatson | what he said, yes | 10:31 |
| cjwatson | still copying off squashfs in that case for the base system, but using live-installer instead | 10:32 |
| cjwatson | anyway, I'll check both | 10:32 |
| rbasak | OK, thanks. | 10:32 |
| * rbasak needs to brush up in this area | 10:32 | |
| cjwatson | ah, live-installer uses tar, we'd need to pass --xattrs I think | 10:33 |
| * mvo wonders what happend to his eglibc upload, no confirmation from the upload since ~1h | 10:36 | |
| cjwatson | mvo: 10:37 -queuebot:#ubuntu-release- Unapproved: eglibc (trusty-proposed/main) [2.19-0ubuntu3 => 2.19-0ubuntu4] (core) | 10:36 |
| Laney | you should have had a Waiting for approval email | 10:37 |
| cjwatson | good, "getcap /bin/ping" in a live session returns "/bin/ping = cap_net_raw+p" | 10:37 |
| mvo | thanks cjwatson and Laney | 10:39 |
| pitti | cyphermox, Laney: NM> ah, it seems our apparmor workaround for bug 1244157 stopped working | 10:40 |
| ubottu | bug 1244157 in linux (Ubuntu) "[3.11.0-12.18 regression] "Failed name lookup - disconnected path" in dhclient D-BUS access" [Low,In progress] https://launchpad.net/bugs/1244157 | 10:40 |
| cjwatson | mvo: accepted anyhow | 10:42 |
| mvo | thanks cjwatson | 10:42 |
| rbasak | beisner: ^^ if you're interested. Thanks for your help. | 10:52 |
| === MacSlow is now known as MacSlow|lunch | ||
| xnox | jodh: slangasek: looks like mounted events block mountall - instead of "--no-wait" =( | 11:19 |
| === Sweetsha1k is now known as Sweetshark | ||
| jodh | xnox: yes, this is documented in mounted(7) since 'mounted' is a hook-type event (upstart-events(7)). | 12:00 |
| xnox | jodh: ack. Fair enough, used a different check/event so i'm all good. | 12:03 |
| === MacSlow|lunch is now known as MacSlow | ||
| GunnarHj | xnox: Anything I can do to help processing bug #1294858? Or will it have to wait? | 12:35 |
| ubottu | bug 1294858 in ubiquity (Ubuntu) "Installer does not install all language support packages" [Undecided,Confirmed] https://launchpad.net/bugs/1294858 | 12:35 |
| === apachelogger is now known as apakhelogger | ||
| === apakhelogger is now known as apaKhelogger | ||
| xnox | GunnarHj: i didn't have time to look into it yet. if not this week, then it would be for U-cycle / SRU into trusty 14.04.1 release =/ | 12:55 |
| GunnarHj | xnox: Ok thanks, then I know. | 12:56 |
| === _salem is now known as salem_ | ||
| === bfiller_afk is now known as bfiller | ||
| jdstrand | xnox: thanks for the apparmor job! question: because this is a task, it isn't possible for a console login, lightdm login, *dm login, etc to happen without this first running? | 13:17 |
| jdstrand | well a task and its start on line | 13:17 |
| xnox | jdstrand: it's a task, thus "started appararmor-loaded" event will only be emitted after it completes fully. | 13:19 |
| xnox | jdstrand: thus e.g. another jobs can do "and started apparmor-loaded" or in their pre-start do $ start apparmor-loaded, which will block until it's completed. | 13:19 |
| xnox | jdstrand: let me check the graphs to see where it's placed... 1sec. | 13:20 |
| jdstrand | xnox: ok, right. so in order to deploy this properly, we need an apparmor job and then adjust all other login jobs to use "and started apparmor-loaded" | 13:20 |
| jdstrand | xnox: what happens when apparmor is not installed on the system? | 13:21 |
| jdstrand | xnox: eg, someone wants to use selinux | 13:21 |
| smoser | pitti, deal | 13:23 |
| pitti | smoser: in case you need to reboot the host: apw is currently debugging the segfault on wolfe-05, so can you please wait with that a bit? | 13:23 |
| pitti | smoser: rebooting the other three VMs is fine at any time as they are essentially dead (at least with ssh) | 13:23 |
| xnox | jdstrand: there is a better way | 13:24 |
| jdstrand | xnox: I guess we could solve that by having upstart itself ship the job file | 13:24 |
| jdstrand | xnox: oh? | 13:24 |
| jdstrand | xnox: I also think we need something along the lines of: http://paste.ubuntu.com/7226194/ | 13:25 |
| jdstrand | so I can collapse the click-apparmor and apparmor jobs into one | 13:26 |
| xnox | jdstrand: so if we change it to "start on mounted MOUNTPOINT="/" " then that job will block reaching further significant events (e.g. local-filesystems, filesystems, runlevel, etc.) until apparmor profiles are compiled and fully loaded. | 13:26 |
| smoser | pitti, i bounced the guests. | 13:26 |
| smoser | and they should all be up now. | 13:26 |
| jdstrand | (along with short-circuiting some known situations) | 13:26 |
| pitti | smoser: cheers; I'll dist-upgrade them while they are still off jenknis, and then plug them back in | 13:27 |
| xnox | jdstrand: yeah, but will need to add a not-container check in the script itself, since we can't block on an "and" condition. | 13:27 |
| jdstrand | xnox: I'm not sure I understand the statement. are you saying that we should remove 'and not-container' and then uncomment the '#[ -x /bin/running-in-container ] && /bin/running-in-container && exit 0' ? | 13:29 |
| === manjo` is now known as manjo | ||
| xnox | jdstrand: well running-in-container is shipped by upstart =) so yeah, we'd need to add a line which is "! running-in-container" | 13:31 |
| xnox | to the job. | 13:31 |
| jdstrand | xnox: ok, here is the updated job: http://paste.ubuntu.com/7226232/ | 13:33 |
| jdstrand | xnox: the 'better way' was referring to making sure console and display managers logins don't have to be modified? | 13:33 |
| xnox | jdstrand: that's way too much. | 13:34 |
| jdstrand | xnox: what is too much? | 13:34 |
| xnox | jdstrand: clicks are already handled by the click-apparmor.conf job | 13:35 |
| jdstrand | xnox: I know-- I want to remove that job | 13:35 |
| xnox | jdstrand: ok, "convergence" eh? =) | 13:36 |
| jdstrand | honestly, I'd like to find a better way than that hack I came up with to know when to run aa-clickhook, but that is for another day | 13:36 |
| beisner | rbasak - cool, thx. looks like it's just about tackled (ping getcap) | 13:36 |
| xnox | jdstrand: i don't like the gazzilion checks we do in shell. If the task fails, that's fine and the upstart job will stop, cause it's all running under set -e. | 13:38 |
| xnox | jdstrand: thus none of the upstart jobs typically do [ -x /usr/bin/foo ]; exec /usr/bin/foo | 13:38 |
| jdstrand | ehh | 13:39 |
| jdstrand | that makes me very unconfortable | 13:39 |
| xnox | jdstrand: if load_configured_profiles gracefully fails, when apparmor is not available that's all what we need. | 13:39 |
| xnox | jdstrand: i'd rather be aggressively loading the profiles. | 13:39 |
| jdstrand | xnox: load_configured_profiles is shell. I can move the checks there, but not sure what difference that would make | 13:40 |
| xnox | jdstrand: http://paste.ubuntu.com/7226258/ without any checks. | 13:40 |
| xnox | they are no-op code / asserts. | 13:40 |
| jdstrand | so, we actually do have these checks | 13:41 |
| xnox | ... because of $reasons ?! =) | 13:41 |
| jdstrand | look at /lib/init/apparmor-profile-load | 13:41 |
| xnox | right. | 13:41 |
| jdstrand | that is what something like mysql uses | 13:41 |
| jdstrand | we have these checks because over the years we've found they are needed | 13:42 |
| pitti | cyphermox, Laney: NM with adjusted tests uploaded; something in the DHCP client stack got slower, so I had to bump the DHCP timeout from 15 to 20 seconds to make them pass again; the other failure was due to the PE change in ubuntu5 | 13:42 |
| * xnox can't wait for "u-cycle" to switch all of these to apparmor stanza =))) | 13:42 | |
| pitti | cyphermox: I disabled the negative test for the temporary IP with PE disabled, as I'm not sure whether that's intended | 13:42 |
| jdstrand | well, I figured we wouldn't do that too aggressively because of systemd | 13:42 |
| xnox | jdstrand: having all check in the upstart job is fine. as long as the conditions are correct. | 13:43 |
| cyphermox | pitti: I think the PE stuff was broken and is now fixed | 13:43 |
| xnox | jdstrand: e.g. check for /sys/kernel/security manually, as one cannot do "and mounted MOUNTPOINT=" reliable (mounted event blocks mountall and thus other portions of the and condition will not get emitted and deadlock mountall) | 13:43 |
| pitti | cyphermox: yeah, perhaps; before, you got a temp IP with PE enabled, and no temp IP with PE disabled, which sounded quite plausible | 13:44 |
| cyphermox | well, no that's the way it should be | 13:44 |
| xnox | jdstrand: hence "start on mounted MOUNTPOINT="/"" and this point it's past mounting "/sys/kernel/security" or try to mount it again. and all profile loading will block boot. | 13:44 |
| pitti | that's the way that it was until ubuntu5, now it always gets a temp IP | 13:44 |
| xnox | jdstrand: and it practice it's lightning quick, here on a typical laptop with an SSD. | 13:45 |
| cyphermox | pitti: must be that the fixes to some patches got done wrong | 13:45 |
| cyphermox | pitti: I'll take a look at it | 13:45 |
| pitti | cyphermox: ok, thanks; I disabled that test in r812 as you told me it's correct now; but please revert that if it passes again | 13:46 |
| jdstrand | xnox: sorry, you lost me. the apparmor job in my paste (http://paste.ubuntu.com/7226232/) doesn't currently check for /sys/kernel/security/apparmor (I missed that). are you saying it should or should not? | 13:46 |
| xnox | jdstrand: let me reply with a paste =) | 13:46 |
| cyphermox | sure | 13:46 |
| pitti | cyphermox: not sure where the slowdown comes from, but with the increased timeouts they at least pass again | 13:48 |
| cyphermox | right | 13:51 |
| cyphermox | pitti: you meant ubuntu6 for the patches no? | 13:51 |
| cyphermox | ubuntu5 contains a patch, but it should be irrelevant to PE | 13:51 |
| pitti | cyphermox: could be, yes; I meant reversion of the disabled "no temp IP" test (r812) | 13:52 |
| cyphermox | ok | 13:52 |
| pitti | if the previously checked behaviour was in fact right, and the test pointed out an actual regression | 13:52 |
| xnox | jdstrand: something like this: http://paste.ubuntu.com/7226316/ | 13:55 |
| xnox | jdstrand: changed "start on" and added "/sys/kernel/security" block. | 13:55 |
| jdstrand | xnox: ack | 13:56 |
| jdstrand | I wonder if mounting securityfs is enough to get /sys/kernel/security/apparmor | 13:57 |
| jdstrand | I guess it would be (would have to check) | 13:57 |
| pitti | mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > your eglibc upload keeps my little minions busy :) | 13:58 |
| jdstrand | xnox: so, because this is 'start on mounted MOUNTPOINT="/"' and it's a task, does that mean other jobs/tasks will block until this is done? | 13:58 |
| mvo | pitti: hehe | 13:59 |
| jdstrand | xnox: ie, we don't have to adjust the lightdm job (et al) | 13:59 |
| xnox | jdstrand: correct it will block, and no changes are required in other jobs. | 13:59 |
| apaKhelogger | does anyone know under which circumstances /proc/sys/crypto/fips_enabled would be present and get EACCESS on fopen()? | 14:00 |
| apaKhelogger | I don't seem to have crypto/ at all | 14:00 |
| jdstrand | xnox: ok, cool. I've got this locally. I guess my team can figure out if we want to push this in 14.04 (it requires a lot of testing) | 14:01 |
| jdstrand | xnox: thanks for you help! it will definitely be in 14.10 | 14:01 |
| xnox | jdstrand: "in 14.10" as in, in just 9 days ;-) =))))) | 14:01 |
| jdstrand | :) | 14:02 |
| apw | stgraber, when we setup lxc environments, what do we use to setup the network brigding for them ? | 14:04 |
| stgraber | apw: most people just use the bridge that's setup by the lxc-net upstart job, or you can define extra bridges in /etc/network/interfaces or you can use libvirt's own bridges | 14:06 |
| cjwatson | rbasak: ok, hopefully wheels now mostly in motion - thanks for the heads-up | 14:07 |
| rbasak | cjwatson: no problem. Thank you for looking at it at such short notice. I certainly wouldn't have been able to figure out all the pieces quickly enough. | 14:08 |
| cjwatson | I probably can't easily do much about systems that are already broken | 14:08 |
| cjwatson | dpkg-reconfigure of the relevant packages should sort them out, or possibly even ongoing upgrades | 14:08 |
| jdstrand | xnox: so, in theory, this upstart job would remove the need for the apparmor stanza? | 14:09 |
| cjwatson | or sudo apt-get --reinstall iputils-ping etc. (perhaps also iputils-arping, gnome-keyring) | 14:09 |
| Laney | pitti: thanks! | 14:09 |
| cjwatson | s/--reinstall/--reinstall install/ | 14:09 |
| rbasak | --reinstall is what I was thinking. dpkg-reconfigure wouldn't fix the delivered binaries, would it? | 14:09 |
| cjwatson | dpkg-reconfigure has the side-effect of running the postinst and it's the postinst that sets the capabilities | 14:10 |
| cjwatson | but --reinstall is probably better, rather than perpetuating the meme of using dpkg-reconfigure for things other than debconf :) | 14:10 |
| brainwash | xnox: please help! =S | 14:10 |
| rbasak | Ah - I was under the impression that the binary package's archive magically contained the capabilities. | 14:10 |
| cjwatson | no, in a sane world it'd be that way, but I think it has to be in maintainer scripts because packages need to define fallbacks in the event of filesystems that don't support xattrs | 14:11 |
| rbasak | I see - thanks. | 14:11 |
| brainwash | xnox: the xubuntu installer background issue needs to be fixed and I would like to help debugging it | 14:11 |
| rbasak | A no change rebuild of the affected packages would fix everything then, right? Not worth it? | 14:12 |
| apw | stgraber, i am more asking by default what interface do you use to add things to the bridge | 14:13 |
| cjwatson | rbasak: it would, though no way to synchronise it with people who do installs from beta-2 media between now and release | 14:13 |
| apw | stgraber, do you run external things, or talk netlink, or ... | 14:13 |
| stgraber | apw: netlink | 14:13 |
| apw | stgraber, where do i find your netlink bits for that | 14:13 |
| cjwatson | rbasak: maybe just -devel-announce with a recipe once the installer is fixed | 14:14 |
| rbasak | Anyone who installed from beta-2 media would have an older version though, and so would end up upgrading and thus fixing? | 14:14 |
| * rbasak doesn't follow | 14:14 | |
| cjwatson | well, uh, maybe you're right | 14:14 |
| stgraber | apw: https://github.com/lxc/lxc/blob/master/src/lxc/network.c | 14:14 |
| cjwatson | yeah, I think you are | 14:15 |
| cjwatson | still, hold off until the installer's done, I need to get attr in and then I need to write the live-installer code; and we need to upload ubiquity | 14:15 |
| stgraber | apw: oh, actually, looks like the bridge add is done through an ioctl | 14:15 |
| rbasak | OK, sure. Thanks! | 14:15 |
| jamespage | pitti, have you seen anything like bug 1303649 | 14:18 |
| ubottu | bug 1303649 in systemd (Ubuntu) "systemd-logind high cpu consumption" [Undecided,New] https://launchpad.net/bugs/1303649 | 14:18 |
| jamespage | pitti, I've hit it on my main laptop, a spare and now on one of our servers in the CI lab | 14:18 |
| pitti | jamespage: not so far; when did that start, just recently? i. e. with the cgmanager integratino? | 14:18 |
| jamespage | pitti, might have - its definately in the last week or so I noticed it | 14:18 |
| pitti | jamespage: yeah; it otherwise hasn't changed for the entire cycle | 14:18 |
| jamespage | mainly because my fan was being noisy | 14:19 |
| pitti | jamespage: when that happens, could you attach strace to it, to see what it's spinning on? | 14:19 |
| jamespage | pitti, sure | 14:19 |
| jdstrand | xnox: also, this job should also obviate the need to the network-interface-security job, no? | 14:22 |
| xnox | jdstrand: definately not needed any more for the network-manager and networking, not sure about network-interface | 14:27 |
| xnox | jdstrand: yeah, it shouldn't be needed. but do test without network-interface-security job. | 14:28 |
| hallyn | what time does freeze start? | 14:28 |
| jdstrand | xnox: I haven't tested it, but for network-interface-security it needs to have '/' mounted to load the policy at all | 14:28 |
| jdstrand | xnox: so if the apparmor task blocks, then network-interface-security should come after it | 14:29 |
| jdstrand | xnox: but yes, need to test | 14:29 |
| jdstrand | xnox: if it doesn't work, I guess we could add another condition in the network* jobs to make sure | 14:29 |
| mvo | does "Apr 9 14:08:19 base-installer: apt-install or in-target is already running, so you cannot run either of" ring a bell? bugreport from a friend of mine installing the server cd on a dell poweredge. if not I will try to reproduce and look into it | 14:30 |
| mvo | (image from yesterday apparently) | 14:30 |
| hallyn | d'oh, it's tomorrow. silly me | 14:32 |
| rbasak | xnox: may I have your comment on bug 1303717 please? Is a missing init.d script a policy violation? It reads to me that there must be a functional init.d service script, but I thought the plan was to detect and make them non-functional? Thus I'm a little confused. | 14:43 |
| ubottu | bug 1303717 in nis (Ubuntu) " (trusty) missing /etc/init.d/ files" [Undecided,New] https://launchpad.net/bugs/1303717 | 14:43 |
| Daviey | mterry: Hey, your disabled test in duplicity upload... Is there a bug tracking the issue? | 14:44 |
| mterry | Daviey, not yet, just a TODO on my sticky note :) I'll file one | 14:45 |
| Daviey | mterry: I quite favour putting the bug number in the .skip comment personally.. but I am sure you'll keep an eye on this, right? :) | 14:47 |
| Laney | Patch headers! | 14:47 |
| mterry | Daviey, yes. I have an idea of how to fix already. Just didn't want to wait given 14.04's imminent release :) | 14:48 |
| Daviey | Laney: well yeah, that aswell... but seeing the skip reason when running a build does stand out. | 14:49 |
| xnox | rbasak: it's a policy violation in Debian. | 14:50 |
| xnox | rbasak: in ubuntu we have about 220 upstart jobs without init.d scripts shipped. | 14:51 |
| rbasak | xnox: thanks. We're considering it fine in Ubuntu to continue with upstart jobs with no init.d counterpart then? | 14:51 |
| ogra_ | until systemd comes :) | 14:53 |
| === alexlist is now known as alexlist` | ||
| === apaKhelogger is now known as apachelogger | ||
| xnox | rbasak: yes. as long as they are precise and trusty compatible. | 14:58 |
| === jono is now known as Guest1478 | ||
| mterry | Daviey, bug 1305124 filed btw | 15:03 |
| ubottu | bug 1305124 in Duplicity "test_last_file_missing_at_end test is flaky" [Undecided,New] https://launchpad.net/bugs/1305124 | 15:03 |
| LocutusOfBorg1 | hi, any ubuntu-sponsor there? | 15:15 |
| LocutusOfBorg1 | I got an ack from release team | 15:15 |
| LocutusOfBorg1 | https://bugs.launchpad.net/ubuntu/+bug/1290253 | 15:15 |
| ubottu | Launchpad bug 1290253 in Ubuntu "[Ffe] Sync can-utils 0.0+git20140227-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] | 15:15 |
| rbasak | LocutusOfBorg1: try arges. He's listed in the topic as on patch pilot duty today. | 15:16 |
| arges | rbasak: i am? i can take a look | 15:16 |
| LocutusOfBorg1 | thanks | 15:17 |
| LocutusOfBorg1 | usually I don't bother people, but they asked for "asap" | 15:17 |
| arges | LocutusOfBorg1: is there a debdiff / bzr associated with this bug? | 15:18 |
| arges | oh its a sync | 15:19 |
| LocutusOfBorg1 | sync | 15:19 |
| LocutusOfBorg1 | plain sync | 15:19 |
| * arges looks at it | 15:22 | |
| LocutusOfBorg1 | arges, can you please also look at this bug? | 15:23 |
| LocutusOfBorg1 | https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1296763 | 15:23 |
| ubottu | Launchpad bug 1296763 in gambas3 (Ubuntu) "Please merge gambas3 3.5.2-1 (universe) from Debian testing (main)" [Undecided,New] | 15:23 |
| LocutusOfBorg1 | seems to be the only way to fix https://bugs.launchpad.net/ubuntu/+source/gambas3/+bug/1295963 | 15:23 |
| ubottu | Launchpad bug 1295963 in gambas3 (Ubuntu) "the official packages for gambas3 is wrong" [Undecided,New] | 15:23 |
| arges | man, i forgot to pilot out from the other day | 15:23 |
| arges | @pilot out | 15:23 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| arges | LocutusOfBorg1: ok let me get to that next. | 15:23 |
| LocutusOfBorg1 | but unfortunately the package is stuck in debian/new queue | 15:24 |
| LocutusOfBorg1 | no problem arges | 15:24 |
| LocutusOfBorg1 | :) | 15:24 |
| LocutusOfBorg1 | I really appreciate | 15:24 |
| === olli__ is now known as olli | ||
| * pitti hugs mvo | 15:25 | |
| pitti | mvo: apt: 10000b years and still not perfect :) | 15:25 |
| mvo | pitti: very true! | 15:26 |
| * mvo hugs pitti | 15:26 | |
| arges | LocutusOfBorg1: bug 1296763 needs an FFe... its a really really big jump in versions and I doubt its a 'bug-fix only release'. I'll mark this in the bug | 15:28 |
| ubottu | bug 1296763 in gambas3 (Ubuntu) "Please merge gambas3 3.5.2-1 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/1296763 | 15:28 |
| LocutusOfBorg1 | yes arges , but the current version seems to be unusable | 15:29 |
| LocutusOfBorg1 | don't know, this isn't a package I care too much | 15:29 |
| LocutusOfBorg1 | but I'm working on libsdl-gfx transition right now | 15:30 |
| LocutusOfBorg1 | and gambas is FTBFS | 15:30 |
| LocutusOfBorg1 | the same for ubuntu https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741789 | 15:30 |
| ubottu | Debian bug 741789 in src:gambas3 "gambas3: FTBFS: dh_install: gambas3-gb-db-postgresql missing files (usr/lib/gambas3/gb.db.postgresql*), aborting" [Serious,Open] | 15:30 |
| arges | LocutusOfBorg1: understood. see comment in the bug regarding FFe. Try going through that process. | 15:30 |
| arges | cjwatson: i'm looking at bug 1290253. i'd like to sponsor this FFe, but its a new package. Which tool(s) do I use to get this package in the upload queue? I have some ideas, but i'd liek to make sure i'm doing this correctly. Thanks | 15:35 |
| ubottu | bug 1290253 in Ubuntu "[Ffe] Sync can-utils 0.0+git20140227-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1290253 | 15:35 |
| cjwatson | just syncpackage as normal | 15:35 |
| arges | cjwatson: then I should see it in the trusty new queue? | 15:36 |
| cjwatson | yep | 15:36 |
| arges | cjwatson: so acutally i did run this, but didn't get any feedback. I did 'syncpackage can-utils'... | 15:37 |
| cjwatson | it's in the new queue | 15:37 |
| cjwatson | $ queue info can-utils | 15:37 |
| cjwatson | or https://launchpad.net/ubuntu/trusty/+queue | 15:38 |
| arges | cjwatson: ah there it is : ) ok thought i was going crazy | 15:38 |
| arges | cjwatson: thanks | 15:38 |
| cjwatson | np | 15:38 |
| LocutusOfBorg1 | thanks | 15:52 |
| Riddell | Sweetshark: what's the plan for bug 1300283 ? you will upload with the revert? | 16:03 |
| ubottu | bug 1300283 in libreoffice (Ubuntu) "LibreOffice does not start in a KDE 4 session" [Critical,In progress] https://launchpad.net/bugs/1300283 | 16:03 |
| cjwatson | Riddell: he already did, I accepted it recently | 16:08 |
| mvo | slangasek: I was looking at bug #1243090 as it appears on the qa tracker and wonder if http://bazaar.launchpad.net/~mvo/update-notifier/use-pycurl/revision/845 might be something worth considering (needs a real testcase first, but not worth persuing if its too late anyway which I kind of suspect :) | 16:09 |
| ubottu | bug 1243090 in update-notifier (Ubuntu) "Dist Upgrade from 13.04 to 13.10 stuck during flashplugin-installer" [Undecided,Confirmed] https://launchpad.net/bugs/1243090 | 16:09 |
| Riddell | cjwatson: nice | 16:12 |
| jdstrand | slangasek, xnox and infinity: fyi, I just subscribed you to bug #1305108 (I split it from bug 1298539). if you want to peruse the attach job for obvious errors or the description for obvious problems, that's fine, but mostly I wanted to make sure you guys saw in conversations surrounding it. | 16:13 |
| ubottu | bug 1305108 in apparmor (Ubuntu) "please provide upstart job for apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/1305108 | 16:13 |
| ubottu | bug 1298539 in upstart (Ubuntu) "apparmor rcS.d sysv initscript is running too late" [Undecided,New] https://launchpad.net/bugs/1298539 | 16:13 |
| jdstrand | slangasek, xnox, infinity: the security team hasn't discussed the timing of landing this, so fyi only atm | 16:13 |
| === bfiller is now known as bfiller_afk | ||
| infinity | jdstrand: I like it. What are the odds we could band together and test this enough to actually make the change for release? I know that fails the "conservative changes only" test by a mile, but I can't help thinking the security (and simplicity) win here is worth it. | 16:21 |
| jdstrand | infinity: it is tempting, isn't it? I need to talk with mdeslaur and the team to see what resources we can put behind it. I plan to do that in a bit when people are online | 16:25 |
| * jdstrand is coordinating another landing atm | 16:25 | |
| mdeslaur | I personally think it's insane | 16:28 |
| infinity | mdeslaur: What's insane? Trying to land the upstart change? | 16:37 |
| infinity | mdeslaur: Or the current state of affairs? | 16:37 |
| infinity | mdeslaur: Or both? :P | 16:37 |
| mdeslaur | trying to land that at this time, in an LTS, blocking boot for policy compilation, not adding it to upstart as a library before other jobs get processed, etc. | 16:37 |
| zyga | mvo: hey, could you look at checkbox-ng in debian again? we missed a build-dep after one of the dpeendencies droping one of their own dependency. I just commited a one-line fix for that, could you please sponsort that and sync it over to Ubuntu? | 16:40 |
| zyga | http://paste.ubuntu.com/7227007/ | 16:40 |
| zyga | that's the debidiff | 16:40 |
| zyga | roadmr: ^^ | 16:40 |
| zyga | pitti: ^^ (perhaps?) | 16:40 |
| roadmr | zyga: looks ok to me, but we need someone who can sponsor that for us :( | 16:42 |
| zyga | I know, just letting you know | 16:42 |
| slangasek | mvo: 1243090> how does switching to curl fix the actual bug? | 16:43 |
| roadmr | zyga: thanks :) | 16:43 |
| slangasek | mvo: I'm inclined to say we shouldn't push this before 14.04; but if we know for sure that curl fixes a bug vs. urllib, maybe this should be an SRU? | 16:44 |
| pitti | zyga, roadmr: yes, can sponsor | 16:44 |
| zyga | thanks | 16:45 |
| * zyga needs to figure out how to do clean feeder archive builds locally :-( | 16:45 | |
| pitti | zyga: uploaded | 16:48 |
| zyga | pitti: thanks, what do we need to do about syncing it to ubuntu now? | 16:48 |
| zyga | pitti: requestsync again after it clears debian? | 16:48 |
| pitti | zyga: wait for about 8 hours, i. e tomorrow morning | 16:48 |
| zyga | pitti: can that still be synced tomorrow? the deadline is 10th of April, is it not? | 16:51 |
| pitti | zyga: I can also do a fakesync | 16:51 |
| zyga | what it a fakesync? | 16:51 |
| pitti | take the Debian .dsc and build an ubuntu source.changes for it (syncpackage --no-lp) | 16:52 |
| pitti | zyga: uploaded; if the release team doesn't like that, we can sync it properly tomorrow morning | 16:52 |
| zyga | pitti: thanks, I really owe you one | 16:52 |
| * zyga will learn and setup proper clean, feeding package build infrastructure at home | 16:53 | |
| slangasek | jdstrand, mdeslaur, infinity: yes, I don't think we should make this change last minute, especially when the driver for this seems to be an issue we have no root causing for and moving apparmor loading up earlier in boot risks making our race condition harder to track down (but no less harmful) | 16:53 |
| pitti | zyga: sbuild is great; if you combine it with apt-cacher-ng, and symlink /var/lib/schroot/unpack to a tmpfs (I use /tmp), it outright rocks :) | 16:54 |
| pitti | and mk-sbuild is fairly easy to do | 16:54 |
| zyga | I'll give sbuild another go, I had issues with getting some of standard tools to build clean debian correctly and I ended up doing custom, broken stuff | 16:55 |
| pitti | hm, I build all my stuff in a sid sbuild, works quite nicely | 16:59 |
| cjwatson | ditto, have absolutely no problem with sbuild for Debian. I think a few Ubuntu releases back it was less good | 17:05 |
| Laney | my problem is my inability to remember -s | 17:08 |
| pitti | Laney: heh, me too; I have alias sbuild-sid='sbuild -s -d unstable' | 17:09 |
| pitti | Laney: and $build_source = 0; in ~/.sbuildrc, as I don't generally want it to (re)build my source, I usually do that with bzr bd or git-buildpackage | 17:10 |
| Laney | pitti: good idea | 17:10 |
| Laney | ooh, build_source, that'll help | 17:10 |
| Laney | hrm, it's supposed to default to 0 | 17:11 |
| pitti | Laney: perhaps; could also be because I copied that from a template | 17:14 |
| * pitti waves good night | 17:14 | |
| Laney | I'm in the habit of not passing -s for ubuntu because it was doing that ... | 17:14 |
| Laney | possibly an obsolete habit though | 17:14 |
| bdmurray | pitti: what about ProcMaps and python crashes - is it useful? | 17:15 |
| cjwatson | chrisccoulson: is there any chance you could fix the firefox-testsuite -> ttf-arphic-ukai NBS entry (http://people.canonical.com/~ubuntu-archive/nbs.html) in time for release? | 17:22 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === tinoco is now known as inaddy | ||
| bdmurray | jibel: why is bug 1269397 set to high? | 18:05 |
| ubottu | bug 1269397 in update-manager (Ubuntu) "update-manager crashed with AttributeError in resize_to_standard_width(): 'NoneType' object has no attribute 'get_resolution' if $DISPLAY is not set" [High,Triaged] https://launchpad.net/bugs/1269397 | 18:05 |
| === bfiller_afk is now known as bfiller | ||
| chrisccoulson | cjwatson, will get to it later | 18:14 |
| bdmurray | infinity: Do you have time to look at bug 1296386? | 18:19 |
| ubottu | bug 1296386 in casper (Ubuntu) "[PATCH] Remove 23etc_modules script" [Undecided,New] https://launchpad.net/bugs/1296386 | 18:19 |
| infinity | bdmurray: It seems to rely on a kernel patch that hasn't been accepted yet. | 18:29 |
| infinity | bdmurray: Err, well, the other bug does. This one might be harmless to fix regardless. | 18:30 |
| bdmurray | infinity: ah, well I think the casper one is causing some install failures | 18:31 |
| infinity | Yeah, we can fix the casper one. It might break sound on a select few machines in the live environment, but that seems like a fair tradeoff. | 18:32 |
| infinity | bdmurray: FWIW, it was added in 2006, due to https://bugs.launchpad.net/ubuntu/+source/casper/+bug/27862 | 18:35 |
| ubottu | Launchpad bug 27862 in casper (Ubuntu) "sound does not work any more on ppc live CD" [Medium,Fix released] | 18:35 |
| bdmurray | woo, a time capsule | 18:36 |
| infinity | bdmurray: So, the way I see it, fixing casper will make the live session happy, but the world will still explode on reboot into the installed system without fixing bug #1296373 | 18:38 |
| ubottu | bug 1296373 in hw-detect (Ubuntu) "[PATCH] Fix sound on PowerPC" [Undecided,New] https://launchpad.net/bugs/1296373 | 18:38 |
| infinity | And fixing that one will leave people without sound entirely until the kernel patch is in. | 18:38 |
| infinity | Fun. | 18:38 |
| infinity | Maybe still worth it. | 18:38 |
| infinity | No sound is better than crashy kernels. | 18:38 |
| infinity | bdmurray: casper change uploaded, hw-detect change commented on, kernel change still in BenH's hands, but maybe we can get it pulled into 3.13 stable as an SRU. | 18:47 |
| cjwatson | chrisccoulson: thanks | 20:25 |
| === salem_ is now known as _salem | ||
| Sweetshark | Riddell: as noted on the bug: was uploaded today, has finished building on amd64/i386. Note that the libreoffice-kde thing in 4.2.3 is still somewhat shaky, there is a set of additional fixes upstream in for 4.2.4 that were too risky to backport this late. | 20:41 |
| Sweetshark | Riddell: so while this fixes the immediate issue -- back to the state we had before, 4.2.4 should be better in general, and be quickly SRUed after testing. | 20:43 |
| Riddell | Sweetshark: great, thanks | 20:47 |
| === mwhudson- is now known as mwhudson | ||
| rsalveti | slangasek: bug 1305315 (the issue with the i386 android toolchain) | 21:17 |
| ubottu | bug 1305315 in gcc-i686-linux-android (Ubuntu) "Android container fails to start when built with the gcc-i686-linux-android toolchain" [Undecided,New] https://launchpad.net/bugs/1305315 | 21:17 |
| rsalveti | and another one related with the toolchain: bug 1302799 | 21:21 |
| ubottu | bug 1302799 in gcc-i686-linux-android (Ubuntu) "Android build fails if -fstack-protector is used in TARGET_GLOBAL_CFLAGS" [Undecided,New] https://launchpad.net/bugs/1302799 | 21:21 |
| rsalveti | slangasek: for qtbase: http://paste.ubuntu.com/7228323/ | 22:02 |
| rsalveti | slangasek: also had to remove the custom override_dh_makeshlibs rule, as that was causing all the packages to have a runtime dep of (= ${binary:Version}) | 22:03 |
| rsalveti | that was something we got from the 4.8 src package, not sure exactly why that was decided | 22:04 |
| rsalveti | let me know if you're fine with it and I'll do a src upload | 22:04 |
| slangasek | rsalveti: fwiw in my own testing, variants 3 and 5 of the symbol dependency were unused and can be safely dropped | 22:05 |
| rsalveti | slangasek: yup, just had there for reference, but yeah, let me remove it | 22:05 |
| slangasek | rsalveti: seems ok to me otherwise | 22:07 |
| slangasek | and pretty closely matches what I had here | 22:07 |
| rsalveti | great | 22:07 |
| bdmurray | stgraber: does ubiquity update itself before starting the install? | 22:14 |
| stgraber | bdmurray: no. The option is however provided to the user if they wish to do so. | 22:18 |
| bdmurray | stgraber: ah, and do you recall what that updates? just ubiquity? | 22:19 |
| stgraber | bdmurray: not sure, sorry | 22:22 |
| === _salem is now known as salem_ | ||
| xnox | bdmurray: from code, it upgrades ubiquity. but it needs to be service-side triggered (e.g. similarish to how upgrade-manager / manifests are triggered to move people to next lts) | 23:11 |
| xnox | bdmurray: i've never triggered that, though. | 23:12 |
| xnox | bdmurray: 'http://changelogs.ubuntu.com/ubiquity/%s-update-available' % _ver is the trigger | 23:13 |
| bdmurray | xnox: I think the fix for bug 1051935 created bug 127706 | 23:13 |
| ubottu | bug 1051935 in oneconf (Ubuntu Precise) "Fails with SystemError when too many files are open" [Undecided,Confirmed] https://launchpad.net/bugs/1051935 | 23:13 |
| ubottu | Error: Launchpad bug 127706 could not be found | 23:14 |
| bdmurray | er bug 1277706 | 23:14 |
| ubottu | bug 1277706 in ubiquity (Ubuntu) "ubiquity install failure due to new ubiquity and old python-apt" [High,Confirmed] https://launchpad.net/bugs/1277706 | 23:14 |
| xnox | bdmurray: not sure what you mean, we respun isos to have everything matching and the bug posted is using Mythbuntu 12.04.3 "Precise Pangolin" - Release i386 (20130820) - 12.04.3 media | 23:15 |
| xnox | bdmurray: during sru process we noticed that we both updated on the images, which we did for 12.04.4 | 23:16 |
| xnox | bdmurray: or you think we should be triggering ubiquity upgrade for 12.04.0, .1, .2 and .3 media? we'd need to test them... | 23:17 |
| bdmurray | xnox: I'm suggesting that ubiquity gets updated and then tries to use code only available in the new version of python-apt | 23:17 |
| bdmurray | xnox: notice how there are 2 different ubiquity versions in the log | 23:17 |
| bdmurray | 2.10.26 and 2.10.29 | 23:18 |
| xnox | i see what you mean now. | 23:18 |
| xnox | bdmurray: right, ubiquity in precise should have a tigher versioned depends on python-apt e.g. >= 0.8.3ubuntu7.2 and we did not do that. This way if somehow, for whatever reason ubiquity is upgraded in the live system (manually that is at the moment) an updated python-apt is also forced to be installed. | 23:21 |
| bdmurray | ah, yeah that would fix it | 23:22 |
| xnox | bdmurray: i'll prepare the SRU and test-plan to reproduce the bug. | 23:24 |
| bdmurray | xnox: I don't think it should be a rush | 23:24 |
| bdmurray | I mean it would be fine after 14.04... | 23:25 |
| xnox | bdmurray: well assigning the bug to myself for now. indeed it's not a common code path to hit. Indeed 14.04 tasks are of the most priority at the moment =)))) | 23:25 |
| * xnox needs more vocabulary | 23:26 | |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!