/srv/irclogs.ubuntu.com/2011/11/11/#ubuntu-motu.txt

=== EvilResistance is now known as Resistance
micahgScottK: isn't pulling the dependency if it's "neeeded" what experimental does and what I suggested in the bug?  as opposed to always using the backports version which was what was occurring pre-natty05:05
Resistanceanyone know if the IRC council meetings are open to the public?  at least for spectating05:05
ScottKI think Experimental only uses Experimental if it's told to, but I'm not sure.05:06
* Resistance cant find anyone who knows05:06
ScottKResistance: They are.  They are, not surprisingly, held on IRC in #ubuntu-meeting.05:06
ResistanceScottK:  know when the next meeting date is?05:06
* micahg requests laney to explain experimental...05:06
ScottKNo.05:06
Resistanceknow where i can find out?05:07
AnAntHello, I am preparing a package for a library that got GIR data06:00
AnAntwhen I use compat level 9 (for multiarch support), the .typelib file gets installed to /usr/lib/<multiarch dir>/gireopository-1.0 instead of /usr/lib/girepository-1.0/06:01
AnAntis this a bug or what ?06:02
broderScottK, micahg: i thought the conclusion we came to was that experimental builds pulled build-deps from experimental if said build-deps carried a versioned build-dep that could only be satisfied by experimental06:03
broderAnAnt: did you mark the gir1.2- package as multi-arch?06:03
micahgbroder: right, that's what I thought, hence what I requested in the bug06:03
AnAntbroder: nope06:03
AnAntbroder: you know of an example library package so that I can follow ?06:08
broderAnAnt: nope, not off the top of my head. i don't think we've multiarched much in the stack above gtk at this point, and gtk certainly isn't a good example06:09
broderAnAnt: yeah, gtk doesn't really solve this well. they move the library out of the multiarch path during the dh_install stage06:13
broderAnAnt: it looks like `pkg-config --variable=typelibdir gobject-introspection-1.0` will spit out where the typelibs are supposed to go, so the best solution might be to get the typelibdir from there, instead of building ot from libdir06:14
broder*building it06:14
micahgisn't /usr/lib/<triplet>/girepository-1.0 appropriate for a multiarch package?06:14
brodermicahg: i don't *think* so. i think the typelib files are supposed to be arch-independent06:14
micahgthen why are they in /usr/lib?06:14
broderhmm. good questoin06:15
broderfine, i revise my statement: i bet gobject-introspection hasn't been made multiarch-aware yet06:15
micahgbroder: take a look at #1: http://anonscm.debian.org/viewvc/pkg-gnome/packages/unstable/gobject-introspection/debian/policy.txt?revision=27188&view=markup&pathrev=27188, /usr/lib is for binary typelibs :)06:16
brodermicahg: yeah, i think gobject-introspection just isn't multiarch aware. slangasek completely side-stepped the typelibs when he multiarched gdk-pixbuf: http://lists.debian.org/debian-gtk-gnome/2011/07/msg00016.html06:17
broderneeding multiarched typelibs would be a bit screwy anyway - it'd have to be something like "my javascript interpreter is 32-bit but my python interpreter is 64-bit and i want to use GI bindings in each"06:20
* micahg hasn't dove into typelibs yet, so can't really speculate06:26
AnAntaren't typelib arch-indep ?!06:39
broderAnAnt: the fact that typelibs are in /usr/lib suggests that they are not arch-inde07:15
broder*indep07:15
micahgAnAnt: according to the policy quoted above, the xml definitions are and are in /usr/share, the binary format ones are in /usr/lib07:17
broderi can't actually find a spec on the typelib format to verify that it's arch-dependent, but both GNOME and Debian have concluded that they belong in /usr/lib, so it seems very likely07:18
AnAntif they are arch-dep, then they wouldn't have worked on 64-bit machines (since arch-all packages are usually built on i386)07:19
broderevan@caron:~$ apt-cache show gir1.2-gtk-3.0  | grep Arch07:19
broderArchitecture: amd6407:19
micahgaccording to policy, the binary typelib needs to be in architecture dependent package07:19
broderthe packages with the typelibs aren't arch-indep07:19
AnAnthmmm, I thought I saw one that is arch-indep07:21
AnAntI'm wrong07:21
AnAntin that case they should be in /usr/lib/<multiarch>/girepository-1.007:22
broderAnAnt: no, they should not, because there is not currently a specification for multiarched typelib files07:22
AnAntah, ok07:22
AnAntok, so I've got 2 options for my package: either manually move the typelib file to /usr/lib/girepository-1.0/, or simply not to multiarch the package07:24
broderAnAnt: i'd recommend the former07:25
AnAntok07:25
broderthat would be consistent with other multiarched libraries that ship typelibs07:25
AnAntbroder: btw, to multiarch a lib, is it required that it's run-time dependencies are multiarched as well ?07:26
broderyou won't be able to install a foreign-arch library unless all of its dependencies have been multiarched as well, but you're allowed to multiarch it anyway in anticipation of the dependencies getting converted07:27
cemcmicahg: https://bugs.launchpad.net/hardy-backports/+bug/888627, I'm not sure what this means in your last comment07:33
ubottuLaunchpad bug 888627 in Oneiric Backports "please backport pdns-recursor 3.3-2 from Precise" [Undecided,Incomplete]07:33
micahgcemc: so, basically I believe that overrides were added in 7.0.50, so any version less than that or its backports (hence using 7.0.50~), require the rules file to be expanded to its previous status, you might want to look at previous versions of the package pre-debhelper 7 to see what that should look like07:35
micahgerr, status isn't quite correct, former larger self?07:36
cemcI've looked at 3.3-1 in Oneiric which has a totally different debian/rules07:36
micahgright, you probably want to got back before the package was converted to debhelper 7, maybe lucid?07:37
micahgs/got/go07:37
brodermicahg: compat 7 still had a mechanism for doing overrides, it just wasn't as good07:37
broderit was something like %:\n\tdh $@ --before dh_install; dh_install --m-custom-args; dh $@ --something07:38
broderi forget the exact syntax07:38
micahgbroder: ok, could you help cemc dig up the changes needed for pdns-recursor then, that should easier than turning the 10 line file back into 5007:38
micahg* be easier07:39
* broder fetches source07:39
micahgthanks, I'm still trying to get an update out before bed07:39
cemcif the package builds as it is on Hardy, why is there a need to revert debian/rules?07:40
brodercemc: it probably builds, but you are probably silently dropping the changes to the arguments to dh_strip and dh_installinit specified in the rules file07:40
broderso i would guess that the dbg package is empty, plus a handful of other small issues07:41
cemcI see07:42
AnAntOFFTOPIC: can anyone help me with autoconf/automake or direct me to a channel for so ?07:43
dholbachgood morning07:46
cemcmorning07:47
AnAnthello07:48
dholbachhi cemc07:52
dholbachAnAnt, صباح الخير :)07:52
AnAntdholbach: how are you ?07:52
brodermicahg: ugh, i'm not sure whether i'm more offended by directly applying all of the patches in a .diff.gz or explicitly enabling quilt in the build system. i guess the latter is more in the spirit of the backport07:53
dholbachAnAnt, good good, thanks - how about you?07:53
broderalso, debian/compat is 5! i don't even know what that means with a dh rules file! :)07:53
AnAntdholbach: fine07:53
dholbachgreat :)07:53
micahgbroder: for personal backports, I usually just leave them applied, not sure how I feel about it for archive backports07:54
dholbachhi micahg, hey broder07:54
micahghi dholbach07:54
brodercemc: ok, i've attached a patch that i think should work properly for the hardy backport (https://bugs.launchpad.net/hardy-backports/+bug/888627/+attachment/2592842/+files/pdns-recursor_3.3-2~hardy1.debdiff), and thrown a test build in my PPA08:07
ubottuLaunchpad bug 888627 in Oneiric Backports "please backport pdns-recursor 3.3-2 from Precise" [Undecided,Incomplete]08:07
broderi probably won't pay any attention to that test build, so that's all up to you :)08:07
AngeloHi! I'm new with packaging and I have a problem learning how to start a package08:07
geserdo you know already about the packaging guide?08:08
Angeloyes, i'm following its instruction geser08:09
Angeloabout kqrcode example08:09
brodercemc: ok, never mind. just got mail about the build failure. working on attempt 2...08:09
Angelobut I got this message running dh_make08:10
Angelo"bzr: ERROR: Either run the command from an existing branch of upstream, or move kqrcode aside and a new branch will be created there."08:10
Angelowhat does it mean?08:10
Angelohello?08:21
geserI don't know what this error message means (and this channel is sometimes quiet, so be a little patient)08:23
broderman, hardy is old08:23
cemcbroder: :)08:24
broderalso, i have not yet done a PPA upload without having a mini panic attack in the middle that i accidentally uploaded to the archive proper08:24
cemcbroder: you can just send me the diff, and I'll upload to my ppa, I don't have access anywhere else :P08:25
brodercemc: i uploaded it to mine - https://launchpad.net/~broder/+archive/backports-tests08:25
broderit should build in a few minutes, assuming that i turned the wayback machine far enough back :)08:26
cemc:D08:26
cemcbroder: the same has to be done with lucid, mav, natty and oneiric too ?08:27
brodercemc: i don't think we need to actually modify the package for any of those. i can go ahead and kick off no-change test builds for those. one moment...08:28
cemcbroder: I did that already08:28
cemcbroder: https://launchpad.net/~cemc/+archive/ppa/+packages check them out here08:29
brodercemc: and you didn't modify the source at all to do the test build, other than adding a new changelog entry?08:29
broderfoiled again! hardy is so old!08:29
cemcbroder: nope, just dch -i and debuild and upload08:30
brodercemc: ok, perfect. then test those, and i'll figure out how to get this #$%^ hardy build to work :)08:30
broderat this point i feel a compulsive urge to defeat the old toolchain :)08:31
=== dholbach_ is now known as dholbach
cemcbroder: I'll get right on it. I'll update the bugreport when I'm done testing the packages. thanks a lot08:50
cemcbroder: there's still something wrong with the backported package, see my last comment pls https://bugs.launchpad.net/hardy-backports/+bug/88862711:56
ubottuLaunchpad bug 888627 in Oneiric Backports "please backport pdns-recursor 3.3-2 from Precise" [Undecided,Incomplete]11:56
Laneyregarding backports, I think respecting NotAutomatic for BDs is the right thing12:00
AngeloHi! Someone knows how to overcome this error? "make[2]: *** [kqrcode/CMakeFiles/kqrcode.dir/kqrcodewindow.o] Errore 1 make[1]: *** [kqrcode/CMakeFiles/kqrcode.dir/all] Errore 2"13:23
AngeloErrore=error (it's in italian)13:24
geserthis is a followup error from a previous error13:24
Angeloboth?13:24
geseryes, the real error should be short before these lines (usually)13:25
Angelook! :-) thank you13:25
Angeloyes13:26
=== Quintasan_ is now known as Quintasan
Angelothis is the first error "error: reference to ‘d’ is ambiguous"13:26
Angelobut I'm following the tutorial to learn ... it should be correct13:27
geserthat's probably the one you need to fix13:28
Angelou know how to do?13:28
gesercan you please put the whole part of this build log into a paste (e.g. http://paste.ubuntu.com/) and put the url here?13:28
Angelook!13:29
Angelo:-)13:29
Angelois this good http://paste.ubuntu.com/735216/ ?13:32
geseryes, this is good13:33
Angelo:-D13:33
geserunfortunately I don't know how to fix it, usually it involves looking at the source code and/or contacting upstream and asking for help13:37
AngeloI read that installing "kqrcode-dev-0.6.0.tar.gz" package we can solve the problem, and it is true with version 0.6.0. (cuz i've done it), but then I had another problem and so I returned using the tutorial version13:37
Angelook13:38
Angelothank you13:38
Angeloif I could help in something else for me it's ok13:40
ScottKbroder: Could be.13:45
geserAngelo: check if there are some easy bugs you could fix, it's often easier to start with bug fixes as there is already a working package to start from13:53
Angelogeser: ok!13:56
Angelo:-)13:56
Laneybdrung: uploading haskell-csv to bpo now14:19
bdrungk14:19
* Laney re-reads the rules14:19
=== bulldog98_ is now known as bulldog98
tumbleweedright, I think the reverse-depends tool in my backports branch is now at feature parity (the features that matter) with reverse-build-depends14:32
tumbleweedbugs, suggestions?14:32
tumbleweedLaney, broder: is the verobose output for that something you'd want in backport request bugs? or just a list of rdepend packages?14:34
Laneysorry, I haven't been following your development14:35
tumbleweedmy backporst branch = lp:~stefanor/ubuntu-dev-tools/requestbackport14:35
Laneywhat is the verbose output?14:35
tumbleweedrun reverse-depensd from that14:35
gesertumbleweed: can it be used to check for reverse-depends before filing a removal bug? list all reverse-(build-)depends for all binary packages of a source package14:36
tumbleweedthat's a good point, one probably wants to query for source pakcages more than binary packages14:37
* tumbleweed makes the DB schema even more complex14:39
Laneyshould it display --help if i run it with no arguments?14:39
* tumbleweed is just using optparse's error-handling there14:39
Laney./reverse-depends -b ghc died14:40
Laney  File "./reverse-depends", line 72, in main14:40
Laney    fields.append('Reverse-Recommends')14:40
LaneyAttributeError: 'tuple' object has no attribute 'append'14:40
tumbleweedta14:40
tumbleweedLaney: r120814:42
tumbleweedprobably no point in separating build-depends from build-depends indep, but it doesn't hurt either14:43
tumbleweedaha, wgrant is also guilty of unusually named changes files https://launchpad.net/ubuntu/feisty/+source/denyhosts/2.6-1ubuntu0.114:46
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
broderLaney: i think we are all agreeing loudly that backports *should* respect notautomatic, but i got the impression from infinity that that would be a lot of dev work, and we have multiple backports currently blocking on this bug, so we need an interim solution16:26
slangasekbroder: gobject-introspection is not multiarch-friendly in many ways16:36
pmjdebruijnhi all17:44
pmjdebruijnhttps://launchpadlibrarian.net/84926948/buildlog_ubuntu-oneiric-amd64.libgusb_0.1.2-0pmjdebruijn1%7Eoneiric_FAILEDTOBUILD.txt.gz17:44
pmjdebruijnI have failing self-test that might be USB related17:44
pmjdebruijnthe builds are taking place in Xen virtuals machines17:44
pmjdebruijnwould it be reasonable to think that this is why the usb related test might fail?17:44
geserpmjdebruijn: does the documentation tell under which conditions the function this assert is checking might fail?17:54
pmjdebruijnI'm not sure17:55
pmjdebruijndidn't find it quickly17:55
pmjdebruijnit builds just fine on my laptop17:55
geseryes, this most likely is the cause18:04
brodercemc: i can't reproduce the hardy install failure you reported with a fresh install or with an upgrade from the hardy version18:18
brodercemc: is it possible you had installed your own backport before hand, where you hadn't changed the rules file?18:20
brodertumbleweed: i don't think we need anything in the bug as verbose as what reverse-depends spits out now18:33
broderi'm sort of experimenting at the moment, but it seems like something like http://pastebin.ubuntu.com/735526/ would be useful in the bug description18:33
broder(though i'm a bit torn on what to sort by first)18:34
brodertumbleweed: other notes: reverse-depends could stand to throw a nicer error on 404, and it would be nice if i didn't have to specify -a source separately to get r-build-deps18:35
Laneybroder: so what solutions are on the table?19:29
aboudreaultwhy my quilt push works.... bud debuild fails to apply my patch?19:53
mewerner_arandaboudreault: Are they by any chance already applied?19:54
aboudreaultcan't be.. otherwise my quilt push would'nt work in the same directory19:54
mewerner_arandHmm...19:56
aboudreaultcan dh_quilt be more explicit?19:57
aboudreaultverbose19:57
jtaylorno 3.0 package?19:58
aboudreaultif I remove the first patch in the serie file... all other are applied.19:58
aboudreaultbut I can do a quilt push, and the patch is applied successfully19:59
jtaylorif its no 3.0 package is possible that its already applied20:00
aboudreaultand I can't see the .rej20:00
aboudreaultdebian/source/format is 3.020:01
jtaylorand its using dh_quilt?20:01
jtaylorthats not good20:01
broderLaney: infinity outlined them in the bug. they were (a) upgrade the sbuild lp uses, (b) somehow bypass NotAutomatic's effect on apt pinning, (c) hack sbuild to recognize when the resolver didn't install something because it's needed from backports and make it try again20:01
broder(bug 888665 for reference)20:02
ubottuLaunchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Undecided,Confirmed] https://launchpad.net/bugs/88866520:02
broderLaney: my opinion is obviously secondary to that of the lp admins, but by my judgement, (a) is the most elegant solution (and therefore good in the long term), (b) is the simplest solution (and therefore good in the short term), and (c) is neither simple nor elegant and therefore probably shouldn't be considered20:03
micahgand b is not a regression since this was the previous behaviour20:06
broderbut honestly, i wouldn't care if we regressed or not because we currently have multiple backports blocked on this bug20:07
micahgwell, it's problematic with backports on by default in oneiric20:08
broderhuh, do the release/proposed/update pockets build with backports enabled then? i hadn't considered that20:09
broderi would have assumed that the sources.list for them are more hand-curated20:10
micahgno, but someone might get more backports than intended20:10
broderah, sure20:10
broderi think that's comparatively minimal risk, though20:10
broder(since theoretically any backports they pick up should already have been tested against the oldpackages)20:10
micahgand is the previous behavior of backports20:10
micahgbroder: BTW, we can't do component matching in backports since the components change between releases20:13
micahgerr, what sources are where cahnges20:13
broderi know that's an issue. i had been led to believe it was possible for an archive admin to manually override component assignments when necessary20:14
broderalternatively, we could make the lp folks cry and have the component matching change between pre- and post- release20:14
micahgthat would work :)20:15
tumbleweedbroder: (re rev-build-deps) yeah agree about 404, I have uncommitted changes to do that, they'll land when I've finished with something else I'm hacking on20:16
tumbleweedbroder: thanks for the paste, I can work with that20:17
broderi'm not totally in love with the format, because i think it'll blow up quickly, so if you have ideas for improvements i'm open to them20:17
tumbleweedbroder: sure. Anyway, can't look right now, anyway20:19
* broder nods20:19
tumbleweedbroder: ok, error handling much improved, and can now do reverse-deps for all binaries produced by a source package. Implemented your example in requestbackport too22:47
brodertumbleweed: awesome. though i think you're using the source release for the backport to find r-deps, instead of the dest release22:52
broder./requestbackport libgdata tells me i need to test claws-mail-gdata-plugin, which isn't in oneiric22:52
tumbleweedoh, true22:53
tumbleweedI was doing that right, and then thought I wasn't because of an unrelated bug22:53
broderheh. and i would find it helpful to have blank entries for packages with no r-deps, just so that we can see at a glance that they've been considered22:53
tumbleweedit's hard thinking about reverse-anything22:54
tumbleweedeasy enough to add22:54
broderis it considering r-build-deps?22:55
broder(this looks awesome, though. i think having a standardized format for these things opens up a lot of possibility for speeding up and automating processing)22:56
tumbleweedshould be22:56
broderdoesn't seem to be catching them. reverse-depends src:libgdata doesn't either22:56
broderalso, "The report has not been changed, but you have to explain why the Ubuntu changes can be dropped." i assume that's from cargo-culting requestsync code? :)22:57
tumbleweedyou want reverse-depends -b src:libgdata22:58
tumbleweedheh, ok, so that needs refactoring :)22:58
broderah22:59
brodertumbleweed: line 122, you iterate over arch in ('any', 'source'), then hardcode 'any'23:01
broder(also explains why it was listing everything twice :-P)23:01
tumbleweedah, that's it23:03
tumbleweedthat's the bug I was going after right now, too23:03
tumbleweedr121823:04
broderawesome. oh, ugh. requestbackport -d natty libgdata seems to barf because the set of binary package names changed23:06
tumbleweeddo you think my web API for the rdepends service is reasonable? It's a good idea to get that kind of thing right before depending on it...23:08
tumbleweedah, easily solved with another defaultdict23:08
broderwell, that would build-in a reliance that a given binary is always provided by the same source, wouldn't it?23:08
broderi think to do this right you might have to get the list of binary packages for the source package you're backporting from, then do a arch=source and arch=any r-deps query for each of those23:10
broderinstead of using the src: query23:10
tumbleweedno, the problem here is simply a skew in binary names between source and target23:11
tumbleweedyou want to list all binary names, so I was trusting the source to be the same as all the targets23:12
tumbleweedthe src: query does exactly what you are suggesting23:12
broderare you sure? what happens if the package getting backported contains a binary that used to be provided by a different package (e.g. backporting git to when it was still called git-core)23:13
tumbleweedI don't see any reasonable way of solving that23:13
tumbleweedoh, right, sorry I misread your suggestion (1am...)23:13
broderno worries :)23:14
tumbleweedyeah, we could do that23:14
tumbleweedit'd be slower, of course23:14
broderright, more round trips23:15
tumbleweed(1am and a fair number of glasses of wine, perfect time for coding :P )23:15
broderwe *could* work around that by making it possible to pass multiple arguments to the rdepends service, though you couldn't use the REST-y scheme you have now to do that23:15
tumbleweedyeah, I've pushed that scheme about as far as it can go23:16
tumbleweedwould you even cosider a backport that builds a binary package also built by another source package (which is the only place where you'd expect to find reverse-dependencies that match this problem)23:18
broderi can imagine circumstances where i'd approve it23:21
brodere.g. a git backport, because gnuit/git didn't have any r-deps at the time23:21
tumbleweedis it worth the extra round trips?23:22
tumbleweedanyway, I pushed the defaultdict change23:24
broderi'd rather make the extra round trips and have the tool be correct. we can optimize for round trips later, but i don't want to have to clean up when we hit those corner cases23:41
tumbleweedbroder: ok, I get the feeling I may want to be clearer about the ignored dependencies (like you were in your example)23:54

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