[00:08] <kirkland> TheMuso: no worries, I think I figured it out ;-)
[00:09] <TheMuso> kirkland: ok.
[00:22] <tormod> TheMuso: the pc speaker issue, can it not be fixed by lowering the priority of the device some way, like the index=-2 for modems and usb devices?
[00:23] <TheMuso> tormod: That has been done for alsa, its pulseaudio thats the issue, as well as the volume for the pcsp alsa device, at least on the hardware I have. If pcsp is muted, then for me at least, there is no sound from the pc speaker when pulse initializes it.
[00:24] <tormod> TheMuso: what criteria does pulseaudio use for selecting the primary sound device?
[00:24] <TheMuso> tormod: Unless the user has set a configuration to use a particular device, pulse uses the first device it finds.
[00:25] <tormod> and it does not go through them in alsa order?
[00:25] <TheMuso> tormod: It goes through them in the order that hal lists them.
[00:25] <tormod> I am sorry I don't know how these things are stacked
[00:26] <TheMuso> tormod: But thats no longer the issue. The pc speaker will never be used by default any more, but the crackling/squeaking sound people get is the issue.
[00:26] <tormod> ok
[00:59] <mardi_soir> hello
[02:58] <RAOF> Oh, curses.  Pulseaudio's getting killed with "Soft CPU limit exhausted" messages again.
[03:09] <crimsun> more context?
[03:10] <jdong> I think RAOF is playing cheapskate CPU socialist government with his shell server ;-)
[03:11] <RAOF> crimsun: Run pulseaudio.  Play some music.  At some point pulseaudio will be killed with SIGXCPU.
[03:11] <LaserJock> crimsun: you know, the thingamagiggie bug in the whatchamacallit
[03:11] <crimsun> RAOF: erm, 8.10? more detail? :)
[03:11] <RAOF> crimsun: 8.10, updated as of this morning, just started happening.
[03:12] <crimsun> interesting, I'll pull a daily-live shortly
[03:12] <RAOF> This _has_ happened before, though.  I forget what happened then, though.
[03:13] <pushax> hi all.  A question. Which html engine as the most interoperability?
[03:16] <LaserJock> pushax: I'm not sure this is the best channel to answer that
[03:16] <RAOF> pushax: In what way do you think that's on-topic for #ubuntu-devel?  Also, there's nowhere near enough information; what do you mean by "interoperability"? :)
[03:16]  * RAOF watches the SIGXCPU signals being ruthlessly caught by gdb.
[03:23] <pushax> ROAF as I want to develop and application but want ti to run also on other systems with minimal changes.
[03:24] <RAOF> pushax: Still off-topic, but both firefox & webkit should be nicely portable.
[03:24] <pushax> KHTML/webkit seems to the be well supported.  I'm fairly new to linux.
[03:25] <pushax> what is the default engine on Gnome?
[03:25] <pushax> is gecko a complete web engine?
[03:26] <pushax> brb
[03:26] <lifeless> gecko is the core of firefox
[03:26] <lifeless> webkit is the core of safari
[03:26] <pushax> does gnome has a web layer?
[03:31] <LaserJock> pushax: Gnome's default web browser, epiphany, has used gecko, but I think webkit is also being worked on
[03:31] <RAOF> Epiphany is moving removing the pluggable backends and supporting just webkit, but it's apparently not going to make 2.24
[03:33] <pushax> thanks gyes
[03:34] <pushax> I wanted soem base, before jumping into reading
[05:21] <LaserJock> hmm, KDE and gnome seem to share the same autostart systems
[05:22] <LaserJock> that seems slightly inconvenient
[05:23] <RAOF> I believe KDE respects the X-KDE-StartOnlyInKDE key, fwiw.
[05:24] <LaserJock> but does Gnome respect X-Gnome-StartOnlyInGnome ?
[05:24] <LaserJock> that's what started this all, Gnome-do was starting in my KDE session and screwing up some things
[05:24] <LaserJock> then I disabled it from KDE and it disappeared altogether from Gnome
[05:25] <LaserJock> hmm, KDE needs to respect X-GNOME-Autostart-enabled I think
[06:00] <Hobbsee> i presume so, but has someone pointed out prior to this point that the information printed on the 8.04 cd sleeves is incorrect?
[06:00] <ajmitch> Hobbsee: which info is that?
[06:01] <Hobbsee> ajmitch: the stuff about the default option being deleting all data on your computer.
[06:03] <dholbach> good morning
[06:03] <Hobbsee> hey dholbach
[06:04] <dholbach> hiya
[06:25] <\sh> moins dholbach
[06:25] <lukehasnoname> I know it's supposed to be a recovery console, but doesn't anyone think it's insecure to have the recovery console (root) not be password protected?
[06:25] <lukehasnoname> What good is locking my screen when a friend (enemy) could reboot, go into recovery and have root control?
[06:26] <dholbach> hi \sh
[06:26] <realist> lukehasnoname: if your enemy has physical access, you've already lost the battle
[06:26] <RAOF> lukehasnoname: That's what luks is for.
[06:26] <lukehasnoname> sudo passwd root
[06:27] <lukehasnoname> luks...
[06:27] <RAOF> Encrypted hard drive.
[06:27] <realist> RAOF means; encrypted root partition
[06:27] <lukehasnoname> ah, yes.
[06:27]  * \sh just fixes all the ESX servers in our company...grmpf 
[06:28] <RAOF> Failing that, physical access trumps everything (and, of course, not even failing that given sufficient encouragement).
[06:28] <realist> Which still wont protect you from someone attempting the frozen memory reboot technique.
[06:28] <lukehasnoname> I'm also thinking of the general population, who won't have any idea to encrypt / or to change root's pass.
[06:28] <RAOF> lukehasnoname: It's a trade-off between convenience and (a little) security.
[06:29] <lukehasnoname> true.
[06:29] <\sh> most people won't know how to access a machine without a password...it's only a promille of the world population
[06:29] <realist> lukehasnoname: I happen to agree with you, by the way. Setting a root password is still a "good idea"
[06:30] <RAOF> The alternative to "no password required for recovery access" is "the root password that you typed once 2 years ago when instaling the system and you've now forgotten is required"
[06:30] <StevenK> Which Windows can do.
[06:30] <realist> RAOF: in which case you can still boot from a recovery disc, chroot, and passwd
[06:30] <RAOF> realist: Indeed.  So what has your root password on recovery access given you?
[06:31] <\sh> realist: that's what bios boot security is for
[06:31] <realist> RAOF: false sense of security :-)
[06:31] <RAOF> realist: Right :)
[06:31] <StevenK> \sh: Sure, and you reboot a server remotely, and then have someone type the password. No, bad.
[06:32] <realist> StevenK: reboot remotely... from alternate boot media?
[06:32] <\sh> StevenK: hmmm? remote insight boards are quite common in our days
[06:32]  * \sh doesn't need remote hands to do the usual work
[06:32] <realist> \sh: or a remote kvm
[06:32] <StevenK> I tend to not like remote KVMs
[06:32] <\sh> realist: I'm HP fan ;) so I have ILO :)
[06:32] <StevenK> They do horrid things like want Java
[06:33] <realist> I'm a Sun fan, so I have an ok> prompt via serial console ;-)
[06:33] <realist> StevenK: not 'real' kvms
[06:34] <StevenK> The "real" remote KVMs tend to cost large sums of money
[06:34]  * realist truely dislikes those web-based remote consoles (eg. Dell RAC, or IBM RSA)
[06:35] <realist> StevenK: there's a nice market there for an open source (hardware/embedded) alternative
[06:41] <Treenaks> nice or niche :)
[06:41] <spm> fwiw, even encrypted partitions can deliver a false sense of security: eg Attacker holds gun to head of (liked vs disliked :-) ) co-worker: "give me the code or bang". There's always a way around, just depends on how much effort an attacker is willing to invest.
[06:42] <RAOF> spm: Or the person with physical access could add a hardware keylogger, or whatever.
[06:43] <spm> RAOF: sure. or take the unencrypted backup tapes :-D
[06:43] <RAOF> Indeed.  Whatever.  Physical access > *.
[06:44] <spm> Hence: Defence in Depth. Physical. Personnel. Logical. (sorry for lecture mode. used to teach this crap... ;-) )
[06:47] <lukehasnoname> spm, a/s/l
[06:47] <lukehasnoname> haha
[06:48] <lukehasnoname> I believe I am one of the younger people to hang around here on the IRC.
[06:49] <spm> lukehasnoname: us grumpy old farts were young once. just remember that. :-P
[06:50] <lukehasnoname> I'm sure. I've been realizing that more and more recently
[06:50] <pitti> Good morning
[06:50] <StevenK> Morning pitti
[06:51] <pitti> emgent: it's always better to do a normal upload to intrepid only, and an automated backport to hardy
[06:51] <Hobbsee> pitti!
[06:51] <pitti> emgent: manual uploads to *-backports should be avoided, and require a special rationale
[06:52] <pitti> kirkland: I am now
[06:52] <pitti> TheMuso: I already blacklisted it yesterday; testing and input appreciated
[06:52] <pitti> TheMuso: I know that it isn't ideal, but I think it's still better than living with those eternal squeaks and hangs
[06:53] <pitti> TheMuso: and if we don't have another solution, we can still re-enable kernel support for the old module?
[06:53] <pitti> hey StevenK, moin Hobbsee
[06:53] <TheMuso> pitti: Yeah I saw, I found a fix for the original problem I tried to fix in alsa-utils. I simply needed to move the calls to mute the pc speaker card to 0. It should be fine now. I have yet to upload alsa-utils, but I've tested the fix locally and it works.
[06:53] <pitti> TheMuso: but how is that different, in principle?
[06:53] <pitti> TheMuso: pc speaker keyboard beeps won't be audible?
[06:53] <TheMuso> pitti: Its because I forgot that udev calls the alsa init script for individual cards, so the reset for pc speaker mute wasn't being called.
[06:54] <TheMuso> pitti: Pc speaker beeps will still be audible. That is a different control for the mixer of the pcsp card.
[06:54] <pitti> TheMuso: ah, I see
[06:54] <TheMuso> If you were to load the pcsp module now, and check the mixer, you will notice a few controls, one is PC speaker which is the beeps.
[06:55] <TheMuso> The Master volume is separate and the one we are wanting to quash.
[06:55] <pitti> TheMuso: other thing, the reported hangs at session start in vmware et al, that won't change with changing the volume, will it?
[06:55] <TheMuso> pitti: I don't know. I don't have VMWare to test with.
[06:56] <pitti> TheMuso: happened to me in kvm, too; not very reliable, seems to be a race condition
[06:56] <pitti> I had it hang in vmware and kvm three times, then tried half a day later, and had it working in kvm
[06:56] <TheMuso> pitti: Is it anything to do with sound?
[06:57] <pitti> TheMuso: that's just what bug 246969 claimed
[06:57]  * TheMuso looks
[06:58] <pitti> no bugbot?
[06:58] <StevenK> Nope, ubotu is MIA
[06:59] <pitti> TheMuso: when I experienced the bug, playing the startup sound through pcsp took half a minute or longer, which could be well perceived as 'hanging'
[07:00] <TheMuso> pitti: Right, but the startup sound will not play through PC speaker any more, the only thing that can still be heard is crackling, which I have now found a better fix for.
[07:00] <pitti> TheMuso: how did you fix the former?
[07:00] <pitti> i. e. ignoring the card if it's there?
[07:00] <TheMuso> pitti: Patched pulseaudio to make sure that the last device it loads support for is pcsp.
[07:01] <TheMuso> pitti: Pulse doesn't ignore it, it just loads pcsp support last.
[07:01] <TheMuso> With my patch.
[07:01] <pitti> TheMuso: how does that help? if you don't have any other card, pcsp is the one that gets used
[07:01] <TheMuso> Prior to that, hal was giving pulse a list of devices, with pcsp at the top of the list.
[07:01] <pitti> and in VMs you very often don't have any other card
[07:02] <TheMuso> pitti: THis is true. I can blacklist the pc speaker from being used with pulseaudio entirely, however I have had some users say that pcsp is sometimes useful with pulse, believe it or not.
[07:04] <TheMuso> back in a bit
[07:05] <\sh> oh what a day...esx update works out of the box
[07:07] <Treenaks> \sh: it'd better, after yesterday
[07:08] <\sh> Treenaks: well, updates via update manager are still not working...but suspending all vm-machines, and applying the issued update package manually from the commandline works as expected..and all machines are coming back without any errors
[07:10] <TheMuso> back
[07:11] <TheMuso> pitti: Ok, after the alpha, I'll blacklist the PC speaker from pulse altogether, and we can unblacklist it.
[07:15] <superm1> pitti, I remember you had some chatter going on about usplash and uvesafb a week or so ago.  "should" things be stable on it right now?
[07:17] <pitti> superm1: stable in the sense of "it didn't change", but it's still broken
[07:17] <superm1> pitti, okay wasn't sure if i was having isolated incidents that i should file bugs on
[07:18] <superm1> but that clears that up :)
[07:20] <tjaalton> pitti: ok if I upload xorg which drops input devices from xorg.conf (irrelevant now anyway, and possibly only confusing)?
[07:20] <pitti> tjaalton: the a4 candidate CDs are in the middle of building
[07:20] <tjaalton> pitti: doesn't touch existing conf's
[07:20] <tjaalton> pitti: hum, ok
[07:21] <pitti> tjaalton: do you think that is critical for a4? if so, it's doable, just asking
[07:22] <tjaalton> pitti: not critical, just that people might be confused by seeing entries in the conf that have no meaning
[07:22] <tjaalton> forgot to upload earlier.
[07:23] <pitti> would you be fine with uploading it on Friday?
[07:23] <tjaalton> pitti: sure, no problem
[07:23] <pitti> if you are concerned that people get confused about it, feel free to add a caveat to the release notes (https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview)
[07:23] <pitti> tjaalton: ok, thanks
[07:23] <tjaalton> pitti: ok, that would work
[07:35] <tjaalton> pitti: done
[08:41] <pitti> TheMuso: oh, I just noticed that livefses are reeeally old, so they just didn't contain your latest fixes
[08:41] <pitti> ok, not that old, 20080808 built
[08:42] <pitti> now they fail with "couldn't find xresprobe"
[08:43] <StevenK>  xresprobe | 0.4.24ubuntu8 |         hardy | source, amd64, i386
[08:43] <StevenK>  xresprobe | 0.4.24ubuntu8 | intrepid/universe | source, amd64, i386
[08:43]  * pitti fixes livecd-rootfs
[08:43] <StevenK> pitti: ^
[08:43] <pitti> right, I was told xresprobe isn't necessary any more
[08:59] <TheMuso> pitti: right.
[09:36] <pitti> siretart: here by chance?
[09:40]  * pitti points tkamppeter at the soft freeze and the topic; please try not to break anything in intrepid ATM :)
[09:42] <ion_> tkamppeter: How would one go about testing the new PDF pipeline used by CUPS without wasting paper? I could of course print blank sheets, but is there a way to simulate and print the filter chain without printing?
[09:43] <Hobbsee> ah yes, that reminds me.  really should track down that printer bug.
[09:43] <ion_> Uh, s/simulate and print/simulate and dump/
[09:43] <pitti> ion_: you could set up a file:// queue?
[09:43] <ion_> pitti: Thanks
[09:43] <pitti> if you found out, that would make some nice test scripts
[09:43] <slytherin> Can anyone please sponsor the fix for bug 256949? I expected doko to do that by now, but he seems to have forgotten or missed it.
[09:44] <pitti> ion_: cups upstream has a test suite and runs it during build, but unfortunately the new filters aren't covered by that yet
[09:44] <pitti> slytherin: doko is on a conference
[09:44] <ion_> Ok
[09:44] <slytherin> pitti: so does that mean he will be available soon?
[09:45] <pitti> slytherin: no, not before next week
[09:46] <pitti> slytherin: I can upload that for you
[09:46] <tkamppeter> ion_, you can creat a printer which prints into a file. At first do
[09:46] <tkamppeter> cupsctl FileDevice=yes
[09:46] <tkamppeter> Then create a queue with URL file:/tmp/printout
[09:47] <tkamppeter> /tmp/printout will be of the format what the printer expects.
[09:47] <pitti> slytherin: uploaded, thanks
[09:47] <ion_> Alright
[09:47] <slytherin> pitti: Thanks. :-)
[09:48] <pitti> slytherin: once it's built and in the archive (ideally in about 1:10 hours), feel free to toss a list of packages to me which should be reattempted to build on powerpc
[09:48] <slytherin> pitti: sure.
[09:49] <tkamppeter> ion_ to get a PDF printing workflow you need a driver which already accepts PDF. This is currently gutenprint and other CUPS-raster-based drivers (others to follow).
[09:50] <tkamppeter> Second, use PDF as input format, by either using KDE or Qt apps for printing or by sending PDFs directly (lpr -P <printer> <file>.pdf).
[09:51] <pitti> tkamppeter: let's hope that once Mike integrates those filters upstream, they'll get tested in the test suite eventually
[09:52] <tkamppeter> pitti, I hope so, too, but he did not answer to CUPS bug 2897 yet ...
[09:54] <ion_> tkamppeter: I noticed cupsfilter and tried cupsfilter -p /etc/cups/ppd/HP_LaserJet_2300.ppd /usr/share/doc/gdb/refcard.ps.gz. It began processing it correctly by running /usr/lib/cups/filter/pstopdf, but that script failed because PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin/usr/bin (note the last item).
[09:55] <ion_> tkamppeter: I mean, cupsfilter itself printed: DEBUG: envp[6]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin/usr/bin"
[09:57] <ion_> tkamppeter: % strings =cupsfilter | grep usr/bin
[09:57] <ion_> %s/filter:/usr/bin:/usr/sbin:/bin/usr/bin
[09:59] <pitti> slytherin: the build made it quickly enough, so the after the next publisher (in 1 hour) it will be avilable
[10:00] <slytherin> pitti: Cool. I will keep list of packages ready. Should I split them by main/universe?
[10:00] <pitti> slytherin: for retrying the builds? not necessary
[10:01] <pitti> slytherin: I'd just appreciate if you could do the list with just spaces, no commas, and no "or", "and", etc. in between, so that it is cut&pasteable
[10:02] <slytherin> pitti: sure
[10:02] <tkamppeter> ion_ so the CUPS code contains a bad path? Looks like a bug in CUPS. But as all needed directories are there, this should not be the source of the problem.
[10:05] <tkamppeter> ion_, but cupsfilter has one problem: It does not report what the actually used filter chain is.
[10:06] <ion_> tkamppeter: I’m about to send a diff for cupsfilter. Oh, and it seems to print which filter commands it runs.
[10:10] <StevenK> pitti: Remind what needed libxsettings in main?
[10:10] <tkamppeter> ion_ for me
[10:11] <tkamppeter> cupsfilter -p /etc/cups/ppd/x.ppd ~/walking-map-portland-1.pdf > x
[10:11] <pitti> StevenK: matchbox-window-manager and libmatchbox
[10:12] <tkamppeter> says that gziptoany and no other filter was invoked, strange, as nothing is gzipped here.
[10:13] <tkamppeter> pitti, all printing-related uploads which I am doing currently cannot break the installation or the CD size. They do not introduce new dependencies.
[10:14] <pitti> "famous last words" :) , well, just be careful
[10:14] <pitti> breaking printing would be bad enough :)
[10:14] <tkamppeter> pitti, they are mainly changing PPD files and such so that PDF printing will work. Alpha 4 users should test the PDF workflow.
[10:15] <pitti> tkamppeter: right, but many alpha-4 CDs are already done
[10:15] <pitti> kubuntu is missing still, rest should already work
[10:15] <tkamppeter> If certain jobs do not print we have still two months to fix these cases.
[10:17] <Ng> ./win 69
[10:17] <Ng> gar
[10:17] <lifeless> nice number there
[10:18] <Ng> I really need to alias /win to /fail given how often I manage to type something else first ;)
[10:18] <tkamppeter> ion_ for better testing you should create a queue printing into a file and set debug mode. Then yiou can see the actual filter chains in error_log
[10:19] <ion_> tkamppeter: Alright
[10:22] <mcadetg> hi, I've a problem with lib/firmware when trying to compile/install vanilla kernel on ubuntu via the git/debian way...
[10:23] <mcadetg> I think the main problem is that dpkg -i linux-image tries to install firmware in /lib/firmware instead of /lib/firmare/$(uname -r)
[10:23] <mcadetg> can I configure this somewhere under the debian control directory?
[10:24] <ion_> tkamppeter: http://heh.fi/tmp/cups_1.3.8-4.debdiff
[10:24] <StevenK> pitti: Thanks, MIR coming soon.
[10:26] <tkamppeter> ion_, thanks. Please do also report a bug to CUPS upstream: http://www.cups.org/str.php
[10:27] <ion_> tkamppeter: Will do.
[10:30] <tkamppeter> ion_ I have found also another cupsfilter bug: I can print a JPG in a regular queue but not via cupsfilter. Seems that cupsfilter does not see all conversion rules.
[10:32] <StevenK> pitti: MIR for libxsettings is bug 257541
[10:42] <StevenK> pitti: I thought you NBS'd out gnustep-back0.12?
[10:43] <pitti> not yet, still wrestling with CDs
[10:44] <StevenK> pitti: If not, gnustep-back0.12 gnustep-back0.12-art libgnustep-base1.14 libgnustep-gui0.12 can all go.
[10:44]  * pitti -> back in ~ 1 hour
[10:53] <ion_> tkamppeter: I tried cupsfilter -m application/vnd.cups-postscript /usr/share/doc/gdb/refcard.ps.gz with the patched cupsfilter, it did gziptoany | pstops, i.e. didn’t do gziptoany | pstopdf | pdftopdf | pdftops. Should it have done that?
[10:54] <echo6> I'm looking for a method of enforcing mount read-only,  especially on a livecd,  there appears to be no way to enforce this using hal policies / gnome-mount. Is it possible that this can be remedied in future releases. Where should I post/email to bring this to the developers attention??
[10:54] <ion_> tkamppeter: I’ll try with a file printer next.
[11:14] <kirkland> pitti: hi, i was working on grub and I saw that both you and benc had also made some changes...  however, I was working off of a bzr branch, but I couldn't find your bzr branches
[11:51] <pitti> kirkland: I didn't do a bzr branch, just a regular upload; it doesn't have Vcs-Bzr:
[11:52] <pitti> kirkland: if it is in bzr, can you please add the Vcs header?
[11:52] <pitti> kirkland: my debdiff is attached to the bug
[11:53] <kirkland> pitti: hmm, when I do an apt-get source of grub, i see ....
[11:53] <kirkland> NOTICE: 'grub' packaging is maintained in the 'Bzr' version control system at:
[11:53] <kirkland> https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
[11:53] <slytherin> pitti: This is the list of packages with FTBFS on powerpc - ant bsh jakarta-log4j libjaxp1.3-java libmx4j-java libservlet2.4-java libxerces2-java sacjava libjdic-java
[11:54] <pitti> kirkland: oh, whoops *brown paperbag*
[11:54] <pitti> kirkland: sorry, I'll commit my change then
[11:54] <dholbach> this is the most hilarious piece of feedback on the Global Bug Jam: http://daniel.holba.ch/blog/?p=167#comment-92989
[11:54] <kirkland> pitti: cool, thanks.  i was thoroughly confused :-)
[11:55] <kirkland> dholbach: :-D
[11:56] <kirkland> dholbach: good point...  lady bugs are too cute to be a representative of truly nasty bugs :-)
[11:56] <dholbach> kirkland: tell kwwii - he did the logo :)
[11:57] <pitti> slytherin: all given back
[11:59] <kirkland> dholbach: ;-)  if you want an ugly bug, you have to go with a flea or a tick :-)
[11:59] <pitti> kirkland: oh, right, the bzr branch is horribly out of date
[11:59] <thorwil> uglier bug availabale for reuse: http://thorwil.files.wordpress.com/2008/01/banner_bugs_01_i.png ;)
[12:00] <pitti> kirkland: seems that we first need to commit the last 5ish uploads first
[12:00] <kirkland> pitti: i think benc may have done the same thing, possibly
[12:00] <kirkland> pitti: i have a bug fix for #33649 in https://code.launchpad.net/~kirkland/grub/33649b
[12:00] <ion_> Missing a ’s
[12:03] <pitti> kirkland: maybe you can grab the debdiffs from https://edge.launchpad.net/ubuntu/+source/grub and commit them one by one into the ubuntu branch? (sorry, I am pretty busy with RMing for alpha-4)
[12:04] <kirkland> pitti: let me see what I can do....
[12:04] <pitti> kirkland: oh, hang on, owned by -core-dev
[12:04] <kirkland> pitti: i'll do the work in my own
[12:04] <kirkland> pitti: and you can merge from there
[12:05] <pitti> kirkland: I'll commit them here, don't worry
[12:06] <pitti> kirkland: the raid fixes in the UNRELEASED commits are not yet in intrepid, right? (you are the current changelog owner)
[12:06] <kirkland> pitti: that is correct
[12:07] <pitti> ah, they were recently merged by slangasek
[12:07] <kirkland> pitti: kees gave verbal approval of those changes before the bzr/dsc diversion was discovered
[12:08] <kirkland> pitti: slangasek merged a downlevel version of that patch...  he asked me to fix a couple of things before releasing
[12:08] <kirkland> pitti: revision 841 in lp:~kirkland/grub/33649b is what i need sponsored and committed
[12:14] <pitti> kirkland: ok, all uploads committed to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu, and pushed
[12:14] <kirkland> pitti: awesome, thanks
[12:15] <kirkland> pitti: hang on...
[12:15] <pitti> merging your branch now
[12:16] <kirkland> pitti: that is a downlevel version of grub-install_better_raid.diff
[12:16] <pitti> 'that'?
[12:16] <pitti> pending merges:
[12:16] <pitti>   Dustin Kirkland 2008-08-11 This commit adds some smarts (back) into the handling of the multiple
[12:16] <kirkland> pitti: oh, wait...  looks like http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/changes is still showing new commits
[12:16] <pitti>     Dustin Kirkland 2008-08-11 slightly different approache to this problem, per IRC with slangasek...
[12:17] <pitti> kirkland: ^ that's what bzr merge lp:~kirkland/grub/33649b gives me now
[12:17] <kirkland> pitti: yes, that one is right
[12:17] <pitti> conflicts:
[12:17] <pitti>   Text conflict in debian/patches/grub-install_better_raid.diff
[12:17] <kirkland> pitti: a few seconds ago, Rev 839 was the top entry on http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/changes ;-)
[12:17] <pitti> kirkland: hm, maybe you can merge your branch against /ubuntu again, now that I pushed everything, and resolve the conflict?
[12:18] <pitti> I think you are in a better position to do that
[12:18] <kirkland> pitti: okay, let me do that
[12:22] <pitti> dendrobates, kirkland, zul: will the server team do the alpah-4 server CD testing again? (VMs are ok)
[12:23] <kirkland> pitti: yeah, i can help with some of that
[12:23] <kirkland> pitti:  i need to test a bunch of this raid stuff
[12:23] <pitti> kirkland: yes, don't worry, please finish that first
[12:23] <StevenK> pitti: Did you commit your livecd-rootfs changes to it's bzr branch?
[12:23] <pitti> StevenK: yes, I did
[12:23] <StevenK> pitti: Too distracted to do NBS stuff?
[12:23] <kirkland> pitti: will these grub changes make it onto that iso?
[12:24] <pitti> kirkland: I was just going to say, by default I wouldn't upload it, since most of the CDs are done already
[12:24] <pitti> and it sounds like intrusive changes
[12:24] <pitti> I'm always open for pings why this or that upload must make it to the CDs, of course
[12:25] <kirkland> pitti: hmm, well, mainly because this stuff really needs testing.  i can probably live without it
[12:25] <StevenK> pitti: If you're open for NBS stuff, please sync sear from Debian, no Ubuntu changes, builds fine, etc, etc, hand-wavy
[12:25] <kirkland> pitti: try: https://code.launchpad.net/~kirkland/grub/33649b
[12:26] <StevenK> pitti: If you commited, did you push? I can't see your changes by pulling from it.
[12:27] <pitti> StevenK: *cough* try again
[12:27]  * StevenK grins
[12:27] <StevenK> That looks better.
[12:28] <StevenK> Ah, and the sync too. Way cool.
[12:28] <pitti> StevenK: gnustep NBS goo removed, thanks
[12:29] <StevenK> pitti: From the directory too, or that needs a regen after a few go-rounds?
[12:29] <pitti> StevenK: just from the archive
[12:29] <slytherin> pitti: all packages build except one which has FTBFS for some different reason.
[12:29] <pitti> still needs publisher, et all
[12:30] <pitti> kirkland: merged, pushed; feel free to pull from lp:~ubuntu-core-dev/grub/ubuntu into your branch
[12:30] <StevenK> pitti: It's actually 'et al' :-)
[12:30] <pitti> I know, tpyo
[12:30] <kirkland> pitti: cool
[12:30] <StevenK> Teehhe
[12:31] <pitti> yohooooo
[12:31] <pitti> ubuntu livefs builds
[12:31] <StevenK> \o/
[12:31] <pitti> first since Sunday
[12:31] <kirkland> well, if you want to get really technical, it's "et alii" or "et alia"  :-)
[12:31] <StevenK> Or "et alibi" when refering to text
[12:31] <StevenK> Or "et alia" as well
[12:32]  * StevenK points kirkland at 'dict "et al"'
[12:33] <kirkland> StevenK: agreed ;-)
[12:47] <pitti> kirkland: btw, was it ever discussed to provide some helper script/app to move all secret data like gpg and ssh keys, the gnome and firefox keyrings, to ~/Private/?
[12:47] <pitti> kirkland: I'm pondering using ecryptfs instead of complete LUKS-lvm for performance reaons on my next desktop install
[12:47] <pitti> but I always have to manually move them across, etc.
[12:47] <kirkland> pitti: \o/
[12:48] <kirkland> pitti: it was discussed....  but the reception was cold/lukewarm
[12:48] <kirkland> pitti: i like the idea though
[12:48] <broonie> Perhaps .Private or similar since those are usually in hidden directories?
[12:49] <kirkland> pitti:
[12:49] <kirkland> rkland@t61p:~$ ls -al Private/
[12:49] <kirkland> total 24
[12:49] <kirkland> drwx------  6 kirkland kirkland 4096 2008-08-08 03:13 .
[12:49] <kirkland> drwx------ 93 kirkland kirkland 4096 2008-08-13 06:40 ..
[12:49] <kirkland> drwx------  2 kirkland kirkland 4096 2008-08-13 06:12 .gnupg
[12:49] <kirkland> drwx------  4 kirkland kirkland 4096 2008-08-13 06:21 .liferea_1.4
[12:49] <kirkland> drwx------  4 kirkland kirkland 4096 2008-02-14 06:59 .mozilla
[12:49] <kirkland> drwx------  2 kirkland kirkland 4096 2008-07-26 21:49 .ssh
[12:49] <kirkland> drwxr-xr-x  9 kirkland kirkland 4096 2008-08-12 14:17 .evolution
[12:49] <kirkland> pitti: that's what I'm running in my Private on a daily basis
[12:49] <kirkland> pitti: kees suggested liferea as a pseudo-stress test, as he's had trouble with that dir on NFS mounts before
[12:50] <pitti> kirkland: ah, you are putting the entire .mozilla there? including cache?
[12:50] <kirkland> pitti: yup
[12:50] <sistpoty|work> must be for some reason :P
[12:50] <kirkland> pitti: i'm symlinking everything back to their natural homes
[12:50] <pitti> kirkland: ah, I was just going to ask
[12:51] <pitti> usually I keep ~/.gnupg where it is and set secret-keyring /media/PittiCrypt/gpg/secring.gpg
[12:51] <pitti> (from the time I used a LUKS-encrypted usb stick to carry my secret stuff)
[12:51] <kirkland> pitti: that's a good idea
[12:51] <kirkland> pitti: one thing to consider....
[12:51] <pitti> because the pubring is huge and not sensitive
[12:51] <kirkland> pitti: you're going to want encrypted swap as well
[12:51] <pitti> and just my secret ssh key, not the entire dir
[12:51] <kirkland> pitti: in that passphrases could get swapped to disk
[12:52] <pitti> kirkland: well, I'm trying to achieve some more speed
[12:52] <kirkland> pitti: right, totally
[12:52] <pitti> kirkland: usually most programs should use mlock() properly, but that doesn't help for hibernate, of course
[12:52] <kirkland> pitti: encrypting all of /usr, /lib, and so forth is a waste
[12:57] <kirkland> pitti: i'd love to get your feedback on encrypted Private, if you do it
[12:58] <zul> pitti: I can do some of it
[12:58] <pitti> zul: great, thanks
[12:59] <pitti> zul, kirkland, dendrobates: we don't need exhaustive coverage, but at least some smoke test and the particular server features you are interested in; e. g. no need to exercise all partitioning options, since they are the same on the normal alternates
[13:02] <tseliot> pitti: I've been hacking on Jockey today and now it is possible to distinguish between a recommended version of a driver and the other versions
[13:02] <tseliot> pitti: the only thing I'm not sure about is how you would like to highlight the recommended version: bold, underline, etc.
[13:04] <tseliot> pitti: I've got the following screeshots of the gtk GUI (the last screenshot is of the QT4 gui):
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-bold.png
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-underline.png
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-recommended.png
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-kde-bold.png
[13:04] <tseliot> pitti: let me know what you think
[13:05] <pitti> tseliot: how does jockey find out which driver is recommended?
[13:07] <tseliot> pitti: I had to add an is_recommended() method  to XorgDriverHandler. It can only return False. The NVIDIA handler overrides this method with one
[13:07] <pitti> tseliot: ah, shouldn't that be on Handler, not just on XorgDriverHandler?
[13:07] <tseliot> which uses nvidia-common and returns either True or False if self.package == recommended
[13:08] <tseliot> pitti: I can move it there if you wish
[13:08] <pitti> mpt might have an opinion, too, but personally I like the [recommended] best, since it's most obvious
[13:09] <tseliot> pitti: then I added this to backend.info:  'is_recommended': str(h.is_recommended())
[13:09] <pitti> tseliot: that sounds good; please adapt the test cases accordingly
[13:10] <tseliot> pitti: and both GUIs will see if self._(info['is_recommended']) is True or False and set the markup accordingly, that's all
[13:10] <tseliot> pitti: ok
[13:10] <pitti> tseliot: please don't call _() on boolean values
[13:11] <pitti> tseliot: those are not strings which need to be l10n'ed
[13:11] <tseliot> pitti: where?
[13:11] <pitti> tseliot: tseliot| pitti: and both GUIs will see if self._(info['is_recommended'])
[13:13] <tseliot> pitti: ah, right, I'll use info['is_recommended'] instead
[13:13] <pitti> right ... == 'True'
[13:13] <pitti> (I know, it's weird, but doesn't work otherwise over D-BUS)
[13:14] <tseliot> pitti: yes, I know that it's a string and not a bool. Otherwise it wouldn't have worked here ;)
[13:14] <tseliot> pitti: which screenshot do you prefer?
[13:14] <pitti> tseliot: as I said, the [recommended] one; mpt, WDYT?
[13:14] <pitti> oh, not online
[13:14] <tseliot> pitti: sorry, I didn't see it
[13:15] <pitti> tseliot: which one do you prefer?
[13:15] <tseliot> pitti: maybe the one in bold
[13:16] <tseliot> pitti: I will also clean up the x-kit part of Jockey
[13:16] <pitti> tseliot: btw, the place where you should use _() is the actual string, like '<b>[%s]</b>' % self._('recommended')
[13:17]  * ion_ shivers at explicit ‘self’.
[13:17] <tseliot> pitti: and isn't it info['is_recommended'] ?
[13:18] <pitti> tseliot: no, info['is_recommended'] is the boolean, whereas 'recommended' is the string you show (or not) in the UI
[13:18] <pitti> ion_: jockey's AbstractUI._() is magic, it translates keyboard shortcuts in GNOME and KDE, etc.
[13:19] <pitti> so that we avoid duplicating strings just because of & vs. _
[13:19] <tseliot> pitti: sorry, I meant info['name']
[13:19] <pitti> tseliot: I'm confused, what's with name? what's the question?
[13:19] <tseliot> pitti: ok, I see your point now.
[13:20] <tseliot> pitti: info['name'] is the one which we put in the row of treeview
[13:20] <tseliot> and therefore the one which we put in bold or whatever
[13:21] <tseliot> if we add the "[Recommended]" string to the name
[13:21] <tseliot> then we'll have to translate Recommended too
[13:21] <tseliot> pitti: it's ok, don't worry
[13:22] <pitti> right
[13:23] <tseliot> pitti: therefore if we choose to use the word "Recommended", I will add it to ui.py
[13:24] <tseliot> pitti: oh, and you don't mind if I use nvidia-common to detect the recommended version, do you?
[13:25] <pitti> tseliot: as long as that logic is in the NvidiaHandler, that's fine
[13:25] <tseliot> pitti: yes, it's only there. Ok, then
[13:27] <tseliot> pitti: also, is there anything I can do for the progress bar or are you waiting for packagekit?
[13:27] <pitti> ouch, apparently grub created a menu.list with /dev/hda1 in that amd64 desktop install, but it's boot=/dev/sda1
[13:28] <pitti> tseliot: I don't think full PK will make it, that dbus-glib bug is a real blocker, and I don't know a workaround
[13:28] <pitti> tseliot: so I guess we have to resort to using python-apt, and its progress callbacks
[13:29] <tseliot> pitti: ok, I'll have a look at it then
[13:29] <pitti> tseliot: great! (sorry, no time this week, I am the RM in charge for alpha-4)
[13:29] <pitti> and problems pop up all over the place, as usual
[13:30] <tseliot> pitti: no problem, I'll see what I can do.
[13:31]  * pitti hugs tseliot
[13:32] <tseliot> ;)
[13:33] <pitti> kirkland: do you happen to know, do we still put things like root=/dev/hda1 into grub's menu.list?
[13:34] <pitti> I mean, do we *mean* to
[13:34] <pitti> (on my desktop installation I just have root=/dev/mapper/foo, which is fine)
[13:35] <kirkland> pitti: i'm not sure i understand your question
[13:36] <kirkland> pitti: my laptop is root=/dev/mapper/vg0-lv0, like you say
[13:36] <pitti> kirkland: I mean, shuold I get UUIDs or device nodes in menu.list?
[13:36] <kirkland> pitti: UUIDs, i think
[13:36] <kirkland> pitti: my RAID-testing vm has root=UUID=29175762-644b-439d-a763-ab15298ef799
[13:37] <kirkland> pitti: which is /dev/md0
[13:38] <pitti> kirkland: right, in an alternate install I get UUIDs, in a desktop install I get device nodes
[13:38] <pitti> which causes a boot failure for me
[13:39] <kirkland> pitti: i should think that UUIDs would be preferred
[13:39] <pitti> since the desktop install added /dev/hdXX, but the device node is /dev/sdaXX
[13:39] <pitti> kirkland: absolutely
[13:39] <kirkland> pitti: for that reason ^  :-)
[13:39] <pitti> argh
[13:39] <kirkland> pitti: does ubiquity use something different?
[13:39] <pitti> and ENOCOLIN to tell us how it's all plumbed together
[13:40] <pitti> kirkland: apparently
[13:40] <kirkland> pitti: see the grub-installer package
[13:41] <kirkland> pitti: that's what's run in the alternate installer at least
[13:41] <kirkland> pitti: i have no idea about the desktop
[13:45] <pitti> "Cannot determine root device. Assuming /dev/hda1"
[13:45] <pitti> bummer
[13:58] <pitti> kirkland: ah, no /etc/fstab, so it's probably not grub-installer
[13:58] <kirkland> pitti: ah
[14:09] <pitti> does anyone happen to know some bits about ubiquity? in particular, which part writes (or currently fails to write) /etc/fstab?
[14:38] <cr3> pitti: would you happen to know which wiki page describes the process for renaming a package in intrepid?
[14:39] <pitti> cr3: I don't think we have one
[14:39] <cr3> pitti: hm, what would you recommend I do?
[14:39] <pitti> best option: avoid it
[14:39] <pitti> second best: upload the new package with a Conflicts/Replaces/Provides: old-name
[14:39] <pitti> and have a transitional package under the old name which depends on the new name
[14:40] <pitti> and keep that transitional one until the next LTS
[14:48] <cr3> pitti: regarding the transitional package, I'm not sure how I understand how it can depend on the new name when the new package conflicts with the old name
[14:50] <cr3> pitti: also, is the transitional package just an empty shell in order to address dependency concerns?
[14:50] <sistpoty|work> cr3: the magic is the combination of conflicts and replaces of the new package, which will force the transitional package to uninstall (at least iirc)
[14:51] <cr3> sistpoty|work: cool, I'll give it a whirl
[15:15] <seb128> pitti, mvo: would it be possible to add an apport hook in compiz to report what nvidia binary driver is being used? there is lot of crashes in libGL coming from nvidia users and I'm not sure where to reassigning those nowadays
[15:15] <jorgenpt> Hiya. Is this the right channel to ask about packaging?
[15:15] <jorgenpt> (i.e. creating packages)
[15:16] <seb128> jorgenpt: not really, try #ubuntu-motu rather
[15:16] <jorgenpt> Ok, thanks. :)
[15:18] <pitti> seb128: right, so far you just know that a reporter is using any nvidia-driver-*, not the version
[15:19] <pitti> anyone with nvidia on intrepid? does "modinfo nvidia" show the version anywhere?
[15:28] <seb128> MacSlow: do you use nvidia on intrepid?
[15:29] <MacSlow> seb128, I'm not on intrepid on my nvidia box yet
[15:29] <seb128> ok
[15:29] <MacSlow> seb128, what issues are there?
[15:29] <MacSlow> general Xorg or compiz?
[15:29] <seb128> MacSlow: just to reply to pitt's question before
[15:30] <MacSlow> ah
[15:30] <seb128> MacSlow: no, just trying to include informations on the nvidia driver version in compiz bugs because they are often due to the nvidia driver
[15:30] <tjaalton> pitti: I've got one back home, but it's not on currently
[15:30] <pwnguin> i hear rumors that the new nvidia triage system is to mark them "wontfix" and ask users to run "nvidia-report-bug.sh" instead
[15:31] <tjaalton> right
[15:31] <MacSlow> seb128, pitti: for some reason I always use -> glxinfo | grep "OpenGL version"
[15:31] <tjaalton> there are hundreds of nvidia/fglrx bugs that we can do nothing about
[15:31] <MacSlow> seb128, pitti: never modinfo
[15:31] <MacSlow> seb128, pitti: at least regarding graphics-drivers
[15:31] <seb128> tjaalton: I don't aim to do something about those, they should just not be assigned to compiz
[15:32] <seb128> tjaalton: and knowing what libGL is used would help to reassigning to mesa or nvidia drivers too
[15:32] <tjaalton> seb128: for the time being you can assign them against nvidia-graphics-drivers-*
[15:32] <pwnguin> -*?
[15:32] <tjaalton> versino
[15:32] <tjaalton> -on
[15:32] <seb128> tjaalton: I did reassigning the new one to -177 but I'm not sure that's right
[15:32] <seb128> tjaalton: that's why I was asking
[15:33] <seb128> tjaalton: looks like some recent nvidia update makes compiz crash a lot in intrepid
[15:33] <tjaalton> seb128: maybe -177 for all of them, since the others are a dead end
[15:33] <seb128> ok will do that, thanks
[15:33] <tjaalton> mine works, GF8600GT
[15:33] <seb128> and again one, grrr
[15:33] <tjaalton> heh :)
[15:35] <pitti> seb128: a specific compiz.py package hook can just do some dpkg -l nvidia* of course
[15:35] <pitti> seb128: but if it can be seen from modinfo, we can extend the generic "NonfreeModules:" field
[15:36] <seb128> pitti: that would be nicer
[15:36] <seb128> bug #256340 is this new nvidia crash
[15:37] <seb128> can we add "crash on any package in _nv000071gl()" as a hook?
[15:37] <pitti> if there are so many, then a bug pattern might be adequate?
[15:37] <seb128> pattern I mean
[15:37] <pitti> seb128: s/hook/pattern/?
[15:37] <pitti> yes
[15:37] <seb128> not "so many" yet, but I reassigned 3 of those today already
[15:38] <seb128> and who knows how long it'll take to get a fixed nvidia update
[15:38] <pitti> seb128: "_nv000071gl () from /usr/lib/libGLcore.so.1" in StackTraceTop should do
[15:38] <pitti> StacktraceTop, even
[15:39] <pitti> seb128: but we don't have packageless patterns, so for now it should be against compiz
[15:40] <seb128> pitti: right that was my question, the "any package" part
[15:40] <seb128> I guess compiz will get most of those crashes
[15:40] <seb128> so that should be good enough
[15:41] <seb128> pitti: hum, there is a retracer or apport bug somewhere
[15:41] <seb128> pitti: see bug #257124
[15:42] <seb128> pitti: it has eaten all the attachments
[15:43] <pitti> seb128: whoops, WTH? did you see that more often?
[15:44] <seb128> pitti: a few times since yesterday yes
[15:44] <pitti> https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/257124/+activity shows additions, but no removals
[15:45] <seb128> pitti: I bounced you the launchpad mail about the attachments removal
[15:45] <pitti> seb128: thanks
[15:47] <seb128> pitti: and since when does the retrace change the private status? I though somebody had to check the stracktrace before doing that?
[15:47] <pitti> seb128: it's only supposed to do that for duplicates
[15:47] <pitti> seb128: it removes attachments, makes it public, marks it as a dup
[15:48] <pitti> maybe it crashed on the latter
[15:48] <seb128> I'll keep an eye and let you know about buggy cases
[15:48] <pitti> anything in the retracer log for that bug?
[15:48]  * pitti chases another alpha-4 failure ATM
[15:48] <seb128> pitti: 08/13/08 11:15:45: retracing #257124 exit status: 0
[15:49] <pitti> seb128: did it say that it is a dupe?
[15:49] <seb128> pitti: the bug has been retraced twice
[15:49] <pitti> aaaah
[15:49] <seb128> maybe that's a buggy case
[15:49] <pitti> I bet apport got confused and tried to mark it as a dup of itself
[15:49] <seb128> pitti: I did retag it since the first retracing failed to produce a good stacktrace
[15:49] <pitti> but that would be weird
[15:49] <pitti> we often retag
[15:50] <seb128> well the log is weird, it's only line for this bug
[15:50] <seb128> usually there is a
[15:50] <seb128> "E: You must put some 'source' URIs in your sources.list
[15:50] <seb128> Report has no crash signature, so retrace is flawed
[15:50] <seb128> Duplicate check negative"
[15:50] <joaopinto> has anyone else experienced bug 254060 ?
[15:50] <seb128> anyway I'll keep an eye on it
[15:51] <joaopinto> It turns the system unusable with a regular boot
[15:55] <james_w> joaopinto: I think there may be another bug on that
[15:56] <joaopinto> I get into gdm with the warning that my home dir is not available, checked with ps, checkfs was still running
[15:57] <james_w> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/255563
[15:57] <james_w> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/255562
[15:57] <james_w> they're the ones I was thinking of
[15:59] <joaopinto> My symptom is different. My system seems to boot normally and gdm runs fine. Shouldn't I get the "Do you want to skip?" notice ?
[15:59] <joaopinto> oh, its equal to the second bug
[16:00] <joaopinto> time to set mine as duplicate
[16:03] <joaopinto> I would also appreciate if someone could check bug 254177 , since it is not a clean install, I may have changed some configuration related to the problem
[16:11] <pwnguin> there's a lot on the ML about CD space -- does the install CD use lzma-squash?
[16:12] <pwnguin> err, squashfs-lzma
[16:12] <tjaalton> pitti: modinfo nvidia does not say anything about the version
[16:12] <pitti> tjaalton: thanks
[16:13] <broonie> tjaalton: the nvidia module prints its version when it loads, if there's not been much kernel output it should be in dmesg
[16:13] <tjaalton> broonie: true
[16:18] <devfil_> pitti: can yo do the giveback at php5 source? it builds fine
[16:18] <pitti> devfil_: nothing to give back, it already built fine
[16:19] <devfil_> pitti: I'm looking http://qa.ubuntuwire.com/ftbfs/, maybe it needs to be updated, however great
[16:30]  * pitti hopes that the sync flood won't break the alphas
[16:37] <pitti> Keybuk: you don't happen to have an ubiquity expert up your sleeve?
[16:38] <pitti> Keybuk: I'm afraid we have to release alpha-4 without desktop CDs, I don't think that there's a way for me to learn ubiquity code and do the rest of the release until tomorrow :(
[16:38] <Keybuk> heh, *I* haven't got evan ;)
[16:38] <Keybuk> I think he's chasing Mark's stewardess round San Francisco or something <g>
[16:39] <pitti> lol
[16:39] <Keybuk> (desperately trying to prove to the world that he's not gay - despite being in SF, and wearing the cowboy hat he got in TX :p)
[16:41] <pitti> ok, can't help it then
[16:41] <superm1> pitti, what sort of trouble is it?
[16:41] <pitti> superm1: bug 257580
[16:42] <pitti> and the isntaller syslog doesn't talk about fstab at all, until grub-installer fails on its absence
[16:44] <superm1> i thought partman is actually responsible for spitting out the fstab?
[16:45] <pitti> superm1: right, but I didn't find anything helpful in the partman log either
[16:45] <superm1> pitti, could you perhaps run ubiquity in debug mode and attach the same types of information?
[16:45] <pitti> superm1: sure
[16:48] <pitti> superm1: how did that work again, sudo UBIQUITY_DEBUG=1 ubiquity ?
[16:48] <superm1> pitti, i thought ubiquity -d should do the trick
[16:49] <pitti> superm1: that seems to work, yes
[16:50] <superm1> pitti, there should then be an extra log that is in /var/log/installer after you get your failure too
[17:10] <pitti> superm1: reading partman-target scripts now, but it doesn't even seem to get to finish.d
[17:11] <pitti> nor does it give any helpful log info in the partman log...
[17:11] <pitti> grep target /var/log/partman is completely empty
[17:20] <mpt> ArneGoetje, did you see S'orlok Reaves' message about Burmese input on ubuntu-devel-discuss@?
[17:22] <pitti> superm1: done
[17:22] <superm1> pitti, okay i'll take a glance this afternoon and see if anything stands out to me
[17:22] <pitti> superm1: thank you
[17:23] <pitti> superm1: I wonder why it works in d-i, but not in ubiquity; it uses the same code, shouldn't it?
[17:23] <superm1> should be
[17:30] <ArneGoetje> mpt: yes
[17:31] <ArneGoetje> mpt: didn't have time to answer yet
[17:31] <mpt> ok
[17:33] <LaserJock> seb128: is your last comment in bug #248163 still the plan?
[17:34] <seb128> LaserJock: yes, nm0.7 is in intrepid and it allows to do static configurations, what exactly can't you do using it?
[17:35] <LaserJock> static eth0
[17:35] <seb128> it allows to do that
[17:35] <LaserJock> spent 20min this morning trying to get it to work
[17:35] <seb128> asac: ^
[17:35] <LaserJock> whenever I try the "OK" button is greyed out
[17:35] <LaserJock> it won't save any configuration
[17:36] <LaserJock> unless it's DHCP
[17:36] <seb128> LaserJock: here it's right click on the nm icon, edit connection, select the connection, change, IPv4 settings, enter the infos
[17:36] <LaserJock> right
[17:36] <LaserJock> when I do that the "OK" button is greyed out
[17:36] <seb128> LaserJock: did you enter the prefix informations, it's a different column and not intuitive
[17:36] <LaserJock> so all I have is "Cancel" which is less than helpful
[17:37] <LaserJock> yes, I filled it out completely as far as I know
[17:37] <seb128> ie, you need to set the network mask there
[17:37] <LaserJock> yep
[17:37] <LaserJock> every column and entry line is filled in
[17:37] <LaserJock> search path, etc.
[17:37] <seb128> LaserJock: what "prefix" did you use?
[17:37] <LaserJock> 255.255.255.0
[17:37] <seb128> I just tried setting an IP and a mask and the ok is unblocked
[17:38] <seb128> can you make a dialog screenshot?
[17:38] <LaserJock> yeah, just got to do some rebooting since I have to do networking in Hardy ;-)
[17:38] <seb128> ah
[17:38] <LaserJock> brb
[17:38] <pitti> asac: do you have some time for the "NM 0.7" section in https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview ? or, alternatively, tell me what to point out?
[17:38] <seb128> LaserJock: wait
[17:38] <LaserJock> seb128: yeah?
[17:39] <seb128> LaserJock: I get the issue when selecting "manual"
[17:39] <LaserJock> yeah
[17:39] <LaserJock> is that not what I want?
[17:40] <seb128> LaserJock: anyway "network-manager has a bug" is not a good reason to install network-admin
[17:40]  * LaserJock is used to "DHCP" and "static"
[17:40] <seb128> LaserJock: let's fix the bug rather
[17:40] <LaserJock> seb128: well, it's a lot more convenient that NM, but I understand your point
[17:40] <seb128> LaserJock: it was working when I tried some time ago, must have been broken since
[17:40] <LaserJock> NM is generally a pain in the butt for me
[17:40] <seb128> LaserJock: let's make NM convenient? if the dialog is not easy enough to discover or the UI sucks could you make suggestions?
[17:41] <seb128> LaserJock: well, there is no reason the "edit connection" in network-manager could not be similar to network-admin
[17:41] <LaserJock> it's just that it does everything automatically and I'm rarely in an environment where networking should be automatic
[17:41] <seb128> LaserJock: the way forward is to fix network-manager, not to write a buggy, complicated, written in perl, non actively maintained, application
[17:42] <LaserJock> for instance, it seems to try to fight between wireless and eth0
[17:42] <pitti> LaserJock: really? what's a good use case of not using dhcp in an eth network nowadays? (that's an honest question, I'm curious)
[17:42] <seb128> LaserJock: I've used nm0.7 to configure my wired static eth interface and that works fine
[17:42] <LaserJock> can I tell it to use one or the other without constantly shutting stuff off and on?
[17:42] <LaserJock> pitti: I have no idea, I've just never found a use for DHCP personally
[17:43] <pitti> as in, it would make things too easy and just work? :)
[17:43] <LaserJock> pitti: at uni we're all static IPs, at home I like to assign IPs so I can easily port-forward
[17:43] <LaserJock> most of it (uni) is out of my control
[17:43] <seb128> you can assign IPs using dhcp too ;-)
[17:43] <pitti> LaserJock: static IP assigment doesn't collide with dhcp
[17:43] <pitti> to the contrary, you have a central management for them
[17:44] <pitti> that's what I do for our house (8 flats with 8 families)
[17:44] <LaserJock> well, I'm not going to argue networking with the experts ;-)
[17:44] <pitti> we need to keep IPs for the way our ISP does its accounting
[17:44] <pitti> LaserJock: no, I was just really curious about use cases for manual setting of IPs
[17:44] <ion_> Yeah, DHCP is really useful for assigning static IP addresses.
[17:44] <pitti> because I think it's cumbersome, error prone, and quicky becomes unmanageable
[17:45] <pitti> so I wondered whether there are cases where dhcp isn't adequate
[17:45] <LaserJock> pitti: I've only got one place (uni wifi) that uses DHCP
[17:45] <sistpoty|work> pitti: if you don't have a dchp server... e.g. spontaneous lan party with friends in a garage *g*
[17:45] <pitti> and whether we might mitigate those
[17:45] <sistpoty|work> (good old days)
[17:45] <pitti> sistpoty|work: for that I'd recommend ipv4ll :)
[17:45] <sistpoty|work> heh
[17:45] <pitti> plug a cable between the two, and there they go negotiating an 169.254. address
[17:45] <pitti> (works since feisty)
[17:46] <LaserJock> pitti: so in my case not using DHCP is just a matter of 1) uni doesn't do it for ethernet yet 2) in my house it was easy to assign IPs
[17:46] <pitti> sistpoty|work: that's a good use case, actually, and one where the particular IPs don't matter at all, just that they are all different and in the same subnet
[17:46] <pitti> LaserJock: 1) is a very good reason, of course (your ISP doesn't give you one)
[17:47] <LaserJock> yes, that's the troublesome case, because right now Intrepid gives me *no* network connectivity at the uni
[17:47] <LaserJock> it used to be eth0 was a given and wireless was hard to set up
[17:47] <LaserJock> we're quickly going the opposite ;-)
[17:48] <pitti> LaserJock: back to /etc/network/interfaces then? that should work
[17:48] <pitti> nm should ignore the interface in this case
[17:48] <LaserJock> yikes, maybe
[17:48] <LaserJock> that's what I used to do
[17:48] <LaserJock> but then NM would barf, and cause problems
[17:48] <pitti> that's where network-admin saves its configuration, too
[17:48] <pitti> LaserJock: that needs to be fixed then
[17:48] <LaserJock> ok, maybe I'll give it a go and see
[17:49] <pitti> (independent of any shiny GUI)
[17:49] <pitti> it's an upgrade issue, and all that
[17:49] <pitti> LaserJock: ok, thank you!
[17:49] <LaserJock> first I'll try to see if there's something in the NM connection editor that'll let me save the config
[17:50] <LaserJock> it seems like it *should* work in the UI, so it's perhaps a bug there
[17:50] <LaserJock> and if I can keep NM around without it causing problems it'd be nice
[17:50] <Keybuk> ooh
[17:50] <Keybuk> I made LWN
[17:50] <Keybuk> http://lwn.net/Articles/293689/
[17:51] <LaserJock> apps seem to be wanting to use NM more and more to determine network connectivity, which is a real pain
[17:51] <ion_> Subscription required
[17:51] <Keybuk> ion_: LWN is well worth the fee
[17:52] <liw> I second that
[17:52]  * sistpoty|work heads home... cya
[17:53] <tseliot> pitti: does progress_cb exist (in oslib)?
[17:55] <tseliot> pitti: you use it in OSLib.install_package()
[18:01] <LaserJock> sooo, got it to work
[18:01] <LaserJock> NM still has "OK" greyed out but /etc/network/interfaces had the information
[18:01] <LaserJock> but resolve.conf was empty
[18:02] <LaserJock> so once I put the nameservers in resolv.conf and ifup eth0 I got a connection
[18:02] <pitti> tseliot: it's a function passed as a parameter to install_package()
[18:02] <pitti> tseliot: install_package() has to call it regularly with current progress numbers
[18:02] <pwnguin> if the ACM can publish Linux proceedings to the wider public
[18:02] <pitti> tseliot: see the dummy implementation in the ubuntu branch
[18:06] <tseliot> pitti: I had a look at backend.Backend.install_package() and at jockey-gtk (from the ubuntu branch). Did I missing anything?
[18:06] <pitti> Keybuk: interesting, I wasn't aware that our udev rules delta was still that big
[18:07] <pitti> tseliot: the thing which calls apt-get with a dummy feedback is jockey/oslib.py, install_package(), in teh ubuntu branch
[18:07] <pitti> that ideally would use python-apt and real progress
[18:08] <pitti> Keybuk: (why does that remind me of Mao so much? "WTF - Your rule?" -- "My rule!"
[18:11] <tseliot> pitti: yes, I saw it and backend.Backend.install_package() calls OSLib.inst.install_package() right?
[18:12] <tseliot> pitti: what I don't get is what the parameters passed to OSLib.inst.install_package() mean
[18:13] <tseliot> pitti: the name of the package and either True or None, right?
[18:18] <tseliot> pitti: but according to install_package in oslib, the 2nd argument should be a function
[18:45] <pitti> tseliot: no, as the docstring says, it's the name of the package, and a function
[18:45] <pitti> def my_progress_cb(phase, cur, total):
[18:45] <pitti>     foo
[18:45] <pitti> OSLib.inst.install_package('pmount', my_progress_cb
[18:50] <tseliot> pitti: maybe I'm looking at the wrong branch. Let me get the code again
[18:51] <tseliot> pitti: ubuntu-core-dev/jockey/ubuntu right?
[18:51] <pitti> tseliot: yes, sounds right
[18:51] <pitti> tseliot: the callback is defined in the GUI, the OSLib implementation calls it
[18:54] <tseliot> pitti: in which directory do I find the file with the example? tests, example, jockey?
[18:54] <pitti> tseliot: example for what?
[18:54] <tseliot> pitti: OSLib.inst.install_package('pmount', my_progress_cb
[18:55] <tseliot> the one you mentioned before
[18:55] <pitti> tseliot: oh, I just invented that from scratch in IRC
[18:55] <pitti> tseliot: the ubuntu branch's oslib.py has an implementation using apt-get
[18:55] <tseliot> pitti: yes, I've noticed that
[18:59] <tseliot> pitti: and does this call in backend mean anything? OSLib.inst.install_package(package, hasattr(self, '_locations') and self.install_progress or None)
[19:01] <tseliot> pitti: I'm just trying to figure out where is the function which you pass to install_package() together with the name of the package.
[19:01] <pitti> tseliot: ah, that's a bit tricky, it should have a comment
[19:01] <pitti> tseliot: you know what "condition and a or b" does in Python?
[19:02] <pitti> tseliot: similar to C's ? :
[19:02] <pitti> tseliot: if condition is true, the value of that expression is a, if condition is false, it's b
[19:02] <tseliot> is it like the conditional operator "?"
[19:02] <sbeattie> LaserJock: what did you do to figure out how to get a static address in Network Manager?
[19:02] <tseliot> yes, it's like that
[19:03] <tseliot> pitti: I knew it only in C and not in python
[19:03] <LaserJock> sbeattie: well, in my case I put in all the information but it won't let me save it
[19:03] <pitti> tseliot: ah, there is a comment
[19:03] <LaserJock> sbeattie: but when I looked at /etc/network/interfaces it was all there
[19:03] <sbeattie> LaserJock: I can't even get it to do let me enter information under xubuntu
[19:03] <LaserJock> sbeattie: hmm
[19:03] <pitti> tseliot: so in practice that means that self.install_progress is the function that oslib install_package() calls
[19:04] <sbeattie> LaserJock: http://www.nxnw.org/~steve/tmp/xubuntu-network-manager.png
[19:04] <pitti> tseliot: hasattr(self, '_locations') is a way to check if your object is a dbus.service.Object instance (at least the best I could fine)
[19:04] <pitti> tseliot: s/fine/find/)
[19:04] <sbeattie> If I unclick "auto eth0" it just automatically requests a new dhcp address.
[19:05] <tseliot> pitti: ok, it makes sense now
[19:05] <LaserJock> sbeattie: if you right click on NM do you get "Edit Connections"
[19:05] <pitti> tseliot: JFYI, it's not exactly like C's ? :
[19:06] <sbeattie> LaserJock: ah, for some reason when I right-clicked before I didn't get anything, but there it is.
[19:06] <pitti> tseliot: "TRUE : 0 : 1" is 0 in C, but "True and 0 or 1" is 1 in Python
[19:06] <pitti> tseliot: (due to the way 'and' and shortcut evaluation work in Python)
[19:07] <pitti> tseliot: but for everything that isn't regarded as False, i. e. 0, None, [], {}, and set(), the and/or construct works
[19:07] <pitti> tseliot: I don't use it often, but sometimes in my tired hours I get lazy :)
[19:08] <pitti> bbl, doing install testing
[19:08] <tseliot> pitti: aah, thanks for the explanation
[19:09] <pitti> tseliot: so the short rule is "and/or works as long as the "true-case" value is not False
[19:11] <tseliot> pitti: ok
[19:14]  * tseliot > dinner. bbl
[19:15] <mdz> something is causing all of my Places to be opened in totem-xine rather than nautilus
[19:16] <mdz> can someone give me a pointer as to where to look for the problem?
[19:18] <Treenaks> mdz: the mime database?
[19:18] <Treenaks> (and the new xine package vs the old one)
[19:18] <ted2> mdz: See what the command "gnome-open" does with the directories.
[19:18] <mdz> ted2: it does the right thing
[19:18] <mdz> MimeType=x-content/video-dvd;x-content/video-vcd;x-content/video-svcd;
[19:18] <mdz> seems correct enough
[19:19] <ted2> mdz: That's really odd.  Places in the panel?
[19:19] <mdz> ted2: yes
[19:20] <mdz> ted2: the Bookmarks menu in nautilus does the right thing
[19:20] <ted2> Makes me want to just blame the panel then, if all those work.
[19:20] <mdz> happens both with the stock bookmarks like Pictures, as well as those I've added
[19:20] <mdz> I don't know why the panel should have a different idea of how to handle file types
[19:20] <mdz> or where its settings would be if it did
[19:20] <ted2> The problem is that you've got a lot working :)
[19:24] <ted2> I don't see any settings for that either.  How odd.
[19:25] <ted2> totem-xine is the new konquerer.  :)
[19:26] <mdz> aha, I found it
[19:26] <mdz> /home/mdz/.local/share/applications/mimeapps.list:inode/directory=totem-xine.desktop;nautilus-folder-handler.desktop;
[19:26] <mdz> I wonder where that came from
[19:26] <mdz> I must have done 'Open with...' to launch totem-xine on a DVD folder
[19:27] <mdz> I wonder why it didn't affect gnome-open or nautilus
[19:29] <ted2> They both must have hard coded directory.
[19:42] <kirkland> mdz: ping, regarding the degraded RAID y/n prompt
[19:45] <seb128> mdz: nautilus doesn't look at this to open directory, it just open those
[19:46] <seb128> mdz: gnome-open is still using gnome-vfs and doesn't look at mimeapps.list which is a new gio thing
[19:49] <superm1> pitti, i identified what's happening re the fstab
[19:49] <superm1> pitti, it looks like it gets created properly, but when the filesystem copy begins, it gets overwritten by the one thats in the squashfs
[20:07] <jpds> pitti: In your buildd.py, are MOTU/core-dev capable of using the "rescore" operation, or is that just for buildd admins?
[20:10] <pitti> re
[20:10] <pitti> jpds: that's just for buildd-admins, I believe
[20:10] <jpds> pitti: OK, thanks.
[20:10] <pitti> superm1: oh, bugger
[20:11] <superm1> pitti, i think i've gvot an idea of a quick hack that might get around it
[20:11] <superm1> pitti, not necessarily the way that evan and colin will want to put in the end, but that should suffice for a4 to get out the door
[20:12] <pitti> superm1: in ubiquity, or in livecd-buildfs? (removing fstab, perhaps)
[20:13] <superm1> pitti, in ubiquity
[20:13] <superm1> pitti, although removing fstab in livecd-buildfs would probably solve it too
[20:13] <pitti> superm1: a hack in ubiquity could be tested right on the live CD, so that's a bit safer
[20:14] <pitti> superm1: what's the plan, like stash it into /etc/fstab.real, and move it over after squashfs copying?
[20:14] <superm1> pitti, okay give me a sec and verify that it works on this end (i'm doing an install here).  i'll post a diff momentarily
[20:14] <pitti> superm1: you rock
[20:17] <pitti> superm1: I just compared the squashfses in hardy and intrepid
[20:17] <pitti> hardy has a default fstab, too
[20:17] <superm1> pitti, some extra magic was added recently in ubiquity that does a file by file unlinking if files exist though
[20:18] <superm1> pitti, which i believe is what's triggering this
[20:18] <superm1> pitti, http://paste.ubuntu.com/37224/ appears to resolve it for me.  if you want to go the ubiquity route, i'll add that to ubiquity bzr and get an upload ready for it
[20:20] <pitti> superm1: ah, I see how http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/2753 has caused that
[20:21] <pitti> superm1: maybe we should just revert that commit for now?
[20:22] <superm1> pitti, well i believe that commit is correct, this is just an odd exception because its the only file written to etc prior to the squashfs copy
[20:22] <pitti> superm1: right, that would have been my next question
[20:22] <pitti> 'do we create any other files in /target before copying'
[20:22] <superm1> pitti, since partman has to run so early, i think this is the only one that it happens with.
[20:24] <pitti> ok, there are a couple of files matching "fstab" in my system, but none prefixed with etc/ (except for /etc/fstab)
[20:25] <pitti> superm1: so I believe your hack should work
[20:25] <pitti> superm1: so, let's use that for a4
[20:25] <pitti> superm1: did you already run a full install test with this applied? or shall I?
[20:26] <tkamppeter> pitti, I need your help.
[20:27] <pitti> superm1: how should we go on, do you have time to prepare the branch and test the fix? and I'll do the uploading/beating throuhgh publisher/CD rebuild/test afterwards? I need 30 minutes for getting some food
[20:27] <pitti> tkamppeter: what's up? I'm about to leave for half an hour
[20:28] <superm1> pitti, i just ran through an install and it did work
[20:28] <pitti> superm1: rocking
[20:28] <tkamppeter> pitti, can you send an e-mail to heno telling him that I sent him several e-mails and did not get any answer from him. Perhaps some spam filter does not let my e-mail come to him.
[20:28] <superm1> pitti, i can add it to the branch right now if you can upload from the branch after i add it
[20:28] <pitti> superm1: sure, will do
[20:28] <pitti> checking out in the meantime
[20:34] <pitti> tkamppeter: he's on holiday
[20:34] <Keybuk> Why are kernel developers so afraid of patches?
[20:34] <pitti> Keybuk: as in "not a git commit but a flat file", or as in "accept changes from other people"?
[20:34] <Keybuk> accept changes
[20:35] <Keybuk> I strongly object to having udev rules like this:
[20:36] <Keybuk>   KERNEL=="hw_random", NAME="hwrng"
[20:36] <Keybuk> especially in the default, hard-coded, non-modifiable udev rules
[20:36] <Keybuk> that says the kernel calls it one thing, but everybody calls it something else
[20:36] <pitti> you mean, then the kernel could just name it hwrng right away? agreed
[20:36] <Keybuk> (including the LANANA Device Names list)
[20:36] <Keybuk> exactly
[20:36] <Keybuk> a *one line* patch to the kernel fixes that
[20:36] <alex-weej> fight the power
[20:36] <Keybuk> I also object to having rules like this:
[20:37] <alex-weej> doesn't ubuntu maintain its own git repo of the kernel anyway?
[20:37] <Keybuk>   KERNEL=="mice", NAME="input/mice"
[20:37] <Keybuk> the kernel could just include DEVNAME=input/mice in the uevent
[20:38] <tkamppeter> pitti, until when? I asked here a lot and no one could tell me this.
[20:38] <pitti> superm1: what do I need to do to turn this into a source package?
[20:39] <superm1> pitti, me to push one more commit, and then debuild -S -sa should do it
[20:39] <superm1> pitti, you might need to run debian/rules update-local too though
[20:39] <superm1> or debian/rules update
[20:39] <superm1> it's been a while since i made a fresh tree to see
[20:39] <pitti> superm1: if you have a ready-made checkout, maybe you can build the source pacakge, too, put it somewhere, and I just sign it?
[20:40] <tkamppeter> pitti, it is about https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format why I want to talk with heno.
[20:40] <pitti> superm1: AFAIK it needs to fetch/include some packages fromd-i?
[20:40] <superm1> pitti, yeah that's what the debian/rules update stuff does
[20:40] <pitti> tkamppeter: according to the holiday calendar he should be back next Monday
[20:41] <pitti> superm1: local checkout still running, remote checkout in developer chroot might screw it up, I dunno
[20:41] <pitti> superm1: ah, debian/rules update looks good
[20:41] <pitti> it fetches them from teh archive
[20:43] <pitti> superm1: ok, nevermind, I think I got it right
[20:44] <pitti> superm1: debdiffing my created source against 1.9.8 is sane
[20:44] <pitti> superm1: so I just wait for your second commit
[20:44] <pitti> superm1: that's just UNRELEASED -> intrepid and tag?
[20:45] <superm1> pitti, doing it right now, i was looking up the last part to do
[20:45] <superm1> modifying configure* and then debian/changelog and then its good to go
[20:46] <superm1> pitti, okay if you pull revno 2767, that should be good to go
[20:46] <pitti> got it
[20:48] <pitti> superm1: uploaded
[20:48] <pitti> superm1: thanks muchly!
[20:48] <superm1> pitti, great.  no problem :)
[20:48] <pitti> now I head out for a bit and let it build and publish
[20:48] <tkamppeter> pitti, you can access a holiday calendar? Can I do so, too?
[20:49] <pitti> tkamppeter: I don't think so, no; sorry