[00:01] <geser> cjwatson_: Hi, when you have time could you review bug #180669? It includes also a fix for the fakeroot FTBFS problem in hardy.
[00:01] <ubotu> Launchpad bug 180669 in fakeroot "[Merge] fakeroot 1.9 from Debian unstable (includes also a fix for the FTBFS)" [Undecided,New] https://launchpad.net/bugs/180669
[00:11] <t0mLe> hi, have a question - any one know what my be causing "gdbm fatal: lseek error" - happens every time i try using svn
[00:17] <geser> t0mLe: bug #180368
[00:17] <ubotu> Launchpad bug 180368 in command-not-found "gdbm fatal: lseek error" [Undecided,Confirmed] https://launchpad.net/bugs/180368
[00:19] <t0mLe> thank you geser; only did a quick search and did not find any thing..
[00:21] <t0mLe> no know now of any temp fixes?
[00:26] <Fujitsu> t0mLe: Are you sure it's svn giving that error, and not command-not-found? Try installing svn.
[00:27] <t0mLe> Fujitsu, i will try..
[00:28] <t0mLe> ok, it probably was command-not-found
[00:28] <t0mLe> since installing SVN worked...
[00:29] <t0mLe> it did fix it..
[02:13] <emgent> keescook, ping
[03:52] <supersako> im a software developer currently running archlinux on my laptop but sick of it.. going to switch to ubuntu  but dont know if i should get ubuntu or kubuntu what are you guys running?
[03:52] <Chipzz> supersako: -> #ubuntu pls
[03:52] <Hobbsee> ubuntu in here
[03:53] <Chipzz> and also ubuntu
[03:53] <Chipzz> Hobbsee: so what's up with you not running kubuntu anyway? ;)
[03:53] <Hobbsee> Chipzz: wanted a change.  *shrug*
[03:54] <Chipzz> Hobbsee: yeah but I though you maintained quite a few kde packages?
[03:54] <Hobbsee> kde is group-maintained
[03:54] <Hobbsee> but yes, i made some fo the uplaods to them
[06:15] <wasabi> Hmm. Epiphany somehow lost NTLM support in hardy recently.
[07:22] <x15_> anybody in here?
[07:24] <ion_> metaquestions + impatience = win
[08:02] <stdin> if I have a patch for devscripts, I should just post a bug and upload the debdiff right?
[08:20] <stdin> done that anyway: bug 180748
[08:20] <ubotu> Launchpad bug 180748 in devscripts "debchange should increment ~ppa revisions" [Undecided,New] https://launchpad.net/bugs/180748
[10:08] <hunger> Any chance of getting valgrind merged into hardy? It is a dev-only tool, so it shouldn't break things for users and it had some mayor updates.
[10:30] <stdin> Hobbsee: bug 180748 :)
[10:30] <ubotu> Launchpad bug 180748 in devscripts "debchange should increment ~ppa revisions" [Undecided,New] https://launchpad.net/bugs/180748
[11:15]  * Hobbsee marks a critical bug.
[11:37] <pabs3> how does one get a sync request acted on? https://bugs.launchpad.net/ubuntu/+source/warzone2100/+bug/180357
[11:37] <ubotu> Launchpad bug 180357 in warzone2100 "Please sync warzone2100 version 2.1.0~0.svn3260-2 from Debian unstable (main)" [Medium,Confirmed]
[11:39] <Fujitsu> pabs3: One waits. Particularly as it is a weekend.
[11:51] <persia> pabs3: It will likely get hit on Monday.
[11:52] <pabs3> cool. what about removing packages from gutsy? is that possible?
[11:52] <persia> pabs3: Only in cases of extreme legal need.  Better to remove from hardy.
[11:54] <pabs3> not even for really really buggy stuff? a buggy SVN revision of warzone2100 was imported from Debian. it either needs to be removed from gutsy or synced from sid into gutsy
[11:58] <Giel> yes, the current warzone2100 version is _very_ much outdated, and we seem to be getting bugreports for that package on our bugtracker
[11:58] <minghua> pabs3: Not going to happen.  The sensible solution is to backport the hardy version (once it's sync'ed) to gutsy.
[11:58] <persia> pabs3: If it's really, really, really buggy (as in RC buggy), it might be eligible for an SRU.
[11:58] <Giel> even though we know that some of those bugs are fixed in later SVN versions...
[11:59] <Giel> persia: it isn't a release candidate it's a snapshot from a very unstable development trunk
[12:00] <persia> Giel: I realise that, and had I known three months ago, I'd have tried to find a way to not include it.  As it stands now, it's hard to fix unless it causes data loss, is a severe regression from a previous release, FTBFS, cannot be installed, or segfault on startup.
[12:30] <Riddell> hunger: valgrind merged
[12:32] <Giel> persia: it _will_ cause incompatibility of several config files and savegames made with the version currently in gutsy _will_ break
[12:33] <Giel> which is something I think users should be made aware of when they upgrade their warzone2100
[12:34] <persia> Giel: That might be data loss, but it might be a candidate for a NEWS.Debian entry or richer maintainer scripts.  I'm not one of the people who can confirm something is SRU worthy, but if you think there is a patch that would make the transition less painful, and wouldn't cause transition breakage by application, it might be worth submitting it.
[12:37] <Giel> persia: the savegame format that's used by 1436 is broken I think, so converting it to a workable savegame format might not even be possible
[12:38] <persia> Giel: Hrm.  In that case it sounds like a bug that can't be fixed, so NEWS.Debian would be the way to go.  Pushing to backports soon, should help, as many gamers prefer to grab the latest version anyway.
[12:39] <Giel> also lately we have been working on moving the savegames to a new format, until that's finished we'll have some intermediate formats that will break for sure
[12:39] <Giel> as long as users are aware of that I think it shouldn't be much of a problem
[12:41] <persia> Giel: OK.  Best thing to do is to get the fixes into alioth SVN before 10th February or so in order to be sure they can be included for hardy.
[14:12] <kaaloo> Hi it seems that udev rules are missing in latest libsane for hardy
[14:14] <minghua> kaaloo: Please report a bug, thanks.
[14:15] <kaaloo> minghua:Ok will do
[14:18] <kaaloo> mmm, seems its been done on purpose : "Do not install the udev rules, since hal now provides dynamic ACLs on     device nodes. (See hardy-hardware-detection spec.)"
[16:14] <tuxice> hi
[16:14] <tuxice> how do i work on ubuntu drivers and themes on launchpad
[16:16] <tuxice> HELLLLLLLLLLLLLLLLLLLLO
[16:17] <mjj29> tuxice: hi, I imagine everyone is busy atm
[16:17] <mjj29> it's only been two minutes
[16:17] <soren> tuxice: Also, your question doesn't make sense.
[16:17] <mjj29> (also, I'm afraid I can't help, I'm not an ubuntu dev, just a DD who occasionally needs to ask about ubuntu's versions of your packages)
[16:17] <mjj29> s/your/my/
[16:19] <tuxice> ok :) srry for messing up this thread
[16:51] <hunger> Riddell: Thanks for merging valgrind!
[16:52]  * hunger grumbles. aptitude keeps crashing here.
[18:01] <articpenguin3800> whats it mean when kubuntu and ubuntu share the ubuntu codebase but kubuntu dosent have automatic printer setup
[18:05] <Riddell> articpenguin3800: they have different desktop apps, one of those apps is system-config-printer which I'm currently porting to KDE
[18:06] <articpenguin3800> so that means its a gnome app that does that
[18:07] <Riddell> articpenguin3800: yes
[18:08] <articpenguin3800> k thanks
[20:01] <EvanCarroll> anyone happen to know where unicode annotations are? I need to file a bug report
[20:01] <EvanCarroll> would seem like libuninameslist0 but that isn't installed on my system
[20:40] <soren> While working on libvirt, I've come across a rather odd problem. The core of it is that on Fedora, the following works, but on Ubuntu, I get an -EINVAL: "brctl addbr foobr ; ifconfig foobr up". On Ubuntu, ifconfig up fails until the first interface has been added to the bridge. AFAICS, the kernel is the same and the differences in the bridge-utils packages are cosmetical..  Any guesses?
[20:42] <ScottK> soren: How are you on perl module dependencies and sbuild getting confused?  I've got a problem I'm trying to sort out and am looking for help.
[20:43] <soren> ScottK: Not sure. What's the issue?
[20:43] <ScottK> http://launchpadlibrarian.net/11178540/buildlog_ubuntu-hardy-i386.mime-tools_5.425-0ubuntu1_FAILEDTOBUILD.txt.gz
[20:43] <ScottK> libfile-temp-perl is already installed with insufficient version, so the newer one doesn't get pulled in and then later this is discovered and sbuild gives up.
[20:45] <ScottK> Builds fine in my local pbuilder, of course.
[20:45] <soren> ScottK: Looks quite odd.
[20:46] <elmo> ScottK: err
[20:46] <elmo> ScottK: I doubt that's actually installed in the chroot
[20:46] <elmo> scottk: are you sure it isn't provided by the perl package itself?
[20:47] <elmo> ScottK: sbuild and pbuilder handle build-depends on virtual packages very differently
[20:47] <ScottK> elmo: I think an older version is provided by perl-modules
[20:47] <ScottK> elmo: Any suggestions?
[20:50] <elmo> ScottK: if you really depend on that new a version of libfile-temp-perl?  get perl to stop providing the package...
[20:50] <ScottK> elmo: It does.
[20:51] <soren> elmo: but... It's a versioned dependency?
[20:51] <elmo> soren: so?  sbuild doesn't have the "smarts" to figure this out.  it doesn't in Debian either
[20:51] <soren> elmo: I see.
[20:51] <elmo> and how does the versioned dependency matter anyway?  it's not exactly a clearly defined area
[20:52] <elmo> perl-modules just says "I provde libfile-temp-perl", it doesn't mention versions explicitly
[20:52] <ScottK> Sbuild shouldn't think it's already satisfied the dependency when it hasn't
[20:52] <soren> elmo: Well, if it's a versioned dependency, it can't be fulfilled by a Provides: blah?
[20:52] <soren> elmo: ..or so I thought.
[20:52] <elmo> in fact it C/R/P libfile-temp-perl, which is a big hint to the packaging system of 'replace this package with me instead'
[20:53] <elmo> soren: I don't think that's defined/a given, esp. given the C/R/P
[20:53] <ScottK> Looks like I need to 'fix' perl-modules then.
[20:53] <soren> elmo: True. I didn't notice the C/R/P, though.
[20:55] <Kmos> why this happen ?
[20:55] <Kmos> http://launchpadlibrarian.net/11121825/buildlog_ubuntu-hardy-i386.win32-loader_0.6.0%7Epre3_MANUALDEPWAIT.txt.gz
[20:56] <Kmos> locales-all is a virtual package and isn't satisfied
[20:56] <soren> buid-depending on virtual packages is asking for trouble.
[20:57] <Kmos> there are a lot of ones like that on the FTBFS list
[20:57] <Kmos> depending on locales-all
[20:57] <elmo> err, locales-all doesn't even exist in hardy, AFAICS?
[20:58] <Kmos> hmm..
[20:58] <Kmos> it should build against libc6-dev?
[20:59] <Kmos> elmo: thanks for the tip =)
[21:12] <geser> ScottK: your perl build problem is bug #111800 filed by you :)
[21:12] <ubotu> Launchpad bug 111800 in sbuild "sbuild attempts to satisfy versioned depencies and fails - causes packages to FTBFS" [Unknown,Confirmed] https://launchpad.net/bugs/111800
[21:13] <ScottK> geser: Thanks.  I thought that sounded familiar.
[21:13] <ScottK> It looks like there's a real problem between perl-modules and libfile-temp-perl that has to be sorted out.
[21:14] <geser> I should try to get infinity's attention to this bug
[21:14] <ScottK> Since perl-modules conflicts
[21:14] <ScottK> Please do.
[21:16] <ScottK> In the meantime, I'm going to figure out how to rip libfile-temp-perl out of perl-modules so we can use the newer one instead.
[21:42] <ScottK> Kmos: Duping a bug that is assigned to someone to work on (particularly someone like inifinity) may not have been the best thing to do.
[21:42] <ScottK> Bug #178536
[21:42] <ubotu> Launchpad bug 178536 in sbuild "Preinstalled Build-Depends not properly detected (dup-of: 111800)" [Undecided,New] https://launchpad.net/bugs/178536
[21:42] <ubotu> Launchpad bug 111800 in sbuild "sbuild attempts to satisfy versioned depencies and fails - causes packages to FTBFS" [Unknown,Confirmed] https://launchpad.net/bugs/111800
[21:42] <Kmos> ups
[21:42] <Kmos> i should dupe the oldest one ?
[21:42] <ScottK> I think you should leave it alone.
[21:43] <ScottK> i.e. put it back the way you found it.
[21:43] <Kmos> ok
[21:43] <somerville32> Why would you ever duplicate a bug?
[21:44] <Kmos> ScottK: done
[21:44] <Fujitsu> Thankyou Kmos.
[21:44] <ScottK> somerville32: Dupe = mark as duplicate
[21:45] <Kmos> Fujitsu: no problem
[21:45] <Fujitsu> I didn't think I noticed it being duped - seems I looked at it a couple of minutes after it was duped, so I hadn't got a mail.
[21:45] <somerville32> Ahhh, that makes more sense now
[22:29] <slangasek> soren: build-depending on virtual packages is sometimes a very reasonable thing to do
[22:30] <slangasek> soren: the issue is that you don't want to do it if there's more than one real package providing it at a time; but some yokels like to change -dev package names like they change their underwear, and the virtual package name is the only thing persistent that you can build-depend on
[22:33] <ScottK> slangasek: Any suggestions on how to deal with build-deps on perl-modules that are both in 'perl-modules' (but in insufficent version) and have newer ones packaged separately?
[22:34] <Mithrandir> ScottK: add versioned build-deps?
[22:34] <ScottK> Mithrandir: sbuild doesn't understand those.
[22:34] <ScottK> I've got that already.
[22:34] <elmo> err, context
[22:34] <Mithrandir> ScottK: uh, yes it does.
[22:34] <elmo> sbuild doesn't understand them against virtual packages
[22:34] <elmo> scottk: I think you have to update the code in perl-modules
[22:35] <elmo> scottk: if you rip it out of perl-modules, you risk breaking stuff which depends on it being present in perl-modules (-> no explicit Depends)
[22:35] <ScottK> elmo: I hope you're wrong, but am afraid you aren't.
[22:35] <ScottK> My plan was to make perl-modules depend on whatever I ripped out.
[22:35] <elmo> oh, well that'd work too
[22:35] <ScottK> So it could still be relied on to be there.
[22:36] <ScottK> But could continue to be updated without having to update perl-modules every time.
[22:36] <elmo> the only other alternative (and I'd strongly unrecommend this) is changing the pkg name
[22:36] <ScottK> I'm not even thinking about going down that path.
[22:43] <slangasek> I don't understand why the flip-flop between shipping it in perl-modules and shipping it as a separate package, fwiw
[22:48] <soren> slangasek: True, but that's kind of a special case, IMO.
[22:48] <ScottK> Well I don't exactly either, but a newer version that some packages need is now packaged separately.
[22:53] <slangasek> soren: it's common enough that "build-depending on virtual packages is asking for trouble" is misleading. :)
[23:15] <IceKiller> any ubuntu dev'rs here wondering about this: http://ubuntuforums.org/showthread.php?t=633068
[23:15] <IceKiller> srry if i'm not allowed to ask this here..
[23:17] <sladen> IceKiller: might be useful to give a quick one-line overview of what $this is
[23:17] <thom> IceKiller: try #ubuntu-x, more likely to be useful
[23:17] <IceKiller> the Intel driver + MESA 7.01 shipped with Gutsy is quite buggy with Intel GM965, there are new 'drivers' and was wondering if it was going to be included in the mainstream
[23:18] <IceKiller> http://www.mesa3d.org/relnotes-7.0.2.html where it mentions among other things that: "Fixed an assortment of i965 driver bugs" && a new Intel driver, version 2.2.0: http://xorg.freedesktop.org/archive/...l-2.2.0.tar.gz
[23:19] <sladen> IceKiller: okay, so re-paste your 1st, 3rd and 4th lines to #ubuntu-x as noted by thom
[23:19] <IceKiller> just did ;)
[23:20] <IceKiller> ty :p
[23:34] <ScottK2> Fujitsu: Looks to me like libfile-temp-perl and libtest-harness-perl are the only perl-modules affected.
[23:34]  * ScottK2 runs off again.