freeflying | wodering how can I know which package I have right to upload, anybody has any clues? | 00:53 |
---|---|---|
micahg | freeflying: you can use the edit_acl.py scripts in lp:ubuntu-archive-tools | 00:55 |
freeflying | micahg: thanks, what about I want the right to upload some specific package, whats the process to apply for it? | 00:56 |
micahg | freeflying: https://wiki.ubuntu.com/UbuntuDevelopers#Per-package%20Uploaders | 00:57 |
freeflying | micahg: thanks | 01:22 |
=== medberry is now known as med_out | ||
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:42 |
nathanbelomy | anyone here? | 01:44 |
=== ubott2 is now known as ubottu | ||
poolie | nathanbelomy: wtf is that? | 02:02 |
=== maco2 is now known as maco | ||
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:08 |
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:09 |
ScottK | For packages by non-MOTU. | 06:10 |
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:11 |
ScottK | OTOH, the difference between PPU and kubuntu-dev is just scale. | 06:12 |
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:13 |
micahg | ScottK: wiki fixed | 06:28 |
ScottK | Thanks. | 06:31 |
=== warp10` is now known as warp10 | ||
bludude | how should i create a debian/watch for a project that's hosted on launchpad but doesn't produce tarballs? | 07:59 |
geser | then you can't. do you use checkouts for the .orig.tar.gz? | 08:04 |
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:10 |
bludude | all we have is a bazaar repo on launchpad | 08:12 |
geser | bludude: then you can ignore the debian/watch file (as there is nothing to watch). | 08:22 |
bludude | alright, thanks. | 08:22 |
dholbach | good morning | 08:54 |
xdatap1 | dholbach, morning! | 08:55 |
dholbach | hey xdatap1 | 08:56 |
BlackZ | morning dholbach :) | 08:56 |
dholbach | hey BlackZ | 08:57 |
=== Quintasan_ is now known as Quintasan | ||
* Rhonda sighs at the screenshot in Mohamad's Xlog post … | 09:46 | |
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:36 |
Daviey | Laney: kinda confusing changelog :).. Suggests it is currently in oneiric archive. :) | 10:55 |
Laney | hah | 10:56 |
Laney | I hope the 'ppa' in the version helps there | 10:56 |
=== ximion1 is now known as ximion | ||
=== ximion1 is now known as ximion | ||
=== ximion2 is now known as ximion | ||
warp10 | Laney: great! After it is accepted and synced I will keep my PPA just for backports to stable Ubuntu release | 12:11 |
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 | 12:13 |
Laney | meh, no rush | 13:58 |
RogueTech | #ubuntu | 14:19 |
=== med_out is now known as medberry | ||
DorianJaminais | hi everyone | 14:54 |
DorianJaminais | I think I have misunderstood something in the version number scheme | 14:54 |
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:55 |
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:56 |
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 | 14:59 |
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 :/ | 15:02 |
=== 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 | ||
bdrung | bludude: packtools has the same purpose as packaging-dev | 19:21 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
bdrung | current status: http://paste.debian.net/120095/ | 19:33 |
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:34 |
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:35 |
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:36 |
tumbleweed | heh, true that | 19:37 |
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:38 |
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:39 |
tumbleweed | persia: if you remove meta-package from the short description, you should add something about that to the long one | 19:40 |
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:41 |
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:42 |
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:43 |
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:44 |
persia | Yeah, "This package" -> "This metapackage" in both lines then. | 19:45 |
bdrung | and section meta-packages is not allowed | 19:45 |
bdrung | final check please: http://paste.debian.net/120099/ | 19:47 |
persia | Where can I look at the rest of control? | 19:47 |
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:48 |
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:49 |
persia | Heh: vim syntax highlighting requires distro-patching for debian/control files :) The deep implications of some of the policy variations are amusing. | 19:50 |
broder | huh? i thought debian added a metapackages section... | 19:51 |
broder | (or something like that) | 19:51 |
broder | huh. maybe not | 19:52 |
persia | Policy 2.4 doesn't appear to include anything like that. | 19:53 |
persia | bdrung: Sorry: failed to get back to you: 120099 looks fine to me. | 19:55 |
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 | 19:56 |
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:01 |
micahg | persia: well, it's good for researching where other files are especially in fixing DSO linking issues | 20:02 |
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:03 |
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:04 |
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:05 |
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:06 | |
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:07 |
micahg | persia: sorry, didn't mean to emphasize the UBuntu part about being domain specific | 20:08 |
persia | Heh, OK. | 20:08 |
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:09 |
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:10 |
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:11 | |
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:12 |
bludude | ok | 20:13 |
Laney | pristine-tar is certainly a good one | 20:13 |
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:14 |
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:15 |
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:16 |
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:17 |
persia | Oooh. mercurial-buildpackage. That ought be at least a suggests of packaging-dev | 20:18 |
* 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:19 |
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:20 |
=== yofel_ is now known as yofel | ||
nathanbelomy | anyone take a look at this http://www.scribd.com/doc/57964655/New-Line-String-Execution-for-Run-Line-Level-7 | 20:35 |
cjwatson | nobody here is interested in that | 20:39 |
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:40 |
nathanbelomy | Maybe vmware wants it | 20:41 |
jtaylor | sladen: openbve does not build in oneiric with mono 2.10, can you have a look? | 20:50 |
bdrung | persia: http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary | 20:51 |
micahg | bdrung: is piuparts useful for regular packagers? | 20:54 |
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:56 |
micahg | persia: ah, I've never used it before, maybe I should :) | 20:57 |
persia | heh. Probably. | 20:58 |
cjwatson | (nathanbelomy's URL is a weird troll of some kind, to save anyone else the trouble of looking.) | 20:58 |
=== Quintasan_ is now known as Quintasan | ||
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:05 |
bdrung | micahg: we should recommend testing :) | 21:09 |
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:10 |
bdrung | persia: pushed | 21:21 |
Laney | sladen: pretty please will you maintain openbve in debian? | 21:23 |
Laney | i'll sponsor you! | 21:23 |
highvoltage | sladen isn't a dd!? | 21:25 |
tumbleweed | that's entirely fixable | 21:27 |
directhex | i thought sladen was a DD. | 21:28 |
directhex | maybe i'm confusing him with someone else | 21:28 |
Laney | can't find any evidence of this fact | 21:29 |
* Laney ldaps | 21:29 | |
bdrung | pushed http://anonscm.debian.org/gitweb/?p=collab-maint/packaging-dev.git;a=summary | 21:39 |
bdrung | now is the last chance to get some changes into it before my first upload | 21:40 |
bdrung | maco, persia, tumbleweed, micahg: ^ | 21:40 |
persia | So, I'd like bundles of changes to Recommends and Suggests (as outlined above). | 21:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
tumbleweed | I'm pretty happy with the current contents | 21:51 |
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:53 |
bdrung | persia: that's the reason why it is in suggest and not in recommends | 21:54 |
bdrung | packaging-dev 0.1 uploaded! | 22:00 |
sladen | Laney: yeah, if you sponsor it | 22:31 |
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:32 |
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:37 |
Laney | not that I can even do forward right yet | 22:38 |
jtaylor | sladen: I propsed a branch for merging with openbve | 22:48 |
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 | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!