[12:32] <ForgeAus> ubuntu (or is it apt?) needs either/or dependancy checking (ie gnome support vs kde support, one of either, but not both...)
[12:33] <ForgeAus> as a kubuntu user to get thunderbird you download thunderbird-gnome-support??? why?
[12:35] <ForgeAus> ... I get mostly its "assumed" your using ubuntu (as in the main/default gnome-based distro) but unneccessary gnome-based packages are silly so having a either/or check or maybe use provides? ie require a thinderbird-support package, and have thunderbird-kde-support or thunderbird-gnome-support provide that?
[12:40] <LaserJock> ForgeAus: it's not really assumed, it's not always easy to have a good solution either. I believe on Lucid thunderbird-gnome-support shouldn't be installed from Kubuntu
[12:41] <ForgeAus> so then why is it a dependancy of the thunderbird package then?
[12:41] <ForgeAus> it doesn't make sense
[12:41] <LaserJock> it isn't a dependency
[12:41] <LaserJock> it's listed as a Suggests
[12:41] <LaserJock> which is much different than a Depends
[12:42] <ForgeAus> oh I did a apt-cache showpkg thunderbird and it had it as a dependancy
[12:42] <ForgeAus> Suggests is ok
[12:42] <ForgeAus> (I didn't know suggestions show up there...
[12:43] <ForgeAus> sorry ...
[12:43] <LaserJock> Depends must me installed with the package, Recommends are installed by default but can be removed, and Suggests are not installed by default
[12:44] <astraljava> ForgeAus: If you do apt-cache show thunderbird, it shows it a bit clearer IMHO.
[12:44] <ForgeAus> thx
[12:44] <ForgeAus> ahh thats what I wanted in the first place, thx :)
[12:45] <ForgeAus> now I feel like a dolt for complaining about something I was wrong about!
[12:45] <LaserJock> no problem, it happens to the best of us ;-)
[13:11] <txwikinger> kmix does not work properly
[14:21] <psusi> damn, no Keybuck atm.... I had a very productive blktrace session last night and noticed that a lot of boot time is wasted reading files less than 4kb, which ureadahead is ignoring for some reason... it lists the file in the pack, but with 0 blocks so it doesn't read them... only I can't figure out why
[14:44] <bigcx2> hey all
[14:45] <bigcx2> i'm building a test debian package with dpkg-buildpackage
[14:45] <bigcx2> my package builds fine
[14:45] <bigcx2> but how do i get a diff.gz?
[14:45] <azeem_> did you get a .dsc?
[14:45] <cjwatson> you get a .diff.gz by having an .orig.tar.gz with the correct filename in the parent directory when you start the build
[14:46] <cjwatson> which should normally just be a rename of the upstream tarball
[14:46] <cjwatson> so if they ship foo-1.0.tar.gz and you want to produce a package which has version 1.0-1, then you need foo_1.0.orig.tar.gz in the parent directory
[14:48] <bigcx2> azeem_: yes, i got a .dsc and a .changes file from the build
[14:49] <bigcx2> cjwatson: ok, let me try that
[14:57] <bigcx2> cjwatson: still no luck
[14:58] <bigcx2> i grabbed a non-debianized source package
[14:58] <bigcx2> made a orig.tar.gz tarball out of it
[14:58] <bigcx2> applied a (older debian diff.gz) to the source
[14:58] <bigcx2> made some changes in debian/
[14:59] <bigcx2> rebuilt the package
[14:59] <bigcx2> but i don't get a diff.gz
[14:59] <bigcx2> :(
[14:59] <cjwatson> you almost certainly misnamed the orig.tar.gz - it's a common problem
[14:59] <bigcx2> ok, the source directory is package-3.8.1
[14:59] <cjwatson> or else you have the wrong version number, depending on how you look at it
[15:00] <cjwatson> the name of the source directory is utterly irrelevant
[15:00] <bigcx2> and the version in the changelog is 3.8.1-0
[15:00] <bigcx2> so should my orig.tar.gz be package-3.8.1-0.tar.gz then?
[15:00] <cjwatson> no, absolutely not
[15:00] <cjwatson> it should be package_3.8.1.orig.tar.gz
[15:01] <bigcx2> that's what it is now
[15:01] <cjwatson> note the underscore, the orig, and the absence of -0
[15:01] <bigcx2> oh wait
[15:01] <bigcx2> no underscore
[15:01] <bigcx2> i had a dash
[15:01] <bigcx2> sheesh
[15:01] <cjwatson> common problem, as I say :)
[15:01] <cjwatson> you'll get used to it
[15:01] <bigcx2> k, one more try!
[15:02] <ogra> cjwatson, i always thought we should put some reminder into the message that points out that you build natively ;)
[15:03] <bigcx2> yay, it worked
[15:03] <bigcx2> !
[15:03] <bigcx2> thanks cjwatson
[15:04] <cjwatson> ogra: we do
[15:04] <cjwatson> <cjwatson@sarantium ~/man-db-2.5.7>$ debuild
[15:04] <cjwatson> This package has a Debian revision number but there does not seem to be
[15:04] <cjwatson> an appropriate original tar file or .orig directory in the parent directory;
[15:04] <cjwatson> (expected one of man-db_2.5.7.orig.tar.gz, man-db_2.5.7.orig.tar.bz2,
[15:04] <cjwatson> man-db_2.5.7.orig.tar.lzma or man-db-2.5.7.orig)
[15:04] <cjwatson> continue anyway? (y/n)
[15:04] <cjwatson> you should just use debuild not dpkg-buildpackage :)
[15:04] <bigcx2> difference being...lintian?
[15:04] <cjwatson> and even with dpkg-buildpackage you do get a message
[15:04] <cjwatson> dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found
[15:05] <cjwatson> bigcx2: and various other checks and such
[15:05] <cjwatson> generally, there's no reason not to use the smarter tool
[15:05] <bigcx2> cjwatson: ok, i'll look into that, it's been a while since i built some packages
[15:05] <bigcx2> can you tell?
[15:05] <bigcx2> lol
[15:09] <bigcx2> cjwatson: how does pbuilder stack up against debuild?
[15:11] <azeem_> bigcx2: they are orthogonal
[15:12] <bigcx2> azeem_: different philosophies then? why two different tools?
[15:13] <azeem_> bigcx2: pbuilder runs something like debuild
[15:13] <azeem_> as part of what it does; you can't really compare the two
[15:14] <bigcx2> hm, ok...guess i'll have to play with 'em
[15:30] <markr_> Is there some "secret place" which doesn't contain as much comment spam as Launchpad?
[15:30] <markr_> All the "Me too"-comments drive me crazy.
[15:31] <markr_> Launchpad with an option to say whether you are just reporting a "Me too"-comment, could help against that, but I am not sure whether the users would respect it.
[15:32] <c_korn> markr_: there is a "affects me too" button
[15:32] <markr_> c_korn: yes, but the issues are all slightly different.
[15:32] <markr_> E.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/270798
[15:35] <markr_> In that whole thread there is not a single person who has actually posted the context source code explaining why it happens for example.
[15:35] <markr_> It is just one long list of clueless users, with the comments by those that can do something about it completely hidden by the mass.
[15:39] <seb128> does anybody know where jcastro is or could tell him I didn't get the session he asked me to add to schedule there because summit doesn't list it (yet)?
[15:44] <psusi> it isn't the "me too" that gets me.. what annoys the shit out of me is all of the "I can't believe this was not fixed for the release, this is a huge problem.  It's a shame I have to go back to the old release or another distro"
[15:44] <crimsun> welcome to my world.
[15:45] <psusi> there should be a mod button to hide such comments ;)
[15:46] <crimsun> which is what should be what's being discussed in Mangrove 3 right now
[15:47] <soren> Can someone tell me what the deal is with zeromq? https://launchpad.net/ubuntu/+source/zeromq exists, suggesting it existed at some point, but the publishing history is empty. It's in Debian testing since early April.
[15:50] <jibel> psusi, that's coming soon, and bug locking when they are marked closed by a bug supervisor.
[15:51] <crimsun> soren: the existence date of the package in testing suggests that it simply didn't make it into lucid
[15:56] <soren> crimsun: ..but should have been synced for Maverick.
[15:56] <soren> crimsun: Right?
[16:02] <crimsun> soren: it doesn't seem to have been blacklisted. Oh well. Perhaps an archive admin can peer deeper?
[16:23] <cjwatson> soren: we haven't done a full new-source sync yet
[16:26] <cjwatson> soren: I've synced zeromq, since you asked so nicely :-)
[16:26] <soren> cjwatson: Yeah, I just saw :) Thanks!
[17:09]  * psusi tries to remember who he was talking to the other day about ext3 vs ext4 debootstrap speed... seems that ext4 is faster with nobarrier... slower with barriers, but it seems that by not using barriers, ext3 is not safe on disks with write caches enabled
[17:39] <psusi> basically without barriers, the disk reorders requests and combines both journal writes into one, then does the actual modification either before, or after both journal writes.. which defeats the purpose of the journal in the first place... I'm surprised that ext3 corruption on power failure is not very widespread because of this
[22:25] <Stevinko> anyone skilled regarding radeon driver that could give me a hand ?
[23:53] <kklimonda> Vala testsuite requires a running and working DBus Session Bus and for some reason it does not (all bits are there, package build-depends on dbus-x11 and make check starts dbus-daemon --session) - you can check bug 580246 for more information.. well, there isn't much yet. Does anyone have experience with running dbus in build environment?