=== yofel_ is now known as yofel [08:54] good morning [08:56] nothing good about it [08:57] aside form the fact that maybe in another 24 hours my brain will shut down and Ill pass out from sleep deprivation [10:06] 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] Rhonda: I did?!?!?! [10:08] Haven't you received the mail yet? :) [10:08] dunno, haven't got that far [10:08] haha [10:08] only as far as irssi :-) [10:09] ah, yes [10:09] woo! [10:09] * Laney makes an adult decision to do no real work for the time being [10:10] Rather make an adult decision to NOT read any archive of debian-private … and resign instantly again. :P [10:10] hah [10:11] 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] Don't take it personal is the best hint I can give. [10:11] O_O [10:11] now you've made me more curious [10:12] heh [10:12] Are you at debconf this year? [10:12] sadly couldn't afford any more time off work [10:12] :( [10:13] I spent some time with AbsintheSyringe at UDS though, and it sounds like it's going to be awesome [10:13] 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] white water rafting :-O [10:13] It _definitely_ will be awesome. [10:13] … or … well, depends. They asked me to run a track. %-/ [10:13] Really??? [10:14] * Rhonda has to bonk Absinthe, he didn't tell me! [10:14] maybe it's not confirmed or unofficial or ... [10:26] Laney: now it's time to make another pic with sebner, with your new email alias :) [10:26] oh, congrats btw! :) [10:26] trying to figure out how to log in :-P [10:27] crack it! [10:27] thanks! [10:43] Laney: It's all in the mail. Read it! :) [10:44] Rhonda: made it in :-) [10:45] propogation delay [11:20] Laney: so does that mean we get a load of haskell uploads shortly? ;-) [11:20] (congratulations!) [11:20] cjwatson: building some right now! [11:20] whee [11:20] ...using ubuntu's transition tracker [11:20] 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] intriguing === duanedeisgn is now known as duanedesign [11:57] Laney: http://justimho.blogspot.com/2011/04/directory-dependent-shell-configuration.html [11:57] cjwatson: Because that's updated manually. Guess we can prod zobel about that one. :) [11:58] Laney: Maybe that's what you are looking for - maybe it will give you hints for what you might want to do. [11:58] Rhonda: ah, yes, that's a good find. I didn't think about doing it that way [11:58] thanks! [11:58] ~/dev/ubuntu → DEBEMAIL=laney@ubuntu.com, ~/dev/debian → .d.o [11:58] * Rhonda nods [11:59] And for those shared stuff, maybe symlinking directories will work too [12:00] `cd src; ln -s . debian; ls -s . ubuntu` :) === UndiFineD is now known as hajour1 === hajour1 is now known as UndiFineD [15:09] 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 :) === Quintasan_ is now known as Quintasan === jdstrand_ is now known as jdstrand [15:55] Laney: Congrats! Party time :D [15:57] I am partying with a nice cup o'assam [15:59] :) [16:23] if anybody can review my merge proposal on http://pad.lv/mps/ubuntu-dev-tools I'd appreciate it :) [16:24] dholbach: I was just looking at it [16:24] yoohoo [16:24] * dholbach hugs tumbleweed [16:24] I don't think I ran into bug 336866 in a while. It's been marked fix committed for over a year :/ [16:24] Launchpad bug 336866 in lazr.restful "When adding tag or updating description, lp_save() gives "HTTP Error 412: Precondition Failed"" [High,Fix committed] https://launchpad.net/bugs/336866 [16:25] tumbleweed, it happened to me after I tagged it one and untagged it again [16:25] I wanted to make sure it works [16:25] try bug 779895 [16:25] Launchpad bug 779895 in Ubuntu "Test bug" [Undecided,Invalid] https://launchpad.net/bugs/779895 [16:25] (and it took me a while to find out what the issue was :)) [16:27] yeah, that's a pain. Esp as it causes extra round-trips [16:27] btw, it didn't seem to mind that the bug was already tagged bitesize [16:28] err, looking at the old version [16:28] dholbach: error_out doesn't need E:, it adds "Error: " [16:29] tumbleweed, fixed [16:30] hrm, I'm still not hitting that bug, with the workaround removed. But if you did, I guess it's necesseary [16:30] tumbleweed, also won't it let you add the same comment twice, but maybe I count that as a feature [16:30] tumbleweed, what I did first was bug.tags += ['bitesize'] which exposed the problem [16:32] ah. tag_bug(bug) seemed to work for me [16:32] yep [16:32] also, please close bug 785973 [16:32] Launchpad bug 785973 in ubuntu-dev-tools (Ubuntu) "[bitsize] code unreachable" [Low,New] https://launchpad.net/bugs/785973 [16:32] it looks like you fixed it [16:33] wow [16:33] indeed :/ [16:36] 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] I have no particular objection to that, however you just got entagled in a u-d-t to devscripts move [16:38] ugh ugh ugh, ok [16:38] you're right [16:38] can backport both :-) [16:38] I can try to make it a more specific kind of backport then :) [16:38] yeah, that's probably the best option [16:43] tumbleweed, thanks a lot for having a look over it [16:49] 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] tumbleweed, according to the LP bug it's necessary and I found another script in ubuntu-qa-tools to do the same [16:50] tumbleweed, I'll quickly fix the error_out thing though [16:51] ok [16:51] fixed the erroring out [16:51] it's ubuntu-qa-tools/launchpadlib-scripts/process-bug-with-patch.py if you're interested [16:52] landed in trunk, thanks [16:54] * dholbach hugs tumbleweed [16:54] fantastico! [16:54] 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] oh wow [16:56] friend's wedding, I was easily lured to stay for the festivities [16:56] yay for UK! [16:56] want to come up to nottingham? [16:57] that is quite far :) [16:57] 2 hours on the train from london [17:00] ah, that's not too bad. today probably would have been best for something like that, though :/ [17:02] ah well [17:03] * tumbleweed will see if a free day or two crops up, but I'm heading home on saturday [17:05] oh nice [17:06] 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] I did a few uploads with the overridden maintainer, hope it doesn't matter too much :/ [17:08] What was wrong with mk-sbuild? [17:08] Laney: Congratulations. [17:08] Looks like it's been there since the beginning (kees?) [17:08] persia: bug 787051 [17:08] Launchpad bug 787051 in ubuntu-dev-tools (Ubuntu) "mk-sbuild is untruthful" [Undecided,New] https://launchpad.net/bugs/787051 [17:09] That used to be true, but isn't now. [17:10] ah, thanks [17:10] 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] With luck, mk-schroot will be replaced with a wrapper for sbuild-createchroot for oneiric, and be dropped for the following release. [17:11] (this mostly depends on me unwinding the differences, since the two are implemented in different languages, and have rather different program flow) [17:12] right, you took that on in the udt session [17:13] I'll quickly fix this in the meantime [17:13] 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] 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] one needs to do binary uploads for Debian [17:16] I prepare those by running dpkg-buildpackage in a schroot, rather than using sbuild. Maybe I'm doing it wrong. [17:17] I thought that was the purpose of sbuild? :) [17:20] 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] 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] (If I'd known it was destined for the chopping board... ) [17:20] Oh, you fixed it? I hadn't run mk-sbuild since release week, and wasn't following commits. [17:20] Thanks! [17:21] heh, np [17:48] Hey, anyone up for reviewing http://revu.ubuntuwire.com/p/l2tp-ipsec-vpn [17:55] 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] tumbleweed: o.k. I'll try it also in debian [18:06] wejaeger: Check wiki.debian.org/Teams for an appropriate team to find sponsorship — I recommend that above mentors [18:16] Laney: thanks for that information ... [18:55] debfx: do you need anything else for that virtualbox bug? you marked it as incomplete [18:58] micahg: what's the bug no? [19:00] bug 746209 [19:00] Launchpad bug 746209 in virtualbox-ose (Ubuntu) "Need to call modprobe vboxdrv after every restart" [Undecided,Incomplete] https://launchpad.net/bugs/746209 [19:10] micahg: does running the init script manually load the modules? [19:12] debfx: yes [19:17] micahg: so are you sure that the init script is run on boot? [19:22] debfx: no [19:22] but shouldn't it be run on boot by default? I didn't modify it AFAIK [19:25] micahg: yes it should [19:26] are the symlinks in /etc/rc* still there? e.g. /etc/rc2.d/S20virtualbox-ose [19:35] 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] germinate or totally-empty-outside-debian/ with a rather full control file and a minimal dh rules file? [19:36] debfx: I have a vboxdrv and a vboxweb-service in there [19:37] micahg: those are from the Oracle packages [19:37] 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] maco: before discussing the meta package: how many package / mb are pulled in with quilt and debhelper? [19:37] maco: What's the purpose of the metapackage? [19:38] persia: https://code.launchpad.net/~maco.m/ubuntu-dev-tools/fix-786370/+merge/61881 [19:38] persia: your opinion? [19:38] debfx: ugh, ok, so maybe that's what broke it, can we make migration to the -ose pacakges easier? [19:38] persia: something like "packaging-dev", an everything you need for building most packages type thing [19:39] I don't care one way or another. Based on the UDS session, I think u-d-t is temporary. [19:39] micahg: I recommend purging those packages, but I'm not sure if they actually cause problems [19:40] persia: things like requestsync will probably always live in u-d-t (or something like "derivatives-tools") [19:40] persia: u-d-t is temporary? [19:40] 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] micahg: so /etc/rc2.d/S20virtualbox-ose doesn't exist? [19:40] debfx: nope [19:40] persia: yeah, that's what I'm thinking [19:41] 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] micahg: that's weired, could you try reinstalling virtualbox-ose [19:42] persia: hrm, I didn't get that impression from the lptools session / poolie (requestsync, not native-source-sync, for that: \o/) [19:42] tumbleweed: I had the impression poolie wanted lptools to be able to do anything one could do with the API. [19:42] Native-source-sync would expose sync requests as an API operation as a first pass. [19:43] So I'm not sure we'd need a separate tool. [19:43] we'd still need the tool for sponsorees [19:44] There'S a solution to that, but it escapes me now. Hrmmm.... [19:44] debfx: it's K19virtualbox-ose [19:45] and people are always going to write lots of little unfinished, ubuntu-specific scripts [19:45] debfx: s/it's/there's// [19:46] Do you believe that we should tell nascent developers to install "lots of little unfinished ... scripts"? [19:47] micahg: aha, so something disabled the init script [19:47] 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] considering we're a linux distribution, putting them in a package seems pretty sensible [19:48] 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] micahg: "update-rc.d virtualbox-ose enable" should fix that [19:49] 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] persia: right, I'm with you there. Although at the moment it seems to be a reasonable place [19:49] 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] persia: im actually trying to make a metapackage source package from scratch right now and failing to find documentation via google [19:49] maco: OK. So, here's what you do. [19:49] well documentation other than "do it backwards and run dpkg-deb --build" [19:50] mostly i just dont know what to do with debian/rules when there's no build system [19:50] also i think we have a meeting in 10 minutes. and quorum as well! [19:50] 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] maco: rules: dh $@ --with germinate [19:51] bdrung_: germinate is overkill for this. [19:51] so just dh $@ ? [19:51] yes [19:51] Yeah. [19:51] funky [19:52] 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] sebner: Your mail is up on one of my screens: I just need to type a reply (although I'll refresh) [19:54] persia: As I said, no rush! Take your time :) [20:02] geser: dmb? [20:03] debfx: it started now :) === hannesw_ is now known as hannesw [20:36] Should I use a special tool to update the changelog ? [20:36] ikus060: dch [20:37] Thanks will look at it [21:08] I'm creating a source package for daily build, do you have any suggestion to the package version ? [21:17] I think that it would like ${MAJOR}.${MINOR}~bzr${REVISION_NUMBER}, ikus060 but I'm a noob at packaging work :/ [21:18] @JackyAlcine : I'm too [21:20] ${MAJOR}.${MINOR}-${REVISION}~${RFCTIME}~${distro}${increment} [21:20] like 0.01-4~201105071919~natty1 [21:20] * JackyAlcine shrugs in unsureness again. [21:20] is this package in ubuntu? [21:22] I'd generally say include the words ppa and/or daily in the version, so it's obvious what it is [21:22] 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] I pulled that from a version number from a PPA I look for (more like use and own, lol). [21:25] https://launchpad.net/~wintermute-devel/+archive/wintermute-experimental [21:25] it makes sense to use the same versioning scheme as everyone else who packages this package [21:25] 0.01-4~201105071919 is lower than 0.0.1-4 [21:26] It's not the other way around? How come? [21:26] ~ is special http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version [21:27] * JackyAlcine learned something new today. [21:28] that's we do things like ~lucid1 for ppa uploads [21:28] so that you upgrade from 0.1-1~lucid1 to the 0.1-1 published in Ubuntu in a release after lucid [21:28] +1 [21:29] 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] if they have a significant delta, bump the major ID anyway :) [21:30] well ~ppaN almost always makes sense too [21:30] if you want the same version in maverick and natty, you need to copy, you can't source upload it to both [21:31] truth [21:31] 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] Thanks tumbleweed and paultag. [21:32] ikus060, I hope this answered your question as well. [21:32] * paultag waves to JackyAlcine [21:38] @JackyAlcine So ${UPSTREAM_VERSION}+${RFCTIME}~natty1 [21:38] Am I right ? [21:39] ikus060: is this package in Ubuntu already? [21:39] nope [21:39] ok, the nit doesn't matter too much. Otherwise you'd probably want to take the versioning used in Ubuntu in account [21:40] Which mean ? I'm noobs. I need a bit more explanation .. sorry [21:40] it means that's fine [21:40] So ${UPSTREAM_VERSION}+${RFCTIME}~natty1 is OK [21:41] may I replace the ${RCFTIME} by svn${REVISION} [21:43] assuming the bzr revision in the bzr import matches the svn revision [21:43] otherwise it may make more sense to say "bzr" instead of "svn" [21:44] you may also want to include your packaging revision, so you can make packaging changes without waiting for new upstream commits [21:44] tumbleweed: btw, most scripts are moved to devscripts [21:45] bdrung_: yay, I guess I have some e-mails to write [21:47] @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] ikus060: I thought you were talking about automated daily builds [21:48] yep [21:48] I miss something ? [21:48] those can only build bzr branches i nlaunchpad [21:48] you can import svn repositories into launchpad (where they will be bzr branches) [21:49] I see, So I need to place all the code in one branch : the svn repo + the debian directory ? [21:51] 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] Hi, I'm trying to build packages for natty but can't find devscripts anymore . [22:22] nevermind, sorry for the noise [22:45] tumbleweed: can you review my commits to u-d-t? [22:48] tumbleweed: any progress on the distro-info naming? [22:50] bdrung_: r1088 is obviously good, although there's still an unecessary \ :) [22:51] tumbleweed: feel free to remove it [22:55] tumbleweed: and r1087? [22:58] bdrung_: yeah, I think it's good. It will obviously not be buildable in the PPA until we have that devscripts [22:59] tumbleweed: yes, we have to backport devscripts once it is released [23:13] maco: ping me if you have a metapackage prepared [23:18] (packaging-dev)