[00:14] <dhillon-v10> hi all I need some help getting the source of a package with dget
[00:15] <andv> dhillon-v10, whats the problem?
[00:15] <dhillon-v10> andv: did you get my email
[00:15] <andv> dhillon-v10, yes, was finishing something
[00:16] <andv> dhillon-v10, anyway the verification failed is ok
[00:16] <andv> the package is signed by a key ID which is different from your key
[00:16] <andv> that's why it fails
[00:16] <dhillon-v10> andv: For that reason the ~ wasn't present
[00:17] <dhillon-v10> andv: I looked again and again in the control file, the ~ was absent
[00:18] <andv> dhillon-v10, I gave a dget -xu https://launchpad.net/ubuntu/+archive/primary/+files/livehttpheaders_0.15-0ubuntu1.dsc
[00:18] <andv> and it worked
[00:18] <andv> dhillon-v10, if it's absent just add it
[00:19] <dhillon-v10> for some strange reason it actually worked this time
[00:19] <dhillon-v10> thanks :)
[00:19] <andv> np
[00:19] <dhillon-v10> andv: again the ~ isn't present in build depends
[00:20] <andv> dhillon-v10, if it's not there add it
[00:20] <andv> yourself
[00:20] <dhillon-v10> okay that's the answer I was looking for, do you want for all instances :)
[00:20] <andv> make a debdiff and add it into the bug report
[00:20] <andv> :)
[00:21] <dhillon-v10> andv: this task was relatively easy but required carefully analysis thanks for you help
[00:23] <andv> np
[00:28] <dhillon-v10> alright done
[00:31] <dhillon-v10> how do I submit the patch now, just go to LP and attach it with the bug file
[00:50] <mruiz> hi all
[01:16] <james_w> thanks nxvl
[01:17] <zooko> Could I interest someone in uploading Tahoe-LAFS into Karmic?
[01:17] <zooko> It is all FFe'ed and approved and reviewed and good to go.
[01:33] <jtimberman> Can someone please review launchpad # 424576, to bump the chef version to match upstream?
[01:34] <jtimberman> i provided a debdiff on the ticket.
[01:34] <jtimberman> there's some important bug fixes in that release..
[01:38] <zooko> Oh, I see that iulian wanted to wait for a new version of pycryptopp: http://revu.ubuntuwire.com/p/tahoe-lafs
[02:06] <ScottK> jtimberman: Is it just bug fixes?
[02:20] <LaserJock> !info mpfr
[02:20] <LaserJock> !info libmpfr1
[02:20] <jtimberman> ScottK: yeah, think so. some important ones though per our CTO :)
[02:22] <ScottK> LaserJock: We're considering putting a small sampling of kdeedu apps on the netbook ISO (it's not limited to CD size).  I was wondering if you had any suggestions for what might be useful on a netbook?
[02:23] <LaserJock> ScottK: ktouch? :-)
[02:24] <ScottK> LaserJock: You tell me, you're the expert.  We can discuss on #kubuntu-netbook if you want.
[04:51] <arand> How to I grab bzr code from LP in a rush?
[04:59] <arand> nvm, found the lp howto
[06:32] <dholbach> good morning
[06:36] <fabrice_sp> Good morning dholbach !
[06:37] <dholbach> hiya fabrice_sp!
[06:38] <mruiz> guten morgen
[06:45] <mruiz> dholbach, thanks for the upload... since I came back, I have forgotten some things
[06:45] <dholbach> no worries :)
[06:46] <mruiz> dholbach, but I'm baaack
[06:47] <dholbach> :-)
[10:03] <slytherin> Can anyone please provide me with output of this command on a karmic installation - pkg-config --cflags libxul-embedding
[10:04] <jussi01> slytherin: http://paste.ubuntu.com/271377/
[10:05] <slytherin> jussi01: You need to install package xulrunner-dev.
[10:05] <dholbach> ttx is reviewing in #ubuntu-reviews
[10:06] <jussi01> slytherin: jussi@eagle:~$ pkg-config --cflags libxul-embedding
[10:06] <jussi01> -DXPCOM_GLUE -fshort-wchar -I/usr/include/xulrunner-1.9.1.3/stable
[10:07] <slytherin> jussi01: Thanks. This is missing nspr includes.
[10:07] <jussi01> yw
[10:07] <slytherin> asac: any idea why 'pkg-config --cflags libxul-embedding' does not include nspr headers? They were included in xulrunner 1.9.
[10:09] <asac> slytherin: yes.
[10:09] <asac> its bug 427638
[10:09] <asac> i am about to fix that
[10:10] <slytherin> asac: Thanks. I should have looked through the bugs.
[10:10] <asac> no problem
[10:11] <asac> i shoudl really fix this pronto ;)
[10:42] <alus> nginx released a security fix yesterday, at version 0.6.39. ubuntu base 9.04 still lists 0.6.35 in apt
[10:42] <alus> when will a new package be available?
[10:42] <slytherin> !sru | alus
[10:43] <hyperair> how does something enter <release>-security?
[10:43] <geser> someone prepares a patch (debdiff) and subscribes ~ubuntu-security and they review and sponsor it
[10:45] <alus> slytherin: I see information about the stable release update process.. I can't find any information about nginx here http://people.canonical.com/~ubuntu-archive/pending-sru.html
[10:45] <alus> http://qa.ubuntuwire.com/sru/todo.html is just blank
[10:45] <alus> nothing in launchpad says "nginx"
[10:46] <slytherin> alus: It was just released yesterday, wasn't it?
[10:46] <geser> alus: the pending sru page is for packages in -proposed which need to be tested before they go to -updates
[10:47] <alus> slytherin: yes.. and I could install it from source in less time than it has taken me to find out when it will be updated in apt
[10:47] <alus> slytherin: not to mention how long it would take someone to exploit it
[10:47] <alus> geser: so, is nginx just not in the queue, or should I look somewhere else?
[10:47] <geser> alus: someone needs to extract the needed changes from the new release and prepare a patch for it (-security only accept patches)
[10:48] <slytherin> Anyway, I am not from security team. So I can not comment on policies for security updates.
[10:48] <alus> geser: ah, well that would explain why it's several versions behind. what a pain
[10:48] <geser> alus: as nginx is in universe, someone from the community needs to prepare a security update for the package in jaunty
[10:49] <hyperair> slytherin: did you shift /usr/share/ant/lib/ant-proguard.jar?
[10:49] <alus> the developer prepared a new tarball. isn't there a nginx source tarball to .deb script?
[10:49] <hyperair> slytherin: what should i be using instead, then?
[10:50] <alus> how did it get in apt in the first place? did someone do it by hand and then throw away the process they used to do that?
[10:51] <geser> alus: the "source package" contains infomation how to build it from the tarball, but it might need some changes for the new upstream version
[10:52] <geser> alus: but no new tarballs are accepted for -security, one needs to extract the patch for the security issue and apply it on the version that's currently in the archive
[10:53] <alus> that seems far more error prone, and much slower
[10:53] <hyperair> alus: it's about auditing the changes
[10:53] <alus> by applying the same process that was applied to the original diff, and diffing the results, you could produce this patch
[10:54] <alus> hyperair: the package maintainers did not write the software, and the original developer had a bug. I don't expect anybody will find anything useful
[10:54] <geser> alus: and the risk for regressions is much smaller if you only fix the security problem
[10:54] <alus> the risk of introducing new problems seems higher
[10:54] <alus> nobody involved is the original developer, and knows the codebase
[10:55] <geser> alus: but the developer doesn't obviously know how to write secure software (else the problem wouldn't rise) so some review from security aware people is good
[10:56] <alus> uh
[10:56] <alus> the security aware people obviously don't know how to write a tiny, fast webserver either
[10:57] <alus> and why didn't the security aware people catch the bug when they accepted the nginx version they had already?
[10:57] <alus> they can verify that the patch fixes the bug, but that has already been verified
[10:58] <geser> because nobody reviews every line of code before it lands in Ubuntu
[10:58] <hyperair> alus: <release>-security exists ONLY for pushing security updates. packages accepted into the UNSTABLE version of ubuntu is not audited by the same security team
[10:58] <alus> but maybe only if you use the tarball as it appears on the developer's website
[10:59] <hyperair> that's why the patch has to be isolated, put onto the existing jaunty package, and tested again
[10:59] <alus> hyperair: so, fixes to software that was never reviewed are delayed by "-security"
[10:59] <geser> alus: how sure are you that the new tarball doesn't introduce any other bugs which aren't currently in the version in jaunty?
[10:59] <alus> leaving vulnerable systems out there in the wild for longer?
[10:59] <alus> geser: how are you sure that the new tarball isn't better?
[10:59] <hyperair> alus: please remember that when an ubuntu version is released, the archive is frozen.
[11:00] <hyperair> alus: hence every change done must be tested intensively to make sure there are no regressions
[11:00] <geser> alus: I'm not sure, it probably even is
[11:01] <alus> this process seems overly cautious to prevent possible breakage, while ensuring it prolongs actual breakage
[11:01] <hyperair> alus: then file a bug, isolate the patch, and get it in
[11:01] <hyperair> alus: it's not overly cautious, it's a necessary measure.
[11:02] <alus> honestly, it's easier for me to ignore apt and install it from source
[11:02] <alus> and that's far more work than I want to do
[11:02] <wgrant> New versions *do* break things.
[11:02] <wgrant> And that's a lot of users to break.
[11:02] <wgrant> So a minimal, obvious, well-tested patch is essential.
[11:02] <alus> it's not a new-feature release. it's a update to the "legacy-stable" version of nginx
[11:03] <wgrant> Then the patch should be simple to isolate.
[11:03] <alus> wgrant: that is overly demanding for a package management system. software packages develop however they like
[11:03] <alus> and as I use I would like to install them
[11:03] <alus> so the package management system is in the way
[11:04] <geser> alus: don't forget that those rules apply to all packages and not only nginx, so they might more strict than necessary in this specific case
[11:04] <alus> if a user does not upgrade, their publicly facing webserver is vulnerable. it's quite easy to find out if a website uses a vulnerable version
[11:04] <wgrant> alus: Feel free to isolate the patch and get an update pushed out.
[11:04] <wgrant> It shouldn't take long.
[11:05] <alus> it's all new to me. it would take quite a while
[11:05] <alus> I know how to install from a tarball. that takes no time at all
[11:06] <hyperair> Andres Rodriguez <andreserl<at>ubuntu.com>
[11:06] <hyperair> that's the last person who uploaded.
[11:06] <hyperair> you could contact him
[11:07] <hyperair> looking at the changelog, he seems to be handling all the syncs/merges of nginx in ubuntu from debian
[11:07] <slytherin> hyperair: read README.Debian. :-)
[11:07] <hyperair> slytherin: ah thanks
[11:11] <slytherin> hyperair: Actually I removed the symlink as recommended by upstream documentation and because of past bad experiences to to presence of such symlinks.
[11:11] <slytherin> hyperair: I will try to push this in Debian policy.
[11:11] <hyperair> i see
[11:11] <hyperair> okay
[11:12] <alus> hyperair: ok, I sent him an email
[11:12] <alus> thanks guys.
[12:22] <moldy> hi
[12:23] <moldy> i want to create a new version of an ubuntu package including a new version of the upstream sources
[12:24] <moldy> are there some tools that can save me from doing all the packaging work again, by including information from the previous version, just bumping the upstream version number?
[12:26] <moldy> i'm not sure how to handle the "new upstream version" case at alll... if anyone could point me to some docs, that would be great
[12:28] <porthose_> https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[12:28] <moldy> porthose_: thank you, just found that
[12:29] <moldy> porthose_: at the "dch -i" step, i should change the upsrteam and ubuntu version manually?
[12:29] <moldy> porthose_: dch does not seem to detect it by itself
[12:30] <porthose_> depends on what you want to do if you are packaging for debian then no if you are packaging it for ubuntu the yes
[12:30] <porthose_> the/then
[12:30] <moldy> packaging for ubuntu
[12:31] <moldy> well, dch does not seem to realize there is a new upstream version at all, that's why i am asking
[12:31] <moldy> it still says "1.0dev1" instead of "1.0dev2"
[12:33] <porthose_> then I would say your changelog entry is incorrect
[12:34] <moldy> hm, in what regard?
[12:34] <moldy> put differently: how does dch detect the fact that there is a new upstream version?
[12:34] <moldy> as far as i understand, it only seems to try to do this when using the -d option
[12:35] <pochu> dch -v '1.2.3-1'
[12:36]  * porthose_ goes and finds some coffee *yawn*
[12:36] <moldy> pochu: ah, so i should so something like "dch -v 1.0dev2-0ubuntu1"?
[12:36] <pochu> I think so
[12:36] <moldy> pochu: ok, thanks
[13:05] <nicolasvw> How can one package an application for which upstream only provides svn and no release tarballs?
[13:30] <slytherin> nicolasvw: create your own tarball.
[13:49] <qnix> Hi, Feature Freeze disallows any package version upgrade, right?
[13:52] <oreon> sera
[13:52] <sistpoty|work> qnix: it means that new features need to get approved first
[13:52] <sistpoty|work> qnix: (and hence need to be justified)
[13:52] <qnix> sistpoty|work: so I can still ask to sync a package with debian unstable ?
[13:53] <sistpoty|work> qnix: yes, but if it introduced new features, than you should get a FFe first ;)
[13:53] <qnix> kk :P
[14:41] <nicolasvw> slytherin: thank, I'll do it that way.
[15:06] <bddebian> Heya gang
[15:06] <sistpoty|work> hi bddebian
[15:07] <bddebian> Heya sistpoty|work
[15:13] <sebner> huhi bddebian sistpoty|work :)
[15:13] <sistpoty|work> hi sebner
[15:16] <qnix> why dh_install reports me: dh_install: usr/include/gdal/gdal_proxy.h exists in debian/tmp but is not installed to anywhere
[15:16] <qnix> but if I do a dpkg-deb -c myfile.deb, the file is present
[15:22] <bddebian> AnAnt: Sorry I missed you the other day, do you still want/need me to look at something?
[15:23] <AnAnt> Hello, for some reason mdbtools in karmic doesn't work, yet the one from Debian (please look at LP 430057) worked for me
[15:23] <AnAnt> bddebian: yeah
[15:23] <AnAnt> bddebian: gplcver
[15:23] <jbernard_> nixternal: is the next membership meeting on the 24th? if so I'll be happy to update the wiki, it still says the 9th at the moment
[15:23] <bddebian> AnAnt: Is it still on mentors?
[15:24] <AnAnt> bddebian: yup
[15:24] <AnAnt> it's an NMU
[15:24] <AnAnt> http://mentors.debian.net/debian/pool/main/g/gplcver/gplcver_2.12a-1.1.dsc
[15:34] <bddebian> AnAnt: You haven't posted your patch or an NMU to BTS.  Have you tried to contact the maintainer?
[15:36] <AnAnt> bddebian: I did  try to contact him for another reason, and got no reply
[15:37] <AnAnt> bddebian: on Aug, 10th
[15:37] <AnAnt> bddebian: yet the maintainer seems to be active till at least july of this year according to his QA page
[16:00] <jtimberman> I need two MOTU to ACK FFE for new upstream version of Chef (0.7.10) which fixes some important bugs from 0.7.8: https://bugs.launchpad.net/ubuntu/+source/chef/+bug/424576
[16:06] <mathiaz> jtimberman: you need to two members of the motu-release team to give an ACK for a FFe.
[16:07] <mathiaz> jtimberman: see https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions%20for%20Universe/Multiverse
[16:07] <mathiaz> jtimberman: I've subscribed motu-release to the bug
[16:08] <jtimberman> mathiaz: cool. also need libmixlib-config-ruby updated to upstream release 1.0.12, bug link is: https://bugs.launchpad.net/ubuntu/+source/libmixlib-config-ruby/+bug/420674
[16:08] <jtimberman> should i add motu-release to that one too?
[16:10] <mathiaz> jtimberman: nope - as it's a bug fix only
[16:10] <mathiaz> jtimberman: you should seek sponsorship though - https://wiki.ubuntu.com/SponsorshipProcess
[16:10] <jtimberman> mathiaz: alrighty.
[16:10] <mathiaz> jtimberman: we're in FeatureFreeze - so new features need to be acked
[16:10] <mathiaz> jtimberman: if it a bug fix only upstream release then it can go in
[16:11] <jtimberman> Right.
[16:11] <mathiaz> jtimberman: but you'll always need sponsorship since you don't have upload rights.
[16:11] <jtimberman> mathiaz: gotcha.
[16:11] <jtimberman> subscribed ubuntu-universe-sponsors to it.
[16:17] <mathiaz> jtimberman: are you planning to push the update to debian as weel?
[16:17] <mathiaz> jtimberman: *well*
[16:17] <mathiaz> jtimberman: it may be easier to get it uploaded to debian and then ask for a sync in ubuntu
[16:19] <jtimberman> mathiaz: it should go in debian too, yes, as the 0.7.10 is what i'm currently trying to get into debian now.
[16:20] <mathiaz> jtimberman: I'm refering to libmixlib-config-ruby
[16:20] <jtimberman> mathiaz: right, mixlib-config 1.0.12 is required for chef 0.7.10:)
[16:21] <mathiaz> jtimberman: right - since mixlib-config is already in debian, it may be easier to get the new version in debian
[16:21] <jtimberman> mathiaz: DEHS shows 1.0.12: http://dehs.alioth.debian.org/report.php?package=libmixlib-config-ruby
[16:21] <mathiaz> jtimberman: and then ask for a sync
[16:22] <mathiaz> jtimberman: in ubuntu
[16:22] <jtimberman> mathiaz: okay, pinging a DD :)
[16:22] <mathiaz> jtimberman: otherwise you'll have to redo the mixlib-config debdiff to follow the ubuntu convention
[16:23] <jtimberman> oh, is my debdiff debianized?
[16:23]  * jtimberman should make a separate sbuild server for debian 
[16:23] <jtimberman> or something.
[16:24] <mathiaz> jtimberman: well first - it's been generated the wrong way
[16:24] <mathiaz> jtimberman: and then the version number is a debian number - it ubuntu it would be 1.0.12-0ubuntu1
[16:24] <jtimberman> gotcha.
[16:24] <jtimberman> well i'll see if thom will upload to debian again :)
[16:24] <mathiaz> jtimberman: and the maintainer field would have to be updated - per https://wiki.ubuntu.com/DebianMaintainerField
[16:25] <mathiaz> jtimberman: if you can get it in debian it would be much better.
[16:25] <jtimberman> mathiaz: indeed. working on that.
[16:26] <jtimberman> mathiaz: do i turn the launchpad bug into a sync request, or close it and open a new bug?
[16:26] <mathiaz> jtimberman: leave it open for now.
[16:26] <mathiaz> jtimberman: *once* the new upstream version is in debian, I'd suggest to turn the bug in a sync request
[16:26] <mathiaz> jtimberman: following https://wiki.ubuntu.com/SyncRequestProcess
[16:27] <mathiaz> jtimberman: and asking sponsorship again since you don't have upload rights
[16:28] <jtimberman> mathiaz: alrighty.
[17:30] <jtimberman> mathiaz: libmixlib-config-ruby 1.0.12 uploaded, accepted: http://packages.qa.debian.org/libm/libmixlib-config-ruby/news/20090915T161725Z.html
[17:34] <Riddell> YokoZar: ping
[17:35] <Riddell> YokoZar: springlobby has a debian/copyright which mentions  src/boost but there's no such directory
[17:35] <Riddell> I could accept and file a bug but I'd prefer to reject and have it uploaded correctly
[17:55] <RoAkSoAx> hey guys what to do in a case where solving a FTBFS, after debuild -S and doing a debdiff between the debian and the ubuntu revision, changes in config.guess and config.sub are showed? these changes are also showed in the diff.gz
[17:56]  * sebner has a deja-vù :)
[17:57] <christoph_debian> RoAkSoAx: maybe working with filterdiff helps?
[18:01] <RoAkSoAx> rigth, the thing is that AFAIK, changes in config.guess and config.sub should not be showed, but still, they are
[18:02] <randomaction> iirc the solution was to rm -f them in debian/rules clean target
[18:03] <sebner> RoAkSoAx: delete that stuff from the debdiff
[18:04] <RoAkSoAx> sebner, I did. Then I did a apt-get source package, applied that debdiff to the sourcepackage, debuild -S and changes were showed again...
[18:04] <christoph_debian> I'd ask the debian maintainer to fix it on the way as you're opening a bug anyway
[18:05] <sebner> RoAkSoAx: not wondering because that stuff gets generated evidently anytime. Show me the rules file
[18:05] <RoAkSoAx> sebner, http://pastebin.ubuntu.com/271548/
[18:06] <sebner> RoAkSoAx: remove that stuff: http://paste.ubuntu.com/271567/
[18:06] <RoAkSoAx> sebner, I did, and the same :)
[18:07] <sebner> what a evil package :P
[18:08] <RoAkSoAx> sebner, haha yeah I've already found 2 with the same issue :) :S
[18:09] <RoAkSoAx> I'll keep investigating though :)
[18:09] <sebner> RoAkSoAx: sorry I couldn't help :\
[18:09] <RoAkSoAx> sebner, no prob :)
[18:10] <christoph_debian> RoAkSoAx: did you remove the copying on the same tree you already did the debuild -S ?
[18:13] <RoAkSoAx> christoph_debian, yep, I keep downloading the source again and again and get the same result. I'm gonna try it again step by step to see what can I be doing wrong :)
[18:15] <christoph_debian> RoAkSoAx: if you called debuild -S once before removing the parts from rules it can't work if you get the same still with removing it from rules first I'll get that source package and see why it does impossible things ;)
[18:16] <RoAkSoAx> christoph_debian, maybe that's it, that's why i'm doing it changing my steps :) thanks for the advice
[18:19] <RoAkSoAx> weird, now I don't get the config.{sub,guess} changes but I do get changes in  .pc/.version :s
[18:22] <RoAkSoAx> finally, no undesired changed
[20:07] <tag> Just how unstable is karmic right now? :-)
[20:07] <directhex> very
[20:07] <tag> Crappy
[21:31] <Mabo> hi
[22:00] <hjmf> please take a look to bug #430272
[22:02] <directhex> hjmf, "Topic for #ubuntu-devel is: Neither karmic nor the buildds are in a happy place right now, things are being sorted"
[22:17] <mruiz> Hi... Why some packages are not available at merges.ubuntu.com ?
[22:19] <sebner> mruiz: define "some packages", most packages are syncs so don't need to be merged
[22:19] <mruiz> sebner, for instance gaphor . It needs a merge
[22:21] <sebner> mruiz: right, interesting
[22:21] <sebner> mruiz: you should more worry if it'd need a FFe though
[22:23] <ScottK> jtimberman: Chef FFe is approved.
[22:24] <jtimberman> ScottK: Thanks :)
[22:24] <jpds> mruiz: Maybe the autosyncs have been disabled and thus it's stopped syncing?
[22:24] <jtimberman> ScottK: libmixlib-config-ruby update uploaded to debian earlier today, that should be bumped in ubuntu karmic too
[22:24] <jpds> And then not checking for merges?
[22:24] <ScottK> jpds: It's supposed to keep checking.
[22:25] <ScottK> jtimberman: You'll need to file a sync request and seek sponsorship through the normal process for that.
[22:25] <jpds> ScottK: Dunno myself. I thought it stopped after DIF.
[22:26] <ScottK> jpds: No.  It being stopped was one reason that DaD existed.  Part of the agreement for killing DaD was it would keep running.
[22:36] <Ng> if I'm doing python distutils and cdbs, how would I add something to the postinst without losing the automatically generated one?
[22:36] <Ng> I don't appear to be able to instruct any quick magic to register my gconf schema for me, so I need to do that in the postinst afaict
[22:36] <Ng> (and presumably deregister it in the prerm)
[22:44] <Riddell> Ng: adding <packagename>.postinst into debian/rules should do it, cdbs/debhelper will merge in its own stuff at the end
[22:45] <mathiaz> Ng: have you looked at dh_gconf?
[22:47] <Ng> mathiaz: can I just drop that into my debian/rules after the cdbs includes?
[22:49] <mathiaz> Ng: yes - at binary-install/package-name::
[22:49] <mathiaz> Ng: something like that:
[22:49] <Laney> Daviey: Yo, just looking at your change. Where does the db-pending-config file come from?
[22:50] <mathiaz> Ng: http://paste.ubuntu.com/271731/
[22:50] <mathiaz> Ng: look into /usr/share/cdbs/1/class/gnome.mk
[22:51] <mathiaz> Ng: to see how the gnome cdbs class uses dh_gconf
[22:51] <Ng> mathiaz: thanks
[22:51] <Ng> you guys are always incredibly helpful :)
[23:53] <jtimberman> libmixlib-config-ruby ready to sync from debian sid/main