[00:16] <ScottK> lamont: Yes.  Please.
[00:22] <micahg> lamont: if you're doing Debian uploads, nmap 5.5.x would be nice :)
[02:00] <Q-FUNK> say, I don't wanna sound pushy, but I've actually had to bork the dynamic /etc/resolv.conf from 2 of my 3 Precises hosts, otherwise, DNS plain doesn't resolve.
[02:09] <cyphermox> Q-FUNK: can you describe the kind of setup?
[02:10] <cyphermox> @pilot in
[02:10] <cyphermox> e.g. is it using NetworkManager, do you have static interfaces defined in /e/n/i, etc.
[02:22] <Q-FUNK> cyphermox: one host has exactly one ethernet.  same result whether I directly use dhclient or via n-m.  loopback fails to resolve to the outside world.
[02:22] <cyphermox> Q-FUNK: you shouldn't have anything set for loopback via dhclient directly
[02:23] <Q-FUNK> cyphermox: the other one has two ethers, one using dhclient, one with a fixed IP to serve my LTSP clients, both configured  via /etc/network.
[02:23] <Q-FUNK> cyphermox: you misread me.  resolvconf puts loopback as the only nameserver host.
[02:23] <cyphermox> Q-FUNK: for kicks, what's in /run/nm-dns-dnsmasq.conf on the system that runs NM?
[02:24]  * micahg mutters something about insserv and wanders off
[02:24] <cyphermox> Q-FUNK: not really. resolvconf by itself doesn't add 127.0.0.1
[02:24] <cyphermox> Q-FUNK: but NM might, if it got dns servers from a dhcp client
[02:24] <cyphermox> server, I mean
[02:25] <Q-FUNK> cyphermox: no idea what sets that as the only nameserver, but I know that if I purge resolvconf, I get the normal DNS servers sent by DHCP there.
[02:26] <cyphermox> you should compare these DNS servers with whatever is in /run/nm-dns-dnsmasq.conf on the system that runs NM, your answer possibly lies there.
[02:27] <Q-FUNK> cyphermox: on the host running n-m, /run/nm-dns-dnsmasq.conf  is what I should expect from the DHCP server.
[02:28] <cyphermox> good
[02:28] <cyphermox> so then is dnsmasq running?
[02:28] <cyphermox> (or even installed)
[02:31] <cyphermox> Q-FUNK: or is anything else listening on udp/tcp 53 acting as a caching nameserver, like bind for instance?
[02:32] <Q-FUNK> dnsmasq seems to be running
[02:34] <cyphermox> and doing something like "dig @127.0.0.1" results in a NOERROR with no answers, a REFUSED, or NXDOMAIN response?
[02:54] <Q-FUNK> that replies with all the root servers
[03:00] <cyphermox> Q-FUNK: then shouldn't things be working properly? I'm not sure I understand what the issue is then
[03:02] <Q-FUNK> cyphermox: doing 'apt-get update' replies with cannot resolve host archive.ubuntu.com
[03:03] <cyphermox> isn't "dig archive.ubuntu.com @127.0.0.1" working?
[03:03] <cyphermox> (unless you don't have 127.0.0.1 in /etc/resolv.conf?)
[03:03] <Q-FUNK> i only have that in there
[03:05] <Q-FUNK> much more worrysome is the host controlled by /etc/network/interface: dnsmasq doesn't show in 'ps'
[03:05] <cyphermox> sorry, I'm having a bit of trouble grasping exactly what might be going wrong if you can reach the loopback nameserver via dig, /etc/resolv.conf has 127.0.0.1 and all, unless the external nameservers just can't resolve archive.ubuntu.com (which would be something out of my control, really)
[03:05] <cyphermox> Q-FUNK: on that other host NM isn't running at all?
[03:06] <cyphermox> if not, I don't know what adds 127.0.0.1 to /etc/resolv.conf. you mentioned a switch or option to dhclient for that in a bug, maybe that's enabled?
[03:07] <cyphermox> there's no point in having such an option enabled if there is no nameserver running locally to grab the requests and parsing/sending them out
[03:07] <Q-FUNK> that's on another host; the only one on which resolvconf works as expected, oddly enough.
[03:09] <cyphermox> anyway, on all systems the main idea is to see what 127.0.0.1 responds as far as the host you're interested in goes. so if "dig archive.ubuntu.com @127.0.0.1" works for any such system, and that's that IP is the only thing in /etc/resolv.conf, then I don't see why things wouldn't just work
[03:11] <Q-FUNK> that's just it. on the host controlled by /etc/network/interface, dig returns nothing
[03:12] <cyphermox> nothing at all or an error?
[03:12] <Q-FUNK> dnsmasq doens't run on it, either
[03:13] <Q-FUNK> ; <<>> DiG 9.8.1-P1 <<>> archive.ubuntu.com @127.0.0.1
[03:13] <Q-FUNK> ;; global options: +cmd
[03:13] <Q-FUNK> ;; connection timed out; no servers could be reached
[03:13] <cyphermox> aye
[03:13] <cyphermox> that's expected if dnsmasq isn't running
[03:13] <cyphermox> (or any other process on port 53 to shepherd dns requests)
[03:14] <cyphermox> now then, why could resolv.conf be getting 127.0.0.1.
[03:14] <cyphermox> Is this written anywhere in /etc/resolvconf/* ?
[03:16] <cyphermox> you should also make sure it's not coming from a file in /run/resolvconf/interface (which is where things speak with resolvconf) and that /etc/resolv.conf is a symlink to /run/resolvconf/resolv.conf (which will make sure you're really looking at resolvconf writing that entry)
[03:17]  * cyphermox thinks we ought to figure out a way to include some such debug information in an apport hook for resolvconf, without including personal info
[03:18] <Q-FUNK> lrwxrwxrwx 1 root root 27 helmi  1 05:09 /etc/resolv.conf -> /run/resolvconf/resolv.conf
[03:19] <Q-FUNK> and /run/resolvconf/interface/eth0.dhclient has exactly what the dhcp server sent.
[03:23] <Q-FUNK> ah, wait.  dnsmasq-base is used by nm, right? since I don't have any interface controlled by nm, could this be why dnsmasq isn't running?
[03:23] <cyphermox> yes, dnsmasq ought to be started by /something/
[03:23] <cyphermox> but if everything is controlled outside NM, is that running at all?
[03:24] <Q-FUNK> that runs, but without anything launching dnsamasq, we cannot call home
[03:24] <cyphermox> is there a /run/resolvconf/interface/NetworkManager file?
[03:25] <cyphermox> or see if /var/log/syslog mentions NM updating nameservers
[03:25] <Q-FUNK> none
[03:25] <cyphermox> something like NetworkManager[1194]: <info> (wlan0): writing resolv.conf to /sbin/resolvconf in /var/log/syslog
[03:26] <cyphermox> might mean you're seeing a side-effect of NM considering unmanaged interfaces as up
[03:26] <cyphermox> but if there is no NM file in /run/resolvconf/interface, it's probably not it
[03:28] <Q-FUNK> there isn't any
[03:29] <Q-FUNK> Feb  1 04:03:40 voito dnsmasq[1090]: failed to access /var/run/dnsmasq/resolv.conf: Tiedostoa tai hakemistoa ei ole
[03:29] <Q-FUNK> : file not found
[03:30] <Q-FUNK> could it be that dnsmasq-base forgot to create /var/run/dnsmasq upon install?
[03:31] <Q-FUNK> I grep'ed for occurences of resolv.conf
[03:40] <Q-FUNK> Feb  1 05:34:19 voito NetworkManager[511]: <info> DNS: starting dnsmasq...
[03:40] <Q-FUNK> Feb  1 05:34:19 voito dnsmasq[708]: no interface with address 127.0.0.1
[03:40] <Q-FUNK> Feb  1 05:34:19 voito dnsmasq[708]: FAILED to start up
[03:40] <Q-FUNK> Feb  1 05:34:30 voito NetworkManager[511]: <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2)
[03:40] <Q-FUNK> I wonder what would cause that?
[03:41] <cyphermox> well, looks like as a minimum, you're missing lo in /etc/network/interfaces
[03:41] <cyphermox> (or anyway, why would dnsmasq find that there is no interface with 127.0.0.1?)
[03:41] <Q-FUNK> no, it's there
[03:41] <Q-FUNK> it appears in 'ip addr' too
[03:41] <cyphermox> ok
[03:42] <cyphermox> doesn't /var/run/dnsmasq exist?
[03:44] <Q-FUNK> nope
[03:46] <Q-FUNK> dnsmasq-base ships with /var/run, rather than with /var/run/dnsmasq
[03:47] <Q-FUNK> either way, since this is /var/run content, it would need to be dynamically created by the init script at bootup.
[03:48] <cyphermox> yes
[03:48] <cyphermox> or by the application itself
[03:50] <Q-FUNK> in this case, most probably by nm
[04:11] <Q-FUNK> cyphermox: confirmed. dnsmasq won't really be launched unless at least one interface is managed by n-m.
[04:12] <cyphermox> right, but NM won't be adding 127.0.0.1 to /etc/resolv.conf either then
[04:13] <cyphermox> (otherwise it would be adding a log about it in changelog)
[04:13] <cyphermox> err, syslog I mean
[04:13] <cyphermox> or you can file a bug about it -- I'm just wrapping things up to go to bed now
[04:15] <Q-FUNK> I'm still not sure what's causing it.
[04:28] <pitti> Good morning
[04:28] <ajmitch> morning pitti
[04:28] <cnd> I'm confused on the policy for uploading new packages to universe
[04:29] <cnd> I'm a core-dev and I've reviewed a package prepared by someone else
[04:29] <cnd> do I just upload it?
[04:29] <cnd> or do I need to get a second advocate still?
[04:29] <lifeless> AIUI just upload
[04:30] <pitti> cnd: yes, just upload it
[04:30] <cnd> ok
[04:38] <ajmitch> pitti: syncing a new source package (ruby-erubis) that afaict is a replacement for erubis, building the same binaries - do I need to file a removal bug?
[04:39] <pitti> ajmitch: yes, please do, so that we keep some documentation
[04:39] <pitti> erubis is still in Debian
[04:40] <ajmitch> yeah, it's still in debian, I haven't seen a removal bug filed there yet
[05:31] <ScottK> cnd: The policy is should be reviewed by two developers, not must.  It's up to you.
[07:35]  * YokoZar considers the implications of the multi-arch field for transitional dummy packages...
[07:44] <ricotz> YokoZar, hi
[07:45] <ricotz> YokoZar, i think it is useful to request the removal of the old wine binaries
[07:45] <ricotz> meaning the amd64 binaries of 1.3.28-0ubuntu1 in precise
[07:45] <YokoZar> ricotz: Yes, after I upload the wine1.4 package marking them as dummy packages
[07:46] <YokoZar> (to my ppa that is, to confirm working)
[07:46] <ricotz> YokoZar, ok :)
[07:46] <ricotz> btw 1.3.37 works fine here with multiarch on amd64
[07:47] <YokoZar> ricotz: yeah but that's not the win 64-bit compatible package I've done with 1.4 :D
[07:47] <YokoZar> (requires some careful surgery to get both 32/64 bit compatibility with the same wineserver)
[07:47] <ricotz> oh, nice, so there will be amd64 binary again then
[07:48] <YokoZar> right
[07:48] <YokoZar> although, your prefix (~/.wine) will still be 32 bit only unless you make a new one
[07:48] <ricotz> but the multiarch way using 32bit wine on amd64 is still the right choice then`
[07:48] <YokoZar> Yup
[07:49] <ricotz> ok
[07:49] <YokoZar> Well, sorta
[07:49] <YokoZar> the 32 bit package has to be split
[07:49] <YokoZar> You'll see
[07:49] <ricotz> ok, thanks :)
[07:49] <YokoZar> on amd64 you install wine1.4 and then it pulls everything you need.  You could also install wine1.4:i386 and avoid 64-bit compatibility if you really wanted.
[07:51] <ricotz> i see, hoping for some love for lucid too ;)
[07:52] <YokoZar> ricotz: Yeah I'm not sure what to do there other than PPA uploads as every Ubuntu before Oneiric will have sound issues due to broken alsa-plugins
[07:52] <YokoZar> (not that they didn't have sound issues anyway)
[07:52] <ricotz> yeah, i am fine with the ppa updates, sound isnt important in my case here
[07:56] <ricotz> oh speaking of alsa -- diwic, hi, i hope alsa 1.0.25 will find its way into precise
[07:59] <didrocks> @pilot in
[07:59] <diwic> ricotz, we haven't had a discussion about that, but so far I don't see any significant improvement compared to 1.0.24. (That is, talking userspace. The drivers we get from the kernel)
[08:02] <ricotz> diwic, hmm ok, you are right
[08:03] <ricotz> diwic, probably still worth some over-thinking
[08:10] <dholbach> good morning
[08:37] <infinity> doko_: Regarding "backport multiarch dpkg for lucid(we don't need this, do we?): POSTPONED"
[08:37] <infinity> doko_: Surely, we need a multiarch dpkg to be able to do single->multi upgrades smoothly for, eg, ia32-libs and flash-plugin?
[08:38] <infinity> doko_: (I didn't notice you made the edit to postpone it, I'm just pinging you because the spec is assigned to you)
[08:38] <infinity> doko_: Err, "didn't notice who made the edit..."
[09:31] <doko_> infinity, I'll talk with mvo, I just inherited this spec
[10:14] <YokoZar> Does apt not know about multi-arch: allowed yet?
[10:15] <YokoZar> (or depends foo:any for that matter)
[11:29] <tjaalton> the NEW queue is rather long..
[11:29] <tjaalton> ..though most of it is from last week or so
[11:35] <tjaalton> @pilot in
[11:36] <tjaalton> wait, I'm a week early
[11:36] <tjaalton> @pilot out
[11:36] <tjaalton> :)
[11:37] <jasox> Hi guys, I was wondering what font size (small/normal) do you use in ubuntu on 24" monitor(16:10) ?
[11:47] <jacekmigacz> Up-arrow captures printscreen on alternative WM. Does gnome-settings-daemon altering xkbmap somehow?
[13:31] <Daviey> Who can fix a missing ddeb issue for Lucid?
[13:34] <seb128> Daviey, what's the issue? if the build is older than a week probably nobody out of doing a no change upload to trigger a new build
[13:34] <Daviey> pitti: Do you know who can add a missing ddeb?
[13:34] <seb128> Daviey, the ddebs are kept for a week
[13:34] <seb128> if they didn't get copied or moved during that time you will need a new build
[13:34] <pitti> Daviey: we can try to fish it out of the buildd, if it has built within the past 7 days
[13:34] <Daviey> seb128: waat, is that a new thing?
[13:35] <pitti> it's been like that forever
[13:35] <pitti> ddebs.u.c. has been a horrible temporary hack for the past n years
[13:35] <Daviey> pitti: it's a lucid sru, from last August.
[13:35] <pitti> Daviey: that's gone, I'm afraid; it needs a new build
[13:35] <seb128> Daviey, they are kept on the builders for a week I mean, once collected they are kept on the ddeb server while the version is the current one
[13:35] <seb128> but you only get a week to "collect" them
[13:35] <pitti> Daviey: this is only really going to work well once LP supports them properly
[13:36] <Daviey> http://ddebs.ubuntu.com/pool/main/a/autofs5/ <-- has lucid release, but not -updates :/
[13:36] <Daviey> seb128: Oh, someone needs to request them to be copies across?
[13:37] <Daviey> pitti: Thanks.
[13:37] <seb128> Daviey, there is a service doing that but it bugged and it's over a week since the build it's too late to sort it out without a rebuild
[13:37] <pitti> Daviey: no, there are no manual requests
[13:37] <pitti> Daviey: but ddebs.u.c. hit -ENOSPC often, or the apache on the buildds tend to time out, etc.
[13:38] <Daviey> ah, right
[13:41] <Daviey> It's going to be easier to just provide a ddeb out of band :)
[13:41] <pitti> you need the accompanying .deb, too
[13:53] <kenvandine> @pilot in
[14:01] <cjwatson> mvo: bug 924079 - do you think we need a release-upgrader-apt backport for oneiric as well, or would it be better to try to isolate the fix?
[14:01] <cjwatson> I suppose isolating the fix would help apt-get dist-upgrade users
[14:02] <cjwatson> definitely something wrong with unpack ordering and M-A: same packages
[14:06] <dholbach> dpm, m_3, tumbleweed, barry, Laney: ready? :)
[14:06] <dpm> dholbach, it's in 1h, right?
[14:07] <dholbach> yep
[14:09] <Laney> hmmm, I will be by 8pm :P
[14:12] <Laney> dholbach: the formatting of the logs on the wiki is annoying, can that be improved?
[14:12] <Laney> horizontal scrolling ...
[14:12] <dholbach> https://bugs.launchpad.net/ubuntu-website/+bug/812337
[14:12] <Laney> nice
[14:12] <dholbach> sladen seems to be in touch with whoever is responsible
[14:30] <cjwatson> mvo: I've isolated it to a single fix, although, as you may have guessed, it's Chris Baines' GSoC work on unpack/configure ordering
[14:38] <cyphermox> @pilot out
[14:39] <mvo> cjwatson: thanks! in a call right now - I assumed that its in there, it is probably difficult to backport that in isolation :/
[14:39] <cjwatson> mvo: I think I'll take this to mail, it's quite complex :)
[14:39] <mvo> ok
[14:39] <cjwatson> mvo: it actually applies cleanly in isolation to oneiric, but I'm not sure about ABI implications
[14:39] <mvo> aha, cool
[14:39] <mvo> if you pastebin the diff I'm happy to have a look
[14:40] <cjwatson> http://paste.ubuntu.com/825133/ - it changes protected members of pkgPackageManager, which I think aren't actually used in practice by binaries but I suspect that technically they may form part of the ABI
[14:42] <cjwatson> I suppose one of the bazillion things wrapping libept might inherit from that class
[14:43] <cjwatson> er, s/libept/libapt/
[14:43] <mvo> cjwatson: yeah, but that looks not too scary, after the call I can do some poking on it to see if we can get it done in a abi compatible way
[14:43] <mvo> thanks a bunch cjwatson!
[14:43] <cjwatson> OK, I'll take it to mail and we can see
[14:44] <mvo> ok
[14:46] <barry> dholbach: mostly! it would be great to get that upg branch published by then.  i'll address the review this morning
[14:47] <dholbach> barry, excellent
[14:47] <dholbach> barry, I'm a bit busy right now - maybe somebody else can help review it?
[14:48] <barry> dholbach: poolie reviewed it last night (which is great b/c there's lots of bzr stuff in there).  i think i have perms to land it after fixing his issues, but not to push them out to web
[14:49] <dholbach> barry, dpm has access, but might be busy with his session in a few minutes
[14:50] <barry> dholbach: no worries, my session is in 4h so i'll ping dpm a little later
[14:50] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek day 2 starting in 10 minutes in #ubuntu-classroom
[14:50] <dpm> barry, dholbach, sounds good
[14:50] <dholbach> dpm, lass den cronjob einfach alle 30m laufen ;-)
[14:51] <zul> doko_: python-keystoneclient should be fixed now
[14:51] <dpm> dholbach, ;-)
[14:51] <doko_> zul, \o/
[14:51] <zul> stupid vitualenv
[14:55] <m_3> dholbach: yup, I'm on at 1700UTC
[14:55] <dholbach> m_3, excellent
[15:07] <ali1234> mvo: ready when you are
[15:12] <mvo> ali1234: hello - if you run "sudo apt-get update; sudo apt-get instlal -f" does that fix the issue you were seeing?
[15:12] <ali1234> no
[15:12] <ali1234> well, not unless there's a update released in the past few hours that fixes it
[15:14] <ali1234> yeah, as before, that does nothing
[15:17] <mvo> ali1234: could you paste(bin) the output of "apt-cache policy openjdk-6-jre-headless:i386 openjdk-6-jre-headless" please (this is bug #924096 right?)
[15:17] <ali1234> yes
[15:18] <ali1234> mvo: http://paste.ubuntu.com/825183/
[15:22] <mvo> ali1234: hm, that looks right on that level
[15:23] <ali1234> yes, apt-get etc does not want to install the i386 package. only update-manager
[15:23] <ali1234> there is some history n this too
[15:23] <ali1234> this was a upgrade from oneiric. after upgrading, all the java packages were still installed, however there was no "java" in the path
[15:23] <ali1234> as if no alternative was selected (not really familiar with how that works)
[15:24] <ali1234> also looking at the list of installed files for the jre packages gave "file lists only available for installed packages" in synaptic, however, apt and synaptic both claimed that the packages were installed in other parts of their UIs
[15:25] <ali1234> so i purged everything and reinstalled
[15:25] <ali1234> then update manager started wanting to install the i386 package
[15:25] <ali1234> so maybe i have some old oneiric files left behind that are messing it up?
[15:27] <mvo> ali1234: you can run apt-get install -o Debug::pkgDepCache::AutoInstall=true install -f to see what is trying to install the java packages that might already help a bit
[15:29] <ali1234> i think there is one too many installs in that command line
[15:29] <ali1234> mvo: http://paste.ubuntu.com/825195/
[15:29] <ali1234> *only* update-manager wants to install the java packages
[15:30] <mvo> ali1234: ohhh, hold on a sec, I have a idea
[15:32] <mvo> ali1234: could you please run "bzr branch lp:update-manager; cd update-manager; ./update-manager" and let me know if it still wants to do that?
[15:34] <barry> dpm: branch merged.  upg ready to go
[15:35] <ali1234> mvo: bzr says "bzr: ERROR: Target directory "" already exists."
[15:36] <mvo> ali1234: could you create a new empty place like /tmp/foo or something please? and cd into it, then hpefully bzr will not complain anymore :)
[15:37] <ali1234> that's what i did
[15:41] <mvo> ali1234: odd, I just tried it here and it worked ok, took a while though
[15:42] <ali1234> here it bombs out instantly
[15:43] <ali1234> does launchpad to tarballs?
[15:45] <ali1234> mvo: btw did i ever tell you about my update-manager patch that integrates with affecting-bugs?
[15:45] <ali1234> so it the change logs it says "this bug affects you"
[15:47] <mvo> ali1234: oh? no you didn't :)
[15:47] <ali1234> well, there's that...
[15:47] <mvo> ali1234: you can try this patch here instead http://paste.ubuntu.com/825210/
[15:47] <mvo> ali1234: if the bzr branch is not working
[15:48] <ali1234> apply that directly to precise version?
[15:52] <ali1234> mvo: that's fixed it yes
[15:53] <mvo> ali1234: awsome thanks!
[15:53] <mvo> ali1234: I will do a update with that
[15:57] <ali1234> mvo: http://paste.ubuntu.com/825232/ is my patch. it's a nasty nasty hack and affecting bugs wasn't even available when i made it.
[15:57] <ali1234> but if i ever get bzr working i might try to clean it up a bit
[16:04] <didrocks> @pilot out
[16:21] <seb128> cjwatson, ev: can we get bug #892384 assigned to someone or milestone so it doesn't slip through this cycle?
[16:22] <seb128> it's basically gtkwidgets.py in ubiquity having some
[16:22] <seb128> "        # TODO i18n
[16:22] <seb128>         l = Gtk.Label('Take a photo:')"
[16:22] <seb128> i.e untranslatable strings
[16:22] <cjwatson> seb128: ok, I'll take it
[16:22] <seb128> cjwatson, thanks
[16:23] <dpm> dholbach, barry, upg update pushed to the web. Does that look ok to you? http://developer.ubuntu.com/packaging/singlehtml/
[16:25] <barry> dpm: not quite.  it still looks out of date
[16:25] <dholbach> barry, did the package build already?
[16:26] <barry> dholbach: oh!  i didn't realize an archive upload was necessary.  let me do that now
[16:26] <dholbach> currently building https://code.launchpad.net/~ubuntu-packaging-guide-team/+recipe/ubuntu-packaging-guide-daily
[16:26] <barry> dholbach: ah, it's running.  okay cool
[17:01] <smoser> doko_, i removed the ppa because an upgrade left my system not starting lightdm (and i immediately suspected libc and removed it) but it turned out that an upgrade had left me without ubuntu-desktop.
[17:01] <cjwatson> barry: I wouldn't mind looking at -o Debug::pkgProblemResolver=true output from your system where ia32-libs is held back
[17:02] <cjwatson> (well, actually, I'd hate it, but I'm prepared to ;-) )
[17:02] <barry> cjwatson: ;)  sure i can generate that
[17:02] <doko_> smoser, was that at UDS? the lightdm issue is fixed
[17:02] <smoser> this was this week.
[17:03] <smoser> but i'm fairly sure it was a result of uninstalled packages that got removed somehow in an upgrade.
[17:04] <barry> cjwatson: well, that doesn't actually output much of anything.  are you sure you don't want -o Debug::pkgPackageManager=true ?
[17:04] <doko_> ok
[17:05] <apw> cjwatson, what are the symptoms when one tries to update a 64bit ia32libs infected system O -> P
[17:05] <cjwatson> barry: for good measure, let's have 'apt-get -o Debug::pkgProblemResolver=true -o Debug::pkgPackageManager=true -o Debug::pkgOrderList=true dist-upgrade'
[17:06] <smoser> and then lightdm was failing. but i seem to have not even included the trace or the segfault.
[17:06] <barry> cjwatson: cool.  should i attach it to that bug or open a new bug?
[17:06] <cjwatson> apw: it calculates the upgrade successfully, then when you say yes go ahead, it says "Couldn't configure pre-depend libtinfo5 for libncurses5, probably a dependency cycle."
[17:06] <cjwatson> barry: maybe just a pastebin for now?
[17:07] <barry> cjwatson: k
[17:07] <apw> cjwatson, ok so i can hit return and find out ...
[17:07] <cjwatson> apw: I'm not ruling out the possibility that there are multiple bugs involved :-)
[17:07] <slangasek> seb128: soft freeze for alpha2? :)
[17:07] <cjwatson> and it's possible the exact symptoms even of this one vary
[17:07] <seb128> slangasek, yes?
[17:07] <apw> cjwatson, i suspect my main devel box here is about to hit the issue, so do you want to keep that machine as a tester for the fix, or should i go ahead and update it
[17:08] <apw> (i literally have the 'go' button on my screen when i heard about this issue)
[17:08] <slangasek> seb128: eog, gedit uploads hit the CDs, and don't seem to be milestone-critical?
[17:08] <seb128> slangasek, I though bug fixes updates to component which were not creating installability issues were ok?
[17:08] <cjwatson> apw: are you using update-manager / do-release-upgrade to do it?
[17:09] <slangasek> seb128: ah, if that's the current agreement, I was unaware of it
[17:09] <seb128> slangasek, no, that was my understanding of alpha soft freeze from years ago, I'm sorry if that's off or if that changed
[17:10] <apw> cjwatson, yeah 'update-manager -d' and sitting with the dialog ready to go
[17:10] <slangasek> seb128: heh, that's not what the standard was when I was RM :)
[17:11] <cjwatson> apw: then just go ahead - it saves a state tarball in advance which gets attached to apport bugs and can be used to recreate a chroot with all the matching packages
[17:11] <cjwatson> apw: I already have one of those from RAOF
[17:12] <cjwatson> so working on upgrade bugs goes "grab apt-clone state from bug, restore into chroot, set that up as an schroot with overlayfs, then repeatedly upgrade / throw away overlayfs until you get it working"
[17:12] <cjwatson> it's almost enjoyable
[17:12] <apw> cjwatson, you have an interesting defination of enjoyable :)
[17:12] <cjwatson> I did say almost
[17:13] <dholbach> barry, dpm: the natty seems to be finished - not sure though if it was published yet though
[17:15] <dholbach> err, natty build
[17:16] <kenvandine> @pilot out
[17:16]  * dholbach hugs kenvandine
[17:16]  * kenvandine hugs dholbach
[17:16] <dholbach> :)
[17:20] <highvoltage> free hugs!
[17:21]  * dholbach hugs highvoltage too
[17:21] <highvoltage> :)
[17:21]  * ogra_ hugs highvoltage, dholbach and kenvandine 
[17:21] <dholbach> hey ogra_ :)
[17:21] <ogra_> :)
[17:21] <kenvandine> ;-D
[17:21]  * dholbach hugs ogra_
[17:21] <dholbach> alright - time to call it a day - see you tomorrow
[17:22] <highvoltage> have a good evening dholbach
[17:55] <apw> cjwatson, ok mine went ahead and did the update even though i had ia32libs installed, interesting
[17:55] <cjwatson> apw: OK, maybe I'm overstating the scope of the problem then
[17:55] <cjwatson> Better than understating it I guess
[17:55] <apw> cjwatson, yep, much better indeed
[17:56] <apw> and mine may crater sometime in the next 3 hours that it claims are needed fo rthe update
[17:56] <cjwatson> oh, it hasn't downloaded the packages yet?
[17:56] <apw> yep, past that and installing them now
[17:56] <cjwatson> ok, I think the failure is immediately after download
[17:57] <apw> cjwatson, ok so i got past it somehow ...
[17:58] <apw> it is indeed removing and replaceing a bunch of :i386 packages as wel speak
[17:58] <cjwatson> oh, you already had :i386 packages installed before the upgrade?
[17:58] <apw> cjwatson, yeah, though i have no idea why, i have the ia32-lib and ia32-libs-multiarch:i386 installed
[17:59] <cjwatson> then it doesn't affect you - this is only for systems that didn't previously have anything :i386 installed
[17:59] <apw> ahh sorry :)  then i am a false false alarm
[17:59] <cjwatson> the problem is in computing the unpack ordering for libc6:i386 / libgcc1:i386 when they weren't already installed
[17:59] <apw> cjwatson, so can't we just install one at random in O before the update
[18:00] <apw> to trigger those to install from O
[18:00] <slangasek> cjwatson: ia32-libs couldn't be installed in oneiric without :i386
[18:00] <apw> rather than fixing apt :)
[18:00] <slangasek> it was just a less complete conversion
[18:00] <cjwatson> could do I suppose, but the apt fix is known
[18:00] <cjwatson> slangasek: huh, then I've misdiagnosed something
[18:01] <cjwatson> slangasek: are you *sure*?  It only Recommends: ia32-libs-multiarch
[18:02] <cjwatson> slangasek: and RAOF's apt-clone file has ia32-libs installed without AFAICS any :i386 packages
[18:02] <slangasek> cjwatson: oh, really?  hrm, wonder why it was only a recommends
[18:03] <micahg> I would think it's only a recommends so people can selectively install the multiarch libs
[18:03] <cjwatson> that does change the tone of the release note, though, so I'll amend it
[18:03] <slangasek> micahg: there's nothing selective about ia32-libs
[18:03] <micahg> slangasek: right, but with multiarch there could be
[18:03] <slangasek> nor about ia32-libs-multiarch
[18:03] <slangasek> no, because with multiarch ia32-libs is there solely for compatibility
[18:03] <micahg> i.e. just install the libs you need from i386
[18:04] <cjwatson> but the point of ia32-libs is to supply everything it used to supply
[18:04] <cjwatson> because there are packages that depend on it and expect that
[18:04]  * slangasek nods
[18:04] <slangasek> so I think that was simply a bug in the oneiric package
[18:07] <cjwatson> I've toned down the release note to say that this only happens sometimes and to give an example of the error message you get if you encounter this
[18:07] <cjwatson> I'm not sure there's much value in explaining the exact circumstances since it's already pretty wordy
[18:08] <cjwatson> apw: so yes, it's true that that's a viable fallback for *this* apt bug - but I wonder about the next one
[18:08] <cjwatson> apw: this is already the third apt bug that I've considered SRUing into oneiric
[18:09] <cjwatson> well, bug fix :)
[18:09] <apw> :)
[18:10] <cjwatson> and that's just in a week of looking at upgrade bugs on and off
[19:58] <bdmurray> stgraber: I've updated bug 924836 and can get the upstart log if you like
[20:03] <stgraber> bdmurray: yeah, I see nothing wrong in what you posted so upstart logging would probably help find the cause of the failure
[20:03] <bdmurray> stgraber: hmm, I think I only saw the message on first boot
[20:05] <stgraber> bdmurray: did you briefly see it or did you see the whole sequence of "waiting for network", "waiting up to 60 more seconds", "booting system without full network"?
[20:05] <bdmurray> stgraber: the whole sequence
[20:07] <stgraber> bdmurray: Riddell also said first boot in the bug report, so might be something that fixes itself ...
[20:07] <stgraber> bdmurray: now that I'm waiting for some rebuilds, I'll try a clean Ubuntu desktop install in a VM
[20:08] <stgraber> (and boot directly with --log on the first boot)
[20:27] <stgraber> bdmurray: reproduced (with --log). Will look into what's wrong once it times out
[21:04] <jdstrand> mdeslaur: do you happen to know off hand why lightdm would not be displaying 'Other user' on 12.04, or if there is a way to login as someone under uid 1000?
[21:04] <jdstrand> mdeslaur: I found user.conf for lightdm, but it said that accountsservice would override anything in that file
[21:05] <jdstrand> mdeslaur: if not, I'll keep poking
[21:06] <mdeslaur> jdstrand: accountsservice has a minimum UID, and won't make lightdm aware of any user under that
[21:06] <mdeslaur> jdstrand: what are you trying to do?
[21:07] <jdstrand> mdeslaur: for quite some time on machines that I administer I create my user as 999 so that it doesn't show up in the list. I can't seem to be able to login via lightdm as that user in 12.04
[21:07] <mdeslaur> jdstrand: nope, that won't work
[21:08] <jdstrand> mdeslaur: do happen to know why there was this change? why won't lightdm allow me to login as someone not in the list like it used to?
[21:09] <jdstrand> mdeslaur: well, that is enough for me to file a bug I guess. thanks
[21:11] <mdeslaur> jdstrand: you _could_ change login.defs to lower it to 999
[21:11] <jdstrand> sure, but then I show up in the list
[21:12] <jdstrand> people complain to me that it is their computer, why should I be in the list at all let alone before them (since I am alphabetically before most of them)
[21:13] <jdstrand> anyhoo, I know it isn't your problem, so I'll move along
[21:13] <mdeslaur> jdstrand: oh, I see :)
[21:19] <mdeslaur> jdstrand: you could try "hide-users=true" in lightdm.conf
[21:22] <mdeslaur> jdstrand: http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/trunk/revision/236
[21:22] <seb128> what do you try to do?
[21:22] <jdstrand> hmm
[21:23] <jdstrand> seb128: removing the 'Other' option in lightdm is causing me mild grief now, and a lot down the line
[21:23] <jdstrand> seb128: I administer a not small number of machines for various people
[21:23] <jdstrand> seb128: I don't own the machines
[21:23] <seb128> how did you solve that issue before?
[21:24] <jdstrand> seb128: so when we started displaying usernames rather than having people type them in the greeter, my name showed up
[21:24] <seb128> oh, what mdeslaur said? use hide-users=true to go back to an entry rather than a list
[21:24] <jdstrand> seb128: and they are like "Why are you in the list when you login?" or "Why are you before me in the list-- this is *my* computer"
[21:25] <jdstrand> seb128: so I created a user with uid 999
[21:25] <jdstrand> this allowed me to use 'Other' for me
[21:25] <seb128> well it seems you use those machines little enough to just log on a vt when you need to log in?
[21:26] <jdstrand> seb128: I wonder why this can't be configuration in the greeter. I guess I can go back to the old way, but it seems a weird change imho
[21:26] <jdstrand> seb128: I can, but I do like to go into X if needed
[21:27] <jdstrand> I have a feeling I am not the only one who will find this inconvenient
[21:27] <seb128> jdstrand, startx? ;-)
[21:27] <jdstrand> seb128: will that still setup everything correctly?
[21:28] <seb128> it should be mostly working
[21:28] <jdstrand> heh
[21:28] <jdstrand> well, it was working perfectly in 11.10 ;)
[21:28] <seb128> jdstrand, but yeah, you should open a bug on unity-greeter, not sure why robert_ancell linked the "other" option to the hide-users
[21:28] <seb128> that seems like it could be its own option
[21:29]  * jdstrand files
[21:29] <jdstrand> seb128: thanks
[21:29] <seb128> jdstrand, user testing showed that the "others" entry was confusing quite some users who wonder why there is an "other" entry on their box
[21:29] <seb128> that's why they hide it by default
[21:29] <seb128> but I'm sure it could be a standalone option rather than linked to the user list
[21:30] <jdstrand> that's cool-- I don't care about the default, I just think it should be configurable
[21:30] <seb128> yeah, I'm a bit surprised robert_ancell did it this way
[21:31] <seb128> he probably did whatever was easiest, and nobody made a case for having the option before you
[21:32] <jdstrand> :)
[21:33] <mdeslaur> jdstrand: maybe put a little secret pi symbol on the bottom of the screen that can be clicked  :P
[21:33] <jdstrand> hehe
[21:37] <jdstrand> seb128: fyi, 925125
[21:39] <seb128> jdstrand, thanks
[21:53] <emgent> salut
[22:17] <YokoZar> slangasek: ia32-libs-multiarch is only a recommends of ia32-libs in oneiric because there were amd64 packages in oneiric that needed to be built with ia32-libs and ia32-libs-multiarch is unavailable on a 64-bit build daemon
[22:17] <slangasek> ah
[22:18] <slangasek> so not a bug we can really fix, then
[22:21] <YokoZar> slangasek: Yeah.  We could make it a depends in precise I suppose but I don't know if that would help anything
[22:24] <slangasek> it's already a depends in precise
[22:24] <YokoZar> Ahh, good