[00:02] <kees> infinity: eglibc ping :)
[00:06] <infinity> kees: "I'm not ignoring you, I've just been busy" pong.
[00:06] <infinity> kees: (I also have a few other things lined up for eglibc, so I'm going to make a day of it at some point)
[00:16] <kees> infinity: cool; thanks :)
[01:02] <infinity> ScottK: What's with the ksplosion of kthins moving to universe on component-mismatches?
[01:04] <ScottK> infinity: I'd guess Kubuntu not driving stuff to Main landed.
[01:04] <ScottK> That's in the plan.
[01:04] <ScottK> But that's a guess.
[01:29] <cjwatson> ScottK: I haven't landed that yet.
[01:30] <cjwatson> Hm, it's a fair bit, but I'm not sure it's enough for that.
[01:36] <micahg> cjwatson: any chance components-mismatches suddenly got smart about versions?
[01:37] <cjwatson> You'd see it in lp:ubuntu-archive-tools if it had.
[01:42] <infinity> micahg: "smart about versions"?
[01:43] <micahg> infinity: straw grasping due to low glucose :) (the basic premise is to drop it out of main if the version doesn't satisfy something, but it doesn't make much sense)
[01:48] <infinity> Oh, hallelujah, the armel GCC build finally finished...
[01:48] <infinity> I wonder how that took 13 hours longer than armhf...
[01:57] <ScottK> infinity: Then I'll go with KDE is half 4.8.3 and half 4.8.80 or 90 and stuff is confused.
[01:58] <infinity> ScottK: Yeah, that's possible.  I'm certainly not knee-jerk demoting anything tonight.
[01:58] <infinity> I know some AAs are a bit more militant about just demoting everything on the list, but hopefully everyone will take pause at the size of the list and not do so. :P
[01:59] <infinity> Cause it's annoying to have to promote half of it the next day...
[02:19] <micahg> BenC: did you test scilab on i386?
[02:19] <BenC> I did, but I don't think it rebuilt configure like it was supposed to
[02:20] <micahg> ah, ok, I was waiting for the diff, but saw the failure first
[02:20] <BenC> scilab was FTBFS on everything !amd64 already, so it's def not a regression :)
[02:21] <micahg> right :), but that's the same thing that happened when the last person sync'd :)
[02:21] <BenC> I'll refix it
[02:21] <micahg> BenC: thanks
[02:22]  * infinity fixes calligra...
[02:22] <infinity> Mostly because it's annoying me that it's blowing up quantal_probs...
[03:00] <BenC> I wonder if anything else can brag about 3Gigs of installed size for it's build-deps
[03:00]  * BenC tips his hat to sdcc
[03:05] <StevenK> BenC: Libreoffice? :-)
[03:06] <mwhudson> that did seem the obvious suggestion
[03:06] <StevenK> Build-Depends: all of main. At once.
[03:07] <BenC> byte of source to byte of build-dep, I suspect sdcc wins this one though :)
[03:45] <infinity> BenC: Making build-indep only get run as a dependency of binary-indep means it all happens under (fake)root.
[03:45] <infinity> BenC: Not a huge issue, I suppose, since we use fakeroot and not real root, but not ideal.
[03:45] <BenC> infinity: Hence the reason I said, "not ideal"
[03:46] <BenC> But it was a toss up of "force the buildd's to install 3Gig of build-deps" or "generate docs as (fake)root on i386 only"
[03:47] <BenC> I may be biased in that I didn't want the ppc buildd's to install all those damn build-deps :)
[03:47] <infinity> There's a theory some day that dpkg-buildpackage -B will eventually change to call "clean ; build-foo ; binary-foo", but that's going to require a critical mass of packages in the archive actually supporting separate build-{arch,indep} targets. :/
[03:48] <infinity> Since suddenly making half the world RC buggy is unpleasant.
[03:48] <BenC> I was under the impression that this was already the case…it's really odd to me that I don't remember this class of FTBFS being a major issue until now
[03:49] <infinity> -B has always done "build ; binary-arch"
[03:49] <BenC> At least, all the packages I create have "build: build-arch build-indep" :)
[03:49] <infinity> And -b does "build ; binary"
[03:49] <BenC> All these years, Build-Depends-Indep was just tease
[03:50] <infinity> This class of FTBFS almost never shows up in Debian because arch:all packages are built on maintainer machines, so no one ever bothers to test if they fail when built in a pristine environment.
[03:50] <BenC> That's the thing, this is causing failures when not building with arch: all as a target
[03:50] <infinity> Oh, hah.
[03:50] <BenC> I would have thought it would show up in Debian too
[03:50] <infinity> Yeah, that also is a uniquely Debian build failure. ;)
[03:51] <infinity> Because, again, it will work for the maintainer.
[03:51] <infinity> And he'll ignore the buildds failing, cause hey, his works.
[03:51] <BenC> Right, so the maintainer will keep saying "but it's under build-indep"
[03:51] <BenC> Damn social problems
[03:52] <infinity> Actually, hrm.  Debian may have switched.
[03:52]  * infinity wonders if his pending dpkg merge will change this...
[03:52]  * infinity sees a "debian/rules build-arch" in a Debian build log.
[03:53] <BenC> Does Debian install Build-Depends-Indep on all builds?
[03:53] <infinity> BenC: If you're running into more of these, you might want to hold off for a bit.
[03:53] <infinity> BenC: No, BDI is never installed on Debian buildds (since none of them build arch:all)
[03:53] <infinity> BenC: But if you check the logs for sdcc on sid, they show a call to build-arch.
[03:53] <BenC> infinity: Unfortunately, most of the ones I've seen are causing a slew of dep-wait and other FTBFS, so the cascade of fixing it does makes me impatient :)
[03:53] <infinity> BenC: So maybe this changed VERY recently in dpkd.
[03:54] <infinity> dpkg*
[03:54] <infinity> BenC: Well, I'm merging dpkg tomorrow.  Let me look right now to see if this behaviour will be changed by that.
[03:54] <BenC> Ok
[03:54] <micahg> \o/ new dpkg will solve a few more depwaits :)
[03:55] <BenC> I don't know of any others right now, but if I see any, I'll note them for rebuild later
[03:55] <infinity>   * Update dpkg-buildpackage to use the "build-arch" (for -B) and
[03:55] <infinity>     "build-indep" (for -A) targets unless "make -qn" says that they do not
[03:55] <infinity>     exist. Closes: #229357
[03:55] <infinity> BenC: Yeah, looks like my merge will let you stop doing these fixes.
[03:55] <BenC> Ah, that's great fix
[03:56] <infinity> I like the age of the bug that closed.
[03:56] <infinity> Not 5-digit, but still back a bit.
[03:56] <BenC> 8 year old bugs...
[03:57] <infinity> Hey, this is why I'm against auto-expiry of bugs.  "We'll get to it eventually..."
[03:58] <BenC> I may have still been in the Uploaders list back then
[03:58]  * micahg still loves how powerpc is doing better than i386 ATM
[03:59] <infinity> Give me to the end of the week to resolve that oversight. :P
[04:00] <micahg> a new dpkg and debhelper would probably tip the scales
[04:00] <infinity> Is our dh lagging too?
[04:01] <infinity> That's a much easier merge.
[04:01] <micahg> yes, --extreme or something like that
[04:01] <infinity> dpkg is pain.
[04:01] <BenC> I dunno…if you can dislodge all the ppc dep-waits, I think I can keep up :)
[04:01] <infinity> micahg: No, that's dpkg.
[04:01] <infinity> micahg: That's just passed unfiltered to dpkg-deb.
[04:02] <infinity> BenC: If ross wasn't unhelpfully sitting at a yaboot prompt without a keyboard or serial console attached, PPC might be a bit happier. :/
[04:03] <BenC> No wonder I keep getting "Build will start in 39182913 hours, you tool"
[04:03] <micahg> infinity: hrm, http://packages.debian.org/changelogs/pool/main/d/debhelper/current/changelog#version9.20120513, http://packages.debian.org/changelogs/pool/main/f/fonts-aoyagi-soseki/current/changelog, people seem to be doing this slightly backwards
[04:04] <BenC> infinity: pay someone to walk over to it with a usb keyboard
[04:04] <StevenK> Hah, USB keyboard on a Xserve
[04:05] <BenC> Please tell me it doesn't use an ADB port
[04:05] <micahg> hehe, ADB port, now I'm getting nostalgic
[04:05] <infinity> micahg: Well, merging debhelper too won't hurt.
[04:05] <infinity> micahg: And gets the default udeb compression for free.
[04:05] <BenC> shaweet, scilab built on something != amd64
[04:06] <infinity> BenC: Pretty sure there's no ADB bus on any G5 system. :P
[04:06] <micahg> BenC: awesome, now let's see if sylvestre takes the patch :)
[04:34] <BenC> ccvjbsmt.s:285077: Error: operand out of range (0x0000000000008000 is not between 0xffffffffffff8000 and 0x0000000000007fff)
[04:34] <BenC> My math may be a little rusty, but I suspect that error is incorrect
[04:38] <infinity> BenC: Heh.
[04:38] <BenC> At the same time, I suspect half a million lines of assembly would confuse the best assembler
[05:22] <BenC> Bug #1012976
[05:24] <pitti> Good morning
[05:26] <pitti> slangasek: changelogs.u.c.> functionally that's mvo's, but out of disk is RT matter
[05:30] <pitti> yay for python3-ified aptdaemon!
[05:43] <glatzor> morning pitti and slangasek
[05:43] <pitti> hey glatzor
[05:44] <glatzor> pitti, may I ask you about the status of the aptdaemon/packagekit plugins? They are already available for Python 3?
[05:44] <pitti> glatzor: I'm porting ubuntu-drivers-common as we speak
[05:44] <pitti> glatzor: and language-selector is also on my list today
[05:44] <pitti> glatzor: I don't know about the software-center plugin
[05:44] <glatzor> great news.
[05:44] <pitti> do we have others?
[05:45] <pitti> glatzor: aptdaemon now landed, this blocked pretty much else on my list before :)
[05:45] <glatzor> I am not aware of any further plugins.
[05:45] <glatzor> pitti, I just wrote an email to slangasek that I am ok with an upload :)
[05:45]  * glatzor seems to be late
[05:48] <glatzor> Thanks for the upload slangasek
[06:01] <pitti> glatzor: argh, seems we missed some bits
[06:01] <pitti> /usr/share/aptdaemon/tests/fake-polkitd.py
[06:01] <pitti> #!/usr/bin/env python
[06:01] <pitti> that's causing test failures
[06:03] <pitti> oh, I see that all scripts except gtk3-demo.py stil run with "env python" in trunk
[06:03] <pitti> glatzor: so I guess the package converts those?
[06:03] <glatzor> pitti, hm. but the fake-polkitd should still work if python 2 is installed. have you already remove python2 completely from your disk?
[06:04] <pitti> glatzor: it works fine in my normal system, but u-d-common shows ImportErrors when building in a pbuilder
[06:04] <pitti> glatzor: the pbuilder doesn't have python-dbus, only the python3-dbus build dep
[06:04] <pitti> curiously even the fake polkitd keeps all tests succeeding
[06:05] <pitti> it seems aptdaemon doesn't actually query polkit, or ignores if it's not there
[06:05] <pitti> so I think we can ignore that for now
[06:06] <glatzor> pitti, I used the demo scripts to test the python 2 interaction since at the python 3 port release time update-manager, s-c and friends would still be python 2 based
[06:06] <glatzor> pitti, Hm. I will have a look at the policykit thing
[06:07] <pitti> glatzor: if it becomes a problem, I'll just add (temporarily) a python-dbus build dep
[06:10] <glatzor> pitti, without a working or always denying fake-polkitd the test suites hangs here
[06:11] <pitti> let's see how it behaves on the buildds, but it worked fine in my pbuilder
[06:11] <pitti> glatzor: so perhaps a workaround would be to start the fake polkit like Popen([sys.executable, 'fake-polkit.py', ...], ...) ?
[06:12] <pitti> in aptdaemon.test
[06:12] <pitti> so that it always runs with the same python version as your test
[06:13] <slangasek> pitti: yes, I was asking about the implementation because I think we should be garbage-collecting some of these changelogs... instead of letting them accumulate without limit
[06:14] <glatzor> pitti, I just replaced the shebang in trunk
[06:14] <slangasek> why would we need to keep changelogs around indefinitely?
[06:14]  * slangasek waves to glatzor - you're welcome :)
[06:14] <pitti> glatzor: wouldn't that cause the opposite problem then?
[06:14] <slangasek> glatzor: and thank you for doing all the hard work on the port
[06:15]  * pitti moves python3-xkit to main, to relieve u-d-common from its depwait
[06:15] <pitti> slangasek: changelogs> indeed; they are still on LP for the historians
[06:19] <pitti> cjwatson: I pushed your language-selector py3 branch to lp:~ubuntu-core-dev/ubuntu/quantal/language-selector/python
[06:19] <pitti> cjwatson: so that we can work on it together
[06:25] <micahg> fun, colliding meta uploads :)
[06:27] <pitti> micahg: urgh, did you update it as well? sorry about that
[06:27] <pitti> fun, I've never seen that happen before in 8 years
[06:28] <micahg> pitti: no, but slangasek did after you, I'm surprised how that worked
[06:28] <pitti> I uploaded 1.272, slangasek 1.273
[06:28] <micahg> right, but they're the exact same changelog
[06:28] <pitti> with exactly the same changelog
[06:29] <pitti> slangasek: so it seems we both had exactly the same idea at the same time? so it must be good!
[06:31] <pitti> cjwatson: err, I mean lp:~ubuntu-core-dev/ubuntu/quantal/language-selector/python3
[06:31] <pitti> cjwatson: (i. e. the changed branch name in the blueprint work items is correct)
[06:44] <pitti> cjwatson: now the test suite works with python3 (except test_package_lists_good, which has failed for years; but as this part, just like most of language-selector, is being deprecated, I don't bother much)
[06:53] <dholbach> good morning
[07:00] <pitti> glatzor: when I run language-selector with Python 3, I get
[07:00] <pitti> TypeError: update() takes exactly 2 arguments (1 given)
[07:00] <pitti> Error in function update
[07:01] <pitti> glatzor: is that something that rings a bell to you? it's not something I do in language-selector itself
[07:01] <pitti> /usr/lib/pyshared/python2.7/apt_pkg.so contains "Error in function", anyway
[07:16] <pitti> glatzor: nevermind; apparently apt.progress.base.OpProgress.update() now gets called with one argument sometimes (not in python2); I added support for this and pulse() the progress bar in that case
[07:16] <glatzor> pitti, sorry I was away
[07:17] <glatzor> pitti, right there is now an optional argument
[07:18] <pitti> cjwatson: I tested PYTHONPATH=. python3 ./gnome-language-selector fairly well now, seems to work fine
[07:19] <pitti> cjwatson: so I'll switch the whole thing to #! python3 and merge
[07:36] <verwilst> hm, precise has a 2-year old lvm2 package, i wonder why it hasn't been upgraded for the LTS
[07:52] <pitti> cjwatson: uploaded l-s now; thanks for your porting work!
[08:03] <pitti> gnagh, dear debhelper, stop calling setup.py through "python" explicitly
[08:05] <cjwatson> pitti: wow, that was quick, thanks
[08:05] <cjwatson> pitti: debhelper needs to do that, surely
[08:06] <pitti> cjwatson: yeah, it's nice to have a package that doesn't need millions of bytes-> str conversions for a change :)
[08:06] <cjwatson> I mean, aside from its general lack of python3 support
[08:06] <pitti> cjwatson: yeah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597105 all over again
[08:06] <pitti> I did that for a number of other packages, I'm mostly just grumbling because I keep falling into that trap
[08:06] <cjwatson> but it needs to be called for each supported interpreter, and IIRC it needs to be called with python rather than python2.7 or #! lines come out wrong ...
[08:12] <pitti> cjwatson: btw, you ignore jockey on the py3 sprint, right?
[08:14] <cjwatson> pitti: Yeah
[08:14] <cjwatson> More didn't even consider it because there was so much else ;-)
[08:18] <cjwatson> mvo: Thanks for the command-not-found merge.  Shall I roll a new Ubuntu package?  How do you pick version numbers, as setup.py seems to be out of date?
[08:21] <cjwatson> mvo: And do you by any chance have an opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656288?
[08:21] <xnox> verwilst: we didn't get around to updating lvm2 in time. It is updated in quantal.
[08:21] <pitti> cjwatson: so it seems this is really going well, great! the two biggest things that worry me are ubuntuone and system-config-printer
[08:21] <cjwatson> (Scroll to the end, I think)
[08:21] <pitti> xnox: good morning
[08:21] <xnox> pitti: that's for pushing u-d-c =)
[08:22] <pitti> xnox: thanks for your work there; I mopped up the remaining bits, and uploaded now; I had a quick discussion with glatzor about the "import dbus" failure from the fake polkit, but it doesn't hurt for now
[08:23] <xnox> pitti: yeap, I reread on irclogs.ubuntu.com ;-)
[08:29] <seb128> pitti, is it worth spending time porting system-config-printer if we plan to deprecate it?
[08:29] <seb128> pitti, well, we will still need the service, but the ui part might be not worth spending time on it
[08:30] <pitti> seb128: right, that's what I meant
[08:30] <pitti> we at least need to port the bckend
[08:30] <pitti> seb128: it seems Fedora is going py3 as well, so maybe it even already happened; I don't know
[08:31] <pitti> I wouldn't worry about the frontend, and rather spend the time helping Lars with fixing the GNOME frontend enough
[08:31] <seb128> right
[08:31] <seb128> though I doubt Lars will have any time for that this cycle
[08:31] <seb128> but we will change before the next LTS for sure
[08:33] <pitti> well, if we don't switch this cycle, we'd have to port the GUI to py3 as well, which seems like a waste? I thought the GUI was already very close
[08:34] <pitti> seb128: I thought GNOME upstream's printer panel would already talk to s-c-p, doesn't it?
[08:34] <seb128> pitti, it does
[08:34] <pitti> nice
[08:41] <mvo> cjwatson: I can do a new version but either way is fine, I had hoped that rookery is fixed so that we get updated command-not-found data for quantal with the new release too
[08:46] <doko> didrocks, online?
[08:46] <didrocks> doko: yes
[08:48] <seb128> doko, infinity: do you have an idea if bug #1007588 could be a toolchain issue? not sure what those @plt are, but the code didn't change since precise (out of being rebuilt with the new toolchain) and the segfaults don't happen when building with gcc-4.6
[09:01] <hrw> hi
[09:02] <hrw> can someone tell me how to specify two arches in apt sources.list for one repo? for one arch it is simple: "deb [arch=armel] http://repo" but tried "[arch=amd64,i386]" and it still tries to find armel there
[09:06] <hrw> ok, [arch=amd64 arch=i386] looks like working
[09:10] <hrw> chrisccoulson: do you have plans to provide quantal packages for thunderbird-next ppa?
[09:13] <cjwatson> mvo: I hadn't seen much sign of rapid movement on getting rookery fixed ...
[09:31] <hrw> nope, only solution is duplication of lines ;(
[09:36] <hrw> ogra_: do you know why ddebs.ubuntu.com does not have armel/armhf ddebs for quantal?
[09:39] <doko> mvo, online?
[09:40] <mvo> doko: yes
[10:03] <seb128> doko, hey, did you see my ping before?
[10:03] <seb128> doko, should we just build gnome-settings-daemon with gcc-4.6?
[10:04] <doko> seb128, no, didn't look yet
[10:04] <seb128> doko, let me know if,when you have some time to look at it, that's hitting quite some quantal users
[10:04] <chrisccoulson> seb128, ooh, that bug looks interesting ;)
[10:04] <seb128> chrisccoulson, lol, you like toolchain issues right? ;-)
[10:04] <chrisccoulson> lol
[10:05] <chrisccoulson> "like" is a bit of a strong word ;)
[10:06] <seb128> chrisccoulson, do you want to have a look to it?
[10:06] <chrisccoulson> seb128, sure, i don't mind
[10:06] <seb128> chrisccoulson, thanks!
[10:59] <verwilst> xnox, , i guess an upgrade of lvm2 will never be allowed in precise? :)
[11:04] <xnox> verwilst: i have enquired about that and the conclusion is that no precise will stay at it's current revision as it's too high of a jump and we do not have sufficient regression testing in place to catch unforeseen problems. A backport on the other hand....
[11:04] <Bluefoxicy> buh.  Ejecting the kindle from Ubuntu doesn't make it drop out of USB drive mode and charge while in use
[11:04] <xnox> verwilst: individual bugs, can and should be fixed/lumped together in an SRU
[11:04] <Bluefoxicy> I think because it ejects /dev/sdc1 but not /dev/sdc?
[11:05] <verwilst> xnox, a backport of that one patch the redhat guy mentioned?
[11:05] <Bluefoxicy> that should be looked into
[11:05] <Bluefoxicy> if you hit 'eject' and nothing on that device is mounted after unmounting, eject the base device itself
[11:06] <Bluefoxicy> (I just manually ejected /dev/sdc, kindle data is /dev/sdc1; it worked)
[11:06] <Bluefoxicy> bleh I'll file a bug after work.
[11:06] <xnox> verwilst: the whole thing. Plus quntal is at .88, so it needs to be fixed in quantal. Debian is at .95 so it should/does affect debian as well.
[11:06] <xnox> verwilst: .96 just got released.
[11:07] <verwilst> i guess quantal can just get an upgrade to .96
[11:07] <xnox> Bluefoxicy: unless you want to repartition the drive. or connected to the yellow always on port....
[11:08] <Bluefoxicy> yellow always on port?
[11:08] <Bluefoxicy> xnox:  this could be serious you know :P
[11:09] <Bluefoxicy> what if you're using a (moron-developed) USB hard drive that expects a proper eject command to know to flush cache?
[11:10]  * Bluefoxicy jumping jacks on tatami, then goes to work.
[11:11] <Bluefoxicy> (I'd imagine a well-designed external drive will flush cache as soon as nothing else is going on, and immediately park the heads awaiting power drop, rather than needing commands for all this)
[11:19] <pitti> jibel: I so love the adt tests
[11:20] <pitti> jibel: that upower regression detected an actual bug
[11:29] <scarneiro> exit
[11:29] <scarneiro> exit
[11:36] <jibel> pitti, Great. If only cloning VMs concurrently could be reliable. I'll spend some time on it tomorrow.
[11:42] <Daviey> jibel: How are you currently cloning ?
[11:43] <Daviey> jibel: if you have a consistent base image, and want lots of duplicates.. using qemu to create an image with a 'backing' image might be wise...
[11:44] <jibel> Daviey, with vm-clone from vm-tools which uses kpartx but sometimes it doesn't find the loopback devices
[11:45] <Daviey> jibel: qemu-img create -f qcow2 -b base.img test-runner.img .. might be what you want?
[11:46] <jibel> Daviey, yes but then I must change the config inside the VM hence the use of kpartx
[11:47] <Daviey> jibel: If you can add cloud-init to the image, you can use that 'stanalone' without a metadata service.. it's quite a gentlemanly way of injecting arbitrary code.
[11:47] <Daviey> (create an iso image, which is attached to the machine, and cloud-init reads from there)
[11:48] <Daviey> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/nocloud/README
[11:50] <jibel> Daviey, nice. That looks like a solution. I'll try it. Thanks!
[11:50] <Daviey> super
[12:44] <ogra_> @pilot in
[12:59]  * dholbach hugs ogra_
[12:59] <dholbach> ogra_, lots to choose from :)
[12:59] <ogra_> :)
[13:12] <pitti> seb128: I updated the test case on bug 984944, FYI; it's working for me here
[13:13] <seb128> pitti, thanks, I will give it a try it a bit
[13:13] <pitti> but right now I only tested on quantal
[13:17] <mterry> @pilot in
[13:18]  * dholbach hugs mterry
[13:18] <mterry> ogra_, ah hello!  You're piloting too?  In the interest of avoiding the ones you're looking at, should I look at the bottom or top of the sponsor report?
[13:18] <mterry> dholbach, morning (for me)!
[13:18] <ogra_> mterry, i started in the middle :)
[13:18] <ogra_> (bottom of yellow)
[13:19] <ogra_> planned to work upwards through it
[13:19] <mterry> ogra_, heh, OK.  I'll do some of the newer ones at the bottom then
[13:19] <cjwatson> juliank: Do you have any thoughts on my latest patch sent to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656288 ?  I'd really like to unblock this.
[13:22] <juliank> cjwatson: I'll comment on that later. I have to go now.
[13:52] <ScottK> bryceh: It looks like xdiagnose is getting called to run in python3 now and 'bad' things happen.  See Bug #1013171 .
[13:55] <xnox> ScottK: it has been ported.... during python jam monday->wednesday
[13:55] <xnox> ogra_: ^^^ bug 1013171
[13:55] <ScottK> xnox: Something's gone awry then because those are python print statements in that bug, not python3.
[13:55] <ogra_> xnox, oooh, thanks !
[13:56] <ScottK> xnox: Actually it looks like the update isn't uploaded as the current package is weeks old
[13:56] <ogra_> thats not the ported version
[13:56]  * ScottK isn't sure why it's getting run in python3, but it is.
[13:57] <ogra_> (note that part of the porting is to wrap brackets around all print stanzas)
[13:57] <ScottK> Multiple dupes too.
[13:57] <ScottK> Yep.
[13:58] <ogra_> i'm pretty sure the ported code wasnt merged yet
[13:58] <xnox> ScottK: is update-manager calling that or aptdaemon or something like that?
[13:58] <ScottK> No idea.
[13:59]  * ScottK hasn't been following it until his ubuntu bug mailbox started filling up this morning.
[14:04]  * ogra_ added the branch to the bug and the bug to the changelog ... should be fixed once the merge is uploaded
[14:04] <ogra_> ScottK, ^^^
[14:05] <ScottK> ogra_: Thanks.  It'd be good to get it done since it's hitting multiple people.
[14:05] <ogra_> yeap, bryceh knows about the branch, i guess he will merge and upload asap
[14:25] <ogra_> ogasawara, hmm, just looking at bug 183076 ... seems your fix is upstream since ages and also in all supported releases, how about closing the bug so it drops of the patches list :)
[14:26] <ogasawara> whoa, 2008
[14:26] <ogra_> :)
[14:26] <ogasawara> ogasawara: I'll close it
[14:26] <ogasawara> bah
[14:27] <ogasawara> ogra_: ^^
[14:27] <ogra_> great
[14:27]  * ogra_ giggles
[14:27] <ogasawara> ogra_: now I fully understand how I steal your pings
[14:27] <ogra_> hehe
[14:35] <cjwatson> ScottK,ogra_,pitti: Doesn't the presence of /usr/share/python3/runtime.d/apport.rtupdate suddenly mean that all apport hooks are required to be Python 3-compatible?
[14:36] <cjwatson> xdiagnose is very far from unique.
[14:36] <ScottK> That sounds reasonble.
[14:36] <pitti> cjwatson: by and large, yes
[14:36] <ogra_> oh, indeed
[14:36] <pitti> as the GUI is now running as py3
[14:36] <pitti> s/as/with/
[14:36] <cjwatson> So isn't this going to require about a bazillion Breaks?
[14:37] <hyperair> RAOF: ping
[14:37] <cjwatson> I mean, I understand it, but it'll all need to be exhaustively handled
[14:37] <xnox> emergency porting all apport hooks to python3?
[14:37] <seb128> cjwatson, pitti: change the hooks dir to avoid the breaks?
[14:37] <seb128> it will just reduce the debug infos for a bit
[14:37] <seb128> but at least it will not trigger reports
[14:38] <seb128> like version it "3" or something?
[14:38] <pitti> I don't like changing the hooks dir; it should not be rocket science to fix the few hooks that we have that aren't already workign with py3 anyway to work with both 2 and 3
[14:39] <cjwatson> Few?
[14:39] <cjwatson> http://paste.ubuntu.com/1040874/
[14:39] <cjwatson> A lot of those are symlinks to source_xorg, I guess
[14:40] <seb128> yes, I was going to say
[14:40] <cjwatson> But I do think we'll need the Breaks, otherwise we'll get mid-upgrade reports
[14:40] <cjwatson> And possibly crashes
[14:40] <pitti> right, most of them are symlinks to source_xorg.py; that's the primary one that we need to fix
[14:40] <pitti> crashes/
[14:40] <ogra_> that is fixed
[14:40] <pitti> ?
[14:41] <ogra_> i ported xdiagnose the last days
[14:41] <cjwatson> There're others there though, network-manager, udisks, ...
[14:41] <cjwatson> ogra_: xdiagnose != xorg
[14:41]  * cjwatson fixes ogra_'s lexer to go past the first character :-)
[14:41] <pitti> xdiagnose: /usr/share/apport/package-hooks/source_xorg.py
[14:41] <pitti> I guess ogra meant that?
[14:41] <ogra_> right :)
[14:42] <pitti> python3 /usr/share/apport/package-hooks/source_xorg.py fails, though (print statement)
[14:42] <ogra_> i fought with that file enough the last days ;)
[14:42] <ogra_> pitti, because my port isnt merged yet
[14:42] <pitti> ah
[14:42] <ogra_> i linked it to the bug
[14:43] <ogra_> xdialog just needs the merge and an upload and will be fixed, though i think cjwatson is right being worried about other hooks, we should make a lot of noise to get people moving imho
[14:43] <cjwatson> Huh
[14:44] <cjwatson> ogra_: Fair enough, sorry, failed to run dpkg -S
[14:44] <dholbach> cjwatson, if you could publish the fix that might help in a lot of other cases :-P
[14:44]  * cjwatson fixes his own parser to not suck
[14:45] <cjwatson> There are also some that won't show up in a current grep but that were fixed after precise
[14:45] <cjwatson> For example source_grub2.py is only py3-compatible in quantal, not precise
[14:46] <ogra_> well, but in precise apport doesnt default to py3, does it ?
[14:46] <pitti> ITHM on upgrades
[14:46] <ogra_> ah, k
[14:46] <pitti> i. e. if you upgrade to quantal, and apport gets upgraded before, say, grub2
[14:46] <pitti> then package install failures of grub2 woudln't have the infos from teh package hook
[14:47] <seb128> should we SRU python3 compat fixes for hooks for packages we upload to precise for other reasons?
[14:47] <pitti> fortunately the hook info does not seem all that relevant for package installation failures in most cases
[14:47] <seb128> i.e I wouldn't do a SRU only to fix a hook to be python3 compatible
[14:47] <pitti> most of them are for manual bug reports, and some for crashes
[14:47] <seb128> but we can probably include those in uploads
[14:48] <pitti> grub2 might be the very exception to this, of course
[15:11] <pitti> udisks hook fix uploaded, udisks2 hook fix committed to git
[15:11] <pitti> cjwatson, seb128 ^ FYI
[15:12] <seb128> pitti, thanks
[15:13] <pitti> chrisccoulson: can you please fix python3 /usr/share/apport/package-hooks/source_firefox.py ?
[15:14] <cjwatson> pitti: Maybe apport should just catch SyntaxError in hooks and downgrade that to some kind of warning.
[15:15] <pitti> cjwatson: apport itself never crashes on bad hooks
[15:15] <cjwatson> Oh, but this bug is about running py3compile over the source directory, so that's not applicable.
[15:15] <pitti> it just shows the exception on stderr for debugging and goes on
[15:15] <cjwatson> OK.
[15:15] <pitti> it's external code, I assume the worst :)
[15:17] <xnox> ogra_: thanks for sponsorship! =)
[15:17]  * ogra_ tips his pilot cap 
[15:18] <xnox> ogra_: you didn't mark the whole proposal as merged, but I did now =)
[15:18] <ogra_> oh, sorry
[15:18] <pitti> chrisccoulson: http://paste.ubuntu.com/1040950/ shoudl be the bulk of the fixes, but I'm not quite sure how your ExtensionINIParserIter parser works (it fails there)
[15:19] <chrisccoulson> pitti, i'll have a look in a bit. and this has changed quite a lot recently as well (but it's not in the archive yet)
[15:19] <chrisccoulson> pitti, i also need to maintain compatibility with the current python :)
[15:20] <pitti> chrisccoulson: yes, my pastebin patch works with both
[15:20] <chrisccoulson> ah, ok. thanks!
[15:20] <chrisccoulson> i'll apply it in a bit :)
[15:20] <pitti> chrisccoulson: thanks; NB that it's not sufficient
[15:21] <pitti> chrisccoulson: please use http://paste.ubuntu.com/1040952/ rather, debug output looks nicer with that
[15:21] <chrisccoulson> pitti, sure, thanks
[15:27] <zul> bdmurray: ping
[15:29] <bdmurray> zul: hi, done sprinting and looking at the queue now
[15:29] <zul> bdmurray: thanks
[15:40] <stokachu> stgraber: hi, could you take a look at http://pad.lv/951343 for possible sponsorship
[15:50] <hallyn> lool: slangasek: hey, I want to test whether qemu-common from a newly merged (not yet pushed) qemu-kvm-1.1 would break qemu-linaro.  is there a testsuite i can use?
[15:51] <slangasek> hallyn: not to my knowledge
[15:52] <xnox> slangasek: I remember you mention that lvm .88  was the 'recommended' version of lvm to use
[15:52] <xnox> debian is now on .95, and upstream released .96
[15:53] <slangasek> xnox: at the time, .88 was /a/ version that upstream had blessed for use; but things have moved on since then
[15:53] <hallyn> slangasek: is there some small .img i can wget and use under qemu-arm as a test?
[15:53] <xnox> are there stability criteria for lvm.
[15:53] <xnox> slangasek: hmm. ok
[15:53] <dobey> stgraber, pitti: want to moderate my reply mail to technical-board through? :)
[15:53] <slangasek> hallyn: I don't know one offhand, sorry
[15:53] <hallyn> slangasek: ok, thanks.
[15:54] <slangasek> hallyn: I mean, between Linaro and Ubuntu there should be several... but if you're meaning to test qemu-system, you need an image for a supported subarch, which is probably only beagle at this point
[15:55] <hallyn> perhaps the thing to do is drop by #linaro and ask if anyone cares to test with a version in my ppa :)
[15:55] <hallyn> thanks
[16:09] <stgraber> dobey: don't have moderation rights, sorry.
[16:09] <stgraber> cjwatson: ^
[16:10] <cjwatson> uh, why not
[16:10] <dobey> oh. thanks
[16:10] <cjwatson> stgraber: you have /msg
[16:13] <lool> hallyn: I dont know a testsuite either; you can create QEMU images from Linaro images with linaro-image-tools
[16:13] <stgraber> dobey: done
[16:14] <hallyn> stgraber: all of the removal of apparmor policies for lxc was meant to NOT be done in lxc.postrm anymore right?
[16:15] <hallyn> lool: ok will try, thanks (saw a few urls describing that)
[16:32] <alexbligh1> What would be the easiest way of automatically building Lucid & Precise installation media with the security updates already applied?
[16:33] <alexbligh1> (specifically amd64 server)
[16:35] <hallyn> lool: seemed to boot up fine.  Terminal worked.  Terminal on vnc connection didn't seem to accept input, but mirrored the other output.  (don't know if that's normal)
[16:37] <ogra_> @pilot out
[16:48] <SpamapS> Hrm.. shouldn't we have an 'update-vcs' the same way we have 'update-maintainer' ?
[16:51] <ScottK> First we should have a policy decision on if we want to replace Debian VCS info or just add Ubuntu info too.
[16:52] <SpamapS> ScottK: right, like the XFOO-Original-Maintainer
[16:52] <ScottK> Yes.
[16:52] <SpamapS> having screwed up the apport upload the other day
[16:52] <SpamapS> I want to make sure UDD and Vcs-* play nice :-P
[16:52] <cjwatson> ScottK: I thought we had a policy decision on that years ago.
[16:52]  * cjwatson hunts.
[16:53] <ScottK> Dunno?
[16:53] <cjwatson> Thread starting https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html
[16:54] <cjwatson> Which agreed on XS-Debian-Vcs-*
[16:54] <ScottK> OK.
[16:54] <ScottK> That's about two months after I started doing Ubuntu development, so no wonder I don't remember.
[16:55] <SpamapS> slangasek: Hey I'm going to fix bug 794082 and do the cron merge (you are TIL) ok?
[16:57] <xnox> cjwatson: does the archive consistently override that? or is it manual job?
[16:57] <xnox> cjwatson: update-maintainer should probably do that, unless it points to launchpad with *ubuntu* somewhere in the url
[16:59] <cjwatson> xnox: Binary packages are consistently overridden.  Sources are only overridden if we've changed them.
[16:59] <cjwatson> (XSBC-Original-Maintainer, that is.
[16:59] <cjwatson> )
[17:00] <cjwatson> We don't override Vcs-* at all at the moment.  I'm not clear whether we should or could.
[17:00] <xnox> hmmm =/
[17:00] <cjwatson> Not actually massively wild about more hacks to override bits of Sources, TBH
[17:00] <cjwatson> If we don't have to
[17:00] <xnox> =)
[17:01] <xnox> yeah, you'd think that you could do a blancket lp:ubuntu/package..... if all of them were realibly up to date, and used by all teams
[17:01]  * xnox grumbles something unintelligent
[17:02] <SpamapS> cjwatson: the only reason I think we might want to is that its now impossible to actually know where the Vcs is in Ubuntu... one must check Vcs-*, and lp:ubuntu/foo
[17:12] <ScottK> SpamapS: If there's an Ubuntu Vcs-* then you know.
[17:13] <SpamapS> It is inferrable..
[17:13] <SpamapS> but its damn unclear
[17:13] <SpamapS> I'm > 2 years into UDD and I only just now learned that some teams still use distinct Vcs branches. Up until now, I had not encountered that.
[17:18] <ScottK> I'm > 2 years into ignoring UDD and I can't imagine how you didn't know that.
[17:20] <SpamapS> Basically I don't think any server packages use it
[17:20] <SpamapS> and it seems very few foundational packages do either
[17:20] <SpamapS> meanwhile, I started with Ubuntu dev with UDD
[17:20] <SpamapS> so, I always start with 'bzr branch ubuntu:..'
[17:20] <SpamapS> never debcheckout
[17:20] <SpamapS> never apt-get source
[17:20] <SpamapS> unless the branch is brorked
[17:22] <dobey> thanks stan
[17:22] <dobey> err
[17:22] <dobey> stgraber: ^^ thanks
[17:23] <seb128> SpamapS, I would say that most packages which are actively maintained are not using UDD in Ubuntu...
[17:24] <smoser> seb128, thats an interesting thought. i have had difference experience.
[17:24] <smoser> the only times i don't use it are when the branches are borked (which, unfortunately, seems too often).
[17:24] <seb128> smoser, well none of the desktop packages are maintained in UDD
[17:25] <seb128> smoser, I'm guessing from ScottK's comment that kubuntu is not using UDD either
[17:25] <ScottK> No.
[17:25] <ScottK> We have our own /debian only branches.
[17:26] <xnox> seb128: not UDD but lp:~ubuntu-desktop-team/package/ubuntu ?
[17:26] <xnox> seb128: not UDD but lp:~ubuntu-desktop-team/package/quantal?
[17:26] <SpamapS> Right, so the desktop side of the house, which I think has a lot more Ubuntu delta than server side, is rejecting UDD
[17:26] <seb128> xnox, yes, debian only vcses
[17:26] <seb128> xnox, lp:~ubuntu-desktop/source/ubuntu
[17:26] <xnox> yeah, so with bzr and correct Vcs-* headers
[17:26] <seb128> yes
[17:26] <xnox> not with apt-get source
[17:26] <SpamapS> Its something that needs to be really clear in the UDD manuals
[17:26] <seb128> but with debian only vcs-es
[17:26] <SpamapS> "This is not a given"
[17:27] <seb128> yeah, that's creating lot of confusions for contributors :-(
[17:27]  * xnox somehow has a notion that UDD is bzr regardless of which branch it actually is. As ~ubuntu-desktop predates UDD package importer.
[17:27] <ScottK> Personally, I think that UDD is great just by virtue of the ubuntu: branch getting created/updated for each upload much of the inherent value is provided without me actually using it.
[17:27] <seb128> xnox, well, our vcs-es are not full source
[17:27] <SpamapS> xnox: no, UDD is lp:ubuntu/
[17:28] <seb128> xnox, so they don't really qualify for an UDD like workflow
[17:28] <ScottK> That means when I need to go understand when something was done, I've got the history to figure it out.
[17:28] <xnox> at one point it was ment to point UDD to ~team branches, for packages that do that. Not sure why that didn't happen for long established branches, like on the desktop
[17:28] <ScottK> UDD branches are full source.
[17:28] <ScottK> ubuntu-desktop and kubuntu branches are /debian only.
[17:29]  * xnox would rather have inconsistent checkouts (/debian only and/or full), but always have consistent locations e.g. lp:ubuntu/package
[17:29] <SpamapS> xnox: +1 from me
[17:29] <ScottK> Can't.
[17:29] <xnox> even if lp:ubuntu/package resolves is a symlink to ~ubuntu-desktop
[17:29] <SpamapS> the full source bit seems to be the part that frustrates most people
[17:29] <ScottK> The UDD branches have to be able to represent changes anywhere in the package.
[17:30] <seb128> what drives me crazy with UDD is that every time I try to get a source it's outdated
[17:30] <xnox> ScottK: I'm sure it was possible to 'bless' and designate branches as "official" at one point.
[17:30] <Daviey> so i understand that if a team maintains a full source bzr branch, the UDD branch can be re-pointed.
[17:30] <seb128> the importer keeps failing for desktop packages
[17:30] <SpamapS> seb128: thats been addressed quite a bit
[17:30] <Daviey> SpamapS: *every* time?
[17:30] <Daviey> err seb128
[17:30] <seb128> SpamapS, we got 3 people asking why lp:ubuntu/source is outdated this month
[17:30] <ScottK> Also, now that Kubuntu is going to Universe, it would drive me nuts to have some random upload overwrite anything staged in the branch.
[17:30] <seb128> SpamapS, i.e the gtk import is outdated still
[17:30] <xnox> seb128: for gnome stuff it is due to .xz tarballs which are failing to import, due to out of date OS of the package-import machine. This is being worked on.
[17:31] <Daviey> ScottK: well, at least you get a auto generated MP to cover the staged stuff
[17:31] <xnox> seb128: more info on ubuntu-distributed-devel mailing list
[17:31] <ScottK> Daviey: That's a regression from not having the changes stepped on at all.
[17:31] <ScottK> xnox: That'll affect KDE too.
[17:31] <ScottK> (note that no one noticed)
[17:31] <SpamapS> seb128: right, caused by pristine-tar issues
[17:31]  * xnox had no clue that KDE is doing .xz tarballs......
[17:31] <seb128> xnox, thanks for the info, but well that's the sort of problem which keeps us away from using UDD
[17:32] <Daviey> ScottK: well it's because we are in the middle ground of not having build-from-bzr and dput.. I can't see how you can keep everyone happy
[17:32] <seb128> xnox, I'm not interested in trade a well working efficient workflow for a "known broken but being worked" one, we will reconsider the days things are solid
[17:32] <xnox> seb128: please comment on the udd mailing list. it's being worked on. as it blocks a lot of stuff in e.g. foundations team.
[17:32] <ScottK> seb128: +1
[17:32] <SpamapS> seb128: I agree with you actually. I'd like for UDD to adapt to that reality, rather than keep fighting against it
[17:33]  * xnox runs his own instance of package import to get mdadm branches for example
[17:33] <ScottK> xnox: I filed bugs on UDD tools two years ago that haven't been addressed.  Why should I invest more time in it now?
[17:33] <slangasek> SpamapS: no objections to the merge, but why fix bug #794082?
[17:33] <Daviey> seb128: right, by that logic.. you don't want any people testing Quantal pre-release?
[17:33] <SpamapS> slangasek: because its broken?
[17:33] <seb128> Daviey, quantal is supposed to be usable every day
[17:33] <ScottK> Daviey: No, by that logic I don't want me testing quantal now and I'm not.
[17:33] <SpamapS> slangasek: and, as yet, we have not come up with a decent way to transition from /etc/default/* to env statements in upstar tjobs
[17:33] <seb128> Daviey, UDD is far from usable every day
[17:34] <Daviey> seb128: except the days it is not, right?
[17:34] <slangasek> SpamapS: but /etc/default is lousy and shouldn't be encouraged - given that this hasn't been usable for two LTS cycles now, why re-insert it now?
[17:34] <seb128> Daviey, well it's not we fix it in the hour or revert
[17:34] <seb128> Daviey, the day UDD will be issues we report in the hour I might consider using it
[17:34] <seb128> doh, can't type
[17:34] <SpamapS> slangasek: because hardy is going away soon? ;)
[17:34] <seb128> the day UDD will fix*
[17:35] <Daviey> I actually cannot criticise the response time on issues i have escalated to the people working on it.
[17:35] <SpamapS> slangasek: we agree, but we don't have a migration path.
[17:35] <seb128> Daviey, you maybe know who to poke to get your issues sorted ;-)
[17:35] <xnox> seb128: tranlation fail of "seb128> Daviey, the day UDD will be issues we report in the hour I might consider using it" can you rephrase?
[17:35] <slangasek> SpamapS: right; but just re-adding /etc/default handling everywhere will regress boot speed
[17:35] <seb128> xnox, <seb128> the day UDD will fix*
[17:35] <xnox> seb128: gotcha
[17:36] <SpamapS> slangasek: I don't worry too much about things that start on runlevel 2 affecting boot speed
[17:36] <Daviey> seb128: right, and i know who to poke to get desktop issues fixed.. because i interface with them :)
[17:36] <seb128> xnox, like if had a place to say "can we get gtk import fix" and have it fixed in a timeline which doesn't block me for a week I would sign on maybe
[17:36] <SpamapS> slangasek: perhaps that is misguided?
[17:36] <slangasek> SpamapS: well we certainly do
[17:36] <ScottK> Fundamentally, I don't know what problem I'm having that switching to UDD would solve.
[17:36] <infinity> ScottK: Honestly, all it seems to do for me is create problems.
[17:37] <seb128> xnox, but maybe I would not, because once the reliability issues are fixed we still run into the source v3, full source, quilt mess issues
[17:37] <Daviey> seb128: who did you speak to about the xz issue of imports?
[17:37] <infinity> (I appreciate the ultimate goal of perhaps building from bzr, it's the interim steps that hurt)
[17:37] <Daviey> seb128: have you been following the work on v3/quilt issues?
[17:38] <xnox> Daviey: xz issues are being discussed on the ubuntu-distritubuted-devel mailing list
[17:38] <seb128> Daviey, nobody and no, I've an efficient, established, working workflow and work to get done which I prefer to spend on the content rather than on the tools
[17:38] <xnox> Daviey: seb128 *just* found out about the cause.
[17:38] <MFen> i'm using debhelper (dh) in my local custom package. i want to customize the source package, so i've got debian/source/format 3.0 (custom) and debian/source/options --target-format="3.0 (native)"
[17:38] <MFen> it errors out, it says..
[17:38] <MFen> dpkg-source: error: can't build with source format '3.0 (custom)': no files indicated on command line
[17:38] <cjwatson> MFen: You've misunderstood "3.0 (custom)".  It's not what you want.
[17:38] <MFen> where does that file list.. go?
[17:38] <Daviey> seb128: right, my Dapper desktop works great... I'll stick with that.
[17:38] <seb128> Daviey, I've been going to the UDD sessions at each UDS and explaining there why we don't use UDD though ;-)
[17:39] <xnox> MFen: use 3.0 (quilt).
[17:39] <cjwatson> MFen: Just put "3.0 (native)" in debian/source/format and drop that --target-format thing.
[17:39] <seb128> Daviey, oh, come on, that's nothing to compare
[17:39] <cjwatson> Or "3.0 (quilt)" if you have a separate upstream tarball.
[17:39] <ScottK> Daviey: Also, I do a lot of work on Debian and so using a common toolset is a major feature for me.
[17:39] <MFen> i don't. i *am* upstream, i just want to pass in a list of files from hg manifest
[17:39] <SpamapS> slangasek: I feel that it is pretty lousy of us to just break peoples systems (even if we have 2 LTS's that are broken, its still lousy) and not give them a way to fix it
[17:39] <seb128> Daviey, it's like saying I should use dpatch instead of quilt in my packages, why would that be a strategic thing
[17:40] <cjwatson> MFen: OK, so if you don't have a separate tarball, just use 3.0 (native) in debian/source/format.
[17:40] <seb128> Daviey, it's just tooling, we use whatever let us do the job best
[17:40] <Daviey> seb128: I'm simply suggesting that putting yourself in a little bit of pain, helps the process develop.. Otherwise, progression is really slow.  I know mbp was able to solve many issues, based on user feedback.
[17:40] <MFen> cjwatson: i don't want all the files in this directory though.
[17:40] <MFen> are you saying i need to manually generate a tarball first, and then there's a source format that just lets me use that tarball?
[17:40] <cjwatson> MFen: Then build yourself a tarball and use 3.0 (quilt).
[17:40] <cjwatson> That's what most normal upstreams do.
[17:40] <seb128> Daviey, the issues we have are known for a long time and don't need use to go through extra pain
[17:40] <SpamapS> slangasek: and the google guys were pretty mad about us suggesting that we can just have them keep all those settings in /etc/init/*.conf because that is impossible for them to resolve on package upgrade..
[17:41] <seb128> Daviey, like we have been converting a few packages to UDD for testing and gave the feedback, the situation didn't change in 3 cycles
[17:41] <ScottK> Daviey: I gave it a good try, gave feedback and filed bugs.  That was two years ago and not much has changed.  Doing the same thing again is not a priority.
[17:41] <SpamapS> slangasek: either way, I don't have time to implement a /etc/default/* converter ..
[17:41]  * xnox uses UDD to do debdiffs/NMU's into debian
[17:41] <cjwatson> SpamapS: /etc/init/*.override exists
[17:41] <seb128> Daviey, I go at the UDD session at each UDS and they admit UDD is just not having lot of resources allocated
[17:41] <slangasek> SpamapS: a) they can put it in /etc/init/*.override instead; b) /etc/default/cron is also a conffile so I don't see any reason to believe that's easier to resolve on upgrade than /etc/init/cron.conf, which should change rarely if ever
[17:41] <seb128> Daviey, they don't lack feedback
[17:42] <SpamapS> slangasek: /etc/init/cron.conf is code, and so they're not as comfortable using --force-confold
[17:43] <cjwatson> MFen: the stuff about "arbitrary files" in dpkg-source(1) for 3.0 (custom) is talking about something a bit different; it's basically for people who are doing enormously arcane source package format development.  Basically, nobody who isn't developing dpkg itself needs it.
[17:43] <slangasek> "code" wut
[17:43] <SpamapS> cjwatson: aye, but we are not converting things into .override
[17:43] <slangasek> SpamapS: the only code there is 'exec cron'
[17:43] <slangasek> indeed, /etc/init/cron.conf is a stellar example of a declarative job
[17:43] <SpamapS> except it would break if you apt-get remove cron
[17:44] <MFen> cjwatson: gotcha. ok, so the quilt documentation is far from clear.. where do i put that tarball?
[17:45] <xnox> MFen: ../myapp_1.3.orig.tar.bz2
[17:45] <MFen> hmm. maybe it's just the missing version that's the problem
[17:45] <slangasek> SpamapS: FSVO "break"
[17:46] <SpamapS> slangasek: emit an error?
[17:46] <SpamapS> slangasek: Maybe we don't care?
[17:46] <xnox> MFen: what version control system do you use?
[17:46] <MFen> xnox: mercurial
[17:46] <cjwatson> MFen: you must have a version, yes.
[17:47] <slangasek> SpamapS: I don't care enough about the emitted error to go making /etc/init/cron.conf ugly
[17:47] <MFen> i'm still having issues with this. now i have the right filename, but it's spewing errors about other files that are in the directory. e.g.
[17:47] <MFen> dpkg-source: error: cannot represent change to m11/util.pyc: binary file contents changed
[17:47] <cjwatson> and it must match the bit before "-" in the head version in debian/changelog
[17:47] <MFen> (this is a file in the source directory but not in the source tarball)
[17:47] <slangasek> SpamapS: nor do I care enough about upgrade support for /etc/default/cron to make the boot slower for all users
[17:47] <MFen> how do i make it stfu about that
[17:47] <cjwatson> you should remove .pyc files on clean; dh will do that for you
[17:47] <MFen> the whole point is not to do that. there are mountains of files in here that i do not want considered in the source tarball
[17:48] <MFen> removing pyc files is one thing, removing tons of demo directories and data directories and config files is another
[17:48] <cjwatson> I think you're missing the point somewhere here ...
[17:48] <cjwatson> get your source tarball right first, then unpack it somewhere else and do the packaging there
[17:48] <cjwatson> the packaging must clean up after itself.  that's unrelated to what's in your source directory, because the packaging should never see that
[17:49] <MFen> that seems like a waste of time. i don't even *want* a source tarball, i will never use it because we don't build our package that way. i'm only doing this so it's not so enormous, because debuild insists on building it anyway
[17:49] <cjwatson> if dpkg-source is seeing that you're doing something wrong
[17:49] <cjwatson> you can use -I to exclude things from the source tarball with 3.0 (native)
[17:49] <cjwatson> if you want to do it that way
[17:50] <Daviey> native, generally, makes babies cry.
[17:50] <cjwatson> not always, and let's not be dogmatic about this
[17:50] <SpamapS> slangasek: ok, so we should mark that bug Won't Fix ;)
[17:50] <slangasek> SpamapS: that's my preference, yes
[17:50] <SpamapS> slangasek: but I do feel that this is pretty crappy still. Users with customized /etc/default/* are getting screwed.
[17:50] <cjwatson> you could even put tar-ignore = <stuff> in debian/source/options (the equivalent of -I)
[17:51] <cjwatson> however you should still make sure to build the package separately otherwise you might well find that you're accidentally shipping incomplete source
[17:51] <slangasek> SpamapS: users with customized /etc/default get a one-time upgrade issue to deal with... when upgrading to lucid
[17:51] <MFen> cjwatson: i've been trying to avoid that because there will be many patterns i have to add to that. i was hoping for a whitelist, not a blacklist
[17:51] <cjwatson> You can't have one, sorry
[17:51] <SpamapS> slangasek: *if* its obvious that it is broken
[17:51] <MFen> although maybe what i really want is to blacklist everything. just give me an empty source package
[17:51] <cjwatson> Why build a source package at all if you're going to do that?  Just use debuild -b
[17:52] <SpamapS> slangasek: if they've just raised log priority .. they may not realize for weeks or months that they've lost logs.
[17:52] <MFen> won't that confuse apt, and reprepro if i don't have one?
[17:52] <cjwatson> It won't confuse apt.  I can't speak for your archive.
[17:52] <slangasek> SpamapS: sure, entirely possible - but I don't see why we should be making the boot slower two LTS cycles *later* to try to patch over this when we shipped with that issue for this long
[17:52] <SpamapS> slangasek: I'm not saying this is super urgent crazy important. But I really don't like that we're sweeping this under the rug. :-/
[17:53] <cjwatson> Or the policies imposed by your archive administrators, if you don't run it.
[17:53] <slangasek> SpamapS: maybe a release note is better?
[17:53] <MFen> well, we don't ship source at all. (properly speaking, we don't ship any of this, it's for internal servers)
[17:53] <cjwatson> Given that this is the primary Ubuntu development channel, I can't recommend shipping packages without source, but perhaps this is something local.
[17:53] <SpamapS> slangasek: Or some priority for something to convert them all to env statements in override files.
[17:53] <cjwatson> Don't see why you need a source package then.  Configure your archive to accept binary-only uploads
[17:53] <cjwatson> And use debuild -b
[17:54] <MFen> cjwatson: i like that idea. thanks, i'll work on that
[17:54] <SpamapS> slangasek: but meh, my time for this issue is officially used up.
[17:55] <slangasek> SpamapS: right, I wouldn't object to a standard-ish tool to convert /etc/default/foo to foo.override... I think we've discussed this explicitly in the past... but it's not anywhere near the top of the priority list
[17:57] <SpamapS> slangasek: one thing.. we should remove the file from the package
[17:57] <SpamapS> slangasek: it would be much more clear that way
[18:00] <juliank> cjwatson: Your patch looks OK I'd say. I'd like to take a final look at it tomorrow, and then merge it. Currently, I need to do university stuff.
[18:00] <SpamapS> slangasek: actually even better, I'll install a "# This file is deprecated please edit /etc/init/cron.conf or /etc/init/cron.override directly'"
[18:01] <cjwatson> juliank: Great, thanks
[18:02] <juliank> cjwatson: Upload of the new release to unstable is planned for next Thursday.
[18:03] <juliank> (As we have next Thursday planned due to translation updates)
[18:05] <SpamapS> slangasek: this might even be a change worth SRU'ing back to lucid, so late hardy upgraders will get the notification that the conffile has changed
[18:05] <cjwatson> Sounds good, I think.  I just don't want the python3-debian work to get caught up in a freeze.
[18:19] <mterry> @pilot out
[19:03] <slangasek> SpamapS: dropping /etc/default/cron> oh indeed, very good point
[19:05] <SpamapS> slangasek: uploaded a "This is deprecated" version
[19:06] <slangasek> SpamapS: cheers
[19:30] <bryceh> ogra_, if you're still around, see the merge proposal; branch is failing to build
[20:57] <mterry> mpt, the SoftwareUpdates spec defines "uninstallable updates" as updates that would remove ubuntu-desktop.  What about updates that would remove some other package?  There is no UI for presenting such updates (and I think the current U-M handles that by pointing users at a release upgrade dialog)
[22:09] <BenC> infinity: any way I can get scilab to stop being bumped on the ppc buildd?
[22:10] <StevenK> BenC: bumped?
[22:10] <BenC> It keeps getting pushed back while other package builds get higher priority it seems
[22:10] <StevenK> BenC: Ah, I can rescore it for you, if you wish.
[22:10] <BenC> Yes, please
[22:10] <StevenK> BenC: Link me the build?
[22:11] <BenC> StevenK: https://launchpad.net/ubuntu/+source/scilab/5.3.3-10ubuntu2/+build/3574412
[22:11] <BenC> Thanks
[22:11] <BenC> I have a few other FTBFS to kick off once that's done, and it's been in queue since last night :)
[22:12] <StevenK> BenC: sulfur just picked it up
[22:40] <RAOF> hyperair: pong.
[22:41] <infinity> BenC: Queue jumper. :P
[22:43] <BenC> infinity: queues go in order…that sucker was on a negative timeline
[22:43] <infinity> BenC: It's in universe and people kept uploading stuff in main.
[22:44] <BenC> Damn core-devs and their main packages
[22:53] <BenC> Dear thunderbird…welcome back to powerpc
[22:53] <BenC> And with that, I've gotten rid of all the FTBFS in main/powerpc
[22:54] <BenC> Damn you firefox
[22:54] <micahg> BenC: please tell me you didn't upload thunderbird
[22:54] <BenC> Nope, but I need someone to do it
[22:54] <BenC> …if not me
[22:54] <micahg> BenC: yeah, ask chrisccoulson how he wants it, it can go in with the next beta
[22:55] <micahg> unfortunately, it's a monstrosity
[22:55] <BenC> Firefox will need the same fix
[22:55] <micahg> yeah
[22:55] <BenC> Does he handle that too?
[22:55] <micahg> yep
[22:55]  * micahg would think merge proposal against lp:firefox/beta
[22:55] <micahg> really should have one for lp:firefox as well ideally
[22:56]  * micahg wonders if it was fixed for 15
[22:57]  * micahg will be happy if we get powerpc back in the stable releases for 14
[22:57]  * infinity is trying to decide how deeply he cares about mozilla.org stuff compiling for incorrect CPU targets on armel.
[22:58] <infinity> Well, or failing to.
[22:58] <infinity> I'm sure I'll care at some point.
[22:58] <BenC> Give it a beer or two
[22:59] <infinity> Could take a few litres of gin.
[23:00] <infinity> GHC seems okay locally, at least.  Just needed a hard rebootstrap, since it sort of explodes upon trying to compile itself.
[23:00] <infinity> Not the brightest compiler on the tree.
[23:00] <BenC> GHC on ppc?
[23:00] <infinity> armel.
[23:01] <infinity> Not EVERYTHING is about you. :P
[23:01] <BenC> I was trying earlier (with no success) to re-enable ghci on powerpc
[23:01] <BenC> hehe
[23:01] <infinity> GHC on PPC is fine.  Well, except for ghci.
[23:01] <infinity> No ghci on ARM either.
[23:01] <infinity> Upstream doesn't much care.
[23:01] <BenC> It's causing a lot of FTBFS and dep-waits
[23:01] <micahg> infinity: hrm?  is something else broke?
[23:01] <infinity> And it's not trivial.
[23:01] <infinity> BenC: Yeah, ghci just plain isn't support on non-primary arches upstream.
[23:01] <BenC> It's at least not segfaulting on innovation like it was in Jan
[23:02] <BenC> *invocation
[23:02] <infinity> BenC: That may be some failures you'll just have to live with, unless you have a lot of free time.
[23:02]  * infinity would like to get some people on ghci-on-ARM too, but I'm not made of Engineers.
[23:02] <BenC> If only I were a haskell type person, but alas, I'm only concerned enough because of the numbers, not because I really like haskell
[23:03] <infinity> Well, I suppose I *am* made of engineer.  Just one, though.
[23:03] <micahg> infinity: oh, right, yeah, well, packages build on Debian somehow, so there's got to either be a patch or flag to make it work
[23:03] <BenC> An Engineer of One (™)
[23:03] <infinity> BenC: I don't care about Haskell, but everyone I know who does use it, uses ghci, so it's effectively useless to them on non-primary arches.
[23:03] <infinity> micahg: Eh?
[23:03] <infinity> micahg: A patch or flag for what?
[23:03] <micahg> infinity: firefox/thunderbird
[23:04] <infinity> micahg: Oh.  Right.
[23:04] <micahg> builds on armel in Debian last I checked
[23:04]  * ajmitch thought that ghci on arm was merged upstream now
[23:05] <infinity> ajmitch: Is it?
[23:05] <infinity> ajmitch: If so, yay, but that certainly hasn't filtered down to the masses.
[23:05] <ajmitch> was reading http://www.haskell.org/pipermail/haskell-cafe/2012-June/101704.html from a few days ago, in 7.4.2
[23:05]  * RAOF might get mono to actually work on armhf over the weekend.
[23:06] <ajmitch> RAOF: that'd be nice :)
[23:06] <infinity> ajmitch: Oh, VERY recently.  Nice.
[23:06] <infinity> RAOF: Define "work".
[23:06] <infinity> RAOF: It already works, it's just not hard float...
[23:06] <RAOF> infinity: Fail to segfault as soon as someone p/invokes.
[23:07] <infinity> RAOF: Unless you meant s/armhf/armel/
[23:07] <infinity> RAOF: Or did I miss a recent development with it no loger working?
[23:08] <RAOF> It's apparently never worked on armhf.
[23:08] <RAOF> Well, except for purely managed code.
[23:08] <RAOF> The JIT works, but as soon as you try to call out to a native library it uses the wrong ABI and things go horribly pear-shaped.
[23:08] <Bluefoxicy> hmm, seems ejecting even the partition does it.
[23:09] <Bluefoxicy> Is 'eject' just umounting?
[23:09] <RAOF> You can see this in the build logs; the test-suite works, except for everything that has “pinvoke” in the name, which segfaults :)
[23:09] <infinity> RAOF: Oh, lovely.  Well, if you like mono, go to town.
[23:09] <infinity> RAOF: Bonus points if you make it actually be hard-float while you're at it. :P
[23:10] <RAOF> It's *got* a hard-float codepath; is that not on?
[23:10] <infinity> RAOF: (Also, I think this hilights that the testsuite is awful, since it passes on armhf...)
[23:11] <RAOF> No, I don't think it does. But failing the testsuite doesn't fail the build.
[23:11] <infinity> RAOF: I could be mistaking it for some other nasty hack, but I was fairly sure that mono on armel and armhf were both more-or-less no-float.
[23:12] <infinity> Oh, indeed.  "390 test(s) passed. 9 test(s) did not pass."
[23:13] <RAOF> It's entirely possible; I've recently prodded around a tiny bit in the ARM (and s390, and sparc, and PPC) JITter, and it seemed to have a float codepath.
[23:13] <infinity> RAOF: Honestly, I only tend to care about mono is as much as it's critical path for building a ton of other crap.
[23:13] <infinity> RAOF: But if you can make it actually work correctly, go nuts.
[23:13] <RAOF> I may ask questions about ARM ABIs :)
[23:14] <infinity> And I may answer them.
[23:15] <infinity> BenC: So, upstream has a table that *claims* ghci is supported on PPC.  So, it may just be suffering a tiny bit of bitrot, might not be as much effort as I initially claimed.
[23:15] <infinity> And with ghci supported on ARM in 7.4.2, that tosses out a ton of build failures and brings all our arches to parity.  Ish.
[23:15] <infinity> Yay for toy languages.
[23:16] <infinity> (Actually, as much as I don't care about ghc/ghci, I guess having a toy language on toy dev boards is kinda the ideal for poor university students and such)
[23:16] <BenC> infinity: Are you uploading 7.4.2? If so, I'll try re-enabling ghci on PPC
[23:16] <infinity> BenC: No.  But I'll probably prod the Debian maintainers about it once I'm done rebootstrapping 7.4.1 on armel. :P
[23:17] <BenC> infinity: irk…Yeah, there's a patch that disables in on ppc…apparently the 6.8 core (of whatever it is that handles ghci) works on ppc, but the 6.10 in current ghc doesn't work so good
[23:39] <BenC> infinity: BTW, I only found one more build-arch fixable package, so I have a note to kick it once dpkg is merged
[23:59] <RAOF> @pilot in