[00:28] <micahg> is anyone having trouble apt-pinning in karmic?
[02:52] <icarus_> Could someone offer a quick tip ? I'm packaging via debhuild which rounds off by calling lintian which seems particularly fussy about even the slightest of things (*sigh*). I keep getting this: 'source: source-nmu-has-incorrect-version-number 3.4' and I know it's got to do with adding a minor package version number, but where ? to what ?
[02:53] <ajmitch> what have you got as the version number in debian/changelog?
[02:53] <icarus_> 3.4, nothing else. Is this where I need to add the minor packaging version number ? Seeing as it's the first package it would be 3.4-0.1 ?
[02:54] <lifeless> icarus_: so, the fact its an NMU is alarming
[02:54] <lifeless> icarus_: as we don't do NMUs in ubuntu
[02:55] <ScottK> icarus_: 3.4-0ubuntu1
[03:31] <maxb> ScottK: not 3.4ubuntu1 ?
[03:32] <ScottK> maxb: Not unless it's a native package which is almost certainly not the case here.
[03:33] <maxb> oh, I was assuming the lack of hyphen in the lintian message meant it was native
[03:33] <ScottK> No it meant he didn't put a revision in, not that it was a good idea.
[07:39] <dholbach> is it out yet^W^W^W^Wgood morning!
[07:42] <ara> dholbach, hehehehe
[07:42] <ara> dholbach, morning!
[07:43] <dholbach> hi ara
[07:43] <dholbach> hi noodles775
[07:43] <noodles775> G'day dholbach :)
[11:00] <\sh> congrats guys for doing a good release (especially our non payed folks :))
[13:21] <aboudreault> emm
[13:22] <aboudreault> I have a launchpad PPA that contains a package who has the exact same version number than package in main universe.
[13:22] <aboudreault> The package in uninstallable.
[13:23] <aboudreault> Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/universe/p/proj/proj-data_4.6.1-5_i386.deb  Size mismatch
[13:23] <aboudreault> That's the error of apt-get.
[13:24] <aboudreault> I think apt-get keep the "size" from the last ppa in the sources.list.
[13:24] <aboudreault> but try to install the universe one
[13:24] <slytherin> aboudreault: How come it has same version?
[13:25] <aboudreault> slytherin: the package has been copied from jaunty (which has an older version) and now karmic have an up-to-date version
[13:25] <aboudreault> but apt-get should just be able to deal with that.. no?
[13:25] <noodles775> See https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning
[13:26] <joaopinto> his point is there might be a bug on apt dealing with this scenario :P
[13:26] <noodles775> ah, sorry.
[13:27] <aboudreault> yes, np.
[13:27] <ScottK> No, that's apt doing exactly the right thing.
[13:27] <ScottK> It'd be a security risk if it didn't.
[13:27] <joaopinto> ScottK, hum ? providing an incorrect error message without reporting the exact problem ?
[13:27] <ScottK> It's noticing that the package doesn't match what it's expecting.
[13:28] <ScottK> No, I think it's exactly reporting what it's seeing wrong.
[13:28] <joaopinto> if having different packages with the same version available from different repositories is not supported, it should report that
[13:28] <aboudreault> ScottK: Why that ? If a package in a PPA doesn't have a higher version, the universe one should be keep.
[13:28] <joaopinto> the size mismatch could be a regular security breach scenario, which is not the case
[13:28] <ScottK> aboudreault: How does it know which one to keep?
[13:28] <aboudreault> ScottK: with the order in sources.list
[13:29] <ScottK> aboudreault: That's relatively arbitrary.  I think it's safer to be conservative and not install if there is doubt.
[13:29] <joaopinto> well, on the other end you may be right, because there is no way for apt to check the filzesize before getting it :P
[13:29] <aboudreault> ok, I'll reupload the package on launchpad for that. I just found that behavior strange.
[13:30]  * ScottK runs off for a while.  
[13:30] <joaopinto> aboudreault, apt-get install mirror selection logic is not "pick the first" when you have multiple sources for the same package, afaiak
[13:31] <joaopinto> erm, wait, apt does fetch Packages for each of it's sources
[13:31] <joaopinto> so it should report size mismatches for the same package+version with different sizes
[13:31] <aboudreault> joaopinto: yes, but it certainly store the "package size" of the higher version somewhere, and that size should be modified ONLY if a package is strictly higher than the last package version read.
[13:31] <joaopinto> during apt-get update
[13:32] <joaopinto> aboudreault, actually it stores the package size for each of the sources, I mean, at least it downloads it
[13:32] <joaopinto> the best thing apt could do would be to report the mismatch on the cache update
[13:33] <aboudreault> but there is no size mismatch, there is simply 2 package with the same version ;)
[13:34] <aboudreault> anyway, I'm know apt does the proper thing, so I'll just upload again the package
[13:34] <aboudreault> thanks for your comments
[13:34] <directhex> sources.list priority isn't based on order
[13:35] <bddebian> Heya gang
[13:35] <directhex> check "apt-cache policy packagename" to see the priorities assigned to various mirrors
[13:35] <joaopinto> aboudreault, there is a size mismatch, that is why you get the error message, there is a mismatch between the size recorded on APT and the size from the http downloaded file
[13:35] <iulian> Hi bddebian.
[13:36] <aboudreault> directhex: I see that the ppa is the first one in version table section. However, apt-get tries to dowload it from universe
[13:36] <aboudreault> joaopinto: yes, I understand that.
[13:37] <aboudreault> and apt-cache show only show the one from universe.
[13:37] <directhex> aboudreault, if both repos have the same pin priority, it shouldn't be trying to download from either, it should be spitting out the mismatch
[13:38] <aboudreault> I did not modify the pin priority (I'm in a pbuilder chroot)
[13:39] <joaopinto> they are both regular repositories, they have the same pin priority, unless you did manual pinning :P
[13:40] <aboudreault> that's it, same priority.
[13:40] <bddebian> Heya iulian
[13:40] <directhex> at which point apt has no sensible way to resolve the situation you describe
[13:41] <directhex> you have two repos, with two identically versioned packages, but size and md5sum differ - which package is "correct"?
[13:41] <directhex> the right answer is "neither until proven otherwise"
[13:42] <aboudreault> it those cases, it tries to download the package and report immediatly a size mismatch
[13:42] <aboudreault> that's ok then
[13:49] <joaopinto> directhex, but apt could report the mismatch during apt cache update
[14:42] <mok0> Let's fix this guys: http://www.guardian.co.uk/technology/blog/2009/oct/29/windows7-usage-guardian
[14:42] <mok0> "Windows 7 overtakes Linux at the Guardian"
[14:57] <dholbach> congratulations highvoltage
[14:57] <highvoltage> thanks again dholbach
[14:57]  * highvoltage is now a MOTU! \o/
[14:59] <hyperair> congrats!
[14:59] <Kamujin> mok0: Is that a dupe of Ubuntu Problem #1?
[15:00] <mok0> Kamujin: I'd say it's a new manifestation of bug #1
[15:01] <mok0> Kamujin: ... or Linux users just don
[15:01] <mok0> 't read the Guarian
[15:01] <mok0> Guardian
[15:01] <mok0> can't seem to hit the right keys
[15:03] <ScottK> !ops
[15:04] <soren> ?
[15:04] <ScottK> Would someone change /topic to say we've released please
[15:04] <ScottK> soren: ^^
[15:04] <wgrant> I see no +t
[15:04] <wgrant> Doesn't need an op.
[15:05] <soren> wgrant: Good call.
[15:14] <mok0> highvoltage: congrats!!
[15:16] <highvoltage> thanks mok0
[15:16] <mok0> highvoltage: too bad the archive is closed :-)
[15:16] <highvoltage> mok0: for now.... :)
[15:49] <MsMaco> so how long after a release do we need to wait to start trying to sru stuff?
[15:49] <ScottK> MsMaco: Not at all
[15:50] <ScottK> MsMaco: The first Univese SRU was uploaded 3 days ago.
[15:51] <MsMaco> ScottK: great!
[15:51]  * MsMaco waits for pbuilder test build to finish
[15:56]  * siretart` can't await that lucid opens :-)
[15:56] <Laney> siretart`: grand plans?
[15:57] <siretart`> not really, perhaps breaking ffmpeg a bit
[15:57] <Laney> we all love some of that
[15:57] <Laney> wondering when I'm going to upgrade already ;)
[16:05] <\sh> highvoltage, congrats on motuship :)
[16:06] <highvoltage> thanks \sh! I'm very excited about it
[16:09] <Laney> get to SRUing!
[16:12] <MsMaco> sponsor needed for an SRU on bug 415766
[16:12] <MsMaco> thanks much whomever gets to it
[16:12] <Amaranth> congrats highvoltage
[16:14] <highvoltage> thanks Amaranth!
[16:21] <ScottK> zooko: You've got to be feeling pretty good about your binutils find.  Did you see the fix is currently building for karmic-proposed?
[17:33] <slacker_nl> congratz highvoltage
[17:33] <slacker_nl> and everyone gg on the release :)
[17:35] <hyperair> :)
[17:36] <ScottK> jdong: I created karmic-backports.
[17:52] <corp186> I have a question about creating both a binary arch-dependent pkg and an arch-independent package using cdbs
[17:52] <corp186> is there a good forum for questions, or should I ask here?
[18:01] <joaopinto> corp186, this is the proper channel, once someone becomes available to reply :P
[18:01] <corp186> I have a source package using cdbs, it builds a binary package and a -dbg package
[18:02] <randomaction> ScottK: Re bug 406721: https://help.ubuntu.com/community/UbuntuBackports currently says that a *-backports bug should be confirmed if the test build has succeeded. Is it not the case now?
[18:02] <randomaction> (Actually, I have marked some more bugs confirmed on the grounds that they test-built.)
[18:02] <corp186> I want to create a third package that just installs a header file as a -dev package
[18:02] <corp186> until now, cdbs did all the hard work of figuring out how to package files
[18:02] <corp186> but now I need to split files into two different packages
[18:02] <corp186> so how do I tell it which file goes where?
[18:02] <joaopinto> corp186, debian/package-dev.install
[18:03] <ScottK> randomaction: We really need to update that since not everyone can mark Triaged, so Confirmed really needs to mean b/i/r.
[18:03] <corp186> joaopinto: is there documentation on how that file works?
[18:03] <corp186> I haven't been able to find any
[18:03] <corp186> mostly cause google search for ".install" doesn't work too well
[18:03] <randomaction> ScottK: OK, I'll unconfirm that stuff, but I guess I can't update the Help page
[18:03] <joaopinto> corp186, thats how dh_install works, man dh_install :)
[18:03] <ScottK> I think you can.  It's a wiki.
[18:04] <joaopinto> corp186, the man includes an example for a -dev package ;)
[18:04] <corp186> joaopinto: great!
[18:05] <corp186> do I need to specify package.install now as well?
[18:05] <corp186> I didn't have to before
[18:05] <joaopinto> corp186, cdbs rules include a dh_install class
[18:05] <jdong> ScottK: awesome, thank you
[18:05] <joaopinto> erm, s/class/call
[18:05] <jdong> randomaction / ScottK: Agreed with regards to changing the meaning of Confirmed
[18:06] <jdong> we should consider the use of tagging to mark the "Yeah it builds but needs testing" phase
[18:06] <randomaction> I also propose to advertise ubuntu-backports-testers PPA as a centralized place to upload packages for testing.
[18:06] <Laney> who can upload there?
[18:06] <jdong> Laney: free-for-all unfortunately.
[18:06] <Laney> then no thanks
[18:06] <jdong> joining the ubuntu-backports-testers (open membership) team
[18:07] <jdong> randomaction: I'm brainstorming on a way of automating that
[18:07] <jdong> i.e. so that a "trustable" bot does the upload.
[18:07] <Laney> Launchpad could just grow a way to copy packages to older releases in PPAs
[18:08] <jdong> having the equivalent functionality of the Archive admin make backport script exposed in the Launchpad UI would help
[18:08] <randomaction> jdong: That would be good. The help page has been saying "Stay tuned for info" for a while now :)
[18:08] <jdong> randomaction: very true indeed :)
[18:11] <ScottK> jdong: Since I am an archive admin, it would be very helpful.
[18:12] <jdong> ScottK: yeah, we should aim in the Lucid cycle to hash out a way with Launchpad to make the backports process more integrated
[18:12] <ScottK> jdong: I also reproposed the not automatic spec for Lucid.  I'll be at UDS to push it.
[18:15] <jdong> ScottK: awesome. Yeah I saw that in my inbox
[18:17] <corp186> how can I prevent cdbs from deleting the build area if the build fails?
[18:28] <highvoltage> thanks slacker_nl :)
[20:13] <james_w> sync requests already?! :-)
[20:13] <james_w> go enjoy the release people
[20:14] <ajmitch> james_w: or just sign up to lucid-changes & start preparing SRUs for the pile of broken things :)
[20:14] <kklimonda> james_w, releases are overrated ;)
[20:14] <kklimonda> james_w, it's development what's interesting :)
[20:15] <ajmitch> it's only about 9 weeks until LTSDebianImportFreeze, according to the release schedule
[20:21] <jcastro> ScottK: I am only just now realizing the luck you had hitting chicago with nixternal on his big mountain sabbatical
[20:22] <jcastro> had he been in town there would have been a trail of debauchery and mayhem
[20:26] <ajmitch> surely he's a well-mannered gentleman?
[20:26] <ajmitch> right?
[21:26] <dtchen> "enjoy the release?" what, with the flood of bugs? pssht.
[21:27] <chrisccoulson> bugs? you mean that there are still bugs? ;)
[21:27] <chrisccoulson> :)
[21:28] <ajmitch> noone will be complaining about audio though, all the drivers are perfect there :)
[21:28] <sebner> wondering more about the kernel bug with ext4 which destroys files >500mb
[21:29] <joaopinto> they just complain about no sound after upgrade or sound being muted at each reboot :)
[21:30] <dtchen> yeah, thankfully I can now pin that one on pulse
[21:45] <ajmitch> sebner: got a reference for that one?
[21:46] <sebner> ajmitch: well it's under known issues for the release notes even .. https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/453579
[21:46] <ajmitch> as if I'd read release notes
[21:47] <sebner> heh
[21:47]  * sebner neither
[21:47] <sebner> but just read about it somewhere
[21:50] <ajmitch> but it does make me glad that my karmic install is still only using ext3 if it's a serious problem
[21:51] <sebner> ajmitch: I used ext4 since jaunty but I plan to re-install on weekend ^^
[21:51] <ajmitch> getting a different md5sum after a sync looks a bit scary
[21:51] <dtchen> well, even with ext3, you may want to read http://ozlabs.org/~rusty/index.cgi/2009/10/20 if you haven't already
[21:52] <sebner> The only solution is to use btrfs! *cough cough*
[21:52] <ajmitch> dtchen: though that looks to be more scary errors on power failure than scary errors in normal everyday usage
[21:54] <dtchen> ajmitch: correct, just something to be aware of
[21:55] <ajmitch> especially on my wonderful HP laptop which doesn't report the discharge rate of the battery
[21:55] <ajmitch> g-p-m doesn't give any warnings of low battery or "shutdown now!"
[21:58] <jdong> sebner: oh btrfs doesn't get along with rough shutdowns at all with GNOME
[21:58] <jdong> I haven't isolated the exact culprit yet
[21:58] <ajmitch> some days it feels like nothing is safe
[21:58] <jdong> sure feels that way
[21:58] <jdong> (*cough* transactional NTFS6 is pretty robust....)
[21:58] <ajmitch> it'll have its flaws :)
[21:59] <jdong> indeed :)
[21:59] <jdong> [PATCH] Prevent btrfsck to run on mounted filesystems
[21:59] <jdong> lol
[21:59] <jdong> finally
[21:59] <jdong> that was exceptionally evil!
[21:59] <jdong> the wiki manual used to say btrfsck is for mounted/unmounted filesystems
[22:00] <jdong> what they MEANT was to use future tense somewhere in there ;-)
[22:00] <ajmitch> using it on a mounted fs would completely toast it?
[22:00] <jdong> ajmitch: yup. Happened to me and confirmed by a dev on the mailing list
[22:00] <ajmitch> wonderful
[22:00] <jdong> ajmitch: btrfsck is more of a developers' consistency/sanity checker right now...
[22:01] <jdong> it's actually remarkably USELESS at fixing anything :)
[22:01] <ajmitch> for some reason I like to keep my data around
[22:02] <jdong> me too :)
[22:02] <jdong> my BTRFS karmics don't store anything persistent :)
[22:02] <ajmitch> maybe I could try it in virtualbox
[22:03] <jdong> it's not too bad to set up. Fun exercise left to the reader for how to make grub-probe (grub2) not blow up
[22:04] <jdong> and oh yeah. btrfsprogs and btrfs kernel modules need to come from mason's git tree...
[22:04] <ajmitch> I'm still sticking with grub-legacy
[22:04] <jdong> a couple known nasties in the 2.6.31 release version :)