| === Guest79151 is now known as med_out | ||
| dglass | Question: I got a package (wakeup) accepted into the oneiric repositories through REVU. How can I get the ubuntu package updated to the most recent version I have made on launchpad? | 06:08 |
|---|---|---|
| micahg | dglass: file a bug w/a debdiff update and subscribe ubuntu-sponsors or a branch with a merge proposed into lp:ubuntu/wakeup | 06:10 |
| dglass | micahg: https://bugs.launchpad.net/ubuntu/+source/wakeup/+bug/876649. Is this correct? | 06:11 |
| ubottu | Launchpad bug 876649 in wakeup (Ubuntu) "Request for "new upstream version" upgrade." [Undecided,Incomplete] | 06:11 |
| micahg | dglass: I commented in that bug already about what you need to do | 06:11 |
| dglass | yes, you said to come here. I didn't understand your reply, sorry I'm new to this | 06:12 |
| micahg | dglass: right, so, you need to version your upstream release w/out ubuntuX in it, ubuntuX should be for updates in ubuntu that are not in the upstream .tar.gz | 06:14 |
| micahg | so you can go 1.0.1, 1.0.2, 1.0.3, or 1.1, 1.2, 1.3 depending on how you wish to version | 06:15 |
| dglass | micahg: So make a release on launchpad versioned 1.1-0ubuntu1 | 06:15 |
| dglass | and upload a diff between .deb files to the bug page? | 06:15 |
| micahg | dglass: no, 1.1 is fine, then we'll take that and make a 1.1-0ubuntu1 release in Ubuntu | 06:15 |
| micahg | the Ubuntu version is X-YubuntuZ where X is the upstream version, Y is the Debian version and Z is the Ubuntu version | 06:16 |
| dglass | micahg: ok, thanks. I will do this. Do you mind if I ask you here again in a few minutes to check on it after I've done that? | 06:16 |
| dglass | yes, it's a little confusing for me because there is no debian version. I got it accepted through REVU, so it's ubuntu only | 06:17 |
| micahg | sure | 06:17 |
| micahg | well, we use 0 when we're ahead of Debian or they don't have the package yet | 06:17 |
| dglass | ok, thank you. | 06:17 |
| dglass | micahg: I believe I have done as you suggested. I released a version 1.1 on lp:wakeup and uploaded a debdiff to the bug page (https://bugs.launchpad.net/ubuntu/+source/wakeup/+bug/876649). Could you check on this please? | 07:05 |
| ubottu | Launchpad bug 876649 in wakeup (Ubuntu) "Request for "new upstream version" upgrade." [Undecided,Incomplete] | 07:05 |
| micahg | dglass: upstream release looks good, debdiff though should target precise and close the LP bug | 07:07 |
| dglass | micahg: again, sorry for not understanding. If I target precise, doesn't that mean I have to change the changelog in the upstream release? Also, does that mean it won't be available in oneiric? | 07:09 |
| micahg | dglass: no, upstream release has no debian dir | 07:09 |
| micahg | the update will not be, that's correct | 07:09 |
| dglass | so.... my updates will go unused until next april?? | 07:10 |
| micahg | you can request a full backport if you like (https://help.ubuntu.com/community/UbuntuBackports), or you can cherry pick fixes for an SRU (https://wiki.ubuntu.com/StableReleaseUpdates) | 07:10 |
| dglass | micahg: in software sources, I believe, -backports is not enabled by default, correct? Unfortunately I think there are some bugs fixed in this recent version which make the older version work improperly in a noticeable way. Do I need to create a separate bug for a backport? | 07:20 |
| micahg | dglass: it is in oneiric, but it's opt in, so they'd have to select the version from there | 07:21 |
| micahg | dglass: well, if you want the bug fixes to go to the widest number of users, you could SRU them if they have test cases, otherwise, for a backport, file a bug against the oneiric-backports project, requirements for a backport are that the package build/install/run | 07:22 |
| micahg | but regardless for either option, the fixes need to be in precise first | 07:22 |
| dglass | micahg: ok, so first I need to change the debdiff to precise, then file a separate bug in oneiric-backports. Backports don't get automatically updated into precise? | 07:23 |
| micahg | no, first the package hits precise, then we can backport to previous releases | 07:24 |
| dglass | micahg: I reuploaded the debdiff. Does this look good? | 07:32 |
| micahg | dglass: looks good, thanks, just reset the bug to confirmed now and it'll be in the queue for the sponsors | 07:33 |
| dglass | micahg: ok, thanks a lot. Now I need to wait for it to get accepted to precise before opening a bug with oneiric-backports? | 07:34 |
| micahg | dglass: right, since if you open it now, it'll just be marked incomplete | 07:35 |
| dglass | micahg: ok, great. thanks for all the help, I really appreciate it | 07:35 |
| micahg | dglass: you're welcome and thank you for contributing to Ubuntu development | 07:36 |
| dholbach | good morning | 07:56 |
| tumbleweed | morning | 07:57 |
| broder | does anybody have a config snippet i could steal to run sbuild under eatmydata? | 07:58 |
| tumbleweed | broder: command-prefix=eatmydata | 07:58 |
| broder | is that...an schroot option? | 07:59 |
| broder | ah, yes, it is | 07:59 |
| broder | ...is there a compelling reason i shouldn't set that on all of my chroots? | 08:00 |
| tumbleweed | not that I know of | 08:01 |
| tumbleweed | (of course you can only do it when eatmydata is installed in the chroot) | 08:02 |
| * broder goes and files a mk-sbuild bug to add an --eatmydata option :) | 08:02 | |
| tumbleweed | well, obviously, only do it for throwaway chroots | 08:02 |
| === sagaci__ is now known as sagaci | ||
| tumbleweed | broder: I'm playing with using a normalised schema for the rdepends database. That will allow more interesting queries (like main-only, which reverse-build-depends could do) | 12:38 |
| tumbleweed | also, collapsing all binary archs into one. I don't see any point in keeping them separate | 12:38 |
| geser | tumbleweed: so you don't have any information anymore which are still has that reverse depends? | 12:40 |
| geser | wouldn't that cause confusion why a reverse depends is listed if one checks on the "wrong" arch? | 12:41 |
| tumbleweed | geser: for most purposes, you want to look at all rdepends, right? | 12:43 |
| tumbleweed | if they are only on one arch, maybe it should show that | 12:44 |
| Laney | nbs | 12:45 |
| tumbleweed | Laney: eh? | 12:45 |
| RainCT | tumbleweed: "not build from source" | 12:49 |
| tumbleweed | RainCT: yeah, I know what it means. I'm asking what he means | 12:49 |
| tumbleweed | is seeing nbs packages in rdepends a problem? | 12:50 |
| Laney | that is when you might have skew | 12:50 |
| Laney | gotta go teach | 12:50 |
| tumbleweed | sure, but a union of all archs rdepends | 12:50 |
| Laney | you might care which arch | 12:50 |
| Laney | really gotta go! | 12:50 |
| tumbleweed | ok, I'll move the aggregation to client-side | 12:51 |
| geser | tumbleweed: I'm not sure if it's a problem for the use-cases you intend? could it also be used for unmet deps? | 13:05 |
| geser | in case of archive skew, it might be helpful to know that a reverse dependency only exists on a specific arch | 13:07 |
| geser | (to avoid questions like is the script buggy because apt-cache doesn't show this dependency) | 13:08 |
| tumbleweed | geser: well, might as well make it as widely useful as possible | 13:10 |
| === yofel_ is now known as yofel | ||
| === chuck__ is now known as zul | ||
| blair | micahg, debian responded to hdf5: http://lists.debian.org/debian-gis/2011/11/msg00002.html, what's your take on the response? | 15:29 |
| tumbleweed | blair: I don't know how hard hdf transitions usually are, but I'd suggest test building all the reverse dependencies against the new version, if it's something you want to persue | 16:01 |
| blair | tumbleweed, thanks, the pure 1.8.4 to 1.8.7 is just a recompile, but debian has redone their packages since, so there may be more work there | 16:04 |
| tumbleweed | blair: oh, right no ABI change | 16:05 |
| tumbleweed | (or is there?) | 16:05 |
| tumbleweed | ah, there is | 16:05 |
| tumbleweed | blair: my question is, will everything recompile? | 16:05 |
| blair | there are unintentional ABI changes, but the code is source compatible | 16:06 |
| blair | yes, it should just recompile | 16:06 |
| tumbleweed | right, but there are packaging changes | 16:06 |
| tumbleweed | so, it's still a question of how much work will this be. We wouldn't want to start it if we couldn't finish it | 16:07 |
| blair | right | 16:07 |
| blair | that's why i'm thinking at minimum, just take the existing 1.8.4 packages in ubuntu and update them to 1.8.7, ignoring the packaging changes | 16:08 |
| geser | blair: why would it be easier to upgrade the packages ourself instead of using the version from experimental? | 16:26 |
| blair | geser, i presumed from tumbleweed's question that they packages may not be fully completed yet and ready to be promoted to debian unstable | 16:28 |
| blair | geser, if they are in good shape, then yes, sync/merge them over | 16:28 |
| blair | does ubuntu ever take experimental packages? | 16:28 |
| geser | yes, if there are good reasons for them (just not by default) | 16:28 |
| geser | from the message you linked the DD are just waiting on a transition slot from the Debian release team (to avoid mixing several transitions into one big chunk which makes it hard for the packages to move into testing as all need to be ready at the same time) | 16:30 |
| blair | i'm not that familiar with debian/ubuntu release process, so does that imply that the packages are basically ready and in good enough shape? | 16:32 |
| blair | do you suggest waiting for them to make the transition to unstable before merging into ubuntu? | 16:33 |
| tumbleweed | blair: it means that they think they are ready | 16:39 |
| tumbleweed | the release team may not agree | 16:39 |
| tumbleweed | you can ask the release team what they think | 16:39 |
| blair | tumbleweed, where/how do i ask the release team? | 16:40 |
| tumbleweed | but presumably, if they think they are ready the packaging changes for all the reverse dependancies should be staged in VCS / experimental | 16:40 |
| micahg | blair: we can't upgrade the package as is due to the ABI break, so changes would be needed, also being out of sync with Debian WRT to the package names will make keeping in sync harder in the future and leave us with a diff we'd have to carry until the next LTS (14.04), so not a good idea for the most part | 16:48 |
| tumbleweed | Laney, geser: there: http://qa.ubuntuwire.org/rdepends/v1/precise/any/bash (see also s/any/source/ s/any/i386/ etc ) | 16:51 |
| tumbleweed | of course my client needs updating now... | 16:51 |
| Laney | good stuff | 16:52 |
| Laney | are you using udd? | 16:53 |
| tumbleweed | no. That's a highly normalised sqlite db | 16:53 |
| tumbleweed | see lp:~stefanor/+junk/reverse-deps/ | 16:53 |
| Laney | normalisation!?!?!?!?!?!?! | 16:53 |
| tumbleweed | turns out you can make useful queries when it's normalised :P | 16:54 |
| tumbleweed | it also got a lot smaller, but then people wanted more information, so it got back to about the same size it used to be before normalisation | 16:55 |
| Laney | someone should normalise udd and make compatibility views for the old stuff | 16:55 |
| tumbleweed | or just add extra normalisation tables | 16:55 |
| tumbleweed | this stuff tends to be quite hard to normalise, though. One has to cut corners | 16:56 |
| tumbleweed | bug relationships are already reasonably normalised in UDD, except that merged bugs still makes it a nightmare to query | 16:56 |
| tumbleweed | blair: sorry enever answered you. The debian release team hangs out in their channel on OFTC. Of course it's not their job to advise us about our transitions, though :P | 16:58 |
| blair | tumbleweed, there's multiple debian channels, is there one specific one where the release managers are in? | 17:00 |
| tumbleweed | #debian-release | 17:00 |
| tumbleweed | you can ask where it is in the queue, and if they've done any research into how hard it'll be | 17:01 |
| blair | ok, thanks | 17:01 |
| geser | blair: thanks for sticking to get it done (and chasing all needed information) | 17:10 |
| aboudreault | hi. with quilt... what's the proper way to edit a patch... it looks like dh_quilt_patch is too simple | 18:51 |
| broder | aboudreault: it's usually easiest to use quilt push/pop to get to the patch, then edit the files you want to change, then run quilt refresh | 18:51 |
| aboudreault | broder, but quilt is not aware of the debian directory | 18:52 |
| aboudreault | it tries to execute in the current dir | 18:52 |
| broder | aboudreault: echo QUILT_PATCHES=debian/patches >~/.quiltrc | 18:52 |
| aboudreault | broder, thanks, will try this way | 18:54 |
| EvilResistance | broder: around? | 19:42 |
| broder | yes, what's up? | 19:42 |
| EvilResistance | re: backport of ZNC. i noticed it was put into oneiric? | 19:42 |
| EvilResistance | no progress on natty, yet, i assume? | 19:43 |
| broder | i've uploaded the natty backport, but an archive admin still needs to accept it from the queue | 19:43 |
| broder | and process the swig backport | 19:43 |
| EvilResistance | i see. | 19:44 |
| EvilResistance | wasnt sure ;P | 19:44 |
| EvilResistance | i'll leave ya be then :P | 19:44 |
| broder | i try not to harass the archive admins too much, but i can start bugging people if it isn't handled by the end of the week. there are a few other pending backports as well that should be seen to | 19:45 |
| micahg | broder: it'll be blocked on Bug #888665 most likely | 19:46 |
| ubottu | Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Undecided,New] https://launchpad.net/bugs/888665 | 19:46 |
| broder | oh, ugh. yeah, you're right | 19:46 |
| broder | i...was just looking at that bug but it slipped my mind :) | 19:46 |
| EvilResistance | heh | 19:50 |
| EvilResistance | perhaps the LP admins should *fix* that before the natty backport :/ | 19:52 |
| EvilResistance | (in the mean time, the backports i did within my own PPA seem to be working :P) | 19:52 |
| broder | yes, ppas work differently from the actual backports pocket in that regard | 19:53 |
| EvilResistance | i'm curious... i take it that an already-built backport within a PPA cant be pulled into the standard ubuntu archive? | 19:53 |
| EvilResistance | or something similar | 19:53 |
| EvilResistance | because if its already been built elsewhere, shouldnt that in theory invalidate the need for the backported build-deP? | 19:54 |
| EvilResistance | build-dep * | 19:54 |
| broder | we do that for a couple of special cases - kernels and security updates in particular | 19:55 |
| broder | if asked, the archive admins could probably do that for backports, but i don't want to do that unless it looks like the launchpad issue just isn't going to get fixed in a reasonable amount of time | 19:56 |
| EvilResistance | ok | 19:56 |
| EvilResistance | but fwiw, define "reasonable amount of time" | 19:57 |
| EvilResistance | (since "reasonable" is relative) | 19:57 |
| EvilResistance | ;P | 19:57 |
| broder | not entirely sure. i'd at least like a few days to figure out what our plan is | 19:59 |
| EvilResistance | broder: ok i'll leave you be then. if all else fails though you all are free to pull the built binaries from my backports ppa. | 20:04 |
| micahg | EvilResistance: not really, we must build from source :) | 20:05 |
| EvilResistance | :P | 20:05 |
| EvilResistance | micahg: then the bug needs fixing :P | 20:05 |
| * EvilResistance attends to his glitchy DNS server | 20:06 | |
| EvilResistance | micahg: the alternative is that i just tell all the Natty users who need the updated znc package to use my ppa :P | 20:08 |
| micahg | EvilResistance: heh, I appreciate you trying to DTRT, we'll try to get this sorted | 20:09 |
| broder | micahg: if it turns out that this will take a while for the lp team to sort out, i would support doing a copy from a properly-configured backporters PPA or something into the archive. we'd have to see if the archive admins would go for it, though | 20:10 |
| broder | but i don't think we're at that point of desperation yet | 20:10 |
| micahg | broder: I wouldn't | 20:10 |
| micahg | but then I'm super paranoid :), also that would only build on i386 and amd64 | 20:11 |
| broder | hmm, that's true. but that's also something we could deal with | 20:11 |
| EvilResistance | As i was going to add to my statement before i got so rudely bumped from campus internet... | 20:15 |
| EvilResistance | ... which looks bad on ubuntu for not backporting when it was backported to oneiric (note that unlike you and I, linux newbies or those not sufficiently acquainted with linux-fu and packaging-fu won't understand there's a bug preventing the build) | 20:15 |
| broder | EvilResistance: right, and we'd rather do this using backports than have you handing out a PPA. just give us a little while to figure out what our options are - we're just now finding out about this | 20:21 |
| EvilResistance | okay, i'm going to slap my campus now... that's the 5th time today i've been bumped from that wireless AP | 20:25 |
| EvilResistance | broder: indeed. dont take what i said as rude (i was just making a statement is all... as well, my internet is glitchy today so sorry about the interruptions in the string of thoughts :P) | 20:26 |
| broder | EvilResistance: yeah, i understand, and i know it's frustrating (i've been on both sides of this process too) | 20:27 |
| EvilResistance | :P | 20:27 |
| === Elbrus_reconnect is now known as Elbrus | ||
| lfaraone | So package pithos is in sid, see <http://launchpad.net/debian/+source/pithos>. But running «syncpackage pithos» on my oneiric machine gives me "ubuntutools.lp.udtexceptions.PackageNotFoundException: The package 'pithos' does not exist in the Debian primary archive in 'sid'". Any idea what gives? | 21:38 |
| jtaylor | its probably only looking in testing | 21:42 |
| jtaylor | lfaraone: ^ | 21:42 |
| lfaraone | yeah, but: $ rmadison -u qa pithos | 21:45 |
| lfaraone | pithos | 0.3.11-1 | wheezy | source, all | 21:45 |
| lfaraone | pithos | 0.3.13-1 | sid | source, all | 21:45 |
| bdrung | lfaraone: that's what the latest version says: $ syncpackage pithos | 21:46 |
| bdrung | syncpackage: Error: Version in Debian 0.3.11-1 (testing) isn't newer than Ubuntu 0.3.11-1 (precise) | 21:46 |
| lfaraone | bdrung: ah, I'll use the version from trunk then with -d sid | 21:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!