[00:53] wodering how can I know which package I have right to upload, anybody has any clues? [00:55] freeflying: you can use the edit_acl.py scripts in lp:ubuntu-archive-tools [00:56] micahg: thanks, what about I want the right to upload some specific package, whats the process to apply for it? [00:57] freeflying: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders [01:22] micahg: thanks === medberry is now known as med_out [01:42] 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] http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7 [01:44] anyone here? === ubott2 is now known as ubottu [02:02] nathanbelomy: wtf is that? === maco2 is now known as maco [06:08] 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] s/not/now [06:08] At the time it was written those two were synonymous. [06:09] I think MOTU is correct in the current context. [06:09] right, but is my understanding correct, 2 MOTU ACKs required (core-dev is considered a MOTU) [06:10] For packages by non-MOTU. [06:11] It's actually a bit trickier. [06:11] For example I think a kubuntu-dev ack on a package should certainly count. [06:11] (I would trust any kubuntu-dev to not comment on things outside their expertise) [06:12] OTOH, the difference between PPU and kubuntu-dev is just scale. [06:13] Meh. [06:13] ScottK: well, ok, but still, 2 ACKs are required, right? [06:13] I think motu is right rule. [06:13] For packages by non-motu, yes. [06:13] For MOTU the 2nd ack is suggested, but not required. [06:28] ScottK: wiki fixed [06:31] Thanks. === warp10` is now known as warp10 [07:59] how should i create a debian/watch for a project that's hosted on launchpad but doesn't produce tarballs? [08:04] then you can't. do you use checkouts for the .orig.tar.gz? [08:10] i find the whole orig.tar.gz thing quite annoying and redundant [08:10] not that my opinion counts for anything [08:12] all we have is a bazaar repo on launchpad [08:22] bludude: then you can ignore the debian/watch file (as there is nothing to watch). [08:22] alright, thanks. [08:54] good morning [08:55] dholbach, morning! [08:56] hey xdatap1 [08:56] morning dholbach :) [08:57] hey BlackZ === Quintasan_ is now known as Quintasan [09:46] * Rhonda sighs at the screenshot in Mohamad's Xlog post … [10:36] 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] kept your changelog entries and copyright :-) [10:55] Laney: kinda confusing changelog :).. Suggests it is currently in oneiric archive. :) [10:56] hah [10:56] I hope the 'ppa' in the version helps there === ximion1 is now known as ximion === ximion1 is now known as ximion === ximion2 is now known as ximion [12:11] Laney: great! After it is accepted and synced I will keep my PPA just for backports to stable Ubuntu release [12:13] 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] meh, no rush [14:19] #ubuntu === med_out is now known as medberry [14:54] hi everyone [14:54] I think I have misunderstood something in the version number scheme [14:55] i created a package witch depends on libois (>= 1.2) [14:55] and in the repos, there is a package libois version 1.2.0-1 [14:56] my problem is that my package is broken because it requires a too high version on libois [14:56] is this normal ? [14:59] DorianJaminais, 1.2. is greater than 1.2 [14:59] yes so my package requires a lower version of libois [14:59] I think i find out what is the actual problem [14:59] libois package is named libois-1.2.0 [15:02] ... [15:02] then you need to depend on libois-1.2.0 [15:02] yes that was it [15:02] sorry for disturbing :/ === superm1` is now known as superm1 === menesis1 is now known as menesis === Amaranth_ is now known as Amaranth === NCommand1r is now known as NCommander === mdomsch is now known as mdomsch_westford === ximion2 is now known as ximion [19:21] bludude: packtools has the same purpose as packaging-dev [19:28] bdrung: Did packaging-dev land? I don't see it (but maybe I'm not looking with the right tools) [19:28] persia: we're poking at it right now [19:29] Oh, excellent. [19:29] where "we" = i'm saying stuff and he's typing [19:29] persia: not yet. i am currently trying to get a proper long description with maco [19:29] 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] persia, maco: http://paste.debian.net/120094/ [19:30] persia: besides that, packaging-dev was discussed on debian-devel [19:30] persia, maco: is the description ok? can you improve it? [19:30] bdrung: Sure, but I don't think it's fair to expect everyone to read that (especially not developers for Ubuntu remixes) [19:30] "mangements" -> "mangement" [19:31] "and packaging macros" -> "packaging macros" [19:31] was about to say that one [19:31] Err, "mangement" -> "management" if you've been accepting corrections verbatim :( [19:32] persia: i enabled word correction :) [19:32] "is just for packaging, not for developing" -> "provides tools for packaging, rather than the development of software" [19:32] improvements for the last paragraph is welcome [19:32] "This package should be installed by packagers. " -> "" [19:33] current status: http://paste.debian.net/120095/ [19:34] "meta-package" -> "package" [19:34] two other questions: should ubuntu-dev-tools in Depends or Recommends? [19:34] do we have a lintian patch for complaining about it? [19:34] "for development" = "for the development" [19:34] I think u-d-t should be recommends. [19:34] +1 for recommends [19:35] the same for bzr-builddeb? [19:35] I'd say so [19:35] Is that interesting to packaging developers? How? [19:35] persia: "meta-package" -> "package" in short or long description? [19:35] i think bzr-builddeb should move from regular recommemds to ubuntu-only recommends [19:35] bdrung: I'm only looking at long for now. [19:36] 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] it's a package that does a thing! stop asking me hard questions! gimme easy ones like "what are the build-deps?" [19:37] heh, true that [19:38] maco: but we have svn-buildpackage and git-buildpackage in there too [19:38] haha, agreed [19:38] "it's a package that does a thing!" - i might use that for one of my internal packages now [19:38] http://paste.debian.net/120096/ [19:39] broder: that's better than a description "TODO" [19:39] "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] bdrung: maco: http://paste.debian.net/120097/ [19:40] persia: if you remove meta-package from the short description, you should add something about that to the long one [19:41] persia: great, i will use that (there should be somewhere meta-package in there. [19:41] ) [19:41] -> This meta-package depends on common packages [...] [19:42] tumbleweed: Why? It wasn't in either the short or long description of several metapackages I looked at before composing it. [19:42] or at the end: This meta-package doesn't contain anything but depends on useful packages. No other package... [19:42] i guess Section:meta-packages tells you that... [19:42] Look at gnome-office, ubuntu-desktop, etc. [19:42] persia: I find it useful when deciding what package to install, I assume other people do too [19:43] W: packaging-dev: empty-binary-package [19:43] yeah section:meta-packages does that too, I guess [19:43] tumbleweed: As pointed out by maco, the information is already available. [19:43] right [19:43] bdrung: Did you remember to install copyright, changelog, etc.? [19:44] 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] Now that's a justification I can support. Thanks! [19:45] Yeah, "This package" -> "This metapackage" in both lines then. [19:45] and section meta-packages is not allowed [19:47] final check please: http://paste.debian.net/120099/ [19:47] Where can I look at the rest of control? [19:48] huh. wonder where i found that section, cuz looking at the policy guide again its not there [19:48] maco: It's an ubuntuism? [19:49] 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] hm maybe [19:49] ah yeah, metapackages is in cjwatson's ubuntu policy manual [19:50] Heh: vim syntax highlighting requires distro-patching for debian/control files :) The deep implications of some of the policy variations are amusing. [19:51] huh? i thought debian added a metapackages section... [19:51] (or something like that) [19:52] huh. maybe not [19:53] Policy 2.4 doesn't appear to include anything like that. [19:55] bdrung: Sorry: failed to get back to you: 120099 looks fine to me. [19:56] I'd still like to see control :) [19:56] 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] Why is apt-file Recommends? I use it sometimes, but can't see how it might be considered essential. [20:01] Or even normally present. [20:02] persia: well, it's good for researching where other files are especially in fixing DSO linking issues [20:03] 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] I think it ought suggest gnome-pkg-tools (and in Ubuntu only, kubuntu-dev-tools, by ${vendor-specific:Suggests} [20:04] persia: I could make the same argument against both of those, they're specific to certain domains in UBuntu [20:05] persia: and kubuntu-dev-tools pulls in ruby, I don't think we want to do that by default [20:05] micahg: How is pkg-gnome-tools specific to Ubuntu? [20:05] ah, suggests, nevermind.. [20:05] Err, gnome-pkg-tools [20:05] persia: you only use it if you package certain parts of the archive [20:05] but suggests is fine for both [20:06] 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] oh dpatch is that one i couldnt remember [20:06] micahg: specific to domain, yes. Specific to Ubuntu, no: gnome-pkg-tools is also used in Debian for the same purposes. [20:06] (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] No. [20:07] I can do stuff with dpatch that simply isn't possible with any of the other systems. [20:07] why do we need more cudgels? [20:07] Go look at the implementation some time :) [20:07] persia: the comment was more tongue-in-cheek :) [20:07] :-) [20:08] persia: sorry, didn't mean to emphasize the UBuntu part about being domain specific [20:08] Heh, OK. [20:09] Also, if we're recommeding all the VCS tools, seems like it's worth mentioning mr and pristine-tar [20:09] 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] 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] 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] persia: I never need genisoimage, should we drop that too? [20:11] true. I made packtools to learn about packaging, so for me it's just for learning [20:11] micahg: I don't see it in the recommends or depends of packaging-dev. Am I missing something? [20:11] persia: I thought we were talking about ubuntu-dev-tools... [20:11] (admittedly I have an old version of the file) [20:11] No. [20:11] * micahg is confused... [20:12] if y'all desire, packaging-dev can have the name packtools [20:12] It already got debated on debian-devel@ as "packaging-dev", which means confusing lots of folk if the name changes now. [20:13] ok [20:13] pristine-tar is certainly a good one [20:14] pristine-tar should already be depended on by everything that uses it, no? [20:14] pristine-tar is pulled in by bzr-builddeb [20:14] OK, then we don't need it. [20:15] bzr-builddeb pulls in a lot of good stuff [20:15] 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] Depends: ... python2.6 | python2.7 | python2.4 ... ??? [20:15] Isn't there a "python-all" for just that purpose? [20:16] persia: I mean git-buildpackage, bzr-builddeb etc depend on it [20:16] persia: that's different [20:16] and I'm ??ing at the 2.4 [20:16] They oughtn't. They ought recommend it. [20:16] git does, bzr depends on it [20:16] That's just wrong. [20:16] and as we can see it's no tthe only thing that's wrong :) [20:17] 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] rdepends for pristine-tar http://paste.ubuntu.com/628131/ [20:17] +1 for recommending [20:18] 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] If there are packages still maintained in cvs, then I agree with tumbleweed that it ought be suggests. [20:20] persia: I hope there aren't but there probably are [20:20] * tumbleweed hasn't ever come across any [20:20] I have, but not in at least a few years. === yofel_ is now known as yofel [20:35] anyone take a look at this http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7 [20:39] nobody here is interested in that [20:40] I guess fedora might be? [20:40] It similar to the way intel's hypervisor technology works, only this is a virtual process that optimizes process executions concurrently [20:41] Maybe vmware wants it [20:50] sladen: openbve does not build in oneiric with mono 2.10, can you have a look? [20:51] persia: http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary [20:54] bdrung: is piuparts useful for regular packagers? [20:56] 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] persia: ah, I've never used it before, maybe I should :) [20:58] heh. Probably. [20:58] (nathanbelomy's URL is a weird troll of some kind, to save anyone else the trouble of looking.) === Quintasan_ is now known as Quintasan [21:05] 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] micahg: we should recommend testing :) [21:10] persia: i am currently busy. will commit it soon. [21:10] No rush. I doubt I'd have anything more useful to comment about than I've already commented. [21:21] persia: pushed [21:23] sladen: pretty please will you maintain openbve in debian? [21:23] i'll sponsor you! [21:25] sladen isn't a dd!? [21:27] that's entirely fixable [21:28] i thought sladen was a DD. [21:28] maybe i'm confusing him with someone else [21:29] can't find any evidence of this fact [21:29] * Laney ldaps [21:39] pushed http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary [21:40] now is the last chance to get some changes into it before my first upload [21:40] maco, persia, tumbleweed, micahg: ^ [21:42] So, I'd like bundles of changes to Recommends and Suggests (as outlined above). [21:43] 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] 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] 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] 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] it targets new users. [21:46] I think "things you're probably going to need" won out [21:47] my original goal was to avoid 3 rounds of "oh wait, install this too" when mentoring newbies [21:47] persia: adding suggestions doesn't hurt and they all seemed reasonable. therefore i added them [21:47] fyi, my goal for packtools was to automate installing everything listed in the Ubuntu packaging guide [21:47] the stuff in the packaging guide should all be in packaging-dev. i checked that [21:47] bludude: packaging-dev has the same goal [21:47] 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] I'm pretty happy with the current contents [21:53] yes, they seem to fulfill the goal [21:53] 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] persia: that's the reason why it is in suggest and not in recommends [22:00] packaging-dev 0.1 uploaded! [22:31] Laney: yeah, if you sponsor it [22:32] directhex: 10 years of me mistaking me for a DD now :-) [22:32] 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] 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] :-) [22:37] basically want to be able to drive a train at work [22:38] not that I can even do forward right yet [22:48] sladen: I propsed a branch for merging with openbve [23:03] 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