[03:50] <pitti> Good morning
[03:50] <pitti> bdmurray_: 298217 needs to be accepted into -proposed first
[05:36] <didrocks> good morning
[05:36] <pitti> stgraber: oh, ltsp-server-standalone recently became NBS?
[06:23] <buxy> https://bugs.launchpad.net/~jerome-bouat I wonder if someone should just go ahead and close all its "/etc/logrotate.d/foo should not have compress option"
[06:24] <buxy> (I closed one on dpkg already)
[06:43] <geser> pitti: Hi, it is ok to ack one own uploads to -proposed? I already forgot that I uploaded a fix for bug 788943 to -proposed and it's still there (3 months later)
[06:44] <pitti> geser: uh, 3 months?
[06:44] <pitti> geser: the oldest upload on https://launchpad.net/ubuntu/natty/+queue?queue_state=1 is from Friday, and unscd is not there
[06:44] <pitti> geser: ah, I misunderstood, it's in -proposed already
[06:45] <pitti> geser: yeah, as long as you test the actual -proposed package instead of a local build, it's fine for me
[06:45] <geser> yes, it's waiting for sru verfication
[06:47] <dholbach> good morning
[06:51] <pitti> hey dholbach
[06:52] <geser> good morning dholbach
[06:53] <dholbach> hey pitti, hey geser
[06:58] <fishor_> hallo all, are there any way to automatically find debug symbols, if they exist. I currently research a performance problem  connected with this library: libapt-pkg.so.4.11.0
[06:58] <fishor_> but i just can't find the dbg package for it
[07:03] <geser> fishor_: https://wiki.ubuntu.com/DebuggingProgramCrash describes how to install the -dbgsym packages (packages with the debug symbols)
[07:03] <RAOF> There's even a script attached that'll list all the dbgsym packages you need to install.
[07:11] <fishor_> geser, RAOF, thank you. But it looks like there is no apt-dbg package at all
[07:12] <RAOF> fishor_: You need to enable the dbgsym repository.
[07:15] <fishor_> RAOF, thank you!
[07:46] <apw> slangasek, iirc its about getting the x-server started as soon as possble, we only ie, when fallback is not actually going to do anything, the dependancies also get themseleves started
[07:50] <apw> s/ie,/delay/
[08:21] <Daviey> doko: bug 831100 is fixed upstream, Werror issue.. 3 options really, disable the Werror fail, new upstream version or cherry pick the fixes.  I tried cherrypicking, but some of the patches are embedded in 1 commit with other stuff - was taking too long.  Therefore, i'm suggesting removing of the Werror for this release, how do you feel about that?
[08:25] <tkamppeter> pitti, hi
[08:26] <pitti> hello tkamppeter
[08:28] <tkamppeter> pitti, I have discovered something strange: You know that if you have a script executable with a shellbang and the specified interpreter executable file does not exist, starting the script gives "No such file or directory". Now I have a compiled program which gives "No such file or directory". Have you ever seen such a thing?
[08:29] <pitti> tkamppeter: what does "file" say on that program?
[08:29] <pitti> tkamppeter: it might not be an ELF program but something else handled by binfmt_misc
[08:30] <tkamppeter> /opt/epson-inkjet-printer-nx420/cups/lib/filter/epson_inkjet_printer_filter: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
[08:30] <geser> tkamppeter: does ldd work on that binary?
[08:30] <pitti> tkamppeter: and you get the error if you run this directly? or through cups?
[08:31] <tkamppeter> pitti, geser, here is the strace: http://paste.ubuntu.com/692867/
[08:32] <pitti> hmm, never saw that one
[08:32] <cjwatson> Daviey: I am generally wholeheartedly in support of nuking -Werror from orbit
[08:32] <geser> tkamppeter: are the permissions correct (all paths accessible and the x-bit set on the binary)?
[08:33] <tkamppeter> pitti, geser, here is the ldd, it finds all its libraries: http://paste.ubuntu.com/692869/
[08:34] <pitti> tkamppeter: is /opt on a separate partition? might be mounted "noexec"?
[08:34] <cjwatson> tkamppeter: readelf -l /opt/epson-inkjet-printer-nx420/cups/lib/filter/epson_inkjet_printer_filter | grep -A1 INTERP
[08:34] <Daviey> cjwatson: heh
[08:34] <tkamppeter> pitti, /opt is on the root partition, and I do not get "Permission denied".
[08:35] <tkamppeter>   INTERP         0x0000000000000200 0x0000000000400200 0x0000000000400200
[08:35] <tkamppeter>                  0x000000000000001a 0x000000000000001a  R      1
[08:35] <tkamppeter> pitti ^^
[08:35] <cjwatson> blast, it must be a different length on amd64.  Try a little after that (-A2?)
[08:35] <tkamppeter> cjwatson ^^
[08:35] <tkamppeter>   INTERP         0x0000000000000200 0x0000000000400200 0x0000000000400200
[08:35] <tkamppeter>                  0x000000000000001a 0x000000000000001a  R      1
[08:35] <tkamppeter>       [Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]
[08:35] <tkamppeter>   LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
[08:36] <tkamppeter> cjwatson ^^
[08:36] <cjwatson> is /lib64/ld-lsb-x86-64.so.3 there and executable?
[08:36] <pitti> it doesn't exist here, anyway
[08:36] <geser> is .so.3 correct? I've here only a natty system to check and have only .so.2
[08:36] <tkamppeter> cjwatson, found the problem:
[08:37] <tkamppeter> till@till:~$ ll /lib64/ld-lsb-x86-64.so.3
[08:37] <tkamppeter> lrwxrwxrwx 1 root root 25 2011-08-25 20:49 /lib64/ld-lsb-x86-64.so.3 -> /lib/ld-linux-x86-64.so.2
[08:37] <tkamppeter> till@till:~$ ll /lib/ld-linux-x86-64.so.2
[08:37] <tkamppeter> ls: cannot access /lib/ld-linux-x86-64.so.2: No such file or directory
[08:37] <pitti> I only have /lib64/ld-linux-x86-64.so.2, the -lsb- one is probably a bad symlnk?
[08:37] <tkamppeter> cjwatson, is this a bug in Oneiric? If yes, which package?
[08:37] <cjwatson> bad symlink, the canonical path for ld-linux-x86-64.so.2 is under /lib64 not /lib
[08:37] <cjwatson> ld-lsb-x86-64.so.3 is not shipped by any package in Ubuntu AFAICS
[08:38] <cjwatson> oh, wait, lsb-core.postinst creates it
[08:38] <cjwatson>             ln -sf /lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
[08:38] <cjwatson> that is a little bizarre
[08:38] <tkamppeter> cjwatson, how does this symlink get onto my system?
[08:39] <tkamppeter> cjwatson, so it is a bug of lsb-core then?
[08:39] <jamespage> doko: MP ready for bug 831399
[08:39] <cjwatson> looks like it, yes
[08:39] <cjwatson> nasty little lurking bug
[08:39] <cjwatson> bug 837745
[08:40] <cjwatson> milestoned for oneiric
[08:41] <cjwatson> nice catch, thanks
[08:42] <tkamppeter> cjwatson, pitti, geser: sudo ln -sf /lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3 solves the problem. So bug is in lsb-core, postinst needs to get updated. Thanks to you all.
[08:53] <Chipzz> can't the package contain the symlink instead of it being created by the postinst?
[08:53] <tkamppeter> cjwatson, pitti, geser, moved bug 840998 to lsb now.
[08:58] <cjwatson> Chipzz: I'm going to go right ahead and guess there's a good reason, since the lsb maintainer generally knows what he's doing.  Feel free to investigate the history if you care
[08:58] <Chipzz> cjwatson: more of a "wth" thing really
[08:59] <Chipzz> cjwatson: if it's done from the postinstall, you would think it might also link elsewhere under specific circumstances (why else create it from postinst?)
[09:00] <Chipzz> but if that is the case... isn't LSB supposed to be a standard? how does 2 possible destinations reconcile with the "standard" part?
[09:01] <cjwatson> I believe that the symlinks used to be shipped by an Architecture: all package, which made it impossible to ship architecture-dependent symlinks
[09:01] <cjwatson> nowadays it's Architecture: any but nobody went to clean that up
[09:01] <Chipzz> that would explain idd
[09:02] <Chipzz> sounds like one hell of a dirty mess (the original arch: all package)
[09:12] <tkamppeter> doko, mvo: Can you fix the "lsb" package updating the amd64 and i386 (if needed) links done in postinst for the new multiarch changes in Oneiric? Thanks. See bug 840998.
[09:17] <cjwatson> tkamppeter: I'm fixing it now
[09:17] <cjwatson> doko,mvo: ^-
[09:19] <cjwatson> i386 is fine
[09:23] <tkamppeter> cjwatson, thanks.
[10:00] <doko> mvo, jibel: not sure what to do with bug 853688, the terminal log looks fine?
[10:02] <jibel> doko, the terminal log is not relevant, only apt.log and main.log are interesting. apport attached it automatically. I'm removing it to avoid confusion.
[10:05] <pitti> hm, I suddenly get a ton of mail wrt. openstack-packagers
[10:05] <pitti> bug mail and merge proplsal
[10:05] <pitti> proposals
[10:05] <Laney> welcome to the club :-)
[10:06] <Daviey> you lucky people :)
[10:07] <Daviey> feel free to jump in.
[10:07] <bluefoxicy> has anyone stumbled across the weird rhythmbox bug where it plays 2 songs?
[10:08] <bluefoxicy> it seems pausing (which only pauses one song) and then advancing to the next song fixes it, but it's weird.  I don't understand how it decides to play 2 songs... what kind of coding error would do that
[10:56] <bdrung> chrisccoulson: are you around? can you forward your patch from eclipse 3.5.2-11ubuntu2 to upstream (because the original patch author needs to send it upstream)
[11:17] <cjwatson> plars: do you think you could fix bug 756043?  I started on it but it seems to have quite a few problems with the current version of Vala in Oneiric
[11:17] <cjwatson> plars: and it looks like it might be best addressed by a new upstream version, so ideally somebody familiar with the package would see if that needs a feature freeze exception
[11:18] <pitti> plars: NB that the previous vala-0.12 is still in the archive as well, in case that's easier
[11:37] <apw> pitti, i have been poking the compressed swap support we use in live-cd images on small memory systems and it seems it doesn't work at all anymore ... i have a proposed fix (for initramfs-tools) which you seem to have merged most recently ... i wonder if you might have time to look it over: lp:~apw/ubuntu/oneiric/initramfs-tools/compcache-zram/
[11:37] <apw> (this may well explain the increased minimum memory requirement we had in natty)
[11:38] <pitti> apw: compcache? sure that you don't mean ogra?
[11:38] <cjwatson> I can have a look at that
[11:38] <pitti> apw: anyway, can have a look over lunch, just not sure how qualified I am
[11:38] <cjwatson> I've poked compcache in the past
[11:39] <pitti> s/over/after/
[11:39] <cjwatson> and doing something about it for this cycle had been vaguely on my list
[11:39] <apw> cjwatson, that would be great.  its been worrying me for a while now
[11:41] <cjwatson> yeah, that looks nice to me
[11:41] <cjwatson> I assume you've tested it so I don't need to? :-)
[11:41] <apw> i tested it before the rebase to ubuntu4, let me retest it just to be really sure
[11:42]  * cjwatson <- lazy
[11:47] <apw> cjwatson, i redo the testing with todays isos etc, so it'll take me an hour or so
[11:47] <cjwatson> ok
[11:56] <Quintasan> jcastro: ping
[12:00] <Quintasan> jcastro: nvm
[12:30] <Sweetshark> doko: your debian upload of gcc-4.6.1-10 causes breakage for mozilla and libreoffice. could you backport the revert patch at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 there?
[12:30] <Sweetshark> see also: https://bugzilla.mozilla.org/show_bug.cgi?id=686280 and http://nabble.documentfoundation.org/Debian-gcc-or-LO-bug-td3347043.html
[12:31] <doko> Sweetshark, do you have the source file at hand?
[12:33] <Sweetshark> doko: nope (also I still have ubuntus 9ubuntu1, not debians -10)
[12:41] <apw> cjwatson, know anything about /run and /var/run being switched round ?
[12:41] <pitti> apw: /run is _the_ location now, everything else is backwards compat symlinks
[12:42] <apw> just upgrading a chroot and my update has died and:
[12:42] <apw> $ ls -l /var/run
[12:42] <apw> lrwxrwxrwx 1 root root 4 Sep  3 08:06 /var/run -> /run
[12:42] <apw> $ ls -l /run
[12:42] <apw> lrwxrwxrwx 1 root root 8 Aug 24 16:31 /run -> /var/run
[12:42] <Chipzz> pitti: oh? I was told several weeks ago that is not te situation?
[12:42] <pitti> the first is correct
[12:42] <apw> pitti, well the update has made this mess ... and isn't fixing it
[12:42] <pitti> apw: /run is suposed to be a tmpfs mount
[12:42] <apw> which ... it won't be in a chroot
[12:43] <Chipzz> but a chroot doesn't need to boot?
[12:43] <pitti> Chipzz: hm, Debian/Fedora switched to that a while ago, and we also followed; you might have more recent news than me, of course
[12:43] <pitti> apw: my sid chroot has a normal /var/run/, and a /run -> /var/run
[12:43] <cjwatson> apw: wiki.debian.org/ReleaseGoals/RunDirectory has full details
[12:43] <Chipzz> pitti: no; there was breakage wrt the transition, and I made the comment that might be a good thing to find packages not using /run yet
[12:44] <cjwatson> and people should read that before commenting further here, I think
[12:44] <Chipzz> to which someone replied that not everything is supposed to use /run
[12:44] <cjwatson> including Chipzz
[12:44] <pitti> so it seems that it might mix up these two different scenarios?
[12:45] <Chipzz> cjwatson: I don't recall the exact details, but I *think* the answer was that /run was only supposed to be used at boot (or sth)
[12:45] <cjwatson> I suggest getting exact details first :-)
[12:46] <Chipzz> cjwatson: did ubuntu's position on the subject change during the last nonths?
[12:46] <cjwatson> /run as a symlink is definitely a bug, anyway
[12:46] <cjwatson> yes, we merged the Debian changes
[12:46] <pitti> ^ so that part affects Debian as well
[12:47] <pitti> but if that's deliberate, it seems weird; seems easier to always have /var/run -> /run, and /run just not mounted (or bind-mounted) in a chroot
[12:47] <apw> cjwatson, now i seem to remember /run -> /var/run being an early perhaps upstart ism
[12:47] <apw> pitti, yep, if i was in that scenario i think i'd be fine
[12:47] <cjwatson> apw: I don't remember any such thing
[12:47] <pitti> apw: my sid chroot doesn't have upstart, and still this broken link
[12:48] <apw> $ dpkg -S /run
[12:48] <apw> initscripts, base-files: /run
[12:48] <apw> can i tell what type it is meant to be
[12:48] <cjwatson> Chipzz: anyway, I think what you've misremembered is that certain things aren't *required* to transition to /run in a hurry
[12:48] <cjwatson> apw: it is meant to be a directory
[12:48] <apw> cjwatson, sorry i mean what my _current_ dpkg database thinks it is meant to be
[12:48] <cjwatson> no
[12:48] <cjwatson> you can dpkg -c the relevant .debs
[12:49] <cjwatson> but dpkg never converts a symlink to a directory or vice versa by itself; that quite intentionally requires maintainer script code
[12:50] <Chipzz> cjwatson: that might have been it.. foggy memory etc, Monday and all that :)
[12:51] <cjwatson> Chipzz: it is absolutely false that /run is only supposed to be used at boot (just to clarify so that nobody here picks up that idea and gets confused by it)
[12:51] <Chipzz> cjwatson: and I stand corrected :)
[12:51]  * Chipzz crawls back under the rock he came from :P
[12:52] <apw> cjwatson, ok my latest base-files has /run and /var/run as directoris, the old one in my /var/cache/apt only has /var/run as a directory
[12:52] <cjwatson> apw: I suspect anyway that dpkg -c will be unhelpful; as I say this is all about the maintainer script code
[12:53] <cjwatson> so, there's stuff in initscripts.postinst about this
[12:54] <cjwatson> in a chroot, we can't do bind-mount tricks to move things around (at least not and have them stick), so the only choice is to make /run a symlink to /var/run
[12:54] <cjwatson> so in a chroot, the question is how /var/run became a symlink
[12:54] <apw> cjwatson, ok i have another chroot updated at the same time as this one, but not yet updated which has a real /var/run, so its something i just installed which bust it
[12:55] <cjwatson> (which means I was wrong above to say that /run as a symink is definitely a bug; chroots are a special case)
[12:56] <apw> as far as i can tell neither initscripts nor base-files changed recently
[12:56] <cjwatson> base-files makes /var/run a symlink to /run, but only on fresh installations
[12:57] <cjwatson> nothing else in my /var/lib/dpkg/info appears to make /var/run a symlink
[12:57] <cjwatson> can you check in /var/log/dpkg.log* for upgrades with the same timestamp as /var/run?
[12:57] <cjwatson> that should be enough to isolate it quite precisely
[13:03] <apw> cjwatson, according to my logs i did no updates between 2011-08-30 and this morning, and the link came into existance 2011-09-03 ...
[13:03] <apw> which seems confusing.  i will upgrade my other chroot and see if that hits the same issue
[13:04] <apw> if it does not then i will have to write it off as pilot error somehow
[13:04]  * apw does not he has installed casper in this chroot
[13:04] <apw> note
[13:05] <cjwatson> casper doesn't touch /var/run
[13:08]  * apw waits on the update, if it doesn't recur then we can assume its fixed i suspect
[13:15] <stgraber> pitti: what? I uploaded a new ltsp source yesterday and didn't get any build failure
[13:18] <stgraber> pitti: ouch, ok, looks like wrap-and-sort messed up debian/control with the last upload. Looking at it now
[13:19] <pitti> stgraber: thanks
[13:19] <stgraber> really weird, wrap-and-sort did what it's supposed to except that it also dropped ltsp-server-standalone...
[13:20] <doko> jamespage,  eucalyptus-commons-ext b-d's on gcj, not openjdk?
[13:21] <jamespage> doko: it pulls both for the build
[13:22] <jamespage> some of the libraries it builds won't compile under Java 6 so it used gcj for those
[13:22] <stgraber> pitti: uploaded
[13:23] <Sweetshark> doko: at https://bugzilla.mozilla.org/show_bug.cgi?id=686280#c9 comment 9 there is a minimal testcase if you need one ...
[13:24] <stgraber> pitti: argh, it's wrong. wrap-and-sort messed up more than I thought. please reject
[13:24] <pitti> stgraber: will do once it hits unapproved
[13:28] <pitti> stgraber: killed
[13:31] <Chipzz> hrrrrm
[13:31] <Chipzz> ubottu looks slightly broken?
[13:31] <Chipzz> " [Normal,New: ]"
[13:33] <Pici> Chipzz: I'll pass it on.
[13:37] <apw> cjwatson, ok other chroots are fine so i am going to write this off as an anomoly
[13:38] <cjwatson> ok
[13:38] <cjwatson> if it shows up again we can come back to it
[13:38] <apw> ack
[14:12] <barry> jelmer: ping
[14:13] <jelmer> barry: hi Barry, how are you?
[14:13] <barry> jelmer: doing good, how about yourself?
[14:14] <jelmer> barry: I'm well too. What's up?
[14:15] <barry> jelmer: debian bug 632225 - subvertpy
[14:15] <kees> wgrant: hi! when you get a chance, can you approve my membership to MOTU SWAT?
[14:15] <barry> jelmer: i am unable to even build the source package from sid on oneiric, and i was just looking for clues :)
[14:17] <jelmer> barry: this is on ia64 too?
[14:17] <barry> jelmer: amd64
[14:18] <jelmer> barry: oh, interesting, I haven't managed to reproduce it on amd64
[14:18] <jelmer> barry: is it the same test that's failing?
[14:19] <barry> jelmer: i don't even get that far: http://pastebin.ubuntu.com/693072/
[14:19] <wgrant> kees: :( but done.
[14:19] <barry> jelmer: yet this works just fine from a cli: python2.6 -c 'import apt_pkg'
[14:20] <jelmer> barry: what about python-dbg -c 'import apkt_pkg' ?
[14:20] <barry> jelmer: segfault
[14:21] <barry> jelmer: i guess that's a clue :)
[14:26] <jamespage> bdrung: whats the current status of eclipse 3.7?  anything I can help with?
[14:37] <apw> cjwatson, ok ... i have built my own iso with the updated initramfs-tools bits and i now get a zram0 mounted as swap if i restrict ram to 480M
[14:38] <kees> wgrant: thanks :)
[14:38] <cjwatson> apw: excellent.  I shall merge right now
[14:39] <apw> cjwatson, most appreciated
[14:40] <bdmurray_> pitti: what was that regarding 298217 and -proposed?
[14:41] <pitti> bdmurray: what about it? it needs review by ubuntu-sru and then testing
[14:42] <bdmurray> pitti: oh that was about the verification-needed tag question - got it
[14:57] <barry> jelmer: perhaps subvertpy is not multiarch aware?
[14:57] <jelmer> barry: I'm not sure why it wouldn't be, it seems to build fine in Debian too.
[15:01] <jelmer> barry: the bug in Debian is almost certainly due to a memory management bug.
[15:16] <slangasek> is anyone here running with the nouveau driver who could test plymouth for bug #849954, please?
[15:17] <broder> slangasek: give me a sec and i can switch my laptop over
[15:17] <slangasek> broder: hurrah, thanks
[15:18] <broder> slangasek: is there a ppa, or am i building off of that branch?
[15:18] <slangasek> broder: build off branch, or just hand-hack the one-line change to /etc/init/plymouth-stop.conf
[15:18] <slangasek> (pretty trivial change)
[15:19] <broder> ok. back in a moment
[15:21] <barry> jelmer: hmm, okay.  i say this because it complains about not finding the subversion dev files.  this is just during source package build
[15:23] <jelmer> barry: do you have the apr util and svn dev packages installed?
[15:25] <broder> slangasek: hmm..looks like nouveau doesn't actually work with my laptop's card, sorry
[15:27] <barry> jelmer: ah, thanks, i was missing libsvn-dev
[15:31] <mterry> debfx, I was working on building/testing the qtwebkit (amarok crash) patch, but if you want to take it, that's fine
[15:32] <mterry> debfx, (just let me know, so I stop working on it)
[15:33] <slangasek> broder: ah, blast.  well, thanks for checking
[15:37] <debfx> mterry: I'm planning to update qtwebkit to 2.2 RC1 which includes that fix
[15:37] <mterry> debfx, OK, then I'll stop.  I don't think amarok needs to be patched at all then, if I read the bug reports right
[15:38] <debfx> hope you haven't spent too much time on it :/
[15:39] <mterry> debfx, not a lot, no  :)  thanks for updating qtwebkit
[15:48] <bdmurray> pitti: how is it that bug 849073 matches the pattern for bug 832745 and still was reported?
[15:50] <pitti> bdmurray: hm, when was the pattern added?
[15:51] <bdmurray> pitti: timestamp: Fri 2011-09-09 09:39:12 -0300 according to bzr log
[15:51] <pitti> hm, last dupe is from 09-13, no newer ones since then
[15:51] <pitti> but that coincides with the fix, not with the pattern
[15:54] <bdmurray> pitti: I don't see 832745 at http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml
[15:54] <bdmurray> oh there it is
[15:54] <pitti> ./test-local 850748 looks quite fine from here..
[16:01] <bdmurray> pitti: should donwloading the crash report using apport and then ubuntu-bug crash_file work?
[16:02] <pitti> bdmurray: in theory yes
[16:03] <bdmurray> pitti: hmm, it doesn't in this case at least
[16:05] <bdmurray> pitti: it does with one of the duplicates though
[16:19] <jmux> Hi. Can anyone with a (fresh) Natty system check, if /var/run and /var/lock are tmpfs mounts?
[16:19] <pitti> jmux: they ought to be, anyway
[16:20] <jmux> I upgraded from Natty to Oneiric and it seems the directory migration /var/lock => /run/lock and /var/run => /run is broken. base-files.postinst does an "rmdir /var/run; ln -s /run /var/run" but AFAIK both are tmpfs mounts, so this will fail.
[16:21] <jmux> This broke my boot in various ways, as some services write their data to /run but look for their data in /var/run, which won't be a symlink. Same for /lock.
[16:22] <bdmurray> pitti: I think it is because OriginalTitle is only in downloaded apport crashes so if a pattern is matching on OriginalTitle it will always fail
[16:23] <pitti> bdmurray: aah
[16:23] <pitti> yes, that's plausible
[16:23] <jmux>  /lock should be /run/lock
[16:25] <bdmurray> pitti: so perhaps apport's _check_bug_pattern should also check OriginalTitle?
[16:25] <pitti> jmux: not in natty
[16:25] <pitti> jmux: that was done in oneiric
[16:29] <jmux> pitti: I know. I'm just not sure if a fresh Natty system has /var/run on tmpfs, since my system has gone a much longer upgrade path.
[16:31] <jmux> And several system deamons (dbus, rpcbind) failed to start, because /var/run was still a directory after upgrade.
[16:31] <pitti> james_w: you just approved https://code.launchpad.net/~mabac/launchpad-work-items-tracker/change-queries-through-storm/+merge/74725, are you merging as well?
[16:32] <james_w> pitti, oh, sorry I missed which branch it was proposed for
[16:32] <james_w> pitti, I can do it if you are happy with it
[16:32] <pitti> james_w: well, I don't really understand it :) but if it was tested, fine for me
[16:32] <doko> barry, could you have a look at bug 755971
[16:33] <SpamapS> Daviey: ack, will take another look at that MP
[16:33] <james_w> pitti, that code is running on linaro's instance now
[16:33] <bdmurray> pitti: can you change the pattern for bug 851169 on ubuntu-archive to match on originaltitle as I can recreate that crash and can test this theory
[16:33] <pitti> james_w: so, go ahead; bzr doesn't easily forget, so if things break, we can alwasy revert
[16:33] <james_w> pitti, indeed, thanks I will do it shortly
[16:34] <pitti> bdmurray: you mean locally in the bzr checkout?
[16:34] <bdmurray> pitti: right locally on people.canonical.com
[16:35] <pitti> bdmurray: changed
[16:35] <bdmurray> pitti: okay thanks so now my crash doesn't match the pattern
[16:36] <pitti> bdmurray: ok, reverted
[16:36] <pitti> bdmurray: so in bzr we should do an s/OriginalTitle/Title/ then?
[16:36] <bdmurray> pitti: yes but that's not a good long term solution I think
[16:37] <pitti> bdmurray: hm, we could change launchpad.py to grab the "Title:" field from the metadata as OriginalTitle
[16:37] <pitti> bdmurray: the code actually already tries to do that
[16:38] <pitti> bdmurray: apport/crashdb_impl/launchpad.py line 294
[16:38] <bdmurray> pitti: that's only in download though which isn't used when building a bug report right?
[16:39] <pitti> bdmurray: ah, right, I got confused
[16:39] <pitti> bdmurray: I think for the patterns it really needs to be Title:
[16:39] <pitti> bdmurray: as at the point when you click "report" you can't actually set/change the title
[16:43] <slangasek> seb128: regarding bug #851481, I certainly know what the right fix is (ignore all plugins of a different architecture), but I know nothing about where the plugin search code is implemented... do you know where I should start looking?
[16:44] <bdmurray> pitti: right that makes sense my concern is using test-local and having it not match in some cases, but I'd rather the pattern matching work than test-local fail in some cases
[16:44] <seb128> slangasek, gstreamer calls gnome-codec-install so I wonder if the bug is not there
[16:44] <seb128> mvo might know better
[16:44] <seb128> mvo, ^
[16:44] <slangasek> right, it probably is
[16:46] <pitti> bdmurray: *nod*
[16:46] <seb128> slangasek, the gst code is in gst-plugins-base0.10 gst-libs/gst/pbutils/install-plugins.c
[16:46] <seb128> slangasek, I don't know about gnome-codec-install much but mvo does and I think the code is small enough
[16:47] <slangasek> seb128: the 'gnome-codec-install' keyword is probably what I needed to dig deeper on it :)
[16:47] <slangasek> mvo: ^^ though if you have time to look at this, I'm sure you'll get it fixed far more efficiently than I
[16:48] <seb128> ;-)
[16:48] <bdmurray> pitti: are you planning on fixing the OriginalTitles in bugpatterns or shall I?
[16:48] <pitti> bdmurray: if you have some time, please go ahead; I'm in "crunch mode" right now, I'm afraid
[16:49] <bdmurray> pitti: I'll get it done
[16:49] <pitti> bdmurray: thanks!
[16:49] <pitti> that might explain a few extra bug floods indeed
[17:12] <mvo> slangasek: I'm about to leave to play some hockey, but I can check #851481 in +12h
[17:13] <slangasek> mvo: sounds fine, thanks.  I'll assign the bug to you so we don't forget
[17:14] <mvo> ;) no way out for me then anymore now
[17:14] <mvo> *kidding*
[17:26] <GrueMaster> Can someone update ltp (Linux Test Project) in Universe?  The last rev hasn't been updated since 2009, and I'm sure there has been a few updates since then.
[17:26] <slangasek> apw: getting the x-server started as soon as possible> I understand that much, but it still looks like this is being checked redundantly in two different jobs
[17:26] <slangasek> apw: as in A starts on B or C, and B starts on C or D
[17:27] <cjwatson> GrueMaster: would be easiest if somebody got a newer version into Debian first
[17:27] <cjwatson> then it could just be a sync assuming that dtchen's recent upload was a backport
[17:27] <GrueMaster> Well, since I am not a dev, I wouldn't know who or where to ping.  Thought I would try here first.
[17:28] <cjwatson> a Debian bug report's the usual way ...
[17:28] <apw> slangasek, but that ignores the udevtrigger rule on fallbackgraphics
[17:28] <cjwatson> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ltp hmm, looks like it could use some help
[17:28] <slangasek> apw: sorry, I don't follow?
[17:29] <apw> slangasek, if we have usable graphics then we start gdm as we are ready to go
[17:29] <slangasek> apw: yes, I understand that
[17:29] <apw> slangasek, if we don't then we must wait for the vesafb to be probed and then start gdm
[17:30] <slangasek> but why are we checking for graphics-device-added or drm-device-added in *both* udev-fallback-graphics.conf, *and* gdm.conf?
[17:30] <apw> so that gdm.conf can get on and start right now as soon as usable graphics appear
[17:30] <apw> it doesn't have to wait for upstart to start fallback, which will do nothing and then start
[17:31] <slangasek> yes, so *why are we checking for these events in udev-fallback-graphics at all*?
[17:31] <apw> slangasek, i believe that is to make the job go away
[17:32] <apw> slangasek, else it will always start when udevtrigger fires, and we cannot tell if we have graphics
[17:32] <slangasek> ok, so we use the OR there to detect whether the modprobe vesafb is needed
[17:32] <apw> essentially yes
[17:33] <slangasek> and having the OR in the gdm job makes a genuine difference in boot speed, vs. waiting for udev-fallback-graphics to finish?
[17:33] <apw> slangasek, that i do not know to be fair, iirc that was more about how it was already formed
[17:33] <slangasek> ok
[17:33] <apw> it was about the smallest number of changes as it was already mind-bendingly complex
[17:34] <slangasek> hrm, the drm-device-added check is also different in lightdm/gdm vs. udev-fallback-graphics
[17:34] <slangasek> drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 vs drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
[17:34] <apw> yeah i just saw that, i don't think they were different originally
[17:34] <SpamapS> slangasek: re bug 848823 .. your assumptions about what rc-sysinit used to have are unfortunately off a bit.
[17:35] <SpamapS> slangasek: pre 11.10, it was 'start on filesystem and net-device-up IFACE=lo'
[17:35] <slangasek> SpamapS: oh
[17:35] <slangasek> SpamapS: ok, so it's not a regression... still a bug though, yes? :)
[17:35] <apw> slangasek, there might be milage in checking that there is any time benefit and if not, then we should scrap the dups
[17:35] <SpamapS> I think we may have changed a race
[17:35] <SpamapS> slangasek: My guess is that by slowing down runlevel 2 we've exposed some other race.
[17:35] <slangasek> SpamapS: I mean, catching the networking before starting runlevel 2 is why you guys made these changes
[17:36] <slangasek> apw: ok.  probably a P matter at this point; I'll document this in a bug report - thanks
[17:36] <apw> slangasek, well i suspect those being differenet is a bug in O and needs review
[17:37] <SpamapS> slangasek: the issue is very troubling
[17:37] <slangasek> SpamapS: howso?
[17:37] <slangasek> apw: yeah, am looking into the difference now
[17:37] <SpamapS> slangasek: that the user would have to restart the kernel server once per day .. seems a bit odd!
[17:37] <SpamapS> oh wait
[17:37] <slangasek> SpamapS: well, he clarified that it's only after reboot - he seems to just reboot frequently :)
[17:37] <SpamapS> ok reading through the comments
[17:38] <blackz> hi people
[17:39] <slangasek> blackz: hello
[17:49] <slangasek> stgraber: I'm looking at the history of the gdm upstart job, and on 2011-05-02 you merged a new version from jhunt that readds the 'or graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1' that had been deliberately removed by pitti in response to bug #615549... but there's no other explanation for this change except that it fixes single user mode (bug #436936).  Do you know of a good reason for readding this line, or is this a mismerge?
[17:51] <stgraber> slangasek: Ouch, that was a while ago. I honestly don't remember the details except that it's very likely the single user mode fix isn't needed anymore with the changes to friendly-recovery
[17:52] <slangasek> stgraber: no, single user mode still exists conceptually and still needs to be handled anyway... :)  But this particular line looks to me like a mismerge, so I'll aim to fix it
[17:53] <slangasek> apw: the 'card0' delta exists from the first occurrence of this check on both the gdm and udev-fallback-graphics jobs
[17:55] <apw> slangasek, i wish i could remember the details.  the conditions gdm i only switch from udevsettle to udev-fallback-graphics, the conditions for udev-fallback-graphics came from something it was enhancing
[17:56] <apw> slangasek, but ... it does seem appropriate that if gdm doesn't think it can use !card0, then its not clear that udev-fallback should not also feel the same about things
[17:57] <apw> slangasek, i assume card0 is there so we only load one gdm regardless of how many screens and cards we have
[17:57] <slangasek> we would only load one gdm anyway
[17:57] <slangasek> I'm not sure under what circumstances card0 would or wouldn't be included
[17:57] <apw> well vesafb is really fallback for 'the one gdm will use' in my mind, so i suspect it needs card0 too
[17:58] <slangasek> I'm not convinced, actually
[17:58] <slangasek> surely if *any* drm-device-added is emitted, we know we don't need to modprobe vesafb?
[17:58] <apw> it is a shame thinking about upstart rules is akin to putting ones sanity in a cross-cut shreader
[17:59] <slangasek> hey, these are udev semantics, not upstart rules :)
[17:59] <slangasek> or at least, the udev upstart bridge
[17:59] <apw> slangasek, that is reasonable _if_ gdm will then use card1, cause it starts cause fallback finishes
[18:00] <slangasek> apw: but what's the definition of "card0" vs. "card1"?  How can you have a card1 without a card0?
[18:00] <apw> but it is odd to me that it will use card0 staight away, but not use card1 until we finish
[18:00] <apw> but then, we'll finish pretty quick once card1 emits, so its probabally starting on fallback finish anyhow
[18:00] <slangasek> oh, because they may start in parallel and we don't want to accidentally start on the wrong card due to a race
[18:01] <slangasek> in that case, I think udev-fallback-graphics should be checking for card0
[18:01] <ejat> bug 854008
[18:01] <slangasek> so that if card1 initializes before card0 for any reason, gdm doesn't accidentally start on the wrong card or with the wrong driver
[18:01] <apw> slangasek, though then we will load vesafb if we don't ahve a 0
[18:02] <slangasek> apw: how do you not have a 0, though?
[18:02] <apw> slangasek, as long as that very reasonable assumption is true, then yes i think card0 on both should work
[18:02] <SpamapS> slangasek: you are pre-Moor occupation and just can't fathom algebra?
[18:03] <apw> if its not true, then i think we are breaking the race order protection anyhow, and thats potentially serious too
[18:03]  * SpamapS made a bad math/history joke. ;)
[18:03] <slangasek> SpamapS: a cursory examination of my mudejar architecture will conclusively establish me as post-Moor
[18:03] <SpamapS> slangasek: hmm, then I guess you can't not have a 0. :)
[18:03] <slangasek> ;)
[18:03] <apw> slangasek, i am more inclined to say drop us to dependancy on fallback-graphics, and move card0 there too, and lets see who hollars
[18:04] <apw> it should be easy to check its still right for the common cases
[18:05] <slangasek> apw: well, further digging shows that gdm should probably *not* start immediately on graphics-device-added because we may get a subsequent drm-device-added for the same video device... so I'm going to dig further
[18:05] <slangasek> in my nearly-palindromic fashion
[18:06] <apw> slangasek, ok .. yeah there is a another difference there, and we risk starting gdm early via -fallback- too
[18:06] <slangasek> yep
[18:06] <slangasek> hence the need for further digging
[18:07] <slangasek> we may need to annotate the udev-fallback-graphics job somehow so we know whether we've loaded vesafb
[18:07] <apw> slangasek, i am unsure you can represent that difference with a mear dependancy; i suspect it needs to emit something specific when it does not probe or something
[18:07] <bdmurray> Could I get somebody to sponsor http://people.canonical.com/~brian/tmp/kerneloops_0.12+git20090217-1ubuntu15.debdiff
[18:07] <slangasek> apw: we'll see what I can figure out :)
[18:08] <apw> slangasek, i still have this lightdm white flash ... did you say your was gone ?
[18:09] <slangasek> apw: I never saw a white flash, just a black one - but that's all the responsibility of lightdm
[18:09] <slangasek> so long as you're not getting text mode, that is
[18:09] <slangasek> apw: do you have unity-greeter installed?
[18:10] <apw> slangasek, nope, just as lightdm initiliases ... i believe i have the new greeter yes, the slidey boxy off to the lefty one
[18:10] <slangasek> right, that's the one
[18:12] <htorque> apw: that's a greeter problem, if you switch to lightdm's gtk greeter, there's no such white flash.
[18:12] <apw> htorque, ok that sounds good, is that easy to check so i can confirm
[18:13] <apw> s/check/change
[18:14] <htorque> apw: make sure you have 'lightdm-gtk-greeter' installed and change to it in the /etc/lightdm/lightdm.conf file (probably need to create one)
[18:15] <htorque> apw: that's mine http://paste.ubuntu.com/693228/
[18:15] <stgraber> apw: /usr/lib/lightdm/lightdm-set-defaults -g lightdm-gtk-greeter
[18:16] <htorque> or that :)
[18:16] <htorque> stgraber: thanks ;-)
[18:18] <apw> ok i think that shows no flash, though there are other flashing things to confuse the mind... good, thanks
[19:21]  * bdmurray is still looking for a sponsor for kerneloops
[19:25] <slangasek> apw: I'm still getting the cursor between grub and kernel after upgrading to the latest grub-pc, and I've even run dpkg-reconfigure grub-pc to ensure that grub-install gets run (and isn't being bypassed).  Any idea how I should debug this further?
[19:41] <chrisccoulson> slangasek, what am i looking for when i boot with plymouth:debug?
[19:42] <slangasek> chrisccoulson: /var/log/plymouth-debug.log
[19:42] <chrisccoulson> slangasek, oh, not sure why i didn't see that the first time around ;)
[19:46] <cjwatson> slangasek: it would be update-grub not grub-install that matters, anyway
[19:47] <slangasek> cjwatson: oh, it is?  I thought this was about license checking of the binary modules?
[19:48] <cjwatson> slangasek: oh, errrrr
[19:48] <cjwatson> ignore me
[19:48] <cjwatson> brains
[19:48] <slangasek> :)
[19:49] <cjwatson> 16:12 <cjwatson> from the command line, try:
[19:49] <cjwatson> 16:12 <cjwatson> hwmatch ${prefix}/gfxblacklist.txt 3
[19:49] <cjwatson> 16:12 <cjwatson> echo $?
[19:49] <cjwatson> 16:12 <cjwatson> echo $match
[19:50] <slangasek> and I should do that from a reboot, right, I guess emulating that from a running system does no good?
[19:51] <cjwatson> yeah, need that from the actual grub prompt not grub-emu or whatever
[19:51] <cjwatson> (no idea whether it'd even work from grub-emu)
[20:06] <seb128> slangasek, update-notifier should use libappindicator
[20:06] <seb128> slangasek, neither the whitelist or the behaviour change seem a good reply to the issue you raised
[20:07] <slangasek> seb128: critical bits of how we notify users of security updates should not regress in the absence of libappindicator support
[20:07] <seb128> slangasek, there is no absence of libappindicator support
[20:07] <slangasek> in update-notifier?
[20:07] <seb128> slangasek, libappindicator fallback to a gtkstatusicon when there is no indicator loader
[20:08] <seb128> slangasek, if update-notifier was using libappindicator it would work under unity and display an indicator and work out of unity and fallback to a gtkstatusicon
[20:08] <slangasek> yes, and no one's patched update-notifier to use libappindicator - it's not ok for that to be silently broken becuase update-notifier "should" be updated to use libappindicator
[20:09] <seb128> slangasek, well, argue with sabdfl and dx, half of the status icon users in the archive are in this case, it was a design decision that forced on us with unity
[20:10] <seb128> they refused to use the whitelist to justify not porting code to the new apis
[20:10] <slangasek> seb128: do you mean to say that unity no longer supports whitelisting?
[20:11] <seb128> slangasek, not that I disagree with you but we fought that battle previous cycle and lost it
[20:11] <seb128> slangasek, no, I say that whitelist has been made as way to support things we can't patch, i.e jave, skype, etc
[20:11] <slangasek> if the whitelist is there, it's important that update-notifier be in it.  It's a no-op for the default case, but critical to security support for those who have opted in to the panel icon
[20:11] <seb128> slangasek, sabdfl and dx refused to use it as a mean to not port code we can patch
[20:11] <slangasek> seb128: where is the whitelist?
[20:12] <seb128> slangasek, dconf
[20:12] <seb128> it's trivial to add something to it technical
[20:13] <slangasek> seb128: well, I don't know any of the technical details of adding it to the whitelist; which package would need to do what in order to have update-notifier in the whitelist?
[20:13] <seb128> unity
[20:13] <slangasek> once I can figure out what needs to be patched, I'll argue with whoever I need to :)
[20:14]  * pitti wishes slangasek good luck, he's been through that several times, too
[20:14] <pitti> perhaps more voices will have some more effect
[20:42] <achiang> would a moderator please review the queue on ubuntu-devel@ please? i responded to the "Getting new packages into Ubuntu" and would like my mail delivered before the conversation goes stale
[20:43] <Q-FUNK> about Bug #852887, I'm wondering how may more like this will come and bite us.
[20:45] <YokoZar> pitti: Do I need a new bug for https://bugs.launchpad.net/ubuntu/+source/wine1.0-gecko/+bug/814975  ?
[20:46] <cjwatson> achiang: done
[20:47] <achiang> cjwatson: thank you
[20:47] <slangasek> Q-FUNK: have you manually enabled insserv on your system for some reason?
[20:48] <slangasek> Q-FUNK: because by default we have /etc/init.d/.legacy-bootordering set, which should disable all insserv handling here
[20:50] <Q-FUNK> slangasek: it might have remained enabled over a few years of upgrades
[20:52] <Q-FUNK> slangasek: of course, it leaves me pondering why ubuntu's APT override hasn't simply demoted the package to e.g. optional or extra
[20:54] <slangasek> Q-FUNK: the /etc/init.d/.legacy-bootordering file is created with a hammer by upstart; I've not heard of anyone hitting this issue due to an upgrade
[20:54] <slangasek> Q-FUNK: as for insserv not being demoted to optional or extra, it's simpler to use the flag file in /etc/init.d to limit divergence from Debian
[20:54] <Q-FUNK> slangasek: mind you, recent insserv releases have been pretty good at skipping packages that don't have the LSB header at all. it's literally been ages since I bumped into such an issue.
[20:55] <Q-FUNK> slangasek: I haven't gone to extremes to enable insserv, so I'd asumed it simply remained on from pre-upstart days.
[20:56] <slangasek> in fact, insserv (or rather, startpar) is known to fail in horrible ways with upstart
[20:56] <slangasek> (I'm working on fixing this actually, to make upstart usable in Debian, but it's definitely broken today in Ubuntu)
[20:57] <Q-FUNK> ah, that could be interesting.
[21:06] <Q-FUNK> slangasek: I really don't have any /etc/init.d/.legacy-bootordering  here.
[21:43] <Laney> why is a QA bot spamming me?
[21:45] <ajmitch> in bug mail?
[21:47]  * micahg blames bdmurray 
[22:16]  * slangasek muses out loud that the dots-over-text plymouth error on shutdown could be caused by both gdm and lightdm being installed in the upgrade case, such that plymouth starts on 'stopped gdm and runlevel 6' because the gdm job starts and then stops before lightdm is done
[22:24] <YokoZar> Were we actually trying to fix the shutdown screen this cycle?
[22:24]  * YokoZar remembers discussing it last UDS
[22:27] <broder> slangasek: no, that's not why it happens, because it happens on natty
[22:27] <slangasek> broder: it didn't happen to me on natty
[22:27] <slangasek> maybe there are multiple causes
[22:27] <broder> slangasek: i see it all the time on natty. i assume it boils down to "omg shutdown is only semi-upstartified and therefore super racy"
[22:27] <slangasek> YokoZar: we are generally trying to fix bugs
[22:27] <slangasek> broder: that part of the shutdown is not semi-upstartified
[22:28] <broder> hmm...i guess it should theoretically be sufficiently upstartified
[22:28] <broder> there's definitely a race with casper, though
[22:28] <slangasek> broder: this is /etc/init/plymouth.conf, start on ... or (runlevel [016] and stopped $fwibble)
[22:28] <YokoZar> slangasek: what I mean is last UDS we mentioned it was broken in Natty (and possibly Maverick as well) and that no one had really paid attention to it since Lucid
[22:29] <slangasek> YokoZar: well, a) it wasn't broken for me in either maverick or natty, b) I don't know where it was mentioned but it wasn't mentioned to me.  I only fix the bugs I know about :)
[22:30] <slangasek> broder: by "casper", do you mean "ubiquity/oem-config", which I notice are listed in plymouth-stop.conf but not plymouth.conf?
[22:30] <YokoZar> slangasek: Well, glad you're thinking about it, it has been an annoying bit of anti-polish lately :D
[22:30] <broder> slangasek: no, i mean /etc/init.d/casper and its "please remove the installation media now" propmt
[22:31] <slangasek> broder: oh, that, yes.  that's certainly distinct from the problem of plymouth rendering its progress bar on top of a text console
[22:32] <broder> slangasek: i know; i've seen the dots-on-text issue as well since at least natty on some machines, possibly earlier
[22:32] <slangasek> mmk
[22:32] <broder> though now that you mention it, i do seem to see it consistently on the one machine i've upgraded to oneiric. i'll try removing gdm and see if it goes away
[22:32] <bdrung> tumbleweed: can i release u-d-t in to days to sid?
[22:32] <slangasek> broder: :)
[22:33] <tumbleweed> bdrung: go for it
[22:34] <bdrung> tumbleweed: sponsor-patch should handle sync requests correctly now
[22:34] <broder> slangasek: no dice. i do get a flash of the full splash screen before i just get dots-on-text, though
[22:35] <broder> (no idea whether i got that before or not)
[22:35] <slangasek> hmm
[22:35] <slangasek> broder: I suggest throwing an 'echo $UPSTART_EVENTS >> /path/to/writable/log' into the job and see what it says when you get this
[22:35] <broder> i'll try just cranking the upstart log level
[22:36] <slangasek> I guess that might work :)
[22:40] <broder> slangasek: ...d'oh. i removed gdm, i didn't purge it
[22:40] <broder> i bet that doesn't work :)
[22:41] <ion> Every now and then i hit _ on the “uninstalled packages” line in aptitude. :-)
[22:42] <broder> slangasek: we have a winner!
[22:42] <slangasek> cool
[22:43] <slangasek> now we just have to fix the darn thing
[22:43] <broder> slangasek: yeah, i think that may prove to be harder
[22:43] <slangasek> which means adding new initctls to all the affected dms
[22:49] <Nafai> kirkland: Hey.  So, about dotdee.  I'm thinking about some things that I need for handling my local dotfiles and other files in ~ that are shared across machines.  I'm thinking that dotdee would solve some of the problems I am seeing.
[22:50] <Nafai> kirkland: but, particularly with the use of alternatives, it is currently aimed at system-wide stuff
[22:50] <kirkland> Nafai: interesting, okay
[22:50] <kirkland> Nafai: right, I can see that
[22:50] <Nafai> kirkland: curious as to what kind of changes you might suggest (I'm willing to write them, the dotdee code is very clean and I <3 shell scripts) to better support the user dir case?
[22:50] <kirkland> Nafai: i suppose it would be easy to add a user-mode (in addition to admin mode)
[22:51] <kirkland> Nafai: thanks for the code compliment :-)
[22:52] <kirkland> Nafai: um, okay, so I think it should be pretty easy to tell if you're running in user mode, vs. admin mode -- (are you a) non-root, and b) operating on a file that you own)
[22:52]  * Nafai nods
[22:52] <kirkland> Nafai: that would probably be the first patch/commit
[22:52] <kirkland> Nafai: let me take a look at the update-alternatives bit ...
[22:52] <Nafai> k
[22:53] <kirkland> Nafai: hmm, the inotify stuff is going to be tricky as non-root
[22:54] <kirkland> Nafai: you'd need to start/run an inotify daemon as your non-root user
[22:54] <kirkland> Nafai: currently, there's an upstart job that runs that at startup
[22:54] <kirkland> Nafai: for the root case
[22:55] <Nafai> ah
[22:55] <Nafai> I hadn't looked at inotify enough to know that it needed a separate instance
[22:56] <kirkland> Nafai: okay, so, the update-alternatives stuff would be easy to simulate for non-root users
[22:57] <kirkland> Nafai: we would just create a couple of small functions in that shell script that either do update-alternatives (for real) if in admin mode, or if not, just shuffle symlinks somewhere in $HOME/.somewhere_xdg_compliant
[22:57] <kirkland> Nafai: inotify is the harder part
[22:57]  * Nafai nods
[22:57] <kirkland> Nafai: inotify is a daemon that watches for filesystem events
[22:57] <kirkland> Nafai: that match some configuration
[22:58] <kirkland> Nafai: when you set something up in dotdee, it addes an inotify watch to the path you've dotdee'd
[22:59] <kirkland> Nafai: iwatch is the actual daemon
[22:59] <kirkland> Nafai: see /etc/init/dotdee
[22:59] <kirkland> Nafai: see /etc/init/dotdee.conf
[22:59] <kirkland> Nafai: exec iwatch -f /etc/dotdee.xml -p /var/run/dotdee.pid
[22:59] <kirkland> Nafai: so each user wanting to dotdee stuff in their home dir would need to have a similar iwatch daemon running
[23:00] <kirkland> Nafai: but with their own dotdee.xml and pid
[23:00] <kirkland> Nafai: all quite doable
[23:00]  * Nafai nods
[23:00] <kirkland> Nafai: and then that user would need some way to start the daemon at boot (perhaps through an @reboot cronjob?)
[23:00] <Nafai> sounds reasonable
[23:00] <kirkland> Nafai: all of that is reasonable, i think
[23:01] <kirkland> Nafai: if enough users come to me asking me to do this sort of thing, i could hack this out in a day or so
[23:01] <kirkland> Nafai: if you want to branch it and work on it, that's cool too
[23:01] <Nafai> I think I might, and send you branches to review
[23:01] <kirkland> Nafai: if the changes are good, i think it's a reasonable feature to add
[23:01] <kirkland> Nafai: fair enough
[23:01] <kirkland> Nafai: advice:
[23:02] <Nafai> cd ..
[23:02] <kirkland> Nafai: detect that user/admin mode
[23:02] <Nafai> whoops, wrong window :)
[23:02] <kirkland> Nafai: wrap the current update-alternatives calls in a local function, that either does update-alternatives, or does our update-alternatives like things
[23:03] <kirkland> Nafai: look at the xdg user dirs a bit, as some people get their panties in a wad about stuff like $HOME/.dotdee
[23:03] <kirkland> Nafai: they want it in $HOME/.cache or $HOME/.config or some other less discoverable location
[23:03] <Nafai> k, I'm used to using those, so not a problem
[23:03] <kirkland> Nafai: cool
[23:04] <kirkland> Nafai: happy to have you hacking on dotdee ;-)
[23:04] <Nafai> thanks, it just happens to fit a niche of a problem I am trying to solve
[23:05] <Nafai> for example, just right now I'm working with Arch in a vm. Python3 is the default, and I was installing some scripts in ~/bin I have in every box that just use /usr/bin/python.  I need to change those to python2, but only here on arch
[23:17] <SpamapS> kirkland: note that upstart has some basic "user session" support
[23:18] <kirkland> SpamapS: wow, rally?
[23:18] <kirkland> really, even?
[23:18] <SpamapS> kirkland: yeah, let me dig up the info on it..
[23:20] <SpamapS> kirkland: you can have a $HOME/.init/ but I forget how to make upstart read it.
[23:21] <SpamapS> kirkland: may want to hit up jhunt about it. IIRC there are some big caveats
[23:24] <slangasek> cjwatson: so from grub shell, I get $? == 0 and $match == 0; is that the expected result?
[23:25] <slangasek> (the hwmatch command itself succeeds with no output, of course)
[23:25] <cjwatson> slangasek: that should amount to 'set gfxpayload=keep', so yes that's expected
[23:25] <cjwatson> which I think means it may be apw's problem not mine
[23:25] <slangasek> heh
[23:25] <slangasek> ok :)