| nad_ | i need help getting ati propriatary drivers to work on an ubuntu 9.10 desktop | 00:39 |
|---|---|---|
| persia | nad_: You want to ask in #ubuntu for that | 00:40 |
| RAOF | Then you want #ubuntu or ubuntuforums.org, most likely. | 00:40 |
| hakaishi | Hi everyone! Anyone up to advocate qt-shutdown-p? - It is a Qt program to shutdown the system at a certain time or after x minutes. It uses qdbus to send a shutdown request to the Gnome- and KDE-SessionManager or to HAL (as a last resort 'sudo shutdown -P now' will be used). http://revu.ubuntuwire.com/p/qt-shutdown-p | 01:08 |
| zooko | Greetings, folks! | 03:21 |
| ddecator | hey zooko | 03:21 |
| suji11 | hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me? | 03:27 |
| rhpot1991 | anyone have some time for a revu? | 03:27 |
| EzraR | persia: any chance you will get some time to take a second look at mangler sometime? :) | 04:03 |
| suji11 | hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me? | 04:32 |
| juan__ | hi | 04:40 |
| juan__ | !foo | 04:40 |
| ubottu | bar | 04:40 |
| juan__ | test | 04:40 |
| RAOF | suji11: You mean, the “native package” comment? | 04:41 |
| suji11 | RAOF: yes | 04:41 |
| juan__ | hi im reading https://wiki.ubuntu.com/PackagingGuide/Basic but seems it only explain how to package/build on packages that already are on ubuntu repo,I.E. it uses apt-get source,i want a guide for packages that are not on ubuntu repo,any link??? | 04:43 |
| RAOF | suji11: Normally, you get the code from the upstream developers in a .tar.gz file. The debian/ directory is then added as a patch (the .diff.gz). | 04:46 |
| suji11 | RAOF: oh! | 04:46 |
| RAOF | suji11: You've got what is called a “native package” - the code and the packaging are both in the .tar.gz. This is wrong, because it makes it harder to update the packaging. | 04:46 |
| suji11 | RAOF: ok, what i should i do now? | 04:47 |
| juan__ | im in the right place or i need to join #ubuntu ? | 04:48 |
| RAOF | suji11: Generally, what this means you need to do is to copy the upstream code tarball - which is likely to be “iok-1.3.9.tar.gz” - to iok_1.3.9.orig.tar.gz, and put it in the directory above your unpacked source (the directory containing the debian/ directory). | 04:51 |
| RAOF | Then debuild should pick up the original tarball, and do the right thing. | 04:51 |
| arand | suji11: Upstream in this case means "original author": asking if you are the creator of the program. Secondly about the debian directory. The .tar.gz archive that comes with the package should (aside from in very special circumstances) be _unmodified_. In this case the original source archive (.tar.gz) should be simply the same as the archeve at https://fedorahosted.org/releases/i/o/iok/iok-1.3.9.tar.gz, all the changes to make it into an ubun | 04:54 |
| suji11 | RAOF: i think before i made a mistake. i named the orig tarball as iok_1.3.9_orig.tar.gz , but now i changed it as iok_1.3.9.orig.tar.gz then build it again and sent to revu.ubuntuwire.com | 04:54 |
| arand | suji11: ^ In response to your question in #-devel | 04:55 |
| suji11 | arand: i'm not an upstream author. | 05:00 |
| suji11 | arand: what should i change in iok-1.3.9.tar.gz.? | 05:01 |
| RAOF | suji11: Nothing. It should be exactly the same file you got from fedorahosted. | 05:04 |
| suji11 | RAOF: ok. now the problem is fixed. i'm right? | 05:06 |
| zooko | http://twitter.com/zooko/status/8884301983 | 05:07 |
| zooko | ^-- "Tahoe-LAFS v1.6 has been accepted into Ubuntu 10.04 Long-Term-Support "Lucid"! http://allmydata.org/trac/tahoe-lafs" | 05:07 |
| RAOF | suji11: Yup, that looks right. | 05:08 |
| suji11 | RAOF: ok:) | 05:08 |
| zooko | Okay, time for sleep. | 05:09 |
| suji11 | RAOF: Can you review/advocate my package. | 05:11 |
| RAOF | suji11: Sorry, no. I'm busy. | 05:18 |
| suji11 | RAOF: It's ok. Thanks for your help yet. | 05:19 |
| suji11 | arand: Can you review/advocate my package. | 05:41 |
| arand | suji11: I'm afraid not, since I'm not a reviewer, or even part of ubuntu MOTU, one thing to note, is that this time of the day seems to be very much an off-hours time for all ubuntu channels, you might have better luck at some other time . | 05:44 |
| suji11 | arand: ok fine. | 05:45 |
| suji11 | arand: Thanks for your help. | 05:45 |
| fabrice_sp | is it good or bad practice to change version from 0.<date> (for example 0.20090101) to directly date (that is 20090101) if upstream version is the date? | 06:13 |
| RAOF | Is the upstream version ever going to be something that's not the date? | 06:16 |
| crimsun | if you can future-proof versioning, it's a good idea to do so. I would leave the "0." there. | 06:19 |
| crimsun | then again, there's an epoch, so it really isn't that big a deal. | 06:20 |
| fabrice_sp | this is the versioning scheme of upstream since 3 years, so I suppose it's a kind of 'stable'. Just for keeping it simple and thanks to epoch, I think I'll sponsor the debdiff with this version (without 0.) | 06:34 |
| fabrice_sp | thanks RAOF and crimsun ! | 06:34 |
| crimsun | np | 06:41 |
| === ttx_ is now known as ttx | ||
| kamalmostafa | james_w and/or other motu's: 'squid' is not up to date in "bzr branch lp:ubuntu/squid". It is actually two revisions stale, which caused the person who checked in the latest revision to accidentally trash the one previous to that, causing bug 519664. | 07:13 |
| ubottu | Launchpad bug 519664 in squid "squid FTBFS: dh_installinit: command not found" [Undecided,Confirmed] https://launchpad.net/bugs/519664 | 07:13 |
| persia | kamalmostafa: technically, squid isn't in the set of stuff we can upload, so this isn't the right channel (although you've highlighted the right person to investigate I think). If you can untangle it, I suspect a bug subscribed to ubuntu-main-sponsors would be appreciated. | 07:37 |
| kamalmostafa | persia: Okay, its already untangled (I've attached the simple debdiff to re-apply the missing fix to that bug). I will subscribe u-m-s. Thanks for the redirection. | 07:39 |
| kamalmostafa | persia: and maybe you could unsubscribe u-u-s for me? | 07:40 |
| persia | kamalmostafa: Sure. Running rmadison can help you determine the component for any package. | 07:43 |
| kamalmostafa | persia: I knew it was in main -- just got distracted when I realized i should notify james_w and did my usual "u-u-s" procedure without paying attention. Thanks for the rmadison tip anyway. | 07:45 |
| Speedy1 | www.search2.net | 08:48 |
| persia | Um, please stop posting that in various places. | 08:48 |
| tolonuga | is there any way to get a totaly broken package in ubuntu fixed before release/freeze/etc? I have a complete patch and several independend test results of it, so you only need to get the tar.gz and diff.gz, create an changelog entry, push it out and it would be done. | 09:37 |
| tolonuga | package name:openct. fixed package here: www.opensc-project.org/debian/ (upstream website). | 09:38 |
| tolonuga | import from debian wont' work - debian didn't fix the package either (still using "hal" setup - which won't work on ubuntu, as hal was dropped) | 09:38 |
| tolonuga | anyone? | 09:38 |
| persia | tolonuga: File a bug against the openct package in Ubuntu, describing the issue (or find one if it is already filed). Attach the patch. | 09:44 |
| persia | If you want to wear an Ubuntu Developer hat, which might make it happen faster, add the patch and changelog entry, etc., build a new source package, and attach the debdiff. The revision for the new entry should be -1ubuntu1. | 09:45 |
| persia | Subscribe the bug with the debdiff to ubuntu-universe-sponsors. If you have questions during the process, ask here. | 09:45 |
| om26er | is there a manual way of making a binary package(not using pbuilder) | 10:00 |
| sistpoty|work | make -f debian/rules binary | 10:01 |
| om26er | sistpoty|work, thanks will try | 10:01 |
| tolonuga | sorry, keyb broken, had to reboot. | 10:05 |
| tolonuga | persia:thanks for the help! | 10:05 |
| tolonuga | done - added my diff.gz, or an interdiff if that is preferered, and added ubuntu-universe-sponsor to cc: | 10:05 |
| persia | The orig.tar.gz differs? | 10:06 |
| tolonuga | no, only the diff.gz | 10:08 |
| tolonuga | well, new version of orig.tar.gz (version 0.6.17 -> 0.6.19) | 10:08 |
| tolonuga | keep "unstable" in debian/changelog or replace it with "lucid"? (with "lucid" I get an error/warning form debuild -S...) | 10:10 |
| slytherin | tolonuga: lucid is correct | 10:11 |
| tolonuga | hmm, how does an debdiff file help? in it I see all the upstream changes 0.6.17 to 0.6.19 - guess that isn't much help. | 10:13 |
| tolonuga | ok, everything implemented as suggested. can anyone look at bug 519713 and push the fixes into ubuntu? | 10:17 |
| ubottu | Launchpad bug 519713 in openct "package outdated" [Undecided,New] https://launchpad.net/bugs/519713 | 10:17 |
| tolonuga | hmm, a better title would be "package outdated and totaly broken" ... | 10:19 |
| slytherin | tolonuga: When working on new upstream version .diff.gz needs to be attached. But if you are working on a new Ubuntu revision then .debdiff is preferred. | 10:20 |
| tolonuga | ok. the diff.gz is the first attachment, so that is already there. it has "-0" in it, but you can easily change that and push it out? | 10:21 |
| tolonuga | also I'm looking for someone to import latest opensc package from debian into ubuntu. the ubuntu changes to the older package can be dropped (a fix that is included in the new upstream and thus no longer needed). can anyone do that too? | 10:21 |
| slytherin | tolonuga: for requesting syncs, the easiest method is to use requestsync tool. It fetches the changelog entries and you can provide reason to drop ubuntu changes. | 10:23 |
| tolonuga | ok,will have a look | 10:24 |
| === ogra_ is now known as ogra | ||
| tolonuga | ok, sync request send with that tool. | 10:39 |
| om26er | where are the .deb file created | 10:42 |
| tolonuga | hmm. is that a regression? an important bug has been fixed in opensc 0.11.8-1ubuntu2 in karmic, but the lucid package 0.11.9-2ubuntu1 does not contain the fix. | 10:43 |
| tolonuga | if unchanged, lucid would be a regression compared karmic with fix. | 10:43 |
| persia | That would be a regression. If the patch isn't in Debian already, go catch your sync bug before it gets ACKed, and change it to a merge bug. | 10:44 |
| persia | For merges, we prefer a debdiff against the revision in Debian (as we'd use the Debian orig.tar.gz) | 10:45 |
| tolonuga | debian testing has the new version and thus can be imported without any change - the ubuntu fix was a backport from the official 0.11.12 which fixed the issue. | 10:45 |
| persia | So a sync would make it not a regression, and the other stuff added to 11.9-2 is also in 11.12? | 10:47 |
| sistpoty|work | om26er: one directory above | 10:47 |
| tolonuga | yes, the sync will remove the regression and fix other things and add the latest features from 0.11.12. a win for everyone! | 10:51 |
| persia | Cool. | 10:53 |
| AnAnt | Hello, when's the next sync ? | 10:58 |
| persia | whenever the archive-admin-of-the-day happens to run the autosync script. | 10:58 |
| AnAnt | persia: how frequent is that ? | 10:59 |
| persia | Depends on the day. Sometimes once a day, sometimes twice, sometimes not at all. | 11:01 |
| AnAnt | well, swt-gtk has entered testing few days ago, yet it isn't in lucid yet | 11:01 |
| AnAnt | swt-gtk 3.5 that is | 11:02 |
| persia | Maybe it's stuck in the NEW queue. Have you checked that? | 11:02 |
| persia | No, that's not it. Just a matter of not having a sync run. | 11:03 |
| persia | Well, there should be a sync run that happens before DIF, so I wouldn't worry. | 11:03 |
| persia | If it still isn't present by Friday, file a bug. | 11:03 |
| AnAnt | DIF is on friday ? | 11:04 |
| persia | No, DIF is on Thursday, but there are archive admins all over the world, so to avoid getting into an argument about which day of the week is the right day, best to leave some slack. | 11:04 |
| AnAnt | persia: ok, regarding LP #511069, should I set this to confirmed again , since swt-gtk 3.5 should get sync'ed ? | 11:06 |
| ubottu | Launchpad bug 511069 in zekr "Sync zekr 0.7.5~beta3+repack-1 (multiverse) from Debian unstable (non-free)" [Wishlist,In progress] https://launchpad.net/bugs/511069 | 11:06 |
| persia | AnAnt: Wait until it's actually present. | 11:07 |
| persia | DIF doesn't mean we can't sync, it only means that it won't happen automatically. | 11:08 |
| AnAnt | ok | 11:08 |
| geser | isn't FF already next week? | 11:14 |
| persia | Yes. The 18th. | 11:16 |
| persia | I have a deep suspicion that after the demand over the next week, the archive-admins will never again agree to such a close relation between DIF and FF. | 11:16 |
| * Laney is going to be going sync crazy with the new GHC transition :) | 11:18 | |
| Laney | (if it is oked) | 11:19 |
| persia | Laney: Why do you need OK, will it not start until after DIF? | 11:19 |
| persia | Otherwise I'd expect something to slip in, so that we didn't have a choice. | 11:19 |
| Laney | it won't, and it will bleed over into FF | 11:20 |
| persia | Oh, lovely. | 11:20 |
| AnAnt | Laney: is that haskell ? | 11:20 |
| Laney | yes | 11:20 |
| AnAnt | I tried to prepare a haskell package once, and failed | 11:20 |
| Laney | you should come to #debian-haskell | 11:21 |
| AnAnt | too many dependancies, flavors | 11:21 |
| AnAnt | Laney: I did | 11:21 |
| AnAnt | Laney: and they removed debhelper support | 11:21 |
| AnAnt | that was sad | 11:21 |
| Laney | right, cdbs is the normal way | 11:21 |
| Laney | just copy an existing library | 11:21 |
| Rhonda | persia: When is the final sync freeze? I think I need to request another one for ejabberd, fixing a CVE. | 11:23 |
| Laney | bug fix uploads are almost always OK | 11:23 |
| Laney | up to final freeze, then they need to be serious and minimal (security will still be alright) | 11:24 |
| Rhonda | Laney: … "up to the final freeze" which is when? :) | 11:26 |
| Laney | errrrrrr | 11:26 |
| Laney | https://wiki.ubuntu.com/LucidReleaseSchedule <- april 15th | 11:26 |
| Rhonda | Alright, I look it up myself | 11:26 |
| Laney | (maybe later for universe) | 11:27 |
| Rhonda | Thought you'd know it out of the head, sorry for making you hunt for it. | 11:27 |
| Laney | it's alright, the release schedule is in my history | 11:27 |
| slytherin | Laney: Did you see the build log I sent yesterday | 11:29 |
| Laney | slytherin: yes, thank you. Unfortunately the interesting part was just after that step :) | 11:30 |
| Laney | but no worries, somebody else tried it on a ppc porterbox for me | 11:31 |
| slytherin | great | 11:32 |
| geser | slytherin: do you know if could/should sync jabref? from a quick look at the changelog it looks like the ubuntu delta got included in the debian package (in unstable) | 11:36 |
| geser | but as the version string contains beta I'm not sure if we should sync or not (a sync would also allow to move it into universe) | 11:37 |
| slytherin | geser: I am not very keen on syncing beta version. | 11:37 |
| geser | ok, so we keep then 2.5 | 11:38 |
| \sh | dholbach: when do you update http://qa.ubuntu.com/reports/sponsoring/ ? every hour or once a day? | 12:00 |
| dholbach | \sh: every 15 minutes | 12:01 |
| \sh | dholbach: cool. thx :) | 12:01 |
| dholbach | once the list is smaller again I can update it more often ;-) | 12:01 |
| \sh | dholbach: working on it ;) | 12:02 |
| dholbach | ROCK! | 12:02 |
| filip | hi, I have a problem with debconf (db_subst). This setup: http://pastebin.com/mb1f7802 doesn't work (suggested value is "${default}") | 12:10 |
| filip | it seems to be done according to the debconf manual... | 12:10 |
| slytherin | dholbach: Did you get my message in #ubuntu-kernel? My IRC client is giving weird error. | 12:42 |
| slytherin | never mind found the problem | 12:43 |
| dholbach | slytherin: nope, didn't get it | 12:44 |
| slytherin | my nick was not identified. :-) | 12:44 |
| \sh | dholbach: could you sponsor bug #506908 for torsten spindler? (provided an updated debdiff, so it follows our standards) (it's main, as it was wrongly added to universe sponsor queue it seems) | 12:48 |
| ubottu | Launchpad bug 506908 in pcsc-lite "Upstart job for pcscd" [Undecided,In progress] https://launchpad.net/bugs/506908 | 12:48 |
| dholbach | \sh: I'd prefer if somebody would sponsor it who has actually looked at an upstart job before because I haven't :) | 12:49 |
| \sh | dholbach: for me the upstart job looks very much ok and very clean :) but I'm not keybuk ;) | 12:50 |
| \sh | anyways subscribe main sponsors | 12:50 |
| \sh | +d | 12:50 |
| dholbach | thanks \sh | 12:51 |
| \sh | dholbach: your expertise, should we fix those debdiffs, or just unsubscribe sponsors and waiting for bugfixer coming back with a correct debdiff ? (bug #368017) | 12:53 |
| ubottu | Launchpad bug 368017 in fet "Wrong description" [Wishlist,Confirmed] https://launchpad.net/bugs/368017 | 12:53 |
| dholbach | \sh: I'd prefer if we would just add the changelog entry, upload and be done with it - extra points for a small message saying "this is how I produced a debdiff" | 12:54 |
| * persia would prefer that the sponsors queue wasn't so strongly recommended to all and sundry arbitrary patch authors, and that we had a better way to catch patches. | 12:55 | |
| dholbach | ? | 12:55 |
| dholbach | why less recommended? | 12:55 |
| persia | Because I don't think there should be any expectation of any relation between people who submit patches to launchpad and people who care about uploading to Ubuntu. | 12:56 |
| dholbach | what does that mean? | 12:56 |
| persia | The "right way" to get something into Ubuntu shouldn't have to involve making a debdiff, although I think the "right way" for someone to do sponsored uploads to Ubnutu should. | 12:56 |
| dholbach | if we would put more work into getting all the bugs with patches closed, we wouldn't need the sponsoring process | 12:56 |
| persia | I disagree vehemently with that statement. | 12:57 |
| persia | To me, the sponsoring process is a way that those who wish to become Ubuntu Developers can demonstrate their skills before being granted upload access. | 12:57 |
| dholbach | I don't think it really matters | 12:57 |
| dholbach | we should be better at spotting fixes and making Ubuntu better | 12:58 |
| persia | I see no relation between this and any activities related to processing patches that fix bugs, except insofar as I expect Ubuntu Developers (both current and prospective) to look for patches and get them uploaded. | 12:58 |
| dholbach | if somebody wishes to apply, they're happy to do that | 12:58 |
| dholbach | and I encourage them | 12:58 |
| \sh | I do understand persia... | 12:58 |
| persia | \sh: Thanks. Sometimes it seems that nobody bothers to think about what I write :) | 12:59 |
| dholbach | it's a distinction which doesn't make the world exactly easier - the bigger problem we have is that there's not enough people willing to get the 2000 bugs with patches reviewed | 12:59 |
| \sh | the problem with debdiffs from "non wanna ubuntu devs" is that they are on the merger list for the next cycle and nobody will take care until DIF and sometimes it's too late | 12:59 |
| persia | \sh: There's that. There's also that patch submitters get annoyed with the frustrating processes and complain about us. | 13:00 |
| dholbach | ... and I didn't disagree with that | 13:00 |
| * persia doesn't want to bother spending effort training anyone to follow Ubuntu processes unless they have an interest in being part of Ubuntu, rather than just submitting bugfix patches | 13:00 | |
| dholbach | persia: and I didn't say you should | 13:00 |
| persia | dholbach: No, but my argument is that conflating "sponsoring" with "patch review" implicitly makes it awkward to distinguish between the two classes of patches. | 13:01 |
| persia | So I'd much rather see random folk told "attach a patch in a bug in LP", and have developers (both current and prospective) hounded to get those patches in. | 13:02 |
| dholbach | right, it's just that the distinction between to me is much less important than getting the 2000 bugs with patches closed or tended to :) | 13:02 |
| persia | And I think that's separate from supporting people who can do the work but just can't upload yet. | 13:02 |
| dholbach | in both cases it's stuff we want to get into the distro to make it better | 13:03 |
| persia | dholbach: I understand. I even agree that it's less important. I'd just prefer that there was more focus on looking for the patches, and less focus on telling people to use the sponsoring process. | 13:03 |
| dholbach | ok, good - I probably should have said "in an ideal world we wouldn't have 2000 bugs with patches to tend to and wouldn't have to have a process which makes getting patches looked at more complicated than it should be" | 13:04 |
| dholbach | in the meantime, until we can tell patch submitters apart from each other (willing to learn more about ubuntu development or not), I'd suggest attaching your debdiff to the bug, so they can take a look at it, but not block on "attaching a debdiff" | 13:05 |
| persia | That's close to my view, but if you don't consider the sponsoring process to me the process for getting patches looked at, then you don't have that issue. | 13:05 |
| persia | So, I7d rather say that the sponsoring process is *only* for prospective and current Ubuntu developers, and have the patch submisison process be as simple as ticking a checkmark on LP. | 13:06 |
| persia | If you want to get more people looking at these 2000 patches, have them look there, rather than fussing with the sponsorship process in a way that makes it harder to train new developers. | 13:07 |
| dholbach | we don't even cope well with the n+1 sponsoring items we have | 13:08 |
| persia | Sure, but tossing those into the mass of unlooked-at patches only makes it worse, in my opinion. | 13:09 |
| persia | If the sponsoring queue only contained stuff that was written by people who are now, or are seeking to be Ubuntu Developers, the quality should rise, and that should make it less annoying to sponsor stuff. | 13:09 |
| dholbach | I wasn't saying "let's get rid of the sponsoring queue" | 13:10 |
| dholbach | ... now | 13:10 |
| persia | That said, we *do* need an active team to be chasing the 2000 patches, but I don't think any of them should be subscribed to the sponsors queue: that just complicates the process for submitters and frustrates sponsors. | 13:10 |
| dholbach | Realistically, the sponsoring queue is where 90-95% of patches/branches from LP come from. | 13:12 |
| persia | I don't think so. Only about 10% of patches are currently shown on your list. | 13:12 |
| persia | But even were that true, I'd argue that we should be focusing on making that not true, rather than trying to push more patches through that mechanism. | 13:13 |
| dholbach | sorry, I was unclear | 13:13 |
| dholbach | I meant to say that 90-95% of the branches/patches form LP that go into Ubuntu come through the sponsorship process | 13:14 |
| persia | Right. My argument is that this represents a failure of Ubuntu Developers to dig up patches properly. | 13:14 |
| dholbach | yes, I'd very much like to see a solution to that problem | 13:14 |
| persia | I'd much rather see strong focus on getting more developers to be proactively searching for patches than to push more patches into the sponsorship queues. | 13:15 |
| dholbach | Do something! | 13:15 |
| persia | Because lots of developers don't need to get sponsored, and so it is wasteful to push it in the queue. | 13:15 |
| dholbach | eh? | 13:15 |
| persia | So, if we say that the process for getting a patch reviewed is to stick it in the sponsors queue we 1) make the process complicated and 2) don't tell developers to go hunt patches. | 13:16 |
| persia | If we say that the process for getting a patch reviewed is to attach it to a bug in launchpad, we 1) make the process easy, and 2) are in a stronger position to tell developers to go hunt patches. | 13:17 |
| dholbach | were you in the fixing-bugs-with-patches session at uds? | 13:17 |
| persia | If some developer fixes something and can't upload, we can fall back to the sponsors queue. | 13:17 |
| persia | I've tried to attend that session for the past 4 UDSs. | 13:17 |
| persia | I don't know if I was in the one you mean now. | 13:17 |
| dholbach | that blueprint is the best place to discuss this :) | 13:18 |
| persia | What7s the URL? | 13:18 |
| \sh | last uds was usa now this time of the year is back in europe ? | 13:18 |
| persia | \sh: Probably. It seems to mostly swap between those two and never come here :) | 13:18 |
| dholbach | https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-qa-fixing-bugs-with-patches | 13:19 |
| dholbach | and I think you were | 13:19 |
| dholbach | but anyway, I need to head out now | 13:19 |
| dholbach | see you later | 13:19 |
| persia | dholbach: I agree with just about everything on that blueprint except that I don't think it's related to sponsoring :) | 13:21 |
| oojah | As an outsider looking in, from what I've read I'd expect the sponsorship queue to be for people that don't have upload rights to a particular component, mostly likely because they're a prospective developer but also possibly because they want to fix something in main and only have universe rights. | 13:24 |
| persia | oojah: It's also important for people working on the edges of package-sets. | 13:26 |
| Daviey | oojah: yes, but also enables better peer review. | 13:26 |
| persia | Daviey: Well, except we've historically rejected submissions by those who could upload :) | 13:27 |
| Daviey | :) | 13:27 |
| persia | For peer review, we tend to just ask in IRC for someone to look at a debdiff or something. | 13:27 |
| Daviey | which is less than ideal IMHO | 13:27 |
| persia | Daviey: Well, I think the idea was that peer-review happened post-upload :) | 13:28 |
| Daviey | which is much much less than ideal :) | 13:29 |
| persia | We can generally fix each other's mistakes, and sometimes changelogs end up looking interesting (ubuntu-dev-tools for the security/deprecated schroot.conf lines, or the old nvidia-settings package were two cases I was involved with) | 13:29 |
| persia | I guess, but with the package:developer ratio being as high as it is, it tends to be faster (as most of us ask if we need and don't make too many mistakes otherwise) | 13:30 |
| oojah | Right, ok on both counts. | 13:30 |
| _stink_ | hey folks. i have an upstream package that has its source split into directories named client/, server/, utils/, etc. I want my rules files to only build what's in client/. Manually I can cd client/; make and it works fine, but it seems that no matter what i try in the rules file, it *always* tries to make everything. any idea how I build only one subdirectory in a source package? | 13:53 |
| sistpoty|work | _stink_: "make -C client" instead of calling "make" in rules? | 13:55 |
| _stink_ | ahhh yes. -C. duh me | 13:55 |
| _stink_ | sistpoty|work: thanks! | 13:55 |
| sistpoty|work | yw | 13:55 |
| persia | Using dh(1), one can also pass --sourcedir client to dh to acheive a similar result. | 13:58 |
| abogani | Hi All, I have a simple question for you. I'm working on packaging of new software which depend from avr-libc. Meanwhile I'm working on my stuff I have noticed that avr-libx seems don't be FHS compliant. Is it possible? | 14:06 |
| abogani | Could header files be placed into /usr/lib/avr/include ? | 14:08 |
| abogani | Don't should be /usr/include/avr a better place? ? | 14:08 |
| persia | Changing stuff to be FHS compliant is always good. That said, one has to look at all the rdepends to make sure they won't break (and reverse-build-depends for libraries). | 14:11 |
| persia | This often ends up being a fairly sizable transition, and is often best coordinated also with any Debian maintainers and upstream. | 14:11 |
| kmdm | Don't suppose anyone has the command to hand to sign a .changes file? (Mind's gone blank on me :( .) | 14:24 |
| jpds | kmdm: debsign? | 14:25 |
| kmdm | jpds: Perfect, thanks ;) | 14:26 |
| bjsnider | siretart, ping | 14:29 |
| siretart | yes? | 14:40 |
| siretart | please avoid contentless pings. I don't like them | 14:40 |
| bjsnider | siretart, is ffmpeg fixed upstream? when i refreshed it and installed the packages, it broke everything | 14:41 |
| bjsnider | i'm sure it was from the master branch | 14:41 |
| siretart | please be more specific. what breaks exactly? | 14:41 |
| bjsnider | mplayer complains about not being able to find libavutil shared libs, and the gstreamer ffmpeg package loses track of the codecs it needs | 14:42 |
| siretart | mplayer: really libavutil and not libswscale? pastebin please. | 14:43 |
| siretart | gstreamer: no idea, please ping slomo and/or bilboed | 14:44 |
| bjsnider | alright, hold on aminute i'll have to reinstall the stuff | 14:44 |
| bjsnider | mplayer: error while loading shared libraries: libavutil.so.49: cannot open shared object... | 14:46 |
| === dholbach_ is now known as dholbach | ||
| siretart | mplayer depends on libavutil49 which provides that lib. if you removed it, then your packages and/or system are broken | 14:47 |
| bjsnider | libavutil-extra-49 is installed here | 14:47 |
| siretart | then check why mplayer fails to find libavutil.so.49 | 14:48 |
| bjsnider | well, the library version is no lnger 49, it's named 50 | 14:50 |
| bjsnider | do i have to rebuild everything that might possibly use ffmpeg for this to realistically work? | 14:50 |
| bjsnider | i planned on refreshing mplayer, but not necessarily much else | 14:50 |
| siretart | if you are using the mplayer package from lucid, then it depends on libavutil49 and that must be installed | 14:50 |
| siretart | depends declares a hard dependency. period | 14:51 |
| bjsnider | this should actually be renamed to libavutil50. i can't have my cake and eat it too where both 49 and 50 are there at the same time can i? | 14:52 |
| siretart | the point of the excercise of soname handling is that you can have both libavutil49 and libavutil50 installed at the same time | 14:52 |
| persia | It's much preferred not to provide eaten cake, as this requires significantly more maintenance overhead. | 14:52 |
| sistpoty|work | persia: shared libraries must be made to coexist, otherwise bad things happen. | 14:53 |
| bjsnider | then if i renamed all of my ffmpeg packages, so they didn't upgrade over the karmic ones, this would work | 14:53 |
| sistpoty|work | persia: just assume libc7 would conflict with libc6 ;) | 14:53 |
| persia | sistpoty|work: I agree that foo.so.1 and foo.so.2 should be in the libfoo1 and libfoo2 packages, but I'd prefer to just have libfoo-dev, and tell everyone to rebuild the world :) | 14:54 |
| siretart | you'd still have to change the SONAME of all libs (which is nontrivial) and change shlibs file to match that change (trivial) | 14:54 |
| bjsnider | siretart, how do you mean change the SONAME? | 14:54 |
| siretart | persia: that's what happening with ffmpeg, BTW. | 14:54 |
| persia | siretart: Right. My comment about eaten cake was an argument against providing libavutil49-dev and libavutil50-dev, but apparently insufficiently clear. | 14:56 |
| siretart | bjsnider: sorry, please read up on that yourself. Try levine's book Linkers and Loaders, chapter 10. I'm currently at work | 14:56 |
| siretart | persia: agreed | 14:56 |
| === RoAk is now known as RoAkSoAx | ||
| bjsnider | oh, i see what you mean by soname. but that's already changed int he -49 packages. they've already been bumped to 50 | 15:03 |
| bjsnider | siretart, thanks for the help. sorry for being a pest. | 15:05 |
| siretart | bjsnider: sorry for being so rude, I'm as said at work and your question are quite confusing to me TBH | 15:05 |
| bjsnider | i have to invent my own terminology because i don't have a programming background | 15:11 |
| persia | bjsnider: The encouraged alternative is to ask lots of stupid questions in appropriate fora until you are using the same terminology :) | 15:12 |
| persia | Err, s/stupid/potentially apparently stupid/ | 15:12 |
| bjsnider | persia, yes, that's exactly it... | 15:13 |
| bjsnider | what i don't understand is, if a package is looking for a shared lib version 49 for instance, but version 50 is there instead, why doesn't it pick that up and talk to version 50? | 15:14 |
| persia | bjsnider: You might find running nm against your binaries to be instructive, or review any of the MOTU/School library packaging sessions documented on the wiki. | 15:18 |
| === asac_ is now known as asac | ||
| geser | bjsnider: from where should the app know how to talk to version 50 if it only knows how to talk to version 49? | 15:33 |
| persia | Might be clearer if we remember that the differences here aren't just arbitrary versions, but rather represent differing ABIs | 15:34 |
| bjsnider | persia, but would the abi be so different that breakage would result? | 15:36 |
| bjsnider | geser, why does it only know to talk to -49? why can't it look for any version to talk to? | 15:37 |
| geser | bjsnider: imagine the app provides a 32bit int and the lib expects a 64bit one at that location | 15:37 |
| bjsnider | or is it that th abi is so different that it wouldn't matter | 15:37 |
| geser | bjsnider: from the headers for the lib it was compiled with | 15:37 |
| geser | bjsnider: the difference might be small or big depending on what exactly has changed | 15:38 |
| persia | bjsnider: The ABI breakage is sufficient that applications compiled against the old version will experience some problems. The nature of these problems depends on the nature of the change. | 15:39 |
| persia | There are many ways to change ABI without changing SONAME, but when SONAME changes, there's usually no going back. | 15:39 |
| kreuter | howdy, #ubuntu-motu. does upstart support running daemons under uid/gid other than root? | 16:40 |
| persia | kreuter: I *think* so, but it might require trickery. | 16:42 |
| persia | You might ask in #ubuntu-server: they tend to try to put stuff in chroot jails *and* use upstart. | 16:42 |
| kreuter | hm. okay. thanks! | 16:44 |
| rmunn | Can I get a MOTU to look at http://revu.ubuntuwire.com/p/python-nltk? I believe it's ready to go into Lucid now, it just needs advocates. | 16:45 |
| persia | rmunn: DEP5 calls for a separated License: stanza when using the same license in multiple Files: stanzas (PSF-2) | 16:47 |
| persia | And I've not seen debian/clean before. Nifty :) | 16:47 |
| rmunn | persia, What do you mean by a separated License: stanza? I don't quite follow. | 16:50 |
| persia | http://dep.debian.net/deps/dep5/ : see the bit about "Standalone License Section" | 16:51 |
| rmunn | persia, I wanted to do "Files: nltk/a.py, nltk/b.py, nltk/c.py \n License: PSF-2" but didn't read the spec as allowing that. | 16:51 |
| \sh | hmm..well...the universe taggeed sponsor queue looks more empty now regarding dholbachs new page | 16:52 |
| rmunn | persia, Ah, I understand now. So basically, I just need to add a single newline and a new "License: PSF-2" line that's standalone. | 16:52 |
| persia | rmunn: I think you can do that, for the same license and copyright, etc. | 16:52 |
| persia | e.g. Files: "Program Files/*", manual[english].txt | 16:52 |
| rmunn | persia, Should I do that now and re-upload, or wait until you're done looking at the rest of the revu entry so there's only a single new upload? | 16:53 |
| persia | But I don't think you can do it for this source, because the Copyright lists differ | 16:53 |
| rmunn | persia, Ah yes, that was the problem -- different copyrights. | 16:53 |
| persia | Oh, just reupload it. I don't see anything else obvious, except that I would have used rules.tiny and debhelper 7 | 16:53 |
| rmunn | persia, Been a week since I started working on this, so I'm forgetting some of the details of what I did at first. :-) | 16:54 |
| rmunn | persia, It's my first package, I used CDBS because it seemed easier to get started with than debhelper. Never heard of rules.tiny -- where can I read about it? | 16:54 |
| persia | /usr/share/doc/debhelper/examples/rules.tiny and `man dh`. | 16:55 |
| persia | But actually, you need to patch it, so you'd have to do something like --with-quilt, and then reformat the patches, etc. | 16:55 |
| persia | Just leave it CDBS. | 16:55 |
| \sh | bddebian: ping mush you filed a removal request in debian for this package :) | 16:56 |
| \sh | bddebian: dead upstream, dead maintainer, dead what? | 16:56 |
| sebner | persia: rmunn or you upgrade to debsrc3.0 so you also don't have to worry about patching ;) | 16:57 |
| rmunn | persia, Uploading, should show up on REVU in 5 minutes | 16:57 |
| persia | sebner: Well, kinda. | 16:57 |
| Laney | oh, while I remember, does anyone know of a way to specify arch-indep build rules with DH7? | 16:57 |
| Laney | I don't know of a convenient way to have my docs only built when building the arch:all package | 16:58 |
| persia | Laney: What are you trying to accomplish? | 16:58 |
| rmunn | sebner, Is debsrc3.0 available on Karmic, or should I switch to my Lucid virtual machine for building packages from now on? | 16:58 |
| sebner | rmunn: debsrc3.0 is only available for lucid and newer | 16:58 |
| bddebian | \sh: NPOASR (Never part of a stable release) :) | 16:58 |
| sebner | huhu bddebian := | 16:58 |
| sebner | :) | 16:58 |
| rmunn | So far the only downside I've found to building packages on Karmic is that lintian thinks "lucid" is an invalid Ubuntu version name. | 16:58 |
| Laney | persia: some processing is required to generate html documentation, but it's wasteful to do it everywhere | 16:58 |
| sebner | rmunn: you can upgrade to lucid lintian version | 16:59 |
| persia | Laney: Compare `dh binary-arch --no-act` to `dh binary-indep --no-act` in your source package. The sequences should differ slightly, and this may help you figure out how to make it work. | 16:59 |
| RoAkSoAx | hey guys anyone know if dput to PPA's is broken? | 17:00 |
| persia | RoAkSoAx: Ask in #launchpad | 17:00 |
| RoAkSoAx | persia, will do :) | 17:00 |
| rmunn | persia, New upload is up at http://revu.ubuntuwire.com/p/python-nltk, thanks for the feedback on DEP5 | 17:01 |
| \sh | bddebian: well, the whole package is horse-dung ;) | 17:02 |
| rmunn | lintian still warns me about "build-depends-without-arch-dep python-yaml", but python-yaml is required for the "clean" operation (because setup.py ends up importing something that imports it) so I can't get rid of that warning. | 17:02 |
| Laney | persia: Actually, they differ in that -a is passed for the arch build, and -i for the indep, and that dh_strip, dh_makeshlibs, dh_shlibdeps are not invoked in the indep case | 17:03 |
| Laney | so I don't see anywhere to hook in there :( | 17:03 |
| persia | Laney: Do you have different targets available in the upstream build system? You could do something with override_dh_auto_build: | 17:04 |
| Laney | No, I don't use their buildsys | 17:05 |
| persia | How do you build it? | 17:05 |
| Laney | I just have to run agda on one file | 17:05 |
| persia | Could you point me at your debian/rules? That might make it easier for me to critique it :) | 17:06 |
| bddebian | \sh: Agreed :) | 17:06 |
| Laney | yes, I'm getting to it... git.d.o is being slow | 17:07 |
| Laney | persia: http://git.debian.org/?p=collab-maint/agda-stdlib.git;a=blob;f=debian/rules;h=b23dfc54e31fab28f5087290350b11bb5c556557;hb=HEAD | 17:07 |
| \sh | rmunn: did you try Build-Depends-Indep, you don't build any arch dependend stuff in it...topic 7.7 in http://www.debian.org/doc/debian-policy/ch-relationships.html | 17:09 |
| rmunn | Haven't tried yet, but 7.7 says Build-Depend must be satisfied when clean is invoked. Running clean runs "python setup.py clean", and upstream's setup.py does "import nltk", which in turn does "import yaml" -- so if yaml isn't around, "setup.py clean" fails with an ImportError. | 17:12 |
| \sh | rmunn: or you find a linitan bug... | 17:12 |
| rmunn | So since python-yaml is required for the clean step, I followed policy and put it in Build-Depends. | 17:13 |
| \sh | "The matrix is based on rules, you can't break the rules, but you can bend them" ;) | 17:13 |
| \sh | in the end, you found a lintian bug ;) | 17:13 |
| sistpoty|work | rmunn: iirc build-depends-indep aren't installed on clean, even though policy says otherwise | 17:17 |
| persia | Laney: Sorry. Got distracted. | 17:17 |
| Laney | no worries | 17:18 |
| \sh | sistpoty|work: I think lintian is right, because python-yaml (the module) is not actually seen by linitian but python is...false positive | 17:18 |
| persia | Laney: If you use sbuild, you might try showing the environment variables in override_dh_auto_build with and without -A and see if you can find a useful difference. | 17:19 |
| * persia suspects there's a way to do this with pbuilder, but doesn't know the details. | 17:19 | |
| Laney | I fear that we get into the realm of "more trouble than it's worth" | 17:20 |
| Laney | I could just make a binary-indep target and do my building in there | 17:20 |
| persia | Laney: Fine. I'll get the variable :p | 17:20 |
| Laney | before "dh binary-indep" | 17:20 |
| sistpoty|work | \sh: sounds like it, yeah | 17:21 |
| Laney | persia: Something like this — http://paste.ubuntu.com/373360/ | 17:23 |
| persia | Laney: I'm not convinced that works with dh: man dh | 17:24 |
| persia | Oh, "binary-indep" rather than "build-indep". Right, yes. | 17:24 |
| persia | I'd probably do it with an override_dh_binary_indep: rule that depended on a documentation: rule and called dh_binary_indep internally. | 17:25 |
| * Laney knows not about dh_binary_indep | 17:25 | |
| persia | Err, except that wouldn't work, and I'd end up doing it your way :) | 17:25 |
| Laney | let's fire off a test build | 17:28 |
| maxb | Laney: The most palatable way I've found is to put the conditional in shell: if dh_listpackages | grep -q '^mybinaryindeppkg$$'; then ..... | 17:28 |
| persia | I like manually defining build-indep: better than that. | 17:29 |
| * Laney too | 17:29 | |
| sebner | Laney: I'm wondering about your (old) --before --after stuff too | 17:29 |
| Laney | sebner: how would you do it? | 17:29 |
| Laney | bear in mind that the binary-indep target runs the whole debhelper sequence | 17:30 |
| sebner | Laney: I don't know about that indep stuff but we also had this --before and --after stuff with old debhelper (e.g configure) so I'm wondering if you can just make ist like the new way | 17:30 |
| Laney | I don't know how. And there are bound to be cases where defining the targets is still useful... maybe this is one of them | 17:31 |
| sebner | Laney: I'll give it a try later too | 17:32 |
| \sh | I thought dh7 should make lifes easier ;) | 17:32 |
| Laney | this --before and --after stuff is really just a condensed way of writing out all of the dh_* commands in a pre-dh7 style rules file | 17:32 |
| Laney | \sh: I do think this is easier than the old way really | 17:33 |
| \sh | Laney: depending on your training imho.. | 17:34 |
| Laney | of course, some people don't use debhelper at all :) | 17:34 |
| persia | Grr. echo ${ENV} didn't do what I wanted. | 17:35 |
| \sh | Laney: actually cdbs is also a black hole for me...people should know what the tools are doing so they understand the whole system...without knowing the old school you don't understand the new school ;) | 17:36 |
| Laney | \sh: ha, when using cdbs I end up reading the source more often than not | 17:36 |
| Laney | trading surface simplicity for below-the-surface complexity | 17:37 |
| \sh | Laney: well...beginners don't and even when they do that, they wouldn't understand much ;) | 17:38 |
| rmunn | Well, moving python-yaml into Build-Depends-Indep: instead of Build-Depends: seemed to make no difference as far as pbuilder was concerned... should I re-upload http://revu.ubuntuwire.com/p/python-nltk with a new debian/control even though that seems to be against (my reading of) Debian policy section 7.7? | 17:39 |
| sistpoty|work | for a lesson, I tried to package completely without helpers. funnily I almost got it right on the first try | 17:39 |
| Laney | rmunn: pbuilder always builds arch-indep afaik | 17:40 |
| \sh | sistpoty|work: do you remember ajmitch' lesson when we opened ubuntu-motu-school long time ago? :) | 17:41 |
| persia | Right. The make manual fails me. If anyone has a good command that prints out the entirery of the environment from within make, I'm happy to test to see if there's an arch-indep solution. | 17:41 |
| sistpoty|work | \sh: right, probably I got the idea from him ;) | 17:41 |
| rmunn | This is my first "real" package (as opposed to following along with the exercises during ubuntu-classroom sessions) so I've reached the limit of my knowledge so far. | 17:41 |
| Laney | hmm | 17:42 |
| \sh | rmunn: as said, you hit a false positive..for linitian python-yaml is not existent, but setup.py which is executed during clean needs it ... for linitian only python is a needed build-dep...file a bug on linitian ;) | 17:42 |
| Laney | from reading /usr/bin/dh, I don't think that binary-indep even does any building | 17:42 |
| Laney | so I don't know if --before dh_auto_build will work | 17:42 |
| rmunn | It seems like http://revu.ubuntuwire.com/p/python-nltk is almost ready, and I'd like to get it into Lucid before Feature Freeze -- but I don't know the right answer to this Build-Depends/Build-Depends-Indep problem. | 17:43 |
| Laney | I could just build the docs and then dh $@ | 17:43 |
| slytherin | is there any reason why 'dh_install --fail-missing' wouldn't report error on i386 buildd but reports problem everywhere else. | 17:43 |
| rmunn | \sh, Okay, so no changes needed to debian/control? Great, that means I *might* be finished with repeatedly re-uploading to REVU now... :-) | 17:43 |
| rmunn | Unless another MOTU comes along and points out yet another newbie mistake of mine... :-) | 17:44 |
| Laney | slytherin: something to do with b-d-i? | 17:44 |
| \sh | rmunn: please document this "behaviour" somewhere in revu and file a bug against lintian (debian + ubuntu) | 17:44 |
| \sh | slytherin: arch indep files? which are only build on i386? | 17:45 |
| rmunn | Already mentioned it in one part of one of my REVU comments, but I'll put it in a separate comment so it's easier to see. | 17:45 |
| james_w | that's not a lintian bug | 17:45 |
| \sh | james_w: then? | 17:45 |
| james_w | it should be an override in the package if you care about it | 17:45 |
| slytherin | Laney: There are no b-d-i | 17:45 |
| Laney | is there an arch:all package? | 17:46 |
| slytherin | \sh: The files are simply being copied. | 17:46 |
| Laney | hmm | 17:46 |
| slytherin | yes the problem happens with -doc package | 17:46 |
| \sh | james_w: that's something to override lintian false-positives... | 17:46 |
| slytherin | \sh: Laney: here is the relevant code - http://paste.ubuntu.com/373371/ | 17:47 |
| james_w | \sh: and this isn't one of those? | 17:47 |
| \sh | rmunn: but james_w is right...prepare a lintian override for this message | 17:47 |
| Laney | \sh: So you put the files in place and then presumably they will only get installed when doing an arch-indep build | 17:48 |
| Laney | erm, slytherin. sorry \sh | 17:48 |
| \sh | james_w: if it is an reported lintian error, I would say it's a bug of lintian, if it's just a warning, I would say the way to go is an override | 17:49 |
| slytherin | I didn't do it. I am just looking at FTBFS. :-) | 17:49 |
| Laney | well "the build" then | 17:49 |
| Laney | I'd just copy the files from their location in the source tree instead of doing that cp at all | 17:49 |
| slytherin | Laney: Perhaps you are right. I guess I will change it to --list-missing | 17:49 |
| \sh | james_w: as this is an informational message, override is appropriate | 17:49 |
| sebner | slytherin: I'm wondering about the --fail-missing option. doesn't install fail anyways when a file is missing? | 17:50 |
| \sh | rmunn: prepare an lintian override for this warning in your package...and file a bug against revu to not declare an info as common error, ;) | 17:50 |
| Laney | no, it fails the build when you forget to install a file into a binary package | 17:50 |
| slytherin | sebner: No --fail-missing means if the file is not included in the resulting package. | 17:50 |
| sebner | ah ic | 17:50 |
| Laney | presumably it could be made more clever though | 17:51 |
| Laney | if no _all package then ignore stuff under /usr/share | 17:51 |
| * Laney -> home | 17:53 | |
| sebner | Laney: bye | 17:53 |
| persia | james_w: Why isn't it a lintian bug again? Lintian is suggesting to do something that doesn't match policy. | 17:54 |
| james_w | lintian explains that if the package isn't used in clean it shouldn't be there, so it's suggesting to you two options | 17:55 |
| james_w | it has a global list of ignores, but is it right for every package to have python-yaml in Build-Depends? no. | 17:55 |
| rmunn | In this case, the package *is* used in clean, but it's about two dependency levels deep via Python imports, and lintian doesn't have a good way of knowing that it's necessary... | 17:55 |
| persia | Well, lintian could run debian/rules clean as part of the check :) But yeah, I can see how it's annoying and/or awkward to fix. | 17:56 |
| james_w | you could file a wishlist bug asking for them to execute python code to work out if that module will be loaded from a site directory during a setup.py clean | 17:56 |
| james_w | but if the package is deviating from the norm then you should override lintian where you know better. That's exactly the advised policy. | 17:56 |
| rmunn | james_w, that seems dangerous to me -- what if someone uploaded a malicious package to REVU with a setup.py that did all kinds of nasty stuff when imported? | 17:57 |
| * persia completely agrees that an override is appropriate | 17:57 | |
| james_w | if lintian is wrong in (nearly) every case or can easily be made to spot your case then file a bug on it, otherwise if you know better then override it if you care about lintian cleanliness | 17:57 |
| rmunn | Override created and new version uploaded to http://revu.ubuntuwire.com/p/python-nltk, should show up in a minute or two | 17:57 |
| james_w | rmunn: exactly | 17:57 |
| kamalmostafa | james_w: hello -- "bzr branch lp:ubuntu/squid" yields a (quite) stale branch -- give it a poke? | 17:58 |
| rmunn | Okay, my override didn't work. Anyone want to look at http://revu.ubuntuwire.com/p/python-nltk (check the debdiff against previous version, that's easiest) and tell me what I did wrong in creating the debian/source/lintian-overrides file? | 17:59 |
| james_w | hi kamalmostafa | 17:59 |
| james_w | you know about http://package-import.ubuntu.com/status/ | 17:59 |
| james_w | rmunn: debian/source.lintian-overrides | 17:59 |
| rmunn | I thought I followed the syntax in http://lintian.debian.org/manual/ch2.html precisely... there's probably *something* obvious I'm missing, but I just don't see it | 17:59 |
| rmunn | "If the override is for a source package, you have to place it at debian/source/lintian-overrides or debian/source.lintian-overrides (the former path is preferred)." I used the former path. | 18:00 |
| james_w | oh | 18:00 |
| rmunn | Now *that* is a lintian bug, if debian/source/lintian-overrides doesn't work despite the manual saying it does. :-) | 18:00 |
| persia | It does work, at least I've seen it work. I don't remember the syntax perfectly though. | 18:02 |
| kamalmostafa | james_w: no, I didn't know about import-status. It's quite bewildering. :-) | 18:02 |
| \sh | rmunn: source.lintian-overrides did work in the past...;) | 18:03 |
| james_w | kamalmostafa: indeed, it needs some ui love :-) | 18:03 |
| james_w | rmunn: not sure why that's not working | 18:05 |
| kamalmostafa | james_w: So I see that it does reference 'squid', but I don't know what to make of its error detail (python error stack). And I note that its squid error log is dated 6 days ago. What's your interpretation of it? | 18:07 |
| rmunn | Which version of lintian is running on REVU? Even on my lucid box, lintian --display-info isn't complaining about this. Only when I upload to REVU do I get the warning. Makes it kind of hard to fix without a dozen re-uploads, when I can't seem to reproduce the problem locally... | 18:07 |
| james_w | kamalmostafa: error in james_w I believe | 18:07 |
| rmunn | I'll try source.lintian-overrides, see if that makes REVU happier. | 18:08 |
| james_w | rmunn: don't bother | 18:08 |
| james_w | it's probably hardy or something, if it works fine on later versions that's good enough | 18:08 |
| kamalmostafa | james_w: Okay then, I'll consider the issue "reported" (unless you can tell me what package to report james_w bugs against? ;-). | 18:09 |
| james_w | kamalmostafa: two ticks | 18:10 |
| sistpoty|work | rmunn: lintian on revu is from hardy, as spooky (revu's host) is still running hardy. just ignore it's output as james_w suggested | 18:11 |
| sistpoty|work | (and nobody dares to update spooky to post hardy, since it's a sparc box and sparc status in anything past hardy is suboptimal) | 18:12 |
| persia | Um, lintian on REVU is 2.2.17ubuntu1.1, which is the same as karmic-updates: there's been some backporting (but it's still out of date) | 18:12 |
| persia | (hardy-backports is only 2.1.2ubuntu1~hardy1) | 18:13 |
| rmunn | Well, I'd already kicked off an upload with a debian/source.lintian-overrides, and that worked. | 18:13 |
| jdong | *seems to recall a backport request to at least some Ubuntu release* | 18:13 |
| jdong | maybe not Hardy. | 18:13 |
| sebner | bddebian: did you already have time to take a look at http://paste.ubuntu.com/373384/ ? | 18:13 |
| jdong | if not, that would be a good idea (tm) :) | 18:13 |
| rmunn | But REVU still says "At least one common error: check the lintian file." Said lintian file contains nothing but "N: 1 tag overridden (1 info)". :-) | 18:13 |
| persia | jdong: I seem to recall there being some issue with getting current lintian on spooky other than just procedural, although backporting to at least karmic may have value. | 18:14 |
| sistpoty|work | persia: oh, cool, so someone did backport it in the meantime :) | 18:14 |
| persia | sistpoty|work: Yep. Might have even been you :p | 18:15 |
| sistpoty|work | persia: no, I recall that my try failed due to some perl errors, and I reinstalled the old version ;) | 18:15 |
| jdong | persia: right; I was thinking more the usecase of contributors that are still on Hardy themselves | 18:15 |
| james_w | kamalmostafa: queued | 18:15 |
| persia | jdong: Hrm. We do have some of those, but not so many (or they work in chroots). | 18:16 |
| jdong | yeah I'd expect the latter to be common :) | 18:16 |
| sistpoty|work | jdong: while you're at it, you could also do dpkg so that revu can handle v3 packages :P | 18:16 |
| jdong | I've definitely seen people request backports of lintian but usually just to the n-1 releases | 18:16 |
| jdong | sistpoty|work: hehe that sounds like something I'd be a bit more scared to touch :) | 18:17 |
| jdong | I don't want the trophy for most broken update ever ;-) | 18:17 |
| sistpoty|work | heh | 18:17 |
| persia | What we need is someone to make sure the SPARC kernels work. | 18:17 |
| rmunn | Okay, so the only changes I've had to make recently to http://revu.ubuntuwire.com/p/python-nltk have been cosmetic. Does that mean it's ready for some MOTU advocates? | 18:17 |
| sistpoty|work | or a different box for revu :P | 18:18 |
| Laney | yeah, setting a binary-indep target doesn't work | 18:35 |
| Laney | at least pbuilder doesn't call it during the build | 18:35 |
| james_w | kamalmostafa: squid up to date, thanks for the reminder | 18:36 |
| persia | Laney: Are you doing arch-dependent or arch-independent builds? I know sbuild has the -A option which, on the buildds, is only enabled for i386. | 18:39 |
| Laney | persia: pbuilder has no such option | 18:39 |
| Laney | AFAIK, at least. And anyway it tried to build the indep package without running the corresponding binary-indep target | 18:39 |
| persia | Well, try in sbuild then, is all I can say. If you're running lucid, you can pull the latest ubuntu-dev-tools from trunk, and use mk-sbuild to create tarball schroots which only take up as much space as pbuilder (no more need for LVM) | 18:41 |
| james_w | kamalmostafa: it produced https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/squid/lucid-201002101821/+merge/19038 | 18:42 |
| james_w | kamalmostafa: is that the dropped upload you were talking about? | 18:42 |
| Laney | persia: will do, thanks | 18:46 |
| persia | Laney: Note that despite constantly talking about sbuild, I do approve of using pbuilder, because I suspect that otherwise we'd have a hard time distinguishing bugs in policy from bugs in sbuild. | 18:47 |
| james_w | kamalmostafa: ah, it's ok, I see what happened | 18:48 |
| Laney | I know, but I also know that sbuild supports selective arch/arch+indep builds, which pbuilder does not, and that I would like to test in this case. | 18:48 |
| persia | Laney: Indeed. I don't know if I'll finish by FF, but I'm hoping to find a way to get sbuild to reuse pbuilder tarballs soon. | 18:49 |
| persia | (although if I miss FF, I'll get distracted and may not get back to it any time soon) | 18:49 |
| kamalmostafa | james_w: back now ... can I answer any questions about the squid issue, or do you have matters in hand? | 18:52 |
| james_w | kamalmostafa: it's all good thanks | 18:52 |
| === Myrtti is now known as Guest75564 | ||
| oojah | Could someone please review http://revu.ubuntuwire.com/p/sqlite3-pcre ? It's had a few suggestions already so should hopefully be pretty sane. It's a very simple package, the only slightly unusual bit being that it gets the source from git. | 19:10 |
| RoAkSoAx | james_w, ping | 19:11 |
| james_w | hey RoAkSoAx | 19:11 |
| RoAkSoAx | james_w, heya!! I just merged my first package using bzr... would you mind reviewing / uploading it please? https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/519940 | 19:12 |
| ubottu | Ubuntu bug 519940 in keepalived "Please merge keepalived 1.1.17-2 from debian testing" [Low,Confirmed] | 19:12 |
| === Myrtti_ is now known as Guest8777 | ||
| james_w | RoAkSoAx: looking | 19:16 |
| === Guest8777 is now known as Myrtti | ||
| DktrKranz | could a revu admin help me to track what happened to ubuntuwintv_0.7.1-0ubuntu1 upload? TIA | 19:27 |
| james_w | RoAkSoAx: uploaded | 19:35 |
| RoAkSoAx | james_w, thanks :) | 19:36 |
| persia | DktrKranz: I don't see it in any of incoming, uploads, or rejected. I'm guessing either the upload didn't happen correctly, or it worked. | 19:37 |
| === EagleScreen is now known as Guest67076 | ||
| DktrKranz | persia: thanks, I'll ask to reupload again | 19:40 |
| persia | DktrKranz: I can't find it in the archived list either. A new upload is probably best. | 19:40 |
| RoAkSoAx | james_w, btw.. starting from when do we have to use bzr as mandatory? | 19:41 |
| james_w | RoAkSoAx: 5 minutes time | 19:43 |
| james_w | RoAkSoAx: nope, it's not mandatory, just really good | 19:43 |
| RoAkSoAx | james_w, oh ok, thought it's going to become mandatory to use bzr over time | 19:44 |
| james_w | RoAkSoAx: maybe one day | 19:45 |
| james_w | but there are currently no plans | 19:45 |
| RoAkSoAx | oh I see, well I guess i can use both methods while mastering the use of bzr :) | 19:46 |
| === EagleSn is now known as EagleScreen | ||
| === yofel_ is now known as yofel | ||
| bddebian | sebner: No, was I supposed to? | 20:19 |
| sebner | bddebian: Well, I showed it some days ago to you. Maybe you missed it. Currently discussing in debian-games on oftc | 20:21 |
| imi | hi | 20:39 |
| persia | Hey | 20:39 |
| === MrKanister1 is now known as MrKanister | ||
| Laney | hm, so it looks like sbuild uses binary-arch when doing an arch-dep build, and binary when doing arch+indep | 20:42 |
| Laney | but binary doesn't depend on binary-indep | 20:42 |
| imi | https://bugs.launchpad.net/bugs/519013 -- I was suggested to try backports as kdevelop may have a newes version in backports. actually, it doesn't have. Since I used to contribute packages to an other dpkg based distribution, I'm considering to build one on my own | 20:42 |
| ubottu | Ubuntu bug 519013 in kdevelop "upgrade kdevelop please" [Undecided,Invalid] | 20:42 |
| JontheEchidna | hmm, I thought somebody had backported a never version than what was in karmic | 20:43 |
| JontheEchidna | guess not though. I'll open up a karmic-backports task | 20:44 |
| imi | it does not have a backport package, I've just checked it at packages.ubuntu.com | 20:47 |
| Laney | yeah, something is wrong with building sid chroots (at least with mk-sbuild) | 21:38 |
| Laney | it installed half the world and then didn't even work for building :) | 21:38 |
| DktrKranz | (it probably needed the other half) | 21:38 |
| Laney | no, part of the world it installed made it die | 21:39 |
| Laney | (exim) | 21:39 |
| === EagleScreen is now known as Guest94638 | ||
| francisco | hi | 22:29 |
| francisco | how can I register in a channel? | 22:30 |
| francisco | in an irc-channel | 22:30 |
| persia | francisco: /query nickserv | 22:31 |
| francisco | persia: thanks a lot! | 22:31 |
| kamalmostafa | james_w: I'm trying to work on yet another package ('gcin') with a stale bzr tree. I see it in the list of "905 outstanding jobs" at http://package-import.ubuntu.com/status/ -- Does this mean that I should ask you to manually provoke it to import, or that I should wait patiently? | 22:32 |
| paissad | hi all, i've packaged a software, i did 1st for debian, but i would like the package to be available in ubuntu repositories ... what do you suggest me to do ? ... | 22:33 |
| sebner | paissad: is it already in Debian? | 22:33 |
| paissad | i've alreaady uploaded the package in mentors-debian repositories & i'm waiting for a sponsor to upload it definitely | 22:33 |
| james_w | kamalmostafa: running | 22:33 |
| paissad | sebner, no for the moment, .... it's just in mentors-debian repositories waiting for a sponsor to upload it ! | 22:34 |
| paissad | sebner, but i do have it in my personal repository | 22:34 |
| paissad | wait 1 min please | 22:34 |
| sebner | paissad: well, if you are not sure to get it uploaded to Debian the next day you should upload it to REVU as Final Freeze is in 8 days | 22:35 |
| Laney | final freeze?!?!?!?! | 22:35 |
| persia | No reason we can't review a package on mentors. | 22:35 |
| paissad | sebner, REVU, let me google that ! | 22:35 |
| paissad | i did not know | 22:35 |
| persia | Feature Freeze. | 22:35 |
| sebner | argh | 22:35 |
| Laney | heh | 22:35 |
| sebner | sorry | 22:35 |
| sebner | wrong word! | 22:35 |
| kamalmostafa | james_w: Thanks -- I see it running on the status page, and will watch for its completion. | 22:35 |
| sebner | !revu | paissad | 22:36 |
| Laney | I'm not sure how likely it is that we will get to review a package on REVU now for Lucid anyway | 22:36 |
| ubottu | paissad: 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 | 22:36 |
| persia | sebner: Just go review the package on mentors. If it looks good, get a peer review, and get it uploaded. | 22:36 |
| persia | REVU is a good tool, but REVU isn't the only way to do two-developers-looked-at-this | 22:36 |
| sebner | persia: we need to pull a DD out of under a rock too though :P | 22:36 |
| francisco | alquien me puede ayudar? | 22:36 |
| francisco | como me puedo registrar en debian-es | 22:37 |
| francisco | ? | 22:37 |
| francisco | necesito un registrarme para poder chatear | 22:37 |
| persia | !es | 22:37 |
| ubottu | En la mayoría de canales de Ubuntu se habla sólo en inglés. Si busca ayuda en español o charlar entra en el canal #ubuntu-es. Escribe "/join #ubuntu-es" (sin comillas) y dale a enter. | 22:37 |
| francisco | ok | 22:37 |
| francisco | ubottu: thanks | 22:37 |
| ubottu | You're welcome! But keep in mind I'm just a bot ;-) | 22:37 |
| francisco | ok | 22:37 |
| * sebner hugs ubottu :D | 22:38 | |
| paissad | for people speaking french, they can read here http://doc.ubuntu-fr.org/pms-linux ... others might be able to understand too .. ^^ | 22:38 |
| ajmitch | sebner: you should join the NM queue | 22:39 |
| sebner | heh | 22:40 |
| sebner | ajmitch: to be honest I intend to become DM the next month (ehm, at least applying) | 22:40 |
| ajmitch | & then DD? | 22:40 |
| sebner | ajmitch: maye in 1-2 years ;) | 22:41 |
| ajmitch | how disappointing :) | 22:42 |
| kamalmostafa | james_w: alas, the gcin import has failed http://package-import.ubuntu.com/status/gcin.html#2010-02-10%2022:36:53.695156 | 22:42 |
| james_w | ah | 22:42 |
| james_w | is it bz2? | 22:42 |
| sebner | ajmitch: lack of time, skill, ... | 22:42 |
| ajmitch | sebner: lack of time, I can accept... | 22:43 |
| kamalmostafa | james_w: yup, sure is. | 22:43 |
| DktrKranz | sebner: too humble | 22:43 |
| * sebner hides | 22:43 | |
| james_w | kamalmostafa: I'm writing the tests for that tomorrow | 22:43 |
| james_w | if you can wait a day it should be there | 22:44 |
| kamalmostafa | james_w: no problem -- I'll just apt-get source in the meantime. thanks! | 22:44 |
| * ajmitch should upgrade his sid VM more often | 22:45 | |
| sebner | ajmitch: lack of time? ;-P | 22:46 |
| ajmitch | sebner: it's just been a couple of weeks since I last did a dist-upgrade | 22:46 |
| ajmitch | I need to remember to do it | 22:46 |
| sebner | ajmitch: when I'm actively doing some -dev stuff I upgrade my pbuilders every day. And my lucid machine too ^^ | 22:48 |
| ajmitch | I've ketp my lucid install mostly up to date | 22:49 |
| === EagleScreen is now known as Guest17512 | ||
| === EagleSn is now known as EagleScreen | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!