[08:54] <dholbach> good morning
[08:56] <X3lectric> nothing good about it
[08:57] <X3lectric> aside form the fact that maybe in another 24 hours my brain will shut down and Ill pass out from sleep deprivation
[10:06] <Rhonda> All congratulate Laney on becoming a Debian Developer.  ;)
[10:08]  * Rhonda . o O ( http://db.debian.org/search.cgi?dosearch=1&uid=laney )
[10:08] <Laney> Rhonda: I did?!?!?!
[10:08] <Rhonda> Haven't you received the mail yet? :)
[10:08] <Laney> dunno, haven't got that far
[10:08] <Rhonda> haha
[10:08] <Laney> only as far as irssi :-)
[10:09] <Laney> ah, yes
[10:09] <Laney> woo!
[10:09]  * Laney makes an adult decision to do no real work for the time being 
[10:10] <Rhonda> Rather make an adult decision to NOT read any archive of debian-private … and resign instantly again. :P
[10:10] <Laney> hah
[10:11] <Rhonda> Just be aware that Debian doesn't has a CoC - and (gladly a few, but still rather vocal) see it as their right to … "behave" they way they do.
[10:11] <Rhonda> Don't take it personal is the best hint I can give.
[10:11] <Laney> O_O
[10:11] <Laney> now you've made me more curious
[10:12] <Rhonda> heh
[10:12] <Rhonda> Are you at debconf this year?
[10:12] <Laney> sadly couldn't afford any more time off work
[10:12] <Rhonda> :(
[10:13] <Laney> I spent some time with AbsintheSyringe at UDS though, and it sounds like it's going to be awesome
[10:13] <Rhonda> And I wasn't able to take time off for UDS, even though the trip would had been pretty short from me to there. :/
[10:13] <Laney> white water rafting :-O
[10:13] <Rhonda> It _definitely_ will be awesome.
[10:13] <Rhonda> … or … well, depends. They asked me to run a track.  %-/
[10:13] <Rhonda> Really???
[10:14]  * Rhonda has to bonk Absinthe, he didn't tell me!
[10:14] <Laney> maybe it's not confirmed or unofficial or ...
[10:26] <DktrKranz> Laney: now it's time to make another pic with sebner, with your new email alias :)
[10:26] <DktrKranz> oh, congrats btw! :)
[10:26] <Laney> trying to figure out how to log in :-P
[10:27] <DktrKranz> crack it!
[10:27] <Laney> thanks!
[10:43] <Rhonda> Laney: It's all in the mail. Read it! :)
[10:44] <Laney> Rhonda: made it in :-)
[10:45] <Laney> propogation delay
[11:20] <cjwatson> Laney: so does that mean we get a load of haskell uploads shortly? ;-)
[11:20] <cjwatson> (congratulations!)
[11:20] <Laney> cjwatson: building some right now!
[11:20] <cjwatson> whee
[11:20] <Laney> ...using ubuntu's transition tracker
[11:20] <Laney> go figure
[11:21]  * cjwatson wonders idly why https://nm.debian.org/nmstatus.php?email=laney%40ubuntu.com still says "Account Created: No"
[11:27] <Laney> intriguing
[11:57] <Rhonda> Laney: http://justimho.blogspot.com/2011/04/directory-dependent-shell-configuration.html
[11:57] <Rhonda> cjwatson: Because that's updated manually. Guess we can prod zobel about that one. :)
[11:58] <Rhonda> Laney: Maybe that's what you are looking for - maybe it will give you hints for what you might want to do.
[11:58] <Laney> Rhonda: ah, yes, that's a good find. I didn't think about doing it that way
[11:58] <Laney> thanks!
[11:58] <Laney> ~/dev/ubuntu → DEBEMAIL=laney@ubuntu.com, ~/dev/debian → .d.o
[11:58]  * Rhonda nods
[11:59] <Rhonda> And for those shared stuff, maybe symlinking directories will work too
[12:00] <persia> `cd src; ln -s . debian; ls -s . ubuntu` :)
[15:09] <dholbach> tumbleweed, I just made a couple of changes to the bitesize script - I hope it makes a bit more sense now and we can announce it properly :)
[15:55] <nigelb> Laney: Congrats! Party time :D
[15:57] <Laney> I am partying with a nice cup o'assam
[15:59] <nigelb> :)
[16:23] <dholbach> if anybody can review my merge proposal on http://pad.lv/mps/ubuntu-dev-tools I'd appreciate it :)
[16:24] <tumbleweed> dholbach: I was just looking at it
[16:24] <dholbach> yoohoo
[16:24]  * dholbach hugs tumbleweed
[16:24] <tumbleweed> I don't think I ran into bug 336866 in a while. It's been marked fix committed for over a year :/
[16:25] <dholbach> tumbleweed, it happened to me after I tagged it one and untagged it again
[16:25] <dholbach> I wanted to make sure it works
[16:25] <dholbach> try bug 779895
[16:25] <dholbach> (and it took me a while to find out what the issue was :))
[16:27] <tumbleweed> yeah, that's a pain. Esp as it causes extra round-trips
[16:27] <tumbleweed> btw, it didn't seem to mind that the bug was already tagged bitesize
[16:28] <tumbleweed> err, looking at the old version
[16:28] <tumbleweed> dholbach: error_out doesn't need E:, it adds "Error: "
[16:29] <dholbach> tumbleweed, fixed
[16:30] <tumbleweed> hrm, I'm still not hitting that bug, with the workaround removed. But if you did, I guess it's necesseary
[16:30] <dholbach> tumbleweed, also won't it let you add the same comment twice, but maybe I count that as a feature
[16:30] <dholbach> tumbleweed, what I did first was    bug.tags += ['bitesize']     which exposed the problem
[16:32] <tumbleweed> ah. tag_bug(bug) seemed to work for me
[16:32] <dholbach> yep
[16:32] <tumbleweed> also, please close bug 785973
[16:32] <tumbleweed> it looks like you fixed it
[16:33] <dholbach> wow
[16:33] <tumbleweed> indeed :/
[16:36] <dholbach> tumbleweed, once it lands, what do you think about backporting ubuntu-dev-tools? I think it'd be nice to have it in natty at least :)
[16:37] <tumbleweed> I have no particular objection to that, however you just got entagled in a u-d-t to devscripts move
[16:38] <dholbach> ugh ugh ugh, ok
[16:38] <dholbach> you're right
[16:38] <Laney> can backport both :-)
[16:38] <dholbach> I can try to make it a more specific kind of backport then :)
[16:38] <tumbleweed> yeah, that's probably the best option
[16:43] <dholbach> tumbleweed, thanks a lot for having a look over it
[16:49] <tumbleweed> dholbach: do we still need to fetch that bug twice? And you may want to error_out instead of printing in save_entry
[16:50] <dholbach> tumbleweed, according to the LP bug it's necessary and I found another script in ubuntu-qa-tools to do the same
[16:50] <dholbach> tumbleweed, I'll quickly fix the error_out thing though
[16:51] <tumbleweed> ok
[16:51] <dholbach> fixed the erroring out
[16:51] <dholbach> it's ubuntu-qa-tools/launchpadlib-scripts/process-bug-with-patch.py if you're interested
[16:52] <tumbleweed> landed in trunk, thanks
[16:54]  * dholbach hugs tumbleweed
[16:54] <dholbach> fantastico!
[16:54] <dholbach> tumbleweed, how is life over there? did you end up with too many work items from UDS as well? ;-)
[16:55]  * tumbleweed hasn't actually got home yet, detoured via London, and so haven't made inroads into work items yet :)
[16:55] <dholbach> oh wow
[16:56] <tumbleweed> friend's wedding, I was easily lured to stay for the festivities
[16:56] <Laney> yay for UK!
[16:56] <Laney> want to come up to nottingham?
[16:57] <tumbleweed> that is quite far :)
[16:57] <Laney> 2 hours on the train from london
[17:00] <tumbleweed> ah, that's not too bad. today probably would have been best for something like that, though :/
[17:02] <Laney> ah well
[17:03]  * tumbleweed will see if a free day or two crops up, but I'm heading home on saturday
[17:05] <dholbach> oh nice
[17:06] <tumbleweed> Laney: ah, good catch with mk-sbuild. I should have picked that up when I was looking at it (I commented it out in my configuration file)
[17:06] <Laney> I did a few uploads with the overridden maintainer, hope it doesn't matter too much :/
[17:08] <persia> What was wrong with mk-sbuild?
[17:08] <ScottK> Laney: Congratulations.
[17:08] <tumbleweed> Looks like it's been there since the beginning (kees?)
[17:08] <tumbleweed> persia: bug 787051
[17:09] <persia> That used to be true, but isn't now.
[17:10] <tumbleweed> ah, thanks
[17:10] <persia> There's lots of cruft building up in mk-sbuild, some because of sbuild changes, and some because sbuild-createchroot is becoming more mature.
[17:10] <persia> With luck, mk-schroot will be replaced with a wrapper for sbuild-createchroot for oneiric, and be dropped for the following release.
[17:11] <persia> (this mostly depends on me unwinding the differences, since the two are implemented in different languages, and have rather different program flow)
[17:12] <tumbleweed> right, you took that on in the udt session
[17:13] <tumbleweed> I'll quickly fix this in the meantime
[17:13] <persia> Yep.  Of the three authors of mk-sbuild, I was the attendee, and we've been talking about doing that for a couple cycles anyway.
[17:14] <persia> If you think it's worth it, go ahead :)  It only affects the generated binaries, which I don't think are suitable for upload anyway (better to run dpkg-buildpackage/debuild within a clean chroot to replicate common behaviour if one must do a binary upload).
[17:15] <tumbleweed> one needs to do binary uploads for Debian
[17:16] <persia> I prepare those by running dpkg-buildpackage in a schroot, rather than using sbuild.  Maybe I'm doing it wrong.
[17:17] <tumbleweed> I thought that was the purpose of sbuild? :)
[17:20] <tumbleweed> persia: oh, I missed your comment on the bug. BTW I fixed the conf.d issue in the last u-d-t upload
[17:20] <persia> I use sbuild for *testing* package builds as they might run on the buildd, and as the basis for the buildd network I'm trying to construct.
[17:20] <tumbleweed> (If I'd known it was destined for the chopping board... )
[17:20] <persia> Oh, you fixed it?  I hadn't run mk-sbuild since release week, and wasn't following commits.
[17:20] <persia> Thanks!
[17:21] <tumbleweed> heh, np
[17:48] <wejaeger> Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn
[17:55] <tumbleweed> wejaeger: new packages really should be submitted to Debian when possible. I think it's also a better place to maintain them (of course, keep an eye on them in Ubuntu, too)
[17:59] <wejaeger> tumbleweed: o.k. I'll try it also in debian
[18:06] <Laney> wejaeger: Check wiki.debian.org/Teams for an appropriate team to find sponsorship — I recommend that above mentors
[18:16] <wejaeger> Laney: thanks for that information ...
[18:55] <micahg> debfx: do you need anything else for that virtualbox bug?  you marked it as incomplete
[18:58] <debfx> micahg: what's the bug no?
[19:00] <micahg> bug 746209
[19:10] <debfx> micahg: does running the init script manually load the modules?
[19:12] <micahg> debfx: yes
[19:17] <debfx> micahg: so are you sure that the init script is run on boot?
[19:22] <micahg> debfx: no
[19:22] <micahg> but shouldn't it be run on boot by default?  I didn't modify it AFAIK
[19:25] <debfx> micahg: yes it should
[19:26] <debfx> are the symlinks in /etc/rc* still there? e.g. /etc/rc2.d/S20virtualbox-ose
[19:35] <maco> so, trying to make a metapackage. pretty sure http://forums.debian.net/viewtopic.php?t=30271 is the *wrong* way to go about it, so...
[19:36] <maco> germinate or totally-empty-outside-debian/ with a rather full control file and a minimal dh rules file?
[19:36] <micahg> debfx: I have a vboxdrv and a vboxweb-service in there
[19:37] <debfx> micahg: those are from the Oracle packages
[19:37] <tumbleweed> maco: Hi, Either it could be a standalone package, or it could just be an empty binary package from ubuntu-dev-tools, or a non-empty one with things like setup-packaging-environment in it.
[19:37] <bdrung_> maco: before discussing the meta package: how many package / mb are pulled in with quilt and debhelper?
[19:37] <persia> maco: What's the purpose of the metapackage?
[19:38] <bdrung_> persia: https://code.launchpad.net/~maco.m/ubuntu-dev-tools/fix-786370/+merge/61881
[19:38] <bdrung_> persia: your opinion?
[19:38] <micahg> debfx: ugh, ok, so maybe that's what broke it, can we make migration to the -ose pacakges easier?
[19:38] <tumbleweed> persia: something like "packaging-dev", an everything you need for building most packages type thing
[19:39] <persia> I don't care one way or another.  Based on the UDS session, I think u-d-t is temporary.
[19:39] <debfx> micahg: I recommend purging those packages, but I'm not sure if they actually cause problems
[19:40] <tumbleweed> persia: things like requestsync will probably always live in u-d-t (or something like "derivatives-tools")
[19:40] <bdrung_> persia: u-d-t is temporary?
[19:40] <persia> I think it would make sense to have a "grab everything you need to work on packages" package.  I'd build such a metapackage with manual dependencies in debian/control (there aren't that many)
[19:40] <debfx> micahg: so /etc/rc2.d/S20virtualbox-ose doesn't exist?
[19:40] <micahg> debfx: nope
[19:40] <tumbleweed> persia: yeah, that's what I'm thinking
[19:41] <persia> tumbleweed: No, requestsync will end up as part of lptools, once Native-Source-Sync is implemented, and I was told at UDS this was really close.
[19:41] <debfx> micahg: that's weired, could you try reinstalling virtualbox-ose
[19:42] <tumbleweed> persia: hrm, I didn't get that impression from the lptools session / poolie (requestsync, not native-source-sync, for that: \o/)
[19:42] <persia> tumbleweed: I had the impression poolie wanted lptools to be able to do anything one could do with the API.
[19:42] <persia> Native-source-sync would expose sync requests as an API operation as a first pass.
[19:43] <persia> So I'm not sure we'd need a separate tool.
[19:43] <tumbleweed> we'd still need the tool for sponsorees
[19:44] <persia> There'S a solution to that, but it escapes me now.  Hrmmm....
[19:44] <micahg> debfx: it's K19virtualbox-ose
[19:45] <tumbleweed> and people are always going to write lots of little unfinished, ubuntu-specific scripts
[19:45] <micahg> debfx: s/it's/there's//
[19:46] <persia> Do you believe that we should tell nascent developers to install "lots of little unfinished ... scripts"?
[19:47] <debfx> micahg: aha, so something disabled the init script
[19:47] <tumbleweed> persia: heh, yeah that's the obvious related question. It makes sense that we can share them with each other rather than all implement them independently
[19:48] <tumbleweed> considering we're a linux distribution, putting them in a package seems pretty sensible
[19:48] <persia> tumbleweed: Absolutely, but I remain unconvinced that u-d-t is the place for maco's list of things a nascent developer should install.
[19:48] <debfx> micahg: "update-rc.d virtualbox-ose enable" should fix that
[19:49] <ikus060> Hi there, I've done alot of work to package iFolder with other people and now I want to bring it to a new step. I want to know whats the best bay the debianize a project. Where do I keep the debian folder ? I'm thinking to keep it in launchpad so I can later on create a PPA. Do someone have some bestpractices for me ?
[19:49] <tumbleweed> persia: right, I'm with you there. Although at the moment it seems to be a reasonable place
[19:49] <bdrung_> it look like the preferred solution is to create a metapackage "packaging-dev" that depends on every a packager wants to have installed.
[19:49] <maco> persia: im actually trying to make a metapackage source package from scratch right now and failing to find documentation via google
[19:49] <persia> maco: OK.  So, here's what you do.
[19:49] <maco> well documentation other than "do it backwards and run dpkg-deb --build"
[19:50] <maco> mostly i just dont know what to do with debian/rules when there's no build system
[19:50] <maco> also i think we have a meeting in 10 minutes. and quorum as well!
[19:50] <persia> Make a directory.  Make a directory in that called "debian".  Populate it with template rules, changelog, copyright, compat.  Create a control file with Section: metapackages (double-check my spelling), and appropriate Depends and Recommrnds.  Done.
[19:50] <bdrung_> maco: rules: 	dh $@ --with germinate
[19:51] <persia> bdrung_: germinate is overkill for this.
[19:51] <maco> so just dh $@  ?
[19:51] <bdrung_> yes
[19:51] <persia> Yeah.
[19:51] <maco> funky
[19:52] <sebner> persia: just added 6 lines. no need to rush but I'll keep you reminding now and then to help you fix your #1 bug :P
[19:54] <persia> sebner: Your mail is up on one of my screens: I just need to type a reply (although I'll refresh)
[19:54] <sebner> persia: As I said, no rush! Take your time :)
[20:02] <Laney> geser: dmb?
[20:03] <micahg> debfx: it started now :)
[20:36] <ikus060> Should I use a special tool to update the changelog ?
[20:36] <micahg> ikus060: dch
[20:37] <ikus060> Thanks will look at it
[21:08] <ikus060> I'm creating a source package for daily build, do you have any suggestion to the package version ?
[21:17] <JackyAlcine> I think that it would like ${MAJOR}.${MINOR}~bzr${REVISION_NUMBER}, ikus060 but I'm a noob at packaging work :/
[21:18] <ikus060> @JackyAlcine : I'm too
[21:20] <JackyAlcine> ${MAJOR}.${MINOR}-${REVISION}~${RFCTIME}~${distro}${increment}
[21:20] <JackyAlcine> like 0.01-4~201105071919~natty1
[21:20]  * JackyAlcine shrugs in unsureness again.
[21:20] <tumbleweed> is this package in ubuntu?
[21:22] <tumbleweed> I'd generally say include the words ppa and/or daily in the version, so it's obvious what it is
[21:22] <tumbleweed> you probably want + rather than ~ for ${RFCTIME}, or you'll have to downgrade to these packages
[21:23]  * tumbleweed tends to prefer revision numbers to time, but that also depends on VCS. Revision numbers are safe for launchpad imports.
[21:24] <JackyAlcine> I pulled that from a version number from a PPA I look for (more like use and own, lol).
[21:25] <JackyAlcine> https://launchpad.net/~wintermute-devel/+archive/wintermute-experimental
[21:25] <tumbleweed> it makes sense to use the same versioning scheme as everyone else who packages this package
[21:25] <tumbleweed> 0.01-4~201105071919 is lower than 0.0.1-4
[21:26] <JackyAlcine> It's not the other way around? How come?
[21:26] <tumbleweed> ~ is special http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[21:27]  * JackyAlcine learned something new today.
[21:28] <tumbleweed> that's we do things like ~lucid1 for ppa uploads
[21:28] <tumbleweed> so that you upgrade from 0.1-1~lucid1 to the 0.1-1 published in Ubuntu in a release after lucid
[21:28] <paultag> +1
[21:29] <paultag> I usually use ~ppaN since if I do a multi dist upload, most of the time they are the same, so there's no reason ~maverick needs to be overridden by ~natty
[21:29] <paultag> if they have a significant delta, bump the major ID anyway :)
[21:30] <tumbleweed> well ~ppaN almost always makes sense too
[21:30] <tumbleweed> if you want the same version in maverick and natty, you need to copy, you can't source upload it to both
[21:31] <paultag> truth
[21:31] <tumbleweed> and for certain packages, you do want it to be upgraded whenever the user dist-upgrades (i.e. when something excternal, like a library or python version has changed, and the package needed to be rebuilt)
[21:32]  * JackyAlcine makes a note.
[21:32] <JackyAlcine> Thanks tumbleweed and paultag.
[21:32] <JackyAlcine> ikus060, I hope this answered your question as well.
[21:32]  * paultag waves to JackyAlcine 
[21:38] <ikus060> @JackyAlcine So ${UPSTREAM_VERSION}+${RFCTIME}~natty1
[21:38] <ikus060> Am I right ?
[21:39] <tumbleweed> ikus060: is this package in Ubuntu already?
[21:39] <ikus060> nope
[21:39] <tumbleweed> ok, the nit doesn't matter too much. Otherwise you'd probably want to take the versioning used in Ubuntu in account
[21:40] <ikus060> Which mean ? I'm noobs. I need a bit more explanation .. sorry
[21:40] <tumbleweed> it means that's fine
[21:40] <ikus060> So ${UPSTREAM_VERSION}+${RFCTIME}~natty1 is OK
[21:41] <ikus060> may I replace the ${RCFTIME} by svn${REVISION}
[21:43] <tumbleweed> assuming the bzr revision in the bzr import matches the svn revision
[21:43] <tumbleweed> otherwise it may make more sense to say "bzr" instead of "svn"
[21:44] <tumbleweed> you may also want to include your packaging revision, so you can make packaging changes without waiting for new upstream commits
[21:44] <bdrung_> tumbleweed: btw, most scripts are moved to devscripts
[21:45] <tumbleweed> bdrung_: yay, I guess I have some e-mails to write
[21:47] <ikus060> @tumbleweed: Ho, you got me confused. The bzr branche only contains the /debian/ directory. The source is checkout from a svn repository.  I tought ~natty1 was used to keep track of packaging changes.
[21:48] <tumbleweed> ikus060: I thought you were talking about automated daily builds
[21:48] <ikus060> yep
[21:48] <ikus060> I miss something ?
[21:48] <tumbleweed> those can only build bzr branches i nlaunchpad
[21:48] <tumbleweed> you can import svn repositories into launchpad (where they will be bzr branches)
[21:49] <ikus060> I see, So I need to place all the code in one branch : the svn repo + the debian directory ?
[21:51] <tumbleweed> ikus060: there are different ways of doing this, see the pages on the lp wiki. Also as this isn't an existing package in Ubuntu universe, #ubuntu-packaging may be a better place to find help (although it's currently quite here, so there's no problem)
[22:22] <dachary> Hi, I'm trying to build packages for natty but can't find devscripts anymore .
[22:22] <dachary> nevermind, sorry for the noise
[22:45] <bdrung_> tumbleweed: can you review my commits to u-d-t?
[22:48] <bdrung_> tumbleweed: any progress on the distro-info naming?
[22:50] <tumbleweed> bdrung_: r1088 is obviously good, although there's still an unecessary \ :)
[22:51] <bdrung_> tumbleweed: feel free to remove it
[22:55] <bdrung_> tumbleweed: and r1087?
[22:58] <tumbleweed> bdrung_: yeah, I think it's good. It will obviously not be buildable in the PPA until we have that devscripts
[22:59] <bdrung_> tumbleweed: yes, we have to backport devscripts once it is released
[23:13] <bdrung_> maco: ping me if you have a metapackage prepared
[23:18] <bdrung_> (packaging-dev)