[12:13] <mikmorg> I was in here last night, and think I asked a misleading question..
[12:13] <mikmorg> although only slightly
[12:14] <mikmorg> Is there any way I can re-master the Ubuntu desktop CD?
[12:14] <mikmorg> I want to change initrd and stuff..
[12:14] <mikmorg> I think it would be easiest to just get all of the tools together to do a complete remastering.
[12:15] <LaserJock> I think it's quite a bit easier to start from an existing .iso
[12:16] <mikmorg> hmm.. is it really that complicated?
[12:16] <LaserJock> but perhaps some of the stuff at https://launchpad.net/ubuntu-cdimage/+branches
[12:17] <mikmorg> thanks
[12:17] <mikmorg> i'll see if i can do it without remastering
[12:17] <mikmorg> but i like to have the option
[12:30] <pochu> mikmorg: You might be interested in https://help.ubuntu.com/community/LiveCDCustomization
[12:31] <mikmorg> pochu: thanks
[12:37] <MrKeuner> hi, are the translations I make using launchpad shared with the actual projects themselves?
[12:38] <MrKeuner> Or am i translating just for Ubuntu?
[12:42] <LaserJock> MrKeuner: #ubuntu-translators might know better than I, but I think the actual projects are welcome to get the translations but Ubuntu is the primary user now.
[12:43] <MrKeuner> what does primary user mean?
[12:43] <LaserJock> the main one
[12:43] <LaserJock> so the translations at this point are mainly used by Ubuntu
[12:43] <bhale> hi LaserJock
[12:43] <LaserJock> but I think the actual projects can get them too if they want
[12:43] <LaserJock> hi bhale
[01:20] <Riddell> tfheen: new kde-guidance not vital for Tribe but nice if you happen to be able to let it through before CDs get built (gives us back our power manager)
[01:37] <elmo> ** (firefox-bin:5296): WARNING **: Owner of /tmp/orbit-james_test is not the current user
[01:37] <elmo> why is it even looking there?
[01:37] <elmo> and not /tmp/orbit-james
[04:30] <calc> is there a way to do a feisty network install from a gutsy cd?
[04:31] <calc> gutsy doesn't appear to work with the laptop that i tried to install it on, but feisty supposedly works
[06:12] <fabbione> morning
[06:13] <Burgundavia> hey fabbione
[06:16] <wasabi> Hurm. At some point we need a clear policy on a direction with regards to evms. Either it's supported or not.
[06:20] <spectre007__> ?
[06:35] <sanmarcos> I have a .deb I created for debian unstable that requires absolutely no changes to run on Feisty or Gutsy. If I wanted it to be included in universe, I should get it added to the official debian repos first?
[06:35] <crimsun> yes.
[06:35] <Burgundavia> sanmarcos: that is the simplest
[06:36] <sanmarcos> ok, thanks :)
[07:34] <Hobbsee> well, the internet sure broke last night!
[07:35] <Hobbsee> http://www.smh.com.au/news/wireless--broadband/telstra-restores-service-after-broadband-meltdown/2007/06/06/1181089114356.html
[07:36] <Amaranth> heh, broke a lot for me the last couple days too
[07:36] <Amaranth> afaik it was broken most of the time i was sleeping and working over the past day
[07:36] <Amaranth> arg
[07:36] <Amaranth> no openoffice, don't crash on me now
[07:38] <Hobbsee> hehe
[07:38] <Hobbsee> gutsy?
[07:53] <pitti> Good morning
[07:54] <Hobbsee> pitti!!!
[07:54] <pitti> hey Hobbsee!
[07:54] <Hobbsee> pitti: why i had trouble last night:  http://www.smh.com.au/news/wireless--broadband/telstra-restores-service-after-broadband-meltdown/2007/06/06/1181089114356.html
[07:55] <Hobbsee> aka, the shoestring broke.
[07:56] <pitti> hah
[07:57] <StevenK> pitti: Morning
[07:57] <pitti> hi StevenK
[07:58] <StevenK> pitti: I have a debdiff for scim-qtimm: http://wedontsleep.org/~steven/scim-qtimm.debdiff
[08:00] <mneptok> Hobbsee: it's not some big truck!
[08:09] <pitti> StevenK: looks harmless enough; is that dependency really necessary for tribe?
[08:11] <StevenK> pitti: I'm classing it as nice to have for Kubuntu, but if you say no, you say no.
[08:12] <pitti> StevenK: I mean, it does not look like if it would change any default behaviour on the CD, since skim is installed anyway
[08:13] <pitti> StevenK: so, of course you can upload, but it doesn't look worth risking FTBFS and archive inconsistency again
[08:13] <pitti> so I might leave it in the queue until the release
[08:13] <Hobbsee> that doesnt look terribly tribe worthy
[08:13] <Hobbsee> and we're getting enough kubuntu breakage already
[08:13] <StevenK> pitti: In that case, I'll leave it until the freeze is lifted.
[08:14] <pitti> StevenK: if it fixes really important stuff in an unintrusive manner, please do bug me :)
[08:14] <pitti> StevenK: if it doesn't qualify for that, you'll owe me a beer instead
[08:15] <StevenK> pitti: It doesn't, which is why I'm not sharing. :-)
[08:16] <StevenK> Heh
[08:26] <Fujitsu> Could [insert person who has rights to accept release nominations today]  (ubuntu-drivers at the moment, it appears) please accept the nominations on bug #118855
[08:26] <ubotu> Launchpad bug 118855 in mplayer "Stack overflow in mplayer cddb handling" [High,In progress]  https://launchpad.net/bugs/118855
[08:26] <Fujitsu> *?
[08:37] <pygi> morning
[08:37] <Hobbsee> hi pygi
[08:37] <Hobbsee> (fujitsu, done)
[08:37] <pygi> hey Hobbsee ^_^
[08:42] <tfheen> morning
[08:42] <Fujitsu> Hi tfheen.
[08:44] <Hobbsee> yay, tfheen!
[08:44] <pitti> hi tfheen
[08:45] <StevenK> pitti: Any bugs for Tribe 1 I can throw myself at?
[08:46] <pitti> StevenK: finding critical ones :)
[08:53] <fabbione> is anybody having issues with loopback devices in gutsy?
[08:53] <tfheen> fabbione: yes, the kernel has changed how they work
[08:53] <fabbione> there has been a kernel module change that tells me that they are created dynamically
[08:53] <fabbione> yeah
[08:53] <fabbione> but i think userland doesn't know about it yet..
[08:53] <fabbione> losetup spits errors everywhere
[08:54] <fabbione> tfheen: is there a bug for it already?
[08:54] <fabbione> (if you know of coursE)
[08:54] <tfheen> unsure, I think userland just has to be changed to cope.
[08:56] <Hobbsee> morning fabbione
[08:56] <fabbione> hey Hobbsee
[08:57] <cjwatson> fabbione: the kernel isn't quite right yet
[08:57] <cjwatson> the final version of the upstream patch (which always creates n+1 loop devices) doesn't require userland changes (at least theoretically)
[08:57] <cjwatson> morrning
[08:57] <cjwatson> morning
[08:57] <fabbione> cjwatson: ah ok
[08:57] <cjwatson> but the patch that we have in the kernel at the moment only creates n loop devices, which makes getting at the n+1'th require manual mknod
[08:58] <fabbione> yes i can see that...
[08:58] <fabbione> thanks
[08:59] <cjwatson> Fujitsu: trying, but LP's giving me an IntegrityError. Will chase that up in a bit
[09:00] <Fujitsu> cjwatson: Hobbsee used a workaround to do it soon after I asked here.
[09:00] <StevenK> Perhaps they should just be both declined?
[09:01] <Fujitsu> Probably, yes. LP seems confused.
[09:10] <dholbach> good morning
[09:10] <pygi> hey dholbach :)
[09:10] <dholbach> hiya pygi
[09:17] <LaserJock> morning dholbach
[09:18] <dholbach> hiya LaserJock
[09:31] <cjwatson> Fujitsu: https://bugs.launchpad.net/malone/+bug/118915
[09:31] <ubotu> Launchpad bug 118915 in malone "IntegrityError trying to approve a bug nomination" [Undecided,Unconfirmed]
[09:32] <Fujitsu> cjwatson: Malone proves its reliability yet again.
[09:33] <dholbach> Fujitsu: Seriously, how often do you have problems with it?
[09:33] <Fujitsu> I guess not that often, but it's still annoying.
[09:34] <dholbach> no, not that often
[10:02] <pitti> doko: https://bugs.launchpad.net/ubuntu/+source/hunspell/+bug/111940 can be closed now, right?
[10:02] <ubotu> Launchpad bug 111940 in openoffice.org "libhunspell-1.1-0 1.1.5-6: Incompatible ABI change" [High,Fix committed]
[10:03] <doko> pitti: done
[10:03] <pitti> awesome
[10:17] <Keybuk> gnargh
[10:17] <Keybuk> now I have to remember how to use OpenSSL again
[10:17] <pitti> hi Keybuk
[10:18] <StevenK> Keybuk: To do what?
[10:18] <pitti> Keybuk: time for the yearly ssl cert re-signing?
[10:19] <Keybuk> indeed
[10:19] <Keybuk> a) figure out what parameters my certs had last year
[10:19] <Keybuk> b) make new ones
[10:20] <Mithrandir> Keybuk: why not just use cacert?
[10:20] <Keybuk> whuh?
[10:20] <shawarma> Keybuk: You can reuse your csr's.
[10:20] <Mithrandir> http://www.cacert.org/ ; free CA
[10:20] <thom> and they seem somewhat less awful than they used to be, too
[10:21] <Keybuk> shawarma: how do I do that?
[10:21] <ogra> pitti, you pinged last night ?
[10:21] <cjwatson> pitti: except for powerpc, where OOo failed to build :-/
[10:21] <shawarma> Keybuk: If you still have it, just use it again. AFAIR it has no timestamp, so you'd just be reusing the parameters.
[10:21] <Keybuk> shawarma: assume that I know nothing about OpenSSL
[10:21] <cjwatson> but I guess the bug's dead, sure
[10:21] <shawarma> Keybuk: Heh.
[10:22] <Keybuk> and the fact that I have managed to successfully generate things before is simply due to being able to cargo-cult enough commands to make it work
[10:22] <Mithrandir> Keybuk: C-r openssl ca in your shell with a long enough history? :-P
[10:22] <pitti> cjwatson: right :/
[10:22] <shawarma> Keybuk: Well, last time you did it, you probably produced a .csr somewhere in the process. This time around, skip the tutorial you're using up until right after the csr generation and start there. :)
[10:22] <Keybuk> shawarma: I don't remember that file, and don't have them
[10:22] <pitti> ogra: hi
[10:22] <Keybuk> I have certs/something.pem and private/something.pem
[10:22] <shawarma> Keybuk: Ah.
[10:23] <shawarma> Keybuk: This time keep the .csr around.
[10:23] <pitti> ogra: any tribe-1 relevant bugs from your side still?
[10:23] <cjwatson> gar, and it looks like it was really close to the end
[10:23] <pitti> cjwatson: at least I'm happy that it worked on amd64 this time
[10:23] <shawarma> Keybuk: Oh,hang on. That might be enough.
[10:24] <Keybuk> Mithrandir: I can't seem to make a cacert account
[10:24] <Mithrandir> Keybuk: oh?
[10:24] <ogra> pitti, not that i'm aware of, but i didnt do a test install yet, just starting the first one
[10:24] <shawarma> Keybuk: openssl req -new -key private/something.pem -out req.pem
[10:24] <pitti> cjwatson: very same problem with the previous build, so it might not just be a glitch
[10:24] <shawarma> Keybuk: (I think)
[10:24] <Keybuk> Mithrandir: crappy web form
[10:25] <pitti> ogra: btw, current cd images are still not 100% good
[10:25] <doko> pitti: please promote portaudio19-dev (the ubuntu1 build) to main, new upstream version of a library already in main
[10:25] <pitti> ogra: publisher is running, afterwards I'll build candidates
[10:25] <ogra> well, but i'll see if they die on any edubuntu specific stuff, virtualbox is cheap ;)
[10:25] <pitti> right
[10:26] <pitti> ogra: just mentioning it for a community CFT
[10:26] <pitti> (call for testing)
[10:26] <shawarma> Keybuk: The EXAMPLES sections of the various openssl man pages are very handy. req(1ssl) is your friend in this case. :)
[10:28] <mvo> pitti: let me know when images are there, I will re-install my workstation with i386 as amd64 hates me and does not give me working DRI (I ignored that problem for the last year or so but now I have enough)
[10:28] <pitti> sure
[10:39] <pitti> doko: doesn't work, because it depends on jack, which build depends on type-handling and another weird thing
[10:40] <doko> pitti: "(the ubuntu1 build)"
[10:40] <doko> pitti: openoffice.org-voikko uploaded
[10:41] <pitti> doko: ah, I see; that's still in unapproved, will do after tribe
[10:41] <pitti> doko: merci
[11:01] <pitti> Riddell: your new kde-guidance upload looks troublesome: http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
[11:04] <pitti> mvo: ubuntu alternates are up
[11:05] <mvo> pitti: cool, thanks
[11:10] <pitti> cjwatson: "mv: cannot stat `usr/lib/syslinux/isolinux.bin': No such file or directory" -> just to confirm, this error on the ubuntu-server CDs is already fixed by your adjustments from yesterday?
[11:20] <cjwatson> pitti: yes
[11:21] <heno> pitti: are we rolling right in to testing of 20070606 (shall I dump -05)?
[11:22] <lool> Hmm could someone enlight me on what XSBC-Original-Maintainer means in the DebianMaintainerField wiki page: for example, would you use XSBC-Original-Maintainer for sources other than Debian?
[11:22] <shawarma> lool: I'd say yes, unless the original maintainer explicitly has said that he/she would manage Ubuntu bugs.
[11:25] <lool> Is there a way to avoid the header to turn up in Sources.gz and Packages.gz?
[11:25] <lool> Or should one simply comment the field out?  e.g. #XSBC-Original-Maintainer
[11:26] <sivang> hey people
[11:26] <lool> Hmm XSBC seems to mean the header will be copied in Sources and Packages files while XS only makes it appear in Source; pehaps C stands for *.changes file
[11:26] <LaserJock> I believe so
[11:28] <pitti> heno: yes, 05 is obsolete in any case; 20070606.1 will be the good ones (ubuntu alternate is up, rest is building)
[11:28] <lool> Right, dpkg-source looks for ^X[BC] *S[BC] *- and copies these headers, dpkg-genchanges looks for ^X[BS] *C[BS] *- and dpkg-gencontrol for ^X[CS] *B[CS] *-
[11:29] <heno> pitti: thanks, I'll post -06.1 then
[11:30] <lool> (So I simply need to use X-OriginalMaintainer if I don't want it anywhere; great)
[11:31] <pitti> lool: we agreed on XSBC-, though
[11:31] <pitti> lool: since we do not want to hide credit for the DDs
[11:31] <lool> pitti: Do you know whether the Debian archive accepts the fields everywhere?
[11:32] <lool> pitti: Credit is a good point indeed; there's the problem of Packages.gz file bloat (especially in Debian) too
[11:33] <pitti> lool: no, I don't, but packages with this are not supposed to be uploaded to Debian
[11:34] <lool> pitti: I'm grabbing Debian packages from Ubuntu itself grabbing them from maemo, and I thought I should follow the same DebianMaintainerField concept, except it's the other way around :)
[11:34] <pitti> lool: ah, heh, I see
[11:35] <iwj> lool: You should think about who might want want and whether they'll be offended.  I don't think Ubuntu guys will be offended whatever you do.
[11:36] <iwj> So the question is whether the maemo people are likely to be offended or not.
[11:36] <lool> iwj: So if I paint your cat in red you want be offended?
[11:36] <iwj> Why not ask them ?
[11:36] <lool> s/want/wont :-P
[11:36] <iwj> lool: Feel free to paint all of my cats red.
[11:36] <lool> iwj: haha :)
[11:36] <iwj> -3s/want want/want what/
[11:37] <pitti> iwj: I guess you have about zero of them, then?
[11:37] <iwj> pitti: :-).
[11:37] <lool> True, I should simply ask them; and the Debian archive not supporting these would also rule the question out
[11:39] <iwj> Yes.  But it would be amusing in a way if maemo say `yes please keep our name in XSBC-Original-...' and Debian don't support it :-).
[11:41] <Mithrandir> lool: fwiw, I don't care if you don't have the Ubuntu people not mentioned in the control file as long as the changelog is correct.  (With my ubuntu mobile hat on)
[11:41] <cjwatson> there's no technical barrier to using those fields in Debian
[11:41] <cjwatson> in the archive
[11:41] <cjwatson> (I make no comment on social issues)
[11:42] <lool> Mithrandir: Was there some discussion to use XSBC-OM for maemo Maintainer:s already?
[11:43] <Mithrandir> lool: not that I know of.  I can raise it on maemo-developers@ if you want?
[11:44] <pitti> heno, all: ubuntu alternate and live are now up and good for testing: 20070606.1
[11:44] <lool> Mithrandir: I was about to do that, but I'm still subscribing; please do for both Ubuntu x Debian if you like; thanks a lot  :)
[11:45] <Mithrandir> sure
[11:56] <fabbione> pitti: did you ever get around to accept multipath-tools in -proposed?
[11:56] <fabbione> pitti: i can't find any mail from L
[11:56] <fabbione> LP
[11:56] <pitti> fabbione: not yet, sorry
[11:57] <fabbione> pitti: ok thanks.. it's fine. i was just worried the upload got lost
[11:57] <pitti> nope, it's in the queue
[11:57] <fabbione> danke
[12:14] <StevenK> pitti: Just noticed that openoffice.org-voikko has hit gutsy_probs. I'd like to bet it's due to the new upstream release of openoffice.org. Would you like me to upload a build1 of it?
[12:14] <StevenK> pitti: (There no being no point showing a debdiff, it only being a changelog change.)
[12:14] <Mithrandir> StevenK: there's a voikko in unapproved.
[12:14] <pitti> StevenK: doko already did that, it's being published right now
[12:15] <StevenK> Aww, someone beat me to it.
[12:30] <doko> pitti: I see that main inclusion reports are outstanding for lp-solve and ufsparse
[12:31] <pygi> jdong, poke
[12:34] <pitti> heno, ogra, all: edubuntu alternatives up (20070606.1), xubuntu alternatives up (20070606)
[12:34] <pitti> heno: can you set the xubuntu timestamp accordingly? there hasn't been a automatic daily build for it yet
[12:35] <heno> pitti: right, so back to 2007606 (?)
[12:35] <pitti> heno: for xubuntu, yes
[12:35] <heno> indeed, ok
[12:35] <pitti> heno: (for xubuntu live as well)
[12:35] <ogra> great, i'm about 2/3 through the 20070606 install in my virtualbox
[12:35] <ogra> i'll test the next one right afterwards
[12:35] <heno> yes, all of https://isotesting.stgraber.org/isotesting/iso/Xubuntu
[12:36] <pitti> heno: for server as well, please
[12:38] <heno> pitti: ok, willdo
[12:39] <heno> pitti: I only see *0605 for server is that right?
[12:39] <pitti> heno: it's still building
[12:39] <heno> ok IC
[12:39] <pitti> I'll announce the images here as they arrive
[12:39] <pygi> jdong, wake up, wake up ^_^
[12:42] <pitti> -server is up
[12:48] <fabbione> pitti: please remember to drop me a note when you plan to release Tribe-1 so we can start hw-cert process
[12:48] <fabbione> pitti: cr3 is aware that you are about to deploy the nuke :P
[12:48] <pitti> fabbione: yep, I'll do that (it's part of the documented process, so I won't forget)
[12:48] <fabbione> pitti: perfect
[12:48] <pitti> heh :)
[12:48] <pitti> fabbione: can you test the server images a bit?
[12:49] <pitti> fabbione: I'm not sure whether the d-i for kernel ABI -6 made it for sparc
[12:49] <fabbione> pitti: that's kind of important, isn't it?
[12:50] <pitti> fabbione: right, but the fix came veeeery late
[12:50] <fabbione> actually i think d-i wouldn't build if the abi doesn't match
[12:50] <pitti> so we already kind of agreed on skipping it for tribe-1
[12:50] <pitti> fabbione: oh, it built this morning
[12:50] <fabbione> pitti: well that will make impossible to do hw-cert
[12:51] <pitti> fabbione: I accepted it and things and built cd images afterwards, but I'm not sure whether the latest version landed on the CD images
[12:51] <fabbione> pitti: for sparc we only need -server
[12:51] <fabbione> pitti: do if you built the server recently enough, it should be good
[12:51] <pitti> fabbione: I built it some 20 minutes ago, yes
[12:52] <fabbione> pitti: ok, let me update my rsync script to cope with gutsy and i will double check
[12:52] <pitti> thanks
[12:55] <fabbione> pitti: ETA 10 minutes
[01:03] <fabbione> pitti: CD has abi 6 of kernel and udebs.
[01:04] <fabbione> pitti: i think it should be good.. checking kernel md5sums
[01:04] <pygi> damn, powerpc failed to build brasero :-/
[01:06] <sabdfl> doko: what's our glibc roadmap look like? someone's asking about RT, and saying glibc2.5 has significant improvements
[01:07] <fabbione> pitti: the md5sum for initrd.gz from last d-i and what's on cdrom matches... not sure why vmlinuz doesn't but we might mangle something there
[01:08] <pitti> fabbione: hm, only linux-ubuntu-modules was FTBFS for quite some time; the actual kernel has worked
[01:09] <fabbione> pitti: that should not change the vmlinuz md5sum but gimme a few minutes to burn it and i will test it directly
[01:09] <fabbione> pitti: does BenC know about those failures?
[01:10] <pitti> fabbione: yes, he fixed them last night
[01:10] <fabbione> ok
[01:10] <pitti> so I gave-back d-i on sparc this morning
[01:11] <fabbione> i might as well do a test install.. quicker than just double checking
[01:12] <pitti> heno: quick status update FYI: ubuntu/edubuntu/xubuntu alternates up, kubuntu still out of date (publisher is running for latest stuff), ubuntu live up, edubuntu live taking ages and block other lives
[01:13] <cjwatson> sabdfl: feisty has glibc 2.5
[01:13] <bhale> sabdfl: gutsy has 2.5
[01:13] <cjwatson> (both!)
[01:13] <bhale> :D
[01:13] <fabbione> eheh
[01:14] <fabbione> glibc war!
[01:14] <cjwatson> pitti: I generally budget about 45 minutes for any livefs set
[01:15] <pitti> cjwatson: edubuntu live build now runs for 1.5 hours
[01:15] <cjwatson> wow
[01:16] <pitti> cjwatson: livefs building finished on king about 20 minutes ago, now teststatus is empty
[01:16] <cjwatson> that's a bit much
[01:16] <pitti> cjwatson: but the ssh king@ still didn't finish
[01:16] <cjwatson> sounds like it's hung
[01:17] <heno> pitti: thanks I've just disabled test reporting on kubuntu for now
[01:18] <pitti> cjwatson: shall I just kill it and try again, or poke the sysadmins about it? has this happened before?
[01:19] <heno> pitti: you should register on https://isotesting.stgraber.org so I can give you admin super powers (everyone has to register again, sorry)
[01:19] <pitti> heno: I did already, and submitted some amd64 reports (pitti)
[01:20] <heno> ok, cool
[01:21] <sabdfl> cjwatson, bhale: doh, thanks :-)
[01:23] <cjwatson> pitti: http://king.buildd/~buildd/LiveCD/gutsy/edubuntu/latest/livecd-20070606.3-amd64.out still seems to be running
[01:24] <cjwatson> it's in the middle of debootstrap
[01:24] <cjwatson> seems to be progressing quickly enough
[01:24] <cjwatson> pitti: I don't know, maybe it was waiting for a lock? did you try to run multiple livefs builds at once?
[01:25] <pitti> I just killed it here
[01:25] <pitti> so maybe it released a lock now
[01:25] <pitti> cjwatson: it might be possible that I accidentally ran two livefs builds in parallel
[01:26] <pitti> cjwatson: can I kill the current build on king somehow?
[01:26] <Mithrandir> pitti: it's quite important you don't kill livefs builds midway through, if so you need sysadmin intervention
[01:26] <pitti> Mithrandir: ok, noted for next time; sorry for the trouble
[01:26] <Mithrandir> sorry for not telling you
[01:27] <Mithrandir> they just don't abort cleanly.
[01:28] <fabbione> pitti: i am afraid something is borked on sparc cd... it can't find the cdrom
[01:28] <fabbione> pitti: skip it for tribe-1. not worth fixing at this stage.
[01:28] <pitti> fabbione: ok; any idea what the reason is?
[01:28] <fabbione> pitti: not yet.. it just booted
[01:29] <cjwatson> pitti: at this point would it not be better to just let it finish?
[01:30] <fabbione> the cdrom detect thingy is looping and i can't back to the main menu
[01:30] <pitti> cjwatson: there's no process attached to that on lithium any more, so not sure whether it'll make sense; currently discussing that in #c-s
[01:31] <fabbione> pitti: i can't debug it from the cdrom itself. i will have to do some manual digging..
[01:31] <fabbione> cjwatson: do you happen to know if there is already a bug on cdrom detect looping forever if it can't find a cdrom?
[01:32] <pitti> fabbione: ok, thanks so far; at least I know that the d-i rebuild/publish/CD image process worked, and I can kill the -5 kernels
[01:33] <mdz> mvo: when do you expect to have an upgrader available for gutsy?  I have a system I'm going to upgrade and would be glad to test
[01:33] <fabbione> pitti: it can be everything for now.. i need a bit more time to understand
[01:35] <StevenK> cjwatson: It worries me a little that ~ubuntu-archive/madison.cgi can't find libc6 in Gutsy.
[01:35] <fabbione> pitti: yeah the kernel is right on the cd..
[01:36] <Keybuk> :'( why does rsync hate me so much?
[01:37] <fabbione> cjwatson: never mind my bug request before. it happens only when booting with "check-cd". it works on normal install
[01:37] <doko> sabdfl: glibc-2.5 is current in gutsy, preparing glibc-2.6, but not yet decided on an upload
[01:38] <fabbione> pitti: it's a kernel bug.
[01:38] <fabbione> pitti: i will have to talk to David about this
[01:39] <fabbione> [   21.844794]  Can't get ranges for PCI-PCI bridge /pci@1f,0/pci@1/pci@1
[01:39] <fabbione> and after that bridge there is the IDE controller for the cdrom
[01:39] <fabbione> that's missing even from lspci
[01:39] <fabbione> no wonder it can't find it :)
[01:42] <fabbione> pitti: netinstall might still work.. but i don't think it's worth spending too much effort into it. If the network interface is behind a non-initialized bridge you will hit the exact same problem
[01:42] <fabbione> pitti: but it's your call if you want it in or out.. i am good both ways
[01:43] <pitti> fabbione: let's declare it as broken for now and mention it in the release notes, shall we?
[01:47] <fabbione> pitti: i am good with whatever decision you take.
[01:47] <fabbione> pitti: personally i see little point in getting tons of reports when we know it's broken
[01:48] <fabbione> i am pretty sure it works on Niagara, but really. not worth the pain
[01:48] <pitti> right
[01:54] <pitti> fabbione: can you please put some information about this problem in a bug report and toss me the number?
[01:54] <pitti> fabbione: so that we have something to refer to in the notes
[01:54] <pitti> (and to track for tribe-2)
[01:56] <cjwatson> fabbione: sounds more like cdrom-checker than cdrom-detect?
[01:56] <Mithrandir> mvo: what do you need from me to add an arch to apt?
[01:56] <cjwatson> StevenK: odd
[01:57] <cjwatson> StevenK: works now; weird
[01:57] <cjwatson> I just ran madison-lite by hand on rookery ...
[01:58] <cjwatson> I assume the cache was a bit buggered or something :-/
[02:00] <StevenK> cjwatson: Yes, quite odd.
[02:09] <mvo> Mithrandir: please check buildlib/archtable buildlib/sizetable
[02:10] <StevenK> cjwatson: Got a sec for a PM?
[02:11] <cjwatson> StevenK: sure
[02:13] <Mithrandir> mvo: can you just do it if I ask you to add lpia?
[02:14] <mvo> Mithrandir: sure, is it lpia lipia?
[02:15] <Mithrandir> mvo: sizelib should be like i386, arch name is lpia
[02:16] <Mithrandir> mvo: the triplet is gnulp-linux-i.86
[02:17] <cjwatson> has the triplet ordering changed?
[02:17] <cjwatson> it used to be i386-linux-gnu etc.
[02:18] <Mithrandir> this is the debian triplet, not the gnu triplet
[02:18] <Mithrandir> look at triplettable
[02:18] <cjwatson> ah
[02:21] <fabbione> cjwatson: the root of the problem is the kernel that doesn't init the cdrom. as result the cdrom-detect can't find one and loop. This happens only when checking the cd. I can go back to main-menu when using normal install. Not sure how checkcd preseed. i don't know that magic
[02:22] <cjwatson> it sets MENU=/bin/cdrom-checker-menu which causes a cdrom-checker helper script to be run instead of main-menu
[02:22] <cjwatson> it's not preseeding as such
[02:23] <fabbione> oh ok..
[02:23] <fabbione> not even sure if that's to be considered a bug
[02:23] <fabbione> it just makes it more difficult to check an error in that stage
[02:23] <cjwatson> an infinite loop is a bug ...
[02:24] <cjwatson> it ought to at least error and give up
[02:24] <fabbione> ok
[02:26] <pitti> Riddell, heno: Kubuntu alternates are up; lives will still take a while until the mess on the buildd settled down
[02:26] <pygi> who here would be ppc & sparc expert? I've got package failing to build in there :p
[02:26] <Riddell> pitti: thanks
[02:27] <fabbione> pygi: url to sparc build log?
[02:27] <pygi> fabbione, http://launchpadlibrarian.net/8004481/buildlog_ubuntu-gutsy-sparc.brasero_0.5.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[02:27] <pygi> I've actually got the error, but it builds fine on three other archs
[02:27] <pitti> heno: I enabled/disabled selections according to the current state
[02:28] <heno> pitti: great!
[02:28] <fabbione> pygi: looks like broken include.. try to follow the dependencies backwards
[02:29] <fabbione> pygi: and see why on sparc something is missing
[02:29] <pygi> fabbione, yea, but it works on other arches. /me needs to look it
[02:29] <heno> let me have feedback on the usability of that when you've used it a bit
[02:29] <fabbione> even on != sparc you can still grab sparc.deb and unpack it manually somewhere to look
[02:29] <pygi> I understand
[02:30] <pygi> fabbione, will try to locate, but ... not sure how much users use brasero on sparc & ppc anyway
[02:31] <fabbione> pygi: well up to you.. if it's in main it must be fixed
[02:31] <mvo> Mithrandir: what is the gnutriplet? this looks like the one that apt is looking at
[02:32] <pygi> fabbione, not main, but I'll see what I can do :)
[02:32] <pygi> fabbione, thanks for the heads up :)
[02:32] <fabbione> pygi: and if it is a system header that is broken, the error might hit other packages too.. still worth looking
[02:32] <fabbione> afaik there is a sparc available for MOTU's somewhere
[02:32] <fabbione> you might want to ask around
[02:32] <pygi> and what if I'm not a MOTU? :)
[02:33] <pygi> but sure, I'll see what I can do and fix it
[02:33] <fabbione> pygi: ebay.....
[02:33] <fabbione> :)
[02:33] <pygi> hehe :)
[02:33] <pygi> AFAIK, the error is weird. it doesn't seem to be related to any dependency, but rather to some weird "syntax error" ?
[02:34] <pygi> ./scsi/scsi-get-configuration.h:869: error: expected ',', ';' or '}' before 'uchar'
[02:34] <pygi> this would be the error
[02:35] <Amaranth> that means uchar is undefined
[02:36] <Amaranth> or you broke something higher up in the code
[02:36] <Amaranth> pygi: probably ./scsi/scsi-get-configuration.h:864: warning: no semicolon at end of struct or union
[02:37] <pygi> I didn't broke it, the uptream might :P
[02:37] <pygi> yea, I'll need to look into that =)
[02:37] <Amaranth> i thought you were upstream
[02:37] <pygi> of brasero? Nop, I just contribute and advise them here and there =)
[02:37] <pygi> I'm the libburnia upstream :P
[02:37] <pygi> (which builds fine everywhere btw :P)
[02:38] <Amaranth> hehe
[02:38] <Amaranth> i remember first seeing something about libburn in like 2004
[02:38] <Amaranth> or 2005
[02:38] <pygi> at that time, libburn could do nothing, and was dead :Pa
[02:38] <Amaranth> thought 'ooh, no more cdrecord bullshit'
[02:38] <Amaranth> the noticed it didn't do anything and forgot about it until brasero
[02:39] <pygi> it can now do all cd and dvd variants, but you have to consider dual layer is heavily untested =)
[02:39] <pygi> otherwise it works pretty fine :)
[02:39] <pygi> for libisofs, 6000 lines changed last week, implemented eltorito and a lot of nice reworking ^_^
[02:39] <Amaranth> yay
[02:41] <pygi> oh well, we still gotta walk a long way
[02:43] <pygi> Amaranth, I hope to get genisofs this year as well if all goes well :)
[02:49] <Mithrandir> mvo: like i386, but gnulp instead of gnu
[02:55] <slomo> mjg59: ping? (re gst-plugins-base alsa patch)
[03:02] <pitti> ogra: did you trigger live fs builds recently?
[03:02] <ogra> nope
[03:02] <ogra> i'm still watching virtualboox ...
[03:03] <ogra> its taking ages for the "please wait..." step in the end ...
[03:03] <pitti> ok; I wonder why king doesn't stop building livefses noone asked for
[03:03] <pitti> I want to build ones that actually get published :/
[03:03] <ogra> (sitting there sinc 1h or so but i need to see the ltsp setup after this so i'm still waiting)
[03:04] <ogra> pitti, infinitys realm iirc
[03:04] <pitti> ogra: yep, discussing with him
[03:05] <PriceChild> Hey, are there any archive admins around?
[03:05] <pitti> several
[03:06] <pygi> PriceChild, you got not only one, but several :P
[03:06] <PriceChild> (any that have a few minutes to help me? :P )
[03:06] <Hobbsee> PriceChild: helps if you say what about
[03:07] <Mithrandir> PriceChild: don't ask to ask, just ask your question.
[03:08] <PriceChild> Managed to get "gizmod" through revu. Since then noticed a problem in the debian/rules get-orig-source that managed to repackage it twice into the new tar.gz Since been fixed on revu, but gizmod is sitting in the queue and wondering whether someone should remove it?
[03:09] <Hobbsee> PriceChild: uploading the fixed version will tend to work
[03:09] <Mithrandir> PriceChild: just upload with a newer version number
[03:09] <Mithrandir> s/newer/higher/
[03:09] <PriceChild> Hobbsee, Mithrandir, ok cool thanks, just didn't wanna waste your time if the new version would have to be looked over completely again.
[03:19] <Mithrandir> mvo: so if that's all you need from me, please upload when the freeze ends
[03:19] <Mithrandir> doko: do you need anything from me to upload a new gcc with lpia support?
[03:21] <khaur> is there a valid reason for mozilla-mplayer package to depend on "mplayer", so that "mplayer-nogui" is not an alternative?
[03:30] <pygi> jdong, around? :P
[03:37] <fabbione> hmmmm
[03:37] <fabbione> who is the archive admin in service today?
[03:38] <Hobbsee> fabbione: pitti iirc
[03:38] <fabbione> ok :)
[03:38] <pitti> would be seb128, but he's on vac
[03:38] <fabbione> pitti: could check where my system-config-cluster upload vanished?
[03:38] <pitti> fabbione: I can do some quick things for you, but nothing really large
[03:38] <fabbione> pitti: i did it yesterday i believe...
[03:38] <pitti> fabbione: no, it's in unapproved
[03:38] <pygi> pitti, he's on vac?!
[03:38] <fabbione> why unapproved?
[03:39] <pitti> fabbione: noone pinged me about pushing it into tribe-1, so I didn't care (people upload all sorts of post-tribe main stuff)
[03:39] <fabbione> pitti: oh sorry....
[03:39] <pitti> fabbione: archive is frozen
[03:39] <fabbione> my bad
[03:39] <fabbione> yes that's fine
[03:39] <fabbione> no need for it for tribe 1 and it's not on CD afair
[03:40] <fabbione> sorry about that... it did slip from my mind
[03:40] <fabbione> thanks for checking
[03:40] <pitti> np :)
[03:42] <pitti> fabbione: do you have some time for testing the other server CDs?
[03:43] <fabbione> pitti: not for today... sorry. they will have to wait tomorrow morning
[03:44] <pitti> ok
[03:44] <fabbione> probably later this night if my wife crashes... but it's our 3rd anniversary so i doubt i will be back
[03:45] <fabbione> or 4th..
[03:45] <fabbione> anyway i am off for now
[03:45] <fabbione> ttyl
[03:46] <pitti> fabbione: oh, enjoy!
[03:46] <doko> Mithrandir: no, but I would like to see the triplet changed to have i686 included by default
[03:46] <ogra> pitti, hrm, i gave up on that test install now
[03:47] <Mithrandir> doko: have you had any feedback from intel on that?
[03:47] <pitti> ogra: what's wrong?
[03:47] <mvo> Mithrandir: on the phone right now, but it may require some massaging into the build system
[03:47] <doko> Mithrandir: that was proposed by an intel engineer
[03:47] <ogra> pitti, no idea, was there a prob with pkgsel in 06 that was fixed in 06.1 ?
[03:48] <Mithrandir> doko: can you just do it, then?
[03:48] <ogra> it hung at pkgsel for more than 1h ... might be virtualboox slowness though
[03:48] <doko> i386 is definitely wrong, when used unmodified for configuring packages.
[03:48] <ogra> i'm retrying without network since thats usually faster
[03:48] <doko> Mithrandir: ok, will do after the freeze ends
[03:49] <pitti> ogra: I doubt it
[03:49] <ogra> then i blame virtualbox
[03:50] <Mithrandir> doko: thanks.  Care to drop me a mail when it happens?
[03:50] <ogra> lets see how this one goes
[03:50] <Mithrandir> mvo: it's going to require byhand bootstrapping, but that's fine
[03:50] <ogra> the sad part is that i couldnt get to the ltsp stuff yet ... debian insisted that it has an installer prio of 7000 .... i'll have to change taht again, its taking way to long during testing
[03:58] <pochu> Do we need transitional packages until the next LTS? If I set up conflicts/replaces/provides, the packages upgrades fine without them.
[03:59] <pitti> pochu: that are two questions in one
[03:59] <pitti> pochu: (1) if a transitional package applies to a transition started in dapper, it needs to stay until next LTS
[04:00] <pitti> pochu: (2) if you merge two packages, or the obsolete one is a libray, then you usually don't need a transitional package at all
[04:01] <pochu> Well, it's a engine for liferea, but now it's integrated in the liferea package, so the C/R/P should be enough, right?
[04:02] <pitti> Hobbsee, Riddell: kubuntu desktop CDs are up and now enabled in isotesting; test away :)
[04:03] <Riddell> thanks
[04:03] <pitti> cjwatson: I am doing an expert install with LVM; the menu only offers me to install lilo, no grub; is that a bug, or doesn't grub know how to boot stuff on LVM?
[04:04] <cjwatson> pitti: the latter, AIUI
[04:04] <cjwatson> ogra: 7000 sounds correct
[04:05] <cjwatson> ogra: all installer-menu-items are to be multiplied by 100 in gutsy (most already have been)
[04:05] <ogra> cjwatson, not if i want it directly after base install
[04:05] <ogra> as we had it before debian intervened
[04:05] <cjwatson> ogra: base-installer = 6500
[04:05] <cjwatson> next things are apt-setup and pkgsel at 7000
[04:05] <ogra> and pkgsel ?
[04:05] <ogra> aha
[04:05] <ogra> so 6800 would be for me then
[04:05] <cjwatson> admittedly if you set ltsp as 7000 then the ordering is probably undefined
[04:05] <cjwatson> 6800 sounds fine
[04:06] <ogra> its just silly to have to wait for the whole install to finish to find my errors ...
[04:06] <ogra> burns a lot of time
[04:06] <cjwatson> sure
[04:06] <cjwatson> ogra: there's a known pkgsel hang with some network (mis?)configurations
[04:07] <cjwatson> it sits there waiting for apt-setup
[04:07] <Mithrandir> pitti: any chance for a NEW processing of osso-gwconnect (binary NEW)
[04:07] <cjwatson> if the hang you're seeing is at 85%, that is; if it's right at the start of pkgsel, it might be a weird racy debconf-apt-progress/dpkg-preconfigure interaction that we're still trying to figure out
[04:07] <ogra> cjwatson, heh, ok, then my guess was right
[04:08] <ogra> this insrtall should get through
[04:08] <ogra> well, i had an interface up but no ip forwarding for the virtualbox i'm running
[04:08] <ogra> so its not properly timing out
[04:08] <cjwatson> yes, so apt-get update will hang
[04:13] <shawarma> I'm working on a package that wants to use a special dhclient-script, but our deroot-client magic makes it unable to do anything even remotely useful.. Has this been worked around before for some other package, perhaps?
[04:13] <pitti> ok, amd64 desktop+alternate all PASS here
[04:13] <pitti> can someone please test the i386 ubuntu images?
[04:14] <pitti> Mithrandir: hmmkay
[04:15] <Mithrandir> cheers
[04:16] <pitti> Mithrandir: there's no init script and nothing in /etc/dbus/event.d (deprecated) either; is that right?
[04:16] <Mithrandir> pitti: yes, AIUI
[04:16] <pitti> Mithrandir: ah, nevermind me, it's a .service
[04:16] <pitti> didn't notice those two
[04:16] <Mithrandir> pitti: I must confess to not really having tested the package since I'm so far just using it as a build-dependency
[04:17] <pitti> heh :)
[04:17] <pitti> Mithrandir: accepted; do you want a publisher run for those, or is it not urgent?
[04:18] <Mithrandir> a publisher run before tomorrow would be fine
[04:19] <pitti> Mithrandir: alright, no problem that
[04:20] <Mithrandir> so "yes, a publisher run would be good, but I don't need it right now"
[04:21] <pitti> shawarma: not right now, since the path is hardcoded; if we need that, we need to hack it into dhcp-client itself
[04:23] <pitti> Mithrandir: so, *shrug*, I don't need buildds and soyuz for anything else right now, so I just run it now before I forget
[04:23] <shawarma> pitti: You mean like a hardcoded exception?
[04:23] <pitti> shawarma: more like a sane way how to modify
[04:23] <Mithrandir> pitti: or just turn it back on auto
[04:23] <shawarma> pitti: Ah.
[04:24] <pitti> Mithrandir: hmm as long as noone gives back packages in main etc. that shouldn't hurt
[04:25] <Mithrandir> pitti: and worst case, the archive and the CDs don't match, which is not really a big deal.
[04:25] <pitti> Mithrandir: well, I'm afraid of archive desync if we need to rebuild CDs
[04:26] <shawarma> pitti: On my test installation I've hacked it to call its argv[1]  and hacked dhclient accordingly, but that renders a lot of the derooting useless, I think.
[04:26] <pitti> but the only way that comes to my mind how to circumvent unapproved is give-back; do you know another one?
[04:26] <pitti> shawarma: right :)
[04:26] <pitti> shawarma: it's not actually that easy without hardcoding
[04:27] <pitti> shawarma: OTOH, I don't really sit on the derooting patch; dhcp3 hasn't had many vulns in the past, and if it blocks development, we can revert it at least temporarily
[04:27] <pitti> shawarma: I sent it to upstream years ago, but they don't seem to be too keen adopting it
[04:27] <shawarma> pitti: Oh, I thought it was yours.
[04:27] <pitti> shawarma: it was, right
[04:28] <Lure> heno: bugs in iso tracker: just release critical should be listed or any (for example HW specific issue (but know workaround) that prevent install)
[04:29] <shawarma> pitti: Ok. Hum... Well, my hack at least doesn't leave anything with root privs listening on an open socket.
[04:30] <shawarma> pitti: But still..
[04:30] <pitti> shawarma: right, but the point is, if someone can execute code as dhcp user in the daemon and then can coerce the suid wrapper to execute an arbitrary script instead of the hardcoded client script, then the derooting doesn't help you
[04:31] <pitti> shawarma: with the hardcoding, all he can do is to change the network configuration (which is something you cannot take away from dhcp client)
[04:31] <shawarma> pitti: Well, dhclient.conf is root-writable only, so if the suid-wrapper could read the dhclient script from the config file, that would plug it somewhat.
[04:31] <shawarma> pitti: :) Clearly.
[04:31] <pitti> shawarma: right, that's what I tought as well
[04:32] <shawarma> pitti: It doesn't solve the pass-an-alternative-dhclient-script-on-the-command-line use case, but it's good enough for my use.
[04:38] <pitti> ogra: edubuntu live CD is up, but it is oversized by two bytes or so
[04:38] <ogra> gah
[04:39] <pitti> no idea why, the previous one was good
[04:39] <pitti> ogra: can you please chop off a bit of them and update the seeds?
[04:40] <ogra> +ohew
[04:40] <ogra> *phew
[04:45] <ogra> pitti, do you think 2M will suffice ?
[04:46] <pitti> ogra: yes, i386 is 701 MB, amd64 700 MB
[05:00] <pitti> heno: https://wiki.ubuntu.com/Testing/ReportingResults is now pretty much obsolete, right? we should direct people to the iso test tracker in the annoucement now, I think
[05:00] <pitti> heno: however, that depends on whether the iso tracker will accept tests of dailies
[05:01] <pitti> heno: erm, no; I mean, accept tests after tribe has been released
[05:02] <pitti> ogra: done with the seed changes?
[05:02] <ogra> just running the update script
[05:02] <ogra> uploading in a second
[05:03] <pitti> ogra: hm?
[05:03] <pitti> ogra: oh, noo
[05:04] <pitti> ogra: I thought you would only need to change live, not desktop
[05:04] <pitti> ogra: can't we chop off a langpack?
[05:04] <ogra> hmm, indeed ....
[05:04] <ogra> how do i uncommit remotely :P
[05:05] <pitti> bzr diff -r -2 | patch -Rp1 :)
[05:05] <ogra> well, that wont wipe the history :)
[05:05] <Hobbsee> bzr has an uncommit function, too.
[05:05] <Hobbsee> dunno where remotely fits in, though
[05:05] <Hobbsee> heh
[05:05] <pitti> ogra: there is bzr push --overwrite, but I wouldn't use it for such official repos
[05:05] <ogra> right
[05:05] <ogra> i'll just revert it in a new commit
[05:06] <pitti> I used it in the past with --overwrite on LP branches, works fine, but only on private branches
[05:06] <ogra> hmm, whom do i upset now ...
[05:07] <pitti> xubuntu desktop CDs up
[05:10] <Hobbsee> ogra: haha.  nice reasoning.
[05:10] <ogra> pitti. ok, seeds fixed ...
[05:11] <pitti> ogra: thanks, building livefs then
[05:15] <Lure-live> pitti, Riddell: kubuntu desktop: ubiquity crashed on manual partitioning, followed by crash of apport
[05:16] <Lure-live> apport crash is in bug 118965, I will submit ubiquity bug manually
[05:16] <ubotu> Launchpad bug 118965 in apport "apport-qt crashed with IOError in get_module_license()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118965
[05:16] <pitti> Lure-live: erk, apport itself crashed?
[05:16] <Riddell> Lure-live: I just got the same
[05:17] <Riddell> ubiquity doesn't actually crash though, it recovers fine
[05:17] <Lure-live> pitti: right, I got ubiquity crashed (even though partitioner window is still up!), then selected to report and apport-qt crashed
[05:17] <pitti> "IOError: [Errno 4]  Interrupted system call", WTF
[05:17] <Lure-live> Riddell: exactly
[05:17] <pitti> I thought I fixed that some months ago in Python
[05:17] <Lure-live> Riddell: so no need to report as you are on it? ;-)
[05:18] <Lure-live> pitti: maybe your patch was dropped by merge
[05:18] <pitti> Lure-live: no, I see it now: I only caught this situation in subprocess itself
[05:19] <pitti> Lure-live: please wait before filing manually
[05:19] <Lure-live> pitti: no problem
[05:19] <pitti> Lure-live: if you do 'sudo touch /var/crash/*ubiquity*', it should re-trigger apport; does it work then?
[05:19] <pitti> Lure-live: I'll change the apport code to use the guarded subprocess functions, that should help
[05:19] <pitti> but preferably not for tribe-1
[05:20] <Lure-live> pitti: nothing happens after tounc
[05:20] <pitti> Lure-live: hmm
[05:21] <Lure-live> pitti: there is /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash though
[05:21] <pitti> Lure-live: right, but *ubiquity* should match on that
[05:22] <Lure-live> pitti: I think ubiquity "crash" (which is not actually) is more problematic, but could be also only documented for tribe1 I suppose
[05:22] <pitti> Lure-live: right, but we want a proper bug report for it
[05:23] <pitti> Lure-live: "sudo touch /var/crash/*ubiquity*; sudo /usr/share/apport/apport-qt" should re-process the crash in apport
[05:23] <Lure-live> pitti: I can open that with apport files manually attached (if Riddell is not doing it already)
[05:23] <Riddell> Lure-live: go ahead
[05:23] <pitti> Lure-live: right, but with above command it might be easier
[05:23] <Lure-live> pitti: ok, now I got it
[05:24] <pitti> Lure-live: so ubiquity actually continues to work?
[05:24] <Riddell> pitti: yeah, no problem actually visible to the user
[05:25] <pitti> Riddell: cool, so we'll only release-note this
[05:25] <Lure-live> pitti: yes - it passed the parition step, will try to complete install after I submit this bug
[05:25] <Riddell> fine with me
[05:25] <pitti> I did a manual-partitioning Ubuntu install without a problem here, hmm
[05:27] <Lure-live> pitti, Riddell: bug 118967
[05:27] <ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118967
[05:27] <Lure-live> will continue installation now
[05:27] <pitti> Lure-live: thank you! can you please add that to the bug list in the iso tracker as well?
[05:27] <Lure-live> pitti: will do
[05:27] <pitti> Lure-live: *hug*, thanks
[05:28] <pitti> Riddell: seems KDE specific, I assing this to you if you don't mind
[05:28] <Riddell> pitti: ok
[05:29] <Riddell> although if evand fancies taking a look at it..
[05:29] <pitti> Riddell: oh, sure :)
[05:29] <pitti> Riddell: delegation is a chain with more than one element :-P
[05:29] <Lure-live> pitti: ;-)
[05:30] <evand> will do
[05:30] <Lure-live> can somebody pass isotracker URL?
[05:30] <pitti> Lure-live: see topic
[05:30] <pitti> I just wrote some details to ubuntu-devel@, too
[05:30] <Hobbsee> https://isotesting.stgraber.org/
[05:31] <Lure-live> pitti, Hobbsee: thanks
[05:36] <Lure-live> pitti, Riddell: https://isotesting.stgraber.org/isotesting/result/36/54
[05:36] <Hobbsee> desrt: you live in a decent country.
[05:36] <Hobbsee> desrt: the au shoestring broke last night.  au is not good for a tech place.
[05:36] <pitti> Hobbsee: heh, I got the '80% of quota limit' mail a few hours back
[05:36] <desrt> Hobbsee; is that a figure of expression or did something actually break?
[05:37] <Hobbsee> desrt: oh it broke.
[05:37] <desrt> like your cable that plugs you into the rest of the net?
[05:37] <Hobbsee> desrt: http://www.smh.com.au/news/wireless--broadband/telstra-restores-service-after-broadband-meltdown/2007/06/06/1181089114356.html
[05:37] <Hobbsee> the isp broke
[05:38] <desrt> ah
[05:38] <ogra> and i only need to know if the ltsp step works, grumble
[05:38] <desrt> Hobbsee; no... i mean the big undersea cable from australia to [world]
[05:38] <desrt> Hobbsee; i imagine you can't fix that one very easily :p
[05:39] <Hobbsee> hehe
[05:39] <Hobbsee> true that
[05:39] <desrt> a friend of mine works for my ISP
[05:39] <desrt> they track badnwidth use... but don't do anything about it
[05:40] <desrt> supposedly they have this guy that regularly pushes (sometimes exceeds) 1TB monthly use
[05:40] <desrt> they called him up once
[05:40] <desrt> he's like "ya.. i do a lot of downloading"
[05:40] <desrt> they were like "cool.  just making sure it wasn't a virus or anything"
[05:41] <desrt> it's really really unlimited.... even if you're an abusive prick :p
[05:42] <Hobbsee> hehe
[05:53] <heno> pitti: yes, that's obsolete (cleaning up test pages in the wiki is on my list ...) We can take test feedback on the tracker under the name 'Tribe 1' after release
[05:53] <pitti> heno: great, thanks
[05:54] <pitti> heno: I announced a call for testing on ubuntu-devel@, now all images are complete
[05:54] <ogra> grmbl
[05:54] <heno> pitti: great, thanks
[05:54] <pitti> ogra: edubuntu live up now as well, but WTF? still oversized
[05:55] <ogra> erm, dont i need to rebuild -meta ?
[05:55] <pitti> ogra: seems it didn't actually pick up the branch changes
[05:55] <pitti> ogra: no, not for live
[05:55] <ogra> i'm always unsure about that at the start of a cycle ...
[05:56] <ogra> according to LP its in the branch ...
[05:56] <ogra> so we'll likely only need another livefs
[05:56] <pitti> ogra: you only dropped it for amd64
[05:56] <pitti> ogra: well, 20070606.2 is the new livefs that was just built
[05:57] <ogra> oh crap
[05:57] <pitti> ogra: hm, tricky, on i386 you do not have any more language packages to drop
[05:57] <ogra> i386 doesnt have any langpacks
[05:58] <pitti> ogra: but still, amd64 is oversized too, so why didn't it pick up the branch changes...
[05:58] <pitti> ogra: ok, then I guess we have to go through removing arabeyes and rebuild -meta *sigh*
[05:59] <pitti> ogra: please upload edubuntu-meta, I'll shove it through publisher and buildds
[05:59] <ogra> pitti. if you are sure amd64 will be fine i can easily drop all gcompris-sound packs for now
[05:59] <ogra> they are i386 only
[05:59] <ogra> and only in live
[06:00] <ogra> i dont care about that stuff for a first milestone
[06:00] <pitti> ogra: I'm not
[06:00] <pitti> ogra: the recent livefs build didn't pick up the seed change, no idea why
[06:00] <ogra> ok, but since we'll have to convice iut somehow to do that, we can assume amd64 will be fine then ...
[06:01] <ogra> dropping the sounds will save us the -meta rebuild
[06:01] <pitti> ogra: ok, fine for me
[06:02] <ogra> ok, pushing
[06:02] <pitti> ogra: hmm, http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/edubuntu/gutsy/daily-live-20070606.2.log does have the removal of -pt, no idea
[06:03] <pitti> ogra: ok, rebuilding fs
[06:18] <cjwatson> Riddell: ubiquity> hmm, doesn't seem like that ought to be a new bug in gutsy
[06:18] <cjwatson> Riddell: but go ahead and check it straight into trunk if you find a fix
[06:19] <Riddell> cjwatson: evand seems to be having first shot at finding it
[06:19] <cjwatson> good-oh
[06:22] <evand> indeed, though the iso is taking its sweet time to download and it appears to be qt-specifc.
[06:24] <cjwatson> about all I can say is that it looks like an empty list, but no idea why
[06:46] <Keybuk> oh, wow
[06:46] <Keybuk> Fedora hardcode the name of the root disk into their initramfs
[06:47] <pitti> ogra: something is absolutely wrong here: http://cdimage.ubuntu.com/edubuntu/daily-live/20070606.3/
[06:47] <pitti> ogra: still oversized
[06:47] <pitti> *W* *T* *F* ??
[06:47] <wasabi> Keybuk: Eh, how can you manage that?
[06:48] <Keybuk> wasabi: ?
[06:48] <pitti> ogra: oh, wait; I guess there is a second CD, and CDimage probably just cap'ed the first one too big as well?
[06:48] <wasabi> hard coding the root disk name?
[06:48] <wasabi> That seems impossible to actually make work
[06:49] <Keybuk> wasabi: it's in their init script hardcoded
[06:49] <wasabi> What is? /dev/hd or /dev/sd?
[06:49] <Keybuk> /dev/VolGroup00/LogVol00
[06:49] <wasabi> oh. Hah.
[06:49] <wasabi> They use lvm by default?
[06:49] <Keybuk> seems so
[06:49] <wasabi> Nifty. We should do that. :0
[06:50] <pitti> ogra: hmm, no; http://cdimage.ubuntu.com/edubuntu/daily-live/20070606.3/gutsy-desktop-amd64.manifest still has the pt langpack and gcompris-sound
[06:50] <Keybuk> wasabi: I have zero objection to lvm-by-default
[06:50] <Keybuk> it's evms that keeps me awake at night <g>
[06:50] <wasabi> What about removing lvm and md and using evms by default? :)
[06:51] <wasabi> That'd be my vote.
[06:51] <Keybuk> wasabi: evms doesn't work with 2.6
[06:51] <Keybuk> so BZZZT
[06:51] <wasabi> Doesn't work without hacks anyways
[06:51] <Keybuk> where hacks = patching out kernel features
[06:51] <wasabi> Hey, why is that anyways?
[06:52] <Keybuk> actually, evms-like-features should be in the kernel
[06:52] <wasabi> Some new thing that only allows one subsystem to control a block device or something?
[06:52] <wasabi> evms doesn't actually rally have any features. It does everything with md and lvm and devmapper
[06:52] <Keybuk> only one thing may claim one block device at once
[06:52] <Keybuk> e.g. you can't mount it twice
[06:52] <wasabi> Okay, evms doesn't cause an issue with that.
[06:52] <wasabi> Just... don't mount it with anything else
[06:52] <wasabi> remove the kernel partition table support and you're golden
[06:52] <Keybuk> it really screws over people who have evms installed and don't want to use it
[06:52] <Keybuk> for anything
[06:52] <Keybuk> you have to use it for *everything*
[06:53] <Keybuk> even USB devices
[06:53] <wasabi> Well, yeah, but that doesn't really *use* evms
[06:53] <wasabi> alll evem does is construct devmapper nodes for the partitions
[06:53] <wasabi> Which is arguably better done by evms using devmapper anyways
[06:53] <wasabi> evms has no kernel presense.
[06:54] <Keybuk> which doesn't work if the partition is being mounted
[06:54] <pitti> ogra: seriously, I'm at loss with this; we should figure this out with cjwatson
[06:54] <wasabi> Keybuk: Which partition?
[06:54] <Keybuk> wasabi: on the USB stick
[06:54] <Keybuk> wasabi: tbh, my absolute major concern with evms is that nobody appears willing to maintain it
[06:54] <wasabi> Huh?
[06:54] <Keybuk> or fix some of its fundamental problems
[06:55] <Keybuk> which means it's utterly out as a default option
[06:55] <Keybuk> and shouldn't even be in main!
[06:55] <wasabi> Yeah, that's my major problem too. It's not any sort of priority for anybody.
[06:55] <wasabi> (ya'll)
[06:55] <Keybuk> wasabi: that includes community members <g>
[06:55] <wasabi> uh huh
[06:56] <wasabi> You know that the kernel hack goes away if you use evms to construct all partition s(even for usb disks) from user space, right?
[06:56] <wasabi> The problem is /dev/sda1 and /dev/evms/sda1 both existing.
[06:56] <Keybuk> right
[06:56] <wasabi> So simply remove /dev/sda1, and link it to /dev/evms/sda1
[06:56] <Keybuk> the problem is also that /dev/evms/sda1 exists at all
[06:56] <Keybuk> since that means evms is trying to manage /dev devices
[06:56] <Keybuk> it should leave that to udev
[06:56] <pitti> cjwatson: edubuntu live was oversized suddenly, so ogra first dropped the pt langpack off amd64 (in 20070606.2) and then gcompris-sound-* from i386 (in .3); yet, those packages still appear on the live systems
[06:57] <wasabi> Yes, a bug that should be fixed. :)
[06:57] <wasabi> You're not forced to usr /dev/evms though, you can use /dev/mapper
[06:57] <pitti> cjwatson: does anything need to happen to the seeds (mirroring somewhere etc.) before cdimage picks them up?
[06:57] <Keybuk> wasabi: it's just a general indication of its evilness
[06:57] <wasabi> It's a general indication of it's less than well maintained-ness.
[06:58] <wasabi> Didn't used to have udev
[06:58] <wasabi> Do you think it sucks as a technology though?
[06:58] <pitti> cjwatson: my guess is "no", since the the logs do show the diff of the seeds in "Checking for other task changes"; however, at the end the packages are still there
[07:00] <Keybuk> wasabi: I think that evms should be un-necessary
[07:00] <wasabi> Why?
[07:00] <Keybuk> ie. the kernel should present "disks", and we should be able to allocate block devices on those however we want
[07:00] <wasabi> I don't follow.
[07:00] <Keybuk> ZFS style
[07:01] <wasabi> Oh.
[07:01] <Keybuk> evms is a huge amount of code to work around the fact that the kernel doesn't do it by default
[07:01] <wasabi> I don't really think that. I think evms is just a pretty interface and API to what the kernel already does.
[07:01] <iwj> Dammit, how long does it take libc to build ?
[07:01] <wasabi> I don't really think pretty API and interface belong in the kernel...
[07:02] <Keybuk> wasabi: it didn't seem that pretty to me
[07:02] <wasabi> The API?
[07:02] <Keybuk> devmapper seemed easier to understand
[07:02] <wasabi> evms *is* devmapper
[07:02] <wasabi> wait... let me rephrase
[07:02] <wasabi> what about pumping mapping characters into devmapper do you find pretty?
[07:02] <Keybuk> I don't need to, LVM seems to do taht
[07:03] <iwj> Keybuk: Did you get a chance to look at my new disk full testing spec ?
[07:03] <wasabi> So you think raid and lvm should be integrated?
[07:03] <Keybuk> iwj: not yet, sorry
[07:03] <Keybuk> wasabi: sure
[07:03] <ogra> pitti. dinner time for me, i'll look through the logs afterwards, there must be something in there
[07:03] <Keybuk> I just think we should have disks and filesystems
[07:03] <pitti> ogra: I need to leave soon as well
[07:04] <pitti> ogra: ok, will you care for this?
[07:04] <Keybuk> "give me a 4GB mirrored filesystem" => then let the $something worry about how it gives it to you
[07:04] <wasabi> I guess I'd agree.... I just don't think what you want is going to happen in the next 10 years.
[07:04] <pitti> ogra: not sure whether you'd want to release edubuntu live oversized...
[07:04] <wasabi> And I think evms is a much better solution to typing mdadm and lv* commands until then.
[07:04] <cjwatson> pitti: live seed changes require edubuntu-meta uploads
[07:04] <ogra> pitti. i'll care, dont worry, its not the end of the world to skip one flavor for one iso with the first milestone
[07:04] <cjwatson> pitti: and then a livefs rebuild after that's been published
[07:05] <pitti> cjwatson: erk, since when is that?
[07:05] <cjwatson> pitti: since ages
[07:05] <ogra> cjwatson. hah, damned, i'm always unsure if we start a new cycle
[07:05] <cjwatson> there is a brief delay in seed propagation, but as you say it doesn't sound like that
[07:05] <iwj> Keybuk: IWBNI you could at least skim it to see if it was the kind of thing you were after ...
[07:06] <ogra> pitti. updating the package
[07:06] <pitti> cjwatson: hm, I was never aware of rebuilding -meta whenever I dropped langpacks
[07:06] <Keybuk> iwj: sorry, I've been swamped by a zillion things the last couple of days.  it is high on my priority list
[07:06] <pitti> ogra: ok, if that helps; neither edubuntu-desktop nor -server sound matching for a change of the 'live' seed, so I wasn't sure
[07:07] <wasabi> I sort of like EVMS's potential to allow commercial people to write plugins for it too... it's not just restricted to md and lvm... you can write a plugin to manage your... oh, Adaptec Card. And the abilities of hte card will integrate into the interface.
[07:07] <iwj> Keybuk: Fair enough.
[07:07] <wasabi> And expanding and shrinking operations will take everything into account, the file system, the adaptec card, the lvm stuff ontop of that.
[07:08] <pitti> cjwatson: out of interest, how can the 'live' seed affect -meta?
[07:13] <iwj> Oh well, I'll let this build go on overnight.
[07:14] <pitti> ogra, cjwatson: as I suspected: 'no changes found' when updating edubuntu-meta, and the seed update propagated correctly
[07:15] <pitti> ogra: this must be something else
[07:15] <pitti> but I really gotta leave now, sorry
[07:16] <Lure> pitti: btw, similar install on desktop (also manual partitioning) -> no false ubiquity crash reported
[07:16] <Lure> pitti: I suspect that crash is related to same partition setup
[07:17] <Lure> s/same/some/
[07:20] <ogra> pitti. its fine, i'll deal with it
[07:21] <pitti> ogra: thanks; I just hate to not understand the reasons for such things :/
[07:33] <Keybuk> how do I change a gconf key default?
[07:33] <ogra> Keybuk. add an override file
[07:34] <ogra> add /usr/share/gconf/defaults/20-sottslittlesectres :)
[07:34] <ogra> gah, cant type
[07:34] <Keybuk> s'ok found it
[07:35] <ogra> ogra@laptop:~$ cat /usr/share/gconf/defaults/20-edubuntu
[07:35] <cjwatson> ogra: (and pitti, but he's gone) oh, argh, I'm really sorry, I misremembered - we took live *out* of -meta a while back
[07:35] <ogra>  /desktop/gnome/interface/icon_theme gartoon
[07:35] <ogra> etc ertc
[07:35] <dholbach> debian/gconf-defaults
[07:35] <cjwatson> ogra: it could be that pitti forgot a livefs rebuild, I'm not sure
[07:35] <ogra> cjwatson. hmm, i'll ask infinity for one then and do an iso rebuild
[07:36] <ogra> or can somebody else trigger that too nowadays
[07:36] <ogra> ?
[07:37] <ogra> infinity. ping ? can you do an edubuntu livefs build for me ?
[07:43] <alex-weej> does anyone know how to debug USB mass storage? it appears that two separate Nokia 5300s (exchanged by courier for another reason) are not playing nicely with Feisty
[07:44] <alex-weej> they work fine when browsing with a file manager, but if you let Rhythmbox scan the whole volume (i.e. if you have Rhythmbox running when it connects) , it hangs for a minute or so and then eventually pops up an "unsafe device removal" warning
[07:47] <cjwatson> ogra: you can
[07:47] <cjwatson> ogra: cdimage@lithium$ buildlive edubuntu
[07:47] <cjwatson> it's in the crontab there
[07:47] <ogra> oh, great, since when is that ?
[07:48] <cjwatson> Date: Tue, 23 Jan 2007 12:04:31 +0000
[07:48] <cjwatson> From: Colin Watson<EMAIL_ADDRESS>[07:48] <cjwatson> To: Jonathan Riddell<EMAIL_ADDRESS>[07:48] <cjwatson>         Oliver Grawert<EMAIL_ADDRESS>[07:48] <cjwatson> Subject: Building live filesystem images
[07:48] <cjwatson> since then ;-)
[07:48] <ogra> oops
[07:51] <pygi> hey folks!
[07:51] <bryyce> heya
[07:52] <tseliot> hi
[08:01] <cjwatson> NonfreeKernelModules: cdrom
[08:03] <pygi> fabbione, have a sec?
[08:03] <fabbione> pygi: 1
[08:03] <fabbione> your time is up
[08:03] <fabbione> :)
[08:03] <pygi> fabbione, hehe :)
[08:03] <pygi> fabbione, wanted to find out where can I find build log of i386, so I could compare if something's missing :)
[08:04] <pygi> (build log for brasero i386 ofcourse :))
[08:04] <fabbione> pygi: they should be on LP...
[08:04] <pygi> fabbione, got that, don't know where tho o.O
[08:05] <fabbione> pygi: you are really begging me to send you to google... aren't you? :)
[08:05] <pygi> fabbione, but my friend, I already used the google! :)
[08:05] <elmo> I hate kernel modules - when they're elided they trigger my nick highlighting :-/
[08:06] <pygi> ha, found it =)
[08:06] <pygi> fabbione, sorry for taking your time ;)
[08:06] <fabbione> http://launchpadlibrarian.net/8004448/buildlog_ubuntu-gutsy-i386.brasero_0.5.90-0ubuntu1_BUILDING.txt.gz
[08:06] <pygi> fabbione, thanks, found it ^_^
[08:06] <fabbione> pygi: do i get a beer? do i get a beer? :)
[08:06] <pygi> fabbione, when I meet you, sure =)
[08:07] <fabbione> ok cool...
[08:07] <pygi> just remind me, it might take a while :P
[08:07] <fabbione> :)
[08:07] <pygi> lol :)
[08:08] <pygi> fabbione, why do you think I'm lazy? :P
[08:11] <fabbione> pygi: dunno... my female instinct
[08:12] <pygi> I wouldn't rework 6000 lines of code in a week if I was lazy :P
[08:14] <Riddell> BenC: the MCE guy with the nvidia problem says he isn't using a hand made install but its down to the wrong module loading, does that seem plasuable? http://paste.ubuntu-nl.org/24459/
[08:19] <pygi> fabbione, ha! Think I got it :)
[08:20] <fabbione> pygi: i can change 6000 lines of code in 2 minutes... wanna bet? :P
[08:20] <fabbione> while read line | sed....
[08:20] <fabbione> ;)
[08:20] <pygi> fabbione, I don't count indent, sorry :)
[08:20] <pygi> meh, I reworked core components, and the way it works :(
[08:20] <fabbione> just teasing...
[08:20] <pygi> fabbione, do you have access to sparc/ppc? there's two lines fix I wanna try :)
[08:21] <fabbione> sparc.. probably... ppc no
[08:21] <pygi> yay :)
[08:21] <fabbione> but not right now.. send me the patch and i will test it tomorrow
[08:21] <pygi> oki doki ^^
[08:21] <fabbione> it's evening and i don't feel like powering on a nuclear reactor
[08:21] <pygi> sure, don't worry
[08:21] <fabbione> the small one at the moment doesn't really boot...
[08:21] <fabbione> did play a bit too much
[08:21] <pygi> hehe
[08:22] <pygi> isn't too important right now, don't worry :)
[08:22] <pygi> I found lines that really don't have ";" at the end
[08:22] <pygi> weird that other arches ignore it tho
[08:34] <ogra> cjwatson. hmm, it doesnt get picked up, the iso is still oversized
[08:37] <ogra> cjwatson. i see a lot moaning about duplicated seeds of gcompris-sound packages in edubuntu/daily-live-20070606.4.log
[08:38] <ogra> which are supposed to be not in the livefs anymore ... could there be something wrong with the ship-addon hack ?
[09:25] <cjwatson> ogra: it does need a publish run before you start the livefs build
[09:25] <cjwatson> because it has to propagate into the Task headers in the Packages files
[09:25] <cjwatson> ogra: which packages in particular?
[09:26] <cjwatson> ogra: ship-addon has no effect on live
[09:26] <cjwatson> unless somebody has been messing with STRUCTUE
[09:26] <cjwatson> +R
[09:26] <ogra> gcompris-sound-it gcompris-sound-pt gcompris-sound-ru gcompris-sound-sv gcompris-sound-es gcompris-sound-fr   gcompris-sound-de
[09:27] <ogra> yeah, that was just a silly guess out of desparation
[09:27] <ogra> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/edubuntu/20070606.6/livecd-20070606.6-i386.out still has all of them
[09:27] <ogra> thats the last i386 build ...
[09:32] <cjwatson> ogra: oh, argh, I see what's happened
[09:32] <cjwatson> ogra: there were no packages to publish for gutsy (because we're frozen), so the publisher skipped it
[09:32] <ogra> ouch
[09:33] <cjwatson> which meant it didn't apply the germinate changes either
[09:33] <cjwatson> ogra: I've worked around this by accepting a few universe uploads
[09:33] <ogra> ok
[09:34] <cjwatson> ogra: so in about an hour's time when the next publisher run has finished, you should be able to kick off YA livefs build
[09:34] <ogra> so the next build should pick it up ?
[09:34] <ogra> oki
[09:34] <ogra> is that something pitti should know ?
[09:34] <cjwatson> be careful to wait that hour though; it definitely won't work before then
[09:34] <cjwatson> yes, it's also something that should be fixed in soyuz
[09:34] <cjwatson> I mean, it's something pitti should be told, not necessarily something he should have been expected to know
[09:35] <ogra> well, thats what i meant
[09:35] <cjwatson> I know, just realised it was ambiguous
[09:35] <ogra> i didnt expect him to know :)
[09:36] <ogra> it was rather a bad way of saying "that should be in the readme" :)
[09:36] <bryyce> glatzor: heya
[09:36] <cjwatson> it should be fixed
[09:37] <glatzor> hello bryce
[09:37] <cjwatson> I didn't know about it until now, actually
[09:37] <mvo> hey glatzor!
[09:37] <cjwatson> I knew about all the pieces and so could put it together once the idea occurred to me
[09:37] <ogra> ah
[09:38] <glatzor> mvo: even nurses don't work so late :)
[09:38] <ogra> well, depends on he shift no ?
[09:39] <ogra> *the
[09:39] <mvo> glatzor: good point
[09:39] <mvo> glatzor:  I should stop
[09:39] <pygi> mvo, o no, not before you build :)
[09:39] <mvo> glatzor: I made some progress with xrandr1.2, I think it comes together (slowly)
[09:39] <tseliot> hi all
[09:40] <glatzor> mvo: whoa. cool
[09:40] <bryyce> mvo, glatzor, I've been talking with tseliot about displayconfig-gtk and bulletproof-x
[09:40] <mvo> glatzor: but I need to sit down and write a nice interface around it, currently its all a bit messy
[09:40] <mvo> bryyce: great, more hands!
[09:41] <bryyce> mvo, glatzor, here is what he's been working on:  http://albertomilone.com/wordpress/?p=93
[09:41] <tseliot> I saw you're using randr's C code
[09:41] <tseliot> btw, a guy is helping me to change the UI
[09:41] <mvo> tseliot: yes, I'm working on ctypes bindings so that the native C api can be wrapped
[09:41] <tseliot> that's the best approach
[09:42] <mvo> tseliot: are you the one behind the gui frontend for the xrandr binary?
[09:42] <tseliot> yep
[09:42] <mvo> nice work!
[09:42] <tseliot> I don't know C yet
[09:42] <mvo> I saw some screenshots on the planet
[09:42] <tseliot> the new interface looks much better
[09:42] <tseliot> ;)
[09:42] <mvo> :)
[09:42] <tseliot> it already works
[09:43] <tseliot> it only lacks a logger
[09:43] <mvo> is your code available in some public repository?
[09:43] <tseliot> not yet
[09:43] <tseliot> you know I would like to clean it a bit
[09:44] <mvo> maybe we can try to agree on a python interface so that we can have a backend based on calling binary and a backend based on the ctypes implementation
[09:44] <mvo> haha
[09:44] <bryyce> :-)
[09:44] <tseliot> hehehe
[09:45] <tseliot> I only used xrandr's output
[09:45] <tseliot> then I manipulate the output
[09:45] <glatzor> tseliot: you mentioned the current git version of xrandr? Does it contain a lot of improvements?
[09:45] <bryyce> glatzor, btw, I found some errors in the code currently in bzr - I posted a patch to comment out the bits of code that were complaining
[09:45] <bryyce> glatzor: wasn't sure how to fix them
[09:45] <tseliot> I can't compile it
[09:46] <tseliot> at least yesterday it didn't compile
[09:46] <tseliot> Keith Packard told me that
[09:46] <glatzor> bryyce: oh, I already rejected your bug. :)
[09:46] <tseliot> the new randr allows you to select between PAL/NTSC
[09:46] <bryyce> I trust that's because you had some real fixes? ;-)
[09:46] <glatzor> bryyce: to use the glade file of the bzr repository you have to use the --data-dir=data option
[09:47] <mvo> bryyce: or build it with debian/rules arch-build and install the debs in debian/arch-build
[09:48] <bryyce> glatzor: hmm
[09:48] <glatzor> bryyce: the DisplayCOnfig class is an inherit of SImpleGladeApp that makes all the glade widgets attribute of the class
[09:49] <glatzor> oh awkward grammar :)
[09:49] <tseliot> mmm
[09:49] <glatzor> SimpleGladeApp provides all glade widgets as attributes of the class
[09:50] <tseliot> yes, that was clear :-)
[09:50] <tseliot> where's the gladefile?
[09:50] <bryyce> ah ok.  perhaps a README would help.  before it ran out of bzr without needing that
[09:52] <bryyce> tseliot: there's one in the data/ dir
[09:52] <tseliot> ok, thanks
[09:52] <bryyce> glatzor, with this I still get an error:  $ ./displayconfig-gtk --data=data/displayconfig.glade
[09:52] <bryyce>     from displayconfigabstraction import *
[09:52] <bryyce> ImportError: No module named displayconfigabstraction
[09:53] <glatzor> bryyce: sudo ./displayconfig-gtk --data-dir=data
[09:53] <bryyce> same thing with ./displayconfig-gtk --data-dir=data/
[09:53] <glatzor> bryyce: you need to install the guidance-backends
[09:54] <tseliot> it works well here
[09:54] <bryyce> ahh, right this is my feisty system, that's not available for it
[09:54] <glatzor> bryyce: YOu can find feisty packages in my file repository that I mentioned in my last mail
[09:54] <tseliot> but I'm using feisty
[09:54] <tseliot> o_O
[09:55] <glatzor> tseliot: bryyce: http://glatzor.de/filesink/displayconfig/feisty/
[09:55] <tseliot> I mean that it's working on feisty
[09:55] <bryyce> ok cool, got it up on my gutsy system
[09:56] <tseliot> it's not fully functional but I guess it parsed my xorg.conf
[09:56] <glatzor> tseliot: bryyce: I just pushed my today's train ride outcome. So perhaps worth to update your repositories
[09:56] <bryyce> ok
[09:56] <glatzor> tseliot: what problems do you have?
[09:57] <glatzor> tseliot: by the way where is your bzr repository for the xrandr gui?
[09:57] <tseliot> I didn't set up a bzr repository yet
[09:57] <glatzor> bryyce: I hope that we will get a shared guidance repository soon
[09:57] <glatzor> bryyce: then we can work more on the backend
[09:58] <tseliot> glatzor: what's your bzr repo?
[09:58] <glatzor> tseliot: every Ubuntu project needs a bzr repository :)
[09:58] <cjwatson> ogra: ok, cprov and I have come up with a plan which I think I can write a patch for
[09:58] <ogra> cool
[09:58] <tseliot> Ok, I'll set up one then
[09:58] <glatzor> tseliot: och, for displayconfig-gtk I merge changes of my local branches to the ubuntu branch
[09:59] <pygi> glatzor, we should all use mercurial or git :P
[10:03] <tseliot> I'm getting the code with bzr
[10:04] <bryyce> tseliot, glatzor, what do you think the potential is for joining forces, as opposed to having two separate xrandr gui config tools?
[10:05] <tseliot> bryyce: it's a good question
[10:06] <tseliot> we're using a different approach
[10:06] <tseliot> therefore I don't know where I can help
[10:06] <M_A_K> Sorry to bother here, but how / who do I tell that I think NIS is broken as of a recent feisty update?
[10:06] <M_A_K> I've tried to ask in #ubuntu and #kubuntu, bot no answer.
[10:06] <cjwatson> Lure: could you try to reproduce bug 118967 with 'ubiquity --debug', please?
[10:06] <ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [High,Confirmed]  https://launchpad.net/bugs/118967
[10:06] <bryyce> glatzor: what do you think?
[10:07] <cjwatson> actually, I'll put that in the bug
[10:08] <Lure> cjwatson: I can try later tonight (as I am working on this machine currently)
[10:10] <mvo> tseliot: what do you think about the "sharing a abstract interface to xrandr1.2" idea? this way we could share a lot of work. we could use the xrandr binary-calling backend initially and at some point switch to the c-based implementation
[10:11] <mvo> and we could try to agree on a gui
[10:11] <mvo> I understand that the backend that uses the xrandr binary works already, whereas the ctypes implemntaiton in ~30%-50% done (at most)
[10:11] <tseliot> ok
[10:12] <mvo> bryyce, glatzor: what do you think about this?
[10:12] <tseliot> I will definitely have to clean and comment my code a bit
[10:13] <bryyce> mvo, I'm definitely a fan of working together as much as possible
[10:13] <mvo> that is no problem :) my current xrandr ctypes prototype can be used to scare small children ;)
[10:13] <tseliot> :-D
[10:16] <glatzor> mvo: tseliot: bryyce: as tseliot already mentioned we have got different goals. But I think that it can still be very inspiring: for the user interface and the backend
[10:18] <tseliot> ok :)
[10:19] <tseliot> I have tried displauconfig from bazaar and installed guidance
[10:19] <tseliot> I have a question for you glatzor
[10:20] <tseliot> it seems to detect 2 displays on my laptop
[10:20] <tseliot> however it says that screen 2 is disabled
[10:20] <tseliot> the problem is that screen 2 doesn't exist
[10:21] <tseliot> and the driver is detected as i810 but I'm using the intel driver
[10:21] <glatzor> tseliot: the backend makes some assumptions that are perhaps not always the best :)
[10:22] <glatzor> tseliot: 2 displays are regarded as a standard feature of laptops
[10:22] <glatzor> tseliot: so all laptops have got a second display for guidance
[10:23] <glatzor> tseliot: But I also tought about disabling this
[10:23] <tseliot> you can see whether an app is connected through randr
[10:23] <tseliot> I mean a device, not an app
[10:23] <tseliot> sorry
[10:24] <glatzor> tseliot: Think of the users: "Hey, my laptop has  got a second hidden device. The bad hardware vendor have included all the hardware but not a plug!"
[10:24] <bryyce> glatzor, don't know if you saw it but I also sent in a patch to add --version support
[10:24] <tseliot> LOL
[10:24] <glatzor> bryyce: oh, it is already commited
[10:24] <glatzor> bryyce: why do you want to change the usage info?
[10:24] <glatzor> bryyce: I skipped this part
[10:25] <bryyce> ah, didn't see it in the changelog
[10:25] <glatzor> bryyce: It was some minutes ago :)
[10:25] <bryyce> oh!
[10:25] <bryyce> what was the usage info before?  I actually didn't look to see if it was already printing something
[10:25] <glatzor> tseliot: one of our main problems is that we have got two resources of information: the xorg.conf and the live detected data
[10:26] <tseliot> that's what I was going to ask
[10:27] <tseliot> does displayconfig test whether the driver supports randr 1.2?
[10:27] <glatzor> tseliot: so we guidance tries to detect the screens.  but we cannot make a clear connection between them.
[10:27] <glatzor> tseliot: it is just hopping that the first detected device is also the first device in the config
[10:28] <glatzor> tseliot: not yet.
[10:28] <mvo> that is why we would need that abstract xrandr python interface ;)
[10:29] <tseliot> :-D
[10:29] <glatzor> tseliot: there is already an instant apply infrastructure in guidance that e.g. applies resolution changes immediately.
[10:29] <glatzor> tseliot: so this is the place where we can hook in.
[10:30] <glatzor> tseliot: have you managed to get the desktop merging running?
[10:30] <tseliot> I haven't tried it yet
[10:30] <glatzor> tseliot: I always have got the problem that I am limited to resolutions that are not usable
[10:31] <glatzor> tseliot: e.g. two 640x480 screens
[10:31] <tseliot> glatzor: did you set the virtual resolution
[10:31] <tseliot> in your xorg.conf?
[10:32] <glatzor> tseliot: nope.
[10:32] <tseliot> glatzor: wait, did you mean something like Nvidia's twinview or distinct workspaces on 2 displays?
[10:33] <glatzor> tseliot: mergedfb that is used by xrandr 1.2
[10:34] <tseliot> glatzor: e.g. putting one screen beside the other?
[10:34] <tseliot> if so then I did it
[10:34] <glatzor> tseliot: the xinerama setup works like a charm to praise myself :)
[10:34] <glatzor> bryyce: have you already tested the locations?
[10:35] <glatzor> tseliot: right.
[10:35] <bryyce> not yet
[10:35] <bryyce> glatzor: xinerama still segfaults for me
[10:35] <glatzor> bryyce: which chipset?
[10:36] <tseliot> glatzor: it works, however KDE seems to mirror some windows on the 2nd screens
[10:36] <tseliot> glatzor: there are some graphical corruptions
[10:36] <glatzor> bryyce: on Saturday there will be our next LUG meeting. I hope that I can test some systems there :)
[10:37] <bryyce> glatzor, radeon R350 + RV280
[10:37] <glatzor> bryyce: two cards?
[10:37] <bryyce> I just tried out the location bar, and got an error with it - "No such file or directory: '/var/lib/displayconfig-gtk/locations/home.conf'
[10:37] <bryyce> yup
[10:37] <glatzor> bryyce: have you compared the configs with the ones created by the ati tool?
[10:37] <bryyce> well, one card plus one on-board
[10:38] <bryyce> no I haven't used the ati tool
[10:38] <glatzor> bryyce: please fill a bug and attach xconfig and pcitable
[10:39] <tseliot> glatzor: back on the virtual resolution
[10:39] <glatzor> bryyce: oh, you have to create the directory /var/lib/displayconfig-gtk/locations
[10:39] <glatzor> bryyce: this is done by the package but it should also be done by the code
[10:39] <tseliot> glatzor: you should set a virtual resolution which can contain both resolutions
[10:40] <bryyce> glatzor: ahh, ok
[10:40] <glatzor> tseliot: I get more and more the impression that xrandr will not avoid hacking on the xorg.conf :/
[10:40] <tseliot> glatzor: it's only an option
[10:41] <tseliot> glatzor: and I think it would be easy to set
[10:41] <glatzor> tseliot: so easy to automate it?
[10:41] <bryyce> glatzor: why are there two cards listed on the graphics card page?  It has i810 and vesa shown
[10:42] <tseliot> glatzor: yep
[10:42] <glatzor> bryyce: you are using the fallback xorg?
[10:42] <tseliot> glatzor: I think that using the re module would be (almost) enough
[10:43] <glatzor> tseliot: from data source do you want to calculate it?
[10:43] <bryyce> glatzor: not intentionally
[10:43] <glatzor> bryyce: the backend has got a problem with dual head cards
[10:43] <glatzor> in the fallback mode, since it was not written for this use case :)
[10:43] <tseliot> glatzor: it's not hard but it would require the user to restart the Xserver
[10:43] <glatzor> but I think this could be fixed
[10:44] <tseliot> glatzor: or maybe displayconfig can do that
[10:44] <glatzor> tseliot: and that is the point where we loose all the benefits of xrandr
[10:44] <tseliot> glatzor: I don't think it's hard to implement
[10:45] <glatzor> tseliot: are there any problems using a too large citural size?
[10:45] <tseliot> glatzor: nope
[10:45] <tseliot> glatzor: randr tailors a part of the buffer
[10:46] <glatzor> bryyce: this is documented in the TODO file
[10:47] <bryyce> glatzor: great
[10:48] <glatzor> bryyce: I am unsure if the locations should also include the driver and videoram settings
[10:49] <bryyce> I'd need to better understand the usage model for the locations bar
[10:52] <glatzor> bryyce: I already tested the locations in real life situations today :)
[10:52] <bryyce> heh cool
[10:53] <glatzor> bryyce: except of a bug, that is already fixed now it worked without any problems
[10:54] <glatzor> bryyce: I have got a location at home with a dual screen setup and a location "on the road" with only a single display
[10:55] <glatzor> bryyce: So I see the major use case in switching dual settings, connected screens and resolutions
[10:56] <glatzor> bryyce: but perhaps there are people like mvo who can only suspend their laptop using the vesa driver
[10:56] <glatzor> bryyce: it would be nice if he was allowed to switch the drivers in a nice way.
[10:57] <tseliot> glatzor: that would require restarting the xserver
[10:57] <glatzor> bryyce: there are also some people who prefer the open source nvidia driver for their daily work
[10:58] <glatzor> tseliot: we always require restarting x :)
[10:58] <glatzor> tseliot: xrandr is only used on single head systems
[10:58] <tseliot> glatzor: ???
[10:58] <glatzor> tseliot: xrandr 1.0 tends to crash xinerama setups
[10:59] <glatzor> tseliot: so if you enable your second monitor in displayconfig you have to log off
[11:01] <tseliot> glatzor: I wasn't aware of that problem
[11:02] <tseliot> glatzor: do you use "sudo pkill Xorg" to restart the Xserver from displayconfig?
[11:02] <glatzor> tseliot: that is why we are interested in getting xrandr 1.2 support
[11:02] <tseliot> glatzor: aaah
[11:02] <glatzor> tseliot: no we just send the USR1 signal to gdm
[11:03] <glatzor> tseliot: gdm will restart the xserver when all users logged off
[11:03] <tseliot> glatzor: ok that would be better if more users are logged in
[11:04] <glatzor> tseliot: I haven't looked into the kde frontend.
[11:04] <glatzor> tseliot: you are a KDE user, right?
[11:04] <tseliot> glatzor: actually I'm a GNOME user
[11:05] <tseliot> glatzor: ok, I use both
[11:05] <tseliot> glatzor: I use pyGTK
[11:05] <glatzor> tseliot: you mentioned kde before.
[11:05] <glatzor> tseliot: pygtk rocks :)
[11:05] <tseliot> glatzor: yes, it does :)
[11:06] <glatzor> tseliot: so you already have got a branch available?
[11:06] <glatzor> tseliot: pyqt isn't as nice as pygtk.
[11:06] <tseliot> glatzor: I have never tried to make a branch
[11:06] <tseliot> glatzor: maybe pyqt4 is better
[11:06] <glatzor> tseliot: no
[11:07] <glatzor> tseliot: software-properties was written with pyqt4
[11:07] <tseliot> glatzor: this is why I have to learn C++ and QT4 ;)
[11:07] <Riddell> what's wrong with pyqt4?
[11:07] <Riddell> or even pyqt 3
[11:07] <tseliot> hehehe
[11:08] <glatzor> Riddell: unicode crashes :)
[11:08] <mvo> haha
[11:08] <glatzor> Riddell: and the designer + gettext issue
[11:08] <Riddell> oh aye, string handing sucks
[11:08] <Riddell> that too
[11:09] <Riddell> mvo: wheesht yerself
[11:10] <tseliot> Riddel: is wheesht = wished?
[11:10] <mvo> the "haha" was because I was wondering if you have a hightlight on "qt" ;)
[11:10] <glatzor> Riddell: but apart from that pyqt is ok
[11:11] <mvo> *much* better than the one in gtk actually ;)
[11:11] <tseliot> :-P
[11:12] <Riddell> mvo: the treeview stuff is one of the few parts of qt I find to be badly documented
[11:12] <Riddell> I have a highlight on "kde"
[11:13] <mvo> Riddell: you should look at the gtk one, that rendering buisness you have to setup for a sinple listview is really a bit much
[11:13] <Riddell> oh totally
[11:14] <Riddell> qt 4 has very complex/advanced model-view listviews, but if you don't need it the plain one is simple to use
[11:33] <ajmitch> morning
[11:33] <persia> Good morning ajmitch.
[11:34] <mvo> hey ajmitch
[11:44] <ogra> yay, my isos look much better now
[11:45] <Seveas> ogra, they're now green?
[11:45] <ogra> Seveas. is green better ?
[11:46] <Seveas> ogra, depends on taste :)
[11:46] <ogra> heh
[11:47] <LaserJock> hmm, "the .iso is always greener on the other side"?
[11:47] <geser> "super green"?
[11:47] <Seveas> greensleeves
[11:47] <ajmitch> ogra: you mean they fit on a cd?
[11:47] <ogra> so green you want to bring your lawnmower
[11:48] <ogra> ajmitch, no, the CD was oversized by exactly 1M
[11:48] <ajmitch> ouch
[11:48] <ogra> and somehow the buildd dint pick up the seed change
[11:48] <ogra> took half a day of poking ... now its fine ...
[11:59] <cjwatson> Riddell: I think my problem with pyqt is that I find the interfaces a lot less obvious - I get the feeling it's good if you know Qt, but it just doesn't feel as pythonic somehow
[11:59] <cjwatson> (not that I'm the greatest arbiter of pythonicity)
[11:59] <cjwatson> all horribly subjective though
[11:59] <cjwatson> ogra: glad it's working now
[12:00] <ogra> cjwatson, thanks for finding and fixing :)
[12:10] <Riddell> cjwatson: I feel quite the same about pygtk


[08:18] <SpecialK|Canon> Heh I just got to the removal bit
[08:24]  * tomwardill is also reviewing it :)
[08:25] <tomwardill> although by 'reviewing', I mean 'reading and then putting a +1 on it, probably'
[08:33] <tomwardill> (which is because I don't necessarily understand the flow well enough to review it, not because 'just +1' :) )
[18:46] <tedg> Hello, I've got a core20 snap that is getting built on bionic instead of focal.
[18:46] <tedg> I'm not sure how to kick it over to focal.
[18:46] <tedg> https://launchpad.net/~ted/+snap/inkscape-master
[19:12] <sarnold> hey tedg :) I think I've heard that one of those fields is non-obvious, like "use core" or similar.. probably #snapcraft would be more active and have more folks who know this secret sauce
[19:26] <tedg> I've asked in #snapcraft and they sent me here :-)
[19:26] <tedg> Apparently it's been seen before and is something for LP admins.
[19:26] <tedg> (and that's the end of my understanding)
[19:36] <sarnold> tedg: oh no! :)
[20:02] <tedg> sarnold: from what you said, I guessed, and it worked. Needs to be set to "Ubuntu Core 16" for the series. Then it seems to autodetect focal. Thanks!
[21:17] <sarnold> tedg: excellent! thanks :D