[00:00] <joaopinto> Riddell, you mean java and any other packages requiring a prompt ?
[00:01] <persia> andre, For assistance, you probably want #ubuntu (or #ubuntu-${country code}).  Aside from that, you really don't want to make that change, because all the files on your system are UTF-8, and you will encounter problems.
[00:02] <andre> persia, with kubuntu i hadnt any bigger problems...
[00:02] <Riddell> joaopinto: java is the only package which doesn't install without debconf that I know of
[00:02] <Riddell> that's the biggest problem for users
[00:03] <joaopinto> ok
[00:03] <Riddell> joaopinto: do you know of other problems?
[00:04] <joaopinto> well, no, but pitti mentioned this morning that those problems prevented it from getting adopted for Ubuntu (gnome)
[00:04] <joaopinto> so it's a bit strange that it will work for Kubuntu
[00:07] <Riddell> the other problems that come to mind are issues with signature authentication, we have problems syncing the repositories to the list of packages shown
[00:07] <Riddell> and other packages use debconf and aren't ideally installed without it, mysql won't have a password set for example
[00:08] <joaopinto> doesn't that bring support complixity increase ? e.g. we will need task if mysql was installed from ubuntu or kubuntu ;)
[00:09] <Riddell> joaopinto: yes a wee bit, although most mysql admins should know how to set the root password anyway, but it's an issue
[00:10] <joaopinto> well, I am looking a it from a general perspective, packages installs with different results based on the WM
[00:10] <Riddell> WM!=desktop
[00:11] <joaopinto> well, name it flavor, whatever :)
[00:11] <persia> Also, desktop or flavour selection doesn't map perfectly to package manager.  While it's not default, there's no reason a user can't use a PackageKit solution in GNOME/XFCE or a non-PackageKit solution in KDE.
[00:12] <Riddell> right, but for documentation you can assume the defaults get used
[00:12] <joaopinto> I am not familiar with Kubuntu, doesn't it present a default Add/Remove menu item ?
[00:13] <persia> Riddell, support != documentation, but for documentation, I completely agree.
[00:13] <joaopinto> persia, documentation is a type of support IMHO
[00:14] <persia> joaopinto, Perhaps a component, but I'm quibbling, rather than objecting.
[00:14] <Riddell> joaopinto: yes, kpackagekit in jaunty
[00:15] <Riddell> we're not arguing :)
[00:16] <joaopinto> ok, I just hope it will work ok :)
[00:17] <joaopinto> now I feel Kubuntu is ubuntu+2 :P
[00:35] <TheMuso> wii dtchen
[00:35] <TheMuso> dtchen: so what do we do with those power save bugs?
[00:36] <TheMuso> How can be attempt to prevent popping etc?
[00:50] <slangasek> pitti: you patched epiphany-extensions to build an epiphany-extensions-2.24.pot; is this still what we want it to be called, now that we're on to 2.26?  (apparently the auto-selection of the name based on ABI version was failing)
[00:57] <nixternal> who is leading this whole Apt URL discussion? I am interested in getting in on it if possible. is it being documented somewhere?
[00:58] <slangasek> pitti: it looks like the original bug is fixed, so I guess it's just a question of whether it's ok to have the name changed within rosetta
[01:30] <dtchen> TheMuso: we add the missing HDA_AMP_MUTE/AC_VERB_SET_AMP_GAIN_MUTE calls
[01:30] <TheMuso> ah ok.
[01:31] <TheMuso> dtchen: what if there is not already a quirk for that piece of hardware?
[01:32] <dtchen> TheMuso: more code to write ;)
[01:32] <TheMuso> yay
[03:01] <cjwatson> oho, I just figured out what the problem was with unionfs-fuse on the karmic live CDs
[03:01] <cjwatson> and it's a one-liner in initramfs-tools
[03:03]  * stgraber needs to look at unionfs-fuse for LTSP ...
[03:03] <cjwatson> though it's still painfully slow
[03:04] <cjwatson> it went faster than this in my tests on jaunty :-/
[03:05] <StevenK> cjwatson: Awful early, isn't it?
[03:06] <cjwatson> insomnia
[03:06] <StevenK> Ugh :-(
[03:06] <cjwatson> anyway, mostly up 'cos that problem was bugging me, so I'll go back to bed now
[03:06] <StevenK> cjwatson: I'm about to accept -8 into karmic, shall I fix the platform seeds too?
[03:07] <cjwatson> anyone who wants to figure out why it's stultifyingly slow is welcome
[03:07] <cjwatson> StevenK: not unless you're also going to change d-i
[03:07] <StevenK> cjwatson: I can do that too, but I've not done it before
[03:07] <cjwatson> either (a) leave seeds and d-i alone and don't NBS-remove -6 which is what they're currently using or (b) change both seeds and d-i
[03:08] <StevenK> I'll do (a), and wait for your all clear
[03:08] <cjwatson> either's fine, if you do (a) then I'll do the changes in sync tomorrow
[03:08] <cjwatson> actually
[03:08] <cjwatson> right now (a) is best, because util-linux-udeb is broken in a way that hoses d-i builds
[03:08] <StevenK> Oh, fun
[03:09] <cjwatson> lamont: did that patch look ok?
[03:10]  * cjwatson &
[03:10] <billisnice> The update today seemed to fix the printer Samba?
[03:18] <prefrontal> i need the latest gcc that is available in karmic and i'm a pretty experienced ubuntu user/packager
[03:18] <prefrontal> is it safe to `update-manager -d' from jaunty to koala?
[03:18] <prefrontal> i assume some of you guys are running it?
[03:19] <geofft> If you just want gcc, you can add karmic to your sources.list and use apt preferences to pin everything else to jaunty
[03:19] <prefrontal> i don't think its going to work. there is a bug.
[03:19] <Hobbsee> i'm running it
[03:19] <Hobbsee> it runs
[03:19] <Hobbsee> it might explode tomorrow, but seems stable today
[03:19] <prefrontal> i built the new gcc from source and it can't find GLIBCXX_3.4.11
[03:20] <prefrontal> Hobbsee could you run this for me: strings /usr/lib/libstdc++.so.6 | grep GLIBC
[03:20] <prefrontal> i'm looking for 3.4.11
[03:21] <Hobbsee> sarah@pluto:~% strings /usr/lib/libstdc++.so.6 | grep GLIBC | grep 3.4.11
[03:21] <Hobbsee> GLIBCXX_3.4.11
[03:21] <prefrontal> ok i'm updating:)
[03:21] <prefrontal> Hobbsee, tx
[03:21] <Hobbsee> prefrontal: depending on what you want to do, a chroot may be helpful
[03:21] <Hobbsee> if you don't wnat to fully upgrade
[03:21] <Hobbsee> and you're welcome
[03:22] <prefrontal> i also want to include a package in the next ubuntu so it makes sense for me to upgrade to karmic now
[03:22] <Hobbsee> ahh
[03:22]  * StevenK has two Karmic chroots for that
[03:22] <prefrontal> StevenK, do you have a guide you follow for that?
[03:22] <Hobbsee> !chroot
[03:23] <Hobbsee> StevenK: I find i find, and fix more bugs if i'm actually running it
[03:23] <StevenK> prefrontal: https://wiki.ubuntu.com/PbuilderHowto
[03:23] <StevenK> Hobbsee: Sure, because then they annoy you.
[03:23] <Hobbsee> precisely
[03:24] <StevenK> My netbook will getting Karmic thrust on it for alpha-2
[03:24]  * ajmitch_ tends to upgrade piecemeal
[03:24] <prefrontal> pbuilder is going to help me make a standards compliant package?
[03:24] <prefrontal> or i still need to go through the manual and do it all by hand?
[03:25] <ajmitch_> pbuilder just helps with building the binary packages
[03:27] <prefrontal> have you guys ever tried downgrading? if i hate karmic, can i go back to jaunty? seems like it would work
[03:27] <StevenK> Downgrading is not supported
[03:27] <lamont> cjwatson: meh. didn't look at the util-linux thing - did you need it tonight?
[03:28] <lifeless> prefrontal: the dpkg package manager doesn't reliably downgrade, as such we don't support downgrading
[03:28] <StevenK> lamont: Are you going to stop hppa building karmic packages? :-)
[03:28] <lamont> StevenK: no.  infinity is
[03:28] <StevenK> Well, someone is, which is good.
[03:29] <lamont> don't let the fact that something doesn't have hppa bits keep you from promoting it/etc
[03:29] <prefrontal> well i think i borked my jaunty system by installing the latest gcc from source. jaunty does not provide GLIBCXX_3.4.11 and gcc does not have an uninstall target
[03:29] <lamont> FTBFS on HPPA is now officially "so?"
[03:29] <lamont> prefrontal: mucking about with toolchain is best done in a chroot, not in the real root
[03:29] <slangasek> lifeless: s/the dpkg package manager/the package maintainer scripts/, really
[03:29] <StevenK> Oh, I've been ignoring FTBFS on hppa for ... oh, three releases?
[03:29] <lamont> StevenK: ^5
[03:29] <ajmitch_> installing from source on top of packaged software tends to end in tears
[03:29]  * StevenK grins at lamont
[03:30] <lamont> slangasek: yeah - the fact that package maintainers don't care so much about downgrading working doesn't mean that the package manager doesn't - just that it's largely untested and therefore "fraught with peril"
[03:30] <lifeless> slangasek: sadly precision doesn't help answering all questions.
[03:31] <lamont> cjwatson: happen to have the patches/pastebin links handy?
[03:31] <lamont> otherwise I'll deal with it in the morning
[03:31] <lamont> lifeless: I think he was more meaning "it's not apt/dpkg's fault that it's b0rked"
[03:31] <StevenK> Hmm. I wonder if duplicated files are a REJECT reason
[03:32] <lamont> ajmitch_: I think you mean s/tends to/nearly always/
[03:32] <lamont> StevenK: nope.
[03:32] <prefrontal> has anyone scripted all these DebootstrapChroot steps?
[03:32] <lamont> that's just an install time failure
[03:32] <lamont> prefrontal: beyond just running debootstrap?
[03:32] <StevenK> Meh, I'll accept it and then file a bug
[03:32] <lifeless> lamont: except that dpkg is not designed to support downgrades.
[03:33] <lamont> lifeless: bullcrap
[03:33] <lifeless> lamont: old version maintainer scripts by defintion don't have enough data
[03:33] <lamont> dpkg fully supports downgrades.
[03:33] <lamont> that's why it runs the new version too
[03:33] <lamont> s/too//
[03:33] <lamont> well, depending on what you hosed between versions, of course.
[03:33] <lifeless> lamont: I thought it ran the current version on pre, then the unpacked version on post
[03:33] <lamont> hence the "fraught with peril"
[03:34] <lamont> I haven't read the docs recently
[03:34] <lifeless> lamont: Last time I dug into this its theoretically possible to dtrt in maintainer scripts but actually very hard, especially given arbitrary version intervals
[03:34] <slangasek> lifeless: which means that the maintainer scripts from the new version of the package need to detect there's a downgrade happening, and roll things back
[03:34] <lamont> but yeah, there are some interesting situations where the downrev scripts aren't quite smart enough to deal with the downgrade
[03:35] <slangasek> which is not unsupported by dpkg, it's just uninteresting and so almost no maintainer scripts do it
[03:35] <lamont> lifeless: what he said
[03:35] <slangasek> (I've written some that do, but then I'm crazy)
[03:35]  * StevenK kicks Launchpad
[03:35] <StevenK> "branding-ubuntu" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
[03:35] <lamont> slangasek: and we all appreciate your largely never-tested-in-real-life support for downgrading
[03:35] <StevenK> Sure it does, I just accepted it!
[03:35] <lifeless> so, ack to all of that. And I know (you note I'm not arguing :)). But it doesn't make a good answer to prefrontal :)
[03:35] <prefrontal> ok, i want to do a karmic chroot but first i need to fix my borked jaunty. all i did is compile gcc from source via ./configure && make && make install
[03:36] <StevenK> Argh!
[03:36] <prefrontal> problem is, how do i now get rid of the damn thing
[03:36] <lamont> prefrontal: and therein lies great pain and suffering
[03:36] <lamont> so once you've recovered from that, debootstrap karmic karmic karmic :-)
[03:36] <prefrontal> which upgrading to karmic will fix...
[03:36] <lamont> or even debootstrap --variant=buildd karmic karmic
[03:36] <StevenK> prefrontal: If you're lucky, it's all over /usr/local
[03:37] <prefrontal> it is all over /usr/local. gcc is kind of huge though
[03:37] <lifeless> rm -rf /usr/local?
[03:37] <lamont> that might be the simplest solution
[03:37] <prefrontal> oh it looks like i don't have the nfs /usr/local..thank god too
[03:38] <ajmitch_> possibly a bit of overkill there, but the alternative would be going through & cleaning up /usr/local{lib,bin} at the very least
[03:38] <prefrontal> that means i can rsync --delete my buddies /usr/local
[03:38] <lifeless> I wonder if autoconf should be taught to check for debian/redhat etc systems and refuse to run without a 'doing a package build' env variable ;)
[03:38] <lifeless> ajmitch_: include, share, man
[03:38] <StevenK> Eek
[03:39] <ajmitch_> lifeless: depends on how much those bits of /usr/local would affect a packaged gcc, I guess, but it's a mess anyway :)
[03:39] <lifeless> StevenK: consider that INSTALL for most upstreams says 'do X Y Z' which are precisely the instructions to wedge a binary package maintained system
[03:39] <prefrontal> i can't believe gcc doesn't have an uninstall target. it uses autoconf
[03:39] <lamont> cjwatson: you still awake?
[03:39] <lamont> is the udeb thing just for ubuntu, or for debian too?
[03:39] <lifeless> lamont: fairly sure its debian too, for d-i
[03:40] <lamont> yeah - except for the part where there isn't a util-linux-udeb package
[03:42] <lamont> except for the part where ubuntu _does_ have util-linux-udeb
[03:43] <lifeless> yes, rmadison ftw
[03:43] <lifeless> EOF for my knowledge here
[03:43] <prefrontal> it worked..phew sudo rsync -av --delete me@eon:/usr/local/ /usr/local/
[03:43] <prefrontal> bye bye gcc
[03:44] <lifeless> another thing you could have done
[03:44] <lifeless> find /usr/local -age {or whatever the flag is}
[03:44] <prefrontal> ahh
[03:46] <lamont> cjwatson: merged, and yeah - will upload in the morning unless y'all scream and make keybuk do it sooner
[03:47] <lamont> Keybuk: pushed, if that helps any
[03:47] <lamont> lifeless:  ! -mtime +1
[03:47] <lamont> or ! -newer timestampfile
[03:47] <lifeless> lamont: yeah, I always have to look it up
[03:48] <lamont> clearly, you don't use find enough
[03:48] <lifeless> I find I use it precisely often enough ;)
[03:48] <lamont> find is love
[03:49] <lifeless> but not sex
[03:49] <lamont> no.  it's _NOTHING_ like sex
[03:49] <lamont> sex is better.  much better.
[03:51] <prefrontal> find is a PITA
[03:51] <prefrontal> '{}' \;
[03:52] <lamont> prefrontal: never use that
[03:52] <StevenK> No, I agree with lamont, find is love. It's just love from the 1970's, and hasn't discovered -- yet
[03:52] <lamont> use -print0 | xargs -0 :-)
[03:52] <lamont> -- is for lusers
[03:55] <lamont> on that note, time for this one to go to sleep
[03:56] <prefrontal> thanks for help lamont
[03:57] <prefrontal> (and others! StevenK etc.)
[04:01] <prefrontal> how many hours will it take me to package our software for karmic? its using cmake but i don't think the `make deb' target from cpack is going to help me
[04:02] <prefrontal> and do you guys script the whole process, or do it by hand every time?
[04:03] <lifeless> prefrontal: #ubuntu-motu may give better answers
[04:03] <lifeless> prefrontal: there is lots of tutorials on packaging software
[04:09] <prefrontal> i'm just surprised that the process is so manual because ubuntu has an impressively wide array of software already packaged
[04:10] <prefrontal> seems like a higher level tool could encapsulate this
[04:10] <lifeless> its nearly entirely automated in the general case
[06:37] <dholbach> good morning
[06:44] <pitti> Good morning
[06:45] <ajmitch_> morning dholbach, pitti
[06:46] <pitti> kees: thank you! Merged into trunk
[06:48] <pitti> slangasek: I guess it needs to be epiphany-extensions-2.26.pot then, but configure.ac should define the domain
[06:48] <pitti> hey ajmitch_
[07:12] <dholbach> hello everybody
[07:12] <dholbach> I just tried calling mvo, to no avail... I hope he's OK still
[07:13] <dholbach> shall we make this an impromptu Q&A session about Ubuntu Development and Packaging instead?
[07:13] <dholbach> who's here for the session?
[07:13] <ara> dholbach: wrong channel
[07:13] <dholbach> narf
[07:13] <dholbach> wrong channel
[07:13] <dholbach> ara: thanks... not enough coffee :)
[07:14] <prefrontal> how do i get my debootstrapped karmic to use both cores?
[09:36] <cjwatson> lamont: thanks, the morning should be time enough
[09:40] <robert_ancell> directhex: hey, pitti said you know about MOM - do you know why gnome-control-center doesn't show in it?  Is it because the debian source has a different name?
[09:40] <StevenK> If the debian source package has a different name then MoM will probably ignore it
[09:42] <pitti> robert_ancell: directhex is the Mono maintainer
[09:42] <pitti> robert_ancell: MoM specialist is Keybuk
[09:43] <pitti> robert_ancell: right, Debian's source is called control-center
[09:43] <pitti> robert_ancell: if we merge, we should rename our source as well
[09:43] <robert_ancell> pitti: ah, I have my IRC threads mixed up, I thought you were replying about MOM
[09:43] <pitti> so that in the future it is covered by MoM
[09:43] <robert_ancell> pitti: what are the implications of changing source name?
[09:44] <StevenK> It has to go through NEW again
[09:44] <pitti> robert_ancell: not much, it will just be stuck in NEW
[09:44] <pitti> robert_ancell: but we'll just wave it through
[09:44] <pitti> robert_ancell: binary package renamings are more painful
[09:44] <pitti> but source basically doesn't matter
[09:45] <robert_ancell> so practically I just change the debian/ file, and request and update on Launchpad?
[09:45] <pitti> robert_ancell: update on launchpad?
[09:45] <pitti> robert_ancell: oh, indeed; it means that bug reports should be moved from g-c-c to c-c, too
[09:45] <robert_ancell> s/and/an/
[09:52] <Keybuk>   $ time (udevadm trigger; udevadm settle)
[09:52] <Keybuk>   real  0m0.558s
[09:52] <Keybuk> wheee
[09:52] <Keybuk> (of which 0.2s is just running path_id)
[09:58] <Keybuk> pitti: I like the fact that the vcs-imports send mails for commits imported
[09:58] <pitti> Keybuk: I guess you can subscribe to them just as any other branch?
[09:58] <pitti> Keybuk: with that udev-extras import it's now so much easier to update the ubuntu package \o/
[09:58] <Keybuk> pitti: right, I think I'm subscribed by default for asking for it
[09:59] <Keybuk> indeed
[10:12] <StevenK> Hmmm. Do I have to get a motu-sru ACK before an SRU is accepted?
[10:14] <seb128> pitti: no no no, we renamed control-center to gnome-control-center for a reason, we are not renaming it back that creates a mess for all bugs, vcs, etc
[10:15] <pitti> seb128: *shrug* okay
[10:15] <seb128> thanks ;-)
[10:19] <maxb> What was the reason, ooi?
[10:22] <seb128> maxb: is that a question about g-c-c?
[10:22] <maxb> yes
[10:22] <seb128> having the same naming than the upstream product
[10:22] <ogra> we could rename it to gnome-gauges-and-levers :)
[10:22] <seb128> otherwise launchpad doesn't let you create a ubuntu bzr for example
[10:23] <seb128> stupid limitation if you ask me, but now we switched to have the upstream product name and I'm not spending efforts migrating all the bugs back, watching 2 components, etc
[10:23] <cjwatson> seb128: that limitation isn't one I recognise ...
[10:24] <cjwatson> you do (currently) need to have a product to stash the branch in, but its name doesn't have to match the source package name
[10:24] <cjwatson> (and of course we have proper source package branches now, but anyway)
[10:25] <pitti> seb128: we should move them all to package branches now
[10:25] <ogra> cjwatson, oh, does your recent initramfs-tools upload fix the issue you talked about yesterday ?
[10:25] <seb128> cjwatson:
[10:25] <seb128>  bzr push lp:~ubuntu-desktop/control-center/ubuntu
[10:25] <seb128> bzr: ERROR: Invalid url supplied to transport: "lp:~ubuntu-desktop/control-center/ubuntu": No such project: control-center
[10:25] <cjwatson> seb128: sure, that doesn't contradict what I just said ...
[10:26] <pitti> seb128: FYI, I created mass-tag.py and subscribe-triagers.py scripts on ronne (now with launchpadlib)
[10:26] <seb128> cjwatson: that's the issue we had
[10:26] <seb128> pitti: excellent!
[10:26] <cjwatson> seb128: my point was that, while the "control-center" bit there has to match an upstream product name in Launchpad, it doesn't have to be identical to the source package name
[10:26] <pitti> seb128: lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu ?
[10:26] <seb128> pitti: I was speaking about why we renamed the source one year ago
[10:26] <seb128> pitti:  not sure how lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu is revelant to that
[10:27] <pitti> seb128: that would be the package branch (not related to the renaming discussion)
[10:27] <cjwatson> ogra: yes, but while it does now seem to more or less boot, it's *much* slower than when I tested on jaunty; I've yet to figure out why
[10:27] <ogra> well, its a step forward at least :)
[10:28] <tkamppeter> pitti, hi
[10:28] <seb128> cjwatson: right, having the bzr matching the source name is handy though ... anyway we did that rename ago, that was perhaps not the best move but it's done now
[10:29] <seb128> pitti: should be stop using ~ubuntu-desktop/source/ubuntu now then?
[10:30] <seb128> pitti: can I push to lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu?
[10:30] <pitti> seb128: it's not urgent, but we should eventually migrate to package branches; it's cleaner, and avoids having to register products, too
[10:30] <geser> mvo: any idea what might have caused "E: Method http has died unexpectedly!"? I get this frequently from my karmic pbuilder (with an apt-cacher-ng proxy).
[10:30] <pitti> seb128: yes, you can
[10:30] <seb128> pitti: has that been announced somewhere?
[10:30] <cjwatson> seb128,pitti: I suggest holding off on those a bit, james_w is still sorting out imports
[10:30] <pitti> seb128: if we do that, we should update Vcs-Bzr: and delete the original branch
[10:30] <seb128> pitti:
[10:30] <seb128> $ bzr get lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu
[10:30] <seb128> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu/".
[10:30] <pitti> seb128: it was demo'ed on UDS
[10:31] <pitti> hm, bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu/karmic/apport/ubuntu/ works for me
[10:31] <cjwatson> specifically we haven't had final word that the importer will cope with other branches in those locations that it didn't import
[10:31] <pitti> seb128: oh, "get"
[10:31] <pitti> seb128: you need to push it there first
[10:31] <pitti> cjwatson: I see
[10:31] <cjwatson> james_w: if you're happy with people pushing to source package branches, maybe you could send a mail to ubuntu-devel-announce saying so?
[10:31] <cjwatson> I do *not* think any branches should be pushed there unless they are full-tree
[10:31] <tkamppeter> pitti, can you upload Poppler with my latest debdiff of bug 382379, so that I can continue to switch over CUPS?
[10:31] <pitti> james_w: that would be nice; especially for the many packages which we already have in bzr, and thus we don't want people to use the auto-imported ones
[10:32] <pitti> hi tkamppeter
[10:32] <seb128> pitti: ok, no hurry though, I think I will wait for an announce email saying things are ready to be used
[10:32] <cjwatson> we want to shift over to a consistent model of the world
[10:32] <pitti> tkamppeter: is that still a patch which needs to go to Debian's poppler first?
[10:32] <pitti> seb128: okay, deal
[10:32] <cjwatson> you can carry on using non-full-tree branches if you like, but please don't push them to the source package branch namespace
[10:32] <cjwatson> (e.g. debian/-only branches)
[10:32] <seb128> hum, full source ... I need to try again how fast bzr is for those nowadays
[10:33] <pitti> cjwatson: so far I pushed apport and jockey, both of which are full-source
[10:33] <pitti> and neither had an auto-import
[10:33] <pitti> seb128: we could request an import of a GNOME package which we regularly work on, and use that as a playground
[10:34] <pitti> (git imports FTW)
[10:34] <tkamppeter> pitti, I got a lot of positive answers concerning the Poppler-based pdftops: bug 362186, bug 377011, bug 381788
[10:34] <seb128> pitti: yeah, I agreed on that during UDS, should I be making a list? where do we need to request those?
[10:34] <cjwatson> pitti: for full-source branches, I think it makes sense to prefer something with history over the importer
[10:34] <pitti> seb128: let's try it for one package for now
[10:35] <cjwatson> seb128: https://launchpad.net/+code-imports/+new
[10:35] <pitti> cjwatson: right (both history, and more fine-grained than uploads)
[10:35] <seb128> cjwatson: thanks
[10:35] <cjwatson> pitti: yes
[10:35] <seb128> pitti: alright, nautilus?
[10:35] <pitti> seb128: sure; it's reasonably big, so we can see how much slower it is
[10:35] <seb128> pitti: doing the request now
[10:35] <cjwatson> so, one thing to bear in mind here is:
[10:35] <pitti> seb128: \o/
[10:36] <cjwatson> do you more often merge from Debian or from upstream?
[10:36] <tkamppeter> pitti, Poppler is not synced with Debian AFAIK, so if you upload it I can offer my test script on bug 310575, to check whether my Poppler fix really fixes this bug (this bug made me switching to Ghostscript originally).
[10:36] <pitti> tkamppeter: right, I don't mean poppler but cups
[10:36] <cjwatson> if you more often merge from Debian, you may find james_w's imports more useful than branches off git
[10:36] <cjwatson> if you more often merge (or cherry-pick, I suppose) from upstream, then you'll want to be branched off the upstream git repository
[10:37] <cjwatson> obviously we want to get everyone over to the latter model eventually, but the automatic package imports are not yet smart enough to link Debian package imports up with an upstream git repository
[10:37] <cjwatson> or an upstream import in general
[10:37] <cjwatson> that's a later phase in the plan
[10:37] <Keybuk> plus the imports don't do git branches, which is pretty much a brick wall across the freeway ;)
[10:38] <jpds> Keybuk: Launchpad imports? I thought they did now..
[10:38] <cjwatson> https://code.launchpad.net/~ubuntu-branches lists a number of automatic package imports that exist now
[10:38] <cjwatson> jpds: master only
[10:38] <jpds> cjwatson: Oh, right.
[10:38] <tkamppeter> For CUPS we must get the Debian maintainer to take Poppler 0.11.0 with my patch, or we need to make a Ubuntu exception in CUPS' debian/rules.
[10:39] <tkamppeter> pitti: ^^^
[10:39] <cjwatson> what we will have this cycle, and what was demoed at UDS, is the ability to do bzr get lp:ubuntu/karmic/blah; cd blah; bzr merge lp:debian/sid/blah
[10:40] <pitti> tkamppeter: right, that was my concern
[10:40] <tkamppeter> pitti, we could also use the test for the support of "pdftops -origpagesizes" which I use in my pdftops test script in debian/rules of CUPS.
[10:40] <cjwatson> if the ability to cherry-pick directly from upstream git is more important to you then you may want to think a bit carefully about how this is going to work for you in the short term
[10:40] <Keybuk> cjwatson: the debian ones are linked to the ubuntu ones?
[10:40] <cjwatson> Keybuk: yes (or at any rate will be this cycle)
[10:40] <Keybuk> how do we change where ubuntu/karmic/some-package points?
[10:40] <cjwatson> (not certain whether they are *right* now)
[10:40] <cjwatson> Keybuk: just push to it?
[10:41] <seb128> ok, bzr is still slooooooooooooow
[10:41] <Keybuk> cjwatson: it's owned by a team that only you and james_w are members of, no?
[10:41] <Keybuk> quest tmp% bzr branch lp:ubuntu/karmic/module-init-tools
[10:41] <Keybuk> bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/karmic/module-init-tools": module-init-tools in karmic has no default branch.
[10:41] <cjwatson> Keybuk: that namespace is supposed to be Magic
[10:41] <pitti> seb128: even with the 1.9 format?
[10:41] <pitti> Keybuk: missing the branch name
[10:41] <cjwatson> you want the 1.14 format, really
[10:41] <seb128> pitti: dunno what format is being used
[10:41] <cjwatson> pitti: err, no
[10:41] <seb128> I'm doing a "bzr get lp:gnome-control-center"
[10:42] <Keybuk> pitti: "the branch name" ?
[10:42] <pitti> Keybuk: s/$/ubuntu/ or something?
[10:42] <tkamppeter> pitti, another thing I am thinking about is to apply my patch also to the Poppler of Jaunty and make the pdftops switchover a Jaunty SRU of the Poppler and CUPS packages, as it fixes nearly every printing problem of Jaunty.
[10:42] <cjwatson> pitti: lp:ubuntu/karmic/module-init-tools is to lp:~owner/ubuntu/karmic/module-init-tools/branch-name as lp:module-init-tools is to lp:~owner/module-init-tools/branch-name
[10:42] <Keybuk> pitti: james_w's demo did not have a branch name
[10:42] <cjwatson> Keybuk: pitti is mistaken here
[10:42] <pitti> tkamppeter: no, that's too intrusive for an SRU, I'm afraid
[10:42] <pitti> cjwatson: ah, that's magic then
[10:43] <Keybuk> cjwatson: if I push to lp:ubuntu/karmic-module-init-tools will the right thing happen?
[10:43] <pitti> Keybuk: no
[10:43] <pitti> Keybuk: for push you need the branch name, and your own branch, as far as I remember James
[10:43] <cjwatson> Keybuk: it needs to have a binding set up, much like lp:module-init-tools needs to have a binding set up before you can push to it
[10:43] <Keybuk> quest ubuntu% bzr push lp:ubuntu/karmic/module-init-tools
[10:43] <Keybuk> bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/karmic/module-init-tools": module-init-tools in karmic has no default branch.
[10:43] <Keybuk> "no"
[10:43] <Keybuk> ;)
[10:43] <pitti> these are import-only fornow
[10:43] <tkamppeter> piiti, so better put appropriate Jaunty packages into my PPA and help everyone who complains personally? Note also that more people switch to another distro instead of complaining at us.
[10:44] <Keybuk> cjwatson: where do we set up those bindings?
[10:44] <pitti> tkamppeter: too bad that we didn't catch all those regressions before jaunty release :(
[10:44] <cjwatson> pitti: no, they aren't
[10:44] <pitti> cjwatson: hm, I asked james about them, and he said something like that in the session?
[10:44] <pitti> well, maybe that was a misunderstandin then
[10:45] <tkamppeter> pitti: So better forget about them and hope for better results in Karmic?
[10:45] <cjwatson> I think that setting the binding may be API-only for now, and it's possible that it does require being a member of ~ubuntu-branches (but there is a bug filed about that, which may or may not be closed)
[10:45] <cjwatson> http://paste.ubuntu.com/188101/ is the script I have from jml to do it
[10:45] <pitti> tkamppeter: backports/ppa is certainly enough, but for an SRU of that magnitude we need a deeper discussion than 5 minutes on IRC
[10:46] <pitti> tkamppeter: in particular, if this causes any other thing to regress again, it's out of scope for SRU
[10:46] <Keybuk> cjwatson: which way round do the arguments go?
[10:46] <pitti> tkamppeter: and since you did the switch to fix some bugs, they'd be reopened again if we switch back, no?
[10:46] <cjwatson> Keybuk: you should be able to push to lp:~ubuntu-core-dev/ubuntu/karmic/module-init-tools/karmic (or similar) and then I can set up the binding for you; but I'd appreciate it if you talked to james_w as well since this is all very new
[10:46] <Keybuk> cjwatson: ~ubuntu-core-dev/module-init-tools/ubuntu exists and has done for a while
[10:46] <cjwatson> we are *not* recommending yet that people push to such branches in general, AFAIK
[10:47] <cjwatson> Keybuk: yes, I know
[10:47] <tkamppeter> pitti, WDYT about how to perform the discussion then? Schedule a meeting with the release team? Or should it go into next ubuntu-desktop meeting? IRC? Phone?
[10:47] <cjwatson> so, you know, if the process seems pretty raw and unfinished it's because it is :)
[10:47] <Keybuk> right
[10:47] <Keybuk> but what I don't want happening is someone accidentally checking out a james_w import branch
[10:48] <Keybuk> that's not the bzr branch we've been using all this time
[10:48] <cjwatson> Keybuk: the plan is to deprecate branches in the upstream product namespace, in favour of the source package namespace
[10:48] <cjwatson> Keybuk: so talk with james_w, please, and agree on a plan
[10:48] <cjwatson> he's on holiday this week
[10:48] <joaopinto> pitti, yesterday I was chatting with Riddell about packagekit  , it will be the default installer for Kubuntu
[10:48] <pitti> joaopinto: hey
[10:49] <pitti> joaopinto: s/will be/is in jaunty/
[10:49] <pitti> tkamppeter: ubuntu-devel@ is a good start, I think
[10:49] <joaopinto> ah, it is already ? despite those problems ?
[10:49] <cjwatson> Keybuk: this general class of thing is certainly something we've discussed and (I believe) accounted for
[10:49] <pitti> joaopinto: I raised these concerns at UDS Jaunty, but the Kubuntu team decided that it's "good enough"
[10:50] <tkamppeter> pitti: Only reason for the switchover from Poppler to Ghostscript was bug 310575, so I only need to ask the reporter of that bug whether the problem still stays fixed with after the switch back.
[10:50] <pitti> joaopinto: but I consider the lack of conffile handling a blocker for Ubuntu, so I don't want it to be the defautl installer for Ubuntu
[10:50] <joaopinto> ok
[10:50] <Keybuk> cjwatson: it'd also probably help to have some meta data along the lines of the current blacklist to say "this merge won't work"
[10:50] <Keybuk> the ubuntu and debian module-init-tools packages are not related
[10:51] <tkamppeter> pitti, can I post on ubuntu-devel@ unmoderated? Ore does one need to be core-dev and/or Canonical full-time for that?
[10:51] <pitti> tkamppeter: you never posted to that?
[10:51] <pitti> tkamppeter: someone will moderate you if not
[10:51] <tkamppeter> No, I solved everything by IRC.
[10:52] <tkamppeter> pitti, what is the policy of that list, can I get unmoderated posting right on the list?
[10:52] <pitti> tkamppeter: no, you need to be a subscriber, as with any ubuntu list
[10:53] <pitti> tkamppeter: but in general, please really think twice before doing any SRU, and even more so with such massive changes
[10:53] <pitti> tkamppeter: in general it's better to document workarounds
[10:53] <tkamppeter> pitti: I am probably subscribed, as I get all the spam posted to it.
[10:53] <StevenK> My personal mail gets more spam than ubuntu-devel
[10:54] <StevenK> I daresay we only see a small fraction that the list actually gets
[10:54] <pitti> yeah, they are pretty well moderated
[10:55]  * StevenK grins cheekily and actually looks the ubuntu-{telepathy,bluetooth} queues
[10:55] <StevenK> bluetooth gets like nothing, and telepathy gets on average 10 or so a day :-/
[10:56] <cjwatson> Keybuk: possibly; although that could easily be determined by the fact that the branches share no common revision-ids
[10:56] <cjwatson> Keybuk: so it would only be needed for optimisation, not correctness
[10:57] <cjwatson> tkamppeter: any member of ~ubuntu-dev (including you) is supposed to be able to post unmoderated; other people are often given unmoderated access if they repeatedly post sensible things
[10:57] <tkamppeter> cjwatso, thanks.
[10:58] <StevenK> cjwatson: Isn't it ubuntumembers, not ubuntu-dev?
[10:58] <StevenK> (IE: @ubuntu.com)
[10:58] <cjwatson> tkamppeter: I'm astonished that you get anything more than a negligible amount of spam genuinely to ubuntu-devel. Sometimes it might have "To: ubuntu-devel" in the headers, but remember that that doesn't mean that you actually received it through that list
[10:58] <cjwatson> StevenK: that would be inappropriate, I think
[10:58] <jerroome> hi
[10:59] <cjwatson> StevenK: http://lists.ubuntu.com/ubuntu-devel says "posting moderated for people who are not Ubuntu developers"
[10:59] <StevenK> Ahh, I sit corrected
[10:59] <tkamppeter> cjwatson: With spam I mean general e-mails, not really unwished commercial postings.
[10:59] <cjwatson> tkamppeter: please don't use that term to refer to both, then.
[10:59] <cjwatson> it's horrifically confusing.
[10:59] <jerroome> does anyone know why an apt-get install fails inside a startup script (runlevel 2) and it doesn't when logged in ?
[11:00] <tkamppeter> sorry for inducing unneeded discussion here.
[11:00] <cjwatson> jerroome: goodness me, why would apt-get install in an init script be a good idea?
[11:00] <cjwatson> jerroome: there are all sorts of reasons that might fail, including needing interactivity for something
[11:01] <jerroome> its a firstboot script
[11:01] <cjwatson> jerroome: can't you do the package installation during the installer, rather than at first boot?
[11:01] <jerroome> in order to install a pool of machine with different packages depending on the machine
[11:01] <cjwatson> that's what nearly everyone else does ...
[11:01] <jerroome> how can I during installation
[11:02] <jerroome> I use preseed in order to install and install a few packages with d-i late_command
[11:02] <jerroome> but I need specific info about the machine in order to install the right packages
[11:03] <cjwatson> what sort of specific information? (also, perhaps move to #ubuntu-installer)
[11:03] <jerroome> hardware information
[11:04] <jerroome> specific own-made drivers
[11:04] <cjwatson> you can do that during preseeding too
[11:04] <cjwatson> aside from bringing up an X server and asking questions in it, there's almost nothing you can do in a firstboot script that you can't do in preseeding
[11:05] <jerroome> during preseed, I'm inside a chrooted environment and I can't read on hubed usb-devices, or can I
[11:05] <cjwatson> and the latter has better facilities for installing packages
[11:05] <cjwatson> you're mistaken there
[11:05] <jerroome> I first need to build my /dev tree to assign every device
[11:05] <cjwatson> firstly, preseed/late_command actually runs *outside* the installation chroot, and you need to chroot in if you need to get at the installed system
[11:05] <cjwatson> secondly, you have full access to /dev, /proc, /sys, etc.
[11:06] <jerroome> ok, I will search a bit more for it
[11:06] <jerroome> thank you for your advices
[11:06] <cjwatson> it is possible to make this work in a firstboot script (setting everything to noninteractive, etc.) but you'll end up basically reinventing chunks of the installer, so ...
[11:07] <pitti> seb128: I'll unseed ekiga from desktop, as a first step towards downsizing
[11:07] <jerroome> ok, thanks to you cwatson
[11:07] <seb128> pitti: thanks
[11:08] <pitti> seb128: do you want to keep it in main?
[11:08] <pitti> seb128: IOW, should it go to dvd, or drop at all?
[11:08] <seb128> not especially
[11:08] <StevenK> pitti: edubuntu-desktop also wants ekiga
[11:09] <pitti> okay
[11:09] <seb128> I'm not decided between easier maintainship for motu and dvd
[11:09]  * pitti moves to DVD for now
[11:09]  * seb128 wants archive reorganization
[11:09] <lamont> Keybuk: I wonder... how well would 2.15.1~rc1-1ubuntu2 work with a hardy everything else?
[11:10] <Keybuk> lamont: other than the blkid problems you mean?
[11:10] <lamont> that was sort of the answer I was looking for, yes
[11:10] <Keybuk> it should be ok
[11:11] <Keybuk> even the blkid thing won't conflict with udev
[11:13] <Keybuk> lamont: what was the util-linux issue colin was asking about?
[11:13] <lamont> delivering a file called "sbin" :-p
[11:13] <StevenK> Haha
[11:13] <Keybuk> really, how?
[11:13] <lamont> combination of lack of util-linux-udeb.dirs and install without trailing slashes
[11:13] <Keybuk> oh, colin did the util-linux-udeb bit ;)
[11:14]  * Keybuk cheerfully remains blameless
[11:14]  * Hobbsee blames Keybuk anyway
[11:14] <lamont> so we didn't create sbin, and then we successfully installed, uh, the wrong place
[11:14] <lamont> Keybuk: your name on the commit .... :-p
[11:14] <lamont> -rwxr-xr-x root/root     18720 2009-05-29 04:52 ./sbin
[11:15] <lamont> -rwxr-xr-x root/root     18720 2009-06-04 04:14 ./sbin/blkid
[11:15] <lamont> the second version is better (and newer)
[11:15] <Keybuk> util-linux (2.15-1ubuntu2) karmic; urgency=low
[11:15] <Keybuk>   * Add util-linux-udeb, containing blkid.
[11:15] <Keybuk>   * Restore correct shlibs for libblkid1-udeb.
[11:15] <Keybuk> Date: Tue, 12 May 2009 10:48:35 +0100
[11:15] <Keybuk> Changed-By: Colin Watson<EMAIL_ADDRESS>[11:15] <Keybuk> :p
[11:15] <Keybuk> I think I just committed due to Colin's allergy to GIT
[11:15] <lamont> and forgot --author, eh?
[11:16] <Keybuk> --author?
[11:16]  * Keybuk didn't know about that
[11:16] <lamont> iz love
[11:16] <TheMuso> SO are we moving to i586 compilation for x86?
[11:16]  * StevenK is allergic to git too. Anything more than bran^Wclone, and I'm stuffed
[11:17]  * pitti looks for his 4-semester git course voucher
[11:17] <lamont> StevenK: one of these days, i'll learn how to have bzr let me do development with multiple branches in one directory tree (instead of tree-per-branch H9), and bzr might become useful for me
[11:17] <StevenK> pitti: That was my joke :-P
[11:18] <lamont> pitti: that was from before 1.5, I'm sure.  1.5 is when the UI people actually made it, um, usable.
[11:18] <lamont> not perfect, mind you, just usable
[11:19] <Keybuk> a punchbag to take out your frustrations on now suffices
[11:19] <lamont> of course, if bzr-git won't let you branch from a git repo and push back to it, then it's b0rked
[11:19] <lamont> and you get your pretty UI that way
[11:19] <Keybuk> whereas before you needed effigies of the development team and katanas
[11:19] <Keybuk> lamont: it does
[11:19] <lamont> Keybuk: time for us to stop enabling them then, eh? :-)
[11:20] <pitti> lamont: you mean usable as in "even people who defend it much can't explain you how to push a branch to a remote site"? :-(
[11:20] <pitti> I RTFMed and tinkered for about an hour, and it still wouldn't work
[11:20] <pitti> and merging/git apply are just plain broken/evil
[11:21] <lamont> pitti: git push origin
[11:21] <Keybuk> lamont: doesn't work if origin does not yet exist
[11:21] <lamont> merging is _LOVE_
[11:21] <Keybuk> the only way to push to a remote site is to ssh into the remote site and run clone there ;)
[11:21] <pitti> the only thing I'm able to do is to push to a previously existing branch where I cloned from
[11:21] <pitti> but after an hour of trying to get a branch on my server which would actually work I gave up
[11:22] <pitti> Kay's recommendation after that was "oh, just do git gc; git prune, and rsync the .git tree"
[11:22] <Keybuk> the thing about git's learning curve isn't that it's steep
[11:22] <cjwatson> Keybuk: somewhere along the line, an added file got lost; I don't know whose fault that was
[11:22] <pitti> (which still wouldn't work)
[11:22] <lamont> pitti: well, one can always just go with 'rsync' :-)
[11:22] <Keybuk> it's that it's a 1000ft sheer cliff
[11:22] <Keybuk> and not only do you need someone at the top to help you
[11:22] <pitti> lamont: see, that's what I mean :) (not that it would work)
[11:22] <Keybuk> but you have to learn how to climb along the way
[11:22] <cjwatson> Keybuk: could well have been that I forgot to add
[11:22] <lamont> cjwatson: dropping an added file would be Keybuk's bad
[11:22] <Keybuk> while meanwhile, some pesky prankster is greasing the ropes and breaking your crampons
[11:22] <cjwatson> that depends on whether the 'git format-patch' output I sent actually included the added file
[11:23] <cjwatson> or whether I did git format-patch rather than just a patch
[11:23] <lamont> heh
[11:23] <cjwatson> Keybuk: I'm not actually allergic to git, I was just lost in the util-linux branch structure
[11:23] <pitti> cjwatson: format-patch should have added files (worked for me)
[11:23] <cjwatson> I don't *like* it
[11:23] <Keybuk> cjwatson: it is quite speial
[11:23] <pitti> cjwatson: the trouble is that "git apply" doesn't bother to add them
[11:23] <StevenK> cjwatson: git or util-linux in git?
[11:23] <Keybuk> cjwatson: that's just lamont though, he's strange
[11:23] <cjwatson> StevenK: the latter
[11:23] <Keybuk> StevenK: util-linux in git
[11:23] <cjwatson> pitti: doh!
[11:24] <lamont> git has lots of specialness.  and no doubt that the bzr UI is much nicer
[11:24] <TheMuso> How many of you now track projects that use git upstrea now? You will end up getting used to it.
[11:24] <pitti> cjwatson: for me, git apply does nothing more than plain "patch"; it doesn't add files, it doens't write commit logs, it doesn't commit
[11:24] <StevenK> I don't like git, I keep sliding down the cliff
[11:24] <pitti> TheMuso: I have done it for some months now
[11:24] <Keybuk> cjwatson: your format-patch does include util-linux-udeb.dirs
[11:24] <cjwatson> TheMuso: people have been telling me that for years :-)
[11:24] <Keybuk> why didn't git apply add that?
[11:24] <pitti> TheMuso: I'm maintainer of hal/hal-info/udev-extras, and I can do the basic stuff; but anything off the most simple add/commit/pull freaks me out :(
[11:25] <TheMuso> pitti: I know what you mean. I don't know all of git, and I don't hate it, but I don't love it either.
[11:26] <directhex> git is a control station with a thousand unlabeled levers, half of which initiate self destruct
[11:26] <StevenK> Haha
[11:26] <cjwatson> I don't mind git too badly as long as somebody else has already set up the repository and all I need to do is push stuff to it
[11:26] <directhex> cjwatson, even that freaks me out
[11:26] <TheMuso> cjwatson: Yeah I know what you mean.
[11:26] <directhex> and pristine-tar? brrr
[11:26] <pitti> cjwatson: yeah, in that scenario I can live with it quite well, too
[11:27] <directhex> there are 2 main problems
[11:27] <Keybuk> cjwatson: the thing to remember with the util-linux repository is all the lines
[11:27] <ion_> I don’t care which VCS is picked as the standard for packaging as long as you’re able to do ‘$vcs get/clone/whatever URI’ and get a single working directory, within which there is a branch that tracks upstream, from which there is a single branch for each patch, from which there’s the packaging branch. :-)
[11:27] <cjwatson> pristine-tar is a really cool idea, and not just needed for git
[11:27] <Keybuk> you merge from origin/master into master than into ubuntu/master, and push that, and it'll show up as lamont/master and lamont/ubuntu/master
[11:27] <directhex> 1) git's commands overload (intentionally?) well-known commands from other VCSes. they do entirely different things to what you expect them to do
[11:27] <Keybuk> unless of course you're merging from a stable branch
[11:28] <Keybuk> in which case you then merge from origin/stable/v2.15 to stable/v2.15 and then into ubuntu/stable/v2.15 and push that so lamont will have lamont/stable/v2.15 and lamont/ubuntu/stable/v2.15
[11:28] <directhex> 2) the docs are shit. they're essentially useless at defining real-world common useful scenarios, and instead drown you in twaddle
[11:28] <Keybuk> of course, packaging changes should be made to both master and stable
[11:28] <Keybuk> it's amazing how you can hear lamont's laugh in your head as you do this ;)
[11:29] <lamont> heh
[11:29] <lamont> anyway, time for me to do some work
[11:29] <pitti> lamont: LOVE> certainly more of the S/M kind :)
[11:29] <ion_> See how git://git.debian.org/git/perl/perl.git uses branches for example
[11:30] <Keybuk> though things like the util-linux branch madness begin to persuade me that supporting easy in-tree switching between in-repo branches is not necessarily a good thing
[11:31] <pitti> Keybuk: *nod* it's not just horribly confusing, it's also inefficient to constantly having to rewrite the working tree
[11:32] <Keybuk> not necessarily
[11:32] <Keybuk> there's a major killer reason for having that feature
[11:32] <Keybuk> build your big tree
[11:32] <Keybuk> make a branch
[11:32] <Keybuk> commit your bug fix
[11:32] <Keybuk> build, test, yup ok
[11:32] <Keybuk> switch back to your development branch
[11:32] <Keybuk> make now only needs to rebuild the diff
[11:33] <Keybuk> in bzr, that'd be a "rebuild the entire thing *again*"
[11:33] <pitti> why?
[11:33] <pitti> bzr commit doesn't remove files?
[11:33] <Keybuk> pitti: because a branch is a new directory
[11:33] <wgrant> You can work around that with bzr
[11:33] <Keybuk> if I have two bzr branches
[11:33] <Keybuk> I have two directories
[11:33] <Keybuk> which means two builds
[11:33] <wgrant> Have a separate checkout, and use 'bzr switch' on that.
[11:33] <pitti> right, but why would you build trunk/ if you are workign in mybranch/ ?
[11:33] <wgrant> YOu can then have working-treeless branches.
[11:34] <Keybuk> wgrant: it's not quite as nice
[11:34] <wgrant> Keybuk: Sure.
[11:34] <Keybuk> pitti: because mybranch is quick, and when I'm done and switch back to trunk, I don't want to have to rebuild the entire kernel again
[11:34] <pitti> Keybuk: well, I'm not saying that there isn't a use case for it; I just find it confusing, and I don't want to think about this concept usually
[11:34] <wgrant> Keybuk: FOr that I would normally unbind, commit commit commit, bind, up, commit.
[11:34] <cjwatson> there really isn't a fundamental reason why you can't do this in bzr; I think it's just that nobody's done the UI plumbing for it
[11:35] <Keybuk> cjwatson: right, bzr fundamentally supports it - there's just no UI
[11:35] <cjwatson> well
[11:35] <cjwatson> a branch is only a single head
[11:35] <cjwatson> so you would need to remember the heads somewhere
[11:35] <seb128> pitti: ok, takes 15 minutes to get gnome-control-center here, that's quite slow but I still workable
[11:35] <Keybuk> even a tree on disk can have multiple heads
[11:35] <Keybuk> cjwatson: bzr heads ;)
[11:35] <cjwatson> I don't think a branch has any way to remember them, although they're certainly stored in the repository
[11:35]  * pitti wonders if he is the only one who is a bit overwhelmed by all these different concepts of branches, heads, origins, indexes, and so on
[11:35] <Keybuk> the difficulty is switching from one head to the other - that's the missing bzr command
[11:35] <cjwatson> Keybuk: bzr heads looks at the repository
[11:35] <wgrant> Keybuk: You can do that with
[11:35] <pitti> seb128: that's a full git import?
[11:36] <wgrant> Gar.
[11:36] <wgrant> 'bzr pull -r somerevid'
[11:36] <seb128> pitti: that's a "bzr get lp:gnome-control-center"
[11:36] <Keybuk> cjwatson: right, heads go in the repository
[11:36] <Keybuk> cjwatson: a repository can have multiple heads
[11:36] <cjwatson> Keybuk: the missing bit is actually identifying the multiple heads
[11:36] <seb128> pitti: git takes 9 minutes
[11:36] <Keybuk> cjwatson: the commit log is usually a good sign
[11:36] <Keybuk> cjwatson: they have revision-ids
[11:36]  * Keybuk may be missing your point
[11:36] <cjwatson> Keybuk: sure, I know this
[11:36] <cjwatson> Keybuk: yeah, I think we're talking past each other, let me think and reword
[11:36] <seb128> pitti: and svn less than 1 minute
[11:37] <pitti> seb128: ah, it's an svn import
[11:37] <Keybuk> cjwatson: it's quite easy in bzr to end up with multiple heads in your repo
[11:37] <Keybuk> bzr heads --all will show them all
[11:37] <cjwatson> yes, I *know*
[11:37] <Keybuk> the bit that's missing is the command to say "right, so give me *this* head"
[11:37] <pitti> seb128: it's not the most recent format, so it might be faster if it gets upgraded to 1.9
[11:38] <cjwatson> Keybuk: .bzr/repository has all the revisions ever. .bzr/branch identifies a single head. 'bzr switch' lets you switch to a different head, by giving it a location; it looks up .bzr/branch in that location and uses that head.
[11:38] <Keybuk> cjwatson: bzr switch only lets you work on checkouts, not full trees
[11:38] <Keybuk> it's a deliberate limitation of that command
[11:38] <pitti> seb128: but I guess the main reason is that the history is just so big?
[11:38] <cjwatson> Keybuk: therefore the thing that is missing is not really a way to switch to a different head, but a way to *name* the head without having to have a .bzr/branch just for it
[11:38] <Keybuk> cjwatson: heads can have tags
[11:38] <Keybuk> but yes, I see your point ;)
[11:39] <cjwatson> Keybuk: oh, well, that's just a consequence of the fact that you don't really want to disassociate the working tree from its branch if they're tightly-bound
[11:39] <seb128> pitti: right, which is sort of my issue with those, I don't need 8 years of commit history to package a new version for karmic ;-)
[11:39] <pitti> seb128: I thought GNOME switched to git now; surprising to still see recent commits in the svn branch
[11:39] <cjwatson> if there were multiple heads stored in .bzr/branch, then that restriction wouldn't be necessary AFAICT
[11:39] <Keybuk> cjwatson: looms obviously store this information in a different .bzr file
[11:39] <pitti> seb128: yeah; for those, the debian/ only branches with bzr-buildpackage are quite nice
[11:39] <seb128> pitti: they did switch to git, svn is read only now
[11:39] <cjwatson> at the moment, running 'bzr switch' on a full tree runs the risk of horribly confusing you into losing a branch
[11:40] <cjwatson> or would run that risk, if it were allowed
[11:40] <pitti> seb128: for some projects, having upstream VCS is great, but I guess it doesn't apply to the majority of packages we maintain
[11:40] <seb128> right
[11:40] <cjwatson> seb128: almost the entire point of the branch format changes in 1.14 is to address this kind of problem
[11:40] <cjwatson> so I think you will see a substantial difference there
[11:40] <elmo> should I expect fairly modern intel gfx chipsets to be blacklisted?
[11:41] <cjwatson> seb128: (look up "brisbane-core")
[11:41] <elmo> someone here just upgraded a Dell XPS M1330 and it's 965 is blacklisted
[11:41] <elmo> which is, uh, surprising to me
[11:41] <Keybuk> elmo: jaunty? yes
[11:41] <seb128> cjwatson: ok thanks
[11:41] <elmo> Keybuk: awesome
[11:41] <cjwatson> seb128: http://bazaar-vcs.org/Roadmap/BrisbaneCore
[11:41] <elmo> (except not)
[11:41] <Keybuk> elmo: you can unblacklist it if you like your X to hang in the morning
[11:41] <pitti> elmo: bug 359392
[11:41] <seb128> note that it might work fine
[11:42] <pitti> elmo: there's a better solution now, but it's not yet inlinux-proposed/jaunty
[11:42] <seb128> I never got a xorg freeze on my laptop i965
[11:42] <pitti> elmo: getting there, though
[11:43] <elmo> pitti: oh, so there is hope it may get fixed in jaunty-updates later?
[11:43] <seb128> you can probably force the compiz use
[11:43] <seb128> especially if you have a virtual settings
[11:44] <pitti> elmo: yes, that's the plan
[11:44] <pitti> elmo: the jaunty-proposed compiz package already unblacklists i965 again
[11:44] <elmo> seb128: it's someone else's laptop and they already have a technological anti-midas touch; I'm not sure I want to further enable that by risking X freezes
[11:44] <elmo> pitti: awesome
[11:44] <pitti> elmo: and jaunty-proposed -intel has a bandaid patch
[11:44] <elmo> (really this time ;-)
[11:44] <seb128> elmo: ok, makes sense
[11:47] <Brent_Roth> quick new guy question: I'm a CS grad student focusing on security and am curious where I could be most useful
[11:48] <cjwatson> Brent_Roth: https://wiki.ubuntu.com/SecurityTeam/GettingInvolved possibly?
[11:48] <cjwatson> Brent_Roth: (also https://wiki.ubuntu.com/UbuntuDevelopment and https://wiki.ubuntu.com/ContributeToUbuntu for more general advice)
[11:49] <Brent_Roth> cjwatson: thanks, I had traversed those last 2, somehow missed the first one (lack of coffee? ;-p )
[11:49] <cjwatson> ... speaking of which
[12:09] <Keybuk> sometimes I worry about the kernel
[12:09] <Keybuk>  * This needs some heavy checking ...
[12:09] <Keybuk>  * I just haven't the stomach for it. I also don't fully
[12:09] <Keybuk>  * understand sessions/pgrp etc. Let somebody who does explain it.
[12:25] <soren> ISTR hearing that we'll be using some new mount magic instead of aufs for Karmic. Where can I find more details about this?
[12:26] <ogra> soren, currently its unionfs-fuse ... but that has speed issues
[12:27] <soren> I can imagine. I just thought I heard someone speak about "--overlay" option to mount or something.
[12:27] <soren> I *may* have been on crack at the time.
[12:27] <ogra> soren, the plan actually is to switch to mount --union if thats inplemented in time
[12:27] <soren> Aha!
[12:27] <ogra> but its not there yet, so unionfs-fuse is our easiest option to have live images at all
[12:31] <soren> Do we know when it's expected to land?
[12:32] <Keybuk> ogra: it's been implemented
[12:32] <Keybuk> just needs some testing
[12:32] <ogra> oh, cool
[12:32] <soren> Keybuk: Since when? 2.6.30?
[12:33] <Keybuk> soren: oh, it hasn't been merged yet
[12:33] <ogra> does our mount have it already ? i'm just setting up an ltsp vbox test server and could play with it
[12:33] <Keybuk> the patches are on LKML
[12:33] <ogra> ah
[12:34] <soren> ah
[12:34] <Keybuk> but that's a misnomer
[12:34] <Keybuk> if we shake out the bugs, contribute patches and generally look interested
[12:34] <Keybuk> it's more likely to be considered
[12:34] <soren> Sure, sure.
[12:35] <soren> It's just not yet something I can generally rely on being available.
[12:35] <soren> Yet.
[12:35] <cjwatson> is somebody actually working on getting it into our kernel?
[12:35] <cjwatson> 'cos I'm well up for getting live CDs working on it about ten seconds after I have a kernel I can do that with
[12:35] <Keybuk> cjwatson: andy had patches lined up
[12:35] <ogra> ++
[12:36] <Keybuk> but that got mixed in with the other kernel issues with -7
[12:37] <Keybuk> there's one known issue with vfs union mounts atm
[12:38] <Keybuk> rename()/link()
[13:02] <soren> Keybuk: Any particular reason "blkid /dev/whatever" only includes the USAGE bit if also passed "-p"?
[13:02] <Keybuk> soren: /
[13:02] <Keybuk> soren: blkid's interface is a bit strange right now
[13:02] <Keybuk> fixing it up is on the todo
[13:02] <soren> So "no"? :)
[13:04] <Keybuk> no particular reason, no ;)
[13:04] <Keybuk> you shouldn't really use -p anyway
[13:04] <Keybuk> that's for udev
[13:04] <soren> Well... Since I sort of need the USAGE bit.
[13:05] <Keybuk> right, so use blkid without -p
[13:05] <Keybuk> blkid -o value -s USAGE /dev/whatever
[13:05] <Keybuk> or does that not work?
[13:06] <soren> No, that's the point.
[13:06] <soren> The USAGE bit seems to nobe cached at all.
[13:06] <Keybuk> heh
[13:06] <soren> ..so unless I pass -p, I'm screwed.
[13:06] <soren> "nobe" means "not be".
[13:06] <Keybuk> and if you pass -p, you can't get the output in a useful form to you ;)
[13:07] <soren> Hm?
[13:07] <Keybuk> you could do eval $(blkid -o udev -p /dev/whatever) and read $ID_FS_USAGE after
[13:07] <soren> Yeah, that's pretty much exactly what I'm doing now.
[13:07] <Keybuk> improving blkid's api is on the todo
[13:21] <Keybuk> cjwatson: ayt?
[13:22] <cjwatson> Keybuk: just about to go out for lunch, but briefly
[13:23] <Keybuk> cjwatson: if I have int foo[] = { 4, 8, 15, 16, 23, 42 }; in a.c, I put int foo[]; in a.h right?
[13:23]  * Keybuk always manages to get this wrong ;)
[13:23] <Keybuk> and C FAQ is being not-there again for me
[13:26] <cjwatson> Keybuk: 'extern int foo[];', but yes, I believe that's right
[13:26] <cjwatson> Keybuk: C99 <IP_ADDRESS> has an example along those lines
[13:27] <cjwatson> (if you omit 'extern', any other translation unit that includes a.h will define its own storage for foo)
[13:28]  * cjwatson departs, being late
[13:39] <ogra> hrm, so unionfs-fuse with ltsp doesnt work
[13:40] <ogra> explodes with squashfs errors all over
[13:47] <ogra> stgraber, around already ?
[13:49] <stgraber> ogra: yeah
[13:49] <stgraber> ogra: oh, you did some tests, good. Bad result though
[13:49] <ogra> stgraber, remind me why we restart the nbd connection instead of using --persist from the beginning
[13:49] <ogra> i got it working now
[13:50] <ogra> but X takes ages to come up
[13:50] <stgraber> because nbd is started from the initrd and for some reason it seems that whatever respawns nbd when it dies use the position from where it was started
[13:50] <ogra> i would really like to know why ldm shows an edubuntu theme though
[13:50] <stgraber> as we pivot_root, the old location is no longer available and so respawning it fails
[13:50] <ogra> well, the restarting kills unionfs-fuse
[13:50] <stgraber> killing and restarting it from the nbd itself workaround that
[13:51] <ogra> though unionfs-fuse doesnt use move mounting which makes me think it should work fine without starting nbd
[13:51] <jerroome> is it possible to build a package which executes a script on it's installation ?
[13:51] <jerroome> if yes, how does it work ?
[13:52] <stgraber> ogra: you could try by killing nbd-server on the server side and see if it reconnects
[13:52] <ogra> i will
[13:52] <ogra> for now it only works if i comment the nbd restarting in the initscript
[13:52] <ogra> but it works at least
[13:53] <ogra> apart from the wrong theme and slow X
[13:53] <stgraber> wrong theme should be easy to fix, it's probably a side effect of the transition from one to multiple theme packages
[13:53] <ogra> yep
[13:53] <stgraber> in the end I don't plan to install all of them
[13:54] <ogra> it should only select edubuntu if edubuntu-artwork (or -desktop) is installed on the server
[13:54] <stgraber> it should only install the one corresponding to the current desktop on the server
[13:54] <stgraber> probably using the same code as we use for the usplash theme
[13:54] <ogra> they are small, and you have LDM_THEME to set them
[13:54] <ogra> if someone installs kde afterwards its easier to set LDM_THEME
[13:55] <stgraber> well, they are not that small no
[13:55] <ogra> so i would install them all, but pick the right default
[13:55] <stgraber> I had to tweak some of them to have them on the alternate CD last time
[13:55] <ogra> ?? they were always on the alternate CD
[13:55] <ogra> and the graphics are plain color squares
[13:56] <ogra> i created them like that for a reason ;)
[13:56] <stgraber> well, the gradient of Xubuntu is quite big and so is the ubuntu one
[13:56] <ogra> ugh
[13:56] <ogra> make it smaller then
[13:56] <ogra> ldm scales the image
[13:56] <ogra> there is no reason to make it bigger than 1024x768
[13:57] <ogra> and with a plain gradient and pngcrush it shouldnt be more than 40-50k per pic
[13:57] <stgraber> well, I deploy on 1680x1050 so I'd say there is a reason to have something bigger than 1024x768 ;)
[13:57] <ogra> no
[13:57] <ogra> ldm scales it
[13:57] <ogra> you wont see a difference with a plain gradient
[13:58] <ogra> which is the reason all themes only use a gradient
[13:58] <stgraber> yeah but scalling something like the current ubuntu one from 1024x768 to 1680x1050 is really ugly
[13:58] <ogra> its a gradient from light brown to dark breon
[13:58] <ogra> *brown
[13:58] <ogra> you wont see the difference
[13:58] <stgraber> it's not
[13:58] <ogra> huh ?
[13:58] <stgraber> it changed in Jaunty
[13:58] <ogra> to what ??
[13:58] <stgraber> it's one done by the ubuntu-art team
[13:59] <ogra> ugh
[13:59] <ogra> thats very bad
[13:59] <ogra> so you need to deply a huge pic that gets scaled down instead of a small one that gets scaled up :(
[14:00] <ogra> which also means you eat a lot of client ram
[14:00] <stgraber> well, other than the size (266k) it's pretty fast even on Geode thin clients with very few RAM memory
[14:00] <ogra> we should change that back
[14:01] <stgraber> though, currently the biggest is the xubuntu one ;)
[14:01] <ogra> why is that ?
[14:01] <stgraber> it's a gradient so doesn't compress well
[14:01] <ogra> should be a blue gradient too ... did that change ?
[14:01] <apw> dholbach, harvest ... doesn't seem to be tracking bugs as they move from one package to another ... see bug #373752 listed as linux-meta on your list
[14:02] <ogra> hmm
[14:02] <stgraber> ogra: nope, didn't change, it just doesn't compress well
[14:03] <ogra> meh
[14:03] <ogra> we should make it a plain color then
[14:04] <ogra> i still see the hang on logout btw
[14:04] <dholbach> apw: I have to admit that harvest is a bit broken right now - I'll put some work into it this cycle to make it better to use and more maintainable
[14:04] <stgraber> well, with the packages being split, I don't really care, I'd just put ldm-ubuntu-theme on the CD and the rest would stay in the archive
[14:04] <apw> dholbach, no worries, just thought you'd want to know
[14:04] <dholbach> thanks apw - i'll check if there's anything immediate I can fix now
[14:05] <stgraber> that way we can have "prettier" backgrounds for some derivatives if someone wants to contribute some. 250k for something like the ubuntu one isn't that bad, it'd just become a problem if we have to ship 4 of them
[14:06] <ogra> ok
[14:14] <ogra> hmm, the ubuntu theme isnt installed at all
[14:15] <stgraber> oh ?? I'll need to look at that ...
[14:16] <ogra> only edubuntu and the ltsp one
[14:17]  * ogra stopwatches a boot in vbox
[14:17] <stgraber> hmm, that's weird, I must have broken something with that transition
[14:18]  * ogra widdles thumbs
[14:18] <ogra> 2min and no X yet
[14:20] <stgraber> (with Jaunty it was like 20s or so)
[14:21] <ogra> 4:15 and i see an idle cursor
[14:21] <ogra> no ltsp theme yet
[14:21] <ogra> ah, there we go
[14:21] <ogra> 4:42
[14:21]  * stgraber wonders how long a livecd will ake to boot ;)
[14:22] <ogra> i think cjwatson tested that and said it was unbearable
[14:23] <ogra> ok, trying the same thing with edubuntu theme (plain yellow wallpaper) and no lts.conf
[14:25] <ogra> 2:11 with the edubuntu theme
[14:26] <shtylman> for those people that were in the SSD session: http://www.linux-mag.com/cache/7345/1.html
[14:30] <stgraber> ogra: I can drop ldm-themes from ldm's depends actually, right ? the ltsp theme is provided by the ldm package and I can then install the right theme in the artwork plugin.
[14:31] <ogra> yep
[14:31] <ogra> hmm, intresting, bg.png has 72k in the edubuntu theme and 2.6k in the ltsp theme
[14:31] <ogra> still the edubuntu theme starts up 2min faster
[14:31] <stgraber> do a "file" on theme just to check if that's png or jpg
[14:32] <stgraber> because we had to do some ugly things so it'd enter on the alternate CD
[14:32] <stgraber> ldm hardcodes the ".png" so there are some which actually are jpg but with a .png extension ...
[14:32] <ogra> ah, right, edubuntu has a jpeg
[14:32] <ogra> we should default to jpeg then
[14:33] <stgraber> (that's one of the things I'll be able to revert now that they all have their own binary package)
[14:33] <stgraber> and I want to fix ldm so it can use .jpg file
[14:33] <stgraber> that way we won't need that kind of hack
[14:33] <ogra> well, it already does :)
[14:33] <ogra> its just a filename issue
[14:33] <stgraber> gtkgreet/greeter.c:    rawpic = gdk_pixbuf_new_from_file_at_scale(ldm_theme_file("/bg.png"),
[14:33] <stgraber> that's the issue ;)
[14:34] <ogra> yeah
[14:34] <ogra> just rip the hardcoding out there
[14:34] <stgraber> we could probably get rid of the / and the file extension and have ldm_theme_file check for both png and jpg
[14:34] <ogra> the / should move into ldm_theme_file
[14:35] <ogra> i always wondered why ryan didnt add it there
[14:57] <stgraber> ogra: http://paste.ubuntu.com/188255/
[14:58] <ogra> can you make the addition of / a single line instead ?
[14:59] <stgraber> not sure I understand what you mean ? like putting it directly in the theme variable when it's set ?
[15:00] <ogra> instead of adding / to each line have a final line that prepends /
[15:00] <ogra> and only one return
[15:01] <stgraber> well, I need the / in the tests too, having it at the end of the function won't work
[15:02] <ogra> right, put the prepneding code at the top
[15:03] <stgraber> yeah but prepend to what ? it looks like replacing that / by a variable containing it ... not sure what's the gain there
[15:05] <ogra> stgraber, http://paste.ubuntu.com/188262/ something similar to that
[15:06] <stgraber> yeah, I actually just did something similar to that ;)
[15:06] <ogra> better readability at least
[15:06] <stgraber> http://paste.ubuntu.com/188265/
[15:07] <ogra> yeah :)
[15:08] <ogra> stgraber, btw, i havent had a sigle successfull logout yet
[15:08] <ogra> oh, i take that back ... this one worked ... so one out of ten
[15:09] <ogra> and it seems parsing lts.conf adds 2min to the boot, might not be the theme actually
[15:10] <ogra> i just copied the edubuntu theme to the ltsp dir and had the same 4min boot
[15:15] <robbiew> cjwatson: ping
[15:20] <ogra> stgraber, http://paste.ubuntu.com/188284/ has the (very hackish) unionfs-fuse code
[15:22] <ogra> stgraber, note that you need to drop configure_nbd from the initscript for now ... but at least that gets us booting (even though slow) clients for alpha2
[15:23] <ogra> stgraber, oh, and ltsp-client needs a dep on unionfs-fuse indeed
[15:28] <stgraber> ogra: thanks, I'll have to work on that for a bit as I'm backporting everything to jaunty and possibly karmic so I'll need to make that a bit conditional
[15:28] <ogra> yeah, hackish as i said
[15:28] <ogra> i just used it for testing the concept
[15:31] <cjwatson> robbiew: hi
[15:32] <robbiew> cjwatson: rickspencer3 is asking who should own bluetooth...I'm leaning towards desktop or mobile...but could be persuaded to take it (maybe)
[15:32] <robbiew> any thoughts?
[15:38] <cjwatson> robbiew: would be helpful to know who actually knows anything about it right now. It's had various owners (for some values of ...) in the past but I can't think of a current expert on the team
[15:38] <robbiew> cjwatson:  https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-bluetooth-stack
[15:38] <robbiew> is in question
[15:38] <ogra> the prob is that its split into three bits
[15:38] <robbiew> yeah
[15:38] <ogra> you have kernel/infarstructure/GUI parts
[15:38] <ogra> *infra
[15:39] <robbiew> superm1: any experience with bluez?
[15:39]  * seb128 has no clue about bluetooth, no bluetooth devices and is not interested to work on that
[15:39] <seb128> in case that's revelant to this discussion ;-)
[15:40] <robbiew> seb128: thanks...lol
[15:40]  * ogra sends seb128 some BT devices
[15:40] <superm1> robbiew, yeah i've worked on a few areas around the stack
[15:40] <superm1> robbiew, particularly killswitch and hid/hci switching
[15:40] <seb128> I know it's not easy to find people to look at the bluetooth bugs in the desktop team but I guess we could learn about it if required
[15:41] <robbiew> superm1: we're trying to find a home for it:  https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-bluetooth-stack
[15:41] <robbiew> and I don't mind making it a foundations thing...but currently you are the only person with any sort of skill in it
[15:41]  * robbiew realizes superm1 has a "day" job ;)
[15:42] <superm1> robbiew, i seem to feel that a majority of it's deficiencies do end up being desktop bugs with the interface
[15:42] <ogra> we have another community guy, i forgot his name but he was working quite a lot on it as well, persia might remember
[15:42] <superm1> robbiew, :)
[15:42] <superm1> and switching to gnome-bluetooth as the GUI tool is probably the first step in the right direction
[15:42] <ogra> was it Celtiore ?
[15:42] <robbiew> superm1: perhaps we agree to own the infrastructure part, but desktop owns the GUI stuff
[15:43] <robbiew> seb128: ^?
[15:43] <superm1> that sounds sane to me
[15:43] <seb128> sounds a fair deal to me
[15:43] <persia> crevette : Baptiste Mille-Mattias
[15:43] <ogra> ah
[15:43] <ogra> robbiew, ^^^
[15:43] <seb128> crevette hangs on #ubuntu-desktop and tend to do some updates
[15:44] <superm1> i especially feel that it's more of a desktop problem because bluez exports all of it's methods over dbus and is successfully used well in android and naemo
[15:44] <seb128> he's not really a hacker though and not a bluetooth expert either
[15:44] <ogra> yeah
[15:44] <robbiew> rickspencer3: ^^^^^^^^^^^^^^^
[15:44] <ogra> but he is keen to put time into BT
[15:44] <persia> And he spends a fair bit of time attempting to triage BT bugs.
[15:44] <rickspencer3> robbiew: is dbus not pat of foundations for karmic?
[15:44] <seb128> right, he's a GNOME bug triager for some years
[15:44]  * rickspencer3 cough cough
[15:45] <superm1> well the frontend desktop tools talk to the backend daemon (bluetoothd) over dbus
[15:45] <robbiew> rickspencer3: yes...we're saying that BT needs to be split
[15:45] <rickspencer3> robbiew: ok
[15:45] <seb128> ok, so clearly 99% of what standard users use are graphical part and some guy try to use graphical interface = desktop land to assign all the work on us ;-)
[15:45] <rickspencer3> who would be the right person to define the split?
[15:45] <robbiew> foundations takes the infrastructure stuff...desktop takes the GUI
[15:46] <robbiew> rickspencer3: superm1
[15:46] <rickspencer3> to be clear though, I don't expect the desktop team to have much bandwidth in this area
[15:46] <robbiew> understand
[15:46] <rickspencer3> I would expect to track upstream UI with a best effort to triage bugs and file them upstream
[15:46] <seb128> that's what I was going to say, I agree it's desktopish but we don't cover our components already
[15:46] <seb128> I don't think we will be able to take over new ones
[15:47] <seb128> I can make sure we have gnome-bluetooth update though
[15:47] <rickspencer3> seb128: I think BT has kind of not had a clear home, so at least this is a start
[15:47] <seb128> and get it added to desktop bugsquad list
[15:47] <rickspencer3> seb128: great
[15:47] <superm1> well after switching from bluez-gnome to gnome-bluetooth, hadess is the one leading gnome-bluetooth, and has a tracker on the gnome bugzilla and what not
[15:47] <rickspencer3> seb128: could you update the desktop blueprint to that effect
[15:47] <seb128> I think we need somebody with a clue about bluetooth to look at issue though
[15:47] <superm1> so bugs should be much more upstreamable and better to track
[15:48] <seb128> rickspencer3: I can do that
[15:48] <rickspencer3> thanks seb128
[15:48] <robbiew> I believe superm1 has a "clue"
[15:48] <rickspencer3> robbiew: will you guys have a blueprint for the foundations side?
[15:49] <rickspencer3> or should we share a blueprint?
[15:49] <robbiew> rickspencer3: just share it...i'll subscribe
[15:49] <rickspencer3> k
[15:49] <rickspencer3> thanks all: robbiew, seb128, superm1
[15:50] <superm1> i've got a clue on a few pieces in the stack, but not everything
[15:50] <robbiew> superm1: at this point..we'll take what we can get :P
[15:50] <superm1> from the foundations side, someone needs to get upstream to open up a bug tracker that bugs can be upstreamed from too. last i remember looking, it was closed and marcel didn't want distro bugs being sent up to it
[15:51] <robbiew> superm1: that's just great :/
[15:52] <cjwatson> was that just in the sense that he wanted them to be reproduced against clean upstream code first?
[15:53] <superm1> I'm not sure. jorge was looking some time back
[15:53] <superm1> if that's all it was, setting up more frequent builds to PPAs isn't too difficult, especially since they do releases so frequently
[15:54] <cjwatson> if it's in public revision control, we could do that by way of the daily upstream builds stuff
[15:54] <cjwatson> bzr-builder et al
[15:55] <superm1> yeah they keep it all in git on git.kernel.org
[15:55] <cjwatson> james_w,al-maisan: ^-
[15:55] <robbiew> cjwatson: good idea
[15:56] <robbiew> man....pidgin is sucking up my CPU lately
[15:59] <dholbach> Packaging Training with mvo in #ubuntu-classroom now!
[16:08] <superm1> robbiew, yeah so this is upstream's "tracker": http://wiki.bluez.org/report/1 they haven't been using it at /all/ since last spring
[16:08] <robbiew> superm1: hmm...okay, thnx
[16:11] <ogra> bryce, playing youtube videos fullscreen with the new intel driver crashes my X server, do you have a bug about that already ?
[16:12] <bryce> ogra: could be bug #383129 which is being widely reported, and which I'm about to upload a fix for
[16:14] <cjwatson> *blink* why does the archive want to promote make to priority: important?
[16:16] <ogra> bryce, i'll test if it goes away with the fix, though i dont see any libglx in my log
[16:16] <bryce> ogra: ...fix uploaded.  Once it's built, give it a test again, and let me know if the problem still occurs (and file a bug)
[16:23]  * al-maisan takes a look at git.kernel.org
[16:24] <cjwatson> perl recommends: make for cpan. wow. I guess that actually sort of makes sense.
[16:32] <slangasek> pitti: ok - so if dropping the patch works to get us an epiphany-extensions-2.26.pot, then in theory this can be a sync?
[16:35] <pitti> slangasek: the patch was necessary because of http://bugzilla.gnome.org/show_bug.cgi?id=556153
[16:35] <pitti> slangasek: I don't see that fixed in the upstream source yet, but maybe something else fixed it
[16:35] <pitti> slangasek: so if it builds a correct pot file, we can sync
[16:50] <slangasek> pitti: hmm, why has the retracer just gone and marked bug #282844 invalid?
[16:51] <seb128> slangasek: for the reason explained in the comment
[16:51] <slangasek> it's claiming it's an invalid bug because it didn't get around to retracing it for 6 months?
[16:51] <slangasek> and the dependency libs have moved?
[16:52] <seb128> yes
[16:52] <seb128> it has been decided to close crash bugs where the retracing is useless
[16:53] <seb128> we don't manage to keep up with those which are correctly retraced already and the retracing failed ones are mostly noise
[16:53] <slangasek> hmm - I guess that's fair, if this was a real problem I would have a newer crash report with fresh libs
[16:53] <seb128> right, that's the other thing, the user can update and send a new bug if that's still an issue
[16:54] <seb128> working on outdated version is suboptimal
[16:59] <pitti> slangasek, seb128: this morning I went through all the ancient failures
[16:59]  * slangasek nods
[16:59] <pitti> slangasek, seb128: and just retagged them for retracing; I fully expect most of them to be horribly out of date
[16:59] <pitti> but maybe some are still good
[17:00] <pitti> bdmurray gave me a list of all bugs which are just accessible for the apport user
[17:03] <bdmurray> Maybe we should chart out the retracer's workflow
[17:03] <bdmurray> Since it is getting rather involved / complicated
[17:28] <bdmurray> pitti or mvo: any idea what's wrong with varlogdistupgrade file in bug 376390?  I've seen many 40 byte dist upgrade files like that.
[17:40] <kirkland> jbernard: you here too?
[17:49] <slangasek> pitti: intltool-update now DTRT on epiphany-extensions, so perhaps the upstream bug can be closed
[17:50] <wip> update on the rt-kernel release date?
[17:50] <slangasek> pitti: it looks like this was fixed by defining EPIPHANY_API_VERSION directly instead of referencing the m4 macros
[17:52] <pitti> slangasek: ah, nice; thanks for checking
[17:55] <pitti> slangasek: I closed the upstream bug
[17:57] <slangasek> cheers
[17:59] <Notch-1> hi all
[18:01] <Notch-1> news about CONFIG_BLK_DEV_LOOP ?
[18:06] <cody-somerville> gwibber is spammy.
[18:07] <al-maisan> consider turning it off :)
[18:07] <cody-somerville> I am
[18:07] <cody-somerville> I'm just wondering how gwibber can be useful for people with hundreds of friends like me :P
[18:08] <al-maisan> get rid of some of your friends ;)
[18:10] <lajjr> hello pitti
[18:10] <pitti> hi lajjr
[18:12] <lajjr> I will work on the new bugs for apport that is what you meant in the e-mail right?
[18:12] <pitti> lajjr: if you want, that would be nice
[18:12] <pitti> lajjr: did you do some bug triage before?
[18:13] <lajjr> great we are on the same page..
[18:13] <pitti> lajjr: (i. e. check if the bug is complete, find reproducer, ask for more info, etc.)
[18:13] <lajjr> yes some on inkscape and ubuntu...
[18:14] <cody-somerville> holy crap
[18:14] <lajjr> I will have to do alot more to make a good dent.
[18:15] <cody-somerville> gwibber takes up 106mb of ram
[18:16] <Notch-1> where the ubuntu kernel people will answer questions? how can i talk with them?
[18:17] <cody-somerville> Notch-1, #ubuntu-kernel
[18:18] <Notch-1> cody-somerville: they do not answer in there, i'm asking since 2 week, only silence in there...
[18:18] <cody-somerville> Notch-1, What is your question?
[18:20] <Notch-1> i have a huge problem with the new kernel configuration
[18:20] <cody-somerville> Notch-1, well, thats not a question. Maybe thats why they haven't responded.
[18:20] <Notch-1> CONFIG_BLK_DEV_LOOP=y is a big problem for enyone that uses loop-aes
[18:21] <Notch-1> cody-somerville: you are very funny, but i have a real deal right here, i assure you i asked properly, but still no answer
[18:21] <Notch-1> look here: https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902 and here http://archives.free.net.ph/message/20090524.121638.72482e0d.en.html
[18:22] <Notch-1> there are a lot of people with the same problem, but nobody taking care of it
[18:22] <lajjr> I will do more pitti and thank you again.
[18:23] <Notch-1> so my question is "why CONFIG_BLK_DEV_LOOP=y? and most of all: can you please get back to CONFIG_BLK_DEV_LOOP=m ?"
[18:23]  * lajjr waves bye I have to get to it.
[18:27] <cody-somerville> Notch-1, my suggestion would be to send a patch to the kernel-team's mailing list
[18:28] <Notch-1> cody-somerville: they are not answering on the mailing list, is the second link i posted
[18:28] <jbernard> kirkland: yep!
[18:29] <cody-somerville> Notch-1, how long has it been since you sent your first e-mail?
[18:29] <Notch-1> cody-somerville: and there is not so much to change, just m to y :D
[18:30] <Notch-1> cody-somerville: 11 days on the mailing list, and 3 month on launchpad
[18:31] <cody-somerville> Notch-1, Folks have been busy with UDS and what not over the last few weeks
[18:31] <cody-somerville> Notch-1, I'm sure they'll reply to your mailing list post once folks get caught up with their e-mail
[18:31] <cody-somerville> Anyhow, I have to run. Best of luck! :)
[18:31] <amitk> Notch-1: I did ask a question on the kernel team ML regarding this.
[18:32] <Notch-1> cody-somerville: i know, but still... no answer on the channel, nor in 3 month on launchpad... i think that's odd...
[18:32] <Notch-1> amitk: well done, can you give me the url? i'll add it to the bug report...
[18:33] <jbernard> kirkland: so how will upstart use inotify? and from that, how can we integrate update-motd? i assume we won't need an init script, we can just register with upstart? can you explain how this works?
[18:33] <amitk> Notch-1: are you Alessandro?
[18:36] <Notch-1> amitk: no, i am notch-1 :D i only posted on launchpad, on the mailing list i found other messages so it was useless to post a new one... oh, i see you, i already posted this link on launchpad
[18:37] <Notch-1> amitk: anyway i don't know why this module is not in upstream, it works very fine for us all, i think they just don't want it
[18:38] <amitk> Notch-1: Please ask the people on the bug who know about the history of the module to reply to this query. It is very easy for a module to go upstream into drivers/staging these days.
[18:38] <Notch-1> amitk: and jari ruusu (the creator) is a very valid coder, but they don't like him :D
[18:39] <amitk> Notch-1: we are not saying we won't do it. We just want a good reason why this module is still not upstream. That's all.
[18:41] <Notch-1> amitk: i'm not talking about you, i just remember some conversation with strange peoples that do not like loop-aes and his creator
[18:41] <Notch-1> i think that's the reason...
[18:42] <amitk> Notch-1: ok :) Just reply to that query in the mailing list with a link to that discussion about loop-aes
[18:42]  * amitk is out of here now
[18:43] <Notch-1> amitk: thank you
[19:19] <kirkland> jbernard: it's still being designed/implemented by Keybuk
[19:19] <kirkland> Keybuk: around?  have a minute to discuss upstart inotify daemon?
[19:19] <Keybuk> kirkland: sure
[19:20] <kirkland> jbernard: from what I heard from Keybuk, basically we'll create an upstart config file that denotes a directory to watch (/var/run/update-motd perhaps), and an action to take when something in that dir changes (update-motd --force, perhaps)
[19:20] <kirkland> jbernard: so we'll just need to make update-motd depend on upstart >= X where X is the version that implements this
[19:20] <kirkland> jbernard: and the update-motd packaging will install that config file to be read by upstart
[19:21] <kirkland> Keybuk: is that mostly accurate?
[19:21] <Keybuk> yes
[19:22] <Keybuk> why --force?
[19:22] <kirkland> Keybuk: "perhaps"
[19:23] <Keybuk> you'll probably have something like /etc/init/update-motd.conf
[19:23] <Keybuk>     while $fhs_writable
[19:23] <kirkland> Keybuk: right
[19:23] <Keybuk>     watch /var/run/update-motd
[19:23] <Keybuk>     exec /usr/sbin/update-motd
[19:23] <Keybuk> --
[19:25] <kirkland> Keybuk: cool
[19:25] <Keybuk> /usr/sbin/update-motd will get run every time a file is added to/changed in/deleted from /var/run/update-motd
[19:25] <Keybuk> you're responsible for your own locking
[19:25] <kirkland> Keybuk: no problem, we have our own locking
[19:25] <Notch-1> amitk: so you are kernel engineer, and you can't tell me why CONFIG_BLK_DEV_LOOP is now y?? and you can't also tell me why you can't get back to m ?!?
[19:26] <Keybuk> Notch-1: because we often have no facility to auto-load the loop module when required
[19:26] <Keybuk> Notch-1: and it's not exactly something you'd ever *not* want loaded
[19:26] <Keybuk> that module doesn't contain a driver
[19:26] <Keybuk> so it's not as if we'll ever need to backport a newer version
[19:26] <Keybuk> or blacklist it for hardware issues
[19:27] <Keybuk> it's just a kernel feature
[19:27] <Keybuk> and it makes little sense to have kernel features *not* =y
[19:27] <kirkland> Keybuk: /usr/sbin/update-motd:41:       # If /var/run/motd.new exists, another instance is running
[19:29] <Notch-1> Keybuk: yes but there is another module, loop-aes that needs to replace the loop module, so with CONFIG_BLK_DEV_LOOP=y we need to recompile the whole kernel every update
[19:30] <Notch-1> there are serveral people stucked on intrepid for this little change
[19:36] <Notch-1> Keybuk: also the loop-aes-source package description is now wrong, cause it still says that we can install it with module-assistant, but right now it's impossibile (for this new kernel configuration)
[19:38] <RicardoPerez> pitti: hi! I would like to ask you a question about a translation typo in netbook-launcher. There's a very big translation typo in Spanish language, but this app is in universe, so the translations aren't in any langpack and the typo could be here until a (possible) SRU for netbook-launcher. This is bug #358641.
[19:39] <RicardoPerez> pitti: the question is: can an SRU be done for netbook-launcher in order to get the latest updated translations and correct the typo?
[19:44] <Notch-1> Keybuk: and amitk please don't make me ask for another month as always, answer me now, i'm tired
[19:47] <mterry> vorian: ping, the kio-gopher debian maintainer asked you to pop into #debian-kde on OFTC
[19:47] <vorian> meh, oftc
[19:47] <mterry> vorian: :)
[19:48] <elmo> Notch-1: I suspect you might get answers quicker if you tried being a little less demanding
[19:48] <elmo> Notch-1: just a thought
[19:51] <Notch-1> elmo: we are asking since 3 month, on 5 channels and launchpad and the kernel mailing list, and i got real answers only now that i spotted who is in the kernel team, asking directly by name... they just don't answer...
[19:52] <Notch-1> elmo: i'm afraid that for the next answer i have to knok to them doors, that's why i insisted...
[20:19] <jbernard> kirkland, Keybuk: awesome, that makes update-motd's job much easier
[20:19] <jbernard> Keybuk: do you have a public branch where you're doing development, perhaps I can help?
[20:20] <Keybuk> jbernard: nothing yet
[20:20] <Keybuk> still working on the internals
[20:20] <Keybuk> the inotify watch on top is the easy bit ;)
[20:21] <jbernard> you're targeting karmic for the new upstart?
[20:21] <Keybuk> yes, hopefully
[20:22] <jbernard> awesome, any idea when you expect to have enough of the structure laid out that I can start integrating?
[20:23] <Keybuk> by feature freeze ;)
[20:23] <jbernard> perfect ;)
[20:26] <cjwatson> you know, when testing the desktop CD to make sure my unionfs-fuse changes worked, it would have helped to give it enough memory, wouldn't it?
[20:26] <cjwatson> like, not kvm's default of 128MB ...
[20:26] <cjwatson> so yeah, desktop CD now boots fine
[20:30] <yellabs> hi there
[20:31] <yellabs> any one from canonical around?
[20:32] <yellabs> when i go to the server webpage and click on download server edition i get the webpage of the desktop edition instead
[20:32] <yellabs> http://www.ubuntu.com/products/whatisubuntu/serveredition
[20:32] <yellabs> check it out,
[20:32] <yellabs> click and see : http://www.ubuntu.com/getubuntu/download
[20:32] <yellabs> will get you to http://www.ubuntu.com/getubuntu/download
[20:33] <yellabs> wich is, yes strange enough , the desktop version
[20:34] <ajmitch> that page has a tab saying server edition on it
[20:34] <yellabs> then after looking around you use the tab on the left to really get the server edition
[20:34] <yellabs> http://www.ubuntu.com/getubuntu/download-server
[20:34] <yellabs> wich would be the correct url link in the first place..
[20:34] <yellabs> dont you agree?
[20:35] <yellabs> small issue thats true...
[20:35] <ajmitch> you could file a bug against ubuntu-website on launchpad
[20:36] <yellabs> yeah ok
[20:36] <ajmitch> mostly because there's probably noone here responsible for the website
[20:36] <yellabs> i was stupid enough not to notice, untill i ran the installer on the server...:P
[20:37] <highvoltage> hey ajmitch! haven't seen you in a while!
[20:37] <ajmitch> hey highvoltage
[20:37] <yellabs> wasted two hour download and burn,... my own mistake afcuase should have been more carefull..
[20:37] <yellabs> any how..started off on the right foot again...
[20:38] <yellabs> all will be wel in a few hours again, thanks for your tolarence of my private rant...
[20:38] <yellabs> :)
[20:41] <ajmitch> highvoltage: what have you been up to lately?
[20:44] <highvoltage> ajmitch: well, I don't know if you've been following, but impi was bought over by a big corporate who wouldn't let me do things like go to UDS's
[20:44] <highvoltage> ajmitch: so I left later last year and started my own thing. freedom has been good so far :)
[20:44] <ajmitch> yeah, so I heard from a former impi person in the NZ loco channel :)
[20:44] <ajmitch> funny where you run across such people
[20:44] <highvoltage> heh
[20:44] <directhex> you can take our conferences, but you can never! take! our Freedom!!!
[20:45] <ajmitch> directhex: but I thought you were leading the conspiracy to steal Freedom
[20:45] <highvoltage> I heard that directhex secretly wants an iphone
[20:46] <directhex> highvoltage, i wouldn't even touch one until i can do the first-run config without iTunes
[20:46] <highvoltage> :)
[20:50] <yellabs> ok off to install the server, bye bye
[20:52] <directhex> highvoltage, android is a little more interesting, but only if it's any good. a Free platform doesn't guarantee awesomeness - merely makes it more achievable
[20:53] <yellabs> have an nice night ( capre noctum )
[20:53] <yellabs> carpe
[20:53] <yellabs> ..
[20:53] <highvoltage> directhex: *nod*
[21:24] <calc> er is it safe for mktemp to be removed? or is karmic currently in a broken state?
[21:27] <calc> seems that coreutils replaced it... except that mktemp was essential and coreutils isn't
[21:28] <tkamppeter> calc, I also got such build failures on Poppler, seems that Karmic on the build servers is currently completely broken.
[21:28] <calc> oh hmm no coreutils is essential also, so why does this show up
[21:28] <calc> tkamppeter: ah
[21:29] <calc> tkamppeter: yea removing an essential package requires the user to type a sentence stating they know they are breaking their system, heh
[21:29] <calc> You are about to do something potentially harmful.
[21:29] <calc> To continue type in the phrase 'Yes, do as I say!' ?] Yes, do as I say!
[21:29] <calc> hehe
[21:30] <maxb> aptitude has an even more emphatic sentence to type
[21:30] <maxb> "Yes, I am aware this is a very bad idea"
[21:31] <calc> heh
[21:31] <arand> What is the reason for the xserver-xorg-video-intel 2:2.6.3-0ubuntu9.2 not having made it into recommended updates yet?
[21:34] <chrisccoulson> arand - it's in jaunty-proposed - that's why
[21:34] <calc> chrisccoulson: i think that might be his question... ;-)
[21:34] <calc> chrisccoulson: as to why its in -proposed instead of -updates by now
[21:34] <chrisccoulson> ah, ok, i misunderstood. thanks;)
[21:35] <calc> otherwise he probably wouldn't know the version number of the package, heh
[21:36] <cjwatson> arand: nobody's marked the bugs it fixed as verified yet
[21:36] <cjwatson> (bug 371544, bug 370777)
[21:37] <cjwatson> bdmurray: 370777 has a couple of confirmations - should it be verification-done now?
[21:37] <arand> cjwatson: I've helped several people install it and so far it seems to have worked for everyone... I was presuming the reason was that the patch was hacksish or something?
[21:37] <cjwatson> arand: it *looks* like just lack of paperwork actually, should be possible to sort it out soonish
[21:38] <chrisccoulson> it seems bug 371544 and 370777 were regressions caused by 2:2.6.3-0ubuntu9.1 in jaunty-proposed, and those are both fixed now. the bug that this version was originally meant to fix is bug 359392, which doesnt seem to be verified yet
[21:39] <arand> Ok, good stuff :), btw the compiz un-blacklist patch would need to get through as well I think.
[21:39] <cjwatson> chrisccoulson: hmm, http://people.ubuntu.com/~ubuntu-archive/pending-sru.html doesn't list that
[21:39] <chrisccoulson> hmmmmm, how is that list generated? the bug report has a verification-needed tag
[21:40] <bdmurray> cjwatson: yes the tag could change to verification-done in that bug
[21:40] <cjwatson> some crazy script of pitti's
[21:41] <sbeattie> it looks at the changelog for lp numbers; if the updated package didn't get generated against the original version, the bug gets overlooked by the script.
[21:41] <cjwatson> oh, YM it looks at the .changes?
[21:42] <cjwatson> no, that doesn't make sense
[21:43] <cjwatson> oh, I suppose it does because it's scraping LP and LP has the .changes
[21:43] <sbeattie> yes, e.g. here it looks at https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-intel/2:2.6.3-0ubuntu9.2
[21:44] <cjwatson> yeah, I was just getting there :)
[21:44] <cjwatson> maybe it ought to explicitly look for all the versions in between
[21:44] <cjwatson> it'd have to walk the publishing history or something
[21:44]  * cjwatson sticks an SEP field around it
[21:45] <cjwatson> I might try to rewrite it with launchpadlib one of these days
[21:49] <sbeattie> cjwatson: I looked at one point; unless things have changed I don't think the actual changelog entry is pullable from the api, but getting which versions were published to proposed is doable.
[21:50] <bdmurray> I've a karmic update failing due to mktemp being marked for removal
[21:50] <bdmurray> sbeattie: I just saw changes_file_url
[21:50] <bdmurray> but haven't tested it
[21:51] <cjwatson> right, I was about to say changes_file_url should be fine
[21:52] <bdmurray> It'd be neat to know what was new in the API
[21:56] <cjwatson> >>> launchpad.distributions['ubuntu'].main_archive.getPublishedSources(distro_series=launchpad.distributions['ubuntu'].getSeries(name_or_version='jaunty'), pocket='Proposed', source_name='xserver-xorg-video-intel')[0].changes_file_url
[21:56] <cjwatson> 'https://edge.launchpad.net/ubuntu/+archive/primary/+files/xserver-xorg-video-intel_2.6.3-0ubuntu9.2_source.changes'
[21:56] <cjwatson> (not that I'd actually write it like that, was just trying to cram it into one line
[21:56] <cjwatson> )
[21:56] <cjwatson> and that URL seems to have sensible contents
[21:59] <seb128> are buildds known to be broken?
[22:00] <cjwatson> what's up?
[22:00] <seb128> http://launchpadlibrarian.net/27504925/buildlog_ubuntu-karmic-i386.poppler_0.11.0-0ubuntu3_CHROOTWAIT.txt.gz
[22:00] <cjwatson> yum, that mktemp thing
[22:00] <cjwatson> it's not buildd-specific
[22:01] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531846
[22:01] <seb128> cjwatson: thanks
[22:50] <kirkland> cjwatson: i was thinking of changing kvm's default from 128 to 256
[22:50] <kirkland> cjwatson: i've hit similar problems recently on vm's without swap space
[22:50] <kirkland> cjwatson: 128 just doesn't cut it ;-)
[22:50] <kirkland> cjwatson: mind you, i use a kvm alias
[22:50] <kirkland> cjwatson: but i'm suspecting that others are hitting this too
[22:51] <kirkland> fwiw: alias kvm='kvm -m 256 -net nic,model=virtio -net user -smp 2'
[22:53]  * ogra used a 256M vbox for the ltsp tests tohday btw ... didnt really speed it up
[23:04] <slangasek> cjwatson: there have been numerous claims in bug #359392 that the -intel in jaunty-proposed doesn't fix anything; OTOH, it's impossible to extract useful information from that bug report due to all the chatter
[23:04] <cjwatson> I couldn't even load the bug
[23:05] <slangasek> there are 11 follow-ups to that bug report since I went to lunch :P
[23:05] <slangasek> none of them useful
[23:07] <bryce> slangasek: is that the one with the patch to increase the virtual resolution?
[23:08] <slangasek> bryce: that's "X freezes starting on April 3rd"
[23:08] <bryce> slangasek: I think the 4k offset patch is believed to be a better solution for that problem
[23:08] <bryce> however there's also a bunch of kernel fixes that have solved various freeze issues, so hard to say
[23:09] <slangasek> are those kernel changes in the pipe for jaunty?
[23:09] <slangasek> damn; type "X freezes" and it obligingly does
[23:10] <bryce> there's a few kernel changes in the pipe, I've lost track of exactly what's going in
[23:10] <slangasek> -0ubuntu2 includes crasher fixes, you said?
[23:10] <bryce> yes
[23:11] <slangasek> crasher, but not freeze?  or both?
[23:11] <bryce> I can confirm only it fixes crashes
[23:12] <bryce> the fix handles a null pointer situation
[23:12] <slangasek> losing track> what do we need to do to get a handle on this?  that bug is already noisy enough that I'm very wary of flip-flopping patches in -proposed
[23:13] <bryce> well, there have been half a dozen different patches that have gone into karmic that fix different freeze issues.
[23:14] <slangasek> so if I'm running karmic with KMS, do I have all the bits needed to provide a useful freeze report?
[23:14] <slangasek> #       Option "MigrationHeuristic" "greedy"
[23:14] <slangasek> #        Option "AccelMethod" "uxa"
[23:14] <slangasek> #       Option "NoAccel"
[23:14] <bryce> I think part of the problem is that you introduce one of those patches, and people with one of the other 5 freezes say "it doesn't help for me" so it's hard to get a positive confirmation on them
[23:14] <slangasek> hmm, that's not what I selected. :P
[23:15] <slangasek> INFO: task_events/1:23731 blocked for more than 120 seconds.
[23:15] <bryce> also we've seen at least a couple instances where the same reporter had at least two distinct freezes, and it took two different patches to get everything resolved
[23:15] <bryce> karmic with KMS, and also need the intel_gpu_dump tool from the x-freeze ppa
[23:15] <slangasek> right, I think that's a lot of what's happened in that SRU bug in question.  We don't have good ways to distinguish the freezes, I guess?
[23:16] <bryce> erf, I need to get that tool into the archive
[23:16] <slangasek> intel_reg_dumper isn't enough?
[23:16] <bryce> yes, it is usually sufficient
[23:17] <slangasek> and apport xorg collection is still broken?
[23:17] <bryce> if the dump for two freezes show it's stopped at the same gpu call, it's the same freeze, else have to assume it's a different freeze
[23:17] <bryce> slangasek: should be fixed now; I uploaded a fix earlier today
[23:18] <bryce> basically I just dropped the fglrx-loaded code; it's redundant anyway
[23:18] <bryce> slangasek: oh hey btw good news - I got KMS working on -ati :-)
[23:18] <slangasek> yay!
[23:18] <slangasek> totally free of all freeze bugs, right? :)
[23:18] <bryce> or I should say, apw got it working, I just did the testing :-)
[23:19] <bryce> it's got totally more interesting bugs
[23:19] <slangasek> heh
[23:19] <bryce> actually, we just need to get the X side of things more up to date.  It doesn't have DRI, Xv, fast-vt-switch, etc. at the moment.  But the kernel boots KMS properly now.
[23:20] <bryce> we might have the necessary bits in for alpha-2...
[23:23] <slangasek> oh good; trying to install the updated xorg package has caused apt-get to hang in an uninterruptible disk wait
[23:23] <bryce> ???
[23:24] <slangasek> I assume KMS is to blame somehow :)
[23:26] <slangasek> bryce: and the x-freeze-test ppa doesn't seem to be built for karmic?
[23:27] <slangasek> I guess I can just use jaunty, then
[23:27] <bryce> the jaunty deb should work fine
[23:27]  * slangasek nods
[23:27] <bryce> on my todo list to merge that into universe...  working on -ati merge first
[23:28] <bryce> slangasek: regarding the freeze bugs, maybe what would help would be to just start cataloging all the freeze patches we know about into a table, indicating status for jaunty
[23:29] <bryce> most of them are kernel patches, but iirc there's a few on the X side as well
[23:30] <ion_> bryce: Btw, when the background image is loaded and rendered with early X during bootup, would it be a good idea to do the loading and rendering with something like nice 20 ionice -c 3 to avoid it slowing down startup?
[23:30] <ion_> 19 even
[23:30] <bryce> probably a bit time consuming to track down all the info, but probably more effective than dealing with those multi-hundred comment bug reports
[23:30] <bryce> ion_: I don't know... test it out and see
[23:30] <ion_> I will :-)
[23:31] <bryce> my guess is that it won't make a difference, but I have no rationale for that guess ;-)
[23:31] <slangasek> bryce: we also have people following up to that bug saying that karmic doesn't fix their problem... I guess we should point them through the freeze debugging guide?
[23:31] <ion_> Loading and scaling a big JPEG *is* somewhat heavy on older computers.
[23:31] <bryce> slangasek: right.  They need to file new bugs using those guidelines and NOT glom onto an existing bug report.
[23:31]  * slangasek nods
[23:32] <bryce> with freeze bugs we really need to insist on one bug report per person
[23:35] <dtchen> not just freeze bugs - bugs with multiple causes that appear as similar symptoms
[23:35] <dtchen> it's a complete PITA to have to open multiple tasks across multiple bugs when people abuse "me too"
[23:38] <bryce> dtchen: totally agreed, it's just especially bad with the X freeze bugs
[23:39] <bryce> users have a hard time identifying what causes their freeze, usually they say the freezes come on "randomly"
[23:40] <bryce> they're not actually random, but the conditions that have to be met are pretty hard to spot as a user
[23:41] <slangasek> hmm... rebooted, and now sound is gone
[23:41] <slangasek> worse than last time :)
[23:44] <dtchen> it'll probably get worse if you boot 2.6.30-8.9-generic
[23:45] <dtchen> also, the "sound is gone" bug is often caused by PA writing to the wrong sink
[23:45] <slangasek> no, it's gone even if I bypass PA.
[23:45] <slangasek> this is with 2.6.30-7, which I just booted for the first time
[23:46] <dtchen> corroborated by speaker-test -c2 -Dplughw:0 ?
[23:46] <dtchen> gotta love the "throw a dart at the stack" bugs :/
[23:47] <dtchen> TheMuso: possible regression for ALSA in 2.6.30-8.9-generic caused by commit 44ada1a147fa28ae15b83a031c48fc2b992cc3ef in linux-2.6.git
[23:52] <dtchen> TheMuso: yeah, it seems to be a bogus commit that only works if CONFIG_PREEMPT is enabled. and karmic has it disabled.
[23:52] <slangasek> dtchen: no sound with that command, even after switching back to the -6 kernel
[23:53] <dtchen> slangasek: have you eliminated mixer settings as a possible cause?
[23:54] <slangasek> dtchen: no, rather I just checked the mixer and found it muted ;)
[23:54] <slangasek> the master mixer