[00:02] <bryce> directhex: this is the public build
[00:02] <bryce> well, ubuntu public build.  Dunno if it's released to the world in general yet.
[00:02] <directhex> latest version on ati.com is catalyst 9.2
[00:02] <bryce> directhex: so?
[00:03] <directhex> which is... hm... 8.582
[00:05] <bryce> I'm sure 8.600 will be available from their website before too long, meanwhile you can have it in jaunty today
[00:06] <directhex> and it adds xserver 1.6 support, presumably, since you're bothering to upload it?
[00:06] <bryce> that is correct
[00:07] <directhex> hm, i heard xserver 1.6 support wasn't due until the release after next. good to know there's no horrible driver migration needed in the release upgrade this time
[00:07] <directhex> or hang on, wasn't the latest version gonna dump support for a bucket of cards?
[00:08] <bryce> sorry, I'm not at liberty to comment on that
[00:09]  * Laney tests
[00:10] <directhex> Laney has a radeon?
[00:11] <Laney> x1950 gt
[00:11] <Laney> I know nothing about it other than it makes pretty pictures appear on my screen
[00:11] <Laney> (and plays l4d and tf2 ^_^)
[00:12] <directhex> i have a 4870 on my toolbox i'm meant to test
[00:13] <bryce> I tested both the latest -ati and -fglrx on an hd4850 and it worked beautifully
[00:14] <directhex> i'm meant to re-examine the old "who sucks more under linux" chesnut, and was handed the 4870 as ~equivalent to my geforce. i'm putting off testing until i have a screen that can do the HD video playback test without scaling
[00:17] <bryce> directhex: good luck with that.  Actually I'd be interested in the results.
[00:19] <directhex> bryce, still not happy about the number of tests available to me - apparently we don't have any current contacts at epic so i can't squeeze unrealengine3 from them for testing with... which leaves limited options for modern tests
[00:19] <bryce> directhex: ever tried phoronix test suite?
[00:20] <directhex> bryce, the test suite itself is a great tool, but i don't think michael at phoronix fully understands which benchmarks are appropriate when and why
[00:20] <directhex> bryce, so it's a good starting point
[00:21] <bryce> sort of was my take too
[00:21] <bryce> on my (overwhelmingly lengthy) todo list to play with it some day
[00:21] <directhex> one detail makes me go "o_O" at it
[00:22] <directhex> console apps written in php do that
[00:23] <bryce> heh, yeah
[00:24] <directhex> i need to better understand unigine, so i can exert more scripted control over detail levels over multiple runs
[00:24] <directhex> oh, and any idea whether you still need to restart X to change ansiotropy/antialiasing on a radeon?
[00:24] <directhex> years since i've used one
[02:29] <adelie42> question: Setup virtualbox to do some patch testing, and after installing guest additions, only start up to a CLI. Guest addidions removed X, which I figured was normal... What did I miss here?
[02:29] <adelie42> Jaunty alpha 6 install, fully updated
[06:48] <tjaalton> asac: dropping the no-bitmaps link from fontconfig made some pages really ugly in ffox
[06:49] <tjaalton> bug 344629
[06:50] <tjaalton> and a screenshot from bug 305394 to illustrate: http://launchpadlibrarian.net/24015504/fontconfig_firefox.png
[06:52] <dholbach> good morning
[06:54] <bryce> heya
[06:54] <dholbach> hi bryce
[07:04] <pitti> Good morning
[07:05] <pitti> bryce: nice! I'll watch out for it
[07:06] <bryce> pitti: it's uploaded now, so go ahead and put jockey changes in at your convenience
[07:10] <dholbach> doko: can you check out bug 324708? :)
[07:28] <mvo> doko: could you please have a look at bug #338395 ?
[07:32] <doko> dholbach. mvo: yes, on my list
[07:33]  * dholbach hugs doko
[07:33] <doko> mvo: any news on the short reads?
[07:35] <mvo> doko: no feedback from the user yet
[07:36] <doko> had one report for gcc as well
[07:37] <mvo> oh?
[07:38] <mvo> hm, I should probably add some debug code to dpkg to see if we can get more information if that error happens
[07:41] <KaiL> new intel driver; new fglrx - today seams to be a good day ;)
[07:56] <taavikko> Any news on upstart 0.5 to make it in jaunty or +1 ?
[08:09] <maxb> Well, we're in FeatureFreeze so it seems rather unlikely for jaunty
[08:14] <KaiL> who killed the clock applet? ;)
[08:14] <Hobbsee> ME!
[08:14]  * Hobbsee MUHAHAHAHAHAHA
[08:15] <KaiL> Hobbsee: so if anybody misses a meeting today, they all will blame you ;p
[08:17] <Hobbsee> KaiL: oh, whacko.  I'll switch all the meetings on to aussie time too, then?
[08:17] <Hobbsee> KaiL: in all seriousness, WFM.  I'm not sure it is broken, or if so, how
[08:18] <KaiL> crashes here after todays updates on loading
[08:19] <Hobbsee> did you check for bugs?
[08:19] <KaiL> none yet, as it looks
[08:20] <KaiL> I guess, then it's time to fill one ;)
[08:20] <KaiL> oh, wait..
[08:20] <KaiL> this time it loads?!
[08:20]  * Kamping_Kaiser suspects Hobbsee is toying with you KaiL 
[08:21] <Hobbsee> haha
[08:21] <Hobbsee> go figure
[08:21] <KaiL> Kamping_Kaiser: as that damn applet does... now it's back again
[08:22] <Kamping_Kaiser> hehe
[08:54] <KaiL> hm, which packages does the authentification to be able to load gdm?
[08:56] <seb128> load gdm? or log in?
[08:57] <KaiL> I try to update as few a possible before I can get an X session to do a short test on the new fglrx
[08:57] <seb128> I don't understand the question
[08:57] <seb128> update what?
[08:57] <seb128> you don't need to update anything to have gdm working it didn't change for years
[08:58] <KaiL> strange
[08:58] <KaiL> but we'll see after the full update is done
[08:59] <KaiL> I hoped, it would be possible to only update the xserver from an intrepid-install to try the new fglrx before everything get's updated
[09:00] <KaiL> I know, silly idea ;)
[09:00] <directhex> i'm just uploading an intrepid version to my ppa, actually
[09:00] <directhex> #  fglrx-installer_8.600-0ubuntu1~intrepid~dhx1.dsc  (1.4 KiB)
[09:00] <KaiL> now it's to late ;)
[09:01] <directhex> well, you see where impulsiveness gets you now!
[09:01] <KaiL> that "8.600" gives some hope for more improvements than only x-server 1.6 ;)
[09:01] <KaiL> like working sensors without a manual xorg.conf
[09:02] <directhex> there IS a changelog
[09:02] <asac> tjaalton: hmm. thats for site specific fonts?
[09:02] <asac> tjaalton: is that ffox 3 or 3.1?
[09:02] <directhex> the changelog only mentions closed bugs though
[09:03] <KaiL> which is a quite good looking list ;)
[09:06] <tjaalton> asac: 3.0
[09:06] <tjaalton> asac: on the forums someone suggested to link ../conf.avail/70-no-bitmaps.conf
[09:11] <asac> tjaalton: no bitmap? hmm
[09:11] <asac> tjaalton: do you see this? can you go to font preferences and disallow sites to use their own fonts?
[09:12] <asac> maybe that fixes it=
[09:12] <asac> ß
[09:12] <asac> ?
[09:12] <taavikko> ffox 3.1 is showing also weird fonts in some sites
[09:13] <tjaalton> asac: yes, it started when the new fontconfig was installed
[09:13] <tjaalton> will try
[09:14] <tjaalton> asac: seems to help
[09:14] <philwyett> Can someone with ubuntu-devel list admin rights please give the awaiting moderation list of posts a kick. Thanks
[09:18] <Keybuk> bah
[09:19] <Keybuk> /etc/init.d/exim4 reload is not Ronseal-Compliant
[09:21] <soren> Whuh? Why is tracker-indexer suddenly running on my system?
[09:23] <KaiL> oh, new intel driver seams to have a usable performance again ;)
[09:23] <soren> Keybuk: "Ronseal"?
[09:24] <Keybuk> soren: it does NOT do what it says on the tin
[09:24] <Keybuk> in fact, it stops your mail server altogether
[09:24]  * Keybuk watches all the e-mail come back
[09:31]  * directhex paints a fence with exim4
[10:12] <lool> pitti: around?  http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt you mention debian-maintainers # pitti, not relevant for Ubuntu
[10:13] <lool> pitti: I think it's helpful for things like who-uploads or dget -x to work without warnings on Ubuntu when fetching Debian sources
[10:13] <lool> We have other keyrings in the archive for similar reason (such as to debootstrap a Debian chroot from an Ubuntu install), so I would like it if we could get that package in Ubuntu as well
[10:24] <cjwatson> lool: bug 180323
[10:24] <cjwatson> (for history)
[10:24] <cjwatson> justification's rather weak
[10:24] <lool> I think I'll reopen with my above comments
[10:24] <directhex> isn't it just a keyring?
[10:25] <lool> It is
[10:25] <directhex> isn't that useful, given source packages may be signed with keys inside it?
[10:26] <lool> directhex: Exactly the argument I made earlier
[10:26] <asac> slangasek: when you have a minute, could you please set your lp.199140 network-manager branch to "merged" ... so it disappears from the active branches list ;)?
[10:26] <directhex> lool, saves a meg or two of archive space though!
[10:26] <oly> hi, Any one able to tell me where to look to make applications show up in system-services application ??
[10:29] <lool> cjwatson: I reopened the bug with above rationale and a bit more
[10:31] <lool> I wonder what motivation Kmos had
[10:33] <Laney> would an Ubuntu dev keyring be useful?
[10:52] <apw> pitti, thanks for that checkbox upload
[11:00] <lool> cjwatson, pitti: Submitter agrees with the rationale for keeping the keyring; would you mind reverting the removal and closing the bug as wontfix?
[11:04] <cjwatson> lool: done
[11:06] <lool> cjwatson: thanks!
[11:13] <seb128> ogra: do you know if edubuntu-desktop really requires screem? it's the only thing in main still using gtksourceview1
[11:13] <seb128> and one the few things using libgnomeprint*
[11:13] <ogra> seb128, i dont do edubuntu anymore, ask LaserJock ... i know there was a discussion for a screem replacement though
[11:14] <seb128> does edubuntu require main or can it use universe?
[11:14] <lool> cjwatson: 2009-03-18 11:10:31 WARNING Upload was rejected:
[11:14] <lool> 2009-03-18 11:10:31 WARNING     Unsupported custom section name 'raw-keyring'
[11:14] <ogra> seb128, currently still main afaik
[11:15] <lool> cjwatson: Should I upload a version manually to allow us to set an override, and then we sync it again?
[11:15] <cjwatson> lool: I think it needs an Ubuntu upload that removes the dpkg-distaddfile bit
[11:15] <cjwatson> we can't do anything useful with that in our archive; its purpose is special communication with the Debian archive software
[11:16] <lool> wow never met that yet
[11:23] <KaiL> bryce: that ATI "8.6" driver does not only work; it runs like hell ;)
[11:23] <directhex> KaiL, 8.600
[11:23] <directhex> KaiL, 8.6 is something else. yay for consistency
[11:24] <KaiL> eh, yes..
[11:25] <KaiL> only interesting, that glxgears slowed down from 10k to 1k
[11:25] <KaiL> maybe because of better power management
[11:26] <directhex> catalyst 8.5 has an internal version number of 8.501
[11:26] <directhex> bah
[11:26] <directhex> 8.6 = 8.501
[11:26] <KaiL> ah, yes
[11:27] <KaiL> the 9.1 previously in jaunty was already a big boost in performance over the intrepid-Version
[11:28] <KaiL> and this version gives another quite good step forward
[11:29] <lool> cjwatson: Done in NEW
[11:29] <lool> +,
[11:29] <directhex> 9.1 = 8.573
[11:29] <lool> cjwatson: thanks for the hint, sent a debdiff to Anibal
[11:29] <asac> tjaalton: ok. so are the bad fonts MS fonts?
[11:30] <asac> tjaalton: maybe check which of the files i removed in the last few uploads needs to be resurrected for you
[11:38] <cjwatson> lool: I don't think it's suitable for Debian; it's an inevitable Ubuntu diff surely?
[11:38] <cjwatson> lool: turning off the raw-keyring bit in Debian would break the ability of new Debian maintainers to upload
[11:38] <lool> cjwatson: I provided a diff to only run the BYHAND chunk based on lsb_release output
[11:38] <cjwatson> ah, ok
[11:38] <cjwatson> cool
[11:41] <ogra> asac, why do my browser fonts look so odd since the last update ?
[11:42] <asac> ogra: try to select "dont allow website to select fonts" ... does that fix it for you?
[11:43] <ogra> where do i find that ?
[11:44] <ogra> ah, got it, yes
[11:44] <asac> ogra: in preferences -> content -> (fonts) advanced
[11:44] <ogra> well, though it switches everything to serif indeed
[11:44] <ogra> but now i see aliased fonts
[11:44] <davmor2> Guys I got a query about ssh/sftp between the desktops and console.  If you do ssh username@server your in the /home/username directory the same applies for sftp in kubuntu and xubuntu the only one in fact that doesn't do this (which I'm guessing is expected behaviour) is Ubuntu's sftp which drops you in /.  I know I was told before that this is deliberate I'm just wondering why when every other desktop and console d
[11:44] <asac> ogra: ok. so the other fonts are probably your mstcorefonts
[11:45] <cjwatson> urk, who accepted linux-ports on i386? its binaries are all in the wrong component
[11:45] <asac> ogra: please do sudo ln -s /etc/fonts/conf.avail/70-yes-bitmaps.conf /etc/fonts/conf.d/70-yes-bitmaps.conf
[11:45]  * cjwatson wheels out security-kernel-overrides to fix it up
[11:45] <ogra> oh, i wasnt aware i installed that :)
[11:45] <asac> ogra: i am not sure ;).
[11:46] <asac> ogra: when did you install this system? was it before feisty?
[11:46] <ogra> no, hardy
[11:46] <ogra> hmm, the link didnt fix it
[11:46] <ogra> (not even after a browser restart)
[11:47] <asac> ogra: yes. i am not saying that that link is the problem ;) i just guessing
[11:47] <asac> ogra: so remove it again ;)
[11:48] <asac> ogra: do you have 10-autohint.conf in etc/fonts/conf.d?
[11:48] <asac> if not please link it similarly
[11:48] <cjwatson> (linux-ports) ia64 too
[11:48] <tjaalton> asac: just adding the link to 70-no-bitmaps.conf seems to be enough
[11:49] <Riddell> asac: could bug 344629 be from your recent fontconfig changes?
[11:49] <asac> tjaalton: no bitmaps?
[11:49] <asac> Riddell: yes.
[11:49] <asac> almost certainly.
[11:49] <asac> we try to figure out which file we need
[11:49] <ogra> no change
[11:50] <asac> ogra: did you try the no-bitmaps thing?
[11:50] <tjaalton> asac: /etc/fonts/conf.avail/70-no-bitmaps.conf, you removed that and a bunch of other links :)
[11:50] <asac> tjaalton: yes i did a cleanup
[11:50] <asac> tjaalton: but but but ... i didnt remove the 70-no-bitmaps.conf
[11:50] <asac> tjaalton: i removed no-bitmaps.conf
[11:51] <tjaalton> asac: you cleaned the link to it
[11:51] <asac> but those are not even shipped anymore
[11:51] <asac> so if you still had them it was luck of an old install
[11:51] <ogra> sudo ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/70-no-bitmaps.conf and restarting FF fixes it
[11:51] <tjaalton> not shipped since when?
[11:51] <asac> ogra: ok
[11:51] <asac> tjaalton: not sure since when. purge fontconfig ... install the version from intrepid. its not there
[11:52] <tjaalton> asac: this is a fresh jaunty
[11:53] <asac> tjaalton: thats odd.
[11:53] <tjaalton> conf.avail/70-no-bitmaps.conf surely comes from the package
[11:53] <asac> tjaalton: yes. but there is no link to conf.d
[11:53] <asac> but let me check
[11:53] <tjaalton> in conf.d you mean?
[11:53] <tjaalton> _to_ conf.avail :)
[11:53] <asac> tjaalton: whatever. you know what i mean ;)
[11:53] <tjaalton> yes :)
[12:00] <Hobbsee> out of general curiousity, where does lsb-core actually use alien?
[12:00] <ogra> Hobbsee, rpm
[12:01] <ogra> lsb compliance requires you to be able to install rpms iirc
[12:01] <Hobbsee> ahhhh
[12:01] <broonie> LSB packages are RPMs.
[12:01] <cjwatson> Hobbsee: lsb-core doesn't actually call it, but part of the purpose of lsb-core is to provide an LSB-compliant environment, so you can think of it as a metapackage
[12:01] <Hobbsee> so it's not actually required for the package, but it's for compliance.  OK then :)
[12:01] <cjwatson> README.Debian explains
[12:02] <Hobbsee> apparently i didn't read that closely enough ;)
[12:02] <cjwatson> hmm, alternates oversized
[12:03] <cjwatson> 10MB jump on i386 from yesterday
[12:04] <cjwatson> seems to be the language pack update
[12:06] <tjaalton> asac: purge/reinstall of fontconfig confirms that conf.avail/70-no-bitmaps.conf is included in the current package
[12:06] <cjwatson> although some of GNOME has grown quite a bit
[12:07] <cjwatson> oh, no, that's an FP due to packages disappearing off cdimage's mirror
[12:08] <asac> tjaalton: err. i never said it isnt
[12:08] <asac> tjaalton: i said. that it wasnt linked by default before
[12:08] <asac> but well
[12:09] <asac> it might have slipped through
[12:09] <tjaalton> ah
[12:09] <asac> tjaalton: can you purge and install ubuntu4?
[12:09] <asac> or ubuntu5
[12:09] <asac> tjaalton: https://edge.launchpad.net/ubuntu/+source/fontconfig/2.6.0-1ubuntu4
[12:11] <tjaalton> I'll build it and compare the result with the current one
[12:14] <asac> tjaalton: the binaries are there too ;)
[12:14] <pitti> lool: debian-maintainers> sure, I don't have a strong opinion about it; it's just potentially out of date, and wrong, in Ubuntu
[12:15] <pitti> lool: seems that cjwatson dealt with this; thanks, cjwatson
[12:15] <directhex> pitti, debian-edu-archive-keyring is right?
[12:17] <lool> pitti: It has been dealt with; I think it's like the other keyrings and useful by default, even if slightly out of date
[12:18]  * directhex runs gpg --refresh-keys in celebration
[12:19] <pitti> directhex: it's in ubuntu; anything wrong with it?
[12:19] <directhex> pitti, no, but i don't see why it's any more useful than the debian-maintainers keyring
[12:21] <cjwatson> goodness, what's up with the kubuntu/alternate/amd64 daily? it's massive
[12:21] <KaiL> hm... what's that "ata1: softreset failed (drive not ready)"? A bug in the hardware or in the kernel?
[12:23] <Riddell> cjwatson: I'm trying to work that out
[12:24] <davmor2> cjwatson: live is 4 meg bigger than daily :)
[12:24] <tjaalton> asac: ah right, the postinst linked it
[12:28] <tjaalton> asac: so the debconf default used to be to disable bitmap fonts, which meant that postinst made the link
[12:28] <asac> tjaalton: ok thanks.
[12:28] <asac> tjaalton: if thats what we want, i will add that link again
[12:28] <asac> have to check whether it has regressions for good fonts
[12:41] <pitti> Riddell: btw, contrary to my belief I didn't actually find a policykit-kde package; is that functionality shipped in some libkde* package, or was it postponed for jaunty?
[12:42] <pitti> Riddell: bah, ignore me; must have been blind yesterday evening
[12:53] <KaiL> oh dear, what happened to firefox font rendering?
[12:56] <tjaalton> KaiL: bug 305394
[12:59] <KaiL> what I see on packages.ubuntu.com looks much worse than missing subpixels to me..
[13:07] <KaiL> somebody killed launchpad :/
[13:07] <Keybuk> oh noes!
[13:07] <Keybuk> you bastards!
[13:08] <Keybuk> (WFM btw :p)
[13:09] <KaiL> grr
[13:21] <pitti> tseliot: do you think it makes any sense to keep nvidia -71 in jaunty at all?
[13:23] <KaiL> pitti: doesn't work with 1.6?
[13:23] <pitti> right
[13:23] <pitti> and it's been like that for a while now
[13:24] <KaiL> crap - so no driver at all for GF2
[13:24] <KaiL> and everybody cries at ATI...
[13:24] <pitti> KaiL: both the free as well as the proprietary ati driver should be pretty good nowadays
[13:24] <pitti> KaiL: fun isn't it, how blame and praise shift around in a matter of a year
[13:26] <KaiL> pitti: yes
[13:27] <slytherin> do those high end HD cards from ATI 4xxx series have any support in jaunty?
[13:27] <KaiL> slytherin: I have a 4670 working here ;)
[13:28] <KaiL> fast like hell (even compared to 9.1) and looking quite stable
[13:28] <slytherin> KaiL: Cool. One of my friend has 4850 and I am planning to install jaunty on his PC.
[13:29] <pitti> Lure: great job on the exiv2 transition!
[13:30] <KaiL> 1002:9460 in modalias, so the driver even knows the 4890
[13:30] <tseliot> pitti: maybe Nvidia will update it sooner or later
[13:30] <Lure> pitti: thanks - that what you get if you really want something ;-)
[13:30] <KaiL> tseliot: like "somewhen in mid april", as always? ;)
[13:31] <tseliot> KaiL: maybe ;)
[13:54] <asac> ogra: why is usb-imagewriter not in archive?
[13:59] <pitti> asac: you mean usb-creator?
[14:00] <asac> pitti: no. i mean the package referenced on the UNR page ;) ... wait
[14:00] <asac> https://wiki.ubuntu.com/UNR#Using%20Usb%20Imagewriter
[14:01] <asac> http://ppa.launchpad.net/ogra/ubuntu/pool/main/u/usb-imagewriter/usb-imagewriter_0.1-1~ppa1_all.deb
[14:01] <pitti> ah
[14:01] <asac> just think if thats the primary way for installing the UNR image on a key, we should have that in the archive
[14:15] <Riddell> cjwatson: well I'm pretty confused on this oversized amd64 issue.  there's a whole load of extra gnome packages on the amd64 CDs.  on the desktop CDs they're in the shipped repository not in the squash filesystem
[14:15] <ogra> asac, we would if pitti hadnt objected my upload and u wouldnt have been to lazy to re-implement dd in python ;)
[14:15] <ogra> s/u/i/
[14:16] <asac> ogra: so you use dd command line tool in that package?
[14:17] <ogra> asac, right, its a pygtk wrapper doing some ugly stuff with dd
[14:18] <ogra> though it works ...
[14:19] <superm1> ogra, wasn't the (eventual) intention to have such support pulled into regular usb-creator to be able to write vfat filesystems?
[14:19] <ogra> right
[14:19] <ogra> or to use isos for everything and have usb-creator to convert them
[14:20] <superm1> ooh i think i'd like that best, then you can still burn them with windows boxen to real CDs
[14:20] <pitti> ogra: oh, did I? I'm afraid I can't remember any more
[14:21] <ogra> pitti, yes, you did (with valid concerns :) )
[14:22] <pitti> ogra: but dd? isn't that more or less just a read()/write() in a loop?
[14:22] <ogra> pitti, yes, but progress reporting is tricky
[14:22] <Cimi> resuming does not work here, on the ubuntu lpia release. it works if I add resume=/dev/sdXY to grub
[14:22] <pitti> I guess I have to see the code and my previous concerns
[14:22] <pitti> ogra: it seems much more tricky to me to parse it from dd than to just have a counter in the read/write loop?
[14:23] <ogra> well, you asked to rip out the dd and implement it in py ... which is the right thing
[14:23] <cjwatson> Riddell: that's odd, oem-config-gtk is being installed as well as oem-config-kde
[14:23] <pitti> ogra: hm, while that is true, I don't see why it is a reason for rejecting from the archive
[14:23] <cjwatson> Riddell: I think everything else is Recommends-following from that
[14:24] <ogra> pitti, i sadly cant remember in detail anymore
[14:24] <Cimi> https://bugs.launchpad.net/bugs/332365
[14:24] <cjwatson> germinate says:
[14:24] <cjwatson> * Chose oem-config-gtk out of oem-config-frontend-1.54.8 to satisfy oem-config
[14:25] <cjwatson> Riddell: oh, it's due to build desync. oem-config-kde is architecture: all but oem-config (and oem-config-gtk) are architecture: any
[14:26]  * ogra wonders why he cant get cups to restart on armel
[14:26] <ogra> that breaks my dist-upgrade ... hrm
[14:28] <cjwatson> Riddell: oem-config/amd64 failed to build due to some transient installability problems: http://launchpadlibrarian.net/23960563/buildlog_ubuntu-jaunty-amd64.oem-config_1.54.9_FAILEDTOBUILD.txt.gz
[14:28] <cjwatson> Riddell: I've kicked off a retry of that, and will look at improving dependencies so that this doesn't happen again
[14:31] <Riddell> thanks cjwatson
[14:33] <soren> What's the syntax in grub's menu.lst to make it use uuid's to determine its root device? In a way that update-grub can deal with, that is.
[14:45] <liw> if one wants to test a really old upgrade (breezy to dapper), are the breezy isos and package archives available somewhere?
[14:46] <soren> http://old-releases.ubuntu.com/releases/
[14:46] <ogra> old-releases
[14:46] <soren> http://old-releases.ubuntu.com/ubuntu/ for the archive.
[14:47] <liw> soren, cool, tackar och bockar
[14:48] <ogra> asac, did something in NM recently change ? my arm systems are suddenly all called localhost.localdomain
[14:48] <mcnicholls> hi. i am looking to get petsc rebuilt te remove a dep on an NBS package, but i found it doesn't build due to something to do with libhypre. I have rebuilt and installed hypre from the source package, installed it and petsc rebuild fine after that. Is it reasonable to submit a rebuild request for hypre citing that it is needed for petsc to recompile, or would i actually have to work out what has caused the problem with hypre to get it rebuilt?
[14:48] <ogra> asac, seems it applies the 127.0.0.1 value from /etc/hosts instead of whats in /etc/hostname
[14:48] <asac> ogra: nope ... maybe your nm-system-settings process isnt running?
[14:48] <ogra> hmm, right
[14:49] <asac> ogra: crashed because of /etc/network/interfaces maybe?
[14:49] <asac> ogra: if so i want that file as a bug
[14:49] <ogra> nope, interfaces has only lo
[14:49] <ogra> i guess its fallout of another bug
[14:50] <ogra> i cant start cups either on that system
[14:50] <ogra> there are actually a bunch of services it cant start
[14:50] <ogra> i just wasnt aware that nm would set localhost.localdomain by default now
[14:51] <ogra> running hostname.sh manually and doing a re-login helps though
[14:52] <ogra> pitti, why is cups always trying to reload apparmor (which we dont compile on armel)
[14:58] <soren> ogra: It should be checking for the existence of /etc/init.d/apparmor first. Doesn't it do that on your system?
[14:58] <pitti> ogra: it ships an apparmor profile, so shouldn't it?
[14:58] <ogra> soren, it might, indeed thats existing
[14:58] <ogra> but we dont/cant compile apparmor on armel
[14:59] <ogra> so there is no module
[14:59] <pitti> ogra: but it doesn't actually do that in the init script
[14:59] <pitti> ogra: but in the postinst
[14:59] <ogra> right
[14:59] <pitti> ogra: and it does check for /etc/init.d/apparmor first
[14:59] <ogra> which indeed exists
[15:00] <pitti> ogra: also, if invoke-rc.d apparmor force-reload, it doesn't fail installation
[15:00] <pitti> ogra: so that's about as much as cups can do
[15:00] <pitti> (it's || true'ed
[15:00] <ogra> ah
[15:01] <ogra> i just wonder if apparmor is responsible for all my probs in userspace if the module is missing but the profiles and tools are installed anyway
[15:01] <ogra> (my user shells get sigkilled, nm doesnt start, gdm commits suicide and cups hangs on startup are the current symptoms)
[15:05]  * ogra goes afk for 30min
[15:17] <pitti> mvo: hm, no luck with overwriting InstallProgress.fork() in bug 280291  :-(
[15:19]  * lamont wonders wtf this error comes from: http://launchpadlibrarian.net/21050486/DpkgTerminalLog.txt (and more to the point, whether he should toss but 315410 at dpkg or apt)
[15:19] <lamont> bug 315410 even
[15:28] <sbeattie> ogra: no, if apparmor is disabled kernel side, the only thing that should fail is the apparmor init scripts; there is no enforcement done in userspace, only configuration and reporting.
[15:31] <ogra> sbeattie, hmm, i still got my sigkill prob with user shells though
[15:32] <ogra> i removed all traces of apparmor in userspce now though
[15:33] <ogra> i'm pretty sure the other probs i see are caused by it
[15:37] <mvo> pitti: let me have a look
[15:37] <pitti> mvo: it's not urgent, please don't waste time on it
[15:52] <pitti> Riddell: ah, just saw policykit-kde in live action
[15:54] <Riddell> pitti: cor
[15:54] <Riddell> does it work?
[15:54] <pitti> Riddell: yes, looks fine
[15:55] <pitti> Riddell: btw, davmor tested current jockey on current Kubuntu, both with kdesu and polkit-kde; worked fine
[15:55] <pitti> Riddell: and I tested it here as well (with a mock handler); what broke for you?
[15:56] <Riddell> pitti: when I click Activate or Remove it greys out the list item and doesn't do anything else
[15:57] <pitti> Riddell: after it does that, could you send/pastebin /var/log/jockey.log?
[15:57] <pitti> Riddell: I also uploaded an important bug fix on Monday or so
[15:57] <pitti> (but it shouldn't completely break like this)
[15:59] <mvo> pitti: I added a patch that hopefully helps, a nice change between hunting a orbit crash
[16:00] <pitti> mvo: to python-apt, you mean? or to the bug?
[16:01] <mvo> pitti: to the bug
[16:01] <Riddell> pitti: http://www.kubuntu.org/~jriddell/tmp/jockey.log
[16:01] <mvo> pitti: its a bit rought, sorry for that
[16:02] <pitti> mvo: oh, interesting! so it works with os.open(), but not with TemporaryFile and .fileno()?
[16:02] <pitti> mvo: many thanks! *hug*
[16:03] <calc> how do i reset keyboard repeat rate in X?
[16:03] <pitti> Riddell: hm, that doesn't even attempt to do something; you opened jockey-kde and tried to click "activate"?
[16:03] <calc> it seems vmware disabled it for me
[16:03] <calc> setxkbmap doesn't seem to help
[16:03] <calc> at least by itself
[16:03] <Riddell> pitti: clicked remove (it did one time successfully activate the pmount "driver")
[16:04] <mvo> pitti: I have not looked at your patch in detail, I suspect it might be some disagreement between the python higher level code and the low-level os.dup2() ?
[16:04] <mvo> pitti: cheers, my pleasure :)
[16:04] <pitti> mvo: I have successfully used that approach in other places (apport), but only with pure python
[16:04] <calc> ah 'xset r on'
[16:05] <ogra> Keybuk, i'm desparetely looking for someone who can help me with my SIGKILLed user shells on armel
[16:05] <Keybuk> KILL?
[16:05] <Keybuk> that's a mighty unfriendly signal you got there
[16:05] <ogra> http://pastebin.com/f759fd172
[16:05] <ogra> i suspeced apparmor but apparently thats not at fault
[16:06] <ogra> that strace output is the result of "strace -f -s 1024 sudo -u ubuntu -s  2>/tmp/shell.log"
[16:07] <mvo> pitti: i wonder if sys.stdout() it not the system stdout (but __stdout__ instead)?
[16:07] <sbeattie> ogra: is there anything in dmesg when that happens?
[16:07] <ogra> seems shells die if i exec them as a normal user and if processes start that change the user from an initscript they hang forever
[16:07] <ogra> sbeattie, no, sadly not
[16:07] <pitti> mvo: $ python -c 'import sys; print sys.stdout.fileno()'
[16:07] <pitti> 1
[16:07] <pitti> mvo: that should be alright
[16:08] <mvo> yeah, odd
[16:08]  * mvo scratches head
[16:08] <pitti> mvo: I guess it's rather something in TemporaryFile().fileno() that it doesn't lie
[16:08] <pitti> like
[16:08] <pitti> mvo: I'll try it with os.open() and clean up temp files manually
[16:08] <ogra> sbeattie, Mar 18 17:08:13 babbage init: tty1 main process ended, respawning in daemon log ... but thats only fallout
[16:08] <ogra> (if i try to log in as a user)
[16:10] <ogra> i dont know where to look further, it all seemed to start when amitk started building kernels with apparmor enabled but now we have one thats completely without any trace of apparmor and the prob still persists
[16:10] <ogra> so i start to think apparmor was a red herring
[16:12] <ogra> i'm happy for every idea anyone might have where to look
[16:12] <ogra> as silly as the idea might be :)
[16:13] <ogra> gdm doesnt start ... but i can startx as root ...
[16:13] <ogra> so there seems to be something wrt privilege changes/separation
[16:15]  * ogra wonders is slangasek has an idea as the declared pam god here :)
[16:15] <ogra> (though i dont know why pam should sigkill anything)
[16:17] <slangasek> no pam module that I claim responsibility for will sigkill anything
[16:17] <slangasek> it's not a ulimit problem?
[16:18] <ogra> ulimit -a : http://paste.ubuntu.com/133100/
[16:19] <ogra> looks like on any other of my systems
[16:19] <slangasek> right, those look sane and normal
[16:20] <Keybuk> the only thing I can think of that sends SIGKILL is the OOM killer
[16:21] <ogra> root@babbage:~# free
[16:21] <ogra>              total       used       free     shared    buffers     cached
[16:21] <ogra> Mem:        482824      96864     385960          0       6304      74292
[16:21] <ogra> -/+ buffers/cache:      16268     466556
[16:21] <ogra> Swap:       996020          0     996020
[16:21] <Keybuk> though is the KILL always on execve()?
[16:21] <ogra> hmm, is gdm calling execve when changing to the gdm user ?
[16:21] <Keybuk> no idea
[16:21] <ogra> might be
[16:21] <Keybuk> does gdm receive SIGKILL too?
[16:22] <ogra> well, it hangs in the process of starting X, not sure where
[16:22] <ogra> cupsd as well
[16:22] <ogra> what i noticed was that its a lot of the processes that switch users during initscript execution
[16:23] <ogra> but apparently not all of them ... i.e. hald runs atm
[16:23] <Keybuk> on ARM is this?
[16:23] <lool> yes
[16:23] <ogra> Keybuk, yup
[16:23] <ogra> oh !
[16:24] <Keybuk> so the first thing I'd do is stop trying to do a full boot
[16:24] <ogra> ps aux gives me uids instead of names for some
[16:24] <Keybuk> and instead figure out, from something as basic as init=/bin/bash what you *can* do without getting SIGKILL
[16:24] <ogra> syslog    2496  0.0  0.1   1928   688 ?        Ss   16:05   0:00 /sbin/syslogd -
[16:24] <ogra> 106       2541  0.0  0.1   2704   868 ?        Ss   16:05   0:01 /bin/dbus-daemo
[16:24] <ogra> root      2568  0.0  0.2   5572  1304 ?        Ss   16:05   0:00 /usr/sbin/sshd
[16:24] <ogra> 109       2615  0.0  0.7   7016  3724 ?        Ss   16:05   0:01 /usr/sbin/hald
[16:24] <Keybuk> that's normal
[16:25] <ogra> right, intresting that i never noticed :)
[16:25] <ogra> Keybuk, well, root can do everything apparently
[16:25] <ogra> as i said above i can startx as root
[16:26] <ogra> but gdm commits suicide after it restarted once or twice
[16:26] <Keybuk> yes, yes
[16:26] <Keybuk> gdm big pile of thing
[16:26] <Keybuk> start SMALL
[16:27]  * ogra boots with init=/bin/bash ... i think i tried that before and couls exec all initscripts manually, but i'll try to confirm
[16:27] <ogra> *could
[16:29] <Keybuk> stop!
[16:29] <Keybuk> don't play with init scripts
[16:29] <Keybuk> SMALLER
[16:29] <Keybuk> stop drying to debug with a 200 lb lump hammer
[16:29] <ogra> smaller like ?
[16:29] <Keybuk> "su"
[16:29] <Keybuk> "exec"
[16:29] <Keybuk> "&"
[16:29] <ogra> root@(none):/# su ogra
[16:29] <ogra> bash: no job control in this shell
[16:29] <ogra> ogra@(none):/$
[16:30] <ogra> aha
[16:30] <ogra> so here we dont die
[16:30] <Keybuk> isn't that interesting
[16:30] <ogra> it is
[16:30] <Keybuk> work up from there
[16:30] <Keybuk> if you're bold, try "login" :)
[16:31] <ogra> works fine
[16:31] <ogra> so do i see an upstart bug ?
[16:31] <Keybuk> no
[16:31] <ogra> or something thats missing in the kernel to give upstart all it needs ?
[16:31] <Keybuk> it's probably a syscall the ARM kernel maintainers haven't bothered to implement
[16:32] <ogra> note that a patch for ppoll/pselect is in that kernel i use
[16:32] <Keybuk> "setuid() ?  when someone needs that, I'll get around fo it"
[16:32] <ogra> the issue showed up before the patch was in though
[16:32] <Keybuk> all you proved is that it's not a fundamental problem
[16:32] <Keybuk> as in the kernel is clearly behaving when there's nothing else running
[16:33] <Keybuk> so now you need to try and replicate the problem
[16:33] <Keybuk> maybe figure out a minimal set of commands on the console that always receive SIGKILL
[16:33] <Keybuk> and figure out *when* in the timeline that starts happening
[16:33] <Keybuk> if the set fails after boot
[16:33] <Keybuk> but works with init=/bin/bash
[16:33] <Keybuk> try single user mode
[16:33] <ogra> works fine
[16:33] <Keybuk> if that works, try starting rc2 scripts
[16:33] <ogra> single is how i started working on that
[16:34] <Keybuk> and then you'll find something where if you do it, things stop working
[16:34] <ogra> and couldnt reproduce
[16:34] <Keybuk> you can reproduce though
[16:34] <Keybuk> you pasted an strace ;)
[16:35] <Keybuk> so something was clearly different between the time you did reproduce and the time you didn't
[16:35] <ogra> oh, indeed
[16:35] <Keybuk> and that difference is going to be what's causing the problem ;)
[16:43]  * ogra hugs Keybuk ... it fails after calling /etc/rcS.d/S17procps
[16:43] <Keybuk> interesting
[16:43] <Keybuk> that one sets sysctls
[16:43] <ogra> right
[16:44] <Keybuk> look in /etc/sysctl.d
[16:44] <Keybuk> also check for an /etc/sysctl.conf
[16:44] <slangasek> grep -rvh ^# /etc/sysctl*
[16:44] <LaserJock> I need to get ubuntu-edu-{preschool,primary,secondary,tertiary} metapackages promoted. Should I file a bug or is a archive admin around who could do it?
[16:45] <slangasek> LaserJock: does something depend on them already?
[16:45] <LaserJock> slangasek: no, edubuntu-desktop will but germinate doesn't like adding them until they are in Main
[16:46] <ogra>  /etc/sysctl.conf is all commented as it should be, i cant imagine 10-console-messages.conf or 10-network-security.conf to be at fault here so i suspect its vm.mmap_min_addr = 65536 in /etc/sysctl.d/10-process-security.conf
[16:47] <LaserJock> slangasek: I'm just splitting the edubuntu-desktop's deps into sub-groups so no new dependencies are there or anything.
[16:47]  * ogra comments that and reboots
[16:47] <slangasek> LaserJock: hrm? germinate should like it fine, the standard practice is to seed then promote
[16:48] <LaserJock> slangasek: germinate says it's skipping them
[16:48] <slangasek> hmm
[16:48] <LaserJock> slangasek: perhaps cjwatson knows but I tried first to just seed then promote
[16:49] <ogra> YAY !!!!
[16:49] <slangasek> LaserJock: so that doubly doesn't make sense to me, because the binaries are all built from the same metapackage, which ought to have enough sense to add the deps on its own
[16:49] <ogra> Keybuk, thanks so much for taking my hand and leading me ... vm.mmap_min_addr = 65536 is the reason ...
[16:49] <cjwatson> slangasek: germinate-update-metapackage indeed doesn't add things until they're in main
[16:50] <slangasek> ah
[16:50] <slangasek> ok, promoting
[16:50] <cjwatson> slangasek: but the seed should be sufficient
[16:50] <Keybuk> ogra: really?
[16:50] <ogra> yep
[16:50]  * Keybuk wonders why that is done as a sysctl config override at all and not a kernel patch
[16:50] <LaserJock> cjwatson: sufficient for what?
[16:50] <slangasek> apparently null dereferences are an integral part of the ARM platform? :P
[16:53] <Keybuk> I wonder whether it's something the ARM link loader does?
[16:54] <ogra> well, it started when amitk enabled something in the kernel ... now to find that something :)
[16:55] <Keybuk> CONFIG_SECURITY probably
[16:55] <Keybuk> ya know
[16:55] <Keybuk> ...
[16:55] <ogra> ogra@babbage:~$ grep CONFIG_SECURITY /boot/config-2.6.28-10-imx51
[16:55] <ogra> # CONFIG_SECURITYFS is not set
[16:55] <ogra> CONFIG_SECURITY=y
[16:55] <ogra> # CONFIG_SECURITY_APPARMOR is not set
[16:55] <ogra> CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
[16:55] <ogra> hmm
[16:55] <Keybuk> a) that sysctl change is pointless, because it's the default
[16:55] <Keybuk> arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
[16:55] <Keybuk> b)
[16:55] <ogra> CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 ??
[16:56] <ogra> yeah
[16:56] <Keybuk> I find it mighty suspicious that the ARM arch is missing a def for that entirely
[16:56] <ogra> not here
[16:56] <Keybuk> "not here" ?
[16:56] <cjwatson> LaserJock: for promotion
[16:56] <ogra> no, i got a newer kernel than you :)
[16:56] <Keybuk> I'm looking at Linus' git
[16:56] <Keybuk> there's a default for that sysctl defined for blackfin
[16:56] <Keybuk> for mips
[16:56] <Keybuk> for powerpc
[16:56] <Keybuk> for x86
[16:56] <Keybuk> but not ARM
[16:57] <ogra> ah
[16:57] <Keybuk> this vaguely implies to me that nobody's tested this stuff there ;)
[16:57] <Keybuk> it's not massively critically serious of course
[16:57] <Keybuk> but it _is_ interesting
[16:57] <Keybuk> (more interesting is that our own kernel configs override it back to 0 again <g>)
[16:58] <ogra> well, its in the middle of being properly merged with the default ubuntu config
[16:58] <ogra> thats the reason we talk here, since i do the userspace testing of amits builds atm
[16:59] <Keybuk> I can't see anything particularly in the kernel that would send you SIGKILL of course
[17:00] <ogra> well, i think thats something the security team should be able to elaborate on
[17:00] <Keybuk>         if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
[17:00] <Keybuk>                 return -EACCES;
[17:01] <Keybuk> EACCES is not SIGKILL
[17:01] <ogra> indeed
[17:01] <ogra> and my strace doesnt have any mentioning of EACCESS
[17:01] <Keybuk> apparmor has a slightly more complicated variant
[17:02] <Keybuk> but still fundamentally the same
[17:02] <Keybuk> so I'd be cautious of declaring that it's definitely the cause
[17:02] <Keybuk> it's more likely that the bug is something else
[17:02] <Keybuk> and this just happens to trigger it
[17:03] <ogra> right, but i know how to work around it and can file a bug with a pointer now
[17:05] <kees> uhm...  ?  arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
[17:05] <kees> when did that become a kernel default?
[17:06] <lool> nice
[17:07] <kees> I mean, I'm for it, but the reason I created the sysctl for it in the first place was to avoid a kernel delta.
[17:07] <Keybuk> 5cb04df8 arch/x86/configs/i386_defconfig (Ingo Molnar    2008-05-04 19:49:04 +0200 2130) CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
[17:07] <ogra> seems no defconfig for arm has it anywhere though
[17:07] <kees> \o/
[17:07] <kees> GO INGO
[17:07] <Keybuk> kees: surely it's better to have a one line kernel delta (esp. just to our own configs!) than something in userspace that costs time and can go out of sync?
[17:08] <ogra> wasnt there an issue with wine ?
[17:08] <kees> Keybuk: if it's upstream, we can drop the sysctl.  I'm just shocked and delighted that it got made the default.
[17:08] <Keybuk> ahh, maybe there wasn't a kernel config before
[17:08]  * ogra vaguely remembers a ML thread
[17:08] <Keybuk> looks like the kernel config option was added only very shortly before
[17:08] <kees> Keybuk: I don't think there was.
[17:09] <kees> I love how all the stuff we cram into Ubuntu eventually becomes the upstream default.
[17:09] <kees> I wonder if I can convince gcc to do the same.  ;)
[17:10] <Keybuk> ogra: I would _guess_
[17:10] <Keybuk> that the ARM tool chain is trying to use the bottom 64k of memory with mmap
[17:10] <Keybuk> and sulking when it can't
[17:10] <Keybuk> maybe even the link loader
[17:11] <Keybuk> this would fit the "you get SIGKILL on exec()" pattern
[17:11] <ogra> Keybuk, heh, amits kernel is built in a cross toolchain ...
[17:11] <ogra> i'm waiting for the build in the ppa to finish
[17:11] <Keybuk> and this didn't happen before perhaps because CONFIG_SECURITY wasn't enabled
[17:11] <Keybuk> (and that entire bit of the kernel goes missing if you remove that config option)
[17:11] <ogra> which is building with our own toolchain
[17:11] <Keybuk> this is all wild hand-wavy speculation
[17:12] <ogra> right, but i can prove it soon, i was suspecting a toolchain issue though because of other things we had before ... not particulary for this one
[17:12] <sbeattie> Keybuk: zap_process from within do_coredump() in fs/exec.c does a sigaddset(&t->pending.signal, SIGKILL); but it does it for threads in the group that aren't current.
[17:13] <Keybuk> sbeattie: ?
[17:13] <sbeattie> just another possible way sigkill might be getting "sent" from the kernel
[17:13] <Keybuk> oh, sure
[17:13] <Keybuk> but that doesn't fit with the "if I turn of the mmap_min_addr sysctl it all works" scenario
[17:14] <Keybuk> isn't that just when it KILLs threads when the leader dies?
[17:16] <Riddell> pitti: the notification used by jockey is still the Qt ones which doesn't fit at all with KDE, I ported it to KNotify but don't know if it's a suitable change at this stage (it's a one line change though)  bzr+ssh://bazaar.launchpad.net/~jr/jockey/trunk
[17:17] <Cimi> is there someone who could help me?
[17:17] <Cimi> https://bugs.launchpad.net/bugs/332365
[17:17] <pitti> Riddell: you have RM powers for Kubuntu, so you tell me :)
[17:17] <pitti> Riddell: I fixed a few other things, working on one bug fix, and I'll do an upload in an hour or so, thus it would be a good time
[17:18] <Riddell> pitti: let's go for it then
[17:18] <Keybuk> Cimi: https://wiki.ubuntu.com/DebuggingKernelSuspend https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting
[17:18] <pitti> Riddell: aye, will merge; thanks!
[17:18] <Cimi> Keybuk, the thing is, it *does* suspend
[17:19] <Cimi> but resuming only works if I add resume=/dev/sda5
[17:19] <Cimi> it seems something doesn't work in the initram
[17:21] <kees> Keybuk: another weird bit is that it shouldn't kill if it's an mmap failure -- that should just disallow the mmap.
[17:21] <pitti> Riddell: is kde/jockey.notifyrc something that needs i18n'ing?
[17:21] <Keybuk> kees: right, so I'm thinking something else is doing that mmap, failing, then sending itself SIGKILL to get out
[17:21] <kees> is it perhaps trying to mmap into a 0 location during the loader?  (or is that what you were saying earlier?)
[17:21] <pitti> Riddell: and it doesn't use the title/text arguments (which are already translated) at all?
[17:21] <Keybuk> kees: that's what I was trying to say
[17:21] <Keybuk> or mmaping into a low location anyway
[17:21] <kees> ARM is weird.  :)
[17:21] <Keybuk> the link loader is the only thing I could think of which doesn't normally show up in strace ;)
[17:21] <kees> Keybuk: btw, since that's a default now, I'm going to drop the procps delta.
[17:22] <Keybuk> kees: it's kinda a default
[17:22] <Keybuk> kees: it's the upstream default
[17:22] <ogra> kees, Linux version 2.6.28-10-imx51 (root@everest) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #32 Tue Mar 17 20:18:30 EET 2009 (Ubuntu 2.6.28-10.32-imx51)
[17:22] <Keybuk> but then our kernel team override that back to 0
[17:22] <Keybuk> and then we set it back to 64k again
[17:22] <Keybuk> so you want to co-ordinate that with rtg to fix our kernel config
[17:22] <kees> Keybuk: oh?  I just looked at our git repo?
[17:22] <ogra> lets see what a natively built kernel does ...
[17:22] <Riddell> pitti: it does use the text from the application
[17:22] <kees> it's correct (64k) in our repo
[17:22] <Keybuk> is it?
[17:22] <Keybuk> it's not correct in this build ;)
[17:23] <ogra> amit uses code-sourcery to cross compile
[17:23] <Riddell> pitti: but the title comes from the .notifyrc, which should be i18n'ed
[17:23] <pitti> Riddell: ah, I see, just not the title
[17:23] <Keybuk> debian/config/i386/config:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
[17:23] <kees> oh... hrm, I see what you mean now.  i was looking at i386_defconfig  :)
[17:23] <pitti> Riddell: so I could name this .notifyrc.in and integrate it into POTFILES.in and the rest of magic?
[17:23] <pitti> Riddell: or is there any way to set the notification title at runtime? (which would ease matters)
[17:25] <Riddell> pitti: I don't think you can set the title at runtime (it's something I'd quite like the dx people to look into)
[17:25] <Riddell> pitti: so PITFILES.in would be the way
[17:25] <pitti> Riddell: ok, I'll look into that
[17:25] <Riddell> pitti: in the packaging that file needs to be installed to /usr/share/kde4/apps/jockey
[17:25] <lool> Keybuk: Do you know how we can tell the toolchain to work when it's 65536?
[17:25] <pitti> Riddell: ok, that needs to happen in setup.py
[17:26] <lool> or do we need to rebuild the toolchain?
[17:26] <Keybuk> lool: no idea
[17:26] <Keybuk> at this point it could be anything
[17:26] <TheMuso> is an archive admin able to fix up the missing package metadata for linux-ports-headers-2.6.28-5 on hppa/powerpc/sparc? Seems it is present for ia64, but no others.
[17:26] <Riddell> pitti: if that's the build system being used then yes
[17:26] <ogra> lool, lets wait for the PPA build to finish, i'll test it then
[17:26] <lool> Oh wait, it's the kernel binary
[17:26] <pitti> Riddell: a static title breaks some cases, since ui_notification() is called with differnet ones depending on the situation
[17:27] <pitti> Riddell: if you can live with that, I'm happy to merge it
[17:27] <kees> ogra:
[17:27] <kees> "On arm and other archs it should not be higher than 32768"
[17:27] <ogra> aha !
[17:27] <ogra> where is that from ?
[17:27] <kees> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=blob;f=security/Kconfig;h=bcc25d0cf3c3edee1f5535840f71fb47919fbac4;hb=HEAD
[17:28] <kees> under the help for SECURITY_DEFAULT_MMAP_MIN_ADDR
[17:28] <ogra> yep, i see it
[17:28]  * ogra sets it to 32768 to test
[17:28] <Riddell> pitti: maybe we should change the title to something generic then "Driver Manager" and make the text  "text + title"
[17:29] <pitti> Riddell: '%s\n\n%s' % (title, text), would that work?
[17:29] <pitti> well, I have that test suite, I'll find out
[17:30] <kirkland> bryce: hi, i'm processing the ArchAdmin queue for today, and I'm looking at https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/343014
[17:30] <kirkland> bryce: it looks like slangasek sync'd it earlier this week
[17:30] <Riddell> pitti: yes
[17:30] <kirkland> bryce: it's marked incomplete, possibly due to the last comment posted?
[17:30] <Riddell> pitti: actually, it might need html  <br>
[17:30] <pitti> Riddell: ah, I see; I'll test it
[17:32] <bryce> kirkland: looking
[17:32] <lool> ogra: Could you try with 32768 and tell rtg to use that if it works (instead of 0)
[17:33]  * ogra hugs kees 32768 is fine 
[17:34] <kees> ogra: ah-hA!  excellent.
[17:34] <TheMuso> kirkland: were you by chance the person who newed linux-ports binary packages today? If so, linux-ports-headers-2..28-5 has not been correctly added for hppa/powerpc/sparc.
[17:34] <TheMuso> linux-ports-headers-2.6.28-5 that is
[17:35] <kirkland> TheMuso: i don't think i touched linux-ports
[17:35] <TheMuso> kirkland: ok np
[17:35] <kirkland> TheMuso: I just accepted: http://pastebin.ubuntu.com/133133/
[17:36] <TheMuso> kirkland: np thats fine
[17:37] <bryce> kirkland: ok I didn't check if there were already bug reports for -nouveau when I filed mine, so maybe it's just a dupe report
[17:37] <cjwatson> TheMuso: what's wrong with it? I noticed it was wrong earlier and I made some adjustments
[17:37] <bryce> kirkland: also I see that it failed to build on some platforms like amd64, but succeeded elsewhere
[17:38] <TheMuso> cjwatson: linux-ports-headers-2.6.28-5 which is arch all is on ports.ubuntu.com however package metadata for hppa/powerpc/sparc doesn't appear to have it included, hense the problem showing up in ports jaunty probs
[17:38] <TheMuso> Tested by installing the linux-ports-headers package by hand and apt-get installing an arch linux-headers package, so the dependencies in the packages are correct
[17:38] <bryce> kirkland: and the last comment on that bug looks to be mistaken; I think he ran into an "ordinary" crash with nouveau
[17:40] <bryce> kirkland: oh I see, that user reopened the bug.  Silly guy, I think he's mistaken.
[17:40] <cjwatson> TheMuso: that's weird
[17:40] <cjwatson> TheMuso: that isn't normally something an archive admin *could* break
[17:41] <kirkland> bryce: okay, i'll close, and ask that user to open a new bug
[17:41] <TheMuso> cjwatson: ok, I thought it was something an archive admin had influence over.
[17:41] <cjwatson> TheMuso: I'll ask the Soyuz wizards
[17:42] <TheMuso> ok
[17:43] <TheMuso> wii cjwatson
[17:43] <TheMuso> woops sorry
[17:43] <bryce> kirkland: already done
[17:43]  * TheMuso thought you were in a soyuz channel on freenod.
[17:43] <TheMuso> freenode
[17:48] <\sh> moins
[17:49] <pitti> mvo: argh, I'm dumb; I used "if p:" instead of "if p == 0" in my previous patch
[17:49] <pitti> mvo: (with p being the result of os.fork())
[17:49] <\sh> does anyone know how to prevent d-i from asking if I would like to initialize Serial ATA Raid while auto preseeding? on my HP server it always asks me if I want to use Serial ATA...and I don't find any documentation on how to stop d-i to ask me
[17:51] <\sh> and reading partman-auto-raid pkg source doesn't help me either
[17:52] <pitti> mvo: so the TemporaryFile() approach works perfectly as well
[17:52] <cjwatson> \sh: disk_detect/activate_dmraid=false on command line
[17:52] <cjwatson> \sh: and perhaps file a bug on dmraid, it seems like a bug if it's misdetecting that
[17:52] <cjwatson> TheMuso: ^- might be worth working with \sh to get details here?
[17:53] <cjwatson> \sh: sorry, I made a typo, disk-detect/activate_dmraid=false (note s/_/-/)
[17:53] <\sh> cjwatson: hmm...i thougn partman-dmraid is removed from archives since ages.. or is it merged somehow into partman-{md,auto-raid} ?
[17:53] <cjwatson> \sh: that is not relevant
[17:53] <cjwatson> firstly, this question is asked before partman starts; secondly, yes, it's been merged
[17:54] <TheMuso> \sh: If a question gets asked like the dmraid one, does that mean its automatically preseedable, or does more have to be done with the debconf code for the question to make it so?
[17:54] <TheMuso> cjwatson: ^^
[17:54] <TheMuso> \sh: sorry not meant for you. :p
[17:55] <\sh> cjwatson: ah ok...lemme test it right away...brb 5 mins
[17:56] <\sh> TheMuso: I just inserted the mentioned option inside the preseed file nwo...if that doesn't work I'll give it a try via kernel append in pxelinux.cfg like the locale stuff
[17:57] <TheMuso> \sh: ah ok
[17:58] <cjwatson> TheMuso: generally it's automatically preseedable unless the code is doing something funny, such as explicitly setting its value or clearing the seen flag
[17:58] <cjwatson> TheMuso: a straightforward input/go/get will Just Work
[17:58] <\sh> TheMuso: works like a charm now :)
[17:58] <TheMuso> \sh: great.
[17:58] <\sh> cjwatson: thx for saving me :)
[17:58] <TheMuso> cjwatson: right makes sense.
[17:58] <cjwatson> \sh: np
[17:59] <\sh> cjwatson: is it documented somewhere, I didn't find anything about this case on the d-i wiki
[17:59] <cjwatson> no, sorry
[17:59] <cjwatson> file a bug on installation-guide in Ubuntu
[17:59] <\sh> cjwatson: har...installation-guide in Ubuntu needs a lot of changes ...
[18:00] <\sh> cjwatson: so yes..I'll file some bugs :)
[18:00] <ogra> patches accepted
[18:01] <\sh> ogra: he
[18:01] <cjwatson> \sh: I don't know that it's *that* bad
[18:01] <\sh> and now for the raid of the "tell d-i to not ask for private encrypted directories...."
[18:01] <cjwatson> \sh: I assume you're starting from the Ubuntu documentation and not the Debian documentation
[18:01] <cjwatson> for example, the Ubuntu documentation describes that point
[18:02] <\sh> cjwatson: I was going through the ubuntu documentation...
[18:02] <\sh> cjwatson: the first steps already broke my heart...nobody tells the admin that some d-i preseed settings needs to be addressed on the kernel append line
[18:02] <cjwatson> the installation guide does discuss that
[18:03] <cjwatson> oh, drat, encrypted private directory preseeding was only documented in the first jaunty upload, not for intrepid, sorry
[18:03] <\sh> cjwatson: it is somehow documented, but not really understandable (when you come from something else like preseeding or kickstarting ;))
[18:04] <cjwatson> it is documented if you read it in order
[18:04] <cjwatson> https://help.ubuntu.com/8.10/installation-guide/i386/preseed-intro.html
[18:04] <cjwatson> \sh: http://bazaar.launchpad.net/~ubuntu-core-dev/installation-guide/ubuntu/revision/435
[18:05] <\sh> cjwatson: thx :) that's helping a lot :)
[18:19] <cjwatson> TheMuso: hey, I'd claimed that rpm bug :P
[18:19] <cjwatson> ah well
[18:20] <TheMuso> cjwatson: woops, sorry, I missed that.
[18:20] <TheMuso> I'
[18:20] <TheMuso> I'm not entirely with it this morning. :)
[18:28] <mvo> pitti: aha, thanks. that solves the mystery
[18:35] <pitti> Riddell: is there any way I can test knotify with a small command line tool? I get the icon and knotify4 is running, but I don't see any bubble
[18:36] <Riddell> pitti: you need to  sudo killall knotify4    before it'll pick up the new .notifyrc file
[18:36] <pitti> ah
[18:36] <pitti> Riddell: got it
[18:36] <Riddell> yay
[18:37] <pitti> Riddell: hm, the notification has a small and a big icon
[18:37] <pitti> that looks weird
[18:37] <pitti> it probably should have only the big one?
[18:39] <Riddell> pitti: hmm, I don't remember that
[18:40] <maxb> If a bug is sitting in the "Nominated for Jaunty" state, and I think it's an important blocker, should I assume someone will review all of the nominations in time, or should I be seeking attention more explicitly? (LP: #319825)
[18:40] <maxb> LP 319825
[18:41] <Ax3> a ./gdm restart using the jaunty alpha livecd, didn't restart X, is this typical?
[18:42] <Ax3> it's just idling in a VM: "* Checking battery state...."
[18:42] <Cimi> didrocks, sorry :( https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-murrine/+bug/344154
[18:42] <pitti> Riddell: I think I'll title the notification "Hardware Drivers", then we get existing translations for free; okay? ("Restricted" is too special, since we advertise free drivers as well)
[18:43] <Riddell> pitti: sounds good
[18:43] <ScottK> maxb: Is it milestoned?
[18:43] <didrocks> Cimi: just saw it. I am thinking of murdering someone/something :p
[18:43] <didrocks> Cimi: I'm on it ;)
[18:43] <Cimi> didrocks, oh sorry
[18:43] <Cimi> symbol lookup errors
[18:43] <maxb> ScottK: no
[18:44] <didrocks> Cimi: no problem, just kidding ^^
[18:44] <Cimi> oh ok ;)
[18:44] <Cimi> thank you anyway
[18:44] <ScottK> maxb: Then it'll probably be looked at, but not at a high priority.
[18:44] <didrocks> Cimi: that's where I am happy to use bzr for packaging :)
[18:45] <didrocks> Cimi: can you please comment on the bug during I am performing the new changes?
[18:46] <Cimi> which kind of comment do you want?
[18:46] <Riddell> pitti: don't worry about the second icon, if you run plasma it uses much more pretty notifications which look much better
[18:46] <didrocks> Cimi: just that you released a new version :)
[18:46] <pitti> Riddell: oh, okay
[18:46] <Cimi> didrocks, I already did
[18:47] <didrocks> Cimi: ok, you was faster that LP to send me the e-mail so ;)
[18:47] <Cimi> maybe ;)
[18:48] <didrocks> Cimi: hopefully, there is no patch with autotools changes in this packages ^^
[18:49] <Cimi> didrocks, also 0.60.1 had the wrong link to the website
[18:49] <Cimi> it is http://www.cimitan.com/murrine
[18:49] <Cimi> and not cimi.netsons.org/pages/murrine.php
[18:50] <didrocks> Cimi: 0.90.1 or 0.60.1?
[18:50] <Cimi> I don't know if it was updated in the 0.90.x series
[18:50] <Cimi> didrocks, 0.60.1
[18:50] <Cimi> the .deb package I mean
[18:51] <didrocks> Cimi: ok, seeing it in debian/control. I change the Homepage: value
[18:52] <pitti> Riddell: this works well for me now, modulo double-icon: http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/529
[19:13] <pitti> asac: bug 278153 is a beta-release blocker, but wishlist; given that it's not a regression, I don't think it should be a release-targetted bug at all? WDYT?
[19:13] <Riddell> pitti: looks good
[19:14] <pitti> Riddell: uploaded now
[19:17] <asac> pitti: yeah. basically i wanted a decision until beta ... which is why i marked it as such
[19:18] <pitti> I see
[19:18] <asac> pitti: i will let you know tomorrow ... have to check with upstream about committments etc.
[19:19] <ScottK> asac: What's your support plan for firefox-3.1?
[19:20] <directhex> hide under a big blanket until the users have gone past?
[19:20] <asac> support until EOL
[19:20] <ScottK> asac: OK.  That sounds great.  Thanks.
[19:21]  * pitti sighs at component-mismatches
[19:21] <asac> ScottK: lets see how well i can scale ;) ... but security infrastrcture has become better. riding upstream shouldnt be a big problem
[19:21] <directhex> i thought they decided to name it 3.5 instead
[19:22] <ScottK> asac: OK.  You know my concern about FF supportability by MOTU.  As long as you and mozillateam are behind it, then I'm fine.
[19:22] <asac> ScottK: yeah. fwiw, its not branded. so basically any MOTU can touch it without risking of getting whipped ;)
[19:23] <asac> not saying i think MOTU will do that until EOL ;) ... just because thats could be a concern for mozilla stuff in universe
[19:23] <ScottK> That's something at least.
[19:23] <ScottK> Agreed.
[19:31] <ogra> pitti, please note that bug 322798 is verified to not show up anymore in recent hal builds (though the patch might still make sense)
[19:32] <LaserJock> cjwatson: since the edubuntu.jaunty seeds inherit ubuntu.jaunty can edubuntu's supported seed to be "in addition to Ubuntu's supported seed"?
[19:32] <pitti> ogra: oh, nice; I just spotted it on the milestone list and assigned it to me, but didn't look at it
[19:33] <ogra> pitti, as i said, makes sense, but not urgent
[19:33] <pitti> ogra: ok, thanks; taking off the release radar then
[19:33] <Stskeeps> ogra: ran into same problem as bug 322798 on n8x0s (alternate patch we used: http://bazaar.launchpad.net/~carsten-munk/hal/led-problem/revision/2 )
[19:34] <ogra> Stskeeps, did you try the latest hal ?
[19:34] <ogra> the OP verified it didnt show up with it anymore
[19:35] <Stskeeps> ogra: as i recall my debugging of it, the patch indicated in the bug would definately fix it
[19:35] <Stskeeps> from code logic point of view
[19:36] <ogra> Stskeeps, you should mention all that on the bug ;)
[19:39] <Stskeeps> ogra: and HAL didn't die constantly, just quite occasionally, so that might cloud the issue
[19:40] <ogra> please note that on the bug too, so pitti is aware, i only had feedback from the OP and didnt even see it myself
[19:40] <Stskeeps> yeah, done so now
[19:40] <ogra> good
[19:50] <geofft> Anyone online who can comment on the Intrepid SRU for mit-scheme (bug 341832)?
[20:04] <slytherin> seb128: did you get any time to look into DVD playback problem?
[20:07] <seb128> slytherin: no
[20:08] <seb128> slytherin: will do that after the beta freeze, there is no hurry it's not in main
[20:08] <seb128> ie that can be uploaded during the freeze or after beta
[20:08] <slytherin> seb128: ok. I was planning to upload it before beta but I will wait.
[20:10] <seb128> slytherin: well you can upload if you get confirmation that the change fixes the issue
[20:10] <seb128> we can still adjust later
[20:11] <slytherin> seb128: I am asking people on #ubuntu+1 currently.
[20:11]  * calc thinks he found the source to all the xsl related problems in OOo
[20:11]  * calc is doing a test build and if it works an upload later tonight
[20:27] <cjwatson> ogasawara: maxb asked up ^- there about bug 319825's jaunty nomination; seems like your department
[20:50] <doko> cjwatson: I don't have a list, do you still can do the db queries?
[21:05] <fta> slangasek, the last libfreetype update broke some of my stuff using ia32. there's a problem with the new FT_Get_Advance symbol that is detected in the headers (2.3.9) but not in the ia32 lib
[21:06] <fta> would be nice to update ia32libs
[21:09] <slangasek> fta: I don't claim any particular responsibility for the ia32-libs eyesore; you're a MOTU, so are also able to do the update?
[21:10] <slangasek> if you do fix it, perhaps you'd like to fix it at the same time so that gtk isn't missing symbols :-P
[21:10] <fta> well, i pinged you to inform you that your libfreetype update broke some stuff. that's it
[21:11] <fta> i can sure update ia32 but from experience, a lot of stuff are old and/or missing from there
[21:11] <slangasek> yes, this is part of why ia32-libs is a horrible hack
[21:15] <slangasek> another part is that it takes an obscene amount of time to do an upload of ia32-libs from my Internet connection, and I'd sooner avoid that in favor of getting more productive things done
[21:25]  * ScottK really wished people wouldn't call something 'Ubuntu Drupal' when it isn't actually in Ubuntu.
[21:25] <ScottK> wished/wishes
[21:32] <kees> asac: hm, I think something weird happened to fontconfig.  my ~/.fonts.conf seems to be ignored now.
[21:33] <asac> kees: what makes you think that?
[21:33] <asac> kees: which pkg version?
[21:35] <kees> asac: I *think* it's fontconfig -- it could be other things, but basically my ~/.fonts.conf-defined fonts vanished on update (2.6.0-1ubuntu9 vs 2.6.0-1ubuntu4)
[21:35] <asac> kees: what was in that file?
[21:35] <kees> http://www.outflux.net/blog/archives/2008/06/22/bold-fonts-in-libvte-gnome-terminal-terminator/
[21:36] <kees> it might be that something else is overriding the "Fixed" family.
[21:39] <asac> kees: we had a regression in u9 that you can workaround by ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/
[21:39] <asac> kees: check that its not what you are seeing.
[21:39]  * kees checks
[21:39] <tjaalton> Fixed is a bitmap font
[21:39] <kees> tjaalton: correct.
[21:39] <asac> yeah. that makes sense then i guess
[21:39] <tjaalton> so something else might've broken it
[21:40] <tjaalton> but it sounds weird not to honor .fonts.conf
[21:40] <asac> tjaalton: i dont think it doesnt honour .fonts.conf
[21:40] <andersk> Not sure if this is related, but fontconfig-config 2.6.0-1ubuntu10 is installing a /etc/fonts/conf.d/10-no-sub-pixel.conf that reappears on upgrades even if removed.
[21:40] <tjaalton> asac: but it should override the system-wide settings
[21:40] <kees> Ah! sweet font is back
[21:41] <tjaalton> kees: adding the link helped?
[21:41] <kees> asac: yeah, that fixed it.  it's because other bitmaps were appears that resolved to "Fixed" and my 1 enabled bitmap fonts was getting obfuscated.
[21:41] <kees> tjaalton: yeah
[21:41] <tjaalton> huh :)
[21:41] <asac> kees: right. good
[21:41] <asac> so its fixed in ubuntu10 for oyu
[21:41] <kees> my ~/.fonts.conf explicitly enables my local bitmap font
[21:42] <kees> asac: sweet, thanks, I see that from the changelog now.  I'd missed that I didn't have ubuntu10 installed.
[21:45] <cjwatson> doko: err, maybe, but I don't know how offhand - do you still have the necessary SQL to hand?
[21:47] <doko> cjwatson: unfortunately not, maybe cprov has?
[21:47] <cjwatson> might as well just ask him to run it then :)
[21:48] <doko> cprov: ^^^
[21:48] <cprov> doko: what was the question ?
[21:50] <doko> cprov: https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027772.html
[21:50] <cprov> doko: checking
[21:51] <doko> cprov: subtracting the packages which have been built after 2009-03-16 and which only build binary-indep packages
[21:53] <cprov> doko: anything built on lpia from -13 to -16, right ?
[21:53] <ArthurLiu> hi, who is admining the GSoC program at ubuntu ? the wiki pages don't mention it
[21:58] <doko> cprov: hmm, more specific: between the two file uploads: 2009-03-11 14:00 UTC+1 and 2009-03-16 20:00 UTC+1
[21:59] <doko> ArthurLiu: looks like Ubuntu was not accepted this year
[21:59] <ArthurLiu> wha?
[22:00] <directhex> debian was. go work on sexy debian projects
[22:01] <ArthurLiu> err, on #gsoc they say you are accepted
[22:02] <Stskeeps> look at second part of the first box, in http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009 - says accepted :P
[22:04] <doko> interesting. this did change within the last hour
[22:04] <kblin> hi filks
[22:04] <kblin> *folks
[22:05] <kblin> ArthurLiu tells me you can't find your org on the GSoC accepted list...
[22:05] <kblin> I'm happy to walk you through the steps needed to get Ubuntu to show up on that list
[22:06] <lh> doko: ping
[22:07] <kblin> or let lh tell you directly
[22:07] <bryce> heya lh
[22:07] <kblin> hi bryce, btw :)
[22:07] <lh> bryce: greets!
[22:07] <bryce> heya kblin
[22:07] <doko> lh: pong
[22:07]  * kblin is Kai from WorldForge :)
[22:07] <bryce> kblin: hey small world :-)
[22:08] <lh> hello everyone, leslie hawthorn, google open source team
[22:08] <lh> so first of all, ubuntu *was* accepted
[22:08] <SRabbelier> still is
[22:08] <lh> http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009?limit_1=50&limit_0=100&offset_1=50
[22:08] <lh> SRabbelier: smart alec
[22:08] <SRabbelier> :D
[22:08] <doko> hmm, my bad, I didn't see this when checking
[22:08] <SRabbelier> apparently some people are confused
[22:08] <SRabbelier> need to be crystal clear :P
[22:09] <lh> doko: now an issue on file for this
[22:09] <lh> so for your ideas list.
[22:09] <slangasek> kblin: nuh-uh, you're Kai from Samba!
[22:09] <slangasek> you're not fooling me
[22:09] <lh> there's some stuff already on there, but let's talk about how to improve and refine it.
[22:09] <lh> for each idea
[22:10] <lh> try to think of something that needs to get done to help move the project forward, bonus points if it is sexy. doesn't have to be fun and exciting, but always helps to have a few of those.
[22:10] <lh> please classify ideas as easy, medium, hard or beginner, intermediate, something along those lines. scale of 1-10
[22:10] <lh> helps students decide which ideas to explore first and what is best for them to tackle
[22:10] <kblin> slangasek: oh, darn, foiled
[22:11] <lh> also each idea ought to be accompanied by links to documentation
[22:11] <doko> ok, will address this tomorrow. there's another criteria which dserves bonus points: be able to find a mentor
[22:11] <lh> e.g. if you want to work on foo, check out the documentation for foo here, here and here, and this documentation on baz over here is also useful
[22:12] <lh> doko: absolutely. ideas need to have an assigned mentor and that person needs to be able to devote no less than 5 hours per week to mentoring.
[22:12] <lh> if you don't have time to mentor, don't sign up. better an idea not get worked on than a potential contributor to your community has a bad experience.
[22:13] <lh> also list where someone should ask for help or guidance, maybe that is this channel, maybe another, maybe it is a mailing list. make sure that's explicit on your ideas page.
[22:13] <lh> if you want me to review drafts, can do.
[22:13] <doko> yes, the ml is mentioned on the ideas page.
[22:14] <lh> okay great. that's all the guidance i've got for the moment. i am around on freenode frequently so if you need help i am here.
[22:15] <bryce> lh: whew, scared me a bit; I didn't see inkscape on the list, but found it buried.  Wow that's a very confusing page
[22:16] <SRabbelier> bryce: what's confusing about it 0.o
[22:16] <SRabbelier> its' the standard code.google.com style list... :-/
[22:17] <bryce> SRabbelier: there's two lists on the page, and it's unclear which of the two lists to look at (ubuntu was on the 1st, inkscape on the 2nd).  Also the lists appear to be alphabetized, so I didn't think to look at the second page, but in fact it isn't fully alphabetized and inkscape is just sorted towards the bottom for some reason
[22:17] <SRabbelier> bryce: both
[22:17] <SRabbelier> bryce: it even explains on the second list
[22:17] <SRabbelier> bryce: what the purpose is
[22:18] <SRabbelier> bryce: the list is sorted by link_id
[22:18]  * lh heads back to her overflowing inbox
[22:18] <lh> peace y'all
[22:19] <bryce> SRabbelier: fair enough, but I wouldn't have guessed inkscape's link_id would be "sxc"
[22:19] <SRabbelier> first list, actually
[22:19] <ArthurLiu> is there a specific ubuntu soc irc channel ?
[22:19] <SRabbelier> bryce: that's their fault
[22:19] <SRabbelier> bryce: don't blame me
[22:19] <SRabbelier> bryce: sxc seems like a particularly bad one, if you ask me
[22:20] <SRabbelier> "inkscape" wouldof made more sense
[22:20] <fta> Keybuk, I can't update ia32-libs because the last isdnutils wasn't built: https://edge.launchpad.net/ubuntu/jaunty/+source/isdnutils/1:3.12.20071127-0ubuntu4
[22:20] <bryce> SRabbelier: I'm not blaming anyone, just explaining why I got confused
[22:20] <SRabbelier> bryce: sorry, true :)
[22:24] <bryce> SRabbelier: so it appears an organization only gets one chance to set that, and if they make a mistake, they can't change it??
[22:25] <SRabbelier> bryce: yup
[22:25] <SRabbelier> bryce: exactly the same way with your personal link_id
[22:25] <SRabbelier> bryce: the notice about that is like, THIS BIG
[22:26] <bryce> SRabbelier: heh, expecting users to read docs... you're certainly optimistic ;-)
[22:27] <SRabbelier> bryce: oi, if they don't, I'm not helping them ;)
[22:27] <SRabbelier> bryce: you lost your right to my time when you decided not to read the docs (with "you" not referring to you personally)
[22:28] <SRabbelier> if you can't take the time to read the docs, which we wrote for this purpose, then I'm sure as hell not going to spend my time rewarding you :P
[22:28] <bryce> wow, that would save me *sooo* much work if I did that
[22:28] <tkamppeter> Any Python expert here? I can build system-config-printer without problems on my local Jaunty (updated today) and I have also uploaded it successfully yesterday. Today I upload it again (tiny patch) and get an FTBFS: setup.py says "options --install-layout and --prefix are exclusive". The same call worked yesterday.
[22:29] <SRabbelier> bryce: I dont' do it as strict as I portray it here :P
[22:29] <SRabbelier> bryce: I'm exagerating by a lot
[22:29] <SRabbelier> bryce: but I don't have the time to worry about "what if people don't read notices THIS BIG" :(
[22:30] <crdlb> tkamppeter: just drop the --prefix usage?
[22:31] <SRabbelier> anyway, if you have any suggestions on how to improve melange, please do file a  http://tinyurl.com/new-issue or drop us a note in #melange
[22:31] <SRabbelier> and even if you didn't read the documentation, I'll do my best to reply ;)
[22:31] <SRabbelier> no guarantees though :P
[22:33] <sbeattie> tkamppeter: I don't know the answer, but in your next system-config-printer upload, could you include http://launchpadlibrarian.net/23529565/system-config-printer_1.1.3%2Bgit20090218-0ubuntu5.debdiff (from bug 338442)
[22:34] <tkamppeter> crdlb: The "make install" runs
[22:34] <tkamppeter> /usr/bin/python setup.py install --install-layout=deb --prefix=/build/buildd/system-config-printer-1.1.3+git20090218/debian/tmp//usr
[22:35] <tkamppeter> This worked yesterday but today it gives the error. My patch does not touch setup.py.
[22:35] <bryce> SRabbelier: http://code.google.com/p/soc/issues/detail?id=331 seems to already describe the UI design problem that leads to the user confusion
[22:35] <SRabbelier> bryce: that one's fixed
[22:35] <SRabbelier> it was a duplicate of... another one
[22:35] <SRabbelier> lemme find it, and close it as duplicate
[22:35] <ebroder> tkamppeter: I think you want to --root=$(DEB_DESTDIR) or whatever it's called instead of --prefix
[22:36] <crdlb> shouldn't that sort of thing be done with DESTDIR (--root with distutils I guess)
[22:36] <tkamppeter> crdlb: debdiff is here: http://launchpadlibrarian.net/24068667/system-config-printer_1.1.3%2Bgit20090218-0ubuntu8_1.1.3%2Bgit20090218-0ubuntu9.diff.gz
[22:36] <SRabbelier> bryce: I'm /part-in #ubuntu-devel, please do join #melange ;)
[22:36] <bryce> SRabbelier: anyway, I didn't set up the inkscape thingee so dunno what the problem was exactly.  But really the issue now is that there seems to be no way to fix the mistake now that it's been made
[22:37] <SRabbelier> bryce: yeah, I know what you mean, but it's a technical limitation I'm afraid :(
[22:37] <SRabbelier> bryce: if we made it mutable things would be a lot slower
[22:37] <tkamppeter> crdlb: The "make install" call has the DESTDIR, the shown command line is what "make install"does internally and what worked on the build server until; yesterday and what is still working on my box.
[22:39] <crdlb> tkamppeter: it was apparently changed in the fix for bug 338395
[22:41] <pygi> hey folks
[22:41] <pygi> where is your list of gsoc09 ideas?
[22:41] <kirkland> mako: ping
[22:42] <dtchen> kirkland: mako or maco?
[22:42] <kirkland> dtchen: good call
[22:43] <kirkland> dtchen: maco, actually
[22:44] <TheMuso> dtchen: anything we need to get in for pulse before beta freeze?
[22:46] <dtchen> TheMuso: yes, quite a bit
[22:46] <dtchen> i'm working as fast as i reasonably can given i'm traveling for work.
[22:46] <TheMuso> dtchen: ok np
[22:47] <TheMuso> dtchen: anything I can help with?
[22:48] <dtchen> TheMuso: for pa, not yet. i think alsa-driver has a pending merge for ~ubuntu-core-dev.
[22:48] <TheMuso> oh ok will check up on that
[22:50] <maco> sorry my keyboard decided to pretend not to exist right when you pinged...well, all of the keyboard except ctrl alt backspace
[22:50] <maco> kirkland: whats up?
[22:50] <kirkland> maco: hiya, just looking at https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/317895
[22:51] <maco> oh right
[22:51] <kirkland> maco: tried to reproduce that again, no luck
[22:51] <maco> need to re-test that here
[22:51] <tkamppeter> sbeattie: Uploaded your debdiff as 0ubuntu10, thanks for the reminder.
[22:51] <kirkland> maco: cool, that would be muchly appreciated on this end
[22:51] <kirkland> maco: i'm about to blast an update of ecryptfs-utils that fixes 4 or 5 bugs
[22:51] <sbeattie> tkamppeter: thank you!
[22:51] <kirkland> maco: was trying to fix that one too, but still don't see where the problem actually lies
[22:59] <maco> kirkland: alright, installation starting. at some point i need to learn to automate such things
[22:59] <kirkland> maco: yeah, that helps
[23:00] <maco> is there kickstart for ubuntu?
[23:00] <kirkland> maco: mathiaz is really good at such magic
[23:00] <kirkland> maco: ack, there is.
[23:00] <maco> thought so...will have to look into it for karmic play time
[23:00] <kirkland> mathiaz: how about a blog post to communicate some of your automated installation magic you use for testing?
[23:01] <maco> whats the good of having two laptops if they dont both get some testing
[23:04] <mathiaz> kirkland: it's on my todo list
[23:04] <kirkland> mathiaz: \o/
[23:04] <mathiaz> kirkland: I plan to write a blog post (or two) about that aspect of testing
[23:05] <mathiaz> kirkland: maco: I've already wrote a post presenting the big picture: http://ubuntumathiaz.wordpress.com/2008/09/18/automate-ubuntu-server-iso-testing/
[23:05] <maco> mathiaz: thanks
[23:06] <doctormo> kirkland: hey there, got a jaunty box that had ecryptfs, which has now failed, the mount doesn't seem to mount anything, no errors.
[23:07] <maco> on the topic of testing: laserjock says vm image distribution was talked about to ease testing before but was dismissed for some reason or other. he suggested possibly because vms are bigger than isos. meh, torrents, i say. so i put a jaunty alpha 6 vm for virtualbox up at http://thepiratebay.org/torrent/4780245 if you wanna point potential testers there.
[23:09] <dtchen> it'd be more useful to have vms generated from the daily and daily-live
[23:10] <dtchen> the same rsync system could be harnessed
[23:10] <maco> thats true
[23:10] <maco> well generating from the cd could be hard. running an update on the vm each day would be easier
[23:11] <maco> but distribution on the initial vm could be painful. that's 1.1gb after i lzma'd it
[23:11] <mathiaz> maco: I've looked at ubuntu-vm-builder?
[23:11] <maco> mathiaz: its for kvm only, right?
[23:11] <maco> well kvm / qemu?
[23:11] <mathiaz> maco: it can build a vm in a couple of minutes
[23:12] <maco> granted i made the default hard disk decently sized, but an empty .vdi is sparse
[23:12] <mathiaz> maco: not only. I think it supports other format as well.
[23:12] <maco> mathiaz: does it do virtualbox? that seems to be the popular one
[23:12] <mathiaz> maco: not sure about virtualbox though.
[23:12] <maco> (i've only used it for kvm)
[23:12] <maco> virtualbox is definitely more user-friendly
[23:12]  * calc found a workaround to the problem of saving xsl related files in OOo
[23:13] <mathiaz> maco: if not, it should be easy to add virtualbox support?
[23:13] <mathiaz> maco: virtualbox more user-friendly -> how so?
[23:13] <maco> easier to reconfigure
[23:14] <maco> easy to configure to begin with. can keep the command line nicely hidden away
[23:14] <mathiaz> maco: virt-manager makes things easy to setup
[23:14] <mathiaz> maco: for kvm setup.
[23:14] <maco> i remember there's a gui somewhere for it
[23:15] <maco> it was the intimidating sort of gui that makes one say "i might as well use the command line. *gulp*"
[23:15] <dtchen> generating from the cd is not difficult; see VBoxManage
[23:17] <maco> im thinking of the class of users that dont know the command line well or at all and thus should not be using devel versions on metal. setting up kvm would be icky for them. it was icky for me, and i was following a howto on the wiki.
[23:18] <mathiaz> maco: which how-to are you refering to?
[23:18] <mathiaz> maco: what was *icky* for you?
[23:20] <maco> the first annoyance was that i was on hardy and trying to test intrepid in a vm. hardy refused to let me tell it i wanted intrepid. it'd only let me choose stable releases.
[23:20] <maco> i think the stable releases ought to offer devel releases for the vm, since that's a nice way to test
[23:22] <maco> i was on https://help.ubuntu.com/community/KVM/CreateGuests (well that used to be a chunk of a larger page). i attempted to follow the "use an iso" way to get intrepid, but that got pretty hairy. i think i had issues with what type of image to create and whether that image already existed or not. i gave up and told ubuntu-vm-builder to install a hardy vm then did a do-release-upgrade on it
[23:25] <maco> virt-install was what i found most "icky"
[23:26]  * TheMuso likes virt-install
[23:27] <maco> well finding that the docs claimed an --os-variant existed that did not was fun...
[23:27] <tkamppeter> crdlb: Thanks for the hint with the "--root", system-config-printer vuilds again (0ubtuntu11).
[23:28] <maco> i suppose documentation explaining how to use it without sudo privs would be nice. unfortunately, i cant answer that question, so i cant write that documentation
[23:28] <maco> im pretty sure its possible to use a vm without root privs though (if not: why?)
[23:34] <maco> sorry, dont mean to be whiny about the tools, i just dont think id suggest them to anyone that's used linux less than a year
[23:35] <maco> if you can figure out how to use them without extra help, you're also probably perfectly capable of troubleshooting weird breakage on actual hardware
[23:55] <kees> tjaalton: in bug 342198, do you mean that we should change /var/run or /var/db to /var/cache ?
[23:58] <maco> oh just remembered something.  there's a problem for kubuntu/ubuntu users (people with both) where if you run gnome first, seahorse sets up ~/.gnupg/gpg.conf blank because it just creates the file if it doesnt exist. that breaks things in kde because it doesn't say use-agent. the skel file has use-agent in it. can something be done to make sure the skel file is copied in before seahorse-agent starts the first time?