[00:59] <ethana2> http://paste.ubuntu.com/205915/
[00:59] <ethana2> I'm new at this, how do I get rid of those errors and warnings?
[01:03] <directhex> ethana2, lintian-info --tags $foo
[01:03] <directhex> e.g. lintian-info --tags dh-clean-k-is-deprecated
[01:03] <directhex> will tell you in detail what to do for each lintian error
[01:04] <ethana2> I don't think all my errors are lintian errors though
[01:04] <ethana2> at least not the fatal ones..
[01:04] <ethana2> how do I make it ignore gpg signing stuff?
[01:06] <RAOF> ethana2: pass "-us -uc" to debuild; that's "don't sign the source" and "don't sign the changes", respectively.
[01:06] <ethana2> ahhhh
[01:06] <ethana2> I had the -us..
[01:06] <RAOF> That'll get rid of the debsign error, by not calling debsign :)
[01:06] <ethana2> RAOF: thanks
[01:06]  * ethana2 does it
[01:10] <ethana2> The following packages are BROKEN:
[01:10] <ethana2>   pbuilder-satisfydepends-dummy
[01:11] <RAOF> The interesting error is after that.  Pastebin time!
[01:19] <ethana2> hmm
[01:19]  * ethana2 pastebins all of it
[01:20] <ethana2> http://paste.ubuntu.com/205930/
[01:21] <RAOF> pbuilder-satisfydepends-dummy: Depends: xautomation which is a virtual package
[01:21] <directhex>   pbuilder-satisfydepends-dummy: Depends: xautomation which is a virtual package.
[01:22] <ethana2> what's a virtual package?
[01:22] <directhex> one which doesn't exist
[01:23] <ethana2> should I just remove it from the project files?
[01:23] <RAOF> Most likely you're missing Universe in your pbuilder?
[01:23] <ethana2> I don't know..
[01:23] <ethana2> but it is a universe package I guess
[01:24] <ethana2> brb
[01:35] <ethana2> back
[04:16] <kb9vqf_> How do you remove a package from REVU?  I was typing too fast and uploaded to REVU instead of my PPA...
[04:17] <ajmitch> packages can be archived there if you tell us which one
[04:17] <kb9vqf_>  	 kchmviewer-kde3
[04:20] <StevenK> -kde3 ?
[04:20] <StevenK> Eeek
[04:20]  * ajmitch doesn't see it there yet
[04:31] <kb9vqf_> ajmitch: strange...it's showing up here: http://revu.ubuntuwire.com/u/kb9vqf
[04:31] <kb9vqf_> StevenK: Yup, it's one of those old KDE3 packages, bound for the KDE3 PPA... ;-)
[04:33] <ajmitch> kb9vqf_: ah, I thought you meant that you'd just uploaded it, and it is archived there
[04:33] <ajmitch> nuked now
[04:33] <kb9vqf_> sorry for the confusion...and thanks! :-)
[04:34] <kb9vqf_> BTW I went ahead and uploaded 389 directory server packages to REVU, just in case I can't get it in upstream in time for Karmic
[04:35] <ajmitch> I saw that
[04:36] <kb9vqf_> I tried to implement your earlier suggestions...we'll see if Debian likes them or not
[04:36] <ajmitch> which ones were they? :)
[04:36] <kb9vqf_> ${shlibs:Depends}
[04:36] <kb9vqf_> instead of all the individial lib depends
[04:37] <kb9vqf_> Needed -0ubuntu1
[04:37] <ajmitch> right, that's fairly standard
[04:37] <ajmitch> -0ubuntu1 is good, but probably not if you're culling all the previous changelog entries
[04:37] <kb9vqf_> I thought I read somewhere that you are supposed to cull them?
[04:38]  * kb9vqf_ doesn't remember where
[04:38] <ajmitch> I'm not a big fan of rewriting history especially when building on the work of others
[04:38] <ajmitch> others will disagree with me, I'm sure
[04:39] <kb9vqf_> Yeah, it didn't feel right to me either--that's why I kept Michele in the control file as original uploader
[04:39] <kb9vqf_> Michele mentioned that he won't be able to work on anything until September, so I guess it's a good thing that I started work on it
[04:39] <ajmitch> probably, since I doubt I'd have found time to pick it up again
[04:42] <ajmitch> now you just need to find some friendly reviewers to bribe
[04:43] <Hobbsee> hint: offer beer
[04:43] <ajmitch> sounds like Hobbsee is thirsty
[04:44] <ajmitch> it's great when 30k of a 40k diff is just the license text
[04:46] <kb9vqf_> :)
[04:47] <kb9vqf_> I'm doing a final rebuild test now, just to make sure it all works
[04:48] <ajmitch> I can at least review the easy ones, which are the various libraries & don't require any setup
[04:49] <kb9vqf_> Sure...try svrcore and all the mozilla libs
[04:49] <kb9vqf_> Those, along with JSS, haven't changed for the past five years (!)
[04:49] <kb9vqf_> In some cases, they're even older...
[04:49] <ajmitch> yeah, I've still got copies of them around from my work, I remember having to play around with pkg-config
[04:52] <kb9vqf_> if you find anything wrong, poke me at kb9vqf_ (*with* the underscore--my laptop screen died from the lightning EMP so I'm on my server for now)
[04:52] <ajmitch> it's the java packaging that scares me
[04:52] <ajmitch> ouch
[04:53] <ajmitch> I take it you got the servers up & running again?
[04:53] <kb9vqf_> Yeah, after $1500 worth of new parts
[04:53]  * kb9vqf_ hopes his insurance will handle it
[04:53] <kb9vqf_> One server mainboard, two CPUs, one hard disk, one video card, and various miscillaneous items
[04:54] <ajmitch> not fun
[04:54] <kb9vqf_> 10 days of downtime...priceless :)
[04:54] <ajmitch> 10 days is a long time for anyone
[04:55] <kb9vqf_> No kidding!  Fortunately my laptop still worked (flickering, but working) during most of that time
[04:55] <kb9vqf_> Hopefully it didn't kill 389 ds in Karmic
[04:55] <kb9vqf_> timewise, that is
[04:56] <ajmitch> how far down did you do the renaming?
[04:57] <ajmitch> I still see a few .jar files with fedora-ds in the name, looking at the diffs
[04:57] <kb9vqf_> It's still the fedora ds tarball, but the packaging is pretty much completely renamed
[04:58] <kb9vqf_> That was, I can just plop in the new 389 tarball when it is released and the users shouldn't notice the difference
[04:58] <ajmitch> so just package names, not binary names?
[04:58] <kb9vqf_> Correct
[04:58]  * ajmitch will have to build it all & try it out
[04:58] <kb9vqf_> It really only affects the ds core and the consoles
[04:58] <kb9vqf_> I'm building it all here:
[04:58] <kb9vqf_> https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa
[04:58] <ajmitch> the other libraries should be fine
[04:58] <kb9vqf_> Should have it all up by tomorrow (hopefully)
[04:59] <ajmitch> great
[04:59] <kb9vqf_> Yeah, someone put together a team, so things should keep moving :)
[04:59] <ajmitch> lp team?
[04:59] <kb9vqf_> Yeah
[04:59] <kb9vqf_> https://launchpad.net/~ubuntu-389-directory-server
[04:59] <kb9vqf_> Michele is a member
[05:00]  * ajmitch should join also
[05:00] <kb9vqf_> Kai-Cheung Leung really wants to see it in Karmic...he's the one that set the team up and transfered control to me
[05:00] <ajmitch> ubuntu-directory team hasn't exactly served its intended purpose
[05:00] <kb9vqf_> Heh
[05:01] <ajmitch> it's mostly been a bug contact for packages
[05:01]  * kb9vqf_ needs to get to bed...early day tomorrow at work
[05:01] <wgrant> ubuntu-directory did nothing, and now ubuntu-server has taken over its domain.
[05:15] <micahg> ping mdeslaur
[05:15] <mdeslaur> micahg: yeah?
[05:15] <micahg> I was wondering if it's worth filing a CVE report bug for something that I know will be fixed and released asap
[05:20] <micahg> mdeslaur: ^^
[05:21] <mdeslaur> micahg: If it's a new issue that has a CVE number and is in main, we usually follow them in our cve tracker
[05:21] <mdeslaur> what cve?
[05:22] <micahg> cve-2009-2210
[05:22] <micahg> It's still mostly unpublished
[05:22] <micahg> but there is a bug # in the mozilla bugtracker
[05:29] <mdeslaur> micahg: that was fixed in thunderbird 2.0.0.22?
[05:30] <mdeslaur> micahg: we just published it http://www.ubuntu.com/usn/usn-782-1
[05:30] <mdeslaur> micahg: but the particular cve number is not in the advisory as it probably wasn't public when we released
[05:31] <micahg> ah
[05:31] <micahg> I guess I was panicking for nothing :)
[05:31] <micahg> but in general, should I open an issue if it's not fixed yet, but I know it will be
[05:35] <mdeslaur> micahg: you can open a bug if you'd like, you can also take a look at our cve tracker: https://launchpad.net/ubuntu-cve-tracker
[05:36] <mdeslaur> our plan is to eventually automate the opening of bugs when we get new cves in our tracker
[05:36] <micahg> Would the cves be added automatically?
[05:37] <mdeslaur> yes, eventually
[05:37] <micahg> ok
[05:37] <micahg> is there anything I can do now to help?
[05:38] <mdeslaur> micahg: what type of help are you willing/able to do?
[05:39] <micahg> add them in the mean time for some packages?
[05:39] <micahg> what's needed?
[05:39] <mdeslaur> you could open bugs for CVEs for packages that are in universe
[05:40] <mdeslaur> that way, people would notice which packages need to be fixed
[05:40] <micahg> ok
[05:40] <micahg> I generally watch for mantis and phpmyadmin
[05:40] <mdeslaur> cool
[05:41] <micahg> I'll be opening ones for phpmyadmin later tonight probably
[05:41] <ajmitch> mdeslaur: how is universe security going?
[05:41] <micahg> eventually, I'd like to help make the patches as well
[05:41] <mdeslaur> micahg: I'll probably do updates for phpmyadmin in my spare time soon
[05:41] <mdeslaur> micahg: that would be cool
[05:41] <mdeslaur> ajmitch: we don't get much community involvement.
[05:42] <mdeslaur> ajmitch: maybe one or two packages a week get some debdiffs submitted
[05:42] <ajmitch> that's rather low, how can that be improved?
[05:43] <micahg> mdeslaur: how would I use the Ubuntu CVE tracker?
[05:44] <mdeslaur> ajmitch: we had a session about it last UDS...we (the security team) will try and give some irc sessions about it, and some other stuff
[05:44] <mdeslaur> ajmitch: we may also create a "universe package of the week" type of thing to try and get people interested
[05:44] <mdeslaur> micahg: you need to check out the tree with bzr, have you used bzr before?
[05:44] <ajmitch> ok, I'm guessing it's something you could target to the existing MOTUs & community
[05:44] <micahg> yes
[05:45] <mdeslaur> micahg: if you check out the tree, there's a readme file in there that explains all the tools and the queries you can perform
[05:45] <mdeslaur> basically, in the active directory, there's one file per CVE number
[05:45] <mdeslaur> the retired directory contains CVEs that we fixed
[05:46] <mdeslaur> and the ignored directory are for CVEs we ignore (they're not for us)
[05:46] <mdeslaur> there are some tools in the scripts directory to print out reports for a particular package
[05:46] <micahg> cool
[05:47] <mdeslaur> so you can do something like ./scripts/pkg_status thunderbird
[05:47] <mdeslaur> check out the readme file, it's full of examples
[05:47] <mdeslaur> I need to go to bed now as I'm falling asleep
[05:47] <micahg> ok
[05:47] <micahg> thanks for your help mdeslaur
[05:47] <mdeslaur> np micahg, let me know how it goes
[05:49] <mdeslaur> ajmitch: yes, existing MOTUs...and also we wanted to mention on the "how to become a motu" wiki page that producing some security updates is a good way to become familiar with a bunch of tools
[05:52] <sdeb> hi , i want anaconda instead or beside ubuntu installer ?
[06:20] <sdeb> ubottu: tell sdeb about motu
[06:33] <dholbach> good morning
[06:39] <iulian> Good morning Daniel!
[06:40] <dholbach> heya iulian!
[06:41] <fabrice_sp> Good morning dholbach !
[06:41] <dholbach> hey fabrice_sp
[06:48] <ajmitch> hi dholbach
[06:49] <dholbach> hiya ajmitch
[06:50] <ajmitch> dholbach: how was your weekend?
[06:51] <dholbach> very good, I even got some of my tax return done! :)
[06:51] <ajmitch> yay!
[06:51] <dholbach> how was yours?
[06:51] <ajmitch> I even got some sponsoring done, though I don't think I really got much other ubuntu stuff in
[06:51] <dholbach> sponsoring! :)
[06:51] <ajmitch> fairly boring & quiet, in other words :)
[06:52]  * dholbach takes the dog for a run - see you in a bit
[06:52] <ajmitch> I have to catch up to your karma somehow!
[06:52] <dholbach> hehe
[06:52] <ajmitch> close to 4k in the last month or two is a good start
[07:00] <qiyong> karmic is the 9.10 ?
[07:00] <qiyong> !karmic
[07:13] <geser> good morning
[07:13] <ajmitch> hi geser
[07:13] <iulian> Hello geser.
[08:15] <\sh> moins
[08:17] <ajmitch> hi \sh
[08:17] <geser> Hi \sh
[08:48] <stefanlsd> is revu working ok?
[08:49] <stefanlsd> submitted a new version of a package and didnt hear anything...
[08:54] <ajmitch> package name?
[08:56] <ajmitch> stefanlsd: if you could give me any more info, it'd be appreciated :)
[08:57] <stefanlsd> ajmitch: http://revu.ubuntuwire.com/p/gears
[08:58] <ajmitch> ok, for some reason it didn't like your signature on the last upload
[08:59] <stefanlsd> ajmitch: oh did update my key a couple weeks ago on LP?  maybe revu hasnt pulled the new one?
[08:59] <ajmitch> it hasn't
[08:59] <stefanlsd> ajmitch: ok. anything i need to do?
[09:00] <ajmitch> let me check the current procedures for updating keys :)
[09:00] <wgrant> Log in, IIRC.
[09:01] <ajmitch> wgrant: does that pull in updated keys & not merely new ones?
[09:01] <stefanlsd> am logged in, let me try relog
[09:01] <wgrant> ajmitch: No idea.
[09:01] <ajmitch> worth a try anyway
[09:01] <ajmitch> the keyring is dated may 16, which seems to be too long ago
[09:02] <stefanlsd> ajmitch: ok. re-logged in. anything change?
[09:03] <ajmitch> nope
[09:03] <ajmitch> I can try & do a manual update
[09:03] <wgrant> ajmitch: Sure that's the right keyring?
[09:03] <ajmitch> it appeared to be
[09:04] <ajmitch> no, you're right
[09:04] <ajmitch> uploaders.gpg vs data/uploaders.gpg
[09:04] <ajmitch> just to confuse me
[09:05] <ajmitch> stefanlsd: hopefully gears will get accepted on the next try
[09:06] <stefanlsd> ajmitch: 7A66BA46 should of been the key i signed with and my current key you should have in revu.   will try again :)
[09:06] <ajmitch> stefanlsd: it appeared to have worked now
[09:06] <stefanlsd> ajmitch: aah. yeah. just got a notification :)
[09:06] <ajmitch> good
[09:10] <stefanlsd> ajmitch: thanks for the help!
[09:12] <ajmitch> no problem :)
[10:33] <gaspa> Laney: hi, news on new ghc version?
[10:38] <Laney> gaspa: no, but you can reply to that bug and ask Simon for an update if you like
[10:38] <gaspa> of course, which bug?
[10:39] <Laney> bug 382803
[10:39] <Laney> it would probably be better to email him directly though rather than spamming LP I guess
[10:39] <gaspa> yup
[10:40] <Laney> you could CC kaol@debian and ask if he's going to update when it releases too
[10:41] <Laney> if it's more than a couple of weeks longer we should consider staying with .3 and that patch
[10:42] <gaspa> Laney: uh, late.... well, i'll do if he will reply.
[10:42] <gaspa> thanks, anyway.
[10:42] <Laney> well there's still a long time to go until FF
[10:42] <Laney> no worries
[10:43] <gaspa> geser: I wont ask you any more give-back, are you happy ? :D
[10:49] <Laney> gaspa: please cc me if you haven't sent it yet
[11:13] <gaspa> Laney: he already replied: "Will discuss with the development team today."
[11:13] <Laney> oh, speedy
[11:13] <gaspa> really. :P
[11:14] <\sh> thekorn: ping -> #leonov pls :)
[11:28] <AnAnt> Hello, it seems that the -ubuntu2 release of sl-modem is one of causes of this bug LP 375148
[11:28] <AnAnt> in that release Ubuntu removed a modprobe conf file that creates a static device (mknod /dev/slamr0)
[11:29] <AnAnt> I understand that creating static devices is not allowed in Ubuntu
[11:29] <AnAnt> but the problem is that sl-modem code doesn't dynamically create devices
[11:30] <AnAnt> and it isn't really maintained upstream (they just accept patches)
[11:30] <AnAnt> and I understand from them that sl-modem code shouldn't use udev because of license problems
[11:30] <AnAnt> anyone can suggest a solution for this mess ?!
[11:31] <dholbach> who could imagine running a session about "simple packaging from scratch" (maybe dh7?) at UDW? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[11:31] <dholbach> I'd really appreciate if somebody stepped up to do it :)
[11:31] <AnAnt> dholbach: is this dh7 trying to be CDBS like ?
[11:32] <AnAnt> dholbach: I saw a rules file using dh7 , they just do dh_* something like that
[11:32] <directhex> AnAnt, except overriding dh7 requires 87% fewer chicken sacrifices
[11:32] <AnAnt> directhex: huh ? what's chicken sacrifices ?
[11:32] <Laney> when is UDW?
[11:32]  * Laney should just click the link
[11:32] <dholbach> AnAnt: you will find that in a lot of cases /usr/share/doc/debhelper/examples/rules.tiny will do what you want and you'll just need something like /usr/share/doc/debhelper/examples/rules.simple
[11:33] <dholbach> Laney: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep Aug 31st to Sep 4th
[11:33] <dholbach> AnAnt: but CDBS will cut the deal too :)
[11:34] <Laney> I'll do it
[11:34] <Laney> packaging hello with dh7
[11:34] <Laney> ;)
[11:34]  * dholbach hugs Laney
[11:34] <dholbach> you're a hero
[11:34] <AnAnt> man I don't feel comfortable with this !
[11:34] <dholbach> Laney: you get to pick a slot :-)
[11:34] <AnAnt> it's like you dunno what's going on
[11:35] <Laney> dholbach: is there going to be a session about setting up pbuilder and such like?
[11:35] <directhex> AnAnt, turn on DH_VERBOSE to watch it - and everything it's doing can be trivially overridden
[11:36] <dholbach> Laney: I'll do it in GETTING STARTED
[11:36] <AnAnt> ok
[11:37] <Laney> dholbach: after that then?
[11:37] <Laney> also, I just looked at the rules file for hello. Does this predate debhelper?
[11:37] <dholbach> Laney: as you like it - first come, first pick the slot :)
[11:37] <Laney> ok, 1800 on the first day then
[11:37] <dholbach> Laney: there#s hello and hello-debhelper
[11:37] <dholbach> Laney: shall I add you then?
[11:38] <Laney> please do
[11:38] <dholbach> will do :-)
[11:38] <Laney> ah, this is more like it
[11:38] <Laney> hello-dh7
[11:39] <AnAnt> dholbach: can any Ubuntu derivative be added to https://wiki.ubuntu.com/Releases ? I see unofficial variants there
[11:39] <dholbach> AnAnt: just do it - I see no reason for you not to and don't know if there's anybody "maintaining the page"
[11:40] <AnAnt> dholbach: well, karmic is mentioned there, so there is someone maintaining it I think
[11:41] <dholbach> sure, just do it
[12:32] <mok0> dholbach: ping
[12:32] <dholbach> mok0: pong
[12:32] <mok0> dholbach: hey, you are a launchpad hacker, right?
[12:32] <dholbach> errrrrrrrrrrrrrrrrrrrrrrrrr
[12:33] <mok0> The sponsor queue is full of entries from Debian, that really can't be sponsored by us. Is is possible to make a script to automatically unsub from those?
[12:34] <dholbach> try https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsors and https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors :-)
[12:35] <mok0> dholbach: huh?
[12:35] <dholbach> mok0: it just lists Ubuntu bugs
[12:36] <mok0> dholbach: ah now I see... :-) I was looking to unsub to clean up the list
[12:37] <dholbach> mok0: the parts of the LP API for unsubscribing teams from bugs is very new so I haven't used those parts yet
[12:37] <mok0> dholbach: OK, I understand.
[12:37] <mok0> dholbach: I also want to consult with you re. bazaar
[12:38] <mok0> dholbach: if you have time
[12:38] <dholbach> mok0: sure
[12:39] <mok0> dholbach: OK, so if you look at sahana sources at sf.net it is divided into several CVS "components"
[12:39] <dholbach> mok0: did you want to package it from CVS?
[12:40] <mok0> dholbach: no I want to import it to LP, like you have done with the civic thing
[12:40] <dholbach> oh, that's something that asomething did
[12:40] <mok0> dholbach: just wondering if it needs 3 different imports
[12:40] <dholbach> hm, good question - maybe we need one sahana super project and subprojects for the others?
[12:41] <dholbach> dunno if that's too complicated though
[12:41] <mok0> dholbach: how do you manage merging the ubuntu and trunk branches?
[12:41] <dholbach> mok0: not at all :-/
[12:41] <dholbach> they don't share history
[12:41] <mok0> dholbach: I see the ubuntu branch only has debian/
[12:41] <dholbach> we just stored the packaging in the branch
[12:41] <dholbach> yeah
[12:42] <dholbach> bzr bd -- -S -us -uc will use the watch file to build a source package for you
[12:42] <dholbach> (bzr-builddeb)
[12:42] <mok0> dholbach: Hm, isn't it supposed to be real smart so you can merge the packaging with an updated upstream clone?
[12:43] <mok0> dholbach: like, the dailydeb thing?
[12:43] <mok0> dholbach: using the watch file kinda defeats the purpose of having upstream sources mirrored in LP
[12:44] <dholbach> mok0: I know, I'd love to see us use full-source-from-vcs instead of tarballs :-)
[12:44] <dholbach> ask james_w about it :)
[12:45] <mok0> dholbach: ok, I will... I tacitly assumed you were doing it like that
[12:45] <mok0> dholbach: thanks for your time!
[12:46] <mok0> dholbach: I will see what I can find out and let you know
[12:46] <dholbach> mok0: asomething started the branch and since he was tracking the stable tarball of civicrm, I thought "ok, let's just do it like that"
[12:46] <Laney> there's funny things like autogen.sh though
[12:47] <mok0> Laney: is that a comment re: this discussion?
[12:47] <dholbach> mok0: I'll spruce up the wiki page about it some more, so we can see which parts of the ./packages/ we need to package in the long run
[12:47] <Laney> mok0: yes
[12:47] <mok0> Laney: ah ok :-)
[12:47] <Laney> so it's not as easy as pulling the vcs history
[12:47] <dholbach> http://daniel.holba.ch/blog/?p=311 is my thoughts about it :)
[12:47] <mok0> Laney: the autogenerated files ought not to be part of the repo
[12:48] <mok0> Laney: I mean the VCS
[12:48] <dholbach> mok0: WORD!
[12:48] <mok0> dholbach: thanx
[12:48] <Laney> mok0: they aren't, but they are part of the tarball
[12:48] <Laney> that's the problem
[12:48] <mok0> Laney: right...
[12:49] <mok0> Laney: when you build from the VCS you should always do autoreconf
[12:49] <Laney> yes
[12:49] <Laney> it makes it an extra step which means that we differ from what upstream releases
[12:50] <mok0> Laney: I go through a great deal of trouble keeping the autogen stuff out of my VCS managed stuff
[12:50] <Laney> as you should
[12:50] <mok0> Laney: I think from a packaging perspective, the correct thing is to ignore it if it's present
[12:51] <mok0> Laney: but there are mountains of stuff like that when you start using VCS'es for packaging
[12:52] <iulian> mok0: Hey.  Have you installed cadabra (from revu) to see if it works?  I'd like to upload it, if that's OK with you but not before I see it working.  Unfortunately, I don't have a Karmic box to test packages. :-(
[12:52] <mok0> iulian: no I haven't... I haven't had the time
[12:53] <iulian> Ouh
[12:53] <mok0> iulian: neither do I... could it be run inside a chroot?
[12:54] <iulian> mok0: Yea, but I don't have one with X installed.
[12:54] <mok0> iulian: I didn't try compiling it for jaunty
[12:55] <mok0> iulian: but I suppose it can be done
[12:55] <iulian> Yup
[12:56]  * iulian prefers and up-to-date Karmic system.
[12:56] <iulian> s/and/an/
[12:58] <iulian> Well, I'll see what I can do.  I believe it works but I just want to be sure.
[12:58] <iulian> Thanks mok0.
[13:00] <mok0> iulian: for a user-land application like cadabra release shouldn't really matter
[13:01] <mok0> iulian: it requires a library "modglue" but that made it into jaunty :-)
[13:01] <mok0> cadabra didn't cut the FF otherwise it would have been there too
[13:02] <iulian> Heh, cool.  I didn't know that.
[13:02] <iulian> OK, so, should I upload?
[13:02] <mok0> iulian: if you think the package is ok, yeah
[13:02] <iulian> Great.
[13:03] <mok0> iulian: If there are bugs in it, we'll find out soon enough :-P
[13:05] <iulian> mok0: I've reviewed it this morning as well.  Having said that, I hope I haven't missed anything, but yeah, like you said, we'll find out soon.
[13:06] <mok0> iulian: Great. I hope to start some revu'ing soon
[13:07] <mok0> iulian: karmic is requiring more work than usual due to the gcc44 toolchain
[13:07] <mok0> iulian: I've been fixing lots of FTBFS'es this time
[13:15] <iulian> mok0: Cool.  I'll have a look at some FTBFS when I have some spare time.  I have been a bit busy lately so I have been falling behind a bit on the Ubuntu front. :(
[13:16] <mok0> iulian: you can only do as much as you can
[13:17] <mok0> dholbach: nice read, holy cows!
[13:17] <dholbach> mok0: most of my ideas around it haven't changed :)
[13:18] <mok0> dholbach: I'm using git for my packaging, locally, and the workflow is quite effective.
[13:19] <mok0> dholbach: I'd like to try out bzr, but it doesn't seem to give me the same options
[13:19] <mok0> dholbach: the "a branch is a directory" paradigm rubs against me
[13:20] <dholbach> really? :)
[13:20] <mok0> dholbach: yes, really :-)
[13:20] <dholbach> "bzr branch trunk my-new-feature" became really intuitive for me already
[13:20] <mok0> dholbach: ... and you have parallel directories?
[13:21] <dholbach> yes
[13:22] <mok0> dholbach: I don't like it
[13:22] <mok0> dholbach: In git, the directory is just a container of your branch
[13:22] <mok0> dholbach: when you switch to another branch, the content of the directory changes
[13:23] <mok0> dholbach: (except for files not under control)
[13:23] <mok0> dholbach: which means you have all your branches right there in the same directory
[13:23] <dholbach> I'm not saying "there's only my way and everybody else is just nuts", but as branching for me is relatively cheap, I do it whenever I feel like it and do all operations only on the branch I'm working on right now... the "bzr pull ../other-branch" afterwards is easy enough too
[13:24] <mok0> dholbach: it's probably just my ignorance, but it seems bzr is always getting in the way of what I want to do
[13:26] <mok0> dholbach: and the extra commit you need to do after pulling trunk's changes drives me crazy :-)
[13:26] <dholbach> I don't get that feeling :)
[13:26] <dholbach> hu?
[13:26] <dholbach> bzr pull   doesn't give you uncommitted changes
[13:26] <mok0> dholbach: oh?
[13:27] <Laney> bzr merge does though
[13:27] <dholbach> right
[13:27] <mok0> dholbach: afair I always have to do a commit when I update my branch with trunk's changes
[13:27] <mok0> Hm, perhaps that's it
[13:28] <mok0> In git, you can only do a merge when your branch is committed, but then it commits everything for you again
[13:29] <mok0> Anyway, I would like to learn how to be productive using bzr
[13:29] <AnAnt> mok0: I've been using git for a week or so now, I find it cooler than bzr indeed
[13:29] <dholbach> mok0: so I should chase somebody up to give a UDW session about it? :)
[13:30] <iulian> mok0: cadabra has just been uploaded to NEW.
[13:30] <mok0> dholbach: that's a great idea!
[13:30] <mok0> dholbach: btw, I can repeat my session
[13:31] <dholbach> mok0: that'd be sweet
[13:31] <mok0> iulian: great! Thanks!
[13:31] <dholbach> mok0: you can still just grab a slot https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep :-)
[13:31] <mok0> dholbach: it was fun, there was a good crowd there
[13:31] <dholbach> fantastic
[13:33] <stefanlsd> iulian: i've been wanting to ask this - did you forward the message to the ubuntu-motu list, or is that an automated thing?
[13:35] <mok0> Wiki button "Save Changes" should be changed to "I'm felling lucky!"
[13:35] <RainCT> OT, is there some easy way to know how much traffic I use on a network interface?
[13:36] <joaopinto> RainCT, iptraf ?
[13:36] <dholbach> mok0: thanks muchly!
[13:36] <mok0> RainCT: netstat?
[13:36] <iulian> stefanlsd: Forwarded.
[13:37] <jpds> RainCT: vnstat
[13:38] <mok0> bbl
[13:39] <RainCT> joaopinto, mok0, jpds: thanks
[13:40] <stefanlsd> iulian: oh ok. thought so. is it required. or just something everyone does...?
[13:43] <iulian> stefanlsd: It's good to forward the message to the list so that everybody knows what you've uploaded from revu.
[13:44] <stefanlsd> iulian: ok. cool. was just wondering if it was a rule, or just something we do. thx
[14:39] <masterkernel> RainCT: got time for a review? :)
[14:40] <masterkernel> http://revu.ubuntuwire.com/p/kernelcheck
[14:42] <RainCT> masterkernel: Not really, I'm busy with something else. By the way, I'd be interested to an answer to the Debian thread
[14:42] <RainCT> Ubuntu is pretty much the same as Debian
[14:42] <masterkernel> which Debian thread?
[14:42] <masterkernel> the wnpp one?
[14:51] <gaspa> dholbach: there will be Loco sessions this time? (about UDW)
[14:54] <slytherin> ttx: was that you who gave back eclipse?
[14:55] <dholbach> gaspa: you mean sessions in more than one language?
[14:55] <gaspa> dholbach: yes.
[14:55] <ttx> slytherin: I've nothing to do with Eclipse, I don't even get your question :)
[14:56] <dholbach> gaspa: I'll do a call for participation once the schedule is a bit fuller, but yes, I'd love to get as much translated as possible
[14:56] <dholbach> :-)
[14:56] <gaspa> cool
[14:56] <gaspa> :)
[15:58] <alkisg> Hi, I'd like to have something like a PPA but on my own server. My main concern is that the server will be remote, and each package will be >100Mb, so I want to be able to only send the changes every time I change something. What should I use for that, reprepro?
[16:03] <mok0> alkisg: as long as the upstream source packages stays the same, you only upload diffs
[16:04] <alkisg> mok0: that's for launchpad, right? I'd like to have my *own* server to host the apt repository...
[16:04] <mok0> alkisg: same thing
[16:04] <alkisg> mok0: ok, but what software will need to be runinng on the server ?
[16:04] <mok0> alkisg: that is, if your server has a buildd
[16:05] <mok0> alkisg: afaik, reprepro should be able to work like you want
[16:05] <mok0> alkisg: the server will already have a copy of orig.tar.gz so there is no reason to upload it again
[16:06] <directhex> i always used apt-ftparchive personally
[16:06] <mok0> directhex: does that build the package?
[16:06] <alkisg> Yes, that's what I'm talking about, a simple "I recomment this tool over the other one". E.g. reprepro or apt-ftparchive?
[16:06] <directhex> mok0, no, it builds the Packages file
[16:06] <mok0> directhex: ah, you have to upload binary debs
[16:07] <mok0> directhex: that wont help him
[16:07] <alkisg> I won't be able to upload binary debs of >100Mb with my dsl :(
[16:07] <alkisg> So, mok0, you think reprepro is a good choice? /me is inexperienced...
[16:07] <mok0> alkisg: yes I do
[16:08] <alkisg> I'll dive into that then. Thanks a lot to both of you.
[16:09] <mok0> alkisg: there is also something called falcon, but I don't know how maintained it is:  https://edge.launchpad.net/falcon
[16:10] <alkisg> Heh I like his milestones map :)
[16:11] <mok0> alkisg: this is for the big thing: http://www.debian.org/devel/buildd/setting-up
[16:12] <alkisg> That's what debian uses for its archives?
[16:12] <mok0> alkisg: yes
[16:12] <mok0> alkisg: a bit overkill if you only need a few dozens of packages
[16:13] <alkisg> I think I'll need about 50 packages, but the bad this is that all over them will contain multimedia so they'll be quite large
[16:13] <alkisg> *thing
[16:13] <alkisg> mok0: I think I'll take your advice for reprepro. Much appreciated :)
[16:13] <mok0> alkisg: https://edge.launchpad.net/debomatic
[16:14] <mok0> alkisg: that's written by DktrKranz, who is always on this channel
[16:14] <alkisg> Hm, and it looks well maintained - packages for karmic and everything
[16:15] <mok0> alkisg: It does
[16:15] <alkisg> DktrKranz: what would you suggest for hosting/maintaining about 50 really big packages? (>100Mb)? debomatic, reprepro or buildd ?
[16:16] <alkisg> They contain multimedia files, but I'd like to be able to only send the differences and have the building process happen on the server
[16:17] <DktrKranz> alkisg: debomatic is something to automate build from debian source packages, is not something for repository management, so you can skip it if you need that
[16:17] <alkisg> Ah, thanks  :)
[16:18] <DktrKranz> mok0: you forgot dak :)
[16:18] <mok0> DktrKranz: Oh yes
[16:18] <DktrKranz> mok0: and a "dak for dummies" book to help configuring it ;)
[16:19] <mok0> heh. There's also "mini-dinstall"
[16:19] <mok0> DktrKranz: In fact, you can combine debomatic with mini-dinstall
[16:19] <ScottK> mcasadevall can tell you how much fun DAK setups are.
[16:20] <mcasadevall> ow dak
[16:20] <mok0> mcasadevall: alkisg is looking to set up a repo
[16:20] <mok0> mcasadevall: going over the various options
[16:20]  * alkisg is reading a little about dak...
[16:21] <ScottK> geser: Do you intend to push your debhelper change to auto add --install-layout=deb to Debian?
[16:21] <alkisg> So far, I'm between reprepro, buildd and dak. A quick "select this" would be the best for me; adding more options the worst :)
[16:23] <DktrKranz> mcasadevall: did you write a full guide on how to setup dak? it would be useful...
[16:23] <DktrKranz> ScottK: already asked myself
[16:24] <mcasadevall> nope
[16:24] <ScottK> DktrKranz: Did you get an answer?  Thanks to that change it'll be tough to make packages work in Debian and Ubuntu without change that need --install-layout=deb .
[16:24] <DktrKranz> ScottK: geser: debian #534620, pending
[16:24] <ScottK> DktrKranz: OK.  We need to go back and look at all the packages where we added it directly since the one of those I've checked no longer builds.
[16:26] <alkisg> Sorry, my xorg decided that it needed a break. /me looks at the logs...
[16:26] <DktrKranz> ScottK: really? so invoking it twice makes packages FTBFS?
[16:27] <ScottK> DktrKranz: I'm not sure exactly what the issue is, but pymilter built on Jaunty, but FTBFS on Karmic.  If I remove --install-layout=deb  from debian/rules it works.
[16:27] <geser> ScottK: I should probably do it, thanks for reminding me
[16:27] <ScottK> So something has changed.
[16:28] <geser> ScottK: any build log at hand?
[16:29] <ScottK> geser: Let me get you one.
[16:29] <DktrKranz> ScottK: I'd try another approach, building a package in jaunty chroot with --install-layout=deb specified twice, to see if that's the issue
[16:30] <mok0> DktrKranz: what do you use to manage the repo of the debomatic built packages?
[16:30] <ScottK> DktrKranz: I'll show geser the log and see if he has ideas.  I've got limited time today to worry about it.
[16:31] <ScottK> Actually I think it's likely some other change as the package still builds on Jaunty and that change was in the Jaunty debhelper.
[16:33] <ScottK> geser: http://pastebin.com/f35992d0e - identical package builds on Jaunty.
[16:34] <DktrKranz> mok0: I scan them with dpkg-scanpackages, but I don't have the need to have a local repository, right now
[16:35] <mok0> DktrKranz: ok thnx
[16:35] <DktrKranz> mok0: but I think every repo helper would be good
[16:36] <geser> ScottK: from a quick look it seems to be the "nice" feature of cdbs to rename dist-packages back to site-packages which hits here again
[16:36] <stefanlsd> is there a requirement for a Copyright line to be in each source code file? i.e. Package contains a COPYING with general license information, do individual source files need to have a copyright?
[16:36] <ScottK> stefanlsd: They should.  It won't get rejected from the archive if COPYING is present and the intent is clear.
[16:36] <ScottK> geser: OK.  Can we fix that?
[16:37] <mok0> DktrKranz: I had some problems with reprepro -- the database got screwed up, so I switched to mini-dinstall which has worked well
[16:37]  * alkisg is reading http://wiki.debian.org/HowToSetupADebianRepository ...
[16:37] <geser> ScottK: I don't know as I did look up the idea behind this yet
[16:38] <ScottK> geser: OK.  Thanks for looking into it.
[16:40] <c_korn> trying to build a package there is this error in configure: http://pastebin.com/d59325ed5 the binary used to be in the libarts1-dev package. but where is it in jaunty now?
[16:42] <geser> c_korn: AFAIR arts went away in jaunty, try building with --without-arts
[16:42] <stefanlsd> ScottK: ok. thanks. so my understanding is its recommended. Not required. With gears for example, there are two main directories.  gears and third_party.  gears/COPYING has a bsd style license. third_party has some thirdpary code and some written by google with the following - // Copyright 2006 Google Inc. All Rights Reserved. But no actual license. I guess what im asking is, does the COPYING apply to that, or is it a bit of a stretch sin
[16:42] <stefanlsd> ce its not inside the gears directory. Although im fairly sure the intended license is the google bsd type license.
[16:42] <ScottK> Since COPYING is in a different dir, I'm not sure it's clear.
[16:42] <c_korn> geser: but the error also says that it removes functionality.
[16:43] <ScottK> Is all the 3rd party stuff the same license?
[16:44] <stefanlsd> ScottK: yeah. not sure its clear either. although i believe that is their intention (although i cant speak on behalf of upstream, but upstream is uselessly unresponsive). No, other thirdparty stuff has explicit licenses.
[16:44] <Laney> all rights reserved is non-free
[16:44] <ScottK> stefanlsd: I probably wouldn't accept it, but other archive admins might.
[16:44] <Laney> isn't it?
[16:44] <ScottK> Laney: Not always.  It can mean all OTHER rights.
[16:45] <ScottK> It's a bit odd.
[16:45] <Laney> well, without any explicit information to the contrary I don't see how you can assume that it is free
[16:45] <DktrKranz> Laney: it's something which hasn't many sense on free licenses, but that won't put it as non-free
[16:45] <stefanlsd> Laney: no. the bsd license has all rights reserved also.
[16:46] <stefanlsd> http://www.opensource.org/licenses/bsd-license.php
[16:46] <geser> ScottK: re pymilter: remove the build/python-milter and install/python-milter (and perhaps also clean) as the default cdbs seem to do it for you already (and some more) and your additional rules just repeat it (when you look at the karmic build log you will see that it gets build and installed twice for every python version)
[16:46] <ScottK> geser: Thanks.  I'll have a look at that.
[16:47] <stefanlsd> ScottK: ok. thanks for the insight. i have an upstream bug opened re the issue and attached diffs for adding the intended license for them, but totally unresponsive.
[16:48] <geser> ScottK: the problem is that cdbs installs it for you to dist-packages (but renames it afterwards to site-packages), your rules install it a second time to dist-packages (so both site- and dist-packages exists now) and pycentral bails out that both exist (it would rename site-packages back to dist-packages if there wouldn't be that conflict)
[16:49] <ScottK> Ah.  I see.
[16:49] <ScottK> So the odd thing is I drop install-layout=deb it works.
[16:49] <ScottK> geser: Thanks for looking into it.
[16:49] <evanrmurphy> I'm going through documentation for beginners in development. Starting to get a decent handle on pbuilder, and it's my understanding that among other things it uses a chroot environment. Now in the PackagingGuide there's a recommendation to make a chroot environment using debootstrap. Why might I like to have two separate chroot envs? Is pbuilder a very specialized one, perhaps? Thanks in advance.
[16:52] <ScottK> evanrmurphy: You can, but you can also use the pbuilder login option to get an open chroot to work in if you need it.
[16:52] <ScottK> Personally, I just do that.
[16:52] <geser> ScottK: it will FTBFS without --install-layout=deb because of "debian/python-milter/usr/local/lib/python2.6/dist-packages"
[16:53]  * ScottK test builds again.
[16:54] <geser> ScottK: have you the sanitychecks from pkgbinarymangler enabled in your karmic pbuilder?
[16:54] <ScottK> geser: Good point.  Probaby not.
[16:54] <stefanlsd> evanrmurphy: i think you just need the pbuilder one.  its essentiallly a debootstrap with added features. like scottk mentioned, --login and you can login to it.
[16:55] <evanrmurphy> Is there any somewhat standard or recommended dev setup in terms of the chroots, virtual machines, etc. to use while working? I'm looking for a good set of tools to start out with, there just seem to be so many!
[16:56] <evanrmurphy> ScottK, stefanlsd: Thank you.
[16:57] <geser> evanrmurphy: a seperate chroot environment has the advantage that you keep work-in-progress there till is ready (so you can use the tools from karmic while the rest of your system is still jaunty)
[16:58] <stefanlsd> evanrmurphy: have you checked out the MOTU videos that dholbach made. They are excellent and should help show you the basics...https://wiki.ubuntu.com/MOTU/Videos
[16:59] <geser> evanrmurphy: I use a seperate chroot for my MOTU work. this has the advantage that I can upgrade it independent from my normal system and I also don't pollute my main system with all those packages needed during package prepareing (debhelper, cdbs, -dev packages, etc.)
[16:59] <stefanlsd> geser: nice idea actually. /me thinks about doing that...
[17:02] <evanrmurphy> geser: That makes a lot of sense, thanks for explaining. Do you use pbuilder's chroot for that (with the --save-after-login option) or another one? It occurs to me that installing too many packages in the pbuilder chroot might thwart it's purpose as the minimal environment for build testing.
[17:03] <evanrmurphy> stefanlsd: I've watched one or two of those videos, but it's been awhile. I'll take another look at them and spend some more time with the tutorials/docs. :)
[17:04] <stefanlsd> evanrmurphy: yeah, right. i wouldnt --save-after-login for that exact reason.
[17:04] <geser> evanrmurphy: I've a minimal pbuilder for test-building and a second chroot (managed through schroot) for the actual work
[17:05] <stefanlsd> evanrmurphy: http://www.debian-administration.org/articles/566 describes that schroot method
[17:06] <evanrmurphy> great, thanks :)
[17:07] <stefanlsd> evanrmurphy: i think many people have different workflows.  personally i just have my pbuilder to test building and sometimes non-gui program functions. for gui stuff testing i use virtualbox. (although i plan on using kvm)
[17:10] <stefanlsd> heading home. cya guys later!  :)
[17:12] <evanrmurphy> I suppose that debootstrap and schroot are just different ways of getting a chroot.
[17:21] <geser> evanrmurphy: debootstrap is used to create a chroot (with the basic packages installed), schroot is used to "use" it
[17:37] <kb9vqf_> Anyone here willing to rescore a PPA build?
[17:40] <c_korn> trying to build the pidgin 2.5.8 version with the diff.gz of 2.5.7 (from karmic) these errors occur: http://pastebin.com/d64f79db1
[17:41] <MTecknology> dholbach: you around?
[17:42] <dholbach> MTecknology: a bit
[17:43] <MTecknology> dholbach: I was trying ot follow the packaging 101 vid and it's kinda broken..
[17:43] <dholbach> really?
[17:44] <MTecknology> dholbach: ya, just minor things, but I only got about 2min into it
[17:45] <dholbach> can you drop me an email about it?
[17:45] <MTecknology> ed version is out of date, it's available in a tar.gz now and dh has an error about no directory existing, I forgot which
[17:45] <MTecknology> sure thing
[17:45] <dholbach> or add something to https://wiki.ubuntu.com/MOTU/Videos ?
[17:46] <MTecknology> which would you prefer?
[17:46] <dholbach> the wiki
[17:46] <MTecknology> alrighty
[17:46] <dholbach> in the next 6-7 weeks I won't have time to work on it
[17:46] <dholbach> so maybe somebody else wants to pick it up
[17:47] <dholbach> alright, I need to leave for dinner now
[17:47] <dholbach> so see you guys around
[17:47] <dholbach> and thanks again
[17:51] <kb9vqf_> Anyone here willing to rescore a PPA build?
[17:51] <kb9vqf_> 382323
[17:52] <kb9vqf_> This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by a certificates bug that has since been fixed, but it'll be many hourse before it rebuilds
[17:52]  * kb9vqf_ needs to check his clipboard contents before pasting :)
[18:24] <fabrice_sp> Hi. I'm using update-maintainer to update the control file, but it seems it's not correct in karmic as gaspa told me 2 times it should be "Ubuntu Developer <ubuntu-devel-discuss@..." instead of the one generated by update-maintainer ("Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>"). Is it a know bug of update-maintainer?
[18:28] <geser> for a package in universe is MOTU correct (unless I missed a memo)
[18:28] <fabrice_sp> geser, that's exactly what I thought, but as I have been 'notified' 2 times, I don't know
[18:29] <geser> it might be related to ArchiveReorg
[18:31] <ScottK> It should still be MOTU.  Perhaps gaspa can explain.
[18:31] <fabrice_sp> ScottK, he is not online. I'll send him an email
[18:32] <fabrice_sp> but I wanted to check before. Thanks!
[18:35] <Ampelbein> fabrice_sp: according to https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028213.html it should be set to <ubuntu-devel-discuss@...>
[18:36] <Ampelbein> the (unreleased) update-maintainer from ubuntu-dev-tools' bzr does the right thing.
[18:37] <Ampelbein> geser: ^^
[18:37] <RoAkSoAx> here is the explanation for it: https://wiki.ubuntu.com/DebianMaintainerField
[18:37] <ScottK> OK.  Then I guess it's changed.
[18:38] <kb9vqf_> I am trying to get a fix into the official archives for bug 357556 , and have attached a debdiff/followed all the steps on https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue -- is there any way to speed the process along or do I just wait?
[18:40] <fabrice_sp> Ampelbein, thanks for that. How can I get the 'unrelease' version of update-maintainer? Or I have to patch it by myself (which is not complicated :-) )
[18:43] <Ampelbein> fabrice_sp: you can check out the newest ubuntu-dev-tools from: lp:ubuntu-dev-tools
[18:43] <fabrice_sp> Ampelbein, thanks!
[18:43] <Ampelbein> fabrice_sp: or you can download a deb from my ppa: https://edge.launchpad.net/~amoog/+archive/ppa/+files/ubuntu-dev-tools_0.75~amoogppa1_all.deb
[18:44] <fabrice_sp> even easier ;-)
[18:44] <fabrice_sp> thanks Ampelbein
[19:24] <Zhenech> could someone (late) sync pokerth for me (#392983)
[19:27] <fabrice_sp> bug #392983
[19:27] <Riddell> ** Kubuntu Tutorials Day starting in half an hour over in #kubuntu-devel  https://wiki.kubuntu.org/KubuntuTutorialsDay
[19:28] <fabrice_sp> Zhenech, do not assign to motu. Subscribe Ubuntu Sponsor for Universe instead
[19:28] <Zhenech> fabrice_sp, ah, ok
[19:29] <fabrice_sp> you can use requestsync for that: it does all the 'dirty' job :-)
[19:29] <Zhenech> and assign to nobody in the meantime?
[19:29] <Zhenech> does it exist on debian? I have no ubuntu machines here
[19:34] <Zhenech> my apt-file says no :(
[19:36] <Laney> Zhenech: packages.ubuntu.com
[19:36] <stefanlsd> is there any motu-sru that could look at bug #364745 for us please
[19:38] <fabrice_sp> Zhenech, yes: assign to nobody, and let is as New
[19:38] <Zhenech> Laney, that would pull some more ubuntu packages, I somewho dislike this :)
[19:38] <Laney> Zhenech: hmm? it has a search box
[19:39] <Zhenech> Laney, installing "ubuntu-dev-tools" from ubuntu on a debian box I mean
[19:39] <Laney> oh that wasn't my suggestion
[19:39] <fabrice_sp> ohh: that was me (with requestsync :-) )
[19:39] <Laney> you could grab the code from launchpad
[19:39] <Laney> should only require launchpadlib for requestsync
[19:41] <Laney> and debian-python apparently
[20:03] <julien__> hi ! is it ok to ask here for REVU reviews ?
[20:04] <julien__> ok just in case : my package is waiting for approval there : http://revu.ubuntuwire.com/p/flabber
[20:04] <julien__> thanks in advance !
[20:12] <fabrice_sp> julien__, did you check/fix the watch file?
[20:14] <julien__> fabrice_sp: yes at that time I didn't put any watch file at all ... there is one now
[20:14] <julien__> and the upstream version was uploaded in launchpad .. so I guess I'm all set
[20:21] <fabrice_sp> julien__, ok. I'll check ;-)
[20:26] <fabrice_sp> julien__, I'm getting no matching hrefs for watch line
[20:26] <fabrice_sp> so your watch file is not ok
[20:27] <fabrice_sp> I think mok0 said that it's http and not https
[20:27] <stefanlsd> RainCT: good news! got that license issue sorted out with gears. pushing new version to revu now. if you're still keen to advocate, that would be great!  :)
[20:27] <julien__> oh and it's still https, right
[20:28] <julien__> sorry it was a long time ago :/ I'm fixing it right now
[20:29] <RainCT> stefanlsd: great, good work! :)
[20:30] <RainCT> stefanlsd: I'll look at it tomorrow. Remember me if I don't do so.
[20:30] <stefanlsd> RainCT: kk. thanks!
[21:05] <gaspa> ls
[21:07] <stefanlsd> bin boot cdrom dev etc home lib lib32 lost+found mnt opt proc root selinux srv sys usr var
[21:07] <gaspa> geser, fabrice_sp: have you solved the Maintainer puzzle? :P
[21:07] <gaspa> I referred to this: https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028213.html and I saw that also it was update on  https://wiki.ubuntu.com/DebianMaintainerField
[21:09] <fabrice_sp> gaspa, yes :-D
[21:11] <fabrice_sp> as the update-maintainer script in Karmic is not yet updated, I had to use the version that Ampelbein has in his ppa ;-)
[21:11] <gaspa> fabrice_sp: I saw you already know about update-maintainer...
[21:11] <gaspa> right :P
[21:12] <gaspa> and about filing a debian bug, I know it's difficult, but on the other side they will use python2.6 sooner or later,
[21:18] <fabrice_sp> gaspa, I already filled some about python2.6, but they have been discarded
[21:18] <fabrice_sp> I used submittodebian for that
[21:18] <gaspa> discarded?
[21:19] <gaspa> fabrice_sp: do you mean the DD says "won't fix"?
[21:20] <fabrice_sp> gaspa, Hmmm, I have to check but even if the bug report stay open, the comments were close to a 'won't fix'
[21:20] <fabrice_sp> But i'll submit this one also
[21:20] <gaspa> fabrice_sp: yep, i think it's always worth trying.
[21:21] <fabrice_sp> Some other bug reports I made has been fixed in Debian, but none of python2.6
[21:21] <fabrice_sp> yep: I try to report all the ones that make sense
[21:23] <gaspa> fabrice_sp: keep me in CC, or attach the upstream bug in LP, please.
[21:23] <fabrice_sp> just sent the bug report. I'll attach the Debian bug report to LP
[21:24] <gaspa> fabrice_sp: thanks a lot ;)
[21:24] <fabrice_sp> thank you ;-)
[21:26] <fabrice_sp> Have to go now. Bye!
[21:28] <gaspa> fabrice_sp: bye! :)
[21:34] <POX> fabrice_sp: please point me to these python2.6 related bugs in Debian
[21:44] <asac> something is odd ... i cannot advocate on revu ... i could do that in the past
[21:47] <ajmitch> asac: what's your LP id?
[21:47] <asac> ajmitch: asac
[21:47] <asac> maybe i left the REVU team accidentially?
[21:48] <ajmitch> asac: I've set you as reviewer again
[21:48] <asac> indeed i was just uploader
[21:48] <asac> ajmitch: thanks.
[21:48]  * ajmitch doesn't know why :)
[21:48] <ajmitch> when could you last advocate?
[21:49] <asac> cant remember ;)
[21:49] <asac> wasnt really active in recent past
[21:49] <ajmitch> ah, so if it was awhile ago, things have changed a little :)
[21:49] <asac> okok
[21:49] <ajmitch> you probably had an old revu account which you could have merged
[21:49] <asac> ajmitch: i am now reviewer, however, in launchpad still member of uploaders team only
[21:50] <geser> gaspa: I see that update-maintainer in trunk is already fixed
[21:50] <ajmitch> yes, because I set you to reviewer manually, I'm not sure if team membership sets anything at the moment
[21:50] <ajmitch> if it did, it should probably get it from ~ubuntu-dev
[21:50] <asac> hmm ... okay
[21:51] <asac> yeah thats what i thought
[22:47] <kb9vqf_> ajmitch: A bunch of the 389 libraries passed build test...see https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa
[22:48] <kb9vqf_> We're still working on the main 389 server itself
[22:48] <kb9vqf_> In case you wanted to review them ;-)
[22:48] <ajmitch> probably this evening
[22:48] <ajmitch> and yeah, I'm lucky enough to get info about the PPA build failures now :)
[22:49] <kb9vqf_> :)
[22:49] <kb9vqf_> Can I set the maintainer field to the 389 team?
[22:49] <kb9vqf_> Or does it have to be an individual?
[22:50] <ajmitch> You'll probably need to set XSBC-Original-Maintainer to that, and Maintainer: to Ubuntu Developers
[22:50] <ajmitch> for Debian, a team is best if it's to be team-maintained
[22:51] <ajmitch> now if only you can get everyone to agree on where the packaging should go, whether it be svn.debian.org, or bzr on launchpad or elsewhere
[23:03] <ajmitch> james_w: what changes were made with regards to cutting down on bug spam & linking to LP branches?
[23:19] <julien__> hey, I just updated my package on REVU, if anyone feels like reviewing :D
[23:19] <julien__> it's there : http://revu.ubuntuwire.com/details.py?upid=6205
[23:36] <ryanprior> If I'm building a package and it fails in the end stages, is there a way I can run debuild again without having to recompile everything? I'm getting a bunch of messages like "dpkg-source: error: cannot represent change to ecere-sdk-0.44d2.1/ec/release/pass15.o: binary file contents changed" How can I start the process again without having to clean everything and compile over again?
[23:37] <RAOF> ryanprior: You can pass -nc to dpkg-buildpackage (& probably debuild, but I haven't tried that) to tell it to not run the "clean" target.
[23:38] <julien__> ahm quick question : how do I tell pbuilder to act like dpkg-buildpackage -S does ? if I want to upload the result to revu
[23:40] <julien__> curently with "pbuilder build --debbuildopts -S"  it says "dpkg-buildpackage: cannot combine -b and -S"
[23:40] <Ampelbein> julien__: why would you want pbuilder for that?
[23:40] <Ampelbein> julien__: debuild -S -sa from the source-dir will create the sourcepackage.
[23:42] <julien__> I see .. no point entering a specific distribution/arch chroot for just this action ?
[23:44] <ryanprior> RAOF: thanks
[23:44] <ryanprior> where is a good place to install sample code?
[23:45] <RAOF>  /usr/share/doc/$PACKAGENAME ?
[23:45] <Ampelbein> julien__: right.
[23:45] <ryanprior> RAOF: thanks again
[23:53] <julien__> ok thank you Ampelbein :) good night everybody
[23:54] <Ampelbein> julien__: you're welcome, good night.