[00:01] <kees> @pilot out
[00:17] <bdrung> persia: can you please have a look at https://wiki.ubuntu.com/fakesync and extent it / improve the wording?
[02:37] <ebroder> ari-tczew: I was skimming the sponsorship queue and noticed bug #615734. Was there a particular reason you asked tjcasey to switch to bzr? As long as both bzr and debdiffs are considered acceptable ways of getting sponsorship, I don't think we should be asking contributors to jump back and forth between the two based on personal preference
[03:36] <YokoZar> latest natty kernel package doesn't seem to be installable on my natty vm...
[03:43] <RAOF> Installed for me :)
[03:52] <yao_ziyuan> i think the no.1 problem in gnome is probably the desktop icon text color. it's white and just doesn't work with light wallpapers. i found a perfect solution.
[03:52] <yao_ziyuan> put a gtkrc-2.0 file in your home dir with this content: http://fpaste.org/jpvP/ . this will set your desktop icon text color to black, and put a 50%-translucent round-cornered box around the text.
[03:53] <yao_ziyuan> the purpose is that whether your wallpaper is dark or light, desktop icon text will always be highly contrasted. i recommend it be a default configuration for ubuntu.
[04:15] <StevenK> yao_ziyuan: That sounds like a great suggestion -- I'd recommend you file a bug so it doesn't get lost.
[04:17] <yao_ziyuan> StevenK: thanks for encouragement
[04:18] <yao_ziyuan> StevenK: i'm actually using fedora but it doesn't matter
[04:24] <yao_ziyuan> StevenK: i found an existing ubuntu bug report concerning exactly the same issue: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/643836
[04:25] <yao_ziyuan> StevenK: it blamed the upstream (gnome). should i add a comment providing my near-perfect solution, or create a new bug report
[04:25] <yao_ziyuan> i guess adding a comment
[06:07] <omdag> hi
[06:07] <omdag> anyone around
[06:10] <cjwatson> (sorry for slow reflexes)
[06:13] <CarlFK> http://dpaste.de/LZ1X/  software-properties$ bzr diff - what is the process for submitting a patch?
[06:19] <micahg> CarlFK: https://wiki.ubuntu.com/Bugs/HowToFix#Using%20Ubuntu%20Merge%20Proposals
[06:22] <CarlFK> micahg: thanks.  figured there was something like that
[07:06] <didrocks> good morning
[07:08] <dholbach> good morning!
[07:09] <didrocks> hey dholbach!
[07:09] <dholbach> salut didrocks
[07:09] <didrocks> dholbach: I filed a bug against the kernel as I got no answer in #ubuntu-kernel, want to subscribe?
[07:09] <dholbach> sure
[07:10] <didrocks> dholbach: bug #686070
[07:10] <dholbach> gracias
[07:10] <didrocks> yw :)
[07:51] <didrocks> @pilot in
[07:51] <didrocks> "welcome onboard" :)
[07:51] <ebroder> Whooo!
[07:51] <dholbach> yooohoooo!
[08:01] <pitti> Good morning
[08:23] <Huawei> hello
[08:26] <hekireki> Hey guys
[08:27] <hekireki> I've built a deb package for my app, and i'd like it to be downloadable via apt, how can i do that ?
[08:29] <CarlFK> hekireki: /j #launchpad and ask about PPA
[08:30] <hekireki> thanks you carl
[09:01] <\sh> hmmm...why is dh_autotools-dev_{restoreconfig,updateconfig} in autotools-dev and not in debhelper ? even if the man page says, that it belongs to debhelper 7?
[09:09] <hyperair> wait, there's a dh_autotools-dev?
[09:09] <hyperair> what happened to dh_autoreconf?
[09:11] <\sh> hyperair: since maverick it seems...
[09:12] <hyperair> what
[09:12] <dapal> \sh, hyperair: they're different
[09:12] <hyperair> dapal: eh?
[09:12] <dapal> dh_autoreconf runs "autoreconf -f -i"
[09:12] <hyperair> ah yes
[09:12] <hyperair> config.guess/sub
[09:12] <dapal> thus changes Makefile.in's, for example
[09:12] <dapal> exactly
[09:12] <dapal> dh_autotools-dev_* only changes config.{guess,sub}
[09:13] <dapal> and that's the reason why it's in autotools-dev: they need the config.guess/sub copies
[09:13] <dapal> i.e. /usr/share/misc/config.sub and /usr/share/misc/config.guess
[09:13] <hyperair> makes sense.
[09:13] <hyperair> what 's config.sub and config.guess for again?
[09:14] <dapal> they're for architecture-specific things, AFAIR
[09:14] <dapal> but please don't ask more, I hate autofools :-p
[09:14] <dapal> (just because I don't know much)
[09:14] <hyperair> heheh
[09:15] <\sh> dapal: but wouldn't it make more sense, to include the debhelper scripts into debhelper itself and not in packages which are not related to debhelper actually?
[09:15] <hyperair> \sh: it's autofools specific
[09:15] <hyperair> just like how dh_quilt* is in quilt.
[09:15] <dapal> \sh: and then make debhelper depend on autotools-dev? Nasty. :)
[09:16] <dapal> hyperair: (or dh_bash-completion is in bash-completion, or [..])
[09:16] <hyperair> yeah
[09:16] <dapal> anyway, who uses dh_quilt these days? 3.0 (quilt) rocks \o/
[09:19] <\sh> hmm...I see it a bit different...someone who wants to change config.{sub,guess} will always include autotools-dev, the dh_autotools-dev_* stuff is a wrapper to some manual shell magic imho (i didn't take a deeper look at those scripts), so for me it belongs more into debhelper then in another package..anyways...it's probelmatic now to build a source package on lucid with those commands inside debian/rules...
[09:20] <hyperair> dapal: i use it when i need to do things before patching.
[09:20] <hyperair> dapal: on older ubuntus
[09:20] <dapal> ah, yes. :)
[09:20] <hyperair> stuff like ltmain.sh
[09:20] <hyperair> speaking of which, i hear that libtool's been fixed and we can drop the patch now
[09:20] <hyperair> is that true?
[09:20] <hyperair> and since when?
[09:20] <dapal> oh, well
[09:21] <dapal> I've been patching ltmain.sh since ages
[09:21] <hyperair> yeah same here
[09:21] <hyperair> rather, ever since i inherited banshee, i've been patching ltmain
[09:21] <dapal> is libtool being fixed just a rumour? :-p
[09:21] <hyperair> lol, maybe. =p
[09:23] <DktrKranz> mvo: I wonder if you had the time to look at a synaptic merge proposal I did some time ago (https://code.launchpad.net/~dktrkranz/synaptic/manual/+merge/42026)
[09:24] <mvo> DktrKranz: briefly, let me check it out again
[09:29] <mvo> DktrKranz: I commented on the bug, I'm a bit unsure about it, but I guess its the right approach
[09:31] <DktrKranz> mvo: it won't exclude other important bits (i.e. some key packages installed by tasksel, or equivalent), but at least it doesn't show apt, dpkg, tar, and thelike
[09:32] <DktrKranz> I'm trying to see if there's a way to do so, didn't come to a solution yet, though
[09:50] <pitti> mdz: did you recently change the tech-board LP settings? the moderation queue now gets tons of merge proposals, and I started getting every TB mail twice
[10:33] <mdz> pitti: yes, I set the contact email address for the team to the mailing list
[10:34] <pitti> mdz: seems TB is somehow involved in all these merge proposals then
[10:35] <mdz> pitti: should I undo that change?
[10:35] <mdz> while we track down why?
[10:36] <pitti> mdz: it's not hard to delete them from the moderation queue, but I wonder why they are landing there in the first place
[10:36] <pitti> seems tech-board is a default reviewer for ubuntu branches or so?
[10:36] <pitti> mdz: you did that because someone used "contact user" for the xubuntu  mail, right?
[10:37] <mdz> pitti: probably we are a member of some other team which is
[10:37] <pitti> mdz: I guess it just landed in a different folder for me then, thus I didn't see the original email where I saw sabdfl's reply
[10:37] <mdz> pitti: I'm actually subscribed to merge proposals for Ubuntu anyway, so I didn't notice
[10:41] <didrocks> pitti: btw, I didn't touch the language-selector and gdm changes for $LANGUAGE. I think the reporter subscribed you, the diff is quite large and you know the issue/functionnality :)
[10:42] <pitti> didrocks: right; I unsubscribed sponsors for that, for this very reason
[10:42] <pitti> it'd take ages for someone else to catch up
[10:42] <didrocks> that was my guess :)
[10:49] <hron84> Hi! I would like to know where finds the GDM its configuration file.
[10:49] <hron84> I use Ubuntu Lucid
[10:49] <pitti> hron84: gdm has a lot of configuration; what kind of config are you looking for?
[10:50] <pitti> (per-user or global, autologin vs. how to start the session, language vs session type, etc.)
[10:50] <hron84> I would like tell to it to don´t start Xorg as first VNC server, but Xvnc
[10:50] <hron84> ahh
[10:50] <hron84> I would like tell to it to don´t start Xorg as first  server, but Xvnc
[10:51] <hron84> i have a config file, i know what i need to do, but gdm doesn´t accepts the config file from standard places.
[10:51] <pitti> erm, Xvnc isn't an X server
[10:51] <hron84> Ok.
[10:51] <hron84> I know
[10:54] <hron84> pitti: i know. I´mn´t a newbie of linux or Ubuntu, just i use GDM and Xvnc very rarely on Ubuntu, i usually config it on Debian.
[10:56] <pitti> hron84: you might be able to set it in /etc/gdm/custom.conf, but I'm not sure whether the X server to use is configurable
[10:57] <hron84> pitti: i tried it, but GDM doesn´t accepts the config from here.
[10:57] <pitti> hron84: it does use the file, though; it's where we put autologin etc. settings
[11:44] <Kano> hi, is it a running gag that your iso images even for natty use a new enough isolinux version but they are still not hybrid because of missing isohybrid command?
[11:57] <ScottK> cjwatson: grantlee (via build-depends from kde4libs) is only used by KDE in Main, but isn't in the Kubuntu packageset.  It may be just because it's newly in Main, but it seems to me that it should be.
[12:15] <cjwatson> ScottK: kde4libs has to be overridden into the kubuntu set because it's so deep in the dependency chain.  I've added an exception for grantlee to match.
[12:15] <ScottK> cjwatson: Thanks.
[12:32] <ScottK> barry: Looks like pyrex is blocking 2.7 for some other packages (it's built for 2.7, so it's a works with 2.7 problem, not a rebuild issue). http://launchpadlibrarian.net/60079969/buildlog_ubuntu-natty-i386.python-evas_0.5.0%2Br49677-1build1_FAILEDTOBUILD.txt.gz
[12:33] <Kano> cjwatson: whats up with your iso builds, cant you trigger isohybrid at the end
[12:37] <Kano> bug 524803
[12:40] <cdbs> kees: there? Does the fetchmail package create a fetchmailrc? I don't think so, and it has START_DAEMON=yes by default in the /etc/default/fetchmail .
[12:40] <cdbs> so this is a clash
[12:55] <Daviey> Hmm... Does pbuilder standard config rebuild the debian.orig.gz?  I have the one that went in, and the one that came out (result), and they binary differ by sum.. but diffing contains the same contents... I'm quite suprised it seems to have repacked it... any ideas?
[12:58] <didrocks> ok, time to fully switch again to normal day job, ejection… :)
[12:58] <didrocks> @pilot out
[14:03] <et_> Can someone help disable cd rom drives on ubuntu?
[14:03] <et_> Need it for a project
[14:04] <et_> I need to deny access to CD ROM drive to certain users.  But so far, I'm unable to do so
[14:04] <et_> can anyone give me a pointer?
[14:05] <cdbs> !support | et_
[14:05] <et_> sorry.. & thanks.
[14:08] <kenvandine> @pilot in
[14:14] <avinashhm> hi, any one tried copying kernel source repos from one PC to another using NFS mount ??? stuck with 'Stale NFS file handle' errors .. any help ??
[14:23] <dnivra> hello. I am working on LP: #647045 and have something weird happening. I edit the only occurrence of the 'Handler silently failed' in the entire source code of apt and yet it displays the same error. How is that even possible?
[14:24] <dnivra> LP:#647045
[14:24] <ScottK> bug 647045
[14:25] <dnivra> Thanks ScottK.
[14:25] <ScottK> You're welcome.
[14:33] <juliank> dnivra: In which file is the message?
[14:34] <dnivra> juliank, apt-pkg/contrib/cmndline.cc
[14:36] <juliank> dnivra: Then, did you set LD_LIBRARY_PATH? And really, that
[14:37] <dnivra> juliank, it should point to? currently it points to /usr/local/lib.
[14:37] <juliank> dnivra: If you are running ./build/bin/apt-get you must also set LD_LIBRARY_PATH=./build/bin, otherwise it loads the old library
[14:38] <dnivra> which is the already existent unmodified library! well i didn't know that. thanks juliank!
[14:38] <dnivra> is it enough if I append './build/bin' to LD_LIBRARY_PATH or should it be the only value?
[14:39] <dnivra> juliank, thanks a lot! I've been breaking my head over this for whole of today-nearly 12 hours now.
[14:40] <juliank> dnivra: That's your thing. But the bug has to be fixed in cmdline/apt-cache.cc anyway, not in cmndline.cc
[14:42] <dnivra> juliank, i think the function 'DispatchArg' in cmdline.cc is what is called from apt-cache.cc, which prints the dependencies. I check it with gdb-it's immediately after the function call 'CmdL.DispatchArg(CmdB)' in line 1865 of apt-cache.cc that the dependencies are printed. but I'm not too sure about that.
[14:43] <juliank> dnivra: The bug is around line 590 of cmdline/apt-cache.cc
[14:43] <juliank> it returns false without creating an error first
[14:47] <dnivra> juliank, gotta check it out then. i'm still learning how apt works. and all I know for sure is that DumpErrors prints out the errors :D.
[14:50] <juliank> dnivra: I already pushed a fix into the debian-sid repository (mvo: fix for 647045 is in debian-sid)
[14:51] <dnivra> juliank, oh! okay then. time to find another bug. can i see the fix you made-link?
[14:51] <mvo> juliank: thanks
[14:52] <juliank> dnivra: The fix can be seen at http://bzr.debian.org/scm/loggerhead/apt/debian-sid/revision/2054
[14:52] <dnivra> it fixes both rdepends and depends? cos I had the same problem with depends too. just asking.
[14:52] <juliank> It prints 'E: No packages found' now if no package could be found.
[14:52] <juliank> dnivra: rdepends just calls depends with a reverse switch on.
[14:53] <juliank> => yes
[14:53] <dnivra> juliank, oh yeah true the same function! i forgot :).
[14:54] <juliank> dnivra: I did not want to take away your bug fun, but this was just too simple to have the ping-pong a patch involves.
[14:55] <dnivra> juliank, can i ask something- in the patch made, return _error->Error(_("No packages found"));, why is there an _ after Error(. i edited a line exactly like this-added to cmndline.cc actually but it complained error: stray '_' or something.
[14:56] <juliank> dnivra: _ is a function (well, it's a macro that calls gettext())
[14:56] <juliank> _("DD") == gettext("DD") == your translation of "DD"
[14:56] <dnivra> i see. hmmm wonder why that error arose then. oh well bug is fixed good enough :)
[14:57] <dnivra> juliank, not the first time :). i patched a bug in gedit long ago but then it was rejected by gnome/ubuntu desktop-i forget. i followed the discussion for a long time and after that lost interest seeing it won't be fixed and so unsubscribed. then, i used this bug to do a session on contributing to ubuntu-thought of showing this as a live fix-and so downloaded the latest source file only to find that the bug was fixed :).
[14:59] <juliank> dnivra: APT has around 700 other bugs (600 in Debian, 100 in Ubuntu), so if you want something to work on something in APT, you might find something.
[15:01] <dnivra> juliank, i'm okay with any bug-i'm pretty new to bug fixing. still finding my way around. been working on this bug for nearly a week now so you get the picture right :).
[15:02] <juliank> dnivra: Than you might want to hack on something else than old obscure complicated APT code.
[15:03] <dnivra> oh okay then. will do.
[15:03] <barry> ScottK: reading backlog.  re: pyrex issue.  is there a bug open on that yet?
[15:03] <ScottK> barry: no.
[15:03] <ScottK> (or not AFAIK)
[15:04] <dnivra> i picked this apt bug randomly and started on it. learnt a lot while attempting to fix it.
[15:05] <barry> ScottK: ok
[15:09] <barry> ScottK: https://bugs.launchpad.net/ubuntu/+source/python-evas/+bug/685492
[15:09] <barry> ScottK: if it turns out to be a pyrex bug, i'll open a new one
[15:11] <slangasek> RoAkSoAx: 'dh_makeshlibs -V' is low-maintenance and usually works, but it's also usually not very accurate
[15:29] <doko> seb128, pitti: could you have a look at the libgda4 build failure? gir issues
[15:33] <pitti> I have a meeting now, so afterwards
[15:38] <mdz> thanks for the brainstorm reply, pitti
[15:39] <geser> lucas, lool: re the apport FTBFS: I can reproduce it with my natty pbuilder. I usually also use tmpfs for it, so I tried without tmpfs (ext4 instead) -> same FTBFS. I've put both logs on http://www.bienia.de/tmp/ubuntu/ if you want to compare both (they differ).
[15:39] <pitti> mdz: yw; please let me know if you think I should take this anywhere else
[15:39] <mdz> pitti: I wish brainstorm had anchors for the comments; it's impossible for me to link directly to your response
[15:39] <pitti> mdz: fortunately the thread isn't very long
[15:41] <cjwatson> lamont: dunno if you noticed, but making the livefs builds use --force-unsafe-io took 16 minutes or so off the amd64 and i386 build times
[15:41] <cjwatson> (out of ~38 minutes)
[15:48] <mdz> cjwatson: is that a dpkg option?
[15:51] <ebroder> cjwatson: Do the buildds have enough RAM and/or swap that you could do the builds into a tmpfs? That made a *huge* performance difference for my livefs builds
[15:51] <cjwatson> mdz: yes, new
[15:51] <cjwatson> ebroder: https://blueprints.launchpad.net/ubuntu/+spec/other-foundations-n-cd-build-speed
[15:51] <cjwatson> "[lamont] Switch to tmpfs for non-DVD builds: TODO"
[15:52] <ebroder> Haha, ok :)
[15:52]  * ogra_ac doubts that building in swap makes a huge difference
[15:52] <ebroder> Yeah, sure - you've lost once you hit swap. The concern is more over OOMing before you can finish
[15:53] <ogra_ac> well, my builds usually happen on machines that dont have much ram
[15:53] <ogra_ac> (read ARM)
[15:56] <cjwatson> powerpc only got 6 minutes faster out of 40; armel+omap4 got 3 minutes faster out of 62
[15:56] <cjwatson> (haven't checked how much variance there is there, though!)
[15:56] <cjwatson> I imagine you need to be bottlenecked on I/O before it makes much of a difference
[16:01] <pitti> sconklin: oh, I eradicated the lucid-proposed dove kernel as well
[16:01] <sconklin> pitti: thank you
[16:09] <Daviey> Riddell: Hey!  Are you doing AA work at present? :)
[16:12] <Riddell> Daviey: at some point today i
[16:12] <Riddell> will
[16:19] <Daviey> Riddell: great..  there is a libvirt, lucid sru - i'm interested in.  no hurry. :)
[16:20] <Riddell> Daviey: bug no?
[16:22] <Daviey> Riddell: bug #668042 , in lucid unapproved queue
[16:30] <doko> ScottK: do you requeue the arm builds? do you some the order to build?
[16:31] <ScottK> doko: For qt/kde?  Yes.
[16:31] <doko> ok, thanks
[16:31] <ScottK> kde4libs should go in about 15 mnutes.
[16:32]  * doko curses Riddell for pre-promoting packages without checking that they are built
[16:32] <ScottK> doko: For reference, here's the KDE build order: https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph
[16:49] <pitti> sconklin: ah, bummer -- it seems the debdiffs generated at https://launchpad.net/~canonical-kernel-team/+archive/ppa/+packages?field.series_filter=maverick are against maverick final, not what's in -updates/-security
[16:50] <sconklin> pitti: sorry. That's an easy mistake to make, and we're working on some tools to prevent that
[16:50] <pitti> sconklin: ?
[16:50] <sconklin> (among other common errors)
[16:51] <pitti> sconklin: that's a Launchpad bug
[16:51] <pitti> the Launchpad generated debdiffs in the Ubuntu unapproved queue are fine, but it seems the ones in PPAs don't do what we need
[16:51] <sconklin> oh, sorry. We often forget to generate packages as a diff.
[16:51] <pitti> sconklin: no, that's not what I mean
[16:51] <sconklin> pitti: yeah, I get it now
[16:51] <pitti> sconklin: I mean, for review I need a debdiff against the version that's currently in that release
[16:52] <pitti> sconklin: well, at least I sufficiently fixed my tools to open all the bugs, get the .changes, etc.
[16:55] <doko> ogra_ac: your `shadow' upload doesn't build
[16:56] <RoAkSoAx> pitti: is there a change you could review bug #527195
[16:56] <pitti> RoAkSoAx: sorry, no; I'm not a MIR reviewer any more, and I'm in a meeting ATM
[16:58] <RoAkSoAx> pitti: oh ok thanks! no worries then. sorry to bother :)
[16:58] <doko> RoAkSoAx: mterry did start these reviews in the past
[16:58] <mterry> doko, yeah, I'm looking at the cluster-glue one anyway
[16:58] <RoAkSoAx> doko: yes he is doing cluster-glue :) IDK about pacemaker though.
[17:09] <jdstrand> pitti, sconklin: just a thought, as an interim solution, it should be possible for the kernelteam to add a manually generated debdiff to the SRU master bug.... not ideal, but could work until LP is fixed
[17:09] <pitti> that'd be awesome
[17:09] <pitti> (and actually that's already part of the SRU policy..)
[17:10] <pitti> bonus points if you can filterdiff -x '*/debian.master/*'
[17:10] <pitti> and all the ABI diffs (which usually account for 90% of the size)
[17:10] <jdstrand> sconklin: to generate a debdiff: debdiff <current kernel in -updates/-security>.dsc <-poposed kernel>.dsc
[17:11] <jdstrand> sconklin: and then filter as pitti mentioned
[17:11] <pitti> sconklin: alternatively, using git diff across all commits to that upload
[17:11] <jdstrand> (should be scritable-- we do it on our team)
[17:11] <cjwatson> https://help.launchpad.net/API
[17:11] <cjwatson> oops
[17:11] <pitti> if you diff against the previous tag, that should also be scriptable
[17:13] <sconklin> in a meeting, but looks like a good idea
[17:18] <mterry> doko, but actually, I wanted you to look at cluster-glue a bit.  There were some issues with libraries being bundled into one package.  That's fixed now, but then the question became to add .symbols or use makeshlibs -V.  How to best use -V with a source package that doesn't use cdbs/dh7 with lots of libraries in it?
[17:20] <doko> mterry: hm, ok, will look at these, but it's end of day for me today, and tomorrow I did plan the python transition ...
[17:21] <mterry> doko, OK.  I guess I didn't want you to look at it so much as advice regarding -V.  I'll ask another MIR person though.  See ya later
[17:22] <mterry> asac, ^
[17:22] <asac> mterry: does it use dh5?
[17:23] <pitti> barry, doko: are we going to drop support for Python 2.6 from natty, or keep 2.6 and 2.7? the former would reclaim the 9.5 MB of extra CD space that 2.7 added
[17:23] <mterry> asac, it uses dh at compat level 7, but not new-style dh.  Still lists all the dh_* items to run and such
[17:24] <doko> pitti: can we discuss this at the sprint?
[17:24] <pitti> doko: sure; I was just curious whether this was already planned, or still in the air
[17:24] <pitti> doko: thanks
[17:24] <cjwatson> .symbols means that packages depending on this one get fine-grained calculation of dependencies based on exactly which symbols they use.  -V just sets a fixed >= minimum.  you can use either - in many cases it isn't worth bothering maintaining symbols file.
[17:24] <doko> pitti: stop shipping the compiler on the CD
[17:24] <cjwatson> *files
[17:24] <cjwatson> it doesn't make much difference what source helper is involved
[17:24] <pitti> doko: which compiler?
[17:25] <doko> gcc
[17:25]  * doko is now afk
[17:25] <pitti> ergh, this isn't even meant to be shipped
[17:25] <cjwatson> yeah it is
[17:25] <pitti> doko: right, thanks for pointing out
[17:25] <cjwatson> there's a comment in the seeds about why, and everything
[17:25] <cjwatson> Here we provide a minimal development environment sufficient to build kernel
[17:25] <cjwatson> drivers, so that this is possible on the live CD and in scenarios where
[17:25] <cjwatson> it is problematic to get these packages onto the installed system in order
[17:25] <cjwatson> to compile a driver. -mdz
[17:26] <james_w> pitti, hi, could I trouble you to take a look at https://code.launchpad.net/~james-w/launchpad-work-items-tracker/multi-project/+merge/42893 soonish? We need some solution for this to have useful charts for Linaro this cycle.
[17:26] <doko> but how many people do this?
[17:26] <cjwatson> it's certainly one of the things that is debatable.  I was merely saying that it wasn't as simple as being there by accident
[17:26] <cjwatson> I have no idea how to get data
[17:26] <pitti> ah, so indeed; I thought this accidentally slipped in as a dependency
[17:27] <pitti> james_w: I got your mail; will look at it ASAP
[17:27] <asac> mterry: it probably runs dh_makeshlibs ... you just use the -vVERSION there iirc
[17:27] <pitti> so, the rallye will be a nice opportunity to have another one of these "what to kick off the CD" fights then
[17:27] <james_w> pitti, thanks. Doesn't need to interrupt your work, but I promised a solution to this this week.
[17:28] <asac> mterry: dh_makeshlibs -V'packagename (>= explicit.version)'
[17:29] <mterry> asac, yar OK.  thanks
[17:29] <RoAkSoAx> asac: but other packages don't have symbols file nor dh_makeshlibs -V'packagename (>= explicit.version)'
[17:29] <RoAkSoAx> and they just have dh_makeshlibs -V
[17:30] <cjwatson> dh_makeshlibs(1) documents what that does
[17:30] <cjwatson> and why you might or might not want to use it
[17:30] <cjwatson> the paragraph in question starts with "Beware of"
[17:30] <kees> cdbs: hi! no, it doesn't create /etc/fetchmailrc and doesn't set START_DAEMON=yes.
[17:30] <RoAkSoAx> indeed
[17:31] <cdbs> kees: hmm? /me confirms
[17:31] <cdbs> since it did that in mmy case
[17:32] <kees> cdbs: hm, did you apt-get purge fetchmail before you started? I tested in a fresh chroot.
[17:33] <cdbs> kees: well, my case is different. I installed on maverick and then upgraded to natty
[17:33] <asac> RoAkSoAx: right. but those dont track the API explicitly which is not good
[17:34] <cdbs> kees: ah, maybe a case that came up due to the upload. I can't see anything wrong with the code
[17:34] <ScottK> cjwatson: In maverick I can do a fresh install on a broadcom wifi system and get working wireless with dkms, etc from the ISO.  If we gave up on that, I would consider it a significant regression for such systems (another reason for gcc).
[17:34] <asac> e.g. indicates that the packager doesnt care about API/ABI imo
[17:34] <cdbs> s/upload/update/
[17:34]  * kees tries
[17:35] <RoAkSoAx> asac: right, but something is for sure in cluster-glue and pacemaker, ABI changes (iirc verioning of the library) doesn't happen quite often
[17:35] <cjwatson> ScottK: that's a good example, yes
[17:35] <cjwatson> (until/unless broadcom fix their stuff ...)
[17:36] <kees> cdbs: hm, nope. same thing for me still. installed maverick fetchmail in a fresh chroot, START_DAEMON=no, did an update to natty fetchmail, still set to =no.
[17:36] <cdbs> kees: okay, I am closing bug, Thanks for testing!
[17:37] <kees> you bet!
[17:37] <cdbs> Don't know how it happened, I surely remember I never modified any file there
[17:39] <asac> RoAkSoAx: right. but even there its more important to see that maintainer double checks to catch upstream mistakes etc.
[17:40] <RoAkSoAx> asac: indeed, to tell you the thruth, at first they didn't even wanted to do the library split! So it's been an strugle to get this to happen in debian
[17:41] <asac> RoAkSoAx: thanks so much for convincing debian on this!
[17:41]  * mterry has to run out. bbl
[17:42] <RoAkSoAx> asac: was not exactly convincing :) but they finally realized it was a blocker on Ubuntu after various attempts to get these packages into Main, and of course, varios rejections of patches from their side
[17:42] <asac> hehe
[17:45] <pitti> skaet_, sconklin: I made two followups to bug 683422; please let me know if you are ok with the current problems and want me to go ahead with the publication
[17:46] <sconklin> looking
[17:52] <pitti> sconklin, jdstrand: FYI, I updated https://wiki.ubuntu.com/ArchiveAdministration#Copying%20PPA%20kernels%20to%20proposed%20(DRAFT) to show how to use queuediff (I just updated it to work with PPAs)
[17:54] <sconklin> pitti: I thin that for this cycle we'll (meaning the kernel team people) just manually update the bug with the typo and keep you informed as needed, and I'll find out why armel didn't get built
[17:55] <pitti> sconklin: ok, so we'll just try and see whether it gets a proper build record in -proposed now?
[17:56] <jdstrand> ack
[18:01] <pitti> erk, this new launchpadlib keyring is awkward
[18:03] <pitti> sconklin-lunch: yup, building: https://launchpad.net/ubuntu/+source/linux/2.6.35-24.42/+build/2084938
[18:03] <BlackZ> kenvandine: bug #685860: I'm not sure I understand your comment. I built the package with the "-v" option. That debdiff will not apply to the currently package in natty, rather you should apply that debdiff to the latest version of the package available in Debian unstable (it's a debdiff debian → ubuntu)
[18:03] <kenvandine> BlackZ, i see
[18:04] <kenvandine> i thought the debdiff was the diff to ubuntu
[18:04] <BlackZ> kenvandine: no, it's not :)
[18:04] <kenvandine> so i need to get the debian unstable version, and apply the debdiff :)
[18:04] <kenvandine> sorry
[18:05] <kenvandine> will do
[18:24] <kenvandine> @pilot out
[18:46] <hallyn_> zul: for daily builds, have you switch to natty as the release, or are you still using maverick?
[18:47] <zul> im still using maverick i havent had a chance to switch to natty yet
[18:50] <hallyn_> zul: which do you think is more useful?
[18:50] <hallyn_> zul: i was thinking more ppl filing bugs fo whom i ask to use upstream would be on maverick...
[18:50] <zul> maverick for now...
[18:50] <hallyn_> kthx
[18:50] <RoAkSoAx> mterry: btw.. you working on pacemaker as well? :)
[18:59] <janimo> .join #ghc
[19:00]  * janimo oopses
[19:02] <tkamppeter> pitti, still there?
[19:16] <kklimonda> jdstrand: do you remember why have you removed locales-all from the Build-Dep of python-django? The comment is "don't Build-Depends on locales-all, which doesn't exist in maverick" but the build-dependency is locales-all | language-pack-en-base which should work on both Debian and Ubuntu (the idea was to limit delta between debian and ubuntu to bare minimum, and to make package syncable)
[19:28] <jdstrand> kklimonda: off-hand? no. but it is very likely that it didn't build with only the main component enabled
[19:29] <kklimonda> hmm, weird - I'll have to test it once more.
[19:29] <jdstrand> kklimonda: in other words, I don't change debian/control in a -security update unless I have to
[19:29] <kklimonda> jdstrand: right, I understand
[19:29] <jdstrand> kklimonda: and that is the only reason I can think of why I would do that
[19:29] <jdstrand> kklimonda: cool
[19:43] <hallyn_> where do debian syncs come from - sid?
[19:44] <hallyn_> oh, hm.  ubuntu package is patched.  so then syncs don't apply, i recon'?
[19:47] <RoAkSoAx> hallyn_: if there's an ubuntu delta, no auto-syncs will be performed for that package
[19:57] <hallyn_> RoAkSoAx: yup, thanks :)
[20:05] <ogra_ac> doko, yeah, i know, one patch needs some adjustments, i'll care for it first thing after my vacation
[20:25] <mr_pouit> mmh, I think the archive admin who accepted the new binary packages libthunarx-2-0 and libthunarx-2-dev put them wrongly in main… (thunar is in universe)
[20:42] <hallyn_> james_w: cjwatson: pitti: do you know of anyone in particular interested in being the ubuntu maintainer of multipath-tools?
[20:42] <james_w> nope
[20:42] <hallyn_> ISTM the package is bit-rotting bc of ubuntu-specific changes which should be pushed back to debian
[20:43]  * hallyn_ strokes his imaginary beard, pondering
[20:44] <hallyn_> is there any particularly good place to talk about the ubuntu package?
[20:45] <james_w> I don't know of a better one than ubuntu-devel@ or ubuntu-server@
[20:45] <hallyn_> james_w: ok, thanks
[21:19] <Roey> hi
[21:19] <Roey> Hey all, using the latest KDE 4.6 beta PPAs here.  I have Capslock mapped to an additional control, keyboard layout switcher mapped to two shift keys pressed together, and repeat delay to 200ms.  I upgraded to the latest PPAs and now these settings no longer seem to be respected, even though they show up as I configured them in System Settings
[21:19] <Roey> Has anyone else seen this?
[21:42] <soren> :( ttf-mscorefonts-installer from maverick-updates just asked me to accept an EULA.
[21:42] <ion> What’s the problem?
[21:43] <soren> I would have expected that stuff from -updates didn't require prompting.
[21:43] <soren> Unless it functionally changed stuff that I needed to be aware of. I have to expect that I've already accepted said license agreement.
[21:44] <soren> Ah, the EULA is new since maverick's release.
[22:43] <doko> barry: nipy fails on i386 only
[22:43] <barry> doko: okay thanks. i'll do a build there
[22:45] <xnox> barry, raphael hertzog recommeds to have debian/source/local-options to have unapply-patches
[22:45] <xnox> that way the tree stays "reverted" after each debuild
[22:45] <xnox> in-tree.
[22:45] <xnox> unfortunatly local-options do not make their way into source package.
[22:46] <xnox> they only stay in vcs
[22:46] <Laney> soren: the eula is new, but there's nothing stopping you patching it out AFAICS (without changing the license, which I don't think has been done). :)
[22:46] <doko> barry: and marked as a sphinx 1.0 failure
[22:46] <barry> xnox: thanks, i'll have to digest that later ;)
[22:46] <xnox> maybe our imports should generate debian/source/local-options on the checkout.
[22:47] <barry> doko: yes, bug 685180, which i'm working on now
[22:47] <xnox> barry: lp:xiphos/debian for you to play around =) it is managed like I describe
[22:47] <doko> barry: and binary-indep packages are only built on i386
[22:54] <achiang> i've a question re: bzr-style development (cf. https://wiki.ubuntu.com/DesktopTeam/Bzr)
[22:54] <achiang> the page doesn't really explain how to update a patch, say if the package uses quilt
[22:54] <achiang> or if it does explain, it's too subtle and i'm not tall enough.
[22:54] <achiang> can anyone clue me in?
[23:03] <barry> doko: nipy built fine for me on natty-i386 chroot
[23:04] <barry> i guess i'll try a ppa just to see if i can reproduce the failure
[23:04] <doko> barry: in such cases, you can give back the build and see if it still exists
[23:05] <barry> doko: i don't think i have permission to do that, but i will still try the ppa first
[23:06] <doko> barry: https://launchpad.net/ubuntu/+source/nipy/0.1.2+20100526-2build1/+build/2076394
[23:06] <doko> can you click on "Retry this build?"
[23:06] <micahg> achiang: I would think you use quilt to update a patch
[23:06] <barry> doko: no such button for me
[23:07] <doko> ok, I'll do it
[23:07] <barry> doko: thanks
[23:08] <achiang> micahg: but if i say: bzr branch lp:~ubuntu-desktop/package/ubuntu ... all i get is the debian/ dir. i can issue a pbuild because there is a file named debian/watch that will download the .orig.tar.gz
[23:08] <micahg> achiang: what does that have to do wtih anything?
[23:08] <achiang> micahg: but the source isn't unpacked... i guess i could just manually unpack it, drop the debian dir in and see what happens?
[23:09] <achiang> micahg: i must be really confused. how can quilt push possibly work if there isn't actual source code to patch? all you have is the debian/ dir...
[23:09] <micahg> achiang: oh, sorry, you're referring to the -desktop branches, you should ask them
[23:09] <achiang> micahg: oh, do they not hang out here?
[23:09] <micahg> achiang: try #ubuntu-desktop
[23:10] <achiang> micahg: thank you
[23:10] <RAOF> achiang: “bzr bd-do” should do what you're after.
[23:14] <achiang> RAOF: wow! that's magic! thank you
[23:14] <achiang> RAOF: shall i update the wiki?
[23:15] <RAOF> Which wiki?
[23:15] <achiang> https://wiki.ubuntu.com/DesktopTeam/Bzr
[23:15] <RAOF> Yeah, that's probably a good idea.
[23:15] <achiang> it has a long section about autotools, but you kinda have to read between the lines to figure out how to update a package with a patch system
[23:28] <doko> barry: still FTBFS
[23:29] <barry> doko: huh.  it definitely builds in my natty schroots.
[23:29] <doko> buildds are not lying (according to lamont)
[23:31] <lamont> barry: which package?
[23:32] <achiang> RAOF: https://wiki.ubuntu.com/DesktopTeam/Bzr?action=diff&rev2=26&rev1=25
[23:32] <barry> lamont: nipy
[23:33] <barry> doko: i'm sure they're not.  but... what's different?
[23:33] <RAOF> achiang: Looks pretty good to me.
[23:34] <RAOF> You might possibly want to link to more information on bzr bd-do; possibly just a pointer to ‘bzr help bd-do’.
[23:34] <barry> well, the ppa is building so let's see what happens
[23:34] <achiang> RAOF: thx.
[23:35] <achiang> RAOF: oh hm. sure, I guess i can do that
[23:35] <lamont> barry: the only difference between your natty chroot and the one on the buildd should be that you have a maverick kernel, and the buildd has a hardy kernel
[23:36] <RAOF> achiang: That points out other interesting things, like the ability to run a command and the ability to cancel changes.
[23:36] <achiang> RAOF: nod. adding a small little pointer now
[23:36] <barry> lamont: hmm. i wouldn't expect that to be relevant in this case, but let's see how the ppa build goes
[23:38] <lamont> ppa should be identical.
[23:40] <barry> lamont: to...? :)
[23:40] <lamont> archive builder
[23:40] <lamont> that difference is only xen vs non-xen
[23:41] <barry> and indeed it is.  ftbfs from the ppa just showed up in my inbox
[23:53] <barry> well, at least i get a different build failure now