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