| LimCore | Im patching a semi-broken security in svn. Anyone wants to give me a hand about the tools to quickly rebuild&test (hand holding ;) | 00:13 |
|---|---|---|
| kklimonda | LimCore, what do you mean by "quickly rebuild&test"? | 00:26 |
| kklimonda | LimCore, ccache would probably speed up rebuilding | 00:26 |
| LimCore | well, I have very limited time, so I hoped I will do what I do well (fix this bug, assuming the code base is readable) and someone will help me build/test/and all other ubuntu specyfic stuff | 00:27 |
| LimCore | upsteam uses variable names like "b". No, its not for index variable. Neat | 00:30 |
| PackThis | hi | 06:05 |
| PackThis | Looking for either the "Debian New Maintainers' Guide" or a different Debian package creation guide in a fully-downloadable format, eg; HTML | 06:06 |
| PackThis | Could you please provide a link/command to one? | 06:06 |
| freeflying | persia: ping | 06:24 |
| === nenolod is now known as happinessturtle | ||
| === happinessturtle is now known as nenolod | ||
| dholbach | good morning | 08:09 |
| OdyX | Hi MOTUs, I just filed a requestsync for usb-modeswitch (#519216), which needs sponsorship from you (if I understood it correctly). Could anyone take a look after it ? | 10:08 |
| geser | OdyX: Acked | 10:14 |
| OdyX | geser: great. Thanks. | 10:15 |
| Rhonda | Is there something like "bts" for launchpad? | 10:28 |
| jpds | Rhonda: Launchpad bugs in Launchpad? | 10:29 |
| Rhonda | i.e., a soap interface or commandline query client? | 10:29 |
| Rhonda | jpds: Yes. | 10:29 |
| jpds | There's an API for Launchpad. | 10:29 |
| jpds | Rhonda: https://help.launchpad.net/API | 10:30 |
| Rhonda | That sounds like there isn't a tool yet, right? | 10:30 |
| dholbach | and there's https://launchpad.net/bughugger | 10:30 |
| Rhonda | jpds, dholbach: Thanks. :) | 10:38 |
| dholbach | no worries | 10:38 |
| phek | when using dpkg-buildpackage is there a way to restart it from a specific step? (there was an error in my make install) | 11:06 |
| geser | dpkg-buildpackage -b -nc | 11:07 |
| persia | Note that this doesn't always behave entirely as expected, depending on the names of various files and various rules. | 11:08 |
| phek | hmm, ok | 11:08 |
| phek | i'm guessing i also need -rfakeroot too if my original build was using it right? (this package takes about 5 hours to build so i really don't want to end up starting all over) | 11:15 |
| phek | guess i can just make a backup copy and give it a try | 11:17 |
| persia | phek: Aside from the -nc, you'll want to use all the same options. | 11:18 |
| persia | -nc just doesn't run debian/rules clean | 11:18 |
| phek | ok cool. thanks | 11:19 |
| phek | now i'm getting an architecture error (now that i'm doing -b -nc which seems strange). dpkg-gencontrol: error: current host architecture 'powerpc' does not appear in package's architecture list (cell) | 11:28 |
| azeem_ | cell? | 11:29 |
| phek | well, i use -mtune=cell -mcpu=cell during the configure (this is on a ps3) | 11:30 |
| azeem_ | that wouldn't make dpkg to think you're trying to build for cell | 11:31 |
| azeem_ | pastebin your debian/control | 11:31 |
| phek | k | 11:31 |
| azeem_ | phek: and the output of "dpkg-architecture" | 11:32 |
| phek | https://www.securepaste.com/decrypt_data.php?id=5e2r597m&password=2Y81h | 11:33 |
| phek | thats the control and i just noticed that cell is the architecture: | 11:33 |
| azeem_ | that'd be it | 11:34 |
| phek | https://www.securepaste.com/decrypt_data.php?id=79wcD&password=2Y81h | 11:34 |
| phek | OK, i guess as long as i can keep the optimizations it's fine to change it | 11:34 |
| azeem_ | is this a new package? | 11:35 |
| azeem_ | change it to what? | 11:35 |
| phek | yeah | 11:35 |
| phek | change the control Architecture line to powerpc | 11:35 |
| azeem_ | does it compile on amd64? | 11:35 |
| phek | the software does, but with the optimizations it would probably crash | 11:36 |
| phek | (using the cell optimizations) | 11:36 |
| phek | which i guess is obvious | 11:36 |
| azeem_ | eh, you're putting the optimizations into debian/rules? | 11:37 |
| phek | yeah | 11:37 |
| azeem_ | using a if statement to check for powerpc I hope? | 11:38 |
| suji11 | hi | 11:38 |
| phek | nope. probably would have been a good idea | 11:38 |
| azeem_ | yes | 11:39 |
| azeem_ | then the package wouldn't be powerpc-specific and you can set Architecture: to any, as it should be | 11:39 |
| suji11 | i need help to create a debian package for hunspell-ta , i'm having the dictionary file and aff file | 11:39 |
| paissad | hi all, i am packaging a software for debian, i have already uploaded to mentors-debian.net ... & i'm waiting for a mentor to handle, but i would like to make the .deb package available for ubuntu too ..... i've totally followed the debian policy ... what must i do now for ubuntu ? | 11:39 |
| sistpoty|work | phek: ooi, does -mcpu=cell make that much difference? | 11:39 |
| phek | sistpoty|work, yeah. well either that or the -O2 does. but full screen with that package and no optimizations is almost unusable | 11:40 |
| paissad | meanwhile, i would like to create a wiki in ubuntu website where i could give instructions about installing that software | 11:40 |
| phek | sistpoty|work, but with the optimizatioins its usuable | 11:40 |
| azeem_ | the regular package should use -O2 already | 11:41 |
| paissad | here is the soft -> http://code.google.com/p/ps3mediaserver/ | 11:41 |
| sistpoty|work | phek: interesting. wouldn't have thought that | 11:41 |
| phek | azeem_, there's no regular package for this. the 1.51 version couldn't do full screen at all due to some file permissions thing. | 11:42 |
| azeem_ | sistpoty|work: well, if it's an emulator, it might take advantage of advanced platform features | 11:42 |
| phek | (there's a package for 1.51) | 11:42 |
| azeem_ | phek: then I suggest you test yourself with and without the -mcpu=cell and see whether that's it | 11:42 |
| sistpoty|work | azeem_: afaict cell is a ppc + 8 spu's (good at floating point, but extremely hard to program), so I didn't expect that gcc could automatically optimize the code to make use of the spus... | 11:43 |
| phek | yeah, i may do that. like i said it takes 5 hours to install (at least) so it's not something i can just spend 10 minutes testing | 11:43 |
| azeem_ | sistpoty|work: it might just turn on altivec | 11:44 |
| azeem_ | as opposed to the regular GCC -O2 | 11:44 |
| sistpoty|work | azeem_: ah, right. had totally forgotten about altivec, thanks | 11:44 |
| azeem_ | phek: to *install* | 11:44 |
| azeem_ | ? | 11:44 |
| phek | err i mean build | 11:45 |
| azeem_ | ok | 11:45 |
| proppy | Hi, I updated the bug report asking for sync of poker-network in lucid, because a new version was recently uploaded to debian | 11:46 |
| proppy | https://bugs.edge.launchpad.net/ubuntu/+source/poker-network/+bug/509677 | 11:46 |
| ubottu | Ubuntu bug 509677 in poker-network "Please sync poker-network 1.7.7-1 from unstable to lucid" [Undecided,New] | 11:46 |
| proppy | let me know if it needs more informations | 11:47 |
| Laney | slytherin: hi, did you have a chance to try that ppc build? | 11:48 |
| slytherin | Laney: No. I couldn't get online yesterday due to some problem on ISP side. Iwill try today if you want. | 11:49 |
| Laney | if you get some free time, please | 11:50 |
| slytherin | sure | 11:50 |
| slytherin | Laney: Can you please send a link of the .dsc file to my email address? I do not have yesterday's logs. https://edge.launchpad.net/~onkarshinde | 11:51 |
| Laney | sure, here goes | 11:51 |
| slytherin | got to go now. Going home. | 11:52 |
| Laney | there you go | 11:52 |
| Laney | see you later | 11:52 |
| sebner | Laney: ~o¨ | 11:53 |
| * Laney pounces on sebner | 11:53 | |
| * sebner hides | 11:53 | |
| phek | well, guess i one of those unexpected behaviors from using -b -nc | 12:00 |
| oojah | Laney: I've addressed your comments on sqlite3-pcre, would you be able to take another look at it when you get a chance please? | 12:25 |
| persia | oojah: You'll end up with a much better package if you get lots of different reviewers, rather than chasing people who reviewed it before. | 12:27 |
| hyperair | persia: do MOTU applications via DMB require announcing on developer-membership-board@l.u.c | 12:31 |
| hyperair | ? | 12:31 |
| oojah | persia: I'm sure you're right. | 12:31 |
| * hyperair is still wondering when exactly the next DMB meeting is | 12:32 | |
| persia | hyperair: No. I'm not sure precisely how it does work, but https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess is likely your best guideline. | 12:32 |
| persia | Next Tuesday. | 12:32 |
| hyperair | hmm tuesday | 12:32 |
| persia | At 14:00 UTC, so late for you. | 12:32 |
| hyperair | 2200 my time. | 12:33 |
| hyperair | perfect. | 12:33 |
| hyperair | i'm spending most of the day in a bus | 12:33 |
| geser | persia: not 15 UTC? | 12:33 |
| hyperair | my chinese new year break ends on tuesday so i have to scramble back across the country to campus | 12:34 |
| persia | geser: Oh, right. 15 UTC. | 12:35 |
| hyperair | 2300 local time. still great =D | 12:37 |
| * hyperair is nocturnal anyway | 12:37 | |
| Laney | oojah: A get-orig-source target which reconstructs the .orig.tar.gz from upstream's git repo would be nice | 12:41 |
| Laney | (but not essential) | 12:41 |
| Laney | I can look maybe later if you don't find anyone else | 12:41 |
| * oojah nods | 12:42 | |
| oojah | I'll look into that and repost later, thanks. | 12:42 |
| oojah | How can I find out the package version that is currently being built for a get-orig-source rule? | 14:18 |
| persia | oojah: You can't usefully. The semantics of get-orig-source are such that it always gets the *newest* available version. Depending on how usptream releases, you may be able to use hints from tarball names, VCS tags, or similar. | 14:25 |
| persia | But, except in the case of tarball names, it may be tricky to determine the version that will be pulled in advance of pulling it. | 14:25 |
| persia | (with tarballs, uscan does an admirable job) | 14:26 |
| umang | Hi, I have a new package that was just uploaded to sid a few minutes back. I just wanted to know, is the Import Freeze day after for sid or testing? (There seem to be conflicting information on the wiki). | 14:26 |
| umang | Also, if it is for testing, then does the package wait for 10.10? | 14:27 |
| persia | umang: It's usually for sid, but we're doing testing this cycle. | 14:27 |
| umang | persia: So I'll have to wait for the 10.10 freeze before filing a bug? | 14:28 |
| persia | For an upload today, it would probably wait for 10.10, but if you *know* it works in current lucid after being recompiled, you can request a sync directly from unstable. | 14:28 |
| persia | No, it would be automatically pulled when the 10.10 archive opened. | 14:28 |
| umang | I know it works on Karmic | 14:28 |
| persia | You only need a bug if you want it before that. | 14:28 |
| persia | Yeah, but it needs to be known to work in lucid to be included in lucid :) | 14:28 |
| persia | You may find that a VM or chroot can help test that. | 14:29 |
| umang | persia: I can do that, but by when would I have to file a bug? | 14:29 |
| umang | I mean it has just been uploaded, not even accepted by the ftp. | 14:29 |
| persia | You'd have to file the bug after it gets through Debian NEW, and before FeatureFreeze. | 14:30 |
| persia | It's potentially possible to do after FeatureFreeze, but that requires a Freeze Exception, which is a much higher bar. | 14:30 |
| umang | OK. I hope I get some time in between. :) | 14:30 |
| umang | It's just a day I think. | 14:31 |
| oojah | persia: Ah, ok. I was thinking about it the wrong way round. So for a git repo I should pull the code and create a tarball based on the version there and it's at that point that the new changelog entry would be created? | 14:31 |
| umang | persia: So a needs-packaging, right? | 14:32 |
| persia | oojah: Well, there's not usually that much automation. Someone updating the package would usually run debian/rules get-orig-source to generate a new tarball, and then dch -i separately to add a new changelog entry, manually setting the version in the changelog. | 14:32 |
| persia | umang: If you've uploaded it to Debian, surely it's already packaged :) You'd file a sync bug. | 14:33 |
| umang | Oh yes. :P | 14:33 |
| umang | "Please sync <packagename> from debian <distro>" where <packagename>" | 14:33 |
| umang | Right? | 14:33 |
| umang | I mean, "Please sync <packagename> from debian <distro>" | 14:34 |
| AnAnt | Hello, I am preparing a package for a library , some symbols are not hidden although they are not in the official API, the question is, should I remove those symbols from debian/libname.symbols file ? | 14:34 |
| persia | Something like that. Most people use requestsync. I recommend searching for one in the ~ubuntu-archive subscription list, and following that sort of pattern. | 14:34 |
| persia | AnAnt: All the symbols file does is help set appropriate dependencies and help you notice when the ABI changes. If you think these symbols don't matter, then you can hide them. If you think they will be used, even if undocumented, you may want to include them. Be careful that no symbols are exposed that properly belong to other libraries. | 14:36 |
| AnAnt | thanks | 14:36 |
| oojah | persia: Yes, that's what I meant - no automation of dch -i. | 14:37 |
| AnAnt | persia: well, thing is that they were supposed to be hidden in previous releases, yet some packages used a few of those symbols, so upstream kept them (but is considering hiding them) to keep API | 14:40 |
| persia | In that case, there are users, and they *should* be shown in the symbols file. If they are hidden, that's an API change, and you will benefit from dpkg-gensymbols telling you so. | 14:41 |
| umang | persia: Thanks. I will use that tool if it clears new before the 11th. | 14:41 |
| c_korn | are unmodified packages still automatically synced from Debian testing ? | 14:41 |
| persia | c_korn: Until DIF *) | 14:42 |
| c_korn | persia: ah, it is the LTSDIF on the 11th, right ? https://wiki.ubuntu.com/LucidReleaseSchedule | 14:44 |
| persia | Indeed. | 14:44 |
| AnAnt | persia: but those users used symbols that they weren't supposed to use | 14:44 |
| AnAnt | persia: ie. it is not actually an API change | 14:45 |
| c_korn | well, then I have not much time to get scilab in :) thanks persia | 14:45 |
| persia | AnAnt: It's not supposed to be an API change, but it *is* an API change. The offending applications need to be patched, and so it needs to have a new soname, to break the dependency. | 14:45 |
| AnAnt | persia: or patch to offending apps? | 14:48 |
| AnAnt | persia: especially that they are a few | 14:49 |
| persia | AnAnt: Well, you *could* patch all the offending applications for which you can get the source, but you can't do it for stuff you can't see. | 14:51 |
| persia | So you might see bug reports if you don't adjust SONAME when the API changes. | 14:52 |
| AnAnt | persia: upstream of the lib doesn't want to bump SONAME | 14:52 |
| persia | Then keep the symbols public. | 14:52 |
| AnAnt | persia: especially that the problem I mentioned is very a very few apps | 14:52 |
| persia | I argue that it's not possible to know how many applications are affected, because it's not possible to determine what all users are doing in their local environments. | 14:53 |
| persia | It's more responsible to just leave those included in the undocumented but official API until there's some other reason to bump the SONAME, and drop them then. | 14:53 |
| sistpoty|work | AnAnt: is the package already in the repos? if not, and if upstream seems to plan to hide those symbols, maybe you should do this too (not in the symbol files, but rather by unexporting them e.g. via __attribute__((__hidden__))) | 14:59 |
| === andreas__ is now known as ahasenack | ||
| === asac_ is now known as asac | ||
| cnd | I've got a package that is near inclusion into fedora, but I can't seem to get anyone to review it for ubuntu | 15:52 |
| cnd | I've got it uploaded into revu and a launchpad bug opened for packaging | 15:52 |
| cnd | what can I do to get it reviewed? | 15:53 |
| cnd | the package is rinputd | 15:53 |
| EagleScreen | cnd: are you Chase Douglas? | 15:55 |
| cnd | EagleScreen, yep | 15:55 |
| EagleScreen | why has you package a -4 debian revision? | 15:56 |
| === Tonio__ is now known as Tonio_ | ||
| cnd | I don't know specifics of how packages versions SHOULD work, but my idea is that the 1.0.2 is the version of the source code | 15:56 |
| cnd | whereas the -4 is the 5th version of the packaging | 15:57 |
| umang | cnd: If it hasn't already reached ubuntu, then you should stick to -1. That's what I was told on Debian. | 15:58 |
| cnd | I can certainly change the version to fit ubuntu standards | 15:58 |
| EagleScreen | cnd: if you package for Ubuntu a package which is not still in Debian, you cannot set a debian reviison grather than zero | 15:58 |
| umang | EagleScreen: cnd, Yes that true. (So I was wrong) | 15:58 |
| EagleScreen | cnd: upstream version is 1.0.2 | 15:59 |
| umang | cnd: Also, why is your package native? | 15:59 |
| cnd | EagleScreen, ok, so the revision should just be rinputd_1.0.2 | 15:59 |
| EagleScreen | the first Debian revision would be 1.0.2-1 | 15:59 |
| EagleScreen | second 1.0.2-2 | 15:59 |
| cnd | umang, because I originally developed it in bzr and used bzr builddeb to build packages | 15:59 |
| cnd | I can repackage it as a non-native, but I'm upstream so its easier if I could leave it that way | 16:00 |
| umang | cnd: Ah. But I don't think you should do that unless the package is irrelavant outside Debian/Ubuntu | 16:00 |
| umang | e.g. Lintian | 16:00 |
| cnd | umang, why not? | 16:00 |
| cnd | when I ship the source tarball, I filter out the debian directory | 16:01 |
| EagleScreen | cnd: if this package is not still in Debian and you package it for Ubuntu, you has to version it like this: 1.0.2-0ubuntu1 -> 1.0.2-0ubuntu2 etc.. | 16:01 |
| umang | Just a sec, I'll find the documentation | 16:01 |
| cnd | EagleScreen, so if I resubmit as 1.0.2-0ubuntu1 then I should be good on the versioning front? | 16:01 |
| EagleScreen | yes | 16:01 |
| Laney | /sponsoring could interface with LP to provide a list of packages-you-can-sponsor | 16:01 |
| EagleScreen | cnd: please merge all your entries in the ubuntu chagelog (debian/changelog) in just one | 16:02 |
| EagleScreen | and verison it 1.0.2-0ubuntu1 | 16:02 |
| === yofel_ is now known as yofel | ||
| cnd | EagleScreen, every single entry in the changelog? | 16:03 |
| cnd | or just since 1.0.2? | 16:03 |
| umang | cnd: For now, you can see this, I'll find a doc that says it more specifically (I'm sure there was one): http://www.debian.org/doc/manuals/maint-guide/ch-update.en.html#fr5 | 16:03 |
| umang | section 9.4 | 16:04 |
| cnd | ok, I'll just make a separate non-native package then | 16:04 |
| EagleScreen | since 1.0.2 | 16:04 |
| EagleScreen | but upstream version always must be continued by an ubuntu revision | 16:05 |
| EagleScreen | never submit an entrie with just 1.0.2 | 16:05 |
| cnd | ok | 16:05 |
| EagleScreen | do the same for previous versions | 16:05 |
| EagleScreen | cnd: have you packaged it using a Debian system? | 16:06 |
| cnd | I currently do my packaging using bzr builddeb | 16:06 |
| cnd | and upload to my ppa | 16:06 |
| EagleScreen | ok | 16:07 |
| cnd | I'll probably continue to do that for development | 16:07 |
| cnd | and have a separate tree for the debian/ files for a non-native package submitted for inclusion into ubuntu | 16:07 |
| umang | cnd: found it http://people.debian.org/~mpalmer/debian-mentors_FAQ.html | 16:07 |
| umang | You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native. | 16:07 |
| cnd | thanks umang | 16:08 |
| umang | ^ quoted from the debian-mentors faq | 16:08 |
| umang | cnd: Welcome | 16:08 |
| umang | :) | 16:08 |
| EagleScreen | cnd: you should ideally include your package in Debian, with a debian revision 1.0.2-1 -> 1.0.2-2 etc.. then it will be automatically synchronized from Debian to Ubuntu | 16:09 |
| cnd | EagleScreen, I will look into that | 16:09 |
| cnd | where is the process documented for inclusion into debian? | 16:10 |
| cnd | also, is it ok if I'm listed as the maintainer in the control file | 16:10 |
| cnd | since I have an @ubuntu.com address | 16:10 |
| persia | cnd: Some people in Debian grumble, but if you're a good maintainer, nobody seems to mind that much. | 16:10 |
| cnd | ok | 16:11 |
| EagleScreen | cnd: all ok you are the maintainer | 16:11 |
| EagleScreen | cnd: visit and read http://mentors.debian.net/cgi-bin/welcome | 16:11 |
| cnd | EagleScreen, thanks | 16:12 |
| EagleScreen | you have to make a good quality package, upload it to debian.mentors repository as if it were a PPA, and then look for a sponsor in #debian-mentors | 16:12 |
| cnd | ok | 16:13 |
| umang | Sorry, I'm curious to know, what does the @ubuntu.com change at debian? | 16:13 |
| Laney | nothing | 16:14 |
| persia | umang: Just some people in Debian are sore because Ubuntu is a derivative. | 16:14 |
| persia | Most people in Debian aren't, but it's worth noting in case one bumps into someone particularly opinionated. | 16:15 |
| EagleScreen | cnd: #debian-mentors channel is in server irc.debian.org | 16:15 |
| Laney | giving back (by maintaining a package there) should make them less sore really | 16:15 |
| umang | But ubuntu encourages upstream contribution to debian instead of only to ubuntu | 16:15 |
| EagleScreen | cnd: update standars version to 3.8.4 | 16:15 |
| cnd | will do | 16:16 |
| umang | I guess I've met only the most people. :) debian-mentors and debian-python have been pretty friendly to me (newbie + ubuntu user) | 16:16 |
| persia | umang: That's been my experience as well, although I hear stories, so like to caution people just in case. | 16:16 |
| rockstar | dholbach, ping | 16:17 |
| dholbach | rockstar: pong | 16:17 |
| umang | Oh yes. I have a related question. If you bump the standards, Lintian fussed about 3.8.4, because Karmic doesn't have the version in sid. So do we have to manually build the lintian source package from sid and then install onto the karmic installation, or do you always run lintian under a chroot? | 16:18 |
| persia | hyperair: You were asking about procedures to apply to MOTU earlier. A decision has been reached, and the wiki is now up-to-date (I believe). | 16:18 |
| rockstar | dholbach, can you take a look at https://bugs.edge.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/516744 | 16:18 |
| ubottu | Ubuntu bug 516744 in tahoe-lafs "please upgrade Tahoe-LAFS to v1.6" [Undecided,New] | 16:18 |
| hyperair | persia: cool | 16:18 |
| hyperair | !motu | 16:19 |
| ubottu | motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See http://wiki.ubuntu.com/MOTU | 16:19 |
| persia | umang: I tend to run lintian in the target environment. Whether you choose to use a chroot, a full install, a VM, etc. depends on your available hardware and preferred workflow. | 16:19 |
| dholbach | rockstar: will do in a sec | 16:20 |
| umang | persia: OK. But for convenience, is it likely to break something if I downloaded the lintian source package and built it myself? | 16:20 |
| umang | (or karmic) | 16:20 |
| dholbach | rockstar: usually attaching a .diff.gz should be enough and have a look at https://wiki.ubuntu.com/SponsorshipProcess | 16:20 |
| umang | *on karmic | 16:20 |
| rockstar | dholbach, great. I thought I'd bug you since it was you specifically I talked to about getting started in packaging. Eventually I'll find someone else to harass about getting my into Ubuntu. | 16:20 |
| dholbach | rockstar: will review now | 16:20 |
| rockstar | dholbach, okay, great. | 16:21 |
| dholbach | yeehaw | 16:21 |
| persia | umang: No. lintian is frequently backported. But there are differences in lintian between Ubuntu and Debian. It's worth pulling the right one. | 16:21 |
| EagleScreen | umang: just isntall the lintian in Debian sid | 16:21 |
| persia | Mind you, ubuntu-policy doesn't get updated as much as it might, so oddly Ubuntu lintian supports a policy version in excess of that documented. | 16:21 |
| umang | EagleScreen: How, you mean download a binary? | 16:22 |
| EagleScreen | yes, use the Debian package in sid | 16:22 |
| umang | persia: Karmic is still at 2.2.17, if I'm going to submit to debian, I'd like 2.3.3 | 16:23 |
| EagleScreen | http://packages.debian.org/sid/lintian | 16:23 |
| umang | EagleScreen: Thanks. :) | 16:23 |
| persia | umang: Right, but my point is that if you're submitting to Debian, you want *Debian's* lintian, rather than Ubuntu's. | 16:23 |
| persia | The changes are relatively minor, but sometimes surprising. | 16:24 |
| umang | persia: The part I'm confused about is how. Build the source package or run in chroot? | 16:24 |
| umang | Or download binary | 16:24 |
| umang | from sid | 16:24 |
| persia | I think you'd do best to either run in a chroot or build a cross-port binary given those choices. | 16:25 |
| umang | persia: Thanks. | 16:25 |
| umang | :) | 16:25 |
| persia | But you could also run it in a VM or on hardware, if you have those available. Whatever works best for you is best. | 16:25 |
| umang | persia: I'm not experienced enough to run sid like that. :P I'll stick to chroot. :) | 16:26 |
| EagleScreen | for standars 3.8.4 you need lintian 2.3.3 | 16:26 |
| EagleScreen | it is in sid | 16:26 |
| Rhonda | EagleScreen, umang: Please notice that 2.3.2 on that sid page is outdated, 2.3.3 is current. packages.debian.org still seems to not have recovered from its harddisk issues. | 16:26 |
| * Rhonda . o O ( see output of "rmadison lintian" ) | 16:27 | |
| EagleScreen | yes it is outdated | 16:27 |
| persia | Or, rather `rmadison -u debian lintian` when running on karmic :) | 16:27 |
| umang | Yes. I have actually been checking it on a chroot, I just wanted to know what's best. :) | 16:27 |
| persia | umang: chroot is fine, if it works for you. | 16:27 |
| Rhonda | persia: Oh, makes sense that ubuntu patched devscripts to use -u ubuntu by default. Should have thought of that. :) | 16:27 |
| umang | Thanks all. :) Going to get some sleep now. Good Night. | 16:28 |
| persia | Rhonda: That was why I had the "nifty ..." comment a couple days back: I thought the entirety of -u was an Ubuntu patch. | 16:28 |
| EagleScreen | if you only package for Ubuntu you can use standars 3.8.3 | 16:28 |
| * persia should probably use the Debian system for more than a NAS more often | 16:28 | |
| Rhonda | persia: No, there is also -u bpo :) | 16:28 |
| Rhonda | For backports.rog | 16:29 |
| Rhonda | org | 16:29 |
| persia | Right. madison.cgi in Soyuz includes backports by default (but unfortunately only includes 2 architectures for binary results) | 16:29 |
| === micahg1 is now known as micahg | ||
| persia | (or at least I *think* it's Soyuz) | 16:29 |
| Rhonda | EagleScreen: One can also use standards 3.8.3 for Debian, there is nothing really wrong with doing so. The changes aren't relevant for most parts, and it's technically the same, most of the times. | 16:30 |
| Rhonda | most packages, that is. | 16:30 |
| EagleScreen | yes | 16:30 |
| EagleScreen | ofcourse, but some uploaders take care about 3.8.4 | 16:31 |
| corecode | hey | 16:33 |
| corecode | the newer linux kernels come with tools, specifically "perf" | 16:33 |
| corecode | i can't seem to find a package containing it | 16:33 |
| corecode | what's the opinion on how to package that? | 16:34 |
| persia | corecode: You might want to ask in #ubuntu-kernel : that team has more experience in that area. | 16:34 |
| corecode | thanks | 16:35 |
| persia | (assuming it's part of the kernel distribution, rather than just being some other tool distributed from kernel.org) | 16:35 |
| corecode | so many different chans | 16:35 |
| persia | Lots of different teams :) | 16:35 |
| Laney | MOTU: Signposts into Ubuntu development | 16:36 |
| persia | Laney: Well, #ubuntu-devel is probably better for that, but most of us end up working with several teams, just in the nature of what we do :) | 16:37 |
| Laney | persia: Indeed. Just that recent discussions have me considering how the future looks... | 16:37 |
| persia | With today's TB decision, I think there is now a clear path forward. | 16:38 |
| sebner | Laney: ultra uploader everywhere | 16:38 |
| persia | MOTU may be less broad than it was, and more QA focused, but at least we know it has a future, and how that works. | 16:38 |
| * Laney ITA: sebner | 16:40 | |
| sebner | Laney: hm? | 16:48 |
| Laney | never mind :) | 16:49 |
| sebner | Laney: I just wanted to point out that there is a new developer position, comparable to core-dev, with upload rights nearly everywhere | 16:52 |
| persia | sebner: Hrm? What sort of developer? | 16:59 |
| sebner | persia: I forgot the correct spelling -.- | 17:00 |
| persia | sebner: I just reedited UbuntuDevelopers, and I'm fairly sure we only have six types, which doesn't include anything like that. | 17:01 |
| Laney | are most package sets restricted? | 17:01 |
| persia | None so far. | 17:01 |
| sebner | persia: really? I've heard about that kind of thing. Let me check | 17:01 |
| persia | sebner: Please. I'd like that everyone had a single shared understanding about these things :) | 17:02 |
| Laney | well... | 17:02 |
| Laney | https://wiki.ubuntu.com/ArchiveReorganisation/Permissions#Resolving%20upload%20permissions the second bullet here | 17:02 |
| persia | That probably needs revision now that MOTU exists. | 17:03 |
| persia | But it basically just says that people can upload to the stuff to which they have permisison to upload, except from the packages' perspective. | 17:03 |
| sebner | persia: ah, it was "generalist developer" | 17:03 |
| Laney | so "generalist" is like core-dev, right | 17:04 |
| sebner | Laney: aye | 17:04 |
| sebner | Laney: like core-dev, upload rights everywhere except special stuff like kernel ,.. | 17:04 |
| Laney | and "MOTU" is P(generalist) \ U (packages in sets) | 17:04 |
| sebner | heh | 17:05 |
| persia | Laney: At the time that document was written, it included an understanding the "MOTU" and "core-dev" would both be replaced by "Generalist". I do not believe this is still the case. | 17:05 |
| persia | A proposal for a definition of MOTU under ArchiveReorg has been submitted and approved. | 17:05 |
| persia | The definition of "core-dev" is still a bit unclear, but I suspect it will end up being close to the "Generalist Developer" of the prior documentation. | 17:06 |
| Laney | Good, that's how I understand it | 17:06 |
| Laney | so I don't think it really affects current permissions that much | 17:06 |
| persia | Where I'm less certain is whether "core-dev" will have access to restricted sets, or whether some other group will be created that has access to everything, or whether core-dev will have access limited only by restricted package sets. | 17:06 |
| persia | No. For us (MOTU), the next big permissions change is when we move from being able to upload to the universe component to only being able to upload to packages that don't belong to package sets. | 17:07 |
| persia | Which means we can't upload to as much stuff, but also means we don't have to feel responsible for as much stuff. | 17:07 |
| persia | Those of us who have interests in packages belonging to package sets would likely be welcomed as members of the teams responsible for those package sets. | 17:08 |
| sebner | persia: I'm wondering if a MOTU can join freely or also has to make some applications as non-MOTU folks | 17:08 |
| persia | sebner: I personally consider membership in MOTU entirely separate from membership in any other development team. I don't see any conflict in belonging to several of them, nor any dependencies between them. | 17:09 |
| persia | Until today, I considered MOTU just another delegated team, but the TB has determined that MOTU is a bit special for now. | 17:10 |
| oojah | persia: Is there a link where I can read about that? | 17:10 |
| sebner | persia: yeah, I just thought about the technical skill question | 17:10 |
| Laney | Well, being the "default" uploaders to the distribution does put MOTU in a bit of a special position AFAICS | 17:11 |
| persia | oojah: About which? | 17:11 |
| persia | Laney: Indeed. I don't argue with the TB decision, it just is different than my previous opinion :) | 17:11 |
| oojah | The TB stuff. | 17:11 |
| Laney | the minutes just went out to u-d-a | 17:12 |
| oojah | Ok | 17:12 |
| Laney | and the logs in the usual place... | 17:12 |
| Laney | !logs | 17:12 |
| ubottu | Official channel logs can be found at http://irclogs.ubuntu.com/ - For LoCo channels, http://logs.ubuntu-eu.org/freenode/ | 17:12 |
| ogra | \sh, thanks for the rootstock fix, why wasnt there a bug | 17:16 |
| corecode | what's the TB decision? | 17:19 |
| persia | corecode: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-February/000673.html | 17:21 |
| ari-tczew | what is the solution for sync, if package's name has been changed? | 17:25 |
| kreuter | hi #ubuntu-motu. I'm trying to upload my first package to REVU, and am dubious of the dput documentation. am I really only uploading the source.changes file? | 17:26 |
| Laney | nope | 17:26 |
| Laney | have a look at the contents of the changes file | 17:26 |
| maco2 | kreuter: dput will pull the rest from the same directory | 17:26 |
| maco2 | i think... | 17:27 |
| Laney | there is a Files: section | 17:27 |
| maco2 | it all it makes it there | 17:27 |
| kreuter | but the only command I need to execute is "dput revu <foo>_source.changes"? | 17:27 |
| EagleScreen | yes maco2 and kreuter, only the .changes | 17:27 |
| kreuter | great. thanks! | 17:27 |
| maco2 | kreuter: right | 17:27 |
| Laney | that's all you need to type, but it's not all you are really uploading | 17:27 |
| kreuter | ok. I guess I expected something more involved. | 17:28 |
| maco2 | EagleScreen: well now im wondering about teh insides of dput. i know i only need to tell it the .changes, but i think the way it works is it then looks for the rest of the files in the same directory, and grabs those too, right? | 17:28 |
| Laney | I just said | 17:28 |
| oojah | maco2: I'd read what Laney said. | 17:28 |
| EagleScreen | yes maco2 | 17:28 |
| Laney | that's why you pass -sa or -sd to dpkg-buildpackage. | 17:29 |
| ari-tczew | Laney: could you take a look @ http://packages.debian.org/changelogs/pool/non-free/f/frobtads/frobtads_0.13-2/changelog | 17:29 |
| ari-tczew | and how we can sync it | 17:29 |
| EagleScreen | -sa is needed when a new upstream tarball is used | 17:29 |
| persia | ari-tczew: The common way is to request inclusion of the new package and removal of the old package. | 17:29 |
| persia | Most of the time the old package is removed in Debian already, but I've ended up filing a few removal requests there when that didn't happen. | 17:30 |
| Laney | -sa is needed when you need to have the .orig.tar.gz included in the changesfile and it isn't by default | 17:30 |
| Laney | most commonly when uploading a merge which contains a new upstream version | 17:30 |
| ari-tczew | persia: how are you think, can be done this before FFe? | 17:30 |
| Laney | ari-tczew: do it now | 17:30 |
| persia | ari-tczew: Quite possibly. I handled a new-package-addition and removal last week. Dunno why someone couldn't do it this week. | 17:31 |
| micahg | what's the proper short for for replaces/provides/conflicts if any? | 17:31 |
| micahg | *short form | 17:31 |
| persia | Generally the archive-admins run the scripts every day, so it's just a matter of making sure the requests have been made properly. | 17:31 |
| persia | micahg: How do you mean "short form"? | 17:32 |
| micahg | persia: can I say R/P/C in a changelog entry? | 17:32 |
| Laney | there is no need to make a changelog entry short | 17:34 |
| micahg | Laney: ok | 17:34 |
| Laney | Making it understandable for people in the future should be your goal | 17:35 |
| micahg | was just wondering if there's a convention | 17:35 |
| Laney | not that I know of | 17:35 |
| persia | I usually just put something like "Enable transition from ${PACKAGE}", but that may be too terse. | 17:35 |
| persia | Or "Support transition ..." | 17:35 |
| Laney | Added replaces/conflicts on xxx due to yyy | 17:35 |
| ari-tczew | persia: do I need to report 2 bugs? 1) remove 2) sync new package? | 17:38 |
| Laney | yep | 17:39 |
| persia | ari-tczew: sync-new should happen without a bug if it reaches testing. | 17:39 |
| persia | If it doesn't reach testing, you'll need a sync-new bug. | 17:39 |
| ari-tczew | yes, this is in testing | 17:39 |
| ari-tczew | but still no synced into lucid | 17:39 |
| persia | And check in Debian: I often find it's more productive to work with maintainers and file removal bugs in Debian directly. The removal is synced (if it happens in time) | 17:40 |
| persia | If it's in testing and not in lucid, check (in #ubuntu-devel) to see if an archive-admin has pulled the new sources from Debian testing recently. | 17:40 |
| persia | There's probably a bunch of stuff we ought have included. | 17:40 |
| ari-tczew | persia: I think is not synced yet, because in Debian this is not _new_package_, just change package's name | 17:41 |
| persia | ari-tczew: The source package name changed? | 17:42 |
| kreuter | is there a delay between dput finishing and the package becoming visibole on revu.ubuntuwire.com? | 17:42 |
| persia | kreuter: Yep. The queue is processed every 5 minutes or so. If it's a long time, ask for a REVU Admin to investigate. | 17:42 |
| kreuter | alright. thank you. | 17:42 |
| ari-tczew | persia, just look at changelog http://packages.debian.org/changelogs/pool/non-free/f/frobtads/frobtads_0.13-2/changelog | 17:43 |
| kreuter | uh, one last question: is it necessary to upload different sets of files for different architectures? | 17:43 |
| persia | ari-tczew: Yes. We'll see that as a NEW frobtads package. So will Debian. Compare the results on packages.qa.debian.org for frobtads and tads. | 17:44 |
| persia | ari-tczew: Also, check the Ubuntu NEW queue: it may already be there. | 17:44 |
| persia | kreuter: No. In fact, it's necessary not to upload any architecture-specific files. | 17:44 |
| kreuter | hrm. dput says it uploaded an amd64.deb. will that cause problems? was I supposed to have deleted the .deb before running dput? | 17:45 |
| persia | Yes. I'll go delete that. | 17:45 |
| persia | No, you need to dput source.changes | 17:45 |
| kreuter | hrm. here's what I did: "debuild; cd ../; dput <package>_source.changes" | 17:46 |
| kreuter | I guess I wasn't supposed to do a debuild./ | 17:46 |
| persia | kreuter: All cleaned out. | 17:47 |
| persia | You wanted debuild -S. | 17:47 |
| kreuter | persia: thanks. should I try again, starting with debuild -S? | 17:47 |
| persia | Yep. | 17:48 |
| kreuter | okay. | 17:48 |
| rmunn | Is it possible to remove a file from a source package without modifying the .orig.tar.gz? The upstream source package includes a binary .jar that shouldn't be there. I tried "rm nltk/nltk.jar; debuild -S" but the removal of nltk.jar didn't show up in the .diff.gz. What should I do here? | 17:53 |
| persia | rmunn: Well, there's two schools of thought: repack and delete on clean. | 17:54 |
| persia | My personal preference is to verify the binary object is licensed in a redistributable way, and delete it in my clean: rule in debian/rules. | 17:54 |
| rmunn | persia: There are no license problems with distributing the .jar since it's built from NLTK source files that are all present in the original tarball, so I'd prefer to leave the original tarball alone and delete it in debian/rules. | 17:54 |
| persia | If the blob isn't licensed in a redistributable way, or can't be regenerated from source, or is otherwise annoying, you have to repack. | 17:54 |
| rmunn | (And that are all licensed under Apache-2.0 license) | 17:54 |
| persia | I can't say I've memorised all the terms of the Apache 2.0 license, but my memory is that it ought be safe. | 17:55 |
| rmunn | All right, I'll delete it in the clean: target of debian/rules. | 17:55 |
| persia | Just be prepared to defend your decision if an archive-admin is in a hurry, and be sure to set out your argument in terms of having a license to redistribute the blob, rather than in terms of deleting it in clean. | 17:56 |
| \sh | ogra: there was a bug :) | 18:09 |
| ogra | \sh, against what ? | 18:09 |
| ogra | i didnt get one | 18:09 |
| \sh | ogra: could be because it was in the sponsoring queue? | 18:09 |
| ogra | no, i probably am not subscribed to the package bugs | 18:10 |
| ogra | i'll check that, might be my fault | 18:10 |
| \sh | bug #517524 | 18:11 |
| ubottu | Launchpad bug 517524 in rootstock "Error in debian/watch file" [Undecided,Fix released] https://launchpad.net/bugs/517524 | 18:11 |
| \sh | https://bugs.edge.launchpad.net/ubuntu/+source/rootstock/+bug/517524 | 18:11 |
| ubottu | Ubuntu bug 517524 in rootstock "Error in debian/watch file" [Undecided,Fix released] | 18:11 |
| ogra | thanks | 18:11 |
| \sh | ogra: there are two more bugs attached | 18:11 |
| ogra | i prefer to know about my packaging errors :) | 18:11 |
| \sh | ogra: I don't think it's a pkg bug, I wonder if it was a change in launchpad which triggered that? | 18:11 |
| ogra | yeah, i guess the whishlist one is a wontfix ... | 18:12 |
| ogra | rootstock trunk is already a lot more complex, would be very hard to do | 18:12 |
| ogra | ok, securetty is triaged ... i'll fix that with my next upload | 18:13 |
| randomaction | Is this sync request somehow malformed? It was overlooked during two last waves of syncs. (bug 491988) | 18:13 |
| ubottu | Launchpad bug 491988 in gcl "Sync gcl 2.6.7-56 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/491988 | 18:13 |
| \sh | ogra: does armel has different ttyS devices? | 18:15 |
| ogra | yeah, nearly for each board there is a different name | 18:15 |
| ogra | versatile boards have ttyAMA0, babbage boards have ttymxc0 ... some just use ttyS though | 18:15 |
| ogra | but given that the device name is a parameter to rootstock if you want a serial tty its not a prob | 18:16 |
| ogra | just some sed magic to add the entry to securetty | 18:16 |
| \sh | ogra: isn't it a better idea to "link" /dev/tty<whatever> to something more standard? | 18:16 |
| \sh | ogra: somewhere in udev hell? | 18:16 |
| ogra | well, that would break vendor docs | 18:17 |
| ogra | usually you get a handbook with your board where such stuff is defined | 18:17 |
| ogra | we could indeed add a udev rule | 18:17 |
| ogra | but i doubt upstream would accept it ... and its hard to get Keybuk convinced to carry extra rules if they are not absolutely needed | 18:17 |
| \sh | ogra: well, but can't we identify those "exceptions" during install and we add some udev rules to react on those "exceptions"? | 18:17 |
| ogra | uuh, no, not if they arent in any package | 18:18 |
| ogra | i'm just working on rootstock to be closer to the default ubuntu images ... such a change would be awkward :) | 18:19 |
| \sh | spec: "Dynamic UDEV Rule creation on arch during install" ;) | 18:19 |
| persia | Would it be similarly infeasible to have a special arm-serial-console package that just contained readmes and udev rules? | 18:19 |
| * persia also advertises #ubuntu-arm as a good forum for this discussion | 18:19 | |
| ogra | persia, that would be possible and cleantr | 18:19 |
| ogra | *cleaner | 18:19 |
| ogra | heh, yeah | 18:19 |
| persia | ogra: You could probably build it out of the rootstock source, etc. :) | 18:19 |
| ogra | heh, yeah thats possible | 18:19 |
| ogra | though i wont have time before FF for that | 18:20 |
| ogra | not sure such a bug justifies an FFe for a new package | 18:20 |
| * \sh just creates udev rules during deploy time, when FAI comes, it checks my database, and writes udev rules for those machines ;) depeding on the input from my asset management system...but this is far more advanced ;) | 18:20 | |
| ogra | thats why we dont use FAI but d-i in ubuntu :) | 18:21 |
| \sh | hehe | 18:21 |
| jcastro | anyone know anyone who uses or likes mongodb? | 18:21 |
| persia | ogra: Adding a udev rule is trivial with dh_installudev. Fixing it to work for everyone is clearly post-FF bugfixing :) | 18:21 |
| jcastro | it's a sql-less db. | 18:21 |
| ogra | anyway, i need to take a break, long conf call at 8pm ... | 18:21 |
| ogra | persia, i'll quote you on that if slangasek hunts me down for it *g* | 18:22 |
| \sh | couchdb, mongodb why are all cool db systems named after lazyness ;) | 18:22 |
| persia | ogra: As long as you commit to fixing it by beta-freeze, I don't mind if you quote me on that. | 18:22 |
| persia | \sh: Because of hubris, laziness, and impatience | 18:23 |
| oojah | Would someone please review http://revu.ubuntuwire.com/p/sqlite3-pcre when they get a chance? | 18:23 |
| slangasek | ogra, persia: depending on what the udev rule does, I might hunt you down sooner. :) | 18:24 |
| \sh | well, couchdb will be included in our 6.1 release..which makes me not happy...and that cisco is tainting the linux kernel with binary blobs on cisco asr, it makes me think../me should switch back to windows or go forward to darwin+apple ui ;) | 18:24 |
| ogra | haha :) | 18:24 |
| persia | slangasek: It creates a known good dev point for serial consoles on armel devices. Priority: extra. | 18:24 |
| slangasek | what's "known good"? | 18:25 |
| ogra | slangasek, linking weird tty names to generic ttyS | 18:25 |
| slangasek | so that will conflict on any system that has both ttymxc and real ttyS? | 18:25 |
| ogra | slangasek, like ttyAMA0 or ttymxc0 | 18:25 |
| ogra | probably | 18:25 |
| ogra | though i wouldnt know what such a system would be | 18:25 |
| persia | Um, why wouldn't we use something like /dev/tty-console | 18:26 |
| persia | That would avoid the conflict. | 18:26 |
| \sh | persia: rewrite LPIC ;) | 18:26 |
| ogra | you would need a lot of soldering experience and a microscope to build it :) | 18:26 |
| persia | \sh: Why? | 18:26 |
| \sh | persia: why not...it would make a good question.."On armel device X what is the name of your serial device? a) ttyS0 b) ttyAMA0 c) ttymxc0 or d) tty-console ;) | 18:27 |
| \sh | LPIC 99101 ;) | 18:28 |
| persia | \sh: Ah. See, I'd like to live in a world where that sort of knowledge didn't need to reside in humans because we had sufficient automation :) | 18:28 |
| \sh | persia: I would like to live in a world, where I plug in a <whatever> hardware thingy into my computer, and everything would behave after a written standard ... but oh well...nice..cisco asr -> crash -> with simple bgp full feed | 18:31 |
| \sh | so...dinner time | 18:32 |
| persia | \sh: You could, but it just needs someone to do the automation first. As time passes, more and more of my hardware actually works. | 18:33 |
| lucas | hi | 18:46 |
| lucas | a long time ago, we had a lot of FTBFS bugs because of a change in X that was picked from the Debian SVN (a dependency change, I think). that change was not in Debian by the time. | 18:47 |
| lucas | does someone remember more details? | 18:47 |
| persia | lucas: If nobody answers here, you might try #ubuntu-x | 18:52 |
| crimsun | what's the timeframe for "a long time ago"? | 18:53 |
| lucas | 3-5 years | 18:53 |
| persia | There was a GL-related transition in breezy, but I forget the details. | 18:54 |
| persia | There was also the x-dev transition, but I don't remember that generating heaps of FTBFSs. | 18:55 |
| kreuter | so my upload to REVU hasn't shown up after about an hour. could anybody with the relevant privileges tell me if I've done something wronga again? | 18:57 |
| persia | kreuter: Try to use the string "REVU Admin" in your requests of that sort, as it may attract more attention if people are only paying half-attention :) Looking now. | 18:57 |
| kreuter | persia: alright. thanks for the tip. | 18:58 |
| persia | What's your LP ID? | 18:58 |
| kreuter | richard-10gen, I think. | 18:58 |
| kreuter | er, my name on LP is "Richard M Kreuter" | 18:59 |
| persia | kreuter: richard-10gen was the string I wanted :) Have you ever logged in to REVU? | 19:01 |
| kreuter | I believe I'm logged in now. | 19:01 |
| crimsun | GL transition was mostly "Depend on lib{gl,glu}1-mesa-dev instead of xlibmesa-{gl,glu}-dev" | 19:01 |
| persia | kreuter: Had you logged in before uploading? | 19:02 |
| persia | crimsun: Yes. That was it. | 19:02 |
| kreuter | persia: yes. | 19:02 |
| crimsun | back when we were tracking transition work on the wiki! | 19:02 |
| persia | OK. The signatures look good. Let me try tossing the .changes back in the queue and see if that fixes it (sometimes this works) | 19:02 |
| kreuter | hm. | 19:02 |
| persia | crimsun: Right. | 19:03 |
| persia | Which worked nicely, but kinda depended on there not being quite so many of us. | 19:03 |
| rmunn | OK, http://revu.ubuntuwire.com/p/python-nltk now has a new version uploaded that fixes the problems pointed out to me yesterday. I'd appreciate a MOTU or two checking it out and giving me feedback and/or advocating the package. Note that there's one lintian warning (with minor severity), but according to my understanding of Debian policy, the warning is wrong in this particular case. | 19:05 |
| persia | kreuter: Seems it got rejected again. Let me look harder. | 19:05 |
| kreuter | :( | 19:05 |
| rmunn | Since NLTK is apparently a rather famous package in the field of computational linguistics (an O'Reilly book was recently published about it: http://oreilly.com/catalog/9780596516499), I'd like to get this package into Lucid, which means advocates are needed. Thanks! | 19:06 |
| persia | kreuter: As a general guideline, you don't want to have two changelog entries with the same version. | 19:07 |
| persia | kreuter: I don't *think* the issue is "Distribution: unsable", but that's the only bit I see wrong about the .changes file. | 19:09 |
| rmunn | geser, jcfp: Thanks for your comments yesterday on http://revu.ubuntuwire.com/p/python-nltk, by the way. Much appreciated. | 19:15 |
| kreuter | persia: sorry, meeting. should I change "unsable" to "unstable" and reupload? | 20:10 |
| persia | kreuter: You could try, but I'm unsure if that would work. I've asked in the support channel for ubuntuwire, but haven't heard back yet. | 20:11 |
| persia | Maybe another REVU Admin can figure it out, maybe it needs someone who has access to logs, etc. | 20:12 |
| kreuter | okay. thank you. | 20:12 |
| juancarl1s | need a guide to package these need packaging bugs, but guides i find or someones pointme is for package on my own PPA, i want to share my packaging work with everyone, not only on my PPA, at least on Multiverse or something like that | 20:14 |
| juancarl1s | how to fix need-packaging bugs?, i know package apps | 20:14 |
| fabrice_sp | !revu | juancarl1s | 20:15 |
| ubottu | juancarl1s: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU | 20:15 |
| fabrice_sp | and also !packaging | 20:15 |
| fabrice_sp | !packaging | juancarl1s | 20:15 |
| ubottu | juancarl1s: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports | 20:15 |
| juancarl1s | fabrice_sp: Thanks!, got experience packaging, traduction, and python so maybe i can help | 20:16 |
| fabrice_sp | juancarl1s, sure. You can also help with merges and bug fixing ;-) | 20:17 |
| juancarl1s | fabrice_sp: got some apps marked as "need-packaging bug" on a personal FTP | 20:19 |
| juancarl1s | others guides talk about my PPA, i dont want to use my PPA | 20:19 |
| fabrice_sp | juancarl1s, PPA is a good way to make the application available to people, andtested before being integrated in the archive | 20:20 |
| persia | Well, except that it can complicate things if there are issues with the early PPA releases that require special upgrade handling. | 20:21 |
| juancarl1s | fabrice_sp: but there are some easy to package apps, kinda python apps and such | 20:22 |
| fabrice_sp | persia, sure. But in this case, you can always make a pre upgrade in your ppa, and upload the version after | 20:28 |
| persia | fabrice_sp: Assuming you have clean version and revision strings :) | 20:28 |
| persia | There's also the risk of someone only updating with update-manager -d, which disables PPAs before doing all the upgrade bits. | 20:29 |
| fabrice_sp | lol I prefer not to look at all the PPA out there (even in mine, I have some ugly versions :-D ) | 20:29 |
| fabrice_sp | right | 20:30 |
| persia | I prefer to avoid PPAs entirely, when possible, although I've uploaded some stuff to them previously. | 20:30 |
| * fabrice_sp still has some software in his PPA | 20:31 | |
| fabrice_sp | especially, backports (for calibre, for example) | 20:31 |
| fabrice_sp | juancarl1s, what experience do you have in packaging? | 20:32 |
| crimsun | james_w: hi, do you have a moment to look at lp:ubuntu/goffice and lp:debian/squeeze/goffice? "bzr merge-package" is balking due to a missing tag. It doesn't appear as if the latest lucid source package has been imported, either. | 20:33 |
| crimsun | or squeeze, for thatmatter | 20:33 |
| fabrice_sp | libboost-dev points to 1.40 in Lucid, right? | 20:36 |
| crimsun | yes | 20:37 |
| fabrice_sp | thanks :-) | 20:37 |
| juancarl1s | fabrice_sp: i work by selling services consulting support to small business and commercial shoops locally, i build solutions for common problems, packaing, traducing, and making quick'n'dirty python apps | 20:38 |
| juancarl1s | not my main job, but my main job gives me spare time | 20:38 |
| fabrice_sp | ok | 20:39 |
| juancarl1s | lol, sorry for my english im reading the web ATM | 20:39 |
| fabrice_sp | np: not native english myself :-) | 20:40 |
| juancarl1s | fabrice_sp:"Uploads to REVU should be source files, with the original tarball" | 20:41 |
| juancarl1s | fabrice_sp: explanations are not so explanatory, a screenshot may be good, continue reading | 20:42 |
| fabrice_sp | yes. Even if you should build the package locally before | 20:42 |
| juancarl1s | but i can upload a .deb or not? | 20:42 |
| fabrice_sp | the packaging guide should explain how to generate the source file | 20:43 |
| fabrice_sp | no: it has to be a changes files, generated from a dsc | 20:43 |
| juancarl1s | or the ready-to-build sources? | 20:43 |
| fabrice_sp | (basically, with debuild -sa -S ) | 20:43 |
| fabrice_sp | a source package | 20:43 |
| juancarl1s | :( | 20:44 |
| fabrice_sp | https://wiki.ubuntu.com/PackagingGuide/Complete | 20:45 |
| fabrice_sp | A source package commonly contains a .dsc file describing the package and giving md5sums for the source package, an .orig.tar.gz file containing the source code from the author(s) and a .diff.gz file containing the packaging (in the debian/ directory) and patches applied against the source code. | 20:46 |
| juancarl1s | fabrice_sp: yes i know | 20:47 |
| fabrice_sp | ok | 20:48 |
| juancarl1s | fabrice_sp: what if not authors .tar.gz?, sometimes its only a .py or .zip or whatever? | 20:48 |
| fabrice_sp | you have to create a tarball, even if it's from a svn or a git repository | 20:49 |
| * fabrice_sp don't remember if source format 3.0 support zip files | 20:49 | |
| juancarl1s | ok | 20:50 |
| ari-tczew | better pack in .tar.gz | 20:52 |
| fabrice_sp | last package I uploaded was a tar.bz2 | 20:52 |
| fabrice_sp | and I think mame is zip | 20:52 |
| fabrice_sp | no: sdlmame is repacked to tar.gz | 20:53 |
| fabrice_sp | by the way, REVU support source format 3.0 yet? | 20:53 |
| juancarl1s | lol, REVU logo is nice! Playmobil xD | 20:54 |
| juancarl1s | i got my PGP keys uploaded | 20:54 |
| bdrung | fabrice_sp: can you use "dpkg-architecture -qDEB_BUILD_ARCH" to determine the architecture for test_install (ack-sync)? | 20:54 |
| fabrice_sp | bdrung, the sbuild can have a different arch than your main system, so I didn't found an easy way to determine the output | 20:55 |
| fabrice_sp | as well as pbuilder, if I remember correctly | 20:55 |
| bdrung | fabrice_sp: then use globbing | 20:56 |
| fabrice_sp | globbing?! | 20:56 |
| juancarl1s | you are using LXC or something like that for testing? | 20:56 |
| fabrice_sp | oh: patterns | 20:56 |
| fabrice_sp | juancarl1s, I'm using chroots | 20:57 |
| bdrung | fabrice_sp: http://docs.python.org/library/glob.html | 20:57 |
| juancarl1s | chroot is nice | 20:58 |
| fabrice_sp | bdrung, thanks! :-) I'm reading Python for beginners right now :-) (began last week) | 20:59 |
| bdrung | :) | 20:59 |
| bdrung | fabrice_sp: you will love python | 20:59 |
| fabrice_sp | juancarl1s, I also have a VM, as sometime, the chroot is not working for some stuff | 20:59 |
| fabrice_sp | bdrung, It's nice, yes: I come from C++ (with some java and C), so it's a kind of easier :-) | 21:00 |
| fabrice_sp | that may explain why my code is not so nice | 21:00 |
| fabrice_sp | :-D | 21:00 |
| bdrung | yes, it's easier and you reach your goal faster | 21:00 |
| juancarl1s | LOLCode is nice | 21:01 |
| juancarl1s | xD | 21:01 |
| POX | fabrice_sp: http://diveintopython.org/ | 21:01 |
| lfaraone | Hi, I was wondering of anybody had some time to do a quick review of a new python module: http://revu.ubuntuwire.com/details.py?upid=7621 | 21:01 |
| bdrung | fabrice_sp: can you wrap long lines? | 21:01 |
| lfaraone | (it's depended on by groundcontrol, and we want to get it in before FF) | 21:01 |
| lfaraone | persia: care to take a look? | 21:02 |
| fabrice_sp | POX, I'm reading the spanish version ;-) | 21:03 |
| fabrice_sp | bdrung, for the piuparts call ,you mean? | 21:03 |
| juancarl1s | ha hablas español fabrice_sp jajajajaja | 21:03 |
| fabrice_sp | ;-) | 21:04 |
| POX | lfaraone: it will be extremely hard to find a sponsor in Debian if you'll not replace pycentral with pysupport | 21:04 |
| bdrung | fabrice_sp: yes. you can use ["a",\n"b",\n"c"] | 21:04 |
| fabrice_sp | ok. Will do (I'll try also to add piuparts call with pbuilder tarball) | 21:06 |
| lfaraone | POX: is there good reason for this general hatred of pycentral? | 21:06 |
| juancarl1s | REVU says im Timezone: Europe/Berlin (GMT+1), and im not, i cant edit, im logged-in | 21:06 |
| juancarl1s | doesnt matter? | 21:06 |
| juancarl1s | im GMT-3 | 21:06 |
| lfaraone | juancarl1s: it's not relevent, really. | 21:06 |
| juancarl1s | ok | 21:07 |
| lfaraone | POX: I've seen many people say things like that, that's why I ask. Is there anything inherently wrong with pycentral? | 21:08 |
| persia | lfaraone: Nothing screams out at me, except that I don't really like python-mkdebian | 21:09 |
| POX | lfaraone: well, short story: pysupport is maintained in Debian | 21:09 |
| POX | (bugs are fixed, etc.) | 21:10 |
| POX | lfaraone: get-orig-source looks familiar ;) | 21:12 |
| lfaraone | POX: heh :) | 21:12 |
| persia | POX: Do you know of anything maintained for pysupport that mirrors python-mkdebian? | 21:12 |
| persia | (from python-distutils-extra) | 21:13 |
| POX | I don't know python-mkdebian very well (never used it to be honest) | 21:13 |
| * POX maintains stdeb | 21:13 | |
| persia | POX: it autogenerates copyright, control, rules, compat, watch? | 21:14 |
| POX | control, rules, compat - yes | 21:15 |
| persia | Well then, maybe I'll send you a patch rather than trying to figure out python-mkdebian (which was causing me confusion). | 21:15 |
| persia | With Lucid, there are a number of tools being released that attempt to automate package construction for python developers, and they all seem to use python-mkdebian today. | 21:16 |
| POX | persia: great, I plan to work on stdeb a little bit once I finish dh_python | 21:17 |
| juancarl1s | LOL, Python tag at REVU is giant | 21:18 |
| fabrice_sp | bdrung, I'll change also the status from Confirmed to Triaged, if you are ok | 21:18 |
| persia | POX: What's the current estimated schedule for dh_python? Weeks or Months? | 21:18 |
| ari-tczew | fabrice_sp: what is the different between Confirmed and Triaged in sync requests? | 21:18 |
| persia | ari-tczew: Isn't really one. | 21:19 |
| fabrice_sp | ari-tczew, for the archive admin, it's the same | 21:19 |
| POX | we have a freeze in March and I promised doko to have it ready in Squeeze | 21:19 |
| fabrice_sp | IIRC, the wiki says to put Triaged | 21:19 |
| bdrung | fabrice_sp: i am fine with that | 21:19 |
| POX | I work now on a compatibility with PEP | 21:20 |
| POX | 3147 | 21:20 |
| persia | POX: Even faster than I'd hoped. Thanks for the update. Good luck! | 21:20 |
| rmunn | How do I add a tag to a REVU upload? http://revu.ubuntuwire.com/p/python-nltk should probably be tagged with "python" but I can't find a way to tag it anywhere on that page... | 21:21 |
| lfaraone | persia: should I increment the ubuntu revision on each REVU upload? | 21:24 |
| persia | lfaraone: Please don't | 21:25 |
| lfaraone | persia: mk, just wondering. One of my sponsors in debian insisted that I do so, and he ended up uploading a -4 version of a package to NEW :) | 21:25 |
| POX | depends on a sponsor | 21:26 |
| lfaraone | POX, persia, new version sans pycentral: http://revu.ubuntuwire.com/details.py?upid=7647 | 21:27 |
| persia | I've had sponsors in Debian insist both ways. For REVU, I tend to encourage collapsing the changelog, as I don't think end-users care about what was done prior to the initial release, excepting documentation of local patches. | 21:28 |
| lfaraone | *same version, different content.s | 21:29 |
| juancarl1s | !foo | 21:30 |
| ubottu | bar | 21:30 |
| juancarl1s | !bar | 21:30 |
| ubottu | baz | 21:30 |
| lfaraone | !botabuse > juancarl1s | 21:30 |
| ubottu | juancarl1s, please see my private message | 21:30 |
| POX | lfaraone: why XS-Python-Version: >= 2.6? I don't see anything that requires 2.6 (nor even 2.5) | 21:31 |
| lfaraone | POX: upstream's packaging used "current". I'm not sure how to check for compatiblity with older python versions. (the only change I noticed between 2.5 and 2.6 is "with") | 21:31 |
| * POX checked with 2.4 and 2.5 | 21:32 | |
| lfaraone | POX: mk, I'll lower it to 2.4 then, thanks! | 21:32 |
| POX | "current" is bad and should be avoided in 99% of cases | 21:33 |
| lfaraone | POX: I realize, that's why I changed it :) | 21:33 |
| POX | python-support can most probably be moved to -Indep | 21:34 |
| lfaraone | POX, persia, "third (er, fourth) time's the charm" upload: http://revu.ubuntuwire.com/details.py?upid=7649 | 21:49 |
| * persia steps away, still not being confident about python, and not having seen anything else worthy of mention | 21:51 | |
| persia | I'm always happy to *reject* python packages that have something else wrong, but not quite entirely confident advocating them. | 21:51 |
| kreuter | persia: so I just tried re-uploading my package with the changelog fix, but revu won't take it. any ideas? | 21:52 |
| lfaraone | kreuter: what error did you get? | 21:53 |
| kreuter | "Already uploaded to revu on revu.ubuntuwire.com" | 21:53 |
| lfaraone | kreuter: that's a issue with dput. do "dput -f pathtofile" | 21:53 |
| persia | kreuter: You probably have a local .revu.upload file. | 21:53 |
| kreuter | oh | 21:53 |
| lfaraone | kreuter: -f forces dput to reupload. | 21:53 |
| persia | lfaraone: No it isn't: it's a matter of dealing with local files. | 21:53 |
| persia | -f is a large hammer. It's generally worth sorting the issue. | 21:54 |
| kreuter | should I delete the .revu.upload? | 21:54 |
| persia | (because -f can force other classes of failed uploads as well, and that's less good) | 21:54 |
| persia | Yes. If you delete the .revu.upload file, you can upload again. | 21:54 |
| kreuter | um | 21:54 |
| lfaraone | persia: well, the manpage is unclear, then. According to it, all -f does is "-f, --force - force an upload of an already uploaded package." | 21:54 |
| kreuter | okay, done. | 21:55 |
| persia | lfaraone: Or my information is wrong since I haven't looked at that code in quite a while. | 21:56 |
| juancarl1s | REVU is kinda Arch AUR | 22:04 |
| POX | lfaraone: if you'll add python-xdg to build depends I will upload it in Debian | 22:06 |
| juancarl1s | what happend if i try to package/upload an .exe, like pptview or playolinux??? | 22:06 |
| juancarl1s | to REVU | 22:06 |
| juancarl1s | no playonlinux is not the right example, but pptview | 22:07 |
| POX | lfaraone: consider using dh instead of cdbs, though | 22:07 |
| POX | lfaraone: /usr/share/doc/debhelper/examples/rules.tiny | 22:07 |
| juancarl1s | what happend if i try to package/upload an .exe, like pptview??? | 22:10 |
| * POX continues stealing developers ;) | 22:10 | |
| jpds | juancarl1s: It would be uploaded? | 22:10 |
| juancarl1s | lol, you reply my question with a question | 22:11 |
| jpds | juancarl1s: Yes. | 22:11 |
| juancarl1s | but wiki says sources only | 22:11 |
| jpds | juancarl1s: And due to copyright, we would remove it. | 22:11 |
| juancarl1s | why?, i dont talk about licensing | 22:12 |
| juancarl1s | then i report pptview package | 22:12 |
| juancarl1s | for licensing | 22:12 |
| RAOF | There are a number of questions you need to ask: (a) Do we have permission to distribute it? If we don't, then there's no point. | 22:12 |
| juancarl1s | en .exe with permission to distribute | 22:13 |
| juancarl1s | an* | 22:13 |
| RAOF | (b) Can we build the package from source? If so, it could go into universe. If not, it could possibly go into multiverse. | 22:13 |
| juancarl1s | this is nice RAOF | 22:14 |
| lfaraone | POX: done, much appreciated. http://revu.ubuntuwire.com/details.py?upid=7650 | 22:15 |
| POX | lfaraone: let me know if you will want it in Debian (Maintainer field in debian/control and distribution field in debian/changelog will have to be changed before I can upload) | 22:18 |
| juancarl1s | WTFPL are allowed on REVU ? | 22:19 |
| lfaraone | juancarl1s: yes, WTFPL meets the Debian Free Software License. | 22:20 |
| juancarl1s | what means build on top of the main component?, it need to build correctly on a Chroot, Ubuntu with ubuntu-standard installed? | 22:21 |
| lfaraone | POX: okay, I'll add myself as maintainer with Martin as an uploader. | 22:22 |
| lfaraone | POX: do you mind if I set DMUA? | 22:22 |
| POX | are you DM? | 22:23 |
| POX | anyway, please let DD set this flag | 22:23 |
| POX | (and I will not set it in NEW package for sure) | 22:24 |
| lfaraone | POX: yes-ish. I applied two weeks ago, got advocated, and recieved an email from the keyring maintainers to keyring@rt.debian.org that I was being added to DM. | 22:24 |
| POX | ask me again after at least few clean uploads | 22:24 |
| lfaraone | POX: https://rt.debian.org/Ticket/Display.html?id=2115 | 22:25 |
| lfaraone | POX: understood. | 22:25 |
| POX | (clean = no replies to RFS mail) | 22:25 |
| POX | .oO( that will not be easy ;P ) | 22:25 |
| asbin | Hi everybody. I'm looking for a reviewer for some packages. They are fully working, I have tested them on my ppa https://launchpad.net/~asbin/+archive/geexbox/+packages : libnfo http://revu.ubuntuwire.com/details.py?upid=7625 - libplayer http://revu.ubuntuwire.com/details.py?upid=7627 - libvalhalla http://revu.ubuntuwire.com/details.py?upid=7629 - enna http://revu.ubuntuwire.com/details.py?upid=7630 . Thanks ! | 22:25 |
| POX | lfaraone: http://people.debian.org/~piotr/sponsor | 22:26 |
| juancarl1s | i printed the Wiki page to play at home | 22:27 |
| lfaraone | POX: testing in pbuilder right now, I didn't have a sid base built yet so it might take a few mins. | 22:29 |
| juancarl1s | ✔ thanks for the Help... | 22:32 |
| POX | lfaraone: please create Debian chroot as well (to test the package) | 22:32 |
| dooooomi | mok0: hi! if you've got a minute, i changed klick's debian/copyright as you suggested | 22:37 |
| mok0 | dooooomi: ok, great | 22:38 |
| mok0 | dooooomi: is it on REVU already= | 22:39 |
| mok0 | ? | 22:39 |
| dooooomi | mok0: yup, revu has the latest version | 22:39 |
| * mok0 looks | 22:40 | |
| mok0 | dooooomi: Looks good. +1 | 22:41 |
| mok0 | dooooomi: I'll take a look at gklick tomorrow. Ping me if I forget :-) | 22:42 |
| persia | POX: Getting more people from this channel to upload directly to Debian isn't "stealing developers", it's "collaboration" :) | 22:43 |
| dooooomi | mok0: ok, thanks :) | 22:43 |
| mok0 | I haven't tracked the multimedia situation lately... Is jack supported now? | 22:45 |
| mok0 | It seems a lot of the nice tools use it | 22:45 |
| asbin | Hi is it too late to have packages included in lucid ? I though the feature freeze is on february 18th, right ? | 22:45 |
| persia | mok0: jack is certainly supported, but it's in universe, so nothing in main links against it. | 22:45 |
| persia | asbin: That's right. | 22:46 |
| mok0 | I see | 22:46 |
| mok0 | persia: of course, nothings in universe soon | 22:46 |
| asbin | persia: right, but reviewing package takes time too ... | 22:46 |
| persia | mok0: Once that happens, jack will be in a package set. | 22:46 |
| mok0 | persia: ... Ubuntu Studio? | 22:47 |
| persia | It's in the ubuntustudio set now, and there is an open MIR. I'm not sure it will end up in some other set anytime soon. | 22:47 |
| persia | Yes :) | 22:47 |
| persia | But I think the only things that *could* use it that don't are gstreamer, vlc, and pulse. I may be mistaken though. | 22:48 |
| mok0 | My son is becoming interested in Linux. He wants to use ardour | 22:49 |
| mok0 | Perhaps I should recommend him to install Ubuntu Studio | 22:50 |
| persia | If he already has an Ubuntu install, no reason to reinstall: just install ardour. I tend to like ubuntustudio-audio-plugins as well. | 22:52 |
| asbin | I'm trying to have my packages (libnfo, libplayer, and libvalhalla) reviewed before they go automatically with the Debian Import, to fiw some packages issues right now ... what do you think about it ? | 22:53 |
| persia | ubuntustudio-audio has a selection of more apps than just ardour, if that's useful. ubuntustudio-graphics and ubuntustudio-video may be less interesting collections of software. | 22:53 |
| mok0 | persia: he doesn't, not yet | 22:53 |
| persia | Ubuntustudio-desktop is an interesting alternative, but that comes down to a matter of preference, mostly. | 22:53 |
| persia | Well then, Yes, installing Ubuntu Studio is the way to start :) | 22:53 |
| mok0 | Great, I'll tell him. :-) | 22:54 |
| lfaraone | POX: done, see http://mentors.debian.net/debian/pool/main/p/python-xdgapp/python-xdgapp_1.1-1.dsc | 23:14 |
| === RoAk is now known as RoAkSoAx | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!