[00:39] <cfhowlett> _Marcus: Devices - Install Guest Additions.
[00:48] <kklimonda> hey - I have a package dogtag-pki-common-theme with Provides: pki-common-theme and another package pki-common which depends on pki-common-theme
[00:48] <kklimonda> I can't install pki-common as it complains about pki-common-theme missing
[00:49] <kklimonda> is there a good read about using Provides with Depends?
[00:53] <kenalex> hello
[00:53] <kenalex> which ubuntu version is best for software development 10.04 or 11.10
[01:08] <RAOF> kenalex: That's not really something that we can answer for you; it depends on your target.
[01:10] <kklimonda> ah, hmm - it seems you can have versioned dependency on a virtual package (which makes sense if you think about it)
[01:13] <RAOF> kklimonda: You mean you *can't* have a versioned dependency on a virtual package, right?
[01:13] <RAOF> And, indeed, if you think about it it makes sense :)
[01:13] <kklimonda> RAOF: yes, right :)
[01:23] <maxb_> Does it make sense?
[01:24] <maxb> It's always struck me as being an implementation shortcoming, but one sufficiently minor that it's no-one's priority to fix
[01:24] <RAOF> Well, you could make it make sense by also versioning the Provides
[01:25] <RAOF> ie: Provides: foo-service (2.0) or something.
[01:25] <RAOF> But if you're doing that you might as well just Provides: foo-service-2.0 and be done with it.
[01:25] <broder> maxb: what does it mean to Depend: mail-transport-agent (>= 2.3)?
[01:26] <maxb> Nothing, but what about Depends: java-runtime (>= 5)
[01:26] <cjwatson> BenC had a go at fixing it years ago (before Ubuntu) but it never made it into production
[01:26] <TheMuso`> superm1: 1.0.25, assuming the rest of the stack checks out ok with testing, i.e no critical showstoppers.
[01:27] <cjwatson> There may even still be patches lying around but I doubt they apply to modern apt :-)
[01:27] <cjwatson> I think his design was that packages could choose to e.g. "Provides: java-runtime (= 5)"
[01:28] <RAOF> I'm not sure even that really works, because there's no guarantee that java-runtime (= 8) necessarily supports java-runtime (= 5).
[01:28] <broder> i assume it wouldn't, right?
[01:29] <broder> you'd have to do provides: java-runtime (= 5), java-runtime (= 8)
[01:29] <RAOF> ie: if we packaged a JRE with deprecated stuff dropped, and split out a jre-5-compat type package.
[01:29] <cjwatson> If you have that class of problem then you could change the name of the virtual package
[01:29] <cjwatson> Don't need to solve every problem with the same hammer
[01:29] <cjwatson> (But, yes, we seem to have adequate fallbacks for this one already)
[01:30] <RAOF> I'm not sure what problem is solved by java-runtime (= 5) that isn't solved by java-runtime-5.0
[01:30] <RAOF> Actually, no, I do know.  When you're providing virtual library packages.
[01:31] <RAOF> So you've got something that currently depends on libfoo3 (>= 2.3.3) and you want to turn libfoo3 into a virtual package provided by libbar2.
[01:32] <maxb> Right - again, the workarounds are not exactly hard, but it could be useful to be able to provide a versioned virtual package
[02:11] <slangasek> stgraber: I'm wondering if it's a mistake for ifupdown to stop running hook scripts at the first non-zero exit
[02:11] <slangasek> stgraber: cf. bug #932485
[02:15] <YokoZar> slangasek: can I use depends foo:any for packages which only exist in Oneiric and later?
[02:16] <slangasek> YokoZar: as cjwatson said, there are other reasons the lucid tools might have to be able to parse these
[02:17] <YokoZar> slangasek: How about for a myapps or ARB package?
[02:17] <YokoZar> (specifically, I want depends: unionfs-fuse:any)
[02:17] <slangasek> YokoZar: er, not my department; I don't know what the constraints are on packages there
[02:17] <YokoZar> presumably they aren't going to ever encounter a Lucid tool though
[02:18] <slangasek> I can't think of any reason specifically that a myapps/ARB package, if distributed for precise, would cause problems with :any
[02:18] <YokoZar> Yeah me neither
[02:18] <YokoZar> Thanks :)
[02:25] <stgraber> slangasek: It was definitely meant as a bugfix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547587
[02:25] <stgraber> slangasek: though I agree it'd probably be safer to re-introduce the "bug" for 12.04
[02:25] <stgraber> slangasek: and let Debian deal with the problems for a bit then maybe switch it back in 12.10
[02:26] <stgraber> slangasek: (apparently we'll get a beta3 or rc pretty soon which will hit unstable and I'll merge into Ubuntu)
[02:26] <stgraber> slangasek: Ubuntu is currently the only distro with --exit-on-error in that run-parts, so we're obviously the first to notice the issues
[02:30] <slangasek> stgraber: how do you mean, the only distro?  is there an Ubuntu-specific patch turning on --exit-on-error?
[02:31] <stgraber> slangasek: no, but currently only Ubuntu ships the new ifupdown (0.7), in Debian it's limited to experimental, the rest is still on 0.6
[02:32] <slangasek> ah, right
[02:35]  * micahg thought that Multiarch: foreign precluded the need for Depends: foo:any
[02:36] <cjwatson> Yep, unionfs-fuse could just have Multi-Arch: foreign (it doesn't right now) and then this wouldn't be an issue
[02:36] <micahg> YokoZar: ^^
[02:36] <cjwatson> :any is only relevant for M-A: allowed, that is, things where some dependents might require the same architecture but others will be happy with any architecture
[02:36] <slangasek> oh, unionfs-fuse isn't M-A: allowed?
[02:37] <slangasek> in that case, :any isn't legal
[02:37] <cjwatson> It's not and I can't think why it'd ever need to be
[02:37] <YokoZar> cjwatson: is it really proper to install unionfs-fuse:i386 on an amd64 system?
[02:37] <slangasek> and :any won't work
[02:37] <YokoZar> err
[02:37] <YokoZar> nm
[02:37] <YokoZar> foreign
[02:37] <stgraber> slangasek: I'll mention to Andrew on IRC and will decide whether to revert the change or not tomorrow after I talk a bit with him
[02:37] <cjwatson> YokoZar: If you use M-A: foreign, then you'll get unionfs-fuse:amd64, not unionfs-fuse:i386
[02:37] <slangasek> stgraber: ok
[02:37] <cjwatson> YokoZar: although in any case I don't see why it would matter
[02:38] <cjwatson> by definition if you have an architecture enabled using multiarch then you can execute its binaries
[02:38] <YokoZar> cjwatson: Yeah foreign is the right way to do it, I can't think of a reason a package would have an arch-specific dependency on unionfs-fuse
[03:12] <superm1> TheMuso`: i was informed that there are some problems with 1.0.25 and nvidia audio chipsets.  specifically with mplayer and mythtv users.  there's fixes in master but not in 1.0.25, so if you do decide to do 1.0.25 I hope you can also backport those other fixes
[04:28] <TheMuso`> superm1: In master of alsa-lib?
[04:29] <TheMuso`> superm1: Because since 1.0.25, I don't see anything in alsa-lib that is to do with anything NVIDIA.
[04:50] <superm1> TheMuso: this is the thread i was pointed at: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-February/049061.html  Here's some more of the context of the discussion about how it's broke: http://paste.ubuntu.com/842632/
[04:50] <superm1> the exact patches that fixed it weren't linked in the thread, but takashi indicates at the end that it's fixed in master
[04:51] <superm1> "The problem of Nvidia HDMI and the buffer-alignment was already fixed in the upstream code"
[04:51] <superm1> i'll see if jya was able to track down what patches actually did that, but if not, i'm sure takashi can help point at them too
[04:52] <pitti> Good morning
[04:53] <TheMuso> superm1: Sounds like kernel, and thats not really my area, but thanks.
[04:54] <superm1> TheMuso: ah.  well when you're ready to do 1.0.25, are you going to stage on a PPA and call for testing and such?
[04:55] <TheMuso> superm1: Well the kernel alsa version tends to follow a different process in terms of when it gets updated.
[04:55] <superm1> oh
[04:55] <TheMuso> superm1: alsa-lib 1.0.25 was in last week, since I accidentally jumped the gun with that one without calling for testing, however everything else alsa is in the Ubuntu Audio Dev PPA, and the community team put a call out for testing late last week to.
[04:56] <TheMuso> But kernel 3.2 has a version of 1.0.24, however this is not often always correct, as 1.0.25 commits make their way in, especially if they enable hardware.
[04:56] <TheMuso> SO kernel wise, the version is not that good a guide.
[04:57] <superm1> TheMuso: ah i see.  i'll talk it over some more with jya then.  he's got a hand full of hardware so he can hopefully test with what's in precise right now and the other alsa bits in the audio dev PPA
[04:57] <TheMuso> Ok.
[05:07] <TheMuso> superm1: TO be clear, we do not use the kernel code found in the alsa-driver package, our alsa kernel code comes from the kernel.
[05:07] <superm1> TheMuso: right so as this problem seems to be caused by a commit to alsa-driver, it will eventually find it's way into the kernel, but probably at a slower rate
[05:08] <TheMuso> superm1: Right, or the fixes may already be in 3.2. If they aren't, we can cherry pick them.
[05:09] <superm1> yeah, really need to identify those commits and figure out where they are right now
[05:09] <TheMuso> Alsa kernel code is developed agains the kernel first, then alsa-driver packaging/development is done second.
[05:09] <TheMuso> against
[05:16] <superm1> TheMuso: okay so crisis averted.  turns out the patch that causes problems for nvidia and the solution for the regression both landed in 3.2, so no worries.  thanks for the help
[05:21] <cfhowlett> Will the AWN dock make be seen in 12.04?
[05:28] <TheMuso> superm1: np.
[06:28] <pitti> superm1: mythbuntu-desktop depends on the NBS mythvideo; can this be dropped?
[06:28] <superm1> pitti: yes, but i was waiting to make the change until mythtv got out of NEW
[06:28] <pitti> hm, I just NEWed it an hour ago or so
[06:29] <superm1> oh, well then i might be behind the times :)
[06:29] <pitti> superm1: ah, still needsbuild on armel/powerpc, will it be NEW there, too?
[06:29] <pitti> (the binNEW from this morning was arch:all, the php-* one)
[06:29] <superm1> there was the php-* one and libmyth-0.25-0.  i'm not sure if that was already cleared on armel or powerpc yet though
[06:30] <superm1> php-* one was i386 only
[06:30] <superm1> i still see them both (i386 and amd64) listed in https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=mythtv is that because publisher run not done yet?
[06:31] <pitti> superm1: oh, I think that's the previous upload
[06:32] <pitti> I just NEWed the recent one
[06:32]  * pitti cleans those up, too
[06:32] <superm1> oh i see
[06:32] <pitti> (done)
[06:32] <superm1> thanks!  i'll get the meta fixed up to take *video out
[06:33] <pitti> cheers
[07:36] <broder> could somebody on ubuntu-branches mark https://code.launchpad.net/~jtaylor/ubuntu/oneiric/distribute/fix-910965/+merge/87303 as merged to get it off the sponsorship queue? (it should show up in UNAPPROVED momentarily)
[07:36] <pitti> broder: done
[07:36] <broder> (or jtaylor, you could do it, if you're around)
[07:36] <broder> pitti: thanks :)
[08:54] <apw> didrocks, i don't know if you saw the discussion on nm-applet eating peoples machines, dunno if that could be the cause of your slowness, cirtainly it makes my machine feel that way and leave kswapd running a lot as well
[08:55] <didrocks> apw: ah interested, maybe that can be related yeah
[08:55] <didrocks> apw: didn't see the discussion though, where was it?
[08:55] <apw> mostly here about 12 hours back, and a bug ... erm
[08:56] <didrocks> apw: I'll look at my IRC logs then, thanks for the notice :)
[08:56] <apw> https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/930491
[08:56] <apw> didrocks, ^^
[08:56] <didrocks> apw: looking
[08:57] <apw> i noticed cause my machine felt like treacle, and was swapping
[08:58] <didrocks> apw: I didn't notice it in htop, but I'll watch after it, thanks!
[08:58] <didrocks> is cyphermox aware?
[08:58] <apw> didrocks, yeah he is
[08:58] <didrocks> ok, nice :)
[08:58] <didrocks> I'll try to kill nm-applet
[08:58] <didrocks> and see if I still get it after a few hours of use
[08:58] <apw> didrocks, yeah its not running a lot, it just leaks an amount proportional to the number of wifi access points
[08:59] <apw> ps lax | grep nm-applet
[08:59] <apw> didrocks, ^^ was showing me 1.7g resident
[08:59] <didrocks> apw: well, I'm "only" at 100Mb res, which is quite high for such a software
[09:00] <didrocks> after 2h45
[09:00] <apw> didrocks, and mine got that far cause the machine in question has 4G of ram, so it started to really hurt
[09:01] <didrocks> yeah, definitively needed to be fixed…
[09:24] <micahg> hi mvo, are you planning on merging aptitude 0.6.5 before feature freeze?
[09:30] <mvo> micahg: no, sorry, I don't think I will have time for this
[09:30] <micahg> mvo: would you mind if I did it?
[09:31] <mvo> micahg: not at all, thanks a bunch!
[10:09] <pitti> apw, ppisati: I binNEWed the new linux-ti-omap4, doing a d-i rebuild now; can you please update linux-meta-ti-omap4 ?
[10:11] <apw> pitti, ack
[10:37] <bkerensa> dholbach: Are you about?
[10:38] <dholbach> bkerensa, yep
[10:38] <bkerensa> dholbach: I'm working on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/593107
[10:38] <dholbach> ah, best have a chat with the guys in #ubuntu-kernel
[10:38] <bkerensa> and was wondering if you might have some feedback on a better description to bring it up
[10:39] <bkerensa> dholbach: Oh those guys eh? :P
[10:39] <dholbach> yep :)
[10:40] <infinity> Note that linux-tools-* are generated from the kernel sources, and they'll be very miffed if you modify those packages. ;)
[10:40] <infinity> But pushing them patches to put in git will make them quite happe.
[10:40] <infinity> happy, too.
[10:41] <bkerensa> infinity: Indeed... I'm just trying to get feedback on a better description to match debian policy on descs
[10:41] <bkerensa> Right now the description is pretty vague
[10:41] <bkerensa> and the only tool I have used is perf
[10:41] <infinity> bkerensa: Describing what tools are included, or at least what you might want to use them for, would be a good start.
[10:43] <bkerensa> infinity: The problem is I cannot find a list of all the included tools so I cannot create a good description the summarize them all
[10:44] <infinity> bkerensa: If you have it installed, "dpkg -L <packagname>" will show you what's included.
[10:44] <infinity> bkerensa: One would assume all the interesting bits are in {,/usr}/{,s}bin/
[10:44] <bkerensa> k
[10:47] <bkerensa> infinity: Hmm http://paste.ubuntu.com/842872/
[10:47] <bkerensa> :)
[10:47] <bkerensa> I also have source which only includes a debian folder
[10:47] <infinity> bkerensa: The versioned package has the tools.
[10:47] <bkerensa> ahh
[10:47] <infinity> bkerensa: linux-tools-$(uname -r)
[10:55] <ppisati> pitti: when you have time, could you pubblish the new omap4 kernels? thanks
[10:55] <ppisati> *publish
[10:56] <infinity> ppisati: They're through NEW already.
[10:56] <infinity> ppisati: Nothing more for pitti to do.
[10:56] <ppisati> nice
[10:57] <pitti> ppisati: yep, did half an hour ago; was eagle-eying this to get NBS down
[10:59] <infinity> pitti: Heh, I'd been waiting up to do it, and I turned away from my computer for a few minutes and you beat me to it. :P
[11:03] <ppisati> cool, just hit the archive
[11:38] <hrw> does someone know what is wrong with login.ubuntu.com?
[11:39] <bkerensa> hrw: What do you mean?
[11:41] <hrw> bkerensa: unable to authorize tomboy to use ubuntuone
[11:41] <hrw> (Identyfikator błędu: 2237canistelubuntu1110)
[11:41] <bkerensa> Hmm
[11:41] <bkerensa> odd
[11:41] <bkerensa> Didn't they end tomboy support for Ubuntu One?
[11:42] <Laney> no
[11:42] <hrw> bkerensa: u1 does not display notes on website
[11:42] <hrw> bkerensa: tomboy still may store them on u1
[11:42] <bkerensa> ahh
[11:47] <bkerensa> dholbach: Got a patch submitted to those Kernel folks :)
[11:47] <dholbach> yoohooo!
[12:07] <barry> quick versioning question: fgfs-atlas 0.3.1-2 is in the archive.  i have to build it from cvs to fix the nbs, so i'm going to upload 0.3.1+cvs20120214-0ubuntu1.  does that seem reasonable?
[12:12] <pgraner> anyone have an idea on why today's updates would want to remove skype?
[12:13] <pitti> pgraner: libaudio i386/amd64 buildd desync
[12:13] <pitti> err, libasound I mean
[12:14] <pitti> oh, https://launchpad.net/ubuntu/+source/alsa-lib/1.0.25-1ubuntu4/+build/3213632
[12:14] <pitti> FTBFS on i386
[12:15] <pitti> pgraner: so don't say yes for now
[12:15] <pgraner> pitti, ok, should that have shown up on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html  ?
[12:15]  * pgraner is not sure how that gets generated
[12:15] <pitti> pgraner: we don't test multi-arch to that level yet
[12:16] <pitti> i. e. it doesn't notice if a libfoo is on a different version between architectures
[12:16] <pgraner> pitti, ah ok, good to know
[12:19] <cjwatson> alsa-lib needs to be built on a 64-bit-capable buildd :-/
[12:19] <cjwatson> stick it on roseapple, and cry a bit inside
[12:20]  * cjwatson goes to do that
[12:20] <cjwatson> (this'll get fixed next time we merge from Debian, since they're dropping the lib64* bits)
[12:20] <cjwatson> oh, bleh, roseapple is on amd64 duty right now
[12:21] <cjwatson> I'll grab it back once it's done with firefox
[12:21] <infinity> cjwatson: Err, what?
[12:23] <cjwatson> notice how all its successful builds of late have been on roseapple ...
[12:23] <infinity> Yeah, no.  I see the issue.
[12:23] <infinity> I'm questioning the solution. :P
[12:23] <cjwatson> and the error is "cannot run C compiled programs" on the -m64 pass
[12:23] <infinity> Can we not just turn that insanity off?
[12:24] <cjwatson> like I say, that's what the next merge from Debian will do
[12:24] <cjwatson> I'm just not prepared to take responsibility for that :)
[12:25] <infinity> Doesn't look like the worst merge ever.  But yeah, it's 5am for me too, I guess I'll pass on being a hero right now.
[12:28] <GunnarHj> cjwatson: Hi Colin, any chance that you can give bug 926207 some attention? Just talked to pitti about it, and we concluded that it's important that the bug gets fixed before the 12.04 release.
[12:28] <cjwatson> not today but I'll load it up
[12:29] <cjwatson> for future reference please don't create tasks on multiple installer components if you aren't an installer developer
[12:29] <cjwatson> one will do :)
[12:42] <GunnarHj> cjwatson: Aha, sorry, just tried to be helpful...
[12:44] <GunnarHj> cjwatson: Anyway, thanks in advance for dealing with it.
[12:58] <ochosi> mvo: hey, i have a question wrt software-center. it currently shows the package "exo-utils" as "Email Reader" and "Web Browser" which is highly misleading. i guess that information comes from the desktop-file, is there anything we/you can do about that?
[13:02] <mdeslaur> @pilot in
[13:03] <mdeslaur> @pilot in
[13:03] <mdeslaur> @pilot in
[13:03]  * mdeslaur kicks bot
[13:06] <mdeslaur> @pilot in
[13:06] <mdeslaur> dholbach: ^ bot's busted
[13:07] <dholbach> AlanBell, ^ do you know what we can do about it?
[13:08] <mvo> ochosi: yes, you can set "X-AppInstall-Ignore=true" in the desktop files
[13:08] <mvo> ochosi: or I can blacklist them in my extraction code
[13:11] <ochosi> mvo: what is the more common approach?
[13:12] <ochosi> mvo: in fact our packager (mr_pouit) just tells me that exo doesn't have any delta with debian atm and it'd be great if you could blacklist it
[13:13] <ochosi> mvo: i meant debian _and_ upstream :)
[13:13] <cjwatson> ochosi: exo has a delta
[13:13] <cjwatson> ochosi: albeit not one that matters for this purpose
[13:13] <ochosi> mr_pouit: ^ :)
[13:14] <cjwatson> i.e. https://launchpad.net/ubuntu/+source/exo/0.6.2-3ubuntu1
[13:14] <mvo> ochosi: having it in the package is easier for me but either way is fine
[13:15] <ochosi> mvo: ok, well i think in fact it's mr_pouit's call, i just noticed because one of "my users" uninstalled exo-utils by mistake and it wasn't very pleasant to fix remotely :)
[13:17] <infinity> mdeslaur: Bots aren't entirely necessary. :P
[13:17] <mr_pouit> ok, then I guess I'll do it in the packages then
[13:17] <mdeslaur> infinity: I'm terrified of dholbach thinking I skipped my patch piloting duty :)
[13:18] <mr_pouit> all items from xfce4-settings appear in software-center too, and it's just confusing
[13:18]  * dholbach hugs mdeslaur
[13:18] <mdeslaur> hehe
[13:18]  * mdeslaur hugs dholbach
[13:20] <mvo> thanks mr_pouit - about xfce4-settings should I blacklist a package (i.e. is it all just in a single pkg?)
[13:20] <mr_pouit> cjwatson: I know, but you forwarded it to debian so there won't be any delta with the next upload, hopefully
[13:22] <ochosi> hm, if i'm not mistaken exo-utils is also single package but several desktop-files...
[13:22] <mr_pouit> mvo: packages can also ship desktop files to appear in xfce4-settings, so blacklisting won't do (e.g. orage ships xfce-xfcalendar-settings.desktop, which appears in software-center because of that ;-)
[13:27] <mvo> mr_pouit: is there a straightforward way to detect them? I guess I should just download the examples
[13:29] <mvo> mr_pouit: so if X-XfceSeettingsName is there I guess it does not make sense in software-center, is that correct?
[13:31] <pitti> SpamapS: wow @ https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.20-0ubuntu1
[13:31] <AlanBell> jussi: is the patchpilot bot running?
[13:31] <pitti> SpamapS: that's the first-ever package that I saw that succeeded on all ports but failed on i386 and amd64 :)
[13:32] <mr_pouit> mvo: mmh, I think you can exclude a desktop file when there's X-XfceSettingsDialog in the category (X-XfceSettingsName is only used by orage)
[13:50] <infinity> SpamapS: \o/ on mysql using gcc-4.6!
[13:53] <infinity> cjwatson: Have you put any time/thought into grub2 and gcc-4.6?  Looks like with the last mysql upload, only the bootloaders (grub2 and u-boot-linaro) are keeping gcc-4.5 in main.
[13:57] <geser> pitti: no wonder as the test suite may only fail on amd64 and i386 (the other archs have "|| true" after the make test-force)
[14:00] <cjwatson> infinity: some, but I've been having build problems
[14:00] <cjwatson> infinity: I was planning to get back to it after FF
[14:29] <hrw> "The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8-pre1."
[14:29] <hrw> = no way to print under precise
[14:29] <hrw> be back in ~1h to discuss
[14:30] <apw> cyphermox, i note i am getting the error below constantly from a version of nm-applet running in a terminal:
[14:30] <apw> LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent.
[14:30] <cyphermox> yes, I'll be fixing that with ted today
[14:31] <cyphermox> this is because the same menu is used for the GtkStatusIcon applet as for the appindicator, and the way it's built
[14:33] <apw> cyphermox, and thats the source of the leak?
[14:33] <cyphermox> not afaik
[14:33] <apw> bah, so no progress on that ?
[14:34] <cyphermox> yes, getting there
[14:34] <apw> cool
[14:38] <apw> am i right in thinking that the control file in a source package, only the top source section is actually used ?
[14:41] <geser> used for what?
[14:43] <infinity> apw: No.
[14:43] <infinity> apw: The entire control file is used to determine the Binary: and Architecture: lines in the .dsc
[14:44] <infinity> apw: Which can do entertainingly haywire with auto-generated control files.
[14:44] <infinity> s/do/go/
[14:44] <apw> infinity, how does that work with udebs which don't appear there
[14:44] <infinity> I think you sort of answered your own question.
[14:44] <infinity> They don't appear there. ;)
[14:45] <infinity> Though, they should still be counted in the Arch: line.
[14:46] <apw> infinity, so them not being in the binary: line is or isn't a problem overall
[14:47] <infinity> apw: For consistency sake (and tools that rely on Binary being correct), it's a potential issue.
[14:47] <infinity> apw: In the real world, I think we've learned to live with .dsc being incorrect.
[14:47] <apw> infinity, and am i right in saying that the only bit that it cares about is the Package: lines then, the rest of the binary area is ignroed
[14:48] <infinity> apw: Package and Arch are the two binary lines that matter to source packages.
[14:48]  * apw is trying to work out if the textual description being inaccurate in the source package is a problem or not
[14:48] <infinity> apw: (Arch being important because it bubbles up to the dsc, and it's how we determine where to build the source)
[14:48] <apw> infinity, ok great, thats what i hoped
[14:48] <infinity> apw: Descriptions don't matter, no.
[14:50] <Beret> kirkland, Ctrl-a in byobu broken?
[14:50] <kirkland> Beret: hmm, it should be fixed in byobu 5.10
[14:50] <kirkland> Beret: what version are you running?
[14:50] <kirkland> Beret: byobu -v
[14:50] <Beret> ah
[14:50] <Beret> ok
[14:50] <Beret> 5.9
[14:51] <kirkland> Beret: yeah, upgrade to the latest and it's fixed;  yes, it was broken for a day or two
[14:51] <scott-work> can anyone suggestion a person that is pokeable to review the lowlatency kernel in REVU?  http://revu.ubuntuwire.com/p/linux-lowlatency
[14:51] <Beret> kirkland, no worries, thanks
[14:51] <scott-work> we have one advocate already but need another (before tomorrow i believe)
[14:52] <cjwatson> apw: the kernel is definitely anomalous here; I can't think of any other package that builds things not declared in its .dsc
[14:52] <cjwatson> apw: ideally, the kernel's debian/control as uploaded would contain stanzas for the union of all the binary packages it might build on any architecture
[14:53] <cjwatson> that's what everything else does :)
[14:53] <apw> cjwatson, yeah the kernel wedge output is most unhelpful
[14:53] <cjwatson> there's nothing wrong with the kernel-wedge output - you're using it wrong ;)
[14:54] <apw> cjwatson, heh is there a unioner ?
[14:54] <infinity> scott-work: Is it heavily patched, or just the Ubuntu source with some config tweaks?
[14:54] <cjwatson> worst case you could run it on clean with DEB_HOST_ARCH set to each of the architectures you support, or something like that ...
[14:54] <infinity> scott-work: The latter would be simple to review, but one could also make an argument for just generating it from the original source.
[14:54] <cjwatson> and cat the whole lot onto control
[14:55] <cjwatson> although I suppose I don't know if having two stanzas for the same package name which differ only in architecture would cause a problem - I guess in that case you would need something to produce the union, yes
[14:55] <cjwatson> though, I thought this was exactly what 'kernel-wedge gen-control' was for
[14:56] <cjwatson> hm, maybe not, can't quite remember
[14:57] <cjwatson> I'd be surprised if the Debian kernel people hadn't solved this recently, since they just started building udebs out of their kernel source
[14:58] <infinity> scott-work: Also, if it's based on the Ubuntu packaging, it should use the 3.2.0.orig.tar.gz instead of being packaged natively.
[15:04] <infinity> scott-work: Yeah, okay, looking at this, it looks like it's literally just config changes, and an accidental change in arch/arm (which is entertaining, since it only builds for x86)
[15:04] <infinity> apw: Is there a reason we can't take this lowlatency config and roll it from the linux source package?  Is it just that the i386 build times are already unforgivably high?
[15:05] <infinity> Oh, wait.  I see a patch here, nevermind.
[15:06] <infinity> ... a 7-line patch.
[15:06] <apw> yick
[15:06] <apw> it was supposed to be config only, but yes separation is about the build times being mental already
[15:07] <apw> infinity, is there a package somewhere for that i can look at
[15:07] <apw> infinity, i want to make sure its not going to make a linux-libc-dev etc
[15:07] <scott-work> infinity: it is the same source as the -generic kernel but with some compile flags tweaked
[15:07] <infinity> scott-work: And a small patch.
[15:08] <infinity> apw: http://lucifer.0c3.net/~adconrad/made-kernel-irq-threaded-by-default.patch <-- The patch.
[15:08] <scott-work> infinity: i wonder if TheMuso added the patch, i was unware of it before
[15:08] <infinity> apw: http://revu.ubuntuwire.com/p/linux-lowlatency <-- The package.
[15:08] <scott-work> but admitedly my knowledge of kernels is rather limited
[15:09] <infinity> The patch seems like it could be skipped entirely by instead shipping a grub config snippet or something?
[15:09] <apw> infinity, ick, just to save having a grub config ?
[15:09] <infinity> apw: Jinx.
[15:09] <apw> *mumble* *mumble*
[15:10] <infinity> I could see extending the patch to it actually has a Kconfig option.
[15:10] <infinity> Then it might be upstreamable.
[15:11] <infinity> Or at least could be committed to the Ubuntu tree.
[15:11] <infinity> s/to it/so it/
[15:11] <apw> yep
[15:11] <apw> bah here are the actual packages from this silly tool
[15:12] <infinity> apw: The source is there.  It doesn't have binaries.
[15:12] <infinity> apw: The source is cleverly hidden under the heading "Files", in light grey text that I can't read.
[15:13] <apw> oh dammit, why do people insist on making their web pages 'cool' by changing the standard understandable markup of a damn link having _____ under it ... ARRRG
[15:13] <apw> hate hate hate
[15:13] <apw> especially as there are other links which are marked up ... sigh
[15:14]  * apw watches dpkg locking trip over itself
[15:14] <infinity> apw: My other obvious complaint would be that it should be a diff.gz against your 3.2.0.orig, rather than being a massive 100MB native package.
[15:15] <apw> cjwatson, somethign has changed in dpkg locking, i beleive the regular apt-daemon update is managing to get in between files in a dist-upgrade and disrupt it
[15:15] <dpm> thanks stgraber for the he.po change in pastebinit :)
[15:15] <apw> infinity, yeah it should be that no doubt
[15:15] <cjwatson> apw: er, dunno guv
[15:15] <stgraber> dpm: np
[15:15]  * cjwatson is neck-deep in writing ubiquity tests
[15:15] <apw> who is apt/dpkg god so i a can whine
[15:16] <infinity> apw: There's a req open for that position. :P
[15:16] <infinity> apw: (Not the answer you were hoping for?)
[15:16] <cjwatson> well, there will be.  eventually
[15:16] <cjwatson> in the meantime we bug mvo and hope he's around
[15:17] <infinity> dpkg locking is pretty primitive, mind you.  I'm curious how it could break as described.
[15:17] <apw> mvo, i suspect we have a lockig issue with apt, i have just had my second apt-get dist-ugrade die due to a conflicting lock
[15:17] <infinity> Unless something's decided it knows better and is actually stomping the locks.
[15:17] <apw> infinity, i manage to trigger it myself previously by doing an apt-get update in the background
[15:17] <apw> which it let me do, and broke the dist-upgrade badly
[15:18]  * infinity raises his brow.
[15:18] <infinity> Cute.
[15:18] <cjwatson> that's really not supposed to happen; it should refuse
[15:18] <apw> i know, that why i think the locking is broke
[15:18] <cjwatson> you're not running this on overlayfs? ;-)
[15:18] <infinity> Is overlayfs anywhere near this? :P
[15:18] <infinity> cjwatson: Jinx.
[15:18] <apw> i'll file a bug with this log, as this one i didnt do the conflicting command myself, i assume it was apt-daemon
[15:19] <apw> cjwatson, infinity, no thankfully, this is a real install
[15:22] <mvo> apw: what is the bugnumber?
[15:22] <infinity> mvo: I think the above was him verbally filing it.
[15:23] <apw> mvo, working on it
[15:23] <apw> launchpad is involved
[15:23] <cjwatson> For me: (1) if another apt-get update is running, then apt-get update fails with "Could not get lock /var/lib/apt/lists/lock"; (2) if apt-get dist-upgrade is running, then apt-get update updates the list files then fails with "Could not get lock /var/lib/dpkg/lock"
[15:24] <cjwatson> It doesn't seem to break the upgrade in either case, although I suppose you could argue that updating the apt lists with another apt process in flight is ambitious
[15:24]  * cjwatson files a bug report for infinity consisting only of pictures
[15:24] <infinity> Shouldn't do any harm, since the apt-in-progress doesn't need to read the lists.
[15:26] <infinity> cjwatson: Do you remember the scan of the printout of the xorg.conf?
[15:26] <apw> cjwatson, well the intersting thing is we are at the beginning of a phase in the dist-upgrade
[15:26] <infinity> Best.  Bug attachment.  Ever.
[15:26] <scott-work> apw: infinity:  is there a resolution on what direction the lowlatency kernel should take?
[15:26] <infinity> scott-work: I think apw was going to give it a quick eyeball.
[15:26] <apw> cjwatson, and it fails trying to take the lock, which implies it thinks it doesn't have the lock and needs it
[15:26] <apw> scott-work, yeah waiting on the download now
[15:27] <infinity> scott-work: Under the assumption that it can't be in the primary sources (and it can't, for now), my only immediate complaint is that it desperately needs to be re-packed to be non-native, using the same orig as the regular kernel.
[15:28] <infinity> scott-work: But that can be done when it's re-based to 16.25 and uploaded to the archive.
[15:28] <infinity> Perhaps I'll comment.
[15:28] <bdmurray> dobey: could you look at my lptools merge proposal?
[15:28] <dobey> sure
[15:30] <apw> mvo, bug #932822
[15:31] <infinity> apw: Having it fail before the dist-upgrade actually takes the lock isn't really a failure...
[15:31] <infinity> apw: Unless you're expecting apt to lock earlier to avoid annoying you.
[15:32] <apw> infinity, bah you are right, thats between the download and application, i had seen it further forward in my mind
[15:32] <infinity> apw: Although, that terminal log is weird.  I'd expect it to take the lock before the pre-config.
[15:32] <scott-work> apw: infinity:  thank you x10^e :)
[15:33]  * apw is confused now
[15:33] <apw> mvo, i am not sure if i expect this to work or not, so if its 'thats expected behaviour' do invalid it as you see fit
[15:34] <apw> as it does seem to be the first phase that fails here, though as infinity says i might have expected the error earlier
[15:34]  * infinity is tempted to do a drive-by bot update on apw's bug to point out that he's not running the current kernel.
[15:34] <apw> infinity, you have quite an evil streak
[15:35] <infinity> Lil' bit.
[15:35] <infinity> I haven't slept for a while...
[15:37]  * Daviey guesses infinity has been burned.
[15:37] <apw> ICE default IO error handler doing an exit(), pid = 17261, errno = 4
[15:43] <cjwatson> infinity: vaguely :)
[15:45]  * apw assumes gnome-session core-dumping would account for his being logged out
[15:45] <cjwatson> infinity: In a previous job, instead of sending us configuration files, somebody sent us a zip file containing screenshots of the web admin interface with the bits they thought we might find interesting circled using a paint program
[15:46] <SpamapS> pitti: lol.. mysql is innovative!
[15:46] <infinity> cjwatson: Sure, but that kinda makes sense, if the admin UI is how they interact with settings.
[15:46] <jamespage> does anyone have a nice way to calculate rebuild order for library transitions?  I want to run a test rebuild to evaluate openmpi 1.5 and not make it to hard...
[15:47] <infinity> cjwatson: On the other hand, finding /etc/X11/xorg.conf in gedit, printing it, scanning it, and attacting the image just blows my mind when you could have attached the text file...
[15:47] <infinity> s/attacting/attaching/
[15:47] <SpamapS> Hm.. unity-2d seems to have lost the ability to maximize windows via keyboard
[15:48] <infinity> SpamapS: More to the point, the reason mysql fails on x86 and nowhere else is because it should fail everywhere (testsuite is shorted with || true on !x86)
[15:50] <SpamapS> infinity: totally t3h awesome
[15:50] <SpamapS> I wonder why it didn't fail on my local build test
[15:51] <infinity> SpamapS: Dunno.  But maybe you've jumped the gun on assuming they actually fixed the gcc-4.6 issues. :(
[15:51] <infinity> SpamapS: (I'm hoping it's something simpler and more obvious when you poke at it, though)
[15:51] <SpamapS> infinity: no, I think I included an errant patch to try and not statically link the client
[15:52] <infinity> I'll be so excited that we get to kick out gcc-4.5 just in time to switch to gcc-4.7
[15:53] <SpamapS> hm no...
[15:54] <SpamapS> passed on retry.... weird
[15:55] <SpamapS> wait, the fails were different on i386 and amd64
[15:56] <SpamapS> oh my..
[15:57] <SpamapS> the test suite was.. ridiculously bad on armhf
[15:57] <apw> infinity, ok this package is sounding rather wonky, rtg is spinning an equivalent of it they way we do 'em for comaprison
[16:04] <mvo> mr_pouit: I updated the extraction code now to ignore X-XfceSettingsDialog category packages
[16:04] <infinity> apw: Thanks.  If the kernel team comes up with something you put a stamp of approval on and uploads it, I'll be happy to review it in NEW instead of making them go through another REVU cycle.
[16:06] <infinity> apw: And if any of you have some spare cycles to turn their patch into something with a Kconfig option, so they can stop carrying a source delta, that would be awesome.
[16:06] <apw> infinity, i think rtg will communicate with allessio on it
[16:06] <infinity> apw: Lovely.
[16:06] <mvo> apw: thanks! I'm a bit flooded in $stuff right now, but that looks like a bug
[16:12] <apw> mvo, i know how you feel, its that drowing in bugs time of the cycle, i've been logged out by two today already, which is no help productivity wise
[16:20] <cnd> slangasek, when I build a library against libx11-dev, it's not finding the XOpenDisplay and XCloseDisplay symbols at dpkg-shlibdeps time
[16:20] <cnd> the symbols exist in /var/lib/dpkg/info/libx11-6\:amd64.symbols
[16:20] <cnd> do you know what might be wrong?
[16:21] <SpamapS> infinity: indeed, we may have to move back to gcc 4.6 .. though I'm not sure why. :-/
[16:26] <slangasek> cnd: have't seen this, no.  is there a build log I can peruse?
[16:36] <slangasek> doko: speaking of eglibc, I noticed a strange thing when scanning precise for multiarch: same file collisions... apparently our libc6-dbg on armhf is using the wrong path?
[16:37] <doko> huh?
[16:37] <doko> looking
[16:37] <slangasek> doko: oh, no - the problem is that it seems to contain dbg symbols for *both* archs?
[16:38] <slangasek> so either it shouldn't contain biarch debug symbols, or it has to be not M-A: same
[16:39] <doko> ahh, the install file has /usr/lib, which works on the other biarchs, but not arm*
[16:40] <mr_pouit> mvo: thanks! Also, do you know why I can't find any xfce4-panel plugin in software-center? because they don't contain any desktop file?
[16:42] <mvo> mr_pouit: I guess so, I don't know much about the panel - but they should appear in technical items, no?
[16:44] <mr_pouit> mvo: mmh, I can't find them. Entering 'xfce' or 'xfce panel' in the search bar doesn't show any plugin (and there's no hidden technical hidden to expand)
[16:44] <mr_pouit> *technical item
[16:45] <cnd> slangasek, http://paste.ubuntu.com/843242/
[16:45] <lifeless> is today a good day to upgrade machines ?
[16:46] <SpamapS> infinity: before I go digging .. do you know why we decided to disable the test suite on non x86 arches?
[16:49] <hrw> Bug #932882 anyone?
[16:50] <slangasek> cnd: your libxorg-gtest.so.0 appears to not be directly linked against libX11
[16:50] <cnd> slangasek, I'm a little fuzzy on shared libs and direct linking
[16:50] <cnd> should it be linking directly>?
[16:50] <infinity> SpamapS: There was no "we", I think it was just laziness. :P
[16:50] <mvo> mr_pouit: I see a bunch of them, but it requires that you have apt-xapian-index installed (which you may not have)
[16:51] <mvo> mr_pouit: its pretty heavy on a slow system :/
[16:51] <cjwatson> pgraner: BTW that alsa-lib thing from earlier should be sorted now
[16:51] <infinity> SpamapS: I know !x86 has always thrown a few more errors than x86, I imagine it crossed the unacceptable threshold recently and someone just turned off the suite.
[16:52] <cnd> slangasek, ahh, I think I found the issue
[16:52] <slangasek> cnd: it uses libX11, so it should be linked against libX11 at build time
[16:52] <cnd> yeah
[16:52] <Daviey> infinity: I thought it shipped 386 asm code?
[16:52] <cnd> it's a bug upstream
[16:53] <infinity> Daviey: I'm sure it does, but I'd assume that's not used on !x86. :P
[16:53] <SpamapS> infinity: ok, seems like those bugs need to be reported and patched..its a little ridiculous. :p
[16:54] <pgraner> cjwatson, yep saw that thanks!
[16:54] <infinity> SpamapS: Yeah, no arguments here about reporting and/or fixing.
[16:55] <Daviey> infinity: right, i thought that was the headache of previous cycles.. was that it DID (try) :)
[16:55] <infinity> SpamapS: If there are a bunch that are arm (especially armhf) specific, you might be able to talk the Linaro folks into caring (see #linaro-armhf)
[16:56] <infinity> SpamapS: But the first step to reporting suite failures is to disable upstream's braindead "I've hit $threshold failures, so not running any more tests!" check.
[16:56] <mr_pouit> mvo: it's installed already, so i'm running update-xapian-index to see if it makes them reappear
[16:56] <mvo> ok
[16:57] <Daviey> infinity: in other news... did utlemming get to speak to you about bug 759545 ?
[16:58] <infinity> Daviey: Nope.  Can you poke me on your Friday (ie: when my work day is starting), and I'll make some time to actually give it a proper eyeball.
[16:58] <utlemming> Daviey: I'm here now
[16:58] <infinity> utlemming: Unless you wanted to steal the bug and run with it.
[16:58] <utlemming> sorry...what was the bug number?
[16:58] <infinity> https://launchpad.net/bugs/759545
[16:58] <Daviey> 16:57 < Daviey> infinity: in other news... did utlemming get to speak to you about bug 759545 ?
[16:59] <Daviey> infinity: thanks!
[16:59] <mr_pouit> mvo: now I've ~40000 items in software-center instead of ~2800, so I guess it worked (I'll retry a fresh install later to confirm it's ok). Thanks for your help.
[16:59] <utlemming> ah, I looked briefly at that bug yesterday...give me a minute
[17:00] <infinity> utlemming: I'm fading fast and approaching post-all-nighter-panic-nap-land.
[17:00] <infinity> utlemming: If you have stuff to add to the bug, post a bunch of comments. ;)
[17:00] <utlemming> infinity: will do
[17:00] <infinity> utlemming: If you have fixes (and/or want to fix it yourself), go nuts, and I'll be happy to review.
[17:01] <infinity> utlemming: Otherwise, see above, re: Friday. :)
[17:01] <mvo> mr_pouit cool
[17:08] <hallyn> jcastro: hey, mr unity workflow master :) - i understand and like how super-N gets me between banshee and ff, for instance.  but do you have tips on how to best, quickly pick one of my 8 xterms on varoius desktops?
[17:16] <tkamppeter> anyone here who can help me on a sync problem?
[17:17] <tkamppeter> I want to sync the "pnm2ppa" package with Debian, once Debian's package needs all our needs, and second, to get rid of a broken upstream source tarball.
[17:23] <kirkland> cjwatson: have we ever considered providing a command that would clean up (remove) old, unneeded kernels, either automatically or on demand?  (or does such a thing exist?)
[17:25] <kirkland> cjwatson: on a very long-running ubuntu machine (especially a server), you may have hundreds of MB tied up in old kernels
[17:25] <kirkland> cjwatson: once you've rebooted into one that works, it may be safe to purge old ones
[17:25] <cjwatson> kirkland: that was the point of computer-janitor
[17:25]  * kirkland looks at computer-janitor
[17:25] <cjwatson> (which at some point ought to become part of software-center)
[17:26] <cjwatson> tkamppeter: you won't be able to sync it until there's a new upstream version
[17:26] <kirkland> cjwatson: suitable for servers too?
[17:26] <cjwatson> kirkland: dunno
[17:26] <barry> computer janitor should die :)
[17:26] <cjwatson> yes; but that was its use case
[17:27] <cjwatson> or at least its primary one
[17:27] <kirkland> barry: :-)
[17:27] <SpamapS> Software developers, more than any other profession, are way too comfortable with killing their least favorite children.
[17:27] <kirkland> so we just received an email from a fairly large cloud hosting provider that's recommending all of their customers running Ubuntu run:
[17:27] <kirkland> dpkg --get-selections|grep 'linux-image*'|awk '{print $1}'|egrep -v "linux-image-$(uname -r)|linux-image-generic" |while read n;do apt-get -y remove $n;done
[17:28] <kirkland> and I face palmed
[17:28] <kirkland> I'm thinking we could/should do better as a distro
[17:28] <barry> SpamapS: i think it's just that they disappoint us so much more often
[17:29] <SpamapS> barry: and they don't bear that much resemblance either
[17:29]  * SpamapS *does* think that pipemeter is way too skinny to be his first born program
[17:30] <tkamppeter> cjwatson, so I suggest then for the meantime to put a samne source tarball under a new "upstream" version, like 1.13+dfsg and then drop in Debian's debian/ directory and add a debian/changelog entry explaining the mess.
[17:31] <cjwatson> tkamppeter: you're welcome to do such a thing, yes, although +dfsg conventionally indicates that the tarball has been stripped down to remove non-free elements
[17:32] <cjwatson> tkamppeter: however
[17:32] <kirkland> cjwatson: do you think it would be worth taking this discussion/suggestion (specifically about kernels) and computer-janitor and servers to ubuntu-devel?  Or would it just rehash old conversations?
[17:32] <cjwatson> tkamppeter: you might be better off using syncpackage -F (a.k.a. --fakesync) - see its docs
[17:32] <cjwatson> kirkland: well, it's not the first time it's come up by a long shot ...
[17:32] <tkamppeter> cjwatson, perhaps then better 1.13+1 or 1.13+non-dbs?
[17:32] <cjwatson> tkamppeter: or use syncpackage -F
[17:33] <kirkland> cjwatson: well, service providers are now recommending customers run some pretty gross hacks to work around this
[17:33] <kirkland> cjwatson: i guess that's what's new hear
[17:33] <cjwatson> the effect of that is to upload the same contents as the Debian source package but with the current orig tarball in Ubuntu
[17:33] <cjwatson> kirkland: not new at all
[17:33] <kirkland> cjwatson: painful to watch that go down, from my perspective
[17:33] <tkamppeter> cjwatson, tried already --fakesync, but failed. Should I paste the output?
[17:34] <cjwatson> tkamppeter: sure
[17:35] <cjwatson> (but into paste.ubuntu.com, not the channel)
[17:35] <cjwatson> kirkland: it's probably best to talk to the software-center developers if you want to try to move it forward
[17:35] <cjwatson> though I don't know what they think of server use cases
[17:35] <kirkland> hmm, computer-janitor doesn't look immediately functional in a server environment
[17:35] <kirkland> ERROR:dbus.proxies:Introspect error on :1.3:/: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send mes
[17:35] <kirkland> sage, 1 matched rules; type="method_call", sender=":1.6" (uid=0 pid=20204 comm="/usr/bin/python /usr/sbin/computer-janitor find ") inter
[17:35] <kirkland> face="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.3" (uid=0 pid=19
[17:35] <kirkland> 905 comm="/usr/bin/python /usr/share/computerjanitor/janitor")
[17:36] <kirkland> cjwatson: thanks;  who are the software-center developers?
[17:37] <cjwatson> kirkland: https://wiki.ubuntu.com/SoftwareCenter
[17:37] <kirkland> cjwatson: thx
[17:38] <tkamppeter> cjwatson, will do, just a minute.
[17:38] <cjwatson> I'm also surprised that (in theory anyway) apt-get autoremove couldn't do the same thing
[17:39] <slangasek> "remove all but the current and most recent kernel" is a bit beyond what apt-get autoremove can do itself currently
[17:39] <cjwatson> mm
[17:40] <mdeslaur> @pilot out
[17:40] <mdeslaur> bah
[17:40] <mdeslaur> dholbach: ^
[17:40] <tkamppeter> cjwatson, http://pastebin.ubuntu.com/843314/
[17:41] <dholbach> mdeslaur, I asked in #ubuntu-irc if somebody can help
[17:41] <dholbach> mdeslaur, I don't have the keys to it
[17:41] <cjwatson> that seems to be a problem with the pnm2ppa package in Debian itself ...
[17:42] <mdeslaur> infinity: could you remove me from the topic pleeeeze?
[17:43] <cjwatson> though can't say I can immediately work out what
[17:44] <Laney> mdeslaur: you can remove yourself; the topic in here isn't protected (unless that's what C or z do)
[17:44] <cjwatson> oh, I see, it's getting confused by the Ubuntu tarball being tarball-in-tarball packaging, how gross
[17:44] <cjwatson> maybe you can't syncpackage this after all
[17:45] <mdeslaur> Laney: hehe, thanks
[17:45] <cjwatson> I think your only choices are (1) just manually sync in the packaging changes you want (2) persuade Debian to artificially bump the upstream part of the version
[17:45] <mdeslaur> infinity: never mind :)
[17:48] <tkamppeter> cjwatson, this DBS is really crazy. It was one of my predecessors who packaged that way. I will remove it by using a renamed source tarball.
[17:48] <smoser> well, i'm not going to bother contributing anything eles to the "get rid of all kernels", but this seems reasonable and generally safe to me:
[17:48] <smoser> list_removable_kpkgs() { dpkg -l | awk '$2 ~ /^linux-[a-z]+-[23][.][0-9].[0-9][.0-9]*-[0-9]+/ && $2 !~ cur { print $2 }'  cur="linux-[a-z]+-$(uname -r)" ; }
[17:49] <cjwatson> tkamppeter: yes, DBS is awful
[17:51] <smoser> i guess you'd also want it to filter out newest.
[17:57] <jtaylor> barry, doko: will you still have a look at the numpy merge before ff?
[17:59] <barry> jtaylor: i can look at it today.  can you paste some links?
[17:59] <jtaylor> barry: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-1.6/+merge/92671
[18:08] <SpamapS> hm
[18:08] <SpamapS> retrying the amd64 tests passed.. but I'm not sure thats exactly a good thing
[18:11] <herton> @pilot in
[18:23] <tkamppeter> cjwatson, thank you very much. New pnm2ppa package is uploaded now.
[18:41] <doko> jtaylor, barry: does this come with at least scipy updated as well?
[18:41] <jtaylor> no scipy has not been updated in debian yet
[18:41] <jtaylor> for to little time do that in ubuntu only now
[18:49] <scott-work> apw: i apologize for being a pest, but do you have an eta for checking the -lowlatency kernel?  i'm concern with having enough time to make changes (which might not be made by me) in time for the feature freeze
[18:57] <doko> jtaylor, does the old scipy work with the new numpy?
[18:57] <jtaylor> numpy 1.6 was released 6 month before scipy .10 so I hope so
[18:58] <doko> could you just rebuild it to be sure?
[18:58] <jtaylor> doko: I did already, all rdepends build
[18:58] <hallyn> if package a has build-depends: b, and b has Depends: c, will c be installed by apt-get build-dep a?
[18:58] <jtaylor> I also checked the arch all depends for the minor api removals
[18:58] <doko> ok, thanks
[18:59] <jtaylor> doko: only 2 affected, one easy to fix one fixed already in unstable (going to merge soon)
[18:59] <jtaylor> doko: numpy 1.6 is abi compatible with 1.5 but there is a new dh_numpy so I want to rebuild the arch any packages anyway
[19:00] <micahg> hallyn: should be, but I suggest sudo mk-build-deps -i -r unless you're in a chroot you don't care about
[19:02] <hallyn> micahg: well, what i really meant was - will that be enough for the buildd to install package c while building a?
[19:02] <micahg> hallyn: yes, but if your package needs it specifically, you should build-depend on it
[19:02]  * hallyn looks up mk-build-deps, sounds interesting
[19:03] <doko> apw, ogasawara: I'll need one more gcc-4.6 upload tonight, fixing a regression with the last upload
[19:03] <ogasawara> doko: ack, that should be fine
[19:03] <hallyn> ok, thanks.  well, is that something debian would agree with (and accept a patch for)?
[19:04] <micahg> hallyn: generally, yes, but it's only RC severity if it currently fails to build in Debian without it
[19:04] <hallyn> micahg: ok, thanks
[19:43] <hallyn> doko: do you have any plans on further eglibc updates?  I'm looking at bug 930181 , not sure whether i should work around it with a #define, or wait
[19:45] <doko> hallyn, I don't have any plans. di you talk with the kvm Linaro guys?
[19:46] <hallyn> thanks. no, i didn't.  yet.
[19:46] <hallyn> slangasek: lool: ^ have you guys seen the AT_EMPTY_PATH failure when qemu-linaro builds?
[19:47] <hallyn> (it's in the 9p virtio code, so you might not enable that...)
[19:47] <slangasek> hallyn: yes
[19:47] <slangasek> wait, maybe that's not the one I'm thinking of
[19:48] <slangasek> hallyn: no, what I've seen is this failure when you mentioned it to me the other day - sorry :)
[19:48] <hallyn> lol - i didn't remember asking you before.  ok, thanks.
[19:48] <hallyn> i guess i can just work around it with a #ifndef #ifdef...
[20:02] <lifeless> heh
[20:02] <lifeless> libc:i386 wants to restart services... why?
[20:04] <cjwatson> because the code that asks that question hasn't checked whether it's running for a foreign architecture or not
[20:05] <slangasek> yes, and it's not entirely clear to me how it should do so
[20:05] <slangasek> (the one I enjoyed was libc6:armel restarting services)
[20:07] <hallyn> doko: let me try one more time.  The core problem is that /usr/include/asm-generic/fcntl.h and /usr/include/x86_64-linux-gnu/bits/fcntl.h cannot be sourced at the same time.
[20:08] <hallyn> they have conflicting definitions of several structs
[20:08] <hallyn> I can work around it, mind you, but is that going to be a problem for more people?
[20:09] <slangasek> hallyn: what's the path by which /usr/include/asm-generic/fcntl.h is being pulled into your code?
[20:09] <slangasek> given that this is a kernel header
[20:09] <hallyn> slangasek: if i want AT_EMPTY_PATH, i need to #include <linux/fcntl.h>
[20:09] <hallyn> that's how it happens
[20:09] <slangasek> ah
[20:09] <hallyn> so i can just #define it by hand, but i don't want to work around something that's going to get worse for other people...
[20:09] <slangasek> well, so, the kernel is responsible for making sure any structs it exports to userspace via linux-libc-dev are actually compatible™
[20:10] <slangasek> and while it's not good to have this sprung on us suddenly like this, in general if the struct definitions don't match, it's a kernel bug, not an eglibc bug
[20:10] <slangasek> because eglibc owns the namespace here
[20:11] <hallyn> slangasek: so i should open a bug against linux, then?
[20:11] <slangasek> I think so
[20:11] <hallyn> great, will do - thanks
[20:20] <cjwatson> slangasek: libc6:foreign> isn't that just a matter of substituting DEB_HOST_ARCH into the maintainer script and then comparing against dpkg --print-architecture at install time?
[20:21] <slangasek> cjwatson: if we assume that services installed are all of the primary architecture
[20:21] <slangasek> I wasn't prepared to make that assumption
[20:34] <cjwatson> slangasek: but, given the multiarch constraints, if you install a new libc6:foreign at any point then you must either have just installed a new libc6:primary or be about to do so
[20:35] <slangasek> cjwatson: oh yes!
[20:35] <cjwatson> and by the time you get to libc6:foreign.postinst, libc6:primary should be at least unpacked, IIRC
[20:35] <slangasek> good point
[20:35] <cjwatson> (though check that assumption, I can't remember how it works with immediate configuration)
[20:37] <cjwatson> I suppose it's possible that it goes libc6:primary unpack, libc6:primary configure, libc6:foreign unpack, libc6:foreign configure, which would break my assumption
[20:37] <lifeless> slangasek: nice (libc6:armel)
[20:38] <slangasek> cjwatson: dpkg doesn't allow configuring m-a: same packages unless they're both unpacked at the same version :)
[20:40] <cjwatson> slangasek: hooray
[21:23] <barry> jtaylor: i'm just doing a few local test builds but if those sanity check okay, i'll upload your numpy 1.6 branch in a little bit
[21:23] <barry> (and get rebuilds of the 18 failures)
[21:23] <jtaylor> barry: great thanks
[21:23] <jtaylor> 18 failures?
[21:24] <barry> er, not failures: http://people.canonical.com/~ubuntu-archive/transitions/numpy.html
[21:24] <micahg> jtaylor: is the multiarch change folded in to the 1.6 migration?
[21:24] <jtaylor> micahg: yes
[21:24] <barry> jtaylor: i'm just the monkey pushing the buttons.  thank *you* for all your great work pushing this forward
[21:24] <jtaylor> barry: I can do the universe rebuild
[21:25] <jtaylor> did them all locally already, all succeed
[21:25] <jtaylor> veusz needs special attention
[21:25] <barry> jtaylor: fab!  okay, i'll push numpy now then.  ping me if you need anything else
[21:26] <barry> jtaylor: in case you're interested, i cannot bzr merge your branch into ubuntu:python-numpy.  bzr crashes.  yes, i should report that ;)
[21:26] <barry> jtaylor: but i did diff locally and looked at the debian/ diffs.  they looked sane to me
[21:28] <barry> jtaylor: uploaded
[21:28] <jtaylor> thx
[21:28] <jtaylor> too bad I didn't find the time for py3 :(
[21:29] <barry> ah well, there's always qwazy quahog
[21:30] <jtaylor> rejected :(
[21:32] <barry> gar
[21:34] <broder> barry: awesome, i was debating bothering you to look at the numpy merge :)
[21:36] <barry> broder: good thing you waited, otherwise i would have stolen all of jtaylor's rightfully earned kudos :)
[21:37] <SpamapS> anybody else want to weigh in on whether or not we should update Erlang to R15B vs. the current R14B4 ?
[21:37] <SpamapS> upstream says that R15B is the bees-knees
[21:39] <jtaylor> considering the load of the buildd's should I wait with the no change rebuilds for numpy?
[21:39] <jtaylor> at least until the test build is done on arm?`
[21:39] <YokoZar> cjwatson: Can I poke you ~ https://bugs.launchpad.net/ubuntu/+source/dssi-vst/+bug/925127   (deleting the old wine packages) since you last touched wine1.4 :D
[21:40] <barry> jtaylor: dunno, might be worth getting them into the queue.  i'm depwaiting on several arm builds myself
[21:41] <jtaylor> I just saw in the ghc bug that -release asked for them to wait until its done
[21:41] <jtaylor> though ghc are 470 packages not 18 ;)
[21:41] <tumbleweed> jtaylor: ghc is way nastier than numpy
[21:41] <barry> oh, definitely get it in the queue now then :)
[21:41] <broder> haha
[21:42] <micahg> jtaylor: load on buildds isn't heavy
[21:42] <broder> micahg: the armhf buildds have a 2-day queue
[21:42] <micahg> it's all rebuilds save for powerpc
[21:42] <Laney> mmmmm tasty ghc
[21:42] <micahg> broder: that's the test rebuild, ignore it :)
[21:42] <broder> jtaylor: so https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/multiarch-fix-818867/+merge/87165 can be rejected at this point, right?
[21:42] <jtaylor> broder: yes
[21:43] <tumbleweed> Laney: btw, my pypy 1.8 upload is currently stuck in Debian binNEW. I'll probably be asking for an FFe on the weekend
[21:43] <broder> jtaylor: would you mind? i don't have my lp creds on me at the moment
[21:43] <Laney> ^o)
[21:43] <Laney> does it build on arm yet?
[21:43] <jtaylor> broder: I can only set it merged or wip
[21:43] <tumbleweed> I built it on debian porterboxes. Only took a couple of days (and got me comments from DSAs in #debian-devel about load :P )
[21:44] <jtaylor> merged is kind of right so should I do thaT?
[21:44] <broder> jtaylor: merged isn't really inaccurate
[21:44] <broder> i'd go with that
[21:44] <Laney> heh
[21:44] <Laney> so, not on the buildds yet?
[21:44] <tumbleweed> when we get arm buildds with >2G RAM then it'll be good
[21:44] <micahg> well, the problem with ghc on arm is ghc-ghci
[21:45] <tumbleweed> possibly on debian buildds with 1.5G. I don't think Ubuntu has any that big
[21:45] <Laney> that is one of the problems
[21:45] <broder> whoo! sponsor queue now has nothing more than...34 days old! :)
[21:47] <infinity> Laney: Oh, do you happen to know the status of ghci on arm?
[21:47] <Laney> Still doesn't work, but at least 7.4 has registerised arm builds
[21:48] <infinity> Laney: Is there any work being done on it, or just a bunch of people asking?
[21:49] <Laney> Yeah I think there is some work being done; there's an infrequently updated blog at http://ghcarm.wordpress.com
[21:53] <tumbleweed> barry: forget -v with numpy? :)
[22:09] <barry> tumbleweed: ?
[22:12] <tumbleweed> barry: when merging we use -v[previous ubuntu version] so that all the intermediate debian changelog entries are included in the .changes file
[22:13] <barry> tumbleweed: yeah, there have been some bugs in udd about that.  i should go back and look to see if they've been fixed or not
[22:13] <tumbleweed> ah, you should be able to pass that to bzr bd after a --
[22:13] <tumbleweed> but yes, it'd be nice if it did it automatically
[22:14] <barry> right, it's *supposed* to do it automatically ;)
[22:14] <micahg> yes, but one should verify the source.changes file before dputting :)
[22:14] <barry> very true. i did look, but should have been more careful
[22:15] <tumbleweed> that's helped me catch a few mistakes (and I've also forgotten to check a few times and missed them :P )
[22:15] <micahg> at least until it's 99.9% foolproof :)
[22:15] <micahg> even then though, I find it helpful to catch mistakes as tumbleweed said
[22:16] <barry> ah, okay, it's still in "new" state (bug 788349) so i will get it through my thick skull not to count on it
[22:18]  * micahg discussed with jelmer at the rally, but it seems that bzr-builddeb isn't the ideal place for the fix for this
[22:37] <broder> barry: any reason for me not to upload tumbleweed's fix for bug #915167? i'll do some quick testing, but it looks trivially and obviously correct
[22:41] <tumbleweed> broder: thanks
[22:50] <broder> tumbleweed: ugh, is python-defaults a debian-native package with a debian revision number?
[22:51] <tumbleweed> yup. it kinda makes sense, though
[23:03] <slangasek> smoser: hi, did you have a chance to check out the new upstart?
[23:11] <broder> tumbleweed: for what it's worth, it looks like the python2.7 postinst has a similar problem with preferring the python2.7 in your path
[23:15] <tumbleweed> broder: so it does
[23:15] <broder> i don't know whether that's still the case and how worth fixing that is
[23:16] <tumbleweed> seems to still be the case, /me plays a bit
[23:18] <broder> anyway, i'll still go ahead and upload the python-defaults change, since it seems correct
[23:20] <tumbleweed> broder: so, a locally built cpython (2.7.0) installed in /usr/local doesn't break the postinst
[23:21] <broder> printf '#!/bin/sh\nexit 1' >/usr/local/bin/python2.7 does
[23:21] <tumbleweed> yes, but that was a pretty evil test :)
[23:22] <broder> why did it break with a real cpython in /usr/local?
[23:24] <tumbleweed> I'm assuming because the postinst has the full path to py_compile.py, and it's the locally built python's py_compile.py that is missing features we need
[23:24] <broder> ok. i'm just thinking - doesn't debian policy have something to say about not using absolute paths in maintainer scripts?
[23:24] <broder> i'm wondering if this change runs afoul of that
[23:24] <tumbleweed> yes http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[23:25] <tumbleweed> but this is obviously the correct thing to do here (my proposed patch)
[23:25] <broder> ok. good enough for me