[00:00] <smoser> i'll try again, but i swear before i added '--debug' and it just didn't do anything.
[00:01] <smoser> hm.. for the record, i added '--verbose', not '--debug' . '--help' output mentions --verbose, not --debug.
[00:03] <wolter> slangasek, yes
[00:03] <slangasek> smoser: I honestly don't remember; I've always captured to a logfile in /dev for easier post-boot analysis, but that doesn't work here if you can't get to a shell :)
[00:03] <smoser> --debug has no effect to the console.
[00:04] <slangasek> smoser: bah.  Maybe try > /dev/console 2>&1 ?
[00:04] <smoser> at least "grep -v 'init:'" rips out just about everything. nothing really looks like mountall output
[00:04] <smoser> well, it *should* get to the console.  other tasks do, i know that. but i guess other tasks don't run so early.
[00:05] <slangasek> wolter: well, AFAIK that should entirely be handled by gnome-settings-daemon, with no pulseaudio involvement
[00:05] <slangasek> wolter: what's the hardware?  It's not a thinkpad, is it?
[00:05] <wolter> no
[00:05] <wolter> its a dell xps m1530 with sigmatel sound card
[00:05] <slangasek> wolter: ok, no idea then, sorry
[00:05] <wolter> but it used to work, so that should not matter
[00:05] <wolter> ok, attempt appreciated anyway, thanks
[00:06] <slangasek> wolter: it matters because on the thinkpad, it "worked" wrong in earlier versions
[00:06] <smoser> scratch that. retrying. hodl on
[00:06] <slangasek> but that definitely doesn't apply to Dells
[00:06] <wolter> ok
[00:09] <smoser> slangasek, http://paste.ubuntu.com/359307/
[00:10] <smoser> that is '--debug' output to mountall, and it does get to the console. user error previously.
[00:10] <smoser> it seems to think it can't mount /
[00:13] <smoser> ok. so i found the issue. or at least a fix/workaround.
[00:13] <slangasek> oh?
[00:13] <smoser> slangasek, /etc/fstab has '/dev/sda1' as root, but /dev/sda is actually root.
[00:13] <smoser> kernel cmdline has the correct value, and / does obviously get mounted
[00:14] <smoser> but mountall sits around waiting for a / that is never going to be
[00:14] <slangasek> ah
[00:14] <smoser> i think it doesn't make sense to wait for the device of /
[00:14] <slangasek> IIRC it waits for it in order to fsck it?
[00:14] <smoser> although that doesn't explain why it works with the initramdisk
[00:14] <slangasek> yeah, I don't know
[00:15] <smoser> that does make sense, to fsck, but better to listen to what is already mounted than to /etc/fstab, which can only ever be wrong.
[00:16] <smoser> at least if, between fstab and the kernel, if one is wrong, its not fstab
[00:17] <slangasek> smoser: right, well, please post this analysis to the bug and we'll consult Keybnz when he's available :)
[00:18] <smoser> k
[00:54] <smoser> slangasek, you agree that this is probably 'mountall' and not 'upstart' ?
[00:54] <cjwatson> didrocks,superm1: please use lp:~ubuntu-core-dev/user-setup/ubuntu rather than lp:ubuntu/user-setup
[00:54] <slangasek> smoser: yes, it's clearly a mountall issue
[00:55] <cjwatson> didrocks,superm1: those may become identical in future, but for now lp:~ubuntu-core-dev/user-setup/ubuntu is the correct branch
[00:55] <cjwatson> didrocks: sorry, you can ignore the above - it's just superm1 getting it wrong :)
[01:00] <smoser> slangasek, thanks for your help.  what do you want me to do for your smb bug?
[01:02] <slangasek> smoser: set log level = 3, reproduce it, and send me /var/log/samba/log.nmbd :)
[01:12] <cjwatson> superm1: I've fixed up the history, though I'd rather not have to do so again as the process is a bit tedious and manual
[01:15] <slangasek> smoser: oh, bear in mind that you need samba 2:3.4.3-2ubuntu1 or earlier to reproduce this; 2:3.4.3-2ubuntu2 includes the /etc/network/if-up.d script that will mask the problem
[01:16] <smoser> well i saw i with alpha2. i'll just use that unless it is otherwise not acceptable.
[01:16] <slangasek> yah, that's good
[01:16] <smoser> is that ok?
[01:16] <smoser> k
[01:28] <micahg> Riddell: thanks for pushing that zf backport, but I wonder if we should push 1.9.7 instead
[01:30] <Riddell> micahg: that's a question for the backports team, I only do what they approve
[01:30] <micahg> heh, ok, ScottK ^^^
[01:31] <Riddell> speaking of which, ScottK, jdong: how come nobody has complained about these not being processed for up to 6 months?
[01:41] <ScottK> Riddell: I've been busy ...
[01:52] <superm1> cjwatson, i'm sorry.  i'm so confused with different projects using lp:ubuntu/blah and others lp:~ubuntu-core-dev/blah/blah+
[01:53] <StevenK> superm1: Some of them should be equal
[01:53] <superm1> StevenK, see that's just the problem : *some of them*
[01:54] <superm1> and i'm not sure which ones those are
[01:54] <StevenK> superm1: It's a transistional period, what can you do?
[01:54] <superm1> complain :)
[01:55] <StevenK> superm1: I'd suggest asking james_w about the above
[01:58] <StevenK> superm1: Can I upload mythtv? :-)
[01:59] <superm1> StevenK, our branches are just as much a mess :)
[01:59] <StevenK> superm1: No-change rebuild for jack ...
[01:59] <superm1> StevenK, actually we've got changes queued up, i'll upload them tonight
[02:00] <StevenK> superm1: Right, well, I've just kicked libjack0.100.0-0 out of the archive, so I may have broken myth, but NBS wasn't picking it up and complaining
[02:01] <superm1> StevenK, okay.  i'll see what happens.  if it fails to build i'll just disable jack for now.  i dont know a single user that uses jack tbh.
[02:02] <StevenK> superm1: I removed the shared library, the -dev package was removed days ago, and your Build-Depends are already fine
[02:02] <slangasek> ArneGoetje: can you roll some new langpack -base packages for hardy (8.04.4)?  i386 alternate has grown, and I think re-compacting language-pack-es-base should be enough to fix this
[02:02] <slangasek> ArneGoetje: (though just in case it isn't, I would certainly suggest doing all the ones that are on the CD...)
[02:04] <cjwatson> superm1: honouring the Vcs-Bzr field in debian/control when it's set to something useful and Ubuntuish will get you out of trouble most of the time.
[02:05] <cjwatson> superm1: (BTW I've already asked james_w to move the lp:ubuntu/... links over for this case, a while back)
[02:06] <ArneGoetje> slangasek: yes, I'm working on it.
[02:06] <slangasek> ArneGoetje: ok, thanks :)
[02:06] <slangasek> ArneGoetje: when do you think that will be done?  (so I can schedule CD testing accordingly)
[02:10] <ArneGoetje> slangasek: I will start a build now and see if it runs through. Since the langpack-o-matic code has moved to another server, there are still some dependency problems when generating the mozilla translations of the langpacks, So, need to test if it's fixed now. But I hope to have at least the packages, which go on the CD ready within 10 hours
[02:11] <slangasek> ok
[02:12] <Keybnz> cjwatson: hey, dunno if you know, but the 19 install failed
[02:12] <cjwatson> Keybnz: nope, any clues as to what went wrong?
[02:12] <Keybnz> http://zelda.netsplit.com/~daily/daily-installer/20100119-max/debug
[02:13] <Keybnz> (the rookery rsync apparently doesn't work anymore)
[02:13] <slangasek> Keybnz: hi, quick question while you're about - the plymouth in initramfs is a temporary workaround until the gdm/plymouth starting race can be fixed, right?
[02:13] <Keybnz> slangasek: got it in one
[02:13] <slangasek> ok
[02:13] <slangasek> do you have an idea yet of how to fix that race? would you like me to work on it?
[02:13] <Keybnz> gdm starts before plymouth ends the world ;)
[02:14] <slangasek> yep
[02:14] <Keybnz> start plymouthd very early, separate job to show splash
[02:14] <Keybnz> so if X is up, it's a no-op
[02:14] <Keybnz> might need some work to make sure you don't get console messages, etc.
[02:14] <slangasek> ok
[02:14] <Keybnz> (since gdm deactivates plymouth when it starts and re-shows it later)
[02:15] <slangasek> I'm keen to see it resolved because I'd like to avoid having to put pango in everyone's initramfs in the interim ;)
[02:15] <Keybnz> yeah it's top of my things to do at the sprint
[02:15] <slangasek> alrighty
[02:19] <Keybnz> slangasek: feel free to give it a shot
[02:21] <slangasek> Keybnz: ok, cheers
[02:29] <cjwatson> Keybnz: rookery> people.canonical.com changed host, it's now "lillypilly" (silly name ...)
[02:29] <cjwatson> Keybnz: could you make the syslog there world-readable?  I get 403 Forbidden
[02:30] <cjwatson> Keybnz: it might be what superm1 just fixed though
[02:30] <cjwatson>   * Fix automatic login on situations where custom.conf didn't exist
[02:30] <cjwatson>     already on the target.
[02:31] <cjwatson> yeah, looks about right
[02:31] <cjwatson> I'll make sure we do a ubiquity upload tomorrow
[02:41] <StevenK> cjwatson: d-i and the surrounds are free of the -9 kernel, so I can kick it out of the archive?
[02:41] <StevenK> I've checked, just want to make sure.
[02:44] <cjwatson> StevenK: yes
[02:45] <ScottK> StevenK: Even on powerpc?
[02:46] <ScottK> Last I looked, d-i wasn't building there.
[02:47] <smoser> slangasek, log files for recreate attached. if you want anything else let me know. i'll keep the vm around for a bit.
[02:48] <cjwatson> ScottK: if memory serves, it didn't build with -9 either
[02:49] <ScottK> Ah, may be.
[02:49] <StevenK> It's because the kernel is too big
[02:49] <StevenK> I think
[02:49] <cjwatson> I've not been bored enough to investigate
[02:50] <ScottK> StevenK: I think that's right.  I looked at it enough to conclude I'm really confused by d-i and will leave it alone.
[02:52] <Keybnz> cjwatson: yeah the problem is that IS haven't copied over the special permission for the rsync
[02:52] <Keybnz> will fix the perms
[02:52] <Keybnz> unfortunately daily installs/bootcharts are down until someone manually reboots the boxes :(
[02:56] <Keybnz> ok, I want bzr reflog now
[05:05] <slangasek> smoser: thanks - that's with a stock smb.conf?
[07:18] <dholbach> good morning
[07:18] <ajmitch> morning dholbach
[07:18] <dholbach> hey ajmitch
[08:14] <doko_> ccheney: yes, please still use -O2 for the arm build
[08:24] <pitti> Good morning
[08:25] <slangasek> morning
[08:46] <abogani> Hi All, I found on our wiki instructions for add new package into Ubuntu. Where can I find instructions for request to removing package from Ubuntu? In my case the simualvr package is buggy, never used and no more developed simulator for AVR. It presence in our archive can let our users think that is a good software and let they disappointed when discover that it is a very bad software. What is the right thing to do?
[08:48] <pitti> ttx: FYI, the missing trend line start update was a problem in my cronjob; fixed last night, so they should be good now
[08:49] <jussi01> abogani: you need to file a bug - instructions are on this page: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
[08:51] <abogani> jussi01: Yeah the missing URL! Thanks Jussy!
[08:52]  * jussi01 hugs abogani and reminds him that his name is spelt Jussi :D
[08:52] <ttx> pitti: yes, it's perfect now, thanks
[08:52] <doko_> pitti: when should we start planning which library versions to demote for lucid (boost, db4.x, readline5, ..., ???)
[08:53] <abogani> jussi01: It isn't the first time, also... Apologize for this I'll try to write your name well. :-(
[08:54] <pitti> doko_: hm, to me it seems this is the kind of work for between beta-1 and beta-2; WDYT?
[08:56] <doko_> pitti: hmm, maybe a bit late? should we try to propose versions which we do want to keep/target for lucid now/next week?
[08:56] <pitti> we can make a list of duplicates, sure
[08:57] <pitti> it just seems less intrusive than the typical alpha-2/3 targets, and we're still syncing from debian right now
[08:58] <smb> Anybody with a spare current Lucid machine, who could help me to verify something?
[08:58] <doko_> ok, I'll start a wiki page later this week
[08:58] <seb128> smb, spare like ready to break?
[08:59] <smb> seb128, Sort of yes, but recoverably (thought maybe in a scary way)
[08:59] <seb128> ok, I will pass on this one, sorry but I've a busy schedule for today
[08:59] <seb128> I can do quick testing but I need my box ;-)
[09:02] <smb> In general, after adding the following to /etc/fstab: "LABEL=NotHere /mnt ext3 defaults,user,relatime 0 0", then on reboot my installation hung. But with sysrq-i (kill all tasks) I get dropped down to a maintenance shell where I can remove the bad entry from the fstab and the system boots again.
[09:02] <smb> This entry did not cause problems until some recent update. It seems mountall gets into trouble now.
[09:04] <slangasek> smb: by design
[09:05] <slangasek> smb: based on negative feedback in karmic, Keybnz has made mountall block waiting for all local filesystems listed in /etc/fstab before declaring the filesystem "mounted"
[09:06] <smb> Though this is a drastic change in behavior.
[09:07] <smb> Those entries were in my case related to USB sticks which I wanted to get mounted with different options, when I plug them in.
[09:07] <slangasek> then you should probably have them marked 'noauto' in /etc/fstab, I think
[09:07] <slangasek> or perhaps 'nobootwait'
[09:08] <slangasek> asynchronous booting is a drastic change in behavior /in general/; we have to pick /some/ policy for handling cases like this, and there's no policy that will make everyone happy
[09:08] <smb> slangasek, Likely and maybe we should add a note to the release notes (if not already there). As updates can suffer from that surprise
[09:08] <slangasek> (I thought the policy in karmic was reasonable, but apparently plenty of users did not, and were vocal about it)
[09:08] <slangasek> smb: certainly - could you file a bug on the ubuntu-release-notes project about this?
[09:08] <smb> slangasek, Yes, will do
[09:10] <pitti> smb, apw: FYI, I just binary-NEWed the lucid kernel
[09:10] <smb> pitti, Thanks, I'll relay to apw when he gets in
[09:17] <apw> pitti, thanks
[09:30] <dholbach> pitti: heya.... czajkowski said there were a bunch of action items missing on the burndown charts... do you know what happened?
[09:31] <dholbach> czajkowski: which spec was it?
[09:31] <pitti> dholbach: I need more details, I'm afraid; what's missing?
[09:31] <czajkowski> It's not the specs so much it's the work items missing from assigness and also the -women blueprint I think is missing
[09:32] <czajkowski> http://macaroni.ubuntu.com/~pitti/workitems/canonical-community.html
[09:32] <czajkowski> going by this page
[09:32] <czajkowski> and I know there is a blueprint on -women
[09:32] <dholbach> czajkowski: do you have an example of a spec that generally shows up but your work items are missing?
[09:33] <czajkowski> dholbach: Loco council is one example then
[09:33] <dholbach> czajkowski: do you have the link to the spec?
[09:33] <pitti> czajkowski: is the missing blueprint assigned to someone not in ~canonical-community?
[09:33] <czajkowski> blueprint is up but I'm not down under asignees neither is pope
[09:33] <dholbach> pitti: ah, it doesn't show community members?
[09:33] <czajkowski> dholbach: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-loco-council-plans
[09:37] <dholbach> czajkowski: on that spec there's just one action item for you and that turns up at least on all-ubuntu-10.04.html
[09:37] <czajkowski> dholbach: :(
[09:37] <czajkowski> wait that's right
[09:38] <pitti> dholbach: it shows community WI assignees, but not specs which aren't assigned to a member of the reports' team
[09:48] <apw> TheMuso, hey ... abuot?
[09:57] <geser> could an archive admin try syncing "libxcb" again? I need a fresh OOPS for bigjools to look why it fails
[10:00] <pitti> can do
[10:01] <pitti> geser: sync-source worked; I'll try to flush it
[10:01] <seb128> geser, sorry I meant to do that yesterday but somebody started on syncs and didn't flush the queue and I didn't want to mess with things before that was sorted
[10:02] <seb128> pitti, it's flush which oops
[10:02] <pitti> 2010-01-20 10:02:05 ERROR   Exception while processing upload /home/lp_queue/sync-queue/incoming/pitti-20100120-100158 (OOPS-1481FTPMASTER1)
[10:02] <geser> pitti: thanks
[10:31] <smb> slangasek, I really would love to file a bug, but launchpad is not in the right mood for that
[11:03] <ArneGoetje> slangasek: upload the hardy langpacks directly to the archive, or go via PPA and -proposed?
[11:04] <ArneGoetje> slangasek: or split the upload? langpacks on the cd to archive, the rest via PPA and -proposed?
[11:06] <slangasek> ArneGoetje: I don't see any reason not to go directly to the archive?
[11:10] <seb128> geser, I've synced libxcb, the issue is due to the new line in the binary list in the .changes
[11:10] <seb128> I workarounded the .changes for the sync
[11:10] <seb128> pitti, ^
[11:10] <pitti> ah, good
[11:11] <geser> seb128: that explains why e.g. mono didn't autosync too, it has also a newline in the Binary: field
[11:13] <geser> directhex, Laney : ^^ that's the reason why mono doesn't autosync
[11:13] <seb128> geser, right, I already workaround mono in the past due to such issue
[11:14] <smoser> slangasek, stock smb.conf (other than adding 'log level = 3' to global section.
[11:14] <seb128> geser, https://bugs.launchpad.net/soyuz/+bug/435316
[11:14] <Laney> is there a soyuz bug for this?
[11:14] <Laney> well anticipated
[11:14] <Laney> :)
[11:14] <seb128> ;-)
[11:14] <seb128> do you need mono to be synced?
[11:15] <seb128> I can do that now...
[11:15] <Laney> I think that requires more discussion
[11:15] <Laney> do you need any help with your ftbfs?
[11:15] <Laney> I feel bad that we didn't consider ubuntu-local packages
[11:19] <seb128> Laney, no that's ok, the build-depends list has 28 items I guess those will be fixed over time
[11:20] <seb128> I will do a check around beta time to make sure we transitionned those
[11:20] <seb128> not a priority for now
[11:21] <Laney> the ones in Debian we will take care of, but ones that aren't might not get picked up by us
[11:21] <seb128> ok, no worry
[11:21] <seb128> let's wait for you to deal with the debian one
[11:22] <tseliot> slangasek: do you think I should do an "LDCONFIG_NOTRIGGER=y ldconfig" (in a postinst script) or export and unset that variable? I'm having problems with buildds.
[11:22] <seb128> then I will run another query to check what is remaining
[11:22] <cjwatson> james_w: could you please have a look at the dpkg failure?  I'm pretty certain that the problem is that get_native_part is failing to handle the case of a .tar.bz2 native package
[11:23] <tseliot> or cjwatson ^^
[11:26] <cjwatson> tseliot: err.  surely we should fix ldconfig if it's breaking?
[11:26] <cjwatson> tseliot: or are you saying you've found a case where calling ldconfig earlier matters?
[11:26] <tseliot> cjwatson: yes, exactly: http://launchpadlibrarian.net/38095009/buildlog_ubuntu-lucid-i386.octave-ad_1.0.6-3_FAILEDTOBUILD.txt.gz
[11:27] <cjwatson> tseliot: can you explain why it matters in this case but not others?
[11:27] <tseliot> otherwise octave won't find libGL.so.1 from mesa
[11:28] <cjwatson> is it because you're changing /etc/ld.so.conf.d/ and need to update ld.so.cache?
[11:28] <tseliot> cjwatson: I guess octave doesn't use libGL.so in /usr/lib/ but relies on ldconfig at build time
[11:28] <cjwatson> that explanation doesn't convince me at all, but the one I just suggested might ;-)
[11:28] <tseliot> cjwatson: yes, that too, of course
[11:29] <cjwatson> tseliot: I think LDCONFIG_NOTRIGGER=y is OK, then, but please leave a comment that it's due to the /etc/ld.so.conf.d/ change
[11:30] <cjwatson> I see there's a comment "explicit ldconfig due to alternatives" there already, so just make that clearer
[11:30] <tseliot> cjwatson: do you mean "LDCONFIG_NOTRIGGER=y ldconfig" ?
[11:30] <cjwatson> yes
[11:30] <tseliot> ok
[11:31] <tseliot> and yes of course I'll add a comment so that my change makes sense to others
[11:33] <geser> cjwatson: the problem on the buildds is that e.g. the postinst of octave3.2 runs one of its binaries (which is linked against libGL.so.1) but as the ldconfig got delayed ld doesn't find the library yet
[11:40] <issimedia> Hi guys! :) Anyone here has experience with unixODBC development? These guys don't have a channel...
[11:41] <dpm> mdeslaur, we've noticed that there is a translation template for hamster-applet on the Karmic translations import queue on LP -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/hamster-applet/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot . Normally only translations for packages in main end up in the queue, but hamster-applet is in universe. Any idea how that could have happened?
[11:41] <dpm> (note that this is not a problem for the translations team, we'll just block the template, I'm just curious to how this could happen)
[11:42] <issimedia> I have a really strange problem with different behaviours between v2 and v3 instruction sets
[11:43] <cjwatson> geser: right, the question I wanted to get resolved is that normally ldconfig is just building a cache and it doesn't matter whether it's run early or not.  I've already worked out with tseliot why it matters here.
[11:43]  * tseliot nods
[11:52] <tseliot> cjwatson: hopefully this explanation will be enough: http://pastebin.ubuntu.com/359506/
[11:54] <cjwatson> tseliot: probably overkill :), but yes
[11:55] <tseliot> heh
[11:55] <cjwatson> I'd just have said that ldconfig needs to be run immediately when changing ld.so.conf.d
[11:55] <tseliot> cjwatson: ok, I'll be less verbose then
[12:00] <tseliot> +  # ldconfig needs to be run immediately as we're changing /etc/ld.so.conf.d/ with
[12:00] <tseliot> +  # alternatives.
[12:00] <tseliot> this should better
[12:01] <cjwatson> yeah
[12:01] <cjwatson> thanks
[12:02] <tseliot> thanks for your help
[12:12] <ArneGoetje> slangasek: ok, uploading...
[12:46] <ockham> hi, can someone help me with this error http://pastebin.com/d275a5d95
[12:46] <ockham> i'm experiencing when trying to build iulib-0.4 using pbuilder?
[12:52] <mdeslaur> dpm: no, I have no idea how that happened. That's odd.
[12:53] <dpm> mdeslaur, thanks for coming back to me. No worries, I'll ask at #launchpad
[12:57] <ockham> sry for nagging, but as i can't see any communication going on here (only logon/offs): is there anybody at all?
[13:00] <cjwatson> ockham: the huge pile of joins and quits was due to problems between some of the IRC servers on the network.
[13:02] <ockham> okay, glad there's someone. soo... can anyone help me out with this:http://pastebin.com/d275a5d95
[14:06] <mathiaz> mvo: squid-deb-proxy package: nice!
[14:10] <mvo> mathiaz: yeah :) if your squid kung fu is good, double check the config
[14:11] <ogra> is that a replacement for approx7apt-proxy and the like ?
[14:11] <ogra> *approx/apt-proxy
[14:11] <mvo> not really a replacement, more a alternative implementation based on squid
[14:12] <mathiaz> mvo: would it make sense to provide a squid-core package - so that you don't pull in a complete squid configuration?
[14:12] <mvo> but yeah, that is the goal
[14:12] <mvo> mathiaz: yes
[14:12] <ScottK> doko_: re your earlier comment about library demotions: For boost, we should be ready to have 1.38 out of the archive shortly and 1.39 is already gone.  There should be nothing to decide about demotions for boost.
[14:13] <doko_> ScottK: the question would be 1.40 or 1.41
[14:13] <ScottK> doko_: Certainly.  I think we should align to whatever Debian is using for default in Squeeze.  I wrote the boost maintainers and asked their plans, but did not hear back.
[14:14]  * ScottK is hoping they don't plan another transition
[14:25] <qense> james_w: I lost track of what bug 422536 should be. There are loads and loads of people randomly changing the status and assignee. You assigned yourself to the bug report, do you know what to it should be?
[14:26] <qense> I think there were almost ten different people with 0 or 5 karma that messed with the report
[15:19] <lamont> powerpc buildds going offline for a while
[16:05] <jjardon> Hello, anjuta can't be installed in lucid due a package conflict with devhelp, should I fille a bug about this?
[16:06] <fagan> jjardon: has it been wrong for a while?
[16:06] <fagan> Or was it an update?
[16:07] <fagan> you may have installed it before the dependencies were updated
[16:08] <jjardon> fagan, the problem is that anjuta 2.28 depends on devhelp 0.23, but devhelp 2.28 is the version available in lucid. The proper solution would be update the anjuta packages
[16:08] <jjardon> or change the actual anjuta 2.28 packages to depend on devhelp 2.28
[16:09] <fagan> jjardon: looking at lucid changes anjuta hasnt been upgraded this month so id file a bug
[16:09] <cjwatson> probably just needs a simple rebuild.
[16:09] <cjwatson> libdevhelp changed its abi
[16:09] <fagan> ah
[16:13] <jjardon> indeed, devhelp 2.28 should be packaged for karmic, as It's an official GNOME 2.28 application; don't know if this is possible now
[16:20] <barry> ScottK: just a quick ping that i pushed a new rev to the distribute merge proposal.  no rush of course
[16:20] <ScottK> barry: I haven't had any time to look at it.
[16:20] <ScottK> It's on my list though ....
[16:20] <barry> ScottK: no worries.  i just wanted to make sure you weren't waiting for more information from me.  thanks!
[16:20] <ScottK> Nope.
[16:20] <barry> cool
[16:30] <jjardon> cjwatson, should I file a bug about this?
[16:41] <slangasek> ogasawara: when you have a chance, could you point the weather report at hardy for 8.04.4?
[16:41] <ogasawara> slangasek: sure
[16:52] <milanbv> slangasek: ping
[16:52] <smoser> slangasek, would you consider upstart or mountall dependency on CONFIG_DEVTMPFS a bug (bug 510130) ? or is that simply a requirement for lucid kernels.
[17:02] <cjwatson> jjardon: it's not my field, but filing a bug for an uninstallable package is certainly reasonable, if there isn't already one filed.
[17:09] <jjardon> cjwatson, ok, done: https://bugs.launchpad.net/ubuntu/+source/anjuta/+bug/508444
[17:32] <cjwatson> jdstrand: is it a good idea to attempt to backport changes for bug 379329 to Karmic?  We elected not to do so in Debian, and the version in Karmic already has the bits that I considered safe to backport (see the changelog for 1:5.1p1-5)
[17:32] <cjwatson> jdstrand: intrepid could probably do with an update for that backport
[17:33] <jdstrand> cjwatson: well, the deal with that is that it has a CVE assigned to it, but it kept showing up on the server teams lists and they would talk about it each week, so I had to do something witht he bug to get it off their list
[17:33] <jdstrand> cjwatson: what I told them is that it is on our list, but we don't have plans to update it any time soon
[17:34] <jdstrand> cjwatson: my feeling is to not update it, but I haven't looked at it closely enough (and neither has anyone from the security team) to say for sure "yes" or "no" on whether to backport it or not
[17:35] <cjwatson> jdstrand: fair enough.  well, you have my take on it now ...
[17:35] <jdstrand> cjwatson: so, is karmic not affected any more?
[17:36] <jdstrand> cjwatson: I realize exploiting this is very difficult to exploit (which is why we haven't been jumping all over it)
[17:36] <jdstrand> that was not the best sentence...
[17:37] <cjwatson> jdstrand: it's mitigated
[17:37] <jdstrand> cjwatson: via the Ciphers?
[17:37] <milanbv> kirkland: around?
[17:38]  * jdstrand is reading the changelog now
[17:39] <cjwatson> jdstrand: no, I wasn't convinced about changing that in 5.1 (I forget exactly why)
[17:39] <jdstrand> cjwatson: if you say it is mitigated in karmic, I'll make a note in our CVE database and in the bug
[17:40] <jdstrand> cjwatson: I was unaware of the mitigation
[17:40] <cjwatson> jdstrand: the packet_disconnect on padding error change reduces the probability of attack to 2^-18, and note that this attack is destructive - if you try it on somebody and it fails, it breaks the connection anyway
[17:40]  * jdstrand nods
[17:40] <jdstrand> cool, thanks
[17:40] <cjwatson> jdstrand: so you'd have to have somebody have their ssh connection broken O(2^18) times and not complain much about it
[17:40] <jdstrand> heh
[17:41] <cjwatson> at least, such is my understanding
[17:42] <jdstrand> ah, so jaunty also has the mitigation, good
[17:42] <jdstrand> 1:5.1p1-5 has packet_disconnect(), and jaunty has 1:5.1p1-5ubuntu1
[17:43] <jdstrand> cjwatson: I'm not superkeen on updating intrepid-- it was quite hard to exploit to begin with, aiui
[17:44] <cjwatson> I don't recall what the original probability was
[17:44] <jdstrand> cjwatson: though I'm noting it in the CVE/bug
[17:44] <jdstrand> cjwatson: http://www.openssh.com/txt/cbc.adv says 2^-14
[17:44] <jdstrand> but "though we suspect this
[17:44] <jdstrand> underestimates the work required by a practical attack."
[17:45] <didrocks> jjardon: I've update anjuta to last release. Just wait for the buildd to build it. It launches correctly now locally.
[17:46] <jjardon> didrocks, great! thank you very much
[17:46] <didrocks> jjardon: y/w ;)
[17:47] <jdstrand> cjwatson: I say for now we plan on fixing it in Intrepid with the next security update
[17:48] <jdstrand> cjwatson: well, by 'fixing' I mean backporting that patch
[17:48] <jdstrand> (of course)
[17:48] <jdstrand> cjwatson: does that seem reasonable to you?
[17:50] <jdstrand> well, the 2^-14 was for the 14 bits of plaintext
[17:53] <cjwatson> jdstrand: sounds reasonable, yes
[18:00] <zul> piti: ping is there a way to ask a question in apport hook if the gtk/kde interface is not installed
[18:04] <jjardon> didrocks, I'm seeing https://launchpad.net/ubuntu/lucid/+source/anjuta and current anjuta doesnt depend on libgnome, libgnomeui, libgnomecanvas, libglade, libgnomeprint or libgnomevfs
[18:06] <didrocks> jjardon: I've just adjusted deps from diff in configure.in between previous version we got and that one. Can you opened a bug and assign it to me so that I'll look at the configure.in carefully (I mean, not diff, but from scratch again) in case someone miss it in a previous upload
[18:07] <jjardon> didrocks, ok, will do
[18:07] <didrocks> jjardon: thx :)
[18:09] <pitti> zul: hi (spelling "pitti" with two t helps :) )
[18:09] <jjardon> we are working hard to remove deprecated libraries for 2.30: Gnome packages don't depend on libgnome, libgnomeui, libglade, libgnomecanvas (only evolution), libgnomevfs, libgnomeprint
[18:10] <pitti> zul: the hooks are completely agnostic about the UI
[18:10] <pitti> zul: if you run ubuntu-bug without $DISPLAY or without -{gtk,kde} installed, it will use the CLI based frontend
[18:10] <pitti> zul: and show questions/read answers from the console
[18:10] <pitti> zul: do "DISPLAY= ubuntu-bug storage" to see how it works
[18:10] <zul> pitti: sorry about that great thanks for answering my question
[18:11] <pitti> zul: np, I just missed your question for a while
[18:11] <zul> pitti: thats ok i cant spell
[18:11] <didrocks> jjardon: I know, I don't saw it when making my diff in configure.in. I guess that was done before but didn't noticed by the uploader. That's why reviewing all deps from scratch won't hurt anyone :)
[18:13] <jjardon> didrocks, no worry, I'll check the configure.ac and report any issue. Thank you again for the update :)
[18:13] <ogasawara> slangasek: I created a separate 8.04.4 weather report - http://qa.ubuntu.com/reports/ogasawara/weatherreport-8.04.4.html
[18:14] <didrocks> jjardon: you're welcome, just open the bug as a reminder for me (I won't have the time to do it tonight)
[18:20] <jjardon> Do somebody if there is a problem whith http://people.canonical.com/~scott/daily-bootcharts/ ? ( It's not updated since 13 Jan)
[18:20] <ScottK> jjardon: Known issue.  Being worked on.
[18:24] <jjardon> ScottK, ok :) BTW, maybe helps to Desktop boot up removing some deprecated libraries: libgnomecanvas or libgnome, for example
[18:25]  * ScottK doesn't have any of those libraries on boot.
[18:25] <cody-somerville> Have libraries installed that don't get used at boot aren't going to slow down boot.
[18:25] <pitti> jjardon: Keybnz is on the other side of the planet right now, so I guess it won't be fixed this week
[18:27] <lamont> who is the current debian-installer victim^wguru?
[18:27] <jjardon> cody-somerville, the problem is that there are a lot of packafes that already don't depend on libgnome, but the package is still not update in Ubuntu: try apt-get remove libgnome2-0
[18:27] <superm1> pitti, wasn't the problem just caused by user-setup not working properly though?  new media spins with the new ubiquity/user-setup should be it?
[18:28] <cody-somerville> jjardon, Thats not going to affect boot speed unless those programs are run as a part of the boot sequence.
[18:28] <jjardon> gnome-panel and gdm, for example?
[18:29] <cjwatson> lamont: #ubuntu-installer
[18:29] <lamont> ta
[18:29] <kirkland> milanbv: am now
[18:30] <cjwatson> jjardon: run-time dependencies are calculated automatically.  Anything that depends on libgnome2-0 almost certainly actually links against it.  (The situation for build-dependencies is different.)
[18:31] <pitti> superm1: ah, I haven't booted the current desktop dailies; just tried UNE today
[18:34] <milanbv> kirkland: hi!
[18:34] <ccheney> doko_: ok will update the arm patch and upload 3.2.0~rc3 today
[18:34] <milanbv> I was wondering about the issues that appear when changing password for a user with ecryptfs
[18:35] <jjardon> cjwatson, we have to wait to packages get updated to latest versions, then. For example; libgnomeui was removed from gnome-panel in 2.29.5
[18:35] <milanbv> because from users-admin an admin is allowed to change the password without providing the old one to PAM, which breaks everything
[18:35] <jjardon> If someone interested of the actual status, take a look here: http://www.gnome.org/~fpeters/299.html
[18:35] <cjwatson> jjardon: yes, the desktop team does this routinely
[18:36] <cjwatson> fear not, we have people well on top of GNOME
[18:36] <kirkland> milanbv: hmm, right
[18:36] <kirkland> milanbv: that's been around for a while
[18:36] <milanbv> yeah
[18:36] <kirkland> milanbv: perhaps we should warn the admin if they're doing so
[18:36] <kirkland> milanbv: that they may be breaking the user's encrypted home setup
[18:36] <milanbv> I'm currently working so that you change your own password, you have to provdie the old one
[18:36] <milanbv> sure
[18:36] <cjwatson> jjardon: see e.g. http://people.canonical.com/~seb128/versions.html
[18:37] <jjardon> cjwatson, :) yeah, I suppossed that you already know
[18:37] <kirkland> milanbv: wait, huh?
[18:37] <cjwatson> we appear to have gnome-panel 2.29.5 already, for instance
[18:37] <kirkland> milanbv: changing your own password works fine
[18:37] <milanbv> but do you think there could be a kind of dialog that could run on the user's session if ecryptfs detects that the password no longer corresponds to the one you need?
[18:37] <cjwatson> 2.29.5.1, rather
[18:38] <milanbv> kirkland: it works fine when using the hack which runs gnome-about-me ATM - I'd like to make this cleaner
[18:38] <kirkland> milanbv: yes, that's the recommended way to change your password
[18:38] <kirkland> milanbv: or by using 'passwd'
[18:38] <milanbv> agreed
[18:39] <milanbv> what about that kind of dialog?
[18:42] <kirkland> milanbv: it's sort of out of my hands
[18:42] <kirkland> milanbv: you'd need to convince one of our desktop or foundations guys to fix that
[18:42] <kirkland> milanbv: i hate it too, fwiw
[18:42] <milanbv> hmm
[18:43] <milanbv> kirkland: another question: do you think it's possible to do something for people who may have changed their password by force, and who use encrypted *home*?
[18:43] <milanbv> i.e. when you can't mount the home dir
[18:44] <kirkland> milanbv: sure, it's easy to fix from the command line
[18:44] <kirkland> milanbv: they just need to run ecryptfs-rewrap-passphrase
[18:44] <milanbv> :-)
[18:44] <kirkland> milanbv: supplying their old, and new passphrase
[18:44] <milanbv> I mean: automatically form GDM
[18:44] <kirkland> milanbv: and then everything works again
[18:44] <seb128> jjardon, we follow GNOME closely on updates and we have no extra lib use easy to clean
[18:44] <kirkland> milanbv: again, i have nothing to do with anything above a command line
[18:44] <milanbv> OK
[18:44] <seb128> jjardon, all the libgnome* libbonobo* need to stay there this cycle
[18:45] <kirkland> milanbv: your best bet to to talk to someone like pitti or seb128
[18:45] <milanbv> and are there plans to put the passphrase in the gnome-keyring for Private dirs?
[18:45] <kirkland> milanbv: there have been many requests to improve the graphical integration of ecryptfs
[18:45] <milanbv> that would help changing passwords
[18:45] <kirkland> milanbv: unfortunately, i'm not tasked to do that
[18:45] <milanbv> sad - I'll see that we the desktop team
[18:46] <kirkland> milanbv: gnome-keyring == graphics, again, i can't really work on that
[18:46] <milanbv> anyway, I'm planning to add an option to encrypt home dirs when creating an user in users-admin
[18:46] <superm1> pitti, well even today's current desktop dailies don't have it.  either needs a respin to pickup ubiquity 2.1.12 or wait till tomorrow
[18:46] <jjardon> seb128, only tomboy depends on libgnome, there is no 2.30 gnome package that depends on libgnome (only bindings)
[18:46] <kirkland> milanbv: that would be great
[18:46] <milanbv> quite easy actually now that I've changed our protocol
[18:46] <seb128> jjardon, we stay on evo 2.28 for lucid
[18:46] <milanbv> (much easier than that password mess ;-) )
[18:46] <seb128> jjardon, 2.30 has way too many changes for a lts
[18:47] <kirkland> milanbv:  Lucid Alpha 2 released | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[18:47] <kirkland> milanbv: whoa, sorry
[18:47] <kirkland> milanbv: https://blueprints.edge.launchpad.net/~kirkland
[18:47] <jjardon> seb128, aps, didn't know that
[18:47] <kirkland> milanbv: let me try that copy-n-paste one more time
[18:47] <kirkland> milanbv: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-ecryptfs-desktop-ui
[18:48] <milanbv> nice!
[18:48] <seb128> jjardon, you are welcome to hang on #ubuntu-desktop for desktop question btw
[18:48] <milanbv> I can see your agenda is full :-)
[18:48] <kirkland> milanbv: that's a blueprint that collects ideas about what needs to be fixed in the GUI for ecryptfs
[18:48] <seb128> jjardon, or if you are interested in desktop work being done there
[18:48] <kirkland> milanbv: i recommend that you read that, and edit the whiteboard, adding the integration features you think are still missing
[18:49] <milanbv> is mrooney working on this?
[18:50] <kirkland> milanbv: not actively, that i know of
[18:50] <kirkland> milanbv: he's been around it, from time to time, though
[18:50] <kirkland> milanbv: you might poke him, see if he's working on it actively, and offer to help, if you like
[18:50] <jcastro> mdeslaur: If I'm an upstream and I want to communicate with Ubuntu on security-type things you send me to which wiki page?
[18:50] <kirkland> milanbv: you should also poke pitti
[18:50] <milanbv> not sure I'll be able to help in that regard
[18:51] <kirkland> milanbv: i think pitti was in favor of this work; he just didn't have any people to dedicate to this
[18:51] <milanbv> I'd just like to know what way I should choose
[18:51] <kirkland> milanbv: my hands are currently full doing ubuntu cloud work, and i have not much time for ecryptfs, and certainly not the desktop aspects of it
[18:51] <kirkland> milanbv: i need to run now, thanks for the feedback, patches would be welcome ;-)
[18:51] <milanbv> sure, I can understand that
[18:51] <milanbv> I'm quite busy too, actually :-)
[18:52] <milanbv> the encrypt home option is all I can do
[18:52] <tjaalton> there's a problem in the new sssd package where some deps have been trimmed from the libs, causing undefined symbols in some components
[18:52] <mdeslaur> jcastro: https://wiki.ubuntu.com/SecurityTeam/Contacts
[18:52] <tjaalton> but is it done on purpose by the default behaviour or what
[18:52] <jcastro> thanks!
[18:53] <mdeslaur> np
[18:57] <tjaalton> so I get this http://pastebin.ubuntu.com/359674/
[18:57] <tjaalton> instead of this http://sssd.pastebin.com/d4f2806e3
[19:13] <cjwatson> kirkland: bug 414986 - what crept back in, exactly?  open-iscsi-utils still seems to be a separate package with the expected contents
[19:14] <cjwatson> kirkland: and failures from ln are still ignored
[19:32] <tkamppeter> pitti, hi
[19:34] <tkamppeter> pitti, can you close http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550575? It is fixed by my new cpdftocps filter which I have introduced in 1.4.2-1 on Nov 17, 2009.
[20:40] <doko_> ccheney: did you verify that it did build?
[21:07] <ccheney> doko_: yea just did the build with the modified patch
[21:07] <ccheney> doko_: it worked on amd64 at least
[21:08] <ccheney> doko_: after looking at what changed closer it looks like the patch i made was the correct change in any case
[21:08] <doko_> ccheney: yes, but not on arm
[21:08] <ccheney> doko_: it seems they factored out part of the makefile into a generic makefile and i checked both for the Os vs O2 part
[21:09] <ccheney> doko_: it might not work even with the change that is true, rene completely disabled arm support for Debian but he didn't have this patch so not sure if this was the only issue he had
[21:09] <doko_> ccheney: I did check that it will fail. please wait with the upload
[21:10]  * ccheney isn't even really supposed to be messing with OOo, still have a huge backlog of work to do on firefox :-\
[21:10] <ccheney> doko_: the O2 still fails?
[21:10] <doko_> thumb fails
[21:11] <ccheney> doko_: ok
[21:11]  * ccheney will commit the new patch to ooo-build and wait to upload then
[21:14] <ccheney> ok pushed the change to master
[21:20] <slangasek> ogasawara: thanks; is it possible to point the weather report at hardy-proposed, in addition to hardy-updates?
[21:21] <slangasek> smoser: CONFIG_DEVTMPFS> dunno, would have to defer to Keybuk
[21:21] <slangasek> milanbv: pong
[21:22] <ogasawara> slangasek: yup, was going to ask that as I noticed the iso diff's were a little off
[21:28] <milanbv> slangasek: yeah, it was about PAM and changing passwords
[21:29] <milanbv> basically, and user is not allowed to change passwords for other users, even when providing their old password
[21:29] <milanbv> which means admins are forced to break encrypted home dirs if they want to change password for their users
[21:30] <smoser> can someone able please send my message onto -devel mailing list
[21:30] <smoser> https://lists.ubuntu.com/mailman/confirm/ubuntu-devel/fa61297872ac220b04d71ba0899e336257f2c3ae
[21:30] <milanbv> so I'm not sure what we can do about it - maybe nothing...
[21:30] <smoser> and if they can at the same time whitelist me, that'd be nice
[21:31] <smoser> i promise not to send any messages about acai
[21:33] <smoser> whoops. i realize that link was just for me. never mind all.
[21:34] <geser> was there some general hickup on the buildds recently? as I see some build logs where dpkg failed at unpacking the downloaded deb, e.g. http://launchpadlibrarian.net/38062888/buildlog_ubuntu-lucid-i386.mono-addins_0.4-6_FAILEDTOBUILD.txt.gz
[21:34] <slangasek> milanbv: well, that's not a PAM issue; it's an application-level decision not to allow changing passwords for other users
[21:34] <milanbv> sure, that's why I'm wondering about users-admin
[21:34] <ccheney> doko_: so you tested on arm with rc2 plus updated thumb patch?
[21:35] <ccheney> doko_: because with rc2 the thumb patch wasn't applied by default
[21:35] <slangasek> milanbv: and the encrypted home dirs shouldn't end up broken, it should only mean the user has to type two passwords...
[21:35] <milanbv> would there be a way to force PAM to accept the old password, even when root calls pam_chauthtok()?
[21:35] <slangasek> milanbv: doesn't users-admin just call the 'passwd' command?
[21:35] <doko_> ccheney: yes, which is a mistake
[21:35] <milanbv> ATM no
[21:35] <milanbv> in a few days, yes
[21:35] <slangasek> how does users-admin interface with PAM?
[21:36] <milanbv> but that doesn't solve the case of *other* users
[21:36] <milanbv> in Karmic, passwords are changed using chpasswd via the backends
[21:36] <slangasek> ah
[21:36] <milanbv> and for current user, via gnome-about-me
[21:37] <ccheney> doko_: so its failing in a different manner in the same area when using O2 then I guess?
[21:38] <milanbv> slangasek: what I would be interested in is a way for the privileged backends to give PAM the old password when we have it
[21:38] <doko_> ccheney: I'm currently test building, the build didn"t finish yet
[21:38] <slangasek> milanbv: pam_ecryptfs should always prompt for it when it doesn't have it; that's a per-module decision
[21:38] <milanbv> that way, admins would be able to change passwords for other users, e.g. asking them their old password (home context)
[21:39] <milanbv> you mean that pam_chauthtok() will always ask for it?
[21:40] <ccheney> doko_: ok no problem
[21:40] <slangasek> milanbv: pam_chauthtok doesn't ask for anything, the individual modules do all the prompting
[21:40] <ccheney> doko_: i committed my updates to ooo-build and ubuntu bzr
[21:40] <slangasek> so pam_ecryptfs has the opportunity to insist on getting a copy of the old password
[21:41] <milanbv> hmm, so that would be a good solution - always provide PAM with the password, except if admins don't want to provide it
[21:42] <slangasek> oh, are you not passing the prompts through to the user?
[21:42] <slangasek> PAM isn't designed for non-interactive use; if you have a UI, you ought to be passing the prompts through
[21:43] <milanbv> yeah, but there's D-Bus in between ;-)
[21:43] <milanbv> pretty complex
[21:43]  * slangasek shrugs. :)
[21:43] <milanbv> that's really messy
[21:44] <milanbv> but AFAIK you can make PAM work non-interactively
[21:44] <milanbv> I've code for that
[21:44] <slangasek> you can use PAM non-interactively and pretend it works :P
[21:44] <milanbv> why wouldn't it work?
[21:44] <milanbv> as long as I have everything it may need?
[21:45] <slangasek> PAM is not designed for non-interactive use, and if you use it that way you're going to have to apply a heuristic to the text prompt from the PAM module to figure out if it's asking for an old or new password
[21:46] <milanbv> have a look at the madness at http://git.gnome.org/browse/gnome-control-center/tree/capplets/about-me/gnome-about-me-password.c
[21:46] <milanbv> just to make passwd work from a GUI :-p
[21:46] <slangasek> (and you'll have to make sure PAM is called with LC_MESSAGES=C, because modules can localize their user prompts...)
[21:46] <milanbv> that's not better
[21:46] <milanbv> localize? they only pass me PAM_ECHO_ON/OFF()
[21:47] <slangasek> er
[21:47] <slangasek> no, there's a text string accompanying that
[21:47] <slangasek> :)
[21:48] <milanbv> maybe that's why it doesn't work
[21:48] <milanbv> the examples I found are maybe too simple
[21:48] <milanbv> so what do you think?
[21:48] <milanbv> I need to change passwords on the privileged side because I'm not allowed to do so as a normal user
[21:49] <milanbv> so I need D-Bus, thus no interactive conversation...
[21:49] <slangasek> I think if you want this to work reliably instead of repeatedly hunting corner cases, you want to make sure you can pass the text of the PAM prompts through to the user
[21:49] <milanbv> but that wouldn't be ideal either
[21:49] <milanbv> what do you want to do in a GUI with PAM prompts?
[21:49] <slangasek> have the user answer them?
[21:49] <milanbv> we don't want strange questions with custom entries...
[21:50] <milanbv> we need a defined set of entries all visible at once
[21:50] <slangasek> PAM isn't guaranteed to give you that
[21:50] <milanbv> and then send to PAM what we have - we can't provide more than old and new password, anyway
[21:51] <milanbv> hey, we're only supporting standard schemes, obviously
[21:51] <milanbv> people can't expect a password management dialog will handle their strange setup
[21:51] <slangasek> as I said, if you prompt for the old and new passwords up front, you have to use a heuristic on the text string to figure out which one to give in response to which prompt
[21:52] <slangasek> why shouldn't they expect that?
[21:52] <chrisccoulson> milanbv - have you had a look at what the gnome-screensaver lock dialog does with the text from PAM?
[21:52] <chrisccoulson> it has some bits in for handling various prompts
[21:52] <milanbv> could be interesting
[21:52] <milanbv> is that different from gnome-about-me?
[21:53] <chrisccoulson> milanbv - i'm not familiar with how gnome-about-me works
[21:53] <chrisccoulson> but i vaguely know how gnome-screensaver works
[21:54] <chrisccoulson> also, the GDM greeter will probably contain similar logic too
[21:54] <chrisccoulson> although i haven't checked that
[21:54]  * milanbv is looking at that file
[21:55] <milanbv> doesn't seem really nicer than toying with passwd directly
[21:55] <slangasek> milanbv: ecryptfs is precisely one of these "strange setups" - I can't even guarantee you which password PAM will prompt for *first* (old vs. new) in that case
[21:55] <milanbv> PAM is eveil
[21:55] <milanbv> evil
[21:56] <milanbv> if that's such a mess, I guess I'm going to keep the changes to the minimum
[21:56] <milanbv> i.e. only use passwd for current user
[21:56] <milanbv> and use chpasswd on the backends for others
[21:56] <milanbv> but that's not perfect
[21:57] <milanbv> > msg != NULL && g_str_has_prefix (msg, _("Password:")
[21:57] <chrisccoulson> milanbv - i don't know what the answer is, i'm afraid ;)
[21:57] <milanbv> what a joke we need such tricks :-)
[21:59] <milanbv> so even in your dreams there isn't an optimal solution?
[22:00] <milanbv> the fallback we have is that gnome-keyring should be able to ask for old and new password when it detects that it cannot decrypt the login keyring anymore...
[22:09] <slangasek> milanbv: the optimal solution *is to pass PAM's questions through to the user*...
[22:10] <milanbv> but that's mad from a UI design POV
[22:10] <milanbv> no UI does that!
[22:11] <milanbv> imagine a series of entries created on the fly, with obscure questions we can't even predict
[22:11] <slangasek> "no UI" - like GDM, or gnome-screensaver?
[22:12] <milanbv> they don't change passwords...
[22:12] <slangasek> GDM will
[22:12] <milanbv> only one entry
[22:12] <slangasek> (or should)
[22:12] <milanbv> it will?
[22:12] <milanbv> have people thought about this already?
[22:12] <slangasek> "only one entry" - nope, GDM has to be able to handle two-factor auth
[22:13] <milanbv> when does that happen?
[22:13] <slangasek> what do you mean?
[22:14] <milanbv> what's the second factor? :-)
[22:14] <slangasek> whatever the admin has configured?
[22:15] <milanbv> like the name of his dog? :-p
[22:16] <mathiaz> slangasek: hi - if a pakcage shows up on the " Source and binary demotions to universe " in component-mismatches.txt, is there anything else that needs to be done to demote it to universe?
[22:19] <slangasek> mathiaz: nope, it'll get processed by an archive admin at some point
[22:20] <mathiaz> slangasek: great - thanks.
[22:22] <slangasek> milanbv: you can see GDM's (thorough) PAM support in daemon/gdm-session-worker.c
[22:22] <milanbv> thanks - I'm currently reading the GUI part
[22:23] <milanbv> I'd like to see how all this is handled over D-BUs
[22:23] <milanbv> anyway, that's not something that will happen in users-admin, because the whole model of the gnome-system-tools is based on one bug D-Bus method called "set"
[22:23] <slangasek> for d-bus, I guess the server needs to generate a unique ID to attach to the message
[22:23] <milanbv> everything else is not supported, and is a pain to implement :-)
[22:24] <slangasek> hmm
[22:24] <milanbv> that would be a nice task for the new accounts-dialog that mclasen started
[22:25] <milanbv> hmm, I see how this works now
[22:26] <milanbv> directly transmitting questions to the GUI
[22:26] <chrisccoulson> milanbv - i was just going to ask you if you had seen mclasen's work
[22:26] <milanbv> that's not perfect since we can't e.g. tell the user the confirmation is not correct in real time - need to wait for PAM to fail
[22:27] <milanbv> chrisccoulson: yeah
[22:27] <milanbv> actually I've already got in touch with him
[22:27] <milanbv> I think users-admin is virtually dead
[22:27] <milanbv> I'm quite happy with the improvements I could bring in, but the general model is not very flexible for what we need
[22:28] <milanbv> (PAM is an example)
[22:28] <chrisccoulson> the new tool looks quite nice. it would be good to put some effort in there i think, and make sure it doesn't have all the issues we have currently
[22:28] <milanbv> yeah, for Lucid+1 I guess I'll switch to it
[22:29] <milanbv> but many common issues with users-admin are now fixed
[22:29] <milanbv> it's just that error reporting is still zero :-p
[22:31] <milanbv> anyway it was nice to see the problems we currently have with liboobs/users-admin
[22:31] <milanbv> that will help designing a tool that suits our needs
[22:38] <barry> anybody here with deep python-gobject and/or gdb-fu that might want to look into bug 503727 with me?
[23:35] <mathiaz> slangasek: hi - is there a reason by xubuntu.lucid/ has a server-ship seed?
[23:36] <cjwatson> mathiaz: because it was branched from ubuntu long long ago
[23:36] <mathiaz> cjwatson: ok - I'm looking at demoting elinks
[23:37] <mathiaz> cjwatson: and the xubuntu.lucid server-ship still has elinks in them
[23:37] <mathiaz> cjwatson: should I delete elinks from there as well?
[23:40] <cjwatson> mathiaz: probably
[23:40] <mathiaz> cjwatson: should I completely remove the server-ship seed for xubuntu.lucid?
[23:41] <cjwatson> if you like