[04:06] <LimCore>  I sent a patch to fix https://bugs.launchpad.net/ubuntu/+source/kerneltop/+bug/486218  please confirm and apply it
[07:57] <alkisg> dh_installdebconf adds a call to db_purge on my postrm script, which fails! How could I debug this? http://paste.ubuntu.com/338512/
[08:00] <alkisg> Here's the apt-get purge output with DEBCONF_DEBUG=developer: http://paste.ubuntu.com/338515/
[08:00] <alkisg> "subprocess installed post-removal script returned error exit status 128 "
[08:32] <dholbach> good morning
[08:34] <Quintasan|Szel> hiho
[08:34] <dholbach> hi Quintasan|Szel
[08:36] <Quintasan|Szel> how nice, 11 people form my class and 17 teachers are absent due to illness :/
[08:39] <Quintasan|Szel> dholbach: btw, how many people from MOTU Council are needed on this adhoc meeting?
[08:40] <dholbach> Quintasan|Szel: we're 7 in total, so to make a decision it needs to be 4
[08:40] <dholbach> simple majority
[08:40] <nigel_nb> good morning dholbach :)
[08:41] <dholbach> hi nigel_nb
[08:41] <nigel_nb> :)
[08:42] <alkisg> Bah, I found the problem, I had to redirect file descriptors on "service ssh force-reload" :(
[10:00] <DktrKranz> dholbach: hi! I remember you once created a script to unsubscribe bugs from sponsors' queue and subscribing ubuntu-archive, is it still available online?
[10:02] <dholbach> DktrKranz: yes, but it used python-launchpad-bugs and that's not going to work any more
[10:02] <dholbach> DktrKranz: should be easy to rewrite using python-launchpadlib
[10:02] <DktrKranz> it probably will
[10:06] <geser> DktrKranz: I've a similar script to ack syncs. If you remove the ACK part you should have your script.
[10:07] <dholbach> ubuntu-dev-tools? :)
[10:07] <geser> when I've time to polish it up (add some error checking)
[10:08] <DktrKranz> geser: if you have something already, it could be nice (and will speed up things :)
[10:11] <geser> DktrKranz: http://paste.ubuntu.com/338573/ it should be easy to remove the unneeded parts (like adding bug comment)
[10:15] <DktrKranz> geser: thanks.
[13:43] <blackxored> hello motus
[13:43] <blackxored> I'm about to upload an azureus revision for new upstream into ubuntu, but I had to diverge since 3.0 format isn't in lucid yet, so you think is ok to upload this merge, otherwise it would be a sync eventually
[14:13] <alkisg> Is there a list of valid db_capb parameters somewhere? E.g. I'd like to enable "cancel", but not "backup", is that possible?
[14:14] <persia> blackxored: If it must diverge, it's fine to upload as a merge.  If you can sync, than it's better to do so.
[14:14] <blackxored> persia, I can't sync since 3.0 format isn't supported yet
[14:15] <persia> Right, so it's fine to upload as a merge :)
[14:15]  * persia is permanently set on extra-verbose, so some messages may end up carrying more information than is strictly necessary
[14:17] <highvoltage> I like persia on extra-verbose.
[14:35] <cjwatson> alkisg: the presence of the cancel button is controlled by whether the backup capability is set
[14:35] <slytherin> ttx: in case you plan to file any sync requests, please file one for jug as well. :-)
[14:35] <alkisg> Thank you cjwatson, so I'll enable the backup capability :)
[14:36] <ttx> slytherin: heh
[14:36] <slytherin> ttx: I may not boot into Ubuntu today at home so informed you.
[14:38] <cjwatson> alkisg: I'm not sure there's a list anywhere, sorry, but 'backup' and 'escape' are the only two that can usefully be set by a debconf client (and also 'align' and 'progresscancel' if cdebconf is involved, but at the moment this is only relevant to installer hackers)
[14:39] <alkisg> Well, being new to debconf, I guess "backup" will be just fine for me :) Thanks again.
[14:40] <slytherin> Are we not syncing packages in source format 3?
[14:42] <Laney> nope
[14:44] <slytherin> Laney: is this announced anywhere?
[14:45] <Laney> I don't think so, it's just that LP can't handle them yet
[14:45] <Laney> it will catch up soon
[14:45] <slytherin> Laney: Soon as in this release cycle?
[14:47] <james_w> slytherin: soon as in next week AIUI
[14:47] <Laney> slytherin: AFAIK (see wgrant@#ubuntu-devel a few minutes ago)
[14:47] <MTecknology> How can I see what package installed a certain app?
[14:47] <Laney> dpkg -S
[14:47] <MTecknology> thanks
[14:47] <Laney> dlocate
[14:47] <Laney> apt-file
[14:47] <Laney> :)
[14:48] <bddebian> Heya gang
[14:58] <MTecknology> Is there any easy way to remove all the packages I installed for mesing with packages? I want to move everything from my primary system into a vm
[15:00] <MTecknology> I think I have most of them - just nice to know I don't have any extras
[15:41] <alkisg> I'm storing a public ssh key in a debconf "string" type, is that acceptable? Or I'd be violating length/LF issues?
[15:50] <blackxored> someone can help me to setup custom from in gmail for @ubuntu.com
[15:50] <blackxored> ?
[17:10] <cornucopic> Hi all
[17:10] <cornucopic> is there a switch for 'apt-cache' so that It shows me only 'ARCH=All' packages?
[17:13] <persia> cornucopic: You might be looking for grep-dctrl, but perhaps not.
[17:14] <cornucopic> persia, ah. from the name of it, i think it might just help me! Thanks. looking..
[17:14] <persia> It's lower-level than you asked about, but consequently more flexible :)
[17:34] <cornucopic> persia, need help with dpkg-cntrl :(
[17:34] <Unggnu> hi all
[17:34] <cornucopic> is this valid 'apt-cache search python | grep-dctrl -FArchitecture ALL
[17:34] <cornucopic> ' ?
[17:34] <Unggnu> Are there plans so ship an 64 Bit version of the Adobe Flashplayer?
[17:34] <cornucopic> i want to list packages with ALL arch.
[17:34] <cornucopic> it throws me a error, i don't understand:(
[17:35] <persia> Unggnu: We don't ship Adobe Flashplayer directly, due to license restrictions.  If Adobe makes one available, it might be possible to integration with flashplayer-installer.
[17:35] <Unggnu> persia, it is one available and it works quite well for me. It also seems to be updated regularly with the standard player.
[17:35] <persia> Unggnu: On the other hand, the Partner archive contains a flash player package, which might get 64-bit at a different timing.
[17:36] <Unggnu> persia, http://labs.adobe.com/technologies/flashplayer10/64bit.html
[17:36] <persia> Unggnu: Feel free to investigate the flashplayer-installer package, if you like.
[17:36] <Unggnu> It would most likely fix this crashes
[17:36] <persia> cornucopic: Sorry: I tend to use snippets copied from mails and IRC logs to drive grep-dctrl.  You'll need to ask someone more knowledgeable.
[17:36] <cornucopic> persia, no problem. i think i am making headways:)
[18:01] <cornucopic> Would any kinds soul help me with grep-dctrl ?
[18:10] <pabelanger> Afternoon, am I in the correct channel for packing help with a PPA?
[18:26] <bjsnider> i'm wondering if there's some way i can upload the same package to a ppa, but for 5 different series, and use the same orig tarball for each one, so i don't have to upload the source each time -- it's big and i don't have a lot of upload bandwidth
[18:31] <ScottK> bjsnider: PPA specific questions like that are more appropriate in #launchpad.
[18:32] <bjsnider> hahaa
[18:32] <bjsnider> yes, they told me to go here
[18:32] <bjsnider> i don't think it's a specific ppa question
[18:33] <bjsnider> more about debian packaging, or debuild
[18:33] <ScottK> bjsnider: It's actually very specific to how PPAs work.  In normal distro work, such questions don't come up.
[18:36] <bjsnider> well, let me take the ppa side out of it. if you're updating a package by adding a patch or changing a dependency, are you then uploading the entire thing including the source tarball or are you just uploading the changes file and the dsc, and it's using the orig tarball that's already on the server?
[18:39] <persia> bjsnider: For distro work, one only uploads a tarball when producing a new tarball and never uploads to multiple targets.
[18:39] <persia> So the question simply never arises.
[18:40] <bjsnider> but what if you're updating a package going from -0ubuntu1 to -0ubuntu2? the whole source tarball is not re-uploaded, only the changes right?
[18:41] <persia> Right.
[18:42] <persia> But whether that applies to PPAs is a different question.
[18:42] <persia> It's based on how the remote archive works, not on how the development tools work.
[18:42] <bjsnider> i'm not sure you're right about that
[18:42] <bjsnider> at least i'm not using the tools correctly
[18:43] <ScottK> It's a strong enough rule that in the Debian infrastructure if you upload the tarball again when you don't need to, the upload will be rejected.
[18:43] <ScottK> Ubuntu will accept it, but complain a bit.
[18:43] <persia> Well, it depends.  I've had rejects for that.
[18:43] <bjsnider> is there a way i can use debuild and force it to use a specific orig tarball?
[18:45] <persia> No, but you can use -sa to force inclusion of a tarball when debuild doesn't think you need one.
[18:46] <bjsnider> no, no, no
[18:46] <bjsnider> i'm not communicating this properly
[18:50] <bjsnider> the orig tarball has to match the name in the changelog, right? otherwise it is not found, at least not on my system. but the name int he changelog has to change for an upload to work, so the orig name has to change with it, and that means you've got a new orig file that has to be uploaded again each time...
[18:50] <bjsnider> which is what i'm trying to avoid
[18:51] <bjsnider> if, on the other hand, i could force debuild to use a generically-named orig tarball, then i could upload it once and only once
[18:51] <persia> Um, no.
[18:52] <persia> So, the name in the changelog has to match the package name.
[18:52] <persia> And then there is the ${VERSION}-${REVISION} string.
[18:52] <persia> The VERSION must match the VERSION of the orig tarball
[18:53] <bjsnider> now we're getting somehwere
[18:53] <persia> The REVISION can be whatever you want (although due to semantic constraints, one should always increase this when preparing new revisions)
[18:53] <bjsnider> well, on of the two has to change or the upload won't work
[18:53] <bjsnider> but that's beside the point
[18:53] <persia> But what you'll need to get from #launchpad is whether an upload of a tarball to a specific target in a PPA automatically makes it available to other targets in the same PPA.
[18:54] <bjsnider> it's easy enough to test though
[18:54] <persia> Well, no.  It again depends on the way the archive works.  I *think* I remember a bug about revision management in PPAs, but I don't recall the result offhand.
[18:55] <bjsnider> between version and revision there is a dash
[18:55] <persia> Right.
[18:55] <bjsnider> the first dash is the one that's used
[18:56] <bjsnider> that's why this wasn't working
[18:56] <bjsnider> that's how i force debuild to use the same tarball
[18:56] <persia> I forget.  There's some discussion of the effects of multiple dashes that I read once.  It might be the last dash.
[18:56] <bjsnider> i didn't have that dash in the name
[18:56] <persia> You might want to test that if you have a real need for two hyphens.  I recommend avoiding it if possible.
[18:57] <bjsnider> so it must have been seeing the whole string as $version
[18:57] <bjsnider> in an ubuntu package, is the very first attempt called -0ubuntu1 or -0ubuntu0?
[18:57] <bjsnider> well, i didn't have any hyphens
[19:07] <geser> if upstream has a '-' in it's version string using a revision is mandatory as the last '-' determines the upstream version and the package revision
[19:08] <persia> geser: It is the last one.  Thanks!
[19:08] <persia> (although one can also use uversionmangle to work around that)
[19:44] <pabelanger> What is the best way for a package in my PPA to always supersede the Ubuntu version?  IE: in my PPA I have helloworld_2.4, but ubuntu have helloworld_3.0.
[19:44] <tsimpson> pabelanger: just upload a new version
[19:45] <persia> pabelanger: If you want to maintain a newer PPA, you have to play the merge game.  What's better about your PPA version?
[19:46] <pabelanger> Nothing is better, I just want to slim down the Ubuntu version, this main reason for the PPA version.
[19:48] <mok0> pabelanger: you can give it a epoch number
[19:48] <mok0> an epoch number, even
[19:48] <persia> Well, except then one runs into the awkward state of not being able to resync if later things work out.
[19:49] <persia> The alternative I'd recommend is to see if the package can be sanely split so that one doesn't need the larger binary footprint, and discuss the split with the relevant Debian maintainer.
[19:50] <persia> (well, there's the intermediate option of trying to maintain the split package in Ubuntu, but we discourage that)
[19:50] <mok0> persia: yeah.
[19:51] <persia> epochs are dangerous.  They are the ultimate bigger hammer.
[19:51] <mok0> I guess another way is to pin it in apt.conf
[19:51] <persia> Well, sure, but that only works for a local system.
[19:51] <mok0> persia: I agree, but it's a working solution to the problem
[19:52] <persia> Depends on the audience, but yes.
[19:55] <pabelanger> what about renaming the package to a new name and setting up a conflict with the original package?
[19:56] <persia> You'd also need to Provide: the original package, and then you run into dependency issues because there's no support for versioned Provides.
[19:57] <persia> (note that any of the solutions outlined above *work*, they just mostly have downsides, either because they don't really solve the problem or because they require social machinations)
[19:58] <mok0> pabelanger: you could also repackage the newest version
[19:59] <persia> But that requires merging on a regular basis.
[19:59] <persia> There's also only supporting stable releases with the PPA, which means only needing to merge once every six months.
[20:00] <geser> if there are no SRUs or security uploads
[20:00] <persia> Right.
[20:01] <persia> Although constructing a version that is larger than any SRU or security update is easier than constructing a version that is newer than anything, but then the package is potentially inherently insecure or buggy.
[20:51] <norsetto> Anyone know of any planning to have format 3.0 in lucid?
[20:51] <maco> launchpad support is in the works
[20:52] <geser> norsetto: with luck next week
[20:53] <norsetto> cool
[20:53] <mok0> norsetto!!!1
[20:53] <sebner> huhu norsetto :D
[20:53] <mok0> Yay!
[20:53] <norsetto> mok0!!!2
[20:53] <mok0> hehe
[20:53] <norsetto> sebner, gruss
[20:54] <mok0> norsetto: what's up? Longtimenosee
[20:54] <norsetto> mok0 indeed, I'm pretty fine, and you?
[20:54] <sebner> norsetto: come stai? =)
[20:54] <sebner> ah
[20:55] <mok0> norsetto: Ah, I'm fine, mostly... too busy though
[20:55] <ScottK> Hello norsetto.  Good to see you again.
[20:55] <norsetto> sebner, and whats up with you?
[20:55] <norsetto> ScottK, hi Scott
[20:56] <sebner> norsetto: bussy with university, some important tests next week and then finally .. holidays \o/ and after that 2 weeks of do or die tests :D
[20:56] <norsetto> sebner, ahhh, so finally you decided to go to uni
[20:56] <mok0> The military got fed up with sebner
[20:57] <norsetto> mok0, I'm just surprised they wanted him in the first place
[20:57] <sebner> mok0: don't say that, I left as private first class ;)
[20:57] <norsetto> mok0, must be desperate up there ...
[20:57] <sebner> rofl
[20:57] <sebner> norsetto: private first class!
[20:57] <mok0> norsetto: they dropped their strategy of trying to bore the enemy to death and let him go
[20:57] <norsetto> sebner, yes sir! of course sir!
[20:58] <sebner> heh
[20:58]  * mok0 hugs sebner
[20:58] <sebner> mok0: My shooting skills weren't *that* good indeed
[20:58]  * sebner hugs mok0 back :)
[20:59] <norsetto> sebner, I read there was a strange decline in the number of alpine cows
[20:59] <mok0> Ah good times are back when norsetto shows up
[21:00] <norsetto> mok0, lets drink a beer together!
[21:00] <sebner> norsetto: hehehehe, I only killed wooden tablets! ... or not? ;D
[21:00] <mok0> yeah!
[21:01]  * norsetto passes a beer to sebner, he is allowed now that he is a real (tm) man 
[21:01] <mok0> chhheeeerssss
[21:01] <norsetto> skollllll
[21:02] <sebner> kampai!
[21:02] <norsetto> burp
[21:02] <norsetto> sorry
[21:02] <mok0> Salut!
[21:02] <sebner> Prost!
[21:03] <mok0> Skål!
[21:03] <mok0> cin cin!
[21:03] <norsetto> the first one that starts singing I let sebner shoot him (he will miss anyway)
[21:05] <sebner> hahahaha xD
[21:06] <sebner> norsetto: Really no worries, I got a pretty quiet office job there ;)
[21:09] <wgrant> norsetto: We're testing 3.0 support out at the moment. It will hopefully become available for use in Ubuntu late next week.
[21:11] <norsetto> wgrant, looking forward to that, hope it will be announced in a devel m.l. once ready
[21:22]  * RainCT wonders whether 3.0 debs are supported already in Ubuntu
[21:23] <mok0> RainCT: last I heard, no
[21:24] <RainCT> mok0: Do you know if that will change anytime soon?
[21:24] <sebner> RainCT: ~~~o~~~
[21:24] <mok0> RainCT: I don't... however, since the Debian archive now contains 3.0 source packages, it can't be long
[21:25] <wgrant> Late next week.
[21:25] <mok0> tataaa!
[21:25] <wgrant> It's taking a while to get dpkg upgraded on all the necessary machines.
[21:25] <mok0> wgrant: is LP prepared for the change?
[21:25] <RainCT> Woo, okay thanks :)
[21:25] <wgrant> mok0: My branch is approved, but cannot land until one last image is upgradd.
[21:26] <wgrant> That should happen in the next day or two.
[21:26] <mok0> However, 3.0 (quilt) is still subject to heated discusssions on Debian mailiing lists
[21:27] <wgrant> They seem to have died down.
[21:34] <geser> pbuilder (and similar) don't need any change to test-build 3.0 source packages, right?
[21:36] <wgrant> geser: sbuild didn't, but not sure about pbuilder.
[21:36] <mok0> geser: Unpacking of source packages is handled by the dpkg-* programs so as long as they are up-to-date...
[21:36] <wgrant> It at least works in Debian, so it's easy to fix.
[21:37] <mok0> wgrant: hmm. What's so special about sbuild?
[21:38] <wgrant> mok0: LP uses it, so I tested that it works.
[21:38] <wgrant> Well, OK, LP uses its own fork of an ancient sbuild full of revolting hacks, but it's close enough.
[21:38] <mok0> wgrant: ah, sbuild *didn't need changes* ... got it