[00:03] <slangasek> persia: today the natural package split is to have powerpc-on-powerpc via qemu-linaro, but I'm obviously flexible
[00:04] <persia> slangasek, I don't really care where to send patches, as long as the ones that were present in the past are retained.  I'm not sure all of them reached trunk.
[00:04] <persia> (but, as noted above, I don't really spend lots of time on this)
[00:04] <slangasek> ok
[00:05] <persia> slangasek, Will qemu-linaro support KVM as well, or just qemu?
[00:05] <slangasek> I don't know the answer to that
[00:06] <persia> To me, it may make sense to have the qemu-based solutions from qemu-linaro, and kvm-based from qemu-kvm, but perhaps I'm reading too much into nomenclature :)
[00:10] <broder> does anybody know of an example of how to build a bootable cd with grub2 instead of isolinux?
[00:11] <RAOF> I think cjwatson did so (for a USB rather than CD, but should be fairly similar) at the rally?
[00:14] <persia> I thought it was panda (Haitao Zhang) who was working on the multiboot grub2-based USB stick (not that others may not know, but that some folk may be busy)
[00:14] <broder> oh look - there's a page in the grub maual about it. how helpful :)
[00:14] <persia> There you go :)
[00:16] <broder> although the file it refers to only shows up in my grub legacy package, so it's possible that it's out of date
[01:26] <smoser> is there a way in a postinst to see if a debconf value has been set ?
[01:27] <smoser> i'd like to do something if its not been seen, but something else if it has
[01:34] <smoser> i'm interested in the difference between "user didn't choose anything" in a multiselect box, and "user hasn't seen the question" (due to priority)
[01:36] <persia> smoser, Could you use the seen flag for that?
[01:36] <smoser> and you get that with db_fget ?
[01:37] <persia> Right.  debconf-devel(7) mentions it
[01:37] <smoser> on my installed system, i saw exactly zero uses of 'db_fget'
[01:37] <smoser> so i thought i must be doing something wrong
[01:37] <smoser> i do see db_fset
[01:37] <persia> I think seen is usually considered a target for FSET, rather than FGET :)
[05:43] <YokoZar> If a package to be installed recommends a virtual package, and nothing providing that is currently installed, what happens?
[05:44] <Guest25428> where is mark??
[05:45] <YokoZar> Guest25428: at his island fortress I imagine
[05:45] <Guest25428> hahaha ok
[05:46] <Guest25428> he worksin this channel?
[05:51] <mneptok> Guest25428: no. but smometimes he rides by in his carriage and throws shillings to the urchins.
[05:52] <Guest25428> LOL
[06:04] <micahg> YokoZar: nothing, it should be ignored
[06:07] <YokoZar> micahg: so it doesn't pick a provider then, ok
[06:07] <micahg> YokoZar: you said nothing provides it
[06:08] <YokoZar> micahg: nothing providing it is installed
[06:08] <pitti> Good morning
[06:08] <YokoZar> micahg: but in principle uninstalled packages could provide it
[06:08] <YokoZar> I'm wondering if there's any logic to choose between them, or if it defaults to nothing
[06:08] <pitti> kees: saw your mail, will reply there
[06:08] <YokoZar> pitti: mornin :)
[06:08] <micahg> ah, hmm, well, idk then, my guess is pitti might know :)
[06:08] <RAOF> YokoZar: I believe from experience that it will pick *something*; I'm not sure how it determines it.
[06:10]  * YokoZar is dealing with some fallout of dummy/virtual packages
[06:40] <broder> https://launchpad.net/ubuntu/lucid/+queue is the right url to look for unapproved sru uploads, right?
[06:41] <broder> oh, never mind. lp finally decided to play ball
[07:20] <pitti> broder: right, select "unapproved"; for some reason the default page (NEW) times out often
[07:20] <broder> pitti: right, i knew that. i was just getting timeout errors so wasn't sure if i had the right page at all
[07:50] <pitti> cjwatson: do you have some minutes for a d-i rebuild against kernel .38?
[08:08]  * hunger wonders why his keyboard layout is currently getting broken during almost every upgrade in natty.
[08:16] <dholbach> good morning
[08:23] <janimo_> hello dholbach
[08:23] <dholbach> hey janimo_
[08:24]  * janimo_ needs to read up on patch-piloting as he's in the cockipt on Monday
[08:30] <pitti> "learn to fly in 24 hours"?
[09:24] <janimo_> can an archive admin let haskell-utf8-string binaries out of NEW, a few packages build dep on them. thanks
[09:35] <cjwatson> pitti: yes, I'm going to deal with that this morning
[09:35] <cjwatson> hunger: I have the fix for that in progress
[09:39] <cjwatson> broder: grub-mkrescue (yes, the manual is currently wrong, I'm going to fix that in a bit ...)
[09:48] <pitti> TheMuso, cjwatson: do you have an idea about bug 672699? did that ever actually work in the alternates? (that would surprise me)
[09:52] <cjwatson> pitti: there is a degree of support in d-i
[09:52] <cjwatson> oh, wait, screen reader
[09:52] <cjwatson> there's supposed to be speakup support I think
[09:52] <cjwatson> whether it works in our build ...
[09:53]  * cjwatson once again loses track of the logic of when bugs are release-targeted
[09:53] <cjwatson> yeah, our kernel doesn't provide the speakup-modules udeb
[09:56] <cjwatson> among the casualties of moving udeb handling to the kernel :-/
[09:56] <pitti> ok, so that never actually worked then; sounds like we should un-target that then and drop priority?
[09:58] <cjwatson> pitti: leave the priority where it is, I'll "close" the installer side of it by removing the boot option
[09:58] <cjwatson> we certainly shouldn't advertise it when it doesn't work
[09:58] <pitti> ah, good
[09:58] <cjwatson> I've created a kernel task for the bits I need to make it work
[09:58] <cjwatson> (and feel free to shove it from desktop->foundations in the release meeting agenda)
[09:58] <cjwatson> it can be trade for the two apport bugs I just shoved in the other direction
[09:59] <pitti> sounds fair :)
[10:12] <cjwatson> mvo: could you look at bug 590998, please?
[10:13] <mvo> cjwatson: yes
[10:13] <cjwatson> thanks
[10:36] <Riddell> cjwatson: why would packages I put in blacklist in kubuntu.natty seed collection not end up in the blacklist germinate output for kubuntu.natty?
[10:38] <cjwatson> don't use blacklist
[10:38] <cjwatson> what are you trying to do?
[10:39] <Riddell> cjwatson: avoid having geoip-database on the CD
[10:39] <cjwatson> you can't as it stands, it's in standard
[10:40] <cjwatson> the 'blacklist' file in seeds is horribly obsolete and we should probably remove it at some point (but it's not impossible that things don't properly check for its existence, so please don't just nuke it)
[10:40] <Riddell> oh well, ok
[10:40] <Riddell> I might get round to doing the kubuntu mobile seed split today
[10:40] <cjwatson> the modern blacklisting facility is '!' seed entries (see germinate(1)), but it's a great big hammer whose primary effect is to make your CDs uninstallable if apt wants to pull that package in
[10:40] <Riddell> seed collection split
[10:41] <cjwatson> it's really only meant as an alarm bell
[10:41] <cjwatson> geoip-database is pulled in because libgeoip1 Recommends it; it wouldn't necessarily hurt to investigate that ...
[11:26] <mok0> I am developing a package that needs a (rather large) amount of scientific reference data. I am thinking of a solution, where this data is placed in bazaar on LP, but is it acceptable for a postinstall script to rely on bazaar? It would IMO be a pretty neat way to install the data.
[11:49] <cjwatson> pitti: FYI I moved bug 681412 to your list on the release meeting agenda
[12:03] <ogra> fasten your seatbelts please
[12:03] <ogra> @pilot in
[12:17] <cousteau`nbk> it's weird that bug 575610 hasn't been solved yet
[12:18] <cousteau`nbk> (thanks, ubottu :) )
[12:19] <cousteau`nbk> it's a version problem; it should be easily solved (just pick the maverick package and put it in lucid repos)
[12:20] <geser> could someone please give back "gtk+2.0" on armel? it got hit by a LP bug
[12:20] <cjwatson> we never "just pick the maverick package and put it in lucid"
[12:20] <cjwatson> the fix needs to be backported
[12:20] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates for how to deal with stable updates
[12:22] <cousteau`nbk> cjwatson: the thing is, the package should have been in version 2.30 from the day Lucid was released
[12:22] <cjwatson> geser: done
[12:22] <cjwatson> cousteau`nbk: (bear in mind I know nothing about epiphany or its extensions, this is just general policy, we don't just copy packages from newer releases)
[12:22] <cousteau`nbk> it's not that "there's a newer version", it's rather than the current one causes a dependency problem when trying to install
[12:23] <cjwatson> understanding that will make it easier for you to have effective conversations with developers on fixing this kind of thing
[12:24] <cjwatson> pitti: ^- can somebody on the desktop team look at bug 575610?
[12:24] <cousteau`nbk> I mean, it would make sense to have this version on repositories if the epiphany-browser version was also 2.29, bit it's 2.30 and epiphany-extensions-more depends specifically on >=2.29 <<2.30
[12:26] <cousteau`nbk> (maybe just removing that <<2.30 restriction makes it installable and it might work anyway)
[12:36] <pitti> cjwatson: I'll put 575610 on our list, thanks
[12:57] <cousteau`nbk> cool, thanks :)
[12:59] <ogra> hallyn, around ?
[13:18] <cjwatson> pitti: could you have another look at bug 638307 (which contains past discussion between you and Clint)?  The Debian maintainer wasn't particularly happy with the idea of removing it, and a number of users have popped up saying that they still need laptop-mode-tools, which makes me uncomfortable about just removing it as an archive admin action.  What should we do about this bug?  There are clearly some pm-utils bugs in ...
[13:19] <cjwatson> ... here somewhere ...
[13:19] <cjwatson> pitti: I wonder if we should try to rearrange things to avoid the conflict with laptop-mode-tools instead ...
[13:20] <pitti> cjwatson: it would require ripping out everything from l-m-t that pm-utils already does, and then of course you couldn't use the l-m-t configuration to configure pm-utils
[13:22] <cjwatson> maybe that's the correct course of action, until such time as nobody needs it any more
[13:22] <pitti> or changing pm-utils to disable hooks when l-m-t is installed
[13:22] <cjwatson> I wonder if the new l-m-t Debian version changes this; it certainly moves the pm-utils hook around
[13:23] <pitti> but that would mean a rather large delta to upstream, so I'd rather fix it in l-m-t
[13:23] <cjwatson> (merge: bug 602881, as Bryce pointed out)
[13:25] <pitti> cjwatson: it's not yet a problem in Debian as pm-utils 1.4 is only in experimental there
[13:26] <cjwatson> pitti: right, but it presumably will be after squeeze releases
[13:26] <pitti> right
[13:27] <pitti> (the conflicts to lmt is in pm-utils experimental, too, FWIW)
[13:29] <cjwatson> pitti: yeah, I noted that in the bug
[13:33] <ogra> cnd, hey
[13:35] <ogra> cnd, i was about to sponsor mtdev-1.1.0 but the packaging tree is missing the final commit (its still UNRELEASED in the changelog), could someone with commit access do the debcommit ?
[13:50] <hallyn> ogra: what's up?
[13:50] <ogra> hallyn, i commented on the merge request now
[13:51] <hallyn> ogra: not sure which you mean, i'll see it in my inbox in a bit.  :)  sounds like I'll find some constructive criticism there, so thanks in advance :)
[13:52] <ogra> hallyn, i was just looking at your multipath-tools merge request for natty
[13:52] <ogra> but it seems you indicate in all bugs that the fixes are already there
[13:53] <hallyn> ogra: yes, the changes are in natty.  lucid and maverick needs them badly
[13:53] <ogra> and one of the bugs referred to is sadly private
[13:53] <hallyn> I'm sorry abougt the private bug.  I wonder if I can make taht public
[13:54] <hallyn> ogra: oh, sorry!  I see now
[13:54] <hallyn> ogra: yes, that merge request should be cancelled, natty has the changes.
[13:54] <hallyn> ogra:  i'm not sure what happened there
[13:54] <ogra> thanks :)
[13:54] <hallyn> ogra: so now I need the SRUs
[13:54] <ogra> i was just confused
[13:55] <hallyn> ogra: canceling that right now, thanks!
[13:59] <pitti> ev: hm, I just got a report about someone trying to install from USB stick and failing in parted; turned out that he used a persistency file which just went full
[13:59] <pitti> ev: do you really think that using this by default is a good option? perhaps we should default to not having a persistency file in usb-creator, at least not if the USB stick is < 4 GB?
[14:00] <ogra> grmpf, the hal initscript is gone
[14:01]  * ogra tries to find an old package/branch with it ... it had a beautiful chroot check in it i could need
[14:01] <pitti> ogra: it's in bzr
[14:01] <ogra> pitti, yep, looking at it now
[14:03] <pitti> bz "I never forget a bit" r
[14:04] <ogra> :)
[14:05] <cjwatson> pitti: otherwise known as br
[14:33] <ev> pitti: yeah, the current minimum is 128M which seems entirely too small
[14:34] <pitti> ev: it's the second time in a few months that I got that, that's why I'm asking
[14:35] <ev> I'm happy to increase it, but I'm just noticing that we're disabling the free space notification in at least KDE in casper
[14:35] <ev> which I'll fix as well
[14:36] <pitti> ev: cheers
[14:42] <dholbach> seb128, thanks for getting somebody on the screen corruption bug :)
[14:43] <dholbach> I was wondering if I should use a different irc client for the next few days already :)
[14:43] <smoser> i'm asking again, now at a possibly more populated time...
[14:43] <smoser> i'm interested in the difference between "user didn't choose anything" in a multiselect box, and "user hasn't seen the question" (due to priority).
[14:43] <seb128> dholbach, yw!
[14:44] <smoser> it looks like i could use db_fget, but i see no occurences of that in postinst scripts in my dpkg/info dir, so i supposed that htere has to be a different solution.
[14:45] <smoser> my goal is to dynamically set the default value of the setting based on whether it appears to be being run on ec2.
[14:45] <cjwatson> smoser: db_fget is in use in packages you almost certainly have installed, so I'm surprised.
[14:46] <cjwatson> smoser: try .config scripts instead.
[14:46] <cjwatson> smoser: the answer you got earlier was the right one
[14:46] <smoser> huh... you're correct.
[14:46] <smoser> i msust have typoed yesterday
[14:46] <smoser> embarrising
[14:46] <smoser> (typoed in my grep)
[14:47] <cjwatson> however, I'm unconvinced of the validity of you asking this question in the first place :)
[14:47] <cjwatson> are you deliberately trying to break preseeding?
[14:47] <smoser> hm.. no. i'm absolutely not trying to break preseeding
[14:47] <Riddell> pitti: what is it that makes a spec appear on http://people.canonical.com/~platform/workitems/natty/kubuntu-dev.html ?
[14:48] <cjwatson> normally you should only be using fget to do migration of seen flags between questions and other such somewhat esoteric stuff.  in normal use you should normally only need to look at the value of the question and trust it
[14:48] <pitti> Riddell: a spec must be targetted at natty, and must have work items from anyone in ~kubuntu-dev
[14:48] <cjwatson> i.e. the default value of the question should be appropriate
[14:48] <smoser> more i was trying to set the value correctly when user didn't see the question due to low priority
[14:48] <cjwatson> that's what the Default is for
[14:48] <cjwatson> in .templates
[14:48] <smoser> i was thikning with pre-seeding it woudl be set to "seen"
[14:49] <smoser> right, but a static default isn't really suitable for me.
[14:49] <cjwatson> normally yes, but preseeders often set the priority to critical as well so that they don't have to bother with non-vital questions
[14:49] <smoser> if you apt-get intsall cloud-init on your desktop
[14:49] <smoser> then rigth now, it does some stupidly long (but mostly necessary) timeouts on boot (lets not get into that)
[14:49] <smoser> so, i want to, by default configure it to not wait on the EC2 metadata service.
[14:49] <cjwatson> can you detect a suitable default at preconfiguration time, before your package is unpacked?
[14:50] <smoser> but on upgrade of someone *in* ec2, i need to turn that on ... or, possibly on first install in ec2 , but that is less necessary.
[14:51] <cjwatson> if you can detect this at preconfiguration time, then the right thing to do is usually something like this:
[14:51] <smoser> well, with 'essential' packages only, setting default in 'config' woudl be difficult.
[14:51] <cjwatson>   db_fget question/name seen
[14:51] <cjwatson>   if [ "$RET" = false ]; then
[14:51] <cjwatson>     db_set question/name $appropriate_default
[14:51] <cjwatson>   fi
[14:51] <cjwatson>   db_input $priority question/name
[14:52] <cjwatson> but if you absolutely must do it in the postinst then checking the seen flag is probably mostly ok
[14:54] <smoser> so config would be preferred, thats fine.  the only reason to not chose config was that "It should only use commands that are in essential packages"
[14:54] <cjwatson> right (plus debconf)
[14:55] <smoser> what i'm needing or wanting to do is look for the metadata wervice (an http interface). but i can probably come up with *something* there.
[14:55] <smoser> thank you cjwatson
[14:56] <RoAkSoAx> howdy!! anyone ideas of what am I doing wrong with the packaging that when I'm purging a package it shows: "dpkg: warning: while removing powernap-common, directory '/usr/lib/python2.6/dist-packages/powernap' not empty so not removed." (I'm using python-central)
[14:56] <pitti> apw: btw, the kernel is NEWed; is it supposed to be used for a2? If so, who can I ask about uploading -meta?
[14:56] <cjwatson> pitti: it had better be, the installer's using it now :)
[14:56] <pitti> ah, good :)
[14:56] <apw> pitti, thanks for that, i have an update to it (same abi number) which is going in shortly; to fix arm boot issues
[14:57] <apw> pitti, now thats repaired i will be uploading it
[14:58] <apw> cjwatson, ahh you got ahead of me, the arm issues had me stalled for a bit
[14:59] <apw> thanks both
[15:05] <apw> pitti, ok both done
[15:25] <ogra> @pilot out
[15:25] <benste> someone familar with PAM + smartcards ? - I want to try login with an existing smarcard which is not writeable for system login - but can't find the right irc ? #pam@freenode does have no one in there
[15:26]  * dholbach hugs ogra
[15:27] <ogra> dholbach, fridays are bad for me, i owe the community 30min :)  (calls and meetings until EOD now)
[15:27] <dholbach> ogra, feel free to move your slot somewhere else or swap with somebody
[15:27] <ogra> but i made at least 3.5h
[15:39] <AbsintheSyringe> uploading my first ppa, if I set it under natty will it work under lucid lets say, and vice versa. tnx
[15:42] <AbsintheSyringe> or like in debian, I'm just targeting which series I want it to see it in
[15:49] <geser> AbsintheSyringe: depends on the package (dependencies and such)
[15:58] <ScottK> pitti: Our latest sip upload drops some old transitional packages.  Calibre still uses the old sip4 in build-depends.  It should be python-sip-dev.  This will apply to Debian as well (the same changes in in New in Debian).  Do you want to fix it in Debian and sync or can I just upload the fix direct to Natty?
[15:58] <pitti> ScottK: I already got a Debian bug report for it; I'll upload a fix RSN
[15:59] <ScottK> pitti: OK.  I'll leave it between you and the NBS list.
[15:59] <pitti> ScottK: if you want to fix it now, please go ahead of course
[15:59] <ScottK> Oh.  OK.
[15:59] <pitti> but NBS should save me by then
[15:59] <ScottK> Will do.
[15:59] <pitti> s/by/until/
[15:59] <ScottK> It's easy enough just to knock them al lout.
[16:02] <ScottK> pitti: Upon futher consideration, I'll leave it to you.  It's got a hard coded depends on python2.6 that's got to change and the binary that needs SIP should depend on ${sip:Depends}.
[16:22] <microm> I don't want to create a duplicate so how do I find out the state of this significant bug in the SRU process for ubuntu 10. The bug is https://bugs.launchpad.net/inkscape/+bug/672686/comments/12
[16:23] <smoser> cjwatson, would you mind reading http://pastebin.com/xYWHTAe7 and telling me if it looks insane
[16:38] <ScottK> microm: Looks like no one has done step 2 of the SRU process.
[16:39] <debfx> Riddell: that's too bad :(
[16:44] <microm> ScottK: regarding step 2, is this something an end user like me must do?
[16:44] <ScottK> microm: Anyone can do it.  Usually it's someone who is very interested in getting the fix to the earlier release.
[16:46] <microm> ScottK: is it bug 672686 that needs to be updated or some other bug in another bug database?
[16:46] <ScottK> microm: Same bug.
[16:50] <microm> ScottK: in 2.2 where the process says "... in the development branch..." is it related to this page -> https://launchpad.net/ubuntu/+source/cairo/1.10.2-1ubuntu1
[16:52] <ScottK> If that's the version that fixed the problem.
[16:52] <ScottK> Gotta run.
[16:55] <smoser> soren, around ?
[17:06] <microm> seb128: are you planning on dong anything to help bring the cairo bug fix mentioned above to ubuntu 10 (maverick), and is there anything someone like me who does not know your process can do to help?
[17:21] <jhunt_> SpamapS: hi - I'm having trouble building your modded upstart for lucid for lp:#672177. Could I fling you the new initscripts pkg to see if you have better luck with testing this fix on lucid. I've tested it on maverick ok.
[17:22] <broder> cjwatson: do you know how to build a cd image that boots grub? do i just pass -b cdboot.img to mkisofs and make sure there's a /boot/grub/ on the image?
[17:23] <broder> actually, that doesn't seem right, but i'm not sure what i'm supposed to do
[17:25] <SpamapS> jhunt_: sure
[17:25] <cjwatson> smoser: looks like that "first time" code will run every time the package is upgraded.  I think the *\ Ec2,* case needs to be a bit more careful to actually match what the "first time" code sets it to
[17:25] <SpamapS> jhunt_: whats the trouble on lucid? IIRC, the upstart package is already in lucid-proposed
[17:25] <broder> cjwatson: oh, heh, just saw your grub-devel mail :)
[17:25] <cjwatson> broder: yes, grub-mkrescue
[17:26] <jhunt_> SpamapS: user error no doubt - pbuilder is failing to resolve the libnih versions required.
[17:26] <cjwatson> you can also do it by hand by sort of unpacking what grub-mkrescue does, but that's more work and I haven't documented it (yet)
[17:26] <smoser> cjwatson, why would it run every time the package is upgraded? on upgrade the 'seen' will get wiped ?
[17:26] <broder> cjwatson: grub-mkrescue sounds fine for my usecase
[17:26] <broder> thanks
[17:26] <cjwatson> the thing you would need to pass to -b would be a concatenation of cdboot.img and an appropriately generated core.img, and you also need to think about the prefix and how grub.cfg should work
[17:27] <cjwatson> smoser: why would 'seen' be wiped on upgrade?
[17:27] <smoser> i wouldn't hvae thought it would
[17:27] <smoser> but you said the "first time code" will run every time the package is upgraded
[17:27] <cjwatson> smoser: I think you're missing my point - since it's a low-priority question, it will never be shown for most people
[17:27] <cjwatson> which means the seen flag will never be set
[17:28] <cjwatson> you probably shouldn't set it yourself - instead you need to arrange that that code is a no-op after it's been run once
[17:29] <cjwatson> anyway, got to go
[17:29] <smoser> fooey.
[17:29] <smoser> ok. have a nice weekend.
[17:29] <cjwatson> ta
[17:29] <SpamapS> jhunt_: any movement on getting sysvinit's package import fixed btw?
[17:31] <jhunt_> no sign yet (bug 708655 raised on udd).
[17:33] <SpamapS> james_w: ^^
[17:33] <SpamapS> james_w: pretty please. :)
[17:37] <SpamapS> jhunt_: got your email. This is intended for natty, yes?
[17:37] <jhunt_> SpamapS: that was lucid
[17:38] <SpamapS> jhunt_: ahh ok. There's no .diff
[17:39] <jhunt_> SpamapS: sorry - on its way....
[17:50] <SpamapS> jhunt_: ok, tests commencing
[17:59] <jhunt_> SpamapS: gr8
[17:59] <SpamapS> jhunt_: btw, the version should eventualy be ubuntu17.1 not ubuntu18
[18:03] <jhunt_> SpamapS: in which case, I made that mistake 3 times I think :)
[18:06] <SpamapS> jhunt_: for natty its incremented as such.. but for SRU's the . notation ensures that the next version will supercede it on upgrade
[18:06] <SpamapS> supersede? supercede? Hrm.. irssi.. why don't you have spellcheck?
[18:13] <shadeslayer> hi, im working on project neon and have a small issue with mono
[18:14] <shadeslayer> one of my packages is searching for usr/lib/mono/qyoto/qt-dotnet.dll
[18:14] <shadeslayer> but i have it installed in /opt/project-neon/usr/lib/mono/qyoto/qt-dotnet.dll
[18:14] <shadeslayer> any ideas on how to export the proper vars on this would be helpful :)
[18:15] <shadeslayer> [ preferably CMake vars ]
[18:55] <ari-tczew> bryceh: ping
[19:01] <SpamapS> jhunt_: so, I have a pristine lucid now with upstart and eglibc upgraded.. and still fails to remount /... now trying your version of sysvinit
[19:05] <SpamapS> jhunt_: still get the 'mount / is busy' message, but I think thats just the first of the remounts failing.. there is no fsck.
[19:09] <kees> seb128: what is going on with bug 708911?
[19:10] <kees> soren: you too
[19:31] <SpamapS> hrm
[19:32] <SpamapS> jhunt_: still issues.. but it seems to be sshd's fault
[19:32] <SpamapS> sshd is not being stopped...
[19:33] <SpamapS> which is probably bug 603363
[19:33] <SpamapS> which.. I was supposed to fix for lucid.. whoops.. never did push up that branch :P
[19:33] <SpamapS> but.. here's a question.. shouldn't sshd be restarted whenever libc6 is upgraded?
[19:42] <SpamapS> DOH .. invoke-rc.d runs the init.d script!
[19:48]  * kirkland wonders if he can upgrade his desktop without loosing a half day of productivity ...
[19:53] <iulian> There is only one way to find out, kirkland.
[19:53] <kirkland> iulian: indeed, i have taken the plunge
[19:54] <iulian> Heh. :)
[19:56] <seb128> kees, what do you mean about the bug?
[19:57] <seb128> kees, you made a fix for the uid thing which got dropped since because refactored their code which was supposed to do the job
[19:57] <seb128> kees, seems it doesn't, soren suggested a fix which bring back the bug from before you fix though
[19:59] <SpamapS> cjwatson: I would love to get your thoughts on this bug I just filed: bug #709468
[19:59] <barry> SpamapS: i think cjwatson is eow
[20:00] <SpamapS> right.. I would hope so.. :)
[20:01] <soren> smoser: Yes.
[20:01] <smoser> soren, i got what i was after, thanks for responding though
[20:01] <soren> kees: What's the motivation for the login.defs parsing anyways? Debian Policy seems quite clear?
[20:01] <sebner> kirkland: natty?
[20:01] <soren> smoser: Cool beans.
[20:02] <kirkland> sebner: yes
[20:02] <sebner> kirkland: works here, haven't rebooted into the new 38er kernel yet though :D
[20:02] <kirkland> sebner: yeah, upgrade succeeded, haven't rebooted
[20:02] <sebner> kirkland: not rebooting .. the best you can do :D
[20:03] <kirkland> sebner: that's the question ;  can i reboot and do anything but fight X and compiz and desktop issues for the rest of the day :-)
[20:03] <sebner> kirkland: just hibernate .. the weekend is near ^^
[20:05] <hallyn> kirkland: i've been afraid to upgrade all week.  i'm going to try it this weekend i think :)
[20:06] <kees> soren: "policy"? it's a configurable. gdm should respect it.
[20:06] <kees> seb128: I did rework the patch once already. it seems pitti just dropped it though?
[20:06] <seb128> kees, right
[20:07] <seb128> "  * Drop 24_system_uid.patch; upstream handles this more dynamically now, and
[20:07] <seb128>     we really want to show users with an ID of < 1000 (but >= 500)."
[20:07] <soren> kees: DEbian Policy defines uid classes.
[20:07] <kees> soren: login.defs is where the system vs user uid stuff is defined
[20:07] <seb128> is the changelog entry, so maybe check with pitti next week why he dropped it
[20:07] <kees> what's weird is that I'm running 2.32.0-0ubuntu5, and my uid still showed up.
[20:08] <seb128> kees, not sure why he dropped it, I was just pointing that soren's patch will put us back in the previous bug situation
[20:08] <kees> soren: what change did you make?
[20:08] <seb128> kees, which might be ok but is not ideal
[20:08] <seb128> kees, the vcs is on the bug
[20:08] <kees> I want to still log in :)
[20:08]  * kees looks
[20:08] <soren> kees: I changed the minimal uid from 500 to 1000.
[20:08] <kees> soren: oh! yeah, no. I need to log in :)
[20:09] <soren> kees: Why is your uid < 1000?
[20:09] <maco> soren: because he <3 red hat?
[20:09] <soren> maco: I
[20:09] <soren> I've always suspected.
[20:09] <kees> soren: because I switched to Debian from RedHat in 2002, and I have a home directory/NFS server.
[20:09] <kees> there's no reason to change my uid; that's just silly
[20:10] <kees> gdm should respect the configured uids, since they are configurable. login.defs is that configuration.
[20:10] <soren> kees: Hey, talk to Debian Policy. :)
[20:10] <soren> I didn't write it.
[20:10] <kees> soren: no; that's what defines the defaults in login.defs.
[20:10] <soren> I just changed the defaults to match what ought to be the defaults.
[20:10] <kees> soren: all the tools that implement user vs systme uids read login.defs
[20:10] <soren> Except GDM.
[20:11] <kees> exactly. gdm is wrong.
[20:11] <soren> Which had a wrong default. I'm not aguing against reinstating your login.defs parsing.
[20:11] <seb128> well if you read the upstream bug on the bug kees fixed the gdm agreed it's a bug
[20:11] <kees> the login.defs patch needs to be restored.
[20:11] <kees> right
[20:11] <soren> I'm just saying that if it needs to have a default I really do think that default should obey DEbian (and Ubuntu) Policy.
[20:12] <soren> It's really not very ambiguous. <1000 is system users.
[20:12] <soren> We just happen to be lucky enough that very few people have more than 401 system users.
[20:12] <soren> (0-100 being globallly assigned)
[20:12] <maco> 401?
[20:12] <kees> soren: your change will break my systems. it was blind luck that pitti's dropping of my patch didn't break my systems.
[20:12] <maco> oh
[20:13] <soren> kees: You can still log in. You just don't show up in the gdm face browser.
[20:13] <soren> Right?
[20:13] <kees> soren: your change will regress an actual bug. please revert it.
[20:15] <soren> I'm not going to revert it. I might add your login.defs parsing, though. That way, the default is what is in debian policy, but if locally overridden, that will take precedence.
[20:16] <soren> You may disagree with Debian Policy. That's fine. So do I on various points. Nevertheless, it says what it says.
[20:16] <seb128> soren, not sure what is best, not showing some users or showing some that don't need to be there
[20:16] <soren> I'm not going to complain if *you* revert it though.
[20:17] <kees> so, patching the upstream source to fix a theoretical bug should not trump leaving it as-is to not regress a real bug. but yeah, the correct fix is the login.defs parsing. adding that is the best of all three options.
[20:17] <seb128> ideally the parsing logic would come back
[20:17] <seb128> until then we should default to list extra users rather than drop some off the login
[20:19] <soren> screw it. This is silly. I've reverted my change.
[20:19]  * SpamapS wouldn't mind seeing what ftp and uucp's faces look like after all these years sharing systems with them...
[20:20] <soren> Maybe some other day I'll learn to understand what purpose those uid classes serve in debian policy if it's not to describe what we should use as defaults for exactly this sort of stuff.
[20:23] <soren> bzr lacks a --introduces lp:123456  option.
[20:23] <seb128> soren, well the policy works for new installs
[20:24] <seb128> it doesn't mean there is not old install around or nfs configs why don't conform to it
[20:43] <janimo_> doko, what do pyconfig.h files provided by python 2.6 and 2.7 reflect? Should they be as different as they are now?
[20:44] <janimo_> doko, in particular the 2.7 one defines   _POSIX_C_SOURCE while 2.6 does not. This causes an autoconf warning and python2.7 is not detected by LibO conmfigure script
[20:47] <janimo_> doko, mailed you
[20:51] <sebner> cyphermox: I just noticed that you are the new master of the network-manger :) Mind taking a look at buh #708118 ? Quite annoying for me
[20:51] <sebner> bug #708118
[20:58] <cyphermox> sebner, hey ;)
[20:58] <cyphermox> sure, I saw it already it's the current top of stack :)
[21:14] <kees> soren: I'm not sure why pitti dropped that patch. I ported it in about 5 minutes. I'll push something to the repo in a few minutes and we can both be happy :)
[21:21] <soren> kees: Happy sounds good. I could use a bit of that right now.
[21:22]  * kees hugs soren
[21:34] <soren> kees: :)
[21:50] <jdstrand> soren: dude!
[21:50] <jdstrand> soren: how are you?
[21:56] <soren> jdstrand: Tired :)
[21:57] <soren> jdstrand: Three months release cycles means twice as many release weeks a year.
[21:58] <jdstrand> jdstrand: heh, sorry man :)
[21:59] <jdstrand> soren: funny, waiting for your response, I came across something I wanted to ask you about. axis2c has you listed as the maintainer
[21:59] <jdstrand> soren: are you interested in fixing FTBFS for it?
[22:01] <soren> jdstrand: HAHAHAHAHHA!
[22:02] <soren> jdstrand: Sorry. I mean: No, not really.
[22:02] <jdstrand> soren: I'm going to jot that down as a tentative 'yes'
[22:02] <jdstrand> soren: thanks! :P
[22:02] <soren> jdstrand: Of course you are :)
[22:02] <jdstrand> soren: seriously, no worries. I'll poke someone else
[22:17] <geser> jdstrand: are you perhaps interested in reviewing/sponsoring https://code.launchpad.net/~geser/ubuntu/natty/subversion/merge_1.6.12dfsg-4/+merge/47822 (it merges two CVE fixes from Debian)
[22:21] <jdstrand> geser: I'm going to point you to mdeslaur. he is eod but working on subversion already
[22:22] <jdstrand> geser: I don't know if he has looked at natty yet or not
[22:22] <mdeslaur> nope, I haven't
[22:22] <jdstrand> oh, hi mdeslaur :)
[22:22] <mdeslaur> hello :)
[22:22] <mdeslaur> waiting for pizza to arrive :)
[22:22] <jdstrand> hehe
[22:22] <jdstrand> sounds good
[22:22] <jdstrand> my long lunch did not actually include eating...
[22:23] <jdstrand> but I am actually >< close to eow myself...
[22:26] <mdeslaur> geser: I don't have time right now, but I'll gladly look it over when I have a minute this weekend or monday morning
[22:26] <geser> mdeslaur: thanks
[22:27] <ari-tczew> mdeslaur: kebab rulez :P
[22:28] <mdeslaur> ari-tczew: hehe, indeed, but not tonight :)
[22:29] <ari-tczew> mdeslaur: then eating on night is not healthy ;-)
[23:30] <ari-tczew> geser: didn't you open bug for subversion merge?