[00:10] <TheMuso> c
[00:11] <TheMuso> ugh wrong tab
[06:15] <a_cuozzo> How is everyone?
[06:15] <a_cuozzo> I have a question regarding package submission.
[06:16] <pwnguin> no chokeholds
[06:17] <a_cuozzo> lol
[06:18] <a_cuozzo> I am interested in making a debian package of Tom Christiansen's Perl Power Tools.
[06:19] <ScottK> a_cuozzo: #ubuntu-motu is a better channel for how to package questions.
[06:19] <a_cuozzo> Ah, I know how to make the package.
[06:19] <a_cuozzo> I was wondering if there would be any interest in submitting it to the repos.
[06:20] <a_cuozzo> Where can I find out if there would be an interest in submitting it?
[06:20] <Burgundavia> a_cuozzo: you need #ubuntu-motu
[06:21] <a_cuozzo> Okay, I will go there. Thank you :)
[09:05] <kagou> Good morning
[10:11] <tjaalton> ion_: could you check bug 182237
[10:11] <ubotu> Launchpad bug 182237 in linux-restricted-modules-2.6.24 "restricted manager does not recognize nvidia 8600M GT on hardy" [High,Confirmed] https://launchpad.net/bugs/182237
[10:12] <tjaalton> nvidia_supported doesn't work anymore for 169.07
[10:21] <ion_> tjaalton: I’ll take a look at it.
[10:26] <tjaalton> ion_: great, thanks
[10:28] <Usiu> Hi, Do you import additonal packages to 7.10 or its freezed ?
[10:28] <persia> Usiu: We can import, but evaluate new packages to make sure they don't break anything else.
[10:29] <StevenK> 7.10 is frozen
[10:29] <persia> Ah.  Right.  My mistake.  7.10 is frozen.  8.04 is open.
[10:29] <StevenK> It's released, and finished with, except for critical bug fixes and security updates.
[10:30] <Usiu> Ok thanks
[10:36] <scizzo-> I am not sure if it is of any interest to put in ubuntu now but there is a svn package version of inkscape on the website if someone wants to give it a go
[10:37] <Usiu> StevenK, but ubuntu page states that merg with debian has already been freezed
[10:37] <Usiu> StevenK, so is it still possible to add packages in this case ?
[10:44] <StevenK> Usiu: For Hardy, yes, if it's justifiable
[10:56] <YokoZar> Could I get a quick outside opinion?  I'm worried about starting a conflict in a bug: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-games/+bug/138713
[10:56] <ubotu> Launchpad bug 138713 in gnome-games "Gnometris uses Gnome foot logo instead of Ubuntu theme" [Wishlist,Invalid]
[11:03] <persia> YokoZar: It's an #ubuntu-desktop decision.  I can see your point, but it needs to be done in a way that can easily be overridden with a -themes package or similar to support in-distro flavour variation.
[11:04] <YokoZar> persia: thanks, that makes some sense
[11:04] <YokoZar> persia: all it is at this point is just changing one file (albeit one part of the gnome-games package)
[11:06] <persia> YokoZar: still #ubuntu-desktop (gnome-games is main, and gnome)
[11:30] <ion_> tjaalton: I attached a new version of nvidia_supported to the bug report.
[11:31] <ion_> tjaalton: Since the PCI ID list isn’t the first symbol of the file anymore, i found another consistent thing between all the releases: there are always two subsequent symbols with the identical PCI ID list. So now the script finds that.
[11:32] <tjaalton> ion_: cool, thanks
[11:33] <ion_> Has someone planned on working on autoselecting the proper nvidia driver release on startup based on connected hardware?
[11:34] <tjaalton> without using restricted-manager to fiddle with the xorg.conf?
[11:34] <ion_> Yep
[11:34] <ion_> Symlinks instead
[11:34] <tjaalton> what symlinks?
[11:35] <ion_> nvidia.o → nvidia-123.45.67.o, libGL.so.something → nvidia’s libGL for the same driver release
[11:35] <ion_> Could be updated using the alternatives system.
[11:36] <ion_> Anyway, if someone feels like implementing that, this program should be helpful. I’m trying to get it uploaded to Ubuntu. http://revu.tauware.de/details.py?package=hardware-connected
[11:36] <tjaalton> so you could have all those installed?
[11:36] <ion_> It can be used almost directly against /usr/share/linux-restricted-modules/$(uname -r)/modules.alias.override/nvidia
[11:36] <ion_> I was thinking that there would be just a single nvidia-glx that would contain all the releases, and the system would pick the correct one on startup.
[11:41] <tjaalton> I don't know.. there are plans though to automatically use the binary driver instead of nv, if it's installed
[12:00] <geser> Hobbsee: Hi, could you please give-back dom4j. Thanks.
[12:02] <Hobbsee> geser: done
[12:03] <Kmos> geser: it won't work.. no build records in hardy. - bug 181981
[12:03] <ubotu> Launchpad bug 181981 in dom4j "Rebuild dom4j to create an hardy build record" [Wishlist,Confirmed] https://launchpad.net/bugs/181981
[12:03] <geser> argh
[12:04] <Hobbsee> erm, /me looks
[12:04] <Kmos> geser: if you want to sponsor the upload to make it building.. :)
[12:04] <Hobbsee> wow, that's classy
[12:04] <Fujitsu> That's actually bug #181328.
[12:04] <ubotu> Launchpad bug 181328 in soyuz "no build records for previously-failed builds" [High,Triaged] https://launchpad.net/bugs/181328
[12:04] <Hobbsee> Fujitsu: which is listed on there, yes
[12:05] <Fujitsu> Ah, right.
[12:06] <Fujitsu> Soyuz isn't actually that bad here, as DEPWAIT and FAILED builds do get new records in the next distroseries...
[12:06] <Fujitsu> Just CHROOTWAIT doesn't, as far as I can see.
[12:06] <geser> looks like we really need an upload for a build retry
[12:07] <Hobbsee> geser: it appears so
[12:07] <Fujitsu> That would fix it, but is a hack.
[12:07] <Hobbsee> Fujitsu: yes, but this is soyuz.
[12:08] <geser> Fujitsu: true, is there any other alternative to waiting till this bug is fixed and the affected packages got retried in hardy?
[12:08] <Kmos> geser: cprov told me he don't know if he could do it for next version of launchpad, so it can take ages..
[12:08] <Fujitsu> geser: I doubt it.
[12:08] <Hobbsee> geser: unless they manually generate build records for all affected packages (who knows how many)..
[12:09] <Hobbsee> Fujitsu: you really should start working on it, and remove some of the crack.
[12:09] <geser> I will check then the chrootwait list for gutsy and see how many packages still need a upload for a rebuild
[12:10] <geser> Kmos: I'll upload it, for the next time: please close your bug in your changelog entry
[12:11] <Hobbsee> geser: hopefully most of it will be picked up with the autosyncs, where the later versions get tried
[12:11] <Hobbsee> or users complain
[12:11] <Kmos> geser: thanks! sorry.. i'll remember that next time..
[12:12] <persia> Hobbsee: We've hundreds of packages for which neither of those conditions get hit, unfortunately
[12:12] <Hobbsee> persia: cruft, or actual useful stuff?
[12:12] <Fujitsu> Builds failing due to chroot failures should very rarely make a release...
[12:12] <persia> Hobbsee: define cruft
[12:13] <Hobbsee> persia: okay, so crap that people care about, vs crap that they don't.
[12:13] <Hobbsee> where people == users, devs, etc
[12:13] <Fujitsu> Urgh, why wasn't that given back months earlier?
[12:13] <Hobbsee> Fujitsu: no build records?
[12:13] <Hobbsee> Fujitsu: oh, originally?
[12:13] <persia> Hobbsee: Umm.  If it didn't get updated, and nobody complained, I'd think that was obvious :)
[12:13] <Fujitsu> I mean the gutsy one.
[12:13] <Hobbsee> persia: right.  true
[12:13] <Hobbsee> persia: how many packages are we talking about there?
[12:14] <persia> I'm not sure right now.  Fujitsu, do you still have those scripts around?
[12:14] <Kmos> also others packages are failing because we don't have right now a locales-all replace, langpack-locales isn't prepared to handle it..
[12:15] <Fujitsu> persia: Probably. I can easily mangle them to work out any non-superseded chrootwait builds in Gutsy.
[12:15]  * Hobbsee wonders if the great hardy lot got given back
[12:15] <StevenK> The simplest way to do is by asking the database. Typical.
[12:15] <Fujitsu> StevenK: That works too.
[12:15] <Fujitsu> Hobbsee: We don't seem to have any chrootwait in Hardy at the moment.
[12:15] <persia> Fujitsu: I think it'd be interesting to see not just only non-superseded chrootwait builds, but also non-superceded FTBFS for any reason.
[12:16] <StevenK> Which would work if you begged an LP admin
[12:16] <Fujitsu> persia: Best to run the normal FTBFS script over Gutsy, then.
[12:16] <persia> Fujitsu: Makes sense.
[12:18] <Hobbsee> Fujitsu: oh, so it did.  good
[12:18] <persia> Fujitsu: Wait, won't that also show superceded builds?
[12:20] <Fujitsu> persia: geser's only lists those failures that are in the last version of each source package, I believe.
[12:21] <persia> Fujitsu: That would be good.  I'll post it somewhere when it finishes
[12:23] <geser> Fujitsu: yes, as it doesn't make sense to list FTBFS for package version which might be fixed in the current version
[12:23] <Fujitsu> geser: Of course, that makes sense.
[12:24] <geser> I could run the script against gutsy if there is interest
[12:24] <persia> geser: I'm running with s/hardy/gutsy/ now, but it might be interesting to run against feisty and dapper to see if we missed any FTBFS SRUs.
[12:25] <persia> Or rather, to catch any FTBFS that haven't been updated in a while.
[12:36] <geser> FTBFS stats for dapper: http://qa.ubuntuwire.com/~geser/build_status-dapper/
[12:36] <geser> FTBFS stats for feisty: http://qa.ubuntuwire.com/~geser/build_status-feisty/
[12:44] <persia> geser: Are all those still outstanding?
[12:45]  * persia is especially surprised to see 39 packages in main
[12:46] <Fujitsu> persia: Most of those are fine.
[12:46] <Fujitsu> They're arch-specific things that appeared before Soyuz had P-a-s.
[12:47] <persia> Fujitsu: I'd say OOo is really the only one that matters, but I haven't heard a lot of complaints from Dapper OOo users, so it may not be as important as it looks.
[12:57] <geser> FTBFS stats for gutsy: http://qa.ubuntuwire.com/~geser/build_status-gutsy/
[12:58] <geser> luckily only 3 packages in chrootwait
[13:01] <madmac> hi, i would like to know if is possible to create a patch with diff that creates directories
[13:01] <madmac> i am trying but dont know how
[13:04]  * persia stops my run, presuming it to be terribly slow for some reason.
[13:05] <mjj29> madmac: patch should just create the dir if you try and patch a new file in it
[13:06] <persia> So it is only CHROOTWAIT packages that don't automatically get requeued for the next release, or are there hidden FTBFS issues remaining?  Are the 499 packages identified as FTBFS for dapper in addition to those for gutsy or hardy, or does it only check within a release?
[13:07] <Fujitsu> persia: depwait and failed builds get new records created, which doesn't leave much.
[13:07] <Fujitsu> Perhaps upload failures, however.
[13:10] <persia> I don't think any of the upload failures are much concern.  They seem to be all lpia or hppa (which are both sort of special), except for m17-contrib and ion3, both of which I think are gone now.
[13:10] <madmac> mjj29: patch tell me "patch: **** Can't rename file /tmp/poXkD8Ax to modules/net/  : Not a directory"
[13:10] <mjj29> madmac: what does the patch say?
[13:10] <madmac> because net doesnt exisit
[13:11] <madmac> patch says that
[13:11] <mjj29> no, what's the actual patch
[13:11] <mjj29> can you pastebin it or something?
[13:11] <madmac> the actual patch is a file inside net directory
[13:12] <mjj29> madmac: ok, can you spell out exactly what you are doing
[13:12] <madmac> creating a patch for adding a new file inside a new directory that doesnt exist
[13:12] <mjj29> I just did: mkdir -p a/b; mkdir newa; echo 'hi' > a/b/c; diff -urN newa a > diff; cd newa; patch -p1 < ../diff
[13:13] <mjj29> and it said:
[13:13] <mjj29> patching file b/c
[13:13] <mjj29> and created the directory b and the file c
[13:13] <mjj29> madmac: how are you trying to do it?
[13:13] <mjj29> what commands are you running
[13:13] <mjj29> what is the text in the diff which you are trying to apply
[13:13] <mjj29> be more specific or we can't help
[13:14] <geser> persia: I've upload libswidgets-java to get a build record in hardy
[13:14] <persia> geser: Excellent.  Thanks.
[13:15] <madmac> diff -Naur old/modules/net/ new/modules/net/socket.c > patch
[13:15] <geser> persia: but for libjempbox-java I need someone first who can resurrect checkstyle which got eaten by the move to universe (arch:all bug)
[13:15] <madmac> then patch -p1
[13:16] <geser> persia: so (almost) all chrootwait from gutsy are handled now
[13:16] <Fujitsu> geser: They're back.
[13:17] <persia> geser: Thanks for digging those out.  Do you think it is worth checking edgy as well?  For pre-Dapper, I think other issues would be more important.
[13:18] <mjj29> madmac: I assume you can't just do diff -aurN old new ?
[13:19] <madmac> no, there are binaries and makefiles
[13:19] <mjj29> madmac:
[13:19] <geser> Fujitsu: then is the mirror I use a little back behind
[13:20] <Fujitsu> geser: Oh dear, maybe it got missed.
[13:20] <mjj29> cd ..; cp -lR new new.orig; rm new.orig/modules/net/socket.c; diff -aurN new.orig new > patch
[13:20]  * Fujitsu looks.
[13:20] <Fujitsu> cprov said he'd restored them all.
[13:21] <madmac> mjj29: thanks i got it
[13:22] <madmac> mjj29: the problem was that i didnt specified the file in old
[13:22] <Fujitsu> geser: That was only demoted a couple of days ago. That's really odd.
[13:22] <mjj29> madmac: oh, right
[13:22] <mjj29> madmac: yeah, of course that works
[13:23] <Fujitsu> geser: It was promoted ~2 hours before the code was fixed, so it may not have made cprov's list.
[13:24]  * Fujitsu is confused as to why there are two universe records there, 5 minutes apart.
[13:27]  * geser hopes that we have soon all arch:all packages back
[13:29] <geser> persia: FTBFS stats for edgy: http://qa.ubuntuwire.com/~geser/build_status-edgy/
[13:30] <Fujitsu> geser: Most of them seem to have been restored, but apparently not all :(
[13:30] <persia> geser: Wonderful.  No candidates that need a poke.  I suspect that the hardy stats are now up to date.
[13:30] <persia> (excepting libjempbox-java)
[13:31] <stgraber> cd
[13:50] <Kmos> geser: dom4j built with success :)
[14:08] <MetaMorfoziS> hi all
[14:09] <MetaMorfoziS> i wanted to try the hardy heron 8.04 cd, and i has a problem, is the good place to say/ask about that?
[14:09] <MetaMorfoziS> live*
[14:09] <ion_> Please read the topic.
[14:10] <MetaMorfoziS> ooh sorry
[14:10] <tormod> ogra: ping
[14:19] <Hobbsee> tormod: it's the weekend
[14:20] <tormod> Hobbsee: so what? :)
[14:20] <Hobbsee> tormod: canonical employees don't tend to work weekends unless there's a very good reason fro it
[14:22] <tormod> Hobbsee: they're too healthy I guess. But he's logged in, so it's reasonable to check if he's here.
[14:24] <Hobbsee> heh
[14:24] <Hobbsee> true
[16:35]  * lamont wonders if libcaca should not build-dep on mono-gmcs on hppa, or if that'd just make it ftbfs
[16:59] <lamont> libapache2-mod-perl2 is d-w locales-all everywhere...
[18:42] <bigon> is someone working on bug 182155 ?
[18:42] <ubotu> Launchpad bug 182155 in cli-common "Please sync cli-common 0.5.6 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/182155
[18:44] <pochu> bigon: you need to wait for an archive admin to sync it.
[18:45] <bigon> yeah I know, the sync is needed to fix bug 182130
[18:46] <ubotu> Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,Fix committed] https://launchpad.net/bugs/182130
[18:47] <pochu> bigon: but archive admins aren't around, as it's saturday... your best bet is to poke Hobbsee when she's back, if that's urgent.
[18:47] <bigon> ok, I will ask her
[19:56]  * lamont notes that upx-ucl fails to build these days
[20:08] <\sh> StevenK: ping inventor...can you describe in a short sentence when you mean with
[20:08] <\sh>   * Hack libInventorWidget.a to not build MyColorEditor, as it also uses GLw
[20:08] <\sh>     now.
[21:17] <choudesh__> Hi all.
[21:18] <choudesh__> does anyone know how to add dist and pool folders to the liveCD? I am remaster a liveCD but when I add the Dist/Pool folders for apt-cdrom, squashfs fails to load
[23:54] <lamont> dpatch.  #$&^*(%)_*_$&#%^*(&)^(_... pain.