[00:53] <freeflying> wodering how can I know which package I have right to upload, anybody has any clues?
[00:55] <micahg> freeflying: you can use the edit_acl.py scripts in lp:ubuntu-archive-tools
[00:56] <freeflying> micahg: thanks, what about I want the right to upload some specific package, whats the process to apply for it?
[00:57] <micahg> freeflying: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders
[01:22] <freeflying> micahg: thanks
[01:42] <nathanbelomy> Hey guys, anyone want to decode some 64 binary, new string line execution for run level 7? It's C++ 3/4. GNU License, I'll add more later.
[01:42] <nathanbelomy> http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7
[01:44] <nathanbelomy> anyone here?
[02:02] <poolie> nathanbelomy: wtf is that?
[06:08] <micahg> ScottK: not that ubuntu-dev has PPU, should we revisit the newpackage wiki that says sign off by 2 Ubuntu developers, for some reason I thought it was 2 MOTUs, was that incorrect?
[06:08] <micahg> s/not/now
[06:08] <ScottK> At the time it was written those two were synonymous.
[06:09] <ScottK> I think MOTU is correct in the current context.
[06:09] <micahg> right, but is my understanding correct, 2 MOTU ACKs required (core-dev is considered a MOTU)
[06:10] <ScottK> For packages by non-MOTU.
[06:11] <ScottK> It's actually a bit trickier.
[06:11] <ScottK> For example I think a kubuntu-dev ack on a package should certainly count.
[06:11] <ScottK> (I would trust any kubuntu-dev to not comment on things outside their expertise)
[06:12] <ScottK> OTOH, the difference between PPU and kubuntu-dev is just scale.
[06:13] <ScottK> Meh.
[06:13] <micahg> ScottK: well, ok, but still, 2 ACKs are required, right?
[06:13] <ScottK> I think motu is right rule.
[06:13] <ScottK> For packages by non-motu, yes.
[06:13] <ScottK> For MOTU the 2nd ack is suggested, but not required.
[06:28] <micahg> ScottK: wiki fixed
[06:31] <ScottK> Thanks.
[07:59] <bludude> how should i create a debian/watch for a project that's hosted on launchpad but doesn't produce tarballs?
[08:04] <geser> then you can't. do you use checkouts for the .orig.tar.gz?
[08:10] <mase_wk> i find the whole orig.tar.gz thing quite annoying and redundant
[08:10] <mase_wk> not that my opinion counts for anything
[08:12] <bludude> all we have is a bazaar repo on launchpad
[08:22] <geser> bludude: then you can ignore the debian/watch file (as there is nothing to watch).
[08:22] <bludude> alright, thanks.
[08:54] <dholbach> good morning
[08:55] <xdatap1> dholbach, morning!
[08:56] <dholbach> hey xdatap1
[08:56] <BlackZ> morning dholbach :)
[08:57] <dholbach> hey BlackZ
[09:46]  * Rhonda sighs at the screenshot in Mohamad's Xlog post …
[10:36] <Laney> warp10: thanks for your package, I based the debian package on it: http://ftp-master.debian.org/new/sparkleshare_0.2.2-1.html
[10:36] <Laney> kept your changelog entries and copyright :-)
[10:55] <Daviey> Laney: kinda confusing changelog :).. Suggests it is currently in oneiric archive. :)
[10:56] <Laney> hah
[10:56] <Laney> I hope the 'ppa' in the version helps there
[12:11] <warp10> Laney: great! After it is accepted and synced I will keep my PPA just for backports to stable Ubuntu release
[12:13] <warp10> Laney: and I'm sure our friend ftp-assistant Dktrkranz  will be happy to give love to sparkleshare accpeting it ASAP from the Debian NEW queue... /me looks DktrKranz
[13:58] <Laney> meh, no rush
[14:19] <RogueTech> #ubuntu
[14:54] <DorianJaminais> hi everyone
[14:54] <DorianJaminais> I think I have misunderstood something in the version number scheme
[14:55] <DorianJaminais> i created a package witch depends on libois (>= 1.2)
[14:55] <DorianJaminais> and in the repos, there is a package libois version 1.2.0-1
[14:56] <DorianJaminais> my problem is that my package is broken because it requires a too high version on libois
[14:56] <DorianJaminais> is this normal ?
[14:59] <directhex> DorianJaminais, 1.2. is greater than 1.2
[14:59] <DorianJaminais> yes so my package requires a lower version of libois
[14:59] <DorianJaminais> I think i find out what is the actual problem
[14:59] <DorianJaminais> libois package is named libois-1.2.0
[15:02] <directhex> ...
[15:02] <directhex> then you need to depend on libois-1.2.0
[15:02] <DorianJaminais> yes that was it
[15:02] <DorianJaminais> sorry for disturbing :/
[19:21] <bdrung> bludude: packtools has the same purpose as packaging-dev
[19:28] <persia> bdrung: Did packaging-dev land?  I don't see it (but maybe I'm not looking with the right tools)
[19:28] <maco> persia: we're poking at it right now
[19:29] <persia> Oh, excellent.
[19:29] <maco> where "we" = i'm saying stuff and he's typing
[19:29] <bdrung> persia: not yet. i am currently trying to get a proper long description with maco
[19:29] <persia> packtools also suffers from a number of other issues (some of which I've passed to bludude), so it will be nice to have the proper replacement.
[19:29] <bdrung> persia, maco: http://paste.debian.net/120094/
[19:30] <bdrung> persia: besides that, packaging-dev was discussed on debian-devel
[19:30] <bdrung> persia, maco: is the description ok? can you improve it?
[19:30] <persia> bdrung: Sure, but I don't think it's fair to expect everyone to read that (especially not developers for Ubuntu remixes)
[19:30] <persia> "mangements" -> "mangement"
[19:31] <persia> "and packaging macros" -> "packaging macros"
[19:31] <maco> was about to say that one
[19:31] <persia> Err, "mangement" -> "management" if you've been accepting corrections verbatim :(
[19:32] <bdrung> persia: i enabled word correction :)
[19:32] <persia> "is just for packaging, not for developing" -> "provides tools for packaging, rather than the development of software"
[19:32] <bdrung> improvements for the last paragraph is welcome
[19:32] <persia> "This package should be installed by packagers. " -> ""
[19:33] <bdrung> current status: http://paste.debian.net/120095/
[19:34] <persia> "meta-package" -> "package"
[19:34] <bdrung> two other questions: should ubuntu-dev-tools in Depends or Recommends?
[19:34] <tumbleweed> do we have a lintian patch for complaining about it?
[19:34] <persia> "for development" = "for the development"
[19:34] <persia> I think u-d-t should be recommends.
[19:34] <tumbleweed> +1 for recommends
[19:35] <bdrung> the same for bzr-builddeb?
[19:35] <tumbleweed> I'd say so
[19:35] <persia> Is that interesting to packaging developers?  How?
[19:35] <bdrung> persia: "meta-package" -> "package" in short or long description?
[19:35] <maco> i think bzr-builddeb should move from regular recommemds to ubuntu-only recommends
[19:35] <persia> bdrung: I'm only looking at long for now.
[19:36] <persia> Oh, my: the short description is very awkward.
[19:36]  * maco tends to think the hardest part of making a new package is writing the stupid descriptions
[19:36] <maco> it's a package that does a thing! stop asking me hard questions! gimme easy ones like "what are the build-deps?"
[19:37] <tumbleweed> heh, true that
[19:38] <bdrung> maco: but we have svn-buildpackage and git-buildpackage in there too
[19:38] <broder> haha, agreed
[19:38] <broder> "it's a package that does a thing!" - i might use that for one of my internal packages now
[19:38] <bdrung> http://paste.debian.net/120096/
[19:39] <bdrung> broder: that's better than a description "TODO"
[19:39] <maco> "did a thing" is a phrase ive used a lot lately. my elbow did a thing. my knee did a thing. my hip did a thing.
[19:39] <persia> bdrung: maco: http://paste.debian.net/120097/
[19:40] <tumbleweed> persia: if you remove meta-package from the short description, you should add something about that to the long one
[19:41] <bdrung> persia: great, i will use that (there should be somewhere meta-package in there.
[19:41] <bdrung> )
[19:41] <bdrung> -> This meta-package depends on common packages [...]
[19:42] <persia> tumbleweed: Why?  It wasn't in either the short or long description of several metapackages I looked at before composing it.
[19:42] <tumbleweed> or at the end: This meta-package doesn't contain anything but depends on useful packages. No other package...
[19:42] <maco> i guess Section:meta-packages tells you that...
[19:42] <persia> Look at gnome-office, ubuntu-desktop, etc.
[19:42] <tumbleweed> persia: I find it useful when deciding what package to install, I assume other people do too
[19:43] <bdrung> W: packaging-dev: empty-binary-package
[19:43] <tumbleweed> yeah section:meta-packages does that too, I guess
[19:43] <persia> tumbleweed: As pointed out by maco, the information is already available.
[19:43] <tumbleweed> right
[19:43] <persia> bdrung: Did you remember to install copyright, changelog, etc.?
[19:44] <bdrung> persia: from lintian: If the package is deliberately empty, please mention in the package long description one of the phrases "metapackage," "dummy," "dependency package," "empty package," or "virtual package."
[19:44] <persia> Now that's a justification I can support.  Thanks!
[19:45] <persia> Yeah, "This package" -> "This metapackage" in both lines then.
[19:45] <bdrung> and section meta-packages is not allowed
[19:47] <bdrung> final check please: http://paste.debian.net/120099/
[19:47] <persia> Where can I look at the rest of control?
[19:48] <maco> huh. wonder where i found that section, cuz looking at the policy guide again its not there
[19:48] <persia> maco: It's an ubuntuism?
[19:49] <maco> maybe it was just because vim stopped going all red-text on the section when i got from meta-package to meta-packages, so it looked like it accepted that spelling?
[19:49] <maco> hm maybe
[19:49] <maco> ah yeah, metapackages is in cjwatson's ubuntu policy manual
[19:50] <persia> Heh: vim syntax highlighting requires distro-patching for debian/control files :)  The deep implications of some of the policy variations are amusing.
[19:51] <broder> huh? i thought debian added a metapackages section...
[19:51] <broder> (or something like that)
[19:52] <broder> huh. maybe not
[19:53] <persia> Policy 2.4 doesn't appear to include anything like that.
[19:55] <persia> bdrung: Sorry: failed to get back to you: 120099 looks fine to me.
[19:56] <persia> I'd still like to see control :)
[19:56] <maco> persia: he's got it in collab-maint. im guessing he's waiting to link it til he's got the desc updated
[20:01] <persia> Why is apt-file Recommends?  I use it sometimes, but can't see how it might be considered essential.
[20:01] <persia> Or even normally present.
[20:02] <micahg> persia: well, it's good for researching where other files are especially in fixing DSO linking issues
[20:03] <persia> micahg: Yes, but if one is packaging for a perfect upstream, once doesn't encoutner those.  Nor if one is packaging python, java, ruby, shell, C#, D, etc.
[20:04] <persia> I think it ought suggest gnome-pkg-tools (and in Ubuntu only, kubuntu-dev-tools, by ${vendor-specific:Suggests}
[20:04] <micahg> persia: I could make the same argument against both of those, they're specific to certain domains in UBuntu
[20:05] <micahg> persia: and kubuntu-dev-tools pulls in ruby, I don't think we want to do that by default
[20:05] <persia> micahg: How is pkg-gnome-tools specific to Ubuntu?
[20:05] <micahg> ah, suggests, nevermind..
[20:05] <persia> Err, gnome-pkg-tools
[20:05] <micahg> persia: you only use it if you package certain parts of the archive
[20:05] <micahg> but suggests is fine for both
[20:06] <persia> And there's still enough software in the archive that uses dpatch it's probably worth suggesting that as well (if not recommending it)
[20:06] <maco> oh dpatch is that one i couldnt remember
[20:06] <persia> micahg: specific to domain, yes.  Specific to Ubuntu, no: gnome-pkg-tools is also used in Debian for the same purposes.
[20:06] <maco> (it's either "quilt" or its "easy" :P)
[20:06]  * micahg thinks we should add a postinst to dpatch outputting something along the lines of (if you're installing this, consider porting the package to source format 3)
[20:07] <persia> No.
[20:07] <persia> I can do stuff with dpatch that simply isn't possible with any of the other systems.
[20:07] <Laney> why do we need more cudgels?
[20:07] <persia> Go look at the implementation some time :)
[20:07] <micahg> persia: the comment was more tongue-in-cheek :)
[20:07] <Laney> :-)
[20:08] <micahg> persia: sorry, didn't mean to emphasize the UBuntu part about being domain specific
[20:08] <persia> Heh, OK.
[20:09] <persia> Also, if we're recommeding all the VCS tools, seems like it's worth mentioning mr and pristine-tar
[20:09] <bludude> I just got a look at the packtools and packaging-dev stuff.  i'm going to move packtools to the same format as packaging-dev (no germinate).
[20:09] <persia> micahg: Anyway, my issue with apt-file is that I never need it, although it may be helpful in some contexts.  In the case of gnome-pkg-tools or kubuntu-dev-tools, there are *lots* of pacakges that simply cannot be built without them.
[20:10] <persia> bludude: Why?  Just join in the debate about what packaging-dev ends up being.  Let's have one perfect tool, rather than two.
[20:10] <micahg> persia: I never need genisoimage, should we drop that too?
[20:11] <bludude> true.  I made packtools to learn about packaging, so for me it's just for learning
[20:11] <persia> micahg: I don't see it in the recommends or depends of packaging-dev.  Am I missing something?
[20:11] <micahg> persia: I thought we were talking about ubuntu-dev-tools...
[20:11] <persia> (admittedly I have an old version of the file)
[20:11] <persia> No.
[20:11]  * micahg is confused...
[20:12] <bludude> if y'all desire, packaging-dev can have the name packtools
[20:12] <persia> It already got debated on debian-devel@ as "packaging-dev", which means confusing lots of folk if the name changes now.
[20:13] <bludude> ok
[20:13] <Laney> pristine-tar is certainly a good one
[20:14] <tumbleweed> pristine-tar should already be depended on by everything that uses it, no?
[20:14] <bludude> pristine-tar is pulled in by bzr-builddeb
[20:14] <persia> OK, then we don't need it.
[20:15] <bludude> bzr-builddeb pulls in a lot of good stuff
[20:15] <persia> tumbleweed: I don't think packages using pristine-tar need to build-dep on it, and I don't believe it's required as part of the workflow for any of the VCS packaging tools (although recommended for the majority of them)
[20:15] <tumbleweed> Depends: ... python2.6 | python2.7 | python2.4 ... ???
[20:15] <persia> Isn't there a "python-all" for just that purpose?
[20:16] <tumbleweed> persia: I mean git-buildpackage, bzr-builddeb etc depend on it
[20:16] <tumbleweed> persia: that's different
[20:16] <tumbleweed> and I'm ??ing at the 2.4
[20:16] <persia> They oughtn't.  They ought recommend it.
[20:16] <tumbleweed> git does, bzr depends on it
[20:16] <persia> That's just wrong.
[20:16] <tumbleweed> and as we can see it's no tthe only thing that's wrong :)
[20:17] <persia> All the more so given the example of the Ubuntu Desktop team who uses bzr for packaging and doesn't use pristine-tar as they use external tarballs.
[20:17] <micahg> rdepends for pristine-tar http://paste.ubuntu.com/628131/
[20:17] <micahg> +1 for recommending
[20:18] <persia> Oooh.  mercurial-buildpackage.  That ought be at least a suggests of packaging-dev
[20:19]  * tumbleweed waits for someone to mention cvs-buildpackage
[20:19] <persia> If there are packages still maintained in cvs, then I agree with tumbleweed that it ought be suggests.
[20:20] <tumbleweed> persia: I hope there aren't but there probably are
[20:20]  * tumbleweed hasn't ever come across any
[20:20] <persia> I have, but not in at least a few years.
[20:35] <nathanbelomy> anyone take a look at this http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7
[20:39] <cjwatson> nobody here is interested in that
[20:40] <nathanbelomy> I guess fedora might be?
[20:40] <nathanbelomy> It similar to the way intel's hypervisor technology works, only this is a virtual process that optimizes process executions concurrently
[20:41] <nathanbelomy> Maybe vmware wants it
[20:50] <jtaylor> sladen: openbve does not build in oneiric with mono 2.10, can you have a look?
[20:51] <bdrung> persia: http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary
[20:54] <micahg> bdrung: is piuparts useful for regular packagers?
[20:56] <persia> micahg, It's worth recommending.  Run on it's own (rather than as a service), it's a really handy way to test install/upgrade/remove/purge of the package.
[20:57] <micahg> persia: ah, I've never used it before, maybe I should :)
[20:58] <persia> heh.  Probably.
[20:58] <cjwatson> (nathanbelomy's URL is a weird troll of some kind, to save anyone else the trouble of looking.)
[21:05] <persia> bdrung: Sorry: yeah, that's what I was looking at before.  I don't see the latest changes we were discussing, but I'm sure you've a good local copy of the useful parts of the discussion.
[21:09] <bdrung> micahg: we should recommend testing :)
[21:10] <bdrung> persia: i am currently busy. will commit it soon.
[21:10] <persia> No rush.  I doubt I'd have anything more useful to comment about than I've already commented.
[21:21] <bdrung> persia: pushed
[21:23] <Laney> sladen: pretty please will you maintain openbve in debian?
[21:23] <Laney> i'll sponsor you!
[21:25] <highvoltage> sladen isn't a dd!?
[21:27] <tumbleweed> that's entirely fixable
[21:28] <directhex> i thought sladen was a DD.
[21:28] <directhex> maybe i'm confusing him with someone else
[21:29] <Laney> can't find any evidence of this fact
[21:29]  * Laney ldaps
[21:39] <bdrung> pushed http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary
[21:40] <bdrung> now is the last chance to get some changes into it before my first upload
[21:40] <bdrung> maco, persia, tumbleweed, micahg: ^
[21:42] <persia> So, I'd like bundles of changes to Recommends and Suggests (as outlined above).
[21:43] <persia> But I'd prefer discussion of my suggestions, rather than just submitting a patch and having it applied, as while I think I'm right, I'm rarely the best judge of that.
[21:44] <persia> Also, since I'm not a target user for the package (I actively don't want it installed, as I tend to like to not have e.g. autotools-dev by default so that when `make clean` breaks, I know I'm unhappy with the implementation, etc.)
[21:45] <persia> I'm probably not the right person to be made happy: the package should ideally match the documentation which is recommending it's installation.
[21:46] <tumbleweed> there was a sub-discussion about that on debian-devel, whether the package was recommended tools for new packages, or useful tools for packaging
[21:46] <bdrung> it targets new users.
[21:46] <tumbleweed> I think "things you're probably going to need" won out
[21:47] <maco> my original goal was to avoid 3 rounds of "oh wait, install this too" when mentoring newbies
[21:47] <bdrung> persia: adding suggestions doesn't hurt and they all seemed reasonable. therefore i added them
[21:47] <bludude> fyi, my goal for packtools was to automate installing everything listed in the Ubuntu packaging guide
[21:47] <maco> the stuff in the packaging guide should all be in packaging-dev. i checked that
[21:47] <bdrung> bludude: packaging-dev has the same goal
[21:47] <persia> bludude: I think that's the right goal, although I'm of the opinion that it makes sense to fix *both* the documentation and the package to do the right thing, rather than accepting either as authoritative.
[21:51] <tumbleweed> I'm pretty happy with the current contents
[21:53] <bludude> yes, they seem to fulfill the goal
[21:53] <persia> I really don't like dh-make, but that's from having repeated myself hundreds of times suggesting people clean up from it's common mistakes (e.g. Priority: extra)
[21:54] <bdrung> persia: that's the reason why it is in suggest and not in recommends
[22:00] <bdrung> packaging-dev  0.1 uploaded!
[22:31] <sladen> Laney: yeah, if you sponsor it
[22:32] <sladen> directhex: 10 years of me mistaking me for a DD now :-)
[22:32] <sladen> directhex: will get around to it at some point.  The previous one five years ago got put on hold because I refused to upload more crap into the archive just for the sake of completing NM
[22:37] <directhex> sladen: means i wasn't mistaking you for someone else, you're one of the "he's not a DD? huh?" folks as gets occasionally mentioned in #debian-uk circles
[22:37] <Laney> :-)
[22:37] <Laney> basically want to be able to drive a train at work
[22:38] <Laney> not that I can even do forward right yet
[22:48] <jtaylor> sladen: I propsed a branch for merging with openbve
[23:03] <directhex> Laney: have you booked a b&b for the night at the debian bbq yet? you're a dd now, it's your duty to attend