[00:26] <Logan_> When I'm patching a package, do I need to update the series file in debian/patches, or will the package maintainer do that after merging?
[00:28] <jelmer> hi Logan_ ; if you're adding a file in debian/patches it's usually a good idea to update the series file too
[00:28] <Logan_> Aw, okay. :-P I already proposed it for merging. :-(
[00:28]  * Logan_ fixes.
[00:28] <Logan_> My first patch, so I have no idea what I'm doing. :-P
[00:29] <Logan_> (Well, hopefully some idea.)
[00:29] <jelmer> Logan_: it's not the end of the world, I'm sure whoever reviews it knows how to update the series file too :)
[00:35] <penguin42> I'd love to know why flash pauses when I boot a vm
[03:17] <clausen> how can I figure out the CFLAGS used to build a .deb?
[05:57] <hyperair> hmmmm how is this multiarch arch:all dependency supposed to work?
[05:57] <hyperair> i tried to install acroread:i386, but it's trying to pull in acroread-common:i386 which doesn't exist because acroread-common is arch:all.
[05:57] <hyperair> so i rebuilt it setting Multi-Arch: allowed as mentioned in the multiarch spec...
[05:58] <hyperair> but that doesn't seem to satisfy dpkg.
[05:59] <imbrandon> arch:all and arch:any are not the same i think you may want the other
[06:00] <ScottK> Try installing acroread-common acroread:i386
[06:00] <hyperair> ScottK: aha, i see it. it's supposed to be Multi-Arch: foreign, not Multi-Arch: allowed.
[06:00] <hyperair> Multi-Arch: allowed merely permits Depends acroread-common:i386
[06:01] <hyperair> or something
[06:01] <hyperair> ScottK: and you need Multi-Arch: to be defined on arch:all packages now.
[06:01] <hyperair> https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
[06:02] <ScottK> Oh.
[06:04] <hyperair> which.... i haven't defined on my multiarch library packages =
[06:04] <hyperair> =\
[06:04] <hyperair> we should have an MBF for this or something..
[08:49] <vibhav> Shall I cereate a patch or sync python-scipy? https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/655192
[08:49] <vibhav> create*
[08:49] <vibhav> FYI, the package is unseeded
[08:50] <Laney> what else would be in the sync?
[08:50] <micahg> tons of rdeps
[08:51] <vibhav> http://pastebin.ubuntu.com/940778/
[08:51] <micahg> well, not tons, but quite a few :)
[08:51] <vibhav> yes
[08:51] <Laney> very informative changelog there
[08:52] <vibhav> why?
[08:52] <Laney> it doesn't say why any of the changes were made
[08:52] <vibhav> ah, sarcasn :)
[08:52] <vibhav> sarcasm*
[08:53] <Laney> :P
[08:53] <vibhav> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651760 might help you
[08:53] <Laney> oh, it's got a new upstream too
[08:54] <vibhav> But isnt the bug a problem with the debian packaging files?
[08:54] <Laney> if you sync you get everything
[08:54] <Laney> i'm trying to answer your question
[08:54] <vibhav> ah
[08:55] <vibhav> Lets get a sync then
[08:55] <vibhav> thanks
[08:56] <Laney> i didn't say that. looks like at least the Ubuntu diff would still be required (so, a merge)
[08:57] <vibhav> why would a ubuntu diff be required?
[08:57] <Laney> have a look at our changelog and you can see what it is
[08:57] <Laney> I think doing the minimal change is going to be safer
[08:59] <vibhav> you mean adding the python3 packages?
[09:00] <Laney> adding the new recommends
[09:00] <Laney> but jtaylor didn't just upload it (instead forwarded the bug) so perhaps it isn't worthwhile
[09:02] <vibhav> fine
[09:02] <vibhav> Ill do the minimal change
[09:06] <vibhav> Also, should I add it as a build-depend or a recommended package?
[10:54] <vibhav> could anybody nominate https://bugs.launchpad.net/bugs/655192 for supported Ubuntu releases?
[10:58] <jtaylor> I don't think its really SRU worthy
[11:03] <vibhav> jtaylor: why?
[11:03] <jtaylor> its a minor bug easily fixed by the user
[11:04] <vibhav> since we are fixing it for precise, might as well get the fix in other versions
[11:04] <jtaylor> SRU's are considerably more work than fixes in precise
[11:04] <vibhav> ah
[11:04] <vibhav> Then what about a backport?
[11:06] <jtaylor> also not really enough for a backport, though backporting 0.10.1 from Q might be a good idea
[11:06] <jtaylor> its a bit late to add that to precise now
[11:07] <vibhav> ah
[11:07] <vibhav> Well, Ill keep it for U+1 then
[11:24] <vibhav> jtaylor: Is that fine?
[11:24] <jtaylor> vibhav: we could fix it for precise, if my numpy branch gets merged we could add dh_numpy3 usage too
[11:32] <vibhav> jtaylor: Could you give me the link to your branch?
[11:33] <jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-8/+merge/102970
[11:38] <Laney> it's seeded. I'm not sure that it will get in.
[11:38] <jtaylor> yeah I guess its to late, but then we merge it in Q
[11:38] <jtaylor> its on no image though
[11:40] <Laney> yeah it is
[11:40] <Laney> ask seeded-in-ubunbut
[11:40] <Laney> or a correctly spelled variant thereof
[11:41] <jtaylor> oh it got on the dvd :O
[13:15] <raffa50> hello. what is the command for rebuilding source. i want to upload it on launchpad
[13:35] <hyperair> hmm why do we have gccgo from gcc 4.7, but not gcc 4.7? =(
[14:07] <raffa50> hello. what is the command for rebuilding source. i want to upload it on launchpad
[14:09] <cjwatson> what exactly do you mean?  Launchpad PPAs will build a source package into a binary package for you ...
[14:09] <cjwatson> could you clarify?
[14:10] <cjwatson> hyperair: probably because introducing all of gcc 4.7 would involve an updated libgcc1
[14:10] <hyperair> cjwatson: ah, that sucks.
[14:11] <cjwatson> raffa50: perhaps https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage will help you
[14:36] <clausen> I think Ubuntu 11.04 has a miscompiled ssh
[14:36] <clausen> it is giving me failed MAC codes, and the openssh source code states that this is a well-known problem
[14:37] <clausen> when compiling with gcc optimizations enabled (-O2)
[14:37] <clausen> so it's important to compile the MAC bit without optimizations
[14:37] <clausen> I only just started getting problems, so I guess I'd like to trace the build history of the package
[14:37] <clausen> is there a good way to do thsi?
[14:38] <clausen> (can I see how each package was built, the history of packages uploaded, etc.?)
[14:44] <ScottK> clausen: https://launchpad.net/ubuntu/+source/openssh/+publishinghistory
[14:46] <clausen> ScottK, thanks!
[14:48] <clausen> ScottK, so how can I see the CFLAGS?
[14:48] <ScottK> Should be in the build logs.
[14:49] <clausen> aha
[14:55] <clausen> it is indeed compiled with -O2
[14:55] <clausen> although the source only complained about -O3 and higher...
[14:56] <clausen> looks like I'm going to have to do some more digging!
[14:56] <clausen> is it possible to get the object files from the build?
[14:58] <cjwatson> clausen: I see no such claim in the openssh source code.  Where do you see it?
[14:59] <cjwatson> It says you sometimes get incorrect results with -O3, not with -O2.
[14:59] <cjwatson> And we don't use -O3.
[14:59] <cjwatson> (I guess you mean the header comment in umac.c)
[14:59] <clausen> cjwatson, yes, you are right
[14:59] <clausen> nevertheless, the code doesn't work for me
[14:59] <clausen> yes, umac.c
[14:59] <clausen> I regularly get corruption messages
[14:59] <clausen> so perhaps something else changed (eg: gcc moved some items from -O3 to -O2)
[14:59] <cjwatson> I don't remember ever seeing those when I was running 11.04
[15:00] <clausen> it only just started recently
[15:00] <clausen> (I'm still using 11.04 on my machine...
[15:00] <cjwatson> Are you sure it isn't a problem on the server side?
[15:00] <clausen> it started getting regular corruption about 2 weeks ago)
[15:00] <clausen> yes, I have no trouble if I use dropbear instead of openssh
[15:00] <clausen> (on the client side)
[15:00] <cjwatson> After all, it's warning about a transport problem
[15:00] <cjwatson> That might not signify
[15:00] <clausen> I agree, it's not 100% evidence
[15:01] <cjwatson> They're sufficiently different in other ways that they might not tickle the same server bugs
[15:01] <clausen> but I would like to get to the bottom of this...
[15:01] <clausen> (the way umac's are used shouldn't make a difference though...
[15:01] <cjwatson> I suppose you could try building 12.04's openssh as a starting point for comparison
[15:01] <clausen> ... it's a very simple interface)
[15:02] <clausen> cjwatson, well, I could recompile myself (11.04) to see if it works :)
[15:02] <clausen> I will do that
[15:02] <cjwatson> Yes, though I'd be surprised if that changed anything
[15:02] <clausen> different gcc?
[15:02] <cjwatson> Will it in fact be?
[15:02] <clausen> you would know better than me :)  i don't know how the build machines are configured
[15:02] <cjwatson> Last openssh upload to natty was 1 April 2011, not that far from release
[15:03] <clausen> oh
[15:03] <clausen> that's odd
[15:03] <clausen> good point
[15:04] <cjwatson> There were a few gcc-4.5 changes since then, but I wouldn't have expected major code gen fixes, though it would depend on your architecture
[15:05] <clausen> ok, that's a puzzle then, why I am suddenly getting MAC corruption
[15:05] <clausen> since the binary didn't change for a year
[15:05] <clausen> I guess I jumped to conclusions when I saw the comment in umac.c
[15:05] <cjwatson> Well, that's why I'm suggesting it might not be a problem in that binary :-)
[15:05] <cjwatson> Nightmare to track down, though, I'm not experienced in that particular part of openssh
[15:06] <cjwatson> What architecture is this, anyway?
[15:06] <clausen> come to think of it, it might be the server side
[15:06] <clausen> x86
[15:06] <clausen> (intel)
[15:06] <cjwatson> OK, so shouldn't have been any relevant compiler changes
[15:06] <clausen> the time-frame is similar to when I upgrade the server from 10.10 to 12.04 beta
[15:06] <cjwatson> You could try winding back recent library upgrades if you still think it might be a client bug
[15:07] <cjwatson> There was an eglibc update in natty a month and a half ago or so
[15:07] <clausen> hmmm
[15:07] <cjwatson> Or an openssl update a few days ago
[15:07] <cjwatson> Bit tenuous
[15:08] <clausen> I'm wary about winding back, because this particular machine is a "secure" machine
[15:08] <clausen> (I guess I could clone it, and work off the clone...)
[15:08] <clausen> (but that's a lot of work!)
[15:08] <cjwatson> Another thing you could try is building 10.10 and 12.04 chroots on the server and starting sshd instances there on spare ports
[15:09] <clausen> yes
[15:09] <cjwatson> So that you can compare a bit more accurately
[15:09] <clausen> that's a good idea
[15:09] <cjwatson> Then possibly bisect at least at the level of uploads
[15:10] <clausen> in fact, I still have 10.10 on another partition, so I can chroot to that ;)
[15:10] <clausen> yes
[15:10] <cjwatson> debootstrap's easy enough if not
[15:10] <clausen> very good suggestion
[15:10] <clausen> thanks
[15:10] <cjwatson> good luck ...
[15:10] <clausen> thankyou :)
[15:12] <cjwatson> To answer your earlier question, the object files from the build are discarded, although you might find some debug symbols on ddebs.ubuntu.com if it happens to have a matching version
[15:12] <cjwatson> (That service isn't desperately robust and it does sometimes not have matching versions)
[15:22] <dupondje> Still allowed to do bugfix uploads?
[15:22] <cjwatson> to unseeded packages in universe, yes
[15:22] <cjwatson> otherwise ask the release team
[15:23] <dupondje> https://launchpad.net/ubuntu/+source/remmina => scrolling is broken in rdp connections. Because of GDK_SCROLL_SMOOTH.
[15:25] <cjwatson> that's on the desktop CD (among others) and it doesn't sound like a showstopper - I'd recommend an SRU
[15:26] <dupondje> I'll prepare an SRU then :)
[15:26] <dupondje> Good to have it fixed still. Quite annoying issue (for me at least ;))
[16:36] <raffa50> hello. what is the command for build the package of debian? i need to upload my software on launchpad
[16:44] <astraljava> raffa50: Did you not understand the previous instructions? You don't need to build locally in order to use a PPA.
[16:45] <astraljava> raffa50: https://help.launchpad.net/Packaging/PPA
[16:52] <vibhav> Since only 5 days are left for 12.04 , should we fix https://bugs.launchpad.net/ubuntu/+source/sivp/+bug/879097 in Ubuntu directly?
[16:52] <vibhav> instead of getting it first into Debian?
[16:52] <raffa50> uhm i found
[17:02] <jtaylor> vibhav: do you have a working patch?
[18:38] <ScottK> vibhav: Yes.
[18:51] <nigelb> Do we have a name for Q yet?
[18:55] <arand> nigelb: Don't think so, but it's generally around this time it gets announced iirc
[18:55] <nigelb> arand: It's far far later than normal. :)
[18:56] <nigelb> I wonder if sabdfl is saving it for the UDS opening keynote ;)
[19:01] <micahg> cjwatson: what do you think of removing packages that FTBFS in the rebuild on all archs that have been removed from testing?
[19:01] <micahg> cjwatson: oh and have no rdeps
[19:02] <arand> nigelb: Might just be very hard to find positive adjectives on Q...
[19:03] <nigelb> arand: HA. lol.
[19:12] <penguin42> arand: Quintessential Quetzalcoatlus, obvious really
[19:13] <nigelb> penguin42: haha
[19:15] <penguin42> nigelb: I know Mark always likes things that are easy to spell and type
[19:18] <nigelb> penguin42: yeah. he does care for us developers
[19:18] <nigelb> who have to type it out many times ;-)
[19:19]  * penguin42 is still just bitter that PP isn't penguin
[19:20] <penguin42> oh, nested KVM seems to work nicely on PP; I've just booted a OO VM on a PP server running on a PP host
[19:21] <penguin42> and given the number of impossible things I've done this weekend I should give up now :-)
[19:31] <ScottK> oneiric was not easy to type at first.
[19:32]  * tumbleweed is hoping for a quirky quagga - quirky is a great name for a post-LTS release :)
[19:40] <jtaylor> well it falls into debian freeze
[19:40] <jtaylor> so it won't be so bad
[19:41] <ScottK> I'm sure we'll invent plenty of crack on our own.
[19:42] <ScottK> Qwality Quail
[19:43] <ScottK> http://dilbert.com/strips/comic/1996-06-11/ comes to mind.
[19:44] <jtaylor> ^^
[19:44] <tumbleweed> :)
[19:53] <cjwatson> micahg: I'm gradually fixing or removing anything that has out-of-date binaries as a result of build failures.  I expect most of the packages in your category would be sane to remove, but I'd like to apply some case-by-case judgement all the same
[19:55] <cjwatson> out-of-date binaries are more urgent IMO
[20:00]  * ScottK doesn't understand why all the axiom binaries on the the outofdate list.
[20:00] <cjwatson> YM from architectures that built?
[20:01] <micahg> powerpc is behind
[20:01] <cjwatson> They're probably arch all.  LP nowadays keeps arch all around until there are no arch-specific binaries from the same version, to try to reduce skew-induced damage.
[20:01] <Laney> it's the arch:all binaries being held because of the FTBFS
[20:01] <cjwatson> Fix or remove the arch-specific ones, and the arch all binaries will be dominated away on the next publisher run.
[20:02] <micahg> where's this out of date list?
[20:03] <Laney> http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt
[20:03] <Laney> and s/testing/testing-ports/
[20:03] <micahg> meh, I've added 2 to the list apparently
[20:03] <cjwatson> it's about half the length it was on Friday :)
[20:03] <cjwatson> it does fluctuate a bit
[20:04] <cjwatson> one of these days I must add a currently-building indication to it
[20:17] <ScottK> It definitely looks much better than the last time I looked at it.