[00:00] <slangasek> (and has to, because /etc/init/networking always races /etc/init/network-interface)
[00:01] <stgraber> ok, so the problem is the second interface trying to join the bond before it's done being brought up by the ifup triggered by the first interface (when both eth0 and eth1 appear at the exact same time)
[00:08] <slangasek> stgraber: yeah, that's probably one of the problems, at least
[00:15] <haakon_n> So do all new packages in Debian get automatically attempted to be added to universe in ubuntu, or do they need to be requested to be synced? It was a little foggy on the matter on the ubuntu wiki.
[00:17] <tumbleweed> haakon_n: They don't need to be requested, but they do need manual review by the archive-admins. If they are lagging on the review, or it's urgent, they can be poked, or a sync can be requsted.
[00:18] <haakon_n> so they do automatically get reviewed just from being in debian?
[00:18] <tumbleweed> if they make it to testing (because it's an LTS, so we are syncing from testing), yes
[00:18] <haakon_n> get to be reviewd, that is
[00:18] <haakon_n> ok
[00:19] <haakon_n> So is there a public page where you can follow the current state of pending packages, etc?
[00:21] <tumbleweed> No, unless it's been synced by a developer, in which case it shows up in the NEW queue
[00:21] <haakon_n> ok :)
[00:26] <slangasek> pitti: why did udev move to /lib/udev?
[00:39] <slangasek> stgraber: so now that I've isolated a udev upgrade bug here (udevd not actually running), I do get udev events when bond0 is brought up
[00:39] <slangasek> s/brought up/created/
[00:41] <stgraber> slangasek: ok, so I guess we could do 'echo +bond0 > /sys/class/net/bonding_masters' which should create the bond and trigger udev
[00:44] <slangasek> stgraber: yep
[00:54] <SpamapS> slangasek: I'm putting forth a plan to drop mysql 5.1 entirely as soon as we've transitioned to libmysqlclient18 entirely.. do I need to even bother uploading a new mysql-5.1 that does not build libmysqlclient-dev (and the other bits) ?
[01:00] <slangasek> SpamapS: I wouldn't bother unless you think you're going to need to upload it in the meantime for other reasons
[01:00] <slangasek> the package would simply not be uploadable without that change, which isn't a major problem if you're not uploading it :)
[01:00] <SpamapS> slangasek: right, thats what I was thinking. I've got a branch with it on deck if the need arrises.
[01:02] <stgraber> slangasek: so current plan sounds like: http://paste.ubuntu.com/738823/
[01:03] <stgraber> slangasek: should be doable with only limited changes to the current scripts so we don't divert too much from Debian
[01:04] <slangasek> stgraber: "wait for" - that implies polling...
[01:04] <slangasek> if you have to poll, you might as well just call ifup instead
[01:05] <slangasek> but you might be able to have the slave added from the pre-up master when triggered?
[01:07] <stgraber> well, I'd have to call ifup + poll anyway as in my tests, the second NIC comes up before ifup is done loading the kernel module and preparing bond0
[01:07] <stgraber> I'd rather not have a different code path for the first interface and for the second, trying to keep things simple :)
[01:13] <slangasek> stgraber: wouldn't both slaves end up waiting for ifup in that case?
[01:15] <stgraber> slangasek: yes, whichever gets to the ifup part first actually starts it (the second one will just fail doing so), then they both wait for /sys/class/net/bond0 to appear and then add themselves to the list of slaves (that part shouldn't be racy, so it's fine having both doing it at the same time)
[01:15] <slangasek> ah, I didn't think it would fail, I thought it would wait for the lock
[01:15] <slangasek> you've tested this?
[01:17] <stgraber> I'm getting a:
[01:17] <stgraber> ifup: interface br0 already configured
[01:17] <stgraber> (tested with a bridge instead of bond because I'm on my laptop :))
[01:17] <stgraber> that's while another ifup br0 is running waiting for 10s (sleep in the pre-up script)
[01:19] <slangasek> stgraber: ah, that's pretty conclusive then :)
[02:30] <hallyn> SpamapS, so to fix my bad upload of libvirt that ftbfs for lucid-proposed;  should i push fix with incremented version # ?  Or can I just as well push with same version # since it failed to build anyway?
[02:31] <slangasek> hallyn: new version number needed, launchpad already knows about that source version
[02:36] <hallyn> slangasek, thanks
[02:37] <hallyn> slangasek, one more q though :)
[02:37] <slangasek> shoot
[02:37] <hallyn> does that mean that I should do -v<version-2> ?
[02:37] <hallyn> so that if/when it goes to -updates, launchpad catches the '(LP: #xxxxxx)' from the previous commit msg?
[02:37] <slangasek> hallyn: preferably, yes
[02:37] <hallyn> cool, thanks
[05:19] <pitti> good morning
[05:20] <pitti> cjwatson: haskell-dummy> whoa, I'll have a look at that one
[05:23] <pitti> cjwatson: rather, it should just operate on the current binary, as it's called through dpkg-deb; there used to be a reason why it does that double interation, though
[05:23] <pitti> slangasek: I'm not sure, upstream decision; but I figure they wanted to have the daemon out of $PATH
[05:24] <slangasek> pitti: upstreams frequently get the FHS wrong; I would suggest we put it back in sbin
[05:24] <slangasek> (udev upstream in particular is clue-impaired where the FHS is concerned ;)
[05:25] <slangasek> pitti: I noticed this because of bug #889226, fwiw
[05:25] <pitti> oh, does it say that daemons should be in $PATH?
[05:26] <slangasek> pitti: sbin is "system binaries", which certainly covers udev
[05:27] <pitti> so, I don't mind much where it lives; we can just revert the commit that changed the path and change the .install
[05:27] <pitti> but AFAICS bug 889226 needs to be fixed anyway
[05:27] <slangasek> agreed on both counts
[05:28] <pitti> okay, will do today
[05:28] <slangasek> pitti: ok, cheers :)
[06:16] <broder> can i get an archive admin to run the backport-helper script? we've had a bunch of pending backports for a little while now
[06:59] <pitti> slangasek: I'm not actually sure why Keybuk added "restart udev || true", i. e. whether it was expected to fail sometimes; but I guess it really shouldn't fail
[07:00] <pitti> and why it's using --no-start with dh_installinit
[07:00] <slangasek> pitti: probably to work around the behavior when trying to call 'restart' in a chroot
[07:00] <slangasek> (but this is the wrong solution; chroots that shouldn't have services started inside of them should have a policy-rc.d, or a diversion)
[07:01] <pitti> *nod*
[07:02] <pitti> slangasek: so invoke-rc.d is still the right thing to call, despite it's verbose "this is not the script you are looking for" warning?
[07:02] <slangasek> that warning isn't from invoke-rc.d itself, and yes it is the right thing to call :)
[07:03] <slangasek> (the warning is from /lib/upstart-job, and is explicitly suppressed when called from maintainer scripts)
[07:03] <slangasek> /lib/init/upstart-job, even
[07:05] <pitti> slangasek: something like http://paste.ubuntu.com/738960/ ?
[07:05] <slangasek> pitti: no
[07:05] <slangasek> lose the conditional
[07:05] <slangasek> invoke-rc.d is always present, and is always the right interface
[07:05] <pitti> . o O { checking for -x invoke-rc.d really seems antique, but is still common pracice in Debian }
[07:06] <pitti> slangasek: okay (also, s/rsync/udev/ of course)
[07:06] <slangasek> heh, right :)
[07:07] <slangasek> as for it being common practice in Debian, I'm pretty sure I chased that out of policy and debhelper a little while ago ;
[07:07] <slangasek> )
[07:07] <slangasek> yeah, February of this year, Debian bug #610340
[07:07] <slangasek> :)
[07:07] <pitti> ah, so the existing scripts like rsync's just haven't been rebuilt since then
[07:08] <pitti> slangasek: thanks; building/testing now, will upload in a bit
[07:09] <slangasek> pitti: yay, thanks :)
[08:02] <dholbach> good morning
[09:12] <pitti> cjwatson: I filed the "too many iterations" part as bug 890595
[09:17] <pitti> and the FTBFS part as bug 890596
[09:17] <pitti> Laney: ^ FYI, if you got spammed with the haskell-dummy FTBFS log; I'll fix this in pkgbinarymangler and retry
[09:26] <cjwatson> pitti: I started out saying "it should just operate on the current binary" but I assumed that it was operating on all of them because it wanted to produce a single tarball
[09:27] <pitti> cjwatson: right, it should merge them together if it already exists; it already does that with the _translations_static.tar.gz stuff
[09:27] <cjwatson> ok, if you think that'd be reasonably performant :)
[09:27] <pitti> but anyway, it's producing a lot of output, but that's not what's breaking the build, and if the translations tarball already exists it doesn't do much
[09:27] <pitti> (that's why I set it as "low")
[09:45] <brendand> anyone know how to make python look in a particular location for a module before looking in /usr/lib/python2.x/dist-packages ?
[09:45] <cjwatson> sys.path.insert(0, ...)
[09:47] <brendand> ah, yeah - i saw that somewhere before. thanks
[09:47] <nigelb> Alternatively, try virtualenv if the package is available in PyPI.
[09:49] <pitti> brendand: or call the program with $PYTHONPATH if it's temporary and you don't want to modify the source
[09:50] <cjwatson> Although I'm currently converting a package from using private modules to using public modules, because it's more useful that way.
[09:50] <brendand> pitti - so if a module is on the PYTHONPATH it should be taken from there first?
[09:50] <pitti> yes
[09:51] <pitti> brendand: cjwatson's suggestion is the right one if you want to use private modules in your project
[09:51] <pitti> $PYTHONPATH is right if you want to test somethign with a local version of a system module
[09:52] <pitti> I often do things like "PYTHONPATH=. ./gtk/apport-gtk" to test the apport modules from trunk
[09:53] <brendand> pitti - my problem is solved now. but it seemed like my script was using the system version of lazr.restfulclient even though i had a local version in the PYTHONPATH.
[09:54] <brendand> which i thought was strange
[10:00] <Laney> pitti: ah, hadn't noticed — actually, how can I subscribe to build failure notifications? I only know how to get bug mail.
[10:01] <pitti> Laney: usually it mails the uploader and the Maintainer:, but perhaps not for Debian syncs
[10:01] <Laney> maintainer will be the team
[10:01] <Laney> (and I've never seen a mail like that for a sync, indeed)
[10:05] <cjwatson> there's a bug about that I think
[10:05] <Laney> or even a manual upload (to the maintainer), I don't think?
[10:05] <Laney> I suppose the lists swallow them though
[10:07] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/876594 is basically the same
[10:07] <cjwatson> I definitely get notifications for failed builds that I've uploaded ordinarily
[10:08] <Laney> as /uploader/, yes
[10:08] <Laney> but I do not think I have ever seen anything as Maintainer except from MoM
[10:08] <cjwatson> generally it's complicated by the need to avoid spamming Debian developers with Ubuntu build failures
[10:09] <Laney> right, it is probably the right thing to do. I was after a way to explicitly subscribe to build failures :-)
[12:10] <pitti> cjwatson: argh, xubuntu failed to build, sorry about that; I'll fix the seeds to drop gnome-codec-installer (same like ubuntu)
[12:11] <pitti> cjwatson: oh, seems you beat me to it, thanks
[12:12] <cjwatson> pitti: yep, already done, also ubuntustudio
[13:38] <jcastro> slangasek: do you have old-powertop in a PPA somewhere?
[13:52] <cjwatson> perl busted on amd64, my fault, I'm working on it as top priority
[14:45] <kirkland> mvo: ping
[14:47] <mvo> kirkland: pong
[14:48] <kirkland> mvo: howdy!  mtaylor just noticed a really nasty new behavior with apt-add-repository
[14:48] <Daviey> bug 890708
[14:48] <kirkland> mvo: it appears to always require an interactive confirmation
[14:48] <kirkland> mvo: it's breaking all automated scripts and utilities that test from a PPA
[14:49] <Daviey> it seems that -y isn't silently ignored pre-oneiric.
[14:49] <kirkland> mvo: is this just a benign regression, or some new behavior we're going to have to work around?
[14:50] <mvo> kirkland: hm, so it does check is sys.stdin.isatty() - in what env do the scripts run?
[14:51] <mvo> Daviey: indeed, the fact that the old scripts do not have it is pretty nasty
[14:52] <kirkland> mvo: well that depends... juju runs in a tty env, i think :-(
[14:52] <mordred_> kirkland: hey. I'm here
[14:53] <kirkland> mtaylor-xchat: howdy :-)
[14:53] <kirkland> mtaylor-xchat: what env did you notice this in?  juju?  or something else?
[14:53]  * mtaylor-xchat punches smuxi
[14:53] <Daviey> mvo: I think the following should be expected to work:
[14:53] <Daviey> #!/bin/sh
[14:53] <Daviey> add-apt-repository ppa:davewalker/ifupdown
[14:53] <Daviey> :)
[14:53] <mtaylor-xchat> yes
[14:53] <mtaylor-xchat> that's kindof how I noticed it.
[14:53] <mtaylor-xchat> for instance:
[14:53] <mtaylor-xchat> http://www.yorba.org/shotwell/install/
[14:54] <mtaylor-xchat> shows how to get the latest shotwell
[14:54] <mtaylor-xchat> if you cut and paste those commands as a sequence, it won't work (ok, bad example - there are $'s there) ... I could find another example though
[14:55] <mvo> mtaylor-xchat: well, I think its fine that it asks you in a interactive scenario, we do want to ensure that people have a vague idea what they are adding and that they thing about it. I do agree that in a script env this is bad though
[14:56] <mtaylor-xchat> mvo: it's the script env I'm most concerned about, tbh
[14:56] <mtaylor-xchat> mtaylor-xchat: but I personally find the interactive prompt quite intrusive and would love a systemic config way to disable it
[14:57] <mtaylor-xchat> wow. I'm bad with tab completion :)
[14:57] <mtaylor-xchat> mvo: I'm open to and will be happy with anything that solves Daviey's use-case above though :)
[14:57] <Daviey> mvo: I suggested perhaps have an env variable to have the old behaviour?
[14:58] <mvo> ok, let me think about it for a second, if a env var works fine, then I'm happy to add it
[14:59] <mtaylor-xchat> mvo: I could live with env var ... I'd personally LOVE something in a config file that could be driven by debconf questions so it could be preseeded
[15:00] <mtaylor-xchat> mvo: and would be happy to help do some of that work if we could get it landed in updates
[15:02] <hallyn> hm, help2man is unintallable on (my) precise (schroot) because of perl-base version mismatches?
[15:02] <hallyn>  liblocale-gettext-perl : PreDepends: perl-base (>= 5.14.2-3) but 5.12.4-6 is to be installed
[15:04] <cjwatson> hallyn: yes, working on it
[15:04] <cjwatson> I tried to avoid this but got something wrong
[15:04] <hallyn> cjwatson, cool, thanks.  just making sure i didn't mess something up
[15:04] <cjwatson> I bet you're on amd64?
[15:04] <hallyn> yup
[15:04] <hallyn> woudl it work on i386?
[15:04] <cjwatson> yes
[15:05] <hallyn> cool, that might tide me over, thanks
[15:05] <cjwatson> although some other things might break, it's a big transition and it wasn't practical to stage it all
[15:05] <cjwatson> precise/amd64 will be very broken for about the next hour
[15:07] <hallyn> cjwatson, thanks for the info
[15:18] <mvo> mtaylor-xchat: http://bazaar.launchpad.net/~ubuntu-core-dev/software-properties/oneiric/revision/729 <- this is what I can offer right away, let me ponder a bit about Daviey example, it would be ideal if the a-a-r would detect that its run inside a script
[15:19] <Daviey> mvo: hah, linaro are disucssing the same issue right now, bug 886209
[15:28] <mtaylor-xchat> mvo: awesome
[15:30] <mvo> Daviey: :/ but their </dev/null seems to be a good workaround, I'm a bit anoyed that there is no better way to detect if run from a script or not, in shell I could (ab)use $- I guess, but not from within the a-a-r context
[15:31] <Daviey> mvo: Well the mtaylor-xchat use-case is using the same script on pre-oneiric and oneiric, and it seems adding -y breaks pre-Oneiric
[15:34] <mvo> Daviey: yeah, so the force environment or < /dev/null will both fix the problem. I'm sorry for the trouble this change is causing, we did it because it seems like the recommended way in a lot of blogs and we want people to be aware what its doing
[15:35] <stgraber> slangasek, Daviey: Updated patch for ifenslave, works great on my system here: http://paste.ubuntu.com/739257/
[15:35] <Daviey> mvo: Oh, don't be sorry - i thought it was a logical change.
[15:35] <stgraber> so that should work even if some slaves don't come up or come up really late in the boot sequence
[15:35] <stgraber> it also properly removes the bond interface when running ifdown (for some reason the older code didn't do that at all, basically leaving unused interfaces...)
[15:36] <Daviey> stgraber: More stuff had to be migrated to the function fired earlier?
[15:37] <Daviey> stgraber: TREllis would be happy to validate an SRU for Oneiric btw.
[15:37] <stgraber> Daviey: nope, I actually moved a big chunk of code to a function that's called after enslavement
[15:37] <Daviey> oh!
[15:38] <stgraber> the old code expected all the slaves to be ready before setting up the master, we can't guarantee that with our event based system
[15:38] <stgraber> so instead I moved that code to a function that's fired every time we add a slave
[15:38] <stgraber> also, there was a race condition where slaves would be added before all the sysctl were done running on the master
[15:39] <stgraber> caused by ifupdown not tracking "starting to configure" and "done configuring" separately
[15:39] <stgraber> so I had to add a /run/network/ifenslave.* file for each bond, that I can check before trying to add a slave
[15:39] <stgraber> (that "race condition" was basically happening every time I was booting my server here, with the kernel deciding to just block all the trafic on the bond :))
[15:40] <Daviey> stgraber: Is that a local server, or the one you were on yesterday?
[15:40] <stgraber> local server
[15:40] <stgraber> DELL 750 (dual intel gigabit) and a cisco switch with a 802.3ad setup
[15:42] <stgraber> I'll just wait for slangasek to have a look and test in his VM setup (using some non-802.3ad bonding), if that works there too, I'll push to precise first, then look into SRUing for >= lucid (anything that uses the event-based interface setup jobs)
[15:42] <Daviey> groovy
[15:43] <stgraber> I was hoping ifstate would actually save the state of the interface, but apparently it's just storing the interface name as soon as it's done anything
[15:43] <stgraber> so I had to implement an ugly "touch" to track when it's actually done configuring the interface...
[16:04] <slangasek> jcastro: old-powertop is in a precise somewhere; powertop-1.13
[16:04] <jcastro> ta
[16:04] <mterry> Riddell, heyo.  Would you mind processing precise NEW a bit?  trying to fix some FTBFS that are waiting on packages (notably libbison-dev and python-scikits.statsmodels)
[16:13] <jelmer> slangasek: hi
[16:14] <slangasek> jelmer: heya
[16:14] <jelmer> slangasek: I was wondering if you'd seen my comment on bug 890529 ?
[16:14] <slangasek> jelmer: hmm, I replied, didn't I?
[16:14] <slangasek> jelmer: it's an issue with the repository perms
[16:14] <slangasek> so we just don't get a very friendly error message when that happens
[16:14] <jelmer> slangasek: you adjusted the importance to low, but didn't reply to my comment with a traceback
[16:15] <jelmer> slangasek: which is what I'm after mostly :)
[16:15] <slangasek> jelmer: oh, well, I can provide the traceback if you still need that, I just thought "server perms screwed" would be sufficient :)
[16:17] <jelmer> slangasek: if you can, that would be useful. I'm curious about the code path - we should already be handling permission dnied errors
[16:20] <slangasek> jelmer: no traceback now, just an error message - posted to the bug
[16:23] <jelmer> slangasek: thanks
[16:30] <stgraber> slangasek: did you have a chance to look at the diff I posted earlier?
[16:32] <slangasek> stgraber: not yet, sorry
[16:32] <slangasek> it's still pre-coffee-AM here :)
[16:33] <stgraber> hehe
[16:35] <slangasek> mr_pouit: have you seen the xubuntu build failures?  sessioninstaller now conflicts/replaces/provides gnome-codec-install, so gnome-codec-install will need unseeded
[16:37] <smoser> http://paste.ubuntu.com/739317/ build failure make sense to anyone ?
[16:40] <smoser> hm.. i guess we need a newer libc6  maybe for perl-base which provides perlapi.
[16:42] <cjwatson> smoser: that should be fixed once the archive mirrors
[16:42] <cjwatson> smoser: don't worry about the build failures, I'll fix them all up in bulk
[16:42] <cjwatson> slangasek,mr_pouit: I fixed that this morning
[16:42] <cjwatson> oh, not a live-build failure I won't ...
[16:42] <smoser> cjwatson, no problem. just wanted to let someone know if it was the first report.
[16:42] <smoser> it'll get sorted out once you sort out packages.
[16:42] <cjwatson> smoser: we're in the middle of the perl transition, see ubuntu-devel.  I'll let you know once it's a bit further along for you
[16:43] <smoser> cjwatson, nightly will just keep trying and succeed at some point
[16:43] <smoser> :)
[16:43] <cjwatson> we don't need a newer libc6, that was my screwup while staging the first step of the transition
[16:44] <mr_pouit> cjwatson: yep, I saw the change, thanks :)
[16:52] <pitti> ah, seems packages gradually get installable again, thanks cjwatson
[16:52]  * pitti re-retries pkgbinarymangler
[16:57] <stokachu> has anyone seen this type of error when attempting to build a deb package? http://dpaste.com/656897/
[16:57] <infinity> stokachu: See the file it points you to.
[16:58] <stokachu> on reporting the bug?
[16:59] <stokachu> infinity, ^
[16:59] <infinity> stokachu: Yes.
[16:59] <stokachu> ok i did that and it's not a common error with gcc
[17:00] <infinity> stokachu: Unless you feel the urge to diagnose and fix the segfault yourself, in which case, thanks. ;)
[17:00] <stokachu> not exactly , didnt know if anyone has run into this issue before
[17:01] <infinity> stokachu: "this issue" is a segfault in the compiler.  There are many.
[17:01] <stokachu> ok so no you haven't run into this issue
[17:01] <stokachu> thanks
[17:01] <infinity> stokachu: On the other hand, you're using gcc-4.4, it may well be fixed in 4.6.
[17:02] <stokachu> im building for 10.04
[17:02] <infinity> stokachu: I run into GCC ICEs all the time.  I don't know if I've seen yours. :P
[17:02] <infinity> stokachu: What you can do to perhaps work around your specific issue is try different optimisation levels (-O1 or -O0, assuming you were building with -O2 before)
[17:03] <stokachu> ok ill try that
[17:05] <mterry> wgrant, hello!  do you know where the source for the ftbfs page is?
[17:05] <stokachu> vanhoof, im staring through your window, put some pants back on
[17:12] <cjwatson> pitti: yeah, making decent progress now
[17:15] <mterry> bdmurray, can you look at bug 459730?  i just had a user bug me about it
[17:17] <bdmurray> mterry: yes
[17:17] <mterry> bdmurray, thanks!
[17:20] <smoser> mterry, does someone actually want xconsole entry ?
[17:20] <smoser> or are they just annoyed at the warning
[17:21] <mterry> smoser, they seem to actually want it?
[17:21] <seb128> speaking about rsyslog: https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/841085
[17:21] <seb128> if anyone feels like working on that ;-)
[17:21] <mterry> seb128, if it builds, I don't care about it this month  ;)
[17:22] <mterry> seb128, find a way to break the build such that I'd have to display the logs to fix it
[17:22] <seb128> mterry, I can break the build for you if that helps :p
[17:22] <seb128> ok
[17:22] <seb128> mterry, yes sir! ;-)
[17:22] <mterry> seb128, this team isn't having the effect we'd hoped  ;)
[17:22] <seb128> hehe
[17:22] <seb128> mterry, you exercice other people creativity toward bug fixing, that's good as well ;-)
[17:23] <seb128> mterry, I've a new theory "given time any bug can be turned into a build issue", I need to verify if it's true ;-)
[17:24] <mterry> hehe
[17:24] <vanhoof> stokachu: :)
[17:25] <gmargo> I've noticed a problem on the packages.ubuntu.com site.  Someone on #ubuntu-website suggested I ask here.  The problem is that package descriptions are not provided for the Oneiric (or Precise) packages.  For instance, compare http://packages.ubuntu.com/oneiric/coreutils against http://packages.ubuntu.com/natty/coreutils and the omission is immediately obvious.
[17:26] <slangasek> gmargo: yes, this is because we now ship package descriptions in separate files on the server; please see the contact link on packages.ubuntu.com
[17:27] <slangasek> (I don't know if this has been reported to the maintainer of that site yet at all; I know the issue is being discussed for packages.debian.org)
[17:29] <gmargo> I have tried to contact frank@lichtenheld.de (listed address on packages.ubuntu.com) a few weeks back but no reply.  And I don't know about packaging the descriptions - it just simply doesn't make any sense to _not_ describe a package on that package's page.
[17:31] <slangasek> gmargo: yes, it's a bug not by design
[17:31] <slangasek> contact> good to know; let me see what I can figure out
[17:34] <dobey> is the perl brokenness in P fixed up now?
[17:35] <slangasek> dobey: it's going to take some time before it's fully fixed, because it's a rolling rebuild
[17:35] <slangasek> it's fixed to the point that the autobuilders can continue making progress, at least
[17:36] <dobey> slangasek: ok; i uploaded an ubuntuone-client this morning, apparently right as it broke, and it failed to build. was wondering if i could tell it to rebuild, but i don't see how to do that on LP
[17:36] <micahg> there's also the ubuntu-build utility in ubuntu-dev-tools
[17:36] <slangasek> I presume there'll be a mass-giveback for packages having ftbfs during the critical window, but let me have a look
[17:37] <slangasek> micahg: what's that?
[17:37] <micahg> you can give back builds with it
[17:37] <slangasek> micahg: presumably only if you also have access to do so from the website, dunno if dobey has that and if that's why he's not seeing the button
[17:37] <micahg> well, it should work as long as you can upload it
[17:37] <micahg> if it doesn't, that's a bug
[17:38] <slangasek> dobey: intltool is known to still be broken AIUI
[17:38] <micahg> same for th eretry button
[17:38] <micahg> *retry
[17:38] <dobey> slangasek: ah, ok
[17:38] <slangasek> though I've entirely lost the reference to this
[17:38] <dobey> micahg: i don't have the retry button; i also have issues with edit buttons not appearing next to upstream series links on packages
[17:38] <slangasek> ah no, found now
[17:38] <slangasek> dobey: you don't have the retry button here? https://launchpad.net/ubuntu/+source/ubuntuone-client/2.0.0-0ubuntu3/+build/2927706
[17:39] <slangasek> dobey: but you do have upload rights?
[17:39] <dobey> yes
[17:39] <slangasek> dobey: bug in launchpad, please file
[17:39] <dobey> oh
[17:39] <dobey> on each arch there is a retry button
[17:39] <slangasek> ah, yes :)
[17:40] <micahg> right, since each arch is a separate build
[17:40] <dobey> there isn't one to rebuild on all archs though :(
[17:40] <micahg> dobey: ubuntu-build from ubuntu-dev-tools :)
[17:40] <dobey> micahg: ok, i'll try that
[17:40] <dobey> but i guess i still have to wait for intltool to be fixed
[17:40] <slangasek> dobey: oh, it looks like intltool is fixed now after all, so I think you should go ahead and give them back for building
[17:40] <dobey> oh ok
[17:41] <slangasek> (tested in a chroot, apt says I can install intltool+perl; that cjwatson works fast)
[17:42] <slangasek> ok, so what bloated my /usr by 200MB in the last week in precise?
[17:42] <slangasek> probably something that's not good for the CDs
[17:43] <dobey> you didn't install the webkit debug lib did you? :)
[17:43] <slangasek> pitti: ^^ do you happen to know of any major package size increases?  I did see some printing-related package upgrades in the run that ate the space
[17:44] <slangasek> cups, ghostscript, PPD updates
[17:45] <slangasek> dobey: webkit debug> heh, certainly not
[18:21] <dobey> yay, u1client built
[18:24] <dobey> slangasek: can you accept ubuntuone-client into oneiric-proposed? :)
[18:28] <cjwatson> dobey: I will be doing mass-retries once I get far enough, yes
[18:29] <dobey> cjwatson: ubuntuone-client is built successfully in precise now. i already retried it. but thanks, and thanks for fixing the breakage :)
[18:33] <slangasek> dobey: looking
[18:34] <slangasek> dobey: no, not possible, you need a different version number for the upload to oneiric-proposed than was used for precise; rejecting instead
[18:34] <dobey> slangasek: oh really?
[18:34] <slangasek> dobey: please reupload as ubuntuone-client 2.0.0-0ubuntu2.1
[18:34] <slangasek> yes, each upload accepted into the archive has to have a unique version number
[18:34] <dobey> bugger. ok, 2.1 it is
[18:36] <dobey> slangasek: 2.1 uploaded
[18:36] <slangasek> ok
[18:39] <slangasek> bryceh, doko: surely someone else can reproduce bug #863761 without me having to use my primary laptop for it? ;)  From what I can see, it should be reproducible on any system with a sufficiently recent processor and an intel graphics chip
[18:43] <SpamapS> slangasek: so, I was looking at but 440179 .. and thinking that there is a simple solutoin.
[18:43] <SpamapS> solution even
[18:44] <slangasek> SpamapS: if we want the semantics of 'service $foo restart' to be the same as 'invoke-rc.d $foo restart' wrt job start/stop, I'm ok with that
[18:45] <slangasek> though it seems low priority to me, since 'service' is a user interface rather than a programmatic one
[18:45] <SpamapS> slangasek: I think that would help quiet a lot of the "WTF" we see from automated systems.
[18:45] <slangasek> and users can well do "service $foo stop; service $foo start"
[18:45] <SpamapS> slangasek: that was going to be my next question. Should we be making 'invoke-rc.d' the recommended automation tool?
[18:46] <SpamapS> slangasek: many users seem unsatisfied with the "just use stop ; start" answer.
[18:46] <SpamapS> which has been my default as well
[18:46] <slangasek> there are times when invoke-rc.d should be used and times that it shouldn't
[18:46] <SpamapS> so
[18:46] <SpamapS> we need to have one place to recommend that an automated system use
[18:46] <SpamapS> /etc/init.d/xxx was that place before
[18:47] <slangasek> I think you need to clarify what you mean by "automated system"
[18:47] <slangasek> maintainer scripts are automated; they must use invoke-rc.d
[18:47] <SpamapS> puppet, chef, cfengine, my wonky bash scripts
[18:47] <juliank> AFAIK; invoke-rc.d blocks scripts from being run in the chroot, the others don't
[18:47] <slangasek> /etc/logrotate.d is automated, and must not use invoke-rc.d
[18:47] <slangasek> juliank: invoke-rc.d doesn't block chroot execution unless you've set it up to do so
[18:48] <juliank> slangasek: Yes, you can set it up like this. You can't do the same for the rest, right?
[18:48] <slangasek> standard chroot setup should involve creating /usr/sbin/policy-rc.d that returns 101, and diverting initctl and start-stop-daemon
[18:48] <slangasek> there's no reason you can't reroute all of these interfaces
[18:48] <SpamapS> can we ignore chroots for now?
[18:48] <slangasek> but in general there's nothing running in your chroot that will try to use any of them besides invoke-rc.d *anyway*, so that's sufficient
[18:49] <slangasek> SpamapS: definitely
[18:49] <SpamapS> There was a time where puppet could reliably expect that a service named "foo" would be controlled only by /etc/init.d/foo
[18:49] <juliank> slangasek: With "can" I mean in normal cases. You can obviously do it, but that's not the expected way to do it.
[18:50] <slangasek> yes it is ;)
[18:50] <SpamapS> And in turn, that /etc/init.d/foo restart would lead to a service that had just been started (whether by stop/start or by just failing to stop, then starting)
[18:50] <SpamapS> That is still true for anything carrying the /etc/init.d/foo symlink to upstart-job
[18:50] <slangasek> others expectations may be flawed in various ways, but if you expect services to be guaranteed not to start in your chroot, you should touch all three of those points
[18:51] <SpamapS> I had hoped that the service command would be suitable as a place to focus all future service control around.. automated or user-driven.
[18:51] <SpamapS> With the exception of maintainer scripts which are special.
[18:51] <slangasek> SpamapS: I think it's right to make /etc/init.d an implementation detail and move this up to the 'service' abstraction
[18:52] <slangasek> SpamapS: so please go ahead :)
[18:52] <SpamapS> alright, cool. :)
[18:52] <SpamapS> I think I'll do some man page tweaking too.
[18:52] <SpamapS>        service runs a System V init script in as predictable environment as possible, removing most envi‐
[18:52] <SpamapS> thats not exactly true. :)
[18:55] <stokachu> how does a deb package build without placing any files in the packages even though they were defined in their respective install files?
[18:55] <SpamapS> slangasek: assuming we'll skip the merges with Debian for now since they're all related to kfreebsd?
[18:55] <stokachu> so it sees the files or it would've errored saying so
[18:57] <mterry> doko, mind if I grab ocaml merge?
[19:06] <bryceh> slangasek, I'll give it a try once I get a couple of my intel systems on precise.  got a few other things to take care of first
[19:17] <slangasek> SpamapS: merges of what? sysvinit?
[19:17] <slangasek> SpamapS: I'm deferring sysvinit merges until I finish my own NMU of it (upstart support in Debian)
[19:17] <slangasek> SpamapS: you're still on point for the lvm merge, right?
[19:17] <slangasek> bryceh: ok, no hurry from my side :)
[19:29] <SpamapS> slangasek: yes, still assigned. :)
[19:31] <slangasek> SpamapS: ok.  I'm sitting on my hands, but would really like a version of lvm that doesn't complain about /proc/misc on every invocation :)
[19:35] <SpamapS> slangasek: I'll push the lvm merge up a bit on the stack then. :)
[19:35] <slangasek> ta :)
[20:31] <apw> cjwatson, pitti, it seems that some of our kernel binaries are in universe again, at least 2.6.38-13.52 for amd64 and i386
[20:37] <slangasek> apw: should all the binaries from that version (all flavors, all archs) go to main?
[20:37] <slangasek> if you don't know, I can work it out
[20:38] <apw> slangasek, from linux yes all are the same currently
[20:38] <slangasek> apw: fixing
[20:39] <apw> slangasek, i am a little confused as i thought rmadison listed /universe aginst things in the wrong place, yet they are in the wrong place in the pool
[20:39] <slangasek> apw: I can't speak to rmadison's behavior here
[20:41] <cjwatson> rmadison will reflect what's in dists/
[20:41] <cjwatson> (by definition; that's its data source)
[20:41] <apw> slangasek, i suspect this error may be systemic as 2.6.35-31.62 also seem to be over in universe in the pool
[20:42] <cjwatson> pool/ may contain symlinks between components so you shouldn't treat it as authoritative for this purpose)
[20:42] <cjwatson> it is systemic, it's a problem with copying out of PPAs
[20:42] <cjwatson> somebody has to override them into main afterwards :-/
[20:42]  * micahg thought there was a kernel helper for publishing
[20:43] <apw> cjwatson, i thought that the helper did that now, clearly not
[20:43] <apw> looks like 2.6.32-36.79 has fallen in there too
[20:43] <apw> and 2.6.24-30.96
[20:44] <apw> no scratch that i think 2.6.24 is ok, as we do have odd ones in there
[20:45] <apw> bah now i am unsure, i think 2.6.24-30.96 may be wrong for the generics at least, but there are some which belong there
[20:50]  * slangasek also wishes we had better cleanup of stale binary packages from -proposed
[20:51] <slangasek> cjwatson: shall I get those other versions as well?
[20:51] <slangasek> micahg: the kernel helper for publishing set the overrides when we used to send them through the unapproved queue - I don't think we have a new helper that handles the ppa copying
[20:51] <cjwatson> slangasek: please
[20:52] <micahg> slangasek: ah, I thought pitti had something for that
[20:52] <slangasek> well, maybe he does
[20:52] <slangasek> hasn't been shared with me :)
[20:53] <micahg> slangasek: copy-proposed-kernel.py in ubuntu-archive-tools
[20:53] <slangasek> micahg: I don't see anything in that script that fixes the component
[20:53] <micahg> ah, ok
[20:53] <Randolph> hi all
[20:54] <slangasek> Randolph: hello
[20:59]  * SpamapS takes the plunge and upgrades "the big laptop" to precise
[20:59] <broder> slangasek: if you're archive-admining at the moment, can i try harassing you again to run the backport-helper script in ubuntu-archive-tools?
[20:59] <broder> (it's been about 2 weeks since somebody ran it last, based on the outstanding requests)
[20:59] <slangasek> broder: sorry, I briefly took a look at that last night and found the interface entirely bewildering
[20:59] <slangasek> I've never seen this program before and can't say my first interaction with it has been pleasant
[20:59] <micahg> SpamapS: you might want to wait until the perl transition is finished (close to finished)
[20:59] <broder> slangasek: hmm, ok. i wrote it to match the interface of sync-helper
[21:00] <slangasek> what's sync-helper? :P
[21:00] <broder> i see :)
[21:01]  * slangasek has another look
[21:01] <broder> as i understand it, backport-helper writes out a file of instructions which you then pass to...mass-sync.py, maybe?
[21:01] <slangasek> ah
[21:01] <slangasek> I've never used sync-helper, I just run mass-sync manually
[21:01] <slangasek> I vaguely recall someone mentioning they were writing a wrapper and also vaguely recall being put off by the interface ;)
[21:02] <cjwatson> sync-helper is fasntastic
[21:02] <cjwatson> *fantastic
[21:02] <slangasek> fântastic
[21:02] <cjwatson> maybe the UI is a personal thing
[21:02] <broder> slangasek: i'd be happy to implement whatever interface would make it more likely to get run, if you tell me what such an interface would look like :)
[21:02] <cjwatson> SpamapS: yeah, I would wait 'til tomorrow, sorry, this is a slightly rough day
[21:03] <cjwatson> I know it's supposed to work at all times, my powers of archive persuasion slightly failed me today
[21:03] <broder> slangasek: alternatively, if you'd like, i can run backport-helper and tell you what you need to pass to mass-syncs
[21:03] <slangasek> broder: well, I run the command and the first thing it shows me is http://paste.ubuntu.com/739628/
[21:04] <slangasek> which seems to give me 8 options and no guidance
[21:04] <slangasek> broder: you running it and feeding me commands sounds more likely to result in a favorable outcome :)
[21:04] <broder> hmm...ok. yeah, that does seem confusing
[21:05] <broder> the intent is that, because backport requests don't have anything resembling a standardized form, the script has to rely on heuristics to figure out things like package names and such - this is an opportunity to fix when the heuristics go wrong
[21:05] <broder> of course, since i know what the heuristics are, i always make sure to form the requests in such a way that they will pass :)
[21:05] <cjwatson> so you hit 's', read the report, use the options to fix up anything that's wrong, hit 'b' to emit backport instruction
[21:06] <cjwatson> it writes out a file that you pass to mass-sync.py
[21:06] <broder> it does look like you have a slightly out of date copy of the script - i know cjwatson added rmadison output that's not in your paste
[21:06] <cjwatson> it automates the "oh my god I have to open 73 firefox tabs and then close all the bugs manually" bit
[21:06]  * slangasek bzrpulls
[21:06] <cjwatson> also broder fixed the bad handling of hyphens in package names
[21:06] <broder> and full stops
[21:06] <broder> both of which are relevant for the current queue
[21:07] <broder> the bit in parens is the information that will actually be used in the instructions; i guess that's also not very clear
[21:08] <slangasek> ah, so 'activity' shows that I'm using the buggy version :)
[21:08] <broder> yeah
[21:08] <cjwatson> yep
[21:09] <slangasek> and does the helper automatically only look at bugs in the correct state indicating the backports team has approved the backport?
[21:09] <broder> yes. it actually goes one step further and requires that a member of the backports team be responsible for it being in the correct state
[21:10] <slangasek> nice
[21:11] <slangasek> ok, backport-helper success
[21:11] <slangasek> and mass-sync fail
[21:11] <slangasek> debugging
[21:11] <broder> oh, crud. i bet you're hitting the issue with multiple backports of the same source package
[21:12] <slangasek> doesn't look like it
[21:12] <slangasek> http://paste.ubuntu.com/739641/
[21:12] <slangasek> running into the error on a package with only one backport
[21:13]  * broder blinks
[21:16] <broder> ah. that happens if the url is None
[21:16] <slangasek> yes
[21:16] <slangasek> trying to work out why it's none :)
[21:16] <broder> ...which means that sp.changesFileUrl() didn't return anything
[21:18] <slangasek> could it be an adverse interaction between the new syncing stuff and the backporting?
[21:20] <slangasek> the API resource in question is https://api.launchpad.net/1.0/ubuntu/+archive/primary/+sourcepub/2026865
[21:20] <broder> that seems likely
[21:21] <slangasek> https://launchpad.net/ubuntu/precise/+source/activity-log-manager/0.8.0-1 states "No changes file available"
[21:21] <broder> and that looks like a syncpackage'd sync
[21:21] <slangasek> yes
[21:21] <slangasek> so I'll skip that one for now
[21:21] <broder> let me see if i can adjust the backport script to not rely on the changes file, because i don't think we need to anymore
[21:21] <slangasek> broder: yes please :)
[21:21] <broder> especially since it's just looking for the .dsc - that should be in .sourceFileUrls()
[21:22] <slangasek> apw: lucid,maverick,natty kernels all overridden back to main; hardy sounds like it needs more tweaking?
[21:22] <slangasek> broder: libgdata also affected, skipping
[21:25] <slangasek> *now* I'm hitting the bug with backporting to multiple suites ;)
[21:27] <broder> i don't really understand that bug, only that it exists, but if you can describe it and it's something i can help with, i'm always interested in making the backports process smoother
[21:28] <slangasek> I think it's that the scripts get upset when the .orig.tar.gz it's trying to write to the staging directory on cocoplum already exists
[21:29] <slangasek> so it could be smarter about checking if it's the same file instead of aborting
[21:30] <slangasek> not sure if/where the backend code is published however
[21:30] <broder> it looks like the stuff in u-archive-tools just ssh's to cocoplum and runs /home/lp_archive/bin/sync-backend, so it sounds like that might not be something i can really help with
[21:30] <slangasek> yeah, it's /home/lp_archive/bin/backport-source-backend for the relevant bits here
[21:35] <broder> i think bzr:~broder/ubuntu-archive-tools/backpoirt-without-changes-file should fix the syncpackage issue
[21:36] <bdrung> broder: backpoirt?
[21:36] <broder> uh, typo on my part - the branch itself os spelled correctly :)
[21:37] <slangasek> narf poirt
[21:38] <broder> i'm not IRC'ing from my ubuntu dev box at the moment, so i have to re-type everything :-P
[21:39] <slangasek> broder: I assume you also meant lp:~ rather than bzr:~ ?
[21:39] <broder> indeed
[21:43] <SpamapS> cjwatson: heh, no worries, pre-alpha1 I'll be happy if nothing catches on fire. :)
[21:43] <SpamapS> and also, I'm dist-upgrading from a local mirror about 24 hours behind
[21:43] <SpamapS> might have just missed the start of the perl transition
[21:45] <SpamapS> anyway, time for the dentist
[22:00] <bdmurray> If I found 2 debian bug reports that are duplicates what is the process for merging them?
[22:01] <wgrant> mterry: lp:lp-ftbfs-report
[22:04] <slangasek> bdmurray: if you have devscripts installed and the bts command configured, you can do 'bts forcemerge $bug1 $bug2 # these are the same bug because $reason'; or you can manually send the same command, 'forcemerge $bug1 $bug2' to control@bugs.debian.org.
[22:04] <slangasek> broder: backports finished, branch merged
[22:09] <bdmurray> slangasek: thanks what kind of confirmation will I get?
[22:11] <slangasek> bdmurray: email acknowledgement
[22:32] <apw> slangasek, thanks for that, i'll get with pitti et al tommorrow to make sure things are ok
[22:39] <broder> slangasek: thanks. i'll also make a note to try and make the initial UI a bit more friendly and informative
[22:40] <slangasek> broder: well, I'm over it now so maybe that's no longer an issue ;)
[22:41] <broder> yes, but you and colin aren't the only archive admins
[22:43] <slangasek> maybe the others already know how to use it too, dunno
[22:44] <broder> i think this is the first time since i wrote the script that i caught anybody but cjwatson running it
[23:10] <doko> slangasek, well, maybe. I don't have this hardware
[23:11] <doko> mterry, not at all
[23:35] <slangasek> cjwatson: that libdbd-sybase-perl upload will surely ftbfs
[23:36] <slangasek> I have 1.14 staged in bzr, dunno if you want to pull it: bzr+ssh://bzr.debian.org/bzr/users/vorlon/libdbd-sybase-perl/trunk/
[23:43] <cjwatson> slangasek: bulk uploads :)
[23:44] <cjwatson> slangasek: it's not critical path for anything particular, so it can wait until you have it in Debian
[23:55] <slangasek> cjwatson: right-o
[23:59] <SpamapS> slangasek: odd .. doing the lvm2 merge.. tons of conflicts on things that don't appear to be documented changes in the changelog.