[00:04] <ion> keybuk: Huh. mountall seems to say that / is mounted and that FHS is mounted and let rc-sysinit begin, even though / is still mounted readonly. Then mountall seems to receive an udev event about the / partition appearing, and proceed to fsck / while rc is trying to get the system started (with everything screaming about not being able to write to /).
[00:05] <Keybuk> that's odd
[00:05] <Keybuk> I don't think it does that here
[00:06] <ion> keybuk: If fsck makes changes to the / partition, i manage to login via getty and then the system reboots suddenly.
[00:06] <Keybuk> I'll investigate
[00:06] <Keybuk> do you have the debug log?
[00:08] <ion> I wonder what's the best way to get one? mount a tmpfs at /mnt before mountall in mountall.conf and redirect the output to a file in there?
[00:10] <Keybuk> oh
[00:10] <Keybuk> I see
[00:10] <Keybuk> it triggers FHS too early
[00:10] <Keybuk> and it looks like it doesn't clear the needs remount flag either
[00:10] <Keybuk> will fix tomorrow
[00:11] <Keybuk> oh
[00:11] <Keybuk> I've fixed this already
[00:11] <Keybuk> I just hadn't applied the patch
[00:12] <ion> :-)
[00:36] <NCommander> pitti, you around?
[00:37] <TheMuso> NCommander: Likely in bed.
[01:32] <arand> I'm using quilt to add a patch to a package (for SRU), but I notice that an older patch has a one-line offset when applying it, should it be refreshed or should I just leave it alone?
[01:34] <slangasek> arand: for SRU, I don't think it's worth bothering with
[01:34] <arand> slangasek: aknowledged.
[01:46] <ArneGoetje> YokoZar: no need to worry
[01:50] <johanbr> dtchen, that "15 sec latency" bug I was talking about... https://bugzilla.redhat.com/show_bug.cgi?id=521276
[01:50] <johanbr> it's fixed by a gstreamer patch in git: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=058776bcf1ab218b509d19685a0b528d71c65f98
[01:51] <dtchen> johanbr: yep, i saw it earlier, but i'm not in a position to do much about it presently
[01:51] <johanbr> alright
[01:51] <johanbr> patching and rebuilding the current karmic package makes everything work as expected
[01:52] <johanbr> would an lp bug be useful?
[01:52] <dtchen> johanbr: absolutely
[01:52] <johanbr> alright, just a few minutes
[02:02] <ion> keybuk: Still around?
[04:01] <jumpingjack> hello! anybody here? i need some advices :)
[04:01] <hyperair> !ask | jumpingjack
[04:07] <jumpingjack> Is there way in ubuntu to get the text under mouse cursor everywhere on the desktop? What language or framework i should use? I'm new in linux, so i need a help with starting..
[04:08] <jumpingjack> i don't need a solution, i need a way to start from
[06:44] <pitti> Good morning
[06:45] <pitti> Keybuk: well, I left my comment in the bug; that was a bit too trigger-happy IMHO
[06:45] <pitti> NCommander: hi
[06:46] <NCommander> pitti, I got a question on calibre, you moved a bug onto python-qt4 which is RC, but pyqt doesn't promise a stable ABI,so calibre needs a binNMU to get going again
[06:46] <NCommander> (I think, I have yet to test that theory)
[06:47] <pitti> NCommander: but a followup upload was said to not fix it..
[06:47] <pitti> well, I could never reproduce it myself anyway
[06:49] <NCommander> pitti, I want to move the bug back to calibre, its currently blocking pyqt4 into testing (which in turn has KDE blocked). It doesn't seem toi be a pyqt4 issue specifically
[06:49] <NCommander> (kdebindings is chugging along just fine)
[06:50] <pitti> well *shrug* sure
[06:58] <dholbach> good morning
[07:04] <didrocks> morning o/
[07:04] <dholbach> heya didrocks, hi amitk
[07:05] <didrocks> hey dholbach :)
[07:10] <amitk> morning dholbach
[08:52] <apachelogger> asac: so... firefox installer is in main and on the latest cd images, time to resolve the remaining issues ;) ... I didn't find a firefox icon in the app-install data (+ I think Kubuntu doesn't have the data installed currently), so I suppse the only options we have is getting TB approval or detach the icon from the branding package (i.e. create a seperate package for the icon)
[08:55] <apachelogger> shtylman is going to come up with a kubuntu-installer-style packag ethat can be shared among ubiquity and k-f-i, so we can free additional CD space :)
[09:04] <dholbach> pitti, seb128: what do you think about bug 407817?
[09:04] <dholbach> bdrung_ worked hard on it
[09:06] <dholbach> sorry, fell out of the internet
[09:06] <dholbach> pitti, seb128: what do you think about bug 407817?
[09:06] <dholbach> bdrung_ worked hard on it
[09:08] <seb128> dholbach, I don't like alternative much and I don't think a distro specific hack is the way to go there
[09:09] <seb128> dholbach, I think the logo icon to use should rather be a gconf key
[09:10] <dholbach> bdrung_: ^ what do you think?
[09:10] <bdrung_> seb128: what do you mean with "distro specific hack"?
[09:11] <seb128> what are you trying to do? allow customization of the gnome-panel menu icon?
[09:11] <bdrung_> gconf would be a solution, too.
[09:11] <seb128> gconf would work on any distro
[09:11] <bdrung_> seb128: yes
[09:11] <seb128> and not rely on alternatives which is a debian,ubuntu thing
[09:12] <seb128> it would also allow users to change the icon
[09:12] <seb128> rather than having a system setting you can't change
[09:12] <bdrung_> that's a good point
[09:15] <bdrung_> when we have a gconf key for that, you can drop my changes
[09:21] <mr_pouit> seb128: Bug #253416 << maybe gnome-panel checks before displaying the issue, but it still installs a desktop file
[09:21] <mr_pouit> so another menu system will display it…
[09:22] <seb128> I'm too busy today to start a discussion about that
[09:22] <mr_pouit> of course (!)
[09:22] <mr_pouit> I don't think adding something like NotShowIn=XFCE; (or similar) needs a big discussion
[09:23] <mr_pouit> (instead of reaffecting the bug to something else)
[09:24] <seb128> the entry has nothing to do there in fact I think
[09:24] <seb128> it should rather be moved in the documentation
[09:24] <seb128> and gnome-panel should be patched to display it if available
[09:27] <ogra> kirkland, using -s in the debhelper invokations might help
[09:36] <kirkland> ogra: i'll try that
[09:36] <kirkland> ogra: which ones?
[09:52] <ogra> kirkland, all under the binary-static target i think+
[09:52] <ogra> s/+//
[09:56] <kirkland> ogra: hmm, that didn't work
[09:56] <kirkland> dpkg-gencontrol: error: current host architecture 'amd64' does not appear in package's architecture list (i386)
[09:56] <kirkland> +
[09:56] <ogra> kirkland, well, just add amd64 to Architecture then
[09:56] <ogra> though -s should work as i understand it
[09:57] <ogra> "It understands that if the control file lists "Architecture: i386" for the package, the package should not be acted on on other architectures. " from the manpage
[09:57] <kirkland> ogra: hrm
[09:58] <ogra> just add amd64 to Architecture: ... will just get me some more bugs for the binary i guess
[09:59] <ogra> there is no reason it shouldnt build, i just think the syscall translation layer doesnt work so well on amd64
[10:12] <ogra> doko, hey !
[10:13] <ogra> doko, "debian/*.shlibs: Update to the version from the branch." ... could that solve my ld-linux3-dev issues with the d-shlibs override ?
[10:13] <ogra> (from your binutils upload
[10:13] <ogra> )
[10:14] <doko> ogra: no, I don't think so
[10:14] <ogra> meh, ok
[10:14]  * ogra had hopes :)
[10:28] <pitti> tseliot: do you happen to have some time to test the intrepid-proposed nvidia-common in bug 303825?
[10:30] <tseliot> pitti: sure
[10:33] <YokoZar> doko: just a poke about the python2.6 stuff I filed/subscribed you to earlier (the FTBFS is blocking me from updating ia32-libs which in turn is FTBFSing Wine ;) )
[10:35] <dholbach> YokoZar: doko is on vacation or at least travelling right now
[10:35] <pitti> doko: I tried building python2.6 locally and in my PPA, and it failed three times with three different errors :-( (https://edge.launchpad.net/~pitti/+archive/ppa/+build/1207804 and https://edge.launchpad.net/~pitti/+archive/ppa/+build/1207804)
[10:35] <YokoZar> ahh ok
[10:35] <pitti> well, he did a binutils upload this morning :)
[10:35] <dholbach> ok
[10:36] <dholbach> I'm sure it's not the first time for doko to do that while on vacation ;-)
[10:36] <doko> dholbach: I'm back
[10:37] <pitti> doko: ah, hey! had a nice vacation?
[10:37] <doko> pitti: yes, thanks!
[10:37] <pitti> doko: beach and cocktail? Or the hiking/bike style? :-)
[10:37] <doko> pitti: there's a promotion request pending for readline6 binaries ...
[10:38] <pitti> doko: well, if we want to start the readline6 transition now, ok; but python2.6 still doesn't build
[10:38] <doko> pitti: no, just running and beach
[10:38] <pitti> nice
[10:38] <doko> pitti: it's not a transition, there are two development packages, and the readline6 source already is in main, because of readline-common
[10:39] <pitti>  readline6 | 6.0-2ubuntu2 | karmic/universe | source
[10:39] <doko> pitti: which is wrong, because readline-common is in main
[10:39] <pitti> ah, bug 421035 is incomplete
[10:40]  * pitti promotes source
[10:40] <doko> ahh, this was asked while I was away ...
[10:40] <pitti> ok, rest of binaries promoted
[10:41] <pitti> bug updated
[10:41] <doko> hmm, strange, no diffs anymore in the ui to the previous version
[10:42] <pitti> seb128: retracer> *nnng* bad gateway; WTH is up with LP today?
[10:42]  * pitti restarts retracers again
[10:43] <seb128> pitti, edge timeout
[10:43] <pitti> seb128: but apport isn't on beta-testers
[10:43] <seb128> my versions script fails on similar errors
[10:43] <arand> I'm poking in an SRU for glib2.0, noticing that in kk patch 61_* is added, however a 61_* patch already exists in intrepid version, should I simply use 62_* for intreipid alone or should it be changed throughout?
[10:44] <doko> pitti: about the build failure: I'll see on which archs the buld fails with -fprofile-use, and then disable it on these archs
[10:44] <arand> i.e. the 61_* patch in intrepid are a completely different patch, with the same number prefix.
[10:44] <pitti> doko: ok, thanks; at least it shouldn't be on depwait any more in 1 hours 15 mins
[10:47] <seb128> arand, the number are just for ordering
[10:47] <seb128> arand, you can use any number you want
[10:48] <arand> seb128: even though the same patch are going to be added in all releases, consistency in naming may be ignored?
[10:49] <seb128> arand, we don't care
[10:49] <seb128> the patch just need to be applied in a way which works
[10:49] <seb128> the naming, ordering, etc is a detail
[10:59] <spaetz> r-base is broken in Ubuntu karmic for all. Doh, could somebody apply the correct fix as described in
[10:59] <spaetz> https://bugs.launchpad.net/ubuntu/+source/r-base/+bug/426360
[10:59] <spaetz> ? It would be embarassing if that goes into karmic gold
[11:03] <pitti> I subscribed the sponsoring team
[11:03] <james_w> spaetz: if you subscribe "ubuntu-universe-sponsors" to bugs like this then they will get reviewed and uploaded when approved
[11:06] <cjwatson> I've also subscribed Dirk Eddelbuettel, who's the Debian R maintainer but who was also responsible for this Ubuntu-specific change; he doesn't seem to be subscribed to all Ubuntu r-base bugs
[11:08] <doko> cjwatson: do we plan to include dpkg 1.15.4 in karmic?
[11:09] <cjwatson> possibly
[11:10] <cjwatson> I haven't looked over it in detail yet but it's not out of the question
[11:17] <cjwatson> doko: what do you need it for? the install-info transition?
[11:20] <doko> cjwatson: yes, that would be convenient
[11:21] <cjwatson> I'm not going to say yes straight away because the changelog is massive, but I'll look at it
[11:39] <dholbach> did we ever come to an agreement if we want merge proposal for ~ubuntu-dev stuff on ubuntu-devel@?
[11:39] <dholbach> if we don't want that stuff, I'll just reject those mails now
[11:39] <dholbach> is there a way for us to turn that off?
[11:45] <james_w> dholbach: well, they were explicitly turned on, so they can be turned off again
[11:50] <pitti> james_w: bug 414298 ack'ed
[11:50] <james_w> thanks pitti
[11:52] <EricInBNE> if I want to contribute to a package in 9.10, where can I go to download the dev packages?
[11:52] <EricInBNE> *new ubuntu users
[11:55] <ScottK> EricInBNE: We aren't accepting new packages for 9.10 anymore.  We are concentrating on getting bugs fixed and things working.
[11:55] <ScottK> !development | EricInBNE
[11:55] <dholbach> james_w: hm?
[11:55] <EricInBNE> ScottK, its for bugfixing an existing package
[11:55] <ScottK> EricInBNE: Excellent.
[11:56] <ScottK> EricInBNE: What package?
[11:56] <EricInBNE> ScottK, recently changed from fedora to ubuntu.
[11:56] <james_w> dholbach: there was a change made in the Ubuntu teams on LP last year such that code review emails would go to ubuntu-devel@
[11:56] <james_w> dholbach: that change could be undone if desired, but it was an explicit decision to send them there
[11:56] <ScottK> EricInBNE: Welcome.
[11:56] <EricInBNE> ScottK, looking to contribute to the Android execution environment.
[11:57] <dholbach> james_w: ok... do you know if that was documented somewhere?
[11:57] <ScottK> I see.
[11:57] <james_w> not offhand
[11:57] <ScottK> dholbach: Do you have suggestions for what channel EricInBNE should be asking about contributing in?
[11:57]  * ScottK needs to run off for a few hours.
[11:57] <EricInBNE> ScottK, is that in .10? I couldnt find it. mjfrey mentioned he is looking for a few replacement pkgs on his weblog
[11:58] <ScottK> EricInBNE: I'm not sure.
[11:59] <ScottK> I suspect #ubuntu-mobile would be the place to ask, but I'm not certain.
[12:01] <dholbach> yep, that's what I'd say to
[12:01] <dholbach> too
[12:02] <EricInBNE> is launchpad the analog to rawhide? or is there another code repo
[12:02] <dholbach> check out https://wiki.ubuntu.com/UbuntuDevelopment
[12:02] <pitti> EricInBNE: karmic (the current Ubuntu development version) is the pendant to Fedora rawhide
[12:02] <asac> cjwatson: superblock having offset of my timezone a known issue?
[12:02] <dholbach> it should explain a lot about how the archive works
[12:03] <cjwatson> asac: bug 423247
[12:03] <cjwatson> (probably)
[12:04] <asac> ok cool
[12:04] <asac> will check if update makes this go away
[12:04] <liw> death to timezones! utc everywhere!
[12:04] <asac> i guess there is no way to not run fsck now?
[12:04] <asac> ;)
[12:05] <cjwatson> asac: update? it was an installer bug
[12:05] <asac> cjwatson: i get this on a regular install
[12:05] <cjwatson> so upgrading will make no difference
[12:05] <asac> cjwatson: second time now
[12:05] <asac> its an old install
[12:05] <cjwatson> install of what?
[12:05] <cjwatson> oh, not my problem then :)
[12:05] <asac> ubuntu?
[12:05] <cjwatson> I mean what vintage
[12:06] <asac> hmm
[12:06] <asac> feels too similar to be not the same ;)
[12:06] <cjwatson> there are lots of similar issues
[12:07] <cjwatson> if it's an old install, could you talk with Keybuk?
[12:07] <asac> Keybuk: ^^ ... on reboot i have to run fsck, because superblock has my timezone offset
[12:08] <cjwatson> of course it could be that the old installation broke your hardware clock
[12:08] <cjwatson> date; hwclock --debug --show
[12:08] <seb128> I got that several times too recently
[12:08] <cjwatson> cat /etc/default/rcS
[12:08] <cjwatson> well, grep ^UTC= /etc/default/rcS
[12:09] <asac> fsck is running ... will run that afterwards
[12:10] <cjwatson> basically, one possible cause is that the hardware clock has been rendered wrong at some point in the past, and it's only fixed up by NTP once the network comes up
[12:11] <seb128> I got the issue several times on karmic
[12:11] <asac> cjwatson: hmm. you say the hardware clock was always wrong? or you think just intermediately during karmic?
[12:11] <seb128> ie it's not only a one time problem due to old values
[12:12] <asac> otherwise we need to do something because loads of users will end up with fsck ;)
[12:12] <asac> seb128: i got it the second time now. feels like on every reboot where i did an dist-upgrade in between
[12:12] <cjwatson> if that's the case, the way to fix your computer is to fix the hardware clock: if /etc/default/rcS says UTC=yes, then it should be the time in UTC; if it says UTC=no, it should be the current local time
[12:12] <cjwatson> seb128: I only fixed the installer bug after alpha 5, a few days ago
[12:12] <cjwatson> asac: I think the installer bug has been around for ages and ages
[12:13] <hyperair> am i right in assuming this only happens if your system clock is in local time?
[12:13] <cjwatson> hyperair: you mean hardware clock; and I don't think you're right
[12:13] <asac> cjwatson: so ok. lets assume i had that installer bug. now its broken. the solution cant be to say: "fix your hardware clock" thats good for me, but not for users
[12:13] <hyperair> hmm
[12:13] <seb128> well, shouldn't we do something so user upgrading don't get that confusing login to manually run fsck on reboot?
[12:13] <cjwatson> yes, feel free to suggest something that actually works :-)
[12:13] <asac> i need to understand why it suddely started to break now
[12:13] <cjwatson> I agree it's a problem but have no bright ideas
[12:14] <cjwatson> asac: because Scott took out a workaround
[12:14] <seb128> same as asac
[12:14] <asac> it always worked till recently
[12:14] <seb128> can't we keep the workaround?
[12:14] <asac> so something must have changed. and thats where we probably need to fix it
[12:14] <cjwatson> it introduced other problems ...
[12:14] <seb128> if we don't have better ideas ...
[12:14] <hyperair> what was the workaround?
[12:14] <asac> we need to understand both impacts. fsck on every second reboot is worst you can get
[12:14] <asac> its close to complete system breakage
[12:15] <cjwatson> I don't know the details, and cannot participate further in this discussion without them
[12:15] <asac> hehe
[12:15] <asac> thats ok ;)
[12:15] <asac> lets wait
[12:16] <asac> fsck run takes about 1h anyway ;)
[12:17] <directhex> oh, hurrah, requestsync now correctly doesn't allow me to sponsor my own main requests
[12:20] <geser> ?
[12:21]  * maxb has also seen that timezone-fsck issue twice on rebooting an existing system
[12:21] <ion> keybuk: Around?
[12:22] <seb128> and it's not like it was a fsck normal run in usplasg
[12:22] <seb128> it's a command line prompt which invite you to run commands
[12:22] <cjwatson> yes, I *know*&
[12:22] <seb128> ie it's broken enough that most normal users will declare the system screwed and reinstall
[12:22] <cjwatson> yes, I *know*
[12:22] <cjwatson> you can stop explaining how important it is now. :-)
[12:22] <geser> directhex: is this a bug or not? I'm not sure from your statement
[12:22] <seb128> ok, let's wait for Keybuk to comment then
[12:23] <directhex> geser, it's an unbug
[12:23] <seb128> well, I have the impression that you argue that we traded an issue for an another one
[12:23] <directhex> geser, i was able to run requestsync for ages to sync packages in main, and didn't need a sponsor as i'm a motu
[12:23] <seb128> but apparently that was a false impression ;-)
[12:23] <seb128> as long as it's on the karmic list I'm fine with it
[12:23] <cjwatson> seb128: no, I'm arguing that "just put the workaround back" probably isn't the right answer, and we should actually think about it instead ;-)
[12:23] <seb128> let's people who understand what's going on work on it
[12:24]  * seb128 goes back to desktop land ;-)
[12:25] <Keybuk> seb128: do I have to comment?
[12:25] <seb128> Keybuk, no
[12:25] <seb128> Keybuk, I trust you to do whatever is required to sort that for karmic ;-)
[12:25] <asac> Keybuk: i would appreciate if you could explain whats the problem ;)
[12:25] <seb128> better to spend your time working on the bug rather than explaining it again on IRC
[12:26] <Keybuk> which bug?
[12:26] <asac> Keybuk: superblock has UTC offset for me on reboot ... requiring fsck
[12:26] <asac> its an old install
[12:26] <seb128> same here
[12:26] <Keybuk> asac: every time, or just after this one reboot?
[12:26] <seb128> it doesn't happen every time though
[12:26] <asac> Keybuk: its the second time in a row now
[12:26] <davmor2> Keybuk: https://bugs.launchpad.net/bugs/423247 I'm assuming
[12:26] <seb128> I didn't notice what trigger it yet
[12:27] <seb128> I had the issue several times
[12:27] <Keybuk> when it next happens, stop at the fsck error
[12:27] <Keybuk> and grab me
[12:27] <seb128> some of those have been forced reboot after a broken suspend resume
[12:27] <Keybuk> you'll need to run "grep ^UTC /etc/default/rcS", "date" and "hwclock --debug --show"
[12:28] <asac> Keybuk: ok. this reboot was forced reboot too
[12:28] <seb128> ie, resume, computer hangs, press the power button several second, turn computer on again, get the issue
[12:28] <asac> so maybe it only happens then
[12:28] <asac> yea
[12:28] <asac> i will try to reproduce once current fsck finishes
[12:28] <Keybuk> seb128: likewise if you can reproduce, stop at the moment things are inconsistent
[12:29] <seb128> ok
[12:29] <ion> keybuk: I added another patch, that one removes /forcefsck in a root_hook. http://heh.fi/patches/mountall/
[12:30] <Keybuk> ion: could you mail these to me, I don't keep track of IRC logs ;)
[12:30] <ion> keybuk: The URL has the patches. Is that okay?
[12:30] <Keybuk> ion: sure, but mail it to me ;)
[12:31] <ion> Will do
[12:31] <Keybuk> asac, seb128: the only clock bug that I am aware of was that the first/second reboot after installing, you'd hit the fsck error
[12:31] <Keybuk> once you've passed it, it's fixed and there are no issues
[12:31] <Keybuk> if you're hitting the fsck error on an installed system, you have an entirely different but that I am not familiar with
[12:32] <seb128> ok, I've an entirely different bug then
[12:33] <seb128> I got it several times in karmic
[12:33] <Keybuk> it's possible that you two have entirely different bugs
[12:33] <asac> Keybuk: colin said the clock-setup bug was around for long time in installer. you know what caused this show up now in karmic?
[12:33] <seb128> and I'm pretty sure each time after broken resume and forced power aoff and on cycles
[12:33] <Keybuk> "fsck has time inconsistency" is a bit like "human has a runny nose"
[12:33] <Keybuk> asac might have a cold, where you might have swine flu, etc.
[12:33] <Keybuk> asac: yes, I know why clock issues are showing up in karmic suddenly
[12:33] <asac> my superblock time is exactly offset by my timezone
[12:34] <seb128> same here
[12:35] <Keybuk> asac, seb128: in which direction?  negative timezone or double timezone?
[12:35] <asac> fsck says: "time == UTC", but superblock == "my timezone time"
[12:36] <Keybuk> asac: don't suppose you can pastebin me the contents of your /etc/adjtime file?
[12:36] <asac> fsck is currently running. i will get you that right after
[12:36] <Keybuk> ok
[12:36] <Keybuk> seb128: what way is the timezone math for you?
[12:36] <seb128> I don't remember, I had the issue several days ago
[12:36] <seb128> $ grep ^UTC /etc/default/rcS
[12:36] <seb128> UTC=no
[12:36] <seb128> if that matters
[12:37] <seb128> I will try to power down the laptop later but not now ;-)
[12:37] <Keybuk> seb128: your /etc/adjtime file would be helpful
[12:37] <Keybuk> see that's interesting
[12:37] <seb128> $ cat /etc/adjtime
[12:37] <seb128> 0.193938 1252449040 0.000000
[12:37] <seb128> 1252449040
[12:37] <seb128> LOCAL
[12:37] <Keybuk> the fact that you have UTC=no means that you can't possibly have the same bug as asac
[12:41] <asac> Keybuk: http://paste.ubuntu.com/267881/
[12:42] <asac> no adjtime at all
[12:42] <seb128> re
[12:42] <seb128> ok, that broke again
[12:42] <seb128> I get it every time I shut down the laptop not properly
[12:42] <seb128> I'm on my netbook now
[12:43] <seb128> Keybuk: what info do you need?
[12:43] <seb128> now =13:
[12:43] <seb128> superblock = 15:...
[12:43] <seb128> 13:40:20 is now
[12:43] <asac> Keybuk: http://paste.ubuntu.com/267883/ ... thats --show --debug
[12:44] <seb128> no rcS UTC=no
[12:44] <seb128> date says 13:45:02
[12:45] <seb128> hwclock says the same
[12:45] <asac> let me try to reproduce now .... /me hits powerbutton
[12:46] <seb128> oh
[12:46] <seb128> hwclock --debug --utc
[12:46] <seb128> Time read from clock ... 13:46
[12:46] <seb128> Wed Sep 9 15:46
[12:47] <asac> Keybuk: so i was wrong. time == "timezone time" ... superblock time == "timezone time + my timezone offset" ... so yeah double timezone offset
[12:47] <seb128> so hwclock is acting as if UTC=yes was used
[12:47]  * asac should better know what time it is ;)
[12:47] <Keybuk> seb128: sorry rewind
[12:47] <asac> i am now in the "do fsck state"
[12:47] <ion> keybuk: Whoops, i hadn’t re-exported the patches. The URL contains patches that actually work now. :-P
[12:47] <seb128> me too
[12:47] <Keybuk> seb128: what is the exact fsck output at the point it fails?
[12:48] <Keybuk> asac: likewise, what is the exact fsck output right now?
[12:48] <ion> keybuk: At least rm-forcefsck was broken.
[12:48] <seb128> ups
[12:49] <seb128> Keybuk: "/dev/sda6: Superblock last write time (Wed Sept 9 15:40:20 2009
[12:49] <seb128> now = ... 13:....
[12:49] <Keybuk> seb128: please, I do need the whole thing
[12:49] <seb128> UNEXPECTED INCONSISTENCY
[12:49] <Keybuk> don't abbreviate it
[12:49] <Keybuk> the times are quite important
[12:49] <seb128> 15:40:20
[12:49] <seb128> 13:40:30
[12:49] <Keybuk> ok, so your superblock was last written at 15:40:20
[12:50] <Keybuk> and your "time now" is 13:40
[12:50] <Keybuk> your time now looks correct to me
[12:50] <seb128> yes it is
[12:50] <directhex> hm. what's the quick way to check why a package was promoted to main?
[12:50] <seb128> the 15: is two hours in the futur
[12:50] <Keybuk> it's 11:50 UTC, 13:50 CET
[12:50] <seb128> directhex: which one?
[12:50] <Keybuk> seb128: you have UTC=no in /etc/default/rcS ?
[12:50] <seb128> I've UTC=no
[12:50] <seb128> yes
[12:50] <directhex> seb128, libgluezilla
[12:50] <Keybuk> seb128: your /etc/adjtime file has LOCAL in it?
[12:50] <seb128> directhex: dunno, look for bugs
[12:51] <seb128> Keybuk: yes
[12:51] <Keybuk> seb128: what does "date" say?
[12:51] <seb128> 13:51:38
[12:51] <asac> Keybuk: http://www.flickr.com/photos/asacasa/3903749434/sizes/l/
[12:51] <Keybuk> and /etc/localtime is a file not a symlink?
[12:52] <Keybuk> seb128: hwclock --debug --show ?
[12:52] <seb128> it's a file
[12:52] <Keybuk> asac: could you provide the same bits of information as seb128
[12:52] <directhex> hm, i wrote the MIR. i need to see someone over memory issues
[12:52] <geser> directhex: look at the MIR bug #362854
[12:52] <seb128> Time read from the hw clock ... 13:52:34
[12:52] <Keybuk> seb128: could you pastebin it so it doesn't get lost
[12:52] <seb128> Hw clock time 13:52:34
[12:52] <Keybuk> I do need the entire output
[12:52] <seb128> Wed Sep 9
[12:52] <asac> Keybuk: time is the same as seb
[12:53] <directhex> geser, look at who wrote the MIR attached to the bug!
[12:53] <seb128> Keybuk: not sure, I'm at the boot fsck prompt
[12:53] <asac> Keybuk: UTC=no in rcS
[12:53] <asac> Keybuk: and no adjtime file at all and localtime is not a link
[12:54] <seb128> Keybuk: give me all the commands you want, I will put that to a log, reboot and pastebin
[12:54] <Keybuk> asac: and hwclock output?
[12:54] <Keybuk> seb128: hwclock --debug --show
[12:54] <Keybuk> that's about all I can think of for now ;)
[12:54] <seb128> all times are 13:...
[12:54] <seb128> but --utc says 15
[12:54] <asac> Keybuk: looks pretty identical to what i pasted from running session: http://paste.ubuntu.com/267883/
[12:55] <asac> i can get a photo if you want
[12:55] <seb128> I don't know why --utc adds 2 hours
[12:55] <seb128> that doesn't make sense to me
[12:55] <seb128> ie --debug --show has all to 13:
[12:55] <seb128> --utc is 15:...
[12:56] <Keybuk> seb128: because it does
[12:56] <cjwatson> --utc assumes that your hardware clock is kept in UTC; the time that hwclock --show shows is always in local time
[12:56] <cjwatson> so it's add, not subtract
[12:56] <seb128> ah ok
[12:56] <asac> for me --utc is correct: 11:50
[12:56] <Keybuk> right, --utc isn't "show me the time in utc"
[12:56] <Keybuk> it's "if the hwclock was in utc, what would the time be"
[12:56] <spaetz> james_w:(and others) thanks for the ubuntu-universe-sponsors tips
[12:56] <Keybuk> asac: err, that doesn't make sense
[12:56] <asac> http://www.flickr.com/photos/asacasa/3903756212/
[12:56] <asac> hwclock photo
[12:57] <asac> Keybuk: not sure if you missed it, but i have no /etc/adjtime at all ... is that ok?
[12:57] <Keybuk> asac: do that with --utc on the hwclock line as well
[12:57] <Keybuk> asac: yes, that's ideal
[12:57] <asac> sure
[12:57] <seb128> I don't get how the superblock got a time 2 hours in the futur
[12:58] <Keybuk> are you using ext4 or ext3 ?
[12:59] <asac> Keybuk: http://www.flickr.com/photos/asacasa/3902980651/ ... and ext3
[12:59] <asac> sorry. photo is not best quality ;)
[12:59] <Keybuk> asac: did you say you had UTC=no or UTC=yes ?
[13:00] <asac> Keybuk: =no
[13:00] <asac> in rcS
[13:00] <Keybuk> huh
[13:00] <Keybuk> well, your hardware clock is in UTC
[13:00] <Keybuk> isn't it?
[13:00] <Keybuk> oh, no
[13:00] <asac> Keybuk: the hwclock --utc output shows 1500 ... thats wrong
[13:00] <Keybuk> sorry, had the images round the wrong way
[13:01] <Keybuk> yes
[13:01] <Keybuk> so that's correct
[13:01] <asac> thats UTC + 2* offset
[13:01] <Keybuk> your hardware clock is in local time
[13:01] <asac> k
[13:01] <Keybuk> ok
[13:01] <asac> does that give any hints?
[13:01] <Keybuk> everything is absoutely right
[13:01] <Keybuk> could you do the fsck -y
[13:01] <Keybuk> then finish booting
[13:02] <Keybuk> and grab me then again
[13:02] <Keybuk> let's see if it's something about the running system
[13:02] <asac> everything is allright, except: http://www.flickr.com/photos/asacasa/3903749434/ :)
[13:02] <asac> ok doing that now
[13:02] <seb128> running fsck takes ages
[13:09] <Keybuk> hmm
[13:09] <directhex> yay @ whomever is on archive admin duty today
[13:09] <Keybuk> Last write time:          Wed Sep  9 13:09:55 2009
[13:10] <Keybuk> so that's in local time
[13:10] <Keybuk> I wonder whether it's supposed to be in local time or UTC
[13:10] <seb128> Keybuk, I'm back from fsck if you need infos
[13:10] <arand> I seem to get that error often after update-reboots: http://imagebin.org/63162
[13:10] <Keybuk> seb128: finish up the boot as normal
[13:11] <Keybuk> seb128: then in the normal system, run "hwclock --debug --show" and "date" again
[13:11] <seb128> Keybuk, right, I'm back at GNOME after fsck there
[13:11] <Keybuk> seb128: it'd also help to have the output from "tune2fs -l YOURDISK"
[13:11] <asac> http://paste.ubuntu.com/267883/
[13:11] <asac> that was in the reboot state for hwclock --debug --show
[13:12] <asac> my fsck hasnt finished, but thats how it was after last fsck ;)
[13:12] <asac> Keybuk: ^^
[13:12] <seb128> Keybuk, http://paste.ubuntu.com/267895/
[13:13] <asac> btw, paste.ubuntu.com has a time issue too  i think ;)
[13:13] <asac> 05:12:37 +0000 for seb128's paste
[13:14] <Keybuk> seb128: thanks, now try "tune2fs -c 29 /dev/sda6" then "tune2fs -l /dev/sda6"
[13:15] <seb128> Keybuk, http://paste.ubuntu.com/267898/
[13:15] <Keybuk> ok
[13:15] <Keybuk> so your "last write time" is in CET
[13:15] <Keybuk> (in tune2fs output)
[13:15] <Keybuk> now could you run "shutdown now" (no -h plz)
[13:16] <Keybuk> that'll take you down into single user mode
[13:16] <Keybuk> from there you should be able to "mount -o remount,ro /"
[13:18] <seb128> let me restart my IRC on the netbook so I'm still online while doing that ;-)
[13:20] <asac> Keybuk: i assume you dont need me until finished with seb128 ? otherwise system has booted
[13:20] <Keybuk> asac: if you could do the tune2fs bits, that'd be helpful
[13:21] <asac> k
[13:21] <asac> but not the shutdown?
[13:21] <Keybuk> not yet, just tune2fs first
[13:21] <Keybuk> one step at a time
[13:21] <asac> kk
[13:21] <Keybuk> want to check what your last write times are in the "up" system
[13:22]  * ogra is fishing for an idea ... 
[13:23] <ogra> i have a static qemu wrapper that enables me to build and use chroots with arm binaires on x86 using the binfmt systemn
[13:23] <asac> oh no
[13:23] <asac> X hanged
[13:23] <asac> right when i wanted to copy the past
[13:23] <ogra> if i chroot into such a chroot, i can apt-get install ubuntu-desktop ...
[13:23]  * asac typing
[13:23] <ogra> my prob is that as soon as it comes to mono, the install hangs
[13:23] <asac> http://pastebin.com/f40cfa057
[13:24] <asac> Keybuk: ^^
[13:24] <pitti> Keybuk: ubuntu boot testing> yay!
[13:24] <ogra> simply because mono installs an armel binfmt wrapper *inside* the chroot ... which indeed cant execute
[13:24] <seb1281> Keybuk: ok, got prompt and remount
[13:24] <seb1281> next?
[13:25] <Keybuk> remount succeeded?
[13:25] <seb1281> yes
[13:25] <Keybuk> wow
[13:25]  * Keybuk has to SysRq that
[13:25] <Keybuk> now try fsck -a /dev/sda6
[13:26] <seb1281> clean
[13:26]  * ogra wonders if anyone has an ide how to wrap binfmt wrappers in binfmt wrappers 
[13:26] <ogra> *idea
[13:27] <seb1281> Keybuk: it says the disk is clean
[13:27] <Keybuk> seb1281: ok...
[13:28] <Keybuk> seb1281: sh -x /etc/init.d/hwclock.sh stop
[13:28] <Keybuk> I'm interested in the line that calls hwclock
[13:28] <seb1281> /sbin/hwclock --rtc=/dev/rtc0 --systohc --localtime
[13:29] <Keybuk> ok
[13:29] <Keybuk> hwclock --debug --show
[13:29] <Keybuk> all the times still right?
[13:29] <seb1281> yes
[13:29] <Keybuk> and tune2fs -i /dev/sda6
[13:29] <Keybuk> what's the "last write time" ?
[13:30] <seb1281> -j?
[13:30] <Keybuk> err -l sorry
[13:30] <cjwatson> ogra: are you sure that the problem is one of wrapping? because I'm pretty sure that the kernel uses the normal exec path when it executes binfmt handlers, including binfmt_misc itself; I know this because when I was writing binfmt-support first, I installed an ELF handler for the ELF binary format as a test, and my system fell over :-)
[13:30] <seb1281> 14:24:44
[13:30] <seb1281> ie correct
[13:30] <Keybuk> seb1281: ok, "reboot -f" from here
[13:30] <Keybuk> does the system come up without an fsck?
[13:31] <arand> Seems like I was able to create the fsck issue by running "dkpg --configure -a" && "apt-get -f install"
[13:31] <cjwatson> ogra: it wouldn't just be that the mono handler installed inside the chroot conflicts with the one outside the chroot?
[13:31] <seb1281> ie, reboot?
[13:31] <ogra> cjwatson, well, binfmt looks for the magic in the binary
[13:31] <ogra> and then execs the wrapper
[13:31] <Keybuk> seb1281: yes, but using that command
[13:31] <cjwatson> ogra: or indeed that the kernel doesn't honour the chroot-ness when executing the binfmt handler
[13:31] <cjwatson> ogra: yeah, I know how binfmt works :-)
[13:31] <ogra> in my case it would additionally have to wrap a call to qemu-arm-static around that
[13:31] <cjwatson> no, I suspect that the problem is that binfmt_misc is executing the binfmt handler outside the chroot
[13:31] <ogra> yes
[13:32] <cjwatson> the call to qemu-arm-static would be implicit if it were *actually executing an arm binary*
[13:32] <cjwatson> but it isn't
[13:32] <seb1281> Keybuk: yes, no fsck it boots just fine
[13:32] <ogra> qemu-arm-static is static because it's in the chroot ;)
[13:32] <cjwatson> it's executing the i386 handler for the same thing outside the chroot
[13:32] <ogra> right
[13:32]  * seb1281 wonders if it would be faster for keybuk to set UTC=no and sit on the power button too ;-)
[13:33] <cjwatson> the only way I can think of to fix this would be for binfmt-support to somehow figure out the path from the real root to the chroot, and prefix everything with that
[13:33] <cjwatson> but then it would also have to resolve conflicts between handlers inside and outside the chroot
[13:33] <cjwatson> this gets *very* complex ...
[13:33] <ogra> but that would mean to fiddle with the host install
[13:33] <pitti> seb1281: FYI, libgdata packaging/security looks fine; waiting for MIR to get rationale/maintainer/subscriber/i18n check, etc.
[13:34] <ogra> yeah, that whole thing is very complex
[13:34] <seb1281> pitti: thanks
[13:34] <ogra> but will rock once it works :)
[13:34] <seb1281> pitti: I will do that later if nobody beats me to it (which I doubt I've been trying to find olunteers for a week without success now)
[13:34] <seb1281> chrisccoulson said he would do it if nobody does
[13:34] <seb1281> but I prefer him to keep working on the bugs he's tracking ;-)
[13:36] <cjwatson> ogra: yes, at the moment I don't think this can be done without fiddling with the host
[13:36] <ogra> hmm, k, i'll think about a not to evil way for that
[13:37] <cjwatson> a more elegant approach would probably involve binfmt_misc recognising and remembering the filesystem namespace of the process registering a handler with it
[13:38] <cjwatson> I think that would be a really good thing to fix, actually
[13:38] <cjwatson> userspace isn't really the right place to deal with this
[13:38] <ogra> right, my biggest prob is currently that i want some tool like livecd-rootfs that rolls an armel rootfs
[13:39] <ogra> if i can somehow have something wrapped around the chroot calls inside that script it would already massively help
[13:39] <ogra> oh, you would fix it in-kernel ?
[13:42] <cjwatson> ogra: yes, I think that makes a lot more sense
[13:42] <ogra> indeed
[13:42] <cjwatson> the kernel should invoke the binfmt handler in the same filesystem namespace that registered it in the first place
[13:42] <ogra> though i dont see that solving my prob
[13:42] <cjwatson> it would solve it perfectly, as long as it could cope with having different handlers for the same thing in different namespaces
[13:43] <ogra> if the kernel invokes "/usr/bin/cli" from the binfmt_misc handler, it doesnt matter where /usr/bin/cli actually lives
[13:43] <cjwatson> yes, it really does
[13:43] <ogra> since /usr/bin/cli needs to be executed by qemu-arm-static
[13:43] <cjwatson> you misunderstand :-)
[13:44] <ogra> oh, wait, binfmt looks only at the magic
[13:44] <cjwatson> if it executes /usr/bin/cli in the chrooted filesystem namespace, then that /usr/bin/cli will be an arm executable, and so when it execs it it'll go through its binfmt handlers again and find that it needs to use qemu-arm-static to execute that binary
[13:44] <ogra> so it *would* use qemu-arm-static because the magic inside the chroot is the right one
[13:44] <ogra> yeah, sorry, i was dense for a second
[13:45] <ogra> indeed
[13:45] <ogra> thats the stacked scenario i was looking for
[13:45] <Keybuk> seb128: so what causes you to hit fsck?
[13:45] <cjwatson> right, all that already works, the bit that doesn't work is just the namespacing
[13:45] <ogra> yup
[13:45] <seb128> Keybuk, press the power button for some seconds to shutdown the box
[13:45] <seb128> Keybuk, on next boot I get the issue
[13:45] <Keybuk> next "normal" boot
[13:46] <Keybuk> or next boot with unclean shutdown?
[13:46] <seb128> Keybuk, ie sit on the button to force powerdown don't let the soft do the job
[13:46] <blackxored> hello
[13:46] <seb128> force the box down by sitting on the button
[13:46] <seb128> and press the button once again to turn it on
[13:46] <Keybuk> seb128: what about force by S U B ?
[13:46] <seb128> S U B ?
[13:47] <Keybuk> seb128: Alt+SysRq S U B
[13:47] <ion> My laptop’s keyboard makes S and B possible, but not U. :-)
[13:47] <seb128> Keybuk, let me try
[13:47] <cjwatson> what, alt+sysrq involves fn+u or something?
[13:47] <cjwatson> get a better laptop :-)
[13:47] <ion> You have to hold down fn to get sysrq from the delete key, and U happens to be one of the letters that do something else (numpad-4) with fn.
[13:47] <Keybuk> on some laptops you have to do Alt+Fn+SysRq, then release the Fn key, while still holding down Alt+SysRq to press S then U then B (individually)
[13:48] <Keybuk> on other laptops, like the dells, you do Alt+PrntScrn
[13:48] <ion> keybuk: I’ll have to try that.
[13:50] <Keybuk> seb128: could you file a bug on e2fsprogs with this information
[13:51] <Keybuk> title should be something like "after hard power off, fsck on boot fails because last mount time is in the future"
[13:51] <Keybuk> attach all the bits you've gatherered
[13:51] <Keybuk> (then I get Ted to look as well)
[13:52] <soren> ion: You can let go of the Fn key once you've pressed sysrq.
[13:52] <seb128> Keybuk, no fsck when rebooting this way
[13:53] <seb128> let me try something
[13:56] <ogra> cjwatson, hmm, actually that sounds like an easy way to do harmful stuf from within a chroot ...
[13:57] <cjwatson> ogra: I disagree; it actually fixes a trivial way to break out of the chroot
[13:57] <seb128> Keybuk, I tried a suspend cycle to see if that changed some values on the filesystem but no
[13:57] <ogra> as long as i know what binfmt support is installed on the host i could actually break out of my chroot
[13:57] <cjwatson> unless you mean the current situation
[13:57] <Keybuk> seb128: so safe sync/unmount cycle does not cause this
[13:57] <Keybuk> but forced power off causes it every time for you?
[13:57] <ogra> cjwatson, i mean the current behavior
[13:57] <ogra> :)(
[13:58] <seb128> Keybuk, I would say yes, it happened 3 times on 3 forced shutdown so far
[13:58] <ogra> sounds like a serious security issue
[13:58] <cjwatson> ogra: not really hugely serious since there are loads of ways to break out of chroots anyway, but yeah
[13:58] <Keybuk> ok
[14:01] <cjwatson> ogra: but yeah, I think I thought about that at more or less the same time you did :)
[14:01] <ogra> heh
[14:02]  * ogra takes a break ... to much mono found its way into my brain today ... 
[14:03] <highvoltage> ogra: ouch!
[14:04] <tseliot> pitti: the fix for bug 303825 works here (I had to install Intrepid to test it). I added a comment in the bug report.
[14:05] <Keybuk> seb128: I can replicate this
[14:05] <Keybuk> you do need UTC=no
[14:05] <Keybuk> and you do need to force the power off, rather than unmounting safely
[14:05] <Keybuk> and the best bit is, dumpe2fs and e2fsck are disagreeing about the last write time of the superblock ;)
[14:05] <seb128> ah good
[14:05] <seb128> I was pondering trashing my netbook install to have a test box
[14:05] <seb128> but if you get the issue it's better ;-)
[14:09] <pitti> tseliot: thanks
[14:15] <ion> keybuk: Bootcharts, as requested. http://heh.fi/tmp/ubuntu-boot/
[14:16] <ion> Dunno why the bar height is different in the charts.
[14:20] <cjwatson> seb128: did you see Martin's comment in bug 351577 to the effect that you should go ahead and add the build-dep to evolution?
[14:20] <seb128> cjwatson, yes but current evolution requires a new lib version which fails to build and I didn't manage to sort that yet...
[14:20] <seb128> cjwatson, thanks for the reminder though ;-)
[14:21] <cjwatson> likewise tracker->vala apparently
[14:21] <seb128> dunno about this one, was the bug from chrisccoulson?
[14:21] <cjwatson> yes
[14:22] <ScottK> cjwatson: Yesterday when I asked about an LP archive rebuild, you said something about a reminder today, so here it is.
[14:22] <cjwatson> ScottK: oh yes, thanks
[14:22] <ScottK> NP
[14:22]  * cjwatson tries to remember the runes
[14:22] <seb128> cjwatson, he's not on IRC right now but I will ask him about it when he joins later
[14:23] <cjwatson> thanks
[14:33] <jjardon> asac, ping
[14:34] <asac> jdstrand: please ask directly if my nick is here ;)
[14:34] <jjardon> hello, some time ago I told you about the posibility of a upgrade of mobile-broadband-provider-info package
[14:35] <jjardon> because it has some new providers
[14:37] <jjardon> Could you upgrade the package now?
[14:52] <cjwatson> ScottK: building now. https://launchpad.net/ubuntu/+archive/test-rebuild-20090909
[14:52] <ScottK> cjwatson: Thanks.
[14:52] <cjwatson> I didn't bother building on lpia
[14:54] <Keybuk> seb128: I think I've cracked this bug
[14:54] <Keybuk> and I'm going to start pulling faces at Ted Tso
[14:54] <Keybuk> it's an ext3/4 bug
[14:54] <ebroder> Can anybody from ubuntu-sru ACK bug #330766? It's affecting our site deployment when users run out of quota
[14:55] <seb128> Keybuk, oh, good job ;-) let me know if you open any launchpad or upstream bug about the issue
[14:55] <Keybuk> seb128: can you please confirm though
[14:55] <Keybuk> are you using ext3 or ext4
[14:55] <Keybuk> that's very important
[14:55] <seb128> ext3 on all my machines
[14:56] <Keybuk> are you *sure* on the netbook?
[14:56] <seb128> yes
[14:56] <Keybuk> if it's running karmic, did you go out of your way to use ext3 not ext4
[14:56] <Keybuk> can you give me /var/log/dmesg from that computer
[14:56] <seb128> I used the netbook to do IRC, not to try the bug
[14:56] <Keybuk> ah right, dmesg from the machine with the bug
[14:56] <seb128> that's my d630, I installed intrepid and didn't reinstall since
[14:56] <seb128> just upgraded
[14:56] <Keybuk> sure
[14:57] <seb128> what do you want in the dmesg?
[14:57] <Keybuk> just the whole log please
[14:58] <seb128> Keybuk, http://people.canonical.com/~seb128/dmesg
[14:58] <seb128> Keybuk, sda6 is the partition which triggers the fsck
[14:59] <seb128> "[   21.959392] EXT3 FS on sda6, internal journal"
[15:02] <Keybuk> sweet
[15:03] <Keybuk> [    3.696914] EXT3-fs: sda6: orphan cleanup on readonly fs
[15:03] <Keybuk> [    3.710783] ext3_orphan_cleanup: deleting unreferenced inode 4636785
[15:03] <Keybuk> [    3.710803] EXT3-fs: sda6: 1 orphan inode deleted
[15:03] <Keybuk> [    3.710804] EXT3-fs: recovery complete.
[15:03] <Keybuk> [    3.712723] EXT3-fs: mounted filesystem with writeback data mode.
[15:03] <Keybuk> that was the important bit from yours
[15:03] <seb128> Keybuk, ok, thanks
[15:04]  * Keybuk can't stop grinning about this
[15:05] <ogra> inodes are overrated anyway
[15:07] <Daviey> ogra: they are until you run out. :)
[15:07] <ogra> i have a pot with them on the desk and a funnel on my disk :P
[15:08] <cjwatson> ogra: can you make ltsp-client-core stop depending on unionfs-fuse? I assume you're using aufs again ... see bug 379952
[15:09] <ogra> cjwatson, hrm, i thought stgraber did that already
[15:29] <ogra> kirkland, did the change work ?
[15:29] <kirkland> ogra: no :-(
[15:30] <ogra> huh ?
[15:30] <kirkland> ogra: Build Log: https://launchpad.net/~kirkland/+archive/ppa/+build/1209629/+files/buildlog_ubuntu-karmic-amd64.qemu-kvm_0.11.0~rc2-0ubuntu3~ppa1_FAILEDTOBUILD.txt.gz
[15:30] <ogra> you made it Architecture: i386 amd64 ?
[15:30] <kirkland> ogra: funny, that works when i build locally (just adding amd64 to the Architecture list)
[15:30] <kirkland> ogra: yeah, that exactly ... that builds fine on my laptop
[15:31] <kirkland> ogra: but not when i push it to the ppa or buildd
[15:31] <ogra> might need the -s too
[15:32] <ogra> i know the buildds runs stuff in a slightly different order than debuild
[15:33] <ogra> erm, in your log it doesnt even build it
[15:44] <liw> I have a new computer-janitor package that I would like to have uploaded; it has bug fixes only; are we late enough in the cycle to require an exception process?
[15:46] <liw> hm, I think we are
[15:53] <jdub> StevenK: does go-home-applet need to depend on netbook-launcher?
[15:59] <cjwatson> liw: bug fixes only are fine at the moment without any particular kind of exception process
[15:59] <liw> cjwatson, good, thanks
[16:04] <geser> kirkland: try passing --binary-arch if you want to simulate an amd64 build on the buildd with your pbuilder
[16:05] <geser> kirkland: the problem is: on the i386 buildd the binary target is used, which depends on your binary-static, binary-indep and binary-arch targets, on amd64 only the binary-arch target is called and it doesn't depend on the binary-static target so no qemu-arm-static is getting build
[16:08] <ogra> geser, oh, thats a good hint ... i dont get why -s isnt respected by debhelper at all though
[16:11] <geser> ogra: it isn't? what makes you believe it?
[16:11] <ogra> geser, kirklands local tests
[16:13] <ogra> geser, when he added -s across the board to all debhelper calls in binary-static having qemu-arm-static as Architecture: i386 in control, a build on his amd64 still attempted to run the debhelper stuff in binary-static
[16:13] <geser> ogra: it depends how kirkland called his pbuilder. Without the --binary-arch option it behaves like the i386 buildd even on amd64 -> the "binary" target gets called which calls then binary-static
[16:14] <ogra> well, depends also if he even uses pbuilder :)
[16:17] <geser> ogra: the manpage for debhelper doesn't say if -pqemu-arm-static will build it regardless of any architecure setting (and any -a or -s flag), need to look into the source
[16:18] <ogra> well, as i understand the manpage it should only build i386 with "-s -pqemu-arm-static"
[16:18] <ogra> (if it is Architecture: i386 at least)
[16:19]  * amitk is wondering why showkey is complaining of a missing file descriptor
[16:19] <amitk> showkey
[16:19] <amitk> Couldn't get a file descriptor referring to the console
[16:19] <ogra> buy another console :)
[16:20] <amitk> ogra: that would mean getting a new dev box too, same error on 64bit karmic
[16:21] <amitk> nevermind, it seems to require sudo. Weird error message though.
[16:21] <cjwatson> ogra: -pqemu-arm-static will build that specific package even if -s isn't given
[16:21] <ogra> yeah, strace agrees
[16:21] <cjwatson> if you don't want that, change debian/rules
[16:21] <ogra> cjwatson, but if -s is given ?
[16:22] <cjwatson> then you get the combination of (same-arch packages) and (qemu-arm-static)
[16:22] <cjwatson> they concatenate
[16:22] <ogra> ah
[16:24] <zul> I forget do we need a FFE for a merge from debian that fixes a bug in launchpad
[16:25] <cjwatson> zul: not if it doesn't add features
[16:25] <zul> cjwatson: thanks
[16:31] <geser> ogra: my perl is not the best, but if I understood the debhelper code correct -s -p is OR and not AND combined, so a package specified in -p gets added always to the list of packages to do
[16:31] <ogra> geser, yes, thats what cjwatson said :)
[16:35] <kees> Keybuk: you mention network filesystems in the boot testing call.  I use autofs for my NFS, not static mounts -- is this still a problem?
[16:39] <Keybuk> kees: autofs should be ok
[16:50] <liw> does anyone here have skype, acroread, or google-earth installed from .debs? if so, could you give me the exact package names?
[16:50] <slangasek> mathiaz: are you doing the seed change for bug #424051?
[16:50] <slangasek> (I see that you're subscribed)
[16:50] <mathiaz> slangasek: I can do that
[16:51] <mvo> liw: picasa is another common one
[16:54] <mathiaz> mvo: hi!
[16:54] <mathiaz> mvo: did you get a chance to look at bug 413789?
[16:56] <mvo> mathiaz: no, sorry
[16:57] <mathiaz> mvo: I've subsribed to the bug - is that enough to get it on your radar?
[17:02] <mvo> mathiaz: not currently :( I have it on my radar now, but for urgent stuff I need irc pings currently, I'm way behind with bugmail
[17:03] <mathiaz> mvo: allright - I'll keep that an eye on it too - thanks!
[17:03] <mvo> thanks
[17:05] <slangasek> Keybuk: ok, shall we stop abusing #-meeting? :)
[17:05] <Keybuk> slangasek: but I like abuse!
[17:05] <Keybuk> err, wait
[17:07] <slangasek> Keybuk: so the only delta vs. what I've sent to Joey should be for the handling of upstart-native jobs, and the maintainer script fixups to remove existing init scripts
[17:07] <Keybuk> yes, I think so
[17:07] <slangasek> the latter can be sent upstream, the former can be kept as an Ubuntu delta right now since Debian can't have any native upstart jobs yet anyway
[17:07] <Keybuk> and the maintainer scripts using upstart commands rather than invoke-rc.d (which doesn't work)
[17:07] <mathiaz> Keybuk: hi! I'm looking at the server seed in karmic and there are two wireless packages in there (wireless-tools and wpasupplicant - the latter with your name beside it)
[17:08] <mathiaz> Keybuk: is there a reason to have these in the default server install?
[17:08] <slangasek> Keybuk: no, that's a bug in upstart-job, it exists to give init script compat and it's not doing it if start-if-started returns an error. :)
[17:09] <Keybuk> slangasek: it's a bug in insserv actually, it doesn't know about upstart-job
[17:09] <Keybuk> and it's a bug in invoke-rc.d because *it* doesn't know about upstart-job
[17:09] <kees> slangasek: do you have a moment to look at bug 426658 ?
[17:09] <Keybuk> ie. they don't *call* upstart-job to ask
[17:09] <Keybuk> and even if they did, for upstart-native jobs, the reply would be "what's a runlevel?"
[17:09] <slangasek> Keybuk: oh; well, that's a bug pere committed to fixing, yes
[17:11] <slangasek> kees: yes, drilling into that this morning
[17:11] <kees> slangasek: ok, thanks
[17:13] <kees> slangasek: anything I can help with?
[17:13] <slangasek> kees: make sure unix_chkpwd still has right perms in the package
[17:13] <slangasek> otherwise, I can't see how it's a pam bug
[17:16] <Keybuk> slangasek: uploaded a boot6 with --replace inverted to --upstart-only, and the "upstart (>= 0.6.0)" dep used in the upstart-only case only
[17:16] <Keybuk> if you don't mind, you have a better rapport with Joey than me, do you mind feeding him the changes?
[17:22] <ScottK> liw: For skype you get choices.  skype-ubuntu-intrepid, skype-ubuntu-hardy, skype-debian.  I'm currently using the Debian one (for Lenny) because it seemed to work best on Karmic.
[17:27] <slangasek> Keybuk: sure, will do
[17:29] <Keybuk> slangasek: you're right, --upstart-only is better
[17:29]  * Keybuk has to modify less <g>
[17:30]  * slangasek grins
[17:36] <kirkland> mdz: soren: I just saw the minutes from the tech board, that sun-java is being removed...  so I should be trying to move alfresco to use openjdk for the appliance images?
[17:37] <mdz> kirkland, those are based on 9.04 afaik
[17:37] <mdz> or expected to be, since that's where alfresco is available
[17:37] <kirkland> mdz: ah, okay
[17:37] <kirkland> mdz: i can roll with that
[17:40] <soren> kirkland: Yes. Did you not get my e-mail on the subject?
[17:43] <kees> slangasek: unix_chkpwd is ok
[17:44] <slangasek> pitti: bug #426905> since ubuntu-desktop Recommends: empathy, won't it be pulled in on (approximately) /all/ systems on upgrade?
[17:46] <seb128> slangasek, that's the intend I think
[17:46] <slangasek> seb128: right, so pretty much everyone will get the offer to remove it
[17:47] <seb128> slangasek, well, seems we have little clue about how the janitor is working
[17:47] <seb128> will that happen in the dist-upgrader?
[17:47] <seb128> or is that something users go to do some cleaning
[17:47] <arand> kees: I think I've done what I can on Bug #418135 . I'm not sure if my suggestion for the hardy patch is the best idea (eepecially since I only half-know what I'm doing), or what to do about dapper (does the bug even affect a server version)?
[17:49] <mathiaz> slangasek: re bug 424051 - I've added apport to the server seed in ubuntu.karmic. Is there anything else that shoud be done?
[17:51] <kirkland> soren: i did, i was going to work on that today
[17:51] <kirkland> pitti: hey, some users are complaining about the .face not being accessible in encrypted-home setups
[17:51] <slangasek> mathiaz: you can do an ubuntu-meta upload if you wish :)
[17:51] <kees> arand: yeah, I think that sounded like a reasonable approach.  I'll double-check it too.
[17:51] <kirkland> pitti: i have a suggestion how we could hack around this
[17:52] <pitti> kirkland: oh, indeed, and neither ~/.dmrc, I suppose (which has your default session)
[17:52] <mathiaz> slangasek: hm well - it doesn't need to be in the default install right *now*
[17:52] <kirkland> pitti: i see where debian/patches/09_gdmsetup.patch tries a few different locations
[17:52] <mathiaz> slangasek: so I'll rely on the next upload :)
[17:52] <slangasek> mathiaz: heh, ok
[17:53] <kirkland> pitti: i was going to add a check to look for it in /home/.ecryptfs/$USER/.face
[17:53] <kirkland> pitti: and modify the About Me thingy to copy .face there, if that dir exists
[17:53] <kirkland> pitti: what do you think?
[17:53] <pitti> kirkland: ah, great idea; same for ~/.dmrc?
[17:53] <kirkland> pitti: sure...  anything else?
[17:54] <kirkland> pitti: what reads/writes .dmrc ?
[17:54] <kirkland> pitti: i'm not familiar with that one at all
[17:54] <pitti> kirkland: gdm
[17:54] <kirkland> pitti: ah, okay
[17:54] <pitti> kirkland: it saves your default session type, keyboard layout, and language, i. e. the things you can change in gdm
[17:54] <kirkland> pitti: okay
[17:55] <kirkland> pitti: and where's the about-me code?  the thing that writes out .face ?
[17:55] <kirkland> pitti: gdm source as well?
[17:55] <seb128> kirkland, gnome-control-center
[17:55] <kirkland> seb128: thanks
[17:55] <pitti> ah, seb128 beat me to it, thanks
[18:12] <Magilum> Hey, is there a repository of all the updates in -security or in -updates in a given release cycle, or a repository of all (including past) SRU's? I'm doing research in dynamic software updating, and Ubuntu's updates over a release cycle seem like a great data source
[18:14] <kees> Magilum: deb archives are organized as pools, but you can get the lists of packages for a release in the "dists" subdirectory of the archive
[18:14] <kees> Magilum: e.g. http://archive.ubuntu.com/ubuntu/dists/hardy-security/
[18:14] <kees> see main/binary-i386/Packages* or main/source/Sources*
[18:15] <cjwatson> you can also mine data about update publishing out of Launchpad using its API
[18:15] <Magilum> kees: I mean more like the metadata, like the SRU's or equivalent document for -security uploads. Optimally, I'd like to see the reason for any particular update, rather than just the fact that an update happened.
[18:15] <cjwatson> http://help.launchpad.net/API  https://edge.launchpad.net/+apidoc
[18:16] <cjwatson> the only coherent and consistent descriptions of each update are (a) the changelog (b) any associated bugs
[18:16] <Magilum> cjwatson: That seems like a rather extreme solution... is there no other option?
[18:17] <cjwatson> Magilum: I'm not quite sure what you're after; personally I find the API is a very good way to get hold of data that nobody'd previously thought of presenting in the particular form I want, but in some cases of course there may be better presentations already available
[18:17] <cjwatson> you could also try the -changes mailing list archives on lists.ubuntu.com
[18:17] <cjwatson> they don't tell you about SRUs that failed validation though
[18:17] <cjwatson> or rather, they tell you about everything regardless of validation
[18:18] <Magilum> Okay, so a good source for the data I'm after about these updates is mining a package's changelog (which should have the bugs linked in it, right?) from launchpad?
[18:19] <kees> the -changes mailing list lacks -security updates, unfortunately.
[18:19] <Magilum> We're doing research in dynamic software updating; if you guys have heard of KSplice, that's an example of an implementation.
[18:19] <kees> Magilum: for -security the bugs aren't always listed, but the CVEs usually are.
[18:19] <Magilum> kees: Just as good, we just need to know what sort of patch it is.
[18:20] <cjwatson> for example, when I was preparing the change summary for 8.04.3, I used http://paste.ubuntu.com/268067/ and http://paste.ubuntu.com/268068/ to automate a lot of the work for me
[18:20] <cjwatson> pretty hacked-up but you can probably get the idea
[18:20] <Magilum> So is there no database of all completed SRU's?
[18:21] <cjwatson> that's what Launchpad's for
[18:21] <kees> SRUs are different, and will almost always have their bug #'s in the changelog
[18:21] <slangasek> kees: bug #426923
[18:21] <cjwatson> any source publication to -updates is a completed SRU or a security update
[18:21] <cjwatson> and you could look at the Distribution field of the changes file to determine which
[18:22] <slangasek> kees: did we find the one Ubuntu user who was affected by the bug?
[18:22] <kees> slangasek: dunno.  how can we start debugging their situations?
[18:24] <Magilum> So basically the only (or best) way of doing this is via launchpad's API?
[18:24] <cjwatson> it's not absolutely the only way, as there are exports of some of the data in various other places in various forms; but if you're looking for a database to query, LP is it
[18:25] <slangasek> kees: well for that case, I suppose 'debconf-show libpam-runtime' should tell us whether this was the reason he's now locked out
[18:25] <slangasek> kees: but of course he needs to get access to his system first
[18:26] <slangasek> we could tell him to look for a root shell listening on a high port
[18:26] <kees> ugh
[18:27] <slangasek> do we have a recovery mode howto somewhere?
[18:28] <kees> https://wiki.ubuntu.com/RecoveryMode
[18:28] <slangasek> awesomesauce
[18:29] <slangasek> oh, apparently you're on top of that bug
[18:33] <Magilum> cjwatson: What and where would those exports be?
[18:34] <cjwatson> the ad-hoc things we've mentioned, like the -changes mailing list, the security update web pages, etc.
[18:34] <cjwatson> and the archive itself although that only gives you things that are currently published not the history
[18:34] <Magilum> ah, okay.
[18:35] <cjwatson> perhaps the full changelog of each individual package
[18:35] <cjwatson> that kind of thing
[18:35] <Magilum> you don't have the older packages in the repository?
[18:35] <cjwatson> we don't really keep separate per-domain databases, it isn't economical
[18:35] <cjwatson> no, they get expired shortly after they've been superseded - the pool is enormous as it is
[18:35] <cjwatson> we only keep ones that are actually current in some Packages/Sources files
[18:35] <Magilum> Do they exist anywhere?
[18:36] <Magilum> I'm interested in seeing what in the code changed
[18:36] <cjwatson> they're archived in the Launchpad librarian, referenced from the Launchpad database, yes
[18:37] <Magilum> Alright, thanks.
[18:37] <cjwatson> that's the only place I'm aware of that archives everything (or close to everything; we have expired some old binary packages from releases that aren't supported any more, though not source packages)
[18:37] <Magilum> So the librarian doesn't have source packages?
[18:38] <kees> Magilum: LP keeps a debdiff between package versions, but that only started recently.
[18:38] <Magilum> kees: How recently?
[18:38] <cjwatson> the librarian has source packages, yes
[18:38] <cjwatson> you may have misread me if you think I said otherwise
[18:39] <cjwatson> my comment was "we have expired some old binary packages from releases that aren't supported any more, though [we have] not [expired any] source packages"
[18:39] <kees> Magilum: I think a little over a year
[18:39] <Magilum> Ahh, okay. thanks.
[18:39] <cjwatson> mm, the package diffs are not necessarily always between the pairs of packages you want, but yes, they can be useful
[18:39] <kees> right
[18:41] <Magilum> Ideally, I would have patches that laid out the growth of the program in a nice line, with metadata as to what each patch did
[18:41] <Magilum> I'm guessing the best thing to do would be to mine Launchpad and launchpad-librarian?
[18:41] <kees> Magilum: as an example, nss 3.12.3.1-0ubuntu0.9.04.1 is not longer available in binary form (a newer release was made) but the source is still available: https://launchpad.net/ubuntu/+source/nss/3.12.3.1-0ubuntu0.9.04.1
[18:41] <kees> Magilum: for that, check with james_w, he's been doing that with bzr trees that track each source package
[18:42] <Magilum> oh, that'd be fantastic.
[18:42] <Magilum> Are they public? james_w?
[18:42] <cjwatson> oh, yeah, that too
[18:43] <cjwatson> they're public, yes
[18:43] <cjwatson> https://code.launchpad.net/ubuntu/+source/<sourcepackagename>
[18:43] <cjwatson> not necessarily everything is imported there as yet - there are still some importer problems
[18:43] <cjwatson> but I think the coverage is now pretty good
[18:43] <Magilum> how long has that been going on?
[18:43] <slangasek> seems to still be about 50-50 odds on the packages I try to find branches for ;)
[18:43] <Magilum> how far back do they go, rather?
[18:44] <cjwatson> only for a few months, but he imported as much history as he could find from LP
[18:44] <cjwatson> so I would expect they'll go back as far as you need
[18:46] <Magilum> that's fantastic
[18:47] <Keybuk>  * Mounting securityfs on /sys/kernel/security...
[18:47] <Keybuk> mount: securityfs already mounted or /sys/kernel/security busy
[18:47] <Keybuk> mount: according to mtab, none is already mounted on /sys/kernel/security
[18:47] <Keybuk> 									 [fail]
[18:47] <Keybuk> kees: ^ OMG! THE SKY IS FALLING! THINGS ARE EXACTLY WHERE THEY SHOULD BE! ARGH!
[18:48] <Keybuk> :p
[18:48] <Keybuk> kees: could you set OGRA=n on that script? :)
[18:48] <Magilum> Do the branches have a single continuous history, or are they totally disjoint from the ones in other pools (if that's the right word). I notice there's a branch for $package in hardy, one for hardy-proposed, one for hardy-updates, etc
[18:52] <Keybuk> jcastro: you should so post that bootchart on twitter
[18:54] <jcastro> Keybuk: I didn't want to steal your thunder, feel free to post it yourself.
[18:54] <jcastro> but I can if you'd like
[18:55] <Keybuk> jcastro: it's better marketing if it's anecdotal
[18:55] <jcastro> he ok
[18:55] <Keybuk> besides, mine are better ;)
[18:55] <jcastro> heh
[18:55] <cjwatson> Magilum: they're supposed to have common history where appropriate
[18:56] <Magilum> cjwatson: Where would they be disjoint?
[18:56] <cjwatson> where the history is in fact disjoint :-)
[18:56] <cjwatson> sorry, I shouldn't have said "where appropriate", that was confusing
[18:56]  * cjwatson -> elsewhere
[19:00] <Magilum> AAhh, the bzr repo's james_w has are in 2a format.
[19:09] <kees> Keybuk: erm?
[19:10] <kees> Keybuk: oh, is /proc/mounts not listing it as securityfs?
[19:10] <kees>         if ! grep -q ^securityfs /proc/mounts ; then
[19:10] <kees>                 log_action_begin_msg "Mounting securityfs on ${SECURITYFS}"
[19:10] <kees>                 if ! mount -t securityfs securityfs "${SECURITYFS}"; then
[19:11] <kees> Keybuk: or rather, I assume it should be the 3rd column, not the first that is checked?
[19:12] <kirkland> pitti: okay, cool, .face fixed in gdm
[19:13] <kirkland> pitti: http://paste.ubuntu.com/268101/
[19:13] <kirkland> pitti: how do i test .dmrc ?
[19:13] <kirkland> pitti: i'm not familiar with it at all
[19:14] <superm1> kirkland, don't you just put it in your home directory and restart gdm?
[19:14] <kees> Keybuk: what would you recommend as the cleanest way to make sure a given fs is mounted in a particular location?
[19:14] <kirkland> superm1: right... but what the heck does .dmrc actually do?
[19:14] <kirkland> superm1: and how can i tell if its working or not
[19:15] <superm1> kirkland, defines the defaults for your user, keyboard, language and login session
[19:15] <superm1> (to override the system defaults for these things)
[19:15] <superm1> so if you want to make sure yours is being read, put a session in it that's different than the system's
[19:24] <jdstrand> Riddell: hi! are you planning an upload of qt4-x11 today? I plan to upload a fix for CVE-2009-2700
[19:25] <jdstrand> Riddell: http://qt.gitorious.org/qt/qt/commit/802d8c02eaa0aa9cd8d0c6cbd18cd814e6337bc6
[19:26] <kees> Keybuk: you can set ulimits in upstart service definitions, right?
[19:27] <ScottK> jdstrand: I think he's offline until tomorrow sometime.
[19:28] <kees> Keybuk: oh, nm, found it in http://upstart.ubuntu.com/wiki/Stanzas
[19:28] <jdstrand> I'll take that as a 'no' then :)
[19:28] <jdstrand> ScottK: thanks!
[19:32] <RainCT> Keybuk: Saying the PPA doesn't improve boot speed was a bad move, now there's no incentive to test it! :P
[19:34] <ScottK> There's still the thrill for the first reboot and waiting to see if it comes up or not.
[19:43] <soren> kirkland: Ok, good, didn't mean to pester you or anything. I had had mail issues on my shiny, new laptop, so I wasn̈́'t completely sure all my e-mail had gotten through.
[19:44] <kirkland> soren: no problemo
[19:44] <kirkland> soren: i reinstalled yesterday too
[19:45] <kirkland> soren: similarly, i didn't mean to pester you about getting started on that image either
[19:45] <kirkland> soren: i just wanted to make sure I wasn't making it more difficult than it needed to be
[19:45] <soren> kirkland: This time, I've added all my $HOME/.*rc files to bzr and added a Makefile that'll install all the packages I can't live without. Blowing this box away now shouldn't be too much of a problem.
[19:46] <kirkland> soren: that's really funny too... i've been carrying around the same $HOME/* since about edgy
[19:46] <soren> kirkland: I deliberaly don't do that.
[19:46] <kirkland> soren: just yesterday, i pruned *all* .*rc that I didn't recognize
[19:46] <kirkland> there was some cruft in there
[19:46] <kirkland> dustbunnies
[19:47] <kirkland> soren: as for testing this image ...
[19:47] <soren> Every time I acquire a new system, my $HOME gets more and more organised this way. I start out with a clean slate and only copy stuff over when I need it. After a while, I grab a full backup, and de- or recomission the machine.
[19:47] <kirkland> soren: it's trivial for me to do so in kvm
[19:48] <kirkland> soren: i can try to setup UEC here, if you tell me it's in better shape than last week, and worth trying an install now
[19:48] <soren> kirkland: I have an upload pending that should take care of a few things, actually.
[19:48] <jjohansen1> kirkland: well we have a karmic kernel that can be tested
[19:48] <kirkland> soren: cool, i'll look out for that
[19:49] <kirkland> jjohansen1: ah
[19:49] <soren> kirkland: Oh, I just looked. It's not something that should affect anything you need.
[19:49] <kirkland> soren: so i should use karmic's vm-builder to generate a jaunty amd64 image with alfresco
[19:50] <soren> kirkland: I'd use what's in bzr.
[19:50] <kirkland> soren: vmbuilder from bzr ?
[19:50] <kirkland> soren: you mean?
[19:50] <soren> kirkland: Yes.
[19:50] <kirkland> soren: hrm...
[19:50] <kirkland> soren: is that going to land in karmic?
[19:50] <soren> Yes.
[19:50] <kirkland> soren: eta on that?
[19:51] <pen1234> http://www.thaiadpoint.com/tap8.1/bin/redir.php?p=2042&l=1357&u_id=363435
[19:51] <kirkland> soren: i only ask for the sake of the reproduciblity of images
[19:54] <pen1234> http://www.thaiadpoint.com/tap8.1/bin/redir.php?p=2042&l=1357&u_id=363435
[19:58] <soren> kirkland: I doubt I'll have the time this week.
[19:59] <kirkland> soren: okay
[20:03] <donri> why is the software store needed, and why can't you use and help improve gnome-packagekit instead? how compatible will the software store be with the packagekit api? e.g. will it work with the pango and gstreamer plugins?
[20:17] <slangasek> mathiaz: thbbt, I'm uploading ubuntu-meta to get that FFe off my list :)
[20:17] <slangasek> mathiaz: well played :)
[20:19] <mvo> donri: PK can not use debconf, we would love to fix this, but it got not accepted upstream
[20:21] <donri> isn't debconf what interrupts installations to prompt for input?
[20:21] <mathiaz> slangasek: thanks! ;)
[20:27] <donri> isn't the upstream concern merely that all prompts should go before installations so that installations run uninterrupted? couldn't this be made to work with debconf?
[20:32] <slangasek> donri: no, it can't.
[20:33] <donri> i'm curious, why not?
[20:34] <slangasek> because debconf is used for communicating errors during package installs, and prompting in cases where we don't know prompts are needed until packages have started to be unpacked and installed.
[20:43] <kirkland> seb128: pitti: do either of you guys want to eyeball my patches to gdm and gnome-control-center for Bug #426724 ?
[20:43] <kirkland> seb128: pitti: i've tested that they "do the right thing"
[20:44] <kirkland> seb128: pitti: you guys might look at them from an upstreamable perspective, as I have no cred in the gnome world :-)
[20:44] <soren> slangasek: thbbt?
[20:44] <slangasek> soren: <raspberry_sound/>
[20:45] <soren> slangasek: Oh, it's an onomatopoieticon?
[20:45] <mneptok> thttpd?
[20:45] <slangasek> soren: yes
[20:45] <soren> twss
[20:45] <mneptok> !info thttpd
[20:46] <kirkland> pitti: seb128: http://paste.ubuntu.com/268159/
[20:46] <kirkland> pitti: seb128: http://paste.ubuntu.com/268160/
[20:46] <soren> slangasek: I would *never* have guessed :)
[20:46] <slangasek> mathiaz: well - I would be uploading ubuntu-meta, anyway, if the darn script noticed that the seed had changed
[20:47] <seb128> kirkland, open a bug and subscribe the sponsor team to it?
[20:47] <seb128> kirkland, it's late european time now, I'm busy with other things and pitti is away for the evening
[20:47] <kirkland> seb128: okay, you'd rather me do that than upload myself?
[20:47] <seb128> kirkland, I will have a look tomorrow morning
[20:48] <kirkland> seb128: cool, thanks
[20:48] <seb128> kirkland, well I would prefer to have changes upstream before being uploaded yes
[20:48] <seb128> otherwise nobody will upstream those later
[20:48] <kirkland> seb128: alright, i'll attach the two debdiff's to the bug then
[20:48] <seb128> thanks
[20:48] <kirkland> seb128: and subscribe you/pitti
[20:48] <kirkland> seb128: thank you ;-)
[20:53] <Keybuk> kees: well, firstly you should *not* do that
[20:53] <Keybuk> kees: you're wasting time, cpu, I/O, etc. during boot just to find out whether some other part of the boot worked or not
[20:53] <Keybuk> far better just to fail loudly as normal
[20:53] <Keybuk> mountall will already have mounted securityfs
[20:53] <fabrice_sp> kirkland, are you looking after FTBFS of pycryptopp ?
[20:53] <Keybuk> (and yes, you're reading the wrong field, field 1 can contain anything, field 3 is the type)
[20:54] <kirkland> fabrice_sp: no, sorry, no time
[20:54] <kees> Keybuk: so assume it's mounted and explode if it's not there?
[20:54] <Keybuk> exactly
[20:54] <fabrice_sp> I'll submit the debdiff then (it's the classical --install-layout python stuff)
[20:54] <kees> Keybuk: ok
[20:54] <Keybuk> I've got that converted to Upstart anyway
[20:54] <Keybuk> which does "start on filesystem", and filesystem checks for securityfs already
[20:54] <Keybuk> but it's worth saying ;)
[20:56] <kees> Keybuk: where does mountall.sh get its knowledge of securityfs's mount location?
[20:56] <Keybuk> kees: mountall is a binary in the Upstart source package in the ubuntu-boot PPA
[20:57] <kees> Keybuk: right, but if someone doesn't have ubuntu-boot...
[21:00] <Keybuk> they will don't worry
[21:04] <slangasek> mathiaz: oh, haha, there's no ubuntu-server metapackage
[21:05] <slangasek> mathiaz: so the bug is fixed, then
[21:07] <kirkland> soren: ping
[21:18] <kirkland> soren: http://paste.ubuntu.com/268172/
[21:27]  * popey pokes directhex with a friendly stick
[21:27] <kirkland> apw: around?
[21:27] <kirkland> apw: i talked to rtg last week about upping our /dev/loop* to something more reasoanble, say 32 or 64
[21:28] <kirkland> apw: he said he'd need to investigate the memory cost ... do you happen to know?
[21:28] <kirkland> apw: seems other distros set that a bit higher than our 8
[21:28] <kirkland> apw: and eucalyptus recommends 32, or it throws warnings in init
[21:29] <popey> directhex: libgconf2.0-cil appears to not exist in jaunty.. which is a problem for backporting tomboy 0.15.x suggestions?
[21:38] <bdmurray> slangasek: I wanted to add that a new package should have an apport package hook to the new package inclusion guidelines.  Does that seem reasonable?
[21:39] <slangasek> bdmurray: seems reasonable to me; those are guidelines for main though, aren't they? (so the domain of the MIR team)
[21:40] <bdmurray> slangasek: I was looking at https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage in particular
[21:40] <bdmurray> so not necessarily main
[21:42] <slangasek> bdmurray: ah, ok
[21:43] <slangasek> # Non-native packages must have verifiable cryptographic path to upstream source
[21:43]  * slangasek peers
[21:44] <slangasek> ok, I don't know what these rules are targeted at, then; that's certainly not something that gets checked as part of new processing
[21:46] <bdmurray> What documentation is refered to for new packages in universe then?
[21:59] <RainCT> mvo: Hey. You may be intersted in the last comment on http://bloc.eurion.net/archives/2009/how-to-help-with-package-screenshots/
[22:01] <mvo> RainCT: sweet, that sounds very nice
[22:01] <mvo> RainCT: I talked to him a while ago when I created the get-screenshot button in synaptic and he is just a incredible nice guy
[22:12] <rgreening> pitti: ping
[22:17] <directhex> popey, for jaunty... that sounds correct
[22:18] <directhex> popey, it was unneccessarily ABI-bumped
[22:18] <directhex> popey, change the dep to libgconf2.24-cil
[22:18] <popey> ahh
[22:18] <popey> thank you
[22:18] <soren> kirkland: ah, that again.
[22:18] <kirkland> soren: i worked around it, but hit a few more issues
[22:18] <kirkland> soren: 2 things i wanted to discuss
[22:19] <soren> kirkland: Ok.
[22:19] <kirkland> soren: before vmbuilder ...
[22:19] <kirkland> soren: kqemu ....
[22:19] <soren> Oh.
[22:19] <soren> kirkland: Ah, yes.
[22:19] <kirkland> soren: upstream qemu and kvm projects have both disabled it, noting that it's basically unsupported
[22:19] <kirkland> soren: we would need to configure that on to support it in Ubuntu
[22:19] <soren> kirkland: It's a shame, really. I'd like to keep it around (I happen to know that jdstrand uses it), but it would end up in main. :(
[22:19] <kirkland> soren: there's a few users complaining about this now
[22:20] <kirkland> soren: yeah, i'm on the fence
[22:20] <kirkland> soren: i don't guess i really mind it in universe
[22:20] <kirkland> soren: but in no way do we want to endorse it in main
[22:20] <kirkland> soren: when upstream is saying that it's unsupportable
[22:20] <soren> kirkland: ..but it would be in the same binary, right?
[22:20] <soren> No way to split it out.
[22:20] <soren> AFAIK.
[22:20] <kirkland> soren: right
[22:21] <kirkland> soren: we'd have to do a separate build, and spit out a different binary deb for universe
[22:21]  * jdstrand does use it
[22:21] <jdstrand> it is fairly flaky on karmic though
[22:22] <kirkland> jdstrand: oh?  how are you using it in karmic?
[22:22] <jdstrand> iirc I could have VMs with 384M of ram, but not 256 or 512
[22:22] <jdstrand> kirkland: I was using it in Dublin
[22:22] <kirkland> jdstrand: not through qemu-kvm, huh?
[22:22] <soren> Ok, just for kicks: Can some please calculate the HMAC_SHA1 with key "12345678901234567890" and data 0 (ASCII 0, not '0')? I have a document that says it should yield one value, but I'm getting another.
[22:23] <jdstrand> kirkland: I did use qemu-kvm once to test the libvirt/apparmor stuff
[22:23] <cjwatson> meh, why on earth is a watch file or get-orig-source a requirement in those "new package guidelines"?
[22:23] <jdstrand> (for kqemu)
[22:23] <cjwatson> rule of thumb: if something is only sporadically followed among the packages in main, making it a requirement for all new packages may not make sense :-P
[22:24] <cjwatson> bdmurray: I think what's happened is that the MOTU review practices have been borged into that page
[22:25] <cjwatson> bdmurray: archive admins doing new queue review are usually experienced enough that their own judgement is a pretty good set of guidelines in itself, and TBH I'd rather leave them to it most of the time, as long as we get the basic licensing checks done; if I were to point people at a set of guidelines, I'd use http://ftp-master.debian.org/REJECT-FAQ.html
[22:26] <kirkland> soren: okay, i suppose we ignore kqemu for now?
[22:26] <cjwatson> bdmurray: as for apport package hooks, it often makes sense, but not always - consider a command-line tool which simply filters its input in some way. There's really no sensible way to write an apport hook for such a thing
[22:26] <kirkland> jdstrand: i would not have expected kqemu to work at all with qemu-kvm ...
[22:27] <cjwatson> bdmurray: so there definitely needs to be discretion in there
[22:27] <kirkland> soren: okay, vmbuilder ... i'm hitting a few errors
[22:27] <kirkland> soren: i was able to change the parted calls to use "linux-swap(new)"
[22:27] <kirkland> soren: that seems to work
[22:27] <cjwatson> use (v1) please
[22:27] <kirkland> cjwatson: i saw some posts from you about this topic, actually
[22:27] <kirkland> cjwatson: hmm, (v1) didn't work ...
[22:27] <cjwatson> let me check if that patch is in place
[22:27] <jdstrand> kirkland: well, I was using it with libvirt, so I used "<domain type='kqemu'>" with <emulator>/usr/bin/qemu</emulator>
[22:28] <jdstrand> kirkland: at the time, it didn't blow apart
[22:28] <jdstrand> kirkland: I may have had a kqemu-source module laying around
[22:28] <kirkland> jdstrand: hrm, okay
[22:28] <cjwatson> oh, meh, it isn't!
[22:28] <cjwatson> you'll have to use (new) for now, yes
[22:28] <cjwatson> but expect that to change again in future; (new) will keep on working at least for a while
[22:28] <kirkland> cjwatson: okay, confirms what i saw
[22:29] <cjwatson> calling things "new" is bad design in general though, which is why I got it changed upstream
[22:29] <kirkland> cjwatson: i tried v1 first, then fell back to (new)
[22:29] <kirkland> cjwatson: oh, i agree, and support your quest ;-)
[22:29] <bdmurray> cjwatson: my intent is to modify the documentation so new packages will be aware of apport package hooks when making a new package.  I modified https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages but wanted something that stressed it more.
[22:30] <bdmurray> cjwatson: I realize it doesn't always make sense to have one
[22:30] <kirkland> soren: okay, so once i fix VMBuilder/disk.py to use linux-swap(new) ... the install proceeds
[22:30] <cjwatson> bdmurray: that's fine, I just don't want us to go too far the other way and end up with a bunch of silly apport hooks that do very little of any use. It's probably only really an issue when the package is likely to get a lot of bugs
[22:30] <kirkland> soren: then blows up at bootloader installation
[22:30] <cjwatson> or a lot of hard-to-diagnose bugs
[22:31] <kirkland> cjwatson: btw, i don't know that I'm going to have time to fix grub2 to install onto each disk in a raid
[22:31] <jdstrand> bdmurray: fyi, the apport report is in the usual place
[22:31] <kirkland> cjwatson: at least, not without a few pointers
[22:34] <cjwatson> kirkland: I was under the impression that that was on my plate
[22:34] <mathiaz> cr3: hey - reviewing your apport merge proposal
[22:34] <kirkland> cjwatson: oh, good, i thought you thought i was fixing that
[22:34] <mathiaz> cr3: isn't the apport support a new feature?
[22:35] <kirkland> cjwatson: thanks, i haven't filed a bug yet ... i'll do that now (unless there's already one)
[22:35] <mathiaz> cr3: hm - s/apport/checkbox merge proposal/
[22:35] <cr3> mathiaz: nope, it was added before ff. I just improved it following complaints :)
[22:36] <cjwatson> kirkland: go ahead
[22:37] <soren> kirkland: Ah, yes, the grub2 thing.
[22:37] <kirkland> soren: do you have a fix for this too?
[22:37] <soren> kirkland: I do not, unfortunately.
[22:37] <jdstrand> soren, kirkland: zul was working on that at one point
[22:37] <kirkland> soren: a work around?
[22:37] <soren> kirkland: For different reasons, I will have to find a fix for it tomorrow.
[22:38] <soren> kirkland: Install grub1? :)
[22:38] <jdstrand> I do not know the status
[22:38] <mathiaz> cr3: same question for the dmi detection
[22:38] <mathiaz> cr3: it seems that this two things add a lot of new code
[22:39] <cr3> mathiaz: dmi was there as requested by launchpad, but it didn't work unfortunately and I couldn't fix it before ff
[22:42] <mathiaz> cr3: and what about apport symptoms support?
[22:42] <kirkland> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/427048
[22:43] <kirkland> cjwatson: i filed against grub2, assigned it your way, triaged it, and targeted at alpha6
[22:43] <kirkland> cjwatson: sorry if any of that is inaccurate
[22:43] <kirkland> soren: i don't see a grub1/2 toggle in vmbuilder :-)
[22:44] <cjwatson> kirkland: that's fine although a6 might be ambitious
[22:45] <kirkland> cjwatson: okay, retarget for beta?
[22:45] <kirkland> cjwatson: i'll leave that to your discretion
[22:45] <cr3> mathiaz: I was hoping that could be considered a bug against checkbox reporting irrelevant bugs
[22:45] <kirkland> cjwatson: i just wanted to make sure it was milestoned, assuming that was okay by you
[22:46] <cr3> mathiaz: however, we could consider that a feature and I could go through the ffe process if that would make you feel more comfortable
[22:46] <cjwatson> kirkland: leave it be for now; sure
[22:48] <soren> kirkland: That's what I'll add tomorrow. :)
[22:48] <kirkland> soren: okay, cool, i'll fix other stuff in the mean time
[22:48] <soren> kirkland: well... Not really. I'll just fix it, so that things Just Work[tm].
[22:48] <kirkland> soren: cheers ;-)
[22:48] <mathiaz> cr3: IIUC the workaround that bdmurray introduced in the previous upload was fixed?
[22:48] <mathiaz> cr3: ie not reporting agains the linux package?
[22:50] <cr3> mathiaz: yep
[22:51] <cr3> mathiaz: ie, if there's no corresponding package and there's no corresponding symptom, then don't report a bug
[22:51] <cr3> mathiaz: I will be revising all the tests later to make sure that a relevant package is assigned to each test so that bugs can be reported for each test
[22:52] <cr3> mathiaz: I need to jet, but I'll be back online later. thanks for looking into my merge request!
[23:26]  * slangasek chuckles at bug #400222
[23:33] <RainCT> how can I fix my install if ~ubuntu-boot/+archive/staging is evil? apt-get inside chroot from Live USB?
[23:34] <slangasek> https://wiki.ubuntu.com/RecoveryMode?
[23:34] <slangasek> what kind of evil was it?
[23:35] <RainCT> slangasek: Haven't tried it yet, asking just in case (I need my laptop tomorrow morning).
[23:35] <slangasek> heh
[23:40] <RainCT> btw, any idea when the diff stuff for 'aptitude update' will land?
[23:48] <mathiaz> mdz: re bug 194140 - should I assign it to mvo?
[23:55] <mrooney|w> is there anywhere to track the number of language packs on the default ISO over past releases of Ubuntu?
[23:56] <mrooney|w> more specifically I'm trying to figure out the total size consumed by langpacks on the ISOs over time
[23:57] <slangasek> the number installed can be extracted from the .manifest files accompanying the ISOs
[23:57] <slangasek> on releases.u.c and old-images.u.c
[23:57] <slangasek> sorry, old-releases.u.c
[23:59] <mrooney|w> slangasek: excellent, thanks