[00:00] <bdrung> doko: even openjdk-6 fails
[00:00] <doko> bdrung, file a report, even with patches
[00:01] <doko> and fixing eclipse issues as well .... ;-P
[00:03] <hallyn> slangasek, I'm working on spice MIR right now
[00:03] <hallyn> well, not RIGHT now.  it's dinner time
[00:05] <hallyn> slangasek, MIR for spice was not feasible for oneiric cycle.  qemu-kvm-spice was.  Now, it's unfortunate that in the end we missed oneiric after all :)
[00:07] <bdrung> doko: first step done: bug #879167
[00:08] <bdrung> doko: next step for me: go to bed :p
[00:10] <bdrung> doko: btw, should openjdk multiarch already work in oneiric?
[00:11] <doko> bdrung, yes with 7, no with 6
[00:19] <bdrung> doko: doesn't work too: bug #879170
[00:33] <slangasek> hallyn: ah.  Do you know if qemu-spice could reasonably be built from the qemu-linaro branch?
[00:35] <hallyn> i think so
[00:35] <hallyn> its in universe right?
[00:37] <slangasek> yes
[00:37] <hallyn> i figured you were pinging me on lvm+udev :)
[00:37] <slangasek> so maybe that would be better than having Yet Another Build?
[00:37] <slangasek> nah, I was leaving lvm+udev for another day :)
[00:37] <hallyn> well it is a different tree...
[00:38] <hallyn> and we'd need a separate configure+make in any case
[00:38] <slangasek> you saw the change proposed on the bug?  I don't know what --noudevsync does
[00:38] <slangasek> sure, but keeping it in a single source package means one fewer source package to be uploaded for each upstream release
[00:38] <hallyn> true.
[00:39] <hallyn> i don't know that the people who want spice woudl care much about it being qemu-based instead of qemu-kvm-based
[00:39] <hallyn> so it might be doable
[00:39] <hallyn> i personally dont' much care, apart from these poor folks being able to use spice at last :)
[00:39] <slangasek> OTOH, if you're doing an MIR for spice anyway, maybe we should wait for the outcome of that before changing the packaging
[00:40] <slangasek> but if we don't get spice in main, I'd like to pull this into qemu-linaro
[00:40] <hallyn> ok, that sounds like a good plan
[00:40] <hallyn> thanks :)
[00:40] <slangasek> thank you!
[00:41] <hallyn> i'll look into EXACTLY what --noudevsync brings and comment later
[00:41] <hallyn> i fear it will just hide boot problems
[00:41] <penguin42> but you need the kvm built to have the spice stuff enabled?
[00:41] <hallyn> penguin42, kvm would be enabled.
[00:42] <hallyn> the qemu and qemu-kvm trees are pretty darned close these days
[00:42] <hallyn> minor differences wrt io threads and such
[00:42]  * penguin42 shudders
[00:42] <hallyn> at what?
[00:42] <penguin42> io threads :-)
[00:42] <hallyn> heh
[00:42] <hallyn> aio threads i should say
[00:53] <hallyn> grr, yeah i guess bug 878162 showed me the dependency chain for spice MIR.  That is NOT pretty :)
[04:15] <pitti> Good morning
[04:15] <pitti> stgraber: pong
[04:35] <pitti> lool: can you please commit your udev changes to lp:~ubuntu-core-dev/ubuntu/precise/udev/ubuntu ? (there's no diff in LP yet)
[05:45] <didrocks> good morning
[06:08] <mbiebl> pitti: hi
[06:08] <mbiebl> we were talking some time ago about updating g-i and pygobject in debian
[06:09] <mbiebl> and seb128 was mentioning, that you would take care of that
[06:09] <mbiebl> (for exp, ie)
[06:10] <pitti> hey mbiebl
[06:11] <pitti> mbiebl: I'm happy to do that, yes; but we really need a newer glib
[06:11] <mbiebl> 2.30.1 landed in exp some days ago
[06:12] <mbiebl> I assume that should be sufficient
[06:12] <pitti> oh, nice!
[06:12] <pitti> mbiebl: I'll update the packages today then
[06:12] <mbiebl> great, thanks
[06:13] <mbiebl> this way we can stage some of the 3.2 changes in exp until the current GNOME 3 transition is ongoing
[06:20] <pitti> slangasek: committed your udisks multi-arch fix to debian git, so we can sync again next time. thanks!
[06:21] <pitti> ah, I see your deiban bug, thanks
[06:56] <lool> pitti: Done, thanks; odd that I don't see it in the package import queue
[06:56] <lool> albeit, import-dsc didn't work because the upstream tag was "173" instead of "upstream-173"
[06:56] <pitti> LP has trouble generating udev diffs, because of the test/sys stuff
[06:56] <pitti> lool: this isn't an UDD branch
[06:56] <pitti> it's derived from the upstream trunk bzr import
[06:56] <lool> oh right
[06:56] <pitti> i. e. a manual one
[06:57] <lool> I guess we could replace the UDD branch with it, but I don't work on udev often enough that I should push for this myself
[07:02] <dholbach> good morning
[07:22] <soren> mvo: http://paste.ubuntu.com/714898/ <--- Does this sound familiar at all? (from #ubuntu-installer last night)
[07:26] <mvo> soren: no, sound like it failed to download the signature file for some reason? is this a common failure or was it a one-off thing?
[07:26] <soren> mvo: That was two people reporting it.
[07:26] <soren> mvo: And hour and a half apart.
[07:27] <soren> mvo: So at least a two-off thing :)
[07:32] <mvo> soren: hm, hm, thanks!  I wonder if maybe one of the archive.ubuntu.com servers was/is out of sync, I est now
[07:35] <mvo> soren: thanks, that is fixed onw
[07:40] <soren> mvo: \o/ Thanks.
[07:42] <mvo> thank you!
[09:53] <xtian> slangasek: ping
[09:58] <xtian> cjwatson: ping
[10:03] <xtian> cjwatson, slangasek: i've filed https://bugs.launchpad.net/ubuntu/+source/apt/+bug/879324 for this supposed multiarch-misfeature of apt
[10:06] <xtian> cjwatson, slangasek: (the issue we talked about yeasterday)
[10:07] <cjwatson> xtian: ok, I was just helping you narrow it down, I doubt I'll be fixing it ;-)
[10:07] <cjwatson> so no need to ping me
[10:07] <cjwatson> but thanks for filing that
[10:08] <cjwatson> I can confirm joe is currently in sync between amd64 and i386
[10:08] <xtian> cjwatson: ok thanks anyway :)
[10:08] <cjwatson> although it was changed relatively recently
[10:09] <xtian> cjwatson: yeah, depends on the mirror you're using. i tried with german mirrors today, but could not reproduce, since these mirrors caught up overnight
[10:09] <cjwatson> there was a period of about two hours on Monday when amd64 and i386 had different versions of joe in precise
[10:09] <xtian> cjwatson: that's why i picked a mirror with a reasonable lag for reproducing :)
[10:11] <xtian> cjwatson: interesting detail maybe, the misfeature shows with 'apt-get dselect-upgrade' only, not with 'apt-get upgrade' or 'apt-get install'
[10:12] <xtian> (it's all there in the report, detailed console logs of what i did included)
[10:12] <xtian> ...moving on...
[10:15] <cjwatson> yep, that definitely looks like a good way to narrow it down; I'll mark it Confirmed
[10:15] <cjwatson> or actually triaged
[12:21] <mdeslaur> !pilot in
[12:21] <mdeslaur> argh
[12:21] <mdeslaur> @pilot in
[12:23] <nigelb> heh
[12:23] <nigelb> mdeslaur: TGIF? :)
[12:23] <mdeslaur> nigelb: hehe :)
[12:55]  * dholbach hugs mdeslaur
[12:55]  * mdeslaur hugs dholbach back
[13:02] <mdeslaur> mvo: hi!
[13:02] <mdeslaur> mvo: I installed a couple of maverick machines yesterday, and the "upgrade to new release" window that popped up points to an invalid URL: http://archive.ubuntu.com/ubuntu/dists/natty-proposed/main/dist-upgrader-all/0.150.2/ReleaseAnnouncement.html
[13:03] <mdeslaur> mvo: are you aware of that? I also seem to recall someone saying the tarball couldn't be downloaded to upgrade maverick also
[13:03] <soren> mdeslaur: Fixed earlier today.
[13:03] <mdeslaur> soren: ah, cool. thanks!
[13:03] <mdeslaur> mvo: never mind :)
[13:03] <soren> mdeslaur: http://paste.ubuntu.com/715103/
[13:04] <mdeslaur> hmm...the web page still doesn't seem to be there though
[13:04] <mdeslaur> unless the url got changed with whatever mvo changed
[13:06] <cjwatson> 0.150.2 has been garbage-collected; the current version is 0.150.5
[13:06] <cjwatson> shouldn't it be using current anyway?
[13:06] <stgraber> pitti: that ping was for yesterday's TB meeting :)
[13:06] <cjwatson> unless this is a version-specific tarball that's being downloaded, but then why is it an out-of-date version ...
[13:06] <pitti> stgraber: erk, I wasn't at home last night; sorry, I thought it was next week
[13:07] <Chipzz> cjwatson: another question that pops to mind is why the archive is hosting a .html file... doesn't look like the proper place to me
[13:07] <mdeslaur> cjwatson: this was a fresh installation from cd media
[13:07] <mdeslaur> without updates installed
[13:07] <cjwatson> hm, changelogs.ubuntu.com lists current
[13:07] <Chipzz> but that may be a matter of (subjective) opinion
[13:07] <cjwatson> the archive's a reasonable place in this case, given that it comes from a custom upload
[13:08] <cjwatson> mdeslaur: is it possible that http://changelogs.ubuntu.com/meta-release has been cached?
[13:08] <cjwatson> mdeslaur: force-refreshing that might help
[13:08] <Chipzz> well it feels wrong to me. I'm used to archive.ubuntu.com and ftp.debian.org only hosting .deb's, sources, Packages etc...
[13:09] <Chipzz> but again, subjective opinion :)
[13:09] <cjwatson> Chipzz: installer kernels, initrds, package index translations, ...
[13:09] <cjwatson> (to list a few other things that live in custom uploads)
[13:09] <mdeslaur> cjwatson: I don't know where it would get cached...there's nothing on my network that would cache it, and this was two fresh installs, immediately after reboot
[13:09] <cjwatson> mdeslaur: "transparent" proxy at your ISP
[13:09] <mdeslaur> possibly
[13:09] <Chipzz> cjwatson: right, but those are all still closely related, and binary data, instead of a document
[13:09] <mdeslaur> hope not :)
[13:10] <cjwatson> mdeslaur: open that URL in a browser, look for the ReleaseNotes/ReleaseNotesHtml entries in the Dist: maverick block
[13:10] <cjwatson> er, Dist: natty I mean
[13:10] <Chipzz> cjwatson: for example, http://www.ubuntu.com/download/ubuntu/download isn't hosted on a.u.c either
[13:11] <mdeslaur> cjwatson: looks fine here...it's the "current" url
[13:11] <cjwatson> Chipzz: *shrug* this doesn't cause any harm and it arises from the structure of the software involved, I don't see that it's worth rearchitecting
[13:11] <Chipzz> but I'll shut up and keep my opinion to myself :)
[13:11] <mdeslaur> I wonder where it got the versioned url from
[13:11] <cjwatson> the current symlink points to 0.150.5
[13:11] <doko> TheMuso, pitti: not sure who handles audio stuff in general, please see bug 879434
[13:11] <cjwatson> mdeslaur: have you done a test install today?
[13:11] <mdeslaur> cjwatson: I'll try a fresh install now to see
[13:12] <cjwatson> mdeslaur: because that file was last modified this morning
[13:12] <cjwatson> mdeslaur: so I suspect mvo edited it during the conversation soren pasted above
[13:12] <mdeslaur> cjwatson: oh, d'uh...sorry, my installs were from yesterday
[13:12] <cjwatson> right, so I think it was fixed today
[13:12] <mdeslaur> ok, cool. thanks cjwatson
[13:15] <cjwatson> sigh, I really must write an actual germinate test suite; this is tedious
[13:17] <smoser> anyone know why sudo forks and not execs ?
[13:17] <smoser> ie, 'sudo sleep 1m'
[13:17] <smoser> then i'll have 2 processes running, the sudo and the sleep.
[13:18] <smoser> why wouldnt sudo exec sleep?
[13:18] <soren> To keep track of the pam session.
[13:19] <soren> If you exec, there's nothing left to close the pam session.
[13:19] <soren> smoser: ^
[13:19] <smoser> that makes sense.
[13:19] <smoser> i was looking at rabbitmq-server, which on start up has like 8 differen't sh -c hanging around
[13:19] <smoser> (ok, 3)
[13:20] <smoser> and was trying to get rid of some of them, but i can't get rid of the 'su'
[13:20] <smoser> thats why i was asking
[13:20] <soren> Yeah, we have the same problem in OpenStack.
[13:20] <Daviey> smoser: are you working on the rabitmq-server remove bug?
[13:20] <soren> The ideal solution (AFAICS) would be if upstart would support setuid'ing on its own.
[13:21] <smoser> Daviey, well, sort of.
[13:21] <soren> For now, we have to resort to su which does the same.
[13:21] <Daviey> smoser: surely that is a binary question? :)
[13:21] <smoser> well, i was aware of that bug.
[13:22] <Daviey> smoser: handy, because you raised it :)
[13:22] <smoser> and that (bug 878597) and bug 878600 was what made me look at it.
[13:23] <smoser> soren, so this seems like the best i can do:
[13:23] <smoser> http://paste.ubuntu.com/715116/
[13:23] <soren> smoser: Yup.
[13:23] <soren> Unless rabbitmq could learn how to setuid.
[13:24] <smoser> right.
[13:24] <soren> Or upstart could.
[13:24] <soren> Well, either that, or you write a custom wrapper thing to do it, but that's an entirely different kettle of fish.
[13:24] <cjwatson> https://bugs.launchpad.net/upstart/+bug/586942
[13:25] <smoser> soren, or modify sudo so it could exec for me (or su to do the same). thats why i originally asked about sudo.
[13:25] <soren> cjwatson: Oh, so that'll probably have the same sort of issue.
[13:25] <smoser> but i assumed there was good reason.
[13:25] <cjwatson> soren: no, I don't think so
[13:26] <soren> cjwatson: No? How would you take care of closing the pam session?
[13:26] <cjwatson> Scott isn't saying "setuid needs to have a PAM session", he's saying "use a different keyword (i.e. setuid not user) because the user keyword is going to imply a PAM session"
[13:27] <cjwatson> basically just a quibble with the text of the bug description
[13:27] <soren> cjwatson: Ah, right, yes. I meant the "user" directive would exhibit similar behaviour (i.e. the "extra" process hanging around just for this purpose).
[13:27] <soren> cjwatson: I didn't realise there were plans for both.
[13:28] <cjwatson> Probably, unless pid 1 learned about PAM (which might be a bad idea)
[13:28] <soren> cjwatson: YEah, I think it's unsafe to assume that pam modules won't mess things up when closing the session.
[13:29] <cjwatson> I mean I suppose you could marshal the PAM state back to pid 1 and then it could start a new process just to close the session, but (a) I don't know if that would even work and (b) it sounds like a lot of bother to save a process
[13:30] <soren> Yeah. It sounds like no fun at all.
[13:31] <smoser> ok. related question.
[13:32] <smoser> other than not depending on sudo, is there any reason i would not want to use sudo to change permissions rather than su ?
[13:32] <soren> su is always present.
[13:32] <soren> sudo might not be.
[13:33] <soren> and sudo's config is more prone to being screwed.
[13:33] <smoser> i dislike the fact that su executes things through sh
[13:33] <smoser> as root to non-root, sudo is not likely screwed i would think.
[13:34] <soren> Nope.
[13:34] <soren> Try it :)
[13:34] <smoser> yeah, you're right.
[13:34] <smoser> that does suck.
[13:34] <smoser> it should just get out of your way.
[13:35] <smoser> am i right that there is no sane way to get su to execute things without re-shell-quoting like at http://paste.ubuntu.com/715120/
[13:37] <soren> I'm not entirely sure why it doesn't just use "$@".
[13:37] <smoser> because su sucks
[13:37] <smoser> su -c "command"
[13:37] <smoser> not
[13:37] <smoser> su -c "command" "arg1" "arg2"
[13:37] <cjwatson> smoser: su is awful for this.  Personally I use a tiny perl wrapper for this job.
[13:38] <soren> su -- "command" "arg1" "arg2"  ?
[13:38] <soren> Wouldn't that work?
[13:38] <cjwatson> (I used to use start-stop-daemon; that's still OK for things that aren't liable to be installed via debootstrap.
[13:38] <cjwatson> )
[13:38] <smoser> su sucks, soren. try it.
[13:38] <soren> Well, really: su -- "command" "$@"
[13:38] <cjwatson>     # start-stop-daemon isn't available when running from debootstrap.
[13:38] <cjwatson> (man-db.postinst)
[13:38] <cjwatson>     perl -e '@pwd = getpwnam("man"); $( = $) = $pwd[3]; $< = $> = $pwd[2];
[13:38] <cjwatson>              exec "/usr/bin/mandb", @ARGV' -- "$@" || true
[13:39] <cjwatson> But modifying rabbitmq to have a drop-privileges option surely wouldn't be that hard.
[13:40] <cjwatson> <root@sarantium ~># su cjwatson -c echo foo bar
[13:40] <cjwatson> Sessions still open, not unmounting
[13:40] <cjwatson> <root@sarantium ~># su cjwatson -- echo foo bar
[13:40] <cjwatson> /bin/echo: /bin/echo: cannot execute binary file
[13:40] <cjwatson> Sessions still open, not unmounting
[13:40] <cjwatson> su really has an awful command-line syntax.
[13:40] <jamespage> I've switched most of my use of start-stop-daemon to daemon with upstart (although that is not in main)
[13:40] <cjwatson> <root@sarantium ~># su cjwatson -c 'echo foo bar'
[13:40] <cjwatson> foo bar
[13:40] <cjwatson> Sessions still open, not unmounting
[13:41] <soren> Madness.
[13:41] <cjwatson> it wants it all in one arg, which is a quoting nightmare.
[13:41] <soren> So that happens to the stuff after "--" ?
[13:41] <smoser> cjwatson, so for the perl magic novice.. the stuff up there is going to change perms to the man user ?
[13:42] <cjwatson> Interfaces designed sometime in the last decade or two tend to be sensibly adverbial and not require differing levels of quoting.
[13:42] <cjwatson> smoser: yes
[13:43] <cjwatson> smoser: I should probably change mandb to have a drop-privileges option instead, though, given that it already has all the code for that.
[13:43]  * smoser imagines cjwatson sitting there thinking "duh, smoser, that was *so* obvious! $( = $).."
[13:43] <cjwatson> no, I have to look those up too :-)
[13:43] <cjwatson> there are more friendly spellings of it but they require 'use English'
[13:48] <tumbleweed> please mark merged: https://code.launchpad.net/~paulbrianstewart/ubuntu/oneiric/visualvm/813165-formattingTypo/+merge/68469
[14:33] <mvo> mdeslaur: yeah, I'm really sorry for the trouble with this last night, a new SRU broke it, it used the explicit version to workaround a old issue that launchpad does not copy the release upgrade from -rpopsoed to -updates. but now this is done manually be the archive-admins so the current symlink in -updates works
[14:33] <smoser> soren, cjwatson. just fyi, i realize that getopt is completely capable of correctly quoting variables for you.
[14:33] <smoser> so
[14:33] <smoser> sh -c 'x=$(getopt -s sh -o "" -- -- "$@"); x=${x# --}; exec su -c "set -- $x; \"\$@\""' arg0 echo howdy world
[14:33] <mdeslaur> mvo: no problem, I just wanted to make sure you were aware of it
[14:34] <mvo> mdeslaur: indeed, thanks for this, if something like this happen, you can always mail the issue to me too if I'm not on irc :)
[14:35] <mdeslaur> mvo: cooll, thanks
[14:41] <soren> smoser: My eyes began watering when I read that. Seriously.
[14:41] <smoser> well, it works, and its more reliable than the sed in the pastebin i showed earlier.
[14:42] <smoser> but other than being in /usr/bin, getopt is probably pretty likely to be around.
[14:43] <soren> "Priority: required" agrees.
[14:43] <soren> As does "Essential: yes"
[14:44] <AnAnt> Hello, is there a way to control the logo position in unity-greeter ?
[14:44] <SpamapS> FreakinInstallMe: uh-huh  is the only one stronger than that
[14:44] <SpamapS> AnAnt: you probably want #ubuntu ;)
[14:45] <SpamapS> smoser: Isn't 'getopts' built in to dash/bash ?
[14:45] <smoser> it is not.
[14:46] <smoser> oh. wait. getopts is.
[14:46] <smoser> getopt is not
[14:46] <SpamapS> smoser: can you make it work w/ getopts ?
[14:46] <smoser> getopt is IMO actually usable for parsing parameters. but getopts is not.
[14:46] <smoser> but yeah, maybe you could.
[14:46] <Chipzz> smoser: heh
[14:47] <Chipzz> smoser: a page I just read yesterday actually claims the compelete opposite
[14:47] <SpamapS> smoser: getopts claims to be more advanced than getopt ;)
[14:48] <SpamapS>             The getopts command deprecates the older getopt(1) utility due to its
[14:48] <SpamapS>             handling of arguments containing whitespace.
[14:48] <Chipzz> smoser: getopt might be buggy wrt spaces in arguments, so you shouldn't use it
[14:48] <smoser> bah.
[14:48] <smoser> might be.
[14:48] <smoser> but is not
[14:48] <Chipzz> is on some OS'es
[14:48] <smoser> and its not like 'sh' is changing its parsing all that often.
[14:48] <Chipzz> so don't use it if you want your script to be portable
[14:49] <SpamapS> smoser: come on you can't make it work with a builtin? ;)
[14:49] <smoser> SpamapS, they're completely different beasts.
[14:49] <smoser> the reason that the builtin can do what it does is because it doesn't attempt to understand shell quoting.
[14:49] <smoser> it uses a global basically.
[14:55] <DoctorPepper> agateau:  are you here ?
[16:08] <mdeslaur> @pilot out
[16:22] <DBO> slangasek, can you help me with my flashplayer? it doesn't seem to work with pulse
[16:22] <slangasek> DBO: apt-get install libasound2-plugins:i386?
[16:22] <DBO> already done
[16:23] <DBO> still doesn't work
[16:23] <DBO> tried installed adobe-flashplugin instead of flashplugin-installer also
[16:23] <DBO> that just made it not work all together
[16:24] <slangasek> DBO: this is amd64?
[16:24] <DBO> slangasek, yep
[16:25] <slangasek> restarted nspluginwrapper / the browser after installing libasound2-plugins:i386?
[16:25] <DBO> slangasek, restarted the entire machine
[16:25] <DBO> slangasek, its a fresh installed too
[16:25] <DBO> I remember it working once, but after installing my development environment
[16:25] <DBO> it stopped working
[16:26] <slangasek> sorry, what do you mean by "development environment"?
[16:27]  * ogra_ glares at the title of bug 879448
[16:28] <ogra_> i hope that doesnt mean a typoed upgrade from warty to whtever 10.11 might be :)
[16:28] <Amaranth> *boggle*
[16:28] <Amaranth> DBO: Wait, you're using a flash that requires nspluginwrapper still?
[16:29] <Amaranth> Doesn't the partner repo contain a native amd64 package?
[16:30] <slangasek> it's not yet integrated into flashplugin-installer
[16:30] <slangasek> DBO: but, if you installed adobe-flashplugin and it still didn't work, I don't know what the problem is
[16:30] <slangasek> DBO: how did you determine it's not talking to pulseaudio?
[16:31] <DBO> adobe-flashplugin simply didn't give me flash
[16:31] <DBO> like chrome didn't think it had flash
[16:31] <slangasek> heh
[16:31] <slangasek> you might need to make sure you uninstall flashplugin-downloader as well?
[16:31] <DBO> okay hold on
[16:31] <DBO> let me try that
[16:32] <DBO> as for not using pulse, lets assume I know what i am talking about :)
[16:32] <DBO> (I do)
[16:32] <Amaranth> slangasek: Right, I know the downloader package still does 32-bit and nspluginwrapper but adobe-flashplugin in partner is the native 64-bit 11.0 release
[16:33] <Amaranth> Oh, and I took too long to type that
[16:33]  * Amaranth goes back to watching paint dry^W^Whis panda board compile
[16:34] <DBO> slangasek, okay that worked
[16:34] <DBO> thanks :)
[16:34] <DBO> you're a champ
[16:34] <slangasek> ok, good :)
[16:34] <slangasek> I still don't know why the 32-bit one isn't working for you
[17:21] <alex-weej> is readahead standard in ubuntu now?
[17:21] <ogra_> ureadahead is
[17:21] <ogra_> since several releases
[17:22] <ogra_> normal readahead was dropped in favor
[17:22] <alex-weej> ogra_: thanks. is there some documentation anywhere for how it works? or is it a 'Use The Source, Luke' thing? :)
[17:23] <ogra_> both i think. there should be a blueprint on launchpad and possibly a spec on the wiki for its implementation
[17:23] <ogra_> beyond that there surely is also source code to inspect :)
[17:24] <broder> http://ubuntuforums.org/showthread.php?t=1434502 is also helpful
[17:24] <alex-weej> ogra_: thank you
[17:24] <alex-weej> broder: also :)
[18:00] <smoser> cjwatson, so where do you use that perl snippet?
[18:01] <smoser> it seems odd to add a perl dependency on a pakage just for that, although its very helpful.
[18:06] <cjwatson> smoser: as I say, in man-db.postinst.  perl-base is Essential: yes so no dependency is required.
[18:08] <cjwatson> smoser: I do think having an option in the daemon to drop privileges itself is a strictly better approach.
[18:08] <smoser> yes.
[19:13] <soakda> i have ubuntu 11.10 and have problem with booting fakeraid (dualboot with windows 7), everything installed like a charm, it even booted after installation to both windows and ubuntu but after updating and rebooting one more time i get kernel panic and message that root= is wrong, didn't get any help on #ubuntu..
[19:23] <Pici> soakda: This is not a support channel. You'll just need to be patient in #ubuntu, or check out our other support resources.
[19:23] <Pici> soakda: htps://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
[19:25] <soakda> Pici: ok, thanks
[19:29] <Daviey> cjwatson: How would you rate the chances of bug 833994 being resolved this cycle?
[19:45] <Daviey> superm1: can python-mysqldb be sync'd from sid? It seems it includes your fixes, dh_python2 and change to quilt.
[20:03] <penguin_03> is it possible to re enable module loading after 'echo "1" > /proc/sys/kernel/modules_disabled' ?
[20:21] <stgraber> penguin_03: no, that's the whole point of this option
[20:22] <penguin_03> stgraber, assuming you have physical access the the machine there *has* to be a way to disable it though
[20:23] <stgraber> penguin_03: rebooting it is the easiest way
[20:23] <penguin_03> thanks
[20:23] <__keybuk> just had one off those annoying upgrade problems where after upgrade mdadm is picking up /dev/sdb rather than /dev/sdb1 :(
[20:25] <slangasek> "one of those"?  I thought those were all in the distant past
[20:53] <__keybuk> slangasek: apparently not
[20:53] <__keybuk> this was on installing natty
[20:53] <__keybuk> so it may be fixed in oneiric?
[20:54] <slangasek> I don't remember any reports of anything like this happening in several years
[20:54] <slangasek> it's not something anyone fixed in oneiric
[20:54] <slangasek> TTBOMK
[20:56] <__keybuk> if you have a partition that fills the entire disk, how does mdadm know to ignore the whole disk?
[21:06] <cjwatson> Daviey: *shrug* I don't care about it, but if you escalate it in the usual way with a justification then I guess I'll have to bloat up the initrd to do it :-P
[21:07] <cjwatson> Daviey: I think I checked and Debian wasn't going to do it
[21:07] <cjwatson> (but that's only a vague memory)
[21:08] <slangasek> __keybuk: I don't know, but I thought it was solved :)
[21:08] <slangasek> so if not, well, doh
[21:08] <cjwatson> __keybuk: I thought that was fixed by using a more modern md format; also the installer deliberately leaves a gap at the end of the disk to avoid ambiguity
[21:09] <__keybuk> cjwatson: the installer didn't make these partitions, I did\
[21:09] <cjwatson> in 1.1/1.2 the md superblock is at/near the start of the device rather than the end
[21:09] <__keybuk> and I didn't leave a gap
[21:09] <cjwatson> well then :)
[21:09] <__keybuk> cjwatson: hmm, the mdadm version is 0.9
[21:09] <cjwatson> yeah, the ambiguity is inherent then unless you leave a gap
[21:09] <barry> any syncpackage (for fakesync) experts around?
[21:10] <cjwatson> I can't remember how to deal with the situation where the partition already exists and can't conveniently be shrunk a bit
[21:12] <__keybuk> I wonder how you update the mdadm version
[21:13] <slangasek> barry: I know things about syncing, if that counts :)
[21:14] <barry> slangasek: that's okay, i think i figured it out.  fwiw, after i uploaded python-support 1.0.14ubuntu1 we discussed just dropping the ubuntu delta.  i'llmanually prepare a 1.0.14ubuntu2 that drops it and make it clear in the changelog that next debian upload can do a sync for real
[21:14] <slangasek> barry: right, that's the thing to do there
[21:14] <barry> slangasek: cool, thx
[21:14] <cjwatson> I don't know of a way to change the metadata version in place
[21:15] <cjwatson> you could probably force the disk to be avoided by tweaking mdadm's udev rule locally
[21:15] <__keybuk> yeah
[21:16] <cjwatson> that's probably the simplest local fix (but not generally suitable since some people deliberately use entire disks as components, of course)
[21:16] <__keybuk> except that gets lost each upgrade
[21:16] <__keybuk> I suspect that's what I did
[21:16] <cjwatson> dpkg-divert?
[21:16] <__keybuk> indeed
[21:16] <__keybuk> I think I actually dropped a replacement in /etc/udev/rules.d
[21:16] <cjwatson> or /etc/udev/rules.d/ I guess, you probably remember the details better than I do :)
[21:16] <__keybuk> but it didn't get copied into the initramfs after upgrade
[21:16] <cjwatson> ah
[21:16] <cjwatson> initramfs-tools ought to have a helper function to DTRT there
[21:16] <cjwatson> (probably doesn't, but)
[21:23] <__keybuk> ok, a little ENV{DEVTYPE}=="partition" seems to have solved my problem
[22:09] <bdrung> barry: yes (i wrote the syncpackage fakesync stuff)
[22:09] <barry> bdrung: thanks, i figured it out though (can't use syncpackage for this particular use case)
[22:12] <bdrung> barry: fakesync building assumes that the content is the same of the mismatching tarballs
[22:24] <barry> bdrung: so, here's a new situation.  i'm trying to sync python-peak.rules.  it's blacklisted, so it suggests --no-lp --force, but --no-lp is "not recommended" (lp sync'ing was rejected).  should i just use --no-lp --force?
[22:25] <bdrung> barry: if blacklisted, use only --force. if this does not help, ask the archive admins to remove this package from the blacklist
[22:26] <barry> bdrung: okay, thanks
[22:27] <bdrung> barry: but --no-lp --force is the right way, if it needs a fakesync
[22:27] <barry> bdrung: nod
[22:27] <bdrung> barry: the comment is clear to me: http://paste.debian.net/138672/
[22:28] <bdrung> barry: and it seems to need a fakesync
[22:29] <barry> bdrung: right, that part makes sense.  it's a little confusing that it's recommending to use --force and --no-lp to override the blacklist, but the manpage warns against --no-lp
[22:29] <barry> or should i say "seems to recommend"
[22:29] <bdrung> barry: --no-lp is the only way for fakesync (patches to make that clear are welcome)
[22:30] <bdrung> barry: --no-lp for fakesync are not discouraged by the admins
[22:32] <barry> WARNING
[22:32] <barry>        The use of syncpackage --no-lp, which generates a changes file  to  be
[22:32] <barry>        directly  uploaded to the Ubuntu primary archive or a PPA, is discour‐
[22:32] <barry>        aged by the Ubuntu Archive Administrators, as it introduces an  unnec‐
[22:32] <barry>        essary window for error.  This only exists for backward compatibility,
[22:32] <barry>        for unusual corner cases, and for uploads to archives other  than  the
[22:32] <barry>        Ubuntu  primary archive.  Omitting this option will cause Launchpad to
[22:32] <barry>        perform the sync request directly, which is the preferred  method  for
[22:32] <barry>        uploads to the Ubuntu primary archive.
[22:32] <barry>  
[22:33] <bdrung> barry: fakesyncs are the "unusual corner cases"
[22:33] <bdrung> barry: patches for better wording are welcome
[22:33] <bdrung> tumbleweed: ^
[22:33] <barry> bdrung: gotcha.  i'll think about and file a bug/patch if i can come up with anything better ;)
[22:37] <infinity> barry: Why not get a new upstream of python-peak.rules into Debian, ask us to remove the blacklist, and be done with the mess? :P
[22:39] <barry> infinity: well, right now i'm slogging through a ton of packages i touched since oneiric, so i'm trying to do a minimal amount of yak shaving.  please do comment on the bug though if you think that's a better way to go and i will address it later
[22:40] <infinity> barry: "The bug" being?
[22:40] <barry> infinity: ah, i thought you were commenting on bug 879708
[22:41] <infinity> Err, we can't remove the blacklist.
[22:41] <infinity> The reason it's there is because of the mismatched orig.
[22:41] <barry> infinity: isn't that what fakesync is for?
[22:42] <infinity> Yes, fakesyncing isn't an LP function.  Or an AA function at all.
[22:42] <infinity> It's something you do locally to work around breakage.
[22:42] <barry> infinity: all these differing recommendations seem quite contradictory
[22:42] <bdrung> infinity: you can remove the blacklist for the fakesynced packgae
[22:42] <infinity> bdrung: No I can't.
[22:43] <infinity> bdrung: Because if a -2 lands in Debian, the next autosync will choke on it.
[22:43] <bdrung> infinity: no, because it has a different ubuntu version
[22:43] <infinity> bdrung: The entire reason the blacklist is in place is the mismatched orig.
[22:43] <bdrung> infinity: you wont autosync a version that has -XfakesyncY in Ubuntu, do you?
[22:44] <infinity> Eww, we actually do that? :P
[22:44] <infinity> That's new (ish).
[22:44] <barry> https://wiki.ubuntu.com/fakesync
[22:45] <infinity> Right, the naming scheme on fakesyncs is new.  I was gone for a year and a half. :P
[22:45] <barry> infinity: :)
[22:45] <infinity> Either way.  It's all less hassle if you just update the Debian package.
[22:46] <infinity> Cause wasn't the Ubuntu one a snapshot that was ahead of the Debian one anyway?
[22:46] <infinity> Oh, maybe not.
[22:46] <tumbleweed> IIRC they were uploaded at almost exactly the same time (I rushed the rview so we wouldn't have to leap ahead in Ubuntu, but barry hadn't noticed that)
[22:46] <infinity> I'm confusing the two -r1234 strings.
[22:47] <barry> tumbleweed: right, we were like ships passing in the night
[22:47] <barry> and my apologies for screwing everything up :)
[22:47] <tumbleweed> it's just a mismatch :)
[22:47] <infinity> Yeah, it's not the end of the world.
[22:48] <infinity> barry: Fakesync away.
[22:48] <infinity> barry: When it's accepted, I'll drop the blacklist, if this shiny new autosync behaviour is indeed the way and the light. :P
[22:48] <barry> infinity: i'm actually uncertain how to do that now :(
[22:48] <bdrung> infinity: the naming schema for fakesync is over a year old :)
[22:49] <infinity> bdrung: Yes, that was in the point when I was not around. ;)
[22:49] <tumbleweed> bdrung: --no-lp --force
[22:50] <barry> $ syncpackage --force --no-lp --simulate -d wheezy -r precise python-peak.rules (without the --simulate)... ?
[22:50] <tumbleweed> err barry
[22:50] <bdrung> infinity: i is easier to see the fakesync and to avoid problems with the autosync (no blacklist required for fakesync)
[22:50] <infinity> barry: That should do it.
[22:50] <bdrung> barry: yes
[22:50] <barry> tumbleweed, infinity, bdrung thanks, executing now
[22:50] <infinity> barry: That won't actually sync anything.  Should just generate a nice source package and a .changes for you.
[22:51] <barry> infinity: fair enough.  i upload that and then it needs to be accepted?
[22:51] <infinity> barry: It'll accept like any other upload, the archive isn't frozen.
[22:51] <barry> gotcha, thanks
[22:51] <infinity> barry: The blacklist doesn't apply to uploads, just actual syncing mechanisms.
[22:51] <barry> infinity: ah, okay!
[22:51] <cjwatson> bdrung: 'fakesync' in the version doesn't inhibit autosync - only 'ubuntu' does
[22:52] <infinity> (If it applied to uploads, maintaining, say, udev, would be awful)
[22:52] <barry> right, so i dput the -1fakesync1 package
[22:52] <tumbleweed> barry: yes
[22:52] <bdrung> barry: please send patches for things in the docu that confuses you
[22:52] <infinity> cjwatson: See, that's what I thought, but hadn't gone digging.  So, this "fakesync and then remove the blacklist" business is... Crazy talk? :P
[22:52] <cjwatson> infinity: correct
[22:52] <cjwatson> fakesyncs still need to be blacklisted, until we can move to something copyPackage-based for autosyncing at which point it will be easier to apply more Ubuntu policy
[22:52] <infinity> bdrung: ^
[22:53] <cjwatson> right now, if you remove the blacklist, I'll probably just have to swear and put it back at some later point
[22:53] <tumbleweed> bdrung, barry: We could add a --fakesync option that does all of the above. Then only --no-lp needs to print scary warnings
[22:53] <infinity> Yeah.
[22:53] <bdrung> cjwatson: can the autosync learn to not sync package with fakesync in the version string?
[22:53] <barry> awesome, thanks guys.  uploaded.  bdrung i will (though not right now ;)
[22:53] <bdrung> tumbleweed: good idea
[22:53] <cjwatson> bdrung: I don't want to modify the old-style autosync process any more
[22:54] <tumbleweed> bdrung: it needs to not autosync, before the first fakesync version exists in Ubuntu
[22:54] <cjwatson> bdrung: when we switch to new-style copyPackage autosyncing, I'd be happy to make it smarter
[22:54] <cjwatson> (in that case, there'd be no need to look at the version, it could just compare orig checksums)
[22:54] <infinity> barry: So, I'm still going to fall back on my initial statement.  Getting a new upstream into Debian and syncing it would be less hassle. :P
[22:55] <barry> tumbleweed, bdrung agreed, great idea
[22:55] <barry> infinity: apparently so :)
[22:55] <cjwatson> new-style autosyncing is presently blocked on LP fixing the inability to credit a copyPackage action to somebody else
[22:55] <barry> of course, it's all my fault originally for leapfrogging tumbleweed
[22:55] <cjwatson> (no way do I want all autosyncs listed under my name)
[22:56] <barry> cjwatson: oh c'mon :)
[22:56] <tumbleweed> even better, according to discussion a few days ago, Apparently there's a known way to write repacking scripts, that'll produce deterministic output.
[22:56] <infinity> cjwatson: Think of the karma.
[22:56] <cjwatson> I was thinking of the mail.
[22:56] <infinity> ;)
[22:56] <infinity> You read mail from LP?
[22:57] <cjwatson> some of it ...
[22:57] <cjwatson> (actually, perhaps more of the people who might think I in some way cared about those packages)
[23:49] <mika> hi, we're at the FAI developer sprint and working on Ubuntu LTS support within FAI. Is there an option to get FAI into universe of lucid (it's present in maverick, natty, oneiric and precise but just missing in lucid)?