[00:00] <_cooper_> Hi.
[00:02] <_cooper_> I'm about to generate an ubuntu package and found in the PackagingGuide how to name the package.
[00:02] <_cooper_> The guide says:
[00:02] <_cooper_> "If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.1.1-1 package was changed by Ubuntu, the version string would be 2.1.1-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.1.1-0ubuntu1)."
[00:03] <savvas> _cooper_: I think this is more of a #ubuntu-motu question :)
[00:03] <savvas> (when you ask the question, that is :P)
[00:05] <_cooper_> 'kay, thanks for the pointer.
[00:30] <evolio> hi there, is jaunty going to have a new theme? has that been decided?
[00:32] <directhex> who's on archive admin duty?
[00:32] <persia> directhex, https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[00:33] <directhex> Riddell, did you just slash the NEW queue to ribbons?
[00:33] <persia> I think you hit a gap, as it's no longer Tuesday in UTC+0, but it's not yet Wednesday in UTC-6
[00:34] <directhex> persia, looking for context on a contextless REJECT
[00:35] <StevenK> Ah, that's the if uploader == directhex check ...
[00:35]  * StevenK hides
[00:35] <directhex> StevenK, damn, i thought only the debian cabal had that
[00:36] <directhex> well, they say a true genius is never appreciated in his own time...
[00:36] <ScottK> Unfortunately the ubuntu-archive list archive is lagging badly.
[00:36] <persia> I suspect it's the abovementioned slowness of the list server.  I'm not seeing context for REJECTs that I *know* were sent (because I received other copies).
[00:36] <ScottK> Yes.  I know because I don't see one I sent.
[00:37] <ScottK> ... and you were sent a copy of ...
[00:37] <StevenK> directhex: Exercise patience, I doubt it was contextless
[00:37] <persia> And that is 9 hours old.
[00:37] <ScottK> Yep.
[00:38] <directhex> StevenK, james_w got the reject message, and was asking ME if i knew context, so unless there's a follow-up lagging someplace
[01:02] <pochu> slangasek: what do I need to get an UI freeze exception for bug 328606? :)
[01:13] <Amaranth> pochu: how is that a UI freeze exception?
[01:13] <Amaranth> pochu: you have to get an exception to fix "the UI accidentally broke"?
[01:14] <pochu> Amaranth: don't ask me, I'm the one who thinks it's a bug fix
[01:14] <pochu> but some people seem to disagree
[01:15] <TheMuso> c
[01:36] <ScottK> Amaranth: It's more U/I doesn't work so well because someone changed the rules without much notice.
[01:37] <ScottK> Pretty well amounts to the same thing, but there's no accident involved.
[01:43] <slangasek> pochu: doesn't look to me like anything that needs a UI exception.
[01:43] <slangasek> pochu: who was saying otherwise?
[02:00] <ScottK> slangasek: Does U/I freeze actually apply to Universe (or at least the unseeded parts of Universe)?
[02:00] <ScottK> Since the docs/translations teams don't (AFAIK) support those packages, I'm not sure what point it would serve.
[02:01] <slangasek> ScottK: I don't think it should apply, and wasn't considering it to apply
[02:02] <ScottK> Right, I just don't think our docs actually say that.
[02:02] <ScottK> (that it doesn't apply)
[02:02]  * ScottK looks
[02:04] <ScottK> slangasek: https://wiki.ubuntu.com/UserInterfaceFreeze includes "all user-visible strings in applications", which one might well think inludes Universe.
[02:05] <slangasek> ScottK: I'm happy to have that amended, though perhaps we should check with the doc team (mdke?) first to make sure that's consistent with their expectations
[02:06] <ScottK> mdke: Would adding "...  which are installed by default" to that cause any issues for you?
[02:06] <ScottK> It uses that construction earlier in the page.
[04:35] <TheMuso> persia: Do you happen to be around now?
[04:37] <TheMuso> slangasek: Got an install problem with studio disks, testing on amd64 but will likely affect i386 since its arch independant, a weird conflict issue with ubuntustudio-sounds and gnome-audio, working out how to address this, but likely enough a seed addition to blacklist gnome-audio will be enough.
[04:42] <TheMuso> persia: never mind, worked around it.
[04:43] <TheMuso> slangasek: If you could respin studio when you get a chance, that would be appreciated, fixed the problem in our seeds, which doesn't require an ubuntustudio-meta upload.
[05:09] <TheMuso> 666/
[05:12] <LaserJock> yikes
[05:12]  * LaserJock wonders what window TheMuso was heading to :-)
[05:14] <slangasek> TheMuso: respinning
[05:14] <TheMuso> slangasek: thanks
[05:15] <TheMuso> LaserJock: lol
[05:16] <Amaranth> LaserJock: The channel which must not be named, of course
[05:22] <slangasek> TheMuso: and build done
[05:23] <TheMuso> slangasek: thanks again.
[05:37] <persia> TheMuso, just back.  You know that germinate doesn't enforce blacklisting for tasks or meta, right?  I'm not sure just blacklisting will work without either adding a Provides: to ubuntustudio-sounds, or extending the Recommends for pulseaudio-module-x11
[05:37] <TheMuso> persia: well gnome-audio is no longer on the disk so...
[05:39] <persia> Hrm.  Odd.  I remember a similar issue with xfce-panel and MID where it kept showing up.  Anyway, if it works, it works.
[05:39] <TheMuso> yeah
[06:19] <TheMuso> persia: well the seed change I made fixed the problem to the point where the disk is installing.
[06:20] <persia> Excellent.  That's enough for alpha.  It's probably worth trying a Desktop -> Studio crossgrade at some point to make sure that still works.  I'll see if I can do that this evening.
[06:21] <TheMuso> ok
[07:06] <dholbach> good morning
[07:17] <mdke> ScottK2, slangasek: that sounds like it should be ok although I think we do have some documentation for the occasional universe package which would be affected if UI strings were changed late, From a quick review it's quite rare though
[07:17] <pitti> Good morning
[07:51] <Amaranth> $ ls -lh /var/log/syslog
[07:51] <Amaranth> -rw-r----- 1 syslog adm 329M 2009-03-11 02:50 /var/log/syslog
[07:51] <Amaranth> can we make pulseaudio shutup already? :/
[08:12] <pitti> Amaranth: can you please file a bug against pulseaudio for that, with some excerpts from the log?}
[08:12] <pitti> and maybe discuss with TheMuso
[08:13] <Amaranth> yeah, doing that now
[08:13] <pitti> certainly sounds worth fixing
[08:13] <Amaranth> Mar 10 10:33:32 ronin pulseaudio[3715]: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 13835058055252444064 bytes (418293347931 ms) Most likely this is a Linux bug. Please report this issue to the ALSA developers.
[08:13] <Amaranth> oops, didn't mean to paste that here
[08:14] <pitti> well, it's fine, just one line :)
[08:14] <Amaranth> it's that over and over and I though crimsun uploaded a fix for it already
[08:18] <Amaranth> ah, it's actually bug 340784
[08:18]  * Amaranth adds a comment
[08:21] <Amaranth> looks like this actually may have already been fixed, the messages stopped right around the time I remember pulseaudio dying and having to restart it
[08:22] <Amaranth> TheMuso: Thank you for making pulseaudio shutup about alsa :)
[08:22] <Amaranth> or whoever did it
[08:22]  * Amaranth &
[08:23] <tkamppeter> pitti, there is still a CUPS SRU for Intrepid which you did not put into -proposed
[08:25] <seb128> slomo: are you there?
[08:36] <slomo> seb128: yes
[08:39] <seb128> slomo: see #ubuntu-desktop log ;-)
[08:49] <pitti> tkamppeter: oh, I see; added to my TODO list, thanks for the poke
[08:50] <tkamppeter> pitti, thanks, this is already waiting for 6 weeks.
[08:50] <KaiL> ..am I the only one, who needs to give gconf a kick from time to time?
[09:03] <Keybuk> lool: it didn't so much as drop it
[09:03] <Keybuk> it was an Ubuntu patch that upstream rejected
[09:03] <Keybuk> just use -q/--quiet instead, that's fixed now
[09:07] <pitti> mvo: I like the current update-manager version number
[09:07] <pitti> 1:0.100.1, is that really still decimal? :-)
[09:08] <directhex> pitti, that version number sucks. there's only one awesome version number in ubuntu, and it's 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2
[09:09] <pitti> mvo: will the next version be 1:0.101.0?
[09:09] <pitti> directhex: yeah, "how to encode the changelog into a version number"
[09:09] <seb128> slangasek: is now still a good time to do uploads? ;-)
[09:09] <directhex> AKA "epochs hurt"
[09:10] <DktrKranz> I hope they don't change their mind again, it can be hard to manage 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2+reallyreally9.0.120.0ubuntu1
[09:13]  * pitti eyes at stgraber .. MirrorKit..
[09:19] <mvo> pitti: I like it too and your idea as well, I think I will switch to this schema
[09:25] <lool> Keybuk: Problem is that it breaks packages which used that
[09:25] <lool> Keybuk: Like powernowd -- which is still installed on most systems
[09:25] <Keybuk> lool: powernowd isn't seeded anymore?
[09:25] <Keybuk> you just need to merge the seeds
[09:26] <Keybuk> I have "remove powernowd from the archive" on my todo list
[09:26] <lool> Keybuk: It's not seeded but it remains installed on upgrades...
[09:26] <Keybuk> lool: didn't you use update-manager? :p
[09:26] <Keybuk> also the modules powernowd tries to load are all compiled into the kernel now
[09:26] <lool> Keybuk: Would update-manager have removed it?
[09:26] <Keybuk> lool: should have done
[09:27] <lool> I used aptitude
[09:27] <Keybuk> I've been grepping the archive to make sure nothing uses -Q
[09:27] <Keybuk> only a few ubuntu-specific things did
[09:27] <lool> Ok, and these are fixed but you missed powernowd?
[09:29] <Keybuk> I deliberately ignored powernowd, since it's going away ;)
[09:29] <lool> Keybuk: Did you also use the occasion to grep for /sbin/lsmod.
[09:29] <Keybuk> lool: no, that one's a simple packaging error
[09:30] <lool> Keybuk: powernowd and acpid -- which we want to get rid off too -- are using it
[09:30] <Keybuk> it should be in /bin
[09:30] <lool> Keybuk: Some programs hardcode it
[09:30] <Keybuk> lool: I couldn't find any reference to modprobe in acpid?
[09:30] <lool> Keybuk: /sbin/lsmod
[09:30] <Keybuk> oh
[09:30] <Keybuk> like I said
[09:30] <Keybuk> that's just a packaging error
[09:30] <Keybuk> lsmod's always been in /bin in Debian/Ubuntu
[09:30] <Keybuk> I hadn't noticed it was in sbin upstream
[09:31] <lool> Keybuk: The other way around I think
[09:31] <soren> ?
[09:31] <cjwatson> I think it was moved intentionally in Debian since /sbin isn't on the default path there
[09:31] <lool> Keybuk: What I'm saying is that packages are hardcoding /sbin/lsmod and they break with the move
[09:31] <soren> We want to get rid of acpi?
[09:31] <soren> acpid, I mean?
[09:31] <cjwatson> but in any case packages should not hardcode the paths to executables
[09:31] <lool> soren: Yes, do you need it?
[09:31] <soren> lool: Err.. yes?
[09:31] <Keybuk> lool: yes
[09:31] <Keybuk> lool: and I'm saying the move was an accident
[09:31] <Keybuk> lool: and I've already got a package to fix that
[09:31] <lool> Keybuk: Oh it's an accident in the last upload which you'll revert
[09:32] <Keybuk>  like I said
[09:32] <Keybuk>  that's just a packaging error
[09:32] <Keybuk> ;)
[09:32] <soren> lool: Unless you've got something else that will shut down my system when it receives and acpi shutdown event?
[09:32] <lool> Keybuk: I thought it was an ancient packaging error which you corrected in the last upload
[09:32] <Keybuk> oh, no ;)
[09:32] <lool> soren: Well on the desktop we have hal-hooked-up stuff
[09:32] <soren> lool: Good for you :)
[09:33]  * mvo is deeply anoyed by pycentral telling him there is no Python-Versions field in the package when there clerly is one 
[09:33] <lool> Keybuk: Ok, good too hear lsmod will move back after A6 then,
[09:33] <Keybuk> lool: I decided to go with a symlink
[09:34] <Keybuk> on the basis that since /sbin/lsmod is the upstream locations, other things might be hard-coding that
[09:34] <lool> Keybuk: That's what I'd have suggested too
[09:34] <soren> lool: Oh, so by "get rid of" you just mean "stop seeding on the desktop"?
[09:35] <soren> lool: Not as in "removing from the archive", which seems to be what Keybuk meant wrt. powernowd.
[09:35] <lool> soren: Actually yes, after discussing it with you I remembered it's only for desktops that it was question of droppin git
[09:35] <Keybuk> lool: I have that backwards, don't I :)
[09:35] <Keybuk> /sbin/lsmod is the traditional Debian/Ubuntu location
[09:35] <lool> /lib/udev/rules.d/85-regulatory.rules:KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/"
[09:35] <Keybuk> but /bin/lsmod is the upstream location
[09:35] <lool> hmpf :-(
[09:36] <soren> lool: Ok, no worries then :)
[09:36] <Keybuk> lool: ?
[09:36] <amitk> lool: be careful what you write -"droppin git" will cause you many enemies in the kernel team :-p
[09:37] <lool> soren: I'm actually happy that we'll keep it somewhere cause I spent some time cleaning it up and was sad that this was being dropped and hence my work wouldn't be that useful  :-)
[09:37] <lool> amitk: Yeah, I almost wrote a joke about git after it
[09:38] <lool> bryce: So 60x11-localhost broke login for me
[09:38] <lool> bryce: startx returns me to the console; if I move the file away it doesn't anymore
[09:38] <soren> lool: :)
[09:38] <bryce> lool: update to u15
[09:38] <Keybuk> wel
[09:38] <lool> bryce: Ok, sorry and thanks
[09:39] <Keybuk> why don't we just run gnome-power-manager on servers?
[09:39] <amitk> lool: we're not affected by git jokes, we just point to bzr vs. speed :)
[09:39] <Keybuk> or a headless equivalent?
[09:39] <bryce> lool: no prob, we can blame redhat (bashism vs. dashism)
[09:39] <lool> Keybuk: There was no headless equivalent until recently; devicekitpower might change that though
[09:39] <Keybuk> lool: DK-power only replaces the HAL bit
[09:39] <Keybuk> you need a policy agent to make the decisions
[09:40] <mvo> could someone with knowledge about initramfs-tools please review my patch for #338563 ?
[09:40] <Keybuk> mvo: looks sensible
[09:41] <mvo> thanks Keybuk
[09:43] <bryce> night
[09:44] <Keybuk> bryce: morning
[09:48] <davmor2> Guys I just completed a 64bit Ubuntu install from netboot mini.iso and am greeted with a nice little window that says....  Kerneloops-ui  Your system had a kernel failure
[09:51] <lool> Archive admins: python-protobuf disappeared from the archive: it used to be in universe and was being promoted to main, then disappeared
[09:52] <lool> I don't see it in rmadison in jaunty anymore
[09:53] <pochu> slangasek: I think the dx team thought they needed UI freeze exceptions, but I may be wrong
[09:54] <pochu> slangasek: at least they tagged the bugs with 'uif-jaunty'
[10:10] <tkamppeter> Any Python expert here? It is about bugs like bug 335543, a Python app does not find a certain Python library (saying "ImportError in <module>()") but the library is installed. Reinstalling the library helps. This does not only happen to Jockey but also to hal_lpadmin, the system-config-printer tray applet, ... What is the problem here?
[10:13] <DktrKranz> tkamppeter: it's probably not transitioned for Python 2.6, a rebuild could fix it.
[10:15] <DktrKranz> tkamppeter: I mean x-kit
[10:18] <tkamppeter> DktrKranz: In the mentioned case a reinstall of the existing library package even helps (no rebuild of the package). Can it be that the postinstall scripts of all Python libraries need to get re-run after Python 2.6 installation? This should be automated in the update process.
[10:19] <seb128> mvo is looking to similar issues
[10:19] <mvo> tkamppeter: it looks like bug(s) in python-central
[10:20] <mvo> tkamppeter: seb128 has a similar issue with bzrtools
[10:20] <DktrKranz> tkamppeter: python-central has some links, probably new python version modified them a bit, so it can't find Python module anymore until a new installation is performed.
[10:21] <seb128> I got things screwed after cleaning python2.4 yesterday
[10:25] <tkamppeter> mvo, DktrKranz, perhaps you should move bug 335543 to python-central then.
[10:30] <dholbach> ara: are the "move files around" changes in ldtp in debian already?
[10:30] <pitti> slangasek: for planning, gnome-themes-ubuntu_0.1_all.deb (which we need to add) is 279 kB
[10:31] <ara> dholbach: no, but I talked with the debian maintainer and he's going to accept the changes
[10:31] <pitti> slangasek: that's about the size I recently removed from gnome-themes, so I don't need to have a too bad conscience
[10:32] <dholbach> ara: is that going to be part of 1.5.1-1?
[10:32] <dholbach> the thing is: if files move from one package to the other, we need a conflicts/replaces (<< old version) - if we want syncability it'd be nice if we'd have the same versions in the conflicts/replaces
[10:34] <ScottK> dholbach: I wanted to mention that I think your idea about more, short MOTU training sessions is a good one.
[10:35] <dholbach> ScottK: excellent - I was planning to wait a bit longer until everybody had read the proposal and then send a mail to all the people who said "sounds good - count me in" to get planning
[10:36] <ScottK> dholbach: Please note there was a distinct lack of 'count me in'.  My Ubuntu time is getting somewhat more limited, so I really can't take on new tasks currently.
[10:36] <dholbach> ScottK: that's completely fine :)
[10:37] <dholbach> I was happy with the feedback I got on the blog post - sounds like this is a more sustainable model. :)
[10:37] <ara> dholbach: then, you could accept michael's debdiff, that does not include that change, I will send my changes to debian instead. those are not as urgent, but the new upstream version is :)
[10:38] <ara> dholbach: the only change i do not agree with michael is that he changed site-packages to dist-packages, I would put *-packages, as ldtp can work with python2.5 as well
[10:39] <dholbach> ara: OK, if Kartik makes those changes in 1.5.1-1 and uses a   Conflicts/Replaces: ldtp (<< 1.5.1-1)   I guess we should be fine with our changes in 1.5.1-0ubuntu1
[10:40] <dholbach> ara: I personally am fine with both, you decide
[10:42] <ara> dholbach: OK, then you can go ahead, as he already accepted the changes (informally). thanks for your help :)
[10:44] <dholbach> ara: hum... does he have that package available somewhere? it'd be nice if we could just sync it instead of me guessing and hoping that the changes are going to be equivalent. my concern is the versioned conflicts/replaces - if we pick different version numbers there, we'll have to maintain that diff for another few releases
[10:46] <ara> dholbach: :-) then, again, just use the michael's version, really (with the python2*/*-packages changes...)
[10:46] <ara> dholbach: really, the other changes are not that urgent
[10:46] <ara> dholbach: we can wait for debian
[10:47] <dholbach> ara: can you please talk to Kartik and make sure that he uses (<< 1.5.1-1) in the conflicts/replaces? :-)
[10:47] <ara> dholbach: if they are not in jaunty... that's not a problem
[10:47] <ara> dholbach: sure, will do :)
[10:47] <dholbach> ara: gracias
[10:47] <ara> dholbach: danke to you :D
[10:47] <pitti> mvo: hm, the task <-> assignee mapping in bug 35876 looks backwards to me
[10:49] <dholbach> ara: de nada :)
[10:49] <pitti> mvo: realistically I don't think we'll be able to generally fix this in metacity; I just corrected the upstream bug link for metacity
[10:49] <pitti> mvo: for a local solution, do you think the progress window should just never receive focus? or at least focus_on_map false or so?
[10:57] <dholbach> ara: done
[10:58] <ara> dholbach: danke!
[11:01] <doko> pitti: can we promote icedtea-6-jre-cacao to main? I'd like to have it for arm and powerpc.
[11:02] <bigon> infinity: hi, do you know how often the chroots are cleaned up on buildd?
[11:12] <pitti> doko: sure; done
[11:12] <doko> pitti: thanks
[11:12] <pitti> doko: btw, is the cacao source still relevant with this?
[11:13] <pitti> doko: it's already in main
[11:13] <pitti> (icedtea-6-jre-cacao I mean)
[11:13] <doko> pitti: no, not exactly, because openjdk has a copy of the cacao source again (cacao is still in universe)
[11:13] <pitti> doko: right, I meant if the cacao-oj6 is now redundant and should be removed
[11:13] <doko> pitti: but now we can remove the cacao-oj6 package
[11:14] <pitti> doko: lp-remove-package.py -u pitti -m 'cacao now built from openjdk-6 source' cacao-oj6
[11:14] <pitti> doko: does that sound correct?
[11:14] <pitti> doko: as a rationale?
[11:15] <doko> pitti: sounds ok
[11:15]  * pitti makes a flushing noise
[11:17] <doko> tkamppeter: it doesn't make sense to refer to a discussion on irc without including or summarizing it ...
[11:22] <tkamppeter> doko, added.
[11:27] <lamont> bigon: how do you mean "cleaned up"?  the chroot is freshly unpacked from a clean tarball every build, and dist-upgraded.  the tarball is freshened "from time to time" (manually)
[11:28] <cjwatson> lamont: he's asking about the latter, because python2.5-minimal is still there and can go away now
[11:28] <cjwatson> a dist-upgrade won't do that
[11:28] <lamont> cjwatson: right
[11:28] <doko> tkamppeter: why should it be a python-central error, if the usb module cannot be imported, which is managed by python-support?
[11:29] <doko> DktrKranz: ^^^
[11:29] <doko> mvo: ^^^
[11:30] <seb128> doko: speaking about python error apt-get autoremove cleaning python2.4 yesterday on my install and since bzrtools is broken
[11:30] <seb128> doko: ie
[11:30] <seb128>  LC_ALL=C ls /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzr*
[11:30] <seb128> ls: cannot access /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzr*: No such file or directory
[11:31] <doko> seb128: bug report?
[11:31] <rmcbride> doko: pitti: python-protobuf seems to have disappeared from Jaunty. Could this be related to the MIR for protobuf that got promoted yesterday?
[11:31] <tkamppeter> doko, see IRC discussion, bug 335543
[11:32] <seb128> doko: what would be useful as extra infos in a bug report?
[11:32] <seb128> doko: I think mvo was investigating but I will open a bug if he doesn't
[11:32] <cjwatson> I've filed an RT ticket to have the buildd chroots refreshed, at lamont's suggestion
[11:32] <bigon> lamont: well there are some package left behind (like python2.5-minimal) that make some pkg FTBFS
[11:36] <doko> tkamppeter: what does this have to do with 291035?
[11:37] <mvo> doko: I was refering to the problems that tkamppeter described and a issues that seb128 had with bzrtools. I don't know about usb modules
[11:38] <tkamppeter> bug 291035 is also an ImportError which was reported recently (not very well done by the reporter, he hijacked an old, closed bug) and is also an ImportError, looks like his problem was also triggered by Python 2.6.
[11:39] <tkamppeter> It has nothing to do with hal-cups-utils (the package correctly requires python-usb) and also not with the case that python-usb is a USB library.
[11:42] <cjwatson> bigon: if packages break with it, they probably ought to use Build-Conflicts?
[11:43] <bigon> cjwatson: actually the pkg will ftbfs with all python*-minimal as it need the std lib
[11:43] <bigon> and the minimal doesn't provide that
[11:44] <cjwatson> bigon: err, surely that means that it needs to build-depend on the appropriate extra packages, not that -minimal breaks it
[11:44] <cjwatson> sounds like your package is just broken
[11:47] <bigon> cjwatson: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474053 << actually it's that problem
[11:48] <cjwatson> bigon: but that bug does not affect build-dependencies. You should build-depend on what you need
[11:49] <cjwatson> that bug is about where the executable is located (and is a bit debatable anyway; I would be inclined to say that we should not change that in Ubuntu, although it's up to doko) and that cannot possibly affect build-dependencies
[11:50] <bigon> the thing it's that the configure takes the smaller version of python, py2.6 is actually pulled but like py2.5 from python minimal is already there it takes that one
[11:52] <doko> bigon: renaming doesn't make much sense. both are pulled, because the -minimal packages recommend the "complete" one
[11:53] <Keybuk> seb128: I think I fixed the bootchart bug
[11:53] <Keybuk> at least, it's far more reliable for me now
[11:55] <MacSlow> seb128, hey there
[11:56] <MacSlow> seb128, today is actually allocated to squash some bugs on notify-osd :)
[11:56] <MacSlow> seb128, I'll see how much I can fix
[11:57] <dholbach> MacSlow: crashers first!
[11:57] <dholbach> :-)
[11:57] <MacSlow> dholbach, I know :)
[11:57] <cjwatson> bigon: "takes the least version of python" seems like a rather odd thing to do ...
[12:03] <bigon> I don't know why it's done like that..
[12:03] <mvo> pitti: looking at the bug now
[12:04] <bigon> doko: recommended pkg are not pulled on buildd
[12:05] <doko> bigon: is python2.5-minimal still installed on the buildd?
[12:05] <bigon> doko: yep
[12:06] <doko> infinity: ^^^ could this be fixed/removed please?
[12:07] <cjwatson> doko: I filed an RT ticket for this already
[12:07] <doko> ok, thanks
[12:08] <bigon> cjwatson: do you have the url of that ticket?
[12:08] <cjwatson> the relevant RT system is internal so it won't help you
[12:09] <cjwatson> I'll let you know when it's done
[12:09] <bigon> ok thx
[12:11] <ogra> Keybuk, is it normal that i dont have any hwclock initscripts at all anymore ? (i still think the babbage passwd thing is related to clock issues, especially since my hwclock is at 01-01-1970)
[12:16] <cjwatson> ogra: the kernel is supposed to sync the system clock from the hardware clock itself nowadays. If this isn't working here, that could well be the sort of thing that's quite architecture-specific
[12:16] <ogra> right
[12:16] <cjwatson> ogra: though if the hardware clock is wrong, then the hwclock init scripts wouldn't have made any difference anyway :)
[12:16] <ogra> and i see on my x86 laptop that pw expiry is set to 13979
[12:16] <ogra> days
[12:17] <cjwatson> is it possible that you have multiple rtc devices, only some of which actually work?
[12:17] <Keybuk> ogra: my hardware clock looks generally right to me
[12:17] <ogra> no, only one and that works if i call hwclock manually
[12:17] <Keybuk> ogra: run /sbin/hwclock --show
[12:17] <ogra> Keybuk, i ran sudo hwclock
[12:17] <ogra> and now ran sudo hwclock --systohc and rebooted
[12:18] <ogra> which makes everything function correctly
[12:18] <ogra> i have ttys
[12:18] <cjwatson> the kernel's supposed to sync it on shutdown too ...
[12:18] <Keybuk> cjwatson: no it's not
[12:18] <ogra> and it depends
[12:18] <cjwatson> do I misremember?
[12:18] <cjwatson> ok
[12:18] <ogra> from where would it sync it
[12:18] <Keybuk> there was an init script on shutdown to do that
[12:18] <ogra> i.e. if i dont have network attached ...
[12:19] <ogra> it wouldnt getr a correct time at all
[12:19] <cjwatson> well, the obvious answer is "the system clock". but if I've misremembered and it doesn't, then the question is moot.
[12:19] <Keybuk> hah
[12:20] <ogra> in any case 13979 days from 01 01 1970 definately is expired :)
[12:20] <cjwatson> presence of the network is a red herring here; that is only relevant for setting the system clock, usually rather later
[12:20] <Keybuk> right
[12:20] <Keybuk> system clock set from hardware clock on power on
[12:20] <Keybuk> system clock set from network on ifup
[12:20] <Keybuk> hardware clock set from system clock on shutdown
[12:20] <Keybuk> except I note that the init script is missing here ;)
[12:20] <cjwatson> but if the system clock is set from the network relative to a completely broken hardware clock, that would certainly break stuff first time round
[12:20] <ogra> right, but if you need a correct time on first boot and the board only has 01 01 1970 in the hwclock
[12:20] <ogra> where would a correct time come from without net
[12:21] <cjwatson> so does this mean network -> system clock needs to adjust password expiry too?
[12:21]  * cjwatson vomits
[12:21] <Keybuk> ogra: where would a correct time come from at all?
[12:21] <Keybuk> cjwatson: I don't see what this has to do with password expiry?
[12:21] <cjwatson> Keybuk: ok, I think this is the sequence of events
[12:22] <cjwatson> 1) system boots; hardware clock says 1970 so system clock is initialised to that
[12:22] <ogra> Keybuk, if your clock is at 01 01 1970 ... the default expiry value in /etc/shadow seems to be 13979
[12:22] <cjwatson> 2) casper runs in the initramfs, and among other things it runs adduser and sets some kind of default expiry time
[12:22] <ogra> 13979/365=38 years
[12:22] <cjwatson> 3) network comes up and ntp runs
[12:22] <ogra> which means its expired :)
[12:23] <Keybuk> ogra: I have 99999 in my expiry field
[12:23] <ogra> wrong field ? :=
[12:23] <ogra> :)
[12:23] <Keybuk> no...
[12:23] <Keybuk> ubuntu:...:0:0:99999:7:::
[12:23]  * ogra thought it was the second field
[12:23] <Keybuk> second field is days *before* password may be changed
[12:24] <Keybuk> third field is days *after which* password must be changed
[12:24] <ogra> days since Jan 1, 1970 that password was last changed
[12:24] <Keybuk> fields after that
[12:24] <Keybuk> ie. username = ubuntu, pass = ..., last changed = 0, may be changed = 0, must be changed = 99999
[12:25] <cjwatson> 99999 days == ~ 27 years
[12:25] <ogra> yeah
[12:25] <Keybuk> cjwatson: 273 years
[12:25] <ogra> oh
[12:25] <Keybuk> so while we will be bitten by this bug, I'm not going to worry about it too much ;)
[12:25] <cjwatson> Keybuk: one of us can't divide
[12:25] <Keybuk> I'll leave a note about it in my will
[12:25] <cjwatson> 99999/365
[12:25] <cjwatson> 27.39452054794520547945
[12:25] <Keybuk> cjwatson: math 101, if you have ~100,000 and your dividing by order of 100-1000 your answer is going to be >100 and <1000
[12:26] <Keybuk> so it's you :p
[12:26] <ogra> 99999/365
[12:26] <ogra> 273
[12:26] <ogra> Keybuk, is right
[12:26] <cjwatson> oh, grr
[12:26] <cjwatson> my system is under load and there was a leading 9 to bc's input as a result
[12:26] <cjwatson> which showed up rather earlier so I didn't notice ...
[12:27] <cjwatson> fair point on maths 101 :)
[12:27] <ogra> anyway, setting the hwclock manually solves my tty prob and gives me a different /etc/shadow
[12:27] <Keybuk> so I agree that this problem looks like it's caused by the system clock being 1970 when adduser is run
[12:27] <ion_> In that case, the result should have been 2739. :-P
[12:27] <Keybuk> but I don't see why login is behaving that way at all
[12:27] <Keybuk> the password still should not be expired
[12:27] <Keybuk> if it was set in 1970, and is not due to expire until 2243 ...
[12:29] <ogra> well, so we might hit a bug somewhere ... all i can say that a proper clock fixes all issues
[12:30] <Keybuk>         if (spent->sp_lstchg == 0) {
[12:30] <Keybuk>                 D(("need a new password"));
[12:30] <Keybuk>                 *daysleft = 0;
[12:30] <Keybuk>                 return PAM_NEW_AUTHTOK_REQD;
[12:30] <Keybuk>         }
[12:30] <Keybuk> hah
[12:30] <Keybuk> hah
[12:30] <Keybuk> hah
[12:30] <Keybuk> someone special-cased 0 to mean "must change immediately"
[12:30] <ogra> OH !!! and on a sidenote a fixed clock fixes https://bugs.launchpad.net/gnome-keyring/+bug/328167
[12:30] <ogra> seb128, ^^^^
[12:31] <Keybuk> ogra: does the hardware clock keep time over a power off?
[12:31] <ogra> apparently, yes
[12:31] <ogra> it did for me right now
[12:31] <Keybuk> sure?
[12:31] <Keybuk> you just rebooted
[12:31] <ogra> no, it took to long and i unplugged power
[12:31] <Keybuk> oh, wait, this is a live image
[12:32] <ogra> right, i was lazy
[12:32] <Keybuk> so the hwclock shutdown script has been removed by casper
[12:32] <cjwatson> heh, so the only valid times for the clock in Ubuntu must be 86400 seconds from epoch or greater
[12:32] <cjwatson> we could change the kernel to guarantee that
[12:32] <Keybuk> changing the kernel to work around a PAM feature sounds like exactly the kind of thing that won't be accepted upstream :-/
[12:33] <cjwatson> 'cos there are so many systems that desperately need to have their clock set to 1 Jan 1970 at boot
[12:33] <Keybuk> I did think of a sensible minimum time
[12:33] <Keybuk> that the kernel has
[12:33] <Keybuk> its own build time/date
[12:33] <ogra> well, we could set it to 1 instead of 0
[12:33] <Keybuk> ogra: then you'll hit the next bit ;)
[12:33] <ogra> or to some fantasy value
[12:34] <cjwatson> useradd could explicitly special-case this
[12:34] <Keybuk> actually, no, you won't
[12:34] <ogra> right, thats what i mean
[12:34] <cjwatson> if the current time appears to be 0 days, add 1
[12:34] <Keybuk> yes useradd could special-case this
[12:34] <ogra> we set the passwd from casper anyway
[12:34] <cjwatson> will anything care if password-last-changed > current-time?
[12:34] <cjwatson> ogra: indeed, but useradd is a better place for the change
[12:35] <ogra> but then it will apply everywhere
[12:35] <cjwatson> not saying it's the best place, but definitely better than casper :)
[12:35] <cjwatson> yes, it wil
[12:35] <cjwatson> l
[12:35] <cjwatson> is that a problem? that sounds like a feature to me
[12:35] <ogra> while we actually only need it in live sessions, no ?
[12:35] <Keybuk> cjwatson: you get a warning
[12:35] <Keybuk> but it returns PAM_SUCCESS
[12:36] <cjwatson> ogra: where possible, a design goal for the live CD should be to differ as little as possible from the normal system. If a bug fix is needed in the live CD that doesn't break anything reasonable in the normal system, we should fix the normal system
[12:37] <cjwatson> since Keybuk has checked that this doesn't break cases where the system clock remains 1 Jan 1970 after boot, I can't think of any reasonable case that this useradd change would break
[12:37] <ogra> right, understood, though the user handling of the live CD is special anyway, which was the reason for me to think we should fix it there, if it improves anything for a normal system i indeed agree
[12:38] <Keybuk> do we care enough about systems with an empty hardware clock, and no network, to deal with the "what is the time mr wolf?" problem
[12:38] <Keybuk> ie. ask the user what time it is ;)
[12:38] <ogra> ugh
[12:38] <ogra> that sounds evil
[12:38] <ogra> like going back to the 90s :)
[12:38]  * ogra remembers a d-i question in woody ...
[12:39] <ogra> imho it should just not break ...
[12:39] <cjwatson> ogra: we create a special user, yes, but "I ran useradd on a normal system that has a broken clock and can't log in with that new user" sounds like a reasonable enough bug to me too
[12:39] <ogra> yeah, agreed
[12:41] <Keybuk> ogra: well, those people will just get systems that think they're in 1970 all the time
[12:41] <Keybuk> it depends whether you think that's breaking or not ;)
[12:41] <ogra> if the functionallity is given i think thats fine
[12:41] <Keybuk> and I tend to agree with something cjwatson said
[12:41] <ogra> if its a desktop system you will notice it immediately
[12:42]  * cjwatson falls over
[12:42] <Keybuk> that at least if the clock is 1970, we _know_ what's happened
[12:42] <Keybuk> whereas if we set it to some random time like the kernel's own build date, we won't have a clue
[12:42] <ogra> indeed
[12:42] <cjwatson> and also, users know what's happened; 1970 is a fairly familiar "hardware clock forgot its time" symptom to an entire generation of techies
[12:44] <ogra> what are we discussing here ? (i never disagreed to that one actually)
[12:45] <ogra> i wouldnt ask the user ... and i wouldnt set it to something random ...
[12:46] <cjwatson> I think Scott is posing a question and then arguing with it himself :-)
[12:46] <cjwatson> i.e. thinking out loud
[12:46] <ogra> heh, yeah
[12:46] <ogra> we might hit filesystem issues though, not sure
[12:47] <ogra> i.e. enforced fsck
[12:47]  * ogra isnt sure in what other areas of the system 1970 will have any effect
[12:48] <cjwatson> largely, it shouldn't matter much. Only things that compute time in days are likely to have a problem
[12:48] <cjwatson> for anything that works in seconds or less (i.e. nearly everything), it's non-zero and positive, so who cares
[12:48] <cjwatson> obviously if the time is inconsistent, e.g. keeps going backwards after power removal, that's a problem
[12:48] <ogra> right... and fsck will actually only kick in if the clock changes to a proper date
[13:02] <seb128> ogra: good to know for the gnome-keyring issue
[13:02] <ogra> seb128, meh, next reboot its back ... seems i was mislead
[13:03] <ogra> it probably just dies after some time, i'm monitoring ti atm
[13:53] <allquixotic> Has anyone else started to get Pidgin crashes in latest Jaunty? I gdb'ed it down to libpurple/protocol/msn/notification.c:941, there's a nice pointer1->pointer2->pointer dereference and the first or second one is NULL... it's never checked before it's used :)
[13:54] <allquixotic> It was fine for days, now it's crashing on startup right as MSN connects
[13:54] <Riddell> siretart: libavcodec52 is ending up on the CDs
[13:54] <allquixotic> I checked our diff on Pidgin and we don't patch that file so it's in upstream
[13:54] <Riddell> siretart: so is libxine1-ffmpeg
[13:57] <Riddell> siretart: libxine1 should depend on  "libxine1-misc-plugins | libxine1-plugins" as it does in intrepid, it's the wrong way around in jaunty
[13:57] <dholbach> allquixotic: did you try asking in #ubuntu-desktop?`people might give you a good answer there
[13:58] <allquixotic> dholbach: Are they interested in Jaunty development over there too? Odd to have different development channels
[13:58] <allquixotic> I've never been to #ubuntu-desktop before now :)
[13:59] <dholbach> allquixotic: there's a lot of individual development channels around here (server, kernel, mobile, desktop, etc.)
[13:59] <Riddell> siretart: changelog tells me we had same problem in intrepid fixed in xine-lib (1.1.14-1ubuntu2)
[13:59] <Riddell> siretart: so I'll make that change now
[13:59] <dholbach> allquixotic: thanks for working on pidgin - I'm sure a lot of people will appreciate it
[14:00] <allquixotic> dholbach: The bug seems network/thread/code-up related, and C/GLib is right down my alley :) I will have a "fix" that causes it not to crash shortly, but I'd like to at least get someone else to acknowledge the problem :-/ Might just be my weird MSN account having a notification Pidgin doesn't know about, or something
[14:01] <allquixotic> Fortunately this is the kind of code that someone who isn't an everyday Pidgin hacker can get their head around
[14:01] <dholbach> allquixotic: rock on! :)
[14:01] <Riddell> asac: I'd like to fix bug 340210 for alpha too
[14:01] <Riddell> just to let you know
[14:06] <asac> Riddell: for alpha?
[14:07] <asac> Riddell: what is with the -kde thing. can we remove that from the archive?
[14:08] <mterry> dholbach: Thanks for the endorsement!  I didn't even notice it until I was adding to the page
[14:08] <seb128> allquixotic: you better open pidgin bugs upstream directly there is no ubuntu pidgin hackers
[14:09] <dholbach> mterry: no worries :)
[14:11] <Riddell> asac: I'm undecided on removing it, the kde 4 version may still have a few scenarios where it doesn't work.  it should move to universe anyway
[14:12] <asac> Riddell: well. from what i know the knetworkmanager never became feature complete either
[14:12] <asac> Riddell: and seems to be abandoned upstream
[14:12] <asac> (for 0.7)
[14:13] <asac> Riddell: i would think that if plasma doesnt cover someone cases they can still use -gnome thing
[14:13] <ScottK> Riddell: I'd like to suggest it move to the DVD so we have an installation medium with it for the scenario where someone only has wireless and the widget doesn't work (for just one release).
[14:13] <asac> ScottK: Riddell: is there a particular scenario you have in mind that is broken?
[14:13] <asac> (for plasma)
[14:14] <ScottK> asac: I think the chances of us getting complete test coverage to know that everything is OK are low.
[14:14] <pitti> rmcbride: hm, curious; seems it simply vanished inded
[14:14] <asac> ScottK: well. we know that knetworkmanager is broken ;)
[14:14] <rmcbride> pitti: seb128 and cprov are looking into it
[14:14] <ScottK> I don't have a specific scenario I KNOW is broken, I just think it's prudent not to totally jump ship from one to another.
[14:15] <asac> i wonder if anyone will consider it a loss if we remove it and point them to the official applet if they need more features
[14:15] <ScottK> asac: More broken than historically?
[14:15] <asac> ScottK: definitly more broken than with 0.6; knetworkmanager development for 0.7 seems to have stopped half way (e.g. just wired and basic wireless)
[14:16] <pitti> rmcbride: seems to be a well-known soyuz bug; either way, seems we need a no-change upload and NEW it again
[14:16] <ScottK> Right, but I'm using the 0.7ish one on Intrepid and it generally works.
[14:16] <asac> ScottK: and plasma ;)?
[14:16]  * ScottK is still on Intrepid, so hasn't used it yet.
[14:16] <asac> heh. ok
[14:17] <ScottK> I think leaving it on the DVD for one release is low risk and gives a decent fallback should unexpected hardware/scenario specific issues with the new widget pop up.
[14:17] <ScottK> If it doesn't work either, the user is no worse off than if we'd removed it.
[14:20] <siretart> Riddell: oh, indeed. thanks!
[14:21] <asac> ScottK: if users wouldnt report stuff against network-manager i wouldn't care. from that point i would prefer that kde folks report bugs against plasma and then go to network-manager-gnome as a fallback (instead of yet another broken thing).
[14:21] <Riddell> siretart: how do I use this hg thing?
[14:21] <asac> just my suggestions. in the end kubuntu team has to decide.
[14:22] <ScottK> Unless we seed network-manager-gnome and all the related depends on the dvd it doesn't really address my issue.  I'm mostsly worried about having and installation media that can be used without users having to resort to hand configuring networks.
[14:23] <ScottK> Just my suggestions too.  Up to Riddell.
[14:26] <siretart> Riddell: pretty similar to bzr, but use 'hg clone' instead of 'bzr get' to checkout
[14:27] <asac> yeah. lets wait for Riddell. i just think that if users can connect somewhere with the current incomplete knetworkmanager, but can't do that with plasma then plasma is just not ready
[14:27] <Riddell> siretart: E: Couldn't find package hg
[14:27] <siretart> Riddell: apt-get install mercurial
[14:30] <siretart> Riddell: however for such a small and uncontroversial change, I'd suggest to just upload to ubuntu, and I'll import the upload to the branch next time I work on it
[14:30] <siretart> (or ping me and I'll do it in a minute)
[14:32] <Riddell> siretart: kubuntu.org/~jriddell/tmp/xine-lib_1.1.16.2-1ubuntu2.debdiff
[14:33] <siretart> Riddell: typo: s/whic/which/
[14:34] <siretart> Riddell: and that change still seems a bit unnecessary to me, or rather a workaround for a limitiation in the cd creation scripts
[14:36] <siretart> Riddell: the other alternative is perfectly valid (as your debdiff demonstrates). Why not respect that libavcodec52 is blacklisted and search for valid package set instead?
[14:44] <cjwatson> siretart: the CD creation scripts try to mirror what apt will do where possible, and with the dependencies as they are, apt will prefer libxine1-plugins if that package is available
[14:44] <cjwatson> siretart: I'd support Riddell's change, it looks correct to me
[14:45] <cjwatson> siretart: remember that apt is used to build the live filesystem, and there's no way to tell it to blacklist a package
[14:45] <cjwatson> so you have to get the dependencies such that apt DTRT, not focus on CD creation
[14:49] <siretart> cjwatson: so `apt-get install gxine libavcodec52-` wouldn't work?
[14:49] <siretart> appending '-' always worked for me for blacklisting packages
[14:49] <cjwatson> I'm not actually sure. But I don't want to have to go hardcoding lots of stuff like that in livecd-rootfs!
[14:49] <cjwatson> the stuff in there for Xubuntu is bad enough
[14:50] <cjwatson> dependencies should just behave how we want things to be set up by default
[14:50] <cjwatson> livecd-rootfs> also in tasksel for netboot installs, which would be a lot harder
[14:51] <siretart> well, having a variable $BLACKLISTED_PACKAGES with "libavcodec52-" can't hurt maintainability of livecd-rootfs that badly, I'd imagine...
[14:51] <siretart> but I have to admit that I haven't looked at that too closely yet
[14:51] <cjwatson> I'd really prefer xine-lib to just have the dependencies the right way round for the default install, please
[14:51] <cjwatson> it'll be a lot more fiddly than that in tasksel, trust me
[14:52] <siretart> ok
[14:57] <seb128> siretart: ok, the new gstreamer0.10-ffmpeg seems to be fixing quite some of those crashers
[14:57] <seb128> siretart: just letting you know, I did follow up with slomo and on bugs
[14:59] <siretart> seb128: excellent.
[14:59] <siretart> seb128: perhaps we should syncronise more closely on ffmpeg updates for gstreamer0.10-ffmpeg
[14:59] <siretart> seb128: does gstreamer upstream intend to switch to the 0.5 release of ffmpeg?
[14:59] <seb128> slomo: ^ do you know?
[15:00] <siretart> if yes, we could consider updating ffmpeg to 0.5 in both the package and gst-ffmpeg
[15:03] <ScottK> Now that there's an actual release, it would be a shame not to use it.
[15:04] <siretart> ScottK: does that imply a (granted) freeze exception? ;)
[15:04] <catnap> hello - I'm not a developer, but I think I have a good development idea in my mind
[15:04] <siretart> actually I have the 0.5 release package ready in my ppa
[15:05] <catnap> people often get annoyded when they're typing something on the screen and some windows suddenly pops up and interupts the typing
[15:05] <ScottK> siretart: No, but if the rdepends were tested and working, I'd defiinitely lean in that direction.
[15:06] <catnap> why don't we make ubuntu so, that it detects when user is typing
[15:06] <seb128> it does that
[15:06] <seb128> and that's working most of the time
[15:07] <catnap> seb128: that's great news
[15:07] <catnap> this actually occured to me when I was using windows where the problem is much worse
[15:07] <catnap> I wonder why they haven't fixed it so far
[15:08] <catnap> what does ubuntu do, when new windows is about to interupt user?
[15:08] <slomo> siretart: yes, gst-ffmpeg already contains ffmpeg 0.5 internally
[15:08] <persia> So, anyone who hasn't voted for MC already really ought to do so: polls close in 8 hours or so.  https://launchpad.net/~ubuntu-dev/+polls
[15:08] <catnap> or does that depend on wether you use kde or genome?
[15:09] <siretart> slomo: can you please follow up then in bug #340303 about this? to me it seems then a very good idea to have gst-ffmpeg and ffmpeg-debian in sync
[15:11] <siretart> slomo: ideally we could syncronise on the next ffmpeg update, what do you think?
[15:12] <slomo> siretart: you mean sync the next ffmpeg upload from debian?
[15:12] <siretart> slomo: that would be too much, I'd think. no I mean the next upstream update
[15:12] <cjwatson> Keybuk: heh, I just noticed that swapoff writes to devices internally in the kernel, as I'm guessing does umount
[15:13] <pitti> calc: I try my luck on jaxme now
[15:13] <cjwatson> Keybuk: so swapoff; lvremove is racy and you need swapoff; udevadm settle; lvremove
[15:14] <tomeu> hi all, I'm wondering if the https://wiki.ubuntu.com/UserInterfaceFreeze applies to all software or just to stuff that gets installed by default or the translation and documentation team work on
[15:14] <tomeu> we have some bugs that would be better fixed by adding a couple of strings
[15:18] <tomeu> maybe should ask this in #ubuntu-motu?
[15:26] <calc> pitti: ok
[15:27] <pitti> calc: I just tried a xom rebuild for fun, but it still fails (thus isn't fixed with current openjdk)
[15:27] <calc> pitti: afaict there are stubs in the svn version that might help, but they didn't all work as is
[15:27] <calc> pitti: yea with xom it builds fine on most developer boxes but seems to always fail on the buildd
[15:27] <pitti> calc: do you happen to know about maven-ant-helper?
[15:28] <calc> pitti: not much other than maven pulls in a bunch of universe depends
[15:28] <pitti> calc: no, I don't mean maven2, but maven-ant-helper
[15:28] <pitti> Description: helper scripts for building Maven components with ant
[15:28] <persia> tomeu, That question was answered here within the last 24 hours: it only applies to that which is either installed by default or documented on help.ubuntu.com
[15:28] <tomeu> persia: so it's ok if I update that page?
[15:29] <calc> pitti: oh no not really, i looked at the example package they listed in it and it seems they had to write new build.xml for it, so i was worried i would end up breaking things in undetectable ways
[15:29]  * persia reviews backscroll carefully
[15:29] <tomeu> the point "all user-visible strings in applications and the desktop. " is a bit ambiguous, IMO
[15:29] <kenvandine_wk> kees: ping
[15:29] <pitti> calc: it just might be a shimmer of hope :)
[15:29] <calc> pitti: if you are pretty familiar with ant and maven it probably wouldn't be too hard to convert it over i guess
[15:30] <calc> the only thing i know about either is there is cdbs support for ant, heh
[15:30] <pitti> unfortunately I'm neither
[15:31] <pitti> calc: so, the worst case for jaxme would be that we just keep building it with gcj, right?
[15:31] <calc> pitti: yes, i believe jaxme still builds fine with gcj
[15:32] <pitti> calc: it does, I just built it here
[15:32] <pitti> I want to compare build logs, and everything
[15:32] <calc> pitti: iirc xom still builds with gcj as well, xom just seems to die due a weird out of resources error
[15:32] <persia> tomeu, I've updated to reflect what I believe was the agreed change, referencing the log.
[15:32] <pitti> it's a recursive stack overflow
[15:33] <calc> pitti: oh hmm, i wonder why it sometimes works during build and sometimes doesn't
[15:33] <calc> pitti: is it infinite recursion or just recurses too much on the buildd?
[15:33] <pitti> calc: infinite, as it looks
[15:33] <calc> pitti: hmm :\
[15:33] <pitti> I see the same stack frame over and over
[15:33] <tomeu> looks awesome, thanks!
[15:34] <pitti> it doesn't look like being related to too little RAM or anything like that
[15:34] <calc> pitti: fwiw i built on amd64 and the buildd that builds it is i386, not sure if that would be related
[15:34] <calc> pitti: i can try rebuilding it on my machine again and see if it still builds ok here, if so there might be some 32/64 bit issue
[15:35] <pitti> calc: thanks
[15:35] <pitti> calc: ok, I'll continue with jaxme
[15:35] <persia> calc, pitti Do be careful of maven builds.  The current archive maven expects to pull from the internet when building.
[15:35] <calc> persia: ugh!
[15:36] <calc> isn't that forbidden in debian policy?
[15:36] <persia> No.
[15:36] <pitti> persia: I don't intend to actually use maven; thanks for the warning
[15:36] <persia> It's forbidden to use that on a buildd.
[15:36] <pitti> calc: in practice yes, because the buildds don't allow it
[15:36] <calc> ah ok, i thought it had managed to make it into policy
[15:36] <persia> Same as we support end-users pulling from cheeseshop or cpan.
[15:37] <persia> But we can't do that when building our packages.
[15:37] <pitti> doko: why does default-jdk-builddep depend on both default-jdk (openjdk) and java-gcj-compat-dev?
[15:38] <calc> persia: well essentially i am surprised it doesn't support a buildd safe way to build as it is a build tool and other things use it (or maybe... they will use it eventually) ;-)
[15:38] <doko> pitti: to build the gcj natively compiled parts
[15:38] <calc> so i suppose either nothing currently uses it in the archive or packages have to hack around its tendency to download things
[15:38] <pitti> doko: I thought we should get rid of gcj?
[15:39] <calc> pitti: you might only need default-jdk depending on what it is
[15:39] <persia> calc, https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec
[15:39] <calc> persia: thanks for the pointer :)
[15:39] <pitti> doko: just wondering how disastrous it would be to leave jaxme build with gcj in jaunty, if all attempts to make it build with openjdk fail
[15:41] <persia> calc, Be warned that the spec is mostly abandoned, in favour of http://wiki.debian.org/Java/MavenRepoSpec (I believe)
[15:42] <calc> persia: ok
[15:42] <stgraber> pitti: didn't we decide that anything that wants to sound new must end with "kit" ? :)
[15:43] <ScottK> No doubt with the kitkit to rule them all.
[15:43] <directhex> it's a rip-off of BeOS, FYI
[15:43]  * calc is seeing if xom will build or explode for him again
[15:43] <directhex> http://en.wikipedia.org/wiki/Be_API
[15:44] <pitti> calc: wear a helmet
[15:44] <dholbach> KITT would rule them all!
[15:44] <calc> pitti: built fine here
[15:44] <directhex> Application Kit? OpenGL Kit?
[15:44] <calc> pitti: i'm going to create a i386 chroot and see if i can make it explode
[15:44] <calc> pitti: when you built it what platform did you try?
[15:44] <pitti> calc: just for fun, fancy throwing it into your ppa?
[15:44] <pitti> calc: I just retried it on the normal buildds, thus i386
[15:44] <persia> pitti, We have a few packages that still build-depend on gcj (and default-jdk *is* gcj in Debian, which encourages that for now)
[15:44] <calc> pitti: i think it probably is an i386 issue, so will try building on i386 now
[15:45] <calc> pitti: all my systems are installed 64bit so i usually do all my builds that way which would explain the issue if it does just die on i386
[15:45] <pitti> calc: at least it would give some reproducibility
[15:45] <calc> pitti: yea, will see now
[15:45] <doko> pitti: sure, that's an option. does ecj handle it? gcj still provides the fastest alternative for some archs. what I really do want to have is a conditional dependency: if gcj is installed/used, install the corresponding "-gcj" package.
[15:46] <pitti> doko: didn't try with ecj, just with java-gcj-compat-dev
[15:47] <pitti> and of course with default-jdk
[15:47] <Keybuk> cjwatson: why is it racy with the lvremove?
[15:47] <Keybuk> or do you mean swap-on-lv?
[15:47] <doko> pitti: this is ecj then
[15:54] <calc> YIPEE!
[15:54] <calc> my OOo file chooser patch works!
[15:56] <pitti> calc: for unbreaking gvfs, and using fuse?
[15:56] <calc> pitti: for forcing OOo to use the fuse path, yea
[15:56] <pitti> yay
[15:56] <calc> it shows up like this more or less (in debugging)
[15:56] <calc> SalGtkFilePicker::getSelectedFiles() - pURI1 = 'sftp://ccheney@127.0.0.1/home/ccheney' - pPATH = '/home/ccheney/.gvfs/sftp for ccheney on 127.0.0.1/home/ccheney' - pURI2 = 'file:///home/ccheney/.gvfs/sftp%20for%20ccheney%20on%20127.0.0.1/home/ccheney'
[15:56] <calc> i take the file_path then stuff it back into a uri and send it along
[15:57] <pitti> calc: I hope you don't have to cobble together the .gvfs path yourself :)
[15:57] <calc> pitti: no, i just have to use the file_get_chooser for GFile instead of uri then pull the path out of it, then convert that to a uri then pass it back to OOo
[15:58] <TheMuso> Amaranth: thank Daniel, he sorted that out. :)
[15:58] <calc> too bad there is no obvious way to tell the chooser to just return a gvfs fuse uri to begin with
[16:00] <pitti> calc: ah, I isolated the "build with java 6" patch from the svn; I'll see how that backports
[16:01] <calc> pitti: cool :)
[16:01] <pitti> it's just a 39 KB diff commit, so how bad can it be
[16:01]  * pitti sobs
[16:02] <calc> heh
[16:02] <calc> so now OOo can't save to ftp but i can probably track down the bug in gvfs for that
[16:03] <calc> i didn't try ftp before since sftp/smb already worked
[16:03] <pitti> calc: just ftp, or sftp also?
[16:03] <pitti> ah, nice
[16:03] <calc> plain ftp
[16:03] <pitti> *shrug*
[16:03] <calc> sftp works, smb works, ftp doesn't
[16:03] <ScottK> It'd be nice if sftp worked on non-gvfs systems.
[16:03] <calc> but OOo is using straight fuse now so fuse just doesn't support something it needs
[16:03] <pitti> calc: I'd call that a feature :)
[16:04] <calc> pitti: heh yea
[16:04] <calc> pitti: tbh i don't know if ftp support ever worked with OOo even in the past when gvfs had otherwise worked for it
[16:04] <Amaranth> pitti: that's nothing, the diff from ffmpeg a month ago and ffmpeg 0.5 is 1.2MB
[16:04] <calc> but it should be relatively trivial to find out why it is failing
[16:05] <calc> pitti: testing the xom on i386 now
[16:08] <alex-weej> any dev know what's happened to Qt in Jaunty to make it not respect fontconfig for hinting?
[16:09] <cjwatson> Keybuk: swapoff/umount triggers change event, lvremove fails because device is busy
[16:09] <cjwatson> I think
[16:09] <cjwatson> and yes, I mean swap on lv
[16:09] <cjwatson> or whatever's-being-umounted on lv
[16:09] <Keybuk> right
[16:09] <ScottK> alex-weej: The move to Qt 4.5 is recent.  You might ask in #kubuntu-devel.
[16:09] <Keybuk> any fput in the kernel will trigger the inotify ;)
[16:12] <alex-weej> scottK: done.ta.
[16:13] <ogra> Keybuk, so looking at the babbage serial ttys i think they should have the same rules as ttyUSBX, do you want a bug for that ?
[16:13] <Keybuk> that means they'd be in "dialout" ?
[16:13] <ogra> right
[16:13] <Keybuk> can you hijack jerone's existing bug and be more useful on it
[16:13] <ogra> if thats correct for ttyUSB i do think thats fine for any other serial ports as well
[16:14] <ogra> Keybuk, do you have a number ?
[16:15] <Keybuk> no, I'm a name, not a number
[16:15] <ogra> :P
[16:15] <Keybuk> bug #340796
[16:15] <ogra> for that bug indeed :)
[16:15] <Keybuk> might as well retitle that one just "udev rules for Freescale ARM MX51 based devices"
[16:15]  * ogra adds 
[16:16] <ogra> yeah, thats for video devices
[16:16] <ogra> Keybuk, oh, the kernel patches arent upstream yet
[16:16] <ogra> and are unlikely to get there in time for jaunty i guess
[16:17] <Keybuk> heh
[16:17] <Keybuk> are they on lkml?
[16:17] <Keybuk> as long as they've hit there, udev upstream is generally happy
[16:18] <ogra> i doubt it, amitk only added the patchset to our kernel yesterday and i think he is still working on sanitizing it for us before anyone even thinks about sending tehm upstream
[16:20] <directhex> "There was a rumour that, in the wake of the TomTom case, Canonical was seriously considering removing Mono from main and leaving it to multiverse as too dangerous to support (like mp3). I haven’t been able to find any more info either way, asking around. "
[16:20] <directhex> yay for boycottnovell :)
[16:25] <soreau> Hello
[16:26] <slangasek> mdke: do you think we should have a whitelist of those universe packages whose UIs wind up in the relevant documentation, or some other way to describe this?
[16:26] <slangasek> pochu: ah, I don't know what semantics they're using for that tag, but they don't seem to have requested a UIF :)
[16:27] <slangasek> (e)
[16:27] <soreau> I know this may not be the correct place to ask but I am having the bug 99908 "The ext3 file system creation in partition # of SCSI (0,0,0) (sda) failed." on both Hardy and Intrepid alternate. Is there any possible way that I can get around this to install ubuntu?
[16:27] <slangasek> seb128: middle of the milestone freeze, so not really
[16:27] <soreau> Actually, I am having the bug in the alt install, not the gui ubiquity (if they are different)
[16:27] <seb128> slangasek: you reply to a question from 8 hours ago?
[16:28] <slangasek> pitti: gnome-themes-ubuntu> sounds fine; also rescued some space because libavformat52 had been sneaking in when it shouldn't, and causing problems
[16:28] <seb128> slangasek: if that was a "can I upload" I did upload what I wanted to get in beta6 so it's all good from my side ;-)
[16:28] <slangasek> seb128: yes, that's what I do when people ask me questions in the middle of the night ;)
[16:29] <seb128> slangasek: yeah, I was just not sure about the context
[16:29] <seb128> I forgot, the day has been busy ;-)
[16:30] <slangasek> ok. :)
[16:30] <soreau> Does anyone have a suggestion to this issue I am experiencing?
[16:30] <ogra> Keybuk, i'm not touching the bug until i have more info from kernel team
[16:31] <cjwatson> soreau: firstly, I would strongly recommend that you regard your problem as a new bug, not tag along with an existing bug; that error message is general and can have many causes, and conflating lots of bugs into one report makes them less likely to get fixed
[16:31] <cjwatson> soreau: secondly, we have had some recent (new!) problems in this area. Have you tried with *today's* daily build, since we installed some fixes yesterday?
[16:32] <cjwatson> soreau: or are you referring to a problem in a stable release of Ubuntu?
[16:32] <soreau> Only with 'stable' releases, 8.04 and 8.10 Alternate cd's
[16:33] <cjwatson> soreau: can you please file a *new* bug and attach your logs to it? you can extract them by going back to the installer main menu and using the "Save debug logs" item
[16:33] <cjwatson> then give me the bug number
[16:34] <slangasek> Riddell: ah, you fixed the xine-lib issue, great :)
[16:34] <soreau> No, I have grown weary with frustration. I was only wanting to know if there was a quick fix solution. Sorry, but I think I'll try that windows ubuntu installer next.. wubi?
[16:34] <soreau> cjwatson: Thanks for your input though
[16:34] <cjwatson> soreau: um, please?
[16:35] <cjwatson> soreau: I can't investigate this and answer your question without seeing the logs
[16:35] <cjwatson> soreau: if I see your logs, there might well be an easy answer for you
[16:35] <cjwatson> but I can't tell you off the top of my head based on just a general error message
[16:36] <ScottK> soreau: He's the senior developer on installer stuff so you won't get a better shot at an answer.
[16:36] <soreau> cjwatson: Well now that I have been trying this so long, I decided to nuke the ntfs partition so am beginning to reinstall windows (not by my choice, all's I wanted to do was make my friends bug ridden xp install a dual boot linux pc)
[16:37] <cjwatson> I'm also hoping that soreau might be one instance of a more general problem, in which case I might get to fix it for lots of people for 9.04
[16:38] <soreau> cjwatson: But, if it will help you, and the alternate cd is capable of mounting my usb stick (any sane mount/umount command give 'invalid argument' btw) then tell me a list of logs you would like to see and I'll try my best to pastebin them for you
[16:39] <soreau> dmesg was polluted with I/O errors so it may even be HW failure which would be puzzling since xp seems to have no such trouble installing
[16:40] <cjwatson> I routinely need /var/log/syslog and /var/log/partman
[16:40] <soreau> Yes, and what else?
[16:40] <cjwatson> that's all
[16:40] <cjwatson> soreau: do you have another computer on the same network that you can ssh into?
[16:40] <cjwatson> or just network-accessible at all, I suppose
[16:41] <soreau> Yes, but for what purpose?
[16:41] <cjwatson> well, you can switch to tty2, run the command 'anna-install openssh-client-udeb', and then you can just scp the log files out
[16:41] <soreau> This is only happening on this A45-S120. All my desktop pc's have never had this problem
[16:42] <cjwatson> much easier than messing around with USB sticks
[16:42] <soreau> cjwatson: Oh, you mean on the problem lappy..
[16:42] <cjwatson> yes
[16:43] <soreau> cjwatson: Ok, give me a few moments please
[16:45] <soreau> cjwatson: To make sure and clarify, you want the logs after the failure (of course) correct?
[16:45] <cjwatson> yes
[16:45] <soreau> ok, sec
[16:56] <soreau> cjwatson: I have the files but I need help because ifconfig isn't even available (?)
[16:56] <soreau> What would a usb stick be list as in /dev?
[16:56] <Keybuk> sd[a-z][0-9]+
[16:57] <ogra> just look at the output of the dmesg command after you plugged it in
[16:57] <soreau> ah yes
[16:57] <calc> pitti: yea iirc i got that error when i was trying to backport the changes also
[16:57] <calc> pitti: which was when i decided i didn't know enough about what I was doing to keep from breaking things, heh
[16:58] <pitti> calc: oh, then it seems that I just duplicated your backporting work
[16:58] <pitti> calc: yeah, NFC what this wants to tell me
[17:00] <cjwatson> soreau: the network should already be up by the time you encounter this bug; you can use the ip command if you need it, things like 'ip addr show'
[17:03] <soreau> cjwatson: /var/log/syslog -> http://pastebin.com/m34edc693 /var/log/partman -> http://pastebin.com/m5566d0fb
[17:04] <soreau> doesn't look too good to me
[17:07] <cjwatson> soreau: ok, so there are indeed a vast number of input/output errors in there, as you said earlier
[17:07] <soreau> yup
[17:07] <cjwatson> soreau: since you said that XP is fine, it's probably a Linux kernel bug; since it isn't an installer problem as such (the installer is just the victim) it's outside my realm of expertise
[17:08] <soreau> okays
[17:08] <cjwatson> soreau: if it were me I'd start by messing around with the boot options provided in the F6 ("Other Options") menu at the CD boot menu
[17:08] <Keybuk> really?
[17:08] <Keybuk> those errors are pretty much definitely dead disk
[17:08] <cjwatson> XP being fine tends to suggest that it might be the 1% of cases where it's the driver that's busted
[17:08] <soreau> cjwatson: I think I will try this wubi thing. Thanks for looking
[17:08] <Keybuk> how would you test the Live CD on XP?
[17:09] <cjwatson> assuming that XP is in fact still fine
[17:09]  * Keybuk is looking at the sr0 I/O errors
[17:09] <cjwatson> Keybuk: (a) this isn't a live CD (b) there are also a slew of I/O errors about sda
[17:09] <Keybuk> ah
[17:10] <cjwatson> soreau: this is just advice and you're free to ignore it, but I would be surprised if it worked any better. It'll be using the same disk driver
[17:10] <Keybuk> there's some odd pnp errors too
[17:10] <soreau> Keybuk: The sr0 errors I've seen on several different machines only with 8.10 disks
[17:10] <cjwatson> CDs are the most unreliable allegedly-reliable medium I've ever encountered
[17:11] <Keybuk> cjwatson: certainly CD+-*Rs :p
[17:11] <cjwatson> a speck of dust on the lens causes immense confusion
[17:11] <soreau> heh, perhaps there is a reason that's not the first time I've heard that
[17:11] <cjwatson> and the physical media is so cheap nowadays that it's cheaply-*made* too, so gets scratched really easily
[17:11] <soreau> cjwatson: How about ubuntu
[17:12] <cjwatson> hmm?
[17:12] <soreau> s fancy disk check program?
[17:12] <cjwatson> you mean the checker on the CD boot menu?
[17:12] <soreau> yea
[17:12] <cjwatson> all it does is read through all the files on the CDs and check their checksums
[17:12] <calc> pitti: you might try asking on their mailing list but it seems to have very low traffic
[17:12] <calc> pitti: other than that i have no clue
[17:12] <soreau> cjwatson: Not the entire cd as a whole collectively?
[17:13] <soreau> iso image even
[17:13] <cjwatson> in some cases it isn't guaranteed to throw up the same errors; I've seen some anecdotal evidence that read order makes a difference. But in any case it will not solve your problem
[17:13] <cjwatson> soreau: (a) how would that help? (b) where would you store the checksum that it would compare against? :-)
[17:13] <soreau> cjwatson: I have no idea, that's just how it's always worked in my head ;)
[17:14] <cjwatson> soreau: it's easier and more useful to check at the filesystem level
[17:14] <soreau> cjwatson: In any event, after I get the results from this wubi thing I'll let you know
[17:17] <soreau> This is probably the worst nightmare I've ever had attempting to install linux but I blame the crappy hw in this laptop
[17:19] <cjwatson> soreau: so Keybuk and I are looking at this, and what's happening under the covers is that the kernel has repeated trouble trying to talk to your disk (possibly relatively minor trouble but just lots of it; hard to say) and eventually decides that it's all too hard and disables the disk
[17:19] <slangasek> NCommander: you can't recommend libxine1-ffmpeg in xubuntu, its dependencies are blacklisted from CDs by Ubuntu technical board resolution 2007-01-02.
[17:20] <Keybuk> the disk errors the kernel is having are DMS related
[17:20]  * NCommander peeks at the seed to see whats pulling it in
[17:20] <slangasek> xfmedia
[17:20] <Keybuk> err, DMA related
[17:20] <NCommander> ew
[17:20]  * NCommander guesses we'll have to drop xfmedia then
[17:20] <TheMuso> or remove the recommends
[17:20] <slangasek> instead of dropping xfmedia's recommends: on libxine1-ffmpeg?
[17:20] <NCommander> The package more or less is useless without it
[17:20] <TheMuso> NCommander: how so?
[17:20] <cjwatson> it only seems to be on write. parted manages to *read* the partition table fine
[17:21] <NCommander> Ugh, there was a bug on this
[17:21] <NCommander> We added the recommends to close it
[17:23] <soreau> cjwatson: I think it's noteworthy that after this problem rerunning the partitioner shows no partitions but only the main disk and update-dev does nothing to help. Rebooting shows the bootloader has been nuked. After running the xp install disk, it shows all partitions and reinstalling the XP BL to the MBR allows it to at least boot xp again
[17:23] <pitti> calc: ok, disabling the test suite work around that weird init.sql problem
[17:23] <soreau> cjwatson: If there's any possibility it may be running out of mem as this thing only has like ~230MB or so
[17:23] <cjwatson> soreau: after this problem, the kernel has entirely disabled access to the disk
[17:23] <soreau> Wow
[17:24] <cjwatson> (until you reboot)
[17:24] <soreau> no wonder
[17:24] <slangasek> NCommander: so do you want to pull xfmedia from the ship seed, or should I upload xfmedia to drop the recommends?
[17:24] <soreau> I wonder why it causes the boatloader on the mbr to disappear or malfunction
[17:24] <cjwatson> soreau: I think out-of-memory is unlikely as it enabled swap just before the disk problems started; besides 230MB is well over spec for the alternate installer itself (although tight for the Ubuntu desktop)
[17:24] <cjwatson> soreau: possibly it started writing the partition table but didn't complete the write
[17:24] <calc> pitti: disabling test suites might not be a good idea depending on why they fail :)
[17:25] <pitti> calc: yeah, it was just a test; I'm bisecting the test suite now to isolate it
[17:25] <calc> pitti: iow will it fail with other software too
[17:25] <cjwatson> the DOS partition table format does not really permit ideal resilience here
[17:25] <calc> pitti: ah ok
[17:25] <pitti> calc: any luck with xom?
[17:25] <calc> pitti: let me see, i started it a bit ago
[17:25] <calc> pitti: yea it fails on i386 for me, works on amd64 for me
[17:25] <Keybuk> soreau: could you try a boot with libata.dma=0 on the kernel command line?
[17:26] <calc> pitti: restarting on i386 to make sure it is consistently failing
[17:26] <soreau> Keybuk: Yes, I can but I will need some time
[17:26] <pitti> calc: hm, sounds like a java compiler error then?
[17:26] <calc> pitti: it seems to consistent pass on amd64 and fail on i386
[17:26] <calc> pitti: seems that way to me with my little knowledge of the situation
[17:26] <pitti> calc: hm, isn't it arch:all?
[17:26] <pitti> weird
[17:27] <cjwatson> soreau: we're in no rush; I'm going out soon anyway
[17:27] <calc> pitti: yea so it would seem to be something related to the openjdk on i386
[17:27] <soreau> cjwatson: Thanks for looking into this, I appreciate it FWIW
[17:27] <calc> pitti: java code that compiles on amd64 should compile the same on i386 (aiui anyway)
[17:27] <soreau> Keybuk: ETA ~30-45mins
[17:27] <NCommander> slangasek, https://bugs.edge.launchpad.net/ubuntu/+source/xfmedia/+bug/307578 - do we have another way to fix this, or is it simply not possible to ship MPEG support out of the box?
[17:28] <Keybuk> soreau: np. if you could grab the syslog and put the url here, I'll get beeped :p
[17:28] <slangasek> NCommander: you can't ship MPEG support out of the box that relies on libavcodec52.
[17:28] <slangasek> NCommander: you could seed totem instead, and then the codec finder would do the work for you :-P
[17:29] <NCommander> ugh
[17:29] <calc> pitti: when it failed the one time in the past for me i might have been trying it on an i386 chroot then too
[17:29]  * NCommander doesn't even know when we made this seed change
[17:29] <NCommander> slangasek, will dropping it to a Suggests work for you? I don't like changing seeds without talking to the other Xubuntu guys.
[17:29] <calc> pitti: i occasionally build for i386 when testing things but not very often, but it is currently looking like it always fails on i386 and always passes on amd64
[17:29] <Keybuk> ...I really quite like this HP Mini
[17:29] <pitti> calc: if it fails building one particular file, maybe you can isolate it, so that upstream has a test case?
[17:29] <Keybuk> much nicer than the Dell

