[00:16] <jdstrand> lamont: *sigh* I forgot a postrm snippet in the bind9 patch
[00:17] <jdstrand> lamont: I didn't see that you committed yet
[00:18] <ScottK2> jdstrand: Would that explain: Reloading AppArmor profiles /sbin/apparmor_parser: Unable to replace "/usr/sbin/named".  Profile doesn't conform to protocol
[00:18] <jdstrand> ScottK2: no, this is an uncommitted patch
[00:19] <ScottK2> OK.
[00:19] <jdstrand> ScottK2: was that on hardy?
[00:19] <ScottK2> jdstrand: Is ^^^ something I should file a bug on then?
[00:19] <ScottK2> Yes
[00:19] <jdstrand> ScottK2: absolutely
[00:19] <ScottK2> Just dist-upgraded from Gutsy to hardy.
[00:19] <ScottK2> That was during the upgrade.
[00:19] <jdstrand> ScottK2: oh-- no that is expected until reboot
[00:20] <ScottK2> Ah.  OK.  So if it perists after reboot, then file a bug?
[00:20] <jdstrand> ScottK2: yes
[00:20] <ScottK2> perists/persists.
[00:20] <ScottK2> OK.
[00:21] <ScottK2> Rebooting then...
[00:21] <jdstrand> ScottK2: the protocol did change in the kernel, and the profile takes advantage of it
[00:22] <ScottK2> That was the most exciting thing that happened using apt-get dist-upgrade.
[00:22] <ScottK2> So that's good news then.
[00:23] <slangasek> asac: thanks for triaging your milestoned bugs :)
[00:23] <jdstrand> ScottK2: heh
[00:23] <lamont> jdstrand: I didn't push it
[00:23] <jdstrand> lamont: yeah I saw
[00:23] <jdstrand> lamont: I just emailed to LP
[00:23] <lamont> want me to push so you have something to fetch and generate a change against?
[00:24] <jdstrand> lamont: no, I'm good
[00:24]  * lamont goes looking
[00:24]  * jdstrand *just* sent it
[00:25] <lamont> well, I'm after-hours so I'm not exactly looking at my mailbox and such
[00:25] <jdstrand> lamont: I wasn't sure LP or your mailbox would have it yet ;)
[00:25] <jdstrand> LP does though
[00:26] <lamont> heh.  yeah, we'll want that patch
[00:26] <jdstrand> yeah, a dangling symlink would be a no-no
[00:26] <jdstrand> thanks lamont!
[00:27] <lamont> meh.  -s dude
[00:27] <lamont>   [Jamie Strandboge]
[00:27] <lamont>   * apparmor: force complain-mode for apparmor on certain upgrades.  LP: #203528
[00:27] <lamont>   * debian/bind9.postrm: purge /etc/apparmor.d/force-complain/usr.sbin.named Signed-off-by: Jamie Strandboge <jamie@canonical.com>
[00:28] <lamont> what version of git are you running???
[00:28] <jdstrand> 1:1.5.4.3-1ubuntu1
[00:28] <lamont> hrm
[00:28] <jdstrand> I did:
[00:28] <jdstrand> git add foo
[00:28] <lamont> and it looks like you said -s
[00:28] <jdstrand> git commit -s
[00:29] <lamont> and something wrapped it up onto line 1.
[00:29] <lamont> maybe it wants a blank line or it sucks them together?
[00:29] <lamont> so you're ready for me to upload -8 then?
[00:30] <jdstrand> lamont: that would be fantastic
[01:03] <lamont>   bind9_9.4.2-8_i386.changes: done.
[01:03] <lamont> Successfully uploaded packages.
[01:04] <lamont> jdstrand: there you go.  convincing slangasek to take it before beta is left as an exercise
[01:04] <lamont> if he blesses it, I'm happy to upload a -7ubuntu1 == -8
[01:04] <jdong> lol I'm not sure how to argue a bind security vuln in an esoteric function as a beta blocker :)
[01:05] <slangasek> lamont: what's the incentive for this being in beta?
[01:05] <lamont> jdong: nah - that was just there and I kicked it
[01:05] <jdong> It doesn't help with heart attacks for certain.
[01:05] <jdong> (apologies for medical pun)
[01:05] <lamont> slangasek: it fixes apparmor the way jdstrand and the rest of the crackheads want it
[01:05] <lamont> which gets bind9 testing on upgrades prior to release
[01:05] <slangasek> jdong: you only need to apologize for coming up with a medical pun before I had a chance to
[01:05] <lamont> and why am _I_ trying to argue his point for him???
[01:05] <jdong> slangasek: I'm sorry :)
[01:06] <lamont> slangasek: it's certainly not a beta-blocker.
[01:06] <lamont> nor even an alpha-blocker
[01:06] <slangasek> lamont: because you're here and I'm here :)
[01:06] <lamont> hell, it's not even desktop.  although ISTR it _is_ shipseed, yes?
[01:06] <lamont> heh. point
[01:07] <slangasek> it's on server, whatever that seed's called
[01:07] <jdong> slangasek: I'll save the alpha blocker pun for you. It could be inflammatory.
[01:07] <slangasek> heh
[01:08] <lamont> slangasek: the issue I have is that, well, it's _tuesday_.  and I don't personally see it as worth holding the show for.  OTOH, it's barely _in_ the show, since next to nothing actually depends on the packages.
[01:08] <lamont> i guess bind9-host or dnsutils might have made it into standard?
[01:09] <lamont> yep
[01:09] <lamont> *2.  I win
[01:10] <lamont> slangasek: I _DO_ most certainly want it in before beta is a couple of days old.  I don't particularly care which order they arrive in
[01:10] <lamont> esp since doing it "right" means waiting until after tomorrow's dinstall run...
[01:11] <slangasek> lamont: ok,well, to have it in for beta I think I would need a more eloquent justification than "the crackheads want it". :)
[01:12] <lamont> slangasek: given that if I was in your shoes, the answer would be "-1 until friday", I have a hard time coming up with a better argument....
[01:12] <slangasek> pitti: hnngh, this apport is making me want to take out a red pen and correct the spelling of the python class names
[01:13] <slangasek> pitti: but somehow I don't think that's appropriate during a beta freeze ;)
[01:13] <lamont> slangasek: if you stab it in the eye, it doesn't have to start as a red pen...
[01:13] <slangasek> s/apport/& diff/
[01:36] <ScottK> slangasek: It would be nice to have pitti's apport upload at or soon after beta as we are currently getting almost no automatic crash reporting on Guidance bugs due to an issue that's fixed in that upload.
[01:36] <slangasek> ScottK: already accepted
[01:37] <ScottK> slangasek: Thanks. (need to be careful what I ask for, I may get it).
[01:52] <xjkx> i have a question that i believe only the devs know. i am studying the boot thing, trying to boot it using a grub config, i put the kernel to be the casper/vmlinuz, and the initrd to be casper/initrd.gz. But it stops booting in the middle of the process and gives me a simple bash ! what am i missing ? i've read the isolinux.cfg file trying to figure out any cool parameters, and i found boot=casper and some others but nothing seems to work
[01:53] <xjkx> on isolinux.cfg we have  file=/cdrom/preseed/ubuntu.seed is it important ? i dont think grub has that special word "file"
[01:55] <xjkx> so i am not using the "file" thing on grub config
[01:55] <xjkx> i forgot to mention i am trying to boot the livecd, on grub.
[01:56] <xjkx> i have a grub in disk
[02:01] <wasabi> Hmm. So any plans to do stuff to the updator that asks to replace config files?
[02:01] <wasabi> It's sort of going to hit people as we start introducing more user friendly ways to edit config files (system-config-printer comes to mind)
[02:01]  * lamont ->home
[02:02] <wasabi> I don't think my mom is capable of making a decision on which lines of cupsd.conf she should merge.
[02:02] <xjkx> wasabi, are you a dev ?
[02:03] <wasabi> Define 'dev'?
[02:03] <wasabi> xjkx: Sounds like it's not able to find /   Does it say unable to mount ROOT?
[02:03] <wasabi> And it sounds like you're screwing with casper. Which most likely means a livecd
[02:05] <xjkx> wasabi, errm, developer...? no it doesn't say unable to mount root. i think it does mount, it gives me a shell i can do some simple commands, wait, i will bot it now and tell you how exactly it is
[02:06] <wasabi> (initramfs)?
[02:06] <xjkx> yes
[02:06] <wasabi> You need to start by explaining what you're trying to do.
[02:06] <xjkx> i have a grub inside the disk, and i want to load ubuntu trough it :)
[02:07] <xjkx> i told where the kernel is, and it boots the kernel, but i think it wants something else
[02:07] <wasabi> You need to start by explaining what you're trying to do.
[02:08] <xjkx> "Busybox v 1.1.3 (debian 1:...) built-in shell (ash) initramfs." this is what i get, no error messages :( what i am trying to do is to boot the livecd from grub ;)
[02:09] <wasabi> So you're in the initramfs.
[02:09] <xjkx> yes
[02:09] <xjkx> which is not where i want to be
[02:09] <wasabi> And a message was spit out to the initramfs?
[02:10] <xjkx> no, just the initramfs, like if it was bash $
[02:11] <wasabi> There should have been a message printed out.
[02:11] <wasabi> Above the prompt.
[02:11] <wasabi> I fnot, read the casper script. :)
[02:11] <TheMuso> wasabi: That doesn't always happen.
[02:11] <xjkx> busybox v 1.3...enter help...is that ?
[02:11] <xjkx> thats what is above
[02:11] <wasabi> Nope.
[02:11] <wasabi> Read the casper scrpt.
[02:11] <TheMuso> wasabi: I actually reported a bug against the kernel this morning related to similar simptoms, usually udev/kernel can't resolve a device node/block device type etc.
[02:12] <wasabi> udev should be async. initramfs waits for ROOT
[02:12] <TheMuso> In my case, there was no message.
[02:12] <wasabi> After 5 minutes, you should get a message.
[02:12] <wasabi> He's doing stuff with casper.
[02:12] <wasabi> which I'm just not familiar enough with
[02:12] <TheMuso> wasabi: Sorry, this was also related to the live CD.
[02:12] <TheMuso> And particular modes that my new machine's mobo's SATA controllers can be set to...
[02:12] <xjkx> where is the casper script
[02:13] <TheMuso> Within the initramfs, it is /scripts/casper
[02:13] <wasabi> boot=casper refers to /scripts/casper-*
[02:13] <TheMuso> It may be easier however to download the casper bzr branch and read things that way.
[02:14] <wasabi>  /scripts is in the initramfs. Just install casper on a desktop machine and look at it in /usr/share/initramfs-tools/
[02:14] <wasabi> Or use bzr
[02:14] <wasabi> or cat from the initramfs. :)
[02:14] <xjkx> maybe /scripts is on a installed system, i see no scripts folder anywhere inside the live mounted image, but there is a /casper
[02:14] <wasabi>  /scripts is in the initramfs
[02:14] <xjkx> oh
[02:15] <xjkx> will check
[02:26] <xjkx> wasabi, i am reading with cat file |more. and seeing no reason for it to stop there :p
[02:26] <xjkx> usually, it stops on initramfs for what reason ?
[02:27] <wasabi> ROOT does not appear.
[02:27] <wasabi> Or it hits a break point.
[02:27] <wasabi> xjkx: break it early in the process and run each step manually.
[02:27] <wasabi> And just see what does not work right
[02:30] <xjkx> speaking of root, i did not specify any root= parameter on grub part "kernel /casper/vmlinuz", if i am supposed to put, what should i ? root=/cdrom ? or it should not have the root= on kernel anyway ? By typing F6 to see what parameters casper gets, i saw no root= :p
[02:31] <xjkx> not sure if it means something but the root folder on initramfs is empty
[02:40] <xjkx> wasabi, i found a way to get a error message above, by removing some parameters :p here it is: check root= bootargs. or missing modules, dropping to a shell
[02:40] <xjkx> i am almost sure its the root= thing
[02:40] <xjkx> just not what to put on it
[02:42] <TheMuso> xjkx: A live CD normally does not have a root= specified.
[02:42] <TheMuso> I'm running an amd64 disk now on another box, and its nowhere to be found in the kernel command-line.
[02:42] <TheMuso> When you specify to boot casper, its assumed that you are booting into a live filesystem.
[02:43] <xjkx> yea, it should work the way it is :/ grub has the vmlinuz, and the initrd, what else it wants...not even god knows i think hehe
[02:43] <TheMuso> xjkx: Got another box you can try on?
[02:44] <xjkx> i tried both my father's and mine
[02:44] <xjkx> not sure if you were reading since the beginning what i am trying to do. i am trying to boot it not the normal way, but using grub, ever tried doing that ? :p
[02:45] <TheMuso> xjkx: Yes, but in this case, I don't think grub is the problem.
[02:45] <TheMuso> However, the output of cat /proc/cmdline from within the intiramfs would help to make sure of this.
[02:45] <TheMuso> initramfs
[02:45] <StevenK> I thought the LiveCD used syslinux, anyway
[02:45] <wasabi> It does. No reason you can't load the kernel/initramfs with grub.
[02:45] <xjkx> it uses isolinux to boot, if thats what you mean
[02:46] <superm1> and actually i have loaded it's kernel/initramfs from grub
[02:46] <wasabi> I have a flash based system using casper that does that.
[02:46] <superm1> make sure you use the one in the casper/ directory though
[02:46] <wasabi> Stores the root file system on a FAT32 partition on a CF disk.
[02:46] <superm1> (there are two kernels on the disk)
[02:59] <xjkx> someone here recommended me a cat /proc/cmdline, and it shows only the parameters i gave to kernel, in this case, i have a boot=casper, i had more, i even copied all the F6 button shows on the normal booting
[02:59] <xjkx> when i pass nothing to kernel, cat /proc/cmdline is empty
[03:01] <TheMuso> xjkx: Mind posting the contents of /proc/cmdline please?
[03:02] <xjkx> thats it. boot=casper, only :P
[03:02] <xjkx> what were you expecting ?
[03:02] <TheMuso> More than that, thats for sure.
[03:02] <xjkx> maybe we found the problem, if there should be that lot of things
[03:03] <xjkx> here it just shows the parameters i pass to kernel
[03:03] <TheMuso> xjkx: Sounds to me like you haven't included everything on the command-line that is found in isolinux.cfg.
[03:03] <xjkx> if i want it to don't return anything by cat /proc/cmdline, i'd just remove the boot=casper in the kernel arguments
[03:04] <xjkx> not this time, but i had one more complete, wait, i will show you my last one
[03:06] <xjkx> file=/preseed/ubuntu.seed boot=casper quiet splash
[03:07] <TheMuso> hrm ok.
[03:07] <xjkx> its what we see in isolinux.cfg: ppend  file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz quiet splash --
[03:07] <TheMuso> xjkx: And the standard live CDs boot fine, i.e with isolinux?
[03:07] <xjkx> yes
[03:07] <TheMuso> I'm out of ideas.
[03:08] <xjkx> yea its a bit complex hehe
[03:10] <lifeless> whats up
[03:10] <xjkx> all the other distributions worked on that grub thing just reading isolinux.cfg, and only ubuntu is driving me crazy with that :p maybe i should try older versions
[03:11] <xjkx> lifeless, trying to boot the live with grub. whats up there ?
[03:12] <lifeless> well it should work
[03:12] <lifeless> reading scrollback
[03:12] <xjkx> TheMuso, my last guess is that grub doesn't know the word FILE that isolinux uses
[03:13] <xjkx> yea, it should :/
[03:13] <lifeless> you need a full valid grub config, I am pretty sure grub can't parse isolinux.cfg
[03:14] <xjkx> yea, what would you put on grub to load the casper kernel on the live ?
[03:15] <lifeless> I can't remember offhand
[03:16] <lifeless> but basically I'd read the isolinux.cfg, then tell grub the kernel, init, and the boot parameters
[03:16] <lifeless> which will need ot include root=, boot=, etc
[03:17] <xjkx> yea, i kinda did that, except the root= part, because there is none on isolinux.cfg
[03:17] <xjkx> and i woldn't know what root= would look like
[03:17] <xjkx> to a cdrom
[03:17] <lifeless> boot up using isolinux
[03:17] <lifeless> and look at proc/cmdline
[03:18] <xjkx> good idea :p but it wouldn't stop on initramfs
[03:18] <lifeless> add break=premount to the command line using advanced mode
[03:18] <lifeless> or boot the etnire way and look once its loaded
[03:19] <xjkx> :o lets see
[04:25] <lamont> jdstrand: Mar 18 21:33:29 mix kernel: [178113.278726] audit(1205897608.689:44):  type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/var/lib/misc/shadow.db" pid=31082 profile="/usr/sbin/cupsd"
[04:25] <lamont> I find that annoying.
[04:26] <lamont> (nsswitch pointing at 'db' makes lots of stupid things try to read the shadow.db file.  this is a bug.
[04:27] <lamont> (including gnome-screensaver... most annoying when one cannot unlock the screen...)
[04:49] <neh> is there anything I can do with bug 172300 so that it doesn't get overlooked for hardy?
[04:57] <xjkx> lifeless, i passed the exact same parameters and still did not work, i am giving up :P
[04:57] <xjkx> exact same as cat /proc/cmdline on the normal live
[05:02] <TheMuso> xjkx: Any reason why you want to use grub?
[05:04] <xjkx> yes, multiboot
[05:05] <TheMuso> xjkx: Does isolinux not work for that?
[05:06] <xjkx> not sure
[05:07] <xjkx> never really used isolinux :p and i am much more familiar with grub anyway
[05:07] <sladen> xjkx: never boot an Ubuntu CD ?
[05:08] <sladen> xjkx: never booted an Ubuntu CD ?
[05:10] <xjkx> i did, but never edited the things myself
[05:10] <xjkx> i used the config they created for me, i mean, you created for me
[05:11] <xjkx> TheMuso, but thats a good point, i will google isolinux to do what i want
[05:11] <xjkx> maybe there is a hope
[05:12] <xjkx> TheMuso, sladen are you a dev?
[05:13] <TheMuso> xjkx: Yes I am.
[05:13] <TheMuso> But my knowledge of isolinux/grub is practically non-existant.
[05:15] <xjkx> can i ask what do you do as a developer ? i frankly have no clue on how they split the jobs, and i wouldn't know how to help if i could, or what to study to help out
[05:19] <TheMuso> xjkx: Well, I got involved because I was interested in helping improve a particular area of Ubuntu, and thats how everybody else gets involved. Find something that you are interested in, and learn about it. If you want to make it better, thats the perfect place to start.
[05:20] <TheMuso> xjkx: You always tend to want to learn more if it is for something you are interested in working on.
[05:21] <xjkx> oh, I see. thanks.
[05:24] <TheMuso> xjkx: You're welcome.
[06:22] <ogra_cmpc> WOAH
[06:22] <ogra_cmpc> did anyone here ever try "gnome-session --help" in a commandline ?
[06:22] <ogra_cmpc> *try
[06:22] <ogra_cmpc> (dont do it)
[06:22] <TheMuso> ogra_cmpc: lol
[06:23] <ogra_cmpc> thats *evil*
[06:23] <TheMuso> Let me guess. It starts GNOME dispite the --help flag?
[06:23] <ogra_cmpc> yeah
[06:23] <tjaalton> not here
[06:23] <TheMuso> Why am I not surprised.
[06:24] <ogra_cmpc> tjaalton, what do you get ?
[06:24] <tjaalton> gnome is running already though :)
[06:24] <tjaalton> ogra_cmpc: a summary of the options
[06:24] <ogra_cmpc> i didnt let it start up fully, but it attempts to start the session here
[06:24] <slangasek> neh: currently that bug is marked as 'incomplete'; do you know what information is missing, and can you provide it?
[06:25] <slangasek> neh: bug #172300, that is
[06:25] <ogra_cmpc> tjaalton, is that hardy ?
[06:26] <tjaalton> ogra_cmpc: yep
[06:26] <ogra_cmpc> strange
[06:27] <ogra_cmpc> hmm, k, might haven been fixed since 2.21.93-0ubuntu1 (which is what this classmate image has)
[06:27] <ogra_cmpc> i'll check again on another image before filing a bug
[06:27] <tjaalton> this box was dist-upgraded yesterday
[06:28] <ogra_cmpc> yeah, dist upgrading is a bit to much for that tiny thing here
[06:38] <neh> slangasek: not sure I can provide the requested info for that bug, so I'll try to get in touch with ogasawara_ and see how I can help
[06:39] <neh> ogasawara_: let me know how I can help with bug #172300 ... I made the latest comment on it and would be happy to help get it fixed if I can.
[06:39] <ogra_cmpc> asac, cant answer you in pm with that account :) but had my mobile ready ;)
[06:39] <ubotu> neh: Error: Could not parse XML returned by Ubuntu: HTTP Error 404: Not Found
[06:40] <Amaranth> Hobbsee: seems your bot has problems...
[06:40] <slangasek> neh: currently, the missing information is "what happens if you boot with the irqpoll" option - do you know how to edit your boot options?
[06:40] <Hobbsee> Amaranth: damn.  it was working.
[06:41] <neh> slangasek: my machine boots fine with irqpoll, and never finishes booting without it
[06:41] <slangasek> neh: then I guess that's the missing info ogasawara_ requested, perhaps you could send that to the bug report?
[06:41] <slangasek> neh: and follow the link on the side panel to 'nominate' the bug for hardy
[06:42] <neh> slangasek: I mentioned that in the comment I already made on the bug
[06:42] <slangasek> neh: oh, so you did; sorry, I'm half blind and half distracted
[06:43] <Hobbsee> Amaranth: has there been a LP release or something in between?
[06:43] <warp10> Good morning
[06:43] <Amaranth> Hobbsee: probably
[06:44] <slangasek> neh: in that case, nominate the bug as I mentioned; I'll also reset the bug state to 'triaged'
[06:44] <neh> slangasek: heh, I guess it is buried in the comment, easy to miss.
[06:44] <neh> and I just nominated it
[06:44] <slangasek> ok
[06:44] <slangasek> that should get it on the radar, I think
[06:45] <Hobbsee> Amaranth: *mutter*  *grumble*
[06:45]  * Amaranth wonders how psyco would make a completely IO bound python app go faster
[06:46] <RAOF> Amaranth: Is this something that you're seeing?
[06:46] <Amaranth> RAOF: No, something a user claims to see in a bug report where they ask me to add psyco support
[06:46] <neh> slangasek: Great. I really hope it gets fixed, it would be strange to have an ubuntu release not boot on my machine. :-)
[06:47] <RAOF> Amaranth: To what?  Alacarte?
[06:47] <Amaranth> yeah
[06:47] <RAOF> Um... yeah.  Right.
[06:47] <RAOF> Completely _user_ bound.
[06:47] <ogasawara_> neh:  care to attach your dmesg output to the bug report
[06:49] <neh> ogasawara_: from a regular gutsy boot?
[06:49] <Hobbsee> Amaranth: yeah, iehter i'm using it wrong, fo they've changed the xml.  *sigh*
[06:49] <ogasawara_> neh: preferably hardy
[06:50] <Amaranth> RAOF: hey, that's part of the I ;)
[06:50] <RAOF> Amaranth: True :)
[06:50] <asac> ogra_cmpc: thx ;)
[06:51] <dholbach> good morning
[06:51] <Hobbsee> morning dholbach
[06:51] <Amaranth> wow, some guy gave me _way_ too much information for what is an obvious dupe of the "broken titlebar on maximized windows" bug
[06:51] <Amaranth> morning dholbach
[06:51] <dholbach> hiya Hobbsee
[06:51] <dholbach> hey Amaranth
[06:52] <neh> ogasawara_: ok, I can only boot hardy with irqpoll when both drives are attached, so will that do?
[06:53] <ogasawara_> neh: that's fine.  would you also be able to maybe attach a digital photo of your screen when you boot without irqpoll?  Just curious what the errors are.
[06:55] <ogasawara_> neh:  it's bedtime here for me so I'll check the report again in the morning
[06:55] <neh> ogasawara_: sleeptime for me as well, I'll get you the info as soon as I can. thanks for looking at the bug. :-)
[07:07] <ogra_cmpc> asac, the first image didnt rip out the cron scripts for scrollkeeper and mandb, i guess cron kicked in
[07:08] <asac> ogra_cmpc: ok. i can do a fresh install if you say that there are better images available
[07:09] <ogra_cmpc> asac, the 20080318 one should be the best so far, just running the build for  the 19 image
[07:10]  * highvoltage is on the 20080318 image and it installed and seems to be working without a hitch
[07:10] <highvoltage> (will do some proper testing tonight though)
[07:10] <asac> ogra_cmpc: if you provide me a link i can test it
[07:11] <ogra_cmpc> http://people.ubuntu.com/~ogra/classmate/images/hardy/
[07:11] <asac> though this particular bug probably takes a day to show up
[07:11] <ogra_cmpc> you can now zsync the images if you like
[07:11] <ogra_cmpc> instructions are on the page
[07:31] <pitti> Good morning
[07:32]  * ogra_cmpc waves at pitti 
[07:32] <pitti> slangasek: apport spelling fixes> bug report appreciated :)
[07:32] <StevenK> Morning pitti
[07:34] <slangasek> pitti: s/subscribtion/subscription/g :)
[07:35] <pitti> slangasek: that's a bug in p-lp-bugs...
[07:35] <pitti> oh, heh, it was fixed recently
[07:36] <pitti> bugbase.py:    subscribtions = subscriptions = (property decl)
[07:37] <slangasek> oh, ok :)
[07:37] <pitti> slangasek: fixed in trunk, thanks
[07:44] <ogra_cmpc> heh, why did i read bugbabe.py above
[07:47] <pitti> ogra_cmpc: Freud would have an answer, I'm sure
[07:47] <ogra_cmpc> heh
[07:47] <slangasek> probably one involving insects, given Freud
[07:47] <Amaranth> asac: the only other useful information i could automatically grab from the system is .xsession_errors and output from lspci but that's only useful for blacklisting bad cards/drivers
[07:47] <Amaranth> i can't make apport automatically run compiz under valgrind :)
[07:48] <slangasek> heh
[07:48] <asac> Amaranth: hmm. nothing else that might help to narrow down? ... e.g. like loaded kernel modules and so on?
[07:48] <Amaranth> asac: apport does that automatically
[07:48] <Amaranth> well, it tells me whether they use nvidia or not, anyway
[07:48] <slangasek> are there any lighter-weight memory debuggers than valgrind that we could try building a special compiz binary against?
[07:48] <Amaranth> *shrug*
[07:49] <Amaranth> tbh I barely know how to use valgrind :P
[07:49] <asac> i am not sure, i had luck that crashes happened earlier if run under gdb.
[07:49] <Amaranth> never run compiz under gdb
[07:49] <Amaranth> unless you have a second machine handy and ssh server enabled
[07:49] <asac> thats a bad start i'd say :)
[07:50] <Amaranth> when you run into the crash gdb stops compiz
[07:50] <slangasek> valgrind is the king because it lets you debug binaries post-hoc; but the overhead is nasty, it might be better to get something like ElectricFence into the picture
[07:50] <Amaranth> compiz is the thing updating your screen...
[07:50] <slangasek> Amaranth: well yes; that's why you run it from tty1 :)
[07:50] <Amaranth> and hope alt-sysrq-r works because ctrl-alt-f1 won't
[07:50] <asac> Amaranth: ... you could run that in a screen or something
[07:50] <asac> oh
[07:50] <asac> right
[07:50] <slangasek> erm, ctrl-alt-f1 should still work
[07:51] <Amaranth> i think it depends on what compiz was doing when it crashed
[07:51] <slangasek> it's handled by the X server... or is compiz just evil enough that it stops X/kernel from resetting the tty? :)
[07:51] <Amaranth> but i don't think building compiz with electricfence is going to help much if i haven't even gotten volunteers for valgrind :P
[07:52] <Amaranth> no one has said "that's too hard" or "that is too slow"
[07:52] <stgraber> you can still install a SSH server on your box and then connect from another one to run gdb/debug tools, no ?
[07:52] <Amaranth> yeah
[07:53] <slangasek> Amaranth: well, my point is that you seem to have stopped trying to get volunteers in the most obvious place :)
[07:53] <asac> yes, but everything that cannot easily done by a tweaked test-package is most likely too much to get wide spread feedback
[07:56] <Amaranth> oh, electricfence is no good
[07:56] <slangasek> because?
[07:56] <Amaranth> would be harder to use than than valgrind
[07:56] <Amaranth> because it stops the process and launches gdb
[07:56] <slangasek> mm
[07:56] <Amaranth> and that requires two computers and ssh
[07:56] <slangasek> that's a bit much, yes
[07:57] <slangasek> is libdmalloc any better?
[07:57] <slangasek> (sorry, I usually rely on valgrind, I just don't think that's a likely choice here)
[07:58] <Amaranth> dmalloc seems to just spit out a log, might be better
[07:59] <slangasek> does it trap memory errors and send a sigsegv?
[07:59] <slangasek> that would be crucial
[07:59] <Amaranth> not sure, it seems rather complicated
[07:59] <Amaranth> it probably makes breakfast for you too
[08:01] <Amaranth> i'll look into it tomorrow
[08:07] <fabbione> morning guys
[08:07] <fabbione> pitti: you around by any chance?
[08:07] <pitti> hey fabbione! *hug*
[08:08] <Hobbsee> morning fabbione, pitti
[08:08] <fabbione> hey Hobbsee
[08:08] <fabbione> pitti: hey dude....
[08:08]  * pitti hugs Hobbsee, too
[08:08] <fabbione> pitti: one very quick question... what's the reason why there are no ddebs for make-dfsg?
[08:08]  * Hobbsee hugs pitti back :)
[08:08] <fabbione> pitti: last time make was built was in feisty
[08:09] <fabbione> pitti: could that be the reason?
[08:09] <pitti> fabbione: the .ddeb retrieval system really sucks
[08:09] <pitti> fabbione: ah, that could be as well
[08:09] <fabbione> pitti: ok.. thought so
[08:09] <pitti> sometimes the apt-ftparchive processes get stuck, etc.
[08:09] <fabbione> pitti: are you still in charge of it?
[08:09] <fabbione> (i mean do you have powers to go and poke?
[08:09] <pitti> yes, I think so
[08:09] <fabbione> would you mind to check that for me please?
[08:11] <pitti> fabbione: there's not even a m/make directory
[08:11] <fabbione> indeed
[08:11] <pitti> so, since it hasn't been built for ages, there's no chance to revive it from teh buildds, sorry
[08:11] <fabbione> ok
[08:11] <fabbione> thanks
[08:11] <pitti> they remove ddebs after 7 days
[08:11] <pitti> so this needs a no-change rebuild
[08:11] <fabbione> what do you mean they remove ddebs after 7 days?
[08:12] <pitti> fabbione: the buildds only keep them for 7 days, otherwise the buildds would explode size-wise
[08:12] <fabbione> ah ok
[08:12] <fabbione> yes that makes sense
[08:12] <pitti> thus we have to fetch them within a week to ddebs.u.c.
[08:12] <fabbione> gotcha
[08:12] <fabbione> thanks a lot
[08:12] <soren> Oh, they're not moved around automatically by sbuild or something?
[08:13] <pitti> usually we fetch every 4 hours
[08:13] <pitti> but sometimes solar radiation breaks something
[08:13] <fabbione> or lunar rays...
[08:13] <pitti> soren: I wish soyuz would fetch and archive them automatically :)
[08:13] <soren> pitti: Yeah, I can imagine. :)
[08:13] <ogra_cmpc> oooh fabio is here
[08:13] <fabbione> pitti: keep wishing.. it might happen at some point in 2020 :P
[08:13]  * ogra_cmpc hugs fabbione 
[08:14] <fabbione> hey ogra_cmpc
[08:15] <soren> pitti: I wonder what would happen if they were added to the binary .changes file.. :)
[08:15] <pitti> soren: I guess soyuz would either ignore them or reject the upload
[08:16] <Hobbsee> pitti: or blow up.
[08:16] <soren> pitti: In the long term, that seems like the right approach, though.
[08:16] <pitti> absolutely!
[08:17] <cprov> soren: it would failed-to-upload, since we don't know yet how to process dddebs.
[08:17] <pitti> I already discussed that with Daniel Silverstone years ago
[08:17] <soren> cprov: Ok.
[08:55] <asac_classy> ogra_cmpc: install worked fine
[08:55] <asac_classy> :)
[08:55] <ogra_cmpc> cool
[08:56] <ogra_cmpc> do you like the new artwork ?
[08:56] <ogra_cmpc> :)
[08:57] <stgraber> ogra_cmpc: got screenshots ?
[08:58] <ogra_cmpc> not yet :)
[08:58] <ogra_cmpc> it looks like edubuntu :)
[08:58] <ogra_cmpc> just a lot smaller :)
[08:59] <stgraber> ok :)
[08:59] <asac_classy> ogra_cmpc: yes the new background looks fine
[09:00] <ogra_cmpc> did you do a german install ?
[09:00] <asac_classy> did the icons in application change as well?
[09:00] <asac_classy> not german... i can do if you want
[09:00] <ogra_cmpc> they should be gartoon all over the place
[09:01] <asac_classy> yeah i can confirm that there is no icon that doesn't fit in the theme
[09:02] <ogra_cmpc> good
[09:02] <asac_classy> but i am probably the wrong person to ask on artwork opinion
[09:02] <ogra_cmpc> the Places menu used to have the wrong folder icons
[09:02] <ogra_cmpc> but that should be fixed
[09:02] <asac_classy> places is fine, right
[09:03] <ogra_cmpc> good
[09:03] <asac_classy> there is still no discharge info btw
[09:03] <ogra_cmpc> i just found that putting /tmp in a tmpfs if you have limited ram is a vetry bad idea :P
[09:03] <ogra_cmpc> *very
[09:03] <asac_classy> obviously
[09:04] <asac_classy> how about swap :)
[09:04] <asac_classy> loike to add 64M more
[09:04] <ogra_cmpc> not for hardy, but there is compcache i'd like to examine for intrepid
[09:04] <ogra_cmpc> http://code.google.com/p/compcache/
[09:04] <ogra_cmpc> swapping kills the flash drive
[09:05] <ogra_cmpc> so no opportunity to swap to disk
[09:05] <slangasek> hmm, why does rhythmbox come with a list of default radio stations pointing at a non-existent ubuntu.hbr1.com?
[09:05] <saispo> hi
[09:05] <saispo> vim maintainer is in this room ? :)
[09:05] <ogra_cmpc> there is no vim maintainer :)
[09:05] <saispo> a team ? :)
[09:05] <asac_classy> ogra_cmpc:  sounds tricky
[09:05] <ogra_cmpc> all packages are group maintained in ubuntu
[09:06] <asac_classy> but most likely an option
[09:06] <seb128> slangasek: bug #183825
[09:06] <saispo> ogra_cmpc: vim is not synced to the latest debian version
[09:06] <ubotu> Launchpad bug 183825 in rhythmbox "rythmbox switching radio streams brings up error "Couldn't start playback: Unknown playback error"" [Low,Incomplete] https://launchpad.net/bugs/183825
[09:06] <saispo> hi seb128 :)
[09:06] <ogra_cmpc> asac, well, compcache seems to be the right thing
[09:06] <seb128> lut saispo
[09:06] <seb128> slangasek: it's on my list of unread mails = to upload after the freeze
[09:06] <asac_classy> ogra_cmpc: how
[09:06] <seb128> slangasek: nobody noticed that they changed those before
[09:07] <asac_classy> important is testing german?
[09:07] <ogra_cmpc> not really
[09:07] <ogra_cmpc> i do it anyway
[09:07] <asac_classy> ok
[09:07] <asac_classy> i guess its covered  enough by your tests then
[09:07] <slangasek> seb128: ok, cheers :)
[09:07] <ogra_cmpc> for the asian langs testing is important, but that needs someone whio actually can read that stuff :)
[09:08] <asac_classy> if you have more images to test let me know
[09:08] <asac_classy> i will see if this thing locks up in a day or two again
[09:08] <ogra_cmpc> i do dailies ... testing every once in a while would help
[09:08] <asac_classy> you do any official beta?
[09:08] <ogra_cmpc> nope
[09:09] <ogra_cmpc> but an official release
[09:11] <seb128> slangasek: about bug #147045, could I see the gtkrc?
[09:11] <ubotu> Launchpad bug 147045 in gnome-control-center "gnome-appearance-properties hogs processor even after close" [Medium,Confirmed] https://launchpad.net/bugs/147045
[09:11]  * ogra_cmpc kicks gvfs in the nuts
[09:11] <ogra_cmpc> you bad bad thing you
[09:11] <seb128> slangasek: do you have gtk-qt-engine installed and did you use KDE on this machine?
[09:11] <pitti> ah, thanks to whoever fixed displayconfig-gtk to say that resolution change only happens after re-login
[09:11] <seb128> ogra_cmpc: heh!
[09:12] <seb128> ogra_cmpc: gvfs rocks, be nice with it ;-)
[09:12] <slangasek> seb128: I don't use KDE; I had a hand-modified gtkrc from long ago to get me emacs-compatible keybindings
[09:12] <ogra_cmpc> seb128, nautilus is to slow in unmounting lopp devcies ... my scripts are scattered with sleep commands since we switched to gvfs
[09:12] <ogra_cmpc> *loop
[09:12] <slangasek> seb128: but yes, can send the .gtkrc over
[09:14] <seb128> ogra_cmpc: slow to umount? what do you do and how slow is it?
[09:14] <asac_classy> ogra_cmpc: just experienced a d&d hang ... e.g. hadn to kill ffox before i could use desk again
[09:14] <ogra_cmpc> asac, remove the /tmp line in fstab, that fix is only in the latest installer
[09:15] <ogra_cmpc> its likely atht ff runs out of ram
[09:15] <asac_classy> k
[09:16] <ogra_cmpc> seb128, i'm mounting a unionfs from squashfs and ext3 image ... two loop mounts and the union on top ... on unmount i remove the dirs ... all that runs on my ltsp server whch also runs a desktop constantly ... so for every loop mount i get a nautilus win ...
[09:16] <slytherin> are there any archive admins here? package 'freemind' is using openjdk to build. And it;s other dependencies are in main (ant, imagemagick). It should be moved to universe
[09:16] <asac_classy> ok let me umount
[09:16] <asac_classy> rather reboot i guess
[09:16] <ogra_cmpc> if i come to umount there is susally still a nautilus accessing the dir
[09:16] <asac_classy> :)
[09:17] <ogra_cmpc> yeah, reboot :)
[09:23] <dholbach> thekorn: good morning
[09:26] <asac_classy> ogra_cmpc: looks better
[09:26] <ogra_cmpc> yeah
[09:26]  * asac_classy back to other work
[09:27] <ogra_cmpc> feels faster i guess as well
[09:27] <asac_classy> yes
[09:27] <ogra_cmpc> :)
[09:27] <ogra_cmpc> thanks for testing
[09:27] <asac_classy> welcome
[09:43] <mvo> lamont: if you have a moment, review/comment on #203849 would be great
[09:46] <ogra_cmpc> hey hivo-cmpc
[09:47] <davmor2> soren: ping
[09:47] <Yoe> hi -- is it still possible to ask for a sync of nbd? or are you guys too far into a release to do that at this point?
[09:47] <hivo-cmpc> hey  ogra_cmpc!
[09:48] <hivo-cmpc> I'm supposed to be working real hard now, but saw you and asac-classy talking and couldn't resist :)
[09:48] <ogra_cmpc> hehe
[09:48] <ogra_cmpc> yay for toys
[09:48] <asac> hivo-cmpc: thats ok :)
[09:48] <soren> davmor2: Wazzup?
[09:49] <davmor2> soren: are you working on virt-manager?
[09:49] <soren> davmor2: Yes.
[09:49] <davmor2> soren: is there a reason I can't select cd-rom?
[09:49] <soren> Probably.
[09:49] <soren> :)
[09:50] <soren> Are you connected to qemu:///system or are you running as root?
[09:50] <davmor2> qemu:/// I think not root
[09:51] <seb128> does anybody has an opinion on bug #83604 (see current comment)
[09:51] <ubotu> Launchpad bug 83604 in ntp "ntpdate 1:4.2.2.p4+dfsg-1ubuntu2 has a flawed configuration file." [Undecided,Confirmed] https://launchpad.net/bugs/83604
[09:54] <\sh> seb128: question is, if we still want to use ntpdate .. ntpd configured to sane ntp servers should be enough in this case, and no doubled work
[09:55] <seb128> \sh: time-admin has a "sync now" button using it
[09:55] <siretart> Yoe: it doesn't seem to be a new upstream release that would bring in new feature, right?
[09:55] <Yoe> eh, nobody?
[09:55] <\sh> seb128: grmpf...:(
[09:55] <Yoe> siretart: eh, well, there are some new features in the debian packaging
[09:55] <seb128> \sh: and if we have ntpdate installed it should be working
[09:55] <Yoe> such as initramfs support etc
[09:55] <Yoe> other than that, no
[09:56] <\sh> seb128: yes, I agree...how do we come around the problem "ntpd is running, ntpdate will fail" in this case (just asking)?
[09:57] <seb128> \sh: time-admin enable the sync now button only when ntp is not used
[09:57] <seb128> \sh: you can select manual or automatic syncing there
[09:57] <siretart> Yoe: I would think that after the beta release it was reasonable to sync nbd. but I'd need to investigate the debdiff more closely
[09:57] <seb128> automatic is ntp
[09:57] <seb128> manual is no syncing but it let you trigger ntpdate
[09:57] <Yoe> siretart: okay. Do I need to poke you a few more times, or will you take care of it?
[09:57] <ogra_cmpc> siretart, ugh
[09:58] <ogra_cmpc> siretart, whats in new nbd we need ?
[09:58] <seb128> I'm wondering why we have an empty /etc/ntp.conf installed in fact
[09:58] <siretart> Yoe: I think ogra is more familiar with the nbd package. perhaps you two could clear the matter directly?
[09:58] <seb128> it's shipped by no package according to dpkg
[09:58]  * ogra_cmpc is worried, ltsp relies 100% on nbd
[09:58] <Yoe> well, I don't know how close you guys are to a release, I don't follow ubuntu
[09:58] <ogra_cmpc> i wouldnt want to break that
[09:59] <Yoe> I just care about it, and would think that these new features would be nice to have
[09:59] <ogra_cmpc> Yoe, the nbd patches come from ltsp ... likely a patch that vagrantc sent in
[09:59] <Yoe> but if you are too close to a release, there's nothing critical in there
[09:59] <seb128> soren: please fix virt-manager to boot not only when ran for the first time, I've enough to delete images and recreated those at every run ;-)
[09:59] <siretart> Yoe: see topic. we are pretty close to beta release
[09:59] <ogra_cmpc> right
[09:59] <Yoe> oh, okay
[09:59] <\sh> seb128: the answer is in the bug
[09:59] <Yoe> well, hold off then
[10:00] <soren> davmor2: That's your problem then.
[10:00] <soren> seb128: Er... What? :)
[10:00] <Volans> Hi, I have a question about the dialog of gnome-volume-manager in case of encrypted partition, it does not display the device to be mounted as in Dapper, can I ask someone (maybe seb128 or lool ? I'm not sure :) )
[10:00] <\sh> seb128: it looks like, that the ntp.conf is generated somehow when you hit sync now at least on feisty
[10:00] <davmor2> soren:  So you need to run virt-manager as root then?
[10:01] <ogra_cmpc> Yoe, i will take a look, but its unlikely that i'll pull it in if there isnt any improvement in the areas we use anyway
[10:01] <Yoe> ogra_cmpc: okay.
[10:01] <soren> davmor2: No.
[10:01] <seb128> \sh: ah, right
[10:01] <Yoe> ogra_cmpc: like I said, I don't think there's anything critical
[10:01] <\sh> seb128: and I just reproduced it on hardy
[10:01] <soren> davmor2: You can choose to connect to qemu:///system instead (if you're a member of libvirtd group).
[10:01] <seb128> Volans: gvfs is used now there
[10:02] <ogra_cmpc> YokoZar, thanks for the pointer though
[10:02] <seb128> \sh: alright, should be easy enough to fix, just not create the empty file
[10:02] <ogra_cmpc> bah
[10:02] <seb128> soren: I try using virt-manager for iso testing
[10:02] <seb128> soren: I don't want to do an install, just boot the iso when I try bugs
[10:03] <seb128> soren: but when I stop the machine and start it again it doesn't boot it, it just complains about not bootable disk
[10:03] <seb128> soren: not sure if I'm clear ;-)
[10:03] <\sh> seb128: I wonder if we can find the bugger in NTP.pm of system-tools-backend
[10:03] <Volans> seb128: I'm in Gutsy now, I dont'have tried in Hardy... you think it will change?
[10:04] <seb128> Volans: yes, it changes, hardy uses gvfs and not gnome-volume-manager
[10:04] <seb128> \sh: that's a task for somebody who likes perl, ie not me ;-)
[10:04] <davmor2> soren: ta I'll try again
[10:04] <Volans> ok, I will wait for Hardy :) The only strange thing is that in Dapper it will show the device, and in Gutsy not. Thnaks
[10:04] <Volans> *Yhanks
[10:08] <soren> seb128: Ah, right. Yes, it behaves differently the first time you boot a vm.
[10:08] <soren> seb128: This is by design, and for most use cases it's really what you want it to.
[10:08] <seb128> soren: well, it boot the first time you mean
[10:09] <seb128> then it doesn't
[10:09] <soren> seb128: First time it boots from the CD. Subsequently, it'll try to boot from the hard drive.
[10:09] <seb128> couldn't it do what  a really bios do
[10:09] <seb128> try one device and then the next one
[10:09] <seb128> like disk first and then cd drive?
[10:09] <seb128> so if I've no bootable OS installed it would still boot the cd image
[10:10] <ogra_cmpc> seb128, is there a fix already for hiding the /cow and /rofs mounts on the CD ? i'd like to look at it for the classmate as well
[10:10] <seb128> ogra_cmpc: I've no clue about the CD and how it hides mounts
[10:10]  * ogra_cmpc forgot the bug # but i know there is one open
[10:11] <soren> seb128: Well, kvm supports it, but virt-manager doesn't expose it. :(
[10:11] <soren> seb128: For now, you need to specify which (one) device you want to try to boot from.
[10:11] <soren> seb128: Except the first time, where it'll always try the cd.
[10:11] <seb128> soren: is there a way without editing the config file by hand?
[10:11] <soren> seb128: Er.. Sure, there's a gui option to change the boot device.
[10:12] <soren> seb128: On the VM details page -> hardware tab -> boot options.
[10:12] <seb128> soren: ok, will try that, thanks
[10:12] <soren> seb128: :)
[10:14] <\sh> seb128: I'll have a look on a fix this evening...
[10:15] <seb128> \sh: thanks
[10:17] <ogra_cmpc> seb128, thats bug #188229
[10:17] <ubotu> Launchpad bug 188229 in nautilus "[Hardy] rofs and cdrom icons shown on LiveCD desktop" [Medium,Confirmed] https://launchpad.net/bugs/188229
[10:17] <ogra_cmpc> wasnt /cow, sorry i remembered wrong
[10:32] <\sh> crimsun: any update on the flash -> no sound issue?
[10:33] <\sh> whoobs...ogra is maintainer for libflashsupport?
[10:36] <ogra_cmpc> WFM
[10:37] <ogra_cmpc> just tried youtube on classmate :) doesnt seem that libflashsupport is ion the way here
[10:37] <ogra_cmpc> *in
[10:37] <\sh> ogra_cmpc: libflashsupport doesn't work properly actually
[10:37] <\sh> ogra_cmpc: select another soundoutput device then the default one (e.g. usb headset) and you only hear sound from the onboard card (the default device)
[10:37] <ogra_cmpc> its used since over a year in ltsp ... i'm unsure if you should have it for non networked sound though
[10:38] <ogra_cmpc> i didnt add it to the deps
[10:38] <\sh> ogra_cmpc: remove libflashsupport and it works as expected
[10:39] <\sh> ogra_cmpc: well it's a dep of flashplugin-nonfree
[10:39] <\sh> and yiour education-desktop-other
[10:39] <ogra_cmpc> my ?
[10:40]  * ogra_cmpc doesnt know that package
[10:40] <ogra_cmpc> thats likely from debian-edu  ... nothing to do with me
[10:40] <\sh> ogra_cmpc: oh it's debian-edu
[10:40] <ogra_cmpc> and i didnt add it to the flash deps
[10:40] <ogra_cmpc> no idea who did that
[10:41] <ogra_cmpc> i only did the libflashsupport package ...
[10:41] <ogra_cmpc> simply because we need it in ltsp
[10:41] <\sh> ogra_cmpc: I wonder if it's a reasonable change to remove it from flashplugin-nonfree as dep and add it to a package which needs it...(imho somewhere in your ltsp packages)
[10:41] <ogra_cmpc> dont blame me for stuff others did with it :)
[10:41] <stgraber> it probably was added to flash's depends when we switched to pulseaudio
[10:42] <\sh> ogra_cmpc: I don't blame anyone :)  I need to fix this problem somehow...
[10:42] <\sh> Timo Aaltonen <tepsipakki@ubuntu.com>  harhar
[10:42] <stgraber> but IIRC flash can use alsa's dmix and so does pulse so I don't see why we would need it ... (except for LTSP of course)
[10:43] <ogra_cmpc> stgraber, right
[10:43] <\sh> stgraber: yes..
[10:43] <ogra_cmpc> it's only really helpful with networked sound i think
[10:43] <\sh> stgraber: so I would remove this dep from flashplugin-nonfree
[10:43] <ogra_cmpc> but the person that added it might have had reasons
[10:44] <\sh> ogra_cmpc: well, it just doesn't work on plain desktop installs
[10:44] <ogra_cmpc> i think the nspluginwrapper setup needs it in lib32
[10:45] <ogra_cmpc> (for amd64 arch)
[10:45] <\sh> ogra_cmpc: the problem occurs on amd64 :) dpkg -r --force-all libflashplugin fixes it
[10:45] <seb128> ogra_cmpc: what are the mountpoint of the things listed in the desktop which should not?
[10:45] <\sh> ogra_cmpc: same applies on i386
[10:46] <ogra_cmpc> seb128, you actually done really have mountpoints for them, they are bind mounted from before the unionfs gets merged out of /cow and /rofs
[10:46] <ogra_cmpc> well, you have mountpoints but no real devices
[10:47] <seb128> ogra_cmpc: right, just to know, debian has a patch to not show /live/cow, but if we use /cow rather we need to update it
[10:47] <ogra_cmpc> we do
[10:47] <ogra_cmpc> can you point me to the patch ?
[10:47] <ogra_cmpc> i need to skip all my local mounts on the classmate
[10:48] <seb128> ogra_cmpc: look to the current glib2.0 debian patches
[10:48] <ogra_cmpc> ugh, its a glib patch?
[10:48] <seb128> yes
[10:48]  * ogra_cmpc was hoping for some easy option
[10:48] <seb128> did it use to work before hardy?
[10:48] <seb128> because we had a similar gnomevfs change
[10:49] <seb128> but it listed /live/cow and not /cow too
[10:49] <ogra_cmpc> i didnt see the loop devices with gnomevfs
[10:49] <ogra_cmpc> i have a lot of loop mounts on a classmate
[10:49] <ogra_cmpc> and some bind mounting magic
[10:51]  * ogra_cmpc thinks generally that loop devices should be ignored though
[10:51] <seb128> ogra_cmpc: we had a patch to ignore ltspfs mounts though
[10:52] <ogra_cmpc> yeah, thats not needed anymore
[10:52] <ogra_cmpc> that was because we had two mounts per ltspfs device ... that was merged into one
[10:53] <ogra_cmpc> in any case it should ignore bind mounts
[10:54] <seb128> ogra_cmpc: feel free to open a gvfs bug about it with a small testcase
[10:55] <ogra_cmpc> ok
[10:59] <ogra_cmpc> hmm, actually it doesnt show the bind mount .. but the (hidden) device the mount originates from
[11:09] <stgraber> ogra_cmpc: anything you want me to test for Edubuntu addon ?
[11:09] <stgraber> ogra_cmpc: I installed everything from the add-on CD without internet access, worked well
[11:09] <stgraber> and I tried iTalc, worked fine too
[11:09] <stgraber> the notification message about the new artwork was there too
[11:13] <ogra_cmpc_> stgraber, fine, there is nothing else atm ... (the menu still shows TeacherTools and LightDesktop though, got to find out why after beta)
[11:13] <DktrKranz> Could a buildd-admin give-back ocamlcreal on amd64? Thanks.
[11:14] <stgraber> ogra_cmpc_: oh, btw about the NM debug message on shutdown you spoke about yesterday : it's something like cb_data->data->... and assertion error
[11:15] <ogra_cmpc_> is it actually an error ?
[11:15] <ogra_cmpc_> i saw it has a debig prefix for each line
[11:15] <stgraber> well, looks like a dbus thing to me but it's really hard to read as it's disappearing quite fast
[11:15] <\sh> ogra_cmpc_: so you need libflashplugin for ltsp sound?
[11:15] <ogra_cmpc_> i thought it was just a debug opton asac didnt drop from the code yet
[11:16] <ogra_cmpc_> stgraber, right, thats my prob as well...
[11:16] <ogra_cmpc_> probably its better to catch without usplash
[11:16] <ogra_cmpc_> \sh, iodeed
[11:16] <ogra_cmpc_> *indeed
[11:17] <ogra_cmpc_> *libflashsupport btw :)
[11:17] <stgraber> ogra_cmpc_: or with VMWare and the record video thing, but I don't have vmware installed anymore
[11:17]  * ogra_cmpc_ neither
[11:17] <ogra_cmpc_> vbox only here
[11:17] <\sh> ogra_cmpc_: yeah...I just wrote  a mail to u-d@l.u.c to discuss this issue
[11:18] <ogra_cmpc_> just ask the person who added it :)
[11:18] <ogra_cmpc_> i dont think there needs to be much discussion
[11:18] <\sh> ogra_cmpc_: adding without testing is a bad thing ;)
[11:18] <\sh> whois tepsipakki
[11:18] <\sh> grmpf
[11:18] <ogra_cmpc_> well, addin for testing is a good thing
[11:19] <ogra_cmpc_> \sh -> tjaalton
[11:19] <\sh> ah :)
[11:19]  * \sh needs to write a nick -> lp email  plugin for irssi ;)
[11:20] <ogra_cmpc_> \sh, so your prob is with nspluginwrapper ?
[11:20] <\sh> ogra_cmpc_: no..the problem is libflashsupport only :)
[11:20] <ogra_cmpc_> \sh, do you use nspluginwrapper ?
[11:20] <ogra_cmpc_> (you said youre on amd64)
[11:21] <\sh> ogra_cmpc_: if it's needed for amd64 to run flashplugin-nonfree then yes...I'm not sure...the problem occurs but on both archs ...i386 and amd64 ...reproducable
[11:21] <\sh> ogra_cmpc_: there is also a bug report for that
[11:22] <ogra_cmpc_> what i want to find out is which package you are uninstalling there, we dont build the native amd64 package of libflashsupport anymore, only the lib32 version for amd64
[11:22] <ogra_cmpc_> that changed very recently
[11:22] <Robot101> with nspluginwrapper, flashplugin-nonfree, and i386 libflashsuport unpacked into lib32, audio works here
[11:22] <ogra_cmpc_> Robot101, thanks :)
[11:23] <lamont> mvo: good catch
[11:23] <lamont> mvo: post beta, I assume?
[11:23] <\sh> Robot101: change sounddevice to usb headset and start over pls
[11:23] <\sh> Robot101: sound works with libflashsupport but only on the non-selected sound device, e.g. your onboard card...
[11:23] <stgraber> ogra_cmpc_: did you test LTSP install using Ubuntu alternate ? I don't see any result on the tracker yet
[11:24] <Robot101> ah - via pulseaudio, and I unpacked the i386 pulse plugins into lib32/alsa/
[11:24] <\sh> Robot101: so even if you select in sound settings a usb headset for default output/input you get sound from your speakers attached to your desktop :)
[11:24] <ogra_cmpc_> \sh, did you by chance generate an ~/.asoundrc.asoundconf that forces a card ?
[11:24] <Robot101> so the sound device selection is made outside via pulseaudio
[11:24]  * lamont wanders off
[11:24] <Robot101> any problems you encounter are due to  not using pulseaudio. :)
[11:24] <\sh> ogra_cmpc_: yes...tested everything with crimsun already
[11:24] <\sh> Robot101: killing pulseaudio helps too
[11:24] <\sh> Robot101: but dropping libflashsupport looks more sane
[11:25] <ogra_cmpc_> \sh, pulse should hook into alsa ... and what you change with the gnome tool are the alsa settings
[11:25] <ogra_cmpc_> that sounds very much like a misconfiguration
[11:25] <Robot101> \sh: no, killing pulseaudio doesn't help at all. that just breaks the rest of my desktop.
[11:26] <stgraber> asac, ogra_cmpc_: http://www.stgraber.org/download/NM-msg.png
[11:26] <Robot101> 1. use pulseaudio. 2. configure pulseaudio as you wish. 3. make everything send its audio to pulseaudio.
[11:26] <asac> evand: 1. it took me 4 minutes to hit the berlin timezone on the map
[11:26] <\sh> Robot101: it breaks the rest yes :)  but not flash
[11:26] <Robot101> success
[11:26] <asac> evand: using a touchpad
[11:26] <asac> evand: and how the new partition size is displayed in the guided option is confusing
[11:26] <Robot101> \sh: flash works fine for me with nspluginwrapper, flashplugin-nonfree, i386 libflashsupport, and the pulse alsa plugins in lib32/alsa/
[11:26] <Robot101> \sh: and yes, it will play through my selected pulseaudio sound device(s)
[11:27] <\sh> Robot101: how do I say pulse to use my usbheadset?
[11:27] <asac> evand: i didn't understand which partition would be which (e.g. a) was yellow reading hardy (development) 8.04, b) was grey reading hardy 8.04)
[11:27] <Mirv> what should be done for bug #106756 still which has "verification-done" for the move from gutsy-proposed to gutsy-updates, but the move hasn't been done even though it's been there for over a month?
[11:27] <ubotu> Launchpad bug 106756 in gnome-app-install ""Search for suitable codec" dialog not translated/translatable" [Undecided,In progress] https://launchpad.net/bugs/106756
[11:27] <Robot101> \sh: use the device chooser applet
[11:28] <Robot101> "PulseAudio Device Chooser"
[11:28] <Robot101> select desired audio device from menu
[11:28] <\sh> Robot101: do i need to install additional software for that?
[11:29] <Robot101> it comes from the padevchooser package
[11:29] <\sh> Robot101: there is no such thing as device chooser somewhere...the only stuff which is installed comes from ubuntu-desktop
[11:30] <Robot101> but ideally, the gnome thing would change the pulseaudio settings if you had pulseaudio
[11:30] <\sh> Robot101: that's crap...honestly...this package is not default...the settings in g-s-s are what the user uses...
[11:30] <Robot101> fedora might have patched it thusly
[11:30] <ogra_cmpc_> it has
[11:30] <Robot101> yes, those settings are basically failure
[11:30] <ogra_cmpc_> its used by default in fedora
[11:30] <ogra_cmpc_> (libflashsupport)
[11:31] <stgraber> ogra_cmpc_: Is that the same warning you saw ?
[11:31] <mvo> lamont: probably, but if you are happy with it, I upload it and it will get unfrozen after the beta (if you have more fixes pending or prefer to upload it yourself, that is of course fine with me :)
[11:31] <\sh> Robot101: so if the problem is solved with using different tools for pulse we need to fix it asap...or just drop pulse as default
[11:31] <ogra_cmpc_> i worked a while with warren togami on it, he cared for licensing fixes in fedora because they install it by default
[11:31] <ogra_cmpc_> stgraber, differetly wrapped, but i think so
[11:31] <lamont> I have a couple of template .po translation files committed in git already
[11:32] <asac> stgraber: that message wasn't there with 0.6.5?
[11:32] <Robot101> \sh: dropping pulse is unlikely to make things work better. :P
[11:32] <ogra_cmpc_> i think that meassage was there since we use 0.6
[11:32] <\sh> Robot101: the issue is still there...even with a known workaround
[11:32] <stgraber> asac: not sure, in most cases it's hidden by usplash or just appears during a too short amount of time to notice it
[11:32] <lamont> mvo: if you do upload, I won't complain at all if you want to grab the git tree and branch off of the right place (before the merge with wietse that I did yesterday of 2.5.2-rc1)
[11:32] <ogra_cmpc_> asac, its hard to catch because it vanishes very fast
[11:32] <lamont> otherwise, I'm happy to manually apply the patch for you
[11:32] <lamont> as in resync later this week
[11:33] <lamont> mvo: in fact, please upload.
[11:33] <stgraber> ogra_cmpc_: I had to use a LiveCD image with usplash turned off to catch it :) (as we have the "remove the CD" prompt to avoid the reboot)
[11:33] <lamont> I'll just plan on dealing with the merge later in the week/early next
[11:33] <ogra_cmpc_> \sh, can you remove ~/.asoundrc.asoundconf and run asoundconf set-pulseaudio ? and then try again
[11:34] <ogra_cmpc_> that way you force pulse to use the alsa backend
[11:34] <asac> stgraber: is it reproducible if you shut down hal _before_ dbus?
[11:34] <\sh> ogra_cmpc_: sec
[11:34] <asac> without shutting down your system
[11:34] <asac> i guess it should appear in syslog
[11:35] <\sh> ogra_cmpc_: and then setting g-s-s settings back to use headset?
[11:35] <ogra_cmpc_> as you like
[11:35] <asac> \sh: i akes on ml. are you using pulseaudio?
[11:35] <ogra_cmpc_> the g-s-s settings should only apply to alsa
[11:35] <ogra_cmpc_> pulse sits on top
[11:36] <\sh> asac: I'm using g-s-s and say "use usb headset" ... PA is running though...bug firefox + flash gives me "sound over default onboard device, not the choosen one"
[11:36] <asac> hmm
[11:36]  * \sh is on i398 now
[11:36] <soren> \sh: Wow!
[11:36] <asac> might sound ignorant, but what is pulse good for?
[11:36] <\sh> hmm
[11:36] <soren> i398 sounds awesome!
[11:36] <\sh> i386
[11:36] <ogra_cmpc_> self invented ?
[11:36] <ogra_cmpc_> heh
[11:36] <\sh> ogra_cmpc_: no change...I think I need to relog to get this setting started?
[11:37]  * ogra_cmpc_ imabgines \sh with soldering iron upgarding his CPU to 398
[11:37] <\sh> hehe
[11:37] <ogra_cmpc_> \sh, might be, not sure
[11:37] <\sh> ogra_cmpc_: brb...
[11:38] <asac> anyone can give me insight why we have pulseaudio in hardy? which use-cases does it tackle?
[11:38] <ogra_cmpc_> \sh, pcm.!default { type pulse }
[11:38] <ogra_cmpc_> ctl.!default { type pulse }
[11:38] <ogra_cmpc_> thats the content your .asoundrc.asoundconf should have atm
[11:38] <\sh> ogra_cmpc_: yepp...that's in .asoundrc.asoundconf
[11:39] <\sh> ogra_cmpc_: but no sound via flash + headset
[11:39] <stgraber> asac: doesn't seem to reproduce the message by stopping hal before dbus. I get some CK messages, hcid too but nothing scary from NM (seems to shutdown correctly)
[11:39] <ogra_cmpc_> asac, because gnome sucks and isnt capable of implementing dings and doings and plings using gstreamer
[11:39]  * asac goes to AC-mode and reads package description
[11:39] <asac> stgraber: and the other way around?
[11:39] <asac> e.g. dbus before hal?
[11:39] <ogra_cmpc_> asac, oyu should see it on the classmate btw ... its slow enough to expose it before usplash comes up
[11:40] <asac> ogra_cmpc_: yes, but not a good environment to work on it :)
[11:40] <\sh> ok...again...asoundconf set-pulseaudio + system/Prefs/Sound -> setting to usb headset...
[11:40] <asac> ogra_cmpc_: i need a way to reproduce this on a running system :)
[11:40] <\sh> no sound at all over headset
[11:40] <ogra_cmpc_> asac, bah, lamer ... i'm working on my classmate sionce 4 weeks wothout probs
[11:41] <ogra_cmpc_> (apart from typing right :P)
[11:41] <asac> yeah ;) ... and you attach gdb during shutdown.
[11:41] <\sh> setting it to pulse in g-s-s works for normal sound..now check flash
[11:41] <\sh> no sound for flash #
[11:41] <stgraber> asac: same result (dbus stops hal anyway)
[11:42] <ogra_cmpc_> we should just switch to 0.7
[11:42] <ogra_cmpc_> it has proper initscripts
[11:42] <asac> stgraber: right. ok. did you try to stop nm after hal (but dbus still running)`
[11:42] <asac> ogra_cmpc_: indeed
[11:43] <asac> ogra_cmpc_: in fact we would want to not stop NM during shutdown at all
[11:43] <asac> same for package upgrades
[11:43] <ogra_cmpc_> yeah
[11:43] <ogra_cmpc_> sad that we'll have to support that for three years
[11:43] <stgraber> asac: "Shutting down normally" it says ...
[11:44] <asac> strange.
[11:44] <asac> whatelse could trigger this?
[11:44] <ogra_cmpc_> \sh, i start to suspect that your flash doesnt use pulse at all
[11:45] <ogra_cmpc_> for whatever reason
[11:45] <asac> you need libflashsupport for that :)
[11:45] <stgraber> asac: "Terminatting all remaining process" is what it does before the arning
[11:45]  * asac ducks
[11:45] <stgraber> *warning
[11:45] <stgraber> asac: so it receives a kill message
[11:45] <asac> so its a KILL?
[11:45] <stgraber> looks like yes
[11:45] <\sh> ogra_cmpc_: I just checked this: 1. libflashsuport is installed...no sound with setting asoundconf set-pulseaudio and set to usb headset
[11:46] <stgraber> asac: I don't see why though, from my point of view we should just call /etc/init.d/dbus stop and that will shutdown all the necessary bits ...
[11:46]  * asac wonders if dbus or hal get a SIGKILL as well
[11:46] <asac> stgraber: right
[11:46] <asac> thats why i wonder
[11:46] <asac> isn't that called at all?
[11:47] <\sh> ogra_cmpc_: removing libflashsupport and restarting firefox+flash doesn't work either...setting asoundconf back to usb headset, with libflashsupport installed -> no sound for flash, dropping libflashsupport restarting everything..sound works with flash
[11:47] <\sh> ogra_cmpc_: fun part...sound works with libflashsupport on the onboard device still
[11:48] <stgraber> asac: find /etc/rc*/ | grep udev
[11:48] <stgraber> asac: I don't see any K entry for it here ...
[11:49] <stgraber> asac: oops :)
[11:49] <stgraber> asac: dbus of course
[11:49] <stgraber> asac: and it actually has K entry
[11:49] <asac> in postinst there is update-rc.d dbus start 12 2 3 4 5 . stop 88 1
[11:50] <asac> e.g. i have /etc/rc1.d/K88dbus
[11:51] <asac> and /etc/rc1.d/K16hal
[11:52] <pitti> lool: argh, elisa-plugins-bad wants more packages, like python-{bluez,coherence,daap}
[11:52] <pitti> lool: would it be possible at all to move the GUI into plugins-good? (and wouldn't that make more sense in the first place?)
[11:53] <\sh> ogra_cmpc_: and libflashsupport is used...shermann@wz-pc-006:~$ lsof |grep libflash
[11:53] <\sh> firefox   10773   shermann  mem       REG        8,3    10848  67155089 /usr/lib/libflashsupport.so
[11:53] <\sh> ogra_cmpc_: usb headset tested via padevchooser -> works...inside ff + flash-nonfree -> doesn't work
[11:54] <jdstrand> slangasek: speaking for the 'crackheads', the apparmor changes in bind9 force certain upgrades into complain mode, to not break existing installs
[11:54] <jdstrand> slangasek: eg dapper - hardy
[11:55] <jdstrand> gutsy with apparmor-profiles installed - hardy
[11:56] <jdstrand> slangasek: the second is probably more important in terms of beta testing, but I don't have the numbers on how many are doing that
[11:56] <jdstrand> s/are/will/
[11:57] <ogra_cmpc_> \sh, find others that can reproduce it ...
[11:58] <\sh> ogra_cmpc_: 4 different desktops ? one amd64 rest i386 ... it could be still a regression from upgrades from gutsy to hardy...
[11:58] <ogra_cmpc_> \sh, my only concern with changing the dep is that i didnt hear anybody but you complaining yet
[12:02] <\sh> ogra_cmpc_: https://bugs.edge.launchpad.net/ubuntu/+source/libflashsupport/+bug/144356 :)
[12:02] <ubotu> Launchpad bug 144356 in libflashsupport "Audio from Flash in Firefox does not go to correct sound device (dup-of: 151849)" [Low,Confirmed]
[12:02] <ubotu> Launchpad bug 151849 in libflashsupport "Sound Broke in Ubuntu Gutsy firefox" [Undecided,Confirmed]
[12:02] <_MMA_> \sh: Luke (TheMuso) might also be able to test as I believe he has multiple sound cards. He's in AU and might be up in a few hours. He said he was gonna start his day early.
[12:04] <\sh> _MMA_: well, I'm really wondering what the bugger is...just because usb headset microphone works as expected (in flash) ...it's just the sound which doesn't come up
[12:04] <\sh> ogra_cmpc_: you see I'm not the only one ;)
[12:05] <ogra_cmpc_> thats all about the lib32 issue
[12:05] <\sh> ogra_cmpc_: the dupe yes...the 144356 not
[12:06] <ogra_cmpc_> and: ALSA lib ../../../src/pcm/pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave is pretty much what the upstream bug has
[12:06] <ogra_cmpc_> that looks rather like amd64 with nspluginwrapper wont work *without* it installed
[12:07] <ogra_cmpc_> (not talking about the dupe here)
[12:07] <pitti> StevenK, lool: hildon-desktop is uninstallable since mobile-basic-flash dependency is in universe
[12:07] <\sh> ogra_cmpc_: it seems that 144356 is not a dupe of 151849
[12:08] <ogra_cmpc_> well, it seems they are both mixed up
[12:08] <\sh> yepp
[12:09] <\sh> well...to fix the amd64 issue we need to add the 32bit libs to ia32-libs somehow (if this is reasonable)
[12:09] <StevenK> pitti: Oh, argh.
[12:09] <ogra_cmpc_> the lib32 issue should be fixed now ... but according to the comments flash wont produce any sound if the lib is missing there
[12:10] <ogra_cmpc_> thats getting tricky
[12:10] <\sh> ogra_cmpc_: more tricky the i386 problems, still...
[12:14] <lool> pitti: It would make more sense to have the GUI in -good; it's the immediate thing I complained about when I saw the -bad dep
[12:14] <lool> pitti: But I'm not too hot on diverging from upstream on that
[12:14] <lool> I could further split -bad though
[12:15] <pitti> lool: ah, it's split upstream like that?
[12:15] <lool> pitti: These are all upstream packages
[12:15] <pitti> hm, so split into -ui and -bad, so that the extra dependencies are only on -bad?
[12:15] <lool> mapped one to one from upstream tarballs to binary packages
[12:15] <lool> pitti: Exactly
[12:15] <pitti> lool: I guess the actual question is: do we want to support the plugins in bad?
[12:15] <lool> pitti: -passable, -mediocre and -nottoobad are also on the table :)
[12:16] <lool> pitti: In a perfect world, we would be good with -good alone; unfortunately, they applied strict criterions to triage plugins, and the UI was in a shape which only allowed to ship it in -bad
[12:17] <lool> Ideally, the UI plugin(s) is fixed and promoted to -good soon
[12:17] <lool> And we can drop the elisa -> -bad dep
[12:19] <pitti> lool: I mean, are the plugins in -bad bad enough so that we wouldn't like to support them?
[12:19] <\sh> grmpf...brb
[12:19] <lool> pitti: This is similar to gstreamer plugins split
[12:20] <lool> pitti: We ship these (in universe), but we don't pull these by default
[12:23] <pitti> lool: so if they are bad/broken enough, IMHO we should leave them in universe and split the binary out, perhaps? WDYT?
[12:23] <\sh> asac: btw...do you know why firefox -width 300 -height 300 doesn't work properly?
[12:24] <\sh> asac: neither in ff3 nor in ff23
[12:24] <\sh> ff2 even
[12:24] <ogra_cmpc> did that ever work in firefox ?
[12:24] <DktrKranz> pitti, could you please give-back ocamlcreal on amd64? Thanks.
[12:25] <\sh> ogra_cmpc: a mozilla option regarding firefox --help :)
[12:25]  * ogra_cmpc only actually saw that working in mozilla
[12:25] <ogra_cmpc> right
[12:25] <ogra_cmpc> i dont think ff ever supported that option
[12:25] <lool> pitti: The reason for badness can be quite different, it could be anything from a license issue to a lacking documentation issue
[12:26] <pitti> hm, licensing would be fatal -- it's in universe and needs to be DFSG-free
[12:26]  * pitti -> lunch, bbl
[12:26] <lool> pitti: Licensing might still be DFSG free, but considered bad
[12:26] <lool> pitti: For example in GStreamer, it's quite bad when a plugin is GPL and not LGPL as it "pollutes" the LGPLing of the whole gst stack you're using
[12:27] <\sh> ogra_cmpc: bah...
[12:29] <\sh> ogra_cmpc: so what browser someone should use for setting the default x/y width/height to actually remote control it ;)
[12:29] <evand> asac: aware of the problem and on it.
[12:30] <asac> evand: ok both?
[12:31] <ogra_cmpc> \sh, write your own :) http://people.ubuntu.com/~ogra/LightBrowser/
[12:31] <ogra_cmpc> took me some hours on a boring weekend to get to that state
[12:31] <evand> not the latter, actually, but I'm not sure how to solve that.  Suggestions?
[12:31] <ogra_cmpc> its all javascript
[12:31] <asac> \sh: i think nobody really cares about that feature. its more an old suite thing
[12:33] <\sh> asac: well...if you want to automate screen recordings (e.g. start firefox at pos x/y with width/height, recordmydesktop -x <pos inside firefox> -y <pos inside firefox> -width <foo> -height <bar> -o myscreencast.ogg) this could be helpful :) (e.g. recording example flash output, or other moving objects)
[12:41]  * \sh is doomed...
[12:43] <\sh> let's see if galeon + flash works somehow
[12:48] <\sh> bah...I need a pause...
[12:48] <asac> \sh does gnash work properly in this regards?
[12:48] <asac> (i assume it does ... just to confirm)
[13:15] <nemo> I know y'all are devs and busy, but if anyone happens to be familiar with checkinstall and knows what:
[13:15] <nemo> grep: /var/tmp/AHXgVEkmBVqAMUSYXXaaX/newfile: No such file or directory
[13:15] <nemo> Copying files to the temporary directory... FAILED!
[13:15] <nemo> might mean in my attempt to install an ffmpeg with faac/faad support, I'd really appreciate it
[13:15] <nemo> checkinstall 1.6.1
[13:16] <cjwatson> Does compiz have a plugin to fade out the screen after a period of inactivity? I noticed that it kicks in while ubiquity is running, even though ubiquity takes steps to poke gnome-screensaver every so often
[13:16] <cjwatson> And if so, is there a way to inhibit it?
[13:17] <seb128> cjwatson: could be gnome-power-manager
[13:18] <cjwatson> point
[13:18] <nemo> heh
[13:18] <cjwatson> though the preferences don't seem relevant here
[13:19] <seb128> cjwatson: run gnome-power-manager --no-daemon --verbose and look at the log when screen is dimming
[13:19] <nemo> appears my checkinstall error is very common
[13:19] <nemo> hm
[13:19] <cjwatson> nemo: it's not obvious from the error message; though I wonder if perhaps you have /var/tmp mounted separately and noexec
[13:19] <cjwatson> (just a guess, though)
[13:20] <seb128> cjwatson: could be https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/137598
[13:20] <ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [High,Fix committed]
[13:20] <cjwatson> seb128: hmm, will be awkward to set up, but I'll see what I can do
[13:20] <cjwatson> seb128: (this is a desktop system, BTW)
[13:20] <nemo> cjwatson: naw. pretty standard setup
[13:21] <nemo> everything under /
[13:21] <_MMA_> nemo: Might save yourself some effort by looking at Medibuntu. Their version might have the support you're looking for.
[13:21] <seb128> cjwatson: (hum, not likely this issue then)
[13:22] <nemo> _MMA_: sure. although, I might need to do this in future...
[13:22] <cjwatson> seb128: I wasn't really looking at the screen when it happened, but based on peripheral vision it looked exactly like gnome-screensaver kicking in
[13:23] <cjwatson> screen dimmed to black over a period of a second or two, and then came back upon pressing a key (with a delay because the system was busy)
[13:23] <cjwatson> I could try using gnome-screensaver-command --inhibit instead, I suppose
[13:23] <nemo> looking around, I keep seeing folks running into this error, but no one with a solution except "do something else besides checkinstall"
[13:23] <nemo> I wonder if checkinstall is completely broken
[13:24] <nemo> seems to be even on, like, Solaris
[13:27] <nemo> ah-hah
[13:27] <nemo> http://oclug.on.ca/archives/oclug/2004-May/038916.html
[13:28] <nemo> hm. or not
[13:28] <nemo> dammit
[13:31] <nemo> _MMA_: I think you're right on the medibuntu thing - that could explain why I had it working before. probably had set that up and forgot.
[13:35] <nemo> darn. the medibuntu one doesn't link against faac either
[13:35] <nemo> oh well. gentoo it is
[13:50] <dholbach> Word Up: http://www.murrayc.com/blog/permalink/2008/03/19/getting-my-microphone-to-work/
[13:56] <ogra_cmpc> dholbach, with the USB mic working i would suspect its an alsa bug with his card driver
[13:56] <ogra_cmpc> seems the upper layer works fine
[13:56] <dholbach> I had the same problem - no usb mic
[13:56] <ogra_cmpc> same card probably ?
[13:58] <dholbach> no, different, but Intel too
[13:59] <ogra_cmpc> "The laptop is using a USB microphone built in to a webcam, and that works fine." somewhat indicates that its at low level
[14:00] <mvo> I had the problem with a gutsy system from a friend
[14:00] <mvo> but I have no usb mic to test myself :/
[14:00] <ogra_cmpc> intel card as well ?
[14:01] <mvo> bno
[14:01] <mvo> no
[14:02] <mvo> ogra_cmpc: didn't read careful enough, I had the trouble with a usb thing
[14:03] <ogra_cmpc> ah
[14:04] <ogra_cmpc> me heard people mention before that they had probs with mics on intel cards being to silent ... apparently you can get something out of them but very very quiet
[14:05] <mvo> aha
[14:14] <sistpoty|work> infinity: can you increase the lp timeout for ghc6 on sparc? it doesn't produce any output for ~800 minutes on my sparc test box, but the build succeeded there w.o. problems (bug #194912). Thanks!
[14:14] <ubotu> Launchpad bug 194912 in ghc6 "ghc6 6.8.2-1ubuntu1 FTBFS on sparc" [Undecided,Confirmed] https://launchpad.net/bugs/194912
[14:18] <pitti> cjwatson, evand: hm, did you recently try the OEM time zone selector? the zoom is way too high, it's very sluggish, and the dots are misplaced (there's no dot where Berlin or London are)
[14:18] <pitti> it works quite fine in ubiquity
[14:29] <asac> pitti: i think evand said that he is working on improving the time zone selector
[14:29] <asac> pitti: for me it took minutes to actually hit berlin
[14:29] <asac> using touch pad
[14:30] <pitti> asac: I didn't even find it in the oem configurator :)
[14:31] <stgraber> selecting Zurich was really hard as Vaduz is pretty close :) and that zoom effect looks weird to me
[14:31] <asac> really? strange. for me it was about where it should be on todays livecd
[14:33] <asac> evand: i am not sure ... you might want to talk to mpt about how to better visualize that
[14:33] <asac> evand: (about the guided resizing preview)
[14:34] <seb128> siretart: could you make xine-lib stop shipping the pulse plugin? the totem upstream requested that because it's really buggy and they get lot of crashes due to it, http://bugzilla.gnome.org/show_bug.cgi?id=449658
[14:34] <ubotu> Gnome bug 449658 in xine-lib backend "Broken PulseAudio plugin in xine-lib (work-around in comment 79)" [Critical,Resolved: notgnome]
[14:35] <seb128> siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471676 too
[14:35] <ubotu> Debian bug 471676 in totem-plugins "Crash when see video from internet" [Normal,Open]
[14:35] <siretart> seb128: thanks for the hint, will investigate
[14:36] <seb128> siretart: thank you
[14:41] <siretart> seb128: ok, we will take out the pulse plugin. Is this something for the beta release?
[14:41] <seb128> siretart: no, it's late for beta anyway and we use totem-gstreamer
[14:41] <siretart> or shall I wait for after the release?
[14:41] <siretart> ok
[14:42] <seb128> siretart: it was just a request from upstream so they stop getting duplicates
[14:42] <siretart> can I upload anyway and expect it to be accepted only after release?
[14:42] <seb128> yes
[14:42] <siretart> ok. on my way
[14:42] <seb128> thanks
[14:43] <seb128> siretart: we are on sync with debian, I can do sync if you fix it there
[14:44] <siretart> hm. I thought mvo had uploaded a patch for dapper->hardy upgrades
[14:45] <siretart> mvo: do you intend to upload that, or have you asked me to upload the debdiff?
[14:45] <mvo> siretart: I uploaded a xine-lib yesterday, but it got not accepted (yet)
[14:45] <seb128> ah ok
[14:46] <seb128> freezes suck
[14:46] <mvo> siretart: feel free to grab the debdiff and apply it on top of your changes
[14:46] <seb128> or a least not having frozen versions listed on launchpad
[14:46] <mvo> seb128: yeah, or do packages in bzr ;)
[14:46] <siretart> we manage the xine-lib in hg
[14:46] <seb128> mvo: don't get me started on bzr ;-)
[14:46] <siretart> a working bzr-hg plugin would be great here...
[14:47] <mvo> or git-bzr ...
[14:48] <cjwatson> pitti: evand has a FF/beta freeze exception request open for that
[14:48] <cjwatson> I think it may be too late for beta though
[14:48] <pitti> ok, so it's known
[14:48] <pitti> cjwatson: fine, using the combobox works good enough
[14:48] <cjwatson> bug 203292
[14:48] <ubotu> Launchpad bug 203292 in oem-config "Freeze exception: zoommap changes port to oem-config" [Undecided,New] https://launchpad.net/bugs/203292
[14:48] <pitti> at least one nontrivial bug in the beta :)
[14:48] <pitti> cjwatson: thanks
[14:52] <\sh> seb128: any workaround to tell the gnome screenshot util to fetch window borders under compiz?
[14:52] <cjwatson> pitti: does fsck usplash integration not work on /?
[14:53] <seb128> \sh: take a fullscreen screenshot
[14:53] <pitti> cjwatson: it's supposed to, but there are a few reported bugs
[14:53] <\sh> seb128: so no single window can be captured with a window border  when running with compiz as wm...
[14:53] <\sh> it's not my day today
[14:53] <cjwatson> yeah, I just noticed it drop to text mode for me
[14:53] <seb128> \sh: correct
[14:53] <pitti> cjwatson: bug 203322 and bug 197667 ?
[14:53] <ubotu> Launchpad bug 203322 in sysvinit "fsck/usplash: ESC does not kill fsck" [Undecided,In progress] https://launchpad.net/bugs/203322
[14:53] <ubotu> Launchpad bug 197667 in sysvinit "problem with new display of FSCK" [Undecided,In progress] https://launchpad.net/bugs/197667
[14:57] <cjwatson> pitti: I don't think so - it *does* drop to console. It could be 203322, though, didn't check process lists
[14:58] <pitti> cjwatson: hm, when I'll deal with those bugs, I'll test it again with the root file systems
[15:31] <mvo> Keybuk: could you pleae have a look at http://paste.ubuntu.com/5880/ and tell me if such a change would be ok with you? it helps the apt resolver to calculate the upgrade from dapper->hardy
[15:33] <mvo> bdmurray: I analyized the problem you had with your test-upgrade and I think that I have a workaround (if Keybuk is happy with it :) - otherwise I will work around it by hinting in update-manager
[15:33] <Keybuk> mvo: why doesn't Breaks work in this situation?
[15:33] <Keybuk> isn't Breaks for forcing an upgrade of libdevmapper?
[15:41] <kirkland> pitti: ping
[15:42] <kirkland> pitti: testing the server iso's I'm hitting bug #203920, postgresql not starting
[15:42] <ubotu> Launchpad bug 203920 in postgresql "postresql task in ubuntu server edition (hardy) doesn't start the database" [High,Triaged] https://launchpad.net/bugs/203920
[15:43] <kirkland> pitti: /etc/init.d/postgresql-8.3 status does NOT return non-zero, and doesn't really demonstrate that the backend isn't running
[15:43] <kirkland> pitti: was wondering if you'd consider that a bug, against the status() function in /usr/share/postgresql-common/init.d-functions ?
[15:45] <mvo> Keybuk: yes, it forces a upgrade, but libdevmapper1.02 is no longer available and that confuses the resolver (a bug there). the resolver is better in hardy, but gutsy still has the buggy version
[15:45] <Keybuk> heh
[15:45] <Keybuk> oh I see
[15:45] <mvo> Keybuk: the result is that it will held back udev
[15:45] <mvo> and that is not good :)
[15:45] <Keybuk> you know best when it comes to the resolver not keeping its toys in its pram ;)
[15:46] <mvo> I wish I would sometimes ;)
[15:46] <Keybuk> so go right ahead :)
[15:46] <mvo> thanks Keybuk!
[16:03] <pitti> kirkland: pong
[16:03] <bdmurray> mvo: I ran across bug 203385 yesterday and thought it was interesting
[16:03] <ubotu> Launchpad bug 203385 in friendly-recovery "Recovery menu cannot be controlled with keyboard" [Medium,Confirmed] https://launchpad.net/bugs/203385
[16:03] <kirkland> pitti: just bouncing that 'issue' off of you before opening a bug
[16:04] <pitti> kirkland: is there actually a cluster running? pg_lsclusters shows them
[16:04] <kirkland> pitti: nope, no cluster running.  no postgres at all, in fact.
[16:05] <pitti> kirkland: ah, seems that's the bug mathiaz found then?
[16:05] <kirkland> pitti: yes, that bug is the root cause, but it sort of unearthed a second one, perhaps
[16:06] <kirkland> pitti: the fact that I run "/etc/init.d/postgresql-8.3 status", and there is no postgres running...  but that DOES NOT exit non-zero, and there's nothing that tells me that my postgres install is b0rked
[16:06] <pitti> kirkland: hm, that's indeed a pathological case
[16:06] <pitti> kirkland: if you have zero configured clusters, are all of them running or not? :)
[16:07] <kirkland> pitti: :-)  chicken, or the egg?
[16:07] <kirkland> pitti: yeah, mathiaz suggested I talk to you first
[16:07] <pitti> I'm not fussed about exiting with nonzero if there are no clusters at all
[16:07] <mathiaz> pitti: if there are not cluster then we shouldn't exit 0 IMO
[16:08] <mathiaz> pitti: it's a valid case.
[16:08] <kirkland> pitti: so the init script status is actually more about the clusters, and not so much about the status of the local postgres daemon?
[16:08] <pitti> kirkland: if you don't have any clusters (instances), there is nothing to run a postgres daemon against
[16:09] <pitti>     pg_lsclusters | awk 'BEGIN {rc=0} {print; if ($4 == "down") rc=3} END { exit rc }'
[16:09] <pitti> that's the current implementation of status
[16:10] <kirkland> pitti: yep, found it
[16:10] <pitti> which is a bit arbitrary, granted
[16:10] <pitti> since with several clusters there are so many ways to define 'success' or 'failure'
[16:10] <pitti> IOW, it fails if there is any non-running cluster, and succeeds otherwise
[16:11] <pitti> kirkland, mathiaz: if you think that a different semantics is better, please file a bug against postgresql-common and assign it to me
[16:11] <kirkland> pitti: so it starts out thinking "all is well", and only returns "not so well" if any cluster is "down"
[16:11] <pitti> in fact, I ponder replacing status() with
[16:11] <pitti>   echo "use pg_lsclusters to display the status for all configured clusters"
[16:11] <pitti> or so :)
[16:12] <soren> Quick question: In a udev rule, I can expect /dev%k to expand to a device node for the device in question, can't I?
[16:12] <kirkland> pitti: i think that would be more true to it's form
[16:12] <kirkland> pitti: LSB has a spec for what "status" in an init script is supposed to return
[16:13] <kirkland> pitti: http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
[16:13] <kirkland> pitti: not that we're anywhere close to LSB compliance :-)
[16:14] <pitti> kirkland: maybe it should return 4 for zero clusters then?
[16:14] <kirkland> pitti: yeah, that would help
[16:15] <kirkland> pitti: 0 tells me all is well
[16:15] <kirkland> pitti: and in this case, that's not entirely true
[16:15] <kirkland> pitti: you mind if I file a bug against postgres-common, and attach a suggested patch?
[16:15] <kirkland> pitti: and you can do with it what you will?
[16:15] <pitti> kirkland: no, please do
[16:16] <pitti> kirkland: just specify the desired semantics
[16:16] <kirkland> pitti: perfect, thanks.
[16:16] <pitti> I'll need to change the test suite accordingly
[16:16] <pitti> and then I'll see to changing the code
[16:16] <kirkland> pitti: sure, i'll suggest what I think is best.  you can decide for yourself how much is enough/too-far for beta-freeze changes
[16:17] <pitti> kirkland: as long as it's only status(), that's fine
[16:18] <pitti> kirkland: I did follow it
[16:18] <pitti> kirkland: that went far beyond fixing this local function, AFAIR you spoke about introducing some infrastructure and PID guessing functions?
[16:19] <kirkland> pitti: did not introduce pid-guessing functions; used ones already there
[16:20] <kirkland> pitti: but yes, it did go too far beyond fixing a single local function, i recognize and agree with that now
[16:21] <mantiena-baltix> Hi all
[16:22] <mantiena-baltix> hi cjwatson
[16:24] <cjwatson> hello
[16:28] <mantiena-baltix> cjwatson: I'm wonder how to fix bug #138252 - you wrote in last comments:
[16:28] <mantiena-baltix> 21:42 <cjwatson> ah, I see! you have them in the .desktop files but not the .mime files
[16:28] <mantiena-baltix> 21:42 <cjwatson> should be trivial to fix
[16:28] <ubotu> Launchpad bug 138252 in openoffice.org "[Ubuntu] [hardy] Office Open XML (OOXML) is not associated with OpenOffice.org, opens with File roller" [Low,In progress] https://launchpad.net/bugs/138252
[16:29] <mantiena-baltix> cjwatson: also you wrote: "With an updated Hardy system at the time of writing, double-clicking a .docx file opens it in OpenOffice.org for me."
[16:31] <mantiena-baltix> cjwatson: so, maybe you can tell me what changes are in hardy, but are missing in gutsy ?
[16:31] <mantiena-baltix> because in gutsy docx opens with file-roller, not with openoffice :(
[16:32] <seb128> mantiena-baltix: what mimetype is that?
[16:33] <pitti> ogra_cmpc: just doing an LTSP test install (on amd64 alternate) and got some problems; do you have a second?
[16:34] <ogra_cmpc> pitti, sure
[16:34] <mantiena-baltix> seb128: in gutsy I see MIME type: application/zip in file properties
[16:35] <mantiena-baltix> seb128: what Mime type shows in hardy ?
[16:35] <seb128> mantiena-baltix: I've no example to try on
[16:36] <mantiena-baltix> seb128:  example is attached to bug #138252
[16:36] <ubotu> Launchpad bug 138252 in openoffice.org "[Ubuntu] [hardy] Office Open XML (OOXML) is not associated with OpenOffice.org, opens with File roller" [Low,In progress] https://launchpad.net/bugs/138252
[16:36] <seb128> mantiena-baltix: the mime database suggests "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
[16:37] <mantiena-baltix> seb128: could you tell me which file has this line ?
[16:37] <seb128> mantiena-baltix: /usr/share/mime/packages/freedesktop.org.xml
[16:37] <seb128> mantiena-baltix: the nautilus properties indicate the correct mimetype on hardy and it uses the correct association
[16:38] <mantiena-baltix> seb128: yea, so, it seems I should just steal /usr/share/mime/packages/freedesktop.org.xml from hardy ;)
[16:39] <seb128> mantiena-baltix: what are you trying to do?
[16:39] <seb128> mantiena-baltix: hack locally to get it working?
[16:39] <mantiena-baltix> seb128: sort of - include M$ OpenXML support in our local distro, based on gutsy
[16:40] <pitti> ogra_cmpc: got my /msg?
[16:40] <ogra_cmpc> err
[16:40] <ogra_cmpc> i asnwered, but indeed i'm not regged
[16:41] <seb128> mantiena-baltix: you can try to backport shared-mime-info from hardy, it should be safe, that's mainly mimetype definitions
[16:41] <mantiena-baltix> seb128: ok, thanks for help
[16:41] <seb128> mantiena-baltix: you are welcome
[16:41] <mantiena-baltix> you too ;)
[16:41] <seb128> cd ..
[16:41] <seb128> ups
[16:44] <seb128> mantiena-baltix: the gutsy version already had those definitions apparently, weird it's not working for you
[16:50] <mantiena-baltix> seb128: are you sure, that gutsy has MS OOXML mime types ? I don't find them in shared-mime-info package from Gutsy and Nautilus displays MIME type: application/zip in file properties
[16:51] <seb128> mantiena-baltix: no, I'm not sure, I just diffed the gutsy and hardy versions and those definitions are not in the diff
[16:52] <mantiena-baltix> seb128: I've downloaded gutsy and hardy packages and see openxml in hardy, but not in gutsy ;)
[16:53] <seb128> mantiena-baltix: ah, that's 210_OOXML_types.patch in the patches in the hardy version
[16:53] <mantiena-baltix> :)
[16:53] <seb128> so you can backport the hardy package or just this patch
[16:53] <mantiena-baltix> seb128: I think I will backport whole package in my PPA
[16:56] <cjwatson> mantiena-baltix: calc is going to deal with it before hardy
[16:56] <cjwatson> it's the obvious .desktop files in debian/ in the openoffice.org source package
[16:56] <cjwatson> I don't remember the exact file names right now but I'm sure they aren't hard to guess
[17:01] <seb128> cjwatson: deal with what? the ooxml support? that's fixed in hardy already
[17:02] <cjwatson> seb128: still needs to be fixed in the openoffice.org source as well; with the fix in shared-mime-info it works partially but not entirely
[17:02] <seb128> cjwatson: hum, weird
[17:03] <mantiena-baltix> cjwatson: AFAIK cals, writer and impress .desktop files have openxml support since Gutsy
[17:03] <seb128> cjwatson: the openoffice desktop declare handling the mimetype and the definition is in shared-mime-info, that should be just working
[17:03] <cjwatson> (as I understood it when looking at the bug)
[17:03] <cjwatson> they definitely didn't when I looked at the bug last week
[17:03] <seb128> cjwatson: and that's working just fine here
[17:03] <cjwatson> I did check
[17:03] <seb128> /usr/share/applications/ooo-writer.desktop has application/vnd.openxmlformats-officedocument.wordprocessingml.document listed on my hardy
[17:04] <seb128> but I didn't upgrade since box since monday I think
[17:04]  * seb128 looks at available upgrades
[17:04] <seb128> no openoffice upgrade pending
[17:04] <cjwatson> sorry, I should have said the .mime files, not the .desktop files
[17:05] <cjwatson> as you observe the desktop files are fine
[17:05] <seb128> .mime are still used by something nowadays?
[17:05] <mantiena-baltix> shared-mime-info (0.23-4) unstable; urgency=low
[17:05] <mantiena-baltix>   * Apply freedesktop bugzilla patch for some OOXML support. (Closes: #469599)
[17:05] <mantiena-baltix>  -- Filip Van Raemdonck <mechanix@debian.org>  Thu, 06 Mar 2008 06:56:47 +0100
[17:05] <cjwatson> but things like /usr/lib/mime/packages/openoffice.org-writer are incomplete
[17:05] <cjwatson> might not be used in GNOME, but our OOo packages may be installed elsewhere
[17:05] <seb128> alright
[17:05] <cjwatson> it makes a difference to e.g. see(1)
[17:06] <cjwatson> and we can't legitimately claim the bug to be closed until that's fixed too, since we still ship those files
[17:06] <mantiena-baltix> cjwatson: does KDE use these mime files ?
[17:06] <cjwatson> mantiena-baltix: I have no idea
[17:06] <seb128> no
[17:07] <seb128> all the modern desktop environment use the freedesktop mimebase
[17:07] <cjwatson> it's trivial enough to be easier to fix than to argue about it
[17:07] <Riddell> mantiena-baltix: yes
[17:07] <seb128> Riddell: you are not using shared-mime-info?
[17:07] <Riddell> seb128: we are
[17:07] <ogra> seb128, did oyu drop the fusa/ltsp patch ? pitti just told me it ofrfers switching
[17:08] <seb128> Riddell: the question was whether KDE is use the old .mime I think
[17:08] <ogra> meh ...
[17:08] <pitti> seb128: I clicked on the other user, and it answered with an error message dialog saying something about 'blabla Xauthority blabla permissions" (and the close button is broken, but oh well)
[17:08]  * ogra excuses for his typing
[17:08] <Riddell> seb128: oh, no
[17:08] <mantiena-baltix> cjwatson: I'm not argue, I'm just asking :)
[17:08] <seb128> ogra: no, we still have the patch
[17:08] <ogra> hmm
[17:09] <ogra> ten there should be no switch option ... strange
[17:09] <seb128> is LTSP_CLIENT defined in the session?
[17:09] <cjwatson> mantiena-baltix: for a backport, I imagine it's simplest to make the obvious changes to ooo's .desktop and .mime files, and to backport the shared-mime-info change
[17:10] <cjwatson> you may only need some of that in practice but a test run will probably take significantly longer than just doing it all
[17:11] <mantiena-baltix> ;)
[17:11] <seb128> well, if they only care about desktop environment they don't need to backport openoffice, just shared-mime-info
[17:12] <ogra> seb128, yes i think the patch is buggy, i'll take a look after beta
[17:13] <kirkland> pitti: debdiff attached here: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/203966
[17:13] <ubotu> Launchpad bug 203966 in postgresql-common "init script status action does not reflect dead postgresql service" [Undecided,New]
[17:23] <Riddell> evand: for the non-live-session ubiquity install the qt frontend still offers an option of reboot/continue using CD which seems like a bad idea.  is that fixed on the gtk side?
[17:30] <TheMuso> I see that iso.sq.ubuntu.com is stills aying images from the 18th, and thats what cdimage appears to have. Should I be waiting for new images?
[17:30] <TheMuso> iso.qa.ubuntu.com even
[17:31] <evand> Riddell: it is, it's been on my todo list for the KDE side as if memory serves the KDE side still just instructs you to reboot, rather than actually giving you a button option.
[17:32] <evand> it is fixed on the gtk frontend, that is
[17:32] <Riddell> evand: I changed the KDE side to offer an option now
[17:32] <Riddell> evand: ok, I'll look into that after beta
[17:32] <evand> ah fantastic
[17:33] <cjwatson> Riddell: is that bug 203931? It's filed against oem-config, but I think that must be a mistake
[17:33] <ubotu> Launchpad bug 203931 in oem-config "kubuntu oem-config allows you to "continue using Live CD"" [Undecided,New] https://launchpad.net/bugs/203931
[17:33] <cjwatson> bdmurray: ^--
[17:33] <bdmurray> cjwatson: yes, that's a mistake
[17:34] <cjwatson> bumped over to ubiquity
[17:34] <Riddell> cjwatson: I don't know what's going on there, you should never see kdm on a live session
[17:34] <cjwatson> Riddell: sounds like an additional bug then ... wouldn't you see it if you logged out?
[17:34] <evand> ubiquity-dm spawns kdm on exit
[17:34] <cjwatson> (briefly, until it autologgedin)
[17:35] <Riddell> I've never logged out of a live CD, I usually just reboot, I thought logging out would reboot too
[17:35] <cjwatson> doesn't in Ubuntu
[17:36] <calc> where should squashfs errors on resume be filed?
[17:36] <bdmurray> calc: I saw that too - the kernel I think
[17:36] <calc> after suspending and resuming the beta cd i get squashfs errors and it doesn't completely resume
[17:36] <calc> bdmurray: ok
[17:37] <bdmurray> I haven't reported it yet though
[17:37] <calc> bdmurray: ok i'll report it
[17:37] <calc> i copied off all the log files in case any of them are useful
[17:37] <Amaranth> whoa you can suspend/resume with the live cd?
[17:37] <Amaranth> i figured that'd be disabled
[17:37] <bdmurray> Hibernate is disabled not supsend
[17:37] <Amaranth> ah, right
[17:38] <calc> suspend/resume works on the i386 cd just not the amd64 for me
[17:38] <calc> on amd64 i get squashfs errors
[17:40] <calc> the kernel source package is now called 'linux' right?
[17:40] <bdmurray> calc: that's correct
[17:40] <ogra> it always was
[17:40] <TheMuso> calc: yes.
[17:40] <ogra> oh, source ...
[17:40] <ogra> sorry
[17:41] <calc> ogra: iirc it used to be a versioned package name for the source
[17:41] <ogra> yeah
[17:42] <ogra> i read to fast and skipped "source" :)
[17:44] <calc> ogra: heh :)
[17:46] <cjwatson> not always linux-* either
[17:46] <cjwatson> it was kernel-* for a period before warty released
[17:46] <ogra> and -di is still kernel- isnt it ?
[17:48] <_MMA_> Before I go filing bugs I'm wondering if anyone has seen this. When using sudo or things that need "admin privileges" I get a "Unable to resolve host" error. Not that it does it all the time. Maybe 1/10. And when it does work, asking for the password is slow to come up. On Hardy. Up-to-date. Something unknown?
[17:49] <calc> bug 203984
[17:49] <ubotu> Launchpad bug 203984 in linux "[hardy beta] [amd64] squashfs errors on resume from desktop cd" [Undecided,New] https://launchpad.net/bugs/203984
[17:49] <calc> thats the squashfs bug i reported
[17:49] <bdmurray> calc: thanks
[17:50] <calc> i'm not entirely sure if my system would completely resume even without the squashfs issue, but that can't be helping things, heh
[17:50] <jdong> _MMA_: is your host name set properly and defined in hosts.conf?
[17:50] <_MMA_> yes
[17:50] <jdong> _MMA_: ok I give up :)
[17:50] <_MMA_> 1st thing I looked at. :P
[17:50] <bdmurray> calc: which log file has the squashfs errors?
[17:51] <bdmurray> ah, found it
[17:52] <calc> bdmurray: should be in kern.log and dmesg
[17:52] <calc> since its kernel error
[17:53] <calc> i attached the other files in case they were of any use in tracking down the issue
[17:53] <calc> too much info usually doesn't hurt ;-)
[17:53] <_MMA_> jdong: TBH, I can only say "yes" by comparing the Hardy one to Gutsy. They look the same so I can only assume. Something might need to be added for all I know.
[17:55] <calc> bdmurray: did your resume work even with the squashfs errors?
[17:55] <bdmurray> It did one time not the second time
[17:55] <calc> bdmurray: ah ok
[17:56] <calc> bdmurray: one time i got continually scrolling squashfs errors
[17:57] <cjwatson> ogra: -di> yes
[17:58] <calc> oh btw, why do we have separate live session and install session now?
[17:58] <calc> i haven't tried the install part yet, but it seems redundant since the live session has the installer icon on the desktop?
[17:59] <cjwatson> hardy-bootloader-review spec
[17:59] <bdmurray> calc: one is ubiquity only without a full desktop
[17:59] <cjwatson> also, the install-only mode is lighter on memory
[17:59] <ion_> Sounds good.
[18:00] <ion_> Let's add compcache to the next release, and it will install on even smaller amount of RAM. :-)
[18:00] <cjwatson> and bug 109064
[18:00] <ubotu> Launchpad bug 109064 in ubuntu-cdimage "Boot-up option 'Start or install Ubuntu' scares new users" [Undecided,Fix released] https://launchpad.net/bugs/109064
[18:00] <cjwatson> ion_: already on the list :-)
[18:01] <calc> bdmurray: oh ok
[18:02] <calc> 109064 didn't scare me but confused me due to the perceived redundancy :)
[18:02] <ion_> cjwatson: Btw, i made a compcache-utils package with an init script that loads the module and swapons, with a /etc/default file you can set the cache size, e.g. "" for the module's default, "50%" for 50% of RAM, "512M" for 512 MiB etc. The package also builds a compcache-source package which can be used with module-assistant, but that of course will become unnecessary when compcache makes it into linux-ubuntu-modules.
[18:02] <calc> oh also is the language selector supposed to automatically pop up?
[18:02] <calc> on my system it did
[18:02] <calc> it showed the boot menu then almost immediately after it popped up the language selector
[18:05] <ogra> calc, yes
[18:06] <ogra> it looks a bit scary but the functionallity is good
[18:08] <calc> looks a bit ugly too since it automatically pops up obscuring most of the screen
[18:08] <cjwatson> ion_: thanks, that'll be great
[18:08] <cjwatson> calc: I agree it looks ugly; there's a bug for it
[18:09] <ogra> but it forces you to select a lang first, which is the important point here
[18:09] <cjwatson> I'm not sure how to make it better with the time available :-/
[18:09] <ogra> surely something to revisit in intrepid
[18:09] <cjwatson> perhaps just a "Select your language" heading would do?
[18:09] <ogra> it fulfills the purpose
[18:09] <cjwatson> would make it look less like a mistake
[18:10] <ogra> can you have scrollboxes in gfxboot like whiptail --menu ?
[18:10] <ion_> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/200765/comments/6
[18:10] <ubotu> Launchpad bug 200765 in linux-ubuntu-modules-2.6.24 "Add compcache modules, allowing ubiquity installs on 256MB machines." [Medium,Triaged]
[18:10] <ogra> i think putting that up centered like a popup win would look a lot better
[18:11] <calc> ogra: yea it would look a lot better, I don't know if its possible though
[18:11] <ion_> cjwatson: (The OLDDEV thing is just temporary, it's not going to go to Ubuntu.)
[18:12] <cjwatson> ogra: would need implementation :-/
[18:12] <cjwatson> it's possible, but there's no widget for it yet
[18:12] <ogra> right, intrepid, as i thought
[18:12] <ogra> i think its good as is even it doesnt look so nice
[18:13] <cjwatson> I'll look at adding a heading
[18:13] <cjwatson> I think that would be the smallest change that reduces the confusion
[18:13] <ogra> yup
[18:17] <TheMuso> Does the language selection on the disk have a timeout?
[18:18] <cjwatson> 30 seconds
[18:18] <cjwatson> in fact after 30 seconds it will simply boot
[18:18] <cjwatson> urgh, I forgot about accessibility; I guess the instructions need to be updated to say press Enter then F5, sorry :-/
[18:21] <TheMuso> cjwatson: Thats alright, I'm letting the community know.
[18:21] <soren> what's the policy for uploading stuff right now? I have a rather serious bugfix for multipath-tools, I'd like to push.
[18:24] <soren> ...but I'm not sure who frozen we are at this point?
[18:26] <pitti> soren: uploading is always fine, it'll land in unapproved
[18:27] <pitti> soren: depending on how critical it is we can accept/respin images, or just release-note it  have people upgrade after install
[18:27] <soren> pitti: Ah, point.
[18:28] <pitti> since this doesn't sound install-critical, I guess the latter is adequate?
[18:29] <soren> Yeah, that'll probably be fine.
[18:34] <davmor2> are there any xubuntu devs here?
[18:38] <mvo> bdmurray: I suspect the menu bug is actually caused by the udev being held-back
[18:40] <bdmurray> mvo: Right, up and down arrows didn't work for me but I thought his point about root shell being the default was valid.
[18:42] <james_w> davmor2: #xubuntu-devel is probably your best bet.
[18:42] <mvo> bdmurray: aha - right
[18:47] <jdstrand> hi slangasek!
[18:47] <slangasek> jdstrand: hey
[18:47] <jdstrand> slangasek: would you mind looking at bug #203898
[18:47] <ubotu> Launchpad bug 203898 in openldap2.3 "slapcat broken when default apparmor profile is enabled" [Undecided,In progress] https://launchpad.net/bugs/203898
[18:48] <slangasek> looking at it, or approving an upload for it...? :)
[18:48] <jdstrand> slangasek: I have a packaging patch that seems sane, but wanted to run it by you
[18:48] <jdstrand> slangasek: look at
[18:48] <slangasek> ok, peeking
[18:48] <slangasek> so making them hard links really fixes the issue?
[18:48] <jdstrand> slangasek: yep
[18:49] <jdstrand> slangasek: it is a 'feature' of apparmor
[18:49] <slangasek> hmm - because then the canonical path of the binary doesn't get rewritten to /usr/sbin/slapd
[18:49] <slangasek> understood
[18:49] <jdstrand> symlinks are normalized to the binary pointed to
[18:49] <jdstrand> but hardlinks are evaluated as itself
[18:50] <slangasek> you've confirmed that they end up correctly as hardlinks within the binary package?  (ISTR that this works with dpkg, but just to be sure...)
[18:50] <slangasek> otherwise, I don't see any problem
[18:50] <jdstrand> slangasek: yes
[18:50] <slangasek> ok, go for it then
[18:51] <jdstrand> slangasek: ran it through qa-regression-testing (with added tests for slapadd and slapcat for good measure)
[18:51] <slangasek> cool
[18:51] <jdstrand> slangasek: cool thanks.  I'll upload with the added goodies for apparmor migration (like what I did for bind9)
[18:52] <jdstrand> slangasek: since I read your answer on bind9, that'll be post-beta
[18:52] <slangasek> speaking of qa-regression-testing, you should be able to drop the hardy special-case for SASL passwords again; it's supposed to work now, and if it doesn't we should know about that
[18:52] <jdstrand> slangasek: goes to check that-- I thought I already did
[18:52] <slangasek> jdstrand: feel free to upload it any time, it can sit in the queue with a dozen other packages until after beta
[18:52]  * jdstrand nods
[18:52] <slangasek> oh, maybe you have; you hadn't last I looked
[18:53] <jdstrand> slangasek: seems the server overlays are fixed too (I marked the bug as fix released)
[18:54] <slangasek> ... ok then :)
[18:54] <jdstrand> (and I did already handle the sasl bits)
[18:54] <slangasek> I don't think I touched the server overlay stuff, so glad to hear it fixed itself ;)
[18:54] <jdstrand> well, I think a new version or two of openldap came in and I hadn't checked it in a while
[18:55] <slangasek> true, I just don't know why the new versions fixed it
[18:55] <slangasek> (I'd been running the tests here before upload, too)
[18:55] <jdstrand> it ran passed three times in a row, so I figured "it's fixed!"
[18:56] <jdstrand> s/ran/ran and/
[19:20]  * ogra pokes google carefully ....
[19:20] <ogra> hmm
[19:23]  * \sh thinks about a beer tonight ... after this day of bad buggers
[19:25] <stgraber> _MMA_: Ubuntu Studio ISOs are waiting for testers http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all
[19:26] <_MMA_> stgraber: Already done actually. If I have another day to call it Beta, I'd like to do another build once 2 fixes hit. Should be today.
[19:27] <stgraber> _MMA_: please report your result so we can coordinate testing :)
[19:28] <_MMA_> stgraber: Added.
[19:28] <slangasek> _MMA_: I'm happy to roll new images for you as needed, just say the word
[19:28] <stgraber> _MMA_: thanks
[19:29] <slangasek> _MMA_: the Ubuntu beta will still happen tomorrow, but you don't have to do your beta at the same time (it just means you won't be in the announcement that /I/ send out, but no big deal)
[19:30] <_MMA_> slangasek: I see. The 2 fixes are small but I'c like to have 'em in. I'll talk to my guys. If they feel its not a big deal we'll go with the build from today.
[19:34] <_MMA_> s/I'c/I'd
[19:56] <TheMuso> slangasek: I just uploaded genpo, which has a fix we would like for UbuntuStudio. When you get the chance, could you please accept it, and respin disks once the binary is built? Thanks.
[20:30] <LaserJock> who's archive day is it today?
[20:33] <slangasek> TheMuso: genpo accepted
[20:34] <TheMuso> slangasek: Thanks.
[20:37] <slangasek> bryce, tjaalton: so if someone were to provide some insight into bug #204035, that could be of certain indirect benefit for the beta release, since it's hard for the release manager to get things done while he has to keep resetting his desktop... :)
[20:37] <ubotu> Launchpad bug 204035 in xserver-xorg-video-intel "945GM: server crashes with "Fatal server error: lockup"" [High,Confirmed] https://launchpad.net/bugs/204035
[20:38] <TheMuso> Ouch.
[20:42] <\sh> slangasek: I'm asking you as relmgr...how should MOTU deal with patches introducing LPIA changes? just forgetting them during release cycle, or should we push them to mobile devs, who couldn't deal with the speed of new versions, regarding universe only?
[20:43] <bryce> slangasek: hmm, we've had a few of these i830WaitLpRing errors reported, though I suspect they're caused by a few different things.  I'll investigate and see what workarounds exist.
[20:45] <slangasek> \sh: universe is not governed by beta freeze, only by feature freeze; so the patches should be handled accordingly
[20:45] <slangasek> bryce: ok, cheers
[20:48] <\sh> slangasek: this is not the problem :) the problem is: 1. a small ammount of motu knows about LPIA 2. the speed of change inside universe is much higher then mobile-devs can provide patches to new versions...it's now my second time I ran into this very special problem (now it's claws-mail which is universe, patch against 3.3.0 and 3.3.1 was pushed yesterday to the archives)
[20:52] <slangasek> \sh: err, so why is whoever's updating claws-mail not incorporating the existing patch?  how much patching could lpia possibly need?
[20:53] <slangasek> zul: I don't understand your followup to bug #180493 - how long does it take to get what message?
[20:53] <ubotu> Launchpad bug 180493 in samba "nmbd shuts down when network disconnected" [Medium,Confirmed] https://launchpad.net/bugs/180493
[20:53] <bryce> slangasek: with #176377 (which I reported upstream), it sounds like the workaround is to downgrade to -intel 2.1 which makes the issue go away.  Users are in the process of git-bisecting to see which change between 2.1 and 2.2.1 introduced the failure.  Upstream seems unable to reproduce the issue themselves (nor have I, although I have similar hardware), but a number of users confirm it, and evidence so far suggest its the same
[20:53] <bryce> root problem for everyone.
[20:53] <zul> slangasek: how long for that message to show in your log files
[20:53] <infinity> \sh: I'm with slangasek on this one.  I did a lot of the original lpia patches, despite not being a "mobile dev", and most are only a line or two, and are incredibly obvious.
[20:54] <slangasek> zul: which message?
[20:54] <infinity> \sh: For some desktop software, it might be 3 or 4 lines (ie: changing some ./configure options, etc), but again, painfully obvious.
[20:55] <slangasek> zul: I cited three different chunks of log file there
[20:55] <\sh> infinity: most stuff is ui changes...which is hard to add to new versions for a non-lpia-guy :) I, e.g. would need a device for testing to know what changes are incorporated, and to know how to port those changes to a new version...regarding the special example, it's not just few lines, but see for yourself in bug #198861  which is already outdated, because 3.3.1 hit the archives
[20:55] <ubotu> Launchpad bug 198861 in claws-mail "There's no flag to enable hildon interface when building for lpia" [Undecided,New] https://launchpad.net/bugs/198861
[20:55] <zul> slangasek: the "No subnets to listen to" yeah I was trying to reproduce the problem
[20:55] <zul> slangasek: nm..:)
[20:56] <\sh> infinity: I'm not talking about simple build fixes...I'm talking about ui changes which are not easily to see when you don't have anything to do with such a device
[20:56] <slangasek> zul: for all intents and purposes, that one should be instantaneous after you kill -HUP the process
[20:56] <zul> slangasek: gotcha
[20:56] <slangasek> \sh: oh, hildon; that's a somewhat different story than lpia
[20:57] <\sh> slangasek: right :)
[20:58] <infinity> \sh: Okay, fair enough, that patch not only expect MOTU to understand debian/rules, but to also understand autotools...
[20:58] <davmor2> slangasek: any idea how long these new images will be?
[20:58] <infinity> \sh: It still doesn't demand any understanding of hildon, really.
[20:59] <nixternal> hey, is the display settings with Ubuntu missing or something with these latest hardy isos?
[20:59] <infinity> \sh: (ie: I can divine what's going on there, and I'm not a hildon dev)
[20:59] <slangasek> davmor2: still a half hour out; I've been delayed by my X bug, am firing the build now
[21:00] <davmor2> slangasek: NP
[21:00] <nixternal> bah, Screen and Graphics Preferences is hiding under the Applications menu right now if nobody has seen that
[21:01] <bryce> nixternal: yeah, I need to commit something to shut that out
[21:01] <nixternal> groovy
[21:01] <\sh> infinity: reading the gtk stuff is not difficult...I'm thinking about stuff like, adding new glade xml templates for hildon etc. regarding me, I would be able to deal with this stuff, when I would have an simulator/emulator for this stuff, as I have for symbian phones ;)
[21:01] <nixternal> dude, I was going nuts trying to figure that one out
[21:02] <\sh> infinity: I just want to make sure, that those patches are not lost, just because there is no one who takes care about it
[21:02] <bryce> nixternal: I assumed just removing all category entries for it would make it disappear, but instead it seems to make it go to a default location
[21:02] <emgent> heya people
[21:05] <infinity> \sh: For complex patches, it's entirely appropriate to put the patch author in the patch header (I'm talking debian/patches here, not tiny changes to debian/rules), and beg them for help on upgrades if integrating the patch with the new version is beyond the skills of the person doing the upgrade.
[21:06] <infinity> \sh: Those cases should be rare, but I realise sometimes a patch can be opaque to some people.
[21:08] <\sh> infinity: as I said, galculator was the first one, which we didn't updated in time, because of a new patch missing ;) and if someone could point us to a hildonizing emulator or whatever it needs to show up with the different ui, I'll be happy to deal with all this on motu side :)
[21:33] <infinity> Hrm, does anyone have a quick fix for "The font in the gdm input box is so huge that it spills vertically out of the login prompt"?
[21:33] <infinity> I assume it's related to "tiny screen + huge resolution = weird DPI"
[21:36] <slangasek> I hadn't heard of that one at all
[21:36] <infinity> Just ran into it on the new laptop.
[21:36] <infinity> 14 inch screen, 1400x1050, hence why I'm guessing it's DPI-related.
[21:37] <infinity> May also be DPI auto-sensing issues with the nvidia binary driver, since nv doesn't identify my display.
[21:37] <slangasek> right, what does xdpyinfo claim for your physical dimensions and resolution?
[21:38] <bryce> infinity: ah, those are typically caused by buggy EDID reported by the monitor, such as reporting physical screen dimensions as cm when they meant mm, etc.
[21:38] <slangasek> I'm not sure why the text would be scaled differently than the login box itself, though; surely both bits should have the same concept of the display size
[21:38] <slangasek> bryce: so quirks to fix it?
[21:39] <bryce> infinity: slangasek's right that you should check xdpyinfo first, then also review the EDID (via Xorg.0.log, or ddcprobe or get-edid | parse-edid)
[21:39] <bryce> slangasek: righto
[21:39] <mjg59> bryce: In my case, it seems to be that X forced my DPI to 96
[21:40] <mjg59> bryce: FWIW, I see this despite my EDID data being correct
[21:40] <bryce> mjg59: did you also get massively out sized fonts, or just slightly?
[21:41] <mjg59> Slightly. THe bottom part of the font spills outside the widget.
[21:41] <infinity> bryce: "dimensions: 1400x1050 pixels (291x210 millimetres), resolution: 122x127 DPI"
[21:42] <infinity> bryce: Yeah, it's not 3 times the size of the widget or anything, but it spills out (where I'm used to the "dots" being well inside the widget)
[21:42] <slangasek> well, those numbers come out right then
[21:43] <bryce> ok, the 96 dpi font forcing was done to combat the hugely outsized font issues people were seeing due to wacked out edid's.  I don't know if we've accumulated sufficient quirks to let us drop the dpi forcing, but presumably that would resolve the slight font missettings
[21:44] <slangasek> Daviey, superm1: how are things looking for mythbuntu to have a beta at the same time as Ubuntu?
[21:44] <mario_limonciell> slangasek, should be very feasible.
[21:44] <mario_limonciell> we can generate live disks and have them on our mirrors and then use the alternate ones generated by you guys
[21:45] <infinity> bryce: Ahh, kay, so it's not a driver bug, but a forced font thing.  Check.
[21:45] <slangasek> bryce: mmm, not a good change to make this late in the cycle then, "don't know how many broken EDIDs are left" isn't very tractable :/
[21:45] <infinity> bryce: And only with gdm, I assume?... Since my fonts on the desktop are sufficiently cute and tiny.
[21:45] <infinity> bryce: (Which is why I don't care deeply... Having an ugly login box beats having an ugly desktop)
[21:46] <slangasek> mario_limonciell: ok; you guys are doing your own ISO testing, and things look good?
[21:46] <mario_limonciell> slangasek, this past weekend tested out the alt's and they looked good
[21:46] <mario_limonciell> when will the candidate's be in place?
[21:47] <slangasek> mario_limonciell: the candidate images are already in place
[21:47] <mario_limonciell> slangasek, okay great.  I'll tell our folks to grab them today and try them out
[21:47] <mario_limonciell> set to announce beta on Friday right?
[21:47] <slangasek> Thursday...
[21:47] <mario_limonciell> ...
[21:48] <mario_limonciell> i'll let them know irght now then :)
[21:48] <slangasek> ok :)
[21:48] <Daviey> mario_limonciell: are we following the same time line as Ubuntu from now?
[21:48] <mario_limonciell> Daviey, that's the plan provided things stay stable enough for us
[21:48] <mario_limonciell> Daviey, can you generate a live i386 right now, test it and push it around the mirrors provided things look good then?
[21:48] <mario_limonciell> have tgm or DaveMorris do an amd64.
[21:48] <Daviey> great.. we should talk about a testing framework
[21:49] <mario_limonciell> yeah well for 8.10 I want to get our live disks generated by cdimages.ubuntu.com too, and then we can join the standard testing framework
[21:49] <Daviey> mario_limonciell: ok, i'll just have to jump on a pc
[21:49] <mario_limonciell> thanks Daviey
[21:50] <Daviey> would be good to get out live cd's built daily :)
[21:52] <mario_limonciell> Daviey, also ask laga to particularly test the diskless stuff on the disk
[21:53] <bryce> slangasek: I agree.  Sounds like a good thing to do once intrepid opens.
[21:54] <bryce> slangasek: quirks are usually pretty viable backport candidates so if in intrepid we find the font situations' sorted out, we could consider un-forcing 96 dpi for 8.04.1 perhaps
[21:55] <bryce> infinity: I don't grok grub 100%, but yeah the dpi situation is separate for gdm and for the logged in X.  I suspect something may be fixing things post-login
[21:56] <Daviey> mario_limonciell: I've been working on a script to test mirror consistency btw
[21:56] <Daviey> ie, are they current
[21:57] <mario_limonciell> didn't tgm throw something like that together alreadY?
[21:57] <infinity> bryce: Whacky.
[21:57] <mario_limonciell> check his home...
[21:57] <infinity> bryce: Now, the million dollar question (for local tweaking, not for distro bugs/changes), is the gdm DPI-forcing in a conffile, or compiled-in?
[21:57] <bryce> infinity: that I don't know
[21:58] <infinity> seb128: ^^
[22:07] <seb128> infinity, bryce: gdm is not forcing anything that I know, it's just using whatever xorg determine as the right value
[22:07] <seb128> infinity: GNOME is forcing 96 dpi though (after the login)
[22:08] <infinity> seb128: Oh, hrm, so the issue is rather the inverse... That makes more sense.
[22:08] <infinity> seb128: The GDM widget itself doesn't scale, but the font does, and since my display is 122dpi (or so), the font is too big for the widget.
[22:09] <infinity> seb128: Sound about right?
[22:09] <seb128> yes
[22:09] <infinity> seb128: Forcing the DPI in xorg.conf would "fix" that, I assume?
[22:09] <seb128> yep
[22:09] <infinity> seb128: Danke.
[22:10] <seb128> infinity: you're welcome
[22:10] <infinity> seb128: Worst part about a new computer, is tweaking all the little bits that annoy me. :)
[22:10] <ogra> infinity, nah, admit, its fun ... :)
[22:10] <infinity> "Yay, it works, but... It's... Not quite right!"
[22:10] <infinity> ogra: It used to be fun when I was younger, now it's just tedious.
[22:11] <ogra> dont talk to me about age :P
[22:11] <infinity> ogra: Just because you're ancient doesn't mean I don't still feel the big three oh.
[22:12] <ogra> heh
[22:12] <\sh> ogra: there are still people much older then the two of us ;)
[22:13]  * heno updates tracker with new Live Ubuntu images
[22:14] <heno> please test ^
[22:14] <heno> http://iso.qa.ubuntu.com
[22:16] <slangasek> heno: thanks, you just beat me to it
[22:17] <heno> :)
[22:19]  * TheMuso syncs new live images...
[22:45] <TheMuso> slangasek: Any ETA on ubuntustudio? I'd like to try and test today before I head off for the weekend if possible...
[22:49] <slangasek> TheMuso: thanks for the prod, spinning it now; shouldn't take more than 15 minutes or so, IIRC
[22:49] <TheMuso> slangasek: Thanks.
[22:50] <_MMA_> :)
[23:00] <slangasek> TheMuso: images built, mirroring now
[23:04] <TheMuso> slangasek: Thanks.
[23:14] <alex_joni> greetings, short security-related question
[23:14] <alex_joni> how is access to repository signing keys kept in ubuntu?
[23:15] <jdong> they are stored in a high-security fort guarded with gatling guns.
[23:16] <jdong> or maybe that was the gold reserves. I always get those two confused in my mind :)
[23:16] <jwendell> pochu, could you fix bug #201440?
[23:16] <ubotu> Launchpad bug 201440 in anjuta "Please sponsor anjuta 2.4.0 into hardy" [Undecided,New] https://launchpad.net/bugs/201440
[23:17] <TheMuso> _MMA_: It seems like one of the fixes that was accepted, genpo, didn't make it onto the disks. Your call as to whether you really want this included, as it is only an icon update after all...
[23:17] <pochu> jwendell: sure, on it
[23:17] <jwendell> pochu, thanks :)
[23:19] <alex_joni> jdong: I was actually beeing serious :)
[23:20] <jdong> alex_joni: I wish I knew :). Probably one one of the central servers the archive admins have access to.
[23:21] <infinity> alex_joni: Only a tiny number of us have access to archive signing keys on the master (not world-visible) server.
[23:21] <cjwatson> alex_joni: do you mean the central repository, as in archive.ubuntu.com signing keys?
[23:21] <alex_joni> cjwatson: yes
[23:21] <alex_joni> and I am *not* interested in gaining acces or the like, I'd just like to know the policy if it's public
[23:22] <cjwatson> alex_joni: the normal signing key is kept on the master archive machine (restricted access, inside datacentre, few logins), since it needs to be used automatically every time the publisher runs
[23:22] <slangasek> oh, well since you've told us you're not interested in gaining access, that makes all the difference then ;)
[23:22] <ion_> If you ever lose the private key, just give me a shout, i have a backup.
[23:22] <alex_joni> I need to set up a sub-repo for custom packages, and would like to do it properly
[23:22] <infinity> alex_joni: Ideally, the signing should not happen on an internet-facing machine.
[23:23] <cjwatson> alex_joni: in the event that that is compromised, there's a master signing key which is never kept in full on the network, but which is split up among seven pieces of offline media held by senior Canonical staff
[23:23] <infinity> alex_joni: So, build your rep and sign it on an internal machine, then mirror it to your "public" archive.
[23:23] <cjwatson> alex_joni: this is probably overkill for a small archive. :-)
[23:23] <alex_joni> infinity: that's the current scenario.. but
[23:23] <cjwatson> what infinity says is generally the most practical, sane approach
[23:23] <alex_joni> we have a board of directors for the project I work on..
[23:23] <infinity> alex_joni: Going beyond that for a small archive is likely overkill, as Colin says.
[23:23] <alex_joni> and the members change yearly
[23:24] <alex_joni> so having one member holding a key, could result in .. oddness for the next board
[23:24] <cjwatson> give them a fragment of the key rather than the whole key
[23:25] <alex_joni> cjwatson: so have the full key somewhere to do the automated signing
[23:25] <alex_joni> and each member holding a subset of it
[23:25] <wasabi> Two keys.
[23:25] <wasabi> no?
[23:25] <cjwatson> alex_joni: it sounds more reasonable to sign the automatic key with a master key that's held in fragments by the directors
[23:25] <wasabi> Yeah. Two keys.
[23:25] <infinity> Two keys, if you're doing the fragment method, yes.
[23:25] <cjwatson> we use libgfshare-bin for this
[23:26] <infinity> Master key always offline, you can rotate the archive key (and resign it) whenever you feel the urge.
[23:26] <wasabi> This way if it is compromised, you can use the master key to issue a new one.
[23:26] <cjwatson> apt has special support for this type of scheme as of hardy
[23:26] <cjwatson> see the two keyrings in hardy's ubuntu-keyring.deb
[23:26] <alex_joni> well, thanks you a lot for the pointers.. I'll look into these, and hopefully figure things out
[23:26] <wasabi> Though if you rotate board, and a board member refuses to give his piece back.
[23:26] <wasabi> Split it into redundant pieces.
[23:27] <wasabi> So N-1 board members are required. ;)
[23:27] <infinity> RAID5 keys.
[23:27] <wasabi> Yeah
[23:27] <alex_joni> our main platform atm is dapper.. but we are working on hardy support :)
[23:27] <cjwatson> you should use an N-of-M scheme anyway in case one gets lost, or a board member is unavailable
[23:27] <cjwatson> schemes such as 3-of-5, 3-of-7, 4-of-7 are fairly usual
[23:27] <infinity> RAID15, works.
[23:27] <alex_joni> we are 5, so 3-of-5 sounds best
[23:28] <infinity> In most organisations, this is probably overengineering, unless you suspect a board coup. :)
[23:28] <cjwatson> on dapper, you may just have to suck up occasionally having to tell your users to change their key
[23:28] <infinity> But, yeah, the general principle, tailored to your current situation, should do.
[23:28] <cjwatson> (by some out-of-band trusted method)
[23:28] <wasabi> YOu also have to ask what type of organization you are, and whether you can reasonably expect a board member to basically violate a contract.
[23:29] <alex_joni> cjwatson: I don't expect out of the ordinary situations to appear (where the key needs to change), but it would be best if we are prepared for such an event
[23:29] <alex_joni> wasabi: open source project, voluntary stuff
[23:29] <cjwatson> I agree that it is better to plan for such things in advance when you have time to do so
[23:29] <alex_joni> so basicly anyone can decide any given day to throw the towel ;)
[23:30] <infinity> s/violate a contract/violate a contract that could result in criminal action/
[23:30] <wasabi> Yeah.
[23:30] <alex_joni> then there's the bus-scenario .. so having a single point of failure is not the best thing to rely on
[23:30] <wasabi> I prefer the cliff scenario.
[23:30] <alex_joni> infinity: that's quite slim as a chance (with the current board)
[23:30] <wasabi> It's much more imaginative.
[23:30] <infinity> Lots of people will violate contract if the only remedies are civil, fewer people want to be brought up on criminal charges, oddly enough.
[23:31] <wasabi> Imagine that.
[23:31] <LaserJock> cjwatson: you mean Mark doesn't have a sticky note somewhere with the archive key passphrase? :-)
[23:31] <alex_joni> but having a proper policy, will ensure things for the future..
[23:31] <infinity> And, especially in the US, but elsewhere too, gaining unauthorised access to systems is a criminal offense.
[23:32] <cjwatson> LaserJock: correct
[23:32] <infinity> alex_joni: Yes, the better your processes the better, security is all about balancing "effort" with "possible outcomes", since nothing is ever "perfect".
[23:32] <infinity> (In a 3-of-5 scenario, you could still have a mutiny, but again, how likely is it?)
[23:32] <alex_joni> infinity: indeed
[23:33] <alex_joni> well.. thanks again for all the insight
[23:33] <alex_joni> (and for the work on ubuntu)
[23:33] <alex_joni> our users are quite happy working with it
[23:33] <infinity> alex_joni: While it may seem redundant, it can also be a helpful security practice to point out the very real possibility of criminal action should such a mutiny occur. :)
[23:33] <infinity> alex_joni: Fear can be much more secure than any technical solution, with the right group.
[23:34] <infinity> (ie: Not worth mentioning with "screw the man" hacker types, but worth mentioning to people with families who don't dig jail)
[23:34] <alex_joni> oh, we are aware of the things a criminal can do with a signing key
[23:35] <infinity> alex_joni: No, no.  I mean "criminal action" as in, "if any of you screw over our archive with your key fragments, we will pursue criminal action".
[23:35] <infinity> (ie: call the cops, press charges, be very grumpy)
[23:35] <alex_joni> infinity: hmm, don't think I got that
[23:36] <infinity> alex_joni: Criminal action = "We'll press charges and you may go to jail", Civil action = "We'll sue you for some random amount of money"... Compromising computer systems is a criminal offense in most western countries these days.
[23:36] <alex_joni> ok, I get that
[23:37] <infinity> alex_joni: Making people aware that if they abuse the trust you give them, they could go to jail, can often be more effective than any attempts to split keys 15 ways.
[23:37] <suweid> Hello, I want to write a transliteration utility for Ubuntu, that would take into account phonetic translitteration of different languages instead of one-to-one mappings currently availible, for example my native tongue - Russian. There exists a set of rules for how russian is most often translitterated into ASCII (for example www.translit.ru), and it involves mappings such as "s" maps to one char, but "sch" maps to another, so to complete 
[23:37] <suweid> task i need to hijack the keyboard quite early on... Is there a way to do that? Easily. :)
[23:37] <cjwatson> suweid: hooking into scim would be the usual way to do this
[23:38] <infinity> alex_joni: Like I said, fear shouldn't be the backbone of your security infrastructure, but having it footnoted in a contract when the keys are handed out isn't a bad plan to make people realise the severity of the responsibility being given to them. :)
[23:38] <cjwatson> suweid: scim-tables-additional already ships an input method for Russian ...
[23:38] <alex_joni> infinity: well, a short downside for that is that our board is not a formal entity
[23:38] <suweid> Is that so, let me investigate.
[23:38] <alex_joni> I mean, not a registered entity
[23:39] <infinity> alex_joni: Formal entity makes no difference, if you formally empower (and disempower) each keyholder, on a time-limit or such.
[23:39] <cjwatson> suweid: we don't enable it by default, but you can turn it on in System -> Administration -> Language Support -> Enable support to enter complex characters, then log out and log back in
[23:39] <alex_joni> infinity: ok, got your point.. don't think it will ever get that far though :P
[23:39] <infinity> alex_joni: Much like an employee becomes a "cracker" the moment he's fired, even if he still has access to his employer's computers.  Your board members become rogues when their board term expires.
[23:40] <suweid> Hey, that's great! I feel a little silly that i tried to reinvent the wheel though...
[23:40] <infinity> alex_joni: In the end, should someone abuse your trust, there's little you can do about it that doesn't involve the police (or hiring someone's grandmother to chastise them), so it doesn't hurt providing fair warning. :)
[23:41] <cjwatson> suweid: it appears to support "qawerty", which doesn't seem like what you're talking about
[23:41] <cjwatson> so it might need a new method - but that's the framework
[23:42] <suweid> Okay, thanks again, I'm going to investigate.
[23:42] <alex_joni> infinity: well, I haven't heard of any OSS project going that far
[23:42] <alex_joni> hope the OSS comunity stays that way :P
[23:42] <infinity> alex_joni: Not that you know of, at any rate.
[23:42] <Kopfgeldjaeger> n8
[23:42] <infinity> alex_joni: I can't imagine many projects that would want to publicise having raised criminal action against "one of their own" for being an idiot. :)
[23:43] <alex_joni> infinity: haha, surely not
[23:43] <alex_joni> maybe just about "for beeing an ass.."
[23:43] <infinity> Well, fine, s/idiot/ass/, then.
[23:43] <infinity> We only punish people for idiocy by ridiculing them on IRC. :)
[23:44] <alex_joni> I mean ill-intended person
[23:47] <alex_joni> infinity: can you describe the difference between master key and archive key?
[23:50] <infinity> alex_joni: Archive key exists in full on the machine that auto-signs the archive.
[23:50] <infinity> alex_joni: Master key exists in fragments, and is used to sign the archive key.
[23:50] <alex_joni> so once set up, the master key has no use, until a new archive key is needed?
[23:50] <infinity> alex_joni: Exactly.
[23:50] <infinity> alex_joni: It's used only to sign new keys or revoke old ones.
[23:51] <infinity> (Well, revoke signatures from old ones, since an outside entity can never revoke a key outright)
[23:51] <alex_joni> hmm.. here's a thought.. currently we have no *dedicated* server which is not a user-owned server, or a server where more than one board-member has access
[23:52] <alex_joni> so I'm not sure if the scenario can be implemented as *cleanly* as you do for ubuntu
[23:52] <alex_joni> could somebody go to the *offsite* server, and just reissue a new archive key?
[23:53] <alex_joni> or would that one be an invalid key?
[23:53] <infinity> It would be invalid if not signed by the master key, if you're using the chaining method from hardy.
[23:53] <infinity> (The trick is to only distribute the master key to your users, so their apt only trusts the archive key implicitly, not explicitly)
[23:54] <cjwatson> we distribute both, as otherwise they'd need network access to verify any packages we shipped
[23:54] <alex_joni> ah, I see now
[23:54] <infinity> cjwatson: Oh, feh.  We need to find a clever way to fix that too.
[23:55] <cjwatson> surely gpg can't do two-level checks without having the public key in the middle
[23:55] <cjwatson> that seems kind of fundamental
[23:55] <infinity> cjwatson: (I haven't looked at the current apt implementation)
[23:55] <infinity> cjwatson: Can we not distribute both keys, but only trust one?
[23:55] <cjwatson> it has a scheme to update from the net and trust anything signed by the master key
[23:55] <infinity> trusted.gpg and keyring.gpg?
[23:55] <cjwatson> that's what we have
[23:55] <infinity> Right, assumed, but your last comment confused. ;)
[23:56] <cjwatson> you said "only distribute the master key to your users", but you have to distribute both
[23:56] <calc> Riddell: i just realized something that is fairly obvious... all of dapper (not just the ubuntu cd) needs to be upgradable to hardy properly since a user could have installed various things outside of whats on the cd (including parts of kde, etc)
[23:56] <infinity> cjwatson: Yeah, bad wording.  "Only trust the one key".
[23:56] <cjwatson> calc: yup
[23:56] <calc> cjwatson: do we have any kind of testing to make sure that works?
[23:56] <cjwatson> calc: meet mvo
[23:56] <Riddell> calc: yes, mvo has been testing the whole world
[23:56] <calc> cjwatson: heh ah
[23:56] <calc> cool :)
[23:56] <cjwatson> otherwise known as "upgrade test machine"
[23:57] <calc> i used to have a script that i used on kde that would spit out what conflicts/replaces items i needed, so i wouldn't break upgrades on debian, but it was not automated at all
[23:58] <cjwatson> there's a file conflict checker for Ubuntu, FWIW
[23:58] <pochu> jwendell: I've requested a sync for it
[23:58] <cjwatson> http://conflictchecker.ubuntu.com/possible-conflicts/
[23:59] <cjwatson> for instance http://conflictchecker.ubuntu.com/possible-conflicts/hardy/main.txt has "openoffice.org-hyphenation_0.2_all[gutsy/main, hardy/main, feisty/main], openoffice.org-hyphenation-en-us_2.3-5_all[hardy/main] ['usr/share/myspell/dicts/hyph_en_US.dic']"