[00:08] <tjaalton> archive admins available? xserver-xorg-video-cyrix can be removed from the archive. it doesn't build against the latest xserver, and it's deprecated anyway. the geode driver will/does replace it
[00:18] <gnomefreak> tjaalton: ah i guess you saw the issue already
[00:19] <tjaalton> gnomefreak: about cyrix?
[00:19] <tjaalton> via should also be synced
[00:19] <gnomefreak> tjaalton: no about X in general it looks like xserver-xorg-core is broken
[00:19]  * RAOF thinks gnomefreak is talking about "the {video,input} ABI changed, so everything's uninstallable".
[00:19] <gnomefreak> most likely respinning is all it is
[00:20] <gnomefreak> ABI changed?
[00:20] <gnomefreak> uninstallable hell it wants to remove everything
[00:20] <tjaalton> input and video ABI
[00:20] <tjaalton> don't force it
[00:20] <gnomefreak> i dont
[00:20] <tjaalton> just wait until it allows an upgrade
[00:20] <RAOF> Wait until the world's been rebuilt
[00:20] <gnomefreak> dist-upgrade wanted to remove it
[00:20] <tjaalton> hm, it shouldn't upgrade
[00:21] <tjaalton> ok, well don't :)
[00:21] <gnomefreak> i know
[00:21] <gnomefreak> just wanted to make sure you were aware of it
[00:21] <tjaalton> of course
[00:21] <tjaalton> was just waiting that all the archs had the latest xorg-server
[00:21] <tjaalton> (and a bit occupied during the evening, but..)
[00:22] <gnomefreak> no rush atleast for me
[00:22]  * gnomefreak has alot fo work i can do as long as i dont use dist-* ill be fine
[00:25]  * TheMuso thinks staying on hardy is a safer bet. :p
[00:25] <RAOF> gnomefreak: Well, nouveau should now be installable, at least :)
[00:26] <gnomefreak> TheMuso: stable is always safer just not so much fun ;)
[00:42] <calc> does anyone know if there is a good debian/ubuntu mirroring program that acts as a proxy (that actually works)
[00:43]  * calc is considering writing one in his spare time
[00:43] <RAOF> You mean an apt-proxy?
[00:43] <calc> RAOF: i guess
[00:43] <calc> RAOF: iirc i used apt-proxy before but maybe not
[00:43] <calc> i know approx doesn't work very well
[00:43] <calc> it seems to nuke the archive for unknown reasons
[00:43] <RAOF> There are a couple; apt-proxy, apt-something-else, apt-zeroconf.  But I'm using squid.
[00:45] <calc> ok i'll have a look i have plenty of room for a full mirror but would rather it pull stuff as needed
[00:46] <calc> but in the past the ones i have used seemed to not work correctly :\
[00:47] <RAOF> apt-zeroconf (when it works) is pretty cool at that.
[00:47] <calc> what package is it in? i don't see it in hardy
[00:47] <RAOF> It's not yet packaged, at least officially.
[00:47] <calc> ah
[00:48] <calc> hmm i think i have used apt-cacher and approx before
[00:48] <calc> approx definitely didn't seem to work right
[00:48] <RAOF> I've used apt-proxy; that seemed to work pretty well.
[00:48] <calc> i'll give apt-proxy a try
[00:49] <RAOF> apt-zeroconf, if you're interested: http://trac.phidev.org/trac/wiki/AptZeroconf
[00:53] <calc> thanks for the tips :)
[00:53] <calc> the desc on the apt-proxy page leads me to believe it should work well and also why i thought it didn't (i think i tried it last back when it was unstable)
[00:54] <RAOF> apt-zeroconf would be cool, particularly for laptops, if it were a bit more stable.
[00:55]  * TheMuso uses apt-mirror, with a post mirror script to mirror other bits.
[00:57] <TheMuso> Since I mirror 3 architectures, and have several boxes that need to download updates every day.
[01:00] <TheMuso> Yow! Xorg flud! >)
[01:01] <RAOF> TheMuso: As in "broken" or as in "every single Xorg package has been rebuilt"? :)
[01:05] <TheMuso> RAOF: The flood of xorg related packages on intrepid-changes. I know why, but still, thats a lot.
[01:13] <kirkland> slangasek: ping
[01:19] <kantor> hi, I have renamed all the SCSI subsystem drivers (so Linux can't load them) and all the SCSI subsystem drivers are compiled as modules, but strangely the SG_GET_VERSION_NUM ioctl returns the sg driver version, how is that possible if the sg (and all the SCSI subsystem) driver was renamed and it is not loaded ??
[01:46] <calc> i see one minor issue with apt-proxy already, it uses the name you put in your sources.list for its cache dir
[01:46] <calc> so if you have different names on different machines it won't all pull from the same place
[02:07] <TheMuso> calc: Ouch.
[02:47] <superm1> slangasek, can you promote the mythbuntu alt disks to the right place now?
[03:20] <calc> it appears apt-proxy doesn't handle versions kept properly for ubuntu 'distributions'
[03:20] <calc> iow it deletes them once it reaches the limit number across distributions
[03:31] <calc> gah apt-proxy has huge number of open bugs on b.d.o
[03:31] <calc> it appears no partial mirror program works as i had found out before :\
[04:00] <TheMuso> calc: I think you might be better off investing time into debmirror or apt-mirror, however I'd recommend apt-mirror svn over the hardy package.
[05:57] <calc> TheMuso: ok
[05:57] <TheMuso> calc: You don't have to, but thats what I think works better.
[05:58] <calc> TheMuso: so is apt-mirror svn better than debmirror?
[05:58]  * calc wishes one of them would just work properly, grr
[06:00] <calc> from what i recall i wrote one myself about 8 years ago but never actually uploaded it anywhere
[06:01] <calc> apt-proxy is probably a good place to work to get a partial one going properly, but seems to need lots of work
[06:01] <TheMuso> calc: heh. I find apt-mirror from svn more flexible, as your configuration file is similar to sources.list. Debmirror has to be called multiple times if you need to pull from more than one source. For example, I would have to call debmirror twice, one for ports.ubuntu.com, and one for archive.ubuntu.com.
[06:01] <TheMuso> Apt-mirror on the other hand does it all at once.
[06:01] <TheMuso> However, apt-mirror doesn't yet support rsync.
[06:03] <calc> oh ok
[06:04] <calc> apt-proxy would really be ideal for me since i don't have much need for a full mirror but its too buggy :-\
[06:04] <calc> so i'll have to try out apt-mirror after i sleep :)
[06:04] <calc> midnight here now, so about time for bed
[06:08] <dholbach> good morning
[06:10] <TheMuso> Hey dholbach.
[06:10] <dholbach> hi TheMuso
[06:11] <Hobbsee> hey dholbach, TheMuso
[06:11] <TheMuso> Hey Hobbsee.
[06:12] <dholbach> hi Hobbsee
[07:01] <pitti> Good morning
[07:01] <dholbach> hi pitti
[07:01] <pitti> tjaalton: if you set proper build-deps, they will just dep-wait until it is built on ia64
[07:02] <nxvl> pitti: hi!
[07:02]  * pitti hugs dholbach
[07:02] <pitti> hey nxvl
[07:35] <tjaalton> pitti: I noticed that it was built on ia64 after all, so went ahead and uploaded what I had
[07:35] <pitti> ah, finally
[07:35] <pitti> tjaalton: thanks!
[07:35] <tjaalton> and bryce did the rest :)
[07:37]  * bryce waves
[09:35] <tseliot> cjwatson: I've just sent you the email which I should have sent you yesterday. Thanks in advance :-)
[09:36] <kantor> hi, ubuntu uses the ide-scsi driver to load ATAP cd devices as SCSI devices ?
[09:39] <Q-FUNK> what would be the correct package for bug #245500 ?  was reassigned from"jigdo-file" but the real issue is that 8.04.1 jigdo templates point to an older version of a package that is not what ships with hardy+1
[09:40] <tjaalton> who's on archive admin duty today? I know it's not mon/wed/fri, but since alpha2 is about to release..
[09:44] <pitti> tjaalton: Riddell usually
[09:44] <pitti> I did some small bits today and yesterday, but not a lot
[09:44] <cjwatson> tjaalton: http://wiki.ubuntu.com/ArchiveAdministration
[09:44] <cjwatson> Q-FUNK: no package, but it should be on the ubuntu-cdimage project
[09:46] <cjwatson> Q-FUNK: your diagnosis is incorrect though - I'll handle it
[09:46] <tjaalton> cjwatson, pitti: thanks, bookmarked
[09:47] <Q-FUNK> cjwatson: thanks
[09:48] <cjwatson> Q-FUNK: incorrect> because actually the jigdo files *do* point to the version in hardy.1
[09:48] <Q-FUNK> cjwatson: so why does their build fail, I'm wondering?
[09:49] <cjwatson> Q-FUNK: because -updates has moved on from 8.04.1
[09:49] <cjwatson> Q-FUNK: see my explanatory comment in the bug
[09:49] <Q-FUNK> ok
[09:50] <Q-FUNK> does ubuntu ever move packages from release-updates to release, after it's out?
[09:50] <cjwatson> no
[09:50] <cjwatson> if we did, that would solve this problem but create others
[09:50] <Q-FUNK> ok
[09:52] <amitk> where might I find the edgy release? I need to look at a package in there but can't find it at http://archive.ubuntu.com/ubuntu/dists/
[09:56] <persia> amitk: There are images available from http://cdimages.ubuntu.com/releases/6.10/release/
[09:57] <persia> amitk: I don't expect that you'll find archives or updates in any sane place.
[09:58] <pitti> amitk: old-releases.ubuntu.com has both the archive and CD images
[09:58] <pitti> persia: ^
[09:58] <persia> pitti: Thanks!
[09:58] <amitk> pitti: aah great, thanks
[09:58] <cjwatson> don't rely on that cdimage URL - it's a bug that it's still there
[09:59] <pitti> <jedi wave>Edgy is not the release you are looking for</jedi wave>
[10:40] <jscinoz> any plans on backporting the newest openjdk/icetea? i hear it passes the TCK
[10:44] <cjwatson> jscinoz: see the discussion on ubuntu-devel
[10:44] <jscinoz> thanks cjwatson
[10:57] <ogra> apachelogger, could you add hardy tasks before closing all the kdeedu bugs with pointers to kde4 ? we dont ship it in hardy and there is still opportunity to fix them through SRUs ...
[10:57] <ogra> (in kde3.x)
[10:58] <apachelogger> ogra: well, I am done with kdeedu
[10:58] <ogra> hrm
[10:58]  * apachelogger hunts through it again
[10:58] <ogra> thanks :)
[10:59] <ogra> sorry for that, be we ship kdeedu3 in edubuntu so i dont wat to lose them ...
[11:00] <apachelogger> ogra: very reasonable, I didn't think about that, sorry :S
[11:01] <ogra> if we ever meet, remind me to pay you a beer :)
[11:03] <apachelogger> yay :)
[11:15] <jscinoz> blarg icedtea is a huge buil
[11:15] <jscinoz> build*
[11:22] <cjwatson> tjaalton,bryce: xserver-xorg-video-geode still seems to be built against xserver-xorg-video-2, despite the rebuild
[11:22] <cjwatson> looks like it's hardcoded in debian/control
[11:22] <tjaalton> cjwatson: yep, a new version on the way to debian-experimental
[11:22] <tjaalton> and we can sync that
[11:22] <cjwatson> please let me know when it's in and I'll do the sync - it's blocking live CD builds
[11:23] <tjaalton> cjwatson: yep, will do
[11:23] <cjwatson> I don't see it in incoming
[11:24] <cjwatson> but it'll be sufficient to have it uploaded, I don't have to wait for the Debian archive to process it
[11:24] <tjaalton> I could upload a fix if that's faster
[11:25] <cjwatson> it would be faster, certainly
[11:25] <cjwatson> same goes for xserver-xorg-video-imstt
[11:25] <tjaalton> imstt should be removed
[11:25] <tjaalton> like cyrix
[11:25] <cjwatson> oh, that failed to build
[11:25] <tjaalton> they shouldn't block anymore
[11:25] <tjaalton> magictouch too
[11:25] <cjwatson> ah, I was reading the wrong xserver-xorg-video-all control file
[11:26] <tjaalton> bug 246525
[11:26] <cjwatson> blink, what a confusing bug
[11:26] <tjaalton> heh
[11:26] <cjwatson> it should be filed on the individual source packages
[11:26] <tjaalton> I know, but too many..
[11:27] <tjaalton> of those
[11:27] <tjaalton> I'll edit the title
[11:27] <cjwatson> how about xserver-xorg-video-via?
[11:27] <tjaalton> synced
[11:27] <tjaalton> *should be
[11:28] <tjaalton> bug 246454
[11:29] <cjwatson> aha
[11:30] <jcristau> tjaalton: via isn't pciaccessed
[11:30] <tjaalton> jcristau: oh right..
[11:30] <tjaalton> so remove from the archive (yay!), openchrome is used by default anyway
[11:30] <cjwatson> err, I just synced it
[11:30] <tjaalton> hmm, maybe video-all needs adjusting too
[11:31] <tjaalton> hmm :)
[11:31] <cjwatson> shouldn't matter, it's the RHS of an |-dep
[11:31] <jcristau> tjaalton: i changed -all to openchrome | via a while ago
[11:31] <tjaalton> jcristau: yeah, that's covered but I thought that | should matter in this case
[11:31] <cjwatson> it shouldn't
[11:32] <tjaalton> geode uploaded
[11:33] <cjwatson> is xserver-xorg-video-openchrome still needed on lpia? it has an outdated package there
[11:33] <tjaalton> probably not
[11:33] <tjaalton> right, the current version is only built on i386/amd64
[11:34] <pitti> tseliot: related to that ^ discussion, the nvidia-glx-* packages need to be rebuilt against the new X, too
[11:34] <pitti> tseliot: current dist-upgrade wants to remove them
[11:34] <tjaalton> so the lpia version can be deleted
[11:34] <cjwatson> mm, looks intentional
[11:35] <pitti> tseliot: would be nice to test them in the PPA with the new X
[11:35] <tseliot> ﻿pitti: tjaalton has suggested a way not to hardcode the server abi
[11:35] <tjaalton> one caveat with mesa/intel.. compiz doesn't work with it, so it should be blacklisted until the mesa driver is fixed..
[11:35] <tseliot> pitti: as, for example, the intel driver does
[11:35] <pitti> tseliot: hardcode in the source, or in the .debs?
[11:35] <pitti> tseliot: most of the -video packages were mere rebuilds, no source changes
[11:35] <tseliot> pitti: in the source
[11:36] <pitti> right
[11:36] <tjaalton> mvo is on leave?
[11:36] <pitti> tjaalton: GUADEC
[11:36] <tjaalton> pitti: ah right
[11:36] <tseliot> pitti: I have implemented this and all the other changes which you suggested. I'm about to reboot and try them in Intrepid 64bit
[11:37] <pitti> tseliot: yay you rock!
[11:38] <pitti> tseliot, tjaalton: WDYT, should we try to squeeze the new nvidia-glx-* into multiverse for alpha-2? it can hardly get much worse anyway :)
[11:38]  * tseliot reboots
[11:38] <cjwatson> mythtv still build-deps on libchromexvmc(pro)1 - I'll file a bug
[11:38]  * tseliot changes his mind on rebooting
[11:38] <tseliot> ﻿pitti: does it mean that the packages should be ready today?
[11:39] <pitti> tseliot: we won't put them on the CDs, at least not for alpha2, so thursday would actually suffice
[11:39] <pitti> tseliot: I'm not trying to rush you, I'm just asking about what you feel what we should do :)
[11:40] <pitti> since they would make a nice paragraph in the alpha-2 release notes
[11:40] <tjaalton> heh
[11:40] <tjaalton> pitti: I'm ok with it
[11:40] <tseliot> pitti: if so, then it's ok. I'm working full-time on this ;)
[11:40] <pitti>  * Unfuck nvidia users, thanks to Alberto Milone
[11:40] <cjwatson> tjaalton: http://people.ubuntu.com/~ubuntu-archive/NBS/mesa-swx11-source says that vnc4 and xserver-xgl still build-dep on mesa-swx11-source - can you please either file bugs or fix them?
[11:40] <tjaalton> cjwatson: uh, ok. will do
[11:41] <cjwatson> ta
[11:41] <tseliot> pitti: LOL
[11:41] <pitti> well, maybe with some slight editorial changes :-P
[11:42] <tseliot> pitti: unless there's something else which you would like to tell me I'll reboot now
[11:42] <pitti> tseliot: good luck!
[11:42] <cjwatson> tjaalton: I think that's all the X-related archive actions done now
[11:43]  * tseliot finally reboots
[11:43] <tjaalton> cjwatson: yep, should be fine now
[11:49] <mdz> pitti: I see lrm-envy seems to have been uploaded.  my desktop at the office is hungry for an nv->nvidia migration, if you let me know when it's appropriate to test jockey
[11:49] <ogra> tsk ... these GL addicts ...
[11:49] <pitti> mdz: is that hardy or intrepid?
[11:50] <pitti> mdz: jockey doesn't control l-r-m-envy, that's envy-ng in hardy
[11:50] <pitti> mdz: tseliot an I will unify envy-ng and jockey at some point, but it's not there yet in hardy :(
[11:51] <pitti> and in intrepid it's a large construction site ATM; nvidia-glx-* can be tested from PPA (they WFM), but no jockey integration yet
[11:51] <mdz> pitti: intrepid
[11:51] <mdz> pitti: would it be more useful to test what's in the PPA now or wait to test jockey integration?
[11:52] <pitti> mdz: I think testing the drivers now would be very useful -- https://launchpad.net/~lrm-intrepid/+archive
[11:52] <pitti> mdz: once they are in the archive, I'll have a go at modifying the jockey handlers appropriately
[11:52] <mdz> tjaalton: xserver-xorg-video-all and some of its dependencies were removed for me on upgrade to intrepid.  are some of them still waiting to rebuild or something?
[11:52] <mdz> pitti: ok, I'll have a look tomorrow
[11:52] <mdz> ish
[11:53] <pitti> mdz: NB that they don't work with the very latest X.org yet, tseliot is currently testing the new version; should be uploaded today (to the PPA)
[11:53] <pitti> mdz: if you didn't dist-upgrade to all the new drivers and xorg yet, you can use them
[11:53] <tjaalton> mdz: yes, geode is still without the correct abiver
[11:53] <mdz> pitti: I'm at home today anyway, so don't have access to the machine atm
[11:53] <tjaalton> mdz: should be fixed RSN
[11:54] <pitti> mdz: I think for alpha-2 we should have working drivers in the archive, and shortly after that, a fixed jockey
[11:54] <mdz> tjaalton: for me it was -geode, -newport, -via, -imstt and -cyrix
[11:54] <mdz> (none of which I need, so I just let it upgrade anyway)
[11:56] <cjwatson> mdz: we were just dealing with that lot in scrollback
[11:56] <cjwatson> half an hour ago or so
[11:56] <tjaalton> mdz: hmm ok, I haven't tested dist-upgrade yet, but the latest video-all should not depend on cyrix, imstt, newport anymore
[11:57] <tjaalton> so maybe the archive was a bit behind
[11:57] <cjwatson> xserver-xorg-video-newport seems to have source but no binaries in the archive in intrepid, which is odd to say the least
[11:57] <cjwatson> tjaalton: the geode problem confused apt
[11:57] <tjaalton> ok..
[11:57] <pitti> current dist-upgrade just wants to kill -cyrix and -via here
[11:57] <jcristau> cjwatson: newport is Architecture: mips now
[11:57] <cjwatson> aha
[11:57] <cjwatson> ok, that makes sense, I'll just leave it there
[11:57] <cjwatson> removing -cyrix and -via is fine
[11:58] <cjwatson> I've demoted -via to universe to clarify
[12:10] <soren> cjwatson: I think I asked you about this before, but I coulnd't find it in my logs: How would you feel about moving openssh's host key generation into the init script instead of postinst?
[12:11] <soren> cjwatson: If we're building virtual appliances, it would be handy to be able to ship them without keys and just have them generated on first boot.
[12:16] <cjwatson> I'd accept a patch to make it generate host keys mentioned in the configuration file if they don't exist
[12:16] <cjwatson> I'd like to leave the existing configuration in the postinst though
[12:16] <cjwatson> i.e. copy not move
[12:16] <soren> Oh? Why?
[12:16] <cjwatson> reason being that it's all bound up with configuration file generation and that belongs in the postinst
[12:18] <cjwatson> I'm not absolutely sure I can articulate it, I'm just more comfortable with it being in the postinst for most uses
[12:18] <soren> Hmm.. Ok. That seems a bit pointless to me, though. The postinst starts the daemon anyway, so in the process of postinst'ing, they'll be generated anyway.
[12:18] <cjwatson> ok, but I have to maintain this so I'd like it to be something I'm comfortable with :)
[12:18] <soren> *g*
[12:18] <soren> Sure. Ok, I'll copy the code and send you a patch.
[12:19] <cjwatson> oh, one good reason - it wouldn't surprise me in the least if a number of people used entirely custom init scripts rather than the one we ship, e.g. for starting multiple sshds
[12:19] <pitti> soren: not really -- policy-rc.d :)
[12:19] <cjwatson> so I'd prefer the postinst to do all the configuration by default
[12:20] <soren> pitti: I deliberately didn't mention that :)
[12:20] <pitti> I actually use that for chroots
[12:20] <soren> pitti: I use it in ubuntu-vm-builder, too.
[12:20] <soren> ...so it would actualy save me the trouble of having to have the postinst generate the key and then remove it afterwards.
[12:20] <soren> *shrug*
[12:21] <soren> Just another quirk to the pile.
[12:24] <emgent> morning
[12:24] <soren> it's not
[12:33] <soren> cjwatson: http://people.ubuntu.com/~soren/regen_host_keys.diff
[12:33] <soren> cjwatson: Or would you rather have it in a bug report?
[12:33] <soren> cjwatson: I don't know if the postinst changes are silly, though.
[12:34] <soren> I left them out of the init script to not confuse regular users who wouldn't know what a postinst script is, but still would like to fiddle with the init script.
[12:36] <cjwatson> soren: bug report, please
[12:36] <cjwatson> soren: alternative would be to introduce /usr/share/ssh/config-library.sh or something
[12:37]  * mdz reboots another system into intrepid
[12:40] <soren> cjwatson: Yeah, I thought about that. Hm.. Ok, I'll give it a shot.
[12:59] <cjwatson> any objections to xcb-util being promoted to main? new cairo needs libxcb-render-util, and it seems fairly unobjectionable
[13:04] <mdz> that did not go well at all
[13:04] <mdz> gdmgreeter is crashing, xfailsafedialog is crashing
[13:04] <mdz> nautilus and gnome-panel are crashing
[13:04] <mdz> but somehow gnome-terminal and xchat-gnome work
[13:11] <tjaalton> yay, x-x-video-all is now installable
[13:11] <tjaalton> ..again
[13:14] <mdz> tjaalton: do you think my mess is related to the X updates?
[13:14] <tjaalton> mdz: I doubt it, I've been using these for a week now
[13:15] <Mirv> mdz: compiz at least doesn't work with intel with the newest mesa
[13:15] <mdz> tjaalton: (gnome-terminal:8546): Gdk-CRITICAL **: get_monitor: assertion `monitor_num < screen_x11->n_monitors' failed
[13:15] <mdz> looks incriminating
[13:15] <tjaalton> mdz: well, gdm doesn't work here so I can't get that far now, after a reboot :)
[13:16] <mdz> Mirv: running metacity here (which only barely runs)
[13:16] <tjaalton> yes, compiz should blacklist intel for now
[13:16] <mdz> my gdm is broken, but I think for the same reasons as everything else
[13:16] <Mirv> tjaalton: I don't see cyrix, imstt, via hitting the archive yet? synaptic would like to remove -all:s and xorg because of those
[13:17] <tjaalton> Mirv: update..
[13:17] <mdz> gnome-terminal segfaults after the above error; gnome-panel segfaults in panel_multiscreen_width
[13:17] <mdz> both behave as if they aren't getting what they expect from the X client libraries
[13:17] <mdz> gnome-terminal somehow manages to render its initial window, but clicking any menu segfaults it
[13:17] <mdz> likewise for metacity
[13:18] <mdz> this is running with vesa; -intel doesn't even get this far
[13:18] <Mirv> tjaalton: yep, archive.ubuntu.com
[13:18] <cjwatson> Mirv: cyrix and imstt have been removed; via is broken but doesn't block xserver-xorg-video-all so you can let it be removed
[13:18] <cjwatson> Mirv: as of a few minutes ago -all is now fine for me
[13:19] <Mirv> cjwatson: right.
[13:22] <Mirv> looks like the rest is just a synaptic problem when not using smart method but marking the packages manually
[13:22] <mdz> tjaalton: with -intel, my X server crashes in libfb.so
[13:24] <mdz> but there is so much wrong at this point that I'm not sure where the fault is
[13:26] <tjaalton> mdz: yes, seems that intel fails here as well
[13:26] <tjaalton> I'll try the previous kernel
[13:27] <mdz> tjaalton: tried that, didn't help
[13:27] <mdz> I am getting some mtrr errors, don't know if they're related
[13:27] <mdz> [   60.432466] mtrr: no MTRR for e0000000,770000 found
[13:27] <mdz> [   63.459226] mtrr: base(0xe0000000) is not aligned on a size(0x770000) boundary
[13:27] <mdz> this is back on 2.6.24-19
[13:28] <mdz> saw the same on 2.6.26
[13:33] <mdz> tjaalton: what would I need to downgrade in order to try the old -intel?
[13:33] <tjaalton> mdz: quite a lot.. I'll try to rebuild something
[13:35] <nxvl> good morning everyone!
[13:38] <mdz> tjaalton: doesn't build with the intrepid libdrm-dev
[13:40] <tseliot> pitti: shall I make the nvidia driver conflict and replace nvidia-kernel-common now or shall I wait?
[13:40] <tjaalton> mdz: the old intel? no, it needs a fix in configure.ac
[13:40] <mdz> tjaalton: fixed that, it wants xf86mm.h
[13:40] <mdz> which was in the old libdrm-dev but not the new
[13:40] <pitti> tseliot: if you want to use n-k-c for the bits we discussed (config, debconf, modalias lists), and having the current package installed doesn't hurt, just leave it for now
[13:41] <mdz> it builds after downgrading libdrm
[13:42] <mdz> tjaalton: fails in the same way as before though
[13:42] <mdz> segfault in libfb.so
[13:42] <tseliot> pitti: ok. BTW if your Intrepid X crashes, is because of the /etc/init.d/nvidia-glx-<VER>. I'll make sure that it's removed in the postinst, just in case
[13:50] <tjaalton> mdz: looks like EXA is broken
[13:50] <tjaalton> Option "AccelMethod" "XAA" seems to work
[13:51] <tjaalton> VT's are broken though
[13:53] <mdz> tjaalton: confirmed here
[13:53] <tjaalton> I'm not sure anymore, but the xserver I had running before was a vanilla debian one
[13:53] <mdz> let me see if that affects my segfault issues
[13:53] <tjaalton> so a patch of ours broke it
[13:54] <mdz> tjaalton: confirmed, I can login to GNOME with XAA
[13:54] <mdz> tjaalton: so my segfault issues seem somehow related to vesa
[13:55] <mdz> I'll try to confirm that
[13:58] <Mirv> tjaalton: I wonder if it's the greedy patch, which is usually not endorsed/supported by upstream
[13:59] <tjaalton> Mirv: could be..
[14:00] <tjaalton> a rebuild it is
[14:07] <tseliot> pitti: another thing: which section should I set in the control files? multiverse/misc?
[14:10] <mdz> tjaalton: I've confirmed GTK clients segfaulting if I run with the vesa driver, which presumably doesn't use exa, so that seems to be a separate problem
[14:10] <tjaalton> mdz: yeah it's separate.. vesa was updated too (1.3.0 -> 2.0)
[14:11] <mdz> tjaalton: on which package should I file the bug about exa?  -intel or -core?
[14:11] <tjaalton> mdz: core, but I'll rebuild the server to see if commenting out a single patch makes it work again
[14:11] <tjaalton> 15:53 < tjaalton> so a patch of ours broke it
[14:11] <tjaalton> (most likely)
[14:13] <Mirv> vesa 2.0.0 + xserver 1.5 works under virtualbox for me. but I haven't yet tried all these on real hw.
[14:17] <mdz> tjaalton: filed as bug 246581
[14:17] <soren> cjwatson: I'm about to look into creating the infamous server seed, but I'm not sure where it belongs, really. Off the top of my head, I'm guessing just separate file in ubuntu.intrepid?
[14:18] <tjaalton> hm, it's not the greedy patch
[14:19] <cjwatson> soren: for now, it would be best as a separate file in ubuntu.intrepid, yes
[14:19] <cjwatson> soren: though I'd like it and the other *-server seeds to move out to a separate server.intrepid seed collection at some point
[14:20] <soren> cjwatson: Right. The fact that each of {ubuntu,kubuntu,xubuntu,mobile}.intrepid have a server-ship is a bit confusing to me.
[14:20] <persia> "seed collection"?  Is the term "seed pot" now deprecated?  (I'm hoping to hear "yes").
[14:21] <Lrrr> now that's a cool name...
[14:21] <cjwatson> I think the suggestion was "seed pod", actually
[14:21] <soren> That makes more sense :)
[14:21] <persia> Ah.  I misheard then.  "seed pod" makes more sense.
[14:21] <cjwatson> I don't think I've bothered to settle on anything "officially", although I did use the term "collection" in germinate(1) recently
[14:22] <persia> I'm willing to consider the documentation in germinate to be the official source of nomenclature for seed management.
[14:22] <cjwatson> soren: server-ship> I definitely regard that as a bug
[14:22] <cjwatson> but it's easier to fix when we can point to somewhere and say "look, this is the final home"
[14:23] <soren> cjwatson: Indeed.
[14:23] <mdz> Mirv,tjaalton: vesa issue is bug 246585
[14:47] <soren> mount
[14:47] <soren> nice
[14:57] <tjaalton> mdz: the intel bug was not on the server after all. it's the "force greedy exa" patch on intel
[14:59] <mdz> tjaalton: I've updated the bug accordingly
[14:59] <tjaalton> mdz: oh, thanks
[15:11] <emgent> hello there
[15:59] <pitti> tseliot: how did the testin go?
[16:02] <tseliot> pitti: I'm still testing. They seem to work well. I'll bump the release for my PPA but we'll have to remove it for Intrepid, so that it's ubuntu1
[16:03] <pitti> tseliot: let me know when you uploaded, I'll test it here as well
[16:03] <tseliot> pitti: sure
[16:03]  * tseliot logs out to try the new drivers
[16:03] <tjaalton> the first uploaded version can be 0ubuntu2..
[16:04] <tjaalton> no need to change IMHO
[16:04] <tseliot> tjaalton: ok, let me fix the changelog then
[16:05] <tjaalton> tseliot: oh you already did it, nevermind then
[16:05] <tseliot> tjaalton: I haven't uploaded anything yet
[16:06] <geser> pitti: have you an idea why many build logs have a line "sh: gcc: not found" in them?
[16:07] <pitti> ugh, no; infinity, do you? ^
[16:07] <ogra> gcc is overrated ... write more scripts !
[16:08] <cjwatson> it's harmless, whatever it is
[16:08] <pitti> tjaalton: hm, on my laptop I only have -intel installed, and purged all the other drivers; dist-upgrade now wants to install all of them again, and I don't seem to be able to keep just -intel; any idea what's wrong there?
[16:08] <pitti> tjaalton: i. e. is -all strictly depended on now?
[16:08] <ogra> by xorg, no ?
[16:09] <geser> pitti: no, just "force" the upgrade of -intel
[16:09] <tjaalton> pitti: xserver-xorg depends on video-all
[16:09] <ogra> ah, its xserver-xorg ...
[16:09] <pitti> well, I can force it, of course, but ideally it would just work?
[16:10] <cjwatson> xserver-xorg Depends: xserver-xorg-video-all | xserver-xorg-video-2, xserver-xorg-input-all | xserver-xorg-input-2
[16:10] <tjaalton> uh no, it should be enough to have just one driver which provides video-2.9
[16:10] <cjwatson> those need to get bumped for the new ABI version
[16:10] <tjaalton> crap
[16:10] <pitti> ah, it's -2.9 now
[16:10] <tjaalton> hmm no, they are fine here
[16:10] <tjaalton> heh
[16:10] <pitti> tjaalton: so the metapackage's depends: just need fixing, ok
[16:11] <pitti> tjaalton: want a bug for that, or shall I do it myself, or do you want to?
[16:11] <tjaalton> pitti: it's fixed already by the latest version?
[16:11] <geser> pitti: xserver-xorg 1:7.4~0ubuntu1 has the correct one already
[16:12] <cjwatson> geser: the Dpkg::Arch perl module (invoked by dpkg-source) uses gcc, which is where that comes from - no idea why it isn't present though
[16:12] <cjwatson> Package: gcc
[16:12] <cjwatson> Build-Essential: yes
[16:13] <pitti> geser: hm, indeed; apt-get doesn't seem to grok that
[16:13] <cjwatson> err, so it does, I missed that
[16:14] <geser> and the build logs also show that gcc got upgrade so it should be really there
[16:14] <cjwatson> pitti: version of -intel?
[16:14] <cjwatson> geser: in e.g. http://launchpadlibrarian.net/15890222/buildlog_ubuntu-intrepid-i386.cairo_1.6.4-6ubuntu1_FULLYBUILT.txt.gz, gcc-4.3 gets upgraded but gcc doesn't. Note that /usr/bin/gcc is in gcc not gcc-4.3
[16:15] <pitti> cjwatson: 2:2.3.2-2ubuntu1 (available)
[16:15] <pitti> cjwatson: the depends: and provides: really do seem ok, but apt-get doesn't seem to notice that if you upgrade both, the virtual pacakge dependency is still fulfilled, or so
[16:16] <geser> cjwatson: http://launchpadlibrarian.net/15667866/buildlog_ubuntu-intrepid-i386.libgnupg-interface-perl_0.36-1_FAILEDTOBUILD.txt.gz has that line too but there is also "Setting up gcc (4:4.3.1-1ubuntu2) ..."
[16:17] <cjwatson> geser: how confusing. buggered $PATH?
[16:17] <geser> while talking about this build log, does somebody have an idea why gnupg was not found (leading to a FTBFS) while there is output from gpg for the signature check?
[16:17] <cjwatson> (can't see why that would be though)
[16:18] <cjwatson> geser: it might be that dpkg-source is run outside the chroot
[16:18] <cjwatson> or it might be that the configure script is on hopeless crack
[16:19] <geser> cjwatson: that package builds inside a pbuilder without problems
[16:20] <geser> cjwatson: do you know how many chroots are involved during a package build? I assumed it happens all in one chroot
[16:21] <calc> a chroot isn't guaranteed to be the same as a current install of the same dist
[16:21] <calc> you have to make sure your build-depends and build-conflicts are tight enough
[16:21] <thebishop> are official ubuntu releases built from source using APT?
[16:21] <calc> i ran into that problem myself with OOo java build on ppc a few months back
[16:22] <calc> i ended up just disabling java since i didn't know what was wrong with the buildd version of the build
[16:22] <Lrrr> thebishop: You can't really build anything with apt...
[16:22] <thebishop> Lrrr, so is it traditional build scripts then?
[16:23] <calc> thebishop: probably built with sbuild
[16:23] <Lrrr> thebishop: No really it's a bit more complex than that, but it's pretty much built from source every release yeah
[16:23] <thebishop> the reason i ask is i'm interested in working on a PS3 port of Ubuntu Mobile
[16:24] <thebishop> i'm trying to get an idea of how big an undertaking it will be
[16:24] <calc> thebishop: you need dpkg-dev to build stuff generally
[16:24] <Lrrr> thebishop: did you ever build a package, like manually?
[16:25] <thebishop> Lrrr, yeah, i've built kernels on ubuntu.  I used to ./configure/make/makeinstall everything when I ran slackware
[16:25] <Lrrr> thebishop: You should initiate yourself to the intricates of Debian/Ubuntu packaging.
[16:26] <calc> http://www.debian.org/doc/manuals/maint-guide/
[16:26] <Lrrr> thebishop: but that'll give you just part of the answer.  There is a part of the work that will probably means porting some software to the PS3.  I don't really know how hard that part could be.
[16:27] <pitti> BenC: hm, installing v86d changed my boot from "usplash horribly distorted" to "not booting at all any more"
[16:28] <BenC> pitti: hmm...what version of v86d?
[16:28] <pitti> ugh, after dist-upgrade, X doesn't start at all any more (intel GMA945)
[16:28] <tjaalton> pitti: yes..
[16:28] <pitti> BenC: 0.1.5-1ubuntu1
[16:29] <tjaalton> pitti: maybe I should just upload a fix..
[16:29] <tjaalton> and not wait for bryce :)
[16:29] <pitti> tjaalton: seems it tries to use the vesa module
[16:29] <tjaalton> pitti: that's because intel makes the server segfault, so bulletproof-x kicks in
[16:29] <pitti> ah, that would be it
[16:29] <pitti> -vesa doesn't work either, though
[16:29] <tjaalton> right, that's another bug
[16:30] <tjaalton> mdz filed those
[16:30] <pitti> tjaalton: right, I have a backtrace here, do you need it?
[16:30] <tjaalton> pitti: those are already on the respective bugs
[16:30] <pitti> ok, thanks
[16:30] <pitti> tjaalton: if it's known, all is well
[16:30] <BenC> pitti: is uvesafb causing a problem with X?
[16:30] <pitti> BenC: I don't think they are related
[16:31] <BenC> ok
[16:31] <pitti> well, at least X breaks equally well when booting without splash
[16:31] <mdz> pitti: bug 246585
[16:31] <BenC> pitti: what video mode are you passing to the kernel?
[16:31] <mdz> pitti: and bug 246581
[16:31] <mdz> pitti: you're correct that uvesafb is not related, though I noticed that problem as well
[16:32] <mdz> it seems to depend on v86d, which isn't installed
[16:32] <pitti> BenC: dmesg has "uvesafb: Getting VBE info block failed" and "vbe_init() failed with -22", and "probe of usesafb.0 failed with error -22"
[16:32] <mdz> installing it didn't particularly help things, though
[16:32] <pitti> mdz: right, I just tried that, and it seems to make it worse
[16:32] <pitti> mdz: scrambled usplash -> black screen
[16:32] <pitti> BenC: those messages are with v86d installed; without it, I got some "/sbin/v86d not present blabla"
[16:32] <mdz> pitti: I think it did the same for me, but I ended up going back to 2.6.24 anyway
[16:33] <mdz> pitti: I got a black screen where not even magic sysrq worked
[16:33] <pitti> mdz: ctrl+alt+del worked for me
[16:33] <pitti> BenC: video mode> how can I tell?
[16:33] <BenC> pitti: was scrambled usplash a new problem, or is that expected?
[16:33] <BenC> pitti: cat /proc/cmdline
[16:33] <mdz> I wasn't sure whether it was a side effect of the X issues or framebuffer-related
[16:33] <mdz> BenC: scrambled usplash was new for me
[16:33] <pitti> BenC: scrambled> happens with the intrepid kernel, works with hardy kernel
[16:33] <BenC> mdz: when did that start occuring?
[16:33] <mdz> I have notes from upgrading my laptop which I haven't posted yet
[16:33] <mdz> BenC: intrepid
[16:34] <pitti> intrepid + hardy kernel> works, intrepid + -26.3> scrambled
[16:34] <pitti> BenC: you can still see text, but the progress bar jumps around, and text appears at wrong positions, etc.
[16:34] <pitti> i. e. it's not a total noise, but pretty distorted
[16:35] <pitti> BenC: no particular video mode
[16:35] <BenC> pitti, mdz: Do you know what framebuffer is loaded when that happens (vg16fb?)
[16:35] <BenC> *vga16fb
[16:35] <tseliot> pitti,tjaalton,superm1: I have just uploaded the drivers to my PPA. Just FYI. I'll have to adapt nvidia-settings so that it doesn't install the old drivers.
[16:35] <BenC> pitti: and btw, I've also noticed the "Getting VBE info block failed"...seems to be racey
[16:36] <pitti> tseliot: yay!
[16:36] <BenC> pitti: weird, uvesafb shouldn't get loaded unless you have a specific video mode set
[16:36] <mario_limonciell> tseliot, great, i'll take a look sometime today
[16:36] <mario_limonciell> tseliot, does this include the dynamically detecting the ABI version of the provides?
[16:36] <pitti> BenC: I think it happens if you boot with usplash, that sets the native video mode (1280x800)
[16:37] <pitti> BenC: now I booted without splash, and have the standard 80x25 text console
[16:37] <pitti> (well, it *might* be a 640x400 framebuffer, hard to tell)
[16:37] <mdz> BenC: uvesafb I believe
[16:37] <BenC> pitti: cat /proc/fb
[16:37] <pitti> BenC: anyway, when booting without splash, I have "uvesafb" kmod loaded
[16:37] <BenC> pitti: if that doesn't exist, then no fb is loaded
[16:38] <pitti> BenC: exists, empty
[16:38] <mdz> BenC: I'm going to reboot later to test 2.6.26 again now that my X problems are fixed.  what do you want me to try?
[16:38] <cjwatson> usplash should just be using svga rather than *vesafb
[16:38] <tjaalton> fixed intel uploaded
[16:38] <pitti> tjaalton: yay
[16:39] <pitti> tjaalton: "Since compiz is not usable on intel anyway..." ugh, since when?
[16:39] <BenC> mdz: do you also have v86d installed?
[16:40] <mdz> BenC: yes, I installed it when I saw that error
[16:40] <mdz> nothing depends on it
[16:40] <BenC> mdz, pitti: Ok, then I just need to find out why uvesafb is getting loaded for no reason
[16:40] <cjwatson> right, it only got promoted to main very very recently
[16:40] <pitti> BenC: I can try and blacklist it, shall I?
[16:40] <pitti> and then boot with usplash again
[16:41] <BenC> pitti: yeah, don't forget to rerun update-initramfs -u
[16:41] <tjaalton> pitti: since mesa 7.1
[16:41] <pitti> BenC: if it isn't loaded, v86d shouldn't make a difference, should it?
[16:41] <BenC> pitti: right
[16:42] <tjaalton> pitti: there are two bugs that have been for some time
[16:44] <cjwatson> is anyone else seeing occasional little bits of screen corruption in usplash in intrepid?
[16:44] <tjaalton> cjwatson: yep
[16:44] <cjwatson> it's mostly fine, but every so often, usplash decides to draw something a little bit above or below where it should be
[16:44] <cjwatson> roughly two text lines' worth
[16:45] <tjaalton> pitti: so, someone should kick the intel guys to fix those
[16:47] <pitti> cjwatson: I also saw the progress bar jump, yes
[16:48] <pitti> BenC: so, with uvesafb blacklisted, I get a reasonably clean usplash up to some 15%, then it completely freezes
[16:48]  * pitti boots again with usplash and verbose
[16:48] <pitti> BenC: blacklisted and no splash works fine
[16:49] <mdz> tjaalton: what was that 'greedy' patch fixing?
[16:49] <mdz> pitti: I was the progress bar jump as well
[16:49] <mdz> along with some random 1-pixel lines of garbage in a couple of places
[16:49] <Chipzz> soren, cjwatson: wrt openssh key generation: how will that work in upstart?
[16:49] <tjaalton> mdz: the driver uses EXA acceration thingy by default, but it's slow in some operations, so greedy tries to bypass some of that
[16:50] <pitti> BenC: hm, now it booted fine with usplash and the module blacklisted; still screen corruption, but a bit better
[16:50] <Chipzz> does upstart support such complex scenario's?
[16:50] <pitti> all very mysterious, though
[16:50] <tjaalton> mdz: but apparently with xserver 1.5 EXA is better, so the patch might be obsolete anyway
[16:51] <pitti> BenC: well, plenty of stuff to try next week :)
[16:52] <cjwatson> Chipzz: upstart supports bits of shell that you run before the daemon starts. I don't see how it would be a problem in the slightest
[16:55] <tseliot> mario_limonciell: would you mind if I removed the Recommends and the Conflicts from nvidia-settings?
[16:55] <pitti> tjaalton: yay, new -intel works, thanks!
[16:55] <mario_limonciell> tseliot, what are they currently right now?
[16:55] <pitti> http://launchpadlibrarian.net/15891896/xserver-xorg-video-intel_2.3.2-2ubuntu2_i386.deb if someone wants to test it before it gets published
[16:56] <tseliot> mario_limonciell: Recommends: nvidia-glx (>= 1:96.43.05+2.6.24.9-8.22) |  nvidia-glx-new (>= 169.09+2.6.24.9-8.22) | nvidia-glx-legacy (>= 71.86.04+2.6.24.9-8.22)
[16:56] <tseliot> same for Conflicts
[16:56] <mario_limonciell> tseliot, yeah i say remove them
[16:56] <Chipzz> cjwatson: ah ok I mistakenly thought it was less advanced
[16:56] <tseliot> mario_limonciell: ok.
[16:56] <mario_limonciell> tseliot, you might consider making nvidia-settings recommends for all the different driver packages though
[16:58] <tseliot> ﻿mario_limonciell: I would like something like Jockey or EnvyNG to deal with hardware detection
[16:58] <tseliot> mario_limonciell: and install the right driver
[16:58] <tjaalton> pitti: as designed ;)
[16:58] <mario_limonciell> tseliot, yeah it will
[16:58] <mario_limonciell> but i'm saying nvidia-settings should be a recommends for each of those driver's packages
[16:58] <mario_limonciell> so that when you install the driver, you get nvidia-settings too
[16:59] <BenC> pitti, mdz: If the screen corruption occurs without v86d installed (or uvesafb loaded), then we may have a vga16fb problem...I'll check into it (I noticed it too, but thought it was local to me)
[16:59] <tseliot> mario_limonciell: ah, ok. I agree then
[17:00] <mario_limonciell> tseliot, i recently committed something to fglrx so similar happens with the amdcccle
[17:00] <pitti> BenC: yes, I purged v86d and blacklisted uvesafb; the machine boots now (no black screen and hang), just with some corruptions
[17:00] <pitti> BenC: it's of course entirely possible that it is a bug in usplash, but it looks ok on the hardy kernel; might be a coincidence, of course
[17:00] <tseliot> ﻿mario_limonciell: great, let's be consistent then ;)
[17:01] <cjwatson> BenC: the screen corruption happens to me both with and without v86d installed
[17:01] <pitti> so the only remaining problem now is broken suspend
[17:01] <cjwatson> BenC: however, I just read through the hardy->intrepid diff to usplash, and there seem to be no relevant changes
[17:05] <BenC> cjwatson: ok, thanks
[17:12] <slangasek> _MMA_: if vorbis-tools cares about file extensions, then it probably makes sense to open a task for it on bug #201291, yes
[17:17] <slangasek> superm1: mythbuntu alt disks published as 8.04.1 now, cheers
[17:24] <_MMA_> slangasek: Sorry. I dug into this further with the guys @ #vorbis and even though they made these new extensions they have no plans to push them and still recommend using .ogg because of breakage downstream.
[17:35] <_MMA_> slangasek: This is with vorbis-tools/oggenc that is.
[17:40] <ogra> hmm, why cant i find any code for using hardy-updates in livecd-rootfs ?
[17:41]  * ogra would have expected it to use updates ...
[17:43] <cjwatson> ogra: it does, it's there
[17:43] <cjwatson> search for 'updates' in livecd.sh, second hit
[17:43] <ogra> hmm, grep updates gains me nothing in the hardy package
[17:44] <cjwatson> ogra: oh, it's only in intrepid
[17:44] <cjwatson> just pull from bzr
[17:44] <ogra> right ...
[17:45] <ogra> (we should sru the package with the patch though)
[17:45] <ogra> so people building their own CDs dont end up with the wrong ssh client :)
[17:46] <cjwatson> ogra: that would make sense
[18:03] <slangasek> _MMA_: er, that directly contradicts the information in the xiph.org wiki page pointed to in that bug...
[18:04] <_MMA_> slangasek: Ill PM you.
[18:04] <slangasek> i.e., they may not currently be recommending that the default extensions be changed when generating, but there's MIME standardization being pushed here, which means that applications that /read/ oggs need to know the new extensions, for sure
[18:05] <_MMA_> Yes.
[18:05] <_MMA_> Awareness of the MIMEs but thats it.
[18:05] <_MMA_> Which seems silly to me but oh well.
[18:06] <slangasek> well, presumably we could make a change down the line to the choice of extensions at creation time, once it's been widely adopted
[18:06] <slangasek> soren: is bug #187048 something that can be fixed in intrepid for alpha 2?  (the milestone pitti originally set for it)
[18:07] <pitti> slangasek: those were all hardy SRUs, so I'd think so
[18:07] <pitti> those just mean "get it uploaded to intrepid NOW", since technically it was already violating SRU rules
[18:08] <slangasek> pitti: right, and this is my pre-alpha2 nag for milestoned bugs :)
[18:13]  * cjwatson gets going on a version of debian-policy for Ubuntu
[18:17] <liw> cjwatson, yay
[18:17] <bryce> tjaalton, mdz, I've pushed up an -intel with that greedy patch disabled
[18:18] <bryce> sorry, we should have caught that earlier yesterday, we knew -intel's behavior with greedy was going to change with the new xserver
[18:20] <geser> did somebody also seen in intrepid that a key is repeated like you would hold it down? it happens here sometimes when the system is under load
[18:21] <ogra> sounds kernelish
[18:22] <geser> might by true as I started seeing this after upgrading to intrepid kernel
[18:25] <slangasek> geser: I've heard of that bug, yes, but I'm afraid I can't be any more specific than that
[18:26] <kirkland> slangasek: hey, i'm off the phone with dendrobates now
[18:27] <kirkland> slangasek: dendrobates feels strongly that AuthClientConfig is the proper place to solve this problem for our purposes, pam_ecryptfs.so munging into the pam stack
[18:27] <kirkland> slangasek: I'm curious about your proposed solution
[18:27] <kirkland> slangasek: do you have anything in writing yet about how you'd like to tackle it?
[18:27] <cjwatson> geser: bug 218516? however, the patch that fixed that seems to be in the intrepid kernel
[18:28] <cjwatson> geser: (probably best not to reuse that bug)
[18:28] <dendrobates> kirkland slangasek: to be clear, I just want the logic in that package, not to solve the problem with templates
[18:29] <slangasek> kirkland: yes; let me push it into a wiki page
[18:29] <slangasek> dendrobates: eh, once the PAM stuff is done, the auth-client-config package should be obsolete
[18:29] <slangasek> because it needs to be done in the pam package itself
[18:30] <kirkland> slangasek: is that for Debian Policy reasons?
[18:30] <slangasek> kirkland: it's because it should be part of the core of how the pam packages work, there's no reason for it to be a separately-maintained package at that point
[18:31] <mdz> bryce: I thought tjaalton already had
[18:31] <geser> cjwatson: thanks, that's seems to be the problem I also see
[18:31] <slangasek> kirkland: auth-client-config might still be useful on an upgrade basis for those who already have it installed, but that's all it should be doing in the New World Order
[18:31] <bryce> mdz, yup he did
[18:32] <cjwatson> geser: perhaps best to file a new bug and refer to it rather than piggy-backing on it; it's potentially quite a general problem so may be unrelated
[18:32] <slangasek> kirkland, dendrobates: oh, correction; I guess auth-client-config would still be relevant for the NSS bits, which are so far down the line I shy away from thinking about it :/
[18:33] <dendrobates> slangasek: the long term plan is to allow pam/nss configuration from a template stored in ldap.
[18:33] <kirkland> slangasek: how much time/effort is there in implementing your suggested pam-config scheme?
[18:36] <slangasek> dendrobates: um, well, the Debian packages are going to implement this using debconf; if you can use the debconf ldap backend, then great, but otherwise ldap isn't going to be a good fit for what actually needs to be done in any case
[18:36] <slangasek> kirkland: depends on how fast you code, perhaps? :)
[18:38] <kirkland> slangasek: i'm trying to put the ecryptfs-related development behind me so that I can focus on a couple of other things dendrobates has me assigned to for intrepid (booting degraded raid, iscsi on installation)
[18:38] <slangasek> dendrobates: wanting to pre-configure everything via LDAP is only one of a variety of use cases that should be supported.  Single-user desktops also have need for a configuration framework for PAM, and that implies debconf.
[18:38] <kirkland> slangasek: the two biggies i have left for ecryptfs-private-dirs are (1) the main inclusions for 4 packages, and (2) the pam config
[18:38] <slangasek> kirkland: right, give me two shakes to finish dumping my notes to the wiki
[18:38] <kirkland> slangasek: sure, no problem
[18:41] <tseliot> pitti,mario_limonciell: I have uploaded the new nvidia-settings and the nvidia drivers so that they recommend nvidia-settings
[18:53] <slangasek> kirkland: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[18:54] <kirkland> slangasek: reading....
[18:55] <slangasek> kirkland: as a spec, it's currently terrible, but I think most of the core design is there
[18:56] <slangasek> saivann: heh, 220631 bumped to alpha-3 without even trying to get it fixed? :)
[18:57] <saivann> slangasek : Was it a bad move? You said that we would not have enough time for alpha 1 (that was before I realised that this bug might not exist anymore in intrepid :) )
[18:58] <saivann> s/alpha 1/alpha 2/
[18:58] <slangasek> saivann: oh, I didn't say that we wouldn't have time, I only said that /if/ there's not time it should be re-targeted
[18:59] <slangasek> but it's fix-released now, so ok :)
[18:59] <saivann> slangasek : Oh, my fault, I didn't read the "*if* that's not feasible", sorry
[19:01] <alex_dinamo> guys... hello to all
[19:01] <alex_dinamo> I've got a problem
[19:01] <alex_dinamo> I am in a urge to get subversion 1.5 running
[19:01] <alex_dinamo> when tryng to compile, it can't find libneon.la
[19:01] <thom> alex_dinamo: way, way offtopic for this channel, sorry
[19:01] <alex_dinamo> seems like neon is not compiled with libtool support, something like that
[19:01] <ion_> We have a problem, too. To prevent it, we’ve set the topic.
[19:02] <alex_dinamo> bump
[19:02] <alex_dinamo> yes
[19:02] <alex_dinamo> sorry
[19:02] <alex_dinamo> where can I ask?
[19:02] <saivann> Is there a developer who knows usplash a bit that can help me fixing bug 55159 and bug 139363
[19:02] <thom> alex_dinamo: please see the topic
[19:03] <ion_> alex_dinamo: #ubuntu or https://answers.launchpad.net/ubuntu/+addquestion
[19:04] <_MMA_> saivann: I can get you in touch with someone who knows the ins and outs of its themeing (they might know something) but I have no clue who actually *works* on usplash anymore.
[19:05] <saivann> _MMA_ : Thanks, if possible, if you can show him/her the bug reports, it would greatly helps me
[19:17] <slangasek> kirkland: page updated, I dug up my draft of the config file format & preliminary stack examples
[19:18] <kirkland> slangasek: cool, i was going to ask for examples of your syntax
[19:19] <slangasek> the draft config file format still needs refined, as you'll see from the notes; there are a couple of points where I think I've got a bit of redundancy
[19:19] <slangasek> hmm, apparently I need to do some wiki formatting though
[19:21] <slangasek> fixed
[19:25] <kirkland> slangasek: you thinking python?  perl?  shell?  C? for the implementation?
[19:27] <ogra> R
[19:27] <ogra> to add something new :)
[19:27] <slangasek> kirkland: I would like python, but that poses implementation problems for Debian since libpam-runtime is transitively essential and python is not part of base
[19:28] <slangasek> kirkland: so realistically, one of perl or C
[19:30] <kirkland> slangasek: Well fwiw, I'm about 2x faster programmer in perl than python.  Considering the string parsing involved, I think perl would be kinder than C.
[19:30] <slangasek> kirkland: that's ok with me. :)
[19:30] <kirkland> slangasek: I'd like, though, to get some input from dendrobates and jdstrand before starting down this route
[19:31]  * slangasek nods
[19:31] <kirkland> slangasek: dendrobates is pretty strongly behind enhancing auth-client-config to have it do what we want, rather than writing something from scratch
[19:32] <jdstrand> kirkland: what input do you need/want?
[19:50] <MtJB> will ubuntu issue a patch for the DNS design flaw today?
[19:51] <laga> what DNS design flaw?
[19:53] <mouz> laga: http://lists.debian.org/debian-security-announce/2008/msg00184.html
[19:54] <MtJB> multi vendor patches coming today from bind, ms, sun, cisco, and other
[20:09] <jdstrand> MtJB: it's being worked on
[20:09] <pitti> BenC: hm, any idea why /dev/rtc doesn't exist any more? (vmware complains); I have a /dev/rtc0 now, but it has a radically different major/minor
[20:12] <BenC> pitti: we aren't using the legacy rtc subsystem anymore
[20:27] <BenC> pitti: with 2.6.26, you can't enable the legacy and standard rtc interfaces at the same time anymore
[20:27] <pitti> BenC: ah, thanks; so itz vmware bug
[20:29] <thebishop> is there a monolithic source tree for the various flavors of Ubuntu?  For instance, is there one place where I can check out all the source for the packages in xubuntu or ubuntu mobile?
[20:31] <LaserJock> thebishop: no
[20:32] <Lrrr> sadly no
[20:32] <Lrrr> thebishop: apt has the source packages
[20:32] <Lrrr> thebishop: check the apt-get source command
[20:33] <thebishop> is that how Ubuntu is able to produce usable builds daily?
[20:33] <LaserJock> thebishop: we don't rebuild from source package daily
[20:33] <Lrrr> thebishop: No that's quite a bit more complex than that.  Still, the sources are  there.
[20:34] <LaserJock> thebishop: there are scripts/programs that build the CD from the existing binary packages
[20:34] <LaserJock> thebishop: generally what you want to read up on is germinate (and seeds ) and debiancd
[20:35] <thebishop> LaserJock, I see.  So only a few packages are built daily
[20:35] <LaserJock> thebishop: whenever a new version is uploaded it is built
[20:35] <thebishop> the reason i ask (Lrrr knows) is that I'd like to port Ubuntu Mobile to the Playstation3
[20:36] <LaserJock> and it's not rebuilt (generally) until a new version is uploaded
[20:36] <LaserJock> thebishop: yeah, saw that from a few hours ago :-)
[20:36] <LaserJock> thebishop: so basically you want to get a list of the packages involved, and build the source packages on PS3
[20:37] <thebishop> LaserJock, I assume Ubuntu also has a ton of its own scripts and config files to make everything more cohesive
[20:37] <ScottK> Note that for Hardy, Ubuntu Mobile is not 100% built from the official Ubuntu mirrors.  They have an additional one of their own.  I don't know where it is.
[20:37] <thebishop> not to mention art assets
[20:38] <slangasek> they have a ppa, but I wouldn't be able to tell you the name of it offhand
[20:38] <thebishop> ScottK, what about Intrepid?  May as well start working on the latest version
[20:39] <ScottK> It is my understanding that they intend to work out of the official repos.  I don't know if they have transitioned yet.
[20:39] <LaserJock> thebishop: everything is in source packages, you just got to find them :-)
[20:39] <thebishop> heh
[20:39] <LaserJock> thebishop: have you looked at the Ubuntu PS3 isos?
[20:41] <LaserJock> seems like it wouldn't be too far to go from there to Ubuntu Mobile PS3 port
[20:42] <thebishop> I don't know, isn't Ubuntu Mobile designed to be fast and light?
[20:43] <LaserJock> thebishop: well, it uses a different package selection, but the basics would be similar I'd think
[20:46] <LaserJock> thebishop: the Intrepid mobile seed is at https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mobile.intrepid I believe
[20:46] <LaserJock> thebishop: that should help you get a list of packages
[20:48] <Mirv> tjaalton/bryce: definitely some progress now with intel performance with xserver 1.5 EXA (without greedy). not completely great yet, but hopefully the greedy patch can now be left disabled.
[20:48] <bryce> Mirv: yeah
[21:14] <Mirv> the compiz broken on intel 965 with mesa 7.1 is https://bugs.freedesktop.org/show_bug.cgi?id=14441 - there's a one-line fix but I guess intel should do it in a proper way
[21:17] <Keybuk> black screen?
[21:17] <Keybuk> I get a white screen!
[21:17] <Mirv> Keybuk: white screen is usually that LIBGL_ALWAYS_INDIRECT is not set, see the last two comments
[21:17] <Mirv> after setting it you get a black screen :)
[21:19] <tjaalton> I get a corrupt screen
[21:19] <tjaalton> but the same bug most likely
[21:26] <YokoZar> What is Ubuntu "Complete Edition" ? http://www.bestbuy.com/site/olspage.jsp?a=8888563&type=product&tab=1&id=1211587312374#productdetail
[21:26] <Mirv> tjaalton: oh yes, as mentioned in the bug report, it at least used to be corrupt screen without TTM (like intrepid now), or black screen with TTM. I guess it hasn't changed.
[21:27] <tjaalton> Mirv: yep, the desktop and windows mostly black, decorations corrupt
[21:30] <Mirv> if it really looks like intel is not doing anything about it soon, one may consider having the one line patched in the intel driver
[21:30] <tjaalton> yep..
[21:34] <Mirv> YokoZar: hopefully something being agreed between this "valusoft" and canonical, since it's on sale on best buy...
[21:35] <YokoZar> Mirv: branding Ubuntu trademarks, no less
[21:37] <Mirv> looks like they also have "office suite 2007", but at least they dont use openoffice.org name
[21:43] <bryce> Mirv: I've emailed Intel support about those two issues this morning to try to raise visibility on these regressions
[21:43] <bryce> Mirv: hopefully we'll see some progress made on them soon
[21:43] <Mirv> bryce: oh great, hopefully so
[21:44] <bryce> I worry the answer's going to be something like, "You need GEM to make it work"
[21:44] <bryce> ;-)
[21:45] <Mirv> yep, gallium + gem + dri2 + xserver 1.6 ;)
[21:46] <Mirv> but Eric indicated in the bug report that the code in mesa should be simply disabled or fixed, so I'd guess the compiz fix is very much doable for mesa 7.1
[21:46] <bryce> hope so
[21:46] <Mirv> Michel, that is, not Eric
[21:46] <kirkland> doko: hi, are you around?
[21:47] <kirkland> doko: i have a bug/patch for lsb.  you sponsored my last one, though you might review/sponsor this one too.
[21:49] <ogra> Keybuk, would you have time for a question ?
[21:53] <cjwatson> YokoZar: could you please mail trademarks@ubuntu.com about that?
[21:55] <cjwatson> it's not clear to me that it falls within the trademark policy
[21:59] <YokoZar> cjwatson: done
[22:00] <Mirv> cjwatson: usage of Ubuntu logo, name etc. in any commercial way. "Restricted use that requires a trademark license" ... "Any commercial use" (http://www.ubuntu.com/aboutus/trademarkpolicy)
[22:00] <YokoZar> cjwatson: "Complete Edition" to me sounds like a box that would have multiple dvds with every package (universe included), sorta like Debian's 14-discs series
[22:01] <_MMA_> Take a peak. Looks like 1 disk.
[22:01] <_MMA_> http://princessleia.com/journal/?p=1262
[22:01] <Mirv> YokoZar: thanks
[22:02] <geser> there is also a Ubuntu Satanic Edition? http://ubuntusatanic.org/news/
[22:03] <_MMA_> geser: Old joke. Parody. ;)
[22:03] <Mirv> they do state they are "Official Re-Distributor" and that Canonical recognizes them as such, so maybe they've a deal. http://princessleia.com/images/ubuntu/box_back.jpg
[22:05] <kirkland> slangasek: hey, question for you, regarding soft freeze
[22:08] <kirkland> slangasek: regarding https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000446.html, I have a non-disruptive, minor change to lsb that's gating a stack of other patches.  I'm curious if it's a candid for upload during soft freeze, or if not, when the archive will open again for upload?
[22:09] <soren> slangasek: re bug 187048> I checked that off my list long, long ago. It's not in intrepid?
[22:09] <slangasek> kirkland: the archive will open again on Thursday; if the lsb change isn't going to break installabilities and is holding up progress elsewhere, go ahead
[22:09] <slangasek> soren: according to the bug state, it's not
[22:10] <soren> That's a fair point. :)
[22:10] <kirkland> slangasek: it's not.  though I'll need a sponsor, as I don't have upload privs.
[22:29] <calc> I switched over to approx 3.3.0 to see how it works, apt-proxy is too incomplete to be useful
[22:29] <calc> it doesn't support more than one distribution (eg dapper/intrepid)
[22:30] <calc> apparently the issues i had with approx may be fixed now
[22:31] <ogra> apt-proxy is ingenious for image building ...
[22:31] <ogra> but beyond that pretty useless
[22:33] <slayton> has anybody here used xdg-desktop-menu install before? I've got some weird errors... the Name=<value> is being ignored in my .directory files...
[22:34] <slayton> oops wrong channel
[22:38] <doko> kirkland: please file a report and patch and subscribe me
[22:39] <kirkland> doko: thanks, it's https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735
[22:39] <kirkland> doko: i think kees was going to sponsor it, but i haven't seen it yet
[22:40] <kees> kirkland: sorry, got caught up in bind9 update paperwork
[22:40] <TheMuso> slangasek: Ubuntustudio is still nowhere near an alpha, due to still unresolved kernel issues.
[22:41] <slangasek> TheMuso: ok. is anyone actively working on those?
[22:41] <kirkland> kees: yeah, i bet that's consuming you, sorry for this nagging, then
[22:41] <TheMuso> slangasek: I belive our kernel guy is, but haven't heard any status on this as yet.
[22:44] <kantor> hi, how makes ubuntu to use ATA and ATAPI (hdx) devices as SCSI devices (sgx, scdx) ?
[22:45] <cjwatson> Mirv: er, yeah, I think you read my sentence the wrong way round
[22:46] <cjwatson> Mirv: my sentence meant "it seems likely to me that it doesn't fall within the trademark policy"
[22:46] <cjwatson> Mirv: I'm surprised that Canonical would have approved something called "Ubuntu Complete Edition", thereby implying that normal Ubuntu is incomplete
[22:46] <cjwatson> I'll ask around
[22:49] <cjwatson> ah, well, Fabian's comment on princessleia's blog would be authoritative on that I suppose
[22:50] <Keybuk> ogra: what's up?
[22:51] <ogra> Keybuk, hey ... i'm working with ion_ on the compcache spec ...
[22:51] <ogra> https://wiki.ubuntu.com/Compcache
[22:51] <ogra> if you look at the code snippet in there, there is a modprobe followed by a swapon
[22:52] <ogra> the loading of the compcache module is slow though ... which means the swapon will catch a race
[22:53] <ion_> ogra: My patch is about ready, i’ll post it in a bit.
[22:53] <ion_> It’s using udev.
[22:53] <ogra> Keybuk, all the core stuff will be added to initramfs-tools for compcache ... to avoid the race ion_ proposed a udev script like http://revu.ubuntuwire.com/revu1-incoming/compcache-0807071820/compcache-0ubuntu1/debian/compcache.udev
[22:53] <ogra> Keybuk, my simple question is where to put something like that in the initramfs-tools source :)
[22:54] <ogra> we dont have any rules scripts there yet ...
[22:54] <ion_> My patch handles that as well. :-P
[22:54] <ion_> Kind of
[22:54] <ion_> I’ll see whether you approve.
[22:54] <Keybuk> in the debian/ directory ?
[22:54] <ogra> ah, k i didnt know that yet :)
[22:55] <infinity> ogra: Should land in /etc/udev, like any other udev rule...
[22:55] <ogra> infinity, in the package source ?
[22:55] <ogra> (of initramfs-tools)
[22:56] <ogra> well, lest wait for ion_, i dont know his solution yet :)
[22:56] <Keybuk> wherever seems sane
[22:56] <Keybuk> I'd argue you should put it in the compcache source package
[22:56] <kees> kirkland, doko, slangasek: lsb 3.2-12ubuntu2 has been uploaded
[22:56] <infinity> Yeah...
[22:56] <ogra> i dont want a compcache source package
[22:57] <ogra> its a core feature like framebuffer or thremal
[22:57] <Keybuk> otherwise how do you disable it?
[22:57] <ogra> initramfs.conf
[22:57] <kirkland> kees: much thanks!
[22:57] <ogra> its disabled by default
[22:57] <Keybuk> thermal shouldn't be loaded by the initramfs
[22:57] <ogra> (see the spec =
[22:57] <ogra> :)
[22:58] <ogra> well, you know what i mean
[22:58] <kees> kirkland: no problemo :)
[22:58] <infinity> Keybuk: thermal probably shouldn't, but it is, because we had nowhere else to put it.
[22:58] <ogra> its a kernel module and gets the config from initramfs.conf
[22:58] <Keybuk> infinity: udev loads it
[22:58] <ion_> ogra, keybuk: heh.fi/tmp/initramfs-tools-compcache.diff
[22:58] <infinity> Keybuk: And PowerMacs explode if you don't load fans early and often.
[22:58] <Keybuk> (it didn't at the time we put it in there, but it does now)
[22:58] <kirkland> kees: would you mind pinging me when bind9 is done?  I'll hold off on posting the init script patch until you've updated Intrepid
[22:58] <ion_> Whoops, http://heh.fi/tmp/initramfs-tools-compcache.diff
[22:58] <infinity> Keybuk: Yeah, well.  Point's still valid, even if the implementation has since gone away. :)
[22:59] <kees> kirkland: well, it's mostly done now.  still issues with glibc that need to be sorted, but not by me yet.
[22:59] <ogra> ion_, eeek, i thought we had agree on standadizing for percent only
[22:59] <ion_> Uh, i thought we didn’t. :-) Me wants 50 %.
[23:00] <ion_> The overhead of the percentage code is neglibigle, and any of it doesn’t go to the initramfs if a percentage isn’t used.
[23:00] <ogra> i just dont like the massive amount of options
[23:01] <ion_> 50 %, 65536 k, 256 M, 1 G. Is the number of suffix choices really that massive?
[23:01] <ogra> also its missing the change from my patch to auto_add_modules ...
[23:02] <Keybuk> isn't it K ?
[23:02] <ion_> force_load does that.
[23:02] <ion_> keybuk: Nope. If we’d use kibits, it’d be Ki.
[23:02] <ogra> hmm
[23:02] <Keybuk> ion_: everywhere else in Ubuntu uses KB
[23:02] <Keybuk>           RX bytes:2960 (2.8 KB)  TX bytes:2960 (2.8 KB)
[23:02] <infinity> Keybuk: I surely hope not.
[23:02] <infinity> Ick.
[23:02] <ion_> Kelvinbytes :-)
[23:02] <Keybuk> so you should match
[23:03] <infinity> Keybuk: There's no such SI prefix.
[23:03] <Keybuk> infinity: bytes aren't SI units
[23:03] <infinity> Keybuk: Matching incorrect prefixes isn't sane.  Where else is "everywhere"?
[23:03] <Keybuk> nor are bits
[23:03] <Keybuk> and you can't argue for them to be SI units either, because a tenth of a byte is meaningless
[23:03] <ogra> Keybuk, infinity optioions on the amount of options ?
[23:03] <Keybuk> and SI units must, by definition, be equally divisible as they are multiplicable
[23:03] <ogra> i'm not really happy with so many
[23:03] <infinity> ogra: The number of options are fine.
[23:04]  * ogra would have gone with MB only or alterantively with %
[23:04] <ogra> its not that it will be used by standard users or so
[23:04] <infinity> Keybuk: You can argue until you're blue in the face, but the units are "kB and KiB", we can argue what they MEAN, but there is no "KB" documented anywhere that I know of.
[23:05] <ion_> infinity: It would be worse: in Finland, operating systems and computer magazines have switched to using t instead of B, because byte happens to be tavu in Finnish.
[23:05] <Keybuk> infinity: it's certainly documented in the Oreilly style guide ;)
[23:06] <ion_> It’s as if nobody learned in school that you don’t translate units, period. :-)
[23:06] <Keybuk> and KB is used everywhere else in Ubuntu
[23:06] <ogra> ion_, can you drop the export  ?
[23:06] <ogra> . "${CONFDIR}/initramfs.conf" in mkinitramfs conf should take care
[23:07] <Keybuk> and has been the conventional way people on the street have written it for years
[23:07] <ion_> ogra: Will do.
[23:07] <infinity> Keybuk: Does "KB" in the output of ifconfig mean "1000 Bytes" (kB) or "1024 Bytes" (KiB)?
[23:08] <Keybuk> infinity: 1024 bytes
[23:08] <Keybuk> as its meant to everyone since the dawn of time, before other people decided to be silly
[23:08] <infinity> Keybuk: I'd argue that if it means "1000", it should be a lower-case k, and if it means 1024, then fine, KB == KiB works for me.
[23:08] <wgrant> Oh dear, this debate is going nowhere good (though I side with infinity)
[23:09] <lamont> and this is what happens when marketing and pedants get near specificiations
[23:09] <ogra> heh
[23:09] <calc> just send all of the people who like si bytes to siberia ;)
[23:10] <Keybuk> I have scientists on my side ;)  a byte cannot be an SI unit
[23:10]  * calc wishes the installer used real units instead of the si crap
[23:10] <Keybuk> no matter how hard the strange people wish
[23:10] <calc> i end up partitioning my system with fdisk and bc
[23:10] <lamont> calc: and while we're at it, lets put an upper limit of 70MB on a package source. :-p
[23:10] <Keybuk> calc: it should use real units, we deliberately patch software in Ubuntu to eradicate KiB where we find them
[23:10] <calc> lamont: heh :)
[23:10] <calc> lamont: even the diff.gz is bigger than 70MB ;-)
[23:10] <lamont> I know
[23:11] <Keybuk> (though partitioners have their own strange problems, since disk manufactures use multiples of 1000 blocks of 1024 bytes
[23:11] <Keybuk>  or is it the other way around?)
[23:11] <lamont> if your diff.gz is bigger that 50MB, it's time to bump the version and make a new orig.tar.gz :)
[23:11]  * ogra dances ... finally got the cmpc image back under 800M
[23:11] <calc> Keybuk: fdisk was good until the author decided to switch it to 1000 bytes
[23:11]  * LaserJock yells "SI FTW!!" and runs to hide behind a laser
[23:11] <Keybuk> lamont: isn't that forking?
[23:11] <Keybuk> calc: fdisk is correct
[23:11] <lamont> Keybuk: diff.gz is forking
[23:12] <Keybuk> disk manufactures really do use 1000 bytes as their base
[23:12] <Keybuk> but then usually use powers of two to multiply that
[23:12] <calc> yes but filesystems really use 1024 bytes
[23:12] <ion_> ogra etc: http://heh.fi/tmp/initramfs-tools-compcache.diff
[23:12] <lamont> Keybuk: that's marketing getting involved... it's all SI base now
[23:12] <ogra> ion_, i'm not sure i actually like the approach of using modprobe.d here vs using a normal initramfs script
[23:12] <wgrant> And disk manufacturers don't do it for innocent reasons.
[23:12] <calc> in particular 4096 byte blocks, etc
[23:12] <calc> bc
[23:12] <calc> oops
[23:12]  * Keybuk wants a 4 mb disk
[23:13] <ion_> ogra: I can change that. I just thought force_load and modprobe.d would be the right thing to do.
[23:13] <ogra> ion_, ond that it looks good to me ...
[23:13] <ogra> *beyond
[23:13] <ion_> Anyone else have comments about that?
[23:13] <Keybuk> and a 23 nB USB key
[23:13] <calc> i assume that means nautilus is supposed to show disk sizes by SI bytes then as well
[23:13] <infinity> ion_: If it works, I honestly don't care how it's done.
[23:13] <calc> since it claims my 32GB partition is 34.4GB
[23:14] <ion_> keybuk: At least we have gb disks now since they introduced the VWBS technology.
[23:14] <Keybuk> calc: nautilus uses 1024 multiples, iirc
[23:14] <infinity> ion_: The current implementation that write files out during mkinitramfs is a bit unreadable, mind you...
[23:14] <calc> Keybuk: it doesn't appear to here
[23:14] <calc> 33551721 blocks for ntfs shows up as 34.4GB in nautilus
[23:14] <infinity> ion_: On the flip side, it's unreadably located in one script, instead of being readably located across 3 or 4 files, so I guess it's a tossup.
[23:14] <ogra> ion_, well, i like the approach, dont get me wrong, its just unconventional and totally different from anything we do in intramfs-.tools
[23:14]  * lamont cries a little at 1:9.5.0-P1.dfsg-0build1 <= 1:9.5.0.dfsg-4
[23:14] <Keybuk> (it'd be a neat project for someone to sanify all our usage of byte multiples -- as long as they don't use wankibytes)
[23:15] <ion_> infinity: Originally i had the computation of the kilobytes in a script that goes into the initramfs, but ogra prefered that no extra computation or lines go to the initramfs, for instance parsin /proc/meminfo when using a percentage.
[23:15] <calc> (33551721*1024)/2^30 = 31.997 GB
[23:15] <infinity> lamont: s/-P1/.P1/
[23:15] <lamont> yeah
[23:15] <infinity> lamont: Dashes in upstream version numbers are vile anyway.
[23:15] <ion_> keybuk: gb, VWBS: http://johan.kiviniemi.name/blag/2005/12/31/gb/ :-)
[23:15] <ogra> ion_, right because the module dtrt and uses 25% if you dont supply a value
[23:15] <lamont> upstream did it, not me.
[23:15] <lkj> hello
[23:15] <infinity> lamont: Yeah, I know. :)
[23:16] <Keybuk> ion_: what's "gb" ?
[23:16] <calc> it doesn't bother me too much that they renamed GB to GiB, etc but it should be displayed in computer units instead of braindead SI/HD Manufacturer units
[23:16] <ion_> keybuk: Please see the page :-)
[23:16] <calc> since filesystems don't use those screwed up units
[23:16] <calc> and ram doesn't etc
[23:17] <calc> so if you want to be certain you have enough swap to suspend you have to convert from real 8GB to SI 8GiB which shows up as 8.6 GB now
[23:17] <Keybuk> ion_: wouldn't that be bits-per-gram?
[23:17] <calc> big freaking mess all due to some greedy marketing people
[23:17] <lamont> Keybuk: gb is where you live
[23:17] <Keybuk> if you wanted a new unit, you can't just smash two units together and hope
[23:18] <Keybuk> calc: I've never seen anyone use KiB
[23:18] <Keybuk> or GiB
[23:18] <Keybuk> especially not marketing people
[23:18] <Keybuk> the only time I ever see it is when people with IRC adenoids start sticking their oar in and whinging
[23:19] <cjwatson> partitioner> it uses disk marketing units because otherwise people complain that it doesn't match the advertised size of their disk. The topic is closed; I have no interest in debating it back and forward until the end of time, sorry.
[23:19] <ion_> So, which ones shall i do? 0) Make the hook clearer by putting the kilobyte calculation to a separate script that is installed VS. let them stay in the hook, making it a bit unclear. 1) Use force_load and modprobe.d VS. do modprobe $parameters directly in a script.
[23:19] <Keybuk> cjwatson: but it doesn't use "GiB" ?
[23:19] <lamont> Keybuk: 4.7GB on a dvd...
[23:19] <cjwatson> Keybuk: er, no, it uses disk marketing units, i.e. 1000 not 1024
[23:19] <Keybuk> cjwatson: right, that's exactly what I understood
[23:20] <norsetto> state the size in binary and let them convert it to whatever units they like
[23:20] <Keybuk> which, in a partioner, is entirely correct
[23:20] <lamont> norsetto: grandma won't like you
[23:20] <norsetto> lamont: should I say what I think of grandma?
[23:21] <lamont> she is the ubuntu user base
[23:21] <norsetto> lamont: I love her :-)
[23:21] <ion_> ogra? infinity?
[23:22] <ion_> ogra: Oh! Sourcing /e/i/initramfs.conf isn’t enough. We forgot /e/i/conf.d and /u/s/i/conf.d
[23:22] <ion_> ogra: Should i source the files in them as well, or just export the variable in mkinitramfs?
[23:22] <ogra> no
[23:22] <ogra> thats all done already
[23:23] <ogra> nothing you need to take care of
[23:24] <ion_> ogra: Wait... mkinitramfs sources everything, but with the latest change, it doesn’t export the variable, i do . /etc/initramfs-tools/initramfs.conf as you suggested. But that fails to read the files in /etc/initramfs-tools/conf.d etc, in which COMPCACHE_SIZE may be overridden.
[23:25] <ogra> err
[23:25] <ogra> i didnt suggest you to add that line
[23:25] <ogra> its already in mkinitramfs :)
[23:25] <ion_> Ah, i misread. Sorry.
[23:25] <ogra> nothing to do with that on your side
[23:26] <calc> Keybuk: which makes the partitioner useless
[23:27] <calc> Keybuk: since it is important in several cases that your partition match whatever you want to call real *B's
[23:27] <calc> for the past 4-5 years (whenever he got on crack) I have had to use bc and cylinders to partition systems
[23:27] <calc> perhaps a good solution for users would be to suggest the GB size to make their swap to actually match their ram size for suspend
[23:28] <calc> since they don't match if you use marketing crap for partitioner
[23:28] <cjwatson> no, it does not make the partitioner useless
[23:28] <infinity> ion_: Remove the source from your hook script, and add an export to mkinitramfs.
[23:28] <cjwatson> I think you'll find that plenty of people manage to use the partitioner quite successfully
[23:28] <calc> also some fs like fat32 change cluster size based on GB boundaries
[23:28] <Keybuk> calc: isn't that exactly what the partioner already does?
[23:28] <calc> cjwatson: oh it works as in it creates a partition of course
[23:28] <cjwatson> the partitioner already suggests sensible swap sizes based on RAM size, yes
[23:28] <infinity> ion_: Well, export it if you need it during mkinitramfs.
[23:29] <calc> Keybuk: it does? i don't recall seeing it tell me that, maybe i was installing in a mode that didn't show it
[23:29] <infinity> ion_: If you need it on boot, it needs to end up in a conf file.
[23:29] <cjwatson> if you're doing autopartitioning
[23:29] <infinity> ion_: (See, for instance, the line with: echo "DPKG_ARCH=${DPKG_ARCH}" > ${DESTDIR}/conf/arch.conf")
[23:29] <cjwatson> and seriously, it does not matter if your swap partition size differs by a factor of 1.024
[23:29] <cjwatson> there are more important things to worry about
[23:30] <cjwatson> the autopartitioner suggests bigger than RAM anyway ...
[23:30]  * calc got called in to finish cooking dinner
[23:30] <cjwatson> that said, it would make sense to have a warning if swap is smaller than RAM, and I'd appreciate a bug on partman-basicfilesystems for that
[23:30] <Chipzz> 00:06 < ion_> It's as if nobody learned in school that you don't translate units, period. :-)
[23:30] <Chipzz> ion_: tell THAT to the French :P
[23:30] <cjwatson> (sorry, I didn't see "suspend" in calc's comment at first)
[23:30] <Chipzz> damn "octets" :P
[23:31] <ion_> chipzz: Well, o is at least a standard.
[23:31] <Chipzz> ion_: it is? outside of France, I mean :P
[23:32] <ion_> Hm, at least i was under such an assumption.
[23:32] <ion_> I may be wrong.
[23:33] <cjwatson> one option would be to set up ubiquity such that hovering over the partition would pop up a tooltip with exact size
[23:33] <Chipzz> I wonder how "octet" can be a standard when the concept of byte was invented by an English speaker :P
[23:34] <Chipzz> anyway, offtopc :P
[23:38]  * lamont finds it amusing that engineers of back-when said KB, knowing full well that there was a 2.4% error, and just not caring.  If you want precision, then you're kind of stuck with the actual SI units...
[23:39] <Keybuk> lamont: except that a byte cannot possibly be an SI unit
[23:39] <Keybuk> if you want precision, you can simply type out, in full, what you mean
[23:39] <lamont> except that the same computer engineers co-oped si for their new "unit"
[23:39] <Keybuk> since if you're rounding by a factor of one million, or even a thousand million, you really really aren't getting any kind of precision anyway
[23:40] <Keybuk> lamont: what use is a nanobyte?
[23:40] <Keybuk> or a millibit?
[23:40] <lamont> Keybuk: exactly.  if you use the SI unit prefixes, then you mean 10^3.
[23:40] <Keybuk> why not just write that, if that's what you mean?
[23:40]  * lamont has heard of networks with millibits per second of throughput
[23:40] <Keybuk> if you have exactly that number of bytes
[23:41] <infinity> lamont: Yours?
[23:41] <lamont> Keybuk: right.
[23:41] <lamont> infinity: meh
[23:41] <lamont> no.  someone implemented IP-over-bongo-drums.
[23:41] <lamont> 140second ping time
[23:41] <Keybuk> if you have 8 x 10^3 + 47 bytes, you're not being precise anyway
[23:41] <Keybuk> so who cares?
[23:42] <lamont> Keybuk: remember that engineers come from a world where the models they use are off by 10% or more
[23:42] <lamont> Keybuk:  marketing
[23:42] <Keybuk> marketing don't use wankibytes
[23:42] <lamont> and so they reduced the error when it became 4.9 and 10% to being .1%
[23:42] <Keybuk> (not that I've ever seen, anyway)
[23:42] <lamont> marketing uses KB and they mean 10^3
[23:42] <lamont> everyone means 10^3
[23:43] <lamont> then there are the pedants who _think_ they mean 2^19
[23:43] <lamont> 2^10 even
[23:43] <calc> cjwatson: its not a factor of 1.024 its a factor of 7.3% for GB
[23:43] <Keybuk> disk marketing use 10^3
[23:43] <Keybuk> RAM still use 2^10
[23:43] <calc> will be a factor of 10% for TB
[23:43] <Keybuk> calc: ?! it's a constant factor
[23:43] <lamont> calc: and that's why marketing decided that they wanted to advertise the extra space, and that the error was becoming significant enough to care
[23:43] <Keybuk> calc: it's always a constant factor of 1000:1024
[23:43] <cjwatson> Keybuk: no, he's right
[23:43] <calc> 1 TB hard drives are 1,000,000,000 Bytes
[23:43] <Keybuk> he is?
[23:43] <cjwatson> Keybuk: 1024*1024*1024 vs. 1000*1000*1000
[23:44] <lamont> Keybuk: yes
[23:44] <calc> they round off decimal all the way
[23:44] <ogra> ion_, let me sleep a night over the modprobe.d thing ... beyond that i'm fie with the patch
[23:44] <Keybuk> oh, of course
[23:44] <Keybuk> it's nearly 2am here
[23:44] <ogra> *fine
[23:44] <calc> it will continue to increase the difference as sizes go up
[23:44] <calc> so for PB whenever they come around it will be 13% difference
[23:44] <cjwatson> I'm still not going to change the unit expression in the partitioner. Sorry. People will complain either way round. I'm willing to make improvements to make it clearer what's going on.
[23:44] <lamont> Keybuk: and the most amusing part is that those of us who say GB when the pedants would say we need to use GiB, really just don't care about being off by 10%
[23:45] <cjwatson> and just noticed that there's no way to force it to enter an exact number of bytes at the moment, so can fix that one
[23:45] <pwnguin> well, as long as dd doesnt use anything but bytes, i think we'll live
[23:45] <lamont> cjwatson: clearer == better, I think
[23:45] <lamont> and yeah, there are much bigger fish to fry
[23:45] <infinity> cjwatson: Just change it to measure everything in UU (uber units) with a footnote explaining what that is, and why it's superior to kB, KB, and KiB combined.
[23:46] <lamont> infinity: reminds me of SWU.
[23:46] <Keybuk> lamont: my theory goes that as soon as you round to a GB, you no longer care about lost KB
[23:46] <lamont> Keybuk: exactly
[23:46] <Keybuk> the only thing I care about is that what our user interface states matches what the user sees on the box
[23:46] <Keybuk> thus disk sizes should be reported in KB, MB and GB which are multiples of 1,000
[23:46] <Keybuk> and RAM sizes reported in KB, MB and GB which are multiples of 1,024
[23:46] <Chipzz> 00:27 < calc> perhaps a good solution for users would be to suggest the GB size to make their swap to actually match their ram size for suspend >> if you try to match those exactly, I think you've already lost anyway, since a swap partition includes a signature
[23:47] <cjwatson> Chipzz: it would make sense for there to be a check though
[23:47] <cjwatson> with appropriate fudges for such details
[23:50] <lamont> Keybuk: my RAM size is reported by bios units of 10^b
[23:51] <emgent> hello
[23:51] <lamont> see also maretroids
[23:51] <Chipzz> cjwatson: check as in checkbox?
[23:51] <Keybuk> lamont: but it is bought in boxes with units of power-of-two bytes
[23:51] <Keybuk> you still buy a 2GB RAM stick, and it means 2*1024*1024*1024 bytes
[23:52] <Chipzz> cjwatson: the issue gets more hairy with filesystems, where the overhead is not of a fixed size
[23:52] <lamont> Keybuk: and then you boot he computer, and it tells you some other number of bytes
[23:52] <Chipzz> and to add up to that, you need to specify the size of the partition before you specify the type
[23:52] <lamont> and you wonder where the extra 100MB of space came from
[23:53] <cjwatson> Chipzz: hi, I'm grandma, perhaps you'd like to teach me to suck eggs ;)
[23:53] <Keybuk> lamont: I don't see this as our problem
[23:53] <Chipzz> I don't think my grandma cares :)
[23:53] <cjwatson> Chipzz: a check as in a check, confirmation, if statement to confirm that swap is big enough to suspend into. I don't care about the tedious details for this purpose
[23:54] <Chipzz> in fact, we tried to explain on her on numerous occasions how to program a VCR, even written it down for her, and she still fails to do it :P
[23:54] <cjwatson> Chipzz: "teach grandma to suck eggs" => "explain in tedious detail to somebody who already knows"
[23:54] <lamont> Keybuk: eventually, someone in marketing will win an argument, and some memory maker will start selling 4.2GB sticks
[23:54] <Chipzz> cjwatson: ah yes :)
[23:55]  * calc would be appeased if he could tell it somehow the exact size he wanted in bytes or GiB or whatever, GB is not exact when sectors are not in x^10 power
[23:55] <lamont> I predict it'll hit when it's 128GB vs 131GB, if not sooner
[23:55] <calc> or change sectors to be 10^3, 1000 byte per sector would work fine
[23:55] <Chipzz> anyway, my opinion on the matter is we should use 2^n, and the hard disc manufacturers can go **** themselves ;)
[23:55] <calc> don't need pages anymore :)
[23:56] <calc> lamont: maybe, but eventually it will stop unless someone releases a new decimal based cpu
[23:57] <Chipzz> actually I think some hard disc manufacturers already got sued over using 1000 instead of 1024
[23:57] <lamont> calc: decimal-based-cpu?  just use COBOL
[23:59] <calc> lamont: well yea since pages, etc are binary sized