[04:57] <pitti> Good morning
[05:01] <pitti> SpamapS: did you copy with -s? mdeslaur pinged me about the linux-meta ABI mismatch in -security
[05:01] <pitti> SpamapS, slangasek: I usually copy the kernel and lbm, then check https://launchpad.net/ubuntu/+source/linux/+publishinghistory that it really worked, and then copy -meta, and check its publishing-history again
[05:03] <pitti> SpamapS: if you do copies, please always look up the tracking bug (seems to be bug 893213 in this case), to check for "updates only" vs. "updates and security", and closing the tasks
[05:03] <pitti> SpamapS: we need to copy the whole thing or nothing
[05:03] <pitti> SpamapS: also, please no kernels or other major SRUs on a Friday evening :)
[05:07] <pitti> SpamapS, mdeslaur: I copied the remaining kernel bits to -security and updated the tracking bug
[05:11] <pitti> doko: yes, I'm the other DB (psql), not mysql :)
[05:18] <ScottK> pitti: Good morning.  It turns out that there's a regression in libmsn that prevented the kdenetwork part of the post-release update from building.  The proposed SRU for libmsn to fix the regression is waiting for approval, so it'd be nice to get that in so that I can get the set completed and a call for testing out the door on Monday.
[05:22] <pitti> ScottK: ah, will do
[05:22] <ScottK> pitti: Thanks.
[05:23] <pitti> ScottK: accepted; do you want to retry the affected packages yourself, or want me to watch for it?
[05:23] <ScottK> pitti: It'd be great if you watch for it since I'm about to go to sleep.  It's just kdenetwork.
[05:24] <ScottK> If you don't get to it though, I'll just to it in my morning.
[05:24] <pitti> ScottK: roger, can do; sleep well!
[05:24] <ScottK> Thanks.
[06:03] <pitti> zul, Daviey: can you please drop the python-coverage dependency from python-nova? this is rendering it uninstallable
[06:07] <pitti> jibel, jamespage: so https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=lts-ubuntu,label=upgrade-test/lastBuild/console -> the upgrade succeeded now, and it rebooted, but it complains about some extra old conffiles and X not starting?
[06:09] <pitti> jibel, jamespage: and similarly for lts-server, it just complains about conffiles? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=lts-server,label=upgrade-test/lastBuild/console
[06:09] <pitti> jibel, jamespage: what does this test do exactly? having .dpkg-dist files is pretty normal after an upgrade
[06:17] <slangasek> pitti: -s?
[06:18] <slangasek> pitti: I certainly used a -s argument for target suite; I'm not sure how that relates to your comment
[06:18] <pitti> slangasek: sru-release -s -> also copies to -security
[06:18] <slangasek> er, source suite rather
[06:18] <slangasek> no, I didn't use sru-release
[06:18] <pitti> that's the tool SpamapS used
[06:18] <slangasek> he said it timed out
[06:19] <pitti> 05:56:16      SpamapS | [00:44:45] bjf: thats more like it!!
[06:19] <pitti> that sounded like a second try succeeded?
[06:19] <pitti> ah, so it didn't then, misunderstood
[06:20] <pitti> slangasek: ok, so when the kernel team says "linux" they really mean "linux, lbm, -meta, and whichever else is attached to it", and the tracking bug says whther or not to also copy to -security
[06:20] <slangasek> ah
[06:21] <pitti> kirkland: eww, your sysvinit upload causes a conflict
[06:21] <pitti> kirkland: /etc/bash_completion.d/service is already in bash-completion
[06:21] <pitti> I'll revert it
[06:25]  * micahg was wondering about that
[06:25] <pitti> kirkland: b-c is in standard, so everyone should already have it?
[06:53] <pitti> slangasek: I debugged bug 901638 somewhat and added a proposal
[06:53] <pitti> slangasek: but I'm not sure whether it would be semantically correct to add that conflicts
[06:54] <pitti> slangasek: I tried raising tdsodbc's Breaks: libiodbc2 to a Conflicts, but that's not enough
[06:54] <pitti> (as unversioned Breaks: are discouraged)
[06:55] <slangasek> pitti: having odbcinst1debian Conflict: with libiodbc2 is not semantically accurate, but given that libiodbc2 is intended to be obsoleted, that's probably not sufficient reason not to do that
[06:57] <pitti> slangasek: is there another package which is a better "replacement" for libiodbc2?
[06:57] <pitti> slangasek: I'm happy to move to conflicts: around a bit and try
[06:57] <SpamapS> pitti: I haven't done the kernel copies myself since the API times out. I respectfully refuse to attempt any such things again until the procedure is recorded somewhere. :)
[06:58]  * SpamapS hopes it actually is already recorded, and he can be pointed to it
[06:58]  * SpamapS is also ashamed at how little SRU approval work he has done in the last 7 days
[06:58] <pitti> I tried to keep up, but didn't manage to clean up all the queues
[06:58] <pitti> but RAOF is back now as well, so perhaps we can share the load again
[07:06] <slangasek> pitti: I guess the conflicts could be added to libodbc1 instead, but logically it's all Breaks, not Conflicts
[07:06] <pitti> slangasek: testing..
[07:07] <pitti> hm, that doesn't do it
[07:08] <pitti> neither a Conflicts:
[07:09] <pitti> slangasek: adding a Breaks: libiodbc2 instead of a Conflicts: to odbcinst1debian2 _does_ work, though
[07:09] <SpamapS> pitti: when my Monday starts officially (in 9 hours or so) I promise I'll crank through anything left in the queue. :)
[07:09] <pitti> SpamapS: thanks! I'll also try to catch up a little today
[07:10] <pitti> slangasek: noted so in the bug
[07:10] <slangasek> ok, cool
[07:10] <pitti> slangasek: want me to upload that to Ubuntu and let it go through the mail-all upgrade test, or do you want to handle this yourself/in Debian?
[07:11] <slangasek> pitti: feel free to upload it and I'll pull it back into Debian from there
[07:11] <pitti> slangasek: I can only suppose it's also an issue for squeeze->wheezy upgrades?
[07:11] <slangasek> I expect so, yes
[07:11] <pitti> squeeze has 0.82-7
[07:11] <pitti> exactly like oneiric
[07:11] <pitti> slangasek: ok, doing that then, thanks!
[07:12] <pitti> . o O { must .. have ... more ... green ... dots! }
[07:18] <pitti> jamespage, jibel: the precise-server tests failed; not much output, but I bet it was due to the file conflict in sysvinit-utils, which is fixed now; the other is that nova is uninstallable, I pinged the server team about it
[07:19] <pitti> Daviey: ^ I'm also happy to fix this (i. e. drop python-coverage from the pips requirements)
[07:19] <pitti> Daviey: I can push to the branch, but not sure you guys want me to
[07:22] <pitti> ScottK: kdenetwork seems happy now, FTR
[07:23] <broder> could somebody on ubuntu-branches mark https://code.launchpad.net/~marcelstimberg/ubuntu/oneiric/labyrinth/fix-for-872756/+merge/84856 as merged?
[07:31] <pitti> broder: done
[07:31] <broder> thanks
[07:40] <slangasek> pitti: did you want to reassign bug #901638 to unixodbc, though?  odbcinst1debian isn't from freetds
[07:48] <geser> pitti: could you please dupe and close bugs #903048, #903068, #903049 and #903050 (the sysvinit upgrade issue you fixed half an hour ago). Thx
[07:49] <geser> LP doesn't let me log in to do it myself
[07:49] <pitti> slangasek: yes, I did
[07:50] <pitti> geser: oh, thanks; I looked for bugs when I uploaded, and there weren't any
[07:51] <pitti> geser: done
[07:53] <pitti> jibel, jamespage: respinning ubuntu-server to pick up fixed sysvutil
[08:27] <micahg> tjaalton: we don't merge nspr from Debian, it's a totally different package and there was a warning on MoM
[08:27] <tjaalton> micahg: i've asked chrisccoulson about it
[08:28] <micahg> well, that's news to me...
[08:28] <tjaalton> it's not "totally" different, doesn't use sonames but mergeable anyway
[08:29] <tjaalton> same goes to nss
[08:29] <micahg> tjaalton: please don't upload 3.13
[08:29] <tjaalton> micahg: why?
[08:29] <micahg> it seems broke
[08:30] <tjaalton> in which way? works fine on my laptop
[08:30] <tjaalton> uploaded already
[08:30] <tjaalton> used it for two weeks
[08:32] <micahg> well, I guess we'll see what breaks
[08:33] <tjaalton> if you already know something please do tell
[08:33]  * micahg sees if he can find the bug
[08:36] <micahg> tjaalton: mozilla 702111
[08:39] <micahg> tjaalton: FTR, I'm actually in favor of being able to merge from Debian, I just thought there was something WRT to the upstream tarball that was keeping us from doing it
[08:41] <tjaalton> micahg: i did it very carefully, checked every diff on launchpad to make sure I didn't miss anything, but in the end it turned out to be mostly just the soname change in them, so the diff is actually pretty small (and some bugs fixed due to the merge..)
[08:41] <micahg> tjaalton: right, that's the packaging side, what about the upstream tarball :)
[08:41] <tjaalton> micahg: also, that bug seems fixed upstream now, so should be ok once firefox is updated, though I'm ok if an archive admin can hold off nss for now
[08:42] <tjaalton> micahg: don't see changes made directly ther
[08:42] <tjaalton> e
[08:42] <micahg> tjaalton: how is that fixed upstream, it's New?
[08:42] <tjaalton> unaffected on 8, fixed for 9
[08:42] <tjaalton> or is 10 already on precise?
[08:42] <micahg> tjaalton: yes, they disabled the feature, that's only in the firefox branch, not NSS :)
[08:44] <micahg> and it shouldn't hit NEW of any type since there are no new packages/soname bumps
[08:44] <tjaalton> ahah, didn't check the product..
[08:44] <raphink> Hello there
[08:44] <tjaalton> micahg: it build-depends on the new nspr, so there might be enough time..
[08:45] <tjaalton> pitti: ^ can you still drop an update from entering when it's in depwait?
[08:45] <raphink> https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/881673 is blocking for GNOME3 users in oneiric
[08:45] <pitti> tjaalton: entering what?
[08:45] <micahg> tjaalton: do you want to revert based on that bug?  you said you've been using it for 2 weeks :), Firefox won't be affected since we use internal libs
[08:45] <tjaalton> pitti: the archive (precise)
[08:45] <raphink> can we port the patch to oneiric-updates?
[08:45] <tjaalton> micahg: oh
[08:46] <pitti> tjaalton: you can upload a newer version which reverts to a previous version
[08:46] <pitti> tjaalton: then the previous builds will be discarded
[08:46] <micahg> chromium might be affected once I get it to build, but meh
[08:46] <pitti> tjaalton: if it's a new package, it can also be removed
[08:46] <tjaalton> micahg: well turns out I didn't use it <blush>, but sounds like it's not that big an issue afterall?
[08:47] <micahg> tjaalton: evolution and pidgin are consumers, have you used either of those?  empathy probably as well
[08:49] <micahg> raphink: You'll want to follow the procedures documented here: https://wiki.ubuntu.com/StableReleaseUpdates, I'm happy to create an oneiric task for you if you want to work on this
[08:49] <tjaalton> pitti: no it's just an update. I'll check if anything breaks with the new one first before doing anything drastic
[08:49] <tjaalton> micahg: I'll test pidgin
[08:49] <raphink> micahg: thanks, it's presily the process that I'm wondering about ;-)
[08:49] <micahg> tjaalton: GTALK would probably be a common one
[08:52] <micahg> tjaalton: epiphany could be a good test as well
[08:53] <micahg> raphink: do you have any specific questions?
[08:53] <tjaalton> micahg: hum, shouldn't it be installed by default?
[08:53] <micahg> tjaalton: which?
[08:53] <tjaalton> epiphany
[08:54] <micahg> no, epiphany is the GNOME browser
[08:54] <tjaalton> oh, haha
[08:54] <tjaalton> so i installed the boulder dash clone
[08:54] <tjaalton> mixed it with empathy
[08:55] <micahg> chromium would be fine also to test with
[08:57] <raphink> micahg: what is the process these days to request a sync from Debian for precise?
[08:58] <micahg> raphink: requestsync, we sync automatically from Debian testing right now if there's not an Ubuntu diff
[08:59] <raphink> synergy is in version 1.3.7-1build1 in precise
[08:59] <raphink> ah right, testing
[09:00] <raphink> is it possible to sync from sid if it fixes a known bug?
[09:00] <raphink> or do we have to wait for the package to enter testing?
[09:00] <micahg> raphink: if it's not likely to break anything else, yes, just state the reasoning for the jump in the sync request
[09:01] <raphink> that, or I just wait for the package to migrate to testing
[09:01] <micahg> raphink: right
[09:01] <raphink> since it was uploaded to sid on the 4th of december
[09:01] <micahg> raphink: should migrate in 3 days
[09:02] <raphink> yes
[09:02] <raphink> and I confirm that it fixes the problem
[09:03] <raphink> for now, I'll just upload it to my PPA :-)
[09:03] <broder> pitti: is the pkgbinarymangler test suite supposed to work outside of the archive builder setup?
[09:03] <pitti> broder: yes, it is
[09:03] <broder> pitti: i'm getting http://paste.ubuntu.com/767674/
[09:03] <pitti> broder: I'm running it locally
[09:04] <tjaalton> micahg: chromium seems to work, other than the url from that bug
[09:04] <pitti> broder: interesting; I suppose that's with the current version?
[09:04] <broder> hmm...interesting question. my checkout might be old <_< >_>
[09:04] <broder> no, it's currnet
[09:05] <micahg> tjaalton: check the site in comment 15
[09:05] <broder> pitti: (i decided that trying to write a fix for bug #899520 was a better option than sleeping)
[09:06] <pitti> broder: ah, sweet; generating correct relative symlinks in shell is really hard, so I didn't get to that so far
[09:06] <pitti> broder: hang on
[09:06] <broder> i'm working on a slightly hilarious port of dh_link to shell. i'm simultaneously proud of and repulsed by it :)
[09:07] <tjaalton> micahg: works, nordea too
[09:07] <pitti> broder: could you locally apply http://paste.ubuntu.com/767679/ and then run: test/run -v T.test_doc_symlink
[09:07] <micahg> tjaalton: alright, I think chromium might have their own fix for this bug though now that I think about it
[09:07] <pitti> broder: this will output the full build log and just run this one test
[09:08] <pitti> broder: do you get that failure with pristine trunk or did you already do modifications?
[09:08] <tjaalton> micahg: ok, so the impact is pretty low then
[09:08] <pitti> broder: it's still succeeding here
[09:08] <broder> pitti: i got it with pristine trunk
[09:08] <pitti> broder: ok, let's see what your build log says
[09:10] <broder> pitti: http://paste.ubuntu.com/767682/
[09:12] <Daviey> pitti: Don't worry, it'll get resolved today.. (unless you already have a branch ready.)
[09:12] <pitti> Daviey: I don't have a branch yet, wanted to wait for the server team's pong before duping work
[09:12] <pitti> (not that it would be much work, but still)
[09:12] <pitti> Daviey: great, thank you
[09:13] <ntr0py> When building a package from an install tree in "debian/dest" with dh_install -a --sourcedir=debian/dest do i need any special treatment for shared object files in /usr/lib/xorg/modules/extensions?
[09:13] <pitti> broder: is that really really a current checkout?
[09:13] <pitti> broder: lp:ubuntu/pkgbinarymangler
[09:13] <pitti> broder: we used to have a different branch in the past
[09:13] <broder> pitti: oh, no, i have lp:pkgbinarymangler
[09:14] <pitti> broder: becuase line 865 is something completely differnt
[09:14] <ntr0py> IM just confused about the shared object not included into my .deb
[09:14] <pitti> broder: ah, then you re-discovered the race condition fixed in 107 :)
[09:15] <broder> pitti: haha, ok. i'll switch to the newer branch then
[09:15] <pitti> broder: let me kill the old branch more properly
[09:15] <broder> much appreciated
[09:15] <pitti> This branch cannot be deleted as it has 5 branches sharing revisions.
[09:15] <pitti> bah
[09:15] <pitti> I'll remove all files in it and just add a README pointing to the new one
[09:15] <broder> can you mark it as...abandoned?
[09:15] <broder> i think that might make it fall off the active list
[09:16] <broder> i guess your approach sounds good too
[09:16] <pitti> did that, too
[09:16] <broder> yeah, that at least keeps it off of https://code.launchpad.net/pkgbinarymangler
[09:16] <pitti> broder: also committed deprecation
[09:17] <pitti> broder: sorry for the confusion
[09:17] <broder> no problem
[09:47] <broder> pitti: err, please disregard that merge proposal. i think i may have off-by-one errors
[10:12] <apw> cjwatson, had any reports of grub getting into a tailspin when installing kernels on oneiric ?
[10:20] <ScottK> pitti: Thanks for taking care of it.
[10:38] <pitti> broder: which one, I've got two now?
[10:41] <pitti> tjaalton: on upgrade I now get a multi-arch conflict on libnspr4 for ./usr/share/lintian/overrides/libnspr4, known?
[10:48] <tjaalton> pitti: hrm.. I'll check
[10:48] <pitti> tjaalton: i. e. you can't currently install libnspr4 and libnspr4:i386 together
[10:49] <tjaalton> pitti: ok, I didn't have 32bit version myself so didn't bump into this. debian was multiarched too but maybe something is missing
[10:49] <pitti> tjaalton: just weird why the lintian overrides should be different on i386 and amd64?
[10:50] <pitti> oh, of course
[10:50] <pitti> file paths
[10:50] <pitti> libnspr4: shlib-without-versioned-soname usr/lib/i386-linux-gnu/libnspr4.so libnspr4.so
[10:50] <pitti> that would be /x86_64-linux-gnu/ on amd64
[10:50] <tjaalton> ah, duh
[10:50] <pitti> so we either need a glob in the override (not sure whether they support that) or drop them, or rename them
[10:51] <tjaalton> well, i don'
[10:51] <tjaalton> uh
[10:52] <tjaalton> i don't mind having lintian warn about the sonames
[10:52] <tjaalton> chrisccoulson: ^
[10:52] <doko> pitti: just add the warning, not the library name
[10:52] <tjaalton> oh that's enough?
[10:53] <doko> yes, but then you won't see other warnings of this type. which probably is fine
[10:53] <tjaalton> indeed, should be fine
[10:53] <doko> for all three libs in this package
[10:58] <broder> pitti: the second proposal is fine. the first one was also, it turns out - i just misunderstood a perl-ism in the code i was copying
[10:59] <pitti> broder: ok, thanks muchly; will review ASAP
[11:02] <tjaalton> pitti: uploaded a fixed nspr, but nss needs a similar fix (debian too)
[11:03] <pitti> tjaalton: cheers
[11:08] <doko> tjaalton, could you file a bug report for lintian, for the expansion stuff?
[11:09] <tjaalton> doko: sure
[11:10] <pitti> broder: looks fine, thanks! merged
[11:11] <pitti> broder: I'll fix something else now for doko, then do an upload
[11:11] <doko> ohh, the -doc png opts? that would help armhf with the whole scientific packages ...
[11:11] <pitti> doko: yes, what we just talked about in /msg
[11:12] <doko> thanks
[11:13] <pitti> doko: so they have arch: any -doc packages? that sounds quite weird
[11:13] <pitti> I'd expect most -doc packages to be arch: all and only built on i386 where it's quite fast
[11:15] <tjaalton> doko: i filed bug 903146, probably should do the same for debian
[11:19] <doko> tjaalton, yeah, having it in debian would be better, I assume
[11:21] <pitti> jamespage: so what was the latest word on the libcegui-mk2-1 NBS stuff?
[11:21] <pitti> jamespage: (about rollback/package dropping/porting)
[11:22] <jamespage> pitt: so; 2 packages; both have non-trivial fixes; bug are/have been raised in debian
[11:22] <jamespage> I also raised bugs in LP for tracking
[11:22] <pitti> jamespage: ok, so we keep the new version then?
[11:23] <jamespage> pitti: for the time being - I suggest that we leave it a few weeks
[11:23] <jamespage> appreciate it clutters NBS a bit
[11:23] <pitti> jamespage: WFM
[11:23] <jamespage> but gives upstream/debian maintainers a change to response
[11:24] <pitti> jamespage: so, libnautilus-extension1a is complete now; need to catch up with wendar about the magic++ FTBFS for libgrib-api-0d-1
[11:24] <pitti> jamespage: I talked to gilir last Friday, he's looking into awn-extras
[11:24] <pitti> jamespage: so that leaves indi, fgfs-atlas, and the poppler stuff to us
[11:24] <jamespage> pitti: I am looking at fgfs-atlas
[11:25] <jamespage> pitti: indi can be dropped now BTW
[11:25] <pitti> jamespage: the Debian poppler maintainer wrote that he has already looked into 0.18 patches and sent them to various upstreams, BTW; so it might make sense to check upstream gits for patches first
[11:25] <pitti> jamespage: oh, NBS just updated
[11:25] <pitti> lp-remove-package.py -u $SUDO_USER -m NBS -b -y indi libnautilus-extension1
[11:25] <pitti> \o/
[11:25] <pitti> (done)
[11:25] <jamespage> pitti: great
[11:26] <pitti> jamespage: I also fixed some more upgrade bugs, so the lts->ubuntu tests now actually seem to succeed
[11:26] <pitti> jamespage: did you see my question about the failed tests in scrollback?
[11:27] <jamespage> pitti: ah - I had not scrolled far enough back
[11:27]  * jamespage reads
[11:27] <pitti> eh, WTH: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[11:27] <pitti> I'll investigate
[11:27] <pitti> nothing changed there, and it's not the new format with build links and apt output
[11:28] <pitti> . o O { wow -- keeping queues to a small number is rather easy -- keeping them at 0 is incredibly much work.. }
[11:29] <jamespage> pitti: 10x the work for the last 1% of issues :-)
[11:29] <pitti> yeah, as always
[11:29] <pitti> quite natural to to the easy stuff first, to get a better overview and throughput
[11:32] <pitti> ScottK, Riddell: koffice-l10n wants to go to universe all of a sudden; did something change there? is that on purpose?
[11:45] <tjaalton> doko: heh, so 2.5.0~rc4 got full support for wildcards :)
[11:46] <pitti> jamespage: hah, better: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[11:46] <pitti> I created more chdists with only the "main" component
[11:46] <pitti> this would also have told us about the kubuntu-full failure some days ago
[11:47] <pitti> ok, fixed the overrides for libindi-data
[11:48] <pitti> should be good in anhour
[11:50] <cjwatson> micahg: reiser4progs> go ahead
[11:51] <cjwatson> micahg: my attempts to upload it got rejected for one reason or another; feel free to figure it out :-)
[11:54] <cjwatson> apw: not that I recall
[11:54] <apw> cjwatson, looking like an osprober issue currently
[11:55] <cjwatson> os-prober usually just exposes somebody else's problems :)
[13:32] <ScottK> pitti: It's probably because of the switch from koffice to calligra packages.  I'd guess it's not on purpose, but Riddell was handling that, so let's wait for him.
[13:33] <Riddell> what what?
[13:34] <akher0n> ScottK: have you seen https://bugs.launchpad.net/pydkim/+bug/901591
[13:35] <ScottK> akher0n: No.  I hadn't (and I'm not sure why as I'm subscribed for bugs like that).  Thanks.
[13:35] <ScottK> Riddell: <pitti> ScottK, Riddell: koffice-l10n wants to go to universe all of a sudden; did something change there? is that on purpose?
[13:49] <Riddell> ScottK, pitti:yeah the seeds changed here, calligra is in New now waiting for an archive admin
[14:02] <smoser> jamesh, ping
[14:11] <pitti> Riddell: ah, so koffice-l10n should be demoted or removed?
[14:14] <Riddell> pitti: it'll be removed but I'd like to test that apt correctly installs calligra first
[14:14] <pitti> Riddell: ok, so I'll keep it in component-mismatches as a reminder
[14:22] <ogra_> argh, Laney owns -changes once again
[14:22] <Laney> muhahaha (and NEW)
[14:22] <ogra_> :)
[15:01] <smoser> jamesh, well, if you see this, see bug 886439
[15:01] <smoser> upgrade of upstart to oneiric -updates causes dirty filesystem on reboot.
[15:03] <stgraber> smoser: something tells me you may want jodh instead :)
[15:04] <doko> mvo, did you break rapt?
[15:05] <mvo> doko: I hope not, what error do you see?
[15:07] <smoser> hm... something tells me you're right stgraber
[15:07] <smoser> what was i thinking.
[15:07] <doko> mvo, sea query
[15:07] <doko> see even
[15:08] <mvo> thx
[15:32] <tkamppeter> pitti, hi
[15:39] <pitti> tkamppeter: hello
[15:42] <tkamppeter> pitti, it is about your message of replacing the python-gobject dependencies by python-gi. This would be the case for system-config-printer. Do I simply need to replace the dependency or are there API changes?
[15:42] <pitti> tkamppeter: no, it doesn't apply there, s-c-printer doesn't use GI but the old static stuff
[15:43] <pitti> tkamppeter: so you don't need to change anything there
[15:57] <tkamppeter> pitti, thanks.
[16:07] <pitti> jibel: mythes-de> argh, another one? I'll fix it ASAP, tahnks
[16:08] <jibel> pitti, yw. I hope it's the last one :)
[16:08] <pitti> jibel: I was quite happy to see that a lot of the upgrade tests actually finish now, and "just" fail in the post-upgrade tests
[16:09] <pitti> jibel: I fixed the freetds one this morning, which broke main-all
[16:09] <pitti> so looking forward to tomorrow's
[16:09] <pitti> jibel: did you see my question from this morning about the failing tests?
[16:09] <jibel> pitti, me too, and they fail with /minor/ bugs
[16:09] <pitti> in particular, the complaints about .dpkg-dist?
[16:09] <jibel> pitti, no, I didn't
[16:10] <jibel> pitti, what was the question ?
[16:10] <pitti> pitti   jibel, jamespage: so https://jenkins.qa.ubuntu.com/view/Precise/job/precise-up
[16:10] <pitti> grade/PROFILE=lts-ubuntu,label=upgrade-test/lastBuild/console -> the upgrade succeeded now, and it rebooted, b
[16:10] <pitti> ut it complains about some extra old conffiles and X not starting?
[16:10] <pitti> pitti   jibel, jamespage: and similarly for lts-server, it just complains about conffi
[16:10] <pitti> les? https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/PROFILE=lts-server,label=upgrade-test/last
[16:10] <pitti> Build/console
[16:10] <pitti> pitti   jibel, jamespage: what does this test do exactly? having .dpkg-dist files is p
[16:10] <pitti> retty normal after an upgrade
[16:10] <pitti> sorry for the broken line endings
[16:11] <pitti> X not starting does sound serious, of course
[16:11] <jibel> pitti, the post-install test check for any .dpkg-dist after upgrade which means there was a debconf prompt during upgrade
[16:11] <pitti> jibel: oh, I see; so these ought to be investigated then
[16:12] <jibel> pitti, I reported 3 bugs this morning about it. There shouldn't be any prompt since the original file was not modified.
[16:12] <pitti> jibel: are they tagged in a particular way, or how can I find them?
[16:12] <jibel> pitti, bug 903131,  bug 903137 and bug 903143
[16:13] <pitti> jibel: ah, they are already rls-mgr-p'ed, great
[16:13] <jibel> pitti, and tagged qa-daily-testing
[16:14] <jibel> pitti, I run main-all and now the upgrade starts but fail with a failure in openoffice
[16:14] <jibel> I'll file a bug for this one as well.
[16:15] <pitti> at least it can figure out the upgrade path now
[16:15] <pitti> jibel: merci
[16:16] <jibel> pitti, talking about upgrades, I found bug 902553 which was fixed with perl 5.14.2-6 but still reported with this version.
[16:18] <pitti> jibel: ok, thanks; putting on my stack of things to look at
[16:51] <pitti> zul: thahnks
[16:51] <pitti> zul: can you also drop python-coverage from keystone's b-deps?
[16:52] <pitti> (see http://people.canonical.com/~ubuntu-archive/component-mismatches.svg)
[16:52] <zul> pitti: yeah its dh_python2 adding them
[16:52] <pitti> zul: no, this is a build dependency for keystone
[16:52] <zul> pitti: ah ok
[16:53] <pitti> seb128: did you sync vte3?
[16:53] <zul> pitti: but yes i can drop it
[16:53] <seb128> pitti, no, mterry was working on that it seems
[16:53] <pitti> mterry: did you sync/upload vte3?
[16:53] <pitti> it conflicts with our vte package, and now the world is broken (http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html)
[16:54] <pitti> so I suppose it should go to main, and replaces the GTK 3 parts of our vte source?
[16:54]  * pitti promotes it
[16:55] <seb128> pitti, there is a mir bug from mterry yes
[16:55] <seb128> not sure why he opened one though, I just read it on the ubuntu-archive list today
[16:55] <pitti> it was mainly the -common package which was missing
[16:55] <pitti> nothing on https://launchpad.net/ubuntu/+source/vte3/+bugs
[16:55] <pitti> but anyway, now we need to change our vte source to drop the -2.90 parts
[16:56] <seb128> pitti, right, the bug was opened before the upload and is on vte
[16:56] <seb128> there was no vte3 source in launchpad yet
[16:56] <seb128> well I'm sure mterry is on it
[16:56] <mterry> pitti, I uploaded a new vte yesterday, still haven't gotten an ACK from the archive
[16:57] <pitti> mterry, seb128: ah, found and closed the MIR bug, thanks
[16:57] <seb128> mterry, your upload probably got rejected for some reason
[16:57] <pitti> mterry: it's inhttps://launchpad.net/ubuntu/+source/vte3/1:0.30.1-2
[16:57] <pitti> imagine a ": " there
[16:57] <mterry> seb128, didn't get a rejection notice...
[16:57] <seb128> mterry, well I mean if you uploaded and it didn't make it in
[16:57] <mterry> pitti, I'm talking about new vte that drops the 2.90 bit
[16:57] <pitti> anyway, need to run, time for Taekwondo
[16:57] <mterry> :)
[16:57] <seb128> mterry, try again just to be sure?
[16:57] <pitti> mterry: ah
[16:57] <mterry> seb128, yar
[16:57] <seb128> pitti, 'night
[16:58] <pitti> anyway, archive should be happier in an hour; I'll check later tonight when I'll be at the TB meeting
[16:58] <pitti> cu later
[16:58] <seb128> mterry_sprinting, oh, sprinting this week?
[16:59] <mterry_sprinting> seb128, yeah, not much time for pure desktop stuff i'm afraid
[16:59] <seb128> mterry_sprinting, have fun I guess ;-) (what is the sprint about?)
[16:59] <mterry_sprinting> seb128, static analysis of unity
[16:59] <seb128> mterry_sprinting, one day we will get you back in desktop, trust me ;-)
[17:00] <mterry_sprinting> :)
[17:00] <mterry_sprinting> seb128, I'm here just to provide help with packaging
[17:00] <seb128> ok ;-)
[17:02] <james_w> pitti, hi, looks like you might have had a bit of a fight with yourself? https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/apvlv/precise-201112121632/+merge/85359
[17:35] <smoser> is ia32-libs-multiarch known broken at the moment?
[17:35] <smoser> (seems broken to me, uninstallable, but is that known ?)
[17:38] <tumbleweed> smoser: https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034279.html
[17:40] <smoser> tumbleweed, i dont think that is relevant.
[17:41] <smoser> unless i'm reading something wrong, i still expect : 'apt-get install ia32-libs-multiarch:i386' to work
[17:42] <tumbleweed> ah, I've just had no expectation of it being usable in precise, so haven't beeen paying attention to it
[17:43] <smoser> tumbleweed, its been close to usable..
[17:43] <smoser> the use case is google+ :-(
[17:45] <tumbleweed> smoser: looks to me like a fair number of its dependencies aren't multi-arched yet, as I expected
[17:45] <smoser> hm.. well up until last week or so, i was functional
[17:45] <ogra_> and you shouldnt need that complex apt line above
[17:46] <ogra_> apt-get install ia32-libs should just DTRT as i read that mail
[17:46] <smoser> yes
[17:46] <smoser> and that has issues :)
[17:47] <ogra_> yeah, help porting the remaining bit sto speed up the fixing ;)
[17:48] <tumbleweed> it's not that far off, by the look of it
[18:01] <slangasek> smoser: that certainly is relevant - ia32-libs-multiarch is broken until all the libs are converted
[18:02] <smoser> slangasek, so how was i getting by previously
[18:03] <slangasek> previously you presumably were not running precise? :)
[18:03] <micahg> cjwatson: re reiser4progs> thanks, will work on it later tonight
[18:03] <slangasek> ia32-libs has not been installable in precise since I sent that mail
[18:04] <tumbleweed> slangasek: I'm impressed how close it is, though. I only spotted two blocking packages in a quick look now
[18:04] <smoser> slangasek, i've been on precise since probably 3 weeks.
[18:04] <smoser> and its been working..
[18:04] <tumbleweed> (but I bet they have dependencies of their own)
[18:04] <slangasek> tumbleweed: there are quite a few more than that, but nothing too unmanagable
[18:04] <slangasek> smoser: then you had the oneiric version of ia32-libs-multiarch:i386 installed
[18:04] <smoser> i'm not sure how.
[18:06] <cjwatson> if you upgraded from oneiric it might still have been there, and then perhaps some upgrade caused it to be removed
[18:17] <micahg> do -meta package updates need to be run on precise now with the new germinate or can we still use oneiric?
[18:33] <jdstrand> @pilot on
[18:33] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[18:33] <jdstrand> @pilot in
[18:40] <apw> slangasek, i think i need to do some poking on this udev thing on the machine which is affected, i have been testing the theory and its not stacking up quite right
[18:41] <apw> slangasek, and i think i am only going to make any progress if i can put some kernels out for test, to find out what udev is really doing
[18:50] <smoser> bug 886439, Sp4rKy
[18:50] <smoser> oops
[18:50] <smoser> SpamapS, ^
[19:13] <SpamapS> smoser: how do I boot a halted instance from euca tools?
[19:13] <smoser> start-instances
[19:14] <smoser> euca-start-instances (should work). thats a new command to euca (long time in ec2-start-intsances)
[19:14] <SpamapS> smoser: I think this is caused by /var/run being a symlink somehow
[19:15] <SpamapS> Or even more sinister actually
[19:15] <SpamapS> looks like /var/run is *removed* and unmounted before this point
[19:15] <SpamapS> DOH
[19:15] <smoser> or /run gets mounted
[19:15] <smoser> yeah
[19:15] <smoser> :)
[19:17] <SpamapS> Hah yeah, RIGHT before
[19:17] <SpamapS> as part of the transition/upgrade process
[19:17] <SpamapS> fix, I think, is to move the check for it right before we torch the whole thing
[19:18] <SpamapS> http://paste.ubuntu.com/768202/
[19:19] <SpamapS> smoser: ^^ happens just before we check the contents of /var/run ... WHOOPS
[19:19] <SpamapS> trouble with that
[19:19] <SpamapS> -d returns true on a *symlink* to a directory
[19:20] <SpamapS> so we're clearing out /var/run even when we don't need to
[19:21] <stgraber> sounds like we want "[ -d /var/run ] && [ ! -L /var/run ]" then
[19:21] <stgraber> or actually the other way around if we want to optimize it a bit
[19:22] <SpamapS> Not sure yet
[19:22] <SpamapS> More importantly, we have to check for things inside this dir before deleting all the contents. ;)
[19:27] <SpamapS> yeah, simply re-ordering the operation works flawlessly
[19:31] <slangasek> SpamapS: where is that code from?
[19:31] <SpamapS> slangasek: umountroot
[19:31] <SpamapS> slangasek: right before the check for init.upgraded
[19:31] <slangasek> SpamapS: oh, hah
[19:31] <smoser> SpamapS, [ -d symlink-to-directory ] && echo yes
[19:31] <smoser> will echo yes
[19:32] <smoser> $ rm -f foo ; ln -s /etc foo && [ -d foo ] && echo yes || echo no
[19:32] <smoser> yes
[19:32] <slangasek> SpamapS: yes, we should both check that it's not a symlink there, and check for the sentinel file *before* removing it ;)
[19:33] <smoser> so i dont see why you'd test if it was a link, or why you'd care.
[19:34] <slangasek> smoser: because this code is here *solely* to migrate it *to* a symlink
[19:34] <slangasek> if it's already a symlink, there's nothing to migrate
[19:34] <slangasek> actually
[19:34] <slangasek> no, because we immediately recreate it with the same target
[19:35] <slangasek> so we don't need to check for it being a symlink, but we *do* need to check the sentinel first
[19:35] <slangasek> since in the upgrade case, rm -rf /var/run isn't removing a symlink, but real contents
[19:36] <ajmitch> SpamapS: are you still considering php 5.4 for precise?
[19:36] <SpamapS> slangasek: yeah, just moving the sentinel block before all those checks fixes bug 886439
[19:36]  * slangasek nods
[19:36] <SpamapS> ajmitch: I'm almost convinced it won't be ready in time.
[19:37] <ajmitch> SpamapS: given that they're still releasing RCs, I'd tend to agree
[19:37]  * ajmitch has RC3 built in a PPA now to test
[19:37] <SpamapS> ajmitch: been watching the churn on the ML.. regular bugs.. but still.. not ready I think.
[19:38] <ajmitch> it'll be a typical .0 release then
[19:45] <SpamapS> slangasek: Ok, so I was thinking I'd upload the "wait for stop/killed" change and this change to precise together. Any objections, or do you want to hold off on the stop/killed change a bit longer?
[19:46] <slangasek> SpamapS: did you happen to catch my comment on here about thinking stop/killed pids should also be included in omitpids, so we don't kill the processes twice?
[19:46] <slangasek> it may not be worth it because every process has a sensible signal handler that copes with multiple -HUP... but then again...
[19:46] <SpamapS> slangasek: I didn't, but that does make a lot of sense.
[19:47] <slangasek> SpamapS: do you think it's worth doing?  I'm not sure it should block the upload anyway
[19:47] <SpamapS> slangasek: I think its worth doing yes... we *know* it has already been killed.
[19:48] <slangasek> ok
[19:48] <SpamapS> slangasek: and its fairly easy
[19:48] <SpamapS> slangasek: I'll update the MP
[19:48] <slangasek> ok
[19:54] <SpamapS> slangasek: is there any issue with using grep -E in initscripts ?
[19:55] <slangasek> SpamapS: nope
[19:55] <SpamapS> alright sweet then its really easy
[19:57] <SpamapS> slangasek: one thought, though I don't think this is really important.. with the way it is now, the processes keep getting killed over and over during those 10 seconds ..
[19:57] <SpamapS> slangasek: whereas upstart just kills once, then waits for kill timeout
[19:57] <slangasek> hmm, really?  that seems buggy
[19:58] <slangasek> there's certainly no good reason to re-kill processes while waiting for the timeout
[19:58] <slangasek> OTOH, it may be prohibitive to track which processes have already been killed and which haven't, for the general case... since there may be new pids being started during that window
[19:58] <slangasek> and we need to make sure we kill them all
[19:58] <SpamapS> exactly
[19:58] <SpamapS> I think upstart just does this more elegantly
[20:47] <pitti> james_w: fight with myself> yes, and I won :)
[20:48] <james_w> good for you :-)
[20:48] <pitti> james_w: I started with 3.0 (quilt), then noticed that the source already had inline changes, but only at the final step of building the source; then I gave up and just built it the classic way
[20:48] <pitti> james_w: I rejected the MP
[20:48] <cjwatson> micahg: oneiric is fine; germinate 2.x shouldn't change the behaviour of germinate-update-metapackage, even though the code has changed around a fair bit for other reasons
[20:49] <micahg> ok, thanks
[20:49]  * pitti groans at http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -- so much damage in 4 hours :(
[20:49] <james_w> pitti, thanks
[20:53] <pitti> ok, cleared up some problems, most of the rest is just buildd lag
[21:15] <soren> What's the name of that gui tool that lets you enable a whole bunch of graphics logging?
[21:17] <slangasek> pitti: heh, right - odbcinst1debian2 Breaks: libiodbc2 is going to render kubuntu uninstallable until soprano gets fixed
[21:19] <micahg> soren: xdiagnose
[21:19] <micahg> soren: that was meant to be a question :)
[21:20] <soren> micahg: Excellent. Yes, thanks. :)
[21:20] <pitti> slangasek: oh, argh; so I guess I need to revert that breaks for the time being? I figure the packages aren't similar enough to warrant a Provides:
[21:20] <slangasek> they most certainly are not, they're libraries
[21:20] <slangasek> so yeah, revert is better
[21:21] <slangasek> pitti: ^^
[21:21] <pitti> slangasek: curiously enough, soprano isn't even on precise_probs
[21:22] <JLuc> hello
[21:25] <JLuc> On scribus, on ubuntu, texts in hint bubbles over buttons have white fonts on white background. It seems to be ubuntu's fault. Any chance it to be corrected soon ?
[21:31] <slangasek> pitti: it'll be some set of packages that are seeded together, rather than a direct conflict, fwiw
[21:33] <slangasek> pitti: and seemingly only on kubuntu dvd, also
[21:33] <psusi> if package C is only useful if both package A and package B are installed, there's no way to get package C to be recommended if you choose to install both A and B is there?
[21:35] <tumbleweed> no
[21:37] <psusi> blast
[22:26] <jdstrand> @pilot out
[22:35] <lardman> any tips on debugging upstart problems? I had a load of unconfigured packages in my ARM chroot image, but it would boot to a login prompt, but since fixing that and running "dpkg --configure -a" it stalls and never gets to a login
[22:41] <beuno> does anyone know where the announcement for keeping Precise stable throught the release cycle went to?
[22:42]  * beuno stares at pitti 
[22:44] <slangasek> lardman: I don't quite understand what you mean; you can't exactly boot a chroot.  Was this a chroot you were using to prepare a disk for booting?
[22:44]  * beuno assumes http://www.piware.de/2011/11/12-04-testing-ftw/ is enough
[22:44] <broder> beuno: i don't know that there was an announcement of the plan. if you give me a sec i can probalby find the uds blueprint
[22:45] <beuno> thanks broder
[22:45]  * beuno is blogging to encourage more people to upgrade to Precise _today_
[22:45] <broder> beuno: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-always-works-daily-iso is the blueprint but doesn't actually seem to have been updated post-uds
[22:46] <broder> http://pad.ubuntu.com/uds-p-foundations-p-always-works-daily-iso is the notes from the session
[22:46] <broder> there's also https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[22:49] <beuno> broder, sweet, thank you
[22:49] <broder> np
[23:10] <SpamapS> slangasek: just pushed up an update to https://code.launchpad.net/~clint-fewbar/ubuntu/precise/sysvinit/wait-for-long-shutdown-jobs/+merge/85208 that fixes bug #886439 .. pretty straight forward, and tested on oneiric.. testing on precise now...
[23:12]  * doko curses Laney or haskell builds even failing on i386 ;p
[23:12] <doko> even for
[23:12] <Laney> heh
[23:12] <Laney> it all comes out in the wash
[23:14] <micahg> Laney: is there any hope for haskell on non-x86 archs?
[23:14] <Laney> it at least works somewhat
[23:15] <ScottK> slangasek: It looks like boost-defaults making 1.48 default may land in Testing before autosync ends.  We ought to think about if we want to try to transition to 1.48 as default or not.
[23:15] <Laney> nobody really does porting upstream though
[23:15] <doko> so you already did give up for haskell on ix86 archs? ;-P
[23:15] <Laney> no, that is just best effort as per upstream
[23:16] <ScottK> slangasek: I don't have time to drive a boost transition, so I thought I'd mention it to someone before it was too late.
[23:17] <doko> Laney, there are a few "key" packages which are just build for x86. can't these ported, or is it just missing?
[23:18] <doko> ScottK, did it even start in debian?
[23:18] <ScottK> doko: No, but there was a warning it's coming sent to debian-devel.
[23:19] <micahg> doko: http://lists.debian.org/debian-devel/2011/12/msg00281.html
[23:19] <ScottK> There's certainly a benefit to using the newer boost, but it's hard to say how hard a transition it'll be.
[23:19] <doko> like db5.2
[23:19] <ScottK> Since boost-defaults is sync'ed from Debian, we'll get it if it makes it to Testing unless we stop it.
[23:20] <micahg> you could add it to the sync-blacklist to block it
[23:20] <ScottK> One could.
[23:20] <doko> how many packages do use explicit boost versions?
[23:20] <ScottK> Mentioning it is as far as I've got time.  "someone" should decide what the best course is.
[23:21] <ScottK> Most of the ones in Main I think.
[23:21] <ScottK> All the KDE ones do.
[23:21] <ScottK> My theory being switching boost versions isn't something you want to do by accident.
[23:22] <micahg> doko: the last transition was ~270 packages
[23:22] <micahg> http://people.canonical.com/~ubuntu-archive/transitions/boost1.46.html
[23:23] <doko> well, most of these use the boost defaults
[23:34] <Laney> doko: the main thing that is missing is template haskell, that impacts a serious number of packages
[23:36] <Laney> well, the interpreter too and data parallel haskell, and performance improvements
[23:36] <Laney> there's been some work done implementing the ghc calling convention in llvm for armel though, so maybe that will enable a registerised build there
[23:37]  * Laney has to go, night
[23:37] <doko> still curious why packages like haskell-src-exts ftbfs
[23:37] <doko> but succeed on i386
[23:39] <Laney> that's the timeout isn't it? not sure about that particular one. perhaps someone could do a manual verbose build and see what happens
[23:39] <doko> no, memory exhausted. still waiting for the kernel mmap bug being fix to recheck this one ...
[23:39] <doko> apw, ^^^ \o/
[23:40] <doko> apw, before Christmas?
[23:42] <lardman> slangasek: sorry for the slow response, yeah a chroot used for setup to be booted on a Galaxy Tab