[01:56] <nigelb> any python experts around.  I need to confirm that all references to pychecker are removed from boa constructor
[01:56] <nigelb> I took a good look at the code and it seems okay.
[03:30] <lfaraone> For packages which lack upstream releases, but instead consist entirely of git snapshots, is this a good version schema: 20100222.git6805c07-0ubuntu1?
[04:40] <ripps> I want to help with some ftbfs packages, but do I have to create a bug and debdiff for every package I want to fix? And if I do, how can I be sure that anybody is going to notice it?
[04:45] <crimsun> lfaraone: I tend to avoid leading dates and instead use 0.date, but it isn't that big a deal
[04:45] <lfaraone> crimsun: yeah, I went with 0+gitDATE.REF-1
[04:46] <lfaraone> crimsun: unrelated, would http://www.cgsecurity.org/wiki/CmosPwd be too trivial to package? (compiles and runs nicely)
[04:47] <AnAnt> is it possible to test a plymouth theme on karmic ?
[04:47] <ScottK> ripps: Yes.  You do.  There are no guarantees, but sponsors try really hard to get through all the potential uploads before release.  Almost always we do.
[04:47] <ScottK> ripps: Alternatively you can propose fixes as bzr branches and make merge requests.
[04:47] <crimsun> lfaraone: "too trivial" doesn't really exist ;-)
[04:48] <lfaraone> crimsun: mk. upstream ships a binary in their tarball, but they include source. Should I repack to remove the binary version, or not worry about it?
[04:48] <crimsun> I would repack it.
[05:01] <jayvee> G'day. I have a bug fix for libvirt that I'd like to get in to Lucid (and Karmic, if possible). Any pointers on what I should do, or who I should ping?
[05:01] <jayvee> It's a patch for un-breaking IPv6 on the libvirt network bridge.
[05:10] <crimsun> jayvee: please file a bug against the libvirt source package
[05:11] <jayvee> crimsun: cool, will do
[05:11] <jayvee> crimsun: what should I attach? just the patch, or a debdiff, or what?
[05:12] <crimsun> jayvee: a debdiff would be ideal, but a unified diff would do, too.
[05:12] <crimsun> (the reviewers team is flexible)
[05:12] <jayvee> crimsun: debdiffs contain changelogs, don't they? does it matter what I put as the changelog, or version number? :)
[05:13] <crimsun> jayvee: correct, and yes (to both)
[05:13] <jayvee> Lucid's current version of libvirt is 0.7.5-5ubuntu7. So what should the new version number be? In my PPA, it is 0.7.5-5ubuntu8~ppa1.
[05:14] <crimsun>    libvirt | 0.7.5-5ubuntu8 |         lucid | source
[05:15] <jayvee> cool
[05:15] <jayvee> and I spose I should reference the LP# bug number in the changelog description, right?
[05:15] <crimsun> so you'd want 0.7.5-5ubuntu9, and yes
[05:16] <jayvee> hmm, they seem to have updated libvirt since a few days ago :)
[05:16] <jayvee> Sorry for the stupid questions — I'm still quite new to this.
[05:16] <jayvee> Just want to make sure I get it right.
[05:17] <crimsun> no prob
[05:24] <AnAnt> why does plymouth conflict with usplash ?
[05:25] <jayvee> AnAnt: because they're competing splash screen mechanisms
[06:28] <AnAnt_> jayvee: what do you mean by competing ?
[06:28] <jayvee> AnAnt_: well, maybe not competing, but alternative
[06:28] <jayvee> they're both splash screen engines
[06:28] <jayvee> you want to use one or the other
[06:28] <AnAnt_> jayvee: yes, I know, but that's not a reason to make them conflict
[06:29] <jayvee> of course it is
[06:29] <jayvee> otherwise they would both install themselves to launch at bootup
[06:29] <jayvee> then they would fight for the display
[06:29] <AnAnt_> jayvee: ah, I see
[06:29] <jayvee> all "Conflicts" does is tell the package manager to only install one or the other, not both at the same time
[06:34] <AnAnt> ah, they both provide /lib/init/splash-functions
[06:35] <AnAnt> ok, how can I test a plymouth theme ?
[06:35] <randomaction> sgnb: I would guess Monday, but it may be better to ping some archive admins here and on #ubuntu-devel
[06:36] <jayvee> AnAnt: well you could always install plymouth ;)
[06:36]  * jayvee presumes plymouth is in the ubuntu repo somewhere
[06:36] <AnAnt> jayvee: I did, what I mean  is that in usplash & xsplash, I can test the theme without rebooting
[06:37] <jayvee> well there's a plymouth command for that as well
[06:37] <jayvee> I believe you just start the daemon with the right parameters
[06:37] <AnAnt> ah, found it
[06:37] <jayvee> it's been a while since I've played with it, to be honest
[06:43] <randomaction> slangasek: could you sync gmetadom (bug 526067) and ocaml-expat (bug 527633) for ocaml transition?
[06:44] <AnAnt> thanks
[08:25] <jariq> I've just tried "pbuilder-dist sid mainonly create" after a week and it still fails with " -> installing dummy policy-rc.d chroot: cannot run command `/usr/bin/apt-get': No such file or directory". Any ideas?
[08:33] <jariq> Just found debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564910 . I see that new pbuilder (0.196) and debootstrap (1.0.20) are already in lucid, so I guess it is tome to dist-upgrade my desktop :)
[09:31] <arand> Is cdbs something you need to install separately, it's not a recommends to any other higher-level package?
[09:50] <jayvee> arand: if a package needs cdbs, it should list it in its Build-Depends, as far as I knkow
[09:50] <jayvee> it's a dependency of quilt, though
[09:51] <arand> I was just surprised I needed it for debuild -S on nautilus...
[09:51] <jayvee> did you apt-get build-dep nautilus?
[09:52] <arand> jayvee: And actually it isn't... only "enhancing"
[09:53] <arand> I prefer to let pbuilder handle all of that..
[10:07] <geser> arand: you need some build-deps installed to be able to run "debuild -S" (those needed to run the clean target and those from "include" in debian/rules)
[10:09] <arand> Yea, I'm guessing it was the auto-* that got pulled in along with cdbs that was the crux, just never stumbled upon needing more than ubuntu-dev-tools and debhelper..
[10:24] <jayvee> nah, you definitely need build-deps
[10:27] <geser> it depends on what you want to do: for just building a source package (that is then build by pbuilder) a subset of the build-dependencies is enough, for building also the binary debs you need all build-dependencies installed
[10:48] <jariq> I am trying to build package for sid on lucid. Is lintian in lucid ubuntu specific or is it the same as the one in debian? Is it ok to build source package for debian on ubuntu?
[10:49] <lifeless> jariq: its the debian lintian, and you can rebuild yes
[10:53] <jariq> lifeless: so I can create package on ubuntu without any doubts and submit it to debian mentors?
[10:56] <lifeless> if you're submitting stuff to mentors, make sure it builds in a sid chroot
[10:56] <lifeless> thats good practice even if you were running debian yourself
[10:57] <jariq> allready done that with pbuilder
[10:57] <lifeless> the debsign the pbuilder output and upload that :)
[11:07] <jayvee> lifeless, crimsun: just filed https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/528934
[11:07] <jayvee> many thanks for the guidance
[13:31] <eagles0513875> hey guys how are you all doing today. i have the amarok 2.3 code pulled from git and im trying to figure out how to package it. im looking at the wiki and it seems like all the packaging documentation is for packages that already exist with a change log .dsc file etc. however the amarok code that i have doesnt contain any of that. where in the documentation does it show me where to add those
[13:31] <eagles0513875> missing files
[13:32] <persia> eagles0513875: You don't want to do it that way :)
[13:33] <eagles0513875> persia: how can i go about packaging something that doesnt have those files so i have it in my ppa. not to mention the current amarok lucid version has some non working features which are fixed in current compilation that i have
[13:34] <persia> Firstly, you probably want to contact the amarok team about it, as some of them are quite adept at packaging.  Secondly, where they can't help, the kubuntu team is likely most helpful, thirdly, we're past FeatureFreeze, so it's unlikely any new versions not already discussed between those groups would be suitable for inclusion in the in-development release of Ubuntu (lucid).
[13:34] <persia> We don't provide PPA support in this channel (and no, I don't know where to send you, as #launchpad doesn't provide support for packaging).
[13:35] <eagles0513875> persia: humm :( ok so you recommend i ask for packaging help in amarok instead
[13:35] <persia> But if you really want to push on it, take a look at https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[13:35] <persia> (and it's still not "missing files")
[13:36] <eagles0513875> persia: i have the git code of amarok that i would like to package but it doesnt have a change log .dsc file is what i ment
[13:36] <persia> eagles0513875: No.  I recommend you talk to the amarok team about outstanding issues you discovered in lucid, and how to best address them.
[13:36] <eagles0513875> humm ok
[13:36] <persia> I do not expect they would give you packaging help, but they are far more iikely to help you resolve outstanding issues.
[13:36] <persia> (and the goal should really be to fix the bugs, not to package stuff).
[13:37] <persia> You may need to learn some packaging to fix bugs, depending on the nature of the bugs, but this is separate.
[13:37] <eagles0513875> thing right now is im wanting to learn how to package as i am quite limited in regards to programming knowledge
[13:37] <persia> And you'd just be wasting your time (and any teacher's time) using an updated version of an existing package to learn to package someting.
[13:37] <persia> In my opinion the best way to learn to package is to work with packages.
[13:38] <eagles0513875> ok
[13:38] <persia> And the best way to work with packages is to fix bugs in packages.
[13:38] <persia> So go look for bugs that appear to just be packaging bugs, and see if you can fix them by fiddling with debian/control and debian/rules.
[13:38] <persia> (or somettimes other debian/ files, but *not* debian/patches/*)
[13:39] <shadeslayer> hmmm weird
[13:40] <shadeslayer> my package fails to build even when i have libfixes as a build dep
[13:41] <shadeslayer> http://launchpadlibrarian.net/39853218/buildlog_ubuntu-lucid-i386.recorditnow_0.7%2Bgit20100227-0ubuntu0~ppa4_FAILEDTOBUILD.txt.gz
[13:42] <eagles0513875> persia: question for you if i build a package locally do i just upload it to my repository and then put what ppa repository of mine its in? on the bug
[13:43] <shadeslayer> eagles0513875: youll have to upload the source not the package ;)
[13:44] <eagles0513875> shadeslayer: ok i need to back track one thing at a time hehe
[13:44] <shadeslayer> eagles0513875: whatcha doing ? :P
[13:45] <persia> eagles0513875: I recommend building sources, adn building binaries locally.  I think it's a complete waste of time to provide either full sources or binaries in a bug: in 99% of cases, patches are more interesting.
[13:46] <persia> And most of the remaining 1% is stuff like image changes, sound alternations, etc.
[13:46] <eagles0513875> persia: i think im starting to jump the gun a bit
[13:46] <eagles0513875> i need to back track fix a package and build it and test it out and then go from there
[13:47]  * shadeslayer is still wondering what build-deps to add
[13:47] <persia> eagles0513875: OK.  Go find a triaged bug with the "packaging" and "bitesize" tags.
[13:47] <eagles0513875> hehe
[13:47] <persia> eagles0513875: Fix the bug, and then play with building source and binaries, etc.
[13:48] <persia> Ask here about building the source and binares when you get to that point.
[13:48] <eagles0513875> persia: ok
[13:48] <persia> If you can't find a good bug, I recommend working in bugsquad for a while: that both exposes you to lots of bugs *and* helps you develop an understanding of which bugs are easy vs. hard, and where they ought be fixed.
[13:48] <nigelb> eagles0513875: +1 to working with bug squad
[13:49] <eagles0513875> persia: mind if i pm you i have a question which doesnt pertain to this channel
[13:49] <persia> You may find that the following are helpful links.
[13:49] <persia> !sbuild
[13:49] <eagles0513875> nigelb: i am already a member of bugsquad btw
[13:49] <persia> !pbuilder
[13:49]  * slytherin is glad i18n is finally working. :-)
[13:49] <eagles0513875> nigelb: i think it was your name that was in the email teling me that my membership was about to expire or am i mistaken
[13:49] <nigelb> eagles0513875: definitely not me!
[13:49]  * persia can vouch for eagles0513875 having worked in bugsquad, and didn't mean that as a "go join another team" admonition, but as a suggestion on a good way to find the target bug.
[13:50] <eagles0513875> persia: i didnt take it that way
[13:50] <eagles0513875> i just need to make sure my membership doesnt expire
[13:50] <nigelb> eagles0513875: I started fixing bugs after finding some easy bugs when triaging ;)
[13:50] <persia> eagles0513875: I know, but I wanted to make sure everyone else didn't take it that way too :)
[13:50] <eagles0513875> ahh ok persia
[13:51]  * nigelb goes to fix a failed to build
[13:51]  * shadeslayer follows suit
[13:55] <nigelb> I'm trying to fix a build dep and this is one file that calls pychecker.  http://paste.ubuntu.com/385081/ the file name of this file is pychecker_custom.py.  this file is referenced in another file PythonControllers.py http://paste.ubuntu.com/385080/, the second file is patched to deal with pychecker not being installed.  Should I delete the first file?
[13:59] <persia> nigelb: Is that pastebin the *entire* file?
[13:59] <nigelb> yeah
[13:59] <persia> I think you either have to patch that file, or if you remove it, need to track down what calls into that file, and patch that.  The former is probably easier.
[14:00] <persia> Were you able to catch DktrKranz?
[14:00] <nigelb> the calls to the file is already patched
[14:00] <nigelb> he commented on the bug to either patch or remove
[14:01] <nigelb> but if you see the second file, where it calls pychecker_custom.py, you can see that its already patched to deal with pychecker not being there
[14:01] <persia> I'd probably patch just in case something got missed, but it may be safe to remove.
[14:01] <nigelb> precisely line 165 of second pastebin
[14:02] <persia> sys.exit(exitcode) vs. sys.exit(127) doesn't look like a safe way to continue operation, *and* I have no idea if a failed import raises an exception.
[14:02] <DktrKranz> ImportError, yest
[14:02] <DktrKranz> *yes
[14:02] <nigelb> ah, you're around :)
[14:02] <DktrKranz> nigelb: if you want remove that file, debian/rules alredy exclude some
[14:03] <DktrKranz> so you could want to use that too
[14:03] <nigelb> DktrKranz: I feel it would be safe not to remove
[14:03] <nigelb> my feeling is the calls to custom_pychecker.py is patched to deal with not having pychecker around
[14:05] <nigelb> what do you think?
[14:05] <DktrKranz> ExternalLib files are somehow self-contained, so it's not an issue anyway
[14:05] <DktrKranz> I excluded some to avoid distributing convenience copies of other modules
[14:06] <nigelb> so I just remove pychecker from depends and it should be fine?  you want me to delete that file?
[14:06] <shadeslayer> hmm any ideas on this ? : http://launchpadlibrarian.net/39854860/buildlog_ubuntu-lucid-i386.recorditnow_0.7%2Bgit20100227-0ubuntu0~ppa5_FAILEDTOBUILD.txt.gz
[14:08] <DktrKranz> nigelb: it should be fine just to remove dependency for now.
[14:09] <nigelb> DktrKranz: thanks.  Will fix and upload new debdiff in a few :)
[14:09] <DktrKranz> ping me if you need a sponsor
[14:09] <nigelb> okay :)
[14:10] <slytherin> Anybody from SRU team around? I need to discuss about gst-plugins-ugly-multiverse0.10 package.
[14:15] <shadeslayer> anyone around to help me with : http://launchpadlibrarian.net/39854860/buildlog_ubuntu-lucid-i386.recorditnow_0.7%2Bgit20100227-0ubuntu0~ppa5_FAILEDTOBUILD.txt.gz
[14:19] <randomaction> shadeslayer: missing build-dep on libxcursor-dev?
[14:19] <shadeslayer> randomaction: um... lemme se
[14:27] <nigelb> DktrKranz: I've upload the new debdiff.  Could you sponsor it?
[14:28] <DktrKranz> nigelb: I'll have a look in some minutes
[14:29] <nigelb> thank you :)
[14:30] <shadeslayer> randomaction: ah thanks its compiling
[14:32] <shadeslayer> randomaction: it still fails : http://launchpadlibrarian.net/39855619/buildlog_ubuntu-lucid-i386.recorditnow_0.7%2Bgit20100227-0ubuntu0~ppa6_FAILEDTOBUILD.txt.gz
[14:32] <shadeslayer> randomaction: apparently it failed at :  X11/extensions/shape.h
[14:32] <shadeslayer> it couldnt find it
[14:36] <eagles0513875> you guys know of any issues with launchpad and uploading pgp keys to users p rofile
[14:37] <shadeslayer> eagles0513875: nope..
[14:37] <eagles0513875> strange
[14:37] <shadeslayer> eagles0513875: #launchpad would know more
[14:37] <eagles0513875> my key hasnt been uploaded to my profile
[14:37] <eagles0513875> nobody is in there :(
[14:39] <cemc> hi. I'm trying to build something with pbuilder, 64bit host, 32bit lucid pbuilder, and I'm getting this: http://pastebin.ubuntu.com/385104/ . any ideas on what this could be ?
[14:40] <shadeslayer> eagles0513875: that can take time
[14:40] <eagles0513875> says up to 10 min and its been longer then that
[14:40] <shadeslayer> try waiting for 25 mins
[14:40] <shadeslayer> eagles0513875: nope
[14:40] <eagles0513875> its been 40 min
[14:41] <shadeslayer> eagles0513875: https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[14:42] <eagles0513875> i have the key and i pushed it to the key server
[14:42] <shadeslayer> eagles0513875: look at the bottom
[14:44] <randomaction> shadeslayer: you need another build-dep then
[14:44] <shadeslayer> randomaction: which one?
[14:45] <randomaction> search with apt-file or at packages.ubuntu.com
[15:47] <eagles0513875> hey persia what kinda bugs am i looking for to try package with
[16:32] <strycore> Hi there !
[16:34] <strycore> so I got a question about packaging inkscape
[16:34] <strycore> 0.48 seems to use autotools
[16:35] <strycore> so I had to add ./autogen.sh in the config.status rule
[16:36] <strycore> but then when it does "build", it chokes on cd po; intltool-update -p
[16:37] <strycore> because some files don't exist in some folder , these files are generated by Makefile
[16:38] <strycore> I tries to move this line after the build part but I wonder if it's the correct way to do it
[16:39] <strycore> s/tries/tried
[16:39] <strycore> it's still compiling right now so I will see if it works in a few minutes
[17:36]  * strycore summons the powers of the Masters Of The Universe
[17:39] <hyperair> strycore: you called?
[17:39] <strycore> ah yes :)
[17:40] <shadeslayer> hehe
[17:40] <strycore> so, like I said, I was trying to package inkscape 0.48 (for educational purposes) and a few things are troubling me
[17:41] <strycore> inkscape now uses autotools which requires some changes in debian/rules
[17:42]  * hyperair nods
[17:42] <hyperair> using autotools is a good thing
[17:42] <hyperair> it's the easiest to package.
[17:43] <strycore> first thing I did was removing "configure patch" after config.status:
[17:43] <hyperair> O_o
[17:43] <hyperair> huh?
[17:43] <strycore> pbuilder complained about this one
[17:44]  * hyperair downloads inkscape's source
[17:44]  * hyperair stares at the debian/rules and facepalms
[17:44] <strycore> for the record I'm upgrading from 0.
[17:44] <hyperair> educational experience indeed.
[17:44] <hyperair> this is virtual hell.
[17:44] <strycore> 0.47~pre4 (karmic) to 0.48
[17:45] <hyperair> you should start from lucid's packaeg.
[17:45] <strycore> well , i'd like to ...
[17:45] <strycore> but there is a bu in lucid right now and aptitude segfaults
[17:46] <strycore> so i'm doing this in VirtualBox with Karmic
[17:47] <strycore> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/515525
[17:49] <hyperair> no i mean start with lucid's package, get that up to date, and then backport back to karmic
[17:49] <hyperair> that way you don't duplicate efforts which have been done updating inkscape from ~pre4 to .0
[17:50] <hyperair> and if you haven't had much experience, it might be a good idea to start with a simpler package first.
[17:50] <hyperair> an old-style debian/rules is virtual hell.
[17:50] <strycore> well I've already done simpler packages ;)
[17:52] <cemc> hi. I'm trying to build something with pbuilder, 64bit host, 32bit lucid pbuilder, and I'm getting this: http://pastebin.ubuntu.com/385104/ . any ideas on what this could be ?
[17:52] <strycore> but inkscape is quite big, I should work on intermediate packages
[17:55] <hyperair> it's not a matter of big, the debian/rules is complex. well you could take the opportunity to learn more Make-fu
[17:55] <hyperair> strycore: what's the error you get anyway?
[17:57] <strycore> in the rules files at the line "install -o root -g root -m 644 $(CURDIR)/debian/inkscape.xpm $(CURDIR)/debian/inkscape/usr/share/pixmaps/inkscape.xpm"  it complians about file not existing
[17:57] <hyperair> and is debian/inkscape.xpm there?
[17:57] <strycore> yep
[17:58] <hyperair> could you pastebin the exact error?
[17:58] <strycore> I'll have to rebuild it
[17:59] <strycore> I launched pbuilder on 0.47 to check if everything was ok so I lost my error message in the abyss of gnome-terminal
[18:00] <hyperair> ah =\
[18:00] <strycore> I'm setting up a wiki page with the problems I get with this package
[18:00] <hyperair> a wiki?
[18:00] <hyperair> er
[18:00] <hyperair> why?
[18:00] <hyperair> and what's it called?
[18:01] <strycore> (on my personnal wiki ;) )
[18:01] <strycore> not on wiki.ubuntu.com
[18:03] <hyperair> ah
[18:06] <strycore> is there a way to tell pbuilder to restart a build from where it failed instead of doing everything from the beginning ? (kinda like make does)
[18:06] <hyperair> unfortunately not.
[18:06] <hyperair> however, you could use the C10shell script included in pbuilder
[18:07] <hyperair> the hook will spawn a shell so you can examine the contents of the build directory
[18:07] <hyperair> after that you can try continuing with fakeroot debian/rules binary
[18:09] <strycore> ok this is fine too
[18:27] <strycore> ok , this is my progress so far : http://wiki.strycore.com/index.php/Packaging_inkscape_0.48
[18:33] <Quintasan> hmm
[18:34] <hyperair> strycore: fyi, inkscape has used autotools even before 0.48.
[18:35] <hyperair> strycore: autotools packages generally do not ship the autogen.sh file -- the configure script which is generated as well as a few other autotools files are shipped.
[18:35] <strycore> so I should run autogen.sh *before* building the source package ?
[18:35] <hyperair> strycore: if you need to regenerate these, it is preferable to use autoreconf -vfi rather than ./autogen.sh
[18:35] <Quintasan> I'm trying to fix bug #526002 but each time I try pbuilding it I get -> http://pastebin.ca/1813927   pdebuild-lucid == rm -rf ../build && mkdir ../build && sudo ARCH=amd64 DIST=lucid pdebuild --buildresult ../build --logfile ../build/BUILDLOG
[18:36] <hyperair> strycore: does the new inkscape tarball have a configure script?
[18:36] <strycore> no
[18:36] <hyperair> strycore: then tell upstream to use make dist and stop using stupid methods to generate tarballs.
[18:36] <strycore> it's not a tarball ;)
[18:36] <hyperair> ah.
[18:36] <hyperair> so it's a snapshot?
[18:37] <strycore> it's from bzr
[18:37] <hyperair> then you should use autoreconf -vfi rather than ./autogen.sh
[18:37] <hyperair> it's a snapshot then.
[18:37] <strycore> yep
[18:37] <hyperair> autoreconf -vfi.
[18:37] <strycore> before building the source package or in the debian/rules file ?
[18:38] <hyperair> in the debian/rules file.
[18:45]  * nigelb wonders if there is anything a motu hopeful could help with
[18:46] <hyperair> /topic
[18:46] <hyperair> there's ftbfs
[18:46] <hyperair> and there's the NBS list
[18:46] <hyperair> plenty of things to do there
[18:46] <nigelb> whats  nbs?
[18:47] <hyperair> not built from source
[18:48] <nigelb> ah
[18:48] <nigelb> lemme see if any of them I can help with
[18:50] <hyperair> the NBS packages are basically packages which should not exist any more, but are being held back from removal by some rdepends.
[18:50] <hyperair> so to fix these, you need to update the rdepends.
[18:51] <hyperair> well there might be other cases, but i'm not sure.
[18:51] <hyperair> perhaps something like sources being superseded but the new sources ftbfs
[18:53] <hyperair> devfil: libwebkit1.0-cil is NBS, held back by galaxium which needs updating. are you going to be updating that?
[18:54] <hyperair> devfil: galaxium ftbfs's at the moment.
[18:55] <hyperair> devfil: by the way, if you're keen on continuing to maintain galaxium, may i suggest that you maintain it in debian as well, and let it be synced?
[18:55] <randomaction> sgnb: coq failed on armel, do you think we should retry the build?
[19:02] <sgnb> randomaction: I have no explanation for the build failure... is it possible to retry it to see if it is reproducible?
[19:03] <randomaction> more than once I've seen random segfaults on armel
[19:03] <randomaction> I'm retrying
[19:06] <sgnb> randomaction: thanks
[19:07] <randomaction> np; I think you'll get another mail if it fails
[19:28] <lbrinkma> I have a problem with my anjuta-extras package: I can't get away the lintian warning: pkg-has-shlibs-control-file-but-no-actual-shared libs. I've no idea how to solve that, please help me. You can get the package at https://launchpad.net/~lbrinkma/+archive/ppa
[19:29] <hyperair> devfil: actually considering galaxium has been abandoned upstream, perhaps we should have it removed from ubuntu.
[19:41] <nigelb> how do I see blacklisted apps?
[19:41] <sebner> nigelb: for syncs?
[19:41] <nigelb> for NBS
[19:41] <sebner> oh
[19:42] <nigelb> or rather figuring out why something is NBS
[19:50] <hyperair> click on the link and view the list?
[19:50] <hyperair> the reasons are all stated there
[19:50] <nigelb> I want to know if sugar is blacklisted
[19:50] <nigelb> seems a package or two fail because of that
[19:55] <strycore> hyperair, where do I put "autoreconf -vfi" in the rules files ? I've tried several places and they all failed
[20:08] <hyperair> strycore: where you put autogen.sh
[20:08] <hyperair> nigelb: what do you mean blacklisted?
[20:09] <nigelb> hyperair: I think the correct term would be marked for removal
[20:10] <hyperair> nigelb: i think you would check the status of the source package.
[20:10] <Laney> check on launchpad
[20:10] <nigelb> ah, will do
[20:10] <hyperair> Laney: where's the list of packages removed and why? i recall looking for it sometime back but couldn't find it
[20:11] <devfil> hyperair, can you please open a bug to remove galaxium? I'm very busy ATM, thanks
[20:11] <hyperair> devfil: okay.
[20:11] <Laney> dunno, I only ever care about individual packages, and check the LP page for that
[20:11] <hyperair> heh
[20:12] <hyperair> Laney: okay, so let's say i have package X which has been removed. where do i go to check out why?
[20:12] <Laney> lp/ubuntu/+source/X
[20:12] <Laney> "publishing history"
[20:12] <hyperair> aha
[20:12] <hyperair> i see
[20:12] <hyperair> okay thanks
[20:13] <hyperair> Laney: and how do i get a package removed?
[20:13] <Laney> !removal
[20:13] <Laney> long shot
[20:13] <hyperair> heh
[20:13] <sebner> hyperair: file a removal bug and subscribe the archive-admins
[20:13] <Laney> right
[20:14] <sebner> hyperair: Please remove foo bar, Rationale:
[20:14] <Laney> you should confirm that you have checked for rdeps
[20:14] <hyperair> Laney: okay thanks
[20:15] <nigelb> what are rdeps?
[20:15] <sgnb> randomaction: well... coq failed again... I don't know what to say... (it succeeded in Debian)
[20:15] <sebner> nigelb: reverse dependencies
[20:15] <sebner> nigelb: e.g if a package depends on the package which is going to be removed
[20:15] <nigelb> packages that depend on this package?
[20:15] <nigelb> ah ;)
[20:15] <hyperair> "Galaxium currently FTBFS on Lucid, and is unmaintained upstream. There are no rdepends." <-- is that fine as a description?
[20:16] <Laney> specify that you want it removed from lucid
[20:16] <hyperair> that's in the summary.
[20:16] <sebner> hyperair: archive admins like lots of text regarding removals ;D
[20:16] <hyperair> "Galaxium currently FTBFS on Lucid, is causing libwebkit1.0-cil to be retained in the archive (NBS) and is unmaintained upstream. There are no rdepends."
[20:16] <Laney> bug 521023
[20:16] <Laney> NO
[20:17] <Laney> bug 521013
[20:17] <nigelb> that was strange
[20:18]  * hyperair recalls seeing haddock recently..
[20:18] <hyperair> was it in the NBS or FTBFS list?
[20:20] <nigelb> NBS
[20:20] <hyperair> how does one view the popcon count for a package in ubuntu?
[20:21] <Laney> .u.c
[20:22] <hyperair> those seem to be general statistics
[20:22] <hyperair> rather than per-package counts
[20:22] <strycore> hyperair, I get this error message :  http://wiki.strycore.com/index.php/Packaging_inkscape_0.48#Error_messages , should I create a configure rule ?
[20:23] <hyperair> strycore: oh yeah, that's right. just take out the autoreconf-vfi and shift it into a configure: rule
[20:23] <Laney> 18816 galaxium                        1196   144   968    82     2 (Unknown)
[20:24] <hyperair> ?
[20:24] <Laney> http://popcon.ubuntu.com/by_inst
[20:24] <hyperair> 1196 installs.
[20:24] <hyperair> that's a significant number =\
[20:27] <Laney> you could fix it up, but it might be dishonest if nobody really intends to maintain it
[20:28]  * sebner agrees with Laney 
[20:32] <Quintasan> what does dpkg-source internal error: 29 means?
[20:37] <strycore> hyperair, thanks, I'll try that
[20:37] <nigelb> there is a whole lot of sugar packages depending on the older version of sugar (which isn't even in karmic) ? should I request deletion
[20:49] <jariq> Is there a way to supress lintian warnings on package ?
[20:53] <nigelb> sugar-0.86 has been deleted from lucid, so the rdeps have failed to build, should I request their deletion?
[20:57] <crimsun> nigelb: please check with lfaraone
[20:57] <nigelb> crimsun: ok :)
[20:58] <nigelb> lfaraone: sugar-0.86 has been deleted from lucid, so the rdeps have failed to build, should I request deletion?
[21:01] <lfaraone> nigelb: sure.
[21:01] <lfaraone> nigelb: but dfarning is the one who is championing that effort
[21:01] <nigelb> there seems to be a bunch of .84 and .86 packages which are failing
[21:49] <MTecknology> hyperair: so if I upload the package, there's no need to attach the debdiff? Or should I still do that and just mark fix released?
[21:49] <hyperair> MTecknology: what?
[21:50] <hyperair> MTecknology: the xdm one right? seems bryce harrington uploaded it before i could.
[21:50] <hyperair> MTecknology: check the current lucid version of xdm.
[21:50] <MTecknology> you mean the package I pushed to revu is out there?
[21:51] <MTecknology> Version 1:1.1.8-6ubuntu2 (lucid)
[21:52] <MTecknology> hyperair: or they built a new package; what I put in revu didn't have anything done to it
[21:52] <hyperair> MTecknology: nothing to do with it.
[21:52] <hyperair> MTecknology: er
[21:53] <hyperair> MTecknology: i mean it got uploaded. your debdiff, prior to you uploading to revu.
[21:53] <hyperair> MTecknology: in the future, just the debdiff is enough.
[21:53] <MTecknology> ok
[21:53] <MTecknology> how to I drop the package?
[21:54] <hyperair> click archive
[21:55] <MTecknology> thanks
[21:55] <MTecknology> is revu just for new packages?
[21:58] <persia> REVU is just a tool for new package review.
[21:59] <persia> And "Fix Released" means that it's fixed in Ubuntu.  Marking something with a debdiff "FIx Released" is just a way to make sure the debdiff is not uploaded.
[22:31] <sarah93> wow you should check this http://bit.ly/bFi9I4
[22:31] <sarah93> wow you should check this http://bit.ly/bFi9I4
[22:32] <nigelb> that was a short-lived spammer ;)
[22:32] <jdong> that's the best kind of spammer.
[22:32] <jdong> :)
[23:25] <lifeless> requestsync is hating on me:
[23:25] <lifeless> $ requestsync --lp python-testresources
[23:25] <lifeless> W: Target release missing - assuming lucid
[23:25] <lifeless> 'python-testresources' doesn't exist in 'Ubuntu lucid'.
[23:26] <lifeless> oh, I think I know
[23:26] <lifeless> rmadison handles binary names too
[23:26] <crimsun> right I was just going to mention the srcpkg name
[23:26] <lifeless> how do you force requestsync to look in unstable?
[23:27] <kamalmostafa> lifeless: -d unstable
[23:27] <lifeless> kamalmostafa: is that very new? I don't see it in requestsync --help
[23:28] <kamalmostafa> lifeless: I do see it in requestsync --help.  I don't think its very new.
[23:29] <kamalmostafa> lifeless: ubuntu-dev-tools version 0.81.1 on Karmic btw.
[23:29] <lifeless> I have 0.92
[23:29] <lifeless> oh.
[23:29] <lifeless> I'm *blind*.
[23:30] <lifeless> sorry for using up cycles on my failing to read methodically
[23:30] <persia> At least share the solution: it may be that the docs are insufficiently clear.
[23:31] <lifeless> persia: my eyes glazed over in the help list
[23:31] <lifeless> the top left is fairly dense
[23:31] <kamalmostafa> lifeless: np, my cycles are pretty cheap these days ;-)
[23:31] <lifeless> and its not alpha sorted
[23:32] <crimsun> I'll clarify the error message for requestsync
[23:32] <persia> Do you think it ought be alpha-sorted?  That's trivial, and I'd like to see an u-d-t upload for other reasons.
[23:32] <lifeless> where is the archive admin rota ?
[23:32] <lifeless> persia: I think it would help.
[23:32] <persia> w.u.c/ArchiveAdministration
[23:33] <persia> lifeless: lp:ubuntu-dev-tools :)
[23:33] <lifeless> ah 'days'
[23:33] <lifeless> persia: :P
[23:33] <lifeless> crimsun: ideally, if its the same version, check unstable, prompt.
[23:33] <lifeless> ah, noone rota'd on a weekday
[23:33] <persia> s/weekday/weekend/ ?
[23:34] <lifeless> persia: for me, doing distro stuff today, its a weekday :P
[23:34] <lifeless> StevenK: yo! bug 529262 plox
[23:36] <sebner> persia: in some states the week beginns with sunday and not monday :)
[23:36] <sebner> persia: ideological and not really (like business) though
[23:37] <persia> sebner: And each "day" is 49.5 hours long, so it's not entirely meaningful even if one selects an alternate set of days for "week".
[23:37] <sebner> heh
[23:38]  * sebner doesn't really care at all
[23:38] <persia> (for instance, the way the AA rota works, there is significant overlap between "Wednesday" and "Thursday" as a result of timezone skew)