[17:30] <calc> pitti: i'll see what i can find out
[17:30] <slangasek> NCommander: yes, I can drop it to a suggests; and 'bzr blame' will tell you when the seed was changed
[17:30] <NCommander> Keybuk, which HP?
[17:30] <pitti> calc: having a bug filed about this would be nice, and then we can revert to gcj for jaunty
[17:30]  * calc is also doing gvfs testing since it appears no one has done thorough testing of the fuse layer and needs it to work right for jaunty OOo :-\
[17:30] <Keybuk> NCommander: "HP Mini"
[17:30] <Keybuk> 1000 I assume
[17:30] <calc> pitti: ok
[17:30] <NCommander> Oh, I didn't realize there were multiple ones
[17:30] <slangasek> NCommander: actually, the seed itself was changed back in 2008 - I think it's xine that has changed since then
[17:31] <Keybuk> if there are, we're probably not supposed to know about them or talk about them ;)
[17:31] <calc> pitti: i'm headed to lunch now, but i should be back in about an hour
[17:31] <NCommander> I'll drop it to a Suggests, then I'll talk to Cody on what we want to do; I didn't know I was breaking a TB rule with recommending libxine1-ffmpeg
[17:32] <Keybuk> you were breaking the law
[17:32] <Keybuk> now, we break your legs
[17:32] <Keybuk> :p
[17:33]  * NCommander tries to find the TB resolution to cite in the changelog
[17:34] <Keybuk> grep for "OMG WE'RE ALL GOING TO JAIL! I REFUSE TO BE YOUR BITCH, JAMES"
[17:34] <NCommander> Oddly enough, all that popped up was a quote from House ...
[17:35] <cjwatson> http://irclogs.ubuntu.com/2007/01/02/%23ubuntu-meeting.html
[17:39] <RainCT> pitti: does the new gnome-power-manager add any nice features?
[17:40] <pitti> RainCT: the statistics look fancier :)
[17:40] <pitti> RainCT: but by and large, none that spring to your eye
[17:41] <RainCT> Heh. I didn't know about the statistics, how can they be accessed from the GUI?
[17:41] <pitti> RainCT: right-click on icon -> Energy consumption
[17:42] <RainCT> ah, so I have to plug out the power cable to get there without using the terminal :P
[17:43] <Turl> hi
[17:43]  * Keybuk wonders why so many initramfs scripts grep /proc/cmdline to look for things
[17:43] <Turl> I read this on a kernel changelog
[17:43] <Turl>   * Set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y for i386/amd64/lpia
[17:43] <Turl> why the change?
[17:43]  * TheMuso discovers that studio is also shipping libavcodec52, however untangling it from our disks is a bit more difficult.
[17:43] <pitti> I just checked, I still get CPU scaling, so it might not be as scary as it looks
[17:43] <Keybuk> Turl: from ondemand?  because ondemand makes boot slow
[17:44] <kees> MacSlow: heya; thanks for looking into the kerneloops breakage.
[17:44] <Turl> Keybuk: but ondemand drains my battery :p
[17:44] <kees> MacSlow: the bug still shows that kerneloops is "confirmed", should that be flipped to invalid now?
[17:44] <Turl> performance, sorry :p
[17:44] <cjwatson> Keybuk: IIRC, only foo=bar gets passed through as environment variables, not just foo
[17:44] <NCommander> slangasek, http://paste.ubuntu.com/129851/ - here's my debdiff, if its Ok by you, I'll upload this after it finishes test building.
[17:44] <Keybuk> cjwatson: right, but most of these are looking for that
[17:45] <Keybuk> Turl: that's ok, it'll be set to ondemand once you've finished booting
[17:45] <Turl> Keybuk: ok then, hope my laptop boots even faster :p
[17:45] <pitti> Keybuk: scaling_governor is still "ondemand" for me
[17:45] <pitti> Keybuk: is that set later in the boot sequence?
[17:45] <slangasek> NCommander: mmm, please don't make changes for miscellaneous lintian warnings for an upload in the middle of the milestone freeze
[17:45] <pitti> Keybuk: ah, you just said, nevermind
[17:45] <Keybuk> pitti: well, not yet
[17:46] <MacSlow> kees, well the fix in notify-osd to make the kernel oops is pushed upstream (notify-osd), what's missing still is a patch to upstream kerneloops (rather kerneloops-applet) to use a proper gtk+dialog and not a notification
[17:46] <Keybuk> but then there's no kernel uploading with it no at ondemand yet either
[17:46]  * NCommander fixes that
[17:46] <MacSlow> kees, that's what I'm working on now
[17:46] <pitti> Keybuk: hm, I thought I read it in the changelog, and I have -9 now
[17:46] <pitti> ah, seems not recent enough
[17:46] <Keybuk> I only see -8.28 on the changes list
[17:47] <Turl> Keybuk: -9 -> http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_2.6.28-9.30/changelog
[17:47]  * pitti has 2.6.28-9.29 installed
[17:47] <TheMuso> a meta hasn't been uploaded either afaik
[17:47] <slangasek> yes it has
[17:47] <slangasek> but -9.30 which has the change FTBFS, seemingly because of m-i-t behavior changes ;)
[17:47] <Keybuk> *blink*
[17:47] <TheMuso> right launchpad tells me otherwise also
[17:47] <Keybuk> why can't I see that on -changes
[17:48] <TheMuso> because changes is laaaaaaaaaaaaaaagggggyyy?
[17:48] <slangasek> s/changes/lists/
[17:48] <Keybuk> slangasek: oh?
[17:48] <MacSlow> kees, might still be tomorrow until I've that patch ready (for discussion) I'd first like to get feedback from the people in #kernel and #ubuntu-kernel on the look of the dialog
[17:48] <TheMuso> slangasek: right
[17:48] <Turl> another thing, about bug 337301, any idea when the kernel changes will be out there?
[17:48] <pitti> Keybuk: I saw it on -changes, FWIW
[17:48] <slangasek> Keybuk: as far as we got with debugging it yesterday, yes.  I don't know if rtg has a handle on it today
[17:48] <Keybuk> slangasek: nobody asked me about it
[17:49] <NCommander> slangasek, http://paste.ubuntu.com/129853/ - how's this (followed by a bump-upload of xubuntu-meta once this publishes)
[17:49] <Keybuk> what was the problem?
[17:49] <slangasek> NCommander: the debdiff is fine.  why do you think you need to bump xubuntu-meta?
[17:49] <NCommander> slangasek, won't xubuntu-meta ... oh right, I'm an idiot, we're not seeding libxine-ffmpeg directly
[17:49] <slangasek> Keybuk: "depmod no workie"
[17:50] <Keybuk> slangasek: -v
[17:50] <NCommander> ignore me, I'm working without enough caffeine
[17:50] <slangasek> Keybuk: that's as far as we got yesterday, rtg was still chasing the thread when I left
[17:50] <soreau> Keybuk: To verify, is this correct?: file=/cdrom/pressed/ubuntu.seed initrd=/install/initrd.gz libata.dma=0 quiet --
[17:50] <NCommander> slangasek, I just kicked off pbuilder, if its successful, I'll upload if that's fine by you
[17:50] <Keybuk> soreau: yes
[17:51] <slangasek> NCommander: I would prefer you upload immediately
[17:51] <TheMuso> looks like 9.31 was uploaded a while back
[17:51] <Keybuk> I'm pretty sure I've done multiple kernel builds with the new depmod and had no problems
[17:51] <kees> MacSlow: cool great!  I'll excuse myself from this process now.  :)  I just got involved due to doing some packaging cleanups for the MIR, and then trying to debug the regression.  thanks!
[17:51] <soreau> Keybuk: Unknown option 'libata.dma=0' ignoring
[17:52] <Keybuk> soreau: oh
[17:52] <Keybuk> slangasek: ohh, was somebody parsing depmod's *output* ? :p
[17:52] <slangasek> yes
[17:52] <Keybuk> oh
[17:52] <Keybuk> yeah
[17:52] <Keybuk> that's totally changed
[17:52] <Keybuk> which is kinda the point, really
[17:53] <slangasek> right, I didn't say it was m-i-t's /fault/ :)
[17:54] <Keybuk> didn't say you did ;)
[17:54] <Keybuk> but I like to know what I've broken
[17:54]  * calc just realized he wasn't hungry, he is actually sick
[17:54] <Keybuk> even if it's just so I can say "well, if you will put it there..."
[17:54] <pitti> Keybuk: hm, /lib/modules/2.6.28-9-generic/modules.dep doesn't look any different to me; I just have an additional modules.dep.bin now
[17:55] <Keybuk> pitti: it's missing the /lib/modules/2.6.28-9-generic/ bit
[17:55] <calc> pitti: i'll update the xom bug and then i'm off for the day, hopefully i'll be better by tomorrow :)
[17:55] <pitti> Keybuk: ah
[17:55] <pitti> calc: no progress on the initdb front :(
[17:56] <calc> pitti: ok
[17:56] <pitti> calc: sick> ugh; get well soon!
[17:58] <calc> pitti: thanks :)
[17:58]  * calc updated the xom bug 329903 to indicate it appears to be openjdk's fault
[17:58] <slangasek> NCommander: I guess you haven't uploaded yet?
[17:59]  * calc off to bed now, if you need me (emergency) call me as I am sick
[17:59] <cody-somerville> slangasek, is this a must do it now emergency?
[18:00]  * NCommander was talking with cody since I got him just before I uploaded
[18:00] <slangasek> cody-somerville: it's a "NCommander wanted to do the upload and I can't roll valid xubuntu CDs for the alpha until it's done and published" emergency
[18:00] <cody-somerville> ah, Okay.
[18:00] <cody-somerville> I'll de-seed xfmedia from ship
[18:00] <slangasek> hrm?
[18:00] <slangasek> why?
[18:01] <cody-somerville> slangasek, xfmedia is in our ship seed as a courtesy
[18:01] <slangasek> ah
[18:01] <cody-somerville> slangasek, if people want to use xfmedia, I'd prefer it work for them
[18:01] <cody-somerville> slangasek, so instead of removing the recommends I figure just de-seeding it is the optimal choice
[18:02] <slangasek> cody-somerville: ok, fine with me - please unseed :)
[18:02]  * cody-somerville waves his hands and casts some magic.
[18:02] <NCommander> slangasek, side note, its a good thing I test built, the package FTBFS due to the change in the X11 headers itseems.
[18:02] <MacSlow> pitti, ping
[18:03] <cody-somerville> NCommander, YOU SHOULD ALWAYS TEST BUILD!
[18:03] <cody-somerville> :D
[18:03] <pitti> hi MacSlow
[18:03] <NCommander> cody-somerville, of course. Rule number one of being a MOTU
[18:03]  * cody-somerville hi5s NCommander.
[18:03] <slangasek> NCommander: heh, ok
[18:10] <Amaranth> NCommander: I thought rule number one of being a MOTU was to worship dholbach
[18:11] <ScottK> worship/gang tackle at UDS
[18:13] <cody-somerville> Is it worth it to upgrade to 18mb pipe from 10mb for an extra $40? :S
[18:14] <ScottK> I'd go with no.
[18:14] <Turl> cody-somerville: I'm in 3mb/256k, don't make me sad :p
[18:14] <JanC> that's 18 millibit?  ;)
[18:14]  * ScottK recently got upgraded from 10Mb to 17Mb or so for the price went down $0.50.
[18:14]  * TheMuso is jellous.
[18:15] <cody-somerville> ScottK, you went from 10mb to 17mb and the price *dropped*? What ISP are *you* with?
[18:15] <ScottK> Verizon FIOS.  I was an early subscriber and they'd redone the plans.
[18:16] <ScottK> I think that's what it was.
[18:16] <cody-somerville> Verizon FIOS, is that ADSL or Cable?
[18:16] <Amaranth> my grandma started with 5mbit cable and went up to 12mbit cable for less money as they upgraded the plans
[18:16]  * TheMuso is currently on 8MB, which is the fastest in this area, unless i wanted to pay rip-off prices to our monopoly telco for faster speeds which aren't a certainty anyway.
[18:16] <Amaranth> cody-somerville: It's...fiber
[18:17] <cody-somerville> Oh, is fiber better than cable? :P
[18:17] <ScottK> Definitely.
[18:17] <slangasek> dietary fiber is better than dietary cable
[18:17] <cody-somerville> So your 17mb fiber pwn my 18mb cable?
[18:17]  * TheMuso would jump on HFC when he returns to sydney if the prices were reasonable.
[18:18]  * Turl is on ADSL
[18:18] <ScottK> cody-somerville: Well mine also comes with a stack of static IPs, so probably.
[18:18] <Turl> T_T
[18:19] <cody-somerville> oh wow
[18:19] <Amaranth> cody-somerville: also his speed doesn't go down when his neighbor fires up bittorrent
[18:20] <Amaranth> well, I guess that depends on how the system is setup but usually
[18:40] <NCommander> cjwatson, is there any chance britney's run of ports could be fixed? It hasn't spit out a new page since 02/19: http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html
[18:40] <TheMuso> NCommander: ouch really?
[18:40] <NCommander> Yeah
[18:40] <NCommander> See the generated date
[18:41] <TheMuso> is this for CDs, or the archive in general?
[18:41] <NCommander> Archive in general, so we have no up-to-date installability counts.
[18:41]  * TheMuso nods
[18:48] <Turl> libdrm-noveau1 is for nvidia cards, right?
[18:49] <Turl> on its description it mentions intel instead of nvidia :/
[18:50] <azeem> so file a bug
[18:59]  * Turl filled bug 341294
[19:34] <Lure> pitti: can you explain why such apport crashes are rejected - bug 341264
[19:43] <slangasek> pitti: a lot of duplicates on bug #335567 - do you know what's going on there?
[19:51] <pitti> slangasek: haven't looked yet, but it's on my radar
[19:52] <slangasek> pitti: ok. should it be milestoned for beta?
[19:52] <pitti> slangasek: doing
[19:52] <slangasek> ta
[19:59] <pitti> Lure: because they have an absolutely useless stack trace and outdated packages
[19:59] <pitti> Lure: in this particular case, the package isn't outdated, but rather nonexisting, hmm
[19:59] <Lure> pitti: my system is up to date - and I do not hav gstreamer (Kubuntu)
[20:00] <pitti> Lure: well, for this particular bug invalidating is probably alright, since there isn't much to be learned from it
[20:00] <pitti> Lure: but in general, this "None" thing is interesting; can you please file an apport bug and give me the output of "dpkg -s phonon-backend-gstreamer"?
[20:01] <Lure> pitti: I am more concerned about that other reports might be lost
[20:01] <Lure> pitti: sure
[20:01] <Lure> pitti: as I said no phonon-backend-gstreamer installed here, so apport message is correct ;-)
[20:01] <pitti> Lure: this only happens on "useless stacktrace" && "outdated packages", so I don't think valuable bugs can get logs
[20:01] <pitti> s/logs$/lost/, duh
[20:02] <pitti> Lure: hm, sounds like an error with parsing alternative dependencies then
[20:02] <Lure> pitti: ok, so should I still submit apport bug?
[20:02] <pitti> Lure: it's purged?
[20:02] <pitti> Lure: yes, please
[20:02] <Lure> pitti: will check
[20:02] <pitti> Lure: thanks
[20:02]  * Lure is not sure as I got some gnome depens installed by accident
[20:03] <pitti> Lure: it's the preferred alternative of "phonon"
[20:03] <pitti> Depends: phonon-backend-gstreamer | phonon-backend
[20:03] <pitti> I think that's what's confusing apport
[20:03] <Lure> pitti: yes, that might be it
[20:03]  * pitti calls it a day
[20:03] <pitti> good night everyone
[20:04] <Lure> pitti: good nite, and thanks
[20:23] <cr3> might it be possible that something changed on jaunty where running debuild now creates files under debian/tmp/usr/local/share instead of debian/tmp/usr/share?
[20:23] <TheMuso> cr3: are you working with a python package?
[20:24] <cr3> TheMuso: yep
[20:24] <TheMuso> cr3: if so, is it using distutils?
[20:24] <cr3> TheMuso: yep again
[20:24] <TheMuso> cr3: you need to add --install-layout=deb to the setup call I think it is, let me double check that.
[20:24] <TheMuso> cr3: its part of the python 2.6 transition.
[20:25] <cr3> TheMuso: I had that problem in another package, I didn't think that flag also affected the location of share files
[20:25] <cr3> TheMuso: thanks for the tip, I know where I need to go from here :)
[20:25] <TheMuso> cr3: yeah I think it does
[20:25] <TheMuso> cr3: np
[20:25]  * cr3 needs to go get some coffee, that's where he needs to go
[20:44] <ScottK> cr3: TheMuso is correct.  It affects that too.
[20:45] <ScottK> The idea is to get packages installed using just distutils into /usr/local and away from where the packaging system installs stuff.
[20:46] <cr3> ScottK: reasonable enough :)
[20:46] <ScottK> Yes, just slightly painful at the moment.
[20:59] <slangasek> cr3, ScottK, TheMuso: hmm, nice discussion; 'zgrep usr/local dists/jaunty/Contents-i386.gz' points to a few bugs that need to be filed
[20:59] <slangasek> I can't tell if the python-twisted ones are the fault of distutils though
[20:59] <ScottK> slangasek: Probably faster to fix than file.
[21:00] <slangasek> there is that
[21:00] <ScottK> I think twisted does some weird stuff in /usr/local, but doko does mind the twisted stuff pretty well.
[21:00] <slangasek> well, it installs binaries to /usr/local/bin, which is a policy violation
[21:02] <ScottK> slangasek: Any chance you could pour the output from your zgrep into a wiki page we could point people at?
[21:02] <doko> if there is stuff in /usr/local in packages, then the pkgbinarymangler doesn't work as expected :-/
[21:03] <slangasek> ... why is it pkgbinarymangler's problem?  or is pkgbinarymangler supposed to abort?
[21:04] <doko> it is
[21:05] <slangasek> ah
[21:06] <doko> if there's stuff in /usr/local, it's a bug in the apckage of course
[21:07] <ScottK> I guess I shouldn't complain since the McDonald's wifi is free, but 2+ minutes for apt-get update is really annoying.
[21:15] <davmor2> Guys I've just done a freesoftware only install and jockey is asking if I won't to install the nvidia drivers I thought this was disabled in fso version?
[21:22] <mdke> slangasek: I'd like to ask the -doc mailing list, I'll copy you in if that's ok.
[21:27] <slangasek> mdke: sounds good
[21:27] <mdke> thanks
[21:29] <kirkland> superm1: i have a couple of dkms issues at play here
[21:29] <kirkland> superm1: one of which is the fact that i need the headers for the specific kernel that is being compiled against
[21:29] <kirkland> superm1: (as well as any others that might be booted)
[21:30] <kirkland> superm1: what do you think of having dkms depend on all of the kernel headers?
[21:30] <kirkland> superm1: too heavy handed?
[21:30] <slangasek> eew
[21:34] <kirkland> slangasek: you eew'ing me?
[21:37] <slangasek> kirkland: yes. :)
[21:37] <cody-somerville> eww
[21:37] <kirkland> slangasek: awesome!  then you can help me figure out how to solve this problem
[21:38] <kirkland> slangasek: kvm-source provides a dkms module for kvm
[21:38] <kirkland> slangasek: it needs the linux-headers for your kernel to build
[21:38] <kirkland> slangasek: how do put this in a debian/control file correctly?
[21:38] <kirkland> slangasek: linux-headers is a virtual package that tells you to install one of (*)
[21:39] <kirkland> slangasek: nvidia depends on linux-headers | linux-headers-generic
[21:39] <slangasek> heh, nvidia's is backwards then
[21:39] <slangasek> it's meant to be linux-headers-generic | linux-headers (real package first, virtual package after)
[21:39] <slangasek> cf. virtualbox-ose-source
[21:39] <kirkland> slangasek: sorry, that's my transcription (not cut and paste)
[21:40] <kirkland> slangasek: okay, how do i work linux-headers-server into that mix?
[21:40] <slangasek> kirkland: poorly? :)
[21:41] <slangasek> kirkland: you could get a set of metapackages that depend on "linux-headers-foo + linux-image-foo" and have an or'ed dep on those
[21:42] <kirkland> slangasek: so you don't think linux-image-foo should just depend on linux-headers-foo, and bring it on with it
[21:42] <kirkland> slangasek: it would be better to add this layer of another metapackage
[21:43] <slangasek> I think it's useful to a lot of people who don't need dkms to be able to install linux-image-foo without the headers
[21:43] <slangasek> but perhaps linux-foo should pull it in
[21:43] <slangasek> it already pulls in lrm-foo today, after all
[21:44] <kirkland> slangasek: 'twould solve my current issue ....
[21:44] <slangasek> and is described as being "complete" :)
[21:45] <kirkland> slangasek: are you still thinking on this?  can i ask the kernel folks to do this?  or does a more formal proposal need to be drafted and ratified?
[21:47] <slangasek> kirkland: given that the desktop tasks all pull it in by default, and we're talking about also pulling it into server, refactoring so it's pulled in by linux-foo seems perfectly reasonable to me (while also leaving the Recommends: in place for desktop so that we don't also pull in lrm by default)
[21:47] <slangasek> kirkland: I don't think it needs to be any more formal than a bug report
[21:48] <kirkland> slangasek: i can do that, thanks.
[21:48] <brettalton1> kirkland: I was just watching your UDS Jaunty video on YouTube: http://www.youtube.com/watch?v=R-783GBVLIg&feature=channel_page
[21:48] <brettalton1> kirkland: and I was wondering, with Jaunty, if I have a 500GB hdd that is mounted as /storage, how would I fully encrypt that it using the same tools you created to encrypt /home?
[21:49] <kirkland> brettalton1: well, you could do that with ecryptfs, but it might make more sense to use a device encryption scheme there
[21:50] <kirkland> brettalton1: if you really want to do it with ecryptfs, you could do:  "sudo mount -t ecryptfs /storage /mnt"
[21:50] <kirkland> brettalton1: you'll go through a few questions, choosing the passphrase, key size, crypto algorithm, etc.
[21:51] <kirkland> brettalton1: then you'll read/write data to /mnt
[21:51] <kirkland> brettalton1: the encrypted data will land in /storage
[21:52] <brettalton1> kirkland: sounds easy enough :) what's the difference between ecryptfs and a device encryption scheme? one is through software (ecryptfs) and the other I assume is hardware-related, correct?
[21:53] <kirkland> brettalton1: not at all
[21:53] <kirkland> brettalton1: they're both through software
[21:53] <kirkland> brettalton1: and they're both handled in the kernel
[21:53] <kirkland> brettalton1: ecryptfs encrypts each individual file as a unit
[21:53] <kirkland> brettalton1: device encryption encrypts the entire device as a unit
[21:54] <brettalton1> kirkland: ahhhh, okay, so last question: what would I use/do to encrypt the whole device?
[21:54] <kirkland> brettalton1: in this situation, i would use lvm + luks for encryption of that entire device
[21:54] <kirkland> brettalton1: i believe that ecryptfs really shines on per-user encrypted home directories
[21:55] <kirkland> brettalton1: even though it can be used for other things
[21:55] <kirkland> brettalton1: https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto
[21:55] <kirkland> brettalton1: it sounds like this is what you're trying to do ... encrypt an entire filesystem
[21:56] <brettalton1> kirkland: perfect, I'll research that. I appreciate your time, especially since it's one on one time with an Ubuntu developer :)
[21:56] <brettalton1> kirkland: exactly
[21:56] <kirkland> brettalton1: ecryptfs is better at encrypting some subset of the filesystem
[21:56] <brettalton1> kirkland: so /home inside /... got it
[21:56] <kirkland> brettalton1: like your home directory, or just one "private" directory inside of your home directory
[21:56] <kirkland> brettalton1: you're welcome.  cheers ;-)
[21:56] <brettalton1> kirkland: makes sense, thank you!
[21:57] <directhex> ecryptfs sounds a lot like encfs
[22:00] <kirkland> slangasek: created https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/341405
[22:00] <kirkland> directhex: it is, but ecryptfs is in the linux kernel;  encfs is entirely userspace
[22:01] <directhex> kirkland, is that desirable?
[22:03] <kirkland> directhex: it is to me
[22:03] <directhex> fair enough
[22:03] <kirkland> i'm a bit slammed right now, and don't really have the time to defend the strong points of ecryptfs, sorry
[22:06] <kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/341405
[22:07] <kirkland> slangasek: you can comment on that, if i've failed to do the justification justice
[22:08] <directhex> kirkland, i'm not ranting, i was just curious. i'd heard only of encfs, so wondered what the difference was
[22:09] <kirkland> directhex: https://wiki.ubuntu.com/EncryptedPrivateDirectory
[22:09] <kirkland> directhex: search for encfs in that page
[22:09] <kirkland> directhex: the sourceforge page is no more
[22:10] <kirkland> directhex: https://answers.edge.launchpad.net/ecryptfs/+question/46302
[22:11] <directhex> kirkland, srsly, go back to what you were workign on, don't let me disturb you
[22:12] <kirkland> directhex: cheers
[22:12] <kirkland> directhex: come debate it in #ecryptfs on irc.oftc.net, if you're interested in some answers;  there are other maintainers there too
[22:13] <directhex> kirkland, not *that* interested, just noticed a small enough gap in my knowledge to ask ;)
[22:14] <kirkland> directhex: sure.  it's a common question
[22:34] <cjwatson> NCommander: whoops, sorry about that. Looks like I didn't sync the binary Python modules across from the non-ports run properly. I've fixed that and the page is now updated
[22:35] <NCommander> cjwatson, thanks, no problem
[22:35]  * NCommander is just beating his head in w.r.t. to GCC
[22:36] <cjwatson> hmm, we seem not to be running maxb's outdate report for all components regularly, for some reason
[22:37]  * maxb really ought to get around to making that include P-a-s information, come to think of it
[22:38] <slangasek> ok, what keeps launching a separate copy of gnome-power-manager as root on my system?
[22:39] <cjwatson> maxb: I've updated the relevant cron job to run your script now; sorry about that
[22:41] <cjwatson> apparently we'd run it once and then forgotten about it, or something
[22:49] <Amaranth> slangasek: gdm?
[22:51] <slangasek> Amaranth: yuck then?
[22:58] <seb128> Amaranth: we still use the old gdm codebase there is no reason it should start it
[22:59] <seb128> Amaranth: and gdm runs as gdm user
[22:59] <seb128> slangasek: it could be dbus activated by something you run under sudo
[22:59] <slangasek> twitch
[23:19] <dtchen> TheMuso: will need to work logic into removing the notifier hint for #328245, because we can't unconditionally remove it for derivatives not using PulseAudio
[23:19] <TheMuso> dtchen: point
[23:25] <dtchen> seb128: is there a timeline for $GNOME_DESKTOP_SESSION_ID going away (i see it's deprecated)? is there a recommended method of checking if GNOME is the user's active session?
[23:25] <seb128> dtchen: I don't think it's going away soon, setting it is cheap and some softwares rely on it
[23:26] <seb128> dtchen: check for DESKTOP_SESSION=gnome I guess
[23:27] <dtchen> hm, it seems to be 'default' in a default 9.04 install
[23:28] <dtchen> i can just check $GNOME_DESKTOP_SESSION_ID being defined, then. thanks.
[23:29] <seb128> dtchen: http://bugzilla.gnome.org/show_bug.cgi?id=542880
[23:29] <dtchen> seb128: right, thanks
[23:29] <seb128> dtchen: yeah, do that or verify if gnome-session is running
[23:46] <kirkland> superm1: let me know what you think about the dkms patch attached to https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/dkms/+bug/341159
[23:50] <blueyed> OFFTOPIC: need some rest? here's some horse porn: http://hellkeyhole.com/horse-porn
[23:52] <Nafallo> ehrm.
[23:52] <Nafallo> please don't link to porn in this channel...
[23:52] <blueyed> Nafallo: sry, that's been the channel with the most nicks.. ^^
[23:53] <Nafallo> why would that be relevant?
[23:54] <blueyed> more people that would laugh per posted offtopic link.
[23:54] <Nafallo> blueyed: you do realise that link includes some... ehrm... real porn at the bottom, right?
[23:54] <ion_> Or more people to get annoyed by it. :-P
[23:55] <blueyed> Nafallo: sry, haven't realized.. I've not thought about scrolling down after catching up from the floor..
[23:56] <cody-somerville> there is porn right on the right!
[23:56] <LjL> and the left! and the top!
[23:56] <blueyed> ion_: yes, I don't want to disturb at the end.. but the picture itself was so funny after all.
[23:56] <blueyed> porn in the bedroom?
[23:57] <ajmitch> in other words, pasting that link was a seriously stupid thing to do
[23:57] <cody-somerville> It isn't even that funny
[23:57] <cody-somerville> FUNNY LINK FAIL
[23:58] <blueyed> ajmitchm, cody-somerville: I'm still LOLLING about it.. but I get your point. Please execute me, I'm drunk.. ;P
[23:58] <cody-somerville> blueyed, evidently