/srv/irclogs.ubuntu.com/2012/01/17/#ubuntu-devel.txt

=== zyga is now known as zyga-afk
=== allquixotic_ is now known as allquixotic
cjwatsontumbleweed: u-d-a> done01:01
=== retoaded_afk is now known as retoaded_gftd
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
TucksHello? :O04:31
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
haraldjHello anybody from the SRU and the security team already online?07:13
micahgharaldj: what's your question?07:15
haraldjno question, rather a discussion about how to handle security/functionality bugs in package openswan07:16
haraldjFor Hardy there are 4 open security issues (at least according to diff of the Ubuntu/Debian changelogs)07:18
micahgharaldj: security fixes need to be cherry-picked, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation (we could probably fakesync for natty)07:18
tumbleweedcjwatson: ta07:19
haraldjmicahg: Well it's not only security but also functionality: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/22729407:19
ubottuUbuntu bug 227294 in openswan (Ubuntu) "defaultroute with PPP does not work" [Undecided,Confirmed]07:19
micahgharaldj: if there are bugs, they can be SRUd, if you want new functionality, you'll want to look at backports07:19
haraldjÄhm sorry I guess you misunderstood me: I'm the Debian uploader ;-)07:20
haraldjAnd after tackling most of the Debian bugs I'm now trying to catch up with the Ubuntu ones07:20
micahgharaldj: so, both SRUs and security updates need to be minimal fixes, full backports are possible with testing of the backport and its rdepends07:21
haraldjmicahg: Sure same in Debian the question remains what issues the SRU and security team deem important enough/vs non-invasive to get into07:23
haraldjmicahg: There are for example many calls for fixes for KLIPS which may not be too easy...07:24
haraldjmicahg: I think it would make most sense to present a list (to be made by me) to the people responsible for this decision which details which fixes are missing in each release07:25
haraldjmicahg: But who exactly are these people?07:25
ScottKharaldj: Fortunately for you, micahg is one of the members of the Ubuntu security team.07:27
haraldjScottK: Well I already thought this when reading his comments ;-)07:28
micahgharaldj: so, for the security fixes, you can discuss with mdeslaur in #ubuntu-hardened after 14:00 UTC, not sure if the SRU people are around, but basically, if it's a small patch and testable, it's probably ok to SRU07:28
* SpamapS is an SRU person07:29
haraldjmicahg: Ok, I will try to come up with a list of fixes needed and will try to test it07:29
micahgharaldj: well, the fixes will need to be tested after they're uploaded as well, but it's always nice to know if they work beforehand :)07:30
micahgharaldj: and the security team loves help :)07:30
haraldjmicahg: Well I can only give it small tests as I do not really use Ubuntu but I will try my best07:31
micahgharaldj: well, I meant that there's a test case that someone can test the fix07:31
haraldjmicahg: Yes I know I've already worked with Moritz Muehlenhoff from Debian security team ;-)07:31
SpamapSharaldj: typically with the SRU process, you'd want to keep it to one fix at a time, or a group of small related fixes at one time. Otherwise it can be difficult to verify all of the bug fixes, which is required to pass into -updates07:31
haraldjSpamapS: Well for Hardy there are 4 open security issues (if counted right) and two other issues07:32
SpamapSharaldj: and for hardy, we'd only do High priority fixes.. things that cause data loss or completely broken software.07:33
micahgharaldj: I'd suggest going for the security issues first, then SRUing the bug fixes afterwards (security issues go in right away after testing, SRUs require 7 days)07:33
SpamapSharaldj: yeah, security is micahg's realm. :)07:33
SpamapSharaldj: and I'd agree with micahg.. get them into security first.07:34
haraldjSpamapS: could you please take a look at https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/227294 and https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/228274?07:34
ubottuUbuntu bug 227294 in openswan (Ubuntu) "defaultroute with PPP does not work" [Undecided,Confirmed]07:34
ubottuUbuntu bug 228274 in openswan (Ubuntu) "openswan creates "rundir" and "subsysdir"" [Undecided,Confirmed]07:34
haraldjSpamapS: If they are not suitable please close them with won't fix07:34
SpamapSharaldj: are these things fixed in later upstream versions?07:34
haraldjSpamapS: Yes07:34
haraldjSpamapS: Lucid has a new version which should fix these issues07:35
haraldjSpamapS: So if they are won't fix please close them (I already applied for ubuntu-bugcontrol for openswan to better care for the package)07:36
SpamapSharaldj: not much info there. Are there workarounds for these bugs?07:37
SpamapSharaldj: well they're technically already "closed" as Fix Released (I'm marking them as such). At this point it would be a task only against hardy..07:37
haraldjharaldj: No not as far as I know - the rundir/subsysdir are just missing $ signs07:37
haraldjsorry meant SpamapS ;-)07:37
micahghttps://bugs.gentoo.org/show_bug.cgi?id=193824#c007:38
ubottubugs.gentoo.org bug 193824 in Applications "net-misc/openswan-2.4.9 creates errant directories "rundir", "subsysdir"" [Normal,Resolved: fixed]07:38
haraldjSpamapS: for the ppp bug I will need to take a look at the fix07:38
SpamapSharaldj: so the rundir/subsysdir .. the software is totally broken for... most, or all, or just some users?07:39
SpamapSharaldj: let me dig out your bugcontrol app so I can +1 it.. :)07:40
haraldjSpamapS: the rundir/subsysdir is merely an annoyance I guess07:41
micahgre bug control app> it doesn't look like it's been moderated yet07:41
haraldjAs long as the dirs already exit07:41
SpamapSharaldj: ok so thats not a good candidate for a hardy SRU. The other one though, that looks more difficult to work around07:42
haraldjSpamapS: Well then I think just close the rundir/subsysdir :-)07:43
SpamapSharaldj: I'll mark it as Won't Fix in Hardy, with a priority of Medium. The other seems High priority, so a patched package would certainly be accepted.07:44
haraldjSpamapS: Ok the fix for ppp is a two-liner07:44
dholbachgood morning07:44
SpamapSharaldj: though, if the test case is clear and the patch fo rthe rundir thing is only 2 lines also.. I wouldn't mind it being fixed as well.07:45
micahgSpamapS: well, cleanup will require a maintainer script fix, the simple SRU would be not to create the dirs anymore07:45
haraldjSpamapS: Well for the rundir issue I would take the Gentoo patch, for the ppp issue I would take the Debian patch07:46
SpamapSmicahg: a maintainer script that searches the entire filesystem for rundir/subsysdir.. that doesn't seem doable.07:46
haraldjmicahg: Well the dirs would be created but the right way ;-)07:46
haraldjSpamapS: +107:47
micahgharaldj: right, sorry :)07:47
haraldjSpamapS: would be far to dangerous, think about a package placing a rundir in eg /opt...07:47
SpamapSmicahg: we could have it echo "Sorry we messed with your home dir"07:47
SpamapSno we're not going to cleanup the mistakes of the past.. ;)07:47
SpamapSnot in that case anyway07:48
haraldjSpamapS: was an upstream mistake ;-)07:48
SpamapSOk, I think I understand the two issues, and both patches are very simple and straightforward...07:48
haraldjmicahg: But we could do a find and tell the user we found them...07:48
haraldjmicahg: They may check and remove if necessary07:48
SpamapSI would suggest addressing the 4 security issues first, then attaching a debdiff or a merge proposal to one of the other two bugs with uploads for hardy-proposed07:49
micahgharaldj: I don't think we'd take a maintainer script to do that as an SRU, but IANA SRU team member07:49
SpamapSharaldj: to be clear, since the fix and test case are so simple, both are acceptible for SRU.07:49
SpamapSmicahg: no, we wouldn't. :)07:49
haraldjSpamapS: Ok :-) so I will talk with the security guy concerning the patches and then later talk again with you about hardy-proposed, is that ok for you?07:50
SpamapSharaldj: yeah. I'd suggest actually attaching the debdiff and subscribing ubuntu-sponsors to the bug.. this will allow somebody to get to it quicker, and helps keep the line clear between SRU team members and -proposed uploaders (more eyeballs.. etc. etc.)07:52
SpamapSharaldj: but by all means, ping me about it07:52
haraldjharaldj: Ok I will do :-)07:52
micahgharaldj: so, for the security patches, for natty, you can just fix in squeeze and sync, precise, fix in sid and sync, the other releases will need debdiffs07:53
haraldjSorry mistyped again ;-)07:53
haraldjmicahg: precise is ok07:53
SpamapSharaldj: btw, did you email ubuntu-bugcontrol@lists.launchpad.net ? not seeing your email there07:53
micahgSpamapS: that list is moderated for non-subscribers07:53
haraldjmicahg: 2.6.37 there is uptodate07:54
haraldjmicahg: squeeze-security has a fixed version, doing the sync may be up to the ones who can do ;-)07:54
micahgharaldj: yeah, just mention to mdeslaur and he can take care of that07:54
haraldjmicahg: ok07:55
haraldjSpamapS: another issue: does Ubuntu want to have KLIPS support from openswan?07:55
SpamapSharaldj: Ubuntu wants everything Debian has to offer.. well.. except insserv. ;)07:56
haraldjSpamapS: *ggg*07:56
haraldjSpamapS: Well KLIPS support would mean greater patches, I'm not sure this would be acceptable, maybe if there is a need for it there should rather be backports07:57
SpamapSharaldj: Oh kernel patches or openswan patches?07:57
haraldjOps alioth is down...07:58
SpamapSwe're not going to take kernel patches that aren't upstream07:58
haraldjSpamapS: In case of Hardy it would be a patch to patch the patch for the kernel ;-)07:58
micahgalso, new functionality isn't allowed in SRUs07:59
SpamapSwe'd like for hardy users to be at least migrated to lucid by now.. so probably no.07:59
haraldjmicahg: Well the functionality isn't new - KLIPS is an alternative IPSec Stack for the kernel which needs to be apadted to compile with newer kernel versions07:59
haraldjSpamapS: Ok no problem for me :-)08:00
SpamapSI mean hardy servers will still get critical updates for 2 more years. But, its time to start planning for the hardy->lucid->precise double upgrade in August if you have hardy boxes. :)08:00
micahgSpamapS: hardy has a little over 15 months of support left08:00
SpamapSwell not 2 more years.. about 21 more months.08:00
haraldjSpamapS: I think https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 is then a candidate for won't fix08:00
SpamapS15?08:00
ubottuUbuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Confirmed]08:00
SpamapSoh right, 12+308:01
SpamapSwas doing 24-3 :-P08:01
SpamapSoi.. its 2012 isn't it? :-P08:01
haraldjSpamapS: :-) well I do not have any hardy boxes08:01
* SpamapS screams AHHHGGGHH we're all gonna die in Homer's voice08:01
haraldjSpamapS: Doh08:01
haraldjSpamapS: so I would think close the above bug if there is no need for KLIPS in Hardy anymore08:02
micahgdoes lucid+ have KLIPS already?08:02
haraldjmicahg: Not sure what kernel version has lucid?08:03
StevenK2.6.3208:03
SpamapSsounds like a Fix Released08:03
haraldjSpamapS: not sure08:04
* haraldj works through Debian and upstream gut08:04
haraldjgit08:04
SpamapSwell 11.10 has 3.0.008:04
haraldjSpamapS: openswan 2.6.37 runs on my netbook with 3.2.0-rc7 so no problem with KLIPS here08:05
micahgso that should at least be Fix Released (precise)08:06
SpamapSindright, 3.2.0 is precise08:07
haraldjmicahg: Yes08:07
SpamapSharaldj: closed as Fix Released08:08
haraldjupstream openswan 2.6.24 contains a commit which fixes KLIPS for kernel 2.6.3208:08
haraldjSpamapS: which one did you close?08:08
SpamapSharaldj: KLIPS support08:09
SpamapSharaldj: btw, thanks very much for tending the bugs.08:10
haraldjSpamapS: There are 4 or so bugs open for KLIPS support :-) for almost every Release one I guess08:10
haraldjSpamapS: Well I try my best08:11
SpamapSharaldj: ahh, if its all just the same request (please add KLIPS) then just mark them all as duplicates08:11
SpamapSharaldj: or if you can't mark as dupe, then list the #'s and I'll do that08:11
haraldjSpamapS: I'm not sure this makes sense this way because the fixes are incremental08:12
haraldjSpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 is a similar matter - https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 did talk about the module not included, https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 did talk about the module not compilable08:14
ubottuUbuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed]08:14
ubottuUbuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Fix released]08:14
haraldjSpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/253041 says the module is not included -> correct there is only the source for it08:15
ubottuUbuntu bug 253041 in openswan (Ubuntu) "KLIPS module not included with openswan" [Undecided,Fix released]08:15
haraldjSpamapS: https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 says it is not compileable -> correct, this is fixed with a patch of me which can be found in Debian Lenny security version08:16
ubottuUbuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed]08:16
haraldjSpamapS: So I guess https://bugs.launchpad.net/ubuntu/+source/openswan/+bug/246713 could be close to08:17
ubottuUbuntu bug 246713 in openswan (Ubuntu) "openswan-modules-source pkg does not compile with m-a" [Undecided,Confirmed]08:17
haraldjUps sorry must do some work now ;-)08:18
robert461hello any one to chat ? ;-)08:40
=== zyga-afk is now known as zyga
tjaaltonstill a huge backlog on ppa-builders? 11h as suggested by lp..10:01
tjaaltonwas the same last week10:01
MacSlowJust ran into LP: #894340 "E:Couldn't configure pre-depend libtinfo5 for libncurses5, probably a dependency cycle" while trying to dist-upgrade my desktop-box from oneiric to precise... any hints for a work-around?10:12
MacSlowseb128, didrocks, pitti: ^^ any idea10:16
seb128MacSlow, hey, I've personally no clue about this one but maybe mvo would10:20
seb128or cjwatson10:20
cjwatsonhuh, I wonder why that's at all hard; libtinfo5 Pre-Depends: multiarch-support (which you should already have) and Depends: libc6 (>= 2.4) (likewise)10:21
MacSlowmvo, cjwatson: got a tip for a work-around on LP: #894340 ?10:21
cjwatsoneglibc wasn't uploaded recently or anything10:21
cjwatsonnor was ncurses10:21
cjwatsonMacSlow: i386 or amd64?10:23
MacSlowcjwatson, amd6410:23
* infinity wonders why ncurses predepends tinfo instead of just a depends.10:24
cjwatsoneither way, not sure why it should break10:27
cjwatsonplaying around to see if I can restore the apt-clone data from that bug report10:27
infinity     - Add Pre-dependency on libtinfo5 to libncurses5 to prevent possible10:28
infinity       symbol lookup errors if libncurses5 is unpacked before libtinfo5.10:28
seb128somebody else is mentioning the same bug on #ubuntu-bugs10:28
infinityThat seems like a blatant misunderstanding of dependencies.10:28
infinityI'm sure that dropping the pre-dep to a dep will fix the resolver breakage.  Still curious that it breaks though, yes.10:29
DavieyDoes anyone own/(have access to) trusted boot (intel) hardware?10:30
cjwatsoninfinity: wait, that actually seems reasonable to me10:30
infinitycjwatson: It does?10:30
infinitycjwatson: Pre-dep is to guarantee a package is configured.  If unpack isn't enough to guarantee symbol lookups, then every binary->library dependency is "wrong".10:31
MacSlowcjwatson, so should I just wait for the relevant packages to be rebuild?10:31
cjwatsonif unpacking the new libncurses5 is going to break without libtinfo5 on the system, then I can't see any way other than Pre-Depends to enforce libtinfo5 being >= unpacked10:31
cjwatsonMacSlow: huh?10:31
cjwatsonMacSlow: we haven't analysed this yet.10:31
cjwatsoninfinity: maybe there are Essential binaries linked to ncurses10:32
cjwatsonit wouldn't overly surprise me10:32
MacSlowcjwatson, ok10:32
cjwatsonI think Priority: required libraries ought to be able to support that, at least10:32
infinitycjwatson: Potentially, sure, but ncurses depends on tinfo, I don't see how that can go backward.  There's no dependency loop.10:32
cjwatsoninfinity: right - that's why I'm trying to stuff apt-clone data into place in the hope of reproducing it10:33
infinitycjwatson: (And, indeed, our own version in oneiric was a dep, not a pre-dep, and I don't recall any fallout)10:33
infinitycjwatson: It was the next Debian revision that promoted that to a pre-dep.10:33
cjwatsonFrom binaries in Essential packages, fdisk, cfdisk, and pg link to ncurses10:34
WellarkI'm pretty sure that this is some corner case on my system. otherwise we would be getting duplicates every 5 minutes from people doing the upgrade10:34
cjwatsonIt doesn't seem strictly vital but I'd prefer to figure out why apt is eating its own tail rather than reverting the pre-dep10:35
Wellarkcould it be some package I've installed is getting the dependency cycles wrong?10:35
Wellarke.i. confusing the resolver10:35
cjwatsonit's possible; do you have an apt-clone state file somewhere?10:36
cjwatsonwhat we need to do is to get a chroot on an expert's system configured to reproduce things10:36
Wellarkyes, attached to the bug10:37
cjwatsonah yes10:37
Wellarkhttps://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/894340/comments/510:37
ubottuUbuntu bug 894340 in update-manager (Ubuntu) "Release Upgrade Fails: depency cycle for libtinfo5/libncurses5" [Undecided,Confirmed]10:37
cjwatsongive me a few minutes to try to beat things into shape here10:37
Wellarksure sure10:37
WellarkI'm not in such hurry10:37
=== kklimonda_ is now known as kklimonda
Wellarkafter all my system is still in usable state :)10:37
infinityWellark: Do you have any ncurses*-dev packages installed?10:38
Wellarkprobably, will check10:39
infinityI note some multiarch mangling in the -dev packages in 5.9-3.  Curious if that could wreak upgrade havoc.10:39
Wellarkhmm.. I've only have lib32ncurses5-dev10:40
WellarkI thought I had some others, too10:40
WellarkI remember doing some ncurses stuff couple of months ago10:40
cjwatsonyeah, multiarch is certainly a possible source of trouble10:40
Wellarkoh, but that was with python ncurses10:40
Wellarkhmm.. using apt-rdepends10:41
WellarkI see that file is needed by wine-dev10:42
infinitySo, you have libncurses5-dev:i386 installed, perhaps?10:43
Wellarkoh, read the output wrong10:43
cjwatsonhah, apt-clone gets pretty confused if you try to restore state into an amd64 chroot in an i386 host system10:43
Wellarklet's see10:43
cjwatson(with an amd64 kernel - it's physically possible for it to execute the binaries)10:43
infinitycjwatson: linux64 to the rescue?10:43
infinityOh, but amd64 kernel, should be reporting linux64ishly anyway.10:44
cjwatsoninfinity: no, I think it's using the system's apt10:44
infinityYeah.10:44
infinitySpecial.10:44
cjwatsonand forgetting to set APT::Architecture10:44
Wellarkinfinity: I've got libncurse5-dev installed10:47
Wellarkand dpkg-query -s says Architecture: amd6410:47
mvocjwatson: heh :) never tried that, what is the error?10:48
infinityWellark: And nothing for "dpkg -l libncurses5-dev:i386"?10:49
Wellarkno, nothing10:49
cjwatsonmvo: no error but it downloads i386 package lists instead of amd64 and (I think) tries to restore i386 packages which doesn't go so well10:49
cjwatsonwell, no error before I noticed what it was doing and C-c10:50
* cjwatson convinces chdist to load that data10:50
mvocjwatson: thanks! good to know, probably trivial to fix (like you said already earlier :)10:51
cjwatsonmvo: want a bug?10:54
infinityOh, ncurses wasn't multiarch in oneiric, so I guess my questions about having i386 stuff installed are irrelevant.10:54
mvocjwatson: I write a note about it, its hopefully quicker to fix than to write a bug10:56
cjwatsonmvo: *nod*10:58
cjwatsonta10:58
Wellarkcjwatson, infinity: if you come up any ideas, just ping me, ok?11:05
WellarkI'm off to make some coffee11:06
cjwatsonbah, chdist apt-get dist-upgrade doesn't reproduce this11:11
=== doko__ is now known as doko
RiddellARM dudes: problem in qtwebkit compile11:27
Riddellhttps://launchpadlibrarian.net/90264873/buildlog_ubuntu-precise-armhf.qtwebkit-source_2.2.1-1ubuntu1_FAILEDTOBUILD.txt.gz11:27
Riddell"/usr/bin/ld: final link failed: Memory exhausted"11:27
Riddellideas?11:27
=== _salem is now known as salem_
WellarkRiddell: more swap..11:35
Wellarkqtwebkit can take from 4-8GB of memory on linking stage11:35
Tm_TWellark: James Bond: When 16 GiB is not enough11:35
* Tm_T hides11:35
RiddellWellark: well yes I could guess that, it's a question of how to get it11:36
Tm_TRiddell: I wonder if #canonical-sysadmin would help11:38
WellarkRiddell: or #launchpad as it's build service related11:40
Tm_Tah, forgot launchpad had their own channel11:43
infinityRiddell: Waiting on kernel upgrades on the buildds to make that happy.11:52
infinityRiddell: Once the buildds have shiny new kernels, we'll retry the world.  If you see the same failure on that package again, please scream.11:53
=== MacSlow is now known as MacSlow|lunch
Riddellinfinity: nice thanks11:54
=== TREllis_ is now known as TREllis
alexblighDoes software exist (say an apache module) which provides a web-based view of the CONTENTS of a .deb (or even better, an entire repository), and let individual files be downloaded over the web (I know it's an ar file containing 2 x tgz, and I know I could write something in perl myself, but I suspect it's been done before).11:59
beunoalexbligh, you mean something like this?  http://packages.ubuntu.com/precise/comm/asterisk12:07
alexblighbeuno, yes, the code behind that (these are .debs we autobuild), save that when you go to (say) http://packages.ubuntu.com/precise/amd64/asterisk/filelist I need to be able to download the files themselves, not just the list of files.12:09
beunoalexbligh, on the right-hand side, don'y you have the tar.gz file and such?12:10
alexblighYes, but I want to download the files IN the package12:11
beunoah, I see12:11
alexbligh(i.e. the individual files in the .tgz in the .ar)12:11
beunoI don't know of any websites that have that since the packages are uploaded already compressesed AFAIK12:11
alexblighIf the source to packages.ubuntu.com is open source, I'd be happy to hack it up so http://packages.ubuntu.com/precise/amd64/asterisk/filelist can be a link12:12
alexblighbeuno, yes, but you can extract them with a bit of perl and ar and tar file by file.12:12
jpdsalexbligh: http://packages.ubuntu.com/about/12:12
alexblighI was just hoping someone had done the work.12:12
alexblighjpds, ooh, thanks. That will be a good start.12:13
beunoright, it may not play super nicely with the servers, though, having to decompress a ton of things on the server-side12:13
alexblighbeuno, that's true. Perhaps not suitable for public consumption, but this is for internal usage.12:13
beunoright, go nuts then!12:14
* Sweetshark wants to rebase on debian, but alioth is down :/12:16
Davieywould someone on foundations like to comment on, bug 913379.. thanks.12:32
ubottuLaunchpad bug 913379 in ntp (Ubuntu) "Migrate ntp from SystemV to Upstart" [Wishlist,New] https://launchpad.net/bugs/91337912:32
=== retoaded_gftd is now known as retoaded
=== calc is now known as Guest36731
tomreynhi, i'm just looking at bug #879926 and wonder whether there will likely be a SRU?13:17
ubottuLaunchpad bug 879926 in Evince "evince crashed with SIGSEGV in g_param_spec_pool_lookup()" [Critical,New] https://launchpad.net/bugs/87992613:17
seb128tomreyn, could be, though it seems most bugs were from precise and not oneiric, not sure if that's a real issue in oneiric13:19
seb128well the code bug is obvious so it's probably is13:20
seb128do you get the issue?13:20
tomreynseb128: yes, i ran into it on oneiric, and the bug is also tagged oneiric13:29
seb128tomreyn, ok, thanks13:29
scott-workit appears that the REVU website is down, it also appears that i cannot dput to REVU13:31
scott-workdoes anyone have any infomration?13:31
tomreynseb128: do you want me to comment on the bug asking for an SRU or will you take it from here?13:31
seb128tomreyn, I will add it to my list but feel free to comment on the bug if you want, what we will need is somebody who has the issue to confirm the fix after the upload ;-)13:32
tomreynokay, i'll comment and watch it.13:34
seb128thanks13:34
tomreynthank you!13:38
=== MacSlow|lunch is now known as MacSlow
cjwatsonalexbligh: http://www.mirrorservice.org/ does that: e.g. http://www.mirrorservice.org/sites/archive.ubuntu.com/ubuntu/pool/universe/a/asterisk/asterisk_1.6.2.9-2ubuntu2_i386.deb%5Bpeek%5D14:08
=== ion_ is now known as ion
ogra_does anyone know if: "Architecture: any-arm" in debian/control should work ?14:12
ndechi. i have tried to use Arch = any-arm for some of our packages, and my upload are rejected in this case. If i use Arch = armel armhf, it works as expected, but i got the feeling from the debian policy that any-arm should work. Anyone can advise?14:13
ndecah... i didn't see that ogra_ just asked the same question ;-)14:13
ogra_heh14:14
ndecany-arm work when building locally with dpkg-buildpackage in armel or armhf root fs. it's just that the upload is rejected by LP14:14
seb128seems like soyuz doesn't handle that yet14:15
* ogra_ guesses soyuz just knows $(dpkg-architecture -L), any, all14:15
cjwatsonIt might be a bit naive about CPU aliases14:16
cjwatsonIt does know about any-i386, say, but -arm is a bit different14:16
ndecso, should I open a bug for any-arm?14:17
ogra_well, the footnote at http://www.debian.org/doc/debian-policy/footnotes.html#f88 also talks about gnu triplets ... we dont have any plain "arm" triplet either14:17
ogra_or am i reading that just wrong ?14:17
cjwatson$ dpkg-architecture -aarmel -iany-arm; echo $?14:22
cjwatson014:22
cjwatsontherefore IMO you should file a bug on Launchpad about this, yes14:22
cjwatsonlib/lp/soyuz/pas.py:determineArchitecturesToBuild doesn't implement the full architecture alias handling14:23
ogra_aha14:23
=== zyga is now known as zyga-food
=== bladernr_afk is now known as bladernr_
ScottKbarry: ping re usb-python.15:02
barryScottK: hi15:05
ScottKHello barry.  Did you get the more detailed ping I sent yesterday?15:05
barryScottK: i didn't15:05
ScottKOK.  Let me find it.15:05
ScottK[11:56:17] <ScottK> barry: ping re python-dbus recommends python-gobject.  This pulls python-gobject and a stack of other things into the Kubuntu seeds that aren't otherwise needed.  Do you think it could be dropped?15:06
ScottKSimilar for python3-dbus.15:06
barryScottK: it's only a build-dep, right?15:06
ScottKNo, it's a run time Recommends.15:06
ScottKThat's why it gets pulled in.15:06
ScottKIt seems somewhat bogus to me.15:07
ScottKBut you've been in the code, so I wanted to see what you thought.15:07
barryScottK: ah right, it's in wheezy that way too.  let me just look at a couple of things15:08
ScottKThanks.15:08
barryScottK: so, outside of the test suite (and thus the build-dep), it's only imported in dbus/gobject_service.py.  we could probably split that out into a separate binary package and then only that would need python-gobject.  i don't really know what kind of impact that would have for clients of the package (i.e. how much dbus/gobject_service.py is used)15:14
ScottKAny suggestions on how we could find out?15:14
barryi guess i could grep through my installed precise *.py to see if i can track down any imports of it15:15
ScottKOr any reference to ExportedGObject as that and ExportedGObjectType are the only classes in there.15:16
barryyep, good idea15:16
=== mfisch` is now known as mfisch
ScottKIIRC kees used to have the entire Ubuntu archive unpacked.  Maybe he could do it ...15:17
barryScottK: well, just ran the import check.  zero imports15:17
ScottKCool.15:17
=== mfisch is now known as Guest39817
barryand all references to ExportedGObject are in dbus itself15:17
ScottKIf it's not used in any packages, then I think it's safe to drop it to suggests.15:18
barryScottK: rather than separating it into a new binary package?15:19
ScottKYes.15:19
barrythat's an easy change15:19
ScottKYeah.15:19
barryScottK: i think my latest upload is waiting to be accepted because of the new python-dbus-common binpkg (slangasek rejected it last time due to lintian warnings, since fixed)15:20
barryScottK: once that's accepted, i can make that change and upload.  when the new dbus-python is released upstream i had planned on submitting my changes to debian, so i can push the suggests change at that point15:20
ScottKOK.  I'm going to grab the rdepends and grep them, just to make sure.15:21
barrycool15:21
stgraber@pilot in15:32
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
ScottKbarry: There's one package that's a problem and it looks like it's unmaintained and likely to go away ~soon anyway.  I'll add the python-gobject depends to it and then your change to suggests is safe.  No need to wait to re-upload, BTW, the newer binaries in binary New will just superced the old ones.15:34
barryScottK: cool.  i'll make that change now then and upload.  could you submit a bug report in debian about it?  you can even assign it to me, and then i'll remember when the time comes there15:35
ScottKbarry: I take it back, they're all fine.15:35
ScottKSure.15:35
barryScottK: http://paste.ubuntu.com/807510/15:36
ScottKbarry: What about python3-dbus?15:37
barryyep, was just there :)15:37
ScottK(that's what I was hoping for for python-dbus)15:37
ScottKOK15:37
barryScottK: http://paste.ubuntu.com/807512/15:38
ScottKbarry: Yes.  Please.15:38
=== 20QAAK923 is now known as jbicha
ScottKbarry: Debian Bug#65623015:45
barryScottK: got it15:47
ScottKGreat.15:47
barryScottK: uploaded15:53
ScottKExcellent.15:54
* barry -> reboot15:56
hrwdoes someone saw eglibc builds looping?15:57
dholbachkirkland, hiya, do you think you can have a look at bug 917682?16:00
ubottuLaunchpad bug 917682 in byobu (Ubuntu) "Sync byobu 5.3-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/91768216:00
=== dendrobates is now known as dendro-afk
cjwatsonbarry: do you think it would be useful if I packaged the 'six' module?16:06
kirklanddholbach: i think it's been done16:06
kirklanddholbach: http://packages.qa.debian.org/b/byobu.html16:06
cjwatsonbarry: writing compat layers for cases where wedging 2to3 into the build system is awkward is getting tedious very quickly16:06
kirklanddholbach: oh, wait ...16:06
dholbachkirkland, eh?16:06
dholbach:)16:06
kirklanddholbach: they want Ubuntu to sync from debian?16:07
keesScottK: i just have the archive mirrored; the unpack is relatively fast though.16:07
kirklanddholbach: no, Ubuntu is upstream here;  Debian byobu is downstream16:07
=== dendro-afk is now known as dendrobates
ScottKkees: It turned out to be few enough packages that I downloaded them and checked.  Thanks though.16:07
dholbachkirkland, you're CCed on the bug - I identified a few things that were missing in the Debian packaging - I'll leave the bug to you16:07
kirklanddholbach: thanks;  the debian maintainer should propose a branch/merge/patch to lp:byobu16:08
kirklanddholbach: and I'll integrate16:08
Laneyget it on the sync blacklist if this is the case16:08
ScottKlamont: How goes postfix 2.8.7?16:08
keesScottK: cool16:09
lamontScottK: actually working on it now16:09
ScottKlamont: Excellent.  Thanks16:09
barrycjwatson: it could be useful.  so far i've managed to port code w/o 2to3 or six, which i think isn't too difficult if you only have to target >= 2.6.  but six could perhaps make that even easier or more consistent16:11
=== zyga-food is now known as zyga
cjwatsonbarry: right, it's just tedium like iteritems.  I could repeat the compatibility code (but that's so boring), or accept the performance hit in Python 2 of using items (but that involves thought about whether it matters)16:15
barrycjwatson: right (it rarely does though :) but yeah, i do agree it would be good to promote six as the compatibility layer.  i've been thinking about submitting some code upstream for the other things i've found at both the python and c layers.16:16
barrycjwatson: and i completely agree it's better than 2to3 :)16:17
cjwatsonheh, yeah16:22
cjwatsonalright, I'll knock a package together16:22
=== dendrobates is now known as dendro-afk
lamontScottK: my ppa16:31
ScottKlamont: I'm trying to remember what we decided on Bug #774500 ?16:31
lamontScottK: if you would be so kind as to play with that some?16:31
ubottuLaunchpad bug 774500 in postfix (Ubuntu) "postfix build does not have documented support of sqlite" [Wishlist,Confirmed] https://launchpad.net/bugs/77450016:31
ScottKSure.16:31
lamontScottK: I believe we decided that I still have some work to do there16:32
ScottKOK.16:32
ScottKbarry: https://launchpad.net/ubuntu/+source/dbus-python/0.84.0-2ubuntu3/+build/3099079 urk.16:35
ScottKlamont: trying.16:39
lamontScottK: do you know off the top of your head if libsqlite3-0 is effectively essential?16:39
ScottKMy recollection is we decided it was.16:39
ScottKIt's certainly in minimal.16:41
lamontScottK: it's entirely possible that it's fixed in this upload16:43
ScottKlamont: debc says there's no dict_sqlite.so16:45
ScottKMight as well leave it for 2.9.0 at this point though.16:47
ScottKlamont: Tests out fine here.  I say ship it.16:51
ScottKbarry: I'm going to mash retry since you didn't change anything that would affect that.16:54
=== deryck is now known as deryck[lunch]
cr3cjwatson: quick preseed question: if the same value is being set twice in the same preseed file, like partman-auto/method for example, does the last value always take precedence?17:02
cjwatsoncr3: Yes17:04
cjwatsoncr3: preseed files are declarative not imperative17:04
cr3cjwatson: thanks!17:06
=== m4n1sh__ is now known as manish
=== bladernr_ is now known as bladernr_afk
ScottKbarry: Failed again.  Not sure what's up there.  Over to you.17:22
=== jcastro_ is now known as jcastro
cjwatsonbarry: OK, six is in Debian NEW now17:35
=== kalosaurusrex is now known as albriga
=== albriga is now known as albrigha
=== deryck[lunch] is now known as deryck
ahasenackpitti: hey,18:03
ahasenackpitti: could you release a new postgresql-common for lucid? For the ppa:pitti/postgresql ppa?18:03
ahasenackpitti: release 128, which has pg_basebackup ;)18:04
broderbarry, ScottK: if you still need it, i have the archive unpacked on my lintian runner18:12
YokoZarSo, I'm working on multiarching Wine and I'm beginning to worry about build daemon skew.  For 32-bit compatibility, I have a few files from wine1.3 split into wine1.3-i386.  wine1.3-i386 is m-a:foreign and builds only on i386, so wine1.3:amd64 installs wine1.3-i386:i386.18:15
YokoZarMy worry is that if I put a depends: wine1.3 (= ${binary:Version}) on wine1.3-i386, then if the archive updates i386 before amd64 (due to faster build or copy) then a user who runs apt-get update has wine1.3:amd64 and wine1.3-i386:i386 will see something screwy, like the suggestion that they remove wine1.3:amd64 and install wine1.3:i386.18:15
YokoZar*wine1.3 is M-A:allowed and the depends in wine1.3-i386 would be wine1.3:any (= ${binary:Version})18:16
infinityYokoZar: buildd skew in a development release is somewhat unavoidable.  Users running devel branches need to not trust apt's "removing everything, kay?" solutions without reading.18:21
infinityYokoZar: It's a non issue in a released dist, since we won't push from proposed to updates until all arches are built.18:22
YokoZarinfinity: That seems reasonable.  And I suppose the archive admins will copy the package set from -proposed to -updates concurrently to avoid that as well.18:22
YokoZarinfinity: Now I'm worried about the launchpad ppa instead, since they have no way of withholding arches currently18:22
SarvattYokoZar: yeah it's a huge problem in xorg-edgers with daily mesa updates where one arch always builds up to a day later than the other18:23
YokoZarSarvatt: is there an existing feature request to launchpad to let us tick a box for the PPA somewhere that asks to hold as such?18:23
infinityYokoZar: The best way to do it in a PPA is to upload to a trunk/devel PPA, and then copy to a release PPA.18:24
infinityYokoZar: And encourage users to use the latter.18:24
YokoZarinfinity: Ok, but I have the same problem with my daily build recipe PPA, and somehow I don't think having a staging PPA for that is correct ;)18:24
infinityYokoZar: Perhaps not.18:25
infinityYokoZar: Have you actually tested to see that it's a problem?18:25
=== Guest39817 is now known as asshole
infinityYokoZar: apt might just hold A back if B isn't in sync, rather than suggest removal.18:25
YokoZarinfinity: it depends on what's marked manually vs automatically installed18:26
=== asshole is now known as stalking_dannf
YokoZarI think18:26
=== stalking_dannf is now known as mfisch
=== mfisch is now known as Guest4880
ScottKbroder: Thanks.  I ended up downloading the relevant packages.18:44
=== dendro-afk is now known as dendrobates
barryScottK: thanks.  we had some ppc failures last time, but rebuilds fixed them.  i'll look at it.19:10
barrycjwatson: awesome! thanks19:10
om26erstgraber, hey! can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/oneiric/tomboy/fix-880299/+merge/88910 as well19:11
stgraberom26er: sure, I was actually wondering if someone would prepare an SRU for it when I saw it land in Precise :)19:12
om26erstgraber, thx, i got another can you please sponsor it as well https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/compiz-sru/+merge/85928 :)19:25
stgraber@pilot out19:31
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
stgraberom26er: ok, will do tomboy and that one, then that's it for this shift19:31
om26erstgraber, thank you :)19:32
stgraberom26er: hmm, actually I'd better have someone with some kind of compiz knowledge to look at the compiz one. The tomboy one I looked at last week and I know the patch is fine, but compiz I'd rather have a desktop/X person sponsor it19:34
stgraberom26er: left a comment + review in that direction, hopefully someone will review it soon19:35
om26erstgraber, seb128 is aware of the compiz sru19:36
om26erits kind of the official SRU followed by a unity sru19:36
stgraberseb128: does https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/compiz-sru/+merge/85928 look good to you? if so, I have it ready for upload here so just let me know and I'll push to -proposed19:37
stgraberseb128: oh, and btw, you uploaded tomboy at -1ubuntu1.2 to precise instead of -1ubuntu2 which obviously made om26er SRU invalid as 1.2 already existed in the archive... :)19:45
stgraberseb128, om26er: Will repload the SRU as -1ubuntu1.1.1 instead19:45
om26eroops, thats all the oneirc/precise system switch :/19:47
stgraberok, re-uploaded with a note in the changelog explaining the weird version number :)19:47
om26erstgraber, if that matters the same compiz is uploaded to the ~desktop-team ppa so you can safely do the upload to -proposed ;-)19:49
om26erhttps://launchpad.net/~ubuntu-desktop/+archive/ppa?field.series_filter=oneiric19:49
stgraberom26er: fine, I'll upload it in 30min or so then ;)19:50
om26erstgraber, ok, thx for the 3upload :)19:52
=== dendrobates is now known as dendro-afk
seb128re20:06
stgraberom26er: have these changes be pushed to Precise?20:06
seb128stgraber, the compiz SRU is fine yes, we have it in the ubuntu-desktop ppa since before holidays20:06
stgraberom26er: I just had a quick look and can't find any matching patches or changes in Precise20:07
stgraberseb128: maybe you can answer that question? ^20:07
seb128stgraber, don't bother about precise, a new compiz release is due there but is taking some time due to the testing etc20:07
seb128stgraber, it will land in the next week or so20:07
stgraberk, as long as I can blame you if someone ask why I uploaded something to proposed without first uploading to Precise, I'm fine :)20:08
seb128stgraber, sorry about tomboy, I used dch -i20:08
stgraberI guessed so when I saw the previous entry in the changelog ;) Bah, we'll just have some weird version numbers in oneiric-updates, that's fine :)20:09
stgraberom26er: compiz uploaded20:10
=== salem_ is now known as _salem
=== stokachu_ is now known as stokachu
=== tilgovi_ is now known as tilgovi

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!