#ubuntu-devel 2004-10-04
<seb128> jdub: happy with a dbus&hal update at this point ?
<jdub> seb128: if they go in soon, and mdz is happy with it, then it's a necessary evil :)
<seb128> ok, I'll look on this tomorrow so
<jdub> cool
<Kamion> what's a good name for the udeb spat out by shadow that asks questions about the initial user account to create?
<Kamion> it's kind of a clone of passwd.postinst but doesn't have most of the other code in passwd
<thom> adduser ?
<Kamion> initial-username.udeb?
<thom> hmm, no. too confusing
<Kamion> and deb/udeb names share a namespace anyway
<thom> initial-user.udeb since it does more than just a username
<Kamion> if it ever went into Debian it would in principle ask all the questions from passwd.config, which has stuff like "do you want md5 passwords?"
<Kamion> passwd-config.udeb?
<thom> WFM
<Kamion> CONSENSUS
<Kamion> woohoo
<mdz> jdub: would you create ubuntu-security-announce?
<jdub> ok
<thom> Kamion: *g*
<Kamion> hm, I think I shall delete the root password question entirely from passwd-config.udeb; even if you wanted to set a root password, storing it in the debconf database across reboot would be evil!
<thom> mdz: for tbird i'll just upload a port of new debian with our additions for amd64 tomorrow; i don't think a backport is beneficial right now. waddya think?
<trukulo> when ubuntu service pack 2 will be released?
<trukulo> lol
<trukulo> ups, sorry, that's devel channel
<Kamion> of course, the user password ends up in the debconf database over reboot ...
<Kamion> mdz: you have a problem with that? it'll be deleted as soon as the user's added
<mdz> Kamion: config.dat or password.dat?
<Kamion> mdz: there's no such distinction in cdebconf
<Kamion> sorry, yeah, the *c*debconf database over reboot
<mdz> Kamion: :'-(    <-- baby jesus
<Kamion> yarrrrrrr
<mdz> Kamion: is the cdebconf database world-readable?
<mdz> if so, can we make it not so?
<Kamion> /var/log/debian-installer/cdebconf/questions.dat is world-readable post-install
<Kamion> it would be a pain in the arse to make it not so, since it's useful for bug reports
<mdz> is there any reason why it needs to be?
<trukulo> can't you save password md5'ed ?
<mdz> there is other stuff in /var/log/debian-installer which is not world-readable
<mdz> like syslog
<Kamion> but we could make it not world-readable if we were willing to suffer the support load
<mdz> trukulo: not without extending adduser to support that
<trukulo> mdz: ok
<Kamion> actually, passwd.config doesn't use adduser for that part
<Kamion> it does adduser --disabled-password, then its own evil chpasswd hack
* ddaa points the Monty Python finger and scream "splitters!"
<Kamion> mdz: would you be happy for a *hash* of the password to be in a world-readable file? I'm uneasy about it myself
<Kamion> I don't think the unencrypted password should be in any file, world-readable or not
<mdz> Kamion: not really
<mdz> but I'd be even happier with a hash in a non-world-readable file than with a password in a non-world-readable file
<Kamion> I think the latter's right out
<Kamion> we might as well store /etc/shadow unencrypted at that point
<mdz> that's what we'd be doing with the former
<trukulo> what about saving password not in database, but in a different file and then remove it later?
<Kamion> no, I mean the passwords in /etc/shadow unencrypted :)
<Kamion> trukulo: too much work for the time period
<mdz> Kamion: me too :-)
<trukulo> Kamion: right
<mdz> I have no qualms about making questions.dat root-only if we're going to put authentication data in there
<Kamion> trukulo: the only way this is even feasible in the TWO DAYS I have to implement this is to use debconf :)
<mdz> we can solve the support issue if needed
<Kamion> all right
<mdz> I'm still a little queasy about putting the password in there
<Kamion> then I have to chroot to run perl
<trukulo> only two days? then non-readable, as you said before
<Kamion> non-readable hash is equivalent to /etc/shadow, clearly ok
<trukulo> but if you accomplished that, then people don't need to restart after installation? going into X automatically?
<Kamion> they still need to reboot after the first stage
<Kamion> I don't think that's negotiable; you need to be sure that the boot loader works
<trukulo> but no passwords at first boot after install, that's very usable
<trukulo> Kamion: i agree, i prefer forcing to reboot after configuration
<Kamion> [personally I don't really see that it's much different from the current case, but the guy who writes the paycheque wins, as lamont sometimes says ...] 
<trukulo> :)
<trukulo> little diferences like these, makes a good look for users
<Kamion> I don't even see the usability win myself :)
<trukulo> nor do i, but remember that most people thins graphical installers are better than ncurses
* Kamion ponders setting a 'hash' flag on passwd/user-password once the password is hashed
<Kamion> to distinguish
<Kamion> Joey Hess has observed in the past that I'm one of the few people who uses custom debconf flags in maintainer scripts ...
<Kamion> (with a reaction like "wow, you actually do that?", IIRC)
<trukulo> i'm not a programmer, i'm only sysadmin :) so i can't understand what you talking 'bout very well
<Kamion> just thinking out loud
<trukulo> that's good technique
<trukulo> when we talk bout we thinking, we're thinking better
<trukulo> k, i'll shut up, don't want to make noise here
<mdz> jdub: ubuntu-security-announce ready?  I'd like to follow up with a hyperlink to subscribe
<jdub> sec
<jdub> sorry, didn't think it was immediate request
* jdub is eating breakfast;)
* trukulo thinks bout going to bed 0:40 here
<Kamion> # Use perl rather than echo, to avoid the password
<Kamion> # showing in the process table. (However, this is normally
<Kamion> # only called when first booting the system, when root has no
<Kamion> # password at all, so that should be an unnecessary precaution).
<Kamion>         SETPASSWD_PW="$2"
<Kamion>         export SETPASSWD_PW
<Kamion> surely environment variables show up in the process table too?
<Kamion> hm, perhaps only for processes you own
<jdub> mdz: explicit reply-to ubuntu-devel?
<mdz> jdub: ubuntu-users, please
<mdz> Kamion: under Linux, yes, only for processes you own
<mdz> a poor feature to rely on for security
<Kamion> yeah, fortunately not in fact relied on
<Kamion> kind of hard to deal with sensitive data securely in shell
<azeem> doogie probably wrote some oo-code for that
<Kamion> doogie and secure in the same sentence? :)
<Kamion> hm, no registry of prebaseconfig item numbers
<jdub> elmo: ping?
<mdz> daniels: ping?
<lamont> Kamion: I didn't realize that had become "my" statement...
<jdub> lamont: build errors coming in :|
<jdub> oh, needs NEW flushing
<jdub> nm
<mdz> fabbione, thom: most recent firefox and xfree86 both have no problems for me on all architectures, thanks!
<lamont> jdub???
<jdub> lamont: did some new stuff for universe+hoary testing late last night
<jdub> fucked up a bit
<jdub> i am a bad person
<mdz> elmo: ping?
<lamont> gah.  so when one changes Makefile.am, just need automake, or autoconf as well>>
<azeem> automake
<Kamion> lamont: you're who made it familiar to me :)
<lamont> Kamion: ah, ok
<lamont> also know as the Golden Rule:  he with the gold makes the rules.
<jdub> BLING!
<lamont> bling-bling
<Kamion> Is it frightening that I know the PCI vendor id for Broadcom by heart?
<jdub> elmo: ping
<lamont> Kamion: there was a time when I could ID many networking cards from the first 3 octets...
* Kamion hands lamont pci.lst; memorize that, I'll test you tomorrow
<lamont> ENOTIME
<Kamion> oh, ok, you can have until Monday then
<Kamion> would certainly make my life easier if I knew the whole lot by heart :)
<lamont> Kamion: I've been known to really annoy people by assembling parisc instructions in my head..
<elmo> mdz/jdub: ?
<lamont> repeat after me: 8 7 4-1 6 5 19-9 0
<lamont> I think that's the order, anyway...
<elmo> s/annoy/freak out/
* lamont has to run the kids to town
<lamont> elmo: yeah
<elmo> jdub: is this NEW stuff for universe or main?
<lamont> the bad part is when you patch about 6 instructions in one fell swoop, in hex.
<lamont> back in a couple of hours.
<jdub> elmo: universe
<jdub> elmo: can you kill polypaudio  in new?
<jdub> elmo: i'll fix that up
<elmo> libao-polyp too?
<jdub> yeah, ok
<elmo> remember, universe stuff needs to be universe/$SECTION... I can override tho, so it's not critical
<jdub> oh
<jdub> libao-polyp (0.3-1) universe/sound; urgency=low ?
<jdub> or in control?
<elmo> yeah, but you should change debian/control - not the .changes
<jdub> so Section: universe/sound -> for both binaries and source?
<Kamion> lamont: you're insane, dude :)
* jdub chuckles at elmo's reject mail
<elmo> jdub: yeah
<Kamion> jdub: share
<jdub> "Rejected at request of bong sipping maintainer
<jdub> "
<Kamion> :-)
<jdub> we should patch our vim to understand our wacky debian/control + changelog foo
<jdub> ;)
<Kamion> oh yes
<elmo> jdub: so am I rejecting them all?
<jdub> just those ones
<jdub> ready to upload?
<elmo> yeah
<jdub> rocking, thanks
<azeem> did I ask whether you guys are keeping all your main debian/ dirs in a repository?
<azeem> if not, do you? =)
<jdub> we will
<jdub> there's some interesting stuff on the way in that regard :)
<azeem> sweet
<elmo> (new) polypaudio_0.5-1ubuntu1.dsc optional sound
<elmo> is that intentional?
<jdub> not universe/sound? no, i did that one before you mentioned it
<elmo> ok, no prob, I'll just override
<elmo> I assume gamin/howl aren't going to main at this stage either?
<jdub> no
<jdub> thanks
<jdub> i'll do that in future :)
<mdz> elmo: upload access for herbert?
<mdz> thom: ick, does libapache2-mod-php4 really only work with the prefork mpm?
<elmo> well, meh, does anyone have any suggestions on an upload method that allows you to reliably tell when a file's completely uploaded?
<Kamion> keep rsyncing until it doesn't do anything? :)
<jdub> elmo: run a twisted ftp server, and fire off events when the files are fully uploaded :-)
<Kamion> sheesh, new Windows XP Home is 163?
<Kamion> not buying that just for testing purposes
<Kamion> maybe one of my friends can lend me a copy or something
<elmo> expense it ;-)
<jdub> "required for the express purpose of bringing freedom to the entire world"
<Kamion> tempting
<jdub> "(also, doom3 looks very interesting)"
<Kamion> actually, very tempting; then I can continue Not Owning A Copy Of Windows
<Kamion> ('cos it won't really be mine)
<jdub> i didn't get that badge ;)
<mdz> are windows XP licenses transferrable?
<mdz> if so, you can have the one that came with my laptop
<jdub> (they're definitely not with the hardware)
<jdub> (dunno about otherwise)
<jdub> oh
<jdub> lwn
<elmo> not legally, but they work
* jdub goes to check out ubuntu article
<jdub> boh
<jdub> not front page
<jdub> " Here is a little quiz. Which Linux distribution's mailing list recorded over 1,000 posts during the first week of its existence? Which project succeeded in attracting some of the best-known and most prominent open source developers to work on it? And why do their email addresses invariably end with @canonical.com?"
<Kamion> so what's all that product activation about then?
<jdub> haw haw
<Kamion> I thought it was supposed to stop you transferring copies around?
<elmo> kamion: it definitely doesn't, there's a key that's assigned "to the NHS" that must be used on thousands of computers
<mdz> -rw-r--r--    1 root     root      2266975 Sep 22 15:42 changelogs
<mdz> that's the apt-listchanges output for a woody->warty upgrade on a non-trivial server
<elmo> neat
<mdz> that's a hell of a lot of changelogs
<azeem> oh, so Dave Miller really is *the* Dave Miller. Should have figured.
<elmo> uh?
<elmo> no, our Dave Miller is not the kernel guy
<azeem> then lwn is wrong
<elmo> neat
<jdub> heh
<elmo> I should do that subscription via debian thing sometime
<azeem> everbody's been named except elmo
* jdub sends correction
<Kamion> plenty of Debian people other than elmo not mentioned either
<jdub> azeem: everyone? :)
<jdub> Hi,
<jdub> Dave Miller on our team is not Dave "dude" Miller, it is Dave "bugzilla
<jdub> maintainer" Miller. :-)
<jdub> Thanks,
<jdub> - Jeff
<jdub> 
<jdub> ;-)
<azeem> heh
<Kamion> namechecking me as "Debian QA" is a bit out of date too, but I won't argue :)
<elmo> jdub: ITYM, "K, Thanks, Bye.  Love, Jeff"
<justdave> haha
<jdub> the other dave miller says dude *way* too much
<justdave> too many Dave Millers out there :)
<justdave> as far as I know, 'davem' still works for Red Hat
<elmo> yeah, he does
<mdz> oh, lwn is out? I guess they go by UTC
<jdub> http://unconcerned.org/index_unbutu.html
<jdub> hahahahaha
<jdub> (for non-gnome dudes, see goneme.org)
<Kamion> :-)
<Kamion> new d-i uploaded with slightly branded installation manual, still lots of work to do there
<Kamion> shout if it fails to build for some reason; I don't think it will, but ...
* Kamion is off to bed
<mdz> Kamion: night
<elmo> my god, the "submit a bug" page is half a mb big?
<justdave> most of that is probably the component list.
<daniels> mdz: pong
<jdub> so
<jdub> sbuild or pbuilder
<jdub> ?
<mdz> elmo: dude, that's a feature
<mdz> elmo: dan jacobson can never report a bug
<mdz> jdub: none of the above
<jdub> mdz: what do you recommend?
<elmo> mdz: LOL
<mdz> jdub: hypothetical UML-based tool I've only half-written
<elmo> jdub: for what?
* jdub spanks mdz 
<jdub> elmo: for building and checking things locally
<mdz> pbuilder is scary crack and sbuild isn't particularly well suited for non-buildd use
<elmo> sbuild is machosistic, unless the package is vastly improved
<elmo> pbuilder's always struct me as particularly bad crack, but I don't have much experience to back that up
<jdub> i basically want something so i can build shit against buildd-cletn unstable or warty whenever
<azeem> elmo: of course it's vastly improved, I'm co-maintainer now
<azeem> didn't do anything yet, though
<elmo> heh
<elmo> personally, I just use a chroot by hand, but I'm 0ld sk00l that way
<azeem> how do you uninstall the Build-Deps afterwards?
<elmo> *cough*, I cut'n'waste the "the following packages will be installed" output from apt-get to a file, and then apt-get --purge remove $(cat to_remove) afterwards
<jdub> haha
<jdub> that's not old skool
<jdub> that's no skool
<elmo> hey, I wrote the precursor to 'sbuild' in a hideously eccentric little shell called 'es' (-> 'esbuild') - I get to be a freak about how I build packages in a chroot
<elmo> jdub: module.h:26:18: ltdl.h: No such file or directory
<elmo> missing b-d on libltd3-dev or whatever it is, I guess
<jdub> yeah, now they're out of new i can upload the fixed one :)
<mdz> I just throw the chroot away afterward
* jdub feels morbid, migrates to pillowful working area
<elmo> hmm, no hoary/supported seed yet?
<mdz> hoary should be sharing warty's seeds for now
<elmo> yeah, I mean for proposals
<elmo> as I assume it's too late to propose things for warty :)
<jdub> 8)
<elmo> mdz/jdub: btw, do you have a timescale when you want hoary, if it's not ASAP?
<mdz> elmo: to be honest, I don't see the point until we have hct
<mdz> elmo: I don't think it's too late to propose stuff for supported if it's trivial
<elmo> mm.. Mark indicated to me that hct was a way away, e.g. he said we'd be accepting community uploads before hct was ready, and I think that included hoary
<mdz> I spoke to him about it today; there seem to be differing visions for hoary
<elmo> giggle.. neat!
<mdz> jdub: what's yours? (the one you've announced on ubuntu-users@ with ETAs and stuff)
<mdz> there are 1009 source packages in warty main
<mdz> we've modified 308 of them
<mdz> clobbering those changes with packages from unstable would produce an, err, undesirable result
<mdz> elmo: would it be possible to rig something up to let unmodified packages flow in from sid, while not clobbering modified ones?
<elmo> well, I can easily enough not sync if there's an 'unbutu' marker in the version number in warty
<daniels> pittping
<mdz> then we could work through those by hand
<daniels> ugh
<elmo> daniels: dude, your keyboard handling skills suck tonight
<mdz> pitti's asleep
<elmo> it's like 5am in Germany :)
<elmo> hmm, and 4 am here.. sleep might be a plan soon
<daniels> elmo: wow, way to make your point, dude :P
* daniels considers a base-config upload with Canonical Standard Time (UTC+10) as the default TZ.
<elmo> mdz: sure, no prob.. anyway, given the differing visions, shall I mail you, jeff, mark?
<elmo> (think jeff's crashed now)
<elmo> daniels: ?
<mdz> oh, I thought he was still here
<daniels> elmo: the 5am thing
<mdz> it's like noon in jdub-land, isn't it?
<daniels> wtf??
<daniels> To: apache@packages.debian.org                                                                                          
<daniels> Subject: Andy Rourke (Smiths Bass Player) replaces Mani (Primal Scream)                                                 
<daniels> and, sure enough, it's about andy rourke replacing mani
<elmo> * jdub feels morbid, migrates to pillowful working area
<jdub> mdz: mmm, thogh feeling uwjwell
<daniels> mdz: 1251
<mdz> jdub: ah
<daniels> mdz: so, just to make sure I'm not entirely on crack
<daniels> mdz: ppp_on-boot_dsl is going into pppoeconf with a different name, no?
<daniels> ppp_on_boot.dsl, even
<mdz> daniels: s/pppoeconf/ppp/
<daniels> mdz: glad I asked
<mdz> I thought I said that in the bug
<elmo> mmm.. 4am.. night all
<daniels> elmo: night dude
<daniels> hmm, my flatmate has discovered the maximum possible score on tony hawk 2
<schweeb> heh, not that hard to hit, iirc ;)
<daniels> well, maximum score for a single trick
<daniels> which is just over the 76 million mark
<daniels> (spiderman + perfect balance + grinding the wire above the bullring + unplugging your keyboard + leaving it all night + a note that says 'leave please! for science's sake!' == very thps2 score)
<daniels> s/very/& high/
* lamont bets Kamion went to bed, yes?
<mdz> yes
<justdave> mdz: want to change the debzilla address right now?  (bug 1328)
<mdz> justdave: yes
<justdave> debzilla@canonical.com?
<mdz> justdave: debzilla@ubuntu.com
<mdz> email prefs are already turned off
<justdave> ok, done.
<justdave> make sure the importer knows to log in with the new address and you're all set.
<mdz> done here
<mdz> I'll do a test run
<mdz> _seems_ to work
<mdz> but I'm not sure there was anything new that represented a good test case
<mdz> looks good though
<daniels> hmm
<daniels> who here has a shinybook?
<justdave> define shiny :)
<daniels> shinybook -> powerbooks
* lamont takes polishing compound to his vaio
* daniels waits for his pay, so he can get an X40.
* lamont sends of his initial writeup of 'so you want to bootstrap an architecture'
<daniels> heh
<justdave> I have a Pismo here...
<justdave> it's not exactly shiny
<justdave> :)
<fabbione> morning guys
* lamont sleeps.
<lamont> night fabbione
<fabbione> ehe
<fabbione> night lamont 
<daniels> night lamont, morning fabbione
<daniels> fabbione: i think the ati powerpc bios thing is an upstream bug
<daniels> that's the reason why I wanted more testing :)
<fabbione> well i0t got some testing
<fabbione> it crashed in several machines
<fabbione> this is hoary stuff
<fabbione> X is now uber deep freeze
<fabbione> also.. apparently someone found a combinantion of nv + xv working
<fabbione> but if we go for that solution we need to roll back the nv driver to the one in -6
<fabbione> that will not work for people that needs X.org driver
<fabbione> and the other way around
<fabbione> get the poiny
<fabbione> point even
<daniels> yeah, there's no way we can do r4xx stuff for warty now
<daniels> but if the bios detection is arse upstream on powerpc, i want to know that now :)
<daniels> yeah
<daniels> i think having the support xorg gives us is more importand than xv, though
<daniels> remember, it's not terribly long until we'll have xorg
<daniels> which reminds me -- early or late november for the sprint?
<daniels> i think early is good, so we can get it done as quickly as possible
<fabbione> daniels: fine for me
<fabbione> did you mail Mark?
<daniels> not yet, but i'll do that now
<fabbione> also because there is just a month or so left
<fabbione> so it's better to get organized
<fabbione> anyway Mark also said that we shouldn't spend too much time on X anymore since it is "stable"
<fabbione> and focus on all the other bugs
<pitti> Morning guys!
<fabbione> hey pitti
<daniels> fabbione: yeah, I'm trying to get off X
<daniels> fabbione: working on Gimp now, for example
<fabbione> <- raidtools2
<pitti> fabbione: BTW, X on my iBook works again. Thanks for fixing the ati driver
<fabbione> pitti: no problem and thanks for reporting :-)
<pitti> npmccallum: here?
<fabbione> jdub, mdz: ping
<fabbione> http://people.no-name-yet.com/~fabbione/raid_changelog
<fabbione> http://people.no-name-yet.com/patches/raidtools2.272864.dpatch
<fabbione> permission to upload raidtools2 to fix #1603
<fabbione> diff and changelog at the above url
<fabbione> tested with all possible raids
<fabbione> there are no regressions here
<pitti> Hi seb128!
<seb128> hello
<pitti> seb128: the new gnome-vfs broke hotplug device handling :-)
<seb128> pitti: og
<seb128> oh
<pitti> seb128: #1599, but I'm just fixing it
<seb128> I've seen your mail to ettore, this guy works on gnome-vfs ?
<pitti> seb128: I copied this from debian/copyright
<pitti> seb128: I hope so :-)
<rburton> ettore?
<pitti> seb128: is there a mailing list or so for stuff like this?
<seb128> rburton: To: Ettore Perazzoli <ettore@ximian.com> 
<pitti> seb128: no, not from copyright, from AUTHORS
<seb128> rburton: is there several ettore ?
* seb128 not sure
<seb128> pitti: I'll ping alex or teuf about this
<rburton> that is the late ettore
<seb128> :(
<seb128> as said 2 lines ago, was not sure
<pitti> seb128: ugh, does that really mean he is dead?
<seb128> pitti: yes
<pitti> uh
<rburton> died 12th december 2003 :(
<pitti> seb128: any other idea where to forward patches then?
<seb128> rburton: I didn't remember his last name, so I was not sure it was him
<pitti> indeed, the mail bounced
<seb128> pitti: as said before, I'll ping teuf or alex
<pitti> ah, ok
<pitti> thanks
<seb128> but better if you can open a bug report about this against gnome-vfs
<pitti> in their bugzilla?
* pitti looks for the gnome-vfs bugzilla
<seb128> yes
<seb128> do you have an account on bugzilla.gnome.org ?
<pitti> seb128: no, but I found the bug: http://bugzilla.gnome.org/show_bug.cgi?id=148186
<pitti> seb128: I just created one
<seb128> ok
<seb128> pitti: I'll probably update dbus/hal to new versions today
<seb128> FYI
<pitti> seb128: UGH! hal 0.2.98?
<seb128> yes
<pitti> seb128: 0.2.87 had _severe_ regressions
<pitti> I hope that they are fixed in 0.2.98
<seb128> 87 ?
<seb128> could you check ?
<pitti> no, 97 of course
<seb128> we need 98 to get the lock device stuff working
<seb128> nautilus-cd-burner 2.8.3 requires it
<pitti> can't we backport jsut this change to 0.2.92?
<seb128> 2.8.3:
<seb128> Lock drive while burning when using HAL
<pitti> seb128: ah, does it finally lock the drive?
<seb128> yes
<pitti> does it unmount the drive before locking?
<pitti> should pumount -l /dev/foo
<seb128> do you have time to make the tests ?
<seb128> I've around 90 bugs assigned in my list ...
<pitti> seb128: if you don't mind, can I do the hal upgrade myself?
<seb128> oh yes please
<pitti> seb128: or do you want to change anything specific?
<pitti> okay, then I will do that.
<seb128> BTW sjoerd (the debian maintainer) has packages almost ready
<rburton> hm, no multisync in ubuntu
<pitti> I just have two major bugs left
<seb128> pitti: apparently we need to update dbus and g-v-m too
<pitti> hell, we are frozen...
<seb128> I know
<seb128> but do you have any other idea to get the device locking ?
<pitti> yes, I have
<pitti> I have a new pmount version ready which implements per-pid locking
<pitti> this is even robust against crashes of nautilus-cd-burner, i. e. if a program crashes that locked a device
<pitti> so n-c-b just had to pmount --lock the device at start, and then pmount --unlock it when it finished
<pitti> I already proposed that in #1234
<seb128> ok, feel free to do whatever you want on this plan :)
<pitti> mdz seemed hesitant to accept a new pmount version
<pitti> that's probably why he assigned the bug to you
<seb128> I've a ton of bugs and no really time to work on this
<seb128> I've just read about the lock stuff in nautilus-cd-burner yesterday but it requires the new hal
<pitti> I tried to read the hal diff yesterday, but there are tons of new code
<pitti> can you please write a short summary of the required changes to #1234?
<pitti> then mdz should decide whether to go with new upstream or with new pmount
<pitti> IMHO the new pmount has less changes and is more robust
<pitti> OTOH it changes root code
<pitti> In any case I can care about this, either hal/ncb/gvm or pmount
<pitti> seb128: ^
<seb128> ok, cool
<seb128> hey sjoerd :)
<sjoerd> morning
<seb128> pitti was saying that's a lot of new code in hal and he's not comfortable with an update
<pitti> seb128: well, I can prepare a new hal package and test it locally
<pitti> seb128: but I got bad results with 0.2.97, that's why I would like to test this very thoroughly
<sjoerd> as i told seb128, you need to patch the dbus python bindings a little for 0.2.98 
<sjoerd> pitti: bad results with respect to hotplugging stuff ?
<pitti> sjoerd: yes, some of my devices were not recognized at all any more
<sjoerd> that's why i did 0.2.97+cvs20040907 in debian
<sjoerd> fixed the problems for everyone who reported them
<sjoerd> i've got hal 0.2.98 packages for debian almost ready, but dbus needs to be fixed first 
<pitti> sjoerd,seb128: AFAIK the locking patch was pretty small; we might be better off to just backport it to 0.2.92?
<fabbione> Mithrandir: mind to check raidtool2 changelog from sid? there is something related to amd64 that might be important
<seb128> pitti: I've not looked on hal internals enough to have an opinion on this, sorry
<fabbione> Mithrandir: between -12 and -13
<pitti> seb128: np, was just meant as CC FYI
<seb128> ok :)
<pitti> I have to log out and back in to test fixed gnome-vfs. BRB
<Mithrandir> fabbione: 266856?
<fabbione> Mithrandir: yes
<fabbione> Mithrandir: since i am keeping a lock on raidtools2 i am still in time to add it
<Mithrandir> fabbione: I don't have my ubuntu system powered up atm, but the patch looks sane to me
<fabbione> Mithrandir: ok
<fabbione> i will talk with mdz or jdub when they are around
<pitti> damn, new gvfs still not working
<sjoerd> pitti: if you only need the locking code for hal, then backporting it is the least intrusive way ofcourse
<fabbione> Mithrandir: it's one liner.. i will just include it
<Mithrandir> fabbione: coolie
<seb128> pitti: if you can backport the lock part perhaps it's the best solution ?
<pitti> seb128: the hal part should be relatively easy; but we also need a new gvm?
<seb128> sjoerd: ? :)
<sjoerd> if you go to 0.2.98 you need a new g-v-m yes
<seb128> no
<seb128> we want to backport the lock changes to 0.2.92
<sjoerd> hmm for the locking too i guys, if you don't want it mounting stuff
<sjoerd> there is support for thet in the development branch of gvm
* sjoerd adds that to debians gvm todo
<fabbione> Mithrandir: i placed the source on people/~fabbione
<fabbione> Mithrandir: can you just build it?
<Mithrandir> fabbione: my amd64 ubuntu system is at home, powered down atm.
<Mithrandir> I need to get rid of a disk so I can sleep with it powered on.
<thom> fabbione: i can built it
<thom> but i have no way to test it
<fabbione> thom: the test has been done.. i only want to be sure that is not a FTBFS
<thom> then sure
<fabbione> Mithrandir: ehehe don't worry :-)
<fabbione> Mithrandir: we still have THOMBOT!
<Mithrandir> fabbione :)
<thom> builds for me
<fabbione> danke
<thom> bitte
<fabbione> thom: can you ping your friend for #1218 ?
<thom> have pinged, will ask colleagues to badger him
<fabbione> thanks
<fabbione> ok patch for raidtools2 is already accepted by the DD.
<fabbione> that's good
<fabbione> he was fast and happy
<jdub> fabbione: pong
<fabbione> jdub: read mail about raidtools2
<fabbione> jdub: patch has been already accepted by the DD
<fabbione> jdub: it also includes an AMD64 fix
<fabbione> see the changelog
<fabbione> it's a one line change
<sivang> g'afternoon people
<rburton> thom: so if i echo mem to /sys/power/state, it suspends and immediatly results on a tosh laptop. any ideas?
<sivang> hi pitti
<thom> s/results/restarts i assume?
<rburton> yes :)
<rburton> dmesg shows e100 suspending and immediately being told to wake up again
<rburton> thom: are you lead man on ACPI issues?  should i get dan to file a bug re: suspend
<Mithrandir> rburton: unload the USB modules
<rburton> trying
<thom> but yeah, please file a bug, assign it to herbert, cc me
<rburton> ok, removed ehci_hcd and uhci_hcd, leaving usbcore loaded, it resumed but when it resumed it had video corruption for a bit, and then shutdown
<rburton> gracefully which was odd :)
<Mithrandir> rburton: yes, it's the power button even which gets caught by /etc/acpi/powerbtn.sh
<Mithrandir> so it thinks you wants to turn it off
<Mithrandir> I miss a command similar to the old apm -s
<rburton> justdave: ping?
<justdave> rburton: pong
<rburton> justdave: i'm so in awe of the icalendar queries on the ubuntu bugzilla that i'm upgrading our own one.  2.18rc2 appears to have broken icalendar export -- so is cvs head safe?
<pitti> sivang: Hi! Just had lunch
<justdave> if it works on bugzilla.ubuntu.com, it'll work on cvs head
* thom jumps up and down on bugzilla's head in a rage
<thom> justdave: any joy with the "assign to me and mark assigned" button?
* Mithrandir gives thom a beer
<justdave> if it's broke in rc2 I'd consider that an rc bug for 2.18
<rburton> justdave: i'll check it again to make sure i'm not mad
<thom> rock. find in firefox is actually totally hozed
<justdave> hmm, works for me on landfill
<thom> bbiaf
<azeem> bbiaf? be back in a fortnight?
<rburton> justdave: right, confirmed. icalendar contains just BEGIN and END
<thom> "few"
<rburton> few.... months?
<rburton> nanoseconds?
<thom> hours, probably, given that i need to build a clean firefox on my crazy debian crack of doom partition
<rburton> justdave: i'll be brave and go to the tip of 2.18
<justdave> rburton: http://landfill.bugzilla.org/bugzilla-2.18-branch/
<justdave> that's tip of the branch, what'll be rc3 in a day or two
<rburton> cool
<rburton> grrr at bugzilla and permissions
<rburton> justdave: what is the recommended user/group for bugzilla. atm its owned by me with group www-data but that is a pita as i have to su to run checkconfig
<justdave> thom: yeah, will hopefully have that in the next update (which is happening today sometime - been fighting with it for the last day and a half)
<thom> justdave: rock, cool
<justdave> rburton: root:www-data :)
<justdave> if you're the only person on the box, you can set webservergroup to an empty string and it'll loosen up permissions a bit
<justdave> but that makes the data directory world-writeable, so that's not advisable if there's people besides you with access to the box
<rburton> yeah, everyone
<rburton> its the file server as well as web
<justdave> you could also add yourself to the www-data group
<justdave> which would let checksetup.pl do the chgrp without complaining
<rburton> yes, i was going to do that
<rburton> hm, still doesnt' work with tip
<rburton> how annoying
<justdave> wonder if there's something it doesn't like in your data...
<rburton> all the bugs have padlocks next to them
<rburton> would the group permissions break it?
<justdave> are you downloading the ics file or subscribing to it?
<rburton> aaaha if i download in ephy it works
<rburton> wget doesn't
<rburton> subscribing also doesn't
<rburton> which is why
<rburton> *darn*
<justdave> yeah, you need your login cookie since the bugs are secured
<justdave> (or pass the user and pass with the url parameters)
<rburton> &user=foo&pass=bar?
<rburton> or in the url server bit?
<justdave> &Bugzilla_login=username&Bugzilla_password=password
<Mithrandir> evo doesn't do https ical urls, though
<azeem> you need evolution-webcal for that, AFAIK
<azeem> oh https
<Mithrandir> there's not a webcals protocol, it seems
<rburton> justdave: rock on, thanks
* thom looks boredly at YA mozilla build
* lamont takes kids to school
<rburton> is the daily install cd okay today?
<seb128> jdub, mdz: approval needed for #1285
<npmccallum> seb128: I don't remember when we talked, did you say that you were going to turn on esd by default (for ubuntu-sounds)?
<seb128> hum
<seb128> we said it should be turned on yes
<seb128> but I didn't say I was going to do it :)
<npmccallum> ok
<npmccallum> Should we wait until #1481 is fix until we do that?
<seb128> probably yes
<seb128> ping jdub about that
<npmccallum> I'll file a bug that depends on #1481
<npmccallum> what package is the esd option in? g-c-c?
<seb128> npmccallum: which option ?
* T-Bone curses d-i for not asking for a proxy before trying to connect to the internet
<pitti> T-Bone: Doesn't it ask if the connection cannot be established?
<pitti> T-Bone: Sarge's d-i asks for a proxy IIRC
<T-Bone> pitti: it stalls eternally, so i'm not waiting. Double ctrl-C gets to the package installation directly
<T-Bone> pitti: correct, sarge asks
<pitti> T-Bone: can you please file a bug?
<pitti> T-Bone: describing some details?
<T-Bone> pitti: sure, ASA i'll familiarize with ubuntu BTS ;)
<npmccallum> seb128: to turn on esound and play sounds at events
<pitti> T-Bone: it's not difficult, you just have to create an account
<pitti> brb
<T-Bone> already reported #1160
<seb128> npmccallum: esound is on by default, isn't it ?
<T-Bone> pitti: already reported as #1160
<T-Bone> btw, another question, probably a FAQ: what's the point of copying all packages to the local HD. Is warthy designed not to be installable under a certain amount of diskspace?
<pitti> T-Bone: thanks
<seb128> npmccallum: BTW the sound events option are in libgnome2-common's schema
<T-Bone> btw, is Mark Shuttleworth around?
<thom> T-Bone: he's on #ubuntu, nick of sabdfl
<T-Bone> thom: thx
<thom> np
<rburton> thom: for the last six months i've wanted your t630, but not i've got a k700i so i'm happy again :)
<rburton> much better than the t68i :)
<thom> now you just need a decent laptop... ;-)
<rburton> yep
<rburton> then i can be MiniThom
<rburton> and follow you around
* thom chuckles
* rburton hears police sirens and hides
<seb128> jdub: #1285 please :)
<seb128> updating esound
<seb128> arg
<jdub> :-)
<seb128> ryan's packages are a pain
* T-Bone edits apt.conf by hand to add a proxy
<seb128> he has almost forked them with all the changes in the diff.gz
<jdub> seb128: libxml is part of gnome ;)
<seb128> and he's the only one to know what's in there
<azeem> T-Bone: running apt-setup by hand also lets you do this, IIRC
<jdub> morning azeem
<seb128> jdub: if that ok to update esound to current upstream and drop all debian changes ?
<azeem> hey Jeff
<seb128> hey azeem, thanks for the patch
<jdub> seb128: hmm
<azeem> cheers
<T-Bone> azeem: oh; i'll try ;) Old debian habits are poising me ;)
<jdub> seb128: can you check the src.rpm in fedora for any patches?
<jdub> seb128: there might be some common ground for amd64 fixes and things like that
<seb128> jdub: ok
<azeem> T-Bone: it's just that I find it hard to remember the syntax needed for apt.conf
<jdub> just in case we miss anything ;)
<seb128> ok :)
<azeem> the whole proxy thing sucks in Debian/Ubuntu currently, IMHO
<azeem> worest of all is synaptic, which neither uses GNOME's nor APT's proxy setup but insists in having its own
<T-Bone> azeem: lol, i'm getting used to it :)
* T-Bone gets "duplicate source entries" errors, tries to figure out what he did wronge
<T-Bone> -e
<rburton> T-Bone: you uncommented the universe lines without commenting the lines at the top of the file
<rburton> they both download main and restricted
<T-Bone> rburton: bingo! thx
<seb128> pitti: 09_pmount.patch + 10_fix_eject.patch break the trash with gnome-vfs 2.8.1...
<pitti> seb128: gnome-vfs 2.8.1 breaks hotplug devices :-)
<pitti> I found a partial fix no
<pitti> now
<seb128> have you opened a bug report ?
<pitti> what breaks with the trash?
<seb128> try to open the trash
<seb128> always empty
<seb128> always 0 items
<pitti> seb128: #1599 for the hotplug stuff
<seb128> it's ok if I rebuild gnome-vfs without these 2 patches
<pitti> seb128: my trash is full
<seb128> pitti: I was thinking to a gnome one so I can point to some upstream
<pitti> I empty it
<seb128> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=1636
<pitti> seb128: trash works for me???
<seb128> I've exactly the same problem here
<seb128> and no pb with gnome-vfs 2.8.0 or 2.8.1 without the 2 patches
<seb128> pitti: the trashapplet works, the trash in nautilus is broken
<pitti> seb128: works for me, too...
<pitti> that's odd
<seb128> perhaps your changes for the hotplug ?
<rburton> fabbione: does X add a synaptics driver to XF86Config if it knows one is there, or if its on a laptop?
<fabbione> the latter
<pitti> seb128: now I have a slightly updated version
<rburton> ok
<fabbione> rburton: afaik there is no way to detect that there is a synaptics whatever it is
<pitti> seb128: now it shows me mounted USB devices on desktop (not yet in the computer place)
<seb128> pitti: try with the current gnome-vfs package
<pitti> seb128: as soon as I fixed this, I will downgrade to the older version and try to reproduce 
<seb128> and killall nautilus before trying :)
<seb128> ok thanks
<pitti> seb128: I don't think that the eject fix is the cause
<seb128> me neither
<pitti> seb128: but 09_pmount does not do anything trash related neither...
<seb128> I know ...
<seb128> but I've build 10 version of the package 
<seb128> removing these 2 fixes the issue
<pitti> seb128: but this whole issue is odd anyway. Nothing in the 880 code relevant lines in the 2.8.1 patch seems to break hotplug devices
<pitti> seb128: I had to fix that in a totally different spot
<seb128> how ?
<pitti> gnome-vfs2-2.8.1/libgnomevfs/gnome-vfs-volume-monitor-daemon.c
<seb128> ok
<pitti> seb128: create_vol_from_mount decides whether the volume appears on desktop
<pitti> but it sets is_user_visible to 0 for all but some special drive types
<pitti> seb128: oddly enough this code hasn't changed from 2.8.0, but I guess it is indirectly called differently
<seb128> what has changed in create_vol_from_mount behaviour between 2.8.0 and 2.8.1 ?
<pitti> seb128: nothing, that's the funny part
<seb128> weird
<seb128> same for the trash
<pitti> seb128: as I said, I read the whole diff from 2.8.0 to 2.8.1
<seb128> that's broken but nothing changed
<pitti> seb128: voodoo
<seb128> one of the patches is perhaps doing bad stuff
<pitti> seb128: can we blame Bill Gates for that?
* truk-zzz blames
<seb128> pitti: why not :)
<pitti> seb128: do you know a possibility to test a new gnome-vfs without logging out/in?
<pitti> seb128: I already tried to run the daemon manually, but that does not work
<seb128> perhaps teuf knows ?
<seb128> teuf: here ? :)
<pitti> seb128: I'm back in a minute
<teuf> seb128: depends on what exactly pitti is trying to achieve
<seb128> he's working with volumes/devices
<seb128> what's showed on the desktop with nautilus
<teuf> yeah, but I don't get why h e needs to log out/log in
<teuf> gnome-session-remove nautilus should be enough to kill the vfs-daemon I think
<seb128> probably to restart the volume-monitor ?
<teuf> ok
<teuf> so
<teuf> pitti: why do you need to log out/log in to test vfs changes ?
<pitti> teuf: I tried to kill the daemon and to start it with the same options, doesn't work
<pitti> seb128: my trash works like charm here :-)
<teuf> pitti: killall gnome-vfs-daemon && killall nautilus isn't enough ?
<pitti> seb128: I will try it now with the old version in Warty
<seb128> ok, thanks
<pitti> teuf: oh, will that restart everything?
<teuf> pitti: depends what you call "everything" ;)
<teuf> it's probably more than enough to test vfs changes
<pitti> teuf: cool, thanks!
<pitti> you just improved my efficiency trememdously :-)
<pitti> seb128: grumpf, the volume icons only appear _either_ on the desktop _or_ in the Computer place
<pitti> seb128: with the current gconf default, they appear only at the desktop
<pitti> seb128: do you think they should appear in both places?
<sivang> is it possible to make them appear on both places?
<seb128> pitti: the icon should always been in the computer place yes
<pitti> seb128: this must be somewhere in nautilus
<seb128> what ?
<pitti> seb128: I'm trying to find it
<seb128> hum
<seb128> that's the upstream behaviour, keep it for the moment perhaps and check with jdub
<jdub> um
<jdub> hrm?
<jdub> i thought they appeared in both
<pitti> jdub: the current behaviour is quite odd
<pitti> jdub: I just fixed gnome-vfs to actually report USB sticks and the like as "user visible" to fix #1599
<pitti> jdub,seb128: now if I plug in my stick, it appears at the desktop, not in the Computer place
<pitti> jdub,seb128: however, if I switch off the "icon on desktop" gconf setting, it appears only in the Computer place
<jdub> weird
<seb128> same
<pitti> jdub,seb128: but in this case the sda1 icon appears as "not mounted" (!!!)
<pitti> jdub,seb128: I can click on sda1 and it complains that sda1 is already mounted
<pitti> jdub,seb128: if the Icon is on desktop, it behaves sanely
<seb128> if it detects it as not mounted that's normal
<jdub> heh
* pitti cries out loudly
<pitti> seb128: why is that normal? a week ago I could click on sda1 in the computer window and the content opened
<pitti> seb128: and I could unmount it there
* pitti wishes to revert to gvfs 2.8.0
<seb128> "if it detects it as not mounted"
<pitti> seb128: ah, but it is mounted
<seb128> I know
<seb128> the detection is wrong
<seb128> but the behaviour is right according to the detection
<seb128> pitti: BTW 2.8.1 fixes some important issues, reverting is not good
<pitti> I'm already working 6.5 hours on this stuff; it's just plain weird
<pitti> seb128: BTW, I could reproduce the trash bug
<thom> that's three days of firefox. rapture
<thom> hey oh fearless laptop leader
<pitti> seb128: funnily enough it seems to work again with my updated gvfs
<seb128> pitti: nice :)
<pitti> seb128: however, inexplicable
<pitti> seb128: my patches were agains gvfs, but the trash thingy should be nautilus, don't?
<seb128> the graphical part
<seb128> the monitor is gnomevfs stuff
<seb128> and as said before is works fine with 2.8.0 package and not 2.8.1 without changing nautilus
<seb128> so I really think the problem is in gnomevfs
<mxpxpod> do you guys need a *mm library maintainer?
<seb128> fabbione: here ?
<seb128> mxpxpod: would be nice :)
<sladen> can somebody with cpu_scaling working on their PowerBook send me the output of    grep '^model name' $CPUINFO | head -1 | sed -e 's/^.*: //;   and tell me which module(s) they had to load
<mxpxpod> seb128: I'd be willing to learn exactly how to do it and help maintain
<seb128> cool
<sladen> s.$CPUINFO./proc/cpuinfo.
<mxpxpod> seb128: just let me know what to read and if I need to register somewhere or something... but that way we can keep on top of *mm stuff
<seb128> jdub: here ?
<seb128> mxpxpod: what to read for what ? Doing a debian package ? 
<jdub> seb128: mmm?
<seb128> jdub: read 2 lines ago
<jdub> mxpxpod: you've looked at the *mm sources in universe?
<jdub> mxpxpod: are they not building, or...?
<seb128> jdub: mxpxpod would like to help to maintain the *mm
<jdub> seb128: yep, worked it out now ;)
<mxpxpod> mxpxpod: no, not really, but I can do that
<mxpxpod> crap, that was to jdub
<mxpxpod> oh, nice... gtkmm-2.4.5 hasn't been compiled for ppc... but the source is in universe
<jdub> ok
<jdub> so
<jdub> grab the sources
<mxpxpod> jdub: got em
<jdub> see if they build on your box
<jdub> fixing that stuff will go straight into universe for everyone else :)
<mxpxpod> jdub: is there a specified way that is more acceptible to build with? or is apt-get source -b libgtkmm-2.4-1
<jdub> if you want updated packages
<jdub> mxpxpod: apt-get source <package>
<jdub> cd <directory>
<jdub> dpkg-buildpackage -uc -us -rfakeroot
<jdub> probably worth hanging out here to ask about the ins and outs of how this all works
<mxpxpod> jdub: you don't care that it's not signed?
<jdub> but i strongly recommend reading the developer docs on debian.org
<mxpxpod> jdub: ok
<seb128> http://www.debian.org/devel
<jdub> if you're building it for yourself, you don't need it signed
<jdub> you're testing ;)
<mxpxpod> jdub: good point :)
<jdub> but, if you've fixed stuff up
<sivang> jdub : you a know a good way to have nautilus-cd-burner not finalize a cd?
<jdub> do your build like this:
<jdub> dpkg-buildpackage -S -rfakeroot -uc -us
<jdub> that'll do a source build only
<sivang> jdub : this seems to be ellusive on the gui
<jdub> which can be checked, signed and uploaded to universe
<mxpxpod> jdub: ah, ok
<jdub> sivang: i don't think it can
<mxpxpod> jdub: oh, I know where the 2.4.5 stuff came from... it came from debian's source stuff
<seb128> yes
<sivang> jdub : darn
<jdub> mxpxpod: universe is debian main, frozen a few months back
<seb128> mxpxpod: most of the packaged are from the debian archive
<jdub> mxpxpod: if you want newer packages, we can sync things from sid
<mxpxpod> jdub: ah, ok
<mxpxpod> jdub: well, I have a deb-src line that grab's sid's current sources
<jdub> mxpxpod: if they build on warty (or you have patches), that is ;)
<seb128> I *hate* changes in the diff.gz
<sivang> jdub : there a list of packages that needs security sync from sid, would you like me to mail you?
<jdub> mxpxpod: hrm, unless you definitely know you want to use those, try working with the existing versions in universe as much as possible
<jdub> sivang: no, that's mdz's gig :)
<sivang> jdub : k ;-)
<mxpxpod> jdub: well, universe has 2.4.2, and it would be nice to have 2.4.5 since it's got a couple of fixes in
<lamont> mdz/jdub about?
<jdub> lamont: i am
<jdub> mxpxpod: ok
<lamont> I, um, have a proposed fix for #1577
<lamont> ..
<jdub> mxpxpod: for this release, we're not worrying too much about freezeness in universe :)
<jdub> mxpxpod: in later releases, it'll freeze just like everything else
<mxpxpod> jdub: ok, cool
<mxpxpod> jdub: gotcha
<lamont> (A) shipping an RC is really, really, ugly.  (B) 9.2.4 just released, (C) upstream is good about not releasing until they've fixed things. (D) it's been verified to fix #1577.
<lamont> jdub: can we sync it from debian? please, please, please, please
* lamont grovels
<mxpxpod> jdub: the reason I'm worried about *mm stuff is that I think I'm going to make a release of coaster in the next few weeks, and I want people to be able to use it
<jdub> mxpxpod: rad
<mxpxpod> jdub: :)
<mxpxpod> jdub: so, I'll need to hack up a gnome-vfsmm2.8 package for us too
<jdub> lamont: i'm going to defer to mdz on this one, sorry :-)
<jdub> lamont: it has my approval if he's happy with it
<jdub> mxpxpod: there's no debian package?
<mxpxpod> jdub: not for 2.8... just 2.6
<mxpxpod> jdub: I should email bradley
<lamont> jdub: well, that's one down, anyway...
<jdub> seb can teach you sexy ways of handling that :)
<lamont> hrm... mdz is almost certainly still asleep
<mxpxpod> jdub: teach me?
<jdub> mxpxpod: packaging-fu
<mxpxpod> lol
<mxpxpod> ok
<sladen> could people have a quick test of:  http://www.paul.sladen.org/ubuntu/cpufreq-detect.sh  if possible and tell me when it doesn't work
<seb128> oh, just remember
<mxpxpod> brb
<seb128> jdub: what do you think about turning on the tab-groups extension in epiphany-extensions ?
<jdub> $ ./cpufreq-detect.sh
<jdub> speedstep-smi.o
<jdub> seb128: dunno
* T-Bone wonders why firefox doesn't account his "stop button hit" (still proxy problem), and why the menus are empty
<jdub> $ sudo modprobe speedstep-smi
<jdub> Password:
<jdub> FATAL: Error inserting speedstep_smi (/lib/modules/2.6.8.1-2-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): No such device
<jdub> 
<jdub> ;-)
<jdub> $ lsmod | grep cpu
<jdub> cpufreq_userspace       5240  2
<jdub> cpufreq_powersave       1728  0
<jdub> 
<jdub> $ lsmod | grep speed
<jdub> speedstep_lib           4100  0
<jdub> 
<jdub> sladen: helpful?
* sladen ponders
<sladen> jdub: do you already have another module setup and working?
<jdub> yes
<jdub> which appears to be speedstep_lib
<sladen> jdub: groovy, what's  grep '^model name' /proc/cpuinfo ?
<jdub> model name      : Intel(R) Pentium(R) M processor 1.40GHz
<sladen> jdub: okay, could you confirm that  modprobe -r speedstep_lib  ; modprobe speedstep  is all that you need to do?
<sladen> er.  speedstep_lib
<thom> um, it claims speedstep_smi for me, too. but speedstep_centrino is the one that works
<jdub> it's working without that loaded
<sladen> thom: what's your   grep '^model name' /proc/cpuinfo
<thom> virelais:~# sh cpufreq-detect.sh
<thom> speedstep-smi.o
<thom> virelais:~# cat /proc/cpuinfo |grep "model name"
<thom> model name      : Intel(R) Pentium(R) M processor 1200MHz
<thom> virelais:~# modprobe speedstep_smi
<jdub> but i still have cpufreq_ ones in there
<thom> FATAL: Error inserting speedstep_smi (/lib/modules/2.6.8.1-2-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): No such device
<mxpxpod> jdub: if I compile these packages for ubuntu, do you want me to make a changelog entry?
<sladen> thom: is that a P4-M ?
<thom> yeah
<jdub> mxpxpod: you have to, to change the version nubmer
<jdub> mxpxpod: basically
<jdub> mxpxpod: run 'dch'
<jdub> sorry
<jdub> 'dch -i'
<jdub> then change the version number like this:
<mxpxpod> jdub: before I compile?
<jdub> 2.6.4-2 becomes 2.6.4-2ubuntu1
<jdub> mxpxpod: yes
<mxpxpod> jdub: ok
<mxpxpod> jdub: oh, I had a question about dch yesterday... which environment variables do I need to set in my .bashrc?
<jdub> hrm, probably not worth doing that
<jdub> i have ~/bin/uch
<jdub> which looks like:
<jdub> #!/bin/sh
<jdub> export DEBEMAIL=jeff.waugh@canonical.com
<jdub> exec dch -i -D warty $@
<jdub> 
<mxpxpod> how does it get your name?
<daniels> from the passwd file
<mxpxpod> oh, rightg
<mxpxpod> -g
<lamont> #!/bin/sh
<lamont> export LANG=C
<lamont> export DEBEMAIL="lamont@mmjgroup.com"
<lamont> export DEBFULLNAME="LaMont Jones"
<lamont> VERS=""
<lamont> if (( $# >= 1 )) && [ "$1" = "-i" ]  && [ -f debian/changelog ] ;then
<lamont>   V=$(sed -n '1,1s/^.*(\(.*\)).*$/\1/p' debian/changelog)
<mxpxpod> jdub: do I need the -D warty?
<lamont>   if [ "$V" = "${V%ubuntu*}" ] ; then
<lamont>         shift
<lamont>         VERS="--newversion ${V}ubuntu1"
<jdub> mxpxpod: yes
<lamont>   fi
<jdub> lamont: :-)
<lamont> fi
<lamont> dch -D warty $VERS "$@"
<jdub> *nice*
<lamont> it does require that -i be the _FIRST_ option, though...
<lamont> the real trick is remembering to _not_ say that for debian uploads... :-)
<mxpxpod> lamont: why not just put -I in  your exec?
<lamont> mxpxpod: I sometimes don't want -i
<mxpxpod> whoops, -i
<lamont> that code basically says 'if they said -i, and it's not already an ubuntu* version, then change the -i to --newversion ..ubuntu1, otherwise just pass the -i through'
<mxpxpod> ah, ok
<mxpxpod> now, when the editor comes up after I type ~/bin/uch -i, I just enter regular changelog entries?
<mxpxpod> jdub: ^
<daniels> mxpxpod: yah
<mxpxpod> daniels: ok, it creates a changelog.dch... it doesn't merge into the changelog
<T-Bone> lamont: ping
<daniels> mxpxpod: it should merge into the changelog after you write and exit
<mxpxpod> daniels: hrmm... doesn't seem to do it with gvim
<lamont> yo
<lamont> T-Bone: let me guess... issues building the chroot?
<jdub> seb128: nautilus scripts don't seem to work
<T-Bone> lamont: bingo
<T-Bone> lamont: don't have warty.buildd
<lamont> grab that from a warty box.
<seb128> jdub: dpkg -l shared-mime-info ?
<lamont> and then you need to edit it. :-(
<T-Bone> lamont: rephrasing:
<T-Bone> lamont: don't have warty.buildd on a warty box
<thom> lamont: we could just get the ones off the buildds
<lamont> apt-get update; apt-get install debootstrap
<T-Bone> lamont: already did that
* lamont uploaded debootstrap ubuntu17 yesterday with the file
<T-Bone> rephrasing
<mxpxpod> grr... dch doesn't like gvim at all
<lamont> ...
<T-Bone> lamont: don't have warty.buildd on a warty box after installing debootstrap
<lamont> which version?
<T-Bone> 0.2.39ubuntu17 (freshly installed)
* lamont checks, screams
<lamont> just a minute
<thom> lamont: did that pbbuttonsd upload fix powerprefs/gtkpbbuttons?
<lamont> thom: will check
<thom> danke
<lamont> t-bone: people.no-name-yet.com/~lamont/warty.buildd  ubuntu18 coming soon.  sigh.
<T-Bone> lol thx
<seb128> jdub: "Hardware request : eagle-usb driver" <- grrrrrrrrrrr, I've mailed the devel list about this 1 one week ago and nobody care about replying :(
<seb128> this package is not big and damn useful for some people
<jdub> seb128: you can upload it to universe, no problem
<seb128> jdub: universe is not good
<lamont> T-Bone: or you could apt-get source debootstrap, and extract it from there. GAH!
<seb128> jdub: we want it on the CD, or people can't have a net access and download the package
<T-Bone> lamont: to recap, i'm debootstraping on a sarge ia64 box, using warty.buildd. Are the special options you gave me still valid?
<jdub> seb128: where is it at the moment? only in debian?
<seb128> yes
<seb128> we have eagle-adsl in universe
<mxpxpod> does anyone here use dch with gvim?
<seb128> is has been renamed in eagle-usb in debian
<seb128> which works better
<lamont> T-Bone: the file I just gave you will still need --exclude=lsb-base
<jdub> seb128: happy for you to sync the debian package to replace it
<seb128> jdub: please read my mail on ubuntu-devel about this, I've included the details
<T-Bone> lamont: and taht's all? or kernel-headers are needed too?
<jdub> seb128: then shift it into supportedseed/shipseed
<lamont> but the --include isn't needed (nor should it be..)
<jdub> seb128: with confirmation with matt
<seb128> jdub: ok, thanks !
<seb128> jdub: and about your version of shared-mime-info ? 
<lamont> linux-kernel-headers _is_ included, it's just that libc6-dev Depends it, and the script had ordering issues...
<T-Bone> lamont: ok, hold on
<jdub> seb128: my which? :)
<seb128> <jdub> seb128: nautilus scripts don't seem to work
<seb128> <seb128> jdub: dpkg -l shared-mime-info ?
<seb128> don't ignore the question dude :p
* seb128 thinks you still have 0.14 :)
<jdub> oh
<jdub> 0.14-1.1
<seb128> the fix is the libxml2/s-m-i upload you've approved 2 hours ago :p
<lamont> T-Bone: and then there's the issue that snapshot.debian.net is b0rked
<lamont> date specs don't completely work...
<jdub> seb128: boh ;)
<lamont> T-Bone: so little things like linux-kernel-headers and apt aren't in that repository...
<T-Bone> lamont: do you have other niceties to tell me ? ;)
<lamont> give me a few mintuew
<T-Bone> lol
<T-Bone> lamont: i shall fire some very heavy stuff at you ;^)
<lamont> T-Bone: starting with a sarge chroot won't work (too new), and starting with woody is just plain painful.
<T-Bone> lamont: debootstrap currently fetching files without errors for now
<lamont> and you can't do what I did, which was start with a snapshot that we made of sid on freeze day.  (since we didn't snap ia64...)
<T-Bone> lamont: would sbuild help me rebuilding everything, or should i do that "by hand"?
<lamont> right.  There's some extra fun to deal with down the road...
<lamont> sbuild is your friend.
<T-Bone> (i'm up to libc6, currently)
<lamont> libc6.1, I hope...
<mxpxpod> jdub: if I'm just compiling debian source packages for ubuntu, do I need to add a changelog entry?
<T-Bone> lamont: correct ;)
<jdub> mxpxpod: if you make a change, yes
<mxpxpod> jdub: what if no change is made
<jdub> mxpxpod: if not, lamont can sync them directly into universe
<mxpxpod> jdub: oh, ok
<mxpxpod> lamont: can you sync libsigc++2.0, glibmm2.4, and glibmm2.4?
<lamont> mdpxpod: wanna send me an email with the whys and such, and I'll forward it along.
<mxpxpod> lamont: to who?
<lamont> it goes to jdub, mdz, and elmo
<mxpxpod> ah, ok
<lamont> jdub/mdz approve, elmo syncs
<mxpxpod> lamont: email addy?
<T-Bone> lamont: up to 'tar' ;)
<lamont> lamont@canonical.com
<seb128> fabbione: here ?
<lamont> T-Bone: did you happen to notice if it fetched either linux-kernel-headers or apt??? :-(
* T-Bone looks
<lamont> it didn't for me...
<T-Bone> lamont: apparently not. and it fucked up on libc6
<lamont> so once the debootstrap fails, then you:
<seb128> jdub: hum, the current package of esound uses --disable-alsa ... do you see a reason to keep that ?
<lamont>  wget http://snapshot.debian.net/archive/2004/06/03/debian/pool/main/l/linux-kernel-headers/linux-kernel-headers_2.5.999-test7-bk-16_ia64.deb 
<lamont> stuff that in the chroot, dpkg -i it, redo debootstrap (yeah, that's bad...)
<lamont> then wget http://snapshot.debian.net/archive/2004/06/10/debian/pool/main/a/apt/apt_0.5.25_ia64.deb
<T-Bone> gack
<lamont> and shove that in the chroot
<lamont> and install it
<lamont> and apt-get update
<lamont> er, after creating a good sources.list, that is...
<lamont> deb http://snapshot.debian.net/archive/2004/06/28/debian unstable main
<lamont> deb-src http://archive.ubuntu.com/ubuntu warty main restricted universe
<lamont> and then you'll be ahead of me.
<lamont> eta 12 minutes on the apt-get update
<lamont> T-Bone: yes, well... snapshot.debian.net's date-specs are known to be br0ken.
<T-Bone> lamont: rerunning debootstrap on the previously debootstrap'd chroot, right?
<lamont> so we'll probably wind up polluting the hell out of this chroot to get main built, etc..
<lamont> yes.
<T-Bone> k
<T-Bone> in progress
<lamont> which is just so sick and wrong, but works.
* lamont looks to make sure Kamion isn't watching
<thom> i should get this going on sparc, too
<lamont> So really, step 1 is Debug the chroot into existance
<lamont> thom: I was planning to wait until late october to do this.
<lamont> t-bone is in a hurry though.
<thom> give me something to do between firefox builds
<T-Bone> lamont: getting tons of unmet deps
<lamont> thom: bounced you my email to t-bone
<lamont> yeah - those are normal.
<lamont> well, less of them is more normal...
<T-Bone> shit, libc6dev depends on linux-kernel-headers hower...
<T-Bone> s/hower/however/
<T-Bone> looks like it didn't work
<thom> lamont: grazil
<lamont> the next step after the apt-get update is to look at warty.buildd, and figure out what other packages are missing from 2004/06/28 on snapshot.d.n
<lamont> T-Bone: after the first debootstrap fails with libc6.1-dev depends l-k-h, then you chroot in to the chroot, dpkg -i linux-ker....deb, drop back out and re-run debootstrap
<T-Bone> lamont: exactly what i did
<T-Bone> didn't work
<lamont> how did it die?
<T-Bone> package l-k-h not installed
<lamont> the lkh install, how did that die?
<T-Bone> didn't die
<lamont> oh, after dpkg -i, do dpkg --configure -a
<lamont> er, s/-a/--pending/
<T-Bone> bummer ;)
<lamont> the chroot is pretty resilliant...
<T-Bone> gandalf:/# dpkg --configure --pending
<T-Bone> dpkg: dependency problems prevent configuration of libc6.1-dev:
<T-Bone>  libc6.1-dev depends on linux-kernel-headers; however:
<T-Bone>   Package linux-kernel-headers is not installed.
<lamont> dpkg -l linux-kernel-headers (in the chroot)
<T-Bone> un  linux-kernel-h <none>         (no description available)
<T-Bone> wtf?
<lamont> could it be that you installed it outside the chroot?
<T-Bone> nop i didn't
* T-Bone redoes dpkg -i
<mxpxpod> lamont: in my email, do you want changelog entries to show what's changed?
<T-Bone> ii  linux-kernel-h 2.5.999-test7- Linux Kernel Headers for development
<T-Bone> lamont: the hell if i understand :P
* lamont is using debootstrap 0.2.39
<lamont> mxpxpod: yes
<mxpxpod> lamont: okey dokey
<lamont> well, at least an explanation of what's changed, and why we care enough to sync.
<T-Bone> un  linux-kernel-h <none>         (no description available)
<mxpxpod> lamont: I'll just put in changelogs :)
<T-Bone> lamont: debootstrap is messing up with my l-k-h manual setup
<lamont> which version debootstrap?
<T-Bone> still the same
<T-Bone> oops
<T-Bone>  0.2.45   
<lamont> yeah - it must have gotten smarter..
<T-Bone> shit
<T-Bone> we don't want it to be smarter, do we?
<lamont> no.  we want it stoooopid
<T-Bone> damn st0000pid :)
<T-Bone> so, what's next?
<lamont> hit snapshot.d.n, debootstrap, and grab 0.2.39
<T-Bone> lamont: and i install it on my sarge box, right?
<lamont> yes
<mxpxpod> lamont: sent
<T-Bone> lamont: still the same
<T-Bone> doesn't work
<lamont> thom: I'm going to write a 'so you want to bootstrap an architecture' paper when I'm done...
<seb128> jdub: nevermind about esound/alsa, was my error
<lamont> t-bone: gimme a minute
<T-Bone> lamont: do i still want the --exclude flag?
<T-Bone> lamont: when i'm done, i'll bootstrap hppa ;)
* T-Bone ducks
<lamont> T-Bone: I would love for you to debootstrap hppa.
* lamont builds a tarball for t-bone
<T-Bone> lamont: heh, if i don't have a receipe, i won't be able to do hppa ;)
<lamont> t-bone: (1) do what it takes to make a chroot with 06/28 bits.
<lamont> did 0.2.39 not install, or did it produce the same issues?
<T-Bone> produced the same issues
<T-Bone> lamont: this is the kind of receipe i enjoy a lot. It leaves everything up to the cook chief ;)
<thom> my sparc has the loudest disks in the history of the world ever :/
<T-Bone> thom: the cool thing with ia64 or big hppa boxes, is that you _can't_ here the HDs ;)
<lamont> people.no-name-yet.com/~lamont/chroot-warty_ia64.tar.bz2 will be complete in about 3 mintues
<T-Bone> s/here/hear/
<thom> T-Bone: heh
<lamont> T-Bone: WHAT??? :-)
<T-Bone> lamont: ok, ping me again when it's ready, so that I'll suck it asap
<T-Bone> lamont: LOL ;)
<lamont> T-Bone: so step 1 for you becomes 1a) untar the beast and then...
<T-Bone> lamont: and then i'll need your help to setup sbuild ;)
<lamont> right
<lamont> was just looking at that...
<T-Bone> hehe
<elmo> lamont: it doesn't fix it :(
<lamont> for file in var/debbuild/avg-build-times var/debbuild/avg-build-space; do install -m0664 -o${USER} -gbuildd /dev/null ${chroot}/${file}; done
<lamont> fix etc/apt/sources.list
<elmo> tsig.c:293: REQUIRE(targetp != ((void *)0) && *targetp == ((void *)0)) failed.
<elmo> zsh: abort      nsupdate
<lamont>     grep -q "^${USER}:" ${chroot}/etc/passwd ||
<lamont>         getent passwd ${USER} >> ${chroot}/etc/passwd
<lamont>     grep -q "^buildd:" ${chroot}/etc/group ||
<lamont>         getent group buildd >> ${chroot}/etc/group
<lamont>     grep -q "^${USER}:" ${chroot}/etc/shadow ||
<lamont>         echo ${USER}:\*:$(getent shadow ${USER} | cut -d: -f3-9) >> ${chroot}/etc/shadow
<lamont>     grep -q "^proc-${USER}-$rel$flavor " /etc/fstab ||
<lamont>         echo proc-${USER}-$rel$flavor ${UHOME}/${chroot}/proc proc rw 0 0 >> /etc/fstab
<lamont>     mount proc-${USER}-$rel$flavor || true
<lamont>     [ -f /etc/source-dependencies-${rel}${flavor} ]  || 
<lamont>         :> /etc/source-dependencies-${rel}${flavor}
<lamont> ew.  sorry about the flood.
<T-Bone> lamont: actually i think it'd be much simpler for you to mail me that ;P
<lamont> elmo: that's not fixed?
<lamont> T-Bone: yea
<T-Bone> lamont: ETA?
<elmo> lamont: the first one I tried worked - the second didn't :(
<lamont> T-Bone: scp done
<lamont> T-Bone: script sent, extract as needed.. :-)
<T-Bone> lamont: wget in progress
<lamont> thom: take steps from /usr/share/buildd-config/build-chroot on any buildd
<lamont> thom: t-bone got the sanitized script
<T-Bone> lamont: ok, chroot extracted
<T-Bone> lamont: anything i should change to your script?
<lamont> elmo: would it be extremely painful to use the wayback machine to get the .debs for everything in hoglet for all architectures?
<lamont> T-Bone: yeah - just read it and do what it says..
<lamont> that script starts from scratch, and builds a warty chroot, assuming that you have a warty repository to start from.
<lamont> so find the debootstrap, and start right after that.
<T-Bone> lamont: so it's to be run within the warty chroot?
<lamont> the pinning probably needs some tlc, etc.
<lamont> no.
<lamont> that runs outside the chroot, to _BUILD_ the chroot
<lamont> but we don't meet the conditions it requires (we're bootstrapping...)
<elmo> lamont: huh?  why on earth do you want hoglet?
<lamont> elmo: what I really want is a coherent sid as of June 28
<lamont> snapshot.debian.net's datespec Packages files are rather, um, sparse.
<lamont> T-Bone: in that chroot, apt-get install build-essential, btw.
<T-Bone>  for file in var/debbuild/avg-build-times var/debbuild/avg-build-space Curren
<T-Bone> tlyBuilding; do
<T-Bone> this is relative to the chroot i guess?
<lamont> yeah
<lamont> you can skip CurrentlyBuilding, btw
<lamont> T-Bone: more to the point, it uses ${chroot}${file} :-)
<lamont> elmo: and I don't care if it's sid or sarge.
<elmo> lamont: we just keep the files not the packages files - I don't see any sane way to get what you're asking - can't you just do the double bootstrap thing?
<T-Bone> lamont: so i skip the for loop, but i have to edit sources.list, right?
<lamont> elmo: OK.  was hoping for something trivial
<lamont> yes
<lamont> the sources.list in the tarball points to 'ia', and you want 'archive.ubuntu.com'
<lamont> otherwise, it's right
<T-Bone> ok
<ore> Hi
<ore> is there someone behind mailman@lists.ubuntu.com?
<lamont> elmo: the issue is that debootstrap wants _one_ mirror, and we ain't got one.  (Although snapshot.d.n comes close...)
* thom drums fingers
<thom> retreving perl
<T-Bone> btw: i have a funny bug: when i login to my warty box, the "X" cursor appears on the center of the screen, but it's not the actuall arrow cursor. It stays there on top of everything
<lamont> thom: no complaining: 8% [3 binutils 1422412/2996kB 47%]                              3511B/s 1h17m42s
* lamont unthrottles
<lamont> 6 minutes is a biit better...
<T-Bone> lamont: you have to be kidding ;^)
* T-Bone ducks
<lamont> T-Bone: wierd.
* lamont has (had) about 200 MB of headroom in his bandwidth budget
<T-Bone> lamont: i remove all other entries in the sources.list, or i add the new ones?
<thom> unpacking libc6
<lamont> in the tarball, there should only be 2...
<T-Bone> right
<lamont> deb http://snapshot.debian.net/archive/2004/06/28/debian unstable main
<lamont> deb-src http://ia/ubuntu warty main restricted universe
<T-Bone> yep
<lamont> is what I'm using,
<lamont> that's all you want
<T-Bone> oh
<lamont> for _this_ chroot
<T-Bone> hmm
<T-Bone> ah
<T-Bone> bummer
<T-Bone> let me recap
<T-Bone> once i have unpacked your chroot, what should I do? ;)
<thom> we, i have a chroot
<lamont> T-Bone: in the chroot, apt-get install build-essential
<lamont> then
<T-Bone> done
<lamont> any files/directories created by the script after the chroot should happen, minus sources.list
<lamont> including mods to chroot's passwd,group, and shadow files
<lamont> create chroot/proc, and mount it (mount happens outside the chroot)
<T-Bone> done
<lamont> touch /etc/source-dependencies-warty
<lamont> (outside)
<lamont> apt-get install sbuild
<T-Bone> outside?
<T-Bone> the touch is outside the chroot?
<lamont> yeah - sbuild fetchs things outside the chroot, using sources.list inside the chroot
<T-Bone> ah true
<lamont> so it looks for /etc/source-dependencies-${THING}
<T-Bone> yeah i recall
<T-Bone> sbuild installed (outside)
<T-Bone> chroot-warty# cp -a /etc/passwd /etc/group /etc/shadow etc/
<lamont> T-Bone: lazy.  my hacks only add the user, and don't copy the shadow password file..
<T-Bone> lol
<lamont> this is untrusted code running in the chroot, after all.
<T-Bone> lamont: this is a box freshly installed, i am the only user on it
* lamont points t-bone at the other window
<T-Bone> and it'll be fully dedicated to build everything for ubuntu
<T-Bone> got it
<lamont> kewl
<lamont> once it's all built, we'll use your repository to bootstrap the buildd's repository, and then build everything from scratch there, of course.. :)
<lamont> and then you sbuild -dwarty ed_0.2-20
<lamont> hrm...  do you have ~/.sbuildrc?
<lamont> and ~/logs
<T-Bone> no
<T-Bone> lemme grab it from the hppa sbuild
<lamont>         install -d -o${USER} -m0750 logs mqueue old-logs stats stats/graphs upload
<lamont> in your home dir
<T-Bone> lamont: would it be easier for me to run sbuild as root?
<lamont> make sure that /var/debbuild exists (outside)
<lamont> no
<lamont> doesn't help
<lamont> although the user needs to have full sudo wide open with no password...
<T-Bone> visudoing
<lamont>         mkdir -p /var/debbuild/srcdep-lock
<lamont>         touch /var/debbuild/avg-build-times /var/debbuild/avg-build-space
<lamont>         chown -R ${USER}:buildd /var/debbuild/
<seb128> lamont: do you know why mime-shared-info is missing on i386 ?
<seb128> the build log is ok
<T-Bone>  ${USER}:buildd ?
<seb128> lamont: oups, shared-mime-info <- right name
<T-Bone> lamont: any way i can avoid the damn thing to mail me everything?
* T-Bone considers mailing stuff to some gmail storage he has ;)
<lamont> seb.  sigh
<lamont> T-Bone: set up mail on the local machine, or see /usr/bin/sbuild
<lamont> sbuild --nolog
<T-Bone> will setup on local machine
<T-Bone> we might need logs no matter what
<lamont> but that doesn't give you log files at all, which is bad
* T-Bone ^5s lamont ;)
* T-Bone points lamont at the other window
<lamont> $mailprog="/bin/true";   :)
<T-Bone> lol
<T-Bone> perfect ;)
<T-Bone> ok
<T-Bone> what's next?
<lamont> sbuild -dwarty ed_0.2-20
<T-Bone> varenet@gandalf:~$ sbuild -dwarty ed_0.2-20
<T-Bone> Bad distribution
<T-Bone> sigh
<jdub> oh man
<lamont> is the chroot named chroot-warty?
<jdub> did i miss an sbuild tute?
<T-Bone> yes
<lamont> doh.
<T-Bone> jdub: you did ;)
<jdub> oh man
<lamont> damn debian sbuild
<lamont>                 #die "Bad distribution\n"
<lamont>                 #       if !isin($main::distribution, keys(%main::dist_order));
<lamont> you need to add the #'s to your file.. :-)
<T-Bone> jdub: don't worry. lamont volunteered to write it down
<T-Bone> lamont: where is it?
<lamont> /usr/bin/sbuild
<lamont> about line 570 or so
<jdub> lamont: the sbuild package is poo, right? and real sbuild is maintained elsewhere?
<lamont> search for Bad distribution :-)
<lamont> jdub: yes
<T-Bone>  $main::distribution = "unstable" if $main::distribution eq "u";
<T-Bone>                 die "Bad distribution\n"
<lamont> and we had to fork
<lamont> t-bone; the die, and the line _following_
<jdub> lamont: can we have elite sbuild in ubuntu?
<T-Bone> lamont: yeah. I trash them both?
<T-Bone> jdub: we can have 3l33t only ;)
<lamont> jdub: chinstrap:~lamont/archive has our sbuild et al
<jdub> ahr!
<lamont> t-bone: yes.
<T-Bone> varenet@gandalf:~$ sbuild -dwarty ed_0.2-20
<T-Bone> varenet@gandalf:~$ 
<lamont> I added this after the options parsing:
<T-Bone> that was quick :P
<lamont> die "Need distribution\n" if $main::distribution eq "bogus";
<lamont> and set distribution=bogus above
<lamont> it's a small package, or it died
<lamont> ls, should have ed_0.2-20_ia64.changes
<lamont> et al
<T-Bone> Checking available source versions...
<T-Bone> /usr/bin/apt-cache failed
<lamont> you were root when you untarred, yes?
<T-Bone> yes
<lamont> and ls chroot-warty/proc shows stuff, not an empty dir?
<azeem> is proc really needed for sbuiling?
<T-Bone> /proc on /home/varenet/chroot-warty/proc type none (rw,bind)
<lamont> sudo chroot chroot-warty apt-get update
<lamont> azeem: there are things that won't build without it, or (worse) build incorrectly
<T-Bone> lamont: ah, that's it. I forgot the visudo step ;)
<lamont> T-Bone: sbuild doesn't auto-update either.
<lamont> the buildd normally does that
<azeem> lamont: ok, but not in the general case
<lamont> azeem: right.  But t-bone is trying to build everything...
<azeem> ok, ok
<T-Bone> lamont: i must have crap in my sources.list. Got 404s
<lamont> T-Bone: and remember, if you don't redirect stdin away from a tty (at least), then there is at least one package whose build hangs...
<lamont> T-Bone: ??
<lamont> what do you have?
<T-Bone> lamont: what's the full domain name for 'ia' please?
<lamont> archive.ubuntu.com
<lamont> ia is my throttled mirror - you wouldn't like it.
<T-Bone> much better
* lamont _did_ say to change that... :-)
<T-Bone> lol
<T-Bone> you _did_ confuse me ;)
<lamont> now parse chroot-warty/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_warty_main_source_Sources to build a list of source_version's, and feed that to sbuild
<seb128> lamont: about shared-mime-info ?
<lamont> that'd be step (2) from the mail..
<lamont> seb128: fixed
<seb128> ok thanks
<lamont> seb128: when I kill buildd on a machine, I expect it to stay dead.
<T-Bone> Cannot opendir chroot-warty/var/debbuild/srcdep-lock: No such file or director
* T-Bone curses lamont
<T-Bone> you said that was _outside_ ;P
<lamont> T-Bone: it's both
<T-Bone> Waiting for job(s) 1 to finish
<T-Bone> it's stuck on that, fwiw
<lamont> kill lots of stuff
<thom> lamont is good at the confusion
<lamont> t-bone: and mkdir chroot-warty/build/varenet (and chown)
<lamont> thom: ??
<lamont> oh, the kill buildd comment?
<thom> lamont: just generally
<T-Bone> lamont: still stuck
<T-Bone> lamont: i don't think that's normal
<T-Bone> ah that's it
<T-Bone> ok, trying again
<T-Bone> Couldn't cd to chroot-warty/build/varenet/: No such file or directory
<T-Bone> grrrr
<lamont> <lamont> t-bone: and mkdir chroot-warty/build/varenet (and chown)
<T-Bone> lol
<T-Bone> Built successfully
<T-Bone> YATTA
<T-Bone> so, now, i have to produce a list of packages to feed sbuild with
<lamont> <lamont> now parse chroot-warty/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_warty_main_source_Sources to build a list of source_version's, and feed that to sbuild
<thom> i could get _really_ bored of building firefox
<lamont> yeah: grep out Package and Version from that
<thom> and i've just broken my sparc
<thom> gar
<lamont> thom: how borke?
<thom> refusing ssh connections
<T-Bone> lamont: it's storing everything in my homedir. Any way i can change that?
<thom> i'll fix it when i stop using that monitor for watching dvds
<lamont> T-Bone: umount chroot-warty/proc; mkdir build; mv chroot-warty build; fix the mount point, remount.
<lamont> and then run sbuild from inside build
<lamont> thom/jdub: if you use _our_ sbuild, then you do care about ${chroot}/CurrentlyBuilding
<lamont> which must be writable by the user running sbuild
* T-Bone tries to figure out how to easily merge Package and Version fields
<lamont> T-Bone: be lazy.
<lamont> apt-get install quinn-diff
<T-Bone> lamont: sure, i'd like to :P
<lamont> fetch warty Sources
<T-Bone> in the chroot?
<lamont> quinn-diff -A ia64 -p /dev/null -s Sources
<lamont> outside
<lamont> but you do have the Sources file in the chroot already
<mdz> morning
<T-Bone> lamont: ok, that gives me lines like "libs/libwnck_2.8.0-0ubuntu1.dsc [optional:uncompiled] "
<T-Bone> can i feed that to sbuild directly?
<lamont> no.
<lamont> sed 's:^.*/\(.*\).dsc.*:\1:
<lamont> '
<T-Bone> just great ;)
<T-Bone> [quinn-diff] : warning: ubuntu-sounds has an architecture field of "all" which doesn't include ia64.
<lamont> yeah, but that's easier...
<T-Bone> should i ignore these?
<lamont> yeah
<lamont> it is... :-)
<T-Bone> =)
<lamont> those are packages that have no arch-dep component
<T-Bone> oic
<lamont> so they're _ALREADY_BUILT_ for your architecture!!! :-)
<T-Bone> bummer
<T-Bone> yeah true. I just wondered why this would make a warning
<T-Bone> ok so no big time for xargs, right?
<T-Bone> s/no/now/
<lamont> quinn-diff wants to be run intelligently...
<T-Bone> lol
<T-Bone> that's a crime ;)
<lamont> xargs not needed for main, dunno about universe...
<T-Bone> no, i mean "cat list | xargs sbuild"
* lamont said: sbuild -dwarty $(</tmp/zz) < /dev/null >/dev/null 2>&1 &
<T-Bone> lol
<T-Bone> fine!
<lamont> that takes about 48 hours or so on a good x86 machines, iirc
<T-Bone> started
<lamont> if I had bandwidth, we could share... :-(
<T-Bone> don't worry
<T-Bone> btw, i wonder if it'll take advantage of SMP
<T-Bone> i guess no
<lamont> and now you have time to kill while that runs, figuring out the CD stuff on i386.
<lamont> marginally
<lamont> only in that gcc and as and ld will run on separate cpus...
<T-Bone> correct
<lamont> then when the build finishes and you know how to make CD's, then you can make d-i work on ia64.
<T-Bone> well, it should be pretty fast. Dual mckinley 900Mhz with 4GB RAM
<lamont> while the total flush/rebuild happens
<lamont> shouldn't be tooo bad
<T-Bone> lamont: hehe, that'd be quite nice ;)
<T-Bone> you betcha!
<T-Bone> lamont: or else, i can start an hppa bootstrap in the meantime ;)
* T-Bone ducks
* T-Bone has a L1000 currently idling on setiathome
<lamont> T-Bone: go for it.
<T-Bone> lol
* lamont has no time, and no machine currently - busted kernel needs help
<lamont> and see issue #1. :(
<lamont> _and_ it's a b180.
<T-Bone> lamont: the problem is debootstrap actually
<T-Bone> #1N
<T-Bone> s/N/?/
<lamont> * lamont has no time,
<T-Bone> lol
<T-Bone> so you'd better deal with porting d-i later, right?
<lamont> gimme root on the box, and I'll give you a chroot
<T-Bone> sure np
<T-Bone> hold on
<lamont> I figured you'd be the hppa/ia64 d-i god, dude...
<T-Bone> lol
<T-Bone> i've never touched d-i yet ;)
<lamont> ditto
<T-Bone> gonna have fun ;)
<T-Bone> lamont: send me an ssh2 pubkey please
<T-Bone> i wonder if i shouldn't setup a local mirror of warty sources
<T-Bone> if i'm going to run two test buildds, i'd need to spare bandwidth
<lamont> want my scripts?
<T-Bone> sure!
<T-Bone> lamont: a rough idea of the disk space needed?
<lamont> warty main, restricted, and a bit of universe, for i386 and source --> 3.8GB
<T-Bone> that's tiny!
<T-Bone> let's go for it
<T-Bone> lamont: please send me your scripts along with a ssh2 key
<lamont> ok
* T-Bone notices the other window
<lamont> mdz?
<npmccallum> is there anyone here that can do debuggin on a samba/smb setup?
<npmccallum> (ie. you have windows)
<npmccallum> (or are using samba for printer sharing)
<mdz> lamont: ?
<lamont> 1577.. I'd like to just sync..
<lamont> (yeah, I know...)
<lamont> <lamont> (A) shipping an RC is really, really, ugly.  (B) 9.2.4 just released, (C) upstream is good about not releasing until they've fixed things. (D) it's been verified to fix #1577.
<lamont> <lamont> jdub: can we sync it from debian? please, please, please, please
<lamont> <jdub> lamont: i'm going to defer to mdz on this one, sorry :-)
<lamont> <jdub> lamont: it has my approval if he's happy with it
<mdz> lamont: it's not even in unstable yet :-)
<lamont> well, yeah
<lamont> but it will be in 45 minutes...
<thom> thunderbird 0.8 looks like it sucks as much as 0.7, can i upload?
<npmccallum> mdz: I haven't heard anything about what we are allowed to change on the openoffice splash screen.  Do you want me to simply do something like: http://www.natemccallum.com/uooo.png ?
<thom> mdz: that was to you, sorry
<lamont> thom: you're supposed to say "0.8 looks like it sucks no more than 0.7, can I upload?" :-)
<thom> same odds :-)
<mdz> thom: yes
<thom> 'k
<thom> (i'm having to binary search through the patches and config for firefox to work out why find is broken, it's not fun)
<mdz> npmccallum: did you ask someone about the restrictions?
<npmccallum> mdz: I asked in #openoffice.org and on the mailing list
<mdz> npmccallum: and no one replied at all?
<npmccallum> mdz: mailing list == dev@distribution.openoffice.org
<npmccallum> mdz: no reply on the mailing list
<npmccallum> mdz: in the channel I got a "you're probably fine with whatever -- IANAL"
<npmccallum> mdz: as long as we stick close to what debian has done, there should be no problem for this release
<azeem> why don't you use the vanilla splash? Do you also brand evolution and so?
<npmccallum> mdz: vanilla splash is an option too
<sivang> T-Bone : so, a ia64 warty is expected?
<T-Bone> sivang: i'm not to one to tell
<sivang> T-Bone : good luck with setting up the sources and buildds !
<T-Bone> heh
<T-Bone> thx
<T-Bone> but that's not the most difficult part
<pitti> mdz: can you please take a look at #1599 and approve?
<pitti> mdz: this is half a step backwards, but I tried to make the new gnome-vfs2 play well with our system the whole day; I agreed with sabdfl that I should just upload a working version now and do the bonus work later, if there is more time
<thom> firefox is making baby jesus cry a frickin' river
<schweeb> thom: I'm about 2 more type-ahead-finds from an install of the old version
<pitti> schweeb: already done :-) Now that the feature is not available, I just recognized how useful it is :-)
<schweeb> pitti: well it works... somewhat/barely
<schweeb> and the backspace = go back a page is frigging killing me
<schweeb> just cause people use IE doesn't mean we can't make them fix their bad habits
<npmccallum> is there an authoritative mime type list anywhere?
<seb128> ?
<npmccallum> that I can browse/search through mime types...
<seb128> the files in /usr/share/mime/ ?
<seb128> /usr/share/mime/packages/freedesktop.org.xml
<teuf> I'd recommend looking at the corresponding .org.xml.in file from shared-mime-info source since it doesn't have all the translations
<pitti> seb128: I'm going to upload gvfs now (see #1599); it will also close #1636 (Trash); do you have any other changes to make?
<seb128> let me check
* lamont realizes that the reason he's hungry is that he forgot to get lunch.  bbiab
<seb128> pitti: apparently no, just go for it
<pitti> seb128: okay
<seb128> mdz: here ?
<mdz> seb128: yes
<mdz> npmccallum: if you have any doubts, just go with vanilla splash
<seb128> mdz: have you read my mail on -devel about eagle-usb las tweek ?
<mdz> npmccallum: mark said he was fine with that
<mdz> seb128: I remember seeing it
<seb128> mdz: there is a thread about it on -user today
<seb128> jdub said he's fine with uploading eagle-usb and to move it to supportedseed/shipseed if you're ok
<mdz> I am not familiar with the software; does it require kernel modules?
<mdz> how many packages do we need? there seemed to be several with similar names
<npmccallum> mdz: I'm also waiting for approval on #1630
<mdz> npmccallum: you added a conflicts: gnome-audio ?
<mdz> or something else?
<npmccallum> mdz: I also tweaked two of the sounds, but its not code related (just volume changes)
<mdz> npmccallum: ok, go ahead
<npmccallum> mdz: should we add a conflicts to gnome-audio as well?
<mdz> @#$@# xchat shortcuts
<seb128> mdz: yes, need a kernel module. The source package build a -src package for the module that's all
<npmccallum> mdz: should we add a conflicts to gnome-audio as well?
<mdz> seb128: can you send mail to -devel with all of the details about which packages we need?
<mdz> npmccallum: I thought you implied that you already did that
<seb128> mdz: ok
<mdz> npmccallum: did you fix #1630 some other way?
<npmccallum> mdz: I added "Conflict: gnome-audio" to the ubuntu-sounds package, should "Conflicts: ubuntu-sounds" go into gnome-audio as well?
<npmccallum> (gnome-audio is in universe)
<mdz> npmccallum: no, conflicts: gnome-audio on ubuntu-sounds is sufficient
<mdz> they work both ways
<npmccallum> mdz: I thought so, just wanted to check... also, I have the change to libgnome-common done (enables sounds by default).  However, at seb128's suggestion, I have not depended on ubuntu-sounds.  He suggesting adding it to desktop seed.
<thom> mdz: does xchat not use the gtk key bindings?
<mdz> npmccallum: why not depend on ubuntu-sounds?
<mdz> if sounds are enabled by default, and ubuntu-sounds is not installed, won't that cause a problem?
<npmccallum> mdz: no
<npmccallum> mdz: it just acts gracefully
<mdz> thom: the last time I looked, it had a hard-coded ^W shortcut
<mdz> even though I think it is a default gtk binding, which can be overridden globally otherwise
<mdz> npmccallum: ok, fine with me
<mdz> I'll add ubuntu-sounds to desktop
<npmccallum> ok, the new ubuntu-sounds should be in the queue
<mdz> however, that means that existing users will never get it
<mdz> which is a shame
<npmccallum> mdz: if we want to we can add a depend to ubuntu-artwork :)
<mdz> we could add an ubuntu-desktop package to desktop, which would be used to pull in new dependencies in the future
<sivang> maybe a package can be introduced into the installer, that will check new pkgs that we _want_ users to get, so it will install a set of new different pkgs each time a regular warty (even old snapshot) is installed.
<sivang> hmm ;) you just said what I thought about..
<mdz> sivang: we already do that
<mdz> but users who upgrade aren't helped by it
<sivang> i see
<mdz> another option would be to add a script to ubuntu-base
<sivang> than adding a desktop package is a good thing, I guess
<mdz> which would run aptitude install '~tubuntu-desktop'
<thom> mdz: yeuch
<mdz> thom: we're going to have something like that anyway, for woody upgrades
<sivang> sounds like reasonable enough
<thom> (yeuch to xchat, i mean)
<mdz> something which lets them say "give me the ubuntu desktop"
<sivang> exactly
* sivang nods for support.
<npmccallum> and its entirely unambiguous :)
* npmccallum seconds
<npmccallum> mdz: do I have approval to upload new libgnome? (just enables sounds by default)
<mdz> npmccallum: yes, have seb review it if you are unsure
<mdz> brb
<mdz> thom: aha
<mdz> thom: new xchat has an ugly workaround
<mdz> thom: if the gtk key theme is set to emacs _when xchat starts_, it changes the keybinding
<thom> eww
<elmo> npmccallum: please get ubuntu-sounds added to the apporpriate seed
<npmccallum> elmo: <mdz> I'll add ubuntu-sounds to desktop
<mdz> seb128, npmccallum: what was the reason for not wanting it as a dependency?
<npmccallum> mdz: so people can remove it if they don't want it
<seb128> because that's not mandatory ?
<mdz> is it large?
<mdz> ah, it is
<mdz> ok
<mdz> works for me
<seb128> fine
<mdz> so if a user upgrades, and then installs ubuntu-sounds, does that enable the sounds?
<mdz> or are they disabled if they are missing?
<npmccallum> if the sounds are missing, no settings change, the sounds just don't play
<npmccallum> its basically like -- if sounds_enabled() and sounds_exist(): play_sounds()
<npmccallum> mdz: I can dither down the size on those sounds btw, I just know a lot of people like Hifi stuff.  Plus, some sound cards only play at 44.1khz, which can be a pain
<mdz> npmccallum: I don't think it's excessive
<mdz> but it's large enough that people who are concerned about space, and don't want the sounds anyway, could very well want to remove it
<npmccallum> ok
<thom> GRAR. make distclean doesn't
<thom> 15kl diff.gz
<thom> of which a thousand lines are debian/
<thom> and the rest is autogen'd crap
* lamont goes to see how much love mdz has sent his way this morning
<mdz> lamont: our special this evening is a delicious freshly-resurrected getty bug, braised in a light tty sauce
<mdz> that thing is still wreaking havoc on the console
<lamont> mdz: yeah - I saw that one.
<lamont> and it's top of the list
<lamont> then there are a few others...
<lamont> btw, had any thoughts on 1577, now that it's in debian?? :-)
* lamont disables gdm on his laptop
* sivang has never felt too comfortable with gdm
<lamont> sivang: I just need a console login to break things with
<m_tthew> mdz: ping
<mdz> m_tthew: pong
<sivang> lamont : I have one running on my gf's laptop only because she's like "please don't let me see those black screens that you like so much"
<m_tthew> mdz: the athlon arrived, bit of a roadbump installing
<m_tthew> mdz: am looking for a little 'here is a nice path to bug report' guidance
<m_tthew> mdz: boot from usb works great, installer can't find the cdrom drive
<sivang> lamont : i really feel more comfortable loggin console.
<mdz> m_tthew: Component: cdrom-detect
<m_tthew> ack
<lamont> mdz: btw, did you see my gross fix for postfix and /etc/aliases.db?
<schweeb> m_tthew: which brand of cdrom?
<mdz> lamont: no
<schweeb> m_tthew: had problems with liteon + d-i myself
<m_tthew> schweeb: it's LG DVDblahblah in an USB ATA enclosure
<lamont> mdz: postalias requires myhostname to be non-null or it dies.  choices are: rewrite newalias (ugh), or notice that it's null, set it non-null, run newaliases, and then restore main.cf...
<mdz> m_tthew: oh, the same one I have (approximately)?
<m_tthew> works 100% connected to my i386 ubuntu box, but I did not install from it there
<m_tthew> mdz: yeah it is the dual layer version of yours
<m_tthew> mdz: in that enclosure
<schweeb> m_tthew: it boots via the usbcdrom and then can't find the install media, essentially?
<m_tthew> schweeb: exactly
<schweeb> that's exactly the problem I've been having with regular d-i
<schweeb> I think it's a kernel issue combined with bad firmware
<m_tthew> I am pretty USB naive so I don't know what module should load anyway
<m_tthew> delightful
<mdz> lamont: what was the blocker on gnucash again?
<schweeb> LG and Lite-ON are probably close to the same hardware
<schweeb> m_tthew: remember the mdk installer that would kill cdrom drives? think it's related to that... probably fixed the kernel so it would never do that
<schweeb> so, in short, look for new firmware (or a diff drive)
<m_tthew> ack
<sivang> schweeb : i've had numerous bugs and problems with LG, my new liteon drive has never given me any trouble. you sure they are the same chipset / framwork based?
<schweeb> sivang: well, I have 2 liteon drives in my desk that don't work.... every single IBM NetVista that I purchase can't install via d-i unless I use a different CDROM
<schweeb> but
<lamont> thom/sabdfl: gtkpbbuttons and powerprefs both ftbfs, missing build-deps
<lamont> thom: but they got past pbbuttons
<schweeb> I can install via the old Blade XFS Netinstall just fine
<schweeb> Lite-On Model LTN-486s and LTN-483S
<thom> lamont: ping me the logs?
<sivang> schweeb : guess it's more than just the cdrom, maybe the whole system makeup - all my d-i (debian/ubuntu) installs using that drive, never had a problem. fast as a deamon
<lamont> thom: first two on the list today: http://people.no-name-yet.com/~lamont/buildLogs/byDate/20040923.html
<schweeb> sivang: same model of liteon as me?
<lamont> both need gtk+2.0, and powerprefs? neesd path-config
<sivang> schweeb : what's the model # ?
<schweeb> Lite-On Model LTN-486s and LTN-483S
<schweeb> CDROMs
<schweeb> some guy was having the same problem, and posted to LKML with no response
<sivang> schweeb : hmm sorry, I have a cdrw = SOHR-5238S ;-)
<schweeb> IBM systems (same as me)
<schweeb> sivang: of course the firmware would be diff :p
<sivang> schweeb : yes ofcourse. I had problems with LG hardware and d-i, (was also a cdrw) that's why i got confused.
<schweeb> ah
<thom> lamont: thanks
<schweeb> these actually could be CDRWs, but they have no markings to indicate so
<schweeb> ugh
<schweeb> gotta download msttcorefonts
<schweeb> liteon's site fonts look utterly horrible
<sivang> yes,. I heared also that a dvdrom is actually a dvdrw, with a minor fimrware patch that can even downloaded from the internet
<schweeb> yea
<schweeb> Liteon is pretty famous for such things
<schweeb> makes it cheaper for them... it's not like everyone's gonna be willing to flash their firmware to get a dvdrw... some will buy it
<sivang> i like the drive alot. serves my ubuntu testing needs very well. I really HATED the lg, so buggy and unstable
<sivang> eight
<sivang> right
<thom> lamont: this is the trouble with single platform packages in debian, i guess
<lamont> thom: certainly
<pitti> sjoerd: do you already have packaged hal 0.2.98? If so, I don't need to do that again
<sjoerd> pitti: it's basically done, yes
<pitti> sjoerd: I would like to prepare them for Warty; many of my changes are adopted upstream now, but there are still some ubuntu-specific packages
<pitti> sjoerd: s/packages$/patches/
<pitti> sjoerd: do you still need to work on them?
<sjoerd> pitti: one patch so it finds the usb usermap libgphoto2 now installs
<pitti> sjoerd: oh, I think I can handle that :-)
<sjoerd> http://luon.net/~sjoerd/hal/hal-0.2.98/
<pitti> sjoerd: thanks!
<sjoerd> and some testing ofcourse
<pitti> sjoerd: yes, I will not upload them into Warty before about a week of testing
<sjoerd> anyway, i need to wait for a dbus update before i can update it in debian
<pitti> sjoerd: since I also need to upgrade other packages (dbus, gnome-volume-manager)
<pitti> sjoerd: oh, 0.2.98 doesn't work with dbus 0.22?
<sjoerd> pitti: it does, but the python bindings don't have support for 64 bit values
<sjoerd> so hdm fails 
<pitti> sjoerd: hdm?
<sjoerd> hal-device-manager :)
<pitti> ah
<sjoerd> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272862
<pitti> sjoerd: ugh, if hal-device-manager fails, we cannot put it into warty
<sjoerd> i've put a patch there too, so if you need to update dbus anyway :)
<pitti> sjoerd: I just saw the patch; doesn't look too scary
<sjoerd> that's from dbus cvs, so should be ok
<sjoerd> pitti: to what version of g-v-m are you upgrading
<pitti> sjoerd: I did not yet look at that
<pitti> sjoerd: I want to prepare and test hal and dbus first
<sjoerd> pitti: i've got a gvm 1.0.2 package mostly ready with patch to work with hal 0.2.98
<pitti> seb128: do we need a newer g-v-m for nautilus-cd-burner locking?
<sjoerd> pitti: you probably want the patch from the g-v-m development branch to not do stuff on locked drives
<pitti> sjoerd: definitively, that's the sole reason why we do all this upgrading hell during deep freeze :-/
<sjoerd> hehe
<sjoerd> pitti: http://luon.net/~sjoerd/hal/gvm-1.0.2/ 
<sjoerd> same as for hal, not completely finished needs some testing
<pitti> sjoerd: today it took me the whole day to (partly) overcome the implications of a bugfix release of gnome-vfs; so I'm hesitant about new upstream releases...
<sjoerd> and doesn't contain the locking patch..
<lamont> Kamion: sleeping?
<pitti> sjoerd: oh, nice, my hal-cdspeed patch already made it into your version :-)
<sjoerd> pitti: about 2 min. after you posted it :)
<pitti> sjoerd: what took you so long :-)
<sjoerd> fetchmail only gets my mail every five minutes ;)
<pitti> sjoerd: ugh, my hal's diff.gz is 177 KB, your's 12 kb. Let's see...
<sjoerd> pitti: a lot of the patches i saw in your hal, where already fixed upstream for some time
<elmo> gar
<elmo> npmccallum: Replaces: not Conflicts for simple file overwrites
<pitti> sjoerd: I know, 5 of the 10 are from me :-)
<sjoerd> pitti: g-v-m contains not mount just everything on startup. If your going to use that, i don't know if it's going to make it upstream (almost zero reaction on the list)
<sjoerd> but it solves something a lot of people complain about
<npmccallum> elmo: ok, I'll make another one
<pitti> sjoerd: what do you mean by "not mount just everything on startup"?
<npmccallum> elmo: conflicts and replaces? or just replaces?
<pitti> sjoerd: I thought it should only mount hotpluggable devices?
<pitti> sjoerd: ah, you mean devices that are plugged in during boot?
<sjoerd> pitti: gvm upstream tries to mount all volume on startup now
<sjoerd> since 0.9.10
<elmo> npmccallum: just replaces for file overwrites
<npmccallum> did you deny the current one?
<elmo> no?
<npmccallum> ok
<elmo> I only process stuff when it's NEW.. I was just catching up on bugzilla spam
<lamont> mdz: oh man of much vim joyfulnessmaking...
<mdz> lamont: hmm?  about to try to find something to eat
<lamont> yes or no: gui? gnome=yes. gtk2? kde=no perl? python? ruby? tcl?
<lamont> python=y
<lamont> that is, do you want anything more than the marriage of vim-python|vim-gnome?
<lamont> and would you like a vim-debian package?
* lamont hopes 'no' for that last one....
<thom> score. powerprefs and gtkpbbuttons both right first time
<elmo> can we get one of those in supported if not desktop?
<lamont> elmo: vim-debian?
<elmo> no, powerprefs/gtkpbbuttons
* lamont breathes a sigh of relief.
<elmo> exepcting new users to deal with pbbuttonsd.conf is a bit harsh
<sjoerd> pitti: your doing pmount too right ?
<pitti> sjoerd: yes
<sjoerd> pitti: are you planning to put it in debian ?
<pitti> sjoerd: probably, if I find time for it
<pitti> sjoerd: I should file an ITP for discussion first
<pitti> sjoerd: but I don't want to do this before sarge
<lamont> hrm.. vim-python says --enable-gui=gtk2, and vim-gnome says --enable-gui=gnome2
<sjoerd> some discussion about how to do things in debian would be nice (pmount vs. fstab-sync).. But that's indeed definately sarge+1 stuff
* lamont assumes we want gnome2..
<azeem> lamont: I don't think there's a big difference between gui=gtk2 and gui=gnome
* lamont hopes not. :)
<azeem> gvim from vim-gnome looks plain ugly and definetely not GNOMEish
<azeem> (at least on unstable)
<azeem> gvim from vim-python looks exactly the same
<azeem> ah no - the GNOME version has a detachable toolbar ;)
<thom> mdz: that apache2 advisory requires no action from us
* lamont wonders if he should throw in the other interps as well.
#ubuntu-devel 2004-10-05
<jdub> MORNING FREEDOM LOVERS!
<pitti> Morning jdbu
<pitti> Morning jdub (sorry)
<seb128> hey hey jdub :)
<lamont> morning pia
<lamont> oh.  hi jdub
<seb128> lol
<jdub> heh
<mdz> thom: great, thanks
<mdz> lamont: python=y, gnome/gtk=y
<mdz> lamont: 'vim' should give you a vim with python scripting
<mdz> lamont: 'gvim' should give you the GNOME gui
<elmo> heh, mouse emulation on the XServes
<mdz> elmo: can't we just give new users a pbbuttonsd.conf which works?
<jdub> are we still fighting vim for sanity?
* Mithrandir updates his .irssi/config
<mdz> jdub: no, I think we're in a comfy spot where we know what needs to be done and lamont is doing it
<lamont> mdz: vim-python turns on gui=gtk2, vim-gnome says gui=gnome2...  just wondering which one to pick.
<mdz> lamont: I assume gnome2
<lamont> ditto
<mdz> the one that vim-gnome uses is the right one
<npmccallum> mdz: do you have any objection to me changing the Conflicts to a Replaces in ubuntu-sounds (smoother upgrades)?
<lamont> you wanna test these before I upload, or just bitch afterwards?
<elmo> mdz: we can give them a reasonable default but not a default no one will want to change ever.. *shrug* not a big deal, I know it's late
<mdz> npmccallum: yes, conflicts is more appropriate
<elmo> mdz: huh?  for file overwrites?
<pitti> mdz: https://chinstrap.warthogs.hbd.com/~pitti/utopia/ contains the latest dbus package (including patch needed for latest hal)
<jdub> pitti: you saw libhal-storage
<mdz> elmo: yes, replaces alone is hardly ever useful
<mdz> all sorts of corner cases just break
<pitti> mdz: I will provide new hal and other packages tomorrow and announce them on the list
<mdz> and in this case, some not-so-corner ones
<pitti> jdub: no, I didn't
<elmo> mdz: err, I only know of one corner case, and it's a) very corner (i.e. rare) , b) it's clearly a dpkg bug
<elmo> mdz: like what?
<jdub> pitti: posted to hal list, kinda interesting
<pitti> jdub: thanks for the hint
<mdz> elmo: user installs ubuntu-sounds, it clashes with gnome-audio, so they remove gnome-audio, now ubuntu-sounds is fixed, then the user decides they want gnome-audio again and installs it
<mdz> *boom*
<elmo> err
<mdz> dpkg bug?
<elmo> it doesn't clash if you have the Replaces
<elmo> next.
<elmo> :-P
<mdz> elmo: you don't get to change history like that :-P
<mdz> the version in the archive an hour ago didn't have either
<elmo> err, but we're going to be fixing gnome-audio, right?
<mdz> the last time I tried it, if a package replaced some files in another, and then you removed/reinstalled the replaced package, it broke horribly
<Mithrandir> Kamion: around?
<mdz> elmo: no, they're meant to contain the same files, afaik
<mdz> they're alternatives
<elmo> then why aren't they using alternatives? :-P
<elmo> but anyway, blah
<Mithrandir> mdz: 1659, would it be fine just to put it in modules?  AFAIK, you can't detect the rtc using hotplug
<mdz> Mithrandir: I think that's our only option for warty
<Mithrandir> ok, I'll add that comment and reassign to Kamion, then.
<lamont> mdz: you want to see the postfix diff?  pb is I really need Kamion to drop it into a CD and see what it does...
<mdz> lamont: yes
<mdz> lamont: don't you have a local mirror?  you could make a CD from that
<lamont> mdz: don't have the black magic make-me-a-cd scripts (well, not figured out anyway...)
<jdub> "fix everything harder" ;-)
<lamont> mdz: diff mailed
<lamont> mdz: fwiw, I _KNOW_ it's sick and wrong.
<npmccallum> mdz: whats your call -- keep conflicts or use replaces or something else?
<elmo> npmccallum: just ignore me, it's fine as is
<elmo> sorry
<mdz> npmccallum: just conflicts is fine
<lamont> ok. so how do I test that I got the neato new stuff in my vim?
<mdz> Conflicts: kdelibs3 (<< 4:3.0.0), kdelibs3-cups (<< 4:3.0.0), kontour (<< 1:1.3.0)
<mdz> er
<Mithrandir> is it just for me or is the new firefox completely busted when trying to access bugzilla?
<mdz> http://bugzilla.ubuntu.com/show_bug.cgi?id=1674
<mdz> ^^^ bug resulting from using replaces without conflicts
<lamont> mdz: vim test?
<Mithrandir> it says (in a new, yellow window) <label value="&serverCertExpired.continue" flex="100%"/>
<mdz> lamont: :python ...some stuff...
<Mithrandir> I think it doesn't like that bugzilla spits out malformed XML
<lamont> mdz: ok,  btw, did we want perlinterp turned on too?
<mdz> lamont: I don't think so; don't bother with it for now
<mdz> python and gnome are what matter
<lamont> you want that diff too?
<mdz> sure
<mdz> I've almost choked down the last one
<elmo> james@adare:~$ sudo su - 
<elmo> fstat: Value too large for defined data type
<elmo> cool
<Mithrandir> elmo: arch?
<lamont> elmo: I told you, ppc is bad.
<elmo> Mithrandir: powerpc
<Mithrandir> elmo: sounds fun
<mdz> lamont: why mv/cp/mv rather than cp/mv
<lamont> permissions
<mdz> cp -a
<lamont> ok
<mdz> lamont: what happens to this if the postconf command fails?
<mdz> lamont: http://www.vim.org/htmldoc/if_pyth.html
<mdz> there's some vim-python stuff to try
<jdub> polypaudio *rocks*
<npmccallum> anyone around that can put a second set of eyes on the diff for my openoffice source package before I start building it?
<mdz> sure
<lamont>     # newaliases chokes if hostname not set
<lamont>     if [ -z "$(postconf -h myhostname||true)" ] ; then
<lamont>         cp -a main.cf main.cf.dpkg.$$
<lamont>         postconf -e 'myhostname=ubuntu' 
<lamont>         newaliases
<lamont>         mv main.cf.dpkg.$$ main.cf
<mdz> lamont: is it not possible to say newaliases -o myhostname foo?
<lamont> mdz: sadly, no.
<elmo> oh, can postfix create /etc/mailname? pwetty pwease
<mdz> lamont: I won't say that it looks good, but it's ready to upload :-)
<lamont> elmo: it does if it's not already there
<npmccallum> http://natemccallum.com:8080/ooo.diff
<elmo> lamont: since when?
<lamont> since ever
* lamont double checks
<elmo> lamont: didn't on the HP machines I installed with warty preview
<lamont> elmo: it won't stomp on it if it already exists (unless you changed it), and always creates it if it has a hostname.  See aliases.db bug
<elmo> aliases.db bug?
<lamont> if the hostname does not have at least one '.' in it, then it won't create it. but bitches
<lamont> aliases.db doesn't get built if the hostname is empty.  warty preview doesn't build aliases.db.
<lamont> ergo, hostname is null at the time postinst runs
<mdz> npmccallum: looks fairly reasonable, though I'm not intimately familiar with ooo's build system
<mdz> npmccallum: did you do a test build and make sure that the patches are applied correctly?
<lamont> I suppose I could pre-depend netconfig, and just be done, eh?
<lamont> about 97KB more vim cruft.
<lamont> and no gvim in the package... sigh
<npmccallum> mdz: I wanted someone to look it over before I start building
<npmccallum> mdz: Its like a 12 hour build
<mdz> npmccallum: set up ccache first :-)
<npmccallum> mdz: ccache only helps after the first build :)
<mdz> npmccallum: there should be a debian/rules target which applies all the patches, that'd be a good test
<npmccallum> mdz: I'm not familiar enough with OOo's build system to do it.  I'll build it to make sure, it will pretty much make me AWOL for the rest of the night though :)
<npmccallum> mdz: I'll still be around, but not with many free CPU cycles... actually, my disk will be the busy one
<mdz> npmccallum: try it with nice -19
<mdz> npmccallum: if it still cripples your machine, then maybe lamont can build it on a buildd for you
<npmccallum> mdz: nice -19 debuild ?
<mdz> npmccallum: yes
* lamont thinks he understands where all the vim variants come from, but still ponders the base 'vim' package's origin
<npmccallum> is there a way to install all build deps at once?
<lamont> dpkg-checkbuilddeps
<lamont> then cut/paste
<mjg59> apt-get build-dep package
<lamont> doh
<mjg59> hahah
* lamont does that usually
<seb128> lol
<lamont> otoh, apt-get build-dep uses Sources, and dpkg-checkbuilddeps uses debian/control
<jdub> lamont: you been to elmo skool!
<lamont> and I've been changing build-deps lately..
<jdub> pants off mjg59 
<Mithrandir> I had a nice script that took the output of dpkg-checkbuilddeps and stripped the versions off it.
<pitti> night guys!
<mjg59> PANTS OFF
<mjg59> It's disgraceful. 4 pints of Adnam's Broadside down, and I feel fairly sober.
<Mithrandir> mjg59: I should go bother you in Cambridge some day. :)  And drink beer.
<mjg59> Mithrandir: That would be an excellent thing to do
<npmccallum> the ooo build has begun :)
<mjg59> There's an obscene amount of beer in Cambridge. More of it needs drinking.
<azeem> same goes for Munich currently
<Mithrandir> mjg59: I need to magic up a little bit of funds, I think, but I really enjoyed Oxford, so I figured I'll enjoy cambridge even more. :)
<mjg59> azeem: But I have to walk less far to Cambridge :)
<Mithrandir> why does bugzilla encode my IP or something in the cookie it sends me?
<elmo> Mithrandir: what was that file you had me alter on yellow to give you chroot indicatorness
<elmo> +?
<Mithrandir> /etc/debian_chroot
<Mithrandir> (please don't invent a /etc/ubuntu_chroot. :P)
<mdz> /etc/chroot would have been sufficient :-P
<Mithrandir> mdz: debian_chroot is already in the default bashrcs and such, though
<mdz> lamont: did synaptic FTBFS?
<mdz> or did it disappear?
<elmo> 'unstable'
<elmo> ^-- synaptic
<mdz> gah
<mdz> mvo's fault
<jdub> christing puce
<jdub> 121 -users mails
* jdub uploads gksu hack
<elmo> mdz: can you confirm home.ubuntu.com works for you now, btw?
<mdz> elmo: yep
<elmo> ok - I'll close the bug since bugzilla isn't we're tracking admin fuckage atm - k?
<lamont> mdz: is there an option to apt that'll tell it to just spew the URL's of what it whats to fetch?
<Mithrandir> lamont: --print-uris
<lamont> Mithrandir: doesn't print uris when used with -s
<lamont> of course, without -s.... :)
<Mithrandir> lamont: it doesn't do anything anyway, if you use --print-uris, so why bother with -s?
<lamont> yeah.   that's where I got to.
<Kamion> lamont: yo
<Kamion> Mithrandir: yo
<lamont> Kamion: is there any way I can make sure that postfix's postinst runs _after_ the hostname gets set, and not before?
* lamont is pondering an evil pre-depends...
<Mithrandir> Kamion: 1659, ok with you?
<Kamion> lamont: it does, or certainly should
<Kamion> lamont: I don't think there's anything more I can do ... if it isn't getting set, it isn't getting set
<Kamion> lamont: netcfg hooks in before base-installer to set the hostname, which is before any packages get installed
* lamont ponders..
<Mithrandir> Kamion: and if you have any suggestion on 1669, I'd be happy. :)
<lamont> actually, if hostname is not an fqdn (contains no '.'s), then all would still make sense
<lamont> postfix's config gets run before netcfg, yes?
<Kamion> lamont: nope
* lamont hrms some more
<Kamion> lamont: nothing of postfix gets run before netcfg sets the hostname, as far as I know
<Kamion> Mithrandir: just looking, one sec
<lamont> but said hostname does not include a domain, correct?
<Kamion> Mithrandir: #1659 fine by me (I'd noticed the bug too), if you're happy to wait 'til I get back from Oldenburg I'll fix it then
<Kamion> Mithrandir: #1669, maybe missing discover1-data entries for the USB controller?
* lamont dist-upgrades. sigh
<Kamion> lamont: not guaranteed, I don't think ...
<lamont> right
<lamont> that could just about explain things.
<Mithrandir> Kamion: possibly, yes.. I could ask for more info from submitter.
<Kamion> Mithrandir: ask for lspci and lspci -n output, that's the standard
<Kamion> Mithrandir: if they don't have a Linux installation on the same machine, the output of 'cut -f1,2 /proc/bus/pci/devices' on tty2 in the installer is generally transcribable with only a moderate amount of patience
<Mithrandir> seems like he got warty working, so
<lamont> vim happiness.  mdz: you wanna see it first?
<lamont> but first a reboot to make the machine state sane.  brbn
<mdz> lamont: sure
<mdz> I'll give it a whirl
<Mithrandir> lamont: is mozilla-firefox in the queue on amd64?
<mdz> elmo: what's the right way for me to sponsor warty uploads so that somebody besides you gets the accept/reject messages?
<mdz> elmo: buildpackage -m?
* lamont uploads postfix
<Mithrandir> lamont: ignore me
<lamont> Mithrandir: ok
<lamont> mdz: you want a diff, or a couple .debs?
<lamont> or both?
<mdz> lamont: diff is fine
<mdz> debs are nice too
<Kamion> damnit, somebody needs to port valgrind to powerpc
<Mithrandir> Kamion: and to amd64.
<Kamion> forget about bounties from Mark, *I'd* pay money for a valgrind/powerpc port
<Kamion> Mithrandir: at least on amd64 you can probably run it in 32-bit mode
<lamont> 4 files, 4595 bytes of diff
<Kamion> qemu valgrind doesn't appeal
<jdub> haha
<jdub> mmmmm!
<jdub> that'd rock
<lamont> mdz: diff sent,building final and clean .debs now
<jdub> is there a thingy
<jdub> to check that every file under debian/tmp is in a package?
<jdub> just as a handyhelpertool
<Mithrandir> jdub: dh_install with --fail-missing?
<Mithrandir> Kamion: doesn't catch sizeof(int) != sizeof(void*) errors, which are by far the most common on amd64
<jdub> Mithrandir: does that make sense with a multibinary package?
<lamont> mdz: 15 minute avg build time..
<Mithrandir> jdub: I'd say so, yes.  Read the documentation for it?
<jdub> ok
<Kamion> Mithrandir: troo
<mdz> lamont: diff looks pretty clean
<lamont> yeah, just renamed vim-tiny to vim-ubuntu... we _could_ deliver a vim-tiny package, but I'm not inclined to...
<lamont> (vim-tiny went away, it seems, because vim _IS_ vim-tiny...)
<mdz> yeah, we have vim in base
<mdz> lamont: as long as you're there, mind taking a look at the icon issue?
<lamont> yeah, and it grew by something like 97KB.
<lamont> bug #?
<mdz> looking
<lamont> mdz: I can't reproduce 1559 at all.
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1639
<mdz> lamont: the .desktop references gvim.png, which doesn't seem to exist anywhere
<mdz> maybe it used to be shipped with gnome or something?
<jdub> hrm, crap
<jdub> that's totally bong on multibinary
<mdz> lamont: odd, it's behaving now
<mdz> jdub: only if you call dh_install multiple times
<mdz> it should work fine if you call it just once
<lamont> hrm.. given kvim and vim*.png, I'd expect that gvim.png was a foot with the Vim logo superimposed.
<jdub> cdbs ;)
<lamont> mdz: in order to reproduce the bug with -8, I had to reboot...  and again for -9 to make it go away...
<lamont> not sure how init is stashing the vnode, but it appears to be...
<mdz> lamont: I don't think I had upgraded it since rebooting, but I suppose I could be on crack
<mdz> jdub: do you know of a gnome vim icon we can use?
<mdz> jdub: (#1639)
<lamont> gvim: should we just reference vim.png, or should we make jdub/seb give us a new one?
<mdz> though, a .desktop entry for gvim is a bit silly
<lamont> remind me again why lapack3 is in main???
<lamont> we could just make that go away...
<mdz> lamont: python-numeric :-(
<lamont> after all my work to get it there...
<jdub> do we have to have a .desktop file for gvim?
<jdub> i guess it helps with mimetypes registration
<mdz> yes
<jdub> but a menu item is bong
<lamont>  /usr/share/applications/gvim.desktop
<mdz> Categories=Application;Utility;TextEditor;
<jdub> mdz: (is this for mimetypes, or...?)
<mdz> it's not localised or anything
<lamont> [Desktop Entry] 
<lamont> Encoding=UTF-8
<lamont> Name=Vim
<lamont> Comment=Vim Text Editor
<lamont> Exec=gvim 
<lamont> Icon=gvim.png
<lamont> Terminal=false
<mdz> jdub: pasted you the whole thing in /msg
<lamont> Type=Application
<mdz> in order to avoid SPAMMING THE CHANNEL
<lamont> Categories=Application;Utility;TextEditor;
<lamont> StartupNotify=true
<lamont> jdub: just tell me what to make it say...
<lamont> oops
<mdz> ;-)
<jdub> well, answer my questions first!
* jdub challenges!
<jdub> so that doesn't have mime stuff in it -> why do we need a .desktop file at all?
<lamont> uh, what's the question?? :=)
<lamont> jdub: exactly.
<lamont> we have one, should we kill it?
<jdub> you can stop being zen now
<jdub> ;)
<jdub> i don't think there's any point installing it
<lamont> gone.
<jdub> cool
<jdub> (mdz must've been saying yes to something else, then - that's what confused me.)
<lamont> prolly
<jdub> lkcl is on so much crack
<lamont> who wants to review vim.menu?
* lamont is menu clueless, you see..
<sidney> hey, i have a question
<sidney> has anybody sucessfully built ndiswrapper?
<sidney> ...with the standard ubuntu kernel that is
<mdz> jdub: I thought you were asking "do we have a .desktop file for vim?"
<mdz> I do not think we need one
<lamont> I left the .desktop file in vim-gnome, but fixed the png reference.  vim doesn't get one
<mdz> elmo: regarding #1677, is auckland running exec-shield? :-P
<lamont> mdz: anything else before I upload vim?
<mdz> sidney: this channel is for development discussion; for questions and other discussion, please use #ubuntu
<mdz> lamont: nope, if it works for you, ship it
<mdz> lamont: go ahead and kick any remaining vim-* variants out of the seeds once it's in
<mdz> I think only vim-gnome remains
<mdz> hmm, maybe not
<mdz> I think they're all in universe already
<mdz> we should really just kill them
<mdz> they're evil and broken and when people install them they get broken diversions
<mdz> let's see how this goes first
<lamont> btw, what's broken with the diversions?
<mdz> jdub: what do you think we should do about the CD-RW/nautilus-cd-burner/pmount situation?
<jdub> mdz: it's actively being worked on upstream
<mdz> lamont: apt-get install vim; apt-get install vim-gnome; apt-get remove vim-gnome and you no longer have /usr/bin/vim
<lamont> sigh
<mdz> jdub: I  know, but a new dbus+hal scares the shit out of me
<mdz> considering pitti said the last version didn't work at all for him
<jdub> mdz: we're just in a rough spot (a little bit) because we're doing things slightly differently
<jdub> mdz: yeah, but consider that both Novell and Red Hat are actively working on this for their upcoming releases
<jdub> mdz: might be worth tracking rawhide packages
<jdub> to see what they're doing
<npmccallum> mdz: If I remember correctly it was just his usbkey that didn't work
<npmccallum> mdz: everything else worked (I think...)
<mdz> npmccallum: hmm, ok, he sounded much more concerned in bugzilla
<npmccallum> mdz: I could be wrong
<mdz> it would certainly suck to have to bail on the automounting magic because of this
<npmccallum> mdz: we'll just make sure we test the new packages before we make a decision
<npmccallum> mdz: I for one am not going to blindly take a new version
<mdz> npmccallum: agreed
<mdz> we can't test on behalf of all of the users who will be affected by it, though
<npmccallum> thats true, but there is no garuntee that many of the users that come after the preview will work with the current version
<npmccallum> and there is a bad known bug now...
<lamont> mdz: all well here, gonna upload unless you scream.
<mdz> lamont: ok
<lamont> 1037432->1394296 bytes.
<lamont> mousenuts
<lamont> mdz: you're running 2.6.8.1, yes?
<mdz> lamont: not right now :-/
<mdz> lamont: see #1632
<mdz> 2.6.8.1 doesn't boot for me on this machine
<lamont> so 2.6.7 then
<lamont> >
<lamont> 1596 is the "just keep retrying it, that happens on powerpc' bug...
<lamont>       (" terminated by signal 4","give\n"),
<lamont> literally.
<lamont> mdz: so how should I handle that one??
<lamont> it certainly affects us, but I've specifically been told that 'powerpc's just do that sometimes, it's perfectly normal'...
<elmo> mdz: yes, but so is newsamosa
<elmo> and saens
<elmo> oh, not with apache2 tho.. hmm, blah.  okay, I've taken it off, we'll see if that clears it up
<elmo> 476345 /var/log/apache2/archive.ubuntulinux.org.error-log
<elmo> god damn it
<lamont> mdz: want me to upload 1666?
<lamont> one char change in configure.
<lamont> although I suppose just re-running autoconf would fix it too.  -but the diff would be much bigger.. :-)
<lamont> - VERSION=1.0.4
<lamont> + VERSION=1.0.5
<lamont> reflecting the change that's already in configure.in
<elmo> mdz: it's not exec-shield :-P
<lamont> root      4067  0.0  0.1  1492  468 tty1     Ss+  19:38   0:00 /sbin/getty 38400 tty3
<lamont> root      4104  0.0  0.1  1492  456 ?        Ss   19:38   0:00 /sbin/getty 38400 tty1
<lamont> hrm. oops.
* lamont hates race conditions...
<lamont> now to identify where it is.
<mdz> lamont: has the machine ever hung?
<mdz> lamont: or is it only a problem in userland?
<lamont> purely userland, and tty assignment
<mdz> lamont: 1666, does it actually break anything?
<mdz> I'm not sure why that was made RC in Debian
<lamont> oh, 1666, dunno.
<mdz> lamont: I mean the powerpc thing, has the buildd ever crashed?
<mdz> or does it only randomly crash programs?
<mdz> no kernel panics?
<lamont> any app that builds against version.h and varies things based on 1.0.4 vs 1.0.5 is screwed.
<mdz> lamont: patch to configure is fine
<lamont> mdz: no kernel panics, just dead user processes.  Always SIGILL
<lamont> mdz: alsa-lib uploaded
<lamont> mdz: seems to only crash dh_install and such - don't have a ppc, so I only see it in the buildd's
<mdz> lamont: has it ever happened on a Debian buildd?
<lamont> dunno.. don't run ppc buildd there
<lamont> but elmo was very familiar with it...
<mdz> googled on it?
<mdz> http://lists.exploits.org/slackintosh-users/Aug2002/00001.html sounds vaguely similar
<mdz> lamont: is it using a CONFIG_HIGHMEM kernel?
<mdz> google(linux powerpc random sigill) turns up a message about config_highmem being a possible culprit
<lamont> CONFIG_HIGHMEM=y
<lamont> CONFIG_HIGHMEM_START=0xfe000000
<mdz> could try turning that off, for giggles
<fabbione> morning guys
<daniels> fabbione: 'morning
<fabbione> today is a good morning
<fabbione> it's friday
<fabbione> ;)
* lamont finishes a long discussion with neuro, turns off neuro's gdm-helper code in getty, restoring the old bug.
<lamont> damn inadequate kernel API's anyway
<fabbione> who forgot to upload enigmamail?
<fabbione> oh thombot
<daniels> fabbione: heh
<fabbione> Errors were encountered while processing:
<fabbione>  /mirrors/ubuntu/pool/main/v/vim/vim-common_6.2-532+4ubuntu2_all.deb
<fabbione>  /mirrors/ubuntu/pool/main/v/vim/vim_6.2-532+4ubuntu2_i386.deb
<fabbione> E: Sub-process /usr/bin/dpkg returned an error code (1)
<fabbione> ehi guys...
<fabbione> is there a bug open for it already?
<lamont> fabbione: what's the errors...
<fabbione> lamont: dpkg: error processing /mirrors/ubuntu/pool/main/v/vim/vim_6.2-532+4ubuntu2_i386.deb (--unpack):
<fabbione>  trying to overwrite `/etc/vim/gvimrc', which is also in package vim-python
<lamont> GAH!!!
* lamont fixes
<lamont> apt-get remove vim-python
<lamont> mdz: so can I just kill the vim-* packages??? huh? huh?  can I? prettttyyyy pleaaaaaasssssssssssssseeeeeeeeeeeee?
<mdz> lamont: care to take a look in sid and see how they fixed it?  maybe it's trivial
<lamont> mdz: that particualr one is because I added gvimrc to the files delivered by vim.  I could just stop delivering that file again...
<lamont> +debian/runtime/gvimrc                  etc/vim
<lamont> +etc/vim/gvimrc                         usr/share/vim/gvimrc
* lamont uploads util-linux_2.12-7ubuntu5_source.changes
<lamont> no similar change in sid
<lamont> mdz: I think we want to keep delivering those files, so it's just a matter of freshening the versions on the conflicts/replaces lines, yes?
<fabbione> mdz: 1637
<fabbione> mdz: i really don't know anything about ldap/slapd and so on.. do you really want me to fix it? I can do it.. it will just take longer time
<lamont> mdz: looking at 834, we need to add a dpkg-divert --remove to preinst, and then just drop the other packages completely?
<lamont> fabbione: btw, vim is #834. :(
<fabbione> ah
* lamont falls over.
<lamont> night all
<fabbione> night lamont
<daniels> lamont: night dude
<pitti> Moin moin
<fabbione> jdub, mdz: http://people.no-name-yet.com/~fabbione/1637.diff
<fabbione> permission to upload openldap2 with that fix for that bug
<Mithrandir> Kamion: The lspci output for the usb cdrom-does-not-work-with-d-i is now at https://bugzilla.ubuntu.com/show_bug.cgi?id=1669
<mdz> fabbione: looks good, go ahead
<fabbione> mdz: ok.
<mdz> lamont: I meant the bit where it doesn't remove the diversions properly
<fabbione> mdz: permission to upload mozilla for 1682 and change again the default of dsp to auto (can't remember the bug number)
<fabbione> mdz: each time we sync we MUST be sure that all the changes we did across the time are reintroduced too
<Mithrandir> Kamion: actually:
<Mithrandir> : tfheen@dessverre ..64-generic/kernel/drivers > find -name \*hid\*
<Mithrandir> : tfheen@dessverre ..64-generic/kernel/drivers >
<fabbione> mdz: sorry i don't have a diff handy but it's basically s/1.7.2/1.7.3 in the menu files
<Mithrandir> Kamion: so it seems like the hid and usbhid modules are missing from the initrd and that's the problem, not that discover1-data fucks up
<mdz> fabbione: yes, that is the responsibility of the person requesting the sync
<mdz> in fact it should be written as part of the request
<fabbione> mdz: ok.. can i upload?
<mdz> fabbione: yes
<fabbione> goody
<Kamion> Mithrandir: hm, usbhid isn't in linux-kernel-di-amd64-2.6 input-modules
<Mithrandir> Kamion: I was just typing that.
<Mithrandir> the input-modules should has a -drivers/usb/input/hid.o, it should have a drivers/usb/input/usbhid.o
<Kamion> Mithrandir: surprised hid isn't there, though
<Mithrandir> there's no hid module at all any more, it seems
<Kamion> Mithrandir: is it missing from the kernel? actually I thought it got renamed
<Kamion> ./i386/input-modules:2:-drivers/usb/input/usbhid.o
<Kamion> should probably match that
<Mithrandir> what does -$foo mean?
<Kamion> optional
<Mithrandir> ok
<Kamion> i386 is:
<Kamion> -drivers/usb/input/hid.o
<Kamion> -drivers/usb/input/usbhid.o
<Kamion> drivers/usb/input/usbkbd.o
<Kamion> is usbkbd not sufficient then?
<Kamion> ah, hid -> usbhid in 2.6.6
<Kamion> yeah, ok, you need usbhid
<Mithrandir> yeah, and usbhid is missing in the amd64 file
<fabbione> hmmm status is not too bad
<Mithrandir> care to add and get permission to upload and such?
<fabbione> 3 critical and 55 maj bugs
<Mithrandir> Kamion: can I reassign the bug to you and you'll handle it further?
<Kamion> Mithrandir: go ahead
<daniels> mdz: http://people.ubuntu.com/~daniels/gimp-2.0/
<daniels> mdz: user install dialog-less gimp
* Mithrandir grabs some food
<daniels> mdz: is this still warty, or hoary?
<daniels> mdz: given the freeze and all
<mdz> daniels: depends on how invasive it is
<daniels> mdz: a few ifdefs; want an interdiff?
<daniels> mdz: i could create a test image just fine with what looked like exactly the right defaults after using it
<daniels> (using it ... to create my ~/.gimp-2.0)
<mdz> confuses the hell out of interdiff
<Kamion> mdz: enormous amounts of stuff seem to have just moved into base
<Kamion> or is my germinate just confused?
<mdz> Kamion: I haven't added anything to base since ubuntu-base
<mdz> (which has no deps)
<fabbione> mdz: we need to sync enigmail
<fabbione> mdz: i am checking if it builds and works in ubuntu
<fabbione> mdz: due to the new mozilla-thunderbird package
<mdz> ok
<jdub> pitti: around?
<pitti> jdub: yes
<jdub> pitti: did you end up figuring out the gnome-vfs isues with desktop/disks?
<jdub> i'm not seeing icons in either atm
* jdub hasn't upgraded for quite a few hours though ;)
<pitti> jdub: yesterday's package should give icons on the desktop for USB and cdrom devices
<pitti> jdub: version 2.8.1-0ubuntu2
<jdub> hmm
<pitti> jdub: However, I did not manage to get the icons appear in "Disks"
<jdub> that's what i have
<jdub> oh
<jdub> i wonder if the one on this cd will be better...
<pitti> jdub: I tried all the day, but then sabdfl and I agreed to postpone that
<jdub> oh
<pitti> jdub: the new upstream version of gvfs does not play well with my old approach of "faking" fstab entries
<pitti> jdub: gvfs only shows fstab entries in "disks", so I emulated them in earlier versions
<jdub> oh
<pitti> jdub: now I go on with packaging the crack-of-the-day utopia stack, if that is finished, I can return to "disks"
<jdub> ok
<jdub> ta
* jdub is just doing a demo in an hour or so
<jdub> hoping i can show those off without a hitch :)
<pitti> jdub: oh, if you do want to show icons in "devices", prepare a fstab entry for an USB stick :-) 
<pitti> jdub: (okay, that's cheating)
<jdub> ;)
<daniels> mdz: new one which makes interdiff far less confused
<mdz> daniels: looks pretty safe to me
<daniels> mdz: rad, ta.
<fabbione> mdz: you got mail :-)
<mdz> I always do...
<fabbione> well... today you are lucky
<fabbione> you got one more from me :P
<seb128> morning
<pitti> Hi seb128!
<seb128> hello pitti 
<fabbione> seb128: ehm
<fabbione> do you realize that totem starts
<fabbione> but there is no sound or video? ;)
<seb128> this part of the bug is a dup
<seb128> and the second part crashs X
<seb128> so I've reassigned for the crash :)
<fabbione> ok ok ;)
<fabbione> you are safe for today :P
<seb128> pfiou :)
<fabbione> also another important thing for everybody
<fabbione> X bugs are almost never major or critical
<fabbione> until they affect more than 1 user
<fabbione> the fact that X crash on one machine can easily be:
<fabbione> a) hardware problems
<fabbione> b) user problems
<fabbione> c) crappy hardware
<fabbione> d) cheap hardware
<daniels> e) crappy code
<seb128> fabbione: you said that for the bug I've reassigned ? I've not even looked on the severity
<fabbione> seb128: just generally
<seb128> ok
<fabbione> i am raedy to bet that the submitter will not even reply 
<seb128> I want a NEEDINFO status :)
<fabbione> seb128: can you comment on 1390?
<seb128> ok
<seb128> fabbione: "The patch is an update of the FAQ, but yes. it's included." <- there is an another patch after that
<seb128> no ?
* seb128 checks
<fabbione> seb128: nope..
<fabbione> the problem is in nautilus/gnome/whatever application
<seb128> "Here is a patch so that GNOME (and maybe other?) keyboard switchers do
<seb128> not call erroneous altwin:meta_super and altwin:meta_hyper options.
<seb128> Can I commit it?"
<seb128> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259740&msg=78
<fabbione> seb128: that patch hasn't been included in Debian either
<seb128> I know
<seb128> but according to Denis it fixes the problem, right ?
<seb128> It's tagged pending in debian
<fabbione> seb128: he didn't mention that patch in our reports
<seb128> I mentionned it to raise the issue ...
<seb128> perhaps we could ping him about it ?
<seb128> I'll mail him
<seb128> he's looking on this problem for 2 weeks, he made some reassing against metacity and back to xfree in debian
<seb128> and mailed me about that last week
<fabbione> ok
<fabbione> who has a ppc can kindly take a look to #1690?
<mdz> I think a powerbook is necessary
<fabbione> mdz: how would you feel to ask that question on ppc?
<rburton> jdub: ping?
<rburton> any chance of a newer HAL in ubuntu?
<rburton> if 0.2.98 is included then Sound Juicer with HAL can be used
<rburton> which seb128 would love
<seb128> rburton: what's specific about 0.2.98 ?
<fabbione> seb128: actually... the patch is not committed, and branden did mark the bug pending due to the addition to FAQ
<rburton> seb128: i'm not entirely sure
<seb128> rburton: we are speaking about new hal for 2 days because of the lock stuff in n-c-b
<rburton> seb128: i've a HAL patch from colin walters which deps on hal > ...98
<seb128> rburton: pitti is working on it, that's the guy to ping :)
<rburton> pitti: ping!
<pitti> rburton: pong
<rburton> new hal coming soon?
<pitti> rburton: i'm right at working on it
<pitti> rburton: I need to port all the changes to the new 0.2.98, this takes me a while
<seb128> fabbione: I've mailed Denis to ask about the patch/his comments/.. what we should do
<fabbione> seb128: you rock!
<rburton> pitti: excellent
<seb128> fabbione: I'll let you know when I get a reply
<pitti> rburton: new dbus is already available :-)
<seb128> pitti: we are upgrading hal finally ?
<pitti> seb128: yes, mdz wanted to have dbus, hal, gvm and nautilus-cd-burner upgraded
<pitti> seb128: I'm working at the whole stack now
<seb128> ok, cool
<fabbione> daniels: nv driver seb fault on amd64 laptop
<fabbione> s/seb/seg
<daniels> fabbione: segfault? i thought it just picked res wrong?
<fabbione> no
<fabbione> he has send me like 20 mails in 5 minutes
<fabbione> the log shows a segfault
<fabbione> Fatal server error:
<fabbione> Caught signal 11.  Server aborting
<fabbione> the rest of the log looks ok
<daniels> argh :\
<daniels> where does it segfault?
<fabbione> at the end
<fabbione> let me forward
<daniels> cheers
<fabbione> oh great
<fabbione> another mail from him
<daniels> ?
<fabbione> it works with -dbg
<daniels> heh, lucky you :)
<daniels> ARGH!
<daniels> -O2 bug?
<fabbione> i am afraid so
<daniels> oh man
<daniels> can we get mdz or someone with an amd64 to rebuild with -O0 but stil lwith the loader?
<fabbione> i will compile a normal package for him
<daniels> thanks
<fabbione> and see what happens
<fabbione> i have access to amd64
<fabbione> no i don't...
<fabbione> dchroot is borked
<fabbione> elmo: please tell me you are around and i know you are reading your mails :-)
<elmo> huh?
<elmo> it's Debian dchroot
<elmo> you need to 'dchroot -c warty'
<elmo> or does that still not work?
<elmo> oh, I may not have added you in yellow, blah, one sec
<elmo> try now
<fabbione> yeah it's on yellow
<fabbione> right a sec :-)
<fabbione> much better
<fabbione> elmo: adare gives me a warning
<fabbione> Executing shell in 'warty' chroot.
<fabbione> su: Authentication service cannot retrieve authentication info.
<fabbione> (Ignored)
<elmo> uh, cute
<elmo> it works tho right?
<fabbione> yes
<fabbione> did you install ccache in the chroots?
<fabbione> that would save several hours recompiling crap around
<elmo> yes
<fabbione> cool!
<fabbione> you ROCK!
<elmo> ah, okay, fixed the warning.. at least I know what that is now - i get that on like 10 of my debian buildds
<thom> lack of /etc/shadow details for the user, right?
<thom> (sorry, just back from reboot)
<fabbione> elmo: there is no ccache on yellow
<elmo> thom: more not having shadow turned on, but yeah
<fabbione> adare is perfect :-)
<elmo> wow, wonder how mithrandir didn't complain about that - anyway, fixed
* fabbione hugs elmo 
<fabbione> Fetched 62.5MB in 2s (25.5MB/s)
<fabbione> AHH NEAT
<elmo> yeah, just don't do that around realise time.. mdz puts on his angry eyes if you do
<elmo> err, release even
<fabbione> ehehe
<seb128> doko: here ?
<seb128> doko: #1159 <- could you reply to the comment ?
<fabbione> elmo: but that was an internal transfer anyway.. i didn't suck bw from outside LAN
<fabbione> anyway
* fabbione grabs some food while X builds
<elmo> fabbione: yes, but auckland only has so much disk I/O ..
<elmo> around release time, with our new BW, it will actually become an issue - I might have to firewall LAN hosts away from auckland :>
<fabbione> elmo: don't worry.. it's not like we change X every day. I can just ssh the interdiffs
<fabbione> but i needed the first orig.tar.gz
<fabbione> i really can't do much without it ;)
<fabbione> i need some food
<seb128> bugzilla broken ?
<seb128> "You don't have permission to access /show_bug.cgi on this server."
<thom> seems to be working again now
<thom> though it's butt ugly
<elmo> aiee, it's  been themed!
<elmo> attack of the killer plone css stylesheets!
* elmo can mock in safety thanks to a certain BT ADSL link death ;-)
<thom> it makes my bug list look a lot smaller tho, so it's probably good
<rburton> hmm
<thom> elmo: *g*
<daniels> ow, my eyes :\
<rburton> hm
<daniels> thom: diediediedieblood
<daniels> thom: using /usr/bin/X11 causes daniels to put on his angry eyes
<daniels> thom: /usr/X11R6/bin in PATH, kthxbye
<daniels> ;)
<thom> uh, the former is a symlink to the latter
<thom> *shrug*
<daniels> yes
<daniels> i would like to kill the former
<fabbione> oh god!
<daniels> more than I would like to kill the latter
<fabbione> someone gives me back the original buugzilla
<fabbione> it's kinda.. hmmmm horrible?
<rburton> no jdub today?
<seb128> "You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party."
<seb128> GRRRRR
<seb128> stop this NOW
* seb128 kicks bugzilla
<fabbione> seb128: i think you should talk to justdave
<fabbione> but is not here
<fabbione> daniels: no luck -O0
<daniels> fabbione: arse :\
<daniels> $10 on the loader
<fabbione> $100 that we will get tons of duplicates
<daniels> yah :\
<daniels> if you want, I could try to build an nv_drv that we can dlload
<fabbione> hmm
<fabbione> no hold on
<fabbione> with -O0 doesn't crash
<daniels> ?
<fabbione> but the screen is black
<daniels> oh, garbled display
<daniels> arse
<fabbione> IF THAT PUNK WILL EVER MANAGE TO SEND A REPLY IN THE SAME PLACE
<fabbione> amd64 = little endian, right?
<thom> why do people want to flipping use mod_rewrite all the time?
<fabbione> thom: because there is too much good crack around
<sivang> morning all
<sivang> what was the final decision about the ubuntu-desktop pkg?
<Sledge__> anyone interested in fixing #1207?
<thom> Sledge__: i'll look once i'm back in amd64
<thom> couple of hours, probably
<Sledge__> cool, ta
<Sledge__> the fix is obvious, mail me if you want a patch
<seb128> what's the right place to add an "updatedb" after the installation ? I want to reassign #1439
<Kamion> base-config
<seb128> ok, thanks
<thom> lets see how my sparc deals with a 2.6 kernel
<thom> badly, appears to be the answer
<jdub> rburton: pong
<rburton> jdub: welcome back. :)
<thom> jdub: i now have a working firefox
<rburton> jdub: two things. 1) i hear you've been talking to my partner in sysadmin crime dalderman
<jdub> haha
<jdub> thom: :-)
<rburton> jdub: and 2) can you mail me all of your .desktop files?  i want to play with python-xdg
<jdub> yours aren't good enough? ;)
<thom> jdub: you have to disable typeaheadfind to get typeaheadfind to work
<jdub> thom: uh....huh.
<jdub> that's completely bong
<thom> cool huh
<jdub> rburton: so i ended up reinstalling the machine i installed every desktop package on ;)
<rburton> jdub: dammit! :)
<jdub> thom: can you change your sync alias to jeff.waugh@ etc. ;)
<thom> yeah, guess
<thom> you have filters i presume?
<jdub> two Maildirs :)
<daniels> spunky
<thom> ahr
* thom -> amd64
<daniels> thom: ... disabling the extension ... makes it work ...
<Sledge__> thom: cheers on the 1207 fix
<thom> daniels: cool huh?
<daniels> thom: you can have the assassinations; i'm *so* sorry.
<thom> *g*
<thom> yikes. mdz is gonna hurt me
<thom> the fix for 1600 is to bring c-client into supported, have it available but not build the imap package
<daniels> !!!!
<daniels> 0
<daniels> (ignore the 0)
* daniels jumps in the queue behind mdz.
<thom> fuck i hate php
* thom hacks
<lamont> Kamion: I keep getting bugs in that I can only explain if I believe that postfix's (debconf) config is being run before the initial user is added, or we have a hostname, or whatever...
<thom> hrm. i take it back
<thom> it just happened to work after i did that
* thom is now running a version with out, adn that works too
<thom> yay
* lamont wishes that bugzilla would add References: lines so that things wound up threading better.
* lamont wanders off again.
<mdz> thom: the what now?
<Mithrandir> Kamion: any response from mrvn on the grub problem?
* schweeb pokes lamont
<T-None> schweeb: should be back in 2h
<schweeb> vim is majorly broken.
<schweeb> filing a bug now.
<schweeb> no alias from vim->vim.org, gvim supposedly included, but not installed, etc...
<schweeb> the .list files in /var/lib/dpkg/info should tell you all of the files that are in a package, right?
<mdz> elmo: I haven't seen auckland misbehaving in some time; it really does seem to be related to your rsyncing antics
<T-None> schweeb: all the files that are installed by the package
<T-None> wich is slightly != all the files in the .deb
<schweeb> gotcha
<schweeb> could be generated by debconf or something
<mdz> schweeb: the bug is already filed
<schweeb> mdz: is it?  the one where vim isn't symlinked?
<mdz> schweeb: 834
<mdz> it's not meant to be symlinked
<mdz> vim-gnome, vim-python etc. divert /usr/bin/ vim when they're installed
<mdz> but then don't remove the diversion when they're removed
<schweeb> ah
<schweeb> so /usr/bin/vim should be... ? an executable?
<schweeb> oh, I see now
<schweeb> vim.org == vim original
<elmo> mdz: huh?
<elmo> do you mean the Sources.gz thing or something else?
<mdz> I've never seen the Sources.gz thing
<mdz> just it becoming unresponsive
<elmo> that wasn't 'rsync antics' it was just me using apt-get on the LAN
<mdz> the Sources.gz thing would be easier to dismiss as SEP if it weren't happening to several different people on different ISPs, running Ubuntu
<mdz> oh, I thought at the time you said you were shipping ISOs around
<mdz> speaking of ISOs...
<elmo> oh, well I might have been dl-ing an ISO, but it would have been using http
<mdz> Kamion: what would it take to convince debian-cd to build DVD images?
<Kamion> probably not a lot, I can grab the runes from gluck
<mdz> ah, ok. whenever I think of thrashing I/O bandwidth, rsync comes to mind
<Kamion> but now isn't a good time to ask, buried in mklibs :-/
<mdz> Kamion: what's broke?
<npmccallum> mdz: everything went find in the ooo build except for the splash screen, which I'm trying to figure out now
<Kamion> mdz: I'm at the d-i developer meeting today
<mdz> ah
<Kamion> trying to make graphical d-i boot, which is not as easy as it doesn't sound ;)
<Kamion> I did make powerpc boot off a USB stick this morning though
<Kamion> ('boot usb1/hub@1/disk@1:2,\\:tbxi', yum)
<Mithrandir> Kamion: did you talk to mrvn?
<Kamion> Mithrandir: um, whenever I've talked to mrvn today I haven't managed to get anything useful done for the next half an hour 'cos he goes off rambling about something or other
<Kamion> give me a while to work myself up :)
<Mithrandir> Kamion: sure, just wondering, not prodding
<Mithrandir> Kamion: I'm off playing mao in a bit anyhow.. gotta infect trondheim as well. :)
<Kamion> heh
<npmccallum> seb128: is there a reason abiword doesn't have a .desktop file?
<seb128> he has afaik
<seb128> or the -gnome version has at least
<npmccallum> seb128: abiword-gnome did it, thanks
<seb128> np
<npmccallum> mdz: I lied, the ooo splash screen does work, but I was running mixed versions :)  It should be ready for upload
<mdz> npmccallum: great, thanks
<npmccallum> mdz: approval?
<mdz> npmccallum: yes
<mdz> gah
<mdz> thom: scroll wheel seems to have stopped working in firefox?
<mdz> er...only in _some tabs_
<daniels> mdz: it's not to do with partial vs full loading?
<daniels> mdz: i can't use (shift-)ctrl-tab or f6 on partially loaded tabs
<mdz> daniels: well, I had a tab where it was working, and then stopped after I scrolled around a bit
<mdz> and it wasn't loading
<daniels> hrm
* daniels sleeps.
<daniels> 0% [1 bsdutils 34401/62.6kB 54%]                                                                                     3459B/s 20h5m43s
<daniels> (hooray)
<mdz> elmo: here?
<elmo> mdz: yeah
<mdz> elmo: sorry to bug you, but lamont is incommunicado today
<mdz> elmo: wanted to know if you could look into #1257
<mdz> seems to have been successfully built, but never appeared in the archive
<elmo> it's an archive problem anyway, I'll fix in a sec
<mxpxpod> is anyone around that has access to the buildd's?
<mdz> mxpxpod: the logs are now public, temporarily housed here: http://people.no-name-yet.com/~lamont/buildLogs/
<mxpxpod> mdz: well, vim is all messed up right now on powerpc
<mdz> mxpxpod: messed up how?
<mxpxpod> Unpacking vim-gnome (from .../vim-gnome_1%3a6.2-532+4ubuntu2_powerpc.deb) ...
<mxpxpod> Leaving `diversion of /usr/bin/vim to /usr/bin/vim.org by vim-gnome'
<mxpxpod> dpkg: error processing /var/cache/apt/archives/vim-gnome_1%3a6.2-532+4ubuntu2_powerpc.deb (--unpack):
<mxpxpod>  trying to overwrite `/etc/vim/gvimrc', which is also in package vim
<mxpxpod> Errors were encountered while processing:
<mxpxpod>  /var/cache/apt/archives/vim-gnome_1%3a6.2-532+4ubuntu2_powerpc.deb
<mxpxpod> elmo: Sub-process /usr/bin/dpkg returned an error code (1)
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1717
<mdz> not a buildd problem, just a bug
* Mithrandir has been playing mao.. fun, as usual.
#ubuntu-devel 2004-10-06
<jdub> mdz: heh, irssi-text -> glib2.0 ;-)
* lamont wanders in, grumbles at OO.o
<mdz> jdub: dude, glib1.2 is gone from desktop now
<jdub> that is so rad
<jdub> also, i did not build the glib1.2 support in polypaudio
<jdub> we will kill it
<jdub> and esound
<mdz> it's a long way from being kicked out of main though
<mdz> lots of  gtk1.2 apps in supported
<jdub> yeah
<jdub> what about that bongy accounting package? ;)
<mdz> the one that you spazzed over, while all this other ancient cruft goes in supported? :-P
<jdub> heh
<mdz> installed from universe and working fine, thankyouverymuch
<jdub> that's good
<mdz> needed a gal upload to get it building
<jdub> no fixes required?
<jdub> aha
<jdub> okay, so
<jdub> i want to write a little script
<jdub> that tells me which of my packages are universey
<mdz> it's sort of a hacky thing to want to do
<mdz> because there's no record of where stuff came from
<mdz> all you can do is compare it to where the packages are in the archive now
<mdz> that's basically what apt-show-versions does
<mdz> which should be in universe
<jdub> -> /var/lib/apt/lists/*universe*_Packages ;-)
<jdub> (awk '/^Package:/ { print $2 }' /var/lib/apt/lists/*warty_universe*Packages ; dpkg --get-selections | awk '{ print $1 }') | sort | uniq -d
* mdz gags
<jdub> haha
<mdz> apt-cache dumpavail | grep-dctrl -nsPackage -FSection universe
<jdub> grep-dctrl is not installed by default ;)
<mdz> comm -12 <(apt-cache dumpavail | grep-dctrl -nsPackage -FSection universe/ |sort)  <(dpkg --get-selections | cut -f1 |sort)
<mdz> grep-dctrl is in supported, and is the right tool for the job :-P
<mdz> 28 packages here
<jdub> 47 8)
<mdz> a bunch of them from gnucash
<mdz> and a handful from grepmail
<mdz> dict is showing up in there for now :-)
<mdz> that'll go away
<mdz> debian-policy is in universe :-)
<mdz> that's almost blasphemous
<jdub> whoa
<mdz> hmm, i had some random libgnome-vfs crap installed that I didn't need, probably bbuild-deps of something
<mdz> down to 27 now
<jdub> man
<jdub> firefox doesn't start :|
<jdub> if i move away my .firefox, it's fine
<mdz> 2 of them are already slated to move into main
<lamont> mdz: hadn't seen the 'will approve bind9 sync' before - thanks for requesting it
<mdz> lamont: I went ahead and fixed vim as well, since it was breaking all sorts of things (including the base install)
<lamont> yeah - was just reading that bug report, see the change.  thanks.
<lamont> ran out of time last night before getting exactly the plan in my head.  Bad timing that.
<mdz> lamont: regarding oo.o, Sep 24 13:09:47 <elmo>  it's an archive problem anyway, I'll fix in a sec
<lamont> oo dictionaries: archive.  oo/ppc: log file too big for mailer.
<mdz> hmm, come to think of it, it's been 6 hours. I should probably mail elmo
<mdz> oh, you just did with the bugzilla comment
<lamont> oo.o is there for i386
<lamont> yep
<mdz> lamont: I meant oo.o-dictionaries
<mdz> oo.o was uploaded today, and also oo.o-dictionaries was supposed to move into main
<lamont> oo.o/ppc binaries uploaded
<lamont> I think I may just bump things up on the buildds to handle the larger log files, now..
<lamont> was already done most everywhere.  even easier. :-)
<lamont> the next OO.o (or other huge-logged) upload shouldn't stall for mail bouncing.
<lamont> mdz: 1711 et al.
<lamont> there are a growing list of bugs that make me wonder exactly when postfix is getting configured...
<lamont> because root mail goes to uid 1000 if it exists (and there isn't an alias for root yet)...  Hence 1711 is, um, worrysome...
<lamont> but I'm not going to think too hard about it this weekend.. :-(
<mdz> lamont: I assume postfix is getting configured from debootstrap
<mdz> because it's part of base
<mdz> this is why Debian runs MTA configuration from base-config
<mdz> we probably need to do the same, but noninteractive
<lamont> that would be fine.
<lamont> didn't we do that at one point, and it got ripped out?
<lamont> or was that because it was interactive?
<lamont> because configuring it from base-config (even noninteractive) is the only way I can see to solve 1711.  Well, short of having the init.d code detect first-start-with-userid-1000-present, and dtrt then.. (which would probably violate policy in 16 diff ways...)
* tseng pokes lamont per instruction
<tseng> who wants to talk mono in universe
<lamont> eh?
<tseng> jdub said you were k-rad and could help me in my mission of mono -> universe love
<tseng> http://wiki.ubuntu.com/UniverseCandidates has some details.
* lamont reads
<lamont> are the source packages we care about in warty source already? or do they need to be sync'ed?
<tseng> i worked off of sid because the stuff in warty (bins) were broken
<tseng> i could check out building from warty source
<lamont> if the sid stuff builds, and you can get mdz/jdub to approve sync'ing sid, then I can bootstrap it in the archive
<lamont> likewise, if warty sources build, and just need to be appropriately beaten^Wbootstrapped, then I can do that as well.
<jdub> i approve of syncing sid
<jdub> much more useful than current warty universe versions
<lamont> works for me... and it's easier to bootstrap from current sid, than old sid...
<tseng> sorry i didnt make a source pkg with the monodevelop patch
<tseng> im still figuring out debian packaging, there seem to be 10 ways to do any given task
<lamont> bootstrapping isn't so bad.... It's more work when you don't have a pre-bootstrapped-on-the-right-arch set of debs.. :)
<tseng> i built everything by a combination of apt-get source -b and dpkg-buildpkg
<tseng> probably did everything the hardway, but barring a few bumps the stuff builds against warty main universe
<lamont> right.  Is it just a matter of building in the right order (and just source is needed), or do I need some build-dep binaries installed at the right magicpoints?
<tseng> only major failures i recalls are monodevelop (patch on the wiki) and muine
<tseng> muine wants mono-mint seemingly as a build dep
<tseng> but my x86 build didnt produce such a thing
<lamont> declared already, or needs to?
<tseng> its my understanding its only needed on amd64
<lamont> build-deps can be arch-specific
<tseng> it doesnt need it on x86... the dep is more accurately ( mono-mint || mono-jit _
<tseng> *)
<lamont> buildd only uses the first one...
<lamont> mono-jit [!amd64] , mono-mint [amd64] , I think
* tseng looks
<tseng> i dont see mono-mint in the control file
<lamont> yeah - not too bad to fix, though.
<lamont> jdub: do you need tseng/me to propose the sync so you can approve it, or could you send the email?
<lamont> grumble.  www.anywho.com crashes firefox
<lamont> Segmentation fault, it says
<tseng> worksforme
<lamont> 0.99+1.0PR-0ubuntu1
<tseng> 0.99+1.0PR-0ubuntu3
<lamont> yeah
<tseng> yay you fixed vim.
<jdub> tseng: could you mail mdz/myself and lamont?
<tseng> yes I can
<tseng> uh oh not from gentoo.org
* tseng hits gmail :)
<lamont> tseng: mdz fixed vim.
<tseng> jdub: what am I mailing you?
<lamont> that firefox works better.
<tseng> oh I thought about mono.
<tseng> some secret proceedure about syncing sid
<jdub> tseng: request for sync of packages (please lsit)
<tseng> {jeff.waugh,lamont.jones,matt.zimmerman}@cannonical.com, yes?
<lamont> should work
<tseng> im leaving f-spot off the list
<tseng> it doesnt work very well for me
<tseng> oops i used the wrong addy after all
<tseng> sent.
<lamont> tseng: given timezones and such, it'll probably be monday before I do any handholding
<jdub> tseng: oh! you packaged tomboy
<tseng> jdub: hmm kinda
<tseng> i seem to remember reading that dpkg figures out the runtime deps
<tseng> but it doesnt seem to pull in the newer libgtkspell
<tseng> if i install that by hand the pkg works ok
<tseng> i just managed to mess it up somewhere
<jdub> hmm
<jdub> tomboy doesn't seem to use gtkspell
<tseng> ./configure disagrees
<jdub> tseng: ahr, you need to put source up in your archive :)
<tseng> i could do that
<tseng> just slap the files in the same dir?
<jdub> yeah
<jdub> and run dpkg-scansources
<tseng> sure
<jdub> like scan-packages
<tseng> 2 mins
<tseng> that should do it.
<jdub> ahar, rocking :)
<tseng> jdub: sorry.. working now
<tseng> i r dumb.
<jdub> heh
<jdub> tseng: why is libgtkspell-dev in your archive, btw?
<tseng> tomboy seemed pretty adament about wanting the newer lib
<jdub> ah, tomboy needs > 2.0.6, we only have 2.0.5
<tseng> configure checks >=2.0.6
<tseng> ya.
<jdub> so it actually works with 2.0.5
<jdub> but >= 2.0.6 does pango underlines
<tseng> ah
* jdub hmms.
<jdub> that's really something that should be updated.
<tseng> seems pretty simple
<tseng> and/or didnt make anything explode
<jdub> mmm
<jdub> bit frivolous though
<jdub> tseng: you need to add mono-mcs to the build depends
<tseng> sure.
<jdub> i have the sneaking suspicion...
<tseng> added mono-mcs
<tseng> and broke the repo again.
<jdub>         [DllImport ("libgtkspell.so.0")] 
<tseng> :P
<jdub> ^ dynamically loads gtkspell
<jdub> so you should add the binary name to the Depends line
* lamont sleeps
<jdub> night lamont :)
<tseng> cya.
<tseng> add gtkspell?
<jdub> Depends: ${shlibs:Depends}, ${misc:Depends}, libgtkspell0 (>= 2.0.5)
<tseng> hmm sure
<tseng> jdub: getting late this side of the pond, ill catch you another day
<jdub> 'night!
<tseng> that package should suck less now
<jdub> tseng: i'll send a debian dir tarball for some hints :)
<tseng> hmm ok :)
<daniels> mdz, jdub: xresprobe 0.4.9 (with interdiff) on http://people.ubuntu.com/~daniels/xresprobe; all it does is re-add some monitor frequency detection code that was lost when we got detailed timings. ok for warty?
<Kamion> lamont: we removed postfix from base-config for reasons that I am and was convinced are specious; if there's a good reason for me to put it back, please hand me the ammunition :)
<jdub> yo Kamion 
<jdub> Kamion: how's the d-i wiggling going?
<Kamion> pretty well, productive so far
<jdub> daniels: approvedf
<jdub> Mithrandir: someone posted about dm-crypt devices and hal on hal-list just recently
<daniels> jdub: thanks
<Mithrandir> Roar: jdub got an URL? :)
<jdub> um
<jdub> not in my mail client ;)
<jdub> Subject: Device mapper interface and HAL
<jdub> it's hosted on freedesktop.org
<mdz> daniels: approved
<Mithrandir> jdub: yeah, looks interesting
<mdz> Kamion: that issue with stuff appearing in base was vim, I think (in which case it's fixed now)
<mdz> I tested debootstrap anyway
<Mithrandir> Kamion: http://bugzilla.ubuntu.com/show_bug.cgi?id=1545 -- mrvn has answered now, and I think his answer makes sense.
<Kamion> mdz: ok
<Kamion> mdz: yes, that would explain it
<Kamion> Mithrandir: yeah, I talked to him last night and he convinced me it was OK
<mdz> daniels: #1153 has returned to you for more love
<Mithrandir> Kamion: ok, I'll make up a new package and get it approved, then.
<Kamion> mklibs HURTS my BRAIN
<daniels> mdz: saw that bouncing back. was thinking of a test to see if ppp_on_boot points to ppp_on_boot.dsl; if it does, and the latter doesn't exist, force a change?
<Mithrandir> mdz: 1545 ; http://raw.no/patches/grub_0.95+cvs20040624-3ubuntu16_2gb_limit.diff ; permission to upload?  This is in the pure64 archive already, so it has been fairly well tested.  (Will add bug # reference)
<mdz> Mithrandir: yes
<Mithrandir> thanks a lot
<mdz> and now to bed
<Mithrandir> sleep tight
<Mithrandir> yay, down to zaroo bugz for me.
<Mithrandir> that mean I can do something else for a few hours.
<seb128> morning
<tseng> monodevelop-0.5.1 fixed the bug
<tseng> im build debs + src for that.
* lamont hands kamion 1711, and a couple other postfix bugs he's been coding around lately
<tseng> guys, is there a command that turns in patch into a dpatch? monodevelop has patches wrapped in a bit of bash
<tseng> ah there it is.
<daniels> tseng: rad :)
<tseng> daniels: i lied, i just added the patch to 0.5 instead
<daniels> either way
<tseng> im out for the day, catch you cool cats later.
<daniels> seeya dude
* lamont passes through briefly, pointing at linux-source-2.6.8.1 (amd64,ppc), and mozilla/ppc ftbfs'es
<lamont> linux-source/i386 is still building
<thom> hrm, what happened about new dbus/hal?
<daniels> thom: what about it?
<daniels> do we need new Ubuntu packages?
<thom> i believe seb/pitti were looking at bringing the new ones across
<daniels> what for?
<seb128> pitti has hal 0.2.98 and dbus uptodate + gvm packages ready afaik
<seb128> daniels: devices locking
<daniels> ah ok
<daniels> i was going to say, I'm probably decently qualified to do them if they need doing ;)
<seb128> daniels: BTW, sjoerd is waiting for you and dbus to upload new hal/gvm in debian :)
<daniels> seb128: yeah, I just spoke to him then and asked him to NMU
<daniels> what with me not having a pure Debian machine and all
<seb128> ok
<seb128> you guys should do a packaging team for utopia stuff
<daniels> yeah, it's been floated
<daniels> I told Sjoerd to not hesitate to prepare NMUs and to just anity-check them past us if he felt it necessary
<daniels> since I won't have a Debian chroot for a couple of weeks yet
<Kamion> seb128: hypothetically, what would you think about adding the directfb patch to the Debian gtk+2.0 package?
<Kamion> um, wrong channel I guess, I'm really thinking about it for Debian
<seb128> I've not looked on it, but could be nice
<Kamion> I'm trying to get the d-i gtk frontend up and running here; the gtk+2.0-directfb package turns out to be a dodgy and rather broken fork of gtk+2.0 2.0.9 or so which needs to die a horrible screaming death
<Kamion> it screws about with library paths in a way that makes it pretty much impossible to build d-i against it
<Kamion> although the gtk-directfb ported to gtk 2.4 requires, er, directfb from CVS
<seb128> have you looked on kov's thread about the d-i gtk+ frontend: http://lists.debian.org/debian-gtk-gnome/2004/06/msg00315.html ?
<seb128> dunno how much he has played with it, apparently he didn't have a lot of free time during the last months, but could be nice to ping him. He probably has some idea on this
<Kamion> I haven't, but we appear to have got about the same distance in slightly different directions
<Kamion> I suspect I've got a lot further with cdebconf-gtk than he has, he's got further with the build
<Kamion> however as far as I can tell he hasn't actually checked in any changes :(
<Kamion> which makes it hard to cooperate ...
<seb128> I think he was trying to get some results before getting further
<Kamion> well, certainly there's not much point trying to improve the UI before having seen it :)
<Kamion> one of the problems that graphical d-i has is that nobody checks anything in though ... gtk.c hasn't been touched since March and spectacularly failed to pass even cdebconf's rudimentary tests
<seb128> yes, but that's because nobody is really working on it
<seb128> kov was the only guy interested for the moment apparently
<Kamion> well, true, most serious d-i people have been working on more urgent things
<Kamion> occasionally one person gets interested, works on it for a while, gets bored and goes off to do other things, and then never checks in what he's done so the next person starts over
<seb128> perhaps we should open an alioth project on alioth on something for the d-i frontend
<seb128> and try to get some people interested
<seb128> where is the current tree ? Who is allowed to commit changes (ie: kov can commit ?) ?
<Kamion> you don't need an alioth project, it's in d-i
<Kamion> any d-i developer
<seb128> yes, but the problem is that we probably don't want anybody able to commit in the d-i tree
<Kamion> all the changes *really* should go in d-i
<Kamion> lots of people already have commit access
<seb128> ok
<Kamion> d-i is watched pretty closely too
<seb128> kov is not here for the moment, but we should talk about this with him when he'll be here
<Kamion> well, I'll continue with what I'm doing for the moment; I'm on a roll :)
<seb128> ok
<Kamion> I'm sure it won't be too hard to merge
<seb128> afaik kov has not made big changes, so it should be easy
<Enyo> Hello
<doko> do we have somewhere a list of supported languages for warty? or better: which should be supported?
<mdz> lamont: flushing old mail?
<mdz> elmo: openoffice.org-dictionaries?
<doko> mdz: did the spell checking mail arrive on the list?
<npmccallum> Mithrandir: did you see Matthias's post to ubuntu-devel yet?
<mdz> doko: yes, I am replying
<Mithrandir> npmccallum: no, sorry, been hacking ARM cross compilers all day, will go read.
<npmccallum> Mithrandir: its all the spell checking stuff
<npmccallum> mdz: I thought openoffice.org-dictionaries was in warty...
<npmccallum> mdz: nevermind, it was thesaurus that I was thinking of
<thom> mdz: are you still having problems with your scrollwheel in firefox?
<mdz> thom: not today, no
<mdz> thom: is there reason to believe it may have been fixed?
<thom> not that i'm aware of, but i can't duplicate it on amd64 or x86
<thom> mdz: did you keep your old profile?
<thom> it could be related to that
<mdz> thom: I didn't destroy my profile
<mdz> I think it was happening to daniels
<mdz> I think the problems preceded your "fix it harder" upload
<thom> heh
<thom> they're quite possibly fixed in -0ubuntu3, but moz seems to be very sensitive about profile destruction :/
<sivang> do we install ppp from base-config?
<sivang> oh it's on the installer seed. guess it's enough for users with dial in broadband
<thom> oh. so, i'm getting a via mainboard for my amd64, and sata. just to give the installer a stretch :-)
<mdz> sata seems to be a source of strange problems
<thom> yeah, it should be an interesting adventure
<thom> my main install will stay on pata for the time being tho :-)
<lamont> mdz: didn't think I was... am i?
<mdz> lamont: just got mail from you dated Sep 14
<mdz> lamont: ahh, you sent it to debian.org
<mdz> and debian.org mail has been fucked
<lamont> that must be it - was getting some myself, wondered why...
<thom> mdz: doogie just fixed master, so it could be old debian mail
<lamont> so who must I convince to get the non-interactive config run of postfix into base-config?
<Kamion> lamont: please remind me when I'm IN THE RIGHT COUNTRY :-)
<Kamion> lamont: I will do it, but probably not from here
<thom> i got mail from Joey dated from the 15th about a security upload *sigh*
<lamont> Kamion: wasn't meant to pester you, was looking for more ammo to give you...
<Kamion> lamont: ah
<Kamion> lamont: setting up /etc/aliases properly is sufficient ammunition for me
<lamont> thanks
<Kamion> lamont: as far as I can tell it'll fix that bug ...
<Kamion> ?
<lamont> yes
<Kamion> good-oh, will restore it then
<mdz> Kamion: what are we going to do about that debootstrapped-packages-with-debconf-questions issue?
<lamont> dpkg-reconfigure postfix after uid1000 is added will kill that bug
<mdz> Kamion: (#1388)
#ubuntu-devel 2004-10-07
<jdub> tseng: around?
<Kamion> mdz: #1388 is filed somewhere in Debian too. It's still got joeyh scratching his head over the correct answer. There are some possible hacks, but he'd like to think about them.
<mdz> Kamion: we should do something about it for Warty
<Kamion> One hack would be having the noninteractive frontend set the seen flag if and only if $ENV{DEBCONF_I_AM_RUNNING_INSIDE_DEBOOTSTRAP} or something is set
<mdz> my feeling is that when the package is configured non-interactively, the questions should be marked seen
<mdz> I think that makes sense regardless of whether debootstrap is part of the equation
<Kamion> mdz: I suggested that to Joey, but he's not entirely sure about some of the ways people are using noninteractive on their own systems
<Kamion> I tend to trust Joey's judgement in these matters ...
<mdz> Joey has no incentive to make a determination on this issue before the Warty release, but we must
<Kamion> look, I'm not saying we shouldn't, OK?
<mdz> ok
<Kamion> I'm trying to avoid having to support a fork in debconf that's too evil, by getting something supportable done before the Warty release instead
<Kamion> I'm not trying to put it off until post-warty
<Kamion> since I have the debconf author sitting ten feet from me, talking to him is worthwhile :-)
<mdz> sure
<mdz> does Sarge not have any debconf-using packages in base?
<mdz> hmm, surely it does
<Kamion> yes, it does, that's why the bug is also filed in the Debian BTS
<Kamion> I'm just looking for it as Joey asked me to now
<Kamion> #238301
<mdz> thanks
<mdz> I'll import it into bugzilla and mark the other one as a dupe
<Kamion> followed up to the new one with current brain state
<Kamion> will fix it when I get back
<mdz> Kamion: thanks
<mdz> Kamion: how is the meeting going?
<Kamion> very well, lots of stuff fixed
<Kamion> I've spent most of the meeting trying to get gtk d-i up and running, still wrestling with directfb unfortunately
<Kamion> but talking to Sven has made it possible to agree on stuff to remove from the powerpc CDs to make them halfway sane, and the appropriately hideous death of the root-2 floppy
<Kamion> oh, and I managed to boot my powerbook from a USB stick, which will speed up my d-i testing a lot in the future 'cos I won't have to burn CDs
<mdz> nice
<mdz> my laptop seems to quite happily boot from a USB CD-ROM
<mdz> so I assume it would work with a USB stick, too, though I don't have one
<mdz> I found out quite by surprise; I left a Warty install CD in the USB drive accidentally when I rebooted
<azeem> my laptop (R51) just refuses to go beyond the IBM logo when a USB stick is plugged in :-/
<Kamion> booting a powermac from USB requires Runes Of Power
* azeem chuckles
<Kamion> unless your OF defines a useful devalias, which mine doesn't; I suspect it's rare to find that
<jdub> Kamion: do we know of any successful installs on pre-toilet-seat powerpc/g3 laptops?
<Kamion> jdub: are there any such which are newworld?
<Kamion> if you gave a model name rather than "toilet-seat", I could check :-)
<jdub> what are black g3 powerbooks?
<jdub> maybe the model is "wall street"?
<Kamion> wallstreet is oldworld
<jdub> aha
<Kamion> (and we don't support oldworld)
<jdub> tops
<Kamion> the first newworld laptop was the Lombard, I believe
<Kamion> that was a powerbook though ... your iBook might be the Bondi?
<Kamion> I confess to not being able to keep track of a lot of the earlier model names
<Kamion> aha, fear our documentation :-)
<Kamion> http://archive.ubuntulinux.org/ubuntu/dists/warty/main/installer-powerpc/current/doc/manual/en/ch02s01.html#id4739961
<Kamion> it's not up-to-date about a lot of things, but anything marked "powermac-OldWorld" there is unsupported
<jdub> azeem: so
<jdub> azeem: basically nothing should be listed in shlibs?
* jdub is deferring the RPATH stuff, very odd ;)
<azeem> well, it is my opinion that if your package does not have any regular shared libraries, but only plugin-type stuff, shlibs should not be used
<azeem> but I'd be interested in the opinion of the demi-gods in here
<mdz> jdub: context?
<Kamion> azeem: agreed
<Kamion> (without context ...)
<mdz> shared objects used as plugins don't need shlibs entries
* lamont made failure buildlogs red on http://people.ubuntu.com/~lamont/buildLogs/byDate
<mdz> they should have shlibdeps though
<jdub> yeah, these are all dlopened plugins
<jdub> shlibdeps is all fine though
<mdz> and ldd -r says they're clean?
<jdub> hrm
<jdub> clean being no undefined symbols?
<jdub> yeah
<jdub> hmm
<jdub> they have undefined symbols
<jdub> but those are all in the same package
<mdz> the plugins should be linked with any dependent shared libraries
<azeem> jdub: polypaudio-alsa does not seem to depend on libpolypaudio0 though, which I guess provides the missing symbols
<mdz> if they need symbols from the binary which loads them (RTLD_GLOBAL or whatnot), that's a bit annoying, but not obviously wrong
<jdub> azeem: mmm
<jdub> azeem: though that's a special case, being a different package
<jdub> azeem: but it does mean there's something wrong with the plugins (and why they have undefined symbols)
<azeem> well, I didn't check thoroughly
<jdub> this totally assumes rpath
<jdub> azeem: 
<jdub> $ dpkg-deb -I ../polypaudio-alsa_0.5.1-1ubuntu1_i386.deb  | grep Depends
<jdub>  Depends: libasound2 (>> 1.0.5), libc6 (>= 2.3.2.ds1-4)
<jdub> 
<jdub> ^ wrong
<azeem> you might touch the border of cdbs' applicability here
<jdub> argh
<jdub> cock
<jdub> it's in svn :)
<azeem> anyway, I'm going to bed now, *tired*
<jdub> night, thanks again :)
<jdub> The following NEW packages will be installed:
<jdub>   db4.2-util libapr0 libpcre3 libruby1.8 libsvn0 libswig1.3.21 subversion
<jdub> 
<jdub> *bong*
<mdz> jdub: what do you think about creating non-english ubuntu discussion lists?
<mdz> I didn't think we'd need them so soon
<mdz> there seems to at least be an -es contingent who would appreciate it
<jdub> mdz: i asked mark about it, he's happy with ubuntu-users-$LANG
<jdub> i'll do the -es one now
<mdz> cool
<jdub> i'll ask carlos to admin it ;)
<jdub> and find other moderators
<jdub> heh
<jdub> i'm glad i set the defaults from ubuntu-users
<jdub> because changing the default language makes the list hard to admin ;-)
<Mithrandir> hmm, what's up with bugzilla?  No new bugs for me the whole day..
<tseng> jdub: here i am
<jdub> tseng: the mono depends in the tomboy example i sent you was kinda wrong
<tseng> hm
<jdub> tseng: it should really depend on mono-jit | mono-mint
<tseng> i think you meant mono-jit or mono-minut
<tseng> yeah
<jdub> ;)
<tseng> mint*
<tseng> i knew that but i had to go to work
* tseng offers no guarantee on his own repo, as im learning on it atm
<jdub> :-)
<jdub> it's good
<jdub> orph (alex, author of tomboy) is way pleased :)
<tseng> ya works pretty well
<tseng> oh neat
<tseng> 20:14 #ubuntu: < whiprush> woo tseng fan club.
<jdub> heh
<tseng> im famous or something.. barely did anything
<tseng> :P
<tseng> all the credit goes to the debian devs.
<jdub> mdz: is ndiswrapper a module?
<jdub> mdz: so it can be in restricted?
<tseng> jdub: yeah its a module + a bit of userland
<tseng> there is an app to install the inf from the windows driver
* jdub knows what it is, wonders what our plans are
<mdz> jdub: yes, it is a module, but it's GPL
<mdz> and so there's no reason to demote it to restricted
<jdub> mdz: linux-image == supported, restricted == unsupported
<jdub> that's a HUGE reason
<mdz> restricted != unsupported
<mdz> universe == unsupported
<mdz> restricted is "supported the best we can given the restrictions"
<jdub> restricted is unsupported
<jdub> it
<jdub> it's just best efforts that the packages will build and work
<jdub> and we *cannot* support ndiswrapper
<mdz> Mark was quite clear on this point in Oxford
<jdub> i thought he was too
<mdz> the userland part of ndiswrapper will print scary warnings
<jdub> unsupported, best-efforts
<mdz> supported, best-efforts :-)
<jdub> i'll mail
<jdub> because this is senseless
<mdz> ok
<mdz> the only clear use case for restricted is binary-only drivers
<mdz> we've been over and over it
<jdub> ndiswrapper is an enabler for binary-only drivers
<mdz> correct
<jdub> but that's a secondary issue
<mdz> but it is itself an open source project
<mdz> yes, it's a gross hack and it sucks
<jdub> and fundamentally unsupportable
* tseng notices that only some bits of asterisk are in universal
<tseng> i might have to fix that next week.
<lamont> evening folks
<jdub> yo lamont 
<lamont> dieman about?
<lamont> 'sup jdub?
<jdub> lunchtime is up
<lamont> heh
<jdub> but i have not figured out what to eat
<lamont> almost bed time
<lamont> I hate the final week before a convention.
<lamont> but nowhere near as much as I hate plumbing
<lamont> mdz: having a hard time picturing 1784 as warty critical, especially since mark and I agreed to discuss auto-config of SASL/TLS post-warty
<lamont> and certainly not grave for debian..
<lamont> set to important
<lamont> mostly to avoid arguing about why I think it's really a wishlist bug
<lamont> or dup of any one of about 6 others like it.. :-(
<jdub> lamont: what are the postfix requests?
<lamont> "grave: after I install postfix-tls, I have to actually configure SASL if I want to use it"
<lamont> s/SASL/TLS/ as needed...
<lamont> it's not that it does it wrong, it's that it doesn't do it...
<tseng> like, add users to a sasl db, or have it use the system passwd file?
<lamont> so once we have hoary opened up, that guy what knows certificates and such is gonna walk me through making postfix-tls autoconfigure sasl and/or tls....  But not before warty..  Or sarge.
<lamont> jdub: hrm.. this bug came from your corner of the world...
<schweeb> so, what's the accepted way of turning laptop-mode off in ubuntu? because I'm  fairly sure that laptop-mode is fucking up my hard drive.
<schweeb> will file a bugreport, if I can find some diagnostic info or something to prove it
<schweeb> but twice, my hard drive has made a spinup or spindown sound, and then anytime I try to access the HD, I just got an I/O error
<schweeb> reboot, fine... then it happened again
<jdub> lamont: ahr.
<mdz> lamont: that's clearly not RC
<mdz> enhancement, Hoary
<lamont> yeah.
<lamont> I'll downgrade the debian bug further later.. :)
<lamont> mdz: how are we marking hoary stuff?
<mdz> lamont: target milestone: hoary hedgehog
<lamont> or are we just assuming that things beyond warty will likely get revisited for hoary?
<mdz> assuming mark said it should be on the list for hoary
<mdz> otherwise, it doesn't need a milestone
<mdz> or we need a "someday" milestone :-)
<lamont> updated
<mdz> jdub: your "spanish list" email was duplicated :-/
<mdz> but not "burning ISO image"
<mdz> something weird is going on with your mail
<mdz> they have different message-ids
<mdz> Message-Id: <1096172902.4733.104.camel@localhost.localdomain>
<mdz> Message-Id: <1096172903.4733.105.camel@localhost.localdomain>
* lamont sleeps
<fabbione> morning
<daniels> fabbione: morning
<fabbione> mdz: are you still around?
<sivang> Where would be the right place to suggest packages for base install? pptp should be included for those on countries who must use a pptp dialer to access broadband..
<sivang> i had to go back to xp home to manually download the .deb file for pptp, and ofcourse I would have to resolve the dependecies by hand.
<thom> schweeb: remove it from power.sh
<sivang> Kamion : around?
<Kamion> sivang: yes?
<jdub> mdz: bong
<jdub> sivang: pptp-linux will be on the cd
<jdub> sivang: not installed by default, but on the cd
<sivang> jdub : it's not currently, right?
<sivang> Kamion : would it be reasonable to incorporate into base-install or post, a pptp confiugration question, just for those who lake DHCP authenticated internet broadband, who _do_ wish to update from the net?
<sivang> Kamion : I'd like to try a go at it myself, however what would be the willingness to add _yet_another question to it?
<sivang> Kamion : or even adding it along side the "ppp" d-i configuration scree.
<azeem> well, having an easier way to configure pptp would be nice (if this is not the case already), but I doubt that the user-base is large enough to warrent an additional question anybody would see
<sivang> azeem : meaning people would miss it?
<sivang> azeem : moreover, we've had several problems streamlining pptp connection in israel in various distribs, debian has it going with a script that somebody wrote, and I improved, which I can adjust to all internet providers here. Would make it nice to have this built in :-)
<mjg59> Is there any reason apm isn't loaded by default?
<sivang> does anybody know how to disable that freakin' beep when in pure console mode? this thing's driving me crazy..:)
<sivang> i disabled it for my debian sid long ago, but forgot how it goes.
<Mithrandir> : tfheen@yiwaz ~ > cat .inputrc 
<Mithrandir> set bell-style visible
<sivang> tnx
<sivang> that would be great
* sivang is still fighting to make his warty connect using pptp to the israeli broadband.
<mdz> fabbione: here
* lamont giggles at fabbione
<lamont> <T-Bone> stupid xfree maintainer:
<lamont> <T-Bone> /usr/bin/make -C build-tree/xc WORLDOPTS="" IMAKE_DEFINES="-DXFree86CustomVersion='\"Ubuntu 4.3.0.dfsg.1-6ubuntu21 20040926054320 root@gropaf.esiee.fr\"' -DBuildSpecsDocs=NO -DBuildFonts=NO" World > logs/make_world.build.log 2>&1
<lamont> <T-Bone> make: *** [stampdir/build]  Terminated
<lamont> <T-Bone> Build killed with signal 15 after 150 minutes of inactivity
<doko> :-)
<azeem> it's a good way to identify doorstop architectures
<azeem> ;)
<lamont> azeem: hppa is _not_ a doorstep architecture, dammit. :-)
<azeem> well, my hppa box is
<azeem> (with the stress on "my")
<lamont> what model?
* lamont contemplates filing a wishlist bug against metacity for 'focus follows users attention/eyes'
<azeem> 512/40 or something?
<azeem> it's lying around in the basement, haven't touched it for a year, because back then (running woody, kernel 2.2), it decided to freeze every couple of days for no apparent reason
<lamont> 712/60 I could believe
<lamont> pizza-box sized?
<azeem> yeah, that's it
* lamont has one of those kicking around here somewhere, he thinks.
<lamont> my firewall is a B180
<azeem> I have to admit I got it for free because the university dumped it, a friend of mine picked it up, couldn't connect a monitor to it and then wanted to throw it away
<azeem> so the hardware might be broken
<lamont> nah 712's are dog slow.
<azeem> Jens Schmalzing sent me a mail today that he installed potato on my father's old Mac SE/30 :)
<azeem> *that's* dog slow :)
* lamont one time put winblows 95 on a 386 w/16MB  (back when)
<lamont> bunch of folks said you couldn't do that...
<azeem> heh
<azeem> I remember I got royally pissed off by Microsoft when I upgraded my 386 from 4 to 8MB because the preview releases said Windows95 would run fine on it, and when it released, you needed a much better system
<lamont> that machine had 15 minute boot times.  Literally
<lamont> Grumble. No jpilot happiness with USB sybc.
<lamont> so, how do I get evo to honor the categories on my palm...
<lamont> address book, that is..
<azeem> what kind of palm do you have?
<lamont> tungsten C
<azeem> lamont: AFAIK does the pilot-link stuff not handle the "new" PalmOS 4.x(?) features. I know it doesn't handle birthdays in contacts on my mother's Tungsten E
<lamont> dunno
<lamont> was justing jpilot, talking to a serial dock...
<lamont> but I just gave the serial doc to my wife...
<lamont> hence I need to figure out USB...
* lamont upgrades his machine, just to stay current.
* lamont reboots, for completeness
* Mithrandir starts compiling coreutils on a microVAX running netbsd 1.4.  I think it takes more time than lamont takes to reboot.
<Mithrandir> .. to run the configure script.
<lamont> moof
<lamont> and hotsync works again. yippee
* Mithrandir notes said configure script has output about ten more lines since lamont rebooted.
<lamont> LOL
<lamont> USB sync is much faster than 9600 baud rs232 sync, too. :-)
<Mithrandir> god, I'm glad it caches the results.
<lamont> you doing the microvax-ubuntu port, then?
<Mithrandir> so far, I'm compiling coreutils to get rid of a cronmail I've been getting for half a year.
<Mithrandir> I wonder if mark would _really_ buy the hardware to do such a port. :)
<lamont> Mithrandir: he requires a _credible_ support plan. :-)
<lamont> would take a double dozen machines just to _BUILD_ the beast every 6 months, I expect. :-)
<Mithrandir> we're using it in production at the computer club at the university -- that uVAX is our primary nameserver.
<lamont> Mithrandir: you should steal azeem's 712... It'll scream!
<Mithrandir> we have a bunch of those as well.
<Mithrandir> apart from the fact that it's hell to log into, it's a nice box.
<srbaker> yo
<Mithrandir> hiya srbaker 
<srbaker> so did anyone else start looking into the ubuntu being really slow on toshiba lappies?
<Mithrandir> it's still fast on my gf's :)
<srbaker> grrr
<T-Bone> lamont: ping?
<lamont> yo
<T-Bone> lamont: good news: both sbuilds are still running
<lamont> yeah!
<T-Bone> lamont: and for zsh, my mistake: sbuild wasn't killed. Looked more or like "stuck", had to kill -9 all processes
* lamont is up to #420: totem
<lamont> ah, ok
<azeem> mrvn has reported problems with building zsh as well
<Mithrandir> T-Bone: zsh has a problem being autobuilt, we see it on amd64 as well
<T-Bone> Mithrandir: good to know. It's now in final position in my sbuild list
<azeem> T-Bone: are you are using the sbuild from db.debian.org?
<T-Bone> lamont: #350 on ia64
<T-Bone> azeem: right
<Mithrandir> T-Bone: it should build fine if you SIGCONT it.
<lamont> T-Bone: my xfree86 died (ia64 only here) for lack of disk space. :-(
<T-Bone> lamont: failed on ia64 are: cyrus-sasl2, enchant, libcaca, lsb-release, mysql-dfsg, ntp, pbuilder, perl_5.8, and syck
<lamont> and a bunch of gnome build-dep issues, I expect.
<T-Bone> lamont: lol. This shouldn't happen here (20G free)
<lamont> sasl2 will be a pain for us - what was the failure
<T-Bone> [varenet@envy ~] $ grep ^Built logs/xfree86_4.3.0.dfsg.1-6ubuntu21_20040926-1716  
<T-Bone> Built successfully
<lamont> ah, that was hppa that timed out,eh?
<T-Bone> lamont: right
<lamont> fabbione: mail logs are all happy with length now - You can quit redirecting.. :-)
<T-Bone> it's imho plain stupid to redirect all output to a file
<T-Bone> lamont: i wonder how this would do on really _slow_ archs (m68k, arm and friends)
<lamont> that was a hack for the warty buildd's of a while back.
<T-Bone> config.status: creating man/Makefile
<T-Bone> malloc: ../bash/dispose_cmd.c:230: assertion botched
<T-Bone> free: called with unallocated block argument
<T-Bone> Stopping myself..../configure: line 32173: 22342 Aborted                 $SHELL $CONFIG_STATUS $ac_config_status_args
<T-Bone> make: *** [stampdir/config-stamp]  Error 1
<T-Bone> ******************************************************************************
<T-Bone> Build finished at 20040926-0446
<T-Bone> FAILED [dpkg-buildpackage died] 
<lamont> log > 10MB --> bounce --> wait for lamont to manually fix it.
* T-Bone goes like "Ouch, really ouch man"
<lamont> t-bone: that's a bash bug
<lamont> if bash is already built, install that in the chroot
<lamont> then find all of the ones that died with that error, and retry them.
<lamont> that is, once the run finishes...
<T-Bone> it's not already built
<T-Bone> lamont: #340 on hppa
<T-Bone> 350 actually
<lamont> cool
<T-Bone> lamont: failed on hppa are: enchant, lsb-release, mozilla-thunderbird, pbuilder and xfree (because of timeout)
<azeem> heh, pbuilder detects it's being built by sbuild and cops out? *g*
<lamont> # Some packages may exceed the general timeout (e.g. redirecting output to
<lamont> # a file) and need a different timeout. Below are some examples.
<lamont> %individual_stalled_pkg_timeout = (
<lamont>         xfree86 => 600,
<lamont> };
<lamont> in .sbuildrc
<lamont> azeem: nah - pbuilder builds pbuilder_..._all.deb, but claims to be arch: any
<lamont> so it's ftbfs, but we don't care.
<T-Bone> lamont: http://gropaf.esiee.fr/~varenet/
<azeem> ugh
<lamont> azeem: yea
<azeem> using a source builder from somebody who confuses 'any' and 'all' would make me uncomfortable I guess ;(
<azeem> eh, :-/ or something like that
<T-Bone> lamont: i've put some stats, updated hourly, and access to the logs folder there. Setting up the same on envy ;)
<T-Bone> lamont: http://envy.esiee.fr/~varenet/  -- There you are. Easier than ssh ;)
<lamont> heh
<lamont> thanks
<T-Bone> if you need anything else useful there, let me know :)
<T-Bone> hmm. i'll add a reminder of the arch, too ;)
<T-Bone> lamont: fwiw, 2.4 is definitely much more stable than 2.6 on ia64
<lamont> figures
<lamont> on the bright side, warty _does_ support installing 2.4
<T-Bone> lol, that's a relief ;)
<srbaker> fuck.  i wanted to chase down the toshiba problems today, but i do'nt think i'm going to get to
* lamont spends a while, then notices that .gz != .py, sighs, bangs head on wall.
* T-Bone spreads some nails on the wall... runs away!
<srbaker> does ubuntu use gksudo where debian uses gksu?
<Mithrandir> yes
<srbaker> ahh
<srbaker> the thing i like about ubuntu is exactly what Edd said.  "ubuntu gives me a system that is exactly how i would have configured my debian system"
#ubuntu-devel 2004-10-08
<srbaker> is ubuntu in debconf high or critical?
<mdz> srbaker: critical in the installer, high in the installed system
<srbaker> cool
<tseng> hi all.
<lamont> hrm.. no jdub, eh?
<Mithrandir> mdz: can we sync gftp with debian? -6 fixes RC bug for both us and them; the fix is in incoming; our bug # is 1806
<Mithrandir> (we have -5 already)
<mdz> Mithrandir: just saw that
<mdz> yes, fine with me
<mdz> please request it
<Mithrandir> willdo
<sivang> night all
<sivang> has anyone bumped into _very__very_ slow disk performance under inspiron 8200 laptop? I recently install a daily from about 4 days ago, and it just crewles..
<sivang> Is this more appropriate at #ubuntu ? :)
* Mithrandir hopes he got the long addresses right and goes to bed.
<sivang> night Mithrandir
* lamont introduces his daughter to xlife.  this is fun.
<sivang> :
<sivang> :)
<sivang> any urgent bugs?
<lamont> justdave: happiness?
<justdave> lamont: yep
<lamont> what was it?
<justdave> I accidently nuked a paren when I added the -f
<lamont> ouch
<justdave> because my stupid terminal was sending the wrong code for backspace :)
<lamont> heh
<justdave> guess postfix isn't as picky about that stuff as sendmail (or at least not by default)
<justdave> sendmail makes you grant users permission to use -f
<lamont> fehj
<justdave> which is why I assumed I needed admin support :)
<lamont> nc localhost 25
<lamont> yeah.  then again, postfix's sendmail is mode 555
<lamont> and just writes a file into /var/spool/postfix/maildrop
<justdave> one of these days soon, bugzilla will do smtp by default anyway
<lamont> if you do, there's always sendmail -bs for those that can't run on port 25. But that's a gross hack from days gone by
<justdave> back in 30 or so
<lamont> later
<fabbione> morning guys
<daniels> fabbione: morning
<fabbione> hey dani
<fabbione> daniels: i start to be a bit worried about Dec conf.
<fabbione> jane talks about end nov. mid dic
<fabbione> mark isn't sure...
<fabbione> personally i don't mind
<jdub> oh man
<jdub> the gnome-cups-manager test pages are all line-based, not font-based
<jdub> ie. can't just s/XIMIAN DESKTOP/UBUNTU/g :)
<lamont> ew!
<lamont> jdub: btw, if you or anyone else can tell me how to preserve categories for contacts into evo2.0 and back, that'd be the last thing that's keeping me on jpilot...
<jdub> lamont: to and from palm?
<lamont> yes
<lamont> the only use I have for evo is to sync my palm. :-)
<jdub> heh
<lamont> I _like_ the MUA I use, don't want some stupid gui MUA. :-)
<jdub> lamont: so why do you sync with evolution at all?
<lamont> atm I don't/
<lamont> but if I could preserve my address book categories, then I could drop jpilot.
<lamont> the wifely one is using evo, because I didn't want to make her non-conformist...
<jdub> ok, why do you want to sync with eovlution insetad?
<jdub> oh
<lamont> she discovered this evening that if you drop 5 concurrent events into evo, it segv's trying to print it... ;)
<lamont> jdub: I'm _trying_ to be a good warthog/
<lamont> and it would be nice to share calendars in the house.
* lamont admits to some usefulness to evo.  I just don't want it for my MUA...
* lamont looks at the clock, and realizes that he has to get up in about 5.5 hours.  sigh.
<lamont> daughter wants up at 5, instead of the normal 5:30.
<lamont> I hate getting up early.
<lamont> anyway, g'night
<mdz> night
<mdz> jdub: pstoedit?
<jdub> mdz: thought about that, but doesn't convert to anything inkscape likes
<jdub> but i could screw around with xfig
<mdz> WWBJD?
<mdz> jdub: there is a pstoedit SVG output plugin
<mdz> maybe you could ask Ximian for whatever source format they have for the page
<jdub> :)
<jdub> it should probably be fixed in gnome cvs anyway
<jdub> mdz: where's the svg output plugin?
<mdz> http://www.pstoedit.net/plugins
<mdz> eww, it's a binary
<jdub> yeah
<jdub> "Unless you get a key, these drivers will slightly distort the generated output. Colors will be changed and the letter e will be replaced by $."
<mdz> oh hey
<mdz> are you sure pstoedit doesn't support svg out of the box?
<mdz> it looks like it can use the libplot svg output
<mdz> pstoedit -f plot-svg xd2-testpage-a4.eps /tmp/test.svg
<mdz> Interpreter finished. Return status 0
<jdub> mdz: it just gave me 0 length output\
<mdz> inkscape seems to like it fine
<jdub> oh, now it's working
<jdub> bong
<jdub> ugh, the output is horrible
<mdz> it's a little cracked out
<jdub> might even be worth doing our own ;)
<mdz> for some reason everything is covered by black circles
<mdz> s/circles/shapes/
<mdz> if you delete that crap, the good stuff is underneath
<mdz> maybe it's some weird printer magic
<mdz> all of the objects are there, it's just the colours that are borked
<jdub> mine are all misshapen
<mdz> inkscape crashed on me
<mdz> probably worth making our own :-)
<mdz> I liked all the little test patterns they provided though
<jdub> mmm
* jdub has found a test page generator
<jdub> will see if the output sucks or not ;)
<pitti> Hi guys!
<mdz> pitti: good morning
<pitti> mdz: Morning. Exhausting weekend...
<jdub> http://www.gnome.org/~jdub/random/ubuntu-a4.eps or http://www.gnome.org/~jdub/random/ubuntu-letter.eps
<jdub> anyone want to check those out?
<jdub> hmm
<jdub> that looks pretty good
<doko> jdub: ERROR 404: Not Found.
<jdub> that makes ithard to test
<fabbione> mdz: 1808 what do you want me to do with this one?
<fabbione> jdub: ^^
<jamesh> pitti: does this sound like it could be related to pmount? https://bugzilla.ubuntu.com/show_bug.cgi?id=1715
<jamesh> pitti: I can easily fix up my gnome-vfs patch, but I'm wondering why the problem occured just recently.
<jdub> fabbione: oh, that reminds me
<jdub> fabbione: pipka's laptop only supports the full resolution of the lcd at 16bit
<jdub> fabbione: which means the configuration fails :|
* fabbione ask again... what should I do with it?
<fabbione> defaulting to 16 bits or let 24 bits?
<fabbione> one way or another we will get bug reports
<jdub> do you mean in the general case?
<fabbione> "it doesn't work at 24 bits but only at 16"
<jdub> http://www.gnome.org/~jdub/random/ubuntu-a4.eps or http://www.gnome.org/~jdub/random/ubuntu-letter.eps
<fabbione> "GRAVE BUG: my video card supports 24 bits and you only init at 16"
<jdub> ^ try again :)
<jdub> fabbione: ;-)
<pitti> jamesh: this is indeed the same bug as #1599.
<fabbione> jdub: yes as a general case... it's either one or another
<mdz> fabbione: if there is some way to auto-detect the situation, great
<pitti> jamesh: this is not directly a pmount problem, it's a gvfs bug
<mdz> fabbione: if not, close it
<mdz> fabbione: either way, it's not important for the release (hence severity; enhancement)
<jdub> mdz: hhhrrrmmm, it ends up being important
<pitti> jamesh: seb recently uploaded a new gvfs, and my patch (which worked fine with the older one) does not play well with the new upstream version
<mdz> jdub: what does?
<pitti> jamesh: so I disabled it temporarily
<jamesh> pitti: I can probably get the computer:/// and network:/// patches to only move "connect to server" type entries.  That would solve the problem, right?
<fabbione> mdz: well there is a way, but that will require xresprobe to return me the amount of ram on the video card and according to resolution set the depth
<jdub> mdz: when the resolution chosen does not work at 24bit
<pitti> jamesh: yes, this would solve both bugs.
<fabbione> mdz: but do you feel to implement it at this point in time?
<mdz> fabbione: no, I really don't
<pitti> jamesh: if you know the guts of gvfs well enough, it would be great! 
<fabbione> mdz: i realize we did never discuss this problem before
<fabbione> mdz: so it's a point, but up to you
<jamesh> pitti: okay.  I'll put together a patch, and we can see if it solves things.
<mdz> this is only an issue with older graphics cards which do not have enough RAM, right?
<jdub> fabbione: i'd say hoary
<pitti> jamesh: I actually thought that I had to write new code to make the devices appear in Disks, but if that code already exists, so much the better
<pitti> jamesh: thanks!
<jdub> mdz: that's a lot of machines
<jdub> mdz: not just older
<jamesh> pitti: my patch moves all GnomeVFSVolumes that don't have an associated GnomeVFSDisk object to network:///
<mdz> jdub: video cards sold today have more ram than most of my computers
<pitti> jamesh: ah, maybe that was the reason why my previous patch just did not work any more
<jamesh> pitti: I'm not sure why things like the firewire and USB drives don't have a Disk object now though.
<jdub> mdz: in ricer machines, sure
<mdz> jdub: in something you buy from Dell or HP
<jamesh> pitti: s/GnomeVFSDisk/GnomeVFSDrive/
<jdub> mdz: it's a significant bug, but something that can probably wait until hoary
<pitti> jamesh: upstream version only shows Disks which have an fstab entry
<fabbione> mdz: yes
<mdz> jdub: I don't see that we can do anything intelligent in that situation; we would need to ask a question
<pitti> jamesh: my previous patch "faked" such an entry by modifying the function which read fstab; it added the user-entries of mtab
<mdz> "what's more important: colours or resolution?"
<jamesh> pitti: okay then :)
<pitti> jamesh: but with the new upstream version, it became unreliable and breaked the trash
<jdub> mdz: it's easy to determine from available video ram
<mdz> jdub: you can't determine whether the user would prefer a higher resolution with fewer colours, or a lower resolution with more colours
<mdz> that's the tradeoff, isn't it?
<jdub> not on an lcd :-)
<jdub> but it's something you can decide that they can reconfigure later
<jdub> (on a crt)
<mdz> that's what we do today :-)
<jdub> they can't, because their system doesn't work
<mdz> why not?
<mdz> can the driver not detect that the mode is no good and fall back?
<jdub> we don't do that today
<jdub> when pipka installed her machine
<jdub> it chose the right resolution for the lcd
<jdub> and the wrong colour resolution
<jdub> were she not a kung-fu master, she would not have got out alive
<mdz> ah, ok
<mdz> so the LCD was configured correctly, but the card can't drive it
<jdub> if you can determine two useful configurations from the video ram
<mdz> in the LCD case there is no tradeoff
<mdz> you just need to drop the depth
<jdub> then on a laptop you can choose the correct one for the lcd
<jdub> on a crt you can make up some reason why you'd choose one over the other
<jdub> and let the user configure it how they want later
<mdz> #1808 is a different case
<mdz> I think the emulator just sucks, but I wasn't sure
<jdub> no, same case
<jdub> it's just not hardware ;)
<mdz> oh, you have a copy of microsoft virtual PC?
<mdz> that'll come in handy for testing the fix
<jdub> i don't, but i know it emulates an s3
<jdub> i think i can get access to a copy
<mdz> I don't think the chipset is relevant
<jdub> but probably don't need it, the fix is described above :)
<jdub> the chipset isn't relevant, it's the 'hardware environment'
<mdz> the 'hardware environment' in this case seems like a buggy emulator
<mdz> which is a very differetn case from a card which is short on video ram
<mdz> the amount of video ram can generally be probed
<jdub> dude, it emulates a video card that can't do that
<jdub> nothing wrong with the emulator
<mdz> I _have_ an S3 card, and it _does_ to 24-bit colour
<mdz> s/to/do/
<doko> jdub: eps: maybe let the user know how many lines around the edges he is supposed to see?
<jdub> apart from making a bad choice of hrdware setup
<jdub> doko: hrm, that'd be a software issue ;)
<jdub> doko: just replacing the poopie eps shipped with gnome-cups-manager
<doko> jdub: no, just print it somewhere on the page, "you should see ... if not, adjust your setup, help at ..."
<mdz> fabbione: hmm, there is also a tradeoff with DRI
<mdz> my mga card can only run 1600x1200 with DRI disabled due to lack of RAM
<fabbione> mdz: ok.. should we default to 16 bits?
<mdz> fabbione: hell no :-)
<mdz> fabbione: just another thing to think about when we decide to look at this issue in the future
<fabbione> mdz: we need to rewrite all the autodetection code anyway
<fabbione> and do a hell of a lot of a cleanup
<daniels> s3s do do 24-bit, yes
<jdub> http://www.robertmoir.co.uk/win/vpcfaq/VPCFAQ7-KnownIssueswithVP.html#7.3
<jdub> http://vpc.visualwin.com/
<jdub> ^ mentions ubuntu ;)
<mdz> hah, nice
<mdz> Colin Barnhorst seems to have tried many different operating systems
<mdz> hah, even knoppixmyth is on there
<jdub> sick puppy ;)
<doko> but "does it worK? no"
<mdz> hah, that page describes linux boot parameters as "cheat codes"
<jdub> up-up-up-b-b-a-start-down-- WOOHOO! KERNEL 2.6!!!!
<mdz> ^^vv<><>ABAB START
<doko> try to submit an entry for "Small Ubuntu Server", maybe it shows up in the front then ;)
* mdz blinks at the PregnantPanda proposed release name
<jdub> let's choose that name for the next release which requires new glibc, new gcc, new kernel, new X and new just about everything else
<daniels> mdz: i like PokeyPenguin
<doko> that's Hoary, or Hoary+1 ?
<daniels> hoary+2 is meant to be PerkyPenguin
<jdub> ok bong-sippers
<jdub> what do you think about those printer pages
<jdub> ?
<jdub> otherwise i'm just going to upload the suckers
<daniels> ubuntu.
<mdz> where are the printer pages?
<mdz> ah, missed the 'try again'
<jdub> http://www.gnome.org/~jdub/random/ubuntu-a4.eps or http://www.gnome.org/~jdub/random/ubuntu-letter.eps
<mdz> jdub: definitely fixes the bug :-)
<jdub> heh
<jdub> you like?
<mdz> fabbione: any idea about  1724?
<jamesh> pitti: I just bugzilla'd the new gnome-vfs patch.
<mdz> jdub: I think it would be nice to have some test patterns and stuff, but for Warty purposes, what you have is more than sufficient
<jdub> patterns rather than colours?
<pitti> jamesh: thanks! Does it work now?
<pitti> jamesh: I will take a look at it (out of curiosity :-) )
<mdz> jdub: text in a few different fonts, stipple pattern, parallel lines, etc.
<jdub> mmm
<jamesh> pitti: it doesn't cause any problems here, and the patch to computer-method.c is a lot simpler
<jamesh> pitti: which means that it should behave more like upstream
<mdz> jdub: I say ship it
<jdub> SHIP IT!
<jamesh> pitti: I've only got a limited number of volume types to test on this box, which is why I'd like to know if it works well in other situations.
<pitti> jamesh: still quite a big patch, but it looks as if it _could_ go upstream...
<pitti> jamesh: I think there's only one possibility to find that out :-))
<jamesh> pitti: it is a replacement for a patch we already have in gnome-vfs, and it is a bit smaller than the one it replaces.
<jamesh> pitti: the diffs between the two patches are quite small.
<pitti> jamesh: shall I build and test the package before you ask mdz to approve it?
<jamesh> pitti: that would be useful, yes.
<pitti> jamesh: do you already have a i386 deb somewhere?
<jamesh> no.
<pitti> jamesh: okay, I build it myself.
<jamesh> this version of the patch could probably be sent upstream (the last version wasn't as clean)
<pitti> Morning seb128!
<seb128> morning
<jdub> yo seb128 
<seb128> grrr, 30 hours to fix the dsl connection, apparently dsl people don't work sunday
<jdub> seb128: got my mail?
<jdub> ouch
<seb128> just back from 30 hours internet-less
<seb128> my fetchmail/spamassassin/... is working :)
<pitti> jamesh: patch works fine for me
<jamesh> pitti: great.
<pitti> jamesh: this bug report was great; so far I thought that the new device would not appear in Nautilus at all
<pitti> jamesh: I would have never come to the idea to look in "Network" for it :-)
<seb128_> funny, I'm getting 2 weeks old mails for 3 days (WTF with my @debian)
<pitti> jdub: the new hal 0.2.98 does not work with the current g-v-m, so I need to upload a new gvm
<pitti> jdub: there is a new upstream version 1.0.2 of g-v-m which just adds some new translations
<jdub> :)
<trukulo> seb128_: read planet.debian.net, there was a problem with mail server
<pitti> jdub: may I upgrade g-v-m- while I'm at it?
<jdub> pitti: yes thanks
<jdub> http://www.extremetech.com/article2/0,1558,1651228,00.asp
<jdub> ^ (p)review
<pitti> seb128: the nautilus-cd-burner in warty does not yet use the new locking mechanism of hal to prevent further mounts; is this already upstream?
<seb128> yes it's upstream
<seb128> but need hal >= 0.2.98
<seb128> so it's not buildable for the moment
<pitti> seb128: I just packaged crack-of-the day hal/dbus/gvm
<pitti> seb128: now I test CD burning
<seb128> ok
<seb128> cool
<pitti> seb128: I cannot find any trace of lockign in the n-c-b sources
<seb128> it's in 2.8.3
<pitti> seb128: ah, so I'm going to package this as well
<pitti> seb128: unless you want to do that...
<seb128> pitti: that's just a matter of dch -i, New upstream release and update the hal depends
<seb128> pitti: so as you want :)
<pitti> seb128: okay, since the other stuff is at my hd and not uploaded yet, I would do it
<seb128> ok, thanks
<pitti> seb128: so the guys can test the complete new stack from my archive without having it to upload first
<seb128> yeah
<fabbione> jdub:
<fabbione> xfree86 (4.3.0.dfsg.1-6ubuntu22) warty; urgency=low
<fabbione>   * Update 000_stolen_from_HEAD.diff:
<fabbione>     + Include Xv/framebuffer fix for xf86xv.c.
<fabbione>   * Update 030_Xserver_and_driver_region_primitive_fixups.diff:
<fabbione>     + Fix REGION_EQUAL call in nv_driver.c.
<fabbione>   * Update Czech debconf template translations (thanks, Miroslav Kure).
<fabbione>   * Apply fix for Keycodes for PrintScreen and SysRq. (Closes: #1762)
<fabbione>  -- Fabio M. Di Nitto <fabbione@fabbione.net>  Mon, 27 Sep 2004 07:58:55 +0200
<pitti> seb128: http://ftp.gnome.org/pub/GNOME/desktop/2.8/2.8.0/sources/ just has n-c-b 2.8.0
<pitti> seb128: where do you pull new sources from?
<pitti> seb128: ah found it
<pitti> seb128: sorry for disturbing
<seb128> np
<seb128> jdub: ok, changes done for the -fr list
<pitti> seb128: hmm, ncb 2.8.3 still does not attempt to umount the CD-RW
<pitti> seb128: how easy is it to add an _extra_ unmount option to the context menu? (By now you just have eject)
<seb128> no idea
<seb128> should ask jamesh about this, he had a look on that
<jamesh> seb128: I haven't looked at the exact nautilus code, but I could.
<seb128> ok
<pitti> jamesh,seb128: I think I can add the unmounting to n-c-b
<seb128> jamesh: have you replied to my question about pygtk/gnome the other day ?
<pitti> jamesh,seb128: but having a separate unmount option for CDs is a good idea nevertheless
<seb128> pitti: why do you want to umount in n-c-b ?
<pitti> seb128: by now you insert an RW, it is mounted automatically; if you want to burn on it, it is busy
<pitti> seb128: however, there is no possibility to unmount it, it is ejected
<seb128> you want to add an umount "option" ?
<pitti> seb128: so we could pumount -l the device before burning
<seb128> yes, but not an option
<seb128> just umount it 
<pitti> seb128: okay, then without -l
<pitti> seb128: by now, there is just a "TODO: unmount the device..." in the ncb code
<seb128> I can ping an upstream about this
<pitti> seb128: maybe a good idea; I don't know much about the code
<pitti> seb128: I can add the umount there and try if it works
<seb128> ok
<jamesh> seb128: I talked a bit with jdahlin about it.  The fix is probably the right thing for Python < 2.3.5
<jamesh> pitti: btw, the code for handling unmount/eject context menu item is in real_update_menus_volumes() in src/file-manager/fm-directory-view.c
<jamesh> pitti: it seems to use the same verb for both eject and unmount
<pitti> jamesh: so the decision is taken at a lower level?
<pitti> jamesh: that would mean it is nontrivial to add, isn't it?
<jamesh> pitti: the decision between eject and unmount is in the eject_for_type() function
<jamesh> pitti: which is set to show an eject option for cdroms, zip and jaz drives, and unmount for others
<pitti> jamesh: I saw this once; it does not seem to be designed for just unmounting
<pitti> jamesh: well, if its nontrivial to change and cd-burner supports automatic unmounting, it's not such a big deal, I suppose
<jamesh> pitti: unmount_volume_callback() uses the result of eject_for_type() to decide whether to eject or unmount
<jamesh> pitti: and the code for setting up the context menu uses eject_for_type() to decide whether to call the item eject or unmount.
<jamesh> it isn't a case of showing one item and hiding the other
<pitti> jamesh: ugly...
<pitti> jamesh: at least for having two commmands...
<jamesh> it is just a single menu item with a different label depending on the drive type.
<jamesh> pitti: well, other than the case you mentioned, when is a user going to want to unmount a cdrom or zip disk?
<jamesh> pitti: the correct fix would be to get n-c-b to do the unmount
<pitti> jamesh: I would do it if I wanted to repartition my USB stick, ZIP drive or whatever
<pitti> jamesh: but if I want to do that, I can as well type umount by hand
<pitti> jamesh: I want to fix n-c-b anyway
<jamesh> pitti: actually, you probably couldn't umount by hand ...
<jamesh> if the stick has a trash dir
<pitti> jamesh: these device locks, I suppose
<pitti> jamesh: but that shouln't happen on CD-ROMs, no?
<pitti> jamesh: seb128 suggested not to lazily unmount the CD, but do that normally
<jamesh> pitti: the Gnome vfs umount/eject stuff has a "pre unmount" signal so that apps like nautilus can stop monitoring directories
<jamesh> since fam/gamin's dnotify watches hold the device open
<pitti> jamesh: hmm, so actually n-c-b should call this instead of umounting directly?
<Sledge> morning...
<pitti> morning Sledge
<jamesh> pitti: yep.  Get the GnomeVFSVolume or GnomeVFSDrive object for the cd drive and call its unmount() method.
<pitti> jamesh: any idea how I can do that in n-c-b? I only have the device string (/dev/hdc or so)
<jamesh> pitti: gnome_vfs_volume_monitor_get_volume_for_path() might do it.
<pitti> jamesh: do I have to call the pre_umount method myself or does GnomeVFSVolume's umount() method care for that?
<jamesh> pitti: the gnome_vfs_volume_unmount() routine handles it all for you.
<pitti> jamesh: thanks a lot for your help!
<jamesh> pitti: if inotify existed a few years back, things wouldn't be so complicated ...
<seb128> does somebody already had problems to boot the warty iso on a powerbook ?
<thom> seb128: define problems
<seb128> the powerbook doesn't boot on the CD
<seb128> it doesn't see it as a bootable one or something like that
<thom> seb128: hold 'c' as you power on
<seb128> ok, not for me, I'm telling that to the guy ;)
<seb128> thanks
<thom> sure
<seb128> and for shared-mime-info, yes it was 0.15 :)
<thom> right, well, that bug is still occurring then :-/
<seb128> thom: 'c' doesn't work, the guy says it already does that
<seb128> debian CDs boot ok
<seb128> warty doesn't boot
<seb128> s/it/he/
<jamesh> seb128: btw, I did a patch for bug 1715 (firewire volume showing up under Network)
<seb128> cool, thanks
<jamesh> seb128: pitti tested it, and it fixes 1599 too
<seb128> ok, I'll do an upload soon
<seb128> thanks
<fabbione> jdub, mdz: ping
<Kamion> seb128: I'd check that it burnt correctly; the CD build processes for Debian and Ubuntu are practically the same
<seb128> the guy has burnt several time the debian and the ubuntu iso, the Debian always boot, the Ubuntu one not ... weird
<Kamion> very odd
<Kamion> is he certain that he downloaded the Ubuntu ISO correctly?
<seb128> yes
<Kamion> rsync shows no changes?
<Mithrandir> make sure to run rsync with -c
<seb128> I'm checking, but I think he downloaded the preview and one daily, and he can mount them without any problem
<seb128> he deleted the iso and is downloading it again ...
<Kamion> the preview has certainly booted on lots of machines
<pitti> jamesh: still here?
<jamesh> pitti: yep.
<pitti> jamesh:  gnome_vfs_volume_monitor_get_volume_for_path delivers a VFSVolume* with device path 'none' and umounting does not work
<pitti> jamesh: do I need to initialize the monitor somehow?
<pitti> jamesh: by now I just create an instance with GnomeVFSVolumeMonitor* gvm = gnome_vfs_get_volume_monitor()
<pitti> jamesh: sorry for askign so much, but this stuff is not documented yet
<jamesh> pitti: hmm.  I'm a bit new to the APIs myself.
<pitti> jamesh: do you know what these _ref and _unref methods are for?
<pitti> jamesh: maybe I need to call them
<jamesh> pitti: imaybe gnome_vfs_volume_monitor_get_volume_for_path() expects a path on the mounted volume
<pitti> jamesh: argh; maybe. By now I give it the device node path
<pitti> jamesh: I don't have the mount path in n-c-b...
<jamesh> pitti: the other thing to try would be to use gnome_vfs_volume_monitor_get_mounted_volumes() to get the list of mounted volumes, and gnome_vfs_volume_get_device_path() to find the device path for each mounted volume
<jamesh> find the volume that matches the device file name.
<pitti> jamesh: sounds possible (although pretty much code for such a simple thing :-) )
<jamesh> pitti: maybe that's why n-c-b doesn't currently do it :(
<pitti> jamesh: :-) So, off to doing it
<jamesh> pitti: of course, the unmount may still fail if other apps have files open ...
<pitti> jamesh: but I think this is reasonable in this case
<jamesh> pitti: but it will get nautilus to stop holding the volume open
<pitti> jamesh: ncb will show a dialog "drive busy", then the user can close the app and click "OK" to try again
* jamesh should get a cd burner to try these sorts of things out ...
<fabbione> seb128: 1762: who the screenshot stuff is supposed to work?
<fabbione> if i press print or alt+print, where is the screeshot saved?
<seb128> fabbione: desktop or home, not sure
<seb128> let me check
<seb128> fabbione: it should open the screenshot dialog (same as in the computer menu)
<jamesh> there's a Sun guy working on adding printing support to the screenshooter dialog ...
<fabbione> seb128: ok thanks. than the fix doesn't work
<fabbione> seb128: does it need anything special installed? like gnome-foo-bar?
<seb128> gnome-panel
<seb128> that's all
<seb128> it runs gnome-panel-screenshot
<ross> fabbione: pressing print or alt-print generally doesn't work in debian's X
<fabbione> ross: that's what i am trying to understand
<fabbione> ross: there is a patch missing
<ross> i've seen a patch to fix it
<seb128> ross: that's the purpose of the bug report yes
<ross> aaah i see
<fabbione> ross: yes but the patch doesn't fix apparently
* ross reads back
<ross> :)
<seb128> ross: http://bugzilla.ubuntu.com/show_bug.cgi?id=1762
<fabbione> xc/programs/Xserver/hw/xfree86/common/xf86Events.c @ 3.147
<fabbione>    8. Fix for non-PC keyboard bug introduced by changes to make SysRq
<fabbione>       generate the same keycode as PrtScrn (Ivan Pascal).
<fabbione> HMM
<mjg59> Is there any reason we don't modprobe apm on boot by default?
<Mithrandir> it would seriously suck for my laptop, for instance.
<mjg59> It won't do anything if acpi is already running
<Mithrandir> we should make sure acpi is loaded first, then.
<Kamion> Mithrandir: the initrd already loads thermal/fan
<Kamion> that should be enough, shouldn't it?
<mjg59> acpi is built into the kernel
<mjg59> Kamion: Does that happen in Debian, too?
<Mithrandir> Kamion: if you load apm on my system the modifier keys behave really badly, they get sticky.
<ross> pitti: i've forgotten pmount policy again -- would an external firewire hdd be mounted without a line in fstab?
<pitti> ross: Should work, yes
<ross> hm, it isn't
<mjg59> Mithrandir: Really, apm won't do anything unless acpi is either implicitly or explicitly disabled
<pitti> ross: does it appear in Device Manager=
<mjg59> There's no way to build modular acpi
<pitti> ross: s/=/?/
<ross> urgh.  hald has hung in scsi_wait_req and is dead
<Kamion> mjg59: in d-i, yes; in the installed system, no
<Kamion> mjg59: (unless it was done somewhere different from where I was expecting)
<pitti> ross: can you kill it and try again?
<ross> nope, its totally dead
<mjg59> Kamion: Bleah. We /still/ need to fix that. It does kill hardware.
<pitti> ross: I packaged a newer hal, maybe it fixed the crash...
<fabbione> it looks to me that code is not even reached
<fabbione> either with the xfree86 patch or the x.org one
<lamont> moof
<Mithrandir> moof, lamont
<fabbione> hey lamont 
<daniels> fabbione: which code, the radeon suspend shit, or the xkb stuff?
<fabbione> daniels: print and <alt>+print
<daniels> ahr
<fabbione> we have both the fixed from xfree86 and x.org but alt+print still = SysRq
<daniels> crap
<fabbione> it gives me the feeling that the part of the code is not used at all
<fabbione> let me try a gdb sessions
<fabbione> where for SURE it will work
<fabbione> therefor making the problem untraceable
<ross> hm, why is my numeric keypad not working at all
<ross> gar
<ross> how am i supposed to shoot people over lunch if my numeric keypad doesn't work
<ross> works at the console but not in X
<fabbione> seb128: 1762 it's a gnome problem :-)))))
<fabbione> seb128: i just finished a gdb session on X and the keyboard mapping is working fine
<fabbione> seb128: meaning that something else (!=xfree86) is mangling the keyboard
<fabbione> and you know what is the best part...????
<seb128> ok
<fabbione> I CAN PROVE IT :P
<ross> fabbione: any idea why in X my numeric keypad wouldn't work at all?
<fabbione> (gdb) n
<fabbione> 579       if (scanCode == KEY_SysReqest)
<fabbione> (gdb) n
<fabbione> 580         scanCode = KEY_Print;
<fabbione> this is the patch to xEvents 
<fabbione> it maps the SysReq to Key_Print and that works
<fabbione> (already the fact that is called means that it works)
<seb128> fabbione: could you provide the evidences in http://bugzilla.gnome.org/show_bug.cgi?id=86506 ? :)
<fabbione> seb128: do i need an account to write there?
<seb128> probably yes
<fabbione> seb128: humpf
<fabbione> :(((
<seb128> just reassign 1762 to me with details
<seb128> I'll follow upstream
<fabbione> ross: no.. keyboard? model? layout? laptop? desktop?
<ross> fabbione: standard UK keyboard, pc105, desktop
<ross> ah.  when i press the arrow keys xev reports motionevents
<fabbione> ross: "Num lock"???
<ross> moves the mouse cursor when its on and off
* ross wonders what catches numpad events and turns them into mouse events
<ross> aha
<ross> i pressed shift-alt-numlock
<ross> obviously
<fabbione> WTF
* fabbione kicks crapzilla
* lamont takes the car to the shop, where he will work on his laptop for a while.  back in a few hours.
* fabbione files a blocking bug on bugzilla for bugzilla
<fabbione> IT
<fabbione> IT'S UNUSEABLE
<seb128> thom: 1221, the return mime for gnomevfs-info is still the same ?
<thom> seb128: MIME type         : application/x-cd-image
<jdub> Kamion: ping
<thom> i think fedora's bugzilla css is about as good as it gets
<jdub> thom: aye.
<jdub> ours is pants.
<jdub> it makes me cry
<jdub> so does planet.u.o
<seb128> thom: could you try to patch with GNOME_VFS_FILE_INFO_FORCE_FAST_MIME_TYPE instead of SLOW and try again with gnomevfs-info ?
<fabbione> jdub: permission to upload 1821
* jdub attempts to say he's not at work.
<jdub> fabbione: approved in comments
<fabbione> ok
<thom> seb128: i'll give it a try in a bit, sure
<seb128> thom: thanks
<thom> jdub: OH MY EYES
<thom> (i just looked at planet)
<jdub> uh huh
<ross> ARRRG
<jdub> thom: seen our website recently?
* thom drums fingers and waits for 400GB of sata love to arrive
<thom> jdub: planetplanet?
<jdub> www.u.org
<ross> huh? a book shop?
<jdub> ross: ubuntulinux
<Kamion> jdub: pong
<thom> jdub: 1787, please confirm ;-)
<jdub> Kamion: how was oldentown? gothamburg? whereveryouwent? ;)
<azeem> oldenburg
<azeem> burg == castle, roughly
* jdub spanks azeem 
<Kamion> jdub: went well, got lots done, didn't *quite* get the graphical installer booting because mklibs hates me, otherwise good
<jdub> Kamion: so there was some discussion a while back about switching off the hidden-menu grub setting if other OSes were detected... did that come to anything?
<jdub> Kamion: noice.
<Kamion> jdub: I think it came to "good idea, put on Colin's to-do list"
<jdub> ahr
<Kamion> (which is fine by me, will do it ...)
<jdub> Kamion: did it have a milestone attached?
* jdub buzzes off again :)
<Kamion> jdub: not sure it had a bug attached, even ...
<Kamion> PS several uploads waiting for approval
<mjg59> Kamion: What's the graphical installer based on at the moment?
<Kamion> mjg59: gtk
<Kamion> (er, not quite sure what you mean)
<mjg59> Just using the gtk debconf front-end, or something nicer?
<mjg59> And is this framebuffer or X?
<Kamion> just cdebconf-gtk for now, will have more bolted onto it
<Kamion> framebuffer
<Kamion> running AWAY from X
<mjg59> Hrm. Has anyone ported atk to the framebuffer?
<mjg59> It's quite X specific at the moment
<mjg59> It'd be nice to get the accessibility support for free
<Kamion> atk? the accessibility library?
<Kamion> dunno
<mjg59> Yeah
<mjg59> What's the main problem with X?
<Kamion> big pile more complexity that we don't need?
<Kamion> plus size; even with gdk-directfb we're going to be hitting initrd size limits on many systems unless we're very careful
<Kamion> powermac netboot already has no chance
<mjg59> Ah, ok - I'd assumed you'd be using a filesystem mounted off the media for graphical install
<mjg59> My (not very strongly founded) recollection is that RH doesn't do graphical installs when netbooted
<Kamion> we don't get to mount the installation media until after cdebconf has already displayed some questions
<jdub> night all
<Kamion> www.directfb.org is probably the place to look for any accessibility stuff
<Kamion> there is XDirectFB, but I suspect daniels will consider it BONG; dunno
<mjg59> Looks like there's no support at the moment
<mjg59> That's a shame - an accessible installer would rock
<Kamion> in theory we could restart cdebconf with a different frontend, but it's not going to be trivial ...
<Kamion> has anyone tried to get the directfb frontend merged into gdk proper, I wonder?
<jdub> mjg59: i'm going to do an accessible derivative
<mjg59> jdub: Rock
<azeem> did you consider using plain GTK for the first stage, and just map the user directions to the debconf-database?
<jdub> mjg59: there's a lot of bong requirements that sighted people will just baulk at
<Kamion> azeem: what do you mean?
<mjg59> jdub: Oh, most of your posts to ubuntu@ seem to appear twice
<jdub> mjg59: i have a local testing team too ;)
<jdub> mjg59: some; evo bug. :|
<jdub> anyway
<jdub> good night
<azeem> Kamion: IMHO debconf-gtk looks pretty different from usual GNOME applications, so it might be more work to get it look right than just do it natively
<azeem> haven't looked at it, of course
<Kamion> azeem: that would really, really suck
<azeem> heh :)
<Kamion> azeem: you're talking about writing a new installer, not porting the existing one.
<Kamion> azeem: we need to use cdebconf, otherwise it is not maintainable
<Kamion> azeem: also, nobody's even touched the cdebconf gtk frontend since March (and not seriously for much longer, I think), so it's not surprising that it's raw
<Kamion> I did some work a few days ago to start cleaning it up, but it'll take a while
<azeem> well, I meant just redoing the UI dialogs and using cdebconf to set the values, based on what the user does
<Kamion> azeem: we have some glade-related plans that will have that kind of effect, but it's not that simple
<azeem> yeah, I guess
<Kamion> azeem: there is a lot of code in the installer that does things like setting the range of values presented to the user based on the answers to previous questions in the same udeb
<pitti> jamesh: can I please ask you for help again?
<Kamion> azeem: if we bypass and duplicate that code, the result won't be maintainable, so we need to come up with a way to keep it (db_callback or similar)
<pitti> jamesh: on www.piware.de/gvfs-unmount.c I put a version of my unmounting procedure
<azeem> true
<Kamion> (I suggested db_callback to joeyh on Saturday and he shuddered ... :-))
<azeem> :)
<pitti> Anybody here who knows about gnome-vfs programming?
* pitti bites in his table
<Kamion> anyone know of anybody selling boxes with Ubuntu preinstalled yet?
<pitti> seb128: have you ever programmed some stuff with gnome-vfs2? Do you know how to correctly unmount a device?
<seb128> yes and no
<pitti> seb128: My function for unmounting the cd in the gvfs way worked after ten minutes
<pitti> seb128: but it makes n-c-b crash when it starts to burn
<seb128> utch
<pitti> seb128: so I assume I have to free some resource or whatever to make it wok
<pitti> work
<pitti> seb128: www.piware.de/gvfs-unmount.c shows my current version
<pitti> seb128: do you think it will hurt much if I just call "pumount /dev/whatever" instead of going through the gvfs calls?
<pitti> seb128: respective pumount -l
<seb128> do whatever you feel right
<pitti> okay
<seb128> I've > 100 bugs in my list now, I don't really have time to look on this
<seb128> sorry
<pitti> seb128: np, just asked
<pitti> seb128: I don't know much about this gvfs stuff...
<seb128> where are you testing this function ?
<pitti> seb128: it's not documented at all
<seb128> I know ...
<pitti> seb128: where? on my pc?
<seb128> in nautilus
<seb128> or as a standalone soft ?
<pitti> seb128: I call n-c-b /path/to/image
<seb128> ok
<seb128> speaking with a gnome-vfs guy, he says that you should start to test it out of nautilus-cd-burner
<pitti> seb128: I think I have found my error
<seb128> oh ?
<pitti> seb128: can you tell me which function to call when I'm waiting for something?
<pitti> seb128: while(...) sleep(1) is not good since it does not process callback functions
<pitti> seb128: is there something like a gnome_sleep_but_process_events()?
<seb128> you can use g_idle_add ()
<pitti> seb128: I call gnome_vfs_drive_unmount with a callback and must wait for the callback to be called
<ross> while (gtk_events_pending ()) gtk_main_iteration ();
<ross> might do what you want
<seb128> yes, but that's ugly, isn't it ?
<ross> depends what you want to do
<seb128> you should use async stuff in nautilus
<pitti> seb128: actually I want to unmount the CD synchronously
<pitti> seb128: that's why I have to wait for the callback to happen
<ross> you can probably block on a signal arriving
<thom> seb128: yeah, still no change with FAST
<seb128> same mime in gnomevfs-info ?
<thom> yep
<seb128> ok, thanks
<pitti> l
<thom> gar. does cdbs really annoy anyone else? :(
<Kamion> thom: yep
<daniels> thom: it's not that bad
<daniels> i use it for all my xlibs packages, and it's used in dbus
<daniels> what's wrong with it?
<daniels> (then again, I have been known to like dbs)
<thom> it just feels totally over engineered, and makes it far too hard to work out what's going on under the hood
<thom> Kamion: oh good :-)
<daniels> thom: how come acpi-support doesn't use dbs?
<seb128> thom: bah, cdbs is cooool :)
<thom> daniels: shuttit,foo
<thom> seb128: you're french, though. i've seen french attempts at cool before ;-)
<Kamion> cdbs is yet another of those things that the maintainers of packages who uses it love, and anybody else who tries to understand what's going on in those packages hates
* seb128 slaps thom
<Kamion> s/uses/use/ # I knew the grammar seemed funny when I wrote that
<seb128> Kamion: you don't have to understand what's going on, the debian/rules has 3 lines most of the time
<Kamion> seb128: oh yes I do
<Kamion> when something breaks, as it does
<Kamion> or when I want to change something
<Kamion> I'm very very scared of any piece of software where somebody says "you don't have to understand what's going on" :-)
<seb128> yes, cdbs is missing some documentation on the internals
<seb128> yeah, but we use it for almost all the GNOME packages
<Kamion> because it usually means that when I need to understand it I won't be able to
<seb128> and no problem at all
<Kamion> GNOME has a sane upstream, that's different ...
<seb128> true
* Kamion wonders how to test this debconf change
<Kamion> I guess I can hack the new package into my local Ubuntu archive and debootstrap
<pitti> l
<pitti> sorry, wrong window...
<pitti> mdz: already awake?
<npmccallum> Kamion: can I get approval for 1516?
<mdz> pitti: awake
<pitti> mdz: Good morning!
<pitti> mdz: The new utopia stack is ready
<mdz> pitti: do you have i386 debs I can try?
<pitti> mdz: but instead of typing it into IRC, I'm just writing an announcement to u-devel; might be better to test this on a broader basis
<pitti> mdz: http://people.no-name-yet.com/~pitti/utopia/  (aptable)
<pitti> mdz: The announcement will be on the list in a few minutes
<mdz> ok
<pitti> mdz: its now on the list
<npmccallum> pitti: I did a dist-upgrade with your site in sources.list, it only upgraded dbus: no hal, etc
<pitti> npmccallum: that's odd, let me look...
<pitti> npmccallum: speling error :-) Packges.gt
<pitti> npmccallum: can you please try it again=
<pitti> npmccallum: s/=/?/
<npmccallum> nope, not yet
<Kamion> npmccallum: whoops, forgot about that. comment added. I want to look at that debconf encoding stuff before we blindly work around whatever the problem is.
<npmccallum> pitti: I mean, I tried again, but its still not working
<pitti> npmccallum: odd, http://people.no-name-yet.com/~pitti/utopia/Packages.gz now exists and shows all packages
<pitti> npmccallum: did you apt-get update'd again?
<npmccallum> yes
<Kamion> npmccallum: (because it might indicate some problem in debconf's internationalization support, and if it does then we *must* fix that)
<npmccallum> ok, I removed it from sources.list, readded it, re apt-get updated, and its working now
<npmccallum> but it wants to remove GVM!?
<pitti> npmccallum: the new hal conflicts to the older gvm
<pitti> npmccallum: you have to upgrade gvm, too
<pitti> npmccallum: can't apt work this out automatically?
<npmccallum> but its not upgrading it
<npmccallum> pitti: it should, but its not
<npmccallum> pitti: you have no GVM package in your ~pitti/utopia directory
<pitti> npmccallum: bad. In fact the Conflicts: even existed before, I just bumped the version
<pitti> npmccallum: good point
<pitti> npmccallum: sorry, I upload it
<pitti> npmccallum: uploaded
<pitti> npmccallum: does it work now?
* pitti is still not used to the fact that ^W does _not_ delete the line in xchat  :-(
<Mithrandir> heh
<Mithrandir> C-u does that
<pitti> Mithrandir: tell that to a seasoned vim user :-)
<npmccallum> pitti: everything is working well here, though I haven't done extensive testing
<pitti> npmccallum: so apt-upgrading now works? Without any dpkg questions?
* pitti is relieved
<fabbione> YES
<fabbione> YES
<fabbione> YES!
<fabbione> mdz: permission to upload X ubuntu22
<npmccallum> pitti: yes, everything now works
<fabbione> Xv extensions are working now
<fabbione> confirmed by the testers
<npmccallum> pitti: the new version even picks up my usb key :)
<npmccallum> pitti: the old hal didn't :)
<pitti> Mithrandir: not for me, BTW. ^U does nothing
<mdz> fabbione: nice catch :-)
<pitti> npmccallum: has it partitions?
<mdz> fabbione: any other changes?
<fabbione> mdz: ps i will upload tomorrow morning
<npmccallum> pitti: yes
<pitti> npmccallum: huh, what did hal-device-manager say to it?
<pitti> npmccallum: anyway, great if it works now
<fabbione> mdz: xfree86 (4.3.0.dfsg.1-6ubuntu22) warty; urgency=low
<fabbione>   * Update 000_stolen_from_HEAD.diff:
<fabbione>     + Include Xv/framebuffer fix for xf86xv.c.
<fabbione>   * Update 030_Xserver_and_driver_region_primitive_fixups.diff:
<fabbione>     + Fix REGION_EQUAL call in nv_driver.c.
<fabbione>   * Update Czech debconf template translations (thanks, Miroslav Kure).
<fabbione>   * Apply fix for Keycodes for PrintScreen and SysRq. (Closes: #1762)
<fabbione> mdz: the first 2 are for the Xv extensions
<mdz> fabbione: right, looks good, OK to upload
<fabbione> mdz: third one.. you guess it
* pitti goes to find sth to eat
<fabbione> mdz: hold on.. the latter.. please read what i wrote on the bug
<mdz> fabbione: I remember the bug
<fabbione> mdz: i added info
<fabbione> mdz: with gdb info
<fabbione> mdz: i applyed the patch from X.org but the problem is not in X
<mdz> fabbione: so there is more than one bug, one of them not in X?  or there is no bug in X (in that case, what does the patch do)?
<fabbione> mdz: the patch remaps SysRq (<alt>+print) to print
<fabbione> mdz: it is applied in 2 points of the code
<fabbione> mdz: but apparently applications still do not understand it
<mdz> why should SysRq be remapped to print?
<fabbione> mdz: the gdb session shows it clearly
<mdz> I thought PrintScrn was the key to take a screenshot
<fabbione> mdz: yes.. on i386 they are the same key
<fabbione> mdz: that's correct
<mdz> so print screen should -> Print and alt+print screen should -> SysRq
<mdz> or is there no keysym for sysrq?
<fabbione> mdz: that's what is actually happening
<fabbione> apparently SysRq is used for screenshot of a window
<fabbione> while print is for the entire screen
<mdz> ahh, ok
<fabbione> in both cases gnome fails to detected it
<fabbione> so they bounced the crap down to xfree86
<fabbione> xfree86 now has this lame remapping all over
<fabbione> but applications still fail to get it
<fabbione> anyway
<fabbione> i am off for today
<fabbione> mdz: someone needs to update linux-restricted
<fabbione> with the latest kernel
<mdz> ok
<mdz> good night
<fabbione> cya tomorrow
<mdz> I don't see why X needs to remap that stuff, but if you think it is correct to include that patch, it's OK with me
<fabbione> goody
<fabbione> i will upload tomorrow
<elmo_> Kamion: ?
<Kamion> elmo_: yep?
<elmo_> kamion: linux-image bumped soname (or whatever) - can you let me know when I can remove the old ones?
<elmo_> (no rush)
<Kamion> npmccallum: the new default bash colours are really foul; when you pop up a terminal you get bright green on white for the username/hostname, which is bordering on painful to read
<Kamion> can we have some slightly more background-neutral ones?
<npmccallum> Kamion: I'm not sure what you mean -- There are no colors on by default
<Kamion> npmccallum: I just installed from a daily build and got these
<Kamion> (amd64, but I'm sure it doesn't matter)
<npmccallum> Kamion: it wasn't my doing then
<Kamion> npmccallum: ah, maybe doko's changes
<Kamion> I thought he talked to you about those
<Kamion> elmo_: ok, will do, need to rev linux-kernel-di-*
<npmccallum> He mentioned that he found a typo (rogue colon)
<npmccallum> but that was it
<npmccallum> maybe he did some other stuff too, I have no idea
<Kamion> npmccallum: 1164     Sep 25 Matthias Klose  (  50) Accepted bash 2.05b-2-15ubuntu4 (source)
<Kamion> nevertheless, perhaps colours which look somewhat better with our default terminal would be a good idea
<npmccallum> Kamion: I turned on colors for the terminal a while ago and almost got shot :)
<Kamion> yeah, I don't think colours-by-default is going to be too popular :)
<npmccallum> its not with people coming from the debian world, but it is with people coming from gentoo and the like
<Kamion> do they really like eye-bleedingly painful colours? :-)
<npmccallum> the colors that I originally put in are from Gentoo, though I don't know if they have been changed or not
<Kamion> (I wouldn't be too upset with darker ones)
<npmccallum> bright green looks good with a black background
<Kamion> perhaps Gentoo's terminal has a black background by default
<npmccallum> it does
<npmccallum> well, not the gnome one
<Kamion> of course, I switch the terminal to a black background first chance I get, but ...
<npmccallum> me too :)
* Kamion wonders if there's a way to pick a readable colour based on the background colour
<npmccallum> there isn't
<npmccallum> its all ansi escape codes
<Kamion> didn't think so - oh well
<Kamion> well, you can retrieve the background colour using ANSI escape codes
<Kamion> it's just painful
<mdz> elmo_: speaking of the kernel, there should be more NEW enjoyment for linux-meta now, and linux-restricted-modules shortly
<mdz> I'm not sure that linux-meta is quite right yet
<npmccallum> Kamion: we should just make gnome-terminal's colors white on black by default ;) (if you want to get shot that is)
<mdz> Kamion: do you agree that it would be nice to have a single metapackage which would install matching versions of the kernel and restricted-modules, for d-i purposes?
<Kamion> mdz: definitely
<npmccallum> mdz: that would fix bug #1835
<Kamion> mdz: although I'm not sure how well it plays with people who want to remove the restricted-modules
<mdz> Kamion: right
<mdz> the question is whether we should have two
<mdz> one which gives you the latest recommended kernel
* Kamion is uploading incremented-ABI linux-kernel-di now
<mdz> and one which gives you the kernel + restricted-modules
<mdz> and if we should, what do we call them?
<Kamion> no good ideas on naming I'm afraid
<mdz> currently we have linux-<flavour> which depends on both image and modules
<mdz> but it's in main, and depends on restricted
<mdz> so it seems to want to be split for that reason as well
<Kamion> I can deal with installing two packages
<mdz> well, we also need it for upgrades
<mdz> otherwise the image gets upgraded and the modules never do
<mdz> and they just vanish
<Kamion> you could make the restricted-modules metapackage depend on an exact version of the kernel metapackages
<Kamion> s/s$//
<Kamion> then you'd have to upgrade it or remove the metapackage, and if people remove the metapackage then we can't help them anyway
<mdz> hmm
<Kamion> and since the two come from the same source package, there's no maintenance issue with having Depends: linux (= ${Source-Version})
<Kamion> (or whatever)
<mdz> well, the modules concrete package depends on an exact kernel version
<mdz> so if we start installing the modules metapackage rather than the concrete, we should get reasonable upgrade behaviour
<Kamion> right
<mdz> tying them together with a metapackage seems like the right thing to do, there is only this naming problem
<mdz> Jane bailed us out of the last naming roadblock; I'll ask her
<mdz> hm, she left
<Kamion> this is relatively easy to do in base-installer, but I was holding off fixing the bug that made it not work until I had a restricted-modules metapackage
<doko> kamion: my mistake, I left the color prompt enabled after testing. I'll have to make a new upload disablint it.
<Kamion> mdz: you don't get reasonable upgrade behaviour just from that, actually
<Kamion> mdz: since the old kernel concrete package stays installed
<mdz> Kamion: aptitude will remove it
<Kamion> which is why I think metapackage dependencies are necessary
<mdz> but arguably it should stay installed, in case the new one breaks
<Kamion> what? that's insanity
<mdz> well, the install kernel should always stay, since that was installed explicitly
<mdz> but things pulled in by metapackage dependencies will be removed by aptitude when the dependency goes away
<Kamion> won't the kernel package stay, since the prerm bails out if it's the currently running kernel?
<mdz> hmm, possibly
<mdz> I bet that pisses aptitude off
<mdz> anyway, speaking of kernels, it's time for a couple of reboots to test if -3 fixes my issues
<mdz> brb
<Kamion> elmo_: linux-kernel-di-* uploaded, let me know when you've NEW-processed them since I need to change debian-installer at that point
<elmo_> Kamion: hmm, don't see them?
<elmo_> oh, right, being built
<Kamion> yeah
<mdz> yay, fixes the APIC issue with my system
<Kamion> mdz: been trying to fix the debconf noninteractive/seen thing; turns out to be amusing to fix, my current attempt causes the aa_DJ locale to be generated by default on new installations
<mdz> Kamion: aa_DJ and only aa_DJ?  or all of them?
<Kamion> (I'm relatively sure we don't have enough Afar speakers to merit that :-))
<Kamion> mdz: only aa_DJ; the default implementation of the noninteractive select element sets the value to the first item in the list
<Kamion> and evidently I've slightly changed the behaviour there, not so unexpectedly ...
<elmo_> linux-restricted-modules-2.6.8.1_2.6.8.1.1-6_i386.changes
<elmo_> SKIP (too new)
<elmo_> Rejected: nvidia-kernel-source_1.0.6111-1ubuntu2_i386.deb: old version (1.0.6111-1ubuntu2) in warty >= new version (1.0.6111-1ubuntu2) targeted at warty.
<mdz> oh EW
<mdz> need to manually update debian/rules for every new version
<mdz> uploading -7
<Kamion> off to karate, back in a couple of hours
<mdz> hmm
<mdz> is it just me, or are linux-meta and linux-source now building some of the same binaries?
<tseng> hi.
<mdz> elmo_: I suppose that's something that ought to be fixed in short order?
<elmo_> mdz: it's not disastrous from my POV?
<mdz> elmo_: which one will end up in Packages?
<elmo_> whichever is newer
<elmo_> if they're the same one will be  REJECTed
<mdz> fascinating.  that happens to be the right thing in this case
<mdz> er, no it doesn't
<mdz> -meta is at 2.6.8.1-5, and -source is at -8
<mdz> elmo_: if I remove the metapackages from linux-source, will that do the right thing and let the -meta ones come out, or will it disappear?
<elmo_> mm, people are wanting to go for food
<elmo_> mdz: nothing will disappear automatically
<mdz> elmo_: so I should upload linux-meta with a higher version number, I suppose
<elmo_> mdz: yeah, sounds like a plan
<mdz> elmo_: ok, don't let me keep you. a thumbs up/down on that plan would be great
<mdz> ok
<fabbione> bah i can't sleep
* thom lends fabbione a large baseball bat
<thom> or a copy of the X protocol specs
<thom> i guess either would work
<Mithrandir> sounds icky
<fabbione> thom: ?
<fabbione> thom: dude.. what's going on?
<doko> mdz: as I need to disable the colorprompt anyway, should #1758 (lesspipe) really be enabled by default in the profile?
<mdz> doko: you need to disable the prompt why?
<doko> mdz: the ugly color prompt I left enabled by default
<mdz> doko: oh, did it become enabled in your last upload or something?
<doko> yes, I accidentally left it on after trying.
<mdz> eek
<mdz> I see, it is only in the skel
<mdz> doko: do you see any harm in enabling lesspipe by default?
<doko> in that case I would like to alias more to less, so that the user has the same experience with both commands.
<mdz> that doesn't make sense to me; they have different user interfaces
<doko> for a beginner, they are about the same, but "more changelog.gz" and "less changelog.gz" should have the same experience.
<mdz> I think that enabling lesspipe in less and aliasing more to less are entirely separate propositions
<doko> welcome to the can of worms of user profiles ;-) I'll add the lesspipe suggestion, but I would prefer to leave it commented out.
<mdz> some programs can view compressed files, and some cannot (e.g., vim/emacs vs. gedit), but they should remain distinct because users expect to get what they ask for
<mdz> ok, if you have doubts, please raise the issue for discussion on ubuntu-devel
<mdz> doko: please don't wait to fix the colour prompt bug; that must be fixed for the next daily CD build
<doko> fine, and for now I added the lesspipe line as well (commented out).
<thom> fabbione: either one would help you sleep ;-)
* thom yawns and stretches
<fabbione> thom: ehehe i got it.. very late ;)
<thom> just converted firefox to dpatch
<npmccallum> Kamion: thanks for fixing the po-debconf bug :), you should probably report something on #1329
<Kamion> npmccallum: it was waiting for a sync, hadn't yet read the mail that the sync was done
<Kamion> I did update the status whiteboard on #1329 earlier :)
<Kamion> npmccallum: oh, bugger, no I didn't, I had a mid-air collision in bugzilla and forgot to follow through. anyway, closing now
<mdz> Kamion: how long before the new kernel propagates to a daily CD?
#ubuntu-devel 2004-10-09
<Kamion> mdz: I'm waiting for the i386 kernels to build
<Kamion> or be NEW-processed or whatever, not sure where they are
<mdz> Kamion: I mean, does that require a 2-day cycle to get into d-i and then onto the CD?  or does it go straight to the CD?
<mdz> on a previous occasion you said that a particular update would take 2 days to propagate
<Kamion> http://people.no-name-yet.com/~lamont/buildLogs/l/linux-kernel-di-i386-2.6/0.64ubuntu4/linux-kernel-di-i386-2.6_0.64ubuntu4_20040927-2023-i386-successful says it built OK
<mdz> they're probably waiting in NEW, then
<Kamion> mdz: I'm going to be doing a debian-installer upload today anyway, so it'll get into that
<Kamion> since it's needed for the new kernels
<mdz> I wonder if NEW processing can be automated for warty, for new binary packages from existing source
<Kamion> and I have a few minor boot screen changes from Mark
<mdz> or more importantly, if elmo would explode
<Kamion> dunno, I tend to think it's a good sanity check
<Kamion> at the very least it would have to validate against germinate output, I think
<Kamion> mdz: to answer your earlier question properly, the new kernel .debs go straight to the CD, but the new .udebs require a d-i build and then a CD build
<Kamion> if you forget about the d-i build stage, then the CD is essentially unusable for a day
<mdz> Kamion: so the end result is that if they get processed in time for your d-i build, they'll be on tomorrow's CD
<Kamion> mdz: since I'm waiting for it ... :)
<Kamion> yes
<Kamion> I'll hopefully be doing a CD build tonight, maybe calling it Sounder 9 if it works
<mdz> I tested a CD install after fixing vim, and it worked for me
<mdz> so hopefully it should be in good shape
<elmo_> NEW cleared
<elmo_> anything else before I head back to the hotel?
<mdz> elmo_: don't think so, thanks
<mdz> elmo_: oht, wait
<Mithrandir> elmo_: sync gftp, please?
<Mithrandir> elmo_: you've got mail about it, and mdz approved it
<mdz> elmo_: myspell-en-us and myspell-en-gb hadn't yet been added to desktopp when you did the resync, I think
<mdz> I've added them now
<Mithrandir> but I haven't seen it, so I guess you've forgotten?
<Mithrandir> or not done yet
<mdz> those should be in desktop for sounder 9 if at all possible
<mdz> so that spell checking works
<elmo_> Mithrandir: it wasn't on ftp.uk earlier - I'll check
<Mithrandir> elmo_: it was in incoming when I wrote the mail. :)
<elmo_> yeah, I don't sync from incoming, that feels like crossing a line
<Mithrandir> makes sense
<mdz> likewise for openoffice.org-hyphenation
<Mithrandir> mdz: we've had an ooo upload since my amd64 build, right?
<mdz> Mithrandir: I think so, yes
<Mithrandir> mdz: do you know if anybody has done the amd64 upload as well?
<Mithrandir> if not, I should get around to it tomorrow
* Mithrandir misses something like madison
<Kamion> elmo_: hm, will you be able to byhand the debian-installer upload tonight?
<Kamion> elmo_: if not, I'll defer Sounder 9 'til tomorrow
<mdz> Mithrandir: I do not think it has been done yet
<Mithrandir> nope, doesn't look like it.
<Kamion> elmo_: just uploaded debian-installer 20040801ubuntu16, so it should build soon
* lamont grumbles
<lamont> linux-source-2.6.8.1_2.6.8.1-7_i386.changes REJECTED
<lamont> hrmpf
<tseng> =/
<tseng> did the builder pickup mono yet?
<lamont> tseng: source package name mono?
<tseng> all the mono stuff we talked about the other day
<tseng> update from sid.
<lamont> not showing up as of 5 minutes ago
<lamont> still, taht is
<tseng> hm, ok.
<lamont> elmo about?
<lamont> "sure, we can get you in and out in a just a couple of hours".. sigh.
<elmo_> kamion: processed
<Kamion> kewl, ta
<elmo_> mdz: myspell done, I think ooo-hyphen stuff was done earlier
<elmo_> Mithrandir: done
<Mithrandir> elmo_: thanks a lot
<elmo_> anything else?
<Kamion> ok, I think I need a drink before the parted-code-review-of-doom
<Kamion> back in a bit
<lamont> elmo_: hints on all the reject mail I got earlier today?
<elmo_> lamont: the contrib shit?
<elmo_> if so, you can ignore it
<lamont> that and some stale amd64 bits
<lamont> and some apparently empty changes..
* lamont likes the ignore option
<elmo_> who uploaded docbook, sgml-data and gnomemeeting?  it got wrong distributioned
<elmo_> seb128: gnomemeeting is you 
<elmo_> (ignore the other two, they were daniels and he fixed)
<seb128> ok
<mdz> elmo_: thanks
<mdz> elmo_: -en-gb was seeded, but -en-us was not
<mdz> elmo_: looks like -en-us is still in universe
<elmo_> yeah, fixed
<mdz> thanks
<elmo_> really going now, it's 30 mins back to hotel :(
<mdz> elmo_: good night
<mdz> thanks for staying
<azeem> did you guys see the ubuntu review featured on /. already?
<mdz> the one which is just a link to the extremetech story?
<mdz> (if so, yes)
<azeem> yes
<azeem> there's another one on osnews, though
<Mithrandir> mdz: argh, sorry, I just uploaded ooo-amd64 to sync; I guess that's ok?
<Mithrandir> if not, I can still pull it
<Mithrandir> no, I can't.
<mdz> azeem: yes, that one is already linked from http://www.ubuntulinux.org/ubuntu/press/
<mdz> Mithrandir: it's ok
<Mithrandir> mdz: sorry about not asking for confirmation.  Shouldn't upload when tired. :/
* Mithrandir goes to bed for real
<mdz> good night
<jdub> uuuggghhh
<tseng> hiya jdub 
<fabbione> morning
<daniels> morning fabbione
<fabbione> hi dani
<daniels> jdub: ok if I claim 1394?
<fabbione> daniels: do you happen to have Rene Rebe email addredd?
<fabbione> address even
<daniels> who's rene rebe? :)
<fabbione> it's someone that commits code to Xfree86
<fabbione> if i knew who he was i wouldn't ask :-)
<fabbione> but google returns only one possible match
<daniels> heh
<daniels> which code has he touched?
<fabbione> ok i found him
<fabbione> i think i even meet him at LinuxTag
<daniels> heh!
(jdub/#ubuntu-devel) mdz: anyway, you pinged?
<mdz> jdub: I think I wanted to ask you about what ended up becoming #1851
<fabbione> mdz: i need to wait to upload X
<fabbione> mdz: Overfiend spotted a possible licence problem with one fix i imported from xfree86
<fabbione> we already mailed the guy asking for copyright/licence clarification
<fabbione> the fix shouldn't be important for the nv driver but it's good to have
* jdub gars at ubuntu-audio bugs
<jdub> most annoying widget when you have audio turned on: the option list!
<jdub> mdz: oddly, g-s-t doesn't even grok that my device is wifi
<jdub> argh
* jdub turns off sounds
<mdz> pitti: did you see my report to the list with the new utopia stack crashing?
<mdz> fabbione: ok
<pitti> mdz: not yet, I look
<pitti> mdz: I'm still at processing my inbox...
<mdz> ok
<mdz> jdub: it seems so strange that it doesn't let you configure an encryption key, since the backend support seems to be all three
<mdz> s/three/three/
<mdz> s/three/there/
<jdub> i can't even configure an essid atm
* fabbione has to wait all the secondary MX's to flush the queue
<pitti> mdz: ugh, it crashes in gnome-vfs?
<pitti> mdz: I have an idea for a slightly easier method of unmounting
<pitti> mdz: I will prepare a test package and send it to you
<mdz> pitti: great, I will be awake for a bit, but not too long
<mdz> pitti: do you not experience the crash?
<pitti> mdz: no, it worked fine for me
<mdz> interesting
<pitti> mdz: I tried burning to an unmounted and to a mounted RW+
<mdz> this is basically a clean warty install
<mdz> I did a daily cd install test 2 days ago
<pitti> mdz: hmm, I apt-upgraded yesterday
<mdz> jdub: what's the deal on wvdial?  shall we suck it up and add wvdial to desktop?
<pitti> mdz: but this stuff must work with all versions, not just with one combination
<jdub> mdz: i think that's the only way forward at this stage
<mdz> done
<pitti> mdz: re capability module loading: was there a hotplug update to handle this? I don't have the modules in /etc/modules
<jdub> "The biggest flaw I see with this distro ..."
<jdub> "Is its name. I mean, what the hell is an Ubuntu? :) I could think of a million names better than this one."
<jamesh> as opposed to a Linspire or a Suse?
<mdz> pitti: I have no idea; I thought it was in the same situation as ppp_generic, ide-disk, etc. where there was simply no trigger to load it
<pitti> mdz: maybe it's loaded automatically as soon as hal starts
<pitti> mdz: I will try that out
<Mithrandir> ARGH.
<Mithrandir> apt-get upgrade hangs, but works if I strace it.
<Mithrandir> I wonder how I am to generate an useful error report out of this..
<pitti> mdz: hmm, now n-c-b crashes at my box _with_ the fix I had in mind...
<pitti> mdz: I wanted to unmount the CD the Gnome way, to get rid of device locks and have the preumount signal
<pitti> mdz: but these APIs are not documented yet; if that fails, I can revert to just calling pumount for the device
<mdz> jdub: you can configure the essid; it's just sneaky about it
<mdz> jdub: essid == "network name"
<mdz> jdub: which nobody _ever_ guesses (#1295) and I think we should fix if possible
<jdub> mdz: no seriously -> g-s-t does not grok that eth1 is a wireless device. (so doesn't offer *any* of those options.)
<mdz> jdub: sux0r, works for me
<jdub> also, where do bluetooth devices show up?
<mdz> jdub: what do you get when a cross an elephant with a rhino?
<pitti> mdz: http://www.piware.de/nautilus-cd-burner_2.8.3-0ubuntu1_i386.deb
<pitti> mdz: works for me
<jdub> /proc/bluetooth has stuff in it, but the device doesn't seem to be listed anywhere sane
<mdz> pitti: I'll give it a try
<mdz> Mithrandir: when did this problem appear?
<Mithrandir> mdz: some time ago -- a week or two, I think.
<jdub> mdz: confirmation for gdm upload that changes conf stuff only?
<Mithrandir> I've upgraded to the latest kernel, so it's at least not that.
<jdub> four changes in total:
<jdub> -#GtkTheme=Default
<jdub> +GtkTheme=Human
<Mithrandir> mdz: and it's worked around easily enough with LD_ASSUME_KERNEL, but I fear some end-user will run into it.
<jdub> -#AllowGtkThemeChange=true
<jdub> +AllowGtkThemeChange=true
<jdub> -#GtkThemesToAllow=all
<jdub> +GtkThemesToAllow=Human,HighContrast,HighContrastInverse,LowContrast
<jdub> -#UseCirclesInEntry=false
<jdub> +UseCirclesInEntry=true
<jdub> 
<mdz> jdub: yes (didn't we do that some time ago?)
<mdz> at least GtkTheme=Human I thought we had done
<jdub> nup
<jdub> that was the gdm default theme
<jdub> not the gtk theme
<mdz> Mithrandir: I've seen no other reports :-/
<Mithrandir> mdz: neither has I.
<Mithrandir> I'm running on a p4 with the smp kernel, though
<Mithrandir> I don't know if that's unusual
<seb128> morning
<elmo_> aiee
<elmo_> seb128: that new gnomemeeting pulled in a whole bunch of stuff to main - known?
<seb128> which stuff ?
<elmo_> db2, docbook-defguide, docbook-ebnf, fftw, tidy, wvdial, wvstreams
<seb128> that's due to gnomemeeting ?
<seb128> I've uploaded previous version with only "libpt-plugins-v4l | libpt-plugins-avc | libpt-plugins-dc" in the depends
<elmo_> hmm, maybe not, sorry, I think it's gnome meeting plus some seed changes
<seb128> ok, no problem
<seb128> wvdial is required for ppp config with gnome-system-tools
<seb128> somebody probably added it to a seed
<seb128> dunno for the others
<elmo_> yeah, matt did
<elmo_> most of them seem to be pulled in as build-deps for wvdial
<elmo_> evil
<seb128> ok
<sivang> fabbione , here?
<mdz> Mithrandir: does it go away if you use the non-smp kernel?
<sivang> or daniels?
<mdz> elmo_: how bad is it?
<mdz> I knew it pulled in one other package, but didn't look beyond that
<elmo_> oh
<mdz> fftw??
<elmo_> you're still awake
<elmo_> mdz: b-d of wvstreams
<elmo_> (which is b-d of wvdial)
<mdz> yeah
<elmo_> all the ones I listed above are source packages that'll be pulled in
<mdz> what crap
<sivang> anyone besides fabbione/daniels can help to work a 100hz working X config?
<elmo_> all due to wvdial
<mdz> I wonder if wvstreams can be pared down not to require those
<mdz> certainly the doc stuff
<sivang> I've been munging it for a couple of hours, X just won't agree to use 100Hz for vrefresh. Although monitor supports it
<elmo_> mdz: want me to add it in the meantime?
<mdz> elmo_: that is way too much cruft for my comfort
<mdz> I wish we didn't need wvdial itself either
* elmo_ quietly undoes the stuff he just added ;-)
<fabbione> sivang: yes i am around but please move the discussion to #ubuntu
<sivang> fabbione : ofcourse
<fabbione> crack of day doesn't install
<fabbione> libdns16 is not going to be installed
<mdz> fabbione: uploading a new debootstrap
<elmo_> gar, main depends on restricted now?
<elmo_> is that valid?
<mdz> elmo_: I emailed you and colin twice, weeks ago, asking your opinion on that, and neither of you replied
<mdz> pitti: your new nautilus-cd-burner fixes the segfault
<elmo_> you mentioned that, but I couldn't find any mail about it
<mdz> pitti: but the original problem is not fixed
<pitti> mdz: okay, thanks for the report
<pitti> mdz: which original problem?
<mdz> pitti: the device is still mounted in the middle of the write operation
<pitti> mdz: even with the new hal/gvm?
<mdz> Version: 0.2.98-1ubuntu1
<mdz> Version: 1.0.2-0ubuntu1
<pitti> mdz: when you start to burn, hal-device-manager should display some info.lock* properties
<pitti> mdz: it worked fine for me, so I thought that were handled...
<mdz> pitti: I did not see any; is that the right version of hal?
<pitti> mdz: this locking stuff is not perfect anyway; it is an advisory lock for gvm, and you can still pmount the device or use a manual mount (right-clock in context menu)
<pitti> mdz: yes, right hal version
<elmo_> mdz: I've re-searched and really can't find this mail - can you give me a subject/msg-id?
<mdz> 02:05:24.253 [I]  linux/block_class_device.c:2312: Directory /etc changed
<mdz> 02:05:24.253 [I]  linux/block_class_device.c:2226: /etc/mtab changed, processing all block devices
<pitti> mdz: I also could reproduce this once, but I tried yesterday and it did not "work" (the bug reproduction)
<mdz> pitti: that is all I see from hal when the write starts
<pitti> mdz: I don't know whether the lockign stuff is logged; can you look into hal-device-manager?
<mdz> elmo_: I'll look; I don't _think_ I hallucinated it
<mdz> elmo_: but basically I think it comes down to naming.  I'd like to have a metapackage which depends on both linux-image and linux-restricted-modules, and probably another one which just depends on linux-image
<pitti> mdz: I just got another grave bug report against the new hal; it can destroy USB stick file systems
<mdz> but I can't think of reasonable names
<pitti> mdz: new upstream versions...
<mdz> elmo_: Message-ID: <20040917001908.GR5721@alcor.net>
<mdz> elmo_: Subject: Re: Metapackages for linux-restricted-modules
<mdz> pitti: great :-/
<mdz> pitti: anyway the burning seems to work correctly at least
<pitti> mdz: yes, great that I did not upload the stuff immediately :-/
<mdz> it is just disconcerting to have it open and close during the process
<pitti> mdz: oh, when it happened to me, the burning failed
<pitti> mdz: maybe because my burner is very old and does not have burnproof and the like
<pitti> mdz: locking still should work, this was the primary reason for the new upstream stuff
<pitti> mdz: I take a look at this today
<elmo_> mdz: okay, sorry I did get that but managed to completely lose it somehow
<elmo_> mdz: anyway, I really think violating the main-is-a-self-contained-unit thing is a bad plan, but I can't really justify it beyond that
<fabbione> mdz: 1405. i dunno. i can't really check right now since my test box can't be installed until debootstrap is built and uploaded
<mdz> elmo_: I agree; I was looking for something more in the way of a solution
<mdz> fabbione: it is already built and uploaded
<elmo_> mdz: you should have learnt not to have such unreasonable expectations by now, dude
<mdz> eek, hal just segfaulted on me
<mdz> after I powered off my burner
<mdz> 02:15:24.905 [I]  linux/block_class_device.c:637: Disc in /dev/sr0 has audio
<mdz> 02:15:24.905 [I]  linux/block_class_device.c:666: get_disc_type returned 0x360a
<mdz> 02:15:24.905 [I]  linux/block_class_device.c:1027: Media in no_partitions device /dev/sr0
<mdz> [1] +  Segmentation fault      sudo hald --drop-privileges --daemon=no --verbose=yes
<pitti> mdz: do you run this with --daemon=no?
<elmo_> mdz: but seriously, there are no solutions beyond "don't do that" surely? i.e. using, like you  said, two meta packages
<mdz> pitti: correct
<pitti> mdz: or where do you get these messages from?
<mdz> elmo_: <mdz> elmo_: but basically I think it comes down to naming.  I'd like to have a metapackage which depends on both linux-image and linux-restricted-modules, and probably another one which just depends on linux-image
<elmo_> I think two meta packages is more correct anyway as not all of us are going to want the restricted crap installed
<pitti> mdz: incidentially, my hal also crashed
<mdz> I guess we could have linux-<flavour> as the image+restricted one
<mdz> and create a linux-image-<flavour> for just the image
<pitti> mdz: but no segfault, it just hangs uninterrupibly
<mdz> ok, I need to get to bed
<mdz> more on all of this tomorrow
<pitti> mdz: sleep well! If you can reproduce the crash, can you please try to run it in gdb?
<fabbione> mdz: well it's not on auckland yet :-))
* fabbione goes and cook lunch in the meanwhile
<seb128> hum
<seb128> I've added "libpt-plugins-v4l | libpt-plugins-avc | libpt-plugins-dc" to the gnomemeeting depends ... we need to update seed too to get these into main ??
<seb128> -?
<elmo_> seb128: I did that already
<elmo_> seb128: but please mail me when you do stuff that adds deps on stuff in universe - it's not automated
<seb128> ok, thanks 
<seb128> sorry, I'll remember next time
<elmo_> no prob
<seb128> I was thinking that depends for stuff in main were automatically in main ...
<elmo_> no, because a) the wiki's wide-open and that's where the seed lists are, b) even additions by our venerable CTO (e.g. wvdial) lead to unexpected and unwanted changes
<seb128> ok
<elmo_> kiko would like you all to not do any work because he couldn't code his way out of a wet paper bag
<elmo_> even pylint says so
* sivang switching to irssi
<Mithrandir> mdz: yes, non-smp kernel fixes it.
<fabbione> mdz, jdub: permission to upload initscripts to fix #1405
* thom has 400GB of SATA love on his desk
<thom> *drool*
<daniels> thom: gar
<daniels> thom: i'll let you keep the hard drives if you send me the LCD
<thom> har har
<daniels> thom: sound fair?
<thom> you're so kind
<daniels> i know. the Mother Teresa of the open source world.
* daniels kicks IBM.
<daniels> fascists.
<daniels> they called me at 11am (!) and then said they'd email me all the details I needed to actually pay them in half an hour
<daniels> that was a good 9 hours ago now
<thom> heh
* daniels sharpens his conversation axe and prepares to do battle again tomorrow.
<fabbione> who is going to approve uploads if both mdz and jdub are not available?
<fabbione> elmo?
<daniels> hm, sabdfl, mdz and jdub all unavailable
<ross> fabbione: i'm sure its fine to upload
<daniels> i sense this is an extension of the dsl bug; more anti-canonical agents, I suspect
<fabbione> ross: eheheh i know it's fine.. but we are deep freeze and uploads require authorization
<elmo_> fabbione: no, not me, I'm just the archive bitch, nothing to do with RM
<Mithrandir> fabbione: mdz should be up in five-ish hours, though.
<fabbione> elmo_: well you are still cool enough to do RM too :P
* Mithrandir raises thom another 400GB SATA disk.
<fabbione> Mithrandir: yeah but i won't be around in 5 hours..
<fabbione> Mithrandir: gotta go and talk with the electrician.
<Mithrandir> I should set up 1-hour DELAYED, 2-hour DELAYED and so on for us.
<elmo_> Mithrandir: gar no
<fabbione> the little punk he sent to me to make a job proposal didn't get a clue that i need a nuclear power plant in the garden
<Mithrandir> elmo_: jk. ;)
<thom> Mithrandir: i have a pair of 200s, as it happens
<Mithrandir> thom: smallish, then.
<Mithrandir> thom: I have a pair of 400s.
<thom> that seems a little over the top
<Mithrandir> not for a backup box
<thom> given that i have windows and two warty installs on a single 40GB drive, 200GB is gonna feel huge
<thom> Mithrandir: ah. see, this is for my desktop
<Mithrandir> my ~ is 20G.
<jdub> fabbione: you need approval for 1405?
<thom> 4.9G  4.4G  506M  90% /home
<jdub> man, hardly worth answering questions on u-u anymore, given the multiple answers all the time
<thom> it gets very uncomfortable when building firefox ;-)
<fabbione> jdub: yes
<Mithrandir> thom: I can imagine.. that's the size of my mail dir
<jdub> fabbione: ok, approved
<fabbione> jdub: thanks
<fabbione> done
* jdub goes to sleep
<trukulo> jdub: good night
* Kamion builds new images, given the base-system breakage
<ross> Kamion: i take it tomorrows daily images will have the new kernel in?
<Kamion> today's already do
<Kamion> they don't work for other reasons
<ross> ah, ok. will tomorrows work? :)
<Kamion> huh, wait a sec
<Kamion> aha, today's *didn't build* :P
<ross> aah
<Kamion> and that would be because people *still* need to warn me when they're going to change the base system. gah.
* Kamion tries again
<elmo_> sorry (I didn't request it, but I could have blocked it/whined at NEW)
<Kamion> ah well
<elmo_> Purging configuration files for nautilus ...
<elmo_> rmdir: `/etc/X11/starthere': No such file or directory
<elmo_> dpkg: error processing nautilus (--purge):
<elmo_> seb128: getting that on one of the machines in the DC - known/fixed problem?
<seb128> no, not known
<seb128> I'll have a look
<lamont> morning world
<thom> yo
<seb128> hey lamont 
<seb128> elmo_: ok, I'll fix it
<lamont> gotta take kids to school in a few.
<elmo_> seb128: cool, thanks
<elmo_> seb128: want me to file a bug you can point jdub/mdz at?
<elmo_> seb128: btw, it's all 3 directories mentioned in the postrm, but I guess you knew that
<seb128> no, that's fine. I'm allowed to fix GNOME bugs without asking :)
<seb128> yes, I know, but thanks :)
<elmo_> haha, Jeff's RM-ing is just such an excuse for him to ignore the rules for "feature goals" (i.e. what he cares about :P)
* lamont debates adding logfile size to the byDate report
<lamont> elmo_: duh...
<lamont> it's _ALWAYS_ that way.  When it's not, you have a boring RM. :-)
<elmo_> Looking for keymap to install:                                                                                                  
<elmo_> \mac-usb-uk
<elmo_> oh my god, not that stupid bug still!
<elmo_> (the \ is a pasto, ignore that)
<Kamion> hm? mac-usb-uk's correct here
<elmo_> kamion: not on a HP DL380, it's not
<Kamion> !
<elmo_> that happened as part of the upgrade
<Kamion> console-data must be on good crack
<Kamion> I'm afraid I only barely understand what's going on in console-data.config, though
<Kamion> 'dpkg-reconfigure console-data' ought to at least let you clear it up ...
* lamont bbl
<elmo_> GOD DAMN IT
<pitti> sjoerd: here?
<sjoerd> pitti: yeah
<pitti> sjoerd: I looked at this mount locking stuff when a CD-RW is burned
<pitti> sjoerd: currently only the hal package supports locking; but shouldn't gvm actually check this lock before mounting a device?
<pitti> sjoerd: do you know whether this is already implemented upstream?
<sjoerd> pitti: it's in gvm's unstable branch
<sjoerd> pitti: i intend to patch debians gvm 1.0.2 with it before uploading
<pitti> sjoerd: I was already wondering why cd burning still sucks...
<sjoerd> but first hal needs to get out of new...
<pitti> sjoerd: thanks; I will grab it from there
<pitti> sjoerd: do you happen to have the CVS URL at hand?
<pitti> sjoerd: don't bother, I have it
<sjoerd> hehe
<sjoerd> pitti: although for debian it's still somewhat useless, because nothing uses it
<pitti> sjoerd: we urgently need that to fix cd burning
<pitti> sjoerd: the half-written cd is mounted during burning, which breaks the further burning
<pitti> sjoerd: and the user can still manually mount the cd
<sjoerd> autch
* sjoerd hasn't seen that behaviour
<sjoerd> only that some drives abort burning when nautilus polls media status
<pitti> sjoerd: ah, I have the patch
<sjoerd> s/nautilus/hal/
* pitti will go to implement it
<pitti> sjoerd: when I'm at fixing gvm, what does this 03_browse_fixup patch do?
<pitti> sjoerd: does it open a nautilus window if gthumb is not invoked?
<sjoerd> pitti: yes
<pitti> sjoerd: nice
<sjoerd> pitti: same for when inserting dvd's when video playing action is disabled
<pitti> sjoerd: will it go upstream?
<pitti> sjoerd: I don't want to diverge from upstream behavior too much
<sjoerd> pitti: i've sent it but it wasn't applied 
<pitti> sjoerd: we already discussed that; this should probably be another option in the removable device configuration dialog
<sjoerd> pitti: ?
<pitti> sjoerd: Ubuntu has a nice dialog where you can configure what happens with your removable devices
<pitti> sjoerd: This is no Ubuntu invention, it must be there in Debian, too
<sjoerd> pitti: you mean gnome-volume-properties 
<pitti> sjoerd: probably :-)
<sjoerd> what do you mean by ``this'' there. Opening nautilus when the import photo's option is disabled ?
* sjoerd needs to put all the debian patches in bugzilla rsn, so they won't be completely forgotten
<pitti> sjoerd: by "this" I mean "fall back to browsing if no other handling was applied"
<sjoerd> ok
<pitti> sjoerd: IMHO it makes sense
<pitti> sjoerd: but some users might not want it
<sjoerd> hmm.. well a mass storage camera is just removable storage, for which gvm makes an exception
<pitti> sjoerd: AFAICS this gvm patch only inhibits automatic mounts during CD Burning
<pitti> sjoerd: users can still mount it manually
<pitti> sjoerd: so maybe gnome-vfs2 shoudl respect info.locked as well?
<sjoerd> that would be nice
<pitti> sjoerd: this still won't help against a command line "mount", though
<pitti> sjoerd: that's the reason why I implemented this in pmount
* sjoerd was just thinking about that
<azeem> pitti: who sould mount a CD while it is getting burned?
<pitti> sjoerd: but matt prefered the upstream solution
<azeem> eh, s/sould/would/
<pitti> azeem: users do stupid things.. :-)
<azeem> yeah, but you don't patch coreutils to prevent rm -rf $HOME either, do you?
<sjoerd> there is a certain level where the user is just doing stupid things
<pitti> azeem: no
<pitti> sjoerd: agreed :-)
<sjoerd> you can't prevent that :)..
<azeem> I mean, if somebody uses the command-line, he should know what he does
<azeem> or she
<sjoerd> preventing accidental mounts from nautilus sounds nice though
<pitti> sjoerd,azeem: Implementing it in pmount was no big deal, so it would have been nice
<sjoerd> Is ubuntu's cdrecord patched to use O_EXCL btw ?
<pitti> sjoerd: I will implement this if the current packages are uploaded
<pitti> sjoerd: I don't know
<pitti> sjoerd: but that sounds sensible; I added it to my ~/.todo
<sjoerd> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262678 for some more info about it
<sjoerd> same goes for all other burning programs ofcourse
<pitti> sjoerd: like these dvd+rw-utils?
<sjoerd> pitti: if that's the same as dvd+rw-tools in debian
<sjoerd> and libburn and cdrdao
<pitti> sjoerd: thanks for pointing me to that; we don't have this patch
* thom sobs at firefox some more
<daniels> thom: what's it done now?
<Kamion> lamont: can you remind me how the buildds manage to install linux-image-* in a chroot?
<Kamion> elmo_: or if you know, for that matter ...
<T-Bone> lamont: ping, btw
<thom> i can see why mark likes mozilla so much. it's the ultimate "ooh shiny" development menthodology
<thom> methodology, even
<thom> "hey, corba in javascript sounds cool!"
<ross> with XML and RDF!
<ross> and and and
<ross> things!
<thom> and C++!
<thom> gar
<thom> oh well, i shall hack on php for a bit to save my poor brain
<daniels> thom: C++ is love, kiddo :)
<daniels> (C# more so, however)
<ross> sjoerd: thanks for the patch :)
<ross> sjoerd: have the cd-drive patches been applied to n-c-b already?
<ross> i can't believe i left HAL_CFLAGS out
<sjoerd> sjoerd: no idea
<sjoerd> ross: no idea
<sjoerd> beh
<ross> k
<Kamion> Subject: Processed: only in Keny^Wwoody
<Kamion> haha
<lamont> Kamion: on the buildd's, I do this:
<lamont>     echo do_initrd = Yes > ${chroot}/etc/kernel-img.conf
<lamont>     install -m644 /etc/fstab ${chroot}/etc/fstab
<lamont> although (technically) you just need the root filesystem'sentry in /etc/fstab in the chroot.
<Kamion> heh, ok, thanks
<Kamion> as it turned out I got bored and nobbled the postinst :)
<Kamion> but I'll know for next time
<lamont> OTOH, it would be much better if the postinst actually noticed that it was in a chroot, and just dealt with it.
<Kamion> lamont: aye
* lamont isn't sure if a process _can_ tell that it's in a chroot, though.
<T-Bone> ladude!
<lamont> t-dude
<lamont> T-Bone: let me guess: "So how do I make that thar archive thang?"
<T-Bone> lamont: lol, roughly
<lamont> man dpkg-scanpackages :-)
<T-Bone> hmm, isn't apt-ftparchive easier to use?
<lamont> truthfully, put all the _ia64.deb's and _all.debs (harvested from an i386 warty box, or the mirror of your choice) into one directory, and run your archive creator of choice.
<lamont> yeah, whatever. :-)
<T-Bone> lamont: thx to you, i _have_ a local mirror ;)
<lamont> then comes the tricky part...
<lamont> ah, yes. well.
<lamont> once you have that repository built, then you have to:
<lamont> A) decide if you think you can debootstrap from it or not.
<T-Bone> lamont: bad news: perl won't build
<lamont> assume "not"
<lamont> that would be a definite "not". :-)
<T-Bone> lol
<T-Bone> make[1] : *** [lib/Config.pm]  Segmentation fault
* lamont forgets what we did to fix that when it died elsewhen.  burn that bridge when we drive off of it.
<lamont> so.  Add your freshly created ia64 (incomplete) repository to sources.list in the chroot, _BEFORE_ snapshot.d.n
<lamont> apt-get clean
<lamont> apt-get update
<lamont> apt-get -udy dist-upgrade, see how ugly it looks, then probably really upgrade.
<lamont> repeat all those steps iteratively until such time as you have a debootstrappable repository.
<lamont> (from apt-ftparchive through dist-upgrade/sbuild)
<lamont> the sbuild happens after the dist-upgrade, but before the "repeat" :-)
<T-Bone> lol
<T-Bone> looks like it's not gonna be a "one shot"
<Kamion> iva
<Kamion> oops
<Kamion> focus-follows-touchpad. boo.
* lamont hands Kamion a metacity-focus-beating stick
<Kamion> lamont: fluxbox, as it happens, and this is *normally* the behaviour I want ...
<thom> daniels: nothing about C++ is love
<T-Bone> lamont: assuming glibc builds cleanly this time, we only have perl left, and we hope that rebuilding it from an almost ubuntu chroot will make it build, right?
<lamont> right.
<lamont> at this point, the only things we worry about rebuilding are things we need to debootstrap
<Kamion> lamont: the kernel clobbers /proc/$$/root when viewed from inside the chroot, so there are at least some attempts to make it hard to tell
<daniels> thom: eh, there are a lot of things to like.  classes, inheritance, all the good stuff.
<lamont> then we (1) save this chroot, because we'll need it later, and (2) create a fresh new warty chroot, throw everything away, and let the building begin.
<T-Bone> lamont: ok. Then afterwards we'll get into the "real" step2, where we'll debootstrap from this archive a new ubuntu ia64 chroot under which we'll rebuild main one more time, correct?
<lamont> of course, at any point that you have enough to play with a CD set, you can start playing with that...
<lamont> Kamion: yeah
<lamont> it's supposed to not be easy.
<T-Bone> lamont: right, CD set is the top item on my todo list
<lamont> Then again, if you're on ext[23]  and / isn't inode 2, you're in a chroot..:-)
<Kamion> heh
<lamont> Kamion: but if it _is_ to, then you may or may not be in a chroot.
<T-Bone> lamont: actually, i don't want to rebuild everything then in the "stage1-2" phase, i'm only trying to rebuild perl, right?
<lamont> in our bastardized half-breed chroot, we just want to build enough to create our new chroot.
<lamont> and additional gravy as desired.
<lamont> that is, we'll eventually want a fully-built warty tree, built on the bits we built in stage 1
<lamont> but for working on the CD's, you really only care that you have bits.
<T-Bone> ok. So i can save time in sbuilding only what's needed to debootstrap, during the bastardized stage
<lamont> shlib deps and such may be issues, hence the stage 2 build.  But I expect that you'll hit DI issues before you hit stage1 vs 2 issues
<lamont> right.
<T-Bone> okay
<lamont> and then later (in full-blown stage2 timeframe), you'll discover circular build-deps that you need to bastardize back into existance because they didn't build in pure-stage 1
<lamont> hence we keep the bastard chroot
<T-Bone> lol
<lamont> the process is very much objective-focused.. :-)
<lamont> step i) "do whatever it takes to" ...
<lamont> for all values of i.
<T-Bone> lol
<T-Bone> and i thought that bootstraping an arch was something "clean" ;)
<lamont> with a footnote to remember anytime you kludge something horribly, because it'll come back and bite you in your backside later when the buildd's start bootstrapping from your chroot...
<T-Bone> come to think of it, i recall some dirtyness during the fist days of palinux ;))
<lamont> yeah
<lamont> it's never pretty at the start...
<T-Bone> even more fun, we had to crosscompile
<lamont> kinda like working with raw sewage, sometimes...
<T-Bone> yeah ic ;)
<lamont> elmo/elmo_: as a note... When we upstream-version-freeze, could we pretty please snag a consistant archive for all the architectures we _don't_ support, too? :-)
<T-Bone> LOL!
<lamont> or maybe one of the architecture boot-strap teams could help snapshot.d.n get good archive-by-date Packages files..
<lamont> T-Bone: I meant _upstream_ archive, not ours.
<elmo_> lamont: sure.. just remember to remind me ;)
<lamont> 'l
<lamont> 'k, even
<lamont> t-bone: btw, my stage-1 build is up to gcc-3.3 finally
<lamont> Kamion: I got it....  Do the chroot-escape hack, and if you wind up at the same place, then you're not in a chroot.. :-)
<T-Bone> lamont: hehe, as a matter of fact, rx2600 is much faster than i2000 ;) hppa is building #633
<lamont> yeah
<Kamion> lamont: :-)
<lamont> T-Bone: once my wife's conference is over this weekend, then I'll worry a little bit about getting the zx2000 powered up somewhere useful.
<Kamion> so, this hideous parted C/H/S bug is apparently fixed in parted 1.6.12
<T-Bone> lamont: hehe ;)
<T-Bone> lamont: i'll setup apache so that you can access my archive anyway
<daniels> Kamion: huzzah!
<Kamion> I'm contemplating just upgrading us to that directly, because I really don't trust the Debian parted maintainers to have come up with a sane parted 1.6.11+patch-based package
<Kamion> particularly because until I noticed it last night the relevant patch wasn't even being APPLIED, so it's clearly had no testing
<daniels> is timshel still maintaining it?
<Kamion> no, luther
<daniels> oh god
<lamont> T-Bone: I'll mail you my list of .changes: let me know if you want any .debs from the pile...
<Kamion> does anyone here actually have a system which manifests the problem?
<T-Bone> lamont: ok
<Kamion> I don't, which makes it problematic
<T-Bone> lamont: asa i'll have setup the repo, i'll mail you the url as well
<lamont> sent
<T-Bone> thx!
<T-Bone> i'll send some feedback to u-devel about the progress we're making, too.
<lamont> mdz: they closed the debian bug wrt SIGILL/powerpc (#1596 for us)... Can I close it here too?  or do we want to actually look for the bug?
<lamont> :-)
<lamont> fabbione: _ANOTHER_ xfree86?  sihg.
<lamont> sigh,even.
<lamont> Kamion: can you verify that 1711 is fixed by adding postfix reconfig back to base-config?
<Kamion> lamont: give me a sec, I'll do a fresh install
<lamont> Kamion: anytime in the next 10 hours or so would be wonderful... :)
* lamont ducks
* lamont grumbles at the lack of myspell-en
* lamont kicks his local mirror
* lamont requests a sync of oo.o-debian-files
* T-Bone apt-get moo
<lamont> T-Bone: still there, yep.
<T-Bone> hehe ;)
<Kamion> lamont: well. newaliases gets run, but the only entry in /etc/aliases is still postmaster: root
<lamont> hrmpf.
<lamont> Kamion: any chance you could mail or /msg me the output from debconf-show postfix?
* tseng pokes buildLogs
<Kamion> lamont: I'll have to transcribe it, give me a second
<Kamion> no network connectivity on that box
<lamont> Kamion: what exactly is in base-config?  dpkg-reconfigure -pcritical postfix?
<Kamion> -       exec dpkg-reconfigure --unseen-only --default-priority postfix
<lamont> and after the user gets added, yes?
<lamont> is there any way for postfix to know that debootstrap is why it
<lamont> s being configured?
<Kamion> well after the user gets added
<Kamion> why does it need to know?
<Kamion> I don't understand why these problems exist
<Kamion> I also don't understand why you think dpkg-reconfigure might help given that everything of any interest in postfix.postinst is guarded by != "No configuration"
* lamont thinks that the question was "seen" during debootstrap - at least enough to set the default...
<lamont> postfix's config/postinst is being too smart for itself, I fear.
* lamont will ponder.
<Kamion> I still don't understand; when I took that question out, it was partly because I looked through postfix.postinst and concluded that reconfiguring it was an absolute no-op
<Kamion> questions in debootstrap rarely get the seen flag set, but they may get their value set
<lamont> it may be...  But I think it shouldn't be a no-op. :-(
<Kamion> the former is a bug currently assigned to me
<Kamion> lamont: I can do another install and get you debconf-show before the reconfiguration, if you like
<lamont> that would be great
<lamont> and then I shall ponder. :-(
<lamont> but in the meantime, I'm going to wander off to the shower for a bit
* netjoined: irc.freenode.net -> sendak.freenode.net
* netjoined: irc.freenode.net -> sendak.freenode.net
<T-Bone> ouch
<T-Bone> happy netsplit
<Kamion> only two of you
<npmccallum> fabbione: ping
<T-Bone> lamont: would it be normal that i don't get any input in glibc's build log for 25 minutes?
<daniels> is hoary open for uploads?
<elmo_> t-bone: in the test suite, it's possible yes
<elmo_> daniels: no
<daniels> elmo_: 'kay
<T-Bone> elmo_: ok, it's actually in the test suite
<elmo_> hoary doesn't really exist in katie, if you try, you'll probably make her cry
<fabbione> npmccallum: pong
<daniels> elmo_: er, stress-testing crucial infrastructure?
<elmo_> daniels: ?
<npmccallum> fabbione: can you take a look at bug #1753?  I'm not that familiar with Xcursors
<daniels> elmo_: by uploading stuff targetted at hoary
<daniels> npmccallum: is it about a solid black X staying on screen?
<npmccallum> daniels: no
<daniels> oh
<elmo_> daniels: no, it's just half-configured I mean
<daniels> npmccallum: that's just a case of bad theming, though
<fabbione> npmccallum: no idea what it can be, but i am sure it's not an X bug
<daniels> npmccallum: there's nothing actually wrong, it's just that someone needs to draw a better cursor
<daniels> fabbione: it's the cursor being inconsistent in the actual theme, not our bug
<npmccallum> fabbione: I'm pretty sure that that X cursor theme comes packaged with X, no?
<fabbione> npmccallum: no
<daniels> npmccallum: ehm, I think in this case, no
<daniels> the jimmac cursors are provided by gnome iirc
<npmccallum> what format are the cursors in?
<daniels> erm
<daniels> probably xpm or some obscure crap
<daniels> they're generated from png iirc
<T-Bone> elmo_: Is the box being idle, and ps show "ld-linux-ia64.so.2 --library" for the same amount of time to be also considered as "normal"?
<T-Bone> +ing
<T-Bone> lamont: i'll need your glibc deb. My build is stuck for good
<npmccallum> daniels: man xcursor
<npmccallum> daniels: x cursors are their own format, no mention of how to convert them
<daniels> npmccallum: xcursorgen
<npmccallum> daniels: is it in the archive?
<daniels> should be, yah
<npmccallum> daniels: nevermind :)
<npmccallum> daniels: its installed with X I believe
<daniels> probably, yeah
<daniels> just like half of the rest of the archive
<daniels> any linux distribution is comprised of stuff installed from x, ooo's i18n, and miscellany
<npmccallum> lol
<npmccallum> daniels: what does cursor size mean? number of pixels?
<daniels> yep
<daniels> 32x32, 64x624, et al
<mdz> lamont: that's the powerpc-random-segfault thing?
* lamont tries to figure out how to fram Gilder
<lamont> mdz: yeah
<lamont> s/segfault/SIGILL/
<lamont> mozilla made it through on try #3. :-(
<mdz> lamont: that one seems like it is, er, still open
<mdz> considering it makes our powerpc builds fail?
<lamont> mdz: yeah.  it's still a bug.
<lamont> although we have a workaround. :-)
<pitti> Hi mdz!
<mdz> lamont: the work around being...you? :-)
<mdz> pitti: morning
<lamont> mdz: nah - the autodepwaiter just retries anything that was 'terminated by signal 4'. :-(
<lamont> although that didn't seem to be working with mozilla...
* lamont has no ppc box to test/debug it on, however.
<pitti> mdz: if you have a minute, can you please take a look at #1864?
<mdz> lamont: I've never seen it on the G4
<mdz> lamont: maybe it's a G5 thing...I think justdave has one
* Kamion has never seen it either, but voltaire suffers from it and it isn't a G5
<thom> mdz: can i upload firefox (#1790) ?
<mdz> thom: isn't "move to dpatch" just a tiny bit intrusive to change the user-agent string? :-)
<mdz> or is dpatch only used for that one patch?
<daniels> heh
* Kamion ponders releasing sounder 9 before or after parted fix, concludes after might be better ...
<mdz> anyone here have an i386 system with >=2GB of RAM?
<thom> mdz: no, it stops me having to juggle about 8 patches to the default firefox, plus our branding. it's a huge time saver, and much *less* intrusive than, say, moving it to DBS
<thom> ;-)
<thom> 1GB is the most i have
<Kamion> would amd64 do? I have == 2GB there
<Kamion> hm, no, I don't, only 1GB
<daniels> thom: nah man, DBS is love
<thom> *g*
* azeem thought quilt was pretty nice, when I was forced to use it
<daniels> thom: anything you're after a co-maintainer for? :)
<mdz> thom: if you've rediffed it and checked that no regressions were introduced by the dpatch conversion, it's ok by me
<thom> daniels: sure, but nothing i'm letting you choose the packaging system for
<thom> mdz: yeah, i have
<thom> several times
<daniels> thom: heh
<thom> actually, i'll leave it till tomorrow to upload, since i'm just about to install a new mobo
<npmccallum> daniels: Is the cursor mentioned in that bug hardwired to X?  I can't seem to change it
<mdz> npmccallum: you have an i386 box with >=2GB RAM, right?
<daniels> npmccallum: not at all
<npmccallum> mdz: no, >=1GB ram
<npmccallum> daniels: do you know which image actually changes that cursor?  I assumed "cross", but nothing happens when I add it and restart...
<daniels> npmccallum: ehm, not really sure off the top of my head, sorry
<npmccallum> daniels: none of the themes actually change that cursor
<daniels> it looks non-core to me
<npmccallum> it certainly does...
<sladen> npmccallum/daniels: is the plan to replace the default X cursor with a completely transparent one?
<daniels> ... *completely*?
<daniels> as in, invisibl
<daniels> e
<npmccallum> sladen: actually we are just going to remove mouse support from X :)
<sladen> daniels: yeah, without reading the scrollback, I wondered if it might be a kludgy solution for cards where the hardware cursor isn't being used, but the default cursor is still loaded and left bang in the centre of the screen
<npmccallum> sladen: see bug #1753
<daniels> sladen: ow, dude, my head
<daniels> core cursors don't have an alpha channel, anyway
<daniels> (iirc)
<sladen> daniels: presumbly their two-bit.  One black/white map;  and one transparent/opaque map ?
<daniels> i can't remember
<daniels> .
<mdz> Mithrandir: can you try backing out to an older/simpler kernel or anything, regarding that futex bug?
<mdz> Mithrandir: none of the userland programs involved have changed in several weeks
<elmo_> we're still shipping wth 2.6.9 right?
<elmo_> err 2.6.8
<daniels> elmo_: 2.6.8.1
<elmo_> right
<elmo_> why does our apt-listchanges read changelogs if it's not going to bother displaying any of them?
<elmo_> or does "Reading changelogs" actually mean "Reading changelogs and news" ?
<mdz> elmo_: the latter
<pitti> mdz: re 1864: yes, this libsg is just a subdirectory of cdrecord, it's not actually a shared lib. I will upload this thing, thanks for approving it
<daniels> pitti: what are you doing to libscg?
<pitti> daniels: #1864
<pitti> daniels: I added a patch which opens the burning devices exclusively
<daniels> hm
<pitti> daniels: this avoids interference with hal
<daniels> be very, very careful wrt licence
<pitti> daniels: oh? it should be DFSG, not?
<daniels> half of libscg is 'you may not breathe on this without adding "schily is god, all hail schily" prominently' all through it
<daniels> pitt	ish
<mdz> pitti: by the way, if you want to operate on a Debian bug in bugzilla, just tell me and I can import the bug itself with all comments
<pitti> daniels: wasn't xfree 3.5 rejected because of this particular reason?
<daniels> pitti: libscg requires you to change version on modification
<pitti> mdz: ah, I forgot that again. Next time :-)
<mdz> daniels: didn't you close that bug saying that our version was old enough that it didn't have the evil problems?
<daniels> pitti: xfree86 4.4 was rejected because you were required to do advertising in documentation
<pitti> daniels: okay, then I will add an ubuntu branding. mdz, is that okay for you? (trivial patch)
<daniels> mdz: there's a difference between utter crap and non-dfsg-free
<daniels> pitti: do you want to let me handle this in the morning?
* lamont goes off to ponder postfix, and maybe get girls from school in a couple hours and such.
<daniels> mdz: since 2.0, libscg has required you to change versions if you change certain parts of it
<mdz> daniels: what matters is whether or not it meets the Ubuntu guidelines; does it?
* lamont will also ponder breakfast
<daniels> mdz: very recently, it was changed to actually violate the licence quite blatant
<daniels> ly
<daniels> we're unaffected by the latter
<daniels> mdz: yes, but it's still obnoxiously crap
<pitti> daniels: if you mean that you want to change the version string, for my sake yes
<daniels> it meets the dfsg, dude
<daniels> pitti: i'd just be a little more comfortable if I handled it
<mdz> pitti: if you need to change the version string, that's fine
<daniels> mdz: essentially, yes
<pitti> daniels: okay, I send you my current interdiff, you mangle the version string and upload. Okay?
<daniels> pitti: sure
<pitti> daniels: I attach the interdiff with a comment to the bug and add you as CC
<daniels> pitti: awesome, thanks
* pitti just finished installation of today's ppc daily
<pitti> Guys, the current installation is AWESOME!
<Kamion> kewl :-)
<pitti> Kamion: the therm_adt746x module is still not loaded automatically on ppc; I have to reopen #1606 :-(
<Kamion> pitti: which image?
<pitti> Kamion: today's daily
<Kamion> pitti: please include a tarball of /proc/device-tree
<pitti> Kamion: anything particularly wrong with that?
<Kamion> shouldn't be
<pitti> Kamion: I'll do
<Kamion> so it's not in /etc/modules?
<pitti> Kamion: no, not in /etc/modules and not loaded
<Kamion> note that it won't be loaded in the installer environment, hope you weren't expecting that
<pitti> Kamion: no, installation is finished, gnome runs
<Kamion> ok
<daniels> hooray -- we've actually been violating the cdrecord licence for a whlie
<mdz> Kamion: what's the status of sounder 9?
<daniels> pitti: ok, you've got an updated #20 dpatch back; my builds are being really weird for some reason
<daniels> 0505 is bedtime, however
<elmo_> Setting up gnome-panel-data (2.8.0-0ubuntu5) ...
<elmo_> We're a laptop
<elmo_> laptop configuration
<elmo_> is that considered a featuree?
<mdz> apparently so
<mdz> there's an explicit echo in postinst; presumably for debugging
<elmo_> k
<T-Bone> gack, perl is still failing :P
<Kamion> mdz: if you don't want me to put the parted fix into it (I had been thinking about doing that to force wider testing), it can go out as soon as I test all three arches
<mdz> Kamion: hmm, sounds risky for a milestone release at the last minute
<mdz> Kamion: maybe push out sounder 9, and then drop new parted onto the daily CDs?
<Kamion> well, I wonder how much point there is doing sounder 9 if we really want people to use the dailies
<Kamion> I've got a Windows XP CD now and am installing using it to see if I can reproduce the problem myself
<Kamion> (current amd64 works, BTW)
<T-Bone> looks like there's a circular dep in gcc-3.3 ubuntu:
<T-Bone> gcc-3.3: Depends: libgcc1 (>= 1:3.3.4-3) but 1:3.3.4-2 is to be installed
<mdz> Kamion: we need to have a "last known good" thing to point people to for the download link on the websit
<mdz> Kamion: so that they don't download a broken CD
<Kamion> T-Bone: libgcc1 comes from gcc-3.4
<T-Bone> according to the .dsc, the package gcc-3.3 provides libgcc1
<Kamion> $ madison -s warty -S gcc-3.4
<Kamion> ...
<Kamion>    libgcc1 | 1:3.4.2-2ubuntu1 |         warty | amd64, i386, powerpc
<T-Bone> Kamion: nope, see http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-3.3/gcc-3.3_3.3.4-9ubuntu5.dsc
<Kamion> the .dsc is not always reliable for such things
<T-Bone> hmm
<T-Bone> so gcc-3.3 is borked ?
<Kamion> not really
<Kamion> the newest binary is taken
<Kamion> build gcc-3.4
<T-Bone> how am i supposed to install gcc-3.3 then?
<Kamion> by building gcc-3.4?
<T-Bone> btw, i got this while trying apt-get install build-essential
<Kamion> this sort of thing happens during bootstrapping :)
<T-Bone> yeah
<T-Bone> gonna have to bastardize my chroot a bit more :P
<T-Bone> shit i fucked up my chroot
<T-Bone> Checking correctness of source dependencies...
<T-Bone> After installing, the following source dependencies are still unsatisfied:
<T-Bone> libgtk2.0-dev(inst 2.4.3-1 ! >= wanted 2.4.4-2)
<T-Bone> Kamion: that's why i couldn't build it the first time alas
* T-Bone finds a workaround
<pitti> Since very recently ago, I repeatedly see messages like "tar: Read 2560 bytes from -"; does anybody else have this problem?
<T-Bone> awesome
<T-Bone> i can't build gcc-3.4. It build depends on gcc-3.3 ubuntu which i can't install for the above mentionned reason
<T-Bone> i'm looking for some help there...
<pitti> sjoerd: I'm just uploading a new cdrecord with O_EXCL. Thanks for the hint!
<mdz> pitti: yes; seems fairly harmless
<pitti> mdz: the tar message?
<mdz> pitti: yes
<mdz> I've seen them for some time, in Debian as well
<sjoerd> pitti: nice
<mdz> pitti: ask bdale
<pitti> sjoerd: I will send the patch to the Debian BTS
<mdz> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264050
<sjoerd> pitti: :)
<pitti> mdz: thanks
<Kamion> ew! WinXP's installer has a bloody Clippy-a-like!
* mdz comforts Kamion
<Keybuk> MS Bob ... the software that just won't die
<Keybuk> http://toastytech.com/guis/bobwriter.gif
<T-Bone> can somebody please educate me about how to override builddeps with sbuild? I have tried various combinations of -f and -b and can't find the solution :P
<T-Bone> s/-b/-a/
<mdz> Kamion: do you have a sounder 9 candidate for me to download and test?
<mdz> T-Bone: sounsd like you need lamont
<mdz> he should be around
<T-Bone> mdz: yeah, unfortunately he's very busy atm
<T-Bone> i'm stuck with that gcc-shit before being able to go over stage 2 (building warty against warty binaries)
<seb128> jdub: just checking, but that's still ok for GNOME point releases (epi 1.4.1 and evo/eds/... 2.0.1) ?
#ubuntu-devel 2004-10-10
<jdub> seb128: yes, thanks
<seb128> np
<jdub> check if they're sane, of course ;)
<jdub> but the current releases look ok
<seb128> jdub: ah, and a guy asked for a gmane archive of ubuntu-fr, I guess that's ok ? :)
<seb128> don't worry, for big package I run them one day one my box before uploading most of the time
<seb128> or at least time to reboot and make basic tests
<jdub> seb128: i think it's already on gmane
<jdub> some dude mailed me to say some of the posts were missing ;)
<seb128> oh, ok, cool :)
<seb128> 37 people on the -fr list, that's a good start :)
<jdub> cool
<jdub> you are beating spain and germany ;)
<seb128> he he
<mdz> Kamion: still here?
<lamont> T-Bone: you modify the source...
<T-Bone> this is what i did, eventually ;)
<T-Bone> unfortunately gcc takes _time_ to build
<lamont> but build deps get dealt with early...
<lamont> Rejected: file 'linux-686-smp_2.6.8.1-10_i386.deb' has invalid priority 'restricted/optional' [contains '/'] .
<lamont> sigh
<Kamion> mdz: current daily is candidate
<mdz> Kamion: ok, I'll download and test
<Kamion> you can probably make amd64 your bottom priority, I've tested that
<mdz> lamont: can you and/or elmo arrange for those messages to go someplace useful?
<lamont> mdz: will do
<mdz> lamont: warty-changes should be a reasonable place
<lamont> you want all REJECT mail to go there?
<mdz> yes, unless there's a bunch of spam I don't know about
<Kamion> hm, WinXP boots for me after installing Ubuntu
* Kamion wonders what the variable is
<lamont> mdz: all katie mail that would have gone direct to me now goes to warty-changes.
<mdz> lamont: thanks much
<mdz> lamont: new linux-meta happier?
* lamont checks
<jdub> WHOA NEW EXCITING KERNEL TO INSTALL
<lamont> mdz: give it 2.6 minutes.
<mdz> jdub: new exciting sounder CD candidate to test
<lamont> either warty-changes should get the reject mail shortly after 16:10 your time,
<jdub> sweeet
<Kamion> i386 WFM
<lamont> or the new linux-meta -11 package will hit the archive at 16:33
<mdz> ran out of disk space, restarted rsync
<Kamion> heh
<Kamion> disk is cheap :)
<mdz> yeah, but adding disks is not
<Kamion> just testing daily+new-parted for good measure, even though I can't reproduce the problem with old-parted
<mdz> all my disk is being eaten by mythtv
<jdub> mdz: btw, what's the status of mythtv in sid or universe?
<Kamion> Free  PE / Size       14499 / 56.64 GB
<jdub> Kamion: what was the package update cutoff point for the new sounder?
<azeem> did you guys see the latest gnoppix announcement?
<mdz> jdub: waiting for elmo to bring in lame
<Kamion> jdub: about 1300 GMT or something
<azeem> "You'll find a new 0.8.1beta ( codename Ubuntu ) with bugfixes and Gnome 2.8 at: ftp://194.94.72.226/linux/gnoppix/gnoppix_0.8.1b4.iso"
<jdub> mdz: "oh."
<jdub> azeem: haha
<jdub> Kamion: cool, ta
<jdub> mdz: so the non-free universe is still going to be called 'multiverse'?
<jdub> we *so* need livecds for testing :|
<jdub> mdz: i punted alex bugging to you, btw.
<mdz> jdub: noticed, followed up
<jdub> cool
<azeem> perhaps gnoppix is the first case of a CUD, as opposed to CDDs
<jdub> azeem: it is all in the CDD family :)
<Kamion> jdub: actually later than that
<Kamion> cjwatson@little:~$ head -n 2 cdimage/log/daily-20040928.1.log
<Kamion> ===== Syncing Ubuntu mirror =====
<Kamion> Tue Sep 28 15:55:48 BST 2004
<jdub> azeem: but yes, CUD explosion is very much in the plans ;)
<azeem> I talked to amu about gnoppix for quite a while at LinuxTag, and he said they entirely repackage GNOME for gnoppix. Perhaps now with ubuntu he finally got driven to sanity :)
<mdz> mako: will there be an ubuntu traffic coming soon?
<mdz> Kamion: what do you think we should do about #1608 (some CD-ROM drives screw up DMA)?
<mdz> Kamion: disabling DMA on all CD-ROM drives seems awfully heavy-handed, but it's simple and safe to implement
<Kamion> there was a bug in Debian about this ...
<Kamion> I think
<Kamion>   * Osamu Aoki
<Kamion>     - When CD mount fails, unmount it and try again, to work around DMA
<Kamion>       issues. Closes: #255128
<Kamion> that was an error on mount, though
<sabdfl> Kamion: ok, nothing in the syslog about firmware loading
<Kamion> mdz: killing DMA on failure works for me, don't like the idea of doing it unconditionally
<Kamion> sabdfl: have you run the hw-detect stage yet?
<sabdfl> Kamion: interesting, detect hardware comes after configure network
<sabdfl> but even after jumping through it, nothing about the firmware load
<Kamion> sabdfl: um ... configure the network definitely has a higher menu-item-number than detect network hardware
<Kamion> sabdfl: ok, well, it was untested code, guess it doesn't quite work :-/
* T-Bone hopes to start ia64 stage2 by tomorrow, calls it a night in the meantime
<Kamion> mdz: didn't you have an ipw2100 you could play with too?
<sabdfl> T-Bone: wow, good progress?
<sabdfl> Kamion: on my system it is showing:
<sabdfl> ...
<sabdfl> Load installer components from CD
<sabdfl> Detect network hardware
<sabdfl> Configure the network
<Kamion> that's not what you said above ...
<Kamion> 00:27 < sabdfl> Kamion: interesting, detect hardware comes after configure network
<sabdfl> then
<sabdfl> Detect hardware
<Kamion> oh, that's detect disks
<sabdfl> nice :-)
<sabdfl> "configure the network" shows the wifi card
<Kamion> should fix the string there
<Kamion> Template: debian-installer/hw-detect-full/title
<Kamion> Type: text
<Kamion> #  Main menu item
<Kamion> _Description: Detect hardware
<sabdfl> but it doesn't seem to work
<sabdfl> still, it's not screaming spam log messages :-)
<sabdfl> to console
<T-Bone> sabdfl: i'll post the m-l as soon as i start "stage2" (ie: building warty main against warty binaries, stage1 was building warty main against debian binaries)
<T-Bone> sabdfl: this should hopefully happen tomorrow
<sabdfl> awesome
<Kamion> sabdfl: guess it just egregiously failed to load firmware then. does that machine have PCMCIA?
<sabdfl> yes
<sabdfl> can i force a firmware load?
<Kamion> I hacked the firmware loading stuff onto the side of PCMCIA, which is kind of broken but I figured would work for now
<mdz> Kamion: I have only a 2200
<Kamion> not sure; mdz, do you know?
<Kamion> mdz: that would do
<mdz> Kamion: I'm not sure that there's a condition we can detect to automatically disable DMA
<T-Bone> sabdfl: another that should happen soon is my beginning to work on the installer for ia64. probably before the end of the week, or in the worst case next week
<mdz> you can force a firmware load by loading the driver
<T-Bone> +thing
<Kamion> chinstrap:~cjwatson/warty-i386-hacked.iso if you want to give this a go, no firmware on that image so you'll have to bring it in by USB stick or whatever
<sabdfl> mdz: already did that, but nothing showed up in syslog
<Kamion> T-Bone: give me a shout if you need help, some ia64 love with the Ubuntu customizations will be needed
<T-Bone> Kamion: that's noted, and I will undoubtly bother you alot ;)
<mdz> sabdfl: it doesn't log anything when it's successful
<Kamion> mdz: it so does
<mdz> mine doesn't
<Kamion>                         log "Firmware for $FIRMWARE loaded successfully."
<Kamion> mdz: it does in d-i
<T-Bone> sabdfl: side note, i've started "for fun" an hppa builder. But that's "for fun". For now ;)
<Kamion> sabdfl: what's in /proc/sys/kernel/hotplug at the moment?
<mdz> Kamion: oh, that
<mdz> I'm pretty sure it loads the firmware every time the ipw2200 module is loaded
<sabdfl> it says /sbin/hotplug
<mdz> aha
<mdz> shouldn't that be /sbin/hotplug-special-d-i-variant?
<sabdfl> which doesn't exist
<mdz> I think it's hotplug-pcmcia
<sabdfl> neither of those exist
<Kamion> the special d-i variant is /bin/hotplug-pcmcia, and that's only loaded for brief periods while the PCMCIA queue is run
<Kamion> I think that's probably the bug
<sabdfl> can i reset that and try to reload the driver?
<Kamion> there's no rmmod in d-i, you'd have to reboot
<mdz> ewww
<sabdfl> oooookkkkkkk
<T-Bone> that's probably the biggest pain in d-i, actually
<sabdfl> i really need to spend some face time with my launchpad code
<Kamion> sabdfl: after reboot, you could try copying /bin/hotplug-pcmcia to /sbin/hotplug and removing the non-firmware parts (since I think those will have unintended side-effects if run with non-PCMCIA)
<Kamion> sorry for awkwardness, will clean it up once an approach has been demonstrated to work
<mdz> Kamion: I did this experiment a while back; it does work
<mdz> if I poked all the bits in the right places, the firmware was loaded
<Kamion> mdz: in d-i?
<mdz> Kamion: yes
<Kamion> mdz: is your ipw2200 card PCMCIA?
<mdz> Kamion: no
<mdz> miniPCI
<Kamion> mdz: then you must have had to set up /sbin/hotplug?
<Kamion> or possibly make /bin/hotplug-pcmcia the hotplug handler temporarily
<mdz> Kamion: I did echo /bin/hotplug-pcmcia > /proc/sys/kernel/hotplug or whatever
<Kamion> aha
<mdz> that was one of the bits that needed poking :-)
<Kamion> how about I create a hotplug-misc which sits in /sbin/hotplug for the rest of the time, then?
<Kamion> we don't have time to port proper hotplug now, will be doing that for hoary
<mdz> sounds fine to me
<sabdfl> what are the non-standard firmware parts
<Kamion> patch is trivial, I'll upload if there are no objections
<Kamion> non-standard?
<sabdfl> your comment above... remove the "non-firmware parts"....
<sabdfl> sorry, not non-standard, non-firmware
<sabdfl> so i've got the firmware in /lib/firmware and /usr/lib/hotplug/firmware for good measure
<Kamion> network events and cardbus events
<mdz> Kamion: is #1586 RC for Warty?
<sabdfl> i've echo >/bin/hotplug-pcmcia /procy/sys/kernel/hotplug
<mdz> Kamion: no objections to having an /sbin/hotplug
<jdub> Kamion: sounder + current daily are the same today?
<Kamion> mdz: it's RC for me to look at it at the very least
<sabdfl> now can i just modprobe the ipw2200?
<Kamion> I just haven't had time :(
<sabdfl> what about the depmod?
<Kamion> if modprobe doesn't work then depmod ...
<Kamion> the build was hacked-up, hopefully shouldn't act that way if built normally
<sabdfl> FATAL: module ipw2200 not found
<Kamion> jdub: aye, not that I've actually blessed S9 yet
<sabdfl> ok, now:
<Kamion> burning powerpc now, I've tested the others
<sabdfl> hotplug pcmcia says it detected pcmcia network interface eth0
<sabdfl> then ieee80211_crypt gets loaded
<sabdfl> then the driver comes on stream
<sabdfl> but says nothing about firmware being loaded
<sabdfl> ah, hold on this is interesting
<Kamion> 00:51 < sabdfl> i've echo >/bin/hotplug-pcmcia /procy/sys/kernel/hotplug
<sabdfl> if i dmesg i see a message at the end:
<Kamion> hope the position of the > there was a typo
<sabdfl> Kamion: yes it was, that's all correct afaics
<Kamion> ok
<sabdfl> but listen to this
<jdub> Kamion: cool, thanks
<sabdfl> it says "Radio frequency kill switch is on"
<sabdfl> which was also in the syslog
<sabdfl> then it says:
<sabdfl> Kill switch must be turned off for wireless networking to work"
<sabdfl> hmm
<mdz> that'll be the wifi button/switch on the laptop somewhere
<Kamion> +To determine if you have such a switch, you can check the contents of:
<Kamion> +
<Kamion> +       /proc/net/ipw2100/eth1/state
<sabdfl> i don't have /proc/net/ipw2100
<sabdfl> this is a 2200
<Kamion> probably same difference
<hazmat> is there a formal mechanism to suggesting a package for inclusion in ubuntu?
<Kamion> or maybe not, the ipw2200 driver's /proc-handling code seems different, oh well
<lamont> Kamion: is there an option to debootstrap to tell it that the archive is not in a {dists,pool} form?
<mdz> hazmat: email to ubuntu-devel
<hazmat> okay.. thanks.
<Kamion> lamont: debootstrap couldn't care less about pool, it uses Filename: fields
<lamont> it cares about Release, though. :-(
<Kamion> lamont: it does indelibly want dists/$SUITE/Release
<lamont> which needs to have the packages md5sums?
<Kamion> and dists/$SUITE/$COMPONENT/binary-$ARCH/Packages*
<Kamion> right
<lamont> ok
<Kamion> I usually just fill the right values into the Release file from whatever CD image I have handy
<mdz> sabdfl: /sys/bus/pci/devices/xxxx/rf_kill
<mdz> seems like the right place
<sabdfl> mdz: just found it too
<sabdfl> using the fn-f8 sequence doesn't seem to affect that
<Kamion> 00:51  * joeyh notices we just got ntfsresize support
<mdz> nice
<sabdfl> BUT i can echo 1 > /sys/..../rf_kill
<sabdfl> or vice versa
<sabdfl> will play with that
<mdz> I don't think my laptop has a switch; the sysfs flie says 0
<mdz> several of the test laptops in oxford had switches
<mdz> some of them in unlikely places
<mdz> Kamion: I think we need to change the default sources.list again
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=1469
<mdz> should have one line with main and restricted
<mdz> and then another line, commented out, with only universe
<Kamion> I thought I already fixed that
<mdz> oh?
<mdz> I'll find out soon, doing a new install
<Kamion> it was part of the universe changes a couple of days ago
<Kamion>   * Remove 'main restricted' from the universe line, so people don't end up
<Kamion>     with duplicate sources.list entries.
<sabdfl> cunnin
<sabdfl> g
<sabdfl> the switch was well hidden, in the off position
<sabdfl> WELL hidden
<sabdfl> Kamion: please could you file a bug to detect those rf-kill switch situations, and alert the user, because i *bet* a lot get bitten by that
<mdz> Kamion: oh, ok
<mdz> you even updated the bug
<mdz> oh, you did that just now. cheat :-)
<Kamion> yes :)
<lamont> sabdfl: if you configure postfix, edit main.cf, and say 'dpkg-reconfigure postfix', do you (a) expect it to overwrite your changes, or (b) preserve them? (for questions that we ask in configure, that is)
<Kamion> sabdfl: ok
<sabdfl> lamont: it's too late for me to give you a reliable answer to that :-)
<lamont> sabdfl: ok.  something to ponder in the morning then?
<sabdfl> perhaps it should figure out you've made changes, offer to (a) show you a diff, (b) forget about it, (c) forge ahead
<sabdfl> and backup the old config?
<lamont> today we preserve them.  which is why postfix is broken (see 1711)
<Kamion> sabdfl: sounds like ucf
<lamont> that'd be ucf
<lamont> what postfix actually does is to set the defaults to what you have configured currently.
<lamont> so that hitting return all the way through produces no change.
<sabdfl> that's pretty neat
<lamont> and then debconf and base-config run: debconf does the wrong things because we haven't set things up yet, and base-config does nothing because the defaults are all what you said in debootstrap  time...
<mdz> elmo: PowerEdge 2650 is on the HardwareSupport page, but without a comment about whether it worked.  did it?
<mdz> elmo: we have a success report from a user on one
<lamont> sabdfl: neat, but breaks ubuntu install of postfix
<jdub> http://www.es.gnome.org/~telemaco/
<jdub> ^ :-)
<Kamion> lamont: the debconf/debootstrap fix would work around this, AIUI ...
<Kamion> I worked out the problem with my earlier change after talking to joeyh; I'd just implemented noninteractive multiselect wrong
<lamont> ah, ok.  that was the default vs seen thing?
<Kamion> trying to get debconf to set the seen flag on questions that would be asked if the frontend weren't noninteractive
<Kamion> my earlier fix caused all systems to have the aa_DJ locale configured
<Kamion> didn't upload that one :)
<sabdfl> WOOHOOO!
<sabdfl> custom install just went all the way through with wifi on ipw2200 and just worked
<lamont> Kamion: it would be nice if debootstrap would accept Packages.gz in place of Packages. :-(
<mdz> messages read in 2004-08: 6288, messages read so far in 2004-09: 13296
<sabdfl> actually, that's fnny
<mdz> I was wondering why it took mutt so much longer than usual to open this month's read-mail folder
<sabdfl> during the pre-boot it configure eth0 (wired)
<sabdfl> then it rebooted, and ifup'd the wifi
<sabdfl> which Just Worked
<mdz> sabdfl: I guess you got lucky and the ipw2200 is later on the pci bus
<sabdfl> no, it's earlier
<mdz> really?
<mako> mdz: it's almost done
<mako> mdz: UT taht is
<sabdfl> pre-boot, it didn't detect it, and configured eth0 (wired) for dhcp
<lamont> mdz: where'd you get that stat?
<mdz> mako: cool, that's a ton of mail to process
<mdz> lamont: bzgrep -c '^From '
<lamont> heh
<mako> ~17k messages :)
<sabdfl> then post-boot, the kernel finds ipw2200 and makes that eth0
<sabdfl> but now, with the rf_kill switch on, it actually boots
<mdz> oh, heh
<sabdfl> so the solution to the bug is turn off the rf_kill, or turn on the radio
<mdz> so it wrote a config for eth0 for the wired net
<mdz> and then used that config for the wireless?
<sabdfl> yes
<sabdfl> which just worked
<mako> the friday-friday stat is 17k
<mako> it's picked up
<sabdfl> interestingly it doesn't need the essid
<mdz> mako: 17k what?
<sabdfl> it seems to just go with the closest / best ap
<sabdfl> dhcp
<sabdfl> and go
<mako> ergh.. 1.7k
<mdz> sabdfl: the 0.8 driver grabs whatever has the strongest signal if it's set to scan
<mako> decimal error
<sabdfl> hmm...
<mako> 1.7k mesasges
<sabdfl> i'll update the bug,and file upstream
<sabdfl> holy crap you guys need a more time-efficient sabdfl
<Kamion> sabdfl: kill-switch bug is #1877
<sabdfl> i can't belive i spent two whole nights on this at this stage :-)
<mako> sabdfl: i'm just going through user now and picking up the last few threads i flagged for possible inclusion
<mako> ergh.. for mdz
<sabdfl> but it feels good to find the bug ;-)
<sabdfl> possible inclusion?
<mako> sabdfl: don't worry about it, it was misdirected
<sabdfl> mako: btw, thanks for the lurker tip
<sabdfl> http://lists.ubuntu.com/lurker/
* mako nods
<mako> awesome
<mdz> sometimes I want to strangle the genius at apple who eliminated the cd-rom eject button
<mdz> the system is powered off, and I want to boot it from CD
<mdz> I have to boot it up, software-eject the CD, and then reboot it
<m_tthew> mdz: or have the always-useful paperclip handy.
<Kamion> you mean you want to boot it from a different CD from the one already in the drive?
<mdz> m_tthew: they even put a door in front of the thing, making the hole difficult to get to (it's below the lip)
<mdz> Kamion: the drive is empty, and I want to put in a CD and boot from it
<Kamion> oh your drive isn't slot-loading
<mdz> correct
<Kamion> mdz: try 'eject cd' in Open Firmware
<mdz> it's a tray with a door in front of it
<m_tthew> mdz: a door? ugh
<mdz> ah, I'll keep that in mind next time
<Kamion> then mac-boot
<Kamion> never tried this myself but it's what the net claims
<jdub> is ndiswrapper in the current -3 kernel?
<Kamion> mdz: one rumour claims holding down the left mouse button during boot also ejects the CD ...
<mdz> ooh, DMA is working on the hard disk now
<mdz> I didn't think that was working before
<sabdfl> bummer
<mdz> jdub: yes it is
<sabdfl> mdz: you won't believe this
<sabdfl> with hotplug setup, and the firmware there
<sabdfl> the installer sees the wifi and lets you use it
<Kamion> hey, warty-powerpc.iso burnt, time to reboot and try this stuff out myself
<sabdfl> but it configures it as eth1
<mdz> Kamion: i386 and powerpc in progress now
<sabdfl> i suspect, after reboot, it will be eth0
<sabdfl> why?
<mdz> discover vs. hotplug
<sabdfl> could it be because discover ran first?
<sabdfl> argh.
<mdz> discover must scan in a different order
<mdz> maybe even exactly the reverse; wouldn't that just be grand?
<sabdfl> well, discover goes first, doesn't find the wifi
<mdz> sabdfl: give it a try; it really should preserve them
<sabdfl> then hotplug could go, and find it
<sabdfl> ifrename?
<mdz> if they're both detected in the installer, ifrename should be able to do its job
<sabdfl> ok
<mdz> check that they're both in /target/etc/iftab
<sabdfl> kamion, this is looking good to me (hotplug)
<sabdfl> mdz: yes
<mdz> hmm, so let's just switch d-i over to use hotplug exclusively, shall we?
* mdz runs for cover
<sabdfl> mdz: you can stay. you've clearly got the cohones for the position :-)
<sabdfl> mdz: (also, you're ifrename magic seems good so far, they are both in there)
<mdz> in theory, when hotplug finds them after the reboot, it'll look in that file and switch the name before bringing it up
<mdz> so it'll find the wifi first, but call it eth1, then find the wired and name it eth0
<sabdfl> we'll see in about 15 minutes :-)
<mdz> this may be the first valid test of that code, ever :-)
<mdz> that was an "oh, look, all the bits are already there, we just need to write iftab and it'll work" sort of job
<sabdfl> so if it works this time, we ship it?
<sabdfl> duck
<sabdfl> well it wrote iftab
<mdz> i386 stage 1 successful
<mdz> gah, 12M of updates on top of the daily CD already
<sabdfl> mdz: do you know which was the bug i filed on the ipw200 loop of death? can't find it
<sabdfl> Kamion: final dialo pre-boot still says "Finishing the installation"
<sabdfl> can it say "Rebooting to finish installation"?
<mdz> sabdfl: #1751
<sabdfl> mdz: thanks
<mdz> jdub: can I get the name and address of the person who tied gnome-system-tools to wvdial, so I can send them a lump of coal?
<jdub> heh
<jdub> you trying to untie them?
<tseng> hi
<jdub> yo tseng 
<Kamion> sabdfl: all depends how many translations you want to trash :)
<Kamion> sabdfl: but sure, can do
<Kamion> mdz: powerpc worked for me, xresprobe apparently hung solid on i386 ...
<Kamion> suspect it's specific to that machine, it's one of the Vias
<Kamion> mdz: incidentally that hold-down-left-mouse-button-during-boot-to-eject-CD trick worked for me too
<mdz> Kamion: I tried it during the reboot for stage 2, but either I was too late, too early, or it didn't work
<Kamion> mdz: shout if i386 works for you
<mdz> <mdz> Kamion: i386 install is a success
<mdz> <mdz> Kamion: powerpc as well
<Kamion> mdz: it's at the same time as you would have to hold down 'c' to boot from CD
<mdz> I'm never sure exactly when that time is, since my monitor switches on and off a few times during the boot and I can't see anything
<mdz> I just hold it down forever
* jdub removes old install cd, inserts new install cd. hrm.
<mdz> I usually end up with about 3 'c's at the prompt by the time I can see again
<jdub> whoa, keymap question
<Kamion> for me there's a clear moment when it switches from black screen to white and starts reading the CD
<jdub> at least ppp is out, that keeps us below quota
<Kamion> jdub: arch, CD date?
<jdub> i386, today
<Kamion> oh, you mean in the first stage?
<jdub> yeah
<Kamion> yes, that was deliberate
<Kamion> good, thought you were talking about a bug :)
<Kamion> yes, 'xresprobe via' hangs
<Kamion> I'll file a bug and ship anyway, seems chipset-specific
<mdz> Kamion: hangs during which bit?
<Kamion> mdz: can't tell, it blanks the screen and leaves the system inaccessible
<mdz> Kamion: oh, _that_ sort of hang :-)
<Kamion> the fatal kind :)
<mdz> must be while it's starting the X server
<mako> mdz: around?
<mdz> mako: yep
<mako> can you clarify the conclusion of the universe multiverse thing from the meeting?
<mako> i think i have it but want to make sure i got it right
<mako> and also, is theere no problem with putting that in traffic?
<mako> i'm assuming anything in ubuntu-* is fair game
<mdz> the conlcusion was that non-free/sketchy stuff should go in a separate component, named 'multiverse'
<mako> but it has no connection to origin?
<mdz> yeah, as far as I know it's fair game
<mdz> no connection to the origin: header
<mako> alright, that's what i thought
<mako> fixed conclusions can be hard to get sometimes re-reading irc meetings
<jdub> hrm
<mako> jdub: oi!
<jdub> i should redirect archive.ubuntu.com to my local apt-proxy ;)
<jdub> morning mako
* tseng wonders about making sound-juicer rip multiple formats at once
<tseng> ala abcde
<tseng> checkmarks in the prefs instead of a radio
<jdub> that would be... odd
<jdub> although i grok the reason
<tseng> i use flac at home.. mp3 on ipod
<jdub> zooom
<jdub> nice and fast install on my desktop
<Kamion> mdz: linux-restricted-modules-2.6-386 is uninstallable in the current daily, just noticed
<Kamion> mdz: (I know you've fixed it since then)
<mdz> drat
<Kamion> mdz: do you think I can ignore this, given that it's not used by default yet?
<mdz> the current daily that we just tested for sounder 9?
<Kamion> right
<mdz> oh, it isn't?
<mdz> sure
<mdz> no problem, then
<Kamion> yeah, we use the concrete package currently
<Kamion> ok
<lamont> hrm.. guess the postfix discussion belongs here more..
* lamont wonders if he should notice that the already-existant alias file lacks a root alias and fix that...
<lamont> Kamion: want to look at a diff and comment?
* lamont sends it anyway. :-)
<Kamion> lamont: will have to be tomorrow, sorry
<Kamion> mdz: is the warty-changes list public?
<lamont> Kamion: np. about to sleep here too.
<Kamion> (-ly advertised)
<jdub> Kamion: yes
<Kamion> so I can mention it in the Sounder announcement, then
<jdub> sure
<lamont> oooh... new sounder?
<lamont> kewl
<tseng> sounder?
<lamont> test cd
<Kamion> tseng: will explain on ubuntu-users shortly
<tseng> mmm.
<tseng> thanks
<lamont> sounder is the collective noun for warthogs
<jdub> oink
<lamont> gcc-3.4 is making t-bone's life a pain, and therefore affecting me as well.... sigh.
<lifeless> jdub: thanks for that :)
<jdub> lifeless: you might want to ask edd about the bluetooth ones
<jdub> (wrt imports)
<lifeless> the bluez ones?
<jdub> yeah
<lifeless> ?
<lifeless> oh lol.
<daniels> lifeless: when do I get to announce xorg? :)
<lifeless> daniels: when its cooked.
<mdz> Kamion: yes, warty-changes is entirely public
<lamont> so how do I (1) de-mimeify something, or (2) get a usable patch from bugzilla?
<lifeless> lamont: mimutils
<fabbione> morning
<mdz> Kamion: I thought therm-windtunnel was supposed to be detected and loaded now
<mdz> (wasn't for me)
<fabbione> mdz: permission to upload radvd for 1868
<fabbione> http://people.no-name-yet.com/~fabbione/radvd.diff
<fabbione> diff is here
<fabbione> 2 cosmetic + the real bug fix
<fabbione> cosmetic are 1 typo and add one line to the output (looks better in case o failure)
<mdz> yep, OK by me
<mdz> is ||true more appropriate than --oknodo?
<mdz> I suppose so
<fabbione> mdz: --oknodo has no effect there
<fabbione> already tested
<fabbione> start-stop-daemon will still die
<mdz> I wonder about start-stop-daemon sometimes
<mdz> I expect it to do many things because they are the right thing to do
<mdz> but it simply doesn't
* fabbione knows
<mdz> fabbione: if you run out of RC bugs, I think that kamion and seb128 currently have more than their share and could use an extra pair of eyes
<fabbione> mdz: yes i know.. i keep tracking bugs..
<fabbione> mdz: also the one "assigned" to debzilla ;)
<mdz> there are very few unassigned RC bugs now, and two of them are sort of fuzzy bugs
<mdz> one is tollef's bug that I have no idea about
<mdz> going to get some food, back later
<fabbione> later
<fabbione> make[5] : *** [libglx.a]  Illegal instruction
<fabbione> ops
<daniels> fabbione: ... nice one
<fabbione> that's the ppc buildd on x -8
<lamont> fabbione: Illegal instruction on ppc is something that "just happens".  That is, it's a kernel bug that no one is working on...  Just gotta retry it..
<fabbione> lamont: it still sucks tho :-)
<lamont> yep.
<daniels> isn't that the exec_shield crack?
<lamont> not on ppc
<daniels> ahr
<jdub> daniels: ppc has bugs to do that for you
<daniels> jdub: huzzah
* tseng updates mono and friends
<tseng> the edge gets sharper !
<jdub> ;)
<tseng> cdbs is rock.
<tseng> i replaced the monodevelop rules w/ yours
<tseng> it was doing some nasty stuff.
<hazmat> has anyone noticed that powerbook sleep seems to be broken with the latest iso nightlies ?
<justdave> mine sleeps but I've been having trouble getting it to wake up on occasion
<tseng>  Depends: ${gdi:Depends}, ${wine:Depends}, ${shlibs:Depends}, mono-assemblies-base-${m ono:upversion}
<tseng> what does that mean
<hazmat> hmm.. i saw a few refs to that on the list... i just did an install on a tibook gen4 (ati mobility) wiping an existing gentoo setup.. which did sleep properly (2.4 kernel though).. i'm wondering if its a 2.6.8 kernel regression, i see a few refs to the not waking up issue while googling around in relation to that kernel version 
<justdave> I'm wondering if it's airport card related...
<justdave> there's an error about attempting to access the wireless when the wireless isn't active in the middle of the output it gets on the screen before it hangs
<justdave> and that message isn't there on the times when it wakes up properly
* lamont always thought cdbs was crack
<hazmat> justdave, what powerbook version do you have? 
<justdave> dual USB 500MHz iBook (white)
<hazmat> so its ati radeon mobility (>9100) ?
<hazmat> for the gfx card
<justdave> yeah.
* justdave looks for the actual driver description
<lamont> does apt-ftparchive just run dpkg-scanpackages eventually, or does it do it's own thing?
<fabbione> i think the latter
<tseng> it does the same thing, but its own way i believe
<fabbione> lamont: if you try dpkg-scanpackage and apt-ftparchive on one package you also notice that the output is slightly different
<justdave> ATI RAGE Mobility M3
<fabbione> lamont: like the order of the fields
<lamont> fabbione: ah, ok
* lamont finds a debootstrap bug.  (well, actually it's a warty.buildd bug, but...)
<hazmat> justdave, do you see any ati related error messages on bootup?
<hazmat> i see a few and i'm suspicious since they werent present with gentoo previously..
<justdave> aty128fb: Invalid ROM signature e78c should be 0xaa55
<justdave> aty128fb: BIOS not located, guessing timings
<justdave> aty128fb: Rage128 LF M3 AGP [chip rev 0x0]  8M 128-bit SDR SGRAM (1:1)
<justdave> Registered "ati" backlight controller, level: 15/15
<hazmat> yah.. i have the same invalid rom sig line with atiradeonfb
<daniels> apparently these suspend problems could well be caused by radeonfb
<daniels> huzzah!
<hazmat> it could be a red herring.. but i'm suspicious
<hazmat> http://www.mail-archive.com/debian-boot@lists.debian.org/msg59641.html
<hazmat> the follow up has some more analysis
<justdave> hmm, there's a bunch of new bugs assigned to me on Bugzilla that I never got bugmail for
<daniels> oh wow, no edid. that sucks horribly.
<lamont> x needs 4.5 GB to build?  sheesh
<daniels> lamont: ya-huh
<fabbione> lamont: only if you build -all
<lamont> well, I have 6gb - hope that's enough.
<daniels> lamont: every time there's a sid upload, we have to poke the arm and s390 folks to build on a box with enough space
<daniels> lamont: plenty
<fabbione> lamont: if you build -B it will be a 500Mb less
<fabbione> lamont: or probably more.. i can't remember
<lamont> fabbione: this is -B
<lamont> on ia64, though
<fabbione> lamont: ah
<fabbione> hmmm
<lamont> so is P1 more urgent than P2?
* lamont sleeps
<lamont> fabbione: btw, you can/should drop the > make_world.build.log hack on your next upload of X...
<fabbione> lamont: just a sec
* lamont doesn't sleep. 
<fabbione> Finished at 20040721-1250
<fabbione> Build needed 02:21:38, 4685680k disk space
<fabbione> Finished at 20040928-1818
<fabbione> Build needed 02:09:09, 4454612k disk space
<lamont> yeah
<fabbione> i guess ia64 doesn't really benefit of the BuildFonts=NO
<lamont> is it building the fonts?
<fabbione> the first one is -6 that was still building the fonts
<fabbione> the second is -7 that does not build fonts and docs
<lamont> heh
<lamont> 200MB, 12 minutes
<fabbione> but for instance on m687k it saves up to 30% of time
* lamont falls over.  night all
<fabbione> night lamont 
<daniels> lamont: night dude
<fabbione> mdz: 1485 permission to upload base-config
<mdz> fabbione: yes
<fabbione> mdz: useless reassing ;) i am done already :P
<mdz> fabbione: you never know; it could get rejected :-)
<fabbione> tsk :P
<fabbione> done
<mdz> 1 down, 38 to go
<fabbione> i am on another one
<mdz> the ones I am really concerned about are #1724 and #1632
<mdz> and #1854
<mdz> 1854 and 1724 I have no idea what is broken
<mdz> #1632 I can at least reproduce and start adding printks
<fabbione> 1834 <-
<fabbione> i will check the others in a few minutes
<mdz> I think 1834 is a dupe of that bug where seb fixed it by adding a dependency
<mdz> but I wasn't sure
<fabbione> yeps.. i am checking that..
<fabbione> Depends: libpt-plugins-alsa | libpt-plugins-oss
<fabbione> it's not versioned
<fabbione> so for a pure warty that's not an issue, but it can be in mixed environment
<fabbione> mdz: do you want me to strict the dependencies?
<mdz> does it need to be versioned?
<mdz> I don't know anything about libpt
<fabbione> neither do i, but according to the maintinaer it needs to be
<mdz> the plugins have an exact versioned dep on libpt
<mdz> and gnomemeeting has a >= dep
<fabbione> "Pwlib is not compatible among different versions.
<mdz> pwlib?
<fabbione> Comment #2
<mdz> I don't think pwlib is related; he must have meant libpt
<fabbione> probably
<mdz> mizar:[/tmp]  apt-cache show libpt-plugins-alsa | grep-dctrl -nsDepends ''
<mdz> libasound2 (>> 1.0.5), libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.3.4-1), libstdc++5 (>= 1:3.3.4-1), libpt-1.6.3 (= 1.6.5-3ubuntu1)
<mdz> it already has an exact dependency, so I don't see how it could be tighter
<fabbione> ok
<fabbione> i missed that :-)
<fabbione> ok.. so it's a duplicate.. let's figure of which bug ;)
<mdz>   * debian/control.in: Added a Dependency on video plugins, so at least one is
<mdz>     going to be always installed (Warty: #1542).
<fabbione> ok.. gone
<fabbione> 1724 smells of nvidia crack
<fabbione> that's something i debugged a while ago and added info to the relevant bugs
<fabbione> as soon as you have nvidia-glx installed, the system becomes.. hmm funny
<fabbione> X -> FTBFS
<fabbione> pyopengl -> as X
<mdz> one of the comments in 1724 swears they removed nvidia
<mdz> but even if it is nvidia, many people posted to ubuntu-users saying xmms did not work
<mdz> I wonder if I can reproduce it just by installing nvidia-glx, not using the driver
<fabbione> mdz: yes you can
<fabbione> with kernel 2.6
<fabbione> the nvidia-glx creates /usr/lib/tls
<fabbione> and boom
<fabbione> the libraries provided by nvidia-glx are pure crack
<mdz> hmm, yes, I can
<mdz> wtf is nvidia doing providing libraries which are used by xmms??
<fabbione> 1632 <- i don't have 2GB of ram.. if Mark wants to sponsor them i can buy another Giga and give serial access to Xu ;)
<fabbione> mdz: no no.. it doesn't
<fabbione> ldso goes on crack with tls
<fabbione> because the libs are pure crack
<fabbione> there is another package that puts stuff in there (can't remember shich one)
<mdz> but everything else works fine for me
<fabbione> that you can use as test case
<mdz> when I don't install nvidia-glx
<mdz> it is still using tls libraries
<fabbione> remove nvidia-glx, install that package and that's it
<fabbione> yu will see that xmms works fine
<mdz> hmm
<mdz> removing /usr/lib/tls/* and running xmms gives a nice segfault
<mdz> what is nvidia-glx changing which breaks it?
<fabbione> it installs some tls libs required for the driver to work on kernel 2.6
<mdz> which ones?  how do they end up linked into xmms?
<mdz> ohhh
<mdz> it is the opengl spectrum plugin
<fabbione> xmms overabuses dlopen
<mdz> rm /usr/lib/xmms/Visualization/libogl_spectrum.so
<mdz> and it works fine
<mdz> ok, that makes much more sense now
<mdz> I didn't know that xmms used GL stuff
<fabbione> if it there is something available, xmms uses it :P
<mdz> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221401
<mdz> xmms is not doing anything wrong; nvidia seems buggy
<fabbione> as i said before :-)
<fabbione> there is a scary override in nvidia-glx
<fabbione> like: lib not linked with libc6 or something
<mdz> Mithrandir: ping?
<fabbione> mdz: 1859. you already disabled the init script completely
<fabbione> mdz: that kinda avoid discover1 to trash /media
<fabbione> mdz: but i think we can safely add joeyh fix to change the default in the template
<fabbione> as extra safety
<mdz> fabbione: I think d-i might call discover to create that stuff, I'm not sure
<mdz> or it might create it itself
<fabbione> mdz: See comment #14
<fabbione> and comment 9
<fabbione> Sorry for the late reply. It seems to mee that discover1 is the culprit
<fabbione> and it probably deleted the directories created in prebaseconfig.
* fabbione checks prebaseconfig
<fabbione> 90prepare-base-config 
<fabbione> # Set up /dev/cdrom link to point to the device used for /media/cdrom0 in
<fabbione> # /target; various programs including base-config want a /dev/cdrom.
<fabbione> [SNIP] 
<jdub> oh man
<jdub> g-s-m has a "run as root" thing all of its own
<mdz> sounds bad
<jdub> so mcuh cock
<mdz> it doesn't have any setuid stuff in it, though
<mdz> so it must eventually call out to su or something
<fabbione> mdz: so should we leave discover1 as it is?
<jdub> mdz: yeah, it does
<jdub> eventually
<jdub> i can evilly hack around it
<mdz> fabbione: hmmm
<mdz> fabbione: I thought someone had reported this in ubuntu
<mdz> fabbione: but now that I am looking, I only see Debian reports
<fabbione> mdz: i am more to apply the patch from joeyh
<mdz> so I think you are right, and it is just discover wiping out the links at boot time
<mdz> in which case it may be NOTWARTY
<mdz> fabbione: joeyh's patch has no effect because it only changes the init script behaviour
<mdz> fabbione: I think we can close it NOTWARTY
<fabbione> mdz: ok
<fabbione> mdz: gone
<mdz> 36 to go
<fabbione> we ARE ROCKING!
<mdz> for #1301, I really think we should just tell the user not to use XFS for root
<mdz> Linux XFS is crap anyway
<fabbione> wtf happened to bugzilla????
<mdz> fabbione: justdave is changing things
<fabbione> the fonts become GIANT in a sec?
<fabbione> ah ok
<mdz> the CSS and such
<mdz> all of the hyperlinks became not-visited for some reason
<fabbione> mdz: i have 38 to go here
<jdub> yay! kill xfs, reiser and jfs! yay!
<mdz> justdave: did you change the visited link color to be the same as the not-visited color?
<mdz> fabbione: I have 36 WartyWarthog bugs >= major
<mdz> fabbione: maybe you are getting website bugs as well?
<justdave> no, visited should be purple, non-visited blue
<mdz> justdave: both are blue
<fabbione> oh could be yes
* justdave surfs the stylesheet for visited again
<mdz> as of a few minutes ago
<justdave> ok, the ones in the header are working, nothing else is.
<justdave> must be something overriding the main one
<justdave> no other mentions of visited in the stylesheet...  hmmmm
<justdave> there we go, got it.
<justdave> there was no explicit declaration for :visited or :active outside of a <p>
<justdave> so it was inheriting the generic <a> style
<justdave> which was explicitly declared as blue
<justdave> that stylesheet is really funky :)
<justdave> no offence intended to the main website :)
<pitti> Morning guys!
* fabbione grabs 2 CDs and checks 1479
<fabbione> hem
<fabbione> sound-juicer just decided to hang completely
<mdz> pitti: morning
<mdz> pitti: what is your feeling on the new utopia packages?  I am quite happy with them so far
<pitti> mdz: Did you try again to burn a CD? Should work better now
<mdz> pitti: I see you have not read your mail yet ;-)
<pitti> mdz: with yesterday's changes, they work really good
<pitti> mdz: no, I just got up. Stayed up too late last night; 
<pitti> mdz: I'm at the bugzilla mail stage :-)
<mdz> pitti: see my comments in #1234
<pitti> mdz: the new packages already work quite well, but there are still problems:
<pitti> mdz: for once, I experienced a hal crash yesterday; I cannot reproduce it, though
<pitti> mdz: the second thing is that hal now correctly detects volumes on raw (i. e. unpartitioned) devices
<pitti> mdz: but if you had an unpartitioned device before, and then partition it and put a new file system on the partition, hal detects _two_ volumes: sda and sda1
<pitti> mdz: this causes overwriting of one volume by write operations on the other and kills the stick
<pitti> mdz: I already asked upstream about this and dived deeply into the hal code, but I was not yet able to solve that
<pitti> mdz: could you reproduce your hal crash after CD burning?
<mdz> pitti: I never saw hal crash
<mdz> with the previous packages, nautilus-cd-burner crashed
<mdz> this time, I only saw g-v-m crash, and I think it was because of the upgrade
<pitti> mdz: Hmm, my brain told me that hal crashed yesterday; I even asked you whether you run it as --daemon=no
<mdz> fabbione: hmm, sounds like you are finding new bugs, that does not help the bug count :-)
<pitti> mdz: but maybe this was a misunderstanding
<pitti> mdz: after installing the new packages, the user must log out and relogin
<mdz> pitti: oh, that was unrelated
<mdz> the hal crash was something else
<pitti> mdz: I'm not sure how we can achieve that
<pitti> mdz: but even if it was sth else, it should not crash :-/
<mdz> I think it was the old version of hal
<pitti> mdz: ah, so much the better :-)
<mdz> anyway it was a corner case, powering off a USB device, much less important than #1234
<pitti> mdz: there is a possibility to restart much of the user's session: killall gnome-vfs-daemon nautilus
<pitti> mdz: but I don't think that we should write this into the postinst script...
<mdz> pitti: I did log out and log in, but I was impatient
<mdz> and I was logging in already before the login completed
<mdz> I am not sure at what point g-v-m starts
<mdz> s/login/upgrade/
<pitti> mdz: pretty early
<mdz> probably my fault, then
<mdz> as I said in bugzilla
<pitti> mdz: so the conclusion is: in principle they work well
<pitti> mdz: I only need to solve this corner case of a repartitioned device
<mdz> I think the only way they will get more testing is if we put them into warty
<mdz> pitti: yes, that sounds dangerous
<mdz> pitti: why does it cause writes to the disk, though?  I don't understand that
<pitti> mdz: if it breaks too badly, we could upload a 0.2.98+really0.2.92 or so, not?
<mdz> hal doesn't even have permission to write to the disk, does iT?
<mdz> yes, we can always fix it if we find something terrible
<pitti> mdz: if both sda and sda1 are recognized as volumes, g-v-m mounts _both_
<pitti> mdz: but sda is not really a volume any more, it's just the first block (where the MBR belongs)
<pitti> mdz: so as soon as something writes to sda, it will destroy the file system on sda1
<pitti> mdz: the problem is that the partition detection code in hal is wrong: it reports 0 partitions for such an USB stick
<mdz> pitti: how can it mount sda if there is no filesystem there?
<pitti> mdz: okay, again: I format /dev/sda with VFAT  (as I used to do earlier; this works well with fstab-style mounts)
<pitti> mdz: then I come to Ubuntu and see that the old hal does not recognize raw devices
<mdz> oh, I see, so you are switching from raw to partitions without blanking it
<pitti> mdz: so I put a partition on the stick and format it as VFAT
<mdz> that seems like an invalid format to me
<mdz> there is no way to tell which one is valid
<pitti> mdz: this alone could be regarded as a corner case, yes
<pitti> mdz: but plovs tried it yesterday with a ZIP drive (which he never touched, partitionwise)
<pitti> mdz: and also for this thing _two_ volumes were detected
<mdz> ZIP disks come with two partitions from the factory I think
<pitti> mdz: he was not able to unmount it again, file writes did not sync; he had to rip it out and reboot
<mdz> one for PC and one for Mac, something like that
<pitti> mdz: but then they share the files written to it?
<pitti> mdz: we are able to mount both partitions... (we are too good :-) )
<mdz> On the other hand, ZIP disks prepared by IOMEGA utilities actually have a partition table (usually having a single entry, the fourth, spanning the whole disk, so that access to such disks with partition table goes via mounting /dev/sda4 (in the SCSI case, say)). On disks for the Mac one has 6 partitions, and again the fourth can be mounted, with filesystemtype "hfs".
<mdz> so actually it is only one partition
<pitti> odd
<mdz> but it is partition #4
<mdz> I remember there was some PC/mac compatibility thing
* fabbione just discovered that HIS cdrom drive is broken
<fabbione> mdz: no worries :-)
<fabbione> my cdrom is either dirty or broken
<mdz> fabbione: well that is good news in a way
<fabbione> but i found a new bug in the kernel
<pitti> mdz: ah, I got a mail from plovs with his lshal listing
<mdz> fabbione: STOP FINDING BUGS
<mdz> fabbione: :-)
* m_tthew laughs
<fabbione> mdz: if i leave the cdrom tray open, when cd<something> module is loaded, it will start spawning a lot of errors
<fabbione> (this is at boot time)
<fabbione> and i can reproduce it on 2 machines
<fabbione> if i revert to the previous kernel there are no problems
<mdz> hmm, doesn't happen with my usb one
<fabbione> it's ide-cdrom probably
<mdz> which previous kernel?
<fabbione> title           Ubuntu, kernel 2.6.8.1-3-686 
<fabbione> actual
<fabbione> title           Ubuntu, kernel 2.6.8.1-2-686 
<fabbione> old
<mdz> weird
<mdz> no ide stuff has changed since then
<fabbione> i know...
<fabbione> but it's not fatal or anything
<fabbione> it is just scary :-)
<pitti> mdz: yep, with plov's ZIP drive both sda and sda4 are mounted
<mdz> pitti: I suppose the safe thing is to not mount the device itself if it contains a partition table
<pitti> mdz: yep; actually this should be fixed in hal; if there are partitions, skip the raw device and do not report it as block.is_volume
<mdz> pitti: agreed
<pitti> mdz: I try again today to fix that; if this one works, I think we could throw it at the public
* pitti shakes
<mdz> pitti: does the current hal in warty not have the same problem?
<pitti> mdz: it does not detect volumes on raw devices at all
<mdz> ah
<pitti> mdz: this was the sole reason why I put a patrition on my stick
<pitti> mdz: a quick fix would be to disable volumes on raw devices completely :-)
<mdz> pitti: if that is simple and safe, I am not opposed
<mdz> that would let us get the new utopia into warty and then you can continue to work on the raw device problems
<pitti> mdz: we could sell it as "compatible to 0.2.92 :-)"
<pitti> mdz: it would be a dirty hack, but it should be not too intrusive/unsafe
<pitti> mdz: on every occasion where block.is_volume is set to TRUE, I would leave it to false if the device is raw
<pitti> (that's my first idea)
<pitti> mdz: the hal code is a mess, I cannot find a clean solution quickly
<sjoerd> pitti: is the block.no_partitions property correct on such devices ?
<pitti> sjoerd: unfortunately not
<pitti> sjoerd: at least this flag does not work properly, its always false
<pitti> sjoerd: (IIRC)
<sjoerd> it's true on my cdrom drive
<pitti> sjoerd: the partition detection in hal is screwed, it always returns partition_count = 0 for such devices
<pitti> sjoerd: all the flags are based on this number
<sjoerd> pitti: try moving the msdos partition detector to the beginning in the volume_id code
<pitti> sjoerd: you mean in the big switch VOLUME_ID_ALL case?
<sjoerd> pitti: yes
<pitti> sjoerd: first probe for msdos, then for raid/ntfs?
<pitti> sjoerd: worth a try
<sjoerd> pitti: it was moved to the end because i had an empty msdos partition signature on my /dev/sda1 :)
<pitti> sjoerd: which does not have VFAT?
<pitti> sjoerd: argh, an msdos part?
<sjoerd> pitti: msdos partition map, not vfat of some other fs
<pitti> sjoerd: hmm; I don't like to fix a bug by unfixing another...
<sjoerd> pitti: no it's safe. the msdos partition prober check if a partition table is empty and doesn't recognize it
<sjoerd> pitti: see the 2004-08-23 of key siever
<sjoerd> s/key/kay
<pitti> sjoerd: okay, thanks for that hint. I will try that after breakfast
* sjoerd had to go shower get to the uni
<fabbione> mdz: why 1805 is a major?
<mdz> fabbione: inflated from Debian
<fabbione> mdz: ok -> enanchement
<mdz> however since the only change is to add some files to the package which are already built, i think it would be nice to have in Warty
<fabbione> mdz: ok, i can take care of it. is that ok for you?=
<mdz> fabbione: argh, my saved search was not including bugs marked NEEDINFO or UNCONFIRMED or PENDINGUPLOAD because those are new
<fabbione> mdz: i only search for severity
<mdz> so now I see 45 bugs
<fabbione> argh
<fabbione> no
<fabbione> you are right!
<mdz> searching only severity would find closed bugs too
<pitti> Hi seb128!
<fabbione> mdz: same here
<elmo_> mdz: you put linux-$SUBARCH in restricted?
<mdz> elmo_: yep
<fabbione> mdz: ok i am on that samba stuff
<mdz> elmo_: they depend on the restricted-modules
<seb128> morning
* elmo_ takes mdz's big hammer away
<elmo_> ;P
<mdz> elmo_: I thought hard about it, and it is pretty much the right thing
<mdz> our default kernel offering is the combination of the image and the restricted modules
<mdz> so the combination is restricted
<mdz> elmo_: if you have another idea which makes more sense, I am interested
* mdz mumbles some more about how nobody cared about this when he solicited input
<mdz> justdave: I think the simple search has the same bug
<mdz> justdave: I don't think it recognises NEEDINFO as an open state
<justdave> mdz: ok, should be fixed now, probably have to shift-reload to dump the old js from your cache
<mdz> thanks
<elmo_> Kamion: ?
<elmo_> mdz: low-ping about wvdial, btw
<elmo_> and mozilla-locale
<elmo_> oh, there's an assigned bug about the latter so nm that
<mdz> elmo_: what about mozilla-locale?
<mdz> the uninstallable stuff? yeah, that's known
<pitti> mdz: I patched gnome-system-tools for #1485 (trivial patch); can you please approve?
<mdz> pitti: go ahead
<elmo_> mdz: yeah
<fabbione> mdz: permission to upload samba for 1805
<mdz> fabbione: only for 1805, or the other samba bug also?
<fabbione> mdz: only 1805
<fabbione> are there more samba bugs?
<mdz> yes, 1433
<mdz> I think that we probably need to disable sendfile by default unless there is a patch available
<mdz> but it needs some investigation
<fabbione> i am reading
<pitti> mdz: yes! yes! yes! I fixed hal!!!
<pitti> mdz: sorry for the noise
<mdz> pitti: the mounting problem?
<pitti> mdz: yep; now it correctly detects only sda1
<mdz> excellent
<pitti> mdz: and if there are no partitions, it still detects sda
<pitti> mdz: now it works as it should
* pitti hugs sjoerd for a great hint where to look
<mdz> yes, that was quick
<pitti> mdz: I prepare an updated package and put it onto my unofficial repo
<mdz> pitti: let me know when to upgrade, and I will give it some testing
<mdz> and then I should probably sleep
<pitti> mdz: it will take me another 20 minutes to clean my debugging stuff and prepare a clean package
<fabbione> mdz: well i think the default should be set to no
<pitti> mdz: I will try to catch plovs to test the new package with his ZIP drive
<mdz> fabbione: yes, I think sendfile is probably only interesting for high-volume servers and such
<fabbione> mdz: yeah i will see what's the best way to revert the default
<fabbione> mdz: if there is a way to change it in the code rather than in the config
<mdz> fabbione: I found an upstream bug report, might be worth looking at
<mdz> https://bugzilla.samba.org/show_bug.cgi?id=1643
<mdz> (emailed to debian as well)
<fabbione> cheking
<mdz> fabbione: upstream says 2.4.x is broken and 2.6.x is OK, while Debian says the reverse
<fabbione> yes i can see that
<fabbione> i trust neither of them :-)
<fabbione> we will just switch sendfile off ;)
<mdz> did 3.0.6 enable it by default, while in 3.0.5 it is disabled?
<pitti> mdz: the new hal crack is up
<mdz> upgrading
<mdz> pitti: the only change is this partition stuff, right?  so I shouldn't need to retest everything I did today
<fabbione> mdz: i am not sure.. i am checking how this crack works
<pitti> mdz: yes, I only changed partition/fs detection
<pitti> mdz: even more precise, I just changed the _order_ of the detection
<justdave> hmm...  thought...  when a bug is NEEDINFO, should we have the radio button default to "make the bug ASSIGNED" so the next time someone touches it the needinfo goes away, unless they set it to "leave as NEEDINFO" before submitting?
<pitti> mdz: now it first attempts to detect a partition table and then raw file systems
<seb128> yes please
<seb128> a lot of people add comment and let the bug as NEEDINFO
<mdz> justdave: however, another common case is for the assignee to make another comment
<mdz> justdave: reiterating the request for more info before closing the bug
<mdz> and the state should not be reset in that case
<justdave> could change the default only if the viewer is the reporter...   but that won't work if they aren't logged in when they view it
<mdz> I can't think of any way to DTRT automatically
<justdave> maybe a checkbox right next to the comment area "I am providing the requested information"
<mdz> justdave: that sounds reasonable
<mdz> pitti: hmm, it seems unhappy
<mdz> pitti: I plugged in my card reader and it isn't appearing in hal
<justdave> or with the default radio button change, you could assume the assignee is more likely to remember to change it to "leave as NEEDINFO" before submitting
<pitti> mdz: you need to relogin
<pitti> mdz: if hal is restarted, this gnome stuff stops to work 
<pitti> mdz: (I assume because of the lost dbus connection)
<mdz> pitti: this is not gnome stuff; it doesn't show up in lshal
<mdz> but I did logout and login
<pitti> mdz: hmm. Had it partitions before?
<pitti> mdz: can you please replug?
<mdz> pitti: it has a single partition
<pitti> mdz: I also noticed that: the very first time after package upgrade my devices are not recognized as wekk
<pitti> mdz: s/wekk/well/
<pitti> mdz: I have no idea why
<mdz> I have replugged several times
<mdz> no change
<pitti> mdz: damn
<mdz> pitti: I think that the init script is buggy
<pitti> mdz: of hal?
<mdz> pitti: when running /etc/init.d/dbus-1 restart, hal is not restarted
<mdz> hal      22730  0.0  2.6  8048 6776 ?        Ss   Sep28   0:09 /usr/sbin/hald --drop-privileges
<mdz> that is the old hald process from before the upgrade
<pitti> mdz: stop and start should work
<pitti> mdz: but thanks for that hint, I will look at the dbus init script
<mdz> mdz@potpal:~ $ sudo /etc/init.d/dbus-1 stop
<mdz>  * Stopping system message bus...
<mdz>  * Stopping Hardware Abstraction Layer...                                [ ok ] 
<mdz> mdz@potpal:~ $ !ps
<mdz> ps aux | grep hald
<mdz> hal      22730  0.0  2.6  8048 6776 ?        Ss   Sep28   0:09 /usr/sbin/hald --drop-privileges
<pitti> still the old process...
<mdz> /var/run/hal/ is empty
<mdz> I assume there should be a pid file in there
<mdz> perhaps it was deleted by the failed restart
<pitti> indeed, it should
<pitti> it is from start-stop-daemon
<pitti> next thing on my TODO list :-)
<mdz> I will restart it by hand so I can test
<mdz> yes, restarting hald let it pick up the device
* pitti is greatly relieved
<mdz> I had a similar problem before
<mdz> but I blamed it on g-v-m
<pitti> mdz: so dbus tries to stop hald, but that fails somehow?
<mdz> pitti: it displays [ok] , but apparently does not succeed
<mdz> fabbione: X is segfaulting on me :-(
<mdz> fabbione: sabdfl was seeing this, too (should be in scrollback)
<mdz> oh, I know what it is
<mdz> I installed nvidia-glx
<mdz> to test that bug
<sabdfl> mdz: my glitch was fglrx
<pitti> mdz: odd, the init script works for me...
<mdz> fabbione: apparently, if nvidia-glx is installed, it breaks the X server even if it is using ati
<mdz> pitti: try it with a package upgrade
<fabbione> mdz: ah
<fabbione> mdz: going back to send file
<pitti> mdz: okay, I can reproduce it
<fabbione> vn diff -r 1312:1262 svn://svnanon.samba.org/samba/tr
<fabbione> bah
<fabbione> svn diff -r 1312:1262 svn://svnanon.samba.org/samba/trunk/source/param/
<fabbione> that's the commit that turns on sendfile by default
<fabbione> i can just revert it
<mdz> pitti: hal is not finding my partition volume :-(
<fabbione> mdz: if that's ok with you
<pitti> mdz: on the card reader?
<mdz> fabbione: that is fine, also fine to change in the config file
<mdz> pitti: correct
<mdz> pitti: the volume does not seem to show up at all
<fabbione> mdz: there is no need to change the config file
<fabbione> mdz: a user that wants sendfile will have to explicitly say so
<fabbione> otherwise it's off
<mdz> pitti: ok, so I logged out
<mdz> pitti: shut down dbus/hal
<mdz> pitti: started dbus/hal
<mdz> pitti: logged in
<mdz> and now it works
<mdz> perfectly, just as before
<sabdfl> lamont: mdz: im getting a ton of postfix errors in syslog after a fresh install
<sabdfl> seems related to /etc/aliases.db not being present
<mdz> yes, me too
<mdz> Sep 29 02:51:05 localhost postfix/local[13672] : fatal: open database /etc/aliases.db: No such file or directory
<mdz> Sep 29 09:51:06 localhost postfix/master[3624] : warning: process /usr/lib/postfix/local pid 13672 exit status 1
<mdz> Sep 29 09:51:06 localhost postfix/master[3624] : warning: /usr/lib/postfix/local: bad command startup -- throttling
<fabbione> mdz:
<sabdfl> pitti: also, hald has a habit of suckng 99% cpu for a few minutes on startup
<mdz> fabbione: sounds fine
<pitti> sabdfl: minutes? another thing I cannot reproduce :-(
<fabbione> samba (3.0.7-1ubuntu3) warty; urgency=low
<fabbione>   * Apply patch from https://bugzilla.ubuntu.com/show_bug.cgi?id=1805
<fabbione>     and start shipping mount.cifs.
<fabbione>     (Closes: #1805/#227791)
<fabbione>   * Set sendfile default to no, reverting upstream change:
<fabbione>     svn diff -r 1262:1312 \
<fabbione>     svn://svnanon.samba.org/samba/trunk/source/param/loadparm.c
<fabbione>     (Closes: #1433/#261917)
<pitti> sabdfl: you also have the most recent hal package? 
<fabbione> mdz: permission to upload ;)
<mdz> fabbione: yes
<fabbione> ok!
<pitti> sabdfl: 0.2.98-1ubuntu2?
<mdz> pitti: I think it has always done this
<mdz> it is the getty/vc/hotplug/hal race
<mdz> all 6 consoles do it at once
<pitti> mdz: ah, this would explain it
<sabdfl> mdz: is the postfix problem a known one?
<pitti> mdz: I think the source of this is udev, isn't it?
<fabbione> mdz: going back to the X <-> nv problem... 
<fabbione> mdz: it means that X segfaults with nvidia-glx installed?
<fabbione> mdz: indipendently of the driver?
<fabbione> s/of/from?
<mdz> fabbione: correct
<fabbione> mdz: hold on a sec
<mdz> fabbione: easy way to reproduce for me: apt-get install nvidia-glx, then log out of GNOME
<mdz> X doesn't come back
<mdz> purge nvidia-glx -> OK again
<fabbione> Package: nvidia-glx
<fabbione> Status: install ok installed
<fabbione> i am running ubuntu22
<mdz> this is using Driver "ati"
<fabbione> and i am in X
<fabbione> i am not using nvidia binary driver
<fabbione> i am using the nv free driver
<mdz> perhaps someone else here can try with a non-nvidia card
<fabbione> that's an option
<m_tthew> I have an ati
<fabbione> otherwise we should really install nvidia stuff only if there is an nvidia card
<fabbione> m_tthew: can you try installing nvidia-glx and the latest X packages?
<m_tthew> apt-get install nvidia-glx ; logout. see what happens?
<m_tthew> fabbione: absolutely. lemme update && dist-upgrade
<fabbione> mdz: and btw the last upload didn't change anything fancy on the driver side
<fabbione> m_tthew: thanks
<fabbione> mdz: it was only a fix contained into the nv driver
<mdz> fabbione: yes, I remember
<mdz> i don't think it is specific to the latest X
<mdz> I have never tried installing nvidia-glx before (obviously I had no use for it)
<mdz> pitti: yes, udev is at the core of the problem
<mdz> getty needs to learn to wait for udev I think
<m_tthew> fabbione: ii  xserver-xfree8 4.3.0.dfsg.1-6 the XFree86 X server
<fabbione> m_tthew: are you on Debian or Ubuntu?
<m_tthew> fabbione: so, I should apt-get install nvidia-glx and the n logout, login to gnome to test?
<m_tthew> fabbione: ubuntu
<fabbione> m_tthew: that it should be -6ubuntu22
<m_tthew> hmmm
<m_tthew> I am on amd64, if that is a factor here
<fabbione> m_tthew: logout -> switch to console -> stop gdm -> start gdm
<mdz> there is no nvidia-glx for amd64
<fabbione> m_tthew: ah
<fabbione> ok
<mdz> you'd need an i386
<fabbione> never mind
<m_tthew> crap
<m_tthew> I can test x86
<m_tthew> "give me about 20 minutes
<fabbione> m_tthew: thanks
<mdz> I knew this nvidia binary driver was crack, but I did not realize the extent
<mdz> breaking things when you don't even use it
<mdz> it will need to be some kind of taint flag in all bug reports
<m_tthew> mdz: the binary driver thing is such a drag and I didn't really grok that until I read all this stuff about nvidia
<m_tthew> fabbione: np, just waiting on the iso; it is my pleasure to help
<fabbione> m_tthew: i really really appreciate it
<mdz> we will collect all such bug reports in a special place and point people there when they ask about binary drivers
<m_tthew> fabbione: daily iso the right stuff?
<m_tthew> mdz: haha
<m_tthew> fabbione: more like 45 minutes, but we'll get there
<fabbione> mdz: daily iso should do fine, otherwise install from the net ;)
<fabbione> ops
<fabbione> ^^m_tthew
* m_tthew smiles
<m_tthew> I'll do the mini-iso to make this as fast as possible
<fabbione> m_tthew: don't worry
<fabbione> take the time you need
<sabdfl> mdz: the only postfix bug i can find that mentions aliases is not the one about /etc/aliases.db not be there
<fabbione> i need to get some food and take a shower
<elmo_> will the gnome auto-magic stuff not work for my camera if it uses usb-storage?
<mdz> sabdfl: yes, I think that one is still around
<elmo_> ('cos it appears as /dev/sda1)
<mdz> elmo_: by default, it'll launch the photo application, which should DTRT
<mdz> elmo_: if it doesn't, you can uncheck the box for that, and it'll just mount it instead
<azeem> btw, gnoppix really uses ubuntu GNOME packages in their latest beta, dunno if somebody tried it already, I did last night
<fabbione> oh fuck.. i just closed 2 bugs and debzilla reports one more
<fabbione> mdz: 1872 - 1881: duplicates?
<fabbione> or should we leave them separate (for $arch)
* fabbione goes and get some food
<mdz> fabbione: I am not sure if they are the same bug or not
<mdz> even if they are both missing discover data, they are probabyl different devices which need to be added
<mdz> bed
<mdz> night
<fabbione> good night
<pitti> mdz: good night!
<ross> pitti: does eject use pmount etc now?
<fabbione> daniels: ping
<sivang> Hi fabbione
<fabbione> hi sivang 
<sivang> I'd like to continue the Xfree discussion, #ubuntu then?
<fabbione> sivang: yes, but i am almost off for today
<sivang> oh
<fabbione> sivang: woke at 4:50 am and it's almost 13:10 ;)
<m_tthew> whomever made the pxe installer Just Work, I owe you a pint.
<sivang> fabbione : boy why so early?
* m_tthew . o O ( because apparently I have more functional eepros than I do functional cd burners )
<sivang> m_tthew : you still need to config mac address on the server? :)
<fabbione> sivang: insomnia
<m_tthew> sivang: dhcp server? yes, but I have one of those and I've been doing pxe installs of open&netbsd all week
<m_tthew> sivang: sooo ... it was more of a filename ""; change than a MAC thing :)
<m_tthew> fabbione: before you go, what bug # is this nvidia library mess I am working to duplicate?
<sivang> m_tthew : i want to do the same! (I've been fighting with PXE for 2 days and gave up, even with mac address it didn't work)
<fabbione> m_tthew: no bug number.
<fabbione> m_tthew: they told me here on irc
<fabbione> m_tthew: i know as much as you do :)
<m_tthew> fabbione: delightful :) ; I'll mail mdz, what should I cc: you at?
<pitti> ross: npmccallum said so, yes (sorry for the delay; lunch break)
<fabbione> m_tthew: you need to install nvidia-glx and see if X crashes given that you are not using a nvidia card
<m_tthew> fabbione : yeah, I understand (logout, restart gdm after apt-get install nvidia-glx)
<ross> pitti: when i do eject /dev/sda to "eject" my ipod, it blocks until i physically unplug. the old eject returned straight away so i could still charge
<pitti> ross: I did not touch that package, but I can take a look at it; can you please file a bug?
<fabbione> m_tthew: that's it :-)
<m_tthew> sivang: for me, the key has always been a host <hostname> { hardware ethernet <MAC>; address <IP>; filename "pxelinux.0"; next-server <my tftp server IP>; }; block in dhcpd.conf
<pitti> ross: I'm currently busy with fixing hal, and that's high priority :-/
<m_tthew> fabbione: ack, will email mdz with results, can CC: you once you give me an email address.
<ross> pitti: sure
<pitti> ross: thanks
<fabbione> m_tthew: fabbione@canonical.com
<pitti> ross: please assign it straigt to me (martin.pitt@canonical.com)
<sivang> fabbione : any tasty X bugs to reproduce if we arelady talking about it? :-)
<fabbione> sivang: not really because you have a nvidia card
<m_tthew> fabbione: ack, will CC:
<fabbione> m_tthew: thanks
<sivang> fabbione : Ah! Darn, I knew I would be better off with ATI ;->
<pitti> ross: nautilus really shows "eject" instead of "unmount" in the context menu for your iPod?
<pitti> ross: and this hangs?
* pitti has to go to the city to have his broken TFT repaired :-(
<pitti> see you later, guys
<thom> interdiff -z mozilla-firefox_0.99+1.0PR-0ubuntu3.diff.gz mozilla-firefox_0.99+1.0PR-0ubuntu4.diff.gz|wc -l
<thom> 11595
<thom> *sigh*
<thom> more interestingly:
<thom> interdiff -z mozilla-firefox_0.99+1.0PR-0ubuntu3.diff.gz mozilla-firefox_0.99+1.0PR-0ubuntu4.diff.gz|grep "^-|^\+\+" |wc -l
<thom> 11232
<thom> go mozilla, your distclean target works really well
<thom> really.
<elmo_> should I have to 'pmount /dev/sda1' or should it automagically mount?
<ross> elmo_: my ipod automatically mounts if it isn't plugged in when gnome starts
<ross> if its in when i boot it doesn't
<elmo_> do hal/dbus write logs anywhere?
<lamont> anybody know what CD image sabdfl was seeing the aliases.db issue with?
* lamont notes that dh_shllibdeps running on the X libraries is a _DOG_.
<lamont> seb128: is moz-firefox yours?
<lamont> nope.  thombos
<lamont> s/s/st/
<Kamion> thombost?
<lamont> Kamion: I got tired of "fixing" it. :-(
* lamont prepares to upload a new-and-improved debootstrap for t-bone
<Kamion> lamont: including ia64?
<lamont> yeah
* lamont fatfingered and said 'without_package' instead of 'subst_package'
<Kamion> can you make sure the changes are done via the required-base.py script?
<lamont> bad juju
<Kamion> adding 'exclude-ia64: hfsplus hfsutils libhfsp0' and excludes for the bootloader to warty.overrides should get you started, and you'll need to suck the right bits of the base system down into warty.base
<Kamion> this way just means that it's maintainable automatically from germinate output
<lamont> Kamion: I'm still just bootstrapping the chroot...
<lamont> this is in warty.overrides, yes?
<lamont> required-ia64: libc6.1
<lamont> exclude-ia64: libc6
<lamont> like that?
<Kamion> don't need to exclude-ia64 that, since it isn't present on ia64
<Kamion> you could just add libc6.1 to required in fact, less maintenance for alpha later :)
<lamont> ah, ok.
<lamont> what about warty.base: does it need to clone the entries?
<lamont> or is it autogenerated?
<Kamion> warty.base should contain what germinate spits out for your architecture
<Kamion> in 'base'
<Kamion>     < base tail -n +3 | head -n -2 | cut -d' ' -f1 | xargs >> "$OUT"
<Kamion> er, prefixed with base-ia64: of course
<Kamion> lamont: might be best to get permission to add all the ia64 entries back to the seeds?
<Kamion> should just be kernels and bootloaders and stuff
<lamont> Kamion: yeah, but that's not really a warty thing...
<Kamion> yeah, but it'll make it manageable :)
<lamont> point.  I'll chat with jdub/mdz later today about it.
<lamont> but t-bone will be the one finding most of the missing packages...
<Kamion> (normally, updating the debootstrap package for a seed change is a one-command operation for me)
<Kamion> editing the script by hand was too error-prone
<lamont> very
<lamont> does the script build foo.buildd as well?
<lamont> or just foo?
<Kamion> just foo at the moment
<Kamion> could be updated
<lamont> Kamion: although that probably requires a buildd seed?
<Kamion> or manual overrides for what goes in the buildd base
<Kamion> you want the same required and a different base, right?
<lamont> buildd's required is quite a bit shorter too
<Kamion> oh, ok
<Kamion> hmm
<Kamion> might be worthwhile having the buildd list seeded somewhere, I guess, for buildd-ng ...
<lamont> on that note, I think I'll leave it with the warty.overrides changes (libc6.1 in required, exclude-ia64 entry), and let t-bone come up with the rest of the edits as he actually bootstraps ia64.
<lamont> Build needed 07:46:14, 4467964k disk space
* lamont beats fabbione and daniels with the build log
<T-Bone> lamont: gcc-3.4 won't build
<T-Bone> lamont: and my box is fucked up. Awaiting aw to see with him whether he wants to take a look at it
<T-Bone> lamont: i'm setting up another one on a zx2000
<lamont> T-Bone: ok.  I'm up to dealing with gtk+2.0, etc.
<T-Bone> lamont: well; if you have a workaround that would allow me to bootstrap stage2 without gcc-3.4, that'd be nice
<lamont> T-Bone: fwiw, stage2 chroot debootstrapped with just gcc-3.3, coreutils, and perl carried forward.
<T-Bone> oh
<T-Bone> care to tell me how to do that? ;)
<lamont> ln snapshot/*3.3.4-2*_ia64.deb stage1
<lamont> then rename *%3a*3.3.4* to *:*3.3.4*
<lamont> and smashArchive
<T-Bone> gack
* lamont points at rule 2.
<lamont> (rule 1 being "never get involved with someone more messed up than yourself" :-)
<T-Bone> lol
<Kamion> is rule 2 broken as often as rule 1?
<lamont> Kamion: rule 2 is the prefix to each step of the process: "Do whatever it takes to ..."
<lamont> bootstrapping an architecture is an _UGLY_ business. :-)
<T-Bone> lamont: come to think of it, your trick is ugly: we're not going to bootstrap stage2 against clean warty binaries, that way...
<lamont> right.  It's actually stage 1.5
<T-Bone> *G*
<T-Bone> considering how often i kill my boxes... (who said ia64 had a stable kernel??)
<lamont> we declare stage 2 as soon as we can debootstrap _WITHOUT_ sarge binaries.
<lamont>  06:54:48 up 15 days, 10:05,  2 users,  load average: 0.10, 0.58, 1.01
<lamont> and that was a power outage
<T-Bone> lamont: itanium1?
<lamont> i2000
<T-Bone> lamont: that doesn't count
<T-Bone> i2000 _IS_ stable
<T-Bone> i can kill pretty well any itanium2 box
<lamont> I'll remember that
<T-Bone> =)
<T-Bone> lamont: remember my killing-fu ;)
<T-Bone> lamont: did you succeed on building perl eventually?
<lamont> er, and perl.
<lamont> :-)
<T-Bone> lol
<T-Bone> give me 5mn to finish the setup on the zx2000
<lamont> <lamont> T-Bone: fwiw, stage2 chroot debootstrapped with just gcc-3.3, coreutils, and perl carried forward.
<T-Bone> hmm right. I didn't catch the meaning of "carried forward" in the first place
<T-Bone> lamont: there's an interesting mail from thierry awaiting moderator approval on u-devel, fyi ;)
* lamont pokes jdub
<lamont> Kamion: so with libc6.1 in required, I shouldn't need to add the subst_package to warty.template, correct?
<T-Bone> lamont: is db.d.o deadN
<T-Bone> s/N/?/
<lamont> looks that way from here, but that'd be that other channel... :)
<T-Bone> heh
<T-Bone> lamont: it's just that i can't fetch sbuild :P
<lamont> wonder if it's one of these machines in disguise: down until further notice: raff, debussy, rameau, bruckner, lully
* lamont lobs a copy - which architecture?
<lamont> ia64?
<T-Bone> yap
<T-Bone> lamont: db is newsamosa
<lamont> hrm.. no copy lying around on caballero.
<lamont> semt
* T-Bone guesses that's a "n", fetches mail ;)
<T-Bone> From:	Debian/IA64 non-US Build Daemon <buildd@caballero.debian.org>
* T-Bone ^5s ladude ;)
* lamont can't type
<T-Bone> shit happens ;^)
<lamont> this happens, you mean?? :-)
<T-Bone> lol
<T-Bone> lamont: i guess i should run your script before doing the symlink stuff, right?
<lamont> what symlink stuff?
<T-Bone> ln snapshot/ ...
<lamont> do _you_ see a -s there?
<lamont> (apache won't follow symlinks...
<T-Bone> right, i misexpressed myself
<T-Bone> anywya, should i run your script first?
<lamont> smashArchive creates Packages, so you'll need to do it after each change to the archive directory
<T-Bone> oic, smashArchive is your script
<lamont> yes
<T-Bone> i didn't have its name in the mail, since it's inlined, my stupid webmail won't show the filename
<lamont> poor name, but it was late...
<T-Bone> lol
<lamont> debootstrap uses Filename, but requires Release and an md5sum for Packages
<lamont> anything else from you (or anyone else, for that matter) before I disappear for a few hours?
<lamont> Kamion: I assume sounder 8 was pre-"seen debootstrap", yes?
<lamont> T-Bone: mind you, I _tried_ symlinks first, too. :-)
<T-Bone> lamont: heh
<Kamion> lamont: was observing that rule 1 is broken just under half the time :)
<Kamion> lamont: hmm, actually this might be tricky ...
<T-Bone> lamont: asa aw has settled with my buggy box, i'll wipe /home out and rebuild it
<Kamion> lamont: making libc6 be per-arch required (and therefore later in the required list) has been known to break things in Debian
<T-Bone> lamont: i hope i'll have less troubles with stage 1.5. I'll only be building missing packages, for stage 1.5, i guess (gcc-3.4, perl & coreutils)?
<Kamion> lamont: maybe sticking with the subst_package hack for now, given how close we are to warty, would be a better plan
<Kamion> lamont: pre-"seen debootstrap"? don't understand
<lamont> Kamion: before your fix that I need for postfix
<Kamion> lamont: everything's before that fix, since it doesn't exist except in my home directory yet ...
* Kamion is building a mirror in order to test it at the moment
<lamont> Kamion: hence my assumption
<lamont> Kamion: rule 1 is broken in 100% of relationships. :-)
<lamont> generally only by one party, though. :-)
<T-Bone> lamont: sbuild postinst is silly: doesn't check for a proxy, btw
<lamont> sbuild assumes a functional (and apt-get update'd) chroot
<T-Bone> lamont: nah
<T-Bone> i'm talking about the package postinst
<lamont> sbuild's postinst shouldn't be fetching anything, I thought.
<lamont> or you mean /etc/source-depend*
<T-Bone> it's trying to run update-sourcedeps, which fails if no direct internet connection is possible
* lamont changed the wget to a touch
<lamont> well,actually :>
<lamont> ubuntu doesn't believe in hacking around broken source packages
<lamont> the mantra is "fix the package, don't kludge it"
<T-Bone> this sounds good to me ;)
<lamont> hrm...  I think I fixed our sbuild package...
<lamont> yeah, but we have more ftbfs's that way...
<T-Bone> true
<lamont> T-Bone: off to the shower, will try to kick a gcc-3.4 build off on my chroot before I run away
<T-Bone> lamont: that'd be nice, just in case i fail ;)
* lamont needs to go run several errands in town today, will be gone for some time.
<lamont> making the change to the sources.list line for my archive should get you where I am.
<lamont> well, a few hours later, damn throttles.
<T-Bone> lamont: woops, i wiped out your home on envy, i'll rebuild your .ssh folder
<lamont> thus reminding us of the meaning of "crash and burn" machine.
<lamont> :-)
<T-Bone> envy:~# journal_bmap_R618276b0: journal block not found at offset 3334 on sd(8,7)
<T-Bone> Aborting journal on device sd(8,7).
* T-Bone considers the system as dead
<lamont> back in a few, then will be gone...
<pitti> jdub: #1769, permission to upload?
* lamont wanders off for a few hours.
* T-Bone wonders who's moderating u-devel
* lamont bets it's jdub
<T-Bone> lamont: dude; i thought you were off!
<lamont> yeah, well...  I got distracted.
<T-Bone> lamont: i'm building gcc-3.4 on my own too, just in case ;)
<T-Bone> lol
<lamont> really going to leave shortly
* lamont runs off to save his marriage.
<lamont> (or she'll kill me..)
<T-Bone> lamont: i know that feeling ;^)
* T-Bone is not married, tho ;)
<lamont> and you haven't met my wife. :)
<T-Bone> lol
<Kamion> hm, that's odd, the diff between debootstraps with old and new debconf only consists of newly set values, not newly set seen flags
<trukulo> fabbione, e u there?
<Kamion> oh, DUH
<Kamion> missing 'export'
<Kamion> now notes *don't* get marked as seen, but everything else does?!
<Kamion> oh, of course, I turned off DEBCONF_ADMIN_EMAIL
<myk> carlos: ping
<carlos> myk: pong
<myk> is there any way to distinguish between releases in mirroring the package archive?
<myk> well, i guess my question is
<myk> will the growth in size be in the package archive or the ISO archive?
<carlos> myk: I don't know those details
<carlos> elmo_?
<myk> carlos: who should I ask?
<carlos> or perhaps mdz, I'm not sure
<elmo_> carlos: yeah?
<carlos> elmo_: myk is preparing a ubuntu mirror
<carlos> and wants to mirror only warty
<carlos> but not hoary 
<elmo_> unfortunately there isn't an easy way to do that - the easiest solution is probably 'debmirror'
<elmo_> that should at least be in 'universe'
<myk> debmirror?
<myk> elmo_: the problem is limited space.  i only have about 25 gigs to play with
<elmo_> myk: it's a mirroring script that allows you to mirror by suite (== warty, hoary etc.)
<elmo_> myk: we're going to be changing the mirror layout, RSN so that it'll drop to more like 12Gb
<trukulo> why not rsync?
<elmo_> trukulo: debmirror can use rsync
<myk> elmo_: i've never heard of RSN.  what is it?
<elmo_> myk: basically archive.ubuntu.com will become 'main' (6Gb)+cdimages (4Gb)  and universe.ubuntu.com will contain the real space killer (17Gb)
<elmo_> myk: ==> Real Soon Now
<myk> haha
<trukulo> elmo_: ok
<myk> elmo_: ahh, okay.  sounds like i should just wait until that happens
<myk> elmo_: will that be announced on any of the ubuntu lists?
<trukulo> myk, you can mirror main part only, if you want
<trukulo> and let universe out
<elmo_> myk: yes, before and after
<elmo_> (to pre-warn existing mirrors)
<myk> which list? devel?
<elmo_> myk: both, and -announce if we have it (I can't recall off hand)
<myk> awesome
<Kamion> the preview release announcement went to -announce I believe
<elmo_> myk: what trukulo suggests is also an option, btw - it's as easy as adding --exclude=universe/ to the rsync command line
<trukulo> elmo_: you need to write that in wiki
<trukulo> of course, when you are ready for that
<myk> elmo_: /pool/universe, eh?
<elmo_> yeah, that's what's taking all the space
<sivang> we ought to find a way to make nv use 100hz for ver refresh rate on FLATRONs
<sivang> although I have overcome my flickering problem, was a nasty AC adaptor that caused this.
<myk> oof.  20 k/s.  this'll take a bit
<Kamion> anyone GNOMEish notice that evolution failed to build?
<Kamion> lamont: marking noninteractive questions as seen during debootstrap doesn't seem to have any effect on postfix at all
<Kamion> lamont: I suspect they're being asked at a priority lower than high
<elmo_> kamion: am I good to remove old kernels?
<Kamion> elmo_: aye
<trukulo> umm, how can we put new packages in ubuntu?
<trukulo> as atmel wireless drivers
<trukulo> like this one: http://at76c503a.berlios.de/
* T-Bone wonders whether Gnome crashing after an upgrade is actually a "feature"
<npmccallum> trukulo: the atmel drivers are already in Ubuntu
<trukulo> npmccallum, not these one
<npmccallum> trukulo: they are in the 2.6 kernel upstream and the firmware is in our kernel package
<trukulo> these one are for USB wifi cards
<trukulo> as mine
<trukulo> i can compile it, it's not a problem
<trukulo> but it would be better to be in a repository
<npmccallum> trukulo: send an email to the dev list propsing that we add it to the linux-restricted-modules package.  It probably won't go in until Hoary though (we are in deep freeze)
<trukulo> npmccallum, umm, the good ones are in CVS, i'm afraid
<trukulo> forget it, too much problems
<npmccallum> why is that a problem? We are using the madwifi drivers from CVS
<trukulo> ah, so i'll send email
<npmccallum> that package is not supported anyway, so if there is a bug, tough luck :)  Its provided as a convenience
<trukulo> :) yes, i understand
<mdz> morning
<thom> mdz: marnin'
<Kamion> mdz: anyone looking at fixing the evolution build failure? #ubuntu is buzzing about it
<mdz> Kamion: I have only begun reading bugzilla mail
<mdz> I didn't know we had a new evolution yet either
<mdz> is seb not aware of it?
<Kamion> I think he's gone for the day; his upload failed to build
<Kamion> seb128: ah, you're back
<Kamion> mdz: #1618, ping?
<Kamion> seb128: you know about the evolution build failure?
<seb128> Kamion: no
<seb128> hum
<seb128> just looking on the build log
<Kamion> you do now I guess :)
<Kamion> unfortunately it makes evolution uninstallable so #ubuntu has been confused
<seb128> yes, ok, need to bump the depends on libgtkhtml
<seb128> fixing right now
<Kamion> ta
<seb128> still the same problem with eds/evolution
<mdz> Kamion: sorry, I thought I gave blanket approval for discover1-data updates. go ahead
<mdz> (additions anyway; those are pretty low-risk)
<Kamion> alrighty, thanks
<mdz> Kamion: do you intend to run the 1781 patch by joeyh?
<Kamion> he's fine with the general idea, but yeah, I'll drop the bug a mail
<mdz> Kamion: I stared at the debconf patch a bit, and it seems right
<mdz> debootstrap stuff is obviously correct
<Kamion> it turned out to be a hairier problem than I'd expected
<mdz> having to add all those noninteractive modules is...unfortunate
<Kamion> we need to do the same DEBCONF_ADMIN_EMAIL thing in debian-installer-utils, BTW, but that's a separate bug
<Kamion> (apt-install)
<Kamion> should squash all those /dead.letter complaints
<mdz> Kamion: any clever way I can verify the fix for #1895 (alsa-base modprobe thing)?
<mdz> I'd like to verify that debootstrap works, but I don't have a local mirror or such
<Kamion> ah, it's awkward without a local mirror
<Kamion> you could debootstrap on a Debian system and then install the new .deb, that might do it
<Kamion> mdz: alternatively send me the patch and I'll try it out
<Kamion> I'm well set up to do that kind of thing after the debconf/debootstrap testing
<trukulo> mdz, using qemu
<trukulo> there's a "installing ubuntu in qemu" in the wiki
<Kamion> trukulo: wouldn't be any easier
<trukulo> Kamion, just a hint, don't know the problem
<Kamion> trukulo: mdz is asking for an easy way to inject a single modified package into the base system
<Kamion> trukulo: for the problem at hand, debootstrap is already considerably easier than qemu
<mdz> Kamion: trivial patch for 1895 sent to you
<trukulo> umm, i agree
<mdz> Kamion: thanks for spotting that; I had run into that but couldn't see past the end of my nose
<trukulo> debootstrap is easier for that than qemu (and faster)
<mdz> Kamion: I thought it was update-modules which was bombing, and meant to look at it later
<Kamion> trukulo: and more likely to show up the problem to boot, since qemu would probably have you using the Ubuntu kernel
<mdz> (it would be nice if the module-init-tools tools printed their names with errors...)
<Kamion> mdz: it was kind of a guess that modprobe was failing, I hadn't really dug into it
<trukulo> Kamion, well qemu it's an emulation of a machine, you can install debian in suse i.e. but uses ubuntu kernel
<trukulo> (i'm not very good at english, forgive me if i am understanding wrong)
<trukulo> sorry, you can install debian in suse, and uses debian kernel in qemu
<mdz> Kamion: well, it was obvious once you said it, because I added modprobe commands to postinst
<Kamion> trukulo: sure, but then you'd have to construct some kind of installation image with the Debian kernel, probably a bunch of Debian udebs to cope with that, and the Ubuntu base system; I doubt it would work very well at all.
<Kamion> (and it would take somebody who knew the installer very well to do it)
<mdz> trukulo: if you look at #1895, it should be clear why debootstrap is a better test environment
<trukulo> going to see #1895
<mdz> qemu wouldn't exhibit the problem because it only happens in a chroot with no kernel installed in it
<Kamion> trukulo: I'm familiar with qemu, and it is indeed cool
<trukulo> :) just trying to help
<Kamion> np
<trukulo> ah, i see
<trukulo> here qemu has nothing to do
<trukulo> ok, ok, i'll get the idea
<trukulo> it's only debootstrap related, ok
<Mithrandir> mdz: pong
<mdz> Mithrandir: wanted to try to get more info out of you about that futex problem
<mdz> but need to reboot, brb
<Kamion> justdave: um, I don't seem to be able to select a component that isn't in the first page of the scrolly drop-down box thing
<Kamion> I know what the component *is*, why can't I just type it?
<Kamion> a single click on the scrollbar makes the drop-down disappear
<mdz> if firefox could save and restore all its tabs as part of my gnome session, I would be such a happy guy
<trukulo> mdz, no, but you can save a "group of tabs"
<trukulo> i imagine you know that
<mdz> I had been using the tabbrowser extensions to do that sort of thing
<mdz> but it broke with some firefox upgrade
<trukulo> firefox can make it without extensions, as i know
<Mithrandir> mdz: opera does that for me, one of the reasons I'm sticking with it.
<Mithrandir> mdz: what do you want me to debug wrt the futex bug?
<mdz> I believe the word is BONG
<mdz> Mithrandir: find out what caused it to start happening, and why it doesn't happen to anyone else? :-)
<Mithrandir> mdz: strace makes the problem go away; we don't have snapshot.ubuntu.com, do we?
* Kamion resorts to w3m to reassign that bug
<mdz> Mithrandir: we don't have it all apt-ified and nice, but we have copies of all packages
<trukulo> mdz, if you save bookmarks in a folder
<trukulo> you can open folder directly
<trukulo> and there you have, grouped tabs
<trukulo> Mithrandir, same for you
<trukulo> right button on folder and: open in tabs
<Mithrandir> trukulo: bookmarks don't preserve history.
<Mithrandir> so it's useless.
<Mithrandir> and it's a large number of clicks when I restart the browser, which is annoying.
<Mithrandir> mdz: can I get to them?  If so, I could install into another drive on the same machine and do a binary search.. possibly, at least.
<trukulo> Mithrandir, that's right
<Mithrandir> mdz: assuming that the patch in http://lists.debian.org/debian-amd64/2004/08/msg00162.html works for fixing autofs -- permission to upload? (#1880)
<mdz> Mithrandir: yes
<mdz> Mithrandir: regarding the morgue, you'll need to ask elmo
<Kamion> mdz: Setting up alsa-base (1.0.5a-1ubuntu5) ...
<Kamion> I: Configuring alsa-base...
<Kamion> FATAL: Could not load /lib/modules/2.6.8-powerpc/modules.dep: No such file or directory
<mdz> Mithrandir: I'd try backing out your kernel first
<Kamion> but it then continues successfully
<Kamion> (as expected)
<mdz> ah, phew
<mdz> thanks for the test
<mdz> uploaded
<Mithrandir> mdz: iirc, it's the one I installed with.
<Kamion> hm, I'd like to have the component name listed in bug lists
<mdz> Mithrandir: oh, you've never let apt upgrade your kernel?
<mdz> Kamion: yeah, that's a weird bugzilla-land difference
<Mithrandir> I don't think so, but I don't remember, this is just my workstation at the university.
<Mithrandir> mdz: I can look at it when I sit down tomorrow
<mdz> Mithrandir: ok, thanks
<T-Bone> lamont: ping?
<mdz> Kamion: any reason not to move pcmcia-cs out to ShipSeed for the next daily?
<Kamion> mdz: not that I know of
<mdz> done
<thom> mdz: permission to upload for #1349 ?
<mdz> thom: yes, thanks
<thom> mdz: ta.
<Kamion> #1826 raises a good point, distinct from the very-hard-to-solve general problem of figuring out whether all partitions are big enough
<thom> although space is no longer at a premium, so it's not so urgent to get rid of source packages :-)
<Kamion> mdz: mind if I make archive-copier stop copying Supported? It's useless until we have better integration in base-config to set up a proper apt archive for it, and all it achieves right now is to eat space by copying stuff that will just be deleted later
<mdz> Kamion: right
<mdz> no objection
<mdz> hmm
<mdz> samba-common just asked me a bunch of questions when it was upgraded
<sivang> what's the state of the FAT32 fsck bug?
<sivang> or it's bug#
<Kamion> sivang: see ubuntu-users
<Kamion> I'm assuming you mean the problem where Windows no longer boots after an Ubuntu install?
<sivang> Kamion : this also :-)
<mdz> Kamion: I think he meant the bit where fsck.vfat complains all the time
<sivang> mdz : hmm, yes. sorry for being so obscure.
<sivang> The thing with fat32/windows installations boot up already worked, I mean grub knew how to detect it.
<sivang> or whatever script that did ut
<sivang> it
<sivang> I'll test again with today's daily
<sivang> mdz : is there a known list for the nv driver limitation list? (the opensource one)
* sivang rebooting after fixing fstab
<sivang> Kamion : any way to rerun the script that supposed to configure grub automagically for other OSs ?
#ubuntu-devel 2005-10-10
<jbailey> jdong: What to explain?  I did sed -e 's/mkinitrd/mkinitrmafs/', it worked, I uploaded.
<jbailey> Then Fabio uplaoded a working version right after.
<jbailey> door, justasec.
<ogra> cant stop laughing about the two sentences jbailey just wrote above
<jbailey> Wow, kids selling chocolate bars.
<ogra> drugs !
<jbailey> Teenagers in think qubec french are a bit hard to understand. =)
<jbailey> ogra: Right, so I refused.
<jbailey> Not only is caffeine not a drug I do, it was also laced with animal products.
<ajmitch> jbailey: aww, not roaming evangelists? :)
<jbailey> tsk.
<jbailey> ajmitch: Nope.
<tseng> ajmitch: do you have jehovahs witness?
<jbailey> ajmitch: I've been inviting all of them in to increase my vocab.
<ajmitch> tseng: of course
<tseng> woot
<jbailey> ajmitch: The JWs didn't come bacak.
<jdong> jbailey: thanks, that's clear
<ajmitch> jbailey: it's a shame when they don't come back
<jbailey> Which is sad.  I learned alot of new words in the 20 minutes I spoke to them.
<tseng> me gives jbailey "Mario Teaches Typing"
<tseng> in true form, botching the clever jab
<jbailey> In school we didn't learn alot of religious vocabulary (that whole separation of church and state and all that)
<jdong> jbailey: LOL, nice initramfs migration method :)
<jbailey> jdong: =)
<jbailey> jdong: If you have questions about the initramfs-tools, I understand how it works much better. =)
<ogra> especially with the fabio sentence below *g*
<camilotelles> laptop guys, I will buy a new notebook. what brand model is best for ubuntu support? i looking for an HP nc series. good choice?
<jdong> camilotelles: wrong channel?
<jbailey> ogra: Understand that I'm incredibly anal about my packages.  But the kernel packages just scare me.
<ogra> jbailey, i can very well understand you :)
<camilotelles> jdong, maybe. I'm looking forward. maybe you are right. thanks.
<jdong> camilotelles: you'll probably have better luck over at #ubuntu
* ogra lols about jdub actually taking the time to close #8725 
<jmg> hmm
<camilotelles> jdong, thanks
<jmg> im kinda dissapointed no SIP app from main works for me
<jmg> except skype, but skype is nonfree
<tseng> SIP is a goal for dapper
* tseng points at \sh
<jmg> tseng: cool i can help with it
<torkel> jmg: and it's not SIP
* jmg is aiming to be a motu in dapper
<jmg> torkel: it is today
<os2mac> By the by I have written a small script that will automatically install ndis-utils and configure the wlan0 card.
<jmg> torkel: sip to asterisk
<jmg> the only softphone i have tried that works unfortunately
<jmg> is xlite
<jmg> :(
<os2mac> it is very specific and points to my thumb drive for the driver and uses my essid and key but you could modify that very easily me thinks.
<jmg> os2mac: nice
* jmg wishes he had a front side usb port for thumb devices
<jdong> jmg: I feel your pain (solved it two weeks ago on my newest system :) )
<os2mac> when are they release 5.10?
<jmg> jdong: yeah?
<ogra> os2mac, have a look at ndisgtk in universe ;)
<jmg> jdong: new box?
<jdong> jmg: exactly :)
<os2mac> ndisgtk?
<os2mac> gui?
<jmg> jdong: this is my work laptop.. i just put up with it :) 
<jdong> LAPTOP???
<jdong> come on, we're just gettin lazy here
<ogra> os2mac, yup
<jmg> jdong: it is nice enough being able to test/work on ubuntu
<jmg> jdong: even if it is kubuntu :P
<jmg> speaking of which
* jmg goes to file bugzilla on acpi-support
<jdong> and speaking of that.... umm, 8725, is "fixed in breezy" really a GREAT way to close a Hoary bug?
<Nafallo> jdong: yes.
<jmg> jdong: isnt hoary meant to be supported for five years?
<mjg59> os2mac: There is no Linux driver for the Broadcom wireless chipset
<Nafallo> jmg: no, that's dapper.
<jmg> right
<jmg> looks like i am going to be helping out the xen goal
<os2mac> I figured that out MJ.
<jmg> since i want xen on this box for work
<os2mac> they only release a driver for their eth0 stuff
<jdong> 18 months or 5 years, Hoary's still the latest stable release.....
<jmg> instead of qemuing xen
<jdong> shouldn't hoary-updates be getting used?
<jmg> ugh
<jdub> jdong: not for unimportant stuff like that
<jdong> jdub: I see.... frivolous bug....
<jmg> ok i need to file a bug on the fact that my laptop powers off after resuming from suspend apparently
<jdong> jmg: my systems hard reset after resuming from disk
<jdong> jmg: as another dev told me the other day, your bios is shit
<os2mac> ogra: I am on a live CD. ndisgtk would still require me to create a mount point and mount hda then go find the driver.
<ogra> os2mac, not if its on you thumb drive
<jmg> jdong: toshi laptop support does work if configured manually
<os2mac> and you would think that I don't get paid to be an admin for this.
<jmg> jdong: something is broken in klaptop
<jdong> jmg: oh, so /sys/power/state can validly do it, but klaptop fails?
<dholbach> jmg: nice to hear that (MOTU-wise) :)
<Riddell> mdz: can I upload an updated kubuntu-meta?  it adds usplash artwork
<dholbach> jmg: you can hang out with the rest of the crew on #ubuntu-motu :)
<jmg> jdong: echo mem > /sys/power/state and i am still here
<os2mac> so onto the next question.
<os2mac> how do you configure acpi to allow hibernation/suspend on my laptop via the FN button?
<jdong> keymap fun....
<jmg> os2mac: does it come up as "Unknown key blah" on console?
<os2mac> nope just doesn't do anything
<jdong> os2mac: under dmesg?
<os2mac> [4295064.124000]  ACPI: PCI Interrupt 0000:02:03.0[A]  -> Link [LNKB]  -> GSI 7 (level, low) -> IRQ 7
<os2mac> is the only alert I got
<jdong> that's ACPI gibberish pretty irrelevant to the sleep button....
<jdong> could the key sequence be wired up to the ACPI sleep button?
<os2mac> I do not know.
<jdong> I don't think sleep button
<jdong> is wired by default
<os2mac> sleep function on this laptop is fn+ESC
<mjg59> os2mac: What sort of laptop is this?
<os2mac> Dell Inspiron 8600
<os2mac> as a matter of fact most of the FN functions do not work.
<jdong> os2mac: I hear ya... they're usually software-wired
<jdong> aren't there special ACPI extensions/patches for Dells?
<mjg59> No
<mjg59> fn+escape is a normal ACPI sleep key
<mjg59> Dell hotkeys are well understood
<jdong> is ACPI sleep wired to anything /etc/acpi-wise by default?
<sivang> anybody else experiencing major X/GNOME slow down ?
<jdong> At UF we've gotten some reports of it... though poorly confirmed or pinpointed
<jdong> my personal systems, no
<Zomb> hello
<mjg59> jdong: Yes. It cals /etc/acpi/sleep.sh
<jdong> sivang: those who complained described long-lasting trails (2+ seconds) dragging windows around
<Zomb> I am trying to make Knoppix work in a similar way the ubuntu live-CD does. However, I get data corruption problems really similar to those described on http://www.redhat.com/archives/dm-devel/2005-August/msg00068.html
<Zomb> so the question... how do you guys manage that?
<mdz> Riddell: yes
<sivang> jdong: exactly that
<Riddell> thanks
<jdong> sivang: http://ubuntuforums.org/showthread.php?t=71680 example of recent one
<sivang> jdong: and I wait about 2 seconds between each gdb step :)
<jdong> sivang: though this one I have to attribute partly to poor Xorg.conf
<mjg59> Acceleration is disabled on some Radeons because they tend to hang the machine otherwise
<sivang> mjg59: I have an nvidia 
<mjg59> sivang: Right, probably not that, then
<jdong> sivang: so does the person in question
<dieman> is acpi-support fixed from the sleep.sh syntax error?
<mjg59> dieman: Yes
<dieman> otherwise, ive got a bug to file.
<sivang> jdong: any idea to what's causing this?
<dieman> dsok
<jdub> BY THE BEARD OF ZEUS!
<dieman> mjg59: ok.  sorry, on gprs here.
<dieman> laggy as hell
<mjg59> dieman: No problem
<jdong> sivang: check your Xorg.conf for obvious things, like GLCore popping back in
<dieman> mjg59: i like the FAN HATE comments
<mjg59> dieman: Haha
<mjg59> dieman: HP breakage workaround
<jmg> i presume ACPI_SLEEP=true /etc/acpi/sleep.sh is supposed to work better than echo mem > /sys/power/state
<sivang> jdub: lol, what's now?
<jdong> sivang: other than that, I'm confused about it too... I can't reproduce it on my two nvidias
<jmg> because it dont.
<mjg59> jmg: Yes
<dieman> i was also happy to see my laptop in the laptop whitelist now :)
<mjg59> jmg: bugzilla.ubuntu.com
<mjg59> dieman: What model?
<jmg> mjg59: But at least it works better than klaptop. Which im trying to patch to use /etc/acpi stuff now.
<jmg> mjg59: then i'll get to /etc/acpi itself.
<sivang> jdong: bah, don't have glcore on the module list
<Riddell> jmg: klaptopdaemon is patched
<mjg59> jmg: That's, uh, cutting things a bit fine
<mjg59> And yeah, what riddell said
<dieman> mjg59: fujitsu p7010
<Riddell> jmg: what's the problem?
<mjg59> dieman: Ah, cool
<dieman> ok, at the bus stop, bbiab
<jmg> Riddell: i get poweroff immediately after wake up from suspend
<Riddell> jmg: what version do you have installed?
<jmg> ok so i think i need to set up my apt sources so i can do apt-get source kdeutils/ubuntu or something
<jmg> but also kdeutils/sid
<jmg> 4:3.4.2-0ubuntu1
<Riddell> jmg: -0ubuntu2 should be the patched one
<jmg> latest breezy unless my mirror isnt synched.
<jmg> typical.
<jmg> Riddell: thats on the main mirrors?
<mjg59>      4:3.4.2-0ubuntu2 0
<mjg59>         500 ftp://archive.ubuntu.com breezy/universe Packages
<mjg59> (yes)
<jmg> .nz admins need to be shot.
<jmg> or at least educated in configuring debsync
<jmg> and cron
<wasabi_> wow this miniitx board totally screwed up in linux
<jmg> oh for frunks sake
<jmg> Riddell: wont be able to test till tomorrow
<jmg> Need to get 175MB of archives.
<Riddell> jings
<jmg> Riddell: i'll sync from work
<jmg> and THIS time, i'm making an lvm snapshot first
<wasabi_> wow
<wasabi_> soon as ubuntu switches into curses, the screen corrupts.
<wasabi_> that's new
<azeem> anybody running deskbar-applet?  I don't see that shiny preferences dialog from http://browserbookapp.sourceforge.net/deskbar.html, just a box which lets me select the width
<dholbach> have a nice evening guys, i'm off to bed
<dholbach> azeem: it got removed
<azeem> aha
<dholbach> azeem: doesnt use keywords anymore, it uses epiphany search thingies
<dholbach> azeem: and will use firefox stuff soon too
<azeem> right, I think I read about that
* azeem wonders whether it replaces contact-lookup-applet as well
<Riddell> jdub: random pagan blaspheming or do you really have zeus there?
<jdub> watching anchorman in the background
<dholbach> azeem: i just uploaded it to breezy universe - let's see how long it will be in NEW :)
<azeem> dholbach: bah, I just packaged it for Debian
<tseng> dholbach: im ahead of you by several days
<tseng> dholbach: GET IN LINE
<jdub> haha
<dholbach> tseng: i was waiting for reviews and i tried it a couple of minutes after it first appeared on UniverseCandidates
* dholbach thinks . o O { slacker! }
<bddebian> hehe
<tseng> resapplet?
<dholbach> oh sorry
* dholbach misread
<dholbach> :)
<tseng> hugs
<dholbach> no, not resapplet
<dholbach> deskbar thingie
<tseng> oh what is that
<dholbach> it was like 2 months ago
<tseng> luis posted a link to flash or some crap
<tseng> that i cant see
<dholbach> http://raphael.slinckx.net/blog/index.php/2005-10-02/deskbar-applet-hotness
<dholbach> that one
<tseng> oh that
<azeem> dholbach: where is your package?  Shall I sponsor it for Debian, or do you prefer I upload my own package there?
<dholbach> azeem: no it'd be awesome if we could coordinate
<dholbach> azeem: http://revu.tauware.de/details.py?upid=708
<azeem> cool, thatnks
<azeem> eh, thanks
<dholbach> merci beaucoup
<seb128> dholbach: you have set uneeded requirement for gtk, you have to change that for Debian
<dholbach> seb128: it is needed
<dholbach> seb128: for some crazy-ass gtk-utility
<seb128> configure.ac is bugged?
<dholbach> dunno, it's not only python, it needs it anyway
<seb128> configure.ac disagree with you one the libgtk2.0-0 version required
<seb128> I'm not sure than it uses anything specific to the new versions
<seb128> anyway, I'll give a try to the build with a debian unstable pbuilder and let you know if that builds tomorrow
<seb128> sleep well for now :)
<bddebian> dholbach: Did you get a chance to hit xfonts-terminus today?
<azeem> well, it builds
<azeem> if you are still talking about deskbar-applet, that is
<seb128> yep
<dholbach> seb128: i remember now... upstream told me to
<dholbach> seb128: i guess he'll fix it in the next release or something
<seb128> k
<dholbach> i will go to bed now too
<dholbach> thanks for your awesome work everybody :)
<dholbach> *wave*
<ogra> night dholbach 
<azeem> n8
* mvo goes to bed now too
<ogra> night mvo 
<bddebian> anyone know what's up with gnome-launch-box?
<ogra> bddebian, i think it got dropped
<dholbach> bddebian, ogra: seb128 should know :)
<seb128> I just packaged it
<seb128> no news since
<dholbach> don't mess with seb :)
<seb128> ah ah
<bddebian> seb128: There's a Malone bug on it
<ogra> seb128, didnt you say it didnt change and you dropped it iirc ?
* bddebian hates his life
<azeem> bddebian: did they make you fix all bugs filed in Malone?
<ogra> if thats true, we probably sould remove it for now to not generate bugs
<seb128> ogra: nop
<bddebian> azeem: They're trying ;-P
<seb128> bddebian: only one? :)
<dholbach> seb128: haha
<bddebian> seb128: Aye, should I not look at it?.. Nope, make that two
<segfault> Niiice. Ubuntu is almost fully translated to pt_BR.
<dholbach> bugs keep that software together :)
<bddebian> hehe
<segfault> maybe fully when ogra fixes that .desktop bug? :D
<segfault> heh
<dholbach> segfault: which one?
<bddebian> seb128: Both bugs say broken dependencies but it doesn't show up in apt-cache unmet ??
<ogra> dholbach, xscreensaver translation typo 
<dholbach> ah i see
<segfault> yup
<ogra> in pt_br :)
<seb128> bddebian: it needs a rebuild with current evolution-data-server libs
<dholbach> seb128: and a transition, i suppose?
<bddebian> seb128: OK< will to
<dholbach> seb128: code-wise?
<bddebian> Err will do
* ogra thinks he can fill the frist two weeks of dapper with fixing gnome-screensaver bugs already
<dholbach> bddebian: xfonts-terminus uploaded
<dholbach> now i'm off
<bddebian> ogra: :-)
<dholbach> see you
<ogra> *sigh*
<seb128> dholbach: no, soname change
<bddebian> dholbach: ROCKIN, thx
<seb128> dholbach: package rename
<seb128> dholbach: just stock rebuild
<seb128> bddebian: thanks
<dholbach> seb128: i'm amazed
<seb128> dholbach: why ?
<dholbach> seb128: i didnt think that a simple rebuild would fix the package again
<ogra> bddebian, if they just wouldnt bomb in my mailbox all the day ...
<bddebian> heh
<dholbach> however :)
<dholbach> *wave* :)
<seb128> dholbach: why not? That's just a matter to catch the dep on the right package, ie: the current soname
<ogra> i get about 3-4 a day for gnome-screensaver
<dholbach> yeah of course... i just thought the API changed in between
<seb128> probably not breaking that
<bddebian> ogra: Can't you just dump those to /dev/null? ;-)
<seb128> gnome-screensaver has a new upstream version
<ogra> bddebian, nope, its actually very good... we even know all bugs *before* we even use the software...
<seb128> which has most of the changes listed on the ubuntu wiki
<seb128> if somebody wants to update it
<ogra> seb128, yes, for dapper
<seb128> universe is frozen?
<ogra> seb128, i have eniugh on the list for xscreensaver currently
<ogra> seb128, and a ton of gnome-screensaver bugs idling...
<seb128> yeah, but an update would probably fix some bugs
<seb128> so you could close some and not get bugs already fixed upstream
<bddebian> Oh, oh, does that mean I can update gnucash, libofx, aqbanking, libosb, etc for gnucash and kmymoney2?? :-)
<ogra> seb128, true... if you have the time... i already lost 10 days for screensaver stuff that were planned for edubuntu, i wont waste time on it for breezy anymore
<seb128> bddebian: ?
<bddebian> seb128: There are about 4 bugs on Malone between gnucash and kmymoney2 but they require a lot of newer subpackages
<seb128> bddebian: you are looking for bug to fix? I can make a list of stuff for you if you want :p
<ogra> seb128, eave bddebian alone !! he's #1 bugfixer for universe currently :) (together with ajmitch )
<seb128> we could use it for main :)
<bddebian> seb128: I currently have 3 goals.  Clean up the UniverseUnmetDeps, Keep Malone bugs < 500, and the MOM merges
<bddebian> seb128: I can't do anything about main :-(
<ogra> bddebian, if you think its reasonable to update all the stuff and it doesnt draw to much time, go ahaead
<seb128> bddebian: sure you can, send patches, I'll do the uploads :)
* tseng is #3424 bug fixer
<bddebian> Otherwise I would have already re-uploaded scribus
<ogra> seb128, !!!
<bddebian> tseng: You are?
<tseng> bddebian: yes
<bddebian> tseng: How do you know that?
<ogra> seb128, stop, or we wont have a universe in breezy :)
* bddebian doubts that he is #1 bug fixer
<ogra> bddebian, note i said currently... in sum i guess thats \sh
<bddebian> Ah ha
<bddebian> Well my karma isn't anywhere near ajmitch yet either.. :-)
<ogra> bddebian, but beside ajmitch noone can cope with you atm
<bddebian> No one can cope with me?? Hmm
<ogra> :)
<bddebian> Oh gnome-launch-box FTBFS, what a surprise
<seb128> anyway time to sleep here
<seb128> later
<ogra> night seb128 
<bddebian> Later seb128 
* bddebian wonders if ogra knows what cope means? :-)
<ogra> i guess so...
* ogra looks it up to be sure
<tseng> ogra: oh
<tseng> ogra: why does mediawiki want php4 again
<ogra> tseng, because it was imported from debian and because the history function has a bug with php5
<tseng> i see, thanks.
<ogra> since it wont go into main i didnt touch it further...
<ogra> else i would have triued to fix that
<tseng> ok
<tseng> using packaged php apps is going to suck for breezy
<ogra> yes
<sivang> ogra: could you please remind me how I exctract a tarball based source package?
<ogra> if they can they should depend php5 | php4
<ogra> sivang, tar xzvf ? 
<sivang> ogra: there's something in debian/rules for that
<tseng> dpkg-source -x foo.dsc?
<ogra> sivang, thats cdbs i think, i dont use cdbs
<ogra> use a normal debhelper based package with orig.tar.gz :)
<ogra> then you dont need to fiddle with tar in /rules
<sivang> ogra: right :) but seb128 had signed with evil as you know, so I have to know how to work with it - nevermind thanks for tip 
<sivang> according to daniels , cdbs=evil
<bddebian> So what replaces menu-tree.h?  gmenu-tree.h seems to puke
<ogra> sivang, look at some other cdbs based package ;)
<sivang> ogra: bah, reading the rules file, I see that build-tree was replaced with "extract"
<sivang> ogra: I wish someone just notified in advance about those...
<doko> Kamion: bad news for the amd64 install CD: openoffice.org2-common is missing a dep on openoffice.org2-java-common, skipping about 8MB of packages
<doko> same for the live-CD
<doko> mdz: I've put a OOo2-help package on people.ubuntu.com/~doko/ it builds, but there's still some bug with cross references. should this be included for breezy in this quality?
<speel> Hey
<speel> would it be possible to recommend a driver to be built into ubuntu?
<jdub> speel: bugzilla's the place for it, file against ubuntu -> linux
<Amaranth> speel: it wouldn't make it into breezy
<Amaranth> speel: is it an open source driver?
<speel> bah
<speel> yes
<jdub> speel: breezy will be released within *days* -> far, far, far too late
<speel> Yea ah kinda figured =/
<speel> because it would be great to have the spca5xx webcam driver built in because alot of cams need it and i was just going to suggest it.
<speel> Ah well thanks anyway :) keep up the good work.
<mdz> mjg59: when you asked about radeontool and smartdimmer in main, I didn't realize you meant _in the default install_
<mdz> mjg59: gnaargh
<Nafallo> jdub: wow! nice work on the new icon :-).
<Nafallo> jdong: background as well :-)
<Nafallo> s/jdong/jdub/ :-)
<jdong> Amaranth:ping
<Amaranth> jdong: pong
<jdub> Nafallo: background and splash by cliff chen
<jdong> Amaranth: 15281... can you help me out?
<jdong> Amaranth: (bugzilla.ubuntu.com)
<Amaranth> jdong: give me 20 minutes for bugzilla to load on dialup
<jdong> Amaranth: lol, np
<Nafallo> jdub: yepp :-). you will have to forward those messages :-).
<jdub> :-)
<Nafallo> and I have to update my screenshoot _again_ ;-)
<Amaranth> known issue if it's gnome-app-install in hoary
<mdz> speel: when requesting a new driver, it is customary to first check whether it is already included :-P
<Amaranth> jdong: they were using unofficial backports
<speel> well i dont think it is =/
<mdz> well it is
<jdong> Amaranth: yes.... so should we mark it resolved/invalid since it doesn't exist anymore?
<Riddell> mdz: can I upload a quick klaptopdaemon fix? http://muse.19inch.net/~jr/tmp/kdeutils.diff
<Amaranth> jdong: yeah, and please get smeg out of the official backports
<speel> spca5xx is not included in hoary ... or is it? lol
<Amaranth> jdong: i get lots of people complaining about it being uninstallable due to a lack of a new pyxdg
<jdong> Amaranth: sure... on it.
<Amaranth> jdong: btw, my email is alleykat@gmail.com if you need it again :)
<jdong> Amaranth: thanks! I'll keep that in my contacts list
* jdong jots it down on desktop wiki :)
<jdong> yes, me pathetic enough to need a personal wiki
<mdz> Riddell: ok
<mdz> speel: that's correct, it is not available in hoary but in breezy
<speel> ah great! 
<bddebian> Anyone know what func replaces menu_tree_directory_get_entries in gnome-menus?
<speel> mdz, thanks for letting me know
<mdz> jdub: who did the usplash artwork?
<jdub> mdz: cliff
<jdub> mdz: I AM SERIOUS, IT WAS CLIFF, DON'T YOU BELIEVE ME?
<jdong> jdub: could use a bit more brown... (j/k)
<wasabi_> hmm. odd. soon as grub loads the kernel, this system reboots.
<mdz> jdub: oh, I thought you were talking about the gnome splash
<jdub> heh
<jdub> we talked about usplash before too
<bddebian> mdz: Know anything about gnomen-menus? :-)
<bddebian> Err s/gnomen/gnome/
<jdub> bddebian: #ubuntu-desktop
<mdz> bddebian: I know something about everything and everything about nothing
<jdub> bddebian: probably a bit late for the core desktop hackeurs
<bddebian> mdz: Ahh
<bddebian> jdub: Thx
<Amaranth> jdub: looking at gnome-menu-editor in gnome cvs might help
<Amaranth> err, bddebian 
<mdz> jdub: must be the crack I've been smoking
<ajmitch> bddebian: gnome-launch-box is crack, ok?
<bddebian> Yes it is
* mdz mumbles something about taking a vacation
* jdub chuckles at mdz's acpi-support changelog
<bddebian> But it's still broken and you know how I HATE broken ;-P
<ajmitch> bddebian: last I heard it needed ported to the new gnome-menus api or somewhat
<jdub> mdz: go to sunny montreal!
* ajmitch is looking forward to long days & little sleep in montreal
<bddebian> ajmitch: That's what I'm trying to do.  ANd I'm fairly close (I think)
<ajmitch> bddebian: why?
<ajmitch> bddebian: you have checked upstream, right?
<bddebian> ajmitch: Sort of
<ajmitch> wonderful, zope 3.1.0 in debian
* mdz chuckles at #17035
* ajmitch gets an internal server error, which isn't too funny
<jdong> mdz: wow... that's what support communties are for :)
<jdong> mdz: ooh, ooh, send him off to the forums :)
<mdz> jdong: doesn't /support/ link there?
<mdz> yep, it does
<jdong> mdz: yeah, 3 layers deep into links :)
<jdong> can someone with magical bugzilla powers mark 15281 INVALID? (nonexistent mirrormax repository)
<Amaranth> consider it done
<jdong> OT, any JFS users here? :)
<Amaranth> done
<jdong> Amaranth: thanks; and I just realized your title hasn't been updated at the forums yet...
<Amaranth> my title?
<jdong> Amaranth: yeah, you need a shiny developer tag :)
<Amaranth> jdong: I need to find the Login button first.
<jdong> enter's a magical key
<doko> mdz: any chance for a zope3 sync this week?
<mdz> doko: it looks reasonable except for the ZODB update; I don't know what comprises that
<jdong> Amaranth: there you go, now you show up as a developer (http://ubuntuforums.org/showpost.php?p=364417&postcount=4)
<mdz> that's like saying  "SCSI subsystem update" in the kernel
<Amaranth> ooh
<Amaranth> jdong: i was hoping it was a shiny image like the edit and quote buttons :)
<test> i did an update this morning and I have been having some weird idle disk activity, the disk activity blinks every second
<doko> mdz: nothing directly in main, I'm waiting for feedback from jinty about schooltool/schoolbell testing
<test> the light*
<mdz> doko: "nothing directly in main"?
<doko> mdz: nothing in zope3 uses zodb AFAIK
<mdz> doko: what specific changes are included in the ZODB update?
<jdong> Amaranth: we do need more shiny-ness
<test> all my systems are having this problem
<Amaranth> jdong: Can I be a moderator of the smeg forum yet?
<bddebian> Well shit, newer gnome-launch-box from svn wants gnome 2.0 stuff :-(
<Amaranth> 2.0?
<Amaranth> it should work with 2.12, backward compatibility and all that
<bddebian> Well I mean gnome-vfs-2.0
<blue22> hey is it normal to have my disk activity light go on every second, all my systems are doing it after a recent update today, can anyone help me?
<jdong> Amaranth: have I really forgot that???
<jdong> Amaranth: sorry :-/
<ajmitch> doko: ah, you did the zope3 update in debian? :)
<Amaranth> jdong: I've been asking people off and on since a week after the forum was created. :)
<ajmitch> doko: thanks, I've been starting to use it :)
<jdong> Amaranth: I apologize for that
<doko> mdz: http://www.zope.org/Products/ZODB3.5/NEWS.html, see the changes between 3.5.0 and 3.5.1
<spstarr> hmm, i think we have a package build problem in koffice -> karbon14
<spstarr> why is libdps* being linked in when they are depreciated ? (i know breezy has them in Xorg but they are not going to be there in 6.9+
<spstarr> or freetype as the koffice are saying might be doing
<Amaranth> jdong: I don't suppose you know why the quick reply button does nothing for me in firefox 1.5b1
<jdong> Amaranth: I think we've heard that one before
<jdong> Amaranth: we're using RC-quality builds right now; waiting for opportunity to upgrade... know of a few issues already, working on fixing them
<spstarr> n/m... i know why
<occy> is there a desktop team?  I know there was an ubuntu-art movement started, but I haven't heard much lately on that mailing list.
<bddebian> occy: #ubuntu-desktop
<occy> ahh
<wasabi_> Hey how can one blacklist a module from the initramfs?
<wasabi_> Hmm.
<robertj^> isn't ubuntu-desktop kinda redundant?
<bddebian> Probably :-)
<ajmitch> robertj^: why is that?
<robertj^> ajmitch: because everyone already thinks of Ubuntu as Debian for the Desktop or "That Penguin Windows thing"
<occy> robertj^, heh
<occy> Yeah, the team should be called: TUB 
<occy> The Ubuntu Beautifiers
<robertj^> ubuntu artwork doesn't interest me much
<robertj^> Rebranding = Reinventing the wheel
<robertj^> and 99% of users don't think its cool at all to have different icons on every distro
<robertj^> By the time users sit through the splash and look at the wallpaper at once, they know if its something they have seen before
<ajmitch> robertj^: the desktop team focuses more on desktop bugs & apps
<ajmitch> rather than artwork
<jsgotangco> yeah
<ajmitch> hey jsgotangco :)
<jsgotangco> ajmitch: g'day m8
<jdub> robertj^: artwork goes way beyond the default desktop artwork (and in fact, the ubuntu-art team don't actually do that yet anyway)
<robertj^> jdub: I know. Anything that goes upstream is great
<robertj^> ajmitch: I hope it doesn't turn into cdplayer1 vs cdplayer2 vs DJ X flamewar ;)
<ajmitch> robertj^: it's *constructive* work ;)
<robertj^> is it going to appear on the community page any time soon?
<ajmitch> on http://www.ubuntu.com/community/teams/ ?
<ajmitch> the desktop team link?
* jdub puts a new poll up on the fridge
<robertj^> ahh, didn't even realize that was a link!
<jsgotangco> ubuntu logo with hearts?
<robertj^> jdub: you need some fridge magnet poetry of the day
<occy> jdub, if you need someone who's interested in helping.  I'm here.  Do you already have your team picked?
<jsgotangco> don't even let mako do the magnet poetry or else we'll be R-18
<robertj^> getting it to look right at the angle the fridge is at would be difficult though
<jdub> occy: the teams are open, jump on the lists
<robertj^> hehe, btw speaking of usability I saw someone accidently click the desktop pager today
<occy> jdub, I joined the ubuntu-art list
<occy> I'm guessing that's not what I want.
<occy> and it seems dead ATM.
<jsgotangco> not dead, just quiet
<occy> ok
<jsgotangco> (you can always check the archives anyway)
<occy> I don't have tons of time to devote to tracking things down, but if there is a project manager for the UD team who can assign some tasks, I'll be glad to help however I can.
<robertj^> is there a story for the I want a pony on the fridge?
<occy> robertj^, heh
<Amaranth> the fridge? it actually exists?
<jdub> occy: it's only recently started, doesn't have a huge mission yet, it'll pick up
<occy> robertj^, Many years ago, when the moon was blue, instead of grey, there was this ancient pony... 
<jdub> Amaranth: yes, for ages now
<jdub> robertj^: no :)
<jdub> robertj^: well
<jdub> robertj^: well, no :)
<Amaranth> link?
<robertj^> and if so, do you have the appropriate magnets to...
<jdub> fridge.ubuntu.com
<occy> heh
<occy> jdub, k, well... I'm sure you know how to find me.  I'll try and do my best to monitor #ubuntu-desktop.
<jdub> ok
<occy> cheers gang.
<whiprush> jdub: hey.
<jdub> yo!
* robertj^ actually ponders a bit of code he has that could be converted into multiuser fridge poetry
<whiprush> so, which things am I covering now? For the top 10?
<jdub> whiprush: name your topics
<Amaranth> ack, lightning is getting really close
<Amaranth> i should probably turn this thing off
<whiprush> gimme a few whilst I dig out my laptop
<jdub> ok
* jdub will dry hair in the mean time
<robertj^> what top 10 is this?
<jdub> countdown to breezy features
<jsgotangco> whiprush: you edit for the fridge atm?
<jdong> jfsutils should be bumped to 1.1.9.... stack overflow
<jdong> http://cvs.sourceforge.net/viewcvs.py/jfs/jfsutils/NEWS?rev=1.26&content-type=text
<whiprush> I have, in no particular order: "Edubuntu, Laptop Love, Launchpad Integration, Summer of Code stuff, OOo2, Universe Tour, 'GNOME stuff that isn't in stock gnome like serpentine and smeg', LTSP integration"
<whiprush> jsgotangco: yeah trying to catch up actually. :p
<Amaranth> what about smeg?
<jsgotangco> Amaranth: the guy from pc world thinks the name is horrible
<jsgotangco> heh
<Amaranth> :)
<whiprush> nothing, I think it would be cool if we highlighted what things make our desktop unique from say, vanilla 2.12.
<jdub> whiprush: for the gnome stuff, let's just make that "new desktop features" (including links to GNOME 2.12 tour and release notes)
<Amaranth> it's supposed to be offensive
<robertj^> smeg is really pretty immature IMO
<whiprush> okey
<Amaranth> robertj^: in what way?
<jdub> whiprush: splat them all on, they don't have to go public all at once, we can whip them through editing rounds and then publish day by day
<whiprush> ah, good point.
<jdub> whiprush: we're just off 10 days, so let's not call it a top 10 countdown, just a countdown :-)
<robertj^> Amaranth: sounds suspciously like smegma no?
<whiprush> heh
<whiprush> ok.
<jsgotangco> i can edit if there is a need for more hands
<whiprush> nothing wrong with going past release either.
* jdub is figuring out what to write for a countdown announce post, so he can officially announce the fridge
<whiprush> I mean, keep going.
<jdub> yeah, totally
<whiprush> that flickr box was genious
<whiprush> kudos to that
* jdub was glad the thumbnails fit
<jsgotangco> yeah
<jsgotangco> they rock
<jdub> i should probably do it a little more anal retentively, given that it's all based on spaces atm
<ajmitch> whiprush: you mean the one with software that's not in breezy? ;)
<Amaranth> robertj^: well, it was supposed to be a red dwarf reference
<jdub> "Its round Its magnetic Stick it on your real fridge!" <- ha ha ha
<jsgotangco> the filter is just based in "ubuntu"?
<jdub> jsgotangco: yeah, using the ubuntu tag
<jdub> so if people start tagging pr0n with ubuntu, we'll have to do something :)
<Amaranth> robertj^: iow, a generic swear word (you smegging lunatic, smeg off, etc)
<ajmitch> jdub: so if I put up my UDU photos tagged with ubuntu..?
<jdub> Amaranth: do you know what it actually means?
<whiprush> jdub: "udu" and "ubz" would be good ones too
<jdub> ajmitch: aye
<jdub> whiprush: stupidly, you can't do really useful expressions and get feeds out of them
<Amaranth> jdub: Nope, just what I've already said.
* ajmitch wants flickr.net support in f-spot before he uses flickr too much :)
<Amaranth> jdub: Unless you mean it's short for smegma.
<whiprush> it can export to flickr
<bddebian> ewww
<jdub> but i suspect people will tag conference photos with ubuntu anyway
<jdub> Amaranth: yes
<jsgotangco> yes
<ajmitch> whiprush: no, it does old-style flickr auth
<ajmitch> whiprush: so new accounts don't work with it
* whiprush tries to figure out how to add draft content on the fridge.
<whiprush> ajmitch: man, weak. :(
<ajmitch> whiprush: dude, I know
<Amaranth> jdub: I knew it as a swear word, the menu spec makes me swear repeatedly, seemed like a perfect match.
<ajmitch> lewing hasn't had time to update it
<jdub> whiprush: log in, click 'contribute'
<Amaranth> Unless someone can come up with a better (non-boring) name. :)
<ajmitch> so I should probably dive in & hack it
<whiprush> ah
<whiprush> i was looking in administrate
<Amaranth> I wanted to call it gnome-menu-editor but manny beat me by about a month.
<robertj^> Amaranth: how about MooCow?
<jdub> Amaranth: call it wtrgmepsu
<Amaranth> meh
<whiprush> what did you call the universe tour?
<whiprush> stars of the universe or something?
<jdub> whiprush: 'stars of the universe'?
<jdub> maybe 'stars of the ubuntu universe'
<jsgotangco> that sounds like a funkadelic tune
<Amaranth> jdub: Did you just slam your fists on the keyboard and hit enter to get that?
<jdub> though i try to avoid saying ubuntu too much on the fridge
<jdub> Amaranth: no, it's an acronym
<whiprush> I was thinking something like, "Warp tour of the Universe"
<ajmitch> I hope you say good stuff about the universe
<whiprush> like, hop into my ship, and let's hit the goodies.
<jsgotangco> warpt tour of the Universe in search for the mothership
<jdub> 'The Universe at Ludicrous Speed'
<whiprush> hahah
<ajmitch> jdub has already said nice things about the MOTUs, or at least one of them :)
<Amaranth> jdub: I'm lost, can you expand it? :)
<whiprush> "MOTUs have gone the Plaid!"
<jdub> he
<jdub> h
<jdub> Amaranth: 'will the real gnome menu editor please stand up'
<robertj^> I think the #1 feature for Hoary should be no more ubuntu spatial ;)
<robertj^> err Breezy
<Amaranth> w00t, i think we have a winner ;)
<jdub> whiprush: in 'new desktop stuff' -> "greatly improved file management experience"
<whiprush> k
<jdub> whiprush: "corrected everyone's stupidity"
<whiprush> ooh, a tour of that should be good.
<jdub> whiprush: "would you believe THIS CLOSE to solving worldwide famine"
<Amaranth> robertj^: I think the #1 feature for breezy should be no more spacial, period. ;)
<jdub> oh, a good thing for the new desktop stuff is snaps of the new artwork
<whiprush> jdub: I'm gonna add a few, even though most of it is rough crap right now.
<jdub> whiprush: no probs
<robertj^> Amaranth: oh that the icons of the desktop would disappear and it would no longer blight my home directory
<jdub> whiprush: maybe put DRAFT in the titles of the ones you don't want edited for publishing?
<whiprush> ok
<jsgotangco> err
<jdub> (where edited means, "jeff gets anal retentive about tagging, grammar, punctuation, etc" rather than "let's add extra bits"
<jsgotangco> are you doing a quick tour???
<whiprush> access denied, can't edit the title.
<jdub> jsgotangco: we're doing a bunch of stories pimping cool shit in breezy as we count down to its release
<whiprush> anyone know if corey is still doing that tour thing?
<jsgotangco> jdub: ahhh
<jsgotangco> whiprush: it seems he's been busy and it lacks screenshots
<whiprush> hmmm
<whiprush> His stuff is real good.
<jmg> hey all
<whiprush> I say we rip off lots of his stuff.
<whiprush> :p
<jsgotangco> let me check if there is an update
<whiprush> k
<jsgotangco> whiprush: sure
<jdub> whiprush: maybe we should chat to him about authoring it for the fridge - might be a better venue for it than 'random web page somewhere'
<whiprush> jdub: yeah
<jmg> anyone see messages about version 18 of wireless extension?
* jdub defines all of www.ubuntu.com to be 'random web page somewhere'
<whiprush> since, like, both me and him fell off the face of the planet each have half finished projects ...
<jmg> Warning: Driver for device wifi0 recommend version 18 of Wireless Extension, but has been compiled with version 17, therefore some driver features may not be available...
<jmg> using hostap driver compiled with module-assistant
<jmg> any idea?
<Amaranth> jdub: I think I'll go with wtrgmepsu, I just need to get more opinions. :) Also, I'm concerned about people not knowing how to spell it to install it.
<jsgotangco> whiprush: https://docteam.ubuntu.com/repos/branches/breezy/gnome/quicktour/ svn please
<jsgotangco> it lacks screenshots at the moment
<jmg> hmm
<whiprush> jdub: I did a [TOUR]  one so it doesn't get mixed in with the other stuff
<whiprush> k, now, how do I go back and reedit?
<whiprush> I'll start with these three.
<jdub> it's not letting you change those?
<robertj^> jsgotangco: that intro seems kinda geeky to me
<whiprush> I get a Coming Soon!
<jdub> when you click edit, or when you go to the node?
<whiprush> no, I have a "view"
<whiprush> clicking on it spits out an access denied on the log
<jdub> you totally have 'edit own stories' privileges
<jdub> fascist
<whiprush> I blame the software!
<jdub> so do i!
<robertj^> Automatic Updates are good, PDF viewing is good although speed is probably not an issue most people care about, OO2 is good.
<jdub> whiprush: sec
<jdub> whiprush: try again
<whiprush> man, that icon turned out sweet.
<whiprush> And they laughed at us in Sydney. pffft.
<ajmitch> whiprush: well yeah.. ;)
<whiprush> jdub: booyah
<jdub> which icon?
<whiprush> the fridge
<whiprush> what else?
<jdub> oh
<robertj^> whip: it is. I still say there needs to be fridge magnet poetry on it though
<whiprush> any gotchas on editing in the cms or is it like the wiki? (locks and stuff)
<whiprush> heh, trendy Fridge AJAX magnet poetry.
<robertj^> btw I've got an A with a circumflex of some sort over it next to the read more link
<jdub> whiprush: no locks, but i think it detects changes made underneath you
<whiprush> k
<whiprush> I'll be in the universe tour. :)
<jdub> robertj^: what locale are you in?
<robertj^> US English with current Safari
<jdub> ah, safari
<robertj^> (my wife stole my laptop!)
<jdub> interesting
<jdub> i haven't tried it in safari yet
<jdub> i should reinstall osx on my ibook
<robertj^> jdub: btw Safari really sucks
<robertj^> especially because 10.2.8 users have a really busted version that chokes on perfectly good css
<jdub> well hey, if you build on sand...
<jdub> ;-) ;-) ;-)
<Amaranth> ooh, bad mouthing khtml, you've got guts
<robertj^> hehe. 2/4 servers are running Ubuntu
<Amaranth> those guys will eat you up, spit you out, then take a piss on the remains :D
<robertj^> file server may be next though
<Amaranth> your fileserver isn't running linux? that seems to be the only thing anyone ever uses it for if they don't use it on the desktop
<robertj^> Amaranth: Open Directory isn't all terrible
<Amaranth> does not compute
<robertj^> Open Directory = Kerberos + slapd
<robertj^> + some replication framework over ssh that uses chewing gum and rubber bands but sometimes works
* jdub chuckles at http://searchdns.netcraft.com/?host=*.ubuntu.com -> the AIX cluster in sweden :)
<robertj^> I need to check again but last time I looked samba + ldap in Debian was a minor black art
<maswan> jdub: :)
* maswan huggles AIX
<jdub> whiprush: you going to be at UBZ?
<whiprush> jdub: I will try to make it for a few days
<jdub> whiprush: love day?
<whiprush> someone from our loco team will be there though along with jam
<whiprush> jdub: probably, will try to come for the whole event.
<crimsun> whiprush: hey, I understand you met Kevin Otte and Jason Tower from TriLUG at OLF
<whiprush> yeah.
<maswan> Hmm.. where/when is the next ubuntu conf?
<wasabi_> don't suppose there is any idea what would make this system reboot immediatly upon grub completing.
<maswan> is that known yet?
<wasabi_> doesn't even look like it loads the kernel
<jdub> maswan: nup
<maswan> jdub: Ok, I was thinking of trying to get to it and perhaps even present, if I get around to it. :)
<jdub> maswan: rawk :)
<jdub> maswan: though we don't really have 'presentations'
<jdub> oh, except for ubuntu love day
<maswan> jdub: well, yeah, bof session on a theme would be much more my style anyway. :)
<maswan> jdub: but then, if things go well, we'll love ubuntu by then and might want to share the love
<jdub> maswan: spec-writing? :-)
<maswan> jdub: right. as soon as I get around to it. :)
<`anthony> is there something wrong with apt and universe at the moment? WARNING: The following packages cannot be authenticated!
<`anthony>  ncftp
<`anthony> with breezy
<`anthony> that's an up-to-date breezy, too
<maswan> jdub: thing is, if I "present", that's a plus in the "convincing boss to pay trip" struggle. ;)
<jdub> `anthony: do a couple of apt-get updates
<wasabi_> Oooh. Annoying grubish bu
<wasabi_> bug
<wasabi_> I need menu.lst to be autogenerated without /boot on the prefix
<jbailey> Eh?
<jbailey> You wnat it in /grub/menu.lst?
<wasabi_> yup
<jbailey> And that's desirable, how? =)
<wasabi_> well, mostly it's the autogenerated kernel and initrd lines
<wasabi_> They expect /boot/vmlinuz*
<jbailey> Remove link_in_boot = yes
<jbailey> from /etc/kernel-img.conf
<wasabi_> ahh
<wasabi_> my boot partition is a vfat drive. ;)
<wasabi_> I can't support links haha
<jbailey> Err.
<jbailey> eww. =)
<wasabi_> Yeah. This is that embedded system.
<jbailey> You might just want to get rid of the do_symlinks = yes
<jbailey> option then
<wasabi_> /dev/hda1 is a flash device with the kernel and initrd and root.img
<jbailey> update-grub doesn't need them.
<wasabi_> being able to "flash" updates to it from windows, just by copying some files to it, is pretty slick
<wasabi_> ok
<jbailey> Remember to actually delete the old symlinks, though.
<jbailey> update-initramfs will use them if they're present, otherwise fall back to the highest versioned kernel.
<jbailey> But as long as theyr'e there, it expects them to be useful.
<wasabi_> nope, that didn't do it.
<wasabi_> It's update-grub which is rebuilding the menu.lst
<jbailey> Right.
<jbailey> but update-grub doesn't touch the symlinks
<jbailey> So what problem are you trying to solve?
<jbailey> (going to be in a couple of minutes)
<wasabi_> okay, embedded system. removable compact flash disk for /boot
<wasabi_> root exists as a loopback fs in /boot
<wasabi_> /boot/root.img
<wasabi_> So boot contains the basics, kernel, initrd, root.img
<wasabi_> grub boots, loads kernel from /boot, loads initrd from /boot. initrd will setup root.img as a loopback device and mount it as root.
<jmg> guys i have an issue with wireless in breezy
<jmg> Warning: Driver for device eth2 recommend version 18 of Wireless Extension,
<jmg> but has been compiled with version 17, therefore some driver features
<jmg> may not be available...
<wasabi_> update-grub adds this:
<jmg> i am using hostap driver compiled with modutils
<jmg> depended library outdated?
<wasabi_> kernel          /boot/vmlinuz-2.6.12-9-686 root=/dev/loop0 ro
<wasabi_>  /boot is an invalid path, as there is no /boot in /boot
<jbailey> Oh.
<jbailey> So update-grub itself is not detecting that /boot is a separate partition.
* jbailey tries to find a machine with grub installed.
<wasabi_> yeah.
<wasabi_> it looks like that works, when /boot/boot -> .
<wasabi_> my /boot is vfat, and doesn't support symlinks though
<jbailey> Well, it looks like it wlaks the fstab
<jbailey> I'm too sleepy to dig through shell code atm
<jbailey> I suspect you need the bit where grub_root_device is set.
<jbailey> Mm, no
<jbailey> kernel_dir=/boot
<jbailey> It looks like if prunes that off if it gets a value for $boot_device
<jbailey> And to get that, it needs to exist in /etc/fstab
<wasabi_> Heh. I really have to think about wtf is going to be in fstab
<jbailey> No kiddin'
<jbailey> I can't imagine there's much I can offer you for changes in breezy, but I can see it being reasonable to be able to override this in the config file somehow for dapper/
<jbailey> Sleep now. =)
<magnon> sleep well
<magnon> greet the lady
<jbailey> Thanks. =)
<\sh> morning
* ajmitch waves to \sh  :)
<wasabi_> wow man this is really annoying the heck out of me. kernel loads, system reboots.
<wasabi_> has to be something with how I have grub set up
<jmg> anyone here use hostap drivers? when i load i get not one but two ether devices
<Lathiat> jmg: This is the wrong place for help with that, this channel is for ubuntu development, try the home page/irc channel/lists for hostap 
<fabbione> morning guys
<synackuator> evening
<jdub> mdz: ping
<fabbione> mdz: ping?
<pitti> Good morning
<pitti> mdz: do you have a minute?
* pitti works offline for a bit due to his broken internet connectino
<wasabi_> finally got the thing to boot the initrd
<wasabi_> now I can finally work on the mount scripts
<fabbione> mdz, Kamion: is the preferred approval method still to upload and request the approval? or do you prefer to see the changes first?
<fabbione> daniels: ping?
<infinity> fabbione : The impression I get is that it depends on the changes.  Small/obvious ones should be okay with "upload, then request", bigger shit should involve requesting first to avoid the effort of a big argument followed by a REJECT.
<fabbione> infinity: ok.. i will wait
<fabbione> it's not big change, but on a big package
<pitti> Kamion: Is it generally too late to drop mozilla-browser from main? Or would you still accept an easy change that would allow us to drop it?
<pitti> mdz: ^ same question
<infinity> pitti : How easy would it be to shove it out to universe?
<infinity> pitti : And do you mean the whole source package?
<pitti> infinity: I need to copy the m-browser's shared libs to m-dev and drop the dependency
<pitti> infinity: no, just the m-browser .deb
<dholbach> good morning
<infinity> pitti : Ahh.
<pitti> infinity: we can't drop the whole source at this stage
<fabbione> pitti: it's probably not worth it
<infinity> pitti : I'm not sure that's worth the effort.
<pitti> Hi dholbach 
<dholbach> hey martin
<pitti> infinity: but it is -browser which has all the vulns
<infinity> pitti : And -mailnews has enough.
<infinity> pitti : And if we're doing new upstream releases to fix -mailnews, then we're getting -browser fixes for free.
<lifeless> silly question, but is the acpi-support maintainer field accurate ?
<fabbione> pitti: given that the source is in main, it won't make any difference for you
<pitti> infinity: -mailnews is universe
<infinity> pitti : Oh, cute.  So, you're proposing moving everything but -dev to universe?
<pitti> fabbione: if the deb was in universe, we can care much less about updates
<infinity> pitti : So we can just bury our heads in the sand about vulns?
<pitti> infinity: the only change would be to move -browser to universe
<fabbione> pitti: and how can you be 100% sure that the vuln fix will not hit -dev too?
<pitti> infinity: we agreed to not *want* to suppose mozilla any more
<pitti> fabbione: by reading the MFSAs, which I have to do anyway
<jsgotangco> hey everyone we're building up Release notes for breezy please contribute appropriate entries for known bugs, faqs, etc. at https://wiki.ubuntu.com/BreezyReleaseNotes
<pitti> infinity: for dapper we need to completely drop it to universe anyway, unless we want to go to hell
<fabbione> let's go to hell!!!
<fabbione> that's what all users tell me anyway :P
<fabbione> at least i won't be alone anymore ;)
<infinity> pitti : Yeah, probably, but that likely means tougher work, like making sure things that want mozilla-dev can build against firefox-dev and such, not praying that vulns won't ever hit mozilla-dev. :)
<jsgotangco> lol
<doko> fabbione: but then you are in bad company ... ;-P
<pitti> infinity: there are only three main packages that use m-dev
<fabbione> doko: no no.. that's because i love you all :)
<pitti> infinity: and one builds clean against f-dev
<pitti> infinity: I talked with doko about OO.o (the second package)
<pitti> infinity: and we can certainly find a solution for enigmail
<infinity> pitti : I can probably split enigmail into two source packages, if we have to.
<pitti> infinity: for dapper that might be necessary, yes
<infinity> pitti : I'm just sayting that, for now, we can't drop mozilla-dev, we're way too late for that, and I'm not entirely sure how much we buy from dropping -browser and keeping -dev.
<infinity> (But argue away... I'm not done with my arguing for the week either, I'm sure) :)
<doko> Noooooooooooooo, the OO.u fonts for the user interface did change. Diziet !!!!!!!
<infinity> OO.u?
<doko> s/u/o/
<pitti> infinity: OpenOffice unlimited :-)
<doko> infinity: but we can split -browser in -libs and -browser and demote -browser
<infinity> doko : What did they change from/to?... The look okay to me..
<pitti> infinity, Kamion: btw, this is the debdiff we talk about: http://people.ubuntu.com/~pitti/patches/mozilla.diff
<doko> for me it looks like a condensed font, see http://people.debian.org/~doko/tmp/ooo/Screenshot.png
<infinity> pitti : Ugh.  Having identical files in both packages and a Replaces is Just Plain Wrong.
<pitti> infinity: the clean alternative would be to split them out into mozilla-libs
<pitti> infinity: but that requires an additional package; it's fine for me, too, though
<infinity> doko : Uhh, do I need to install something special to get help?
<pitti> infinity: but for testing buildability of the rdepends it's good enough
<infinity> doko : I just get "The help system could not be started"
<doko> infinity: no, that's something else, but look at the window in the background. same font
<infinity> doko : Yeah, looks okay here.  Whacky.
<infinity> doko : So, why doesn't help work? :)
<pitti> infinity: so in terms of testing, librsvg2 and enigmail work perfectly with this; this leaves me with OO.o which I can't test without a proper internet connection...
<seb128> hi
<seb128> so, who broke my fonts? :)
<doko> infinity: ask again, and you will debug it ... 
<pitti> Hi seb128 
<seb128> hey pitti 
<seb128> Diziet: your 2.3.2-1ubuntu3 breaks my "Fixed" font
<seb128> ups
<seb128> Diziet: your fontconfig 2.3.2-1ubuntu3 breaks my "Fixed" font, downgrading to 2.3.2-1ubuntu2 fixes the issue
<tepsipakki> seb128: which size do you use? I've had problems with Fixed 10 for ages
<seb128> Fixed 20
<seb128> which was working fine for months
<fabbione> hmmm
<tepsipakki> that's big =
<seb128> until today
<tepsipakki> =)
* fabbione checks fontconfig
<seb128> tepsipakki: that uses my 10x10 font
<seb128> ups
<seb128> 10x20
<seb128> which is not that big
<tepsipakki> copying the font in .fonts should fix it?
<seb128> the fonts are from .fonts
<tepsipakki> does it for the Fixed 10 (ie. 6x13)
<seb128> for months
<tepsipakki> ok
<seb128> what are you trying to prove? That the upgrade is right to break my working config ? :)
<fabbione> seb128: if i give a test pkg, can you try it?
<seb128> fabbione: sure
<fabbione> seb128: if so.. what arch?
<seb128> i386
<fabbione> ok
<tepsipakki> seb128: nono ;)
<tepsipakki> seb128: just thought that it might be similar to my problem
<fabbione> seb128: can you check what you have in /usr/lib/X11/fonts ?
<fabbione> i mean /usr/lib/X11
<fabbione> if fonts points to /usr/share/X11/fonts
<seb128> $ ls /usr/lib/X11
<seb128> fonts  locale  rgb.txt  x11perfcomp  xkb  xsm
<seb128> no, that's a folder
<fabbione> hmmm you sure?
<fabbione> it should be a symlink
<seb128> $ ls -l /usr/lib/X11/ | grep fonts
<seb128> drwxr-xr-x  2 root root 4096 2005-09-28 23:00 fonts
<fabbione> what's inside?
<seb128> $ ls /usr/lib/X11/fonts/
<seb128> 100dpi  75dpi  encodings  misc  Type1
<fabbione> and what's inside /usr/share/X11/fons ?
<seb128> lrwxrwxrwx  1 root root 31 2005-08-02 12:12 100dpi -> ../../../share/X11/fonts/100dpi
<seb128> lrwxrwxrwx  1 root root 30 2005-08-02 12:12 75dpi -> ../../../share/X11/fonts/75dpi
<seb128> etc
<fabbione> fonts even
<seb128> $ ls /usr/share/X11/fonts/
<seb128> 100dpi  75dpi  encodings  fonts.cache-1  misc  Type1
<seb128> 
<seb128> all dirs
<seb128> except the cache
<fabbione> ok
<fabbione> can you try this:
<fabbione> in /usr/lib/X11
<fabbione> mv fonts fonts-old
<fabbione> ln -sf /usr/share/X11/fonts /usr/lib/X11/fonts
<fabbione> install the latest fontconfig
<fabbione> and tell me if it works
<seb128> k
<fabbione> the cache files might be the culprit here
<seb128> the package update regenerates the cache 
<seb128> no?
<seb128> doesn't work
<fabbione> ok
<fabbione> hmm
<seb128> my fixed font comes from ~/.fonts
<seb128> if that makes any difference
<seb128> I've 10x20 pcf files here for it
<fabbione> what do you have in /usr/X11R6/lib/X11 ?
<fabbione> still fonts related
<fabbione> so skip the rest
<seb128> fonts beeing a dir
<fabbione> seb128: it shouldn't make any differenve
<seb128> $ ls /usr/X11R6/lib/X11/fonts/
<seb128> 100dpi  75dpi  encodings  fonts.cache-1  misc  Speedo  Type1  util
<fabbione> ok.. what's inside?
<seb128> all dirs
<seb128> except the cache
<fabbione> is there anything inside the dir?
<fabbione> +s
<fabbione> or there are only 4/5 files per dir
<fabbione> ?
<seb128> $ ls /usr/X11R6/lib/X11/fonts/100dpi/ | wc -l
<seb128> 1484
<fabbione> amen
<fabbione> something is utterly broken
<fabbione> they should be empty
<fabbione> or with 4/5 files
<seb128> I blame daniels 
<fabbione> can you do the same check in /usr/share/X11/fonts ?
<fabbione> i wonder if fonts have been migrated at all on your system
<seb128> $ ls /usr/share/X11/fonts/100dpi/ | wc -l
<seb128> 409
<fabbione> fixed is Type1 iirc
<fabbione> or misc
<seb128> my fixed font comes from ~/.fonts as said before
<fabbione> seb128: yes i get that
<fabbione> but the change in fontconfig doesn't change the use of ~/.fonts
<seb128> so whatever /usr/... are that should not change it, right?
<fabbione> it might fail because it doesn't find the proper fonts in /usr/*
<seb128> $ fc-match Fixed
<seb128> 12x13ja.pcf.gz: "Fixed" "Regular"
* seb128 downgrades
<seb128> $ fc-match Fixed
<seb128> 10x20.pcf: "Fixed" "Regular"
<seb128> 
<seb128> the new then previous version
<seb128> $ locate 12x13ja.pcf.gz
<seb128> /usr/share/X11/fonts/misc/12x13ja.pcf.gz
<fabbione> where 10x20.pcf comes from?
<seb128> ~/.fonts
<seb128> I already said it twice :p
<seb128> $ locate 10x20.pcf
<seb128> /home/seb128/.fonts/10x20.pcf
<seb128> /usr/share/X11/fonts/misc/10x20.pcf.gz
<fabbione> oh right... .gz
* pitti goes offline again, bbl
<seb128> fabbione: any other idea?
<fabbione> seb128: can you check the top of /etc/fonts/fonts.conf ?
<daniels> fontconfig is SO NOT MY PROBLEM
<fabbione> there should be a few entries like <dir>/path/</dir>
<seb128>         <dir>/usr/share/fonts</dir>
<seb128>         <dir>/usr/X11R6/lib/X11/fonts</dir> <dir>/usr/local/share/fonts</dir>
<seb128>         <dir>~/.fonts</dir>
<seb128> previous version
<seb128> let me upgrade
<fabbione> seb128: this is with the old one, right?
<fabbione> yeah
<fabbione> daniels: it might not be fontconfig
<fabbione> daniels: i suspect that on some upgrades xfont-core didn't move files/symlinks around as it should
<seb128>         <dir>/usr/share/fonts</dir>
<seb128>         <dir>/usr/share/X11/fonts</dir> <dir>/usr/local/share/fonts</dir>
<seb128>         <dir>~/.fonts</dir>
<fabbione> ok
<seb128> with the update
<fabbione> seb128: can you try add also <dir>/usr/X11R6/lib/X11/fonts</dir> ?
<daniels> fabbione: xfonts-core does not move symlinks around
<fabbione> daniels: i meant the source.. the binaries should be -100dpi and so on..
* daniels notes that 10x20.pcf.gz lives in xfonts-base, as it should, so that change is performing as advertised.
<daniels> at a wild guess, I'm going to say that it needs to be both, because some fonts haven't been migrated or so.  but if you're getting 10x20.pcf.gz, then -base is doing exactly what it should do.
<seb128> fabbione: is there any fontconfig stuff to run after updating the config file ?
<fabbione> daniels: yes.. that's why i was asking seb to add it :)
<fabbione> seb128: no idea... let me check
<daniels> seb128: invalidate your cache with fc-cache
<fabbione> fc-cache -f -v <-
<seb128> doesn't make a difference, weird
<seb128> fc-cache: "/usr/X11R6/lib/X11/fonts/misc": caching, 0 fonts, 0 dirs
<seb128> hum
<daniels> there shouldn't be anything in there
<fabbione> seb128: can you try to rebuild the package, adding /usr/X11R6/lib/X11/fonts into debian/rules?
<seb128> fabbione: sure
<fabbione> daniels: seb128 has like 1450 files in there...
<fabbione> seb128: 
<seb128> daniels: 
<fabbione> -DEB_CONFIGURE_EXTRA_FLAGS := --enable-docs --with-add-fonts=/usr/X11R6/lib/X11/fonts,/usr/local/share/fonts
<fabbione> +DEB_CONFIGURE_EXTRA_FLAGS := --enable-docs --with-add-fonts=/usr/share/X11/fonts,/usr/local/share/fonts
<seb128> $ ls /usr/X11R6/lib/X11/fonts/misc | wc -l
<seb128> 244
<fabbione> check that line
<fabbione> and add the 3rd path
<fabbione> daniels: what did you decide about mkdirhier?
<daniels> mdz: ping
<daniels> fabbione: will talk further about it with mdz; assign the bug back to me if you like
<fabbione> daniels:  i did already :)
<sivang> Good morning 
<fabbione> daniels: yesterday.. i added a comment about the patch available.. 
<seb128> fabbione: DEB_CONFIGURE_EXTRA_FLAGS := --enable-docs --with-add-fonts=/usr/share/X11/fonts,/usr/local/share/fonts,/usr/X11R6/lib/X11/fonts
<seb128>  doesn't fix the issue ... should I try placing it before?
<fabbione> daniels: and reassigned.. i didn't want to start another xorg upload pingponmg dance
<fabbione> seb128: that's really weird
<seb128> $ fc-match Fixed
<seb128> 12x13ja.pcf.gz: "Fixed" "Regular
<daniels> thanks
<sivang> daniels: morning
<seb128> still
<daniels> sivang: hi
<fabbione> seb128: try to put it before...
<fabbione> i doubt it can make any difference
* seb128 rebuilds
<sivang> seb128: you know that some of applets are crashing / not reloadable ?
<seb128> sivang: no
<seb128> sivang: which one?
<sivang> daniels: I've been experiencing terrible slow down in X the last couple of days, dragging and switching beween windows is a PAIN, anything you know about ?
<Lathiat> sivang: ati?
<daniels> sivang: running a radeon x300 or similar?
<sivang> daniels: nope. nvidia
<sivang> seb128: desktop switcher for start
<sivang> seb128: lemme remove panel from session and restart it
<seb128> sivang: have you fixed those lpi warnings?
<infinity> sivang : I accidentally clicked "don't reload" on one of my crashing applets, and since re-adding it, I can't reproduce the bug, so there goes my chances of debugging/tracing it. :/
<sivang> man
<seb128> fabbione: nop, the order doesn't matter, still broken
<sivang> damn proxy irssi failed on me
<fabbione> seb128: i wonder if something in the B-D did change in the meanwhile...
<fabbione> can you try to rebuild ubuntu2 
<fabbione> without any debian/rules change?
* seb128 build a package with /usr/X11R6/lib/X11/fonts,/usr/local/share/fonts
<fabbione> yeah exactly
<Cashel> Allo... seems gnome-devel for 2.12 isnt in the breezy repository.. just a little fyi... or correct me (please!) lol
<sivang> seb128: I have a perliminary patch, didn't test it yet - going to do that now. (btw, there are also compile time warnings that suggests why the warnings appear afterwards, something with incompatible types)
<seb128> oh, cool
<seb128> Cashel: that's an universe package you may want to speak with motu 
<seb128> fabbione: that fixes it
<Cashel> motu a regular in here? Perhaps I'll msg him next time I'm on.. .
<seb128> $ fc-match Fixed
<seb128> 10x20.pcf: "Fixed" "Regular"
<seb128> Cashel: #ubuntu-motu
<Cashel> ahhhh 
<Cashel> thanks.. 
<seb128> they are the guys working on universe packages
<seb128> np
<fabbione> ok.. so that excludes the B-D changes
<fabbione> ahhhh
<hunger> Cashel: motu = masters of the universe, the universe maintainers.
<Cashel> Ahhhh cute :P
<fabbione> seb128: can you please check confdefs.h with and without /usr/share/X11/fonts ???
<fabbione> seb128: there is an interesting check on paths in there..
<daniels> sivang: *shrug*, I haven't changed anything
<fabbione> seb128: perhaps we need to add /usr/share/X11/fonts there too
<dholbach> good morning mvo
<fabbione> (there = configure)
<mvo> hey dholbach 
<seb128> fabbione: k
* mvo catched a cold and feel awful today
<seb128> hey mvo 
<seb128> :(
<mvo> hey seb128 
<daniels> mvo: you too, hey?
<mvo> daniels: yeah :( my first this year 
<fabbione> seb128: thanks
<hunger> mvo: I hope you will feel better soon.
<mvo> hunger: thanks
<sivang> mvo: me too, I hate to catch a cold when it's still warm outside
<jsgotangco> the feeling is awful
<mvo> sivang: it's rather cold here in germany already :)
<sivang> mvo: ah :)
<hunger> mvo: Yes, the wether is getting really ugly already.
* sivang invites all the sun lovers to his place
<hunger> sivang: Will you pay for the trip? ;-)
<jsgotangco> a beach BOF would be rad
<sivang> hunger: hmm, I would have, if I could :-)
<hunger> sivang: I know that feeling:-) I'd love to invite some interestting people over to my place for a fun time:-)
<hunger> sivang: Of course I wouldn't dream of inviting somebody like myself;-)
<seb128> fabbione: the diff between 2 builds has just FC_FONTPATH/FC_ADD_FONTS changes for the config.h, the differents Makefiles, fonts.conf
<seb128> fabbione: and the code doesn't use the FC_...
<lucas> hi
<seb128> lu lucas 
<HrdwrBoB> hi
<lucas> how do I get a debian package (which is inside Debian/main) to be included in universe ?
<seb128> lucas: it's done automatically
<fabbione> seb128: dunno.. i have finished my options
<lucas> seb128: it has been in debian since mid-august, but isn't in universe yet. that's normal ?
<dholbach> lucas: we hit upstream version freeze, that's where the auto-syncs stopped
<seb128> lucas: we have stopped the auto-sync during august, Upstream Version Freeze, etc
<dholbach> lucas: which package are you talking about?
<lucas> ok
<lucas> feed2imap
<dholbach> is it any cool?
<lucas> I'm not the best one to talk about it ;)
<dholbach>  why is that? :)
<lucas> upstream + debian maintainer
<dholbach> hehe :)
<dholbach> lucas: sounds nice, from the description
<seb128> lucas: oh, you are a DD ?
<seb128> hey pitti 
<sivang> morning pitti 
<lucas> seb128: no, I just maintain this package
<pitti> Hi again
<pitti> I don't have any bugs I could fix safely for Breezy any more
<pitti> does anybody need a hand with something?
<lucas> seb128: I just started NM, and am currently waiting for my advocate to write something clever about me ;)
<sivang> pitti: I could use some
<pitti> I'm currently fixing pmount bugs, but that's not urgent...
<dholbach> pitti: desktop-bugs@lists.ubuntu.com :)
<seb128> lucas: oh, k :)
<daniels> pitti: sure
<seb128> lucas: pllaned to be motu too? :)
<pitti> Hi sivang 
<chmj> pitti: I think BenC could use a hand 
<daniels> pitti: #15372, as I don't have the time to work on it
<dholbach> oh seb does recruitment for us! :)
<pitti> dholbach: I have more than enough bugs, but none with simple fixes...
<doko> pitti: #11028 :-)
<dholbach> pitti: malone bug #1 :)
<lucas> seb128: I'm not sure exactly of what motu is. but from what I understand, I don't really like the approach. when you are a DD, you improve both Debian & Ubuntu. when you are a MOTU, you only improve ubuntu, right ?
* pitti taps foot until this $)$( bugzilla pushes his megabyte of bug page through the modem
<Kamion> pitti: I think it's far too late for this mozilla change, sorry
<daniels> pitti: oh, you're on a modem.  i'm so sorry.
<seb128> lucas: you can be a DD and a motu so you make sure that your package works fine on both, is imported, updated, etc :)
<dholbach> lucas: not necessarily, since the patches are provided too
<daniels> pitti: i spent a couple of months bitching about bz, then I got brodband
<lucas> ok
* lucas will read about MOTU :)
* dholbach invites lucas to #ubuntu-motu
<carlos> pitti, the language pack cronjob failed again, I'm creating a new one now manually (just in case you have your cronjob in place now)
<ajmitch> yay, new victims!
<pitti> Kamion: alright, then I keep the solution (or a cleaner one with a proper package split) for dapper
<pitti> carlos: I don't yet since I don't know the URL
<pitti> daniels: I have broadband 95% of the time, unfortunately 'now' belongs to the other 5%...
<zyga> hello folks
<carlos> pitti http://mawson.ubuntu.com/~carlos/rosetta-breezy.tar.gz
<pitti> carlos: that's always the current one?
<pitti> carlos: cool, then I will setup a fully automatic tarball generator cronjob :-)
<carlos> pitti, yes, as you asked
<seb128> Riddell: the Debian maintainer says we don't want to move gconf depends away for -misc, playbin uses gconf by example
<seb128> carlos: hey. What's going on with rosetta? It's broken for me since yesterday
<carlos> seb128, define broken, please
<fabbione> pitti: ping?
<pitti> Hey Mr. Nitto
<fabbione> eheh
<zyga> pitti: hi, potfiles are around I smell :)
<fabbione> pitti: any news about that kernel security patch?
<pitti> fabbione: still not, I will contact you ASAP
<fabbione> pitti: ok
<pitti> fabbione: I'm afraid we have to do this one as an USN
<pitti> zyga: yes :-)
<pitti> zyga: I'll export the automatically generated tarball to people.u.c
<zyga> pitti: excellent :)
<zyga> pitti: will the URL be stable?
<zyga> Kamion: do you have a moment?
<Kamion> zyga: yes?
<fabbione> pitti: works for me more or less
<pitti> zyga: yes
<seb128> carlos: " Oops Sorry, something just went wrong in Launchpad. "
<zyga> Kamion: I wanted to ask about realistic chaces of ruby upgrade from 1.8.2-9 with some patches to 1.8.3-1, from unstable
<carlos> seb128, URL?
<zyga> Kamion: current ruby is broken
<seb128> carlos: I had that yesterday and this morning but seems to work now
<seb128> carlos: I was trying to update gdm fr.po file
<Kamion> zyga: "broken"?
<carlos> seb128, the /+lang/fr?
<seb128> carlos: https://launchpad.net/distros/ubuntu/breezy/+sources/gdm/+pots/gdm/fr/+translate
<seb128> carlos: but that just worked
<carlos> seb128, hmmm, that smells like a timeout problem...
<zyga> Kamion: some issues that were fixed for 1.8.3 are present
<seb128> carlos: grrr, I get those all the time
<zyga> Kamion: for example alexandria triggers internal ruby errors
<zyga> Kamion: I know that breezy is around the corner
<carlos> seb128, please file bugs
<seb128> carlos: you are saying that nobody knows that it timeout all the time? That's probably a load issue or something
<carlos> seb128, yeah, it's related to load issues
<daniels> god, I can't believe how much of a mess XKB was pre-xkeyboard-config
<Kamion> zyga: surely those changes can be backported?
<Kamion> zyga: release candidate is TOMORROW
<zyga> Kamion: I'm unable to do such backports - the diff is rather longish and I'm not familiar with ruby
<zyga> Kamion: all I can say is that 1.8.3-1 worked for me and fixed the issue
<Kamion> zyga: we cannot just blindly update at this point
<zyga> Kamion: understood
<Kamion> we need to know the important diffs
<zyga> Kamion: I had a look and it's a minefield IMHO 
<daniels> christ, what is it with ruby and HOLY SHIT UPDATES right at release time
<chmj> huh?
<daniels> we had the same problem in hoary
<Kamion> and ruby 1.8.3 includes a shlibs bump
<Kamion> zyga: I don't think we can do this without somebody who knows ruby well who is present and can look after issues, and for that somebody to have been around since a couple of weeks ago
<pitti> fabbione: However, I just saw another hole: http://bugs.gentoo.org/show_bug.cgi?id=107893
<pitti> fabbione: it's an easy and nonintrusive patch
<fabbione> pitti: let me look..
<zyga> Kamion: okay, I knew that is a lost cause - I just wanted to ask
<pitti> fabbione: and we recently had something that could exploit writable sysfs files
<fabbione> pitti: ok.. i am on it
<Kamion> zyga: I realise ruby has long been a problem in Ubuntu (as daniels alludes to), but the only real way to sort that out is to have somebody paying attention to it
<pitti> Kamion: is it too late to get security patches into the kernel?
<lucas> Kamion: say I want to look at this ruby problem. When do you need an answer ?
<pitti> Kamion: it's an easy one-liner fix, but I don't know about d-i interactions
<Kamion> lucas: last week
<Kamion> lucas: if you think you can backport a change from 1.8.3, it will probably have to be within 24 hours
<Kamion> pitti: sigh
<fabbione> Kamion: i am on it already..
<daniels> pitti: if you're just talking about the drm stuff, making that file non-world-writable is fine
<Kamion> pitti: mandatory for RC?
<Kamion> I guess we might as well, grumble
<pitti> Kamion: not really urgent
<Kamion> well, we'll need it for breezy final anyway
<lucas> Kamion: I'll see what I can do
<pitti> Kamion: something we should eventually fix, but nothing really scary
<daniels> as the name implies, it's just debugging stuff -- not touched by anything except the user when airlied wants crazy debugging output
<fabbione> daniels: it's still a hole tho
<pitti> daniels: no sysfs file should be world-writable, there even was a vuln about exploiting this to a DoS
<daniels> right, that's why I'm saying it's safe
<pitti> daniels: the vuln itself just allows you to trigger some printks
<daniels> -> nothing relies on it being world-writable
<daniels> pitti: i know what echoing 1 to that file does :)
<Kamion> pitti: today's schedule is that d-i has to be built (which must come after everything included in the initrd is built, i.e. obviously the kernel), and then RCC images have to be built and somewhat tested; this all has to be done before 16:45 London time, when I leave to catch a train
<pitti> Kamion: I leave the decision to you; it's not a biggie, as I said
<Kamion> pitti: my inclination is to commit to doing another d-i rebuild for final
<\sh> mvo, ping
<Kamion> hmm, best start working through ReleaseChecklist
<mvo> \sh: pong
<\sh> mvo, https://launchpad.net/distros/ubuntu/+sources/cdrdao/+bug/2765 <- u implemented the last patch for it...but it looks like we have the same issue 
* mvo looks
<mvo> \sh: I'll comment on this
<mvo> \sh: I wonder a) if it works for him on cdrecord b) why he wants it, the symlink /dev/cdrw should work fine, no?
<Kamion> zyga: BTW, are there bugs filed about these issues?
<\sh> mvo, I actually don't know..but scanbus is not working I checked it this morning...
<\sh> mvo, but should work if you have more then one burner in your server ;)
<zyga> Kamion: no, there are no bugs filed about this at all
<mvo> \sh: yes :) looking at it now
<zyga> Kamion: I didn't have time to file a proper bug as I'm killed by tons of work IRL
<\sh> mvo, I wonder, if we should morgue cdrdao ;) cause cdrecord can handle bin/cue 
<zyga> Kamion: I did get a word from ruby people arund the net that the issues were simply fixed later
<lifeless> is this the ruby doesn't wrk with rails issue ?
<Kamion> zyga: ok, I'm afraid we are generally unable to effectively track things not filed as bugs
<Kamion> because we are also killed by tons of work ;)
<zyga> Kamion: real time sucks near releases doesn't it?
<Kamion> zyga: s/near releases //
<sivang> Kamion: lol
<mvo> \sh: probably not, it's used by nautilus-cd-burner to copy audio cds 
<lucas> 1.8.2-9 was uploaded in Debian on 2005-06-29, 1.8.3-1 on 2005-09-20. analyzing the diff doesn't look possible
<lucas> if it's 4.1M
<lifeless> zyga: ^^ ?
<zyga> lifeless: ? :)
<lucas> zyga: I think the best we can do is make sure this doesn't happen again for breezy+1
<lifeless> zyga: I was told that current breezy's ruby fails to run ruby on rails
<zyga> lifeless: no no no
<lifeless> zyga: I'm asking if thats what you are talking about
<zyga> lifeless: it fails on alexandia 0.6.1
<lucas> lifeless: it might be because of the rubygems issue
<zyga> lifeless: I don't touch ruby on rails
<lifeless> lucas: is this known ?
<fabbione> pitti: i am going to give the same love to hoary..
<Kamion> ruby seems to be moving very quickly; I think we really need somebody looking after it in order to effectively avoid these problems
<\sh> mvo, oergs
<lifeless> Kamion: likely.
<zyga> lifeless: maybe you know something about internal ruby errors in 1.8.2-9?
<pitti> fabbione: that'd be nice, thanks
<fabbione> pitti: what about warty?
<lifeless> zyga: nope, not at all sorry, I was simply carrying a favour for a friend
<fabbione> we are in a half/half situation
<zyga> lifeless: okay, thanks
<pitti> fabbione: right, we should discuss warty maintenance soon
<pitti> fabbione: Herbert's contract ended
<lucas> lifeless: rails packaging sucks because they only distribute gems now
<lifeless> and gems are what - small bundles of source?
<lifeless> or a ruby specific vcs ?
<fabbione> pitti: yes, but he still has the last changes on his hd...
<lucas> a ruby-specific packaging system
<lucas> which sucks.
<lucas> but ruby people find it cool
<pitti> fabbione: his current debdiff could be helpful then?
<zyga> if you need someone to look after ruby for dapper feel free to take me :)
<lucas> ZygmuntKrynicki <= that's you ?
<pitti> fabbione: the patch for the other vuln was trivial, so it's probably not much work to redo it, but we can ask him anyway
<zyga> I'm novice as far as debian/ubuntu is concerned but I learn quickly and know my way around source :)
<zyga> lucas: yes
<Kamion> zyga: I'd rather somebody just did it than that somebody waited to be taken ...
<lucas> zyga: then you are on https://wiki.ubuntu.com/MOTURuby
<zyga> Kamion: well - I'll talk to you about this in a month when I'm less burdend by my work
<fabbione> pitti: yeah debdiff is enouhg of course
<zyga> :-)
<lucas> zyga: same here.
<fabbione> brb
<fabbione> pitti: ok.. i have breezy and hoary ready
<pitti> fabbione: thanks
<fabbione> pitti: no problem
<ajmitch> lamont or infinity: can you clear the dep-wait on phpmyadmin, please?
<fabbione> seb128: 16869 is for you, but i am not sure to which pkg reassing it..
<Kamion> Riddell: argh, your kubuntu seed sync wasn't a proper arch merge
<Kamion> Riddell: you *must* do this with 'baz replay' or 'baz merge' otherwise you ruin our ability to track which merges last happened.
<Kamion> Riddell: I will attempt to fix it up
<Kamion> (probably by reverting your change and starting again)
* fabbione blanks his CD's
* pitti goes offline again; cu later
<seb128> fabbione: commented/reassigned
<Kamion> ogra,dholbach: my comment about our support of jigdo was *only* about universe/multiverse
<fabbione> seb128: thanks
<Kamion> ogra,dholbach: jigdo is fully supported for our CD images
<ogra> Kamion, oh
<Kamion> I thought it was clear from the context of my mail
<dholbach> Kamion: thank you, will take a look at the mail again and correct my comment on bugzilla accordingly
<ogra> Kamion, not really, since the OP didnt specifically talk about universe
<Kamion> > Would it be possible to provide official jigdo templates for breezy
<Kamion> > for dvds of universe and multiverse? I know a lot of people who would
<Kamion> > really appreciate this.
<Kamion> It's unlikely to happen officially (the cdimage machine is already quite
<Kamion> busy, and jigdo-ing things takes ages), but I welcome efforts to do it
<Kamion> unofficially.
<Kamion> I fail to see how that was in any way unclear
<ogra> Kamion, oh, my fault
<Kamion> "official jigdo templates for breezy for dvds of universe and multiverse"
<ogra> i missed the mail in the middle :(
<ogra> > > > Hello, I have built three isos with the Ubuntu repositories
<ogra> > > > in three different DVDs, 1 for Main and a set of 2 isos for
<ogra> > > > Univerese and Multiverse.
<ogra> > >
<ogra> > > Do you think you could provide jigdo templates for use with
<ogra> > > jigdo-lite? So you could use the existing ubuntu mirrors for
<ogra> > > downloading.
<ogra> thats what i read ... sorry
<ogra> but dholbach fixed the bug anyway
<dholbach> only the first part of it
<Kamion> you can probably point to http://releases.ubuntu.com/jigit/, but check that that still works first
<Kamion> (it's a bit fragile)
<dholbach> merci beaucoup
<Kamion> just check for warty/hoary; the breezy one probably won't work due to the archive having moved on since then
<Kamion> don't have snapshot archives yet
<sivang> Interesting. Removing all apache packages leaves apache2 without a /etc/init.d/apache2 script for controlling
<ogra> Kamion, does the ubutu DVD contain a live part ? 
<Kamion> ogra: yes
<sivang> can anybody confirm that or is just me and my weird setup..
<sivang> ok, installing "apache" brings back the init.d script, however it controls the 1.3.33 one, and I want apache 2. argh
<infinity> sivang : Uhm.  What?
<infinity> sivang : /etc/init.d/apache2 ships in apache2-common.  It's a conffile, however, so if you deleted it by hand (did you?...), it won't be magically reinstalled without a "dpkg --force-confmiss -i apache2-common.deb"
<infinity> sivang : This is true of pretty much all init scripts.
<sivang> infinity: I didn't remove it by hand. But I will try with --forece-confmiss -i
<infinity> sivang : Well, something/someone did, and I guarantee it wasn't my maintainer scripts. :)
<sivang> infinity: ah right. I think I apt-get remove --purge apache-common and apach2-common
<sivang> infinity: thnks
<infinity> sivang : Erm, but if you removed apache2-common, that would have removed apache2-mpm-* too, which would remove the daemon.
<infinity> sivang : So you're missing more than just the init script.
<infinity> (And reinstalling it after a purge would bring the init script back)
<sivang> infinity: yes, it seems that after installing it and it would stop, but wouldn't start
<infinity> sivang : /etc/default/apache2
<janimo> infinity, is the large udeb problem deferred after RC? thanks
<infinity> janimo : No, it should be fixed for RC.  (the fixed upload/build is in)
<sivang> infinity: I have those installed:
<sivang> ii  apache2                               2.0.54-5ubuntu2                      next generation, scalable, extendable web se
<sivang> ii  apache2-common                        2.0.54-5ubuntu2                      next generation, scalable, extendable web se
<sivang> ii  apache2-mpm-prefork                   2.0.54-5ubuntu2                      traditional model for Apache2
<sivang> ii  apache2-utils                         2.0.54-5ubuntu2                      utility programs for webservers
<sivang> ii  libapache2-mod-php4                   4.4.0-2                              server-side, HTML-embedded scripting languag
<sivang> infinity: still no go at starting the daemon
<infinity> sivang : If port 80 wa sin use when apache2 was installed, /etc/default/apache2 would have been configured in a fashion that makes apache2 not start from the init scripts.
<infinity> sivang : So, edit that file, and you're good to go.
<sivang> infinity: k, will try that now - thanks
<infinity> sivang : Note that it prints a big blinking warning on install when it does that.
<Kamion> janimo: if you want to know about changes as they happen, subscribe to the breezy-changes mailing list
<sivang> infinity: it didn't
<sivang> infinity: and I have:
<sivang> #edit /etc/default/apache2 to change this.
<sivang> NO_START=0
<sivang> infinity: woops. the default one has it set, sorry
<sivang> infinity: does the init.d script prefer the /etc/default/apache value rather then the one set up in itself?
<janimo> Kamion, I follow breezy-changes, but I don't know which package is concerned wrt this bug
<infinity> sivang : Well, yes, that's the point.
<Kamion> janimo: linux-restricted-modules-2.6.12
<infinity> sivang : So you can edit the small file in /etc/default, rather than editing the script itself.
<sivang> infinity: cool, thanks
<sivang> infinity: works now
<janimo> Kamion, yup it's there in the changelog I should've read more carefully, thanks
<sivang> infinity: anything else I should do to enable mod_rewrite other then a2enmod and drop a config snippet with RewriteEngine On under ./conf.d ?
<dholbach> Kamion: could you (once you have a moment), sync gftp from sid? justification would be the changes from -6 to -10 (http://packages.debian.org/changelogs/pool/main/g/gftp/gftp_2.0.18-10/changelog)
<infinity> sivang : Only do RewriteEngine On in the vhost(s) where you intend to use it.  It's pretty evil to have it always on, even when not in use.  Trust me.
<sivang> infinity: you mean, inside the .htaccess file?
<infinity> sivang : Or in /etc/apache2/sites-enabled/$whatever
<sivang> infinity: k, thanks alot
<Kamion> dholbach: which Ubuntu bugs does this fix?
<Kamion> dholbach: oh, OK, I see that the crash bugs fixed in 2.0.18-8 were not introduced in 2.0.18-7, as I initially thought
<\sh> Kamion, when elmo is back online? :)  
<dholbach> Kamion: #13179 should be fixed by -7 and the bug reports the debian maintainer fixed with -8 and -9 sound a lot like the other reports in bugzilla
<Kamion> dholbach: it's not on the CD, so I've synced it; make sure it works etc. once it builds
<Kamion> \sh: Thursday
<dholbach> Kamion: i built it here and played a bit with it, but will give it more testing... thanks
<\sh> Kamion, thx
<Kamion> doko: I wish you hadn't included that clear-screen thing in your bash upload
<Kamion> did mdz talk with you about that? I notice he didn't approve it last night, but don't have any other information
<Kamion> I'd like to have the volatile fix though
<Lathiat> is there any particular reason we no longer have animation in the clearlooks engine enabled?
<doko> Kamion: is there anything wrong with the .bash_logout, or too late for breezy?
<doko> Kamion: no, mdz didn't mention bash
<Kamion> doko: I dunno, it just seems a bit late and it's incomplete anyway as Ralph notes in the bug report
<Kamion> oh, and ps isn't essential
<doko> hmmpf, ok. I'll make an upload with this one backed out
<doko> Kamion: where does he note, that's incomplete?
<Kamion> I don't buy Ralph's comment about su, but the rest seems valid: i.e. his comment that you can just shift-pgup
<doko> ahh, ok, that thing
<Kamion> clear doesn't wipe scrollback
<doko> hmm, changing the console and changing the console back should work. any way to do that automatically?
<Kamion> if somebody logged in as root and was looking at something sensitive, she can always clear the screen; whereas if it's done automatically it's more annoying if they *don't* want the screen cleared
<Kamion> not really
<Lathiat> that is oh so ugly
<Lathiat> you dont really know what your switchign to
<Kamion> certainly not that I'd take at this point :)
<Lathiat> could be an xsession or something
<Kamion> doko: yes, I think I'd prefer an upload without that, if you could; the rest looks fine
<Kamion> we can do it early in dapper and iron out any problems
<doko> db4.3 wasn't approved as well?
<Kamion> it was, but it was also NEW, and I only did that part of the processing a few minutes back
<Kamion> the binaries will show up in the archive in about ten minutes
<doko> fine, thanks
<Kamion> doko: approved now
<Kamion> thanks
<pitti> is anybody familiar with fontconfig?
<ogra> pitti, only very rough
<pitti> ogra: if you have time, could you please look at #15108? it's not RC-critical, but we shuold fix it for release
<pitti> ogra: they have a patch which looks sane, and I will test it
<pitti> ogra: but I'd like to have another two eyes on it to be sure
<pitti> ogra: it basically asks for increasing the priority of mgopen (greek fonts) so that Greek is displayed properly
<ogra> yup
<ogra> i see it
<pitti> ogra: I'm just afraid that this could break Asian languages
<Kamion> right, that's the d-i build for RC in
<Kamion> after next cron.daily that is
<ogra> pitti, did you compare with hoarys fonts.conf ? 
<pitti> ogra: no, I don't have the slightest clue about fonts; but I'll do
<ogra> pitti, it lloks ok to me... but i havent ever used asian fonts 
<mvo> pitti: I have a greek install here, I'll have a look if the fonts looks as ugly as in the screenshot
<pitti> ogra: there are some differences to Hoary; in particular, some new Asian font family " "
<pitti> ogra: (which looks rather Klingon to me :-/ )
<ogra> hehe
<Lathiat> qapla'!
<pitti> Qapla', AFAIK :-)
<Lathiat> yeh your right
<Lathiat> im used to typing it lowercase now as its the hostname for one of my machines ;p
* pitti wipes the saliva off his screen :-)
<Lathiat> as is nuqneH
<pitti> ogra, mvo: Hmm, greek text in gedit looks fine... 
<pitti> right, but in OO.o it looks terrible
<mvo> pitti: yeah, (almost) fresh greek install looks terrible too
<pitti> mvo: I'll try the patch and also compare with Japanese and Chinese for any regressions
<pitti> $ LANGUAGE= LANG=el_GR.UTF-8 gksudo synaptic   *shudder*
<pitti> ogra, mvo: ok, Chinese and Japanese still look exactly the same after the patch; he seems to be right, mgopen does not have Asian letters, so it is ignored for Asian chars
<ogra> pitti, so go ahead with it, i dont see anything wrong in the fonts.conf patch
<Kamion> pitti: I just gave back lots of language-* builds that had been hung somewhere in the buildd network for five days; hopefully they'll actually arrive soon
<pitti> Kamion: ouch, I didn't notice that; thanks
<pitti> Kamion: they build quickly, a full round usually takes ~ 30 minutes
<pitti> Kamion: would you accept the patch in #15108 directly after RC?
<Kamion> yes, we already have 7 of them in unchecked
<Kamion> pitti: yes, if we're doing other post-RC changes
<pitti> ok, thanks
<Kamion> infinity: what happened to gnome-pilot_2.0.13-0ubuntu10_powerpc? it built fine, then disappeared
<Mirv> hmm, I'd think some Gnome-person knows instantly how to fix this: https://launchpad.net/distros/ubuntu/+sources/gnome-panel/+bug/2848 ? the bug (from start day of the week) is quite highly visible for any user of the locale, but probably quite easily fixed
<Mirv> of course, it just has to be fixed in the correct place, wherever the actual mistake happened
<Kamion> Mirv: please file bugs in the main distribution in Bugzilla, not Malone
<pitti> Mirv: looks like a bug in the locale definition, I check...
<Mirv> Kamion: oh, I thought I had used differend bug reporting tool before. why there's Malone/ubuntu anyway?
<Mirv> pitti: ok, I will file the bug anyway, and see if I can cancel that malone bug. thanks if you can check if it's something obvious (and not breaking any other locale)
<Kamion> Mirv: we'll be moving to it eventually, but have not done so yet. Universe uses it.
* Kamion assigns the Malone bug to seb128
<seb128> Kamion, Mirv: that's a locales bug
<seb128> Kamion: and we have quite some dups to bugzilla already for different locales
<Mirv> seb128: okay, I just found 16216 in bugzilla that has "Seb asked me to hold off on first_weekday updates until we can get glibc and gtk
<Mirv> to agree on things."
<seb128> data are not coherent between locales, so whatever way you pick you will have some wrongs
<Kamion> seb128: sure, just might as well assign the bug to somebody rather than nobody
<seb128> Kamion: right
<Mirv> seb128: yes, I now found them as I went go bugzilla instead of malone. "good" that it's affecting many locales so it'll surely get fixed.
<Kamion> I don't think it's possible to mark a Malone bug as a duplicate of a Bugzilla bug usefully, although you can add the Bugzilla URL
<seb128> rejecting with the bugzilla URL :)
<seb128> Mirv: that will not be fixed for 5.10 though
<seb128> locales are crap
<tepsipakki> how about the regressions regarding translations?
<seb128> what regression ?
<zyga> hi
<tepsipakki> I compared hoary to breezy
<Mirv> seb128: shouldn't there be some way to fix it in 5.10? it sucks to have most people have wrongly displayed calendar?
<zyga> is there anyone around who knows cups enough to help me port old drivers?
<pitti> seb128: humm, I can't find a field in a loale definition that describes the first day of week
<tepsipakki> seb128: for example the menu-items on the panel aren't translated anymore (fi_FI)
<seb128> Mirv: no, that would require a libc upload and I'm not sure one is planned
<pitti> tepsipakki: did you install language-pack-gnome-fi?
<Kamion> it's kind of annoying that we have no way to automatically install language-pack-gnome-* on upgrades
<Kamion> I hope that's in the release notes?
<tepsipakki> pitti: yes
<seb128> pitti: I've talked about that with jbailey, some Suse guy, the GTK maintainer and mailed Denis Barbier, there is simply no way
<pitti> Kamion: we have an upgrade notification for it
<tepsipakki> f*ck
<Kamion> pitti: ah, ok
<pitti> Kamion: even translated :-)
<tepsipakki> wait a sec..
<seb128> pitti: locales are no coherent with the use of week_1stday / first_weekday
<Mirv> seb128: argh, ok. I just thought that a bug this visible could use some temporary hack to have most countries displayed right. but do as you must.
<seb128> pitti: current GTK code does (first_weekday + week_1stday -1) % 7  to get a week start
<seb128> Mirv: no, it would need peopel caring about it but not 1 week before candidate ...
<pitti> $ LC_TIME=fi_FI.UTF-8 locale -k LC_TIME | grep first_weekday
<pitti> first_weekday=2
<pitti> indeed
<seb128> pitti: week_1stday?
<pitti> week-1stday=19971130
<tepsipakki> pitti: no I didn't.. damn me
<seb128> so it does (2+0-1)%7
<pitti> seb128: for de_DE it is week-1stday=19971201
<seb128> should be monday
<pitti> seb128: what is week_1stday?
<seb128> de_DE has
<seb128> week-1stday=19971201 == 1
<tepsipakki> ok, so no bad translation regressions, then ;)
<seb128> first_weekday=1
<seb128> (1 + 1 -1) %7 == monday
<pitti> tepsipakki: didn't you get the upgrade note?
<seb128> pitti: you clock applet should start on monday, right?
<tepsipakki> pitti: what, when?
<pitti> seb128: the calendar starts at Sunday
<pitti> seb128: (I never paid attention to this)
<tepsipakki> ah that one
<pitti> seb128: evo starts at Monday, just the small calendar with the clock is wrong
<pitti> seb128: do you know the meaning of week_1stday?
<seb128> pitti: the panel one? have you restarted it since gtk 2.8.6 ?
<pitti> seb128: I booted this morning
<seb128> pitti: not sure it was accepted yesterday evening
<seb128> pitti: gnome-session-remove gnome-panel && gnome-panel
<pitti> seb128: ah, ok, then I'll try again
<pitti> seb128: I need to dist-upgrade, but I can't with only a modem
<Kamion> seb128: it was accepted yesterday evening; you can tell by the timestamps on the binaries
<seb128> pitti: no, I don't get the diff between first_weekday and week_1stday
<Mirv> I also haven't tested anything else than the clock applet's calendar, but it gave (fi_FI) Tuesday instead of the correct one (Monday). should check as soon as I get from work.
<seb128> Kamion: k
<Riddell> Kamion: can I upload a new kubuntu-default-settings?  usplash.png file has fixed palette order
<Kamion> seb128: BTW, installer-po/statistics is currently showing French as the only language at 100%
<seb128> rock
<Kamion> (although I still need to check why some stuff is missing from that - could be that's not actually true, but not much I can do at this stage)
<seb128> Kamion: I've just done a daily install, the stage 2 is still english
<Kamion> seb128: that's apt not the installer
<seb128> I've updated apt translations some days ago
<seb128> weird
<seb128> like 1 week ago
<seb128> mvo: did you use my updated po file for the upload?
<Kamion> oh, CRAP
<Kamion> pitti: please add apt to pkgstriptranslations.blacklist
<Kamion> sigh
<infinity> Kamion : gnome-pilot rescued.
<Riddell> seb128: ldd says playbin doesn't use gconf
<Kamion> infinity: thanks
<Kamion> Riddell: yes
<seb128> Riddell: this is french but
<seb128> niveau elf
<seb128> ups
<seb128> <lool> seb128: en mme temps, il y a peut-tre des plugins qui utilisent gconf mais qui ne dpendent pas de gconf au niveau elf
<seb128> <lool> seb128: en fait virer la dp gconf c'est vraiment risqu  mon avis
<seb128> <lool> libgstplaybin est dedans
<seb128> <lool> et playbin utilise gconf pour choper les audiosink et videosink
<pitti> Kamion: just the binary package "apt"? or some more?
<seb128> Riddell: basically no elf depends on it, but playbin code use it
<seb128> Riddell: argue with mdz or Kamion if you want this move, I'm against it for 5.10, we are going to break stuff on the multimedia app likely with it
<seb128> Kamion: the translation issue is due to apt beeing po-stripped?
<pitti> Kamion: ready to upload if you confirm that only the binary package "apt" is affected (and not apt-utils, or whatever)
<pitti> Kamion: no, that should be fine, there's only the "apt" domain
<pitti> Kamion: uploaded
<jdub> so after all that to-and-fro about deskbar-applet, finally Mithrandir uploaded it?
<jdub> as maintainer?
<jdub> interesting ;)
<Lathiat> indeed, little buggy unfortunately
<Lathiat> do you know the keyboard shortcut to jump to it?
<winkle> there is none
<Lathiat> that sucks
<jdub> Lathiat: just saw the services applet go in, c/o seb128 :)
<Lathiat> jdub: was already in :) new version :)
<Lathiat> jdub: wrong sebastien ;p
<winkle> I can't seem to find where to add engines though, only some width setting in preferences..
<seb128> jdub: ? dholback packaged/uploaded deskbar-applet
<dholbach> jdub: ?
<Lathiat> hrm
<Lathiat> looks like dholbach uploaded it
<Lathiat> but tfheen just uploaded 1 too
<seb128> winkle: it is beeing reworded upstream
<dholbach> Lathiat: where?
<jdub> see b-c :)
<Lathiat> but with a -1 version and maintainer @debian.org
<Lathiat> breezy-changes just now
<Kamion> pitti: yes, belatedly
<Kamion> seb128: yes
<dholbach> that tfheen... tststs :)
<seb128> nice that you caught it ;)
<seb128> thanks Kamion 
<jdub> that's a heenous crime!
<Lathiat> dholbach: your versions width doesn't work
* jdub chuckles
<Lathiat> dholbach: it tries to expand right as far as possible
<jdub> HA HA HA
<jdub> <- HUMOURIST
<Lathiat> and it seems to be missing the border on the bottom
<Lathiat> which looks disconcerting :)
<daniels> jdub: have you been hitting the malibu?
<Kamion> seb128: I think it's too late to get it fixed for RC (given pkgstriptranslations has to get built first, installed on the buildds, etc.), but we can queue it up if there are post-RC changes to me
<dholbach> Lathiat: hm? the width is fine for me
<Kamion> s/me$/make/
<dholbach> Lathiat: what about the border?
* Lathiat ss
<seb128> Kamion: as far as it's fixed for gold it's fine for me
<jdub> daniels: vicious.
<Lathiat> http://bur.st/~lathiat/deskbar.png
<Kamion> Mithrandir: (was that a by-hand sync?)
<Kamion> hmm, no
<jdub> Lathiat: dude. your theme.
<dholbach> Lathiat: will report the width-thing to upstream, i can't reproduce the border thing though
<jdub> dholbach: maybe muck with your font size a bit
<seb128> Kamion, jdub: could we remove the gdm Depends on ubuntu-artwork and list it as a desktop package instead ?
<jdub> seb128: hrm, but our gdm conffile changes point to the theme
<dholbach> Lathiat: will do it later, now i'll be out for a bit
<jdub> seb128: btw, what happened to -br in the config file?
<Mithrandir> Kamion: yes, or rather initial upload
<Mithrandir> Kamion: since rburton asked if it could make it into breezy
<seb128> jdub: nothing?
<Kamion> seb128: not pre-RC
<Kamion> Mithrandir: ^--, dholbach had already done it :)
<Mithrandir> Kamion: heh, 'k.
<jdub> seb128: oh, hmm, now it's bakc.
<seb128> jdub: when did you get the issue?
<dholbach> i don't quite get why it got accepted, i mean it says "unstable" doesn't it?
<seb128> dholbach: syncs from Debian do that
<Kamion> but it wasn't an auto-sync
<Lathiat> jdub: what about my theme
<jdub> seb128: i have it atm when starting new logins...
<seb128> weird
<jdub> hrm, back soon
<Mithrandir> I hacked the .changes file by hand
<Kamion> Mithrandir hacked Distribution: in .changes
<dholbach> seb128: it's neither in incoming nor in sid/stable/..
<Kamion> dholbach: katie parses Distribution:, not the Changes: field
<seb128> Mithrandir: you trashed dholbach package on purpose? you hate him or something? :p
<infinity> Kamion : Permission to upload a new mysql-dfsg-4.1, disabling the generation of the problematic docs (they've been disabled in Debian in a more recent version, I'll cherry-pick the patch from sid)
<Lathiat> hrm, the border thing is in fact caused by my theme
<Lathiat> (clearlooks does it)
<Lathiat> human doe snot
<dholbach> seb128: i'm fine with Mithrandir taking the package... he can deal with lathiat and the first bugreports :)
<Mithrandir> seb128: no, I asked about if anybody was packaging it in #-motu yesterday, but didn't get around to uploading till today.
<seb128> Mithrandir: it was on revu yesterday
<Mithrandir> dholbach: sorry for trampling over your work. :-/
<dholbach> Mithrandir: don't worry
<Kamion> infinity: how long does it take to build? libmysqlclient14 is in desktop
<dholbach> Mithrandir: we'll be the deskbar-applet team :)
<infinity> Kamion : Under one cron.daily cycle for everyone but ia64, I'd guess.
<Kamion> infinity: all right then
<Diziet> Re the thread on ubuntu-devel `ubuntu can damage your hardware? (radeontool)', has anyone looked at making acpi-support not depend on radeontool ?
<Lathiat> jdub: http://bur.st/~lathiat/aero.png <-- better theme. :)
<Lathiat> Diziet: yes it was backed out earlier
<Lathiat> Diziet: however i highly doubt that error is anymore than a scare-off
<Diziet> lath: Oh, good.  I didn't see it in -changes.
<Kamion> Diziet: acpi-support 0.45
<Lathiat> acpi-support 0.45
<Diziet> Oh, yes, there it is.
<jdub> Lathiat: oof
<Diziet> That'll teach me to try to use vgrep when I can have a computer do it.
<Lathiat> Diziet: heh
<fabbione> Diziet: did you read all the discuss between Seb128 and me about your fontconfig changes?
<Kamion> infinity: fyi, yours is now the last upload I'm waiting for ... not to hassle or anything. :)
<magnon> Lathiat: it's still loading, and I'm thinking more and more that it's not worksafe :p
<daniels> the radeontool warning is, indeed, a more sophisticated no-warranty
<Diziet> fab: On -devel ?  If so yes.
<fabbione> yes
<daniels> given the code does almost exactly the same as xorg, last I looked, I'd be shocked if it destroyed hardware
<magnon> ah, it was
<seb128> Diziet: on this chan
<Lathiat> magnon: oh its worksafe
<Diziet> Oh, no.  Let me look.
<Lathiat> its just skimpy ;p
<daniels> and, put it this way.  there are no confirmed reports of radeontool destroying hardware, and I'd be shocked if it ever did.  however, we know for sure that radeon_drv destroys hardware.
<magnon> :P
<Lathiat> but the theme is more what i was talking about ;p
<daniels> make of that what you will.
<infinity> Kamion : Yeah, yeha... Bandwidth.  Buy me some.
<Lathiat> daniels: radeon_drv ?
<infinity> Kamion : Up.
<magnon> Lathiat: The background is definately a big part of the theme, no? :P
<infinity> Kamion : If you're really impatient, you can re-run cron.daily after you ACCEPT it, and I'll babysit the buildds into getting it to you ASAP.
<Lathiat> magnon: i guess ;p
<daniels> Lathiat: yes
<Lathiat> daniels: (whats that?)
<daniels> Lathiat: the radeon driver for xorg.
<Lathiat> oh
<Diziet> OK, I think I've read it but I don't understand it :-).
<Lathiat> it destorys hardware?
<daniels> yeah
<Lathiat> .... how?
<seb128> Diziet: your change breaks my Fixed font
<seb128> Diziet: which used to work for ages 
<seb128> to summarize
<daniels> if we knew, we'd probably fix it.  just makes LCDs in a certain variety of laptop decide that life isn't worth living.
<Lathiat> daniels: ouch, nice
<Diziet> That's unfortunate but I don't understand how.
<Lathiat> that is rather impressive
<Kamion> infinity: approved, extra cron.daily on its way
<Diziet> seb128: Did you diagnose it at all ?
<Diziet> I have to say I don't really understand all of this stuff so please don't think I'm an expert just because I last touched it ...
<Diziet> (GUI programs are always so full of layers, just to make sure there's plenty of opportunity for things to go wrong.)
<seb128> Diziet: we talked on this chan with fabbione about it for half and hour, but I don't know why it picks 12x13ja.pcf.gz rather than 10x20.pcf
<daniels> well, also because people like their fonts to not look like complete shit and most people want to reuse a font handling layer rather than writing their own and getting it differently wrong
<daniels> but primarily to ensure things go wrong ;)
<bddebian> Good morning
<seb128> Diziet: I don't really know fontconfig neither ... 
<infinity> Kamion : While we're talking cron.daily and buildds and such, do we need a new, unstripped apt upload to go with that new pkgstriptranslations?
<daniels> fontconfig is relatively simple
<bddebian> seb128: gnome-launch-box is not just a rebuild and the version from svn wants gnome-xxx-2.0 :-(
<Lathiat> i thought that got fixed
<Kamion> infinity: leaving that until post-RC, but if you could have the new pkgstriptranslations installed by then, that'd be great - then we can drop it through easily
<seb128> daniels: so basically with dir=/usr/X11R6/lib/X11/fonts, fc-match picks 12x13ja.pcf.gz
<daniels> seems sensible
<infinity> Kamion : Well, the buildds update daily, but I was prepared to hit the chroots and manually update them, if you needed it RIGHT NOW.
<daniels> i assume that 12x13ja.pcf.gz would be in there
<infinity> Kamion : If you're leaving it to post-RC, I'd rather go back to my evening soon. :)
<seb128> daniels: with dir=/usr/X11R6/lib/X11/fonts,/usr/share/X11/fonts it picks 12x13ja.pcf.gz
<seb128> grumpf
<Kamion> infinity: hmm.
<seb128> daniels: with dir=/usr/X11R6/lib/X11/fonts,/usr/share/X11/fonts it picks 10x20.pcf
<Kamion> infinity: ok, let's. I'll hammer it through.
<seb128> oh, crap
<daniels> makes sense to me
<Kamion> I'd really like to get second-stage translations
<seb128> daniels: without /usr/share/X11/fonts it picks 10x20.pcf, with it, it picks 12x13ja.pcf.gz
<carlos> pitti, new language pack ready at mawson's URL I gave you
<daniels> seb128: er?
<daniels> seb128: okay, *that's* bong :)
<infinity> Kamion : Alright, it's uploaded, so I assume it'll be Installed when your manual cron.daily is done.
<infinity> Kamion : As soon as I see it installed, I'll touch all the chroots, and you should be free to throw an apt upload at me.
<Diziet> On my testbed 10x20 and 12x13ja.pcf.gz are both in /usr/share/X11/fonts/misc from xfonts-base.
<seb128> $ locate 12x13ja.pcf.gz
<seb128> /usr/share/X11/fonts/misc/12x13ja.pcf.gz
<seb128> $ locate 10x20.pcf
<seb128> /home/seb128/.fonts/10x20.pcf
<seb128> /usr/share/X11/fonts/misc/10x20.pcf.gz
<mvo> carlos: any idea why I can't upload file for synaptic in rosetta? I have a ro.po update that I would like to add
<seb128> Diziet: without the new path it picks my ~/.fonts one
<daniels> seb128: heh, awesome
<Diziet> So is the problem that it's not looking in your .fonts ?
<carlos> mvo, because you are not member of the 'ro' team nor the owner of the potemplate
<Diziet> And did this work when everything was in /usr/X11R6/lib ?
<seb128> Diziet: that, or it looks for it but prefer 12x13ja.pcf.gz
<carlos> mvo, send me it by email and I will upload it for you
<Kamion> infinity: cron.daily's run; ready when you are
<seb128> Diziet: yep
<daniels> Diziet: no, because 10x20 is the canonical 'fixed', essentially
<daniels> Diziet: and 12x13ja looks like arse
<mvo> carlos: thanks, will do
<carlos> mvo, if you think it's an usual procedure you should be able to do, file a bug asking for a long term solution, in the mean time the email or a bug requesting the upload is ok 
<Diziet> The canonical `fixed' is 6x10, surely.
<Kamion> infinity: oh, drat, pkgstriptranslations missed that cron.daily
<infinity> Kamion : Gah, that upload must have happened after your daily run started.
<seb128> Diziet: with 1ubuntu2 it picks the 10x20 since it doesn't know about 12x13ja.pcf.gz
* Kamion runs another one
<seb128> Diziet: with 1ubuntu3 it prefers 12x13ja.pcf.gz over 10x20.pcf
<infinity> Kamion : Just let me know when apt-ftparchive is done, I don't need to wait for wanna-build. :)
<Diziet> seb: Yes, but what I don't understand is how this could ever have worked.
<seb128> which is the issue
<daniels> Diziet: i think we've used 10x20 client-side forever, since it scales better
<Diziet> I mean, before it was broken by the fonts moving but not the path in fontconfig.
<mvo> carlos: not sure, I would like to be able to upload po's for my own packages, but I'm not sure how often I'm really going to need it
<seb128> Diziet: right, so my bug is not due to your change but rather "fontconfig picks 12x13ja.pcf.gz before 10x20.pcf.gz"
<seb128> and it should pick 10x20.pcf.gz
<seb128> because the other one is plainly ugly
<daniels> i could just stop shipping 12x13ja ;)
<Diziet> fc-match --sort fixed |head   produces much output, with 10x20 halfway down.
<seb128> daniels: but do you know why it match on it for Fixed?
<carlos> mvo, let's try the mail approach and if I get tired to handle your request, we look for a better solution ;-)
<mvo> carlos: fine with me, thanks
<daniels> seb128: *shrug*
<seb128> Diziet: do you sort how it sorts them?
<seb128> do you know
<Diziet> Not really but fonts-conf(5) has lots of info.
<Diziet> I mean, I'm rereading that now :-).
* seb128 man fonts-conf
<Kamion> oh, er, oops, not sure I can run cron.daily with 'sudo -u katie'
<Diziet> Strangely there's no way of telling it that certain fonts are just ugly.
<Kamion> (which doesn't change $HOME ...)
<Kamion> infinity: try now, if the possibly-broken Release.gpg files don't screw you up
<fabbione> sudo su - katie -c ?
<Kamion> yes I know how to avoid the problem
<Kamion> *in future* :-P
<fabbione> :)
<daniels> Kamion: -H
<pitti> carlos: rock
<infinity> Kamion : Good to go.
<Kamion> daniels: same to you. I know how to avoid it, I just didn't that time round
<Kamion> infinity: chroots updated?
<daniels> Kamion: ah, okay.  was just offering something cleaner than su -
<Kamion> (because most stuff in katie doesn't care so I forgot I needed to - it's just when it invokes gpg)
<carlos> pitti, did you find any problem with the previous tarball?
<pitti> carlos: the last tarball I looked at was last Friday's
<pitti> carlos: the only problems with it were outdated evo and control-center
<infinity> Kamion : Yup.
<carlos> pitti, ok
<mdke> carlos, do you know if anyone fixed update-manager for rosetta? if not, i might file the problem in bugzilla
<mvo> mdke: I uploaded a new version that should be importable now
<mdke> mvo, wicked!
<carlos> mvo, thanks
<infinity> Kamion : apt rebuild uplod on the way, I assume?
<pitti> carlos: btw, will the other translation tickle into the tarball eventually, too?
<pitti> carlos: about 60% are still missing
<carlos> pitti, over time, not sure if all will be fixed on time for latest base package
<Kamion> infinity: yes, it's in the pool and apt-ftparchive's running
<carlos> we need to review all by hand and we have more than 250
<carlos> pitti, I'm working on a better way to handle that post breezy so we don't have this problem next time
<carlos> pitti, in the mean time, every new language pack will get more translation domains
<infinity> Kamion : \o/
<pitti> carlos: what is the primary reason? why can't you import so many?
<infinity> Kamion : mysql is starting to upload. 2/4 arches.
<infinity> Kamion : Make that 3/4, (ie: all the release arches)
<bddebian> Did I see someone say yesterday that elmo is unavailable for a while???
<Kamion> bddebian: yes, until tomorrow
<carlos> pitti, they are imported, but I need to visit one by one and rename them to the right translation domain
<bddebian> Kamion: Oh, OK, I GUESS, I can wait that long. ;-)  Thanks.
<pitti> carlos: odd, my script is able to import the vast majority of tarballs without any help
<pitti> carlos: maybe we shuold sit together and improve the logic of Rosetta?
<pitti> carlos: I have manual overrides for some 30 packages, the rest imports fully automatically
<carlos> pitti, no needed, as I said, we have a better way now, it's partial implemented
<Kamion> bddebian: if it's just syncs, I can do them if you tell me within the next two hours or so
<carlos> pitti, we just took the wrong approach
<Kamion> (after that, I'm on a train)
<bddebian> Kamion: It's about 5 or 6 packages
<bddebian> Kamion: You want a list here or an e-mail?
<Kamion> bddebian: here
<pitti> lamont: ping
<lamont__> ack
<bddebian> Kamion: libchipcard2 1.9.14.99+1.9.15beta-1  from unstable
<infinity> Kamion : apt uploaded for all release arches, and the build logs show dpkg-deb -c listings that look very unstripped.
<pitti> lamont__: /home/lamont/public_html/translations/20051003/translations.txt claims that there is control-center_1:2.12.1-0ubuntu2.1_i386_translations.tar.gz, but there isn't
<Kamion> infinity: hooray, thanks
<bddebian> Kamion: libgwenhywfar 1.18.0-1 from unstable
<pitti> lamont__: is this a bug in your scripts, or a transient error from shuffling files around?
<lamont__> interesting... /me checks
<bddebian> Kamion: libofx 1:0.8.0-3 from unstable
<Kamion> [NOT Updating - Modified]  libgwenhywfar_1.14.0-2ubuntu1 (vs 1.18.0-1)
<Kamion> bddebian: ok to overwrite Ubuntu changes?
<bddebian> Kamion: BTW, any of these with Ubuntu changes can be dropped
<Kamion> ok
<bddebian> Kamion: libosp-dev 1.5.1.0-4 from unstable
<bddebian> Kamion: libaqbanking 1.5.99+1.6.0beta-1 from unstable
<pitti> lamont__: the version number looks indeed very binNMUish...
<pitti> lamont__: no, source NMUish, but anyway, unusual
<Kamion> bddebian: libofx is a soname bump, hope you're prepared to rebuild any dependents
<bddebian> Kamion: libktoblzcheck1-dev 1.7-1.  However, this one build-deps glade (>= 2.0) and needs to be glade-2 so I can do this if preferred
<bddebian> Kamion: Yes, it's mainly grisbi, kmymoney2, and gnucahs
<bddebian> Err gnucash even
<Kamion> bddebian: libosp-dev is a binary; you mean opensp?
<bddebian> Kamion: Yes, sorry
<bddebian> I had these all laid out in a nice e-mail to elmo but that's at home so I am working from memory here.. :-(
<Kamion> bddebian: opensp is in main, not allowed
<bddebian> It is?
<Kamion> bddebian: likewise libktoblzcheck1-dev
<bddebian> Fux, how the hell did I miss that
<Kamion> oh, no, sorry, ignore that last one
<Kamion> opensp definitely is though
<bddebian> Well then the rest are pointless I suppose then because I need all these to get to gnucash and kmymoney2. Shit.
<Kamion> bddebian: I've done the others
<lamont__> pitti: interesting, since those versions (.0, .1) don't exist
<Kamion> bddebian: why do you need opensp? the Debian changelog looks trivial
<pitti> carlos: do you still need the hoary translation tarballs I created some eons ago?
<bddebian> Kamion: build-dep for this chain :-(
<Kamion> bddebian: (to clarify, done libchipcard2, libgwenhywfar, libofx, libosp-dev, libaqbanking)
<carlos> pitti, don't think so
<carlos> pitti, btw, should I do tarballs for Hoary?
<carlos> I suppose I should 
<Kamion> bddebian: you should probably fix the libktoblzcheck build-dep if that's needed
<pitti> carlos: would be nice
<bddebian> Kamion: Then you may as well do: gnucash 1.8.10-18
<pitti> carlos: but the hit will be quite big since so many files changed
<Kamion> bddebian: please find out why newer opensp is needed
<pitti> lamont__: just removing the bad entries from translations.txt is fine, but I wondered whether there was a deeper bug
<carlos> pitti, perhaps is time to generate a new base package?
<pitti> carlos: hmm, we might in fact need that for hoary
<pitti> carlos: further updates will be small, right?
<lamont__> pitti: NFC how it got there
<carlos> pitti, yeah, just changes
<pitti> lamont__: ok, let's forget about it now; I'll complain if it happens again
<Kamion> bddebian: gnucash even without opensp?
<carlos> pitti, another option is to generate a language pack with all updates since Hoary realease
<bddebian> Kamion: libofx
<lamont__> and the script doesn't munge path names at all...
<bddebian> libosp-dev (>= 1.5.1.0-2.1)
<bddebian>     OpenJade group's SP suite, developer support
<carlos> we would get less translations than we have inside Rosetta
<bddebian> Kamion: Hmm
<pitti> carlos: since this involves whitespace fixes, it doesn't buy much, or does it?
<carlos> but over time that would be fixed
<pitti> carlos: but if we do it, we can as well do it properly
<Kamion> bddebian: -2.1 is the C++ transition
<Kamion> bddebian: if it matches, you could temporarily weaken that build-dep
<Kamion> (to >= 2ubuntuwhatever)
<carlos> pitti, I could generate a full tarball export and get a diff like we did with breezy to know the changes...
<bddebian> Kamion: Understood, and please don't take this wrong, but with the only rdpends being libofx and libaqbanking, isthere a harm in updating opensp in main?
<pitti> carlos: that would rock
<carlos> pitti, ok, I will prepare it now
<pitti> carlos: if you have something to diff against
<carlos> pitti, we could get the tarball you used to generate current language packs, right?
<Kamion> bddebian: gnucash has a .desktop icon path change in Ubuntu; does that need to be re-applied?
<jdub> mako: ping
<Kamion> bddebian: it cannot happen today; the archive is frozen for release candidate tomorrow
<bddebian> Kamion: No, it was fixed upstream
<pitti> carlos: tricky, I don't have it any more, and it's nontrivial to generate
<bddebian> Kamion: That's OK but can it not happen at all?
<pitti> carlos: however, I still have all source packages here
<Kamion> bddebian: it can possibly happen between release candidate and release, but we'd rather not touch main if we don't have to
<pitti> carlos: so we could take the source packages and generate it from there
<bddebian> Kamion: OK, I'll try to weaken the deps.  SOrry.  I don't know how I missed that it was in main. :-(
<carlos> pitti, ok
<Kamion> bddebian: gnucash done
<bddebian> In fact I'm not quite sure why it is in main if everything else using appears to be in Universe :-)
<carlos> pitti, I will generate a language pack for hoary with .pot files included so we can do the same kind of diff
<Kamion> bddebian: well, your premise is wrong ...
<Kamion> ship:libosp4                           | opensp                          | epiphany-extensions        | Neil Roeth <neil@debian.org>                                |          731628 |            2288
<bddebian> Ahhh
<Kamion> epiphany-extensions depends on it directly
<bddebian> Did you get that with gmane or germinate or whatever it's called?
<Kamion> as do openjade, openjade1.3
<Kamion> bddebian: yes, http://people.ubuntu.com/~cjwatson/germinate-output/breezy/
<bddebian> Kamion: OK.  Sorry
* bddebian feels fucking stupid again
<Kamion> my intention is certainly not to make you feel stupid; I'm just pointing things out
<bddebian> Kamion: No, it's not you.  I just thought I was being careful with this one.
<bddebian> It should let me close about 5 or 6 Malone bugs
<Kamion> the changes to the reverse build-depends should be pretty trivial, and you'll be able to get them out of the way more quickly than we can unlock bits of main
<mdke> dholbach, is it correct to assign istanbul bugs to you?
<Robot101> hmm, ubuntu-desktop intentionally doesn't depend on cron?
<Robot101> on my laptop which just suspends and resumes, and boots only on battery power when I resume it and X is fucked, the cron.{daily,weekly,monthly} don't get run
<Treenaks> Robot101: is anacron available/
<Robot101> yes, anacron is installed
<Robot101> is it worth kicking anacron when AC power is attached?
<Kamion> Robot101: ubuntu-standard depends on cron
<Kamion> and ubuntu-base depends on ubuntu-standard, for upgrades from hoary
<Robot101> I debootstrapped this straight to breezy at some point, it seems to be a bit lacking
<Kamion> install ubuntu-{minimal,standard,desktop} to fix it up
<bddebian> Kamion: Aye, will do, thx
<Robot101> ubuntu-desktop doesn't depend on -standard?
<Kamion> Robot101: debootstrap only installs minimal BTW, not standard
<Kamion> oh, I see the problem, our instructions go "debootstrap, then install ubuntu-desktop"
<Kamion> they should go "debootstrap, then install ubuntu-standard and ubuntu-desktop"
<Robot101> yeah I have -desktop and -minimal, not -base or -standard
<Kamion> Robot101: no, we tried that out for a bit and it made some things quite awkward
<Kamion> might revisit in dapper
<Robot101> fair enough
<Robot101> this would explain why update-notifier wasn't ever notifying until I ran apt-get update
<Robot101> :D
<Robot101> it all makes a lot of sense
<Kamion> I've noted this in case there's another build of the installation manual pre-breezy
<Robot101> I didn't actually read a manual, I just heard ubuntu-desktop was the magical thing to install :)
<Robot101> this was at UKUUG when I wanted to smoke fresh dbus crack
<mako> jdub: yes
<Robot101> (and I didn't have any handy way of booting my laptop with the installer)
<Robot101> Kamion: cheers
<daniels> love the dbus
<Robot101> I don't love the way introspection is optional
<Diziet> Wow, this swsusp is really scary-looking.
<Robot101> especially with python bindings which can't send an empty array over the bus because it doesn't know its type signature
<bddebian> HrdwrBob and SexMachine.  For some reason that just cracks me up.. :)
<dholbach> mdke: yes
<mdke> dholbach, cool thanks
<Kamion> can somebody please fix python2.4-qt3 to be installable?
<Kamion> hmm, waiting for sip-qt3 promotion to main
<Kamion> and qscintilla
<jdub> whoa
<jdub> brown is taking a beating on the fridge poll
<infinity> I find the brown soothing.
<daniels> i hated it in oxford, but in time, came to love the brown
<bddebian> Mr. Hankey would be sad
<ogra> guys VOTE for it !
<bddebian> Heya ogra
<daniels> maybe we could go sign a petition for ATI and NVIDIA to open source their drivers while we're at it :P
<bddebian> ogra: You were right about gnome-launch-box btw, it needs an API update
<bddebian> daniels: Now THAT is a plan :)
<daniels> ...
<ogra> bddebian, i'd throw it out until its usable ... its just rubbish, even if you fix the ftbfs
<bddebian> ogra: They are unfixable afaict.  An update from svn wants gnome-vfs-2.0
<ogra> ah
<ogra> so either leave it unbuilt hanging around, or drop it completely... (seb128 will oppose it, i'm sure)
<bddebian> :-)
<bddebian> I tried to ping him this morning but he seemed deep in discussion
<ogra> mail him :)
<bddebian> Bah, then he'll just try to "recruit" me again. ;-P
<ogra> heh
<pitti> infinity: is language-pack-gnome-sa really given back and building?
<infinity> pitti : Did it not make it?
<pitti> infinity: Kamion gave it back this morning IIRC
<infinity> pitti : Kamion gave back a whole mess of langpacks..
<pitti> infinity: yes, there is a g-b build log, but there is no .deb
<Mirv> pitti: eh, was something actually done for the firstdayofweek-problem? now that I got home, the clock applet's calendar shows the correct starting day (Monday) for my locale..?
<fabbione> infinity: it's still uninstallable
<infinity> Right, on it then.
<Mirv> at some point yesterday, it was still wrong
<pitti> Mirv: no, we didn't do anything
<pitti> Mirv: but it is consistent, for me it starts at Sunday, althouhg it should be Monday
<Mirv> pitti: it might have been between yesterday and today
<pitti> Mirv: so it seems that the calendar is one off
<seb128> bddebian: who?
<Mirv> pitti: yeah but for me it was starting at Tuesday, although it should have been Monday.. the other way around
<bddebian> seb128: Who what? :-)
<pitti> Mirv: the Finnish locale is wrong, and the calendar starts one day early
<Mirv> and now it's correct. okay, I won't state anything about this now, with luck it might stay this way for my locale :)
<seb128> bddebian: <bddebian> I tried to ping him this morning but he seemed deep in discussion
<bddebian> seb128: You
<seb128> ?
<seb128> I've not read what you said
<seb128> said it again
<Mirv> pitti: this whole thing is really fuzzy
<pitti> Mirv: we won't fix it for Breezy, but please remind us for dappy
<bddebian> seb128: gnome-launch-box won't build because of API change in gnome-menus.  And newer svn version wants gnome-xxx-2.0
<seb128> Mirv, pitti: GTK 2.8.6 from yesterday changing the first day stuff
<pitti> seb128: ah, IC
<seb128> bddebian: what is xxx?
<ogra> seb128, vfs
<seb128> and the package doesn't ship that?
<Kamion> pitti: I only gave back the packages that were out of date; I only just realised that that obviously didn't include new langpacks
<seb128> pitti: I said this morning to try with the new GTK :)
<infinity> pitti : Fixed.
<Kamion> infinity: did you check for others in the same state?
<pitti> infinity: thanks
<infinity> Kamion : That's the only one listed as uninstallable by britney.
<pitti> seb128: yes, sorry, still no (real) network here... :-(
<Kamion> infinity: yeah, that's because language-pack-gnome-sa-base happened to build though
<pitti> Kamion: yep, breezy_probs.html just lists that
<Kamion> breezy_probs.html is not a sufficient check
<seb128> pitti: no need to be sorry, just pointing it changed with new GTK
* infinity looks for more.
<Mirv> seb128: ok, yes, I had the idea I already tried with gtk 2.8.6 yesterday, but probably didn't really restart until today.
<seb128> Mirv: you need to restart an app to get changes
<infinity> -lb
<Kamion> language-pack-gnome-lb |   20050930 |        breezy | source
<Kamion> language-pack-gnome-lb-base |   20050930 |        breezy | source
<Kamion> language-pack-gnome-sa |   20050930 |        breezy | source
<Kamion> right
<seb128> bddebian: /usr/lib/pkgconfig/gnome-vfs-2.0.pc ... you need this file? it's from libgnomevfs2-dev for ages
<pitti> Kamion: -sa and -lb were NEW after Friday's upload, probably the buildds choked on that
<Kamion> pitti: buildds do not typically have any problem with new packages
<infinity> pitti : No, rothera just choked in general.
<Kamion> pitti: wouldn't you expect many more problems if that were the case? :)
<infinity> Kamion : Are you going to want the buildds idle for the next while in case you need to do emergency uploads?
<pitti> Kamion: well, right :)
<ogra> seb128, i really dont think gnome-lunchbox is worth the effort to put time into it before it didnt change even a bit...
<infinity> Kamion : If not, I might want to do a mass give-back of everything in building to make sure we don't have any other such issues hanging around.
<seb128> ogra: me neither
<seb128> ogra: but bddebian wants to fix it, up to him
<ogra> he just wants the bug count to get down :)
<Kamion> infinity: I don't have time for emergency uploads any more
<Kamion> infinity: go for it
<ogra> bddebian, grab something usable rather...
<infinity> Kamion : Alright, great.
<jdub> <- *** THE POINT OF NO RETURN ***
<infinity> pitti : lang-pack-lb{,base} fixed
<ogra> jdub, ? lands end ?
<daniels> jdub: remember to drink plenty of water before you go to bed.  vitamins help too.
<bddebian> Sorry I was asleep
<bddebian> :-)
<bddebian> ogra / seb128: I'll play with it if I get time.
<bddebian> There is a Malone bug to close after all ;-)
<ogra> bureocrat !
<bddebian> :-)
<ogra> s/o/au/
<Amaranth> seb128: if i were to provide a patch for 15636 would it be too late to get it in?
<seb128> Amaranth: depending on the patch 
<Amaranth> seb128: http://bugzilla.ubuntu.com/attachment.cgi?id=4365
<seb128> Amaranth: seems to be a woraround no?
<Amaranth> seb128: What else are you supposed to do when the file doesn't exist?
<seb128> I've no context
<seb128> it seems that you ignore error if no using debug by opening this patch
<mvo> seb128, dholbach: http://people.ubuntu.com/~mvo/lpi-accel-stuff.diff <- should fix it
<seb128> what is "debug"?
<seb128> mvo: rock
<Amaranth> bug 15636 is pyxdg failing on missing merge files, this just makes it so that unless you have the debug variable set to True it ignores the error and keeps going
<dholbach> mvo: will try
<mvo> seb128: cheers
<seb128> Amaranth: ignoring error seems to not be a good idea usually :)
<Amaranth> seb128: It's what everyone else does.
<Amaranth> If libgnome-menu doesn't die on a missing merge file then pyxdg can't either, otherwise it makes it look like pyxdg is broken.
<seb128> the whole universe just ignore errors and let software break in a silent way, that's what you are saying?
<seb128> or you just speak about the menu editors?
<Amaranth> No, I'm saying gnome-menus and the kmenu thing don't fail on missing merge files.
<seb128> k
<Amaranth> They just ignore the error and keep parsing the menu.
<seb128> will consider the patch after RC
<mvo> Kamion: are uploads ok currently (assuming they will just go into the queue and sit there until it's unfrozen)? or should we wait with them until after the preview? 
<mdke> hno73, ping?
<Kamion> mvo: wait
<mvo> Kamion: ok, will do. thanks
<Kamion> I'm off now, hopefully mdz will turn up soon to release/stage-manage ;)
<jbailey> jblack seems to have two blocker severity bugs in bugzilla.  One against X, and one because the torrents aren't working. =)
<daniels> jbailey: bug# for X?
<jbailey> daniels: 9067
<fabbione> Kamion: have fun
<daniels> oh jesus, that's a duplicate of something else
<bddebian> infinity or lamont: If libofx ubuntu1 version comes through, can you please clear the dep-wait for libosp-dev?
<bddebian> infinity or lamont: Same for libaqbanking ubuntu1 and glade
<j^> did an update from a ubuntu/warty(from cd without updates) to breezy, x did not work after the upgrade, had to start in single usermode and run dpkg-reconfigure xserver-xorg
<zyga> jordi, sto: ping
<infinity> bddebian : Are you sure it builds with the older versions?
<infinity> bddebian : And runs?
<daniels> j^: that's entirely possible; we only support warty->hoary->breezy
<bddebian> infinity: Which one?
<bddebian> infinity: libofx yes
<bddebian> infinity: libaqbanking isn't an older version, just a different packagename
<lamont__> bddebian: if waiting for something else to arrive is part of the equation, please poke me after it comes through... no long-term memory cells available.
<bddebian> lamont__: Well I have already gotten the ACCEPTS back but they aren't showing up on people.u.c/~lamont yet :-)
<lamont__> bddebian: ok...  but I tend to only look when asked, not 20-50 minutes later...
<bddebian> ??
<bddebian> I'm not sure when it actually hits vs. when it shows up on your pages :)
<mdz> Kamion: morning
<fabbione> mdz: i think he took off already
<daniels> 16:44 < Kamion> I'm off now, hopefully mdz will turn up soon to release/stage-manage ;)
<infinity> bddebian : I already fixed it anyway.
<bddebian> infinity: Fixed what?
<infinity> bddebian : Your dep-wait issues.
<bddebian> Ohh, thx
<infinity> bddebian : ie: don't bother bugging lamont.
<bddebian> But it's fun ;-)
<mdz> yeah, thought I might catch him since he was just leaving
<mdz> Kamion said he hasn't tested the current builds yet; have any of you?
<fabbione> mdz: there are no builds yet afaik
<fabbione> the archive has been fixed with new d-i & co
<mdz> Kamion mailed me before he left and said that they are done
<fabbione> ok
<fabbione> than we need to test them
<mdz> I'm downloading now
<fabbione> me too
<jbailey> Do we just redo the rsync of the current daily?
<infinity> jbailey : Should do, looks like they're fresh, as of 45 mins ago or so.
<infinity> I, however, am about 2.5 hours past my bedtime.
<jbailey> Tx
<jbailey> Good sleeps, Adam
<infinity> I did my duty to make sure everything that went into the builds was as okay as possible.  I'll test tomorrow. :)
<mvo> infinity: good night
* mvo rsyncs
<mdz> jbailey: yes
<fabbione> infinity: g'night
<bddebian> infinity: Gnight, thx
* fabbione starts netinstall dance
<mdz> doko: as documented on the page, UbuntuMainInclusionQueue is only for source packages, not binary packages
<doko> mdz: yes, I did read that, _after_ adding libdbXX, and then skipping lib64bz2 ...
<mdz> doko: doesn't your PROMPT_COMMAND change disable setting the terminal title bar?
<doko> mdz: no, it's set in the user's .bashrc by default
<hno73> mdz: I see that the latest live builds are still over-sized. Are you using this Win-tarball: http://www.theopencd.org/winfoss/ubuntu/current/ ?
<mdz> doko: ok
<mdz> hno73: no, it appears to be using http://maitri.ubuntu.com/theopencd/ubuntu/winfoss/latest/Hoary-WinFOSS.tgz and similar
<hno73> mdz: ok, so changing that link should help
<hno73> but only by about 6MB :(
<mdz> hno73: we have things we can lose
<mdz> it isn't a showstopper for RC, only for final
<hno73> ok, cool
<hno73> right
<Riddell> hno73: are you going to make an updated kubuntu winfoss image today?
<Riddell> or in time for the RC
<hno73> Riddell: yeah, doing it now
<Riddell> hno73: awooga
<fabbione> mdz: i386 netinstall is go on 2 machines here
<fabbione> crap.. CD bad burn
<mdz> taking forever to download here
<fabbione> taking forever to burn :(
<fabbione> for once that i am faster in downloading :)
<TMM> hi all
<fabbione> mdz: btw i have a kernel upload for after RC.. security fix + sparc only specific changes
<TMM> breezy has been working out pretty well :) good job people! :) thank you
<fabbione> mdz: Kamion said to wait after RC.. and talk with you
<TMM> much better than hoary :)
<fabbione> mdz: the source is ready and tested FYI
<TMM> still no suspend though :( I'm going to pester the people at acpi-devel :) I'll try and get patches for breezy in time for the compaq stuff, not sure if I'll get it in time though, it's like 5 days before breezy releases, right?
<fabbione> TMM: breezy is super frozen
<TMM> o well, dapper then
<fabbione> we are preparing a Release Candidate now
<TMM> :)
<mdz> fabbione: definitely wait until after RC
<TMM> well then, it'll probably be a wiki page then :)
<fabbione> mdz: yes sure.. that was what we agreed with Kamion.. but i still had to talk with you on Kamion request
* lamont__ looks around for someone who knows nfs well enough to answer a question or 3
<jbailey> Depends what part of nfs.
<bddebian> lamont: Am I on crack?  Looking at libchipcard2-dev shows built but libaqbanking is showing a dep-wait for it??
* lamont__ points jbailey at his question to fabbione in the other other channel
<jbailey> Hmm, pegasos box doens't like the usb keyboard
<j^> daniels ups it was hoary->breezy
<fabbione> mdz: i386 live cd is go
<fabbione> (2 machines)
<TMM> can I do anything?
<mvo> mdz: i386-german cd-install is fine here
<segfault> can anyone confirm that gnome-btdownload is included in the default install?
<crimsun> segfault: yes.
<crimsun> segfault: check for yourself: apt-cache rdepends gnome-btdownload
<mvo> segfault: yep
<segfault> humm, i see.
<segfault> so it should be translatable, i guess
<segfault> however i can't find it in Rosetta, can anyone manage it?
<zyga> segfault: check #launchpad
<zyga> dholbach: ping
<dholbach> zyga: pong
<zyga> dholbach: gnome-btdownload is totally i18n ignorant, will you accept a patch that fixes this *today*?
<dholbach> zyga: that's not something, i can decide - mdz, when would be the proper timing for a get-i18n-for-gnome-btdownload patch?
<zyga> dholbach: okay I'm still learing my way around here - you are the maintainer of that package, that's all
<dholbach> zyga: since when?
<zyga> hmm
<zyga> gpg: skipped "Daniel Holbach <dh@mailempfang.de>": secret key not available
<dholbach> zyga: i was never maintainer of that package - i did a TINY change some days ago
<zyga> dholbach: that cought my eyes :)
<dholbach> zyga: apt-cache show gnome-btdownload | grep Maintainer
<zyga> dholbach: I see now :)
<dholbach> zyga: but if we can translate it soon, that's GOOD STUFF, so it's be nice, if we had that patch in bugzilla for example
<zyga> dholbach: anyway - that's about 1K lines, triviall to i18nize
<zyga> dholbach: okay - I'll patch - mdz decides
<dholbach> zyga: super
<mvo> zyga: please CC me too
<zyga> dholbach, mvo: err 
<zyga> it's fixed in 0.0.22 
<zyga> we've got 0.0.18
<zyga> if this doesn't make it into breezy I see no point in fixing it
<dholbach> zyga: that will have to wait until dapper
<zyga> dholbach: k, nothing to do then
<dholbach> zyga: sorry, for that :/
<zyga> (unless someone says 'zyga: fix it, we'll put it into breezy'
<zyga> dholbach: that's okay :)
<sladen> jbailey: unresume should probably check the modifcation dates on the filesystems before allowing a resume
<jbailey> sladen: I don't know how you'd reliably get that from all filesystems
<sladen> jbailey: only really ext2/3
<crimsun> sladen: hmm, how about before allowing a hibernate?
<crimsun> for instance, whenever a new kernel is installed and I hibernate, it's as good as useless
<crimsun> (understandably useless, but it'd be nice to alert the user nonetheless)
<mdz> dholbach: maybe after RC
<dholbach> mdz: it seems that upstream introduces i18n in 0.22 (we have 0.18), i'd rather defer it for dapper
<mdz> dholbach: fine
<bddebian> lamont__: ping?
<sladen> crimsun: that's a /different/ issue.  But one that if you can find a solution to would be great (eg.  /how/ do you work out which kernels the use is likely to try and use to resume;  the only feasible method is probably to restuff the grub-menu so that the hibernate from the swap partition is only allowed with that particular kernel that is currently running)
<crimsun> sladen: I see.
<sladen> crimsun: or just take the sledge-hammer approach and disable it if /vmlinuz doesn't point to $(uname -r)
<sladen> and if the user really knows what they're doing, they can call 'pmi' themselves
<bddebian> Why didn't we update gnome-pkg-tools?
* doko hates OOo2 help
<hunger> Who changed the network config script to wait for a timeout?!
<fabbione> hunger: all the people that needs that in order to boot
<hunger> That is really annoying with laptops... Could someone maybe add a ethtool check for the link before waiting for dhcp?
<fabbione> hunger: nope.. the link check is not reliable
<lucas> hunger: edit /etc/dhcp3/dhclient.conf, change timeout
<hunger> I used to have one... but you guys keep overwriting it:-)
<fabbione> and it is annoying in the same way for people that can't boot
<fabbione> hunger: you need wait.. they can't do anything
<fabbione> between the two.. you wait :
<fabbione> P
<hunger> lucas: Nah, I need the long timeout when my laptop is connected:-(
<lucas> 60 seconds?!
<fabbione> lucas: it's a perfectly reasonable timeout
<lucas> hunger: do we know each other ? are you in my lab ? ;)
<hunger> lucas: WLAN sucks in hotels!
<lucas> ah
<fabbione> anyway--
<hunger> lucas: I doubt that... im not in a uni.
* fabbione goes for amd64 live test
<hunger> fabbione: I do understand your argument ... but I still do not like it.
<hunger> fabbione: I guess it is too late to send in a ethtool test patch (disabled by default, can be enabled in /etc/default/something)?
<hunger> fabbione: And I was allready happy that *everything* works just the way I want it in breezy;-)
<doko> mdz: openoffice.org2-java-common is missing from the amd64 CD's due to a missing dependency. Adding that dependency will add about 7-8MB
<mdz> doko: I thought you mentioned and fixed that yesterday
<mdz> doko: what does it break?
<mdz> and does it involve a full oo.o2 build?
<siretart> is there any reason why xfonts-*-transcoded is missing in breezy? is this on purpose or a bug?
<doko> -base, -writer wizards and other wizards. no new build, just updating the amd64 control file
<doko> mdz: yes, but I got no reply from you or Colin what to do (i.e. still removing stuff from the CD's)
<fab64live> yo
<fab64live> mdz: amd64live is good to go
<fab64live> daniels, ping?=
<doko> fab64live: could you just test, what happens starting OOo-writer and starting one of the wizards?
<fab64live> doko: sure
<jbailey> ppc install appears to still not like pegasos even with the update bios.  Ah well, was worth a shot.
<jbailey> (i386 install still running)
<fab64live> doko: write starts fine..
<fab64live> testing the wizard now
<fab64live> doko: what wizard should i run? or better.. from where?
<fab64live> oh never mind
* siretart gets an error about a missing JRE from OOo2 writer
<siretart> which is ridiculus. I have working java.. hrmpf..
<fab64live> doko: it seems to work fine
<doko> fab64live, File/Wizuards/Letter
<fab64live> hmm ok
<fab64live> i did use the fax
<doko> that's ok.
<siretart> hm. why does OOo2 hate me?
<fab64live> doko: they work fine afaict
<doko> mdz: so we don't need -java-common on the live CD, but it would be better to have it on the install CD
<doko> siretart: which platform, new install?, live cd?
* doko watches fabbione coming back as PowerFabbione ...
<ogra> does he own ppc ? 
<siretart> doko: this is a amd64 desktop install
<siretart> breezy, just updated and freshly rebooted
<doko> siretart: please install openoffice.org2-java-common as well, then try again
<siretart> just a sec
<bddebian> lamont: ping again? (Sorry)
<siretart> heureka
<doko> I'm back in about 2 hours ...
<siretart> doko: with openoffice.org2-java-common, the wizards work!
<siretart> bye doko 
<mdz> doko: if it's only oo.o2-amd64, please get it uploaded immediately
<bddebian> Anyone know how I can easily set PKG_CONFIG_PATH prior to ./autogen.sh?
<fabbione> bddebian: PKG_CONFIG_PATH=/foo/bar ./autogen.sh
<bddebian> fabbione: I tried that. Hmm
<fabbione> bddebian: export PKG_CONFIG_PATH=/foo/bar
<fabbione> ./autogen
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Colony 5 released: http://cdimage.ubuntu.com/releases/breezy/colony-5/ | RC preparation: no uploads,  TEST the current daily and report here!
* mdz coughs loudly and points at the topic
<mdz> fabbione: amd64/live OK here too
<fabbione> mdz: cool
<jbailey> Eh, i386 install (fr_CA) works, suspend works, hibernation does nothing and seems to have set default keybaord to french despite me choosing US in the installer.
<hunger> Anyone besides me noticing /usr/bin/tput not found messages on shutdown?
<fabbione> hunger: nope.. 
<jbailey> Mm, it suspends if I do it by hand, just not from the gnome logoff menu.
<jbailey> mdz: Any special way you want bugs files from these installs?
<mdz> jbailey: no
<hunger> fabbione: You should:-) /lib/lsb/init-functions calls TPUT in log_end_msg without checking whether that is available.
<mdz> jbailey: were all of the translations there for fr_CA?  that's one of the things Kamion mentioned needed to be verified after the apt update
<fabbione> hunger: i still don't see it
<jbailey> mdz: I didn't notice any English go by.
<mdz> jbailey: especially the progress messages in stage 2
<jbailey> mdz: I'll watch for that on my next install.
<hunger> fabbione: I get 3 in a row just before the box reboots.
<fabbione> hunger: is your /usr on a separate partition?
<hunger> fabbione: Yeap.
<fabbione> that could be the reason
<fabbione>  /usr gets umounted
<fabbione> tput isn't there anymore
<hunger> fabbione: Sure. But the scripts should detect that and behave accordingly. all the other log_* functions do.
<hunger> fabbione: Mind if I write up a patch for that and mail it to you (or someone else)?
<fabbione> hunger: i am pretty sure this was fixed a long time ago
<fabbione> i wonder if the fix was lost somewhere
<fabbione> anyway it's nothing critical
<hunger> fabbione: I agree. But it is easily fixed.
<fabbione> hunger: yes.. after RC probably
* fabbione heads for dinner
<fabbione> mdz: did we also build DVD?
<fabbione> (for RC i mean)
<segfault> are the langpacks really removed from live cds?
<mdz> fabbione: I didn't, but Kamion may have. check the timestamps.
<mdz> segfault: there are very few langpacks available on the live CD due to space constraints
<fabbione> mdz: no.. no new DVD.. would it be possible to build it?
<fabbione> i can test it on amd64/i386
<mdz> fabbione: yep, but let's wait for doko's new oo.o2-amd64
<segfault> mdz: pt_BR is part of them?
<mdz> doko: ETA?
<fabbione> mdz: doko I'm back in about 2 hours ...
<fabbione> that was 30 minutes ago
<mdz> ok, then I guess RC goes out without that java fix
<fabbione> hmm acutally i have only dvd-i386 locally..
<fabbione> mdz: what was the system to speed up dvd rsync? cat live > dest && cat install >> dest and rsync?
<fabbione> or viceversa?
<seb128> mdz: is there any know bug about network not beeing set on boot (ie: I need to run dhclient to get a DHCP IP). That's not a new bug but a regression from hoary
<mdz> seb128: there is one bug open, eys
<mdz> yes
* mvo boots into amd64 live-cd
<mdz> seb128: http://bugzilla.ubuntu.com/show_bug.cgi?id=17015
<seb128> mdz: somebody working on it?
<seb128> thanks
<bddebian> seb128: Would you mind looking at this:? http://pastebin.ubuntulinux.nl/2801
<dholbach> bddebian: you may want to read config.log
<seb128> bddebian: one of the dep mentionned is not installed
<dholbach> bddebian: what are the build-depends you have?
<bddebian> dholbach: I have.  It cant find gnome-desktop.pc
* fabbione goes for dinner for real this time
<seb128> bddebian: install libgnome-desktop-dev
<bddebian> dholbach: I haven't gotten that far, I'm trying to run autogen from the svn source
<bddebian> seb128: I have it
<seb128> bddebian: "pkg-config --cflags gnome-desktop-2.0", does that work?
<bddebian> Gawd I am stnoed
<bddebian> Err stoned even
<seb128> ?
<bddebian> I didn't have libgnome-desktop-dev installed
<seb128> ah
<dholbach> amd64 gives me the option to "delete the whole drive /dev/ide/host0/bus1/target1/lun0/cd -"    -    and by starting the installation it hung a while over finding the disk... might be broken harddisk    -    will try different one next
<zyga> is there any # devoted to bazaar?
<mvo-live> amd64-live works here, I'm asked for the screen resolution of my lcd, but this is known, isn't it?
<bddebian> Damnit, why is even the code from svn using Menutree *tree when it should be GMenutree *tree ??
<dholbach> mvo-live: was the same for mine too
* mvo-live goes to bed now hoping his cold goes away over night
<seb128> 'night mvo-live 
<dholbach> mvo-live: hope you're well soon
* dholbach hugs Michael 'bug squasher' Vogt :)
<mvo-live> thank you guys
<seb128> mvo-live, dholbach: yeah, that's known, amd64 a no xresprobe
<seb128> s/a/has/
* dholbach gets some food
<zyga> bazaar is not available for hoary... whaaat? :/
<dholbach> zyga: it was in hoary
<jbailey> mdz: Did another i386 install, server mode this time.  The only english string I saw was in stage one when I dropped out of expert mode to look at the menu.  "Configure a multiseat system"
<mdz> jbailey: s/out of/out to/ ?
<mdz> jbailey: good news, thanks
<jbailey> Right. =)
<mdz> amd64/live OK, amd64/install in stage2, powerpc/live OK, powerpc/install in stage1
<fabbione> mdz: install i386 from cd now
<lamont__> zyga: pool/main/b/bazaar/bazaar_1.2-2_i386.deb is the hoary version
<lamont__> Kamion: ping
<jbailey> amd64/live OK in fr_CA.  Funny, the gnome is 3/4 in French with little bits in English.  So it's like it got *most* of a language pack.  The modules step at startup was long enough for usplash to drop out, and (as expected) same keyboard problem with X.
<lamont__> mdz: are you in a position to turn the crank on ia64 isos?
<mdz> i386/live OK, amd64/install OK, powerpc/install in stage2
<mdz> lamont__: busy
<mdz> after RC
<lamont__> ok
<mdz> wtf, when did resolvconf enter desktop??
<mdz> or at least the i386 live CD
<fabbione> i386/install stage2 now
<mdz> never mind, user error
<mdz> too many boots going at once :-)
<fabbione> mdz: sparc/netinstall stage1 is good to go :) (given new kernel)
<jbailey> mdz: Yeah, you clearly have better burners that I do.  =)
* jbailey glances at the 4 minutes left.
<bddebian> Damn: menu_tree_directory_get_entries (dir);  This func doesn't even exist in the newer gnome-menus stuff.
<jordi> Kamion, mdz: ping.
<mdz> jbailey: 17907 should be straightforward for you to fix and test; daniels won't be back for many hours
<TMM> hi
<mdz> jbailey: there's just a big case statement in xserver-xorg.config
<mdz> jordi: speak, my friend
<jordi> mdz: hello dude. BOSTON AWAITS.
<TMM> is pressing my touchscreen's on/off button supposed to try to hibernate my computer?
<TMM> it's pretty damn annoying
<jordi> mdz: so, jbailey missed RC for a quite important glibc update (on the i18n/locales pov).
<bddebian> Oh yeah, the GNOME thing.  Tell them to fix gnome-launch-box ;-)
<jordi> How are my chances of seeing that update in the final cd?
<TMM> I think it only does that since acpi-support 0.43
<mdz> jordi: slim
<jordi> no no no no
<TMM> I'd consider that a bug....
<jordi> it's only locale data updates
<jordi> nooo
<jbailey> mdz: Colin said this morning that he didn't mind a locale update
<mdz> jbailey: thanks, but I'm not speaking on Colin's behalf
<TMM> do you think I should file a bug?
<mdz> jbailey,jordi: mail me the debdiff if you want a concrete answer
<fabbione> mdz: 17907 ?
<jordi> jbailey: go go :)
<jbailey> fabbione: 17097
<mdz> dholbach: please change your bugzilla email to an ubuntu.com one
<jordi> what's in 17097?
<dholbach> mdz: will do
<jbailey> jordi: Keyboard layout bug that I reported.
<mdz> fabbione: er, yes, 17097
<jordi> ok
<fabbione> eheh
<fabbione> ok
<Mirv> jordi: please don't break anything with the locale data update that gtk 2.8.6 fixed
<fabbione> mdz: <davem> stage1 complete
<fabbione> ^^^sparc :)
<jordi> what did gtk fix in locale data? How can that happen?
<mdz> jordi: and why is this update arriving so late?
<jordi> glibc upload was held by gtk
<jordi> I think, jbailey has more details
<Mirv> jordi: well, I heard the start of the week problems were caused by glibc-gtk-miscommunication of sorts, and gtk update fixed gnome clock applet's calendar view at least for fi_FI.UTF-8
<jbailey> Mirv: Right.  bug in gtk-calendar.c
<jordi> Mirv: ok. Locale changes might do it better, in any case.
<mdz> jordi: given all the problems we've had recently with this, it's clear that it takes some time to test these changes
<mdz> jordi: that's why I'm disinclined to change it at the last minute
<jordi> Mirv: I'm guessing gtk-calendar assumed locale data had weekday/workday infromation, but most don't.
<TMM> ah, the bug is already entered somewhere
<jbailey> jordi, Mirv: No, it simply couldn't count.
<jordi> Mirv: and someone implemented a fallback. Dunno.
<jordi> jbailey: great
<TMM> on another model, and since yesterday also :)
<jbailey> jordi: There's quirks as to whether ther week starts on a Sunday or a monday.
<jbailey> You have to set the root as either 19971130 or 19971201
<jbailey> That day becomes "1"
<jordi> mdz: I'm not in the distro team; I just try to get in Ubuntu what some Rosetta users have been asking for
<Mirv> jordi: don't know, but if the start of the week values are now again changed for in glibc for those locales that got fixed by the gtk update, it might get again broken for some locales (and maybe fixed for some others?) but dunno, one just would have to have most locales tested
<jordi> i mean, I have little knowledge of how release stuff works in ubuntu
<jbailey> It woudl occasionally use the 1201 date instead, in which case a first_weekday of 2 would be Tuesday.
<jbailey> But it had a bug that when you set it back to 1, it would use 19971130 instead and be Sunday.
<mdz> jordi: we release Ubuntu every 6 months, according to a predetermined schedule :-)
<mdz> jordi: the current one is at https://wiki.ubuntu.com/BreezyReleaseSchedule
<jordi> read "how release stuff works in the last days before a release" :)
<jordi> I know about the 6 months thingy :)
<mdz> jordi: in the last days before release, we STOP MAKING CHANGES :-)
<seb128> jordi: what is the question ?
<jordi> seb128: locale updates. :)
<fabbione> mdz: sparc/stage2 fails as expected since the buildd is lagging.. all stage1 + reboot is good to go
<mdz> seb128: he doesn't understand why we might not want to upload a new glibc
<jordi> mdz: chicken!!!!
<seb128> ah ah
<jbailey> jordi: mdz only sleeps 2 hours a night as it is. =)
<seb128> jordi: you should come some weeks before
<jordi> seb128: I couldn't.
<seb128> so don't complain now :)
<seb128> you suck :)
<jordi> I mean, I don't remember when the request was done, but I dont' have upload rights to ubuntu
<jordi> And AIUI, jeff's upload was blocked by other things, but that's beyond me
<jbailey> Right.  Uploading locales changes with gtk acting weird and us not being sure whose fault it was didn't make sense.
<jbailey> Whups, 4pm.  Chiropractor appointment
<bddebian> So who's the GNOME master? :-)
<seb128> jordi: hey, but that would required a calm discussion on what to do and what locales to fix, not an hurry update the day before candidate
<seb128> bddebian: jordi 
<bddebian> jordi knows GNOME? :-)
<bddebian> jordi: You know much/anything about gnome-menus?
<jordi> bddebian: it's a 
<jordi> GTK BUG
<jordi> seb128 has the details
<jordi> (I'm having dinner)
<bddebian> jordi: No I am looking at gnome-launch-box
<bddebian> jordi: But enjoy your dinner
<seb128> mdz: i386/install went fine, 100% french translated, apt bug from this morning fixed
<fabbione> mdz: i386/install (CD) is go here...
<fabbione> mdz: i need to get some sleep. if you can build the DVD, i will test them tomorrow morning
<fabbione> mdz: (in 6/7 hours from now)
<fabbione> mdz: also http://people.ubuntu.com/~fabbione/changelog <-
<fabbione> mdz: let me know if and when i can upload that
<fabbione> (just drop me a /msg)
<mdz> i386/install and powerpc/install successful
<mdz> 6/6 here
<mdz> seb128: great, thanks
<seb128> np
<mdz> so the only known issue is doko's oo.o2 bug
<seb128> mdz: I've some GNOME known issues to fix after candidate
<mdz> seb128: are they in bugzilla?
<seb128> mdz: yeah
<doko> mdz: currently fixing
* fabbione heads to bed
<fabbione> good night guys
<mdz> doko: I don't think we'll roll a new RC for it, but get it uploaded so that we have it for the next daily
<mdz> fabbione: night
<seb128> mdz: 1 sj crasher, 2 librsvg bugs and a small fix for gnome-panel categories code
<doko> mdz: agreed
<mdz> seb128: 15742 has milestone 5.10; is that realistic?
<seb128> mdz: these was quite my personnal list to not forget bug which is easy to do with the ~700 bugs
<mdz> seb128: is 17066 the sj bug?
<seb128> mdz: this one should be dropped right
<seb128> a sec, I'll point the bug
<seb128> right
<seb128> #16692 and #16930 are the librsvg bugs
<dholbach> amd64 install was nice (even the windows partition resizing worked fine)
<seb128> one is a parsing issue with locale with "," as DP, upstream have fixed is with a setlocale call
<seb128> the other is a crasher on some icon with gradients
<bddebian> Grrr I'm getting no bugs fixed today damnit
<seb128> jbailey: you are working on the "about ubuntu" entry not working atm?
<jbailey> seb128: Yes.
<seb128> k
<mdz> jbailey: you seem to have a lot of bugs with milestone 5.10 which haven't been touched in a while; please make a pass over them
<jbailey> mdz: i386 live cd (english) okay
<jbailey> Ooo, pretty.  I hadn't seen the kubuntu splash before.
<mdz> jbailey: 14456?
<jbailey> There was a late kernel update where the feature was added.  It's one define.  It can either go in or not.  I don't know enough to say one way or the other.
<jbailey> When I originally told the submitter no, it wasn't in the kernel yet.
<jbailey> amd64-kubuntu-live ok
<whiprush> wasabi_: ping
<jordi> seb128: how much time do we have for translation updates from now to the release?
<jordi> fuck
<jbailey> jordi: Zero..
<jordi> s/seb128/*/
<jordi> what do you mean? Translations are closed?
<jbailey> Mmm, I guess LangpackTranslationDeadline is tomorrow by the schedule.
<Nafallo> mdz: we have moin and python2.4-moinmoin in main. moin shouldn't be there, right? :-)
<bddebian> jordi: Back from dinner? :-)
<jordi> yes
<bddebian> jordi: You know anything about menu-tree.h vs. gmenu-tree.h?
<\sh> bddebian: u have to rewrite the app to let it use gmenu-tree.h
<bddebian> \sh: I know but it currently is using functions not in gmenu-tree.h
<bddebian> gmenu_tree_directory_get_entries (dir);
<jordi> bddebian: not at all
<bddebian> jordi: OK, thx
<zyga> cool
<jordi> zyga: I'll have a look at this in a minute
* zyga has found bugs in translations that may bork rosetta for example
<jordi> when I get back to X
<zyga> jordi: okay :)
<bddebian> Is there a gnome -dev channel anywhere here?
<jordi> zyga: we really need bug reports on those with test files
<dholbach> bddebian: might be  gmenu_tree_directory_get_contents() today *shrug*
<jordi> bddebian: #gnome-hackers @ GIMPNet
<bddebian> jordi: Ah, thx
<zyga> jordi: I'm not sure if it _will_ bork rosetta, I'm sure it might though :)
<bddebian> dholbach: I thought so too but I have a menu_tree_directory_get_subdirs (dir); too which I can't quite parse :-)
<dholbach> ouch
<jordi> zyga: heh
<mdz> Nafallo: it's superseded by python-moinmoin, I think
<mdz> though that is a silly name since it is more than just a python module
<wasabi_> whiprush, pong
<wasabi_> jbailey, questions about initrd design. I need vfat in the initrd... wondering what hte appropiate long term strat for that is.
<jbailey> wasabi_: Err.
<wasabi_> To put it all in one initrd hooks package for loopback stuff, or make seperate packages for each piece.
<Nafallo> yea, looks like it. we might want moin for compability? they've changed alot in moin1.3 is seems.
<bddebian> Kamion: Around yet? :-)
<jbailey> wasabi_: You can add it to /etc/mkinitramfs/modules
<jbailey> wasabi_: Then klibc's fstype needs to be taught how to detect a vfat filesystem.
<wasabi_> Oh yes, but I'm thinking about long term... packaging, etc.
<jbailey> wasabi_: Is this really a common enough use case to generally have it in there?
<wasabi_> No.
<whiprush> wasabi_: I understand you did some of the free java stuff for breezy. Can you explain to me the general state of java for breezy in a few sentences? (for the fridge)
<wasabi_> But the idea of building generic flash bootable devices is. I'm wondeirng if I should package it in something like flash-initrd-tools
<wasabi_> which pulls in vfat and loop and stuff
<jbailey> Ah, I see.  Yeah, that would work.
<wasabi_> whiprush, gij is our prefered VM. Available and works at the moment.
<wasabi_> Not too good with Swing, but that's okay.
<jbailey> wasabi_: It runs jedit, IIRC
<wasabi_> Eclipse is in Universe, doko recently synched to Debian's packages.
<wasabi_> Eclipse is missing it's help system because we are waiting for tomcat5.
<wasabi_> We're pretty much inline with Debian.
<jbailey> wasabi_: I've done the start of a HACKING file for initramfs-tools
<wasabi_> All the important stuff I got done there.
<whiprush> wasabi_: k, thanks.
<doko> jbailey: only with retroweaver
<jbailey> doko: What's that?
<doko> runs 1.5 features on a 1.4 runtime
<wasabi_> jbailey, modprobing "loop" in the initrd doesn't create /dev/loop*
<wasabi_> is that normal?
<jbailey> wasabi_: yes.  There's no udevd running at that point.
<jbailey> wasabi_: It really wants to get run before udevstart runs.
<wasabi_> Ahh so I need to mkae the devs by hand
<jbailey> wasabi_: Scott was chatting with Kay Sievers from the linux hotplug list and they've got some clever magic tht will let us safely run udevd in the initramfs.
<jbailey> But I think that requires 2.6.15 =)
<wasabi_> Interesting.
<jbailey> doko: Ah, cool. =)
<ogra_> mdz, ping
<mdz> ogra_: yes?
<wasabi_> wow i have to learn mknod
<ogra_> mdz, why did you remove the milestone from 7150 ? 
<wasabi_> never had to do that before
<jbailey> wasabi_: Nah.  Just use the force_load hook script.
<jbailey> wasabi_: It'll cause it to get loaded in the iniital pass unconditionally.
<ogra_> mdz, i was planning another small hack session on xscreensaver to fix the majors... 7150  was on my list
<wasabi_> Sure but it won't create the nodes?
<jbailey> wasabi_: Eh, why not?
<wasabi_> eh?
<ogra_> mdz, next week...
<wasabi_> no udev?
<ogra_> mdz, or rather this weekend
<hno73> Riddell: I'm uploading now, here: http://www.theopencd.org/winfoss/kubuntu/20051005/
<jbailey> wasabi_: udevstart is run after hte modules are loaded, but before lvm, md, evms and friends are run.
<mdz> ogra_: it's too late for intrusive changes
<hno73> It will take about an hour to complete though
<wasabi_> ahhh.
<wasabi_> I see
<jbailey> wasabi_: So you can hook it either onto the general module loading, or mknod it.
<mdz> ogra_: that bug isn't a showstopper for 5.10 and fixing it has the potential to create new bugs
<ogra_> mdz, hmm, what about just adding a check for a env var (a one liner)
<wasabi_> So the hook will force the modules to be loaded before udevstart populates dev
<jbailey> wasabi_: But since the only reason someone would load this package is if they wanted it, I think it's okay to use the general module loading case.
<wasabi_> vs doing it in my script which won't get nodes made
<poningru> I was wondering whatever happend to the goal of windows migration?
<poningru> in breazy
<ogra_> mdz, so you could set XSS_NOLOCK in casper
<wasabi_> also, does mount in initrd not autodetect type?
<wasabi_> Doesn't seem to
<poningru> err how come its not under defered or anything
<mdz> ogra_: would have been fine a week or two ago, but not now
<ogra_> ok
<mdz> ogra_: this is RC
<mdz> final = RC + showstopper bugfixes and ultra-safe trivial fixes
<ogra_> mdz, ok
<wasabi_> jbailey, also, my situation is thus: mount /dev/hda1 inside initrd, loopback mount root, change to it, and then mount /dev/hda1 again on /boot
<wasabi_> How do you propose that?
<wasabi_> a bind mount sure, but how do I rig it up?
<jbailey> wasabi_: Eh, didn't we get a sript written for you already to handle this?
<wasabi_> Well, not the whole remounting part.
<jbailey> ISTR you saying it was all working. =)
<jbailey> Ah.
<ssam> hi, where do i find todays breezy live daily? thanks
<seb128> mdz: amd64/livecd alright
<mdz> seb128: thanks
<seb128> mdz: I've tried to track the gdm slowness today too
<jdong> seb128: so how was looking at lpi?
<Mithrandir> ssam: http://cdimage.ubuntu.com/ ?
<seb128> mdz: mandriva builds their cairo with a workaround for xrender issues which create slowness
<seb128> mdz: but that has no change on Ubuntu
<seb128> mdz: I've built cairo/pango/glib/gtk/gdm current on hoary then, and that's fast as the hoary version, so I blame xorg/xrender
<mdz> seb128: hmm, that's interesting
<seb128> jdong: was busy with other stuff
<mdz> seb128: please update bugzilla with that info
<seb128> mdz: sure, I'll try to update xorg now on the hoary updated box
<seb128> and then put that to bugzilla
<mdz> Riddell: how do the kubuntu builds look?
<seb128> mdz: for the I/O slowness, no such issue neither on my desktop or laptop ... 
<ajmitch> morning
<jdong> ajmitch:  afternoon :)
<ajmitch> hey jordi 
<ajmitch> sigh
<ajmitch> s/jordi/jdong/
<wasabi_> gnome-vol-manager should totally mount things without any write cache
* ajmitch needs new glasses
<jdong> ajmitch: this is your second time with me, isn't it? ;)
<ajmitch> jdong: probably 
<mdz> seb128: me either, but clearly many people are experiencing the problem
<ajmitch> that's what I get for reading scrollback
<Mithrandir> seb128: one of the problems is that nobody here on IRC or similar is able to reproduce it, so it's bloody hard to debug.
<seb128> right :/
<seb128> bddebian: you had GNOME question? you can ask them on #ubuntu-desktop
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | RC preparation: no uploads,  TEST the current daily and report here!
<mpt> poningru: it was never approved, and no developers were assigned to it
<bddebian> seb128: Well I got it to almost build
<mpt> poningru: Maybe we'll have better luck at the next conference in a few weeks
<Eins> hi guys i got a problem with some last breezy updates hdc hdd devices doesn't works
<poningru> mpt: I see no Bofs for it
<poningru> mpt: I would love to work on this but my skills are limited to python
<BenM> mdz, on http://bugzilla.ubuntu.com/show_bug.cgi?id=6108, what can i do to help you guys debug
<BenM> there's nothing funky in my logs
<Eins> anybody knows why this devies are not working  (on breezy live cd works fine)
<mpt> poningru: MigratingToUbuntu
<poningru> oh rofl
<poningru> thanks mpt 
<poningru> mpt: I was wondering why that isnt high priority?
<bddebian> frikin' A gnome-launch-box builds
<poningru> wait are you Mathew Thomas?
<mpt> poningru: that's me
<mpt> modulo an extra "t"
<poningru> hehe
<poningru> mpt: wait you used to volunteer at mofo right?
<poningru> I think I have heard stories about you
<mpt> It was before the days of mofo
<poningru> from asa and the gang
<mpt> Bad stories, no doubt
<poningru> right ofcourse
<poningru> hehe some bad some good
<poningru> you know jx right?
<poningru> jesus x?
<mpt> jx? not by those initials
<mpt> oh, jesus_x
<mpt> yeah
<poningru> hehe cool
<poningru> yeah good stories from him
<mpt> I used to piss people off, because the distances between Mozilla and elegance, and between myself and tactfulness, were both rather large
<poningru> hehe true
<poningru> you should come hang out in #bs
<poningru> dont know if you were there at the creation of that
<mpt> the former being the cause of Firefox and Thunderbird, and the latter being the cause of my not being involved in Firefox or Thunderbird :-)
<poningru> yeah true
<poningru> irc.mozilla.org #bs
<wasabi_> jbailey, anyway I can make the initrd step thru messages? or log?
<wasabi_> It's erroring like, 2 screens up
<jbailey> wasabi_: Add "exec >/dev/foo 2>&1" after it mounts /dev
<jbailey> wasabi_: That way if it manages to boot, you'll still have it n your /dev
<jbailey> wasabi_: That doesn't entirely work, but it'll be something close to that.
<jbailey> wasabi_: IF you manage to find the answer before I do, lemme know.  I've been tryiing to add a debug log mode that doesn't require adding a whole bunch of extra logging to each function. =)
<joh> Anyone know what happened to the nvidia kernel module in linux-restricted-modules on breezy?
<Mithrandir> joh: still there?
<joh> Mithrandir: no, it's not...
<Mithrandir> joh: on my system, it is. :-)
<joh> Mithrandir: it is!? which version of linux-restricted-modules?
<grayman> erm its there
<Mithrandir> ii  linux-restricted-modules-2.6.12-9-amd64-k8-smp  2.6.12.4-8     Non-free Linux 2.6.12 modules on AMD K8 SMP
<Mithrandir> at least
<wasabi_> jbailey, we should totally define a binaryish interface for initrd pieces... so we can use C. ;)
<Mithrandir> wasabi_: "klibc"?
<joh> Mithrandir: hmmm
<wasabi_> I mean for the interaction of the hooks and scripts.
<wasabi_> I get the feeling somehow this isn't runnin gin the right place
<wasabi_> local-top is where stuff that creates the root device should be, right? that's where all the rest is.
<joh> Mithrandir: ah, figured it out. installing nvidia-glx didn't install the kernel module for my kernel... even though it depends on linux-restricted-modules-2.6.12-9-k7
<jbailey> wasabi_: Right.
<wasabi_> where does init kick off local-top?
<Mithrandir> joh: you may need to reboot to have the modules built again.
<jbailey> wasabi_: That's after udevstart has run, though.
<wasabi_> run_scripts /scripts/init-premount ?
<wasabi_> that's all I see before mountroot
<jbailey> mountroot calls scripts/local's mountroot function.
<joh> Mithrandir: the modules are built at boot? (it worked after installing linux-restricted-modules-2.6.12-9-k7)
<wasabi_> Ahh I see
<wasabi_> Just found it
<jbailey> wasabi_: It's how I do polymorphism in shell. =)
<jbailey> wasabi_: I don't need no stinkin' pointers.
<wasabi_> haha yeah
<jbailey> (I used to be a pascal programmer, can you tell?)
<Mithrandir> joh: they should be, yes, but if it works now, then it works, so.
<joh> Mithrandir: ok :)
<wasabi_> gar stupid thing
<wasabi_> hmm, /proc/cmdline doesn't exist
<wasabi_> weird
<lj-ia64-live> IT'S ALIVE!!!
#ubuntu-devel 2005-10-11
<lamont__> sorry - I just couldn't resist
<Nafallo> lol
<ajmitch> lamont__: able to drop dep-wait for phpmyadmin for me? :)
* Mithrandir tickles the ia64 live box to see if it overheats.
<lj-ia64-live> Mithrandir: I want my openoffice.org2/ia64, dammit
<Mithrandir> lj-ia64-live: ship me an ia64 box, then. :-P
<wasabi_> jbailey, is there at least some way to pause execution?
<wasabi_> read doesn't seem to work
<wasabi_> causes a kernel panic
* lj-ia64-live is actually running the latest ia64 daily with a freshened cloop, since the old one doesn't work so well...
* lj-ia64-live puts Mithrandir on his list.
<Mithrandir> lj-ia64-live: bump me on the list, not just put me on it. :-P
<lamont__> ajmitch: by your command
<lamont__> Mithrandir: dude there's like you and one more person on it.
<ajmitch> thank you
<Mithrandir> lamont__: heh, 'k.  Anyway, what's the hold-up for ooo2-amd64?
<lamont__> Mithrandir: one of the dep packages is Arch: amd64 or has amd64 specifics in it...
* lamont__ goes to look
* os2mac waves
<os2mac> anyone got time to talk about ACPI on a dell inspiron?
<lamont__> dpkg-gencontrol: error: current build architecture ia64 does not appear in package's list (amd64)
* lamont__ can't believe it got that far
<Mithrandir> lamont__: it's probably just an oversight of my part, since none of the parts should be amd64-only, they should be "amd64 ia64".
<jbailey> wasabi_: Umm.
<jbailey> wasabi_: No idea.  It's not something I'd considered. =)
<lamont__> Mithrandir: ia32-libs: dpkg-deb: failed to open package info file `debian/lib32z1/DEBIAN/control' for reading: No such file or directory
<jbailey> wasabi_: Try just calling shell
<lamont__> iz amd64 biarch crap that killed it
<jbailey> wasabi_: Then you can type exit and keep going.
<Mithrandir> lamont__: ah, so the ia32-libs stuff is broken on ia64.
<wasabi_> ahh
<lamont__> Mithrandir: and oo.o2-amd64 needs to be taught about ia6
<Mithrandir> lamont__: care to file a bug about it and I'll fix it tomorrow+
<lamont__> 4
<lamont__> Mithrandir: will do
<jbailey> wasabi_: Don't use panic, though.  It exec's shell so that you can exec run-init after and still keep everything as pid 1
<seb128> mdz: do you have a min to try something?
<wasabi_> jbailey, not following. I run sh from inside the script?
<wasabi_> And then type exit to exit? Okay, makes sense.
<wasabi_> When I type exit it panics
<Mithrandir> wasabi_: type exec /sbin/init instead
<wasabi_> but that doesn't resume the position it was at does it?
<wasabi_> heh maybe I can sleep for a few seconds
<mdz> seb128: yes
<seb128> mdz: you have the gdm slowness right? could you try with those packages? http://people.ubuntu.com/~seb128/libgnomecanvas/
<seb128> mdz: I think I've tracked it down
<Nafallo> seb128: dholbach has it :-)
<seb128> but some feedback would be welcome :)
<seb128> Nafallo: he just said he has not
<dholbach> Nafallo: no, i asked if somebody has it
<mdz> seb128: I certainly can
<seb128> mdz: thanks
<Nafallo> seb128, dholbach: dooh. my mistake :-)
<dholbach> seb128: whiprush does too
<duffman25> Hello. Does anyone here know what happened to the ubuntu traffic page? There haven't been any updates in a long time
<lamont__> Mithrandir: 17119 assigned to you.  Does oo.o2-amd64 need a bug too?
<wasabi_> hah crazy
<seb128> dholbach: http://people.ubuntu.com/~seb128/libgnomecanvas/ if he wants to try with those
<wasabi_> after about 400 hot swaps of this compact flash card, it started mounting it in /media/scsidisk instead of /media/usbdisk
<Mithrandir> lamont__: if it's arch line is wrong, yes.
<lamont__> ok
<dholbach> seb128: rocking, thanks
<seb128> dholbach: thank you :)
<lamont__> Mithrandir: is it? :-)
<BenM> mdz, i really need some help to give you guys data on the laptop freezing issue
<BenM> would having an ssh login to my box help?
<Mithrandir> lamont__: I can't be arsed to download 50000TB of sources on my measly 3Mbit. :-P
<mdz> BenM: no, I don't think it would.  there's nothing we can do via ssh when it hangs :-)
<BenM> actually, that might not be true; i noticed that the network light on my hub stays on when it hangs
<mdz> BenM: what would help would be to collect information about who is experiencing the bug and find out what they have in common
<BenM> and it didn't before
<mdz> this doesn't happen to everyone
<BenM> it could potentially be X
<Nafallo> Mithrandir: dude... the archive isn't that large :-P
<BenM> i know that my roomate has it on another dell 600m
<BenM> though that isn't much data for you :-)
<lamont__> Mithrandir: 17120
<Mithrandir> Nafallo: oh, sorry, just 500TB ooo2-amd64 sources.
<Mithrandir> lamont__: cheers.
<Nafallo> hehe
<BenM> i was thinking ssh if you wanted to get some log data, settings on my computer etc
<lamont__> Mithrandir: note that they're both currently 'Normal'...  I'll let you decide if we care enough for breezy...
<lamont__> personally, I think the answer is 'no'
<Mithrandir> lamont__: I'll punt the call to mdz/kamion
<Mithrandir> lamont__: it's a trivial very-low-risk change, but those have broken stuff in the past, so..
<mdz> BenM: it seems like there may be more than one bug
<mdz> BenM: there is at least one hang when X isn't even running (I documented it in the bug)
<BenM> i'm sorta thinking that at this point
<mdz> seb128: those libgnomecanvas packages are a solid improvement
<mdz> seb128: what's changed in them?
<seb128> mdz: the interpolation type, they changed it between 2.10 and 2.12
<seb128> they use a better but slower one
<mdz> I can't tell the difference in quality, but it is noticeably faster
<seb128> mdz: http://bugzilla.gnome.org/show_bug.cgi?id=129891 is the upstream bug
<BenM> mdz, using teh binary driver didn't end up fixing my X problem, sadly
<BenM> though i found that ati driver to be a bit unstable
<seb128> mdz: cool, let's say that was the issue. It's as fast as the hoary one here with the change
<BenM> dunno if that exactly rules out that other X bug
<seb128> mdz: that's a one line change, should I upload that after the candidate tomorrow?
<mdz> seb128: go ahead and upload now; I'll let it through once RC is out
<seb128> mdz: cool, thanks
* BenM seriously hopes this can get fixed soon; i have a whole nice CMU specific customization to make it easy to install stuff, but feel horrible giving people it knowing about the hang
<jdub> Whereas in the free software world, we do take an evolutionary approach, and we know over time that evolution beats intelligent design, right?
<jdub> ^ sabdfl being cheeky
<seb128> jdub: please try http://people.ubuntu.com/~seb128/libgnomecanvas/ and tell me if that fixes your gdm slowness :)
<wasabi_> hmm, using disk mounter to umount this compact flash disk results in disk mounter clearing it.
<jdub> canvas, eh?
<wasabi_> but it's still mounted in the background.
<wasabi_> flushing.
<wasabi_> (bad)
<seb128> jdub: just try :)
<jdub> seb128: can't do this morning, preparing to leave :)
<seb128> jdub: roh
<seb128> jdub: k :)
* jdub downloads and installs anyway
<mdz> jordi: don't go back to boston
<mdz> who here can test DVDs?
<wasabi_> I.
<seb128> mdz: I can but that will take some hours to download ... 
<seb128> ie: I can download while sleeping and try tomorrow morning
<mdz> seb128: yes, it will take me a long time as well
<jbailey> mdz: Theoretically.  That burners been giving me alot of coasters lately, though.
<mdz> seb128: the build is finished so you can start downloading
<wasabi_> jbailey, so, where should I mount /dev/hda1 where it's safe?
<jbailey> wasabi_: Make a directory
<ajmitch> mdz: ok, which image?
<jbailey> mkdir /wasabimnt =)
<wasabi_> If I use /mnt or /tmp run-init dies
<wasabi_> Saying either one isn't empty.
<wasabi_> Hmm. K.
<mdz> http://cdimage.ubuntu.com/weekly-dvd/current/
<jbailey> You're in a ramfs, so as long as you clean up after yourself, you're fine.
<wasabi_> I won't be.
<wasabi_> That's the problem.
* ajmitch starts fetching
<jbailey> mdz: Is it worth adding this to the nightly rsync list?
<wasabi_> Oh I guess I can lazy umount?
<wasabi_> After creating the loop device?
<wasabi_> That gives me a problem with getting access to the file system later, though.
<mdz> jbailey: perhaps
<wasabi_> I need to be able to expose this tmp system as /boot in the real system
<mdz> jbailey: concatenating live + install and then rsyncing that is fairly effective
<mdz> seb128: ^^
<seb128> mdz: good idea, thanks
<jbailey> rsync just scares me that much more, then. =)
<ajmitch> oh dear, grabbed 3K of the dvd so far
<Mithrandir> jbailey: rsync is love.
<ajmitch> looks to be something wrong somewhere on my box :)
<jbailey> Do we have USB fob installs that should be tested?
<jdong> If you guys need a break, I just got these from a friend's e-mail.... might give you a laugh: http://adambots.gotdns.com/cgi-bin/view/Main/WifeBeater
<mdz> lamont: can you disable the livefs cron jobs please?
<lamont__> mdz: already done so
<lamont__> and daily-di
<jdong> lamont__: is there anyway to boot the livecd just to console?
<lamont__> mdz: around 0840 pacific today's date
<lamont__> jdong: that's a casper question
<jdong> hmm
<lamont__> although ctl-alt-f2 will get you a terminal sessiion
<lamont__> once booted.
<jdong> lamont__ not if you run out of RAM beforehands :)
<lamont__> ah, there is that
<lamont__> jdong: it might be a question of building your own customized livecd.
<lamont__> https://wiki.ubuntu.com/LiveCDCustomizationHowTo
<jdong> lamont__: Sure, rm /usr/sbin/gdm will stop X from loading... for good :)
<segfault> maybe with init=/bin/bash?
<jdong> segfault: gets passed to d-i
<segfault> well, although it needs the ramdisk
<jdong> segfault: busybox wasn't what I was looking for :)
<jdong> Runlevel 2 is GDM... rl 1 does not get passed in....
<jdong> I guess a grep line in /etc/init.d/gdm would be the best way
* jdong goes to modify livecd root
<jdong> I might switch back to Knoppix-based, actually.... it boots faster, also... oh well
<mdz> lamont__: thanks
<mdz> jdong: yes, there is
<mdz> jdong: "live casper-udeb/runlevel=S"
<lamont__> mdz: woot
<lamont__> mdz: if I have a usb keyfob and I want to use it instead of the ramdisk, is that an option yet?
<mdz> lamont__: nope
<mdz> lamont__: well, in a sort of maybe that would work but no one has ever tried it kind of way
<lamont__> ok.  dapper goal/wish, I suppose?
<lamont__> right
<mdz> sure, why not
<mdz> it was a hoary and a breezy wish too
<lamont__> casper-udeb/snapshot/front-file?
<mdz>  /cow-device actually
<lamont__> also, casper should behave correctly when the machine is headless.. :-)
* lamont__ will give it a go tonight/tomorrow, just for giggles
<mdz> that will COMPLETELY DESTROY anything on your USB key of course
<lamont__> yeah
* lamont__ has a scratch 1GB
* lamont__ is touched that mdz warned him, though.
<lamont__> hppa live is kinda annoying right now.. network device not found because of hotplug issues, so we get no network, even though we have eth0.  And then sudo exits immediately --> no love.
<lamont__> oh, and X fails to start.
<lamont__> all in all, not terribly surprising
<lamont__> install, however, rocks
<lamont__> mdz: and, aside from the red background during init.d, ia64 live will just work once we burn a new iso.
<dholbach> i'm off to bed... good night
<mdz> dholbach: night
<seb128> good idea, I'm going to bed too :)
<seb128> 'night guys
<dholbach> night seb128, sleep tight
<seb128> you too!
<mdz> seb128: good night
<seb128> thanks
* lamont__ -> home
<doko> mdz: does openoffice.org-amd64 need special handling?
<doko> it's not yet built
<mdz> doko: see /topic; we're releasing RC and so uploads are disallowed
<mdz> doko: please test the current images
<mdz> DVD especially needs testing
<doko> ahh, ok, i just did an "immediate upload. did test the amd64 live/install which is fine. started a i386 install, but heading to bed now
<mdz> I don't want to invalidate all of the testing which has been done in order to get that package in
<mdz> a lot of person-hours have been spent on testing this candidate already
<mdz> we'll bring it in after RC
<doko> yep, completely agree. starting dvd downloads overnight
<segfault> are those 05oct the pre-rc images?
<Surak> grub-install does not work with hard drives bigger than 100 gb. Is that only me? 
<HrdwrBob> only you
<Surak> HrdwrBob: It works fine with SATA drives, even with 200gb. But ide ones does not.
<jdong> mdz: Thanks!
* jdong makes isolinux alias livecd-cli
<mdz> segfault: the current daily build is the RC candidate, yes
<jordi> mdz: It is decided man
<segfault> should the live cds really include some windows programs, like OO, thunderbird, mozilla, gimp?
<segfault> removing them would save some space for the langpacks
<Surak> HrdwrBob: when I mount the file system (through a live cd), and do a grub-install --root-directory=/mnt/target /dev/hda  - it will do in ANY drive I try < 100 gb. I tried two 100gb ones, one 120gb and three 200gb. None of those worked. It says something about probing bios, and keeps there forever.
<whiprush> jdub: We shall need a "Release Party Photos" gallery on the fridge
<HrdwrBob> Surak: that's most likely a bios problem
<grayman> looks like there is a problem with russian locale for tsclient. On clean breezy it gives nonesense strings. same when you check the translation in rosetta. Might it be written with a font that breezy dont have?
<Surak> HrdwrBob: I tried this on at least four different motherboards.
<Surak> different models, I mean.
<grayman> that fact prevents from using the app
<grayman> and looks ugly in the menu
<Surak> One of them is amd64, via chipset. The other ones are both intel and sis chipsets.
<grayman> erm
<grayman> any ideas?
<Surak> so it does not look like on specific broken bios.
<mdz> jordi: NO
<Riddell> mdz: kubuntu daily and daily-live 20051005 i386 CDs are both good
<mdz> Riddell: those were built before the archive was frozen; there are now 20051006 CDs
<Riddell> mdz: ok, I'll test those
<segfault> mdz: any idea on what i said earlier?
<segfault> mdz: about windows apps in the livecds
<Riddell> mdz: can you change the live CD to use the new kubuntu winfoss collection http://www.theopencd.org/winfoss/kubuntu/20051005/
<Riddell> mdz: are we doing DVD release candidates?
<mdz> segfault: yes, they are there intentionally
<Surak> some strings reverted these days. Like screensaver is written in pt-pt when the rest of the system is pt_BR
<mdz> Riddell: yes
<mdz> Riddell: the Ubuntu ones are built
<mdz> kubuntu DVDs are in progress
<mdz> Riddell: add to bug 17125 regarding winfoss changes for 5.10
<segfault> surak: you mean System->Preferences?
<Surak> yes
<mdz> Surak: file a bug against the appropriate langpack
<Surak> my colleages talked about others, I did not notice
<segfault> surak: there were some desktop typos fixed in pt_BR, but xscreensaver is not yet fixed
<segfault> surak: i reported that as #16448, i guess ogra will fix that as soon as he have time
<Surak> hm, ok. That one appears in fedora from time to time, like a ghost :-)
<segfault> heh, i know... i hope dapper comes with gnome-screensaver
<Surak> This big hard drive issue with grub is puzzling me. I don't know what can it be. There are so many machines seeing this. I just installed lilo at one of those, and it worked just fine. 
<Nafallo> ehm, buildds borked?
<lamont> mdz: when you say "archive frozen" what does that mean for the SCC archs that are struggling to catch back up after 2.12.1
<lamont> ?
<Nafallo> lamont: why does phpmyadmin and xserver-xorg-driver-synaptics FTBFS because of libghc6-cabal-dev ?
<mdz> lamont: it means source uploads were locked down
<slomo> and _why_ is haskel-cabal and all its binary packages not removed from the archives as it should and as i told elmo weeks ago...
<mdz> and, hopefully, release architectures up-to-date
<sistpoty> Nafallo: package was only half installed and failed to purge
<Nafallo> sistpoty: ofcourse, but things like that shouldn't happen :-)
<sistpoty> Nafallo: sure ;)
<LaschW> Is ther a specific reason why ipt_TTL patch is not included in linux image pakets? Im talking of ipt_TTL (target module) not ipt_ttl (match module, which is part of linux images)
<LaschW> Having a spurious inet provider who don't allow more than one computer per line this module allows to set al outgoing ip pakets to a fix ttl 
<jdong> why doesn't Ubuntu have dm_bbr, especially since it includes EVMS in default?
<crimsun> why aren't you guys volunteering dpatches?
<lamont> Nafallo: because the chroto is broken because the package failed to remove properly.
<lamont> Nafallo: it's on the list of things for infinity/me to look at.
<slomo> lamont: that package should be removed completly for various reasons
<lamont> mdz: release arch are (I beleive) all caught up - infinity did a mass give-back of everything that wasn't installed as of yesterday, just to catch things that were wrongly depwaited, now buildable, etc.
<lamont> slomo: that would be one way to solve it.
<slomo> lamont: and the correct way imho... that package is already provided by ghc6 >= 6.4 and we only have ghc6 >= 6.4...
<mdz> lamont: yes, but I'm not sure whether that was true when the CD builds were done (though I believe it was)
<slomo> lamont: is it ok with you when i upload a "fixed" cabal package for the time beeing that makes it simply uninstallable to avoid further breakage when some package pulls it in again?
<lamont> mdz: I believe it was as well
<slomo> lamont: and i would do another mass give-back after the cabal problem is fixed... at least some packages ftbfs because of that... i bet many of them would build fine otherwise
* Nafallo just agrees with slomo :-)
* lamont goes to jujitsu class
<jdong> so was BBR ever present in Ubuntu kernels?
<slomo_> lamont: please read what i've written above when you're back...
<crimsun> jdong: not in Breezy afaict
<netdur> thank you very for packading deskbar
<jdong> crimsun: any reason why not? (part of EVMS patchset)
<crimsun> jdong: I don't know.
<infinity> mdz : Everything was up to date when the CD builds were done, Kamion and I made sure of it.
<mdz> infinity: thanks
<infinity> mdz : Also, can you flex some ftp-master mojo to remove haskell-cabal and its binaries from breezy?...
<sistpoty> infinity: thx for asking this... apparently slomos "fix" ftbfs'd 
<infinity> sistpoty : That's because it build-depended on a version of ghc6 no longer in the archive.
<sistpoty> infinity: i just saw it... only reason was to avoid further buildd-breakage ;)
<mdz> infinity: that's a bit beyond my comfort level; perhaps it can wait until tomorrow when elmo returns
<infinity> mdz : Alright, then I'll make sure to break it properly, if the last upload hasn't already done that. :)
<sistpoty> hehe
<whiprush> infinity: so, I'm totally paraphrasing something you mentioned during a bof at udu for my blog post.
<whiprush> don't worry, it's all good.
<infinity> Oh man, quoting me is never a good idea.
<whiprush> heh
<whiprush> infinity: ugh, on top of that I'm having a hard time remembering what you said
<whiprush> I think I got the general idea though.
<infinity> In relation to?
<whiprush> well ... 
<whiprush> meh just give me a minute.
* infinity thinks he needs to set aside a couple of weeks early in the dapper cycle to making sure WindowsInterop is all up to snuff.
<whiprush> I'm running breezy samba clients and printers
<whiprush> no problems so far.
<whiprush> 500+ machines and ~75 or so printers.
<infinity> Oh, samba tends to work quite well for people who understand it, but I still think it's a far cry from "Just Works".
<jsgotangco> whiprush, WOW
<whiprush> infinity: booyah I just remembered your quote
<infinity> Do tell.
<jsgotangco> whiprush, it still can't do AD though, but that is trolling already :)
<whiprush> sec.
<infinity> AD is on its way, but I have my doubts about us having a working solution for dapper.
<infinity> I can hope/pray, though.
<whiprush> hmmm
<bddebian> Kamion: around?
* Riddell goes to bed
<bddebian> Gnight Riddell 
<whiprush> oh Riddell !
<Riddell> whiprush!
<jsgotangco> night Riddell 
<bddebian> Heya tritium 
<tritium> hi bddebian 
<jsgotangco> mdz, ping?
<mdz> jsgotangco: yes?
<jsgotangco> mdz, can you svn co https://docteam.ubuntu.com/repos/branches/breezy/gnome/releasenotes/C/breezy-release-notes.xml for the updated release notes?
<mdz> jsgotangco: and then do what with them?
<jsgotangco> mdz, just review/suggest what needs to be added
<mdz> jsgotangco: I suggest talking about "applications" or "programs" rather than "packages"
<jsgotangco> right
<mdz> jsgotangco: under What's New, "We've" shouldn't be capitalized
<mdz> jsgotangco: we're up to gnome 2.12.1 now
<mdz> jsgotangco: I suggest "Add Applications" (the name of the menu item) rather than "GNOME App Install"
<mdz> jsgotangco: the system requirements are a little confusing; the server install is much less demanding than the desktop, but your requirements for it are greater
<mdz> I don't think it's worthwhile to have  the "no desktop" option there, or it should be called something else
<mdz> and moved to the end of the table
<jsgotangco> ok
<mdz> I wouldn't mention that a desktop can be fit into less space, since the installer doesn't make it at all straightforward to do.  we should leave that to experts who already know
<mdz> the key description for the  server install is that it is the common base for all sorts of server applications; as such, it's minimal and designed to have the desired services added on top
* bddebian swears loudly and kicks gnome-launch-box
<mdz> jsgotangco: please list www.ubuntu.com/support ahead of bugzilla
<mdz> jsgotangco: that should be users' first stop for support
<mdz> or help->get help online
<jsgotangco> ahh right
<mdz> jsgotangco: in fact it might be best to separate "participation" (participate page, bugzilla, etc.) from "getting help" (ubuntu-users, IRC, forums, etc.)
<mdz> otherwise looks good
<jsgotangco> right the other stuff should fit in easily in a day or two
<jsgotangco> mdz, thanks will update the doc now
<mdz> no time to translate it, unfortunately
<jsgotangco> yes next time we'll aim to have relesae notes for every milestone
<mdz> we'll get better at this over time ;-)
<fabbione> morning
<bddebian> Hello fabbione 
<fabbione> mdz: did you build the dvd?
<fabbione> uh yeah i can see from the rsync
<mdz> fabbione: yes, I've tested amd64 and am testing powerpc and i386 now
<fabbione> ok i am rsyncing right now
<fabbione> mdz: i also need approval for that upload
<bddebian> Are elmo and Kamion the only ones that can let NEW stuff in to Universe? 
<bddebian> Wow, gnome-launch-box works
<bddebian> Would I get in trouble for uploading gnome-launch-box that was a combo of svn updates plus a user patch??
<grayman> is there a reason why a launcher on the panel returns address not found when the same launcher on desktop opens a directory?
<tritium> bddebian, I guess you'll have to find something else for me to fix?  ;)
<bddebian> tritium: :-)
<bddebian> tritium: tyvis needs love.  Or xgsmlib (unless \sh fixed it), or postgresql-plruby
<bddebian> :)
<tritium> that was fast ;)
<bddebian> :-)
<mdz> fabbione: what upload?
<fabbione> mdz: http://people.ubuntu.com/~fabbione/changelog <-
<fabbione> mdz: same as we discussed yesterday
<mdz> fabbione: yesterday was a long day
<fabbione> yeah i understand
<mdz> fabbione: it's still not over for me :-R
<fabbione> it just looks like i am pushing a lot
<mdz> I don't know what kind of face that was, but it's probably accurate
<fabbione> and i don't like that
<fabbione> but it's also important :)
<mdz> fabbione: I thought that was for post-RCT
<mdz> post-RC, I mean
<fabbione> yeah
<fabbione> but we are post-RC, aren't we?
<mdz> not until it's blessed
<fabbione> or do you expect to build more CD's?
<fabbione> ok
<mdz> I haven't even finished one full test pass yet
<fabbione> in anycase..
<fabbione> is it ok after RC?
<mdz> we need server install tests
<mdz> and OEM tests
<mdz> yes, perfectly OK for after RC
<fabbione> right..
<fabbione> ok thanks
<mdz> go ahead and upload it; if we need a last-minute kernel change, we'll just roll that in too
<fabbione> mdz: if you can instruct me on how to do OEM tests..
<fabbione> roger
<mdz> fabbione: I've never done one, but presumably there's an option in isolinux for it
<fabbione> ok
<fabbione> (i will still wait after RC to upload... just to be safe)
<poningru> I had a suggestion for faster startup
<poningru> basically load everything for X and then render a login screen
<poningru> but as the user is typing in the username/password the other stuff is loaded in the background
<fabbione> poningru: this is already happening
<poningru> ?
<poningru> it is?
<fabbione> yes
<poningru> docs por favor
<poningru> err docs please
<fabbione> check /etc/rc2.d
<fabbione> man update-rc.d
<poningru> hmm ok
<poningru> oh no thats not what I meant
<poningru> I mean even larger things
<poningru> like network
<poningru> or dma
<fabbione> you can't
<poningru> why not?
<poningru> does X require these things?
<infinity> poningru : Initialising the network after the user logs in may happen for dapper with network-manager.
<fabbione> you need to have network in place before X starts
<infinity> fabbione : Only loopback.
<fabbione> infinity: for default install lo is ok
<fabbione> if you need to listen on *:6000 you might have issues
<infinity> Yes, and for non-default, people know how to munge interfaces(5)
<infinity> But I'm hoping to kill non-lo interfaces from the "normal" boot sequence with n-m, if it can ever be made to play nicely and Not Suck.
<infinity> At any rate.
<poningru> so basically everything being loaded before login is what X is dependent upon?
<infinity> poningru : You really picked the wrong week to discuss this.  Poking people about it in a week and a half would be much better, after we're through getting breezy out the door.
<poningru> hehe true
<bddebian> infinity: Can you look at stuff in NEW?
<Amaranth> everytime network-manager is talked about it's either a rant about it sucking or someone saying it changed their life
<bddebian> Amaranth: Yeah, it's like editor wars :-)
<Amaranth> editor wars are so 1980s, we bitch about DEs these days
<poningru> EMACS
<poningru> DEs?
<calc> VI!
<poningru> sorry that was a joke
<calc> ;)
<poningru> :)
<bddebian> NANO
<calc> i can't imagine how slow emacs must have been in the 1980s
<bddebian> Amaranth: What else is there besides xpde? ;-P
<jmg> anyone have any suggestions for a thin client distro i can install to hard disk from cd?
<calc> debian probably has the needed apps and can be pretty small
<infinity> bddebian : No.
<fabbione> mdz: i386/server (net)install is ok on 2/2 machines
<jmg> there are plenty of thinstation etc
<poningru> jmg: perhaps ubuntuexpress ;)
<fabbione> mdz: i can see an oem install option on cd
* fabbione tests
<fabbione> too bad it's not on netinstall
<poningru> I had another question do we have a netinstall through windows thing yet?
<mdz> i386 DVD is good, powerpc doing stage2 install
<fabbione> no
<poningru> fabbione: to me?
<fabbione> poningru: yes
<poningru> ic thanks
<Amaranth> is there a netinstall at all?
<fabbione> mdz: i am still rsyncing dvds
<fabbione> Amaranth: yes
<mdz> fabbione: did you concatenate live+install CD ISOs to seed it?
<mdz> goes much faster that way
<fabbione> mdz: yup
<mdz> took about 1 hour per DVD for me
<Amaranth> maybe i've got the wrong term here, i mean the 50MB iso thing that installs what 'server' installs and lets you do the rest
<fabbione> yeah i started 30 minutes ago.. it'a 70% on the way
<infinity> Amaranth : No, fabbione meant a netboot image for PXE/tftp type installs.
<fabbione> mdz: the weekly dvd were generated 2 days ago.. so there is no much gap
<fabbione> Amaranth: there is that one too
<Amaranth> infinity: yeah, i figured that
<infinity> fabbione : I thought we didn't generate official netinst ISOs?
<fabbione> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/images/netboot/
<fabbione> infinity: we do.. but i don't think we consider it official
<fabbione> tho i still regularly test them
<infinity> Oh, right, the mini.iso that d-i generates in the build.  Forgot about that one.
<fabbione> (at least PXE boot)
<fabbione> infinity: i do test CD only close to release.. otherwise all my installs are via network
<fabbione> it's much faster for me given the local mirror
<infinity> <nod>.. Same.
<fabbione> i wish i had a gigabit switch
<fabbione> but i am going to buy one for xmas
<fabbione> today is powerbook day :)
<poningru> funny pics
<poningru> http://www.arouse.net/despair-linux/
<fabbione> i convinced my wife that i really really need one :)
<poningru> oops sorry wrong channel
<fabbione> why on earth we install xmkmf on desktop??
<infinity> Because xutils depends on it?
<fabbione> yeah i know that
<fabbione> humf
<fabbione> that's sort of lame
<fabbione> i guess xutils depends on it to preserve upgrades
<infinity> Yeah, we're pulling in a lot of modular stuff that I'd rather not for the sake of upgrades.
<infinity> Such is life.
* fabbione thinks
<Sepheebear> poningru:  that was hilarious
<fabbione> it's clearly too late for breezy
<fabbione> but there should be a new field for dpkg called Depends: foo [if-available] 
<fabbione> that will force install of foo if it's there
<fabbione> otherwise skip it
<fabbione> that would give us the option to create a meta-package
<fabbione> that can depends on all pkgs required for upgrades
<fabbione> but that we can keep away from cd
<fabbione> so old crack isn't pulled in
<fabbione> (if that makes any sense)
<infinity> This could be handled by the "pre-upgrade hooks" mvo and I discussed a few weeks back.
<poningru> Sepheebear: you should join us in #ubuntu-offtopic
<infinity> Of course, it's too late to get pre-upgrade hooks into the breezy versions of synaptic/update-manager
<infinity> Which kinda sucks.
<fabbione> well we will get it for dapper
<infinity> Yes, but that means we can't use them for breezy -> dapper.
<infinity> But oh well.  Life rumbles on.
<fabbione> infinity: none of us has 48 hours per day
<fabbione> ;)
<infinity> Well, I gave up sleep a few weeks ago and discovered I had 24h/day.
<fabbione> infinity: ahhaha
<infinity> Until that stopped working, I crashed hard, and had about 3 hours in a day, and 21 hours of sleep.
<fabbione> infinity: i have been there.. 10 years ago
<fabbione> but i did crash for 3 hours after a week
<fabbione> then decided it was not worth sleeping to get sober and went out to the disco for another 2 days in a raw
* infinity waits for his mirror to finish syncing, so he can jigdo up some test images.
<infinity> I wish my PPC machine booted from CD, so I could test there.
<fabbione> infinity: what ppc do you have?
<infinity> Riced-up OldWorld.
<fabbione> ok
<infinity> (Ancient beige G3 with a 1GHz 750GX upgrade)
<fabbione> ehhe
<infinity> Fast, but fast doesn't magically make openfirmware 2.4 stop sucking.
<fabbione> yeah
<fabbione> i will start discovering the ppc world soon :)
<fabbione> so i can start claiming to have 4/6 arches :)
<fabbione> (in ubuntu at least)
<fabbione> might soon get ia64 and hppa too
<fabbione> infinity: should we still consider that micro-ubuntu bof for arm/m68k?
<infinity> parisc machine are cheap and plentiful on eBay.  Sadly, no one seems to eBay them in Australia, and I don't want to pay overseas shipping on one of those beasts.
<infinity> Even the "small" machines (C200, etc) are heavy as all get out.
<fabbione> infinity: yeah.. 
<infinity> fabbione : It might be nice to sit down and draw up some quick ideas/plans, but I wouldn't dedicate more than a session to it, cause a real microbuntu with a small/embedded libc is probably not doable for dapper anyway.
<infinity> I wouldn't mind starting to bootstrap it for fun, though.
<fabbione> infinity: i am not that sure.. we have klibc that's pretty small
<infinity> fabbione : OTOH, the "slightly less micro buntu" idea (glibc-based, but really, really cut down installaiton footprint) is probably doable.
<fabbione> infinity: yeah let's sit and talk abou tit
<fabbione> i would love to get these 2 m68k up again for something cool
<fabbione> and testing would be an interesting thing
<infinity> Well, with all the d-i work smarenka has put into m68k in the last 2 years, m68k is much less of an adventure than it used to be.
<infinity> It now works so well that it just feels like a mid-range Pentium system that "just works"...
<fabbione> ahah
<fabbione> mdz: i386/oem cd install is good here.
<mdz> fabbione: yay
<fabbione> one minor detail that i am going to check again
<mdz> ppc dvd install is almost complete
<fabbione> the oem installer didn't ask me my location properly
<fabbione> in gfx mode when you select in what country you are in.. i select "others"
<mdz> jdub: did you find out what's up with the list archives?
<fabbione> but i didn't see the extra prompt for "-> Europe -> Denmark"
<fabbione> tho it still gets it right from d-i
<fabbione> brb
<mvo> mdz: I'm answering to your various questions on open bz bugs now, do you want some sort of message or will you read it on ubuntu-bugs?
<lamont> Mithrandir: awake yet?
* ajmitch tries fetching the dvd again - haven't got more than 20K of it so far
<fabbione> bah rsync connections are slowing down to death!
<fabbione> GOOD MORNING EUROPE
<lamont> hrm.. that reminds me.. need to file my implicit defn bugs
<mdz> mvo: I read ubuntu-bugs
* fabbione burns the first DVD
<fabbione> mdz: dvd live/i386 looks good.. 
<fabbione> installing now
<fabbione> but i think we have everything ok by now
<mdz> I'm 12/12 with the caveats mentioned in my -devel post
<fabbione> oh i forgot to mention.. i did also try install on LVM in some of the stages
<fabbione> well anyway you got a reply
<fabbione> mdz: re #17018.. libxft1 was not in hoary either.. they must had it around from warty
<fabbione> tho it's possible to repackage it..
<ajmitch> fabbione: maybe for universe?
<fabbione> ajmitch: for sure not main
<mdz> fabbione: it's in the Binary field for xfree86 4.3.0.dfsg.1-6ubuntu26, which was in hoary
<fabbione> mdz: hmmm it shouldn't...
<fabbione> because the last xfree86 upload had only the server
<daniels> libxft1 used to exist, yes, but libxft-dev has not existed for years
<fabbione> daniels: right..
<infinity> I assume these matlab packages are binary-only.
<fabbione> and we shouldn't resurrect the -dev at all
<fabbione> just the lib
<fabbione> daniels: Xft1 is not autotooled.. but it builds fine using imake & Co.
<fabbione> daniels: i guess i am going to create a source package out of lib/Xft1
<fabbione> but absolutely no -dev
<fabbione> it has to die
<daniels> is it worth packaging?
<infinity> matlab is pretty heavily used in certain fields.
<infinity> Of course, some bizdev folks hitting up mathworks and suggesting they should rebuild their binaries to not require the library would be good too.
<infinity> (but not likely to happen in a week)
<fabbione> daniels: yeah well it's an easy pkg to do
<daniels> all yours if you want it
<fabbione> + what infinity said
<fabbione> daniels: yeah i will do it
<fabbione> daniels: did you decide what to do with mkdirhier?
<daniels> mdz: ping
<daniels> fabbione: not yet, although now mdz and I are actually around at the same time, maybe something can come of it
<Mithrandir> lamont: awake now
<mdz> daniels: yes?
<daniels> mdz: did you get my comments over the past few days about mkdirhier?
<mdz> daniels: I heard from you that you think we don't need it, and from a user that he does need it
<daniels> that his custom scripts use it, yes.
<daniels> my contention being that a separate package for a shell script that does something posix-compliant versions of mkdir do anyway is pointless overkill.
<daniels> so, I'd appreciate your final word on whether or not we need a separate package for mkdir -p.
<mdz> no, I don't think we need a separate package
<mdz> but we shouldn't assume that it's OK to silently drop it
<daniels> i think that this is an extreme case; it's a reimplementation of a feature of POSIX mkdir.
<mdz> it could have been written and added back to xutils in the time you've spent talking about it
<infinity> Just sneak it into the xmkmf package or something, and call it done.
<daniels> isn't xutils a dummy package?
<mdz> yes, currently it only contains copyright and changelog
<mdz> daniels: any progress on that xkb bug?
<fabbione> mdz: permission to upload libxft1 (only the library, no -dev or -dbg)
<fabbione> mdz: it has to stay in universe..
<mdz> fabbione: yes
<pitti> Morning
<mdz> as we discussed
<fabbione> because we want to get rid of it
<fabbione> mdz: ok thanks
* infinity thinks xmkmf is the best fit for reintroducing mkdirhier, given its history.
<fabbione> infinity: i tend to agree on that
<fabbione> or even imake
<mdz> daniels: that is, of course, a higher priority
<fabbione> mdz: done
<infinity> fabbione : Nah, imake is a single binary with a reasonably specific purpose, xmkmf claims to be a "build system" which is nice and meaningless, and the perfect place to toss extra useless shell scripts. :)
<daniels> mdz: no, I've not looked at that XKB bug at all
<daniels> mdz: i've fixed others, however (as you saw, given I assume it was you that approved xk-c)
<fabbione> xmkmf is used only to generate Makefile out of Imakefile :)
<fabbione> sort of an imake wrapper
<fabbione> well it's all the same crack anyway
<bob2> that's sick
<fabbione> bob2: not really..
<mdz> daniels: beg your pardon?  I what?
* infinity sighs.
<infinity> mdz : Should I work on a post-RC lrm upload to make the -src packages actually work?
<mdz> infinity: how bad is it?
* infinity LARTs himself for never having tested them since taking that baton.
<infinity> mdz : Well, I think #17071 sums it up nicely.
<daniels> mdz: they don't work full stop, and never really have.
<mdz> I thought they were in universe, but apparently not
<infinity> mdz : They look to be effectively useless currently.
<infinity> They should be in multiverse, if they're not.
<fabbione> restricted you mean
<mdz> if they've never worked since hoary and no one noticed until now, we can do without them for breezy too
<infinity> I see no reason to support that in main/restricted.
<infinity> fabbione : No, I mean multiverse.  ie: they should be demoted.
<infinity> daniels : Oh, they were just as broken in hoary?
<fabbione> infinity: oh right
<infinity> mdz : Okay, if it's not a regression, I'm happy with fixing it all up for dapper.
<mdz> infinity: please verify that it's broken in hoary before giving up on it
<infinity> mdz : I'd be all for demoting the -source stuff to multiverse, though.
<daniels> infinity: yes
<daniels> infinity: and just as broken in warty
<daniels> one person appears each release cycle and bitches about it
<lifeless> day before release?
<infinity> Apparently so.
<daniels> no, usually about halfway through, to be fair
<infinity> daniels : This one was yesterday. :)
<infinity> http://bugzilla.ubuntu.com/show_bug.cgi?id=17071
<mdz> daniels: this xkeyboard-config upload which is sitting in accepted doesn't have any bug numbers in it; which ones does it fix?
<infinity> mdz : I'll grab a hoary CD and see if the breakage there is similar enough to call it "pretty much just as bad".
<infinity> In breezy, it looks to be 12 kinds of bad.
<daniels> mdz: 'none'
<daniels> mdz: several reports on irc and lists.  it's also demonstratably correct.
<daniels> i don't think the breakage pattern has actually changed since warty
<daniels> (breakage pattern -> for fglrx source and probably nvidia too)
<fabbione> mdz: what install do we need to test more?
<fabbione> imho we did cover everything
<mdz> fabbione: only what I already mentioned on the list
<mdz> Kamion may have one or two cases he wants to check
<fabbione> yeah but i did test OEM and server installs
<fabbione> so there is not much left to do
<mdz> yes, I saw
<daniels> mdz: three-level layouts without any kind of level 3 switch are as good as useless, if not work (being that a us layout is more useful)
<daniels> s/work/worse/
<mdz> daniels: what does that mean in the context of this being a regression from hoary?
<infinity> Hrm, are restricted/multiverse not seeded like main/universe?
<mdz> assuming you're talking about 15372
<daniels> mdz: it means that it's a regression from hoary, and that there's a fix uploaded
<mdz> infinity: they're overridden by hand by elmo I think
<daniels> mdz: 15372 is a clusterfuck regression from hoary
<infinity> mdz : Ahh.  Would explain it.  Would you have any objections to dropping the -source packages to multiverse?
<daniels> mdz: my current thoughts on that are just to force alts_toggle to ctrls_toggle and remove alts_toggle from being selected
<mdz> infinity: no
<infinity> Kay, I'll poke elmo about it when he gets back, then.
<mdz> I believe he's due back today
<daniels> mdz: if I 'fix' the alts_toggle stuff, then we won't have any xkb-related hoary regressions that I know of
<mdz> daniels: what would alts_toggle->ctrls_toggle do?  wouldn't that result in a different layout from hoary?
<daniels> mdz: yes
<daniels> mdz: alts_toggle -> switch between layouts by holding down both alt keys.  ctrls_toggle -> switch between layouts by holding down both ctrl keys.
<daniels> it's simply too late to come up with a proper, auditable, fix that I know won't break other stuff.
<infinity> mdz : Okay, I just extracted the tarball from the hoary fglrx-kernel-source and looked at it; it's broken in exactly the same ways, so this is no regression, just an unfortunate maintenance of the status quo.
<mdz> infinity: to multiverse with them
<maswan> Whee. I'm walking in through the building on my way to my office, and out in the corridor on a table I suddenly see a stack of Ubuntu CDs. :)
<infinity> maswan : hoary CDs?... Just in time for them to become obsolete? :)
<maswan> infinity: I guess, I didn't check though. :)
<hunger> infinity: Well, you can install them and upgrade.
<maswan> infinity: they had people on the front. :P
<pitti> doko: argh, did you recently change the name of libstdc++6-0? jigdo-file got uninstallable
<sivang> Morning all!
<pitti> Hi sivang 
<pitti> mdz: permission to upload a no-change jigdo to rebuild against the current libstdc++ and make the package installable again?
<mdz> pitti: jigdo is in universe
<pitti> mdz: right
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | RC preparation: no uploads to main,  TEST the current daily and report here!
<pitti> mdz: we don't need to ask for universe?
<pitti> ah, ok
<torkel> maswan: where are they? :-)
<pitti> mdz: I need jigdo for testing CD images :-)
<siretart> from http://cdimage.ubuntu.com/weekly-dvd/current/breezy-dvd-i386.list I see that fglrx is missing. is this on purpose?
<siretart> nvidia is there, after all.. hmm
<mdz> fglrx has never been on the CD
<infinity> nvidia is in the ship seed for multiseat, according to the comment in the seeds.
<infinity> Not sure what that comment means when expanded. :)
<siretart> aah. okay, this explains..
<infinity> pitti : Erm, jigdo is built against the latest C++ ABI here..
<siretart> mdz: wouldn't that be an option for the dvd?
<daniels> if we're not promoting fglrx, we should demote nvidia
<daniels> it would free up a ton of space on the cd
<pitti> infinity: Depends: wget, libc6 (>= 2.3.2.ds1-4), libdb4.2, libgcc1 (>= 1:3.4.1-3), libstdc++6-0 (>= 3.4.1-3), zlib1g (>= 1:1.2.1)
<pitti> infinity: and libstdc++6-0 does not exist
<infinity> Depends: wget, libc6 (>= 2.3.2.ds1-4), libdb4.2, libgcc1 (>= 1:3.4.1-3), libstdc++6 (>= 3.4.1-3), zlib1g (>= 1:1.2.1)
<infinity> powerpc, I guess?
<daniels> mdz: ^^ recommend nvidia for demotion from ship
<pitti> infinity: amd64
<infinity> Ahh, yeah.
<pitti> infinity: a local rebuild worked perfectly
<infinity> pitti : Please rebuild then. :)
<pitti> infinity: already happened :-)
<mdz> daniels: why?  does multiseat no longer need it,  or is multiseat broken by the new l-r-m?
<infinity> mdz : Installs on my i386 laptop and amd64 desktop went smoothly.
<mdz> infinity: thanks
* pitti curses at the "one rsync per IP" restriction
<fabbione> pitti: that was really mandatory
<pitti> fabbione: I know :-/
<fabbione> there were people overabusing rsync with 10 connections at the same time
<pitti> fabbione: ah, I'll ssh to chinstrap and rsync from there :-)
<fabbione> that would work too
<pitti> Hey Seberino
<pitti> mdz: which tests are required most urgently? desktop, server, or OEM?
<seb128> hey Martin
<seb128> pitti: you can download again? :)
<mdz> seb128: I noticed in my tests that the network monitor applet was missing from the panel in some cases; do you know why that might be?
<pitti> seb128: yes, my network is back
<mdz> pitti: yes :-)
<seb128> mdz: nop, read that on your mail, I'll have a look
<pitti> mdz: I interpret this as "I should do all at once" :-)
<mdz> infinity: we should flush the amd64 cloop after RC goes out
<mdz> hopefully it will shrink
<mdz> currently all 3 live CDs are oversized; we have some new and smaller WinFOSS which may help but we may need to squeeze a little harder
<jordi> mdz: hey
<Treenaks> lzip ;)
<seb128> mdz: so the laptop config has the applet but not the desktop config
<seb128> mdz: I'll fix that now
<jordi> mdz: if locales ended up not changing, how slim are the chances of updating belocs-locales-data in universe instead?
<mdz> seb128: that explains it
<mdz> jordi: universe is entirely unfrozen
<jordi> That would help the Kurdish guys a bit, even if they had to rely on a universe package to operate in Kurdish
<jordi> mdz: ie, I can ask for a sync right away?
<mdz> jordi: I haven't said no to a glibc update after RC
<jordi> mdz: I mean universe-for-breezy
<mdz> jordi: no one has sent me a diff yet
<seb128> mdz: would an update of gnome-screensaver to universe considered a bad idea?
<jordi> mdz: I'm talking about alternatives.
<jordi> just in case
<mdz> seb128: I've no problem with it
<jordi> mdz: I'll get jbailey to send one as soon as he rises
<seb128> mdz: cool, thanks
<mdz> jordi: if it is only adding a new locale, and not modifying existing ones, then I am unlikely to take issue with it
<jordi> mdz: ack
<infinity> seb128 : Err, I thought the lack of network applet in the desktop config was intentional, since desktops don't tend to have networks come and go much.
<seb128> mdz: should I mail you Cc: Kamion on my uploads, after candidate, to describe the fixes/with a debdiff of the changes?
<seb128> infinity: how was hoary? I'm not sure now
<mdz> seb128: for main?  that would be helpfuul
<seb128> mdz: k, will do
<infinity> Neither am I... Grab the relevant deb and peek inside? :)
<seb128> yeah
<mdz> seb128: if you have them prepared already, go ahead and send
<seb128> mdz: read what infinity just said?
<mdz> I don't see any reason why it should be different
<mdz> infinity: this is the network monitor applet, not netapplet or network-managre
<mdz> it doesn't actually do anything as far as interface configuration, it just goes blinky blink
<infinity> mdz : yeah, I know.  But there's not much to monitor on a (generally) wired network that doesn't change.
<infinity> Sure, some desktop are more laptop-like with a wireless interface and such, but that's a rare case.
<mdz> infinity: it has activity like any other network; that's all the applet shows
<infinity> Well, it also shows wireless connectivity and signal strength and such, which is the more useful reason to have it on the panel.
<infinity> If I didn't have wireless, I'd disable the applet here.
<mdz> oh, right, that's the same applet
<mdz> agreed then
<mdz> it's just a nuisance on the desktop
<seb128> k
<mdz> it's rather a nuisance on my laptop, too, since it's usually wired
<seb128> so NOTABUG :)
<mdz> but if we need to accept the annoying wired display in order to get the wireless display, so be it
<mdz> jordi: you can request syncs (or make uploads) to universe at any time until the MOTU team says no more (if they do at all)
<jordi> mdz: nod
<jordi> so, can anyone sync belocs-locales-* from unstable?
<mdz> jordi:  the procedure is to mail elmo and tell him which version of the package to sync
<jordi> ok. IRC has worked all the time before though :)
<pitti> jordi: wait
<pitti> jordi: did unstable add the install/remove-language-locales scripts?
<jordi> pitti: AFAICT, yes.
<pitti> jordi: ah, ok
<jordi> let me check.
<pitti> jordi: because the Debian maintainer said to me he didn't want to do that
<mdz> carlos,pitti: what's the latest story on langpacks?
<mdz> someone was reporting earlier that they saw regressions in translations
<mdz> Oct 05 17:21:12 <Surak> some strings reverted these days. Like screensaver is written in pt-pt when the rest of the system is pt_BR
<pitti> mdz: current packs look fine and yesterday I set up automatic merged tarball generation
<pitti> mdz: oh, I missed that, let me check
<mdz> pitti: why do we need a merge?  are the exports still incomplete?
<pitti> mdz: yes, Rosetta currently exports only 40% of main translations
<mdz> pitti: why?
<pitti> mdz: so I merge them with my buildd downloads
<pitti> mdz: no idea, apparently their import logic is still flawed
<pitti> mdz: carlos said that they have a new algorithm that works much better, but it's not in production yet
<mdz> carlos: when can we have complete exports?
<carlos> mdz, seems like the problem there is that the pt_BR was not imported into Rosetta
<carlos> mdz, so the gettext algorithm gets the pt translations 
<carlos> mdz, I will take a look to know where is the problem there
<pitti> carlos: humm, but then we shuold have the buildd pt_BR
<pitti> carlos: was there an empty pt_BR in Rosetta? or an old one?
<carlos> pitti, could be that we have an empty one... seems like the import failed and thus the export produced an empty file
<carlos> mdz, it will take sometime as there are a lot of templates to rename, I'm fixing the code to let Jordi help me with that task
<pitti> carlos: why do you need to rename templates?
<jordi> because "review-breeze-1" isn't the best name :)
<carlos> pitti, as I told you yesterday, if the import script was not able to guess a good translation domain, we set it to review-breezy-*
<pitti> seb128: darn, it seems my ISP still has trouble - I get no more than 20 kB/s downstream *grumble*
<pitti> carlos: "guess"???
<pitti> carlos: ah, you don't use the .mo files yet? I remember...
<carlos> pitti, I use them
<carlos> but sometimes the .mo files are missing
<pitti> carlos: please tell me if that is still the case; it should be fixed now
<carlos> or we have one .mo file and several directories with .po files
<carlos> pitti, for instance, gtk+ has that problem
<pitti> carlos: yes, for this case I need manual overrides, too
<pitti> carlos: but I only need to override some 30 source packages, not more
<carlos> we have two translation domains, so we get two different .mo files but we have multiple times those domains as po files
<carlos> pitti, Again, I now we have a design problem there, and I'm fixing it, it's too late to fix that for breezy, that's why I'm wotking on a new approach for that
<fabbione> maswan: ping?
<pitti> jordi: the Debian changelog of b-l-data does not tell anything about the scripts
<pitti> jordi: so please merge, don't sync
<carlos> pitti, another issue is the tarballs that use a build directory that depend on tha package version
<carlos> because we use the path too as a way to guess the right translation domain
<pitti> jordi: belocs-locales-bin should be fine, though
<pitti> jordi: (syncing)
<pitti> jordi: if you are at it, maybe the scripts make more sense in -bin anyway
<jordi> pitti: I'm not at it, no
<pitti> infinity: bah, jigdo failed on i386 on installation of Setting up libghc6-cabal-dev
<jordi> I mean, I'm not in the belocs team
<maswan> fabbione: pong
<infinity> pitti : Oh, right, I need to go clean up those chroots.  Thanks. :)
<pitti> infinity: is that a known broken package? or a chroot issue?
<pitti> infinity: ah, ok
<infinity> pitti : I'll rebuild it in a sec for you.
<infinity> pitti : Which buildd was that?
<pitti> infinity: vernadsky
<infinity> Danke.
<fabbione> maswan: do you happen to remember what kind of processors are installed on buttercup?
<pitti> infinity: well, the current i386 version is fine  anyway, so not urgent :-)
<infinity> It's urgent for me.  With no uploading happening, now is the ideal time to make sure everything's squeaky clean again. :)
<maswan> fabbione: hmm.. not offhand, I'll take a look
<fabbione> maswan: thanks
<fabbione> maswan: if they are Sparc IIIi processors we know why they were crashing and we will have a fix tomorrow
<maswan>   The sparcv9 processor operates at 400 MHz,
<maswan> II
<fabbione> i recall different infos from /proc/cpuinfo
<fabbione> but ok
<fabbione> than it might not be the same problem
* maswan nods
<fabbione> basically there is a user page corrupts on heavy load that affects only certain CPUs
<fabbione> it might as well affect that one too
<maswan> ok
<maswan> we can go back to linux then in a few days to try
<doko> pitti: libstdc++6-0 was dropped in May ...
<fabbione> maswan: sure..
<fabbione> that'd be great
<pitti> doko: I did a rebuild to make it work again. Odd though, probably I still had the old package in my apt cache
<pitti> doko: since I successfuly installed it two weeks ago
<fab-ltsp> mdz: ltsp install 100% success
<fab-ltsp> the howto seems pretty complete
<carlos> mdz, pitti latest pt_BR.po file from ubuntu's archive has 0 translations
<carlos> mdz, pitti so I don't think we have any regression...
<carlos> unless jwz broke it with latest release...
<pitti> carlos: maybe the guy mixed up gnome-screensaver and xscreensaver?
<dholbach> good morning
<pitti> Hey dholbach 
<carlos> carlos@rookery:/home/lamont/public_html/translations/temp/source/po $ msgfmt pt_BR.po -v --statistics -o /dev/null
<carlos> 0 translated messages, 11 fuzzy translations, 1698 untranslated messages.
<pitti> dholbach: btw, what happened to "Hellas"?
<dholbach> hey martin :)
<dholbach> pitti: it's not every day that i'm in a greek mood :)
<carlos> pitti, let me check gnome-screensaver...
<carlos> pitti, I doubt it, gnome-screensaver has translations for pt_BR but there are not translations for pt so the regression is not possible unless someone is translating into pt_PT using pt_BR
<pitti> carlos: ok, so the regression is in the package itself
<pitti> carlos: thanks for checking
<seb128> hey dholbach carlos 
<carlos> pitti, I think so, yes
<carlos> seb128, hi
<seb128> carlos: this is not a main package
<carlos> gnome-screensaver?
<seb128> yep
<seb128> it has been demoted to universe for the moment
<seb128> not sure if that makes a difference for you
<carlos> seb128, not for me but for language packs
<mdz> Kamion: awake?
* fabbione doubts
<zyga> morning guys
<pitti> Hi zyga 
<mdz> draft RC announcement at https://wiki.ubuntu.com/DraftBreezyRCAnnouncement (proofreading and feedback welcome)
<mhz> hi
<zyga> pitti: hacking on language packs :)
<mhz> could someone see my dhcpd.conf and tell me what is I am doing wrong, please?
<mhz> I got ltsp running, tftp running, but dhcp.
<fabbione> mhz: check /etc/defaults/dhcpd
<pitti> mdz: just read the announcement - maybe it is worth mentioning that we now use Rosetta translations?
<fabbione> and see if it is configured to listen on the correct interface
<mhz> fabbione: it's set ok
<zyga> mdz 
<zyga> mdz:   * The second stage of the installation now has a progress bar
<mhz> var/log/syslog says it is not configured to listen, but ltspcfg says it is :(
<zyga> mdz: this is really not interesting to many people IMHO, it's too technical
<mdz> pitti: yes, please add it
<Treenaks> mhz: do you have a weird network setup with multiple network interfaces?
<jsgotangco> zyga, for a release notes POV, its a new feature =)
<mdz> zyga: it's a significant usability improvement
<infinity> mhz : What else does syslog have to say?
<mhz> Treenaks: only eth0 and eth1 plus a dlink router
<zyga> mdz: then perhaps it could be re-worded to sound like such
<mdz> zyga: for example?
<zyga> mdz: new progress indicator will tell you how long the install is going to take, yada yada
<infinity> mhz : Anything like "no subnet declarations found for ethX"?
<mdz> zyga: it doesn't do that
<zyga> hmm :D
<zyga> mdz: maybe we should display cheerful messages while the installer is running ;-)
* zyga is out of ideas
<mhz> infinity: not now, but it did
<doko> mdz: add python-2.4.2 (and plone-2.1) to the announcement?
<jsgotangco> zyga, a fortune cookie
<mdz> doko: yes, please do
<Treenaks> zyga: yeah, like the "New Features" ads during Windows installations
<zyga> jsgotangco: including porn and politically-incorrect fortune cookies
<mdz> jsgotangco: will you fold these changes from the RC announcement into the release notes?
<zyga> ;-)
<jsgotangco> mdz, yup looking at the changes now
<mdz> jsgotangco: thanks
<zyga> Treenaks: silly as that may sound IMHO it was a *good* feature
<zyga> Treenaks: imagine mom and dad installing their brand new ubuntu system
<Treenaks> zyga: not for breezy, though
<infinity> mhz : Just sounds like a broken config, then.  Can you post it somewhere, or paste it on pastebin or something?
<mhz> infinity: ltsp generated a dhcpd.conf that it looked very good so i used that.
<fabbione> mdz: the announce looks ok to my itaglish
<doko> mdz: the windows programs on the i386 dvd seem to be outdated
<infinity> doko : We used the wrong tarball (apparently)
<infinity> doko : The newer one is both newer (one hopes), and a bit smaller.
<doko> infinity: fine, if it's known
<doko> infinity: is there a "main" HTML page, which I can open with a browser?
<doko> on the DVD?
<infinity> Not sure....
<sivang> Mithrandir: where are your deinotified kernels you rolled for #15571 ?
<Mithrandir> sivang: on the buildd, I haven't pulled them out yet.  Are you able to reproduce the problem?
<sivang> Mithrandir: I am with my Dell Inspirion ATA100 laptop, I reduced all the GNOME fancy stuff to minimum, and got a bit better on GUI responsivness, yet from time to time it pains me with performance stops
<mdz> doko: http://bugzilla.ubuntu.com/show_bug.cgi?id=17125
<sivang> Mithrandir: After noticing disk access, I think it's the same issue
<Mithrandir> sivang: excellent! I'll get you the kernels in a few seconds.
<Mithrandir> sivang: http://people.ubuntu.com/~tfheen/noinotify/
<bob2> does anything use inotify in breezy, by default?
<fabbione> Mithrandir: if that works.. fix userland later :)
<fabbione> bob2: gamin
<bob2> hah
<Mithrandir> sivang: if you could test those, I'd be grateful
<sivang> Mithrandir: I will do that as soon I get home, that issue has been killing my hacking performance for a week :)
<Mithrandir> sivang: ook.  Ping me when you have something
<sivang> Mithrandir: sure
<Kamion> mdz: still awake?
<Kamion> morning all
<seb128> hi Kamion 
<mdz> Kamion: yep
<mdz> Kamion: is this your idea of an early start? ;-P
* Kamion goes to pre-publish the RC images to mirrors
<sivang> morning Kamion 
<mdz> Kamion: I thought you had a few more tests you wanted to do
<Kamion> mdz: not really - I'd've liked to be up earlier, but my body rebelled
<sivang> Mithrandir: I need to use only linux-image* right? (there are several other files there)
* pitti looks at http://people.ubuntu.com/~ogra/buildlogs/ and sighs
<pitti> Hi Kamion 
<Mithrandir> sivang: the linux-image should be enough, yes.
<Kamion> mdz: pre-publishing just in .pool - even if we have to change, the rsync diff will be small
<mdz> Kamion: the LWE awards dinner sounded like a good scene ;-)
<mdz> Kamion: ok, sounds good
<mdz> Kamion: what's the procedure for pre-publishing?
<sivang> pitti: I didn't know you can track build logs by maintainer :)
<pitti> sivang: you can't
<Kamion> mdz: $ publish-release daily 20051005.1 install poolonly rc
<pitti> sivang: but ogra's page is nice to track the current builds
<Kamion> mdz: see cdimage/README
<sivang> pitti: I wonder how does he do that :)
<pitti> sivang: you mean so many failutes?
<mdz> Kamion: does that trigger any mirrors?
<pitti> sivang: probably just a glitch in the build log upload
<Kamion> mdz: publish-release never triggers mirrors; you have to sanity-check the results and then run sync-mirrors
<mdz> Kamion: I mean, do we have the ability to trigger some external mirrors, or do we need to wait for them?
<Kamion> mdz: I believe .us and .se are triggered automatically when syncproxy updates (syncproxy is triggered by sync-mirrors)
<sivang> pitti: no I mean, the script he wrote to track those builds :)
<pitti> sivang: oh, it's just some fancy wrapping for lamont's exported scripts
<pitti> sivang: http://people.ubuntu.com/~lamont/buildLogs/ and .../byDate
<mdz> Kamion: draft announcement at https://wiki.ubuntu.com/DraftBreezyRCAnnouncement
<pitti> sivang: but since lamont's logs are compressed, you can't just click'n'view
<infinity> pitti : The failures are intentional (though I'd like to see some successes in there too, just for fun)
<Kamion> mdz: ok, just catching up on mail then I'll read it
<Kamion> pre-publishing done
<Kamion> mdz: are we putting the DVDs on releases.ubuntu.com?
<Kamion> (we haven't before, but we can do)
<mdz> Kamion: I'm all for having the DVDs be less obvious
<mdz> but I did want to mention them in the announcement this time around in hopes of getting some real testing
<mdz> RC should be as close to final as possible in process
<mdz> not quite a dry run, but just slightly damp
<Kamion> cdimage.ubuntu.com/releases/breezy/ is the alternative location, not so widely mirrored
<sivang> mdz:re, * Support for automatic storage allocation into LVM volumes, maybe we want to make this less obvious in view of #15017 ?
<Kamion> it's mostly a question of how much disk space releases.u.c mirrors have :-)
<fabbione> sivang: it's in the release notes
<mdz> sivang: that's only about using free space; afaik erasing the entire disk and using LVM works fine
<mdz> fabbione: perhaps we should disable the freespace+lvm option?
<fabbione> mdz: i don't mind that, but it will require a p-a-l upload
<sivang> mdz: I choose "Use free space for LVM...etc" and it left my system inbootable, as noted in the bugreport
<fabbione> or Kamion to do some magic..
<mdz> sivang: yes, that's #15017
<Kamion> partman-auto-lvm isn't in the initrd so it's no harder than most packages to upload
<sivang> mdz: so erasing entire drive and using LVM (automatically) is not working, but manually it would.
<fabbione> sivang: EH????
<Kamion> sivang: "use free space for LVM" != "erase entire drive and use LVM"
<mdz> sivang: as Kamion says
<sivang> err, ok sorry
<mdz> Kamion: RC is appearing in the us.cdimage pool
<sivang> right, I apologize for misunderstanding.
<fabbione> mdz: i can do the upload.. just tell me what's your preference.. Kamion?
<mdz> fabbione: preference?
<mdz> is there another option available apart from disabling that case?
<fabbione> what you prefer me to do
<fabbione> demoting p-a-l to extra
<fabbione> that will take it away from the default install path
<Kamion> that loses the entire feature, effectively
<Kamion> few people know how to select extra features in anna
<fabbione> right
<fabbione> ok.. i will kill the Use free space thing
<Kamion> disabling the option can be a one-liner in choices, I'd've thought
<fabbione> Kamion: i checking it right now
<fabbione> shouldn't be enough to remove it from _numbers?=
<Kamion> fabbione: same effect, sure
<mdz> announcement is locked and loaded
<fabbione> Kamion: ok.. i am testing the changes just to be 200% sure
<jsgotangco> mdz, BreezyReleaseNotes updated on the wiki as well (just in case)
<mdz> jsgotangco: thank you
<zyga> where does 'About Ubuntu' menu item in system come from?
<infinity> zyga : Erp.  Nowhere, on my system.
<zyga> infinity: update - it's there
<mdz> infinity: known bug
<sivang> zyga: you probably want to ask seb128 about that
<zyga> I've just checked all .pot files that pitti exports daily and it wasn't there
<zyga> seb128: :-)
<mdz> infinity: http://bugzilla.ubuntu.com/show_bug.cgi?id=16982
<infinity> mdz : Good, cause I never owuld have clicked on it wihtout someone prompting.
<seb128> zyga: gnome-panel
<zyga> seb128: thanks
<seb128> zyga: but it depends on ubuntu-doc package beeing installed
<mdz> infinity: one of these days we will have formal test plans
<zyga> seb128: it's not in the .pot file
<zyga> seb128: no such package, ubuntu-doc... hmm
<Kamion> ubuntu-docs
<zyga> .sss :)
<zyga> okay I've got ubuntu-docs
<seb128> zyga: what do you ask?
<seb128> zyga: the "About Ubuntu" translations? That's a desktop file
<zyga> seb128: the phrase 'About Ubuntu' is not in the .pot file - it's not translatable
<seb128> the menu item?
<zyga> yes
<zyga> cd
<seb128> that's ubuntu-about.desktop
<seb128> from gnome-panel
<seb128> and desktop files don't use language-packs
<seb128> so this string is frozen and not translatable now
<zyga> uhh, okay 
<zyga> seb128: the desktop file does contain some translations, how can I get another one inside it?
<seb128> you can't, it's frozen now
<seb128> subscribe to ubuntu-translators
<seb128> a mail has been sent friday about that
<seb128> pointing to a wiki page for the desktop files to translate
<seb128> and the packages have been uploaded with the translation this week
<fabbione> Kamion, mdz: http://people.ubuntu.com/~fabbione/pal.diff <- tested
<mdz> fabbione: not much context in the diff, but I trust that you tested it.  ok with me.
<Kamion> fabbione: I think I prefer the _numbers change you suggested earlier
<Kamion> but that diff works too
<fabbione> mdz: it basically disable the feature by exiting the script that checks if the feature can be used
<fabbione> Kamion: that didn't work in my test.
<fabbione> Kamion: i rather be safe
<Kamion> ok
<Kamion> mdz: I'm doing various CD tests for the hell of it, but it seems everyone already did those last night. Time to just release it?
<fabbione> uploaded
<zyga> seb128: are you talking about this: https://wiki.ubuntu.com/DesktopTranslations
<Kamion> mdz: oh, perhaps worth noting in the announcement that the release candidate images require 700MB+ media
<Kamion> non-install/i386 anyway
<mdz> Kamion: sure
<jsgotangco> good idea
* fabbione uploads the kernel too since RC are out there
<jordi> mdz: ping :)
<mdz> jordi: WHAT IS IT NOW
<seb128> zyga: yep
<jordi> mdz: BOSTON
<jordi> err, no
<jordi> mdz: do you have a minute to look at this bug report? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=148565
<daniels> jordi: CONSPIRACY
<mdz> jordi: when is boston?
<zyga> seb128: aww, is it really too late for one more translation? :/
<jordi> should I consider applying it? I'm uploading gtk1 :)
<seb128> zyga: yeah, upload are frozen
<mdz> jordi: omg that bug is 3 years old
<jordi> mdz: YES
<seb128> zyga: as said, the translation freeze was one week ago
<jordi> mdz: Boston is just after UBZ
<jordi> ie, 11-15 nov
<mdz> jordi: I am gonig to be in SF at that time
<seb128> zyga: if you are interested by translation you should read the translators list
<jordi> SF SUCKS
<jordi> I SENSE THERE WILL BE AN EARTHQUAKE
<mdz> SF is one of my favorite cities in the whole world
<mdz> whereas boston is NOT
* zyga wasn't ware there is one
<zyga> seb128: okay thenks
<jordi> seek shelter at the Acetarium.
<fabbione> Boston rocks!
<jordi> mdz: I know SF is cool. But it's not on my travel plan this time :)
<fabbione> my grandma lives in boston.. so it must be better than SF
<jordi> mdz: so, is the patch safe, do you remember any drawbacks?
<mdz> jordi: have you been there? we should go sometimes
<mdz> sometime
<mdz> jordi: dude, it was THREE YEARS AGO
<jordi> mdz: nope
<mdz> that's like 30 open source years
<jordi> mdz: so what. I'm going to fix your bug. )
<jordi> :)
<Kamion> mdz: announcement edited
<mdz> I don't remember what I ate for dinner yesterday
<mdz> Kamion: I already edited my copy
<jordi> You're going to get a nice BTS email stating that your 3 YEAR OLD bug has been dealt with.
<mdz> jordi: I have even older open bugs
<Treenaks> jordi: _are_ you coming to UBZ?
<mdz> jordi: I don't even care about that bug anymore; the world has moved on to gtk2
<zyga> seb128: just one more question ... AFAIR some desktop files *were* translated inside each application, for example disks-admin and language-selector, did this change?
<mdz> jordi: but anyway this is way off-topic for this channel
<jordi> mdz: UBUNTU DOESN'T USE XMMS!?!?
<mdz> Kamion: us.releases is synched up, se.releases is almost there
<jordi> ok
<jordi> the patch doesn't apply anyway :)
<mdz> jordi: @#$#@%$!@%!@5
<seb128> zyga: they are, why?
<mdz> jordi: I just went to SF this past weekend, I had a blast
<zyga> seb128: then why are they listed on that wiki page? they can be translated through rosetta
<seb128> zyga: <seb128> and desktop files don't use language-packs
<seb128> zyga: we have updated the packages by hand with the translations from this page
<zyga> seb128: I know - but installing language-selector used to install a desktop file containing all translations
<seb128> zyga: no way
<zyga> seb128: yes
<jordi> mdz: mako is preparing a totally PUNKROCK party that weekend.
<seb128> that's a new app and there is no a lot of translations
<zyga> seb128: I did translate language-selector and disks-manager this way anyway
<seb128> zyga: maybe the title changed and that reseted the translations
<zyga> seb128: I'm sure it didn't :/
<seb128> zyga: disks-manager don't use rosetta translations for the .desktop
<zyga> seb128: I'll track this and let you know 
<seb128> zyga: translation from rosetta don't work for desktop files
<seb128> again
<seb128> the desktop is generated during the build
* infinity heads off for the day.
<seb128> so it has the .po from the build
<seb128> ie: the upstream one
<infinity> mdz, Kamion : Happy publishing, guys.
<seb128> we don't push rosetta po to the source package
<jsgotangco> its probably safe to grab the image now in the main links
<seb128> zyga: not sure if that's clear for you how that works, but no .desktop get its strings from rosetta
<mdz> infinity: dude, I've seen you leave and then come back and then leave again
<mdz> infinity: during one work day
<zyga> seb128: I understand now I think
<mdz> I need to go to bed
<seb128> 'night mdz :)
<jsgotangco> night mdz
<mdz> need to release RC first
<zyga> seb128: but some .pots do contain strings from .desktop.in files and those pots get translated in rosetta and find their way back into the package (do they?)
<jsgotangco> ahh
<zyga> then buidling the package updates the translation
<seb128> zyga: we didn't bother to do this wiki package for nothing
<seb128> zyga: no
<seb128> zyga: building the package is done from source
<seb128> zyga: there is no rosetta po for the build
<zyga> okay I see
<mdz> Kamion: can we push the symlinks out while se is still getting the isos?
<mdz> us is up to date
<Kamion> mdz: certainly; I'll do that now
<seb128> zyga: rosetta export its po to language-packs, no to source package
<zyga> seb128: I understand now
<seb128> good
<mdz> jordi: I could maybe go, but only for like a day
<jordi> you'd cross the con tinent just foor one day?
<ajmitch> hey jordi, how's it going? :)
<jordi> hi ajmitch 
<jordi> Treenaks: _yes_
<ajmitch> jordi: good, I hope you're in better health at UBZ than you were in sydney :)
<mdz> jordi: only  for a very good party
<jordi> mdz: then mako is the man you should ask.
<jordi> I hope it will be :)
<Treenaks> jordi: _cool_ :)
<mdz> ajmitch: jordi is accident-prone.  he was run over at debconf5
<jordi> startgirl will be around I think
<jordi> mdz: NEARLY KILLED
<ajmitch> mdz: the swim didn't help?
<mdz> ajmitch: he swam through the pain
<ajmitch> hah
<ajmitch> he'd do that
<ajmitch> he put up with me as an NM applicant
<Treenaks> there's a lot of water around montreal too...
<mdz> FROZEN water
<ajmitch> hi kobold 
<kobold> ajmitch: hi!
<Treenaks> mdz: it wasn't frozen in Finland?
<mdz> Treenaks: Finland was incredibly hot
<jordi> it wasn't
<ajmitch> jordi: you'll be happy to know that my packaging skills have picked up a bit since NM :)
<mdz> it was incredibly hot unless you come from Spain
<mdz> it was incredibly hot to me and I live in southern california
<jordi> you didn't feel the temperature when walking out the aiport in Valencia at my return.
<jordi> ajmitch: that's good :)
<jordi> so, what do you guys think about this?
<jordi>   * Patch the file selector to do file autocompletion like every other
<jordi>     application (thanks, Matt Zimmerman, even if you don't care at all :)
<jordi>     closes: #148565).
<jordi> is it a good changelog entry?
<mdz> it should also highlight the fact that the patch was made 3 years ago
<doko> mdz: is it necessary, that the CD Rom is searched (/pool scanned) on the live CD?
<mdz> doko: it is only useful on the live CD actually
<mdz> it speeds up the d-i unpacking process there
<mdz> elsewhere it is a waste of time
<Lathiat> a big one
<jordi> mdz: Done.
<doko> ahh, ok. maybe we can title the progress bar with "caching ..." instead of searching
<mdz> jordi: pop it
<jordi>     application (thanks, Matt Zimmerman, even if you don't care at all
<jordi>     just and because the patch is 3 years old and everyone is using GTK2
<jordi>     anyway :) closes: #148565).
<mdz> s/just //
<Kamion> doko: it used to speed things up pretty noticeably; that may not be true any longer
<Kamion> but everybody complained before I did that, and I get fewer complaints having done it
<mdz> Kamion: no RC on us.releases yet
<jordi> mdz: you don't care about poor orphan free software packages. You're a MONSTER
<mdz> jordi: I live to destroy
<doko> Kamion: yes, just the wording
<mdz> jordi: I especially like to destroy Linux distributions
<jordi> mdz: you maintain the ultimate tool for that, yes.
<jordi> I'm proposing a poll for debianplanet: Was mdz's apt6 upload TOO EARLY or TOO LATE?
<mdz> on the bright side, se.releases has an up-to-date pool now
<mdz> jordi: or BOTH?
<mdz> so that you have an option for joeyh
<Mithrandir> too late in this universe, too early in other universes?
<Treenaks> Mithrandir: so ask the MOTU
<jordi> mdz: of course
<Mithrandir> Treenaks: they're just masters of this universe, right?
<jordi> Mithrandir: the fun think is that joeyh told mdz in Finland that that upload was both early and late, after he had got quite some heat afor "totally breaking Debian" :)
<jordi> s/think/thing/
<Treenaks> Mithrandir: hm, good point.. how about MOTM?
<Mithrandir> jordi: which means that he shouldn't have uploaded at all?
<mdz> jordi: that was in #debian-devel actually
* sivang returns from lunach and tried to make sense of the backlog
<ajmitch> sivang: don't try
<Zomb> whoever mastered the Hoary live CD (mdz? Mithrandir?) : when you have time, have a look at https://www.redhat.com/archives/dm-devel/2005-October/msg00008.html and tell me if you have encountered that before
<sivang> ajmitch: lol
<maswan> mdz: well, it took an hour to sync it at 1 meg/s
<jordi> mdz: ah
<mdz> Zomb: I had some weird problems until I un-broke cloop
<Zomb> mdz: ok... un-broke? how? 
<Mithrandir> Zomb: I haven't seen it (except in cases where the media was bad, which obviously gave me problems)
<mdz> Zomb: it wasn't interfacing with the 2.6 block layer correctly
<Zomb> mdz: ok, are there any useful patches on the net? it is not in the cloop package AFAICS
<fabbione> hmm
<mdz> Zomb: the ubuntu sources are on the net, so yes
<fabbione> Zomb: i think we merged it into our kernel so it's on the net
<Zomb> aaah
<mdz> this channel is getting increasingly off-topic tonight
<infinity> mdz : Well, I'd stick around to make you feel better, but I'm not much help at this point, and I have a celebration dinner to attend. :)
<jsgotangco> ti's waitin' for RC prolly
<mdz> Kamion: something go wrong with that mirror push?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | RC is imminent
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | RC is imminent
<mdz> oop
<doko> seb128: which package belong the "About Ubuntu" docs to (seen in the help app)? At least the german ones still reference Hoary
<mdz> doko: ubuntu-docs
<seb128> what mdz said
<seb128> jbailey: around?
<fabbione> seb128: too early
<seb128> fabbione: right
* fabbione heads for food
<Kamion> mdz: looks fine to me; I'm still preparing the push with the symlinks
<Kamion> (and the source images)
<Kamion> shouldn't be long now
* jsgotangco patiently waits
<mdz> Kamion: please no source; I can't stay awake that long
<Kamion> too late, already done
<Kamion> just verifying indices and such now
<mdz> it took an hour to get install+live mirrored
<mdz> and source is twice as big
<Kamion> source < install+live
<mdz> oh, true. only one arch worth of source ;-)
<mdz> but still
<Kamion> like I say, too late, sorry :(
<Kamion> it's all on its way
<Kamion> (i.e. mirroring)
<Kamion> the DC mirrors are up-to-date
<mdz> yay, the symlinks went up first
<mdz> us and se are set
<Kamion> indices not though, apparently
<Kamion> i.e. the page still says "preview"
<jsgotangco> yea
<mdz> us says "index of ..."
<mdz> I can absolutely live with that though
<mdz> announcement is away
<pitti> yay
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | RC is released!
<doko> jsgotangco: are the hardware requirements synced with the CD cover layouts?
<pitti> mdz: congrats
<mdz> time to sleep
<pitti> mdz: sleep well
<janimo> sleep tight mdz
<Kamion> night
<mdz> someone add a link to the announcement to /topic if it shows up in the list archives
<Zomb> fabbione, mdz: thanks
<mdz> good night all
<fabbione> kdz
<Kamion> mdz: will do
<doko> night
<fabbione> mdz: good night
<pitti> Kamion: since uploads are happening again, do you think I can upload the Greek fontconfig fix?
<ogra> night mdz
<mdz> we'll do this for real next week ;-)
<Kamion> pitti: I checked that before RC and it looked fine, so yes
<ajmitch> sleep well mdz 
<pitti> Kamion: ok, thanks
<pitti> Kamion: I also checked with Greek, Japanese, and Chinese, I didn't see any regression
<fabbione> mdz, Kamion: thanks for letting the new kernel in
<Kamion> pitti: oh, good
<jsgotangco> doko, sent an email to silbs about it a few minutes ago
<pitti> Kamion: I was afraid to break the Asian fonts (since mgopen then has a higher priority)
<mvo> night mdz
<seb128> 'night mdz
<fabbione> infinity: you around?
<doko> jsgotangco: thanks, jsgotangco: 128MB is ridiculous
<jsgotangco> doko, please updated as needed, mdz will look over it again prolly this weekend
<jordi> mdz: I'm uploading gtk+1.2. THANKS FOR YOUR CONTRIBUTION!
<pitti> jordi: I wonder how many Ubuntu users will notice a GTK 1 change :-)
<jsgotangco> lol
<jsgotangco> xmms users?
<doko> fabbione, Kamion: can you really recommend 64MB minimum RAM for server installations? ok to double that to 128MB?
<jordi> pitti: many. MANY
<Kamion> doko: server installation => minimal base install
<Kamion> not ok
<fabbione> doko: 64MB are a lot to run a bunch of services
<jordi> I'm mailing the GNOME foundation, I have this great plan for GNOME 3.0
<pitti> doko: my home server (router, dhcp, ssh, files) has 20 MB :-)
<jordi> it'll be based on GTK 1.2.10 again, which is so much faster.
<pitti> doko: (well, it doesn't run Ubuntu, though)
<pitti> jordi: *ahem*
<tseng> jordi: we can bring back awesome gdk-xft hacks
<doko> well, on the other hand, I really can't recommend running our desktop with 128MB ...
<tseng> jordi: im in!
<jordi> tseng: who needs xft! that was one of the slowing agents!
<jordi> plain type 1 fonts. No unicode.
<jordi> unicode is overrated
<fabbione> doko: minimum required to install != recommended to run *
<ajmitch> jordi: might as well just go back to motif
<jordi> no man, motif was so bad.
<doko> fabbione: well minimum, or recommended, but "minimum recommended" doesn't make sense
<seb128> jordi "noise generator" mallach
<seb128> jordi: shut up now, that's a working chan :p
<jordi> yeah, I guess I'll shut up now. :)
<doko> jordi: go running
<jordi> i'll go pop the trunk
<Kamion> us.releases is fully up-to-date now
<Kamion> se.releases still has a bit to go
<Kamion> Riddell: have you tested the current set of Kubuntu daily install/live images? Are they ready for RC?
<fabbione> Kamion: 
<Riddell> Kamion: testing now
<fabbione>   partconf_1.09ubuntu2
<fabbione>   archive-copier_0.3.6
* Kamion builds Edubuntu daily
<fabbione> any of these 2 are in the initrd if you remember?
<Kamion> fabbione: neither
* fabbione unleash debian-installer build
<Kamion> fabbione: we'll need a new initrd build for the other architectures for the new kernel anyway
<Kamion> fabbione: so don't worry about getting the timing exactly right now
<fabbione> Kamion: yes.. but  i can get more test on ubuntu18 in the meanwhile
<Kamion> fine
<fabbione> if that's ok with you to process it BYHAND
<Kamion> fabbione: that's not a problem
<fabbione> perfect
<Kamion> se.releases up-to-date
<jordi> pitty is alive!
<pitti_live> jordi: it's "pitti", not "pitty" :-)
<pitti_live> hmm, the old ffox start page was much nicer
<jordi> pitti_live: that's a pitty!
<pitti_live> brb
<seb128> firefox sucks anyway
<pef> hello
<jordi> seb128: when do you push for ubuntu to ship ephy by default?
<kikidonk> yes ! yes !
<ogra> booo
<jordi> ff sucks so much
* kikidonk agrees
<doko> pitti: why are english language packs installed for a german installation?
<ogra> doko, they are always installed
<ogra> not only in german installs
<Kamion> doko: by mdz's request pre-hoary
<Kamion> we always install English
<Kamion> so there's always a fallback; it's not like they're large
<doko> ok
* Kamion wonders what happened to mdz's announce mail
<fabbione> has it been approved?
<seb128> jordi: https://wiki.ubuntu.com/EpiphanyDefaultBrowser
<rob^> eww.. try Opera now that its free
<Kamion> fabbione: ah, I guess not
<ogra> rob^, free ?
<rob^> yes
<ogra> did the chnage it to opensource ? 
<ogra> thats news to me
<rob^> its been free (not opensource) for a few weeks now
<ogra> rob^, its "bennerfree" thats all...
<ogra> *banner
<rob^> no banner
<ogra> thats what i typed
<rob^> no banner + free = free opera
<ogra> before it was free and had a banner...
<rob^> they removed licensing fees too
<ogra> the only change i see is that they ripped out the banner
<Treenaks> rob^: Free as in money != free as in freedom
<rob^> yes, Treenaks thats what I said
<jordi> seb128: that's a nice page.
<rob^> 21:28| rob^ its been free (not opensource) for a few weeks now
<Treenaks> rob^: yes, and ubuntu only includes Free software..
<ogra> rob^, its been like that since years... it just had a banner
<Mithrandir> ogra: which meant it stole  screen estate. :-)
<ogra> Mithrandir, true....
<rob^> I didn't say we had to include it, I just said its another option to firefox now that its free as in free (not as in freedom)
<doko> DVD images for i386 and amd64 look ok
<ogra> but that doesnt make it more free for me than before :) just more usable
<rob^> well, it won't cost you anything ;)
<ogra> it never did cost me anything 
* rob^ gives up
<seb128> jordi: yeah :)
<\sh> rob^: it's not an alternative for ubuntu, only for kubuntu as konqui replacement
<\sh> rob^: and this should never happen
<rob^> well it will never replace ff as the browser of choice in Ubuntu
<\sh> hmmm...who has the powers to check if linphone-common for amd64 is handled as NEW?
<\sh> rob^: opera is QT
<\sh> rob^: that's the point ;)
<rob^> but I don't see why we would want to drop ff for Epiphany
* Kamion kicks emacs out of ship
<Kamion> bam, 14MB freed up on the install CD
<Lathiat> heh
<Lathiat> not more? ;p
<Lathiat> thats like 10 language packs or something :)
<Kamion> if it was more, I'd have said more
<Kamion> that's the figure germinate gives for i386
<rob^> its such a popular internet browser that people would question why we would remove it
<kikidonk> rob^ epiphany is gnome
<kikidonk> ubuntu uses gnome
<Kamion> \sh: linphone-common is not in NEW
<\sh> Kamion: not for i386 or ppc but I don't find amd64 (which I enabled with the last upload)
<Kamion> \sh: the decision about whether something lands in NEW isn't architecture-specific, anyway
<Kamion> once it's added to the overrides once, that applies to all architectures
<\sh> Kamion: hmmm....
<rob^> kikidonk, yes, but ubuntu doesn't just use gnome
<\sh> I'm such an idiot
<Kamion> \sh: judging from (a) the build log and (b) the state of the archive, your upload does not build linphone-common/amd64
<\sh> Kamion: is ok...I changed the control file on ravel and not locally...but adjusted the changelog on my local machine *bangmyheadonmydesk*
<kikidonk> rob^ do you know what browser kubuntu uses ?
<rob^> yes
<\sh> Kamion: bug thx
<kikidonk> that was a question, actually :)
<\sh> but even
<\sh> kikidonk: konqueror as for kde and ff 
<kikidonk> so they use konqueror by default, i bet
<rob^> I'd much rather tell new users that Ubuntu uses ff, because a lot of non-technical users know what that is
<kikidonk> do you think new users care about which browser they use ?
<rob^> yes
<kikidonk> they don't even know there are more than IE :)
<rob^> most know about ff now days
<rob^> for example, on sfd this year I had several people ask me what applications Ubuntu ships with
<rob^> I said OOo, firefox.. all knew or at least heard of them
<rob^> if I was to say Epiphany they would just look at me strangely
<kikidonk> ok
<kikidonk> it might be an argument
<kikidonk> but you can always install firefox beside epiphany
<rob^> yes, but you can also always install epiphany beside ff
<rob^> if thats what you prefer
<kikidonk> that is not saying that epiphany is superior to firefox :P
<kikidonk> that' what i do, indeed, i guess this is all just a stupid "flamewar"
<rob^> yeah
<poningru> if I may chime in
<kikidonk> but i still do think that being gnome a gnome distro it should a least ship with all gnome components
<rob^> not trying to have a flamewar, ff has its problems but I think sticking with it would be better for Ubuntu 
<poningru> I think an end user distro should ship with transitional software
<poningru> transitional software meaning the user has some exp with it so that s/he doesnt feel lonely in the linux world
<poningru> it has some familiar apps there
<rob^> yes, for example the Open CD
<rob^> very handy on sfd :)
<poningru> exactly
<kikidonk> i don't like the idea of ubuntu being windows, just without the price problem
<rob^> its far from that kikidonk 
<kikidonk> we deserve more than being just transistional software
<rob^> ff just happens to be best of breed at the moment, and the most popular non-ie browser
<poningru> kikidonk: you have to ween people off
<poningru> even if that means crappy software at first
<infinity> What's so 'crappy' about firefox that epiphany solves, anyway?
<poningru> they get frustrated then you say to them look we have better software sitting two clicks away
<slomo> seb128: something fast to fix: https://launchpad.net/distros/ubuntu/+sources/nautilus-cd-burner/+bug/2889
<poningru> infinity: thats what kikidonk is saying
* rob^ looks at his new windows laptop.. just a matter of time before its Ubuntuified (this weekend)
<poningru> so I just went along with a 'for the sake of the argument'
<seb128> slomo: no, it's not
<kikidonk> yes :)
<slomo> seb128: not? ok :/
<rob^> ok I'm off to bed
<rob^> night all
<seb128> slomo: cdrdao has to be promoted first
<kikidonk> but infinity are you using any QT software on a gnome install by default, no because QT doesn't "integrate" with the gnome way
<kikidonk> same can be said with firefox
<seb128> slomo: https://bugzilla.ubuntu.com/show_bug.cgi?id=13168
<kikidonk> nd is the main point i think
<infinity> kikidonk : Until a large number of OEM systems ship with Ubuntu (or Linux in general), you have to deal with that fact that we can't target "completely newbie users", but we also have to target people who are a little more "web savvy" and "brand conscious", because those are the people who will suggest Ubuntu to their "normal" friends.
<seb128> slomo: will be fixed after 5.10
<infinity> kikidonk : The Firefox brand id very helpful with that, given its prevelance on the web.
<kikidonk> yes i do agree about that, what is saddening right now, is that epiphany isn't even installed by default
<infinity> kikidonk : People are used to seeing "works with IE and Firefox" out there at this point, and they don't want to see some "no name browser" shipped by default.
<mvo> Kamion: how are uploads handled now? I have a fix for a users-admin crash on amd64 pending
<jbailey> seb128: Am now
<mvo> slomo: cdrdao dosn't have a working -scanbus ATM :/
<infinity> kikidonk : Installing two browsers by default (or two of anything by default) is silly.
<seb128> jbailey: hi
<Kamion> mvo: as pre-RC, but showstoppers only
<seb128> jbailey: do you know why yelp summary has "Courte description du systme Ubuntu Hoary" for " propos d'Ubuntu" ?
<kikidonk> yes that is true :)
<infinity> Kamion : I assume "segfaults hideously on one arch" is a showstopper?  (I have a pending php5 upload for that)
<mvo> Kamion: ok, thanks. a crash on amd64 each time a user is added is serious enough I figure?
<infinity> Kamion : Which I will make when I'm not innebriated.
<Kamion> mvo: yes
<seb128> infinity: read the webpage about what epiphany fixes
<jbailey> seb128: Err, no. =)
<Kamion> infinity: yes, that's acceptable
<jbailey> seb128: I can remove that translation. 
<seb128> infinity: better GNOME integration, gettext translation shipped with the package, schedule matching the GNOME one
<poningru> seb128: dude its all a giant flamewar
<jbailey> seb128: The OMF files weren't put into Rosetta, but there were some bits that were already translated.
<kikidonk> :)
<poningru> on planet deb
<poningru> on here
<poningru> please stop
<seb128> jbailey: can't you fix it rather? What title is that supposed to translate?
<jbailey> seb128: So I kept those.  they come from before me.
<Kamion> kikidonk: speaking as the guy currently trying to make CD images fit, I completely agree with infinity; we don't need duplication
<seb128> poningru: who are you?
<poningru> seb128: sorry just a random guy
<kikidonk> yes that was a stupid proposal
<seb128> poningru: why do you talk about flamewar here?
<poningru> didnt mean to yell at a dev in here
<kikidonk> and beside ephy needs gecko anyway so currently you have to install both
<jbailey> seb128: This document aims at answering questions that are asked frequently. It contains Wiki entries from the ubuntu.com web site, the mailing lists and all contribution that we received through the Ubuntu Bugzilla.
<poningru> seb128: kikidonk and someone else were arguing about epiphany and firefox
<seb128> jbailey: it has an english subtitle?
<jbailey> seb128: No, that'
<jbailey> s what the English version of that has.
<seb128> poningru: yeah, you can have a discussion on the topic without doing a flameware
<poningru> ok
<poningru> well I assumed this was a continuation of what was going on many blogs
<seb128> how firefox is translated is enough to hate it to start :)
<doko> seb128: the gnome startup analysis is a nice read
<seb128> doko: yeah
<seb128> jbailey: k, thanks ... so could you fix it? :)
<seb128> jbailey: or should that be fixed on rosetta?
<jbailey> Well, it should go through Rosetta and have someone whose French is more perfect than mine do the Translation.
<seb128> will do it, thanks
<jordi> jbailey: JEFF
<jordi> got my email?
<jordi> seb128: Subject: Bug#148565: marked as done (libgtk1.2: gtkfilesel completion does not behave like anything else)
<jordi> :)
<seb128> bah
<fabbione> Kamion: d-i- ubuntu 18 is up.. mind ot BYHAND it?
<Kamion> fabbione: done
<fabbione> Kamion: thanks
* Kamion gets the CD images back within size, I think
<jordi> pitti: so did will belocs-locales be up to date? did you request a sync?
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | RC is released! http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000035.html
<Kamion> seb128: should launchpad-integration bugs go to you, or to sivang, or what?
<seb128> Kamion: me is fine, I can reassign them then if required
<Kamion> ok
<pitti> jordi: I didn't request a sync since that would destroy my changes
<pitti> jordi: please merge
<seb128> pitti: do you know about #17148 ... we already talked about such stuff, do you have some other such bugs?
<segfault> is there any new CD image, or its the same as yesterday?
<jordi> pitti: I don't know how to do that
<jordi> pitti: if it's not "mail elmo"
<Lathiat> hrm, the umu.se rsyn cmirror seems to be having issues
<Lathiat> it randomly wont list stuff in the breezy dir,a nd then when it does, i try to get the .iso and it says its not a regular file
<seb128> jordi: mege? that's easy, you diff Debian and Ubuntu version and you apply the Ubuntu specific changes then you do and upload :p
<Nafallo> Lathiat: ping maswan about that :-)
<Kamion> Lathiat: well, it's not, it's a symlink
<pitti> jordi: as seb said
<pitti> jordi: we used to have merge-o-matic for this, too, but it seems to be broken ATM
<Kamion> Lathiat: could be one of the machines is missing a file though; as Nafallo says, ping maswan
<Lathiat> Kamion: well, thats broken
<Lathiat> Kamion: ok
<Lathiat> maswan: ping
<Kamion> Lathiat: what's broken?
* pitti finally finsihes the hoary->breezy upgrade
<pitti> got the dreaded keyboard dialog
<Kamion> segfault: all CD image building has been disabled for the RC.
<Lathiat> Kamion: it says its a non regular file when i try to rsync, and sometimes a directory listing of releases/breezy/ just shows "breezy", and sometimes it works
<Kamion> definitely sounds like one frontend is out of kilter
<Nafallo> pitti: you should find a way to tell people about /var/lib/postgres -> /var/lib/postgresql :-)
<jordi> pitti, seb128 : I can't upload ubuntu packages.
<pitti> daniels: hmm, I still got the keyboard question after hoary->breezy upgrade; keyboard now works fine, though
<Nafallo> pitti: hi btw :-P
<pitti> Hi Nafallo 
* Kamion goes to release the RC DVD to further stress mirrors ;-)
<jordi> If anyonme wants to do this merge for me, the Kurdish people will be happy
<seb128> jordi: you can do the work and be sponsored
<Kamion> jordi: (they still won't get installer support in breezy ...)
<Lathiat> ok i see
<pitti> jordi: the Kurdish people will be happy if glibc's locale supports the locale; jbailey promised that, but I'm not sure whether Breezy will get it
<Lathiat> Kamion: seems one of the machines showed a release/ instead of ubuntu-releases/
<Lathiat> *releases/
<Kamion> -> maswan then
<jordi> Kamion: minor glitch
<jordi> "minor" as in you only install once, you use ubuntu many times after that
<Kamion> true
<Lathiat> gha, us.releases gives the same non-regular file thing
<pitti> Nafallo: pg_lslclusters will tell you the path
<pitti> Nafallo: seriously, why do you think it's so important?
<Nafallo> pitti: I have that path on a seperate lvm-partition. I had a 100% full /var yesterday :-P
<pitti> Nafallo: if /var/lib/postgres is a separate partition, the transition does not touch it
<pitti> Nafallo: the path is pretty much arbitrary in the new architecture, you can use whatever you want
<pitti> Nafallo: the transition just tries to use the canonical path
<pitti> Nafallo: so you dist-upgraded, and the cluster was moved to another partition?
<Nafallo> seems like it, can't be sure though. I was rather tired ;-).
<Nafallo> my databases got prunned to :-P
<pitti> "prunned"?
<Nafallo> removed, deleted, stopped to exist :-)
<pitti> Nafallo: hmmm?
<Treenaks> pruned
<Nafallo> so I have NFC what I did :-P
<pitti> Nafallo: they were removed automatically? there is no code that does this
<Nafallo> clearly, I don't consider this a bug since I don't know what I did :-)
<pitti> Nafallo: ok; if you feel like checking and see an important bug, please cry immediately :-)
<Nafallo> hehe, I will :-)
<Nafallo> otherwise I figure someone else will if the hit it ;-)
<pitti> Nafallo: many people upgraded since them (myself included, on 3 machines)
<pitti> Nafallo: I had some minor things, but never total data loss
<pitti> Nafallo: maybe the cluster is just misconfigured now?
<pitti> Nafallo: i. e. the transition failed to configure the new path properly?
<Nafallo> could be, but the old path only had lost+found :-)
<pitti> hmm
<Nafallo> working not anyway, with /var/lib/postgresql and a new database :-P
<Nafallo> s/not/now/
<pitti> seb128: I don't have a similar bug; we eject USB devices deliberately (see the old iPod bug)
<pitti> seb128: I'll answer
<maswan> Lathiat: Ah, rsync on releases? That's because the uk.releases have that as a "releases" rsync module, while se.releases has it as "ubuntu-releases"
<seb128> pitti: thanks
<maswan> Lathiat: I've asked the uk.releases admins to fix this, since rsync has no vhosting, we're not comfortable with calling anything just "releases". that would appear as ftp.se.debian.org::releases and ftp.mozilla.org::releases and ftp.gnome.org::releases
* maswan is gone for a meeting, back in a few hours
<Nafallo> wow
<Nafallo> what would FOSS be without that cluster :-P
<Nafallo> doko: ping :-)
<Robinho_Peixoto> which is the burn cd/DVD default of Ubuntu ?
<pitti> Robinho_Peixoto: #ubuntu
<pitti> Robinho_Peixoto: you mean the default program? nautilus-cd-burner
<\sh> Kamion: can u do me a favour when you have time? Please check the control file of linphone_1.0.1-6ubuntu7 and tell me what's wrong with linphone-common? it doesn't show up for amd64 on archive.ubuntu.com...
<pitti> Kamion: ok to upload security updates to Breezy?
<pitti> Kamion: (with minimal backported patches, as usual)
<doko> Kamion: Nafallo: png
<Nafallo> doko: openoffice.org2-core deps openoffice.org2-common (>1.9.129-0.1ubuntu3) but 1.9.129-0.1ubuntu3 will be installed.
<Robinho_Peixoto> The programs update-manager and gnome-app-install are not in rosetta.  It has forecast to place in rosetta?
<mvo> Robinho_Peixoto: gnome-app-install is availabe at https://launchpad.net/distros/ubuntu/breezy/+sources/gnome-app-install/+pots/gnome-app-install
<mvo> carlos: any idea why update-manager is not imported yet?
<bddebian> Morning
<Nafallo> morning god ( bddebian ) :-)
<bddebian> pfft.  Hi Nafallo
<Nafallo> hihi
<sivang> hey bddebian 
<bddebian> Howdy sivang
<doko> Nafallo: oh crap, thanks for the pointer
<Nafallo> doko: np. I got hit by it ;-).
<bddebian> Kamion: ping?
<bddebian> seb128 or ogra: ping also? :)
<lamont> doko: I'm wondering what exactly you did change in the oo.o2-amd64 control file... add ia64 perhaps?
<lamont> doko: if you're in there, see 17119
<seb128> bddebian: what about just asking?
<doko> lamont: just updating it from the oo.o2 control file (two deps, adjusting descriptions)
<doko> lamont: that looks like a defect deb on ia64?
<lamont> doko: that bug says that everywhere in that control file that says 'Architecture: amd64' should also say 'ia64'
<lamont> see oo.o-amd64.
<bddebian> seb128: Sorry, I never know when someone is actually "here".  I have a "working" gnome-launch-box but it is a combo of an svn update and a patch from a user.  Should I even bother?
<lamont> OTOH, I'm not sure that I _want_ that fixed for breezy... livecd is on the bitter edge of going back over 700MB again...
<seb128> bddebian: you can let a message for people not here
<seb128> bddebian: you worked on it, if it works upload it yep
<doko> lamont: your call, I did an upload without that ...
<bddebian> seb128: Should I add some svnblahblah version to it?
<seb128> bddebian: yeah
<seb128> <currentversion>svn2005nnnn
<slomo> bddebian: you fixed it? good work :) svn didn't work for me because of new gnome-menus api ;)
<bddebian> slomo: Yeah, I worked on it but I got a better patch from StoneTable.
<slomo> seb128: wouldn't <currentversion>+svn2005abcd be better? with the +
<bddebian> I hate all that crap :-)
<slomo> bddebian: hehe so i can finally test it and see whether it is really useful ;)
<seb128> slomo: no, why?
<bddebian> slomo: It's not. ;-)  Actually it is kinda neat but the interface sucks
<bddebian> So here is current version: 0.1-0ubuntu4  I would make it 0.1-0ubuntu4+svn20051004  ?
<bddebian> Err ubuntu5...
<slomo> seb128: almost everybody uses it ;) maybe dpkg has some magic to let 0.1sz be higher than 0.1+svnbla so upstream can release some version like that ;) no idea...
<slomo> bddebian: 0.1svn20051004-0ubuntu1... or with the +
<bddebian> Ugh
<seb128> slomo: no magic, 0.1anything is less than 0.2
<slomo> seb128: and 0.1anything less than 0.1.1?
<seb128> man dpkg
<seb128> dpkg --compare-versions
<bddebian> seb128: So what would the "correct" way be?
<seb128> bddebian: anyway you want
<seb128> version as you want
<seb128> or put the diff to a patch
<bddebian>  0.1svn20051005-0ubuntu1?
<seb128> by example
<slomo> seb128: ok, 0.1anything < 0.1.1 ;) btw, who was the gstreamer maintainer and in which irc channel can i find him? except one bug (that should be fixed soon) wavpack should be ready for inclusion
<Riddell> Kamion: i386 and powerpc kubuntu CDs are good
<seb128> #gnome-debian on gimpnet, lool is the maintainer
<Riddell> jbailey: did you get a chance to test the amd64 kubuntu CDs?
<seb128> but he's quite busy atm
<bddebian> I'll try the patch route and see if it works
<slomo> seb128: ok, thanks... then i'll wait until the beginning of next week :) this can wait
<rob^^^> hrmm, VirtualPC works very well but DefaultDepth needs to be 16 for video not to be garbled.
<rob^^^> Is there a way to have that autodetected?
<Treenaks> rob^^^: what kind of video card is emulated?
<rob^^^> Treenaks: hold, a sec, it's loading ... slowly ;)
<rob^^^> VPC is a great way to take a look at dailys without closing down my 20 apps I have open ;)
<jbailey> Riddell: I haven't, sorry.  I've just been looking at a couple bugs that might be RC worthy.
<Lathiat> jbailey: any idea on my slow loading modules one?
<Lathiat> jbailey: that causes usplash to timeout
<Lathiat> cus not having usplash any boot sucks :(
<jbailey> Lathiat: Nope, but it won't be fixed for Breezy.
<jbailey> Lathiat: And post-breezy, that whole module-loading bit will change significantly.
<Lathiat> is the usplash early load change going to be reverted then?
<jbailey> No
<rob^^^> Treenaks: I'm having a hard time from Device Manager, dmesg, and /proc
<rob^^^> hrmm, maybe the hardware reporting wizard can help
<Lathiat> jbailey: well, that sucks
<Treenaks> rob^^^: lspci
<jbailey> Lathiat: If you can still manage to boot, then it's not going to be important enough to risk breakage during RC.
<Lathiat> well, i already count it broken, heh.
<jbailey> Lathiat: You do eventually get to a gdm screen, right? =)
<Lathiat> yes, but i go through all sorts of horrid pain and suffering
<Lathiat> and withdrawl
<rob^^^> 86c764/765
<jbailey> Lathiat: It's true, the withdrawl method is not terribly effective.
<Lathiat> and it burns my eyes
<jbailey> Lathiat: But it will have to do until the dapper cycle.
<Lathiat> pff
<jbailey> Lathiat: Just be brave and test with us for that release.
<Lathiat> jbailey: so, whats ahead for dapper?
<Lathiat> jbailey: your lucky it doesn't break on my canonical laptop or i'd jump up and down harder ;p
<jbailey> Lathiat: Hard to say.  Dapper discussions mostly take place at UBZ.  I'm hoping for a more conservative release, given how long we have to support it.
<Lathiat> jbailey: i more meant specifically the modules stuff
<Lathiat> jbailey: since you mentioned that was changing
<Lathiat> curious what to
<rob^^^> exact string is 0000:00:08.0 VGA compatible controller: S3 AInc. 86c764/765 [Trio32/64/64V+] 
<jbailey> Lathiat: The udev upstream posted a patch to make it possible to watch hotplug events.
<Lathiat> jbailey: meaning?
<jbailey> Lathiat: So we'll be much more conservative of what we load at the startup time, and mounting root will trigger based on a uevent.
<jbailey> Lathiat: so USB booting will Just Work(tm)
<Lathiat> jbailey: oh, nice
<jbailey> Lathiat: Beyond that, it means that we can go very quickly from there into gdm, because we can order the bits needed for that first.
* Lathiat nods
<Lathiat> i hope the gnome login stuff will get niced too
<jbailey> In what way?
<Lathiat> since it seems that we can get large optimizations very easy from the various reports
<rob^^^> Treenaks: Xorg will run but it's quite stretched horziontally
<Lathiat> just things like not reading from 370 files every login
<rob^^^> like 5x as wide as it should be or something
<Lathiat> like this one for example
<Lathiat> http://www.gnome.org/~lcolitti/gnome-startup/analysis/
<jbailey> Lathiat: Ah pure upstream stuff.
<Lathiat> jbailey: oh, kyeh
<Lathiat> jbailey: but its still related
<Lathiat> its a shame avahi support can't work out of the box :\
<Lathiat> damn no server policy
<Lathiat> our network code is flawless, honest ;)
<slomo> Lathiat: no server policy?
<Lathiat> slomo: can't have any open ports out of the box
<bddebian> Grrr, I need my NEW stuff to come through.. :-(
<slomo> Lathiat: :(
<slomo> jbailey: are there any news on the ppc-xfs problem?
<jbailey> slomo: No, I wasn't able to figure out what the problem is for certain, and I don't know the ondisk XFS layout well enough to get it.
<slomo> jbailey: did you report this to the yaboot guys? otherwise i would do now...
<jbailey> slomo: I spoke to Ben about it, yes.
<slomo> jbailey: ah ok... thanks :) well so i can't use initramfs for breezy... when you get something to test for me just tell me ;)
<rob^^^> Treenaks: any thoughts on what it could be?
<jbailey> slomo: Will do. =)
<Treenaks> rob^^^: read the docs
<Kamion> \sh_away: linphone-common seems to have built fine for amd64; I assume it just arrived later
<Kamion> pitti: yes
<Kamion> doko_: pong
<Kamion> bddebian: pong
<Kamion> jbailey: testing Kubuntu/amd64's relatively urgent; it means we can do a Kubuntu RC release
<Kamion> I can do it in principle, but it'll take hours
<jbailey> Kamion: 'k
<jbailey> Kamion: I can't easily test an install, but I can test live CD definetly, and live DVD is my burner feels up to it today.
<jbailey> (The DVD burner has been giving me alot of coasters lately)
<doko_> Kamion: pong for what?
<Kamion> doko_: 14:13 < doko> Kamion: Nafallo: png
<doko_> Kamion: hmm, something left in the buffer ;)
<bddebian> Kamion: Can you please look at libchipcard2 stuff for me?  I think one of the binaries came in as NEW
<Kamion> bddebian: been on it for the last few minutes or so
<Kamion> (having cocked up the override change the first time round)
<wickedpuppy> hi guys got a question ... suppose i would like to port a program from another distro to ubuntu .. how would  i go about doing that ?
<wickedpuppy> any links ?
<jbailey> wickedpuppy: Do you only wnt to do one, or are you interested in helping keep a bunch of packages happy in Ubuntu?
<Kamion> bddebian: libchipcard2* and libofx* are in queue/accepted/ now
<wickedpuppy> eh i am new so i start with one ?? 
<wickedpuppy> i will take on more as i get more confidence
<jbailey> wickedpuppy: Well, just that if you're interested in getting involved, the Masters of the Universe team is a good place to get involved with.
<wickedpuppy> yup i am prepared ... i am on wiki , launchpad and setting up my pbuilder as of now
<jbailey> wickedpuppy: They have little tasks that will help you learn packaging, and after you develop confidence and have some experience, you'll be able to upload your packages to Universe.
<jbailey> wickedpuppy: Great!  It's probably best to poke your head into #ubuntu-motu
<bddebian> Kamion: Awesome, thank you sir
<wickedpuppy> oh greats .. where can i find those little tasks jbailey ? in wiki ?
<jbailey> wickedpuppy: I'm not involved with them on a day-to-day basis, so it's probably best to ask in there.
<wickedpuppy> oh ah ...
<wickedpuppy> heh ... actually my problem is i am fully aware of the ubuntu dev process
<wickedpuppy> so i am not sure who does what and where things are sent to
<wickedpuppy> if you guys know any guide on it , i appreciate if you could point out to me
<wickedpuppy> thanks
<bddebian> Kamion: Any idea how long that will take?  I'm sorry to be a pest but I have a user that will test the ofx stuff in gnucash for me.
<Kamion> bddebian: "cron.daily" (the name's historical) runs at 3 and 33 minutes past every hour, and takes under 10 minutes to run. Mirrors (including archive.ubuntu.com) are triggered at the end of every cron.daily run.
<Kamion> bddebian: in other words, it's there now (it being ~45 minutes past the hour)
<bddebian> Kamion: OK, thx, sorry
<bddebian> Kamion: Do you know if the dep-wait for libaqbanking self-cleared also?  Lamont's site still shows it?
* bddebian feels like a major pain in the ass right now
<seb128> grumpf, no needinfo nor upstream for malone
* seb128 kicks malone
<bddebian> seb128: Aye :-(
<bddebian> And afaict no way to view bugs I have subscribed to or made comments on :-)
<Kamion> bddebian: yes, libaqbanking's building now. There's a slight delay (only 20 minutes or so, I think) on lamont's buildlogs mirror
<Kamion> dep-waits generally auto-clear unless they're on virtual packages or something like that
<daniels> pitti: can you please send /etc/X11/xorg.conf, and the output of xprop -root | grep _RULES?
<bddebian> elmo!! Welcome back :-)
<carlos> mvo, update-manager still lacks the .pot file
<Lathiat> lamont, elmo, infinity: about?
<Kamion> elmo: welcome back. archive hasn't crashed and burned, you'll be glad to hear
<Kamion> 5.10RC on LWN
<Kamion> (http://lwn.net/Articles/154760/)
<Lathiat> It seems nothings attempted to build oprofile for amd64 but its listed in arches, any idea why?
<bddebian> Kamion: :-)
<mvo> carlos: it looks to me like it's available (0.37.1+svn20050404.14)?
<Lathiat> ouch, ogras buildlog page is like a sea of red
<Kamion> Lathiat: Packages-arch-specific says "%oprofile: i386 ia64 alpha hppa powerpc sparc"
<Lathiat> Kamion: is that that silly override thing?
<Kamion> Lathiat: s/silly //, but yes
<Lathiat> ok, i guess i'll try find out if it actually works on amd64
<Kamion> Lathiat: you'll need to get elmo/someone to update it
<Lathiat> Kamion: can i get that list?
<Lathiat> well, it seems to be building on debian
<Kamion> Lathiat: I believe it currently matches http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup
<Kamion> Lathiat: Debian/amd64 may well just blatantly ignore P-a-s
<carlos> mvo, yeah
<Lathiat> cheers
<Kamion> it wouldn't surprise me
<carlos> mvo, http://people.ubuntu.com/~lamont/translations/20051005/update-manager_0.37.1+svn20050404.14_hppa_translations.tar.gz
<mvo> carlos: looks like there was a missing build-dep on intltool; D'Oh
<carlos> mvo, ok
<mvo> Kamion: uploaded update-manager with "intltool" added as build-dep, no other changes. hope that's ok
<mvo> carlos: new version uploaded, thanks for leting me know about the problem
<carlos> mvo, I will try to add in the future some kind of notification to the maintainers about this issue automatically, in the mean time I need to check the logs manually, sorry...
<desrt> where are the archives?
<tseng> desrt: which?
<desrt> ca.
<desrt> it was down yesterday and today
<desrt> hmm.. maybe it's just a connectivity problem between school and it
<mvo> carlos: yeah, some sort of notification would be nice
<carlos> mvo, my main concern is if we have a way to know if the maintainer field has an Ubuntu maintainer or a Debian one...
<carlos> I don't think a Debian one will be interested on that kind of "SPAM"
<mvo> carlos: oh, right. that's a pretty big problem indeed 
<carlos> hmm, I suppose I would check if is an Ubuntite or not
<Kamion> mvo: should be fine
<bddebian> elmo: If you are around and happen to have a second could you look at my @ubuntu.com e-mail?  I don't get any and I'd really like to start using that on my uploads.  Thanks.
<Kamion> carlos: I'd've thought this would be best dealt with by having separate Ubuntu owners registered for packages in Launchpad, and some kind of "none" field there if there's no explicit Ubuntu maintainer.
<Kamion> carlos: (we get lots of other nice effects from that)
* mvo thinks of something like the default assignie in bz
<Kamion> indeed, except more global and exported to the Maintainers file etc.
<carlos> Kamion, well, whatever solution you find is ok for me, as soon as I can get that info ;-)
<Kamion> we could seed it from the bugzilla default-assignee list, even
<carlos> Kamion, anyway, I can get that information from launchpad, I don't need it directly from hte source package so I suppose it's easier for me that way
<Kamion> carlos: I've already asked for it in the context of Malone, although (as discussed then) it's clearly a Launchpad-global thing; I don't know if I got anywhere
<carlos> Kamion, yeah, that would be useful for Rosetta to send this kind of notifications
<Kamion> nobody seemed to know whether it was possible to make a package have a different owner in different distributions
<Kamion> I sincerely hope the data model allows for that
<Kamion> I'm sure it did originally ...
<whiprush> jdub: ping
<wickedpuppy> Failed to fetch cdrom:[Ubuntu 5.10 _Breezy Badger_ - Alpha i386 (20050902)] /dists/breezy/main/binary-i386/Packages.gz  Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs
<wickedpuppy> hi how to solve this error message ?
<wickedpuppy> i did apt-cdrom add to added the cdrom 
<mdke> wickedpuppy, you should ask in #ubuntu
<wickedpuppy> but still having this error
<wickedpuppy> okie sorry
<mdke> np
<slomo> daniels: as you seem to be one of the dbus maintainers in debian... do you know when we can expect dbus 0.50 in unstable?
<Robot101> slomo: its in experimental
<Robot101> slomo: has been for ages
<slomo> Robot101: yes i know... but i asked for unstable ;)
<Robot101> oh
<Robot101> lalala :)
<Robot101> it breaks stuff or something
<Robot101> quite a lot of foo needs to be recompiled I think
<seb128> not only recompiled
<seb128> the API changed
<slomo> yes... and ported to new apis :/
<Robot101> so its a horrific transition of dhoom
<pitti> but many packages are in experimental that just wait for dbus
<Robot101> which presumably is done already in ubuntu?
<pitti> Robot101: we did it for breezy
<pitti> Robot101: everything is ready and just waits for dbus
<seb128> Robot101: I'm not sure than universe is
<Robot101> hm
<Robot101> what do the release badgers say?
<pitti> Robot101: I assume daniels waits until the other transitions are complete in etch
<seb128> pitti: GNOME 2.12 should go with it and it's not ready atm
<pitti> Robot101: vorlon asked not to break etch further
<seb128> yeah, new GTK is waiting too because of that :p
<slomo> who wants to patch dbus? ;) http://lists.freedesktop.org/archives/dbus/2005-October/003514.html
<slomo> or is it already too late?
<Lathiat> heh
<Lathiat> its probably waaaay late ;p
<Kamion> seems far too late for that
<slomo> Kamion: even for a small bugfix like that? ok...
<infinity> There are lots of small bugfixes to be made, but the only ones getting in a reasonably critical ones.
<bddebian> Aren't new l33t versions of ANYTHING critical? ;-P
<infinity> Too many unimportant small bugfixes add up to big archive churn, which adds up to "stuff magically becoming unstable and not being ready for release anymore"
* bddebian hides
<Kamion> slomo: a simple URL with no justification is not enough; if you provide justification, i.e. major breakage caused by the lack of this patch, then that might be different
<Lathiat> it breaks avahi. :)
<slomo> Kamion: see Lathiat ;) but as avahi isn't in main this is probably not critical enough...
<Robot101> Kamion: it means nothing in python can send/recieve unicode strings on dbus
<Robot101> Kamion: (and a unicode string isn't necessarily one that contains unicode, its just however python is representing it internally)
<\sh> Kamion: did you find the time to have a look over linphone and the missing amd64 package of linphone-common?
<Lathiat> \sh: i've requested it be added to packages-arch-specific
<Lathiat> oh
<Lathiat> wait 
<Lathiat> wrong pcakage, i was looking at that one too 
* Lathiat screws his brain on correctly
<\sh> Lathiat: well...it should be already be build...but somehow it's not in the archive...
<Lathiat> \sh: interesting
<infinity> \sh : http://archive.ubuntu.com/ubuntu/pool/universe/l/linphone/linphone-common_1.0.1-6ubuntu7_amd64.deb
<infinity> \sh : Looks there to me.
<infinity> Are you just being impatient again? :)
<\sh> infinity: wow...the last time I checked (before 2 hours) it was compiled, and all other archs where there, but not the amd64
<Lathiat> yeh ditto
<infinity> \sh : Which means the amd64 upload probably just missed the previous dinstall run, that's all.
<arkais> hi
<\sh> infinity: ok...you're right...my doctor says all the time that I'm a terrible patient ;) I can't wait ;)
<bddebian> :-)
<bddebian> How can I tell for sure that libofx2 conficts and/or replaces libofx1c2 ?
<azeem> why should they conflict?
<infinity> Or replace, for that matter.
<bddebian> azeem: On installing the new gnucash
<infinity> ...
<azeem> bddebian: so you want libofx1c2 removed when upgrading gnucash?
<azeem> bddebian: this should be left to the admin/the APT frontend 
<infinity> bddebian : If they have different SONAMEs, they shouldn't need to conflict, that's kinda the point.
<\sh> guys...TB reschedule meeting @ 20 UTC?
<bddebian> azeem / infinity: trying to overwrite `/usr/lib/libofx.la', which is also in package libofx1c2
<azeem> bddebian: .la files should be in -dev packages, no?
<infinity> .la files shouldn't be in the library package.
<infinity> (Well, we really shouldn't ship them at all, but if you must, they should be in the -dev package)
<bddebian> hmm
<azeem> having the -dev libraries conflict is alright
<azeem> Thomas Bushnell, BSG is responsible for this Debian package
<azeem> bah
<infinity> bddebian : So, move the .la to the -dev package, and have the -dev package "Replaces: libofx1c2, libofx1, lobofx1c102" (or whatever packages had that .la file in them)
<bddebian> azeem: Aye ;-)
<infinity> bddebian : Alternately, just say "screw it, it's wrong, but I refuse to deal with it right now", and have the library package do the replaces, and file a report with Thomas to get his act in gear.
<bddebian> Heh, OK
<infinity> bddebian : Either way, no need to Conflict, just use Replaces to overwrite the file.
<desrt> this is why the archive appears to be offline, i suspect:
<desrt> http://www.theregister.co.uk/2005/10/06/level3_cogent/
<infinity> Damn, makes me wish I was an affected Cogent customer.
<desrt> the two places i can't hit it from are on cogent
<infinity> A year of free bandwidth, when I don't even want to talk to L3 customers, sounds pretty good.
<Amaranth> infinity: you probably have to sign a contract
<pitti> Hi mdz 
<mdz> nothing like a solidly wedged video card to help one wake up with confidence
<bddebian> Heh.  Good morning mdz
<mdz> thanks to whoever moderated the announcement...I realized when I woke up this morning that I forgot to do it
<\sh> guys...u really made my day...the first time in the last months I don't have to tweak the initrd of the installer iso :)
<mdz> \sh: tweak the initrd?
<\sh> mdz: sk98lin problem
<\sh> mdz: before I could install breezy I had to open initrd and include a separate sk98lin driver and put it back into the installer media
<mdz> Zomb: thanks for the nasty comments.  I sent the patch upstream ages ago.
<bddebian> Doh
<\sh> bddebian: conflicts/replaces i think is a good idea for libofx2
<bddebian> \sh: Or I should probably fix it correctly as infinity pointed out..
<\sh> bddebian: yes this would be better
<infinity> \sh : No need to conflict for a file overwrite.  Just replaces.  Please.
<Zomb> mdz: does not change the fact that it has been broken in Debian for months, fixed in Ubuntu for months, and nobody did know about that except of the few Ubuntu developers. And upstream does not care unless some bug hits him directly.
<infinity> \sh : There's no reason why two libraries with different SONAMEs should ever have to conflict.
<mdz> Zomb: that is no excuse
<\sh> because of the .la?
<mdz> Zomb: you asked me for help, I answered your questions gladly, and you responded with rudeness in your changelog
<infinity> \sh : What about it?... That doesn't make the packages conflict, just means the new one needs to overwrite the file in the old one.  That's what "Replaces" does.
<\sh> infinity: *bang* yes
<infinity> \sh : Again, two packages that have libraries with different SONAMEs should (almost) never conflict.  If they do, you break smooth transitions, locally-compiled packages, etc.
<Lathiat> infinity: i think you need to write a guide on this stuff :)
<bddebian> Oh, hehe, libofx2 does have Replaces but the -dev doesnt
<infinity> Lathiat : It's called Debian Policy. :)
<Lathiat> with easy steps for diagnosing what you need to do :)
<bddebian> Weird
<spayne> doko: ping
<Lathiat> heh 
<\sh> bddebian: not in your package
<bddebian> \sh: I just re-pulled the source
<bddebian> Package: libofx2
<bddebian> Architecture: any
<bddebian> Depends: ${shlibs:Depends}
<bddebian> Replaces: libofx1c2
<Zomb> mdz: fine, see it as you wish. IMO "rude" is a bit different.
<\sh> bddebian: from whom?
<bddebian> \sh: apt-get source libofx
<\sh> bddebian: in debian libofx.diff.gz there is nothing to see 
<infinity> bddebian : That should probably be a longer list (1, 1c2, 1c102), I'm betting the .la file has been there forever.
<mdz> Zomb: I took time to talk with you about it even though we were in the middle of preparing a release.  The least that you could do was to be civil.
<doko> spayne: pong
<infinity> bddebian : And yes, I see no Replaces on the libofx2 package in the archive.
<\sh> +Package: libofx2
<\sh> +Architecture: any
<spayne> doko: when i go to change the icon theme in OOo2, there are no options
<\sh> +Depends: ${shlibs:Depends}
<\sh> this is the diff from debian
<spayne> doko: so i can't change it to the standard one - is this a known bug?
<bddebian> Well it's there.. WTF???
<mdz> Zomb: if you have a complaint about me in the future, talk to me rather than writing it in a changelog.
<zyga> hello
<infinity> bddebian : Oh, it's there in -3ubuntu2, which isn't built/uploaded yet.  La la la.
<zyga> who build the live cds?
<\sh> lol
<Lathiat> maswan: about?
<infinity> bddebian : My most recently available binary is -3ubuntu1
<\sh> my source as well was -3ubuntu1
<doko> spayne: you can file an enhancement request, very low priority ...
<infinity> bddebian : Anyhow, a -3ubuntu3 that fleshes out that Replaces line would be nice.
<spayne> doko: a few versions ago, i could do it
<bddebian> Smurf fixed it
<spayne> doko: but seems to have disappeared in recent uploads
<\sh> hmmm...
<Lathiat> maswan: it seems my rsync client has problems dealing with your symlinks
<bddebian> But he only added libofx1c2 not libofx1
<Lathiat> maswan: e.g. the isos symlink to ../.pool/
<Zomb> mdz: hookay, the next issue will go through open mailing lists first... no irc, no changelog comments.
<infinity> bddebian : Hrm, probably no need to add libofx1c102, looks like it never was in a stable Debian or Ubuntu release.  But yes, please add libofx1, it's in Sarge at least.
<bddebian> Ahh, WTF happened to gnome-launch-box?? :-(
<ogra> mdz, the "|| true" solution wont give me the opportunity to notify the user what to do, will it ? (re: ltsp)
<mdz> ogra: you mean if they read base-config.log?
<ogra> mdz, nope, if i add a debconf notification... i didnt plan to have any echo stuff in a final version, its just to outline the principle
<mdz> ogra: it is too late to add debconf templates
<ogra> ok
<mdz> keep it absolutely dead simple
<ogra> so only a "|| true" and a notification in the install notes then... better than the current state at least
<mdz> mvo: around?
<mvo> mdz: yes
<mdz> mvo: never mind, I see you attached the patch in bugzilla
<mvo> mdz: which one in particular? gnome-system-tools?
<mdz> pitti: is there any possibility for these fontconfig changes to affect non-greek languages?
<mdz> mvo: yes
<mvo> mdz: I have fixed another crash (on amd64, services-admin). I would like to fix it too 
<pitti> mdz: in theory yes, since it moves priority of the Asian fonts below mgopen
<mvo> mdz: one line fix: G_TYPE_INT -> G_TYPE_POINTER
<Kamion> Lathiat: those aren't his symlinks, they're my symlinks
<pitti> mdz: but in practice Kamion, ogra, and I checked that Asian fonts work as before
<Kamion> Lathiat: there are rsync options to deal with that
<Riddell> Kamion: kubuntu amd64 CDs are good, i386 DVD is good
<Kamion> pitti: I didn't test this myself; I only quickly eyeballed the diff
<Kamion> Riddell: yep, amd64/install working for me
<Lathiat> Kamion: oh, what do i have to pass?
<pitti> mdz: since mgopen does not provide Asian fonts, it does not "shadow" them
<Lathiat> Kamion: unfortunately just using rsync with no flags makes it die
<Kamion> ogra: there are Edubuntu CDs and DVDs waiting for you to test if you're going to do a release candidate
<Riddell> Kamion: great, can you put them on the server?
<Kamion> Lathiat: man rsync, search for 'symlink'
<mdz> dholbach: gparted?
<Kamion> Riddell: we have many servers :-)
<Kamion> Riddell: but I'll assume you meant "please release the Kubuntu RC" and do that ;)
<ogra> Kamion, i didnt plan a RC way to much stuff to fix... but i can test the isos indeed
<Riddell> Kamion: that'll be the one
<mdz> mvo: sounds fine
<dholbach> mdz: it's a couple of fixes from cvs, upstream advised me to get in
<mdz> dholbach: we're post-RC; we need to be very cautious
<dholbach> mdz: the changes all made sense and were reported either in out BTSs or in gnome's one, but if you want me to do a patch for more clearity, i can do so
<dholbach> mdz: a cherrypicked patch
<mdz> pitti: so mgopen contains only greek glyphs?
<Riddell> do uploads still have to be vetted by mdz or Kamion?
<mdz> Riddell: all uploads still require manual approval, through the final release
<Riddell> mdz: ok
<mdz> Riddell: you don't need to ask in advance if it's obvious and safe
<mdz> pitti: there are many more speakers of asian languages than greek; we don't want to cause problems for them ;-)
<pitti> mdz: mgopen probably also contains latin glyphs, but we have higher priority fonts for them
<pitti> mdz: right, I checked Japanese and Chinese, and mgopen does not contain *any* asian glyphs
<mdz> pitti: ok, thanks
<pitti> mdz: I compared a Japanese and CHinese desktop without and with the patch
<pitti> mdz: I didn't see any difference in terms of glyphs
<pitti> mdz: btw, would it be possible for uploads to only appear at b-changes after they are actually accepted?
<pitti> mdz: in the case of a rejected upload the mail cannot be undone...
<mdz> pitti: that's an elmo question, but I suspect it isn't worth the effort
<mdz> this is a temporary hack for breezy
<pitti> mdz: propably depends on the number of uploads that are actually rejected
<Kamion> pitti: UNACCEPTing stuff is nasty anyway
<mdz> pitti: they can't be rejected because they've already been accepted
<mdz> I don't expect to reject anything
<pitti> ok
<mdz> only hold things until after release
<Kamion> pitti: we don't reject stuff generally, we either ignore them or get people to supersede them with different uploads that resolve problems
<Kamion> (e.g. bash)
<bddebian> infinity: Did kmymoney2 ubuntu2 come through?  It's been a while since changes got accepted and it's not showing up on lamonts site
<mvo> mdz: gnome-system-tools uploaded with a amd64 crash fix for services-admin
<fabbione> mvo: is that ubuntu9 or ubuntu10?
<mvo> fabbione: ubuntu10 is the updated one, ubuntu9 fixes another amd64 crash
<mdz> jbailey: ping
<fabbione> mvo: thanks
<fabbione> mvo: i mean.. thanks for making my life impossible ;) i am trying to build get the last 2 pkgs built for sparc to have RC CDs :P
<fabbione> super itaglish++
<bddebian> infinity: Never mind :-)
<fabbione> but you get the point :P
<mvo> fabbione: is the sparc a 64 bit arch? if so, you probably need ubuntu10 :)
<fabbione> mvo: yes it's a 64 bit kernel arch, but userland is 32
<mvo> fabbione: can I help you in some way? send you the ubuntu10 packages or something?
<fabbione> mvo: nah.. don't worry.. just stop fixing bugs :)
<mvo> fabbione: heh :) ok
<mdz> lamont: did you or infinity flush the amd64 cloop?
<mdz> ogra: is 16726 actually a bug, or just sabdfl's screensaver selection?
<spayne> doko: i've took a screenshot (http://www.evolutionconsultancy.com/~spayne/OOo2-NoIcon.png) and it looks like there is a fault with the actual chaning of icon themes as the correct .zip files are present
<ogra> mdz, i'll have to look at it...
<ogra> mdz, normally rss-glx shoud add the screensavers in postinst to /etc/X11/app-defaults
<ogra> i didnt change a thing on this package except settin the default volume for skyrocket to zero during this release cycle
<spayne> doko: this feature works fine on Debian and SUSE
<Kamion> mdz: I believe lamont did it a week or so back
<bddebian> Where is the "missing" stuff on people.u.c/~cjwatson   ??
<Kamion> ogra: not that I'm complaining about having less to do, but it must be nice to have a choice about whether to do an RC ;-)
<Kamion> bddebian: eh?
<jbailey> mdz: pong
<bddebian> Kamion: Doesn't he have a page that shows "missing" stuff. (I.E. NEW) ?
<Kamion> bddebian: dude, *I* am cjwatson
<mdz> ogra: it doesn't have a postinst and I see no mention of it being removed
<bddebian> Kamion: The reason that I ask is that I still don't see the libaqbanking 1.5.99... binary stuff yet?
<Kamion> and no, I do not have anything that monitors the state of the NEW queue. The closest I have to what you might be thinking of is http://people.ubuntu.com/~cjwatson/testing/, which is main-only
<ogra> Kamion, the current image is lacking fixes... i dont see that it should be a RC before these are in... since it will take time i think a RC before release doesnt make sense
<bddebian> Kamion: Oohhh *red face*
<mdz> ogra: don't waste time on it; it isn't a regression
<mdz> ogra: the package didn't have a postinst in hoary either
<ogra> mdz, i didnt say i removed a postinst... and except me nobody touched it... give me time to look at it
<ogra> mdz, exactly...
<Kamion> ogra: I hope you realise that you can only get a very, very limited class of fixes into the archive from now on
<ogra> Kamion, yes i'm discussing with mdz since yesterday for my most critical one...
<Kamion> you will have to cut your losses at some point; better do it at a point when the problems are well-understood
<bddebian> Kamion: Is the libaqbanking-libgwenhwfar-plugin still hung up in NEW ?
<Kamion> bddebian: YES
<bddebian> Oh :-(
<bddebian> Why the caps?  How would I know that?
<Kamion> NEW processing is not instant, nor will it be; I've been processing it since your last question about it a whole three minutes ago
<bddebian> Kamion: I thought you did it this morning, sorry.
<Kamion> sorry to be tetchy, but I mean, really
<ogra> Kamion, yes, but this one was a installation blocker it needed fixage
<Kamion> ogra: in universe
<Kamion> I am also busy dealing with the Kubuntu release
<mdz> Kamion: he's talking about edubuntu
<Kamion> ah
<Kamion> fair enough
<mdz> bddebian: coincidentally, I was just processing queue/new while you were nagging :-P
<ogra> Kamion, err you meant MOTU ?
<bddebian> I'm not trying to NAG.. Sheesh :-(
<ogra> heh
<ivoks> calm down guys... you are doing great stuff...
<bddebian> Is there any chance of getting someone appointed later on to handle Universe specific stuff so we don't have to bug you main guys?  Kind of a laison or something?
<Kamion> mdz: um ... you can't do universe NEWs like that
<Kamion> there is an obscure and undocumented process :-/
<mdz> Kamion: I thought the process was "just do it and then move it later"
<Kamion> oh, well, I guess you can
<mdz> that's what elmo recommended to me
<Kamion> there's a new_universe program in katie's path
<Kamion> you add the output to the overrides using natalie, and then move everything back into queue/unchecked/
<Kamion> then it goes straight into universe
<Kamion> bddebian: ultimately it'll all be in Launchpad; any processes we define now will change anyway ...
<Kamion> mdz: I had to ask elmo a couple of times how he did it before he told me that method; for some reason he seems to believe it's a bit of a hack ;-)
<bddebian> Kamion: I didn't mean immediately obviously, just thinking out loud.
<Kamion> bddebian: ok - release day is not the best time for all of us, really :-)
<ivoks> :)
<ivoks> as i said... calm down :)
<bddebian> Kamion: I know sorry.  I have goals too ya know.. ;-P
<Kamion> bddebian: I know, no problem. I did try to do a universe version of http://people.ubuntu.com/~cjwatson/testing/ a while back, since it's been on my to-do list for some time and I know it'd be helpful - but it took longer than the cron.daily cycle to generate
<Kamion> so I need to get it going on some other machine with a full mirror, probably rookery itself (i.e. people)
<Kamion> takes a shedload of memory though
<bddebian> I can imagine
<ogra> mdz, there is a mechanism in xscreensaver (thom added it i think) to prevent GL screensaver to be run in software rendering mode... i guess thats the prob with rss-glx...
<infinity> bddebian : No, you probably can't imagine, until you've seen britney in action.
<infinity> bddebian : It's twelve kinds of scary.
<bddebian> If I stay at this job maybe I'll throw up a mirror
<bddebian> infinity: Heh
<Kamion> britney used to be ulimited to 900MB of memory in Debian. It overflowed that on a regular basis ...
* infinity is pleased to have found only one chroot-breaker in the last mass give-back.
<infinity> (and a fix uploaded)
<slomo> infinity: you mean cabal? or something else?
<infinity> slomo : No, tipa.  Bad remove/purge conffile handling.
<mvo> mdz: is #17172 something that should be fixed for -final?
<Kamion> Riddell: Kubuntu release is syncing out to mirrors now; will be a while
<Kamion> Riddell: sorry for the delay
<jbailey> mdz@ubuntu.com  2005-10-06 19:53 UTC  Target Milestone  ---  Ubuntu 5.10
<jbailey> Is my clock, or the DCs confused?
<Riddell> Kamion: no problem, thanks for that
<Riddell> Kamion: are the DVDs there as well?
<tseng> jbailey: i thought bugzilla was in UK local time for some reason
<Kamion> Riddell: yeah
<Kamion> tseng: shouldn't be claiming UTC, then :)
<Riddell> Kamion: did you or jbailey test the AMD64 DVD?
<tseng> this is true.
<Kamion> Riddell: I didn't; I don't think jbailey did either
<jbailey> 'k,np.  I knew Matt was super-human, but this was a new one to me. ;)
<Kamion> but if the Ubuntu DVDs work (which they do) and the Kubuntu amd64/{install,live} CDs work (which they do), then I'm not too worried
<infinity> jbailey : bugzilla is in Europe/London, but in certain places claims to be UTC.  Known issue.
<jbailey> infinity: Luvly, thx.
<mdz> bugzilla calls Europe/London UTC for some reason
<lamont> mdz/Kamion: I manually reset the amd64 cloop a bit ago
<mdz> lamont: ok
<mdz> lamont: depending on how pressed we are for space, we may need to do it again
<lamont> but since we hadn't deployed sladen's zero-er earlier, I was unwilling to deploy it post-preview on amd654
<mdz> Kamion: have you done a build since all your changes?
<lamont> (ia64 has it turned on in the daily script, to give us testing)
<lamont> mdz: np.  it's a straightforward run of the python script... the long part is the diff of the entire fs afterwards, just to be pedantic....
<lamont> (when I reset it, it was copy, zero, mount both, diff, make sure we're happy, replace.)
<Kamion> mdz: not yet, no
<lamont> mdz/kamion: and btw, I'll be mostly offline from tomorrow morning until monday evening...
<lamont> wait.. this is thursday...  off and on tomorrow, gone sat-am thru mon late evening
<grayman> When you install something in synaptic you get that status bar with terminal. The questions is... can i use it in my own application in someway, because i noticed that gnome-app-install uses the same one too
<mvo> grayman: yes you can, please join #synaptic for details (I don't want to be too OT in this channel)
<grayman> i can? thanks
<lamont> mdz: actually, the only one I reset was ubuntu-live... still need to reset the others.
<lamont> mdz/kamion: since I know how much you love changes just before release....
<lamont> ia64 has been running sladen's zero-er for a couple weeks, with no ill effects... we could consider just turning it on...
<jbailey> Anyone able to install pieces in the chroot on concordia?
<fabbione> jbailey: i guess both elmo and Znarl can
<lamont> mdz: I'll reset all of the amd64 images today sometime, in any case.
<lamont> the advantage of deploying the zero-er is that the image then has no wastage, instead of 'just today's wastage'
<jbailey> fabbione: YEah, probably not the right timezone for them.
<jbailey> Ah well.  /me fires up the test build on a slow local machine.
<lamont> fabbione: and pretty much only them.
<fabbione> lamont: yeah
<mvo> mdz: sorry for pestering you, I wonder if #17172 is something that can/should be fixed for -final (one line fix)?
<zyga> mvo: one line fix that fixes an issue is a good fix
<mdz> mvo: that's fine
<mdz> mvo: remember that you already have 3 existing bugs with 5.10 milestone, though; don't forget about those
<mdz> jbailey: did I already ask you about #14456?  something to be concerned about for 5.10, or not?
<Kamion> ooh, need a preset query for me + 5.10 milestone
<mdz> Kamion: you only have 2 and you are quite aware of them already ;-)
<Kamion> yep, just checked
<jbailey> mdz: Adding the define would allow us to match the kernel change from the end of September.  Nothing is relying on it, though.
<jbailey> mdz: So path of least resistance is 'no', path of completeness is 'yes'.  I don't know inotify well enough to know if anyone would notice if it weren't there.
<mdz> jbailey: so the things that use inotify in breezy are  including their own copy of the header?
<mvo> mdz: thanks for reminding me :) I'm not sure if #8502 is a "must-fix" for 5.10 and I'm not sure if it is possible to produce a "simple and obvious" fix for this. what do you think?
<mdz> mvo: you are the one who set the milestone to 5.10 :-)
<mdz> mvo: if it isn't fixed upstream and the fix isn't obvious, let's defer it
<jbailey> mdz: The header is there.  There's one define that's missing because the feature wasn't in the kernel when I added the header.  Ben added the feature at the end of September, so most things either include their own header or use this one without the define.
<jbailey> mdz: It's not a standard feature in 2.6.12, it's one we added, so I don't think it's high-impact to not have it in.
<mvo> mdz: I set that months ago :) 
<tepsipakki> mdz: #17151, yes the swap is on LVM, sorry for not making that more clear
<mdz> jbailey: oh, the patch made it look as if l-k-h wasn't shipping the header at all
<bddebian> Hello sabdfl
<mdz> tepsipakki: please follow up to Bugzilla so that this information is recorded there
<sabdfl> hey bddebian
<fabbione> hey sabdfl 
<sabdfl> mdz: T-8mins, right?
<tepsipakki> mdz: sure, just can't do it from here ;)
<fabbione> tepsipakki: there is already a bug open for it
<jbailey> mdz: Right.  I added it partway, then marked it as upstream, since it wasn't part of 2.6.12.  Ben patched inotify after.
<tepsipakki> fabbione: oh?
<fabbione> it's a duplicate of another one...
<jbailey> mdz: It's literally adding the line: +#define IN_MASK_ADD0x20000000
<jbailey> mdz: To the header.
<ajmitch_> morning all
<jbailey> tepsipakki: What sort of problem are you facing?  I tested resume from lvm swap 2 days ago on my laptop with no problems.
<tepsipakki> jbailey: i tested it several times on monday
<mdz> sabdfl: er, I never heard back from you or scott
<mdz> sabdfl: or claire
<sabdfl> ok
<tepsipakki> jbailey: I'll test it tomorrow to make sure, and to get the message from boot
<jbailey> tepsipakki: First take a look at /etc/mkinitramfs/initramfs.conf.  Is the RESUME= line set?
<mdz> so I didn't announce a meeting
<sabdfl> i'm here, just :-)
<tepsipakki> jbailey: yes
<\sh> hmm..who is responsible for the wiki.ubuntu.com?
<mdz> jbailey: if that's the only change, then let's get it in
<Kamion> mdz: running daily-live builds now, so we'll see how the sizes look. I've re-enabled the cron jobs.
<mdz> Kamion: sounds good
<Kamion> can't believe we were shipping all those powerpc initrds; I should've checked /install/ earlier :)
* fabbione has the feeling that there isn't much bw left at the DC
<jbailey> tepsipakki: 'kay.  I will need you to add the word 'break' to your kernel command line.
<tepsipakki> jbailey: sounds cool ;)
<jbailey> tepsipakki: Then when you're inside the initramfs-tools, make sure that your RESUME= line is defined in /conf/initramfs.conf
<jbailey> tepsipakki: What's the path that's there?
<doko> mdz: please accept openoffice.org2-amd64_1.9.129-0.1ubuntu3-0ubuntu3, openoffice.org2-amd64_1.9.129-0.1ubuntu3-0ubuntu2 had too tight deps
<mdz> doko: it's already in the archive
<tepsipakki> jbailey: in /etc/mkinitramfs/initramfs.conf? /dev/mapper/poo-swap
<sabdfl> fabbione: why?
<jbailey> tepsipakki: 8-P
<jbailey> tepsipakki: 'kay, so when you're in the initramfs, that should trigger it fine.
<doko> mdz: thanks, checked some minutes before
<jbailey> tepsipakki: Do you have another machine that you can use to IRC from while you're looking at this?
<fabbione> sabdfl: never mind.. it's yet another ISP in the middle falling apart
<sabdfl> ok
<tepsipakki> jbailey: the "break" makes it to boot interactively?
<fabbione> never had so many problems recently
<jbailey> tepsipakki: Right.  That tells it to give you a shell inside the initramfs
<\sh> fabbione: you don't have problems with level3 and cogent? 
<tepsipakki> jbailey: well, maybe my home installation uses lvm too, don't remember
<fabbione> \sh: no.
<\sh> but my company has *gnarf* we can't reach parts of romania anymore :(
<jbailey> tepsipakki: Well.  If you can remember, set the RESUME variable exactly as you see it in that file.  Then look in scripts/local-premount
<mdz> has anyone checked if the torrent tracker is working for RC?
<mdz> the status page is giving its usual 'server error'
<jbailey> tepsipakki: There's a script in there called 'suspend'
<jbailey> tepsipakki: Follow the commands in there by hand, and let me know which one isn't behaving right.
<jbailey> tepsipakki: The echo ${major}:${minor} >/sys/power/resume
<jbailey> tepsipakki: command shouldn't return.
<tepsipakki> jbailey: ok, I'll write these down ;)
* lamont works on tasks for the wifely one
<bddebian> Heh
<mdz> mvo: what can we do about 16678 for 5.10, if anything?
<mvo> mdz: I have no idea yet, the strange thing is that it doesn't happen for "de and fr", I was only able to reproduce it for it_IT
<mdz> mvo: curious
<mvo> mdz: yes
<mdz> mvo: so it is supposed to work?
<seb128> gdm doesn't detect new locale without beeing restarted
<mvo> mdz: seb128 thinks that gdm should be restarted in any case if new locales are generated
<seb128> restart = /etc/init.d/gdm restart
<fabbione> is there anything that actually detects locales changes when in "daemon" mode?
<seb128> mvo: that's my experience with it from before hoary
<fabbione> since the daemon inherits the env from the moment in which it's executed
<fabbione> seb128: imho NOTABUG
<mvo> seb128: curiously it did work for fr and de (see pitts comment too)
<jbailey> mvo: Doesn't restarting gdm cause the session to restart?
<pitti> fabbione: it's not about the env
<fabbione> pitti: it's a dameon..
<pitti> fabbione: it's about re-reading "locale -a" when the current session ends
<seb128> fabbione: what I said
<jbailey> Otherwise it's easy to add to the list.
<seb128> jbailey: yep it does
<fabbione> pitti: locale -a | wc -l
<fabbione> 17
<fabbione> pitti: which one should pick than?
<pitti> fabbione: all
<seb128> fabbione: the issue is
<seb128> - run gdm
<jbailey> mvo, seb128: Then restarting automatically would be a fairly large mistake, I think.
<pitti> fabbione: the problem is not that gdm itself has the wrong locale
<seb128> generate a new locale
<mvo> jbailey: yes, we can't do that
<seb128> pick it from the language menu on login screen
<pitti> fabbione: but that it does not offer new locales for the next session
<seb128> you get a message saying it's a known language
<fabbione> i am with seb128 on this one
<pitti> somewhere in the gdm code there must be a function that reads available locales
<fabbione> i might temporary add locales for other reasons
<fabbione> and i don't want them available on gdm
<mvo> the strange thing is that gdm offer the it locale but then complains on login
<pitti> fabbione: if there is a locale *after* the session ended, it shuold be available for the next one
<mvo> s/it/"it_IT"/
<pitti> right
<fabbione> pitti:not necessarely
<pitti> fabbione: gdm shuold either not offer the new locale at all, or it should work for the next session
<pitti> fabbione: so either way you look at it, it's a bug
<seb128> pitti: we have it since warty
<fabbione> pitti: it's a chicken egg
<fabbione> pitti: i would rather leave it as it is
<pitti> seb128: sure, I'm not arguing that we must/can fix it for breezy
<fabbione> well known behaviours
<fabbione> -s
<pitti> I'm just confirming that this is broken
<seb128> yeah, that's known to be since before hoary :)
<seb128> but nobody cared enough to fix it before
<seb128> so it can wait after 5.10 now
<pitti> so, some locales just have bad luck :-)
<fabbione> pitti: who cares about it_IT anyway
<fabbione> ;)
<mvo> heh :)
<sistpoty> is (rescheduled) TB-meeting now?
<pitti> fabbione: they should make good spaghettis, not good locales :-)
<mvo> and great pizza
<mvo> *yum*
<fabbione> pitti: that's why i cook and my desktop is in pure english :)
<pitti> fabbione: I like your attitude
<diamond> is there a known hindi display glitch in the installer? searching bugzilla for 'hindi' shows up nothing. this is a (very bad) photo of the issue: http://diamond.nonado.net/misc/pics/hindi.jpg
<diamond> this is from the rc btw
<pitti> fabbione: I have a German desktop and don't cook every day
<fabbione> pitti: heheh
<pitti> diamond: yes, known bug
<diamond> pitti: grand, thanks
<fabbione> i don't cook everyday either
<poningru> did someone say hindi?
<Simira> hi fabbione, how are you?
<fabbione> hey Simira !
<fabbione> Simira: i am fine thanks and you?
<poningru> oh
<Simira> fabbione: harassing Tollef to get the kitchen done. Have to get things in order for the party on saturday. Moving-in-party
<tepsipakki> jbailey: just crossed my mind: would it suffice if I opened up the initrd-img and see what's inside?
<fabbione> Simira: hehehe
<seb128> mdz: can we drop the gdm Depends on ubuntu-artwork and "desktop" it instead?
<jbailey> tepsipakki: that would let you make sure the conffile was updated, but I generally assume it is.
<jbailey> tepsipakki: The problem is likely elsewhere.
<tepsipakki> jbailey: ok
<jbailey> tepsipakki: I include that step for completeness because if it's *not*, we could spend hours troubleshooting a very simply problem. ;)
<tepsipakki> jbailey: it's my laptop, but it is online so I can easily take a look
<mdz> seb128: I would prefer not to do any seed changes before final.  what bugs would it fix?
<mdz> s/seed/desktop or minimal or standard seed/
<sabdfl> does anything require the artwork in minimal? usplash?
<seb128> mdz: people complaining because they have forced to use the panel logo branding
<seb128> mdz: would a panel patch with a gconf key for that been accepted?
<jdong> hey, I'm trying to make flashplayer/msttcorefonts style fetcher packages for w32codecs and libdvdcss
<jdong> any pointers? ;)
<jdong> decided breezy-extras needs to be a bit more legal
<mdz> seb128: for kubuntu and edubuntu, or someone else?
<mdz> well, not kubuntu obviously
<seb128> mdz: for anybody who wants to change the panel logo
<mdz> seb128: people who want to run ubuntu but with the gnome foot?
<seb128> mdz: let's say GNOME liveCD
<mdz> I see
<seb128> by example
<infinity> jdong : There's no way to make that legal.
<seb128> I don't really get why we force the artwork installation
<infinity> jdong : The difference is that flash and msttcorefonts are freely available, we're just not allowed to distribute them.
<mdz> I thought we added that dep intentionally to solve a problem
<seb128> mdz: the workaround are easy, we can keep that the current way for 5.10 if you prefer
<jdong> infinity: no; but it shifts the legality from me to the users :)
<jdong> infinity: Gentoo's been doing this for ages, and nobody's gone after them
<infinity> jdong : w32codecs, on the other hand, is not freely available at all.  The only legal package you could do is one that copies the files from the user's Windows partition.
<seb128> mdz: gdm default theme is ubuntu one, I though it was due to that
<mdz> seb128: sounds right
<mdz> seb128: I really prefer not to change the dep at this late stage
<mdz> seb128: what are the workarounds currently? dpkg-divert?
<Riddell> Kamion: there's no torrents for the kubuntu install CDs
<infinity> jdong : For w32codecs, where would you fetch it FROM?.. In the end, someone's still distributing it illegally, so you may as well just point users at that remote deb, if that's what they really want to do.
<fabbione> hmmm
<mdz> there is no gconf key etc. to set the panel logo currently?
<\sh> jdong: gentoo pulls in the sources from somewhere...it's source...not distributed by gentoo 
<jdong> infinity, \
<fabbione> what did pull libaqbanking into main without the source??
<jdong> infinity, \sh: it's from mplayer.hu... the authoritative source of w32codecs :)
<seb128> mdz: install a variant of the icon for your the theme you use, or divert it
<seb128> s/your//
<bddebian> fabbione: How did it go to main??
<\sh> jdong: which means, it doesn't distribute the source package
<fabbione> mdz: sorry that was for you
<jdong> \sh: they're binaries....
<\sh> jdong: sure..but you know what I mean
<\sh> jdong: the source of distribution is not gentoo :)
<jdong> \sh: yeah, but how's that different from what I'm trying to accomplish?
<mdz> fabbione: don't panic; new packages go into main by default and then get moved
<fabbione> bddebian: how did it go to main without source
<infinity> \sh : Yes, that's what he's driving at anyway, with a "fetcher package"... My point is that, no matter where you DL w32codecs from, it's still illegal, so why did you bother to add indirection?
<fabbione> mdz: ah ok. wasn't the other way around before?
<bddebian> fabbione: It should be Universe??
<bddebian> Ohh
<jdong> infinity: so the Backports team is free of legal blame
<fabbione> bddebian: it's a completely different problem.. i am asking about the source.. 
<seb128> mdz: what do you think about patch from http://bugzilla.ubuntu.com/show_bug.cgi?id=17049 ? is that ok to upload ?
<mdz> fabbione: did it build?
<\sh> infinity: that's the idea of gentoo...they're pointing you to anywhere else...what gentoo is, is only python/bash scripts..nothing else..the rest comes from unknown places...they don't care
<mdz> fabbione: I was waiting for the binaries so I could move it
<infinity> jdong : Meh.  Fair enough.  If you need/want help with it, post-release, ping/mail me.
<fabbione> mdz: it's on my local mirror.. that's why i noticed
<jdong> infinity: sure... I'll see if I can modify the msttforeconts source to work in the meantime
<jdong> (err, wow I'm dyslexic today)
<mdz> seb128: hmm, I don't like it too much; I would rather disable the button honestly
<bddebian> fabbione / mdz: You two are confusing me.  What of libaqbanking is in main?  apt-cache madison shows both in Universe here??
<infinity> jdong : Make sure the files get installed to the same paths as they are in the current .deb
<jdong> yep
<mdz> bddebian: all of its binary packages
<seb128> mdz: what's wrong about it? (not that I care either way)
<mdz> bddebian: and I've just moved tem
<bddebian> mdz: OK, gotcha, thx
<mdz> seb128: not wrong, just intrusive
<mdz> seb128: it's also ok with me to just leave it as-is for 5.10
<mdz> hehe, we are in that time of the release when bug reporters start to lobby for their pet bugs to be fixed
<Seveas> :)
<bddebian> Heh
<Seveas> it was not my pet bug (i created the patch) but I just didn't like the security issue disks-admin gives
<Seveas> disbling the button would work too, this was just as easy though :)
<seb128> mdz: right :)
<seb128> Seveas: what security issue?
<Seveas> seb128, browsing things as root
<Seveas> or running gnome-cd/totem as root
<seb128> Seveas: that as secure as running g-s-t tools or gdmsetup or synaptic with sudo imho
<Seveas> agreed for totem/gnome-cd, but not for nautilus
<fabbione> Kamion, mdz: one of your last ubuntu-meta uploads did kill ubuntu-desktop on sparc..
<fabbione> is there any chance to get it fixed?
<tepsipakki> jbailey: the initrd-img is fine
<Zomb> mdz: again, please take my appologies for the bad sarcasm... and Knopper says he did not receive any fix.
<fabbione> mdz:  powermanagement-interface and openoffice.org2* should be removed.. (they were not there, but apparently a refresh did add them back)
<jbailey> tepsipakki: 'kay.  So you'll need to step through it and figure out why it's not poking the major:minor in.
<jbailey> tepsipakki: Can you look to see what's in /sys/power/resume now?
<jbailey> tepsipakki: (Just cat it, it's a plain file)
<tepsipakki> jbailey: but the machine is not at my hands currently, so I can check those things tomorrow
<tepsipakki> jbailey: or is there something I _can_ do it via ssh?
<jbailey> tepsipakki: cat /sys/power/resume can be done now. =)
<jbailey> tepsipakki: Let's see if it's actually being set in the first place.
<tepsipakki> jbailey: 0:0
<jbailey> tepsipakki: Yup, not set. =)
<jbailey> tepsipakki: So I definetly need you to walk through that fiel and figure out why it's not being run.
<mdz> Zomb: thank you.  if there is an upstream mailing list for cloop, please tell me and i will send patches there instead so that you receive them also
<jbailey> tepsipakki: Putting your initramfs somewhere I can download it would help me look quickly for obvious things, too.
<Zomb> mdz: Knopper has left LinuxTag and is constructing something on alioth right now
<tepsipakki> jbailey: the image you mean?
* ogra hugs mdz 
<jbailey> tepsipakki: S=)
<ogra> thanks :)
<doko> fabbione: could you start on OOo2 test build without java, please?
<fabbione> doko: on what arch?
<doko> sparc
<fabbione> doko: yes in theory
<doko> no, I mean in practice
<tepsipakki> jbailey: http://users.tkk.fi/~tjaalton/tmp/
<fabbione> doko: yes.. in a few minutes it will be practise
<doko> thanks
<fabbione> doko: is it just a random test to see if it builds, or is it know to fix the FTBFS?
* [-Jarod-]  http://pics.soohrt.org/fun/unix-admin/microsoft-cat5-linux-bsd.jpg yeah !
* jdong cautiously proceeds with first test deb....
<jdong> SUCCESS :)
<jdong> lol
* jdong reflects on what a crappy hackjob he's made... then uploads to breezy-extras :)
<jdong> I just put the installation and removal code in postinst/postrm... is that a no-no? ;)
<fabbione> doko: ??
<xTina> Is the daily installer from yesterday (Oct. 5) the same as the RC? I tested the automated installs in our labs just last night with that one, but I definitely would test the RC again if it isn't the same.
<doko> fabbione: AFAIK, the build failure is in java related code, therefore the retry without java
<fabbione> doko: ok
<doko> fabbione: maybe keep the build tree around
<fabbione> doko: yes.. i am doing it in a dedicate chroot
* jordi grumbles at people translating wiki.ubuntu.org/DesktopTranslations not knowing how to do it in alphabetical order.
<jbailey> jordi: File a bug against the translator for bad LC_COLLATE implementation ;)
<sistpoty> mdz: is the rescheduled TB-Meeting today?
<jordi> jbailey: maybe it was a BUG IN HIS LOCALE DATA!
<hunger> Hehe... The RC announcements are all over the web, but I can't spot it on www.ubuntu.com:-)
<jbailey> jordi: See?  And if it was all in Rosetta...
<jordi> haha
<hunger> Good work, guys. Breezy is a really great distri!
<jordi> "you've got mud on your face...", Queen music for our wrestling,
<[-Jarod-] > i agree :)
<mdz> sistpoty: no, I didn't hear back from anyone in time
<sistpoty> mdz: ok, thanks
<jbailey> jordi: It's as good as any I can think of. =)
<jcohen85> jbailey, well, the last update has slowed my startup by 10 seconds. There's a delay when setting up the network that i never had before.
<jbailey> jcohen85: I thought we agreed that you were never updating again? ;)
<jcohen85> i didn't
<jcohen85> from the previous update
<fabbione> doko: ENABLE_JAVA is already off on sparc
<fabbione> i can try to rebuild tho
<fabbione> i didn't test it for a while
<doko> if you do have the cpu time ...
<fabbione> doko: i will make space..
<fabbione> not that i have much given release is close
<zyga_amd64> hi
<Kamion> fabbione: ubuntu-desktop does not depend on either powermanagement-interface or oo.o2 on sparc
<fabbione> Kamion: yes, we just verified that, but i can't understand why they get pulled in..
<fabbione> or better.. by waht
<fabbione> what
<zyga_amd64> I've just installed RC for amd64
<fabbione> in a chroot is ok.. not on install
<ploum> jdub, can I annoy you with planet ?  (I just want a 1.0 tarball)
<fabbione> there must be a difference that's triggering the problem
<zyga_amd64> I don't know if that is a known issue but users-admin pretty much crashes all the time
<Kamion> (as per elsewhere, it's due to lack of architecture-specific Task: headers)
<Kamion> zyga_amd64: I thought mvo fixed that today; have you tried upgrading to current?)
<mvo> zyga_amd64: do you run 1.4.0-0ubuntu10?
<doko> mdz: I think I found all bugs, for building and using OOo2 help. but I need another OOo2 upload (followed by an OOo2-amd64 upload)
<mdz> doko: send me a diff, please
<mdz> doko: this would enable help on all architectures?
<doko> mdz: yes
<g14> Will gnome integrate any of the patches for improving gnome startup time?
<tseng> in 2.14 they will surely have a look
<g14> tseng: One of the patches got rejected, because it breaks backwards compatibility for people who have gnome < 2.6 installed side by side with newer gnome
<g14> But that one improves startup time for me personally about 6 seconds
<tseng> sorry, you'll have to take that up with the gnome developer in question
<Kamion> I think you'd be better off asking GNOME upstream directly about what they plan to do
<Kamion> we're just another distributor, albeit one with fairly close connections to GNOME
<g14> It doesnt make sense for gnome to distribute it if it breaks backwards compat
<g14> But ubuntu doesnt have a problem with backwards compat
<g14> So why not?
<g14> Im not trying to flame, breezy is amazing
<Kamion> I don't understand that claim, since people NFS-mount home directories between different distributions quite frequently
<g14>  gconf-merge-tree /usr/local/gnome/etc/gconf/gconf.xml.defaults
<Kamion> in any case, these patches only seem to have been produced well after the stage in our release process when we could have considered integrating it for breezy
<HiddenWolf> Oh My. JaneW, did you just about double the size of the wiki, or what? ;)
<g14> gnome < 2.6 doesn't support merged configuration files
<g14> No, for dapper
<g14> Not breezy
<fabbione> g14: wait to ask after breezy is released :)
<tseng> file a bug in a few weeks :)
<Kamion> we haven't started dapper development yet; we are concentrating very hard on getting breezy out the door right now.
<fabbione> we are all a bit overloaded
<g14> understood
<fabbione> night everybody
<HiddenWolf> can anyone braindump on those spec-pages?
<HiddenWolf> wiki
#ubuntu-devel 2005-10-12
<JaneW> HiddenWolf: possibly :)
<JaneW> HiddenWolf: and I just got started.... *efg*
<JaneW> HiddenWolf: yes, if you are adding useful info and insights ;)
<HiddenWolf> JaneW, no, i'll troll, what do you think? :P
<Nafallo> lol
<JaneW> HiddenWolf: nothing surprises me anymore *hide*
<zyga_amd64> mvo, checking
* HiddenWolf tries to look innocent
<zyga_amd64> mvo, yes
<zyga_amd64> mvo, it still crashes
<zyga_amd64> reboot, new kernel - brb
<mdz> seb128: librsvg OK for upload
<seb128> mdz: thanks
<dand> mdz: thanks for looking at bug 8468 . would it be too late to include a patch for that in xkeyboard-config? (I know I should have pushed for this eariler)
<mvo> zyga: hm, strange, works here (on my amd64)
<mdz> seb128: what is your feeling on updating evolution-exchange to 2.4.1 as proposed in 16967?
<mdz> dand: if you could attach a complete patch for breezy to the bug, we can consider it
<Nafallo> mvo, zyga: wfm
<dand> mdz: great! I'm working on it
<HWolf> JaneW, get half of that implemented in dapper, and MS goes bankrupt. \o/
<mdz> seb128: I'm not sure how broken it is currently
<robertj> HWolf: half of what ;)
<robertj> (for the latecomer)
<seb128> mdz: that's a part of GNOME 2.12.1, didn't get uploaded because I thought jbailey was going to do it. Anyway it seems to be quite broken for every connector users atm and has no impact on the non-exchange users ... since it has been following GNOME freeze, patch review, etc, I would be fine with an update
<jbailey> mdz: It seems to get frequent complains.  I tracked down the patch that should fix it, and it appears to be in evo-exchange 2.4.1.  The 2.4.1 update also includes fixes for two memory leaks.
<mdz> jbailey,seb128: if you guys feel that it poses no significant risk to plain exchange users, go ahead, but do it soon
<HWolf> robertj, JaneW is spamming the wiki with suggestions for DapperGoals / things to talk about on the next conference. 
<seb128> mdz: I'll do it right now, thanks
<mdz> jbailey: is 2.4.1 a conservative bugfix-only release?
<mdz> er, s/plain exchange/plain evolution/
<JaneW> HWolf: if you want spam subscribe to those pages :P
<seb128> mdz: doesn't impact on non-exchange users yeah
<robertj> ohh
<jbailey> mdz: All of the patches but two have bugzilla entries that they fix.  Of the two, one is a memleak fix, the other is the fix that we need.
<robertj> HWolf: hehe, go for it girl
<seb128> mdz: and the package is borked for month :/ Evolution was built without the corresponding lib, but since we ignored bug for some months ...
<HWolf> robertj, call me a girl again and I'll show you. :P
<robertj> (I meant Jane ;)
* HWolf grins
<robertj> DapperGoals deems not exist yet per-say
<jbailey> mdz: The original set of bugs are the ones we talked about for me getting the exchange server.
<mdz> dholbach: please send me a debdiff for gparted if you still want it in
<HWolf> robertj, go figure, we're still waiting on breezy. 
<the--dud> is there no anon cvs for breezy?
<robertj> HWolf: I'm excited. This is the first time I will have made it all the way to a release without running unstable of some sort
<the--dud> thought I'd do some bug hacking as I have some spare time...
<jbailey> the--dud: What are you looking for?
<robertj> JaneW: where are you spamming at?
<the--dud> just a current development source tree generally
<jbailey> the--dud: It's not one big source tree.  With 1000-odd packages in made, that would be excessive.
<the--dud> so that any bug hacking I'd be doing isnt done by someone else while I actually work with it
<HWolf> robertj, take a look at wiki.u.c/RecentChanges
<the--dud> jbailey, was thinking the main here ;)
<robertj> ahh, should have thought of that
<jbailey> the--dud: main is 1000-odd package.  Universe is an order of magnitude larger than that.
<the--dud> sorry, should have stated it more clearly. sources for breezy install cd
<the--dud> only current development if such a thing is available
<ogra> universe > 16000 packages
<jbailey> the--dud: Mostly we pick bugs in bugzilla, assign them to ourselves and chase them.  If you're looking for things that will be accepted for Breezy, mdz posted a list to ubuntu-devel recently.
<jbailey> the--dud: Other patches are not likely to be accepted now.
<the--dud> yeah, the mail post with subject "Release status: 5.10RC complete, approaching 5.10 final"
<the--dud> which gives a link to the bugzilla page right
<jbailey> That would be the one. =)
<zyga_amd64> re
<zyga_amd64> okay :-)
<zyga_amd64> fglrx fails to load
<the--dud> thats what got me coming here in the first place today hehe
<zyga_amd64> mvo, I'm running latest and greates - going to check the problem again
<mvo> zyga_amd64: make sure you run ubuntu10 of gnome-system-tools
<zyga_amd64> I am
<zyga_amd64> mvo, was the problem related to sudo?
* zyga_amd64 successfuly created another user
<zyga_amd64> mvo, okay it doesn't crash but there is a bug for sure
<zyga_amd64> I added a user, no funky characters in password and login
<zyga_amd64> then I edited the user and entered non ascii description
<zyga_amd64> I clicked okay and closed the application
<zyga_amd64> the changes were not applied
<zyga_amd64> is there some low-level issue with non-asci stuff in /etc/passwd?
<mvo> zyga_amd64: the crash in users-admins is a problem in the internal md5 implementation of users-admin, it uses crypt(3) now 
<zyga_amd64> mvo, I see
<mvo> zyga_amd64: no idea, I recently added stuff was only a fix for the amd64 crash
<zyga_amd64> mvo, I'm sure I was running latest g-s-t when it crashed before reboot
<zyga_amd64> mvo, anyway the bug 'let's put non-ascii stuff into user description and see it dissapear' is still there
<mvo> zyga_amd64: is it already reported?
<zyga_amd64> mvo, checking
<zyga_amd64> 70 bugs on g-s-t ;)
<mvo> zyga_amd64: yeah :/
* zyga_amd64 notices that boot admin is gone
<zyga_amd64> wtf?
<zyga_amd64> is this amd64 specific or did we just dump a really usefull tool?
<ajmitch> zyga_amd64: it had a habit of screwing up grub configs, iirc
<zyga_amd64> ajmitch, I see
<zyga_amd64> no more GUI tool that enables dual booting with windows :/
<ajmitch> I heard that some people lost their update-grub-inserted entries because of it 
<zyga_amd64> hmm
<zyga_amd64> actually windows was detected..
<zyga_amd64> mvo, it's already filed: http://bugzilla.ubuntu.com/show_bug.cgi?id=12532
* mvo goes to bed
<seb128> 'night mvo
<mvo> zyga_amd64: ok, thanks
<mvo> seb128: thanks, n8
<doko> mdz: OOo2 patch sent
<zyga_> anyone with radeon+amd64 around?
<zyga_> (II) LoadModule: "fglrx"
<zyga_> (II) Loading /usr/X11R6/lib/modules/drivers/fglrx_drv.o
<zyga_> Duplicate symbol rol_long in /usr/X11R6/lib/modules/drivers/fglrx_drv.o
<zyga_> Also defined in /usr/X11R6/lib/modules/linux/libint10.a
<jmg> guys, latest update breaks my grub and installs lilo
<jmg> and i cant reinstall grub
<jmg> cant boot
<jmg> i beleive its because im using lvm that lilo wont boot
<Riddell> Kamion: I'm still getting preview on this page http://releases.ubuntu.com/kubuntu/5.10/  do I just need to be more patient?
<Surak> Hello, I just like to report some progress on grub-install running forever on hard drives < 120gb. I noticed that if you create a small /boot partition at the beginning of the disk, it will work, inspite of the fact it still takes several minutes.
<Surak> If you create a big / with everything inside it, grub-install will take forever. (I left it for two days here and nothing happened)
<the--dud> heh, installing breezy rc1 as a vmware virtual machine now
<Surak> I noticed this on every hard drive/mobo combination I have access to, and the minimum hard drive I noticed this is a 120gb one. 80gb ones works just fine. 
<the--dud> breeze sure has a lot of packages it needs to install!
<dholbach> could it be that  popcon.ubuntu.com  data is stale?
<crimsun> more than likely
<dholbach> *cry*
<Surak> http://bugzilla.ubuntu.com/show_bug.cgi?id=15594 Is something I'm referring to. 
<ogra> dholbach, there are not many people using it
<dholbach> ogra: apart from that it lists gcc-4.0 as a universe package
<ogra> dholbach, and thim was theonly one who cared for it afaik
<ogra> thom
<the--dud> hehe, amazing how much stuff breeze comes default with now... beanshell, wtf?
<ogra> dholbach, a good project to take over ;)
<dholbach> ogra: ...
<dholbach> :)
<ogra> :)
<sabdfl> ANNOUNCING: Breezy release party, in London!
<sabdfl> hmm... we should put up a page on the wiki and let people coordinate release parties
* ogra looks up train prices
<ogra> sabdfl, there is a wiki page for it anywhere
<Nafallo> sabdfl: https://wiki.ubuntu.com/BreezyReleaseParty :-)
<dholbach> i dont get why they didnt use https://wiki.ubuntu.com/ReleaseParty
<dholbach> but ... :)
<dholbach> "it's a wiki"
<ogra> hehe
<Nafallo> dholbach: we should rename that one to HoaryReleaseParty :-P
<the--dud> I wonder if the ubuntu wiki is one of the very few wikis which requires https even for anonymous access
<dholbach> Nafallo: and the other one to ReleaseParty? :)
<Surak> is there a ubuntu for sparc? http://popcon.ubuntu.com/
<sabdfl> bugger
<sabdfl> i just created https://wiki.ubuntu.com/BreezyReleaseParties
<sabdfl> doh
<dholbach> haha :)
<ogra> Surak, yes
<ogra> Surak, talk to fabbione tomorrow... images should be at ports.ubuntu.com
<tseng> it has 2 users :)
<Surak> :-)
<whiprush> i am doing an announcement for the release parties on the fridge in a bit.
<Surak> Would like to know what 'unknow' system is :-D
<dholbach> ooohhh baby... the FRIDGE :)
* ogra still whishes for a mips port
<Surak> I thought it was a watch :-)
<Nafallo> ogra: go create one then :-)
<ogra> Nafallo, my good ole indigo cant even run a console with its extreme graphics card
<ogra> (indigo2)
<tseng> dude two of the fridge random bits are inspired by me
<tseng> awesomeness
<Nafallo> hihi
<Surak> hehe
<the--dud> erm, how can I bypass X from initializing in ubuntu breezy?
<the--dud> it obviously failed to set the video driver as vmware, so it locks up completely
<Diablo-D3> hey all
<Surak> Just noticed some sort of hippie bug: Default colors of GRUB are very sad - white letters on black. It gives negative feelings.
<Diablo-D3> any word on when ardour-gtk will be fixed?
<Surak> this is #14687
<ogra> Diablo-D3, did you file a bug ? 
<tseng> hm we are making alot of noise guys, this is bad.
<Diablo-D3> ogra: um, it depends on packages that arent in universe
<Diablo-D3> ogra: the package maint should already know about that one since he caused it ;)
<ogra> Diablo-D3, again, did you file a bug ? 
<ogra> we have no package maintainers...
<Diablo-D3> uh, why would I?
<Diablo-D3> er, crap, universe
<ogra> we only work through the bugs....
<Diablo-D3> damnit >_<
<whiprush> hey is "ubuntero" the preferred term?
* Diablo-D3 files a bug.
<ogra> Diablo-D3, thanks a lot :)
<Diablo-D3> ogra: I'm used to packages having maintainers.
<Surak> whiprush : ubuntero? 
* Diablo-D3 used debian for entirely too long.
<Nafallo> whiprush: not according to launchpad :-)
<ogra> Diablo-D3, we're only about 30 MOTUs caring for 16000 packages ;)
<whiprush> I think it was Ubuntite before.
<sabdfl> Ubuntero sounds cooler. more fridge. less... ite
<ogra> Diablo-D3, feel frr to join us in #ubuntu-motu :)
<mdz> doko: still here?
<ogra> 'free
<whiprush> ubuntero it is then
<Diablo-D3> how about "God"
<Diablo-D3> hrm, wait, that'd only describe me
* Diablo-D3 flexes muscles.
<Nafallo> Diablo-D3: ehm, are you bddebian? :-P
<grayman> hah
<crimsun> sorry, but only sabdfl can claim that in here.
<ogra> Diablo-D3, sounds like we could need your power to rule the universe ;)
<Diablo-D3> ogra: ruling the universe is so boring
<Diablo-D3> I have poeple do that for me
<doko> mdz: half awake, no more uploads today ;)
* Diablo-D3 flexes muscles more
<ogra> Diablo-D3, boooring :)
<mdz> doko: ok, sent mail
<ogra> Diablo-D3, do something with these muscles
<Diablo-D3> if there were women in here, they'd be all over me.
<ogra> just flexing isnt impressing
<Surak> Diablo-D3: use your muscled fingers to open bugs ;-)
<grayman> Diablo-D3, yeah. do something cool
<ogra> even they are more impressed by bugfixers :)
<tseng> dudes
<tseng> flex all you want in #-motu :P
<ogra> *g*
<Diablo-D3> tseng: happy?
<tseng> thanks.
<grayman> lol
<Diablo-D3> oh wow.
<Diablo-D3> https://launchpad.net/distros/ubuntu/+bug/1
<Diablo-D3> best. bug. ever.
<grayman> yeah
<grayman> nice one
<grayman> they should provide a patch that removes windows boot from grub
<doko> mdz: upgrade issues: no, we require the same base version, and we add one file (shlib), which was not in any upload with the base version
<Diablo-D3> yeah, but then how would I test new viruses?
<grayman> :)
<grayman> good point
<tseng> ok guys to be a little more clear, its release crunch time, these guys need to work in here w/o alot of excess noise
<Diablo-D3> breezy is rsn now, isnt it?
<ogra> Diablo-D3, yes, so lets keep the channel on topic... noise cn go to #ubuntu-motu
<doko> binaries: I have some from the -help build, making some overnight built from the original ooo2 source
<Surak>  #ubuntu-noise
<mdz> doko: ok, please do a hoary upgrade test and then upload when ready
<sabdfl> night all
* lamont__ wonders if he's supposed to have 2 screensaver property menu items
<lamont__> admittedly not current breezy yet
<ogra> lamont__, remove gnome-screensaver
<ogra> we dropped it again
<crimsun> it should be in universe [soon] , actually
<crimsun> oh, it is.
<lamont__> ogra: ok... does that happen automatically on a hoary upgrade
<lamont__> ?>
<ogra> #it wont be there on a hoary upgrade... it was only there for 5 days during breezy
<ogra> similar to polypaudio...
<lamont__> ah, ok
<bob2> heh
* lamont__ looks for some candy to lob at bob2
<ogra> mentos !
<ajmitch> ogra: how could you? :)
<ogra> :)
<bddebian> The Freshmaker ;-P
<ogra> bddebian, nah, the fruity ones were way cooler
<bddebian> :-)
* ogra wonders what kind of candy will rule UBZ
<ajmitch> hopefully something with plenty of sugar
<bob2> hope it's better than the boiled things from spain
<bob2> they become a currency so people would have something to eat between 8am breakfast and 10pm dinner
* ogra still has some frm the spain ones
* ajmitch will have to figure out something for meals for UBZ
<ogra> ajmitch, at least it wont be pumpkin ...
<Riddell> hmm, none of the mirrors have picked up the kubuntu RC
<ajmitch> ogra: yeah, I'm not sure if I get to eat with the real conference attendees (not just the groupies) :)
<bob2> eat poutine
<bob2> over and over
<ajmitch> heh
<ogra> ajmitch, sure you will... 
<ajmitch> ogra: then I'd better sort that out soon..
<Riddell> ajmitch: Poutine
<Riddell> ah, bob2 beat me
<bob2> lifeless: bring me back some poutine
<lifeless> bob2: what branch did you want registered?
<ogra> could i ask any australian for a glass vegemite to bring to UBZ ? my GF dies for it ...
<ogra> a small one would be enough
<bob2> haha
<womble> ogra: Run away while you still can.  Anyone who likes that smegma of satan is not to be trusted.
<ajmitch> ogra: want me to try & bring some vegemite?
* ajmitch doesn't qualify as an australian..
<ogra> any vegemite will do... 
<ajmitch> sure :)
<lifeless> ogra: put her out of her misery
<ogra> even NZ one
<lifeless> ogra: thats a terrible substance she is abusing :)
<bob2> womble: traitor
<lifeless> bob2: weakling
<HrdwrBob> I love vegemite
<bob2> lifeless: hm, one sec
<bob2> lifeless: I forget, does pqm register branches or archives?
<lifeless> HrdwrBob: I'm sorry ;)
<lifeless> bob2: archives
<ogra> lifeless, she's known for consuming terrible stuff.... 
<womble> bob2: Hey, I haven't told him the secret of how to avoid getting mauled by the dropbears
<lifeless> womble: its easy to avoid getting mauled...
<ogra> womble, wasnt that a hat with forks in it ? 
<lifeless> womble: avoiding the squash is the problem
<womble> ogra: Forks?!? Are you crazy?!?  That'll attract them like nothing else.
<ogra> lol
<lifeless> not to mention poking holes in your head
<lifeless> bob2: so email me, gpg signed, the details please
<bob2> lifeless: will do
<dholbach> good night guys
<dholbach> mdz: i will look at gparted tomorrow
<dholbach> (later)
<dholbach> *wave*
<sadam> bmonty: you around?
<Riddell> mdz: kubuntu announcement in queue
<mdz> Riddell: awaiting moderation?
<Riddell> mdz: yes
<Riddell> none of the mirrors seem to have picked it up though
<mdz> let me know when they have, and I'll let it through
<whiprush> Riddell: mind cc'ing me? I can fridge it right now.
<Riddell> whiprush: http://www.kubuntu.org/announcements/breezy-release-candidate.php
<whiprush> ta
<whiprush> Riddell: I need to mail you soon, we need a kubuntu guy for the fridge.
<whiprush> Riddell: I think you should convince aseigo. :P
<Riddell> because he doesn't have enough to do :)
<mdz> whiprush: hold off on the fridge until it's actually published on the mirrors, too
<mdz> Riddell: did Kamion already trigger a push?
<whiprush> mdz: I can publish it in the future, when would a good time be?
<Riddell> mdz: I don't know, it's been a good 8 hours
<mdz> Riddell: pushing now
<mdz> it took about an hour for ubuntu
<Riddell> thanks
<whiprush> I'll push the fride thing out 2 hours then.
<ajmitch> whiprush: thanks for putting the motu report up :)
<whiprush> :)
<whiprush> wait until post-release. I got a good long distance plan.
<whiprush> mdz: I'm calling you first!
* ajmitch will have to put the fridge as part of his daily reading habits
<jsgotangco> fridge it!
<whiprush> dev interviews rule!
<mdz> whiprush: this is an unlisted wall!
<ajmitch> whiprush: going to UBZ?
<whiprush> "mdz released ubuntu twice last night ... it was wonderful."
<whiprush> ajmitch: going to try, if I can it will only be for a few days."
<ajmitch> whiprush: you'd be able to get in a few inebriated interviews there
<whiprush> yeah, because people would love "drunk source package management with scott james remnant."
<whiprush> hmmm, we really need an #ubuntu-sounder or somesuch for the fridge and other non-development related marketing.
<whiprush> who can I propose this to?
<ajmitch> just do it
<whiprush> metal. as soon as I get home.
<Riddell> mdz: anything you can do about the lack of torrents for the kubuntu install CDs?
<mdz> Riddell: hmm, not without fiddling things by hand.  why weren't they generated?
<Riddell> mdz: no idea
<Riddell> but I don't see them at http://82.211.81.152/kubuntu/5.10/
<bob2> wow, suspend3 is sick
<bob2> but cool
<mdz> bob2: those two words mean the same thing in contemporary US slang
<jdong> am I the only to experience EXTREME FF slowness at suspend2.net?
<jdong> especially with wheel scroll and autoscroll?
<mdz> Riddell: I don't even see RC on releases.ubuntu.com
<bob2> "The answer is, of course, another ioctl() command, IOCTL_KMALLOC, which executes a get_zeroed_page() call and returns the address of the resulting page to user space. "
<mdz> (kubuntu RC)
<bob2> mdz: hah
<Riddell> mdz: it depends what IP you get, it's only on http://82.211.81.152/kubuntu/5.10/ as far as I can tell
<mdz> Riddell: something's busted
<mdz> whiprush: community council
<mdz> Riddell: I don't think it's making it onto syncproxy, so it won't get out to the mirrors
<Riddell> mdz: anything we can do tonight then?
<mdz> Riddell: I don't think so; we need elmo or Znarl
<mdz> Riddell: we can either wake them up, or wait until tomorrow.  I recommend the latter.
<mdz> Riddell: send mail to elmo explaining the situation and he'll look into it when he wakes up
<Riddell> mdz: ok
<Riddell> mdz: sabdfl said I should get KDE 3.4.3 into breezy since we now have the sources
<jsgotangco> Riddell, wow!
<jsgotangco> hmm i seem to have a post-update info notification that is stuck
<jsgotangco> i click on it and it doesn't contain anything
<mdz> Riddell: I think that's a little aggressive, but it's your funeral ;-)
<mdz> (and sabdfl's)
<bob2> new upstream after RC? daring!
<neuralis> jsgotangco, i saw a few of those. they eventually went away by themselves.
<Riddell> KDE release schedule hasn't fitted in the ubuntu as well as it did last release
<Riddell> ah well, when I'm KDE release manager..
<jsgotangco> Riddell, so evilll...=)
<Riddell> ...it'll be a strict 3 month release cycle!
<bob2> that's a full 2 times better than gnome
<mdz> Riddell: one month of feature development, one month of bugfixing, and one month of sheer panic
<Amaranth> haha
<Riddell> new koffice on monday too, but those karbon developers seem to have been developing a bit too much in branch http://koffice.kde.org/announcements/changelog-1.4.2.php
<dobwan> whiprush, you about? I'm trying to play A/V files you got the time?
<bddebian> Riddell: :-)
<daniels> slomo_: we've been asked by the debian release managers to hold off until all the other transitions are complete
<fabbione> morning
<bddebian> Hello fabbione 
<magnon> goodd morning
<jdub> elmo: ping
* lamont notes that python-qt3 Build-Depends: sip4, and that sip4 is universe while python-qt3 is main...  elmo/kamion/mdz?
<crimsun> lamont: not too different from say vlc & libpostproc-dev
<lamont> crimsun: still a policy violation
<mdz> lamont: http://people.ubuntu.com/~mdz/anastacia.txt
<mdz> it was seeded late and I think some inclusion reports are lacking or unreviewed
<lamont> meaning that you're dealing with deciding which package moves to the "correct" component?
<lamont> ew.  hopefully we won't demote the kernel packages...
<mdz> lamont: it means that there's investigation to be done
<lamont> mdz: and it means that you're aware of it. :0)
<mdz> yes, though it was temporarily off my radar
<lamont> hppa's buildd is spinning trying to build python-qt3 every cron.daily run, is the reason I noticed...
* lamont does the reset on the amd64 livecds, the rsync-friendly way
<tritium> Kamion, ping
<bddebian> WTF is <X11/bitmaps/icon> supposed to bring in??
<mdz> tritium: I wouldn't expect him for at least another 3 hours
<tritium> mdz, no problem.  Thanks.
<bddebian> Nevermind, it's not build-depping on xbitmaps
<bddebian> Not that anyone was gonna answer anyway ;-P
<daniels> bddebian: i was, but i don't look at IRC every minute
<bddebian> daniels: Well why not?? :-)
* bddebian loves packages that get a warning on virtually every line of code
<tritium> bddebian, how late are you going to be up?
<bddebian> tritium: I should hit it pretty soon
<bddebian> I should actually be in bed already but thanks to dholbach we have this HUGE list ;-)
<tritium> okay, I was going to ask you to request the sync of xfig
<bddebian> tritium: You want me to e-mail him?  I'm already his favorite PITA :-)
<tritium> bddebian, I don't mind emailing him.
<bddebian> Boy is xppaut a lame-ass package :-)
<bddebian> Aw fsck
<lamont> elmo: is king mad, or is it just me?
<fabbione> doko: wake up dude
<bob2> wasabi: why's tomcat4 not in ubuntu?
<jdub> haha: "THe most trusted colour in the world: WHAT CAN BROWN DO FOR YOU?"
<jdub> ^ UPS ad on USA tv
<Amaranth> you've never seen those?
<Amaranth> UPS commercials :)
<tritium> jdub, are you already in the US?
<infinity> UPS isn't terribly popular in Australia, and maybe jdub doesn't watch much North American TV...
<jdub> tritium: yeah
<bob2> jdub: come to my lug!
<whiprush> bob2: you're in the us?
<whiprush> thought you lived in the uk for some reason.
<Amaranth> infinity: they play those so much if you've managed to walk by a TV in the US in the last year or two you've probably see them
<tritium> jdub, if you pass through New Mexico on your way to Old Mexico, you've got a place to stay
<whiprush> jdub, if you want to experience urban decay, there's a place for you to stay in detroit also.
<bob2> whiprush: I live in .au, but my lug could do with a jalapeno up it's tailpipe
<whiprush> heh
<Yagisan> bob2: where is your lug ?
<bob2> Canberra
<Yagisan> bob2: damm - just a bit too far
<womble> bob2: You mean having the annual AusLUB meeting in Canberra wasn't enough for you?
<womble> s/AusLUB/AusLUG/ dammit
<bob2> then they moved it to NEW ZEALAND
<fabbione> does Jani Monoses IRC?
<crimsun> yes
<crimsun> (janimo)
<fabbione> ok thanks
<Yagisan> bob2: that's just proof that New Zealand is part of Australia :-P
<Lathiat> linux.conf.au is being held in new zealand too, so
<Lathiat> nz is just a state of australia :)
<jsgotangco> lol
<Yagisan> nah - two states - north and south island :-P
<Lathiat> haha
<lifeless> Yagisan: wrong way around
<lifeless> Yagisan: australia is west island....
<lifeless> we just dont make a fuss to avoid upsetting them
<lamont> mdz: amd64 livecd roots cleaned up, daily build started (albeit 30 minutes late)
* lamont -> bed
<fabbione> night lamont 
<Yagisan> lifeless: technically Australia is a continent - so it would be west continent.
<Yagisan> although it seems the kiwis have established a beachhead at bondi in preparation for an invasion
<daniels> (a continent and an island, plus all the terroritories.  and bondi is far more english than kiwi; all the kiwis are infiltrating the melbourne dnb/breaks scene.  but this is getting horrendously off-topic.)
<Yagisan> it is off-topic - but a bit of good natured humor - no offense meant to ajmitch and any other kiwis
* Yagisan goes back to work
<pitti> Good morning
<daniels> morning pitti
<fabbione> hey pitti
<fabbione> yo daniels 
<daniels> sup fabio
* daniels does a jig.
<pitti> Hi daniels
<fabbione> daniels: X has been a success on a Creator 3Dsomething..
<pitti> daniels: yesterday's hoary->breezy upgrade produced a nice xorg.conf and my keyboard worked, thanks :-)
<fabbione> daniels: no autodetection tho.. but we will fix that for dapper
<pitti> daniels: however, I still got this dumb X/Gnome keyboard question
<pitti> daniels: do you have any idea what Gnome could still complain about?
<daniels> fabbione: creator is sunffb, isn't it?
<fabbione> daniels: i think so yes
<daniels> pitti: could you please /msg me the Xkb bits of xorg.conf and the output of xprop -root | grep RULES?
<daniels> pitti: (also, no worries)
<fabbione> daniels: generally the autodetecion on sparc sucks.. there are also warnings at keyboard layout code..
<fabbione> daniels: nothing we are going to touch for breezy
<daniels> cool
<fabbione> at least we know the code works
<fabbione> and that's good
<tepsipakki> jbailey: around?
<fabbione> are we still free to upload to universe?
<fabbione> hmm i guess so from -changes
<pitti> fabbione: yes, until the MOTUs say stop
<fabbione> ok
<daniels> gar
<daniels> sebariiiiiiiiiiiino
<pitti> daniels: found a GTK bug?
<daniels> pitti: i blame the gnome kb applet at this point :)
<Lathiat> i thought all bugs were gtk bugs :)
<fabbione> daniels: i think 8468 is an easy fix...
<fabbione> 4 hours of sleep at night aren't enough
<daniels> +// This RO_US/Programmers layout, although the secondary layout in the 
<daniels> +// Romanian standard, has always been the "de facto" standard in the 
<daniels> +// Linux/Unix world. It is implemented here as the default layout and it's
<daniels> +// fully compatible with an US keyboard (Euro on AltGr+5 doesn't count).
<daniels> i can't quite express how much I don't want to apply that patch
<fabbione> wasn't that applied to CVS upstream?
<daniels> yes
<fabbione> ok
<daniels> +    // Primary layout in the new Romanian standard.
<daniels> +    // Implemented here as a variant because of the lack of hardware 
<daniels> +    // Romanian keyboards and because of the predilection of Romanian
<daniels> +    // X users towards the secondary layout from the new standard.
<fabbione> *ugly*
<fabbione> ok
<fabbione> i see your point :)
<fabbione> when do you plan to upload X?
<daniels> as soon as I establish that my current fixes aren't FTBFS
<fabbione> (i am getting kind of worried to get too many big pkgs in the last minute to make it with sparc)
<fabbione> ok
<infinity> fabbione : Dude, what's with that "special case sparc" xubuntu-meta upload?.... Do they not use proper seeds like everyone else?
<fabbione> infinity: nope
<fabbione> infinity: they use a static file
<infinity> Ew.
<fabbione> transex3 <- only OO2 could have a dir called that way :P
<fabbione> infinity: they planned to bind to seeds, but it looks like they can't?
<fabbione> i really have no idea
<infinity> <shrug>
<maswan> "it would be neat if we could saturate our uplink, hope you manage to fill your 2xGigE" -- our netmasters, when asked about bandwidth usage for breezy release. :)
<Lathiat> heh
<infinity> Not many people think saturating their uplink is "neat".
<daniels> only when it's virtually impossible to do so
<daniels> e.g. pdx
<Lathiat> well we hit what, 1.4gbit last release?
<maswan> 1.2-1.4 or so at peak, yeah. sarge peaked at about 2 here, and that's still 500Mbit short of saturation
<maswan> this network has been aronud like this for 2-3 years now, without ever having been saturated.
<Lathiat> heh
<fabbione> hey maswan 
<fabbione> maswan: give me access to a box with a lot of disk space and i will saturate that bw easily
<maswan> fabbione: hi there
* fabbione considers a mirror of internet a good way to do that ;)
<fabbione> lot of space + enough GigaEthernets 
<maswan> I can do that with iperf too, that's not the issue. the thing is doing it with something useful.
<fabbione> maswan: yeah.. i can do it with something useful
<maswan> fabbione: like what?
* fabbione knows plenty of useful warez^Wdownload sites
<fabbione> ;)
<fabbione> just kidding
<pitti> Kamion, elmo: please sync mod-auth-shadow (universe, security update)
<robitaille> does anyone know if hoary was using the country codes by default for the urls to the archive servers  in /etc/apt/sources.list? Or that's a new thing for breezy?
<sabdfl> Kamion: ping
<fabbione> hey sabdfl 
<sivang> GOod morning all
<hunger> good morning!
<sivang> hey hunger 
<pitti> Kamion, elmo: bugzilla sync, please (universe, security)
<pitti> ogra: please check http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3166
* daniels stares at pitti.
<pitti> ogra: ah, forget it, we have 1.4.10
<pitti> daniels: ?
<daniels> n/m
<pitti> OMG - fabbione, joy! 5 new kernel CANs
<fabbione> pitti: you kidding right?
<pitti> fabbione: no, I'm not, but I didn't review them closely yet
* fabbione sighs
<fabbione> ok
<fabbione> send me the crack :(
<pitti> fabbione: I evaluate them, collect patches, and mail you
<fabbione> sure that's perfect
<pitti> Hi seb128 
<seb128> hey pitti 
<fabbione> pitti: did you get any answer from Herbert?
<fabbione> pitti: i would like to have his debdiff before applying the new crack
<Lathiat> Kamion: you still cant change the mount point of ntfs partitions
<Lathiat> Kamion: is that goign to be fixed?
<pitti> fabbione: oh, no, I didn't ask him - it wasn't clear to me that I should be the relay, sorry
<pitti> fabbione: I'll ask him immediately
<fabbione> pitti: oh sorry.. we misunderstood..
<fabbione> no problem dude
<daniels> seb128: good morning sunshine
<pitti> fabbione: sent
<seb128> hey daniels 
<Lathiat> Kamion: (#14236)
<fabbione> pitti: thanks
<daniels> seb128: pitti has an xkb problem that I think is a gnome problem :)
<pitti> seb128: on hoary->breezy upgrade I still get the keyboard question, but xorg.conf loks fine
<daniels> seb128: basically, we've got rules xorg, model pc105, layout de, variant nodeadkeys, options lv3:lwin_switch
<daniels> seb128: and _XKB_RULES_NAMES has exactly that, and _XKB_RULES_NAMES_BACKUP is identical too
<daniels> seb128: but we still get the question
<seb128> weird
<daniels> that's what I said
<carlos> seb128, just in case someone else asks, update-manager is already imported into Rosetta (I don't see mvo around...)
<seb128> carlos: k, cool
<carlos> https://launchpad.net/distros/ubuntu/breezy/+sources/update-manager/+translations
<daniels> seb128: my understanding was that _X_R_N_B was the original settings, and _X_R_N what the kb applet said, so yeah
<daniels> seb128: i dunno what's going on
<sivang> Bon Jouj seb128 
<seb128> hi
<sivang> err, Jour even
<seb128> daniels, pitti: gnome-control-center/gnome-settings-daemon/gnome-settings-keyboard-xkb.c gnome_settings_keyboard_xkb_analyze_sysconfig() is the code for that warning
<seb128> 	GSwitchItKbdConfigLoadFromGConfBackup (&backupGConfKbdConfig);
<seb128> 	GSwitchItKbdConfigLoadFromXInitial (&initialSysKbdConfig);
<seb128> 	isConfigChanged = g_slist_length (backupGConfKbdConfig.layouts) &&
<seb128> 	    !GSwitchItKbdConfigEquals (&initialSysKbdConfig, &backupGConfKbdConfig);
<seb128> pitti: run gnome-settings-daemon with XKL_DEBUG=200 maybe
<Yagisan> G'day all - IA64 (Itanium) - Can run i386 binaries right ?
<daniels> no
<Lathiat> Yagisan: hah, i was right ;p
<daniels> you're thinking of amd64
<Yagisan> no - I know amd64 can run i386 - I have one
<Yagisan> I thought ia64 could too
<fabbione> Yagisan: you want to ask that to lamont when he is around
<Yagisan> no worries
<bob2> if it had, maybe people would have bought them
<Yagisan> I was just making a patch - and wanted to know if I should add ia64 to it
<Yagisan> bob2: it still cost too much
<daniels> yes, it does cost a hundred times more than competing space heaters
<pitti> fabbione: sent
* Yagisan goes back to bending ltsp to my will
<bob2> haha
<fabbione> pitti: thanks
<fabbione> pitti: got all of it :/
<fabbione> pitti: i assume everything is public by now
<infinity> ogra : Too late for breezy, but shouldn't the Escape key be bound to "cancel" in the xscreensaver dialog?
<infinity> ogra : s/dialog/unlock dialog/
<Kamion> tritium: pong
<Kamion> sabdfl: pong
<sabdfl> hey Kamion. did mdz discuss a new iso with you?
<Kamion> pitti: please ask just elmo - I was only doing syncs while he was on holiday
<Kamion> sabdfl: not that I've seen so far, although I haven't started on mail yet. Any particular new ISO?
<pitti> fabbione: yes, all public
<pitti> Kamion: alright
<Kamion> Lathiat: /var/log/partman would probably help
<fabbione> pitti: ok thanks
<pitti> carlos: http://mawson.ubuntu.com/%7Ecarlos/rosetta-breezy.tar.gz
<pitti>  is still 403
<Kamion> sabdfl: oh, I've got mail about it. give me a bit to digest
<carlos> pitti, because as I told you, stub had to kill the script and it's still running since I wake up this morning
<pitti> carlos: ah, ok
<pitti> carlos: odd, a dangling symlink should be a 404, but anyway
<carlos> pitti, removed so you will get a 404 :-)
<daniels> pitti: you got a link to these bugs?
<pitti> I don't particularly mind :-)
<stub> carlos: I'll disable the staging updates if you think it will be running for another 12 hours or more.
<pitti> daniels: "these"?
<carlos> stub, no, it will take only 3-4 hours and it's already running since 1 hour and a half ago
<daniels> pitti: the kernel security ones
<jc-denton> hi all
<jc-denton> i run breezy and in openoffice i still cannot start the help system
<jc-denton> i think i did everything right, i just cannot belive that this is still unfixed
<jc-denton> afaik breezy will be shipped with ooffice2
<Treenaks> or at least a beta of it
<jc-denton> yes
<Treenaks> jc-denton: is there a bug in bugzilla for this
<Treenaks> http://bugzilla.ubuntu.com/show_bug.cgi?id=14700
<jc-denton> yes
<jc-denton> i just saw it
<jc-denton> "confirmed. currently the help cannot be built using java-gcj-compat, and fails
<jc-denton> to build using the blackdown jdk as well."
<jc-denton> wtf
<jc-denton> i mean i cannot be shipped w/o help
<Treenaks> jc-denton: fix it then
<jc-denton> Treenaks: i'm not into openoffice
<jc-denton> hrmm
<jc-denton> cannot u just use the sun jdk
<jc-denton> i mean it's non-free
<jc-denton> but at least it works well
<daniels> 'i mean it's non-free'
<jc-denton> yes
<jc-denton> it also ships restricted kernel modules
<jc-denton> like the fw for my wlan chipset
<jc-denton> so why not java
<jc-denton> i'll probably ask on the mailing list
<crimsun> non-free does not imply that the license restricts its redistribution
<jc-denton> sun java does this?
<daniels> sigh, please take this to #ubuntu, but as crimsun implies, we can't redistribute it anyway.
<jc-denton> humm
<jc-denton> just
<jc-denton> to ship ubuntu as a newbie friendly distro w/o help seems to be a pretty stupid idea
<bob2> #ubuntu
<jc-denton> k i'll shut up
<rob^> like bitching in here will help..
<jc-denton> humm
<jc-denton> of course it does not
<jc-denton> but i think redhat also ships ooffice2 in fedora
<jc-denton> i wonder how they handle this
<rob^> jc-denton, file a bug
<jc-denton> there is already one
<jc-denton> 11:09 < Treenaks> http://bugzilla.ubuntu.com/show_bug.cgi?id=14700
<rob^> well just sit tight and the dev will get to it
<jc-denton> lol
<jc-denton> i hope so
<Kamion> we also don't really have CD space left for it
<jc-denton> but isn't it already frozen ( breezy)
<Kamion> yes
<jc-denton> humm
<jc-denton> ok
<rob^> I wonder if its worth changing to dvd, they are pretty cheap now days
<Kamion> sigh
<Kamion> http://cdimage.ubuntu.com/dvd/
<jc-denton> lol
<jsgotangco> yeah right try downloading a dvd
<jc-denton> install media fl4am3
<rob^> you don't have to fill the whole thing :)
<jc-denton> i prefer a small cd
<jc-denton> then i can install the rest from the net
<rob^> and have a net install iso for download too
<bob2> #ubuntu, kthxbye
<jc-denton> heh
<Lathiat> bob2: 'bai'
<jsgotangco> Kamion, do you just change strings in the installer doc in the cd?
<bob2> Lathiat: I dunno how you spell in WA, but here it's "bye"!
<rob^> heh
<Kamion> jsgotangco: ?
<jsgotangco> Kamion, it says we support 11 archietectures
<Kamion> which installer doc?
<Kamion> url?
<rob^> jsgotangco, is that one of ours?
<jsgotangco> file:///media/cdrom0/doc/install/manual/en/ch02s01.html#id2513920
<jsgotangco> rob^, no this is the debain installer doc
<rob^> yeah just thought that
<jsgotangco> i'm looking for parts of it usable for the release notes
<daniels> cool.  7 ubuntu-specific patches, 4 patches to be applied upstream.  the rest are modularisation, already applied upstream, or imake patches.
<rob^> are they almost done?
<Kamion> jsgotangco: I fixed that in debian-installer 20050317ubuntu16. See http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/ch02s01.html#id2513920 for an updated version.
<jsgotangco> Kamion, ahhh i haven't checked the rc doc actually sorry..(i pulled in an old colony cd)
<rob^> ah nice
<Kamion> jsgotangco: ok, use the net version
<ogra> infinity, yes, i'd have preferred that too, but i lost to much time for screensaver stuff already, so i concentrated on the essential bits sabdfl wanted me to do... we'll drop xscreensaver the day after breezy anyway ;)
<infinity> Are we planning on dedicating any real development effort to gnome-screensaver, or just praying that it improves upstream?
<ogra> infinity, upstream is very responsive to all our requests...
<ogra> i wont have much work with it... only the bits we might disagree about
<daniels> 'please make it actually function'
<azeem> it worked out-of-the-box for me so far, haven't noticed any problems
<azeem> didn't touched the dials, of course
<azeem> s/touched/touch/
<ogra> and note that its the only way to integrate right with gnome-power-manager
<ogra> azeem, it had a default dpms value of 2 mintes or so in the first package i got from upstream... it hardlocked many machines in GL mode, it has no option to setany powe management settings for your display and has no options to adjust and settings for any screensaver
<infinity> It had many (many) issues for me, so here's hoping we clear them all up very early.
<zyga> hello miracle workers
<ogra> ... just to mention some drawbacks
<fabbione> pitti: you got mail
<seb128> infinity: they changed almost everything that has been listed on the ubuntu wiki page already
<azeem> heh, cool
<ogra> infinity, we'll adopt it right away and due to the swich i already know the weirdest bugs ;)
<ogra> so it should become a rocking thing in dapper :)
<pitti> Hi carstenh, how are you?
<carstenh> hi pitti, fine :)
<XtaZ> hi friends
<sabdfl> Kamion: server-oriented. default (enter) just does ubuntu-minimal. ship-seed for that cd would include a bunch of server stuff (apache, zope, php, mysql, postgres, ldap, cluster stuff)
<sabdfl> no new supported software
<sabdfl> keybuk suggested name of 1ubuntu. or one-u-buntu
* infinity groans.
<infinity> I don't know how many poeple would get the pun without it being spelled out for them.
<daniels> so you can't install it on dl385s?
<sabdfl> daniels: agreed. two-u-buntu seems more industrial strength
<Kamion> sabdfl: mdz said ubuntu-minimal + ubuntu-standard by default (which seems more what I'd expect)
<fabbione> sabdfl: please skip cluster from default install. it can be dangerous if the user doesn't know about it
<fabbione> or it is installing another cluster node
<Kamion> sabdfl: should be doable - I'll just have to do some scary juggling :-)
* sivang wonders if this discussion is for breezy release.
<Kamion> I can't decide whether to create a new seed branch or to add a new file to the Ubuntu seeds
<sabdfl> Kamion: +1 ubuntu-standard
<dholbach> hellas
<sabdfl> sivang: yup
<Kamion> seed handling will depend on how it's most smoothly implementable in cdimage
<sabdfl> Kamion: whatever's lowest risk and easiest to implement
<sivang> sabdfl: I was just sure this sort of things would be sorted out for dapper rather then breezy. Well, sooner the better probably.
<sabdfl> sivang: if it were more than a few hours, or involved new packages, i would defer
<sabdfl> but i keep getting asked for a "server version", and those people are happy with a separate cd, so we should just DOIT
<Mithrandir> sivang: did you get around to testing the kernel images yesterday?
<Kamion> my inclination is to make it be http://cdimage.ubuntu.com/ubuntu-server/ (or whatever project name we choose), i.e. a different project on cdimage like kubuntu or edubuntu
<infinity> That makes most sense to me.
<Kamion> but possibly to use Ubuntu seeds for it rather than branching
<infinity> We could have ship-desktop and ship-server...
<sivang> sabdfl: ok, but we would have more room to discussing the standard/server-base for dapper over UBZ , right?
<Kamion> ship-desktop makes no sense :-)
<daniels> whatever happened to buntu?
<infinity> Kamion : Well, ship and ship-server, then, whatever.  The point being that the "ship" seed should be the only one that differs.
<sivang> Mithrandir: I will have results for you today.
<infinity> daniels : I can't type that character on my keymap, so I gave up on the project.
<Kamion> infinity: I was thinking of just calling it 'server' and treating it like ship. There's nothing magic about the name 'ship' really
<daniels> infinity: rctrl+u
<Mithrandir> daniels: deferred.
<Kamion> cdimage can select the seeds it wants to use for any given project ...
<daniels> infinity: or AD07 L3, whichever you prefer
<sabdfl> Kamion: except it would not be installed by default
<sivang> Mithrandir: err, rather, this evening.
<Mithrandir> sivang: ok
<Kamion> sabdfl: ship isn't installed by default either
<infinity> Kamion : Nothing magic about it, except that we all know what it means.  But call it whatever you like. :)
<Kamion> although it is copied to the hard disk
<sabdfl> ok, so cdimage knows which seeds, and which to install?
<Kamion> yes
<Kamion> lots of strange requests for things over time have made it quite generic ;-)
<infinity> sabdfl : Do you have a reasonably concrete package selectoin already, or will you need some help defining this seed over the weekend?
<daniels> Kamion: i strongly suggest that nvidia-glx be demoted from ship, and multiseat-udeb be removed from standard, after breezy; any objections?
<Kamion> daniels: none to multiseat-udeb (although udebs don't go in standard, but I know what you mean)
<daniels> s/standard/thingy/, then
<Kamion> daniels: not sure about nvidia-glx; depends on the outcry involved
<infinity> Kamion : We don't ship fglrx.  We only ship nvidia-glx, specifically because of multiseat, if the comment in the seeds is to be believed.
<daniels> well, nvidia-glx was only seeded for a very specific reason which no longer applies at all; if we're keeping it for more generic reasons (i.e., people find it useful), then we should really be seeding fglrx too
<Kamion> infinity: mdz sent me a mail with a draft seed; I can bounce it to you
<mjg59> daniels: Weirdly, the daily amd64 build from Tuesday worked fine on the HP amd64
<Kamion> infinity: ah, in that case fine by me
<daniels> mjg59: the ... fuck?
<mjg59> Quite
<daniels> mjg59: i blame the kernel.  but I just uploaded something which disables accel on hp rv370s, and r[cs] 4xxs
<mjg59> (Sorry, I've been in London without net access since then)
<janimo> daniels, if you need more data or live testing on the wavy X600 issue I am here
<fabbione> ah janimo 
<mjg59> daniels: Had it running all day for two days without any trouble, so...
<daniels> janimo: i can't think of anything useful at the moment, sorry, bar 'try without the framebuffer'
<fabbione> here you are
<janimo> fabbione,, yup :)
<daniels> mjg59: bongtasmic.  so, 14446.
<daniels> mjg59: what's the maximum keycode of these suckers/
<mjg59> Christ knows
<fabbione> Janimo: i had to do an xubuntu-meta upload this morning..
<mjg59> Why would anyone want autorepeat on any of those keys?
<janimo> I put in powermgm
<fabbione> hope you don't mind too much
<janimo> because I thought it was cross platform
<fabbione> but it makes it working on sparc..
<janimo> fabbione, not at all :)
<daniels> mjg59: just trying to dampen the impact as much as possible
<mjg59> daniels: If I confirm this, can you revert the "fuck my acceleration" thing?
<mjg59> daniels: They're scattered all over the range
<janimo> mjg said pmi should be cross plat so I included it
<fabbione> powermgm is cross platform.. but acpi-support no
<daniels> mjg59: and I assume that 146 is the minimum keycode rather than 141, since that's what they thing does
<mjg59> Yeah
<daniels> mjg59: sure thing, I'll just revert it to 'disable on r[cs] 4xx only'
<janimo> I thought it cleverly depends on acpi only on selected archs
<fabbione> janimo: not your fault.. so don't worry
<daniels> mjg59: my current line of thinking is that it's a BIOS thing, given that it varies per-vendor
<mjg59> daniels: Well, the HP machine seems unaffected now
<mjg59> I'll test again later on
<daniels> mjg59: if you're really bored, you could use the table parsing code in radeon_bios.c to modify an IBM BIOS to do your bidding
<daniels> or just take it from an equivalent laptop (LVDS on the primary connector, same resolution)
<janimo> fabbione so you actually use xubu on sparc?
<daniels> then see if it will do your bidding
<fabbione> janimo: no i don't.. other people do
<janimo> ah ok
<daniels> mjg59: so yeah, if it occurs again, I wonder if re-POSTing won't fix
<fabbione> janimo: my sparc is headless :)
<daniels> mjg59: (or just running an IBM BIOS, then running an HP BIOS immediately after, and hope you don't destroy your display ITMT)
<mjg59> daniels: A-ha ha ha.
<daniels> mjg59: (seriously)
<daniels> i mean, if you want to get funky, you could also disconnect the LCD while you do this
<mjg59> I'm not stripping the machine, I'm afraid
<daniels> or just modify the BIOS so it doesn't touch FP_GEN_CNTL at all, ever
<daniels> and set DISABLE=1
<mvo> Kamion: is #16149 ok for -final?
<Kamion> mvo: does the API change matter?
<Kamion> -void launchpad_integration_add_icon_factory ();
<Kamion> +void launchpad_integration_add_item_factory ();
<Lathiat> i had to reread that 4 times to see the differene
<sivang> why icon was replaced with item?
<sivang> (afaik there were two funcs like this)
<mvo> Kamion: not really, it just fixes some warnings (because the prototype was mixed up)
* pitti curses at bazaar
<mvo> sivang: it wasn't replaced, it was just a wrong prototype
<sivang> mvo: ah, k
<Riddell> elmo: do you know why Kubuntu RC isn't mirroring?
<ogra> Riddell, thats rather a question for the mirror masters ;) poke magnon for example 
<Mithrandir> Kamion: 17183; fix looks ok to you?
<sivang> Mithrandir: is it a good idea to run bonnie as well for referehce?
<Mithrandir> sivang: I was just using it since it does disk benchmarking.  Any method works for me.
<Riddell> ogra: there was a syncing issue on the ubuntu side last night
<sivang> Mithrandir: k
<ogra> Riddell, ah, ok
<Mithrandir> sivang: if you're actually able to track down _what_ is causing the slowdown, I'd be very, very grateful as well. :-)
<Riddell> Kamion: do you know why there's no torrents for the Kubuntu RC install CDs?
<Kamion> Riddell: I'm fixing
<pitti> Riddell: you are reasonably sure that you want kde-guidance in main?
<Kamion> I was going to send you mail when done
<Riddell> pitti: yep
<pitti> Riddell: is it tested enough to be known not to trash your config files?
<Riddell> Kamion: cool
<Riddell> pitti: not killed mine yet
<sivang> Mithrandir: well, if your kenrel solve it, that it's definitely inotify , or are there there any others factors to check?
<sabdfl> Riddell: how's progress on 3.4.3?
<pef> hello
<Mithrandir> sivang: the only difference in those kernel images is the disabling of inotify, yes.
<Riddell> sabdfl: mdz said it's mine and (your funeral) so I'm packaging it now and I'll get some people to test it and upload if there's no problems
<sabdfl> cool. thanks. kde: the new black
<Lathiat> Riddell: whats this, new kde?
<Riddell> Lathiat: a badly times bugfix release of KDE, yes
<Kamion> Riddell: in any case, though, once I've fixed the torrent generation, it still requires admin action to restart the tracker
<Lathiat> Riddell: ah
<Lathiat> Riddell: well im not much of a kde user but i'm up for some testing
<janimo> jdub, ping
<Kamion> Riddell: it probably broke because my connection died in the middle of publishing
<sivang> Mithrandir: do you run bonnie default, or use some cmd line args?
<Mithrandir> sivang: just bonnnie++.
<sivang> Mithrandir: k, on my way now.
<Mithrandir> sivang: you need free space equivalent to double the size of your RAM.
<sivang> Mithrandir: I have, I didn't specify a subfolder for it to work in, will it clutter all my / ?
<Mithrandir> sivang: no, it'll clutter the directory you're running it from, then clean up afterwards
<the--dud> wow, installing suse 10.0 OSS now... breezy should have even 40% of the GUI installer that suse has cooked up
<the--dud> fucking amazing stuff ;/
<Treenaks> the--dud: Suse is hell once you've installed it..yast is SLOW
<Treenaks> the--dud: and upgrading to a new version? don't even try if you have custom packages installed
<the--dud> Treenaks, I wont dispute that. but the installer
<sivang> Treenaks: and what about compat-db ? where has it gone for SUSE ? :)
<the--dud> not only is it even more userfriendly than the XP installer for windows... but it's incredibly powerful for expert users
<the--dud> the only drawback for this 10.0 installer is that you need all 5 cds it seems
<the--dud> but my point is, why can't ubuntu have something like this? :D
<Treenaks> sivang: I have no idea
<Treenaks> the--dud: because ubuntu wants to be once CD
<mvo> the--dud: please move this to some other channel, this is the ubuntu development channel. see the wiki for information about a graphical installer for ubuntu
<the--dud> well sorry then, was just wenting an idea... I'll refrain myself from such actions in the future
<Treenaks> the--dud: just have a look at the wiki first ;) webwereld.nl/
<Treenaks> uh
<Treenaks> the--dud: https://wiki.ubuntu.com/GraphicalInstaller
<Treenaks> (doh @ pastebuffer)
<mvo> the--dud: I didn't wanted to sound unfriendly/harsh, but there is some information on the wiki already :)
<the--dud> yeah, thanks... I'm following it closly
<Kamion> the XP installer is anything but user-friendly
<Kamion> it's absolutely dreadful
<the--dud> Kamion, I meant like... all buttons and lots of colours and shapes
<Kamion> that's not user-friendly, that's just shiny. there's a difference.
<the--dud> good point
<Mithrandir> Kamion: it's not even shiny.  It's plasticy and icky.
* mvo has never seen it
<sivang> Mithrandir++
<Kamion> Mithrandir: well, I happen to agree - but even taking the--dud's comments at face value ...
<mjg59> Kamion: Tuesday's daily still automounted FAT partitions but not NTFS ones
<Kamion> ok, I'll investigate
<janimo> Kamion, will you have some time this coming week for seeding/buildd 101 so I can take care of that for xubuntu?thanks
<janimo> I ahve read the wiki pages
<Kamion> janimo: sure, try me early next week
<janimo> ok
<Lathiat> mjg59: nice ot see suspend is enable dou tof the box on my m20 now
<Lathiat> *nice to see suspend is enabled out of the box
<Lathiat> (to ram)
<Lathiat> hrm, hibernate didnt work tho, it just booted back up and didnt resume
<mjg59> Are you using LVM?
* fabbione heads offline for a bit
<maswan> mvo: excuse me for asking a probably trivial question, but how does the keyring package work wrt getting trusted by apt-key? I can't seem to find anything in it that adds stuff anyway.
<Lathiat> mjg59: no
<Lathiat> i'll try again and see if i can see an error
<mvo> maswan: it calls apt-key update in it's postinst
<Riddell> elmo: can you restart the tracker on the kubuntu torrents, kamion added the missing ones
<doko> fabbione: is the sparc build still bleeding?
<maswan> mvo: yes, but that seems not to include my newly added keyring.
<maswan> mvo: does it assume that the ubuntu-archive keyring is already trusted by some other means?
<Kamion> maswan: apt.postinst in Ubuntu does it
<maswan> Kamion: Ah, thanks. That's what I needed to know.
* maswan was looking in the wrong place
<Lathiat> mjg59: gah, it worked that time
<Lathiat> but i did drop out of usplash
* Lathiat tries again
<pitti> mjg59: do you want radeontool in main for breezy? it does not work at all for me (Radeon 9200) and the description scares me off...
<Yagisan> Lathiat: I searched the debian mailing lists - ia64 can run i386 :)
<mjg59> pitti: Yes, I do
<mjg59> Otherwise I wouldn't have proposed it for main
<mjg59> It's only run under tightly controlled circumstances
<pitti> mjg59: so it's not supposed to be run by users directly?
<mjg59> It has functionality that may be useful to some users, but the reason it's there is so that acpi-support can use it
<Lathiat> Yagisan: really?
<Lathiat> Yagisan: interesting
<Lathiat> mjg59: i thought mdz backed that out
<mjg59> He did
<pitti> mjg59: hmm, ok. So if some user breaks his hardware with that, I know who to blame :-)
<mjg59> The same user can quite happily break his hardware in other ways as root
<Lathiat> mjg59: ok i i just hibernated twice
<Lathiat> fine
<Lathiat> so i dont know what happened the first time :\
<Lathiat> i know, i'll try sleep, come out, and then hibernate
<Lathiat> mjg59: did the extra dell keycodes go in?
<mjg59> Which extra Dell keycodes?
<Lathiat> hibernate, eject
<mjg59> Yes
<mjg59> Some time ago
<Lathiat> theres a battery and crt button too
<Lathiat> but they dont really ahve any associated action
<mjg59> What the CRT button does is up to the BIOS
<Lathiat> well in both my dells, the CRT button is software
<Lathiat> does nothign in hardware
<mjg59> It signals the BIOS
<Lathiat> well, my bios does nothing
<mjg59> Right
<Lathiat> and it gives me an acpi event
<Lathiat> or is it a keycode
<Lathiat> i forget
<mjg59> It's a keycode
<Yagisan> Lathiat: it is interesting - it seems to be SLOW - but it's there just like amd64 (well not quite - I think it's done by firmware)
<Lathiat> Yagisan: ok
<Lathiat> Yagisan: where as amd64 is very much like x86
<Lathiat> so its not much of an issue
<Yagisan> Lathiat: yes. It reminds me of how apple did m68k on ppc
<Lathiat> mjg59: ok i lied, it works on my 8600
<Lathiat> mjg59: it doesnt work on the m20
<Lathiat> doesnt give a keycode on my 8600 either
<mjg59> What chipset is in the m20?
<Lathiat> ati firegl v3100
<Lathiat> nvidia go 5200 in the 8600
<mjg59> Bleah
<mjg59> No, I don't think we have any nice easy way of toggling the head from userland
<Lathiat> mjg59: ok
<Lathiat> do we have support for it at all?
<mjg59> You can configure X so it always outputs on the CRT head
<Lathiat> hm ok
<Lathiat> does xorg 7 have any plans for a dynamic configuration system? :)
<Treenaks> Lathiat: plans? always ;)
<Lathiat> let me rephrase that
<Lathiat> does xorg 7 have any actual momentum
<Lathiat> for a dynamic configuration system
<mjg59> For that? No
<Lathiat> like changing driver options on the fly
<Lathiat> maybe even video drivers
<Treenaks> mjg59: eventually...
<Treenaks> Lathiat: http://xorg.freedesktop.org/wiki/ToDo
<mjg59> Treenaks: Not for 87.0
<mjg59> Uh
<mjg59> 7.0
<Treenaks> mjg59: maybe fore 87.0 ;)
<Lathiat> hah
<Mithrandir> *chuckle*
<maswan> Kamion: Hm. That copies the keyring to /etc/apt/trusted.gpg, I don't get what good the apt-key update in the keyring postinst is going to do, a new keyring package won't get copied into /etc/apt.
<bob2> lkml needs some sort of anti-crackpot SA rule
<Kamion> maswan: pass
<maswan> mvo: do you care about the above statement/question to Kamion?
<maswan> or are you guys busy with actually trying to release something. :)
<mvo> maswan: a bit busy :) apt-key update will add any new keys from /usr/share/keyrings/ubuntu-archive-keyring.gpg to the apt keyring and remove keys from /usr/share/keyrings/ubuntu-archive-removed-keys.gpg 
<mvo> maswan: does that not work for you? 
<maswan> mvo: Oh, ok. Is the /usr/share/keyrings/ubuntu-archive-keyring.gpg filename hardcoded into apt-key?
<mvo> maswan: yes. do you need something more flexible?
<maswan> mvo: The background is that I'm doing a keyring package for our local repository.
<maswan> mvo: I just hacked in an apt-key add for our local key in the postinst. I just didn't get how it worked in the first place. :)
<mvo> maswan: documentation is a bit sparse :/ could you remind me after the release about this issue again? maybe we can have something more flexible for apt-key update then (there is a patch floating around that adds /etc/apt/keys.d or something
<maswan> mvo: Yes, I'll try to remember that.
<mvo> maswan: thanks :)
<jdub> mjg59: pong
<jdub> er, ping
<mjg59> jdub: Hi
<jdub> yo mjg59 
<mvo> infinity: do you have a opinion on #17116?
<jdub> mjg59: so is this formal hall thing sorted?
<mjg59> jdub: Not yet. I was planning on sorting it today (I've been in London for the past couple of days)
<jdub> mjg59: aha
<jdub> mjg59: you've been in touch with dean wilson?
<mjg59> No...
<jdub> hrm
<mjg59> Who's he?
<jdub> greater london lug person
<jdub> speaking to someone else from there?
<mjg59> Oh, yes
<mjg59> Him
<jdub> so they're trying to get us on the 4th
<jdub> haha
<jdub> 14th
<mjg59> Yeah
<mjg59> That doesn't actually sound ideal
<jdub> mmm, i thought you were hoping for the 14th in cambridge
* jdub is in the other cambridge atm
<mjg59> You said the 12th for that
<mjg59> Release is the 13th, so release party in London is likely to be the 14th
<Kamion> mvo: it doesn't seem to be about console fonts - it's about what vt you end up on
<Kamion> mvo: maybe S98usplash should 'chvt 1' slightly less conditionally
<Treenaks> jdub: we'll have a late party in Amsterdam the week after :)
<mjg59> jdub: I have to go out now
<jdub> ok
<mvo> Kamion: yes, I was thinking of something like "if [ "$(fgconsole)" = "8" ] ; then chvt 1; fi
<Kamion> that sounds reasonable
<sladen> mvo: if $(fgconsole) != "7"   ...
<Kamion> or 'if type usplash_write >/dev/null 2>&1 && [ "$(fgconsole)" = 8 ] ; then ...'
<Kamion> or 'type usplash', or whatever
<Kamion> sladen: personally I'd rather have it very usplash-specific
<mvo> IMHO we should add "post-run-scripts" support for usplash for dapper. so that whenever usplash exits a script can be run that sets the console-fonts and switches the terminal 
<xTina> Kamion: Quick question: is the daily-installer from Oct. 5 and the RC's installer the same? I tested that daily in our automated lab install, but if the RC were different I'd test again.
<mvo> Kamion, sladen: thanks
<Kamion> xTina: slightly different; I did a full (non-daily) installer build on the 5th for RC
<Kamion> i.e. installer-* rather than daily-installer-*
<Kamion> I doubt the differences are significant, though
<xTina> Kamion: ok, thanks :)
<xTina> Kamion: btw did I show you the pix? http://tuxtina.de/tmp/ubuntu_lab1.jpg & ...2.jpg
<Mithrandir> xTina: cute tux in the corner. :-)
<Lathiat> xTina: nice
<xTina> Mithrandir: yeah, unfortunately it has been loosing air recently. guess I'll have to take it to the swimming pool or the bath tub at some point to figure out where the hole is ;)
<Kamion> xTina: no, hadn't seen that before - neat!
<Mithrandir> xTina: oh, it's not one of the plush ones?
<xTina> Mithrandir: no, a huge inflatable one :)
<mvo> xTina: nice
<Kamion> xTina: http://www.livejournal.com/users/ewx/316986.html
<xTina> Kamion: *lol* good idea :)
<xTina> there's another 70 machines currently on Fedora Core 1 that get Ubuntu at the end of next week
<Kamion> xTina: do you reinstall them all every day then, or something?
<Kamion> wondering what the automated lab install is
<kent> xTina, is it a school classroom or what? 
<xTina> Kamion: No, it's installed through d-i preseeding and updated/patched through a custom python-based system.
<xTina> Kamion: http://tuxtina.de/archives/2005-09-25T11_40_00.html
<xTina> kent: no, a university lab
<jbailey> tepsipakki: Was asleep, I'm around now.
<pschulz01> xTina: That's a fantastic photo!
<xTina> kent: 74 machines in this one and another one with 71
<pschulz01> xTina: How long does it take?
<kent> xTina, it looks very nice :)
<xTina> pschulz01: what? installing? or making the move from Fedora-1 to Ubuntu?
<pschulz01> xTina: all of the above... 
<pschulz01> xTina: How long would it take to setup a room, given that the machines are already there (plugged in etc.)
<lamont> Yagisan: (and fabbione) ia64 runs i386 binaries just fine... see openoffice.org on hoary. :0)
<pschulz01> xTina: Do you start from a 'blank' system?
<xTina> pschulz01: Well, it took me a few weeks (part-time) of course since I had to get debian-installer partitioning to work and figure out a few of its quirks first. And then I ran into every single bug in hoary I guess ;)
<xTina> pschulz01: If I did it now it probably wouldn't be much of a problem to do it in less than a day.
<Yagisan> lamont: thanks lamont
<xTina> pschulz01: depending on the amount of customization needed that is
<pschulz01> xTima: Would torrent help the pre-seeding?
<xTina> pschulz01: torrent?
<Kamion> xTina: oh, I knww you don't reinstall them all *manually* :-)
<Kamion> cool
<pschulz01> xTina: Using bittorrent to update to d-i cache.
<Kamion> the meaning of "preseeding" there has nothing to do with the BitTorrent meaning of seeding ...
<xTina> Kamion: We only reinstall when something's badly screwed up.
<Kamion> xTina: *nod*
<pschulz01> xTina: sorry.. not what I ment.. just using bittorrent to copy files to pre-seed the d-i cache should be faster..
<xTina> pschulz01: The speed of the installation isn't a problem at all. We have a local mirror and gigabit ethernet. And with preseeding I meant the settings.
<xTina> Installing all 74 machines simultaneously takes < 30 minutes.
<pschulz01> xTima: cool...
<Mithrandir> xTina: it would be useful if we got a patch for fixing NIS password changes with pam_unix.. :-)
<pitti> fabbione: can you give me a hint how to interpret the kernel timestamps? how much time passed between 4294890.576000 and 4294976.648000?
<pitti> fabbione: are these seconds?
<pschulz01> pitti: yes they are
<xTina> Mithrandir: Well, if you're staying at 0.76 that's no problem (it's the stuff from Debian bugzilla plus a little more since this wasn't the only place where it's broken). But the problem is that there are major changes in any version following that and it doesn't seem to work properly in any (and fixing it is different in any of these versions).
<pitti> pschulz01: ok, thanks; is that the uptime, btw? 
<pschulz01> pitti: it doesn't look big enough to be seconds since 1970 :-)
<Mithrandir> pitti: about 49 days, 16 hours and 48 minutes.
<pschulz01> Mithrander: beat me to it.
<xTina> pschulz01: The other 70 machines is going to be a lot less fun. They only have 100 MBit and are 5 years old. But I have to modify the install only very slightly so it shouldn't require more than one attempt until it's up and running (I've checked it every few days on one machine and it always worked flawlessly).
<pitti> Mithrandir: impossible - that was right after a reboot
<pitti> anyway, thanks
<pschulz01> xTina: good luck :-)
<Mithrandir> pitti: hmm, weird.  IIRC, it's time since the machine was powered on.
<pitti> Mithrandir: my own dmesg looks sensible in that regard, too
<pitti> Mithrandir: I'm just trying to squeeze iformation about a dmesg log from a bug report
<pitti> thanks to you guys
<Kamion> mjg59: ok, I see why that ntfs thing's happening; should be easy to fix
<zyga> who build live cds for ubuntu?
<tepsipakki> jbailey: I made comments to the bug #17151
<Kamion> zyga: why?
<Kamion> (it's more effective to say *what* you want first, rather than trying to find out *who* you want ...)
<zyga> Kamion: true :)
<Kamion> zyga: I operate cdimage, which builds all of the official Ubuntu CD images; but I'm not sure if that's what you're really looking for
<zyga> Kamion: I've been building live cds for the past week and I'm dying to know if there is some faster way than cloop and create_compressed_fs with 
<sivang> Mithrandir: I'm trying to redirect the output of bonnie++ , any idea why it ignores my redirection attemps?
<Kamion> zyga: that's what we use too, AFAIK
<zyga> I've got a bunch of boxes here that could be used to compress my image in parallel but cloop utils seems buggy 
<azeem> sivang: maybe it writes to stderr instead of stdout?
<zyga> Kamion: do you use distributed compression?
<Kamion> zyga: but now I know you mean the live filesystem image, not the CD wrapper itself, and that's done by lamont/infinity
<Kamion> zyga: no
<zyga> ah okay :)
<Kamion> why bother - we only do it once a day or so
<Mithrandir> sivang: it writes to stdout, so just bonnie++ | tee logfile should work fine
<zyga> true :)
* zyga builds 20 images a day :/
<jbailey> tepsipakki: Thanks.  I'm still just getting started for the morning, I'll check it out in a moment.
<pitti> Kamion: when do you think is a good time to build the final langpacks for breezy gold? Monday?
<pitti> Kamion: that still gives us enough time to do another emergency build, and the Rosetta guys can fix some export bugs
<tepsipakki> kamion: how do I preseed static network configs? I've done a fresh install by hand but don't see any difference comparing to preseeded installation (which uses dhcp despite the preseed-files)
<Kamion> pitti: sounds reasonable, given that the language pack translation deadline has passed
<Kamion> tepsipakki: have you looked at the preconfiguration file example in the installation manual? it has an example of how to do this
<Kamion> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/apcs01.html
<tepsipakki> kamion: not for awhile..
<jbailey> daniels: ping
<bob2> EPUBTIMEIN.AU
<jbailey> Ah, 'k
<jbailey> Right, it's after the workday Friday there, as opposed to before it, here.
<bob2> the magic of timezones ;-p
<dholbach> doko: what about berlin release party?
<Riddell> Znarl: would you be able to restart the kubuntu rc torrents and look at why the images arn't syncing?
<Znarl> Riddell : ok.
<tepsipakki> kamion: that example doesn't seem to work. /target/etc/network/interfaces still shows dhcp-config
<tepsipakki> kamion: the preseed-file has been loaded correctly
<Kamion> tepsipakki: netboot or CD install?
<tepsipakki> kamion: netboot
<Kamion> tepsipakki: what method are you using to load the preseed file?
<tepsipakki> kamio: http
<Kamion> tepsipakki: do you think that network configuration might need to happen before loading the preseed file over HTTP? :-)
<tepsipakki> hrmh
<Kamion> tepsipakki: look up near the top of that example - it has an example of passing netcfg parameters on the command line rather than in a preseed file, to avoid exactly this problem
<infinity> mvo : Yeah, having the usplash init script chvt back to 1 iff we're on 8 sounds sane to me.
<tepsipakki> kamion: yeah, would've been a lot nicer to do it via preseeding..
<Kamion> tepsipakki: you can, but you have to modify the initrd to do that
<mvo> infinity: thanks
<Kamion> the installer will look for a preseed file in /preseed.cfg in the initrd
<Kamion> (passing kernel parameters like that is preseeding, BTW, just a different method)
<tepsipakki> kamion: ok, thanks
<infinity> mvo : Err, wait.  What will that do if gdm has started?... Will fgconsole report 7, even though the script's parent is vt8?
<Kamion> tepsipakki: np
<daniels> jbailey: asdfaser
<mvo> infinity: fgconsole will report 7 (but I'll re-check that before I upload anything :)
<jbailey> daniels: Basically just to say thanks. =)
<jbailey> daniels: I knew testing my fix before uploading was the right idea ;)
<daniels> jbailey: oh, for fr_CA?
<infinity> mvo : Please.  I don't want us to do anything dumb here. :)
<daniels> heh
<jbailey> daniels: Yup! =)
<jbailey> daniels: Since I now live in French Canada, it'll save me much annoyance. =)
<mvo> infinity: I wouldn't want to win the brown paperback award either :)
<daniels> jbailey: i could've told you off the boot that VARIANT=pc104 was totally wrong, but didn't even look at that bug tbh, so feel free to point me at bugs you've just filed if you want me to actually see it
<jbailey> daniels: Honestly, I had assumed it wasn't Breezy material and that you probably had some that were.
<infinity> mvo : It's probably safe to assume tha tif we're stuck on vt8, there's a chance we didn't properly reset the fonts, either, so I'd just make this test an || with the pidof usplash test.
<tepsipakki> kamion: there should be a netcfg-phase2 that would put preseeded config in /target ;)
<jbailey> daniels: mdz pointed me at it and marked it 5.10, so I gave it a shot =)
<jbailey> daniels: X now officially scares me more than gcc or glibc. =)
<daniels> heh
<daniels> jbailey: dude, that's the *easy* bit.  try 15372. :)
<mvo> infinity: sounds sane 
<tepsipakki> kamion: I mean that its ok if the installer used dhcp internally, but after reboot would use a static config
<tepsipakki> kamion: but maybe that's a wishlist item..
<jbailey> daniels: Right.  For instance. =)
<doko> daniels, seb128: just did a hoary->breezy upgrade, I still get the popup in gnome about non-matching X and Gnome keyboard layouts.
<pitti> sivang: here?
<jbailey> daniels: I may have to debug things in 4 different assembly languages, but at least all the assembly languages are *Documented* =)
<Diziet> I am right in thinking that people aren't supposed to confirm their own bug reports, aren't I ?
<jbailey> Diziet: Generally, yes.
<ogra> Diziet, yes
<jbailey> Diziet: I don't think it would be wrong if 12 people on the channel all said "Hey, we see that too!"
<Diziet> http://bugzilla.ubuntu.com/show_bug.cgi?id=17240, if anyone wants to be slightly amused.
<Robot101> wtf does gnome-power-manager register itself to the session manager as "GNOME Power Manager"? unsurprisingly, that binary doesn't exist, so it never restarts.
<jbailey> Diziet: But that's pretty rare, and still generally not worth it.
<Diziet> jbailey: Right.  Not quite the situation here.
<daniels> doko: i know, and not my problem
<ogra> Robot101, works fine here
<seb128> doko: speak with pitti about it, seems to be german specific
<seb128> dunno what weird keyboard you guys use
<seb128> I've no issue with french one
<pitti> seb128: what's the problem?
* jdub has issue with french one!
<seb128> pitti: <doko> daniels, seb128: just did a hoary->breezy upgrade, I still get the popup in gnome about non-matching X and Gnome keyboard layouts.
<daniels> Diziet: DUDE.
<Robot101> ogra: ver 0.1.2-2ubuntu1?
<jbailey> jdub: Eh.  Dis-le moi en Octobre! ;)
<seb128> jdub: hey. gdm slowness fixed ? :)
<pitti> seb128: ah, I see
<jdub> seb128: yes!
<seb128> jdub: ROCK
<jdub> seb128: i saw you uploaded the canvas fix too
<segfault> Man, Ubuntu in pt_BR is rocking.
<ogra> Robot101, yes.... since some months...
<daniels> Diziet: the only way to input characters for Asian languages is to use input methods, such as scim and uim.  the fact that gecko requires you to set an environment variable to achieve this is neither here nor there.
<seb128> jdub: yeah, as jordi bloged some time ago I need to do uploads, upload something ... anything :p
<jdub> seb128: heh
<Robot101> ogra: really now, it doesn't work
<Robot101> 4,id=103e84b0af000112868955800000066950007
<Robot101> 4,RestartStyleHint=2
<Robot101> 4,Program=GNOME Power Manager
<Robot101> ..
<jbailey> Diziet: I like how the glibc folks have an open bug in their bugzilla that basically says "We don't support end users building glibc  themselves.  Go away".  They take bad bug reports and mark them of duplicates of that one. =)
<Robot101> 4,RestartCommand=GNOME\\ Power\\ Manager --sm-config-prefix /GNOME\\ Power\\ Manager-YBSXVJ/ --sm-client-id 103e84b0af000112868955800000066950007 --screen 0
<Robot101> ogra: ^^ NO :P
<Diziet> daniels: Ah.  Um, that's very lame.  It's still a hopeless bug report.
<doko> pitti, seb128: after the upgrade, language-pack-gnome-de is not installed
<ogra> Robot101, thats why we left it in universe... its simply not ready for more than battery status reporting
<pitti> doko: sure, there is an upgrade note
<daniels> Diziet: a hopeless bug report that I've reopened, in any case; set it to NEEDINFO if you cannot reproduce it and need more information.
<pitti> doko: we can't do it automaticalyl
<seb128> doko: you should get a notify note about it, no?
<jbailey> Diziet: http://sourceware.org/bugzilla/show_bug.cgi?id=333
<seb128> doko: language packs have changed note
<ogra> Robot101, but i hae no problem with it staring in the session
<Diziet> IME trying to extract information from these kind of submitters is a waste of time.
<Lathiat> hrm, gstreamer is defaulting to ESD
<Lathiat> i thought we were defaultking to ALSA
<daniels> Diziet: no, it is not.
<jbailey> Lathiat: esd makes more sense for systems without hardware mixers.
<ivoks> Lathiat: libsdl1.2debian is OSS default, not ALSA too :/
<daniels> Diziet: ot
<daniels> er
<Lathiat> jbailey: but we run dmix
<daniels> Diziet: it's what helps us fix bugs.
<jbailey> Ah do we?
<jbailey> Hmm.
<doko> well, yes ...
<Lathiat> indeed
<Diziet> daniels: MMV.
<Lathiat> and esd with videos ends up with terrible audio sync *all* th etime
<daniels> Diziet: people not knowing first off exactly what bug submitters need does not make the bugs any less relevant.
<jbailey> I should check, my wife's machine seems to still suck for multiple inputs.
<Lathiat> it was alsa at one point
<daniels> Diziet: honestly, if you reported a bug on X, I would not have enough information from you to solve the bug.
<daniels> Diziet: you require specialised knowledge to effectively report bugs on various components, and that's not something we can require off the bat.  it requires gentle guidance.  if you need any kind of specific information from the reporter, reply and ask for that exact information.  replying with a generalised URL is pointless and insulting.
<Diziet> I disagree.  The generalised URL contains sensible and useful advice that anyone should follow when giving a bug report.  It's unfortunate that our bug reporting channel makes that harder (did I mention how much I hate bugzilla?) but IME people who submit such short and content-free
<Diziet> bug reports are rarely able to produce more and useful information.
<seb128> carlos: does rosetta force the encoding on a file for export?
<carlos> no
<carlos> seb128, we use the one that the last .po had when was imported
<doko> jbailey: what do I have to do to enable usplash after an hoary->breezy upgrade? it's not enabled automatically
<daniels> Diziet: again, if there was a report following that guide to the letter, would not be a useful bug for xorg.
<jbailey> doko: Install it, and reinstall the kernel
<jbailey> Or dpkg-reconfigure the kernel, rather.
<Diziet> Have you actually read what it says ?  It doesn't say anything particularly specific.
<daniels> Diziet: my attitude is not to tell them to piss off and magically learn how to report bugs that will be useful with zero interaction, but to instruct them how, so they get their bugs fixed, and my software becomes more useful to people who, say, don't speak english.
<seb128> carlos: zyga says that tsclient/ru.po encoding is broken on the source package, on rosetta but correct on export
<doko> jbailey: so this not supposed to work out of the box?
<jbailey> doko: Because of upgrade ordering, there's only so much we can do.
<daniels> Diziet: so how are people supposed to know that they have to attach Xorg.0.log and probably xorg.conf, to enable me to solve their bug?
<infinity> Diziet : When someone reports a segfault in software, it's a bug, whether you like the report or not.  There's not such thing as an "invalid segfault".
<jbailey> doko: For dapper, we'll force the initramfs to be regenerated.
<infinity> Diziet : Asking them for help debugging it and digging deeper is not generally considered a bad thing.
<daniels> Diziet: even if they're relatively smart and give me a backtrace, a BT showing that it's hung in drmCommandNone() is utterly useless, because I need to know what command was submitted *before* that that has wedged the chip.
<daniels> Diziet: my point is that you need specialised knowledge to properly report bugs, and you cannot just handwave that away.
<jbailey> doko: There's an update-initramfs tool in Breezy that could be used, but it requires some changes in the kernel scripts that Ben and Fabio wanted more than a couple weeks of testing  on.
<Diziet> What's backtraces got to do with it ?
<daniels> Diziet: sigh, my point is about bug reporting in general.
<carlos> seb128, hmm the procedure is: we get the encofing field inside the .po file and recode the content of the .po file and recode it from that one to UTF-8
<seb128> carlos: so you recode it
<carlos> seb128, then, on export, we get that encoding and recode the UTF-8 into that  encoding
<daniels> Diziet: the point is this -- if you require more information, ask for it.  you might imagine that a full bug report with a backtrace attached is enlightened, and useful.  it may not be.
<carlos> seb128, yes, to store it into our database
<Diziet> inf: There are segfaults that are caused by unsupported software.  Obviously I agree that segfaults are bugs (with a few obscure exceptions).
<carlos> seb128, but on export time, we recode it again
<daniels> Diziet: however, the answer is not to say 'well, clearly you're on acid, and you're not actually experiencing any problems'.  the answer is to go work out what you need to find out to fix the bloody thing.
<seb128> carlos: how do you know the encoding? using the charset= from Content-Type: ?
<Diziet> You seem to be under the misapprehension that bug reports are a scarce resource.
<carlos> seb128, yes
<lifeless> Diziet: bug fixes are scare
<daniels> Diziet: scarce, no.  useful, yes.
<seb128> carlos: how do you recode it on export?
<Diziet> daniels: No, not all bug reports are useful.
<lifeless> Diziet: closing bugs before you determine the cause means you have lost that fix.
<Diziet> lifeless: Quite so.
<lifeless> :)
<carlos> seb128, using python, from UTF-8 to the encoding from Content-Type
<daniels> Diziet: if it transforms someone's system to 'utterly useless' (let's assume that Chinese people actually want to communicate in Mandarin) to 'wonderful', then we should bust our arse to fix that.
<Diziet> Err, no.  It's quite likely to recur.
<daniels> Diziet: not to say 'please come back when you have a clue'.
<Lathiat> pitti: about?
<daniels> Diziet: yes, and when it recurs, people will find the now-open report, and contribute to that.
<daniels> Diziet: if not, you can close one as a dupe of the other.
<pitti> Lathiat: right over here :-)
<Diziet> daniels: Could you do me a favour and read Simon's essay and then tell me if you think that it was helpful advice ?
<Lathiat> pitti: i thought we were using alsa by default?
<doko> fabbione: ping
<infinity> Diziet : Even a bug caused by unsupported (in this case, Universe) software isn't "INVALID", it should just be reassigned to that software, or you should kindly ask the submitter to submit a bug in Malone against the affected product (but only AFTER you've confirmed the segv isn't happenning deep in the bowels of firefox or GTK, or something we DO support)
<Kamion> There's a case for closing bugs when people don't reply to requests for information for a long time. I'm not so sure about closing them straight off due to incomplete information.
<daniels> Diziet: i've read it, and it's very helpful advice.
<pitti> Lathiat: as backend, yes
<daniels> Diziet: it is not, however, justification for closing bugs off the bat.
<Lathiat> pitti: for esd?
<Lathiat> pitti: having esd as sync for gstreamer sucks, because the a/v sync is horrid 
<pitti> Lathiat: we use libesd-alsa0, yes
<Diziet> daniels: So you'd support me saying `please read this essay, and submit more information, and then I will look at your report' ?
<pitti> Lathiat: I know, but tell me something better
<Kamion> They can always be marked NEEDINFO and you can save a query for your own bugs minus those marked NEEDINFO, if you don't want to see them during triage.
<Lathiat> pitti: set the gstreamer sink to alsa?
<pitti> Lathiat: polypaudio isn't there yet, and it is pretty much abandoned upstream
<daniels> Diziet: debbugs has a + moreinfo tag.  bz has a NEEDINFO status.  there is a reason why bugtrackers have these sort of statuses, rather than closing it with 'fuck off and come back later, or preferably not at all'.
<Lathiat> pitti: if esd is only going to use alsa anyway, and we're always using dmix
<Lathiat> pitti: it cant' get any worse
<pitti> Lathiat: and alsa dmix fails for many people
<Lathiat> pitti: dmix isnt configured out of the box anymore?
<pitti> Lathiat: I'll try direct alsa again for dapper
<ogra> daniels, malone has no such status ;)
<daniels> Diziet: depends.  if you can reproduce that bug yourself, then no, I would not.  if you genuinely need more information in order to reproduce it, then yes, go ahead.
<pitti> Lathiat: dmix *is* used
<Lathiat> pitti: does dmix only screw up when you actually have more than 1 stream then?
<pitti> Lathiat: but for the cases where it doesn't work (still too many), folks still get mixing through esd
<pitti> Lathiat: it seems so
<Lathiat> pitti: ah ok
<Lathiat> pitti: makes sense then
<Lathiat> i thought when dmix was broken, it just plain didnt work
<pitti> Lathiat: for dapper I'll immediately drop it and urge people to report bugs
<Lathiat> pitti: ok, nps
* azeem just distributed his remaining Hoary CDs at the Microsoft Security workshop in our faculty building
<pitti> Lathiat: then folks can manually install esound if they really need to
<Lathiat> pitti: well, having esd running isnt so bad
<Lathiat> pitti: having it used by gstreamer is what sucks :)
<Diziet> daniels: Well, obviously if I can reproduce it I'll try to fix it (or decide it's too hard, or look for it upstream, or whatever).
<pitti> Lathiat: right, we could switch the gstreamer default for dapper
<pitti> Lathiat: makes it easier to switch
<Lathiat> pitti: yep, but keep esd
<Lathiat> pitti: for sound effects/gnome apps that use it direct
<Lathiat> pitti: and then if people have issues, they can easily switch to it
<Lathiat> pitti: or we could even employ some kind of blacklist
<pitti> Lathiat: yes, as long as dmix sucks
<Lathiat> (or whitelist)
<daniels> Diziet: so why did you mark it as 'go away' before you even attempted to reproduce it, decide it's too hard, or look for it upstream?
<Lathiat> pitti: the other annoyign thign si taht dvd playback with gstreamer is totally broken with esd
<Lathiat> as in it hardly works
<Lathiat> the video slows right down, etc
<Lathiat> and when it does work its verry jittery
<Kamion> daniels: (he did attempt to reproduce it and couldn't, as the bug log indicates)
<Diziet> daniels: Well, I used the information provided to try to reproduce it (if you'll read what I wrote you'll see that).  Of course it WFM.
<pitti> Lathiat: right; for computers where dmix works, people can switch to alsa
<Kamion> Lathiat: I'm working on that NTFS thing now
<Lathiat> pitti: yup, i know, just throwing that argument on the end :)
<Lathiat> Kamion: sweet, thanks
<Lathiat> Kamion: if you need any help, shoot, its fairly generic tho
<Kamion> Lathiat: nah, I have it fixed already, just needs a bit more testing here
<Lathiat> Kamion: cool
<Lathiat> Kamion: let me know if you upload it/get a cd with it and i'll try it out
<Kamion> Lathiat: the problem is approximately "partman has no support for ntfs other than quickly-hacked-in resize support"
<Diziet> Anyway, I should go and do something useful rather than arguing on IRC.  I could go try to fix that gs weirdness.
<pitti> Lathiat: yes, we have to find a smooth transition
<Lathiat> Kamion: ah, ok
<Lathiat> pitti: yup
<Diziet> Oh, before I do ...
<Lathiat> Kamion: yeh that resize support is horrid :P)
<Kamion> Lathiat: so the fix is kind of adding a new feature, which is tricky at this point; but I think it's safe
<Diziet> Kamion: I didn't get around to 14236.  (NTFS custom mountpoints._)
<Lathiat> it just did something, and i had no idea if it worked, or what :)
<Diziet> Is that what you're talking about now ?
<daniels> seb128: yeah, it's german-specific.
<Lathiat> was afraid i might have trashed mjy windows by just truncating the partition :)
<Diziet> It didn't seem vitally important so I kind of let it slide ...
<Kamion> Diziet: Yes, it is. No problem; it turned out to be closely associated with another one of my bugs, and easy enough to fix once I realised what was going on
<Diziet> (Just after I took it, mdz made me ffox maintainer.)
<Diziet> OK.  Shall I assign it back to you ?
<Kamion> Diziet: I just did
<Diziet> Oh, OK.
<Diziet> Thanks.
<Kamion> Diziet: It wasn't vitally important in itself, no. A related symptom was that NTFS partitions didn't get automounted, unlike FAT partitions, which was somewhat more important - I only realised today that they were connected.
<Diziet> Yes, that sounds more serious, indeed.
<Diziet> `Ok, it's the old problem with the flash plugin, i made the page not crash by putting export XLIB_SKIP_ARGB_VISUALS=1 at the beginning of /usr/bin/firefox.'  I do feel like I've come in halfway through lots of these conversations ...
<daniels> Diziet: that's a flash bug that xlib exposed when we added argb32 visuals.
<daniels> Diziet: basically it just assumes that the default visual exposed will have 0-bit alpha, instead of the 8-bit visual at the top of the list when you have composite.
<daniels> macromedia are the suck, is the executive summary.
<daniels> (that environment variable was added especially for flash.)
<Diziet> Right.  Um, shouldn't we organise a workaround ?
<fabbione> doko: pong
<Diziet> The whole flash thing is pretty evil anyway, but if we're going to `support' it (plugin finder, etc.) then it should generally work.
<fabbione> Diziet: yo
<Diziet> fabbione: Hello.
<fabbione> Diziet: see /msg :)
<fabbione> just a few notes
<doko> fabbione: when should the OOo build for sparc finish?
<daniels> Diziet: arguably the firefox wrapper script should export that variable, yes.  but we support proprietary software unfortunately, which is just something we all have to deal with.
<fabbione> doko: -ENOCLUE
<fabbione> doko: probably tomorrow
<doko> which module is it currently building?
<fabbione> Making: ../../unxlngs.pro/slo/styleexp.obj
<Diziet> So another question I'm going to ask is: what effect will it have on the rest of firefox if I just set that variable in the wrapper script ?
<fabbione> if it tells you anything
<Diziet> NB that firefox invokes all kinds of stuff eg other plugins, xpdf, image viewers, ...
<daniels> Diziet: none
<Diziet> So what are these new visuals _for_ ?  I mean, which applications use them ?
<daniels> Diziet: if things are relying on argb32 visuals right now, they're going to be completely broken
<Diziet> Or to put it another way, why don't we just turn them off globally ?
<daniels> Diziet: anything which needs to do compositing.  it's just that extra 8 bits of alpha.
<Diziet> (Not that I'm suggesting we should, but ...)
<daniels> Diziet: because some apps use it.  but not firefox.
<doko> fabbione: find a line where you see ooo-build/build/src680-m129 and the dir following that path is the module
<Kamion> daniels: stuff like xcompmgr?
<Diziet> How do you know that none of those apps will be run from firefox if you don't know what they are ?
<fabbione> doko: xmloff
<Diziet> Sounds like eg gimp might well use it.
<daniels> Kamion: xcompmgr doesn't, but it enables it.
<Diziet> I'd have to check the mime bindings to see if firefox can ever run gimp.
<Diziet> An alternative would be to try to have firefox arrange for only plugins or perhaps only this plugin to run with that variable.
<daniels> Kamion: basically ... it means the alpha bit actually has an effect.  but unless you're using the composite extension (either xcompmgr, or asking the server to do its own internal compositing), it just acts as if all the alpha bits are set anyway.
<doko> fabbione: nearly the half ...
<fabbione> doko: ok. than i expect to finish by tomorrow morning
<fabbione> (take into account it's building in parallel with other stuff)
<fabbione> i can't take the risk of killing the buildd for nothing
<fabbione> not at this point in time
<daniels> Kamion: so if you rely on the alpha bit being meaningful atm (e.g. if you're using subwindows and you're relying on visibility down to the parents), you're stuffed anyway.
<fabbione> doko: let say within the next 10 hours it should finish.. i started it this morning at 7am
<daniels> Kamion: but it's a graceful degradation -- you just don't expose that visual.  so when your app queries xlib for the available visuals, you just don't find anything which exposes visuals.
<fabbione> so you can make your calculation
<doko> fabbione: hmm, ok, I'll delay my upload
<fabbione> doko: there is also another point.. openoffice-org2-common Depends: oo2-java
<fabbione> but sparc doesn't build java
<daniels> s/exposes visuals/exposes anything with alpha/
<Diziet> daniels: So why wouldn't it be OK to set this variable globally ?
<doko> fabbione: ok, I'll change that
<fabbione> doko: is that addressed somehow?
<fabbione> doko: just verify that
<fabbione> doko: because according to debian/rules JAVA=no for sparc
<daniels> Diziet: because we don't need it, and it limits our ability to use compositing globally later.
<daniels> basically, one of the main reasons our desktop is shit right now is that we don't use composite.  nothing to do with transparency and bling, just the fact that we do Exposes back to the client window to redraw.
<Diziet> So does setting it in the firefox wrapper script.  Remember that firefox might run pretty much any program from the mime system, or anything the user selects as `open with ...'.
<bddebian> Morning
<daniels> there's only one situation we know of at the moment where exposing an argb32 visual breaks, and that's flash.  so let's just work around it for flash.
<daniels> Diziet: sure, but that's something we'll just have to suck up.
<Diziet> Seems like it would be strange and flakey to me and we risk breaking something else.
<segfault> pitti: any plan for the next langpack release?
<pitti> segfault: at Monday
<doko> fabbione: ?? openoffice-org2-common does not depend on oo2-java
<Diziet> I wonder if firefox already has some kind of kludge hook thing for plugins.  If not maybe it should do.
<segfault> pitti: nice!
<Kamion> Diziet: s/breaking/failing to fix/, I think?
<fabbione> doko: sorry right...
<daniels> Diziet: well, firefox is your baby, so it's your call.  but it's basically 'breaking flash' vs 'not breaking flash'.
<daniels> trust me, if your app cannot deal with not having an argb32 visual, it's fundamentally fucked anyway.  it won't work with >95% of deployed X servers today.
<Diziet> kamion: True.
<Diziet> I'll see if I can find somewhere more selective to put it.
<Diziet> If not I'll try it out in the wrapper script.
<Diziet> Not that I have an X server which can do argb32 anyway, but.
<Diziet> What's the visual name in X11-speak ?
<Diziet> JOOI.
<daniels> Diziet: it's called a 'visual'
<Diziet> No, I mean, like TrueColor and DirectColor.
<daniels> each visual has a visual ID, which is variable per-server, per-start, et al.
<Diziet> The `class'.
<daniels> true, IIRC.
<daniels> er, s/true/direct/
<daniels> i'm pretty sure it's not true or pseudo.
<daniels> since each of argb has 8 bits, so you don't need to go through a clut
<Diziet> Um, so does this reuse some mbz bits in the visual info structure ?
<daniels> no
<Diziet> Because my xdpyinfo here doesn't show any spare space for alpha channel.
<zyga> is it possible to have ubuntu-desktop-no-openoffice.org
<Diziet> I mean, it doesn't print `alpha mask: 0x00' or some such.
<zyga> so that people that don't need it can get rid of all that java packages 
<Kamion> zyga: no, sorry
<Kamion> zyga: remove ubuntu-desktop
<tepsipakki> kamion: mangling the initrd helped.. now I suppose the usual preseed-tricks apply to /preseed.cfg, that is you can load other files too?
<Kamion> tepsipakki: I don't understand the question?
<tepsipakki> kamion: sorry... d-i preseed/include_command works?
<tepsipakki> kamion: from the /preseed.cfg on the initrd
<jbailey> tepsipakki: Oh!
<jbailey> Your swap partition isn't in the same volume group as your root volume.
<tepsipakki> duh
<tepsipakki> should be
<tepsipakki> the poo-swap was a joke..
<jbailey> Oh.
<jbailey> Hmm
<jbailey> tepsipakki: I had apparently missed a step.  break stops before lvm is activated, my bad.
<tepsipakki> ah
<jbailey> tepsipakki: You need to run /scripts/local-top/lvm first
<Kamion> tepsipakki: yes
<tepsipakki> jbailey: ok, I'll test it now
<jbailey> tepsipakki: Cool, thanks.
<jbailey> tepsipakki: Do you have another box you can stay on IRC with handy?
<zyga> Kamion: how are seeds generated?
<tepsipakki> jbailey: yes
<jbailey> tepsipakki: Lovely.  Lemme know when you're at the break point
<tritium> Kamion, sorry I missed your pong.
<tepsipakki> jbailey: ok, just ran /scripts/local-top/lvm
<tritium> Kamion, I emailed elmo for a sync, so I'm taken care of.
<bddebian> Heya tritium
<jbailey> tepsipakki: 'kay.  Did the /dev/mapper stuff appear?
<tepsipakki> jbailey: nope
<jbailey> tepsipakki: Is your harddrive visible in /dev ?
<jbailey> Like /dev/hda#? 
<jdub> mako: ping
<tepsipakki> f*ck, us-layout bit me
<mako> jdub: dude
<mako> jdub: whats up?
<jdub> mako: aha! :)
<mako> jdub: where are you?
<jdub> mako: was stalking your front door last night :-)
<jdub> mako: hotel in cambridge
<mako> jdub: damnit
<daniels> tepsipakki: us layout is love
<jdub> dude, your doorbell is a *phone*
<mako> jdub: yes i know
<tepsipakki> daniels: well, it broke my shell ;)
<daniels> tepsipakki: ...
<mjg59> jdub: Hello?
<jdub> yo mjg59 
<mako> jdub: you need to call me and/or mika.. it's in italics.. i got your message but didn't know how to get back to you
<mako> jdub: did you get in the building at all?
<daniels> mjg59: also -- 141 or 146?
<jdub> mako: nup
<tepsipakki> daniels: this is the initramfs-shell..
<daniels> mjg59: bitch
<mjg59> daniels: 146
<mako> jdub: blast
<jdub> mako: yeah, don't have raoming
<daniels> mjg59: okay
<daniels> mjg59: represent
<mako> jdub: mika is there right now
<tepsipakki> jbailey: put zsh in the image ;)
<mako> jdub: i thought you were coming today
<mjg59> jdub: We need to arrange timings for next week
<jbailey> tepsipakki: Ahahahahah
<jbailey> no
<jbailey> =)
<jdub> mjg59: yeah
<jdub> mako: aha
<jdub> mako: well, i might be having lunch with luis
<tepsipakki> jbailey: well atleast the same settings as in the installer, it has completion too =)
<mako> jdub: that's fine.. i have lunch with wikipedia people
<bddebian> daniels: Isn't there a metapackage that provides libxau-dev, libxmu-dev, etc?
<daniels> bddebian: no
<mako> jdub: i can probably get off early afternoon.. this evening is sushi feast
<bddebian> daniels: Crap, OK, thx
<mako> jdub: are you in the hotel the whole time or ONE NIGHT ONKLY
<mako> ?
<daniels> bddebian: xlibs-dev doesn't provide any of the crap that used to be in xlibs-static-dev
<jdub> mako: was hoping just the night
<mako> jdub: ok good
<tepsipakki> jbailey: ok finally.. yes my /dev/hd* is visible
<jbailey> tepsipakki: Okay.  Do you have any partial lvm volumes that I might corrupt?
<tepsipakki> jbailey: tmp?
<jbailey> tepsipakki: Sorry, I'm being unclear, too many things at once.
<jbailey> tepsipakki: You don't have removable drives, right?
<tepsipakki> no
<jbailey> Cool.
<jbailey> Please do "vgchange -ay" then.
<tepsipakki> failure to communicate with kernel device-mapper driver etc
<tepsipakki> jbailey: i don't think the lvm-script actually did anything.. no modules got loaded etc
<tepsipakki> if /sys/module is to be trusted?
<tepsipakki> or /proc/modules
<Lathiat> Kamion: thanks
<Lathiat> Kamion: (ntfs)
<Lathiat> i'll try out the next dail
<jbailey> tepsipakki: Hmm
<jbailey> modprobe dm-mod
<jbailey> Then try the vgchange -ay
<jbailey> Let's brute force this first until it works, then we'll make it right. =)
<tepsipakki> yes, 5 logical volume(s) ..... active
<tepsipakki> and /dev/mapper/* has them
<Riddell> mvo: you had a better kdm patch for me for console fonts?
<tepsipakki> jbailey: umm, I have to leave rsn, but will be back in, say, 5-6 hours
<jdub> mjg59: so 12th is formal hall, 14th is GLUE
<mjg59> jdub: And release party is when?
<jbailey> tepsipakki: Cool, thanks.
<jdub> oh, i thought you wanted to do release party at one of those?
<tepsipakki> jbailey: ok, see you then!
<mjg59> jdub: Uh, no - that's being organised separately
<mjg59> You probably want to speak to Scott
<jdub> scott for...?
<mjg59> Finding out what's being organised
<jdub> for which?
<mjg59> The release party
<jdub> oh
<mjg59> Since Mark generally hosts something
<bddebian> Did someone say party?? :-)
<jdub> maybe that'll be the 13th
<j^> did anyone look into this? http://bugzilla.ubuntu.com/show_bug.cgi?id=15309
<j^> have the same problem on ibm X30, black screen + pointer, desktop is only visible aber switching to console and back
<daniels> j^: can you trigger same with xset dpms force off, then xset dpms force on?
<bddebian> daniels: Is libxaw-headers supposed to provide libXaw.so since is replaces libxaw8-dev ??
<j^> daniels no,xset dpms force off;xset dpms force on;
<j^>  the desktop is back once i move the mouse
<daniels> bddebian: no, you want libxaw7-dev
<bddebian> daniels: OK, thx
<daniels> j^: fuck
<daniels> j^: does disabling gl screensavers help it?
<j^> i have blank only as screensaver
<daniels> hm
<Lathiat> hrm, i have a package with a build-dep on xlibmesa-gl-dev, it says it cant find it, but x11proto-gl-dev replaces it, but with that installed, it still doesn't see the dep as satisfied (so i cant build-dep it) is that an apt bug or proper behavior or what?
<Kamion> replaces != satisfies-dependencies-on
<Lathiat> Kamion: ah ok
<Kamion> you want to look for something that provides it
<Lathiat> oh i have that
<Lathiat> just wondering why it offered that solution btu wasnt happy wiuth it
<Lathiat> how i have to manually paste 10 lines of build-deps ;p
<Kamion> 'libgl1-mesa-dev | libgl-dev' is probably a suitable replacement build-dep?
<Lathiat> Kamion: yeh thats not the problem
<Kamion> that apt message has always annoyed me; it fosters misunderstanding of Replaces
<Lathiat> the problem was getting the rest installed so i can test the package :)
<Lathiat> just inconvenient thats all :)
<daniels> libgl1-mesa-dev | x11proto-gl-dev | libgl-dev is the canonical b-d
<Lathiat> bah
<Lathiat> daniels: you know our glu page doens't say that
<Kamion> daniels: really? I'd've thought something more like 'libgl1-mesa-dev | libgl-dev, x11proto-gl-dev | libgl-dev'
<Lathiat> it was just libgl1-mesa-dev | libgll-dev
<Lathiat> last check
<Lathiat> *libgl-dev
<daniels> Kamion: oh fuck
<Lathiat> https://wiki.ubuntu.com/MOTUGLUTransition
<daniels> libgl1-mesa-dev | xlibmesa-gl-dev | libgl-dev, x11proto-gl-dev
<daniels> but you shouldn't be requiring x11proto-gl-dev, I don't think
<daniels> handwaving amidst the bongsmoke
<Lathiat> i hope not :\ 
<Lathiat> libgl1-mesa-dev depends on it
<Lathiat> as does glu1-mesa-dev
<bddebian> bongsmoke?? w00t
<daniels> yeah
<daniels> long story
<Lathiat> daniels: so, which one is it? ;p
<daniels> i don't know, and it's too late on a friday night to be caring about work
<Lathiat> heh
<Lathiat> Kamion: any insight? :)
<Kamion> look at the file lists and see which makes sense
<elmo> pitti: ?
<pitti> elmo: yes?
<elmo> pitti: can you do the sip main inclusion review if you haven't already?
<elmo> uninstallables == teh suck
<pitti> elmo: I cleared the list today and sent mdz a report
<pitti> elmo: everything is ready to be promoted
<elmo> ok, great thanks
<pitti> elmo: I also did some seed adjustments to clean up anastacia output a bit
<SteveA> mjg59: ping
<mjg59> SteveA: Hi
<pitti> seb128: is it known upstream that the calendar selector in the clock is slightly broken? regardless on which day I click, I always get "today" open, not the day I clicked on
<SteveA> mjg59: hi.  running breezy (up to date as of 1 week ago) on my laptop.  hangs on suspending.  hibernates, but hangs on coming back to life again. 
<SteveA> mjg59: something you can help with?
<SteveA> i'm updating to the latest breezy now
<mjg59> SteveA: Yes, grab a later acpi-support package
<seb128> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=11336 / http://bugzilla.gnome.org/show_bug.cgi?id=162305
<pitti> seb128: thanks
<seb128> np
<seb128> elmo: please sync gnome-blog from Debian
<torkel> seb128: do you want me to file evolution bugs in b.u.c even though I already have filed them upstream?
<seb128> torkel: no, why would you do that ? :)
<torkel> seb128: because it crashes evo? :-)
<seb128> that has to be fixed upstream
<torkel> seb128: and to make it easier for you to track it? :-)
<seb128> fill it to bugzilla.ubuntu.com if you have a really trivial patch that fixes an issue
<seb128> other way 5.10 is frozen
<torkel> sure
<seb128> I don't want to track every single upstream issue
<seb128> I'm happy if they fix them upstream and we get the fix for free with the new tarballs
<seb128> 5.10 is frozen, and I'm not going to patch unstable packages anyway
<bddebian> seb128: You updated gpdf from upstream?
<seb128> bddebian: no, I've not touched this package since hoary since we use evince now
<seb128> bddebian: why?
<bddebian> seb128: It FTBFSs
<seb128> maybe gcc4 ?
<bddebian> Yes
<johnm> fabbione: ping.
<mdz> morning
<jdub> yo mdz
<seb128> hi mdz
<fabbione> johnm: pong?
<johnm> fabbione: mind if I PM?
<fabbione> johnm: not at all, but i am quite busy, so i might not be extremely responsive
<bddebian> Morning mdz
<Riddell> Znarl, elmo: any news of the kubuntu torrents and mirroring?
<Znarl> Riddell : Yep, we're still working on it.  Sorry for the delay.
<Riddell> Znarl: ok, good luck
<bddebian> seb128: Do you think we should morgue gpdf instead of fixing it?
<seb128> so people may still use it
<seb128> it's not fixed by debian ?
<bddebian> OK
<bddebian> seb128: They are still at 2.8.something
<zoot_> hi, anyone here working on xfce packages?
<seb128> bddebian: upstream is not really working on it since evince
<seb128> doesn't mean than nobody uses it
<bddebian> seb128: Fair enough, I'll try to fix it
<janimo> zoot_, I am
<zoot_> janimo: hi, have u guys moved or changed the way xfce reads kioskrc?
<janimo> zoot_, come over to #xubuntu
<zoot_> janimo: thx, c u there
<sivang> hmm
<sivang> Unpacking replacement nvidia-glx-legacy ...
<sivang> Errors were encountered while processing:
<sivang>  /var/cache/apt/archives/eclipse-pde-common_3.1-10ubuntu1_all.deb
<sivang>  /var/cache/apt/archives/linux-image-2.6.12-9-686-smp_2.6.12-9.22_i386.deb
<sivang>  /var/cache/apt/archives/linux-image-2.6.12-9-686_2.6.12-9.22_i386.deb
<sivang> E: Sub-process /usr/bin/dpkg returned an error code (1)
<sivang> pitti: still upgrading , when finished I will try to reproduce 17175
<mdz> Riddell: your promotions to main are now processed
<mdz> Riddell: you'll probably want to roll new kubuntu-meta
<mdz> Riddell: you may or may not need to wait for the next cron.daily at :03
<Kamion> mdz: we should add libxp{-dev,6-dbg} to "rescued from extra", right?
<elmo> how did libxp end up coming back?
<mdz> +cat >&4 <<SECTION
<mdz> +ection "InputDevice"
<elmo> I'm sure it's been demoted at least once
<mdz> that can't possibly be right
<Kamion> elmo: some commercial apps needed it
<elmo> ah
<Kamion> ones we were trying to get certified
<mdz> elmo: e.g., java
<pitti> Hi mdz
<mdz> pitti: hi, thanks for knocking out the seed syncage
<Riddell> mdz: thanks
<Kamion> elmo: (#15739)
<bddebian> Anyone have any idea why xprint would bring in it's own Printstr.h instead of using it from /usr/include/X11/extentions/ ??
<mdz> bddebian: because it's insane
* bddebian decides to rip out that -I
<mdz> Kamion: yes
<bddebian> Heya madduck
<mdz> Kamion: there's a bunch of stuff in anastacia that should be added there, as long as you're at it
<\sh> hmm....
* \sh needs some syncs...
<mdz> I've just run cron.sync and updated http://people.ubuntu.com/~mdz/anastacia.txt
<mdz> aspell-es is going away
<mdz> pretty much everything else there should be rescued
<mdz> with the possible exception of schoolbell. ogra?
<Kamion> mdz: xorg> 'Option        "Device"        "/dev/input/event0"' doesn't look like a valid shell command, either ...
<Kamion> mdz: ok, I'm checking the d-i stuff too - I demoted ufs-modules-*
<Riddell> I'll rescue the pykde/pyqt build-deps
<Kamion> mdz: weren't we killing mozilla-openoffice.org?
<mdz> Riddell: hmm? germinate should handle those fine
<mdz> Kamion: hmm, yes, I believe doko said it didn't work
<Kamion> right, please don't list build-deps explicitly
<Riddell> python-kde3-doc and libqscintilla-doc should be kept if we're having the actualy pacakges in main
<Kamion> yes, those aren't build-deps though :-)
<Kamion> Riddell: add them to the appropriate subsections of "Rescued from Extra" in supported
<\sh> Riddell: u don't want to have pykde/pyqt in main 
<wasabi_> Hmmm.
<Diziet> Steaming crack-monkeys !
<Diziet> # If this is an "official" build, try to build everything.
<Diziet> # I.e., don't exit on errors.
<wasabi_> umount -l in the initramfs doesn't seem to work
<Diziet> ifdef BUILD_OFFICIAL
<Diziet>     EXIT_ON_ERROR               = +e
<wasabi_> =(
<Kamion> \sh: kde-guidance depends on python-kde3, and is in the Kubuntu desktop seed. So yes, we do
<SteveA> mjg59: suspend is better now.  it worked, but the screen backlight is off on resume.
<mjg59> SteveA: Did it ever work?
<SteveA> mjg59: did what ever work?
<SteveA> suspend just didn't work before i upgraded just now
<\sh> Kamion: no we don't...because the last patches I made are not upstream, and upstream is refusing to take them, they're at least 1 year old...and I don't see any serious support for python-kde3 in main...honestly
<mjg59> How about in Hoary?
<SteveA> before, it didn't even fully suspend
<SteveA> i didn't have this laptop for hoary
<mjg59> Ok
<Kamion> \sh: it's a bit late to rip stuff out
<mjg59> What model is it?
<\sh> Kamion: so with next release cycle I will break main :(
<Kamion> I think maintainers are entitled to refuse patches, too, so that alone is not a "must be kicked out" criterion
<SteveA> mjg59: dell latitude x1
<SteveA> intel 955 graphics chip i think
<doko> mdz, Kamion: well, it should go to universe for now, it does work, but needs explicitely to be enabled in the OOo2 preferences
<\sh> Kamion: no..upstream (real upstream) is not interessted in python-kde3 it's only a "add-on" src support for this is quite annoying...
<mjg59> Odd. Should work fine (and does for other people)
<mdz> doko: your python-defaults upload  seems to have inadvertently included some local changes from June
<SteveA> mjg59: is there a command to turn on the backlight?
<\sh> Kamion: I don't say this to produce more work...but when I patched python-kde3 to fix some really serious bugs, I used patches which are at least one year old..so right now, we have a really good running version, which is better then in any other distro..but will break again in dapper
<Kamion> mdz: do we need python2.3-moinmoin? I'm assuming that if we can demote old modules, we should
<\sh> Kamion: as I said just now to Riddell , python-sip4-qt is ok for main, but not python-kde3
<mjg59> SteveA: No
<mjg59> It's very machine specific
<SteveA> mjg59: aha... i touched the brightness control, and it came back
<mjg59> Ah, interesting
<Riddell> \sh: why will is break again in dapper?
<mdz> Kamion: most of them are useful with zope, but perhaps not moinmoin 
<Kamion> \sh: it is *too late*
* SteveA tries again
<Riddell> Kamion: thanks for fixing the seeds merge
<Kamion> Riddell: np
<Kamion> \sh: removing desktop stuff between RC and release isn't generally OK
<\sh> Riddell: because the new releases are completly different...and we have to work on the "patches" which will make python-kde3 running again and not segfaulting again 
<SteveA> mjg59: yep... backlight is off after resume.  back on if i nudge the brightness a bit.
<mjg59> SteveA: Odd
<Kamion> SteveA: do you think python2.3-moinmoin is useful in main (we have the python2.4 version)?
<\sh> Kamion: I only tell you my concerncs :) 
<Kamion> \sh: if desktop applications didn't depend on it, I'd listen
<SteveA> Kamion: i don't think so.  we should be encouraging people to use python 2.4.
<doko> mdz: reverting ...
<mdz> doko: already did
<Kamion> Migrated python2.3-moinmoin_1.3.4-6ubuntu1_all.deb from main to universe in breezy suite.
<mdz> Kamion: refreshed anastacia.txt
<mdz> Kamion: did you commit your seed changes? if so, we should cron.sync
<Kamion> I always just run anastacia anyway
<SteveA> mjg59: what information do you want to see in a bug report about this?
<Kamion> mdz: haven't done all of them yet
<Kamion> fabbione: do we want to support the iseries kernel?
<fabbione> Kamion: good question.. i never heard of anybody testing them..
<fabbione> so i guess not really
<SteveA> Kamion: is there much python2.3 stuff in main?
<pitti> carloooooos
<Kamion> SteveA: no; python2.3, python2.3-dev, plus eight other module packages
<Kamion> well, seven module packages and python2.3-sip4-dev
<Kamion> fabbione: ok, I'll demote them
<mdz> SteveA: if there are python2.3 modules which ought to be in main, please tell us
<SteveA> mdz: i'm really thinking the other way
<Kamion> SteveA: otherwise, we have docutils, imaging, numeric, sip4-qt3, tk, xml, and zopeinterface, all pulled in by dependencies and/or build-dependencies
<doko> SteveA: it's only zope2.8, which needs it
<SteveA> mdz: do you have a good reason that python 2.3 is in main at all?  
<mdz> SteveA: zope
<SteveA> aw poo
<SteveA> this has been an issue for the zope community
<fabbione> Kamion: fine for me
<SteveA> the zope3 people want to use python 2.4 for various good reasons
<SteveA> but zope 2.8 is stuck on python 2.3 until some scary "author python code through the web" features get a security audit for python 2.4
<doko> SteveA: yes, they can. but there's still no securtiy audit done for zope 2.x running with python2.4.
<SteveA> so, zope3 officially still supports python 2.3, although everyone uses it with python 2.4
<SteveA> so, don't see any point nin python2.3-sip-dev really
<jsgotangco> k good night
<SteveA> docutils and imaging and numeric i can see a point for, given zope
<Kamion> it's all there because something depends on it
<Kamion> none of it is explicitly seeded
<SteveA> i see
<doko> Kamion: I think, python2.3-sip-dev is a mistake, pulled in by Riddell'ish stuff
<SteveA> mjg59: hibernate works, but resuming from hibernate hangs on a text console sayig "swsusp: Need to copy 43534 pages" at the end
<pitti> SteveA: are you interested in evaluating bugs in the Rosetta hoary output?
<pitti> SteveA: just typed a mail to carlos, shall I CC: anybody?
<doko> Kamion: python2.3-sip-dev is a b-d for sip4-qt3, so demotion looks fine
<SteveA> pitti: yes please.  also kiko, please
<Kamion> doko: if that were true, anastacia would list it
<Kamion> it does not
<Kamion> doko: sip4-qt3 is in main
<zyga> re
<zyga> Kamion: did you catch my last question few hours ago?
<Kamion> mdz: what about tagcoll and tdb-tools? they're both tools to access data created by packages in the build-dependency chains of Kubuntu package management tools
<Kamion> zyga: yes. seeds aren't generated, they're written
<zyga> Kamion: great, thank you :)
<wasabi_> jbailey, ping
<pitti> Kamion: tdbtools is mentioned in the report; it's poorly (i. e. not at all) documented
<\sh> doko: it's not the truth...sip4-qt3 produces python2.3-sip-dev which is not the default anymore..now it's python2.4-sip4-dev
<doko> yes, did see that too late
<pitti> Kamion: security-wise it is ok, though
<sabdfl> mdz: can you prepare to freeze bugzilla, and redirect people to malone?
<\sh> hmm...who can I nerve with some sync requests? I don't know if elmo is back and I need at least for one package some more time to test it community wise...
<Kamion> pitti: I'll demote tdb-tools
<bddebian> OK, I give up xprint is a piece of crap
<Kamion> \sh: elmo is back
<\sh> Kamion: ok...so I'll write emails ;)
<Kamion> sabdfl: I asked on #launchpad, but didn't get a clear answer. What are the provisions for making people the owners of packages in Launchpad (and thus Malone), without having to make them the owner of the whole product (in most cases they won't be upstream, may not be the Debian maintainer, etc.)?
<sabdfl> Kamion: owner?
<Diziet> firefox on davis tries to build the i386 asm versions of various stuff because config.guess says ppc64 which falls off the bottom of a switch-a-like in mozilla's makefiles ...
<Kamion> default assignee for bugs, in this case
<sabdfl> in general, the "owner" is now being rebranded "registrant" - it's the person who first told us about a product, or distro, etc
<sabdfl> separately we'll have things like maintainership
<Kamion> ok, I'm not sure of the appropriate terminology
<sabdfl> Kamion: malone doesn't do that right now, it could do
<Kamion> but per-distro maintainership
<sabdfl> please discuss requirements with bradb
<Kamion> that seems somewhat essential
<tseng>  the motu has asked him about it many times
<tseng> and its never made it to his working list it seems
<sabdfl> i know we have spec'd package subscriptions
<sabdfl> default assignee is a good idea
<doko> Diziet: did you start the chroot using linux32 ?
<Diziet> It's not my chroot.  davis, in the colo.
<doko> Diziet: but _you_ call dchroot ...
<Diziet> I can fudge it up for what I want to do now but it's a bit lame really.
<fabbione> Diziet: linux32 
<doko> should be linux32 dchroot ...
<Diziet> OIC.  I still think it's lame but I wasn't blaming the chroot/abi machinery.
<Diziet> I was blaming Mozilla.  But linux32 is a nicer fudge.
<Kamion> sabdfl: ok, I'll mail this conversation to him with comments
<fabbione> Diziet: did you build that test binary on amd64?
<Diziet> Really, there ought to be a standard way in autoconf to get any configure script to use system's config.guess which would just be a small script which would always print a fixed string.
<Diziet> fabb: I thought you said ppc ?
<fabbione> nope..
<Diziet> Oops.
<Diziet> Well, I'll think of it as a learning experience.
<fabbione> the past i gave to you was for general RISC processors
<fabbione> :)
<jdub> hrrrm
<fabbione> but the bug might be the same i am experiencing here
<Diziet> I don't think I have an account on an amd64 in the colo.
<Diziet> Yes, it probably is.
<fabbione> Diziet: concordia
<jdub> if you hibernate after upgrading a kernel
<SteveA> mjg59: hello?
<jdub> your hibernate image is dumped without any warning :(
<fabbione> Diziet: you should have an account there
<jdub> perhaps we should try and boot the old kernel in that case? (dapper)
<Diziet> fabb: Yep.
<fabbione> Diziet: my ppc will arrive while we will be at UBZ :(
<fabbione> exactly the day after i will leave dk
* fabbione sighs
<Diziet> How convenient.
<jbailey> wasabi_: pong
<fabbione> Diziet: i am sort of unhappy.. i was really looking forward to take it with me at UBZ
<fabbione> but well.. that's the delivery time
<Diziet> Oh, a laptop.
<fabbione> i could have get it faster i was going to give up on the RAM
<wasabi_> jbailey, umount -l doesn't seem to work in initramfs
<mdz> Kamion: if we're supporting the source packages for tdb and tagcoll anyway, we may as well have the tools in main
<wasabi_> different umount?
<zyga> is there any # for translators?
<fabbione> but i can't be bothered to go and get it later
<jbailey> wasabi_: Right, it's busybox's mount and umount
<wasabi_> Umm. Okay, Well, I'm realizing that I should not umount it.
<wasabi_> I have to some how MOVE the mount into the real root.
<Kamion> mdz: ok for tagcoll. pitti said in the inclusion report "I don't like to see tdb-tools in main."
<jbailey> wasabi_: Right. =)
<wasabi_> How the heck can I do that?
<jbailey> wasabi_: Look at the bottom of /init to see how I move /dev
<mdz> Kamion: why?
<mdz> sabdfl: can we hold off on migrating to Malone until after the 5.10 release?
<Kamion> mdz: lack of documentation apparently
<wasabi_> Okay. I see that after root is mounted, it makes /dev/.static/dev
<wasabi_> mount -o move?!?!
<wasabi_> Interesting.
<wasabi_> Never seen that before.
<mdz> jdub: booting the old kernel is impossible in the common case of having upgraded to an ABI-compatible version
<mdz> jdub: rather, we should refuse to hibernate when the kernel has been upgraded but not booted yet
<mdz> jdub: there's a bug in bugzilla somewhere
<wasabi_> I suspect I want to do this in init-bottom? I want to move /tmp/flash to ${rootmnt}/boot
<zyga> oh, okay then
* zyga invites interested people to #ubuntu-translators
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with breezy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | 5.10RC is released! http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000035.html
<jbailey> wasabi_: Sounds right.
<wasabi_> thx once again
<jbailey> Anytime, my friend.
<wasabi_> Cool. I get it.
<wasabi_> make /boot/.static/boot, bind the original /boot to it, move the /tmp/flash system in place of the real /boot
<Kamion> mdz: you seem sceptical, so I've added tdb-tools to the Kubuntu supported seed
<doko> wasabi_: forwarded you an eclipse mail
<mdz> Kamion: lack of documentation has not stopped us before ;-)
<Kamion> heh
<Kamion> mdz: go ahead and run cron.sync now; it probably won't quite be complete, but close
<Kamion> well, s/now/after this cron.daily/ probably
<wasabi_> jbailey, run-init seems to complain if I create any new directories in the initramfs
<wasabi_> should I actually be doing /dev/.static/boot or something?
<zyga> who manages the wiki page?
<Kamion> zyga: what wiki page?
<zyga> wiki engine
<zyga> 0 rezultatw z liczby 5074 stron. (<ul> <li style="list-style-type:none">0.56 sekund. </li> </ul>)
<Kamion> hno73 I believe
<zyga> that means 0 results from 5074 page
<Kamion> (Henrik Omma)
<zyga> that's not source, I see HTML on the page
<zyga> https://wiki.ubuntu.com/?action=fullsearch&context=180&value=popularity+contest&titlesearch=Tytu%C5%82y
<zyga> hno73: ping :)
<jbailey> wasabi_: Got a specific error message for me? =)
<hno73> zyga: hi :)
<zyga> hno73: check above :)
<zyga> hno73: separate issue: clicking 'assign category to this page' combo box displays ["CategoryMOTU"] 
<zyga> hno73: wiki used polish locale
<wasabi_> one sec
<doko> mdz: syncing the ooo2-helpcontent2 "source" now, will finish in two hours. I'm waiting with the ooo2 upload for a few hours, until fabbione tells me the sparc results.
<wasabi_> doko, odd. Working fine for me. Need more info.
<fabbione> doko: it's munging as fast as it can :)
<wasabi_> There a bug report?
<doko> wasabi_: there's none, I just got the mail
<doko> wasabi_: could you test 3.1.1 packages?
<wasabi_> Yes, in a bit.
<wasabi_> IT BOOTED
<wasabi_> MY FLASH BOOTED
<mdz> doko: please do not wait for sparc
<jbailey> \o/
* jbailey ^5's Jerry
<wasabi_> Hahah.
<wasabi_> That kicks freaking ass.
<wasabi_> It's up, waiting for login.
<mdz> doko: this is already very last-minute
<doko> mdz: ok
<wasabi_> Okay, next step is I need to get loading/saving configuartion to work.
<mdz> doko: I'm not even sure we should do it, since we can't fit it on the CD anyway
<wasabi_> My idea is to have a "write" script, like a cisco.
<mdz> unless...
<wasabi_> Which saves specific modifications to the flash.
<wasabi_> like specific files in /etc, etc, and then reloads them at boot.
<wasabi_> Oh and I have to figure out how to do a unionfs too. =(
<mdz> sabdfl: around?
<fabbione> doko: please upload with that patch.. 
<tseng> wasabi_: you might take a look at openwrt
<fabbione> doko: i think that was the only point were asm love was required
<tseng> wasabi_: they have a readonly flash partition, and then an overlay for changed configs
<doko> fabbione: sure, I did include it, it's a sparc specific file, which gets patched
<dholbach> re
<fabbione> doko: exactly..
<doko> fabbione: mention Dave in the changelog?
<fabbione> doko: it's building binfilters now..
<wasabi_> tseng, that's good too. I need to learn how to do overlays right.
<fabbione> doko: yes please.. David Miller..
<fabbione> doko: are you aware of any other portion of code that are arch specific like that one?
<doko> AFAIK the uno bridge is the only one
<fabbione> doko: ok.. than we are good to go imho
<fabbione> don't wait for me to build..
<fabbione> just upload
<doko> fabbione: yes, have only 35kB/s upstream and the help.orig is 350MB ...
<fabbione> doko: doh
<fabbione> that will take at least 4 hours
<wasabi_> So, overlay file systems. What's the recommended software for this? I've heard of unionfs, but heard it's unstable.
<mdz> doko: assuming the .orig is pristine, you should be able to download to chinstrap and upload from there
<\sh> wasabi_: check openwrt or dd-wrt
<doko> mdz: no, not the prebuilt help content, which I did build on my server.
<wasabi_> Archives down or is it just me?
<mdz> wasabi_: so you're going to implement buntu then?
<wasabi_> mdz, well, not exactly. I'm implementing a simple initramfs extension to boot off a flash with a stored ro file system.
<wasabi_> Two bash scripts, done in about 50 lines each, seem to have completed it. ;0
<mdz> wasabi_: that's a big part of it
<mdz> plus the saving stuff
<fabbione> Diziet: firefox seems much more stable.. any hope to get to test mozilla-browser with the same CFLAGS?
<fabbione> (at least it didn't crash yet)
<mdz> wasabi_: once you have copy-on-write and a way to save the delta back to flash, the hard bits are done
<mdz> the rest is just package selection
<mdz> oh, and the installer
<wasabi_> yeah.
<elmo> bddebian: WTF, dude?
<bddebian> elmo: Now what did I do?
<elmo> why the hell are you uploading stuff instead of waiting for syncs?
<bddebian> elmo: With what?
<elmo> I SPECIFICALLY asked you not to do that
<elmo> libchipcard2
<bddebian> I asked for a sync and Kamion did it
<elmo> ok, so why are you emailing me stuff and then not telling me it's done?
<bddebian> elmo: The e-mail went out before Kamion did it for me and you are right, I meant to e-mail you that he did it and I did not.  My apologies.
<\sh> elmo: forget my wesnoth request...didn't know that Lathiat was requesting it, too :(
<Lathiat> \sh: heh
<wasabi_> mdz, copy-on-write is my next step. It shouldn't be that hard once I figure out what software to use.
<\sh> Lathiat: u should say a word :)
<elmo> bddebian: are any of the other emails superseded?
<bddebian> elmo: As far as I can recall, just the ones in that one big e-mail.  aqbanking, gnucash, libchipcar2, etc.
<Lathiat> \sh: we discussed it in #ubuntu-motu ;p
<fabbione> Diziet: ?
<\sh> Lathiat: grmpf...I didn't see that..so I requested it as well...ok no harm ;)
<Lathiat> perhaps is hould write a sync tracker :)
<\sh> Lathiat: a good thing for revu2 ;)
<\sh> Lathiat: putting everything on a list, and at the end of the week a mail will be send to elmo :)
<siretart> sync and morgue tracker are on my personal todo list
<\sh> siretart: rock
<Lathiat> btw if something has been thrown out of debian
<Lathiat> shoudl we throw it out too?
<elmo> guys don't expend too much energy on it - the manual sync process is a result of us  using katie
<elmo> it'll go away eventually when we move to LP
<Lathiat> e.g. howl
<Lathiat> altho we have one program depending on howl, theres code to use avahi in cvs 
<\sh> elmo: so LP will have a "please sync" trigger button? 
<siretart> elmo: do you have a timeframe for that?
<\sh> while gcl is test-compiling, I could grab some beer for tonight...yeah good idea
<moyogo> hi, i was wondering if there could be some font evaluation program
<moyogo> especially for opentype features
<moyogo> right now pretty much all of the fonts and all the programs don't have a decent opentype/unicode support
<moyogo> some fonts just have lots of glyphs, without the proper definitions
<moyogo> at least in latin script
<elmo> siretart: no
<sivang> Mithrandir: these are the performance samples I did , with GUI sessions, and without : http://muse.19inch.net/~sivan/breezy-performance/
<mvo> infinity: does the patch for #17116 looks sane to you?
<Riddell> Znarl, elmo: how are the kubuntu CDs?
<Znarl> Riddell : Think it's solved.  Just confirming now.
<Riddell> Znarl: what was the problem?
<Znarl> Riddell : We had to restart the seeding process.
<infinity> mvo : type isn't POSIX, is it?  Otherwise, the logic looks sane.  Is it tested?
<doko> mdz: OOo2 uploaded, hoary->breezy upgrade didn't show any problems. will upload the help in about three hours, but these cannot be uses without the updated OOo2 anyway
<infinity> mvo : Also, you may want to use "fgconsole 2>/dev/null", since it vomits on stderr if it can't figure out our current console.
<mdz> doko: accepted
<mvo> infinity: tested it with normal setup, multi-head, without gdm, with gdm, with timeout and without
<mvo> infinity: yeah, good point (the redirect)
<infinity> mvo : Cool, then it has my seal of approval, just needs mdz's.
<infinity> mvo : The whole thing is a pretty hideous hack that needs to be rethought, but it's good enough for now, I think.
<mvo> infinity: oh yes! right after the release we need to implement a post-run hook for usplash, that is a much better way to handle this IMHO
<infinity> Well, we need to know if it was running in the first place, and one what VC, etc.  Having it drop something in the (pivoted) root filesystem that we clean up in the init script might work.  I dunno.  I've not thought about it much beyond "the current solution is scary wrong"
<infinity> mvo : I think it's good enough for release, though (and subsequent inclusion in the Hideous Hacks BoF)
<mvo> infinity: my current idea is to have something like /etc/usplash/postrun that is a script that is run by usplash when is exists. we register the console-screen.sh stuff in it then
<infinity> mvo : Speaking of hooks, remind me at UBZ to corner you and discuss the "pre-upgrade" hooks ideas for synaptic/update-manager.
<mvo> infinity: right
<opi> g;day
<mvo> ping carlos 
<infinity> mvo : Yeah, that would work.  Except in the odd case usplash crashes, but I suppose designing for segfaults is a pessimistic view.
<mvo> infinity: b, it won't crash
<infinity> Hasn't done so for me so far, but give it time. :)
<mvo> haha
<infinity> "All software has bugs, this goes double for anything with the name 'Adam Conrad' in the changelog."
<infinity> A certain truth, I'm sure of it.
<carlos> mvo, pong
<\sh> I thought I heard bddebian, but I read infinity ;)
<mvo> carlos: is there a way to tell if the pot file of gksu in rosetta is up-to-date? it seems to lack a string
<mvo> carlos: "Please enter your password\n to run %s"
<mvo> carlos: it is part of the pot file that is generated with intltool-update -p 
<mvo> infinity: heh :) don't forget that my name is in the changelog as well, that will certainly make things worse
<infinity> \sh : I'm not being terribly self-deprecating, just realistic.  Software work (especially on a tight schedule) is a very "two steps forward; one step back" affair.
<carlos> mvo, I can give you the version of the imported .pot file, is that enough?
<mvo> carlos: yes, that's a good start
<mvo> carlos: I wonder if it might be easier to just upload a new pot by hand for now to make sure the string is in
<mvo> carlos: it's aobut the only string the users sees from gksu :)
<carlos> mvo, I or Jordi can do that, you don't have the rights
<bddebian> \sh: What did I do now?? :-)
<blueyed> I've posted a patch which fixes some issues with pppoeconf. I think it's important to get it into breezy: http://bugzilla.ubuntu.com/show_bug.cgi?id=10080 - would be nice if someone could at least re-open it. It's a "popular" bug and still not finally fixed!
<mvo> carlos: right, do you want me to send it to you? or will you do a "apt-get source gksu; cd gksu-1.3.0; intltool-update -p" yourself?
<jordi> mvo: I was going to do your request right now
* mvo hugs jordi 
<carlos> mvo, just a second...
<jordi> the synaptic one, is this a new one?
<mvo> jordi: not that I know of ...
<jordi> carlos: should I handle it?
<mvo> jordi: I splited the po dirs into "po and po-manual" recently (like 3 weeks ago). not sure if you mean this
<mvo> jordi, carlos: please let me know when a new template is up so that I can translate the missing strings
<carlos> mvo, POT-Creation-Date: 2005-06-18 14:57-0300
<carlos> that's the one imported
<carlos> jordi, if you could, yes, please
<infinity> blueyed : I mean to review your patch tomorrow and talk to the release managers about it.
<blueyed> Thank you infinity!
<jordi> carlos: ok. Do we have all the required filesi n rosetta@?
<mvo> carlos: will rosetta import changed pot files automatically in the future?
<carlos> mvo, we do that now, what do you mean?
<carlos> jordi, we should...
<jordi> ok
<mvo> carlos: hm, I wonder why the string is missing (or am I just overlooking something)?
<carlos> mvo, If it's missing it's because a bug not because we are not syncing
<mvo> carlos: ok, that's what I wanted to know, thanks. 
<sivang> can anybodyu tell me how does OO finds its font is uses? (trying to figure out #17175)
<mdz> carlos: how go the langpacks?
<jordi> mvo: so this is for the breezy template, right?
<carlos> mdz, breezy langpacks seem to look ok, just missing ones that we are reviewing / fixing every day and does not block the deployment of the language pack
<carlos> mdz, hoary ones seems that need some reimports now that we solved many bugs since hoary release
<mvo> jordi: yes
<doko> sivang: locate show VCL.xcu
<doko> sivang: locate VCL.xcu
<sivang> doko: k, and so a pakcage that installs font for OO should ship a file like this to let OO know about its fonts?
<doko> sivang: no, that's a priority list. OO uses fontconfig
<mvo> mdz: does the fix for #17116 looks ok to you?
<sivang> doko: k, thanks
<doko> so something did change with Diziet's changes, which you have to dig out. have fun :-(
<sivang> doko: I have this file both in my home and on /usr/share/
<fabbione> doko: oo2 started building right now...
<doko> yes, that's ok, edit the system file
<fabbione> doko: let's hope for the best or it will be a royal waste of CPU time ;)
<doko> fabbione: on sparc, the second time?
<fabbione> doko: from ubuntu4...
<doko>  ahh, ok
<fabbione> doko: i did stop the other.. since this was the last upload anyway
<sivang> doko: k
<fabbione> pointless to let it go twice..
<fabbione> doko: do you have any idea how much space it takes to build it?
<fabbione> like 4? 5? 6 GB?
<mdz> mvo: is that while pidof usplash .... for paranoia, or have we seen cases where it fails to exit?
<mvo> mdz: pure paranoia
<mdz> mvo: looks good
<mdz> mvo: I think the /proc/cmdline check is superfluous, but harmless
<sivang> doko: can fonts be used even if they do not appear in that file ?
<doko> fabbione: about 3GB ccache
<doko> sivang: yes
<mvo> mdz: additional paranoia ...
<mdz> mvo: you tested this with gdm disabled and it does the right thing?
<sivang> doko: I see, probably when queried from fontconfig ?
<mdz> mvo: well, in that case, the paranoia is backwards. :-)  if we have doubt, we should go ahead and execute the conditional
<doko> fabbione: debian: 3,5GB, ooo-build: 8,5GB
<mdz> because it's harmless if usplash isn't actually running
<mvo> mdz: yes, I added a sleep to ntpdate to trigger a timeout
<doko> sivang: the file describes priorities/choices. Look in the font selector, you'll see that all fonts are displayed, which are available from fontconfig
<fabbione> doko: ccache is not a problem, but i don't understand what you mean by debian: 3,5GB, ooo-build: 8,5GB ?
<fabbione> so i need a total of 12GB to build?
<doko> fabbione: the whole unpacked tree is about 12GB at the end, yes
<mvo> mdz: it's the chvt 1 scares me and that's why I don't want to be extra careful
<doko> + the space for the debs
<fabbione> shit
<fabbione> ops
<fabbione> sorry
<sivang> doko: font selector in fontconfig?
<mvo> s/don't//
<doko> sivang: in OOo
* mvo stares at his typing fingers
<mdz> mvo: there seem to be more changes in your lpi upload than in the changelog
<mvo> mdz: yes, my bad. some compiler warnings are fixed as well 
<mdz> mvo: e.g., x-www-browser
<mvo> mdz: that one was already in, I just moved it from debian/patches into my baz tree
<mdz> oh, I see
<sivang> mdz: that helped us drop dependency on the pakcage holding gnome-open , enable the future use by other desktops.
<elmo> doko: why is this oo2-helpcontent stuff so damn big?
<mdz> elmo: let me guess...it's another copy of the oo.o2 source
<doko> mdz: nah, not that easy ;)
<doko> elmo: 12MB per language
<elmo> mdz: it's 2 x the size of the oo.o2 source
<doko> prebuilt
<mdz> SWEET
<mdz> that's another source CD right there
<jsgotangco> ugghh
<doko> elmo: don't exxagerate!
* mvo cheers at OO
<elmo> 185M    /srv/ftp.no-name-yet.com/ftp/pool/main/o/openoffice.org2/openoffice.org2_1.9.129.orig.tar.gz
<fabbione> mdz: if you want i can upload oscar :) it's another 340MB of source ;)
<elmo> 338M    openoffice.org2-helpcontent_1.9.129.orig.tar.gz
<elmo> doko: ... ?
<doko> elmo: 2*185=370
<elmo> dude, please
<doko> we cannot build it from source, because it requires non-free jars
<elmo> 340, 370.  with oo2, what's 30Mb between friends?
<doko> so, the "source" package contains the prebuilt help, which is not the preferred format for editing, but good enough for breezy
<doko> elmo: 30MB is gcc ;)
<mdz> doko: non-free jars?  I thought the issue was that our JDK wasn't up to it yet
<jordi> mvo: hey
<jordi> mvo: I have no file for gksu in my email
<jordi> I do have a request for synaptic
<doko> mdz: iff I build the helpcontent from source, I'll have to use old versions of jaxp and xt, which have a non-free license. So we did have the choice of a third copy of source in multiverse, and the binaries not in main, or have the prebuilt binaries put in the source and in main, arguing that it's not code, but documentation, which doesn't come in the preferred format for editing
<sivang> doko: weird, there a conf.d conffile , also a fonts.dir for X11 , still no culmus for oo
<mvo> jordi: oh, sorry. I asked before if I should send a file or if it easier for you to do "apt-get source gksu; cd gksu-1.3.0/po;intltool-update -p" 
<doko> sivang: two weeks ago it did work. maybe try an old live-cd? or old fontconfig packages?
<sivang> doko: where I can fetch an old package?
<sivang> oh nice, firefox crashed for me on p.d.o
<doko> from an old cd. but there are only three cd's from the past ...
<jordi> mvo: can you mail me a quick file?
<jordi> it's only the pot, not the translations, rihht'
<sivang> doko: I can take a hoary package, I have a CD
<doko> sivang: what does this help?
<mvo> jordi: sure
<sivang> doko: nothing, sorry
<mvo> jordi: send
<jordi> mvo: thanks dude
<jordi> mvo: will do synaptic as well
<mvo> jordi: thanks! 
* jordi waits for mvo's mail.
<jordi> ah, here!
<janimo> elmo, I copy pasted the xubuntu-artwork copyright from kubuntu-default-settings that's why it's not CC-...
<janimo> I now see that edubuntu's is what you say
<jordi> mvo: gksu done, Catalan updated :=
<seb128> jordi, mvo: what about gksu?
<jordi> seb128: rosetta template update
<seb128> k
<jordi> don't wrory man :)
<jordi> https://launchpad.net/distros/ubuntu/breezy/+sources/synaptic
<jordi> I wonder how much sense this makes
<jordi> what does it mean it's not published in breezy?
<mvo> jordi: thanks
<jordi> mvo: synaptic should be done
<mvo> jordi: cool, thanks
<mvo> ping smurf 
<mvo> smurf: could you please add me to the german translators team?
<sivang> doko: is there anything you could suggest to check ? I don't see anything else I can check. and none of the culmus fonts appear on the OOo font selectors
* fabbione heads to bed
<fabbione> good night guys
<mdz> night fabbione
<fabbione> night mdz
<HiddenWolf> mvo, ping
<mvo> HiddenWolf: pong
<HiddenWolf> mvo, just dist-upgraded, and I get an empty post-update information notice.
<mvo> HiddenWolf: anything usefull in your ~/.xsession-errors ?
<hno73> Kamion: Slim AMD64 tarball: http://www.theopencd.org/winfoss/ubuntu-AMD/current/
<HiddenWolf> mvo, empty file
<mvo> HiddenWolf: empty? that's unusal. 
<HiddenWolf> mvo, nm, typo. :$
<mvo> HiddenWolf: can you send the file to me by mail?
<hno73> Riddell: Does Kubuntu Live need a slimmed down WinFOSS tarball for AMD64 too? The current one is about 92MB (compressed)
<HiddenWolf> mvo, what's the addy?
<mvo> HiddenWolf: and test if http://people.ubuntu.com/~mvo/update-notifier/ helps?
<mvo> HiddenWolf: michael.vogt at ubuntu.com
<mvo> HiddenWolf: there is a 0.40.13 in there
<HiddenWolf> mvo, sent
<mvo> HiddenWolf: thanks
<xTina> Hm. Who decided on putting that bearded face into the password dialog for xscreensaver?!?
<HiddenWolf> mvo, installed the new version, but that froze update-notifier.
<Riddell> hno73: breezy live amd64 CD is only 619M
<Riddell> Znarl: kubuntu CDs don't seem to be mirrored yet
<hno73> Riddell: but is that using an old tarball?
<Znarl> Riddell : Noticed another problem.  Fixing it now.
<Riddell> hno73: I'm not sure
<hno73> Riddell: http://www.theopencd.org/winfoss/kubuntu/current/ is the new URL
<hno73> http://www.theopencd.org/kubuntu/amd64/latest/ is the old
<hno73> 92 vs 35 MB
<segfault> who handles people.ubuntu.com?
<jdub> mdz: oh, good point (re: same-abi kernel)
* mvo heads to bed
<seb128> 'night mvo
<mdke> segfault, it depends on the person afaik
<tepsipakki> jbailey: ok, back online!
<jbailey> tepsipakki: Cool.  I think I guess why LVM didn't fire for you, we need to make sure the "root" variable is set from your shell
<tepsipakki> ROOT='/dev/hda2'
<janimo> jdub, I have an esound question
<janimo> I want to start it as part of default xfce session
<janimo> is it ok to just put it in there with -nobeeps and it will have the same params as in gnome?
<jbailey> tepsipakki: Right, now do export ROOT
<jbailey> tepsipakki: That way it's visible to the subshell, and run /scripts/local-top/lvm
<tepsipakki> jbailey: on the shell if I say 'export' it lists all those variables, including "export ROOT='/dev/hda2'"
<tepsipakki> jbailey: is "vg=${ROOT#/dev/mapper/}" right?
<tepsipakki> in lvm
<jbailey> Mmm, hold on a sec.
<jbailey> Your root is on a regular drive, but your swap is on lvm?
<tepsipakki> yes
<jbailey> Oh.
<jbailey> That won't work for resuming in breezy, sorry.
<tepsipakki> it has worked, though
<tepsipakki> but, ok
<jbailey> Right now we only activate the volume group that the root volume is on.
<jbailey> It would be reasonable to check the RESUME partition and do it for that one too.
<jbailey> tepsipakki: For your local setup, you could just hacka in a "vgchange -ay" somewhere.
<jbailey> tepsipakki: But we can't do that generally, because in a multipath case, some of the drives may not be visible until the network stack is up.
<jbailey> (Or other bus drivers not needed for booting)
<tepsipakki> jbailey: ok, I might just reinstall this some time and add root to the vg
<jbailey> tepsipakki: Are you going to be tracking dapper as it goes?
<tepsipakki> definately
<jbailey> If you could file a bug in bugzilla "initramfs-tools should also activate the lvm VG for the RESUME partition"
<jbailey> Then I'll probably nail that one fairly quickly after.
<tepsipakki> will do, and I won't reinstall it before it is done ;)
<jbailey> Great ;)  Always nice if the submitter can test to see if it's fixed. =)
<tepsipakki> of course then there's no need..
<tepsipakki> although my root is a bit too small
<sivang> Diziet: around?
<tepsipakki> jbailey: might I just rename the bug that I created yesterday?
<jbailey> tepsipakki: That'll work too. =)
<mdz> doko: the help built, but the packages seem to be empty
<tepsipakki> jbailey: done
<jbailey> tepsipakki: Cool, thanks
<mdz> doko: never mind, I've fixed it
<doko> mdz: just came home. thanks, thinko. the control file isn't regenerated
#ubuntu-devel 2005-10-13
<ogra> mdz, any opinion about my ldm mail ? 
<sistpoty> we've just discussed atlas3 in -motu... there is a new debian version (we are -19, they are -20) which fixes ftbfs with gcc-4. however since it has many depends on it, we are not sure whether it's worth syncing. any suggestions?
<RobertC_> where is pitti when you need him :[
<siretart> sistpoty: how many?
<dholbach> RobertC_: asleep, i guess - it's 00:34 over here
<RobertC_> ah
<sistpoty> siretart: very many... many libs as well
<RobertC_> fai enough
<RobertC_> fair.
<sistpoty> siretart: apt-cache rdepends lists 120
<bddebian> w00t
<RobertC_> mjg59: dont suppose you are up 
<dholbach> sistpoty: i should better go to bed.... i read "apt-cache rdepends lists 120" and typed "apt-cache rdepends lists 120" to test what it does... ouch :)
<sistpoty> hehe
<sistpoty> ogra: your opinion on this? (atlas3 not dholbach going to bed)
<bddebian> Ack, same problem for svgalib
<ogra> what about atlas3 ?
<sistpoty> [00:34:08]  <sistpoty> we've just discussed atlas3 in -motu... there is a new debian version (we are -19, they are -20) which fixes ftbfs with gcc-4. however since it has many depends on it, we are not sure whether it's worth syncing. any suggestions?
<sistpoty> ogra: see backlog in motu from 0:23h (utc+2)
<mjg59> lifeless-win: Hi
<bddebian> Isn't something already known about gnome-themes-extras??
<ogra> sistpoty, hmm, we have refblas3 in main...
<sistpoty> ogra: but that doesn't depend on atlas3, rather the other way round?
<ogra> sistpoty, refblas replaces atlas3
<ogra> *refblas3
<sistpoty> ah
<ogra> its a binary incompatible new version of blas
<ogra> so check which of the rdepends *really need* atlas3
<sistpoty> ok, will do that
<ogra> most if not all of them will: atlas3-base | refblas3
<sistpoty> ogra: thx, just saw that... I'll report back when i gathered the info ;)
<ogra> ok :)
<ogra> thanks a lot :)
<segfault> Go go go!
<bddebian> segfault: ?
<segfault> j/k. :P
<lifeless> mjg59: hi
<lifeless> mjg59: more tests, no more joy
<mdz> Kamion: is amd64/live space still an issue?
<lifeless> mjg59: tried killing xscreensaver (xscreensaver-command -exit) before hibernating, didn't appear to change anything
<mdz> the new cloop is likely somewhat smaller, since it's fresh
<lifeless> mjg59: also, I've filed two bugs, one for the usplash-kills-backlight and one for hibernate restores
<mjg59> usplash doesn't kill the backlight. Your BIOS does that.
<mjg59> I'll look into the hibernate thing.
<lifeless> mjg59: well, I marked as UNKNOWN component
<mjg59> It's a BIOS bug
<lifeless> erk.
<mjg59> The same happens in Windows
<lifeless> so why did I not see it during bootup with hoary ?
<mjg59> I've no idea
<mjg59> If you close the lid after ACPI has been enabled, Latitude BIOSes will kill the backlight
<lifeless> ok. sigh.
<mjg59> The Windows graphics driver knows how to deal with that
<lifeless-win> garh
<lifeless-win> just nuked my session
<lifeless-win> what was the magic dpms call 
<lifeless-win> ?
<mjg59> xset dpms force on
<mjg59> Or vbetool dpms on
<mjg59> xset will call driver-specific stuff, vbetool will call your BIOS
<lifeless-win> garh
<lifeless-win> no luck, suspend-resumeing
<mjg59> To RAM or to disk?
<lifeless-win> hahaha ram of course
<lifeless-win> *that* comes back
<lifeless-win> vbetool dpms on
<mjg59> The X1 was supposed to work, but you're the second person today to suggest that the screen didn't come back after suspend to RAM on it
<lifeless-win> open /dev/mem: pemrmission denied
<mjg59> Try hitting the brightness keys
<mjg59> Yes. It executes BIOS code - it needs to run as root
<lifeless> ok
<lifeless> so I think I was unclear
<lifeless> what I just did to myself was a test:
<lifeless> switched to console
<lifeless> closed lid
<lifeless> opened lid
<lifeless> backlight was off
<lifeless> (this differs from hoary as I recall it)
<lifeless> tried brightness keys (yes, I know that hack)
<lifeless> no joy
<lifeless> switched to alt-f7
<lifeless> tried there too
<lifeless> no-joy
<lifeless> blind-fold tried the vbetool, didn't realise I needed to sudo
<lifeless> so I'll try that again from console
<lifeless> ok, that works fine
<mjg59> Ah, ok
<mjg59> I believe that Hoary should have had the same failure mode
<mjg59> But haven't actually checked
<lifeless> hoary *always* lost the brightness on a ram suspend cycle
<mjg59> I'll be getting in touch with Dell next week to look into this (I've got the contact details of the brand manager)
<lifeless> but *never* lost it when closing the lid in either X or console
<mjg59> Hm.
<mjg59> Hang on a minute.
<lifeless> breezy *sometimes* loses it in X
<lifeless> and appears (now) to always lose it in console
* lifeless holds
* mjg59 boots a Hoary CD on his latitude
<mjg59> lifeless: My Latitude behaves identically under Hoary and Breezy
<lifeless> mjg59: I know you know that that this is a samsung q30
<lifeless> which is not exactly dell-standard
<mjg59> Yes. The BIOS is by Dell.
<lifeless> (rebadged q30)
<lifeless> ok
<bddebian> "Changes in Latitude, changes in Attitude..."
<lifeless> would the hoary livecd be sufficient demonstration ?
<mjg59> lifeless: Yeah
<mjg59> That's what I just tested
<lifeless> want me to try ?
<mjg59> If you could, that would be great
<sistpoty> ogra: it's actually only one library (libumfpack4) that can't live w.o. atlas3 when refblas3 is available. and no rdepends on that one
<lifeless> oh damn, just remembered, my hoary livecd is borkified
<lifeless> let me see what I can rustle up this weekend
<lifeless> womble: ping 
<ogra> sistpoty, so i would sync it and make sure libumfpack4 gets ecompiled too
<womble> lifeless: pong
<ogra> *recompiled
<lifeless> mjg59: anyway, I have two workarounds there, so its not really a great bother. hibernate however ... :)
<lifeless> womble: got a hoary livecd at home ?
<womble> lifeless: And arch-pqm commiter groups don't work, BTW.   <grin>
<lifeless> womble: they so do.
<sistpoty> ogra: ok, thanks
<womble> lifeless: I most certainly do
<lifeless> womble: can I borrow it? and are yo ucoming to yum cha ?
<ogra> sistpoty, thanks too :)
<womble> lifeless: They so do not.  Need to add a groups = {} to arch_pqm/__init__.py, and a arch_pqm.groups = groups after the groups parsing code in bin/arch-pqm.  And yes, and yes.
<womble> Hell, you can have it (and a couple more besides)
<lifeless> womble: sweet
<lifeless> womble: mmm, I use them all the time, in production no less.
* womble wanders off to stuff a couple more Ubuntu CD packs in his backpack
<womble> lifeless: Hmm, perhaps it's a Python 2.3 vs 2.4 thing.
<lifeless> womble: I'll bring lappy to yum cha, we can eyeball then.
<dholbach> good night
<ogra> night dholbach 
<jdub> mako: ping
<sistpoty> good night
<zyga> hi
<zyga> alsa-utils does not depend on udev
<zyga> Setting up alsa-utils (1.0.9a-4ubuntu5) ...
<zyga> ln: creating symbolic link `/etc/udev/rules.d/z60_alsa-utils.rules' to `../alsa-utils.rules': No such file or directory
<zyga> I didn't have udev around at that time
<eazel7> hi, eagle usb modem doesn't works in ubuntu after 2.6.10, and I'm trying to compile it under 2.12 but simply can't
<eazel7> anybody tried this?
<mdz> zyga: a bug
<zyga> mdz: and an obscure one
<zyga> mdz: I did a ... knoppix -> breezy upgrade
<oxez> wo lol
<Riddell> Znarl: still no kubuntu RC on http://releases.ubuntu.com/kubuntu/5.10/
<calc> mako: here?
<bddebian> Anyone know why in a pbuilder login I can build a package fine.  But I make the same changes to the package in my normal environment and I get:  "debian/rules:61: *** multiple target patterns.  Stop" ??
<bddebian> Anyone??  This thing is blowing my mind.. :-(
<Lathiat> bddebian: because its broken!
<dieman> strange, ive got a battle going on between gnome/pmount and hotplug
<dieman> over a ide cf card reader built into the laptop shown as a pcmcia device
<bddebian> Lathiat: Well amen to that.  Now I get "target pattern contains no `%" ??
<dieman> oh no, it may be pcmcia-cs, ugh
<dieman> 23:24:38.462 [I]  osspec.c:154: SEQNUM=2443, TIMESTAMP=1128745478, ACTION=remove, SUBSYS=block, SYSFSPATH=/block/hde/hde1, DEVNAME=/dev/hde1, IFINDEX=-1
<dieman> 23:24:38.462 [I]  blockdev.c:1044: block_rem: sysfs_path=/sys/block/hde/hde1 is_part=1
<dieman> 23:24:38.462 [I]  blockdev.c:1079: Ignoring hotplug event
<dieman> 23:24:38.506 [I]  osspec.c:154: SEQNUM=2444, TIMESTAMP=1128745478, ACTION=add, SUBSYS=block, SYSFSPATH=/block/hde/hde1, DEVNAME=/dev/hde1, IFINDEX=-1
<dieman> niiiiiiice
<bddebian> Lathiat: Was it you that was playing with boson-base?
<tritium> elmo, ping
<fabbione> morning punks
<bddebian> Heh, gmorning
<ajmitch> morning fabbione 
<fabbione> Diziet: i can confirm that mozilla-browser doesn't crash with that option
<fabbione> YAYA
<sivang> morning all
<jeff_> I am using sed -e /'# deb '/s/'# '/''/g /etc/apt/sources.list to uncomment every repository. Is there a way to exclude repositories that contain a certain word like backports?
<Burgundavia> jeff_, that is a #ubuntu question
<jeff_> No one on #ubuntu would help me
<sivang> jeff_: you just need to modify your regex,
<sivang> jeff_: add a condition to the matching, that won't match when you have the word backports
<jeff_> sivang: I don't know how. And I can't understand anyof the regex manuals. How do I add a condition?
<jeff_> I'm not asking you to do it for me. I just can't find out how. man regex is too much for me
<sivang> jeff_: let's take this to private ok?
<jmg> jeff_: try kregexpeditor
<sivang> jeff_: oh, that one can help too :)
<jmg> jeff_ get the regex cheat sheet
<jmg> look on delicious
<jeff_> jmg: this isn't a simple regex
<jeff_> I have a regex book!
<jeff_> the sed and awk oreilly book
<jeff_> But can't find out how to exclude a word in a regex
<jeff_> I tried: sed -e '/^# deb/ { !/backport/s/^# //g }' /etc/apt/sources.list, but that didn't work
<Burgundavia> jeff_, please take this elsewehre
<jeff_> ok, sorry
<jmg> heh
<jmg> what a weird regex
<fabbione> i don't understand why using a regexp when you have i
<fabbione> vi
<sivang> true :)
<sivang> fabbione: Bon Journo :)
<fabbione> hi sivang 
<arkais> if i want migrate to breezy i just have to change all hoary by breezy?
<fabbione> arkais: yes
<fabbione> but only after release
<fabbione> there might still be gllitches atm
<arkais> well i have to wait one week more? or it's safe do it now?
<fabbione> it should be safe to do it now
<fabbione> but if you can't cope with possible (even if extremely unlikely) breakage.. you better wait
<arkais> should, jeje should no always works good, isn't it?
<arkais> jeje
<arkais> oks
<arkais> thx
<jmg> hehe
<Mithrandir> sivang: those numbers look quite normal to me.. this is with the inotify-enabled kernel or the inotify-disabled one?
<sivang> Mithrandir: with the enabled kernel, still the system feels a bit unresponsive  , although maybe a bit better then with the previous kernels (there were a couple of updates during the last week)
<Mithrandir> sivang: what does hdparm -tT give you as numbers?
<sivang> Mithrandir: I will check and let you know. it's not my machine so I currently don't have access to it, should have around the evening.
<Mithrandir> sivang: ook.
<sivang> Mithrandir: I hope to have a T43 bu UBZ though :)
<Mithrandir> sivang: infinity is unable to reproduce it on his T43 and so does mdz (iirc, both of them have T43s, but I could be wrong), so it's not entirely reproducible there.
<infinity> mdz has an older T42, IIRC.
<infinity> Unless he upgraded.
<infinity> So, completely different drivers and such (the T42 is PATA, ICH4/5, the T43 is SATA ICH6)
<sivang> Mithrandir: I think those two have SATA, while that Dell is PATA
<sivang> infinity: ah :) to t42 is also PATA
<infinity> Yeah.  The T42 is PATA, AGP, DDR.  If you want old skool and well supported, get a T42.
<Mithrandir> oki, but people have reported the bug with both pata and sata, iirc.
<infinity> The T43 is all bling, bling new tech, SATA, PCIe, DDR2.
<sivang> infinity: yeah, I really want to have this slick and light machine with me for UBZ, it would help my productivity :)
<mdke> i'm getting the "user interaction required: new kernel" message after every boot/login...
<mdke> is this known?
<mdz> Mithrandir: T42 here
<Mithrandir> mdz: ok, I misremembered then
<mdke> :) that's the one I have too
<mdke> oh no, T43
<sivang> hmm, none of the pdf reading programs seem to work
<sivang> gpf crashes, evince cant launch and only xpdf is working
<mdke> evince works good here
<sivang> mdz: thanks for the ^D tip in mutt, it really helps :)
<sivang> mdke: I just upgraded, I will retest
<sivang> mdke: oh weird, for some reason it was not even installed now
<sivang> mdz: from some research I did upstream, it seems that klik is less strcit and can cater for a wider seleciton of software packages, what is our general direciton wrt autopackge(s) for dapper? (seems klik should be the major one, with possible support for OBLISK and autopackage)
<pitti> Hi
<fabbione> hey pitti
<sivang> pitti: moins :)
<pitti> Hi Fabio, hi Sivan
<fabbione> pitti: i have hoary almost ready..
<fabbione> pitti: fixing the last patch to build on amd64
<pitti> nice
<fabbione> yeah but the one liner for 3108 become a few hundred
<fabbione> because the function doesn't exist in .10 :/
<maswan> Lathiat: rsync on ubuntu-releases works fine for me here
<zyga> 'IPP request failed with status 1030'
<zyga> does anyone know why gnome-cups-manager keeps saying this?
<sivang> zyga: are you able to print ?
<zyga> sivang: no
<zyga> sivang: I'm trying to get it working
<zyga> this is a stripped down knoppix->breezy upgrade (don't ask)
<zyga> I've got all cups/foomatic stuff I could find
<zyga> and this issue
<sivang> I don't think we support knoppix -> breezy upgrades, or do we ?
<zyga> I've found a log from some german ubuntu irc channel
<zyga> but I don't speak german
<zyga> http://netz.smurf.noris.de/logs/freenode/2005/09/25/%23ubuntu-de.html
<zyga> sivang: could you have a look if they managed to resolve the problem
<sivang> zyga: let's take this to #ubuntu
<zyga> sivang: -> #ubuntu
<infinity> mvo : You broke all my console fonts!!
<mvo> infinity: *argg*
<mvo> infinity: I did?
<infinity> mvo : No, I just wanted to see your heart skip a beat.
<mvo> infinity: *gasp* 
<mvo> infinity: you did succeeded
* mvo makes a note to self to kick infinity at UBZ ;)
<infinity> I did so well that you've forgotten English grammar, apparently.  Go me.
<mvo> infinity: how could I forget something that I don't really know :)
<sivang> mvo: lol, same here :)
<\sh> English grammar? something new to me ;)
<infinity> sivang, \sh : Yeah, but mvo is lying; his English is impeccable.
<mvo> ha! see? we are even in the majority :p
<sivang> mvo: right :)
* mvo looks up impeccable now
<\sh> morning btw :)
* mvo blushes 
<\sh> and why I did take over xterm..now I know why daniels didn't want it anymore :(
<zoot_> hi there - who's responsible for software update applet breezy/gnome? despite upgrading the kernel (via synaptic) and rebooting, i repeatedly get the little globe alert icon requesting me to reboot due to a kernel upgrade.
<mvo> now infinity you know how to be mr. charming 
<zoot_> my system is up to date btw
<mvo> zoot_: that would be me, can you please send me your ~/.xsession-errors file?
<infinity> zoot_ : Do you keep getting it even if you click on it and read the message?
<zoot_> mvo: yes, keep on getting it and will send ~/.xsession-errors
<infinity> mvo : Bah, it's nothing to do with being charming.  When I met you at UDU, it took me a few minutes of talking to you before I even realised you were German.
<zoot_> mvo: where to find your email address?
<infinity> zoot_ : michael.vogt@ubuntu.com
<zoot_> infinity: thx
<\sh> grmpf
<mvo> zoot_: please look if #17091 is the bug
<doko> mdz, Kamion: ooo2-amd64 updated and uploaded
<mvo> zoot_: and please have a look at the bug I mentioned too
<zoot_> mvo: ok, file sent, will also look at bug
<xTina> http://bugzilla.ubuntu.com/show_bug.cgi?id=16816 is resolved/wontfix. Is it really a good idea to put a non-modifiable "guy with a beard" icon into the unlock dialog of Xscreensaver? Wouldn't it be better to put something more "neutral" in there, e.g. an Ubuntu logo?
<doko> fabbione: how did ooo finish on sparc?
<zoot_> mvo: must go now, will check bug later :)
<mvo> zoot_: ok :)
<fabbione> doko: it's building.. 
<fabbione> doko: binfilter <-
<fabbione> doko: i expect it to finish max tomorrow morning
<fabbione> it's a huge piece of code ;)
<fabbione> doko: or do you plan another upload?
<\sh> xTina: the best thing is to put the login picture in it...but seeing the timeframe...and knowing that ogra has to fix some other bugs which have higher prio...something for dapper + gnome-screensaver ;)
<sivang> \sh: we're gonna have much fun with dapper + gnome-screensaver :)
<xTina> \sh: Yeah, that would probably be best. But even for now I think a "guy with a beard" isn't the best thing to have hard-coded in there ;)
<infinity> xTina : Why not?  That's the default user pic, if you don't have one set.
<infinity> (ie: The "generic user icon")
<xTina> infinity: No it isn't!
<\sh> infinity: not right...I sat something else..but it's always this picture
<xTina> infinity: That is _always_ the default pic.
<infinity> That's why I have in gnome-about-me, which I haven't touched.
<xTina> infinity: Yeah, but in Xscreensaver you cannot change it.
<xTina> infinity: And you have to look at it every time you unlock the screensaver.
<infinity> xTina : No, I mean thtta's the default GNOME user icon.  The fact that you can't change it in xscreensaver doesn't mean much.
<xTina> infinity: Ah, yeah.
<infinity> It's like saying "You can change folder icons in nautilus, so why does some other app always show the "default folder icon" for my folders?
<infinity> (IOW: I don't think it matters terribly, but it will change in dapper with gnome-screensaver anyway)
<xTina> infinity: But it does cause unnecessary confusion  because it's not changeable and at least 50% of the population simply do not identify with a guy with a beard ;)
<\sh> xTina: did u mark the bug as wishlist?
<xTina> \sh: I haven't added any comments myself to that bug.
<infinity> \sh : The bug is WONTFIX, cause we're not hacking on that part of xscreensaver.
<sivang> I thought the guy with the beard was jdub  :)
<infinity> \sh : It'll magically "fix" itself when we switch to gnome-screensaver, which already does what people want.
<\sh> infinity: ok...:) 
<sivang> \sh: what does gnome screensaver has instead?
<xTina> infinity: I think it's WONTFIX because it can't be made configurable right now.
<\sh> well...anyways..I can identify myself with a "guy with a beard" ,-)
<infinity> s/can't/won't/
<sivang> lol
<\sh> sivang: dunno...I never checked it...it's something which is not important for me ;) I could live as well with a barbie doll displayed there
<sivang> \sh: who needs a screensaver anyways? :)
<fabbione> infinity: do you have amd64 over there?
<xTina> I still think the Ubuntu logo should be put back in there. All the Gnome default face does in there is cause confusion.
<infinity> fabbione : Only when my girlfriend isn't using it.  Why?
<xTina> sivang: Anyone in a lab environment?
<fabbione> infinity: i need some extra testers for a hoary security update
<fabbione> infinity: a patch that's amd64 specific
<infinity> Kernel?
<fabbione> infinity: yup
<infinity> I'd have to kick her off her system long enough to install hoary, then.  She'll likely divorce me doing that on a weekend.
<infinity> Try Mithrandir? :)
<fabbione> infinity: ahaha ok.. 
<fabbione> i can understand that
<doko> fabbione: no other upload
<fabbione> infinity: if your box has breezy, that would too
<fabbione> doko: ok thanks
<fabbione> doko: building over nfs is not exactly fast.. but i don't have 20GB locally
<fabbione> not without reinstalling the machine
<doko> fabbione: ouch
<fabbione> well a lot has been compensated by the ccache from the other build
<fabbione> so it's an okish compromise
<fabbione> disk usage tells me about 5GB for the build dir
<DanielN> hi
<fabbione> doko: so how far is binfilter in the build queue?
<fabbione> s/queue/sequence
<DanielN> is someone working on that shitty keyboard problem with swiss de-CH layout?
<DanielN> breezy is quite unusable for swiss people in that state
<infinity> Is there a bug number you're refering to?
<DanielN> yeah wait..
<DanielN> it's No. 8824
<DanielN> :)
<doko> fabbione: about the half of build, but this module takes ages ... (these are import filters for StarOffice 5.2 formats)
<fabbione> doko: so after that i can expect a speed up?
<doko> fabbione: why a speedup? I don't think so
<fabbione> doko: dunno.. i was just hoping :)
<sabdfl> hmm... new abiword
<Kamion> xTina: it definitely shouldn't be the Ubuntu logo FWIW; that would conflict with http://wiki.ubuntu.com/BrandingForDerivatives
<xTina> Kamion: I see.
<DanielN>  htmpf
<\sh> http://www.beejaysworld.de/archives/79-My-outlook-was-right.html
<DanielN> oh.. hi \sh nice to see you :)
<\sh> reactions to impilinux and the involvement of sabdfl 
<\sh> hey DanielN how r u?
<DanielN> thx fine... but it's  *goddamn* (sorry) to write with that keyboard layout at a swiss keyboard....
<DanielN> sucks :/
<\sh> DanielN: use german layout ;)
<DanielN> no, that doesn't suit the phisical swiss layout
<DanielN> :(
<azeem> DanielN: can't you change the keyboard layout in GNOME/KDE?
<DanielN> no.. it always switches to us
<DanielN> i can do what i want
<DanielN> going down to restart Xorg... see ya in minutes
<\sh> ok...xterm scrollbar issue is invetigated by upstream...very nice
<\sh> investigated even
<DanielN> back
<DanielN> wurgs
<DanielN> german layout sucks
<tseng> oh yes
<tseng> when i used dholbachs keyboard i was so lost
<tseng> i gave up
<DanielN> :)
<DanielN> and im lost with swiss keyboard and german layout
<DanielN> :(
<tseng> a UK keyboard for me is not so bad
<tseng> but i mapped it to us anyway
<Lathiat> ditto
<DanielN> but why can such a bug like the one in breezy happen?
<bddebian> Morning
<\sh> hey barry
<bddebian> Heya \sh
<bddebian> lamont or infinity: ping?
<infinity> bddebian : pong?
<\sh> hmm...oracle bought the innoDB company
<bddebian> infinity: qbankmanager has failed to build several times but looks like build-dep for libaqbanking0-dev wich is there and it builds fine for me locally?
<infinity> Meh.
<infinity> mdz / Kamion / elmo : looks like qbankmanager got NEWed to main, but it should be in universe.
<infinity> bddebian : For future reference, pay close attention in the build logs to where the source are being downloaded from.
<infinity> bddebian : If it's coming from main, it can't build against anything in restricted/universe/multiverse.
<ogra> infinity, any idea where xaos disappeared ? i uploaded it yesterday already...
<infinity> "disappeared"?
<infinity> -ETOOVAGUE
<ogra> i got katie mail, but it doesnt appear in the archive nor buildlogs
<infinity> ogra : /topic
<ogra> is there still a lock active ? 
<infinity> Oh, it's not in the topic anymore.
<infinity> Yes, the archive is locked until we release.
<infinity> Wouldn't make much sense to make it free-for-all in the last week, now would it? :)
<ogra> thats why i thought we can upload without pestering mdz/Kamion
<ogra> not really... youre right
<bddebian> infinity: OK, sorry
<\sh> elmo: just send an email with "ok to overwrite ubuntu changes" for svgalib ... thx
<ogra> \sh, there is still stuff using it ? 
<\sh> ogra: a lot
<ogra> ogra@honk:~ $ apt-cache rdepends svgalibg1
<ogra> svgalibg1
<ogra> Reverse Depends:
<ogra>   svgalib1-libggi2
<\sh> ogra: and it was in the testbuild snapshots not building properly
<ogra> doesnt look like here
<\sh> ogra: so dholbach was wrong...and I have not to fear any ass pain
<bddebian> heh
<\sh> ogra: at least..it fixes amd64 and gcc4 stuff
<ogra> look on your arch what its rdepends are...
<\sh> ogra: yeah..it fits
<\sh> ogra: but anyways...it's on popcon and on our ftbfs list for universe...so it was important to daniel ;)
<ogra> it should go away...
<\sh> ogra: dapper...
<\sh> ogra: there is a lot to go away...
<ogra> why carry something around nothing uses ...
<ogra> its obsolete...
<ogra> hmm, seems breezy-backports is contained in the default sources list... we should at least have a empty Packages.gz in the archive, people tend to uncomment it and complain about the errors :)
<elmo> err, WHAT?
<bddebian> ogra: We have a ton of shit no one uses :-)
<Lathiat> hrm, what package generates sources.list
<Lathiat> oh, apt-setup in base-config
<Lathiat> can someone send me a default sources.list?
<bddebian> ogra: Would you say the same thing about libzvt2.0-0 ?
<ogra> bddebian, nope... there are rdepends on libzvt2.0-0 thats a bit different than "nothing depends on it"
<ogra> ;)
<bddebian> ogra: I didn't say "nothing depends on it" just no one uses it ;-P
<ogra> bddebian, i said "nothing" not no one ;)
<ogra> bddebian, somebody might use scilab ;)
<bddebian> ogra: Well it's unbuildable and unmaintained in Debian :-)
<ogra> yes, but its not the same as svgalib :)
<\sh> bddebian: what about upstream?
<bddebian> \sh: Haven't looked there yet
<infinity> \sh : Err, when you "removed the replaces" from libofx, did you move them to libofx-dev instead, since that will now overwrite all those packages?
<\sh> infinity: please read the changelog :) 
<\sh> infinity: I moved .la to -dev
<infinity> \sh : I did, that's why I asked.
<infinity> \sh : Yes, and?
<\sh> infinity: u mean I need a replaces for -dev?
<infinity> \sh : Now -dev will have file conflicts with the old libs.
* \sh will never listen to God anymore...
<Lathiat> haha
<\sh> infinity: so Replaces: libofx1.... at libofx-dev
<Lathiat> libofx-dev replaces libofx1 << (old version) [i think, infinity knows :P)] 
<\sh> Lathiat: it's much more difficult
<infinity> \sh : Yes.  All the ones that were previously replaced, whatever that list was... libofx1, libofx1c2, libofx1c102, libofx0, or whatever...
<Seveas> Should http://bugzilla.ubuntu.com/show_bug.cgi?id=17292 be marked critical?
<\sh> infinity: so I have to do a libofx2 (< 0.8.0-3ubuntu4) as well
<\sh> aeh 3-ubuntu3
<infinity> \sh : And libofx2 (<< Verion-you-fixed-it-in)
<\sh> yes
<infinity> \sh : And push the moving file change upstream to Debian, no ifs, ands, or buts... Having stuff like this out of sync becomes VERY annoying, very fast.
<\sh> infinity: and only for libofx-dev
<\sh> infinity: ROGER THAT ! :)
<infinity> \sh : Since we get wrid file overlaps on sidegrades, and it's nearly impossible to solve them sith a simple version compare, since Debian may fix it a few versions after us, etc.
<infinity> s/wrid/weird/
<\sh> hah
<\sh> I need something for the changelog
<bddebian> \sh: That's what mdz told me in an e-mail
<\sh> bddebian: my fault..but I will never listen to god anymore..
<bddebian> \sh: How about "God is Dead"
<\sh> done
<bddebian> :-)
<bddebian> I've been trying to tell you that I'm a fucking idiot
<\sh> bddebian: what about >> The "That's why I left church" upload?<<
<infinity> bddebian, \sh : mdz was right to tell you guys to move the .la to the -dev package (in fact, I seem to recall making the same suggestion two days ago too).
<bddebian> infinity: Yes you did
<infinity> But you guys just needed to also take into account the file overlap issue, which doesn't go away, just moves to a new package. :)
<\sh> infinity: well...I don't know why the .la was in the libofx\d[^\-dev]  package anyways
<\sh> well...uploaded
<infinity> \sh : Convince Debian upstream to drop the .la completely, but don't dare try to sync that change until after we release.
<\sh> infinity: I'll file a bug now to bts
<infinity> Dropping a .la (while a Good Thing) means rebuilding every libtool-using app that build-deps on the lib.
<sivang> infinity: what's the alternative to using a .la ?
<infinity> "alternative"?... .la is just a hint to libtool for broken operating systems that can't figure out what to link to without it.
<infinity> On Linux, it's a) useless, and b) can cause massive headaches.
<\sh> another one
<\sh> .a is as well in libofx
<\sh> gnarf
<infinity> You're kidding?
<\sh> no
<\sh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326989
<\sh> *bangmyhead*
<infinity> \sh : File that one at severity "serious" in the Debian BTS.  It's a policy violation.
<infinity> Already filed as minor?
<\sh> infinity: I'll fix it first...then I'll bug debian
<infinity> Dear god.
* infinity bumps the severity.
<\sh> wait
<infinity> Wait?
<fabbione> Kamion, mdz: ping?
<\sh> infinity: now :)
<\sh> infinity: now u can bump the severity
* infinity wonders what he was waiting for.
<\sh> infinity: that I send the report to debian ;)
<infinity> Erm.
<infinity> Not much point in reporting it when you found a report already...
<infinity> Unless you followed up with a better patch or something.
<fabbione> infinity: can you please check the powerpc livefs for me? it appears to have a /pmu that's a duplicate of /dev/pmu
<fabbione> it really shouldn't be in /
<infinity> ...
<slomo> elmo: yes, it's ok to override
<\sh> infinity: well it's from the Date: Wed, 07 Sep 2005 02:37:00 +0200
<\sh> anyways I send as well a debdiff with it
<infinity> fabbione : Any idea who/what makes /dev/pmu?
<fabbione> infinity: udev?
<\sh> now I will buy some more beer and grab my washing
<fabbione>  /dev/pmu is ok.. but /pmu really no no no no
<slomo> elmo: infact we had the plain package by this guy before but now he finally got it into debian ;)
<ogra> sounds like a typo in a udev rule somewhere
<fabbione> infinity: i am debugging ppc liveCD on kiko's machine from remote.. so i am not exactly sure what to look for
<infinity> fabbione : RC or daily?
<fabbione> God only knows...
<infinity> That said, I can't find anything in the livecd scripts themselves that would litter devices anywhere.
<infinity> I can try mounting the cloop and looking at it, but I suspect it's being created at runtime.
<kiko> ahoy maties
<fabbione> kiko: infinity is looking into that extra device
<fabbione> what version of the livecd is that
<fabbione> ?
<kiko> fabbione, the RC version
<infinity> I take it back, pmu is in the fs image.
<infinity> I blame a postinst.
<fabbione> ok
* ogra wonders if kiko has seen the "with extra pmu power" on the cover :)
<fabbione> infinity: i guess you know yaboot better than i do
<infinity> Not in the least.
<fabbione> how can we disable usplash at livecd boot?
<infinity> My PPC is OldWorld.
<infinity> I've never even seen yaboot.
<fabbione> ok.. so whatever it boots the livecd
<fabbione> how can we disable usplash?
<kiko> yeah
<kiko> stop usplash!
<mjg59> Don't pass the splash argument
<sivang> lol
* infinity goes to install ubuntu-desktop and ubuntu-live in a breezy/PPC chroot and see where /pmu is coming from.
<fabbione> mjg59: yeah ok.. how do we do that on the livecd for ppc?
<fabbione> mjg59: i don't know the other boot options that we pass on it
<fabbione> or somebody please convice apple to send me my ppc asap
<kiko> fabbione, the livecd actually offers me a prompt
<kiko> I can type in yaboot
<kiko> what do I type? :)
<fabbione> kiko: yes.. but i have no idea of what you need to type :)
<kiko> nosplash?
<fabbione> that's what i am trying to gather from these punks
<infinity> No, you need a command line without "splash" on it.
<kiko> can I change the line from yaboot?
<fabbione> kiko: no idea sorry
<fabbione> kiko: if disabling usplash works
<fabbione> open a bug on usplash/xresprobe
<fabbione> link them together
<kiko> ok
<fabbione> and just say that usplash makes xresprobe baby jesus cry on $yourhardware
<fabbione> also add all the info from our IRC talk
<fabbione> so we can spare sometime
<fabbione> i can't do much from now without the cmd line
<kiko> okidok
<fabbione> IF it still doesn't work.. call mdz and complain about casper ;)
<sladen> fabbione: the correct answer is that vga16fb with the mode it is currently using makes hardware cry
<infinity> Erm, PPC doesn't use vga16fb.
<infinity> It uses offb to do usplash, I'm pretty sure.
<kiko> fabbione, infinity, sladen: the console font is ruined once X exits
<infinity> Which should "just work".
<kiko> can't even see what I type properly
<kiko> I gave fabbione some logs pretty blindly
<fabbione> kiko: that's mostlikely the framebuffer 
<infinity> kiko : Is the console okay while X is running (if you chvt over to another console)?
<fabbione> kiko: oh. now i can understand why there was /etc/passwd
<kiko> infinity, yes, mostly
<fabbione> kiko: i did logout.. so you can do whatever you need
<kiko> okay, thanks fabbione 
<fabbione> no problem
<infinity> kiko : Curious.
* fabbione goes and searches for his wife
<fabbione> i haven't seen her for almost 2 weeks
<fabbione> and it's saturday night
<\sh> fabbione: hmm...file a bug ;)
<Lathiat> heh
<jsgotangco> good night
<\sh> can someone check on -changes for 
<\sh> -- Jordan Mantha <mantha@lambda.chem.unr.edu>  Fri, 16 Sep 2005 22:04:04 -0700
<\sh> libghemical ?
<\sh> it's on the webarchive http://lists.ubuntu.com/archives/breezy-changes/2005-October/012373.html
<Lathiat> i cant find any
<\sh> but not in my mail archive
<\sh> and who is that guy?
<Lathiat> from *october* ?
<Lathiat> i should have that
<Lathiat> i dont...
<mdz> infinity: yes, that will happen (stuff NEWed to main); I just wait for the builds and then move it all to universe
<Lathiat> \sh: oh i have it
<Lathiat> \sh: it came from ubuntu installer thingy
<infinity> mdz : Erm, sure, but can't wait for the buildds, if the package doesn't build. :)
<Lathiat> because he wasnt whitelisted i assume
<infinity> mdz : (which is doesn't, cause it build-deps on stuff in universe)
<Lathiat> search for ~b "Changed-By: "
<\sh> Lathiat: hmmm
<mjg59> mdz: Can I have a diff for that acpi-support update?
<Lathiat> rather than from
<Lathiat> From breezy-changes-bounces@lists.ubuntu.com  Wed Oct  5 22:57:58 2005
<Lathiat> From: Ubuntu Installer <katie@jackass.warthogs.hbd.com>
<Lathiat> To: breezy-changes@lists.ubuntu.com
<Lathiat> Date: Wed,  5 Oct 2005 15:55:02 +0100 (BST)
<Lathiat> Subject: Accepted libghemical 1.90-1ubuntu1 (source)
<\sh> Lathiat: yes...another bug somehow in evolution..
<Lathiat> as for who he is
<mdz> mjg59: you don't have 0.44 around anymore?
<Lathiat> i have no idea
<\sh> Lathiat: laserjock :)
<Lathiat> ah
<Lathiat> i remember him
<\sh> Lathiat: but searching for libghemical doesn't show me anything but libgh somehow
<mjg59> mdz: I have 0.44, yes
<mjg59> Uhm, actually, no, I don't
<mjg59> I've got some local updates to the whitelisting
<Lathiat> \sh: interesting
<mjg59> mdz: Is it ok to upload a package that does nothing other than whitelist some more machines?
<\sh> Lathiat: right now evolution just fck up again...have to restart
<Lathiat> \sh: this is why i dont use evolution
<Lathiat> mutt = win
<infinity> Someone needs to invest in a few dozen terabytes of cheap disk and setup snapshot.ubuntu.com
<Lathiat> thunderbird = usable
<\sh> Lathiat: kmail == working
<mdz> mjg59: fine by me...in fact I think I have one more for you
<Lathiat> pff kmail :)
<mjg59> mdz: ok, cool
<bddebian> infinity: I suppose this is another dumb question but why was qbankmanager given back on i386 and ppc?
<mdz> mjg59: diff mailed
<mjg59> mdz: thanks
* infinity decided that snapshot.debian.net was officially the "coolest thing ever" when I had to install "sarge, as it was on Sept 13th, 2004", to test an upgrade bug.
<kiko> heh
<infinity> bddebian : It's failt obvious, if you follow the conversation here, and look at the build log.
<Lathiat> infinity: haha
<Lathiat> mjg59: anything i can do to help bug 15803
<infinity> bddebian : mdz moved the sources to universe, wanna-build still had them registered in main, i386 and ppc looked for them in main, builds blew up.  Next attempt will find the universe reigstration instead, and all will be well.
<bddebian> infinity: I know it' s not in main but amd64 and ia64 came back
<infinity> bddebian : s/failt/fairly/... I've been drinking, forgive my fingers.
<bddebian> infinity: OK, sorry
<infinity> bddebian : But ia64 and am64 built it later.  Just later enough to get the new wanna-build info.
<infinity> bddebian : Compare the 4 build logs, you'll see what I mean.
<mdz> infinity: there is a delay between when I NEW it and when I can move it into universe, unfortunately
<mdz> I understand elmo avoids this race by doing the overrides by hand
<infinity> mdz : Unless you use the crazy NEW to universe by-hand mojo.
<infinity> "The hack so hideous, elmo refused to admit to its existance, for fear of being laughed at."
<elmo> mdz: you can just leave NEW to me now
<infinity> elmo : haskell-cabal still desperately wants to be removed, BTW.
<infinity> Hrm... My keyboard gets nice and warm when I've been compiling for an hour straight.
<sistpoty> btw infinity: if you have enough time, could you please take a look at hat on ppc (seems to be dep-waiting for nhc98, which is i386 only)... but that's a low prio ;)
<infinity> sistpoty : Cleared up.
<sistpoty> infinity: thx
<infinity> Bing.
<infinity> fabbione --->
<infinity> pbbuttonsd.postinst:        if [ ! -c /dev/pmu ] ; then
<infinity> pbbuttonsd.postinst:        MAKEDEV pmu
* infinity claps the special kind of clap.
<infinity> mdz : Is it worth cleaning up old littered /pmu devices made by the above bug, or should i just leave 'em around (and fix the bug)?
<infinity> "[ -c /pmu ]  && rm -f /pmu" should do it.
<spayne> elmo: ping
<tucoz> there is a problem with dbi and postgresql. Postgresql creates the socket under /tmp but dbi looks for the socket under /var/run/postgresql
<tucoz> if I have understood this correctly. The fix was to change the unix_socket.. in postgresql.conf
<tucoz> to point to /var/run/..
<tucoz> instead of /tmp
<tucoz> (this is breezy)
<mdz> mjg59: it's dmidecode you need for the whitelist, right?
<mjg59> mdz: Yeah
<mdz> mjg59: # No SMBIOS nor DMI entry point found, sorry.
<mdz> STR works out of the box though ;-)
<mjg59> mdz: Gngh. What hardware is this?
<mdz> mjg59: old toshiba craptop
<mjg59> APM? Or ACPI?
<mdz> acpi
<mjg59> Weird
<mdz> USB doesn't come back though (ohci)
<mjg59> Hrmph.
<mdz> that's automatically unloaded and reloaded, right?
<mjg59> Should be, yes
<mdz> [4331329.434000]  ohci_hcd 0000:00:0b.0: USB bus 1 deregistered
<mdz> ah
<mdz> [4331360.564000]  ohci_hcd 0000:00:0b.0: USB HC takeover failed!  (BIOS/SMM bug)
<mdz> [4331360.564000]  ohci_hcd 0000:00:0b.0: can't reset
<mdz> it gets even more pissed off if I try to reload the module again
<mdz> [4331769.012000]  ACPI: PCI interrupt for device 0000:00:0b.0 disabled
<mdz> [4331769.012000]  ohci_hcd 0000:00:0b.0: init 0000:00:0b.0 fail, -16
<mdz> [4331769.012000]  ohci_hcd: probe of 0000:00:0b.0 failed with error -16
<\sh> ohci? this is compaq crap
<mdz> I wonder if the IR works
<mdz> it's destined to be a jukebox, would be cool to have a remote
<sivang> hmm, Ubuntu JUkebox, I also need one =)
<tseng> sivang: apt-get install mythmusic :)
<ssam> why does dmesg preceed everything with a crazy number in breezy?
<\sh> who can I ask for a new "universe test build run"?
<elmo> you can't, it's too late
<\sh> elmo: that's bad...
<\sh> well...backports team need as well some work ,-)
<\sh> lets check if I can get a better list of ftbfs source packages...
<spayne> elmo: tseng has uplaoded a new version of resapplet
<bddebian> \sh: And/or source with no binaries ;-)
<spayne> elmo: will kati email me?
<\sh> bddebian: the lists are a no go...
<bddebian> \sh: I'm soo surprised ;-)
<\sh> bddebian: we don't know from when the snapshots are 
<\sh> bddebian: and the last time QT was ftbfsing on i386 was a long time ago
<bddebian> :-)
<bddebian> OK, well I gotta run.  Though I should probably just turn in my MOTU badge for good ;-)
<\sh> ok...I'll sit down...drink my beer and wait for 13th
<sistpoty> hehe
<\sh> well..it's a thursday and not a friday ;)
<sistpoty> he \sh: before you sit down and do nothing (but beer-drinking), i got some tough problem: malone 2912 (-ENOCLUE from me)
<\sh> sistpoty: bah ;)
<sistpoty> *g*
<Lathiat> yay avahi sync
<Lathiat> thanks elmo 
<\sh> sistpoty: did you find something similar in debian bts or upstream? if not, file a bug against upstream ;)
<\sh> sistpoty: same happened to me with xterm today..
<sistpoty> sh: debian BTS: negative (wxwidgets2.6 checked only)... wxwidgets upstream has > 1000 bugs :(
<sistpoty> ' \sh even
<sistpoty> ' \sh I wouldn't even know on what to file the bug. I'm pretty clueless when it comes to gui-stuff ;)
<\sh> sistpoty: doesn't matter...just file a bug to something.../me has no clue about wxgtk, too :(
<sistpoty> ok
<elmo> spayne: no idea, probably
<j^> bug #17294, will anything be done to make DV capture work out of the box? if not for breezy, for breezy+1, with the new mpeg2-ts over 1394 (HDV Camcorders) the only way to capture is using /dev/raw1394
<\sh> evening sabdfl 
<Lathiat> anyone know how i can filter in procmail but have the mail continue through filters?
<sabdfl> hiya \sh
<Lathiat> (i want to filter all *new* launchpad universe bugs into my main mailspool, but leave them to get filtered with the rest to a folder later)
<sivang> hey sabdfl 
<spayne> sabdfl: are you Mark Shuttleworth?
* infinity curses whoever thougt it would be a good idea to change dupload's default to ubuntu, and sets his local version to have no default.
<elmo> infinity: err
<Lathiat> infinity: heh, misfiring uploads again?
<elmo> infinity: I'd much rather have mispalced debian uploads go to us than vice versa
<infinity> elmo : Well, yes, we're better at handling/rejecting them.
<infinity> elmo : But for me, "no default" is the sanest option, then I have to consciously pick a host to aim the upload at. :)
<Lathiat> whos the ia64 person?
<Lathiat> lamont?
<infinity> lamont is the ia64 porter, we both run the buildds, though.
<infinity> 'sup?
<Lathiat> libxaw7
<Lathiat> felt is failign to build on ia64 due to libxaw7-dev being uninstallable
<Lathiat> altho i see a successful build of that on ia64 
<Lathiat> oh hangon, it built fine later
<Lathiat> i missed that
<Lathiat> sorry
<mjg59> mdz: I've just uploaded a hotkey-setup to deal with 14446 and 16071
<jdub> GOOD MORNING FREEDOM LOVERS!
<mjg59> Good evening Jeff
<mjg59> How's Boston?
<jdub> muggy and rainy
<sivang> lol
<mjg59> Much like here
<sivang> jdub: morning dude
<jdub> not what i was hoping for
<elmo> Kamion: releases.u.c is nearly 30Gb :(
<sivang> can someone tell me how do I make the curret date appear on a spec I'm creating?
<sivang> I tried copying from SpecSpec but it didnt' work
<\sh> elmo: please sync rxvt 2.6.4-9 from debian unstable, thx :)
<dholbach> elmo: could you please sync quodlibet from sid?
<elmo> \sh: done
<elmo> dholbach: done
<dholbach> elmo: merci
<\sh> elmo: hugs :)
<psusi> shouldn't the inode number of a unix domain socket like /dev/log match the inode number that netstat -a -x reports for the listening socket of the same name?
<desrt> anyone have issues with libgphoto crashing on ppc?
<siretart> infinity: around? could you please kick zsnes out of dep-wait, please?
<psusi> and shouldn't one be able to do echo foo > /dev/log ( as root of course )
<desrt> psusi; if it was a pipe then yes.  if it's a socket then definitely not.
<psusi> because for some reason none of my unix domain sockets seem to be accessible doing things like echo > and cat, and the inode of the socket reported by ls -i and netstat are not the same...
<psusi> desrt, well, /dev/log is a unix domain socket isn't it?
<desrt> yes
<desrt> don't confuse sockets with pipes
<desrt> and don't confuse the ID of the listener with the ID of an active connection
<psusi> isn't the main difference that a pipe can only be opened by two processes, but a unix domain socket requires a server, and the clients open the file like a pipe
<desrt> no.
<desrt> pipe - open()
<desrt> socket - connect()
<desrt> if you open() a socket you will fail
<psusi> netstat -x -a shows the LISTENING socket and it's inode number.... ls -i of the node in the filesystem shows a different number
<desrt> (therefore shell redirection, cat, etc fail)
<psusi> you will?
<psusi> I thought that was the point of having unix domain sockets have nodes in the filesystem?
<desrt> you need to connect() to sockets in the AF_UNIX (aka AF_LOCAL) namespace
<psusi> so that the clients can just open() if they don't know about sockets
<desrt> definitely not.
<psusi> ( but the server still has to bind() listen() accept() etc )
<psusi> strange... I swear that at some point in the past I did something like echo foo > /dev/log
<psusi> if they can't be open()ed then why do they exist in the filesystem?  seems odd
<desrt> well... i might be wrong?
<\sh> elmo: please sync cadaver 0.22.2-1.1 from debian unstable, thx...
<\sh> and from this time on, I'll collect all syncs and write it in an email 
<infinity> elmo Can you sync php4_4:4.4.0-3 from queue/accepted?
<elmo> \sh: done
<\sh> elmo: how many beers I owe u now? :)
<Treenaks> \sh: Canadian beer? :)
<\sh> Treenaks: what ever ;) I'll bring some german beer ;)
<elmo> \sh: you don't, I'm just doing my job
<elmo> infinity: done
<\sh> elmo: ok..but the at least 2 six-packs of good old german beer...you'll like it ;)
<infinity> elmo : Many happy returns.  That spells bedtime for me, and maybe I can still have one day of my weekend.
<sivang> for someone who hadn't been in UDU, what does the scope field in a spec needs to specify?
<Riddell> Znarl, elmo: kubuntu RC still not mirrored?
<elmo> what?
<slomo> elmo: can you give-back banshee? it failed because one new dependency wasn't in the archives yet
<elmo> slomo: no
<elmo> talk to lamont or infinity about buildd stuff
<slomo> elmo: ok, sorry...
<slomo> lamont / infinity: can you give back banshee? it failed before because one new dependency wasn't in the archives yet
<\sh> btw...does anybody plan a halloween party during UBZ? 
<sivang> \sh: hmm, that'd be nice, what's the date ?
<elmo> Riddell: why isn't this in RT?
<\sh> sivang: 31st? ;)
<\sh> sivang: means: 30th -> ubuntu love day && 31st -> ubuntu halloween day ,-)
<Mithrandir> sivang: look at the specs from UDU?
<Riddell> elmo: because Znarl said it was being worked on
<Riddell> elmo: actually he said it had been fixed
<elmo> Riddell: he was talking about torrent
<elmo> Riddell: and you should ALWAYS use RT
<elmo> in any event, I'm fixing it now
<eruin> I can reproduce this every time, but I'm not sure how to make a good bug report out of it; every time I use synaptic to install/upgrade/reinstall pacakges, nautilus crashes (most often several times) during the "applying changes" phase.. what info do I need to submit here?
<\sh> elmo: my evolution just died again...so I'll bug you again via irc
<elmo>    * Rebuild, because gcl just came to late for the archives
<elmo> \sh: err, what?
<elmo> please don't rev the source in that situation
<\sh> elmo: please sync sysstat 6.0.1-3 and ircii-pana 1.1-2 from debian unstable
<elmo> the buildds will automatically retry
<\sh> elmo: sorry...gcl was to slow to build...and acl2 should build after that :(
<elmo> \sh: what do you mean should?  if it _has to_ it should have a build-depends which enforces that
<\sh> elmo: ok..you can smash a pumpkin on the 31st halloween party on my head ;)
<elmo> sysstat, ircii-pana done
<\sh> elmo: it has...but gcl was not ready (acl2 has gcl ( >= 2.6.7-9 ) ) and I thought gcl will hit the archives first
<\sh> elmo: thx btw :) 
<dholbach> elmo: could you please sync mldonkey from sid?
<dieman> elmo: heh, i have people at work who ignore the ticketing system all the time
<elmo> \sh: dude - either, it failed to build, in which case, you don't do anything.  or it built, but needed to build with another version.  in that case you should have fixed the build-depends
<elmo> dieman: I'm going to start ignoring people who ignore it soon
<dieman> heh
<dieman> elmo: our boss sends out mails every 6-12 months to all users
<dieman> elmo: explaning why we make them use the ticketing system
<\sh> elmo: roger that...
<elmo> dholbach: done
<dholbach> thank you
<jdub> mjg59: the suse 10 boot splash is pretty sexy
<\sh> jdub: the suse yast is pretty blond
<mjg59> jdub: Yes
<\sh> g'night gentlement :)
<\sh> cu tomorrow
<mvo> ping HiddenWolf 
<HiddenWolf> mvo, I installed your package yesterday, and today update-manager didn't work
<HiddenWolf> mvo, got notified of updated, could see them greyed-out in the window, and installing dindn't work.
<HiddenWolf> pong, btw. :)
<mvo> HiddenWolf: could you please install the updated version from today? I added another update
<mvo> HiddenWolf: people.ubuntu.com/~mvo/update-notifier
<HiddenWolf> mvo, don't be lazy, add http:// :P
<mvo> HiddenWolf: heh :) copy-n-paste problem
<HiddenWolf> mvo, still .13 there
<mvo> HiddenWolf: yeah, I didn't renamed it 'cause I was lazy :/
<HiddenWolf> mvo, right
<HiddenWolf> Setting up update-notifier (0.40.13) ...
<HiddenWolf> mvo, what do I need to pay attention to?
<mvo> HiddenWolf: please restart update-notifier ("pkill update-notifier; update-notifier")
<mvo> HiddenWolf: and then see if it it works all right (you may re-install a kernel-image or dbus if you want to stree it a bit)
<mvo> HiddenWolf: thanks for testing!
<HiddenWolf> mvo, dude, fix those warnings. :)
<mvo> HiddenWolf: debug-version!
<HiddenWolf> :)
<dholbach> jdub: ping
<jdub> dholbach: pong
<HiddenWolf> mvo, installing a -386 kernel, besides my -k7 one.
<dholbach> jdub: do you have an idea, how to let mailman know to accept mails with "X-Generated-By: Launchpad (canonical.com)"?
<dholbach> jdub: i tried in the spam-regexp stupid thingie, but neither of my feeble tries worked
<jdub> dholbach: mithrandir wrote a hack for us to handle x-katie, so we could extend that
<dholbach> i'd need that for universe-bugs
<jdub> ok
<dholbach> because i had to approve like 1000 mails
<jdub> i'll have a look
* dholbach hugs jdub 
<j^> dholbach privacy/sender
<jdub> you can't accept based onemail address?
<dholbach> j^: sender is problematic, because that could be someone who isnt subscribed
<mako> jdub: dude. have you told all the fashionable people to come to our party?
<HiddenWolf> mvo, should there be a notification in that case?
<dholbach> j^, jdub: Reply-To: Bug 1969 <1969@bugs.launchpad.net>  <--- that's the one i could filter too
<j^> dholbach same thing for X-Generated-By: ...
<mako> j^: hey dude
<j^> hey mako 
<j^> how is the lab?
<mako> j^: it's fun! not really any pressure yet so that's cool
<dholbach> j^: ok, can you guide me howto do it in "sender filters"?
<sivang> mako: what are you doing there? are you with jdub? :)
<sivang> mako: howdy btw, long time since we last talked.
<mako> i'm in the media lab right now.. i suspect jdub is back in the stata center where the gnome conference is
<j^> dholbach you can got to cgi-bin/mailman/admin/$LISTNAME/?VARHELP=privacy/sender/accept_these_nonmembers and set emails/regexps that should go to the list
<mvo> HiddenWolf: yes, but it can take a bit to show up
<mako> i came back to take a nap although i've not been very successful yet
<dholbach> j^: isn't that for the "From:" part of the mail only?
<j^> dholbach i guess so, for the Reply-To part you have to change some python code
<dholbach> j^: hrm
<jdub> dholbach: this is the same as the katie case
<dholbach> jdub: what did you add there?
<HiddenWolf> mvo, yup, took an age, but showed up nicely
<mvo> HiddenWolf: ok, let me know if anything strange happens
<HiddenWolf> mvo, I'll see what happens when there is an update, had that weird issue this morning.
<mvo> HiddenWolf: I think I fixed the issue with this version
<HiddenWolf> mvo, good
<HiddenWolf> mvo, you rule, btw. :)
<sivang> mako: btw, if we'd have time over in UBZ, you promisd to teach me some emharic over in Mataro :)
<dholbach> HiddenWolf: i have an autograph from him
<HiddenWolf> dholbach, nice. ;)
<HiddenWolf> sivang, isn't that amharic?
<sivang> HiddenWolf: err, right. You know I can't spell :)
<HiddenWolf> sivang, how will you ever learn a language if you can't spell it's name. ;)
<sivang> HiddenWolf: lol, right :)
<HiddenWolf> sivang, I can't really say anything tho. I'm still expecting my computer to know what I'm thinking when I press <tab> halfway though typing a random word. :$
* HiddenWolf chuckles
<HiddenWolf> u<tab>, and I expect gedit to know I mean ubuntu. 
* HiddenWolf needs to get a life
<sivang> lol
<HiddenWolf> I can't wait for wireless headsets, voip, and voice recognition to be up to par. 
<HiddenWolf> Altho that'll make doing my usual 5 conversations at a time rather difficult. 
<HiddenWolf> "Please Hold, my computer is trying to do $foo" "Please Hold, I've got a jabber on line 3"
* HiddenWolf muses
<sivang> maybe something to spec 5 releases from now :)
<HiddenWolf> sivang, I'd love to see you make a spec for handling 3 conversations and controlling a pc with one set of vocal cords, while listening to music. :)
<slomo> elmo: please sync smb4k from debian/unstable
<HiddenWolf> sivang, I'm off, saturday-night is for chilling. :)
<sivang> HiddenWolf: laterz dude
<HiddenWolf> sivang, count in it, I'm here to stay. ;)
<HiddenWolf> in/on
#ubuntu-devel 2005-10-14
<poningru_> I Had a question
<poningru_> does breazy still require significant work?
<poningru_> cause there is only a week left
<sabdfl> it's in good shape for the release
<bddebian> poningru_: But you are welcome to come help us with Universe ;-)
* sivang should dist-upgrade tommorow and try the vmware alltoall patch
<poningru_> bddebian: hehe I would love to but too busy
<poningru_> if only the release werent this week
<poningru_> I have two conferences this week and 3 midterms
<sivang> night all
<sivang> *time to sleep
<bddebian> poningru: Ugh :-(
<mdz> bddebian: looks like there are more conflicts in libofx
<mdz> Unpacking libofx2 (from .../libofx2_1%3a0.8.0-3ubuntu6_i386.deb) ...
<mdz> dpkg: error processing /space/cache/apt/archives/libofx2_1%3a0.8.0-3ubuntu6_i386.deb (--unpack):
<mdz>  trying to overwrite `/usr/share/libofx/dtd/opensp.dcl', which is also in package libofx1c2
<mdz> what a mess; it isn't packaged properly at all
<bddebian> mdz: Aye.  \sh is going to fix it for me I think since apparently I'm a moron :-(
<bddebian> mdz: BTW, would you mind if tseng uploaded a simple change to liboro-java?  It's just a build-dep change from java-runtime1 | java-runtime2 to java1-runtime or java2-runtime ?
<tseng> did you make a debdiff for that yet?
<tseng> or I was meant to do that
<tseng> done
<tseng> great.. i need ant to repack a source package
<tseng> bddebian: mdz i can upload this when you are happy
<mdz> bddebian: ok
<bddebian> tseng: Yes isn't that stupid :-)
<tseng> going.
<tseng> done
<mdz> does anyone know if multimedia keys are supposed to work in rhythmbox?  the code seems to be there, but it certainly doesn't work for me
<tseng> mdz: did you happen to set the keys up after starting rb?
<mdz> tseng: hmm, maybe
<tseng> muine doesnt re-read them
<tseng> quite possibly a global limitation
<mdz> restarting doesn't help
<mdz> I've tried both with and without setting up the shortcuts in gnome-keybinding-properties
<tseng> bah this laptop doesnt have more than volume +/- and mute
<mdz> the code in rhythmbox seems to look for the XF86XK_Audio* keysyms, rather than gnome keybindings
<mdz> so maybe I need to map those for it
<Burgundavia> mdz, I have had them work for me
<bddebian> Anyone an Ada expert? ;-)
<mdz> Burgundavia: via gnome-keybinding-properties or directly to rhythmbox
<mdz> L
<mdz> ?
<tseng> mdz: for me if you put in the same key twice for Skip to next track
<tseng> mdz: it will show XF86AudioNext
<tseng> what in the world that means, I do not know
<tseng> just something ive noticed
<mdz> tseng: yeah, I noticed that too
<mdz> it's as if gnome is simulating an event for the Audio keysyms
<joh> mdz: did you get my pm?
<mdz> joh: yes, but I'm not sure what you expect from me
<tseng> bddebian: liboro accepted
<mdz> joh: it sounds like you need a security consultant, and I'm not available for that type of work just now
<bddebian> tseng: Thanks man
<joh> mdz: anything would be helpfull, if you have time that is.
<joh> mdz: ok, you could've just told me that ;)
<tseng> bddebian: nps
<mdz> joh: http://www.ubuntu.com/support/supportoptions/ is a good starting point
<Burgundavia> mdz, they just worked
<Burgundavia> mdz, never dug deeper
<mdz> Burgundavia: so you do not have them set up in gnome-keybinding-properties?
<Burgundavia> mdz, no I did not. I think mjg69 set some defaults a while back that probably did it
<mdz> it seems the gnome-keybindings stuff doesn't really work
<mdz> if I map them with xmodmap to the XF86Audio keysyms, it works then
<Burgundavia> mdz, one further peice of info. I think it might be RB setting them, as if I start both RB and Muine, muine complains about not being able to capture to keys
<bddebian> OK, Ada sucks
<slomo> bddebian: :)
<slomo> why?
<slomo> for gnat... ask doko... he seems to be the maintainer ;) maybe he can tell you what to do
<bddebian> slomo: It's dumping out for every little dumb warning :-)
<slomo> bddebian: -Werror?
<bddebian> I was thinking that :-)
* bddebian wonders how many times he should recompile a package no one gives a shit about? :-)
<slomo> ...until it is fixed, you gave up or it was morgued? :P
<bddebian> Heh
<bddebian> I'd ask for a morgue but there is a Malone bug against it so I guess SOMEONE uses it ;-)
<dholbach> good night
<bddebian> Anyone know how to wrap a line in Ada??
<lifeless> mjg59: ola
<lifeless> mjg59: Another data point for you.
<mjg59> Yup?
<lifeless> mjg59: in X, closing the lid and reopening does not lose the backlight (it goes off, then on, properly)
<mjg59> Yes
<mjg59> That's because xset gets run in that case
<lifeless> mjg59: ok, just so you know :)
<mjg59> That's us managing to work around the bug to some extent...
<lifeless> nice
<johhny> Is everything in breezy compiled with gcc 4 by default?
<mjg59> Yes
<johhny> Would I be able to take a binary from Novell Linux Desktop and older gcc and run it on breezy?
<johhny> If I can, I am deploying breezy on the desktops for all of our technicians at work
<lifeless> johhny: *maybe*.
<lifeless> johhny: only way to tell is to try.
<johhny> I get to find out if it will run the official novell client monday :)
<johhny> I really hope so
<johhny> My boss wants me to find an os better than novell linux desktop. He thinks gnome 2.6 sucks (I agree)
<johhny> And breezy is amazing
<johhny> I found a really weird bug in sabayon, would anyone mind trying to reproduce it for me?
<bddebian> johhny: What is it?
<johhny> I open up sabayon from the menu and it says it can not find gnome, falling back to default session. When I try to close it, it brings up a dialog "Your session has changed blah blah blah: Save, Cancel, etc" and then it starts loading gnome
<johhny> So I hit cancel and it works
<johhny> That makes it appear broken
<johhny> It only does that when loading up an Xnest window
<johhny> Also, Xnest :2 gives me a blank screen and no gnome
<bddebian> Give me a minute
<johhny> thanks
<bddebian> johhny: Where does it put it in the menu?
<johhny> System --> Administration --> Desktop User Profiles
<johhny> I opened it up and created a user named unpriv. Then I clicked edit and thats what happened
<bddebian> johhny: Yes, I get that error also
<johhny> Could you confirm my bug? http://bugzilla.ubuntu.com/show_bug.cgi?id=16971
<bddebian> johhny: Well I don't have the exact same problem it seems.  When I start sabayon, I get the "could not find "gnome" session error in the window, click OK, then I get the Ubuntu desktop.
<johhny> ah
<johhny> I get the ubu desktop if I try to close it and then hit cancel
<bddebian> Where is the Xnest thing coming from?  I don't even see that window
<johhny> bddebian: The window that is x embedded within x is Xnest
<johhny> Run Xnest :2 and what do you get?
<johhny> Ive been trying to figure out why sabayon does this all day
<johhny> And would like it to be fixed before the launch of breezy
<bddebian> Seems to work fine, no error messages
<johhny> And brings up an ubuntu desktop?
<bddebian> No, just an X-window
<johhny> I just realized that I dont have to hit cancel, I just have to wait about 10 seconds after hitting ok for it to login to ubuntu
<johhny> So now I have to find out what it is not finding that tells it about gnome
<johhny> Any ideas?
<bddebian> I'd have to look at the source
<bddebian> And I can't do main
<johhny> ok, thanks for the help
<bddebian> NP, sorry I can't be more.  If I get some time, I'll poke around
<pef> bye !
<marcin_ant> hi guys - short question - I would like to create icon theme for ubuntu-desktop and I would like to know if there is something like a full list of icon names to create in new theme to replace all defaults icons?
<Burgundavia> marcin_ant, #ubuntu-artwork
<marcin_ant> Burgundavia: heh... and no #ubuntu-icon-theming?
<LaschW> Does anyone know why gnucash-hbci is not in breezy? For a lot of European users, a lot of them companies, this would be very important.
<bddebian> LaschW: Is that a seperate package or just enabling hbci in gnucash?
<LaschW> On http://people.debian.org/~tviehmann/debian/unstable/ are gnucash-hbci deb's which don't install due to dependencie problems.
<LaschW> bddebian: Its a addon package which is needed for HBCI in a couple of european states.
<bddebian> LaschW: I think it's just a matter of --enable-hbci or something like that
<LaschW> bddebian: I'm not shure about that. AFAIK gnucash -hbci adds a lot of dependencies, e.g. to aqbanking. Martin Preuss, developer of aqbanking shuld be able to give more information abiout that
<bddebian> LaschW: Yes, I just added all the aqbanking dependencies in breezy not too long ago
<LaschW> bddebian: Hhhm, just a moment, will just start gnucash. Hope I don't miss something...
<bddebian> It may not be enabled currently.  I'll pull the source in a bit
<LaschW> bddebian: No HBCI at all. There should be a menu entry: Action (Aktion in German) -> HBCI; in an opened ledger. Which is not
<bddebian> Anyone know if a .xml file for mime types should go in the -common package?  (lyx in this case)
<LaschW> bddebian: Oh yes, I would vote for if I could. Up to now LyX is handled as a text aplication which makes popup LyX for every text document...
<LaschW> bddebian: This is so in kubuntu and in ubuntu
<bddebian> LaschW: There is a --enable-hbci option to configure.  I will try it.
<LaschW> bddebian: Thanks a lot, that would be great to have. There are a lot of small and midrange companies I was told they use gnucash for their buisines.
<LaschW> bddebian: BTW, LyX. It would be smart to have the LyX svg icon, looks graet indeed.
<LaschW> bddebian: s/graet/great/
<LaschW> bddebian: Dont get afraid abut the number of new dependencies which will come along... (c:
<bddebian> Sorry I don't know what you mean.  I'm kinda stupid :-)
<johhny> Does the breezy installer support ntfs resizing? I dont use windows so I haven't been able to test it out and a buddy wants to know
<LaschW> bddebian: Hey, deFreese, sounds good for a Frieslander (central Friesland, between east and northern Friesland).
<LaschW> bddebian: Gnucash hbci needs libaqbanking, libktoblzcheck and some more dependencies I forgot...
<bddebian> libchipcard2
<LaschW> bddebian: and libchipcard...
<LaschW> bddebian: libaqbanking0, libktoblzcheck1, libgwenhywfar17, libssl0.9.7, libaqbanking-data, libaqbanking-plugins-libgwenhywfar17, ...
<tseng> apt-cache depends gnucash | grep Depends: | awk '{print $2}'
<tseng> no need for guessing
<tseng> oh i see.
<seth_k|lappy> johhny, yes it does
<johhny> seth_k|lappy: Thanks, that will make him very happy
<LaschW> seth_k|lappy: A rezize ntfs option would be a good thing for oem preseed. So oem would be usefull for install parties too.
<bddebian> What is up with gnucash??
<johhny> the partition editor sucks for someone who knows nothing about partitioning
<johhny> I breezed through it, but only because I can manually write an fstab
<LaschW> bddebian: There is no HBCI support for breezy...
<bddebian> LaschW: No, it won't even build
<LaschW> bddebian: due to dependencie problems?
<Riddell> mdz: kubuntu RC is on the mirrors, you can release the ubuntu-announce post
<bddebian> LaschW: No, can't find config.status :-(
<LaschW> bddebian: May be thats why there is a standalone paket gnucash-hbci? 
<bddebian> Hmm, I must have blown the configure line out too far
<bddebian> LaschW: This one might be over my head.. I have no idea why it's puking when I add --enable-aqbanking and --enable-hbci ??
<bddebian> The config.log just seems to stop
<LaschW> bddebian: May be it might be an idea to ask Martin Preuss (aqbanking developer) and Christian Stimmig (gnucash-hbci developer).?
<LaschW> bddebian: Will it be ok to post their email addresses here on irc?
<mdz> Riddell: done, congrats
<mdz> Riddell: what was the issue with the mirrors?
<Riddell> mdz: not sure, need to ask elmo 
<Riddell> mdz: I'm about to do a muckle upload of KDE 3.4.3
<bddebian> LaschW: Your best bet would probably be to bug Thomas Bushnell, the Debian Maintainer
<mdz> Riddell: how long do you think it will take?  if you ping me when it's done I can process them all at once
<elmo> the mirros are broken because 2 machines ran out of space, because releases is now 40Gb and torrent is over 100Gb
<elmo> we should probably reconsider providing 3 releases concurrently on releases.u.c
<LaschW> bddebian: Hhhm, I'm not shure about that. He don't offer the HBCI packages for Debian. They are done by Thomas Viehmann.
<Riddell> mdz: an hour maybe, my upstream bandwidth is slow
<LaschW> bddebian: And you may only find them on thomas's URL: http://people.debian.org/~tviehmann/debian/unstable/
<bddebian> LaschW: Well we sync most of our stuff from Debian so...
<LaschW> bddebian: gnucash is even out of sync in unstable, so...
<mdz> elmo: or reconsider putting the DVDs there
<LaschW> bddebian: That would be a good-to-have for Ubuntu ;-)
<bddebian> I tried -19 but we don't have the matching build-dep versions
<bddebian> LaschW: I don't disagree but we are probably too close to release for anything major to happen :-(
<elmo> mdz: that too
<LaschW> bddebian: 1.9.10? AFAIK there is an 1.9.11
<LaschW> bddebian: And I would bet that the HBCI guys would be glad if they are asked to bring it into ubuntu ;-)
<elmo> the DVDs being there is going to absolutely slaughter any chance we have of caching the actual ISOs
<elmo> tho kubuntu and edubuntu already don't help with that
<johhny> Is it just me, or does the openoffice.org2-gnome integration package not work on the latest breezy?
<johhny> I like my native gnome dialogs for open/save
<bddebian> LaschW: Again, I don't disagree but it probably can't happen for breezy.  You notice Debian and Ubuntu are still at 1.8.10-xx.
<LaschW> bddebian: I just found that there is a need for some patches to buils with gcc4: (Guppi) Guppi-gcc4.patch, Guppi-intltool.dif, any-gettext.patch, guppi-font.dif; (G-Wrap) g-wrap-1.3.4.dif
<johhny> http://www.digitalprognosis.com/opensource/Screenshot-Save-as.jpg This is what I get even with openoffice.org2-gnome integration package installed
<LaschW> bddebian: I will ask Martin, Christian and Thomas. It's 4:30AM here (UTC+2) just right for a wakeup challenge. *laugh*
<Riddell> johhny: native file dialogues arn't turned on by default
<johhny> Riddell: That is inconsistant with the rest of gnome, why not? /me is horrified
<johhny> Riddell: Was there a strategic decision for making OO.o not fit in with the rest of gnome?
<bddebian> LaschW: Heh
<Riddell> johhny: no
<Riddell> johhny: it caused crashes in earlier versions
<johhny> Riddell: Some more questions questions: Could it be made the default before breezy ships? I will ask the maintainer if I can get information on them, and how can I turn them on?
<Riddell> johhny: I doubt it.  turn on in Options I think
<johhny> Riddell: Thanks
<johhny> Riddell: So I dont guess you know a way to script that or what files it changes
<Riddell> I don't I'm afraid
<johhny> Thats ok, thanks for the help
<Riddell> whiprush: you can fridge kubuntu RC
<Riddell> is it possible to use gpg-agent with debuild?
<LaschW> bddebian: Ok, I send an email to the hbci guys. Lets hope they will take the chance...
<LaschW> bddebian: s/send/sent/
<anne_> Is there a good tutorial on how to make a kernel-source package?
<Amaranth> Rotund: That is a highly non-trivial task.
<Rotund> grrr.  I want to add more support for VIA (I have an EPIA)
<Amaranth> Rotund: Snag the source package for the kernels breezy has and make a patch
<bmonty> elmo: please sync gnome-alsamixer from unstable, tested in breezy pbuilder and it builds fine, thanks
<Rotund> Amaranth: Could I submit it?  or would it not be looked at until dapper?
<Amaranth> not a chance until dapper, too close to release to touch the kernel for anything
<Rotund> I know a bunch of people on the Via Arena website are looking into Ubuntu for their EPIAs and looking elsewhere.
<Rotund> Amaranth: Wasn't sure if it could be added in an "update"
<elmo> bmonty: done
<bmonty> elmo: thanks
<fabbione> morning
<tambaqui> In Brazil  night
<tambaqui> :)
<fabbione> Riddell: did you decide to upload more pkgs than seb in one go?
<Riddell> fabbione: I havn't started the kde-i18n upload yet...
<fabbione> well that's arch all
<fabbione> it doesn't bother me :)
<fabbione> the rest just takes ages to build
<tritium> thanks for your help with xfig/launchpad, elmo 
<bddebian> Heya tritium 
<tritium> hi bddebian :)
<fabbione> Riddell: is there any specific build order for all the stuff you are uploading?
<fabbione> or it will just work because of proper B-D?
<poningru> question about the open cd will the windows component have the latest stuff?
<poningru> bbl
<joe_> Can someone tell me what packages were just added to the repository in the last 12 hours?
<joe_> My computer won't work now and theres a bunch of others in #ubuntu w/ odd problems
<bmonty> joe_: have you checked the breezy-changes list?
<joe_> sorry, I'm on a computer attached to a TV now cuz my other one doesn't work
<joe_> I can't seem to get permissions to anything, even when I was in recovery mode
<fabbione> amen
<fabbione> elmo: are you still around?
<joe_> amen?
<fabbione> joe_: not for you
<elmo> fabbione: kind of
<fabbione> elmo: i am getting connection refused from archive.ubuntu.com
<fabbione> did apache die again?
<fabbione> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/breezy/multiverse/source/Release  Could not connect to archive.ubuntu.com:80 (82.211.81.182). - connect (61 Connection refused) [IP: 82.211.81.182 80] 
<elmo> blah, yes
<elmo> I knew there was a reason I stay up till 6 on sundays
<fabbione> :)
<elmo> fixed
<elmo> thanks
<fabbione> thanks
<ajmitch> elmo: could you sync libgringotts please?
<tritium> elmo: could you please sync texmacs 1.0.5-3 ?
<fabbione> guys.. it's sunday :)
<tritium> sorry elmo, it can wait
<elmo> ajmitch: done
<elmo> tritium: done
<ajmitch> thanks :)
<tritium> thanks :)
<Lathiat> Riddell: how rsyncable are kubuntu isos to ubuntu ones?
<Lathiat> maswan: about?
<sivang> Morning al
<sivang> or rather, all
<robitaille> I just looked at the logs of the last doc team meeting on Friday.  It was a very short one...
<robitaille> and since there wasn't a TechBoard meeting this week either.  I guess it was a bad week for meetings :(
<bob2> hah
<sivang> I wonder how TB can affect all others :)
<bob2> postfix isn't installed by default anymore?
<robitaille> bob2,  appears that way.  I still have it on my hoary-dist-upgraded computer, but my fresh RC install doesn't have it.
<robitaille> should be breezy-dist-upgraded...
<sivang> c'y all, going to work
<newob> wuz up 
<newob> how are we deving
<Lathiat> infinity: that pppoe bug isnt fixed
<Lathiat> infinity: about not bringing the network interface up (10080)
<Lathiat> infinity: ah, judging by the changelog its supposed to add a section to interfaces, that will still break upgrades
<Lathiat> infinity: heh *and* to add to that
<Lathiat> infinity: the network/interfaces change it makes when you reconfigure it doesnt even work
<\sh> mdz / Kamion: ping can one of you approve a small patch for closing http://bugzilla.ubuntu.com/show_bug.cgi?id=11459 which I sadly forgot since 3 months? :(
<mdz> \sh: fine
<\sh> mdz: thx
<zyga> morning
<pef> hello
<\sh> mdz: uploaded
<pef> when is the next meeting of the Technical Board ? wikipage is outdated https://wiki.ubuntu.com/TechnicalBoardAgenda
<sivang> re morning all
<infinity> Lathiat : Have you tested the patch in the bug report?
<fabbione> mdz: ping?
<sabdfl> hey fabbione. how's life in the sparc world?
<fabbione> sabdfl: rocking! oo2 is very close to the end of the build.. added another buildd right this morning to the rotation
<sabdfl> nice!
<fabbione> sabdfl: my inbox is overloaded with patches from david :)
<sabdfl> miller?
<fabbione> sabdfl: it will be a bit grumpy.. but well
<fabbione> yes
<sabdfl> cool
<fabbione> he is using Ubuntu on a couple of boxes afaik
<fabbione> sparc..
<fabbione> sabdfl: how is life in uk?
<sabdfl> good. i'm trying to get the soyuz pages up to speed, so we can see which packages are actually going into dapper :-)
<fabbione> nice :)
<fabbione> anything i can help testing?
<sabdfl> not yet
<fabbione> ok
<fabbione> than i am going back to finish warty kernel security
<sivang> Mithrandir: I've not yet tested with your disabled inotify kernels, however since last night's update - the machine seems responsive again, and even the desktop slowness in moving windows and alike is basically gone =)
<Lathiat> infinity: i thought you applied that?
<infinity> Not unless someone else did.  I know I didn't.
<infinity> Lathiat : If I could get some feedback on that patch, I'd be happy to apply it.  I'm not using PPPoE here, so I have to follow the logic through and say "yeah, I guess that looks right", which kinda sucks.
<infinity> (and sucks even more, if we're talking about uploading a fix in the 3 days before release)
<Lathiat> infinity: ok
<Lathiat> well i run it here
<Lathiat> so i can try it
<infinity> Please do.
<fabbione> sivang: i am so much convinced that's not a kernel problem...
<infinity> The three cases worth looking at are 1) Does it work at all, 2) do upgrades from hoary work, 3) is there any way we can clean up broken interfaces files?
<infinity> Lathiat : Case (3) is less important then the first 2, obviously, and if we can't fix them without intrusive changes, we shouldn't try.
<\sh> btw..until when are the buildds open for changes? 12th 23:59? 
<Lathiat> infinity: im sure we never had to do this before
<Lathiat> infinity: cant pppoe just be made to ifconfig <int> up when its activated
* fabbione sighs...
<fabbione> now i remember why i didn't like dpatch in warty :)
<infinity> Lathiat : Are you sure the pre-up wasn't rewuired in hoary?
<infinity> required, even.
<Lathiat> i dont recall it
<Lathiat> i'd have to install hoary to find out
<Lathiat> which is painful
<Lathiat> let me look at the hoary era package and see what it was doing
<Lathiat> infinity: any idea what version was in hoary?
<Lathiat> of rp-pppoe and of pppoeconf
<janimo> fabbione, I have kernel building question
<Lathiat> ah packages.ubuntu.com knows
<janimo> which is the most efficient (time wise) way of rebuilding a module in the breezy kernel sources
<janimo> I want to test a new uspteram version of a sound driver
<fabbione> janimo: it depends...
<janimo> hand-edit the config file?
<fabbione> no that has nothing to do with the config file
<fabbione> there are several tricks to do that
<fabbione> it also depends how good is your knowledge of kbuild..
<fabbione> what driver is that?
<janimo> intel 802 I think
<janimo> let me see how it's actually called
<janimo> intel8x0.c
<fabbione> infinity: did you manage to sortout that /pmu problem?
<infinity> fabbione : Yup, fixed in the latest pbbuttonsd upload.
<fabbione> janimo: well if the changes are contained only in that file, than it's pretty simple
<Lathiat> infinity: ermm
<fabbione> infinity: ehhe cool
<janimo> I see 2.6.13 and 14 have resume from sleep related changes and I'd like totry them out
<Lathiat> infinity: pppoeconf depends pppoe, but pppoe seems to be in universe?
<fabbione> janimo: are the changes contained only in that file?
<janimo> fabbione, yep and maybe in ac97.c
<infinity> Lathiat : ppp | pppoe... ppp does pppoe now.
<Lathiat> oh i see
<janimo> but for now I think it's only that
<Lathiat> ppp | pppoe
<fabbione> well you need to be sure :)
<Lathiat> right
<janimo> well I am not sure which of the upstream changes could fix my bug ;)
<fabbione> janimo: we can hack that file, but there is no guarantee that it will build
<janimo> but right now I will only rebuild the intel one
<infinity> Lathiat : And that may be where some of the semantic changes are coming from.
<Lathiat> infinity: but was pppoe used in hoary?
<janimo> well I will edit it til it builds I just want tips to make the process fast 
<Lathiat> infinity: it was in universe in hoary too i see
<infinity> Lathiat : And we should probably just respect the new world order, and make sure pppoeconf works as-is.
<janimo> so I don;t wait too much
<fabbione> janimo: let's move to #ubuntu-kernel and i will drive you trough the basic steps
<fabbione> no that won't work
<infinity> Lathiat : pppoe has always been in universe, so probably not.
<infinity> Lathiat : But I see stuff in the Debian changelog about "transition to new pppoe on boot" stuff.
<Lathiat> infinity: yeh
<Lathiat> i was wondering about that
<infinity> Lathiat : And the bugs in bugzilla about "I have to set up pppoe on every reboot" were originally from hoary, not breezy.
<Lathiat> any which way
<Lathiat> it doesnt bring the interface up
<Lathiat> and that stanza in the apckage it now creates, doesnt do anything
<Lathiat> if i ifup with that, the interface is still down
<infinity> Well, cause it needs a pre-up, right?
<infinity> Is it not getting one?
<Lathiat> auto eth1
<Lathiat>     iface eth1 inet manual
<Lathiat> thats all it puts
<Lathiat> infinity: the 'new ppp on boot' might be
<Lathiat> auto dsl-provider
<Lathiat> iface dsl-provider inet ppp
<Lathiat> provider dsl-provider
<Lathiat> ^^ that
<Lathiat> iirc it didnt do that before
<Lathiat> and had some magic trigger script
<Lathiat> infinity: so i figure all we need
* infinity really wishes he had some sort of PPPoE connection here to test.
<Lathiat> is a pre-up in that section
<Lathiat> to ifconfig eth1 up
<Lathiat> however, i wonder if that gets created on upgrade
<Lathiat> cant see a postinst in pppoeconf
* infinity runs ppoeconf for kicks and sees what it does here.
<Lathiat> infinity: it wont find a concentrator
<Lathiat> infinity: so wont do anything
<Lathiat> wonder if theres any pppoe servers for linux ;p
<infinity> It won't let me do it manually?
<Lathiat> noo
<Lathiat> might be an option
<Lathiat> man page isnt indicative of that
<Lathiat> i'll try delete all my dsl stuff
<Lathiat> and reconfigure it
<Lathiat> and see what happens
<Lathiat> but installing hoary is goign to be a hassle because i dont have a working cd drive atm
<Lathiat> ah i know, i can run a hoary livecd on my other laptop and connect the modem to that
<fabbione> Riddell: kdebindings is FTBFS
<fabbione> Riddell: i think it needs to grow a ruby-dev B-D
<Lathiat> thats what i'll do
<Lathiat> infinity: be back in a bit, breaking my internet. :)
<infinity> Alright.
<sivang> fabbione: I wonder if it's really GNOME that's been causing this, or the X server itself.
* infinity blinks.
<infinity> KEYBUK!!
<fabbione> sivang: i blame gamin.. really
<sivang> fabbione: moreover, I'm curious to know what have changed from before yesterday
<infinity> dpkg: unknown option --print-gnu-build-architecture
<fabbione> sivang: check -changes
<infinity> Good thing we don't use that anywhere...
* sivang pokes changes
<infinity> Oh, wait, we shouldn't.
<infinity> mac-fdisk is behind the curve.
* infinity grumps.
<sivang> here's Riddle's multitude of KDE uploads, looking looking..
<Mithrandir> sivang: heh, ok.
<sivang> Mithrandir: maybe I can get even greater performance boost with your kernel ? ;-)
<sivang> (/me thinks of experimenting)
<Lathiat> infinity: ok
<Lathiat> infinity: so, when you run pon dsl-provider
<Lathiat> infinity: it if ifconfig ups the interface
<Lathiat> infinity: and nothing is put in /etc/network/interfaces
<fabbione> Mithrandir: do you have an amd64 where you could kindly test a hoary kernel?
<Lathiat> infinity: i guess it was done at the ppp level
<Lathiat> since pppd call dsl-provider is what pon calls
<infinity> Lathiat : And that no longer happens?
<Lathiat> infinity: right
<Lathiat> just sourcing ppp to have a look now
* fabbione sends a hidden message to infinity to look around
<infinity> Lathiat : Is the /etc/peers/dsl-provider file basically the same?
<infinity> * Removed patch 057_pppoe-interface-change which was refused by the
<infinity>      upstream maintainer. Now users must arrange for the ethernet
<infinity>      interface used for PPPoE to be up. (Closes: #279135)
<Lathiat> ah
<Lathiat> can we put it back? because that breaks upgrades and sucks :\
<sivang> fabbione: bah, I recalled I emptied my -changes last night, what a cuinicidence 
<infinity> Lathiat : I dunno... I'm not inclined to diverge from upstream too much..
<infinity> Lathiat : Is there a clever way we can deduce a user's current config and upgrade them seamlessly to the new config?
<infinity> Lathiat : Can you get me a "fresh hoary config" for your PPPoE, and a "fresh breezy config" (ie: not upgraded)?
<Lathiat> infinity: well
<Lathiat> infinity: upgrading from hoary
<infinity> Lathiat : Maybe i can figure out an easy way to get us from A to B.
<Lathiat> infinity: theres no stanzo in /etc/network/interfaces
<Lathiat> when you reconfigure, it adds one
<Lathiat> (it doesnt do that on upgrade)
<Lathiat> but that stanza doesn't actually work
<Lathiat> so we need to figure out what will work
<Lathiat> i have no idea, im sure that inet manual thing used to work
<infinity> Well, I assume that patch in the bug is meant to make the stanza work.
<Lathiat> ah ok, well i'll try that
<Lathiat> but
<Lathiat> things will still break
<Lathiat> but we'll sort that out next
<Lathiat> infinity: ah i see
<Lathiat> infinity: that patch adds a pre-up to the ppp0 stanzo
<j^> why is there "Login Photo" and "About Me" in System->Preferences
<Lathiat> j^: changing my "user image" doesnt change it in about me
<Lathiat> user image = login photo
<Lathiat> changing it in about me changes 'user image' tho
<Mithrandir> sivang: feel free to try.
<j^> Lathiat so Login Photo could go
<Mithrandir> fabbione: I could install hoary on this box and try; security update?
<Lathiat> j^: right
<Lathiat> infinity: mm that patch has a # FIXME ;)
<infinity> All good patches do. :)
<fabbione> Mithrandir: it's ok if it is running breezy, i only need a test.. yes security update
<fabbione> Mithrandir: there is an amd64 patch that is quite intrusive and right now i am using my box to fix warty too.. so an extra test will be appreciated
<infinity> Well, only one FTBFS in breezy-autotest (not counting ia64 failures..) so far.  Could be worse.
<infinity> Of course, half of KDE just failed to build overnight.
<Lathiat> yeh that error confuses me
<fabbione> Mithrandir: concordia:~fabbione/amd64/linux-image* <- pick the one that fits you better
<Lathiat> it says it faile dto satisfy a dep after installing
<Lathiat> but if it had a versione ddep, why did it try to install it in the first place
<infinity> Lathiat : Hrm?.. Which package?
* Lathiat finds an example
<infinity> Lathiat : But, to answer your question, sbuild installs all build-deps, then checks the versions if installed packages.  Broken, perhaps, but it's old crusty code, and no one's changed it.
<infinity> (Actually, not entirely true.  I have a patch that changes that behaviour, but I'v enot applied it, for fear of the instability it may bring)
<Lathiat> infinity: ah ok
<Lathiat> infinity: unlike pbuilder
<Lathiat> kdeaccessibility (i386) is an example
<Lathiat> but from what you just aid that makes sense
<infinity> Well, that would have gone into dep-wait anyway.
<infinity> So I don't much care.
<Lathiat> except it didnt? ;p
<Lathiat> or it did after?
<infinity> I'm talking about real failures, of which there are 5 or 6 already.
<Lathiat> infinity: right
<infinity> Failed log mentioning broken deps -> mailed to log munger -> gets munged -> gets set to dep-wait.
<Lathiat> infinity: ah ok
<infinity> There's no way to tell from the logs if something is dep-wait or failed unless you know the regexps.
<Lathiat> sounds dodgy :)
<infinity> Well, the wanna-build mail interface was originally designed for humans to parse and respond to it.
<infinity> The current scripts in place are a bit of a hack.
<infinity> And occasionally get things wrong...
<infinity> But are mostly okay.
<infinity> In Debian, there've been some changes to do dep-waits when importing packages to wanna-build and such, so they never reach the buildds, but we're not bringing those changes into Ubuntu, as we're anticipating switching to the Launchpad infrastructure Real Soon Now(tm)
<Lathiat> me nods
<ajmitch> yay
* Lathiat passes himself a /
<Lathiat> i do like that ubuntu builds everythign from source
<Lathiat> i only just foudn out that debian peoploe upload the arch they use :\
<Lathiat> damn lag
<infinity> There's been contention over that in Debian for YEARS.
<infinity> It's one good argument to run a !i386 arch, since most of your packages will be autobuilt. :)
<Lathiat> at the very least, building from source is a) 1 level extra making sure the binary packages are really matchign the source and b) makes sure the developers are getting their build-deps etc right and not infectinb builds with crap on their personal systems
<Lathiat> i mean it tends to be pretty good for the most part, but still
<Lathiat> things like compiling in the presence of nvidia-glx
<Lathiat> just 1 example that pops into mind
<Lathiat> thats bitten me a couple times
<infinity> had packages depending on nvidia-glx instead of libgl-mesa?
<Lathiat> i've seen that too
<Lathiat> but sometimes compilign with nvidia-glx causes a ftbfs
<Lathiat> or somethign that doesnt run properly against !nvidia
<Lathiat> lathiat@qapla:~/devel/ubuntu$ grep-dctrl -FBuild-Depends nvidia-glx-dev Sources-breezy -sPackage,Build-Depends|grep Package:
<Lathiat> Package: boson-base
<Lathiat> Package: crystalspace
<Lathiat> Package: searchandrescue
<Lathiat> haha, go my brain
<Lathiat> -sPackage,Build-Depends|grep Package
<tseng> clever
<\sh> Lathiat: boson-base, crystalspace are worldforge sources, right? they're crap somehow 
<Lathiat> oh yeh :)
<Lathiat> \sh: crystalspace is a d game development kit
<Lathiat> boson-base is an opengl RTS for kde
<Lathiat> s&r is some thign to fly aircraft to pick up people in distress
<infinity> Kamion : Does a rebuild of mac-fdisk require a new d-i build on PPC?... Or is the udeb not included in d-i?
<\sh> Lathiat: yeah...but boson-base in universe is breaking because of old include depends of kde <old version> and the new one brings in old sources from old kde upstream and ftbfs again :(
<infinity> Kamion : Cause I just uploaded a new mac-fdisk to fix an FTBFS. :/
<fabbione> infinity: we need to rebuild d-i anyway
<fabbione> so don't worry about it
<fabbione> we need to get the latest kernel into the different images
<Lathiat> \sh: boson-base has gcc4 issues
<Lathiat> even the new upstream faisl to uild on gcc4
<\sh> Lathiat: it has old kde gcc4 issues 
<infinity> fabbione : Okay, cool.
<\sh> Lathiat: it delivers now old sources from old kde kdegames stuff
<Lathiat> \sh: ah
<infinity> Hrm.
<\sh> Lathiat: that's why I sad everything from worldforge is crap ;)
<\sh> Lathiat: and I gave up on fixing their stuff :(
<infinity> Did cupsys just grow a build-dep on libfontconfig-dev, or did one of its other build-deps stop depending on it?
<\sh> now lets have a look why blender is on the universe ftbfs list
<infinity> Interesting, something did recently stop depending on libfontconfig1-dev.  Great.
<infinity> And by "recently", I mean "in the last 3 weeks"
* infinity grumps.
<maswan> Lathiat: nope, gone again any minute
<fabbione> maswan: hey due
<fabbione> dude
<maswan> fabbione: yes?
<fabbione> maswan: i think i have a kernel fix for linux crashing on buttercup :) do you think you can bring it up again monday?
<maswan> fabbione: yeah, I think so.
<fabbione> i need to test a kernel.. thanks a lot
<fabbione> have a good we :)
<maswan> the ftp cluster maintenance is higher pirority though, but we should manage to pull and push a few hotswap disks and reboot it at least. :)
<fabbione> maswan: sure.. if you can is good.. otherwise is still good :)
<Lathiat> maswan: 'sok
<infinity> elmo : source package "aspell-es" needs to be removed from breezy, it's superceded by "espa-nol", which provides the same (and more) binary package.
<zyga> is there any idea to setup a ubuntu knowledge base?
<zyga> like all the people keep asking 'how to do X' where X is a common task
<Yagisan> zyga: isn't that called the ubuntu wiki ?
<zyga> Yagisan: hmm ubuntu wiki lacks the newbie approach
<zyga> (I never redirected anyone to a wiki page, probably because I don't know any usefull pages for them to check)
<tseng> so add it.
<tseng> you'll want to see #ubuntu-docs
<mdke> please please please don't set up a NEW category of knowledge
<zyga> tseng: :)
<mdke> there are already too many, the best approach is to work to improve the existing ones
<Yagisan> zyga: I know - there are gems in there, it's just most people don't copy it from the forums or where ever
<tseng> mdke++
<zyga> tseng: #u-docs is empty
<mdke> zyga, #ubuntu-doc
<zyga> I like the unofficial ubuntu guide
<zyga> it does answer most newbie (window porters) questions
<zyga> but it's too automatic
<zyga> no explanation
<zyga> just apt-get...
<Yagisan> zyga: The incorrect unofficial ubuntu guide ?
<zyga> Yagisan: yes ;] 
<zyga> Yagisan: it's got the newbie approach - I didn't check the correctnes really
<Yagisan> zyga: that's not something I'd send new people too. The newbies I test ubuntu on usually  don't need it
<mdke> guys
<mdke> take it to #-doc please
<zyga> sure
<mdke> the devels need to work
<\sh> please...new users are not named as newbies...we call them "New Users"
<Yagisan> mdke: no worries
<zyga> \sh: that requires quoting due to the space, it's very non-unixish..
<zyga> (eot)
<\sh> zyga: but it's friendly to new users exploring our community
<\sh> -EOT 
<\sh> morning mvo ;)
<mvo> \sh: hey
<mdke> hey mvo
<mdke> have you nailed that notifier thing?
<mvo> mdke: still on it, but making good progress :)
<mdke> great
<Mithrandir> fabbione: anything in particular I should test with it, or just run it for a bit?
<infinity> Mithrandir : If it boots, that's probbaly good.
<Lathiat> mvo: did you try my patch for the lines?
<mvo> Lathiat: which one in particular?
* mvo waves to dho
* mvo waves to dholbach 
<Lathiat> mvo: the oen on the bug report
<Lathiat> mvo: ixes the incorrect arrow drawing
<Lathiat> *fixes
<dholbach> hi
<dholbach> hey mvo
<fabbione> Mithrandir: like infinity said.. try to stress the memory a bit..
<fabbione> Mithrandir: nothing too fancy really
* fabbione -> food
* Lathiat tries to find the bug report and fails
<Lathiat> 14006
<Lathiat> http://bugzilla.ubuntu.com/show_bug.cgi?id=14006
<mvo> Lathiat: sorry, didn't managed to look at it yet, will do that today
<Lathiat> mvo: ok, beware that patch file i think integrates part of debian/patches/04[hatever] 
<Lathiat> might require some manual mguning
<Lathiat> i only changed the section under ::UP
<Riddell> fabbione: build-depens should sort out the build order
<fabbione> Riddell: ok
<infinity> Riddell : Want to fix kdebindings' FTBFS?
<Riddell> infinity: I'm working on it
<infinity> (I was about to do it, but since yu showed up..)
<Riddell> infinity: oh go ahead, I have other FTBFSs to fix too
<infinity> I noticed. :)
<zoot_> mvo: hi, just upgraded to update-notifier-0.40.13.1 as per bug #17091 and so far, no light bulb after reboot :)
<mvo> zoot_: cool, thanks for testing! you may want to stress it a bit by (re-)install a kernel or dbus 
<zoot_> mvo: ok, will do
<mvo> zoot_: thanks! please let me know if anything strange/unusual happens
<zoot_> mvo: k
<Riddell> Kamion: MD5SUMS on kubuntu RC is missing a lot of the files
<speel> hey will the spca5xx driver get fixed within the next few days ( well before breezy comes out ) ?
<mvo> Kamion: please approve updaet-notifier updates. fixes two bugs in the post-update information logic (debdiff is at http://people.ubuntu.com/~mvo/update-notifier/update-notifier_0.40.13.debdiff)
<mull> hi folks
<mull> I think I found a bug in Breezy
<Lathiat> mull: what package?
<mull> gnome-keyboard indicator applet
<Lathiat> then you could have a quick search and/or file a bug at http://bugzilla.ubuntu.com
<mull> ok
<Lathiat> package is probably gnome-applets.. let me check that
<Lathiat> indeed
<mull> yes it is
<mull> I just looked myself
<mull> Ok i'll file the bug
<Lathiat> thanks
<Lathiat> mjg59: hrm something interesting
<Lathiat> mjg59: i installed kubuntu, and usplash survives the time of "Loading modules"
<Lathiat> mjg59: in ubuntu, it fails, every single boot of the last 15 or so
<Lathiat> i'll see what happens post-install
<Lathiat> might effect it
<zoot_> mvo: just upgraded to the latest -686 kernel, rebooted (after light bulb appeared) and so far, the light blub hasn't appeared - looks like the bug is squashed :)
<spayne> jdub: ping
<mdke> mvo, testing new update-notifier now
<mvo> zoot_, mdke: thanks
<zoot_> mvo: cool beans ;)
<mdke> mvo, i installed it and rebooted and I didn't get the notification. So looks like it has worked
<mvo> mdke: cool, thanks :)
* mvo is reliefed
<\sh> re sabdfl 
<sabdfl> hi?
<jsgotangco> hi sabdfl 
<sabdfl> hey jsgotangco
<Seveas> mvo, I've seen 2 more reports about the lightbuld, didn't close them as dupes yet, but I pointed the reporters to the bug with your solution
<speel> hey i have a question whats the status on the spca5xx bug?
<psichron> lo sabdfl
<\sh> hmm...I think I'll take a nap for 2 hours...
<slomo> how can i get the banshee sourcepackage into malone? or is the package list updated automatically every X days?
<fabbione> doko: ping?
<dholbach> brb
<doko> fabbione: pong
<fabbione> doko: it's installing now
<doko> fabbione: msg me the last lines ;-)
<fabbione> when it finishes :)
<mvo> Seveas: thanks!
<fabbione> doko: see /msg
<bddebian> Hello
<tambaqui> Hello
<jdub> spayne: pong
<jdub> GOOD MORNING FREEDOM LOVERS!
<Lathiat> hey jdub
<sivang> jdub: morning allmighty jdub!
<spayne> jdub: sabdfl answered my question
<spayne> only 4 days left!
<fabbione> mdz: dpkg-deb: building package `openoffice.org2' in `../openoffice.org2_1.9.129-0.1ubuntu4_sparc.deb'.
<jsgotangco> morning jdub 
<zakame> hi jdub 
<slomo> spayne: you have an ipod, don't you?
<jsgotangco> jdub, how's the summit?
<spayne> yeh - which doesn't work with Banshee
<slomo> spayne: fine... that's what i wanted to ask you :P only since the new version or even before?
<spayne> slomo: before
<slomo> spayne: what ipod model do you have?
<spayne> slomo: 3G 20gb
<jdub> jsgotangco: pretty cool
<spayne> it is because i have had it on iTunes 5
<slomo> spayne: database format > 14?
<spayne> 15
<slomo> spayne: ok, forget it :P can't this be downgraded somehow?
<slomo> spayne: ?
<spayne> slomo: sorry, yeh - i will look at it later
<slomo> spayne: thanks... because it seems like it doesn't work anymore :(
<tseng> spayne: database 15 works with banshee now
<tseng> spayne: we uploaded new versions..
<slomo> spayne: 15 works now? are you sure?
<spayne> don't think so
<slomo> tseng: * src/SongDatabase.cs: Throw an unsupported exception if DB version is
<slomo>  greater than 14
<tseng> uh
<tseng> i am sure i saw them fix db v15
<zyga> why does ubuntu-minimal depend on reiser4progs?
<spayne> slomo: i can get my ipod to mount!
<the--dud> just a little thought... shouldnt 5.10 be released 9 day ago actually?
<slomo> spayne: does it even work in banshee?
<spayne> the system isn't mounting it when i plug it it!
<infinity> Riddell : kdebindings fixes upload, you owe me at UBZ.
<infinity> Riddell : s/upload/uploaded/
<dholbach> re
<jsgotangco> hi dholbach 
<dholbach> hey jerome
<zakame> wb dholbach 
* fabbione waves his sparc fist in front of the community 
<fabbione> doko: openoffice.org2_1.9.129-0.1ubuntu4_sparc.changes ACCEPTED
<bob2> hah
<fabbione> Build needed 43:34:00, 8903296k disk space
<fabbione> now it's all ccached :)
<fabbione> UHA UHA UHA
<infinity> Nah, cause there'll be a gcc upload before the next openoffice upload.
<Lathiat> heh
<fabbione> infinity: that means that doko will sign his death certificate :P
<doko> sure, the first upload for dapper is a gcc-4.0 update :-)
<fabbione> doko: dapper is not a problem.. 
<infinity> doko : How far away is 4.1?
<doko> not yet branched
<infinity> That doesn't sound promising.
<infinity> So, 4.0.x for dapper seems more likely?
<infinity> (Since we're going to want to pick a version, freeze it,and stabilise it pretty early one)
<infinity> s/one/on/
<fabbione> doko: we will need to fix libgcc on sparc (4.0) for dapper
<fabbione> doko: but we will work on it as soon as dapper open
<doko> fabbione: what is wrong?
<fabbione> doko: weird stuff when building klibc
<fabbione> we had to switch klibc back to 3.4
<fabbione> but it was too late in the process to fix 4.0
<sivang> fabbione: klibc = kernel libc ?
<fabbione> doko: http://bld-3.mmjgroup.com/buildLogs/k/klibc/1.0.14-1ubuntu2/klibc_1.0.14-1ubuntu2_20050915-0618-sparc-failed.gz
<fabbione> sivang: more or less yes
<fabbione> anyway
<fabbione> it's time to finish to mount the ceiling lists :)
* fabbione &
<bob2> hah
<sivang> fabbione does alot of renovations realtive to being a deep kernel hacker :-)
<sivang> I wonder if there are simialr traits which you shoudl have to be successful at both
<elvirolo> hi all
<elvirolo> does anyone know whether the spca5xx bug will be fixed or not before the release of breezy ?
<elvirolo> it is very critical
<mvirkkil> Is someone working on dotUbuntu or any kind of jabber/xmpp styff for Ubuntu?
<mvirkkil> stuff, even.
<sivang> mvirkkil: there are plans. I know Robot101 was working on something as well
<mvirkkil> sivang: Wondering because I've been thinking about an interactive help system which would be based on xmmp.
<sivang> mvirkkil: if you want to suggest it as something to be discussed over the next Developrs summit, feel free to outline it on the wiki
<mvirkkil> sivang: Weeeell... I was hoping on having some very casual brainstorming about it, but it seems the ubuntu-doc channel is pretty dead atm. 
<sivang> mvirkkil: if this is a development subject, there are alwasy mailing lists 
<mvirkkil> sivang: Where should I link the page to, so that people will actually find it?
<sivang> mvirkkil: if that's a suggestion, put it somewhere on the wiki and email the -doc or other list you think relevant with request for feedback, or  just link it from the UbuntuBelowZero/BOFs page on the wiki
<mvirkkil> sivang: Thanks, I'll try to write something on the wiki :)
<sivang> mvirkkil: no prob, ideas are always welcome!
<the--dud> dotUbuntu? whats that going to be?
<Robot101> sivang: we did an UbuntuIMSpec
<\sh> anyone as an idea where TIOCGDEV is declared?
<\sh> has even
<wasabi> make-kpkg modules_image should be updated to properly append EXTRAVERSION for Ubuntu, I suspose.
<wasabi> hmm. latest breezy throws a kernel stack trace on boot heh
<wasabi> not good!
<wasabi> and a dozen seg faults
<magnon> does anyone by any chance speak portuguese here?
<dholbach> hi mvo
<wasabi> jbailey, pingaling
<mvo> Kamion: do you need a debdiff for the approval of update-notifier?
<segfault> magnon: i do.
<dholbach> elmo: could you please sync xmame from sid?
<jbailey> wasabi: Sort of here.  Doing some exercises and just taking a break for a moment.
<wasabi> Found a few things in the base initramfs that need a bit of changing
<wasabi> In local it tests for  the existance of $ROOT, after local-top... which is great in most cases, but not mine
<jbailey> Err..  You don't means like urgently for Breezy, do you?
<wasabi> No.
<jbailey> Oh good. =)
<wasabi> That's in mountroot()
<wasabi> also it tries to actually mount it, always.
<wasabi> In my case, one of the custom scripts does teh actual mounting job, and no ROOT is passed on cmdline
<wasabi> (unionfs)
<jbailey> Hmm
<jbailey> It may be that your case is too complicated to use the general stuff in local.
<jbailey> I'd hate to complicate it for a strange corner case.
<wasabi> Hmm. So you would use another type completely?
<wasabi> such as flash
<jbailey> I might, yeah.
<jbailey> Right. =)
<wasabi> Hmm. Didn't think about that.
<jbailey> 'cause at the point when the model is being stretched that far, I don't see any point in trying.
<wasabi> I see.
<wasabi> Yeah, you are completely right.
<jbailey> What I love about initramfs-tools is that the cases are simple enough to understand why they're the way they are. =)
<wasabi> I'll start working on this new case then. "flash" is a good name for it, perhaps?
<jbailey> Sounds good to me.
<jbailey> Maybe wait a few days to avoid getting lost in the noise of the release, butpost it to ubuntu-devel and get other cases that people might want covered.
<jbailey> I think that this could be more generic than flash devices - like for appliances where a binary blob is shipped in general.
<jbailey> For when Cisco gives up on IOS and goes with Ubuntu instead ;)
<wasabi> Yeah.
<wasabi> Haha.
<ajmitch> morning
<\sh> jbailey: ?? cisco appliances could run linux ;) 
<wasabi> Yeah, PIX can right now. ;)
<wasabi> ubuntu even
<wasabi> it's just an x86
<jbailey> g'm Andrew
<\sh> jbailey: but more interesting is, if a juniper m160 is running with linux ;) 
<jbailey> \sh: IIRC, The Junipers are based off of something in the BSD familar.
<jbailey> family, rather.
<\sh> jbailey: yeah...
<jbailey> It's possible to get the GNU utilities ported to it already.
<\sh> jbailey: it's done already ;)
<jbailey> At my last job, we all had Cisco tatooed to our asses, our we would've considered looking more carefully at the Juniper stuff.
<jbailey> But with 600 cisco routers, it's hard to consider switching. =)
<jbailey> We got one of the Juniper firewall products..
<jbailey> Hmm
<\sh> jbailey: both are nice..I learned on cisco and I had a juniper training last month...but thinking about this, the juniper JunOS config script is much nicer then the cisco one ;) 
<jbailey> netscreen?
<jbailey> Mmm, nice is relative.  The difference is that I can sit down in front of any Cisco router made in the last decade and solve your problems without refering to a manual.
<jbailey> And i'm fairly certain that I'll generally be able to for another decade.
<\sh> jbailey: well, that's right :) this is as well a big advantage of cisco :) 
<jbailey> Heck, even catalysts are starting to finally integrate.
<\sh> jbailey: but reading junOS config is just like reading a perl script 
<jbailey> IOS on their phone systems would be nice.
<wasabi>              panic "ALERT!  ${ROOT} does not exist.  Dropping to a shell!"
<wasabi> That message sucks.
<jbailey> \sh: That's not something I would put in a marketing brochure.
<wasabi> Because if ROOT is not set, it's called.
<jbailey> wasabi: If root's not set in the current local script, you're pretty screwed.
<\sh> jbailey: this was the first thought I had, when I saw the config ;)
<wasabi> Yeah, but it'd be nice to error better. ;)
<sivang> re all
<jbailey> wasabi: "No root varilable set.  WTF were you thinking?" is probably not approved by our PR department. ;)
<jbailey> Heya Sivan
<\sh> re sivang 
<sivang> jbailey: Jeff ! :)
<grout> elmo here?
<\sh> who was talking this morning about pppoe and problems with the interface going up?
<ajmitch> Lathiat
<\sh> Lathiat: ping :) do u have a bug ref?
<fredix> hi
<fredix> does anyone can update ruby into breezy ? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322346
<wasabi> g-v-m isn't mounting removable stuff sync all the time. =/
<dholbach> fredix: i'm sure it will get considered
<fredix> dholbach: before 13 oct ?
<dholbach> considered, i won't promise anything
<fredix> i hope
<dholbach> but if it renders ruby completely unusable, ...
<fredix> thanks
<wasabi> unionfs is unstable. =(
<lucas> dholbach: should fredix file a bug to make sure it will be considered ?
<dholbach> lucas: sure
<ajmitch> dholbach: I think it has been considered but it's a massive debdiff to check, and it's in main
<dholbach> ajmitch: yes, i thought so too, but as it seems to be of HIGH priority and the old version seems to break stuff heavily...
<slomo> ajmitch: the diff shouldn't be that big... the guy who have done the debdiff hasn't done it properly...
<hwaara> mpt!
<wasabi> /etc/mtab confuses me
<wasabi> jbailey, got it mounting with rw / with unionfs. ;)
<wasabi> Writing saving routine now.
<lamont> bob2: no default MTA as part of desktop.  this is a good thing.
<slomo> ajmitch: the diff is really to big... even after doing it properly :(
<jbailey> wasabi: Nice!  It's all working for you?
<wasabi> Yup. I redid everthing into a single class script
<wasabi> now you pass boot=flash flashdev=/dev/hda1 flashimg=/root.img to boot
<wasabi> and it works.
<jbailey> Nice.  Much complication saved, I imagine. =)
<wasabi> Yes.
<wasabi> Trying to think about configuration
<wasabi> root.img will be a basic install, customized.
<wasabi> config.tar.gz will be saved configuration files.
<wasabi> (extracted into overlay on boot)
<wasabi> Now, on first boot, I want to launch the base-setup thing properly.
<wasabi> Which sets up, and then /usr/sbin/flash save
<wasabi> /etc/flash.save lists files to persist.
<wasabi> I guess what I really want is to kick of d-i
<wasabi> just like the live cd
<mpt> hwaara!
<mpt> Welcome!
<hwaara> mpt, thanks! :)
<sabdfl> hey guys
<sabdfl> how do i change the keyboard mapping?
<sabdfl> i got the wrong one during install
<siretart> setxkbmap us
<sabdfl> i don't think its the xkbmap
<sabdfl> is there something at the low-level?
<\sh> locales are correct? 
<sabdfl> how do i test?
<\sh> so dpkg-reconfigure console-data or something?
<carstenh> iirc dpkg-reconfigure xserver-xorg for x
<sabdfl> i want to repeat the questions that it asked during install
<carstenh> iirc dpkg-reconfigure xserver-xorg for x
<\sh> sabdfl: i think this is correct...so dpkg-reconfigure console-data
<sabdfl> dpkg-reconfigure console-data doesn't do the trick
<siretart> sabdfl: are you talking about X or console? afaik the installer configures both indipendently
<\sh> sabdfl: the start of the install is 3 things in one...locales, console-data and according to this setting xkbmap
* mpt smells the need for a graphical keyboard layout switcher
<\sh> so dpkg-reconfigure + one of {locales,console-data,xserver-xorg}
<sabdfl> ok
<\sh> or try to use the gnome keyboard change util in system/administration
<\sh> for Xorg
<\sh> locales -> language, date, currency, etc  / console-data -> console keymap / xserver-xorg -> settings of keymap in xorg
<torkel> you can also use loadkeys to switch the console keymapping
<lifeless> I have a question from a friend, do we expect oprofile to work out of the box ?
<lifeless> ignore that, its in universe. ..
<\sh> lifeless: file a bug in malone or just ask in -motu ;) 
<\sh> a
<lifeless> \sh: beat ya!
<\sh> lifeless: it's late ;) i'm not as fast as I should be at this time of the night ;)
<lifeless> \sh: go to bed then :)
<\sh> lifeless: yeah..that's what I'm doing after my beer is finished..
<\sh> so...last mail to elmo for today...i think that's all for today
<dholbach> good night guys, i'm off
<\sh> cu dholbach 
<\sh> good night to you :)
<dholbach> thank you :)
<slomo> gn8 dholbach :)
<dholbach> bye slomo :)
<Burgundavia> mpt, you tried out gnome-screensaver recently?
<mpt> Burgundavia, not in the past couple of weeks
<Burgundavia> mpt, try it again now
<mpt> I can't, the power cable's broken on my laptop and it's run out of battery
<the--dud> I really fail to see the usefulness of screensavers
<fabbione> sabdfl: did you get the wrong keymap on console or X?
<mdke> jdub, ?
<mdke> jdub, unping, emailed
<Keybuk> that analysis of gnome startup is interesting, especially that the "FontPath unix/:7100" entry in xorg.conf adds 5 idle seconds to the startup
<sivang> Keybuk: does it take so much time to load the fonts from there?
<sivang> (is it a domain socket ?)
<Keybuk> it isn't that, it's the fact we don't actually ship a font server
<lifeless> sivang: I'm guessing its a timeout
<Keybuk> so it spends 5 seconds waiting for it
<lifeless> bingo
<Keybuk> and even if we did ship one, we wouldn't use it because we use Xft2 and fontconfig by default
<sivang> so let's drop that connection timeout away
<lifeless> its a unix socket, it should not need a timeout. its plain weird
<sivang> lifeless: you mean, either we successfuly opened it in an instance, or we didn't and move on with life
<Keybuk> lifeless: it's not a timeout, it's an actual for (i = 0; i < 5; i++) { do it; sleep (1); }
<lifeless> sivang: yes
<Keybuk> type affair
<lifeless> Keybuk: holy fucking crack monkeys batman
<sivang> what lifeless just said
<sivang> :)
<Keybuk> lifeless: because you'd _NEVER_ use sleep (1) in your code <g>
<ajmitch> Keybuk: daniels fixed that in the default config a few weeks ago
<lifeless> Keybuk: not five times!
<Keybuk> ajmitch: indeed
<sivang> Keybuk: why not ?
<Keybuk> I'm just catching up on e-mail
<Keybuk> sivang: lifeless famously "fixed" a baz race condition by sticking a sleep (1) in the code
<lifeless> Keybuk: no scare quotes please, it did fix it.
<sivang> lol
<lifeless> Keybuk: not optimally, but fix it did.
<lifeless> sivang: inode signatures with a granularity of 1 second.
<sivang> eh, sot that's rougly fixing it :)
<lifeless> tla was too slow to trigger failures, so while making baz faster, we started getting test failures.
<Keybuk> it's like taking pain-killers to hide the fact your leg is falling off
<sivang> heheheh
<sivang> lifeless: what a bout a shared memory space for addressing when each of the entities attemting access? :)
<sivang> s/addresing/singaling/
<lifeless> sivang: ewww
#ubuntu-devel 2005-10-15
<sivang> sorry :-/
<qbertibur> hi
<sivang> Keybuk: so , just drop that snippet and we got less 5 idle seconds for gnome boot no ;-) ?
<sivang> hi qbertibur 
<Keybuk> sivang: for us it'd be at the "start gdm" stage
<Keybuk> ajmitch says daniels already did that
<qbertibur> What is the ubuntu way to view dvb-s?
<zyga> is there any #ubuntu-hardware or similar?
<sivang> qbertibur: this is a development channel, could you please ask this in #ubuntu? this is not quite the place to ask such questions.
<ajmitch> sivang: "  * Disable font server in dexconf for mad startup time victory.
<ajmitch> "
<ajmitch> so it's disabled in xorg.conf rather than in the code
<sivang> lol
<sivang> yes, nice
* zyga wonders which fs is best to put on a CF card
<zyga> with very rare updates
<qbertibur> Is anybody using a SkyStar2 with ubuntu?
<sivang> 's late here. Good night all
<blueyed> Could someone please bump the priority for http://bugzilla.ubuntu.com/show_bug.cgi?id=10080 (pppoeconf). There is a confirmed patch and it is critical for release! infinity said he would take a look at it.
<Lathiat> \sh_away: bug ref for?
<Lathiat> \sh_away: oh, 10080
<Lathiat> \sh_away: we found the problem
<Lathiat> \sh_away: the patch to ppp in debain which brings an interface up before using it was backed out
<Lathiat> \sh_away: because it was rejected upstream
<bob2>  7416 rob       16   0  217m 4124 1100 S  0.0  0.8   8:44.01 nm-applet
<tseng> nice!
<bob2> 217MB of virtual space is particularily special when I've disabled it
<tseng> its angry
<hub> bob2: it is a gnome program, right ?
* hub runs
<didymo> lifeless: ping
<didymo> lifeless: just committed bug report as you suggested. Bug 17434
<lifeless> didymo: excellent
<didymo> lifeless: I've joined the ubuntu-devel mailing list. Should I post the bug there as well or just bugzilla?
<lifeless> didymo: only one place
<lifeless> just bugzilla is sufficient.
<didymo> lifeless: cool thanks will leave it then.
<bob2> the new tomboy logo is way less tintinish
<tseng> bob2: upstream hates it
<tseng> i told him i had to replace it and there was a long string of words begining with f
<bob2> haha
<lifeless> I liked tintin
<tseng> id like to see you tell that to debian-legal
* tseng hides
<bob2> I felt better entrusting my notes to tintin than to two squares
<magnon> two LINKED squares, mind you
<lifeless> that makes *all* the difference
<daniels> bug #17394: logo contains 100% less tintin
<magnon> bah, fooled me, daniel
<bob2> that bug does 100% seb, tho
<magnon> tseng: so, in essence: "Sorry, we can't replace the infringing logo, because upstream keeps swearing at us"
<tseng> god
* tseng slaughters roomates
<tseng> between one giggling with his gf and the other yelling at his team on battlefield 2
<tseng> who should die first?
<magnon> Ate, n.: "The goddess of criminal rashness and consequent punishment."
<bob2> tseng: the battlefield guy
<magnon> totally
<bob2> * > gamers
<magnon> hey, I played wow this summer
<tseng> erm
<tseng> welcome back?
<bob2> magnon: be glad you only lost 3 months to it!
<magnon> well, until I figured out that noone were up for playing socially and casually, just out for items and uh, creds
<magnon> so I guess, * > gamers
<magnon> (yes, that's the first mmorpg or anything big I've ever played anywaY)
<magnon> *y
<magnon> bob2: didn't play that much :P
<bob2> I lost a friend to wow for about 3 months...now he's clean and his gf is hooked
<magnon> haha
<bob2> I've been trying to wean them off it with a nice clean coke addiction
<magnon> jesus, gaim so needs support for MSN Spaces
<magnon> people always go "hey, check my new picture or blog thing or whatever", I go "URL?" all I get back is "just check my space!"
<bob2> is that MS's "I can't believe it's not livejournal!"?
<magnon> yeah
<tseng> uh
<magnon> and you get new nicknames for it, unlike MSN profiles which are profiles.msn.com/addy@hotmail.com or something
<magnon> the bastards
<bob2> wow, that's so awesome!!1111
<magnon> you forgot "one"
<daniels> bob2: s/livejournal/myspace/
<daniels> the name kind of gives it away
<magnon> I always thought of myspace as the place people hosted warez when I was 13
* bob2 googles myspace
<bob2> ah
<magnon> apparently they innovated
<tseng> liberate ex infernis
<daniels> magnon: no, that was master.d.o
<magnon> :D
<tseng> substite myspace or livejournal or whatever
<magnon> anyway
<magnon> apparently one of my pretty intellectual friends write on MSN Spaces, people say he writes good articles in his "blog"
<magnon> I should propose to host it I guess, so I won't have to search, I can't fucking find it
<tseng> give him a wordpress install
<magnon> and when I asks for the URL, he's just saying "duh, space"
<tseng> or leave him to rot
<Amaranth> his "space" is based on his MSN Messenger name, iirc
<magnon> it's not, as far as I can see
<magnon> it has nothing to do with his addy, and people's nicknames are often 150chars+ long :P
<magnon> Jesus christ.
<magnon> these spaces things have support for msn smileys
<magnon> ugh
<magnon> it's worse than deviantart
<HrdwrBob> mmm tarts that use debian
<magnon> right, so
<magnon> I'm supposed to set up this server now
<magnon> and the guy who installed it opened ssh and gave me a user, but forgot to add me to adm
<magnon> anyone got a hoary 0-day? :P
<bob2> hoary's default kernel has local root exploites
<bob2> iirc
<ajmitch> depends if he grabbed security updates & rebooted, I guess :)
<magnon> it has 2.6.10-5 atm
<magnon> dunno if that's recent or not tbh
<bob2> that's old
<magnon> cool
<magnon> ah, he just woke up actually, sent me an sms
<magnon> I guess that's a better way. :)
<mjg59> bob2: Uhm. I thought we managed not to break the ABI in Hoary security updates?
<bob2> hrm, you're right, ignore me
<mjg59> 2.6.10-5 could be the latest
<magnon> never mind, got access now.
<magnon> and yes, it's the latest
<wasabi> Hmm so what's the best file system to use for a loopback file system?
<wasabi> I notice cramfs.
<Lathiat> wasabi: depends what you want to do with it
<roxville> hello folks :)
<roxville> ok, i'll try to make it short:
<roxville> i read about a screen vid capture app called istanbul possibly getting incl in ubuntu or edubuntu
<roxville> anybody know anything about it?
<roxville> coz i can't find it anywhere
<Burgundavia> roxville, this is really a #ubuntu question, but it is in Breezy
<Keybuk> syndicate scott% apt-cache policy istanbul
<Keybuk> istanbul:
<Keybuk>   Installed: (none)
<Keybuk>   Candidate: 0.1.1-0ubuntu2
<Keybuk>   Version table:
<Keybuk>      0.1.1-0ubuntu2 0
<roxville> ok Burgundavia thank you! :)
<Keybuk>         500 http://archive.ubuntu.com breezy/universe Packages
* magnon looks from anyone danish
<Treenaks> The danes are coming! ?
<fabbione> yeah yeah i am around :)
<fabbione> morning
<fabbione> magnon: i am not danish, but i live in dk
<jsgotangco> don't forget the pastries
* jsgotangco hides
<fabbione> magnon: anything i can do?
<magnon> fabbione: was looking for danish whitepages online, but I found them at last :)
<Keybuk> morning bella
<fabbione> bella Scott
<Keybuk> ah, freeze work
<Keybuk> week even
<fabbione> Keybuk: how did it go the race yesterday?
<lifeless> wow, nautilus is fragile
<lifeless> its refusing to show my sfs mounted tree :[
<lifeless> segsigv's R us
<bob2> maybe it's taking a strong moral stance against SFS
<Keybuk> fabbione: did you not watch it?!
<fabbione> Keybuk: no
<Keybuk> :-(
<Keybuk> it was a brilliant one
<fabbione> i was preparing hoary/warty security updates
<Keybuk> Kimi and Alonso started from the back row and finished 1/2
<fabbione> putting up cieling lists.. and whatever my wife was asking me to :)
<fabbione> ah
<Keybuk> some utterly fantastic moves
<fabbione> ehhee
<Keybuk> Alonso passed Schumacher flat out at 130R, with the UK commentator screaming "oh my god! he can't do that! he's gonna die!" or words to that effect
<Keybuk> and Kimi only went into first on the LAST LAP
<fabbione> ahahah
<Keybuk> great race
<Keybuk> hasn't sold the constructors yet either, so the last race of the season will end that
<fabbione> did the client managed?
<Keybuk> though Ferrari are now solidly third
<Keybuk> worked fine, once the server started working (it was out for about the first 5 mins)
<fabbione> oh
<fabbione> cool
<fabbione> we should probably consider make a package and stick it in dapper
<fabbione> if you want to be my upstream, i can be your packager :P
<Keybuk> yeah, need to tidy a few things with it first, etc.
<Keybuk> but should be packaged in plenty of time for the new season <g>
<fabbione> ehehe
<fabbione> i need to look at the code
<Keybuk> it's in bzr
<fabbione> i am sure you already separated the decoding engine from the curses display.. didn't you?
<Keybuk> http://www.netsplit.com/bzr/live-f1/
<Keybuk> yup
<fabbione> yes i saw that..
<Keybuk> you can drop in a replacement display.c to do gtk+ or whatever
<fabbione> i need to look at bzr first ;)
<fabbione> or just make the display.c modular
<fabbione> so we can just build all the display we want at once
<Keybuk> yup, either works
<Keybuk> some of it probably needs cleaning up too, the parsing engine is pretty separate but the "actually do shit with the packets" bit is pretty un-modular
<fabbione> hmmm
<Burgundavia> Keybuk, what does this fancy package do?
<fabbione> what we need is the stream manager and a possible replay to feed the same kind of info to the decoding engine
<Keybuk> Burgundavia: it's a client for the Formula 1 Live Timing stream
<fabbione> the decoding engine to export a standard struct of into to the clients.. that could be a curses viewer or gtk or the recorder
<fabbione> i don't think we need much more than that
<Keybuk> yeah, I figure that packet.c should maintain a "state of the race" and call a function pointer to update the screen
<fabbione> we might want to consider to open a 3 stream sessions to gather weather info and the last one with the positions..
<fabbione> if they don't come all on the same stream
* Burgundavia notes that f1 prevents right clicking by some means
<Keybuk> they all come on the same stream
<fabbione> Keybuk: even better
<Keybuk> the reason it doesn't display weather right now is simply that it's not useful static information -- "the track is 23C, so what?  what was it 5 minutes ago, and before that?"
<Keybuk> it needs a graphical client to show graphs and stuff
<fabbione> yes..
<Keybuk> I also want the core to keep history of the race ... right now it just holds the current table, and doesn't record previous values and stuff
<wasabi> So what would be the best way to leave a Ubuntu system in a totally unconfigured state and have d-i or debconf or whatever run at first boot?
<Keybuk> cause I've only just really figured out what everything means
<wasabi> d-i would need to run, right?
<fabbione> wasabi: oem install
<Keybuk> wasabi: you mean exactly like the Live CD? :p
<wasabi> Yup.
<Keybuk> or indeed the oem installer
<Treenaks> Keybuk: you're re-implementing the formula1.com java applet in C? :)
<Keybuk> Treenaks: implemented
<wasabi> The oem installer? Eh?
<Treenaks> Keybuk: cool :)
<wasabi> New thing I've missed.
<wasabi> (i'm working with a debootstrap, too)
<fabbione> wasabi: use the install cd (breezy) and type oem at the install
<fabbione> s/install/boot prompt/
<fabbione> enjoy
<fabbione> Treenaks: yeah it looks neat ;)
<Treenaks> too bad the season's almost over
<Keybuk> wasabi: https://wiki.ubuntu.com/OEMInstaller
<fabbione> Treenaks: at least we know Keybuk can code something that works and he will be busy enough NOT to break dpkg before elease :
<fabbione> release even ;)
<Treenaks> fabbione: ;)
<Keybuk> tsk, iwj's been breaking dpkg, not me
<fabbione> Keybuk: it's to easy to blame iwj :)
<Keybuk> I've been breaking udev and hotplug instead
<fabbione> right.. that too
<daniels> which aren't at all critical
<fabbione> daniels: exactly :)
<wasabi> interesting.
* wasabi figuring out how to install this in a chroot
<fabbione> wasabi: you can't
<fabbione> there is no need to install that in a chroot
<wasabi> Sure there is.
<wasabi> I'm building a flash-based system, custom root image.
<wasabi> Need to be able to have the user config at first boot. Pretty simple.
<fabbione> oh
<fabbione> wasabi: that's what oem offers you
<wasabi> Yeah, just trying to figure out how to install and set it up.
<wasabi> in a chroot. ;)
<wasabi> So when the root is mounted/booted it runs.
<wasabi> Cool, ya just install it.
<wasabi> nifty.
<wasabi> Hmm. Depends on python and glade and thus gtk.
<wasabi> Needs to be smaller. =(
<Treenaks> wasabi: http://lists.ubuntu.com/archives/ubuntu-devel/2005-October/011903.html :)
<pitti> Hi
<ajmitch> hey pitti 
<fabbione> hey pitti
<pitti> Hi ajmitch, hi fabbione 
<fabbione> pitti: i did forward you a couple of mails..
<fabbione> you might want to do some kind of CAN dance. it's all public... or at least the patch is
<pitti> fabbione: sure; can you please send me a GIT or similar link? the mitre guys need a reference
<fabbione> i don't have one, but i can search for it
<fabbione> that patch just landed in my inbox
<fabbione> just gimme a few secs
<fabbione> http://www.kernel.org/git/?p=linux/kernel/git/davem/sparc-2.6.git;a=commit;h=ba6399334dd8a75bd295de26496196c720abae0a
<Keybuk> I really should play with git sometime
<Keybuk> and hg, and darcs, and monotone, and ...
<fabbione> Keybuk: i heard that git isn't really that fantastic as it claims to be.. it tends to corrupt the archive pretty easily
<bob2> kernel developers writing untested code?????
<fabbione> bob2: tsk..
<fabbione> kernel developers don't need to test code
<dilinger> hey, testing kernel code is dangerous.  you could lose a filesystem, ya know :P
<fabbione> dilinger: lol
<dilinger> fabbione: i'm pretty unimpressed w/ git
<dilinger> i use it daily, but it doesn't seem to really scale from what i've seen of kernel.org/git
<fabbione> so are many kernel developers
<dilinger> i still have high hopes for bzr :)
<\sh> daniels: ping
<dilinger> initial import/commit/diff tests are pretty impressive (on 2.4 kernel trees), even on my horribly slow laptop.  branching and merging still needs a lot of work, though :/
<\sh> daniels: do u know something about problems with i810 driver, since friday there is no external output anymore on the laptop of a colleague, before the last xorg he had dual display on his laptop
<wasabi> hmmm. Guess I need to create /etc/inittab to launch oem config.
<wasabi> Doesn't seem to be documented much.
<infinity> elmo : Can you sync expect-tcl8.3 from unstable?... It fixes the FTBFS we just saw in -autotest (and nothing else)
<HiddenWolf> pitti, ping
<pitti> Hi HiddenWolf 
<pitti> HiddenWolf: I'm changing computers, back in 2 minutes
<infinity> 0 upgraded, 0 newly installed, 882 to remove and 0 not upgraded.
<infinity> Need to get 0B of archives.
<infinity> After unpacking 1675MB disk space will be freed.
<infinity> Cleaning chroots is fun...
<fabbione> infinity: ahha where is that?
<infinity> (a chroot that had -desktop and -live installed for some testing)
<pitti> HiddenWolf: what's up?
<mdke> has jeff started on his badger tour already?
<HiddenWolf> pitti, noticed my unmounted/unused cardreader slots are showing up in gtkfilechooser suddenly. flash card, usb ports, etc.
<HiddenWolf> pitti, doesn't show up in nautilus or the likes.
<pitti> HiddenWolf: hmm, I'm afraid it's a bit too late for Breezy for that, unless it is a very safe patc
<pitti> HiddenWolf: is there a bug about it?
<HiddenWolf> pitti, I haven't posted one, just really got around to checking it.
<HiddenWolf> pitti, it even shows my floppy drive. ;)
<pitti> HiddenWolf: hmm, that works fine for me with an USB stick
<fabbione> doko: oo2 works perfectly on sparc :)
<pitti> HiddenWolf: if I unmount it, I still see it in the dialog
<pitti> HiddenWolf: and when I click on it, it is automatically mounted again
<pitti> HiddenWolf: just like in the computer place
<pitti> HiddenWolf: this might even be considered as a feature :-)
<HiddenWolf> pitti, it's rather dumbish to show an usb port without an usb-stick into it.
<HiddenWolf> pitti, might be that my monitor is a hub/cardreader, so it's confusing the matter.
<pitti> HiddenWolf: ah, you don't mean "unmounted", but "removed"?
<dholbach> good morning
<pitti> HiddenWolf: WFM - as soon as I unplug the USB stick (with an open filechooser), the drives instantly disappear
<pitti> Hi dholbach 
<HiddenWolf> hi
<pitti> HiddenWolf: you seem to encounter a special case, can you please file a bug then? It does not seem to be generally broken
<HiddenWolf> pitti, the weird thing is, nautilus does it right.
<infinity> pitti : It shows readers with no media in them.  Is that a feature?
<HiddenWolf> pitti, I'd think the same code would be used for nautilus/places and the file chooser.
<infinity> OTOH, nauituls is showing me my readers too, so whatever.  I must be seeing a different behaviour. :)
<pitti> HiddenWolf: I only tried a filechooser and the computer place
<pitti> infinity: not sure whether this is a feature, probably not
<dholbach> hey martin, HiddenWolf, infinity :)
<pitti> infinity: but well, it shows my CD-ROM drive, which is the same case
<infinity> Yeah, exactly.  Hence why I assumed it was a feature.
<pitti> in any case it is nothing that should stop breezy :-)
<HiddenWolf> pitti, yeah, but if I take out the cdrom, the entry goes away.
<pitti> it might be a bit confusing, though
<HiddenWolf> pitti, HOLD the presses! :)
* HiddenWolf chuckles
<HiddenWolf> There is still one annoying bug I want fixed.
<HiddenWolf> Pretty trivial, but nobody bothered, and I can't. :(
<pitti> $ LANG=C df
<pitti> df: cannot read table of mounted filesystems
<pitti> hmmmm?
<infinity> pitti : No mtab?
<pitti> infinity: yes, nevermind, /etc/mtab is 0 bytes
<pitti> I was just surprised
<infinity> That's okay, I'm more interested in why I don't have a /proc/kcore in 2.6.13...
<infinity> Not that I want it, but some braindead debian/rules is looking for it as proof that proc is mounted.
<HiddenWolf> infinity, give it a brain?
<infinity> Yeah, but I'm curious about where kcore went. :)
<HiddenWolf> http://www.google.nl/search?q=%22ohh+kcore%2C+where+are+you%3F%22&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:en-US:unofficial
<HiddenWolf> ?
<fabbione> doko: btw.. OO2 on sparc64 is faster than on amd64
<fabbione> no kidding :)
<infinity> Oh, it appears I explicitely disabled kcore in my config.  That was WEEKS ago, how am I supposed ot remember these things?
<HiddenWolf> infinity, hah
<HiddenWolf> infinity, why would you do that.
<infinity> I don't think I did it intentionally, actually.
<infinity> Hence why I don't remember. :)
<infinity> Oh, cause it's disabled by default now upstream.
<infinity> Erm, no it's not.  Oh, I have no idea.
* infinity moved on to more interesting things.
<infinity> I fully approve of not having kcore anyway, so whatever.  Happy accident.
<fabbione> infinity: do you happen to know if we have some crack around that given a Sources.gz in input, it will unpack automatically (and keep updated) all the unpacked sources in a dir?
<fabbione> remove the obsolete and stuff like that?
<infinity> No, but I could do it in shell in about 5 minutes, I guess.
<fabbione> well the first unpack it's easy
<fabbione> that's not an issue
<infinity> (Which may be why no such thing exists)
<fabbione> but update/remove it's the pain
<infinity> Well, are you expecting it to merge changes with unpackaed sources, or just remove the old and unpack the new?
<infinity> The latter is easy.
<infinity> The former would require a bit more effort.
<fabbione> the latter
<fabbione> no i don't expect RCS magig
<fabbione> magic
<fabbione> but only if there is a new one
<infinity> Sure, so you just compare the versoin in Sources.gz with the version in your current .dsc
<infinity> If they don't match, out goes the diff, dsc, and build-tree, and you re-update.  If you have two orig.tar.gzs after update (cause the update was a new upstream), remove the older orig.
<fabbione> well if you need to hack it, i can do it myself :) i was just curious to know if there was something done already
<infinity> (Do it in that order, so you can reuse the orig, if it matches)
<`anthony> so the whois client in breezy right now doesn't know about the new .travel top level domain. Is this the sort of thing that should get fixed before the final release, or can it wait for a bugfix?
<`anthony> hm. Or the .eu TLD
<fabbione> `anthony: breezy will get only security updates
<fabbione> so that's dapper stuff
<infinity> Adding TLDs to whois is pretty trivial, I don't see why we couldn't do it pre-release without destabilising.
<`anthony> fabbione: sigh. 
<infinity> Doing it post-release is likely a no-no, though.
<fabbione> infinity: i would consider them features :P
<fabbione> but whatever ;)
<infinity> Yeah, but tiny/trivial ones.  Worth passing by mdz anyway.
<infinity> It's not a complete rewrite or anything (like when whois had to be hacked to handle the new world order of whois redirects)
<`anthony> I'm mystified as to why the whois client appears to have all this stuff hardcoded into it, but whatever... ;) 
<`anthony> whois is a disaster of a protocol, anyway.
<infinity> `anthony : Because there's no canonical source for which whois servers to query for which TLDs that doesn't move itself every three weeks.
<infinity> `anthony : The only way to make it work at all is to hardcode the initial discovery into whois itself.
<`anthony> infinity: I meant "instead of having a text file with the seed info"
<Treenaks> have one on a central server somewhere :)
<\sh> hmmm....I should reactivate my kwhois tool ;)
<infinity> `anthony : Oh, yes, that's just a crusty holdover of the Old World Order, where having it hardcoded made sense.  I'm sure Md would take patches to make it use a configuration in /etc (or, one in /usr/share, overridden by /etc)
<lucas> hi
<lucas> I'd like to point out bug #17415
<dholbach> lucas: i just had a look at the packages, that need ruby in main, it's kdebindings (which provides libqt0-ruby1.8 - which is used by amarok) and redland-bindings which is used by redland-utils - it might help to build the new debian package and test those packages if they run perfectly well
<lucas> note that it was been in debian for 18 days without any important bug report
<sivang> Morning all
<dholbach> lucas: yes, it's just that users will have to live with it for 6-18 months, so if an expert double checked it (could be somebody else too, somebody of the kubuntu crew for amarok maybe), it would give people more confidence in the sync
<lucas> I don't think amarok is an issue : it only suggests libqt0-ruby1.8
<dholbach> oh, i see
<dholbach> i just flicked through the rdepends
<\sh> dholbach: amarok uses those bindings for additional scripts...just like it's using python-kde3 
<dholbach> i see
<dholbach> it's just what i saw on first glance
<\sh> dholbach: and redland-bindings (binary package librdf-ruby) is in universe (source in main right)
<dholbach> redland-bindings is in main though
<\sh> dholbach: the source yes, the resulting binary for ruby-bindings not...
<\sh> dholbach: if it's only a rebuild with new ruby, I think that's fine but needs an ok by mdz/kamion ;)
<dholbach> \sh: i hope so
<\sh> damn..
<\sh> xview needs X11/bitmaps/xlogo64 which is not in xbitmaps but in tendra...
<\sh> but i think it's not the right build-dep for xlogo64...
<infinity> mvo!
<infinity> I've been looking for you.
<mvo> hey infinity 
<mvo> good morning
<fabbione> mvo: apt sucks :
<fabbione> P
<infinity> mvo : Are apt's DPkg::Post-Invoke hooks just sent to "sh -c"?
<pitti> Hi mvo, hi chmj
<infinity> mvo : If so, you may want to change update-notifier's to have a "[ -d /var/lib/update-notifier/ ]  &&" before the touch.
<infinity> mvo : Purging update-notifier makes apt whine about the lack of directory, and exit non-zero.
<mvo> infinity: yes, that should work, thanks
* mvo tests this now
<mvo> pitti: hi!
<infinity> mvo : Just discovered while cleaning a chroot that had ubuntu-desktop installed in it. :)
<daniels> \sh: no idea, sorry
<daniels> \sh: the i810 driver hasn't changed in that respect.  if it's terminating with a SIGILL, then his BIOS is screwed and it's a GCC bug, again.
<\sh> daniels: I'll investigate, because I'm not sure if it's really i810 related or just a b0rked tft :(
<\sh> daniels: thx anyways
<daniels> \sh: np
<fabbione> Mithrandir: ping?
<\sh> daniels: or no...other thing...dpkg-reconfigure xserver-xorg called inside a Xorg session, during the monitor detection it was falling back to plain console and gdm doesn't come up again...
<daniels> \sh: that sounds a lot like broken BIOS + gcc bug (the gcc bug triggers the particular broken BIOS behaviour) to me
<\sh> daniels: hp/compaq nc6120
<Treenaks> daniels: and what can we do about 14007 ?
<Treenaks> daniels: (any ideas?)
<\sh> daniels: called from console with running X session, works as expected
<Treenaks> daniels: uh, not 14007
<Treenaks> daniels: I meant 14043
<daniels> Treenaks: without the hardware or co-operation from ati, I have no clue, tbh
<Treenaks> daniels: ok, too bad :(
<Treenaks> daniels: you'll be in Montreal, right?
<daniels> yeah
<chmj> hey pitti 
<mdke> is anyone other than jdub able to add blogs to planet.u.c?
* Treenaks guesses elmo
<jsgotangco> mdke, heh you into blogs too?
<mdke> not majorly, i just thought I would like to post things occasionally
<dholbach> good morning mvo, seb128 
<seb128> hey dholbach
<pitti> Hi seb128 
<mdke> elmo, can you add blogs to planet.u.c?
<mdke> or any other generous soul
<seb128> hey pitti
<\sh> bah...real life work...brb
<janimo> pitti, pmount no longer has async option because it's default?
<Mithrandir> fabbione: pong
<pitti> janimo: yes
<fabbione> Mithrandir: yo.. did you get to try that amd64 kernel?
<fabbione> Mithrandir: if not.. don't worry.. i just did
<Mithrandir> fabbione: no, sorry, the network here at home decided to implode last night so I spent some time trying to track that down.  Then I managed to get a nice and evil headache which is still present.
<Mithrandir> fabbione: thanks dude.
<fabbione> no problem, thanks anyway
<daniels> seb128: morning sebarino
<seb128> hey daniels
<daniels> could everyone on i386 please grab libxkbfile1_7.0.0-3_i386.deb and xkeyboard-config_0.6-6_all.deb from http://people.ubuntu.com/~daniels/, install them, type setxkbmap -print | xkbcomp - :0, and tell me if your keymap still works fine or not? pay particular attention to your right alt key.
<lucas> daniels: still works fine here
<\sh> una momenta...
<\sh> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols Ignoring extra symbols
<\sh> and a lot of other warnings
<\sh> but altGr+{q,2,7,8,9,0,e} works 
<daniels> ignore the other warnings, but the RALT bit is juicy
<\sh> so german layout here
<daniels> what's the symbols line from setxkbmap -print?
<seb128> X Error of failed request:  BadValue (integer parameter out of range for operation)
<seb128>   Major opcode of failed request:  148 (XKEYBOARD)
<seb128>   Minor opcode of failed request:  9 (XkbSetMap)
<\sh> xkb_symbols   { include "pc(pc105)+de"  };
<daniels> (notably, xk-c 0.6-6 fixes grp:alts_toggle.)
<mvo> daniels: works here too
<seb128> daniels: score :)
<dholbach> elmo: could you please sync xmame from sid?
<mvo> daniels: my is xkb_symbols   { include "pc(pc102)+de+ctrl(swapcaps)"   };
<daniels> cool, thanks
<daniels> seb128: huh, if you do setxkbmap -print | xkbcomp - :0?
<daniels> seb128: if so, anything interesting at the bottom of Xorg.0.log?
<seb128> daniels: I've the same with the package before update
<seb128> still this bug with fr, us keymaps
<seb128> grumpf
<lucas> I get this with an fr keymap :
<lucas> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
<lucas>                   Ignoring extra symbols
<lucas> but it still works fine
<fabbione> seb128: no no no no.. the real bug is the country you leave in :P
<daniels> okay, hold on a second
<seb128> daniels: http://pastebin.com/388840
<seb128> daniels: Xorg.0.log on chinstrap if you want it
<daniels> hmm, okay
<daniels> give me a second, need to look a little deeper into this
<zoot_> hi, any LTSP devs here?
<dholbach> zoot_: #ltsp?
<zoot_> dholbach: am on there too, no replies, so i thought i'd checkin here, since the wiki asks to give feedback to ubuntu-devel ;)
<dholbach> ah i see
<dholbach> maybe ubuntu-devel@? :)
<zoot_> yep ;)
<janimo> zoot_, all ok with the kioks?
<janimo> in /etc I mean
<zoot_> hi janimo - yes, so far, thx very much!
<janimo> cool :)
<zoot_> tho i see there's still a mix of /etc/xdg and /etc/X11/xdg
<zoot_> that's amongst the xfce pkgs
<janimo> yes only the xserverrc is in /etc/X11 I think that's ok to leave for now
<zoot_> it works, so yeah, think so to ;)
<janimo> are there other kiosk settings besides the panel stuff?
<janimo> I think xfce-session has some
<zoot_> yeah, let me find the url..
<zoot_> also for desktop menu
<daniels> okay, please download xkeyboard-config_0.6-6_all.deb again and try that
<seb128> dpkg: regarding xkeyboard-config_0.6-6_all.deb containing xkeyboard-config:
<seb128>  xkeyboard-config conflicts with libxkbfile1 (<< 7.0.0-3)
<seb128>   libxkbfile1 (version 7.0.0-2) is installed.
<daniels> seb128: yes, so install that too :)
<daniels> you can't compile keymaps from new xk-c with old libxkbfile1
<seb128> from where?
<daniels> same place
<seb128>  libxkbfile1_7.0.0-3_i386.deb 
<seb128> that's all
<daniels> amd64?
<seb128> hum?
<seb128> no i386
<daniels> which architecture are you on?
<seb128> http://people.ubuntu.com/~daniels/
<seb128> i386
<daniels> okay ... so download and install that?
* daniels notes that 7.0.0-3 does not satisfy << 7.0.0-3.
<seb128> ups
<mvo> Kamion: would http://people.ubuntu.com/~mvo/update-notifier_0.40.14.debdiff be ok for breezy?
<seb128> X Error of failed request:  BadValue (integer parameter out of range for operation)
<seb128>   Major opcode of failed request:  148 (XKEYBOARD)
<seb128>   Minor opcode of failed request:  9 (XkbSetMap)
* seb128 hates xkb
<daniels> wtf
<seb128> hum
<seb128> now that's fine
* daniels shrugs.
<seb128>         xkb_symbols   { include "pc(pc105)+fr+group(alts_toggle)"       }; 
<seb128> changed to
<seb128>         xkb_symbols   { include "pc(pc105)+fr"  };
<zoot_> janimo: can't find kiosk refs to items other than -panel and -session. will let you know. the -panel url is:  http://www.loculus.nl/xfce/documentation/docs-4.2/xfce4-panel.html#panel-kiosk but i know there's a ref elsewhere with more options...
<daniels> seb128: okay, could you run xkbcomp - :0, but add +group(alts_toggle) to the symbols line?
<daniels> if it still gives you shit, please send me the output of xkbcomp -xkb - -, with that input
<seb128> daniels: setxkbmap -model pc105 -layout 'fr' -option 'grp:alts_toggle'
<seb128> daniels: with that you should get the crasher, no?
<daniels> daniels@ephemera:~/canonical/xorg/data/xkeyboard-config% setxkbmap -model pc105 -layout fr -option grp:alts_toggle
<seb128> daniels: xkb_file on chinstrap
<daniels> daniels@ephemera:~/canonical/xorg/data/xkeyboard-config%
<seb128> daniels: now | xkbcomp - :0 it
<daniels> qrgh azerty cqn bite ,e
<Treenaks> daniels: ;)
<seb128> yeah
<daniels> seb128: pleqse type setxkb,qp )lqyout us for ,e
<HiddenWolf> who is the ubuntu-calendar artwork person?
<seb128> daniels: ah ah
<Treenaks> daniels: "command not found" :P
<jsgotangco> HiddenWolf, jdub is your best best
<daniels> seriously
<sivang> seb128: you aware that the link for evo is broken from the panel?
<sivang> Bon Jour BTW :)
<seb128> it's not
<HiddenWolf> jdub, ping
<sivang> evolution-2.2 - "No such file or directory"
<sivang> but that minus the version works
<seb128> ah, that's an update
<seb128> known "issue"
<daniels> seb128: my testcase was layout us,de,fr option grp:alts_toggle
<daniels> which worked fine
<seb128> daniels: with fr alone? :)
<daniels> seb128: with fr alone, I just make a dick of myself on IRC, as above
<daniels> (i like testing with multiple layouts, because I'm just two keypresses away from getting myself back into a sensible keymap.  usually I test with de, and I've got that memorised now, but azerty is a whole different kettle of fish.)
<seb128> :)
<seb128> daniels: right, with 2 keymaps that works fine
<seb128> daniels: the issue is if I've only fr
<daniels> weird.  works fine with just fr here.
<seb128> $ setxkbmap -model pc105 -layout 'fr' -option 'grp:alts_toggle'
<seb128> $ setxkbmap -print | xkbcomp - :0
<seb128> X Error of failed request:  BadValue (integer parameter out of range for operation)
<seb128>   Major opcode of failed request:  148 (XKEYBOARD)
<seb128>   Minor opcode of failed request:  9 (XkbSetMap)
<seb128>   Value in failed request:  0x16710002
<seb128>   Serial number of failed request:  77
<seb128>   Current serial number in output stream:  83
<daniels> seb128: hrm
<daniels> seb128: okay, that happens only if I clear out my options
<daniels> oh, duh, god I'm stupid
<seb128> ?
<seb128> just curious, but are you playing with some code to fix that? or with the keyboard definitions?
<daniels> seb128: s/group(alts_toggle)/level3(ralt_switch_for_alts_toggle)/
<daniels> seb128: does -print give you group(alts_toggle), or level3(ralt_switch_for_alts_toggle)?
<seb128>         xkb_symbols   { include "pc(pc105)+fr+group(alts_toggle)"       };
<daniels> okay
<daniels> grab http://people.ubuntu.com/~daniels/xorg, stick it in /etc/X11/xkb/rules, and try again
<daniels> this time you should get level3(ralt_switch_for_alts_toggle); seems to work here
<daniels> make that ~daniels/xorg/xorg
<seb128>         xkb_symbols   { include "pc(pc105)+fr+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)"   };
<seb128> and it doesn't crash
<seb128> and keyboard works fine
<ericf> I can repeatedly crash nautilus, don't know why, but it seems to happen when browsing a dir via a symlink. How can I make a useful backtrace? I should use gdb for that, right? I'll file this in bugzilla, if I can give some useful information. Then question 2: is this question here inappropriate? #ubuntu isn't very responsive to this question. 
<seb128> ericf: https://wiki.ubuntu.com/DebuggingProgramCrash
<seb128> ericf: install libgnomevfs2-0-dbg nautilus-dbg and describe the version/arch you use and what to do exactly to get the issue
<seb128> ericf: and this chan is not to speak about how to get a backtrace :)
<ericf> seb128: Thank you. I'll have a look.
<seb128> np
<daniels> seb128: rockin, thanks a lot
<seb128> np, thank *you* :)
<daniels> i've pinged svu too, so we can shove this hack of a fix through
<daniels> i started working on the real fix on the tram
<seb128> what is difference between "group(alts_toggle)" and "level3(ralt_switch_for_alts_toggle)+group(alts_toggle)" exactly?
<daniels> well, +group(alts_toggle) shouldn't be there
<daniels> but, basically, group(alts_toggle), does this: key <RALT> { (some stuff blah blah) [ NoSymbol, ISO_Next_Group ]  }
<seb128> that's to switch between layouts?
<daniels> and level3(ralt_switch) does key <RALT> { (stuff) [ ISO_Level3_Shift ]  }
<daniels> yeah
<seb128> how do I use it?
<daniels> so ralt_switch_for_alts_toggle does key <RALT> { [ ISO_Level3_Shift, ISO_Next_Group ]  }
<daniels> setxkbmap -layout fr,us -option grp:alts_toggle
<daniels> just press both alt keys at the same time, and you will have switched between fr and us
<HiddenWolf> jdub, seb128, some patches attached to bug 8721, fairly trivial and obvious, is it possible to fix this?
<seb128> daniels: right :)
<seb128> HiddenWolf: a real patch instead of changing dir as a workaround would be nice
<daniels> seb128: so the real fix is to let the xkb parser know that you just want to skip a specific level, so we don't have these stupid collisions
<daniels> also there's a bit of handwavy alt-handling stuff that needs to get fixed
<HiddenWolf> seb128, not my patch btw, but i'll look into it.
<seb128> daniels: k
<daniels> http://www.icedoutgear.com/DT39.php
<tepsipakki> kamion: does the installer remove etc/dhclient.conf?
<tepsipakki> kamion: from the image
<sivang> seb128: re 14910, I managed to reproduce that on 2 machines of mine, but the bug report says it was fixed upstream.
<sivang> seb128: (after upgrades, that is)
<Lathiat> mjg59: about?
<seb128> sivang: have you actually read it?
* sivang rereads
<tepsipakki> kamion: yes it seems to do that, read the netcfg sources... bugger
<carlos> pitti, could you give me an URL where I could get the tarball with your hoary's translations? so I can debug the missing strings?
<pitti> Hi carlos 
<seb128> hey carlos
<carlos> pitti, btw, hi :-P
<carlos> seb128, hi
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/hoary-final.tar.gz
<pitti> carlos: did you get my email with the bugs I found?
<mvo> pitti: when did you build it?
<pitti> mvo: that tarball? right before hoary was released
<Kamion> mvo: please either (a) mail me or (b) just upload and let it sit in the approvals queue - if you ask me on IRC, I'll lose stuff, amid the two-and-a-half days of #ubuntu-devel I've just had to trawl through
<carlos> pitti, yeah, I'm debugging it atm
<mvo> pitti: sorry, me should read more carefull :)
<Kamion> tepsipakki: the installer doesn't remove anything, it either installs stuff or doesn't install it
<pitti> mvo: actually I built that tarball at Friday, but it's contents is the same as in the zip file I built for haory
<janimo> seb128, do you have suggestions how I should package a modified evince-0.4.0 for universe so as it doesn't conflict with the original
<janimo> it is a diff to take out gnome dependencies from it
<seb128> janimo: DON'T
<mvo> pitti: I was wondering when you will build the breezy langpack (IIRC it was scheduled for today?)
<seb128> janimo: no no no
<pitti> mvo: it will be today, yes
<janimo> would you take a patch for the original package to build two binaries?
<seb128> janimo: we have enough packages without starting to have 2 packages for the same stuff
<pitti> mvo: I'm waiting for carlos' tarball to arrive and my cronjob to finish
<seb128> janimo: no
<janimo> seb128, any other suggestion to have evince with gtk only for lighter desktops?
<mvo> pitti: ok, thanks
<janimo> in universe?
<seb128> janimo: don't? :)
<sivang> lol
<janimo> seb128, that's not an option many people will like :)
<carlos> pitti, the tarball is there already
<seb128> janimo: seriously, having 2 source package for the same stuff is not a good idea
<sivang> evince rulez
<sivang> :)
<tepsipakki> kamion: it does remove for example etc/dhclient.conf and etc/dhcp3/dhclient.conf if they exist (from the ramdisk, that is), see netcfg-common.c
<janimo> seb128, xpdf, gpdf, kpdf, why evince then ;)?
<carlos> pitti, I got the email an hour ago
<pitti> -rw-r--r--  1 langpack langpack 278376521 Oct 10 09:37 buildd-rosetta-merged.tar.gz
<janimo> not the same stuff, it's a friendly fork
<seb128> janimo: that's the GNOME official pdf/ps viewer
<pitti> oh, yay
<azeem> janimo: why do you want to strip down evince anyway?
<pitti> carlos: so my cronjob worked as well :)
<tepsipakki> kamion: but I can change the dhclient-script which is enough, I think..
<janimo> azeem, for xubuntu so it doesn not bring in gnoem stuff
<seb128> janimo: it'll Depends on libgsf and GNOME office stuff anyway
<mvo> janimo: I was under the impression that evince makes very heavy use of various gnome-libs, do you have a url for the patch?
<carlos> pitti, cool!
<janimo> seb128, what do you mean depends on gnome stuff office?now?
<martink> mvo, it's in the evince-list archives at mail.gnome.org
<azeem> janimo: why not use xpdf for that?
<janimo> mvo, I sent it to the evince list last Thursday
<janimo> azeem, it's ugly and not nearly as nice as evince
<seb128> janimo: no, but they plan to open ppt files, etc
<janimo> evinces niceties are mostly non-gnome related
<Kamion> tepsipakki: ok, sorry, I'm really busy at the moment so if you can read the source and work it out yourself that's far preferable to asking me
<janimo> seb128, ok but for now and the xubuntu releas it'd be nice. People seem excitded about it and they haven't even tested it :)
<seb128> janimo: I'm against it
<janimo> mvo, beware the pacth is ugly
<seb128> we have double bugs, double upload, double package to patch, etc
<tepsipakki> kamion: yes, sorry for the noise ;)
<dholbach> janimo: might be a target for dapper?
<seb128> janimo: did you get any reply upstream?
<janimo> seb128, you are aginst me forking an open source project and providing it to ubuntu users on older machines? that's not nice of you ;)
<dholbach> janimo: don't you go and blame seb :)
<janimo> seb128, the evincelist seems dead
<seb128> janimo: no, I'm against you putting extra work and duplicating the same code 
<janimo> on IRC J blandford seemed skeptic a couple weeks ago of a gtk only evince, but avoiding to tell me what it would take to change it if I really wanted
<seb128> janimo: a 1500 lines diff is not something we want to push the week of a stable
<janimo> seb128, not really extra code, I mostly deleted stuff :)
<seb128> still 1500 lines of changes
<janimo> seb128, of course not in main, that's why I asked of advice under what name shoudl  I package it in universe so that it does _not_ conflict with evince
<seb128> with some FIXME comments
<Kamion> janimo: it's not possible to have two source/binary packages of the same name in main and universe; therefore they'd have to have different names and provide the same files etc., which is very nasty and difficult to do right, especially at short notice
<seb128> janimo: having the same source package to main and universe with different names is not nice
<Kamion> janimo: it would cause support problems in main
<janimo> Kamion, seb128, of course different names, that's what I was asking
<Kamion> janimo: yes, that doesn't make it non-nasty
<seb128> and different path to install files, etc
<janimo> seb128, there's lots of resued code in different packages
<seb128> and we will get bugs about yours
<Kamion> in fact it makes it worse if you do it wrong
<Kamion> janimo: that's not an excuse for more
<janimo> no, it can be renamed
<daniels> does anyone here have a powerpc that can test XKB stuff?
<janimo> I was going to call it evionce-gtk to give credit for upsteram but it can be called gtk-docview or piglet or anything
* pitti raises hand
<janimo> you won't get bugreports fro evince
<daniels> pitti: word
<seb128> you are willing to maintain the work yourself?
<janimo> seb128, Conflicts: evince
<seb128> s/work/fork/
<janimo> seb128, yes I am 
<mjg59> Lathiat: Hi
<carlos> pitti, hmmm, did you patched Python to use language packs?
<seb128> janimo: they have planned quite a lot of changes, you are going to keep the amount of work?
<Lathiat> mjg59: is there any reason "Loading modules" would be different in kubuntu
<Lathiat> mjg59: in kubuntu, it doesn't time out usplash
<Lathiat> in ubuntu, it did every time
<daniels> pitti: could you please get the libxkbfile sources from p.u.c/~daniels/, compile and install libxkbfile1, then install xkeyboard-config from p.u.c/~daniels?
<mjg59> None that I can think of
<seb128> janimo: I would say after 5.10 is better than to fork it now, 3 days before 5.10 with 0 feedback
<janimo> seb128, not necessarily. It can remain at this stage as evince 0.4 I find it already excellent for pdf and ps
<pitti> carlos: I didn't, but since it obviously works, somebody apparently did it
<Kamion> janimo: Conflicts: evince is not acceptable at this stage
<Lathiat> maybe something new went into kubuntus RC iso that changes on install but not upgrade or something
<seb128> janimo: and poppler will change and you will have to follow
<pitti> daniels: how urgent is this? 
<daniels> pitti: i'd really like to get it in breezy
<pitti> daniels: i. e. would doing this in 1 hour block you?
<janimo> seb128, for the first release of xubuntu, for dapper we may have something cleaner
<carlos> pitti, your hoary tarball has sane-backends.LANG directories...
<daniels> pitti: oh, not at all; need to go make dinner and do something that doesn't involve a computer for a while
<janimo> so poppler changing after breezy does not affect me 
<sivang> be back later, going to eat
<carlos> that looks like the python layout but are not exactly the same...
<pitti> carlos: these will just be ignored
<pitti> carlos: the breezy importer knows how to handle these
<pitti> carlos: but not the hoary branch
<carlos> pitti, what's that?
<pitti> carlos: there was a reason why I branched langpack-o-matic for hoary, but I don't know it currently
<janimo> seb128, as for conflicting paths I can install elseweher
<janimo> most files are nautilus.gconf/gnome related anyway, thiose won;t be in anyway
<carlos> pitti, should I ignore it then?
<pitti> carlos: mainly because I want to use the same scripts that I used for the initial langpacks, I guess
<pitti> carlos: yes
<seb128> janimo: I'm against pushing a new code untested 
<seb128> 3 days before a stable
<seb128> but that's my opinion
<Kamion> janimo: standard release management practices suggest that anything that xubuntu requires for release should really have been in the archive for some time, not be shoved in at the last minute
<janimo> seb128, but it's universe, and does not affect reputation of gnome/evince
<seb128> still
<Kamion> janimo: I'd strongly, strongly suggest using a different PDF viewer, even if it's not as pretty.
<janimo> Kamion, there are still xubuntu packages in the NEW queue (artwork etc)
<Kamion> janimo: no there aren't
<Kamion> xubuntu-artwork was rejected; you should have mail
<Kamion> (licensing)
<janimo> Kamion, I answered to elmo but no respponse
<janimo> you saw those mails too?
<Kamion> janimo: you're supposed to reupload, not argue :)
<janimo> I copy pasted kubuntu license
<Kamion> janimo: I didn't see the mails originally, but I can see the file in the reject queue with a copy of the mail
<janimo> but I wasn;t arguing but asking why the kubuntu art license isn;t approproate for xu
<Kamion> The Ubuntu artwork is licensed under the CC-BY-SA 2.5.  Given the Xubuntu artwork
<Kamion> seems to be derived from the Ubuntu artwork, it seems only reasonable it should follow
<Kamion> the Ubuntu artwork's licensing rather than relicensing it?
<janimo> I happened to copy from kubuntu-artwork
<janimo> not edubuntu
<Kamion> if it's derived from the Ubuntu artwork, I don't see that "but Kubuntu gets it wrong" is a justification for you getting it wrong too?
<janimo> I did not know kubuntu got it wrong
<janimo> and after elmo's mail I asked
<Kamion> janimo: in any case, nothing will happen until you reupload
<janimo> ok, thanks
<janimo> I thought I'd wait till elmo sees my mail
<Kamion> the file is not in the new queue, it's rejected; that's permanent for that upload
<Kamion> janimo: that would seem wise, certainly
<Kamion> janimo: but alternatively, is it so hard to licence it under the union of the licences of anything you've copied from?
<janimo> so as a curiosity is kubuntu art license wrong then?
<Kamion> you could just do that, trivially
<Kamion> janimo: I have no idea; I have not checked it
<janimo> no it;s not hard
<janimo> I made the pa ckage based on edubuntu artwork. I am inncocent :)
<mjg59> Derived works of CC-SA have to be CC-SA, from what I can remember
<Kamion> janimo: I think the term is "complicit", technically ;)
<janimo> oh kubuntu, sorry
* janimo ducks
<janimo> oh well I reupload with CC license, sigh
<Kamion> anyhow, this argument is pointless. why not just get it right once you've been informed of the problem?
<janimo> I thought that by asking I may raise and lead to solving another prob, the possible kubuntu license one
<Kamion> that's fine, but in the meantime you should resolve your own release blockers
<janimo> I want to learn something from what I do not just comply :)
<janimo> and is xfce4-taskmanager not in NEW either?
<janimo> another MOTU supposedly uploaded it
<janimo> ivoks to be precise
<mvo> ping carlos 
<Kamion> janimo: there is nothing matching x* in NEW
<carlos> mvo, pong
<janimo> Kamion, I'll upload it myself then, thanks
<segfault> ogra: ping
<Kamion> janimo: the person who uploaded xfce4-taskmanager forgot to build with -sa
<segfault> ogra_: looks like the desktop fix is likely to have something wrong with its charset
<Kamion> cjwatson@jackass:~/queue$ cat reject/xfce4-taskmanager_0.3.1-0ubuntu1_source.reason
<Kamion> Rejected: xfce4-taskmanager_0.3.1-0ubuntu1.dsc refers to xfce4-taskmanager_0.3.1.orig.tar.gz, but I can't find it in the queue or in the pool.
<Kamion> they should have got mail about that
<bob2> jackass is the most awesome ftpmaster. name, ever.
<segfault> ogra_: looks like the file is in ISO-8859-1 and the string i wrote is in UTF-8
<janimo> Kamion, thanks
<ogra_> hmm, shouldnt be.... my vi is working in utf8 normally... i'll check and fix it :)
<ogra_> thanks for reporting
<segfault> ogra_: thanks
<seb128> What package is to blame for a "eth0 no set up during the boot"?
<seb128> I've to run "sudo dhclient" 
<seb128> hoary sets it correctly on the same box
<mjg59> seb128: Is eth0 wireless?
<ogra_> seb128, hotplug/dhclient i'll look up the bug...
<seb128> yeah, ipw2200
<mjg59> Wireless devices don't seem to get set up during the install
<mjg59> Kamion: ^ ?
<ogra_> seb128, 13497
<seb128> nop
<seb128> sudo ifup eth0 works fine here
<ogra_> seb128, as it does for all others in the bug
<ogra_> the hotplug script doesnt work right...
<ogra_> it will also work if you add "auto eth0" to your interfaces file...
<seb128> I should not have to
<seb128> hotplug is supposed to get it
<mvo> ogra_: do you got the /msg from me?
<infinity> seb128 : Does /etc/init.d/hotplug restart get it after you're done booting?
<ogra> mvo, in fact i was answering since 20min already :/ damn freenode
<mvo> ogra: sorry, I should change this "unfiltered" thing (or whatever it is called)
<seb128> infinity: yep, it does
<ogra> mvo, nope, i should notice if i'm not logged in :)
<infinity> seb128 : Yell at Keybuk, really loudly, then.
<seb128> infinity: will do, thanks
<daniels> infinity: i find that works for most things
<daniels> well, s/works/applies/, I suppose
<ogra> yelling at Keybuk or restarting hotplug ? 
<pef> hello
<bob2> is "buch" a german word?
<zoot_> bob2: yes, book
<Treenaks> bob2: Buch, yes. it means "book"
<bob2> ah
<Kamion> mjg59: atheros?
<pef> does every FTBS has a bug  opened ?
<daniels> mostly
<mjg59> Kamion: No - plausibly something that was fixed
<infinity> pef : Probably not.
<mjg59> Kamion: But what does happen on Atheros systems?
<pef> mmm and if I fix a FTBS which hasn't one bug report opened, should I open one ?
<Kamion> mjg59: not supported on breezy; the card won't be recognised
<mjg59> Kamion: Once the system is installed?
<infinity> pef : In which package?
<pef> infinity: it's just an example :)
<Kamion> mjg59: once the system is installed, it should be fine, although you'll probably have to munge /e/n/i
<mjg59> Kamion: Oh, FFS.
<infinity> pef : Oh, sure, if you find a bug, file a bug and attach a patch.
<infinity> pef : bugzilla for main, malone for universe.
<mjg59> Kamion: (Yes, I know it's not your fault)
<pef> infinity: ok, thank you
<mjg59> Kamion: Do you know if that's been release-noted?
<Kamion> mjg59: no, sorry
<Kamion> Riddell: kubuntu MD5SUMS fixed, sorry about that
<Kamion> elmo: I think I'll move the source images back to cdimage, which will free up 4GB or so
<Kamion> DVDs, yeah, I guess
<daniels> i thought l-r-m had properly-sized udebs now?
<infinity> It does.
<daniels> Kamion: btw, you're going to get a bunch of CD space back with -77
<infinity> We don't, however have a binutils udeb (that change was vetoed), nor d-i hooks to link ath_hal.
<daniels> ah, rockin.
<Kamion> daniels: oh, driver stripping. cool
<daniels> Kamion: novel, innit?
<segfault> ogra: http://www.prognus.com.br/~carlos/xscreensaver_4.21-4ubuntu16.diff.gz
<ogra> segfault, thanks a lot :)
<Kamion> daniels: -77 looks OK to me but I'd rather leave xorg to mdz
<daniels> Kamion: okay
<sivang> back
<Diziet> Any kubuntu people here ?  I'd like to talk to someone about 17390.
<\sh> when riddell is not answering ;) 
<\sh> Diziet: how can I help you
<sabdfl> fabbione: ok, the "official" tag is added to my branch
<sabdfl> should land this week
<sabdfl> and be in production next week
<fabbione> sabdfl: cool! thanks a lot
<Diziet> Hello.  Could you take a look at 17390 and tell me if you agree with dennis@kaarsemaker.net ?  If so I'll reassign the bug.  Otherwise let's talk about what to do about the problem.
<sabdfl> np
<sabdfl> kinnison will be doing the import of breezy into launchpad at some stage
<fabbione> sabdfl: i will still need your suppah powha to add the info tho...
<sabdfl> discuss with him whether to reflect those architectures
<sabdfl> hmm...
<sabdfl> they are on our servers, right?
<fabbione> sabdfl: the .deb's yes
<\sh> Diziet: well...actually I don't know what riddell thinks about it...i'll discuss this with him
<fabbione> they are all on jackass and splitted with rsync magic to archive and ports
<\sh> Diziet: the default homepage for ff is in ubuntu-artwork? 
<ogra> \sh, -docs
<Diziet> The default homepage is a file which is currently provided by -docs, yes.
<Diziet> The file is in .../share/.../ubuntu-artwork because that's the package it used to be in.
<\sh> Diziet: symlink is as well in /usr/share/ubuntu-artwork/home/index.html
<Diziet> Oh, they've made it a symlink ?  OK.  That symlink is what Firefox is looking for.
<Diziet> NB, see also https://wiki.ubuntu.com/BreezyFirefoxStartPageTranslation
<Diziet> I think you'll find that you must perform the role quoted there as ubuntu-doc'.s
<Diziet> s/\.s/s.
<mjg59> Kamion: hotkey-setup-0.9ubuntu2 - can you approve that?
<\sh> Diziet: so the link is provided by ff?
<Kamion> mjg59: done
<daniels> mdz: ping
<Riddell> Diziet: it could be a link to alternatives and have an alternative provided by ubuntu-doc and kubuntu-doc
<daniels> (or kubuntu-doc could divert.)
<Riddell> yes
<mjg59> Kamion: Thanks
<Riddell> Kamion: is the kubuntu live CD set up to use the new winfoss?
<Kamion> Riddell: yes
<Kamion> as stated in #17125
<Diziet> Alternatives are for when the situation depends on local admin configuration decisions, not when it depends on which packages are installed.  If kubuntu includes ubuntu-doc then yes, divert it.
<Riddell> Kamion: great, thanks
<\sh> Riddell: do we such a page like the index page of ubuntu-docs? we could make a link in kubuntu-docs and the problem would be solved at least until a better solution is found
<\sh> +have 
<Riddell> \sh: we have aboutkubuntu (which I havn't look at yet but will do today)
<\sh> Riddell: so adding debian/links with the correct locations in kubuntu-docs, will solve it...well, bug is pendingupload  I would say ;)
<daniels> \sh: then you'll need a Conflicts
<\sh> daniels: yepp
<\sh> a nicer solution would be that ff package is detecting the (k)ubuntu-desktop postinst and should set the link correctly to ubuntu/kubuntu-docs dir (including the locale for dapper)
<carlos> pitti, you have an update about Hoary's language packs in your mailbox
<carlos> pitti, thanks for the report
<Kamion> \sh: a diversion would avoid the need for a conflict
* carlos -> lunch
<Kamion> firefox should not be getting into detection of {ubuntu,kubuntu}-desktop; that way clearly lies madness
<seb128> carlos: is there anything to mask all the xxx-... from the rosetta list? It makes the list and the stats crappy
<carlos> seb128, will fix that today and ask for a fast cherry pick
<torkel> dholbach: thanks for taking care of #17465 (e-d-s)
<dholbach> torkel: thanks for fixing it :)
<torkel> dholbach: well, as I was the only one suffering from it, I guess I had to fix it :-)
<dholbach> you won't have been the only one :)
<ogra> segfault, ping
<seb128> carlos: thanks
<seb128> carlos: same for "review-...." items?
<Kamion> mvo: does your update-notifier change actually make any difference? note that '[ -d /nonexistent ]  && true' exits 1
<Kamion> mvo: I would prefer either '[ ! -d /var/lib/update-notifier ]  || touch /var/lib/update-notifier/dpkg-run-stamp' or (perhaps clearer) 'if [ -d /var/lib/update-notifier ] ; then touch /var/lib/update-notifier/dpkg-run-stamp; fi'
<mvo> Kamion: right. can you reject the upload?
<bob2> holy god the monospace font in breezy is unreadable
<ogra> bob2, thats your eyes :)
<smurf> ... or your settings for font smoothing
<Kamion> mvo: no, due to the way approvals work; just upload 0.40.15 superseding it
<mvo> Kamion: thanks for the review. I uploaded a new version
<pitti> carlos: thanks for the mail
<dholbach> bbl
<ogra> Kamion, any hint about http://cdimage.ubuntu.com/edubuntu/daily/current/report.html ? it doesnt have an OVERSIZED tag in the dir...so i wonder what broke...
<j^> why is it that i need mp4 to watch go-opensource videos [http://www.go-opensource.org/go_open/news/download_go_open/]  but can watch aplle advertisement in Ogg Theora [http://theora.watchmactv.com/] ?
<Kamion> ogra: hmm, I'm not sure, nothing jumps out at me as obviously problematic there
<ogra> for me neither... i'll rip out kstars from ppc... probably it just overflowed silently ? 
<Kamion> ogra: ah, yes, it overflowed
<ogra> ok
<Kamion> ogra: the .OVERSIZED thing isn't reliable once you get beyond 700MB, at the moment
<ogra> ah, ok
<Kamion> ogra: so it probably means your CDs are just ridiculously big and you need to sort that out ...
<Kamion> CD 2 will only be filled with 17508534 bytes ...
<ogra> Kamion, another thing, if you find a minute, could you wipe the default IP from the installer ? the install can manage now without a special range
<ogra> is there a public place where i can see the second CD data ? 
<Kamion> it can? I thought I tried that and you told me it still broke after the fix
<Kamion> ogra: no
<Kamion> but "reduce what you're putting on the CD by 20MB or so" should be enough information; it doesn't matter exactly what randomly happened to go on CD2
<ogra> Kamion, ltsp can install now without braking the install.. that was the reason for putting it there first place
<Kamion> -EPARSE, sorry, try again
<ogra> the IP
<Kamion> it wasn't that that broke; it was a bizarre message in netcfg
<Kamion> which I thought I'd fixed, but IIRC you told me was still broken
<ogra> i still have the message and i think its unlikely we'll solve it now... nd the installer doesnt need a default IP anymore:)
<ogra> so just rip out the default and the message should be fine for now
<ogra> (trying to go with the least amount of work for you here)
<pitti> Mithrandir: we currently have cfengine-doc in main and cfengine in universe - should we unseed the former or seed the latter?
<Kamion> or do I totally misremember?
<pitti> Mithrandir: only having the documentation in main as the sole reason for keeping the source package in main seems silly
<Kamion> ogra: I thought you asked me to put the IP address in because you didn't want to use DHCP and you thought the static address question was unreasonably complicated or something
<ogra> Kamion, nope, you are right... but the reason for having a default there is gone... having it fixed with default would be nicer, but there is no urgent need for a default setting... 
<Kamion> if I remove the preseed then you won't see the "you should never see this message" thing, certainly
<Kamion> since that's triggered by some corner case in preseeding
<ogra> exactly
<ogra> but the IP should still be static...
<ogra> ltsp-server broke in base-config when the dhcpd range didnt match the configured IP, that was the main reason for having a default... this part is fixed....
<Kamion> ah, I see
<Kamion> although I think you're editing history a bit, because the IP address thing went into debian-cd long before any of the LTSP stuff did
<ogra> it would be nicer to have the right ip though... but i can live with a note in the install notes :)
<Kamion> ogra: anyway, done
<ogra> ta :)
<j^> pitti wrt /dev/raw1394 not being accessible for plugdev users by default. any chance to work that out for breezy?
<pitti> j^: sorry, I'm afraid not
<pitti> j^: we can't fix upstream software to use /dev/video1394 that quickly
<ogra> Kamion, the IP thing was planned from the beginning... but being forced to have a default was the thing that came later with ltsp...
<j^> pitti you never will
<ogra> (i'm probably just expressing myself wrongly :) )
<j^> pitti as i said before, raw1394 is the way to go, with the new libiec61883. its the only way to i.e. get HDV(aka MPEG2-TS over FireWire) working
<pitti> j^: ah, I remember that mess - this is such a broken design, there is no hope to get this right for breezy, I'm afraid
<pitti> j^: this needs to be discussed with upstream and kernel guys
<pitti> j^: we can't just allow all users to write to all Firewire devices, at least not without having evaluated the consequences properly
<Kamion> ogra: ok
<pitti> j^: there are more firewire devices than just video cams; Imagine Firewire hard disks, ethernet cards, and the like
<j^> pitti will you do this, talk with upstream/kernel guys? because so far i am not aware of someone complaining about the "broken design", besides you
<pitti> j^: if you are interested in that topic, can you do it yourself?
* infinity agrees that it's hideously broken.
<j^> pitti i see 4 firewire hard disks next to my camera, and i am dont care if i can access them via software
<pitti> j^: maybe *you* don't care
<j^> i can just drag and drop them on the floor
<pitti> j^: I will care if a random user can write anythign to my firewire ethernet card
<pitti> j^: so we can't open raw device access to all users *by default*
<pitti> j^: if you change this locally for you in /etc/udev/permissions.rules, that's of course fine
<j^> pitti, i am fine chaning that for myself
<pitti> j^: but it is by far not a proper solution for the default
<infinity> pitti : Good thing we just hired a Linux ieee1394 hacker, eh?
<pitti> j^: getting DV cams work OOTB would of course rock, but we should not sacrifice security for it IMHO
<pitti> infinity: we did?
<j^> pitti but thats not why i am using ubuntu, its because i just had to "fix" a friends lapotp so i could capture video
<infinity> pitti : BenC.
<pitti> infinity: oh, cool; I didn't know that he hacks on firewire stuff
<pitti> j^: I understand that it might be frustrating, but there apparently is no easy fix for breezy (or even a patch at all)
<pitti> j^: from a design perspective it is silly for an user app to assume that it can write to raw devices
<j^> pitti its also frustrating on the dev side, what way should i work on HDV support for gstreamer? and yes my goal would be that it works out of the box 
<pitti> j^: so for me this mainly looks like a driver/user app interaction problem
<pitti> j^: so the problem is that the /dev/dv1394 and /dev/video1394 do not offer an adequate interface?
<j^> pitti no they dont, also not for AMDTP (audio and music)
<pitti> j^: then it seems that this is the real bug
<j^> pitti have you filed a bug report?
<pitti> j^: no
<pitti> j^: I'm not a good person to push this; I don't have video cams and the like
<pitti> j^: talking with BenC could be enlightening, though
<bddebian> Hello
<j^> pitti if ben collins works for canonical now, you should talk to him
<pitti> j^: I can do that, yes
<pitti> j^: but I can't tell him more than "it does not appear to work, please fix it"
<pitti> j^: which packages are affected by this?
<pitti> j^: we should contact their upstreams and have them find a proper interface design with the kernel guys, instead of relaying this discussion over people who have NFC about the details
<j^> pitti kino, gstreamer, dvgrab, ffmpeg
<j^> pitti so far there pov is change permissions of /dev/raw1394
<\sh> guys...dpkg-divert...when I set up a divertion of file X to be renamed to file Y, is it only done once, or will it be regocnized even in future...let's say, kubuntu-docs is installed by default during a kubuntu-installation. now the user installs ubuntu-desktop with ubuntu-docs as dep...will it rename the ubuntu-docs link to the mentioned name in the dpkg-divert list?
<\sh> (regarding the ff default homepage problem) 
<Kamion> diversions stay in effect
<Kamion> dpkg honours existing diversions when installing new packages
<Kamion> you should make sure to remove the diversion when the package is removed, of course
<\sh> Kamion: sure..it's done..but if I install the kubuntu-docs package now, on a mix system, it divert the default ubuntu homepage to lets say index-ubuntu.html ...
<Diziet> When _your_ package is removed, that is.
<\sh> Kamion: means, when I'm starting up firefox, even in gnome, i have a kubuntu default homepage ;)
<doko> Kamion: I added openoffice.org2-help-en-us to the desktop seed
<Kamion> \sh: not much you can do about that
<Diziet> Are you saying you want the startup page to depend on what desktop the particular user happens to be running ?
<Kamion> doko: how big is it?
<doko> 12MB
<ogra> doko, how big is that ? 
* ogra cries
<Kamion> doko: er ... please revert that
<Kamion> doko: it must be a dependency of language-support-en instead
<doko> Kamion: hmm, ok
<Kamion> doko: talk to pitti to make that happen
<\sh> Kamion: ok..I wanted to be sure, that this way is ok
<Kamion> I think this might screw the live CDs, incidentally :(
<Kamion> only the install CDs currently have that kind of space available
<Diziet> \sh: The diversion will do what you might hope.  But it's not possible to override it eg by the syadmin.
<doko> Kamion: done
<doko> pitti: ^^^
<doko> could you add the openoffice.org2-help-* packages?
<\sh> Diziet: well..then it's fixed...I'll let riddell test it on a pure kubuntu install and I think then we're ready to upload the package..let's see
<\sh> Kamion: thx for the hint...it's a really handy tool ;)
<pitti> doko: yes, I'll add the help files to l-support-*
<pitti> doko: but 12 MB? that's nasty
<doko> pitti: thanks
<doko> pitti: why?
<carlos> seb128, no, sorry, the review-* will take more time as we need to fix them one by one by hand
<pitti> doko: because we already have overfull CDs
<pitti> Kamion: I still fail to see how replacing langpacks by English support packages is beneficial for the majority of users... *sigh*
<doko> pitti: no, mdz did remove thunderbird and ephipjany
<pitti> doko: ah, fine
<seb128> carlos: can I help on them?
<seb128> grrrrrrr
<pitti> doko: I will build new langpacks today anyway, in that course I will build new suport packages, too
<seb128> epiphany-browser got dropped? :(
<doko> pitti: for -en, you cannot depend on -help-en-us and -help-en-gb, that would be too big
<pitti> doko: humm, right
<pitti> doko: so which one should I pick?
<Kamion> \sh: use it with care
<doko> pitti: openoffice.org2-help-en-us
<Kamion> doko: (it's nasty anyway, because of the live CD problem)
<pitti> Kamion: should l-support-en only depend on -en-us, and we seed -en-gb? 
<Kamion> doko: mdz's removals only affected the install CD
<Kamion> pitti: yes
<Kamion> it'll have to do
<pitti> alright
<Kamion> for dapper I'd like us to consider installing something that pops up in place of the oo.o2 help content and points people to online help
<doko> Kamion: hmm, anything, I can do now?
<Kamion> this sort of 12MB growth isn't sustainable
<Kamion> doko: unless you can figure out how to do the above now ...
<doko> Kamion: we don't have online help
<Kamion> bah, y'all suck
<pitti> or, pops up and tells to install language-support-foo
<pitti> (or the help packages itself)
<Kamion> pitti: language-support-en is installed by default; I doubt that will change
<Kamion> but help packages, sure
<pitti> Kamion: we could seed a subset of l-s-en to desktop and enrich l-support-en, too
<doko> well, I can look at it, but I doubt, that I'll have sucess ...
<pitti> Kamion: (not for breezy, of course)
<pitti> I guess for breezy we just need to live with the current situation
<\sh> Kamion: for sure :)
<Kamion> pitti: that makes it unremovable by tools like language-selector, which seems like a regression
<pitti> hmm, right
<Kamion> pitti: we can't entirely live with it. #17123 is a blocker bug
<Kamion> which I had almost got fixed before the oo.o2 help thing came along
<sabdfl> jbailey: is your nightly bzr build up to date?
<j^> pitti ah ok, so there is some discussion about raw1394 #10517 and #14330
<jbailey> sabdfl: No.  Lifeless asked me to stop producing them while the shift to weaves happens.
<sabdfl> ok thanks, hope to see it again soon now that weave landed
<Diziet> Quiz question: what demented character set transformation (or sequence of transformations) attempts to represent U+00E9 (e', UTF-8 C3 A9) as C3 C2 A9 ?
<pitti> sabdfl: weave is fully there now? great, can't wait to try it out :)
<jbailey> sabdfl: Yup.  Basically it should be back when 0.1 has landed.
<sabdfl> which is tomorrow am aussie time, tonight your time
<janimo> Kamion, ping
<jbailey> Diziet: Is that still unicode?  There's a whole compose section that I suspect nothing honours.
<pitti> carloooooooos
<pitti> carlos: missing translations in the breezy tarball alert!
<Kamion> Diziet: UTF-8 C3 A9 run through iconv -f ISO-8859-1 -t UTF-8 gives C3 83 C2 A9, so maybe that's the start of it
<Kamion> janimo: pong
<janimo> Kamion. let me know when you have time for talking to me about seeds/buildd
<Kamion> jbailey: hmm, ubuntu-docs is hyooooooge. Anything we can do to reduce the amount of it that we have to ship on the live CD?
<carlos> pitti, ?
<carlos> pitti, which module?
<jbailey> sabdfl: Yup!  It will make it tonight if I'm awake when the aussies come on and give the go ahead, otherwise I'll email and look for the answer when I wake up.
<pitti> carlos: I /msg
<jbailey> Kamion: Yeah.  I'm trying to prune out unused graphics.
<sabdfl> ok, cool thanks
<carlos> ok
<Kamion> janimo: perhaps it would be better if you sent me mail with what you need
<sabdfl> actually, you know, a current build should be fine since it's post-rc2 which seems to have been well received
<janimo> Kamion,ok
<Kamion> janimo: cjwatson@ubuntu.com
<Diziet> jbailey: No, the result isn't UTF-8.
<Kamion> janimo: then I can deal with it regardless of whether we're both simultaneously online
<Diziet> Maybe something once more thinks it's ISO-8859-1, and decides to drop the invalid 83.
<Kamion> jbailey: ok, please do that urgently if you can - are there multiple documents in there at the moment that could perhaps be split out?
<Diziet> kamion: I'm about to upload new firefox and mozilla to add -fomit-frame-pointer re 17276.  I hope that's OK.
<Kamion> Diziet: yes, that's fine
<infinity> Kamion : I'm about to upload Thunderbird 1.0.7 (security fixes ahoy), do you want me to walk through the debdiff or anything with you first, or is "I've audited it, and the changes are all small and sane" good enough for you?
<infinity> (I've also been abusing it for the last while to make sure it's okay)
<Kamion> infinity: new upstreams need special exception; I'd prefer to leave this one to mdz
<Kamion> are *all* the changes security fixes?
<pitti> Kamion: yes
<pitti> Kamion: this time they stayed sane and did not add new features
<pitti> Kamion: well, sorry, not all fixes are
<pitti> Kamion: some patches fix regressions from previous security patches
<infinity> It's not all security, a few small bugfixes.
<Kamion> have the dependencies of the various locale packages been checked?
<infinity> Nothing even close to a feature, though.
<pitti> Kamion: yes
<infinity> Kamion : Locales packages are fine, the only thing that needs rebuilding is enigmail, which I'll upload at the same time.
<Kamion> ok, mdz should be up in a few hours, please run it past him
<infinity> Alright..
<Kamion> (or send mail and leave the packages in a location where somebody else can upload them later, if that's getting late for you)
<infinity> Nah, I suck at sleeping anyway, I'll wait up.
<Diziet> kamion: I already reviewed the diff between upstream firefox 1.0.6 and 1.0.7 and they seemed very good about it there.  Obviously I don't know for sure about Thunderbird.
<hno73> Kamion: are you now pulling the Ubuntu-AMD winfoss from here?: http://www.theopencd.org/winfoss/ubuntu-AMD/current/ (it's about 7MB smaller than the old one)
<Kamion> sabdfl: I'd like to consider taking python2.4-samba, python-opengl, and perhaps python-twisted out of the desktop seed. They (or their dependencies) are all large, and we're under serious space pressure on the live CD.
<Kamion> hno73: yes
<pitti> Kamion, mdz: for the records, I cannot use the current Rosetta tarball for building the gold langpacks, it has regressions again
<sabdfl> Kamion: is the livecd an exact desktop clone?
<Kamion> sabdfl: live CD includes all of ubuntu-desktop
<pitti> Kamion, mdz: let's hope that these can be fixed by tomorrow
<Kamion> and a few other bits, but only 8MB or so worth of other bits
<pitti> Hi jdthood 
<jdthood> hi ho
<sabdfl> Kamion: can the livecd be different to desktop?
<Kamion> we've squeezed pretty much all we can out without touching desktop
<Kamion> sabdfl: it's theoretically possible, but there's no infrastructure for doing it at the moment; I'm not sure I want to try to create that infrastructure three days before release
<Kamion> we thought we'd be OK for breezy without that
<sabdfl> i'm not sure i want to weaken our python position in favour of winfoss
<sabdfl> we already dropped thunderbird, right?
<hno73> heh, looks like I'm against the well
<Kamion> yes, but that only affected the install CD; thunderbird and epiphany were never on the live CD in the first place
<Kamion> is python2.4-samba really a core part of our Python position? at 5MB+ it's an awfully large piece
<infinity> Nothing depends on it, except the metapackages..
<Kamion> it's about as big as the OO.o2 database and spreadsheet components put together
<infinity> And, despite years of samba usage, I can't claim to have ever used it.
<infinity> Take that for what it's worth.
<hno73> The Ubuntu winfoss i386 is currently: OpenOffice2, Firefox and gaim
<doko> I think we don't loose anything removing python2.4-samba
<hno73> Firefox is 5mb, gaim is 6. We can't drop firefox though. the poor w32 users needs it :)
<infinity> (I don't suppose we could sneak PuTTY on the WinFOSS side?... Then I'd always have a copy everywhere I went..)
<infinity> :)
<infinity> elmo : ping ... Can I get a sync of expect-tcl8.3 from Debian?... The only thing is changes is to fix the FTBFS we just saw in -autotest.
<infinity> elmo : s/is changes/it changes/
<\sh> well...I would remove gaim, cause there are other, better GPL alternattives for gaim on windows, e.g. mirandaIM
<infinity> To each their own, I've used GAIM on Win32 for ages.
<Kamion> python2.4-samba accounts for 30% of the total space consumed by all python packages in desktop; there are 126 such packages in total
<Kamion> sabdfl: in any case, powerpc is also under pressure, and dropping WinFOSS won't help there
<smurf> IMHO dropping python-twisted won't hurt too many people (if any)
<sivang> lol, but really firefox on that cd is a must have, everytime someone cmoplains about viruses coming through it's explorer, I give them the WinFOSS cd :)
<Kamion> smurf: I'm reluctant to push for that one
<doko> smurf: on the desktop, it's not a loss
<smurf> Kamion: people who really want to use twisted need the docs anyway
<fabbione> Diziet: ping?
<infinity> Diziet : BTW, I'll apply the no-strict-aliasing fix to Thunderbird as soon as I get approval for the 1.0.7 upload.
<Kamion> samba's the big killer, at >5MB. opengl is 2.8MB or so, twisted is 1.2MB.
<fabbione> infinity: thanks.. that's what i was going to ask to Diziet 
<smurf> 5 MB is a lot of Python :-/
<Diziet> fabb: Yes ?
<Diziet> Oh, right.
<fabbione> Diziet: moz-thunderbird :)
<Kamion> it's almost all enormous .so files which are apparently big chunks of samba
<Diziet> The change is trivial.  OPTFLAGS += -fno-strict-aliasing in the right point in debian/rules.
<Kamion> or massive autogenerated bindings, I can't tell
<Diziet> Near where it says -DDEBIAN.
<Diziet> HTH.
<Kamion> hno73: what are the applications in the amd64 tarball at the moment?
<sabdfl> Kamion: ok, go ahead and drop them
<sabdfl> infinity: is 1.0.7 coming into breezy?
<infinity> sabdfl : That's the plan.
<infinity> sabdfl : It's security fixes, plus a few conservative bugfixes, just waiting on mdz to wake up for approval.
<pitti> sabdfl: if that happens, we will also put it into hoary and warty
<ogra> Kamion, * python-imaging-sane # pulls in big packages, can cut it if needed
<ogra> what about that one ? 
<hno73> Kamion: firefox, abiword, gaim, thunderbird
<doko> ogra: what do you save with python-imaging-sane
<ogra> doko, no idea, i didnt make that comment in the seeds....
<sabdfl> pitti: awesome, folks will be very happy i think
<ogra> but looking at it i dont see the mentioned big deps...
<doko> afaik libsane is needed by other packages as well
<pitti> Kamion: since I don't add ooo-help-en-gb to l-support-en, shall I also remove ooo-l10n-en-gb from it? it would save 2.5 MB
<hno73> Kamion: if you need to drop one I would say thunderbird
<sabdfl> python-imaging-sane can go
<smurf> doko: like OOo2 ;-)
<doko> smurf: ?
<pitti> sabdfl: hm, that's only 25 kB
<segfault> ogra: pong
<smurf> doko: wrt libsane
<pitti> sabdfl: sorry, didn't look at the dependencies; python2.4-imaging is big
<ogra> segfault, what arches do you have around there ? i'd like to prepare a xss package for testing for you... it seems the whole pt_BR.po file was set to iso-8859-1 
<ogra> segfault, i'd like to change that... all others are utf-8
<doko> pitti: python2.4-imaging is 300k
<segfault> ogra: just x86
<Kamion> sabdfl: thanks
<smurf> pitti: I'd rather keep python-imaging, it does have a couple of desktop-ish scripting uses
<pitti> doko: yes, it's still tiny comared against twisted and such, but more than 25 kB :-)
<pitti> smurf: agreed
<Kamion> ogra: I think that comment is out of date; there are no packages in desktop that are pulled in only by {python,python2.4}-imaging-sane
<ogra> segfault, ok, i'll prepare a package for testing later today... i'll ping you or add a comment to the bug
<pitti> but before we start to drop packages to free 70 kB (python-imaging) we should identify the bigger ones which can go
<ogra> Kamion, yes, thats what i figured now... i was just alerted by the comment :)
* Kamion removes the outdated comment; python-imaging-sane is not worth bothering with
<segfault> ogra: nice, thanks.
<Kamion> pitti: maybe that should be the other way round; at the moment the only OO.o2 locale we have on the CD is en_GB
<Kamion> pitti: so perhaps add openoffice.org2-help-en-gb instead?
<doko> Kamion: no
<pitti> Kamion: WFM
<Kamion> doko: ?
<pitti> Kamion: and same for -locale?
<infinity> Kamion : Approval for pppoeconf, svp.  According to feedback from people at bug 10080, this should fix it once and for all.
<smurf> Hmm, UBZ's FirstAgainstTheWall session will be interesting ;-)
<doko> Kamion: en-US is needed for OOo2
<doko> for all languages
<Kamion> doko: only help, or l10n too?
<doko> only -l10n, as as a fallback help, when the locale package is not found
<doko> so I would prefer -en-us over -en-gb
<fabbione> hey doko
<Kamion> doko: well, germinate output suggests that it is not that way at present
<Kamion> I agree with pitti; if we're taking en-us we should drop en-gb
<doko> Kamion: openoffice.org2-core depends on openoffice.org2-l10n-en-us
<Lathiat> infinity: i'll try out pppoeconf
<pitti> doko, Kamion: ok, so I seed l10n/help en-gb and add en-us to the l-support-en package?
<jbailey> It's funny to see a whole bunch of people who don't speak American English proposing that it should be the default.
<Lathiat> infinity: not sure this fixes upgrades tho
<Kamion> doko: oh, crap, ok
<Kamion> you're right; I hadn't checked deskop
<Kamion> desktop
<Kamion> pitti: yes, please do
<pitti> jbailey: few people would agree to put l-support-de onto the CD instead :-)
<infinity> Lathiat : I think we're too late to try to sort out upgrades on this one. :/
<doko> pitti: please test before, that en-gb is used as fallback help, if the language specific help is not installed
<Lathiat> infinity: heh
<pitti> doko: you mean en-us?
<Lathiat> i don't knwo why that patch was rejected upstream, its a perfectly sane thing to do
<Lathiat> i should ask the debian maintainer
<doko> pitti: AFAIU you do want to put help-en-gb on the cd, which IMO is wrong
<jbailey> pitti: I imagine.  But AFAIK, The US is the only place that uses US spellings in English.  I thought everywhere else used UK spellings.
<pitti> doko: no: <pitti> doko, Kamion: ok, so I seed l10n/help en-gb and add en-us to the l-support-en package?
<pitti> doko: I have to explicitly put -en-gb into supported since l-support-en does not depend on them any more
<Kamion> so, I've moved python-twisted and python2.4-samba out to supported; not sure about python-opengl, since it seems more obviously desktop-ish. we'll see how it goes
<doko> pitti: yes, you are reight
<pitti> doko: is that fine?
<doko> pitti: yes
<doko> fabbione: hi
<fabbione> doko: did you read the scrollback from this morning?
<doko> fabbione: nothing highlighted ...
<fabbione> doko: hmmm strange.. anyway OO2 works perfectly on sparc64.. it's way faster than the amd64 
<fabbione> but faster a lot...
<doko> cool :)
<fabbione> yup :)
<doko> fabbione: wait, until it's built natively for amd64
<doko> anyway, need to run, see you later
<fabbione> doko: right.. later..
<tepsipakki> kamion: sorry to bother you, but on the d-i preconfig-example it says that from kernel 2.6.9-> the number of environment and kernel variables is 32+32, but my breezy netboot won't accept more than 8 (+?)
<tepsipakki> kamion: so is this a bug or a feature?
<fabbione> tepsipakki: it depends how long they are
<fabbione> tepsipakki: there is also a limit in size
<tepsipakki> so a static network is basically not possible to put there?
<fabbione> tepsipakki: it depends.. it might be
<Kamion> yeah, I think the size limit is something like 256 characters - can't remember for sure
<tepsipakki> fabbione: I also need to preseed console-keymap and the preseed-file... so a full "append" line contains some 12 variables
<Kamion> tepsipakki: use kbd-chooser/method=us (or similar) instead of console-keymap-blah
<Kamion> that's usually shorter
<tepsipakki> ok, thanks
<Kamion> you still have the option of rebuilding the initrd to put a preseed file in there if necessary
<fabbione> tepsipakki: yeah, you are over the max lenght. I suggest you to do the minimum you need on the cmd line required to pull in the preseed file
<fabbione> and manage as much as you can from the preseed
<jdub> mjg59: ping
<tepsipakki> I already tried to work with the initrd, but the problem is that you need one initrd per machine, if they use static ip:s
<Kamion> you could possibly hack around that with variables set on the command line
<Kamion> (kernel command line)
<mjg59> jdub: Hi
<Kamion> i.e. NETCFG_IP=blah, then use a preseed command to fill in the actual preseed from that
<Kamion> or alternatively use /preseed.cfg in the initrd for everything except the IP address
<jdub> mjg59: Robot101 asked me about something you wanted to do on the 12th - is that in addition to the formal hall?
<Kamion> or use kickstart (which brings the network up earlier) and supplement the result with preseeds for finer control
<tepsipakki> uh, kickfart
<Kamion> it's just a layer over preseeding in Ubuntu
<Kamion> pejorative names notwithstanding
<tepsipakki> but I've just learned to love d-i ;)
<tepsipakki> (and hate)
<Kamion> kickstart in Ubuntu *is* d-i
<mjg59> jdub: Yup
<Kamion> we translate kickstart directives into d-i preseeding
<ogra> tepsipakki, its the "Kamion is a magician" ubuntu kickstart :)
<jdub> mjg59: what are the timings?
<tepsipakki> ogra, kamion: ok ok I'll look into it ;)
<mjg59> The meal will be 7:30ish
<ogra> tepsipakki, and it has a nice gu to ease the work
<mjg59> If you wanted to give a talk beforehand, that could be arranged
<ogra> s/gu/gui
<pitti> Kamion, doko: new support packages uploaded, seed adjustments done
<tepsipakki> ogra: my gui is the cmdline and cron
<Kamion> ogra: IME people doing lots of funky installer deployments don't really care about GUIs, but your mileage may vary
<ogra> i found the gui very helpful...
<Kamion> pitti: d'oh, I'd just uploaded ubuntu-meta
<pitti> Kamion: and that hurts?
<Kamion> oh, good, I don't need to reupload it
<Kamion> nah, just mistakenly thought you'd have had to change the live seed
<pitti> Kamion: the seeding was just to make anastacia quiet
<pitti> ah, alright
<tepsipakki> ogra: the server I work with is a woody
<Mithrandir> pitti: (re cfengine and -doc), yes that sounds silly.  If anything, we should rather have cfengine2 in main, not cf1.
<pitti> Mithrandir: I just did a security fix to cf1, cf2 also needs one
<pitti> Mithrandir: can you please discuss this with mdz/Kamion and unseed it perhaps?
<segfault> ogra: IIRC, you can use "recode" to convert everything from ISO-8859-1 to UTF-8
<Kamion> segfault: or just iconv, which comes with glibc
<ogra> segfault, that should be done on build depending on the charset selected in the po file ...
<ogra> segfault, there are no special chars in the pt_BR file, except this one line
<segfault> humm, ok
<Mithrandir> pitti: yes, once my body stops melting and my head stops wanting to explode, I can.
<\sh> ogra: do u need a german sun usb keyboard including mouse?
<\sh> ogra: new one
<ogra> segfault, in fact, if you look a bit closer, all strings that are translated have the translation: "Propriedades da proteo de tela
<ogra> "
<ogra> \sh, absolutely !
<\sh> ogra: ok...u sure they're running on a bloody x86 laptop?
<ogra> why not...
<\sh> ok...grab one for u as well...ish throws out...NEW SUN USB keyboards +lol*
<ogra> i used susus's ppc keyboard when i had to work around the breakage on my laptop...
<Kamion> Riddell, ogra: I'm going to do {kubuntu,edubuntu}-meta uploads to sync up with Ubuntu seed changes, if that's OK
<Riddell> Kamion: ok with me
<ogra> Kamion, will you trigger new CD builds after that ?
<\sh> ogra: delivery will be friday after work ;)
<Kamion> ogra: no, I'll probably just wait for the dailies
<ogra> Kamion, else leave it to me, i'll have to find another 20MB to drop on ppc anyway
<Kamion> ogra: ok, fine
<segfault> ogra: yeap... xscreensaver is messed up. Should i work on it or gnome-screensaver will be the default on dapper?
<ogra> segfault, gnome-screensaver will be the default on dapper... but xscreensaver is the supported one fr breezy...
<ogra> Kamion, any opinion ? the po file for pt_BR is totally messed apparently... would it be ok to replace the complete translation at this point ? 
<segfault> ogra: no problem then. i'll try to work on it.
<Kamion> ogra: I've done a seed merge, which should help
<Kamion> (slightly)
<ogra> ok, thanks :)
<Kamion> ogra: what package is this?
<\sh> ok..going home....
<\sh> cu around 
<ogra> Kamion, xscreensaver
<Kamion> ogra: yes, if you do it very soon
<ogra> Kamion, it would else pick up pt.po 
<ogra> segfault, so if you volunteer, id replace the whole traslation...
* ogra doesnt speak pt :)
<segfault> ogra: but please change the desktop description. :-)
<segfault> ogra: i can work on it, when is the deadline?
<ogra> segfault, in pt you mean ? would that be ok for normal pt translations ? 
<ogra> segfault, last month ? *g*
<ogra> segfault, no, to be serious, asap...
<segfault> ogra: heh. pt should be ok, and at least change the desktop file, because the "screen" description in pt is "ecr", and in pt_BR is "tela"...
<ogra> ah
<segfault> ogra: i'll try to work today, changing in rosetta would be sufficient?
<ogra> hmm, i thought you couldnt fint it in rosetta
<ogra> *find
<Kamion> hno73: how much space would we save on amd64 by dropping Thunderbird?
<segfault> ogra: its there, but looks like to be empty
<segfault> dunno why.
<hno73> Kamion: 5.75 MB
<segfault> kamion: are you guys fighting to get all the langpacks in the livecd? :P
<Kamion> segfault: not a hope. I'm fighting to get everything *else* in the live CD that has to go in there
<segfault> kamion: the live dvds should contain them, right?
<Kamion> hno73: let me get back to you on that. I think it'll be necessary, but don't have the figures right now
<hno73> Kamion: make that 6mb (some screenshots get removed too)
<Kamion> segfault: at the moment I'm afraid the live DVD contains the same filesystem image as the live CD
<Kamion> we should probably fix that eventually
<hno73> Kamion: OK
<Kamion> or else make it know how to install language packs from the archive on the DVD, which contains the .debs
<ogra> pitti, a reboot is required if i update xscreensaver ???
<segfault> probably not, just kill the daemon
<da_bon_bon> does the hibernate of ubuntu unmount all disks before hibernating ?
<ogra> pitti, it will break if it doesnt reread the X defaults from /etc/X11/app-defaults ... but asking for a reboot is heavy... this code was there since warty and is also in debian
<ogra> segfault, thats exactly what it does since ages
<Kamion> -Depends: myspell-ga, aspell-ga, mozilla-firefox-locale-ga-ie,
<Kamion> +Depends: myspell-ga, aspell-ga, mozilla-firefox-locale-ga-ie, , openoffice.org2-help-ga
<Kamion> pitti: looks funny
<pitti> ogra: no, of course a reboot is not required
<Keybuk> seb128: ping
<seb128> Keybuk: pong
<pitti> ogra: for my sake you could just drop the kill command completely
<ogra> pitti, this will break
<Keybuk> seb128: could you add "exec 2>/tmp/network.log" to the top of /etc/hotplug/net.agent for me and attach that file to your bug
<ogra> pitti, the daemon will just silently quit... 
<pitti> Kamion: oh, I think I know what's wrong - I should filter out empty lines in the db lists
<seb128> Keybuk: sure, doing that now
<pitti> Kamion: shall I upload a new one?
<Kamion> pitti: does it actually break anything? if not, no need
<Kamion> if so, feel free
<Keybuk> uh, sorry net.rc!
<Keybuk> actually, can you add it (with 2>> instead) to the tops of net.agent, net.rc and net.ifup
<Keybuk> and stick "set -x" after it <g>
* Keybuk gets his brain in gear
<pitti> Kamion: dpkg-buildpackage seems to sanitize it anyway
<ogra> pitti, i tae back the "since ages" :)
<ogra>   * debian/xscreensaver.postinst:
<ogra>     + send SIGHUP to all running xscreensaver processes.
<ogra> [....]    -- Josselin Mouette <joss@debian.org>  Thu, 24 Mar 2005 00:06:43 +0100
<ogra> *take
<pitti> ogra: I just generally think it is evilish
<pitti> ogra: especially if it breaks screen locks
<ogra> pitti, but it will have evil side effects if it doesnt reread the config
<pitti> ogra: but if it breaks otherwise, I'll shut up :-)
<ogra> i.e. it might just stop working the next time xscreensaver-command acts
<pitti> ogra: why should it? once it runs, it shouldn't re-read its config, or does it?
<pitti> ogra: but if it stumbles over a new config later, why should it work if you forcefully restart it?
<ogra> if the config changed on upgrades it needs to reread the changes... to not call non existing screensavers etc
<ogra> and there were a lot changes hoary->breezy
<ogra> i.e. the lockscreen will not work if the new config isnt in place...
<ogra> (the handling of the new login button done by upstream is through the new config file... the lockwindow drawing depends on it for example)
<Kamion> pitti: ok, fine, can just be left alone then
<Keybuk> hmm, you know, sometimes I think my brain has a flappy-paddle gearbox
<pitti> ogra: not having the new login button until the user reboots seems fine to me, but of course it should not just die
<ogra> pitti, the real bug is that xss doesnt act rigth on HUP
<pitti> ogra: still this is confusing to me
<ogra> pitti, you dont understand...
<pitti> ogra: either xscreensaver restarts automatically (i. e. after killing it) or it doesn't
<ogra> pitti, the whole window and all text will be gone ...
<ogra> its not that easy...
<pitti> ogra: I didn't claim that it was easy, I just want to understand it :-)
<pitti> ogra: if it breaks that hard, then the current way needs to stay for breezy anyway
<ogra> pitti, exactly...
<seb128> Keybuk: 17472  updated
<Keybuk> elmo: could you PLEASE buy us a real SSL cert
<Keybuk> or just change to one that's not EXPIRED :p
<ogra> pitti, and the right fix is to move on to a better screensaver implementation... i'm fine with having the same behavior sarge and sid have now...
<ogra> ...and to move to gnome-screensaver next week :)
<Znarl> Keybuk : I know, I know.  I will get to it soon.
<Keybuk> seb128: hmm, your /etc/iftab is trying to swap your ethernet cards around?
<Keybuk> (it's plugging eth0, and getting it renamed to eth1, and getting all confused)
* ogra drops gcompris from powerpc with tears in his eyes...
<seb128> Keybuk: that's a stock install, iftab has eth0 / eth1 lines with the corresponding mac
<Keybuk> right, try swapping them around <g>
<Keybuk> so what was eth0 is now eth1, and vice-versa
<Keybuk> fix network/interfaces to match
<ogra> lol
<Keybuk> hotplug can't deal with interface swapsies because it's stupid
<Keybuk> it decides it needs to coldplug eth0 and eth1, starts eth0 which has to be renamed to eth1, so moves eth1 to eth2 and eth0 to eth1, then ifup's eth1; then starts on eth1 (not eth2)
<azeem> Md agreed to first look at /etc/modules in the future, so you can force an order through that, btw
<mjg59> This would be easier if we just put mac addresses in e/n/i
<Keybuk> mjg59: that's my dapper plan
<mjg59> Hurrah
<Keybuk> to remove all vestiges of eth0/eth1 etc. so they just don't fucking matter
<Keybuk> the user will see "Wireless card" and "Wired card" or whatever
<azeem> what about NetworkManager?
<azeem> does that play with e/n/i at all?
<Keybuk> basically same as we do for sda* -- doesn't matter what the * is as long as the mount point is sane
<seb128> Keybuk: switching eth0/eth1 from iftab fixes the issue
<Keybuk> seb128: I thought it might; thanks
<seb128> np
<Keybuk> I had a fix for that, but the fix breaks more than it solved
<seb128> any chance it got fixed for 5.10?
<Keybuk> no, it's just too damned low-level
<seb128> k
<seb128> what component decide the switch the cards?
<Keybuk> and completely broke pcmcia network cards, etc.
<Keybuk> ifrename
<Keybuk> I want to kill ifrename, and just make it so we never care which card is eth0 and eth1, because we configure by MAC, rather than kernel-assigned-random-number
<mjg59> Keybuk: Are we still using ifrename?
<mjg59> (since it gets called on resume)
<Keybuk> yes, in breezy
<seb128> hum, k
<mjg59> Ok
<Keybuk> breezy's hotplug is a mess, sadly
<j^> Kaloz configuration based on MAC is not so nice on a server, where you just want to replace the first network adapter and be done with it
<Keybuk> j^: define "first"
<Keybuk> is that the first by PCI order, the first by module load order, or the first by entropy of whichever one completes PCI initialisation first?
<Lathiat> Keybuk: any idea if hotplug-ng is at all sane?
<j^> Keybuk i know thats right now order of modules, pci order
<Keybuk> Lathiat: "replacements for hotplug" are very sane
<Keybuk> j^: actually, wrong
<Lathiat> Keybuk: i more meant hotplug-ng specifically
<Lathiat> but ok
<Keybuk> modules now don't block during loading
<Keybuk> load one with firmware before one without
<Keybuk> and guess which way they end up plugged
<Keybuk> (tip: it's pretty much 50/50)
<Keybuk> you can even get a cute effect where loading them means the second one wins because it's got better PCI karma
<Keybuk> even without firmware
<Keybuk> it's just too unpredictable these days
<Keybuk> I think it's _FAR_ better for you as a sysadmin to assign names to them (if you don't like the ones the Installer picked)
<Keybuk> so you could replace "Wired Ethernet Card #1"
<Keybuk> and not care which eth? that was
<Lathiat> i think you more need reliable actual names, for scripts etc
<jdthood> Lathiat: There has been discussion of this in #290
* Lathiat looks at it
<Lathiat> malone?
<Lathiat> hm, no
<Lathiat> ah i was using the wrong url to bugz
<Keybuk> which scripts?
<Lathiat> Keybuk: anything use interface names
<Lathiat> say, iptables
<Lathiat> pppoe
<Keybuk> we'll find a way to fix those
<Keybuk> the other option is just not using eth* and assigning different names to them with ifrename
<Keybuk> which is even ickier
<Keybuk> and actually has exactly the same damned bug
<Keybuk> ifconfig net0 would annoy people
<Lathiat> cant we just assign an ethX to each new card we find
<Lathiat> and keep it only for that
<Keybuk> no
<Lathiat> why not?
<Keybuk> because the kernel assigns those
<Lathiat> yeh but you can rename them?
<Lathiat> if we make issues with that not suck
<Keybuk> right, but what if the X is already taken by another card?
<Keybuk> which you're also _simultaneously_ hotplugging?
<Lathiat> my point being, it shouldnt
<Keybuk> but it will be
<Lathiat> so the first time you hotplug
<Keybuk> two network cards, the first is eth0, the second is eth1
<Lathiat> Keybuk: oh so your saying
<Lathiat> at the split second you get both
<Keybuk> you want to swap them
<Keybuk> excatly
<Keybuk> you can't, because you're trying to swap them both simultaneously
<hughsie> hey, desrt?
<Lathiat> could hack the drivers to initially name them netX and rename to ethX ;p
<Keybuk> that's just as bad
<Lathiat> and then first time you find a card, assign ethX, and then rename to that each time you see it, and nothing else wil el ever use it
<Lathiat> heh
<Lathiat> yeh
<jdthood> eth_X would be better than netX
<mae> If something is MIT licensed, is it legal to take that code and incorporate it into gpl code and then release it as gpl code?
<jdthood> You just need to use a separate namespace.
<\sh> does anyone have a sun keyboard map for x86 xorg with german layout?
<Keybuk> mae: no.  you must release it as MIT code
<Keybuk> but you can integrate MIT code into GPL code, and release the GPL bits as GPL, and the MIT bits as MIT
<Keybuk> which is what you intended to mean, you just need to be carefully specific
<mae> Keybuk, but the mit license says basically, you are free to do whatever you want to it.
<Keybuk> except relicence
<Keybuk> the MIT licence does not grant you that permission
<mae> ah.
<Keybuk> it is however compatible with the GPL, and vice-versa, so code licenced under both can be combined into an aggregate work (with each bit licenced appropriately)
<Lathiat> mae: you could also  ask the author if theyd relicense it to GPL
<Keybuk> jdthood: that's just a kludge though, in the long term
<Keybuk> I think removing reliance on the kernel-assigned names is the right solution
<Lathiat> Keybuk: but thats hard to do nicely
<Keybuk> it's _SO_ easy for a firewall script to get the name of the device from the address
<Keybuk> Lathiat: isn't, it's pretty easy actually
<Lathiat> Keybuk: sure but addresses arent always static
<Lathiat> many ISPs (here at least) assign dynamic IPs say
<jdthood> Well, using ifrename to map to eth_X eliminates dependency on what the kernel decides to name interfaces originally.
<Keybuk> address == MAC address
<Lathiat> Keybuk: oh, right
<jdthood> Other solutions are just going to reproduce what ifrename already does, in other tools.
<Lathiat> still makes it hassly for lots of existing stuff
<Keybuk> jdthood: not at all
<Keybuk> I'm saying we configure network interfaces based on details other than their kernel-assigned name
<jdthood> ifrename looks at the MAC address and assigns a name, say eth_0.  This is a stable name that can be used by everything else.
<Keybuk> Lathiat: the existing stuff will work as well as it does now, because it will use the kernel-assigned names which we won't change
<Keybuk> the existing stuff is _currently_ sensitive to kernel-assigned name changes
<jdthood> The alternative suggestion, I take it, is to make everything else look at the MAC addresss.
<Keybuk> jdthood: where "everything else" is basically just network-manager
<Lathiat> Keybuk: doesn't solve reliability for other thigns tho, thats what im trying to say
<Lathiat> but yes, that would be a start
<Lathiat> whats plans for dapper in hotplug/udev/etc land
<jdthood> Well, reinventing the wheel seems to be the name of the network-manager game.
<sivang> Lathiat: see the first groupe of BOFs suggestions :) (most of them but scott I think)
<jdthood> In Debian I take it Md has replaced hotplug with udev and coldplug.
<j^> sometimes its better to start over than to try to fix things
<Keybuk> Lathiat: not for "existing" stuff, but we'll provide an easy way for those to be updated to work
<j^> jdthood but i do not agree with your that network-manager is about reinventing the wheel, it actually brings network configuration to the desktop, something i did not see before on linux.
<Keybuk> firewall configuration in a "network up" event that confirms the card is the right one -- rather than a boot-time script run at a hopeful point in the sequence
* netjoined: irc.freenode.net -> brown.freenode.net
<Keybuk> new world order should be an /etc/scripts/firewall-dmz which has at the top "run when interface up 12:34:56:78:9a" or something
<mdz> seb128: what is the reason for this evolution-2.2.desktop addition?  it seems safe of course, but I don't understand why it is necessary
<Keybuk> you could even add "hourly, boot, ipod plugged in" type triggers
<Keybuk> but that's a bit past dapper, which has to be supportable for a while <g>
<infinity> Ahh, mdz, ahoy!
<Keybuk> morning, boss
<sivang> mdz: there's an issue with that one , after an upgrade the panle's link/launcher stops to work
* netjoined: irc.freenode.net -> brown.freenode.net
<seb128> mdz: gnome-panel writtes its configuration on first startup. You install hoary, login evolution-2.2.desktop is used. You upgrade to evolution2.4, the package ships evolution-2.4.desktop ... 
<infinity> mdz : I've reviewed the upstream thunderbird 1.0.6 -> 1.0.7 diff, and it's all very small/safe security and bug fixes.
<ogra> mdz, do you have any suggestion about my ldm change i mailed you on friday ? i'd like to see that in, its already available in my bazaar repo
<infinity> mdz : I've been running test packages here for the last 12+ hours, stressing them a afair bit, and all is well.
<seb128> mdz: did you get my mail about it ?
<infinity> mdz : Do I have approval to shove it into breezy (and do the security updates with 1.0.7 to hoary/warty)?
<HiddenWolf> hm, firefox is slow
<dholbach_> re
<infinity> mdz : As well as do the -fno-strict-aliasing fix (in breezy only)
<pitti> Hi mdz 
<mdz> seb128: yes, package is approved now
<mdz> infinity: thunderbird 1.0.7 OK
<mdz> ogra: did you talk to Kamion about fixing this it on the ssh side instead?
<mdz> I don't know where ssh gets its default PATH from
<infinity> mdz : Thanks.
<mdz> probably hardcoded, knowing those guys
<ogra> mdz, all DMs do it this way, i dont think setting /usr/games for ssh at complie time would be right... Kamion ?
<infinity> mdz : Can I get you to approve the pppoeconf in the queue too?
<infinity> mdz : The patch applied there has had some positive feedback from a few users.
<ogra> mdz, its hardcoded
<ogra> mdz, i checed gdm, wdm and xdm, they all set the path themselves before establishing a session...
<mdz> infinity: already done
<infinity> mdz : Cheers.
<mdz> ogra: but we don't use gdm, wdm or xdm
<mdz> ogra: everything should use the same default path, including ssh
<ogra> mdz, but we establish a session after login... 
<ogra> mdz, root shouldnt have /usr/games in the path...
<mdz> ogra: why?
<ogra> heh, no idea, beacause its traditional ? 
<mdz> Kamion: what's the latest on the live CD squeeze?
<ogra> Kamion, any opinion? ltsp needs /usr/games in PATH ... ssh has set a default path without it at compile time, if i understand it right, ~/.ssh/environment is considered evil 
<wasabi_> hey so, need some oem-config advice. Installing it on a chrooted system, want to configure it so it pops up on the first boot of the chroot.
<wasabi_> Not finding what needs to be set in inittab documented.
<ogra> Kamion, my guess would have been to set the path from ldm bfore the session is established
<ogra> Kamion, mdz thinks that should be done in ssh
<seb128> Keybuk: are you sure than the eth bug affect "few unfortunate people"
<seb128> Keybuk: my laptop has nothing special, it just has a wireless eth0 and an eth1 (and it works fine with hoary)
<Keybuk> tbh, I really don't know
<Keybuk> the installer seems to sometimes randomly plug them the other way to the boot sequence
<Keybuk> which is why you end up with a backwards iftab in the first place
<seb128> so there is an installer bug too?
<Keybuk> the installer detects hardware differently
<Keybuk> for whatever reason it saw your wireless card first, so named that eth0 and your wired eth1; if I'm reading the runes right
<Keybuk> where the normal boot sequence sees your wired card first and your wireless seconds
<Keybuk> and ifrename tries to swap them, but hotplug fucks it up
<seb128> hum, I though that the wireless had been eth0 
<seb128> with hoary too
<seb128> not sure right now though
<seb128> I'll play with that
<Keybuk> I'd love to know why the installer behaves like that
<Keybuk> it might have something to do with when the restricted modules get added to the pudding I guess
<Keybuk> or even just the wireless ones
<Keybuk> I couldn't get it to do anything here
<Keybuk> the explanation how to fix it ("swap the lines in iftab") was far less scary than a ground-up rewrite of the hotplug net.* stuff right before release
<seb128> sure
<seb128> but it makes than the laptop works out of the box with hoary and not now
<mdz> my desktop hung overnight, second time this week
<seb128> I've to "sudo dhclient" before doing anything
<mdz> s/this/& past/
<mdz> not very confidence-inspiring
<seb128> I don't expect any user to go edit /etc/iftab
<mdz> something X-related, the box was still alive and on the network
<Keybuk> seb128: the reports are incredibly rare, yours is actually the first since well before preview
<jdthood> mdz: What video driver?
<mdz> jdthood: ati
<Keybuk> and the last person did a reinstall and it didn't happen that time :-/
<mdz> was very stable for most of breezy
<seb128> Keybuk: crispin just pinged me on #epiphany when you dupped my bug from 290 saying the bug is really annoying, but yeah, that does only 2 people :)
<jdthood> mdz: https://bugs.freedesktop.org/show_bug.cgi?id=4486 ?
<Kamion> ogra: at this stage, I'd much rather see the change happen in ldm
<mdz> there haven't been ati changes in breezy for quite a while, I don't think
<seb128> Keybuk: I've done random candidate/daily install for 10 days, that happens 100% of the time here
<infinity> mdz : If you can approve expect-tcl8.3 too, that'd be great (just an FTBFS fix)
<mdz> jdthood: that's vague enough to match my symptoms
<Keybuk> it's a bit confusing because #290 was originally a different bug, but it's become the home to this problem now <g>
<ogra> Kamion, me  too... do you think doing it in shh would be right at all ?
<mdz> infinity: done
<seb128> Keybuk: just booted hoary on the laptop, eth0 is ipw2200, eth1 is 8139 ... ie: the same
<ogra> *ssh
<Kamion> ogra: .ssh/environment is security-broken and will go away
<infinity> mdz : The only radeon changes I know of are blacklisting (and unblacklisting) renderaccel on various PCI IDs.
<Keybuk> oh bugger
<Keybuk> you know what I think it is
<infinity> mdz : If you haven't noticed X getting noticeably slower and/or faster, that hasn't hit your card.
<Keybuk> in breezy, firmware for the ipw2200 isn't loaded synchronously
<ogra> Kamion, yup, thats how i understood it
<mdz> infinity: and that only on 20 Sep according to the changelog
<hub> seb128: the abiword package in main does not have equation and grammar support :-(
<hub> seb128: FYI
<Kamion> ogra: not really; I'm fairly sure that if I put /usr/games in root's $PATH I'd get bugs saying "why is all this random crap in my system administration path?"
<seb128> hub: what is needed for that? build-depends?
<Keybuk> so ipw2200 is loading firmware while 8139 is loading and beats it to getting eth0
<Keybuk> so at boot, they get swapped
<mdz> I'm unable to get the video card back into a working state by any means other than a hard reset
<seb128> Keybuk: better explanation imho
<mdz> it's good and wedged
<hub> seb128: gtkmathview and link-grammar respectively
<Kamion> ogra: shouldn't you be starting a user session in some way rather than relying on root's path? I'd have expected root's path to be essentially irrelevant for desktops
<Keybuk> random, could you try booting with the hoary kernel on the breezy userland? :p
<hub> seb128: I should check the package: we had a talk with joshk last night
<ogra> Kamion, ldm runs ssh -X <server> Xsession
<Keybuk> actually, that almost certainly won't work :-/
<Keybuk> udev won't start
<jdthood> mdz: Search bugs.freedesktop.org under the ati and radeon driver components.  There are lots of reports of X lock ups, most that are reproducible under particular conditions (such as: only with acceleration)
<mdz> jdthood: I have no explanation for why it only started happening recently, though
<ogra> Kamion, so there are three points where we could set it, ldm, ssh or Xsession...
<Keybuk> does crispin also have an ipw/non-firmware combination?
<seb128> hub: not main packages, this is not going to be changed for 5.10 ...
<Keybuk> and does the ipw win eth0 in the installer (and iftab?)
<seb128> Keybuk: asking
<mdz> ogra: Xsession doesn't and shouldn't set a path
<ogra> Kamion, by looking at all other DMs i found they set it before establishing a session...
<ogra> mdz, yup... 
<hub> seb128: fine with me. I just thought you should know
<Kamion> ogra: surely you should be running the remote session as non-root
<seb128> hub: yeah, thanks
<ogra> Kamion, yes
<Kamion> i.e. ssh -X nonprivilegeduser@<server> Xsession
<infinity> mdz : Even more curious, when you realise that 99% of video card lockups wedge the hardware so badly that the wohle machine freezes, so your bug is SPECIAL.
<infinity> mdz : Then again, that also makes youre a tiny bit debuggable, perhaps.
<infinity> s/youre/yours/
<ogra> Kamion, err, yes, i omitted that bit, sorry... indeed we give the username to ssh
<hub> seb128: equation in a plugin. grammar too. so we can make universe packages for that:-) and push them to the next release in main :-))
<Kamion> ogra: ah, I see, it's not about root at all - something in scrollback confused me
<mdz> yeah, unfortunately I was in no position to debug it the last time
<seb128> hub: no, because abiword source package is main and the Build-Depends have to be main
<Kamion> ogra: I'll fix ssh to include /usr/games in the default non-root $PATH
<ogra> Kamion, ok, thanks :) that was my last bad edubuntu bug
* ogra hugs Kamion 
<Kamion> ogra: go ahead and reassign the bug to me
<ogra> Kamion, ok
<hub> seb128: we'll talk about that at ubz :-) no urge
* infinity wonders why /usr/games still has its own binary path...
<mdz> Kamion: are we still overflowing after removing -twisted and -samba?
<mjg59> infinity: Has fglrx changed at all lately?
<elmo> Riddell: ?
<Kamion> mdz: I don't know yet - sorry, I was at the shops and am still working my way through all the questions people asked me in the meantime :)
<infinity> mjg59 : Define "lately"... Hasn't for a month or so, at least.
<jdthood> mdz: Is X using 100% CPU?
<Kamion> mdz: FWIW the reason that the default paths are built into sshd is that there is no stable API for extracting the values from /etc/login.defs
<mjg59> infinity: Ok. Suspend/resume seems to have broken for a load of fglrx people over the past week or so (not that I actually care, but still)
<Kamion> (no, grep doesn't count)
<mdz> Kamion: perhaps we should have a SetDefaultPathInOneGodDamnPlaceSpec at UBZ
<infinity> mjg59 : Ask them what framebuffers they're running, that's more likely a culprit than fglrx itself.
<Riddell> elmo: hi
<mdz> jdthood: dunno, this was last night and I reset it
<Keybuk> could we have a SetDefaultLang/Umask one too?
<infinity> mjg59 : The revelation that usplash now supports vesafb may have caused a mass migration or something.
<mjg59> Ah
<mjg59> True
* Keybuk still has a list of the 482 files that need changing to ensure a different umask on login <g>
<Kamion> mdz: I'd be happy to talk about it with shadow upstream at some point if I get the time
<infinity> mjg59 : Also, radeonfb is known buggy (read: effin' broken) on most setups, so if anyone's using that, rap them on the knuckles.
<Kamion> it's certainly been a long-standing annoyance
<ogra> Kamion, err, i have no bugreport about it, only user reports about non working games entrys in the manu... want to fill me a new one? 
<Kamion> ogra: never mind then
<ogra> ok
* infinity goes for a walk to the store while his poor little DSL line uploads TBird.
<jdthood> "System locks up w/ radeonfb" https://bugs.freedesktop.org/show_bug.cgi?id=197
<Kamion> mdz: so I doubt -twisted and -samba will free up enough space, but they will get us a good chunk of the way there; the questions are (a) whether removing Thunderbird from the amd64 WinFOSS tarball will be enough after that, (b) whether powerpc will fit after that
<Kamion> mdz: what do you think about python-opengl? it does seem moderately desktop-ish
<mdz> Kamion: as far as I'm concerned all of the python-* in the desktop seed is superfluous, but sabdfl has been known to disagree ;-)
<Kamion> mdz: sabdfl OKed removing python-opengl if we needed to
<janimo> elmo, is there an xfce4-taskmanager in the NEW queue? I uploaded one today but got no mail not even reject
<Kamion> wasabi_: I don't use inittab to start oem-config any more; it caused a variety of tedious problems
<janimo> I just signed it the changed-by field is not whitelisted
<Kamion> wasabi_: see /usr/lib/base-config/menu/oem-config, which does 'update-rc.d oem-config start 12 2 3 4 5 .'
<Kamion> janimo: it's been processed already
<pitti> janimo: xfce4-taskmanager_0.3.1-0ubuntu1_source.changes was accepted
<pitti> janimo: at 2005-10-10 17:25
<janimo> hmm I wonder why I got no mail
<janimo> thanks
<pitti> janimo: yep, and it is in nEW
<seb128> Keybuk: <crispin> seb128: yeah, an ipw2200
<janimo> can the NEW queue be seen from the outside?
<Kamion> janimo: no
<Keybuk> ok, so I understand why the bug affects you now
<Keybuk> the ipw driver used to block for firmware, but that was crap because if you didn't find it in time, the driver sulked
<Keybuk> they changed it to request firmware and get called back, which means the kernel is free to load other things while it's waiting
<Kamion> mdz: daniels tells me that xorg -77 fixes a mistaken lack of stripping of drivers, thereby saving a fair amount of space; it seems to revert the problematic untested stuff from -76. What do you think of it?
<mdz> Kamion: oh, I didn't notice that -76 had been replaced by -77 in helena output.  I'll have a look
<seb128> "<crispin> seb128: yeah, but I don't have the 290 problem on my laptop, just a desktop machine" ... grumpf, no clear
<Keybuk> seb128: his desktop, I think, has an odd card which d-i doesn't recognise but lrm does
<seb128> may be
<Keybuk> and it's at a higher pci number, so gets plugged on boot t'other way round
<mjg59> Keybuk: Like any Atheros?
<Keybuk> atheros tend to be later in the pci numbering than the internal
<Keybuk> the problems are:
<Keybuk> 1. the kernel plugs devices in a random order
<Keybuk> well, pseudo-random
<mjg59> Keybuk: Atheros stuff isn't supported in d-i
<Keybuk> which is in their view notabug, because you shouldn't rely on the order; and they go into details about schroedinger's network card which is a bit like schroedinger's freedrom toaster, but without the plane crash
<Keybuk> 2. the events arrive at userspace in a random order
<Keybuk> which is pretty much just #1 again
<Keybuk> 3. userspace takes a random amount of time to react to the event
<Keybuk> 4. the event takes a random amount of time to finish
<Keybuk> fortunately we live in a universe of malignancy, so for most people the first one in the list ends up as eth0; just like their bread lands butter-side-down
<Keybuk> but for some people, it just doesn't
<ficusplanet> Hey everyone.  With the Tango Project (http://tango-project.org/Tango_Desktop_Project) announced, I was wondering if Ubuntu will be supporting/using this icon theme?
<smurf> Keybuk: so the solution seems to be to rename the interfaces based on their MAC address, or something
<Keybuk> smurf: which we do
<mjg59> I sense that we're approaching the beginning of this conversation
<mdz> Kamion: kelly'd
<Keybuk> but the trouble is you end up trying to rename eth0 to eth1 and eth1 to eth0 at the same time
<Keybuk> and something goes ping and one of your network cards (which, sods law states, is usually the one you actually wanted) ends up flying across the room and sulking in the corner
* ogra <- dogwalk
<smurf> Keybuk: so think of entirely new names, and use these instead when you find a new card ..?
<Keybuk> smurf: so Ubuntu wouldn't use eth0, eth1, et. al. except for some cards, which it would
<Keybuk> this would be upsetting
<Keybuk> if I wanted to have to brute-force my network device names, I'd use FreeBSD
* Lathiat laughs
<smurf> Well, having cards randomly fly into a corner and sulk isn't entirely optimal either
<Keybuk> very true; what I'd like to be doing next week is configuring and activating cards based on their MAC address, or perhaps device path
<Keybuk> so we wouldn't need to _care_ what random kernel name got assigned to it
<smurf> Yeah, right now is probably the worst possible time to attempt stuff like that ;-)
<Keybuk> yes
<smurf> I'd use MAC addresses, BTW; device paths can change randomly too ...
<Keybuk> this isn't a regression on hoary, afaict ... hoary would fail to swap the network devices and ifup the wrong one
<Keybuk> ie. it'd configure your wired for dhcp instead of your wireless
<Keybuk> which is basically what breezy is doing
<Kamion> mdz: running a live filesystem build now so that I can see what's happening size-wise
<mdz> Kamion: thanks
<wasabi_> Does oem-config require X?
<wasabi_> Seems to.
<wasabi_> I'd be happy with my app for some ncurses debconf questions
<infinity> mdz : Can we get Tbird out of the queue and building, so I can babysit it and go to bed? :)
<HiddenWolf> Configuring postgresql.conf to use port 5432...
<HiddenWolf> Warning: The socket directory for owners other than 'postgres'
<HiddenWolf> defaults to /tmp. You might want to change the unix_socket_directory parameter
<HiddenWolf> in postgresql.conf to a more secure directory.
<HiddenWolf> w t f!
<HiddenWolf> It should run under it's own user.
<Kamion> wasabi_: yes, sorry, at the moment it does; that can probably be fixed later
<HiddenWolf> infinity, new TB build?
* psichron test
* psichron test
<wasabi_> Kamion, cool! Also, serial support. ;)
<wasabi_> And "first time SSH login"
<elvirolo> hi all
<elvirolo> breezy still suffers from very critical bugs ...
<elvirolo> like this one http://bugzilla.ubuntu.com/show_bug.cgi?id=14566 and this one http://bugzilla.ubuntu.com/show_bug.cgi?id=16066
<dhonn> damn hp
<HiddenWolf> elvirolo, there are sure to be more than a few of those.
<elvirolo> the spca5xx is absolutely critical ... it completely freezes my (and others') system, even the magic sys req keys don't work
<elvirolo> HiddenWolf, I imagine so yeah
<elvirolo> will they be fixed though ?
<HiddenWolf> elvirolo, sorry to say, but at this piont, I doubt it.
<HiddenWolf> elvirolo, best you can do is ask pitti or mdz
<elvirolo> sad :(
<dhonn> im sure eventually it will get fixed its probably not just ubuntu users that have this problem
<HiddenWolf> dhonn, most likely not.
<dhonn> hasnt hp been helping 
<elvirolo> my pinter did work under hoary though
<elvirolo> how annoying
<dhonn> remove hp printing services 
<dhonn> that might help
<dhonn> chmod -x /etc/init.d/hplip
<dhonn> it never was in hoary
<elvirolo> god of course i'm using windows right now
<elvirolo> i'll write this down
<elvirolo> thanks
<Belutz> can i make ubuntu fit enough into a 512mb flash drive?
<Belutz> or should I ask in #ubuntu?
<tseng> I dont think so
<tseng>  /usr on my server install is at 717 atm
<mdz> infinity: I had already approved it before you said anything
<dhonn> recompile the livecd without a few packages
<Belutz> hmmm i see
<dhonn> dump that to your flash drive
<Belutz> dhonn, any howto how to do that?
<infinity> mdz : Cool.  An enigmail rebuild to go with it just got tested locally and uploaded.
<infinity> And now I'm off ot bed.
<\sh> infinity: good night
<dhonn> just the knoppix documentation
<dhonn> get a gig flash drive
<dhonn> install grub boot loader
<ogra> Belutz, dhonn, there is plenty of docs in the wiki about remastering the live CD and this is rather appropriate for #ubuntu
<dhonn> there you go Belutz
<Belutz> ogra, dhonn, thanks :)
<Belutz> someone ask me how to do that for government project
<sivang> ogra: or #ubuntu-remastering :)
<dhonn> i learned how to make knoppix run directly from a ISO without the use of the live dvd, and just just grub
<dhonn> im sure it works the same way for a flash drive as it did for my hd
<dhonn> i wish the ubuntu live cd had the toram option again
<wasabi_> unionfs is pretty cool, except it doesnt' support moving files
<kbrooks> Hey all.
<kbrooks> I have a e-mail to send to -- shall I send it to ubuntu-users mailing list
<fabbione> evening
<kbrooks> anyone here subscribed to ubuntu-devel?
<kbrooks> Please read the post I just sent
<mirak> hhhelp
<kbrooks> mirak: no support here. #ubuntu
<mirak> kbrooks: I am there
<sivang> mirak: I'm with you on #ubuntu
<mirak> ok
<Keybuk> kbrooks: the plan for the next release is to use network-manager
<Keybuk> http://people.redhat.com/dcbw/NetworkManager/
<kbrooks> Keybuk: what is that
<Keybuk> it handles which network card in your system is active, and which wireless network you connect to
<Keybuk> just about everything else in your mail is already handled by udev
<Keybuk> I chatted to the ndiswrapper developers the other week about getting proper support for it
<mirak> hem what fs is used for the initrd ?
<kbrooks> mirak: cramfs i think
<Keybuk> mirak: breezy doesn't use initrd
<kbrooks> not sure
<Keybuk> we use initramfs, which is a compressed cpio file
<Keybuk> rather than a filesystem
<kbrooks> Keybuk: i see
<mirak> Keybuk: what does it use then ?
<kbrooks> mirak: he said so altrady
<siretart> Keybuk: will it be possible to configure NetworkManager without X? Current implementation seems to lack this :(
<mirak> ok but the concept of an external file with module is the same 
<mirak> ?
<Keybuk> siretart: I should think so
<Keybuk> mirak: I don't understand your question
<mirak> Keybuk: what don't you understand ?
<Keybuk> what you're asking
<mirak> I need to see what is in the file along the kernel
<Keybuk> right
<mirak> don't know how to call it since it's not an inirt
<mirak> rd
<mirak> initrd
<Keybuk> "call it" ?
<mirak> name it
<Keybuk> do you mean how to see what's inside it?
<mirak> you said it's not an initrd so it might be nammed someting else isn't it ?
<Keybuk> no, named the same thing
<mirak> ok
<mirak> so how to see what is in it ?
<Keybuk> gunzip -c initrd... | cpio -t
<mirak> Keybuk: thank you
<siretart> Keybuk: btw, is the installers initrd an real initrd or an cpio archive, too?
<Kamion> siretart: it's a real initrd for now
<siretart> okay
<mirak> lib/modules/2.6.12-9-powerpc/kernel/drivers/ide/pci/cmd64x.ko
<Kamion> it'll switch to initramfs eventually, probably
<mirak> so this module is inside but it's not loaded at boot time
<kbrooks> Kamion: why is it a real initrd
<kbrooks> ?
<Kamion> kbrooks: no compelling reason to change
<kbrooks> Kamion: what would be?
<mirak> how can I be sure the initrd is correctly loaded ?
<Kamion> why do you care? :)
<Keybuk> mirak: do you see the graphical splash?
<fabbione> mirak: if it's not loaded, your machine won't boot
<Kamion> the reason the main system moved from initrd-tools to initramfs-tools was that we needed to get away from devfs and initramfs-tools was easier to handle
<mirak> fabbione: thanks for your intervention LOL
<Kamion> the other reasons for moving to initramfs are more nebulous, at least as far as the installer is concerned
<Kamion> anyway, got to go
<mirak> fabbione: it doesn't boot
<Keybuk> Kamion: ah, marriage
<kbrooks> nebulous?
<Keybuk> mirak: are you using a stock ubuntu kernel?
<kbrooks> define?
<mirak> Keybuk: I don't see the graphical splash
<Kamion> Keybuk: no, hitting things
<mirak> Keybuk: I use the ubuntu ppc image
<Kamion> (i.e. karate)
<fabbione> Kamion: have fun :)
<dholbach> i'm out for a walk, bbl
<mirak> Keybuk: vmlinux-2.6.12-9-powerpc
<\sh> yeah baby yeah....one romanian leaded company will switch from suse to ubuntu....tomorrow i know more :)
<kbrooks> \sh: so.
<kbrooks> you're famous eh
<Keybuk> mirak: in what way doesn't it boot?  how far does it get?  if you remove "quiet splash" from the kernel command-line, what do you see?
<mirak> Keybuk: ubuntu ppc uses yaboot
<\sh> kbrooks: no...I just evangelise all my colleagues to use ubuntu...and they like it...and just now I had a phone call of one romanian guy who is administrating some servers for a romanian company...he will switch them all to ubuntu
<mirak> Keybuk: I can't tell if there is a splash at all, because my last working kernel is 2.6.10-5
<mirak> and the yaboot config file is not automatically updated
<kbrooks> \sh: no, i'm talking about you being op in a channel...
<mirak> Keybuk: can I flood 8 lines in this channel ?
<mirak> my yaboot.conf file
<\sh> kbrooks: ???? i don't understand
<mirak> hum kernel entry
<Keybuk> I don't know yaboot, sorry
<fabbione> mirak: no flood in here
<Keybuk> you may have more luck in #ubuntu
<mirak> there is no ppc support
<mirak> that's horrible
<mirak> Keybuk: maybe yaboot doesn't support this cpio file format
<mirak> this would be my bet
<Keybuk> this isn't a support channel
<fabbione> Keybuk: did you ever build a deb in your life? because i did build hundreds of them...
<mirak> I get no help in the other channel
<\sh> kbrooks: I was never an op in one channel
<mirak> fabbione: yes I did
<mirak> however I just need to know what is different
<mirak> and why it doesn't work
<fabbione> mirak: ?
<kbrooks> \sh: never mind, not you
<fabbione> mirak: i did say something to Keybuk ...
<fabbione> not to you
<mirak> if the automated deb file creates a initrd with cpio it's maybe not gona work
<mirak> fabbione: yes I didn't seen it
<mirak> I can ask in the other place, but there is no answer
<mirak> people that knows this kind of thing are only lurking here it seems
<mirak> nobody knows that in the #ubuntu channel
<mirak> if I ask here it's because here people knows. I wouldn't bother you otherwise
<Keybuk> this still isn't a support channel; this channel is for discussing development
<mirak> I got an answer
<mirak> I might want to look on #ubuntu then :D
<speel> hey did you guys fix the spca5xx issues? ( just curious )
<fabbione> speel: bug number?
<speel> hang on let me get it 
<rob^^^> is Wed still looking good for 5.10?
<speel> #14566
<fabbione> rob^^^: any reasons why it shouldn't be?
<rob^^^> no, just wanted to know whether to clear my calendar ;)
<elmo> umm, Thursday, not Wednesday
<fabbione> release is the 13.. 
<fabbione> elmo: exactly :)
<rob^^^> ok, I'm mixed up then
<fabbione> speel: -> dapper.
<fabbione> speel: it won't be fixed for breezy
<speel> ah ok
<speel> How come?
<fabbione> speel: because it's a minor issue and breezy will release in 3 days
<fabbione> the kernel is frozen and only security updates will go in
<speel> oo ok. heh sorry I dont know how development works and etc :P
<fabbione> speel: nothing to be sorry about.. next time we will hunt you down and burn you alive :P
<speel> Lol
<Keybuk> hey, don't forget the flaying
<fabbione> eheh
<kbrooks> fabbione: not "the kernel"
<kbrooks> ubuntu
<fabbione> kbrooks: sorry?
<kbrooks> Ubuntu is frozen
<kbrooks> for release
<chip> elmo: You live!
<slomo> mdz: why did you assign #17359 to me? ;) but i'll take a look at it... seems to be a non-bug
<mdz> slomo: weren't you working on things mono-related?  perhaps I confused you with someone else
<fabbione> hey mdz
<mdz> fabbione: sshh, I am not here
<fabbione> kbrooks: we are still allowed to do RC bug fixes
<chip> elmo: What say you update my key?
<slomo> mdz: no that was me... np :) i'll find someone to sponsor a fix for that for main... if this is really a bug ;)
<kbrooks> fabbione: i mean after release
<fabbione> mdz: i didn't see you.. don't worry
<fabbione> mdz: hide! hide!
<fabbione> kbrooks: oh.. really?
<elmo> chip: what does this have to do with Ubuntu development?
<fabbione> kbrooks: but can we get the latest firefox in?
<kbrooks> fabbione: i'm saying ubuntu will be frozen -- no new apps only sec updates
<kbrooks> on october 13th
<chip> elmo: I'll be happy to discuss it in #debian-devel if you will respond there
<kbrooks> breezy release
<fabbione> kbrooks: ah.. i must have missed that
<elmo> chip: I'm not in #debian-devel, so how exactly do you expect me to respond?
<kbrooks> i have 1.0.7
<chip> elmo: /join, I suppose
<elmo> chip: so, please take off-topic talk out of this channel
<elmo> chip: no
<fabbione> kbrooks: so what will happen with 1.0.8??
<kbrooks> fabbione: i'm not a ubuntu developer
<kbrooks> i was just corecting you
<kbrooks> thats all
<fabbione> kbrooks: hmmm.. ok.. i guess i will need to read up on that.. afterall i was only the Xfree86/Xorg and kernel maintainer for Ubuntu
<fabbione> i guess i got too old for that :)
<Keybuk> right, am gonna crash and get an early night
<fabbione> night Keybuk 
<Keybuk> elmo stole my timezone, so now I'm taking it back, or something
<fabbione> Keybuk: lol
<\sh> Keybuk: btw...can we talk at ubz about planet and s9y problems? ,-)
<Keybuk> no, because I don't maintain Planet
<Keybuk> you can talk to jdub though :p
<\sh> Keybuk: software side...not administrating ;)
<Keybuk> that's what I mean
<\sh> actually...I would like to fix the issues in planet ;)
<Keybuk> go for it :p
<\sh> Keybuk: bah ;) solution: install s9y with planet plugin ;)
<\sh> hmmm...if i didn't fix universe until 22:00 UTC .. i'm lame
<fabbione> \sh: you have less than 60 secs..
<\sh> fabbione: that's 22:00 uhr ;) german time...
<fabbione> it's still 21:59
<fabbione> you have a few secs left
<\sh> fabbione: it's still 19:59 UTC ;)
<fabbione> oh right.. UTC
<\sh> HAR HAR
<fabbione> dong
<fabbione> ahaha
<\sh> I'll fix it ;)
<fabbione> you got me :)
<\sh> fabbione: ;)
<moyogo> is there any reason why we have freetype6-2.1.7 when 2.1.10 is out since june?
<moyogo> 2.1.7 is from 2004-02
<kent> moyogo, 2004 was perhaps a very good year?
<moyogo> hehe
<dieman> of course! i try seeing how fast i can download from a gigE machine from ftp.heanet.ie and sure!
<Mithrandir> elmo (and maswan): any thoughts on pointing no.archive.ubuntu.com to ftp.acc.umu.se instead of level3?  The latter is often faster.
<dieman> it dies!
<dieman> (playing with mirroring)
<dieman> ftp.heanet.ie should be the default for .edu network users though, holy crap is it fast.
<dieman> from the usa even
<rob^^^> dieman: "how fast is it ;)"
<dieman> heh
<dieman> i was doing 100mbps to the mirror ive got
<dieman> but another box i was testing with was 200mbps+
<rob^^^> dieman: I'm bottlenecked by my 10/100 switch to my campus mirror
<dieman> heh
<rob^^^> ooh
<rob^^^> idea ;)
<dieman> ive got a mirror up here at cs.umn.edu too
<dieman> but its only 100mbps
<dieman> i need to get my hands on a gigE card for it perhaps though
<dieman> yeah
<dieman> got it up to 445mbps for 3 tcp streams
<\sh> g'evening _mvo_ 
<rob^^^> boo, only 5.5 megs a second on VirtualPC :(
<\sh> buh...mvo@ping.de and _mvo_@ish.de both are well known provider *grin*
<rob^^^> ooh up to 7.5 now;)
<fabbione> \sh: dude.. you blog too much
<\sh> fabbione: it's planet 
<\sh> fabbione: there is a bug
<_mvo_> hey \sh!
<fabbione> ah ok
<\sh> fabbione: and I want to fix it with keybuk...but he refused ... brrr
<haggai> what's the best tool to import CVS into a new baz archive?
<_mvo_> \sh: my ish was down for a couple of minutes, but it's back apparently
<fabbione> haggai: probably tailor
* haggai waves to _mvo_
<\sh> _mvo_: well..that's ish ;)
<haggai> fabbione: thanks, I started looking at that and was wondering if it is any good. Have you used it?
<_mvo_> \sh: actually I'm pretty happy with it
* _mvo_ waves back to haggai 
<fabbione> haggai: approx the time to apt-get install it, see it failing on svn and purge it
<haggai> fabbione: uhh :)
<fabbione> haggai: get the latest from upstream if you want to play
<janimo> fabbione, do you know if xdm worked when you uploaded it last time?
<fabbione> the package is old and buggy
<fabbione> janimo: yes it did
<haggai> hmmkay
* _mvo_ is having dinner noch 
<janimo> fabbione, it does not start here and I recall someone saying the same thing last week
<\sh> bah
<\sh> _mvo_: ish is ok ..
<janimo> I found some things needed changing in order for it to start
<fabbione> janimo: it's universe :)
<janimo> it looked for config file in /usr/lib/X11 instead of /etc
<janimo> and tried to load a greeter .so which was not built
<janimo> so can I upload my change then?
<fabbione> janimo: sure.. i am not jalous of my pkgs
<\sh> janimo: what is it?
<fabbione> not the one in universe at least
<janimo> fabbione, ok I was just trying to make sure it is not broken beyond hope and I waste time on it
<janimo> \sh xdm
<janimo> or you mean the .so?
<janimo> Some libGreeter.so
<janimo> I got it to start eventually 
<\sh> janimo: hmmmm....
<\sh> janimo: I think ogra was working on it..and something is really broken
<janimo> \sh what is it working for you?
<\sh> janimo: I'm using gdm or kdm
<janimo> \sh well it seems to work now
<\sh> hu_
<janimo> well those are out for xubuntu
<\sh> ?
<ogra> \sh, i had a look at it and had no clue whats broken was what i said ;)
<\sh> ogra: ok...but it was somehow broken
<ogra> i think it still is
<\sh> well..1:11 still left until I fixed the universe *lol*
<zyga> hello overworked good people
<\sh> hey zyga 
<zyga> hello, how is ubuntu doing today?
<zyga> new kernel package
<dholbach> re
<dieman> heh
<dieman> fix my cd images ehre, and start doing 40-50mbps out
<pvanhoof> dudes. by the time I can upgrade my breezy, you have have 106 new packages. You guys are working to hard
<maswan> dieman: heh, yeah, ftp.heanet.ie is fast. :)
<dieman> they have a *scsi cache*
<dieman> raid-0
<dieman> because the 12tb or raid is 'too slow'
<dieman> of, rather
* Kamion sighs and unbreaks his live-CD-building trigger script
<maswan> dieman: :)
<Kamion> silly ssh's connection sharing support is a bit racy ...
<dieman> i liked the graphs in their apachecon presentation (i think thats the right one)
<maswan> dieman: I'm syncing up some test data for the offload host
<dieman> showing that 4gb -> 12gb with PAE is worthless.
<dieman> but 32GB works great!
<maswan> hehe
<dieman> hrm, their last ubuntu sync took 2hrs
<dieman> im going to probally have to resync my ubuntu here and push back the interval
<maswan> .pool/ubuntu-5.04-install-powerpc.iso
<maswan>    654131200 100%   19.54MB/s    0:00:31  (10, 5.4% of 479)
<maswan> :)
<dieman> yeah
<dieman> i did 445 to a gigE connected machine
<dieman> (mbps)
<dieman> i was impressed
<maswan> ftp.sunet.se has bigger hardware though. I wonder what kind of rates I'd get from them
<dieman> heh
<dieman> only 2 of the mirrors on their box take 2 hours (that they report)
<dieman> gentoo-portage
<dieman> and ubuntu
<maswan> hmm.. only about the same rates though
<dieman> yay, nearly through universe
<maswan> http://ftp.sunet.se/about.html
<notmdz> seb128: which package is responsible for the "Failed to find mountpoint for device <foo> in /etc/fstab" error that I get from totem?
<dieman> we generally can't get funding like that for mirrors
<dieman> since we dont have this whole 'transit is expensive' problem much.
<maswan> yeah, those are exceptions
<dieman> and never really did
<maswan> a few NRENs do
<notmdz> oh, it's totem itself
<seb128> notmdz: I would say totem, we have upstream and downstream bugs about it
<notmdz> odd that it doesn't even open /etc/fstab before giving that error
<notmdz> which is why I assumed it came from another place
<maswan> dieman: in the sunet case it is considered a strategic project, to provide a good general and "close" mirror for the swedish academia and the genreal public
<dieman> yeah
<maswan> dieman: also, back in the days, it helped to even out the balance on the transit links.
<dieman> heh
<dieman> most spots in the US never really had that sort of pressing issue
<notmdz> hmm, it's doing a gnomevfs call
<maswan> yeah, back in the 90:ies the transatlantic link situation wasn't as good as it is today
<seb128> notmdz: it uses gnomevfs yep, the message has not been updated since gnomevfs has switched to hal
<seb128> notmdz: the code is totem-1.2.0/src/plparse/totem-disc.c: cd_cache_get_dev_from_* if you want to debug it
<notmdz> seb128: I get that error if g-v-m is not running
<seb128> hum
<seb128> lemme try
<notmdz> I was trying to use totem on a system which doesn't run GNOME
<notmdz> starting g-v-m got me past that error, but now it segfaults when I try to play the DVD ;-)
<seb128> notmdz: right, same here. I've to mount the DVD before using totem
<seb128> grumpf
<seb128> does somebody knows about a "running dhclient breaks the loopback" bug?
<notmdz> seb128: yes
<notmdz> seb128: http://bugzilla.ubuntu.com/show_bug.cgi?id=10174
<seb128> which is great because GNOME waits on some timeout when you try to log out or log in
<seb128> thanks
<notmdz> dhclient should probably just abort if you don't tell it which interface to use
<seb128> yeah
<\sh> I'm off, elmo: you have mail :) and the rest: have a nice night, morning, afternoon, whereever you are, whatever you do...
<notmdz> seb128: would a backtrace for this crash be at all interesting?  seems to be gst-ffmpeg related
<seb128> notmdz: if the backtrace is correct yep
<dholbach> slomo will be delighted to hear :)
<seb128> notmdz: I've uploaded gst-plugins0.8_0.8.11-0ubuntu5. I've fixed a Depends on ${misc:Depends} not listed (and useful for dh_gconf) and dropped the autosinks which are bugged (crash totem by example), upstream recommand not shipping them before 0.9/0.10
<seb128> notmdz: should I mail you about it?
<notmdz> seb128: approved
<seb128> thanks
<slomo> dholbach: what gst-ffmpeg crash?
<seb128> slomo: notmdz's one :)
<notmdz> building it with debug now
<slomo> ok, i can take a look at it... i've worked with gdb for hours today so some more wouldn't hurt ;) how can it be reproduced?
<notmdz> slomo: happens when I try to play a DVD in totem
<notmdz> hmm, I built with nostrip and it's still stripped
<Kamion> notmdz: http://people.ubuntu.com/~cjwatson/germinate-output/ubuntu-server-breezy/, FYI
<Kamion> notmdz: (ubuntu-devel@lists.ubuntu.com/seeds--breezy-server--0)
<Kamion> notmdz: it looks like it should come out smaller than our normal images, so at least that's one place where we won't be under space pressure for now
<notmdz> Kamion: I should hope it does
<Kamion> well, one never knows
<Kamion> it's not a lot smaller, only 15-20MB or so
<notmdz> slomo: I have a trace for you
<notmdz> not sure how valid it is, but it's something
<slomo> notmdz: and my dvd drive is busy for the next 12 hours... i'm currently testing thoggen and theora encoding is so damn slow :(
<notmdz> slomo: what's your email address?
<slomo> notmdz: slomo@ubuntu.com
<slomo> notmdz: hey, you assigned a bug to this address a few hours ago ;)
#ubuntu-devel 2005-10-16
<notmdz> slomo: bugzilla knew it ;-)
<slomo> notmdz: oh ok... but anyway, dvd playback works fine here with totem :/ what kind of dvd is it?
<notmdz> slomo: TRUMAN_SHOW_SCE
<notmdz> I'll try a different disc
<seb128> one of the usual upstream reply is "send me a DVD with the issue and I debug it" :)
<tseng> and then review it on his blog
<seb128> he he
<seb128> I was thinking to BBB, but right hadess does that too :p
<tseng> yes :P
<slomo> notmdz: weird audio? i had some problems because of that in the past... was mostly with dts sound iirc
<tseng> are you talking about xine/libdvdcss2 or gst?
<notmdz> same crash with the Go Open DVD
<slomo> notmdz: crash in what way? freeze? segfault?
<slomo> tseng: gst
<notmdz> slomo: crash as in restart/inform developers
<notmdz> presumably a segfault or similar
<seb128> any assertion if running from the command line?
<slomo> that backtrace doesn't look useful... hmm... i'll try all my dvds tomorrow if i can reproduce it...
<slomo> notmdz: btw, what kind of cpu does your machine have? i suspect that there will be problems with gst-ffmpeg on non-mmx x86... and on non-altivec powerpc
<notmdz> slomo: k7
<notmdz> totem-xine plays it fine
<HWolf> where is the breezy-changes archive located?
<notmdz> HWolf: lists.ubuntu.com
<HWolf> notmdz, i figured that much, but I can't find the link going from there.
<Kamion> HWolf: second link under "List"
<Kamion> then first link on the page
<HWolf> Kamion, omg, I overlooked it. :$
<HWolf> wee, I found the changelog again.
<mirak> hi
<mirak> I fixed the initrd ppc problem for macintosh
<mirak> if there is anyone in charge of that here ...
<slomo> mirak: which one?
<mirak> a problem with mounting the rootfs
<slomo> mirak: #14485?
<mirak> a link ?
<slomo> http://bugzilla.ubuntu.com/show_bug.cgi?id=14485
<mirak> slomo: do you have a full link ?
<backports-r-us> Security team, #17410, typo in Mozilla package
<mirak> ok
<foxiness> can i tell here a about a bug on breezy ?
<backports-r-us> 0ubuntu05.04 > 0ubuntu1, upgrade to Breezy will fail
<mirak> slomo: yes ! that's the same issue
<foxiness> there are a bug on arabic script on breezy show the txet like this "   " not like this "" 
<mirak> slomo: I built a initrd with the old method with mkinitrd and it works
<slomo> mirak: also with xfs as root fs? how did you fix it? ;)
<mirak> slomo: yes I have xfs as rootfs
<foxiness> the arabic font must be join
<slomo> mirak: yes that is a known workaround ;) i use it the same way currently...
<slomo> mirak: :(
<mirak> slomo: I didn't really fixed it, but use the mkinitrd with a cramfs file instead of mkinitramfs
<mirak> slomo: for me the reason is that the ide module cmd64x must be forced to load
<Kamion> that's definitely not the reason on this hardware
<mirak> if you look into the cramfs file, you will see a file loadmodules and you will se there is a bunch of modules forced to load
<slomo> mirak: cmd64x is compiled into the kernel for ppc afaik... not as a module
<Kamion> we won't be going back to initrd-tools for powerpc
<mirak> slomo: no it's not
<mirak> Kamion: then you must find a way to explicitely force the load of some modules
<mirak> because they are not automatically loaded
<mirak> exept if there are built into the kernel
<slomo> mirak: oh it was another ide driver which was there... the pmac ide driver... my fault
<mirak> the G3 b&w have two ide drivers in fact
<Kamion> mirak: on my system, the hang was before the initramfs even started, and it only happened with XFS, not with other filesystems
<Kamion> mirak: so with respect I don't think that's the problem
<Kamion> if you're using initrd-tools, you're using a completely different code path, and workarounds applicable there are not generally applicable to initramfs-tools
<mirak> dmesg says me the ramfs is loaded
<mirak> I am aware of that
<mirak> anyway a solution must be found
<Kamion> yes, it is a major bug
<mirak> I already had this problem on debianppc
<Kamion> but "must be found" unfortunately does not really help; nobody seems to know what the real problem is
<mirak> the problem was about ide drives name swapping
<Kamion> Debian is not using initramfs-tools, so you did not encounter this problem there
<Kamion> you encountered some different problem with similar symptoms
<mirak> device swap I said
<Kamion> I'm familiar with the problem you're describing, but it is not the same as bug #14485
<mirak> what do you mean ?
<mirak> well anyway I had the exact same problem as described in this bug
<Kamion> it is not the same bug, even though it has the same symptoms
<mirak> I am not sure what you are talking about now
<mirak> ^^
<Kamion> you can get that message for all kinds of reasons
<Kamion> the problem currently encountered by Ubuntu powerpc users using XFS as / is a different one from previous reasons you may have encountered
<mirak> ok
<Kamion> we know this because it works fine on the same hardware using a different filesystem
<backports-r-us> oh yeah, add Warty to the list of hell thanks to USN-186-1
<mirak> ok
<Kamion> as a workaround, use some different filesystem for /, or just for /boot if you like
<Kamion> that should be sufficient
<mirak> I was planing to drop xfs 
<mirak> and use reiser
<Kamion> I don't believe reiserfs currently suffers from that bug
<mirak> if I use xfs it's because debian was only proposing a xfs install as an alternative to reiserfs some years ago
<mirak> I then switched to ubuntu
<backports-r-us> mirak: I've ran into lots of random corruption with XFS
<mirak> I never had a problem with xfs
<backports-r-us> mirak: it can't survive a hard reboot if my life depended on it
<mirak> I had VERY BIG problem with hfsplus read/write
<backports-r-us> but that's just me :)
<mirak> lol
<backports-r-us> I'm personally a JFS fan now
<backports-r-us> former reiserfs fan
<Kamion> I certainly wouldn't want to rely on being able to write to HFS+ from Linux
<Kamion> anyway, bedtime
<mirak> I use ext3 for my home because there is windows drivers for it
<Kamion> notmdz: I've cronned the ubuntu-server build for 10:29 London time daily
<Kamion> looks fine, apart from some redundant and confusing preseed files and boot options
<mirak> but I think I will use a real fs and use colinux plus samba to read write on linux fs from windows
<mirak> Kamion: what have the FS to do with not beeing able to mount root ?
<backports-r-us> mirak: probably the initramfs scripts
<backports-r-us> mirak: and I've had a struggle getting Grub to cooperate with XFS roots
<mirak> I mean in my case, I should at least see the cmd64x driver be loaded since it's supposed to be in the initrd
<mirak> backports-r-us: i managed to use grub and LVM2 so anything seems possible for me now :D
<backports-r-us> lol
* backports-r-us shifts #17410's blame over to security team :)
* backports-r-us thus completes his first assigned bug :)
<dholbach> good night, folks, i'm off
<sistpoty> gn8 dholbach
<dholbach> bye stefan :)
<mirak> I am happy I have finnaly found the correspoding bug to my problem
<mirak> in fact slomo did :p
<mirak> I am not alone on eaarth !
<mirak> youpi
<mirak> :D
<mirak> ok bye
<azeem> w72
<foxiness> the driver 'smart link' no longer work on breezy
<speel> hey did you guys happen to remove the terminal from applications>system tools in gnome
<elmo> speel: it's in applications->accessories
<speel> ah Lol ok =x
<Riddell> I always expect accessories to be full of cheap girly jewlery, but I'm just mistaking it for clair's accessories
<speel> same here 
<fabbione> elmo: dude. thanks for the chroots :)
<opi> Riddell, btw: where's 3.5 link gone on kubuntu.org? Are you uploaded it into main?
<opi> (and, btw, Hi:-)
<HWolf> gees, seems sh had some time on his hands.
* HWolf awed by breezy-changes
<Riddell> opi: not uploaded, under announcements
<opi> Riddell, superb
* infinity is impressed that in that flurry of uploads last night, only 2 were FTBFS...
<tseng> infinity: i did not upload
<tseng> infinity: probably part of it
<infinity> :)
<bddebian> tseng: Nah, it's lack of my uploads.. ;-)
<infinity> notmdz : Ouch, nice catch on the volatile mount mode.
<bddebian> How do I stop this build from dumping out on warnings?  I've added -Werror.. What else can I try??
<infinity> Uhm, dude.
<infinity> -Werror is WHY it's doing that.
<ajmitch> I hope that was s/added/removed/ ?
<infinity>        -Werror
<infinity>            Make all warnings into errors.
<bddebian> SOrry, yes removed
<infinity> Do you have any other -Werror-foo-bar stuff?
<bddebian> No, it's just -g -O2
<infinity> Then maybe it's dying on errors? :)
<bddebian> Oh and I had to add -fno-strict-aliasing
<infinity> (note that it will finish processing the current file, so you could be seeing "error, warning, warning, warning", and missing the error in the haystack of warnings.
<bddebian> But most of these are stupid errors.  Extra () and bs like that
<bddebian> function foo is not referenced.  Bar is not modified, could be declared constant, etc etc :-(
<notmdz> infinity: yeah, that could have been embarrassing ;-)
<infinity> notmdz : A wee bit, yes. :)
<infinity> In other good news, you got all the minors incremented on the first upload, too.
<infinity> (Care to file a big, blinking "as soon as dapper opens" bug for me to fix that mess?)
<infinity> Oh, hah.  I lied.
<infinity> Just got my first REJECT mail from katie. :)
* infinity goes to fix.
<notmdz> infinity: #@$@#
<notmdz> I hereby propose a policy amendment: packages must not arbitrarily build incorrectly when you do OBVIOUS AND REASONABLE THINGS to them
* infinity points at debian-policy.
<bddebian> Amen to that policy
<infinity> I'm sure Manoj will accept it without debate.
<infinity> mdz : Uploaded.
<mdz> infinity: installed
* infinity watches a bunch of manual m68k uploads bounce off upload.ubuntu.com and blushes.
<segfault> ogra: just uploaded a new xscreensaver po. should appear soon.
<pitti> Good morning
<ajmitch> morning pitti 
<pitti> Hi ajmitch 
<jsgotangco> morning pitti
<infinity> Hey pitti.
<CaiN_SA> morning
<fabbione> morning
<infinity> Aww, crap.  I just realised that getting atheros to work in d-i would probably require almost zero effort.
* fabbione scratches his head on 17275
<infinity> fabbione : Ugh, I have that bug open elsewhere too.
<fabbione> you do?
<infinity> fabbione : I meant to look into whether or not festival can take a list of allowed hosts, and fix it.
<fabbione> ok.. than you win ;(
<fabbione> )
<fabbione> i have no idea how festival works
<infinity> (The problem is that it's doing a reverse lookup of 127.0.0.1, which reutned "localhost.localdomain", which doesn't match "localhost", and all hell breaks loose.
<fabbione> no actually.. i don't even know what it is
<fabbione> ahhhhh
<fabbione> crap
<infinity> I have no idea how it works either, that's why it's been low on the priority list.
<infinity> Also, WTF is "reutned"?
<infinity> I need new fingers.
<pitti> bah, why is suspend to disk so utterly broken again? two weeks ago it was working perfectly...
<infinity> pitti : Erm.  Is it?.. I should test after this kernel upgrade.
<fabbione> infinity:  it won't make any difference
<infinity> Suspend to disk and RAM were both working for me a week or two ago...
<fabbione> the last kernel was only security
<fabbione> i just figured that i don't have the power to sleep only 4 hours at night
* fabbione feels totally trashed
<fabbione> i guess i need more coffee
<pitti> infinity: at suspend I had to manually create swap partitions because they were not present before; then it suspended fine, but it just ignored the image on the swap, booted normally, and left me without swap again
<pitti> fabbione: you need more sleep :-/
<fabbione> not only
<fabbione> jeee guys stop uploading non bug fixes
<fabbione> when a mirror rsync takes more than 30 minutes it ends up being broken ok?
<fabbione> and i am not on a slow pipe
<infinity> Yeah, I had to re-run my mirror update three times to get it back in sync.
<fabbione> infinity: that's the reason why i was awake till 3am
<infinity> Okay, if I'm reading the docs okay, this should do what I want.
<infinity> -(defvar server_access_list '(localhost)
<infinity> +(defvar server_access_list '("127.0.0.1" "localhost\.localdomain" "localhost")
* infinity tests this theory before he uploads.
<fabbione> i suggest for dapper we must not have sources bigger than 1MB and that produces binary for more than 1MB
<fabbione> (aggregate sum of all bins)
<pitti> fabbione: hah, happy kernel splitting
<pitti> fabbione: what about giving every driver its own source package? :-)
<fabbione> pitti: that would be doable per subsystem/class easily
<fabbione> it's much easier than you think :P
<\sh> *cough* please, dear immunesystem, don't let me get a cold...I don't need it, I don't want it
* jsgotangco is testing up the oem mode
<infinity> I WIN!
* infinity uploads.
<infinity> Also, screenreaders are creepy.
* infinity uninstalls.
<pitti> fabbione: oh, I would actually appreciate to not download bazillions of bytes for just a driver update :-)
<fabbione> Dear Release Managers, please stop new packages in main. thanks
* pitti throws USN-200 at the world
<fabbione> congratulation pitti
<fabbione> the kernel one was good too
<infinity> Dear Release Manager, please stop new packages in main, after you accept festival.
<fabbione> It D1D d51v3 s0rt 0f 1ns4n3
<infinity> That bug's been on my list ever since I was hired, I think.
<fabbione> infinity: than close mine too.. please
<infinity> Hooray for bumped priorities.
<infinity> fabbione : I'll close both when the upload is approved and built/uploaded.
<fabbione> infinity: thanks dude
<jsgotangco> err do you guys know any "known issues" that needs to be listed in the release notes?
* jsgotangco is cleaning up the doc atm
<infinity> jsgotangco : Yes.
<fabbione> jsgotangco: yes..
<fabbione> jsgotangco: mention the users NOT to try to talk with the kernel/security guys
<jsgotangco> please add them to BreezyReleaesNotes
<fabbione> WE ARE GETTING INSANE!
<jsgotangco> LOL
<fabbione> MUHA MUHA MUHA
<fabbione> pitti: dude we need more crack :)
<fabbione> pitti: good one this time
* pitti is scared of fabbione getting mad
* fabbione sniffs the leftovers from yesterday
<pitti> fabbione: DUDE - you talked about "coffee"...
<fabbione> pitti: no why??? 3 kernel uploads in a single day are cool :)
<fabbione> isn't coffee the white powder you left on my desk?
<pitti> fabbione: maybe, I don't drink coffee, so I couldn't tell anyway 
<fabbione> pitti: eheh
<fabbione> anyway.. let's keep the schizo aside..
<fabbione> pitti: did you get all the CAN sorted out?
<fabbione> or should we recheck together?
<pitti> fabbione: for the kernel?
<pitti> fabbione: I didn't yet ask for new ones, but I have tracked current ones well
<fabbione> pitti: ok, the new ones can wait..
<fabbione> we will add them at the first USN
<CaiN_SA> ok right i need some info
<CaiN_SA> best way to build a deb file ?
<CaiN_SA> or must i go ask in other channel ?
<\sh> CaiN_SA: #ubuntu-motu ?
<\sh> CaiN_SA: but better to read the "new debian maintainer guide" first :)
<Mirv> should I report in bugzilla that the yesterday's language-pack update didn't bring any of the new translations since 20050930 in? serpentine, language selector, disk management, other changes were done to fi...
<CaiN_SA> sh url ?
<\sh> CaiN_SA: it's all written on http://wiki.ubuntu.com/DeveloperResources
<CaiN_SA> thx
<\sh> u're welcome
<CaiN_SA> cos sh all the things ive seen
<CaiN_SA> and used to build .debs
<CaiN_SA> doesnt work
<\sh> CaiN_SA: then join #ubuntu-motu and we will help u to satisfy your need...and let the hard-ubuntu-core devs do their work :)
<\sh> here I mean, without being disturbed 
<CaiN_SA> :/
<CaiN_SA> well i have to get info somewhere
<CaiN_SA> cos #ubuntu is no help
<CaiN_SA> and i have to release same day as ubuntu
<fabbione> Mirv: yes please do so
<CaiN_SA> so thx
<fabbione> infinity: how do i undep-wait with wb?
<fabbione> it seems one depwait wasn't cleared properly on sparc
<fabbione> ah no 
<fabbione> never mind
<fabbione> it's ok
<infinity> If it's a dep-wait on a real package, cron.daily will do it for you.
<infinity> If not, you want "--pretend-avail package_version"
<infinity> And if the dep-wait is so broken that pretend-avail doesn't work (which can happen if someone types it in manually and fucks up the dpkg-like syntax), then you want to --forget the package (and cron.daily will bring it back in needs-build with no history on the next run)
<fabbione> yup thanks
<fabbione> i misread -i output
<mvo> good morning
<ajmitch> morning mvo!
<jsgotangco> morning
<lifeless> is there an equivalent to debian-keyring for ubuntu ?
<mvo> lifeless: we have the ubuntu-keyring, but it only contains the archive keys right now
<lifeless> I know
<lifeless> we're doing a key-trust analysis in launchpad, would like the ubuntu devs and possible motus 
<pitti> Hi mvo
<lifeless> in a keyring.
* mvo waves to pitti, ajmitch, jsgotangco 
<infinity> lifeless : Ask elmo to export the ftp-master keyring for you.
<Treenaks> you could screen-scrape the launchpad user pages ;)
* Treenaks prepares to be axe-murdered by the launchpad team
<mbreit> infinity: can i /query you about a buildd problem (at least it seems like a buildd problem ;))
<infinity> How problematic is it?
<mbreit> two packages (ardour and cheesetracker) don't get build and they are uninstallable at the moment
<mbreit> so that should really get fixed before release
<lifeless> elmo: please export the ftp-master keying for stub
<infinity> keyring(s)
<infinity> Should be one for main and one for universe.
<lifeless> elmo: please channel infinity
<sabdfl> pitti: did you see the mail from tino jyrinki?
<pitti> sabdfl: I can't remember the name; what topic was that about?
<sabdfl> Re: Translations (some/all?) weren't updated in 20051010?
<infinity> Oh, hurray for the irritating "all your chrome is buggered until you restart all your firefox instances" bug.
* infinity sighs.
<siretart> lifeless: I can offer you the revu keyring, and the keyring of universe uploaders elmo passed me when revu started
<siretart> if you need something quick
<lifeless> siretart: we'll demo with the debian keyring, and do a final run when elmo arises
<pitti> sabdfl: I did not get that mail; I wanted to update translations yesterday, but the current langpack was broken again; I contacted carlos
<sabdfl> that's what he's saying
<sabdfl> no new translations
<pitti> sabdfl: if it is still broken today, I have to manually sort out the broken files
<infinity> mbreit : ardour quite obviously appears to fail to build, I don't see how that qualifies as a "buildd problem".
<pitti> sabdfl: but I didn't talk to carlos yet, he's not yet online
<pitti> sabdfl: I sent carlos a list with the issues, maybe it just was a small bug (it worked fine the week before *sigh*)
<mbreit> infinity: both packages build fine in each pbuilder i have tried and they have both the same problem: scons cancels the build and says that gcc failed but there is no gcc error... (i hope you understand what i mean ;))
<infinity> mbreit : I'll try the builds locally for kicks, but a string of continual build failures over two months doesn't bode well for you.
* ajmitch hopes elmo is around for syncs soon :)
<pitti> Hey hey seb128 
<pitti> oh, I scared him...
* ajmitch waves to seb128 & realises he's gone already
<daniels> yo pitti
<pitti> Hi daniels 
<pitti> Moin seb128
<daniels> yo seb
<mbreit> infinity: i already talked with lamont... he did not have enougth time for it but he seemed to think that it _could be_ a buildd problem as well
<seb128> hey pitti
<infinity> Sure, anything COULD be, doesn't mean it IS.
<infinity> I'm about to play.
<mbreit> infinity: and i have no chance to find the real problem because i am unable to reproduce it...
<jsgotangco> ajmitch, you free?
<ajmitch> jsgotangco: yeah
<jsgotangco> ajmitch, can you review BreezyReleaseNotes ? I just updated it with the install stuff
<ajmitch> ok, will look over it
<ajmitch> want me to fix spelling as I go?
<mbreit> infinity: in any case, thanks for looking at it!
<jsgotangco> yes
<daniels> pitti: did you get to that keyboard stuff?
<ajmitch> jsgotangco: I wonder if we should mention zope 3.1.0 alongside 2.8.1?
<pitti> daniels: argh, sorry, completely forgot about that
<pitti> daniels: let's do it right now
<daniels> pitti: thanks :)
<daniels> pitti: sorry to be a hassle
<jsgotangco> ajmitch, it was added nonetheless
<jsgotangco> (by doko i believe)
<ajmitch> yes
<crimsun> made some minor capitalisation corrections to BreezyReleaseNotes
<pitti> daniels: I'm doing this now at my ppc, is that right? 
<pitti> Hi dho
<ajmitch> morning dholbach 
<pitti> Hi dholbach 
<dholbach> hellas andrew, martin
<daniels> pitti: yep
<\sh> mdz: http://bugzilla.ubuntu.com/show_bug.cgi?id=16375 <- this issue is fixed in amarok 1.3.3 but I think it's better to backport it after breezy release...my opinion...dunno how do you think about it
<pitti> daniels: ok, I installed libxkbfile1 7.0.0-3, and then xkeyboard-config 0.6-6. what now?
<daniels> pitti: setxkbmap -print | xkbcomp - :0
<pitti> daniels: lots of warnings, shall I email the output to you?
<seb128> hey daniels
<daniels> pitti: if they're 'no symbols for key <FOO>, ignore it'
<seb128> daniels: any xkb crack that needs some testing?
<daniels> seb128: represent
<daniels> seb128: nothing new, just testing on ppc (kamion asked)
<pitti> daniels: also, no symbols for many other prefixes (<K..., <I, and so on)
<pitti> daniels: and "Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols"\n Ignoring extra symbols
<daniels> pitti: those are fine; the first one is more concerning
<daniels> s/first/last/
<pitti> daniels: (the last warnign I quoted is actually the first one, in case it matters)
<daniels> yeah
<daniels> pitti: when did you download 0.6-6?
<daniels> pitti: if it wasn't just then, could you please try it again?
<pitti> daniels: maybe 5 minutes ago
<pitti> daniels: md5sum of the deb starts with 90b829
<pitti> erm, 90b820
<daniels> hold on a sec
<daniels> this is what I have on disk: 8bc3e15c2af8197a8c105b7651679548  xkeyboard-config_0.6-6_all.deb
<daniels> seb128: which md5sum do you have?
<pitti> daniels: ok, I install the new version
<seb128> daniels: ? that's for pitti?
<daniels> seb128: no, I'm curious to see which one you got last night
<pitti> daniels: still the same output
<seb128> daniels: I've dropped the .deb this morning ...
<daniels> pitti: please send me the output of setxkbmap -print in /msg
<daniels> seb128: okay, thanks
<seb128> np :)
<pitti> daniels: done
<sabdfl> Riddell: ping
<sabdfl> Kamion: ping
<janimo> pitti, ping
<janimo> which lang packs should be included in a base+xfce (no kde/gnome/OOo) install?
<Kamion> sabdfl: yes?
<pitti> janimo: just the base ones
<pitti> janimo: language-pack-XX
<janimo> pitti, does that have firefox too?
<pitti> janimo: no, ffox has its own locale packages
<pitti> janimo: mozilla-firefox-locale-XX
<janimo> and how large are the base packs in all languages?
<pitti> janimo: the language-support package depend on them, but also on OO.o stuff
<janimo> pitti thanks
<pitti> janimo: a well translated lang is in the order of 2 MB
<janimo> is that the Size: field in apt-cache show?
<sivang> Good morning all
<janimo> hey sivang
<seb128> elmo: kbd sync please
<dholbach> Kamion, mdz: how do you think about a ruby1.8 sync to fix #17415? the changelog and the corresponding debdiff are a bit long, but 1) ruby insiders consider it massive breakage, 2) ruby is in main merely as a biuld-dep for redland-bindings and kdebindings, so i'd consider it important enough to do it
<dholbach> Kamion: oh, i see that mdz already commented on the bug and doesnt like the idea :(
<pitti> janimo: yes
<sabdfl> Kamion: what was the name we settled on for the server-oriented iso?
<sabdfl> and is that on track?
<fabbione> 2ubuntu ?
<fabbione> because 1ubuntu was too small ;)
<Kamion> sabdfl: I've just labelled it ubuntu-server for now
<Kamion> http://cdimage.ubuntu.com/1ubuntu/ would just be gratuitously confusing, I think
<johnm> I half expected it to go the same way as things like kubuntu. subuntu ;)
<sivang> yay for ubuntu-server :)
<infinity> one-u-buntu might be less confusing, if you really wanted the catchy name.
<Kamion> sabdfl: I did most of the work last night; first cronned build is due to happen at 10:29 today
<sabdfl> Kamion: did i ever mention that YOU ROCK!
<Kamion> ta :)
<Kamion> it wound up being a pretty plausible size for a CD image, actually
<Kamion> maybe 15-20MB smaller than our main images
<pitti> Kamion: do you have an idea why amd64 live is so much bigger than the other archs?
<sabdfl> mdz: ping
<sabdfl> does anyone know if there is a draft breezy release announcement?
<Treenaks> sabdfl: there is
<sabdfl> i see the preview one
<sabdfl> and he rc one
<Treenaks> sabdfl: oh wait.. the RC one is not the draft for the final one?
<Burgundavia> sabdfl, https://wiki.ubuntu.com/BreezyReleaseNotes
<Kamion> pitti: not at present
<Burgundavia> sabdfl, talk with jsgotangco, he is coordinated that from the doc team side of things
<jsgotangco> i've been updating it today
<sabdfl> Burgundavia: those are the release notes, not the announcement
<sabdfl> jsgotangco: updating it where? can i edit it too please?
<jsgotangco> sabdfl, i meant the release notes...
<Burgundavia> sabdfl, in that case, it is much too late
<jsgotangco> eh?
<Burgundavia> night all
<pitti> Hi carlos, I missed you :-)
<carlos> pitti, Hi
<pitti> carlos: did you find the reason for the removals? I'm currently processing today's tarballs
<carlos> I'm with the gas installer, it's taking much more time than I expected...
<carlos> pitti, the removals are usually removals of msgid and msgstr I'm not completely sure, need to do some extra checks
<sabdfl> carlos: please can you set aside some time to bring me up to speed on the langpack status? it's critical for the breezy release
<pitti> carlos: for dapper, is it possible to add some checks to the exporter that it never ever removes valid translations?
<carlos> pitti, excuse me?
<carlos> pitti, those removals are related to .pot files because the msgid is also missing 
<pitti> carlos: they are? but I merged my own import with all pot files that rosetta exports
<pitti> carlos: is it possible that rosetta exports po files for domains which don't have a pot file?
<carlos> sabdfl, well, the fast answer: all things where ok until yesterday's language pack when pitti saw that we were removing some msgids. No code changes done, so I don't have an explanation other than .pot files pending to be imported...
<carlos> pitti, no
<carlos> pitti, but it's possible that Rosetta exports a .pot file that is not the one currently imported
<sabdfl> carlos: have you seen this mornings mail from timo jyrinki?
<pitti> carlos: I'm just wondering why it worked so well the last time and now we start to see removals again
<carlos> pitti, and as we don't export obsolete messages with language packs the .po files are missing those
<pitti> carlos: so you are 100% sure that these are obsolete?
<carlos> pitti, I started yesterday a test merging the .pot files too with the .po files exported from Rosetta
<pitti> carlos: I will check whether I have a corresponding pot file when I compare the diff
<carlos> pitti, but I think your script was not working as expected there (not sure how is possible as it's too simple)
<carlos> pitti, no, I'm not 100% sure those are obsolete
<carlos> pitti, but it's the only explanation I have for that change without any code change in my side
<carlos> as I said, still working on it, but the gas installer is taking too much time this morning and I was not able to resume my work yet
<pitti> carlos: ok, I will scrutinize today's diff
<carlos> pitti, ok, thans
<carlos> thanks
<carlos> sabdfl, from the email that Timo Jyrinki sent to the rosetta-user mailing list I see that we have a hard usability problem
<carlos> sabdfl, he translated serpentine from the upstream links but he didn't translate it for Breezy, so it's normal that it does not appears in the language pack
<sabdfl> bugger
<carlos> checking what happens with the other packages
<seb128> pitti, Kamion: do you know about #17395 ?
<JaneW> hi guys, I am busy proofing the BreezyReleaseNotes, are there any more know issues to be listed in these?
<carlos> pitti, seb128, mvo: I'm not sure how python's gettext works... where does it look for the translations?
<zyga> carlos: hi
<Kamion> seb128: seems a bit like #1291
<carlos> zyga, hi
<Kamion> don't know what the default ntfs permissions are
<seb128> Kamion: I found #1291, but pitti updated it to mention that's a write issue
<Kamion> seb128: ... for vfat
<Kamion> your bug's about ntfs
<seb128> yeah
<zyga> carlos: is there any page where I can track stuff language pack, besides the wiki?
<carlos> zyga, no, sorry
<seb128> Kamion: what is the right place for that? partman?
<Kamion> seb128: yes
<seb128> Kamion: I'll reassign so, thanks
<Kamion> well, partman-basicfilesystems if you want to be specific
<pitti> seb128: ntfs has its own permission system, but I don't know about it
<Kamion> there's uid= gid= umask= for ntfs mounts
<pitti> seb128: it's similar to the "I can't read my UDF cd-rom because files have uid 500"
<Kamion> the problem is that partman doesn't know what the first user's uid is going to be
<pitti> Kamion: but does these really help?
<Kamion> pitti: they're not terribly helpful
<pitti> Kamion: in the UDF and hfsplus case, they only help to map uid 0
<seb128> in any case an user should be authorized to browser it no?
<pitti> (which is a sane thing, but doesn't help in that particular case)
<seb128> s/browser/browse/
<pitti> seb128: we should not forcefully override permissions of all paritions we see
<pitti> seb128: (that would require a kernel patch anyway)
<pitti> seb128: but playing around with umask would be worth a try
<seb128> pitti: in any case we should not put it on the desktop if it's not browsable
<Kamion> TBH I think it's really too late to sort this out for breezy; we get hardly any testing of installer changes at this point, and when we're essentially just trying to hotfix things we don't really understand it makes me scared
<seb128> pitti: but that's for 5.10 now anyway
<seb128> s/5.10/after 5.10/
<Kamion> I think it's the desktop's responsibility to figure out what it should/shouldn't display :-)
<Kamion> the installer's just arranging for it to be mounted ...
<seb128> Kamion: is there any installer update planned (I could use a string fix)?
<Kamion> seb128: no more string fixes
<seb128> k
<Kamion> there will be some small installer changes but only really critical stuff
<Kamion> I need to figure out why oem-config isn't displaying any translations
<Kamion> if it's a fix to a string that's translated in Debian too, best get it upstream
<Mirv> carlos: (i'm timo jyrinki) the translations are missing also for eg. language-selector and gnome-system-tools (disks part), that were part of breezy. I couldn't find breezy version of serpentine template, but most other were done under the breezy
<carlos> Mirv, hi
<carlos> Mirv, https://launchpad.net/distros/ubuntu/breezy/+sources/serpentine/+pots/serpentine
<pitti> infinity: I'm afraid iI need your help again
<seb128> Kamion: k, because the LVM menu item from partman is a bit long so you get the device name cut, but that's not a big deal
<pitti> infinity: courier failed to build on adare due to the old procps install failure
<pitti> infinity: "error: 'dev.mac_hid.mouse_button_emulation' is an unknown key" and so on
<infinity> Ugh.  warty?
<pitti> infinity: yes w-security
<infinity> I need to get elmo to build those into the kernel until we stop supporting warty..
<Mirv> carlos: what about the rest of the problem? are you looking at it?
<seb128> pitti: have you done any dia upload to hoary?
<pitti> yay, new bzr!
<infinity> pitti : I'll kick it manually in a second.
<carlos> Mirv, yeah
<pitti> seb128: yes, yesterday AFAIK
<seb128> pitti: http://bugzilla.ubuntu.com/show_bug.cgi?id=17521
<carlos> pitti, what tarball did you use for the language pack?
<pitti> well, not yesterday, but recently
<pitti> carlos: for which one?
<Mirv> (and serpentine wasn't found mainly because it's not in https://launchpad.net/distros/ubuntu/breezy/+lang/ list, the same problem as with some other packages earlier)
<seb128> pitti: that's a standard arch all/any out of sync?
<pitti> seb128: yes, easy
<carlos> pitti, latest one
<seb128> pitti: k, thanks
<pitti> seb128: he needs hoary-universe security updates
<pitti> seb128: dia is universe, dia-gnome and dia-common are main
<seb128> pitti: yeah, I've asked for some details, I was thinking the same
<seb128> pitti: thanks
<pitti> carlos: 20050929 AFAIK
<pitti> seb128: shall I answer? If you do, just suggest him to install dia-gnome :-)
<carlos> pitti, ok, thanks
<Mirv> carlos: as a sidenote; serpentine was now also imported to the breezy version - nice to see upload working so nicely nowadays.
<seb128> pitti: I've replied, thanks
<carlos> Mirv, cool
<sabdfl> mjg59: ping
<sabdfl> daniels: ping
<daniels> sabdfl: 'evening
<Kamion> seb128: ok, that's Ubuntu-specific
<sabdfl> daniels: quitting the X server seems to put X into a catatonic state
<sabdfl> am using fglrx, kde and kdm
<sabdfl> not sure where the issue is
<sabdfl> how to debug?
<daniels> sabdfl: if you could mount the partition containing /var with 'sync', so you get a full Xorg.0.log and dmesg, that would probably be handy; that is, if it's an error
<daniels> if it's just fglrx failing to set the card up right when it exits, then there's not much I can do other than to just pass it up to ATI
<sabdfl> it doesn't hang the box
<sabdfl> i can still ssh into it
<daniels> oh, okay
<sabdfl> has fglrx changed recently?
<daniels> does the tail of Xorg.0.log show a clean exit rather than a crash?
<sabdfl> can i isolate it down to X or Kdm easily?
<daniels> we took a new upstream version ... maybe a month ago?
<daniels> it won't be kde or kdm; if it tanks the display on exit, then that's wholly fglrx's fault
<sabdfl> well, Kdm doesn't respond to -HUP
<daniels> is Xorg stil running?
<daniels> if so, it could well still be waiting on a child server
<daniels> also, maybe HUP just reloads the config file; does it respond to other signals?
<sabdfl> daniels: yes, xorg was still running
<sabdfl> can i start up to maintainer mode, then just startx?
<daniels> sabdfl: you can just sudo Xorg :0 -ac vt7, if you like
<daniels> then ctrl-alt-backspace it and see if it dies cleanly
<sabdfl> ok, will try that and report
<mjg59> a
<mjg59> Hrm
<mjg59> sabdfl: Hi
<Kamion> infinity: I'm thinking an amd64 live filesystem reset might be a good idea shortly, to clear out any cruft; it's large
<Kamion> or seems excessively large, anyhow
<Kamion> is there any way to see how much wasted space there is there?
<infinity> lamont just reset it 3 or 4 days ago, has it been growing?
<Kamion> infinity: it's hard to tell, because there's been churn. I've been removing stuff from desktop to try to make things fit; does that need a reset to really be effective?
<mvo> carlos: do you still need that python gettext information? it does basicly the same as the (original) gettext patch in glibc
<pitti> mvo: oh, does it still compare timestamps?
<infinity> Kamion : Quite possibly.  I'm not well-versed in the ways of the rest, but I do have some handy instructions here.  I can play right after I make/eat dinner.
<carlos> mvo, ok, so you are 100% sure that will get the .mo files from language packs, right?
<infinity> Kamion : If I get back to you in a couple of hours with some numbers (and a reset cloop), is that soon enough?
<mvo> pitti: yes
<Kamion> infinity: yep, that's fine, plenty of other stuff I can be doing in the meantime
<pitti> mvo: *shudder*
<mvo> carlos: well, if the patch wasn't ripped out then yes
<pitti> mvo: for dapper we should sanitize it to match the current libc patch
<mvo> pitti: fine with me
<carlos> mvo, ok, thanks for the info
* infinity -> food.
<mvo> pitti: the new one is the one with caching support?
<pitti> mvo: and without stat()
<pitti> mvo: it just prefers a file in /u/s/locale if it exists
<pitti> mvo: and falls back to /u/s/locale-langpack otherwise
<pitti> mvo: and uses libc's internal caching
<zyga> pitti: hmm why was stat needed in the first place, to know which file to pick?
<pitti> zyga: yes, for hoary, when we did not strip all the packages yet
<mvo> carlos: I'm apt-get sourceing python now to have a look. do you have a test-case where python gettext fails for you?
<carlos> mvo, no, I'm just asking, I was not sure if python was patched
<zyga> pitti: so now packages never contain .mo files, right?
<pitti> zyga: main packages don't, right
<carlos> mvo, what about the applications like zope that have a different layout than the other gettext applications?
<pitti> zyga: universe packages do
<zyga> pitti: k :)
<zyga> pitti: is there any change in rosetta-breezy.tar.gz export process?
<pitti> zyga: the point was, if you build a package locally, you will get translations in /u/s/locale, and they should be used
<pitti> zyga: not recently
<mvo> carlos: I don't know about zope, but it sounds pretty bad if it has a different layout then any other gettext app 
<zyga> pitti: what is missing? you said it only catches about 40% of the total number of translations in rosetta
<mvo> carlos: it seems to work for our various python desktop apps (language-selector, update-manager etc)
<pitti> zyga: right, that will be fixed in the near future
<zyga> pitti: I've got some progress on my side but nothing spectacular yet
<carlos> mvo, they store the .mo files inside their own tree and I think they use directly es/zope.mo
<carlos> mvo, ok, thank you for the check
<mvo> carlos: I'm happy to have a look at zope after the release (please remind me)
<carlos> ok
<carlos> thanks
<daniels> seb128: what's the usual remedy for 'my desktop is fucked'?
<daniels> seb128: couldn't log in before, everything was hanging
<Treenaks> daniels: ifup lo
<Treenaks> that usually fixes hanging logins for me
<daniels> seb128: started a new xterm session, started gnome-panel, gnome-settings-daemon, nautilus, by hand; g-p was useless until I killed the old one by hand, nautilus just crashed then
<daniels> but most everything else (started metacity by hand) works okay
<daniels> to add to the hilarity, I've been stuffing around with XKB locally, and that had broken VT switching for me
<daniels> Treenaks: ah, thanks
<daniels> isn't hotplug supposed to do that, or is that too boring for it to be doing in a release week?
<seb128> daniels: yeah, you need to have a working loopback
<seb128> daniels: did you run dhclient?
<daniels> i just started doing dhclient for my wlan, yeah
<daniels> bad idea?
<daniels> okay, that fixed things -- thanks
<seb128> daniels: http://bugzilla.ubuntu.com/show_bug.cgi?id=10174
<daniels> ungh, firefox sessionsaver rocks
<daniels> mjg59: we should really switch to a VT around S3 on Intel hardware
<daniels> mjg59: else the next use of Xv tanks the engine
<daniels> mjg59: in a you-must-reboot kind of way
<daniels> seb128: thanks for the link
<mjg59> daniels: We do
<daniels> mjg59: hrm
<daniels> i wonder if POSTing it breaks things
<mjg59> daniels: I'm using xv here
<CaiN_SA> charles you here ?
<mjg59> No problem at all
<daniels> mjg59: are you POSTing?
<pitti> infinity: courier on warty-security/ppc still seems to hate me :-(
<daniels> fucking xkb can bite me
<pitti> bah, I get the gnome/X keyboard dialog even on a fresh breezy install
<Kinnison> Hi guys
<Riddell> sabdfl: pong
<Kinnison> Can I have everyone's attention for a moment please.
<Kinnison> As you are all (hopefully) aware; dapper will be opening on Launchpad (assuming we don't have any hideous problems)
<Kinnison> As a result, you all need to ensure that, 1. you have launchpad accounts
<Kinnison> and 2. you have your GPG keys registered with launchpad
<Kinnison> Thank you
<pitti> Kinnison: will there be a special upload tool for launchpad?
<ogra> Kinnison, so we'll switch officially to maolne on friday too ? 
<pitti> Kinnison: or will uploading to upload.ubuntu.com work as usual?
<mjg59> daniels: Yes
<Kinnison> pitti: uploading will be done by FTP as usual
<daniels> mjg59: arsing shit
<daniels> Kinnison: i have a question
<Kamion> Kinnison: would you mind sending instructions to ubuntu-devel@lists.ubuntu.com, for those who aren't here?
<Kinnison> Kamion: I'll do that, yes
<Kamion> thanks
<daniels> Kinnison: how do you represent <center><h1><font color="red">A system error has occurred.</font></h1></center> in text, if we're just going to be using an FTP client?
<crimsun> Kinnison: I can't upload my gpg key (via fingerprint) to launchpad. It explodes with a system error.
<Kinnison> daniels: Hah, you think the FTP server runs in zope?
<Kinnison> crimsun: then it's essential that you work with the launchpad team to get that fixed
<Kinnison> crimsun: please see them on #launchpad
<mvo> ha! worked for me
<daniels> Kinnison: dude, if this Launchpad meme spreads any further, the kernel will be modified to run on Zope, and all the Ubuntu installs will use it
<ogra> daniels, wasnt that planned anyway, after the kernel was rewritten in python ? 
<ogra> i think then you'll need a slim replacement for thttpd anyway :)
<segfault> ogra: ping
<ogra> segfault, ponmg
<segfault> ogra: i updated the xscreensaver po file in Rosetta, can you try using that one?
<ogra> i'll try... sadly it always generates iso-8859-1 files for pt_BR ... :/
<segfault> should be using UTF-8 now. 
<seb128> jbailey: around?
<ogra> oh, ok
<segfault> if that doesn't wok, i can send you the po file by mail
<ogra> segfault, i'll have a meeting soon and have to prepare something for that, i'll check it out now, but it will take a moment before i can get to it
<segfault> ogra: no problem, good meeting :)
<ogra> thanks...
<ogra> feel free to attend if you got nothing better to do ;)
<Kamion> infinity: I've approved your festival change. #17275 should be closed now, yes?
<Kamion> Riddell: your diversions handling in kubuntu-docs looks completely wrong to me
<Kamion> Riddell: remember that diversions persist across versions, so there's nothing wrong with a diversion still being there when the preinst runs
<\sh> Riddell: it was mine...I'd took it from another package
<\sh> aeh Kamion i mean
<segfault> heh, ok
<nomed> hi all
<nomed> just a question .. i have this string in debconf: xserver-xorg/autodetect_keyboard: true
<Kamion> \sh, Riddell: please just drop all that and just call 'dpkg-divert --package kubuntu-docs --add --rename --divert /usr/share/ubuntu-artwork/home/index-ubuntu.html /usr/share/ubuntu-artwork/home/index.html'
<Kamion> dpkg-divert will do nothing (silently, if you also use --quiet) if the diversion is already there
<Kamion> none of the dpkg-divert --list stuff is necessary
<\sh> Kamion: ok...I'll change it just now..ok for upload then?
<Kamion> \sh, Riddell: also, you should only call dpkg-divert 'if [ "$1" = install ] '
<nomed> but it seems during dpkg-reconfigure -fnoninteractive xserver-xorg it can't set the keyboard .. this in breezy .. in hoary it was working 
<Kamion> no, sorry, 'if [ "$1" = install ]  || [ "$1" = upgrade ] '
<\sh> Kamion: fixing 
<Kamion> (because the preinst is also called in the abort-upgrade case)
<\sh> Kamion: what about postrm?
<Kamion> \sh: the postrm's fine except that [ == ]  is a bashism; use = instead of == there
<\sh> k
<\sh> oh well...
<\sh> why don't I get kubuntu-docs_5.10-0.4 from the archives?
<Kamion> \sh: there's also a stray kubuntu-docs_5.10-0.4_i386.build in the source package
<Kamion> \sh: because I haven't approved it
<\sh> Kamion: grmpf...i need the source package :(
<\sh> or wait for riddel to fix it
<segfault> is anyone looking into that "About Ubuntu" missing link?
<Kamion> \sh: http://people.ubuntu.com/~cjwatson/tmp/kubuntu-docs/
<\sh> thx
<Kamion> segfault: jbailey's assigned to it
<segfault> ok
<\sh> Kamion: can I upload with the same version again, oder version +0.1?
<Kamion> \sh: no, you can't; increase the version
<\sh> k
<Kamion> infinity: does SUBSTing into a Default: field the way nagios-common.config does actually work, anyway? I didn't think debconf did subst expansion on Default
<Kamion> infinity: I'll approve it anyway, since it's not going to do any harm if I'm right
<\sh> Kamion: uploaded...thx for the hints :)
<Kamion> \sh: did you test this? I suspect not
<Kamion> +if [ "$1" = "install"]  || [ "$1" = "upgrade" ] ; then
<Kamion> \sh: note the missing space before ] 
<\sh> *grrr* vim
<\sh> and grrr my space key
<Kamion> don't blame your editor for lack of testing
<\sh> Kamion: just doing what my son is doing every time he's smashing a glas accidently..it's the tables fault
* Kinnison does wish people would at least test build and install of packages before uploading them
<siretart> hint: piuparts is great for having this automated..
* \sh 's blaming himself now, pbuilding and testing it now, and is, as punishment, having fun with nagra
<Kinnison> siretart: heck, debuild && sudo debi is a good start
<infinity> Kamion : Erm, oh.  Did I miss fucking with the template too?
<pitti> infinity: hm, still no ppc build for courier warty-security - is that a buildd problem or does the pacakge merely need a g-b?
<hno73> Kamion: you've got a new AMD64 tarball, sans thunderbird and ~6.5MB smaller
<dholbach> bbl
<zyga> pitti: ping
<pitti> Hi zyga 
<zyga> pitti: hi, I'm hacking the language pack thing and I'm wondering how does rosetta handle broken .po files, I've noticed that many many .po files have things that msgfmt -c chokes on
<pitti> carlos: ^ ?
<carlos> zyga, on import or on export?
<zyga> carlos: on export
<pitti> carlos: ideally, there would not be broken po files in the database, thus not on export either :-)
<zyga> carlos: I'm using exported catalogs I fetch from pitty
<carlos> zyga, we still have some pofiles that needs some migration done but usually we validate translations on import time or submission time from the website
<zyga> carlos: how do you validate them?
<carlos> zyga, as we still have some data to migrate, on export time those are exported as fuzzy (when my patch lands on production)
<carlos> zyga, using gettext's library
<zyga> carlos: is that something different from what msgfmt is using
<zyga> carlos: I can show you how many errors I've got if you are interested
* pitti tests live CD
<carlos> zyga, no, it's the same
<carlos> zyga, it depends how do you got the pofile
<carlos> zyga, if it's part of the language pack, it should validate
<zyga> carlos: ask pitty :) I'm fetching http://people.ubuntu.com/~pitti/langpacks/rosetta-breezy.tar.gz
<carlos> zyga, http://mawson.ubuntu.com/~carlos/
<carlos> those are latest language packs
<carlos> hmm
* zyga wants apache to show those damn filenames...
<carlos> but that one smells like the latest one
<zyga> carlos: who is exporting them?
<zyga> carlos: pitty's archive is updated daily
<carlos> zyga, pitti didn't tell me anything about msgfmt failing....
<carlos> zyga, pitti's archive come from that URL
<zyga> carlos: it's failing for me
<carlos> zyga, could you show me an example?
<zyga> carlos: check this out, it's not compleate though: http://www.suxx.pl/ubuntu/language-packs/
<Kamion> infinity: no, the template was like that before you touched it (and messing with it wouldn't make any difference without more invasive changes, so I'm fine with what we have now for breezy)
<Kamion> hno73: thanks!
<carlos> zyga, don't use -c
<zyga> carlos: :-)
<carlos> zyga, those errors are because most of the PO header are fuzzy
<zyga> heh
<zyga> I'll patch header fuziness and try again
<zyga> or better
<zyga> use --check-format 
<carlos> zyga, msgfmt does that check by default
<zyga> okay, cool
<zyga> thanks, I'm back to hacking
<zoot_> ogra: hi, if you have a moment, please pop-in on #ltsp for a sec?
<HiddenWolf> mvo, ping
<\sh_away> Kamion: tested now...works fine.
<zyga> pitti_live: did you concider using qemu to test the live cd?
<pitti_live> zyga: I tried qemu once, but first it is nontrivial to set up, second, I'm not sure whether it supports amd64, and third, I want to test the true experience, not a simulated environment
<pitti_live> zyga: does qemu work well for that?
<zyga> pitti_live: I haven't tested that but AFAIR it does support both amd64 and ppc 
<zyga> pitti_live: nontrivial? qemu -cdrom foo.iso
<mvo> HiddenWolf: pong
<pitti_live> zyga: hm, last time I tried it it fell apart into pieces
<pitti_live> zyga: maybe it got better now
<zyga> pitti_live: I've been using it lately to test live cds I've been building - it's quite usefull
<pitti_live> zyga: but thanks for the hint! will try that
<HiddenWolf> mvo, how trivial would it be to patch gksudo to grey out it's 'continue' button when no password is entered?
<zyga> pitti_live: for extra hardcore experience - try it now ;D
<pitti_live> zyga: qemu on the live CD?
<zyga> HiddenWolf: quite :)
<zyga> pitti_live: why not
<mvo> HiddenWolf: good question, shouldn't be very hard but it's still something I would feel uneasy about so short to the release
<zyga> pitti_live: just apt-get install it :)
<HiddenWolf> mvo, just put it on the shortlist, it's kinda dumb to pop up a "you did not enter a password, and gksudo needs it" dialog. :)
<zyga> HiddenWolf: does gksu works if user has no password?
<mvo> zyga: no
<mvo> zyga: qemu looks really nice
<pitti_live> zyga: it doesn't have amd64, but powerpc
<HiddenWolf> Can you get a useraccount without a password?
* carlos -> lunch
<Kamion> last I looked its powerpc emulation was PReP only
<Kamion> but that might have changed
<zyga> HiddenWolf: you can disable the password with passwd -d
<pitti_live> zyga: I started it with the i386 live image, and it indeed does something :)
<zyga> pitti_live: tip: ctrl+alt+f for fullscreen
<zyga> carlos: there are some residual errors 
<zyga> carlos: default CHARSET as charset, or non-portable charsets (windows stuff mostly)
<carlos> zyga, yeah, please, file a bug
<carlos> I suppose that the best solution would be to export it as UTF-8
<zyga> carlos: a bug?
<zyga> carlos: where, to the original project?
<zyga> carlos: I agree about utf-8
<carlos> well, it's not a problem with Rosetta but someone uploading a broken pofile
<zyga> all non utf-8 stuff should DIE unless we invent something better than utf-8 
<carlos> zyga, no, against Rosetta so we fix those files
<carlos> zyga, see you later, time to have lunch
<zyga> okay
<mdke> Kamion, around?
<Kamion> mdke: yes?
<mdke> Kamion, pvt
<\sh_away> grmpf
<zyga> hno73: ping
<pitti_live> zyga: I'm impressed - I run a i386 live image in qemu on top of an amd64 live system 
<zyga> pitti_live: how is performance? how much ram do you have?
<pitti_live> zyga: if my mouse would actually work in that system, it would be perfect :-)
<zyga> pitti_live: tip: alt+ctrl over the emulator window
<zyga> (this will transfer the mouse)
<pitti_live> zyga: I know
<pitti_live> zyga: -> #ubuntu
<hno73> zyga: pong
<zyga> hno73: hi, IIRC you are responsible for the wiki.ubuntu.com
<hno73> zyga: yes
<zyga> hno73: I've told you about a trivial error in the search result page (for polish) recently, do you remember?
<zyga> hno73: I was wondering if I should file a bug about that :)
<hno73> zyga: you can write it up here: https://wiki.ubuntu.com/wiki/BugReports
<zyga> hno73: okay, thanks
<pitti_live> sivang: brb, booting back to my normal system
<da_bon_bon> does ubuntus hibernate unmount all disk drives before hibernating ?
<zyga> hno73: done
<zyga> hno73: that bug seems trivial if you are interested in fixing it now ;-)
<JaneW> Guys please read the BreezyReleaseNotes, and add any more know issues which need to be listed in these. https://wiki.ubuntu.com/BreezyReleaseNotes
<zyga> carlos: full log, some more less critical things that should not have been imported are around too: http://www.suxx.pl/ubuntu/language-packs/
<zyga> pitti: ^
<hno73> zyga: thanks. I don't think now is a good time though, with various release-related things up in the air
<zyga> hno73: sure
<da_bon_bon> why does hibernate on ubuntu blank the screen ? that way, people like me, who donot use acpi cant know when to switch of the computer.
<HiddenWolf> Guys, my firefox is messed up badly
<HiddenWolf> Could that be todays upgrade?
<fabbione> messed up how?
<HiddenWolf> no menus
<fabbione> no
<fabbione> there was only a CFLAGS option changed
<HiddenWolf> I'll investigate.
<Treenaks> HiddenWolf: did you exit/restart firefox after the upgrade?
<fabbione> (btw it works here)
<HiddenWolf> Treenaks, i'll give it a reboot in a minute.
<Treenaks> HiddenWolf: no, just firefox
<Treenaks> HiddenWolf: not the entire machine
<HiddenWolf> Treenaks, kernel upgrade too, might as well do the machine. :)
<HiddenWolf> Treenaks, seven vunerabilities yesterday, remember. :)
<fabbione> HiddenWolf: not in breezy
<fabbione> read the changelog
<HiddenWolf> fabbione, must've cleaned thunderbird out already, i'll believe you on your word. :)
<bddebian> Hello
<dholbach> re
<Kamion> oh crap, that debconf-copydb templatedb translation handling bug has come back to bite me with oem-config
* Kamion tests frantically
<zyga> JaneW: ping
<JaneW> zyga: pong
<zyga> JaneW: regarding BreezyReleaseNotes
<JaneW> zyga: yes
<zyga> how about adding a FAQ: where did the terminal from the desktop context menu go
<zyga> my friedns keep asking for this after recent upgrade
<zyga> (it's in the nautilus extension stuff AFAIR)
<Kamion> zyga: there's already a FAQ entry for that
<Lathiat> yeh, nautilus-open-terminal package
<Kamion>  Where did the Terminal go?
<Kamion>     *
<Kamion>       Not on the desktop context menu anymore. Install nautilus-open-terminal if you want it.
<zyga> ...
* zyga is blind
<zyga> sorry I did read that but I've missed the n-o-t part somehow
<Lathiat> tahts not the best description
<Lathiat> (question)
<JaneW> zyga: that's in BreezyReleaseNotes already
<JaneW> ditto what kamion said...
<zyga> JaneW: right, sorry
<JaneW> np :)
<Diziet> Curse gs and it's strange half-reopening and half-closing of the x11 driver.
<Diziet> s/it's/its/; # and curse my speling two
<zyga> carlos: ping
<Seveas> elmo, Kamion, sabdfl, mako, *ping* CC meeting in 3 minutes :)
<Kamion> oh god, such a bad time
<Kamion> ok
<dieman> nice
<ogra> oh, there is CC meeting now ? 
<dieman> the new .htaccess broke my mirror
<dieman> oh well
* dieman had to add another allowoverride
<carlos> zyga, pong
<zyga> carlos: nautilus-open-terminal/rosetta/where/question/execute
<Kamion> dieman: which new .htaccess?
<zyga> carlos: according to mapping.txt it should have separate domain
<dieman> Kamion: there were some RedirectTemp entries for ubuntu-releases
<carlos> zyga, nautilus-open-terminal/rosetta/where/question/execute ?
<Kamion> dieman: right, yeah, I added those 'cos I moved the source off releases back onto cdimage
<zyga> carlos: also, re-checked current .po exports with less-strict checks and msgfmt still chokes on some of them, is that okay (since they were alredy imported and had to go through verification)
<dieman> Kamion: i didn't have the allowoverrides set to allow those,
<dieman> not a huge deal
<Kamion> fair enough
<dieman> but all the sudden it stopped working :)
<zyga> carlos: rosetta doesn't contain nautilus-terminal-open according to search from the main page
<Kamion> did you spell it right? you didn't just now ...
<Lathiat> nautilus-open-terminal
<carlos> zyga, which sourcepackage contains it?
<zyga> carlos: n-o-t
<carlos> LaschW, thanks
<carlos> s/LaschW/Lathiat/
<carlos> zyga, https://launchpad.net/distros/ubuntu/breezy/+sources/nautilus-open-terminal/+pots/nautilus-open-terminal
<zyga> hmmmm
<pitti> Kamion: do we care enough about sparc to warrant a postgresql-8.0 upload which uses gcc-3.3 on sparc? (#17507)
<pitti> fabbione: ^ 
<janimo> Kamion, can I branch the public ubuntu seed archive locally for xubuntu?
<zyga> carlos: then why did searching for it fail?
<Kamion> janimo: certainly; see http://wiki.ubuntu.com/SeedManagement for info there
<Kamion> janimo: that's what I was going to suggest you do, in fact, as soon as I got time to reply to you
<fabbione> pitti: is that required to make it working? 
<fabbione> pitti: up to you really.. i have spare cpu cycles to build...
<pitti> fabbione: yes, otherwise it just plainly fails
<Kamion> janimo: you should also play around with germinate (in breezy)
<fabbione> pitti: if you can get it in, the better
<pitti> fabbione: it's a simple workaround I already tested in Debian
<janimo> Kamion, so no chinstrap account and things like that?
<Kamion> pitti: not unless an upload is needed for another reason, I think
<Kamion> janimo: no
<pitti> Kamion: no, on the primary arches it works fine
<janimo> I'll have to ask jblack or lifeless for a place to publish my changes though
<Kamion> that's only if you need to commit to the Ubuntu/Kubuntu/Edubuntu seeds
<Kamion> janimo: surely you have some web space somewhere?
<pitti> Kamion: the upload would not change anything on the primary arches, though
<fabbione> pitti: it's ok.. we will cope with it on dapper
<pitti> fabbione: alright
<janimo> Kamion, other than a sourceforge account not right now
<fabbione> pitti: thanks a lot for looking into it
<janimo> will get some though don't worry
<carlos> zyga, because the sourcepackage search form does not contain any data
<carlos> zyga, it will be fixed soon
<zyga> carlos: right, thanks :-)
<carlos> zyga, if you know the sourcepackage name will work if you add it by hand, sorry for this usability problem, hope it will be fixed soon
<zyga> barf
<zyga> anyone know how the hell does msggrep works...
<zyga> eg: msggrep -K foo bar.po 
<Kamion> -K -E foo
<Kamion> ?
<Kamion> er, -e
<zyga> I want to find 'foo' in msgid in bar.po
<Kamion> I think I usually have to give it -e or -f
<Kamion> so 'msggrep -K -e foo bar.po'
<zyga> hmm
<Kamion> that's what the --help says if you read it VERY carefully
<zyga> manpage is broken
<zyga> ;)
<zyga> lacks 'EXAMPLES' section
<zyga> Kamion: Message selection:
<zyga>   [-N SOURCEFILE] ... [-M DOMAINNAME] ...
<zyga>   [-K MSGID-PATTERN]  [-T MSGSTR-PATTERN]  [-C COMMENT-PATTERN] 
<zyga> -K pattern -- that is wrong according to real life 
<Kamion> MSGID-PATTERN or MSGSTR-PATTERN or COMMENT-PATTERN syntax:
<Kamion>   [-E | -F]  [-e PATTERN | -f FILE] ...
<zyga> ah
<Kamion> therefore [-K MSGID-PATTERN]  => [-K [-E | -F]  [-e PATTERN | -f FILE] ] 
<Kamion> not really obvious, but ...
<zyga> only GNU people read help files like that
<zyga> thanks Kamion :)
<zyga> s/read/write/
* zyga curses msggrep
<zyga> it's useless for checking .pot files
<zyga> carlos: is there any plan to change the way long long messages are displayed?
<zyga> carlos: currently it is very difficult to translate long messages as the translator needs to scroll back and forth to read both texts
<carlos> zyga, any suggestion is welcomed, we don't have any solution for that atm
<Riddell> mjg59: who made the ubuntu usplash image?
<zyga> carlos: since horizontal space is very limited this is difficult
<carlos> yeah
<zyga> carlos: is it possible to include the contents of both columns as a box atop the page
<zyga> so that translations can use all the horizontal space below?
<zyga> (hint: this way we could fit a two column interface there)
<carlos> zyga, talk with mpt at #launchpad, he's our UI expert
<zyga> carlos: ok
<zyga> mvo: ping, if busy respond with pong-busy
<zyga> (low importance)
<infinity> pitti : Build fixed/rescued.
<pitti> infinity: thanks
<mvo> zyga: pong-busy
<mvo> zyga:what is it about?
<zyga> mvo: missing patch for update-manager CVS, nothing important really
<mvo> zyga: ok
<seb128> pitti: http://bugzilla.ubuntu.com/show_bug.cgi?id=17540
<pitti> seb128: yep, I'm on it
<seb128> pitti: k, just to make you know
<pitti> seb128: the current Rosetta export is a mess, I need to clean it up
<mvo> pitti: I got a similar report today (just FYI)
<pitti> yesyesyes, I'm working as fast as I can
<Diziet> kamion: I think I have a fix for at least half of 17141 (strange gs crashes).
<Diziet> (on oofice pdf's)
<Diziet> I've been investigating with gs-gpl.  Should I (a) port my fix to gs-esp and upload both straight away or (b) wait until I think I know what the second problem is (pdf2ps fails if you use gs-esp but not otherwise) or (c) something else ?
<ogra> Kamion, ping
<Kamion> Diziet: how long do you think (b)'s likely to take?
<Kamion> ogra: pong
<ogra> Kamion, can you make todays edubuntu daily a RC ? i tested on amd64 and i386... seems fine for me
<Kamion> ogra: I'm working on utterly scarily critical stuff right now, but if I get done with that, yes
<Diziet> kamion: I don't know yet, I had been assuming they were the same bug and I haven't looked at the 2nd half yet.
<Kamion> Diziet: we're rapidly running out of time, so I'd say (a), if (b)'s as yet uninvestigated
<ogra> Kamion, thanks... its not urgent, bureaucracy only anyway :)
<Diziet> When is out of time ?
<Diziet> In about 15 mins I'll know whether (b) is trivial or nontrivial.
<Kamion> you certainly have 15 minutes
<Diziet> :-)
<Kamion> 'cos I'm not going to have oem-config fixed within that time :)
<Keybuk> ...who knows about pcmcia-cs ?
<Keybuk> most of the modules seem to be missing from /lib/modules/.../drivers/pcmcia
<Diziet> kamion: the crash is in a freeing routine and the first thing valgrind spots is in the garbage collector.  I think it might be best to punt.  gs-gpl and pdftops (from xpdf) both work fine.
<spayne> sabdfl: ping
<Kamion> Diziet: all right
<Diziet> I'll go and fight these nightmare patch systems to prepare a pair of uploads.
<pitti> Diziet: does that have anything to do with the bug that ps2pdf cannot convert postscript produced by latex or firefox? (missing fonts)
<Diziet> I doubt it.
<Diziet> The symptoms from these pdfs is that gs-esp eats a lot of ram and then coredumps.
<Diziet> Err, symptoms are.
<pitti> Diziet: ok, thanks
<Diziet> pdf2ps is pretty ropey.  I'm not sure why you'd use it if you've got pdftops.
<pitti> Diziet: it worked fine in hoary
<Diziet> Um, yes.  It's still ropey :-).
<dieman> yeah
<dieman> pstopdf keeps fonts around, too
<dieman> doesn't pdf2ps lose them?
<pitti> Diziet: erm, btw, I mean ps2pdf, not pdf2ps
<Diziet> Err, oh.
<dieman> pdftops, rather
<dieman> hrm
<dieman> broken ps2pdf would suck.
<pitti> if there is another way to convert a postscript file to pdf other than ps2pdf (i. e. ghostscript), I'd be interested :-)
<N6REJ> May I ask a hardware support question?
<pitti> I noticed it yesterday when I wanted to archive my fiscal report for September
<zyga> Lathiat: you have reached a zero value!
<Diziet> I don't know anything about this other bug, but it doesn't sound at all related to what I have here.
<N6REJ> yes? no?
<Lathiat> zyga: :)
<Kamion> N6REJ: we prefer support questions on #ubuntu, really ...
<N6REJ> Kamion: ok, I've tried there, and I believe there to be a bug in the driver is why I'm asking here... But I understand.
<Kamion> if you've got it down far enough that you think you can point to a particular bug in a particular driver, then that sounds like good material for a bug report
<Kamion> oh, I *hate* cdebconf sometimes
* Kamion is forced to upload-then-test rather than the other way round because of awkward cdebconf limitations
<N6REJ> Kamion, I have an ancient S3 Virge video card, with 8mb of ram ( pci ) and it runs great in ubuntu UNTIL you throw the desktop on.  Then it boots gives you the beautiful orange breezy screen and locks up at the username prompt! Its a hardware lock as you can't even [ctrl] +[alt] +[del]  to reboot.  It uses the I850 chipset.  I've tried s3, vesa, s3virge, everything I can think of and all do the...
<N6REJ> ...same.  If I dont' use the gui it works great.
<N6REJ> Kamion: Its a server, so its not a show-stopper, but sense your so close to release I thought I'd mention it.
<Kamion> N6REJ: does it work if you boot in recovery mode?
<N6REJ> Kamion: yes
<Kamion> N6REJ: file a bug against the usplash component, please; it's probably that
<N6REJ> works if you just install in straight server mode too.
<bddebian> Who enables whitelists for katie?  Is that mako?
<dholbach> elmo
<bddebian> Ohh
<dholbach> it's explained on http://wiki.ubuntu.com/Uploads
<mako> bddebian: not me :)
<N6REJ> kamion, ok.. last one... and this might be a big one..... I just bought belkins 54g F5D7001 wireless nics, and gave my son his first computer ( with ubuntu breezy of course ) and breezy thought it was a "firewire" card.  I fixed the wiki so that others can now use it with ubuntu, but I don't think breezy should think its a firewire card.
<N6REJ> ty for listening, and I'll post the bug... I've posted a few others
<dholbach> so don't write to his normal adress
<Kamion> again, that sounds better as a bug report; if it's an installer issue, use 'debian-installer' as the first-resort component
<dholbach> EWINDOW
<N6REJ> Kamion: very good... btw, nice job.  Installs fairly easily... not as slick as engarde, but nice.  Better server documentation would be wonderful.  Have a great day hope to be able to participate more.
<N6REJ> g'bye
* ogra wonders what engarde is
<Kamion> ogra: oh, I dunno, you could try the first hit on google ;-)
<ogra> heh
<ogra> in fact its the second :)
<segfault> what a boring day.
<ogra> oh, looks like a trulux sideproject :)
<ogra> and mentions the word secure in every second sentence ...
<Kamion> ogra: *shrug* it's the first here
<ogra> Kamion, i ger german ones first... there is a fair booth building company called engarde :)
<ogra> s/ger/get
<Diziet> Dammit, something has gone wrong here.  gs-gpl ubuntu3 seems to be missing the diff from ubuntu1.
<Diziet> Oh for a revision control system !
<zyga> Amaranth: hi
<Keybuk> Diziet: I'm writing' it, I'm writin' it!  hold yer 'orses
<Keybuk> https://launchpad.net/products/gs-gpl/+series/main
<Keybuk> ^ there's a CVS mainline import for gs-gpl, so that one's probably ready earlyish
<Keybuk> oh, wait, "Test Failed" ... bug lifeless and ddaa <g>
<Diziet> Hrrrrm.  It's my own diffs I'm losing track of !
<Keybuk> that's what HCT is for
<segfault> ogra: will the new xscreensaver be fixed for breezy?
<ogra> segfault, you mean pt_BR
<segfault> yeah, heh
<Diziet> Indeed.  Should I start to use it yet ?  Given that I'm not really a bleeding-edge type ...
<ogra> segfault, i'm on it... i'm just preparing a RC for edubuntu in the other channel
<segfault> ah, ok
<Amaranth> zyga: hi
<zyga> Amaranth: dholbach suggested that you might know something about one thing
<Amaranth> zyga: python or menu?
<zyga> Amaranth: does the .desktop file specs provide any icon fallback support
<Amaranth> zyga: Not that I'm aware of
<ogra> zyga, the panel maenu has a fallback
<Amaranth> zyga: If the icon doesn't exist ubuntu's patched gnome-panel will add a basic application icon
<zyga> hmm 
<zyga> ogra: how does the panel select the icon then?
<Amaranth> zyga: But you can just say "Icon=foo" and it'll look in the icon theme the user is using for foo.png, foo.svg, etc at all sizes, then fall back to hicolor, then to the basic application icon
<ogra> zyga, it doesnt... if there is no icon, it shows a hardcoded default one
<zyga> Amaranth: I know
<mvo> slomo_: did you had any luck with the updated gnome-terminal? did it fix #17309 for you?
<zyga> Amaranth: I've noticed tango-icon-theme and decided to check how it works in reality - nautlius.desktop has Icon=file-manager where t-i-t provides system-file-manager
<zyga> Amaranth, ogra: thanks
<Kamion> Keybuk: dude. what do you think about adding - flags to programs in dpkg-dev? ;-)
<ogra> zyga, did you read all the docs on the websie about new specs ? they want to change naming schemes
<Keybuk> Kamion: -?! what
* Kamion rings doorbells and runs away
<ogra> loool
<zyga> ogra: no, not yet I'm parsing thru...
<zyga> Kamion: - ;-) ?
<Amaranth> zyga: You should email the fd.o xdg-list and suggest making the Icon key a semicolon seperated list
<ogra> zyga, afaik, dholbach just packed up quickly what was there i dont think the theme has seen extensive adjustments to match ubuntu
<Amaranth> zyga: or have fun with symlinks
<zyga> Amaranth, ogra: I'm off job for today so I might hack this stuff for recreation
<ogra> (which was the right thing imho regarding its immaturity)
<zyga> dholbach: interereted in a tester? :)
<dholbach> zyga: tester for what?
<zyga> ^^
<ogra> zyga, its very young... 
<zyga> ogra: I know :)
<Amaranth> zyga: If you can hack gnome-panel/gnome-menus (whichever handles loading the file and finding the icon) to work with lists that'd be awesome
<zyga> dholbach: the icon theme
<ogra> dont expect i to work or have at least the minimal icon set
<Amaranth> tango doesn't have many icons actually completed yet
<ogra> yup
<ogra> so its nice to have... but dont file bugs about it ;)
<zyga> Amaranth: I don't care about the icons really 
<zyga> Amaranth: what I do like is the idea of another standard for desktop stuff that others might follow
<zyga> (linux desktop really needs this)
<zyga> IMHO of course
<dholbach> bbl
<Amaranth> zyga: Unless the gnome-panel handles icon loading like that it'll get no where without support from GNOME and every upstream in the world. :)
<jdub> part of the project is standardising icon names
<Amaranth> Sure, but we need a gradual change, not a massive all-or-nothing change.
<spayne> is this Tango
<Amaranth> yeah
<mdz> doko: ping
<zyga> Amaranth: true
<mdz> morning all
<zyga> morning mdz
<doko> mdz: pong
<spayne> Kamion: ping
<mdz> doko: can we get #4658 fixed for the release?  it is a long-standing wart
<Kamion> spayne: yes?
<ogra> morn mdz 
<spayne> Kamion: the next meeting is in half term so i can make it :)
<spayne> Kamion: sorry again :)
<Kamion> spayne: yes, I saw your comment to that effect on #ubuntu-meeting
<Kamion> thanks
<spayne> Kamion: just when you're thinking about something all day and when it comes to it :(
<infinity> mdz : Mornin'.
<doko> mdz: yes, looks doable
<pitti> Hi mdz 
<infinity> mdz : Do you have time to argue once more about atheros in the installer?... Earlier today, I had a revelation that it would be MUCH easier to do than we first imagined, and worked up diffs to make it so.  The changes are tiny, very obvious, and should Just Work.
<infinity> mdz : I have the two diffs here: http://cerberus.0c3.net/~adconrad/ath_di/
<infinity> mdz : The nice thing is that no changes in d-i itself are required.
<spayne> Kamion: will this go against my application?
<Diziet> kamion: After faffing, I've determined that: 1. gs-gpl had accidentally had one of our fixes revered (by me, I assume :-/).  But I have a version with that fix and the new one and it works nicely.
<mdz> infinity: isn't a dependency from nic-restricted-modules -> binutils-static-udeb necessary?
<Diziet> 2. gs-esp is broken on at least some pdf's from ooffice and this is true for x11 driver as well as pdf2ps.
<Kamion> spayne: applications are considered on the basis of ongoing contribution to Ubuntu; persistent disruptiveness or obnoxiousness would be a problem, but a simple mistake isn't
<\sh> hmm...hotplug is the responsible piece of software which loads the pcmcia drivers, right?
<Diziet> 2. is the heap corruption, which is a different bug to the x11 bug I've just been chasing.
<spayne> Kamion: thanks :)
<Diziet> So I propose to upload gs-gpl now and carry on faffing with gs-esp.
<infinity> mdz : No, binutils-static-udeb will get pulled in by priority overrides.
<mdz> infinity: and guaranteed to be there before nic-restricted-modules is configured?
<infinity> mdz : Dependencies would be nice, but anna doesn't quite deal with them as expected anyway, so fixing that particular warty can wait for dapper.
<infinity> mdz : So Kamion tells me.  It should unpack them in alphabetical order (oo, how frightening is that?)
<Kamion> in practice anna unpacks stuff (and configures, for non-menu-item packages) in Packages file order
<mdz> I don't think it would be wise to force this into breezy at this point
<Kamion> which is sucky, but no way am I fixing it now
<Kamion> mdz: we can incorporate these changes into breezy, but not raise the priority of the udebs
<mdz> yes, that's fine
<Kamion> mdz: that will have zero effect on our current installer, but allow us to give people a boot option that will make atheros work
<Diziet> The debdiffs between Debian and the proposed upload and between Breezy and the proposed upload of gs-gpl look as I'd expect.
<infinity> mdz : So, I'm okay to upload these, then, and the priorities will determine if stuff gets used or not?
<mdz> infinity: sounds good
<Kamion> Diziet: gs-gpl> yes, based on the previous discussion we had
<Diziet> kamion: Right.
<spayne> jdub: do you know at what stage Tango is at?
<mdz> infinity: surely this uses a ridiculous amount of memory in the installer
<bddebian> elmo is back to doing all the syncs right?
<mdz> oh, I suppose it's nvidia and ati which are huge
<mdz> ath_hal is fairly small
<infinity> mdz : Quite, yes.
<infinity> (Hence why we shrunk the udeb)
<mdz> infinity: if lrm-manager fails, will it bring down the postinst (and the installer) with it?
<spayne> weird thing
<spayne> why for some, is it called Trash and others Wastebasket
<spayne> is this a bug?
<spayne> which should it be?
<infinity> mdz : Note the liberal sprinkling of || true in the two places where it might fail for odd reasons.
<infinity> mdz : (Well, the true on the touch is necessary because busybox just plain can't do that, the ||true on the ld call is my own paranoia)
<mdz> infinity: right, but even safer would be to wrap the lrm-manager call itself
<infinity> There is no lrm-manager call, lrm-manager is installed as the postinst.
<mdz> oh, you made lrm-managre the postinst
<mdz> eek
<mdz> infinity: have you tested this?
<infinity> It seemed a very di-ish thing to do.
<infinity> Not in an installer image, but I've tested lrm-manager-commands-in-busybox
<jdub> spayne: kicking off, with a fair few icons done
<spayne> jdub: it sounds like a good project
<spayne> jdub: do you know about this wastebasket thing?
<Kamion> the postinst will definitely get run at what seems to be an appropriate time (during the anna run)
<ogra> spayne, i dont think its at a stage where you should file any bugs about stuff yet ;)
<ogra> spayne, its *very* young
* ogra <- dogwalk
<mdz> Diziet: please send a debdiff for gs-gpl 8.01-5ubuntu4
<spayne> ogra: i'm talking about Breezy man!
<infinity> mdz : Kamion's giving me a recipe to do a local test right now.
<spayne> ogra: on dist-upgraded from Hoary, it is called Trash
<spayne> ogra: but on fresh installed, it is called Wastebasket
<spayne> has anyone seen this one?
<jdub> spayne: wastebasket?
<Lathiat> we're moving to malone after breezy?
<jbailey> spayne: Are you sure you selected the same locale?
<jdub> oh, that's the non-US name for 'trash' :)
<jbailey> spayne: From a terminal "set | grep LANG" would tell you. =)
<\sh> mdz: ping
<mdz> \sh: yes?
<\sh> mdz: http://bugzilla.ubuntu.com/show_bug.cgi?id=16375 <- see last comment...what are you saying? (amarok)
<mdz> \sh: there are no comments from me in that bug
<spayne> jbailey: i have a dist-upgraded on my ibook and it says trash
<spayne> jbailey: the rest say Wastebasket
<\sh> mdz: yes, I'm asking you about a comment...for me it's a nogo to include a new untested amarok
<mbreit> infinity: thanks for fixing my problem!!! (well... what was the problem??)
<jbailey> spayne: Right.  But it's still worth checking to make sure you have the same locale set.
<pitti> @all: if package foo version 1 Replaces: foo (<< 1), will that hurt in any way?
<jbailey> spayne: My best bet is that you don't.
<mdz> \sh: if you feel that it should not be included, then I will not argue with you
<spayne> jbailey: they both say LANG=en_GB.UTF-8 and LANGUAGE=en_GB:en
<\sh> mdz: what do you feel? I'm scared...cause 1.3.1 gave me enough paine
<infinity> mbreit : Not sure right now, actually.  It's a bug we need to debug post-release, right now I just worked around it.
<infinity> mbreit : it's a bug in either scons, ccache, or our crazy gcc wrapper.  Or all three.  Or something else.  I'm undecided at this point.
<pitti> Kamion, mdz: I'm building new langpacks now; I expect to have them ready in about 1 hour; is uploading ok for you?
<mbreit> infinity: okay.... if I can help there just ask... and thanks again for fixing it
<spayne> jbailey: ping
<Phanatic> hi all
<mvo> mdz: I need to revert a launchpad-integration fix: http://people.ubuntu.com/~mvo/launchpad-integration_0.0patch26+mvo20-0ubuntu2.debdiff, it seems to cause problems with gnome-terminal (because it has a different implementation of menu accelerators). this will bring back ugly warnings, but it fixes a (rare) crash
<jbailey> spayne: I'm still trying to think of what else is likely.
<mvo> mdz: is that ok with you?
<\sh> bah...I'll package a new amarok...and lets see
<\sh> the bugfixes are more interessting then the ipod issue
<spayne> jbailey: i think it could be something in gconf or .gnome
<jbailey> spayne: what happens if you force the language with gdm on each of those?
<spayne> jbailey: how do i do that?
<jbailey> spayne: The gdm screen has a languge option near th bottom.
<mdz> Diziet: eek, only 8.01-5ubuntu4 was in the .changes (you forgot -v)
<Diziet> mdz: Um ?  -v on debdiff ?
<mdz> Diziet: on dpkg-genchanges
<mdz> for the actual upload
<spayne> jbailey: trying now
* Diziet double-checks the script.
<mdz> Diziet: oh, -5ubuntu3 is already in the archive (I guess Kamion approved it?)
<Diziet> Yes, a little while ago.
<Diziet> But ubuntu3 is broken because it's missing the change in ubuntu1.
<mdz> you sent a diff for 8.01-5 -> 8.01-5ubuntu4
<Diziet> I sent two diffs in the same mail.
<Kamion> there's nothing in my shell history approving gs-gpl
<mdz> so you did
<Diziet> 13th of September.
<Kamion> though it might have overflowed
<Diziet> The first one is from the Debian version, indeed.  Mainly because ubuntu3 to ubuntu4 is scarier than Debian to ubuntu4.
<mdz> Kamion: nor mine
<mdz> how long ago was -5ubuntu3?
<Diziet> 13th of September.
<mdz> oh
<mdz> well that explains
<Kamion> mdz: I have some oem-config, localechooser, and kbd-chooser changes on the way to fix #17366; they have no effect on the normal installer, despite changing localechooser and kbd-chooser
<Kamion> (i.e. they're only the oem-config hooks for the latter)
* infinity waits patiently for the :33 cron.daily...
<mdz> Kamion: I'm happy to eyeball them as a sanity check
<Kamion> thanks
<Kamion> I can only apologise for not sorting out translation earlier
<Kamion> I think I also need to arrange for oem-config-firstboot to refuse to drop you to a login prompt until you've created a non-system user
<Kamion> today I managed to cancel my way out of oem-config only to arrive at a login prompt on a system which had no users with configured passwords
<mdz> seb128: gnome-vfs2 approved, thanks
<paulproteus|jhu> There is a very important bug with Ubuntu PowerPC in Breezy.  pbbuttonsd does not start because it does not find /dev/mixer and /dev/dsp .  These are created on "modprobe snd-pcm-oss" and "modprobe snd-mixer-oss".
<paulproteus|jhu> Without pbbuttons running, sleep does not work, which is how I noticed this.
<paulproteus|jhu> After running those two commands, and doing sudo /etc/init.d/pbbuttons start, sleep works fine.
<paulproteus|jhu> Breezy is coming out extremely soon - whose attention can I bring this to?
<crimsun> does pbbuttonsd use an initscript?
<paulproteus|jhu> crimsun, Yes.
<dilinger> ooh
<dilinger> seb128: any particular reason we're not building totem-{gstreamer,xine} w/ --enable-mozilla and --enable-nautilus?
<crimsun> paulproteus|jhu: what is its numbering relative to hotplug and to alsa-utils?
<mdz> paulproteus|jhu: I have a very good friend who works at JHU
<dilinger> neat, it works
<pitti> uh - libmad0 is still in main - I though that should disappear?
<silbs> mdz: did keybuk talk to you about fixing the network config delay at boot?
<mdz> silbs: how recently?  I thought he had fixed it last week or so
<mdz> silbs: if not, it's entirely too late now
<silbs> mdz: yesterday.  
<silbs> it's not fixed now
<silbs> he said he knew how to fix it and needed to talk to you
<mdz> silbs: no, not yesterday (I was ostensibly on holiday, though I was around most of the day)
<silbs> it slows down boot by over a minute. 
<mdz> I haven't heard about it from anyone other than you; it certainly doesn't affect any of my test systems
<silbs> there are a couple other very obvious, user-facing bugs I've been watching that aren't fixed yet - shall I start questioning those?
<mdz> silbs: I plan to start building candidate ISOs today
<mdz> for release in <48 hours
<silbs> mdz: it happens to claire too, don't know about others. Scott says it is leftover "auto eth" lines in interfaces file
<paulproteus|jhu> mdz, Cool!  Who do you know who works at JHU?
<silbs> mdz: about ubuntu still doesn't work
<silbs> mdz: we put an evolution icon on the panel that doesn't work
<mdz> silbs: about ubuntu should have been fixed today
<ogra> silbs, not with the update from today (about ubuntu ?)
<mdz> silbs: the evolution panel icon has worked fine in all my tests to date; can you be more specific?
<silbs> cllick icon, error msg "failed to execute child process evolution-2.2". seb128 knows about it
<ogra> mdz, have you clicked it 
<mdz> ogra: yes, on the RC live CD
<mdz> on 3 architectures
<mdz> silbs: hmm, that sounds like a post-RC change that seb128 made
<silbs> ogra: I updated this morning (my time) and it doesn't work. If it went in sometime today then I don't have it yet
<pitti> FWIW, I always test evo on my live CD tests; WFM
<mdz> silbs: and assured me it would have absolutely no visible impact :-P
<paulproteus|jhu> crimsun, Let me check.
<silbs> mdz: the evolution problem has been there since I started using breezy (preview-ish time)
<mdz> silbs: then probably something is not fixed on upgrade; it had been fixed for new installs for ages
<vuntz> silbs: did you upgrade from hoary?
<silbs> mdz: yes, it is an upgrade issue. But we have lots of people who upgrade.
<mdz> silbs: did you file it in bugzilla at preview-ish time?
<silbs> mdz: yes
<silbs> yes to upgrade, and yes I filed it
<mdz> silbs: there are upgrades, and there are upgrades to pre-release versions
<paulproteus|jhu> crimsun, postinst contains "update-rc.d pbbuttonsd defaults 12 >/dev/null
<paulproteus|jhu> "
<vuntz> mdz: it's most probably because evolution .desktop file calls the versioned evolution binary
<vuntz> (evolution is broken, yes)
<paulproteus|jhu> crimsun, Problem is, even after the system is fully-booted, my iBook doesn't have snd-pcm-oss or snd-mixer-oss loaded
<ogra>  vuntz and we have this issue every release
<crimsun> paulproteus|jhu: what sound driver is loaded?
<vuntz> seb128 should install a evolution-2.2 symlink
<paulproteus|jhu> crimsun, snd-powermac , iirc
<vuntz> ogra: will be fixed in 2.14
<paulproteus|jhu> (I'm not currently at it.)
<ogra> i remember it from warty and i remember it from hoary
<vuntz> ogra: I flamed evo people and they'll change it ;-)
<mdz> silbs: sometimes we can only fix the upgrade after the fact.  this is all guesswork, though, since I don't know for certain what the bug is
<ogra> vuntz, yay
<crimsun> paulproteus|jhu: hmm, is snd-powermac loaded automatically? (it should be)
<paulproteus|jhu> crimsun, Yes.
<paulproteus|jhu> But snd-mixer-oss and snd-pcm-oss aren't.
<silbs> mdz: whenever I bring this up people say "we know about that, we've had that problem before, we need to add a symlink for the update in ersion nnumbers"
<crimsun> paulproteus|jhu: ok. You should be able to work around that for now by placing snd-pcm-oss in /etc/modules
<silbs> mdz:  but as is, for a large number of users (people who upgrade), one of the few icons we put on the panel doesn't work.
<paulproteus|jhu> crimsun, I can work around it myself.
<paulproteus|jhu> crimsun, It's for the release that I'm worried.
<mdz> silbs: well the bug (10164) has been marked "pending upload" for 5 months
<zyga> uhh
<zyga> does ubuntu use any library prelinking?
<Mithrandir> no
<silbs> fyi - elmo just updated and says the about ubuntu one is fixed
<elmo> the evolution-2.2 one probably isn't fixed
<elmo> as I just updated and there isn't an 'evolutuon-2.2' command
<vuntz> seb128 just added the evolution-2.2 .desktop file, I think
<vuntz> he didn't think about the binary
<mdz> elmo: yes, see 10164
<crimsun> paulproteus|jhu: that reeks of update weirdness; snd-pcm-oss should be loaded automatically due to line 12 of /etc/modprobe.d/alsa-base
<mdz> vuntz: why isn't the launcher on the panel just updated on upgrade?
<paulproteus|jhu> crimsun, Okay.  Then perhaps that's the cause.
<mdz> that would be much more elegant than adding symlinks
<crimsun> paulproteus|jhu: (basically, if you have snd-powermac loaded, you have snd-pcm loaded, and snd-pcm-oss is loaded directly after snd-pcm is loaded)
<fabbione> mdz: aren't the panel thing added to ~/.gnome* ? if so i am not sure how you can do that cleanly without treating them as config file
<fabbione> mdz: that might be why they are not updated automatically
<vuntz> mdz: the launchers on the panel are referenced in gconf
<ogra> fabbione, thats not how gconf works... 
<vuntz> mdz: it's user data
<paulproteus|jhu> crimsun, Glad to hear this won't affect others, then.
<vuntz> it can not be upgraded that easily :/
<ogra> vuntz, not if its a global setting
<vuntz> ogra: the reference to the launcher is in gconf
<fabbione> ogra: similar concept
<vuntz> the default launchers are in /usr/share/applications, though
<vuntz> so evolution-2.2.desktop should use the evolution binary (not evolution-2.2)
<ogra> if i have a global setting normally no user setiing is created for it unless i change something, no ? 
<vuntz> ogra: wrong for the panel :-)
<vuntz> mdz: I suppose it doesn't work for people who manually created a new launcher for evolution
<mdz> vuntz: I don't think silbs manually created a new launcher
<ogra> uhh, odd... we should use the cdd gconf dirs for that instead
<vuntz> mdz: well, it must be
<vuntz> mdz: because it's not using the .desktop that's in /usr/share/applications
<silbs> vuntz: no, I didn't create a new one. 
<dholbach> vuntz: /usr/share/applications/evolution-*.desktop has Exec= evolution-2.4 (or 'evolution --component=mail')
<silbs> we had one there by default in earlier versions (to the left of the life preserver).
<vuntz> silbs: can you do: "grep evolution ~/.gnome2/panel2.d/default/launchers/" in a terminal?
<vuntz> dholbach: indeed. That's why I'm saying silbs is not using the default launcher :-)
<TMM> hey, I've got some ideas on some enhancements I want to have in dapper, and I am willing to implement them myself too. What is the way to go about this? I don't really want to implement the tools I would like to see only to find out that they are not going to be accepted. I know the usual way of these things is 'show us the code' :)
<TMM> opening a wishlist bug perhaps? but I don't really want someone else to do it :) and I don't want to give people that impression :)
<silbs> vuntz: /home/jane/.gnome2/panel2.d/default/launchers/eek-00480999d8.desktop:Exec=evolution-2.2
<TMM> (not that I'd mind someone else implementing somethings though) :)
<fabbione> TMM: this isn't exactly the right time to discuss dapper
<vuntz> silbs: so you manually added the launcher to the panel :-)
<fabbione> TMM: we are very close to release and we are all overbloated of work
<TMM> whoops, sorry
<dholbach> TMM: IdeaPool on the wiki maybe
<silbs> vuntz: I really didn't.  I did add other launchers to the panel, but not that one
<fabbione> TMM: please stick all your ideas on the wiki
<fabbione> TMM: so that nothing will get lost
<dholbach> TMM: and if it's desktop related, DesktopTeamVisions, thank you :)
<TMM> fabbione, ok, I just want to know the prodcedure :) not discuss the ideas, I know you are busy :)
<TMM> carry on :P
<TMM> ;)
<dholbach> the only option in the evolution issue seems to a symlink
<elmo> sorry - not being funny, but what does it matter whether or not it was user added?
<silbs> vuntz: and frankly, even if I did add it myself (which I didn't :) ), it should still work
<TMM> btw, anything I can do or test? if people are overbloated, perhaps there's some things that non-authorised people can take over?
<vuntz> silbs: I'm pretty sure you added it :-)
<vuntz> silbs: but it should work, yes
<elmo> vuntz: I'm pretty sure she didn't
<elmo> vuntz: we have other people in the office with the same symptoms
<vuntz> elmo: well, the file can not appear without user interaction
<elmo> vuntz: sigh
<vuntz> or a script installed it
<elmo> anyway, this is STILL missing the point
<zyga> I modified libgnome-desktop but I have trouble actually seeing any changes, is there something tricky I need to do to make all binaries use this modified library?
<TMM> I couldn't quite get the hang of the FTBFS list for universe, a lot of stuff didn't really seem broken, and I don't have an AMD64 box
<TMM> :)
<elmo> why can we not just add the symlink and be done with it?
<elmo> it's a one line change
<vuntz> the point is that someone should add a evolution-2.2 symlink
<dholbach> TMM: that's for #ubuntu-motu
<zyga> I've tried make install and building & installing 
<vuntz> (and probably a evolution-2.0 symlink too, btw)
<TMM> dholbach, I know, I just made an example :) asking for something else that would be useful
<seb128> re
<seb128> dilinger: what? we use mozilla/nautilus
<seb128> mdz: thanks for gnome-vfs2
<seb128> vuntz: that doesn't work, it gives 2 menu entries, I already said it to you yesterday
<vuntz> seb128: if you added a symlink for the *binary* ?
<vuntz> s/added/add/
<fabbione> mdz: may i suggest you add also an evolution -> evolution-$latest? so we can get over this transition in the next release?
<dholbach> as i see it evolution-2.{0,2,4} weren't installable anyway, so that should be no problem to do
<mdz> fabbione: that has always been there
<fabbione> mdz: like changing the .desktop to point to evolution (neutral version)
<dholbach> ... parallel ...
<fabbione> ah ok
<mdz> fabbione: the problem is that the .desktop file points to evolution-<ver>
<seb128> silbs, mdz: the change was supposed to fix that
<fabbione> mdz: yes.. we should make it neutral
* jdub flames the evolution team who do not think this is a problem
<vuntz> fabbione: evolution people will fix this for 2.14
<jdub> vuntz: finally?
<silbs> seb128: it didn't
<seb128> vuntz: why, evolution-2.2.desktop has Exec=evolution-2.4
<vuntz> jdub: yes, I flamed them :-)
<mdz> jdub: they get the rusty trowel award
<jdub> vuntz: sweet, well done :)
<vuntz> seb128: .desktop files added by the user :-)
<dilinger> seb128: sorry, was looking at older packages
<dholbach> seb128: some dekstop entries still have evolution-2.2
<seb128> fabbione, mdz: it is neutral now, issue is upgrades from hoary
<mdz> seb128: silbs' launcher still tries to run evolution-2.2
<seb128> dholbach: not everybody to the same time please
<mdz> seb128: and it doesn't seem neutral now either
<mdz> grep Exec /usr/share/applications/evolution-2.4.desktop
<mdz> Exec=evolution-2.4
<seb128> mdz: panel uses /usr/share/applications/evolution-mail.desktop
<seb128> with new installs
<mdz> ok
<mdz> /usr/share/applications/evolution-2.2.desktop:Exec=evolution-2.4
<mdz> /usr/share/applications/evolution-2.4.desktop:Exec=evolution-2.4
<mdz> /usr/share/applications/evolution-mail.desktop:Exec=evolution --component=mail
<seb128> we use -mail now which is neutral
<dholbach> the problem are older launchers in ~
<seb128> for update as I understand it the panel looks for evolution-2.2.desktop
<seb128> and I've made <mdz> /usr/share/applications/evolution-2.2.desktop:Exec=evolution-2.4
<seb128> vuntz: any other option?
<seb128> dholbach: I can't change ~ datas from the package
<dholbach> seb128: what about providing /usr/bin/eovlution-2.2 in a symlink?
<dholbach> evolution
<seb128> we can do that right
<seb128> so we have 3 binaries *g*
<mdz> seb128: I uploaded evolution with an evolution-2.2 -> evolution-2.4 symlink
<Amaranth> dholbach: iow, the problem is smeg users who messed with the evolution menu entry :)
<seb128> mdz: thanks
<mdz> I hope it doesn't break any interesting upgrades
<janimo> elmo, please sync wdm, override ubuntu1
<vuntz> seb128: only option is symlink, I suppose
<Amaranth> although something with a different binary name for every release should probably be considered broken (if they don't make a symlink)
<seb128> vuntz: we agree that we need alternatives for both the desktop and the binary?
<vuntz> yes
<seb128> k
* seb128 kicks Novell guys
* ogra helps kicking :)
* Amaranth kicks ogra
<seb128> and after that they try arguing against providing an non-versionned version
<ogra> ouch
* bddebian joins the fun
<Amaranth> seb128: What, do they call it user error?
<zyga> hey all the kickers
<Amaranth> holy shit, class started 7 minutes ago
<speel> lol
<Lathiat> haha
<seb128> mdz: I would rather close #10164
<seb128> mdz: since the panel config uses evolution-mail which is neutral now and we ship the 2.2 variant for hoary updates ...
<mpt> TMM: In one sentence, what's the enhancements you'd like to implement?
<\sh> mdz: I have to revert my opinion about amarok-1.3.3..it's much more stable then 1.3.1 will ever be
<mdz> seb128: ok with me if you are happy with my horrible 
<mdz> hack
<bddebian> \sh: :)
<seb128> mdz: there is no other way afaik, those are user datas stored to gconf, we can't update them from the package ...
<TMM> mpt, X configuration stuff, a'la sax but working and implemented in pyglade (so it looks good) and fallback X server on vesa in 640x480 because right now people's setups get completly borked if they switch videocards
<silbs> goodnight guys, thanks for all your work
<TMM> mpt, that fallback X server would be to run the aforementioned tool :)
<\sh> bddebian: serious...this is really serious 
<bddebian> \sh: That :-)  Was a "good" :-)
<kikidonk> dholbach: ping ?
<dholbach> kikidonk: pong
<kikidonk> ha !
<dholbach> :)
<kikidonk> do you think it would be wise to release another deskbar ?
<\sh> bddebian: oh :) sorry :)
<dholbach> kikidonk: i'm not the maintainer anymore, Mithrandir just overwrote it, we're now the deskbar-applet team :)
<bddebian> heh
<bddebian> dholbach: Dan man, how many teams are you on? :-)
<bddebian> Err s/Dan/Dang/
<dholbach> bddebian: :)
<mpt> TMM: ok, that seems like https://wiki.ubuntu.com/XConfigurationModification
<mdz> \sh: so it seems that it was a mistake for me to allow 1.3 in the first place
<mpt> TMM: So maybe you want to complete that spec, and I could help push it through the review process at Ubuntu Below Zero
<mpt> (assuming you're not going yourself)
<\sh> mdz: I think "no", because the people wanted it, but I'm not in adventuring mode, so I'll let it test by others until tomorrow...whole kubuntu-devel team is on it ;)
<mdz> \sh: I have tried to be flexible about kubuntu in order to accodomate the KDE community, but as long as they aren't stabilizing at the same time that we are, it isn't really going to work
<mdz> \sh: we are now at a point where if you change it, and it's worse than what we already have, there is no time left to fix it
<\sh> mdz: so I think it would be better to ship 1.3.3 then 1.3.1 (serious now), because most of the patched stuff from riddell is now fixed in upstream and even the ipod generation is happy
<ogra> \sh, whats wrong with 1.3.1 i only heard good things until now...
<mdz> \sh: in other words, you have exactly one chance to get the absolute final version right.  first try.
<mdz> \sh: and if it isn't right, then kubuntu 5.10 will suffer
<\sh> mdz: as I said, my decision will be made tomorrow lets say 12 UTC
<mdz> \sh: tomorrow is too late
<\sh> ok..give me at least 22 UTC
<mdz> it is already too late
<TMM> mpt, I'll start by finishing the spec then, I have been fixin Xfree and Xorg problems for years now here on freenode, and I think I've got a pretty good idea of stuff that goes wrong, and the stuff you don't get bugreports about because people give up (non working mouse, display frequency trouble etc) 
<TMM> mpt, thanks, I'll work from here
<TMM> mpt, bbl :)
<mpt> TMM: no problem, and welcome
<mdz> \sh: either upload it now, or don't.  but if it's wrong, I will not be able to help you.  I will be busy with the Ubuntu release
<\sh> mdz: 22 UTC that's 24:00 my time...I'll decide...and we can talk again, deal?
<mdz> \sh: so you need to decide whether you trust amarok upstream enough to risk the Kubuntu release
* \sh is looking into a mirror...and is watching a 34 year-old-guy who can fck or unfck a complete release 
<mdz> \sh: personally, i think that a botched release might be a good lesson for the community.  I'm not willing to risk Ubuntu to teach that lesson, but if you want to use Kubuntu for that...
<mdz> \sh: I assume Riddell agrees with you?
<fabbione> \sh: sometimes a stable release implies to have software that is bugged. better bugged but predictable behaviour than a bugged unknown behaviour
<fabbione> \sh: it happens with much more important pkgs than amarok all the time
<fabbione> \sh: see the kernel
<\sh> fabbione: believe me when I say, that I have really serious stomach-paine, and that I'm running every bloody 5 mins to toilet to pray to montezuma
<ogra> segfault, building xscreensaver :)
<mdz> Kamion: do you have an ETA for those oem fixes?
<fabbione> \sh: yes i understand.. what i am suggesting is a safe path..
<fabbione> \sh: you know where you are now, you won't know where you will be in 5 minutes (other than the toilet i mean)
<Kamion> mdz: I think they're about as good as they're going to get now; uploading in a few minutes
<mdz> Kamion: my eyeball offer still stands
<Kamion> can you eyeball them from queue/accepted, or do you want a diff first?
<Loevborg> Is there a good reason for installing locate (slocate) by default (even run daily)? (please tell me if this is not a good place to ask)
<mdz> Kamion: doesn't much matter, I suppose
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/oem-config/
<mdz> Kamion: *whimper*
<Kamion> tell me about it
<Kamion> anything in particular that concerns you, or just the size?
<mdz> Kamion: why is the argument passed to translate_labels a dictionary, when translate_labels seems to only use it as a sequence?
<mbreit> is it a known bug that about ubuntu is broken?
<mdz> Kamion: size
<mdz> mbreit: it's a known _and fixed_ bug
<bddebian> mbreit: I think so
<Kamion>             widget.set_label(self.description(questions[label] ))
<Kamion> mdz: ^--
<Kamion> the argument is a map from glade widget names to the debconf question names whose (translated) descriptions should be filled in
<mbreit> oups... i think i did no dist-upgrade today... so sorry ;)
<mdz> Kamion: 'for label, question in questions' would be clearer, but ok
<Kamion> oh, fair point, my python-fu is not as strong as it might be
<Kamion> mdz: hmm, that doesn't work for dictionaries
<Kamion> I think it would have to be a sequence of tuples for that to work
<mdz> Kamion: .values()
<\sh> mdz: even if i'm being fcking wrong...and I'll get all the amarok fans against me...1.3.1 will be shipped...and I don't mind now Riddell's veto in this...I'll rather backport 1.3.x from dapper to breezy then taking a risk...thx for your ear..last line of gibberish you will hear for breezy about the amarok issue...
<mdz> er, .items() -> sequence of key, value
<mdz> \sh: you have my full support
<fabbione> \sh: wise choise
<Kamion> mdz: ah yes, that works
* \sh goes and will sit another 5 mins on the toilet...and let the tears out
<mdz> Kamion: it looks correct and still scares the bejeezus out of me
<bddebian> \sh: :'-(
<Kamion> oem-config scares the bejeezus out of me without even trying
<Kamion> but that's just the mad debconf use
<fabbione> Kamion: can't be THAT bed.. it managed to work for me.. 
<fabbione> s/bed/bad
<Kamion> um, yeah. dunno what to say. I've tested it as much as I can without building new images with the .debs; I can do that if you like, it'll just take a while
<Kamion> actually, if I built official images now (with the shadow fix from earlier today), I could test it just by dpkg -i'ing new .debs
<Kamion> mdz: (diff updated for the .items thing)
* Kamion goes to build fresh images
<\sh> bddebian: you read my blog article about MOTU work? With the upload rights, you'll have responsibilities? This is what I meant...and as I was telling ogra...I didn't even know parts of my body, that there are  perspiratory glands  
<bddebian> \sh: :-)
<mdz> Kamion: fire away
<mdz> Kamion: anything else pending before we do some CD builds?
<mdz> seb128: still here?
<mdz> seb128: you have one 5.10/PENDINGUPLOAD bug left
<Kamion> mdz: debian-installer build following the OEM changes
<mdz> seb128: http://bugzilla.ubuntu.com/show_bug.cgi?id=12336
<Kamion> (which is prepared and ready)
<mdz> seb128: now or never
<pitti> mdz: langpacks still need maybe 45 minutes until I fully reviewed and tested them
<mdz> hmm, looks like it's a "fixed upstream" rather than "ready to upload"
<Kamion> mdz: need new live filesystem image builds, too; I'll just check whether the amd64 image has been zeroed
<mdz> updated milestone
<Kamion> amd64/live should fit with the next build
<ogra> mdz, i have a last minute translation fix for pt_BR in xscreensaver, just testbuilding... am i to late ? 
<Kamion> mdz: nothing else on my list
<mdz> ogra: put it into rosetta instead
<mdz> it can go in a post-release langpack update
<ogra> mdz, thats wher i got the fix from
<mdz> rosetta data is exported to langpacks now
<mdz> either it's in pitti's new langpacks, or it will be in the next set
<mdz> no need to touch xscreensaver
<ogra> oh, ok... so i dont need to touch the code at all... silly me
<pitti> ogra: I don't have xscreensaver pt_BR
<pitti> ogra: I had to kick many many po files due to some Rosetta export bugs
<pitti> that's also why the langpack update was delayed so badly
<ogra> pitti, it was changed today
<pitti> ogra: ah, then no chance
<pitti> ogra: the tarball uses yesterday's data
<pitti> next update then
<ogra> pt_BR was heavily broken all translations were the same sentence for all mgsstrings :)
<ogra> pitti, is there to be one before release ? 
<pitti> ogra: no, after releas
<ogra> oh, and rosetta always makes it iso-8859-1 ... 
<pitti> ogra: but I can manually put in a new file or kill the existing one
<ogra> segfault, ^^^
<ogra> hmm
<jdub> hrm, firefox has started hanging really badly
<jdub> gettimeofday({1129058862, 863849}, NULL) = 0
<jdub> select(0, NULL, NULL, NULL, {0, 11000}) = 0 (Timeout)
<jdub> gettimeofday({1129058862, 874813}, NULL) = 0
<jdub> select(0, NULL, NULL, NULL, {0, 11000}) = 0 (Timeout)
<jdub> gettimeofday({1129058862, 885821}, NULL) = 0
<jdub> select(0, NULL, NULL, NULL, {0, 11000}) = 0 (Timeout)
<jdub> gettimeofday({1129058862, 896815}, NULL) = 0
<jdub> select(0, NULL, NULL, NULL, {0, 11000}) = 0 (Timeout)
<jdub> gettimeofday({1129058862, 907786}, NULL) = 0
<jdub> select(0, NULL, NULL, NULL, {0, 11000}) = 0 (Timeout)
<jdub> 
<ogra> uuh, whats that ? 
<jdub> strace -p $(pidof firefox-bin)
<fabbione> it's polling on a FD that timeouts and firefox probably doesn't check for that condition
<fabbione> = infinite loop
<jdub> nice
<jdub> it's happened 3 times in the last few hours
<j^> with flash animations i saw that quite often lately
<j^> but also the totemplugin(is that installed by default?)
<mdz> jdub: google video's .swf does something like that to the flash plugin when I close its tab sometimes
<jdub> hrm, was opening a new tab
<mdz> Kamion: I've drafted a https://wiki.ubuntu.com/BreezyTestPlan#preview ; feedback and edits welcome
<Kamion> mdz: oh, only other thing I know about is that initramfs-tools breaks with XFS /boot on powerpc
<Kamion> I doubt we'll have time to fix that, but dedicating somebody's time to investigating it would be good, if only for release notes
<mdz> Kamion: not a showstopper by any means as far as I'm concerned
<mdz> Kamion: definitely release notes caveat material though
<fabbione> oh crap
<fabbione> Diziet: ping???
<mdz> fabbione: don't say something like that during release prep unless you really mean it ;-)
<mdz> my poor nerves
<ogra> i guess he means it... ?
<fabbione> mdz: i meant it.. he did drop something on gs-gpl that made it break on sparc.. and crap at one day from release is the suck..
<fabbione> dunno what he changed.. but it hits an ICE on gcc
<mdz> fabbione: he mostly just restored older, dropped changes.
* ogra looks for the big 5l bottle of valerian to send via express to mdz
<mdz> fabbione: if gs-gpl is out of date on sparc, that is not the end of the world
<fabbione> mdz: no but it sucks that yet again for one package i can't make the full release
<mdz> ogra: I prefer the US equivalent, bourbon
<fabbione> and that's really annoying for a last minute fuckage 
<mdz> fabbione: gs-gpl is not even part of the default install
<ogra> mdz, lets have some at UBZ... :)
<fabbione> mdz: i know.. it's all of main that matters after one year of effort :/
<fabbione> bah
<fabbione> ok
<fabbione> we will ROCK dapper!
<ogra> yay
<mdz> fabbione: it isn't too late if you can fix it immediately ;we need another cron.daily anyway
* Kamion is syncing/burning as fast as possible
<Kamion> but will take a burn/install cycle before I can test these .debs
<fabbione> mdz: checking
<mdz> ogra: I brought some fine bourbon to debconf5, perhaps I can find some for UBZ as well
<ogra> yeah... i'm rather the scotch type, but i gues i just havent had the right bourbon yet ;)
<mdz> ogra: I enjoy scotch as well, but there is no point in me bringing scotch from the us which is imported from scotland ;-)
<Kamion> mdz: oh, one other thing; we have some space on the install CD now as a result of changes made to make the live CD fit. Do we want to put some language packs in?
<ogra> mdz, *G*
<mdz> Kamion: how much?
<Kamion> http://cdimage.ubuntu.com/daily/current/
<mdz> ogra: mjg59 and stargirl both brought excellent scotch to debconf5
<Kamion> 27MB, 47MB, 37MB
<ogra> damned, i need to go next time...
<Kamion> unexpectedly quite a bit, in fact
<mdz> Kamion: whoa, amd64 > powerpc now?
<Kamion> yes
<mdz> pitti: what langpacks could we fit in that space?
<Kamion> has been for a fair while, I think
<Kamion> there's about 10MB free on the i386 and powerpc live CDs
<mae> wazzup.
<pitti> mdz: I'd wait with the precise calculation until the new packs are in
<mdz> lamont/infinity: around?
<Kamion> new filesystems are building for amd64, which should get it under, but I don't think it'll be by much
<mdz> pitti: ETA still ~30m?
<lamont> mdz: ack
<pitti> mdz: yes
<mdz> lamont: can you confirm that release architectures are up-to-date?
* lamont looks
<mdz> Kamion: does that build have the fixed evolution x3?
<lamont> mdz: the only DC architecture currently building anything is ia6
<lamont> 4
<lamont> (yes)
<mdz> Kamion: not that it matters for purposes of the bug, but for up-to-dateness
<mdz> lamont: thanks
<Kamion> mdz: no
<lamont> mdz: btw, would be nice to let binary uploads for the other 3 finish before making breezy be read-only
<seb128> mdz: sorry I was away for dinner
<seb128> mdz: no, nothing pending from me
<mdz> seb128: ok, it was clear from reading the bug that it was not for 5.10
<seb128> yeah
* lamont wonders WTH put the versioned expect: dependency on binutils
<fabbione> mdz: 5 minutes max and i should know if it works or not (test building all over)
<mvo> mdz: I have a pending issue with launchpad-integration that I would like to upload very soon
<segfault> ogra: sorry, My connection sucks
<ogra> segfault, po files are completely handled by langpacks now...
<ogra> segfault, sorry, didnt know that...
<segfault> ogra: no prob.. should be one langpack release today, right?
<ogra> segfault, and the most recent translations that go into the langpack are from yesterday... :/
<Kamion> segfault: it'll get fixed in a langpack update after release; don't stress about it now
* pitti tests final langpacks with a reboot, brb
<thesaltydog> seb128, just to inform you that baobab now has an entry in gnome-bugzilla. Just in case you need, move bugs to there.
<fabbione> mdz: permission to upload gs-gpl. it's a no op for all arches. sparc switches to gcc-3.4
<fabbione> test builded on amd64/i386
<Kamion> http://cdimage.ubuntu.com/ubuntu-server/daily/current/report.html
<Kamion> hmm, odd
* Kamion ignores for just now
* fabbione fires up...
<fabbione> mdz: up to you if you want to reject it.. i will understand
<mdz> fabbione: fine with me
<mdz> it's not on the CD
<fabbione> o
<fabbione> k
<fabbione> i care relatively 0 about CD given apt borkage on deb file://
<Kamion> ogra: (this xscreensaver fix *is* in a .po file, not in a .desktop file, right?)
<ogra> yep
<Kamion> ok
<pitti> mdz: ok, this was a lot of manual surgery and hacking, but the packs look good now
<Riddell> Kamion: the contents of the kubuntu live CDs havn't changed in some days, is it possible to get them rebuilt? (I know you don't control the whole process there but I'm not sure who does)
<mdz> Kamion: curious
<mdz> Riddell: that's not a good sign; usually that means it's been failing
<mdz> unless lamont/infinity disabled the automatic builds
<mdz> which would be entirely appropriate
<Kamion> Riddell: that's strange; there have been successful automatic Kubuntu live filesystem builds for the last several days on all architectures
<Kamion> automatic daily d-i builds have been disabled, but not the live filesystem builds
<seb128> thesaltydog: thanks
<thesaltydog> seb128, np
<pitti> mdz: ok to fire langpacks?
<Kamion> ah, the kubuntu daily-live CD builds haven't happened
<mdz> pitti: go
<lamont> mdz: not disabled
<Kamion> http://www.theopencd.org/winfoss/kubuntu/Kubuntu-WinFOSS-5.10.tgz:
<Kamion> 06:32:09 ERROR 404: Not Found.
<Kamion> hno73: ?
<mdz> lamont: could you disable then, please?
<segfault_> ogra: oops, continuing
<Kamion> ah, my typo
<segfault_> ogra: can you at least fix the desktop entry?
<Kamion> hno73: never mind
<lamont> ppc built kubuntu-live fs ~16 hours ago
<Kamion> lamont: iz my fault, not yours
<lamont> ah, ok
<segfault_> ogra: the translated entry is UTF8 while the desktop entry is ISO
<ogra> segfault, yes, because th po file is iso
<lamont> mdz: livecd fs build for all 3 images getting disabled now.
<ogra> the new one i got from rosetta was again iso
<Kamion> Riddell: fixed, sorry about that
<lamont> disabled.
<mdz> lamont: thanks
<Riddell> Kamion: can you set off a new build now?
<lamont> Kamion: please remember to do a "BuildLiveCD base" for the final images, which will need to get published somewhere and pointed to by the LiveCDCustomization page
<Kamion> Riddell: fresh build running now
<Riddell> Kamion: excellent, thanks
<Kamion> lamont: damn, yeah, I really need to sort that out on cdimage
<hno73> Kamion: OK, cool. I'm around if there are issues though
* Kamion moves it to a more prominent position in his todo list
<Kamion> hno73: thanks
<lamont> 635814893 is the magic am64-live number, btw.
<segfault_> ogra: thats strange
<segfault_> ogra: oops, weird.
<segfault_> i did entirely in UTF8
<Kamion> lamont: doesn't seem to have shrunk at all?
<lamont> 100KB or so
<Kamion> lamont: that's ridiculous; we took 2.5MB out of the contents
* lamont hasn't compared .outs
<mdz> Kamion: not entirely surprising for amd64, since it doesn't get zeroed
<Kamion> mdz: lamont explicitly zeroed it, apparently
<lamont> mdz: that was after zeroing
<segfault_> ogra_: how can we fix that?
<mdz> oh
<lamont> or at least after what we assert is zeroing...
<lamont> Kamion: want me to do another build explicitly nuking it to see if it makes a diff?
<Kamion> 20051011, 20051011.1, and 20051011.4 are all the same size within a megabyte, despite the first having python2.4-opengl and the other two not, and the last one being zeroed
<Kamion> lamont: yes please
<lamont> and then move the old old- back into place?
<lamont> ok
<Kamion> only move the old old- back into place if it doesn't make a difference ...
<ogra> segfault_, it will be fixed with the next langpack update... soon after release i cant do much, the .desktop strings are generated
<Kamion> segfault_: .desktop files are not in langpacks
<Kamion> ogra: ^--
<Kamion> (oopS)
<ogra> hmm
<lamont> if we use this now-in-progress image, it'll be rsync-unfriendly
<ogra> the .desktop file is empty... i'll check
<Kamion> that's fine, as long as it's now and not release day
<mdz> mvo: talk to me about this launchpad-integration upload
<mvo> mdz: the problem is that the current version of lpi triggers a segfault in gnome-terminal (#17309)
<segfault_> ogra: thanks
<mvo> mdz: the old version (that we had in -rc) gives ugly warnings but doesn't trigger the bug and gnome-terminal works fine
<mvo> mdz: the segfault dosn't happen a lot and is hard to reproduce but it happens for people (depending on their working pattern ~1-3 times a day)
<mdz> mvo: diff?
<mvo> mdz: I don't think it's a bug in the lpi change but a different problem that is triggered by the change
<mvo> mdz: http://people.ubuntu.com/~mvo/launchpad-integration_0.0patch26+mvo20-0ubuntu2.debdiff
<mdz> I haven't had it crash at all
<zyga> mvo: might be related to this crash
<mdz> mvo: ok, approved, but this means we need to do another set of livefs builds
<zyga> mvo: are menu items populated in a async fashion?
<mdz> mvo: I hope you are staying around to help test them ;-)
<lamont> Kamion: for purposes of the exercise, I'll assume that >500KB is "different"
<mvo> mdz: try opening a lot of gnome-terminals (with CTRL-SHIFT-N). you need around ~50. then close them and open them again
<zyga> mvo: (in gnome-terminal)
<mvo> mdz: promised
<pitti> mdz: don't we need another build anyway to fit more langpacks?
<mvo> zyga: I don't think so, why?
<Kamion> lamont: to make it fit, I need at least two megabytes
<mdz> pitti: I was only planning to add them to the install CD
<mdz> pitti: adding them to live requires a metapackage update
<pitti> mdz: ok
* lamont grumbles at his house connectivity dropping yesterday/today
<zyga> mvo: type something that looks like a link and right-click on it repetadly
<lamont> Kamion: ok
<mdz> pitti: do you have a list?
<zyga> every 10 clicks or so I can get stuff like duplicated 'open this link' items
<pitti> mdz: I can generate one
<zyga> or items in random order
<pitti> mdz: all langpacks uploaded now
<lamont> elmo: ping
<mvo> mdz: sorry for the trouble (and the late upload). I hoped until now to find the real cause of the problem so that it can be fixed properly (instead of just not triggering it)
<mvo> :/
<mvo> zyga: -> #ubuntu-desktop?
<pitti> mdz: how much space do we have?
<Kamion> pitti: 20:48 < Kamion> 27MB, 47MB, 37MB
<Kamion> amd64, i386, powerpc respectively
<Kamion> pitti: I'd appreciate it if you could stay 5MB or so clear of the limit, to avoid last-minute problems
<pitti> ok, I can make a list based on current (not new) langpacks
<pitti> the new packs are not considerably bigger, so I just leave some safety margin
<Kamion> add that safety margin to 5MB :-)
<pitti> right, of course
* Kamion wants space for other last-minute weirdnesses, just on the off-chance
<pitti> so I'll leave 7 MB?
<Kamion> should be fine
<pitti> so that is nice: 20, 40, 30 MB :-)
<fabbione> jdub: ping?
<elmo> lamont: ?
<mdz> pitti: finished?
<mdz> pitti: (uploading)
<pitti> mdz: yes; 22:20 <pitti> mdz: all langpacks uploaded now
<pitti> mdz: not sure whether all of them are in accepted already, though (but should)
* Kamion taps fingers waiting for localechooser to build
<elmo> grr
<elmo> NEW packages _now_? :P
<mdz> pitti: there's nothing left in unchecked, and I've processed everything from accepted
<elmo> I assume these want to go into main?
<pitti> great
<mdz> pitti: -fo is new, eh?
<Kamion> Riddell: you have new kubuntu/daily-live builds
<pitti> mdz: oh, hm, entirely possible
<Riddell> and i386 is even undersized
<pitti> mdz: drop it if it creates trouble
<Riddell> thanks Kamion 
<mdz> elmo: (yes)
<mdz> pitti: seed it
<mdz> Kamion,Riddell: kubuntu-live wants to move into universe; bad seed merge?
<lamont> elmo: nm
<pitti> elmo, mdz: seeded
<Kamion> mdz: oh, yeah, my fault, fixing
<pitti> elmo, mdz: oops, wait, commit failed; gimme 1 minute
<pitti> elmo, mdz: -fo committed
<mdz> pitti: and the new packs for the install CD?
<ogra> mdz, looks like there are some people upset with the broken pt_BR tanslation (see -devel and the bug)... Kamion said .desktop files are not handled by .po files and i have the fix ready for upload here...
<ogra> (tesbuilt and tired)
<pitti> mdz: shall I commit the seed changes directly? or do you wnat to take a look at the diff?
<mdz> ogra: you said a few minutes ago that this was not a .desktop file
<mdz> pitti: go ahead
<mdz> ogra: which bug?
<ogra> mdz, the translation stuff for that .desktop file is in the po
<ogra> 16448
<Kamion> oh, what's wrong with the timezone screen now
<ogra> mdz, i wasnt aware that .desktop files are not handled by langpacks... the .desktop file in the source is empty (us only) inded 
<mdz> ogra: upload it; if we need to build a new livefs anyway we will roll it in, otherwise target breezy-updates
<ogra> ok
<mdz> ogra: the situation with .desktop files is documented on the release schedule and has been for some time
<ogra> mdz, i'll read it immediately
<mdz> I also mentioned it in my release status update to -devel when the freeze date arrived
<mdz> Kamion: are the new ubuntu livefs builds ready?
<Kamion> mdz: yes
<Kamion> mdz: but probably not amd64
<mdz> Kamion: amd64 will need a new one, or has one already in progress?
<Kamion> mdz: in progress, lamont's doing it
<mdz> unless it's far along, we might as well redo all 3 and get xscreensaver and launchpad-integration in
<Kamion> ok, but I want to see the outcome of lamont's build for size purposes
<Kamion> oem-config etc. uploads coming up now; tested, and they worked with one small modification (reloading /var/lib/dpkg/info/base-config.templates because something seems to be trashing the translations from it in the templatedb, and I'm buggered if I'm going to track that down now)
<Florob> Sorry to bother you all with a silly user question, but nobody else seems to know: Is there any specific reason, why the caligula themes are not packaged for breezy, or is it just lack of time, or do I miss something obvious.
<pitti> mdz, Kamion: I added all langpacks to amd64 and i386, they don't even fill the CD up; powerpc is committed, too
<mdz> pitti: excellent
<pitti> mdz: the complete lack of langpacks on the live CDs is more worrying, but I guess it's too late for that
<Kamion> mdz: what about this xkeyboard-config thing in accepted? daniels checked it with a number of people, it apparently works on all arches, fixes a major bug, but I didn't want to touch the actual approval myself
<mdz> pitti: how much could we fit?
<mdz> Kamion: not touching it
<mdz> no bug refs in the .changes, diff is non-obvious
<mdz> too late
<Kamion> +    $threelevellayouts, although this is only cosmetic (closes: Ubuntu#13527).
<mdz> uploads at this stage are subject to the same criteria that breezy-updates will be
<Kamion> (point of information)
<mdz> so if it's safe for now, it'd be just as good after release
<Kamion> oh, the bug number was typoed
<pitti> mdz: none to amd64 apparently, four big ones to i386 and ppc
<Kamion> no, I'm just looking in the wrong place
<Kamion> +    $threelevellayouts, although this is only cosmetic (closes: Ubuntu#15327).
<Kamion> argh, and *that* was typoed too
<mdz> Kamion: it was obviously hurried
<Kamion> #15372 was the number
<mdz> xkb is a nightmare and I want no part of it
<seb128> daniels is pinging people all around the place for some days
<seb128> and those changes seem to fix the weird issues reported on GNOME and duped according to bugzilla feedback
<mdz> seb128: we are releasing now
<seb128> (not that I'm pushing them)
<seb128> mdz: yeah, I agree that's quite late ... we will get them with -update?
<mdz> and there are a bunch of other changes in there as well
<mdz> seb128: not enough information for me to predict that
* fabbione goes to make some coffee... 
<fabbione> i guess it's going to be a long long night
<\sh> well...I really admire mdz ... no joke
<mdz> seb128: if we can get a minimal, well-tested upload prepared, I don't see why not
<mdz> seb128: it's not critical at install time, right?
<ogra> \sh, we all do
<pitti> mdz: ok, let's not touch the live images to have some safety margin for new uploads and the growing new langpacks
<\sh> I think gentoo will say: come on...let's get every untested patch get in...actually it's bleeding egde
<seb128> mdz: no
<Kamion> mdz: I'll approve the oem-config stuff now
<mdz> Kamion: ok
<Kamion> then we can get debian-installer built, and then get started on images
<mdz> Kamion: gparted is also ->dapper btw
<pitti> mdz: is it reasonable to sleep now to start the mega-test in about 8 hours? or is it vital to test them ASAP and crash afterwards?
<Kamion> mdz: noted
<fabbione> Kamion: any of these 3 udebs will land in the initrd?
<Kamion> (I thought it probably was)
<Kamion> fabbione: yes
<Kamion> fabbione: 21:55 < Kamion> then we can get debian-installer built, and then get started on images
<\sh> ogra: no...seriously this guy at ISH? and no changerequest will be fulfilled ;)
<mdz> pitti: if you are tired, sleep
<fabbione> Kamion: ok.. 
<Kamion> fabbione: only kbd-chooser is arch: any
<fabbione> Kamion: roger
<mdz> pitti: save it for tomorrow night ;-)
<pitti> mdz: btw, I already tested all images today (I thought it made more sense to be able to actually fix things); no big issues
<pitti> mdz: powerpc live did not shut down totally cleanly for me, but it works for other people
<Kamion> mdz: I'm uploading the new d-i, but please don't approve it just yet
<mdz> Kamion: all yours
<mdz> pitti: what was the issue?
<pitti> ok, I'm dizzy and tired anyway, I'll crash now and get up early, unless there is some catastrophy
<mdz> pitti: good night
<pitti> mdz: after ejecting the CD it did not ask for pressing Enter
<mdz> pitti: sometimes on powerpc there seems to be a long delay there, but it eventually comes up
<pitti> mdz: and didn't react to it, but the autoreboot after 30 seconds, or the ctrl+apple+power worked fine
<dholbach> night pitti
<seb128> elmo: kbd sync please
<seb128> "night pitti
<pitti> mdz: no blocker IMHO
<mdz> there is no autoreboot that I know of
<\sh> pitti: I#m dizzy, too...but heavy dizzy
<fabbione> \sh: get some reast
<pitti> mdz: ok, then it was just the delayed reaction to my enter press, I guess
<fabbione> rest even
<mdz> pitti: yes, enter seems to work even when the message does not display quickly
<fabbione> \sh: we will need everybodys help tomorrow to test the images
<pitti> mdz: I leave my mobile on in case there is some trouble with langpacks
<mdz> \sh: drink water and sleep
<pitti> good night, cu tomorrow
<\sh> mdz: too late..
<ogra> mdz, he had to much beer already i suppose :)
<fabbione> \sh: close IRC, take a break and relax
<pitti> langpack buildd output looks fine :-)
<\sh> ogra: don't suppose
<ogra> heh
<\sh> i had a hard day at work...and forget it..going to bed...good night
<ogra> \sh, ciao
<dholbach> night \sh
<\sh> mdz: appreciate your work...really...I would like to see u as project manager in our company...
<ogra> lol
<mdz> \sh: thanks, but I think I have enough work for now ;-)
<ogra> \sh, what a loss for the world having mdz locked in into ISH
<mdz> what is ISH?
<ogra> www.ish.de
<dholbach> a telco/tv company
<HWolf> \sh, we all kind of apprecaite your work too. :)
<mvo> night \sh 
<HWolf> but without typing errors, really. :)
<ogra> mdz, my former company... \sh is one of my former colleagues :)
<\sh> HWolf: thx :) but I'm just another guy
<mdz> ogra: oh, I didn't realize
<ogra> mdz, and actually look at mvo's ip ;)
<HWolf> \sh, sure, but doing a lot of work. :)
<mdz> telcos can be difficult places to work
<fabbione> the telco were i was working before, just crossed 50GB/sec of customer traffic today
<\sh> mdz: I'm a stoopid ops guy...who kicks only non working servers and appliences
<\sh> fabbione: that's nothing
<fabbione> \sh: only customers.. without services and anything else.. the real traffic is way higher :)
<ogra> fabbione, ISH has 4.5 mio customers...
<fabbione> ogra: ISH is not a Tier-1
<fabbione> anyway
<ogra> nope, they are a cable company that also provides voip and internet
<fabbione> sorry i did drag you offtopic
<\sh> fabbione: yeah for us, too :) only 30 analog tv streams..and finally 20 transport streams with aehm...20x20 dtv streams..fcking scary when I'm rebooting the scramblers for p0rn stuff
<\sh> fabbione: u would have fun :)
<fabbione> \sh: get a sleep.. on the unscrambled p0rn ;)
<\sh> ah...btw
<fabbione> \sh: -> GO TO SLEEP
<mdz> lamont: is there a reasonable way for me to check up-to-dateness for myself, using stuff in http://people.ubuntu.com/~lamont/buildLogs/Lists/ perhaps?
<\sh> fabbione: YES SIR ;)
<fabbione> \sh: you need some rest and we need you fresh tomorrow
<\sh> fabbione: well..no prob...I'll have to work at 4 UTC
<\sh> quit
<mdz> Kamion: is the winfoss issue resolved, or do we need hno73?
<mdz> I have his phone number somewhere if so
<hno73> mdz: I'm here
<hno73> mdz: I made new uploads today, so I think it's resolved
<hno73> if not let me know
<Riddell> what's the winfoss issue and does it affect kubuntu?
<hno73> Riddell: 'too much of it'
<hno73> Riddell: AFAICT your ADM image still looks rather big ...
<mdz> hno73: reading the log, yes, it looks like Kamion worked out what was wrong and we're OK
<hno73> ok
<mdz> hno73: he was getting a 404 trying to get a tarball I think, but I guess the URL was wrong or similar
<hno73> Riddell: AMD64 even
<hno73> The URL might be wrong in the bugzilla entry
<mdz> Riddell: yep, http://cdimage.ubuntu.com/kubuntu/daily/current/breezy-install-amd64.OVERSIZED
<mdz> Riddell: looks like you have some trimming to do, if that's up-to-date
<Riddell> mdz: yep, top of my TODO list after testing the live CDs
<hno73> mdz: It's all sitting nicely here: http://www.theopencd.org/winfoss/
<Kamion> mdz: it's resolved for Ubuntu, AFAIK
<Kamion> lamont's latest build is MUCH smaller
<Kamion> like, 81MB smaller
<Riddell> Kamion: is kubuntu using the image at http://www.theopencd.org/winfoss/ ?
<Kamion> we could probably go back to using the i386 build on amd64 for Ubuntu, in fact
<Kamion> Riddell: yes, as I said before
<Kamion>                                                                 echo http://www.theopencd.org/winfoss/kubuntu/current/Kubuntu-WinFOSS-5.10.tgz
<Kamion>                                                                 echo http://www.theopencd.org/winfoss/kubuntu-AMD/current/Kubuntu-WinFOSS-5.10-AMD.tgz
<Riddell> Kamion: great
<fabbione> ok guys
<mdz> Kamion: that's, err, worryingly smaller
<fabbione> i am off to sleep
<Kamion> mdz: it's not much bigger than the i386 image, though
<fabbione> mdz/Kamion: i have my mobile phone with me if something shows up
<mdz> Kamion: where did 81M come from?
<Kamion> lamont: have you by any chance only been e2fs-zero.py'ing the amd64 image for some time, not removing the old- cloop?
<mdz> fabbione: ok, good night
<fabbione> otherwise i will be back in 6 or less
<fabbione> night
* mdz considers ordering enough pizza to sustain him for the next 48h
<Kamion> hno73: yeah, the URL was wrong in bugzilla, but it's fixed in cdimage now
<hno73> cool
<Kamion> lamont: also, could you take the thing you just did to the Ubuntu amd64 image and do it to Kubuntu amd64 as well, please?
<Kamion> mdz: I think we've just been using sladen's zeroing script for a while, and not realising that it hadn't in fact been working properly
<Kamion> so, with 66MB difference between the WinFOSS tarballs (as of last download), 81MB decrease in cloop size, and amd64 only being 8MB over, I think we can switch amd64 back to the tarball including OOo2
<Kamion> mdz: (FWIW, my mobile's AWOL at the moment; use my landline on Offices if you need to call)
<hno73> Kamion: or I can make an AMD tarball like the i386 one, but sans gaim, saving ~7MB
<Kamion> hno73: it appears that the i386 tarball will now fit on the amd64 live CD, though
<hno73> Kamion: cool, all the better
<Kamion> so if we're not going to be adding more langpacks to the live CDs (mdz?) then we might as well use the space for WinFOSS
<lamont> Kamion: 550601665
<lamont> wow.  sladen's code is b0rked.
<Kamion> lamont: how long have we been relying on sladen's code for amd64 reduction?
<lamont> Kamion: the solution is to reset
<Kamion> (by hand or otherwise)
<lamont> Kamion: for my manual reductions
<lamont> ia64 has been doing it automatically, none of the others have
<Kamion> lamont: put another way, when did you last manually reset, roughly?
<lamont> Kamion: breezy never reset, other than when I ran sladen's code 2-3 weeks ago
<Kamion> mdz: I think that explains it
<lamont> (64-bit arch that is...32 is always)
<Kamion> lamont: ok, definitely please do that for amd64 then
<Kamion> lamont: er, for Kubuntu I mean
<lamont> kubuntu to happen, ubuntu already happened.
<Kamion> yep
<lamont> kubuntu to happen, ubuntu already happened.
<lamont> ga
<lamont> ubuntu already done
<lamont> actually, next kubuntu (and base) loads on ubuntu will already get fresh fsimages.
<ajmitch> morning
<lamont> Kamion: unless you say "no", I'm going to nuke all 3 on ia64 and start a fresh build of all 3
<Kamion> lamont: fine by me
<lamont> ok
<Kamion> hno73: I'll keep using the special amd64 tarball on Kubuntu for the meantime
<Kamion> as it's tighter on space
<hno73> Kamion: OK, will you need me for urgent stuff into the night or can I retire :)
<lamont> and on that note, must go away for a few hours... back online in approx 7 hours give or take....
<lamont> last call
* hno73 remembers that he owes you one ;)
<Riddell> Kamion: does that mean I can expect new kubuntu amd64 live CD sometime soon?  I'm a little lost
<Kamion> 21:56 < mdz> pitti: if you are tired, sleep
<Kamion> 21:57 < mdz> pitti: save it for tomorrow night ;-)
<Kamion> hno73: that goes for you too, I think :)
<hno73> Kamion: oki :)
<lamont> Kamion: ia64 building all 3, I launched no amd64 build besides that test-now-really-it amd64 ubunut
<Kamion> lamont: I will start Kubuntu amd64 now, then
<Kamion> actually, Kubuntu amd64/i386/powerpc
<lamont> and remember base :-)
<lamont> (not that we much care - if ubuntu builds, base will)
<Kamion> yep
<lamont> later then
<Kamion> Riddell: in progress, yes
<Kamion> fabbione: be careful to upload kbd-chooser before building debian-installer
<Kamion> I'm assuming fabbione doesn't autosign
<segfault> ogra: thanks! :-)
<segfault> ogra: but did you get that po from Rosetta? the diff seems completely different from what i did. But there's no encoding problems, it's ok for breezy.
<segfault> :)
<ogra> segfault, thats the rosetta po file, converted to utf-8 and the encoding string fixed
<ogra> i have no idea how to tell rosetta to give it to me as utf-8 sadly...
<segfault> file pt_BR.po
<segfault> pt_BR.po: UTF-8 Unicode PO (gettext message catalogue) text
<Kamion> that's what msgconv's for
<segfault> i sent it as utf8, dunno what happened
<mdz> Kamion: might as well go for a fuller winfoss bundle, yeah
<Kamion> I think Rosetta always outputs in the encoding that's published in the archive for that .po file if it can
<Kamion> it probably should have a fallback case for if the text isn't fully representable in that encoding
<HiddenWolf> guys, current dist-upgrade...
<HiddenWolf> 29 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
<HiddenWolf> Need to get 32.7MB of archives.
<HiddenWolf> After unpacking 26.8MB disk space will be freed.
<HiddenWolf> 26mb will be _freed_ ?
<zyga> HiddenWolf: what was updated?
* zyga guesses language packs
#ubuntu-devel 2006-10-09
<Seveas> mjg59, you rock!
<Seveas> (but of course you already knew that)
<_ion> mjg59: Have you had time to review my usplash patch? (There's no hurry, i'm just interested.)
<mjg59> _ion: It's committed
<_ion> Ok, thanks.
<TheMuso> c
<sid> Is there an ubuntu-legal mailing list like there is a debian-legal mailing list/
<mjg59> No
<sid> mjg59: Is there a website specific to ubuntu about legal stuff? Like copyright law[dmca(the european version too)]  / software idea patents / trademark law(firefox)?
<sid> Does Ubuntu use SPI like debian does? Or do you guys have your own laywer?
<mjg59> sid: No idea, I'm afraid. I'd assume that Canonical have someone on the legal side of things.
<tseng> we follow the DFSG, mostly
<tseng> a few exceptions
<tseng> firefox might end up being one of them
<sid> Is there a marillat _like_ mirror for Ubuntu?(I know marillat doesn't do Ubuntu); Like a european only version of Ubuntu.(a version where software idea patents don't apply).
<sid> ie, not a mangled mplayer with stuff ripped out because of american patent law
<tseng> there are a few things in plf
<tseng> not that interesting to us, YMMV etc
<sid> hmm, I can't seem to connect; the google cache will have to do.
<sid> thanks a lot for the information tseng and mjg59; I appreciate it.
<sid> "The PLF Ubuntu project is shutting down, due to lack of time of its maintainers. New volonteers are welcome."
<sid> Guess that's why I couldn't connect.
<fabbione> morning guys
<Hobbsee> hey fabbione 
<fabbione> yo
<ajmitch> hey fabbione 
<fabbione> hey aj
<zul_> hey fabbione 
<fabbione> ajmitch: i should be able to start the buildd tomorrow. my wife will go away a couple of days and i can move out of the office to work (noise mainly) and she won't complain about an airplane or two turned on in the house
<fabbione> hi zul
<ajmitch> fabbione: great, I've got procmail setup for it
<fabbione> ok
<zul_> night
<fabbione> night zul
<fabbione> ajmitch: who can i contact in the MOTU team to do some batch job?
<fabbione> ajmitch: there are a bunch of xfonts that need a rebuild
<ajmitch> I can do that if you want
<fabbione> ajmitch: ok.. see bug #52803
<Ubugtu> Malone bug 52803 in gsfonts-x11 "insufficient dependency on xfonts-utils" [High,Confirmed]  http://launchpad.net/bugs/52803
<fabbione> read it all to the bottom
<fabbione> i already uploaded a new debhelper that sets the proper version Depends: on xfonts-utils
<fabbione> it will take about 2/3 hours to propagate in the archive
<ajmitch> ok
<fabbione> what i would like you to do is to prepare all the fonts in universe for upload
<fabbione> IF the package does not have an ubuntuX extension, make it buildX
<fabbione> so that it can be resynced automatically for edgy+1
<ajmitch> yes, I've got tools to do all that if I hand it a list of packages
<fabbione> without MOTU having to redo the merge manually
<fabbione> ok.. also.. make sure that the package actually needs the rebuild and that it uses dh_installxfonts in debian/rules + misc:Depends in debian/control
<fabbione> i am taking care of main 
<ajmitch> ok, I'll start downloading them
<fabbione> ok
<fabbione> there is no need to add a versioned B-D on debhelper.. just wait that it hits the archive before uploading
<fabbione> less delta > *
<fabbione> ajmitch: you want a changelog similar to:
<fabbione> culmus (0.101-6build1) edgy; urgency=low
<fabbione> 
<fabbione>   * Rebuild with new debhelper to set versioned Depends: on xfonts-utils.
<fabbione>     This change can/should be dropped automatically in edgy+1 syncs.
<fabbione>   (Closes Ubuntu #52803)
<ajmitch> there don't seem to be too many xfonts-* source packages in universe
<ajmitch> thanks
<fabbione> ajmitch: no, there aren't many
<fabbione> but they still need that version Depends:
<fabbione> otherwise it can breaks upgrade from dapper to edgy
<fabbione> ajmitch: there are some packages that add a Depends: xfonts-utils manually without calling dh_installxfonts. You want to add the versioned Depends manually
<ajmitch> 30 packages to check over, won't take long :)
<fabbione> xfonts-100dpi (1:1.0.0-2ubuntu1) edgy; urgency=low
<fabbione>   * Set versioned Depends on xfonts-utils.
<fabbione>   (Closes Ubuntu #52803)
<fabbione> yeah
<fabbione> this is the changelog i am using for the manual ones
<fabbione> note that it's a manual delta -> ubuntu1
<ajmitch> ok, noted
<fabbione> perfect
<fabbione> are you also checking multiverse?
<fabbione> i noticed 1/2 fonts there too
<ajmitch> I'll check that too
<fabbione> ok perfect
<ajmitch> I've got a list of all the source packages that build an xfonts-* binary
<ajmitch> I'll check it against those that depend on xfonts-utils
<fabbione> ajmitch: it's easier if you check apt-cache rdepends xfonts-utils
<fabbione> not all of them are called xfonts-
<fabbione> you will pull in a bit more junk, but you will catch them all
<pitti> Good morning!
<fabbione> hey pitti
<highvoltage> morning pitti and fabbione 
* pitti hugs fabbione 
<tfheen> morning, pitti
<Hobbsee> hey pitti 
<Hobbsee> hi tfheen 
<pitti> hey Hobbsee 
<pitti> moin tfheen 
<pitti> hi highvoltage 
<tfheen> 'morning, Hobbsee 
<Hobbsee> :)
<dholbach> good morning
<ajmitch> morning daniel
<fabbione> hey dh
<dholbach> hey fmdn
<pitti> hi giftnudel 
<giftnudel> hi pitti
<fabbione> ajmitch: new debhelper is published.. we are good to go with the uploads
<ajmitch> great, I'll get onto it now
<fabbione> there.. main is done
<tfheen> mvo: could I have a GnomeAppInstallDesktopDatabaseUpdate today, please?
<mvo> tfheen: sure. the last is from 5. oct
<tfheen> mvo: sure, but I'd like to have one from now, since we're getting close to the freeze.
<ajmitch> tfheen: freeze is thursday?
<tfheen> ajmitch: correct.
<ajmitch> thanks for fixing the casper issues with mono
<tfheen> np
* ajmitch has a small pile of upstream patches against f-spot to grab 7 test
<Keybuk> seb128: ping?
<seb128> Keybuk: pong
<Keybuk> seb128: evolution is still doing the "folder-display|..." thing
<seb128> Keybuk: yeah, we have a language-pack update once by century or something like that :p
<Keybuk> ahh, it's waiting on those?
<seb128> it's a translation issue and fixed to launchpad for weeks so probably
<pitti> we had the last one for beta, I plan another one for RC
<pitti> seb128: ^ if that's fine with you?
<seb128> yep
<ogra> dholbach, ping
<seb128> though I would prefer weekly translations updates next cycle
<dholbach> ogra: pong
<pitti> Keybuk: speaking of broken langpacks, can you please nudge the dapper ones into proposed?
<pitti> seb128: I have no problem with weekly
<ogra> dholbach, human-cursors-theme doesnt contain the thzeme file, is that intentional ?
<Keybuk> pitti: if I can get around to it today, I will
<dholbach> Keybuk: if you find the time can you get the libgalago3 binary out of new, please?
<seb128> 2-3 updates in 6 months is no fun
<dholbach> ogra: it's in human-theme, yes
<Keybuk> dholbach: again, only if I can get around to it today
<pitti> Keybuk: *hug*, thanks
<ogra> dholbach, why ? 
<Keybuk> see #canonical
<pitti> seb128: yeah, but the initial delay was due to Rosetta export; I hope we won't have that again for edgy+1
<seb128> pitti: right
<ogra> dholbach, that forces me to install human-theme in the thin client chroot .. couldnt it move to the cursors package ?
<ogra> since i only need the cursors for ldm
<dholbach> Keybuk: Ok - thanks.
<dholbach> ogra: i need to think about it - when I did it, it was for a reason
<Keybuk> doko_: ping
<Keybuk> or maybe seb128 
<Keybuk> python-gnome2 conflicts and provides python2.4-gnome2
<Keybuk> but doesn't replaces it
<ogra> dholbach, ok
<tfheen> fabbione: it seems like something blew up in the sparc world over the weekend; http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html ; can you investigate?
<seb128> Keybuk: I'll fix that
<fabbione> tfheen: looking
<fabbione> COW!
<fabbione> seb128: this is your fault
<fabbione> seb128: something in desktopland didn't build
<Keybuk> seb128: same with things like cairo, pyorbit, etc.
<seb128> fabbione: libgnomeui apparently
<seb128> Keybuk: python* then?
<seb128> Keybuk: that's a dh_ something bug? should maintainers do that by hand or that should be done automatically with the new policy?
<fabbione> seb128: did you batch upload without proper versioned B-D ?
<seb128> fabbione: no
<fabbione> hmmmm
<seb128>   libbonoboui2-dev: Depends: libbonoboui2-0 (= 2.16.0-0ubuntu1) but it is not going to be installed
<seb128>   libgnome2-dev: Depends: libgnome2-0 (= 2.16.0-0ubuntu1) but it is not going to be installed
<seb128>   libgnomevfs2-dev: Depends: libgnomevfs2-0 (= 2.16.1-0ubuntu1) but it is not going to be installed
<fabbione> The following packages have unmet dependencies:
<fabbione>   libbonoboui2-dev: Depends: libbonoboui2-0 (= 2.16.0-0ubuntu1) but it is not going to be installed
<fabbione>   libgnome2-dev: Depends: libgnome2-0 (= 2.16.0-0ubuntu1) but it is not going to be installed
<fabbione>   libgnomevfs2-dev: Depends: libgnomevfs2-0 (= 2.16.1-0ubuntu1) but it is not going to be installed
<fabbione> E: Broken packages
<seb128> hum
<Keybuk> seb128: I've no idea
<fabbione> that one :)
<seb128> fabbione: that looks like a "arch all/any out of sync"
<seb128> maybe a retry would be enough
<fabbione> tfheen: can you give back libgnomeui on sparc please?
<fabbione> seb128: yeah checking here locally too
<seb128> fabbione: the 3 "not going to be installed" packages have built correctly
<seb128> fabbione: retry should be fine
<fabbione> seb128: yup
<tfheen> fabbione: done
<fabbione> tfheen: thanks
<geser> could someone please giveback gnustep-gui?
<tfheen> geser: done
<geser> tfheen: thanks
<seb128> Keybuk: python-cairo and python-pyorbit seem to have a proper Replaces in fact
<tfheen> pitti: do you happen to know if anybody's working on a MIR for kexec-tools?
<pitti> tfheen: not to my knowledge
<tfheen> I'll have to get BenC to do that, then.
<sivang> morning!
<Keybuk> seb128: ok, I guess they depend on the python-gnome2 ?
<seb128> Keybuk: no, they are lower in the stack
<Keybuk> odd
<seb128> why?
<seb128> did you get some upgrade issues with them?
<tfheen> Kamion: could you please enable your cronjobs on drescher?
<tfheen> Kamion: http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html is severly out of date.
<Keybuk> seb128: yeah
<Keybuk> I foolishly didn't write it down though
<Keybuk> (upgrading my desktop today)
<Kamion> morning
<Kamion> tfheen: they aren't disabled ...
<sivang> morning Kamion 
<Kamion> I think it's stuck somewhere, checking local mail
<Keybuk> Kamion: did you get much chance on Friday to do archive-bitch stuff?
<Kamion> Keybuk: a little, but not a lot
<Keybuk> Kamion: if you get a chance, could you do some today?
* Keybuk is awaiting for andreas to arrive
<Kamion> ok
<Kamion> tfheen: I've kicked it; not sure if it'll stay kicked though
<tfheen> Kamion: hmkay and thanks a lot
<Kamion> oh
<Kamion> dapper upgrade
<Kamion> ImportError: libapt-pkg-libc6.3-5.so.3.9: cannot open shared object file: No such file or directory
<tfheen> that'd explain things
<Kamion> ok, fixed properly now
<sivang> mvo: thanks for the test in hubackup, it will serve as a nice starting point for testing the other modules :-)
<mvo> sivang: cheers!
<tfheen> Keybuk: is there an lrm upload stuck in NEW?
<dholbach> Kamion: Hi - Keybuk wasn't sure if he would get around to it today, but it'd be very cool to get libgalago3 binary package out of new, so I could start rebuilding the redepends.
<fabbione> Kamion: sorry to bother, but when you have time, could you please look at bug #63693? i just need a quick look from you
<Ubugtu> Malone bug 63693 in initramfs-tools "dapper -> edgy dist-upgrade prompts for questions" [High,Unconfirmed]  http://launchpad.net/bugs/63693
<mvo> does anyone know what package installs /etc/default/locale? 
<fabbione> mvo: probably belocs-locale-bin
<mvo> fabbione: I don't have it on my upgraded systems, only on new installs. and apparently it overwrite the settings in /etc/environment
<fabbione> belocs-locales-bin.postinst:EE="/etc/default/locale"
<mvo> fabbione: thanks
<fabbione> mvo: we also need to look at that bug... i just need to finish one thing here
<mvo> fabbione: at the apt bug for the upgrades?
<fabbione> yeah
<Kamion> mvo: it's created by localechooser
<Kamion> yes, it's intended to be used in preference to /etc/environment if possible, AFAIK; it was a Debian change
<Kamion> dholbach: done
* tfheen kicks busybox in the nuts.
<dholbach> Kamion: you ROCK! :-)
<mvo> Kamion: ok, thanks. I need to change language-selector to take this into account then
<Kamion> fabbione: checking
<fabbione> Kamion: thx
<tfheen> Kamion: so, busybox's md5sum complains about mismatches if there's a blank line in the input.
<tfheen> Kamion: should we fix that by fixing it to work correctly or fix cdrom-checker to DTRT or both?
<Kamion> fabbione: oh, how was the install done? d-i or ubiquity?
<Kamion> tfheen: why is there a blank line in its input?
<fabbione> Kamion: d-i (netinstall bitch ;))
<tfheen> Kamion: because cdrom-checker does fgets(line, sizeof(line), fd), and then gives that to a system call.
<tfheen> (without stripping off the \n)
<tfheen> actually, it gives it to an echo | md5sum -c call
<tfheen> see main.c:131 and five or so more lines
<Kamion> oh, I see
<tfheen> stripping the newline is trivial, but busybox shouldn't complain when it's given one valid and one empty line, IMO
<Kamion> probably do both fixes
<Kamion> fabbione: replied
<fabbione> Kamion: thanks
<Kamion> fabbione: ... and updated with another possibility
<fabbione> Kamion: reading
<Keybuk> tfheen, dholbach: -> Kamion
<fabbione> Kamion: the strange thing is that it happens on fresh-install.. i mean i can see RESUME=/dev/hda5 on dapper fresh install
<dholbach> Keybuk: hm?
<Keybuk> ask Kamion for archive stuff today
<dholbach> Keybuk: I already did - thanks.
<fabbione> Kamion: the only code that can change that is not nowhere in initramfs.. so i can only assume something in d-i was mangling it
<dholbach> Keybuk: Have a nice day.
<Keybuk> :-)
<Kamion> fabbione: ok, it wasn't clear to me that you'd checked the conffile before attempting to upgrade
<fabbione> Kamion: ok.. yes i did check
<fabbione> see the diff on top
<tfheen> Keybuk: 'k
<Kamion> fabbione: yes, but that diff is generated after the new preinst runs
<tfheen> Kamion: is there an lrm stuck in NEW?
<tfheen> or, was there?
<Kamion> tfheen: not AFAIK
<fabbione> Kamion: right.. but i did check it.. yes
<Kamion> I'll see if I can test it out here and isolate it
<fabbione> if you want i can reinstall here and triple-verify
<fabbione> ok
<tfheen> Kamion: ah, lrm ftbfs-ed on ppc.
<fabbione> i also noticed the rename in the config dir.. but that *seems* to work ok
<fabbione> i need to go offline a few minutes... brb
<Kamion> fabbione: I'm unconvinced by that preinst, given that it has:
<Kamion> case "$1" in
<Kamion>         configure)
<Kamion> fabbione: and preinst never gets $1 = configure
<Kamion> tfheen: I think that localechooser upload of mine may also fix that zh_CN/zh_TW issue that's on the ubuntu-6.10 list, but I'll need to test it
<tfheen> Kamion: good, thanks.
<Kamion> which leaves the manual partitioning summary bug and system-config-kickstart brokenness
<tfheen> malone doesn't do graphs yet?  So there's no way for me to say "please give me a graph showing how many bugs match those criteria over the last ten days"?
<lifeless> no
<tfheen> is it planned?
<lifeless> we do that with cricket at the moment, and AFAIK theres no solid plan for that finess in data mining
<tfheen> or even just being able to get at those data would be immensely useful.
<tfheen> "show me how the situation looked ten days ago", "show me how it looked nine days ago", etc.
<lifeless> yah
<lifeless> spec it up :)
<lifeless> (sorry thats the best long term answer)
<tfheen> I guess so, yes.
<lifeless> short term, let stub know what you need, if the criteria are fairly static.
<tfheen> what I'm really wanting to know is "are we on track for having no targetted bugs on Thursday"
<tfheen> (and if not, how are we doing?)
<holycow> kamion great nick
<holycow> means truck in eastern eu languages, right?
<fabbione> Kamion: fehh....
* tfheen gives back a bunch of gnome stuff on sparc
<fabbione> seb128: the libgnomeui thingy did clear a bunch but not all of the sparc mess....
<fabbione> seb128: any idea what else might be missing?
<tfheen> fabbione: libvte-dev seems to be uninstallable?
<fabbione> it's probably something that needs a kick after libgnomeui build
<fabbione> tfheen: getting there...
<pitti> hi tkamppeter 
<tkamppeter> hi pitti
* fabbione sighs
<ProN00b> who made the share folder functionality of ubuntu ?
<ProN00b> i suggest sharing over ftp as a feature
<seb128> fabbione: things probably need to be kicked in the right order, libs first
<mantiena-baltix> Hi all
<fabbione> seb128: kicked as in they are FTBFS and needs to be give-back or kicked as in re-uploaded to re-build?
<seb128> fabbione: buildd retry
<seb128> fabbione: it looks like the issue was gnome-python
<tkamppeter> pitti, thanks for updating CUPS, but probably we need another patch: bug 64725
<Ubugtu> Malone bug 64725 in cupsys "USB driver cannot find printers if usblp0 is disconnected" [Undecided,In progress]  http://launchpad.net/bugs/64725
<pitti> tkamppeter: yes, smurf already mailed me about it
<seb128> fabbione: 0ubuntu5 I've uploaded this morning has built on sparc now, it's probably just a matter to retry build of gedit, gnome-applets, gnome-panel, etc when it's available now
<pitti> tkamppeter: I'll review and test it today
<fabbione> seb128: i see...
<fabbione> tfheen: can we do a massive give-back?
<tfheen> fabbione: I've done a bunch of those already, I'll get more during the rest of the day.
<fabbione> tfheen: ok thanks
<tfheen> I have to clicky-clicky through the interface. :-/
<fabbione> tfheen: i know you love that...
<fabbione> i am hungry.. a lot
* fabbione heads toward the fridg4
<fabbione> tfheen: libvte-dev looks installable now
<fabbione> i need food
<Treenaks> hm, libapache2-mod-fcgid leaks memory in apache2's heap.. about 100MB/week for me.. (switching to -mod-fastcgi removes the growing behavior)
* Treenaks hops to the launchpad
<tfheen> Treenaks: valgrind is your friend
<Treenaks> tfheen: not on my Via C3 server
<Keybuk> mjg59: is usplash supposed to just not start on nvidia?
<dholbach> tkamppeter: Hello - my sister asked me of how good the chances are to get a Lexmark Z43 working in Ubuntu - do you know anything about that?
<tfheen> Keybuk: it segfaults ATM, iirc
<tfheen> Keybuk: https://launchpad.net/distros/ubuntu/+source/usplash/+bug/56587
<Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Confirmed]  
<Keybuk> ahh
<Kamion> ProN00b: AFAIK, it's an upstream GNOME feature
<ProN00b> i see
<pitti> tfheen: thanks for fixing the cdrom-checker
<tfheen> oh, no problem
<ogra> infinity, any news about the arch specific package selection breakage ? my ppc-live is still 40Mb to big
<ogra> grmbl, why the heck does update-manager remove xchat on every upgrade for me ...
<doluu> which package contains net/errno.h file?
<fabbione> Keybuk, mjg59: it doesn't segfault here... 
<Keybuk> I have an odd grub feature to
<Keybuk> it prints "kernel direct mapping tables ..." on the bottom line of the screen
<geser> does somebody know when uptodate Contents files will be available again on archive.ubuntu.com?
<fabbione> geser: they are generated daily
<tfheen> fabbione: do you have an amd64 with nvidia?
<geser> fabbione: http://archive.ubuntu.com/ubuntu/dists/edgy/ shows 07-Jun-2006 as date
<fabbione> tfheen: yes it's amd64 + nvidia, but i am running x86... i can test with livecd tho
<mantiena-baltix> Kamion, hi, could you tell me is /boot/initrd-* file, which is inside filesystem.cloop is needed in LiveCD ?
<fabbione> geser: feh.. that's about right
* fabbione pokes some guys around
<tfheen> mantiena-baltix: it's not.
<tfheen> mantiena-baltix: but why are you using cloop?
<mantiena-baltix> tfheen, sorry, inside filesystem.squashfs
<mantiena-baltix> so, if initrd file is not needed why it's inside filesystem.squashfs from official Ubuntu CD's ? ;)
<tfheen> mantiena-baltix: anyway, it's not used by the live session.  It's used by grub after installation, though.
<mantiena-baltix> tfheen, AFAIK initrd file is generated during installation, when you are installing with ubiquity
<tfheen> mantiena-baltix: it could be, at least.  I don't think it is, though
<mantiena-baltix> tfheen, I think, that I should report a bug about not needed /boot/initrd* file inside filesystem.squashfs 
<tfheen> mantiena-baltix: 
<tfheen> argh
<mantiena-baltix> Kamion, you are ubiquity developer, what you think ?
<tfheen> mantiena-baltix: *shrug*; if so, it should go on ubuntu-cdimage.  I don't see a big point in it, while it would save a bit of space on the CDs, which is good.
<mantiena-baltix> yea, this saves about 7 Mb disk space, which is very good for example for language-support-lt ;)
<heno> when is final artwork freeze?
<heno> I need to know for screenshots used in the winfoss section
<tfheen> heno: what are your thoughts on updating onboard?
<heno> tfheen: I agree it needs an update (just replied to your mail)
<tfheen> ok, thanks.
<tfheen> heno: r38 is fine with you?  I can do the update for you.
<heno> tfheen: if the reporter was tortoise, then that's the developer
<tfheen> heno: tortoise_, but ok
<heno> tfheen: why not r40?
<tfheen> heno: because he said r38?
<heno> tfheen: hm, ok. Looks like he made two updates yesterday after being here then
<ogra> heno, btw, onbioard works fine on ltsp clients ... what was the magnifier we ship ? i didnt test that one yet
<heno> r38 should be fine then
<heno> ogra: gnome-mag, powered by gnome-orca
<ogra> oki
<ogra> i'll check that one too (iirc it didnt work in wiesbaden)
<heno> right
<heno> ogra: it might get worse with hw-accelerated magnifiers in future
<ogra> hrm, orca doesnt use gstreamer ?
<heno> how does ltsp deal with compiz stuff?
<ogra> not at all
<heno> ogra: what should it use gstreamer for?
<ogra> you dont have access to /dev/dri on the client from the users session
<Treenaks> ogra: wasn't aiglx made to be "usable" over the net?
<ogra> heno, i just had sound output when starting orca manually from console ...
<Treenaks> (i.e. more usable than not at all)
<heno> ogra: cool! 
<ogra> Treenaks, i havent looked into that yet, might be ... but afaik you still need access to dev/dri
<ogra> heno, not really ... it comes out of the server instead of using the gstreamer-esd redirect we use in ltsp
<Treenaks> ogra: no, you need access to an X server with the GLX extension -- slight difference :)
<mjr> Treenaks, yep
<mjr> "Accelerated Indirect GLX", hence no absolute need for "Direct Rendering Interface" access
<Treenaks> mjr: although I keep confusing XGL and GLX :)
<heno> ogra: perhaps you can file a bug on orca upstream, I'm sure they'd want to fix that
<tfheen> gnr, the onboard package should be a proper branch
<TheMuso> heno, ogra Thats not an orca issue.
<TheMuso> Its to do with festival/gnome-speech.
<heno> tfheen: in the 'project' or in the ubuntu archive?
<ogra> right, that might be ... *something* isnt using gstreamer here :)
<heno> TheMuso: does speech dispatcher look any better in that regard
<tfheen> heno: the package you get when you do apt-get source onboard should, IMNHSO include the .bzr directory.
<TheMuso> heno: In terms of offering several formats for audio output, yes.
<TheMuso> As it is, festival supports alsa/oss/esd afaik.
<TheMuso> It may also support nas. I am not sure however.
<ogra> tfheen, well, thats fine during development if you can waste the bandwith though ... but should be cleaned before releasing the final package ;)
<tfheen> ogra: why?
<heno> tfheen: ok, I'll ask Chris to fix that when he turns up
<tfheen> heno: please also make Chris not nuke old changelog entries.
<ogra> tfheen, you dont need to bzr export all the time 
<tfheen> ogra: ... why should you ever strip the .bzr directory?
<heno> tfheen: ok, I'll send him a log of this discussion :)
<ogra> tfheen, because i dont want it in my source package ...
<tfheen> heno: thanks.
<tfheen> ogra: you didn't answer the question.  _why_ don't you want it in there?  It makes updating the package easier and is otherwise harmless.
<ogra> tfheen, the tar.gz of ltsp is 2M big with the .bzr tree and 180k without it
<tfheen> ogra: yes, and?  Bandwidth is cheap.  The additional cost of updating a source package without a .bzr directory is much higher than the cost of downloading 1.8MB extra.
<ogra> during development i keep the .bzr dir ... just because its one step less i have to do before uploading it ... short before release i only upload with bzr export before ...
<_ion> lintian complains about version control directories in the source package.
<tfheen> _ion: lintian is wrong in this particular case.
<tfheen> ogra: if you're so concerned about source package size, use a lightweigth checkout.
<ogra> tfheen, well, i dont want ltsp to be that big ... if a user wants to use bzr he/she should checkout the proper branch anyway
<mjg59> Keybuk: On amd64?
<ogra> tfheen, do you keep CVS dirs if you have a choice not to ?
<tfheen> ogra: you _do_ know that CVS and bzr are completely different beasts, don't you?
<ogra> right, i know ... but we're talking about version control info in both cases
<ogra> for a final released package it appears cleaner to me not to have that in the package, especially since its a lot of bloat
<tfheen> if you think they are comparable, I suggest you look at the centralised vs decentralised RCS discussions that have been all over the net for the last couple of years.
<_ion> Whether it's {,de}centralized is irrelevant IMHO. I'd just bzr export ../foo-0.42 and build the source package from there.
<agutierr> Hello All. I have a question about preseeds. I am using a preseed to autoinstall the system, but always installer download packages from security.ubuntu.com. Someone knows how I can set this selection to download from my local mirror? Thanks.
<tfheen> _ion: a CVS checkout is useless on its own.  A bzr checkout isn't.
<_ion> tfheen: Yes, and still i don't consider a debian source package to be the proper place for .bzr. If a user wants to get a bzr tree, she can easily branch it from upstream or launchpad or whatever.
<_ion> Especially when it causes the size of the source package to increase tenfold.
<tfheen> bandwidth is cheap. *shrug*.
<Seveas> tfheen, not everywhere
<fabbione> tfheen: you are a bit spoiled bw wise :P
<ogra> well, uploading 200k or 2M *makes* a difference with my 512k uplink here
<ogra> (its 30sec vs 10min)
<mjg59> ogra: I think you mean 30sex vs 5min...
<mjg59> Uh, sec
<_ion> For instance, the price of my GPRS service is about 1.5/1MiB IIRC. :-)
<ogra> mjg59, lol, yes
<tfheen> Seveas: I think saying that you have to have reasonable bandwidth to develop is reasonable.  Just like you have to have a faster machine to compile programs at a reasonable speed.
<ogra> i never stopwathed it, but its significant :)
<ogra> *stopwatched
<Seveas> tfheen, imagine all source packages converted to bzr and including a checkout
<Seveas> archive would explode
<tfheen> Seveas: it'd be lovely.
<Seveas> znarl would be mad at you 
<tfheen> he'd be happy to get more toys, I'll tell you. :-P
<ogra> heh
<Seveas> hmm, /me sees elm.o, znar.l and spad.s chasing tfheen with pitchforks because now noone wants to mirror ubuntu anymore ;) 
<pitti> Seveas: eventually we want to drop the source packages anyway and *only* commit to a bzr branch on LP
<fabbione> tfheen: i am not so sure our src cd publisher will like to jump from N cd's to N dvd's
<pitti> Seveas: that'll be much more bw-efficient :)
<ogra> hello, this cabinet to your right is our new SAN for .bzr dirs :P
<Seveas> pitti 
<pitti> and, for that matter, I oppose .bzr in source packages, too
<fabbione> ogra: there is already a SAN at the datacenter :) 
<fabbione> matter of fact is that we might get the second one for bzr branches :)
<ogra> fabbione, yes, i meant the second one to hold all the bzr inofs ;)
<Seveas> fabbione, supermirror?
* tfheen shrugs and goes back to actually doing useful work.
<fabbione> Seveas: the second one? yeah.. that was the rumor
<Seveas> neat
<fabbione> but i am only speculating.. i am not in London or plan DC operations
<tcr> May I suggest to ship libcap-dev with the installation cd. Rationale: It may be needed to install vendor software to configure internet access, and if it isn't provided on the cd, may make the life of people quite a bit awkward.
<ogra> Keybuk, init: Re-executing /sbin/init 
<ogra> is that something i should be worried about ?
<ogra> just appeared on my console
<fabbione> tcr: please file a bug and explain the rationale.. including an example of vendor software that requires that.
<tcr> fabbione: I think it kind of sucks that I've gotta register for that.
<Treenaks> fabbione: any news from the X people on my bug? :)
<fabbione> Treenaks: nope.. i didn't speak with them today
<Treenaks> fabbione: hm, ok :) I'm waiting for airlied to parse my bios ;)
<tcr> I downloaded the .deb file from http://packages.ubuntu.com/dapper/libdevel/libpcap0.8-dev, but when I try to install it on edgy it reports "Dependency is not satisfiable libpcap0.8", otoh libpcap-0.8 i.e. 0.9.4-1 was installed by default.
<mantiena> tfheen, still here ? I wanna talk with you about mounting hard disk partition in LiveCD - look at bugs #16356 and #34873 and #48118
<Ubugtu> Malone bug 16356 in Baltix "LiveCD does not mount hard disk partitions (yet)" [High,Confirmed]  http://launchpad.net/bugs/16356
<Ubugtu> Malone bug 34873 in Baltix "Harddisks listed at Places and Desktop, but not mounted to /media" [Medium,Unconfirmed]  http://launchpad.net/bugs/34873
<Ubugtu> Malone bug 48118 in Baltix "pmount should not refuse to mount nonremovable drives without fstab entry" [Undecided,Unconfirmed]  http://launchpad.net/bugs/48118
<pitti> mantiena: pmount should be discussed with me
<tfheen> mantiena: yes, I'm here
<tcr> I've got to correct myself, the version that ships with edgy is libpcap 0.9.4-2. but I can't find that on packages.ubuntu.com.
<tcr> I could image that the -2 is part of an ubuntu internal versioning scheme, is that right? 
<Seveas> tcr, yes
<mantiena> pitti, tfheen: problem is mainly for LiveCD, but not only, because new hard disk are connected on installed systems also
<tcr> Seveas: Is it automatically increased when going from on release to the next? 
<mantiena> pitti, tfheen
<Seveas> no
<tcr> Seveas: How can I find out the changes between -1 and -2?
<mantiena> but Live CD is almost not usefull if user can't see his data in hard disk partitions
<pitti> mantiena: that should be solved with an fstab manager, like pysdm
<Seveas> download both sourcepackages and run debdiff 
<Kamion> tfheen: ubiquity does call update-initramfs, so removing /boot/initrd* is probably ok
<tfheen> Kamion: 'k.
<pitti> mantiena: also, gnome-system-tools' disks-admin was ok for that
<mantiena> pitti, it's too hard for average users to understand this
<pitti> mantiena: we specifically do not want to give access to the fixed hard disk
<Kamion> agutierr: preseed apt-setup/security_host
<pitti> mantiena: otherwise a normal user could pmount a system partition and put backdoors into it
<mantiena> Kamion, so, I should a bug about not needed /boot/initrd in filesystem.squashfs
<Kamion> mantiena: that's what we just said, yes; /products/ubuntu-cdimage
<pitti> mantiena: we do not care for removable devices, since truly removable ones cannot be trusted as system partition anyway; but we do care for fixed hard disks, which might be physically protected
<mantiena> pitti, I'm not talking about normal users, who aren't in admin group
<agutierr> thanks Kamion 
<mantiena> Kamion, ok
<mantiena> pitti, I think pmount should allow to mount non-removable partitions for users, which are in admin group (has sudo rights)
<pitti> mantiena: well, as I said in the bug trail, providing a GUI wrapper around mount would be nice
<pitti> mantiena: but not hacking this into pmount; it's the wrong place
<mantiena> pitti, gnome-vfs already does this, right ?
<pitti> mantiena: 'this' == ?
<mantiena> pitti, this == wrapper around mount
<pitti> mantiena: pmount should not make assumptions about groups
<pitti> and checking whether an user can execute something with sudo is *very* hard (and impossible for a normal user)
<pitti> and third, it's simply not pmount's purpose
<mantiena> pitti, but now pmount works only for users, who are in plugdev group, so it makes assumptions about groups already, right ?
<pitti> mantiena: no, pmount does not check any groups
<mantiena> pitti, ok
<pitti> mantiena: that's simply the case because it gets installed root:plugdev 4754
<pitti> mantiena: but, as I said, a gnome integration would still be nice, of course
* pitti -> lunch, bbl
<mantiena> pitti, so, auto-mounting hard disk partitions in Live CD should be solved no in pmount, but in casper or somethin, right ? Last comment about mounting hard disk partition in LiveCD if from tfheen - bug #16356 
<Ubugtu> Malone bug 16356 in Baltix "LiveCD does not mount hard disk partitions (yet)" [High,Confirmed]  http://launchpad.net/bugs/16356
<tfheen> mantiena: yeah, it's been argued that it should be done in casper, but I just haven't had enough time to do it.
<mantiena> tfheen, I can finish this, just give me you code :)
<mantiena> tfheen, I must have LiveCD which automounts hard disk partitions in 2 days :)
<tfheen> mantiena: I presume you know where the casper bzr tree is; just branch off that.
<mantiena> tfheen, http://people.ubuntu.com/~mdz/archives/ ?
<mvo> Kamion: localechooser is not using LANGUAGE anymore?
<mvo> Kamion: and LANG is now written to both /etc/environment and /etc/default/locale?
<Kamion> mvo: what do you mean, using?
<Kamion> localechooser still writes out LANGUAGE
<mvo> Kamion: to what file/location?
<Kamion> # We set LANGUAGE only if the languagelist is a list of
<Kamion> # languages with alternatives. Otherwise, setting it is useless
<Kamion> if echo "$LANGLIST" | grep -q ":"; then
<Kamion>         echo "LANGUAGE=\"$LANGLIST\"" >> $DESTFILE
<Kamion>         echo "LANGUAGE=\"$LANGLIST\"" >> $DESTFILE2
<Kamion> fi
<Kamion> mvo: to both /etc/environment and /etc/default/locale, but see that comment
<mvo> aha, right
<mvo> htanks
<mvo> thanks
<Kamion> LANG> as you say
<mvo> Kamion: so I need to change it in both files in language-selector?
<Kamion> yeah
<mvo> ok, fixing that now
<Kamion> it'll stop being written to /etc/environment once etch is out, I think
<Keybuk> ogra: no, that shouldn't be a problem
<Keybuk> that usually happens when upstart gets upgraded
<mantiena> tfheen, sorry, can  you tell me where is casper bzr tree and partition automount branch now ?
<ogra> Keybuk, right, i forgot that update-manager was running on another thin client ... so i saw that meassage on the servers console while working there
<Kamion> mantiena: http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/
* ogra starts to note that extremely distributed working gets confusing 
<kristog> hello
<Keybuk> ogra: kill 1 does it
<tfheen> mantiena: http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk
<ogra> ah
<dholbach> hey kristog
<seb128> hi kristog!
<kristog> hello dholbach seb128 :)
<mantiena> thanks
<ogra> pitti, pmount /dev/sda1 on console gives me a million NTFS-fs error messages (the disk is ext3)
<mantiena> ;
<Keybuk> seb128: getting icon theme errors?
<Keybuk> media-player-48.png not found
<seb128> Keybuk: no
<seb128> Keybuk: ah, do you have a totem launcher on your panel or something like that?
<Keybuk> yezh
<seb128> the icon name and launcher changed
<seb128> but the panel config is static, so it's not updated on upgrade
<seb128> and still used the deprecated name
<seb128> s/used/using
<Keybuk> oh right
<seb128> not a lot we can do
<seb128> we could create a compatibility symlink for that icon if we think many user have a launcher for it
<seb128> but that's about it for edgy
<Hobbsee> mjg59: you're known to be good with wifi cards that are supposed to be auto-recognised.  did you want to check out https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/60231 please?
<Ubugtu> Malone bug 60231 in linux-source-2.6.17 "wg511 pccard not loaded (regression: dapper -> edgy)" [Undecided,Unconfirmed]  
<mjg59> Hobbsee: It's not appearing in lspci, so the driver will never bind
<mantiena> tfheen, btw, maybe you can recommend some graphical bzr management tool ?
<Hobbsee> mjg59: argh, i thought it was, sorry.
<Treenaks> bzrk? or real "I want to commit this file" GUIs?
<mjg59> Hobbsee: dmesg shows that the card plugging is being detected, but shows no sign of the device itself appearing
<Hobbsee> mjg59: good point, i missed that.
<tfheen> mantiena: I just use the command line
<mantiena> ;)
<mantiena> I try to use bzr-gtk ;)
<ogra> whee, evo stopped misbehaving in message deletion !
* ogra hugs dholbach 
<dholbach> ogra: it does?
<ogra> yes
<seb128> it has been fixed with 2.8.1
<ogra> i just upgraded my system
<seb128> I've done the update and closed the bug
<seb128> and dholbach gets the hugs, that's not fair :p
<ogra> seb128, you rock :)
* ogra un-hugs dholbach 
<ogra> :P
<seb128> ;)
* seb128 hugs dholbach
* ogra hugs seb128 
<dholbach> :-)
<dholbach> wow NICE
<mjg59> Hobbsee: 
<mjg59> Hobbsee: http://bugzilla.kernel.org/show_bug.cgi?id=6801
<Ubugtu> bugzilla.kernel.org bug 6801 in PCI "lspci missing my CardBus Ether card" [Normal,New]  
<mjg59> Hobbsee: I've linked to a patch for 60231
<Hobbsee> mjg59: cool.  the guy was in -bugs, looking for help to fix it
<mjg59> Hobbsee: pci=bios may well work around it
<mjg59> Or pci=conf1
* sivang goes back to using evo then!
<heno> tortoise_: tfheen is doing a fresh upload of onboard
<heno> tortoise_: he also wanted the full bzr tree included in the source package, but the jury seems to still be out on that :)
* heno regrets starting that discussion again
<heno> tortoise_: also, please preserve the full changelog (with old entries)
<tortoise_> heno: ah, ok
* heno reboots to work on some winfoss stuff
<Hobbsee> mjg59: [23:32]  <drew_> Hobbsee: pci=conf1 works!!
<mjg59> Hobbsee: Ok, cool
<mjg59> Hobbsee: In that case, the patch should work
<pitti> BenC: crashdump-helper patch> btw, it's relatively easy to pry out the signal number from the core dump, so in edgy+1 we can just use the upstream 'pipe' core dump pattern feature and completely drop our kernel patch
<BenC> pitti: excellent
<pitti> BenC: (assuming that the pattern supports pid macros)
<BenC> pitti: it should, which means you can make the pattern something like "| /usr/sbin/apport %pid %sig"
<BenC> or whatever the replacement is
<tortoise_> heno: uh oh, I was wrong that version still had the menu item :(
<pitti> BenC: ah, right
<tortoise_> I swear I took it out ages ago
<pitti> BenC: %p and %s, indeed
<pitti> BenC: do you happen to know if that helper is still called as root?
<pitti> BenC: (currently we depend on it, and it would require some hackery to have it called as normal user)
<BenC> pitti: it supports pid, uid, gid, signal, time, hostname, executable name
<pitti> sweet
<pitti> nice that apport will work on off-the-shelf upstream kernels then
<BenC> pitti: it appears it is
<BenC> pitti: sort of...we still need to either force core size for apport being enabled, or set it globally
<pitti> BenC: oh, the normal ulimit still applies to the piping, hmm
<BenC> I can make it so that if corename[0]  == '|' that we ignore core size
<pitti> would be a possible solution, yeah
<pitti> BenC: is there a method to set the global limit from userland?
<pitti> BenC: i. e. it would be nice to set that limit in the same place that sets core_pattern (i. e. apport init script)
<pitti> BenC: well, let's think about it in MV
<BenC> yeah
<dholbach> for everybody interested in the motu meeting, we'll start off in a minute in #ubuntu-meeting
<StevenK> Oh drat, I completly forgot about the meeting.
<sivang> what is the channel for loco teams?
* sivang needs a reminder
<Tonio_> pitti: may I ping you concerning this ? https://wiki.ubuntu.com/MainInclusionReportKipi-Plugins
<Tonio_> pitti: we decided to include this during the latest kubuntu devel meeting
<pitti> Tonio_: I can process it now, but three days before RC freeze I'd be a bit hesitant with promotions and package changes
<Tonio_> Riddell: your opinion concerning this ? can we delay to edgy+1 ?
<Riddell> we're not frozen yet
<pitti> Tonio_, Riddell: kipi-plugins-doc should be Arch:all
<Tonio_> pitti: yeah I know kamion told me about that mistake (my fault)
<Tonio_> pitti: wait second I'm reuploading a corrected version...
<pitti> ah, nice
<Tonio_> pitti: that was on my today's todo :)
<Tonio_> pitti: uploaded
<pitti> Tonio_: does kipi-plugins wrap imagemagick, ppmtools etc.? or is it yet another reimplementation? (these imaging libraries are so horribly prone to security issues)
<Tonio_> pitti: it can potentially wrap imagemagik but that's optionnal
<Tonio_> pitti: it's a self implementation in fact, and has its own features
<pitti> Tonio_: it build-deps on libmagick, though
<Tonio_> pitti: true yes
<Tonio_> let me check this exactly
<pitti> if it's only glue between kde and libmagick, this would rock, of course
<pitti> if it's a reimplementation of algorithms, this would be a waste and also yet another source of vulnerabilities
<Tonio_> pitti: well the binary it only recommends imagemagick
<dholbach> What is the current state of -proposed? Does it work? Does it work for universe and multiverse as well?
<Kamion> dholbach: working but restricted by policy (StableReleaseUpdates); yes; yes
<dholbach> Kamion: gracias
<Kamion> whether SRU applies to universe and multiverse is up to you guys; mdz said he'd like there to be at least some similar-looking process
<pitti> Tonio_: weird, why does it b-dep on libmagick then?
<jdong> BenC: when are you going to fix my unusual_dev? :)
<BenC> jdong: Doh, I had that patch ready and forgot to apply it...I'll get it in tonight and upload
<Tonio_> pitti: binary depends on libmagick++9c2a, you're right
<jdong> BenC: thank you :)
<pitti> Tonio_: ah, indeed, I was looking at the wrong version
* jdong shoves shiny FC6 Preview DVD into his test box
<Tonio_> pitti: so the "glue between kde and libmagick" is probably the good option :)
<pitti> Tonio_: well, it's not something I'm entirely happy about at that point in the release, but I do not have a concrete point against it
<pitti> so be it
<pitti> Tonio_: yeah, definitively
<Tonio_> pitti: great, thanks ;)
<Tonio_> pitti: yes, sorry for deciding this so late in the dev cycle...
<elmo> how do you get the a CRT to turn on, when you attach it to a laptop with an i945GM in it?
<elmo> i810switch doesn't seem to recognise the card
<elmo> (and the hotkey doesn't DTRT either)
<mjg59> elmo: Try i855crt
<mjg59> You may need to add the PCI ID
<Fujitsu> mjg59, yeah, I've had better (ie. working) results with i855crt and my i915.
<elmo> mjg59: gracias
<elmo> bah, yeah, need PCI ID hacking - I assume that's a source thing
<mjg59> Yeah
<bddebian> Howdy folks
<dotwaffle> Edgy's ACX100 driver is b0rked, is this the right channel to try and sort out getting it fixed? (I mena b0rked as in the distro, not just on my system - anyone with acx100 wireless can not use their wireless card.)
<mjg59> dotwaffle: In what way? 
<dotwaffle> mjg59: with the acx100 plugged in, there are a few kernel messages, mostly due to missing firmware.
<mjg59> dotwaffle: Is there an open  bug?
<dotwaffle> you need to include the latest version of the driver, and the firmware, for it to work.
<dotwaffle> mjg59: open? no.
<mjg59> dotwaffle: Please open a bug, then
<dotwaffle> although I'm writing one now
<dotwaffle> =)
<dotwaffle> thought i'd ask to see if it's too late for edgy first...
<Kamion> mjg59: don't we have the /bind interface now?
<mjg59> Kamion: ?
<Kamion> echo VVVV:DDDD > /sys/bus/foo/drivers/bar/bind
<mjg59> Kamion: i855crt is a userspace app
<Kamion> to make a driver bind to a PCI ID
<Kamion> replying to this:
<Kamion> 15:35 < elmo> bah, yeah, need PCI ID hacking - I assume that's a source thing
<Kamion> 15:36 < mjg59> Yeah
<Kamion> I mean, assuming my memory is correct, it's quicker than rebuilding the kernel
<mjg59> Kamion: Yes - i855crt is a userspace app that writes to the hardware directly
<Kamion> oh, I see
<mjg59> Kamion: So it has a whitelist of IDs
<Kamion> sorry, I thought it was talking to a kernel module
<mjg59> Ah, ok
<elmo> god damn I hate gcc's insane "LALA UTF-8 quote characters, ENJOY"
<thom> yup
<_ion> What's the problem?
<Kamion> isn't that what the @quot locale thing is for?
<thom> _ion: "array subscript has type char "
<Kamion> gettext automatically generates an en@quot.po without those
<thom> Kamion: oh really?
<_ion> Are your terminal's settings or locale settings wrong?
<Kamion> gcc may not ship that locale though
<thom> hrm, i may just hack buildbot to DTRT
<Kamion> $ LANG=en_GB@quot.UTF-8 gcc -Wall -O2 t.c -o t
<Kamion> t.c: In function 'main':
<Kamion> t.c:5: warning: array subscript has type 'char'
<Kamion> elmo,thom: ^---
<thom> shiny, thanks
* elmo idly wonders why strstr("0000:00:02.0 0300: 8086:27a2 (rev 03)", "8086:27a2") is not doing what I want
<elmo>                 (p = strstr(*buff_ptr, I810_IGSTR)) != NULL ||
<elmo>                 (p = strstr(*buff_ptr, I810_CFCSTR)) != NULL;
<elmo>                 (p = strstr(*buff_ptr, I830STR)) != NULL ||
<elmo> quick, spot the typo!
<elmo> anyhoo.
<giftnudel> I found it, I found it!!! ;)
<elmo> mjg59: this works, but, rawpipe mode doesn't give the full size screen, and chosing a mode (e.g. 1024x768@70) resulted in an extremely corrupt display - any other ideas?
<thom> elmo: does this mean you have a real laptop now? ;-)
<elmo> thom: no, it means I'm designated tech support
<tfheen> if this happens to be a thinkpad, I've had better success poking /proc/acpi/ibm/video
<elmo> tfheen: it is - poke it how?
<tfheen> elmo: cat the file, it should be fairly self-explanatory.
<thom> elmo: oh yum
<tfheen> typically, you do echo crt_enable > /proc/acpi/ibm/video to turn the crt on
<elmo> yeah, not so much
<elmo> # echo crt_enable > /proc/acpi/ibm/video ; grep ^crt /proc/acpi/ibm/video 
<elmo> crt:            disabled
<tfheen> it might have gotten confused after i855crt frobbed it or the module might not like the machine.
<sivang> 
<sivang> ah, ops
<iwj> tfheen: Can I have a UVF exception for new upstream Firefox rc2 please ?
<ogra> iwj, i dont think tollef does UVF exceptions 
<jdong_> ooh, FF2RC2... shiny... must ... have....
<iwj> ogra: The wiki agrees with you.
<tfheen> iwj: please talk to Kamion or mdz.
<iwj> tfheen: Emailing them now, thanks.
<tfheen> I guess I should be added to the list of people who can do UVFs, but I'm not there now, so better to follow the established process.
<iwj> Right.
<elmo> grr
<elmo> https://launchpad.net/distros/ubuntu/+source/i855-crt/+bug/17659
<Ubugtu> Malone bug 17659 in i855-crt "[i855-crt]  no i915" [Wishlist,Rejected]  
<dotwaffle> Oh deary me... "Jesus WEPed but Chuck Norris WPAd!" That barely even makes sense!
<jdong_> dotwaffle: ??
<dotwaffle> crappy gamers thinking they're funny by making Chuck Norris jokes.
* jdong_ thought Chuck Norris would use OpenSSH tun VPN....
<dotwaffle> Chuck Norris doesn't need security. His data packets assault anything that gets in the way of their destionation.
<azeem> dotwaffle: this is off-topic here
<dotwaffle> we had a topic?
<dotwaffle> I just realised, this isn't #lugradio
<dotwaffle> sorry, my fault.
<jdong_> no.. this isn't nearly as entertaining as lugradio.....
<dotwaffle> I'll /part in case it happens again ;)
<Hobbsee> how odd :P
<jdong_> pffft... chuck norris would still use openssh....
<jdong_> Hobbsee: you mean it'd be on-topic in #kubuntu-devel? :D
<Hobbsee> jdong_: no, it'd still be offtopic there. 
<jdong_> oh yeah, that reminds me
* jdong_ goes on to #k-d to drive-by a bug report
* Hobbsee retaliates.
<StevenK> jdong_: is that: /j ; *BANG* ; /part ?
<jdong_> StevenK: something like that :)
<Hobbsee> StevenK: more or less.  
<doko_> infinity, Kamion: looking for the openoffice.org 2.0.4~rc3-0ubuntu3 binaries, not in the archive, not in the queue, build finished 5h ago
<giftnudel> doko_ how can you possibly loose them, they are quite big ;)
<jdong_> lol
<jdong_> who does linux-restricted-modules?
<jdong_> i'd like to talk to him about a UVFe for fglrx
<jdong_> 8.29 restores XVideo acceleration for AVIVO and Xorg 7.1
<shenki> \sh_away: are you really away?
* shenki is 5 minutes late
<infinity> doko_: Looking.
<infinity> doko_: 
<infinity> 09:34:12 INFO    Rejected:
<infinity> 09:34:12 INFO    openoffice.org-common_2.0.4~rc3-0ubuntu3_all.deb: deb contents timestamp check fail
<infinity> ed [exceptions.SystemError: E:Cannot find chunk data.tar.gz] 
* infinity blinks.
<infinity> Let me, uhm, try that again.
<infinity> Fails the same way on the second go..
<StevenK> infinity: Could it be a data.tar.bz2?
<infinity> StevenK: It is indeed, but we have dozens of those in the archive.
<StevenK> Ah
* infinity goes to poke Team Soyuz.
<doko_> infinity, StevenK: it's bzip2 compressed
<infinity> doko_: I know, I tore it apart with ar just now.
<infinity> Team Soyuz is on the job.
<doko_> ok
<infinity> doko_: I'll reprocess the upload when the bug is found..
<infinity> mvo: Around?
<mvo> infinity: yes
<infinity> mvo: The above error string comes from python-apt.
<infinity> mvo: Looks like our upgrading python-apt on drescher made bz2 deb handling explode.
<mvo> infinity: *ick* what does the code look like that deals with bz2?
<infinity> I have no idea what's calling that.
<mvo> infinity: it shouldn't have changed, but dreshers python-apt was very old, wasn't it?
<infinity> Care to join ##soyuz1.0 and trace it with malcc?
<infinity> drescher was runniing hoary's python-apt until just now (edgy's backported now)
<infinity> Well, "just now" being "a few days ago".
<mjg59> ogra: Have you done anything about the g-p-m issue?
<elmo> ok, so, like who tested edgy beta on powerpc?
<elmo> and with what?
<Kamion> I sort of cowboy-tested it
<Kamion> what's failing?
<elmo> Kamion: X ;-P
<Kamion> haha
<Kamion> wasn't that badly broken for me
<elmo> Kamion: on both an Xserve and the shinybook in the office
<elmo> anyone object to me milestoning the relevant bug?
<infinity> doko_: All better now.
<infinity> doko_: Thanks for the heads-up.
<doko_> infinity: do you still plan with subversion1.4 for edgy?
<dholbach> mjg59: hello - the changelog of bluez-utils 3.1-1ubuntu3 mentions 'Fix discoverability of host' - do you remember what you changed? would it make sense to add piscan somewhere? bug 59222 has quite a few people who are confused by not being able to discover the computer
<Ubugtu> Malone bug 59222 in bluez-utils "Computer isn't discoverable" [High,Confirmed]  http://launchpad.net/bugs/59222
<infinity> doko_: "plan" may be a strong word, but if you bug me about it in /msg after I go to bed (in a few minutes), I'll poke mdz about it in the morning and see if he thinks it's too scary.
<BenC> can someone approve linux-source-2.6.15 in dapper-proposed please?
<mjg59> dholbach: I backported some bits from 3.2 to 3.1. If that doesn't work, the sensible thing to do is to bump the version to the latest upstream.
<dholbach> mjg59: the changes are pretty large - I'm not sure Matt will like the changes before Edgy release :-/
<dholbach> debian has 3.7 now, I'll try with them
<mjg59> dholbach: The version we have is an utter crock of shit, really
<dholbach> :-)
<dholbach> mjg59: seems I still have to run    hciconfig hci0 piscan
<Keybuk> mjg59: I have the usplash 100% spin bug, apparently
<mjg59> Keybuk: On what hardware?
<fabbione> elmo: yeah.. ati driver was broken on PPC for beta.. i fixed it afterwards
<fabbione> elmo: specifically the UseFBDev option
<fabbione> elmo: it should be all good now
<ColiFato> hi all
<ColiFato> sorry people.. but i dont know if i can ask a question here about load balancing in ubuntu
<ColiFato> i can do load balancing of 2 internet connections.. one of 300 kbps and another of 128 kbps (download off course) and then download at 400 kbps for giv a number
<dholbach> mjg59: with bluez-gnome's bt-applet (just in debian), I was able to pair (with bluez suite 3.7), sending files from the phone to the box still does not work either - I'll have a look later on
<fabbione> elmo: added comment on the bug.
<_ion> colifato: See topic.
<dholbach> ColiFato: that's more a question for #ubuntu or #ubuntu+1
<elmo> fabbione: thanks, I'm downloading a daily live now
<ColiFato> ok thanxs
<fabbione> elmo: lovely. i am going offline to spend sometime with my son. I guess there is no chance to get ssh access to the xserver in case it still doesn't work?
<fabbione> elmo: upstream has been very active with us to fix stuff
<pitti> mvo: I'm currently looking at the list of open edgy bugs; is there still info required for bug 59079? (It seems not?)
<Ubugtu> Malone bug 59079 in gksu "Edgy uses gksu instead of gksudo (gconf schema not registed)" [Medium,Needs info]  http://launchpad.net/bugs/59079
<mvo> pitti: no, no user info. clue why this happens is required ,)
<pitti> ah
<pitti> mvo: the schema default is true?
<mvo> pitti: yes, the problem is that some people seem to not get a schema at all
<mvo> pitti: we could hack around this in gksu, but finding/fixing the real issue would be better
<pitti> mvo: hm, my current gksu package does not have any schema either
<mvo> pitti: libgksu1.9 has it now
<elmo> fabbione: hmm?  davis is an example of the xserve in question
<pitti> mvo: ah, /usr/share/gconf/schemas/gksu.schemas from libgksu2-0
<mvo> pitti: yep. the postinsts look correct etc. I was not able myself to reproduce it. and no upgrade logs from someone who had the problem
<pitti> mvo: does ~/.gconf allow you to delete a key?
<mvo> pitti: maybe something evil in the upgrade ordering - just speculating - it might be that for a certain amount of time gconf is not fully working 
<fabbione> elmo: i mean get ssh access when running the livecd and to be able to debug the ati driver if the bug is there
<mvo> pitti: I don't know, maybe seb'gconf-master'128 might know. seb128?
<pitti> mvo: but that bug report was apparently about *after* the dist-upgrade
<mvo> pitti: yes, people upgrade and the schema is no longer registered
<pitti> mvo: it would be very weird to entirely remove keys locally
<fabbione> elmo: i will sort of need root power to restart X and change config or gather debugging info... stuff *just* like that..
<pitti> mvo: oh, there is another db of available schemas? it doesn't just loko in /usr/share/gconf?
<mvo> pitti: they must be registered to be usable AFAIK, its not enough to have them in this path
<elmo> fabbione: yeah, that's not very viable ATM, sorry - I'll see what daily's like on this powerbook first, and then get someone to try the Xserve tomorrow
<pitti> mvo: ah, well, that points to a likely point of failure
<fabbione> elmo: ok thanks.
<mvo> pitti: yes, definitely. now we only need to figure out why register sometimes fails
* thom hugs pitti for the new sudo upload
<pitti> thom: does that happen to you a lot? (to me it does...)
<thom> pitti: all the time - mostly i try to run sudo as the wrong user
<jdong> oh sweet!
* jdong hugs pitti, too, after reading changelog
* fabbione takes off
<pitti> thom: heh, for me it's 'sudo apt-get install <make_a_typo>' and the like
<Kamion> there is actually a small amount of information to be gained from that
<LaserJock> jono: got a sec?
<Kamion> namely that you were asked for a password (i.e. that command isn't NOPASSWD)
<Kamion> but it's probably not too big a deal
<pitti> Kamion: hm, but AFAICS the issue is mainly about disclosing information that would help you for brute-force speedups, but you have a point
<pitti> Kamion: however, both 'empty string+enter' and 'Control-C' are logged in auth.log, so I wasn't concerned
<jono> LaserJock, yep
<sivang> tfheen: had a chance to take a look at the changlog entry I've sent you for moin?
<seb128> mvo: pong
<seb128> pitti: no, gconf doesn't allow to delete a key
<seb128> pitti: if there is no user config the schemas is used
<pitti> seb128: ok, thanks; then it seems the file becomes unregistered in the dist-upgrade process
<pitti> seb128: update-desktop-database is responsible for registering?
<seb128> pitti: we already have bug #50150 about weird errors like that
<Ubugtu> Malone bug 50150 in metacity-themes "Configuration editor reports that no schema can be found since latest dapper updates" [Undecided,Rejected]  http://launchpad.net/bugs/50150
<mvo> pitti: it unregisters the old schemas automatically in the prerm rule
<seb128> pitti: no, update-desktop-database is for .desktop
<mvo> pitti: via gconf-schemas --unregister
<pygi> sivang: ping!!!!
<mvo> pitti: dh_gconf adds this automatically to the maintainer scripts
<seb128> pitti: dh_gconf makes the snippets and gconf-schemas (which is a wrapper around gconftool-2) does the registration
<pitti> ah, thanks
<pitti> I don't want to step on your toes, it's just interesting me
<seb128> I'm not sure if there is some sort of weird bug happening to few people
<seb128> or if the few case can be hard drive issue or something
<mvo> my current theory is that something happens when a new gconf is unpacked but not configured yet 
<pygi> hey pitti, seb128 
<seb128> like not sure if that's a gconf bug or just the system not being robust to transitional issues on upgrade
<pitti> hi pygi 
<seb128> hi pygi
<seb128> not easy to get datas on that
<seb128> we would need to log all the gconf registration for everybody to have some luck and get a log of somebody having the issue
<mvo> seb128, pitti: similar to the problem that we had with pango for the breezy->dapper upgrade
<seb128> because usually reinstalling the package works fine for those people
<seb128> mvo: no, the pango issue we had a clear understanding of the issue
<mvo> seb128: or a useful terminal log of a upgrade and *might* contain a error message or something
<seb128> right
<mvo> seb128: not at first (at least I hadn't :)
<seb128> right
<seb128> but postinst does the registration
<seb128> it's not supposed to be able to fail without breaking the postinst
<seb128> and there is nothing supposed to run after the postinst touching the schemas neither
<mvo> seb128: does the schema registration require a runing gconfd-2 ?
<mvo> to work?
<seb128> I'm not sure
<seb128> gconfd-2 is spawned when required
<seb128> and doesn't need a running xorg
<seb128> let me try to run the binary away :p
<seb128> s/run/move
<sivang> pygi: you made it ! :)
<pygi> sivang: ergh, yes!!!
<pygi> pm if you can read it, gotta run soon :)
<sivang> pygi: where you are in anyways? on the moon?
<pygi> sivang: kind of :)
<seb128> mvo, pitti: I would not consider that "some people have schemas not registred" an edgy blocker, we already had such bugs before dapper
<seb128> there is really few of them
<seb128> would be nice to fix but not a blocker
<pitti> seb128: I agree, as long as we do the h4ck1sh workaround for gksu
<pitti> since breaking gksudo can lock out people completly from their boxes
<mvo> seb128: when it happens for gksu it makes the system no longer usable for "normal" users, if we don't find anything I would rather want to add a hacky workaround than to leave it open
<seb128> mvo: what is the workaround about?
* pitti hugs mvo for being in perfect opinion sync :)
<pitti> seb128: default to true if the value is empty
* mvo hugs pitti
<seb128> ah, I'm fine with that
<seb128> it doesn't hurt
* mvo agrees again with pitti
<mvo> seb128: the only "trouble" is that there is no "gconf_get_bool_with_default()"
<pitti> yeah, it's just like hardcoding the schema :)
<mvo> so it will be 1) test_key 2) use default if not found 
<pitti> mvo: hm, but gconftool has to figure out the null value somehow?
<mvo> but not a real issue
<pitti> ah, ok
<mvo> pitti: there is a test-for-key
<mvo> but when gconf_get_bool() returns false
<mvo> you don't know why
* mvo hacks it into libgksu2 now so that we have it for edgy
<seb128> mvo: what do you mean?
<pitti> seb128: 'false' can mean 'key found, value false' or 'key not present'
<seb128> pitti: there is gconf_client_get_without_default() and gconf_client_get_default_from_schema()
<elmo> rah so much hate
<janimo> seb128: thanks for the python-extras upload :)
<seb128> janimo: np
<elmo> tfheen/mjg59: ACPI doesn't work even after a reboot, crt_enable just doesn't. i855crt 'works' in as much as a visible copy of the screen is displayed on the monitor, but the colours are all SNAFU and the mouse isn't visible
<elmo> either of you (or anyone) got any other ideas how I can get this damn Thinkpad to talk to a monitor?
<mjg59> elmo: What model?
<elmo> X60
<elmo> ah, google suggests fucking with xorg.conf
<mjg59> What bit depth is it configurd to?
<elmo> 24-bit
<mjg59> You can fuck with xorg.conf, but you'll be stuck with the CRT output powered at all times
<mjg59> Try 16, though it's a bit of a long shot
<elmo> mjg59: what's the implications of that - just battery life?
<elmo> (CRT output powered at all times)
<seb128> mvo: no, no need of a running gconfd-2
<mjg59> elmo: Yeah
<elmo> mjg59: any idea how much?
<Keybuk> mjg59: amd64 nvidia 
<mjg59> elmo: Not really
<mjg59> Keybuk: x86emu exploding
<Keybuk> mjg59: you run usplash under x86emu?
<hunger> elmo: Why don't you do a special xorg config for giving presentations? You can then start an extra xserver with that when you need it.
<mvo> seb128: thanks for verifiying, that destroies my nice theory
<mjg59> Keybuk: How else are you going to do vesa on amd64?
<seb128> mvo: np
<Keybuk> no idea, can't it do it?
<Keybuk> is there any debugging I can usefully do?
<mjg59> Keybuk: You need to make real-mode bios calls. amd64 kernel doesn't have vm86 mode.
<elmo> ok, he has 7 hours battery life
<elmo> I don't think he cares
<mjg59> Tollef's been looking at it today
<Keybuk> mjg59: I see
<Keybuk> what broke it?  x86emu update?  usplash using svgalib?
<mjg59> It's never worked
<sladen> hunger: just an extra ServerLayout is needed
<mjg59> Other than via the framebuffer interface
<Keybuk> oh, I usee
<Keybuk> so the bogl stuff worked
<mjg59> Yeah
<Keybuk> but the svgalib stuff doesn't?
<mjg59> Indeed
<Keybuk> I guess the emergency "oh well" is to just use bogl on that hardware?
<mjg59> Now in theory, this should work fine
<mjg59> Since the vesa driver runs happily on amd64
<mjg59> But there's clearly a problem of some sort, and it's awkward to track down
<elmo> mjg59: ok, worked perfectly after adding relevant 3 lines to xorg.conf, thanks
<mvo> seb128, pitti: http://people.ubuntu.com/~mvo/tmp/15_extra_paranoia_for_gconf.diff.patch <- does that look ok?
<pitti> mvo: looks as if exactly fixes the corner case condition
<mvo> pitti: thanks!
<seb128> mvo: looks fine to me too
* seb128 hugs mvo pitti
* mvo hugs seb128 pitti
<elmo> is there any other way to fix the CMOS clock on a powerpc?  hwclock isn't working anymore (no rtc)
<pitti> seb128: d'oh - gnome-sound-properties neither uses gconf nor .asoundrc nor .gstreamer-0.10/registry.xml; Where the heck does it save its settings?
<pitti> seb128: oh, it does use gconf, gconfd just didn't write back the changes; nevermind, sorry
<janimo> mjg59:do you think the usplash can do soemthing to break resume from suspend for a radeon? If I boot w/o usplash it works fine
<edoardo> hi everyone!
<edoardo> you guys
<edoardo> i've downloaded ubuntu-6.06.1-desktop-i386.iso... on my hd it's a 1.4g file, i burned it to a dvd... but the dvd won't boot! so i've loop mounted the iso... and it's seven hundred megs! how come? help!
<dholbach> edoardo: please try rather #ubuntu or #ubuntu+1
<sladen> janimo: very likely, svgalib is doing tinkering
<_ion> Perhaps you somehow concatenated two images to a single file.
<dholbach> hi _ion
<_ion> Hi dholbach
<edoardo> over ther discussions tend not to be technical
<edoardo> *there
<edoardo> come on you guys! i wrote a package that's part of universe! : ) help me out!
<dholbach> edoardo: this is a channel about development of ubuntu
<dholbach> hehe
<pitti> edoardo: sounds like a bad download, really
<edoardo> pitti uh, awright. i'll try and download it again then
<edoardo> thankyou pitti!
<dholbach> bye edoardo :)
<edoardo> byebye everyone! use audio-convert! : )
<edoardo> audio-convert kicks ass! byebye everyone! and thankyou! : )
<janimo> ogra: ping
<elmo> huh, what - how did avahi-daemon become an installed by default?
<sivang> IIRC it was planned for it to be there by default :)
* sivang recalls some discussions with Lathiat about the fact that there needs to be some way to enable or disable it from GUI
<mvo> elmo: its installed, but not enabled, right?
<elmo> not sure, I just saw it being pulled in as part of a dist-upgrade
<elmo> I suspect/hope libnss-mdns isn't enabled at least
<sabdfl> is the python2.5 dep of python-gnome2 a known issue?
<LaserJock> hehe
* LaserJock resists a "Go look at LP" comment ;-)
<mvo> sabdfl: AFAIK yes, I'm looking for the bugnumber now
<seb128> sabdfl: I thought I fixed it, looking if the update built
<seb128> hum, in fact I fixed it for pygtk, fixing it for gnome-python now
<sabdfl> thanks seb128 :-)
<seb128> np
<Tonio_> Kamion, Keybuk: pitti approved kipi-plugins main inclusion report and I seeded it today, since it was decided to add it to kubuntu-desktop. Any chance to get the package to main today or tomorrow ?
<jdong> could a core-dev look at  bug 57872 for me
<Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
<jdong> I attached a proposed fix, people who tried it say that it works well
<Kamion> Tonio_: ok, I'll have a look
<Tonio_> Kamion: thanks
<Kamion> Tonio_: done
<Tonio_> Kamion: perfect, thanks a lot
<mdke_> Kamion: got a mo?
<Kamion> mdke_: yeah
<mdke_> Kamion: I'm trying to figure out how to use buildweb.sh in installation-guide to build more than one arch, but can't. Do you know off-hand?
<Kamion> mdke_: looks like this should do it:
<Kamion> architectures='amd64 hppa i386 ia64 powerpc sparc' ./buildweb.sh
<Kamion> mdke_: or we could just change buildweb.sh to build only the Ubuntu architectures by default
<AlinuxOS> mjg59, ping
<mdke_> Kamion: which archs should I build?
<mdke_> those you've listed?
<mdke_> Kamion: that command still just seems to build one arch for me, I wonder if I've broken the script somehow. I've made very few changes tho
<AlinuxOS> mjg59, https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966/comments/13 unic thing that remains to solve for Georgian (in Edgy).
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Undecided,Confirmed]  
<Kamion> mdke_: try it with 'sh -x ./buildweb.sh' to see if it's bailing out somewhere in the middle
<Kamion> mdke_: yes, the architectures I listed are the Ubuntu ones. actually you could drop hppa if you're building for edgy
<mdke_> Kamion: I'll pastebin the output
<kristog> night*
<mdke_> Kamion: http://paste.ubuntu-nl.org/26099/
<Kamion> seb128: why doesn't python-gnome2-extras depend on the new python-gtkhtml2? not doing so seems like it'll break upgrades
<Kamion> or at least cause the gtkhtml module to go missing on upgrades
<Kamion> mdke_: apt-get build-dep installation-guide
<Kamion> mdke_: in this case it wants you to install gs-common
<Kamion> but you'd probably better grab the lot
<mdke_> Kamion: for the arches? I'm not bothered about the pdf, tbh
<seb128> Kamion: because I overlooked the patch sent by janimo :/
<Kamion> mdke_: then set formats='html txt' in the environment
<seb128> Kamion: fixing now
<Kamion> it's html pdf txt by default
<Kamion> seb128: thanks
<Kamion> I NEWed it a moment ago, so the new version should sail on through
<seb128> thank you for pointing it
<Kamion> np
<mdke_> Kamion: yes, I saw that error, but didn't think it was relevant to just one arch being built
<Kamion> mvo: re bug 61684, you say that the alternate installer needs to be modified. However, the alternate installer uses aptitude install ~tubuntu-desktop (etc.), not apt-get install ubuntu-desktop. Does your statement still stand?
<Ubugtu> Malone bug 61684 in portmap "Removing any u-desktop depdencency marks all other packages for auto-removal (on alternate install)" [Undecided,Rejected]  http://launchpad.net/bugs/61684
<Kamion> mdke_: buildweb.sh is set -e, so it bails out on any error
<Kamion> like most sensible shell scripts
<mdke_> Kamion: oh, I see. Sorry, I'm not familiar with shell scripts
<Kamion> set -e means that commands that exit non-zero cause the whole script to terminate, unless they're "caught" (by 'if', '&&', '||', or constructs like that)
<mdke_> ok!
<Kamion> it basically turns on a simple form of exception handling :-)
<mdke_> so I do formats='html txt' architectures='amd64 hppa i386 ia64 powerpc sparc' ./buildweb.sh
<Kamion> sounds right
<mdke_> ahh, yeah :)
<Kamion> set destination=/wherever if you want it to be somewhere other than /tmp/manual
<imbrandon> Kamion, can you do a giveback rebuild ?
<Kamion> imbrandon: no - I'm not in the launchpad-buildd-admins team
<mvo> Kamion: I think it does, because when I tested it for the beta all dependencies of ubuntu-desktop were marked auto-installed. 
<imbrandon> Kamion, ahh ok
<Kamion> mvo: ok, I can change the installer then, but can we fix aptitude too?
* imbrandon looks arround for someone that is
<mvo> Kamion: I can look at aptitude first thing in the morning. If we fix that, we don't need to fix the installer (I guess)
<Kamion> mvo: either works - tasksel isn't too hard to change
<AlinuxOS> Kamion, when is the debian-installer translation dead-line date ?
<Kamion> AlinuxOS: it's marked on EdgyReleaseSchedule (non-language-pack translations)
<mvo> Kamion: right, I think I remember the problem now. aptitude ~t goes over the tasks and finds that ubuntu-desktop is part of the task and selects it for install. this means that all (not-yet-marked-for-install) dependencies of ubuntu-desktop get marked for (auto)install
<Kamion> mvo: oh, ugh
<Kamion> AlinuxOS: guess I'd better send a quick note to ubuntu-translators@
<AlinuxOS> Kamion, great
* mvo checks his aptitude theory
<AlinuxOS> I've another 200 string to do for debian-installer ! So great to know the deadline date.
<Kamion> AlinuxOS: note that many of them (particularly the later ones) are unlikely to actually be incorporated, because there are 50+ component packages and I don't upload all of them at this point for translation updates
<Kamion> AlinuxOS: those that are in ubiquity itself, I'll certainly import
<AlinuxOS> Kamion, I hope that suspended https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966/comments/13 will soved too.
<Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Undecided,Confirmed]  
<Kamion> but for the rest, your best bet is to get the translations into Debian
<Kamion> AlinuxOS: 55966 is nothing to do with me
<AlinuxOS> Kamion, After debian-installer what chould I do ? Is there something non language pack pacakge
<AlinuxOS> something linked with debian-installer ?
<Kamion> gfxboot-theme-ubuntu too
<Kamion> also ubiquity/+translations for ubiquity's desktop file
<Kamion> and note that debian-installer has two templates, the other of which is the boot menu help files
<Kamion> AlinuxOS: ttf-bpg-georgian-fonts 0.3 failed to build from source; see http://librarian.launchpad.net/4710114/buildlog_ubuntu-edgy-i386.ttf-bpg-georgian-fonts_0.3_FAILEDTOBUILD.txt.gz
<Kamion> cp: cannot stat `./debian/ttf-bpg-georgian-fonts.conf': No such file or directory
<AlinuxOS> Kamion, gfxboot-theme-ubuntu is done... Ubiquity ?
<Kamion> you can check for yourself :) I just incorporated all the pending translations into ubiquity 1.1.30
<AlinuxOS> Kamion, ok. I'll do it.
<AlinuxOS> mjg59, Hello, maybe here ? ;)
<mvo> Kamion: I think changing the installer would be a good option for now, I will look at aptitutde tomorrow, but I don't know yet how hard/easy it will be 
* mvo goes to bed
<Kamion> mvo: ok
<AlinuxOS> Kamion, thank you for infos!
<Kamion> you're welcome
<Kamion> good good, my big pile of changes to make usplash detect resolution correctly on initial d-i installs worked
<Kamion> ... apparently I can't post to ubuntu-translators@
<mdke_> I can moderate it
<mdke_> oh no I can't, we made it subscriber only...
<Kamion> oh, sigh
<Kamion> if I bounced the message to you, could you forward it for me?
<mdke_> sure
<AlinuxOS> Kamion, I think put ubiquity at second place after debian-installer is a good idea.
<Kamion> thanks a lot
<mdke_> sorry, it was the superspam list, and hardly any genuine mails were in the queue
<AlinuxOS> putting ubiquity :)
<Kamion> AlinuxOS: not my call, I don't run Rosetta
<Kamion> nor am I a translator, so I don't know what else is important
<Kamion> I'm reluctant to shout "put all my stuff FIRST kthxbye" :-)
<AlinuxOS> :)
<mdke_> Kamion: posted
<Kamion> mdke_: thanks!
<AlinuxOS> I think that debian-installer,menu stuff and ubiquity should be at the beginning.
<Kamion> ubiquity isn't all that critical - the icon on the desktop should be fairly obvious even if you can't read the text
<Kamion> and that's all that that template controls
<AlinuxOS> :)
<Kamion> well, that and the item in the Applications menu
<AlinuxOS> so only menu and debian-isntaller :)
<AlinuxOS> Kamion, is it normal that ubiquity has only 2 strings ? :)
<Adri2000> could any archive admin sync xmoto please, bug 64404 (uvf exception accepted), mdz Keybuk Kamion ?
<Ubugtu> Malone bug 64404 in xmoto "Please sync xmoto 0.2.2-1 (universe) from Debian Sid" [Undecided,Confirmed]  http://launchpad.net/bugs/64404
<Kamion> AlinuxOS: Yes. As I just told you, that template only handles the text on the desktop. Everything else is incorporated into the debian-installer template.
<Kamion> Adri2000: I'll have a look in a moment
<Adri2000> thanks
<AlinuxOS> Kamion, great. So I concentrate myself on debian-installer
<ajmitch> morning
<AlinuxOS> Kamion, ...and that +50 string are Ubuntu distribution related right ? 
<Kamion> AlinuxOS: I don't understand your question
<Kamion> "+50"?
<AlinuxOS> I've noticed that today incrised number of strings to translate...
<AlinuxOS> circa 50 I think.
<Kamion> AlinuxOS: I don't know exactly, sorry
<Kamion> AlinuxOS: that's because danilos imported a new version of the master translation file from me, and I think it hadn't been updated in a while
<Kamion> for all I know it could date from pre-UVF
<AlinuxOS> Kamion, that's ok... I'll translate them all! :D
<AlinuxOS> Kamion, that's really great that finally users can install Ubuntu with Georgian interface since CD-ROM boot...that's really amasing! :)
<AlinuxOS> I'm proud that Ubuntu is the first distribution that does it!(finally)
<Kamion> good to hear
<joejaxx> hey Kamion may i pm you?
<Kamion> joejaxx: please just ask the question, rather than asking to ask
<Kamion> joejaxx: if you'd asked last night, I'd have answered when I woke up in the morning
#ubuntu-devel 2006-10-10
<Lathiat> sivang: there is a way
<Lathiat> sivang: its in the network prefs
<sivang> Lathiat: /me checks
<Lathiat> system->admin->networking
<Lathiat> general tab
<Lathiat> which crashes for me.. but its there ;)
<sivang> Lathiat: oh nice, that is slomo's patch ?
<Lathiat> sivang: not sure
* sivang attempts to start it
<sivang> Lathiat: did not crash, but then again I do not have any other appliances that would respond to it
<Lathiat> well i maen the 'networking' util crashed
<Lathiat> wouldnt even opern the first screen :)
<sivang> Lathiat: hehe, file a bug or either look for the tons already reported
<sivang> elmo: ^^^ (about the avahi-daemon thiingy)
<Lathiat> oh the networkign thign dying is well known?
<sivang> Lathiat: I think I've seen a couple dying network-admin reports already
<Lathiat> ah ok
<Lathiat> bbl
<Riddell> tfheen: kubuntu accessibility seems to work except that the spelling is wrong in ubiquity-hooks/30accessibility  s/imparement/impairment
<Riddell> (which is my fault)
<Tonio_> Riddell: have you finished your changes to kds ? I have a few things to do too
<milosevic> mdke_ ?
<milosevic> mdke_: ping ^^^
* milosevic is away: [... gomirrito :) lqmL :* ** ]  [sleeping] 
<hile> how does a package appear for translation in launchpad?
<hile> I have some translations for which i can't find a translation page to upload upstream .po files ...
<infinity> The templates and translations are stripped from packages when we build them, then rosetta imports those.  In theory.
<infinity> In practice, I'm not sure precisely what happens, as I've not played with the rosetta side of it, only the buildd side.
<hile> I'll check again if it's in rosetta banshee-plugins and not banshee-official-plugins (package name, source is just banshee-plugins)
<hile> there's no simple 'search package by name' in rosetta either which would be really nice...
<hile> btw, what do you thinkw e should do for a package which does not have translations at all, i.e. seems not to be localized (revelation)
<hile> should I file a bug to launchpad for it, expecting someone to implement localization or what ;)
<infinity> You could try, though you're better off going to upstream (if you know where to find them) to get them to do that, generally.
<hile> of course yeah ... 
<infinity> While we try to forward as many bugs upstream as we can and, occasionally, we might even be interested in localising a pet project here and there, we don't have the manpower to deal with feature requeusts like that all the time.
<hile> just thought if it's tupid idea in the first place
<hile> true
<infinity> It's never a "stupid idea" to ask for someone to use gettext-style string localisatoin in their software, IMO.
<infinity> They may not do it, but it never hurts to ask. :)
<hile> no but it might be stuupid idea not to ask it from upstream and ask it from ubuntu devels ;)
<infinity> Yeah, it's generally something we're not likely to spend our time on, unless it's a highly visible part of the default desktop, and thus has a pretty obvious usability impact.
<hile> ok, what does this mean: https://launchpad.net/distros/ubuntu/edgy/+source/banshee-official-plugins/+translations
<hile> that package  is translatable, it just does not have many translations yet 
<infinity> Yeah, the buildd process did find and strip translations (banshee-official-plugins_0.11.0-0ubuntu1_i386_translations.tar.gz), so if rosetta imports aren't actually running, you might wantto bug the launchpad/rosetta people about it.
<hile> as I said I have translated upstream and sent a patch as bug (not in gnome cvs),  not yet accepted or handled, just would like to push it via launchpad to edgy package as well ;)
<hile> well, I asked on rosetta-users about it
* bluefoxicy yawns
<bluefoxicy> heh wow lots of directories.  Maybe a function to watch recursively would be a good idea.
* bluefoxicy prods readahead a little more
<fabbione> morning guys
<tfheen> Riddell: where do you see that typo?  If it's in gfxboot, that's not from casper.
<tfheen> fabbione: any chance you could tell me why gcc-3.3-doc is uninstallable on sparc?
<fabbione> tfheen: yes.. i need a few minutes to power on everythin
<tfheen> thanks
<fabbione> i wonder why we have gcc-3.3 in main still
<fabbione> tfheen: gcc-3.3 -13 (HI SCOTT) is FTBFS on sparc
<fabbione>  /usr/include/gnu/stubs.h:9:27: gnu/stubs-64.h: No such file or directory
<fabbione> looks like glibc borkage 
<tfheen> fabbione: that explains it; any chance we could get it fixed?  (And I too wonder why it's in main; that might be because of libstdc++5 or something like that)
<fabbione> tfheen: i am looking into it
<tfheen> cheers
<fabbione> but it might require doko/jbailey love
<hile> uhm, funny, the rosetta error page for translations says 'send mail to rosetta-users',  only problem is you have to subscribe first ...
<fabbione> tfheen: looks like glibc borkage
<fabbione> tfheen: i need some time to dig into it
<fabbione> tfheen: but one thing i am sure about....
<fabbione> I HATE YOU ALL!!!! I DO NOT WANT TO HACK GLIBC!!! YOU ALL HATE ME TO DEATH!!! :P
* fabbione takes the green pill
<infinity> tfheen: Yeah, it's in main for libstdc++5.
<infinity> Not really necessary for sparc, so we could just remove the sparc binaries if the FTBFS is a pain to fix.
<fabbione> infinity: nah it's not a pain
<fabbione> it's a missing include that should be provided by glibc
<fabbione> i need a few minutes to dig it... local mirror was rsyncing
<fabbione> tfheen: confirmed.. it's a bug in glibc
<psykoyiko> fabbione: your confirmation wouldn't revolve around asm/processor.h, would it?
<fabbione> psykoyiko: no
<fabbione> gnu/stubs.h becoming a wrapper to include gnu/stubs-{32,64}.h and the 64 not being generated at all
<fabbione> and i think that's just sparc specific
<psykoyiko> ah.
<pitti> Good morning
<fabbione> tfheen: it's actually a general bug.. also i386 and others are affected. except that they usually do not include the -64.h 
<fabbione> hey pitti
<pitti> hey fabbione 
<psykoyiko> should developer support type questions be directed here or in #ubuntu? 
<psykoyiko> by developer support I mean developer questions not directly related to ubuntu development
<tfheen> psykoyiko: this channel is for development of ubuntu, not development on ubuntu.
<psykoyiko> tfheen: Thanks, the lines seemed blurry from my point of view.
<bluefoxicy> bah
<bluefoxicy> I don't know how to approach this problem.
<bluefoxicy> I want to prove that if you have a task that relies on CPU and IO, and you parallelize the CPU and IO, then the time the task spends is precisely the isolate time of the longer task
<bluefoxicy> so for example a task that's primarily CPU bound (say 1.0s CPU and 0.5s IO) will take a nominal time normally (1.5s); but in parallel, take the CPU time (1.0s) and the IO time will be lost because the parallel IO thread is outrunning CPU
<bluefoxicy> whereas a primarily IO bound task (0.5s CPU 1.0s IO) will have a situation where the CPU catches up to the readahead() in the parallel IO thread and waits to get data; but then its following CPU-bound moment has the parallel IO thread skipping over that IO which just happened, and reading the next IO burst.  Eventually this should yield a total time of the IO time (1.0s) plus precisely the last bit of work the CPU does.
<bluefoxicy> oh well.  I'll just sleep.
<popey> heh
<popey> I'm sure someone was listening
<popey> :)
<bluefoxicy> yes but I need sleep :)
<bluefoxicy> I'm still working on writing my own readahead program
<bluefoxicy> this one is going to have the concept of a "monitor," which monitors a directory for access, which gets logged later
<bluefoxicy> (as opposed to /etc/readahead/*)
<psykoyiko> okay, this actually seems like a bug
<psykoyiko> I can't seem to #include <asm/atomic.h>
<sivang> morning!
<psykoyiko> due to a missing asm/processor.h
<bluefoxicy> And also the concept of special types of files, most importantly ELF files, which when being read ahead will only have a subset of sections read in; this part seems interesting to me, because i would lend itself to glibc read-ahead optimizing itself
<bluefoxicy> (glibc takes 1.5 seconds to ldd -r -d openoffice.org and then 0.4 seconds to do same afterwards)
<bluefoxicy> heh.. there's a funky idea, gnome with read-ahead
<bluefoxicy> let's see.. icon is displayed on the screen... yeah I can see this...
<bluefoxicy> I'll spec this up, it'll be better than just babbling on.
<fabbione> hey mvo
<fabbione> mvo: i am not sure #63353 is a glibc bug... the submitter has a messed up mix of dapper and edgy in sources.list
<fabbione> and i can't even reproduce it here
<fabbione> (with apt-get that's it)
<mvo> fabbione: hi! 
<mvo> fabbione: well, his sources.list looks sane, he had only dapper source before he tried to upgrade
<mvo> fabbione: its unfortunate that we don't have the terminal log of the failure :/
<fabbione> such kind of bug would have show up much early and a much more "OMG THE SKY IS FALLING DOWN" style
<mvo> fabbione: yeah, its a odd report
<tfheen> doko_: why is #64946 against gcc-defaults rather than the universe packages?
<dholbach> good morning
<tfheen> dholbach: excellent, I was just looking for you.  You're on the ball for the 6.10-targeted bluetooth bugs, right?
<pitti> hi tkamppeter 
<dholbach> tfheen: I didn't have much luck with them - it'd be nice, if somebody would help looking into that
<dholbach> tfheen: but I'll play with those bugs later on
<tfheen> dholbach: 'k.  I can poke them and see if they're easy to fix
<tfheen> but now I need to go out and pick up a couple of disks.
<dholbach> tfheen: mjg59 said we were crazy to not ship 3.7 (which is in debian)
<dholbach> tfheen: the problems are: 1) computer is not discoverable until you type   hciconfig hci0 piscan   (regression that happened somewhere), 2) pairing does not work  3) nautilus-sendto being broken about bluetooth  and maybe others I can't remember right now :-/
<tfheen> dholbach: that's a fairly big jump.  I'll have to take a look at it.
<geser> tfheen: could you please giveback gnustep-back on i386? thanks
<dholbach> tfheen: his exact words were:    Okt 09 18:10:14 mjg59      dholbach: The version we have is an utter crock of shit, really
<tfheen> dholbach: heh, ok.
<tfheen> dholbach: any chance you could try the version in Debian and file an UVF exception request?  If you can't, I'll do it.
<tkamppeter> hi pitti
<dholbach> tfheen: it's not just syncing from Debian unfortunately
<tfheen> dholbach: why not?
<dholbach> tfheen: because that doesn't just fix all our bugs
<dholbach> but it's a good first step :)
<tfheen> well, we'd still need an UVF exception to go to 3.7
<tfheen> and I care less about it fixing all bugs than fixing all 6.10-targetted bugs
<dholbach> tfheen: right
<Keybuk> seb128: last night's upgrade killed my panel and all the applets
<seb128> hum
<seb128> what packages did you update?
<seb128> killed, like it froze?
<pitti> *me too*
<pitti> seb128: it was just killed and restarted automatically
<seb128> what package did you update?
<pitti> hm, today I had 90 MB worth of dist-upgrade
<pitti> and I upgraded yesterday, too, so something from yesterday
<Ng> I do upgrades each morning, just did this mornings and my panel et al are still intact
<Ng> although I haven't restarted yet ;)
<pitti> seb128: wasn't that bad actually, since the panel restarts automatically I got the new version with new libs for free :)
<seb128> :p
* seb128 upgrades now
<tfheen> dholbach: you never said whether you could handle bluez or not, you just said it wouldn't fix all the bugs. :-P  Can you or can't you?
<dholbach> tfheen: I'd be happy with some help on it :)
<tfheen> dholbach: I'll attack it with fangs and claws once my dist-upgrade finishes then.
* dholbach hugs Mithra^Wtfheen
<dholbach> ;-)
<seb128> hum
<seb128> my panel didn't crash on upgrade
<Kamion> mjg59: was compiz-kde deliberately removed?
<seb128> Keybuk, pitti: did apport collected any crash about that panel restart?
<Keybuk> seb128: it hung, it didn't restart
<pitti> seb128: not for me, it just restarted
<seb128> Keybuk: did you get a backtrace of the hang?
<Keybuk> seb128: http://people.ubuntu.com/~scott/upgrade.txt
<Keybuk> seb128: I couldn't even open a terminal at that point
* gicmo does a blind guess and points to g-v-m
<gicmo> ;-D
<doko_> tfheen: hmm, a MOTU changed that, reverted ...
<tkamppeter> pitti, kamion, you have mail, UVF ER for HPLIP 1.6.9, until when does this need to be packaged. Which hour is the final freeze on Thursday?
<pitti> tkamppeter: the earlier the better; preferably it should be in the archive by tomorrow
<tfheen> I'll freeze the archive when I get to work on Thursday morning, fwiw.
<tkamppeter> pitti, doko_, mvo, I will not have much time today, can someone of you package it? It is only replacing the source tarball by the new one from upstream and moving the fax PPD from hpijs-ppds to hplip subpackage? Thanks.
<pitti> I cannot test it at all
<dholbach> tkamppeter: Hello - do you know how good the chances are for a Lexmark Z43 to work in properly in Ubuntu?
<gicmo> "Sound does work, just not through the speaker jacks. For some reason the current ALSA driver doesn't control the audio outputs correctly. This is a known issue and hopefully will be resolved soon. The optical output plug works, and I currently use this to get sound through an amplifier. Just make sure the IEC958 port is turned on in alsamixer."
<gicmo> FUCK
<gicmo> and I was about the buy the cable but didnt 
<gicmo> grml
<dholbach> tkamppeter: My sister just acquired one of these and wasn't happy with it in a Dapper install
<tkamppeter> dholbach, it probably fails due to the driver "drv_z42" (see linuxprinting.org) not being in the Ubuntu distro. Perhaps current Edgy's Gutenprint supports this model, too but I am not sure. If everything else fails, compile drv_z42 from source.
<dholbach> tkamppeter: Ok, I'll tell her to try with an Edgy LiveCD
<dholbach> tkamppeter: Thanks.
<mantiena-baltix> tfheen: hi
<tkamppeter> pitti, perhaps doko_ or mvo can test and I can perhaps do a test tomorrow (on PhotoSmart 2600) when I can grab the package somewhere
<mantiena-baltix> tfheen: are you online ? I wanna talk about hard disk partitions automount realization in casper
<tfheen> mantiena-baltix: yes, I'm online, but I rarely respond to contentless pings.
<tkamppeter> pitti, another thing is moving over the Fax PPD from the hpijs-ppds sub-package to the hplip sub-package, which does not require real testing but only checking whether it was done correctly by the build.
<doko_> tkamppeter: my printer dies a week before ... :(
<mantiena-baltix> tfheen: ok,  so, I didn't found any code, related to partition automountin in casper bzr, have you some code or not ?
<tfheen> mantiena-baltix: there is no code in the current branch, no.
<mantiena-baltix> tfheen: maybe there is some code in some other branch, for example in http://people.ubuntu.com/~tfheen/bzr/casper/ ?
<tfheen> mantiena-baltix: I doubt it; there was some code written for breezy, but the rest of casper has changed a lot in the meantime.
<tkamppeter> doko_: which model? If it is an HP multi-function device, certain parts can still be working, for example if the printing mechanics is broken it still can fax).
<doko_> tkamppeter: hp6110, it has a fax, yes ... but last I checked, faxing was only working locally
<mantiena-baltix> tfheen: in Previous Baltix Linux distro versions (based on Ubuntu hoary and breezy)  I used automount code, written by Kamion - look at http://people.ubuntu.com/~cjwatson/bzr/casper/automount/casper/pre.d/12fstab
<mantiena-baltix> tfheen: what you think about using same code for current casper ?
<mantiena-baltix> tfheen: less than 50 lines ;) 
<mantiena-baltix> current casper still has 12fstab script in scripts/casper-bottom/
<tkamppeter> doko_, if fax only works locally, that is enough to test the fax capability.
<tkamppeter> If the network interface of your device is broken, simply test it as an USB device.
<Kamion> mantiena-baltix: that code won't work any more
<tfheen> mantiena-baltix: that one won't work correctly due to how udev works.
<tfheen> amongst other things.
<Kamion> it uses partconf, which is not available
<tkamppeter> doko_, and you also do not need a phone line and a destination fax machine. If you hear your device dialling, then HPLIP has done its job.
<Kamion> it would have to be rewritten in a different way
<Kamion> probably iterating over /sys/block or something
<tfheen> it should really rather just be a daemon which mounts all block devices as they become available
<tfheen> similar to g-v-m.
<mantiena-baltix> Kamion, tfheen: it's pretty hard for me to write a daemon :(
<doko_> tkamppeter: ok, I'll look at it. do you have an updated package?
<tkamppeter> doko_, unfortunately, Debian did not pick it up even that it is available for 3 weeks now.
<Kamion> doko_: I assume you'll subscribe ubuntu-archive to bug 64946 when you're ready?
<Ubugtu> Malone bug 64946 in Ubuntu "sync requests / UVF exceptions (Ada packages in universe)" [Medium,Confirmed]  http://launchpad.net/bugs/64946
<tkamppeter> So what needs to be done is ap-get source hplip to get the souurce of the current 1.6.7-2ubuntu2 package
<mjg59> Keybuk: Can I grab you to help work out why zd1211s seem unhappy about the essid being set from /etc/network/interfaces at some stage?
<mantiena-baltix> Kamion, tfheen: btw, in current casper there is a script for finding and mounting swap partitions - this script doesn't use /sys/block :(
<Keybuk> mjg59: sure
<mjg59> Not right now, though
<tkamppeter> and then replace the source tarball by the 1.6.9 one from http://hplip.sf.net/
<tfheen> mantiena-baltix: correct, it doesn't work properly.
<mjg59> Since I can't actually find mine at the moment
<Keybuk> mjg59: isn't that one of the cards that has to be UP before it will accept and essid?
<mantiena-baltix> scripts/casper-bottom/13swap
<tkamppeter> and move over the Fax PPD to hplip (bug 59409)
<Ubugtu> Malone bug 59409 in hplip "Fax PPD not installed by default" [Undecided,Confirmed]  http://launchpad.net/bugs/59409
<doko_> Kamion: ok, done; was waiting for MOTU approval 
<mjg59> Keybuk: Could be, in which case it's possible that ifup is doing the wrong thing in this case
<Keybuk> mjg59: could be
<Kamion> Keybuk: bagsy the backports in ubuntu-archive's queue - I want to work on fixing bugg 63726
<Kamion> er, bug 63726
<Ubugtu> Malone bug 63726 in Ubuntu "backports-changes are currently useless" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63726
<mjg59> Keybuk: It's certainly a card that needs the essid to be explicitly set
<tkamppeter> Perhaps simple changes can also fix bug 58727 and bug 60242, 
<Ubugtu> Malone bug 58727 in hplip "bug in hplip .deb removal script" [Undecided,Unconfirmed]  http://launchpad.net/bugs/58727
<Ubugtu> Malone bug 60242 in hplip "Removing hplip encounters errors: scanner group not empty" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60242
<Keybuk> Kamion: ok
<mantiena-baltix> tfheen: can we make a deal ? if you or Kamion or someone else will rewrite scripts/casper-bottom/13swap in correct way then I can write partitions automounting code in the same way :) Now it's to hard for me to write a daemon without any example :(
<tkamppeter> doko_, perhaps bug 62718 is also a small thingy in the scripts, but when I installed my last two builds of HPLIP 1.6.7, this bug did not occur for me.
<Ubugtu> Malone bug 62718 in hplip "[Edgy]  Current Updates (2006-09-27) Break HPLIP" [Low,Needs info]  http://launchpad.net/bugs/62718
<Keybuk> mjg59: are the "usplash segfaults" and "usplash spins at 100% CPU" bugs the same?
<mjg59> Keybuk: Yes
<tfheen> mantiena-baltix: no; if I get the time to rewrite 13swap I'd write it so it could automount partitions too.
<mantiena-baltix> tfheen: then maybe you can show me some example how to write partition automounting daemon for casper ?
<dholbach> Keybuk: 65030 is a dup and a translation team problem - didn't seb128 tell you that yesterday? or was that somebody else?
<tfheen> mantiena-baltix: dude, I'm busy with the release candidate for Edgy, there's absolutely no way I have time to sit down and fix those bits of casper.  Ask again in a month and I might have time.
<Keybuk> dholbach: I couldn't find the dup bug
<Keybuk> it's certainly not listed against the 6.10 milestone
<Keybuk> and a bug should be open for that until it's fixed
<seb128> it's fixed
<Keybuk> it isn't fixed
<Keybuk> I'm completely up to date today, and I still see it
<seb128> it just needs a damn languagepack upload
<seb128> it's "Fix Commited"
<Keybuk> then it's not fixed until there's been a langpack upload
<Keybuk> how do we get one of those?
<pitti> I'm fine with doing it at any time
<seb128> bug #60047
<Ubugtu> Malone bug 60047 in language-pack-gnome-en-base "Folders with new messages are prefixed 'folder-display|'" [Medium,Fix committed]  http://launchpad.net/bugs/60047
<pitti> but I'd like to do it after all other edgy stuff settled
* seb128 marks it as dup
<Keybuk> seb128: ok, I'll make that targeted against 6.10
<pitti> i. e. tomorrow would be a good time IMHO
<seb128> Keybuk: fine with me ;)
<shawarma> Should kernel bugs be assigned to ubuntu-kernel-team? They're already in the "also notified" list.
<Keybuk> shawarma: let them choose the assignee
<fabbione> shawarma: no. 
<Keybuk> in general, if there's a bug contact for a package, let the bug contact(s) decide
<infinity> shawarma: Yeah, don't assign them at all, please.
<seb128> Keybuk: "deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./" BTW
<shawarma> Keybuk: Ok. So setting it to confirmed and providing info about a fix should be sufficient?
<seb128> Keybuk: daily language packs
<Keybuk> that way an entire team see the bug, and can assign to an individual who's actually going to debug/fix it
<infinity> shawarma: If someone wants to claim (or delegate) a bug, then we use the assignee for that.
<shawarma> infinity: alright. I'll just leave it as is.
<shawarma> Keybuk: Ok. Sounds sane enough. I wasn't sure if it wasn't assigned automatically so that the bugsquad could confirm it first and the assign the team.
<Keybuk> assigning to teams is almost always worthless
<Keybuk> teams should be subscribed, individuals should be assigned
<shawarma> Makes sense.
<shawarma> Ok, thanks.
<seb128> Keybuk: it cleans up the un-assigned list and allow team member to have an overview of bugs the team is responsive for
<Keybuk> seb128: I mean for people not in that team
<tkamppeter> doko_, thanks in advance for your help. Contact me (pref. by e-mail) in case of any problems.
<RicardoPerez> pitti: ping
<pitti> hi RicardoPerez 
<RicardoPerez> pitti: hi! there are no daily langpacks since some days ago. is it correct?
<pitti> RicardoPerez: oh, ugh
<pitti> RicardoPerez: hm, I got packages from today
<RicardoPerez> pitti: ummmmm...
* Spads notes that the supervisor on Alcatraz is Ranger Ricardo Perez
<RicardoPerez> Spads: :D
<pitti> RicardoPerez: however, some time ago I taught langpack-o-matic to only generate a new package if there is actually new data
<RicardoPerez> pitti: my current version is 20061004
<pitti> RicardoPerez: so there might not be a new version for your particular language
<doko_> seb128: ping
<RicardoPerez> pitti: mmmm... strange... carlos change the name of one .mo file...
<seb128> doko_: pong
<pitti> RicardoPerez: oh, indeed, edgy is indeed behind, I was looking at dapper
<pitti> RicardoPerez: will fix, thanks
<RicardoPerez> pitti: ah, great :) thanks to you
<pitti> RicardoPerez: generating new edgy packs now, check again in 1 or 2 hours
<RicardoPerez> pitti: thanks again :) i'll check it
<fabbione> elmo: ping?
<fabbione> elmo: regarding bug #64198, it would be lovely if you can add the info today. I only have a small time window to talk to upstream every day because they are located in different TZ. otherwise we risk to take ages to get that fixed
<Ubugtu> Malone bug 64198 in xserver-xorg-video-ati "LiveCD can't start X on Apple Xserve or PowerBook" [High,Confirmed]  http://launchpad.net/bugs/64198
<Keybuk> doko_: ping
<sivang> pitti: has there been soem changes recently to how hal reports information volumes in optical drives et al ?
<doko_> Keybuk: pong
<sivang> pitti: hubackup CDROM detection code breaks now becuase what seem like layout change in child and parent nodes on the tree..
<Keybuk> doko_: bug #63747
<Ubugtu> Malone bug 63747 in openoffice.org-amd64 "please remove the openoffice.org-amd64 source" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63747
<Keybuk> shall I do that now?
<doko_> Keybuk: yes please! :)
<pitti> sivang: actually not; hal upstream version didn't change since dapper
<pitti> sivang: only a couple of patches, but I cannot remember any of them touching CD stuff
<sivang> pitti: CD volumes now appear to be a child of the CD/DVD/CDROM  'device' node.
<pitti> doko_: yay :)
<pitti> sivang: that's how it's supposed to be
<sivang> pitti: rather then being populated in the device node, as I recall it was..
<pitti> sivang: and I don't remember it ever being different
<pitti> sivang: bus -> controller -> drive -> volume
<sivang> pitti: hmm, I see. it does make much more sense, I guess it's me flipping :-)
<sivang> thanks anyway
<pitti> sivang: np :)
* sivang goes back to media detection bugs.
* pitti giggles at -DOSARCH=\"Linux\" when building mozilla
<thom> heh
<pitti> hi thom, how's it going?
<thom> going well
<thom> und du?
* dholbach hugs thom
<madduck> tfheen: ping!
<tfheen> madduck: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<madduck> tfheen: this was on purpose...
<madduck> wouldn't it be better to /msg privately?
<madduck> just thinking...
<thom> dholbach: hey duder
<dholbach> thom: Alter!
<dholbach> :-)
<pitti> thom: cold disappears slowly, I'm fine :)
<hunger> pitti: You were at akademy in dublin?
<pitti> hunger: no, I wasn't
<sivang> pitti: anything I can kill in order to release a cd from the drive? eject /pumount / gui eject won't work on account it's busy.
<hunger> pitti: Oh, I thought because of the cold... everybody that has been there got one;-)
<sivang> pitti: never mind, managed it.
<pitti> sivang: fuser -k? :)
<pitti> but I wouldn't recommend that
<sivang> pitti: cool, would come useful for testing.
<Kamion> madduck: personally I hope that Tollef's script complaining publicly will reduce the incidence of contentless pings
<madduck> Kamion: yeah true. i have adopted it too.
<Riddell> tfheen: the spelling is wrong in ubiquity-hooks/30accessibility in casper
<Riddell> it needs to be changed to match scripts/30accessibility
<sivang> crap, cdrecord got hung up on blanking a media
* sivang curses cdrecord
<giftnudel> fuser -k?
<giftnudel> ;)
<ogra>  human-cursors-theme (0.2-0ubuntu1) edgy; urgency=low
<ogra>  .
<ogra>    * New release:
<ogra>      - moved cursor-theme from human-theme.
<ogra> dholbach, ^^^^
<ogra> did you also move the alternative setup ?
<dholbach> yes
<ogra> thanks :) 
<dholbach> you could have looked before you asked ;-)
* dholbach hugs ogra
* ogra fixes the ltsp workaround :)
* ogra hugs dholbach 
<dholbach> cool
<tfheen> Riddell: fixed
<Riddell> thanks
* sivang discovers that a hal oddity caused hubackup not to detect an empty never used DVDRW and calms down.
<Ng> sivang: does hubackup use gnome-vfs at all? like can I direct backups to a remote machine easily?
<giftnudel> sivang: where is the main development branch of hubackup which I can check out to fiddle with it?
<sivang> giftnudel: I love you forever ((tm) Martin Pitt) if you could join me in helping :-)
<sivang> Ng: yes. the new version in edgy now uses a stock GNOME file selector that will allow your to save backup to any gnome-vfs mounted target.
<giftnudel> let's say it that way, I like python and I like the idea, if I can help is really another question ;) (but I can try)
<sivang> giftnudel: the really recent branch is now http://muse.19inch.net/~sivan/bzr/hubackup/hubackup--main
<Ng> sivang: how new? I just ran it and it didn't show my gnome-vfs mounts in the selector
<Ng> but maybe I have an older version
<sivang> Ng: you on edgy?
<Ng> yup
<sivang> Ng: what kind of mounts do you have?
<Ng> sivang: I have two sftp mounts in my Places menu
* sivang checks
<Ng> sivang: also, in the backup/verification windows, when it says it's finished, the button to make it go away still says "Cancel"
<Ng> funky little app though :)
<sivang> Ng: interesting. Either the stock selector lies, or I used it wrongly. Could kindly file a bug?
<Ng> certainly
<sivang> Ng: and also for the latter one? O:-) 
<Ng> will do
<Ng> I have a couple more too ;)
<sivang> Ng: thank you. It started off as something "will be finished in no time" and continues growing at an alarming rate :-)
<sivang> Ng: The amount of implementation issues discovered in attempting to bring the "no worries" workflow is enurmous.
<Ng> that sounds quite normal ime ;)
<Keybuk> pitti: ping
<pitti> hi Keybuk 
<Keybuk> pitti: has anybody spoken to you about kexec-tools and main?
<Keybuk> or command-not-found ?
<sivang> Ng: I hope so :-p
<pitti> Keybuk: no
<Keybuk> pitti: kexec-tools is a dependency of the linux-image-kdump package
<Keybuk> and command-not-found is seeded in desktop
<pitti> Keybuk: l-i-kdump should go into main?
<tfheen> Keybuk: linux-image-kdump should be demoted.
<Keybuk> pitti: we main anything built by the kernel by default
<Kamion> it's hard to express that demotion in the seeds without expanding the %linux-meta entry, unfortunately
<Kamion> which would be annoying
<Kamion> is anyone working on a glibc upload?
<infinity> linux-image-kdump isn't in linux-meta, it's in linux-source.
<Kamion> infinity: good point
<sivang> Ng: If you would, I'd like to have all your discovered bugs, thank you :)
<infinity> THough I suspect the same argument may apply. :)
<Kamion> it doesn't. why's linux-image-kdump in supported then ...
<Keybuk> Kamion: because I put it there
<Kamion> oh
<Keybuk> you said to main anything built by linux-source, remember ;)
<tfheen> I removed it yesterday, though
<tfheen> it's not in the germinate output
<tfheen> so it should be demotable.
<Kamion> let's drop it back and get Ben to put universe/ in its control file
<infinity> Right, so we're just talking in circles, but everything's okay? :)
<Kamion> so the queue is still easily processable
<infinity> Kamion: I already asked him to put universe/ in the control file, for the sake of our sanity with queue/new, yes.
<Keybuk> tfheen: it's still in *ubuntu supported
<tfheen> Keybuk: oh, probably yes.  That's easy to fix, though.
<Kamion> I'm wondering whether I should fix bug 63234 by adding librt to libc6-udeb (which is what Debian did, but is an extra bit of space used just for xfsprogs) or link xfsprogs against librt statically
<Ubugtu> Malone bug 63234 in debian-installer "installer unable to format xfs" [Undecided,Confirmed]  http://launchpad.net/bugs/63234
<Kamion> leaning towards being in sync with Debian
<Kamion> (it's only 30K)
<infinity> Kamion: I'm sure something else will want it eventually.
<Keybuk> ok, so mdz put command-not-found into desktop
<Kamion> yeah
<Keybuk> but didn't make an MIR for it
<infinity> Kamion: Like the guy who complained on ubuntu-devel@lists a day ago.
<Kamion> infinity: ?
<infinity> https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021560.html
<Kamion> /usr/lib/cdebconf/frontend/gtk.so doesn't link to librt directly in Debian, although it may do indirectly for all I know
<mantiena-baltix> dholbach: hi, I wanna talk about translations in ubuntu-docs package, do  you have some time ?
<dholbach> mantiena-baltix: I doubt I'm the right person for that
<dholbach> mantiena-baltix: but what is your problem?
<giftnudel> sivang: do you have any small things you liked to do to hubackup but have never gotten around?
<mantiena-baltix> dholbach: I found you in changelog of ubuntu-docs package :) in Ubuntu Dapper ubuntu-docs source package was ~7Mb size, but  in edgy it's less than 1 MB, it seems translations were removed, right ?  
<dholbach> mantiena-baltix: you might want to talk to mdke or people in #ubuntu-doc - I'm not sure, but I guess that translations should be in the language-packs, no?
<mantiena-baltix> dholbach: I also think so, but in dapper all translations were in ubuntu-docs package :(
<mantiena-baltix> ok I will talk on #ubuntu-doc
<dholbach> ok cool
<infinity> Files: 
<infinity>  42034af3a900c210a282d677ae6a0322 327544 text optional ubuntu-docs_6.10.1_all.deb
<infinity>  0a4a580670e541d70d30dd40030f121c 122965 raw-translations - ubuntu-docs_6.10.1_i386_translations.tar.gz
<infinity> The translations were stripped and fed to rosetta, so they'll be in the langpacks.
<dholbach> Thanks infinity.
<mantiena-baltix> infinity: ok, thanks
<infinity> Well, some translations anyway, I don't know if that's "all of them"
<infinity> Cause I'm not sure how the package is laid out.
<sivang> giftnudel: let me think :)
<Keybuk> tfheen: can I make a really scary request?  we ship gettext 0.14 which isn't completely compatible with the version of autoconf and automake we ship (doesn't support datarootdir)
<Keybuk> could we merge that with Debian's 0.15?
<tfheen> Keybuk: how big and scary is the diff?
<fabbione> tfheen: are you sure you want to know? :P
<tfheen> fabbione: I LOVE big and scary diffs.  Didn't you know?
<fabbione> tfheen: ehhee
<Keybuk> tfheen: the diff between 0.14.6-1 and 0.15.2 ?
<Keybuk> oh, a mere 21MB
<tfheen> uh.
<tfheen> that's.  scary.
<tfheen> is there anything which is _broken_ if we don't upgrade?
<Keybuk> I wouldn't ask, except the merge is clean and it's in unstable
<Keybuk> in theory any package developed on Ubuntu that uses gettext is fractured
<Keybuk> not completely broken
<Kamion> and in practice?
<Keybuk> it means ./configure --dataroot=/usr/share won't do the right thing
<Keybuk> it'll put translations in /usr/local/share
<tfheen> that single thing sounds backportable quite easily.  Isn't it?
<Keybuk> it's hard to gauge because --dataroot is new, so most people may still be building with --datadir= instead
<Keybuk> tfheen: it involves remaking Makefile.in.in ... which is ... N-hard
<Keybuk> it certainly means any software developed on Ubuntu gives an ugly warning during ./configure
<seb128> dholbach: ubuntu-docs translations to rosetta, how would that work?
<Keybuk> it may be enough to just add datarootdir = @datarootdir@ to the one in our package
<seb128> dholbach: aren't documentation file .xml which have to be translated (ie: don't use gettext)?
<Keybuk> tfheen: yes, that gets rid of the warning
<seb128> Keybuk: I've seen warnings about that for a bunch of packages with autoconf updates too
<tfheen> Keybuk: I'd be far happier with that than a new upstream version of gettext, really.
<Keybuk> seb128: yes, updating autoconf or automake and not updating gettext is the cause
<Keybuk> tfheen: I'm just grepping gettext for any use of that variable, other than having it in Makefile.in.in to allow datadir to be defined based on it
* Keybuk can't find any
<tfheen> ok, so let's just go for the one-line patch solution then?
<Keybuk> yup
<Kamion> right, I think that's LVM and RAID in a rather healthier state in the installer now
<fabbione> Kamion: there was another duplicate bug of the one you just closed...
<fabbione> Kamion: can't remember the number tho
<Kamion> you mean one not already marked as a duplicate?
<fabbione> probably....
<Kamion> if you find it, feel free to mark it
<tfheen> dholbach: it seems nautilus's sendto thingy with obex doesn't work because gnome-obex-send doesn't grok gVFS URIs.
<fabbione> the one in which i did add comments..
<fabbione> Kamion: willdo
<Kamion> ta
<dholbach> seb128: you can use translations for .xml files too
<dholbach> seb128: isn't @INTLTOOL_XML_RULE@ for stuff like that?
<dholbach> tfheen: ahhhhhh!
<dholbach> tfheen: I'll have a look at that after lunch
<tfheen> dholbach: so it gets a file not found when passed file:///whatever.  Thanks. :-)
<dholbach> tfheen: thanks
<tfheen> dholbach: and we'd need to get bluez-gnome in, but that's doable.
<dholbach> tfheen: for main?
<dholbach> tfheen: did you play with it?
<tfheen> dholbach: bluez is kinda useless if you can't pair your phone, don't you agree?
<dholbach> I do
<funman> hi
<seb128> dholbach: not that I know of
<tfheen> dholbach: are you in touch with fschoep?  Any idea about when we'll get the final artwork?
<seb128> dholbach: usually such magic is to list strings to a .po so translators can translate them
<dholbach> tfheen: I'll prod him about it.
<tfheen> thanks
<seb128> dholbach: then transitions are used to build translated .xml during the build
<tfheen> dholbach: please do remind him that we freeze on thursday.
<seb128> s/transitions/translations
<dholbach> seb128: I'm not sure, that's why I pointed him to #ubuntu-doc
<sivang> giftnudel: so for the free space in a multi session CD, there are some hints in nautilus-cd-burner we might be able to borrow. However, they are in C and not in python.
<seb128> ncb doesn't do multisession
<giftnudel> sivang:  if ncb can't do that. then I'll see how gnomebaker does that
<sivang> seb128: true (due to the fact that CDs are so cheap these days ;-)) but I'm sure I've seen code there that reports how much free space is left on A CD.
<sivang> giftnudel: that would be cool, thank you!
<giftnudel> i'm sure they got that right ;)
<tfheen> ok, so the bluez-passkey-gnome seems to work.  That means we "just" have to get the hci config to scan by default
<Keybuk> tfheen: so this gettext thing turns out to be hard
<Keybuk> the Makefile.in.in and Makefile.in that need patching are inside archive.tar.gz
<Keybuk> which is a tarball inside the orig.tar.gz\
<Keybuk> (so can't be patched by diff.gz)
<tfheen> well, we can repack the orig.tar.gz if we really want to.
<tfheen> or we could have a patch system in there.
<Keybuk> patch system can't patch binary tarballs?
<tfheen> it could unpack and repack the tarball
<tfheen> ugly, agreed
<Keybuk> this seems rather intensively evil just to avoid updating the tarball
<Keybuk> and more error-prone
<tfheen> heno: have you heard anything from TheMuso regarding casper and accessibility?
<tfheen> Keybuk: well, let's just repack the tarball then.
<Keybuk> oh, and not only are they inside the archive.tar.gz
<Keybuk> they're RCS files!
<tfheen> \o/.  Or something.
<heno> tfheen: no, but he should be here
<heno> tfheen: can you point me at the actual scripts somewhere so I can have a look
<lifeless> t east RCS files are patchable
<heno> alternatively, any suggestions on debugging it?
<seb128> heno: hi, should bug #59553 be fixed for edgy? did the patch get testing?
<Ubugtu> Malone bug 59553 in control-center "launch AT apps from gnome-at-prefs" [Wishlist,Confirmed]  http://launchpad.net/bugs/59553
<tfheen> heno: apt-get source casper gets you something which is fairly fresh and up to date.
<heno> seb128: yes please. I've tested it myself, but I think that's it
<heno> tfheen: thanks
<seb128> heno: ok, I'll look at it now
<Fade> tfheen: I updated the xemacs bug with the workaround.
<Keybuk> lifeless: are you saying RCS is better than bzr? :)
<Fade> the segfault is still there, but it should be pushed upstream, imo.
<tfheen> Fade: fabbione did some font updates which could have fixed this yesterday or so
<Fade> I had already updated my configs at that point, so I can't verify.
<sivang> giftnudel: n-c-b seems to be using gnome_vfs_get_volume_free_space, it probably should have some python bindings we coudl use, but make sure this reports free space on multisessoin CDs (RW/R)
<giftnudel> I just created a multisession cdrw
<fabbione> tfheen: unlikely.. the changes were related only to versioned Depend to fix dapper -> edgy partial upgrades
<giftnudel> sivang: cdrecord -msinfo does return some information for mkisofs, maybe this is usable too
<tfheen> fabbione: hmkay.
<sivang> giftnudel: true, see if you can find a way to integrate it into DeviceInfo.py's list, I actually experimented with this not sure why I left it eventually.
<giftnudel> sivang: I see if, at some point can get a reliable size
<lifeless> Keybuk: in this one regard, it can do something bzr can't :)
<giftnudel> sivang: gnomebaker uses the -msinfo info and seems to get the size from there, I'll see if I can find out how they do it ;)
<sivang> giftnudel: hehe, funny, What about the gnome-vfs thingy?
<giftnudel> well, they don't use it
<sivang> giftnudel: okay, cool, let's stick to the gnomebaker approach
<sivang> giftnudel: if we can come up with two functions, one that tells the complete volume / media size (not free space) and ones that tells the free space left on a medium, we win. the former will also cater for hal's reporting capacity basically as volume size.
<sivang> giftnudel: (this sometimes breaks setting up correct slice size)
<kristog> hello
* sivang -> lunch
<mantiena-baltix> pitti: could you tell me if regexps are supported in /etc/pmount.allow ?
<pitti> mantiena-baltix: no, not right now
<mantiena-baltix> pitti: I found some code in device_whitelist:
<mantiena-baltix>  const char*  whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$";
<mantiena-baltix> pitti: what does this code ?
<pitti> mantiena-baltix: it checks the validity of an entry in the whitelist
<pitti> mantiena-baltix: basically, a device name surrounded by some whitespace and comments
<mantiena-baltix> pitti: could you add support for regexps in pmount.allow ? It would be very good to have an ability to write for example /dev/sd* in pmount.allow to have an ability to mount all SCSI/SATA devices
<giftnudel> sivang, do you know how they do it? They try to mount the cd and add up the size of all files in the disc
<pitti> mantiena-baltix: I'm not convinced that this is very useful, but feel free to file a wishlist bug :)
<pitti> mantiena-baltix: IOW, I agree that this is an useful feature, but it's not high-priority on my todo list
<mantiena-baltix> pitti: It's hard to add regexp feature for /etc/pmount.allow ?
<pitti> mantiena-baltix: not terribly, no, just a SMOP
<Keybuk> tfheen: nope, there is no way to do this
<Keybuk> not without serious RCS-file surgery of a revision several away from the head, and manual fixing of those since
<Keybuk> (it checks out against a tag)
<tfheen> Keybuk: *sigh*.
<Keybuk> they've done everything possible to make it impossible to just patch that file :-(
<tfheen> and the archive.tar.gz is what's shipped in the deb?
<heno> tfheen: I grabbed casper version 1.73 from LP; I assume I can use that. I see various obsolete things in the script. I'll update and make a patch.
<Keybuk> tfheen: yeah
<mantiena-baltix> pitti: I could try to add but my regexp knowledge is not big, especially for regexps in C :(
<pitti> mantiena-baltix: well, the function already handles regexps for checking the pmount.allow format
<infinity> A little RCS surgery never killed anyone.  In fact, it used to be a hobby of mine.
<pitti> mantiena-baltix: you can use the same scheme for matching the entry against the device name
<StevenK> infinity: Yes, but you're a masochist.
<Kamion> mantiena-baltix: for a start, "/dev/sd*" isn't a regex, unless you really mean "/dev/s followed by zero or more d characters"
<tfheen> heno: excellent, thanks.
<Kamion> mantiena-baltix: the correct term for things like /dev/sd* is "glob" or "shell pattern"
<mantiena-baltix> Kamion: ok, I mean glob support in pmount.allow
<Keybuk> tfheen: so what you want to do?
<pitti> mantiena-baltix: yeah, I would be more comfortable with globs, too
<tfheen> Keybuk: strangle the hcid author?
<tfheen> Keybuk: about gettext.. if Adam volunteers to hack the ,v file, let him?
<sivang> giftnudel: maybe they export this function of their as a module ?
<sivang> giftnudel: so we could just import or use?
<Keybuk> tfheen: want to do it?
<Keybuk> it's two RCS files inside archive.tar.gz inside the orig.tar.gz files
<mantiena-baltix> pitti: regcomp function handles globs or I should use another function for this ?
<Keybuk> gettext checks out some arbitrary old revision
<tfheen> dholbach: so, do you actually have any bluetooth hardware?  If so, can you test a fix for me.
<pitti> mantiena-baltix: no, regcomp handles regular expressions
<tfheen> Keybuk: a revision and not just a tag?
<pitti> mantiena-baltix: use glob() for shell patterns (globs)
* sivang wish bzr would remember the push location after one time pushing a place
<pitti> sivang: it does after pushing the first time
<giftnudel> sivang: for me it does that
<Keybuk> tfheen: I honestly don't know, it's a maze of twisty shell that does it
<tfheen> sivang: bzr push --remember ?
<pitti> sivang: if you want to change it, use --remember
<jdong> sivang: --remember; set up branch aliases if you want to remember more
<Keybuk> and, annoyingly, gettextize and autopoint appear to do different things
<sivang> tfheen: yep, that's what i needed. it never does it automatically for me for some odd reason.
<sivang> jdong: haha
<sivang> jdong: that is read as a natural language sentence :)
<jdong> lol :)
<dholbach> use --remember
<tfheen> Keybuk: I'm really not happy about putting in a new upstream version at this point -- particularly not something where the diff weighs in at 21MB.
<giftnudel> sivang: what do you mean, gnomebaker is c as well?
<Keybuk> tfheen: I can understand that, but I don't think we should ship a broken gettext either
<Keybuk> as this affects any developer who uses ubuntu, and all their users
<tfheen> Keybuk: yes..
<infinity> Keybuk: What's the bug# here, and the patch that needs applying?
<giftnudel> sivang: anyhow, I get a feeling why you stopped looking at it (there is no really easy way to do these things, for example, get the size of a cd medium)
<Keybuk> infinity: I haven't filed a bug yet
<infinity> Keybuk: Can you? :)
<Keybuk> infinity: the patch is adding "datarootdir = @datarootdir@" before the datadir= line in ever occurance of po/Makefile.in.in and intl/Makefile.in
<infinity> Keybuk: I'll poke at the RCS hacking route, and if it looks sufficiently low in crack, I'll just do it.
<ogra> infinity, any news about the archive bug that makes my ppc CD explode ?
<Keybuk> infinity: the RCS tree is inside archive.tar.gz, it checks out a non-head revision to copy into the package when you update it
<infinity> If not, we'll need to argue about the right thing to do.
<infinity> (Maybe checkout both branches, and alter the build system to just used the checked out copies, or similar scariness)
<Keybuk> build system?
<Keybuk> nothing to do with the build system
<Keybuk> this is the installed system
<Keybuk> /usr/share/gettext/archive.tar.gz
<sivang> giftnudel: yes, it's very discouraging. I wish there was a unified API for this things, but there will not be , until libburn will be finished with multi session support.
<sivang> giftnudel: still, just copying with gnomebaker does could be useful, no?
<zul> pitti: ping
<pitti> hey zul
<sivang> giftnudel: hal also does not make it easy, as 'capacity' is always the size of the volume, not the true capacity of the medium.
<sivang> anyway, I really need to get lunch now before I'll drop! 
<Keybuk> bug #65063
<Ubugtu> Malone bug 65063 in gettext "Doesn't support datarootdir" [High,Confirmed]  http://launchpad.net/bugs/65063
<sivang> giftnudel: ttl
<giftnudel> ok
<zul> pitti: hi i have a question on one of the security patches for the kernel-sec svn, the s390 patch we shouldnt really care about it should we?
<pitti> zul: I marked it as 'ignore'
<zul> ah ok
<pitti> zul: since we don't have that platform anyway, not even as port
<zul> pitti: heh i just needed more coffee
<sivang> giftnudel: that was meant with a ;-) , sorry for not supplying it
<giftnudel> sivang: yes, the gnomebaker approach of just opening the disc and reading the size of all files seems the easiest way
<giftnudel> sivang: oh, I understood it that way
<tfheen> dholbach: if you have any bt hardware, please try adding "discovto 0;" (no quotes) in the device { section in /etc/bluetooth/hcid.conf, rm -rf /var/lib/bluetooth/* and restart hcid/bluetooth.
<pitti> infinity: do you see any reason to keep php4 in edgy?
<pitti> infinity: I'm just doing another php security update and I'm too lazy/busy to fix it for the universe php4's, too
<infinity> pitti: I see reasons to keep it in Etch, but if you'd prefer to drop it from Edgy, I don't know if I care so much.
<infinity> pitti: We draw such a clear line between supported and unsupported, that people would be a fool to run the "alternate php" anyway.
<pitti> infinity: oh, wait, it has a fair number of rdepends
<infinity> (It does still have uses, but most stuff should work with both)
<giftnudel> sivang: I'll write down what I found out and what we could try, i have an idea, I will notify you when it's ready
<infinity> Keybuk: Right, s/build system/whatever the fuck does an RCS checkout/ then.
<infinity> Keybuk: Anyhow, file a bug and subscribe me to it, SVP?
<StevenK> infinity: [23:11]  < Keybuk> bug #65063
<Ubugtu> Malone bug 65063 in gettext "Doesn't support datarootdir" [High,Confirmed]  http://launchpad.net/bugs/65063
<infinity> StevenK: Thanks, I'm half asleep.
* StevenK managed to nap watching TV.
<Keybuk> infinity is clearly a "glass half empty" kinda guy
<tuhl> what is the right channel to discuss xen on edgy?
<zul> #ubuntu-xen or me
<tuhl> crimsun: I solved the python problem, by removing all packages and reinstall them :-)
<tfheen> zul: oh, speaking of xen.  Any reason why the ubuntu-xen repo's master branch isn't the right one?
<zul> tfheen: for 2.6.16 or 2.6.17?
<tfheen> zul: we have/want to switch to .17 don't we?
<zul> we have switch to .17
<mantiena-baltix> pitti: pmout uses debug function for debug messages - how I can read these messages?
<pitti> mantiena-baltix: pmount -d
<zul> i just havent had a chance to update the git repository yet for 2.6.17
<tfheen> zul: ok.
<pitti> mantiena-baltix: or, if you use pmount-hal, export PMOUNT_DEBUG=1
<pitti> mantiena-baltix: (see manpages)
<zul> tfheen: its on my todo list for tonight
<tfheen> zul: cool, thanks.
<mantiena-baltix> pitti: thanks
<jdong> who do I subscribe in LP for UVF exceptions?
<jdong> the wiki's down so I couldn't pull up the doc
<giftnudel> sivang: http://paste.ubuntu-nl.org/26158/ - I have put down the idea there
<giftnudel> pitti: I don't understand why you closed bug 59981 again, this is the exact same issue /etc/dbus.d/event.d/20hal restart, 25networkmanager restart did fix this (as before)
<Ubugtu> Malone bug 59981 in hal "suspend makes network-manager say eth1 is a wired device" [Undecided,Fix released]  http://launchpad.net/bugs/59981
<pitti> giftnudel: NB that you have to restart hal, not network-manager
<pitti> giftnudel: i. e. reboot to be on the safe side
<pitti> giftnudel: and the fix was confirmed by several other people
<pitti> if it doesn't work for you, then it must be a different cause
* pitti -> lunch (really for now), bbl
<giftnudel> well, it worked for me too, but I had this once in 7 suspends ...
<giftnudel> yeah, guten appetit
<mantiena-baltix> tfheen: I have one good idea about mounting hard disk partitions in live CD :)
<mantiena-baltix> tfheen: you told, that we need a daemon like gnome-volume-manager, right ?
<mantiena-baltix> tfheen: so, maybe we don't need another daemon, maybe we should just improve gnome-volume-manager  ? ;)
<pitti> giftnudel: re
<giftnudel> pitti: let me reboot and see if I get that again, but I'm really sure that I installed the most recent version before I got this problem
<pitti> giftnudel: ok
<giftnudel> pitti: also, I wouldn't have reopened it, if there hadn't been a duplicate reported today
<pitti> giftnudel: do not get me wrong, I don't blame you for that, I just want to track them properly
<Kamion> ogra: the archive bug is fixed; your next CD builds should be within size limits
<Kamion> jdong: ubuntu-release
<Kamion> jdong: (for main; I forget for universe)
<jdong> Kamion: yep, thanks, figured it out
<ogra> Kamion, yippie, you roock !
<ogra> -o
<giftnudel> pitti: yes, I know, I just wanted to tell you why I thought a reopen would be justified
<pitti> giftnudel: if it still happens, please open a new bug for now and attach /proc/net/wireless and lshal before and after suspending
<giftnudel> pitti: ok, I will do that, thanks a lot
<pitti> would be nice to settle that for edgy
<StevenK> jdong: motu-uvf for universe
<StevenK> (Just so you know)
<jdong> StevenK: yep
<jdong> I'm more familiar with universe UVFe's than main ones
<mantiena-baltix> Kamion: what you think about adding mounting hard disk partition for LiveCD functionality into gnome-volume-manager  ? Why to write another daemon when there is daemon for partition mounting already ?
<pitti> mantiena-baltix: (For the record, I'm the person who breaks g-v-m usually)
<pitti> mantiena-baltix: I don't really see how that should work TBH
<Kamion> mantiena-baltix: I'm not qualified to say
<pitti> mantiena-baltix: g-v-m runs in the user's session, it would need some backend to do this
<pitti> mantiena-baltix: for example, adding the partitions to /etc/fstab
<pitti> mantiena-baltix: g-v-m and Utopia are very bad at/not designed for handling static hard drive partitions
<mantiena-baltix> pitti: hehe, it seems you are the person, who breaks most of things, I'm talking about ;)
<pitti> mantiena-baltix: sorry :/
<jdong> pitti: btw, have you come to any sort of decision on the mWhr conversion patch in hal?
<pitti> mantiena-baltix: My gut feeling is that a simple gksudo mount wrapper on the nautilus level, combined with a small hal fix to display unmounted hard disk partitions is the way to go
<mantiena-baltix> pitti: btw, I don't see difference in handling static or removable partitions when runing from LiveCD
<pitti> jdong: oh, sorry, didn't yet find time for this bug; I'll do another session today, promised
<pitti> mantiena-baltix: it's not live CD specific at all, unless you aim for a casper solution
<pitti> mantiena-baltix: everything !casper, i. e. nautilus, pmount, g-v-m have to work identically in the live and the instlaled system
<pitti> mantiena-baltix: so either you modify casper to add them to fstab (user-mountable), or we modify gnome to allow the user mounting hard drive partitions through gksudo
<pitti> mantiena-baltix: the latter will become much easier in edgy+1 when we get gnome-mount, btw.
<pitti> which alternative we take depends on whether or not we want the same functionality in the installed system
<mantiena-baltix> pitti: yea, I understand you, thanks for info about gnome-mount. btw, where I can get gnome-mount ?
<giftnudel> pitti: it looks good with some quick tests but I will open a bug when I encounter it again
<pitti> mantiena-baltix: it's in Debian now, or you just build the upstream version
<pitti> mantiena-baltix: but it requires hal 0.5.8.1
<jdong> waaah, BenC... unusual-dev... :(
<pitti> giftnudel: it is possible that the dup was because the user didn't reboot
<mantiena-baltix> pitti: why it requires such new hal ?
<sivang> re giftnudel 
<giftnudel> pitti: : yes probably
<pitti> mantiena-baltix: well, basic gnome-mount works with edgy's hal, too
<sivang> giftnudel: thanks for the research, seems interesting
<pitti> mantiena-baltix: just not the more elaborate features
<pitti> mantiena-baltix: I successfully used gnome-mount 0.4 here on edgy
<giftnudel> sivang: funnily, your deviceinfo works nicely with my quickly burnt multi-session-cd
<sivang> giftnudel: are you sure?
<giftnudel> sivang: it reports the size and the capacity correctly
<giftnudel> yes
<sivang> hmm
* sivang scratches head.
<giftnudel> it doesn't work with a single-session dvd
<giftnudel> well it works
<giftnudel> but the capacity is of course just the size (since you can't add more)
<giftnudel> actually, all looks nice ;)
<sivang> giftnudel: hmm, can you paste the output somewhere ? or do you see it in the hubackup gui ?
<giftnudel> I will privmsg you, it's not that much
<sivang> sure, thanks
<jdong> does anyone want to consider bug 57872 and the fix I proposed?
<Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
<jdong> a few users have reported back that it fixes the problem
<jdong> no negative feedback
<dholbach> tfheen: with bluez-utils 3.1 or 3.7?
<tepsipakki> jdong: ask seb128 directly?
<jdong> tepsipakki: yeah, perhaps I should... I wasn't sure if he (or anyone) is responsible for the package
<tepsipakki> jdong: actually, ogra has done latest uploads..
<tepsipakki> of g-p-m
<jdong> I really don't mind who... just someone please weigh in on it....
<ogra> jdong, urgh, why is this patch 4.5M compressed ?
<jdong> ogra: it's not just the patch... I just zipped up pbuilder/result after the build finished
<jdong> which includes the source and binaries
<ogra> ah
<jdong> binaries because people tend to be more motivated to test binaries :)
* ogra stops the download
<jdong> the actual patch is to delete the first hunk from patch 56
<tepsipakki> jdong: just attach the patch
<ogra> but that will mean it always saves the session
<jdong> ogra: no it doesn't
<jdong> the first hunk is calling the logout dialog
<jdong> the second hunk saves the session
<jdong> an interactive save session request = logout dialog
<jdong> I've confirmed that it does not save the session
<tfheen> dholbach: yes, both please.
<ogra> jdong, oh, right, i'll revert that in the patch then ... what bothers me is that it worked in 2.14, the pacth is a direct port
<jdong> ogra: hmm, really? that's really odd then
<ogra> yes
<jdong> ogra: because post-patching, the else if branch for interactive logout is blank
<jdong> except for a log function call
<ogra> but if it doesnt force the saving of the session, its fine to revert that part
<jdong> I'm positive it doesn't force the saving of the session
<ogra> ok, i'll redirect angry users to you then ;)
* ogra fixes the patch
<jdong> oh boy :)
<dholbach> tfheen: looks good!
<tfheen> dholbach: so it then enters discoverable mode for you by default?
<dholbach> tfheen: it looks like
<tfheen> dholbach: yay.  Then we "just" need to fix the passkey problem.
<dholbach> tfheen: let's see what people answer to the bug report
<dholbach> tfheen: i'll look at nautilus-sendto now
<dholbach> tfheen: we should sync bluez-gnome anyway
<dholbach> ;)
<tfheen> dholbach: ok, thanks.  Yes, we should grab bluez-gnome.  mjg59 seemed to wish for bluez-{libs,utils} 3.7; I can't really comment on that.
<mantiena-baltix> tfheen: have you read pitti talks about mounting hard disk partitions ?
<tfheen> mantiena-baltix: no.
<dholbach> tfheen: i flicked through the changelogs and it seems that they fixed a lot of issues
<mantiena-baltix> tfheen: you told, that we need a daemon like gnome-volume-manager
<tfheen> dholbach: can you draft an UVF exception request then?
<mantiena-baltix> my idea was, that we don't need another daemon, maybe we should just improve gnome-volume-manager  
<seb128> jdong: you are pinging for 3 days about that patch now, no?
<seb128> jdong: didn't Kamion said he would have a look yesterday?
<dholbach> tfheen: Ok, I'll send it to you and mjg59 to take a 2nd look
<mantiena-baltix> tfheen: and pitti told, that we could use gnome-mount ;)
<jdong> seb128: on and off for a few days... I didn't catch it if Kamion said so
<tfheen> dholbach: thanks.
<jdong> sorry, I thought nobody responded
<mantiena-baltix> tfheen: (17:29:18) pitti: mantiena-baltix: so either you modify casper to add them to fstab (user-mountable), or we modify gnome to allow the user mounting hard drive partitions through gksudo
<mantiena-baltix> (17:29:31) pitti: mantiena-baltix: the latter will become much easier in edgy+1 when we get gnome-mount, btw.
<tfheen> mantiena-baltix: I guess I'll revisit this after edgy, then.
<seb128> jdong: I'm probably mixing that with something else
<mantiena-baltix> tfheen: ok, don't forget this !
<seb128> jdong, ogra: I've not followed the issue, but might be due to bug #62163
<Ubugtu> Malone bug 62163 in control-center "variables from the session are not defined" [Unknown,In progress]  http://launchpad.net/bugs/62163
<seb128> cf https://launchpad.net/distros/ubuntu/+source/control-center/+bug/63423 too
<Ubugtu> Malone bug 63423 in control-center "[Edgy]  keybind for "Log out" does not work" [Unknown,Unconfirmed]  
<mantiena-baltix> tfheen: I think now best solution for me would be to patch pmount to understand globs in /etc/pmount.allow and to put these lines into dapper-based Live CD:
<mantiena-baltix> /dev/hd*
<mantiena-baltix> /dev/sd* 
<pitti> mantiena-baltix: ouch
<pitti> mantiena-baltix: then you should make damn sure to not install that pmount.allow into the final system
<tfheen> mantiena-baltix: I don't care what you're doing in baltix, but we will not do any such changes in Ubuntu at this point.
<ogra> seb128, hmm, should i hold back the g-p-m change and wait for your fix then ?
<ogra> to check that its really caused by SESSION_MANAGER ?
<mantiena-baltix> pitti: of course I'm not planing to put these lines into installed system
<seb128> ogra: it's not sure we will fix gnome-session for edgy
<ogra> ok, then i'll go on
<seb128> ogra: upload your workaround, we will revert it if required
<ogra> just testbuilding here ... 
<mantiena-baltix> tfheen: I understand, I just wanna find best solution for dapper-based LiveCD
<ogra> (pbuilder is outdated and i get shitty bandwith :( )
<Kamion> seb128: I think you're confusing that with something else, or at least I hope I didn't go temporarily insane and say I'd do it
<seb128> Kamion: yeah, I had a look at my IRC log, you were probably replying to somebody else, there was several people speaking on the chan yesterday evening ;)
<ogra> we should fobid that :P
<Kamion> yeah, I was talking to Tonio about a main inclusion request
<janimo> ogra: hi, did you get my mail re ldm and gnomecanvas?
<BenC> $ sudo apt-get -u dist-upgrade
<BenC> Segmentation fault (core dumped)
<BenC> wonder when that started
<ogra> janimo, ouch, i forgot to reply ... i dont think thats feasable this late in the release ...i'm not sure ldm uses *only* gnomecanvas and the change would also require a change to some ltsp bits (the installer etc)
<ogra> i'd rather have had that request a month ago now its a bit late to get proper testing for it
<janimo> ogra, no it really only uses gnome canvas
<janimo> and besides the rest of python-gnom eis in the lareday installed desktop
<janimo> ogra, grep fro import in the sources
<janimo> it's only gnome canvas
<janimo> :)
<ogra> janimo, i wrote it, i know whats in there
<janimo> well a month ago the package split was only discussed
<KhanFounded> gnome canvas is so cruel, takes a lot less elves for the same area
<janimo> ogra, so why do you sayd then you are not sure that is the only gnome thing? I thought you said that before
<janimo> ogra, and I mailed as soon as python-gnomecanvas hit the archives. And that timing was beyond me believe me :)
<ogra> right, its still vers ylate 
<ogra> *very late
<ogra> freeze is in two days ... if the installer breaks due to broken dependencys i wont have the time to fix everything 
<ogra> ltsp is bigger than ldm
<ogra> if i find the time tonight i'll do some testing, but i'm noit really fond of causing possible breakage *now*
<Petaris> ajmitch: Any progress with the network authentication bits?
<janimo> ogra: cannot really cause breakage I am sure, as you'll just change the package (if you chose) to only Depend: on what it uses
<ogra> janimo, and rewrite the installer 
<janimo> and if by some mircale that dep was broken anyway you still have the original deps in teh default install
<ogra> it *is* a lot moire than just changing this one dependency
<janimo> ogra: same thing is done in update-manager in dapper
<janimo> ogra, what else is there besides the dep?
<janimo> I must have missed something LTSP specific then
<ogra> the installer plugins that resolve dependencys etc
<Kamion> huh?
<Kamion> ogra: what's the problem here?
<janimo> ogra, but supposing the package only depends on gnome-canvas then there's no extra work right?
<Kamion> beyond hand-waving about installer problems
<janimo> Kamion: ldm depends on python-gnome2 now but can only use the recently split python-gconf now
<Keybuk> seb128: new rhythmbox is confusing me ... it's given me an icon for my iAudio, which contains its contents
<Keybuk> should I also add that to my library?
<ogra> Kamion, ltsp-build-client's plugin system needs changes if i change a dependency of an installed package
<ogra> Kamion, its not about d-i
<Kamion> ogra: oh, so not the core installer then
<ogra> no :)
<Kamion> due respect but that's rather broken
<Kamion> you should make it process dependencies properly
<janimo> ogra: is there a parallel thing doing more or less the same thing?
<ogra> Kamion, it does
<Kamion> ogra: then why does it need to be changed?
<ogra> i just dont want to touch the code two days beforew freeze if i9 have a working edubuntu iso since week and that change should really have been months ago
<seb128> Keybuk: what do you mean? no, your library is your local list of files, the permanent one
<seb128> Keybuk: removable medias are considered as differents libraries
<Keybuk> seb128: how can I share the removable media?
<ogra> and especially since my time is very limited these tests will take me the time to fix final stuff with g-p-m or g-s-s 
<Keybuk> my laptop sees "Music", but not anything in it
<ogra> which i'm also not fond of
<ogra> i'm not saysing "it will break" but it has breakage potential in it which i really really dont like at this point 
<ogra> so it needs decent testing which costs lots of time
<seb128> Keybuk: hum, good question
<Keybuk> this worked when it used to just consider players as detachable bits of your library :)
<seb128> Keybuk: you can try unsetting /apps/rhythmbox/plugins/generic-player/active
<Keybuk> what will that do?
<seb128> stop using the generic-player plugin
<dholbach> tfheen: NonLangagePackTranslationDeadline is the same date for artwork?
<Keybuk> that killed the music player
<seb128> ie: doesn't make your player listed as a different entry
<Keybuk> can't it just share those?
<Keybuk> it doesn't share podcasts either
<seb128> it could
<seb128> but it's not done and will no change before edgy
<tfheen> dholbach: I haven't been able to get anybody to tell me when artwork freeze is.
<tfheen> dholbach: but artworkfreeze in two days is fine with me.
<dholbach> tfheen: right, mail sent - I guess he'll get back to you
<janimo> ogra: but testing in the ldm case is either it starts or it doesn;t no? Like if by absurd one daily would break one would notice at once
<janimo> ogra: your call of course, I don;t want to cause too much pains
<janimo> it's just that there's a few unused megs of debs on the xubuntu CD because of it
<ogra> janimo, testing the ldm case starts with spending 30-40 minutes watching ltsp-build-client building, then booting a thin client and checking if ldm works 
<ogra> the install part is the time consuming piece here
<ogra> as i said i'll try to invest some time into it .. but no promises
<ogra> and please, please dont come up with such changes some days before RC  ... such things should be solved far before beta
<sladen> pitti: is apport meant to use vast amounts of CPU?  It's mmap()ing, reading half megabytes pages, and remmap()ing
<sladen> pitti: but doesn't acutally appear to be /doing/ anything visible (aside from the 90% CPU usage)
<sladen> pitti: ah, that was a 60MB firefox core dump.
<pitti> sladen: apport itself has to gzip the core dump, collect some /proc information and other bits 
<pitti> sladen: so yes, it's quite resource intense
<pitti> sladen: but I moved most of the expensive bits to aport-gtk, where they will be only done when the user actually wants to report a bug
<pitti> bbl
<dholbach> tfheen: were you able to do the pairing with the default passkey "BlueZ"?
<kristog> dholbach, afaik BlueZ cannot be handled by phone you have to use numbers 
<dholbach> hrm
<sfllaw> Kamion: What is the most recent documentation about kickstart and Ubuntu?
<sfllaw> Is it the hoary manual?
<sfllaw> And is it supposed to be better these days?
<Kamion> sfllaw: the installation-guide-${arch} package
<Kamion> it's had some maintenance, although not lots. What in particular are you wondering about?
<sfllaw> I need to know what kind of testing would be reasonable.
<sfllaw> Is installation-guide-* available on the web?  Or does one have to install Ubuntu before reading it?
<Lure> mjg59: I have usplash regression on ATI FireGL V5000 laptop after Beta: kubuntu logo looks edgy and there is green (or in one case) white cast on progress bar
<Lure> mjg59: this has happened with first upgrade of usplash after beta, but I did not pay attention as I though usplash artwork is still changing, but my desktop (ATI radeon 9100) displays it perfectly after dapper->edgy upgrade
<bddebian> Howdy
<tkamppeter> doko_, did you have a look into HPLIP 1.6.9? Is it feasable?
<doko_> tkamppeter: no, not yet
<Kamion> sfllaw: it's on doc.ubuntu.com, but an old version; I've been engaged in a conversation with mdke about getting that updated
<Kamion> though IME the best testing of Kickstart support so far has come each time a big corporate starts trying to roll out Ubuntu :)
<sfllaw> Oy.
<sfllaw> I'm probably unable to go through all the combinations, but a preliminary test would be good.
<Kamion> use dapper's system-config-kickstart to generate some test files
<Kamion> (edgy's is broken at the moment; working on that right now)
<sfllaw> Thanks.
<sfllaw> I'll fire up my Dapper VM.
<Kamion> (bug 59820)
<Ubugtu> Malone bug 59820 in system-config-kickstart "system-config-kickstart not starting" [High,Confirmed]  http://launchpad.net/bugs/59820
<Kamion> oh, yeah, it'd need to be dapper's system-config-kickstart with other bits of dapper, so a VM's a good plan
<sfllaw> ^^ will be fixed before release, right?
<dholbach> tfheen: WOOOOO! gnome-bluetooth 0.8.0 fixes the pass URI to gnome-obex-send thing :-)
<psykoyiko> does anyone want to poke at http://launchpad.net/bugs/65014 ?
<Ubugtu> Malone bug 65014 in linux-source-2.6.17 "asm/atomic.h #includes non-existant header file, asm/processor.h" [Undecided,Unconfirmed]  
<psykoyiko> Hi, Spads.
<zul> hey Spads how is it going?
<Spads> psykoyiko!
<gnomefreak> tfheen: your irssi script "contentless_ping" is there a way to get it to /msg $user output instead of output in channel? (im looking at the irssi docs on varibles but i dont see one that will work)
<hunger> Why is archive.ubuntu.com so slow recently? Is that on purpose to get people to use mirrors?
<kristog> mdz, why bluez-libs 3.7.1 and bluez-utils 0.3.5?
<kristog> we will have 2 different source so
<Kamion> sfllaw: it's targeted at ubuntu-6.10 - so yes, I hope so
<mdke_> tfheen: yay for countless_ping
<mdke_> *contentless*
<gnomefreak> i think i fixed it to /msg user
<LaserJock> mdke_: ping? ;-)
<gnomefreak> LaserJock: try mdke_ ping  without the chars
<gnomefreak> LaserJock: also try me let me know if you get a /msg about it
<gnomefreak> :)
<LaserJock> gnomefreak: ping
<gnomefreak> grrrrrr
<gnomefreak> its putting  :: with your nick and i thought i fixed that brb
<sladen> ho ho ho, every single python TLS library seems to be broken in some manner
* gnomefreak really needs to learn perl if irssi isnt gonna use python in near future :(
<gnomefreak> i fixed it :)
<psykoyiko> can someone confirm that #include <asm/atomic.h> is broken on edgy?
<psykoyiko> this seems to be a using-kernel-headers-but-we-shouldn't kind of bug
<mdz> seb128: on some recent upgrades, my panel has gone weird (menus, clock, show desktop, window list, pager all missing) until I kill it.  is this known?
<Seveas> mdz: ah so I'm not the only one who sees tha
<Seveas> t
<seb128> mdz: looks like some applet didn't like something which has been updated, some people mentioned it but none with useful data to have an idea on the issue
<mdz> seb128: my system is in the broken state right now; is there any information i can collect?
<mdz> my .xsession-errors is useless due to bug 39075
<Ubugtu> Malone bug 39075 in vte "No handler for control sequence `device-control-string' defined" [Low,Unconfirmed]  http://launchpad.net/bugs/39075
<sivang> re
<vuntz> mdz: can you interact with the panel?
<vuntz> right-click on it, move it, etc.
<vuntz> or is it blocked?
<seb128> mdz: reply to vuntz :)
<vuntz> seb128: lazy you :-)
* vuntz hugs seb128 
<seb128> vuntz: apparently interactions are not working but sysmon applet, clock etc keeps being updated
* seb128 hugs vuntz
<seb128> vuntz: bt have not a lot of useful and strace is blocked on a FUTEX or something
<seb128> not of useful, like no panel funtion
<vuntz> it probably means an applet is blocked in the loading stage and the panel blocks on it
<seb128> yeah, my bet was an applet
<seb128> "loading"?
<vuntz> easy way to debug this is to kill each applet process until this unblocks the panel :-)
<seb128> panel was running fine, it's not on startup
<vuntz> oh
<seb128> that happens while running
<vuntz> that's quite interesting
<seb128> desktop is fine, dist-upgrade and it hangs
<seb128> something change under it
<seb128> I would have blamed a dbus restart or something
<vuntz> is it using the cpu or just waiting?
<seb128> but we don't restart dbus on update and it has not been updated
<seb128> waiting
<vuntz> could be because of file monitoring, but I can't imagine how this would happen
<vuntz> seb128: do you have a bug number for this?
<seb128> no
<seb128> we can get mdz to open one with required infos though ;)
<vuntz> interesting info to get: list of applets/panel objects (ie, applets + launchers + menus)
<vuntz> what changed (if dist-upgrade, which packages were upgraded, etc.)
<vuntz> stack trace
<jdong> Kamion: when you get a chance, can you go through Backports's binary NEW queue?
<dholbach> or bonobo-activation-server :)
<mdz> vuntz: I can interact with the applets which are still running
<mdz> vuntz: but not with the panel itself (no response to right-click)
<mdz> vuntz,seb128: should I kill applets to see if it continues?
<seb128> yeah, maybe getting a bt for every one before killing it?
<seb128> each one
<sladen> mdz: last time I had that, it was the keyboard switcher applet dying on load
<desrt> seb128; i did my proof of concept.  it seems to work.
<mdz> all of the applets I see running are still alive and I can interact with them
<seb128> desrt: oh, nice!
<desrt> seb128; i haven't actually seen that it produces better traces
<desrt> seb128; only that it works :)
<seb128> vuntz: any idea?
<mdz> there were two sets of e-d-s / e-a-n running for some reason
<mdz> I killed them all and it didn't help
<xav> doko_, doko__ ping
<desrt> seb128; got any 100% reproduceable crash in a gnome app for which bugbuddy always gets bad traces?
<vuntz> mdz: can you put a stack trace of what's the panel doing somewhere?
<desrt> seb128; k.  i have class so i should go
<desrt> seb128; ping me later if you know of such a bug
<seb128> desrt: oh, sorry, looking at several things at the same time
<seb128> desrt: I've a non-easy example, deskbar-applet crashing with pygtk 2.10.2
<seb128> which requires downgrading pygtk
<seb128> I kept packages on my box for that :)
<seb128> desrt: feel free to send me a patch and I'll try it, otherwise I'll try to think to a simpler example
<imbrandon> mdz, ping , w.r.t bug 64488 , upstream commented saying they never left string freeze upstream ( e.g. no new strings )
<Ubugtu> Malone bug 64488 in konversation "UVFe ( main ) for konversation 1.0 to 1.0.1" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64488
<mdz> vuntz: I did, but it's not very good
<mdz> vuntz: pasted in /query
<vuntz> would be interesting to know if people seeing this are all using ubuntulooks
<rodrigue> Salut  tous j'ai un gros soucis de mise  jour !
<rodrigue> En gros tout fonctionnais bien jusqu'a la mise  jour d'aujourd'hui que j'ai hsiter  faire .....
<rodrigue> Depuis qu'elle est faite, plus d'acclration graphique !!! Comment revenir en arrire ?
<imbrandon> !fr
<vuntz> rodrigue: je pense que ce serait mieux de demander dans #ubuntu-fr
<vuntz> rodrigue: c'est un canal anglais
<rodrigue> Oups. . . dj demander dans Ubuntu-fr 
<_ion> No sithn minkin.
<vuntz> rodrigue: et c'est un canal de dveloppement, pas de support
<_ion> (I.e. thanks for only using English)
<rodrigue> Pardon . . . 
<rodrigue> I'm sorry
<jdong> whoa, did #ubuntu-fr and #kubuntu-devel switch on me while I was gone?
<jdong> I remember this stunt from grade school
* jdong fell asleep in class a few times more than he should
<rodrigue> :)
<jdong> BenC: how's my faaavorite kernel developer doing today? :)
<mdz> imbrandon: it's pretty clear from the changelog that it isn't a bugfix-only release; where did you get the idea that it was?
<mdz> imbrandon: none of the bugfixes seem critical for edgy, and it sounds like there's a substantial amount of new code which is untested in ubuntu
<xav> jdong, I'm not sure if it's the best place to ask, but do you know what's up with https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/54776 ?
<Ubugtu> Malone bug 54776 in openoffice.org "[Edgy]  font hinting does not work with libfreetype6 v. 2.2.1" [Undecided,Needs info]  
<AlinuxOS> mjg59, ping.
<jdong> xav: why do you ask me? I am the clueless fool when it comes to Openoffice/freetype :)
<xav> jdong, but you contributed to this bug report, right?
<jdong> xav: yeah, just  to say that the fonts looked BETTER after the recent uploads
<jdong> it still looks different than native
<xav> oh, so that's what I didn't understand
<jdong> but much less blurry
<xav> what changed
<xav> and why does it look better
<xav> I personally didn't see a difference, but I'm not sure
<jdong> well, it's not nearly as blurry as it was before on my screen
<jdong> I have an LCD, idn if that makes any difference
<jdong> but the old fonts were very blurry (my eyes watered after using it for a few minutes)
<jdong> the new ones are bearable again
<xav> do you have a screenshot before and after?
<xav> I still find them very blurry
<Spads> "Playing with the use-mention dichotomy" isn't "everything in life, you know."
<Spads> er, wrong channel
<jdong> xav: when I feel less lazy I might do a screenshot comparison
<xav> jdong, I don't see a difference between http://librarian.launchpad.net/4168326/openoffice-font.png and http://librarian.launchpad.net/4566596/Bildschirmfoto.png
<jdong> xav: you don't see the difference?
<jdong> xav: it's slightly less blurry 
<jdong> Look at the two capital E's for a rough comparison
<xav> you made me doubt, so I zoomed on both E
<xav> they are totally identical
<mantiena-baltix> pitti: still online ?
<_ion> Eww, blurry fonts.
<pitti> mantiena-baltix: yup
<mantiena-baltix> pitti: why did you want to make me busy for the whole night ?
<mdz> kristog: you proposed an agenda item for the technical board meeting, but you aren't in #ubuntu-meeting
<ogra> Keybuk, could you have a loo9k at the last two comments on bug #65003 i thought that part of coreutils was fixed ...
<kristog> 22.01 :) sorry
<Ubugtu> Malone bug 65003 in ltsp "ltsp-build-client needs to handle proxy settings for apt in the chroot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65003
<Keybuk> ogra: ?
<Keybuk> doesn't look like any problem I'm familar with
<xav> so antialiasing is still very blurry, and without antialiasing, it's still very ugly
<ogra> Keybuk, well, didnt you patch rm back in london ?
<ogra> oh, no that was cp 
<ogra> sorry
<xav> there are 2 fedora patches for ooo in the bug report. they weren't applied ?
<pitti> mantiena-baltix: pardon?
<mantiena-baltix> pitti: some time ago (16:03:42) you toldi: mantiena-baltix: use glob() for shell patterns (globs)
<xav> that's what I wanted to ask to doko_ 
<mantiena-baltix> pitti: but after reading glob() function documentation (after ~20 minutes) I understood that this is not our way ;)
<pitti> mantiena-baltix: well, if you prefer regexps, that's fine, too, but a bit unusual for specifying files
<ogra> mjg59, which g-p-m issue did you mean yesterday ?
<mantiena-baltix> pitti: no, I don't prefer regexps, it's not user-friendy way to write regexps into /etc/pmount.allow
* pitti agrees
<pitti> mantiena-baltix: so, what's so evil about glob(3)? it's pretty straightforward
<mjg59> ogra: The power button action one
<pitti> call glob() on the pattern and check if the target device file is in the result set
<mjg59> ogra: So yes, I've just seen the bug closed
<ogra> mjg59, ah, great so i fixed the right one today ;)
<mantiena-baltix> pitti: but glob () function is not our way (TM) it's too hard to use 
<pitti> mantiena-baltix: fnmatch(3) is even easier
<jdong> ogra: thanks for your time on that bug :)
<mantiena-baltix> pitti: yea, fortunately in glob () manual I fount this line:
<jdong> I've been eagerly waiting for it for a week now :)
<mantiena-baltix>  If a utility needs to see if a pathname matches a given pattern, it can use fnmatch().
<ogra> jdong, thanks for the patch
* ogra hugs jdong 
* jdong hugs ogra
<mantiena-baltix> pitti: so. maybe you wanna patch, which removes one line from TODO file and changes 2 lines in src/policy.c ?:)
<pitti> mantiena-baltix: heh, sure :)
<pitti> mantiena-baltix: I can't apply it to edgy, but I can apply it upstream, and in Debian soon
<mantiena-baltix> -           if( !strcmp( d, device ) ) {
<mantiena-baltix> +           if( !strcmp( d, device ) || !fnmatch(d, device, 0) ) {
<mantiena-baltix> ;)
<pitti> mantiena-baltix: the strcmp should be superfluous then
<pitti> fnmatch(a, a, 0) should be true
<mantiena-baltix> pitti: maybe, that's why I'm pasting patch here - I'm not very experienced in glob and fmatch
<mantiena-baltix> pitti: So, you think we should simply use
<mantiena-baltix> +           if( !fnmatch(d, device, 0) ) {
<mantiena-baltix> ?
<pitti> mantiena-baltix: I think so; I have to test it thoroughly, but it looks fine
<mantiena-baltix> pitti: One of things, which I don't understand, is last fmatch argument - flag
<mantiena-baltix> pitti: I don't know which flag to use, so I put zero there :)
<pitti> mantiena-baltix: you should use FNM_PATHNAME 
<pitti> mantiena-baltix: man fnmatch explains the options
<mantiena-baltix> pitti: so, line should look like this:
<mantiena-baltix> if( !fnmatch(d, device, FNM_PATHNAME) ) {
<mantiena-baltix> ?
<pitti> looks fine
<pitti> mantiena-baltix: please test it a bit with various cases
<mantiena-baltix> pitti: yes, I'm testing now and I changed also another line in policy.c to allow * character in /etc/pmount.allow
<mantiena-baltix> -    const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$";
<mantiena-baltix> +    const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-*] +)[[:space:] ] *(#.*)?$";
<pitti> mantiena-baltix: heh, right
<pitti> mantiena-baltix: and, while you are at it, [ and ]  for full shell glob support
<mantiena-baltix> pitti: but I'm not sure if I did this in correct way
<mantiena-baltix> pitti: could you show me how to add [ and ]  ?
<pitti> mantiena-baltix: just adding \[\]  to the []  set should do it
<pitti> right after the *
<mantiena-baltix> pitti: btw, why there is slash before minus in [[:alnum:] /_+.\-*]  ??? why not like this: [[:alnum:] /_+.-*]  ???
<Keybuk> mantiena-baltix: because that matches all characters from "." to "*" :)
<mantiena-baltix> Keybuk: ok, I understood, thanks
<tfheen> gnomefreak: yes, it's trivial.  Just remove the $channel from the msg command
<tfheen> dholbach: yay, great.
<pitti> mantiena-baltix: the minus should be the last character in that set to keep it readable, and to avoid ambiguity with ranges
<dholbach> tfheen: and nautilus-sendto is a gnome-bluetooth bug, fixed in 0.8.0 (which needs uvf + libbtctl uvf)
<tfheen> dholbach: uh-huh.  Have you filed UVF exception requests and/or talked with mdz/Kamion about it?
<dholbach> tfheen: not yet - I just finished packaging and testing it
<dholbach> tfheen: what about bluez-gnome?
<tfheen> dholbach: since while I'd love us to have decent bluetooth functionality, we're quite close to freeze and I'm too happy about doing those kinds of surgery at this point.
<tfheen> dholbach: it's needed for the passkey agent, iirc?
<dholbach> tfheen: it's the only thing that worked for me
<dholbach> tfheen: i'll write a mail about libbtctl and gnome-bluetooth now
<mantiena-baltix> pitti: like this ?:
<mantiena-baltix> const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+*.\] \[\-] +)[[:space:] ] *(#.*)?$";
<pitti> mantiena-baltix: you don't have to escape the minus if it's the last character; it *should* work, though (testing appreciated)
<tfheen> dholbach: goodie.
<mantiena-baltix> pitti: but you escaped minus in your code, even when minus was last
<pitti> mantiena-baltix: hm, wait
<pitti> mantiena-baltix: please read regex(7)
<mantiena-baltix> pitti: ok
<pitti> mantiena-baltix: \ is not an escape character in []  sets
<pitti> mantiena-baltix: it needs to be sth. like [] [:alnum:] /_+*.[+\-] 
<pitti> mantiena-baltix: 'To include a literal ]  in the list, make it the first character'
<mantiena-baltix> pitti: your code in pmount 0.9.13 is:
<mantiena-baltix>  whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$";
<pitti> mantiena-baltix: yes, \ is a valid character for file names
<pitti> mantiena-baltix: ah, bzr diff told me now: before I used the - unescaped, but that didn't work in some locales
<pitti> mantiena-baltix: with \- it worked
<sladen> \sh_away: your last wine upload ( 0.9.22-0ubuntu1 ) takes the diff from 5k lines to 35k lines---alot of the churn in the diff looks a bit suspect
<sladen> \sh_away: can you give it a once over when you're next around;
<mantiena-baltix> pitti: if I write slash in /etc/pmount.allow then regexp doesn't match, it seems  whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$"; doesn't allow \ 
<pitti> mantiena-baltix: ok; it seems the regexp manpage isn't that precise then
<dholbach> tfheen: done
<dholbach> tfheen: and added ubuntu 6.10 milestone to that bug
<mantiena-baltix> pitti: so, what I pattern I should use for regexp ? it's enough to use this ?:
<mantiena-baltix> const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+*.\] \[\-] +)[[:space:] ] *(#.*)?$";
<pitti> mantiena-baltix: if that works, it lokos good to me; but please put the \- to the end
<lemsx1> mantiena-baltix: [[:alnum:] /_+*.\] \[\-] + <--- this is almost the same as [^[:blank:] ] + ... perhaps is a better class?
<mantiena-baltix> lemsx1: talk with pitti - I'm not regexp guru ;)
<pitti> it's not almost the same
<pitti> also, I'd prefer a whitelist over a blacklist
<mdke> mantiena-baltix: you had a question earlier?
<mantiena-baltix> mdke: what question ?
<mdke> mantiena-baltix: I don't know, it was your question. I got a highlight
<mantiena-baltix> :)
<mdke> mantiena-baltix: translations for documentation maybe?
<tormod> pitti, hi, do you have a prism2 device yourself to test with?
<pitti> tormod: hi
<pitti> tormod: well, a half-broken Netgear stick, yes
<AlinuxOS> pitti, ;)
<pitti> tormod: I bought an Airport Extreme when it broke, and I almost threw it away
<pitti> tormod: but it still sorta works for testing basic stuff
<tormod> pitti, because the firmware upload is still broken. The /proc/net/p80211 is missing. Should that be /proc/net/ieee80211 now?
<pitti> tormod: hm, no idea; I don't upload firmware to my stick
<nawty> Hi guys, i've got a strange question, anyone around that'd be able to help me, i'm not sure how to log this specific bug. 
<nawty> Basically, my boot hangs ( although, not really a hang, just kinda sits there, without hanging, but does nothing ) 
<tormod> pitti, because you don't want to, or because it doesn't work :)
<nawty> at 'waiting for root filesystem...' 
<nawty> Using linux-kernel-2.6.17-10-generic, and -i386
<nawty> was a clean install of dapper yesterday, edgy-ed today. 
<nawty> the dapper kernel, -2.6.15-somthing works perfectly. 
<tormod> nawty, try remove "quiet" and "splash" and ask again in #ubuntu
<pitti> tormod: I don't need to, and the only time when I tried, the stick went broken, and I had to plug it into a winxp box to make it work again
<nawty> tormod: i've removed quiet, and splash, and that's where i've seen it hangs. 
<nawty> tormod: it's a bug, not a support request. 
<nawty> tormod: I've tested booting with the options : 'irqpoll, and nommap ( i think it was no mmap )' 
<nawty> tormod: which were both on forum posts about that specific problem 
<nawty> the thing is, it's not a kernel / hardware bug, i'm sure of it, because it doesn't hard hang, it just seems to sit there, when it's supposed to go from kernel->rootFS 
<nawty> thus, the 'waiting for root filesystem... ...'
<tormod> nawty, file a bug with all the information you can give.
<AlinuxOS> pitti, hello again, is there deadline for mozilla 2.0 translations pack ?
<nawty> tormod: but under what package. 
<nawty> tormod: it could be anything from the initrd, to the upstart stuff, to the kernel. 
<pitti> AlinuxOS: well, it's becoming really tough now; given that it had to get through NEW and everything
<nawty> tormod: and against the kernel -i386, or -generic
<pitti> AlinuxOS: I'm afraid it's veery late
<nawty> tormod: or against, source? 
<AlinuxOS> pitti, and after realise ? :)
<nawty> tormod: i've also regenerated the initrd a few times ( for the record ) 
<pitti> AlinuxOS: we can't introduce new packages after release
<AlinuxOS> mozilla is still beta.
<pitti> AlinuxOS: we have 2.0rc2 now
<AlinuxOS> yes
<nawty> tormod: do you still figure i should ask in #ubuntu ? 
<AlinuxOS> so when there is final...we need final transaltion packs or not ? 
<mantiena-baltix> mdke: yea, I asked dholbach about ubuntu-docs package  - why in dapper all translations were included into ubuntu-docs package, but infinity told me, that in edgy ubuntu-docs  translations will be included into langpacks ;)
<tormod> nawty, file under linux-source-2.6.17 please. no wait, that sounds familiar, this is a "udev" bug. look in launchpad, file a new if needed.
<AlinuxOS> pitti, so it's impossible to have it like update after Edgy realise ...right?
<nawty> tormod: i've also reinstalled udev, and upstart. 
<pitti> AlinuxOS: right
<nawty> tormod: should i check under udev @ launchpad ? 
<tormod> nawty, yes udev @ launchpad
<nawty> *seaches the great launchpad massives*
<AlinuxOS> pitti, why so ?  I know that there is freeze period, but I think that having locale remotely linked with your locale is pretty good.
<AlinuxOS> that means that georgian remains without transalted firefox 2.0 :(
<mantiena-baltix> pitti: should'nt I use FNM_NOESCAPE flag in fnmatch ?
<nawty> tormod: this the correct one ? : https://launchpad.net/distros/ubuntu/edgy/+source/udev/+bugs
<tormod> nawty, yes, and then ask in #ubuntu+1 since you are using edgy.
<nawty> tormod: no bugs, under dapper, or edgy. 
<nawty> let me go ask in #+1 anyway. 
<nawty> tormod: thanks for your help so far. 
<doko_> xav: pong
<xav> doko_, I had questions about openoffice, concerning freetype problem
<xav> https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/54776
<Ubugtu> Malone bug 54776 in openoffice.org "[Edgy]  font hinting does not work with libfreetype6 v. 2.2.1" [Undecided,Needs info]  
<xav> someone pasted the links to two fedora patch there
<doko_> the patches are both applied
<xav> oh I see, that's what I wanted to know, I wasn't sure
<xav> unfortunately, it doesn't seem to fix the issue then
<doko_> :-/
<xav> that's odd, I thought it would do it
<xav> and openoffice isn't the ideal app to play with, with its building time
<Seveas> xav, you don't have a 4gazillion mhz machine with infinite IO bandwidth and neglegible IO latency?
<xav> no, but I hope openoffice devs have
<xav> doko_, ohhh
<xav> doko_, it works :))
<AlinuxOS> Seveas, 4gazillion :D
<doko_> xav: what did you change?
<xav> doko_, I remember fontconfig was a bit weird sometimes about its settings
<xav> so I wrote a .fonts.conf with antialiasing/hinting settings
<xav> like kde does
<xav> gnome only exports Xft resources, it doesn't write any config files
<sivang> doko_: if you have time, there are those two bugs for moin that I'd like to take care of if you think it's right - https://launchpad.net/distros/ubuntu/+source/moin/+bugs and deserves UVFs , as well as a pending merge as it seems. The merge is about adopting to new python policy, is it worthwhile UVF and upload as well?
<doko_> xav: you may want to attach that settings as documentation to the report
<xav> it looks much better now, the hinting / hintstyle options are now used
<xav> doko_, yep
<xav> but it seems it still can't use subpixel rendering
<xav> nor native hinting
<sladen> seb128: what's the deal with bug #59159 ?  Do you have a rough idea of the extent of the problem?
<Ubugtu> Malone bug 59159 in gst "network-admin doesn't scan for networks [regression] " [Unknown,Unconfirmed]  http://launchpad.net/bugs/59159
<seb128> sladen: the feature has not been implemented/ported to the new code
<seb128> gnome-system-tools src/network/connection.c
<seb128> wireless_essid_populate_model() to rewrite
<seb128> and probably needs to write the liboobs method for it
#ubuntu-devel 2006-10-11
<PWill> Quick question: Will IceWeasel/GNUZilla be included in Edgy's final release?
<PWill> Or is it too late after the freeze...
<ogra> IceWeasel is firefox with another name ... there is no further difference
<sladen> PWill: I suspect that whether it's called IceWeasel, or Firefox will probably depend on whether Mozilla's sanity recovers 
<PWill> OK, thanks.
<doko> sivang: I won't have time to test moin ... 
<kristog> night
<sladen> seb128: is the main change to drop the XML style of inteorgation and to write a brand new direct 'C' method instead?
<seb128> sladen: the main change is to talk over dbus rather than over some custom xml protocal
<seb128> protocol
<wasabi> So, curiously, I don't want to start a flame war, but what's the Ubuntu firefox situation? Are we approving patches through mozilla and using the logos/name?
<wasabi> Or are we calling it Iceweasel?
<wasabi> I haven't heard a thing about it. Maybe I'm not paying attention.
<funman> btw, did debian call it Iceweasel?
<wasabi> Looks like unless god steps in, they will.
<sladen> wasabi: as you've seen on the mailing lists.  We don't know, yet.  And mdz is the person handling the situation behind the scenes
<wasabi> Ahh.
<lifeless> I worry that ff will set a trend
<mdz> for the record, mozilla has been slow to respond so things aren't moving ahead quite as much as I'd like
<wasabi> Yeah. Agreed.
<mdz> the last turnaround took 10 days
<lifeless> and we'll have to rebrand gnome, kde, gcc, even 'linux'.
<wasabi> I don't really give a hoot about the difference between copyright/trademark.
<wasabi> I just want the rights.
<sivang> oh dear
<lifeless> which frankly, would suck.
<lifeless> that, or essentially give the upstream direct control over the quality and content of what we create. 
<wasabi> Semantic arguments piss me off sometimes heh.
<lifeless> would would also suck.
<funman> i'm runnig faheurfoqs on my lee-nouks operating system
<lifeless> funman: precisely.
<HrdwrBoB> lifeless: that is not going to happen, it's licensed differently
<sladen> wasabi: there are *major* differences between copyright and trademarks, please don't get them confused, or mixed up.
<HrdwrBoB> but you are right, it's stupid
<wasabi> sladen: I recognize the difference, but there is one end result.
<wasabi> And that is whether I can take the work produced by Ubuntu and do what I want with it or not.
<funman> copyright means you intellectually own something, material or not
<funman> trademark means you commercially own a brand
<wasabi> Copyright, trademark, patents.
<wasabi> They are all seperate.
<wasabi> But they all work towards the goal of preventing me from excercising freedoms. :)
<wasabi> At the end of the day anyways.
<sladen> wasabi: no.  With the GPL and the copyright situation, we get to keep the software (even without the name).  
<wasabi> Sure. But we don't get to keep the logo.
<wasabi> Or the name. :)
<sladen> wasabi: which would you prefer;  5million lines of code, or a motif that an artist can replace in a day
<wasabi> Depends how deep it goes.
<wasabi> Can the packages be named "Firefox"?
<lifeless> HrdwrBoB: AFAIK its possible to do this trick on anything that is trademarks, the right to copy license is irrelevant
<wasabi> Hell, isn't the whole reason we use FF and not Epiphany is to ride on the name recognition? :)
<mjg59> There's several technical mechanisms for us to ensure that apt-get firefox works
<mjg59> ^install
<lifeless> wasabi: no
<wasabi> mjg59: I wonder that. I suspect If we encourage users to type "apt-get firefox" we'd be required to be allowed to use the firefox trademark. :)
<wasabi> Ya know, since we are using their name, and users are making the association between firefox and... firefox.
<mdz> wasabi: yes, basically
<HrdwrBoB> basically, it's the stupidest thing ever
<wasabi> Uh huh.
<wasabi> Just like the patent situation.
<mjg59> I think there's an argument that something like Provides: firefox is a technical description rather than anything in the scope of trademark law, but legal advice etc
<wasabi> I've always found that lawyers, and especially judges, from the cases I've read, don't give a damn about "technical details" heh.
<wasabi> Users either think they're installing firefox or not.
<maswan> wasabi: yeah, but on the other hand apt-get going "you said you wanted firefox, I'm going to give you earthturtle" might be ok. (or not, depending)
<gnomefreak> iwj: i have a question about a bug of yours if you get time
<exarkun> Is svn 1.4 likely to be included in edgy?
<LaserJock> I'm thinking no as we are past the upstream version freeze
* exarkun pouts
<exarkun> Thanks for the info
<Toadstool> 6
<Toadstool> uhuh
<fabbione> morning guys
<Hobbsee> hey fabbione!
<fabbione> hi Hobbsee 
<fabbione> ajmitch: ping?
<ajmitch> fabbione: pong
<ajmitch> sorry, got caught up with other stuff as I left them to test-build
<fabbione> ajmitch: did you upload the font pakcages?
<ajmitch> not yet
<fabbione> we need to transit them and finish
<ajmitch> yep, will do it tonight
<ajmitch> just have to sign & dput most of them
<fabbione> ok
<fabbione> who does know  a little bit of c++?
<fabbione> by little i really mean almost nothing..
<Amaranth> depends on what you need
<fabbione> Amaranth: hello world in cpp?
<Amaranth> hehe
<fabbione> i just need to test one stupid thing
<psusi> I know C++
<Amaranth> http://en.wikipedia.org/wiki/C++#Hello_world_program
* psusi waves at fabione
<fabbione> thanks
<fabbione> hi
<psusi> you ever get that dmraid setup you were going to buy? ;)
<fabbione> psusi: i have one controller, but the disks died and no.. i didn't spend any more money on replacing them
<fabbione> psusi: the machine had enough disk space anyway
<psusi> doh.... bad diskcs....
<fabbione> the dmraid was a toy
<psusi> mine is still running solid and fast... which is more than I can say for X
<psusi> what did you need about C++?
<Hobbsee> fabbione: what was your c++ problem?
<fabbione> psusi: well the disks in there were 5 years old 120GB that have been running 24/7 since.. i was expecting them to fail sooner or later
<fabbione> psusi, Hobbsee: i just add to test a fix in gcc-3.3 64bit on sparc 
<psusi> were you running smartd?  if so did it anticipate the failure?
<fabbione> psusi: no, they just failed.. i don't bother with my storage.. everything important is on real raids and backed up.. 
<fabbione> all my machines could die all of a sudden and i wouldn't lose more than a week of emails
* Hobbsee wonders what that has to do with c++ :P
* Hobbsee makes a mental note to do another backup
<Hobbsee> time for work.  really, this time
<pitti> Good morning
<netdur> is there vmware image ready for ubuntu/gnome development?
<Sp4rKY> hi
<Sp4rKY> i'm trying to use unsquahfs but i get this error : "zlib::uncompress failed, unknown error -3"
<mdke> infinity: 
<mdke> 22:29 #ubuntu-devel: < mantiena-baltix> mdke: yea, I asked dholbach about ubuntu-docs package  - why in dapper all translations were included into ubuntu-docs package,  but infinity told me, that in edgy ubuntu-docs  translations will be included into langpacks ;)
<mdke> infinity: sadly not
<infinity> mdke: I didn't actually say THAT, I said that "some translations appear to be stripped in the build process, which would end up in the langpacks, but I'm not sure just what those are"
<mdke> infinity: ;) 
<mdke> what gets stripped?
<infinity> ./ubuntu/desktopguide/desktopguide.pot
<infinity> ./ubuntu/menus/menu-entries.pot
<infinity> ./ubuntu/getting-help/getting-help.pot
<infinity> ./ubuntu/aboutubuntu/aboutubuntu.pot
<infinity> ./generic/packagingguide/packagingguide.pot
<infinity> ./generic/serverguide/serverguide.pot
<infinity> So, I imagine those would get fed into rosetta, but there's no way they'd be useful in langpacks anyway, since we wouldn't know what to do with the resulting translations.
<mdke> ah, yes. Those get fed into Rosetta, but the resulting translations have to be got manually and put into the package
<infinity> Yeah, I figured.
<mdke> "got manually, beaten with a stick, and put into the package", rather
<infinity> Why does it always have to be a stick?
<mdke> sticks do the job
<mjg59> infinity: We don't want to know what you'd prefer instead
<mdke> haha
<infinity> Something less phallic?
<mdke> infinity: btw, have you still got your T43?
<infinity> mdke: Burning a  hole in my lap as we speak.
<mdke> infinity: good. does it resume from suspend every time in Edgy?
<infinity> Yup.
<mjg59> His is an ATI, so probably
<infinity> I suspend it constantly.
<infinity> And yes, it's an ATI.
<mjg59> The issue is Intel specific
<infinity> My only problem is with NM being retarded.
<mjg59> More irritatingly, it's 915 and above specific
<mdke> oh, I thought yours was an Intel too
<mdke> sorry
<infinity> (On one out of ten resumes, NetworkManager decides that the ipw2200 is a wired interface, and refuses to do fancy wireless things with it)
<Treenaks> ooh, a wired ipw2200
<mdke> mjg59: so you're aware of the problem then. Is it resolvable?
<robitaille> ah...that explains why my laptop doesn't always come back from suspend properly...I'm not alone :)
<mjg59> mdke: Well, it's software, so...
<mdke> mjg59: right. I mean, is it resolvable in the time frame before Edgy gets released?
<Burgundavia> robitaille: I was wondering why mine came back 50% of the time. It is quite annoying
<mjg59> mdke: I sincerely hope so
<mjg59> If I had the faintest idea what the problem was, I could give you a better answer
<mdke> as far as I can see, Xorg is crashing
<mjg59> Yes
<mdke> ah, you need more than that, grr
<mjg59> It's something to do with the reprogramming of the graphics chipset
<mjg59> I need to reproduce it with current git and then get upstream to give me a tool to dump the register state
<mdke> my error seemed to say something about AIGLX
<mjg59> I think that's probably irrelevant
<mdke> ok
<Trewas> btw my thinkpad X41 with intel 915GM is crashing on resume only with splash boot-option, with nosplash it works ok
<pitti> Kamion: can I bother you with approving the dapper-proposed langpacks? they really need to get out soon, we keep getting bug duplicates
<tfheen> Riddell: you're aware that kdebase failed to build?
<janimo> tfheen: where is the onboard bzr repo? I can't find it on LP
<janimo> tfheen: I'd like to commit a change that I only added as a patch in 0.82 package but was discarded in 0.83 upload
<tfheen> janimo: http://www.mail-archive.com/ubuntu-accessibility@lists.ubuntu.com/msg00738.html ?
<infinity> pitti: Have they been through the whole new-and-improved approval process and are just waiting for ftpmaster action?>
<janimo> tfheen: I'll look, Ia m not subsrcribed to that
<tfheen> me neither, but it's the first google hit..
<pitti> infinity: yes, mdz already said twice that he is fine with them
<pitti> infinity: and we discussed the future process as well
<infinity> pitti: Is there a paper trail for that? :)
<infinity> pitti: If you could forward me a "yeah, they're fine with me" approval, I'll process them right now.
<pitti> infinity: well, the emails, sure
<infinity> pitti: Those are good enough for me, yes.
<pitti> infinity: sent
<pitti> infinity: while you are playing with the queue, any chance you could release cupsys (bug 54277) and hal (bug 56484), too, before they decay into bitrot?
<Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Fix released]  http://launchpad.net/bugs/54277
<Ubugtu> Malone bug 56484 in hal "hal does not detect non-ATAPI CD-ROM drives" [Unknown,Confirmed]  http://launchpad.net/bugs/56484
<seb128> pitti: language-packs update for edgy still planned for today?
<seb128> hi dholbach
<pitti> seb128: yes
<pitti> seb128: Riddell uploaded new KDE langpacks tonight, but they are too late for today's langpacks unfortunately
<pitti> we might have to roll out another set in a week, but *shrug*
<seb128> we will have an another roll before edgy anyway, no?
<seb128> "might"
<pitti> yes
<seb128> I expect we will have
<dholbach> good morning
<dholbach> hey seb128
<seb128> since the translations are so outdated at the moment than translators can't really work at polishing
<pitti> seb128, Riddell: can you please test the current daily edgy langpacks?
<seb128> k
<infinity> pitti: hal and cups approved, langpacks on their way.
<pitti> infinity: *hug*, thanks
<pitti> seb128, Riddell: oh, please wait a bit still, today's are still building; I'll ping you again when they are ready
<seb128> ok
<tfheen> dholbach: yay, looks like the bluetooth fix fixes the problem for most people.
<dholbach> tfheen: and Matt filed the bluez-* syncs himself - so we seem good to go
<dholbach> tfheen: I got an exception for libbtctl and gnome-bluetooth too - so I'll do some tests and upload it later on
<tfheen> dholbach: excellent!
<dholbach> tfheen: did you file a sync bug for bluez-gnome?
<pitti> dholbach, infinity: dholbach, I'd like to do some rebuilds to get rid of gnutls11 in universe, so that we at least have only two versions; can I get a general approval for that? infinity, can you help me with some syncs with that (e. g. with crywrap)
<dholbach> tfheen: I should make you honorary member of the bluetooth team on LP :-)
<dholbach> pitti: sure
<tfheen> dholbach: :-)
<tfheen> dholbach: no, I didn't, I thought I asked you to?
<dholbach> tfheen: ok I'll do it - once we have the new bluez-utils - will you do the upload changing the discovopt setting?
<tfheen> sure, I can do that.
<dholbach> super
<dholbach> you have a shiny new emblem now :)
<tfheen> or actually, if we want to change the package, no need to ask for a sync
<dholbach> that's fine too
<dholbach> then we just need the bluez-libs sync first
<tfheen> I'm sure we can get Colin or Scott to do that for us
<dholbach> rock 
<xav> did mdz come to an agreement with mozilla?
<pitti> infinity: can you please sync crywrap, echoping, kaya, and libggz? All of these are NMUs for gnutls11->13 or unintrusive maintainer uploads for the same reason
<infinity> pitti: Those are all universe, and have dholbach's approval above?
<pitti> infinity: yes
<infinity> pitti: Consider it done when this for-loop from hell to accept your langpacks is finished. :)
<pitti> infinity: main is clean wrt. openssl and gnutls13, it's just universe I'm caring about now
<pitti> infinity: and *three* gnutls versions are too much for my taste
<sivang> morning
<pitti> infinity: thanks
<pitti> infinity: after these have built, I need to bother you with three more syncs (ggz stuff)
<infinity> pitti: There, 232 langpacks accepted.  Oi.
<pitti> infinity: merci
<infinity> Now on to syncs.  Demanding children...
<pitti> infinity: may I really stress my fortune with asking for cupsys and hal, too? :)
<infinity> pitti: What about them? :)
<pitti> infinity: releasing them from d-proposed
<infinity> I already did that. :P
<pitti> ooh, cool
<pitti> time to ask sfllaw then
* pitti args about thy - it totally doesn't build at all and was removed from Debian a while ago
<pitti> s/args/arghs/
<infinity> pitti: That libggz upload has "Changed build system to CDBS" in the changelog.  Are you sure that's a safe upload?
<pitti> it's only a build system, why not?
<mjg59> infinity: What could possibly go wrong?
<pitti> if it FTBFSes, I'll fix it, but it works fine in Debian
<thom> hah
<infinity> pitti: Right, I hold you personally responsible for the mess of "hey, there's no longer a .so in the devel package" and other such bugs that come from complete repackaging. :P
<dholbach> CDBS to the rescue! :)
<pitti> infinity: yeah, I'll go and grab the asbesto pants in the meantime
<pitti> go away from the archive, thy, go away!
<tfheen> get thy away from me, purge thy from the archive's inner bowels!
<infinity> But algernon maintains it, it must be awesome.
<tfheen> oh well, I have to find some food now.
<tfheen> before I die.
<thom> dholbach: where rescue == rescuing the archive from having any content, anyway
<thom> ;-)
<infinity> pitti: Are you filing a removal request, or should I just kill it on the sly?
<dholbach> thom: pfffft :-)
<pitti> dholbach: what's the process for removing universe packages which are old, unloved, and removed from Debian? just 'whoops', or do you want an archive bug?
<dholbach> pitti: I'm not an archive administrator - I guess they want a bug :)
<infinity> pitti: It's not removed from Debian... It was removed from *etch* due to RC bugginess, but it's still in sid.
<pitti> ah
<infinity> Oh, wait.
<infinity> WTF?
<infinity> No, it's only in sid on kfreebsd-i386.
<infinity> That looks more like a fuckup of some sort. :)
<pitti> http://packages.qa.debian.org/t/thy.html says otherwise
<pitti> dholbach: no, infinity would be fine with just killing it
<dholbach> then kill it
<dholbach> i'll direct the users that still want it to you guys ;)
* infinity whacks thy and thy-auth
<pitti> dholbach: it's the very same version and deb since hoary - plenty of releases to pull it from :)
<dholbach> hehe :)
<Kamion> jdong: I've cleared out dapper-backports NEW now
<Kamion> thanks for the reminder
<infinity> Will remove the following packages from edgy:
<infinity>        thy |    0.9.4-1 | source, amd64, hppa, i386, ia64, powerpc, sparc
<infinity>   thy-auth |    0.3.0-1 | source, amd64, hppa, i386, ia64, powerpc
<infinity> ------------------- Reason -------------------
<infinity> (adconrad) removed from Debian, buggy and unmaintained
<infinity> ----------------------------------------------
<infinity> Going to remove the packages now.
<infinity> Continue (y/N)? 
<infinity> pitti: Good 'nuff?
<pitti> infinity: *hug*, thanks
<geser> are binary packages (in universe) which aren't build in edgy anymore removed automagically?
<pitti> hi sjoerd 
<sjoerd> morning 
* infinity decides to avoid stepping on Kamion's toes..
<infinity> Kamion: Let me know when libtexttools, libaunit, libgtkada2 are all processed, since I was just about to do that and they started disappearing from the queue. :)
<geser> infinity: I'm trying to get an updated php4 from Debian into universe. The problem is it build-depends on both libdb4.3-dev and libdb4.4-dev (which can't be both installed at the same time). Any idea how to resolve this?
<pitti> Kamion, tfheen: ah, I just did an OEM test install, works great now!
<infinity> geser: Yes, I need to either update our apache2 (and its rdeps) to use db4.4, or I need to roll apache1.3 back to using db4.3
<infinity> pitti: Did we standardise on a DB version for main for edgy, or are we just a general mish-mash this time?
<pitti> the latter
<thom> (please do the former :-) )
<infinity> thom: It'll come down to whichever is the least amount of effort, really.
<Kamion> infinity: you realise that 'queue accept' arguments take substrings? so you can just say 'queue -M accept language-pack'
<thom> infinity: *nod*
<infinity> Kamion: Grr, info doesn't, and I assumed that the queue item matching would work the same for any command.
<Kamion> infinity: I was just going to process all of NEW now
<infinity> Wait, now it does again?
<Kamion> infinity: info does ...
<infinity> My head hurts.
<infinity> I swear it didn't used to.
<Kamion> has for a while, but it used to be '\*foo\*'
<Kamion> or '*foo*' I guess if you're quoting
<Kamion> they changed that circa Paris
<infinity> Yeah, I used to use the wildcard syntax before, then when that went away, I could have swore it didn't do substrings.
<infinity> Maybe I was on crack.
<infinity> Oh well.
<Kamion> infinity: libtexttools, libaunit, libgtkada2 all processed
<infinity> Kamion: Danke.
<infinity> On both counts.
<tfheen> infinity,Kamion: did either of you get bluez-libs too?  I'd like to get a new bluez-utils into the archive.
<tkamppeter> doko_, ping
<Kamion> I haven't yet, but can shortly
<pitti> infinity: oops, that was the ultimate dapper-changes ML DoS
<Kamion> infinity: you forgot to use -M, right? :P
<infinity> Kamion: Yes, it slipped my mind until you just mentioned it that langpacks are supposed to be silent.
<infinity> I blame the nap I had right before pitti asked for the ACCEPTs.
<infinity> Oh well, no harm done, just a bunch of annoying mail. :/
<AnAnt> I realize that when I plug/unplug the AC adapter, anacron get started/stopped. Also when I get connect/disconnect LAN cable, the DNS service is reloaded. How is that done ?
<infinity> AnAnt: /etc/acpi/ac.d/ (and this is not a #-devel question)
<AnAnt> infinity: well, they didn't know in #ubuntu+1
<Kamion> tfheen: processing the sync request queue now
<AnAnt> infinity: so how about the network ?
<infinity> AnAnt: "Someone else didn't know" isn't a reason to ask random questions here.  Please try to respect that, doubly-so as we're getting close to a release.
<Kamion> dholbach: there are lots of Ubuntu changes to bluez-utils. Do you know anything about them?
<infinity> I know I've made some.
<dholbach> Kamion: don't sync it, tfheen will make some changes to it anyway
<dholbach> Kamion: I'll comment on the bug.
<infinity> it was all small stuff, like fixing desktop files and making the tray icon transparent, that sort of thing.
<dholbach> Kamion: but bluez-libs would be nice
<dholbach> infinity: I think that was gnome-bluetooth, no?
<infinity> dholbach: Oh, so it was.  I'm a confused man today. :)
* dholbach hugs infinity
<infinity> dholbach: I realised that when I started looking at the changelog. :)
<Kamion> dholbach: thanks; and yes, I've already run sync-source for bluez-libs
<dholbach> Kamion: you ROCK! :-)
<Kamion> er, it's not that hard :-)
<ogra> Kamion, WOW, my ppc iso is 100MB (!!) smaller now
<dholbach> Kamion: anyway :-)
<infinity> We had 100MB of incorrect overrides?
<infinity> Neat.
<Kamion> infinity: speaking of space, could you remove /boot/initrd.img* from the squashfs, please?
<ogra> i wasnt aware how much i already had to thrown out. ubuntu will look quite different
<ogra> -to
<Kamion> (bug 64887)
<Ubugtu> Malone bug 64887 in Baltix "/boot/initrd.img*should be removed from filesystem.squashfs" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64887
<Kamion> infinity: s/cp/mv/ on the relevant line should do fine ...
<Kamion> ogra: neat. you might want to put some stuff back in :-)
<infinity> Kamion: I question the utility of vmlinu[xz]  on the filesystem too, while we're at it.
<infinity> Kamion: System.map should be all we need in /boot.
<fabbione> infinity: probably not even System.map
<tfheen> infinity: vmlinuz is kinda needed for grub, no?
<fabbione> it's not required to boot but it's nice to have
<infinity> Don't we want System.map on the off chance we want to re-run depmod on the live system?
<infinity> tfheen: Err, this is on the livecd.
<tfheen> infinity: which is copied into the installed system by ubiquity.
<infinity> tfheen: vmlinuz on the rootfs is completely useless, afaict.
<infinity> Oh, right, ubiquity.  Feh.
* infinity grumps.
<tfheen> heh.
<infinity> Okay, I'll just kill the initrd, then.
<fabbione> infinity: well the ubiquity is another point to have it there :)
<infinity> (Unless ubiquity wants to steal the kernel from the ISO9660 filesystem..)
<tfheen> I guess we could teach ubiquity to copy the vmlinuz file from the cdrom, but not at this point.
<infinity> Another day, another optimisation.
<infinity> No pooint in doing it now.
<infinity> I'll do the initrd thing now, though.
<ogra> Kamion, or spoil ppc users with langpacks ;)
<Kamion> indeed, vmlinuz needs to be there
<Kamion> see the bug :)
<infinity> Kamion: Yeah, I just read the log, which came to the same conclusion. :)
<heno> tfheen, Kamion: I've attached a patch for the a11y script to bug 58836 but I don't think it will fix the core problem
<Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Undecided,Fix released]  http://launchpad.net/bugs/58836
<heno> I'm not sure the script gets run at all
<tfheen> uh
<tfheen> that'd be weird.
<heno> How do I get text output on the new usplash?
<tfheen> remove quiet from the boot.
<heno> ok, thx
<tfheen> and grab /var/log/casper.log from the booted system and see if it contains any clues
<infinity> Kamion: Are you going to remove the *ubuntu-live packages from *-meta entirely?
<infinity> Kamion: (before release)
<heno> tfheen: cool, will do
<Kamion> infinity: hadn't thought about it, but I suppose we shoul
<Kamion> d
<tkamppeter> doko_, ping
<infinity> Kamion: Well, if I'm using tasks in livecd.sh now (and I am, as of today), and I'm doing that so you can change the tasks without changing the package, then the tasks and package will get out of sync and we won't be able to rebuild without an upload anyway.
<infinity> Kamion: (Since the package is in the task)
<infinity> Kamion: So, I'm pretty sure we have no choice but to drop it.
<infinity> tfheen: I'm going to give that gettext bug a serious looking at in an hour or two (need to go buy some food to cook, then come home), and then I'll deliver a verdict.
<tfheen> infinity: yay.
<tkamppeter> doko, ping
<sivang> hmmm, why does cdrecord have to suck so much and either complain about not being suid root , or just fail with mysterious error messages?
<Kamion> infinity: yeah, we could add to it without uploading, but not remove from it
<Kamion> which is just confusing, frankly
<infinity> Kamion: Right, hence why it should probably be removed. :)
<dholbach> Kamion: thanks for bluez-gnome!
* infinity runs out to seek food.
<sladen> seb128: that DBUS code is going to take a while to write.  Both sections of the code that is commented are read-only, non-critical codepaths.  I'm tempted to make it "just" work by uncommenting the two sections {wifi,modem}_detect and copy those across to that package for the next release
<seb128> sladen: what are you speaking about? the essids listing?
<seb128> sladen: what do you want to copy? the selected essid needs to be applied
<seb128> sladen: you want to copy the code to the g-s-t frontend instead of doing the proper functions of it or something like that?
<Kamion> dholbach: I'll accept it due to urgency, but please (get Debian to) correct debian/copyright to include a reference to the LGPL; several files in bluez-gnome are licensed under that
<Kamion> and fill out the list of copyright holders
<dholbach> Kamion: alright, will send a patch to the maintainer
<sladen> seb128: yes.  Those two helpers have nothing to do with /settings/ and could be called from anywhere.  If they don't get called, we have the status quo
<dholbach> Kamion: thanks.
<Kamion> it's not complete at least with respect to a random file in compat/ I picked
<seb128> sladen: should work fine, I'm busy with other things to fix before edgy atm but if you want to send a patch I'll have a look on it
<seb128> sladen: no, bug-buddy doesn't save the coredump, and it's not weird it's called instead of apport, we decided to keep it that way for now because we are not ready to take over the bug load it would generate
<Kamion> infinity: could you comment on bug 53710, please?
<Ubugtu> Malone bug 53710 in phpdoc "Please re-sync with debian, there's a newer version" [Undecided,Needs info]  http://launchpad.net/bugs/53710
<pitti> seb128, Riddell: ok, today's langpacks are ready for testing
<heno> tfheen: the "Configuring accessibility options..." prompt is displayed and nothing interesting in the log AFAICT
<Keybuk> mjg59: nice iceweasel post
* pitti wonders why all the buildds are idle while there is so much to be built
<Keybuk> probably the build queue failed
<Kamion> heno: is there an access= option in /proc/cmdline? if so, what is it?
<Keybuk> pitti: ?
<Keybuk> there's nothing Needs building
<heno> Kamion: no there isn't
<Kamion> heno: that would be the problem then. starting from the boot screen, what exactly did you do?
<Sp4rKY> hi
<pitti> Keybuk: strange - there are 300 dapper langpacks and maybe 30 edgy universe uploads which need build, e.g. https://launchpad.net/distros/ubuntu/+source/libggz/0.0.13-2
<heno> Kamion: er, but that I assume you mean the boot prompt line
<Sp4rKY> please does some know how use unsquashfs over edgy ?
<Keybuk> ah
<Keybuk> "No builds recorded"
* Keybuk goes to kick soyz
<pitti> Keybuk: and that example, source libggz 0.0.13-2 is in the archive
<Kamion> heno: I mean the graphical CD boot loader screen
<Kamion> the one with the accessibility menu
<Sp4rKY> i have to backport it from debian unstable and it depends of libc6 :/
<Kamion> Sp4rKY: that dependency is autogenerated; if you build the source package on edgy, the dependency will be different
<pitti> Keybuk: thanks
<janimo> heno, hi is launching of onboard going to be provided in the livecd acess menu?
<Keybuk> pitti: sequencer isn't picking up new uploads and creating build records for them
<heno> Kamion: Press F5, select an option, press F6 to look and remove 'quiet' (optional), Press Enter to boot
<Kamion> heno: which option?
<Kamion> (it might matter)
<heno> Kamion: High contrast in this case
<janimo> Keybuk: is there a gcalctool-gtk binary in NEW and if so could you let it in main? thanks
<Sp4rKY> Kamion: yep, but with the source package unsquashfs doesn't works :/
<heno> which has not had any changes in the script
<Kamion> janimo: is it seeded?
<Kamion> (yes, it's in NEW)
<janimo> Kamion: yes
<janimo> as of yesterday
<Kamion> I'll deal with it, then
<heno> janimo: if we can get it to work now, yes :)
<janimo> Kamion: thanks
<janimo> heno: ok, I'll do that for the xubnutu CD as well
<heno> janimo: cool!
<janimo> I am looking at adding at least some xubuntu tweaks to the casper script  
<janimo> like v1 and stikcy keys
<heno> Kamion: "I'll deal with it, then" was that about this casper thing?
<maks> heya
<heno> janimo: great! do you need any input from me?
<Kamion> heno: no, I was talking to janimo
<heno> ah, ok
<Kamion> janimo: processed
<seb128> pitti: grumpf, the control-center translated are still outdated, must be a rosetta issue
<janimo> Kamion: thanks
<maks> Kamion: the edgy beta desktop hangs on localization, hope the daily builds are better? :)
<seb128> pitti: s/translated/translations I mean
<Kamion> heno: I followed that procedure and got access=v1 at the end of /proc/cmdline
<Kamion> maks: please be more verbose
<Kamion> I have no idea what you're talking about
<janimo> heno: I'll try translating the ngome gcionf settings into appropriate sed commands for the xfce config files but will ask you if there's anything
<janimo> heno: btw I filed a patch for onboard to let it run without nautilus
<seb128> pitti: do you have a way to see if the .pot is correctly generated at build time?
<maks> Kamion: http://cdimage.ubuntulinux.org/daily-live/current/edgy-desktop-i386.iso.torrent was not able to install
<Kamion> maks: that's not more verbose, that's actually less verbose
<Kamion> you're not telling me e.g. the error message
<heno> Kamion: is /proc/cmdline the boot option line on the Live CD or an actual path in the system?
<Kamion> I suggest you file a bug
<Kamion> heno: 'cat /proc/cmdline' from a terminal
<pitti> seb128: carlos will notice if it is not generated at all, but we cannot detect outdated versions (e. g. if the pot is shipped in the source package)
<Sp4rKY> Kamion: i get this error when i try a mount -o loop -t squshfs ...
<Sp4rKY> SQUASHFS error: sb_bread failed reading block 0x992a8
<Sp4rKY> SQUASHFS error: unable to read uid/gid table
<Kamion> heno: /proc/cmdline is a kernel-simulated "file" that provides the contents of the kernel command line
<heno> Kamion: ok, I didn't not check that
<heno> ok, thanks for explaining
<pitti> seb128: do you have an example string that I could check?
<seb128> pitti: all the first tab of the gnome-sound-properties capplet
<seb128> pitti: "Sound Playback:"
<Kamion> heno: if the output has access=<something> at the end, it's a casper/something-else bug; if it doesn't, it's a gfxboot-theme-ubuntu bug
<maks> Kamion:  no i don't have an account on launchpad and in 5 min the daily build is here, if it hangs again i'll bug you with the error message from the logs
<pitti> seb128: indeed, they are English for me as well; let me have a look
<seb128> pitti: my local build is fine, upstream translations are working
<Kamion> maks: ok, I'm happy to deal with an error message but I'm sure you can understand that "hangs on localization" is not something I can get my teeth into
<seb128> pitti: the language pack .mo have no mention of those strings though
<Kamion> maks: (BTW my kernel hangs on PCI)
<Kamion> (P.S. I lied)
<maks> :-P
<heno> Kamion: right, I do get access=v1 as well on /proc/cmdline
<dholbach> infinity: could you please comment on bug 65266?
<Ubugtu> Malone bug 65266 in php4 "[UVF Exception]  Sync php4 4.4.4 from Debian unstable" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65266
<Fujitsu> php4 4.4.4, I like it.
<maks> Kamion last message is "Set d-i/locale = 'en_US.UTF8
<heno> seb128: Thanks for patching the at preferences, works nicely! Now we just need to get rid of the extra menu items in Applications -> Accessibility. Shall I file a separate bug about that?
<Kamion> heno: I think I see the problem
<heno> Kamion: \o/
<pitti> seb128: indeed, the German file from Rosetta has
<pitti> "POT-Creation-Date: 2006-06-15 17:56+0000\n"
<pitti> "PO-Revision-Date: 2006-08-25 22:57+0000\n"
<Kamion> maks: try starting the installer with 'sudo env UBIQUITY_DEBUG=1 ubiquity' and putting the log somewhere I can see
<seb128> heno: np, just tell me  what changes are to do on the chan, I'll do them now
<Kamion> maks: oh, the log = /var/log/installer/syslog + /var/log/installer/debug
<seb128> pitti: any idea of why?
<pitti> seb128: let me find the translations tarball
<Kamion> heno: gconf_version=$(chroot /root /usr/bin/dpkg-query -W --showformat='${Version}' gconf-2 2>/dev/null) || gconf_version=""
<Kamion> heno: the package is called gconf2, not gconf-2
<heno> seb128: just remove the onboard, onboard settings and orca menu entries. That way we get rid of the Accessibility menu completely
<seb128> pitti: intltool-update: POTFILES.in not found.
<seb128> pitti: ok, that's because the package is build out of the srcdir
<maks> Kamoin: thanks not reproducible in DEBUG mode
<Kamion> just trying out the fix now
<Kamion> maks: !
<seb128> pitti: so the build po/ has no POTFILES.in
<Kamion> maks: try from a fresh boot
<seb128> pitti: I'll fix it now
<Kamion> maks: debug mode isn't meant to magically make problems go away ;-)
<maks> we are trying from fresh reboot
<seb128> pitti: would be nice if we had a page or something listing packages without a .pot though :/
<pitti> seb128: yeah
<pitti> seb128: indeed, translation tarball only has debian/build/help/control-center.pot
<sivang> does anybody know if cdrecord ever supported burning into DVDs and/or blanking them?
<heno> Kamion: sounds good, so that must have been changed during edgy some time I guess
<pitti> sivang: that's traditionally growisofs' job
<pitti> sivang: our cdrecord does not have dvd extensions
<sivang> right, so that's why I'm getting those terrible cryptic 'not supported' messages :)
<Kamion> heno: yes, r293 on 6 September
<Kamion> works now
<sivang> pitti: so I should use dvd+rw tools instead , thanks
<heno> woooo!
<Kamion> tfheen: want to check my casper commit and upload that?
<Riddell> pitti: language packs working fine
<pitti> Riddell: they don't contain last night's updates, though
<tfheen> Kamion: checking
<pitti> Riddell: is it ok for you if we do another update right before release to pick them up?
<seb128> pitti: out of that issue update looks fine to me
<tfheen> Kamion: oh, I suck.  Feel free to upload.
<tfheen> (I'm in the middle of the bluez-utils merge)
<pitti> seb128: with some manual hackery (shouldn't take more than 20 minutes) I can smuggle the po files in and trigger a rebuild
<seb128> pitti: would be nice, thank you
<seb128> pitti: if you update them next week again that should work though
<Riddell> pitti: that would be great
<seb128> it just don't give the week for translators to fix issues they might notice
* pitti takes out his shell hacking fingers
<Kamion> tfheen: ok
<Keybuk> tfheen: random question; I modified /etc/mailman/en/*.html, ran arch by hand, and they changed -- but in the automatic run, it ignores my templates
<tfheen> Keybuk: "they changed" meaning the archives changed or the templates changed?
<tfheen> there are per-list templates too
<Keybuk> archives
<tfheen> unsure if that plays in
<pitti> seb128: ok, hacking finished, new edgy langpacks are building
* seb128 hugs pitti
<seb128> pitti: control-center with fixed pot build uploaded from my side
<Keybuk> tfheen: maybe it's just cached in memory?
* Keybuk tries restarting mailman
<pitti> seb128: *hug*
<maks> Kamion: daily build works, so we'll happily showoff this one for the teaching class
<Kamion> ok, cool
<Kamion> I've fixed a few things since beta, some of which touched localisation
<infinity> Kamion: Commented.
<infinity> dholbach: And yours too.
* dholbach hugs infinity
<seb128> sladen: have you tried apport-retrace --download-debug to download automatically the debug packages for a given crash?
<sladen> seb128: I don't think that helps if apport didn't catch the crash and you're just trying to get the correct ones installed for bug buddy next time
<seb128> sladen: if you use bug-buddy that's not really apport's job, might be better place to apt
<seb128> sladen: like apt-get debug-dep package
<seb128> like build-dep
<infinity> Yeah, I argued in Paris that "apt-get debug apache" should get me apache's debug symbols, plus symbols for all the dependencies.
<Kamion> heno: oh, sorry, I didn't incorporate your accessibility update - feel free to reopen that bug if that's still required
<dholbach> infinity: that'd be soooo good
<Kamion> heno: (or perhaps a fresh bug would be better at this point)
<Kamion> mvo: could you clarify what you meant by "server install" in bug 60415? i.e. "Install a server" from the alternate install CD (now "Install a command-line system") or a normal install from the server CD?
<Ubugtu> Malone bug 60415 in debian-installer "English keyboard on german install" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60415
<Kamion> infinity: thanks
<mvo> Kamion: IIRC it was a "command-line-system" install, let me try to reproduce it
<Kamion> it's curious, I haven't yet tried to reproduce it (although I will, if you still can), but I don't know why a command-line install would affect that
<Kamion> oh, unless the lack of X is relevant; that could be ...
<mvo> Kamion: ok, give me some minutes to check it again
<Kamion> or I can do it, just talking about it gave me an idea for a possible cause
* Kamion thanks mvo for being a volunteer pot plant ;-)
<Kamion> my test rig's doing a netboot install at the moment which is obviously a bit slow
<mvo> Kamion: no problem, my test-upgrade just finished, the machine has spare cycles :)
<mvo> Kamion: no, can't reproduce it anymore, its all fine now. strange thing
<tfheen> hmm, why does ndiswrapper even build stuff on ppc?
<tfheen> dholbach: you're closing #56651 once bluez-gnome is synced?
<janimo> Kamion: gcalctool-gtk did not show up yet in the archive, is the publishing delay this large?
<seb128> do we have a snapshot.ubuntu.com?
<dholbach> launchpad! :)
<seb128> it has all the previous source packages stored?
<dholbach> yes, at least the ones since we use soyuz
<dholbach> tfheen: should it be in supported or something?
<dholbach> anyway, I wanted to be running already - see you later :)
<seb128> rock on 
<tfheen> dholbach: I think it should be in supported or something, yes.
<dholbach> tfheen: I add the MIR on my list
<dholbach> tfheen: if cheerleading is needed it'd be nice if you could jump in
<tfheen> dholbach: will do, thanks.
<dholbach> cool
<dholbach> seeya
<kristog> hello
<Kamion> janimo: malcc was running the publisher by hand, and probably only re-enabled it recently
<Kamion> mvo: oh, it could easily have been fixed by console-setup 1.7ubuntu12 or similar
<Kamion> thanks for re-testing
<mvo> Kamion: cheers
<mvo> Kamion: I closed it already
<kristog> dholbach, tfheen  how i can help you with bluez-* ?
<tfheen> kristog: it's all trickling in now, so I think we're fine, actually.
<kristog> tfheen, cool :)
<tfheen> kristog: I just uploaded a new bluez-utils (3.7) package, we've synced bluez-libs and are syncing bluez-gnome
<heno> dholbach: will you pull the upstream patch for bug 59531 ?
<Ubugtu> Malone bug 59531 in gnome-desktop "Add a 'Quit Orca' button" [Unknown,Fix released]  http://launchpad.net/bugs/59531
<dholbach> tfheen: pybluez is in incoming - we need to sync that too
<dholbach> heno: need to look at it - i'll just get lunch, then do it
<heno> cool, thx
<tfheen> dholbach: what do we need it for?
<dholbach> tfheen: it's needed, because it works with bluez-libs 3.7 
<dholbach> the other does not - iirc
<tfheen> dholbach: *shrug*; it's universe so feel free.
<dholbach> already did it for bluez-hcidump
<dholbach> i'll do it, when i get back from lunch - on my list
<tfheen> doko__: what's up with 63864?
<dholbach> can somebody get libbtctl through binary NEW?
<dholbach> oh, it already is
<dholbach> yeehaw
<tfheen> mvo: 63183 - is it crucial for 6.10, you think?
<mvo> tfheen: not likely, it seems that it is caused by a locally installed python module - it would still be good if it could be fixed IMNSHO opinion there is no point in the postinst script failing 
<tfheen> mvo: I can't see any responses from the submitter though
<funman> hello
<tfheen> doko__: also, if you could answer iwj in #57161, that'd be good.
<mvo> tfheen: right, but I was not able to reproduce it on a normal upgrade and doko thinkgs that this is the most likely explaination
<tfheen> mvo: also, have you gotten access to the popcon logs and found out how to solve the "duplicated hostid" problem?
<mvo> tfheen: no, no response from my rt ticket yet unfortunately - no access and no logs :/
<mvo> I pinged again monday (IIRC) but still nothing
<tfheen> mvo: what's the ticket #?
<mvo> tfheen: #16960
<tfheen> mvo: thanks, I'll go prod the sysadmins now. :-)
<mvo> tfheen: thanks :)
<heno> Kamion: here is a new bug 65297
<Ubugtu> Malone bug 65297 in casper "change gnopernicus -> orca and gok -> onboard in script" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65297
<heno> Use the second patch pls, as it fixes another bug too
<pitti> infinity: do you have a minute to sync the remaining ggz packages now? libggz has built everywhere and is in the archive
<pitti> infinity: it's ggz-client-libs, ggz-kde-client, and ggz-kde-games
<pitti> infinity: (all universe, just for gnutls11 transition)
<infinity> pitti: Can do.
<infinity> pitti: Done.
<pitti> seb128, Riddell: new langpacks have built, please test again
<pitti> infinity: thank you
<tfheen> pitti: why is the mysql-server security vulnerability 6.10-critical?  It'd surely be nice to have in, but we haven't hold up releases in the past for similar issues.
<pitti> tfheen: the part that's milestone'ish is mdz's decision whether we want to sync 5.0.24a from Debian or just apply the security patches
<pitti> tfheen: in the latter case, we don't need the milestone
<pitti> tfheen: but I would still like to settle it today, just awaiting mdz's reply 
<tfheen> pitti: oh, you might want to subscribe the release team then. :-P
<tfheen> pitti: or mdz, since he's not subbed either (or maybe he's part of the security team, I'm not sure)
<pitti> tfheen: the discussion went on over private mail between him, me, and infinity 
<xeros> I have the symptoms of old bug 14911 now in firefox 2.0rc2 - can someone else admit that he has it, too?
<Ubugtu> Malone bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Unknown,Confirmed]  http://launchpad.net/bugs/14911
<tfheen> pitti: ok, goodie.  I'll shut up, then
<tfheen> mvo: znarl's either giving you access or putting the files somewhere you can get at them.
<mantiena> pitti, hi, how are you doing ?
<pitti> mantiena: hi! fine, thanks, and you?
<tfheen> Spads: have you had a chance to retest a daily on any of the xserves or the pb in the office?  (Re bug #64198)
<Ubugtu> Malone bug 64198 in xserver-xorg-video-ati "LiveCD can't start X on Apple Xserve or PowerBook" [High,Confirmed]  http://launchpad.net/bugs/64198
<doko> Kamion, tfheen: 63864 is not relevant for the default installation; the default style is now selected for non-KDE and non-GTK installations; if we want to be fool-proof again, we have to include the 4MB default icons on the CD
<tfheen> doko__: hmm, ok.  Is it a recommends or similar?
<Spads> tfheen: we tried a daily on the pb in the office on monday/tuesday
<Spads> tfheen: livecd couldn't get X up, but installing dapper and upgrading worked fine
<doko> tfheen: 57161, I'm trying to fix that on the eclipse side, too late for firefox changes
<pitti> seb128: yay translated control-center
<tfheen> doko__: or maybe have it depend on one of the icon styles (or-ed)?
<doko> Package: openoffice.org-common
<doko> Depends: openoffice.org-style-default | openoffice.org-style-industrial | openoffice.org-style-crystal
<tfheen> doko__: 57161 > ok, thanks.
<tfheen> then how has he managed to not have any of them installed? (Or did I misread the bug report?)
<tfheen> Spads: weird, ok.  If you could test with yesterdays or todays or so, that'd be good since Fabio thinks he might have fixed it.
<Spads> tfheen: I'll try burning one now
<doko> I added openoffice.org-style-default in the last upload. the problem is, that OOo doesn't explicitely check for installed icon sets.
<tfheen> Spads: thanks a lot
<tfheen> doko: .. ok.  Is that hard to fix?  (As in, do you think we can get it done for the release?)
<mantiena> pitti, almost ;) I still can't write regexp, which allows [ and ]  symbols in /etc/pmount.allow :(
<doko> tfheen: hmm, lacking time ... the choices in the UI are static at the moment
<tfheen> doko: ok.  I don't think it should be 6.10-targetted, then.  Was it you or somebody else who added the target?
<doko> tfheen: I did want to have the -default dependency in, which is done now. maybe remove the target
<tfheen> doko: ok, I'll remove it then.
<tfheen> doko: thanks.
<doko> seb128, Riddell: can an application see, if it was invoked from the gnome/kde/whatever menu?
<mantiena> pitti, yours yesterdays solution - whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+*.\[\] \-] +)[[:space:] ] *(#.*)?$"; doesn't work at all
<mantiena> pitti, but whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+*.\-] +)[[:space:] ] *(#.*)?$"; works fine
<Kamion> doko: I agree with you that it is not release-critical, but the reporter(s) are entirely correct that the program should not break if you don't have those packages installed and try to select the styles. IMO you're missing the point by telling them to install the packages.
<pitti> mantiena: but I told you that \[ doesn't work, you have to put ]  as the first character into the set
<Kamion> ... although I see tfheen said the same already
<pitti> mantiena: please read regex(7)
<Kamion> mantiena: having - as anything other than the first or last character in the [...]  class is also wrong
<tfheen> Kamion: yeah; I just noted in the bug that it's obviously a bug, but we don't have the resources to fix it before release.
<Kamion> oh, you do have it as the last character - never mind
<mantiena> pitti, you told, that I must use \- as last character ;)
<pitti> mantiena: right
<pitti> mantiena: and also that ]  must be the first
<doko> Kamion: I don't deny that. my current fix was to have a sane default installation. the bug is certainly still there.
<mantiena> pitti, hehe, it seems I didn't noticed you talks about first ;)
<infinity> tfheen: Meh, I concede defeat on grounds of inconvenience.  There are a few too many RCS revisions to hack here without spending a couple of hours in a text editor.
<tfheen> infinity: grr, ok.
<tfheen> infinity: that leaves us with the choice between applying said 23MB diff and having gettext not work correctly with auto{conf,make}, right?
<Riddell> doko: no
<infinity> tfheen: Sounds like it, yes.
<Riddell> doko: but you can have two .desktop files one of which is OnlyShowIn=|Gnome and one is NotShowIn=Gnome
<AlinuxOS> Kamion, hello, would you be so kind to tell me the exact time of deadline for nonpack transaltions in Edgy?
<dholbach> http://wiki.ubuntu.com/EdgyReleaseSchedule
<Kamion> AlinuxOS: no
<AlinuxOS> dholbach, I know
<tfheen> Keybuk: on a scale from 1 through 10, how confident are you that the new gettext won't blow up the world?
<AlinuxOS> it's tommorow night or day? :)
<doko> Riddell: doesn't help. I have a program, that goes in interactive mode, when it fails to import the python Qt bindings; so I just want to have a gtk warning dialog, when it's started from the menu. what is DESKTOP_STARTUP_ID?
<Kamion> mantiena: "\-" is not a character in a regex class
<tfheen> AlinuxOS: it's tomorrow morning.
<Kamion> mantiena: it is two characters, "\" and "-"
<AlinuxOS> tfheen, thank you.
<Kamion> AlinuxOS: even if I could tell you an exact time, it is a horribly bad idea for you to rely on it
<tfheen> probably a bit after I've had breakfast tomorrow.
<Keybuk> tfheen: well, it's been in unstable for a while
<tfheen> AlinuxOS: I'd not recommend against relying on any particular point in time.  Maybe we'll freeze earlier or later.
<Spads> tfheen: so this may be a dumb question, but cdimage only has up to daily-live/20061009
<AlinuxOS> Kamion, the problem is not time...the problem is that I've some translated ready modules, but import exports are very slow.
<Spads> tfheen: where should I go for today's?
<Keybuk> tfheen: though there is a serious bug filed against it there
<Kamion> Spads: if it's not on cdimage, it didn't build, or didn't mirror successfully
<AlinuxOS> consider that yesterday (day) I've requested debian-installer .po file and I've recieved it only today.
<tfheen> Keybuk: it seems to have blown up a bit there, yes.
<Kamion> http://people.ubuntu.com/~henrik/winfoss/edgy/ubuntu/current/ubuntu-winfoss-6.10
<Kamion> .tar.gz:
<Kamion> heno: please fix?
<Keybuk> "The new upstream version of gettext has improved checking of .po file syntax, which unfortunately is causing a number of build failures in unstable now."
<Kamion> 07:43:00 ERROR 403: Forbidden.
<AlinuxOS> Kamion, I've debian-installer help file too, yesterday I've uploaded it...but it's not uploaded yet.
<Keybuk> did infinity's rcs hacking attempts fail?
<Kamion> AlinuxOS: I'm sorry, but none of this is my problem
<heno> Kamion: looking
<Kamion> if it's too late, for whatever reason, it's too late, unless it's release-critical in which case we can consider exceptions
<tfheen> Keybuk: yes, he gave up.
<pitti> doko, doko__: ok for you if I freshen ia32-libs now?
<Kamion> AlinuxOS: I'm not going to be sitting there at the keyboard hitting "reload" until I get the absolute latest translations
<infinity> Keybuk: Fail is the wrong word, it just looks like a few more hours than I'd prefer to spend in a text editor.  If we decide that's really the ONLY option, I can spend a day hating myseld and doing it.
<infinity> Keybuk: I punted the bug back to you in the meantime.
<mantiena> pitti, Kamion: So, I should use: whitelist_regex = "^[[:space:] ] *([\] \[[:alnum:] /_+*.\-] +)[[:space:] ] *(#.*)?$";  ???
<AlinuxOS> Kamion, loool I uderstand you but I'm working too...and infrastructure is too slow..it's not my fault.
<pitti> mantiena: [\] \[ looks wrong to me
<pitti> mantiena: it should be [] [ ... ]  according to the docs
<Kamion> AlinuxOS: and what I'm saying is that if your translation doesn't make it, I'm sorry, but I won't be held responsible
<pitti> mantiena: but if it works that way, fine for me
<infinity> AlinuxOS: Many of my late deliverables "aren't my fault" either, but despite my being on the release team, I'm not allowed to make exceptions for myself. :)
<infinity> AlinuxOS: If you're not on time, you're not on time, and there's always next time.
<Kamion> "get the translation in as fast as you can" is the only guideline that can workk
<Kamion> work
<AlinuxOS> :)
<doko> pitti: no problem, maybe -gtk and -kde are worth updating as well
<Kamion> you're not supposed to try to get things in exactly on the deadline
<AlinuxOS> infinity, I'll do it manually this evening! :) And I'll be in time :) 
<pitti> doko: bah, it fails at linux-kernel-headers
<pitti> doko: I guess linux-headers-generic is the replacement?
<mantiena> pitti, ok, I will try. Btw, did you tried to mount any hard disk partition, whitelisted in /etc/pmount.allow with nautilus (from computer: location) ?
<pitti> mantiena: no, I didn't
<tfheen> Keybuk: so, it seems like it hasn't blown up that much in unstable, or at least not that much we care about.  *ponders*
<heno> Kamion: fixed
<doko> pitti: hmm, no
<AlinuxOS> Kamion, infinity I'm not discussing...I've just asked you :) I know that you are very busy...+ I want thank you simply for your work.
<sfllaw> pitti: Got your SRU e-mails.  Thanks.
<Kamion> heno: thanks
<Kamion> I'll kick off new builds
<pitti> doko: ah, linux-libc-dev rather
<pitti> sfllaw: hi! thanks
<tfheen> Kamion: thanks.
<tfheen> Kamion: could you please tell Spads when they're done too?
<doko> pitti: yes
<dholbach> hm, bluez-gnome "needs building" - can somebody do something about that? :-)
<Spads> tfheen: thanks
<infinity> dholbach: I can make it need harder?
<dholbach> infinity: that'd be very nice :)
<infinity> Alright, now it has a MIGHTY need to build.
<dholbach> and I was wrong the new libbtctl binaries aren't out of NEW yet
<Kamion> I'll deal with that now
* dholbach hugs infinity
* dholbach hugs Kamion too
<Kamion> done
<dholbach> heno: what was the plan for orca? apply the upstream patch?
<infinity> dholbach: Slut.
<dholbach> Kamion: Thanks a lot.
<dholbach> infinity: come on! you have those days too... ...
<infinity> *cough*
<infinity> Yes, some days I also need ot "walk my dog" more than usual.
<dholbach> hahahaha
<heno> dholbach: You suggested looking at it in the bug comments and I agree that it's a good option
<dholbach> heno: ok - so I try both and look which one is better?
<heno> dholbach: well ours is better :) But with theirs we stay in sync
<heno> speaking of the turtle :)
<heno> we were just looking at the orca Quit patches
<dholbach> heno, tortoise_: if you or TheMuso agrees on updating the patch for every release and maintaining it, I'm happy to upload it
<dholbach> heno, tortoise_, TheMuso: that's your choice
<seb128> doko: not really, look at environment variables makes the trick
<tfheen> dholbach: I'd like to get it in quite quickly though; 6.10-targetted and all.
<heno> dholbach: I would say go with the upstream one. We'll try to get the difference pushed into upstream as well this cycle (2.17)
<doko> seb128: yes, hacked that together
<heno> dholbach: the main point is the Quit button, which both have
<dholbach> tfheen: I don't intend to have a longer discussion about it.
<tortoise_> dholbach: Is this the at-properties patch?
<dholbach> tortoise_: orca quite, bug 59531
<Ubugtu> Malone bug 59531 in gnome-desktop "Add a 'Quit Orca' button" [Unknown,Fix released]  http://launchpad.net/bugs/59531
<lastnode> sfllaw, ping
<dholbach> s/quite/quit
<heno> tortoise_: the at-properties one is in place and working
<tortoise_> heno: Whats the difference between mine and the upstream?
<heno> tortoise_: yours has the Apply button and close instead of cancel
<heno> tortoise_: yours is a bit more useable for magnifier users I think
<tortoise_> heno: Didn't I make that a separate patch?
<heno> tortoise_: right, so it's just Close vs. Cancel
<heno> a semantic difference really
<Riddell> doko: I see no DESKTOP_STARTUP_ID
<heno> to be discussed with the gnome usability people
<tortoise_> heno: Does the upstream one have an apply button?
<heno> tortoise_: no
<heno> don't think so (checking again)
<pitti> doko: yup, refreshing and fixing -gtk and -kde now, too
<mantiena> pitti, So, I have one usability problem when click on any hard disk partition, whitelisted in /etc/pmount.allow with nautilus (from computer: location) - it mounts fine, but nautilus still displays unmounted disk icon and doesn't enter inside partition when I click on it :(
<dholbach> heno, tortoise_: the upstream patches don't apply at all :-(((
<mantiena> pitti, I can see partition content only when I press refresh button in nautilus :(
<pitti> mantiena: hm, does hal pick up the mount?
<heno> dholbach: so then it's an easier choice :)
<mantiena> pitti, I don't understand you, what you mean ?
<dholbach> heno: ok - since the other patches are in 2.17 already we get them for free for ... edgy+1
<heno> dholbach: we can even drop the patch in the Edgy+1 merge again, because it's so close to theirs
<heno> right
<pitti> mantiena: do you see a difference in the mounted attribues in lshal before and after mounting?
<heno> dholbach: do Chris' patches apply?
<dholbach> heno: lemme check
<dholbach> heno: cleanly (if done in the right order ;-))
<mantiena> pitti, I will try
<infinity> dholbach: Uh...
<dholbach> infinity: hm?
<infinity> dholbach: The bluez-gnome currently building is 0.5-2, but there's a 0.5-2ubuntu1 that was in queue/new.. Did you really want that one instead?
<dholbach> infinity: I can reupload - that's fine
<infinity> (I suspect someone only accepted the sync and not the merge)
<dholbach> infinity: or bump the version, that's fine too
<infinity> dholbach: No need to reupload, I can accept it now.
<infinity> dholbach: Just wanted to know if you want it. :)
<dholbach> infinity: cool - I just changed the copyright after Colin accepted it
<dholbach> if 2ubuntu1 builds later today that's fine too :-)
<Kamion> I accepted the sync, yes, but another one might have come through before the overrides were committed
<infinity> Right, I'll accept the ubuntu revision now, and push the sync binaries through NEW, so the rest will go without intervention.
* dholbach hugs infinity
<tortoise_> dholbach: I'll maintain it if you upload it, I think (hope) the current orca config is going to be redone in a more gnome-ish way at some point anyway
<Keybuk> tfheen: I leave the decision up to you, oh release master, you
<tfheen> Keybuk: lucky me. :-P
<dholbach> tortoise_: thanks a lot
<heno> \o/
<infinity> dholbach: All better.
<dholbach> *phew*
<heno> the a11y stuff is really falling into place today
<jdong> Kamion: did you get my poke yesterday about binary NEW/ backports?
<infinity> jdong: He processed them, no?
<Kamion> jdong: yeah, and I replied to say I'd done them and thanks for the reminder
<jdong> Kamion: oh cool, when did you do them?
<Kamion> about four or five hours ago
<jdong> cool
<jdong> thankie
<jdong> oh yeah, another thing, Kamion....
<jdong> bug 63842 has been granted UVFe for over a week now with no activity... I was told it needs sync approval from ubuntu-archive?
<Ubugtu> Malone bug 63842 in avidemux "UVF Exception Request: x264 to svn20060928 from marillat" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63842
<Kamion> jdong: I was waiting for a member of ubuntu-dev to actually request the sync
<seb128> pitti: new language packs look good, and control-center is translated correctly ;)
<Kamion> jdong: you said it needed an avidemux rebuild
<pitti> seb128: ok, I'll ask malcc/cprov to upload
<seb128> cool
<Kamion> jdong: and you asked slomo/nafallo to ask for the sync, which neither of them has yet
<jdong> Kamion: ok, so you need a dev to actually do the sync request?
<pitti> doko__: there is no new stuff for ia32-libs-kde, I'll skip that
<Kamion> jdong: yes - syncs are like uploads in that respect
<Kamion> we need at least confirmation from somebody who could ordinarily do the upload
<jdong> Kamion:  slomo I believe is on vacation... and crimsun is waiting for the sync :)
<jdong> ok
<Kamion> just get somebody to say "yes, I've checked that over and it's ok"
<doko> pitti: even better :)
<jdong> Kamion: ok
<Kamion> preferably in conjunction with actually checking it over ;-)
<jdong> :)
<jdong> thanks :)
<heno> Kamion: did you ever look at applying that run-orca-as-root hack to ubiquity?
<Kamion> if the comments from siretart and dholbach were intended as sync approval, that's fine too, but I wasn't sure
<Kamion> heno: oh, no, I guess I should ...
<Kamion> is there a bug for it?
<heno> Kamion: it started with bug 59250
<Ubugtu> Malone bug 59250 in ubiquity "ubiquity makes at-poke hang" [Undecided,Needs info]  http://launchpad.net/bugs/59250
<heno> Kamion: but we followed up on email
<heno> Kamion: only if you have time. There is a reasonable workaround for it too
<Kamion> heno: oh, I think I was waiting for the orca script to be put somewhere
<heno> (run both as root manually)
<Kamion> since dholbach reckoned it should live in gnome-orca
<Kamion> has that been done?
<heno> Kamion: yes, that's working
<Kamion> ok
* heno is away for ~20 mins.
<doko> mvo: ping ...
<doko> mvo: unping
* Spads grabs the 20061011.1/ build
<Kamion> Spads,tfheen: ... oh yes, they're done, forgot to say
<Spads> haha
<Kamion> heno: is the Orca Preferences thing meant to come up when booting the live CD with the screen reader on?
<mantiena> pitti, Yes, there is a difference in lshal output before and after mounting with nautilus
<mantiena> pitti, volume.is_mounted was false before and  true after
<pitti> mantiena: that's good
<pitti> mantiena: then something in gnome-vfs seems to ignore it
<mantiena> pitti, also volume.mount_mount was '' before and '/media/idedisk' after
<mantiena> pitti, btw, on another system with libgnomevfs2 version 2.14.1-0ubuntu8 mounting with nautilus works fine - disk icon changes to mounted and I enter into volume automatically ...
<pitti> mantiena: it might treat 'idedisk' specially, I have to look into this, but I do not have time for that now (sorry)
<heno> Kamion: ideally no, but there is a problem there in that we cannot force the magnifier on in the way we did with gnopernicus because Orca doesn't use gconf
<Kamion> ah
<Kamion> it just surprised me
<Kamion> heno: any further idea of whether that sleep after starting orca is necessary, or should I just read the source?
<heno> Kamion: I just discovered that and put it in the casper bug report with the patch
<heno> Kamion: what was the sleep for again?
<Kamion> you suggested something along the lines of sudo orca -n; sleep 2; sudo ubiquity
<mantiena> pitti, ok I will look into it by myself
<heno> Kamion: not sure why. Your judgement will be better than mine there
<heno> I probably just made that up ;p
<dholbach> tortoise_, heno: uploaded - thanks a lot
<heno> cool!
* heno hugs dholbach
* dholbach hugs heno back :-)
<seb128> dholbach: what did you upload?
<gnomefreak> iwj: is edgys firefox supposed to overwrite existing symlinks from other versions?
<heno> seb128: gnome 2.17 ;)
<heno> seb128: a patch to Orca
<seb128> heno: my question is because I uploaded gnome-orca like 15min ago for the menu change
<heno> to add a quit button
<seb128> I wanted to know if he based it on my upload
<jdong> gnomefreak: what symlinks?
<heno> seb128: ok, cool. Sorry for being a wiseass :)
<seb128> np ;)
<dholbach> seb128: : gnarf
<dholbach> seb128: i'll re-upload :-)
<seb128> heno: apparently he didn't :p
<seb128> dholbach: k ;)
<gnomefreak> jdong: i use mozilla's firefox not normally ubuntus but every update of ubuntu's firefox overwrites all the links for my firefox
<jdong> gnomefreak: where are you putting your symlinks?
<seb128> gnomefreak: I'm not sure the distribution is supposed to support your random hacks
<jdong> (that's what I was trying to get at)
<gnomefreak> seb128: yes i understand but it shouldnt overwrite them either should it?
* gnomefreak thought it was safe having built ff in /opt/
<thom> well, if you're putting a symlink into /usr/bin/firefox, then yes, becaues the package owns that file
<seb128> gnomefreak: how can the package know youa re doing hacks out of the packaging system?
<jdong> gnomefreak: look at dpkg's divert feature?
<gnomefreak> i set them
<gnomefreak> sudo dpkg-divert --divert /usr/bin/firefox.ubuntu --rename /usr/bin/firefox
<gnomefreak> ah
<gnomefreak> /usr/bin :(
<Spads> tfheen: well the bootsplash progress bar in the latest daily works better than the Sunday build did.
<tfheen> Spads: good, good
<Spads> hmmm, or it was...
<Spads> tfheen: it just went to black base, rainbow background for the progress bar, correct image for the completed portion, which was something we saw on Monday
<iwj> gnomefreak: Err, WDYM `existing symlinks' ?  Other versions of firefox ?
<Spads> however, X appears to be starting
* iwj reads scrool.
<Spads> tfheen: so apart from the cosmetics of the last stage of the bootsplash stuff, it looks good
<gnomefreak> iwj: i have FF 3 and when you update FF2 its not leting me run FF3 it defualts back to 2
<gnomefreak> im working on it right now
<iwj> gnomefreak: If you want to have `firefox' mean your version, the right answer is to put your version in /usr/local/bin, which ought to be earlier on the PATH.
<Kamion> heno: heh, ok, I'll see what I can work out
<gnomefreak> ok ty 
* popey pokes cbx33 
<iwj> But I'm reading between the lines here.  You don't say which files it's overwriting, but yes, the packaging system will overwrite all of the files belonging to the firefox package even if you've messed with them.
<tfheen> Spads: probably usplash and dpkg-reconfigure xserver-xorg not being entirely friendly with each other, then.
<iwj> Apart from the config files (generally in /etc).
<cbx33> hey popey 
<Kamion> and unless you've diverted them
<tfheen> iwj: have you had a look at https://launchpad.net/distros/ubuntu/+source/firefox/+bug/63814 ?
<Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  
<doko> pitti, tkamppeter: gutenprint still installs the symlink in /usr/share/cups/model. Is this really correct? cups will see the entries twice?
<Spads> tfheen: yeah, well it used to happen sooner in the bootsplash period, and there was a bit of a hang involved before that isn't there now
<seb128> tfheen: I think that's the
<seb128> "  * Fix/workaround for epiphany GtkSocket lifetype crash:
<seb128>     apply patch id=241087 from Mozilla Bugzilla #241535 to fix LP #63814.
<seb128> "
<seb128> tfheen: from the upload of yesterday
<doko> sivang: what is #65433 about?
<tfheen> seb128: oh, probably, yes.
<tfheen> iwj: if you'd be so kind as to close the bug, I'd appreciate. :-)
<seb128> Keybuk: could you comment on whether you think the patch from bug #63975 is good to upload?
<Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
<Hobbsee> infinity: you around still?
<tfheen> Hobbsee: he went to bed.
<tfheen> (not that that means he's not around, mind)
<Hobbsee> tfheen: right.  i'm looking for someone to nuke gomoku.app_1.2.7-7ubuntu1
<Hobbsee> (because i screwed up)
<Kamion> heno: yeah, the problem is that orca won't fork itself, you have to put it into the background
<tfheen> Hobbsee: nuke as in?
<Hobbsee> tfheen: kill, get rid of, remove, etc.  stop it building.  -6 was just uploaded, and i didnt see it.
<Hobbsee> a) i got the version wrong and b) it was already done.
<Hobbsee> which means that when debian syncs -7, we'll be in trouble.
<Keybuk> seb128: I've repeatedly said many times that I'm not happy with that
<Keybuk> not this close to release
<heno> Kamion: when I run it as root it kills the user-run copy, which seems ok (not sure if that's what you mean)
<seb128> Keybuk: your only comment on the bug is "Please provide a rationale for this change, citing the bugs it fixes.", if you said it many times maybe you should say it once on the bug instead?
<Kamion> heno: the problem is that when you run something in the background, you have no idea when it's actually managed to start up
<tfheen> Hobbsee: I suspect you'll need to have it rejected, then.
<Kamion> heno: if orca had a switch to fork itself into the background and exit the parent process when it had finished starting up, that would be better
<heno> right I see
<Hobbsee> tfheen: right.  people like Kamion do that?  :P
<tfheen> Kamion: can you reject gomoku.app_1.2.7-7ubuntu1 for Hobbsee?
<Keybuk> seb128: basically it's a complicated patch in the middle of the wpa supplicant driver selection
<Kamion> Hobbsee: rejected
<Hobbsee> Kamion: thanks very much
<Keybuk> cf. the mailing list, other bugs, etc.
<Kamion> Hobbsee: however edgy-changes will remain confusing
<Keybuk> I've also said I'm not happy with the request to update NM to the latest version
<Kamion> Hobbsee: you might like to follow up to some appropriate list saying that it got rejected
* Hobbsee notes that if she's getting signing declined due to getting her passphrase wrong repeatedly, she shouldnt be trying to upload things
<sivang> malone #65433
<Ubugtu> Malone bug 65433 in gcc-4.1 "[UNMETDEPS]  gcc-4.1 has unmet dependencies" [Undecided,Confirmed]  http://launchpad.net/bugs/65433
<seb128> Keybuk: I'm not arguing we should use it, I was looking at n-m bugs and that one is high importance with a patch and comment saying it would be nice to have for edgy and no objection, so I figured I would ask :)
<Hobbsee> Kamion: i did on the bug report.
<Kamion> ok, but there are a lot of bug reports :-)
<Kamion> I'd reply to the edgy-changes mail and direct the reply to ubuntu-devel
<Kamion> for clarification
<sivang> doko: mass filing of bugs for unmetdeps, this must be a mistake, sorry
<dholbach> sivang: did you check all the binary packages of gcc-4.1 if they are installable?
<elmo> sivang: you know we have a britney instance right?
<elmo> trying to replicate britney as a small shell script doesn't strike me as the best move ever
<sivang> elmo: I used a dholbach's script...
<sivang> dholbach: checking
<sivang> elmo: it served us well in previous times, I might have done someting wrong operating it, hopefully not..
<Hobbsee> Kamion: good idea.  however, i'm not going to do that tonigth, and make a fool of myself over two things :P
<Keybuk> seb128: tbh, I've been largely ignoring n-m this cycle
<Kamion> elmo: we don't/can't run britney on universe - last time I tried the runtime exceeded six hours before I gave up
<elmo> Kamion: ah, this was a package in main, so I assumed that's what this was about
<Kamion> sivang: oh, yeah, definitely don't run dholbach's script over main, there's no point
<elmo> Kamion: it might be worth trying again sometime on jackass - it's pretty much idle these days, and even if it took 12 hours, it might be better than apt-cache output hackery
<elmo> but *shrug*
<dholbach> the list of packages he fed into it was largely just looking at        apt-cache -i unmet
<Kamion> elmo: mm, worth a try I guess
<Kamion> I'll have a look once we're in RC freeze and uploads have settled
<sivang> Kamion: I overlooked the fact that it didn't exclude main, but all in all I think it's only gcc that has been filed as unmetdep
<sivang> Kamion: (I went through 99% of the packages before it filed the bugs, I would have noticed if they all seemed mainish)
<iwj> tfheen: Aye, sorry.  I have set the bug to Fix Released.  Although, I haven't tested it.
<Kamion> heno: ok, orca startup business done in my bzr branch, I think; should happen automatically if access=v3 is in /proc/cmdline
<bddebian> Howdy
<heno> Kamion: cool! thanks
<dholbach> heno: after the mid-air collision with seb128, finally uploaded.
<heno> dholbach: great! I know it's a popular application these days ;)
<heno> easy to collide
<dholbach> hehe :-)
* dholbach hugs heno
<azeem> so ubiquity tries to wget something but I'm behind a proxy, so it hangs at "configuring apt", can I just kill the wget or is there a recommended way?
<Kamion> fix your proxy to reject the request rather than just dropping it on the floor
<azeem> hmpf :)
<Kamion> but yes, killing the wget, apt methods, etc. is about the best you can do
<azeem> thanks
<Kamion> may take a few goes until it sorts its life out
<Kamion> it will time out eventually by itself
<azeem> does it take gnome's proxy settings?
<Kamion> but apt's timeouts are still rather too long and it doesn't realise that it timed out on a given host before
<Kamion> doesn't GNOME basically just set http_proxy for all its subprocesses?
<Kamion> IIRC yes, and last time I tested that IIRC it worked
<azeem> oh, I didn't know.  I'll try with gnome-network-properties
<azeem> ah, it timed out
<Kamion> yes, I set a proxy in GNOME, started a terminal, and http_proxy was set appropriately in the environment
<Kamion> so that should work fine
<azeem> now that you mention it, I wondered why http_proxy was being set on my notebook all the time the other day.   I never noticed this before, must be something newish, maybe
<azeem> but a nice feature
<Kamion> I last tried it quite a while ago; could be newish when measured in years, I guess :)
<doko> <doko> pitti, tkamppeter: gutenprint still installs the symlink in /usr/share/cups/model. Is this really correct? cups will see the entries twice?
<pitti> doko: doesn't matter any more, the /usr/share/ppd/transitional symlink doesn't exist any more
<doko> pitti: but I do see the printer twice ...
<doko> $ ls -ld /usr/share/ppd/gutenprint
<doko> drwxr-xr-x 3 root root 16 2006-08-31 22:27 /usr/share/ppd/gutenprint
<pitti> that looks right
<doko> $ ls -ld /usr/share/cups/model/g*
<doko> lrwxrwxrwx 1 root root 20 2006-08-31 22:18 /usr/share/cups/model/gutenprint -> ../../ppd/gutenprint
<pitti> /usr/share/cups/model is ignored by cups now
<pitti> doko: maybe you see the printer with two different possible drivers?
<doko> pitti: didn't we want to remove the duplicate entries?
<pitti> well, sure
<pitti> but I don't know what's causing them now
<doko> http://people.ubuntu.com/~doko/addprinter.png
* pitti summons tkamppeter 
<HiddenWolf> Is there a ubuntu.com webmaster around?
<pitti> HiddenWolf: see /msg
<BenC> jdong: ping
<jdong> BenC: pong
<BenC> jdong: There's no unusual dev flag for "max sectors". There's one for "GO_SLOW", maybe that will work for you
<jdong> BenC: that sounds about right :)
<jdong> hopefully it does the same thing :)
<BenC> it inserts delays after command phase
<JohnFlux_> Hey all
<JohnFlux_> To get cups + samba working so windows computers can print through samba, I wrote a script to download the needed cups drivers, extract them and install them
<JohnFlux_> as well as get the needed cups windows drivers and install them too
<JohnFlux_> I want to know where I can go from here
<JohnFlux_> I can make a .deb package with a bit of guidance
<JohnFlux_> if someone can say they'll check and add it to a repos
<HiddenWolf> JohnFlux_: I'd suggest checking out #ubuntu-motu
<heno> HiddenWolf: what do you need WRT ubuntu.com?
<heno> (I'm the old webmaster)
<HiddenWolf> heno: It's fixed now. 
<heno> ok, cool
<lfittl> infinity: could you take a look at https://launchpad.net/distros/ubuntu/+source/phpdoc/+bug/53710, dholbach meant I should talk to you about syncing it
<Ubugtu> Malone bug 53710 in phpdoc "Please re-sync with debian, there's a newer version" [Undecided,Unconfirmed]  
<mdz> tfheen: ping
<tfheen> mdz: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<mdz> tfheen: ha
<pitti> is that the new tfheenbot?
<mdz> apparently
<pitti> tfheen: pong
<pitti> did I confuse it? did I?
<pitti> 'ping stack underflow'?
<fabbione> ahah
<mdz> tfheen: I want to know where we stand on the RC checklist and what problems, if any, were found during the review
<gnomefreak> where do the xubuntu devs hang out?
<crimsun> gnomefreak: on the xubuntu-devel mailing list.
<gnomefreak> :( another mailing list
<BenC> mdz: Did you get any where further with your suspend bug?
<crimsun> gnomefreak: if you need a dev immediately, Gloubiboulga is present.
<gnomefreak> i tried pinging him in #xubuntu
<gnomefreak> is gnome-desktop-environment safe to remove?
<gnomefreak> oh and keep a working gnome
<agutierr> hello all. I have a question about preseeds. How I can set up universe, multiverse and restricted repositories in preseed ? I think apt-setup/section universe multiverse restricted but I dont know if its correct... Thanks!
<mdz> BenC: only what I told mjg59 last night
<mdz> BenC: it doesn't seem related to radeon
<BenC> mdz: Can you tell if there are more oopses before the one in the screen photo?
<mdz> BenC: I don't think I was able to scroll
<fdsd> hey guys, I am customizing the ubuntu livecd for my school, we are going to use it for data recovery, I have a shell script that starts on tty1, but its really annoying because dmesg messages keep interupting the script, how do I turn that off?
<mdz> yeah, just reproduced it and I can't scroll
<mdz> BenC: this time after the panic, I get an endless sequence of "atkbd.c: Spurious ACK on isa0060/serio0. ..."
<BenC> mdz: So there's possibly another oops before the one you captured?
<mdz> 2 messages every 500ms
<mdz> BenC: it's possible, but I don't know any way to check
<mdz> BenC: is there a panic=something which will make it stop at the first one?
<mdz> I guess panic=bignumber would do
<BenC> mdz: you could also set a higher console res (vga=791 or something) to see if there's more lines captured
<jdong_> whoa, cool, update-manager blocks shutdown
<jdong_> of course not admitting that I was being a complete moron trying to shut down with an upgrade process running ;-)
<pef> hello
<mdz> Kamion: why are we using this horrible console font btw?
<mdz> BenC: tried a higher res mode; the console gets corrupted when it panics
<BenC> shitty
<jdong_> and why doesn't that horrible font on my dist-upgraded boxes
<jdong_> (NOT THAT I WANT IT OR ANYTHING) :)
<pygi> sivang, ping?
<lmanul> hey guys, I'm trying to enhance the services-admin dialog a bit, and I'm looking for a way to figure out whether a given daemon is running or not. I saw there was a pretty clever infrastructure with all the /etc/init.d scripts, and start-stop-daemon, etc., but is there a simple way to do that?
<Kamion> mdz: oh, I meant to switch it back to Fixed
<Kamion> or VGA or something
<Kamion> mdz: it's supposed to reduce eyestrain, but I'm not entirely convinced
<mdz> Kamion: please change it back pre-freeze
<Kamion> will do
<mdz> I think it's hideous
<Kamion> that makes two more things to do pre-freeze, since I just cleared out one of them
<mdz> BenC: any other ideas?
<Kamion> no, three - have to refresh d-i and ubiquity tomorrow morning
<BenC> mdz: what's the bug number again?
<Kamion> mdz: I'm not going to attempt to fix it for upgraded systems, I'm afraid - IMO trying to do that will be fragile at best, given that different fonts are needed for different scripts
<Kamion> people running edgy can edit /etc/default/console-setup and change Terminus to VGA
<mdz> Kamion: that needs to be in the release notes for folks who installed beta
<Kamion> mkay
<Kamion> I'd like to fix bug 63915, but I'm not quite sure of the correct fix
<Ubugtu> Malone bug 63915 in console-setup "[Edgy Beta]  "Japan" keyboard layout is actually "U.S. English"" [Medium,Confirmed]  http://launchpad.net/bugs/63915
<Kamion> I'll hold off on an upload until I've had a bit more of a chance to investigate tonight
<Kamion> but first, food
<BenC> mdz: Without having the machine and doing some debug, I can't say for sure what the problem is
<BenC> mdz: It seems the timer list is corrupt, which would suggest some part of the system is referencing it after it is removed
<BenC> (after a timer is removed)
<BenC> mdz: Can you get me the stack trace from where the snd modules are removed, it may be easier to grok
<BenC> mdz: My fear is that the stack trace you captured is several oopses into the problem, and that what I'm looking at is just a symptom and not the real problem
<mdz> BenC: panic=300 didn't seem to help; I got the same info on the screen
<BenC> well, the oopses aren't "panic"s so it wouldn't stop the first one from happening
<BenC> you could install the kdump kernel, and we can set it up to drop to a shell in initramfs on the first oops
<mdz> I can dot hat
<mdz> do that
<mdz> if it's only an oops, shouldn't it be logged?
<BenC> it would if it didn't cause a panic shortly after
<BenC> I'm thinking that most likely a module is being unloaded that isn't cleaning up correctly
<BenC> if one module corrupts the timer list, than you would see things like this where a later timer would show the problem
<mdz> oh, I see
<BenC> cascade() basically bubbles up the timer list
<mdz> BenC: do you think it's related to the sound driver, or is that a red herring?
<BenC> mdz: Can you get me a diff of lsmod in single user and full boot?
<mdz> yep
<BenC> mdz: I think it's a red herring
<BenC> single user suspends/resumes without problem, right?
<mdz> BenC: that was my impression, though it seems to be less reproducible than I originally thought
<mdz> usually 3-4 tries is enough to get it to happen in multiuser
<mdz> but I did that many in single-user without a problem
<mdz> going to try a few more times ot be sure
<mdz> I wonder if acpi-support is unloading any modules
<mdz> BenC: one interesting difference is that acpid isn't running in single-user
<mdz> BenC: ok, I'm about as confident as I can get that this isn't reproducible in single-user
<mdz> it also suspends quite a bit faster in single-user
<mdz> I'll get that lsmod diff
<tfheen> mdz: we're at 39 RC bugs, 9 of those are fix committed, 3 are artwork where fschoep has promised me those by 10:00 UTC tomorrow, 4 or 5 which are desktop team bugs which seb128 said would be fixed by tomorrow.  We seem to have a couple of python/apt/dist-upgrader problems which I'm not sure what the state of are and a couple of stragglers like 65063, 64909 and 64122
<seb128> tfheen: I've 3 on my list
<mdz> tfheen: thanks...how about package inconsistencies, CD sizes, livefs builds, etc.?
<pygi> hello neuralis 
<tfheen> mdz: package inconsistencies seems good; there's ndiswrapper-utils on ppc and a couple of gcc-3.3 bugs on sparc (gcc-3.3 is supported mainly for libstdc++5)
<seb128> tfheen: there is only one of those 3 desktop that needs to be fixed and it's not really complicated, I'm waiting for upstream to get a fix, if they don't I'll revert the few liner commit that created the issue
<mdz> BenC: http://librarian.launchpad.net/4792360/lsmod-diff.txt
<tfheen> mdz: livefs-es are happy now with fresh winfoss (which caused a bit of a problem due to a 403 when downloading those).  No oversized as of now, the dapper upgrade of drescher and per-arch overrides helped a bunch, so did the removal of the initrd from the livefs, it seems.
<tfheen> seb128: goodie.
<mdz> tfheen: why is ndiswrapper-utils even built on ppc?  seems unnecessary
<tfheen> mdz: yeah, that occured to me too.  I can't see why it'd be useful
<mdz> tfheen: maybe somebody has a plan to use qemu to run NDIS drivers :-P
<mdz> tfheen: drescher was upgraded to dapper? eek
<tfheen> if so, they'll probably use the i386 ndis packages, I'd imagine.
<tfheen> yes, last weekend.
<mdz> I thought we were just upgrading apt-ftparchive
<tfheen> I think it was a full upgrade, at least.
<mdz> it's supposed to have edgy apt-ftparchive on it now; has that helped cron.daily runtime?
<tfheen> I think so, but I don't have any exact numbers.
<tfheen> (I don't have access to drescher, so I can't even grep the logs)
<seb128> BenC: any other linux upload planned for edgy? gicmo (who is one of the cool GNOME guys) would appreciate having the trivial change from bug #64433 with edgy if possible :) It's after freeze so probably for next cycle I point it in case though
<Ubugtu> Malone bug 64433 in linux-source-2.6.17 "Use correct SATA driver for (some) MacPros" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64433
<mdz> oh
<mdz> most recent one seems to have taken 24 minutes
<mdz> which would be a substantial improvement
<tfheen> mdz: there are a couple of kernel bugs as well; BenC has said he's on top of those, but we need to discuss what the different freezes mean in SF.  I thought kernelfreeze was "kernel is utterly frozen", not "kernel ABI is frozen".  BenC seems to have understood the latter and I'm not sure what's the intention
<mdz> tfheen: kernel freeze is meant to be "kernel updates require review and approval"
<tfheen> mdz: oh, and it would have been nice if we had a proper artworkfreeze too.  I lumped it together with the general RC freeze tomorrow.
<tfheen> mdz: kernel freeze> I suspect I should tell BenC that then. :-)
<mdz> tfheen: we had one; it's just that sabdfl disregarded it (again)
<tfheen> mdz: is there anything we can do to make that not happen again?
<mdz> tfheen: by definition, no
<tfheen> tie him up in a room with no connectivity for the last month of the release cycle?
<tfheen> might work once, but probably not the second time around..
<mdz> tfheen: my understanding is that we're to revert to the dapper artwork unless something magical happens
<mdz> tfheen: in which case it seems wise to go ahead and do that
<tfheen> mdz: ok.  dholbach is handling that with fschoep.
<dholbach> tfheen: Ok, I was waiting on fschoep's "something magical has happened" some minutes before the freeze
<shining> mdz: do you know if something happened for firefox? there has been some branding changes in last package
<dholbach> I didn't fancy reverting it, just to change something in the magical case
<mdz> shining: discussions are ongoing
<mdz> those changes are unrelated; they're just preserving the status quo
<shining> mdz: ah ok
<shining> is it ok to ask here about this stuff? or is there a better place to track if the discussions lead to something
<BenC> tfheen, mdz: the ABI change thing was mainly that I wont accept any change that affects ABI, and changes that don't have to be pretty important and trivial
<mdz> BenC: I'm concerned about the notion of merging new upstream code at this point, as I mailed about just now
<BenC> trivial patches that is
<BenC> mdz: The new upstream merge was 99% security fixes
<BenC> I reviewed the changes between .11 and .13..the diff was really trivial, non-ABI changing, and addressed most of the CVE's that pitti sent me
<BenC> the only thing major was sky2, and it's disabled anyway
<mdz> BenC: the changelog needs to say that; new upstreams without clearly reviewed changes make the release team cry
<BenC> mdz: The modules that are new in the diff, can you try unloading some of them after a full boot, like in groups of 5, to see if the oops goes away?
<BenC> mdz: Starting with the ones that are >0 ref count
<mdz> BenC: ok
<tfheen> BenC: I'd actually liked if you sent it to the release team even so; I just saw an upload and hadn't gotten any explanation for it.
<BenC> mdz: True, I guess just doing "update from .11 to .13" is a little scary :)
<BenC> tfheen: Ok, I wasn't aware of the process for new uploads...I don't forsee any further kernel updates, unless I can fix mdz's bug :)
<BenC> tfheen: If there are any other uploads, I consult first about the reasons why
<tfheen> BenC: thanks.
<mdz> starting tomorrow they'll require manual approval anyway
<tfheen> BenC: you had an upload pending this morning, iirc, was that uploaded?
<BenC> right, that's why I didn't think today's needed any approval
<tfheen> the kernel's special. :-)
<BenC> tfheen: the 2.6.17-10.31 was the one
<BenC> it's in the process of building now
<tfheen> ok.
<tfheen> if you'd be so kind as to mark bugs that are fixed by that upload as at least fix committed, but preferably fix released I'd be very glad.
<mdz> BenC: I can unload speedstep_centrino; something has a reference to it and I don't know what
<BenC> mdz: Probably userspace power management
<BenC> maybe an init script will disable it
<mdz> BenC: no, I stopped powernowd and scaling_governor=performance now
<BenC> powernowd
<BenC> hmm
<BenC> ok, skip that one for now then
<BenC> we can try blacklisting it later or something
<kristog> night
<mdz> BenC: it blows up even when I comment out the meat of /etc/acpi/sleep.sh (i.e. it doesn't even start to try to suspend)
<mdz> so I'll try to isolate which step in the script jungle is causing it
<BenC> ok
<mdz> BenC: it unloads *_ircc, *_ircc2, e1000, ipw2200, switches the console, does vbetool stuff, then crashes while shutting down alsa
<BenC> can you add -x to the alsa init script?
<mdz> BenC: did that, rebooting to get the output
<mdz> BenC: alsactl followed by sleep 1 is as far as it got
<mdz> then there is a bunch of garbage in the log
<mdz> BenC: should I try disabling any of the above steps I listed?
<BenC> can you try running /etc/init.d/alsa-utils stop before suspend and see where sleep.sh gets then?
<mdz> I wonder why it has a sleep in there
<mdz> BenC: alsa-utils stop will try to do the same things even if it's already been run
<mdz> I can disable it
<BenC> ok
<mdz> but since unloading the sound drivers didn't help, I don't think that will either
<mdz> BenC: if I disable the unloading of e1000 and ipw2200, it doesn't seem to panic
<BenC> mdz: Hoping that the getting alsa out of the way will make the oops more relavant
<BenC> hmm
<BenC> mdz: Can you narrow it down to one or the other?
<mdz> yep
<BenC> I bet it's ipw2200
<BenC> and I bet I have it fixed already
<BenC> like just now :)
<lifeless> BenC: is it safe to try running the edgy kernel on a dapper box ?
<BenC> lifeless: Should be, there's no deps, and it should operate fine
<lifeless> BenC: sweet. - The drop-cache patch sounds very interesting for bzr performance testing.
<mdz> BenC: I've whitelisted e1000 (so only ipw2200 gets unloaded) and it isn't crashing on me
<mdz> imlpying that it's e1000
<BenC>     [PATCH]  - quiesce ipw2200 on shutdown
<BenC> 
<BenC>     This seems to be needed for some Toshibas. We carried it in 2.6.12.
<BenC> that patch got lost recently
<BenC> I cherry-picked it
<mdz> swapped them, and boom
<mdz> so it's e1000
<BenC> hmm
<mdz> can you get me an e1000 with that patch?
<keescook> seb128: ping (re: bug 14392)
<Ubugtu> Malone bug 14392 in gnome-system-tools "[network-admin]  WEP key stored in world-readable /etc/network/interfaces" [Undecided,Unconfirmed]  http://launchpad.net/bugs/14392
<BenC> mdz: That isn't an e1000 problem
<fdsd> hey guys, I am customizing the ubuntu livecd for my school, we are going to use it for data recovery, I have a shell script that starts on tty1, but its really annoying because dmesg messages keep interupting the script, how do I turn that off?
<mdz> BenC: oh, right
<seb128> keescook: pong
<BenC> mdz: When you tested e1000, did you test it on a fresh boot with out ipw2200 being loaded?
<keescook> seb128: I just put a note onto that bug... I think if you move the key's index up one position, you'll stop any possible race.
<BenC> mdz: Are e1000 and ipw2000 sharing an IRQ?
<seb128> keescook: "race"? is that multi-threaded?
<keescook> from the looks of it, it'll update the key first, then chmod the file.
<keescook> (i.e. there's a race between those two moments to read the key)
<seb128> keescook: right, do you expect somebody will read the will during the split instant between them? ;)
<seb128> s/will/file
<lifeless> seb128: such attacks have happened before
<keescook> seb128: well, it's very unlikely, but fixing this race is easy.  :)
<seb128> right, will fix it, thank you for pointing it
<mdz> BenC: yes
<keescook> seb128: no problem.  :)  thanks!
<mdz>  11:      11448          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4, yenta, ipw2200, eth0
<mdz> BenC: eth0 is e1000 (why isn't /proc/interrupts consistent about module name vs. interface name?)
<mdz> why are all of my IRQs XT-PIC anyway?
<BenC> mdz: all depends on how the irq is requested...like for any sata and pata drivers, they all say libata is the irq owner
<mdz> oh
<mdz> [17179569.184000]  Local APIC disabled by BIOS (or by default) -- you can enable 
<mdz> it with "lapic"
<fdsd> anyone have any idea?
<BenC> wow, diff between .17 and .19 e1000 is 300k
<fdsd> BenC, yeah ltrack has been making alot of updates to it
<mdz> fdsd: you could fix that by disabling the messages, or by running the script on a different tty
<fdsd> mdz, yeah I am looking to disable it, that has been my alternive to run it on tty2, but I need it on tty1
<fdsd> do I edit a config file?
<BenC> mdz: What kernel are you running, x86 -generic?
<mdz> BenC: 2.6.17-10-generic, yes
<mdz> _i386
<mdz> fdsd: who or what is ltrack?
<BenC> mdz: I want to get you a fixed ipw2200, just to see if it helps (I don't suspect it will, but how knows)
<fdsd> mdz, kernel developer
<fdsd> mdz, she is pretty cool
<fdsd> mdz, she works on alot of ppc stuff and intel nic stuff
<mdz> fdsd: I don't know who you are talking about
<lifeless> fdsd: what is her _name_ ?
<fdsd> lifeless, tina jones
<mdz> fdsd: I think you're thinking of someone else
<fdsd> do you guys know if its syslogd or klogd that gives the messages to tty1?
<fdsd> mdz, hmm i am pretty sure
<seb128> BenC: did you read my comment about #64433?
<BenC> fdsd: There's no "Tina" in the e1000 git-log
<BenC> Jeff Kirsher seems to be doing most of the work there
<BenC> mdz: people.u.c:~bcollins/ipw2200.ko
<BenC> mdz: Move that into /lib/modules/2.6.17-10-generic/kernel/drivers/net/wireless/
<BenC> mdz: Reboot, and let me know if it helps any
<brandon> mdz, ping , got a moment to chat with me and the core konversation guys for a sec ?
<mdz> brandon: I'm dealing with a serious kernel regression right now
<brandon> mdz, sure no problem
#ubuntu-devel 2006-10-12
<mdz> BenC: crashed immediately when I attempted to suspend
<mdz> without even a console switch, no output
<mdz> BenC: modprobe -r e1000  hangs instantly
<mdz> oh, no it doesn't
<mdz> it crashed the first time I tried in X, but has worked a few times on the console so far
<mdz> oh, the module was left unloaded
<mdz> BenC: ok, reproduced the same panic with that module
<BenC> mdz: ok, let me check into some of the e1000 logs
* jdong races buildd to getting the new kernel upload compiled
<jdong> thx, BenC... I'll test and see if GO_SLOW does the trick
<Kamion_> aaaaaaand now to wait for console-setup to build so that I can test this keymapper change to fix UK keymap detection so that I can test the corresponding cdebconf-keystep change so that I can upload the whole stack in reverse order
* Kamion_ does so love dependency chains
<infinity> Kamion: Are you in need of manual archive/buildd love to make your life easier?
<elmo> oh, what a coincidence, I was about to whine about that :)
<elmo> (getting keyboard prompts on a dapper -> edgy upgrade)
<Kamion> elmo: which is er kind of orthogonal to what I said?
<Kamion> infinity: no
<Kamion> build-deps plus overnight will take care of it
<Kamion> elmo: 'echo GET debian-installer/keymap | sudo debconf-communicate' please?
<elmo> kamion: 0
<Kamion> so why is that empty?
<Kamion> how was the original installation of that system done?
<elmo> this is mid upgrade - it was defaulting to US, so I answered UK twice and moved on
<Kamion> yeah, doesn't matter
<elmo> Kamion: um.  not actually sure.  it may be a sidegrade from Debian, it's my home desktop that pre-dates Ubuntu
<Kamion> Debian woody perhaps?
<Kamion> or before
<elmo> could be, yeah, I wouldn't have been running sid or etch, and it's the wrong timeframe for sarge
<infinity> Heck, I have an Ubuntu system that started as slink.
<Kamion> yeah, boot-floppies-era original installs are a known case that console-setup can't handle without asking questions right now
<elmo> Kamion: ah, ok, then
<Kamion> might be able to figure out how to snarf it from console-data/* questions in debconf
<Kamion> but those might well be wrong too
<elmo> oh, shiny I have an installer.log still
<Kamion> elmo: actually 'debconf-show console-data' in a bug report would be useful
<elmo> Mar 21 04:48:29 (none) user.info dbootstrap[83] : dbootstrap starting; built 2002.05.16-04:54+0000 for i386
<Kamion> (bug report on console-setup)
<Kamion> bing, boot-floppies
<Kamion> if debconf-show console-data doesn't say much useful, then never mind ...
<Kamion> the only other way to figure out the keymap from an installation of that vintage is to disassemble /etc/console/boottime.kmap.gz
<Kamion> which is approximately no fun at all
<elmo> it's 138 lines of stuff, including some hints as to the britishness of my keyboard
<Kamion> elmo: ok, sounds useful for a bug report then
<elmo> ok, let's see if I can file it before the upgrade takes out my browser ;-)
<Kamion> the many lines are just due to the super-weird layout of console-data's templates
<BenC> mdz: people.u.c:~bcollins/e1000.ko
<Kamion> can't guarantee to fix it for edgy though, it *is* a corner case
<BenC> mdz: Please move that to /lib/modules/`uname -r`/kernel/drivers/net/e1000/ and test it
<Kamion> also affects folks who installed using the debootstrap-in-a-chroot-and-fiddle method, though
<elmo> Kamion: sure
<Kamion> which I think is probably more common
<mdz> BenC: trying
<infinity> Kamion: That's my preferred method of installation on a few machines. :)
<Kamion> oh, btw, #ubuntu-installer is open for installer development and stuff
<Kamion> I created it ages ago but forgot to mention
<BenC> mdz: That's a backport of the 2.6.18 driver (ours is 2.6.18-rcX backport)
<BenC> mdz: We probably want that anyway, since it has a lot of support added for newer chipsets
<mdz> BenC: same result
<BenC> mdz: I'm not sure I even want to consider the 2.6.19-rc1 version
<mdz> BenC: can you send me the huge diff you generated earlier?
<BenC> mdz: the diff to get e1000 to 2.6.19-rc1?
<mdz> no
<mdz> Oct 11 14:31:44 <BenC>  wow, diff between .17 and .19 e1000 is 300k
<BenC> mdz: Yeah, I could, but it will take backporting to actually make it work
<mdz> BenC: will the 2.6.15 driver build for this kernel?
<mdz> maybe we can narrow down the change which introduced the regression
<BenC> let me revert to 2.6.17 stock and see if that works
<jdub> hey dudes, how goes edgy?
<BenC> mdz: New module, same location
<BenC> mdz: This is stock 2.6.17.13 code
<BenC> if this doesn't work, then I'll revert to 2.6.16 and see what we get there
<mdz> ok
<BenC> then we can bisect when we have a known working version
<BenC> mdz: Any luck
<BenC> ?
<mdz> BenC: with what?  the most recent e1000.ko you provided didn't seem to help
<mdz> jdub: manageable
<BenC> mdz: fa74227d3a2974804fc56a508d912021 <- that match the md5sum of the last one you used?
<mdz> d374350940aac7675f737efb79ad6d6f  2.6.17-10-generic/kernel/drivers/net/e1000/e1000.ko
<BenC> then there's a newer one :)
<mdz> BenC: same location?
<mdz> oh, I missed 'new module, same location'
<BenC> hehe
<_ion> I posted a comment to bug 33243; i'd really appreciate more information.
<Ubugtu> Malone bug 33243 in linux-restricted-modules-2.6.15 "tmpfs setup is unexpected" [Wishlist,Rejected]  http://launchpad.net/bugs/33243
<mdz> BenC: 4/4 successful suspends with that driver
<BenC> mdz: How long will you be on?
<mdz> 5/5
<mdz> BenC: ages
<infinity> _ion: We'd still have to use the tmpfs setup for livecds, which would get messier to implement if we had to do it differently for installed systems (since the livecd is really just an installed system)
<BenC> mdz: Ok, we need the 2.6.18 driver because of the intel support...I'll start pumping through git-bisect and giving you modules to test
<BenC> if we can fix this bug in the 2.6.18 driver, it will be ideal
<BenC> mdz: Unless you think that the updated driver just isn't important enough to worry about, in which case I'll just leave it as stock 2.6.17
<mdz> BenC: is there a place where I can browse the git log messages and diffs?
<mdz> BenC: it depends; if the fix is small and manageable, that would be preferable to swapping it out
<BenC> mdz: Best place is the www.kernel.org/git linux-2.6 repo
<cjfp> how do i get 'info autoconf' to work?
<BenC> the update I did in our tree was just a single patch to go from .17 to .18 version
<cjfp> i have manpages-dev installed, but it doesn't have info docs
<Kamion> cjfp: autoconf-doc
<cjfp> ah.
<mdz> BenC: there are a lot of trees there; which one do I want?
<cjfp> Kamion: this package doesn't exist for me...
<_ion> infinity: A simple "if running on livecd, use tmpfs" clause wouldn't be very difficult or messy, would it?
<cjfp> i'm running breezy
<mdz> BenC: so the driver which works for me is stock 2.6.17?
<Kamion> cjfp: looks like it isn't available theen, I'm afraid. However, the version of autoconf-doc in dapper is for the same upstream version, so you can probably just use that.
<Kamion> s/theen/then/
<cjfp> sorry, i don't understand
<Kamion> install autoconf-doc from dapper and be happy
<cjfp> so apt-get install -t dapper autoconf-doc?
<Kamion> #ubuntu for the details, please
<Kamion> might be better to fetch the individual .deb rather than messing with apt pinning though
<Kamion> (the lack of autoconf-doc in hoary and breezy is a bug, but not one that we can/will fix now)
<cjfp> i already asked about info docs on #ubuntu and they were no help, but ok
<Kamion> I'm sure #ubuntu can handle installing packages
<cjfp> ok, i will try to find the .deb
<cjfp> is there a development task or whatever those things are called?
<cjfp> so that i can just get useful development packages?
<azeem> "useful development packages" is rather broad I'm afraid
<cjfp> okay, how about so that when i type "info some-gnu-tool" it works?
<BenC> mdz: Right
<Kamion> cjfp: install the relevant -doc packages until it does; see packages.ubuntu.com for searching facilities. Please, this is really off-topic here and we are trying to prepare for RC freeze tomorroow
<Kamion> tomorrow
<cjfp> i'm sorry, i'll leave you in peace.  good luck.
<Kamion> thanks
<malix0> hi all can someone test this wit Firefox http://www.massimofidanza.it/firefox/
<HrdwrBoB> because.. you don't have firefox?
<HrdwrBoB> yes, the popup window remained in the background in current edgy bon echo
<BenC> mdz: test 1 is there: md5sum: 509d603dd73b9a2a0f38fcfe0c170346
<mdz> BenC: 2/2
<BenC> mdz: Ok
<mdz> BenC: I just unloaded the working module and loaded this one without rebooting; assume that's OK
<BenC> yeah, that should be fine
<mdz> eck
<mdz> try #4 panicked
<Viper550> Why don't you put in the actual Firefox logo? Debian won't do it, but we've "sorta broken free" of debian!
<HrdwrBoB> yes, it's  that simple.
<BenC> mdz: test 2: md5sum: 509d603dd73b9a2a0f38fcfe0c170346
<mdz> BenC: just to confirm, you saw my previous message about the panic and so we're bisecting in the right direction?
<BenC> mdz: Right
<mdz> ok
<BenC> mdz: between 2.6.17.13(known good) stock and 2.6.18(known bad)
<mdz> BenC: hmm, I get 736fd91125932795548aee05c0b76ea6
<BenC> ah, that's right
<BenC> not sure how I pasted the wrong one
<BenC> probably pasted the git sha :)
<mdz> I should blacklist it so that I don't need to reboot twice when it panics
<BenC> mdz: Does that last one work?
<mdz> BenC: 3x so far
<mdz> it sometimes takes 4-5
<BenC> mdz: test 3: md5sum: 2788929c3de1db918b7278a7eb6d7867
<mdz> survived 5x
<mdz> 2788929c3de1db918b7278a7eb6d7867 got it
<AlinuxOS> mdz, could you please tell me when exactly debian-installer transaltion is no more accepted ?
<AlinuxOS> is it tonight or tommorow morning ?
<mdz> BenC: 5/5 OK
<mdz> AlinuxOS: NonLanguagePackTranslationDeadline
<AlinuxOS> yes it's 12
<AlinuxOS> I'm reviewing debian-installer right now.
<mdz> AlinuxOS: they will be accepted between when Kamion is awake and when the RC freeze begins
<Kamion> AlinuxOS: was the extensive conversation earlier where we went through this not good enough for you?
<AlinuxOS> so not now :)
<mdz> possibly later if he needs to do a d-i upload for other reasons
<AlinuxOS> tommorow morning :)
<AlinuxOS> Kamion, just would like to know if deadline is near :)
<mdz> it is
<mdz> it has been on the release schedule for 6 months now
<AlinuxOS> cause I'm reviewing transaltions right now.
<Kamion> AlinuxOS: please stop constantly bugging us about this. the only thing stopping me from excluding the Georgian translation right now is that it would be unethical
<Kamion> we had this conversation this morning; there is no need to go over it all again now
<BenC> mdz: test 4: md5sum: 1b8fc0e0ca307ad7c1eaf6a0a0c621d2
<BenC> mdz: This test will narrow it down to 4 commits
<mdz> BenC: hmmm
<mdz> BenC: after 5 successful suspend/resume cycles I just got a crash when trying to copy down the new one
<mdz> maybe an unrelated bug in that range somewhere
<BenC> yeah, probably something already fixed
<AlinuxOS> I've only gently asked about a current situation... to be sure... no comments about excluding Georgian translations please! It's enough what Russian government is doing(right now) with our citizens in Russia.
<Kamion> AlinuxOS: imagine how it would be for us if every translator came and asked us how closely they could push the deadline
<mdz> BenC: argh yeah, that driver is borked even if I don't try to suspend with it
<Kamion> it would be absolutely intolerable
<BenC> mdz: Number 3 or 4?
<mdz> BenC: 3
<mdz> need to boot an old kernel to get 4
<BenC> mdz: ok
<AlinuxOS> I'm inexperienced and I know this..., but consider that I'm alone who is working on everything.
<mdz> AlinuxOS: I've talked with you before about waiting until the last minute; I thought we understood each other now
<Kamion> AlinuxOS: lots of people are inexperienced, but most of them learn by watching quietly rather than coming up and poking the development team with sticks twice a day
<Kamion> and I'll thank you not to compare us to government repression
<infinity> AlinuxOS: As I said last night, if you don't get it done on time, you don't get it done on time.  Such is life.
<infinity> AlinuxOS: As a member of the release team, I'm not allowed to delay the world for things I couldn't deliver on time, and no one else gets that privilege either.  There's always edgy+1 if you can't get us your translations now.
<infinity> AlinuxOS: (And, yes, the deadline may as well be "now", since it's "anytime between now and when we freeze hard", which is "soon")
<Kamion> annoying the people who you need to get your translations in is just about the least productive strategy I can imagine
<AlinuxOS> Kamion, "the only thing stopping me from excluding the Georgian translation right now is that it would be unethical". I'm not comparing you, don't worry... but you are very severe, with me.
<Kamion> AlinuxOS: you're hassling the people you need to help you even when you've been told to stop. Do you not think this is behaviour that needs negative reinforcement?
<Kamion> s/told/asked nicely/ actually
<AlinuxOS> Kamion, infinity transaltions are ready :) I just wanted to know some more infos...that's all.
<mdz> BenC: 4/4 with #4
<BenC> mdz: Ok, getting down to a culprit
<AlinuxOS> Kamion, I'm not hassling no one here, just some further questions. If something goes wrong with me is that I have no idea howto make a font related packages... so I need help. And I really need help, because some months ago there was nothing for Georgian (I mean font,fontconfig,transaltions,console fonts..etc..).
<AlinuxOS> mjg59, ping
<infinity> Man, I love how I'm still processing queue/new within hours of a freeze.
<BenC> mdz: Bad news, I was going the wrong direction with the commits (this is a manual bisect so I don't have to worry about ABI differences between ubuntu and stock kernel)
<infinity> Tres speciale.
<BenC> mdz: 5: 1c268c8ff18c9a3cf6ffffa3fdb4c1f8
<elmo> RAH
<elmo> damn it, edgy still doesn't bring up network when /var is on a separate partition
<mdz> BenC: fails
<mdz> elmo: still? you noticed this before?
<elmo> mdz: yes, it was broken in dapper, but I upgraded far too late for anything to be done about it
<BenC> mdz: 6: a9f2bf93027f6e6dff44a7ea276940cf
<mdz> elmo: is it filed?
<mdz> BenC: failed, but slightly different symptoms
<BenC> mdz: slightly as in "probably unrelated" or as in "same thing, just different enough to notice" ?
<elmo> mdz: the original dapper one?  no, keybuk debugged and diagnosed it for me, and hand wavingly promised me it would be fixed by new shiny edgy.  I never filed a bug, but I should have :(
<elmo> I'll file one now though...
<mdz> elmo: send me the bug number please
<BenC> mdz: I'll mark it "probably bad" and move on
<mdz> BenC: as in "probably unrelated"
<mdz> BenC: it blows up during boot as well
<Kamion> elmo: do /var/lock and /var/run exist on the underlying root filesystem?
<Kamion> (just checking, as that's a requirement for some things - should be handled by the upgrade to dapper or so though)
<mdz> BenC: does git bisect let you say that the test result was indeterminate, so that it picks another in the same range?
<infinity> CDBS makes me weep.
<infinity> lp_archive@drescher:~/foo/meta-telepathy-1$ cat debian/rules 
<infinity> #!/usr/bin/make -f
<infinity> include /usr/share/cdbs/1/rules/buildcore.mk
<infinity> include /usr/share/cdbs/1/rules/debhelper.mk
<BenC> mdz: 7: 6376cf2a1bc886cfb99fa6d6a2ee44b6
<BenC> mdz: I'm not using git-bisect, I just spit out a list of the 53 commits between the known working and known bad
<mdz> booting with 7
<mdz> oh, right
<BenC> mdz: I dropped just one commit from 6 closer to "last known good"
<mdz> BenC: 6376cf2a1bc886cfb99fa6d6a2ee44b6 fails
<mdz> (in the usual way)
<BenC> cool, that makes 6 irrelevant
<BenC> mdz: 8: 5136ea9c374d445682448877552a745f
<infinity> Lookie there, an empty new queue.  I wonder how long that will last...
* mjg59 uploads stuff to annoy infinity
* BenC uploads linux-source-2.6.19 for shits and giggles
<infinity> Ngh.
<zul> heh
<BenC> infinity: So, is edgy+1 chroots and buildd's ready yet? ;)
<infinity> BenC: Is that actually ready to go in the first day or two of edgy+1 along with the toolchain bootstrap?
<mdz> BenC: 5136ea9c374d445682448877552a745f fails with the usual panic
<infinity> BenC: The chroots are ready, yeah.
<BenC> infinity: Yep, I have it building and booting on x86, x86_64, powerpc and sparc already
<infinity> BenC: Sex.
<infinity> BenC: We should have an hppa toolchain from the get-go too, so feel free to make it boot there too.
<infinity> (Yay, working glibc)
<BenC> infinity: Not sure about boot, I can't even get edgy booting with 2.6.17...but I can get it building
<infinity> Well, building is a start.
<infinity> I can help with making it boot once the edgy+1/hppa toolchain is bootstrapped.
<infinity> (And we get to rebuild half the archive, because hppa's glibc is introducing an ABI break)
<infinity> Woo-freaking-hoo.
<mdz> infinity: how is the rebuild test going?
<infinity> mdz: Slowly, but it's going.
<mdz> speaking of mass rebuilds
<infinity> (as of this morning)
<mdz> infinity: what's the cause of the slowness?
<BenC> mdz: 9: 364fe620711f36d4de99c120921e17fb
<infinity> The "as of this morning" bit, along with the "only one machine per arch" bit.
<AlinuxOS> Good night everyone and good work!
<BenC> infinity: If you need libc-kernel-dev prior to upload, let me know
<AlinuxOS> Kamion, sorry again for disturbing. (anyway debian-installer and help are ready).
<mdz> BenC: fail
<Kamion> AlinuxOS: thanks
<psusi> so is there any way to get a newer version of git-core backported to dapper?  the current one is no longer compatible with kernel.org
<mjg59> psusi: Since when?
<mjg59> Oh, sorry, dapper
<psusi> since the 10th I think
<mdz> psusi: yes, the process is at http://wiki.ubuntu.com/StableReleaseUpdates
<BenC> mdz: Ok, that leaves us a culprit, but let's rebuild the known good that right next to the bad one to be sure we did nothing wrong
<psusi> ahh, cool... I'll have to read that if/when I get X working again
<BenC> mdz: 10 (same as first bisect module): 509d603dd73b9a2a0f38fcfe0c170346
<BenC> commit 9a53a2029885e0088e9149679215b95d04deb57b
<BenC> Author: Auke Kok <auke-jan.h.kok@intel.com>
<BenC>     e1000: add smart power down code
<BenC> that appears to be the problem, sounds right too
<psusi> hrm... got it up in lynx... looks like git no longer being compatible doesn't qualify for backporting
<Kamion> smurf: FYI, uploaded keymapper 0.5.3-7 to unstable, with all your changes plus a few more to make the UK keymap detectable properly
<Kamion> smurf: (the map_yes/map_no generation code wasn't taking alt-ness into account)
<mdz> BenC: that one breaks in a  different way
<BenC> mdz: Ok, give me a sec
<infinity> BenC: At this point, I'll assume we can bootstrap glibc and gcc without new kernel headers (can't see why not), but we'll see if jbailey or doko think otherwise.
<BenC> mdz: Does it break on suspend/resume or just general?
<mdz> BenC: yes
<BenC> I'll assume that means "yes, it breaks on suspend"
<mdz> that means "yes, it broke".  I only tried it once
<mdz> and that was a suspend test
<BenC> that's odd, because that's the same as the first one we tried that you said worked
<mdz> but it broke way earlier than any other
<mdz> no, look back
<mdz> <mdz> BenC: hmmm
<mdz>  BenC: after 5 successful suspend/resume cycles I just got a crash when trying to copy down the new one
<mdz> and then it shit the bed during the next reboot, so I had to go to another kernel to download a new one
<mdz> so it broke outside of a suspend/resume context as well before
<mdz> I think that revision is just hosed
<BenC> BenC mdz: test 1 is there: md5sum: 509d603dd73b9a2a0f38fcfe0c170346
<BenC> mdz BenC: 2/2
<BenC> same md5sum
<mdz> BenC: yes, keep reading though
<mdz> BenC: oh, I'm confused by where you pasted the wrong md5sum
<mdz> BenC: can we go one revision earlier?
<BenC> mdz: Yeah, hold a sec
<BenC> mdz: 11: 6fdfef162426766611b1f640138e4720f56e45f8
<mdz> BenC: failed first try
<mdz> when suspending
<Snake> Can a dev tell me what ubuntu plans to do with this firefox chaos?
<mdz> Snake: no, not until it's been discussed and agreed with mozilla
<BenC> mdz: 12: 0b70b852c27d9535d666a18164c45f9d
<mdz> that dialog is still in progress
* Snake nods
<mdz> BenC: that one looks good so far, 4x
<mdz> 5x
<mdz> 7x
<mdz> BenC: I can't seem to break 0b70b852c27d9535d666a18164c45f9d
<BenC> mdz: That's just one commit above 2.6.17.13 stock (only one we know was perfect)
<BenC> we'll go from there
<mdz> BenC: one more, and then I need to run to the store
<BenC> mdz: 13: 736fd91125932795548aee05c0b76ea6
<BenC> mdz: ok, after this just ping me when you are ready to do some more
<mdz> BenC: 736fd91125932795548aee05c0b76ea6 seems solid
<BenC> mdz: Ok
<mdz> BenC: how many more do you think?
<mdz> these go pretty fast when it works
<mdz> slow when it doesn't
<BenC> mdz: 11 commits between good/bad, so splitting, probably 5-6
<mdz> should be closer to 3
<mdz> let's try to finish it before I go
<BenC> mdz: 14: f1fc3b0dc86d4b1064666533262eb0df
<mdz> f1fc3b0dc86d4b1064666533262eb0df looks good
<mdz> BenC: ^
<BenC> mdz: 15: e494359e9a260f18d5eb18a92e5a769a
<Kamion> mdz: mind if I upload *-meta to remove the *-live metapackages? they're useless now that Adam's switched livefs.sh to using tasks
<mdz> BenC: e494359e9a260f18d5eb18a92e5a769a looks good
<mdz> Kamion: let me think about that one for a minute
<mdz> Kamion: should be safe considering that no one should have that installed
<Kamion> and if they do, it'll have been changing wildly on them in unhelpful ways
<mdz> Kamion: yeah, ok
<Kamion> like insisting that they suddenly must have Estonian language support or something
<mdz> it has occurred to me that with the combination of metapackages and autoremove, the metapackages we have must live forever :-)
<mdz> the ones which end up on an installed system I mean
<Kamion> seems suboptimal :)
<Kamion> we should ponder that
<BenC> mdz: 16: 9632301e6aa5be39f93b5b849c0462cc
<BenC> mdz: If this one is good, it's the last, if not, then one more
<BenC> I'm hoping it's bad, because the commit it points to doesn't look like it could cause a problem
<mdz> BenC: took a bunch of attempts, but I panicked it
<BenC> mdz: 17: ac6b764fe8f6a8c42d9741cb633bcc5a
<BenC> last one hopefully
<mdz> rebooting
<Kamion> mdz: are we moving avahi-daemon to desktop for all derivatives?
<Kamion> I'm just doing a full set of seed merges while I'm here
<mdz> Kamion: at least the kde and gnome ones
<mdz> I don't know whether xubuntu has a knob to enable it
<mdz> if not, they might want to leave it out
<Kamion> the daemon ships disabled until enabled by UI, right?
<mdz> yes
<Kamion> good good
<Lathiat> yeh, thats causing no end of bug reports tho
<mdz> despite unhelpful blog entries
<Lathiat> im wondering if we can do something liek print an error message in the init script if its run interactively, or something
<Kamion> Lathiat: that's not unprecedented; e.g. see pcmciautils
<Kamion> the run_by_init stuff
<mdz> BenC: panicked on me, but slightly different
<mdz> flashing caps lock and nothing on screen
* Lathiat can't see that?
<Kamion> Lathiat: /etc/init.d/pcmciautils
<Lathiat> yeh but i cant see a 'run_by_init' in there?
<Lathiat> oh this is dapper tho
<Lathiat> is this an edgy thing?
<Lathiat> ah, it is
<Lathiat> that said, this would only help 'half' the cases, theres two problems that come up
<Lathiat> 1) I installed avahi-daemon in synaptic and avahi doesn't work and
<Lathiat> 2) I ran /etc/init.d/avahi-daemon start and it doesnt work
<Lathiat> i guess that solves the latter but not the former
<Kamion> ok, avahi-daemon's tiny, even edubuntu can cope with this
<Kamion> Lathiat: solving the latter seems worthwhile anyway - people suffering from the former might have people with general Unix knowledge try to help them who would be confused by the latter
* Lathiat nods
<mdz> BenC: second attempt, freezes hard while X is still displayed and the sleep light flashing
<mdz> I need to run, back in <30
<BenC> mdz: Ok, that should do it, let me review these commits
<BenC> thanks
<mdz> BenC: back
<jdong> BenC: sadly, GO_SLOW doesn't do the trick :(
<jdong> BenC: and the linux-usb folks seem to be against doing max_sectors stuff from the kernel side
<jdong> rather, they say it should be done via hal/udev scripts in userland
<jdong> so is there a way to set max_sectors via a udev rule?
* fabbione yawns
<fabbione> morning guys
<mdz> morning fabio
<Burgundavia> morning fabbione
<Burgundavia> mdz: are we going to ship with both gthumb and fspot?
<jdong> does keybuk handle udev stuff?
<jdong> or is there someone else here fluent in udev that can decide if my bug can be fixed?
* jdong still bumming about his cheap mp3 player
<fabbione> hey mdz
<fabbione> Burgundavia: yo
<jdong> *blick*
<jdong> blink
<BenC> mdz: Hey, I've looked over the diffs, but it's after 12am here, so I'll get back to you tomorrow afternoon
<BenC> hopefully have something to test
<jdong> umm, why is any arbitrary password unlocking gnome-screensaver?!?
<jdong> can anyone reproduce that?
<BenC> jdong: Nope, I just unlocked and mistyped the password the first time
<BenC> jdong: It failed
<jdong> BenC: I must've screwed something up restarting udev then :D
* jdong schedules a reboot soon
<HrdwrBoB> jdong: still not a good failure 
<Burgundavia> jdong: file a bug anyway
<HrdwrBoB> in terms of security
<Burgundavia> it should fail closed, not open
<jdong> BenC: I commented on the bug a bit more regarding the usb device; looks like a userspace udev fix is best
<jdong> Burgundavia, HrdwrBoB, I'll reboot and see if it's reproducable
<BenC> jdong: Please reassign to udev then, and point to any linux-usb comments you can
<BenC> jdong: I'll revert the GO_SLOW
<jdong> ok, confirmed, it is caused by udev
<jdong> stopping udev will cause gnome-screensaver to accept any password
<jdong> is that a bug or user stupidity? 
<BenC> bug
<jdong> ok, I'll file it then
<jdong> BenC: should I tag it security or leave it normal?
<HrdwrBoB> no stupidity should cause any password to be accepted
<HrdwrBoB> short of deliberately haxing pam or something stuipd
<HrdwrBoB> stupid
<jdong> bug 65615
<Ubugtu> Malone bug 65615 in gnome-screensaver "Stopping udev causes gnome-screensaver to accept any password" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65615
<jdong> now, this sleep thing... probably should start at 12:30AM
<Donkeybreath> check out my site www.jpegtown.com tell me what you think of the coding, just finished it up
<fabbione> Donkeybreath: it's offtopic here
<pitti> Good morning
<Fujitsu> Hey pitti.
<pitti> infinity, mjg59: ATM booting takes about 5 minutes for me, if I remove 'splash', it's done in 56 seconds; do the usplash functions have some timeout which could cause this? (I have the segfaulting usplash variant here)
<infinity> I have no idea.  The New and Improved usplash is a mystery to me. :)
<pitti> infinity: heh, ok; if I would only see how it should look like :)
* pitti removes splash option for the time being
<infinity> pitti: Want to look at a build log for me and tell me if this is a bug in your symbol extractor?
<pitti> infinity: of course
<infinity> pitti: Forwarded.
<tfheen> pitti: which arch?
<pitti> tfheen: amd64/nvidia, the duo infernale
<tfheen> pitti: hmm, that's weird.  It should just segfault and run on its merry way.
<pitti> tfheen: it looks as if the functions would hang and wait for usplash for some time
<tfheen> pitti: hmm
<infinity> Who feels like looking into a tar testsuite failure before I start randomly filing and assigning bugs to the first person on my list?
<pitti> infinity: argh, it seems that hppa is the only reason why we have to keep gnutls11 :-(
<tfheen> uh, just when did ubuntu-desktop start depending on linuxprinting.org-ppds?
<infinity> pitti: Ingore hppa.
<pitti> tfheen: argh, wasn't this supposed and agreed to be split into a small desktop and large supported package?
<tfheen> pitti: I thought so, yes.
<tfheen> I blame Scott
<pitti> infinity: if I would fully ignore hppa, then gnutls11 could go; no reason to keep a vulnerable old version just for one multiverse package that doesn't build anyway
<pitti> erm, my last sentence echoed very broken in xchat -- was it ok for you?
<pitti> infinity: libtasn FTBFS> will look into it and fix pkg-create-dbgsym
<infinity> pitti: Your grammar was just as bad in irssi as it was in xchat. :P
<infinity> pitti: Anyhow, we can ignore hppa.  If you want gnutls11 removed, just say the word.
<tfheen> you just have to run it through the degermanisation filter and it parses fine. ;-)
<pitti> infinity: I meant, half of the sentence was completely missing here
<infinity> Which half? :)
<pitti> everything before 'go'
<fabbione> the good one
<pitti> anyway, /me blames solar radiation
<fabbione> so now we have itaglish and germanish
<pitti> fabbione: the latter is commonly referred to as 'Denglish' here :)
<fabbione> ehhe
<infinity> pitti: Okay, when Fabio's making fun of your English, you know it's time to go back to bed for an hour and try this whole "morning" thing again. :)
<Fujitsu> pitti, Xchat often does things like that.
<pitti> 'Good morning, Mr. Nitto, how do you do?' 
<pitti> infinity: instead of going to bed, I think I'll try having some breakfast
<infinity> Not a bad plan.
<pitti> infinity: is hppa just lagging behind buildd-wise, or is there some other congestion I don't know about?
* StevenK notes it's too late for breakfast, and too early for bed.
<Fujitsu> 5pm isn't too early for bed!
<Fujitsu> Just have a very, very early night :P
<infinity> pitti: hppa isn't shipping with edgy at all, we never bootstrapped it.
<infinity> pitti: Broken glibc, it'll be back with a working toolchain for edgy+1.
<pitti> ah, ok
<infinity> I commend you for not having noticed this for 4 months. :)
<pitti> well, then let's kick gnutls11 and sleep a bit better :)
<pitti> infinity: well, the number of hppa boxes in my vicinity is somewhere between epsilon and 0
<tfheen> pitti: you're unable to detect both their velocity and position at the same time?
<infinity> I was thinking the same thing...
<pitti> tfheen: yeah, unfortunately, that's why I can't count them exactly
* pitti engages the Heisenberg compensator
<infinity> Mine's pretty easy to locate, it's being used as a coffee table.
<infinity> One of these days, I'll spill something in it and be non-plussed.
<Fujitsu> -shudder-
<tfheen> infinity: it'll just drink it and burp back at you.
<StevenK> I've seen coffee tables go faster than my hppa.
<tfheen> zul: are you planning on getting a new xen-restricted-modules with the correct ABI into the archive?
<pitti> tfheen: is that the promised hppa 'release'? :)
<StevenK> Damnable 712 that it is.
<infinity> tfheen: He can't until he fixes the headers.
<infinity> tfheen: I was about to upload XRM for him, but it still doesn't build.
<tfheen> infinity: oh, those are broken (again)?
<tfheen> *sigh*
<infinity> tfheen: Missing asm/ on (at least) i386.
<infinity> tfheen: Just tested a few hours ago.
<tfheen> I've only fixed that like five times.
<tfheen> apparently, we keep losing the fix.
<Fujitsu> tfheen, want me to break it a few times, just for you?
<infinity> tfheen: If you want to fix it AGAIN and upload a fixed version, I'll get XRM in.
<infinity> tfheen: I just don't want to upload XRM blindly without first testing that it builds.
<tfheen> oh, absolutely agreed.
<infinity> Cause it, y'know, never has.
<infinity> (Not on i386, anyway(
<tfheen> I should get some breakfast and get the freeze really started first, I think.
<infinity> You want me to flip the freeze switch?
<tfheen> yes, please
* ..[topic/#ubuntu-devel:tfheen] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Frozen for release!
* ..[topic/#ubuntu-devel:infinity] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is FROZEN
<tfheen> bah
<infinity> COLLISION!
* tfheen sees IRC segfault
<tfheen> I'll mail u-d-a after breakfast
<infinity> tfheen: In the u-d-a announcement, be sure to mention that unapproved uploads will most likely just be rejected, since this is the final freeze.
<|thunder> sup guys. ive got a question no one in #ubuntu can awnser. I need to create a symlink to glibc libs to install borland kylix 3. The symlink has to reside in /usr/lib and have the same name as the lib itself excluding inline version number. Anyone got any ideas on this one ?
<infinity> (ie: We'll want the queues completely empty by release day)
<infinity> |thunder: You want to install libc6-dev.  You also want to not ask these questions in here.
<|thunder> ohh, sorry to break the rules.
<|thunder> thanks though
<|thunder> infinity; just so you know. im still getting this. "Glibc version....FAILED"
<|thunder> even thought that installed fine
<infinity> Well, I know nothing of kylix, I just know what package includes libc6 development libraries. :)
<infinity> Note that this isn't #kylix, and we've not the time to deal with it, really.
<|thunder> mainly my question was really "where is glibc.so"
<infinity> Well, that got answered. :)
<infinity> Either way.  Not a support channel.  Please respect that we're working on a release here.
<|thunder> duely noted
<mantiena-baltix> pitti: hi, I found where is problem when partition is listed in /etc/pmount.allow but nautilus doesn't allow to enter into this partition from computer:/ locatiom ;)
<mantiena-baltix> pitti: it's in hal
<infinity> And dholbach wins the prize for being (probably) the very last NEW source package accepted to edgy..
* StevenK managed to sneak a universe upload in that just went through.
<StevenK> Where sneak in is like half an hour ago.
<Fujitsu> RC Freeze is not applicable to universe, is it?
<infinity> Fujitsu: I'd beg to differ.
<infinity> Fujitsu: Though freeze exceptions for universe will be more slack.
<infinity> Fujitsu: The whole archive is frozen, however, and will remain so until release.
<Fujitsu> Ooh, OK.
<infinity> Fujitsu: So, you'll need MOTU freeze exception approval (from, say dholbach), then an archive admin to approve the upload.
* StevenK sets Fujitsu 50 lines: I will not question infinity.
* infinity goes about clearing out queue/new again.
<tfheen> infinity: agreed; no need for the release team to worry about universe.
* Fujitsu obeys StevenK.
<Fujitsu> I'm too close to infinity to risk it :P
<infinity> We have a package called "hat"?
<StevenK> Hah
<infinity> A package called "hat" that doesn't build on sparc, even.
<heno> Sounds more like a Fedora package
<StevenK> infinity: Some Haskell thing.
<infinity> StevenK: Evidently.  Do you like haskell things enough to fix it?
<infinity> (It's trying to include sys/byteorder.h directly)
<Fujitsu> Haskell is... odd.
<infinity> Bad hat.  Bad.
<Fujitsu> Who wants to wear the hat failure on their head?
<StevenK> infinity: I can spell it, but I'll have a look.
* Fujitsu ducks.
<infinity> StevenK: The failure is in C code, obviously.
<infinity> StevenK: So, you win.
<StevenK> The "include sys/byteorder.h" told me that. :-P
<infinity> Yeah. :)
<StevenK> Yay, mpg321!
<StevenK> Frame#  9822 [18446744073709547505] , ...
<StevenK> This from a 4Mb mp3
<tfheen> it's trying to get you to use oggs
<StevenK> #if defined(sparc)
<StevenK> #include <sys/byteorder.h>
<StevenK> #endif
* StevenK sighs.
* StevenK wonders if he can build an edgy chroot onto his poor Ultra 5.
<fabbione> StevenK: yeah you can
<fabbione> it's enough you run a sparc64 kernel
<dholbach> good morning
<pygi> morning dholbach 
<dholbach> hey pygi
<infinity> dholbach: I've just nominated you Universe Release Manager, by the way. :)
<infinity> dholbach: Whether you want it or not.
<infinity> dholbach: All universe uploads need to go through you (or people you delegate) from here on in, then you'll need to ping an archive admin to get them out of queue/unapproved
<dholbach> infinity: oh - why can't we let them through? i expect quite a bunch of them (unmet deps, ssl transition, etc)
<infinity> dholbach: The whole archive is frozen.
<infinity> dholbach: I'm happy to take large lists of "let this crap through" though. :)
* dholbach not happy :-/
<dholbach> for hoary I uploaded until 3 hours before release ;-)
<infinity> Still can. :)
<dholbach> yeah, I need to be awake and prod you for everything
<Fujitsu> We've still got a lot of stuff to do :S
<infinity> Well, the prodding can by async.
<infinity> Not a big deal.
<dholbach> Hrm, I don't like the "you need to pass two people" solution
<infinity> dholbach: Propose a "allow freezing of individual components" soyuz spec for Mountain View. :)
<dholbach> but I guess there's no choice
<dholbach> infinity: Ok :-)
<dholbach> infinity: I knew it wasn't your fault
* dholbach hugs infinity
<Fujitsu> infinity, it can't be /that/ hard to implement it...
<infinity> dholbach: Well, if your word is that "universe isn't frozen", then it only needs to pass one person (archive-admin), since you've pre-approved the world. :)
* dholbach gets the infinity fanboy t-shirt ready
<infinity> dholbach: But that's your call, the release team refuses to deal with universe.
<infinity> We'll have our hands full as it is.
<dholbach> yeah, I can see that
* Fujitsu throws 15000-odd packages at infinity.
<infinity> This is going to be a bumpy release, I fear. :/
<infinity> I'm already looking forward to edgy+1, if for no other reason than so I don't have to think about edgy.
<Fujitsu> infinity, most are, no?
* dholbach hugs infinity
<infinity> Fujitsu: Well, they all have bumps, but some approach release date a bit more prepared than others. :)
<Fujitsu> True... Exceptions seem to have been more liberally applied to Edgy...
<tfheen> dholbach: I'm writing the freeze announce now.  I'd like to have universe frozen and require approval, but your choice.
<infinity> tfheen: Well, it's frozen regardless.  I can't change that.
<infinity> tfheen: It's a question of whether he's giving blanket approval, or case-by-case.
<tfheen> infinity: well, yes.
<infinity> dholbach: So, your call, really.
<dholbach> we already do uvf for new packages and new upstream versions - i really don't fancy approving each rebuild upload
<infinity> dholbach: As I spot stuff in queue/unapproved, I'm likely to ask you about it anyway, so it's not a one-way street.
<dholbach> Ok
<infinity> (ie: Nothing will get "lost")
* StevenK wonders when an archive admin will flip the "Hoary is OBSELETE" switch.
<dholbach> *nod*
<infinity> One way or another, all the uploads will either be accepted or rejected. :)
<infinity> StevenK: It's not yet. :)
<tfheen> dholbach: would you like to nominate a person in addition to yourself right away?
<tfheen> StevenK: it's not like we're not itching to.
<infinity> slomo played that role once, didn't he?
<ajmitch> evening
<dholbach> he's on vacation
<ajmitch> slomo is still away
<dholbach> not sure if ajmitch or siretart have enough time for that
<infinity> And yeah, I have a lot of dirty hacks in hoary that I can't WAIT to go unsupported.
<dholbach> they already help with  motu-uvf
<infinity> I'm actually pretty happy with my work in breezy and dapper, by comparison.
<ajmitch> dholbach: I'm fine with that if you want
<Fujitsu> Poor old Hoary :'(
<dholbach> ajmitch: us approving/rejecting each universe upload?
<infinity> dholbach: Just change the U in UVF from "upstream" to "upload" and you've got a team.
<dholbach> infinity: super
<tfheen> infinity: upload version freeze?
<infinity> tfheen: Sure, why not? :)
<Fujitsu> tfheen, that's perfectly valid.
<dholbach> ajmitch: if you're prepared to take the load, say so
<ajmitch> dholbach: yeah, it'll be painful, but I think we can do it if there's enough checking them
<dholbach> tfheen: fschoep told me to revert to dapper artwork - so expect 3 upload to main in a bit
<dholbach> ajmitch: Ok
<ajmitch> though I think that there'll be a lot of rebuilds & small fixes going in soon
<infinity> ajmitch: It doesn't need strict checking, per se, just yay or nay approval so I'm not blindly letting everything through.
<tfheen> dholbach: I'll point to the UVF motu team for universe, then and you can chuck people in or out of the team as you feel like?
<ajmitch> infinity: alright
<siretart> dholbach: I think I should be able to handle that as well
<infinity> ajmitch: So, y'know "this was an FTBFS fix, these 12 are libssl rebuilds", etc.
<ajmitch> hey siretart 
<siretart> huhu ajmitch 
<dholbach> ajmitch is Upload Liteunant
<ajmitch> infinity: sounds manageable
<dholbach> hi siretart
<siretart> huhu dholbach 
* dholbach hugs siretart and ajmitch
<siretart> :)
* BHSPitMonkey distributes hugs all around
<tfheen> dholbach: do you have any policies wrt what should be uploaded in universe?
<infinity> dholbach: We're not using the edgy artwork?  And I just got used to it too...
<tfheen> dholbach: artwork> 'k; I'd rather have us keep the edgy artwork, but it's not my call..
<dholbach> tfheen: no, in the most cases I trust people
<dholbach> tfheen: it's not my call either - I'd like to keep it too
* StevenK tries to invite the cooler air in from outside.
<dholbach> I'll prepare some   unofficial-edgy-artwork   packages ;-)
<StevenK> dholbach: Any reason given?
<Kamion> morning
<ajmitch> morning Kamion 
<infinity> Mornin'.
<dholbach> StevenK: it does not meet the expectations of Mark and select other people and there is work underway, but not sure if it's going to make it
<crimsun> infinity: hi, do you have a moment to look at a strange ftbfs across five arches (https://launchpad.net/distros/ubuntu/+source/vlc/0.8.6-svn20060918.debian-1ubuntu4 )? It seems to be dying on an empty .po file - which I'm certain is not empty.
<Fujitsu> Hey Kamion.
<dholbach> hi Kamion
<dholbach> StevenK: that's all I know
* tfheen gives Kamion a couple buckets of coffee.
<StevenK> Damn it. Does anyone have a base tarball of Dapper/Edgy for sparc? My sparc insists "binary-sparc/Packages.gz was corrupt"
<Fujitsu> StevenK, it's 36 degrees here :(
<dholbach> Kamion: when did you go to bed?
<ajmitch> the archive is frozen now?
<tfheen> ajmitch: yes
<infinity> ajmitch: Yup.
<StevenK> Fujitsu: My panel applet says 25.
<siretart> 09:47:16 < infinity> dholbach: The whole archive is frozen.
<StevenK> Fujitsu: Thank $DEITY
<ajmitch> good thing I got f-spot bugfixes in on time
<Fujitsu> StevenK, in Melbourne?
<siretart> infinity: will it be unfrozen again after the release candidate?
<tfheen> siretart: no.
<StevenK> Fujitsu: No, here. :-)
<infinity> siretart: Probably not.
<Fujitsu> StevenK, lucky.
<StevenK> Fujitsu: Feel free to visit. :-P
<siretart> i see
<dholbach> siretart: the uvf team will approve uploads though
* Fujitsu hits Thunderbird's junk mail filter. It nicely detects all of USNs as junk,.
<siretart> how do we approve uploads? pinging infinity via irc or using some fancy launchpad pages?
<ajmitch> how will we view the list of frozen uploads, firstly?
<infinity> crimsun: I assume it creates it during the build?  Since I don't see that in the source package at all.
<fabbione> StevenK: corrupted? what mirror are you using?
* dholbach wants a crazy launchpad starttrek panel with millions of buttons across at least 3 screens
<fabbione> dholbach: ROFL
<StevenK> fabbione: Either archive.u.c or au.archive.u.c.
<infinity> siretart: ping me or kamion.  We could use Malone for it, but seems like a non-starter if there'll be a lot of uploads.
<crimsun> infinity: I have to guess so. It seems to reference debian/patches/001_1008snap.translations.diff indirectly, which is confusing me.
<Kamion> dholbach: about 4:15am
<janimo> crimsun: hi, I fixed the xss and splash LP bugs, gxine is in the upload queue
<crimsun> janimo: thank you!
<infinity> ajmitch: You can see the unapproved queue here: https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=1
<ajmitch> thanks
<Kamion> IIRC unapproved isn't visible by mortals
<Kamion> check
* dholbach hugs Kamion and joins tfheen in handing you coffee
<infinity> ajmitch: Well, I think you can.
<infinity> ajmitch: Check, please. :)
<Kamion> infinity: failing that I suggest we periodically dump a list of packages in unapproved onto IRC
<ajmitch> infinity: no permission
<infinity> Kamion: Works for me.  I was planning on pinging these guys when I saw a mess of stuff in there anyway.
<infinity> ajmitch: We'll work something out.
<Kamion> right, time for final(?) d-i and ubiquity uploads
* infinity needs to head off for dinner and such, but will be back later.
<siretart> hm.. no permissions here as well
<Kamion> will take a little while to have Rosetta dump translations on me
<infinity> siretart: See above.
<Kamion> I think it's a bug, really - you can see NEW, why not UNAPPROVED
<siretart> ok
<malcc> Kamion: I'm pretty sure that was deliberate, so there was an answer to your why in someone's head at some point. No idea what it was anymore though
<infinity> malcc: There's no question that it was deliberate, but that doesn't answer the why. :)
<Kamion> malcc: I wonder if it was before UNAPPROVED was added
<Kamion> malcc: so deliberately not ACCEPTED, REJECTED, DONE
<Kamion> even so it's kind of odd
<Kamion> I think everyone should be able to see a list of items in all the queues, but everyone should not be able to download files from them (once that's implemented)
<StevenK> fabbione: Right. It's a local problem. A missing md5sum will do that.
<siretart> hm. I'm presented an 'ACCEPT' button on the NEW queue. I wonder what happens if I press it :)
<Kamion> although in fact the code is explicit about not allowing UNAPPROVED
<mantiena-baltix> pitti: why 0.5.7-1ubuntu18.1 still in proposed-updates, not in updates ? you noticed some problems in new version ?
<ogra> Kamion, would you mind taking a look at the patch in the last comment of bug 65003 ? does that seem like a valid workaround ?
<Ubugtu> Malone bug 65003 in ltsp "debootstrap fails to remove own log file on NFS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65003
<Kamion> siretart: known bug that you see it - you'll get Forbidden if you click Accept
<siretart> Kamion: ah, I see. In fact, I thought so :)
<doko_> Kamion, tfheen: uploaded zlib, fixing FTBFS on i386
<siretart> Kamion: btw, given that we could look at the unapproved queue, how can we check/qa the uploads?
<Kamion> ogra: you're mistaken about the repeated unpacking/configuring thing - debootstrap always unpacks and configures all of required, then unpacks and configures all of base
<Kamion> siretart: you can't, yet ;-)
<siretart> ah. I see :)
<Kamion> you'd have to get an archive admin to fetch them and put them somewhere public
<ogra> Kamion, yes, i noticed it later
<ogra> Kamion, in d-i it does that but tells you about the five times it attepmts it, i was mixing that up
<Kamion> that's only if something goes wrong, as you say
<Kamion> I'll ponder that suggested patch
<Kamion> mantiena-baltix: see https://wiki.ubuntu.com/StableReleaseUpdates; all dapper updates are being staged through dapper-proposed now
<ogra> Kamion, i think the real fix should be in rm/coreutils though, but it seems appropriate as workaround to me
<Kamion> ogra: do you have a link to a more complete description of the rm bug?
<ogra> nope
<tfheen> I'm not convinced it's a bug in rm, but rather a bug in the nfs server.
<ogra> tfheen, you mean it treats -rf different than rm on its own ?
<Kamion> unless it's http://www.mail-archive.com/bug-coreutils@gnu.org/msg08031.html
<pitti> mantiena-baltix: that's our new stable release update policy; it must be in -proposed for at least a week
<Kamion> ogra: obviously not (the NFS server doesn't know that you said -rf) but that unlink() isn't processed in time for the rmdir() to succeed
<tfheen> ogra: do you know how NFS works?  On a protocol level?
<ogra> roughly
<tfheen> you know POSIX semantics wrt accessing deleted files?
<tfheen> and how NFS to a certain degree emulates those semantics?
<Kamion> OH
<Kamion> the problem is that the file is still open but NFS is implementing access to it by means of a dotfile?
<Kamion> s/but/so/
<tfheen> at least the NFS server thinks it's open
<ogra> ah
<Kamion> it probably is, it's stderr
<tfheen> it should still allow removing the directory if there are no other files in it.
<ogra> well, i know he's using freebsd and plugs our ltsp on top ...
<tfheen> (yes, this can easily be painful for the NFS server)
<Kamion> another workaround might be to redirect stdout and stderr back to where they were before (or close them) before doing the rm -rf
<Kamion> I'll comment on the bug report
<fschoep> dholbach: ping?
<dholbach> fschoep: working on it :)
<ogra> Kamion, thanks
<fschoep> dholbach: thanks so much
<dholbach> fschoep: de rien
<mantiena-baltix> pitti: I found where is problem when partition is listed in /etc/pmount.allow but nautilus doesn't allow to enter into this partition from computer:/ location ;)  it's because hal set's volume.ignore property for these partitions
<Chipzz> pitti: I have a hppa box; 2 actually
<janimo> ogra: thanks for the ldm upload
<Chipzz> pitti: would setting one up with breezy and giving you access to it help?
<pitti> mantiena-baltix: aaah
<ogra> janimo, youre welcome, but please try to get such stuff sorted earlier next time
<pitti> mantiena-baltix: yeah, I specifically patched this so that nautilus doesn't show these partitions on a desktop, since a user could not mount them anyway :)
<tfheen> Riddell: you broke poppler, please fix.
<pitti> Chipzz: erm, actually not, I just wondered about the edgy archive state of hppa
<pitti> Chipzz: but thanks a lot for the offer!
<janimo> tfheen: please approve gxine upload, it closes two LP bugs
<Chipzz> yw :)
<ogra> tfheen, why are we frozen already btw ? i thought the meeting date is the time ...
<Kamion> ogra: actually, on reflection, Steven's patch is probably the best approach
<tfheen> ogra: don't try gaming the system.  We are freezing today, the time is explicitly undefined.
<tfheen> janimo: debdiff, please?
<ogra> tfheen, i'm not "gaming the system" all freezes before deliberately started with the meeting, thats why i wondered
<mantiena-baltix> pitti: unmounted partitions are newer shown on the desktop in any case but if volume.ignore is set to true for these partitions then user should press "Reload" button manually (after he double clicks on partition) if he wants to enter into this partition from computer:/ location
<pitti> mantiena-baltix: let's find a solution in edgy+1 which suits us both
* pitti would prefer a gksudo mount wrapper in nautilus
<Kamion> ogra: I think you can reject the ltsp part of that bug
<ogra> right
<Kamion> tfheen: ok to upload http://librarian.launchpad.net/4793845/debootstrap.nfs.patch ? NFS server bug or not, it seems a reasonable workaround
<mantiena-baltix> pitti: ok, I think volume.ignore should be set to false in 20-storage-methods.fdi for unmounted partitions, this is valid for gksudo mount wrapper too
<tfheen> Kamion: approved.
<pitti> mantiena-baltix: yes, we'll un-ignore it as soon as the desktop can actually handle them correctly
<Kamion> (I added an extensive comment)
<mantiena-baltix> pitti: because unmounted hard drive partitions should be shown in computer:\ location if there will be a way to mount these with gksudo mount wrapper ;)
<dholbach> fschoep: edgy-wallpapers and edgy-session-splashes uploaded, doing edgy-gdm-themes now
<fschoep> dholbach: OK, did I ever tell you you are Clark Kent's alter ego?
<fschoep> dholbach: :)
* dholbach hugs fschoep :-)
<dholbach> Thanks :-)
* fschoep hugs dholbach 
* StevenK sighs.
<StevenK> enervated:~# chroot /tmp/d mount -t proc proc /proc
<StevenK> FATAL: kernel too old
<Treenaks> kernel too old to mount /proc?!?!
<Fujitsu> Haha.
<StevenK> That's my sparc64 mailserver. I didn't really want 2.6 on it.
<fabbione> StevenK: we don't support 2.4
<fabbione> not even on sparc
<pitti> mantiena-baltix: can we please discuss that after the edgy release?
<StevenK> I figured.
<pitti> mantiena-baltix: I'm afraid I really have to care for other stuff now, sorry
<Kamion> tfheen: accepted zlib; it was just removing a couple of compiler options from the i386/x86-64 build
<seb128> iwj: hi. Is compreg.dat of any use? Maybe the firefox postinst could rm it to workaround weird issue happening for people who have one still installed, it's creating bug #30791 now
<Ubugtu> Malone bug 30791 in firefox "firefox 1.4.99 upgrade still have compreg.dat, creates issue" [Medium,Needs info]  http://launchpad.net/bugs/30791
<tfheen> Kamion: thanks
<mantiena-baltix> pitti: no problem, I just write comments about volume.ignore in bugreport about mounting non-removable partitions, because we can forget these after edgy will be released ;)
<pitti> mantiena-baltix: yes, a bug report is appreciated; please subscribe me; thanks
<tfheen> pitti: your mail-notification upload FTBFS due to not finding a .desktop file.
<tfheen> (yes, I realise it's a no-change upload so probably not your fault)
<tfheen> probably mvo's fault, actually.
<pitti> tfheen: oh, thanks, will look into it
<pitti> sorry
<tfheen> powerpc-linux-gnu-g++: now: No such file or directory
<tfheen> that's.. special, isn't it?
<tfheen> seb128: you're probably aware of it, but your latest tsclient upload FTBFS-ed across all arches.
<seb128> tfheen: no, I'm not
<seb128> thank you for pointing it
<seb128> would be nice if we had ftbfs notification ;)
<tfheen> checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
<ogra> tfheen, http://people.ubuntu.com/~ogra/fuse.debdiff ok to upload ?
<seb128> tfheen: ok, fixing it
<pitti> hi mvo
<pitti> tfheen, dholbach: can I upload a FTBFS fix for mail-notification? (simple debian/rules fix to adapt the path to the .desktop file)
<dholbach> pitti: sure
<tfheen> ogra: use grep -q instead of redirecting the output.
<mvo> pitti: if you upload it, make sure the desktop file is ok too
<ogra> ok
<mvo> pitti: it used to have a typo
<tfheen> ogra: apart from that, feel free.
<pitti> mvo: hm, what do you mean? looks fine on a first sight
<tfheen> oh, bloody thingabob.
<tfheen> lcome.pdfpdfetex: symbol lookup error: pdfetex: undefined symbol: _ZN4Dict3addERK10UGooStringP6Object
<mvo> pitti: no, its all good. 
<pitti> tfheen: bless you
<tfheen> pitti: any idea about that?  It seems like a rebuild should fix it?
<tfheen> pitti: http://librarian.launchpad.net/4794030/buildlog_ubuntu-edgy-i386.gnat-gps_3.1.3-2ubuntu1_FAILEDTOBUILD.txt.gz is the build log
<pitti> tfheen: rebuild might be worth a try, but should be tested locally
<pitti> tfheen: that smells like a poppler ABI change that tetex-bin didn't pick up
<janimo> tfheen: the gxine debdff is basically two new patches under debian /04_poke_xscreensaver.dpatch and /05_no_splash.dpatch. If that is not easy to peek at in the queue directly I'll put a debdiff up shortly
<tfheen> pitti: yeah, which means we might have to either rebuild everything using poppler or bump the soname.
<tfheen> janimo: I don't have access to the queue.
<pitti> tfheen: hmm, pdflatex works fine here
<pitti> tfheen: texi2dvi, too. WTH???
<tfheen> pitti: on i386?
<pitti> tfheen: aah, i386-only FTBFS; I tested on amd64
<pitti> can anyone on i386 please try: gzip -cd /usr/share/doc/bzip2/manual.texi.gz > /tmp/manual.texi && texi2dvi /tmp/manual.texi  ?
<pitti> and if that fails, rebuilt tetex-bin and try again?
<dholbach> fschoep: uploaded gdm-themes and pushed them all to bzr
<seb128> dholbach: one of your uploads broke the cursor theme, you know about it?
<fschoep> dholbach: OK, great - this means they're in time for the freeze?
<janimo> tfheen: http://paste.ubuntu-nl.org/26413/ . The code is a copy of the gnome-screensaver poking code nothing new or scary
<seb128> dholbach: no  /usr/share/themes/Human/cursor.theme installed
<ogra> seb128, depends on the POV ;) it fixed the cursors for ltsp
* seb128 kicks ogra
<dholbach> seb128: uh? how did you get that? ogra did you hear anything about it?
* ogra hugs seb128 
<seb128> dholbach: a guy reported it on launchpad
<seb128> and it's broken on my box too
<ogra> dholbach, worked here
<dholbach> it works for me too
<tfheen> janimo: please add a proper description to the dpatches.
<ogra> (on a new ltsp install though)
<seb128> $ ls -l /etc/alternatives/x-cursor-theme 
<seb128> lrwxrwxrwx 1 root root 36 Sep 15 09:38 /etc/alternatives/x-cursor-theme -> /usr/share/themes/Human/cursor.theme
<seb128> $ ls -l /usr/share/themes/Human/cursor.theme
<seb128> ls: /usr/share/themes/Human/cursor.theme: No such file or directory
<seb128> 
<seb128> and I've just dist-upgraded
<seb128> which means gdm get the ugly cursor
<seb128> ogra: it works on the desktop because GNOME forces the cursor and doesn't need to alternative
<ogra> seb128, no it worked on the login manager ...
<seb128> do you have that cursor.theme?
<ogra> (before any gconf is loaded)
<ogra> oh, wait
<seb128> what package provides it?
<ogra> thats still the ltsp package with the workaround that sets the alternative
<janimo> tfheen: ah ok, although  I thought descriptive filenames were enough.
* seb128 slaps ogra
<janimo> tfheen: so I upload with the same version number but corrections added?
<pitti> tfheen: bah, texi2dvi works fine in ronne's i386 dchroot, too
<ogra> seb128, sorry, the publisher apparently wasnt fast enough for me ... i tested an older pkg ... :/
<dholbach> seb128: my fault. ogra: I'll install it to /usr/share/themes/Human/cursor.theme instead of /usr/share/*icons*/Human/cursor.theme
<dholbach> that should fixit
<pitti> tfheen: (it has an old libpoppler)
<dholbach> seb128, ogra: sorry for that
<tfheen> janimo: won't it fill the log with "can't poke the xscreensaver" for people who don't have it installed?
<seb128> dholbach: yep that should, thank you
<pitti> dholbach, seb128: does any of you have a current i386 edgy and some minutes?
<dholbach> seb128: you have the bug number?
<dholbach> pitti: yes
<pitti> dholbach: gzip -cd /usr/share/doc/bzip2/manual.texi.gz > /tmp/manual.texi && texi2dvi /tmp/manual.texi
<pitti> dholbach: (with tetex-bin installed) -> does the texi2dvi fail with a symbol error?
* dholbach installs tetex-bin
<seb128> dholbach: bug #65600
<Ubugtu> Malone bug 65600 in human-cursors-theme "(Edgy) gdm now uses black X cursors instead of Ubuntu Human cursors by default" [Undecided,Confirmed]  http://launchpad.net/bugs/65600
* pitti hugs dholbach
<dholbach> i didn't have command-not-found installed
* dholbach installs that too
<seb128> pitti: dholbach was faster, do you need me to test anyway?
<pitti> seb128: nevermind, thanks
<seb128> np
<janimo> tfheen: it's the same code as for gnome-screensaver. If EACCESS is rececived it will no longer try to poke
<dholbach> pitti: bash: texi2dvi: command not found
<tfheen> janimo: oh, I'm blind; sure.  Ok, feel free to upload.
<dholbach> pitti: and tetex-bin is installed
<pitti> dholbach: sorry, that's texinfo
<janimo> tfheen:do I keep same version number for the new upload?
<dholbach> pitti: 
<dholbach> daniel@lovegood:~$ gzip -cd /usr/share/doc/bzip2/manual.texi.gz > /tmp/manual.texi && texi2dvi /tmp/manual.texi | grep -E "(symbol|error)"
<dholbach>  file:line:error style messages enabled.
<dholbach> daniel@lovegood:~$ 
<dholbach> pitti: looks good
<pitti> dholbach: ok; and texi2dvi -p /tmp/manual.texi ?
<dholbach> daniel@lovegood:~$ texi2dvi -p /tmp/manual.texi  | grep -E "(symbol|error)"
<dholbach>  file:line:error style messages enabled.
<dholbach> daniel@lovegood:~$ 
<tfheen> janimo: ask infinity or Kamion to reject 1ubuntu5 first or bump the version number.  Either's fine.
<janimo> tfheen: uploaded, added LP bug numbers to changlog and fixed the dpatch descriptions
<pitti> dholbach: you have libpoppler1_0.5.4-0ubuntu2_i386.deb ?
<tfheen> janimo: this is why you should ask a member of the release team before uploading.
<dholbach> pitti: 0.5.4-0ubuntu3
<tfheen> Kamion: you broke *ubuntu-meta ; ubuntu-live no longer exists.  Feel like fixing that? 
<janimo> Kamion: please reject gxine_0.5.7-1ubuntu5
<pitti> dholbach: ok, thanks; hmm, very mysterious
<janimo> so I can reupload it fixed
<janimo> thanks
<dholbach> tfheen: judging by the changelog it was deliberate
<seb128> dholbach: how did you do that, he did build
<seb128> didn't
<seb128> https://launchpad.net/distros/ubuntu/+source/poppler/0.5.4-0ubuntu3
<dholbach> seb128: because I used showsrc instead of show
<dholbach> seb128: lalalalala
<seb128> :p
<dholbach> pitti: sorry, is 0ubuntu2
<seb128> you know about dpkg -l, right? ;)
<pitti> dholbach: heh
<tfheen> dholbach: I don't think the FTBFS was deliberate.
<dholbach> tfheen: no, I shouldn't think so.
<Kamion> the FTBFS wasn't, I'll check that
<Kamion> but ubuntu-live is going away
<pitti> dholbach: still, http://librarian.launchpad.net/4794030/buildlog_ubuntu-edgy-i386.gnat-gps_3.1.3-2ubuntu1_FAILEDTOBUILD.txt.gz is mysterious
<seb128> pitti: do you know why ekiga didn't get its debsym moved on your people page?
<pitti> dholbach: it only fails on i386, and the amd64 build used the same libpoppler
<Kamion> let me just get this d-i upload done first
<tfheen> Kamion: please do.
<pitti> seb128: let me track it
<dholbach> pitti: urg :-/
<tfheen> dholbach: syncropated ftbfs-ed; http://librarian.launchpad.net/4797234/buildlog_ubuntu-edgy-i386.syncropated_0.1.2-0ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> dholbach: maybe you could try a local build of gnat-gps?
<dholbach> tfheen: checking in a bit
<dholbach> pitti: getting the source
* dholbach gets 26M of build-deps
<pitti> dholbach: ouch
<dholbach> no problem :)
<dholbach> I always thought I'd need some more gnat packages on my laptop ;)
<tfheen> pitti: and your gnomesword upload failed to build due to libsword changing underneath you.  I'm looking at that.
<pitti> seb128: fixed; I blame cosmic rays
<Hobbsee> pitti: damn them.  havent you written something to get rid of them yet?
<pitti> apt-get install lead-shield on rookery :)
<Hobbsee> hehe
<seb128> pitti: thank you :)
<dholbach> tfheen: syncropated fixed
<Kamion> janimo: the older one, I assume?
<tfheen> if there are any ichtux/ubuntu christian edition people about: gnomesword ftbfs with the new libsword-dev.
<Kamion> janimo: done, although in future I'd rather you just superseded it with a new version
<dholbach> seb128, ogra: human-cursors-theme fixed
* seb128 hugs dholbach
* ogra hugs dholbach 
<dholbach> whoever drives that part of launchpad now: please accept edgy-gdm-themes, edgy-session-splashes, edgy-wallpapers, human-cursors-theme
<iwj> seb128: No, compreg.data is an anachronism.  Nothing should be creating it.
<Treenaks> iwj: so why is stuff still crashing when it exists? Shouldn't it also just be ignored?
<seb128> iwj: it happens for a bunch of people still, what about just making the postinst rm it?
<tfheen> dholbach: technically, you should ask a member of the release team to review them before uploading. :-P  They're trivial rollbacks to edgy?
<dholbach> yes, I even tested them
<dholbach> human-cursors-theme has a fix
<tfheen> dholbach: testing> that being a new experience for you?
<pitti> dholbach: testing? wimp! :)
<iwj> seb128: I'm not sure that would be sufficient.  Some other package's maintscript is creating it.
<iwj> Treenaks: This is Mozilla code we're talking about - don't ask questions like that.
<dholbach> tfheen: Tell me what you think
<iwj> seb128: So it could easily be created after firefox was last upgraded.
<Treenaks> iwj: because of brain-hurt, of because looking at mozilla code invalidates the trademark license?
<iwj> What we need to do is find out _why_ it's being created.  There's probably one thing that's doing it.
<iwj> Treenaks: It's huge and old and full of cruft.
<Treenaks> of=or
<tfheen> dholbach: debdiffs would be nice.
<pitti> infinity: argh, finally got to the libtasn1-3 FTBFS; debian/rules uses "--dbg-package libtasn1-3", while the manpage mandates "--dbg-package=libtasn1-3"; will fix
<dholbach> tfheen: hang on
<pitti> infinity: (fix in pkg-create-dbgsym to accept that syntax as well, I mean)
<seb128> iwj: right, I agree on that, the issue is that's not reproducible easily and people who get it didn't install anything to get datas before the upgrade
<tfheen> gnat-gps ftbfs on amd64, but with another error.
<tfheen> *sigh*
<iwj> seb128: If I arrange for the firefox postinst to remove this file, it will only help if the thing that's creating it is upgraded before firefox.  But that seems unlikely; it's probably a gecko embedder.
<seb128> iwj: yeah, might be
<iwj> Certainly there is no harm in it.  It would mean also that reinstalling firefox would fix the problem.
<iwj> I think in edgy+1 I might do some crazy thing with inotify.
<dholbach> tfheen: http://daniel.holba.ch/temp/ <- 4 debdiffs
<janimo> Kamion: thanks, I'll know next time
<sivang> morning
<Kamion> ok, that's *-meta fixed
<iwj> seb128: How often do you get these reports ?  We could collect installed package lists from people and compute the intersection.
<seb128> iwj: I think we got around 10 people complaining about the "gmail is not working" issue for a month
<tfheen> dholbach: go ahead.  Please close the artwork bugs as well when you upload.
<seb128> iwj: I had the issue too during the Wiesbaden sprint, we just figured yesterday it's due to the compreg.dat
<dholbach> tfheen: I already uploaded them - they're sitting in the queue
<dholbach> tfheen: I'd like fschoep to close the bugs - aiui there's still ongoing work
<Kamion> dholbach: all four accepted
<dholbach> Kamion: thanks a lot!
<Kamion> tfheen: in unapproved: tsclient gxine fuse dist-upgrader
<fschoep> tfheen: dholbach: I can close the bugs, I was waiting for the sign that the "new" art stuff was in
<dholbach> fschoep: oh - I thought tere was still work ongoing?
<tfheen> Kamion: tsclient, gxine, fuse approved, dist-upgrader I have not heard anything about.
<iwj> seb128: Hmm.  OK, I will arrange for the postinst to delete it - and to grumble to stderr.
<seb128> iwj: thank you
<iwj> seb128: But we should do something more proactive for edgy+1.
<fschoep> dholbach: there was, but I haven't received word from above so we can't do anything
<Kamion> mvo: ^-- ?
<iwj> I don't think this will make the problem go away but it will probably make it easier to fix.
<iwj> It's annoying not to be able to do anything more useful.
<seb128> iwj: I'll try to set debug for it when I do dapper to edgy upgrades
<mvo> Kamion: I just uploaded a one-line fix. I can put the diff to people.u.c if you want
<iwj> Can you confirm that it's always created in the same place ?
<fschoep> Only thing to change might be applying the patch in bug 57588 to the old GDM
<Ubugtu> Malone bug 57588 in edgy-gdm-themes "GDM themes do not have pam-message item" [High,In progress]  http://launchpad.net/bugs/57588
<iwj> seb128: Thanks.
<seb128> iwj: /usr/lib/firefox/components/compreg.dat
<iwj> Right.
<dholbach> fschoep: alright-y
<fschoep> dholbach: don't worry about it though - I mean, I was waiting for Mark but he hasn't sent me anything in the last fourteen hours or so and I've been up almost all night
<Kamion> mvo: please
* dholbach hugs fschoep
* fschoep hugs dholbach
<Kamion> -            loggging.warning("_tryMarkObsoleteForRemoval failed for '%s' (%s)" % (pkgname,e))
<Kamion> +            logging.warning("_tryMarkObsoleteForRemoval failed for '%s' (%s)" % (pkgname,e))
<Kamion> oh, that's obviously trivial, will approve
<tfheen> Kamion: oh, happy enough with that, yes.
<mvo> Kamion: http://people.ubuntu.com/~mvo/tmp/dist-upgrader-20060928.1238.diff <- spott the error ,)
<Kamion> mvo: that's an entirely different diff ...
<iwj> seb128: I have edited the bug appropriately.
<mvo> Kamion: rurg
<fschoep> tfheen: dholbach: I set bug 64317 and 64318 to "Fix Released" to get them off the list.
<mvo> Kamion: the wrong one
<Ubugtu> Malone bug 64317 in evolution "Copying mail from imap / exchange to local mailbox looses data." [Undecided,Needs info]  http://launchpad.net/bugs/64317
<Ubugtu> Malone bug 64318 in zsh "shell dumps core while accessing libnss-ldap" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64318
<Kamion> mvo: never mind, I think we've got it
<dholbach> fschoep: rock and roll
<tfheen> fschoep: I hope you typoed both of those bug numbers.
<mvo> Kamion: ok
<fschoep> tfheen: No I didn't, Ubugtu is in the wrong I think
<fschoep> Oh I did
<fschoep> Sorry
<fschoep> tfheen: Bug 64137 and 64138
<Ubugtu> Malone bug 64137 in edgy-gdm-themes "Edgy RC needs new Human GDM theme" [Medium,Fix released]  http://launchpad.net/bugs/64137
<Ubugtu> Malone bug 64138 in edgy-wallpapers "Edgy RC needs new Human wallpaper" [Medium,Fix released]  http://launchpad.net/bugs/64138
<fschoep> That's better
<pitti> tfheen: I'd like to upload a new pkg-create-dbgsym which fixes the libtasn-1-3 FTBFS
<fschoep> I'm 20% awake right now, so apologies
<seb128> iwj: oh, I pointed the wrong bug number previously, bug #57888 is the new issue due to it
<Ubugtu> Malone bug 57888 in firefox "GMail and Ajax websites not working with Firefox 2.0 backend" [Undecided,Unconfirmed]  http://launchpad.net/bugs/57888
<seb128> iwj: should it be marked as dup of the other one?
<pitti> tfheen: one-line fix in the dh_strip wrapper plus added test case
<seb128> iwj: thank you for the bug update
<tfheen> pitti: go ahead.
<pitti> tfheen: uploaded
<pitti> infinity: ^ this fixes libtasn-1-3 ftbfs
<fschoep> iwj: are the Firefox themes going to be 0.5.4, the branch and all builds but I can't find this version on Launchpad?
<dholbach> pitti: it seems it builds for hours
<tfheen> mvo: are you doing upgrade testing?
<mvo> tfheen: yes, I can do this
<tfheen> mvo: great, thanks.
<mvo> (and did that to a certain extend the last days on and off)
<tfheen> mvo: yeah, I just hadn't heard you explicitly said "I'll do upgrade testing", so I asked. :-)
<mvo> :)
<mvo> "I'll do upgrade testing"
<mvo> (for the records ,9
* tfheen hugs mvo 
* mvo hugs tfheen
<Tonio_> hi
<sivang> hey Tonio_ 
<iwj> fschoep: Uh ?
<fschoep> iwj: remember I did some changes this week, you updated the branch and all, but no package was built from the new source it seems
<iwj> fschoep: Oh, I seem to have forgotten to actually do the upload.  Sorry.
<fschoep> iwj: right, that part I was talking about ;)
<iwj> It's done now.
<fschoep> iwj: no problem though, I imagine you have more important things right now
<fschoep> iwj: thanks
<iwj> The theme testing (and hence upload) got tangled up with a firefox change.
<fschoep> Oh dear, not something that messes up the themes again I hope?
<fabbione> ajmitch: ping?
<Kamion> fschoep: I noticed that the search engine box icon and text entry box are misaligned; is that related?
<fschoep> Kamion: yes
<Kamion> good
<fschoep> Kamion: the new package should fix everything and more
<iwj> fschoep: No, I just couldn't test it straight after making it because my install's firefox was in a mess because I was doing a new ff at the same time.  When the ff was fixed all was well but I only uploaded ff and not the themes package.
<fschoep> iwj: I see, I hope all is well now and the fixed themes are in :)
<fschoep> iwj: thanks a ton as I probably already said
<Kamion> tfheen: FYI this firefox-themes-ubuntu changelog is:
<Kamion> +  * Updated to latest bzr (revno: 24), changes by Frank Schoep:
<Kamion> +    - Implemented pressed icon states for the main, small, bookmark
<Kamion> +      and help toolbar
<Kamion> +    - Added a renderDarkened() function to render pressed icon versions.
<tfheen> fschoep: what bugs does that touch?
<fschoep> These:
<Kamion> fschoep: weird that $pressed and $disabled are different ways round in createbookmarks and createhelp
<Kamion> fschoep: is that an artifact of the Mozilla API?
<fschoep> Bug 65196
<Ubugtu> Malone bug 65196 in firefox-themes-ubuntu "[Edgy]  New Firefox 2.0rc2 looks ugly with Human theme" [Unknown,Fix released]  http://launchpad.net/bugs/65196
<fschoep> And 64472
<fschoep> Bug 64472
<Ubugtu> Malone bug 64472 in firefox-themes-ubuntu "Icons dissapear when mouse is clicked and held down" [Medium,Fix released]  http://launchpad.net/bugs/64472
<fschoep> Kamion: I don't know what goes on in the mind of those Mozilla folks
<fschoep> Kamion: I just look at what they want and work from there
<fschoep> Kamion: a lot of things are inconsistent
<Kamion> fschoep: as long as it's intentional
<fschoep> Kamion: it is, but I'm pretty sure that the bookmarks thing is a bug in Firefox
<fschoep> Kamion: I just copied their behaviour
<fschoep> Kamion: the default theme with disabled buttons looks like crap, so mine do too
<Kamion> tfheen: I'd like to do *something* about the theme definitely - the most recent version looks a lot worse
<tfheen> Kamion: ok, approved.
<fschoep> Kamion: 0.5.4 is *worse*?
<fschoep> than 0.5.3?
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/firefox-themes-ubuntu.diff
<Kamion> fschoep: no, 0.5.3 is worse than earlier themes
<pitti> tfheen: FYI, my own milestone bug list is empty now; I'll look into the other milestone bugs, unless you have something specific for me
<fschoep> Kamion: that's because of Firefox moving to RC2
<Kamion> yeah, I realise that
<fschoep> Kamion: they tend to break theme stuff all the time :)
<Kamion> sorry, 0.5.3 + rc2
<Kamion> I've accepted 0.5.4
<fschoep> OK, great - it looks a lot better
<fschoep> Matt also asked if we could make the Human one default?
<fschoep> I think iwj and the Xubuntu guy(s) looked at that earlier
<pitti> tfheen: ok for me to fix bug 61184? it only affects certain Thinkpads, but it's easy to fix (no code, just FDI changes)
<Ubugtu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  http://launchpad.net/bugs/61184
<Keybuk> chilly in here, today
<tfheen> Kamion: the firefox-themes-ubuntu build-deps on php?
* tfheen chokes
<fschoep> tfheen: shoot me
<fschoep> tfheen: I used PHP to script the theme building and it works
<tfheen> oh well
<fschoep> tfheen: it's maintainable
<tfheen> fschoep: I won't enter a discussion about PHP with you with fear of causing permanent bodily harm to you.
<fschoep> tfheen: iwj probably wants me dead for it, but it was the first bit of code I wrote for Ubuntu in a voluntary fashion
<tfheen> s/with/for/
<fschoep> tfheen: please don't look at the makefile that builds a debian package
<tfheen> Kamion: it looks good enough to me, the bookmarks bit is strange, but if that's how it works, that's how it works..
<fschoep> tfheen: it's that way in the default theme
<fschoep> tfheen: I just mimic what they want
<tfheen> pitti: yay, excellent.  Please do attack the list of unassigned milestone bugs, yes.
<tfheen> Keybuk: why did you add linuxprinting.org-ppds to -desktop?
<Kamion> tfheen: am I waving through unapproved universe uploads?
<Kamion> I can always do a quick review of them myself
<tfheen> dholbach: ^^
<Keybuk> tfheen: I did?
<Keybuk> was it one of those that went from a depends to a recommends
<Keybuk> and was originally held in main because of that?
<Keybuk> that's most likely
<tfheen> Keybuk: no, main is fine, desktop isn't fine.
<Keybuk> tfheen: it was a dep of something in desktop in dapper
<tfheen> I explicitly moved it from Depends to Recommends in order for it not to be in desktop.
<tfheen> it wasn't in dapper, iirc
<Keybuk> oh, I see
<Keybuk> then move it to supported :)
<tfheen> 'k
<Keybuk> I couldn't find any rationale for it vanishing, so thought it was just an accident
<Keybuk> or even move it to universe
<Keybuk> I tend to assume that if something is in main, was a depends, became a recommends, but didn't also get demoted -- that it was an accident, rather than deliberate
<dholbach> Kamion, tfheen: if ajmitch, siretart and I got a list of universe uploads we could check if they got Universe/Upstream/Upload/U... approval before
<tfheen> yeah, supported is fine.
<Kamion> dholbach: your xdg-utils patch updates are wrong - they produce duplicate code in xdg-email at least
<dholbach> Kamion: uh? I'll double-check
<infinity> pitti: Thanks for the libtasn FTBFS fix.  How do you feel about hunting a tar test suite failure on i386? :)
<Kamion> dholbach: could you upload -0ubuntu2 correcting that?
<dholbach> Kamion: sure, in a bit
<pitti> infinity: can do, as long as I have the necessary stuff on ronne
<infinity> Build-Depends: debhelper (>> 5), gettext, autoconf, autotools-dev
<pitti> infinity: any details?
<infinity> Should be okay. :)
<Kamion> dholbach: it could be it was an older update that broke it, I don't know
<pitti> yeah
<Kamion> but either way, it's wrong :)
<infinity> pitti: I'll bounce you the log.
<dholbach> Kamion: just looking at libflaim and libxflaim that Mark wanted to see go in - i'll do xdg-utils after that
<Kamion> dholbach: currently the list is xdg-utils and gnome-phone-manager; I'm looking at the latter now
<Kamion> gnome-phone-manager is fine, accepted
<dholbach> Kamion: thanks a lot
<pitti> infinity: can you please try a give-back on gnat-gps on i386? a local rebuild doesn't have that linking problem and it worked on other arches
<infinity> pitti: It's been tried a few times.
<pitti> oh, ok
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.2.0.diff <- OK to upload? most of the changes to incorporated source packages aren't very relevant; I wouldn't mind a second eye on the orca change down near the end though
<pitti> infinity: tar test suite works fine on ronne/i386, btw
<infinity> pitti: Cock.  Really?  It fails on my laptop and on the buildds.
<infinity> pitti: I thought it might be kernel-related, but the laptop is an edgy kernel, and the buildd it fails on is 2.6.15... Hrm.
<infinity> pitti: Oh, wait, but ronne isn't a real i386, so it could still be kernel.
<pitti> infinity: I can install an i386 dapper to track it down, will just take a bit
<infinity> pitti: I can track it later, I'm just trying to pawn off some stuff 'cause it's late for me. :)
<pitti> infinity: trying on my i386 server now (but that has 2.6.18 custom upstream kernel)
<dholbach> tfheen: it seems that kdebluetooth needs changes to be happy with libbluetooth 3.7
<dholbach> tfheen: and we got a bug report about passkey stuff for kde - not sure how to handle that one
<dholbach> tfheen: debian just had an upload for the kdebluetooth <-> bluez-libs 3.7 fixage
<tfheen> Kamion: it looks correct to me.
<tfheen> dholbach: how big are the changes?
<dholbach> tfheen: hang on
<Kamion> good good, I was paranoid with try
<tfheen> Kamion: yeah, you could have skipped the outer finally and just have let cmdline go out of scope
<tfheen> Kamion: but what you have there should be good
<Kamion> I don't trust python's gc to close files when they go out of scope
<Kamion> IME it doesn't do so reliably
<cbx33> seb128: Hi - I there is a bug with pessulus
<seb128> cbx33: hi
<cbx33> it is broken
<seb128> cbx33: which one?
<Kamion> I've had ubiquity bugs in the past due to leaked fds from files I thought had been automatically closed
<cbx33> because the file I created in the patch...
<cbx33> the gconfapplierscp
<cbx33> is not present on thesystem
<cbx33> gconflockdownapplierscp
<cbx33> it's in the diff....but never gets installed
* Kamion hands cbx33 some punctuation
<cbx33> sorry Kamion ..... /me is all in a panic now...
<dholbach> tfheen: http://people.ubuntu.com/~dholbach/kdebluetooth-debian.debdiff
<Kamion> I mean for your program names :-)
<seb128> cbx33: I don't understand the issue, do you have a patch?
<dholbach> tfheen: but it needs merging into our package and testing (and it doesn't fix the bluetooth passkey kde issue)
<cbx33> oh....was following convention in package ;)
<cbx33> http://archive.ubuntu.com/ubuntu/pool/main/p/pessulus/pessulus_2.16.1-0ubuntu1.diff.gz - is the latest diff right? - in tehre I create a file called Pessulus/lockdownappliergconfscp.py
<cbx33> but I must not have added it to the install file
<cbx33> so it gets created but nuver installed
<cbx33> does that make sense?
<tfheen> dholbach: looks safe enough to me -- Riddell, can you take a look at http://people.ubuntu.com/~dholbach/kdebluetooth-debian.debdiff and see if you'd want it in?
<Kamion> Keybuk: I was up hideously late last night and need a bit of rest now. Can you take over the unapproved queue? The xdg-utils upload in there has some wrong bits in the xdg-email patch - I've asked dholbach to fix that
<Kamion> deliberately leaving it in the queue for comparison purposes
<Keybuk> Kamion: yup, was just talking to Tollef about that
<Kamion> ok
<dholbach> Kamion: thanks a lot again - take your time resting!
<Kamion> phone me if the sky falls in
<cbx33> seb128: what file would I edit to make it install the new module....?
<tfheen> dholbach: would you agree that we close the door for NEW packages now?  Unless they're fixing critical bugs, that is.
<Riddell> tfheen: yes please
<pitti> infinity: ah, I get the tar issue on my i386 sarge server; I'll look into it
<Riddell> dholbach: although shouldn't it be a patch in debian/patches?
<seb128> cbx33: I'll have a look in a moment
<tfheen> Riddell: do you have any thoughts on the "kde doesn't have a passkey helper" problem?
<cbx33> ok np
<Keybuk> tfheen: gettext decision time? :)
<pitti> infinity: (interesting, it works on proper sarge and fails in edgy chroot)
<Riddell> tfheen: got a bug number?
<tfheen> dholbach: ^^ kde pin helper bug no?
<dholbach> Riddell: that's the raw debian debdiff
<dholbach> Riddell: as of 20 minutes ago in incoming.debian.org
<dholbach> Riddell: I'll make it nice and pretty
<tfheen> Keybuk: 
<tfheen> argh
<dholbach> tfheen, Riddell: bug 56651
<Ubugtu> Malone bug 56651 in bluez-utils "Missing passkey-agent binary" [Unknown,Fix released]  http://launchpad.net/bugs/56651
<tfheen> Keybuk: I'm tempted to ask Adam to spend copious amounts of his free time on hacking the RCS files since I'm worried about bumping the version at this point.
<Keybuk> tfheen: I'm inclined to suggest that given Adam and I have spend n hours trying to patch 0.14, without success, any potential success would be more error-prone at this point than just an update to a known "ok" version
<tfheen> that's a point, too.
<tfheen> but a 21MB diff _scares_ me.
<Keybuk> the new version would only affect packages will called "gettextize" or "autopoint" in their build process
<Keybuk> fwict, most of the diff is support for new languages and updates to the hello files
<iwj> tfheen: Just FAOD, I take it it's OK to upload a new firefox which attempts to help workaround the compreg.dat problem by deleting the file, as described in my last comment in bug 30791 ?
<Ubugtu> Malone bug 30791 in firefox "firefox 1.4.99 upgrade still have compreg.dat, creates issue" [Medium,Confirmed]  http://launchpad.net/bugs/30791
<tfheen> iwj: ok, approved.
<iwj> tfheen: Thanks.
<tfheen> Keybuk: *sigh*, I'll hate myself for this when the build failures haunt us, but ok.  New version.
<Keybuk> tfheen: I sympathise, but I do think that's less hate than all the Ubuntu-using upstream developers shipping lots of broken tarballs
<tfheen> yes, they'll hate us even more.
<Riddell> dholbach: any idea how it decides which bluetooth passkey agent to run?
<tfheen> Riddell: iirc it uses dbus activation
<Riddell> dholbach: I'm sure we had this in previous releases, where it's a bash script that would run /usr/lib/kdebluetooth/kbluepin if it existed, else the gnome one
<Riddell> hmm, dbus sounds new
<dholbach> Riddell: i'll take care of the ftbfs/compatibility fix now and take a brief look at it after that - I have no idea at all
<dholbach> tfheen: we still need to seed bluez-passkey-gnome (once it's out of MIR)
<tfheen> dholbach: you've written the report?
<dholbach> tfheen: ARRR!
<tfheen> dholbach: was that a "yes"?
<dholbach> yes :-)
<tfheen> pitti: could you fast-track the bluez-passkey-gnome MIR?
<dholbach> I think I even said so, yesterday. For reference: https://wiki.ubuntu.com/MainInclusionReportBluezGnome
<fabbione> doko_, mvo: dpkg: error processing python-apt (--purge):
<fabbione>  subprocess pre-removal script returned error exit status 1
<pitti> tfheen: doing now
<doko_> fabbione: on a buildd?
<fabbione> doko_: yes
<doko_> fabbione: please point me to the log
<fabbione> doko_: check your email :)
<doko_> thanks
<fabbione> doko_: it's not a buildd in LP.. it's local sparc rebuild the world
<fabbione> but the chroots are the same
<mvo> fabbione: oh jesus - do you have logs? that smells like python-central
<Keybuk> Configuration file `/etc/init.d/bluetooth'
<mvo> fabbione: can you pleae CC me too?
<Keybuk> Configuration file `/etc/init.d/bluetooth'
<Keybuk>  ==> Modified (by you or by a script) since installation.
<Keybuk>  ==> Package distributor has shipped an updated version.
<Keybuk> gnargh
<Keybuk> known?
<pitti> dholbach: what does this bt-applet do, in short?
<tfheen> Keybuk: I've seen it, but I have no idea why it happened.
<fabbione> mvo: on the way to you too
<pitti> dholbach: store PINs and ask for them if it doesn't know it yet?
<mvo> fabbione: thanks!
<dholbach> pitti: notify you, if another device wants to pair with the box over bluetooth and lets you enter a pin
<pitti> dholbach: ah, ok; it's just a frontend for the bluez tools, I assume?
<Keybuk>   108806 | S- | poppler              | 0.5.4-0ubuntu4       | four minutes
<Keybuk>          | * poppler/0.5.4-0ubuntu4 Component: main Section: text
<Keybuk>   108804 | S- | libflaim             | 4.9.966-0ubuntu1     | nine minutes
<Keybuk>          | * libflaim/4.9.966-0ubuntu1 Component: universe Section: libs
<iwj> seb128: http://paste.ubuntu-nl.org/26419/, opinion ?
<Keybuk>   108805 | S- | libxflaim            | 5.1.969-0ubuntu1     | ten minutes
<Keybuk>          | * libxflaim/5.1.969-0ubuntu1 Component: main Section: libs
<tfheen> Keybuk: if that poppler has "fixes FTBFS" in the changelog, it's approved.
<Keybuk> tfheen: dholbach said libflaim and libxflaim were things Mark wanted?
<seb128> iwj: looks good to me
<tfheen> Keybuk: yes.  => universe, though
<Keybuk> *nods*
<Keybuk> tfheen: poppler changelog contains only this
<Keybuk>    * Clean sources before upload
<Keybuk> Riddell: 
<tfheen> Keybuk: ok, good, and Riddell is the uploader?
<Keybuk> yes
<tfheen> approved.
<tfheen> (there was a config.status in the previous source package which caused a FTBFS)
<dholbach> pitti: It should be.
<pitti> tfheen: I didn't test bluez-passkey-gnome, but I trust dholbach that it actually works; packaging-wise it's fine
<dholbach> it works
<tfheen> pitti: it worked for me.
<dholbach> and Upstream is in the bluetooth team as well
<Keybuk> brb
* pitti presses his approval stamp onto the report
<dholbach> so he'd know pretty quickly if stuff was broken :)
<dholbach> Riddell: http://people.ubuntu.com/~dholbach/kdebluetooth-ubuntu.debdiff - that's the diff I'm going to apply - currently testbuilding
<Keybuk> seb128: panel crashed on update again
<Keybuk> dholbach: why is there a useless bluetooth logo in my notification area?
<seb128> Keybuk: what did you update?
<Keybuk> BenC: still got a floating "kernel direct mapping up to" message on the screen at boot
<dholbach> Keybuk: that's the bluez-passkey-gnome thing
<Keybuk> seb128: http://people.ubuntu.com/~scott/upgrade.txt
<dholbach> Keybuk: you can either remove the package or disable it in gnome-session-properties
<Keybuk> dholbach: yes, why does it have an icon?  the icon doesn't do anything
<dholbach> Keybuk: that's the best I can offer, sorry
<Kaloz> the new xubuntu gdm thema makes me sick :P i hope the old one will be available :P
<Keybuk> can't you comment out the icon code?
<seb128> hum, lot of upgrades :/
<dholbach> Keybuk: I'd prefer if upstream would do that in a clever and proper way.
<seb128> Keybuk: are the applet still working, context menu on them working, etc?
<Keybuk> seb128: the context menu still worked, but couldn't click anything
<cbx33> I kept getting panel applets crashing
<Keybuk> the main menu worked too, but again, couldn't launch anything
<Keybuk> some notification icon applets vanished at the point of crash
<dholbach> Keybuk: bug 65645
<Ubugtu> Malone bug 65645 in gnome-bluetooth "Die systray icon die!" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65645
<seb128> hum :/
<cbx33> for exmaple terminal services applet wou'dnt load
<cbx33> still doesn't 
<seb128> cbx33: I've fixed that applet yesterday, do you still get the isuse?
<Riddell> dholbach: looks good
<cbx33> just gonna reboot and test
<dholbach> Riddell: gracias
<cbx33> I had it with the new note taker a few times too
<cbx33> seb128: I'll be right back
<Keybuk> usplash is still borked too :-/
<infinity> pitti: You have a weird definition of the word "interesting". :/
<dholbach> pitti, tfheen: I seed bluez-gnome to supported, alright?
<tfheen> dholbach: please
<dholbach> tfheen: ok
<cbx33> seb128: it's fixed now ;)
<cbx33> sorry for the scare
<cbx33> the tsclient applet
<seb128> np
<seb128> thank you for trying :)
<cbx33> tomboy notes was doing it but seems fine now too
<cbx33> I did try to look at the pessulus package to see how to fix it....but coudn't see what is up.....must be me being stupid
<cbx33> I have to go and teach a python class now
<cbx33> bbl
<seb128> cbx33: I've pessulus fixed, I'm about to upload
<seb128> tfheen: http://people.ubuntu.com/~seb128/pessulus.debdiff ok to upload?
<seb128> tfheen: it's basically one file added to the Makefile.in list
<Keybuk> seb128: they really haven't put much thought into this new rhythmbox, have they?
<Keybuk> it has to rescan portable media every time you start it
<Keybuk> so it's indexing the same 40GB again, and again, and again
<tfheen> seb128: ok, approved.
<ogra> hmm, i have either a udev or a kernel regression here ...
<Keybuk> and it even forgets the fact I like the browser open for that media
<Keybuk> ogra: kernel
<ogra> Keybuk: heh
<ogra> my external usbdisk isnt recognized with the usb hub in the chain 
<seb128> Keybuk: it's like that since ever
<Keybuk> seb128: not true, the dapper rhythmbox - you had to add your player to the library
<seb128> Keybuk: rescanning removable media every time
<Keybuk> and then it was always available when it started
<ogra> it works fine without the hub ...
<Fujitsu> Keybuk, I /could/ suggest you file a bug... But I think I'd get attacked.
<Keybuk> ogra: usb 2 disk, usb 1 hub
<ogra> Keybuk: both should be usb2
<ogra> and it worked before
<ogra> must be the last kernel upload i guess
<Keybuk> have you checked with the previous kernel?
<dholbach> tfheen: done
<ogra> it worked on my outdated system (i'm typing from a test install of 20061012)
<Keybuk> Fujitsu: bugs already exist
<ogra> Keybuk: linux-image-2.6.17-10-386        2.6.17-10.28 is the one installed in my old system, ii  linux-image-2.6.17-10-386        2.6.17-10.30 is what the fresh install brought 
<Keybuk> ogra: ok, so boot .28 then and see if that makes a difference
<ogra> and udev has teh same version ... so i guess its a change in the recent kernel
<Keybuk> it's nothing to do with udev
<Keybuk> sheesh
<Keybuk> stop blaming udev for every hardware glitch you encounter
<Keybuk> udev receives uevents from the kernel, and processes rules for them
<Keybuk> nothing more
<Keybuk> if you have strange topological errors with usb devices, it's hardware or kernel
<ogra> right
<Keybuk> if a device has the wrong permissions, then it's a udev bug
<Keybuk> if a device has the wrong name, then it's a udev bug
<Keybuk> if a device doesn't show up at all, then it's almost certainly a kernel bug
<ogra> but tracking that bug top down, i start at udev because i know the scripts arent run ... then look at why it doesnt get triggered ...
<ogra> so indeed i mention udev as well :)
* antoniac is away: Gone away for now.
<Hobbsee> antoniac: please remove the away message.
<Keybuk> Hobbsee: probably wise to mention that when he's back, no? :)
<Hobbsee> Keybuk: i figured removing him with that as his removal message was a little brutal.  but that's what i usually do.  :)
<tfheen> Hobbsee: doit! :-)
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<Hobbsee> tfheen: remove you too?
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<Hobbsee> :P
<\sh> mons
<\sh> +i
<Hobbsee> hey \sh 
<Hobbsee> Keybuk: there :P
<tfheen> Hobbsee: nah, I'm nice, you know that.
<ogra> would be a bit hard to get the RC done 
<\sh> sladen: regarding you bugreport #63492 what would you propose? security or usability?
<infinity> pitti: Another dbgsyms build failure...
<dholbach> Riddell, tfheen: i just did a successful file transfer from the box to the phone with konqueror (using kdebluetooth) - ok to upload?
<pitti> infinity: still thinking about the tar issue; that seems to be a real bug, and I think I have a vague idea now
<pitti> infinity: can you please forward the log? I'll care for it after tar
<infinity> pitti: Yeah, It's gcc-4.0, so it's a slightly large log. :/
<pitti> ouch
<infinity> pitti: You might just want an extract. :)
<pitti> infinity: or just copy it on chinstrap
<Hobbsee> tfheen: :)
<tfheen> Kamion: the d-i build blew up on i386
<tfheen> Kamion: .. and all other arches
<Fujitsu> Fun fun fun.
<Riddell> dholbach: more than I've ever done, go ahead :)
<dholbach> alrighty
<dholbach> done
<Keybuk>   108809 | S- | firefox              | 1.99+2.0rc2+dfsg-0ub | 17 minutes
<Keybuk>          | * firefox/1.99+2.0rc2+dfsg-0ubuntu2 Component: main Section: web
<tfheen> Keybuk: iwj upload with changelog along the lines of "nuke compreg.dat in postinst"?
<tfheen> Keybuk: if so, approved.
<Keybuk> tyup
<Riddell> dholbach: there's a patch to bluez-utils to let it still work with the current kdebluetooth pin helper
<Riddell> dholbach: http://www.kmobiletools.org/node/228
<Riddell> dholbach: there's also a dbus branch in the works but I think we don't want to try beta code at this stage
<dholbach> Riddell: you want to look at that? i do xdg-utils in the meantime
<Riddell> dholbach: well I have no bluetooth hardware at all to test with
<Ng> if you guys want a hand testing bluetooth stuff, I have suitable hardware and a desire to see it rock as hard as possible :)
<pitti> Ng: can never hurt :)
<jsgotangco> bt rocks
<infinity> tfheen: I'm approving a new pkg-create-dbgsyms disabling an anal build-time check that causes several build failures (we'll re-enable the anal check in edgy+1 again to catch the affected packages, but the bug it's catching isn't worth uploading them all for)
<tfheen> infinity: thanks
<tfheen> Keybuk: can you tend to https://launchpad.net/distros/ubuntu/+source/gettext/+bug/65063 please?
<pitti> Keybuk, tfheen: I need to upload another pkg-create-dbgsym with a removed sanity check which causes gcc-4.0 and maybe others to FTBFS; we don't want to fix those packages at this point
<Ubugtu> Malone bug 65063 in gettext "Doesn't support datarootdir" [High,Confirmed]  
<infinity> tfheen: Basically, packages that call dh_strip on binaries not actually being built (say, gcc-4.0 and lib64stdc++6)
<dholbach> tfheen: Riddell proposes to use http://people.ubuntu.com/~dholbach/bluez-pin-exec-patch.diff on bluez-utils as an attempt to fix bug 56651 for kde - I can't make heads nor tails of the patch to be honest - I can see if it builds and see how it behaves with ubuntu and kde
<Ubugtu> Malone bug 56651 in bluez-utils "Missing passkey-agent binary" [Unknown,Fix released]  http://launchpad.net/bugs/56651
<infinity> pitti: Upload at will. :)
<pitti> done
<infinity> And util-linux is another asm/page.h victim, I'll fix that one.
<tfheen> dholbach: hmkay.  I understand what and how the patch works.  It's an ugly hack, but we don't want to ship without bluetooth support in KDE either.
<dholbach> tfheen: I'll get testing and playing with it
<Riddell> it seems to need something to start passkey-agent
<tfheen> we'd still need to actually ship the passkey helper
<dholbach> Riddell: if you want, you can do xdg-utils in the meantime - can you upload as 0ubuntu2 so kamion/keybuk can compare with the old upload?
<tfheen> which we don't ATM
<Riddell> dholbach: I'd rather see the 0ubuntu1 upload first to see how they compare
<dholbach> Riddell: hang on
<infinity> pitti: accepted.
<cbx33> thanks seb128 tfheen
<dholbach> Riddell: http://daniel.holba.ch/temp/xdg-utils_1.0-0ubuntu1.debdiff
<Keybuk> tfheen: "tend to" ?
<tfheen> Keybuk: get the new version in?
<Keybuk> tfheen: am in the process of testing and making sure it's ship-shape at the moment
<Keybuk> obviously I didn't want to just download the new one and chuck it in without even checking it against a few packages first
<tfheen> Keybuk: ok, excellent.  That's is as good a tending to as I could ask for.
<tfheen> mvo: did you get the necessary information to fix the duplicated hostid bug yesterday?
<mvo> tfheen: I have all the information we have, it may not be enough though and we may have to unconditionally reconfigure all popcon package to be sure that it is fixed
<tfheen> mvo: ok, if you're not busy with something else, can you please upload a package which does that?
<mvo> tfheen: let me dig a bit more into the logs, but I can do it in max. 1h
<tfheen> mvo: thanks
<tfheen> infinity: do you have any clue about 63693 ?
<seb128> cbx33: np, thank you for pointing it
<mvo> Kamion: what versions of popcon where not reconfigured on install from the live-cd? only edgy versions? or was that a problem in dapper too?
<ogra> pitti, hmm, the gstreamer autosink seems still buggy 
<ogra> i get reports from perple where it didnt select esd at all
<Riddell> dholbach, Kamion: I'm not sure where the duplicate code is in the xdg-utils patch xdg-email-generic
<dholbach> Riddell: we fixed the patch differently, I saw - could be my attempt was wrong
<seb128> tfheen: http://people.ubuntu.com/~seb128/xchat.debdiff : 3 simple crasher fixes from upstream for xchat-gnome, upstream asked if we can ship them (crasher tend to bugzilla flood with the new bug-buddy)
<Riddell> dholbach: out fix to the open_kde part is the same
<tfheen> seb128: shouldn't the first one return something if user is null?
<tfheen> seb128: the other two look good to me
<Riddell> dholbach, kamion: oh, I see it, open_generic() is duplicated, I'll fix that
<seb128> tfheen: right, is the first one ok if I make it return NULL in the case where there is no return atm?
<tfheen> seb128: yes, that should be good  (as long as whatever calls this handles a NULL return value)
<seb128> yeah, should be fine, there is already a case where it returns NULL
<seb128> I'll double check
<tfheen> then it's fine with me
<doko_> tfheen, Kamion, mvo: chinstrap:~doko/python-apt.debdiff: ok to upload to restore dep on python-central?
<tfheen> doko_: which bug does it fix?  (And can you please put patches somewhere web-accessible in the future?)
<doko_> tfheen: fabbione reported that on the channel, python-apt doesn't work without python-central installed.
<tfheen> doko_: hmm, ok.  I'm fine with it if mvo doesn't protest.
<tfheen> but please do file bugs in malone, I miss stuff going on in the channel once in a while.
<mvo> tfheen: fine with me (assuming doko_ tested it and everything)
<tfheen> doko_: ^^ so upload away.
<doko_> tfheen: uploaded
<Kamion> tfheen: meh, will investigate
<Kamion> mvo: I didn't start reconfiguring popularity-contest until 12 September; I think it was a problem in dapper
<Kamion> Riddell: was open_generic and something else about generic
<Keybuk>   108829 | S- | supertransball2      | 1.5-3build1          | 25 minutes
<Keybuk>          | * supertransball2/1.5-3build1 Component: universe Section: games
<Keybuk>   108827 | S- | tipa                 | 2:1.3-4build1        | 40 minutes
<Keybuk>          | * tipa/2:1.3-4build1 Component: universe Section: tex
<Keybuk>   108826 | S- | kdebluetooth         | 0.99+1.0beta1-12ubun | 50 minutes
<Keybuk>          | * kdebluetooth/0.99+1.0beta1-12ubuntu7 Component: main Section: kde
<Keybuk> dholbach: tipa by ajmitch, "rebuild with new debhelper to set versioned depends on xfonts-utils"
<Keybuk> dholbach: supertransball2 by StevenK, "rebuild to pick up libsdl-sgec2 -> liibsdl-sge change"
<tfheen> Keybuk: kdebluetooth is uploaded by dholbach and has something like "make kdebluetooth work with libbluetooth2 >= 3.7-1 ?
<Keybuk> tfheen: yes
<dholbach> Keybuk: tipa and supertransball2 are fine
<tfheen> Keybuk: ok, approved.
<Keybuk> okies
<mvo> Kamion: ok, thanks. then I will reconfigure the popcon uuid now on upgrade for all users. but after 20days (that is when the old entries are cleaned) we have reliable data again
<Keybuk> dholbach: flaim's gone through too
<Keybuk> I NBS'd the old binary as nothing used it
<Keybuk> (popular library)
<dholbach> Keybuk: tahnks a lot
<geser> should bug 63396 be targeted for edgy?
<Ubugtu> Malone bug 63396 in imake "Upgrading to edgy beta leavs imake and makedepend" [Medium,Confirmed]  http://launchpad.net/bugs/63396
<tfheen> geser: it already is?
<tfheen> Kamion: the xorg entries on http://people.ubuntu.com/~cjwatson/testing/edgy_outdate.txt ; are those false positives or is something broken and I don't see it?
<Keybuk> doko_: what was libintl.jar for?
<geser> tfheen: sorry then
<tfheen> Kamion: oh, or those are probably NBS-es?
<Kamion> yes, there are xorg NBSes I've been too scared to remove
<Kamion> though none of them are actually seeded
<doko_> Keybuk: that was gettext?
<Kamion> tfheen: weren't we going to put xbase-clients and xutils back, or am I hallucinating?
<tfheen> Kamion: at least xbase-clients, yes.
<Keybuk> doko_: yes, it vanished
<doko_> looking ...
<doko_> $ dpkg -L gettext-base|grep libintl
<doko_> /usr/share/java/libintl.jar
<doko_> /usr/share/gettext/libintl.jar
<doko_> Keybuk: ^^ ??
<Riddell> Kamion: if I upload a new xdg-utils 1.0 should I include the .orig?
<Kamion> Riddell: err, can't actually remember, shouldn't hurt to include it
<Keybuk> doko_: yes, 0.15 isn't building it
<Kamion> (provided it's the same, obviously)
<Keybuk> doko_: it has a gettext.jar instead
<Keybuk> which has different contents
* ogra cant find where pitti applied the LTSP specific bits in gstreamer :(
<pitti> ogra: can you please help me to remember the issue?
<tfheen> mjg59: ttf-bpg-georgian-fonts FTBFS-ed.
<doko_> Keybuk: is 0.15 for edgy?
<ogra> pitti, after first login the audiosink is set to alsa instead of gstreamer
<pitti> ogra: you mean s/gstreamer/esound/?
<ogra> i tried to find the patch that reads LTSP_CLIENT and forces esd usage, but i dont seem able to find it
<doko_> anyway, I'm not aware of any users for libintl.jar in main
<Keybuk> doko_: likely, yes
<ogra> pips1, right
<Keybuk> tbh, it looks like a build problem
<ogra> pitti, right
<pitti> ogra: hm, I applied that in dapper IIRC, maybe it got lost during the merge
<ogra> pitti, i thought you added a check for that variable somewhere, but i cant find it by grepping through the dapper package even
<ogra> pitti, is it in gst-plugins-base0.10-0.10.7 or in gnome-media ?
<pitti> ogra: should be the former
<ogra> nothing ... hmm
<tfheen> pitti: your latest xmms upload (yes, ancient) FTBFS-ed.  I retried it and it still failed.
<tfheen> pitti: could you give that a poke?
<pitti> tfheen: yup, I'm still debugging tar, though; will do after that
<tfheen> pitti: thanks.
<tfheen> hmm, is ZhengPeng Hou on irc and around?  There's a problem with scim-chewing.
<doko_> Keybuk: I don't see any gettext.jar in upstream gettext-0.15
<Hobbsee> tfheen: freeflying
<infinity> tfheen: I need to do a test install here in vmware to try to reproduce #63693, but if I can reproduce it, the fix should be simple and non-intrusive ehough.
<infinity> enough, too.
<Hobbsee> tfheen: not here at the moment
<tfheen> infinity: thanks a lot
* infinity packs up his laptop to ru nhome where he has bandwidth to do some uploads before the meeting.
<tfheen> Hobbsee: thanks.
<Hobbsee> infinity: uh?  where are you?
<doko_> Keybuk: ahh, that's gettext-tools, which isn't shipped in 0.14.
<tfheen> pitti: lucky you, you touched quagga last and win yet another FTBFS.  (Might be libc-header-related; only affects i386 and ppc, it seems)
<pitti> yay
<pitti> . o O { actually, why do I bother test-building stuff before I upload??? }
<tfheen> pitti: since it ftbfs anyway, you mean?
<pitti> tfheen: yes; well, since I only test on amd64, it evaded me precisely :)
<pitti> tfheen: added to my TODO list
<tfheen> doko_: python-setuptools FTBFS-ed
<ogra> pips1, intrestingly the code seems never to have looked for LTSP_CLIENT to be set, i'm courious how that worked before ...
<ogra> s/pips1/pitti
<ogra> *sigh*
<pitti> ogra: hm, ISTR that I patched this...
<ogra> your patch moves priorities around, but doesnt add any heck for LTSP_CLIENT
<ogra> *check
<Riddell> where is anastacia located these days?
<ogra> Riddell, still the same place ?
<Riddell> I have http://people.ubuntu.com/~mdz/anastacia.txt but it's not there
<ogra> http://people.ubuntu.com/~cjwatson/anastacia.txt (since dapper iirc)
<Keybuk> doko_: 0.15 doesn't seem to build any of the java stuff :-/  looks like its a bug in the upstream packaging
<doko_> Keybuk: I can have a look; do you have a preliminary package?
<doko_> tfheen: missing b-d on python-all-dev; ok to upload?
<Keybuk> doko_: I don't think having a look will help
<tfheen> doko_: yes, please.
<Keybuk> I can see what the problem is
<doko_> the sources are in the package
<Keybuk> the gettext-runtime subtree is missing things from its configure.ac
<tfheen> doko_: pychecker FTBFS as well
<Keybuk> though I don't understand how this works in Debian *shrug*
<elmo> Keybuk: !
<tfheen> doko_: python-qt[34]  FTBFS as well
<elmo> Keybuk: my home machine with a separate /var is still broken in edgy :-(
<doko_> tfheen: pychecker: proposing a sync from unstable; 0.8.17-3 passes the tests
<tfheen> doko_: you've tested it?  If so, I'm happy enough to take it.
<doko_> tfheen: yes, built, installed, removed, works
<Kamion> oh well, I haven't been able to test this d-i upload because I need to upgrade the world first, but it should fix the immediate problem
<tfheen> doko_: please ask for a sync, then.
<Keybuk> elmo: ?
<Keybuk> elmo: be more descriptive
<tfheen> Kamion: any chance you could do a quick NBS run?  There are a couple of obvious and harmless ones which will clean up the outdate list a bit
<Kamion> yeah
<tfheen> thanks
<Keybuk> doko_: it looks like they only support building the jar with javac, not with gcj
<troy_s> hey guys... great work on edgy.  
<Kamion> tfheen: do you know about compiz-kde? Can I remove that?
<tfheen> Kamion: no idea.
<tfheen> Riddell: ^^ ?
<Kamion> -- edgy/universe i386 deps on python2.4-libbtctl:
<Kamion> telepathy-blue
<Kamion> dholbach: can you or somebody fix that up?
<doko_> Keybuk: that's ok, gcj-4.1 registers an alternative for javac
<Keybuk> checking for Java compiler... no
<Keybuk> heh
<Keybuk> configure:4285: checking for Java compiler
<Keybuk> configure:4447: found /usr/bin/gcj
<Keybuk> configure:4534: gcj -C -d . conftestlib.java
<Keybuk> configure:4672: result: no
<infinity> Hobbsee: I'm at home, why do you ask?
<infinity> Hobbsee: Oh, you mean where *was* I?  My (ex-)wife's apartment.
<Hobbsee> infinity: yes, i asked where you were.  ahh.  couldnt see any logical place you'd be doign ubuntu stuff on a thursday night late at night apart from at home
* StevenK twitches.
<Kamion> BenC: please (a) tell me and (b) changelog it when you do stuff like renaming *-itanium-di to *-mckinley-ddi
<Kamion> -di
<Kamion> BenC: is that really a good plan, BTW?
<Kamion> at this stage?
<infinity> Hobbsee: I lead a strange and interesting life with two homes right now.  Her DSL sucks, though.
<StevenK> infinity: Doing Ubuntu work at my mothers house is like that.
<StevenK> Sucky 256/64 connection.
<Riddell> Kamion, tfheen: I know nothing about compiz-kde, although it was only every a placeholder package so I don't suppose we're loosing anything by deleting it
<infinity> StevenK: 512/128 at Zofia's, but with the recent death of Veridas, her new ISP is congested and unhappy, so it may as well be 256/64.
<Keybuk> doko_: heh, it looks increasingly like this assumed that gcj's version is 3.x and tries to parse it :)
<Keybuk> and thus fails when it's 4.x
<Kamion> BenC: actually, never mind, I'm hallucinating with the aid of the cruft checker :-)
<Hobbsee> infinity: ahh.
<StevenK> infinity: I could suggest Exetel. :-P
<Kamion> I think it just gets really confused when the kernel hasn't built
<tfheen> Kamion: ok, nuke compiz-kde, then
<Kamion> done
<Kamion> tfheen: shall I get rid off xlibs-dev?
<Kamion> s/off/of/
<tfheen> Kamion: no, I'll talk with rodarvus about it at the meeting, if he's there.
<tfheen> (or tomorrow if not)
<infinity> StevenK: I'm pretty happy with iinet, but I'm paying for the connection at her place, and wasn't thrilled about the idea of dropping that much on two ADSL2+ lines.
<mvo> tfheen: could you please have a look at http://people.ubuntu.com/~mvo/tmp/popularity-contest_1.33ubuntu2.debdiff 
<StevenK> infinity: Good point.
* StevenK will be switching to ADSL2+ when he can afford the $300 it will cost.
<Kamion> tfheen: ok, then it's just libbtctl (dependency from telepathy-blue), libgtkada2 (dependency from gnat-gps), linux-source-2.6.17 ia64 udebs (weird, don't understand), and xorg
<Kamion> (xbase-clients, xlibs-dev, xutils)
* infinity grumbles at "rgrep PAGE_SIZE" in util-linux, and starts patching..
<tfheen> mvo: your changelog doesn't document both changes you're doing?
<tfheen> Kamion: thanks a lot.
<mvo> tfheen: right, I will mention the fix for the FTBFS as well
<tfheen> mvo: good.  And approved once you do
<mvo> thanks
<seb128> tfheen: http://people.ubuntu.com/~seb128/evolution-data-server.debdiff fixed evolution-exchange bug targeted for edgy (subfolders not being listed)
<tfheen> seb128: and it works?  If so, approved.
<tfheen> it's small enough, but I don't know the intracies of exchange, so hard to review
<seb128> tfheen: it works according to Novell guys, I've no exchange setup to test
<seb128> tfheen: it's basically a revert from the commit which broke the feature with a small change
<tfheen> seb128: ok, approved.
<seb128> uploaded, thank you
<Kamion> hmm, we should either include ttf-dzongkha and ttf-khmeros in desktop, or exclude those languages from ubiquity
<Kamion> they probably want to be in main, at least, so that language-support-* can depend on them
<tfheen> Keybuk: can you make cyrus-sasl2 use libkrb-dev instead of heimdal-dev?  It FTBFS.
<tfheen> Keybuk: and can you make fetchmail not ftbfs, please?
<tfheen> and with that, I'm going home for some food before the meeting.
<Keybuk> W: Unable to locate package libkrb-dev
<tfheen> libkrb5-dev, sorry
<dholbach> Kamion: alright, will do it - thanks.
<dholbach> Kamion, Keybuk: can you promote bluez-gnome to main?
<jsgotangco> yes!
<mvo> tfheen: popularity-contest is uploaded now
<dholbach> can somebody give back galago-gtk-python?
<pitti> tfheen: xmms ftbfs fix uploaded
<seb128> tfheen: opinion on https://launchpad.net/distros/ubuntu/+source/launchpad-integration/+bug/60426 edgy or next cycle?
<Ubugtu> Malone bug 60426 in launchpad-integration "uses gnome prefs if kde and gnome are installed." [Low,Fix committed]  
<Riddell> seb128: in edgy+1 it should use xdg-utils
<seb128> Riddell: right, but do you need the "workaround" for edgy?
<BenC> has the installer been rebuilt with the latest kernel yet?
<Kamion> BenC: I've uploaded it, should be building soon
<BenC> Kamion: cool, thanks
<jdong> Kamion: is it a known alternate installer problem that atheros cards do not function at install time?
<infinity> BenC: Feel like looking at some devmapper-hates-the-kernel-headers FTBFS logs for me?
<ogra> tfheen, there is an edubuntu-artwork upload in the queue ... could you please approve it (do i need a debdiff for it ?)
<jdong> Kamion: I tried a search through launchpad, and learned that I suck at searching :)
<BenC> infinity: Sure
<BenC> infinity: URL?
<Kamion> dholbach: done
<infinity> BenC: Email.  Which address should I send them to?
<BenC> jdong: No, lp sucks at matching
<dholbach> Kamion: thanks.
<Kamion> jdong: it was in ~breezy, but should be fixed; is /lib/modules/blah/volatile mounted in the installedd?
<Kamion> installer
<BenC> infinity: Any known email address is fine (bcollins@ubuntu.com), they al go to my inbox :)
<jdong> Kamion: I gotta check when I get a chance, but I did an alternate edgy amd64 install yesterday....
<jdong> Kamion: it detects the card and gives an ath0 interface, it associates to my AP correctly
<jdong> Kamion: but there is no communication with the network
<jdong> after install, it worked perfectly
<Kamion> that sounds like missing firmware or something
<BenC> jdong: Check to make sure linux-restricted-modules-`uname -r` is installed
<infinity> Gar, Perl testsuite failure on amd64..
<infinity> ext/Time/HiRes/t/HiRes....................FAILED at test 14
<jdong> BenC: on the installer?!
<Kamion> dunno though, the module's there
<jdong> right, the modules there and probed
<jdong> the ath0 interface is created
<Keybuk> BenC: any clue as to my strange kernel message?
<infinity> BenC: Sent.
<Kamion> jdong: ath_hal too?
<jdong> yeah
<BenC> jdong: I thought you said the installed system is broke, and the livecd worked
<BenC> Keybuk: I missed it, can you repaste?
<jdong> BenC: no, the installer environment is broke, the installed AND live both works
<Keybuk> BenC: when the kernel boots, the last line on the screen is "kernel direct mapping tables up to BLAH BLAH BLAH"
<BenC> jdong: so like alternate is broken?
<jdong> BenC: right
<Keybuk> and that line persists, all through the boot, and even after the getty is loaded
<jdong> Keybuk: I get that on my amd64 boxes too
<BenC> jdong: There's an lrm udeb for this stuff, I think
<infinity> That's pretty sketchy, since nic-r-m and l-r-m contain exactly the same objects...
<Kamion> there is, and he has it loaded
<infinity> And if the objects weren't linking correctly, you'd not get an ath0 at all.
<BenC> Keybuk: persists or repeats?
<jdong> BenC: persists
<jdong> BenC: it's stuck on the bottom of vt1 for ever and ever and ever.....
<doko_> tfheen, Kamion: http://people.ubuntu.com/~doko/qt/, fixing the qt failures
<jdong> BenC: it seems to only happen on amd64 though....
<Keybuk> BenC: I suspect it's just printed there, and nothing gets round to clearing that line with our quiet boot
<BenC> Keybuk: Not clearing it would be a console-setup issue, right?
<Keybuk> BenC: it shouldn't be printed at all
<Keybuk> we don't run "clear" in the boot sequence for obvious reasons
<BenC> Keybuk: I can fix the line, if you give me the exact message
<Keybuk> "kernel direct mapping tables up to %d"
<Keybuk> or %lu or some numbers, anyway
<jdong> it's a hex number
<jdong> memory address, I would think
<BenC> hrmm
<BenC> that's an "early_printk"...
<Keybuk> Google says it's part of Xen ?
<BenC> Keybuk: Ok, fixed...nope, it's not part of xen that I can tell (no xen here)
<Keybuk> ok
<BenC> Keybuk: If I do another kernel upload, it will be fixed
<zul> xen eh?
<Keybuk> zul: the top hit was [xen-source]  :)
<jdong> BenC: you can revert the GO_SLOW, too
<jdong> and hey hey, Keybuk's here...
<Keybuk> ?
<Keybuk> keybuk's always here
<Keybuk> keybuk works here
<elmo> Keybuk: remember eons ago when you diagnosed dapper not bringing up the network on my machine?  it's because I have a small / and a RAID 0 which has var on it.  this confuses the jiggery pokery you do with /var/run/network (or wahtever it is)
<jdong> Keybuk: what's your opinion on doing max_sector workarounds in userspace via udev rules?
<Keybuk> elmo: why does it confuse it?
<Keybuk> jdong: poking sysfs from udev rules?  common use case
<zul> Keybuk: top hit for what sorry i have people talking me at work
<Keybuk> zul: don't worry
<jdong> Keybuk: ooh, then bug 61235 is awaiting you :D
<Ubugtu> Malone bug 61235 in udev "USB mass storage stops working after a while" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61235
<zul> Keybuk: er ok :)
<Keybuk> jdong: edgy+1
<elmo> Keybuk: meh, I've no idea, I'll go and find it in IRC logs I guess
<jdong> aww ok :(
<Keybuk> jdong: also it appears that only fixes it for you, not for others on the bug
<Keybuk> elmo: you have a /var/run and /var/lock directory on the root filesystem?  (under the /var mount)
<zul> where is the popcon stats anyways?
<jdong> Keybuk: yeah, at first I thought it was the same bug but later realized differently
<thom> zul: popcon.ubuntu.com ?
<zul> thanks
<thom> cor, someone's pimped that webpage
<elmo> Keybuk: I think we determined I did, yeah, you had me run some bind magic
<Keybuk> jdong: should be echo -n 128 > $p/max_sectors, no?
<Keybuk> elmo: ok ...
<tfheen> seb128: lp-integration > that is 6.10-milestoned.  Did you or mdz or somebody else add that milestone?
<jdong> Keybuk: something along those lines; the last comment is the udev rule I came up with
<jdong> Keybuk: it looks really hairy, so I'm sure I did something wrong :D
<Keybuk> jdong: I'd like more info about the effect of that rule before applying it by default
<seb128> tfheen: no, I think I did, I use milestone as a "keep on the radar for", not as "blocker for"
<tfheen> doko_: python-kde3, python-qt[34]  ok with me ; upload away.
<jdong> Keybuk: only for RockChip USB devices, it sets the max transferred sectors to 128 per command
<jdong> Keybuk: this slows down transfer speeds for that device
<jdong> Keybuk: when you transfer too fast (anything above 128) to the device, it'll disconnect from the USB
<tfheen> seb128: ok, upload away.
<tfheen> pitti: thanks.
<tfheen> ogra: if you're confident in it, I can wave it through.
<tfheen> Keybuk: what does the unapproved queue look like now?
<seb128> tfheen: thank you
<ogra> tfheen, i am ... but if you need one, i have a debdiff
<Keybuk> tfheen: largish
<jdong> Keybuk: and I know of no other RockChip vendor names other than the USB chipset used by common cheap Chinese MP3/MP4 players
<mvo> Kamion: is the debian-installer using apt-get now to install the ubuntu-desktop task?
<Keybuk>   108873 | S- | util-linux           | 2.12r-11ubuntu2      | 15 minutes
<Keybuk>          | * util-linux/2.12r-11ubuntu2 Component: main Section: base
<Keybuk>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 15 minutes
<Keybuk>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
<Keybuk>   108870 | S- | edubuntu-artwork     | 0.1.0-43             | 15 minutes
<Keybuk>          | * edubuntu-artwork/0.1.0-43 Component: main Section: gnome
<Keybuk>   108867 | S- | xmms                 | 1.2.10+cvs20060429-1 | 20 minutes
<Keybuk>          | * xmms/1.2.10+cvs20060429-1ubuntu2 Component: main Section: sound
<Keybuk>   108860 | S- | telepathy-blue       | 0.0.1.1~darcs2006092 | 35 minutes
<Keybuk>          | * telepathy-blue/0.0.1.1~darcs20060926-0ubuntu3 Component: universe Section: net
<Keybuk>   108858 | S- | popularity-contest   | 1.33ubuntu2          | 45 minutes
<Keybuk>          | * popularity-contest/1.33ubuntu2 Component: main Section: misc
<Keybuk>   108857 | S- | evolution-data-serve | 1.8.1-0ubuntu3       | 45 minutes
<infinity> Keybuk: util-linux is mine, I'll approve it.
<Keybuk>          | * evolution-data-server/1.8.1-0ubuntu3 Component: main Section: gnome
<Keybuk>   108841 | S- | xchat-gnome          | 1:0.13-0ubuntu9      | 1 hour 10 minutes
<Keybuk>          | * xchat-gnome/1:0.13-0ubuntu9 Component: main Section: gnome
<Keybuk>   108839 | S- | xdg-utils            | 1.0-0ubuntu2         | 1 hour 40 minutes
<Keybuk>          | * xdg-utils/1.0-0ubuntu2 Component: universe Section: utils
<infinity> (FTBFS fix)
<tfheen> Keybuk: edubuntu-artwork, xmms, popularity-contest, evolution-data-server xchat-gnome are ok.
<pitti> Keybuk: xmms and i smy FTBFS fix
<tfheen> I think the xdg-utils one is fine too, but I haven't seen either of the diffs so I'd like Kamion to look at that.
<BenC> infinity: It's interesting, I fixed this already once
<infinity> BenC: Not hard enough, apparently. :)
<infinity> BenC: devmapper obviously chokes, as does anything that build-deps on it.
<BenC> infinity: Uploading a fixed package now...basically, you can't include linux/types.h, and add "typedef unsigned int __kernel_dev_t"
<pitti> tfheen: good and bad news; I fixed the original quagga FTBFS, just to find the same pdftex symbol error; but now I can care for that, too :)
<dholbach> telepathy-blue is just a dependency change to make it installable
<Keybuk>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 18 minutes
<Keybuk>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
<Keybuk>   108860 | S- | telepathy-blue       | 0.0.1.1~darcs2006092 | 38 minutes
<Keybuk>          | * telepathy-blue/0.0.1.1~darcs20060926-0ubuntu3 Component: universe Section: net
<Keybuk> that leaves those towo
<infinity> BenC: Havint to include that typedef in a userspace header reeks of a bug elsewhere.
<Keybuk> pitti: 
<Keybuk>  o bluez-gnome: bluez-passkey-gnome
<Keybuk>    [Reverse-Depends: Edgy supported seed] 
<Keybuk>  o command-not-found: command-not-found command-not-found-data
<Keybuk>    [Reverse-Depends: Edgy desktop seed, command-not-found] 
<tfheen> pitti: thanks and thanks.
<infinity> BenC: But whatever fix works, I'm cool with it for now. :)
<Keybuk> neither of those have MIRs or main approval?
<pitti> Keybuk: I approved bluez-gnome some hours ago
<BenC> infinity: Since __kernel_dev_t is pretty static, It is safe
<pitti> Keybuk: indeed I never looked at c-n-f
<Kamion> mvo: no, haven't done that yet
<Kamion> mvo: I thought you were going to have a look at the feasibility of fixing aptitude first?
<Keybuk> pitti: I don't see it in the queue?
<Kamion> Keybuk: I just promoted bluez-gnome
<Keybuk> pitti: oh, someone stuck it under promoted ?
<BenC> infinity: Uploaded, so you may want to push that through
<Keybuk> Kamion: ok
<pitti> Keybuk: apparently someone moved it already
<Kamion> Keybuk: it's in the other queue now :)
<Keybuk> Kamion: note that I've already done the rest :p
<mvo> Kamion: it does not look easy to fix in aptitude, very generic code
<Keybuk> Kamion: so we may end up with some soyuz mid-air collisions in a moment
<tfheen> Kamion: isn't beagle NBS on sparc?
<infinity> BenC: Accepted, thanks.
<tfheen> Kamion: same for brltty on ppc
<BenC> infinity: IMO, it's a devmapper bug that it uses __kernel_dev_t instead of dev_t, but I wont get in the middle of that
<Keybuk> dholbach: telepathy-blue fixes the dep on python2.4-bttctl ?
<dholbach> Keybuk: yes, please
<Kamion> Keybuk: I just did bluez-gnome after dholbach asked, nothing else
<BenC> infinity: It may be one of those things where "we always used it, and now we can't change"
<infinity> BenC: Nonsense, change can always happen. :)
<Kamion> tfheen: dunno if archive-cruft-check understands that
<infinity> BenC: Think of all the bloody s/PAGE_SIZE/sysconf(_SC_PAGESIZE)/ uploads I've made.. *sigh*
<tfheen> Kamion: can you make it understand it with an appropriately sized bat?
<Keybuk> doko_: fixed the libintl.jar problem with java-gcj-compat-dev
<Keybuk> their configure is busted for gcj detection, basically
<siretart> xmms is in main? interesting..
<pitti> tfheen: yup, a tetex-bin rebuild fixes the pdfetex symbol; yay ABI changes; I'll do a no-change upload, okay?
<doko_> Keybuk: hmm ... in that case I would like to propose another solution: registering a javac alternative in ecj-bootstrap, and depending on that package. java-gcj-compat-dev sucks in too much.
<Keybuk> that solution sounds edgy+1 :)
<doko_> or you teach gettext to use ecj instead of javac
<tfheen> pitti: I'm worried about poppler silently breaking the ABI
<pitti> tfheen: I'll check the other rdepends, too
<doko_> Keybuk: as the worst case, make a symlink from ecj to javac for the gettext build
<tfheen> pitti: thanks.  If those are fine, I'm fine with a no-changes rebuild.
<Keybuk> doko_: I'm afraid it cannot be taught to do that
<Keybuk> it is hardcoded to look for "javac" or "gcj"
<doko_> Keybuk: ln -sf /usr/bin/ecj javac; PATH=.:$PATH configure ...
<Keybuk> doko_: *shrug* my way worked
<pitti> Riddell: can you please check if kpdf plays well with the current poppler? pdfetex crashes with a weird 'symbol not found' error; I'll check the other rdepends
<Riddell> pitti: ok
<doko_> Keybuk: as long as you don't have a dep on libgcj*, that's maybe ok
<doko_> pitti: I've seen that error as well, building gnat-gps, but cannot reproduce it here locally.
<pitti> doko_: exactly; that'll be fixed with the tetex-bin rebuild as well
<pitti> doko_: the very same as with quagga FTBFS, crashes through texi2dvi
<seb128> mdz: bug #63481 for the panel freeze
<Ubugtu> Malone bug 63481 in gnome-panel "gnome-panel freezes after dist-upgrade" [Medium,Needs info]  http://launchpad.net/bugs/63481
<pitti> ogra: is there a bug for the gstreamer ltsp issue
<ogra> pitti, yep
<ogra> bug #65690 i think
<Ubugtu> Malone bug 65690 in gst-plugins-good0.10 "should select the esdsink for LTSP_CLIENTs" [Medium,Unconfirmed]  http://launchpad.net/bugs/65690
<pitti> ogra: hm, I just read my bugs inbox and didn't see it, thanks
<ogra> probably LP is delayed again ...
<mooey> i'm trying to fix a bug that deals with default / preferred browsers -- does kde have an alternative of gnome-open / gnome-www-browser?
<Riddell> mooey: kfmclient
<mooey> thanks
<giftnudel> sivang: ping session and freespace detection
<sivang> giftnudel: yeah ? :)
<giftnudel> sivang: is capacity the whole capacity, volumesize the current size of the medium and freespace bytes the rest which is free to save stuff on?
<sivang> giftnudel: that what I would think , why?
<giftnudel> I've got something to test for you which seems to work nicely sometimes ;)
<sivang> somttimes? ;-)
<giftnudel> well, if it can't unmount the cd, it won't work (but shouldn't crash either)
<sivang> ah, then I think we can aloways unmount the cd if need before a certain action
<giftnudel> I did that, but sometimes, the cd is still busy and I don't know why ...
<sivang> giftnudel: what's your method of calculating anyway?
<giftnudel> but anyhow, I will sent you the DeviceInfo.py (it's not a major change, just some additions) please tell me what you think
<giftnudel> sivang: cdrecord -msinfo -v
<giftnudel> this is very reliable (the only reliable way to do so as I found out)
<jdong> can anyone familiar with git comment on bug 43210 for me?
<Ubugtu> Malone bug 43210 in dapper-backports "Git-core is out of date" [Undecided,Unconfirmed]  http://launchpad.net/bugs/43210
<jdong> is git something worth backporting?
<giftnudel> sivang: you've got mail
<sivang> giftnudel: thank you, I shall read later today
<fabbione> jdong: i find it hard to believe that's not compatible.. use wiki.u.c/KernelGit <- to test yourself
<jdong> fabbione: thanks
<fabbione> it's KernelGit+something... i can't remember the exact page
<zul> https://wiki.ubuntu.com/KernelGitGuide
<pitti> Riddell: ok, abiword and evince work fine, and tetex-bin works again after rebuild; if kpdf works as well, then a mere rebuild should do fine
<fabbione> mvo: there were 2/3 things that were messing up
<fabbione> but imake in edgy is provided by xutils-dev or something
<fabbione> and for some reasons we don't pull it in
<fabbione> till before Kamion cleared the NBS there was another package from dapper, sliping in the edgy Packages file
<Kamion> Provides aren't always enough for apt
<Kamion> particularly not if the old package remains installed
<Kamion> you'd probably want Conflicts/Replaces/Provides anyway surely
<fabbione> Kamion: yes.. i know. i don't recall all the details off-hand
<Kamion> ... which it does have
<Kamion> so it needs a transitional package because the package management system isn't up to it *shrug*
<Kamion> see specs by iwj passim
<seb128> BenC: you didn't reply yesterday, if you do an another upload, could you consider the change from #64433? It would make one of the GNOME dudes happy. If you can't that's fine too
<BenC> seb128: Sure thing
<cipher_nemo> Should I use the ubuntu wiki to post about brand-name PCs which fail on ubuntu dapper install (works with Debian sarge)?
<dholbach> iwj: Hi, do you think bug 35333 and bug 62802 are easy to fix (if you should do a firefox upload), disregard them, if it's too much trouble
<Ubugtu> Malone bug 35333 in firefox "xpcshell is unusable due to lack of wrapper script" [Medium,Unconfirmed]  http://launchpad.net/bugs/35333
<Ubugtu> Malone bug 62802 in firefox "missing static libraries" [Undecided,Unconfirmed]  http://launchpad.net/bugs/62802
<pitti> dholbach: why do we need static libs?
<pitti> if we have them, somebody could use them, which would suck
<iwj> dholbach: Is 35333 really that big a problem ?
<dholbach> iwj: I just had a look if another one of chpe's bugs was fixed and it was, so I stumbled over those two - I wasn't sure if they were hard or easy to fix.
<iwj> dholbach: I don't want to ship the run-mozilla.sh script from upstream because it's completely insane.
<dholbach> I see
<iwj> Ideally we'd set the rpath so it would Just Work (tm).
<dholbach> I know that seb128 asked for xpcshell on another occasion already - I don't know the use-cases for it, to be honest.
<iwj> I had a go at that but it doesn't seem to have completely taken.
<pitti> Riddell: kpdf works fine for me
<dholbach> iwj: don't bother then.
<iwj> dholbach: It does work; the workaround - setting LD_LIBRARY_PATH is both trivial and documented.
<dholbach> iwj: thanks anyway. :-)
<pitti> tfheen: so, only tetex-bin needs a rebuild, other rdepends work fine; ok for me to upload?
<iwj> dholbach: OK :-).
<Riddell> pitti: great
<tfheen> pitti: approved.
<dholbach> iwj: chpe is always a big help and hacks on the the gnome firefox-related bits (using ubuntu), so if I could make him happy, ... ;-)
<pitti> tfheen: uploaded; I'll defer the quagga upload until the new tetex-bin is in the archive to avoid yet another ftbfs
<iwj> dholbach: Right.
<tfheen> pitti: please tell me when you do the quagga upload so I can give-back the ftbfs which gave us the first hint of this problem.
<pitti> tfheen: yup
<janimo> tortoise_:, heno: hi could either of you commit the patch in bug 65251
<Ubugtu> Malone bug 65251 in onboard "work without nautilus" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65251
<janimo> it was part of the upload I made for 0.82 a few days ago but got reverted by accident
<heno> janimo: looks good. I'll let tortoise_ apply the actual patch though (being the maintainer)
<janimo> heno: thanks
<pitti> Keybuk: can you please approve the tetex-bin upload? it holds up quite a few ftbfs issues
<Keybuk> pitti: tfheen
<pitti> Keybuk: 1820: <tfheen> pitti: approved.
<tfheen> Keybuk: also, please approve the python-{setuptools,qt3,qt4,kde3} uploads from doko_
<wasabi_> So... where do we stand on EFI? This neato server board I just bought seems to support an EFI shell.
<wasabi_> Oooh elilo
<tortoise_> janimo: done
<sivang> hi janimo , what's up?
<janimo> tortoise_: thanks, planning a package upload in the next days?
<janimo> sivang: hi
<tortoise_> janimo: Not in my power to do so.  Have to ask one of the ubuntu-core-devs
<dholbach> janimo, Gloubiboulga: bug 57588 might affect xubuntu-artwork too
<Ubugtu> Malone bug 57588 in edubuntu-artwork "GDM themes do not have pam-message item" [Undecided,Unconfirmed]  http://launchpad.net/bugs/57588
<dholbach> just fyi
<pygi> pitti, ping? :)
<pitti> hey pygi 
<pygi> hey pitti 
<pygi> some nice news again :) Libburn completely working on freebsd :)
<pitti> nice
<pygi> :)
<Riddell> pitti: I confirm today's kpdf with today's poppler is working fine for me
* gnomefreak likes the artwork for edgy just fine, no need to revert :(
<pitti> Riddell: thanks
<sivang> hey pygi !
<pygi> sivang, !!!!
<sivang> pygi: new release to package for edgy+1 when it opens? :-)
<pygi> sivang, you saw the above? :)
<Gloubiboulga> dholbach, thanks
<pygi> sivang, dunno, we'll see, a lot of work in libisofs to be done (and a lot in cdrskin + libburn still)
<janimo> tortoise_: I can upload ( Id id so with 0.82) but will ask for permission as it's a freeze
<janimo> dholbach: thanks
<sivang> pygi: yes, what does 'work' includes? 
<pygi> sivang, I want to have Kamion's features ready for 0.2.4 :)
<pygi> sivang, told ya already :) HFS, HFS+, and eltorito :)
<sivang> pygi: should then get cracking on getting some good specs and updated ones.
<dholbach> janimo: I'll add a task for you, if not you can just reject it
<pygi> sivang, we have good specs I believe :)
<janimo> dholbach: ok, thanks
<dholbach> super
<sivang> pygi: okay, cool. btw, what about switching out from trac but still using svn? (possible as well)
<pygi> sivang, dunno :)
<pygi> what's so wrong with trac?? :)
<Gloubiboulga> janimo, I'll take care of the gdm bug
<janimo> Gloubiboulga: thanks
<sivang> pygi: hmm, it's awkward and we'll win pretty nice feature planning features in LP :-)
<pygi> sivang, I've told you stuff, bleh =)
<sivang> pygi: let's go to privmsg
<tfheen> tkamppeter: is there any reason why we can't ship the firmwarE?
<tfheen> s/E/e/
<sivang> tkamppeter: is printdrake in python?
<tkamppeter> sivang, printerdrake is Perl
<tkamppeter> tfheen, the firmware is copyrighted, I perhaps need to talk with HP guys on the summit.
<sivang> tkamppeter: ah
<tkamppeter> tfheen, but if we have auto-download of printer drivers from the FSG OpenPrinting database, HP can put the firmwares into their packages.
<tfheen> tkamppeter: we should be able to get a redistribution agreement or something for it, I'd imagine.
<tkamppeter> Yes, that's it.
<tkamppeter> tfheen, but if all works fine, only FSG needs this agreement and Edgy+1 does the rest.
<JanC> bah, since the last python2.4 update, it also suffers from the python-central bug--now both installed python versions aren't properly configured anymore  :-(
<janimo> Gloubiboulga: does gnumeric require latest goffice and latest gsf to build and run?
<Gloubiboulga> janimo, yes
<Gloubiboulga> tfheen, is it ok to upload a new xubuntu-default-settings : http://tiber.tauware.de/~gauvain/x-d-s.debdiff ?
<tfheen> Gloubiboulga: yes, looks good to me.  Feel free to upload.
<Gloubiboulga> thanks
<keescook> dholbach, tfheen: I have a fix for bug 39275.  Okay to upload?
<Ubugtu> Malone bug 39275 in gstreamer "AC3 videos sound WAY too soft" [Unknown,Fix released]  http://launchpad.net/bugs/39275
<mdz> BenC: what's next in tracking down this e1000 bug?
<BenC> mdz: I need to talk to davem, fabbione says he's aware of a similar problem on sun4v
<mdz> BenC: the bisecting didn't result in any leads?
<BenC> mdz: It resulted in a couple of commits, but the only one that looked like it could cause a problem, was fixing a problem just as bad as the one it seems to be causing
<BenC> and it was pretty complicated, lot of locking fixes
<BenC> I don't have time to try to understand the locking symantics to fix the fix
<fschoep> mdz: ping?
<dholbach> keescook: you rock
<keescook> cool.  :)
<keescook> should I wait for tfheen to okay the upload too?
<jcole> does the mini.iso installer for edgy use the new debian gtk installer?
<jcole> http://wiki.debian.org/DebianInstaller/GUI
<keescook> I also have a security upload for edgy as well (xorg package, one-line change)
<fschoep> Can anyone point me to the head of the documentation team? Launchpad isn't helpful.
<pitti> ROCK! fresh new tetex-bin, now without poppler troubles
<pitti> tfheen: new tetex-bin is in the archive, I upload quagga now; please give-back gnat-gts for that, too
<mdz> fschoep: pong
<jcole>  /j #ubuntu-boot
<jcole> oops
<fschoep> mdz: who leads the docteam?
<mdz> fschoep: points of contact are at https://wiki.ubuntu.com/DocumentationTeam/Contact
<siretart> dholbach: anything to do on the unapproved queue?
<dholbach> siretart: i don't know - Kamion, keybuk, infinity, tfheen would know
<siretart> okay. I've set my irssi hilights for this channel, I'll try to notice if something is to do
* dholbach hugs siretart
<dholbach> siretart: how are you?
<siretart> dholbach: Oh, writing a thesis makes you quite busy, you know? ;) - anyway, I'm trying to catch up with my ubunut work, and I think I managed it so far :)
<siretart> the move is finally finished, so I can concentrate now on the thesis fully :)
<dholbach> siretart: i remember :)
<siretart> dholbach: how are things going on your side?
<dholbach> siretart: quite busy too, but good to see that bugs and todo lists are shrinking away :-)
<siretart> :)
* pygi notes to siretart in case he missed it that libburn work on freebsd from today :)
<keescook> where does checkrdepends come from?  apt-cache isn't helpful, and neither is google.  I'm feeling crazy.  :)
<dholbach> dlocate?
<dholbach> dpkg -S?
<dholbach> apt-file? :)
<keescook> dholbach: well, as in, I want it, but I can't find it's origin to go get it from.  :)
<dholbach> apt-file the
<dholbach> then
<siretart> pygi: I've seen it. whoohoo
<pygi> siretart, :)
<keescook> dholbach: no luck.  is this tool only on the archive machines?  (https://wiki.ubuntu.com/ArchiveAdministration is the only thing that talks about it)
<dholbach> keescook: oooh, that might be
<keescook> dholbach: ah well, I will stick with apt-cache until I have access to those machines.  ;)
<dholbach> http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=checkrdepends&searchmode=searchfiles&case=insensitive&version=edgy&arch=i386 is empty too
<keescook> dholbach: yup, did that too
* dholbach hugs keescook :)
<keescook> :)
<keescook> dholbach: during freeze are you the RM for universe uploads, or does everything need tfheen's approval regardless of repo?
<keescook> I've got two universe uploads to do (milestone fix and security fix), and I'm just trying to understand the process.  :)
<dholbach> keescook: keybuk, tfheen, Kamion and infinity will all ask, if they process the queue - if nobody of you speaks up for an upload, they will assume that I know and ask me :-) :-)
<dholbach> keescook: luckily the most cases were easy enough
<keescook> dholbach: okay, so I should go ahead and do the two uploads?
<dholbach> keescook: if it's easy and simple enough, yeah, sure
* Burgwork hugs keescook for all the great QA being done
* keescook hugs Burgwork :)
<dholbach> good night
<keescook> cya dholbach
<dholbach> bye keescook
<siretart> sleep well, dholbach !
<dholbach> siretart: later, yeah - but you too! :-)
<siretart> :)
<ajmitch> morning all
<_ion> Good evening.
<zul> later
<mdz> BenC: any word from davem?
<BenC> mdz: He says it is unrelated, so I'm trying to backout the commit that the bisect pointed to, from a 2.6.18 version and get it compiled for you
<mdz> BenC: ok, I'm around
<BenC> I gotta get the kids off the bus, then I'll get it to you
<wasabi_> heh. dapper is totally failing to deal with these md devices
<BenC> mdz: test ready: 50ae5b06fc3e011a6a8e14ce40f4017d
<mdke_> can someone help me with something very basic? If I have a bunch of files name "index.xyz.html", where xyz is a variable, how can I rename them all to "index.html.xzy" using one command?
<neuralis> mdke_: for i in *xyz.html; do mv "$i" `basename "$i" xyz.html`html.xzy; done
<mdke_> wow, that sounds spiffy, trying
<BHSPitMonkey> showoff
<mdke_> neuralis: doesn't seem to work. It's "xyz" that varies...
<mdke_> so I have index.en.html, index.fr.html etc
<neuralis> you said it's a variable, by which i assumed you mean it's a $VARIABLE.
<mdke_> maybe I expressed myself badly, sorry
<mdke_> I mean it varies from file to file
<neuralis> sec
<BHSPitMonkey> anyone seen keybuk recently?
<Ng> for i in `ls index.*.html` ; do echo mv $i index.html.`echo $i | sed -e 's/index.\(.*\).html/\1/'` ; done
<Ng> then remove the echo if you're happy
<Ng> not the cleanest it could be, but it works ;)
<mdke_> Ng: yes, I'm happy :) What do I remove, exactly?
<Ng> "do echo mv" becomes "do mv"
<Ng> it do the command instead of echo what you would have done
<Ng> -it+te
<Ng> gah, my typing sucks so much today...."ie"
<mdke_> got it, and it works. Thanks!
<Ng> I should probably be sent to some kind of shell hell for not doing it more cleanly though ;)
<Ng> maybe a place with no bash, only csh ;)
<_ion> rename -n 's/\.([^.] +)\.html$/.html.$1/' *
<_ion> Remove -n after you've verified the result.
<Ng> see that's much nicer :)
<neuralis> mdke_: ah, okay, you were helped while i was out.
<mdke_> :)
<mdke_> for some reason, it has broken some of the styling in the html
<mdke_> how odd
<Kamion> jcole: no; while I've been involved with the Debian graphical installer at various levels for a while, I still don't think it's quite up to scratch
<Kamion> keescook: pitti wrote checkrdepends
<wasabi_> nice. no elilo on dapper install?
<Kamion> keescook: http://people.ubuntu.com/~cjwatson/checkrdepends is the current version
<mdke_> Ng: that script doesn't touch the inside of the files right? it's very odd that the styling has broken on them
<keescook> Kamion: ah-ha!  Thanks.  I looked for it in ~pitti earlier.  :)
<Kamion> interface-wise it's rather nasty - it would be better if the suite were either first, or had a sensible default
<Kamion> but shrug, it does the job
<Ng> mdke_: you saw the echo output, all it does is call mv and last time I checked there's no way mv can change a file. Is it not more likely that apache/whatever is treating the files differently now they aren't called .html?
<Ng> perhaps one of those strange things whereby a browser goes into sloppy/strict rendering modes of its own accord, but I'm really very doubtful that command would have broken the files
<BenC> mdz: ping?
<mdke_> Ng: I'm just viewing them on my filesystem, without apache
<mdz> BenC: have booted with the new module, testing now
<Ng> mdke_: try renaming one of the "broken" ones back to .foo.html and see if it renders properly
<mdke_> Ng: yes works :) Ok presumably apache will make it work
<Ng> mdke_: do they not have proper doctype headers?
<Ng> that usually seems to convince browsers to behave predictably (in as much as browsers ever do that ;)
<wasabi_> oh nice. it ftbfs in dapper ad64 haha
<wasabi_> amd64
<mdke_> Ng: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<Ng> weird. stupid browsers!
<mdke_> yeah. Anyway, I'm happy it will work
<mdz> BenC: 5x OK
<BHSPitMonkey> anyone seen keybuk recently?
<tkamppeter> mdz, keybuk, New foo2zjs package on http://www.freestandards.org/~till/tmp/ubuntu/edgy/foo2zjs/ to address bug 65618
<Ubugtu> Malone bug 65618 in foo2zjs "Package broken/incomplete, missing firmware files" [Low,Needs info]  http://launchpad.net/bugs/65618
<BenC> mdz: So that resolves it?
<BenC> mdz: e1000: rework driver hardware reset locking
<BenC> mdz: That's the patch I backed out
<mdz> BenC: yes, that driver seems to work well
<BenC> mdz: Ok, one more test, give me 5 minutes
<mdz> BenC: can I see the diff?
<mdz> going to make some lunch, will check back from time to time
<AlinuxOS> mjg59, hello... ping
<BenC> mdz: next test: 502570b8f8f51eb60056efc7dc9fee4c
<mdz> BenC: testing
<jcole> Kamion: oh ok, it appears it only supports i386 and amd64 too
<mdz> BenC: 5x OK
<BenC> mdz: Ok, the first test was stock edgy kernel, with that problem patch reverted, the second test was 2.6.18 stock version with the same patch backed out
<mdz> sounsd compelling
<BenC> I'm leaning to do the 2.6.18 - the problem commit reverted
<BenC> s/-/minus/ to be clear
<mdz> what else is in 2.6.18 which we don't have in edgy?
<BenC> mdz: in e1000 or in general?
<mdz> BenC: e1000
<mdz> BenC: I assume you're not talking about moving the rest of the kernel to 2.6.18 ;-)
<Seq> I was wondering if anybody using edgy had beagle indexing gaim logs at all? Mine doesn't seem to, but I haven't found anything on launchpad yet
<seb128> anybody around to approve http://people.ubuntu.com/~seb128/gaim.debdiff ?
<mdz> BenC: I'd like to see the diff for the problem commit
<zul> ooh...move it to 2.6.18 :)
<mdz> seb128: sure
<seb128> that's just changing again the "stop the glowing effect" default option again
<seb128> (we did for dapper and the patch got dropped on the road during edgy)
<mdz> seb128: yep, no problem
<seb128> mdz: thank you
<seb128> uploaded
<ajmitch> zul: somehow I don't think he means the whole kernel :)
<BenC> mdz: Sent
#ubuntu-devel 2006-10-13
<mdz> BenC: hmm, it seems to drop an e1000_reset call, wonder if that's OK
<BenC> mdz: in e1000_set_settings?
<jdong> seb128: is there anything gnomeish in /etc/X11/Xsession.d that could possibly mess with DPMS settings?
<BenC> mdz: That's all ethtool stuff, probably doesn't even come in the play with this use case
<seb128> jdong: what is your issue?
<jdong> seb128: when running KDE with gnome installed, DPMS timeouts seem to multiply by 60
<jdong> seb128: thatis, seconds turn into minutes
<jdong> seb128: everyone who has the problem appears to have GNOME installed
<mdz> BenC: any idea why it gets rid of the watchdog task?
<jdong> and from what we can tell, KDE is doing the restore correctly.. but something later on is overridding it
<seb128> jdong: not that I know, do they use gdm?
<BenC> mdz: According to the comments in the commit, it is replaced with a non-scheduled task
<jdong> seb128: I do, and I see the problem
<seb128> jdong: might be gdm doing something with it
<jdong> seb128: hmm, interesting idea
<Lure> jdong: I use kdm
<seb128> dunno then
<jdong> Lure: do you want to sacrifice your Xsession.d to experimentation?
<mdz> BenC: doesn't make much sense to me
<jdong> Lure: that is, move it somewhere else, make a new one only with displayconfig-restore
<mdz> BenC: the patch seems to have 3 more or less independent parts, maybe we can narrow it down
<mdz> the _reinit_locked stuff, irq request/release, and the watchdog
<BenC> mdz: The one part I wonder about is this:
<BenC> +       while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
<BenC> +               msleep(1);
<BenC> mdz: That has to do with timers, which would seem to be a likely trigger for our problem
<mdz> it does the same thing as _reinit_locked
<mdz> BenC: what's the first arg to test_and_set_bit?  is it supposed to be a bit position or a mask?
<BenC> mdz: That's an interesting question, because that is an enum, and so one of the values is 0x0, which is not a bit at all
<mdz> yeah, that seems ot be valid though
<BenC> mdz: let me try the full 2.6.18 with those enums as bit values
<mdz> I see other test_and_set_bit(0, ...) elsewhere in the kernel
<BenC> oh, wait
<BenC> no, that's valid
<BenC> it's a but number, not a mask
<BenC> s/but/bit/
<mdz> yes
<mdz> BenC: could something else be modifying adapter->flags?
<BenC> mdz: Give this a try: 1eec6078ecea6a3cead2e9f35820a1fa
<BenC> mdz: That's stock edgy kernel, minus all the adapter->flags fiddling
<BenC> we'll take this one at a time
<mdz> BenC: broke on the second try, but not quite in the usual way
<mdz> actually first try
<mdz> let me do a fresh boot
<mdz> oh, flags is new, so no other code would be touching it
<BenC> well, it's based on broken source, so if removing flags didn't fix things, then it isn't the culprit
<BenC> Let's try the reinit change
<mdz> BenC: yeah, this one won't suspend at all
<mdz> worse than stock edgy
<shining> did anything change recently in edgy kernel about cpufreq (centrino driver)?
<mdz> I'm suspicious of the irq changes
<shining> mdz: for suspend or cpufreq?
<mdz> shining: the e1000 problem that BenC and I are working on
<shining> ah ok. that doesn't seem to be easy :p good luck
<BenC> mdz: next: ee221a06d71530fee7faa6f0371db2cb
<BenC> mdz: This is stock edgy, with just the reinit_locked parts reverted
<BenC> I'm not so sure how well that's going to work
<shining> I'm sure speedstep-centrino worked fine before on my core duo laptop. but now it doesn't even load anymore (no such device). too bad I stopped using it, so I can't know if it stopped working after a kernel update
<mdz> BenC: panics in the familiar way
<BenC> mdz: next: dcfe691b1e2a4888ff792cbe97329f38
<BenC> mdz: This one re-adds the watchdog timer
<mdz> BenC: only?
<BenC> mdz: Right
<mdz> ok
<BenC> I'm reverting back to stock edgy for each of these
<mdz> doing the reboot dance
<mdz> 1x OK
<mdz> crash on 3x
<mdz> blank screen, flashing caps lock
<BenC> interesting
<BenC> mdz: Let me investigate this change a bit...I got a fresh cup of coffee
<mdz> BenC: how about we try backing out the irq changes?  I mailed you a diff
<mdz> nm, I can build it here and try
<mdz> BenC: ack, the diff you sent me is word-wrapped
<BenC> mdz: you have git?
<BenC> mdz: If so: git-diff-tree -p 2db10a081c5c1082d58809a1bcf1a6073f4db160 > temp.diff
<mdz> BenC: yep, thanks
<AlinuxOS> mdz, good evening or good night (I don't know your location) ;)
<Riddell> Kamion: the language packs don't get added to the meta packages any more?
<AlinuxOS> I've just mailed a letter, my problem is explained there...please check when you've some free time. Thank you in advance.
<mdz> BenC: backing out the irq hunks gives me something which seems to work. 5x and counting
<AlinuxOS> mdz, thank you for tempestive response, also sorry my for my stupid question but I don't know what should I do in this case ?
<BenC> mdz: try this: 371c320808c3aebadd6379c4ba8d6caf
<BenC> mdz: That pretty much does the same thing, but with less changes (leaves the request/free functions, but moved them back to where they used to be called)
<mdz> BenC: looking good, 3x and counting
<mdz> BenC: I'm satisfied
<`anthony> doko_: Older Ubuntu releases need a security update release (whatever you call them) for Python 2.3 to pull in PSF-2006-001. You distribute a UCS-4 build - this is vulnerable to a buffer overrun.
<BenC> mdz: Now the real question, stock edgy + this diff, or 2.6.18 e1000 plus this diff?
<mdz> BenC: edgy
<mdz> minimum changes to fix this regression
<BenC> mdz: Ok, I sent you a copy of the diff
<BenC> commiting and marking the bug
<doko_> `anthony: replied by email: afaik, we do. I'll recheck tomorrow with keescook and pitti
<keescook> `anthony: that should have been covered by http://www.ubuntu.com/usn/usn-362-1
<keescook> are you still seeing issues with the latest build?
<keescook> sorry, wrong USN: http://www.ubuntu.com/usn/usn-359-1
<mdz> BenC: nice work, what's next on the kernel hit list?
<`anthony> keescook: I don't have a test that reproduces it. That advisory doesn't mention python
<BenC> 58742: I need to check into the dvb modules for v4l-1
<BenC> 64433: I'm trying to decide if the suggested fix is correct
<lifeless> `anthony: it does - at the top
<lifeless> python2.3, python2.4 vulnerabilities
<lifeless> CVE-2006-4980
<`anthony> php4, php5 vulnerabilities
<BenC> bug 58742 bug 64433
<`anthony> ??
<Ubugtu> Malone bug 58742 in linux-source-2.6.17 "[edgy]  Important dvb-ttpci modules are missing in edgy!" [Undecided,In progress]  http://launchpad.net/bugs/58742
<Ubugtu> Malone bug 64433 in linux-source-2.6.17 "Use correct SATA driver for (some) MacPros" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64433
<lifeless> ...
<lifeless> Benjamin C. Wiley Sittler discovered that Python's repr() function did
<lifeless> not properly handle UTF-32/UCS-4 strings.
<`anthony> ah - there was a second link.
<`anthony> I missed that scroll past :)
<keescook> `anthony: yeah, sorry for the typo
<lifeless> :)
<mjg59> BenC: It's almost certainly correct. Most modern Intel chips should be listed in both ahci and ata_piix
<`anthony> It also applies to 2.2, btw, which you guys have.
<mjg59> Yes, this is greatly irritating
<`anthony> and quite probably 2.1 - which we (python.org) don't support any more at all.
<BenC> mjg59: So the dual listing is ok...hopefully ata_piix just wont claim it?
<lifeless> we have 2.2 ?
<BenC> does udev handle that?
<keescook> `anthony: true, 2.2 is in "universe"
<lifeless> who knew.
<`anthony> ii  python2.2      2.2.3dfsg-4    An interactive high-level object-oriented la
<mjg59> BenC: In this case, if both drivers can bind it, it may need manual blacklisting to pick the right one
<mjg59> BenC: Nothing we can fix in time for edgy, though
<`anthony> apologies in the delay in getting the python security advisory out - post 2.5, there was a bit of shellshock/PTSD :)
<doko_> keescook: well, is it possible to fix the universe versions as well?
<keescook> `anthony: no problemo.  :)  I'll see about 2.2; I was going to be rebuilding it to relink against openssl 0.9.8 anyway.  :)
<`anthony> same patch as for 2.3
<keescook> `anthony: I was just going to ask.  :)  great, I'll get to that tomorrow.  Thanks for checking in with us!  :)
<AlinuxOS> mjg59, hello, I've mailed you a letter,please would you be so kind to check your mail when you've some free time. Thank you.
<`anthony> I should probably hunt down a list of relevant people at various distributions, actually.
<`anthony> What's the best email address for ubuntu?
<doko_> security@ubuntu.com?
<`anthony> No, I'm not going to go and submit a "security" bug to each of 15 different bugtrackers :)
<doko_> keescook: ^^^
<keescook> `anthony: yup, as doko_ says, security@ubuntu.com will hit both me and pitti.
<keescook> `anthony: it doesn't look like python2.2 is vulnerable (at least not for the testcase that was reported)
<`anthony> keescook: >>> sys.maxunicode
<`anthony> 65535
<`anthony> aha. it was built as UCS-2. How odd, when 2.3 and 2.4 are UCS-4
<keescook> `anthony: ah, where did you find the UCS-2 details?
<`anthony> sys.maxunicode :)
<keescook> ah, I see.  2.4 == 1114111
<`anthony> so the source for 2.2 still has the vulnerability, but it's fine the way it's built and distributed as a binary. 
<`anthony> that's a policy decision for you as to whether that's worth fixing, I guess.
<`anthony> (the problem only manifests itself with ./configure --with-unicode=ucs4, which is not the default)
<doko_> yep, I started to configure --with-unicode=ucs4 after a chat with mvloewis
<`anthony> "_=str.upper" is my preferred approach to i18n :)
<BenC> mdz: Ok, I'm down to just the v4l-1 bug
<BenC> mdz: all my bugs for the kernel are taken care of now
<mdz> BenC: excellent
<BenC> mdz: Who can I email my change log to for approval?
<mdz> BenC: me
<BenC> mdz: diff too?
<mdz> BenC: sure
<BenC> mdz: Sent
<sladen> mdz: 1 line wine upload to reapply a change dropped since dapper (do not install mime handlers---so that Firefox does not offer to run .exe's for security reasons)
<mdz> BenC: that pcbios patch gives me the heebie-jeebies
<mdz> sladen: ok
<BenC> mdz: That was pulled from 2.6.18
<mdz> BenC: upstream has bugs too :-)
<BenC> mdz: check the GIT-SHA (git-diff-tree --pretty=medium <sha>) and read the comment
<BenC> mdz: I checked it though to the email discussion about it, and it is absolutely correct
<BenC> mdz: Otherwise, it's a regression from dapper
<BenC> since a lot of pcmcia devices wont even be seen by PCI much less the driver
<railz> I was curious what happened to the option 'allow browsing folder' with share folder
<mjg59> mdz: The patch is considered correct by upstream
<mdz> BenC: what happened with the v4l1 situation?  I thought it was mutually exclusive
<mjg59> And restores 2.6.15 behaviour
<railz> it's no longer available in edgy
<mdz> mjg59: the latter is more compelling than the former; I don't expect upstream willfully applies incorrect patches :-)
<BenC> mdz: v4l1 only drivers had been disabled in edgy...that was ok for most things since a lot of v4l2 drivers had v4l1 compatibility
<BenC> mdz: Some didn't though
<BenC> mdz: It's a small subset, but it's a regression from dapper on our media hw support
<mdz> BenC: right, but I had looked at the bug before and you'd said that we couldn't enable both in some cases
<ajmitch> Kamion: bzr-svn got UVF approval just before freeze, but wasn't uploaded for universe. Still ok to go in?
<BenC> mdz: I checked and the cases where the driver is only v4l1, there's no v4l2 driver
<mdz> BenC: oh, ok
<mdz> BenC: ok, I'm happy with all of this
<BenC> mdz: Ok, then uploading
<mdz> I assume the v4l1 stuff is .config only; there's nothing in the diff
<BenC> right
<BenC> and I did test compile all of it
<BenC> I was going to disable any drivers that spewed even a hint of warning crud, but they all compiled cleanly
<mdz> BenC: ping me when it's processed and I'll accept it
<BenC> compiz == the best way to impress your friends about linux, and the easiest way to lose time in an otherwise normal workflow :)
<BenC> I can't help but to play with kiba-dock everyone in awhile
<BenC> *everyonce
<railz> also, I used to be on hoary and admin/share folders no longer requires admin privledges why is that?
<railz> whereas in hoary it did
<jdong> BenC:  you have time to play?
<jdong> ;-)
<BenC> jdong: I call it "alternate development time" :)
<jdong> ha! that's good
<jdong> sort of like my alternate study time
<sladen> railz: could you file a bug with a screenshot if it's a regression
<railz> sladen: will do
<railz> actually here's a link of how it used to look:
<railz> http://shots.osdir.com/slideshows/659_or/50.png
<BenC> mdz: accepted, just needs approval
<BenC> need to reboot
<bddebian> Howdy
<wasabi> Huh. casper-udeb/runlevel seems to have no effect.
<mdz> BenC: accepted
<BenC> mdz: Thanks
<wasabi> Hmm. DId it change names to/from casper-udeb/configure-init/runlevel? What is it in dapper?
<wasabi> Awww. Looks like that template is gone.
<wasabi> Bah this is silly.
<whiprush> wasabi: hey did you see the lockdown thing I wrote up for the gnome summit? Might be useful for mountain view.
<ajmitch> hey whiprush 
<wasabi> nope.
<whiprush> hi ajmitch!
<whiprush> ajmitch: you too
<wasabi> i'm getting angry right now. =(
<ajmitch> whiprush: I've got to get to MV first
<wasabi> I've spent 3 hours trying to boot this system with Ubuntu heh
<whiprush> http://live.gnome.org/Glockenspiel
<whiprush> Federico from Novell sent along his notes to the admin bof at the summit
<whiprush> I think there are some good ideas there for basing an ubuntu spec off of.
<ajmitch> yeah I read that write up there
<wasabi> I'll check it out when I get home.
<ajmitch> looks good
<wasabi> leaving now
<whiprush> ajmitch: I have a ticket, but haven't gotten a hotel yet. :-/
<ajmitch> whiprush: ah, that's a pain - I can probably afford a plane ticket but would stretch it a lot for the hotel
<whiprush> ajmitch: do you think it would be a good idea to start a spec outline or something before the summit?
<ajmitch> definitely
<ajmitch> always good to start with as much as possible
<whiprush> ajmitch: dude it's the ubuntu community, someone will take care of you. :D
<whiprush> as always, you can have my floor.
<ajmitch> heh
<whiprush> but apparently I snore loudly.
<ajmitch> I can handle that
<ajmitch> that's what earplugs are for :)
<whiprush> ajmitch: as a bonus, I convinced a coworker to come with me, he's like wasabi, a windows/linux guy.
<ajmitch> great!
<whiprush> I'm pretty sure that if we can't spec something decent at MV then we should all quit computing.
<ajmitch> so now I just need someone willing to help me with an airfare & I'll be set :)
<whiprush> msg
<sladen> wasabi: what "doesn't boot"?
<sladen> whiprush: fancy doing an Ubuntu-specific report from Boston for El Fridge?
<whiprush> sladen: possibly.
<whiprush> if ubuntu-specific means "Corey wore the shirt" and "jdub was there" :)
<sladen> whiprush: fantastic, I'll mark that down as a 'yes' then :)
<whiprush> heh
<whiprush> sladen: lots of brown desktops. :D
<jdub> everyone was down with the brown
<jdub> you could make a snarky comment about how wonderful it was to have engineers from all major gnome-shipping companies
<sladen> jdub: you're not suggesting by any chance that Canonicals 2days-per-year conference allowance prevented any engineers from attending...
<heatxsink> sup
<heatxsink> anyone in here ever done two video cards with Ubuntu?
<whiprush> heatxsink: try #ubuntu
<sladen> heatxsink: yes, you'll be wanting https://help.ubuntu.com/community/XineramaHowTo and #ubuntu
<heatxsink> tried that
<infinity> jdub: I was there, I was just hiding.
<mdz> mjg59: do you have an idea about 56365?
<mjg59> mdz: I'll be taking a look at the weekend
<mjg59> I've got a couple of ideas
<mooey> theres a spec on launchpad (bug-reporting-tool) which dosen't seem to have anyone working on - i would like to set about getting this going, but i'm not really sure how to go about it or where even i should ask about these sorts of things
<Burgundavia> mooey: bug reporting is something pitti has been working on
<mooey> Burgundavia, ok. do you have an email address for pitti?
<mooey> or a suitable means to contact him/her :)
<Hobbsee> mooey: he'll be on here later today, i expect
<Burgundavia> martin.pitt@canonical.com
<mooey> thanks :)
<wasabi_> There used to be a document someplace in the Wiki about the process of building the LiveCD. 
<wasabi_> Try as I might I can't find it.
<wasabi_> Oh there it is. ;)
<wasabi_> Weird. The wiki didn't load the entire page the first time I viewed these pages.
<ajmitch> wasabi_: or it redirected you to help.u.c
<wasabi_> Hmm. It took about 10 seconds for the page to show. Before that it just showed the header and the page footer. So I thought "oh, empty wiki page. weird."
<ajmitch> yeah, that happens for redirects like that
<wasabi_> whiprush: What was that you pasted earlier?
<wasabi_> I just got home.
<whiprush> http://live.gnome.org/Glockenspiel
<wasabi_> Heh. This is intersting how the LiveCDCustomization stuff takes an existing livecd and just alters it.
<wasabi_> I was sort of expecting we had a package which built a CD out of apt. :0
<fabbione> morning
<fabbione> ajmitch: you have been flooded with emails
<ajmitch> yes, I saw
<ajmitch> I've also had most of the xfonts builds fail locally due to bad build deps
<fabbione> ajmitch: tthere are some failures due to SYSV IPC.. ignore them
<fabbione> it claims the system is out of disk space
<fabbione> but it's crap
<ajmitch> right, I saw errors like that in packages like dpkg :)
<fabbione> i just kick them back
<fabbione> yes exactlt
<ajmitch> a few other failures due to build depends to sort through
<fabbione> yeah those are real FTBFS
<ajmitch> I'll start filing some bugs & pass the list around
<ajmitch> about 150MB of build logs so far
<fabbione> probably.. some of them will never arrive to you > 10MB
<ajmitch> ah
<fabbione> not many tho
<ajmitch> they getting bounced on my end, or are you not sending them?
<fabbione> probably bounced on your end
<ajmitch> ok
<fabbione> i did remove the size check.. i think
<ajmitch> if you wanted to change the email address at some point, ajmitch@ajmitch.net.nz is on my home DSL, no mailservers in between
<ajmitch> it ought to work now that I fixed the exim config :)
<fabbione> it's not worth.. there are probably 5/6 pkgs that makes a log > 10MB and they are all in main
<ajmitch> ok
<fabbione> crimsun: bug 65831 is for you
<Ubugtu> Malone bug 65831 in john "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65831
<Kagou> morning
<tepsipakki> latest kernel builds have failed, but I can't see any correlation between the architectures
<pitti> Good morning
<fabbione> morning pitti
<pitti> hi fabbione 
<mvo> good morning pitti
<mvo> hey fabbione
<siretart> morning folks
<fabbione> hey mvo
<fabbione> guys FYI i am batch filing bugs on FTBFS
<fabbione> if you get one assigned is because you touched it last
<fabbione> so sucks to be you :)
<tfheen> doko_: python-setuptools still fails to build.
<siretart> tfheen: okay to upload http://librarian.launchpad.net/4821656/nm-patch, as per bug #63975?
<Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
<pitti> tfheen: can you please give-back gnat-gps on i386? it should work now with the new tetex-bin
<pitti> mooey: I'm here now, you had a question?
<tfheen> pitti: done.
<tfheen> siretart: is this patch properly tested?  Why aren't the bugs 6.10-targetted?
<siretart> tfheen: I didn't follow nm the last months, but followed wpasupplicant, espc. in debian. I can assure you that with kernels > 2.6.14 ndiswrapper will only work with driver backend 'wext', and not with 'ndiswrapper', like the patch does. see also my last comment
<siretart> tfheen: I have no idea why this isn't 6.10-targetted, but I think it should be.
<siretart> tfheen: nm is currently broken for ndiswrapper users
<siretart> since months!
<Lathiat> hrm.. for avahi
<Lathiat> im thinking we could write a separate init script for the dbus stuff that uses that defaults file
<tfheen> siretart: contrary to people's expectations, the release team is not psychic and does not read every bug report and so we rely on people to tell us about bugs they think should be fixed for a release.
<Lathiat> and leave /etc/init.d/avahi-daemon to work as expected
<Lathiat> perhaps thatl help
<siretart> and no, I cannot test it propery myself, because I don't have a bcm43xx based card, for which I could use ndiswrapper. but according to the bug reports, I find it pretty straightforward
<Lathiat> (because the dbus system.d stuff is what actually starts avahi on boot)
<tfheen> siretart: wouldn't this have been known since before dapper released?
<siretart> tfheen: heh, no offense. 
<pitti> siretart: funny, my airport extreme (without ndiswrapper stuff) stopped working with NM in edgy, too
<pitti> siretart: but on powerpc I cannot test ndiswrapper either
<siretart> pitti: what driver backend do you use for wpa_supplicant?
<pitti> siretart: however, why do you need ndiswrapper for bcm43xx in the first place?
<pitti> siretart: I don't use wpasupplicant at all; all WiFis I have access to are open
<pitti> (my main one uses Radius)
<siretart> pitti: well, with ndiswrapper, you do use wpasupplicant ;)
<siretart> s/ndiswrapper/network-manager/
<pitti> n-m never picks up an IP for me any more
<pitti> with /e/n/i and ifup it works fine
<siretart> pitti: yes. because n-m now unconditionally starts up wpa_supplicant. and if the wrong backend get choosen, you get the behavior you see
<pitti> ooh
<pitti> siretart: well, I'm up for testing then, I guess
<pitti> if my use case 'n-m with bcm43xx, open auth' is applicable
<tfheen> siretart: find me three users for whom it fixes their problem and no regressions and I'm happy to take it.
<siretart> tfheen: bug #42504 was reported before dapper release
<Ubugtu> Malone bug 42504 in wpasupplicant "Cannot associate with unencrypted networks using bcm43xx chipset (ndiswrapper driver)" [High,Confirmed]  http://launchpad.net/bugs/42504
<tfheen> (preferably today)
<siretart> tfheen: I propose to target it for 6.10
<fabbione> anyone here that uses reiserfs?
<fabbione> (nothing to do with Hans's wife or stuff like that.. i just need to know)
<torkel> fabbione: yes
<pitti> fabbione: me
<siretart> hm. gotta run to work, cu later!
<fabbione> torkel: do you have main upload privs?
<pitti> siretart: hm, I'm afraid that patch won't make a difference to me, so I'd not be a good tester
<torkel> fabbione: no
<fabbione> torkel: good.. pitti: you win :)
<siretart> pitti: right. I tried to explain the problem to you
<pitti> fabbione: I should run away really fast now, shouldn't I?
<torkel> fabbione: yay :-)
<fabbione> pitti: nah.. just a FTBFS
<pitti> fabbione: oh, I have some of them already, toss it over
<siretart> pitti: if you want the get n-m working on your notebook, first get wpa_supplicant working. It also supports unencrypted and wep 'secured' wifis
<fabbione> pitti: yes i know.. i saw you taking them.. already did :)
<pitti> siretart: hm, it's a dependency, I didn't really ever configure wpasupp
<siretart> pitti: n-m obviously fails to start up wpa_supplicant correctly
<pitti> ah, maybe
<siretart> pitti: first, you need to find what parameters are correct, then find out what n-m does wrong, then write a patch
<siretart> pitti: this is how this patch in question has been found
<pitti> siretart: you forgoth: 0. get an idea what the heck wpasupplicant is doing and why/how :)
<pitti> if I find some time, I'll take a look, but no promises
<siretart> pitti: it 'establishes' a connection to your wifi, regardless how it is secured
* siretart runs
<pitti> fabbione: your libapache2-mod-python ftbfs scares me - if the first patch doesn't apply, how it could ever build before?
<fabbione> pitti: it seems like autoconf is executed right before that
<fabbione> so it might be that it is running when it shouldn't?
<pitti> fabbione: ah, autoconf2.60 breakage then
<pitti> yay
<pitti> fabbione: yup, plausible
* pitti grabs the autotame bat
<Burgundavia> mdz: the reportbug to -users volume is growing again, just fyi
<dholbach> good morning
<pitti> hey dholbach 
<dholbach> heya pitti
<pitti> tfheen: libapache2-mod-python FTBFS fix uploaded (just removed 'autoconf' call from debian/rules)
<tfheen> pitti: ok
<mvo_> good morning dholbach
<dholbach> heya mvo_
<pitti> yay, gnat-gps finally built on i386 \o/
* dholbach high-fives pitti
<infinity> The one and only time it will? :)
<dholbach> pitti: congratulations! :-)
<pitti> infinity: no, pdfetex is happy now
<infinity> pitti: Oh, excellent.
<pitti> dholbach: *hug*
<pitti> infinity: I tooked a Kleenex, wiped away tetex' tears, gave it a big hug, and now it wants to play with us again :)
<Treenaks> KleeNTeX?>
<fabbione> ajmitch: are you actually filing bugs for the FTBFS in universe?
<infinity> pitti: Your efforts will not go unpuni^H^H^H^Hrewarded.
<fabbione> ajmitch: or are you getting people to look at the logs?
<infinity> pitti: Drinks all 'round in Mountain View. :)
<pitti> infinity: sounds great, who pays? :)
<pitti> Google does, right?
<pitti> 'Google Autumn of drink'
<infinity> I'm sure I can pay for one or two. :)
<pitti> infinity: I look forward to fixing all the FTSUFC bugs then
<pitti> (fails to stand up from couch)
<infinity> FTSUFC isn't nearly as bad as FTMITTWC (fails to make it to the toilet)
<pitti> yeah, I don't like core dumps on the carpet either
<infinity> Often shortened to "VIC" (vomits in cab)
<fabbione> LOL
<infinity> Not going to name any names, though.
<infinity> Oh look, more PAGE_SIZE breakage.
<infinity> Quel surprise.
<pitti> infinity: is it legitimate for a package to build-depend on linux-headers-generic?
<pitti> infinity: reiserfsprogs needs asm/unaligned.h, which does not exist any more in /usr/include (did until dapper)
<fabbione> pitti: well theorerically yes..
<pitti> linux-libc-dev apparently doesn't quite Provide linux-kernel-headers
<infinity> pitti: Well, it's either a bug that BenC doesn't provide it, or a bug that reiserfsprogs needs it.
<pitti> fabbione: I'm just worried about the name being the same on all arches
<fabbione> pitti: that should be ok...
<pitti> infinity: well, it needs {get,put}_unaligned macros; that seems quite legitimate to me
<pitti> and they aren't anywhere in /usr/include any more (I grepped)
<infinity> pitti: We don't have l-h-generic on all arches, of course.
<fabbione> infinity: ?
<infinity> BenC: Alive?
<fabbione> ah right
<pitti> infinity: ok, I'll postpone this until this afternoon; providing the include in linux-libc-dev would be the best solution, of course
<infinity> pitti: If it feels like legit userspace usage, I'd say the bug is in linux-libc-dev
<pitti> fabbione, infinity: ok, I processed the current batch and will fix some other bugs now, but I should have more time to fix FTBFS; so feel free to throw bugs at me
<fabbione> pitti: i am ... reload your page :)
<pitti> fabbione: ah, nice; you all make them prio: high, right?
<fabbione> yes
<fabbione> high -> confirmed -> targetted
<fabbione> so just reload the milestone page
<fabbione> or check for bugs assigned to you
<fabbione> the confirmed comes if i can reproduce the failure on more than one arch
<dholbach> can somebody sync libopenobex1.0 (bug 65840) and wave through the telepathy-blue upload?
<Ubugtu> Malone bug 65840 in libopenobex1.0 "Please sync libopenobex1.0 (1:1.0.0-rel-3.1) from Sid." [High,Confirmed]  http://launchpad.net/bugs/65840
<infinity> dholbach: MMkay.
* dholbach hugs infinity
<fabbione> dholbach: does that fix the FTBFS?
<dholbach> fabbione: yes
<fabbione> ok
<dholbach> mjg59, BenC, <anybody else who might know>: could you have a look at bug 32415? I'm not sure how to deal with it.
<Ubugtu> Malone bug 32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper Flight 4 & 6.06 beta 2" [Medium,Needs info]  http://launchpad.net/bugs/32415
<pitti> tfheen: bogl uploaded, fixes FTBFS
<tfheen> pitti: cheers.
<infinity> pitti: You're a champion.
<infinity> Can someone give me a status on these?
<infinity>   109032 | S- | libapache2-mod-pytho | 3.2.8-1ubuntu2       | 33 minutes
<infinity>          | * libapache2-mod-python/3.2.8-1ubuntu2 Component: main Section: python
<infinity>   109031 | S- | wine                 | 0.9.22-0ubuntu3      | 5 hours 50 minutes
<infinity>          | * wine/0.9.22-0ubuntu3 Component: universe Section: otherosfs
<pitti> fabbione: gtk-perl> '1/3649 subtests failed'? c'mon, who measures that precisely? :P
<infinity>   109027 | S- | qt4-x11              | 4.2.0-1ubuntu1       | 6 hours 20 minutes
<infinity>          | * qt4-x11/4.2.0-1ubuntu1 Component: main Section: libs
<tfheen> infinity: mod-python is approved.
<infinity>   108976 | S- | telepathy-blue       | 0.0.1.1~darcs2006092 | ten hours
<infinity>          | * telepathy-blue/0.0.1.1~darcs20060926-0ubuntu4 Component: universe Section: net
<mjg59> dholbach: I'll take a look at the weekend if nobody beats me to it
<infinity>   108971 | S- | gst-plugins-ugly0.10 | 0.10.4-0ubuntu3      | 12 hours
<infinity>          | * gst-plugins-ugly0.10/0.10.4-0ubuntu3 Component: universe Section: libs
<infinity>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 17 hours
<infinity>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
<fabbione> ARGH
<infinity>   108839 | S- | xdg-utils            | 1.0-0ubuntu2         | 19 hours
<dholbach> mjg59: Tahsnk so much!
<infinity>          | * xdg-utils/1.0-0ubuntu2 Component: universe Section: utils
<infinity>   108756 | S- | xdg-utils            | 1.0-0ubuntu1         | 21 hours
<infinity>          | * xdg-utils/1.0-0ubuntu1 Component: universe Section: utils
<infinity> tfheen: Thanks, accepted.
<dholbach> infinity: xdg-utils 1.0-0ubuntu2 is the good one - fixed by Riddell
<fabbione> infinity: libapache2-mod-python was uploaded to fix FTBFS approved by tfheen i think
<dholbach> infinity: telepathy-blue is a 2 line fix
<dholbach> infinity: what does the wine changelog say? I remember \sh_away uploading some sort of fix
<infinity>    * Re-apply dropped change from dapper:  (Closes: Ubuntu #63492)
<infinity>    + Remove insecure mailcap entries; MS Windows '.exe' files should be run
<infinity>      using 'binfmt-misc' support instead.  (Closes: Ubuntu #24829)
* tfheen ponders rejecting the ones which haven't gotten release team's approval prior to upload..
<dholbach> infinity: \sh_away can do his own cheerleading on those - I'm not sure about them :/
<dholbach> I think that gst-plugins-ugly0.10 has a fix of keescook for a rc bug "ac3 way too soft" or something like that
<infinity> dholbach: Actually, sladen uploaded that...
<dholbach> oh sladen, ok - then I was completely on the wrong track
<pitti> dholbach: yeah, that was given 'special importance' from Matt :)
* infinity acceptes bogl.
<infinity> dholbach: Does telepathy-blue need to wait on that sync I was doing, or are the two completely unrelated?
<dholbach> infinity: unrelated
<pitti> fabbione: can you please do me a favor? if you assign ftbfs stuff to me, can you please set it to 'in progress'? then it'll land on my special priority page
<tfheen> sladen: please provide a debdiff and rationale for the wine changes.  They don't seem to fix and 6.10-targetted bugs.
<fabbione> pitti: i am done for now...
<fabbione> pitti: will do next time
<pitti> thanks
<fabbione> pitti: last i assigned was netkit-base
<tfheen> dholbach: oh, wine's main.  Your decision, then.
<tfheen> s/main/universe/
<fabbione> tfheen: i finished mass filing for now... 
<dholbach> tfheen: as I said: I'm happy for sladen to do his own cheerleading for the changes - I'm not sure about it
<fabbione> we just need to wait the buildd's to keep munging sources
<dholbach> I just filed bug 65857, which is RC too
<Ubugtu> Malone bug 65857 in gnome-panel "Change Help menu link to help.ubuntu.com" [High,Unconfirmed]  http://launchpad.net/bugs/65857
<dholbach> it's blocked on the move of the book excerpt
<pitti> infinity: can re remove gnutls11 or do you want to keep it for anythin?
<infinity> pitti: I think it's pretty, and I like to look at it.
<infinity> (Yes, I can remove it)
* pitti looks again and does not find any pr0n in it
<tfheen> dholbach: just get the change done in the archive and we'll get the website when mdke (or whoever) gets around to that.
<infinity> -- edgy/multiverse build deps on libgnutls11-dev:
<infinity> ldmud
<infinity> pitti: ^^^
<dholbach> tfheen: the problem is that clicking on the gnome-panel link will lead to a 404 page
<pitti> infinity: yeah, as I said, that's the only package left that doesn't even build with gnutls11
<dholbach> tfheen: and the URL is not fixed either
<fabbione> pitti: can you please try to build strace on your x86 machine? it fails here with another error
<pitti> fabbione: yeah, I just built it on amd64
<tfheen> dholbach: can you get that finalised with the doc team or whoever's responsible ASAP?
<fabbione> pitti: i386
<pitti> fabbione: to confirm the fix with current pkg-create-dbgsym
<dholbach> tfheen: I subscribed mdke
<pitti> fabbione: I can try building it on ronne
<dholbach> tfheen: and reply to the mail on ubuntu-devel@
<fabbione> pitti: no, it fails way before that
<fabbione> pitti: see /msg
<fabbione> pitti: the dbg log stuff was from sparc
<infinity> pitti: Err, you mean it's FTBFS anyway, so screw it? :)
<pitti> infinity: *shrug*
<infinity> pitti: Works for me.  I have no love lots for some random non-free mud.
<infinity> s/lots/lost/
* pitti blows off the dust from gdome2 (last upload in 2003!) and fixes FTBFS
<infinity> Will remove the following packages from edgy:
<infinity>   gnutls11 | 1.0.16-14ubuntu1 | source
<infinity> libgnutls11 | 1.0.16-14ubuntu1 | amd64, hppa, i386, ia64, powerpc, sparc
<infinity> libgnutls11-dbg | 1.0.16-14ubuntu1 | amd64, hppa, i386, ia64, powerpc, sparc
<infinity> libgnutls11-dev | 1.0.16-14ubuntu1 | amd64, hppa, i386, ia64, powerpc, sparc
<infinity> ------------------- Reason -------------------
<infinity> (adconrad) Requested by pitti, no longer in use, and no urge to support it
<infinity> ----------------------------------------------
<infinity> pitti: ^^^
* pitti hugs infinity 
<infinity> Sane?
<infinity> *poof*
<pitti> "don't need no triplicate version" :)
<tfheen> Riddell: how come your qt4-x11 changelog doesn't list all outstanding changes?
<pitti> tfheen: gdome2 FTBFS fix uploaded
<infinity> Yeah, while I've not cared much about (insert random thing I haven't cared about here) during edgy's cycle, we really need to dust off ReducingDuplication for feisty.
<tfheen> pitti: yay you
<tfheen> pitti: you're trying to get us to beer you through the whole conference?
<pitti> tfheen: (well, I keep reporting these to you for approval sake; please do tell me if I shuold stop annoying you)
<infinity> Reporting them is good.
<infinity> I need to know what to shove through the queue.
<pitti> tfheen: I'm trying to get me enough appetite for beer for two weeks :p
<infinity> And we also need to know who's making us look bad. :)
<pitti> well, with me touching all these packages, I also have to merge them *shudder*
<infinity> ../../../interfaces/IDirectFBVideoProvider/idirectfbvideoprovider_v4l.c:47:28: error: linux/compiler.h: No such file or directory
<infinity> Can someone explain to me why a userspace app wants compiler.h?
<infinity> Seriously.
<infinity> WTF?
<Kamion> Riddell: language packs and metapackages> right - there's no metapackage for live any more, there never was for ship, so no need to upload *-meta for language pack changes
<dholbach> LOL - did you see the humping weasel on  http://wiki.ubuntu.com/IceWeaselIcon ?
<Chipzz> is there a list of valid values for 'Section' available somewhere?
<tfheen> pitti: reporting is good.
<infinity> dholbach: There's also the goatse weasel.
<Kamion> ajmitch: bzr-svn> yes, that's fine
<dholbach> infinity: ouch ouch ouch
<tfheen> pitti: we might need to shuffle the merges or something.
<pitti> oh, don't worry, I'll cope
<fabbione> infinity: dunno.. but i filed a bug on that already and assigned to BenC
<tfheen> pitti: who-touched-it-last-maintenance only works for so long, really.
<fabbione> infinity: directfb fails in different ways on different arches.. all kernel headers realted
<infinity> fabbione: Ahh, well it has two bugs (that and a PAGE_SIZE bug), I found the former only after fixing the latter. :)
<fabbione> infinity: if you are going to fix it, you might as well take the bug..
<infinity> Yeah, I'll snag it if I fix the compiler.h thing.
<fabbione> sounds like a viral form of somekind...
<fabbione> i got FTBFS... HIV was not enough
<infinity> This whole "build the userspace linux headers from the kernel source" idea would have been great if it had also been accompanied with a "rebuild the archive right after we make the switch".
<infinity> Oh well.
<fabbione> infinity: we need to do that each time we change kernel or ben uploads.. go figure
<Keybuk> infinity: it didn't help that jbailey and BenC conspired to omit headers they found distasteful, etc. :)
<infinity> Keybuk: Well, I'm inclined to agree that we shouldn't ship compiler.h (for example), I just wish I'd have known a couple months back. :)
<heno> Kamion, tfheen: Tested the Live CD + F5. Everything starts as it should except onboard
<infinity> Automatic rebuilding in Soyuz will likely be my number one crusade in Mountan View.
<heno> I found the problem and made a patch though
<tfheen> heno: yay.  Big one?
<heno> bug 65861
<Ubugtu> Malone bug 65861 in casper "onboard fails to start with F5 boot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65861
<heno> tfheen: 1 line
<tfheen> heno: ok, coolie.  I'll trawl the rest of my morning mail and get it applied.
<heno> tfheen: thx!
<heno> tfheen: a general question: do all bugs have to be targeted to get patched from now on?
<heno> or will other minor fixes go in as well?
<infinity> Oh wow, I'm a special kind of retarded.
<infinity> Edit file on machine A, build source tree on machine B, wonder why it still fails the same way.
* infinity grabs a coke and pays more attention to the hostname in his prompts.
<ajmitch> Kamion: thanks
<Kamion> Chipzz: should be a pretty current list in debian-policy, though add "metapackages" to it
<Keybuk> infinity: when did you last sleep?
<Kamion> heno: nice
<infinity> Keybuk: I don't understand the question.
<tfheen> heno: only targetted bugs.
<heno> ok
<infinity> I love packages with, like, 5 minutes of autotools buggery followed by about 3 seconds of compiling.
<infinity> Something always seems a bit wrong there.
<dholbach> Keybuk: welcome to the bluetooth team - can you help with bug 32415?
<Ubugtu> Malone bug 32415 in bluez-utils "Bluetooth Mouse and Keyboard Broken in Dapper Flight 4 & 6.06 beta 2" [Medium,Needs info]  http://launchpad.net/bugs/32415
<infinity> Wow, is that all it takes?
<tkamppeter> hi pitti
<pitti> hi tkamppeter 
<infinity> dholbach: Welcome the "Adam's Bitch" team.  I'll start forwarding you build logs.
<dholbach> infinity: you're so funny :-)
* dholbach hugs infinity
<tkamppeter> I have added a comment to bug 54277, I have done on Edgy what the original poster was supposed to do on Dapper
<Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Fix released]  http://launchpad.net/bugs/54277
<infinity> That's why you love me. :P
<ajmitch> fabbione: was going to start filing bugs this evening
<tkamppeter> And it seems that Edgy is still suffering the bug.
<dholbach> infinity: and because you played together with LTJ Bukem - that's SO cool
<pitti> tkamppeter: ah, cupsd itself chowns the files back, it seems
<fabbione> ajmitch: ok. keep in mind that there is not much time..
<infinity> dholbach: Same show, not TOGETHER. :)
<ajmitch> fabbione: I know
<pitti> tkamppeter: however, did you use the official edgy packages or upstream's?
<infinity> dholbach: But, y'know, we did hang out a bit afterward.
<dholbach> infinity: still, that's  S O  cool!
<infinity> dholbach: MC Conrad can really (REALLY) inhale coffee. Like.  A lot.
<tkamppeter> I have reopened the bug and assigned it as an Edgy milestone
<Keybuk> dholbach: that sounds somewhat PPC specific?
<fabbione> infinity: did you file a bug on klibc already?
<pitti> tkamppeter: well, does it actually harm?
<dholbach> Keybuk: one guy said it was on x86 too
<infinity> fabbione: jbailey's got the logs for all 5 arches, and has promised me he'd look into it.
<tkamppeter> pitti, all official Ubuntu packages coming in from the usual Debian morning gymnastics.
<pitti> ok
<GNUro> hi all
<GNUro> ubuntu live cd contains xfs_repair?
<tkamppeter> according to /etc/group cupsys has only read access to error_log and so I cannot imagine how CUPS (running as cupsys) can do the logging.
<fabbione> infinity: ok
<pitti> tkamppeter: I assume it first opens the files and then chowns them
<Treenaks> tkamppeter: it might have opened the file, and then dropped to another uid?
<tkamppeter> Treenaks, this was my thought now, too, as the file is growing.
<tkamppeter> Can we be sure that the CUPS daemon NEVER loses error_log while it is running?
<Treenaks> the only way to "lose" it is to close the filehandle
<Treenaks> and I wouldn't do that :)
<tkamppeter> Once when I tested faxing with HPLIP, CUPS was not logging at all until I restarted it (I had "LogLevel debug" set in cupsd.conf all the time).
<pitti> we should fix it nevertheless, but it doesn't seem that urgent
<pitti> tfheen: strace FTBFS uploaded
<pitti> tkamppeter: hm, I thought you reopened it? it's still marked as fixed
<Kamion> mvo: something's excitingly wrong with apt-get install taskname^
<Kamion> mvo: it seems to only handle the first task on the line
<tkamppeter> I have set the Edgy task to "Confirmed".
<Kamion> mvo: try 'apt-get --dry-run -q -y install edubuntu-live^ kubuntu-live^'
<tfheen> pitti: yay.
<tkamppeter> Ubugtu, WDYT: bug 54277
<Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Confirmed]  http://launchpad.net/bugs/54277
<pitti> tkamppeter: ah
<infinity> infinity: Permission to upload a directfb to fix two FTBFS bugs?
<infinity> infinity: Sure, go nuts.
<infinity> infinity: Thanks.
<pitti> lol
<infinity> Keybuk: To answer your question, "a long time ago".
<Kamion> mvo: your task regex also looks a bit suspicious
<Kamion>    snprintf(S, sizeof(S), "^Task:.*[^a-z] %s[^a-z] .*\n", taskname);
<Kamion> mvo: doesn't that do weird things if the task you select is at the end of the Task field?
<tkamppeter> By the way, is someone here who has one of the printers HP LaserJet 100, 1005, 1018, or 1020?
<tkamppeter> Sorry LaserJet 1000 and not 100.
<pitti> argh, libgtk2-perl is giving me the creeps
<pitti> fabbione: I can't reproduce the libgtk2-perl FTBFS you filed, but the testsuite failed in a different script in exchange
<fabbione> pitti: i think it's related to Xvfb somehow
<fabbione> i saw different kind of FTBFS
<pitti> I'll get to a closer look later
<fabbione> one of which Xvfb segfaults if X is running
<infinity> pitti: Is that strace upload yours?
<infinity> Ahh, so it is.
<pitti> infinity: unless someone beat me with it, yes
<pitti> infinity: the autoconf mangling for ftbfs fix
<infinity> You realise we're all going to get fired in two weeks, with a big note saying "how come you can't fix this many bugs per day during the reast of the cycle?"
<DrSpin> I know you guys are hard at work on Edgy and I can't wait but in the meantime I have a problem with GNOME on Breezy -- for no apparent reason GNOME takes a long time to load... here's the post in the main channel that received no response.
<infinity> Just so you know.  No pressure to underperform or anything, though.
<DrSpin> (01:45:24 AM) DrSpin: DAPPER: Gnome takes FOREVER (3-5 minutes) to start -- tried 386,686,686-SMP kernels and it's faster with SMP (hyperthreading) :: .xsession-errors contains "Gnome-Message: gnome_execute_async_with_env_fds: returning -1" -- google doesn't seem to turn up a logical solution -- tried dpkg-reconfigure gconf2 as well -- any ideas?
<pitti> because we are just lazy bastards playing games and watching p0rn during the development cycle, aren't we?
<infinity> DrSpin: Just because you didn't get help elsewhere doesn't make this a support channel.
<mvo> Kamion: urgh, thanks. let me check that 
<tfheen> pitti: bogl FTBFS-ed on ia64 and ppc ; http://librarian.launchpad.net/4821823/buildlog_ubuntu-edgy-powerpc.bogl_0.1.18-1.4ubuntu3_FAILEDTOBUILD.txt.gz 
<pitti> nnng
<DrSpin> infinity: I know... but It occurred to me that someone in here might have a quick solution -- rather than wading through conversations about wine and how do I <insert topic on wiki, forums here>
<pitti> tfheen: will fix, thanks
<infinity> pitti: I'll fix, that's one I've fixed a dozen times already.
<pitti> infinity: oh, ok; thanks
<infinity> DrSpin: And once that occurs to a few more people, we get no work done here.
<DrSpin> infinity: understood... my apologies
<pitti> tfheen: netkit-base ftbfs fix uploaded
<Kamion> mvo: just trying to trace it with gdb now
<seb128> tfheen: http://people.ubuntu.com/~seb128/gdm.debdiff, the diff is not trivial but that's basically a copy of the suspend code for hibernate (the hibernate patch was already copied from the suspend one, some parts were missing though). somebody confirmed on the bug that the patch update works fine for him
<infinity> tfheen, pitti: bogl reuploaded.
<tfheen> seb128: ew, ugly; it'd be slightly less bad if you didn't include the updated patch headers.
<tfheen> seb128: approved though, it doesn't look wrong.
<heno> Riddell: the high contrast and magnifier modes look lovely on the Kubuntu Live CD :)
<heno> just did some testing
<seb128> tfheen: right, will do next time, thank you
<Keybuk> thom: around?
<ajmitch> Keybuk: is there much in unapproved for universe? I know zope-cmfmember can be put through if it's not already
<infinity>   109031 | S- | wine                 | 0.9.22-0ubuntu3      | 7 hours 10 minutes
<infinity>          | * wine/0.9.22-0ubuntu3 Component: universe Section: otherosfs
<infinity>   108971 | S- | gst-plugins-ugly0.10 | 0.10.4-0ubuntu3      | 14 hours
<infinity>          | * gst-plugins-ugly0.10/0.10.4-0ubuntu3 Component: universe Section: libs
<ajmitch> thanks infinity 
<infinity>   108871 | S- | zope-cmfmember       | 1:1.1b2-1ubuntu1     | 19 hours
<infinity>          | * zope-cmfmember/1:1.1b2-1ubuntu1 Component: universe Section: web
<infinity> ajmitch: ^^^
<pitti> to all people having a ThinkPad: do the brightness control keys DTRT? which model do you have? (for bug 61184)
<Ubugtu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  http://launchpad.net/bugs/61184
<tfheen> pitti: works for me, x40.
<infinity> pitti: I have a T43, and it works fine.
<pitti> ok, thanks; the bug demands extending the match to other thinkpad models
<seb128> tfheen: when would be the limit to upload an yelp package with translations update?
<infinity> seb128: Same as the langpack deadline (right after RC), I'd suspect.
<seb128> infinity: i:e. today?
<infinity> tfheen: Opinion?
<seb128> ah, after RC
<infinity> seb128: No, final langpacks are going in right AFTER RC.
<seb128> ok ok
<infinity> (like, immediately after)
<pitti> infinity: if you replace 'string="ThinkPad T60"' with 'contains="ThinkPad"' in /usr/share/hal/fdi/policy/10osvendor/10-laptop-panel-mgmt-policy.fdi and restart hal and your session, does it still work? (just to confirm a bug repoerter's claim)
<infinity> Ish. :)
<tfheen> seb128: it doesn't use langpacks?
<pitti> tfheen: not the help files
<infinity> tfheen: HTML.
<seb128> tfheen: no, translated .xml built at build time
<infinity> (Or ML, or whatever)
<infinity> XML, even.
<infinity> pitti: Why does "Restart hal and your session" sound like it will bugger my desktop? :)
<seb128> tfheen: xml files are not language-pack-able atm
<Keybuk> tfheen: how badly do we feel that cryptsetup doesn't work?
<tfheen> seb128: ok.  The translation deadline was yesterday, any reason you can't upload it today?
<pitti> infinity: /etc/dbus/event.d/20hal restart and gdmflexiserver to a different user will work as well
<tfheen> Keybuk: with usplash or at all?
<infinity> pitti: Alright.
<Keybuk> tfheen: at all
<seb128> tfheen: no, I did an upload previous week, I just wanted to do another update with updated translations before edgy, I'll do it now if that's ok
<pitti> Keybuk: at all? my encrypted usb stick works fine
<Keybuk> pitti: you get asked for a password on boot?
<pitti> but I guess a dapper->edgy upgrade will break people's computers if they have encrypted hard disk partitiosn
<tfheen> seb128: yes, now is fine.
<pitti> Keybuk: it's not automounted at boot
<tfheen> seb128: I'm going to start building real candidate isos on monday, so it needs to be in before then.
<seb128> ok
<seb128> this morning should be fine then
<Keybuk> pitti: right, those people that have things automounted on boot, now don't, because cryptsetup won't ask for a password
<ajmitch> infinity: please accept wine & gst-plugins-ugly0.10
<infinity> pitti: That didn't appear to break it.
<pitti> infinity: thanks; to be 100% sure, lshal|grep brightness?
<tfheen> Keybuk: cryptsetup is universe.  I don't really care.
<pitti> (without the ?)
<siretart> Keybuk: does cryptsetup work with sysvinit?
<infinity> udi = '/org/freedesktop/Hal/devices/acpi_brightness'
<infinity>   info.udi = '/org/freedesktop/Hal/devices/acpi_brightness'  (string)
<infinity>   org.freedesktop.Hal.Device.LaptopPanel.method_execpaths = {'hal-system-lcd-set-brightness', 'hal-system-lcd-get-brightness'} (string list)
<infinity>   linux.acpi_path = '/proc/acpi/ibm/brightness'  (string)
<tfheen> pitti: didn't you upload a fixed debug-thingy-mangler?
<Keybuk> siretart: if we used sysvinit, we would make the same change as we did to upstart, to make the output get logged to /var/log/boot instead of to the console
<infinity> tfheen: He did.  A few.
<pitti> infinity: hm, that looks wrong
<pitti> tfheen: several
<pitti> tfheen: what breaks now?
<infinity> pitti: I assure you that it's not wrong. :)
<tfheen> pitti: unsure, but gcc-3.3 is still out of date.
<infinity> tfheen: On which arch?
<tfheen> it might just be that neither Adam nor I gave it back
<tfheen> infinity: amd64
<pitti> infinity: I expected laptop_panel.brightness_in_hardware=true
<tfheen> looked like the debug problem last time
<infinity> pitti: Well, if it did that, it'd probably also fail to work.
<infinity> tfheen: Retrying, then.
<pitti> tfheen: I fixed the gcc-4.0 ftbfs yesterday in pkg-create-dbgsym
<siretart> Keybuk: err, sysvinit is still around as alternative, no?
<pitti> infinity: ah, well, your's might not be from smbios.system.manufacturer=LENOVO then
<infinity> pitti: How can I check?
<pitti> infinity: lshal|grep smbios.system.manufacturer
<infinity>   smbios.system.manufacturer = 'IBM'  (string)
<infinity> Yeah.  I'm old skool, I guess.
<pitti> infinity: ok, thanks a lot
<Keybuk> siretart: not a supported alternative, no
<siretart> Keybuk: ah, but available as alternative in universe, right?
<infinity> Still in main, actualy.
<Keybuk> infinity: yeah, I just fixed that ;)
<infinity> If we really don't want to support people swapping, we should demote it to prove the point.
<infinity> Ahh, good. :)
<siretart> Keybuk: just for my understanding, would disabling logging (e.g. by disabling /etc/event.d/logd) 'unbreak' cryptsetup?
<Keybuk> it's in main because we haven't kicked hppa out of the world yet
<Keybuk> siretart: adding "console owner" to /etc/event.d/rcS would fix it
<Keybuk> also adding a call to /usr/bin/openvt would fix it
<siretart> Keybuk: hm. how about writing an /etc/event.d/ file for cryptsetup, and removing the old initscript?
<siretart> s/removing/disabling/
<Keybuk> siretart: where would it be run? :)
<Kamion> mvo: hmm, never mind, I think that was a false alarm due to a broken local mirror
<Kamion> mvo: I do think that the task regex should maybe be more like this?
<Kamion>    snprintf(S, sizeof(S), "^Task:.*[^a-z] %s([^a-z] |$).*\n", taskname);
<Kamion> or ([^a-z] .*|$)\n
<pitti> tfheen: ok to upload a hal with fixed laptop panel FDI to fix bug 61184?
<Ubugtu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  http://launchpad.net/bugs/61184
<Keybuk> tfheen: ok to approve squashfs FTBFS fix, bug #65826
<Ubugtu> Malone bug 65826 in squashfs "FTBFS in edgy" [High,Fix released]  http://launchpad.net/bugs/65826
<mvo> Kamion: right, I check that in a bit. a unreleated question, would it be possible to get openoffice.org-l10n-en-us onto the cd? it makes apt majorly unhappy to not have it for cd-cd upgrades (without any networking). it seems like this is the only blocker for this upgrade scenario
<pitti> shouldn't it be on the CD anyway?
<pitti> mvo: ooo-common depends on it
<pitti> mvo: whoops, sorry, it replaces/provides it
<mvo> pitti: it isn't currently, only en-gb and en-za and -common
<pitti> mvo: right, -en-us doesn't exist any more
<seb128> dholbach: will we get ubuntu-docs translations for edgy?
<infinity> Perhaps an empty transitional package might make apt happier here?
<mvo> pitti: yeah, its  apt being stupid and not understanding that during the upgrade calculation
<dholbach> seb128: I don't know - best to ask mdke or people in #ubuntu-doc
<infinity> That's often easier than fixing apt bugs. :)
<mvo> infinity: we have that in the archive already, we just need it on the CD and apt should be happy
<mvo> infinity: oh yes :)
<seb128> mdke_: ping?
<seb128> dholbach: so nobody from distro team is looking at that? :/
<infinity> mvo: Ahh, so we do.
<Kamion> mvo: sure, shove it in ship
<dholbach> seb128: I can ask the #ubuntu-doc guys
<infinity> mvo: Given that it's a tiny package, I say toss it in ship without asking. :)
<seb128> dholbach: please do
<infinity> mvo: Or, better yet, listen to Kamion. :)
<Kamion> same difference ;)
<infinity> 'Zactly. :)
<infinity> Kamion: Everyone should listen to you when you agree with me, I think that was the point being made. :)
* infinity runs to the store.
<micahcowan> What's a good way to prepare for the Mtn View conference? Read up on a slag of specs? Are some better to read up on than others?
<Treenaks> micahcowan: beer. definitely beer.
<micahcowan> :)
* mvo hugs Kamion infinity
<tfheen> pitti: yes
<pitti> tfheen: done
<tfheen> Keybuk: yes, please.
<Kamion> infinity: :-)
<Keybuk> micahcowan: I find the best preparation is sleeping for a few days in advance, because it's something you don't get to do much of whilst there
<micahcowan> :-)
<dholbach> seb128: <pepsiman> 07:58 < mdke> the translations are seriously error-ridden bt, <pepsiman> entities, tags were translated/moved, <pepsiman> eg "translating &thankyou; to &gracias;", <pepsiman> 07:59 < mdke> I sent an angry email to the translators about it
<seb128> dholbach: that sucks a lot, maybe we should revert to dapper ubuntu-docs package :p
* seb128 runs fast
<dholbach> seb128: propose that to the ubuntu-doc team
<pepsiman> mdke is trying to fix it, but it may take a while
<seb128> we don't have a while
<pitti> ouch @ &gracias;
<dholbach> seb128: I'll watch them throwing stones at you
<pepsiman> seb128: he said "several hours"
<mvo> Kamion: I updated "ship" now, thanks! do we have a plan yet when we build the next set of cd-test-images?
<Kamion> mvo: they're still on the daily schedule
* dholbach hugs mdke_ and pepsiman
<Kamion> but I think I'll probably do another build later today
<mvo> Kamion: cool, thanks. if you could announce that in the channel here, that would be perfect
<Kamion> sure
<Keybuk> fabbione: bug #65838 is a bug in xserver-xorg-dev
<Ubugtu> Malone bug 65838 in wacom-tools "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65838
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/tasksel.diff, http://people.ubuntu.com/~cjwatson/tmp/pkgsel.diff - both in unapproved
<Keybuk> the headers contain two different definitions of xd86usleep, one as a macro that expands it to just usleep() and the other that defines it as a function that takes unsigned long
<Kamion> those fix my two remaining RC bugs
<fabbione> Keybuk: i didn't dig all of them .. just noted FTBFS and assigned to who touched last. You are welcome to reassign it :)
* Kamion grabs the iptables and liblockfile FTBFS bugs
<fabbione> Keybuk: i am still mass-filing 
<infinity> Kamion: Thanks, I was waiting for someone to take iptables. :)
<fabbione> Kamion: congratulation on iptables
<fabbione> Kamion: now.. look in a mirror and ask yourself why i didn't assign it to myself :P
<Kamion> heh
<Kamion> if I get stuck I can always give it back to nobody; nobody's a really excellent hacker
<fabbione> Kamion: i am sure nobody will fix that
<fabbione> Kamion: otherwise assign it to pitti.. he seems to be in a good mood today
<pitti> MUST...KILL..ALL..FTBFS...*nnnngh*
<ajmitch> pitti: we'll try & keep up the bug filing for you then :)
* infinity decides it's time to start hacking the launchpad_prod DB.
<infinity> Don't tell anyone!
<seb128> keescook: thanks for the gst ac3 fix ;)
<mooey> pitti, howdy. can i pm please?
<pitti> mooey: sure
<pitti> mooey: I'll answer shortly, brb
<ajmitch> hm, I wonder why gtk-sharp-unstable is still in the archive
<Keybuk> tfheen: ok to upload wacom-tools to fix FTFBS bug #65838
<Ubugtu> Malone bug 65838 in wacom-tools "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65838
* mvo takes dhcp
<tfheen> Kamion: why does tasksel still depend on aptitude then?
<tfheen> Kamion: pkgsel looks good to me
<Kamion> tfheen: for the manual selection mode
<Kamion> the versioned dependency is for --visual-preview
<Kamion> you know, for iptables, it might be best to just sync with Debian
<Kamion> +  * updated to Linux kernel 2.6.17 source
<tfheen> Kamion: tasksel> approved
<tfheen> Keybuk: go ahead
<infinity> Kamion: If Debian's iptables builds, I'm certainly not 100% against that idea.
<Kamion> it would still need to be hacked to use linux-libc-dev, so it's not a trivial option
<Kamion> I'll see how much work it is to fix up our current version
<infinity> tfheen: https://launchpad.net/+builds/+build/255478 <-- Enjoy.
<Keybuk> I worry about how much time and code went into the queue tool to make it print things like "a minute", "3 hours", etc.
<infinity> tfheen: Were there any other suspicious "this looks like P-a-s breakage" things on the out-of-date list?
<tfheen> infinity: who-ho.
<tfheen> infinity: none I saw, no.
<infinity> Keybuk: That's common code throughout all of LP (perhaps from an underlying python lib even)
<Kamion> Keybuk: instead of like "3:01" which would be much more useful and readable anyway
<infinity> pitti: Was that hal upload approved?
<infinity> tfheen: ^^^
<tfheen> infinity: yes.
<infinity> Accepted, then.
<dholbach> tfheen: ok, to upload  http://daniel.holba.ch/temp/bluez-utils.debdiff ?
<tfheen> infinity: directfb still blows up on amd64 and i386
<infinity> tfheen: Seriously?  There were THREE bugs in there?
<infinity> Serves me right for only testing on PPC.
* infinity looks.
<infinity> Ooo, ugly.
<tfheen> dholbach: any reason you can't rather fix it by fixing bluez-gnome?
<tfheen> dholbach: if we're to have an upload for it, I'd rather have a fixed b-g, tbh
<fabbione> infinity: test sparc too please. that's where i found the bug
<dholbach> tfheen: it's a fix in bluez-gnome CVS - I can imagine that it's not small
<infinity> fabbione: sparc built fine.
<fabbione> infinity: hmmm ok
<pitti> re
* mvo goes for lunch
<dholbach> tfheen: I'll have a look
<pitti> ogra: bah, currently esdsink is sorted below osssink for some reason
<ogra> heh
<ogra> silly
* pitti investigates why
<tfheen> fabbione: could you please fix the ttf-bpg-georgian-fonts ftbfs?
<fabbione> tfheen: 
<fabbione> tfheen: looking at it but the missing file is crucial
<dholbach> tfheen: ok, tried bt-applet cvs, works fine, seems to not display the icon, if you have no hci<n> device, which is a first step - the code diff is ~900 lines -- it's supposed to have a gconf key, but the gconf schemas seem to not have been written yet, so you can only control it by gconf, if you added the key manually
<Keybuk> Oct 12 12:18:55 rcS: setupcon: The console-chars utility from the console-setup 
<Keybuk> font can load only fonts witn 8 pixel width matrix.  Please install the setfont 
<Keybuk> utility from the kbd package.
<Keybuk> Kamion: ^
<fabbione> tfheen: no, we need mjg59 to give us the missing file.. it's an XML mess
<tfheen> dholbach: not displaying the icon if you don't have a HCI adapter is a one-line change.
<Kamion> Keybuk: yes, don't use one of the fonts in question then
<Kamion> Keybuk: bug filed, wontfix until edgy+1
<tfheen> fabbione: it's completely missing from the source, not just misplaced?
<fabbione> tfheen: missing
<tfheen> fabbione: ok. :-/
<tfheen> fabbione: thanks
<Keybuk> Kamion: which fonts are in question?
<fabbione> tfheen: checking again..
<Keybuk> Kamion: this is just an ordinary dapper->edgy upgrade
<fabbione> tfheen: yeah it's missing..
<fabbione> i don't know how to write stuff like that.. sorry
<fabbione> Keybuk: ttf-bpg-georgian-fonts
<tfheen> fabbione: ok, no problem.  I'll try to get it from Matthew
<Kamion> Keybuk: hmm, I'll check whether the switch back to VGA affects this
<tfheen> fabbione: Keybuk/Kamion's font discussion is about console-setup, not the georgian fonts.
<Keybuk> Kamion: "switch back to vga" ?
<tfheen> dholbach: I wonder if we should make it only display the icon when it wants to blink it
<fabbione> oh sorry
* fabbione got confused
<Keybuk> Kamion: the console doesn't appear to be running a framebuffer
<infinity> tfheen: brltty/{powerpc,ia64} rescued.
<dholbach> tfheen: hm, that's a diff we'd have to maintain post-edgy
<tfheen> infinity: cheers.
<dholbach> tfheen: better make it not show and discuss options with upstream for edgy+1
<Kamion> Keybuk: you're missing the point slightly but I would have to explain too much of console-setup's internals to explain why :-)
<Kamion> Keybuk: upgrade to what vintage of edgy?
<tfheen> dholbach: upstream thinks it should always display a useless icon?
<Keybuk> Kamion: that reboot would have been due to an update
<Kamion> Keybuk: and could you put your /etc/default/console-setup somewhere for me?
<dholbach> tfheen: he wants to have it controllable by a gconf policy
<Keybuk> http://people.ubuntu.com/~scott/console-setup
<Kamion> Keybuk: (whether the console is actually running a framebuffer is not relevant here)
<tfheen> dholbach: but you can't interact with it in any way except get the "about" dialog up.
<Kamion> ah, terminus 12x6 is the default Terminus font
<Kamion> that's irritating
<dholbach> tfheen: I absolutely agree with you and I think it should be fixed
<Kamion> Keybuk: ok, thanks, I'll see if I can munge this on upgrade somehow
<dholbach> tfheen: but we should make an easy fix for the release
<Keybuk> Kamion: my laptop appears to have FONTSIZE="16" there
<tfheen> dholbach: is upstream around now?  As in, if I give you a diff, can you get him to agree to it?
<Keybuk> ooh, I like TerminusBoldVGA :p
<Kamion> yeah, that's weird, 16 is the default
<dholbach> tfheen: it's 'holtmann' in launchpad
<Kamion> I think there may be a really subtle use-of-debconf bug here
<dholbach> tfheen: he's on the bluetooth team, so he'll be notified of changes to bug 65645
<Ubugtu> Malone bug 65645 in bluez-gnome "Die systray icon die!" [Undecided,Fix released]  http://launchpad.net/bugs/65645
<Kamion> because at some point it's obviously picked the first option rather than the one in Default:
<infinity> Ngh, the gcc-3.3/amd64 failure isn't pitti's fault, I should have read the log before I wasted an hour on the build retry.
<infinity> doko__: http://librarian.launchpad.net/4822231/buildlog_ubuntu-edgy-amd64.gcc-3.3_1%3A3.3.6-13ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> doko__: While you're at it, gcc-3.3 is FTBFS on ia64 too, but for different reasons.
<Kamion> Keybuk: so do you reckon I can reproduce this by installing dapper and upgrading to edgy?
<tfheen> dholbach: he's not on IRC?
<pitti> infinity: we only need it to keep libstdc++5-3.3 for commercial apps, right?
<Keybuk> Kamion: should do; this was installed fresh dapper from the CD.  kept up to date.  and then upgraded to edgy this week
<dholbach> tfheen: I don't know - he replied to a bunch of bugs, but I never talked to him on IRC and he has no IRC nick registered in his launchpad account
<Keybuk> I generally make a point of not touching anything in /etc as well
<infinity> pitti: Pretty much, yeah.
<infinity> pitti: It's also somewhat handy for GCC regression testing, but that argument's beginning to wear thin.
<Kamion> Keybuk: all right, thanks
<tfheen> dholbach: ok.  I'll whip up a patch and see if that's acceptable.
<dholbach> tfheen: super
<Keybuk> I have a vmware image that I only upgraded yesterday
<Keybuk> let me check that
<doko_> infinity: yes, low priority.
<Keybuk> that's i386, but not sure that makes a difference or not
<Kamion> I don't *think* it should
<Kamion> Keybuk: the other is amd64?
<dholbach> tfheen: hang on, he just attached a patch to the bug
<Keybuk> Kamion: yes
<Keybuk> Kamion: my vmware install and upgrade exhibits the same bug
<Keybuk> so this is definitely replicatable
<Kamion> apart from hppa (which asks for model) and sparc (which uses the sun4 model and asks for model), all the architectures we support are equivalent from console-setup's point of view, I think
<dholbach> tfheen: seems he extracted the strictly necessary bits from the cvs checkout
<Keybuk> that's an image with dapper installed from CD and updated.  and then updated to edgy from the repos
<Kamion> ok, great, thanks, I'll just get my local mirror up to date and try that
<Kamion> Keybuk: dapper installed from d-i or ubiquity?
<Keybuk> Kamion: u6y
<Kamion> righto, in progress
<tfheen> dholbach: that patch mixes features with something not exactly what we want.
<tfheen> dholbach: do you agree that the sane way for the icon to work is to display an icon when you can interact with it?
<tfheen> dholbach: so since you can't put you BT device into discoverable mode or similar yet, it should only be there when somebody tries to pair.  Agreed?
<dholbach> you can set it to discoverable mode with the version in CVS, but yeah, that's one possibility that makes sense
<dholbach> having it around, when you have a hci device makes sense for some people too, but that's something we should have in edgy+1 with upstream's blessing.... I'm sure that if you attach a patch, Marcel will reply on it
<tfheen> dholbach: I'm not going to pull in the version from CVS.  I want the icon to behave sensibly as described above.  Neither "display always", "display when there are adapters present", "never ever display icon" doesn't match any of those
<tfheen> dholbach: I'm happy to have this conversation with upstream, sure.
<tfheen> I just want us to agree to a sensible behaviour before writing code.
<pitti> ogra: hm, I'm pretty stuck with this; gstreamer does not seem to load the esdsink automatically any more, so it doesn't even have a chance of registering itself
<ogra> pitti, gah
<dholbach> tfheen: for edgy, I agree, it makes sense
* infinity tries to decide if he should quit for the weekend, or kick over into "crunch mode" and work into the wee hours of the morning...
<ogra> pitti, well, then my only chance is to set the gconf key, but thats darn ugly
<dholbach> tfheen: for edgy+1, it should be configurable, and I'm sure that upstream will consider your case as another gconf option, if we talk to him about it
<pitti> ogra: oh, I can still ask the mighty seb128, maybe he has an idea
<dholbach> tfheen: (and we can make it default)
* ogra prays to the mighty one
<infinity> kylem: Why is palo arch:any?
<fabbione> infinity: in the hope to take over the world? :)
<pitti> ogra: hm, sometimes it *is* registered, and sometimes not; bwah
<ogra> thats weird
<infinity> fabbione: No one in their right mind would want that.
<infinity> fabbione: It may not be as bad as silo, but it's pretty bad. :)
<ogra> is theer a commandline to show the registered one ?
<pitti> ogra: I didn't find one, I hacked gstreamer0.10 to printf() gst_element_register() invocation
<ogra> ah
<pitti> ogra: it doesn't have an useful gstreamer logging call
<pitti> hi BenC 
<pitti> BenC: kernel panic mode on
<fabbione> infinity: eheh
<tfheen> fabbione: I've seen many weird misspellings, but never seen "grub2" misspelled as "palo".
<Kamion> infinity: palo is used by debian-cd to make hppa CDs bootable. Please don't make it Architecture: hppa.
<infinity> Kamion: I wasn't planning on it.
<Kamion> anyway, that's probably why
<infinity> Kamion: More to the point, I was wondering if it's worth caring that it's currently FTBFS on all arches.
<infinity> Kamion: I'll care anyway. :)
<Kamion> I think so, given that we use it on lithium on i386
<Kamion> no, amd64
<fabbione> tfheen: it's a matter of Itaglish/Ameritalian/Engrish
<doko_> heh, Fri Oct 13 13:13:13 CEST 2006
<doko_> where's the black cat?
* HiddenWolf doesn't meow
<HiddenWolf> sorry ;)
<pitti> doko_: ugh
<tfheen> dholbach: http://err.no/patches/bluez-gnome-disable-icon-when-inactive.diff
<tfheen> (actually, reload, I reworked it slightly)
<infinity> Kamion: Now that P-a-s works correctly, any objections to removing old pbbuttons binaries on !powerpc?
<Kamion> infinity: no - done
<dholbach> tfheen: looks good - seems to work ok
<mvo> tfheen: http://people.ubuntu.com/~mvo/tmp/dhcp_2.0pl5-19.4ubuntu1.debdiff <- debdiff of the just uploaded dhcp
<dholbach> tfheen: do you want to attach it to the bug report and get feedback or do you just want to go with it?
<tfheen> dholbach: if you could get Kamion or infinity to review it and then upload, that'd be good.
<tfheen> dholbach: or you could attach it to the bug and wait a couple of hours.
<tfheen> I'd like it in before the weekend.
<dholbach> tfheen: it's YOUR patch :-))
<dholbach> I won't get blamed for uploading your patch ;-)
<tfheen> pft.
<dholbach> sure, I'll attach it :)
<tfheen> just sponsor the upload or something.
<tfheen> or I could upload it; point is I don't want to dig too much into single issues -- I'm trying to have something resembling a grand view of the situation.
<kylem> infinity, because it can run on anything else to generate netboot images.
<infinity> kylem: Yeah, Kamion said as much.
<infinity> kylem: You're too slow. :P
<kylem> it's like 7:30, i've not slept, cut me some slack. :)
<dholbach> tfheen: done
* dholbach -> lunch
<tfheen> dholbach: did you get anywhere with the kubuntu bluetooth problems?
<dholbach> tfheen: RockMan (kmobiletools upstream) said that using the patch and setting kbluepin as default passkey-agent works for him, another kubuntu user confirmed that - however it doesn't work for me yet - so I want to give it some more testing
<dholbach> tfheen: but I'm on it
<tfheen> dholbach: thanks; enjoy your lunch. :-)
<dholbach> gracias - hope you lunch soon too
<pitti> wb seb128 
<infinity> Kamion: Same for gtkpbbuttons, gtkpbbuttons-gnome, and powerprefs, if you didn't already nail the rdeps.
<seb128> pitti: re
<Kamion> infinity: oops, yeah, done
<pitti> ogra: aaaaaaaaah
<pitti> ogra: I got it
<ogra> what is it ?
<pitti> ogra: that is, I know the reason
<pitti> ogra: rm ~/.gstreamer-0.10/registry.x*
<ogra> where does that come from ? gst-register ?
<pitti> ogra: in short: gst reads all the plugins and caches their ranks in that XML file
<pitti> ogra: so the second time you run gst, it only reads the cache, and thus the esdsink cannot re-register itself with a different priority
<ogra> aha !
<ogra> hmm, tricky
<pitti> ogra: once you rm the cache and set LTSP_CLIENT, then the cache will be regenerated with highest rank, and esdsink is always used
<pitti> seb128: ^ this gstreamer caching behaviour breaks our alsadmixsink/ltsp sink behaviour; do you know an easy way to disable caching for a particular sink?
<seb128> no
<seb128> #gstreamer guys are responsive usually though
<seb128> just ask on the chan
<ogra> we could make gst respect LTSP_CLIENT
<pitti> ogra: the alternative would be to have an ltspesdsink which only succeeds for LTSP_CLIENT
<ogra> so it does skip the chache
<pitti> ogra: that would be even cleaner
<pitti> but a bit code-intrusive
<pitti> at this point
<ogra> likely
<pitti> seb128: will do, thanks
<seb128> np
<dholbach> tfheen: update: kubuntu patch looks good, works, needs some integration and some more testing
<dholbach> tfheen: (bluez-utils thingie) - i'll test some more after lunch
<_ion> dholbach: Please see bug #65897.
<Ubugtu> Malone bug 65897 in edgy-wallpapers "Redundant "widescreen" wallpaper in the package" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65897
<dholbach> _ion: will do it, when i get back from lunch - thanks for that!
* dholbach hugs _ion
<janimo> heno, Riddell: in comments of bug 58836 I see separate options for sticky keys and mouse keys. Is that the current state?
<Ubugtu> Malone bug 58836 in gfxboot-theme-ubuntu "F5 options need to be linked to the right casper options" [Undecided,Fix released]  http://launchpad.net/bugs/58836
<janimo> they can be separate in xubuntu as well but I'd like to keep the options close to ubuntu/kubuntu
<Riddell> janimo: yes, they're separate
<janimo> tfheen: http://paste.ubuntu-nl.org/26587/ permission to upload a one liner fix for gxine
<Kamion> FYI: app-install-data-commercial, language-pack-kde-lo, language-pack-kde-lo-base, and libiddev-dev are all newer in dapper-updates than in edgy
<Kamion> libiddev-dev may be NBS, checking
<pitti> Kamion: uh, seems that KDE dropped that language
<pitti> Kamion: I can do a no-change upload with a higher version number if required, but it would not change much
<janimo> Riddell: so you have v1/v2/m1/m2 now for kubuntu even though same bug does not mention m2 right?
<Kamion> pitti: I'd like edgy to be >= dapper-updates for all packages
<Riddell> if the % translated goes below a certain figure it doesn't get released
<Kamion> pitti: or else we could remove that package
<Riddell> janimo: yeah, one of the m's doesn't get used :(
<Kamion> (from edgy)
<pitti> Kamion: then removing is prefered
<Kamion> ok, will do
<pitti> thanks
<tfheen> janimo: you've tested this?
<janimo> tfheen: sure
<tfheen> janimo: approved, but I think this is the last of such minor fixes I'll accept.
<janimo> tfheen: I always pbuild and run tests
<Kamion> mvo: can you ensure that edgy has at least as new a version of app-install-data-commercial as dapper-updates, please?
<janimo> tfheen: thanks
<infinity> tfheen: As the acting RM, do you have any objections to the complete obliteration of edgy/hppa from the face of the planet?
<seb128> tfheen: http://people.ubuntu.com/~seb128/evolution-data-server.debdiff, the patch is http://bugzilla.gnome.org/attachment.cgi?id=71859 and used by the e-d-s FC package for a month
<heno> janimo: KDE has the kmouse tool, which is used in #4 I guess, but does nor run onBoard yet
<infinity> tfheen: Cause it's about to happen in ~22 minutes. :)
<tfheen> infinity: press da button!
<tfheen> infinity: will lamont kill us?
<janimo> heno: do you think for xubuntu I should separate mouse and sticky keys as well?
<infinity> tfheen: No.  If he threatens to, send him my way.
<infinity> tfheen: hppa will be back and should kick ass in feisty, so it's all good. :)
<tfheen> infinity: 'k
<kylem> :)
<mvo> Kamion: yes, I will fix that
<heno> janimo: so by mouse, you mean mouse keys. You could. We don't in Ubuntu just now
<Kamion> mvo: thanks
<tfheen> seb128: ok, approved.  Now, can we please stop attacking !milestone bugs?
<Kamion> libiddev-dev will be NBSed once archive-cruft-check tells me I can
<Kamion> and that'll be edgy strictly >= dapper-updates everywhere
<janimo> heno, tfheen: I'd also like to upload a new onboard with sync to latest bzr , fixes it to work in xfce (where there;s no nautilus)) bug 65251
<Ubugtu> Malone bug 65251 in onboard "work without nautilus" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65251
<seb128> tfheen: I've no milestoned bugs left on my list but ok, I'll pick some non assigned ones from now
<tfheen> seb128: there are plenty of ftbfs-es for instance.
<seb128> yeah, doing that next
<tfheen> thanks
<infinity> pitti: Which FTBFS were you looking at that looked like a linux-libc-dev bug?
<pitti> infinity: reiserfsprogs
<infinity> Right, thanks.  BenC's awake, want to poke him in #-kernel?
<pitti> infinity: bug 65842 (some details there)
<Ubugtu> Malone bug 65842 in linux-source-2.6.17 "FTBFS in edgy: no asm/unaligned.h" [High,Needs info]  http://launchpad.net/bugs/65842
<pitti> infinity: sure
<BenC> pitti: Checking it
<infinity> tfheen: queue filling up again, and I've not been watching the channel.
<infinity>   109125 | S- | gxine                | 0.5.7-1ubuntu6       | seven minutes
<infinity>          | * gxine/0.5.7-1ubuntu6 Component: main Section: graphics
<infinity>   109124 | S- | yelp                 | 2.16.1-0ubuntu3      | 22 minutes
<infinity>          | * yelp/2.16.1-0ubuntu3 Component: main Section: gnome
<infinity>   109123 | S- | adept                | 2.1.1ubuntu3         | 32 minutes
<infinity>          | * adept/2.1.1ubuntu3 Component: main Section: kde
<infinity>   109110 | S- | dhcp                 | 2.0pl5-19.4ubuntu1   | 47 minutes
<infinity>          | * dhcp/2.0pl5-19.4ubuntu1 Component: main Section: net
<infinity> tfheen: Status/approval of each?
<heno> janimo: are you putting onboard on the CD?
<tfheen> infinity: gxine is ok, yelp's ok.
<ajmitch> nothing new for universe? we must be slacking
<tfheen> who uploaded adept and dhcp?
* ajmitch also
<pitti> ogra: hmm, messing with the cache reading in gstreamer does not work unfortunately
<ogra> :(
<ajmitch> tfheen: mvo said he did earlier
<pitti> ogra: and the #gstreamer guys didn't have a good hint apart from 'original patch was flawed'
<janimo> heno: sure, and know how to start it from casper
<lritter> hey there
<ajmitch> sorry, mvo did dhcp
<infinity> tfheen: There's also the qt4-x11 upload still kicking around, and Riddell seems alive now. :)
<heno> janimo: you know or need to know
<lritter> there is a bug which i'd personally like to see fixed, as it broke 6.06 font rendering
<tfheen> infinity: dhcp is approved.
<janimo> heno: I know :)
<pitti> ogra: so, we are down to two options: (1) fix it properly with an ltspesdsink (much code, although mostly copy&paste), or (2) add a nasty hack to ltsp scripts to rm the cache at a good point
<tfheen> Riddell: did you upload adept and qt4-x11?
<lritter> it's in 6.06 since quite a time now, and i spent a lot of time getting this heard
<janimo> heno: I am just trying ot make the 30accessibility diffs small so I only send the pacth once
<heno> janimo: without at-spi I take it
<janimo> for all xubuntu buts
<tfheen> lritter: if it's the alternative font renderer patch for freetype, it's too late.
<heno> right
<ogra> pitti, hmm, the second option doesnt seem right
<lritter> tfheen: what do you mean?
<janimo> heno: I'd lik to start at-spi as well, it would mean xubutu can do all 5 options as ubuntu
<tfheen> lritter: what do you mean by what do I mean?
<pitti> ogra: well, 'right' is only the first option, but I'm not sure that tfheen is happy with it
<heno> janimo: cool!
<janimo> heno: but I do not know how to install at-spi if an a11y option is chosen but otherwise keep it and gnome deps off the installed system
<lritter> tfheen: https://launchpad.net/distros/ubuntu/+source/freetype/+bug/60760
<Ubugtu> Malone bug 60760 in freetype "turning off autohinting has no effect" [Undecided,Unconfirmed]  
<ogra> pitti, yeah, i'd guess so
<janimo> heno: stacjed filesystems was supposed to help but it is not implemented
<janimo> heno: another way would be to use whatever ubiquity does with optional langage supports but had not time to look at how it is done
<janimo> Kamion: maybe you can point me to the right code to read ^^^
<heno> janimo: oh right, we just have it installed regardless 
<ogra> pitti, i think a ltsp-sound script in /etc/X11/Xsession.d probably ... hmm
<janimo> Kamion: to get xubuntu-at- installed only if a11y is selected, or installed anyway but not copied over to the disk 
<heno> janimo: btw, if you add yourself here https://launchpad.net/people/onboard/+members I'll approve and you can sync XFCE stuff yourself :)
<tfheen> lritter: no patch and we're in RC freeze and not critical for the release in any way => too late.
<lritter> rc freeze for 6.06?
<tfheen> no, 6.10
<lritter> how is that possible
<lritter> ok, but the bug got in inbetween 6.06
<lritter> when 6.06 was already released
<lritter> so how can this not be considered?
<siretart> zul: what compiler is used for compiling ubuntu kernel images? 'standard' /usr/bin/gcc or special settings?
<janimo> heno: I joined :)
<tfheen> lritter: uh, I'm not sure what you mean by "in between 6.06"
<kristog> hello
<lritter> tfheen: the 6.06 live cd renders the font correctly
<lritter> tfheen: after installation, fonts are also correctly being rendered
<lritter> tfheen: after a package update however, fonts are incorrectly being rendered
<agutierr> hello all: someone knows why nfs doesnt mounts on boot on dapper ?
<heno> janimo: always handy to have someone with main upload right on the team :)
<tfheen> lritter: if it's something which only affects 6.06, that should be noted in the bug report.
<lritter> tfheen: so how is it possible that a release final can change essentially in behaviour,
<lritter> tfheen: but can not be fixed ;)
<mvo> tfheen: dhcp is already upload, see http://people.ubuntu.com/~mvo/tmp/dhcp_2.0pl5-19.4ubuntu1.debdiff
<tfheen> lritter: does it affect 6.10?
<tfheen> mvo: yes, I just approved it.
<lritter> tfheen: good question. is 6.10 edgy?
<tfheen> lritter: yes.
<lritter> tfheen: i can't tell... i had a look at edgy a few months ago, and it blasted my system ;)
<lritter> tfheen: i wanted to have another look at it when its sufficiently stable
<tfheen> lritter: it should be sufficiently stable now.  We're in release freeze.
<lritter> tfheen: sounds great
<mvo> tfheen: thanks. to fix #65850 we need a updated python-egenix-mx-base-dev, the debdiff is at: http://librarian.launchpad.net/4823082/egenix-mx-base_2.0.6ubuntu1-1ubuntu5.debdiff, then psycopg only needs a give-back
<tfheen> lritter: and you can always test a live cd.
<janimo> heno: Ok ping me when it needs uploading in the future :)
<lritter> tfheen: a good argument indeed.
<pitti> ogra: I added the status to the bug; tfheen, if you have a minute, can you please give your RM opinion on bug 65690?
<Ubugtu> Malone bug 65690 in gst-plugins-good0.10 "should select the esdsink for LTSP_CLIENTs" [Medium,In progress]  http://launchpad.net/bugs/65690
<lritter> tfheen: i will check and let you know.
<heno> janimo: thanks :)
<mvo> tfheen: I just did iptraf as well, debdiff is at #65832
<Kamion> janimo: can the xubuntu-at-* packages be installed on the live CD?
<Kamion> janimo: as in, just shoved into the xubuntu live seed
<tfheen> pitti: nuke the cache, imo.
<janimo> Kamion: yes they can
<tfheen> pitti: (why is it even cached?)
<pitti> tfheen: just to speed up startup, I guess
<janimo> Kamion: if it can be figured out how to purge them from the disk as with languages
<Kamion> janimo: right, then do so and make ubiquity-hooks/30accessibility call 'apt-install xubuntu-at-foo xubuntu-at-bar' (or whatever) if the packages should remain installed
<janimo> Kamion: along with their deps though
<Kamion> trivial
<Kamion> (and yes, I mean apt-install, not apt-get install)
<tfheen> infinity,Kamion: either of you please review and approve casper when it hits unapproved.
<janimo> Kamion: so the purge will  take the gnome libs away like apt-get autoremove?
<lritter> tfheen: nevertheless, congratulations
<Kamion> janimo: yes
<infinity> tfheen: Do you have a diff I can peruse, so I don't have to fetch it?
<janimo> Kamion: great
<Kamion> not autoremove though, it just removes them
<pitti> ogra: are you fine with adding this to the LTSP session scripts?
<Kamion> same code as is used for language packs
<heno> Kamion: should I update the ubiquity hooks script to match the changes I made to the casper script or would you prefer to do it?
<Kamion> heno: I'll have a look now
<heno> ok
<tfheen> infinity: http://err.no/tmp/foo.diff
<ogra> pitti, commented on the bug
<pitti> ogra: (don't forget the ~ in the path :) )
<Kamion> heno: in future feel free to do it, though
<ogra> ouch
<ogra> right :)
<tfheen> mvo: is that egenix-mx-base the debdiff against what's in Ubuntu or what's in Debian?
<tfheen> mvo: and why doesn't the changelog list the changes from the Debian package?
<heno> Kamion: ok, cool
<infinity> tfheen: Your whitespace usage sucks, otherwise it looks fine.
<lritter> is there any newer iso release than sept 28?
<Kamion> lritter: yes, the daily builds
<tfheen> infinity: I need to apply a suitable tool to emacs to teach it about indentation.
<Kamion> infinity: the whitespace use in lots of casper sucks
<lritter> are they acceptable? ;)
<Kamion> lritter: maybe
<lritter> :PP
<mvo> tfheen: this is a merge of the debian changes (the update to the new python policy) to the ubuntu package. our package does not have done the python-polciy yet and that causes the FTBFS for the dependencies of this
<lritter> ok i try one
<Kamion> there is no newer "blessed" release
<Kamion> the next one will be the release candidate
<Kamion> heno: committed
<heno> cool!
<infinity> tfheen: casper accepted.
<Kamion> diff from casper script to ubiquity hook:
<Kamion> -                        gct "-s -t string /desktop/gnome/background/primary_color \#666666"
<Kamion> -                        gct "-s -t string /desktop/gnome/background/secondary_color \#7F7F7F"
<Kamion> +                        gct -s -t string /desktop/gnome/background/primary_color \#666666
<Kamion> +                        gct -s -t string /desktop/gnome/background/secondary_color \#7F7F7F
<Kamion> those quotes should die, right?
<Kamion> I think they'll break setting of those options
<tfheen> they shouldn't be needed at least.
<heno> Kamion: I think so yes
<heno> Kamion: did you catch that last 1 line change from this morning?
<Kamion> ok, they're gone
<Kamion> heno: no
<tfheen> heno: I just uploaded a version with that change.
<heno> bug 65861
<Ubugtu> Malone bug 65861 in casper "onboard fails to start with F5 boot" [Undecided,Fix released]  http://launchpad.net/bugs/65861
<pitti> ogra: ok, bug updated. sorry :/
<heno> makes onboard work
<Kamion> yes, that's fixed in casper 1.75, but the ubiquity hook is out of sync
<heno> ok
<ogra> pitti, fine with me
<tfheen> mvo: you didn't answer why the changelog doesn't list the changes from Debian we still have?
<heno> tfheen: yeah, that's what I just saw :)
<janimo> heno: are these deps which I set a while ago still valid for current edgy? magnifying:  at-spi, gnome-orca, gnome-mag  
<janimo> heno: I see the speech packages are still in universe?
<janimo> espeak, speech-dispatcher
<heno> janimo: those are valid, yes
<heno> janimo: we are just using gnome-speech this time
<mvo> tfheen: we could sync it, but our version number is higher than the debian version number - should I update the changelog to explain this?
<tfheen> infinity: didn't you upload a new directfb?
<Kamion> janimo: you'll need to guard the apt-install call I suggested with a check for whether the xubuntu-at-* packages are installed
<infinity> tfheen: Waiting on feedback from BenC.
<Kamion> otherwise it'll install them for all derivatives
<heno> plan to use speech-dispatcher and espeak in Edgy+1
<infinity> tfheen: Which is waiting in line behind pitti. :)
<janimo> Kamion: even if the packages are not on those CDs?
<tfheen> infinity: 'k
<infinity> tfheen: (mess with agpgart headers and non-userspace typedefs)
<tfheen> mvo: but is the debdiff the still-remaining diff to Debian or the diff to our current version?
<lritter> so, what does it mean, when edgy is frozen? what will be fixed?
<Kamion> janimo: apt-install would try to install them (possibly from the network); whether it succeeds or not is a different matter
<pitti> infinity: neeeeext, please
<Kamion> janimo: we only want its queueing/preventing-removal behaviour, so check whether they're installed first
<infinity> Kamion: Can you think of a clever way to find out-of-dates accross the whole dist, without invoking britney for the task?
<tfheen> mvo: iptraf fix > approved
<Kamion> infinity: quinn-diff maybe?
<infinity> Kamion: I'm curious how many other things like pbbuttonsd stopped building when P-a-s started working.
<infinity> Yeah, quinn-diff would do.
<mvo> tfheen: oh, sorry, I misunderstood your question. its the diff between of ubuntu version 
<infinity> I may actually have a copy on drescher, come to think of it.
<mvo> tfheen: thanks
<heno> janimo: speech depends on Festival and gnome-speech ATM
<tfheen> mvo: ok, approved.
<mvo> tfheen: do you want a diff between debian<->ubuntu as well (just to be sure)?
<tfheen> mvo: that should just be the changelog if we could just as well have synced, isn't it?
<mvo> tfheen: yes it is
<tfheen> mvo: if so, no need for that debdiff.  Upload away.
<mvo> tfheen: thanks, I will make the changelog a bit more verbose and upload 
<tfheen> doko_: your eunuchs upload a month ago ftbfs on amd64.
<infinity> tfheen: Did it die with an incompatible pointer type complaint?
<tfheen> infinity: yes.
<infinity> tfheen: If so, it died on ia64 with the same thing, and I assume it's not 64-bit clean.
<tfheen> infinity: it used to build.
<doko_> tfheen: no, it didn't build
* tfheen retries the build, just for kicks
<tfheen> doko_: the build log is available now.
<pitti> tfheen: reisersprogs FTBFS fix uploaded
<tfheen> pitti: cheers
<heno> Kamion: did the ubiquity/Orca fix make it into this morning's Live CD? I don't see it working here
<doko_> tfheen: it was available before as well
<infinity> That's curious that it dies now with no code changes.  Woo.
<tfheen> doko_: not when I retried the build, no.  Then it nukes the build record.
<tfheen> Keybuk: your gmp upload some time ago ftbfs on sparc.
<Keybuk> gmp?
<Keybuk> and s/sparc/amd64/ ?
<mvo> tfheen: virkey (#65846) is fixed too, debdiff in the bugreport. do you actually want this kind of irc feedback :) ? or will you scan the uploads anyway and its just noise?
<tfheen> uh, yes, amd64.
<Keybuk> I don't think that was my upload ?
<tfheen> mvo: shouldn't that be python-all-dev in the build-deps?
<tfheen> oh, sorry, it is
<tfheen> I'm clearly blind
<mvo> too much reviewing :)
<tfheen> Keybuk: LP claims otherwise.
<Keybuk> tfheen: LP still thinks I've uploaded most of the archive at some point or other
<infinity> He synced it in his own name. :)
<Kamion> heno: should've done, check 'dpkg -l ubiquity', should be 1.2.0
<Keybuk> right
<Keybuk> I tended to do that ;)
<Keybuk> or mom output
<Keybuk> etc.
<tfheen> Keybuk: any chance you could give it a shot nevertheless?
<Keybuk> the fact it's got "unstable" in the distribution string is a bit of a give-away
<Keybuk> tfheen: it's failing in some assembly code, so, err, no
<Keybuk> :)
<Keybuk> I'll see if current Debian builds on amd64
<tfheen> thanks
<tfheen> infinity: is gtk-sharp2 a PaS bug victim or is it NBS on sparc?
<Keybuk> infinity: this looks like an autosync
<Keybuk> or probably a hammer while autosyncing
<tfheen> mvo: virtkey > approved.
<tfheen> mvo: and yes, I want those since I use my backlog when infinity or Colin asks what I've approved. :-P
<Riddell> tfheen: yes, I uploaded adept and qt4, adept fixes a High priority targetted bug, and qt4 was approved by mdz at the meeting yesterday
<infinity> tfheen: Likely the former.
<tfheen> Riddell: even so, please do make diffs and post links to them here, else I won't know if they're ok or not.
<heno> Kamion: oh, I'm an idiot: I booted with something other than v3 and then had orca and at-spi started manually. Will test properly now ;p
<tfheen> Riddell: so, if I could have an adept debdiff, that'd be good.
<infinity> tfheen: Yeah, it builds arch"all packages, so it's malcc's P-a-s bug.
<tfheen> infinity: qt4-x11 is approved.
<heno> ubiquity is indeed 1.2.0
<infinity> tfheen: Will perform more DB surgery to fix.
<tfheen> infinity: cheers.
<tfheen> crimsun: your john upload ages ago FTBFS
<tfheen> uh, that klibc ftbfs on amd64 is.. special.
<infinity> tfheen: gtk-sharp2/sparc rescued in the DB, qt4-x11 accepted.
<seb128> is anybody looking at libcairo-perl ftbfs yet?
<infinity> tfheen: klibcs is FTBFS on all arches, jbailey's handling it.
<Keybuk> tfheen: 
<tfheen> infinity: no, latest just failed on ia64 and amd64
<Keybuk>  gmp  (2:4.2.1+dfsg-3) unstable; urgency=high
<Keybuk>    * Disable fat support for amd64, as it is broken upstream.  Thanks to
<Keybuk>      Steinar H. Gunderson for initial version of patch.  Closes: #376353.
<Keybuk>  -- Steve M. Robbins <smr@debian.org>  Mon, 17 Jul 2006 23:15:30 -0400
<Keybuk> tfheen: ok to sync that from snapshot.d.n?
<tfheen> Keybuk: yes.
* Kamion sends a UVF eexception for iptables
<Keybuk> tfheen: will check it builds first ;)
<Kamion> exception request
<infinity> tfheen: No, it fails everywhere, the autorebuild says so.
<tfheen> Keybuk: please do.
<infinity> tfheen: Just cause it once built doesn't mean it does now. :)
<tfheen> infinity: pft.  Details. :-P
<tfheen> infinity: I'm still trawling outofdate.
<infinity> Yeah, I can tell. :)
<infinity> tfheen: I've handed off directfb to BenC, if you're keeping tabs on who's got what.
<BenC> tfheen, anybody: I'm uploading kernel 10.33, which is a two-liner fix for the build failure of the approved upload I did last night
<tfheen> BenC: go ahead.
<janimo> tfheen: permission to upload new snapshot of onboard from bzr, debdiff http://paste.ubuntu-nl.org/26594/
<BenC> tfheen: Upload is done, should show any minute
<Keybuk> tfheen: it builds
<tfheen> janimo: while I appreciate adding accessibility stuff to xubuntu, we're way past FF.
<janimo> tfheen: I uploaded this before FF as well but you accidentally reverted it in 0.83 ;)
<janimo> tfheen: and it does not break ubuntu/kubuntu
<tfheen> janimo: oh well, it looks decent enough.  Approved.
<janimo> tfheen: and I could only start on a11y stuff ofr xubuntu once a11y in casper is settled for ubuntu which has only happened recently
<janimo> I have a casper 30acceesibility patch in the works, I hope it will be ok to get that in before RC
<janimo> tfheen: thanks
<infinity> BenC: accepted.
<janimo> doko_ : do you know what happened in edgy vs dapper that now language support packages bring in openoffice-core and writer?
<infinity> janimo: Argh, the dummy openoffice.org-l10n-en-us package doesn't depend on "| language-support-en"
<infinity> doko_: ^^^
<seb128> bug #65845 is fixed with the new version to Debian
<Ubugtu> Malone bug 65845 in libcairo-perl "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65845
<BenC> infinity: Thanks
<seb128> we have 0.3 and Debian has 1.01
<seb128> nothings Depends on libcairo-perl
<seb128> should we just sync the new version?
<seb128> or should I rather backport the fix?
<infinity> seb128: If nothing depends on it, why is it in main?
<Kamion> build-depends IIRC
<infinity> libgtk2-perl yeah.
<seb128> I'm fine backporting the fix
<seb128> but the new version basically update for the libcairo API too
<infinity> seb128: If it's simple, please do.
<seb128> ok
<seb128> we will have binding not matching the current cairo API
<Kamion> seb128: will libgtk2-perl need to be rebuilt?
<seb128> Kamion: bug #65849, I've not looked yet, but I expect so
<Ubugtu> Malone bug 65849 in libgtk2-perl "FTBFS in edgy" [High,In progress]  http://launchpad.net/bugs/65849
<seb128> I think that's a similar issue
<heno> Kamion: OK, so if you kill the running version of Orca first and then launch install, it works perfectly. If Orca is already running as the user, then the root version falls over when you start install
<heno> I'm fairly happy with that though, I guess we can describe it in notes
<janimo> infinity: would adding that dep fix other language support packages not bringing in OOo?
<janimo> infinity: the Ooo package names and deps confuse me
<heno> These at-spi with multiple user issues really need fixing upstream anyway
<Riddell> tfheen: http://kubuntu.org/~jriddell/tmp/adept.debdiff
<Kamion> heno: ugh, I'm not sure I'm happy with that; if we're doing that then either ubiquity should be fixed to do that or I should remove the hack from ubiquity and the notes should just say to kill your own orca, run orca as root, then start ubiquity
<Kamion> half-and-half just seems confusing
<doko_> infinity: ok, will fix it
<Kamion> heno: given the lateness of this, I'm quite tempted to just back out the ubiquity change
<infinity> janimo: All the OOo langpacks need to have the alternate dep back to language-support-$foo.
<infinity> doko_: Can you give  aonce-over and make sure all the others are right?
<infinity> doko_: ISTR having some issues with this during the dapper release too. :)
<heno> Kamion: I agree. It's starting to become many layers of hacks here
<heno> Kamion: It's quite an easy workaround to describe really
<tfheen> infinity: adept approved.
<tfheen> Riddell: thanks.
<infinity> tfheen: accepgted.
<infinity> But spelled correctly.
<doko_> $ apt-cache show openoffice.org-l10n-de |grep ^Dep
<doko_> Depends: openoffice.org-l10n-common (>= 2.0.4~rc3), openoffice.org-common (>= 2.0.4~rc3) | language-support-de, openoffice.org-common (<< 2.0.5) | language-support-de
<doko_> infinity: ^^^
<doko_> looks okay
<infinity> doko_: Yeah, -en is the one that's not okay.
<infinity> doko_: Just wanted you to make sure all the others were alright too, that's all. :)
<tkamppeter> pitti, doko_, mvo, mdz, HPLIP in Ubuntu is a complete mess, especially we have lost scanning support by unsuccessfully trying to get fax on board (bug 65908). I am trying to redesign the packaging now without all the obscure Debian changes, having only the original tarball and a debian/ directory, no non-debian/ changes in the .diff.gz file.
<Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Undecided,Confirmed]  http://launchpad.net/bugs/65908
<AlinuxOS> doko_, OO.org -ka localisation works great (menu entries too)! Well done!
<doko_> AlinuxOS: thanks
<AlinuxOS> doko_, a big thank you ! ;)
<mvo> tfheen: it looks like we need a rebuild of tetex-bin to fix bug #65839
<Ubugtu> Malone bug 65839 in tetex-bin "FTBFS in edgy" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65839
<doko_> mvo: we just had a rebuild ...
<tfheen> mvo: we just had a rebuild
<mvo> tfheen: oh, cool - then doygen just needs a give-back
<AlinuxOS> is it possible to request 
<AlinuxOS> opps (wrong channel)
<tfheen> mvo: no, it's a false positive from the rebuild testing.
<AlinuxOS> mjg59, ping.
<Kamion> tfheen: liblockfile FTBFS uploaded:
<Kamion>   * glibc 2.4 added an eaccess declaration to unistd.h; rename our eaccess
<Kamion>     function to eaccess_write (closes: Malone #65837).
<Ubugtu> Malone bug 65837 in liblockfile "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/65837
<tfheen> Kamion: approved.
<mvo> tfheen: right
<heno> Kamion: so yes, just back out the change. I'll work out the smoothest way to work around it and post it on access.u.c
<Kamion> ok
<Kamion> backed out in my bzr branch
<AlinuxOS> Kamion, hello, is it possible to request a package bug fix in this period of freeze ?(or maybe in the near future?)
<Kamion> AlinuxOS: depends on the bug
<Kamion> and the fix
<Trae> https://launchpad.net/bugs/22336
<Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  
<Trae> I am on Mandriva 2007 and that bug doesn't seem to affect this distro (didn't bother Gentoo 2006 either)  
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<AlinuxOS> Kamion, where can I send a mail with bug explanation ? (it's better via mail than IRC)
<Trae> Is there something I can check here that might help fix it in Ubuntu?
<Trae> maybe if we check how they have stuff here, then it might help fix it 
<Trae> I'd hate to think this bug won't be fixed for Edgy
<Trae> as it'll mean almost a whole year of my laptop being unusable 
<Trae> (with Ubuntu)
<Trae> and I can't stand any othe distro but Ubutu
<Trae> so I'm caughtbetween a rock and a hard place
<Trae> heh
<Kamion> AlinuxOS: ubuntu-devel@lists (if main or restricted) or ubuntu-motu@lists (if universe or multiverse)
<AlinuxOS> Kamion, thanks
<BenC> yay, directfb was a one-liner fix
<Trae> I can't code or anything but will do whatever is necessary to help debug for this issue.  (follow commands a developer gives me)
<doko_> tfheen, Kamion: please approve the debdiffs at http://people.ubuntu.com/~doko/edgy/, all fixing build failures
<seb128> Kamion, tfheen, infinity: http://paste.ubuntu-nl.org/26596/ fixes the libcairo-perl ftfbs, I think we should consider syncing 1.01 from Debian though, it's update for the cairo 1.2 API changes and to Debian unstable,testing without open bug
<seb128> let me know if I should upload the patched version or if you prefer a sync
<bddebian> Howdy
<doko_> tfheen: for python-4suite, please see #65890
<seb128> hi bddebian
<bddebian> Hello seb128
<Kamion> Keybuk: hmm, how long ago did you actually do that dapper->edgy update?
<Kamion> Keybuk: I tried it just now and it didn't reproduce
<BenC> tfheen, infinity: directfb is uploaded
<Trae> no love for me today
<Trae> heh
<Kamion> Keybuk: could it have been before Thu, 12 Oct 2006 02:42:15 +0100 + build time?
<Keybuk> Kamion: yes, likely before then
<Keybuk> Tuesday probably
<tfheen> bugs 65890
<Ubugtu> Malone bug 65890 in python-4suite "UVF exception, fixing FTBFS to build with python2.5" [Medium,Confirmed]  http://launchpad.net/bugs/65890
<Trae> Keybuk: hey Scott, you see my above ramblings?
<Keybuk> Trae: no?
<Kamion> Keybuk: ok, so it won't happen on a current upgrade, but it wouldn't hurt to try to clean up the mess
<tfheen> doko_: looks good to me, upload away.
<Trae> Keybuk: I'm in Mandriva 2007 right now... and (just as Gentoo) it doesn't have the laptop overheating issue.  Is there anything we could look at how they do stuff to perhaps fix it in Ubuntu?
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<doko_> tfheen: what exactly, debdiffs plus python-4suite?
<Trae> Keybuk: having large numers of laptops not being able to function wth Ubuntu seems like a really bad thing 
<Trae> :(
<lritter> laptops not overheating is cpu power not used!
<tfheen> doko_: your debdiffs look good to me.  The UVF exception is for universe and already approved by dholbach
<seb128> doko_: I took the libperl-cairo ftbfs bug ownership since I'm working on it
<doko_> seb128: thanks
<seb128> np
<Keybuk> Trae: no idea, sorry; way above my level now
<Trae> lritter: shutting down in the middle of a compile or working  is not fun
<Trae> who's area is this?
<Keybuk> Trae: the best thing to do would be to see if a pristine upstream kernel over heats
<seb128> pitti: I'll fix the libgtk2-perl ftbfs too if you are not on it yet
<Keybuk> and if not, figure out which of our kernel patches causes the overheating
<Trae> Or is there anyonein Ubuntu that paricularly cares about this
<Trae> ?
<Keybuk> or if so, which patch in mandrive causes it to *not* overheat
<mvo> tfheen: did you approved egenix-mx-base already? I have no mail so far
<Keybuk> Trae: BenC or mjg59 ... but without you sending your laptop to them, there's not much they can do
<Trae> Keybuk: great queston.  I just make things pretty[tm] 
<Trae> :)
<Kamion> mjg59 has already been asking questions on that bug
<Keybuk> Trae: at this point, you're way beyond "oh, edit /etc/default/acpi_support and set OVERHEAT_LAPTOP to 'no'" :)
<Trae> I can give them shell access
<Trae> Keybuk: :(  
<tfheen> mvo: I guess I need to poke infinity or Kamion about the queue state.
<Trae> le suckxor
<Kamion>   109147 | S- | directfb             | 0.9.24-4ubuntu3      | three minutes
<Kamion>          | * directfb/0.9.24-4ubuntu3 Component: main Section: libs
<Kamion>   109138 | S- | onboard              | 0.85                 | 28 minutes
<Kamion>          | * onboard/0.85 Component: main Section: gnome
<Kamion>   109135 | S- | virtkey              | 0.41ubuntu1          | 48 minutes
<Kamion>          | * virtkey/0.41ubuntu1 Component: main Section: python
<Kamion>   109132 | S- | egenix-mx-base       | 2.0.6ubuntu1-1ubuntu | 53 minutes
<Kamion>          | * egenix-mx-base/2.0.6ubuntu1-1ubuntu5 Component: main Section: interpreters
<Kamion>   109127 | S- | iptraf               | 3.0.0-1ubuntu2       | 1 hour 20 minutes
<Kamion>          | * iptraf/3.0.0-1ubuntu2 Component: main Section: net
<Keybuk> Trae: ondemand didn't fix it for you then?
<Trae> Keybuk: nope
<tfheen> Kamion: directfb, onboard, virtkey, egenix-mx-base are all approved.
<Trae> it seemed to have, but then died again not long after
<Keybuk> Trae: ok, does a pristine upstream kernel overheat?
<tfheen> Kamion: iptraf too is ok.
<Trae> Keybuk: no clue, I really hate (and don't know much about) compiling kernel
<Kamion> ok
<Trae> that's so 1998
<Trae> heh
<Keybuk> Trae: unfortunately, at this point, it sounds like we have to track down a single line of kernel code that causes your laptop to overheat
<Keybuk> which means probably about 300,000 kernel compiles and tests
<doko_> seb128: do you want to have a look at gst-python? it's apparently a pygtk incompatibility
<Trae> Keybuk: ok, so now tell me the bad news
<Trae> :P
<Keybuk> Trae: you've only got a week left to live to do it all in
<Trae> hahahahaha
<Kamion> log2(300000) surely ;-)
<Trae> Keybuk: Your going down with me, I ain't going alone!
<Trae> :)
<Keybuk> Trae: nothing to do with me
<Trae> heh
<Trae> hmm
<Trae> where does BenC live?
<BenC> Trae: Virginia
<Keybuk> Hicksville, Merkia
<Trae> or the other gentleman you spoke of.
<Trae> BenC: oh there you are
<seb128> doko_: what bug number?
<Trae> hmm
<Trae> I doubt I could go very long without my laptop.
<Trae> as it's where I do all my work from.
<doko_> seb128: https://launchpad.net/distros/ubuntu/+source/gst-python/0.8.4-3build1
<BenC> tfheen: Fixed iptraf uploaded (bug 65832)
<Ubugtu> Malone bug 65832 in iptraf "FTBFS in edgy [sparc at least] " [High,Fix released]  http://launchpad.net/bugs/65832
<BenC> hmm, maybe already fixed
<tfheen> BenC: that's already fixed, yes.
<BenC> tfheen: Ok, drop my upload then :)
<infinity> Shall I reject that? :)
<infinity> BenC: Does that mean you gave up on directfb? :)
<BenC> infinity: I uploaded a fixed directfb already
<tfheen> infinity: Kamion accepted that ten minutes ago
<infinity> Oh, indeed.
<infinity> Awesome.
<infinity> BenC: Err, did you test directfb on amd64 too?  I suspect the FTBFS there may have been unique. :/
<BenC> infinity: No, just i386
<infinity> Can you test it now, for kicks?
<infinity> (I don't have an amd64 system here anymore)
<dholbach> tfheen: ok to upload a fix for bug 65897?  http://daniel.holba.ch/temp/edgy-wallpapers.debdiff ? (will save 1,3 M)
<Ubugtu> Malone bug 65897 in edgy-wallpapers "Redundant "widescreen" wallpaper in the package" [Medium,Confirmed]  http://launchpad.net/bugs/65897
<tfheen> dholbach: with the obvious fix ("not install the file")?
<dholbach> tfheen: and a change to the wallpaper.xml to say "zoom" instead of "stretched"
<pitti> seb128: thanks; no, I'm not at it
<dholbach> (and autofoo stuff to not install the file, etc)
<tfheen> dholbach: go for it
<dholbach> tfheen: done
<pitti> tfheen: I have a fixed evolution for bug 62593 now (just adds a desktop file to /etc/xdg/autostart); can I upload?
<Ubugtu> Malone bug 62593 in evolution-data-server "Does not display alarms until I start evolution" [Unknown,Unconfirmed]  http://launchpad.net/bugs/62593
<tfheen> pitti: go ahead
<pitti> done
<seb128> tfheen: opinion about libcairo-perl?
<infinity> tfheen: Do you know if we need the newer one for libgtk2-perl to be happy?
<seb128> infinity: I'm on it
<seb128> infinity: I'm still waiting for somebody to reply to my question about libcairo-perl first though
<seb128> <seb128> Kamion, tfheen, infinity: http://paste.ubuntu-nl.org/26596/ fixes the libcairo-perl ftfbs, I think we should consider syncing 1.01 from Debian though, it's update for the cairo 1.2 API changes and to Debian unstable,testing without open bug
<seb128> in case you didn't read it before :)
<infinity> seb128: Yeah, I'm more interested in knowing if libcairo-perl is perhaps somehow responsible for the libgtk2-perl FTBFS, that's all. :)
<seb128> infinity: it's likely to be, let me try to rebuild libgtk2-perl now
<infinity> seb128: I have no real opinion on the libcairo-perl UVF... It's got no rdeps, just the rbuild-dep of libgtk2-perl, so if they play nicely together, I'm not picky.
<doko_> tfheen: all the stuff from http://people.ubuntu.com/~doko/edgy/ uploaded
<pitti> tkamppeter: ugh, completely reverting all debian/ubuntu history doesn't really sound appropriate at that time? can't we just revert the fax changes to fix scanning?
<BenC> tfheen, infinity: That directfb upload is probably bogus
<BenC> I didn't realize it was a dpatch pkg
<infinity> BenC: Well, too late now.  Give me another.
<infinity> Right, I think it's bed time.
<BenC> tfheen, infinity: Fixed directfb uploaded, with correct dpatch usage, and tested on amd64
<infinity> BenC: Danke.
<infinity> BenC: Where did you hide your fix in that upload? I can't be bothered to debdiff...
<BenC> infinity: Yep, I modified an existing dpatch
<infinity> Which one?
<tfheen> seb128: I'd like us to be conservative and not grab new versions at this point
<tfheen> seb128: so if the fix in http://paste.ubuntu-nl.org/26596/ works, I'd say we go for that.
<seb128> ok
<seb128> I've no idea of how usuable is the old libcairo-perl though
<infinity> gah.
<infinity> BenC: That wasn't clean...
<tfheen> seb128: me neither.  It's in main, but no rdepends?
<seb128> tfheen: libgtk2-perl Build-Depends
<infinity> BenC: You ended up re-autotoolifying...
<seb128> no rdepends no
<infinity> BenC: Was that intentional?
<BenC> infinity: I ran a "debian/rules patch" and "debian/rules unpatch", and then did "debian/rules clean"
<BenC> infinity: So that's a failure in the debian/rules, since it does autoconf
<infinity>  90 files changed, 30811 insertions(+), 56119 deletions(-)
<tfheen> seb128: ok, then I'd rather we stay with what we have and just get the minimal build fix in.
<infinity> Might want to unpack the previous version, swap in your patch, dpkg-buildpackage -S :)
<BenC> infinity: I can do that
<infinity> Not sure I'm comfy with that diff, even if it's just autocrap. :)
<seb128> tfheen: ok, uploaded
<tfheen> seb128: thanks.
<infinity> BenC: Kay, rejecting so you can reupload the same version number.
<infinity> BenC: Wait a sec..
<infinity> BenC: Nevermind.  I was diffing against your -4ubuntu3 upload.  THAT was the one with autotools rape.
<infinity> BenC: The diff between my -4ubuntu2 and your -4ubuntu4 was fine.
<BenC> infinity: ok
<infinity> BenC: I'll yank it from the rejected queue and accept it.
<BenC> sounds good
<infinity> BenC: Thanks for the fix.
<BenC> no problem
<infinity> Queue status update before I head to bed:
<infinity>   109192 | S- | libcairo-perl        | 0.03-1ubuntu1        | six minutes
<infinity>          | * libcairo-perl/0.03-1ubuntu1 Component: main Section: perl
<infinity>   109172 | S- | evolution            | 2.8.1-0ubuntu3       | 41 minutes
<infinity>          | * evolution/2.8.1-0ubuntu3 Component: main Section: mail
<infinity>   109171 | S- | edgy-wallpapers      | 0.6-0ubuntu1         | 46 minutes
<infinity>          | * edgy-wallpapers/0.6-0ubuntu1 Component: main Section: x11
<infinity>   109170 | S- | sip4-qt3             | 4.4.5-2ubuntu1       | 50 minutes
<infinity>          | * sip4-qt3/4.4.5-2ubuntu1 Component: main Section: devel
<infinity>   109169 | S- | pyx                  | 0.9-2ubuntu1         | 50 minutes
<infinity>          | * pyx/0.9-2ubuntu1 Component: universe Section: python
<infinity>   109168 | S- | python-omniorb2      | 2.6-3.1ubuntu1       | 50 minutes
<infinity>          | * python-omniorb2/2.6-3.1ubuntu1 Component: universe Section: devel
<infinity>   109167 | S- | pysvn                | 1.4.2+dfsg-0.1ubuntu | 50 minutes
<infinity>          | * pysvn/1.4.2+dfsg-0.1ubuntu1 Component: universe Section: python
<infinity>   109166 | S- | omniorb4             | 4.0.6-2.2ubuntu1     | 51 minutes
<infinity>          | * omniorb4/4.0.6-2.2ubuntu1 Component: universe Section: devel
<infinity>   109165 | S- | ggz-grubby           | 0.0.13-2ubuntu1      | 51 minutes
<infinity>          | * ggz-grubby/0.0.13-2ubuntu1 Component: universe Section: games
<infinity>   109164 | S- | eunuchs              | 20050320.1ubuntu4    | 51 minutes
<infinity>          | * eunuchs/20050320.1ubuntu4 Component: main Section: devel
<infinity>   109163 | S- | python-4suite        | 1.0~rc4cvs20061012-0 | 51 minutes
<infinity>          | * python-4suite/1.0~rc4cvs20061012-0ubuntu1 Component: universe Section: python
<infinity>   109162 | S- | iptraf               | 3.0.0-1ubuntu2       | 51 minutes
<infinity>          | * iptraf/3.0.0-1ubuntu2 Component: main Section: net
<infinity> tfheen: Care to pronounce on those?
<dholbach> edgy-wallpapers was approved by tfheen, fixes a milestone bug and gives us back 1.3M :)
<tfheen> infinity: libcairo-perl, evolution, edgy-wallpapers, sip4-qt3, pyx, python-omniorb2, pysvn, omniorb4, ggz-grubby, eunuchs, python-4suite can all be accepted.
<tfheen> infinity: who uploaded that iptraf?  BenC?
<dholbach> I think that was mvo
<BenC> tfheen: Reject my iptraf upload
<dholbach> oh, no :)
<mvo> yeah, I uploaded it - something wrong?
<tfheen> infinity: if so, reject.  If not, enlighten me.
<BenC> someone did an iptraf upload, mine should be ignored
<tfheen> mvo: no, just a mid-air collision, most likely.
<mvo> I did that hours ago ..
<mvo> I'm sure BenC was sleeping then ,)
<seb128> infinity: wait
<seb128> infinity: no, that's fine :)
<infinity> mvo, BenC : Interesting, you both fixed it in completely different ways. :)
* mvo would like to see the fix of benc
<BenC> mvo: s,asm/types.h,sys/types.h,
<infinity> Well, mvo's wins, since it built. :)
<keescook> dholbach: I've uploaded the 10 ssl fixes now
<dholbach> keescook: super
<tkamppeter> mdz, tfheen, kamion, pitti, doko_: biff, critical bug 65908
<Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Critical,Confirmed]  http://launchpad.net/bugs/65908
<Kamion> there's also a ggz-grubby sync request outstanding
<Kamion> (IIRC)
<Kamion> should it be rejected)
<Kamion> ?
<infinity> Kamion: Since I just accepted a non-sync... One would think there's  afailure to communicate. :)
<infinity> dholbach: pipsecd, linm, dsniff, cl-ssl, clamcour, cfengine are all universe SSL rebuilds?
<infinity> keescook: ^^^
<keescook> infinity: yes.  I have debdiffs up on people.u.c/~kees if you want to see them
<dholbach> they're fine
<infinity> keescook: Are there more coming in?  You mentioned "10" up there, and that's only 6.
<heno> seb128, tfheen: there is a small problem with the new at-config not wanting to start onboard on boot without at-spi being active
<keescook> infinity: yeah, sorry, they're going slower than I expected.
<heno> bug 65937
<Ubugtu> Malone bug 65937 in control-center "start osk at login only works with at-spi on in gnome-at-properties" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65937
<heno> The bug has two patches with it, one slightly complex and one dead simple
<heno> seb128, tfheen: any chance we can target this?
<tfheen> tkamppeter: there is no diff there, and if you put up binaries like that you should provide the sources too.
<infinity> keescook: smssend and python2.2 part of the same batch?
<keescook> infinity: yes, 2 more after that: tkrat, zmailer
<infinity> keescook: Mmkay.
<infinity> We sure are doing a good job at being frozen. :P
<infinity> I don't think edgy-changes has seen this much activity since it opened.
<dholbach> hehe :-)
<lritter> tfheen: bug seems to be fixed
<tfheen> lritter: ok, good
<lritter> tfheen: however at smaller dpi rates i notice wrong spacing, but thats a different issue i can live with
<doko_> tkamppeter, pitti: before looking at your package, could you tell me why you don't fix it in the existing package?
<Kamion> I have the same question. Totally repackaging stuff at this point is deprecated.
<Kamion> and having changes in the .diff.gz outside debian/ is not at all unusual
<Kamion> changing that will make it harder to merge from Debian in future so we try to avoid doing so
<infinity> keescook: Okay, got 'em all now.
<keescook> infinity: okay, thanks.
<doko_> keescook: ugh, thanks for "noticing", that we should remove python2.2 for edgy ...
<infinity> Thank you for shopping at Archives'R'Us.
<keescook> doko_: I was wondering about that.  :)
<doko_> filing a removal request ...
<dholbach> tfheen: are you ok with  http://daniel.holba.ch/temp/bluez-utils.debdiff  and  http://daniel.holba.ch/temp/kdebluetooth.debdiff ? Riddell is happy with them, Tonio_ tested them on Kubuntu and I tested it locally
<dholbach> tfheen: this will fix bug 56651
<Ubugtu> Malone bug 56651 in bluez-utils "Impossible to do pairing in Kubuntu" [Unknown,Fix released]  http://launchpad.net/bugs/56651
<tfheen> dholbach: just a second, I have to flip a few pancakes
<dholbach> tfheen: FLIP ON!
<infinity> doko_: http://cerberus.0c3.net/~adconrad/python2.2-rdepcheck
<infinity> doko_: Is that all self-contained?
<tkamppeter> doko_, I was trying to see whether the Debian mess broke it, and whether it perhaps also broke faxing.
<infinity> doko_: Nope, looks like some of those are extra source packages.
<doko_> infinity: I'll look ...
<infinity> HAHAHAHAHAHA.
<infinity> E: Unimplemented, sucks to be you.
<infinity> Kinnison's legacy.
<Kamion> tkamppeter: also Python modules belong in /usr/lib not /usr/share
<tfheen> dholbach: upload away.
<dholbach> tfheen: ROCK
<tkamppeter> ifheen, pitti, doko_, mdz, mvo, kamion, the sources are there: http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
<infinity> doko_: Would be nice to indicate all the rdeps in the removal request.
<Kamion> tkamppeter: actually, I may be incorrect on that; I believed that .pyc and .pyo files were architecture-dependent, but some googling reveals that the dependency is more on the interpreter than on the architecture
<Kamion> tkamppeter: regardless, it's a gratuitous change that should not be made at this point in the release cycle
<infinity> And I think I'm dangerously close to joining Team Soyuz, so I can fix any number of "E: Unimplemented, sucks to be you." error messages in our tools.. :/
<doko_> Kamion, tkamppeter: found the cause for 65908, preparing an update
<mvo> Kamion: I just solved the mystery of the missing app-install-data-commercial in edgy (or rthat the outdated version number) I uploaded a new version some weeks ago but made a embrassing typo in the distribution field. got no mail from lp about the failure and never noticed the error. I upload a empty a-i-d-c package now because we don't have any edgy-commercial apps yet
<dholbach> ogra blogs again
<ogra> heh
<ogra> i knew someone would notice it :)
<highvoltage> heh
<Kamion> mvo: heh, ok
<highvoltage> ogra: as long as you don't get threatening emails about it ;)
<seb128> ogra: dholbach is watching everything everywhere all the time, you know it ;)
<ogra> heh, after that weeken i can handle any mail flood :)
<ogra> seb128, he must have 100 eyes :)
<seb128> yeah, something like that
<highvoltage> ooh, that's an interesting blog post
<tfheen> ogra: it's spelt "interested", not intrested, though. :-P
<ogra> thanks ... fixing ...
<doko_> tfheen, Kamion: please approve  http://people.ubuntu.com/~doko/edgy/hplip.debdiff
<doko_> tkamppeter: ^^^
<tkamppeter> tfheen, kamion, doko_, in addition, /usr/lib/libhpip.so.0 and /usr/lib/libhpip.so.0.0.1 are missing. They also need to be added to debian/hplip.install
<tfheen> tkamppeter: there is no need to try to talk to half the development team at once.  Please develop a solution, give references to what targetted bugs it fixes and present it when it's there.
<tkamppeter> tfheen, sorry, please approve http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/hplip.debdiff
<tfheen> tkamppeter: you have tested this properly and it fixes all the 6.10-targetted bugs for hplip?
<tkamppeter> The additional libs are required for libsane-hpaio to work.
<doko_> infinity, Kamion: bug 65946
<Ubugtu> Malone bug 65946 in Ubuntu "python2.2 removal requests" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65946
<Kamion> doko_: ok
<tkamppeter> Yes, I have tried at first to only add libsane-hpaio and it did not work, then I added libhpip and it worked.
<tkamppeter> Device is a USB-connected HP PhotoSmart 2600
<Kamion> doko_: please reply to my question on bug 64353
<Ubugtu> Malone bug 64353 in python2.3 "python2.3 removal requests" [Undecided,In progress]  http://launchpad.net/bugs/64353
<tfheen> tkamppeter: ok, approved.
<nixternal> hmm..ever since i switched from the 386 kernel to the generic one, i get [17179742.292000]  APIC error on CPU0: 01(01)
<nixternal> causes my computer to lockup now
<tkamppeter> doko_, can you upload the corrected HPLIP package? Thanks.
<doko_> Kamion: done
<doko_> tkamppeter: I don't have libhpip libraries ... how did you configure your build?
<tkamppeter> doko_, then Debian has messed them away and there mess does not scan, too. I have done the following:\
<tkamppeter> I have taken the upstream tarball and uncompressed it.
<tkamppeter> Then I have copied the debian/ tree into it
<doko_> tkamppeter: from the changelog:
<doko_>       * Build libhpip as a convenience library (and don't package it)
<doko_> Kamion: your "ok" was for the hplip upload?
<tkamppeter> I have at first replaced "lib/hplip" in the Debian tree by "share/hplip" to point to the upstream location, and not to the place where Debian has moved all the stuff to.
<tkamppeter> Then I have built, and according to error messages adjusted paths in the debian/rules and the debian/*.install files.
<doko_> tkamppeter:  ./libtool --tag=CC --mode=link gcc  -Wall -pipe -g -O2   -o libsane-hpaio.la -rpath /usr/lib/sane -version-info 1:0:0 -module hpaio.lo mfpdtf.lo 
<doko_> pml.lo scl.lo io.lo libhpip.la libhplip-api.la -lnetsnmp -lusb -lpthread 
<doko_> gcc -shared  .libs/hpaio.o .libs/mfpdtf.o .libs/pml.o .libs/scl.o .libs/io.o -Wl,--whole-archive ./.libs/libhpip.a ./.libs/libhplip-api.a -Wl,--no-whole-ar
<doko_> chive  -lcrypto /usr/lib/libnetsnmp.so /usr/lib/libusb.so -lpthread  -Wl,-soname -Wl,libsane-hpaio.so.1 -o .libs/libsane-hpaio.so.1.0.0
<doko_> so everything looks fine
<tkamppeter> Then I saw the bug 65908 in my e-mail and I tested scanning. It did not work.
<Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Critical,Confirmed]  http://launchpad.net/bugs/65908
<tkamppeter> I added the missing libsane-hpaio to hplip.install. It still did not work.
<tkamppeter> So I ran "sudo apt-get install sane-utils; SANE_DEBUG_DLL=255 scanimage -L" and so in the screen output that also libhpip*.so.* was missing.
<tkamppeter> I added these libs to hplip.install, rebuilt, installed and scanning simply worked.
<tkamppeter> Resulting source package:
<Kamion> doko_: no, acknowledging the python2.2 removal request
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
<Kamion> tkamppeter: see my mail on that subject
<fabbione> infinity: did you file a bug on autogen already?
<Kamion> repackaging isn't acceptable at this point
<tkamppeter> And this package is now in the shape that I could simply replace the source by the preview 1.6.10 upstream tarball which I got from HP, but this did not make fax working anyway (not uploaded).
<doko_> Kamion: anyway, please see the one line fix at http://people.ubuntu.com/~doko/edgy/hplip.debdiff
<Kamion> tkamppeter: if you're unhappy with the Debian packaging, please do talk to the Debian maintainer, but this is the wrong time to be experimenting with packaging changes in Edgy, I'm afraid
<Kamion> doko_: I'm fine with that much, but I'd prefer that you and tkamppeter reach agreement first
<tkamppeter> kamion, sorry, I simply tried out whether I got fax working, and during the experiments I have fixed scanning.
<Kamion> tkamppeter: the problem with repackaging is that we don't know what else you've thrown away in the process of fixing this bug
<doko_> tkamppeter: what devices are used for faxing, I see we do have a fax group, hplip is not a member.
<Kamion> tkamppeter: and, as I said in my mail, large-scale moving around of Python modules isn't good at this point either
<tkamppeter> So I think, as all 1.6.7, 1.6.9, and 1.6.10 do not fax in Ubuntu, we should at least get scanning working with any of them.
<doko_> tkamppeter: do you agree with my proposed fix?
<tkamppeter> So the very first step is to see whether Debian ships libhpip and whether Debians packages scan.
<Kamion> <cjwatson@riva ~>$ dpkg -c /mirror/debian/pool/main/h/hplip/hplip_1.6.7-2_i386.deb | grep hpip
<Kamion> <cjwatson@riva ~>$
<doko_> tkamppeter: do you read what I write? libhpip is linked as a convenience library?
<tkamppeter> doko_, I can only agree with it if it really works. So upload the fixed package into a web space and I try it out.
<tkamppeter> doko_, I am reading what you are writing, but perhaps I am not fast enough in answering.
<tkamppeter> What does mean "linked as a convenience library"?
<doko_> rsyncing to http://people.ubuntu.com/~doko/hplip ...
<doko_> a "static" library with object files compiled with -fPIC, linked into the target library
<tkamppeter> doko_, so the libsane-hpaio has libhpip statically linked?
<doko_> tkamppeter: yes
<doko_> the one from the hplip package
<tkamppeter> Then it should work, I will test.
<doko_> tkamppeter: rsync finished
<Kamion> tfheen: ok for me to do a universe-only sync pass?
<tkamppeter> doko_, thank you. Downloaded the package tested, and scanning works. Package can be uploaded.
<doko_> tkamppeter, Kamion: uploaded
<tkamppeter> doko_, thanks, marked bug 65908 as "Fix committed".
<Ubugtu> Malone bug 65908 in hplip "libsane-hpaio.so not shipped anymore" [Critical,Fix committed]  http://launchpad.net/bugs/65908
<Kamion> tfheen: I'll just do it, I reckon it's safe :-)
<keescook> ajmitch: re 65831 (john ftbfs), is CLK_TCK -> CLOCKS_PER_SEC correct?  I thought the right fix was to call sysconf(_SC_CLK_TCK) ?
<Kamion> doko_: could you give me a reason for removing gnat (bug 65875) for the record, so that we know why we removed it later?
<Ubugtu> Malone bug 65875 in gcc-defaults "FTBFS in edgy" [High,Needs info]  http://launchpad.net/bugs/65875
<fabbione> keescook: probably it is.. 
<fabbione> keescook: mind to give it a shot?..
<doko_> Kamion: gnat-4.1 is the current package, the binary gnat is built from gcc-defaults, the old gnat is based on gcc-2.8
<keescook> fabbione: no problem.  (did this yesterday for dsniff)
<fabbione> keescook: perfect
<keescook> fabbione: hm, actually, either seems to be right.
<Kamion> doko_: thanks
<fabbione> keescook: up to you.. i was waiting a comment on that testsuite thingy from ajmitch. but if you can test/upload i am ok
<keescook> oh!  no, actually, it's not.  sysconf is the right way.
<tfheen> Kamion: oh, feel free.
<keescook> CLK_TCK == 100, CLOCKS_PER_SEC == 1000000
<keescook> :)
<keescook> probably why the test suite fails
<tfheen> Kamion: universe is something I try hard to keep off my radar. :-)
<doko_> tfheen, Kamion: please approve http://people.ubuntu.com/~doko/edgy/python-setuptools.debdiff
<tfheen> doko_: looks good to me; approved.
<mdz> tkamppeter: scanning was working fine for me with 1.6.7
<mdz> tkamppeter: so this is a regression in 1.6.9
<mdz> doko_: was it a packaging problem or an upstream problem?
<doko_> mdz: packaging, imported from debian, but didn't notice
<keescook> dholbach, fabbione: I've got a successfully built fix for 65831 (john FTBFS).  okay to upload?
<tfheen> bug 65831
<Ubugtu> Malone bug 65831 in john "FTBFS in edgy" [High,In progress]  http://launchpad.net/bugs/65831
<tfheen> keescook: debdiff, please?
<dholbach> keescook: john is in main - that's not my domain
<keescook> tfheen: one sec
<dholbach> tfheen: uploaded the fix for bug 65645
<Ubugtu> Malone bug 65645 in bluez-gnome "Die systray icon die!" [Undecided,Fix released]  http://launchpad.net/bugs/65645
<tfheen> dholbach: yay
<keescook> tfheen: http://librarian.launchpad.net/4825077/john_1.6-40ubuntu2.dsc.debdiff
<dholbach> we're up to 41 RC bugs
<dholbach> 44
<fabbione> keescook: sorry but i can't authorize uploads.. 
<tfheen> keescook: looks good, upload away.
<keescook> tfheen: thank, uploaded.
<seb128> dholbach: up? it was 57, I would call that down
<dholbach> it was 41 at the meeting yesterday ,no? ;)
* seb128 slaps dholbach
<tfheen> dholbach: we've had a bunch of rebuild errors since then
<heno> seb128: can you help applying the patch for bug 65937? (I ask since it's your package)
<Ubugtu> Malone bug 65937 in control-center "start osk at login only works with at-spi on in gnome-at-properties" [Medium,Confirmed]  http://launchpad.net/bugs/65937
<mdz> BenC: what caused the kernel build failure?
<dholbach> tfheen: yeah, I know - that's whyI added the 'smiley' :)
<seb128> tfheen: would you be happy with something like http://paste.ubuntu-nl.org/26618/ ?
<BenC> mdz: I quieted some printk's, but forgot it is KERN_WARNING, not KERN_WARN
<BenC> mdz: one-liner fix in two files, and things are building now
<heno> seb128: and sorry for the ~ cruft in the patch :-/ 
<mdz> BenC: you said you did a test build, though; was that change added later?
<seb128> tfheen: that's probably fixing the Xvfb crashers happening atm (breaking some builds because xvfb-run crash)
<Treenaks> 4
<mdz> it was in the diff you sent me
<Kamion> seb128: I'm going to have to reject a number of dapper-{proposed,updates} uploads from you; could you re-run those through the procedure in http://wiki.ubuntu.com/StableReleaseUpdates?
<seb128> tfheen: I say "probably" because the package is still building, but I've tried with the "-extension Composite" and it does fix it
<BenC> mdz: I only test built the things that changed (e1000, v4l1, etc). I didn't do a full build, and didn't check the one-liner printk edits
<mdz> BenC: oh, I misunderstood then
<Kamion> seb128: (I realise they're from before the policy was in place, but I can't help that now)
<tfheen> seb128: hmm, ok.  Can you give me an example of a build which failed?
<seb128> Kamion: will I get some notification about which ones are rejected?
<Kamion> seb128: yes, you'll get mail
<BenC> mdz: I did do a full build of this and booted, so it should be good to go now
<Kamion> seb128: do you need the source packages put somewhere for you, or do you still have them?
<seb128> tfheen: libgtk2-perl
<seb128> Kamion: I probably have them, not sure though ... if you could give me the list of packages first I will tell you
<tfheen> seb128: and it works for you with that?  If so, go ahead.
<seb128> tfheen: yes, ok, thank you
<Kamion> seb128: from dapper-proposed, gtk+2.0 2.8.20-0ubuntu2, evolution 2.6.3-0ubuntu1, evolution-data-server 1.6.3-0ubuntu1, evolution-exchange 2.6.3-0ubuntu1
<Kamion> I haven't gone through dapper-updates yet
<Kamion> seb128: but in any case we can retrieve stuff from the rejected queue essentially forever, so you just need to ask
<seb128> Kamion: I have them
<seb128> you can clean them
<Kamion> ok
<seb128> evo stack was pending on a reply with extra informations to mdz because they are non trivial updates anyway
<seb128> I'll do a second round on them after edgy ;)
<lritter> i'm inbetween upgrading dapper to edgy
<lritter> seems i can't install python-minimal
<keescook> tfheen: ack, I need someone to sponsor my john upload (since it's in main).  what's the best way to do this?
<doko_> tfheen, Kamion: please approve bug 65963, fixing a FTBFS of python-biopython
<Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
<tfheen> seb128: any chance you could sponsor keescook's john upload?  My brain's utterly fried now.
<lritter> http://rafb.net/paste/results/XZbiUG96.html <- anyone knows what to do?
<seb128> tfheen: ok, where is it?
<tfheen> keescook: ^^
<seb128> keescook: bug number?
<Kamion> mvo: the apt changelog in edgy shows this change:
<Kamion> apt (0.6.43.3ubuntu3) dapper; urgency=low
<Kamion>   * methods/http.cc:
<Kamion>     - fix the user-agent string
<Kamion>  -- Michael Vogt <michael.vogt@ubuntu.com>  Fri, 26 May 2006 18:09:32 +0200
<tfheen> seb128: thanks a lot.
<keescook> seb128: where do you want it?  (bug is 65831)
<Kamion> mvo: apparently that was never uploaded (or never accepted), and now there's a 0.6.43.3ubuntu3 in dapper-proposed. Does that proposed upload include the change above, or what?
<lritter> help!
<lritter> :>
<tfheen> doko_: python-biopython is universe, and the other is a warning.  I don't see a big point.
<tfheen> lritter: this channel is not for support, not even with edgy.
<tfheen> lritter: there are some bugs filed about similar problems to yours, please contribute to those instead.
<lritter> oh
<lritter> i was thinking this was a common problem
<doko_> tfheen: http://bugs.debian.org/379763 got my attention
<fabbione> guys i am going offline
<lritter> and only required one line of answer
<lritter> but obviously its not ;)
<fabbione> the buildd is still going on sparc.. i will pass later today or tomorrow to check logs
<fabbione> and file other bugs
<lritter> tfheen: anyway, parts of the packages have been upgraded and i can confirm again that the font problems are gone ;)
<seb128> keescook: looking on the bug, you have the package somewhere to download?
<keescook> seb128: what's best for you?  rookery?
<seb128> keescook: rookery is good yep
<tfheen> doko_: hmm, point.  -Wall -Werror might cause build failures
<tfheen> doko_: do you have a debdiff?
<keescook> seb128: http://people.ubuntu.com/~kees/ftbfs-fixes/
<siretart> oh. I think there is an archive problem. http://archive.ubuntu.com/ubuntu/dists/dapper/Release references a file main/binary-amd64/Packages, which doesn't exist. I'm not sure if this is the cause that debmirror fails to sync my local mirror
<mvo_> Kamion: I uploaded it to dapper-proposed, the edgy changelog entry is wrong for some reason [re-send because my connection just dropped] 
<Kamion> mvo_: well, see my mail anyway
<mdz> Riddell: what's happening with bug 65675, bug 65963, bug 63325, bug 64978?
<Ubugtu> Malone bug 65675 in kdebase "system menu fails to load on start" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65675
<Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
<Ubugtu> Malone bug 63325 in kde-systemsettings "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Undecided,Confirmed]  http://launchpad.net/bugs/63325
<Ubugtu> Malone bug 64978 in kde-guidance "powermanager icon sometimes shows fully charged when not" [Undecided,Fix committed]  http://launchpad.net/bugs/64978
<tfheen> doko_: I'm leaving for the weekend now, so if you could poke mdz about the flex bug instead, that'd be good.
<infinity> siretart: That's perfectly normal.  We don't ship the uncompressed files on the mirrors, but you'll find that when you uncompress the .gz/.bz2 files, they have the same hash as the one listed in Releases.
<infinity> siretart: And apt insists that the uncompressed file be listed, because it checks that has after decompressing locally.
<Riddell> mdz: 65675 I'll confirm if it's fixed this evening
<Kamion> mvo_: I think it should be fine eventually, but I am obliged to go through the process
<Riddell> mdz: 65963 isn't mine
<mdz> fabbione: are you fixing sparc-utils
<Riddell> mdz: 64978 is now fixed, I'll change that
<siretart> infinity: hm. then the debmirror breakage has another cause. interstingly, this seems to happen with dapper only. hrmpf
<doko_> tfheen: just a minute, reducing the debdiff ...
* infinity goes to bed for real this time.
<Riddell> mdz: and 63325 I need to look in to
<mvo_> ok
<mdz> Riddell: 65665 I meant
<mdz> the 4 kde bugs on the 6.10 list
<Riddell> mdz: 65665 I have a likely fix for that I'll test tonight too
<mdz> sfllaw: did you receive my mail about the validation process for next week?
<seb128> keescook: looks good to me, uploaded ;)
<keescook> seb128: great, thanks
<seb128> np
<doko_> tfheen: http://people.ubuntu.com/~doko/edgy/ (removed the generated files from .shortdiff)
<seb128> heno: I'll have a look at the bug you pointed next, sorry for the lag
<heno> seb128: np :) thanks
<heno> seb128: the last patch on the bug should be simple and clean
<Kamion> tfheen: mdz approved a UVF exception for iptables, so I'll accept that once it lands
<seb128> heno: right; looks good to me
<heno> \o/
* heno hugs seb128
* seb128 hugs heno back
<rick_> has anyone seen this bug as of yet?: https://launchpad.net/distros/ubuntu/+bug/65787
<Ubugtu> Malone bug 65787 in Ubuntu "Major Problem with DHCP setting MTU Correctly." [Undecided,Unconfirmed]  
<keescook> 65948> "-lz" is coming from libxml2's .la file.  Looking at libxml2's debian/control file, libxml2-dev doesn't have ${shlibs:Depends}.  isn't that wrong?
<keescook> should libxml2 maybe include zlib1g-dev explicitly as a Depends?
<mdz> keescook: does edgy-security exist yet?
<keescook> mdz: unsure.  pitti was talking about it, but I don't have jackass access yet.
* heno away
<janimo> heno: I have just played with sticky/mouse keys for the first time and it's really nice. The whole idea I mean :)
<janimo> mdz: I'd like to ask for an UVF in advance for Sunday or early next week for xfdesktop. There are some major bugs being fixed upstream
<janimo> crashers and memleaks
<mdz> keescook: libxml2-dev should depend on zlib1g-dev in that case
<mdz> janimo: your call, but I recommend being cautious about what you choose to accept this late in the game
<mdz> janimo: if it causes a problem which requires work on the part of the archive admins to process packages and builds, they may not have time to do it while busy with the RC
<Trewas> rick_: maybe that's related to bug 61989
<Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [Undecided,Confirmed]  http://launchpad.net/bugs/61989
<janimo> mdz:thanks.  work on part of admins besides approval?
<wasabi> Hmm. Is there a text mode installer CD, somewhere, that has EVMS on it?
<wasabi> (and lets me mount /target on my own)
<mdz> janimo: CD builds, livefs builds, etc.
<wasabi> The fight I'm having with this system sucks. =(
<janimo> mdz: ok
<keescook> mdz: zlib1g-dev explicitly deps on libc (which libxml2-dev should as well).  Is it more correct to use explicit deps, or use $shlibs?
<mdz> keescook: shlibs is only for runtime libraries
<mdz> sfllaw: hello?
* mvo_ goes for dinner
<AlinuxOS> mdz, I saw you responded to my mail on ubuntu-devel, unique thing that I know is that this http://packages.debian.org/unstable/x11/ttf-bpg-georgian-fonts Debgian package works for me without problems (I don't know if it's ok for Ubuntu too). If not so I should wait for mjg59's fix, because I'm just simple Gnome translator.
<doko_> Kamion, tfheen: Please approve a no-change upload to build libopentoken (with gnat-4.1, built last time in June with gnat-3.15)
<wasabi> There any way to launch the text mode installer from the livecd?
<wasabi> hmm guess not.
<dholbach> have a nice weekend
<mdz> night dholbach
<Mez> wasabi: the alternative CD should I believe - but try #ubuntu
<dholbach> mdz: have a *VERY* nice day :-)
<elmo> could a MOTU please fix https://wiki.ubuntu.com/MOTU/Packages/Merging ? it talks about pinging me for syncs, which is like a bazillion years out of date
<elmo> (I don't know what the correct sync procedure is these days - and while I could probably find out, it seems easier to ask someone who knows offhand to fix it)
<elmo> similarly, https://wiki.ubuntu.com/Uploads talks about me checking new packages and warty, it looks like it could use some love
<Mez> ::wikiwub::
<mdz> elmo: it already links to the correct instructions;  I just removed mention of you
<Mez> mdz: security uploads for warty should go to warty-security. build logs are not published because some security uploads are embargoed (not to be released until a certain agreed date). New builds have to be confirmed by the security team (pitti). You must read and follow SecurityUpdateProcedures 
<elmo> mdz: thanks
<sfllaw> mdz: Yup.
<mdz> Mez: wherever that is, it deserves the same treatment (delete everything but the link to SecurityUpdateProcedures, which will be kept up to date)
<Mez> its in /Uploads ;)
<Mez> mdz: fixed anyways
<Mez> whats the default mail agent for ubuntu - exim ?
<sfllaw> mdz: Hello.
<elmo> Mez: there isn't a default installed, but postfix is preferred as a choice if none is specified/already installed
<Mez> elmo: oh... /me wonders why he thought exim was the default
<Mez> cheers elmo - btw - hows things - been a long time ;)
<elmo> probably because it's the default in Debian
<elmo> mez: fine thanks
<Mez> elmo: ah that makes sense.
<mdz> sfllaw: hi
<sfllaw> mdz: Hi.
<mdz> sfllaw: so about the validation process...
<sfllaw> This was the mail entitled Re: DevelTeamMeeting - 20061012, right?
<keescook> Kamion, tfheen: I need permission (and a main sponsor) for http://people.ubuntu.com/~kees/ftbfs-fixes/libxml2_2.6.26.dfsg-2ubuntu4.dsc.debdiff (prereq fix for 65948)
<tfheen> keescook: your changelog there is wrong ; you don't add libc-dev (and you shouldn't either)
<mdz> sfllaw: no
<mdz> sfllaw: ->/query
<keescook> tfheen: ah! thanks for that.  I realized it while changing the Deps...
<tfheen> keescook: it's merely the changelog which is wrong, though.  Your change looks correct.
<fabbione> mdz: no, i assigned it to Ben.
<mdz> fabbione: yes, I see that now
<fabbione> mdz: ok perfect
<fabbione> i am off for the evening.
<fabbione> mdz: i will be back in 12 or so and look around.. buildd is still going
<fabbione> i am sure there will be more to fix
<Mez> who's the lead for ubuntu-serveR? 
<keescook> tfheen: okay, corrected libxml2 changelog and re-uped to rookery.
<mdz> tfheen,Kamion,mvo: did you receive my email about the release validation process?  it seems Simon didn't
<tfheen> mdz: I got it, yes.  I pointed sfllaw to the wiki page earlier today.
<doko_> Kamion, tfheen, mdz: please approve http://people.ubuntu.com/~doko/edgy/bouncycastle.debdiff, fixing FTBFS for binary-arch only builds
<mdz> tfheen: thanks
<mdz> doko_: yep
<tfheen> doko_: it looks sane; you've tested it, I presume?  If so, approved.
<tfheen> doko_: could you sponsor keescook's libxml2 upload, please?
<doko_> tfheen: I shortened the debdiff again, removing the archive files, attached to bug 65963
<Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
<doko_> tfheen: yes, tested; will do
<sfllaw> mdz: That's where I heard it from.
<sfllaw> mdz: Your e-mail still hasn't arrived after the bounce.
<sfllaw> Am testing on my side to see if I get e-mails.
<mdz> tfheen: for FTBFS fixes, I don't think there's a need for review before uploading; it can be done as part of the archive admin process.  do you agree?
<mdz> sfllaw: just sent you a test email
<sfllaw> mdz: I'm not getting @ubuntu.com mail anymore.
<sfllaw> mdz: Could you bounce the mail to sfllaw@law.yi.org and I'll follow up with rt@?
<mdz> sfllaw: bounced
<sfllaw> Got it.
<sfllaw> mdz: tfheen and I talked about it this morning.
<sfllaw> I'm actually working on StableReleaseUpdates and ReleaseValidationProcess right now.
<doko_> keescook: libxml2 uploaded
<keescook> doko_: thank you!  :)
<sfllaw> This evening, I should have some announcement e-mails to send out.  ubuntu-devel-announce, ubuntu-devel, ubuntu-laptop, and ubuntu-bugsquad seem like prime candidates for this.
<elmo> sfllaw: your MX is unreachable from the UK
<sfllaw> elmo: ?!?
<sfllaw> elmo: I can connect to fiordland.ubuntu.com.
<elmo> sfllaw: I can't get past piero.pppoe.ca when trying to get to law.yi.org, from multiple providers in the UK
<sfllaw> elmo: My MX is 206.248.157.16.  Is DNS out of date?
<elmo> sfllaw: looks like, I'm seeing 206.248.152.22
<Kamion> doko_: libopentoken> really? libopentoken3.0b Depends: libgnat-4.1 here (powerpc)
<sfllaw> elmo: I guess I need a shorter TTL.  Thanks.
<doko_> Kamion: sorry, my mistake. fooled by the clear and easy structure of https://launchpad.net/people/doko/+packages ;-p
<Kamion> haha
<tfheen> mdz: the workflow so far has been that infinity or Kamion has listed the unapproved items in the queue and I've told them what to do about each (or gone off investigating if there has been unknown uploads).  While ftbfs reviews take a little bit of time, it hasn't been problematic in any way and means all packages go through the same process.
<siretart> is bug #61711 a duplicate of #56587, and should they be targeted for 6.10?
<Ubugtu> Malone bug 61711 in usplash "no boot splash and very slow booting" [Undecided,Confirmed]  http://launchpad.net/bugs/61711
<tfheen> mdz: so I'd rather just have the cursory review we're currently doing than risking having stuff stuck in unapproved since nobody knows about it.
<mdz> tfheen: I can't think of any scenario where we would decide not to fix an ftbfs, so they wouldn't be stuck in unapproved ever (only superseded by a new upload if necessary)
<tfheen> mdz: they'll be mixed with uploads which do need review and I'll have to spend time finding out what the upload is about rather than doing lastlog $package if I can't remember having approved it.
<tfheen> s,lastlog,/lastlog
<Kamion> tfheen: speaking of unapproved:
<Kamion>   109326 | S- | djplay               | 0.3.0-0ubuntu2       | 1 hour 50 minutes
<Kamion>          | * djplay/0.3.0-0ubuntu2 Component: universe Section: sound
<Kamion>   109288 | S- | bluez-gnome          | 0.5-2ubuntu2         | 2 hours 40 minutes
<Kamion>          | * bluez-gnome/0.5-2ubuntu2 Component: main Section: gnome
<Kamion>   109225 | S- | bluez-utils          | 3.7-1ubuntu3         | four hours
<Kamion>          | * bluez-utils/3.7-1ubuntu3 Component: main Section: admin
<Kamion>   109224 | S- | kdebluetooth         | 0.99+1.0beta1-12ubun | four hours
<Kamion>          | * kdebluetooth/0.99+1.0beta1-12ubuntu8 Component: main Section: kde
<tfheen> Kamion: bluez-* and kdebluetooth are approved, djplay is universe => dholbach and friends.
<Kamion> all the bluetooth ones are dholbach; djplay is adri2000
<tfheen> I assume the djplay one is fine, but I don't do universe so I have no idea.
<tfheen> maybe ajmitch knows?
<siretart> dholbach approved it on #ubuntu-motu
<Kamion> ok, I had a quick look but the int->long patch wasn't obvious to me
<Kamion> ok, according to the #ubuntu-motu log it comes from upstream; thanks for the pointer
<Kamion> tfheen: control-center change in unapproved:
<Kamion> +  * debian/patches/34_at_properties_onboard_and_new_interface.patch:
<Kamion> +    - make the osk option active only when at-spi is active,
<Kamion> +      patch update by Chris Jones (Ubuntu: #65937)
<Kamion> I think that's meant to be s/osk/sok/ possibly
<Kamion> ... or maybe not
<tfheen> on-screen keyboard, I guess.
<Kamion> yeah, just worked that out
<tfheen> it looks sane enough to me.
<tfheen> approved.
<heno> osk = on-screen keyboard, yes
<heno> AT jargon ;)
<shining> I always fail to find the git web view of the ubuntu kernel tree
<shining> I only find this: http://www.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/
<keescook> Kamion, tfheen: with dholbach gone for the weekend, who should I run universe uploads past?  I have a fix for 65616, uncovered during openssl rebuilds.
<tfheen> keescook: I think we made ajmitch volunteer for it, at least.  Maybe siretart too wants to, if he's still around.
<siretart> keescook: hm. this looks rather like a hack than a proper fix to the problem
<keescook> siretart: I wasn't sure that the issue was.
<keescook> it attempts to check for pgsql, so I thought that'd be the best way
<keescook> (the docs say to use that variable, anyway)
<lritter> hm
<lritter> why is there a difference in the live cd bootscreen and the dist-upgrade bootscreen?
<lritter> the dist-upgrade bootscreen shows a test image
<lritter> the live cd bootscreen shows a large ubuntu logo
<mdz> lritter: sounds a bit like bug 61313, perhaps you could investigate a little and see what the cause is
<Ubugtu> Malone bug 61313 in usplash "Usplash artwork missing on upgrades" [Medium,Fix released]  http://launchpad.net/bugs/61313
<lritter> mdz: allright
<lritter> mdz: it seems it requires me to install usplash-theme-ubuntu
<mdz> lritter: in which case the issue is that you removed ubuntu-desktop at some point in the past.  I recommend reinstalling it
<lritter> mdz: let me see
<lritter> mdz: sacre bleu
<lritter> mdz: i wonder how this happened :D
<mdz> lritter: if you use the automated upgrade process, it fixes this up for you
<lritter> mdz, which one?
<lritter> mdz, apt-get kind of refuses to do this.
<lritter> mdz, but i'll handle this
<lritter> with great delight i notice more tango icons :D
<Twoods196> can anyone tell me how to install Blowfish, Crypt, And others into Ubuntu?
<lritter> i assume you need cryptlib 
<lritter> or in this case, libcrypt
<Twoods196> yeh, im trying to install vhcs
<Twoods196> i tried thhe sudo apt-get libcrypt
<mdz> lritter: Update Manager
<Twoods196> bruce@ubuntu:/root/vhcs_tmp/install/vhcs2.4$ sudo /var/www/vhcs2/engine/setup/vhcs2-setup
<Twoods196> Password:
<Twoods196> CRITICAL ERROR: Module [MIME::Entity]  WAS NOT FOUND !
<Twoods196> CRITICAL ERROR: Module [MIME::Parser]  WAS NOT FOUND !
<Twoods196> CRITICAL ERROR: Module [Crypt::CBC]  WAS NOT FOUND !
<Twoods196> CRITICAL ERROR: Module [Crypt::Blowfish]  WAS NOT FOUND !
<Twoods196> CRITICAL ERROR: Module [Term::ReadPassword]  WAS NOT FOUND !
<Twoods196> Modules [MIME::Entity, MIME::Parser, Crypt::CBC, Crypt::Blowfish, Term::ReadPassword]  WAS NOT FOUND in your system...
<Twoods196> thats what im getting
<tfheen> Twoods196: this is hardly on-topic for this channel.
<tfheen> Twoods196: perl modules are usually named lib$perlname-perl, so libmime-entity-perl, libmime-parser-perl, etc.
<Twoods196> ahh..asked in wrong room guess i neeed ot ask in ubuntu
<Twoods196> sorry
<tfheen> Twoods196: yeah, #ubuntu is more appropriate.  Thanks. :-)
<ajmitch> morning
<lritter> can somebody take care of this
<lritter> https://launchpad.net/distros/ubuntu/+source/scite/+bug/61033
<Ubugtu> Malone bug 61033 in scite "Tabs don't function properly under edgy" [Undecided,Unconfirmed]  
<lritter> there's obviously a fix
<ajmitch> lritter: would you be able to fill out the info needed for a UVF exception please? (https://wiki.ubuntu.com/MOTU/Processes/UVF)
<lritter> what is this?
<lritter> anyway
<lritter> yeah
<lritter> :)
<ajmitch> too easy for the bug to get lost, especially as noone set it as confirmed :)
<lritter> ajmitch: how can i assign this?
<ajmitch> click on scite (Ubuntu) in the middle of the page
<ajmitch> it expands to change the bug details
<lritter> ok
<keescook> tfheen, Kamion: now that libxml2 is published, can you give permission for my autogen upload to close 65948?
<keescook> http://people.ubuntu.com/~kees/ftbfs-fixes/
<Riddell> Kamion: kubuntu ubiquity won't let me pass the map page without going back then forward again
<ajmitch> keescook: sorry, I saw that CLK_TCK 'fix' in another changelog
<keescook> ajmitch: no problem.  do you remember which (it should be changed too)
<ajmitch> just looking
<tfheen> keescook: looks good to me; can you get ajmitch or Riddell or somebody to sponsor you?
<keescook> tfheen: I will, thanks.
<ajmitch> keescook: netkit-bsae
<ajmitch> -base
<keescook> ajmitch: can you sponsor my autogen fix upload into main?  (see URL above)
<ajmitch> sure
<keescook> thanks!
<seb128> tfheen: I've uploaded a libgpod with that patch: http://paste.ubuntu-nl.org/26678/
<seb128> tfheen: new ipod firmware makes that pszSerialNumber is not defined for some people and rhythmbox crashes on start, the patch fixes the crasher
<tfheen> seb128: gnr, ok.  Approved.
<seb128> thank you
<keescook> ajmitch: cool, I'll re-fix netkit-base
<ajmitch> keescook: it certainly explains why the test suite ran so long before I killed it :)
<keescook> ajmitch: hehe, yeah!  :)
<keescook> tfheen: permission for another upload, please: http://people.ubuntu.com/~kees/ftbfs-fixes/netkit-base_0.10-10.3ubuntu4.dsc.debdiff
<ajmitch> keescook: autogen uploaded
<keescook> ajmitch: cool, thank you.
<tfheen> keescook: yay, good.
<tfheen> (approved)
<keescook> tfheen: thanks.  :)   ajmitch: can I lean on you again for the netkit-base upload from the same place?  :)
<ajmitch> no problem :)
<tfheen> keescook: I'm going to bed RSN since it's almost midnight here.  For FTBFS fixes, just uploading or running them past mdz (or just typing them out to me and uploading) should be fine.
<keescook> tfheen: okay, thanks.
<ajmitch> keescook: netkit-base uploaded
* keescook hugs ajmitch
<dave_> What package has this file: X11/glcanvas.h
#ubuntu-devel 2006-10-14
<Riddell> Kamion: https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/66022
<Ubugtu> Malone bug 66022 in ubiquity "Can't pass map page in Kubuntu Ubiquity" [Undecided,Unconfirmed]  
<Kamion> Riddell: "won't let" as in the forward button isn't displayed?
<Kamion> oh, enabled, hmm
<Kamion> ok, probably due to the back/forward handling changes I made; I'll investigate
<Kamion> need to do another ubiquity upload before RC anyway to back out the orca stuff
<Kamion> Riddell: ah, the problem is that it doesn't think a timezone is selected until slightly after the decision whether to enable the forward button is made
<Riddell> Kamion: how fixable is that?
<Kamion> Riddell: well, it works in GTK, shouldn't be too hard to fix
<Kamion> Riddell: I'm happy to take care of it
<Kamion> in the meantime, the workaround is either to go back/forward as you did, or just to click on a city on the map
<Riddell> I did click on a city
<Kamion> er. worked for me.
<Kamion> which city?
<Kamion> oh, hey, I see what you mean
<Kamion> it's probably related ...
<Kamion>         elif city == "Edinburgh":
<Kamion>             self.city = "London"
<Kamion> sigh :)
<Kamion> oh, right, got at least part of it
<Kamion> missing conversion to allow_go_forward
<Kamion> well, that was easy
<Kamion> keescook: re bug 65616, exit code 10 is often debconf's "bad parameters" exit code
<Ubugtu> Malone bug 65616 in torrentflux "Upgrade fails" [Undecided,In progress]  http://launchpad.net/bugs/65616
<keescook> Kamion: good to know; I haven't had time to dig much further with it yet.
<Kamion> which can include "the question you tried to operate on doesn't exist"
<jdong> evening
<Kamion> also, this should be done to debian/torrentflux.prerm, although it's not the cause of the bug:
<keescook> Kamion: what's the best way to get all the debugging output from these kinds of situations?
<Kamion> -            db_input torrentflux/restart-webserver high || true
<Kamion> +            db_input high torrentflux/restart-webserver || true
<Kamion> keescook: DEBCONF_DEBUG=developer in the environment turns on debconf debugging, and will tell you exactly what the problem is if the exit code 10 is coming from debconf
<keescook> okay, thanks.
<Kamion> mdz,tfheen: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.2.1.diff - OK to upload?
<mdz> Kamion: absoloodle
<Kamion> ta
<Kamion> oh, damnit, I meant to fix bug 62479 before release - I guess it's not technically RC but it's an easy and fairly innocent-looking way to get ubiquity to crash
<Ubugtu> Malone bug 62479 in ubiquity "canonicalise grub device names" [Medium,Confirmed]  http://launchpad.net/bugs/62479
<pirast> any xubuntu dev around?
<FireRabbit> hey, im trying to set up an apt mirror, do i need an account to rsync from the servers listed on https://wiki.ubuntu.com/Archive ?
<FireRabbit> oh nevermind, i see .. the documentation on the website is horribly wrong
<Burgwork> FireRabbit: which website?
<FireRabbit> i found this https://help.ubuntu.com/community/Debmirror
<FireRabbit> i guess this page is supposed to be the official documentation, but it doesnt explain how to do anything other than mirror EVERYTHING http://www.ubuntu.com/download/mirror
<FireRabbit> (it doesnt mention debmirror at all)
<Burgwork> FireRabbit: both of those pages are wikis
<Burgwork> please fix them
<FireRabbit> huh? /download/mirror isnt a wiki
<Burgwork> for that, file a bug against ubuntu-website
<FireRabbit> ok
<FireRabbit> ill rewrite the Debmirror page as soon as i get it set up here
<gnomefreak> dholbach  << is that his nick?
<azeem> somebody is impersonating him right now
<gnomefreak> working on banning him if i find out he is
<doko> mdz, Kamion, infinity: please approve openoffice.org 2.0.4-0ubuntu1, survives oosmoketest on i386
<doko> infinity: please build on palmer
<BHSPitLappy> can anyone tell me, has keybuk just not been on in a few days, or do I just not coincide with the right hours of the day?
<ajmitch> BHSPitLappy: wrong time of day
<BHSPitLappy> oh...
<BHSPitLappy> so I might catch him tomorrow morning then?
<BHSPitLappy> since the school week has ended
* ajmitch shrugs
<ajmitch> perhaps
<BHSPitLappy> well thanks
<wasabi> Kernel panic - not syncing: no cpio magic.   I ask here because I'm hacking my boot loader. =)
<wasabi> What's expected out of Ubuntu's initrds?
<Riddell> tfheen, mdz: kubuntu-default-settings uploaded to fix some issues and do the artwork Ken said, http://kubuntu.org/~jriddell/tmp/k-d-s.debdiff
<Riddell> tfheen, mdz: also kdelibs to fix printing issues, just a revertion to the 3.5.4 code
* Riddell beds
<samuel> you guys to a wicked job...
<infinity> doko: No -l10n upload to go with it?
<infinity> keescook: netkit-base fix approved.
<infinity> doko: openoffice was pre-approved at the meeting, afaict, so accepting and building it.
<infinity> keescook: autogen fix approved at well.
* keescook hugs infinity
<infinity> Hug yourself instead, you're doing great work.
<infinity> Nice catch on pitti's ping.c breakage, BTW.
<Hobbsee> infinity: but hugging oneself tends to looks weird.
<infinity> Hobbsee: Still feels oddly comforting sometimes, though.
<Hobbsee> true that
<keescook> infinity: thanks.  :)
<ajmitch> infinity: not only that, he caught the same issue in the john debdiff
* ajmitch didn't spot the mistake
<keescook> ajmitch: well, you mentioned you'd seen the fix before; else I would never have seen pitti's.  :)
<infinity> keescook: You're booked for UDS-MV, right?
<keescook> infinity: I'll be there, but the booking folks are running behind with me for some reason.  clan is on it.  :)
<infinity> keescook: I think I already owe you a drink or two, which may be a new record for a new employee.
<keescook> woohoo! :)
<keescook> I think I owe pitti drinks forever.  :)
<infinity> given that my very first exposure to you was reverting one of your uploads, things are looking up. ;)
<ajmitch> heh
<ajmitch> that's a good improvement
<wasabi> Hmm. Where's the best place to get teh debian/ dir for building a debian kernel image?
<keescook> infinity: *sob* yeah.  that was bad build environment #1.  #2 was on python breakage.  #3 is looking up (sbuild+schroot+lvm snapshots)
<infinity> keescook: Fancy.  I just use a chroot cleaning script.  LVM snapshotting sounds saner, but was never high on my TODO. :)
<keescook> it's really sweet.  Writing up a wiki for it is on my list.
<ajmitch> keescook: I'd like to see that - currently I just use pbuilder
<keescook> ajmitch: cool, I'll write it up tomorrow.
* ajmitch should get back to filing bugs
<infinity> My directory naming scheme leaves something to be desired...
<infinity> adconrad@lucifer:~/fuck/ktorrent-2.0.3$ 
<infinity> I don't think I was in the best of moods last night. :)
<keescook> heh
<infinity>   109474 | S- | agave                | 0.4.0-0ubuntu3       | 33 minutes
<infinity>          | * agave/0.4.0-0ubuntu3 Component: universe Section: gnome
<infinity> ajmitch: Was that uploaded with your approval?
<infinity> Hobbsee: Or, rather, would you like to tell ajmitch why I should accept it? :)
* ajmitch pokes Hobbsee 
<ajmitch> I'm thinking we should get people to attach debdiffs in malone for things they upload 
<ajmitch> given that everyone is just fixing bugs now
<infinity> Up to your.  Your workflow, your process. :)
<infinity> I'm just driving the big red button.
<ajmitch> approve agave, if you will - Hobbsee did put the changelog in there :)
<infinity> Accepted.
<keescook> is there a way to make sure an otherwise not-autoloaded module loads at boot-time?  (Normally I'd just echo module >> /etc/modules ...)
<infinity> That would do it, yes.
<infinity> If you need it in the initrd, you cant it in /etc/initramfs-tools/modules, if you can wait until after / is mounted, /etc/modules
<keescook> so no magic debian tool to do it Right?
<keescook> yeah, totally afterwards.
<infinity> s/cant it/can put it/
<infinity> No idea what my fingers were thinking there...
<keescook> I think it's a bug that lvm tools don't attempt to load the snapshot module when you ask it to do snapshot work.
<infinity> Yeah, I'd call that a bug in the tools.
<infinity> Manual module loading in /etc/*/modules should really be a last resort.
<keescook> yup, that's why I was wondering.  :)
<infinity> There used to be a Debian tool back in the boot-floppies days (so, woody?) that listed all the modules based on descriptions from modinfo, would let you try to insert them, etc, and would append to /etc/modules as appropriate.
<keescook> heh
<infinity> I can't seem to find it on my system now, so I assume we did away with it when we decided that hardware detection actually worked well enough to not require it.
<keescook> yeah, normally udev and friends handle it all, but not for the LVM tools (dm_mirror for pvmove, and dm_snapshot for lvcreate)
<infinity> Yeah, it's my opinion that any userspace utility that needs a kernel module should really be trying to load it on the fly.
<keescook> and the error message is really not helpful.  :)
<Hobbsee> infinity: ajmitch:  was a 1 line fix.  and ajmitch will accept it, else havoc will come to him when he next visits sydney :P
<ajmitch> threats won't help. much
<Hobbsee> ajmitch: much.
<ajmitch> but thanks for putting the changelog on the bug :)
<Hobbsee> hehe
<ajmitch> just don't close it so quick next time, it makes it harder to find
<Hobbsee> ajmitch: what, instead of my "fixed, thanks" way?
<ajmitch> fix committed, not fix released
<Hobbsee> ajmitch: just subscribe to the entire bugtracker, like you do for the wiki.  no more problem
<Hobbsee> then i tend to forget about ever marking it as released
<ajmitch> ubuntu-bugs mailing list, great thing
<Hobbsee> yeah, well
<Hobbsee> so you shouldnt have a trouble finding the bug.
<ajmitch> sigh
<ajmitch> you just want to make things hard for me, I know it
<Hobbsee> indeed.
<Hobbsee> ajmitch: you mean you didnt know that before?
<ajmitch> oh I knew
<Hobbsee> you just underestimated, it seems.
<ajmitch> obviously
<ajmitch> we shall have to discuss this later
<Hobbsee> hah.  later when?
* ajmitch shrugs
<fabbione> morning
<ajmitch> hi fabbione 
<ajmitch> you're up early :)
<fabbione> as usual
<Hobbsee> hey fabbione!
<fabbione> yoyo
<Hobbsee> ajmitch: lets be fair here.  if i wanted to make life hard for you, i'd make sure the search was disabled for you in mutt.
<ajmitch> Hobbsee: it takes a little while to search on 140K bug mails
<Hobbsee> ajmitch: then you need a quicker search algorithm.  or maybe to just delete some of the mail
<fabbione> infinity: ping?
<Hobbsee> BenC: it seems like the latest update has broken some people's X.  you want syslogs, xorg.0.logs, from them?
<BenC> Hobbsee: If it broken i965, then I blame Intel
<tfheen> k-d-s looks good to me, approved if nobody else has approved it yet.
<BHSPitMonkey> why do I always hear this kind of stuff WHILE synaptic is updating
<tfheen> Kamion: ubiquity looks good, approved (if mdz hasn't already)
<Hobbsee> BenC: at least 1 is a nvidia card.
<tfheen> hiya Sarah
<Hobbsee> hey tfheen :)
<BenC> Hobbsee: Can you point me to some info? Nothing I just uploaded should break X in any way
<BHSPitMonkey> Hobbsee, are you looking for users of that specific card, or users of the broad i9xx category
<Hobbsee> BenC: i've been trying to grab the people who *arent* running beryl.  There are two on irc so far.
<Hobbsee> the beryl-running people are screaming the loudest though.  in #ubuntu+1
<BHSPitMonkey> that's because they're the most concerned with visuals
<BenC> i965 is probably broken, but then again i965 drm/dri never worked before the latest kernel
<Hobbsee> BenC: chuckyp is one user, if you wanted to query him.  i cant debug X terribly well - only what i learned when mine broke
<BenC> and the problem is userspace i965_dri.so in mesa, not the kernel driver
<Hobbsee> apparently the update was due to a kernel
<Hobbsee> ahh right
<tritium> Hobbsee: Toshiba acpi?
<Hobbsee> tritium: that was mine, yes.
<tritium> Hobbsee: me too.  All better now :)
* Hobbsee got her computer running about 10 degrees C hotter than usual, from that :P
<ajmitch> Hobbsee: and you were so ready to blame GNOME, too
<Hobbsee> ajmitch: that was later.  much later.
<BenC> if i965 is causeing problems, I suggest "sudo rm -f /usr/lib/dri/i965_dri.so"
<Hobbsee> hmmm.  seems that the problem isnt fixed in .31, so it's not a kernel problem
<Hobbsee> sorry for the noise
<BenC> Hobbsee: See my last comment wrt to i965
<Hobbsee> BenC: yep, saw it, thanks
<fabbione> hey BenC !
<BenC> hey fabio
<fabbione> BenC: do you think you can look at sparc-utils FTBFS?
<BenC> fabbione: in the morning, just heading to bed
<fabbione> otherwise i can look at it later, but the error is a bit obscure to me
<fabbione> sure that would do fine
<fabbione> thanks man!
<BenC> np
<keescook> infinity, ajmitch: I've got a prototype for my sbuild/schroot/lvm script up:
<keescook> http://people.ubuntu.com/~kees/scripts/mk-sbuild-lv.sh
<ajmitch> yay, thanks
<keescook> no problemo.  I'm off to bed.  *wave*
<ajmitch> now I should modify it to work with xen :)
<keescook> heh
<ajmitch> though I think that sbuild should be getting xen support soon
<keescook> probably need to patch schroot for that.
<keescook> nice
<ajmitch> yep
<ajmitch> I should find out where that's at
* imbrandon looks up
<imbrandon> eh
<keescook> I haven't tried it lately, but pre-3.0 hand nasty whole-system hangs when using LVM snapshots.  Hopefully that's fixed by now.
<keescook> oh, and as noted in the script's comments, see my patch to schroot to handle stray processes in the chroot when shutting down:
<keescook> at the end of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391319
<Ubugtu> Debian bug 391319 in schroot "schroot: leftover processes cause umount to fail" [Normal,Open]  
* keescook really going to bed now
<ajmitch> night keescook 
<ogra> Seveas, Bug 65693 is no bug in usplash, our progressbar image is broken
<Ubugtu> Malone bug 65693 in edubuntu-artwork "progressbar is distorted " [Medium,Rejected]  http://launchpad.net/bugs/65693
<ogra> but i'll happily try a fixed usplash as well indeed
<fabbione> ajmitch: 4000 pkgs to go in universe/multiverse
<fabbione> ajmitch: main/restricted are almost done
<Tonio_> tfheen: ping ?
<infinity>   109473 | S- | kubuntu-default-sett | 1:6.10-58            | 7 hours 20 minutes
<infinity>          | * kubuntu-default-settings/1:6.10-58 Component: main Section: kde
<infinity>   109420 | S- | xorg-server          | 1:1.1.1-0ubuntu12    | 14 hours
<infinity>          | * xorg-server/1:1.1.1-0ubuntu12 Component: main Section: x11
<infinity> tfheen: Were either of those approved at any point?
<fabbione> infinity: who uploaded xorg-server?
<Hobbsee> infinity: i think the k-d-s ones were.  if that's the change to adept, and font.
<infinity> Changed-By: Sebastien Bacher <seb128@canonical.com>
<infinity>  xorg-server (1:1.1.1-0ubuntu12) edgy; urgency=low
<infinity>  .
<infinity>    * debian/patches/17_no_composite_for_xvfb.patch:
<infinity>      - fix a crasher by not using composite for Xvfb when using -render
<infinity>    * debian/patches/18_no_composite_for_xvfb_run.patch:
<infinity>      - use "-extension Composite" to fix xvfb-run crashing
<infinity> Hobbsee: I tried to find mention of it in backscroll and could only find Riddell asking for approval, but no one approving it..
<Hobbsee> infinity: ahhh...was that it
<fabbione> infinity: right.. that was an important bug to fix.. if you want i can review the debdiff
<infinity> 20:16 < Riddell> tfheen, mdz: kubuntu-default-settings uploaded to fix some issues and do the 
<infinity>                  artwork Ken said, http://kubuntu.org/~jriddell/tmp/k-d-s.debdiff
<infinity> 20:16 < Riddell> tfheen, mdz: also kdelibs to fix printing issues, just a revertion to the 3.5.4 
<infinity>                  code
<infinity> 20:16  * Riddell beds
<infinity> Yeah, no response after that.
* infinity leaves k-d-s there, and goes to grab a debdiff for xorg-server
<infinity> fabbione: http://cerberus.0c3.net/~adconrad/xorg.diff
<mdke_> if I have a script that is doing a grep, how can I avoid it pasting the output and simply tell me if there is output or not? (is that a clear question?)
<infinity> mdke_: grep -q
<infinity> mdke_: RTFM, please. :)
<mdke_> sorry. I thought it would be something clever with another command
<infinity> if grep -q pattern file; then echo "It found stuff!"; fi
<infinity> For instance.
<mdke_> infinity: so is this going to work? http://paste.ubuntu-nl.org/26720/
<mdke_> (adding the -q)
<fabbione> infinity: there is something fishy in that upload
<fabbione> infinity: like a patch patching debian/local/
<mdke_> infinity: seems to work, thanks
<fabbione> infinity: we will need to talk to seb.. the 017 seems sane, but the 018 is wrong
<fabbione> infinity: it shouldn't be in a patch in the first place and i am not sure why he is forcing Composite 
<giftnudel> he is not
<giftnudel> fabbione: - is unforcing, + is forcing
<giftnudel> so +extension enables, -extension disables
<fabbione> giftnudel: yes unforcing..
<fabbione> the patch is still wrong there...
<giftnudel> ok, just wanted to make that clear
<infinity> Uhm, yeah, patching debian/local looks pretty suspect. :)
<fabbione> there is also another thing i am not sure it will work properly
<fabbione> Xvfb extends the cmdline parsing for it's own options
<fabbione> like -render
<fabbione> but there is no guarantee that it will be executed after +extension Composite
<fabbione> so -render might disable composite, while a +extension will reenable it
<fabbione> it's kind of fishy IMO
<giftnudel> that's probably why he forces -extension
<fabbione> giftnudel: you can call Xvfb in several ways.. not necessarely via xvfb-run
<giftnudel> oh, so that won't work
<fabbione> the latter is only a convenient wrapper
<infinity> I dunno, that may just be an "enough rope" scenario.
<fabbione> infinity: i think he is fixing the buildd case
<fabbione> that's the most common one to be executed via xvfb-run
<infinity> If you intentionally call Xvfb directly with incompatible args, I'm inclined to let you keep both pieces.
<fabbione> infinity: i tend to agree.
<fabbione> i am worried about wrappers around wrappers here
<fabbione> anyway let's talk with seb again
<fabbione> i wouldn't approve it personally..
<infinity> I'm fine with not touching it -- it is my weekend, afterall. :)
<fabbione> yeah well i am we mode too.. just babysitting the buildd
<fabbione> root@sunfire:/home# for i in buildd*/build/build-progress; do cat $i |grep -v "^ "; done  | wc -l
<fabbione> 24
<fabbione> it's all good :)
<infinity> doko: idlc is hanging on sparc during the OpenOffice.org build. :/
<kristog> HELLO
<highvoltage> EHLO kristog 
<Tonio_> any release manager available ?
<infinity> Tonio_: Not *the* RM (tfheen is playing that role this time around), but a member of the release team, yes.
<infinity> Tonio_: What do you need?
<Tonio_> infinity: dholbach released a couple of patches for kdebluetooth yesterday
<Tonio_> infinity: they work fine except the autostart desktop file, which requires & end of the Exec command, otherwise kde is blocked and cannot shutdown
<Tonio_> infinity: I have a debdiff and I was searching for someone to approve the upload
<infinity> Tonio_: Show me the diff.
<Tonio_> infinity: sure
<Tonio_> infinity: http://paste.tonio.homelinux.org/27
<doko> infinity, fabbione: that's bug 59537, apparently a kernel or glibc problem. that's a smp kernel on the buildd? should work fine with a non SMP one.
<Ubugtu> Malone bug 59537 in Ubuntu "[sparc]  OOo build hangs in futex call" [High,Unconfirmed]  http://launchpad.net/bugs/59537
<infinity> adconrad@artigas:~$ uname -a
<infinity> Linux artigas 2.6.15-26-sparc64 #1 Mon Jul 17 19:54:18 UTC 2006 sparc64 GNU/Linux
<infinity> doko: An strace is going nowhere, fwiw.
<Tonio_> infinity: that debdiff will close milestone bug 56651
<Ubugtu> Malone bug 56651 in bluez-utils "Impossible to do pairing in Kubuntu" [Unknown,Fix released]  http://launchpad.net/bugs/56651
<infinity> Tonio_: That looks fine to me.
<Tonio_> infinity: okay, can I upload then ?
<infinity> Please do.
<Tonio_> infinity: done, thanks ;)
<doko> infinity: yes, and restarting, the build will continue, and randomly hang in a following idlc run
<infinity> doko: It's hung in the same idlc run twice in a row this time.
<infinity> doko: And it's a UP kernel, so if it's the same bug, you're theory's shot.
<doko> infinity: well, you could retry, setting AVAIL_CPUS to 1 in debian/rules.
<infinity> 29115 ?        R    180:15 idlc @/tmp/mklNOCAb
* infinity grumps.
<ajmitch> infinity: zodb uploaded, if you could approve please. drops a python2.3 dependency
<infinity> ajmitch: Done.
<infinity> doko: OOo is building on the other sparc buildd this time, if it hangs and fails again, we'll have to look at it later.  I'm out for the night.
<doko> infinity: have fun!
<tfheen> infinity: both kde-default-settings and xorg-server were approved, yes
<wiggy> anyone here familiar with what russkaya.ubuntu.com is doing with svn servers?
<tfheen> wiggy: probably importing the repos to bzr.
<wiggy> I it would be much appreciated if you contact a project before putting that load on a svn server
<wiggy> 1gb of traffic in a day is insane if the normal load is 30mb
<tfheen> that's excessive, agreed.
* wiggy firewalled the box off for now until someone officially contacts me about it
<tfheen> I'll send a mail to the people who are responsible for it and they'll get in touch.
<tfheen> sorry about it. :-/
<tfheen> at least, I'll send a mail once my mail server is back up.
<wiggy> heh
<wiggy> thanks
* wiggy back to work
<Riddell> tfheen: did kdelibs get approved?
<tfheen> Riddell: I haven't seen any kdelibs upload?
<Riddell> and I don't have an accepted e-mail either.  strange, the .upload file suggests it got uploaded
<Kaleo> Hello guys
<Viper550> Excuse me, but I have a pretty good Usplash bug to share
<Viper550> https://launchpad.net/distros/ubuntu/+source/usplash-theme-ubuntu/+bug/66107
<Ubugtu> Malone bug 66107 in usplash-theme-ubuntu "Placeholder Theme is a Regression (and is ugly)!" [Undecided,Unconfirmed]  
<Kamion> tfheen: kdelibs is in unapproved
<tfheen> Kamion: I haven't seen the debdiff, but Riddell  seems to want it and it'll only affect kubuntu, so approved.
<Riddell> the debdiff is large and not really readable
<Riddell> but it's just a revertion to known good code
<tfheen> 'k; your choice.
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/kdelibs.diff
<Kamion> Riddell: there seems to be a lot of stuff outside the kdeprint directory in there; was that intentional?
<Riddell> hmm
<Riddell> Kamion: they're all fine, it's just caused by me not running a clean rule at the correct time, but I'll upload a cleaner version to do it properly
<bddebian> Howdy
<Seveas> ogra: all progressbars are broken because usplash_put_part is broken
<bluefoxicy> what's the ETA for Edgy
<bluefoxicy> I still have imake as obsolete and removing it removes xorg
<Amaranth> bluefoxicy: I remember that one
<Amaranth> bluefoxicy: Another package provides imake but it doesn't seem to pick it up
<Amaranth> bluefoxicy: Install xutils-dev
<lordpatman> hi
<licio> how can I view usplash in verbose mode?
<siretart> does anyone here know hendrik's aka hno73 email address? does he irc?
<AlinuxOS> mjg59, ping
<_lemsx1_> siretart: did you try looking for that information in Malone?
<_lemsx1_> siretart: or better said, launchpad.net
<siretart> lemsx1|gone: I did, but I didn't find him
<Kamion> siretart: he's /people/henrik
<siretart> Kamion: oh, thanks. do you know if he is still an (active) canonical admin?
<Kamion> siretart: er, depends what you mean by "admin" (he's never been on the sysadmin team), but he's still employed by Canonical yes
<Kamion> I think Matthew Nuzum does most of the webmastering now, but I'm sure Henrik can point you to the right person
<siretart> he was the one who arranged the machine for revu
<siretart> I need to contact him because of that
<Seveas> siretart, his current nick is heno and afaik he can be found in #ubuntu-accessibility
<siretart> Seveas: thanks. I thought heno was someone else than hno73
<exarkun> Is there any dapper configuration where the powernow-k8 kernel module is loadable?  I can't seem to find it, if so.  It says "powernow_k8: disagrees about version of symbol cpu_data" and "Unknown symbol cpu_data" when I try to load it.
<exarkun> Uh, or maybe I forgot to reboot after the last kernel upgrade.
* exarkun tries that
<exarkun> Oh well, that's a different failure mode anyway...
<rawler> https://wiki.ubuntu.com/XlessLoginSpec <- my first spec.. please tell me what you think, both of the structure of the spec, and of the proposal as such.. :)
<mjg59> rawler: We don't use framebuffers by default now
<mjg59> And when we did, they were 640x400 in 16 colours
<rawler> hmm, allright.. there goes that idea, then.. ,)
<rawler> what does the bootsplash use then?
<mjg59> vesa
<wasabi_> Wonder how long until X desktop migration becomes something people will want.
<tfheen> wasabi_: X desktop migration as in "connect to running X session"?
<rawler> wasabi_: how do you mean?
<wasabi_> Gtk had the beginnings of it, a long time ago.
<wasabi_> THe ability for one app, or all of them, to disconnect from X, and reconnect to another X.
<wasabi_> Reprobe screen layout, readjust self, etc.
<wasabi_> Reupload images, etc.
<AlinuxOS> mjg59, ping (may I disturb you?)
<tfheen> wasabi_: doable, but ugly.
<wasabi_> I don't really think it's ugly. ANything that connects to something should be able to cleanly disconenct and reconnect again. :)
<wasabi_> Makes stuff like VNC nice too. You'd have a system VNC server, that when you logged in, GDM popped up on.
<wasabi_> GDM would then migrate your existing desktop to the VNC, and put it's login screen back on the old X server.
<wasabi_> Not saying it isn't massively hard though. Stuff very deep in Gdk. ;)
* maswan waves a bit at tfheen from NUCCC
<tfheen> hiya maswan!
<tfheen> maswan: how's the crowd?
<wasabi_> I have seen it work, a long time ago, with a little sample program.
<rawler> I kindof agree.. however I would prefer a proxied solution in that case, something like what Y-windows were considering..
<tfheen> wasabi_: sure, I've written software to make it work.  That doesn't mean it's pretty.
<maswan> tfheen: It's neat, I just sat opposite a bunch of PVVers at the dinner
<wasabi_> Proxies, like X move, do suck.
<wasabi_> First off, one more layer for everyting to talk to.
<tfheen> maswan: did quarryman (Jens dne) get my sms?
<rawler> wasabi_:  you know, our competitor from bug #1 can do JUST that.. ;) (remote login and takeover session)
<Ubugtu> Malone bug 1 in ubuntu-meta "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
<maswan> tfheen: yup, their singing was somewhat uncoordinated though
<wasabi_> rawler: Yup.
<tfheen> maswan: heh. :-)  The message was about 8 sms-es long..
<wasabi_> They do it quite a bit differnet though.
<rawler> they usually do.. :)
<wasabi_> They have a single central place where all apps talk to, and THAT redirects to different display devices.
<wasabi_> Anyway. I'd be neat. Stick an X property someplace that instructs all the apps to move. Wait until they're gone, GDM covers screen with login screen.
<rawler> (often to some 5 or ten years later "upgrade" to a solution more like what Unices have been doing for decades) ;)
<maswan> tfheen: :)
<shawarma> Does anyone know why user-mode-linux is not in edgy?
<maswan> tfheen: torben is getting all the chicks, as usual (for a chicken) ;)
<maswan> tfheen: anyway, 'night, I only popped in before sleep and thought I should say hi since you were referenced at dinner
<tfheen> maswan: good to hear that you brought him.  I'm not enough in with the crowd that I felt like going this year.. getting old.
* maswan nods
<tfheen> maswan: oh, please say hi to everybody I know there tomorrow.
<maswan> tfheen: will do
<tfheen> and 'night to you too
<rawler> wasabi_: as far as I recall, that's kindof what Y-windows had in mind for connecting and disconnecting.. the notion of a "session" built into the display server, that could then transition to new displays, and the only thing applications would notice was a resolution change
<rawler> wasabi_: don't really know how this would fit into "special" apps like xv-equivalents and gl-apps, though..
<jdong> is there any chance of anything getting a freeze exception?
<wasabi_> I suspect it's not the biggest thing in the world to make Gtk do. I mean, massively difficult, sure. And GL would probably suck.
<wasabi_> Gtk certainly has full knowledge of what widgets it has, and what X structures they are mapped into.
<rawler> I guess.. :) only problem is few people are using GTK-only desktops.. :)
<wasabi_> Yeah. It'd obviously involve X. Standards to disconenct and reconnect, GDM would have to do "something" if a program didn't leave.
<rawler> yeppers.. neat idea, though.. next part is to be able to bring your programs on a USB-drive, connect them to a terminal, work for a while, then disconnect and go somewhere else.. :)
<wasabi_> That's a bit far fetched.
<tfheen> rawler: trivial; just use xen vms.
<wasabi_> And cool but unneccassary. :)
<rawler> I've seen there ARE a few working complete computer on USB2 nowadays.. just plug them in and they run.. :)
<wasabi_> Oh. Yeah. Heh. Put a Xen VM on the drive.
<wasabi_> I'm more fond of the completely networked world... you don't need to carry your stuff with you.
<wasabi_> But you shoud be able to get to it, wherever it is, from wherever you are.
<wasabi_> Being able to sit down in an airport at GDM, specify a username in the form of wasabi@mydomain.com, and a password.
<wasabi_> (or smart card)
<wasabi_> and having it just pop up.
<wasabi_> Sun-style.
<rawler> wasabi_: definitely cool, definitely fat-fetched, but not entirely fictional..
<wasabi_> Companies do it internally now.
<wasabi_> (Sun)
<wasabi_> Heck I do it to an extent with Windows.
<tfheen> SSO isn't hard to do, it's just a lot of work.
<wasabi_> tfheen: We're going to be talking about SSO a lot at the summit apparently.
<tfheen> wasabi_: we as in you and I or as in everybody?
<wasabi_> Me as in me and some other people. ;)
<tfheen> heh, 'k
<tfheen> it'd be nice if networkauth was completed, since it's kinda essential for SSO to be meaningful
<wasabi_> network auth = ?
<tfheen> https://wiki.ubuntu.com/NetworkAuthentication
<rawler> I've heard the Swedish police is working on a setup running Linux on 1Gb USB drives, and a floppy.. they the floppy, which in turns load a autoconfiguring DE from the USB drive, and they can work securely and disconnected wherever they go, and in most (x86) machines they encounter..
<wasabi_> Oh neato.
<wasabi_> whiprush and I have been talking about that.
<rawler> I heard the patrol-cars had some sw integrating to this as well, but don't remember exactly how..
<tfheen> rawler: you can do that trivially with Ubuntu; https://wiki.ubuntu.com/LiveUsbPendrivePersistent and a floppy with grub on it.
<rawler> clever.. :) I'll tip the police.. ;)
<wasabi_> First step, authentication against common Kerberos/LDAP systems with optional components (Samba/Windows)
<wasabi_> Second step, construction of authentication servers.
<wasabi_> Second step is going to take a few years. ;)
<tfheen> wasabi_: oh?  What auth servers are you missing?
<wasabi_> Say that again?
<tfheen> 23:41 < wasabi_> Second step, construction of authentication servers.
<rawler> from what I've heard they (swedish police) have been looking quite a lot into linux solutions recently, both for increased security and more efficient costs..
<wasabi_> Installation of a LDAP server + Kerberos + DNS in a supported and common format.
<tfheen> wasabi_: samba is probably going to grow into some sort of a super-server integrating a lot of this, I think.
<wasabi_> I don't think so.
<wasabi_> Samba is going to help drive the pieces out, but they are still seperate.
<wasabi_> You don't need MSRPC for a unix network.
<wasabi_> But, a MS network is still plain LDAP/Kerberos/DNS... so those need to be tight for Samba to accomplish their goal.
<wasabi_> And we get the benefits of that, without bringing Samba into the mix.
<tfheen> you need to integrate the DHCP server into it too.
<wasabi_> Yup.
<wasabi_> Well, maybe not, actually.
<wasabi_> MS doesn't really do so.
<wasabi_> Also, with ipv6, removing DHCP, it's best to not plan in that direction.
<tfheen> you need something like it for ddns.
<wasabi_> MS DHCP doesn't update DNS.
<wasabi_> The workstatiosn themselves do, using their computer accounts.
<wasabi_> Key missing piece from Bind.
<_ion> Avahi!
<wasabi_> Bah.
<wasabi_> insecure. ;)
<tfheen> wasabi_: uh, that's utter crack.
<tfheen> not hard to implement in bind though.  Just crackful.
<_ion> More insecure than workstations telling bind "yo, my address is now 1234:5678::42"?
<wasabi_> tfheen: MS DNS has ACLs.
<wasabi_> tfheen: Integrated exactly like FS ACLs.
<tfheen> wasabi_: that makes it more, not less crackful.
<wasabi_> Joining a computer creates an A record, and sets permission for the host/computername principal to update it.
<wasabi_> So, the hosts update themselves.
<wasabi_> tfheen: It's the only feasible method. DHCP is going away.
<wasabi_> It also works quite nice in practice.
<wasabi_> Since leasing a DHCP address is not a secure operation.
<tfheen> wasabi_: people have been talking about ipv6 almost being here for ten years.  I don't think dhcp or ipv4 is going away anytime soon.
<wasabi_> Me neither, but it's true some networks don't use it.
<wasabi_> With ipv4.
<wasabi_> zeroconf, etc.
<tfheen> *shrug*
<wasabi_> Anyways, the Samba guys have been working on the changes to Bind.
<wasabi_> Bind supports signed updates, just not with a KRB5 principal.
<whiprush> wasabi_: tfheen: that sounds awesome
#ubuntu-devel 2006-10-15
<Kim^J> Does the original kernel in Edgy eft knot3 have SMP support? Or do I have to install another one?
<Trae> BenC you here?
<Trae> BenC, the laptop overheat issue, https://launchpad.net/distros/ubuntu/+bug/22336 , It affects Debian's latest testing, as well as Fedora Core 6 pre (their latest release before the final this week)
<Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  
<wasabi_> whiprush: Have you been to a ubuntu dev summit/conference/thing, previously?
<Trae> The only two distro's I've seen NOT be affected by it are: Mandriva 2007 and Gentoo 2006.1
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<Trae> I really don't want to have to run Mandriva
<Trae> :(
<Trae> and Gentoo is too much compiling for my tastes
<jdong> Trae: hehe, gentoo has overheat issues unique to itself.... :)
<jdong> Trae: does a vanilla kernel exhibit the same issues?
<imbrandon> tfheen, can i get an OK to upload http://federation.imbrandon.com/amarok.debdiff tis a very trivial fix
<jdong> imbrandon: have you gotten to look at my ktorrent debdiff too?
<imbrandon> jdong, i just seen your message, i'll check it on my ppc tonight
<jdong> imbrandon: thankie
<Trae> jdong I ran for quite a while with gentoo ( in terms of testing ) about 72hrs.
<jdong> Trae: you should be able to isolate the patch from gentoo-sources that did the trick
<Trae> it was just too much work to keep compling stuff over and over, but gentoo passed all the tests that Ubuntu and others fail at
<Trae> jdong I am a Graphic Artist who happens to run Linux
<Trae> I don't know about development stuff
<Trae> I used Linux for 10+ years, but only as an end-user
<jdong> Trae: do you know how to compile kernels and use patch to apply patches?
<Trae> I mean, sure I can type ./configure && make && make install
<Trae> but that doesn't make me a developer
<Trae> heh
<Trae> jdong not realy
<Trae> I don't know how to do patches
<Trae> I've done them, like, back in 96', 97', 98' 
<Trae> when I had to, but I've all but forgotten any of that stuff
<Trae> And I hated it back then
<Trae> heh
<jdong> well, gentoo's patches are at http://dev.gentoo.org/~dsd/genpatches/trunk/
<jdong> if gentoo doesn't have the problem, one of those patches fixes it
<Trae> :(
<jdong> a quick glance/grep shows nothing ACPI related though
<jdong> which makes me question if that's the culprit...
<Trae> I can't see how this bug wouldn't be the #1 issue for all the distro's it affects
* imbrandon notes that this would be better of talking to the kernelteam #ubuntu-kernel
<jdong> Trae: because not all hardware exhibits this?
<Trae> having your distro bomb on a laptop... just seems very bad
<imbrandon> Trae, becouse very little hardware is afected by it
<jdong> none of the laptops I've ever used Linux on exhibit this
<Trae> imbrandon that one bug seems like a lot of laptops are affected
<imbrandon> Trae, not all laptops obviously as the whole laptop testing team and most developers run a lappy including myself
<wasabi_> My laptop works fine. =)
<jdong> Trae: put that into perspective with the number of laptops that run Ubuntu or Fedora Core combined
<jdong> it's certainly a very significant bug for those it affects, but it's not as widespread as you make it out to be...
<pirast> Trea, I didn't read the bug report, but can't that be caused by the the kernel not detecting the temperature correctly?
<Trae> acer, hp, fujitsu, toshiba
<imbrandon> anyhow all i'm getting at is this is better suited for #ubuntu-kernel as they can tell you exacly what to diag ( and they are normaly only arround durring the week )
<Trae> not major brands I know... (hp is)
<Trae> imbrandon the sad thing is, breezy never had a problem with this.
<pirast> (Trae)
<Trae> :(
<Trae> nor warty
<Trae> it's something that was introduced in Dapper Drake
<jdong> Trae: I have both acer and toshiba laptops, and they are fine
<jdong> so it's not as widespread as that
<Trae> jdong Do you run custom kernels?
<jdong> only a certain subset is affected
<imbrandon> Trae, as i said ALOT has changed since breezy , anbd mostly only the kernel team can help[
<jdong> no, I use stock Ubuntu kernels
<jdong> unless I have a _really good_ reason to deviate
<Trae> jdong nod...
<Trae> it just sucks that my laptop is basically now a freakin' useless brick
<Trae> unless I want to run Mandriva or Gentoo
<jdong> Trae: do you know if your lm_sensors reports temporatures correctly?
<jdong> Trae: if you lm_sensors can control your fans, just use fancontrol/pwmconfig to do userspace thermal
<imbrandon> ugh i give up, #ubuntu-kernel
<Trae> I'd rather have bamboo slivers drivin under my fingernails than use Gentoo
<Trae> heh
<jdong> imbrandon: that's a ghost town too... for today there's really not much of a difference :D
<Trae> jdong hmmm don't really know about lm_sensors
<imbrandon> jdong, yes there is , and i said that he needs to go in there durring the week, not say the same thing in here day after day
<jdong> Trae: give setting up lm_sensors a chance...
<Trae> my grub is busted ATM (after failed FC6pre attempted install)
<Trae> jdong hmm ok.
<jdong> good luck
<Trae> let me see if I can install grub again
<Trae> I've got an extra partition I've been using to do tests of other distro's
<Chipzz> jdong: the fact that someone doesn't get an answer elsewhere does not justify having them come complain here
<Chipzz> jdong: neither for #ubuntu, nor for #ubuntu-kernel
<jdong> Chipzz, imbrandon: sorry, I was already in the middle of getting him a workaround, didn't feel like migrating. I'm done now
* jdong shuts mouth
<Chipzz> jdong: I was just pointing out the "policy"; also, if you're the one helping it's not your fault either ;)
<JanC> <jdong> if gentoo doesn't have the problem, one of those patches fixes it  or one of the ubuntu patches breaks it...  ;-)
<Trae> heh
<Trae> In my experience, it's best to help when you can (provided a channel isn't swamped with discussion), and then kindly remind the particular use of a channel.
<Trae> like, if there was an active discussion going on.. and the user is OT, then that's a time to directly intervene.
<Trae> that's just my thoughts
<Trae> jdong tx for tring to help
<Chipzz> Trae: OTOH, most users do not care about anything but getting a solution for their problem
<Trae> I didn't even know there was an #ubuntu-kernel
<Chipzz> that's why they violate rules in the first place
<Trae> Chipzz I've been dealing with this bug since Dapper was released...
<jdong> JanC: I was about to say that, but diagnosing that is way beyond Trae's self-reported technical scope :-)
<Trae> heh
<Trae> jdong self-reported heh
<Chipzz> helping them out against policy makes that feeling even stronger, and may encourage them to do the same thing the next time too
<Chipzz> "Yes I know this is off-topic, but I need a solution for my problem, and I got helped here last time too..."
<Chipzz> and I have seen this exact thing happen
<Chipzz> users knowingly and willingly violating the rules for their own benefit
<mjg59> This conversation is not usefully topical.
<th_> hi lupine_85 
<th_> :)
<Chipzz> mjg59: heh :)
<Chipzz> mjg59: exactly :)
<imbrandon> mjg59, can only tfheen approve uploads atm ? i have a trivial upload 
<mjg59> I certainly can't
<imbrandon> k
<th_> is there any interest in making ubuntu detect bios raids like medley (silicon image/cmd) and nvidia?
<imbrandon> he's most likely gone for the day, i'll try to cacth him tomarrow
<th_> like so it can install from scratch with a windows on such a raid
<ompaul> th_, you should qualify that with what you have previously done
<th_> http://www.infowares.com/linux/
<th_> got my 2.4 kernel silicon image raid driver into the official kernel tree
<th_> anyway
<th_> i'm just trying to find out if this is something that is needed or not.. because I think a lot of people have windows installed on these bios raids
<th_> if I didn't have to dual boot myself, I'd of course go with Linux raid instead of biosraid, but many people already have these systems so we should support them
<ompaul> th_, I think you should hang out here until you see some kernel chat taking place
<th_> ompaul, thanks, I will
<th_> well, try that is ;) 
<ompaul> it may take until Monday
<th_> but I will have a look at what needs to be done to support this
<th_> knowing that it works in Gentoo it can't be impossible ;) I think some dmraid initramfs script might be what it takes..
<AlinuxOS> mjg59, ping (do you see me?, or maybe I'm not logged in freenode :( )
<ompaul> th_, message me an I will give you a quick tour around ubuntuland and its support stucture
<th_> AlinuxOS, you are in freenode alriight.. and to send a private messae you tyke "/msg username message"
<AlinuxOS> th_, I've alredy done this... but no respose... I guess there is something wrong with my cnnection..or loging stuff
<th_> AlinuxOS, what do you mean you have done it? you mean, implemented support for these bios raids?
<AlinuxOS> I mean I've alredy messaged mjg59 in private...but no response...
<th_> oic
<ajmitch> afternoon
<srbaker> dude
<_ion> Night.
<imbrandon> heya ajmitch
<ajmitch> hi imbrandon 
<keescook> tfheen: when you're back, I've got 1 main (libx11-6) upload ready to go in http://people.ubuntu.com/~kees/to-upload/ (and 2 universe, but I don't see dholbach around atm)
<poningru> iwj: ping
<poningru> anyone know where I can find the entire changelog for a particular package?
<poningru> in this case firefox
<jdub> /usr/share/doc/firefox/changelog.Debian.gz
<poningru> thanks
<poningru> mdz: ping
<imbrandon> moins jdub
<infinity> tfheen: Around?
<StevenK> infinity: Careful, tfheen doesn't like contentless pings.
<infinity> StevenK: He makes exceptions for the cute ones.
<imbrandon> infinity, uploaded ( incase you have to poke it through the queue or such ) , thanks 
* imbrandon is off to sleep
<infinity> I do have to poke, yes.
<jdub> mjg59: ping
<dholbach> hi
<mjg59> jdub: Hi
<dholbach> drop it like its hot
<jdub> mjg59: oh, was going to email you
<jdub> mjg59: i'll dot hat anyway
<mjg59> Dude, you have entirely unrealistic expectations of my response times
<mjg59> If getting back to you within 90 seconds of the initial query at 5:20AM isn't enough to stop you from going off to email me instead, what is?
<jdub> mjg59: email seemed to be the most sensible choice when i realised what time it was
<mjg59> jdub: Oh, yeah, saw that a while ago
<dholbach> i found a critical bug in edgy
<dholbach> a very critical one, take care.
<dholbach> it's already reported
<mjg59> dholbach: Mm?
<keescook> dholbach: I've got two universe uploads for you to look at, when you've got a moment: http://people.ubuntu.com/~kees/to-upload/
<keescook> for the openssl ->098 migration, ettercap & aolserver4
<dholbach> w/e
<dholbach> night
<keescook> ssh
<dholbach> I will tommorow
<keescook> yup, hence the "when you've got..."  :)
<imbrandon> hrm
<fabbione> who is part of the U. Media team?
<fabbione> or multimedia?
<BHSPitLappy> do you mean the artwork/audio teams, or something else?
<minghua> fabbione: I believe crimsun is in multimedia team
<minghua> fabbione: they actually have a LP page: https://launchpad.net/people/motumedia
<fabbione> BHSPitLappy: no. i meam multimedia
<fabbione> siretart, crimsun: ping
<fabbione> minghua: thanks
<fabbione> sharms: ?
<siretart> fabbione: good morning!
<fabbione> simira: morning...
<fabbione> bug #63493
<Ubugtu> Malone bug 63493 in mythplugins "mythweb.postinst: 31: Syntax error: Bad substitution (fix is to use Bash instead)" [High,Confirmed]  http://launchpad.net/bugs/63493
<fabbione> siretart: i meant
<siretart> :)
<fabbione> siretart: it's one liner.. can we please get that done yesterday?
<fabbione> infinity: i just uploaded iproute to fix FTBFS (wrong B-D) it's quite obvious fix..
<siretart> oh. slomo is AFAIK still on holiday.
<fabbione> infinity: 66207
<fabbione> siretart: well holidays or not, Release is getting closer ;)
<fabbione> tfheen: ^^
<siretart> fabbione: I have heard something like that. ;) - yes, I'm looking at it
<neuralis> fabbione: long time no see
<neuralis> fabbione: how are you?
<fabbione> hey neuralis 
<fabbione> i am okish and you?
<fabbione> i saw you might show up at MV
<neuralis> yeah, i'll be there
<neuralis> okish sounds about right :)
<neuralis> i wanted to ask -- did we ever put together a decent installation guide for sparc?
<fabbione> yeah just a bit tired but otherwise fine
<neuralis> yeah, same here
<fabbione> neuralis: is there any point in making one when the installer is exactly the same?
<fabbione> you get no extra or different questions except for a warning before writing the partition layout to disk
<fabbione> and that's about it
<neuralis> hmm
<neuralis> i need to try edgy; with dapper, it looked like the sas controller wasn't being detected
<fabbione> neuralis: what kind of hw?
<neuralis> t2000 (t1)
<fabbione> i know that T2000 rev2 requires edgy kernel
<fabbione> yeah but is it rev1 or rev2 of the hw?
<neuralis> that'll do it, then
<neuralis> rev2, i believe
<fabbione> does it have the sas controller on board or on a pci slot?
<neuralis> looked to be on-board, but it's 3:28am, so i might be misremembering.
<fabbione> if it is on the mobo it's rev2
<fabbione> and it needs edgy
<fabbione> natural evolution :)
<Kamion> there's already installation-guide-sparc
<neuralis> right. okay, cool; i'll throw edgy on there tomorrow or monday.
<Kamion> patches welcome if it's inadequate
<Kamion> it's built from the same source as the other installation guides
<fabbione> Kamion: it's just neuralis that's weird ;)
<neuralis> haha
<neuralis> no, it's just neuralis that's used to having to do all sorts of magic to get sparc machines happy with linux in the earlier years
<neuralis> anyway, i'll check things out and submit doc patches if need be.
<fabbione> neuralis: i don't have rev2 hw here, but i am told by a few SUN guys that works ok
<Kamion> Riddell: I think speedcrunch, attal, kmformat need to be modified to take the removal of libqt4-debug-dev into account
<neuralis> fabbione: yeah, i'm happy to debug if not. i only had about 10-15 minutes to play with it before leaving the office, which is why i was asking if it's known.
<fabbione> fair enough
<fabbione> neuralis: how much time do you have before slamming it into production?
<fabbione> neuralis: i would like to get access to it to see if i can get dapper to work on it
<fabbione> and given the TZ diff, i can do the work while you sleep
<neuralis> fabbione: i don't have alom hooked up yet, but certainly, i'm happy to set that up
<fabbione> neuralis: i will need ALOM and access to a machine from where we can do tftpboot
<neuralis> of course
<fabbione> that would rock
<neuralis> sure. are you in a rush? it'll be a lot easier for me if it can wait about 3-5 days, but if you need it earlier, i can probably try and arrange it.
<fabbione> nah 3/5/7 days are fine
<neuralis> perfect.
<fabbione> but you are the first one i know from where i can get access :)
<neuralis> not a problem
<neuralis> is the sas patch easily backportable to the dapper kernel, or do you have a better approach in mind?
<fabbione> neuralis: i need to check that basically. i am not sure if it is only a matter of PCI-ID or it needs more
<fabbione> the changes to the sas driver between dapper and edgy are almost all related to the hw RAID support
<fabbione> that doesn't work in dapper
<neuralis> right
<fabbione> there are also a bunch of bugs opened for that one
<fabbione> so i want to see how reasonable is a backport of the driver
<neuralis> yeah, makes sense.
<neuralis> okay, i'll mail you close to the end of the week and we can get it going.
<fabbione> neuralis: thanks.. that's fine
<neuralis> 4am; sleep time. cheers, it'll be good to see you in mv
<siretart> fabbione: fix for bug #63493 uploaded
<Ubugtu> Malone bug 63493 in mythplugins "mythweb.postinst: 31: Syntax error: Bad substitution (fix is to use Bash instead)" [High,Fix committed]  http://launchpad.net/bugs/63493
<fabbione> siretart: good boy
<fabbione> ajmitch: only 1600 pkgs left to build.. once that's done i will rekick only main.. 
<fabbione> ajmitch: do you still want to get the mails for that or not?
<ajmitch> I don't mind getting them
<fabbione> ok
<ajmitch> only 650MB of build logs so far :)
<fabbione> yeah it's not that much
<duncan> who can i talk to about upping my priveleges on launchpad?
<duncan> It's mostly just because I'm finding bugs which clearly need closing but I can't seem to get anyone to notice.
<ajmitch> you can close bugs
<ajmitch> you just won't be able to set importance unless you're in the ubuntu-qa team
<duncan> I can't find a way to do that anywhere. I'm thinking for example of bug 54095
<Ubugtu> Malone bug 54095 in acpi-support "monitor dim/brighten reversed (HP Pavilion dv8220ea)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/54095
<StevenK> Click on the link listed under "Affects"
<duncan> StevenK-> I have two 'Also Affects...'. I can't see how they can help
<StevenK> Just above that.
<StevenK> For example, "acpi-support (Ubuntu)" is the link I'm refering to.
<duncan> aha, now I've found it. Thanks - I guess I'll slowly become more useful...
<minghua> There REALLY should be a LP usability bug open for that thing
<Burgundavia> minghua: most of LP's interface is fundmentally broken
<infinity> fabbione: approved and accepted.
<tfheen> imbrandon: amarok > approved
<tfheen> fabbione: mythplugins is multiverse, I don't do *verse.
<Kamion> tfheen: edubuntu-meta and xubuntu-meta uploads from me in unapproved to *actually* remove the *-live metapackages - ok?
<tfheen> Kamion: approved
<Kamion> tfheen: sync requests in bug 65972 and bug 65973 need your approval
<Ubugtu> Malone bug 65972 in planner "Please sync planner (main) from unstable (main)" [Undecided,Confirmed]  http://launchpad.net/bugs/65972
<Ubugtu> Malone bug 65973 in rus-ispell "Please sync rus-ispell (main) from unstable (main)" [Undecided,Confirmed]  http://launchpad.net/bugs/65973
<Kamion> (or otherwise)
<tfheen> Kamion: I think those can be left for edgy+1
<tfheen> (there are no other bugs on rus-ispell in Ubuntu; the planner update is really just a sync and I'd rather have us go with what we have and have tested than something else when it doesn't fix any targetted bugs)
<Kamion> tfheen: ok, could you comment on those bugs?
<Kamion> (I more or less expected that answer)
<tfheen> Kamion: will do.
<azazel> i guys where should i file in generic bugs for edgy? i'm trying it out on my powerbook titanium and both sound and resume aren't working anymore (in dapper they workerd fine)
<tfheen> azazel: all bugs should be reported in launchpad.
<Kamion> if you don't know the correct source package, then leave that field empty
<azazel> yes... but where ? here? https://launchpad.net/distros/ubuntu/edgy/+bugs
<tfheen> https://launchpad.net/distros/ubuntu/+filebug
<azazel> tfheen: done, thanks
<Kamion> tfheen: ditto bug 65963
<Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
<tfheen> Kamion: iirc, doko was supposed to upload a fix for just the warning; I can't say I want to sync toolchain stuff at this point (when all it fixes is a build-issue for a universe package)
<gnomefreak> doko__: you around i need to ask you something about eclipse depends for somereason the depends on eclipse is set like this: libjsch-java (>= 0.1.19) libjsch-java (<< 0.1.20) but edgy uses 0.1.28-1
<xav> gnomefreak, which package?
<gnomefreak> libjsch-java is the depends issue for eclipse
<xav> I've both eclipse and libjsch 0.1.28 installed
<xav> for eclipse-platform, I see: libjsch-java (>= 0.1.16)
<gnomefreak> xav: im building eclipse and its complaining
<xav> oh, so that's build-deps ?
<gnomefreak> bug 66190
<Ubugtu> Malone bug 66190 in eclipse "[Edgy]  Eclipse wont build unmet depends" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66190
<gnomefreak> xav: yes
<gnomefreak> ^^ the bug on it
<pygi> gnomefreak: so debdiff and attach? :)
<xav> well maybe remove the << 0.1.20 first, build eclipse and check it works fine
<gnomefreak> i dont have edgy pbuilder :(
<gnomefreak> can i change the file save it and run apt-get source -b?
<gnomefreak> or would i need to use pbuilder like any other package?
<xav> afaik, you never need pbuilder
<Kamion> tfheen: ok, please say that in the bug?
<xav> but you can always use it
<tfheen> Kamion: done
<Kamion> thanks
* Hobbsee wonders what has caused NM to stop finding her atheros wifi card, in the last 48 or so hours.
<gnomefreak> it seems to be all of the depends are off
<sivang> morning / afternoon all
<Hobbsee> hey sivang 
<sivang> hi Hobbsee , what's cracking, how are we doing with the UNMETDEPS stuff?
<Hobbsee> sivang: not sure, i've uploaded a few
* Hobbsee has been doing work and uni work
<sivang> Hobbsee: I see, I've seen lots of stuff by MIchael, he has been busy ;-)
<Hobbsee> hehe, yeah.  i've been uploading them :)
<Hobbsee> geser: is here
<gnomefreak> doko__: eclipse isnt playing nice with me im re building it but found out other lib versions need to be changed. let me know if you want to build it all i will give you the changes if you want.
<gnomefreak> doko__: here is the full story bug #66190
<Ubugtu> Malone bug 66190 in eclipse "[Edgy]  Eclipse wont build unmet depends" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66190
<giftnudel> hi sivang, have you gotten around to look at my approach?
<sivang> giskard: I have glanced at it, I'm keen to do something testing with it
<sivang> oops
<sivang> giftnudel: ^^
<sivang> giftnudel: can I jus take the file put it in and test, or is this just a sketch?
<sivang> giftnudel: also, does it work on DVDs as well?
<giftnudel> sivang: no it doesn't work on dvds, since it uses cdrecord
<giskard> sivang: :P
<giskard> :)
<sivang> giftnudel: okay, that's okay
<giftnudel> sivang: you can merge the relevant changes to your DeviceInfo.py, it's one big block
<sivang> giskard: sorry , but if you want to help on hubackup you're welcome :-)
<giskard> what is it?
<giftnudel> sivang: I works with my multisession cd, so I'm really interested if it works in general
<sivang> giftnudel: yes, I shall do that, also, it not a big problem to probably make this work using dvd+rw tools and make it seemlessly support DVDd
<sivang> giftnudel: I shall do some testing now. I just need to finish some talks with libburn upstream , pygi :)
<giftnudel> sivang: dvd+rw-mediainfo works with dvds
<giftnudel> it might do it
<giftnudel> sivang: ok
<sivang> giftnudel: you interested to try add support to device info using it, you can check if it's dvd/cd from the hal info already there.
<sivang> giftnudel: ?
<sivang> giskard: apt-cache show hubackup
<sivang> giskard: (make sure you have universe enabled)
<giftnudel> sivang: I will try to make that work with dvds, (if mediainfo does provide useful output
<giftnudel> )
<sivang> giftnudel: you'r my hero :)
<giftnudel> sivang: oh, wait and see if it works ... ;)
<giskard> sivang: :P 
<sivang> giftnudel: well, you deserve praise just for your help attempts and sharp approach to that.
<zul> *sigh* i need a uvf exception
<infinity> zul: For?
<zul> xen 3.0.3-rc5
<zul> fixes the udev rules as well
<infinity> Beg dholbach and/or ajmitch.
<zul> yep ill wait for ajmitch
<infinity> Also, are you going to upload a new xen-source with Tollef's fixes, so I can finally get XRM building for you?
<infinity> If you upload xen-source, I'll approve that right away as an FTBFS fix.
<zul> yep will do that today im about to do some more changes
<infinity> Kay, get it in in the next 8 hours and ping me, and I'll approve it when I wake up in the morning.
<zul> ok cool
<giftnudel> sivang: btw, I have set up a temporary bzr branch on http://www.student.informatik.tu-darmstadt.de:8080/~mbergner/hubackup/hubackup--main/
<sivang> giftnudel: make sure you update reglarly from my location, but very cool :)
<giftnudel> sivang: well, I'm a bzr newbie, so expect some problems ;)
<sivang> giftnudel: I'm happy to show you the way
<giftnudel> sivang: if you find the first problem, please tell me, but I think up to now, everything should be fine ;)
<sivang> giftnudel: I shall just branch from you, you already got the device info improvements inside right/?
<giftnudel> I should
<tfheen> zul: you don't happen to have an idea about what my 2.6.17 problem with xen on amd64/smp can be, do you?
<zul> no i dont did it work with 2.6.16?
<giftnudel> sivang: to update to your branch, I can use update and merge?
<sivang> giftnudel: after you've merged from me nce
<sivang> giftnudel: once,
<sivang> giftnudel: actually no, you just merge everytime I tell you I made new changes
<giftnudel> ok
<sivang> giftnudel: (or you check it with bzr missing and locatoin)
<sivang> *location
<sivang> so:
<sivang>  1) bzr branch sivang--main
<sivang>  2) hack my stuff there
<sivang>  3) commit, push to my web space
<bhale> hi sivang 
<sivang>  4) bzr missing sivang's-location
<sivang>  5) bzr merge sivang's location if changes were made
<sivang> let's make sure we don't touch same files at a given time, to avoid conflicts
<sivang> hi bhale 
<sivang> bhale: no more tseng? :)
<Lathiat> tfheen: any further comments on the avahi init script stuff?
<giftnudel> sivang: I'll see if that helps me, if not, I will ask you again, thanks!
<bhale> sivang: nope.
<sivang> giftnudel: np, feel free to ping, or email if you need
<giftnudel> I will
<tfheen> Lathiat: I think it's a tad late to come running with this bit now.  While it's unfortunate, only advanced users should be confused, right?
<tfheen> advanced in this case is "people who run random stuff from /etc/init.d"
<Lathiat> tfheen: no, same thign happens tryign to use the services gadget in system->administration
<Lathiat> tfheen: also people who try install avahi-daemon from synaptic or even apt-get.. judgying by the bug reports they aren't 'advanced users' there just users trying to make it work
<tfheen> Lathiat: why wasn't this picked up a week or a month ago?  It's not a new issue, is it?
<Lathiat> no its just come more to my attention that i consider it might be a running problem
<Lathiat> from the couple extra bugs of late etc
<Lathiat> and af ew people on irc
<Lathiat> as i said in my followup email i think theres a realtively "low-risk" way of doin git.. but yeh i understand we're in pretty hard freeze etc :\
<tfheen> Lathiat: hmm.  Your proposed solution at this point is exactly what?
* bhale notices that tfheen is not in the mood to grant UVF
<tfheen> bhale: we have a relase candidate due on Thursday, so your analysis is quite likely to be correct.
<siretart> fabbione: re bug #66212
<Ubugtu> Malone bug 66212 in wpasupplicant "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/66212
<siretart> fabbione: what makes you think the problem is in wpasupplicant rather then libqt4-dev?
<siretart> fabbione: the mysql dependency is absolutely unneeded, because wpasupplicant nor wpa_gui doesn't do anything with mysql
<siretart> fabbione: the fact that qt4 requires this, doesn't seem to be the problem of the wpasupplicant package to me
<sivang> giftnudel: you have the free space fix applied in your repo?
<sivang> giftnudel: I just want to branch and debuild :)
<sivang> (and test)
<giftnudel> sivang:  it should be in there, yes
<sivang> giftnudel: cool, thanks
<giftnudel> sivang: I should have the dvd part done by tomorrow, I might create a new file CDMisc.py if you don't mind
<giftnudel> sivang: where all the cd, dvd detection stuff will be in (there are some problems with hal and some correct values which dvd+rw-mediainfo does correctly)
<sivang> giftnudel: feel free to be as creative as needed. so this module would be imported by DeviceInfo.py and then it's 'low level' bits be used there?
<giftnudel> yes
<sivang> giftnudel: you also fixed the fle name with spaces qoute problem yes?
<sivang> (according to the diff)
<giftnudel> oh, yes
<giftnudel> I think so
<sivang> giftnudel: did you apply the patch from malone?
<giftnudel> yes
<sivang> (I happily saw someone posted that there)
<giftnudel> that was me ;)
<sivang> oh
<giftnudel> I was a little bored ;)
<sivang> stupid me to not notice
<sivang> giftnudel: very cool, I really appriciate it
<giftnudel> oh well, the translation irc_nick <=> real name is not that easy sometimes ;)
<sivang> giftnudel: yes, indeed. I need to upload a new version of your fix anyway, should do it today or tomorrow. (the quote fix)
<giftnudel> yes, the real problem was the cmd_line.split, the rest is just safety I guess
<giftnudel> sivang: oh, wait
<sivang> giftnudel: why are you replacing the spaces with slashes btw?
<giftnudel> sivang: I think the " " in the cmd_line are wrong
<giftnudel> sivang: with "\ ", you don't need to quote the line then
<sivang> ah right
<sivang> escape for space, good catch! :)
<Kamion>   109622 | S- | cernlib              | 2005.dfsg-5ubuntu1   | 3 hours 20 minutes
<Kamion>          | * cernlib/2005.dfsg-5ubuntu1 Component: universe Section: science
<Kamion>   109530 | S- | qt4-x11              | 4.2.0-1ubuntu2       | 25 hours
<Kamion>          | * qt4-x11/4.2.0-1ubuntu2 Component: main Section: libs
<giftnudel> sivang: but "/path/to\ empty/"  is wrong
<Kamion>   109473 | S- | kubuntu-default-sett | 1:6.10-58            | 38 hours
<Kamion>          | * kubuntu-default-settings/1:6.10-58 Component: main Section: kde
<Kamion>   109420 | S- | xorg-server          | 1:1.1.1-0ubuntu12    | 44 hours
<Kamion>          | * xorg-server/1:1.1.1-0ubuntu12 Component: main Section: x11
<Kamion> tfheen: ^--
<sivang> giftnudel: ?
<giftnudel> sivang: COPY_CMD_LINE = '-Q -y -v -m 256 -s %s -D -R %s -c %s -Z "*.gz" -Z "*.bz2" -Z "*.zip" ' <- this is correct, note the missing " " at -s %s (should not be -s "%s")
<giftnudel> sivang: I don't know if I did this correctly or not
<sivang> giftnudel: so you wanted to drop off the double quotes?
<Kamion> that all sounds like a security nightmare if whatever expands %s doesn't escape unsafe characters
<giftnudel> Kamion: right
<Kamion> (by which I mean, escape anything it doesn't know to be safe)
<giftnudel> Kamion: it gets the path from a filechooser, that should be safe actually
<giftnudel> no it isn't...
<Lathiat> tfheen: To move /etc/init.d/avahi-daemon to /etc/dbus-1/event.d/25avhai-daemon as is
<Lathiat> tfheen: and modify init.d/avahi-daemon not to do the default checking
<Lathiat> tfheen: https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021733.html
<Kamion> giftnudel: er, no
<giftnudel> sivang: hmm, let me think about this fix and if I can do it better ... maybe -s "%s" is better, then remove the sourcePath.replace() stuff, that should be much better
<Kamion> giftnudel: well, *perhaps* safe in that you can only compromise your own account unless this is set-id, but it might well do the wrong thing. What happens if you create a file containing spaces and try to use it?
<Kamion> "%s" is almost always wrong
<Kamion> if you have to use "...", it implies that the code expanding %s isn't quoting properly
<Kamion> in which case, what happens if the filename contains a literal "?
<giftnudel> Kamion: well the space stuff is handled correctly now, but  I wonder at stuff like " & ; does it
<tfheen> Kamion: kubuntu-default-settings and xorg-server were approved yesterday, iirc?
<tfheen> Kamion: what's the changelog for the qt4-x11 upload?
<pitti> sivang: you try to call a program with that set of command line arguments from python or from shell? (in python you should never use shell=True if you can avoid it)
<Kamion> tfheen: k-d-s/x-s> dunno, I haven't been keeping track
<Kamion> giftnudel: there's no excuse for only handling *some* metacharacters, IMHO
<giftnudel> Kamion: yes, that's true
<Kamion> if you're fixing it for some of them, do it properly :-)
<Kamion> tfheen: I'll review the universe one
<sivang> can't double quoting helpe a bit here? (although not enough)
<Kamion> sivang: that's not a solution.
<Kamion> it just papers over some instances of the problem
<giftnudel> you can do something like if ' in path quote with "", else with ' ' 
<Kamion> tfheen: it's from Riddell:
<Kamion> +  * Install usr/bin/qdbus usr/bin/qdbusxml2cpp and usr/bin/qdbuscpp2xml
<Kamion> +    closes Malone No 66098
<Kamion> giftnudel: oh god no
<giftnudel> hehe, I know ...
<Kamion> does nobody understand escaping?
<sivang> right, so need to make sure everything received from user is well quoted
<giftnudel> no, better escaped
<sivang> pitti: this is from python, lemme check again
<sivang> sorry,
<sivang> I wanted to say escaped
<giftnudel> like /path/to/\;\ \&\ strang_pathname
<sivang>         self.proc = spawn('dar',self.BACKUP_CMD_LINE.split())
<sivang> pitti: ^^^
<sivang> so probably is using the shell...
<Kamion> use the subprocess module if you can
<tfheen> Kamion: ok, qt4-x11 approved.
<pitti> sivang: you should use subprocess.call() with a proper argv array
<sivang> pitti: I need to be able to monitor the process through a ptry
<sivang> pty
<pitti> sivang: well, if you can do it with spawn, you can do it with subprocess.Popen()/communicate()
<giftnudel> pitti: like call(proc, ("-s", path) and path can be anything like /path/to file
<giftnudel> pitti: (so will it work with strange paths)
<giftnudel> empty spaces, &, " and so one in it
<sivang> pitti: I'm actually using python-expect
<sivang> In [3] : print pexpect.spawn.__doc__
<sivang> This is the main class interface for Pexpect.
<sivang>     Use this class to start and control child applications.
<Lathiat> tfheen: (a possibly better 'implementation' detail would be to check $0 and see if it matches 25avahi-daemon or something)
<pitti> sivang: you can get stdin/out/err FDs from subprocess easily; please read the documentation about subprocess
<sivang> so this is the spawn  I use
<Lathiat> tfheen: do you want me to prepare a patch so you can review or would you rather leave it?
<pitti> sivang: in general, please avoid using the shell in python, unless you have a very good reason to use it
<Kamion> sivang: I suggest reading the Secure-Programs-HOWTO if you haven't already done so
<Kamion> even if your program is not on a security boundary, following its recommendations is likely to improve your program's reliability
<pitti> sivang: a backup program which can possibly work automatically is most likely a security threat if it allows shell injection
<sivang> pitti: what is wrong by using pexpect? it saved me time and effort having to reimplement my own pty subprocess control system. I wonder if it can use some sort of escape mechanism
<pitti> Kamion: not sure, but things like browser caches are prone to arbitrary file name injection (maybe not firefox, but in general)
<tfheen> Lathiat: prepare the patch, and I'll review it.
<tfheen> Lathiat: that's not a promise it'll be accepted, mind.
<sivang> pitti, Kamion : I see
<sivang> pitti: also, the program is not htat much of an 'automatic' , but more need to be actively operated to do something.
<pitti> sivang: hm, if pexpect wants to do the spawning itself, and doesn't just accept a stdin/out pair, it seems quite badly designed
<Lathiat> tfheen: *nod* ok thanks
<pitti> sivang: (I don't know p-expect, not sure whether it's really like that)
<tfheen> Lathiat: oh, and if you want it in, please make that patch now rather than later.  I'm going to totally close the door for such updates tomorrow morning (UTC)
<Kamion> there really should be a standard Python codec that escapes shell metacharacters, so you can do .encode("shell_escape") - there's the string_escape encoding but it's not clear that it's guaranteed to be safe for use outside python
<sivang> I can check how pexecpt does it's spawning
<sivang> IIRC it uses subprocess
<pitti> Kamion: I guess it's not pythonic to encourage the programmer to use Unix specific shells instead of subprocess (and I can perfectly understand that, too)
<sivang> pitti: subprocess.call() is not prune to that vulns ?
<pitti> sivang: it would be nice if it would accept a Popen object or a pair of file handles instead of a shell command string
<pitti> sivang: if you use the default (shell=False) and use an argv array instead of a string, then there is no shell involved
<Kamion> sivang: pexpect knows how to accept a list of arguments rather than a shell command
<Kamion> __init__(self, command, args=[] , timeout=30, maxread=2000, searchwindowsize=None, logfile=None, env=None)
<pitti> sivang: it's similar to using execv() instead of system() in C
<Kamion> pitti: right, but metacharacter expansion is at least as generically useful as, say, the palmos encoding
<pitti> heh, true
<sivang> I see now that there's an fdepxect module, in beta that commetns say will move intp pexpect when proven to be stable enough
<sivang> intersting
<sivang>     """This is like pexpect.spawn but allows you to supply your own,
<sivang>     already open file descriptor. For example, you could use it to
<sivang>     read through a file looking for patterns, or to control a modem or
<sivang>     serial device.
<Kamion> in this case it does not sound like it adds significant value over using the existing support in pexpect for supplying a list of arguments
<Kamion> just use %s and make sure that your code to expand that always fills in the filename as a single argument
<Kamion> for instance: COPY_CMD_LINE = ['-Q', '-y', '-v', '-m', '256', '-s', '%s', '-D', '-R', '%s', '-c', '%s', '-Z', '*.gz', '-Z', '*.bz2', '-Z', '*.zip'] 
<Kamion> assuming that assignment is in a Python program
<hash_> Hi, just wondering if Edgy is frozen even for small bug fixes?
<sivang> yes
<mjg59> Especially for small bugfixes
<Kamion> hash_: small release-critical bug fixes are allowed but need to come very soon indeed
<hash_>  It's a trivial fix, here's the patch: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/sinhala/patches/firefox_1.99%2B2.0rc2%2Bdfsg-0ubuntu2-sinhala1.patch?root=sinhala
<Kamion> non-release-critical fixes will have to wait
<sivang> Kamion: so s/\"/\'/ ?
<Kamion> sivang: well done, you picked out the least relevant part of my suggestion ...
<Kamion> (it doesn't matter in this case)
<sivang> sorry, but I picked the previous parts as well ;)
<sivang> it will just help fpr the expansing, it won't help injection ofcourse
<Kamion> I just use '' out of habit unless I need ""
<Kamion> sivang: huh?
<sivang> (since someone coul provide ' at the filename)
<Kamion> sivang: that is not true
<pitti> saves a shift key press :)
<pitti> sivang: unlike perl and shell, python does not treat ' and " differenlty
<Kamion> sivang: you've missed the point of using a list
<sivang> that what I recalled, but Colin's comments made me doubt that :)
<hash_> We need to enable Pango for the si locale, otherwise Sinhala does not get rendered in Firefox, that's critical for us, but would that be considered critical by ubuntu?
<sivang> Kamion: the original code before giftnudel's suggestion was using a list:
<Kamion> sivang: the '...' are only parsed when Python is constructing the list COPY_CMD_LINE itself
<Kamion> sivang: you then take a copy of that list, and iterate over it filling in the %s bits
<sivang>         self.proc = spawn('dar',self.BACKUP_CMD_LINE.split())
<Kamion> sivang: at that point Python couldn't care less whether the strings you copy into the new list contain ' characters or not
<Kamion> hash_: unfortunately our firefox maintainer doesn't tend to be around at weekends
<Kamion> tfheen: what do you think about that firefox pango change?
<Kamion> sivang: self.BACKUP_CMD_LINE there isn't a list, it's a string. the error-prone part is that split()
<hash_> Kamion: should I open a bug in launchpad?
<Kamion> sivang: you should be working with a list throughout rather than having a stage where it's a string that you have to split up
<Kamion> hash_: yes
<hash_> Kamion: should I add anyone in particular to the CC list? e.g. release manager?
<Kamion> hash_: I've already asked tfheen for his opinion
<sivang> Kamion: error prone in that it fails on space contaiing file names, yes, so your suggestion is to iterate over COPY_CMD_LINE as a list, and then construct a string out of it, then feeding it to spawn? or just feed COPY_CMD_LINE as a list to spawn since it receives list arg as well?
<Kamion> sivang: no no, don't construct a string at any point!
<hash_> Kamion: Thanks!
<Kamion> sivang: any point where a string with multiple arguments is involved for a shell command is a possible security vulnerability or reliability problem
<Kamion> sivang: just feed it straight through as a list
<sivang> ah okay, that should resolve the issue of space containing file nmaes as well as the secuirty vuln ?
<pitti> sivang: yes (I hope you understand, why)
<sivang> pitti: let's see if I understood why:
<pitti> sivang: let f be 'foo bar', then compare ['cp', f, 'target/']  (direct execve) with 'cp %s target/' % f that's executed in a shell
<pitti> sivang: let f be '; rm -rf ~; true' for a more drastic example 
<sivang> yes, so eseentially, being inside a list, not injection can really be made,
<sivang> since everything will be treated literaly, or just break invocation through the args supplied to the spawn comman
<sivang> command
<pitti> sivang: the real point is not that you cannot inject random stuff into a list, but that you avoid passing random stuff to a *shell*
<pitti> sivang: right
<pitti> sivang: the golden rule is: *never* call a shell with anything that is provided by the user
<sivang> that is like the never access the db with anything that is provided by the user for web devel :-)
<sivang> (or before you've used a built in escaping func, after thoroughly checking it)
<_ion> pitti: Hi. You've probably noticed these already, but just in case: please see bug #65914 and bug #65917.
<Ubugtu> Malone bug 65914 in apport "apport-retrace -d fails with KeyError" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65914
<Ubugtu> Malone bug 65917 in apport "Doesn't handle diversions" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65917
<sivang> pitti, Kamion : thanks for the tips I should also read the howto as well.
<giftnudel> sivang: want me to take care of the problem or do you want do to it?
<giftnudel> pitti, Kamion: yes thanks alot ;)
<sivang> giftnudel: be my guest :)
<pitti> sivang: exactly
<pitti> _ion: I did, but I'm afraid it's a little too late for fixing them for edgy
<giftnudel> sivang: ok, then I will do that I will rewrite the thing so that we only use a list and not a string
<_ion> pitti: Ok, thanks.
* sivang hugs giftnudel 
<giftnudel> sivang: I will open a bug about that and will assign it to me, so that it's clear that we are working on it
* giftnudel hugs sivang back
<sivang> giftnudel: thanks alot dude
<giftnudel> no problem!
<bluefoxicy> oh wow
<bluefoxicy> full real-time patches in 2.6.18!
<tfheen> Kamion: what firefox pango change?
<bluefoxicy> edgy is a 2.6.17 but these are gonna be on in Edgy+1 right?
<tfheen> bluefoxicy: we're probably going to have 2.6.19 for edgy+1
<bluefoxicy> tfheen:  yes but you can disable the real-time ptaches
* bluefoxicy wants it all though, has been waiting for this :)
<Kamion> tfheen: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/sinhala/patches/firefox_1.99%2B2.0rc2%2Bdfsg-0ubuntu2-sinhala1.patch?root=sinhala per hash_ above
<Kamion> tfheen: kubuntu-default-settings accepted; there was a concern about xorg-server using a patch in debian/patches to patch a file in debian/local, which is a bit crackful
<bluefoxicy> tfheen:  you know I have multiple times wanted the newer kernels for one reason or another, pretty much every release; it's bounced between "Driver X crashes my system and is essential" to "Kernel has new feature that I want" (or:  preempt is disabled due to bug in our version).  These have never, ever hit backports.  o_o
<tfheen> Kamion: agreed; Seb was the uploader, wasn't he?
<Kamion> tfheen: yes
<tfheen> Kamion: si is which language again?
<Kamion> <cjwatson@cairhien ~>$ grep -w si /usr/share/iso-codes/iso_639.tab
<Kamion> sin     sin     si      Sinhala; Sinhalese
<giftnudel> sivang: I recycled bug 59412 for that ;)
<Ubugtu> Malone bug 59412 in hubackup "Malformed directories can cause hubackup to crash" [High,In progress]  http://launchpad.net/bugs/59412
<sivang> giftnudel: very good, recycling is good for the environemtn!
<giftnudel> :)
<tfheen> Kamion: the change looks innocent enough; I have no idea whether it's needed for Sinhalese, though, given that even with the name I'm not sure where it's spoken.
<mdke_> sri lanka
<giftnudel> sivang: ok, I need to go now, I think this will be finished at the end of this week
<Kamion> sounds plausible for an Indic language
<tfheen> Kamion: ok, let's do it.  Can you upload a fixed package?
<hash_> tfheen: Pango is needed by Sinhala
<Kamion> should be able to, let's see
<hash_> Kamion: does this mean I don't have to open a bug?
<Kamion> but you'd better not finger me for TILM of firefox
<Kamion> hash_: please do anyway and tell me the bug number
<tfheen> Kamion: we have iwj for that. :-)
<Kamion> I wonder if I can realistically test it ...
<tfheen> Kamion: hash_ should be able to point to a page which doesn't render correctly with it?
<Kamion> hash_: yes, if you could give me a URL that would be good
<hash_> Kamion: more info here: http://bugzilla.gnome.org/show_bug.cgi?id=361538
<Ubugtu> Gnome bug 361538 in I18N "Add si (Sinhala) to the list of locales requiring Pango" [Major,New]  
<Kamion> is there a Sinhala-capable font in Ubutu?
<Kamion> Ubuntu
<hash_> ttf-freefont has glyphs but some lookups are missing.
<hash_> Kamion: launchpad bug number: 66270
<tfheen> bug 66270
<Ubugtu> Malone bug 66270 in firefox "Add si (Sinhala) to the list of locales requiring Pango" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66270
<mjg59> tfheen: I've got a two-line diff that fixes the "only the first suspend works" bug
<tfheen> mjg59: bug #?
<mjg59> #56365
<mjg59> bug 56365
<Ubugtu> Malone bug 56365 in xserver-xorg-video-i810 "X crashes on second resume from suspend-to-ram on Thinkpad X41" [Critical,Confirmed]  http://launchpad.net/bugs/56365
<tfheen> oh, shiny.
<mjg59> Where "Thinkpad X41" is "Any machine with i915/i945"
<tfheen> have you gotten ilm to verify it?
<mjg59> I can reproduce here
<tfheen> ok, coolie.
<tfheen> can we have a second verification that it's fixed?
<mjg59> Fix makes sense, but is in acpi-support rather than xserver-xorg-video-i810
<mjg59> Uh. I can test the fix on a second machine? :)
<Kamion> tfheen: I'm just looking at that ktorrent FTBFS before firefox
<tfheen> mjg59: what's the fix?
<tfheen> Kamion: the ppc one which didn't make sense to either Adam or me?
<mjg59> tfheen: Explicitly set the screen back to text mode on resume before switching back to X
<Kamion> tfheen: oh, was it *that* one?
<mjg59> Since the vbestate saved is from a graphical mode now (due to usplash)
<tfheen> Kamion: I think so, yes.
<Kamion> hadn't realised it was the same bug
<Kamion> is Adam still on top of it?
<tfheen> I think he's horisontal in bed, so I assume not.
<Kamion> I'll have a go, then
<tfheen> infinity: ^^ around and is the ktorrent build failure the crackful build failure we talked about on Friday?
<tfheen> it's ppc specific, isn't it?
<Kamion> the suggested patch indicates the same thing
<Kamion> yes
<tfheen> mjg59: if you can test it on a second machine and then upload, please do.  It sounds sensible.
<Kamion> tfheen: oh, the patch is hateful and patches configure
<Kamion> no wonder
<Kamion> probably need to hunt-and-destroy the .m4 that contains it
<mjg59> tfheen: Tested on another machine
<tfheen> mjg59: go for it
<mjg59> tfheen: Do you need anything in the changelog?
<tfheen> mjg59: nothing apart from documenting the change; Kamion or Adam will ask me about it in a bit.
<mjg59> Ok
<tfheen> (and I'll tell them that the change is approved)
<mjg59> Cool
<mjg59> Uploading
<tfheen> cheers.
<tfheen> did you have any luck with usplash on amd64 or are you going with the vga16 route there?
<mjg59> About to hit that now
<mjg59> (Yesterday was a bit of a loss. Never drinking again)
<tfheen> heh
<tfheen> at least not until Wednesday?
<mjg59> Especially not with freshers
<mjg59> Eh. Maybe tomorrow.
<keescook> what's the issue with usplash on amd64?  I'd like to help if possible...
<mjg59> keescook: x86emu and nvidia bioses don't get along
<tfheen> keescook: blows up with nvidia cards.
<keescook> sounds like my config.  :)
<tfheen> mjg59: do you have the debdiff for the acpi-support somewhere?
<keescook> usplash needs a vga= line, yes?
<mjg59> tfheen: This stuff /works/ in X, so the current plan of attack is to get a better idea of what X is doing
<mjg59> keescook: No
<hash_> Kamion: Is there anything else I need to do or any info that you need?
<tfheen> mjg59: given that it works once in a while, I'm wondering if there are some data structures not cleared properly or something.
<mjg59> tfheen: http://www.codon.org.uk/~mjg59/acpi-support.debdiff
<keescook> mjg59: okay.  would 'usplash -c' be one way to test fixes?
<mjg59> vgamode rather than vbemode is deliberate
<tfheen> mjg59: 404
<mjg59> keescook: Yeah
<mjg59> tfheen: http://www.codon.org.uk/~mjg59/tmp/acpi-support.debdiff
<tfheen> thanks
<keescook> mjg59: okay, cool.  usplash for me just changes the brightness, and doesn't display any graphics.  is there anything I can do to help debug?
<mjg59> keescook: Other than figuring out the bug, I doubt it
<tfheen> keescook: does vbetool vbestate save SIGSEGV for you?
<keescook> tfheen: checking
<keescook> tfheen: yup, sure does.
<mjg59> Yeah, that's the simple csae of the problem
<tfheen> that bit is trivially solved.
<mjg59> tfheen: That doesn't mean it works though, right?
<tfheen> mjg59: no, it means it runs into the infinite loop problem.
<keescook> there is a bug # for the usplash junk so I can get up to speed on it?
<tfheen> keescook: ok, if you grab the source for vbetool, change a few defines at the top of x86-common.c, it should loop forever.
<tfheen> #define REAL_MEM_BASE ((void *)0x1000)
<tfheen> #define REAL_MEM_SIZE 0x80000
<tfheen> are the defines you want.
<tfheen> #define REAL_MEM_BLOCKS (REAL_MEM_SIZE/1024)
<tfheen> that'll make it not segfault
<keescook> usplash pours stuff to the screen (e.g. Calling INT 0x0 (0004:003E), EAX is 5100, Leaving interrupt call. over and over)
<tfheen> usplash sometimes work, so vbetool is really a better test.
<keescook> okay
<tfheen> since it consistently fails (for me at least)
<tfheen> you can make the same change to usplash and it should loop forever unless you neighbour's cat is red and the moon is waning and your grandfather is brushing his teeth when you run it.
<keescook> dunno if it helps, but I've never had usplash work yet on this machine.  :)
<tfheen> not even in dapper?
<tfheen> or haven't you had dapper on it?
<keescook> wrt REAL_MEM_SIZE, that should change from 0x40000 to 0x80000?
<tfheen> yeah.
<keescook> I had it disabled in dapper.  :P
<Kamion> hash_: no, thanks
<tfheen> the size isn't that important, but ISTR I ran into some bugs when I didn't bump it.
<hash_> Kamion: thanks for the info and help, cya later
<keescook> tfheen: after those changes, mine still segfaults...
<keescook> er, nm, missed MEM_BASE change.  agh
<keescook> yes, now it loops forever.  :)
<sladen> I was looking at the i810 issue earlier (i810switch prove)
<sladen> i810switch probe
<Kamion> tfheen: ... y'know, Adam can keep ktorrent
<Kamion> I've hit my "way too horrible" barrier
<tfheen> keescook: ok, that's about where I've gotten to.  Enjoy your debugging session.
<keescook> tfheen: looks like the save_state function just reports errors instead of quitting out.  :P  so it plows ahead even those the very first call fails.  :P
<tfheen> keescook: that's, AIUI, normal.
<tfheen> keescook: also, the VESA initialisation shouldn't fail either.
<keescook> tfheen: heh.  oh.  okay.  :P
<keescook> the save_state function seems to really depend on the size returned, though.  ?
<tfheen> Kamion: heh.  We really want it fixed before release, though.
<tfheen> keescook: yes, the bug is probably somewhere in x86emu.
<Kamion> tfheen: too horrible for a Sunday evening, anyway
<tfheen> Kamion: yeah, understandable. I'm saved by not having anything resembling a usable ppc.
<Kamion> oh, damn, hash_ left
<Kamion> I can't seem to reproduce that problem; the only problem with the URL he gave was that I need to set the character encoding manually
<Kamion> unmarked as RC
<fabbione> siretart: i am only mass-filing bugs.. i don't check all the failures in details. whatever it is.. something is broken and need fixing
<tfheen> Kamion: ok.
<geser> can someone review the debdiff for bug 66212 and upload it?
<Ubugtu> Malone bug 66212 in wpasupplicant "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/66212
<Kamion> tfheen: what should be done with the two bugs currently targetted at ubuntu-6.10-beta?
<Kamion> bug 63823, bug 63975
<Ubugtu> Malone bug 63823 in update-manager "Edgy : Randomn crash on quit" [Medium,Needs info]  http://launchpad.net/bugs/63823
<Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
<Kamion> I presume they should be retargetted at ubuntu-6.10 and checked
<tfheen> yes, they should be retargetted.  They weren't 6.10-beta-targetted when beta released.
<Kamion> tfheen: done
<tfheen> Kamion: thanks.
<Kamion>   109625 | S- | speedcrunch          | 0.7~060412-0ubuntu5  | 44 minutes
<Kamion>          | * speedcrunch/0.7~060412-0ubuntu5 Component: main Section: kde
<Kamion>   109623 | S- | acpi-support         | 0.90                 | 54 minutes
<Kamion>          | * acpi-support/0.90 Component: main Section: admin
<tfheen> Kamion: acpi-support is approved.
<Kamion> tfheen: speedcrunch is removing build-dep on libqt4-debug-dev (NBS); acpi-support is mjg59's vbetool vgamode set 3
* Kamion -> dinner
<tfheen> Kamion: ok, speedcrunch approved too, then.  Who uploaded it?
<Kamion> Riddel
<Kamion> l
<tfheen> Kamion: ok, thanks.
<tfheen> Riddell: again, please, please tell me about uploads you make rather than leaving me to work them out by myself.
<hash_> kamion: when you tested firefox with the patch what were the contents of /var/lib/locales/supported.d
<tfheen> hash_: he went to dinner, but he'll probably be back in a bit, if I know him correctly.
<hash_> tfheen: Hi, would you be able to check the rendering?
<tfheen> hash_: no, sorry, I'm deep into some other hacking.
<hash_> tfheen: no probs.
<shining> doko__: ping
<sivang> tfheen: so *any* upload needs to be in advance notified to you? (I have some hubackup fixes I'd like to push before release)
<sivang> tfheen: (hubackup is in universe)
<tfheen> sivang: if it's in main, preferably.
<tfheen> sivang: if it's in universe, I ignore it anyway.
<tfheen> it won't go onto the CDs, etc, etc so talk to dholbach.
<sivang> ah, okay cool
<Kamion> $ cat /var/lib/locales/supported.d/si
<Kamion> si_LK UTF-8
<Kamion> hash_: ^--
<Kamion> (I installed language-pack-si first)
<hash_> Kamion: here's a screenshot: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/sinhala/patches/icu-sinhala-rendering.png?root=sinhala
<hash_> Kamion: Is that how it rendered?
<Kamion> hash_: yep
<hash_> Kamion: can you please do: ls /var/lib/locales/supported.d
<Kamion> it looked correct to me; I don't speak Sinhala, but it didn't look like "formatting characters" either
<Kamion> is that .png an image of correct rendering or incorrect rendering?
<Kamion> $ ls /var/lib/locales/supported.d
<Kamion> en  local  si
<hash_> correct rendering
<Kamion> oh, I have LANGUAGE set
<hash_> In firefox it won't look like formatting characters. It just doesn't reorder the glyphs correctly.
<Kamion> doesn't seem to matter though
<Kamion> oh. want me to get screenshots to compare?
<hash_> run: MOZ_DISABLE_PANGO=0 firefox
<hash_> is the rendering different to the screenshot?
<Kamion> hash_: sorry, I'm not quite sure what you're trying to get at here - the rendering looked *correct* to me even without the patch
<hash_> Kamion: Pango is currently on enabled if bn|gu|hi|kn|ml|mr|ne|pa|ta|te these locals are there.
<Kamion> I'm using http://people.ubuntu.com/~cjwatson/tmp/icu-sinhala-rendering.txt to avoid having to set the character encoding manually
<Kamion> hash_: yes, I understand that and I changed /usr/bin/firefox temporarily for testing
<Kamion> in order to confidently apply your patch and push it through for RC, I need to be able to see a difference in firefox with and without that patch
<hash_> Kamion: I'm trying to work out how Pango is getting enabled without the patch on your system. Any ideas?
<Kamion> oh, right, I see what you mean now
<hash_> That's why I asked for an ls of /var/lib/locales/supported.d
<Kamion> hash_: I ran firefox under 'bash -x'; it's definitely setting MOZ_DISABLE_PANGO=1
<hash_> with the patch?
<Kamion> hash_: no
<Kamion> + egrep '^(bn|gu|hi|kn|ml|mr|ne|pa|ta|te)_' /var/lib/locales/supported.d/en /var/lib/locales/supported.d/local /var/lib/locales/supported.d/si
<tfheen> hash_: Kamion needs to be able to see what's wrong, then that it's fixed by the patch.  Without that, we won't apply the patch.
<Kamion> + MOZ_DISABLE_PANGO=1
<Kamion> + export MOZ_DISABLE_PANGO
<Kamion> (you confused me by asking for an ls of /var/lib/locales/supported.d - firefox doesn't care about the filenames, it cares about the contents)
<hash_> I just needed to know what files where there.
<Kamion> you needed to know their contents, actually
<hash_> Kamion: could you take a screenshot and put it on the web?
<Kamion> but in any case none of those languages are there
<hash_> You can work out the latter from the former
<Kamion> hash_: http://people.ubuntu.com/~cjwatson/tmp/sinhala-unpatched.png
<Kamion> hash_: no, you really can't - the contents of /var/lib/locales/supported.d/local can't be determined from the filename
<Kamion> if you don't believe me, tell me what's in there :-)
<hash_> so that's incorrect rendering
<Kamion> ok
<Kamion> what's incorrect about it? (I believe you, just trying to understand so I can compare)
<hash_> incorrect: the dependent vowel modifiers succeed the consonants always.
<hash_> correct: some of the dependent vowel modifiers precede the consonants.
<slomo> tfheen: are uploads to main for fairly trivial bugfixes still allowed? i uploaded a libnotify with some small patches ~2 weeks ago but forgot to add simple patchsystem to debian/rules :/ bug #63335 and the duplicate is about it
<Ubugtu> Malone bug 63335 in libnotify "patches in debian/patches are not applied" [Medium,Confirmed]  http://launchpad.net/bugs/63335
<Kamion> ah, I see
<Kamion> ok, it was clearer once I actually compared them side by side
<Kamion> and wasn't expecting there to be Unicode replacement characters or something in there
<Kamion> hash_: does http://people.ubuntu.com/~cjwatson/tmp/sinhala-patched.png look right, then?
<hash_> please have a careful look at rows 11 to 16.
<hash_> Kamion: yes! :-)
<hash_> compare rows 11 to 16 of the two.
<tfheen> slomo: no, sorry.
<Kamion> yep, I see, and the bits around the bottom of the characters on rows 8 and 9 are different too
<slomo> tfheen: ok, np
<hash_> yep.
<Kamion> hash_: ok, thanks a lot, sorry for giving you the run-around on that
<tfheen> slomo: we're just too close to release.
<hash_> that's ok, it's not the first time and it won't be the last. ;-)
<Kamion> you need to invent less subtle rendering bugs ;-)
<hash_> hehe. when it comes to i18n, it usually takes a little while to convince maintainers.
<hash_> So relatively speaking, this has been one of the quickest positive responses I have had in 3 years! :-)
<tfheen> hash_: it's more that most of us are western-language people who are (unfortunately) ignorant of a lot of the issues affecting non-latin languages.  Even those of us who have gone through this a couple of times for different languages stumble across new problems for new languages.
<Kamion> now all I need is enough disk space to build a firefox source package
<tfheen> Kamion: do it on a porter box?
<Kamion> yeah, I've done lots of i18n work in the past for various languages - it's usually more obvious when stuff breaks :)
<Kamion> tfheen: if I have to, yeah. I think I'm not far short so I'll just zap a few things.
<giskard> Kamion: do you need diff, dsc of NM?
<Kamion> hoary and breezy chroots can go
<Kamion> giskard: nothing to do with me - I was just changing the bug targets since the 6.10 beta is out
<tfheen> doing installations in languages you have no idea about and debugging problems in those is.. interesting.
<giskard> Kamion: ah! ok :)
<tfheen> like me fixing korean support for dapper.
<hash_> do you guys have access to native speakers, so that you can ask?
<tfheen> hash_: sometimes.
<tfheen> depends on the language and such.
<Kamion> hash_: mostly via helpful folks like you
<Kamion> we have some spread of languages on the Canonical staff but it's obviously far from complete
<hash_> There's Sri Lanka Ubuntu team. I assume other countries have such teams too.
<Kamion> the community's big enough now that it's getting easier
<Kamion> often, though, the latency involved is such that if you have the broken system in front of you it can be easier to guess
<tfheen> Sinhala is a Sri Lankan language?
<hash_> BTW, is rendering of Latin based character sets in firefox *without* bug that much quicker than *with* Pango?
<tfheen> hash_: yes.
<Kamion> tfheen: we did this earlier :-)
<Kamion> 17:47 < tfheen> Kamion: the change looks innocent enough; I have no idea whether it's needed for Sinhalese, though, given that even with the name I'm not sure where it's spoken.
<Kamion> 17:47 < mdke_> sri lanka
<hash_> Yeah Sinhala is the main language of Sri Lanka
<Kamion> hash_: yes - disabling Pango dealt with a *lot* of complaintss
<tfheen> Kamion: ah, ok.  I didn't see mdke_'s reply.
<Kamion> -s
<tfheen> Pango is horribly, horribly slow.
<Kamion> the complaints were mostly of the form "I tried upstream's binaries and they were an order of magnitude faster. You guys suck"
<hash_> Because Fedora Core and Debian use Pango by default.
<tfheen> if it would grow optimisations for ascii/latin languages, I wouldn't mind, really.  Unsure how easy that is to do, though.
<Kamion> yes, Debian gets the complaints too
<Kamion> don't know about Fedora, as I'm not active in that community
<hash_> I actually use Debian, and was using Fedora before.
<hash_> But Majority of new Linux uses in SL use Ubuntu.
<Kamion> Debian doesn't have the MOZ_DISABLE_PANGO optimisation
<hash_> This particular problem was discovered in July: http://sinhala.linux.lk/enabling-pango-in-firefox-to-enable-sinhala
<Kamion> so they don't run into the sort of problem you did here, but they also still get the slowness complaints
<hash_> But I didn't get around to addressing it till now. Deadlines do wonders! hehe
<Kamion> tell us about it ;-)
<hash_> 0h yeah, sorry, completely forgot!
<tfheen> hash_: usually, we appreciate if people do get around to telling us about those kinds of problems a bit earlier.  To put it this way; I wouldn't have accepted the update tomorrow.
* pygi tells Kamion about deadlines :P
<pygi> Kamion: tell me more about hfs and hfs+ deadlines =)
<hash_> tfheen: wow, that was a little too close then, lucky I stayed up - it's now 5:37am (AUS)
<tfheen> hash_: and lucky that I felt like looking at IRC today.  It's sunday here and I'm supposedly not working.
<hash_> tfheen: much appreciated!
<hash_> is the 16th some kind of deadline?
<Kamion> hash_: we're releasing Thursday week
<Kamion> this coming Thursday is release candidate, so we lock down for everything non-essential a little before that
<tfheen> the images which are done in ~12 hours are hopefully the release candidate image.
<tfheen> +s
<ajmitch> Kamion: universe continues as normal?
<Kamion> tfheen: with 40+ RC bugs, mind you ...
<Kamion> ajmitch: for a bit, yeah, but don't push it :)
<tfheen> (ok, I don't really believe that, but at that point I'm going to really start rejecting uploads and removing milestones)
<Kamion> (for your own sakes)
<tfheen> ajmitch: requires approval, but yes.
<Kamion> ajmitch: speaking of which, unapproved has telepathy-python 0.13.3-0ubuntu2 and xen-3.0 3.0.3~rc5-0ubuntu1
<ajmitch> I don't plan to leave it right to the last minute, but we haven't had many fixes uploaded this last week
<ajmitch> I'm happy with xen-3.0, of course. who did telepathy-python?
<tfheen> Kamion: 40+ RC bugs > pft, they'll all be gone tomorrow morning.  *cough*
<Kamion> hash_: ok, new firefox is building and should be in the archive in a few hours
<Kamion> +telepathy-python (0.13.3-0ubuntu2) edgy; urgency=low
<Kamion> +
<Kamion> +  * Really dropped:
<Kamion> +    debian/patches/01-from-darcs_update-to-new-manager-format.patch
<Kamion> +
<Kamion> + -- Riccardo Setti <giskard@ubuntu.com>  Sun, 15 Oct 2006 17:08:57 +0000
<ajmitch> heh, ok
<ajmitch> put it through
<hash_> Kamion: Thanks again and good night
<Kamion> ok, accepted
<Kamion> hash_: no worries, it's my job ...
<giskard> Kamion: ajmitch thank you
<ajmitch> the rest of us just do it for fun :)
* Kamion removes language-pack-si-base again so his browser will go back to normal speed. :)
<hash_> tfheen: thanks and if you need any Indic or Unicode help in general just contact Sri Lanka local team and they'll contact me
<tfheen> hash_: coolie, thanks.
<Kamion> oh, DAMN, that reminds me
<tfheen> I'll try to remember. :-)
<Kamion> I was supposed to remove Dzongkha and Khmer support from ubiquity for now due to lack of fonts and translations
<hash_> Kamion: Changelong: "Disable Pango if a Sinhala locale is present." You meant Enable right?
<Kamion> hash_: yes, I did, whoops
<Kamion> sorry about that
<tfheen> hash_: the switch is the wrong way around, it should really have been named _ENABLE_PANGO, not DISABLE_TANGO.  IMO, at least.
<Kamion> I added it to that list, anyway, as per your patch
<tfheen> s/TANGO/PANGO/
<hash_> tfheen: true, not sure why it was done this way around
<hash_> tfheen: my guess those would be that there was a lot of demand for *disabling* Pango at the time and hence the usage of _DISABLE_.
<tfheen> yeah, I guess.
<hash_> tfheen: BTW when does the next sync with Debian unstable occur?
<sivang> when edgy+1 opens, AFAICR no?
<hash_> sivang: when's that?
<tfheen> hash_: when edgy+1 opens, so in about two weeks.
<Kamion> plus next release setup and get-round-to-it time
<Kamion> add another week or two in practice
<Kamion> we need to bootstrap the new toolchain first
<Kamion> that's being prepared already, so I hope it won't take too long
<sivang> right
<sivang> this soyuz responsibility? (new toolchain)
<hash_> Ok thanks, will try to get any other changes into Debian before then.
<hash_> or upstream.
<Kamion> we'll be syncing on an almost-daily basis for a couple of months after that
<Kamion> at least for automatic syncs (no Ubuntu changes)
<sivang> Kamion: this is going to be regular cycle time this round right?
<sivang> (we've caught up after the dapper delay by now)
<hash_> Kamion: brilliant, *months* is good.
<Kamion> sivang: yes, I expect so
<Kamion> hmm, bug 66214 seems RC if true
<Ubugtu> Malone bug 66214 in tasksel "Installation of daily build 10/14 fails" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66214
<tfheen> Kamion: targetted
<Kamion> I see what might be causing that. Hmm. Hmm.
<Kamion> aptitude doesn't fail if the task is missing. apt-get does ...
<tfheen> ouch.
<tfheen> well, your cour.
<tfheen> +t
<Kamion> the fix might be to drop the stupid derivative-specific *-standard tasks and replace them with a single standard task
<Kamion> since they're all the same anyway
<Kamion> at least one good thing is that I don't need to change bits of Launchpad any more to do this kind of thing
<Kamion> ok, going to do that, it's the sane answer
<Kamion> tfheen: will be a seed change plus a tasksel chang
<Kamion> e
<tfheen> Kamion: big ones?
<Kamion> nah
<Kamion> -# Only per-derivative for historical reasons because the archive already has
<Kamion> -# ubuntu-standard etc. We should fix this, since it's never really been
<Kamion> plus automatic refresh of tasksel
<Kamion> -# sensible for standard to be per-derivative.
<Kamion> -Task-Per-Derivative: 1
<Kamion> that will collapse the *-standard tasks down into a single standard task; as far as I can see and remember, only tasksel internals know about the standard task now
<tfheen> it won't blow up upgrades?
<Kamion> upgrades don't (yet) know about tasks at all
<Kamion> the ubuntu-standard metapackage will stay the same
<tfheen> oh, and we didn't use to have xubuntu-standard and kubuntu-standard langpacks?
<Kamion> YM metapackages?
<tfheen> yes, sorry.
<tfheen> my brain is obviously confused.
<Kamion> no, and it wouldn't matter anyway, the diff above only affects tasks not metapackages
<tfheen> this'll be a fun last bit of a cycle.
<tfheen> ok, coolio
<shawarma> Does anyone know why user-mode-linux is not in edgy?
<shawarma> Kamion: You usually know this kind of thing, don't you?
<Kamion> shawarma: was removed ages ago IIRC; I think (a) it had been removed from Debian at the time and (b) we didn't have the time to keep it up to date with our kernel
<Kamion> I see it's back in Debian now, but we certainly won't import it again for Edgy now
<shawarma> Kamion: Well, it's a universe thing anyway, so I'm just curious why it never showed up in MoM..
<Kamion> might've been blacklisted
<Kamion> removed packages sometimes are
<shawarma> Kamion: Oh. 
<Kamion> yeah, apparently was
<Kamion> http://people.ubuntu.com/~cjwatson/sync-blacklist.txt
<shawarma> Kamion: I just fell over an e-mail to ubuntu-devel ml from late in the Dapper cycle asking where it went and now I discover that it's still gone. :-)
<Kamion> I don't seem to have access to jackass any more to get at the pre-Soyuz removal log
<shawarma> Kamion: Any reason why it couldn't be un-blacklisted now?
<shawarma> jackass?
<Kamion> shawarma: old ftp-master machine
<shawarma> Kamion: oh.
<Kamion> I dunno, it still falls over the "we do our own kernel" criterion
<shawarma> Kamion: How so? We make our own versions of a lot of other stuff as well and we handle the "problems" that arise from that.
<Kamion> ah, at the time I think it was still on 2.4
<shawarma> oh dear.
<Kamion> shawarma: kernel stuff's tricky, because we want to keep the amount of rebuilding we have to do for security updates as low as possibl
<shawarma> Well, uml definitely works on 2.6 now.
<Kamion> e
<Kamion> and user-mode-linux is yet another package that would have to be rebuilt each time
<shawarma> Kamion: Even if it was in universe?
<Kamion> shawarma: I'd rather you talked to Ben Collins about this to see if you can work out a good solution
<Kamion> shawarma: yes
<Kamion> we removed all the kernel patches, similarly
<Kamion> in Ubuntu, as much as possible goes into the mainline kernel
<Kamion> any variations from that must be cleared with the kernel team
<Kamion> because they're the ones who'll have to deal with the fallout if somebody isn't around to update dependent packages
<shawarma> Kamion: Which patches were removed? I have a load of kernel-patch-* packages in my apt-cache?
<Kamion> they *were* removed - some might have sneaked back in
<Kamion> I don't care to go and investigate at the moment because I'm fixing multiple RC-targetted bugs
<shawarma> Kamion: Ah, ok.
<Kamion> since this is all post-Edgy anyway, I'd rather defer any investigation until later
<shawarma> Kamion: That's fine. I'll take it up with BenC at some point.
<shawarma> Kamion: Thanks for your time.
<Kamion> it's all got his name attached in the sync blacklist
<Kamion> which means he's the go-to person for any changes :)
<Kamion> no problem
<mikael_> hi there. i am trying to compile a package from its sourrce
<mikael_> i just grabbed it via svn
<mikael_> but no howto (on ubuntu.com) could help me
<mikael_> i am using kubuntu 6.06
<mikael_> and i have already apt the build-essential packages
<mikael_> ./configure; ./make; ./make install won't lead me to a positive result
<mikael_> maybe one has an idea?
<mikael_> this is the page i grabbed it from:  http://www.willwap.co.uk/Programs/vbrfix.php#DL
<mjg59> Woo
<mjg59> Well, got usplash into a state where it oopses the kernel
<tfheen> mjg59: I'm not sure I'd characterise that as progress..
<tfheen> though, it's different.
<mjg59> tfheen: The mmapping of the interrupt vectors can never work
<mjg59> It's behaving as though they'll be mmaped to 0, which is just not going to happen
<mjg59> tfheen: Hacking with that in vbetool seems to have changed how things behave, anyway. Not sure that it's /working/ yet, but still
<tfheen> mjg59: won't it just have to be mmapped to the real_base?
<mjg59> Yes
<mjg59> But what's currently happening seems to be that they get mapped to 0x1000
<mjg59> Which is then likely to result in things not working
<mjg59> (surely?)
<tfheen> that's weird, give we map it with MAP_FIXED.
<tfheen> sure you're not looking at the first mmap call?
<mjg59> Yes
<mjg59> The manpage for mmap says that it will never return 0
<mjg59>       m = mmap((void *)0, 0x502,
<mjg59> (etc)
<tfheen> RETURN VALUE On success, mmap() returns a pointer to the mapped area.  On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is  set  appropriately. 
<mjg59> "The actual place  where  the object is mapped is returned by mmap(), and is never 0."
<tfheen> hmm, ok.
<tfheen> I guess we should really pick some other mem_base, then?
<mjg59> Yeah
<tfheen> but does that fix the problem or just create a new problem?
<tfheen> and how this did ever work?
<mjg59> No idea
<mjg59> Hrm.
<mjg59> Why is it now exiting with a return code of 3?
<sivang> laters all
<sivang> (or good night)
<mjg59> Oh, argh.
<mjg59> tfheen: This turns out to be difficult, for subtle reasons
<mjg59> Though I may have an idea
<tfheen> what subtle reasons?
<mjg59> alloc_real needs to return a pointer that refers to mapped memory
<mjg59> But that then gets passed in as an argument and used as an offset from mem_base
<tfheen> can't mem_base be subtracted from it?
<tfheen> hmm
<mjg59> Not without breaking compatibility with lrmi
<mjg59> And having to change every call made
<tfheen> that's a point.
<mjg59> So, what we could do is just mmap it twice?
<mjg59> Once to the absolute range and once to the relative range?
<tfheen> are there that many calls which use memory returned from alloc_real?
<mjg59> Yes
<tfheen> ok
<tfheen> we could do really, really evil tricks.
<tfheen> like, look at the pointer, and if it's bigger than 10MB treat it as an absolute pointer, if not treat it as a relative pointer.
* _ion shivers.
<_ion> ;-)
<mjg59> tfheen: Dude. So no.
<mjg59> tfheen: We can mmap things twice, right?
<tfheen> mjg59: sure, that's easy.
<tfheen> but will it work?
<mdeslaur> What's the process to get a patch added to gnomebaker in edgy/dapper backports?
<pygi> mdeslaur: I dont think you can add a patch to backports
<mdeslaur> pygi- ok, how about getting it added to edgy?
<pygi> mdeslaur: that's also a no go for now
<pygi> once edgy is released, it may go to -updates tho
<pygi> mdeslaur: have you submited it upstream? 
<mdeslaur> pygi: yes, it's in gnomebaker cvs
<pygi> mdeslaur: oh, what does it fix? I'll talk to Luke Biddell to see how important that is
<mdeslaur> pygi: gnomebaker 0.6 is seriously broken for people with a cd-reader and a cd-writer
<mdeslaur> pygi- when you try to burn to a cd/dvd writer, it miscaculates and tries to burn to the wrong device
<pygi> mdeslaur: could I see the diff pls?
<mjg59> tfheen: Ehm. Well, it fails differently...
<pygi> mdeslaur: ah, I know about that problem
<pygi> mdeslaur: diff pls
<mdeslaur> pygi: http://sourceforge.net/tracker/index.php?func=detail&aid=1576272&group_id=127397&atid=708501
<Ubugtu> Sourceforge bug 1576272 "Patch to fix bug #1522258" [Pri: 5,Closed accepted]  
<mjg59> tfheen: Now it blows up in X86EMU_setupPioFuncs
* mjg59 boggles gently
<pygi> mdeslaur: sec pls
<tfheen> that's a fairly trivial function; how does it blow up?
<doko_> infinity: awake?
<pygi> mdeslaur: the diff seems sane
<pygi> mdeslaur: I don't think we'll change anything at this point, but if you file a bug and assign it to me I think it'll get in -updates
<mdeslaur> pygi: ok, launchpad #63805. How do I assign it to you?
<pygi> bug #63805
<Ubugtu> Malone bug 63805 in gnomebaker "Gnomebaker 0.6 not recognizes my CD-RW" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63805
<tfheen> doko_: if you need a give-back or similar buildd admin tasks, I'm still awake.
<pygi> mdeslaur: done, I'm assigned
<mjg59> tfheen: So I've got it into a state where I think it ought to work, but instead it's failing in a bizarre manner
<doko_> tfheen: just OOo uploads which should build on palmer to not disturb other things
<pygi> mdeslaur: thanks for notification :)
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/tasksel.diff FYI
<mdeslaur> pygi- once it's in edgy-updates, it can go in dapper-backports?
<pygi> mdeslaur: I could rebuild the package with patch if you want, so you could get it from my site
<pygi> mdeslaur: uh, I can't promise anything, but I can try
<pygi> I'm not sure on our backports policy
<mdeslaur> thanks pygi
<Kamion> mdeslaur: yes, assuming it builds cleanly on dapper
<tfheen> Kamion: ok, looks good
<pygi> Kamion: patch is trivial, I don't see any problems why it shouldn't
<mdeslaur> Kamion: dapper had a working gnombaker 0.52 and dapper-backports has a broken gnomebaker 0.6
<tfheen> Kamion: (approved)
<pygi> (broken in sense of that patch)
<pygi> mdeslaur: luke should just do point releases more often
<mdeslaur> yes :)
<Kamion> pygi: if you're really confident in it, and the problem is that serious, then edgy/universe is still somewhat open
<tfheen> doko_: infinity told me how to do that, but I'm not sure I remember right now, so I'll leave it.
<pygi> Kamion: oh, really? Would be very nice to get it in then. This way gnomebaker is broken if you have more then 1 drive
<Kamion> um, OOo needs to build ASAP though?
<doko_> tfheen: ok, I'll upload then before I go to bed, and send an email to infinity and you
<Kamion> assuming that's OOo proper
<tfheen> doko_: thanks.
<doko_> Kamion: why?
<tfheen> doko_: because it should be built before we start building candidate ISOs tomorrow morning.
<doko_> hmm, ok. but then I would need palmer now ... to have it built in 6.5h ...
<tfheen> is it accepted yet?
<mjg59> tfheen: Hrm. Where does the stack usually end up?
<pygi> Kamion: if it's not a problem it's: http://librarian.launchpad.net/4820538/gnomebaker-0.6.0-device.patch
<pygi> Kamion: but if it makes any trouble for you, dont bother
<doko_> no, test build is still in it's install stage ...
<tfheen> mjg59: hmm, I can't really remmeber.  0x1000 maybe?
<Kamion> tfheen: only thing in unapproved is xorg-server. what are we going to do about that, BTW? just accept it on the grounds that we should get something in
<Kamion> pygi: er, sorry if I unintentionally misled you, but I didn't mean to suggest that I was going to take care of it
<Kamion> pygi: a MOTU who uses gnomebaker should do it
<doko_> -l10n will need another hour or so
<tfheen> Kamion: the problem with it is that it patches debian/local from debian/patches?
<Kamion> tfheen: yees
<Kamion> yes
<tfheen> Kamion: what's the changelog?
<pygi> Kamion: ok, as long as universe is open 
<adamh> What package holds /usr/lib/python2.5/pstats.py?
<adamh> I tried python-profiler but it only works for python2.4.
<Chipzz> adamh: this is not a support channel
<Chipzz> adamh: try packages.ubuntu.com
<adamh> Chipzz: I'm a deloper... this is a developer support channel, isn't it?
<Chipzz> no it is not
<Kamion> this is for development of Ubuntu, not development on Ubuntu
<Chipzz> it is a channel about developing ubuntu, not developing *with* ubuntu
<adamh> Ah, good point. Okay, let me rephrase: "I think there's no package that holds /usr/lib/python2.5/pstats.py -- is this a known bug?"
<mjg59> tfheen: Ok, a little further. Moving REAL_MEM_BASE seems to have helped
<tfheen> mjg59: hmm, ok.
<Chipzz> speaking of which, packages.ubuntu.com seems a bit out-of-date
<tfheen> mjg59: I have to go to bed now, but I'll be happy to be useful for you tomorrow.
<mjg59> tfheen: In that I don't seem to be scribbling over the stack any more, at least
<mjg59> tfheen: Ok
<tfheen> mjg59: yay, good.
<Kamion> tfheen: /usr/lib/python2.5/pstats.py
<Kamion> err
<mjg59> Now I'm just left with it segfaulting for no obvious reason
<Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/xorg-server.diff
<Kamion> Chipzz: known, the Soyuz guys need to do a Contents generation run
<Kamion> it'll be done before release, probably just before
<tfheen> Kamion: approve it; the patching of debian/local is wrong and slightly crackful, but should work just fine.
<shining> adamh: try apt-file
<tfheen> Kamion: unless you have serious complaints?
<Chipzz> Kamion: that doesn't get run automagically?
<adamh> shining: Ooh wow, never heard of that :). Thanks :)
<Kamion> Chipzz: not at present, unfortunately
<Chipzz> shining: packages.ubuntu.com does the same as apt-file
<Kamion> shining: apt-file is out of date for the same reason packages.ubuntu.com is
<Chipzz> adamh: don't use it
<shining> Kamion: ah really? didn't know that
<Kamion> adamh: I think python-profiler just hasn't been rebuilt to add python2.5 yet
<Kamion> doko_: ?
<Chipzz> you'll pull in a whole shitload of packages when installing it, and packages.ubuntu.com provides exactly the same functionality
<Kamion> tfheen: ok, done
<tfheen> Kamion: thanks.  Good night.
<tfheen> see you in 8-9-ish hours.
<Kamion> Chipzz: "don't use it" is a bit strong I think
* adamh prefers the command-line interface, really...
<Chipzz> Kamion: well, for one-time use he is better of using the website
<Kamion> and "Depends: perl, gzip (>= 1.2.4), libconfigfile-perl, libapt-pkg-perl, wget" is hardly "a whole shitload"
<Kamion> Chipzz: who are you to say it's one-time?
<shining> apt-file and packages.ubuntu.com use both the same source, which is outdated?
<Chipzz> Kamion: if you use it on a regular base, installing apt-file may be more usefull
<Kamion> shining: correct
<adamh> hehe, too late, I'm already done :P
<Kamion> shining: it'll be sorted out before release
<Chipzz> Kamion: just a hunch, since he didn't even know it existed in the first place
<Kamion> Chipzz: remind me never to suggest any new and potentially useful tool to you
<Kamion> you must know about them all already
<Kamion> tfheen: sleep well
<Kamion> doko_: also a bit odd that python-profiler only has a python2.4 module but Depends: python (<< 2.6), python (>= 2.4)
<Chipzz> hrrm last time I considered installing it it pulled in more packages than that... must have installed some perl-packages since then
<adamh> Kamion: Yeah, I noticed that
<Toadstool> Kamion: hi, pygi asked me to upload the fix for gnomebaker. I just want to make sure that this ok for me to upload it. Just reviewed the patch, it's an upstream patch and it looks sane
<Kamion> libconfigfile-perl and libapt-pkg-perl have no further perl module dependencies
<Kamion> Toadstool: yes, although at this point in the freeze you should also be testing (or getting somebody else to test) it as well
#ubuntu-devel 2007-10-08
<LaserJock> is there an RM about?
<jason> hello i was wondering if any of you people program in C++
<ikonia> most of the applications in ubuntu are written in c++, so mosst of the developers can
<ikonia> jason: as I mentioned in the other channel
<Amaranth> mjg59: ack, sorry
<LaserJock> ikonia: most?
<Amaranth> mjg59: yeah using nvidia but it happens if i blacklist the nvidia driver too
<LaserJock> ikonia: if you include C I think I would agree, but I'm not sure about C++ specifically ;-)
<jason> ok i wanted to learn C++ for linux and ive been having a harder time googling for specific real world examples
<ikonia> LaserJock: couple of pythons slip thorugh the net ;)
<LaserJock> heh
<jason> any help pointing me in the right direction would be great
<ikonia> jason if you can't find any resources to learn c or examples, then your not going to have the aptidue to learn c
<LaserJock> jason: actually sourceforge I believe lets you filter projects by language
<Amaranth> ikonia: almost zero apps in ubuntu are written in C++
<Amaranth> well, in the default desktop, anyway
<ikonia> Amaranth: C yes, apologies
<LaserJock> Amaranth: there's gotta be some
<jason> sourceforge is for projects im not looking for projects im looking for example sites
<ikonia> Amaranth: I was picking up a conversationwith jason from another chanel where he was rambling
<ikonia> I was trying to highlight an example, badly
<LaserJock> jason: well, a program is an example
<jason> its a more complex example
<mjg59> Amaranth: Try it from the console (sudo /etc/acpi/sleep.sh force) without nvidia loaded. You'll be unlikely to get a console back, but you can then see if the machine is still alive.
<ikonia> jason: amazon.com - there are books
<Amaranth> LaserJock: gnome-system-monitor
<Amaranth> mjg59: alright
<Amaranth> mjg59: do the pm-trace thing?
<mjg59> No
<jason> i currently program in php OOP just want to stear into c++ for app development
<LaserJock> jason: so maybe just google C++ tutorial?
<jason> or C
<Amaranth> ok, brb
<jason> thanks that did the trick for c++ tutorial
<jason> http://www.cplusplus.com/doc/tutorial/
<Lamego> well, most of the ubuntu specific apps are written in python, not C++ :)
<jason> python has a gui
<jason> or i mean can create one?
<Lamego> yes, it does not have a gui, it has libraries which provide a gui, same as for C++
<jason> neat
<jason> what IDE do you use for it
<Lamego> a plain text editor :)
<LaserJock> same as for C++ ;-)
<LaserJock> emacs/vim FTW
<Lamego> give a try either to wxpython or wxpython
<Lamego> I personally found wxGTK easier to learn
<Lamego> ops, i mean, pygtk or wxpython
<Lamego> jason, you have plent of examples your system, more /usr/bin/update-manager :)
<jason> is that a binary file or text
<Lamego> it is a text, more was the command to read it
<jason> sorry didnt see the more
<Lamego> when in doubt: file /usr/bin/update-manager ;)
<jason> i see the could pretty neat
<jason> /usr/bin/update-notifier is not readable though
<Lamego> uh ?
<Lamego> hum
<Kmos> kmos@bash:~$ file /usr/bin/update-manager
<Kmos> /usr/bin/update-manager: python script text executable
<Kmos> :)
<Lamego> hum, there is something strange, randomly, more is reporting as not executable
<jason> so update-notifier is python
<Lamego> ops, i mean't manager
<Lamego> erm, meant
<Lamego> update-manager, is
<Lamego> or /usr/bin/gdebi , etc, etc
<jason> ok
<Amaranth> mjg59: even if i blacklist nvidia and ipw3945 and boot in recovery mode it fails, no caps lock, sound stays muted (hardware light)
<LaserJock> jason: python is a scripted language so you have many many examples already on your computer
<LaserJock> jason: there is also a book called Dive Into Python which you can install (if it isn't already) in Ubuntu
<Amaranth> LaserJock: diveintopython is a dependency of ubuntu-desktop :)
<LaserJock> ah, good, I thought maybe they removed it
<LaserJock> so you can just go into the Help and search for dive into python
<jason> which IDE can i use for this python
<LaserJock> jason: I just use a text editor, but I think python may come with one (IDLE) and I think SPE is decently popular
<LaserJock> I believe there are also python plugins for eclipse
<Lamego> hum,  python plugin for eclipse would be handy
<MrMazda> Does gutsy have a startup option that allows to use legacy drivers instead of libata for IDE HDs?
<ryanakca> umm... why do we have ddate in util-linux, or on the default install... it seems like the biggest waste of 7.7k :P
<Amaranth> MrMazda: no, afaik those drivers are gone
<cjwatson> ide-generic is still there
<MrMazda> What's the secret to using them? I did modprobe -r ata_piix but the installer just reloaded it. My installation target is hda22
<cjwatson> hmm, it's true piix.ko isn't built any more
<cjwatson> MrMazda: what problem are you trying to solve? it's usually better to move forward than back ...
<MrMazda> installation target is hda22
<MrMazda> cjwatson: forward is not substituting a 14 partition limit for a 62 partition limit. SUSE and Mandriva furnish legacy drivers so people can continue to use existing partitioning.
<cjwatson> my point was that it would be good to report bugs on the current drivers so that they can be fixed, because they do resolve other problems
<cjwatson> I agree the limit is unfortunate, and it's not a problem that had occurred to me before
<cjwatson> as for legacy drivers, you'd need to ask the kernel team
<cjwatson> hmm, there is a pata_oldpiix.ko
<cjwatson> though drat, that's still libata
<cjwatson> MrMazda: I think the best you're likely to be able to do at present is to build the module yourself and blacklist the other in modprobe configuration so that it doesn't get reloaded
<MrMazda> cjwatson: libata cannot be fixed because the limit is in the kernel to use the same limits that plague real SCSI. The only possible kernel fix (already planned) is actually a complete libata rewrite that doesn't depend on SCSI. Until either that rewrite or a device mapper solution, only legacy drivers are possible solution for systems requiring access to all existing partiitons.
<MrMazda> cjwatson: how would that help getting installed in the first place?
<cjwatson> I didn't say it would be easy ...
<mjg59> MrMazda: Yeah. I'm afraid there's currently no practical way to install on devices with more than 16 partitions.
<mjg59> You're the first person to have complained, amazingly
<cjwatson> I think if I needed that many partitions I'd be inclined to move to LVM
<MrMazda> mjg59: not exactly: https://bugs.launchpad.net/ubuntu/+bug/134983
<ubotu> Launchpad bug 134983 in ubuntu "Cannot mount /home on /dev/hda16" [Undecided,New] 
<cjwatson> (I'm not saying that your situation isn't a problem, understand - but this isn't going to change for 7.10 at this point)
<cjwatson> I should probably make the installer check the partition count so that it fails earlier / more obviously
<mjg59> MrMazda: Heh. Ok, second.
<MrMazda> there's an even bigger problem in that it is a booby tray for upgraders who have no clue it's a problem
<mjg59> Yes.
<mjg59> But it's an issue that was introduced with the previous release, so I suspect it's hit about as many people as it's likely to now
<MrMazda> mjg59: SUSE & Mandriva at least offer a clue: e.g. http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/Notes#Changes_to_the_Mandriva_installer
<cjwatson> if somebody could file a bug on update-manager to add a check, that would be good
<cjwatson> MrMazda: TBH it simply hadn't occurred to me up to now. Now that you've mentioned it we can release-note it in various places
<MrMazda> mjg59: a google for the subject of libata partition limit or somesuch does turn up a lot of discussion from people who hit the problem in SUSE & Mandriva beta testing, and people who simply can't with Fedora, plus other distros affected
<mjg59> MrMazda: I'm not denying it's a problem. I just don't think the number of people it hits is large.
<mjg59> For those it does hit, it's obviously a major issue and we ought to be communicating that.
<mjg59> But since you're only the second person to have raised it as an issue with us, it's something that hasn't featured as a high priority...
<MrMazda> mjg59: I know, like the problem of mousetype on web pages doesn't affect many people, but it's a big problem for those it does hit. :-(
<MrMazda> lvm isn't for everyone
<MrMazda> I wanted to bring this up on ubuntu-devel@lists.ubuntu.com a long time ago, but my attempts to post there always get rejected by moderators :-(
<cjwatson> moderation rejections from ubuntu-devel@ are typically quite clear about where things should go instead
<cjwatson> was yours not?
<cjwatson> (cf. http://wiki.ubuntu.com/UbuntuDevelModeration)
<cjwatson> and ubuntu-devel-discuss@ is always an option
<MrMazda> cjwatson: OK thx. I didn't know about the devel-discuss
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<Amaranth> That reminds me, how do I get access to ubuntu-devel?
<Amaranth> I was told being in ubuntu-dev automatically whitelisted me but apparently not
<cjwatson> Amaranth: can be arranged *clicketyclick*
<Amaranth> cjwatson: ok then, amaranth@ubuntu.com
<cjwatson> moderation's pretty quick nowadays mind you
<cjwatson> Amaranth: done
<Amaranth> cjwatson: thanks
<MrMazda> cjwatson: OK, I'm now off devel, on devel-discuss :-)
<bddebian> Heya
<Burgundavia> is the release the 18th or the 17th?
<mjg59> 18th
<mjg59> Thursday is traditional
<Burgundavia> ok, the Fridge calendar is wrong, need to change that
<lamont> gcc-3.4 for hppa/gutsy has built, and yet the dapper libstdc++6-dev from dapper is still in the universe Packages file... is that launchpad, or just an archive god that needs to fix that?
<StevenK> lamont: Is it in NEW?
<lamont> not even close
<lamont> it's a real package that turned into a provided package somewhere between dapper and gutsy
* lamont sleeps
<LaserJock> gnight lamont
<MrMazda> Is anyone not getting dbootstrap failure while installing base packages on beta2 i386? This happens to me on both network and CD installs.
<MrMazda> an error was returned while trying to install the initramfs-tools package onto the target system happens every time
<pitti> Good morning
<LaserJock> hi pitti
<mekius> bryce: you still up?
<LaserJock> pitti: I've got an edubuntu-docs upload in the queue, can you approve it?
<pitti> LaserJock: what does it change?
<LaserJock> pitti: adds in the translations
<LaserJock> it's hopefully the last upload before release
<pitti> LaserJock: done
<LaserJock> pitti: thank you
<StevenK> pitti: I have something for you to cast an eye over too, if you have a moment?
<pitti> StevenK: sure
<StevenK> pitti: http://wedontsleep.org/~steven/vbox
<StevenK> pitti: Basically, it builds the modules for virtualbox-ose for -generic and -server, since I asked BenC and he said something along the lines of
<StevenK> "I've played that game, it was a pain, and we're not playing it again."
<pitti> that game -> include them into l-u-m?
<pitti> or did he refer to dapper's vmware modules?
<mjg59> Ben doesn't want to include modules which have a tight version dependency with userspace
<StevenK> That game was including them in l-u-m, which I believe was done for Edgy or Feisty
<pitti> the package itself looks sane enough, no problem there
<pitti> but if we put it in, this sort of commits us to support it and keep it up to date
<pitti> i. e. increases the number of things to do for kernel ABI bumps and testing, etc.
<StevenK> pitti: I'm happy to do so, I've no plans at all to update virtualbox-ose during gutsy.
<pitti> StevenK: did BenC give his blessing to this approach?
<StevenK> pitti: BenC's suggestion was to use DKMS. I've not asked for his blessing for this approach since I was unsure if I could make it work.
<StevenK> It fails to build due to an interesting message, I need to track that down
<StevenK> dpkg-genchanges: error: badly formed line in files list file, line 1
<pitti> StevenK: ah, so I propose: get that build fixed and upload, and we keep it in the queue until we can ask BenC later?
<pitti> uh?
<StevenK> pitti: Sounds absolutely perfect to me.
<pitti> StevenK: debian/files exists and wasn't cleaned or so?
<StevenK> It doesn't exist in the source tree.
<StevenK> pitti: If you notice, I still need to write a copyright file. :-)
<LaserJock> StevenK: "need"? ;-)
<LaserJock> I thought they were optional
<pitti> LaserJock: hm? they are one of the most important things to get a package through source NEW :)
<StevenK> Oh, duh, I know why it fails.
<StevenK> % grep Section debian/control
<StevenK> Section:
<LaserJock> heh
<doko> good morning
<StevenK> pitti: I've updated the package, would you mind having a closer look at the copyright file, and letting me know if it's okay?
<liw> '423 projects found  matching ubuntu' -- that makes it surprinsingly hard to find the real Ubuntu project on launchpad
* StevenK chuckles
<StevenK> liw: /ubuntu
<liw> StevenK, it searches the paths, not the human-readable names?
<pitti> StevenK: wow, the copyright file will not exist for another 19 seconds (timestamp in the future)
* pitti watches it pop out of nothing all of a sudden
<StevenK> liw: I have no idea. :-)
<pitti> StevenK: you need to add an explicit link to the GPL v2 in common-licenses/
<StevenK> Leet. My time was -160 seconds off
<StevenK> pitti: I do
<pitti> StevenK: only for the general GPL for hte packacing, not for the innotek license
<pitti> StevenK: (which is GPL 2 only)
<StevenK> pitti: Ahh. Package updated.
<StevenK> pitti: I've added another line to the copyright about GPL-2, does it look all fine now?
<pitti> right at the bottom? yes, that sounds fine
<StevenK> Okay. Let me test build it again, and then I'll upload it.
<dholbach> good morning
<Burgundavia> morning dholbach
<dholbach> hey Burgundavia
<mdke> hiya dholbach
<dholbach> hey mdke
<\sh> moins
<StevenK> pitti: virtualbox-ose-modules uploaded, thanks for your help.
<pitti> thanks
<StevenK> Oh drat. I forgot to mention the LP bug. Oh well, I'll close it manually with the virtualbox upload.
<StevenK> (After this is sorted out, I'm plotting to upload virtualbox-ose that Suggests virtualbox-ose-modules)
<superm1> pitti, lirc's source package sits in main, but the interesting binaries end up elsewhere (and should be under the hard freeze right now).  would it be possible (er would you guys be opposed ) to fix a few minor changes regarding configurations that aren't available still, like bug 148756 and bug 145847 and bug 147440?
<ubotu> Launchpad bug 148756 in lirc "lirc_gpio module cannot be loaded in Gutsy" [Undecided,New]  https://launchpad.net/bugs/148756
<ubotu> Launchpad bug 145847 in lirc "Remote codes for Hauppauge Nova-T-500 dual tuner DVB-T PCI card" [Undecided,New]  https://launchpad.net/bugs/145847
<ubotu> Launchpad bug 147440 in lirc "cannot make lirc_i2c kernel module" [Wishlist,Triaged]  https://launchpad.net/bugs/147440
<pitti> superm1: fixing those sounds appropriate to me
<pitti> superm1: I (or slangasek) reserve the right to judge based on the debdiff, though
<superm1> pitti, of course.
<superm1> just wanted to make sure before i put the effort forward
<pitti> cjwatson: for debugging the cryptroot initramfs problem with set -x, do I need to create a customized alternate CD, or is it possible to sneak in a modified cryptsetup deb somehow?
<StevenK> pitti: Oh yeah, NBS has 3 -12 packages living it in, input-modules-2.6.22-12-{hppa{32,64},lpia}-di
<StevenK> Sigh, living in it
* pitti kills
<pitti> done
<StevenK> pitti: Thanks!
<cjwatson> pitti: I'd just edit the script on the fly if I were you ...
<pitti> cjwatson: just hit the right moment?
* pitti currently exercises the alternate CD customization howto, but it's quite a lot of overhead
<cjwatson> you should have a reasonable window
<pitti> cjwatson: ok, I'll try that first, thanks
<superm1> pitti, would you prefer that i go through a core-dev sponsor before you have a look at the debdiff, or would you like to look it over directly yourself?
<pitti> superm1: a review from your usual sponsor would be good, since I don't know LIRC myself
<superm1> pitti, okay will do. thanks
<dholbach> hey mvo
<mvo> hey dholbach
<mdz> cjwatson: yes, I do, and I see you already did it, thanks
<mdz> cjwatson: I thought we had decided that ages ago, but if we did, it apparently didn't get implemented until now
<heno> *** 20071008 ISO images are now candidates for RC *** Please test and report results at https://iso.qa.stgraber.org/
<heno> Current test subscriptions: https://iso.qa.stgraber.org/qatracker/subscription
<pitti> hi heno
<pitti> heno: hm, I'm just moderating the unapproved queue
<pitti> heno: e. g. there is a new ubiquity, and such
<pitti> heno: I'll probably re-roll new images today
<heno> pitti: ok, I got a mail from Steve asking me to start the testing
<heno> pitti: but things change obviously :)
<pitti> heno: well, that's fine :)
<pitti> heno: just saying that those aren't the final RC images yet
<heno> do you think you'll rebuild just desktops for now?
<pitti> heno: the langpack export should also finish at some point today, so we'll get new langpacks and thus new alternates, too
<Amaranth> mvo: did the compiz fixes get in already?
<pitti> heno: but testing the current images is very important to verify fixes and find new grave bugs
<heno> pitti: Right. I think it's useful to start mobilising people though :)
<pitti> heno: absolutely
<mvo> Amaranth: the current bzr is not uploaded yet, because of #122549
<heno> pitti: so we are agreed. I should find a word for almost-candidates :)
<Amaranth> bug 122549
<ubotu> Launchpad bug 122549 in compiz "[gutsy]  unredirect-fullscreen-windows option breaks gnome-screensaver locking behavior" [High,In progress]  https://launchpad.net/bugs/122549
* Amaranth is lazy
<mvo> Amaranth: there is some progress, but I'm not sure if my approach for the fix is correct, it seems to work for me though.
<Amaranth> mvo: ah, that one
<Amaranth> I still can't reproduce that
<Amaranth> That guy using synergy can probably be ignored if the patch you have doesn't fix it for him
<mvo> Amaranth: the trouble is that I change findTopLevelWindowAtScreen() and that may cause undesired side-effects
<mvo> indeed
<mvo> I was able to reproduce it here with out synergy or anything
<RAOF> I've just checked, I easily get it without Xgl.
<Amaranth> I don't use Xgl
<RAOF> I get it with and without Xgl, so :P
<Amaranth> *sigh* I wish the -rt kernel would not lock my CPU to C0
<Amaranth> I just did an apt-get upgrade and didn't even notice
<RAOF> Now, to test whether nvidia resumes-from-suspend...
<persia> dholbach: Thank you.
<mvo> RAOF: if you easily get it, could you please test if the patch http://launchpadlibrarian.net/9847233/030_fix_screensaver fixes it for you? (against compiz)?
<RAOF> mvo: Certainly; it'll have to wait 'till I get home though.
<Amaranth> mvo: It is an interesting fix
<dholbach> persia: de rien
<Amaranth> mvo: But you should probably make it exclude tooltips and menus
<mvo> Amaranth: yeah, that is my concern. I was wondering if those are InputOnly or InputOutput
<Amaranth> mvo: You could just explicitly check for them and not have to worry about it
<ogra> pitti, are you crazy ? what am i eversupposed to do with 50Mb spare space on my CDs ?
<pitti> ogra: :)
<Amaranth> ogra: How did you get free space?
<pitti> ogra: thank doko
<Amaranth> No fair :P
* ogra falls into diabolic laughter with a crazy look in his eyes
<pitti> ogra: fill them with langpacks
<ogra> pitti, yeah :)
<doko> ogra: you could add icedtea ... (including java plugin for amd64)
<pitti> ogra: and/or ship nvidia-glx-new, or anythign
<ogra> doko, how much is that ?
<ogra> (i'D love to :) )
<doko> 27mb
<doko> but not yet in the archive ...
<ogra> ah, that still leaves space for the major langs
<doko> and still universe
<cjwatson> icedtea -> hardy
<cjwatson> much though I think it's great to have free hopefully-fully-working Java, it still needs to get into the archive and there are 10 days to go. :-)
<cjwatson> to clarify I mean icedtea in main / on CDs -> hardy
<pitti> cjwatson, mvo "useDevelopmentRelease=False" in the dist-upgrader is not yet done for the release candidate, right?
<ogra> if [ -e $COMPRESS_LOG ] ; then
<ogra>     mv $COMPRESS_LOG /taget/var/log/
<ogra> fi
<ogra> how disconcerting ...
<tkamppeter> hi, pitti
<\sh> remoins
<pitti> hi tkamppeter
<tkamppeter> pitti, I have put up fixed gutenprint packages, see mail
<pitti> thanks
<tkamppeter> Riddell, ping
<pitti> I'd like to hear Riddell's confirmation first, though
<tkamppeter> pitti, the ijsgutenprint package is for sure needed by foomatic-db-gutenprint. The PPDs from foomatic-db-gutenprint NEED ijsgutenprint. Therefore I have reverted Riddell's change.
<pitti> tkamppeter: no doubt about that
<pitti> tkamppeter: I meant, the alternative solution you proposed
<tkamppeter> pitti, this is confirmed by users in the bug report. They got the problem solved by installing foomatic-db-gutenprint (which pulled in ijsgutenprint).
<pitti> ok
<Riddell> pitti: on the whole I trust tkamppeter when it comes to printing :)
<pitti> Riddell: ok
<tkamppeter> Riddell, so take in foomatic-db-gutenprint and ijsgutenprint and leave out cupsys-driver-gutenprint in the Kubuntu Gutsy seeds.
<Riddell> the trouble with ijsgutenprint is it depends on gs
<tkamppeter> Riddell, but note that it is a workaround for the totally outdated KDE Printing Manager. For Hardy the KDE-P-M must get fixed and the seed change reverted.
<Riddell> which means moving it and one of the gs packages to main
<Riddell> tkamppeter: are you going to UDS?
<tkamppeter> Riddell, the gs dependency in ijsgutenprint I have fixed now.
<tkamppeter> pitti, do not upload gutenprint, I need to do still a little fix.
<pitti> tkamppeter: alright, I'll wait for it
<kagou> Hi
<tkamppeter> Riddell, I have done it in the upcoming gutenprint 5.0.1-0ubuntu8. Now I have added the new package name "ghostscript" as alternative for this dependency.
<tkamppeter> kagou, thanks for the bug report with the Canon printers, so I could fix this in the last minute.
<kagou> tkamppeter, your welcome ^^
<ogra> pitti, there is an ltsp upload waiting for approval, debdiff is on http://people.ubuntu.com/~ogra/debdiff-5.0.38-5.0.39.diff
<ogra> (ailly typo)
<ogra> *silly even gah
<pitti> ogra: NP, I'll get the diffs directly from the queue
<tkamppeter> Riddell, I will not be on the UDS, as the same week there is an OpenPrinting Meeting in Tokyo (Oct 31 - Nov 2). I will show the work of OpenPrinting to the japanese printer manufacturers.
<liw> mvo, I just filed https://bugs.launchpad.net/ubuntu/+bug/150500 -- I didn't find anything about it yet, but is it a known issue?
<ubotu> Launchpad bug 150500 in ubuntu "update-manager fails upgrading feisty to gutsy, Python "import os" is missing" [Undecided,New] 
<mvo> liw: do you use update-manager from feisty-updates?
<liw> mvo, I installed feisty from the iso, then installed updates with update-manager, then rebooted, so I assume that was the one
<mvo> liw: could you please check the version number?
<mvo> liw: and add that information to the bugreport?
<liw> sure, just a minute
<liw> mvo, I added "import os" at the top of the problematic file, that made it work (at least past the point where it crashed before)
<liw> mvo, 1:0.59.19
<mvo> liw: that is not the version from -updates, maybe something was missing from the update-manager update run you did before?
<liw> mvo, if so, update-manager's failure mode for that was not evident; I'll try the experiment from scratch
<mvo> liw: thanks, that is appreciated
<liw> mvo, this is what I'm here for :)
<RAOF> Mvo; your fix doesn't work
<mvo> RAOF: that makes me unhappy. you still get the problem?
<RAOF> mvo: Yes.  I typed that on a locked screen.
<RAOF> mvo: I'm just trying to find the build log to ensure that the patch was actully applied; sbuild doesn't seem to want to email me reports anymore :/
<Amaranth> So how did doko get 50MB free space for ogra to fill?
<Amaranth> Drop OOo? :)
<pitti> that would have given us half of the CD, no
<ogra> Amaranth, removing file duplicates
<pitti> mainly, getting air out of duplicated changelogs, files, etc.
<Amaranth> Oh, still just that
<Amaranth> apparently evolution was a big one
<ogra> pitti, did you change anything wrt oo.o in ubuntu now ?
<pitti> ogra: no; removing -base is too complicated surgery for this point
<ogra> Amaranth, localized screenshots are the biggest one i guess ... they should go into special langpacks imho
<ogra> but thats nothing for "dawn of release" time :)
<Amaranth> Is OOo really half the CD?
<pitti> including all the java, db, and other dependencies it pulls in, it's very large
<pitti> (not half of the CD, but I'd guess in the order of ~ 200 MB?
<Amaranth> ouch
<Fujitsu> Ow.
<Amaranth> Is it compiled with -Os?
<Amaranth> :)
<Amaranth> I don't remember what ubuntu's default CFLAGS and such are
<pitti> -O2
<Amaranth> Huh, I thought for sure it'd be -Os since we're always fighting for more space
<Fujitsu> Noooo, OOo is slow enough without Os
<Amaranth> Fujitsu: It would go faster?
<elmo> Fujitsu: err, -Os is often faster than -O2
<pitti> Amaranth: IIRC only -O3 might make binaries bigger; -O2 only has optimizations which don't increase size
<Fujitsu> Ah.
<Amaranth> pitti: But -Os makes it smaller than -O0
<pitti> yeah, maybe
<Amaranth> Fujitsu: Less data to load from disk, better chance of fitting in cache
<Fujitsu> Amaranth: True.
<Amaranth> Someone should try it
<Amaranth> I would but all I have is this laptop and I don't want it burning a hole in my leg for the 6 hours or whatever OOo takes to build :P
<Fujitsu> Isn't 6 hours waaaay to conservative?
<Fujitsu> *too
<Amaranth> Fujitsu: Someone with a dual dual core Xeon built it in 6 hours, iirc :P
<Fujitsu> That might do it.
<RAOF> mvo: Is it possible that some plugin set up is why I see this problem?
<mvo> RAOF: I don't think so, but it might be
<RAOF> mvo: Want a tarball of my gconf tree?
<tkamppeter> pitti, the fixed gutenprint is in place now. Ready for uploading.
<liw> mvo, ok, seems that my first attempt to upgrade to current feisty had failed, upgrading and continuing
<mvo> liw: what was/is the issue with the update?
<ogra> liw, s/to/from/ ?
<liw> mvo, I have no idea, I thought I did all the same steps as just now
<liw> ogra, from system installed from feisty iso to feist-updates
<ogra> ah
<pitti> soren: FYI, I now found the most convenient way how to circumvent erasing the encrypted partition
<pitti> soren: use the autopartitioning method, say "No", flip the erase flag, choose "guided partitioning", and say "yes" for confirmation
<soren> pitti: Uh.. How do you flip the erase flag before it shows you the page where you can alter the partition layout?
<pitti> soren: in the 'manual' dialog
<soren> pitti: Ah.. Clever.
<soren> pitti: did you track down the initramfs issue yet?
<pitti> soren: at it
<pitti> soren: I know the reason, now I'm looking for the cause
<pitti> Oct  8 07:57:28 apt-install: + [ -L /dev/disk/by-uuid/bb796e0a-307c-4129-a152-8cf6bda3cb5d ] 
<pitti> fails
<pitti> my current theory is that there is no /dev in /target, at least not the same dynamic one we have in /
<pitti> (in the installer environment)
<pitti>  /target/dev/mapper/ is fine, but there is no /target/dev/disk/by-uuid/
<soren> pitti: Makes sense.
<soren> Any reason why we're not bind mounting it in the /target ?
<cjwatson> pitti: that's very possible, actually
<cjwatson> sounds like a straight bug
<pitti> well, I guess bind-mounting it would be a good answer
<pitti> for the long-term solution
<pitti> but I'm not sure whether that's appropriate at this point of the release
<cjwatson> try mount -o bind'ing it in the install_extra function in /var/lib/dpkg/info/base-installer.postinst
<cjwatson> and umounting it on return from that function
<pitti> I currently have a test install going
<pitti> and I SIGSTOPed the kernel installation by apt
<pitti> so I have time to poke around
<cjwatson> maaaaaaybe around bits of install_linux too
<cjwatson> bit worried about doing it for the whole of base-installer at this point, as it's a touch fragile
<pitti> unless there's an easier method to resolve an UUID to a device node?
<soren> pitti: What does it need it for anyway?
<pitti> soren: it needs to feed the device node to dmsetup
<pitti> soren: so that it can find out the physical device of the root lvm
<soren> Ok.
<pitti> soren:  deps=$(dmsetup deps "$node" 2> /dev/null | sed 's/[^:] *: *//;s/[ (] //g;s/)/ /g')
<pitti> if $node is a UUID, this fails
<pitti> so in the recent cryptsetup I added that UUID resolution
<soren> ah, yes, I remember.
<pitti> above command will cut out the major and minor device number of the PV
<pitti> cjwatson: I'll give this a try
<Keybuk> pitti: resolving a UUID is easy (iterate block devices and peek)
<pitti> cjwatson: when is that postinst called?
<Keybuk> ensuring that the UUID is for the device that udev would have picked is hard
<Keybuk> (since udev applies priorities to UUIDs)
<pitti> Keybuk: that sounds like an issue for ambiguous UUIDs only?
<Keybuk> pitti: such as any involving devmapper :p
<cjwatson> pitti: the postinst implements the "install the base system" menu item
<pitti> cjwatson: I mean, is it installed into /target, or run within the installer? when can this change be made in the installer env?
<Riddell> mvo: you're the man for sru-verification?
<cjwatson> pitti: it's run within the installer
<cjwatson> pitti: you can make the change at any point between "retrieving additional components" ending and "installing the base system" starting. The hostname prompt is usually a good time
<\sh> hmmm...after a reinstall of latest gutsy daily, all my ooffice crashes are gone (at least on one machine) strange
<pitti> cjwatson: ah, sweet
<pitti> Keybuk: vol_id seems to be a good tool for getting the UUID (just in case we don't want the bind-mount approach); however, iterating over all block devices sounds a bit painful
<Keybuk> pitti: vol_id is *the* tool for getting the UUID :-)
<Keybuk> but as I said, don't do it that way if anything involving devmapper, lvm or md comes into play
<Keybuk> lvm especially, since with snapshots, you might not know which of the four block devices with identical UUIDs you need
<pitti> ok
<Keybuk> or if evms is likely to be installed
<soren> Keybuk: This is in the alternate installer if you choose encrypted lvm.
<Keybuk> ahh
<soren> So evms is not very likely to be around :)
<Keybuk> so yes, do NOT NO NOT use vol_id for that
<soren> (I know, you missed the start of the conversation)
<Keybuk> since you need udev to sort out the duplicate UUIDs for you
<pitti> Keybuk: ok, so it's bind-mounting or nothing
<kyja> pardon me.. anyone home? :) I seem to have a double entry of the Desktop menu item in Places menu in Gnome. How can I remove one?
<kyja> I should probly ask this elsewhere folks here are rather busy for the development of core software.
<pitti> kyja: that's a known bug, and marked for gutsy release candidate
<kyja> oh thank you. I wont hack then hehe
<tepsipakki> pitti: I have a fix for ati (pulled from upstream); the latest update changed to default on CVT mode, but this change reverts that (back to LVDS) and adds an option to use CVT if needed. I have a package on my ppa and people have verified it works
<seb128> pitti: it's already fixed
<seb128> kylem: that's a gtk bookmark, you can remove it from nautilus
<kyja> k
<seb128> the package is fixed, new installation or upgrade will not add the bookmark to desktop
<seb128> but if you used a buggy version you have to remove it yourself now
<asisak> mvo: if I use pbuilder-satisfydepends-gdebi with unsigned local repositories, it will fail, since "E: There are problems and -y was used without --force-yes". Do you want to accept a patch that fixes this? I would not be afraid of security issues, since a pbuilder user should know what he wants to do.
<bigon> hi, is it still possible ton sync gtk-doc from debian (new upstream version)? I've an issue with the version currently in gutsy and the version of debian fix the probleme
* soren -> lunch
<pitti> tepsipakki: please get it uploaded and make sure the relevant bug is properly milestoned, u-release sub'ed, etc.
<pitti> tepsipakki: slangasek will take a look later
<pitti> (or me)
<tepsipakki> pitti: just uploaded that, I'll milestone those bugs etc
<tepsipakki> done, phew
<tepsipakki> strange bug actually, it had three symptoms; 1) misplaced desktop, 2) nearly monochrome graphics, or 3) blank screen :)
<bluekuja> pitti: dont need to check lightning-locales, I'm working on them with seb128
<bluekuja> so you can move to other tasks
<bluekuja> thanks for bittornado :)
<pitti> bluekuja: appreciated, thanks
<seb128> pitti: lightning-extension-locales is good to approve if you want, that's only a section fix (technically I could process it but since I'm not a r-t member I prefer to let you do it ;)
<pitti> seb128: if it's only that, then we don't actually need it; we need to use the soyuz override anyway
<seb128> pitti: the binary upload has been rejected by soyuz because of the incorrect section if I understand it correctly
<seb128> pitti: it's using a non valid section
<seb128> not a valid but wrong one
<pitti> seb128: I rejected it manually on bluekuja's request
<seb128> ah, ok
<seb128> I didn't understand correctly what he told me or he was not clear then
<pitti> he asked me to so that he could fix the section
<seb128> sorry for the noise
<pitti> np :)
<bluekuja> seb128: yeah, there was a control template inside debian/
<seb128> pitti: btw people argue on the nautilus vfat bug that the patch should be reverted because it's better to have the freeze on mount that during a copy (because if you try closing it before it's frozen it can lead to data loss apparently)
<bluekuja> seb128: which was still set on internet section (wrong)
<seb128> s/before/while
<seb128> bluekuja: well, as pitti said that's no big deal and can be override on soyuz without a new upload for now
<asac> heno: i run update-manager -d -c in my feisty vbox install, but no upgrade happens (e.g. update-manager claims to be up-to-date)??
<asac> heno: nevermind :)
<bluekuja> seb128: ok then :)
<asac> heno: hmmm ... there is indeed no upgrade version button :/
<heno> asac: which distro flavour?
<liw> asac, strange, it just worked for me
<heno> I just completed an Ubuntu upgrade, which was fine
<bluekuja> seb128: what will you do with that revision then? will be rejected as well?
<heno> doing kubuntu now
<seb128> bluekuja: up to pitti
* Riddell crosses fingers
<bluekuja> seb128: ok, I'll ask pitti for it then
<bluekuja> thanks
<pitti> bluekuja: it's only the source section? or any binaries as well?
<bluekuja> pitti: only source
<pitti> bluekuja: that's about the least important thing anyway, but let me change it
<bluekuja> pitti: ok thanks
<asac> heno: desktop ... feisty i386
<mvo> asac: do you have the update-manager from feisty-updates
<asac> mvo: hmm let me see ... just default feisty install + all upgrades
<mvo> asac: that should be fine, but please check the version to be sure
<asac> mvo: updates is in sources.list ... i try to upgrade (i setup this install on fri/sat)
<pitti> bluekuja: oh, failed-to-upload; that's more serious; I'll accept this
<bluekuja> pitti: yeah, it was a failed-to-upload
<mvo> asac: please check for update-manager and update-manager-core, it should be 0.59.25
<bluekuja> pitti: for that error in the section
<bluekuja> pitti: thanks
<pitti> bluekuja: accepted and overridden, thanks
<asac> mvo: hmmm ... both have that version ... but apparently my vbox has lost network access ... could this hide the upgrade button?=
<bluekuja> pitti: thanks for your work on it martin
<mvo> asac: yes, no network will result in this
<xjkx> will you ever create an ubuntu comming with mp3 codecs?
<asac> mvo: ok that explains it then
<bluekuja> pitti: it's normal I see Section: misc in gutsy-changes mail?
<carlos> pitti: would be possible that you block some locales to be used in language packs?
<pitti> bluekuja: I think yes; might be souyz' fallback for an invalid section
<carlos> pitti: it will take me a while to get it done in Launchpad to stop exporting them, so if you could do it in your side for Gutsy, would be wonderful
<pitti> bluekuja: the override does not get active until after the next publisher run
<Riddell> mvo!
<bluekuja> pitti: oh ok, perfect :) , sounds fine then
<pitti> carlos: for this one langpack build I can remember it, but not in general
<mvo> asisak: yeah
<mvo> hello Riddell!
<Riddell> mvo: I'd like to move kdebase update to -updates, I believe I need your backing as sru-verification man? bug 117731
<ubotu> Launchpad bug 117731 in python-kde3 "Python crashes after attaching pty to a konsole kpart" [High,Fix committed]  https://launchpad.net/bugs/117731
<carlos> pitti: yeah, just talking about gutsy final
<carlos> pitti: if we ship those locales once, even if I don't ship new updates from Launchpad, those old files will remain
<mvo> Riddell: mine or bdmurrays. I'm currently debugging a very nasty compiz issue with the screensaver
<pitti> carlos: ok, can do (assuming that you speak about particular languages, not locales)
<mvo> RAOF: anything new trying the patch? do you want me to prepeare a updated package that you can test?
<pitti> carlos: however, what do we use instead?
<pitti> carlos: we can't just entirely kill a language like Spanish
<seb128> pitti: the issue fr_FR taking over fr
<pitti> eww
<seb128> and fr is the correct domain, which has updated translation
<pitti> carlos: you mean I should locally modify the tarball before importing; yes, that's doable, too
<seb128> and the fr_FR has some randomly broken outdated files
<pitti> carlos: can you please mail me a list of all those cases?
<carlos> pitti: I'm talking about remove all languages that use '_' as part of the locale, except a good known list like 'zh_*' 'en_*' and  'pt_*'
<carlos> pitti: sure
<pitti> alright
<pitti> carlos: export is still running? time is pressing...
<carlos> pitti: if it takes as much time as last one, it will finish around 1:00AM tonight
<pitti> eww
<pitti> I thought I would have had the tarball this morning
<carlos> and yes, still running
<pitti> carlos: my error might have been that I assumed that "start it on Saturday" would mean 0200, not 2200
<carlos> pitti: yeah, sounds like that
<carlos> pitti: again, should I change the start time to 02:00 ?
<pitti> too late now
<carlos> we should fix this performance issue soon, but not in time for Gutsy
<mvo> Riddell: woah, the out of memory  issue is nailed down? that is GREAT!
<pitti> right, and changing the cronjob now wouldn't retroactively fix the time pressure
* mvo hugs Riddell
<carlos> ok
<carlos> pitti: I will send you that email after lunch
* carlos -> lunch
<carlos> later!
* Hobbsee waves
<Treenaks> hi Hobbsee
<realist> Hobbsee o/
<Hobbsee> :)
<Riddell> mvo: well
<Riddell> mvo: to some extent, I don't think it fixes it entirely, but it helps
* Hobbsee had forgottne just how loudly cars go boom.
<Treenaks> Hobbsee: you were in one?
<Hobbsee> yeah
<bluekuja> pitti: how long does it take to get published on lp starting build?
<pitti> bluekuja: publisher starts 3 minutes past the hour
<pitti> bluekuja: so, the next :03 after it finished building
<bluekuja> pitti: ok, was looking inside lp and watched a 0ubuntu1 pending
<bluekuja> pitti: and I dont see a 0ubuntu2
<bluekuja> pitti: https://edge.launchpad.net/ubuntu/+source/lightning-extension-locales/
<bluekuja> pitti: got published right now
<bluekuja> on lp
<bluekuja> ;)
<bluekuja> a small delay then
<pitti> the source gets known to LP immediately, yes
<bluekuja> yeah, after 10 mins from being accepted wasnt on lp
<Hobbsee> soyuz may have eaten it
<pitti> seb128: vfat patch> not sure; but if it does more bad than good, then let's revert it and hope that we can fix the kernel side in -updates
<Hobbsee> (or did it get stuck in NEW?)
<bluekuja> Hobbsee: wasnt NEW :)
<seb128> pitti: ok, I would do that then
<bluekuja> Hobbsee: so got eaten from soyuz
<bluekuja> Hobbsee: :)
<Hobbsee> i said may :)
<bluekuja> :D
<dholbach> asac: I subscribed you to bug 150529
<ubotu> Launchpad bug 150529 in firefox-3.0 "firefox.sh: unexpected operator ()" [Undecided,New]  https://launchpad.net/bugs/150529
<dholbach> cjwatson: I subscribed you to bug 145852
<ubotu> Launchpad bug 145852 in ntfs-3g "[UVFe]  please merge ntfs-3g (1:1.913-1) from Debian unstable (main)" [Undecided,In progress]  https://launchpad.net/bugs/145852
<cjwatson> dholbach: yeah, I've been working on it for the last couple of hours
<cjwatson> thanks
<dholbach> cjwatson: thank YOU :)
<asac> dholbach: why don't i have that? strange.
<dholbach> asac: nobody is bug contact for it
<dholbach> https://bugs.launchpad.net/ubuntu/+firefox-3.0/+subscribe
<dholbach> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+subscribe
<asac> dholbach: no:) ... i mean why does ffox just start fine here?
<asac> :)
<dholbach> oh ok :)
<gnomefreak> dholbach: asac mozilla-bugs is now the contact for firefox-3.0
<asac> gnomefreak: ok thanks
<gnomefreak> np
<asac> gnomefreak: please do the same for xulrunner-1.9
<gnomefreak> ok one sec
<gnomefreak> done
<bddebian> Heya
<Whoopie> mjg59: did you look at uswsusp for the usplash patch?
<sabdfl> BenC: sound is not working for me at all on X60. I found #95940 but that is for 2.6.20, should I file a new bug or add a new link to 2.6.23?
<mjg59> sabdfl: Make sure the modem is turned on in the bios
<mvo> RAOF: I have a update for the screensaver issue, would you be able to test ?
<bluekuja> pitti: built and published fine ;)
* Hobbsee ponders...stabbing against the code of conduct?
<StevenK> It isn't explicitly mentioned .... :-P
<Hobbsee> yeah, well.  this guy is about to cop a stabbing.  or a kickban
<Hobbsee> "yes, i should be allowed to repeat my question in #ubuntu every minute, because people who join may know the answer!  and isnt it lucky that everyone else isnt doing it, so the channel stays useful...."
<StevenK> Twitch
<StevenK> Oh look, you made sabdfl quit. :-P
<realist> Perhaps a gentle warning Hobbsee?
<zul> Hobbsee, hah
<Hobbsee> realist: he's already had it, over and over.
<Hobbsee> hahaha, nice.
<ScottK> Gentle warnings aren't Hobbsee's speciality.
<realist> Otherwise there's /ignore or /part
<Hobbsee> realist: there's /kb.
<Hobbsee> solves all
<realist> ScottK: /k then /kb constitutes a gentle warning
<Hobbsee> ScottK: no, no, this had a gentle warning - across 3 channels.
<Hobbsee> ScottK: and has already been kickbanned across 2 (although not by me)
<zul> Hobbsee: does the /kb include the option to electrocute?
* Hobbsee got to be the impartial "and what the frick do you think you're doing?" person
<Hobbsee> zul: i wish.
<ScottK> Hobbsee: Given your reputations for genteel subtleness, I've no doubt at all. ;-)
<realist> Hobbsee: As long as it's accompanied with a brief yet specific reason, it's perfectly reasonable
<Hobbsee> bah.  gone.
<realist> zul: that would deprecate *stab in the face* though?
<zul> realist: Hobbsee is  a bit evil so its up to Hobbsee's discretion
<Hobbsee> haha
<Keybuk> bdmurray: what do you use "Triaged" to mean?
<Kopfgeldjaeger> hi
<soren> What's the process for getting an upload approved these days?
<asisak> soren: I guess upload & wait :)
<Hobbsee> soren: ask a member of the release team
<Hobbsee> soren: oh, main or universe?
<soren> Hobbsee: Main
<pitti> soren: make sure the changelog has a milestoned bug #
<Hobbsee> and if it doenst, milestone the bug first :P
<pitti> and that the debdiff doesn't make us weep
<soren> pitti: Oh, I didn't bother to file the bug first. Should I do that for bookkeeping?
<pitti> no, don't milestone every small itch
<pitti> that will make the milestone list even worse than it is
<pitti> soren: what this meant was: "make sure you only work on bugs which are already milestoned"
<soren> pitti: It's a fresh dovecot merge with a few additions to post{rm,inst}
<soren> The fresh dovecot thing was already approved, afaik.
<pitti> soren: I just have that on my screen incidentall
<pitti> mvo: oh, btw, do you plan another update-notifier upload? we need one today to switch off apport by default
<mvo> pitti: ok, I can take care of this
<pitti> mvo: thanks
<pitti> soren: there is no bug number in the changelog, and intrusive changes
<soren> pitti: The dovecot upload fixes bug 149049, bug 146648 and another one that I discovered but didn't bother to file.
<ubotu> Launchpad bug 149049 in dovecot "FFe request: 1.0.5" [Undecided,In progress]  https://launchpad.net/bugs/149049
<ubotu> Launchpad bug 146648 in dovecot "Suboptimal defaults in dovecot.conf" [Medium,Triaged]  https://launchpad.net/bugs/146648
<soren> pitti: There are two bug numbers?
<pitti> soren: sorry, I mean milestoned bugs
<soren> pitti: Oh.
<pitti> soren: the changes look ok, though; how much testing did you give this?
<soren> pitti: My changes (the post{inst,rm} stuff) have been tested quite a bit, I'd say. mathiaz tested the new dovecot version.
<soren> mathiaz: Oy, great timing!
<soren> mathiaz: You tested the new dovecot version, did you not?
<mathiaz> soren: mornin' - I knew it :)
<mathiaz> soren: I've tested the upgrade.
<pitti> hi mathiaz
<mathiaz> soren: but not the functionalities - why ?
<mathiaz> hi pitti
<soren> mathiaz: Rock. I've fixed the "protocols = none" bug and redid the post{inst,rm} stuff to do what we agreed would be best.
<soren> mathiaz: Because pitti just asked :)
<mathiaz> soren: I think there is a small testcase in the security test package
<mathiaz> soren: to test that dovecot is working correctly.
<soren> "the security test package"?
<pitti> cjwatson: is the installation step where "additional packages" are installed (like update-manager-core and fuse) still covered by base-installer?
<mathiaz> soren: sftp://rookery.ubuntu.com/home/pitti/bzr/package-tests/
<pitti> cjwatson: ah, ignore my previous question; that can't be it
<soren> mathiaz: Oh.
<TomaszD> pitti, after the latest updates r-m is still in English, I thought this was fixed?
<pitti> TomaszD: there is no update yet; the langpack export is still going
<TomaszD> pitti, alright.
<pitti> mathiaz, soren: NB that dovecot has an autopkgtest
<pitti> mathiaz, soren: pretty much the one like in my package-tests branch
<soren> pitti: When is that run? At build time?
<mathiaz> soren: yes.
<sabdfl> mjg59: modem is switched on in BIOS, yes
<sabdfl> i'll file a new bug
<sabdfl> i wonder if we can close some of the older kernel ALSA bugs?
<pitti> soren: you have to invoke it manually
<sabdfl> they are all either wontfix, or fixed, or invalid i assume
<mathiaz> pitti: aren't they run automatically on the buildd ?
<pitti> no
<pitti> it's still a separate entity on iwj's
<Hobbsee> sabdfl: didnt mean to scare you off :P
<soren> pitti: They all fail.. Hm.. That can't be good :)
<\sh> so...time to go to another interview...new job I'm coming, or not
<pitti> soren: did you run them as root?
<pitti> soren: they assume that you have a pristine installation
<pitti> soren: and the default configuration changes might need an update of the test suite
<pitti> soren: I suggest running the test on the current gutsy version first
<pitti> for compariso
<pitti> n
<soren> pitti: I'm running it in schroot
<soren> pitti:  I'll see how it works on current version.
<pitti> not sure if that works
* soren is an idiot
<soren> note to self: Don't have a proper dovecot running while trying to do dovecot testing inside schroot.
<lool> iwj: Heya, if you're subscribed to ubuntu-desktop, do you think you could offer some suggestions on the topic of search engines enabled in deskbar-applet?  (Re: bug #131182)
<ubotu> Launchpad bug 131182 in deskbar-applet "search applet has inconsidered list of searches" [Medium,Confirmed]  https://launchpad.net/bugs/131182
<cjwatson> pitti: no, that's pkgsel
<pitti> cjwatson: anyway, /target/dev/disk was bind-mounted at that time still, so that's not it
<pitti> cjwatson: it works fine when the kernel is retrieved and installed, and the later run for fuse ruins it
<pitti> still debugging, if I could ever get 30 minutes without interruption :)
<Hobbsee> pitti: try /quit.  solves all.
<StevenK> Turn off the phone, tell your wife you're dead and quit IRC. Problem solved.
<soren> pitti: Yay, all the tests pass.
<BenC> sabdfl: We have an entire backport of alsa 15rc3 going into linux-backports-modules
<Hobbsee> BenC: what's your opinion on https://launchpad.net/bugs/130208 (apoligies if you'v ealready seen ti)
<ubotu> Launchpad bug 130208 in linux-restricted-modules-2.6.22 "package nvidia-glx None failed to install/upgrade: subprocess post-removal script returned error exit status 2" [Undecided,Confirmed] 
<BenC> sabdfl: I can get you a .deb to test if you want
<StevenK> BenC: I've got a quick question, if you have a moment?
<BenC> StevenK: sure
<BenC> Hobbsee: checking...
<StevenK> (It's 1am, but what the hell)
<ivoks_wii> BenC: i think nvidia-glx-new and nvidia-settings both have /usr/bin/nvidia-settings, but don't conflict as packages
<StevenK> BenC: I've packaged up the virtualbox-ose modules in virtualbox-ose-modules that builds vboxdrv.ko for -server and -generic. pitti wanted to get your approval about this approach before approving it out of NEW. Could I get you to check it over?
<pitti> cjwatson, soren: re cryptroot> ah, I know what's wrong; in the d-i environment, /dev/disk/by-uuid/ does not have LVM devices
<StevenK> BenC: It's built against -13, and I'm happy to do the hard yards for any ABI bump during Gutsy, I just need to be pinged and told about it.
<BenC> StevenK: it's going to suck because it'll need re-upload on -security ABI bumps
<StevenK> BenC: ^ :-)
<BenC> StevenK: ah, sounds good then :)
* StevenK grins
<pitti> BenC: good morning
<BenC> StevenK: if we have to ping you, then we might as well do the upload :)
<BenC> pitti: hey
<soren> pitti: So why doesn't it fail until fuse is being installed?
<BenC> ivoks: sounds like a conflict is needed between them
<StevenK> BenC: To be honest, it would be s/-13/-14/ in control, rules adding a changelog entry and uploading.
<ivoks> BenC: yes, -new lacks Conflict: nvidia-settings
<pitti> soren: the trick with the .bak is that this initramfs only has the swap device
<StevenK> I could be convinced to just get that down to control. :-)
<pitti> soren: it doesn't actually have the root device
<soren> pitti: I'm not sure how that answers my question.
<pitti> soren: fortunately this is not even necessary, due to the udev magic we have nowadays; but at least one of them need to be mentioned
<BenC> StevenK: yeah, but we already have 5 packages to do that with...you'd need to just check on such things
<pitti> soren: and the entire thing breaks if swap and root are not on the same LVM
<pitti> soren: I do not yet know why it breaks further (your actual question)
<soren> pitti: You mean vg?
<pitti> soren: yeah
<soren> Ok.
<StevenK> BenC: Fair enough, I can just bug pitti/kees about what to do when -security does an ABI bump.
<StevenK> BenC: If you're okay breaking it with -security uploads, I'm happy enough to fix it and slam bugs shut.
<cjwatson> pitti: by-uuid> why's that?
<pitti> cjwatson: I have no idea
<BenC> happy happy
<pitti> cjwatson: but it doesn't look like any trivial fix any more
<BenC> new lum uploaded with fixed unionfs
<StevenK> BenC: Cool.
<StevenK> BenC: Er, wait, was that 'happy happy' directed at my conversation? :-)
<pitti> BenC: ooh
<soren> BenC: Just now? Did you happen to see my mail to kernel-team about half an hour ago?
<BenC> StevenK: you're good with that package, as long as I don't get blamed for it breaking :)
<BenC> soren: no
<StevenK> BenC: Works for me. :-)
<pitti> BenC: and with rolled-back apparmor? or what's the current approach for that?
<StevenK> pitti: Can you NEW it? *flutters eyelashes* :-)
<bdmurray> Keybuk: I use triaged to mean that all the documented debugging information for that package / area has been gathered and that the bug should be looked at by a developer.
<BenC> pitti: no, this is just a unionfs-1.4 (reverted from 2.1) to work with current apparmor
<BenC> pitti: no other changes needed
<pitti> BenC: oh, and that's it? great
<soren> BenC: Could you take a look? Pretty, please?
<BenC> soren: sure, I thought someone had put it in
<soren> BenC: Yes, me too :)
<pitti> cjwatson: oooh, I just noticed that there are UUIDs in /dev/disk/by-id/dm-uuid-LVM-<something strangely encoded that is not an UUID>; how weird
<pitti> the <something strange> could be the base64 encoding of an UUID
<pitti> well, I think I give up at this point
<pitti> this isn't anywhere near trivial any more
<Keybuk> bdmurray: ah, that explains it then
<Keybuk> I use "Confirmed" for that :)
<Keybuk> "Triaged" to me means that there's enough information in the bug to fix it
<Keybuk> (Confirmed being enough information to replicate it)
<sabdfl> BenC: seems like sound is the #1 issue reported against the kernel
<bdmurray> Keybuk: Do you have a bug that you would consider Triaged?  I'm curious to see one with your criteria.
<Keybuk> not off-hand
<StevenK> pitti: Could I beg you to NEW virtualbox-ose-modules at your leisure? Maybe even binary NEW it when it builds on amd64 and i386?
<Keybuk> I've got lots which should only be Confirmed :)
<pitti> StevenK: yep, in a minute
<StevenK> pitti: Sure, thanks.
<BenC> sabdfl: it always is...stock alsa in the kernel is always way behind upstream :/
<Keybuk> e.g. any of the fsck/swap issues -- we have lots of information and can repeat the problem in vmware and see the bug
<Keybuk> but we have no idea what causes it
<Keybuk> at the point we know, I'd use the higher status
<Hobbsee> Keybuk: introduce YALPS!
<Hobbsee> Keybuk: ("Yet Another Launchpad Status")
<Keybuk> so to me, that's Confirmed because we've confirmed the bug exists and is replicable -- but not Triaged, because we don't know what's wrong with it
<BenC> sabdfl: cherry picking individual fixes is way too time consuming, which is why we're opting for a linux-backports-modules of the current alsa for people that want to install it
<Keybuk> otherwise if that's Triaged, it's not clear to be what Confirmed is for
<Keybuk> since that should be the same as New?
<Hobbsee> Keybuk: others can reproduce it / it is reproducible
<Hobbsee> or so the logic goes, anyway.
<cjwatson> the distinction as I've heard it explained is that Confirmed means that somebody can reproduce it, and Triaged means a developer can reproduce it
<cjwatson> which is, I concede, a non-trivial distinction (often reproducing a problem is 90% of the way to solving it)
* BenC sides with cjwatson's assumption
<StevenK> Which is oh so clear from the name.
<cjwatson> but it's not clear that it's exactly what we want
<Hobbsee> just blame sabdfl.
<Amaranth> cjwatson: I thought Confirmed was we can reproduce, Triaged means we know what's wrong, In Progress means we're working on a fix
<Keybuk> Amaranth: that's how I try and use them
<StevenK> That way makes sense to me.
<Keybuk> (Triaged but not yet In Progress bugs being good things for other people to pick up, since there's everything they need except the actual patch)
* Hobbsee suspecst they mean different things to different maintainers, and as long as the LP devs decree "this is the way it's done", that's more or less fine.
<Hobbsee> although that does cause trouble for the bug triagers, i concede
<sabdfl> kiko produced this: http://news.launchpad.net/general/of-bugs-and-statuses
<Hobbsee> sabdfl: yes.  havent you seen the mailing list thread after it?
<sabdfl> which doesn't really do as neat a job of confirmed vs triaged as Amaranth did above
<sabdfl> Hobbsee: i've heard of this thread
<sabdfl> BenC: why don't we generally go with upstream alsa, rather than putting it in backports?
<Hobbsee> sabdfl: then you'd know that there's reasonable amounts of disagreement and discussion about the statuses :0
<bdmurray> I think it will become much harder for a triager to determine when a bug is triaged.
<pitti> Keybuk: any idea how to interpret "/dev/disk/by-id/dm-uuid-LVM-KJO4ugYyA4nFPEw5btZXayQjDRI8VPeP" ?
<bdmurray> And the concept behind the extra status was to offload some work from developers.
<BenC> sabdfl: if we had done it in time (for testing), I'd be happy to put it into linux-ubuntu-modules, but it's too late now
<Keybuk> pitti: devmapper device with the devmapper UUID LVM-KJO4ugYyA4nFPEw5btZXayQjDRI8VPeP
<pitti> Keybuk: ah, that's from 65-dmsetup.rules:ENV{DM_UUID}=="?*", SYMLINK+="disk/by-id/dm-uuid-$env{DM_UUID}"
<BenC> sabdfl: I've never liked the idea of tracking such a huge set of modules out-of-tree, but things the way they are, we made this last minute decision to handle it this way
<Keybuk> pitti: right
<BenC> sabdfl: probably be something we do from the start past gutsy
<Keybuk> it's part of an LVM wotsit
<Keybuk> LVM passes in the LVM UUID when it sets up the device
<Keybuk> probably the VG UUID
<Keybuk> (rather than the UUID of the filesystem *inside* the VG)
<pitti> Keybuk: so, I wonder why I don't get proper /dev/disk/by-uuid/ in the installer for LVMs
<Amaranth> bdmurray: I honestly get annoyed with someone other than me or mvo sets a compiz bug to triaged
<cjwatson> bdmurray: which in many cases is a bit misguided anyway - until developers can count on 100% triaging coverage, they'll often look at everything coming in anyway :-)
<Keybuk> pitti: no filesystem UUID available at the point the device is created?
<Keybuk> pitti: e.g. because it's formatted after being set up? :p
<cjwatson> (not that it's not a noble goal)
<Amaranth> bdmurray: It seems like the QA team just assumes valid output from apport is enough to mark a crash bug as triaged
<pitti> Keybuk: that's most likely
<BenC> sabdfl: kind of the obvious thing when most sound bug reports end with "it works with current alsa" :)
<cjwatson> BenC: didn't we have to back out current alsa because it regressed a bunch of intel chips?
<pitti> Keybuk: can it be poked somehow? (udevtrigger doesn't)
<cjwatson> or did I misunderstand that reversion?
<Keybuk> pitti: udevtrigger should poke it
<Keybuk> though you might have to poke something surprising
<Keybuk> echo -n change > /sys/block/dm-NN/uevent
<Keybuk> ?
<BenC> cjwatson: we backed out snd-hda-intel because of that...we couldn't just include that one module without a lot of core alsa API changes
<pitti> Keybuk: ah, wait, i was still in chroot /target
<BenC> cjwatson: hence the reason for doing a full backport
<pitti> Keybuk: yes, udevtrigger in the outside chroot did the trick
<cjwatson> BenC: oh, it was because we tried to pick and choose? ok
<bdmurray> cjwatson: Right, but the triaged bugs should be a better starting point.
<BenC> cjwatson: right
<cjwatson> bdmurray: yeah, it depends on the time of the release cycle
<pitti> Keybuk: thanks
<cjwatson> bdmurray: early on that makes sense - near the end response time is key
<BenC> snd-hda-intel is the fastest moving target in alsa
<BenC> all the new codecs and wiring for every freaking new laptop ever made (AMD and Intel)
<BenC> snd-hda-intel needs to be renamed to snd-hda...nothing Intel specific about it
<bdmurray> Amaranth: What detailed output should the QA team be looking for to distinguish between a crash report that should be Triaged vs one that is Confirmed?
<Amaranth> bdmurray: I think it'd require knowledge of the compiz code for compiz bugs
<Amaranth> bdmurray: For other packages I dunno, I don't know their code :P
<bdmurray> Amaranth: Then it seems to me that we have limited the work the QA team can do if all compiz crashes should be confirmed.
<cjwatson> bdmurray: my understanding of http://news.launchpad.net/general/of-bugs-and-statuses is that the QA team shouldn't generally set Triaged?
<cjwatson> (which makes it a very misleading status name, but ...)
<Keybuk> bdmurray: what work do you do on other packages to distinguish between Confirmed and Triaged?
<Keybuk> do you have any examples how you differ the statuses?
<Amaranth> Confirmed should be locked so users can't confirm their own bugs
<Amaranth> That is so annoying
<StevenK> It's much better when people file -uvf reports, and then another person "Hey, wow, great! I want this, so I'm going to set to Confirmed" - which for a motu-uvf request means "Two people have looked at this and rubber stamped it"
<Hobbsee> Keybuk: the equivalent of the australian decision dice
<bdmurray> Keybuk: because anybody can confirm the bug it is possible that someone may have confirmed an X bug without obtaining the necessary log and configuration files.  So after confirming that everything is there and that the reporter is not making a mistake I would set the status to triaged.
<Kopfgeldjaeger> pitti: any progress with the cryptsetup stuff? can i help you somehow?
<soren> pitti: So, the dovecot update passes the tests (when the person doing the tests is not an idiot), and I've tested the dovecot-{pop3,imap}d.post{inst,rm} magic quite a bit. What else do I need to do?
<Keybuk> bdmurray: so if use of Confirmed was limited to members of qa, assignee or package contacts - that would solve the problem?
<bdmurray> cjwatson: I disagree with what kiko wrote up about triaged
<Amaranth> bdmurray: I suppose Triaged could mean "the QA team thinks this has enough info" then I could bounce the bug through Incomplete or Confirmed as needed
<Keybuk> (or we need YALS between Triaged and In Progress ... maybe "Understood"?)
<bdmurray> Keybuk: I don't think limiting the way people can help out even more is the solution
<pitti> Kopfgeldjaeger: I have another attempt in the pipeline
<Keybuk> bdmurray: my concern is that there doesn't appear to be any difference between those two Statuses
<Keybuk> can anyone set Triaged?
<pitti> soren: sounds fine
<Hobbsee> Keybuk: no
<Amaranth> Keybuk: no
<Keybuk> who is it limited to?
<Hobbsee> ubuntu-q
<Hobbsee> a
<Keybuk> Hobbsee: can the assignee or package contacts set it?
<Hobbsee> no idea, tbh
<Amaranth> Which is somewhat annoying, I joined the QA team just so I could manage compiz bugs
<bdmurray> I don't think so
<Keybuk> hmm
<Hobbsee> Keybuk: the package contacts cant select importance, so i doubt they can do that either.  apparently that's a lp "feature" - although i've long debated how it isnt.
<Hobbsee> (there's a bug open, but little to no progress on it)
<mvo> glatzor!
<bdmurray> Amaranth: In regards to has enough info yes.  If there wasn't enough info than debugging documentation for the QA team needs to be improved.
<Kopfgeldjaeger> pitti: um... hum? im not thaat familar with english phrases :/
<glatzor> evening mvo!
<Amaranth> bdmurray: I can just say generically "these things are useful" but then some bug report comes that needs some very specific info
<cjwatson> Kopfgeldjaeger: "in the pipeline" => "on its way"
<Amaranth> bdmurray: Or would you rather waste time getting all possible stuff from the user at once even though almost none of it gets used?
<pitti> Kopfgeldjaeger: I'm on it
<Riddell> heno: how was your kubuntu upgrade?
<Amaranth> We need something like bug buddy's scripting
<cjwatson> there is a point when QA debugging shades over into "developer needs to sit and stare at the code and then ask the user very specific questions to try to isolate codepaths"
<bdmurray> Amaranth: I think getting what is necessary most of the time is appropriate it.
<Amaranth> So if you file a bug on a certain package it can have a script associated with it that apport runs to collect package-specific info automatically
<Kopfgeldjaeger> ok, thanks ;)
<cjwatson> which I don't think indicates that the documentation needs to be improved
<bdmurray> cjwatson: absolutely, I meant that if there is a trend of bugs being incorrectly triaged
<cjwatson> right ...
<glatzor> mvo: sorry, but I cannot come to the ubucon, since I have got night shift before :/
<bdmurray> Amaranth: apport does have per-package hooks for crash reports
<Amaranth> bdmurray: Oh? I need to figure out how to write one of those
<mvo> glatzor: oh :/
<Amaranth> bdmurray: Although I suppose it's not as nice as 'attach this file to the bug report'
<bdmurray> Amaranth: I'm not sure what you mean but it auto uploads whatever files you want
<Amaranth> bdmurray: ah, cool
<bdmurray> For ubiquity it grabs stuff like /var/log/partman
<Amaranth> I'll just setup apport to upload files for all the info we need from a crash report then
<bdmurray> Amaranth: That'd be great
<mathiaz> Keybuk: During an upgrade to gutsy with update-manager yesterday, I was hit by bug 115616.
<ubotu> Launchpad bug 115616 in evms "Device-mapper errors: dm-linear, lookup failed" [High,Fix released]  https://launchpad.net/bugs/115616
<heno> Riddell: not so good. I'm filing a bug
<mathiaz> Keybuk: However update-manager never prompted me to remove the evms package (which I did afterwards).
<mvo> mathiaz: could you please put your /var/log/dist-upgrade/* files somewhere?
<mathiaz> mvo: sure.
<mathiaz> mvo: The reason I think is bebause there was a failure on python-apt.
<bdmurray> heno: Just one - that's good. ;)
<mvo> mathiaz: that would a error with dpkg-querry form pycentral I guess?
<mvo> mathiaz: anyway the logs are interessting
<heno> bdmurray: yeah, just crashed once
<mathiaz> mvo: yes.
<mathiaz> mvo: http://people.ubuntu.com/~mathiaz/dist-upgrade/
<mvo> mathiaz: checking, thanks
<mathiaz> mvo: let me know if you need something else.
<Riddell> bdmurray: can you give me sru verification on 117731?
<bdmurray> Riddell: I'm working on that I am downloading a Kubuntu Feisty image
<Pierre> Hi
<Pierre> http://pierre.libgd.org/update_gusty_bug_size.png
<Amaranth> mvo: looks like the size calculation is a little screwy
<Pierre> the required size in /boot was first 115MB, then I removed 2.6.17 and now I still have this error, but different size
<mvo> Pierre: looks not too bad to me, what do you have still installed in /boot
<Pierre> nothing but feisty stuff
<mvo> Pierre: i mean, how many kernels
<mvo> Pierre: it looks like all that is needed is to remove one old feisty kernel
<heno> Riddell, mvo: bug 150162
<ubotu> Launchpad bug 150162 in update-manager "update-manager feisty-> gutsy besta failed with instruction" [Undecided,New]  https://launchpad.net/bugs/150162
<pitti> yay!
<pitti> soren, cjwatson: got it!
* soren hugs pitti
<soren> pitti: What was/is it?
<Pierre> mvo: trying
<pitti> soren: calling udevtrigger did the trick
<mvo> heno: thanks, Failed to fetch http://wine.budgetdedicated.com/apt/dists/feisty/main/binary-i386/Packages.gz 403 Forbidden
<Pierre> mvo: but still looks weird :)
<soren> pitti: That's... odd, isn't it?
<mvo> Pierre: what exactly? the error message, the fact that it requires this amount of memory?
<Pierre> mvo: both
<heno> mvo, Riddell: woops. it's bug 150612
<ubotu> Launchpad bug 150612 in update-manager "[kubuntu]  Method http has died unexpectedly" [Undecided,New]  https://launchpad.net/bugs/150612
<iwj> lool: I'm not subscribed to ubuntu-desktop right now but I'll reply anyway.  Thanks, and sorry for the delay.  (I've been struggling with rsync this afternoon.)
<Pierre> mvo: notice the background, df -h was run, the /boot partition is 95MB
<Pierre> mvo: the 1st error asked me to free 115MB there
<pitti> soren: no, it isn't actually; the devices are formatted after creating them
<Riddell> heno: that's a new one to me
<Riddell> heno: did your network go down?
<soren> pitti: so why does the .bak work?
<mvo> Pierre: there may be a error left in the size calculation, if file a bug, please include "ls -l /boot " and df -h and the file in /var/log/dist-upgrade/main.log
<Pierre> mvo: but removing one more old kernel did it. Amaranth is right, it is only about the size calculation being wrong :)
<heno> Riddell: not that I know. It works now. How could I check?
<pitti> soren: that bit is still a mystery to me
<Pierre> mvo: ok
<Pierre> Amaranth: mvo: thx for the help
<Pierre> upgrading, bbl :)
<mvo> Pierre: each kernel requires ~10mb for its initramfs, on update each already existing initramfs gets backed up (that requires an additional 10mb)
<Riddell> heno: dunno, try it again maybe
<heno> Riddell: ok, I have the system up now. Any logs I should gather before rolling it back to try again?
<soren> pitti: Ah, ok.
<heno> so network activity logs?
* soren goes to dinner
<heno> *some
<soren> bbia few hours.
<mathiaz> soren: thanks for the dovecot upload
<mathiaz> soren: do you think it's worth forwarding to debian ?
<soren> mathiaz: Thanks for doing most of the work :)
<pitti> soren: I prepare an updated base-installer and do a full test install including UI, for final testing
<soren> mathiaz: Yes, very much so.
<Riddell> heno: don't think so, mvo might know
<soren> pitti: Rock!
<mathiaz> soren: I'll look into that then.
* soren *really* goes to dinner
<bdmurray> mvo: I had an automatic crash report when updating Edubuntu to Gutsy regarding gaim-data however apport would not let me report because it was about and invalid version.  Is that something you would want to look at?  If so which information would you want?
<pitti> mvo: is the update-notifier "disable apport" still on your list, or shall I do it?
<mvo> bdmurray: the files in /var/log/dist-upgrade/* would be the ones i'm interessted in
<bdmurray> mvo: okay, the apport crash report is unnecessary?
<mvo> bdmurray: as far as I'm concerned yes, the logs contain all interessting bits
<pitti> cjwatson, soren: I attached a base-installer debdiff to bug 144390; WDYT?
<ubotu> Launchpad bug 144390 in debian-installer "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,In progress]  https://launchpad.net/bugs/144390
<lool> iwj: No problem; as you're the person who brought this up, I thought you might have some ideas on how to best handle this
<cjwatson> pitti: I would prefer bind-mounting all of /target/dev rather than just .../disk
<cjwatson> pitti: there's some tab/space damage in there too
<cjwatson> pitti: also please commit that to bzr if you upload it
<pitti> cjwatson: XS-Vcs-Svn: svn://svn.debian.org/d-i/trunk/packages/base-installer
<pitti> hmm
<cjwatson> pitti: but I'm OK with it; I think it's a bit weird that udev doesn't notice the partitioning stuff for itself, I thought we already told it to update, but whatever
<mvo> heno: re #150612> was a crash file produced? did you hit ctrl-c by any chance ;) ?
<pitti> cjwatson: all of /dev/ seems more intrusive, but it does make some sense, yes
<cjwatson> pitti: yeah, it's wrong, I'll fix it after gutsy
<cjwatson> bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/base-installer/ubuntu
<pitti> cjwatson: thanks
<cjwatson> it's more intrusive, but it also feels less likely to break than bind-mounting just a bit of /dev
<pitti> cjwatson: ok, I do a test with bind-mounting the full /dev
<pitti> and fix the tabs
<heno> mvo: I did hit 'Right-ctrl' at some point which is the key used to recapture focus from vbox
<heno> mvo: there is indeed a crash file. attached
<mvo> heno: cool, thanks
<heno> or, will be soon
<pitti> cjwatson: thanks for review; new patch attached (now with UNRELEASED, will commit to bzr and fix once my test finished)
<mvo> heno: I have a idea what might have caused this. the interessting questions is what triggered it for you and why I have not seen it myself yet
<glatzor> thanks riddell for guidance
<cjwatson> pitti: looks good
<heno> mvo: ok. crash log really attached now
<heno> annoying that the crash log is only readable by root, so you have to chown or chmod to upload it
<pitti> cjwatson: thanks
<mvo> pitti: will the apport retracer pick up a manually uploaded crash file (bug #150612) automatically?
<ubotu> Launchpad bug 150612 in update-manager "[kubuntu]  Method http has died unexpectedly" [Undecided,New]  https://launchpad.net/bugs/150612
<pitti> mvo: unfortunately not
<pitti> mvo: you have to pipe them through the UI once, since they are incomplete otherwise
<pitti> mvo: and that one doesn't have a core dump, so no retracing possible
<bdmurray> mvo: it is bug 150626
<ubotu> Launchpad bug 150626 in update-manager "gaim-data failed to upgrade during dist upgrade of Edubuntu to Gutsy" [Undecided,New]  https://launchpad.net/bugs/150626
<mvo> pitti: no? http://launchpadlibrarian.net/9883209/_usr_lib_apt_methods_http.0.crash <- that one seems to have a field CoreDump
<rexy_> tepsipakki: i tried the ati-update for this morning, it fixed the garbled screen for me but it still has some issues, crash on relog via gdm/compiz , not sure where on LP to file that under and what info to attach?
<heno> mvo: another data point I had had kde sticky keys turned on, which is not so common, and may have done unpredictable things with Ctrl+<other key> when combined with vbox
<pitti> mvo: right, I missed that
<mvo> pitti: heno had the bug, I would love to get the full backtrace, will it be enough if he calls /usr/share/apport/apport-gtk?
<pitti> mvo: yes; you can call it with -c /path/to/crash/file, or touch the .crash file to get the UI again
<pitti> mvo: I think I'll do the update-notifier change now, if you are fine with that?
<mvo> heno: ----^ could you please do that ?
<mvo> pitti: new update-notifier is already uploaded
<heno> do I need to install that first (this is kubuntu)
<pitti> mvo: oh, you rock
<heno> ?
<pitti> heno: s/gtk/qt/ will work, too
<heno> ok, cool
<pitti> Riddell: can you please change adept-notifier to not report apport crashes by default?
<heno> pitti: where do I find the output of that? (I doesn't offer to upload it)
<pitti> heno: oh, that's strange; what does it say?
<heno> pitti: nothing at all
<pitti> heno: you might alternatively try apport-cli -c /path/to/crash/file if the Qt UI is broken somehow
<pitti> heno: did you call it with -c? or without arguments?
<heno> ok
<iwj> lool: cat -> pigeons, thanks.
<heno> pitti: ok, let me retry, sorry
<pitti> heno: if you call it without arguments, you need to touch the .crash file before
<pitti> heno: (and then apport shuold come up automatically)
<pitti> seb128: ah, interesting feedback on bug 133567
<ubotu> Launchpad bug 133567 in linux-source-2.6.22 "nautilus hangs on accessing vfat drives - statfs() blocks for a long time" [Medium,Confirmed]  https://launchpad.net/bugs/133567
<seb128> pitti: indeed
<pitti> seb128: so let's revert the natuilus hack, and instead I'll fix hal to use that option instead maybe?
<seb128> pitti: that looks like a good idea yet
<seb128> yes
<heno> mvo, pitti: here we are; bug 150630
<ubotu> Launchpad bug 150630 in apt "[apport]  http crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New]  https://launchpad.net/bugs/150630
<pitti> cjwatson: argh, I'm a muppet; unmounting /dev in install_extras() is too early, since as you said, those extra packages are installed later
<pitti> cjwatson: so we either move that to a different place, or not unmount it at all?
<tepsipakki> rexy_: search x-x-v-ati bugs if you find a match.. we will clean it up after gutsy has been released, and forward upstream those that are valid
<lool> iwj: I'm afraid i'll need help decoding "cat -> pigeons"; I like Agatha Christie, but I'm not sure I'm making the right connection
<iwj> I have put the cat amongst the pigeons.  It's a metaphor for err, stirring up a hornets nest.
<iwj> Saying or doing something likely to cause commotion etc.
<iwj> You'll see what I mean when you read my message ...
<lool> Ok; I tried googling for the expression, but I'm afraid Google isn't of much help to improve one's english
<lool> *English
<lool> Perhaps Amazon.com, Answers.com, Yahoo.com or Wikipedia would be better?  ;-)
<mc44> lool: urbandictionary.com ;)
<lool> mc44: That's not included in Firefox or deskbar-applet!
<pitti> cjwatson: new patch attached, take III
<pkern> mjg59: The "disable the fglrx module" is not a viable workaround. IMHO 2d rendering got significantly worse and I *think* I had xvideo before.
<iwj> lool: ROTFL
<mjg59> pkern: Shrug.
<mjg59> Little we can do at this point.
<pkern> I still don't get why a SLAB flavour was refused but I don't think it's a pleasure to run Gutsy on >R5xx at this point but well.
<Riddell> heno: install what?
<pkern> There is still no official response from the kernel team.
<pkern> Which makes me sad too.
<mjg59> pkern: Because a SLAB flavour would be insane
<rexy_> tepsipakki: am looking at it, noticed you reffered me to 150278, so i'll post there.
<iwj> lool: Anyway, I have to go and find my dinner now.  I'll keep an eye on that thread.  Thanks for bringing it up.
<lool> iwj: bon apptit
<pkern> mjg59: At this point: Yeah, probably.
<mjg59> No, at any point
<pkern> It's not that I hadn't spoke up earlier.
<heno> Riddell: hm? context?
<pkern> mjg59: Technical point of that?
<pkern> mjg59: SLAB ran fine for years.
<mjg59> We're not offering multiple flavours based on different memory allocators
<Keybuk> linux-image-2.6.22-config-69efa2c20c510e0f0416c9e254c706899cbcefbd
<mjg59> The number of flavours we already have is fairly unmanigable
<Keybuk> (where the latter is the sha1sum of the config :p)
<mjg59> (urgh, spelling)
<Hobbsee> bad keybuk!  :P
<Keybuk> (that's actually not a bad idea for user-generated kernel images)
<StevenK> pitti: virtualbox-ose-modules failed on amd64, and built on i386 - I'll fix it when I wake up and bug you about it when you surface tomorrow.
<sladen> Keybuk: config + time_t
<pitti> StevenK: that's fine; there's still plenty of time to fix universe
<sladen> teach grub about UUIDs, then it can go looking across all the available partitions for a kernel with the right UUID
<Riddell> heno: never mind, seems not to have been for me
<superm1> cjwatson, I was trying to debug further why BulletProofX wasn't working on the mythbuntu live disks and discussing with bryce a little bit.  It appears that the results from casper-reconfigure xserver-xorg apply fine to the live env's debconf database, but are never replicated over to the resultant system.  Could you speak to what mechanism is supposed to be handling that?
<pochu> should I poke anybody if a package in universe failed to build because of unmet dependencies of its build-dependencies? It was when beta, and it should be Ok now.
<Hobbsee> pochu: it usually gets given back
<pochu> BTW the package is listen, and it built fine on 4 archs, and failed on 3: https://edge.launchpad.net/ubuntu/+source/listen/0.5-4ubuntu3
<pochu> Hobbsee: automatically?
* Hobbsee bets one is hppa
<Hobbsee> oh, it seems it isnt
<pochu> Hobbsee: hppa built fine :p
<pochu> Although it's possible it was in DEPWAIT
* Hobbsee kicks edge
<pochu> dunno why the others weren't
<Hobbsee> that's a failed to build.  that's not depwait.
<Hobbsee> which means it'll need a manual giveback
<Hobbsee> assuming the package isnt broken
<pochu> Yeah, but it failed because its build-dependencies couldn't be installed because its dependencies weren't satisfied...
<Hobbsee> so the answer is yes, you want to ask for a giveback of listen on {insert arches here}
* pochu looks for an archive admin to give back listen on amd64, ppc and sparc :-)
<Hobbsee> you're looking for a buildd-admin
<pochu> Hobbsee: should that be enough, or is there any kind of policy such as filling a bug report?
<Hobbsee> nah
<Hobbsee> no idea if any are around, though
<pochu> Mithrandir: ^ if you have a moment. Thanks
<Lure> mjg59: what is status of ubuntu-laptop-mode - it wants to remove acpi-support here...
<Pierre> mvo: looks like one already met this issue: #104337
<Hobbsee> mvo: did you ever end up making the dist-upgrader not upgrade with automatix installed?
<mjg59> Lure: Yes. Don't use it right now.
<mjg59> I haven't had time to sort that out.
<Lure> mjg59: ok, and laptop-mode-tools is still not good, right?
<Pierre> mvo: sounds weird that it is seen as a feature request...
<Riddell> mvo: is the dist upgrader on the CDs?
<mvo> Riddell: yes
<mjg59> Lure: laptop-mode-tools is what should be used for the moment
<mvo> bug #104337
<ubotu> Launchpad bug 104337 in update-manager "[MASTER]  /boot free space check message misleading and space requirement too big" [Low,Fix committed]  https://launchpad.net/bugs/104337
<Riddell> mvo: where do I find it?
<mvo> Riddell: dists/stable/main/dist-upgrader/binary-all
<mvo> iirc
<Riddell> mvo: it's not there
<mvo> Riddell: only on the altnerative cd
<Riddell> mvo: oh, duh, of course
<mvo> Riddell: it does not make a lot of sense on the desktop CD because there are no packages (or almost no packages)
<Riddell> sure
<tepsipakki> rexy_: you had the same symptoms as reported in that bug, but it's already fixed as you said :)
<Riddell> mvo: are we going to use meta-release-proposed for RC?
<rexy_> tepsipakki: logging out back to gdm crashes X still, it half paints the gdm images but stops
<rexy_> simply killing X and restarting it via startx does not have that problem though
<rexy_> altough admitedly that's not listed in that bug
<pitti> cjwatson, soren: bug updated, this is a mess :/ I demoted partman-auto-crypto again to disable that feature
<tepsipakki> rexy_: yes, maybe open a new one then..
<tepsipakki> rexy_: and attach xorg.conf, Xorg.0.log and 'lspci -vvnn'
<rexy_> tepsipakki: ok, thanx, i'll see if i can find a current bugrp on that or file a new one, thanx
<tepsipakki> rexy_: sure, np
<mvo> Riddell: that is a good idea, yeah, lets do that
<superm1> Riddell, any chance you would be able to pull the fix from svn for this bug: https://bugs.edge.launchpad.net/ubuntu/+source/kde-guidance/+bug/139603 ?  It is causing a few other odd ones to crop up in ubiquity for mythbuntu
<ubotu> Launchpad bug 139603 in kde-guidance "installer crashed just after vnc server url return 404 error" [Undecided,New] 
<mvo> superm1: sorry that I didn't managed to followup on the install issue with python-apt, what is the current status there?
<superm1> mvo, give me a moment to glance back at the code and then i can tell you what we were thinking last
<mvo> superm1: so its still a problem?
<superm1> mvo,  well a few things.  in short yes
<superm1> mvo, if i remove the call for cache.open(None), it appears that things work correctly unless a package really is broken
<superm1> mvo, if you look at http://codebrowse.launchpad.net/~ubuntu-installer/ubiquity/trunk/annotate/cjwatson%40canonical.com-20071007200415-j69ftz0zr82h58w4?file_id=copy.py-20051205084030-2802314aaac6fca0 around line 1418
<superm1> removing that call for cache.open(None) causes that broken packages list to not populate correctly
<superm1> in line 1422
<mvo> superm1: yeah, that is sort-of-expected, libapt needs to sync itself with /v/l/d/status after a commit()
<superm1> but if i leave the cache.open(None), it has random tendencies to hang still.
<mvo> ok
<superm1> mvo, so does a sleep need to be put in there for some length of time?
<superm1> to work around that, or is there a call to wait for?
<mvo> superm1: out of curiosity, could you try to replace "cache.open(None)" with "cache = apt.Cache()" ?
<Keybuk> doko: err, is python-mode bust or is it just me?
<Keybuk> I opened a .py file and it stayed in Fundamental
<mvo> Keybuk: you need to purge python-mode
<superm1> mvo, not immediately at this moment (i'm on campus), but i'd be glad to when i get home and have access to a VM again
<mvo> Keybuk: the latest emacs has a build-in one
<superm1> mvo, should that have the same result?
<mvo> Keybuk: and they seem to conflicts for some reason
<Riddell> superm1: ubiquity uses guidance?
<mvo> superm1: yes, I'm curious if you see the hang with this too
<doko> Keybuk: emacs22?
<pitti> hm, shuoldn't emacs22 Conflicts: python-mode then?
<superm1> Riddell, ubiquity-frontend-mythbuntu does.
<mvo> superm1: or if it goes away. if so, I have at least a clue where to start debugging
<superm1> mvo, i'll check later and catch up with you tomorrow on it then
<Keybuk> doko: emacs21-nox
<mvo> superm1: sure, thanks
<Keybuk> we don't *have* emacs22 do we?
<doko> we do
<mvo> ignore me then, I was thinking of emacs22
<Keybuk> oh, wow
<Keybuk> I didn't even know that had been released
<doko> well, usually you only need to check for new emacs releases once a decade
<Riddell> superm1: interesting.  well that fix has been in the archive for 10 days
* Keybuk syncs emacs22-common-non-dfsg
<superm1> Riddell, hm that is particularly interesting then, because ubiquity on our beta disk was built right about then.  I'll have to check the version of guidance that is on the disk
<superm1> Riddell, do you know what version the commit was added offhand?
<superm1> Riddell, i'm guessing 0.8.0svn20070928-0ubuntu1
<pitti> Keybuk: it's the default for quite some time, and emacs21 is in universe now
<Riddell> superm1: yes
<pitti> Keybuk: the 'emacs' metapackage pulls it in, too
<superm1> Riddell, okay, i'll double check with that tonight
<Riddell> mvo: does dist upgrade tool work without an internet connection?  it seems to add feisty-backports as a source
<mvo> Riddell: it should work, yes. but only if you use it from the CD, either via "sudo sh /cdrom/cdromupgrade" or when update-notifier ask if you want to perform a upgrade
<mvo> Riddell: it will ask you if you want to use network or not in this case
<bigon> hi, is it still possible to sync gtk-doc from debian (new upstream version)? I've an issue with the version currently in gutsy and the version of debian fix the problem
<RicardoPerez> pitti: hi! is there any way to translate the gnome-access-guide via Launchpad?
<sladen> RicardoPerez: is it in gnome-user-docs?
<RicardoPerez> sladen: yes, but gnome-user-docs has no templates at all in Launchpad...
<RicardoPerez> sladen: see https://translations.launchpad.net/ubuntu/gutsy/+source/gnome-user-docs
<superm1> Riddell, actually it looks like our disk was mastered with the newer version.  i'll have to poke around with that bug then and see what else is breaking
<superm1> thanks
<sladen> RicardoPerez: there's some commentary on http://www.mail-archive.com/launchpad-users@lists.canonical.com/msg02064.html perhaps mdke or the #ubuntu-docs can give you the final outcome
<mdke> RicardoPerez: yes, I've been discussing with danilo a way to try and do it but we haven't reached a solution yet
<mdke> (thanks sladen)
<RicardoPerez> mdke: oh, thanks! I only want to translate one only string: "Assistive Tools", which shows in the Yelp main menu... It's the only untranslated string in the Ubuntu help center
<mdke> RicardoPerez: damn, yes
<RicardoPerez> mdke: can you include the translation in the final gnome-user-docs?
<RicardoPerez> mdke: it's only one string...
<RicardoPerez> mdke: my goal is to have the Yelp main string fully translated into Spanish...
<mdke> RicardoPerez: it's a worthy goal; I'd like to find a way for each language to do it though
<RicardoPerez> mdke: of course, I know that including my string translation as a patch is that... a patch, not a solution
<mulima> hi
<mulima> i couldn't play mp3 files using gstreamer appz is there a known bug about this issue ?
<mulima> i have all gstreamer plugins isntalled and i get this error with totem "Message: don't know how to handle application/x-id3"
<mulima> using gutsy
<RicardoPerez> mdke: what about send a proposal in ubuntu-translators mailing list in order to get the string "Assistive Tools" translate in the main languages, and then to incorporate the translations directly into the package?
<Keybuk> hmm
<mdke> RicardoPerez: I'll mail the list in a bit. do you know how to manipulate po files and such?
<Keybuk> with emacs22 and no python-mode, I get no indenting
<donspaulding> mulima: read the topic, then take that question over to #ubuntu+1
<RicardoPerez> mdke: I do that regularly with gtranslator...
<mulima> donspaulding, yes sorry
<RicardoPerez> mdke: and then to generate the corresponding .mo file with msgfmt
<mdke> RicardoPerez: if you do, grab the pot file from http://launchpadlibrarian.net/9836563/gnome-access-guide.pot and the es po file from LP at http://tinyurl.com/2yuggw; merge and send me the updated po file
<RicardoPerez> mdke: ok, i'm doing that just now
<mdke> apparently diff doesn't work properly on po files, so best just to send me the whole new po file
<RicardoPerez> mdke: one question: how can I merge one .pot and one .po files?
<mdke> I don't know
<RicardoPerez> mdke: ummm, ok, i'm on the way
<donspaulding> Keybuk: I was trying to mimic your minimal debian/rules file for a meta package, but debuild keeps failing with the message here: http://pastebin.org/4431
<donspaulding> got a minute to take a look?
<mvo> heno: if you could test wesnoth again with the latest compiz, that would be cool. please also check if /apps/compiz/general/screen0/options/unredirect_fullscreen_windows is set (gconftool -g /apps/compiz/general/screen0/options/unredirect_fullscreen_windows)
* Keybuk 1 - python.el 0
<heno> mvo: mind if I check it at the end of my day today? It may well crash my whole world here
<Keybuk> donspaulding: why do you have %s in debian/control? :)
<ion_> donspaulding: Btw, i implemented the same thing a bit differently: http://codebrowse.launchpad.net/~ion/+junk/ion-meta/files
<donspaulding> doh!  I should've seen that, I just thought the error message didn't pick up the character it was choking on correctly, wasn't looking for an actual % sign, sorry.
<donspaulding> ion_: I'll take a look
<Keybuk> donspaulding: sometimes error messages are helpful, rather than a hinderance :p
<donspaulding> yeah, I'm just so used to looking at python tracebacks where error messages complaining about %s really mean they're choking on a variable that was supposed to be in %s.
* donspaulding really needs to learn bash
<donspaulding> ion_: where do you end up specifying all the ${ion-base:Depends}  lines at?
<ion_> donspaulding: Theyre read by debian/rules from ion-base in the packages root directory.
<donspaulding> gotcha, so that way you can just keep a flat text file with all the dependencies, interesting
<ion_> Yeah, with comments etc.
<donspaulding> ion_: well you just rendered several hours worth of work useless.  thanks for that :-P
<RicardoPerez> mdke: i think i have it now
<RicardoPerez> mdke: can I send you and try it?
<donspaulding> ion_: it's nice how that takes dependencies out of the control file, makes editing them programmatically much easier :-)
<mdke> RicardoPerez: alright, tell me how you did it
<RicardoPerez> mdke: using the msgmerge tool
<RicardoPerez> mdke: msgmerge es.po gnome-access-guide.pot > final.po
<RicardoPerez> mdke: and then translating the final.po file using gtranslator
<mdke> that sounds right
<mdke> RicardoPerez: if it works, I can't promise that the release managers will allow another upload of the package, but we'll try
<RicardoPerez> mdke: ok, great!
<RicardoPerez> mdke: how can i send you? via email?
<mdke> sure
<RicardoPerez> mdke: ok, just now
<Mithrandir> pochu: given-back
<RicardoPerez> mdke: i just email you with the updated es.po
<soren> pitti: Aw... I'm really sorry to see it go.
<mdke> RicardoPerez: fine, I'll see if it works later
<RicardoPerez> mdke: great, email me if there's news :) thanks a lot!
<mdke> thanks to you
<pochu> Mithrandir: ty
<geser> pitti: is it worth to merge libservlet2.4-java 5.0.30-6 right now? it contains a fix for CVE-2007-4724
<ubotu> Cross-site request forgery (CSRF) vulnerability in cal2.jsp in the calendar examples application in Apache Tomcat 4.1.31 allows remote attackers to add events as arbitrary users via the time and description parameters. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4724)
<cjwatson> superm1: I believe I answered that question a day or two ago; perhaps you missed my reply
<superm1> cjwatson, that's possible.
<superm1> which channel was it in?  I'll look through logs
<cjwatson> superm1: casper/ubiquity-hooks/20xconfig copies /etc/X11/xorg.conf over to the target system. It doesn't copy over the relevant bits of the debconf database because that isn't supposed to be necessary; if not copying bits of the debconf database is causing a problem, then that's a bug
<cjwatson> (was approximately my answer from the other day)
<superm1> that would be causing a problem (not copying over the relevant bits of debconf).  Since they aren't copied over, any effort to regenerate xorg.conf using dexconf will fail
<cjwatson> superm1: that's a horrible, horrible bug
<cjwatson> superm1: the debconf database is not supposed to be canonical in any way, shape or form
<cjwatson> superm1: the canonical thing is the configuration file on the filesystem, /etc/X11/xorg.conf
<superm1> cjwatson, then perhaps some of the underlying principles of BulletProofX have issues then.
<cjwatson> superm1: are you calling dexconf directly by hand?
<superm1> cjwatson, yeah i've called it by hand to verify this issue.
<cjwatson> superm1: I don't think that's a good idea - try dpkg-reconfigure xserver-xorg instead?
<cjwatson> I was under the impression that dexconf wasn't something you were typically supposed to call directly
<cjwatson> but rather something that the xserver-xorg maintainer scripts call, and that's just provided as a separate binary for debugging convenience
<superm1> cjwatson, that works properly and will generate a new xorg.conf properly.  the problem is that when a xorg.conf.failsafe is made for BulletProofX, it pulls the data from debconf
<superm1> i have only been using dexconf for debugging indeed
<cjwatson> superm1: I think we may be unable to fix this at this point for 7.10, and should revisit the problem for 8.04
<cjwatson> pitti: urgh, gross
<superm1> cjwatson, that's rather unfortunate.
<ivoks> mvo: there's a bug in latest upload of update-notifier - typo in schema
<cjwatson> pitti: another possibility: go back to the previous code in base-installer, reinstate the update-initramfs diversion in pkgsel, and change pkgsel to run update-initramfs with a bind-mounted /dev (but the rest of pkgsel can run without that)
<superm1> cjwatson, since the new debconf pieces aren't copied over at all during the live install, what data *should* be in those debconf variables after you first boot into the new system?  The data gathered from the cdimage buildd's local machine?
<cjwatson> um, goodness knows, probably not very well-defined
<cjwatson> with the exception of the special uses to which the installer puts it, the contents of the debconf database aren't really expected to be well-defined outside maintainer script runs
<superm1> well i wonder if bryce is aware of the issues this can be causing then.  i'll discuss this more with him later
<cjwatson> in fact you're supposed (theoretically, it doesn't *quite* work right) to be able to nuke the db without much harm done - that's why it's in /var/cache
<superm1> i see
<superm1> would you be entirely opposed to adding a step to copy this debconf data over in ubiquity as an interim fix (provided it didn't break anything)?
<superm1> and then for 8.04 coming up with a better solution
<cjwatson>        You can also use debconf in  other,  standalone  programs.  The
<cjwatson>        issue  to watch out for here is that debconf is not intended to
<cjwatson>        be, and must not be used as a registry. This is unix after all,
<cjwatson>        and programs are configured by files in /etc, not by some nebu
<cjwatson>        lous debconf database (that is only a cache  anyway  and  might
<cjwatson>        get blown away). So think long and hard before using debconf in
<cjwatson>        a standalone program.
<cjwatson> ^-- debconf-devel(7)
<cjwatson> at this point I'm worried about the flakiness of such code in ubiquity too
<superm1> i understand.
<cjwatson> though it could be done, there's a copy_debconf function in bin/ubiquity which does this
<cjwatson> (actually I should get rid of that for exactly the same reasons, of course!)
<superm1> haha
<cjwatson> console-setup is part of the installer so there's some clash of assumptions there
<cjwatson> if a very small change to copy_debconf can make this work, I'd be prepared to upload that
<superm1> cjwatson, i'll see what i can come up with
<mvo> ivoks: *ick*
<cjwatson> if this only affects mythbuntu, though, I'd prefer it to be conditionalised for the mythbuntu frontend?
<cjwatson> better safe than sorry at this point
<superm1> cjwatson, i wouldn't expect it to only affect mythbuntu based on its basis
<superm1> cjwatson, but i'll check with bryce
<cjwatson> hmm, you're probably right
<cjwatson> I'd like to know a little more about how this failsafe stuff works, but we don't have a lot of time
<cjwatson> bryce: ^--
<mvo> ivoks: where is the typo?
<ivoks> mvo: line 7
<ivoks> iirc
<ivoks> <default>false/default>
<mvo> ivoks: thanks, fixing now
<ivoks> np
<pitti> geser: libservlet> please get it uploaded, if it has a minimal diff
<pitti> cjwatson: unfortunately that won't help
<pitti> cjwatson: the problem is that this is now a "damned if you do, damned if you don't" situation
<cjwatson> pitti: why won't it help?
<pitti> cjwatson: i. e. when running with bind-mounted /dev, libraw1394 will fail to install (and god knows what else), and without bind-mount, the next package which update-initramfs'es will trash it
<cjwatson> pitti: my suggestion was to bind-mount /dev just around the update-initramfs call
<cjwatson> pitti: specifically not around the whole of pkgsel
<cjwatson> pitti: diverting update-initramfs in pkgsel will ensure that it's not called when you don't expect it
<pitti> cjwatson: ah, I see what you mean
<cjwatson> and you can bind-mount /dev around things that update-initramfs in base-installer, just as before
<pitti> cjwatson: actually, wouldn't it be easier to use that finish-install hook of cryptsetup?
<pitti> cjwatson: this is done as a very last thing, after installing everything else, right?
<pitti> cjwatson: so this thing could bind-mount, update-initramfs, unmount
<pitti> cjwatson: that would avoid reverting the diversion fix, etc.; seems a little less intrusive to me
<cjwatson> the diversion change isn't a problem, I only did that for cleanliness
* Keybuk shakes his fist at Python's USELESS documentation
<Keybuk> the docs for the ElementTree API utterly fail to document the Element class
<cjwatson> pitti: well, whatever you want, I suppose that would work but it seems a lot more fragile
<pitti> cjwatson: ok, if you think so; I was just pondering the possibility
<cjwatson> you need to make sure there isn't *another* finish-install hook after it in order, and yet it still needs to be called before unmounting the CD (er, probably); and interesting things happen if the user goes back and forward in the installer menu in expert mode
<pitti> ah, I se
<pitti> e
<cjwatson> we had a security flaw in the past that only happened in the latter situation, iirc :)
<cjwatson> pitti: but it's true that solution would be a lot quicker, so ... up to you
<cjwatson> quicker to implement that is
<pitti> cjwatson: ah, I looked at r87 of pkgsel; reverting that and bind-mounting indeed seems easier
<cjwatson> that's the bunny
<donspaulding> Keybuk: Python's docs only *appear* useless when all you can see is the problem, once you understand the solution, the docs make perfect sense :-)
<mdke> like all good docs
<donspaulding> mdke: heh, yes, I suppose you could say other docs implement the "this is simply a reference for the Masters" documentation idealogy, but surely Python came up with it first.
<mdke> I don't know much about python, but from what I've seen in error messages, it's a general philosophy rather than just limited to the docs
<donspaulding> eh, it's fairly easy to get good at reading tracebacks and finding the problem, but some of the docs take "cryptic technical writing" to a whole new level.
<mdke> :)
<mdke> RicardoPerez: was "Herramientas de accesibilidad" the string you added?
<mdke> RicardoPerez: works :)
<geser> pitti: bug #150692 contains the debdiff for the merge (I need a sponsor for the upload)
<ubotu> Launchpad bug 150692 in libservlet2.4-java "[Merge]  libservlet2.4-java 5.0.30-6ubuntu1" [Undecided,New]  https://launchpad.net/bugs/150692
<RicardoPerez> mdke: yes! that's the string
<RicardoPerez> mdke: great!
<mdke> RicardoPerez: would you mind filing a bug on gnome-user-docs about that string being untranslated and subscribe me
<RicardoPerez> mdke: mmmm... yes, i'll do that
<mdke> thanks
<Keybuk> donspaulding: the trouble is it applies to all Python afaict
<Keybuk> nobody ever bothers to properly document an interface
<Keybuk> this is at its worst for bindings
<Keybuk> imagine, the python binding for a gnome api to talk to dbus
<Keybuk> it actually becomes a documentation black hole! sucking in other useful documentation from nearby and crushing it into nothingness
<RicardoPerez> mdke: thanks to you :)
<donspaulding> Keybuk: I imagine that's true for the majority of low-level-language to high-level-language bindings though
<donspaulding> not that that's an excuse for poor documentation
<Mithrandir> donspaulding: fwiw, I generally find Perl module docs quite useful.
<donspaulding> and python's claims to enhanced readability (which oftentimes obviates the need for much documentation) only stretch as far as you are writing in python.
<donspaulding> so I can see your problem
<donspaulding> Mithrandir: I don't do anything low-level, so it's going to be hard for me to get in an argument of Perl vs. Python regarding library api docs.
<donspaulding> Keybuk: is there an *easy* way I can include a python script in a meta package?  Can I just add a postinst script and a rules target?
<Keybuk> you can do whatever you want in your own packages :)
<Keybuk> you could write your postinst *in* Python :p
<donspaulding> and just have rules call it?
<Keybuk> rules is build-time
<Keybuk> postinst is install-time
<Keybuk> which do you want?
<donspaulding> postinst
<Keybuk> easiest way there would be to make your postinst a python script
<Keybuk> otherwise you'd have to install the script somewhere and call it from postinst
<Keybuk> which gets to be a bit of a pain
<Keybuk> since your meta package would ship executables
<donspaulding> ok, I have a meta-package that results in about 6 binaries, how do I include a postinst in just one of them?  or do I only get one postinst for the meta?
<Mithrandir> put it in debian/binarypackagename.postinst
<Keybuk> depends how you made your meta package
<Keybuk> whether you're using debhelper, etc./
<RicardoPerez> mdke: done :)
<Keybuk> (if you just copied mine, just name it as tollef suggests)
<RicardoPerez> mdke: https://bugs.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/150696
<ubotu> Launchpad bug 150696 in gnome-user-docs "[Gutsy]  "Assistive Tool" string untranslated" [Undecided,New] 
<donspaulding> I'm using ion's CDBS rules script and using debuild
<Keybuk> yeah, same name then
<donspaulding> so just write a python script that shebangs /usr/bin/python and name it binaryname.postinst?  That's really all there is to it?
<Mithrandir> donspaulding: yes, and make sure you handle the different values you can be called with.
<Mithrandir> (you can find those in the Debian policy manual)
<soren> donspaulding: Almost. It gets passed some arguments depending on the action that is being taken.
<hunger> update-manager has broken gconf schemas here.
<mvo> hunger: yes, I just uploaded a fix
<hunger> mvo: Great, thanks!
* hunger wonders why lintian (or whatever checker is en vogue today) does not catch that kind of error.
<soren> donspaulding: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact
<donspaulding> Mithrandir: soren: thanks for teh tips!  I'll go reread that section of the policy manual.  This rocks!
<donspaulding> s/teh/the
<soren> donspaulding: The entire chapter is what you want to read, actually. That particular section just lists the ways the script might get called by dpkg.
<donspaulding> sure, I'll look at it
<donspaulding> thanks
<soren> np
<donspaulding> it looks like all I have to code for are "configure" and "abort-remove", which doesn't seem too bad.
<soren> donspaulding: It's very common to only do anything at all for configure.
<soren> pitti: So the lvm crypto magic stuff should be in working condition now?
<pitti> soren: I just got my first successful test
<pitti> soren: with the pkgsel aproach
* soren hugs pitti
<soren> That's excellent. I'm backing up my laptop right now, so that I can go cryptolvm on it before I leave for Boston.
<cjwatson> donspaulding: you should Depends: python too
<cjwatson> donspaulding: in debian/control
<cjwatson> (I know Ubuntu has essential python-minimal and all that, but it's good style)
<donspaulding> cjwatson: ok, thanks
<Kopfgeldjaeger> :-)
<pitti> soren, cjwatson: pkgsel debdiff attached to bug 144390; phew
<ubotu> Launchpad bug 144390 in pkgsel "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,In progress]  https://launchpad.net/bugs/144390
<Kopfgeldjaeger> now i can happily go to bed ;)
<cjwatson> pitti: looks good to me. what a hack. :-)
<cjwatson> pitti: isn't there a race between you calling udevtrigger and the devices appearing?
<pitti> cjwatson: thank you so much for your help; I'm just a d-i noob :(
<cjwatson> I can never get my head around that
<cjwatson> though Keybuk tells me udevtrigger/udevsettle is useless ... but you might need a better explanation from him
<pitti> Keybuk: ^ any idea?
<cjwatson> hey, I have an idea
<soren> cjwatson: I think he suggested it himself this time.
<cjwatson> call update-dev
<pitti> cjwatson: last time he explicitly recommended me to call udevtrigger to get the missing uuids
<cjwatson> that way at least d-i is wrong consistently :-)
<cjwatson> ok, if Keybuk suggested it then I guess it must be OK
<pitti> that's a wrapper around udevtrigger plus some magic?
<cjwatson> if type udevtrigger >/dev/null 2>&1 && type udevsettle >/dev/null 2>&1; then
<cjwatson>         udevtrigger
<Kopfgeldjaeger> pitti: are you sure you need /sys for that?
<cjwatson>         udevsettle
<cjwatson> fi
<cjwatson> Kopfgeldjaeger: does no harm
<pitti> Kopfgeldjaeger: no, I'm not
<pitti> Kopfgeldjaeger: but I definitively need /proc
<Kopfgeldjaeger> yeah, thats right.
<pitti> so I just added it in case
<cjwatson> pitti: if Keybuk suggested udevtrigger, let's just leave it as you have it
<pitti> ok
<cjwatson> Kopfgeldjaeger: bits of initramfs-tools do walk /sys, so yes, it is needed.
<soren> I'm curious: How do you guys test d-i stuff? There must be a simpler way than to build a fresh installer image and try it in a vm?
<cjwatson> grep /sys /usr/share/initramfs-tools/hook-functions
<pitti> cjwatson: I hope that the changelog is written halfway comprehensible, and that it explains the dilemma
<pitti> cjwatson: for hardy, I'd instead fix packages to install cleanly with a dynamic udev and keep /dev bind-mounted (seems much cleaner to me)
<cjwatson> soren: typically I either edit it while it's running (you have nano), or I wget or scp in updated versions while it's running
<cjwatson> pitti: yeah, I think setting up /dev/.static/dev might be enough
<Kopfgeldjaeger> aah, ok. but in my qemu mashine, i didnt need /sys to do a successfull update-initramfs. but things may vary
<cjwatson> dunno. anyway
<cjwatson> Kopfgeldjaeger: you probably get different results in some circumstances
<cjwatson> Kopfgeldjaeger: it won't error out, but it may behave differently
<Keybuk> pitti: do you need the UUIDs immediately?
<Kopfgeldjaeger> yeah..
<cjwatson> though only in MODULES=dep mode
<cjwatson> Keybuk: yes, it's basically udevtrigger; update-initramfs -u
<soren> cjwatson: Oh, really? I would have thought you had some sort of special environment where you could do things more easily.
<pitti> Keybuk: I call update-initramfs immediately after; a few seconds delay won't hurt, but it's not defined
<cjwatson> soren: it's easy enough
<Keybuk> ok... then he needs a udevsettle in there too
<geser> pitti: have you time to sponsor bug #150692 or should I look for an other sponsor?
<ubotu> Launchpad bug 150692 in libservlet2.4-java "[Merge]  libservlet2.4-java 5.0.30-6ubuntu1" [Undecided,New]  https://launchpad.net/bugs/150692
<pitti> Keybuk: ok, I'll add that, thanks
<cjwatson> pitti: ok, use update-dev then please
<cjwatson> for consistency
<pitti> cjwatson: alright; that's defined in pkgsel.postinst?
<Kopfgeldjaeger> good night
<pitti> anyway, I'll do another test with that better
<Keybuk> trigger tells udev to re-run its rules for devices in the /sys tree
<Keybuk> settle actually waits for udev to finish
<cjwatson> pitti: no, it's a script shipped by di-utils (which is basically Essential as far as d-i is concerned)
<Keybuk> in this case, you're doing it to refresh the information about devices you already know about
<Keybuk> so you're not falling into the "udevsettle does not wait for new hardware" trap
<cjwatson> aah
<cjwatson> now I understand
<pitti> ah, got it
<cjwatson> soren: sometimes I build a new udeb, grab it, udpkg -i it on the fly
<cjwatson> soren: just depends what I'm doing
<cjwatson> soren: there's a special monolithic initrd type which I used to use a lot more when I was porting d-i to Linux 2.6 on powerpc, which isn't really something you can hack on the fly; monolithic doesn't rely on a CD or the network for anything
<soren> cjwatson: I suppose. To me it all just seems opaque.
<cjwatson> soren: but I find that to lengthen the test cycle too much for ordinary work, really
<cjwatson> soren: plus I've been working on d-i for 3+ years so I have a head-start in terms of instinct for what will work ;)
<soren> cjwatson: Sure :)
<cjwatson> (having written big chunks of the infrastructure sure helps in remembering how it works)
<soren> pitti: So tomorrow's daily will have working auto-crypto-lvm goodness?
<cjwatson> pitti: did you promote partman-auto-crypto back to main?
<soren> pitti: Oh, you actually demoted it already?
<soren> I thought "I'll demote foo to universe" was just pitti-speak for "/me shakes his fist at foo".
<pitti> cjwatson: yes
<pitti> soren: that's the problem if you have a drescher account -- shaking your first actually *does* things
<soren> <g>
<pitti> meh, why doesn't vmware support copy&paste in VTs
<soren> Is that an actual question?
<pitti> </rhetoric>
<soren> Oh, good. :)
<pitti> wasn't there a trick to get scp in d-i?
<cjwatson> pitti: anna-install openssh-client-udeb
<pitti> merci
<cjwatson> works immediately after "retrieving installer components"; before then, it'll queue
<cjwatson> wget and nc are built-in
<pitti> ah, wget, that'll do
<pitti> BenC: can we please have lbm for -13?
<soren> pitti: You discussed bug 119075 with jdstrand recently, right? What did you decide for gutsy?
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [Undecided,In progress]  https://launchpad.net/bugs/119075
<pitti> right
<wasabi> soren: What's up with ebox?
<wasabi> I notice you're the only uploader in ages.
<soren> pitti: I understand that at this point in the release process we should keep things simple, but we've changed things in released versions of Ubuntu to this effect. It seems wrong to have a feature in Dapper, Edgy, and Feisty, not in Gutsy, and then reintroduce it in Hardy.
<soren> wasabi: We decided to defer it. It'll be in hardy.
<wasabi> Ahh.
<pitti> soren: ok; what particular feature do you mean?
<wasabi> The packages look like they're not in a complete state. Am I right?
<soren> pitti: Adding the resetpassword thing in the init script.
<soren> wasabi: Yes.
<wasabi> k. Thanks.
<pitti> soren: AFAIR we just agreed to make sure to display the debconf question for gutsy
<soren> pitti: Ok. Hmm...
<soren> I understand the argument, I think. We didn't used to ask for a root password, so gutsy is different w.r.t. to password handling, but you can just tell it that you want an empty password, and it'll accept that.
<soren> ..and unlike dapper, edgy, and feisty, it won't make a fuss over it.
<soren> Uargh... Has Jamie's patch been uploaded to -security already?
<pitti> soren: not sure; keescook?
<soren> It seems not.
<soren> Phew..
<soren> jdstrand: You wouldn't happen to be around, would you?
<pitti> \o/ my final pkgsel install test succeeded
<pitti> time to upload
<soren> Woo!
<pitti> wow, my first d-i-ish upload
<cjwatson> really?
<cjwatson> I thought you'd done something around there before
<pitti> I might have forgotten, right
<pitti> not something that costed me hours to figure out, though :)
<pitti> cjwatson: committed and pushed to bzr, too
<cjwatson> ta
<Riddell> keescook: I just came across bug 150716
<ubotu> Launchpad bug 150716 in pam "libpam0g interrupts upgrade" [Undecided,New]  https://launchpad.net/bugs/150716
<pitti> tkamppeter: still here?
<pitti> Riddell, tkamppeter:
<pitti>   foomatic-db-gutenprint: Depends: ijsgutenprint (>= 5.0.1-0ubuntu8) but it is not installable
<pitti> Riddell, tkamppeter: (since it's in universe)
<pitti> I'm fine with promoting it if necessary, but please confirm that this is deliberate
<pitti> I read something about 'reverting' a change, but this wasn't here before
<pitti> Riddell: anyway, promoted
<teprrr> tkamppeter, heya, got my private messages?
<teprrr> (just joined to be sure you haven't missed them if you're using ignoreoc )
<teprrr> ;)
* soren calls it a day and goes to bed.
<mjg59> slangasek: 149997 probably wants to be milestoned
#ubuntu-devel 2007-10-09
<tkamppeter> teprrr I have got them and answered to the kernel bug report. There is another kernel USB problem which can be similar or the same. On that other one I got already one promising answer which can lead to this milestoned bug getting fixed in Gutsy.
<teprrr> tkamppeter, ah. I see, great
<tkamppeter> I hope I get answers from some other Brother users.
<teprrr> hmm, brother has the same problem? I thought spl is samsung-only thing :P
<teprrr> (about the spl error, for sure)
<teprrr> don't know about the kernel one..
<teprrr> something is wrong in udev(?) as it doesn't want to create dev entry for my printer.. but haven't had time to investigate and I'm running dapper/edgy kernel myself and my system is quite borked atm
<teprrr> waiting for a new comp and clean install :)
<tkamppeter> teprrr. the other bug is that Brother printers sometimes disappear or show only a partial device ID. Your Samsung seems to have disappeared sometimes, too. The SPL error is another bug which I have already fixed earlier by packaging the newest SPL version.
<tkamppeter> teprrr, for the SpliX package for old Ubuntu versions you can also take the LSB package from OpenPrinting. This is also the latest version.
<teprrr> tkamppeter, hmm. the spl bug was caused by a firmware bug in the printer, right? and it was fixed in never splix I think
<teprrr> ahh, that's nice to hear :)
<tkamppeter> Yes, that is the case. Software workaround for hardware bug. At manufacturers very common.
<teprrr> will test one from openprinting soon. forcing gutsy package in didn't do good for my other upgrades ;)
<teprrr> yup
<teprrr> I haven't seen this printer disappearing or showing partial devid, but for some reason it doesn't get the /dev entry at all
<teprrr> but the error could be anywhere..
<superm1> bryce, cjwatson i verified that adding '^xserver-xorg/' to the copy_debconf function in ubiquity does work for fix bulletproofx on the mythbuntu disks.
<superm1> so i wouldn't suspect any other conflicts from ubuntu disks by committing it
<tkamppeter> Does the workaround with the USB suspend in the kernel bug report help you?
<teprrr> tkamppeter, hmm, you mean appending that line to sysfs.conf?
<teprrr> tkamppeter, I'm not running gutsy at least, but hmm
<teprrr> tkamppeter, and using kernel: Linux tuli 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux
<tkamppeter> Did not take into account that you are running a much older kernel. Perhaps the same problem exists there, too, but otherwise, it can be needed when you switch to Gutsy in the next days.
<teprrr> tkamppeter, yup, well, it'll take sometime until I get a new machine and will do clean install on it
<teprrr> I think gutsy will be released much before that
<teprrr> though I'd like to wait for HH, but doubt I can live with this piece of .. that long
<tkamppeter> teprrr. HH is an LTS, this will fit your needs better.
<teprrr> but well, time to have some sleep. thank you for this nice chat :)
<teprrr> tkamppeter, yup, that's why I'm waiting for it actually
<tkamppeter> teprrr, and thanks for the hint with the bug reports, it can perhaps fix a very ugly one (the one with the Brother printers).
<teprrr> yup, no problem and good night o/
<pitti> rebuilding new CDs now
<ScottK> pitti: Are you up for doing a sync while you wait for the CDs to rebuild?
<pitti> ScottK: can do
<ScottK> Bug #148548 if you wouldn't mind...
<ubotu> Launchpad bug 148548 in gnucash-docs "Please sync gnucash-docs (universe) from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/148548
<ScottK> It'd be nice to have the docs match up to the installed package ;-)
<bddebian> pfft :-)
<ScottK> bddebian: Well people do accuse me of being "detail oriented".
<bddebian> :-)
<jroes> oh, is the dancer going counterclockwise for you then?
<jroes> ;)
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<RAOF> Why can't mvo stay permanently connected in here?  Now I'll have to use launchpad to tell him that his compiz fix isn't ;)
<pitti> new alternates are up, ubuntu live up, rest of live are building; ISO tracker updated, please go wild and test
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy release freeze in effect | Please test the RC candidates: https://iso.qa.stgraber.org/qatracker/
<StevenK> pitti: Wow
<pitti> hi StevenK
<StevenK> pitti: Also double-wow, based on the time there. :-)
* pitti yawns
<StevenK> pitti: virtualbox-ose-modules 2 uploaded, if you can push The Big Red Shiny Button to let it in at your leisure.
<pitti> StevenK: at it
<pitti> good night everyone; I'll sleep a bit longer tomorrow morning, so don't expect me at my usual early-morning-bird time :)
<ion_> Night
<ScottK> good night pitti.
<StevenK> Night pitti
* Hobbsee pokes fabbione
<superm1> keescook, you around?
<m1ke> Will the kernel have xpad integrated?
<pwnguin> m1ke: modprobe xpad worked on my gutsy laptop
<pwnguin> I don't have hardware to test with
<m1ke> wired or wireless controller?
<pwnguin> i dont have either
<pwnguin> i do have the wiimote working though ;)
<m1ke> Well I know this isn't the appropriate help channel, but I have tried ever tutorial out there to get a xbox 360 wireless controller to work with no luck.  I was reading a bug.launchpad thread that was talking about adding in the xpad into current/future kernels.
<pwnguin> well here's the deal. if it doesn't work right now with gutsy, it'll have to wait until hardy, as there's only like a week left and much more critical things to fix
* pwnguin is thankful Nintendo went with a relatively open set of protocols
<pwnguin> exit
<defcon> ralink based cards still dont work in gutsy
<defcon> isnt wireless cards high priority for gutsy?
<frostburn> they usually dont work because there is no published api
<frostburn> from the chipset makers
<Hobbsee> i thought ralink's were open sourced.
<Hobbsee> i thought they also got picked up
<defcon> yes they are
<defcon> they are open source and work in every other distro
<defcon> just not ubuntu
<defcon> search launchpad bugs for rt73 or ralink
<defcon> tons of problems
* Hobbsee would suggest #ubuntu-kernel, a sthey're the kernel people (but probably arent awake yet)
<defcon> it seems for the past 2 years they have ignored these cards
<defcon> how can they not see the bugs in launchpad?
<nemik> for some reason i think my x11 got recompiled with the xcb option, how can i put it back?
<m1ke> pwnguin, are you a dev?
<pwnguin> m1ke: not a kernel dev, no
<m1ke> pwnguin, you are a gamer?
<pwnguin> yes
<pwnguin> just not halo
<pwnguin> therefore, i have no xbox controllers
<m1ke> Halo3 is amazing
<ion_> xjump is, too.
<pwnguin> i dont think this's the place for this conversation
<kagou> Good morning
<dholbach> good morning
<kagou> hey dholbach
<dholbach> hey kagou
<mdke> cjwatson: https://lists.ubuntu.com/archives/ubuntu-translators/2007-October/001334.html is for you, I suspect
<soren> Eeek! I just tried the alternate installer on real hardware. At some point (fairly soon after "Running tasksel") the display became completely messed up (as in video memory corruption messed up).
<tepsipakki> soren: intel?
<soren> Yup
<tepsipakki> hmm, I thought that was fixed already
<soren> This is a fresh daily alternate.
<soren> tepsipakki: Anything I can do to work around it for now?
<tepsipakki> soren: disable framebuffer IIRC
<tepsipakki> although that means you don't get usplash without putting that manually on grub menu.lst
<soren> I think I can mange that. :)
<tepsipakki> heh
<soren> tepsipakki: Is there anything I can do to help get it fixed?
<tepsipakki> soren: well, I'm not familiar with that bug, been concentrating on ati lately :)
<tepsipakki> but let me check the bug
<soren> tepsipakki: Which package has the bug?
<soren> Is it X trying to autoconfig that messes it up?
<tepsipakki> soren: I'm trying to find out.. I guess it was xresprobe
<soren> Looks like it.
<soren> * xresprobe: Fix issue in alternate installation for Intel gfx laptops resulting in screen to be replaced by flashing colored blocks, by making xresprobe use ddcprobe instead of xprobe for laptops using the -intel driver. (Closes LP: #127008 and many, many duplicates)
<tepsipakki> hmm, that's not yet passed the queue?
<soren> Yes.
<soren> I'll check what's on the CD.
<soren> 0.4.24ubuntu5
<soren> Which should have the fix.
<tepsipakki> soren: indeed
<davmor2> bryce: ping
<tepsipakki> davmor2: he's most likely asleep ;)
<soren> slacker :)
<davmor2> tepsipakki: to be honest I thought he would be which is why I pingged to check :(  I'll speak with him tonight
<tepsipakki> soren: :)
<slangasek> mvo: ping
<mvo> slangasek: good morning
<superm1> hey mvo
<slangasek> mvo: hi.  is release-upgrader currently set to useDevelopmentRelease=False?
<mvo> slangasek: let me check
<slangasek> thx
<mvo> slangasek: DistUpgradeControler.py:        m = MetaReleaseCore(useDevelopmentRelease=False)
<slangasek> mvo: great, thank you
<pitti> Good morning
<geser> Hi pitti
<superm1> mvo, i attempted using the other line you had recommended, but no difference : things still hung.  just to rule it out, i remastered a disk today with unionfs 1.4 (since BenC uploaded it to lum), same thing
<\sh> pitti, keescook: please review https://bugs.edge.launchpad.net/ubuntu/+source/dircproxy/+bug/150848 security issues in dircproxy (fixed versions for dapper, edgy, feisty, gutsy) thx
<ubotu> Launchpad bug 150848 in dircproxy "[CVE-2007-5226]  dircproxy segfault on blank /me" [Undecided,New] 
<mvo> superm1: ok, thanks. is the current image avialable somewhere? I will give it another go
<superm1> mvo, i'll generate it on our webserver rather than push it all up again and wait for our slow upload so that you can have it with all current packages
<mvo> ok
<pitti> mvo: apt change looks good, accepting
<mvo> thanks pitti
* soren -> coffee
* \sh <- BYOD aka Build Your Own Distri
<pitti> soren: how much testing did the new l-u-m with vmware modules get, and on how many arches has it been build-tested?
<pitti> soren: I'm not happy about introducing it into l-u-m at this point, but since it's what we have in the queue, and I don't have the skills to separate it from the bug fixes, I'd like to make sure in advance
<superm1> mvo, http://uk.cdimages.mythbuntu.org/~superm1/mythbuntu-7.10~071009-i386.iso http://uk.cdimages.mythbuntu.org/~superm1/mythbuntu-7.10~071009-i386.iso.md5sum
<superm1> mvo, again to reproduce, the way i typically do it is just pick advanced and change a ton of items from their default behavior.  (With those two lines commenting out, this testing strategy works)
* mvo downloads
<superm1> i better go take a nap for a few hours, it's getting late here :).  i'll touch bases with you when i get up
<superm1> mvo, and the interesting file is /usr/share/ubiquity/install.py.  lines 1418 and 1529 for do_install and do_remove respectively
<superm1> those two lines are reached between 94 and 95 percent
<pitti> hi Keybuk
<mvo> pitti: plesae reject my translations_main_20071009.tar.gz ddtp upload, this one is bogus, rosetta send something unexpetecd when I requested the export
<mjg59> #68370 actually looks like a server bug, as far as I can tell
<pitti> mvo: done
<mjg59> The server is calling DeviceOn even after the vt has switched
<mvo> pitti: thanks
<cjwatson_> mjg59: the touchpad tap-to-click disable thing doesn't seem to be working for me any more; where should I start in investigating this?
<mjg59> cjwatson_: Hm. Seems to be working here.
<mjg59> Any errors in ~/.xsession-errors ?
<cjwatson_> I've suspended/resumed recently, but IIRC it didn't work on the most recent couple of boots either
<cjwatson_> mjg59: lots of rubbish, what should I look for?
<mjg59> Any mention of pad
<cjwatson_> no
<mjg59> Ok
<mjg59> And gnome-settings-daemon is running?
<cjwatson_> yes
<mjg59> Ok.
<cjwatson_> I'm assuming that my touchpad isn't a core pointer ...
<mjg59> Mm?
<cjwatson_> the synaptics entry in xorg.conf has SendCoreEvents but not CorePointer, but I'm not sure how to check that that's really the device corresponding to my touchpad
<mjg59> Ok, that should be fine
<cjwatson_> wasn't the synaptics stuff disabled for corepointers?
<mjg59> Yes
<mjg59> But SendCoreEvents doesn't make it a core pointer
<cjwatson_> ok
<StevenK> pitti: Morning. Can you accept my virtualbox-ose-modules 2 upload? :-)
<pitti> StevenK: done earlier; sorry
<StevenK> pitti: Quite alright, thanks. :-)
<StevenK> pitti: I daresay you had other things on your mind when you quit IRC earlier - like how much you miss your bed. :-)
<pitti> indeed :/
<pitti> StevenK: it wasn't in the queue yet when you asked first, and then I just forgot about it :(
* StevenK nods.
<StevenK> pitti: It's fine, like you said yesterday, we have plenty of time to fix universe stuff.
<mantiena-baltix> Riddell, hi, are you kde-guidance/displayconfig-gtk maintainer in Ubuntu ?
<mantiena-baltix> there are big problems with displayconfig-gtk or guidance-backends in Ubuntu Gutsy :(
<Riddell> mantiena-baltix: I package it, glatzor does most of the maintaining
<Riddell> (he's not here just now)
<Riddell> what sort of problems?
* dholbach hugs pitti and StevenK
<mantiena-baltix> Riddell, one of the biggest problems is, that generated xorg.conf contains wrong line "Virtual H V"
<mantiena-baltix> look at description of bug #139027 and last comment in bug #137517
<ubotu> Launchpad bug 139027 in displayconfig-gtk "Screens & Graphics not setting correct resolution" [Undecided,Confirmed]  https://launchpad.net/bugs/139027
<ubotu> Launchpad bug 137517 in displayconfig-gtk "[Gutsy]  displayconfig-gtk configures my 22" 1680x1050 LCD panel wrong." [Undecided,Incomplete]  https://launchpad.net/bugs/137517
<Riddell> mantiena-baltix: sounds like a job for glatzor, please e-mail him (https://launchpad.net/~glatzor) and CC me (~jr)
<mjg59> mantiena-baltix: Why would the virtual line matter?
<mantiena-baltix> I've tested on several CRT monitors and newer get correct results - virtual screen was always bigger than choosed resolution :(
<mantiena-baltix> mjg59: look at description of bug #139027
<ubotu> Launchpad bug 139027 in displayconfig-gtk "Screens & Graphics not setting correct resolution" [Undecided,Confirmed]  https://launchpad.net/bugs/139027
<soren> pitti: Woot! I've just booted my laptop after reinstalling it using the autocryptolvm stuff. It worked like a charm!
<mantiena-baltix> When Virtual is bigger, than selected resolution then only part of desktop is visible, user should move mouse towards edge of screen to see that the window could pan and scroll the missing portion into view.
<pitti> soren: :)
<cjwatson_> soren: ++
<soren> pitti: I've build-tested it on i386. They're only built for the -virtual flavour on i386.
<pitti> ok
<mantiena-baltix> mjg59, almost all commenters tells the same - read for example https://bugs.launchpad.net/ubuntu/+source/displayconfig-gtk/+bug/139027/comments/2 and later comments
<ubotu> Launchpad bug 139027 in displayconfig-gtk "Screens & Graphics not setting correct resolution" [Undecided,Confirmed] 
<mantiena-baltix> Riddell, why you think, that this problem is not in guidance-backends, but in displayconfig-gtk ? AFAIK xorg.conf if generated by guidance-backends, right?
<mjg59> mantiena-baltix: Sigh. It sounds like nvidia doesn't cope with the new semantics of virtual.
<mjg59> mantiena-baltix: In the RANDR1.2 world, "Virtual" indicates the largest screen size that will be used
<mjg59> mantiena-baltix: guidance needs to avoid writing a virtual line if it's using the nvidia driver
<mantiena-baltix> mjg59, you think, that problem is in open source nv driver ?
<mjg59> mantiena-baltix: No
<mantiena-baltix> mjg59, I performed all tests with open source nv driver, not closed source nvidia
<mjg59> mantiena-baltix: The bugs you pointed at only seem to mention the closed one
* Fujitsu upgraded a machine using nvidia today, and managed to get X to die severely using displayconfig-gtk.
<mantiena-baltix> mjg59, but I tested several times on several systems with only open source drivers
<mjg59> mantiena-baltix: Your description in 137517 doesn't make sense
<mjg59> mantiena-baltix: The presence of the virtual line will not make X start in a lower resolution
<mantiena-baltix> mjg59, yea, problem is, that virtual is bigger, than selected
<mjg59> mantiena-baltix: That's not what the bug says
<mantiena-baltix> mjg59, not all people can write in correct english :)
<mjg59> mantiena-baltix: Point 1 of https://bugs.edge.launchpad.net/ubuntu/+source/displayconfig-gtk/+bug/137517/comments/3
<ubotu> Launchpad bug 137517 in displayconfig-gtk "[Gutsy]  displayconfig-gtk configures my 22" 1680x1050 LCD panel wrong." [Undecided,Incomplete] 
<mantiena-baltix> mjg59, look for example at http://launchpadlibrarian.net/9833237/xorg.conf (attached at bug 139027)
<ubotu> Launchpad bug 139027 in displayconfig-gtk "Screens & Graphics not setting correct resolution" [Undecided,Confirmed]  https://launchpad.net/bugs/139027
<Riddell> mantiena-baltix: I've no idea
<mantiena-baltix> SubSection "Display"
<mantiena-baltix> 		Virtual	2048	1536
<mjg59> mantiena-baltix: I'm trying to understand the issue. How does writing the virtual result in the screen only running at 1400x1050?
<mantiena-baltix> Modes		"1400x1050@75"	"1600x1200@65"	"1400x1050@60"	"1600x1200@60"	"1280x960@75"	"1600x1200@75"	"1280x1024@60"	"1600x1200@70"	"1280x1024@85"	"1600x1200@85"	"1280x960@85"	"1792x1344@75"	"1280x960@60"	"1792x1344@60"	"1280x1024@75"	"1856x1392@60"	"1152x864@75"	"1856x1392@75"	"1024x768@43"	"1920x1440@60"	"1024x768@60"	"1920x1440@75"	"1024x768@70"	"2048x1536@60"	"1024x768@75"	"2048x1536@75"	"1024x768@85"
<mjg59> Riddell: guidance-backends is just inept
<mjg59> By the looks of it, right now it's pretty much guaranteed to write out garbage for several common cases
<mantiena-baltix> mjg59, if you can restart your X-window system I can show how to reproduce this bug
<mjg59> mantiena-baltix: No. Please tell me how the presence of the virtual line results in your monitor starting at 1400x1050
<mjg59> mantiena-baltix: In any case, attempting to reproduce it on this machine wouldn't help - writing the virtual line is the correct thing to do on Intel hardware
<mantiena-baltix> mjg59, could you show me your xorg.conf ? is it generated by displayconfig-gtk ?
<mjg59> mantiena-baltix: It's not, no, but that's irrelevant. I'm trying to understand your issue.
<mantiena-baltix> wait a minute
<mjg59> mantiena-baltix: Are you saying that deleting the virtual line makes your monitor start in 1920x1440?
<mantiena-baltix> mjg59, wait a minute, I showed you bad example above :(
<mjg59> mantiena-baltix: I'm still trying to understand your comment in the bug
<mjg59> mantiena-baltix: You have a 1920x1440 panel, right?
<mantiena-baltix> mjg59, no, I've CRT
<mjg59> mantiena-baltix: That can run at 1920x1440?
<mjg59> Riddell: Argh. Seriously. Who wrote the displayconfig backend?
<mantiena-baltix> I don't know maximum, because I never use it, problem is, that displayconfig-gtk generated xorg.conf doesn't choose right resolution on all computers, where I tested
<mantiena-baltix> I show you real example after 1 minute
<mjg59> mantiena-baltix: I'm still trying to understand how deleting the virtual line makes it work at the correct resolution
<Riddell> mjg59: various people
<Riddell> (none of them me)
<mjg59> Riddell: It's astonishingly wrong in places
<mjg59> Like "Make my X not work" wrong
<moyogo> ping ArneGoetje
<mjg59> mantiena-baltix: So, your monitor starts in 1400x1050. You delete the virtual line. What resolution does it then start in?
<mantiena-baltix> mjg59, wait a minute
<mjg59> Oh, argh.
<mjg59> This is full of nightmares.
<mantiena-baltix> I just generated new xorg.conf with displayconfig-gtk and upload it to public location to show you
<mjg59> mantiena-baltix: I don't see how that's going to help. I don't have nvidia hardware here, so I can't reproduce your issue.
<mantiena-baltix> mjg59, I don't think that problem is only with nvidia hardware - now I'm testing on computer with ATI Rage 3 card (ati open source driver)
<mjg59> mantiena-baltix: So, your monitor starts in 1400x1050. You delete the virtual line. What resolution does it then start in?
<mantiena-baltix> mjg59: it seems there are 2 problems - first problem is, that displayconfig-gtk generated xorg.conf doesn't set choosed resolution
<mjg59> mantiena-baltix: Please answer my question
<mantiena-baltix> mjg59, I can't answer your question now, because I tested on several systems with several monitors and don't remember exact resolutions
<mantiena-baltix> I just remember, that all systems had the same problems
<mantiena-baltix> so, wait few minutes, while I start some computers and show you exact problems
<mantiena-baltix> I think, that I found where is the problem
<mantiena-baltix> mjg59, can you look at http://ftp.akl.lt/incoming/xorg.conf
<mantiena-baltix> at Section "Screen"
<mjg59> mantiena-baltix: Yes?
<mantiena-baltix> mjg59, tell me, which at resolution X should start ?
<mjg59> mantiena-baltix: 1024x768
<mantiena-baltix> mjg59, why ?
<tepsipakki> it's the first
<mjg59> mantiena-baltix: What resolution did you select?
<mantiena-baltix> 1024x768
<mjg59> Right. So it starts at 1024x768, but will have a virtual of 1400x1050.
<mjg59> You delete the virtual line. Now what happens?
<mantiena-baltix> mjg59, you are righ - screen is larger than my resolution
<mantiena-baltix> mjg59, I never tried to delete that line, I just tried to set it to my resolution 1024x768
<mjg59> mantiena-baltix: Then what does your comment on #137517 mean?
<mantiena-baltix> mjg59, if you need I can delete that line and restart X
<mjg59> mantiena-baltix: You said that your monitor starts at the wrong resolution because it writes the virtual line
<mantiena-baltix> mjg59, I told you already - this is because of bad english :)
<mjg59> mantiena-baltix: Ok, so the screen starts at the right resolution?
<mjg59> Just with the wrong virtual size?
<mantiena-baltix> mjg59, yes, but real screen is bigger than resolution and doesn't fit in my monitor
<mjg59> mantiena-baltix: Yes. Ok. So it's setting the resolution correctly.
<mantiena-baltix> has launchpad a way to edit or delete comments ?
<mjg59> No
<mantiena-baltix> mjg59, I think in several bugreports people says resolution instead of virtual screen
<saispo> anyone use a macbook ?
<mantiena-baltix> saispo, I, sometimes
<saispo> mantiena-baltix: which keyboard layout you use ? i search how to do a ~, | and {}
<mantiena-baltix> I use lt and don't have my mac here (can access only through ssh)
<saispo> k :/ thanks
<iwj> Why is the gimp on the current ISOs a release candidate ?
<dholbach> because it's the latest version there is
<iwj> Hmm.  Fair enough I suppose.
<dholbach> clearly we hoped we'd get final
<iwj> seb128: The icon used in Gnome menus for "Get help online" is the original gnome lifering which is replaced in the toolbar by the blue spot with the question mark.  Is it right that it remains unchanged in the help menus ?
<popey> I want to file a bug against a package but I am not sure what package to file against - it's the brightness thing that shows on the screen when you press the special function keys on a laptop.. any ideas?
<mjg59> Gnome or KDE?
<popey> gnome
<mjg59> Then gnome-power-manager. But what's the issue?
<popey> ahh, of course
<popey> you know the little icon that shows when you press the buttons, well it shows for local users and anyone vnc'ed in too
* Fujitsu looks at bug #150906... did I see somebody say yesterday that was fixed?
<ubotu> Launchpad bug 150906 in xdg-user-dirs "[gutsy]  VERY bad Desktop location inconsistency with xdg-user dirs" [Undecided,New]  https://launchpad.net/bugs/150906
<popey> even different users
<popey> it's only minor I guess, but I thought it needed reporting
<mjg59> Interesting
<mjg59> I guess it's picking up on the dbus message
<popey> yeah, kinda freaked me out a bit
<popey> worth filing?
<mjg59> But yeah, if you're VNCed into a local session, there's no obvious way around that
<mjg59> The VNC session will just scan out anything that's drawn to the screen
<popey> no, this was vnc'ed to a vncserver for a different user
<mjg59> Hm. Yes, it'd happen in that case as well
<popey> I can see why it happens, no user abstraction in dbus or something
<popey> as you said
<mjg59> Well, yeah. Failure to check that it's the foreground console.
<mjg59> We some some infrastructure for doing that, but it's going to have to be reimplemented at some stage
<popey> well, I'll file it.. wishlist?
<mjg59> Yeah
<popey> ok, ta
<kagou> i have a strange bug. Doing test with RC iso, desktop and alternate, with desktop i do not have usplash. My question is there any difference between packages on desktop and alternate ?
* popey files bug 150908
<ubotu> Launchpad bug 150908 in gnome-power-manager "brightness popup incorrectly apears for remote users" [Undecided,New]  https://launchpad.net/bugs/150908
<mjg59> popey: Ta
<kagou> whan i say that i do not have usplash, i mean that i have black screen
<popey> i don't see how I can make it wishlist, do i need to change it from "new" or does someone else have to triage it?
<mjg59> popey: Feel free to change it from new
<kagou> popey, which bug
<popey> sorry, such a bug noob
<mjg59> kagou: At a guess, the one that he was just talking about?
<popey> :)
<kagou> sorry i'm just came back from lunch
<kagou> popey, click on "importance" and select wishlist
<kagou> for more question ask then on #ubuntu-bugs
<DktrKranz> pitti, around for a quick quick question?
<kagou> popey, i will close your bug, it's a duplicate. And fix have been released
<pitti> yes, if you wouldn't disappear so quickly
<bluekuja> pitti: he wanted to ask you about https://bugs.edge.launchpad.net/ubuntu/+source/xawtv/+bug/150905
<ubotu> Launchpad bug 150905 in xawtv "Merge xawtv 395.dfsg.1-6 from Debian unstable" [Wishlist,Confirmed] 
<pitti> it's universe, so subject to motu-sru scrutiny (and not bound by the current RC freeze)
<popey> oh, thanks kagou, i searched but didn't find it, sorry
<bluekuja> pitti: it's just a new debian revision
<bluekuja> pitti: so we dont need motu-uvf
<pitti> then get it uploaded :)
* pitti -> lunch
<bluekuja> good lunch :)
<jdstrand> soren: re bug #119075
<ubotu> Launchpad bug 119075 in mysql-dfsg-5.0 "Root password policy for mysql" [Undecided,In progress]  https://launchpad.net/bugs/119075
<jdstrand> you had some questions?
<mantiena-baltix> mjg59, hi again, I tested displayconfig-gtk on several computers again and it seems I really know where is the problem
<mjg59> mantiena-baltix: Mm?
<mantiena-baltix> main problem is that Virtual line is set not the same, like choosen mode
<mantiena-baltix> s/choosen/choosed
<mjg59> If it was set to the chosen mode, there'd be no point in it being there
<mantiena-baltix> mjg59, so, you think, that virtual desktop should be bigger, than selected resolution and user shouldn't see all the desktop ?
<soren> jdstrand: so..
<mjg59> mantiena-baltix: No
<soren> jdstrand: Yes, it's not going to fly the way you've proposed.
<jdstrand> soren: this is the partial debdiff for mysql
<jdstrand> http://paste.ubuntu-nl.org/40052/
<jdstrand> that is for dapper, edgy and feisty
<jdstrand> I didn't do anything for gutsy
<jdstrand> very unintrusive
<soren> The reason I messed around with whiptail and all that jazz was to avoid ever being able to see the mysql root password in the process list. With your approach a malicious user has as much as three chances to do that, iirc.
<jdstrand> soren: I didn'twant to introduce a new dependency into the fold on a security update
<soren> jdstrand: line 75 and 84 at least.
<soren> jdstrand: That's fine. I understand that.
<mantiena-baltix> mjg59, but if virtual is bigger, than choosed resolution, then user can't see all the desktop, right?
<soren> jdstrand: ...but your debdiff is not acceptable. We need another way to get a password from the user without it being made trivially available to a malicious user. Currently, even a friendly user might see it by accident.
<jdstrand> soren: I understand your point
<soren> jdstrand: I'd create two files and do a diff -q on them instead.
<jdstrand> soren: that was my thought just now
<mjg59> mantiena-baltix: By default, yes
<soren> And create another temporary file similar to what I did originally.
<soren> ...to hold the SQL code to inject the new password.
<jdstrand> soren: I can do that
<soren> Rock.
<soren> jdstrand: Something like splitting your line 84 into a: echo -n "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('" >> "${tmpfile}" ; cat "${passwdfile}" >> "${tmpfile}" ; echo -n "');" >> "${tmpfile}"
<jdstrand> soren: yeah
<mantiena-baltix> Riddell, hi again, maybe glatzor sometimes comes here ?
<soren> jdstrand: Coolness.
<mantiena-baltix> mjg59, so, why you are telling, that virtual should be bigger, than selected resolution ? Why user should't see all desktop by default ?
<mjg59> mantiena-baltix: No, that's not what I said
<Riddell> mantiena-baltix: sometimes
<mantiena-baltix> mjg59, then I don't undertand you :( Please tell me, what you want to tell when told "If it was set to the chosen mode, there'd be no point in it being there"
<mjg59> mantiena-baltix: A virtual line that specifies the default resolution is a noop
<mantiena-baltix> mjg59, but if I remove virtual line then same problems still exists - resolution is smaller than desktop :(
<iwj> Looks like I have some kind of weird display regression installing on my test laptop.
<mantiena-baltix> at least with nv driver (I don't tried to remove virtual line with ati driver)
<mjg59> mantiena-baltix: No, it's not
<soren> Failure to resume from hibernation... which package should that be filed against?
<soren> acpi-support?
<mjg59> soren: Probably the kernel
<mantiena-baltix> mjg59, I just tried this with Ubuntu 7.10 beta and noticed, that removing virtual line does nothing with this xorg.conf: ftp://ftp.akl.lt/incoming/xorg.conf
<mjg59> mantiena-baltix: Can you please put /var/log/Xorg.0.log there as well, please?
<mantiena-baltix> I get correct virtual desktop only when I specify Virtual 1024 768
<soren> mjg59: Maybe if I give you a rough description, you can tell me which package is likely to be at fault? It's seems a bit special.
<mjg59> soren: Sure
<mantiena-baltix> mjg59, ok, which Xorg.0.log I should put ? when Virtual line exists or when it's removed ?
<mjg59> When removed
<soren> mjg59: It seems to hibernate just fine. When booting again I type my password for the cryptolvm (I don't think this matters, the problems were there before I switched to that), and then there's a lot of disk activity again. I get the typical white bar across the screen and after a while, nothing more happens. When I get tired of waiting for that...
<mantiena-baltix> mjg59, then I should restart X, wait several minutes
<soren> ...I press Alt-f7 or something, and it suddenly springs to life, shows me a mouse cursor which I can move around, flickers a bit, shows me the cursor again, starts blinking the little moon led (this is a thinkpad) and then stops responding (black screen).
<soren> Magic SysRq+S doesn't even make the hdd led blink.
<Fujitsu> soren: You sure it hasn't gone to sleep?
<soren> Fujitsu: It's very much awake (it gets warm, the fan is running, the backlight is on (iirc))
<Fujitsu> Ah.
<soren> suspend-to-ram and resume from that works perfectly, though.
<soren> Well... If I'm not using compiz, that is.
<soren> Blimey! It worked this time!
<soren> That's a first.
<StevenK> soren: It was the threat of mjg59.
* soren tempts fate and does it again
<soren> StevenK: I think you're right. I should have picture of him I can wave in front of it if it misbehaves.
<StevenK> Bwahahaha
<soren> StevenK: If *I* was a b0rken ACPI implementation, I'd be frightened.
<soren> Twice in a row!
<Zarrathusa> i need some help.I want to try linux.I have spare drive(d)which is empty so I thought I would give it a whirl to look see.
<StevenK> Zarrathusa: Please ask in #ubuntu
<Zarrathusa> can anyone spare time to be my spirit guide in this instance
<jdstrand> soren: I was evaluating your comments
<jdstrand> echo and [ are builtins for dash
<Zarrathusa> wots #ubuntu
<Chipzz> Zarrathusa: please type /hop #ubuntu
<jdstrand> soren: as such, not a separate process and not in the process table
<pitti> StevenK: vbox-modules NEWed
<Chipzz> (does that even work with x-chat? :p)
<StevenK> pitti: Ahhhh, thanks.
<Zarrathusa> hop#ubuntu
<jdstrand> soren: its true of bash as well
<StevenK> pitti: We'll probably need to NBS them tomorrow. linux-image -14 is building now.
<Zarrathusa> hop#ubuntu
<pitti> StevenK: ah, indeed; I should have rejected them
<pitti> *shrug*
<soren> jdstrand: You need to put it in a file anyhow to fix the other problem, don't you?
<StevenK> pitti: Let me just upload a bunch of packages with virtualbox-ose-modules in their Depends. :-P
<jdstrand> soren: unless I am missing something it is safe as is
<pitti> StevenK: no problem at all; the queue is *very* patient :)
<StevenK> Muahaha
<jdstrand> soren: reading
<ScottK> pitti: Speaking of the queue, would you please accept libcommons-modeler-java (if you haven't already).  There's a merge waiting on it.
<jdstrand> soren: I use a tmpfile.  /usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf -e "\. ${tmpfile}"
<jdstrand> soren: unless I just don't understand what you are referring to
<Zarrathusa>  /hop #ubuntu
<Chipzz> Zarrathusa: without the leading space
<Zarrathusa> dont work this
<Chipzz> hrrm ok then try /join #ubuntu
<soren> jdstrand: How do you get the password into that file?
<Zarrathusa>  /join #ubuntu
<jdstrand> soren: 'echo -n'.  echo is builtin
<soren> jdstrand: Hm... Good point.
<jdstrand> echo -n "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('$ans1');" >> "${tmpfile}"
<Zarrathusa> magic not working
<soren> mjg59: Amazing. Until I told you about the issue it failed consistently. Now I can't make it break. How do you do it?
<soren> Zarrathusa: Stop putting a space at the beginning at the line.
<Chipzz> Zarrathusa: you're typing ' /join #ubuntu', you need to type '/join #ubuntu' (without a space in front of the /)
<Hobbsee> right, there we go
<jdstrand> soren: I think things are good as is.  I'll admit that I didn't think about echo and [ in terms of dash, as I have long used bash and pdksh, which are built in
* Hobbsee notes that he's obviously used to typing joins, else how did he get here?
<jdstrand> soren: so I definitely appreciate your bringing it up
<Chipzz> Hobbsee: was wondering that too; maybe he clicked on something instead of typing it?
<Hobbsee> Chipzz: usually requires some level of clue.
<persia> Hobbsee: In GUI tools, one can use Join...Chat Room :)
<Hobbsee> Chipzz: it's opera on windowd...
<Hobbsee> persia: in which case, joining #ubuntu wouldnt be hard
<Hobbsee> it's *defnietly* not listed there by default.
<Chipzz> Hobbsee: possible the server channel list?
<Hobbsee> Chipzz: windows opera?
<Hobbsee> there's *nothing* by default there that would point to linux, let alone a development channel of it.
<Chipzz> Hobbsee: haven't tried it, but I recall mirc having such a feature
<Chipzz> Hobbsee: but irssi also has the /list command
<Hobbsee> Chipzz: true
<soren> jdstrand: np. Thanks for checking up on it.
<kagou> ping Riddell
<Riddell> hi kagou
<kagou> hey Riddell , i'v reported Bug #150930
<ubotu> Launchpad bug 150930 in usplash "Black screen, and bad usplash.conf" [Undecided,New]  https://launchpad.net/bugs/150930
<kagou> Riddell, but i think that it's a ubiquity problem. i ask you if this is the case
<kagou> Riddell, if i understand, it's ubiquity which tell usplash, what's the resolution to write in usplash.conf. Am I wrong ?
<Riddell> kagou: not as far as I know (evand, cjwatson_, mjg59 could confirm)
<kagou> thank you Riddell
<seb128> iwj: yes, that's the icon that the artwork guys picked to use for lpi
<iwj> seb128: OK.  Just wanted to check, since it seemed like it might be a mistake.  Fair enough, thanks for confirmation.
<seb128> np ;)
<seb128> I don't really like those icons to be honest, the color are too faded or something, but I'm not an artwork guy
<mantiena-baltix> mjg59, hi again
<mantiena-baltix> mjg59, http://ftp.akl.lt/incoming/Baltix-stuff/Xorg.0.log-no-virtual
<mantiena-baltix> mjg59, I tested one more time - same problems, X starts with correct virtual desktop only when there is a Virtual line, with same resolution, like first Mode
<iwj> seb128: As I suspected, that "pigdin does not start" bug was due to it already being running.  I think the behaviour is wrong and have reported it in bug 150953.  HTH, thanks.
<ubotu> Launchpad bug 150953 in pidgin "menu item can sometimes do nothing" [Undecided,New]  https://launchpad.net/bugs/150953
<seb128> iwj: ok, right, that's better than what he did before (running again which was making you first instance disconnect from everywhere when the second was connection to those accounts)
<Hobbsee> iwj: HTH?
<Hobbsee> oh, hope that helps
<seb128> iwj: anyway, it should open the window list when you run it again to show that's it's using the running one
<evand> kagou: I beleive Riddell is right.
<kagou> evand, ok :) thanks
<mantiena-baltix> mjg59, are you alive ? I wanna help ubuntu developers to fix this important problem before 7.10
* Hobbsee killed him.  sorry.
<iwj> Hobbsee: That linux-ubuntu-modules-2.6.22 ftbfs is just archive skew then ?
<Hobbsee> iwj: yeah, they're in the process of fixing it.
<iwj> OK.
<Hobbsee> iwj: parts are approved, parts arent, iirc
<Hobbsee> yeah, the modules have gone thru now
<iwj> I just wanted to point out that closing the bug will put the package back on autopkgtest's to test list, so if you just leave it broken with the bug closed, autopkgtest will refile it ...
<iwj> Ah, good.
<iwj> But the turnaround is quite a while so you won't get caught out straight away.
<Kopfgeldjaeger> pitti: is your patch already included in the current daily? or, is it already uploaded?
<Hobbsee> iwj: oh, oops.
<pitti> Kopfgeldjaeger: "my patch"?
<Hobbsee> iwj: hopefully it will all be fixed before the new lot
<Kopfgeldjaeger> pitti: cryptsetup stuff, patch for pkgsel
<pitti> Kopfgeldjaeger: yes, that's in; I tested it this morning on the ISO, works like a charm now
<Kopfgeldjaeger> oh, how wonderful :-) thanks a bunch
<pitti> BenC: can you please upload lbm for -14?
<pitti> BenC: I'm currently beating the new kernel through the buildds and the archive, looks good so far
<BenC> pitti: rtg is working on it, we needed to nail down and test the alsa update in there
<pitti> BenC: oh, there's actually stuff in lbm already? I thought it was empty?
<BenC> pitti: we wanted to do a largish update of alsa preemptively for vendor support and to close some bugs without a huge round of testing :)
<Hobbsee> BenC: sounds like fun...
<Hobbsee> who needs sound anyway...
<pitti> BenC: oh, I see :/
<pitti> BenC: alright, thanks for the heads-up; I thought it would just be a 2-minute bump-abi no-brainer
<pitti> BenC: ia64 FTBFSed again, BTW (abi checker)
<BenC> pitti: right now it will be a 2-minute test then upload
<pitti> BenC: oh, no problem to delay it for another day or so in this case
<BenC> pitti: yeah, and kyle is doing a non-ABI kernel upload to get last minute sparc fixes in, a serious USB hang fix, and fix the ia64 ftbfs
<sladen> BenC: the last that happened, it opened as much as it fixed
<pitti> it doesn't affect CDs, it just generates some noise in the gutsy_probs.html report
<pitti> BenC: hm, another kernel? we need CDs RSN
<pitti> BenC: would it be too bad to release the RC with the currently built -14 kernel? (amd64 and i386 at least; sparc is easier, since it has much fewer test cases)
<BenC> pitti: this is mostly sparc related, so feel free to roll CDs, with a reroll after RC
<pitti> BenC: ah, we think alike :)
<BenC> :)
<kylem> in that case, we definitely shouldn't put this acpi patch in.
<BenC> kylem: agreed
<pitti> cjwatson_: can you please prepare a d-i upload for building against -14? lum is almost built
<BenC> kylem: don't want to risk a "works in RC, but not in release" situation :)
<kylem> indeed.
<kylem> it's ready to go now, just need to test the module checker
<evand> hrm, anyone else having connection issues with launchpad.net and ubuntu.com?
<pitti> evand: WFM
<evand> curious
<bddebian> Heya
<pitti> Mithrandir, evand: do you know the steps to do for building d-i against new kernel abi?
<evand> pitti: nope, sorry
<mathiaz> pitti: do you plan to create new server isos ?
<pitti> mathiaz: we have a new kernel, with lots of sparc fixes, so yes
<Mithrandir> pitti: bump the kernel version in the seeds, do a no-change upload, iirc.
<mathiaz> pitti: ok. Thanks.
<pitti> ogra: do you want to fill your CDs with langpacks a bit?
<pitti> cjwatson, Mithrandir: seeds mangled for -14
<pitti> Mithrandir: apparently it's changing all the {BASE,KERNEL}VERSION in build/config/**
<Mithrandir> pitti: sure that doesn't happen automatically?
<pitti> no, I mean "it needs to be done"
<ogra> pitti, i was waiting for doko's ok that icedtea is ready for inclusion to see whats left then
<mantiena-baltix_> mjg59, are you alive ? I wanna help ubuntu developers to fix displayconfig-gtk problem before 7.10
<doko> ogra: as cjwatson said: it won't be in gutsy main
<davmor2> ogra: your include a free rapper wow your generous :)
<ogra> doko, ok
<ogra> pitti, then yes, i think i'll do some math today :)
<pitti> ogra: no need to, I have a clever script which calculates it
<pitti> http://people.ubuntu.com/~pitti/scripts/langpacksize
<pitti> ogra: ^ "./langpacksize MB" -> list with Megabytes; just ./langpacksize gives a list with byte precision
<ogra> heh, i have something similar but more genereic
<mjg59> bryce: Hm. I'm not suer switching to -intel on <915 was a great plan.
<mvo_> bryce: that reminds me, if -intel is used by default on i855,  I will have to blacklist that card for compiz because of the suspend/resume texture problem
<mvo_> bryce: it would be cool if you could update me on this
<cjwatson_> pitti: will do now
<\sh> mjg59, how would you re-start the udev daemon in an initramfs ? ...
<cjwatson_> pitti: unless you beat me to it
<pitti> cjwatson_: oh, thanks (seeds should be ok already)
<\sh> mjg59, i need to catch up with newly created raid volumes...so it needs somehow a restart
<cjwatson_> Mithrandir: it's not a no-change upload
<cjwatson_> the kernel version is hardcoded in several files
<cjwatson_> pitti: ok
<mantiena-baltix_> cjwatson_, it seems bug #64887 should be reopened...
<ubotu> Launchpad bug 64887 in ubuntu-cdimage "/boot/initrd.img*should be removed from filesystem.squashfs" [Undecided,Fix released]  https://launchpad.net/bugs/64887
<cjwatson_> pitti: all merged too?
<cjwatson_> (to gobuntu too?)
<pitti> cjwatson_: oh, I forgot gobuntu; rest is merged
<Mithrandir> cjwatson_: hence my "iirc".
<mantiena-baltix_> I found /boot/initrd.img.bak in 7.10 beta compressed filesystem ...
<mjg59> \sh: I know nothing about udev
<mjg59> mvo_: Hm. Which cards are we actually enabling compiz on?
<mvo_> mjg59: all intel < i965
<mjg59> mvo_: But not 855?
<cjwatson_> pitti: uploaded
<mvo_> mjg59: currently we do, but there is a bug that after suspend/resume the texture get into a very bad state on the i855 with the intel driver
<mvo_> mjg59: so it is probably best to blacklist this card too
<mjg59> mvo_: Ok
<mvo_> mjg59: the interessting bit is, that it seems to be not happening with i810
<mantiena-baltix_> mjg59, have you looked at http://ftp.akl.lt/incoming/Baltix-stuff/Xorg.0.log-no-virtual ?
<pitti> cjwatson_: checking out and merging gobuntu seeds now
<pitti> cjwatson_: done
<cjwatson_> mantiena-baltix_: sure, feel free
<mantiena-baltix_> cjwatson: ok
<tkamppeter> hi pitti,
<pitti> hi tkamppeter
<tkamppeter> pitti, I want to talk with you about some simple polishing action for Gutsy. See bug 150985.
<ubotu> Launchpad bug 150985 in ghostscript "Printer setup tools list PPDs for which there are no driver executables in Ubuntu" [High,Confirmed]  https://launchpad.net/bugs/150985
<tkamppeter> There rae some PPDs generated by Foomatic for which we do not have the drivers. Most of this is easy to correct, by deleting the appropriate driver XMLs from the foomatic-db package and by fixing a trivial "make install" bug of Ghostscript.
<ogra> pitti, seeds for server are updated (added  es, de, fr, pt, xh, ru and hr)
<pitti> ogra: ah, great
<pitti> tkamppeter: window for non-fatal bug fixes is pretty much closed, I'm afraid
<tkamppeter> pitti, regression is not possible on this one. It does only remove files from foomatic-db and adds files to ghostscript which Feisty's ghostscript shipped, fixing a Feisty -> Gutsy regression.
<pitti> tkamppeter: please attach some debdiffs to the bug and instructions which are independent (i. e. whether we could ship RC with the new ghostscript, but update foomatic post-RC, or so
<superm1> mvo_, i've returned
<tkamppeter> pitti, will do so. I will generate the packages and debdiffs and upload them onto my server and then link them to the report.
<pitti> tkamppeter: thanks
<tkamppeter> After that we can discuss here on the IRC and decide.
<tkamppeter> Whether it gets in or better a spec for Hardy (and a demo for OpenPrinting's work on printing testing and validation tools.
<gnomefreak> what package would a bug be filed under for a ldconfig error?
<gnomefreak> during process triggers
<mvo_> superm1: in advanced installation, what will I have to tell it so that it installs additional packages?
<superm1> mvo_, tell it to take off a few plugins, take off the themes, and check vnc, nfs
<superm1> change the video driver to something else
<superm1> and it will make a ton of package changes then
<gnomefreak> mvo_: is apt running the process triggers or does it call on something else to run them?
<mvo_> superm1: ok, nice
<mvo_> gnomefreak: triggers are done by dpkg, apt has no control over those
<gnomefreak> yeah sorry thats what i meant
<mantiena-baltix> mjg59, do you have some time to help to solve Virtual screen problem ?
<gnomefreak> ok ill cahnge it to dpkg than ty
<mvo_> gnomefreak: wat is the bugnumber?
<gnomefreak> mvo_: bug 150997
<ubotu> Launchpad bug 150997 in xorg "nvidia driver issues" [Undecided,New]  https://launchpad.net/bugs/150997
<mvo_> superm1: ok, thanks. its running now
<superm1> okay great.
<superm1> mvo_, did you go for real hardware, or is this a vm?
<mvo_> gnomefreak: this sounds like the real issue here is that something is wrong with the nvidia package
<mvo_> superm1: a VM, is that bad?
<superm1> mvo_, no not at all.
<gnomefreak> mvo_: with the -11 package but shouldnt dpkg overwrite the -11 for the -19?
<superm1> mvo_, i was going to recommend it actually, doing it on real hardware it has a little less frequent of an occurrence
<mvo_> superm1: I might add that I'm pretty impressed with the mythbuntu CD, it looks really nice
<superm1> mvo_, thx :)
<mvo_> gnomefreak: hm, that looks strange indeed
<mvo_> superm1: and then it hangs after "ldconfig deferered processing"?
<superm1> mvo_, yeah
<superm1> which from what i narrowed down to was that call to cache.open(None)
* gnomefreak not real sure what an ELF file is but i would have though everything but config would have been overwritten but i agree it very well can be a nvidia issue
* iwj 's ears prick up.
<iwj> My http request is important to launchpad ... please hold ...
* mvo_ giggles
<superm1> and then goes into python-apt code and i want to say it was line 62 or os that it stopped at and jumped into C, so i grabbed you :)
<iwj> gnomefreak: You've got this system to hand right now ?
<iwj> Can you   dpkg -S /usr/lib/libGL.so.100.14.11  ?
<gnomefreak> iwj: no the guy left
<iwj> Damn.
<gnomefreak> iwj: i slent 1hour or so with him
<gnomefreak> spent
<iwj> Are these packages from the archive ?
<gnomefreak> yeah
<mvo_> superm1: it looks like for some reason the cdrom method is stuck - let me debug further
<gnomefreak> iwj: i left a comment on bug to run that command and post output and if he sees me to ping me
<iwj> nvidia-glx-new_100.14.19+2.6.22.4-13.6_i386.deb contains /usr/lib/libGL.so.100.14.19
<mvo_> superm1: when I kill the cdrom process it seems to be happy again
<superm1> hm interesting
<gnomefreak> right bu 100.11 doesnt so wouldnt dpkg provide it from new package?
<iwj> gnomefreak: No need any more, I've got the info from the archive.
<gnomefreak> ah ok
<superm1> mvo_, so perhaps why this doesn't occur on standard gutsy disks then is because it doesn't use the cdrom method but instead a http method
<mvo_> superm1: its a all a bit mysterious, I will appy some debug options to apt and see what it spits out.
<mvo_> superm1: yes, that sounds plausible
<iwj> gnomefreak: Hmm, I can't reproduce it here with those files.
<mvo_> superm1: could you give me the url of your source again?
<superm1> mvo_, source of ubiquity?
<mvo_> superm1: yes, of your branch of it
<superm1> mvo_, actually that is running trunk
<superm1> we have no additional things added to it outside trunk
<gnomefreak> iwj: ive never seen it but he swears it was working until latest nvidia-glx-new and kernel updates
<superm1> i'll grab you the trunk url then
<gnomefreak> -13 kenrel
<mvo_> superm1: oh, cool
<iwj> gnomefreak: It's almost like the file is corrupted somehow.
<superm1> mvo_, here is the LP page: https://code.edge.launchpad.net/~ubuntu-installer/ubiquity/trunk
* mvo_ updates his checkout
<superm1> mvo_, the only thing i've been using our branch for lately was to build with that cache.open call commented out, so we could get the beta out in time
* gnomefreak has a strange feeling about this
<iwj> gnomefreak: I don't think triggers are relevant but I'll take an interest in this bug.
<gnomefreak> iwj: when i see him again ill run through a few other things. he used envy in feisty and upgraded but he said he had our drivers working im wondering if envy didnt leave something behind after removing the modules although envy doesnt allow you to do that but maybe the fix we added to u-m corrupted it?
<iwj> envy doesn't allow you to do what ?
<iwj> Does envy divert anything ?
<gnomefreak> if that is the case than we have issues
<iwj> Or mess with these files ?
<iwj> What fix to u-m ?
<gnomefreak> iwj: envy doesnt remove ht emodules it builds
<gnomefreak> s/ht/the
<iwj> By module you mean kernel modules ?
<gnomefreak> yes
<iwj> I don't think that's relevant here.
<iwj> Unless I suppose the user has kernel-bug-induced fs corruption.
<iwj> But it's a bit early to start thinking seriously about that.
<gnomefreak> true
<cjwatson_> mjg59: any more ideas on the synaptic thing? IRC has been up and down for me today
<mjg59> cjwatson_: Which one? Failure to tap to click?
<mjg59> Nope. Does the vertical scroll option work?
<superm1> mvo_, are you following the layout of code progression in ubiquity when installing mythbuntu, or did you want me to explain ?
<mvo_> superm1: I'm fine, thanks
<cjwatson_> mjg59: nope
<_MMA_> cjwatson_: Hi Colin. Did you get my message re: Tasksel options on todays Ubuntu Studio build? "print server" still shows. :(
<cjwatson_> _MMA_: I didn't
<mvo_> superm1: I will have to leave for dinner soon, but I can reproduce it now and that is a good step
<_MMA_> cjwatson_: Was a PM to you're normal nick. Oh well.
<cjwatson_> it is inaccessible to me today
<mjg59> cjwatson_: Hrmph. Ok.
* mjg59 upgrades gnome-control-center
<superm1> mvo_, awesome, well i'm glad we're headed in the right direction now :)
<cjwatson_> _MMA_: oh, I forgot to deploy my debian-cd changes ... fixed
<_MMA_> cjwatson_: Ahh.. :)
<cjwatson_> _MMA_: also, I trust you noticed that there wasn't an Ubuntu Studio CD build today ;-)
<cjwatson_> CD builds are all on manual for the upcoming RC
<_MMA_> lol. Crap. I did grab the one from the 8th. :)
<cjwatson_> I'll do another one once the new kernel is all in place
* _MMA_ needs to look at a calender more.
<cjwatson_> building one now would be unhelpful
<_MMA_> cjwatson_: Sure. np. I also attached a new install splash to bug 150736.
<ubotu> Launchpad bug 150736 in ubuntu-cdimage "Install splash image on Ubuntu Studio dailies is fuzzy." [Undecided,New]  https://launchpad.net/bugs/150736
* _MMA_ still doesnt know the right term for that image.
<cjwatson_> _MMA_: the pcx? "gfxboot background image"
<_MMA_> Ahh... Thanx.
<Kopfgeldjaeger> pitti: i can confirm that it works super :-) but there's an error from cryptsetup; "failed to setup lvm device". see http://img9.myimg.de/BildschirmfotoQEMU26ba8a.png
<Kopfgeldjaeger> pitti: but everything works as it should
<cjwatson_> _MMA_: done
<pitti> Kopfgeldjaeger: right, known; that's just a cosmetical error
<pitti> Kopfgeldjaeger: sorry, I didn't manage to fix that any more; looks scary, but can be ignored
<Kopfgeldjaeger> pitti: yeah. it just would be nice if it wouldnt appear. but, while it does no harm..
<_MMA_> cjwatson_: Thank you.
<tkamppeter> pitti, foomatic-db on its way to my server ...
<superm1> cjwatson, is there syntax to set an or between packages in a seed branch, something like: * (network-manager-gnome) || * (network-manager-kde) ?
<Riddell> how would it know which one to pick?
<superm1> well i would assume the first one
<superm1> but it was more intended for when building a meta, so that it ended up with either as an option
<superm1> eg if someone is installing that meta on top of kde, they won't need to pull in the nm for gnome
<cjwatson_> superm1: no
<superm1> cjwatson, ok.
<Kopfgeldjaeger> pitti: the line is in cryptsetup source/debian/initramfs/cryptroot-script, line 214. activate_vg fails because its not installed
<cjwatson_> superm1: the only way to do that at present is to use an intermediary package
<superm1> cjwatson, okay i'll defer worrying about it for now then
<bryce> mjg59: do you think we should switch back for now?
<mjg59> bryce: Well, I think mvo would prefer it
<bryce> mvo_: does compiz work ok on it with i810?
<davmor2> bryce yes
<davmor2> bryce sorry hit return as I got up. there is a problem with the graphics on kubuntu.  I have added photo's to bug 127008
<ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)" [High,Confirmed]  https://launchpad.net/bugs/127008
<Kopfgeldjaeger> pitti: sorry, i was absolutely wrong... of course activate_vg isnt installed, its just a bash function
<pitti> Kopfgeldjaeger: right, that script tries to do a lot; but with our modern udev that isn't necessary, it'll happen automatically
<mantiena-baltix> Riddell, are you configured your X with guidance ? if yes, then maybe you can put your xorg.conf somewhere ?
<iwj> gnomefreak: re bug 150997, the submitter seems to be around now.  Do you happen to know their nick ?
<ubotu> Launchpad bug 150997 in dpkg "nvidia driver issues" [Undecided,Incomplete]  https://launchpad.net/bugs/150997
<Kopfgeldjaeger> pitti: yeah, it creates the UUID=x files in /dev/mapper/ for example
<keescook> pitti: (hi!) continuing a conversation you had with superm1 a few days ago, his lirc patches look okay to me.  shall I upload it?
<pitti> keescook: at this point I won't accept any nonessential patches any more which affect RC CD images; we might let them slip into post-RC
<keescook> pitti: is lirc on the CD?
<Kopfgeldjaeger> pitti: im currently testing what fails
<keescook> we need an "rseed" like "rmadison" or something.
<pitti> keescook: yes, liblircclient0 is
<keescook> pitti: aaah, okay.
<pitti> keescook: just check the .list/.manifest files on cdimage
<keescook> pitti: okay
<iwj> gnomefreak: I have deassigned that bug from dpkg.  Is there an appropriate target in Launchpad for bugs in envy ?
<Kopfgeldjaeger> pitti: the sanity checks fail. i guess it's checking if /sbin/vgchange does exist while / is not yet mounted, and at least that fails
<pitti> Kopfgeldjaeger: this whole shell code should entirely go away
<mathiaz> keescook: it seems that apparmor wasn't downgraded to 2.0.1
<mathiaz> keescook: am I correct ?
<keescook> mathiaz: that's right.
* rulus is back (gone 00:00:31)
<Riddell> mantiena-baltix: no, but I see glatzor is online
<glatzor> evening Riddell
<keescook> rulus: can you disable your away/back messages please?
<glatzor> mantiena-baltix: what can I do for you?
<Riddell> hi glatzor, mantiena-baltix and mjg59 have been grumbling about guidance-backends
<rulus> keescook: sorry, that was a mistake in my setting, corrected now I think
<mjg59> I can work around the worst of it in gdm, I think
<mdke> elmo: around for the meeting?
<elmo> oh
<glatzor> Riddell: mjg59: mantiena-baltix: The displayconfig part of guidance, right? Is there an urgent problem?
<mjg59> glatzor: The whole "Write a maximum-sized virtual and then let the screen pan" thing kind of sucks
<mjg59> As described in the comment at line 253 of displayconfig-restore
<mjg59> But also other things, like flagging i740 as dual-head
<bryce> heya glatzor
<mathiaz> keescook: I've got a couple of fix in my bzr branch.
<mathiaz> keescook: could you review them after rc ?
<keescook> mathiaz: yup, certainly.
<gnomefreak> iwj: no envy target that i know of last i heard he ran his own place for them but give me a few and ill look it up
<glatzor> hello bryce
<gnomefreak> iwj: RE: bug 150997 i added envy task and left ubuntu there, envy has to be added from projects otherwise LP doesnt know it
<ubotu> Launchpad bug 150997 in ubuntu "nvidia driver issues" [Undecided,New]  https://launchpad.net/bugs/150997
<iwj> gnomefreak: IC.  OK.  Well, I'll set the Ubuntu task to Invalid then I suppose.
<iwj> gnomefreak: Thanks.
<gnomefreak> iwj: im there i can do it if you like
<bryce> pitti or slangasek, xorg 7.2-5ubuntu13 has been uploaded, but could one of you let it into the archive?
<bryce> debdiff here:  http://people.ubuntu.com/~bryce/Uploads/
<pitti> bryce: sorry, it's a little late for RC
<pitti> bryce: change looks ok, so I'll let it in as target of opportunity, but no gurarantees
<bryce> thanks, this is pretty critical, else bulletproof-x won't launch properly if X fails on the cd install
<bryce> pitti: is it too late for any further changes for gutsy?  we've been running into stability issues for -intel on some hardware (see mvo and mjg59 discussion above), and I'm wondering if there's time for us to consider flipping back to i810 for those cards
<pitti> bryce: no, just late for RC
<bryce> ah, ok
<glatzor> mjg59: sorry, I was in the kitchen. do have got any ideas how to avoid this? espcially having randr 1.2 hotplug in mind.
<mjg59> glatzor: Modify gdm and kdm
<glatzor> sorry, I have not tested guidance on a i740 chipset yet. so I just assumed that the one who wrote the code was right.
<glatzor> mjg59: the i740 cannot support dualhead at all, or is there actually no dual head card available?
<glatzor> the i740 driver cannot ...
<mantiena-baltix> glatzor, hi, I was waiting for you all the day ;)
<glatzor> mantiena-baltix: we had a little "oktoberfest" at work so I had to do an extra shift :)
<mantiena-baltix> ;)
<glatzor> mantiena-baltix: anything evil?
<mantiena-baltix> glatzor, so, if you still can think after octoberfest we can talk a little :)
<mantiena-baltix> glatzor, yes - displayconfig-gtk generates wrong xorg.conf , at least xorg's nv driver doesn't work correctly with that xorg.conf
<mjg59> mantiena-baltix: I almost have it fixed
<mantiena-baltix> look at http://ftp.akl.lt/incoming/Baltix-stuff/xorg.conf
<glatzor> mantiena-baltix: oh, that is not nice. for dual head or single head?
<mjg59> For gdm, anyway
<mantiena-baltix> glatzor, for single, not tested for dual
<mantiena-baltix> mjg59, how you fixed it?
<glatzor> mantiena-baltix: the virtual size issue?
<mjg59> By getting gdm to handle that situation
<mantiena-baltix> glatzor, yes, main issue is virtual size, also I found other important issues, like displayconfig-gtk crashes
<glatzor> mjg59: a large change set?
<glatzor> mantiena-baltix: have you already filled but reports?
<mantiena-baltix> mjg59, so, if I start X without gdm I will still get too large desktop ?
<mantiena-baltix> glatzor, there are already several bugreport's, people often call this issue "incorrect resolution", etc
<mjg59> mantiena-baltix: Yes
<Kopfgeldjaeger> pitti: that debdiff ( http://xeve.de/mute-cryptsetup-lvm.debdiff ) mutes the error message. of course it's not "clean", but i think, if noone has a better solution, that cosmetical problem shouldnt appear in gutsy (final)
<mjg59> mantiena-baltix: So don't do that
<Kopfgeldjaeger> s/that/that that/
<mantiena-baltix> mjg59, :( not all people use gdm...
<mjg59> Then things are going to be broken for them
<mantiena-baltix> :(((
<mantiena-baltix> mjg59, could you tell me why we can't find the real solution, which would work with all software, not only with gnome/gdm ?
<mjg59> mantiena-baltix: Because there is no "real solution"
<mjg59> If you want to be able to increase the resolution at run-time, you need a larger virtual
<mjg59> The only other place it could be done is in the X server
<mantiena-baltix> mjg59, you mean if I wanna able to increase resolution without restarting X ?
<mjg59> Yes
<mjg59> Wow. Worked first time.
<mantiena-baltix> mjg59, so, this is an X server upstream issue and real solution would be to patch X :)
<glatzor> i am away for some minutes
<mjg59> mantiena-baltix: No, real solution is to make drivers use randr1.2
<mantiena-baltix> mjg59, nv driver still doesnt' use randr 1.2?
<mjg59> Not for anything before the 8000, no
<mantiena-baltix> you mean, that nv driver uses randr 1.2 for newest Geforce cards, but doesn't use randr 1.2 for older, like Geforce 2 or Geforce 4 ?
<mjg59> Yes
<mantiena-baltix> mjg59, thank you very much, at least I understand this mystics, I think :)
<glatzor> bryce: mjg59: mantiena-baltix: Is there anything I can do for you?
<mantiena-baltix> mjg59: so, when nv driver will support randr 1.2 then virtual desktop will be 1024x768 with this conf file http://ftp.akl.lt/incoming/Baltix-stuff/xorg.conf ?
<bryce> sorry, I was distracted by another critical issue; reviewing backlog
<mantiena-baltix> glatzor, it would be better if you could do for displayconfig-gtk, not for me ;)
<tkamppeter> pitti, I have everything uploaded now for bug 150985, see the last comment there.
<ubotu> Launchpad bug 150985 in ghostscript "Printer setup tools list PPDs for which there are no driver executables in Ubuntu" [High,Fix committed]  https://launchpad.net/bugs/150985
<mjg59> mantiena-baltix: Yes
<mantiena-baltix> mjg59, so, it seems I should report bugs on all xorg drivers, where this problem exists, right?
<mjg59> mantiena-baltix: You could, but I doubt it would make things happen any faster
<mantiena-baltix> mjg59, at least this helps people know, where is real problem, because I though, that this is displayconfig-gtk or guidance-backends problem
<glatzor> mjg59: so should we add a white list handling for known to work drivers?
<mjg59> glatzor: Mm?
<mjg59> Oh, right. No, that would still defeat the point of that code.
<glatzor> mjg59: should we only set the virtual size for drivers about which we know that they are working
<mjg59> glatzor: No, that would defeat the point of that code
<glatzor> mjg59: hm?
<mjg59> If you don't set the virtual to be larger than the screen size, then you can't increase the resolution at runtime
<tkamppeter> pitti, still there?
<pitti> tkamppeter: on the phone
<glatzor> mjg59: but won't having to restart the xserver be less annoying than having a "broken" desktop?
<mjg59> glatzor: I've got a patch that avoids the issue
<glatzor> mjg59: but for gdm only, right.
<glatzor> mjg59: bryce: mantiena-baltix: sorry, but I have to get up early. So I have to leave. See you. Night.
<mantiena-baltix> glatzor, ok, hope to meet you on IRC tomorrow :)
<mjg59> glatzor: KDE works around it in some other way, I assume
<mantiena-baltix> mjg59, maybe you have patched gdm packages ? I wanna test it before Ubuntu RC will be released :)
<mjg59> It won't be in RC
<mantiena-baltix> mjg59, so, we must test it even more, right ?
<mjg59> http://www.codon.org.uk/~mjg59/tmp/gdm
<mantiena-baltix> mjg59, thanks
<tkamppeter> pitti, re-run the test script after installing the fixed packages and now no problem with missing drivers or not installing test queues any more.
<mantiena-baltix> mjg59, could you build 386 packages ? please ;)
<mjg59> mantiena-baltix: No. The full source is there.
<pitti> tkamppeter: re
<mantiena-baltix> mjg59, btw, when you are planing to put your patch to official ubuntu archive ?
<mjg59> Yes
<pitti> bryce: ok, xorg beat sound-juicer on the buildds, so its in
<bryce> yay, thanks!
<mantiena-baltix> mjg59, short answer about time :)
<superm1> bryce, did you also have a gdm upload too?
<superm1> is that going in post rc then?
<superm1> or was it just the xorg
<bryce> no, the change I mentioned is in xorg
<superm1> ah okay
<superm1> great that got in.
<bryce> the files updated are in /etc/gdm/, but it's not a change to the gdm package
<superm1> ah.  bryce, ubiquity 1.6.4 was uploaded this morning and has the fix to copy over debconf during install too.
<bryce> so just need to check that things are getting copied in correctly, and that displayconfig-gtk is writing out xorg.conf's properly
<pitti> tkamppeter: the patches look fine; I just don't have time ATM to sponsor them
<pitti> tkamppeter: can you please ping around and ask for a sponsor?
<pitti> tkamppeter: they won't make it to the RC (unless we have to rebuild the CDs), but post-RC is fine for me
<pitti> tkamppeter: btw, please sub ubuntu-release to such bugs (I did that now)
<kagou> tkamppeter, what a great work on Bug #150985 !
<tkamppeter> pitti, does post-RC still mean for Gutsy?
<ubotu> Launchpad bug 150985 in ghostscript "Printer setup tools list PPDs for which there are no driver executables in Ubuntu" [High,Fix committed]  https://launchpad.net/bugs/150985
<tkamppeter> pitti, I have subscribed bug 150985 to both ubuntu-release and ubuntu-main-sponsors.
<heno> evand, Riddell: bug 151051 doesn't look good
<ubotu> Launchpad bug 151051 in ubiquity "ubiquity crashed with NameError in run()" [Undecided,New]  https://launchpad.net/bugs/151051
<heno> ubiquity-kde crashes on start
<evand> hrmm
<tkamppeter> anyone here who can upload the foomatic-db, foomatic-db-engine, and ghostscript packages fixing bug 150985 for me? Thanks. doko? Riddell? ...?
<evand> investigating now
<ubotu> Launchpad bug 150985 in ghostscript "Printer setup tools list PPDs for which there are no driver executables in Ubuntu" [High,Fix committed]  https://launchpad.net/bugs/150985
<evand> oh wow
<evand> that's an incredibly stupid mistake on my part
<Riddell> tkamppeter: could do, at the usual place?
<tkamppeter> Riddell, all links in my last posting in bug 150985
<ubotu> Launchpad bug 150985 in ghostscript "Printer setup tools list PPDs for which there are no driver executables in Ubuntu" [High,Fix committed]  https://launchpad.net/bugs/150985
<tkamppeter> kagou, with these fixes in Gutsy all printers listed in the setup tools will simply work. Printers for which we have no driver will not appear in the setup tools.
<kagou> tkamppeter, indeed it's a great enhancement
<kagou> tkamppeter, thank you for your support on my wiki page. I'm approved as a member since 10mns :) (thanks pitti too)
<evand> pitti: I'm afraid I'm going to have another ubiquity upload as bug 151051 completely breaks the KDE UI
<ubotu> Launchpad bug 151051 in ubiquity "ubiquity crashed with NameError in run()" [Undecided,New]  https://launchpad.net/bugs/151051
<evand> It was a bad copy and paste job by myself, I'm terribly sorry.
<evand> heno: thank you for pointing it out
<heno> evand: np, sorry for not testing this part sooner
#ubuntu-devel 2007-10-10
* Starting logfile irclogs/ubuntu-devel.log
<kagou> Good morning
<dholbach> good morning
<joshk> is ubiquity-automation working in any of the gusty prereleases?
<joshk> *gutsy
<pitti> Good morning
<StevenK> Morning pitti
<Hobbsee> morning pitti!
* pitti hugs the Australians
* holycow hides the sheep
<RAOF> Hey pitti
<kagou> morning pitti
<slangasek> ogra: anything new since beta that should be added to the announcement for the RC (as opposed to the release notes)? https://wiki.ubuntu.com/GutsyGibbon/RCAnnouncement
* StevenK grumbles.
* Hobbsee hugs the pitti
<StevenK> virtualbox-ose-modules fails against -14 on i386
<pitti> StevenK: eww, ABI change?
<StevenK> pitti: Actually building the module fails, but works on amd64
<YokoZar> Is anyone else getting a serious rendering issue in Firefox?  http://tuzakey.com/~scott/offcie.png
<pitti> YokoZar: remind us what's wrong with that?
<pitti> ooh, "office"
<pitti> yeah, it handles ligatures badly
<YokoZar> Yeah.  It's been doing that for a couple of weeks now.
<YokoZar> Is it just my box though, or do you get that too?
<pitti> I get it, too
<YokoZar> Hmm.  Well if Firefox is rendering it weird...
<YokoZar> I'm assuming it's not a problem with http://www.digg.com/linux_unix :)
<seb128> might be bug #37828?
<ubotu> Launchpad bug 37828 in firefox "Text rendered incorrectly in presence of ligatures and justified text" [Medium,In progress]  https://launchpad.net/bugs/37828
<slangasek> I see it with the "sans-serif" font, and not with Bitstream Vera Sans
<slangasek> I guess I goofed when I assumed that I had inherited non-default font settings in my profile...
<YokoZar> seb128: yup, that's exactly it.  Office uses the ffi ligature, so it comes out all weird.
<slangasek> wow, there's an "ffi" ligature?  that seems elaborate
<pitti> well, LaTeX has those, too (ffi and ffl), they are quite common
<pitti> except that they actually look *good* in LaTeX :-P
<slangasek> heh
<slangasek> how little I seem to know about fonts
<seb128> the bug has a dejavu suggested workaround
<\sh> keescook, ping bug 150848 will do
<ubotu> Launchpad bug 150848 in dircproxy "[CVE-2007-5226]  dircproxy segfault on blank /me" [Undecided,Confirmed]  https://launchpad.net/bugs/150848
<pitti> but with this, we should better have disabled ligatures in ffox
<YokoZar> Either way, it's a regression compared with Feisty, so the patch needs to go in until we can wait for Hardy and Firefox 3
<YokoZar> or some sort of workaround, maybe not that patch
<tepsipakki> duh? amd64 does not have 'arch' command?
<slangasek> seb128: which workaround, the ligature disabling?
<YokoZar> sabdfl: Will you be at FOSScamp, UDS, or both?
<slangasek> tepsipakki: what do you expect "arch" to do?
<pitti> tepsipakki: what is "arch"?
<tepsipakki> slangasek: return "x86_64"
<slangasek> you mean "uname -m"?
<tepsipakki> no
<tepsipakki> well
<pitti> but that's what it does :)
<tepsipakki> maybe that works as well
<tepsipakki> but, why does i386 util-linux have arch and amd64 does not?
<liw> my i386 ubuntu doesn't have "arch" either
<tepsipakki> ah
<tepsipakki> so it was dropped
<tepsipakki> feisty has it
<pitti> ah, in my dapper chroot it works
<seb128> slangasek: yes
<tepsipakki> "arch is equivalent to uname -m"
<tepsipakki> says man arch
<slangasek> dropped in 2.13~rc3 or earlier
<tepsipakki> right, time to use uname then :)
<\sh> doko, please review bug 76807, think you forgot it with the last upload...
<ubotu> Launchpad bug 76807 in bash "/etc/skel/.bashrc sets HISTCONTROL twice in succession." [Wishlist,Confirmed]  https://launchpad.net/bugs/76807
<soren> Question: I see https://edge.launchpad.net/ubuntu/gutsy/+package/linux-ubuntu-modules-2.6.22-14-virtual but I don't see it in the archive, and it's not in https://edge.launchpad.net/ubuntu/gutsy/+queue either.
<soren> Where could it have gone?
<slangasek> linux-ubuntu-modules-2.6.22-14-virtual | 2.6.22-14.35 |         gutsy | i386
<sabdfl> YokoZar: both, IIRC
<sabdfl> and looking forward to it :-)
<pitti> slangasek, soren: ah, with -14 it slipped to main again, demoting
<pitti> (it is uninstallable in main)
<soren> pitti: Oh, is the linux-image-virtual in universe, too?
<soren> slangasek: Where is that from?
<pitti> soren: ah, no; just -rt and -xen, sorry
<slangasek> soren: drescher
<soren> pitti: Why is it uninstallable in main then?
<slangasek> but I concur that it's not visible on my mirror
<pitti> soren: no, I misread; just lum -ume, -xen, and -rt are; -virtual is just not seeded
<pitti> soren: I wonder why, linux-image-virtual (from -meta) is in main
<pitti> ah
<soren> pitti: It's not supposed to?
<pitti> linux-virtual does not depend on linux-ubuntu-modules-virtual
<pitti> soren: well, linux-image-virtual should pull in l-u-m-2.6.22-14-virtual
<pitti> similar to -generic
<soren> Sure.
<pitti> so that's a bug in linux-meta
<soren> -virtual didn't exist 24 hours ago.
<doko> \sh: yes, if I need another upload
<soren> ...so it's not that odd, really. It still needs to be fixed, though.
<soren> pitti: Oh, I need guidance here. What I need to do now is to poke the kernel team to make the appropriate changes to linux-meta.. Should I do anything to the seeds?
<pitti> soren: no, seeds should be fine; it's just adding the dependency
<soren> pitti: Rock. And until then, I won't hit the archive at all or is that a separate issue
<soren> ?
<ogra> slangasek, * Completely redone thin client login manager with themes for all *ubuntu flavours and support for autologin as well as an optional unencrypted graphics transport mode for low level hardware
<ogra> slangasek, (for the edubuntu section)
<cjwatson> slangasek: (scrollback) bdmurray is correct, the help text is in debian-installer
<YokoZa1> sabdfl: Great, we'll finally meet :)
<soren> Is it kosher to brag about stuff that's only available in the alternate installer in the release notes? If so, I think we should definitely put the new crypt-lvm magic in there.
<slangasek> cjwatson: yah, I opened a bug on it for you :)
<pitti> soren: it is in the archive, it just wants to move to universe
<slangasek> ogra: processing
<cjwatson> mdke: (scrollback from yesterday) wasn't the major issue it was made out to be :-), it was just that gfxboot-theme-ubuntu needed a translation update
<ogra> slangasek, * edubuntu supports collaborative document editing with the newly included gobby editor
<pitti> soren: just about to do that
* soren hugs pitti
<pitti> soren: as a small note only
<ogra> slangasek, * all packages needed to build a moodle server are shipped on the server CD now
<ogra> i think thats enough for an RC announcement :)
<slangasek> ogra: tsk, trying to crowd out the other flavours, are you? :)
<ogra> heh
<soren> pitti: Gah... Yes, it's in the archive. I sometimes forget that my workstation is amd64 and I was looking at "apt-cache madison"'s output which obviously didn't show it.
<ogra> i could add more but then the final announcement is less exciting ;)
<soren> My bad.
<pitti> hi ogra
<ogra> hey pitti
<pitti> ogra: any idea how to get some 100 MB off the edubuntu DVDs?
<ogra> not yet, was on my list for today to look at it ...
<slangasek> ogra: the first point is incorporated, please review my wording changes to make it fit the format
<ogra> pitti, why did they grow again ? we were down to 50M iirc
<slangasek> ogra: for gobby/moodle, I have a hard time understanding why these are important to include in the announcement, could you please provide a "why" for each of these?  (Feel free to update the wiki directly)
<pitti> ogra: I just looked at the rounded file size (4.4 GB)
<ogra> edubuntu/dvd: gutsy-dvd-i386.iso oversized by 61544448 bytes (4761917440)
<ogra> thats thats yesterdays state
<ogra> slangasek, they arent that important :)
<slangasek> k then :)
<pitti> slangasek, soren: I added a stanza about it; could use some unDenglishification and general improving, though
<slangasek> bryce: is a fix for #148231 inbound (post-RC)?
<slangasek> (xresprobe)
<tepsipakki> slangasek: he's asleep atm
<soren> pitti: I keep misplacing the link to that page...
<tepsipakki> slangasek: it's not uploaded yet?
<ogra> mjg59, http://cvs.fedoraproject.org/viewcvs/devel/gnome-power-manager/gnome-power-manager-2.20.0-expected-return-types.patch?rev=1.1&view=auto
<pitti> soren: you mean https://wiki.ubuntu.com/GutsyGibbon/RC ?
<soren> pitti: That's the one. Thanks.
<slangasek> tepsipakki: it's not in unapproved, so either it's already in and the bug didn't get closed, or it's not uploaded
<ogra> mjg59, what do you think ? should we pull that in for final ? it extends your uint patch it seems
<tepsipakki> slangasek: right, seems that it isn't uploaded yet
<Riddell> doko: looks like icedtea lacks a bzip2 dependency
<mvo> superm1: I may have a fix for you
<doko> Riddell: lp is so pedantic ... fixed
<tepsipakki> slangasek: I can wrap up a new xresprobe and upload it later today (post-RC)
<slangasek> Riddell: what is still outstanding on bug #99372, foomatic-db-gutenprint and ijsgutenprint now seem to be on the Kubuntu CDs without going over on size (#149899), does cupsys-driver-gutenprint need to be removed as well?
<ubotu> Launchpad bug 99372 in kubuntu-meta "MASTER: [Feisty]  KDE Printing Manager does not list the PPDs of Gutenprint" [Critical,Confirmed]  https://launchpad.net/bugs/99372
<slangasek> tepsipakki: ok, cheers
<Riddell> slangasek: that can be closed now
<slangasek> Riddell: care to do the honors? :)
<Riddell> closed
<Riddell> doko: accepted
<dholbach> seb128: can you unsubscribe ubuntu-archive from bug 151078? it was a mistake on my end
<ubotu> Launchpad bug 151078 in rails "Please sync rails 1.2.4-1 from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/151078
<mvo> pitti: what is the policy for moving milestones? I would like to unmilestone bug #140913 as there is no way to get this fixed for gutsy anymore
<ubotu> Launchpad bug 140913 in compiz "session save/restore does not work" [High,Triaged]  https://launchpad.net/bugs/140913
<mvo> pitti: is it fine if I just do that or does it need discussion/approval with the release team?
<pitti> mvo: IRC ping works for me (slangasek ^)
<pitti> mvo: go ahead and unmilestone it
<seb128> dholbach: done
<dholbach> seb128: thanks
<mantiena-baltix> hi all
<mantiena-baltix> mjg59, hi
<pitti> Riddell: do you want to keep kdelirc and klaptopdaemon in main (it needs seeding to supported then), or universe (then I'll demote them)?
<pitti> ogra: so, can we go over http://cdimage.ubuntu.com/edubuntu/dvd/current/gutsy-dvd-i386.list and check for stuff to throw out?
<pitti> ogra: what about linux-image-debug?
<Lure> pitti: I am sure klaptopdaemon should be "retired" to universe, not sure about the other one
<Riddell> pitti: they should both be demoted
<pitti> Riddell: done, thanks
<ogra> pitti, why is that back ? i thought all linux -debug packages were gone last time already
<pitti> ogra: that should buy us some 80 MB
<ogra> thats enough
<ogra> hmm, i really thought we had dropped all of them already for beta
<pitti>  * /^linux-image-debug-.*(?<!lowlatency)$/
<pitti> ok, I'll throw out this
<ogra> yeah, then the size should fit
<pitti> and try another dvd build
<pitti> ogra: running
<ogra> thanks :)
<Riddell> heno: seen any reports of bug 150930? I just got it on two machines?
<ubotu> Launchpad bug 150930 in usplash "Black screen, and bad usplash.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/150930
<heno> Riddell: I didn't get it here in vbox; I'll ask testers to look out for it
* soren goes to lunch
<heno> Riddell: could you test with an Ubuntu live CD to see if it's kubuntu-specific?
<Riddell> heno: ok
<chand> hi
<seb128> does something on the desktop CD creates the Desktop directory?
<heno> Riddell: never mind ; stgraber confirms it on Ubuntu
<Riddell> (phew)
<Riddell> what creates that usplash.conf file?
<cjwatson> it's a ubiquity bug
<mvo> pitti: if you could have a look at the new compiz upload, that would be cool
<cjwatson> it needs to copy xserver-xorg/config/display/modes to /target's debconf db before reconfiguring usplash
<cjwatson> yet another thing depending on debconf db contents, gah
<ogra> seb128,
<ogra> if [ -L /root/home/$USERNAME/Examples ] ; then
<ogra>     chroot /root install -o $USERNAME -g $USERNAME -d /home/$USERNAME/Desktop/
<ogra>     mv /root/home/$USERNAME/Examples /root/home/$USERNAME/Desktop/
<ogra> fi
<ogra> seb128, usr/share/initramfs-tools/scripts/casper-bottom/10adduser
<pitti> mvo: it's too late for the RC anyway, so I'll just let it sit in the queue, so that (1) slangasek can decide, and (2) if you need another fix, we don't have two rebuilds
<pitti> hi Keybuk
<seb128> ogra: ok, thanks
<cjwatson> I think we should fix it post-RC and release-note that people upgrading from before may need to dpkg-reconfigure usplash
<pitti> mvo: unless it's an OMGtheskyisfalling bug?
<mvo> pitti: no, its anyoing, but not critical
<pitti> mvo: simple and safe, or will it make Steve bite into the table?
<mvo> pitti: small at least.
<mvo> pitti: pretty safe too, but the compiz code is not so easy that its obvious
<cjwatson> oh god, don't tell me the Desktop directory name needs to be translated
<ogra> shudder
<cjwatson> whoever thought that translating directory names on-disk (as opposed to in the UI) was a good idea owes me a *lot* of drinks
<ion_> I translated it to ~/.local/share/desktop
<ion_> Less clutter in ~, yay
<ogra> bad if you want to access it via commandline
<cjwatson> a perfect example of why it should not be translated
<Riddell> heno: how do I target a bug at gutsy final?
<cjwatson> now suddenly translators are able to break code that doesn't use mkdir -p or equivalent
<cjwatson> or impose their own personal views of home directory layout on everyone speaking their language
<Riddell> heno: got it, nominate for release
<pitti> ogra: ah, daily CD health mail just came in; right, 61 MB for i386, 22 MB for amd64
<ogra> cjwatson, and additionally you have to remember if you have put the downloaded word doc with the picture collection inside into Dowloads, Documents or Pictures :)
* ogra is really no fan of the xdg-dirs
<cjwatson> I bet a language pack update can now make your existing desktop folder disappear by changing the translation
<cjwatson> we should revert this madness for gutsy
<Mirv> I think xdg-user-dirs and its translations are a great thing overall, and I also like "correct" (localized) folder names in Terminal in gutsy, though I wouldn't object if the translations were only shown in GUI/Nautilus etc.
<ogra> ++
<Mithrandir> cjwatson: agreed.
<cjwatson> Mirv: translating them in the UI is fine, but translating the directory names themselves is utter madness
<mvo> Keybuk: I would like to unmilestone #146759 because its a gnome-keyboard-capplet bug and not a compiz bug (duplicate of #12153). is that ok with you? if it is important we can milestone #12153 instead
<Keybuk> mvo: is the "It's not possible to disable some shortcuts, notably Move Window and Resize Window; attempting to do so, will just put them back" bit fixed?
<Keybuk> that was a ccsm issue
<mjg59> ogra: Probably, yes
<mjg59> mantiena-baltix: Were you able to test that package?
<mvo> Keybuk: I investigate and update the bug description
<cjwatson> oh dear goodness there seems to be a crazy scheme to move XDG user dirs around on login
<Mirv> cjwatson: I agree making xdg-user-dirs-(gtk-)update foolproof is probably quite hard. Then again it'd be funny that you have "Typyt", "Asiakirjat", "Kuvia" in Nautilus but "Desktop", "Documents" and "Pictures" in terminal. And regarding gutsy, everything seems to work fine, all software that needs the translated Documents or Desktop dirs seem to find it, so apparently the GTK 2.12 xdg changes were gotten into use properly.
<pitti> ogra: \o/ new DVD images are there, and not oversized
<cjwatson> that's a nightmare
<ogra> yay!!!
<cjwatson> Mirv: no, all software doesn't
<cjwatson> Mirv: I maintain stuff that has apparently been broken by this
<cjwatson> or at least may have been, can't quite be sure yet
<Mirv> cjwatson: yes that was an exaggeration, having just used OOo et cetera. It's no wonder if some stuff is broken still, though it should work when software has been updated to use the new functions instead of hardcoding.
<cjwatson> Mirv: at RC time, the appropriate reaction to an unknown quantity of software being broken by a change is to revert the change
<Keybuk> cjwatson: only if you're sure that the change won't break even more software
<Keybuk> I thought all GNOME apps were relying on xdg-user-dirs now?
<Keybuk> and have been throughout gutsy
<cjwatson> Keybuk: there's a switch that turns off the translation ...
<Keybuk> what about people who have already got translated directories?
<pitti> will that DTRT for upgrades which already have translations?
<pitti> (I think it shuold, since you can manually remove them, but we need to check)
<cjwatson> god knows, what about when the translations change?
<ogra> Keybuk, seb once told me i can just uninstall the xdg-dir stuff to revert to the old beghavior (i didnt try but i'D excpect that to work)
<cjwatson> it ought to be the same case
<Keybuk> cjwatson: what doesn't work when translations change?
<cjwatson> turning off the translations should be equivalent to retranslating everything to "Desktop" et al
<cjwatson> and then older Ubuntu code that relies on the name "Desktop" will keep on working
<Keybuk> what code do we have that relies on the "Desktop" name?
<Mirv> and the translations should not change, once they've been decided. the same translations are used in every distribution.
<cjwatson> casper, for one
<Keybuk> cjwatson: casper doesn't typically run inside a user's login session?
<cjwatson> Mirv: surely they go into Rosetta and are subject to language packs, like everything else
<heno> people who already have this and may get issues on a revert have been running Alpha/Beta software and should expect some turbulence
<ogra> Keybuk, on all that are started by liveCD users ?
<cjwatson> they're just .mo files in /usr/share/locale
<Keybuk> ogra: it doesn't matter if things happen before login
<Mirv> cjwatson: xdg-user-dirs was now changed so that the translations are part of the source package, not stripped for Rosetta (in order to have all translations available even without language packs)
<ogra> Keybuk,
<Mirv> part of the binary package, that is
<ogra> <ogra> if [ -L /root/home/$USERNAME/Examples ] ; then
<ogra> <ogra>     chroot /root install -o $USERNAME -g $USERNAME -d /home/$USERNAME/Desktop/
<ogra> <ogra>     mv /root/home/$USERNAME/Examples /root/home/$USERNAME/Desktop/
<ogra> <ogra> fi
<cjwatson> Keybuk: so if casper creates /home/oem/Desktop, xdg-user-dirs-update will move it on login?
<cjwatson> Mirv: nevertheless, there are language packs that contain overriding versions of xdg-user-dirs.mo
<cjwatson> (I checked)
<Keybuk> cjwatson: it seems that if ~/Desktop exists on login, that becomes the default
<Keybuk> rather than using a translated name
<cjwatson> $ zgrep xdg-user-dirs.mo /mirror/ubuntu/dists/gutsy/Contents-i386.gz | grep locale-langpack | wc -l
<cjwatson> 37
<cjwatson> Keybuk: does this whole thing not seem horribly flaky and an invitation to bugs to you?
<cjwatson> I mean the entire design of having to move subdirectories of $HOME around on login
<Keybuk> cjwatson: I can't see anything that suggests it moves directories?
<Keybuk> it seems to just ensure that when you first login, you have the right name for your locale
<cjwatson> hm, you're right, it doesn't
<cjwatson> surely that's even worse
<Keybuk> otherwise only handles new "standard" directories
<cjwatson> the translations can never be changed, even if they turn out to be wrong
<cjwatson> what if you change your language?
<Mithrandir> what does it do when I first log in using Norwegian, then switch to English because the Norwegian translation is less than perfect?
<Keybuk> it appears that the authors haven't got that far yet
<Mithrandir> (which is a perfectly sensible use case)
<Keybuk> it does not appear that the sky is falling here though
<ogra> well, its something we'll inherit into the next releases
<Mithrandir> it'll easily wedge us into a position that's bloody hard to get out of.
<cjwatson> I'm concerned that because it has no backward compatibility provisions for the sort of use case Mithrandir outlines, we need to turn it off now or we're stuck
<Keybuk> (if we wanted to be useful, we should take comments and concerns upstream and help them make it better)
<ogra> given the impact it has on the future that should better work perfect before we default to it
<cjwatson> upstream are not going to produce fundamental improvements in eight days
<cjwatson> our primary concern is the quality of the Ubuntu release we're preparing now
<Keybuk> what impact on the future?
<Keybuk> what is the bug that's been discovered here?
<Mirv> cjwatson: hmm, I just checked that too, that's true though they haven't really been changed except for three languages. though there is a local copy of the translations in .config/user-dirs.dirs, so xdg-dirs-update should be able to even notice changes in the currently used language's translations (and maybe does).
<ogra> Keybuk, transaltions being done on disk
<ogra> in the path structure instead of the UI
<Mirv> Mithrandir: the xdg-user-dirs-gtk-update asks the user if she wants to switch the folder names back to English or not
<ogra> witrhout covering all possible cases
<Keybuk> ogra: so we're going to go with a different solution to upstream, and patch every single application to keep the on-disk names the same and just translate in the UI
<Keybuk> (which upstream will not do)
<Mithrandir> Keybuk: use case: "Tollef logs in using Norwegian, because he is Norwegian and likes his computer to talk to him in Norwegian Bokml.  However, the Norwegian translation is buggy, so Tollef is sad and switches to the Norwegian Nynorsk translation, which is better.  His downloaded images which was on his Desktop are now gone.  Tollef is sad."
<Mirv> if not, .config/user-dirs.dirs keeps the translated version, if yes they're changed back to the English ones and folder names are updated. of course, I don't know how foolproof that is but it seemed to work quite fluently and without breaking anything when I switched between English, Spanish and Finnish
<ogra> Keybuk, if you never had the xdg-dirs package installed your ~ will look sane ...
<Keybuk> Mithrandir: but it doesn't appear to go
<Keybuk> did you actually test this?
<Keybuk> it looks to me like everything will stay the same
* pitti tries the live CD on his flatmate's laptop and is astonished how slow Vista Ultimate is
<Mithrandir> how will it?  Does it check for all translations of all directories?
<cjwatson> so you end up with the old translation that you explicitly asked not to have any nmore?
<Keybuk> Mithrandir: it has a config file saying what the directories are called
<Keybuk> if an entry is in that config file, it uses it
<ogra> pitti, not with quad core CPU in your laptop and 6G RAM :P
<pitti> ogra: on such a machine, every OS is fast :)
<ogra> heh
<pitti> ogra: it's already a core duo, pretty recent
<Mithrandir> Keybuk: so it doesn't respect me changing my language, then?
<Mirv> Mithrandir: It does not remove any files, it just renames folders when necessary and keeps track on what folder names are in use and suggests folder names from the translations.
<seb128> catching up with the discussion
<Keybuk> Mirv: where's the rename bit?
<Keybuk> there's no rename in xdg-user-dirs-update
<seb128> is the issue about "Desktop" or a general discussion about translated directories?
<pitti> I saw fast XP bootup/operation on 800 MHz/512 MB RAM machines
<ogra> pitti, vista is for the fjutscha :P
<Keybuk> Mithrandir: so you don't like the implementation - the right way to fix that is to help upstream improve it
<seb128> /etc/xdg/autostart/user-dirs-update-gtk.desktop does open the dialog asking if you want to rename directories when changing locales
<ogra> Keybuk, a week before we release ?
<cjwatson> Keybuk: correct me if I'm wrong, but we're in #ubuntu-devel talking about the Ubuntu relese
<Mithrandir> Keybuk: I think the idea is fundamentally unsound.
<Keybuk> ogra: this has been in our distribution for the entire development process!
<Keybuk> known bugs are better than unknown bugs
<ogra> Keybuk, i know, i complained early
<seb128> ogra: now is late for feedback
<Keybuk> if we're reverting things we find distasteful, I have quite a length list here :)
<ogra> seb128, when i complained you told me i can just remove the package and am fine, that suffices for me personally
<Keybuk> cjwatson: yes, and this isn't a new thing - this is something we've had for 6 months; if it were a new update that broke, it would be appropriate to worry about it - but this is something we've had during our alphas, betas and now release candidate images
<seb128> ogra: you didn't make constructive comments just ranted because you didn't like it
<Keybuk> now is not the time to revert it because it happens to leave a sour taste in your mouth
<Keybuk> without actually demonstrating any actual bugs from what I can tell
<Keybuk> (since there would be Malone bug numbers going around here :p)
<seb128> ogra: we can't stop every time somebody doesn't like a change or we would never do anything
<ogra> seb128, i didnt want to stop you (especially since upstream wants to push it) bein able to revert if needed was a sufficient answer in my case ... you might have noticed that i didnt rant after that ;)
<seb128> Keybuk: what is the issue exactly pointed there?
<seb128> ogra: right, so don't rant now ;)
<Mirv> I have used xdg-user-dirs for the whole time of gutsy, and haven't had problems after the translations were also included in the binary package. I haven't noticed bugs, and there are three bugs in a
<Mirv> Malone
<Keybuk> seb128: for me, the issue is that people are arguing to disable a piece of desktop infrastructure without actually quoting any bugs
<Keybuk> which worries me
<Keybuk> I've just checked everything in Malone I could think of, and cannot find any complaints about this being handled badly
<cjwatson> Keybuk: what is the appropriate way to engage with upstream when you say that they have already dismissed the solution that I would advocate? I don't see a constructive way to do that
<Keybuk> cjwatson: demonstrate problems with their chosen solution
<seb128> cjwatson: what is your way? translate in the UI rather than on the disk?
<cjwatson> seb128: yesw
<cjwatson> -w
<cjwatson> similarly, we don't translate "/etc"
<seb128> cjwatson: they discussed that on the GNOME and xdg list for quite some time and agreed on the current solution, I don't think that will change now
<seb128> well, those directories are mainly new
<cjwatson> so there is no point in engaging
<seb128> only Desktop is a special case and there is code to not translate it if required
<ogra> what if translations change ?
<ogra> will we have users with "Schreibtisch" and others with "Arbeitsplatz" ? (given a german user)
<seb128> ogra: you get the xdg-user-dirs-gtk-update dialog asking if you want to rename it or not
<Keybuk> cjwatson: we can't like every decision our upstreams make
<ogra> ah
<seb128> cjwatson: http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00424.html is the first discussion on the topic
<cjwatson> Keybuk: forgive me for attempting to anticipate future problems with a poor design. I'll try not to do that in future.
<Mirv> ogra: I haven't tried, but in theory xdg-user-dirs should notice the translation having changed, and probably it does nothing until the language is changed to another and then back. Since the translations aren't used directly, but saved into a .config/ file
<Keybuk> cjwatson: are you willing to commit your team to developing a replacement, patching every application and maintaining those patches in the face of upstream doing it a different way
<seb128> cjwatson: there is pro and con for each methods with some long discussion
<Keybuk> cjwatson: but you're not, you're ranting
<ogra> seb128, but if they say no they'll  keep "schreibtisch", right ?
<cjwatson> Keybuk: I'm speaking as a developer, not a manager
<Keybuk> cjwatson: you're throwing out the entire design, rather than looking at it from the "ok, they're doing it this way, how can we fix the resulting problems?" position
<seb128> ogra: yes, you can write whatever you want as names
<seb128> ogra: .config/user-dirs.dirs has the list
<ogra> seb128, well, but i as developper lose the predictability for the names
<seb128> ogra: you can make any change there you want
<seb128> ogra: the API will get the names listed there on your configuration
<ogra> so i can look them up there ?
<cjwatson> Keybuk: you appear to think we should never point out design errors
<Keybuk> cjwatson: not at all, I think we should
<seb128> ogra: there is no "predictability", you use the glib API
<cjwatson> I'll back off from "we should revert this for gutsy" because there appears to be enough glue and sticky tape to avoid major problems
<ogra> seb128, well, given the casper code it would be very bad if it wouldnt be called Desktop
<Keybuk> cjwatson: I strongly advocate using our experience to help upstream improve it
<seb128> ogra: const gchar*        g_get_user_special_dir              (GUserDirectory directory);
<Mirv> to put it short, I don't want my grandma to see "Documents" folder, and I don't like the idea that what _I_ see in Nautilus is not what's on the disk, either.
<ogra> i dont use glib in scripts
<Keybuk> and I think we should be a little bit flexible, and try to help them improve their design -- but also a degree of smug "see, told you you should do it our way" in the background helps too :)
<seb128> ogra: there is an easy function to copy in xdg-users-dir which has no GTK, GLIB, GNOME, etc depends for applications which don't use glib
<cjwatson> Keybuk: but let's say it *had* broken casper because the sticky tape was arranged slightly differently; I find the position of "we shouldn't fix this in Ubuntu because upstream agreed to do something different" to be objectionable
<Keybuk> the only thing I disagree on is using "we don't like the way it works" as a justification for disabling it *one week* before the release, without any actual apparent bugs :-)
<Keybuk> cjwatson: I would agree
<seb128> ogra: xdg-user-dir-lookup.c
<ogra> seb128, yeah, as long as i can find out the name thats fine
<Keybuk> I don't disagree that we shouldn't fix it in Ubuntu
<cjwatson> Keybuk: bug 122602 appears to be caused by casper's creation of the Desktop directory
<ubotu> Launchpad bug 122602 in gnome-panel "Duplicated entries in Places Menu" [Medium,Fix released]  https://launchpad.net/bugs/122602
<Keybuk> (err, tries to parse his own sentence)
<cjwatson> (it's Triaged in xdg-user-dirs-gtk)
<Keybuk> I just think we shouldn't rip things out at *this point* unless they're actually causing critical bugs or regressions
<Keybuk> the appropriate time would've been before Feature Freeze, or at least before Beta
<seb128> cjwatson: right, I've reopened that less than an hour ago while doing testing because I noticed that
<cjwatson> I certainly regret not noticing it earlier
<cjwatson> seb128: yep, your comment on IRC is what sparked this discussion ;)
<seb128> cjwatson: I though that was due to download = desktop
<seb128> and it was bookmarking download
<ogra> cjwatson, well, you apparently can use XDG_DESKTOP_DIR if you source the users .config/user-dirs.dirs (if that exists already)
<seb128> which was actually an issue (which has been fixed)
<cjwatson> seb128: I think it's likely to be that casper creates ~/Desktop so that it can put the ubiquity icon there
<cjwatson> ogra: it won't exist at that point
<Mithrandir> and create the symlink, yes
<seb128> right, what I figured this morning
<ogra> yeah
<Mithrandir> (the example-content symlink)
<cjwatson> yes, that too
* pitti gets a hanging ubiquity with "DebconfError: (10, "migration-assistant/new-user/martin/ doesn't exist")"
<pitti> evand, heno: ^ known already?
<cjwatson> Keybuk: I apologise for being immoderate; since I was working from the starting point of seb128's comment, I was going from my reading of the source code
<pitti> it's in autoresize mode, so there is anohter installation; however, m-a did not show me any suitable OSes to import from
<cjwatson> pitti: I see the bug
<Keybuk> cjwatson: I'm the last person you need to apologise too ;)  I'm frequently immoderate, myself <g>
<cjwatson> pitti: please file it though
<seb128> cjwatson: an easy way to workaround it is to comment the DESKTOP xdg dir, in which case it'll fallback automatically at using ~/Desktop
<cjwatson> seb128: do you think we should do that in casper?
<cjwatson> seb128: and, for that matter, oem-config
<cjwatson> and ubiquity
<pitti> cjwatson: will do
<seb128> cjwatson: hum, thinking about it
<cjwatson> seb128: changing it in oem-config (and ubiquity in OEM mode) would persist to installed systems
<cjwatson> so this doesn't seem straightforward
<seb128> cjwatson: I think that should be fixed in xdg-user-dirs rather
<seb128> in the case where Desktop already exist it should use that
<seb128> so that would work on the CD using ~/Desktop
<seb128> and the installation system will get the translated directory since nothing create a ~/Desktop there
<cjwatson> that sounds right
<Keybuk> seb128: there's code in there for "backwards_compat_dirs"
<seb128> I'm working on that
<seb128> Keybuk: yeah, I though it was not supposed to create a translated version if "Desktop" exists in fact
<pitti> cjwatson: bug 151243
<ubotu> Launchpad bug 151243 in ubiquity "DebconfError: (10, "migration-assistant/new-user/martin/ doesn't exist")" [High,New]  https://launchpad.net/bugs/151243
<seb128> Keybuk: there is likely a bug somewhere, I'm looking into it
<cjwatson> pitti: introduced by the fix for bug 135149
<ubotu> Launchpad bug 135149 in ubiquity "[gutsy]  failed to unmount migrationassistant" [Medium,Fix released]  https://launchpad.net/bugs/135149
<seb128> Keybuk: hum, the issues are introduced by the fact that we use Download=Desktop
<seb128> Keybuk: the DESKTOP config is correctly set to Desktop on the CD
<seb128> but Download is set to Bureau (french version of Desktop) there
<Keybuk> seb128: yeah, I just touch touch ~/Desktop/foo and it appeared in nautilus
<seb128> Keybuk: my xdg-user-dirs-gtk patch is not correct
<seb128> 01_no_desktop_bookmark.patch
<seb128> it works only when Desktop is translated
<heno> pitti: I've not seen that; will test for it now
<elmo> seb128: are there any known regressions in evince?
<Keybuk> elmo: I've had a couple of broken PDFs fail to load that older evince loaded ok
<Keybuk> (because older evince ignored the forms bit in thim)
<pitti> heno: nevermind, see cjwatson's comment above; I filed it as a bug
<elmo> Keybuk: these aren't broken AFAICT, and work fine with feisty
<heno> ok
<cjwatson> pitti: I think this needs evand
<seb128> elmo: not really, there is a new bug about printing quality but that's not really confirmed yet
<elmo> seb128: ok, thanks, I'll file a bug about it now, I get cairo memory errors when running it from the command line.  would evince or poppler be a better package to bug?
<seb128> elmo: is the document rendered empty but display it contents if you highlight it?
<bluekuja> mjg59: do you have a minute for uswsusp problem?
<seb128> elmo: s/highlight/select
<elmo> seb128: aha, yes!
<seb128> elmo: that's a known one
<heno> pitti: is your bug the same as bug 151165 ?
<ubotu> Launchpad bug 151165 in ubiquity "ubiquity hangs indefinitely at Step 6" [Undecided,New]  https://launchpad.net/bugs/151165
<elmo> seb128: ok, do you have a bug number?  'cos it's a regression from feisty, I'm getting a lot of whining about it in the office
<Keybuk> elmo: turn the aircon down a notch, that keeps them quiet ;)
<seb128> elmo: some people already had the issue on feisty
<seb128> elmo: bug #116236
<ubotu> Launchpad bug 116236 in libcairo "evince shows a mostly blank pdf" [Medium,Confirmed]  https://launchpad.net/bugs/116236
<cjwatson> heno: yes, same bug, please dup it
<heno> ok
<pitti> heno: right, that's it
<pitti> I searched for that string before, hmm
<pitti> doesn't LP search in bug descriptions any more?
<heno> I can reproduce it in vbox as well now
<elmo> seb128: interesting, this PDF definitely works on feisty.  ok, well then I guess I can't really play the regression card ;-)
<mantiena-baltix> mjg59, hi again, I tested your patched gdm and didn't noticed any problems with xorg.conf from http://ftp.akl.lt/incoming/Baltix-stuff/
<seb128> elmo: if you have a public example please attach it to the bug so we can test on different cases if there is a fix
<pitti> heno: I dup it the other way round, since cjwatson already milestoned and commented it
<mantiena-baltix> mjg59, Thank you for making Ubuntu better
<heno> pitti: ok, good
<mantiena-baltix> I also builded patched gdm packages - see http://ppa.launchpad.net/mantas/ubuntu/pool/main/g/gdm/ (they can run even on feisty :))
<elmo> seb128: done
<seb128> elmo: thanks
<mjg59> mantiena-baltix: So it worked?
<pitti> mvo: is "ensure that cd release-upgrader is set to ""useDevelopmentRelease=False" done now?
<mvo> pitti: yes
<pitti> thanks
<popey> mjg59: another bug filing question if you have a few minutes?
<popey> (or anyone else)
<mjg59> popey: Sure
<popey> c2d 6700 system. /sys/devices/system/cpu/cpu0/cpufreq doesn't exist
<popey> 3.6.20 - feisty
<popey> er, 2.6.20 of course
<popey> so cpu runs flat out all the time
<popey> wondered if I should file a bug or wait for gutsy / 2.6.22
<mjg59> Well, unlikely that it'll be fixed in feisty
<mjg59> But make sure you have powernowd installed
<popey> yeah, i do
<popey> http://pastebin.ubuntu-uk.org/467
<Kopfgeldjaeger> hi
<stgraber> pitti: argh, I'm looking for 10 minutes after a tracker bug which in fact isn't !!! (I wondered why the dups were switched for the m-a bug)
<soren> Aw, crap I closed the tab with the milestoned bugs on it.. What's the magic to get it back? Ubuntu's bug page->search for milestoned bugs  doesn't give me an option to order by assignee.
<persia> soren: "Recently Closed tabs" in History?
<soren> persia: a) I use epiphany and b) I might not have closed it recently. I only just noticed its absence just now.
<soren> Oh, he buggered off.
<cjwatson> soren: https://edge.launchpad.net/ubuntu/+milestone/ubuntu-7.10-rc
<cjwatson> -edge.
<soren> No, edge is good :)
<soren> cjwatson: Excellent. Thanks.
<_MMA_> cjwatson: Do you have time to manually trigger a Ubuntu Studio build so I can test if those updates from yesterday took?
<cjwatson> _MMA_: I've triggered it, but we've stopped mirroring of CD images temporarily during release candidate prep, so you won't actually be able to get at it for a while, I'm afraid
<_MMA_> Ahh.... Ok. :(
<_MMA_> Thanx anyway.
<soren> What handles the automagic printer setup?
<soren> I would have thought it was gnome-volume-manager, but it doesn't seem to be so in my fresh gutsy install.
<soren> Ah, never min.d
<evand> pitti: have you discovered a grave bug?  I'm slightly confused.
<evand> oh wow, I see it now
<evand> this just isn't my week/release
<evand> fixing now
<cjwatson> evand: see my comments on the bug
<evand> indeed
<mantiena-baltix> mjg59, so, when are you planing to include virtual-screen patch into official Ubuntu packages?
<pitti> hi evand
<evand> hi pitti
<Keybuk> I can't decide whether TAL is evil or nice
<Hobbsee> it's evil, pretending to be nice.
<Keybuk> it does save me having to embed vast amounts of Python into this program
<Keybuk> err
<Keybuk> I mean vasts about of HTML into this Python program
<Keybuk> nothing can save me from having to embed vasts amount of Python
<Keybuk> I was doomed to that special hell long ago
<soren> While checking up on bug 137581, I've found out that cups by default sets new printers to shared unless told otherwise at ./configure time. Should we change the default in cups or should I work around it in hal-cups-utils. Both are simple fixes (in terms of lines of code changed), but I'm not confident that everything will work properly afterwards. What to do?
<soren> ubotu ftl..
<ubotu> Sorry, I don't know anything about ftl.. - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<soren> bug 137581
<Mithrandir> heh
<ubotu> Launchpad bug 137581 in cupsys "[Gusty]  Printer shared by default (Security)" [Medium,Confirmed]  https://launchpad.net/bugs/137581
<pitti> soren: eww, thanks for finding that; weird, the default switch is 'sharing disabled' in the global configuration
<pitti> soren: let me check
<soren> pitti: My cupsd.conf doesn't even mention sharing?
<pitti> seb128: there are two gdms in the unapproved queue; which is the 'good' one? (one from 6:30 hours ago, one from 1:10 hours)
<pitti> soren: I believe this might be a red herring, but let me check
<soren> pitti: But you're right. There's a third option: Add <DefaultPrinter> Shared No </DefaultPrinter> to cupsd.conf (or something to that effect)
<pitti> soren: usually it only listens on localhost by default
<pitti> soren: and only if you enable sharing in the server options, individual printers can be shared in the first place
<pitti> tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     11087/cupsd
<pitti> ^ my default
* pitti configures a printer
<pitti> OMG, who did the German translation for hal-cups-utils... "Drucker addiert" -- hilarious
<pitti> "ML-1610 ist druckbereites."
* pitti weeps
* MacSlow rolls on the floor
<lamont> it's moments like these where I regret stopping my german studies
<MacSlow> "Drucker addiert" is gold!
<gilligan_> should be "Drucker hinzugefgt"
<soren> Ok, so since this is not a problem unless people explicitly open cups to external connections, it should be safe to leave it as is for this release.
<soren> "addiert" is not really a proper German word is it? That's the joke, right?
<gilligan_> it is a proper word
<gilligan_> just not for this context AT ALL
<gilligan_> addieren is more or less only for "adding" in a mathematical sense
<MacSlow> soren, in german the verb 'addieren' means add in the mathematical sense not like 'added something to something else' (e.g. a printer to a computer)
<soren> Right.
<soren>  Same in Danish.
<pitti> soren: see the bug, I added a comment
<pitti> soren: also, "druckbereites" is not a word at all
<soren> pitti: Wicked. Thanks for the help.
<pitti> soren: it's like the genitive of an adverb (if such a thing would exist)
<MacSlow> but then... 'Drucker addiert' is probably not totally wrong... printers these days are likely able to perform some kind of calulcations :)
<pitti> but the printer doesn't add, it got configured
<pitti> :)
<soren> pitti: Translations can be... Um.. fun.
<pitti> soren: I just wonder why Rosetta's restrictions might be too lax
<pitti> carlos: meh, https://translations.edge.launchpad.net/ubuntu/gutsy/+source/system-config-printer/+pots/system-config-printer/de/+translate times out for me
<soren> pitti: It's a bit of a bummer that I'm sitting here with my brand new and shiny core-dev hat, and I can't even be allowed to change a typo in a translation.
<pitti> soren: well, translation teams should be independent from upload privs IMHO
<soren> Sure. I understand why it's like that. It's just yet another thing I need to get sponsored or reviewed or whatever.
<pitti> hm, the upstream translations are correct
<pitti> carlos: do you know why https://translations.edge.launchpad.net/ubuntu/gutsy/+source/system-config-printer shows no Rosetta specific translations for system-config-printer, the upstream translations are correct, but the ones in the langpacks aren't?
<pitti> carlos: ah, it might be because the langpacks are so horribly outdated
<bddebian> Heya
<pitti> lool, mjg59: so, you two uploaded two conflicting versions of gdm (2.20.0-0ubuntu4)
<pitti> to unapproved
<pitti> mjg59: I'll reject your's, since lool came first, and your patch looks very intrusive for this point of the release
<bddebian> doko: You really consider that platform.dist() returns Debian lenny/sid to be a wishlist bug?
<doko> bddebian: it's a duplicate anyway
<bddebian> doko: OK, well that I didn't know and I didn't know it was a dupe.  I was just surprised that python parses /etc/<dist>_version
<lool> pitti: Sorry about that, I prepared my upload yesterday; is there a way to prevent such collisions in the future or was that just FMI?
<dholbach> pitti: are you aware of bug 125308? ok, if I subscribe you to it?
<ubotu> Launchpad bug 125308 in esound "[gutsy]  esd makes diverse gnome apps freeze" [Medium,Confirmed]  https://launchpad.net/bugs/125308
<pitti> lool: during freezes, people should ask the RMs before upload, or at least look into the unapproved queue first; if there is an upload already, then again coordinate with RM
<pitti> mjg59: ^
<pitti> dholbach: we don't install esd by default any more, for exactly those reasons
<pitti> dholbach: and the last uploader of esound made a mess of the package (killed all our precious patches, etc.)
<dholbach> hrm, who is interested in it still being in main?
<pitti> dholbach: once we install pulse by default (or at least the esd compat client libs), I'll be happy to see it six feet under
<pitti> but that's hardy material
<dholbach> the patch is hardy material too?
<pitti> dholbach: definitively on my list, though
<dholbach> (patch on the bug)
<pitti> dholbach: oh, patch?
<bddebian> Oh lool!  I didn't use console-colors package as the source but I did borrow a lot of their changes for colorgcc.  I got a new version uploaded yesterday if you are interested in testing it out for me.
<bddebian> To Debian that is
<lool> bddebian: I guess I'll naturally test it when I apt-get update :)
<bddebian> Heh, fair enough, thx
<carlos> pitti: hi, I'm back
<pitti> dholbach: ah, that looks good
<pitti> hi carlos
<dholbach> pitti: thank YOU
<lool> To be honest, I didn't spend huge time playing with colorgcc, I wanted it to "just work" and do the right thing, when I was at that point I stopped looking into it
<bddebian> OK
<lool> bddebian: I'm not sure I filed a bug about it, but I have a local hack here to generate symlinks like ccache does
<lool> In order to only have to add $colorgcc-symlinks-dir to the PATH to use it as cc
<bddebian> lool: Yes it's on BTS thanks.  I'm just not sure I know what to do with it.  I'm kinda stupid. :-)
<carlos> pitti: what's the problem with system-config-printer?
<carlos> pitti: translations were working for me, it had some bugs though, so no all translations were used
<pitti> carlos: I wondered where the odd translations came form
<pitti> carlos: and I can't check, because the page times out
<lool> bddebian: Perhaps check how ccache did it and look for a similar solution?
<bddebian> I looked briefly at ccache
<nicolai__> pitti: what will you do with the "cryptsetup> could not setup lvm" error message? keep it as it is?
<pitti> nicolai__: that's my plan anyway; it's too late to fix it properly
<carlos> pitti: but what's the problem you are having?
<nicolai__> pitti: and dirty? ;)
<pitti> carlos: there are some very wrong German translations of s-c-p (see above), which I'd like to check and correct
<pitti> carlos: upstream's original ones  are correct
<carlos> pitti: the timeout problem is known problem, we are improving the performance, but still need to speed some things
<pitti> carlos: so I'd like to check where they come from; but with the page timing out, I can't
<carlos> pitti: oh, I see, so maybe someone 'forked' translations in Launchpad..
<mjg59> pitti: I suspect we either need to include mine or heavily refactor guidance-backends
<pitti> carlos: but there's just a green and a red bar, no blue one
<pitti> mjg59: can you merge your patch into lool's package?
<mjg59> pitti: Sure
<carlos> pitti: https://translations.edge.launchpad.net/ubuntu/gutsy/+source/system-config-printer/+imports
<carlos> pitti: there are some pending files to be imported
<pitti> mjg59: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/gdm_2.20.0-0ubuntu4.dsc
<mjg59> Thanks
<carlos> pitti: so maybe that's the problem, those should be imported soon (I think any time between today or tomorrow)
<pitti> mjg59: it just didn't look like the OMGTSIF type of patch we'd need at this point of the release
<pitti> carlos: too late for the currently running export, right? well, not that important
<mjg59> pitti: It basically screws anyone who runs the X configuration tool on a CRT
<pitti> uh, that does sound serious
<mjg59> Unless they want to run at the very maximum resolution that the CRT supports
<carlos> pitti: yeah, it will need to wait for the language pack update
<mjg59> (which they probably don't)
<pitti> mjg59: so, please reuse ubuntu4, and I'll reject lool's upload, too, then
<pitti> well, ubuntu5 is fine, too, as you wish
<mjg59> pitti: Oh, just merge mine into lool's? No problem.
<davmor2> bryce: ping
<mjg59> pitti: I've uploaded a new ubuntu4 with both sets of changes
<pitti> mjg59: thanks, I'll reject the older one then
<seb128> pitti: who did upload gdm one hour ago?
<seb128> ah, you sorted that apparently
<JayTheMentalMidg> Would anyone know why that nvram commit wouldn't save settings that will make it through a reboot?
<pitti> evand: how are things looking? we need to get new desktop CDs out soon if we want to rebuild them at all
<evand> pitti: changes are in ubiquity trunk, but cjwatson is requesting we wait.
<cjwatson> pitti: I'm trying to get a bit further with this language pack thing
<cjwatson> I am making concrete progress
<pitti> which bug is that?
<cjwatson> pitti: bug 145012 and a very similar issue reported by seb128
<ubotu> Launchpad bug 145012 in ubiquity "installer hangs retrieving langpacks when network is down" [Medium,Confirmed]  https://launchpad.net/bugs/145012
<pitti> ah, that one
<ogra> seb128, did the icon names for desktop and home change accordingly with the start-here vs. distributor-logo ? (asking because of bug 151294)
<ubotu> Launchpad bug 151294 in edubuntu-artwork "Edubuntu icons are not uniform" [Undecided,New]  https://launchpad.net/bugs/151294
<seb128> ogra: no idea
<seb128> ogra: I'll have a look, a min
<ogra> i can look myself, is the code gnome-session or -panel ?
<seb128> ogra: gnome-panel
<ogra> ta
<bdmurray> mvo: Where does do-release-upgrade maintain state?  If you say "No" one time it seems to remember.
<seb128> iwj: I don't really understand bug #151325
<ubotu> Launchpad bug 151325 in gnome-terminal "scrollback gesture should be disabled" [Undecided,New]  https://launchpad.net/bugs/151325
<seb128> iwj: do you click or something?
<iwj> seb128: No.
<iwj> seb128: It's a trackpad so it might be that it treats my finger-down as tap.
<seb128> iwj: are you sure you didn't activate the scrollweel or something?
<iwj> seb128: I didn't do anything.  It's a very vanilla install.  The only thing I changed was to turn off compiz.
<iwj> I can't get it to do it if I place my finger gently, wait, and then move suddenly left.
<seb128> iwj: I don't get how a pointer move could create an action, there is no gesture configured under GNOME
<iwj> So it maybe that it things I'm doing click-and-drag.
<iwj> s/things/thinks/
<seb128> click and drag should display a selection
<iwj> You would think so, yes.
<seb128> iwj: what would explain that is scrolling with the middle button of a mouse
<seb128> which acts as page up
<Nafallo> BUHU!
<iwj> There is no middle button.  It's a two-button trackpad but I'm only using my finger on the actual trackpad.
<seb128> can you do that with your trackpad?
<Nafallo> I can't enable desktop effects :-/
* Nafallo blames kylem ;-)
<seb128> iwj: k, doesn't really seem important for gutsy and I don't manager to trigger that using a regular mouse so I'll pass on it for now
<iwj> seb128: Sure.  It's been doing it like this for ages.  I thought we had a bug about it already but when I looked I couldn't find it.
<Nafallo> ehrm...
<mvo> bdmurray: it does? that is cool. I think that this was a feature request, but I can't remember ever implementing it. if there is a [Yn]  it should use the cpatial one as default
<cjwatson> pitti: nearly there ...
<pitti> cjwatson: damn, I didn't disable the publisher, so you have at least another 30 minutes :/
* pitti puts it on manual now
* lamont finds himself wondering what the publisher publishess
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> slomo: ping?
<davmor2> bryce: new bug create (as per your request)  for the kubuntu intel error.  Plus Lore gave me a load of tips on things that might be useful bug 151311.  I got to go to the lug meeting in a bit and will be test other desktops after so is there any more info that you need before I go?
<ubotu> Launchpad bug 151311 in xserver-xorg-video-intel "DPI in kubuntu incorrect on xorg-video-driver-intel" [Undecided,New]  https://launchpad.net/bugs/151311
<bryce> davmor2: thanks, the one other piece of info that may be helpful is the output of lspci -vvnn
<davmor2> np
<bryce> oh, and since this sounds like it could be a resolution related issue, output from `xrandr` and `ddcprobe` should also be attached in case it's relevant
<davmor2> bryce: how do I get that?
<bryce> just run those commands
<bryce> you may need to install xresprobe to get ddcprobe
<davmor2> bryce: right updated for you.  also although res and stuff is right when you force the issue.  The login screen font is still an inch high.
<davmor2> bryce: that applies to the ubuntu fix aswell I think :(
<Oliver3> I upgraded to Gusty beta last night. Ever since doing so I've had a crackly sound coming from my speakers when playing audio. Also, the screen resolution become screwy, it's fine in GNOME after changing it, but it's still messed up at the login screen.
<Oliver3> I'm unable to see the edges of the screen, and I've already tried changing the settings on the monitor to their minimum.
<Oliver3> Oh
* Oliver3 reads topic >_<
<ogra> seb128, which g-p-m patch is that ?
<ogra> seb128, i'm working on http://cvs.fedoraproject.org/viewcvs/devel/gnome-power-manager/gnome-power-manager-2.20.0-expected-return-types.patch?rev=1.1&view=auto atm
<ogra> seb128, is that the same ? and if so, did you take the whole patch ? it closes a ton of other gpm (mostly brightness and notification) bugs as well
<blueyed> Bug 151319 is about a package where the (python) binaries are missing in the package. It builds fine in pbuilder, Debian, but not in a PPA and Ubuntu in general.
<ubotu> Launchpad bug 151319 in bitbake "The package not contain binaries thus it isn't useful at all" [Undecided,Confirmed]  https://launchpad.net/bugs/151319
<blueyed> Does the package need to be adjusted?
<geser> blueyed: does the PPA build log give a hint why the binaries don't get included?
<blueyed> geser: I'm not sure.. see http://launchpadlibrarian.net/9928858/buildlog_ubuntu-gutsy-i386.bitbake_1.8.2-1~ppa1_FULLYBUILT.txt.gz
<blueyed> Maybe I should compare this to the pbuilder log..
<seb128> ogra: no, I took http://svn.gnome.org/viewvc/gnome-power-manager/trunk/src/gpm-manager.c?r1=2523&r2=2522&pathrev=2523
<ogra> seb128, ok, then we dont clash :) thanks
<seb128> ogra: we do on revision number
<seb128> ogra: dget http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/gnome-power-manager_2.20.0-0ubuntu4.dsc
<ogra> i didnt upload anything yet, i was collecting info from bugged users to justify if its worth it i wasnt planning to upload before RC
<seb128> ogra: if you want to add a new revision
<seb128> ogra: ok
<ogra> but it seems fixing the uint/int mistmatch will solve really a lot of the remaining bugs
<ogra> i really woder how that could slip into the final upstream release
<seb128> ogra: the same reason why you didn't notice it before now, people being busy, too many bug reports, etc
<ogra> seb128, well, mjg59 noticed it ad fixed one piece ...
<ogra> i noticed there were more related errors, but youre right i was to busy to look into it ...
<mvo> slangasek: could you please reject my  translation_main and translations_restricted uploads ?
<mvo> slangasek: (type raw-ddtp-tarball)
<mvo> or Riddell maybe? reject my translation_main and translation_restricted upload?
<geser> blueyed: looking at the build-log it looks like a docbook-xml build-dependency should be added (for building the documentation)
<cjwatson> mvo: done
<mvo> thanks cjwatson
<slangasek> cjwatson: did those go through unapproved? 'q -Q unapproved info' didn't seem to show them for me
<slangasek> or I should've rerun the command instead of looking at the one in my scrollback from a few minutes ago...
* mvo updates his script that process the rosetta export and hope that its updated to the new rosetta export format 
<blueyed> geser: I'll test it and let you know.
<zul> hey LaserJock
<mvo> cjwatson, slangasek: I assume that ddtp translation updates are ok at this stage?
<LaserJock> hi zul
<geser> blueyed: but I guess that's only a minor error and shouldn't affect the missing binaries
<LaserJock> something messed up my  Gnome again :/
<zul> use kde
<LaserJock> but this time I only have to narrow it down from a few hundred updates ;-)
<LaserJock> zul: that's what I did last time
<LaserJock> at some point it's nice to actually be able to logout
<LaserJock> must be some secret Gnome plan
<slangasek> mvo: uh... /sounds/ ok to me, but I guess I don't know for sure
<mvo> slangasek: I uploaded the multiverse translations now (fixed ones) and if cjwatson is ok, we could let this thorugh. if all is fine iwth those I will upload the rest. deal :) ?
<slangasek> mvo: well, I presume that if cjwatson says it's ok, that means it's really ok
<slangasek> I can't think of anything that would break, I'm just being overly cautious
<mvo> slangasek: caution is fine at this stage
<pochu> slangasek: do you think we can get the fix in bug 151217 in? It fixes a crash when adding a local feed, and the fix looks pretty harmless to me.
<ubotu> Launchpad bug 151217 in liferea "[gutsy]  liferea-bin crashed with SIGSEGV while trying to a new feed" [Medium,Confirmed]  https://launchpad.net/bugs/151217
<slangasek> pochu: not before RC, but we can take a look at it for final (i.e., please go ahead and upload)
<BenC> is there a command line for mute/unmute?
<Kmos> I need an opinion about bug 151024 , i think it's kernel related..
<ubotu> Launchpad bug 151024 in ubuntu "can not install gutsy livecd beta with nvidia graphic card" [Undecided,New]  https://launchpad.net/bugs/151024
<BenC> Kmos: nope, xorg-video-nv problem most likely
<Kmos> BenC: amixer set Master mute
<BenC> Kmos: thanks :)
<Kmos> BenC: thx
<BenC> Kmos: invalid command
<pochu> slangasek: thanks. slomo, mind uploading it? :-) http://emilio.pozuelo.org/~deb/
<Kmos> BenC: it works here
<Kmos> BenC: do you have amixer?
<BenC> Kmos: ...
<BenC> $ amixer set Master mute
<BenC> amixer: Invalid command!
<BenC> amixer is there, just doesn't like my command
<Kmos> it works here and works
<Kmos> BenC: http://pastebin.com/d154369e
<BenC> Kmos: maybe "Master" isn't here
<BenC> Kmos: how do I get a list of mixer controls?
<BenC> hmm, nope, amixer shows a Master
<Kmos> yeah
<Kmos> if you type: amixer is shows it
<Kmos> amixer |grep Master
<BenC> yeah, I got that
<Kmos> BenC: amixer controls
<Kmos> BenC: amixer scontrols
<Kmos> scontrols it's better
<Kmos> you don't have two sound cards?
<BenC> no
<BenC> Front works for me
<BenC> it's a laptop
<Kmos> hmm
<Kmos> i'm on a desktop
<mjg59> The mixers are screwed up on most recent machines
<mjg59> (that's if sound works at all)
<mjg59> If you don't have the correct mapping tables, it'll end up with odd bits of functionality being on strange mixer channels
<Kmos> rt2500 is included in kernel on gutsy ?
<cjwatson> slangasek: they did go through unapproved, just only briefly because I happened to notice mvo's request quickly
<slangasek> right :)
<cjwatson> mvo,slangasek: DDTP updates are fine to the best of my knowledge
<slangasek> ok, will have a look right after lunch
<pochu> mjg59: new liferea 1.4.5 workarounds the data loss on forced termination. Not sure we should include it, as we may be too close to release for this change... http://liferea.svn.sourceforge.net/viewvc/liferea?view=rev&revision=3481
<mjg59> pochu: I'd go for it - the current situation is greatly irritating
<mjg59> But you'll probably want to get it past one of the release team
<pochu> mjg59: of course.
<mjg59> pochu: But feel free to let them know I'm enthusiastic :)
<pochu> slangasek: do you think it's reasonably if I test it and find no regressions? (it's for not trying it in case you won't accept it hehe).
<mdke> cjwatson: cool, thanks for looking into it
<mjg59> slangasek: Can you take a quick look at #68370 ? There's a synaptics upload queued that fixes it, but it'd be nice to know if you view it as a target for gutsy (I can reproduce the issue here without any trouble)
<mdke> Seveas: here?
<gnomefreak> mdke: he might be afk for a bit
<mdke> okie dokey
<pitti> mvo: I assume we want those translation tarballs?
<mvo> pitti: yes, just to avoid badness we may import one for now and see if all is fine then and then take the rest?
<pitti> mvo: you make that sound as if it wasn't the trivial and safe update it should be?
<mvo> pitti: its just data, so there can be no serious harm. I'm just very cautios now
<pitti> mvo: so should I accept universe and multiverse now, and you'll check the results after publisher?
<pitti> mvo: and if all is well, I do main/restricted?
<mvo> pitti: yes, that sounds good
<pitti> done
<mvo> thanks
<nicolai__> n8
<blueyed> geser: adding the docbook-xml build-depends for the bitbake package fixed it!
<blueyed> I don't understand why it works with pbuilder without it (and in Debian), but it fixes it for the ubuntu build system.
<LaserJock> blueyed: could there be a component problem?
<LaserJock> I had a perhaps a similar situation
<slangasek> pochu: hum, I still need to look at the fix before accepting it; you should also test it, but I don't know what answer I can give you here
<blueyed> LaserJock: Are you refering to main/universe et al? I've tried it in ppa before without changing anything, but using "main".
<LaserJock> hmm, but that was for a Main package
<LaserJock> yes
<LaserJock> my problem was that a dep had changed and so it was trying to pull in something that was in Universe for a package that's in Main
<LaserJock> so in my pbuilder (where I have Universe enabled) it'd work
<LaserJock> and in Debian
<LaserJock> but in the buildds it didn't because Main doesn't know about Universe
<slangasek> mjg59: #68370: if the fix is straightforward enough I'll accept it, time allowing
<blueyed> docbook-xml is in main, and only explicitly adding it fixed it. So I don't think that's the case here.
<pochu> slangasek: sure, I'll backport the fix and use it until RC. Then I'll let you know if I think it doesn't have regressions.
<LaserJock> blueyed: yeah, that is odd, you should check the pbuilder output where it'd doing the dep resolution
<mjg59> slangasek: Diff is the addition of:
<mjg59>     if (xf86Screens[0] ->vtSema == FALSE)
<mjg59>             return !Success;
<slangasek> mjg59: sounds good
<mjg59> slangasek: Ok. It's sitting in unaccepted at the moment.
<slangasek> pochu: sorry, you /will/ backport?  Is this not the same change you were just asking for an uploader on?
<slangasek> mjg59: if the bug's not milestoned yet, please add it so my memory doesn't lose between now and when we start accepting post-RC packages
<mjg59> Ok
<pochu> slangasek: s/backport/patch/ . They are different bugs (the one you approved me to upload and this one), but I'd like to see both in the main archive, (providing it's feasible).
<mjg59> slangasek: Milestone it to rc? We don't seem to have a final target yet.
<cjwatson> we probably should have
<cjwatson> let's see, what did we do for feisty
<slangasek> mjg59: milestoning to RC for now would be good
<mjg59> slangasek: Done
<slangasek> pochu: oh, then I think I didn't get the context for your second request, hang on a sec
<cjwatson> ok, I've added an ubuntu-7.10 milestone
<pochu> slangasek: the first one is tested, and shouldn't have any regression...
<slangasek> pochu: hnngh, the second one seems quite the ugly workaround
<pochu> that's why I'm not sure about it...
<slangasek> sigh, it appears to do what's intended though; if it works for you and it hits the queue soon enough (i.e., within a day of RC), I'm inclined to allow it all the same
<cjwatson> I think we *are* within a day of RC :-)
<slangasek> I meant on the other end actually :)
<cjwatson> oh, right :)
<pochu> Ouch, I thought RC was next week :)
<slangasek> heh, nope
* cjwatson hands pochu a nice cup of GutsyReleaseSchedule
<slangasek> wow, even the cups are more friendly around here
<pochu> Ok, will patch it tomorrow and test it (I'll also upload to ppa and ask others to do the same).
<pochu> cjwatson: thanks :)
* bigon doesn't understand why he gets (no debugging symbols found)...done. even with debug symbols installed
<heno> *** New desktop CDs are available for testing *** Please help test and file your results at https://iso.qa.stgraber.org
<Keybuk> heno: still says rebuilding
<pitti> Keybuk: I just added them
<slangasek> mvo: it was ok to accept the most recently uploaded translations, wasn't it?  earlier you said we only needed to wait for cjwatson's ok, which he gave
<mvo> slangasek: yes, pitti was so kind to accept universe/multiverse, I will test if the translations show up correctly and then we can accept the other two (I expect no problems, I'm just super cautious)
<slangasek> mvo: well, I missed that second discussion and have gone ahead with accepting them, so if there are any other problems please find them soon :-)
<bddebian> OK kiddie time, bbiab
#ubuntu-devel 2007-10-11
<seb128> cjwatson: new desktop CD doesn't hang without network but it displays a message saying that security sources will be added but not active, is that expected?
<cjwatson> seb128: yeah
<cjwatson> I'm not sure why it wasn't shown before
<cjwatson> oh, same bug I guess
<seb128> k
<cjwatson> I think I agree with the intent of the message; if security updates won't be used, you should know about it
<seb128> right
<seb128> I was rather thinking that I still want the security, I just didn't have the network connected during the installation
<seb128> but there is no way to know if that's the case or if the box has no internet access
<seb128> so commenting the sources and showing the message is probably fair ;)
* soren shakes his fist at the buildd's
<Keybuk> Ubuntu DVD amd64 [20071009] : https://iso.qa.stgraber.org/qatracker/info/1013
<Keybuk>  ... a short amount of time passes ...
<Keybuk> Ubuntu DVD amd64 [20071010.2] : https://iso.qa.stgraber.org/qatracker/info/1030
<Keybuk> aaiiiiieeee
<Keybuk> there should be a law about rebuilding DVD images more than twice a week
<Keybuk> they take that long to download!
<cjwatson> rsync, man
<Keybuk> I do rsync
<Keybuk> but I'm on ADSL
<Keybuk> so while I can download as fast as I'd like ...
<Keybuk> I can't ACK
<cjwatson> do you keep a local mirror?
<Keybuk> yes
<cjwatson> jigdo, then?
<Keybuk> oh, mirror of cdimage
<cjwatson> possibly based on the live CD
<Keybuk> I don't have a mirror of the actual packages
<cjwatson> ah, not so useful
<cjwatson> if you're grabbing the alternate and desktop as well ...
<Keybuk> it actually takes about 8-9 hours to rsync the cd images
<Keybuk> yeah
<cjwatson> I suspect that if you cat new-alternate + new-desktop + old-dvd together, and then rsync new-dvd over that, it'll be faster
<cjwatson> since the livefs is the same
<Keybuk> heh
<cjwatson> assuming you have the disk space to do that, that is
<Keybuk> rsync copes with chunks going missing?
<cjwatson> sure
<cjwatson> rsync is magic
<Keybuk> heh
<Keybuk> I might try that
<cjwatson> or at least sufficiently advanced technology
* soren kicks l-u-m-virtual
<soren> Do any of you use wmware workstation?
<Keybuk> aye
<soren> Could you check which NIC it emulates?
<soren> eth0 is not the right answer.
<Keybuk> pcnet32
<soren> Figures.
<soren> What about SCSI controller?
<Keybuk> mpt
<soren> Mkay.. Thanks.
<Keybuk> ens1371 sound card :)
<soren> Dear kernel team. In your efforts to slim down the -virtual kernel image, please don't remove my nic and scsi drivers. Love, Soren.
<mpt> Keybuk, you rang?
<mpt> Or are you referring to the driver that is the bane of my existence?
<Keybuk> mpt: you are not a SCSI card :p
<soren> Who's good a spotting why stuff breaks on buildd's but not in sbuild  and is also actually around these days?
<Keybuk> Ian is pretty good at that kind of thing
<soren> http://launchpadlibrarian.net/9898594/buildlog_ubuntu-gutsy-i386.linux-ubuntu-modules-2.6.22_2.6.22-14.35_FULLYBUILT.txt.gz  <--- the vmnet module fails to build.
<Riddell> bryce: I've raised the priority of bug 151311, it's pretty nasty
<ubotu> Launchpad bug 151311 in xserver-xorg-video-intel "DPI in kubuntu incorrect on xorg-video-driver-intel" [High,Confirmed]  https://launchpad.net/bugs/151311
<soren> Keybuk: I'll try when he's around again then.
<mjg59> Yeah, that's a touch broken
<mjg59> bryce: Weren't we nailing the dpi to 96 or whatever?
<soren> 112x968 dpi? Wow.
<Keybuk> whee, lanky fonts
<bryce> mjg59: yeah I thought so
<bryce> Riddell: sorry, I won't have time to look at it; cjwatson's sending me out for customer support for the rest of the week
<bryce> Riddell: that is one bug we split out from 127101, which is the one I'm focusing on currently
<Riddell> mjg59: that's gnome only and GDM is still unusable
<mjg59> Riddell: ?
<mjg59> No, in the server
<mjg59> bryce: Erm.
<mjg59> -#define DEFAULT_DPI            75
<mjg59> +#define DEFAULT_DPI            100
<mjg59> That's not going to override the driver.
<bryce> mjg59: but iirc seb128 put the 96 hardcode into gnome
<Riddell> we're talking about different things then
<mjg59> bryce: It has to be done in the server
<bryce> mjg59: do you know where at in the server this is done?
<bdmurray> The fix for bug 135319 should have made it in yesterday's dailies right?
<ubotu> Launchpad bug 135319 in usplash "Usplash progress bar not centered on the monitor" [Medium,Triaged]  https://launchpad.net/bugs/135319
<zul> can someone push the xen-3.1 upload through contains a security update for gutsy
<zul> thanks btw
<keescook> zul: I think that'll get snagged after RC unfreezes.
<zul> ah yes i forgot about that
<mjg59> bryce: hw/xfree86/common/xf86Helper.c
<bryce> thanks.  I also noticed something calculating dpi's in the xrandr code
<mjg59> Hm. Yeah, it might be the xrandr-side code that's tripping us up
<bryce> I'm making a patch for each, so folks can try either or both
<slangasek> zul: in the meantime, is there a public report about the bug it addresses?
<slangasek> zul: if so, please flag it with the ubuntu-7.10 milestone so that it's on the release team's radar
<bryce> mjg59: does this look sane? http://people.ubuntu.com/~bryce/Testing/xorg-server-dpi/xorg-server_1.3.0.0.dfsg-12ubuntu9.debdiff
<ion_> Seeing such a patch is painful. :-(
<mjg59> Dunno, does it work? :)
<bryce> no clue
<mjg59> Easiest way is just to build and do an xrandr query in the new server
<ion_> Whatever is done, the DPI should *not* be overridden if the user has set DisplaySize manually in xorg.conf.
<mjg59> ion_: Why not? It is already in the desktop environment.
<bryce> mjg59: I'd appreciate it if you'd take a quick look at this backtrace:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127101/comments/65
<ubotu> Launchpad bug 127101 in xserver-xorg-video-intel "laptop hangs when switching video mode" [Unknown,In progress] 
<bryce> mjg59: we're looking for any ideas for further gdb work or other things to test
<mjg59> bryce: Uhm. It hit the breakpoint. There's not a lot else I can say from there
<bryce> well, the system locks up right after that point.
<mjg59> bryce: Need to keep stepping at that point until hitting the instruction where it actually hangs
<bryce> https://bugs.freedesktop.org/attachment.cgi?id=11964&action=view
<bryce> looks like its around line 1959 of i830_driver.c - a loop doing something with PALETTE_A
<bryce>    for(i = 0; i < 256; i++) {
<bryce>       OUTREG(PALETTE_A + (i << 2), pI830->savePaletteA[i] );
<bryce>    }
<mjg59> Try putting a usleep in there
<bryce> usleep(1) ?
<mjg59> Bit longer
<mjg59> Try 20 or so
<bdmurray> sladen: was bug 135319 supposed to have been fixed?
<ubotu> Launchpad bug 135319 in usplash "Usplash progress bar not centered on the monitor" [Medium,Triaged]  https://launchpad.net/bugs/135319
<jojo4u> so ... is the release candidate on it's way?
<slangasek> it is imminent
<jojo4u> nice. btw. are there any automated tests done on each daily? I only found https://wiki.ubuntu.com/UbuntuAutomatedTesting and the qatracker in the topic
<bryce> mjg59: btw, here's an strace:  http://launchpadlibrarian.net/9943161/127101-strace.txt
<mjg59> bryce: I don't think that really helps
<mekius> hi, in Ubuntu gutsy, it creates an /etc/fstab with a /media/cdrom entry in it
<mekius> this is unecessary when hal is available and actually causes hal to return an error
<mekius> anyone know how this is being added to the /etc/fstab?
<cjwatson> mekius: partman-target does it; it's needed to make apt work right (I believe both in the installer and outside)
<cjwatson> it's too delicate to change for gutsy
<mekius> damn :/
<mekius> this causes issues with some stuff we have since we are trying to use HAL exclusively and not attempting to parse /etc/fstab at all
<mekius> anyway to make hal not care about /etc/fstab that you know of?
<mekius> any way*
<cjwatson> mekius: no idea, sorry, I don't know much about hal
<mekius> alright
<mekius> wish hal would parse /etc/fstab and use the mount point or something
<mekius> seems goofy for it to just give up and fail :/
<mekius> anyway, thx for the help
<mekius> guess i can't change the way ubuntu works wrt to this
<mekius> might just have to cut the line
<bryce> mjg59: adding the usleep() had no effect; still crashed with gray block lockup
<mjg59> bryce: Ok, so probably not a timing issue. If you skip that block entirely, does it work?
<bryce> I'll give it a shot
<bryce> mjg59: after disabling that block (and the one after) I've been unable to reproduce the issue
<mekius> bryce: hey, not your realm i'm sure, but hal refuses to mount any device listed in /etc/fstab, someone mentioned that this is necessary on the livecd for the install, is it possible to add something in ubiquity to remove the cdrom device from /etc/fstab before copying it to the installed system?
<mekius> bryce: or will we have to do this ourselves, it seems like a pain in the ass :/
<bryce> that I don't know
<bryce> sorry
<mekius> ok
<mekius> that's fine, i figured you might not :)
<mekius> hmm, how to fix this, probably gonna just have to cut the file during boot
<mekius> or comment the line might be simpler
<cjwatson> mekius: no, it's necessary post-install as well in order for apt to be able to retrieve files from the CD (AFAIK)
<cjwatson> mekius: we're not going to change ubiquity for this in gutsy (not that it would be appropriate specifically in ubiquity anyway); we may revisit this in hardy though
<cjwatson> mekius: post-install> for example, the Edubuntu add-on CD, though there are other cases where it's useful for people to use apt with the CD
<mekius> cjwatson: hmm, i see, well we don't care much about the CD after install, but i think i'll just hack it out for now
<mekius> it breaks things
<jshriver> Greetings everyone
<cjwatson> mekius: I understand that you don't, but some people do; just explaining why *we* can't just hack it out of the installer :)
<cjwatson> mekius: btw, /etc/fstab isn't copied to the installer system, it's created right there in the first place
<jshriver> hrm so linux development questions are inappropriate here? recommend a channel?
<mekius> cjwatson: created where, on the live cd?
<cjwatson> mekius: /lib/partman/finish.d/50fstab_removable_media_entries is the script in question
<mekius> hmm, k
<mekius> cjwatson: so this is only used for special install discs?
<cjwatson> in some circumstances ubiquity does rely on being able to install some packages from the CD
<mekius> ah
<mekius> are these special circumstances, or could this happen on any install?
<cjwatson> you could maybe arrange to call something just before ubiquity exits that seds /target/etc/fstab
<mekius> yeah, that is what i was thinking of doing
<mekius> but even later then that
<cjwatson> mekius: moderately special but I'm not willing to enumerate the possibilities :)
<mekius> :)
<cjwatson> any install on Intel Macs will install mouseemu from the CD, for one
<cjwatson> there are some other cases
<mekius> gotcha, alright
<cjwatson> mekius: can't be a whole lot later since ubiquity unmounts /target just before it exists
<cjwatson> exits
<mekius> i've got a place to do the sed that shouldn't intefere with all this stuff
<cjwatson> jshriver: "Linux development" is an extremely broad topic. Narrow it down a bit for yourself and pick a channel based on that; you'll probably find most of them are quite obviously named.
<jshriver> looking for a C library that lets me capture data from the soundcards line-in for analysis
<cjwatson> jshriver: I'm not an expert in this, but I'd start by searching for "alsa capture library" or some such
<bdmurray> cjwatson: What performs the mounting of crypto partitions when booting up now?
<bdmurray> Or rather presents the dailog for entering your password to have the partition mounted?
<cjwatson> bdmurray: cryptsetup
<bdmurray> 'kay thanks
<nikosapi> Is RC1 still planned to be released today (Thursday)?
<Hobbsee> probably
<nikosapi> ok, thanks.
<frostburn> there's a bug in the nvidia module introduced after 100.14.09 for certain users, is there a way to get that into the repo as an alternative?
<RAOF> frostburn: Proabably not at this point.  We *already* have 3 different nvidia drivers in there!
<frostburn> yeah i see new and legacy
<frostburn> and glx
<StevenK> I thought 100.14.09 was already in there as -new
<RAOF> And nvidia-glx being the third.
<RAOF> StevenK: No, that's 100.14.11 or something
<frostburn> StevenK, it's 100.14.19
<RAOF> StevenK: The idea is that drivers newer than .09 have a particular regression.
<RAOF> frostburn: Can you not use nvidia-glx?
<frostburn> RAOF, no direct rendering
<RAOF> frostburn: What card?
<frostburn> geforce go 7600
<RAOF> Also, no direct rendering seems more likely to be an artifact of Xgl than poor drivers.
<RAOF> Heh, same card as me :)
<frostburn> 64bit system?
<RAOF> Yup
<frostburn> i'm on a hp9000t
<RAOF> Colour me not seeing whatever bug you're seeing with nvidia-glx-new, though.
<frostburn> http://www.nvnews.net/vbulletin/showthread.php?t=92339   nearly the same as this.
<RAOF> It's an X lockup with some specific integraded cards, right_?
<RAOF> frostburn: You'll notice that was due to hardware problems? :P
<frostburn> it doesn't lock up, the screen flickers, videos can't be played, and continues to flicker randomly
<frostburn> RAOF, keep reading
<frostburn> link at the end says they eliminated all hardware problems
<frostburn> sec, let me find the other article
<RAOF> frostburn: So, "screen flickers with compiz every now and then" *is* something I'm seeing, because of fun refresh-rate issues.
<RAOF> (I believe)
<frostburn> http://www.nvnews.net/vbulletin/showthread.php?t=99426     it isn't  try the .09 ones and it wont flicker any more
<RAOF> frostburn: So anyway, my (doesn't count for anything) opinion is: (1) the .19 driver probably fixes more than it breaks, and hense should probably not be revertet, and (2) there's absolutely no way that a 4th nvidia driver is getting added to the archives.
<frostburn> yeah, the next best thing i could do is write a howto in the forums for others if they have the same problem
<RAOF> frostburn: Again, does nvidia-glx not work?  (It's possible that you'd see a bug where /lib/linux-restricted-modules/.nvidia_new_installed is left behind and breaks nvidia-glx)
<frostburn> RAOF, i'll give it another whirl, perhaps tomorrow
<superm1> bryce, i managed to test a few cases today that BulletProofX would need to kick in upon the first boot (such as the user choosing the wrong proprietary driver during install).  and it's working as expected now with the ubiquity and xorg changes :)
<bryce> superm1: ah excellent
<dholbach> good morning
<Hobbsee> morning dholbach!
<dholbach> heya Hobbsee
<maikmerten> hmmm... anybody else having experienced that the error message dialog "The composite extension is not available" in the Visual Effects preferences just won't close hitting the OK button?
<maikmerten> (it does close using the close window decoration)
<pitti> Good morning
<StevenK> Morning pitti
<Hobbsee> pitti!
<superm1> out of curiosity, does anyone know why usbfs was turned off by default in gutsy?  Just found out via http://www.virtualbox.org/ticket/747
<mdke> from some of the recent comments to bug 115616 it sounds like evms isn't getting removed automatically even with upgrades from update-manager; will a developer be taking a look at this before release? It's a serious one
<ubotu> Launchpad bug 115616 in evms "Device-mapper errors: dm-linear, lookup failed" [High,Fix released]  https://launchpad.net/bugs/115616
<mjg59> superm1: udev provides the same functionality already
<superm1> mjg59, ah i see
<mjg59> I suspect that virtualbox is expecting it to be in /proc/bus/usb, which is going to break in other situations
<superm1> yeah
<superm1> well that wasn't the case i was seeing broke actually
<superm1> it was for a firmware loader for a usb tv tuner
<superm1> that expected things in /proc/bus/usb
<mjg59> But udev lets us handle doing things like setting permissions as the device node is created
<superm1> but google pointed me at virtualbox
<mjg59> Rather than it being racy
<mjg59> (racey? Maybe that's better)
<AlexC_> Hey,
<AlexC_> Will the RC be out later today, or will it be pushed backed a bit?
<mjg59> It should be out later today
<superm1> so for cases like this tv tuner that something in /proc/bus/usb is expected, is there a particular way that things should be reconfigured nicely to work with udev?  Where else will the equivalent nodes be made then?
<mjg59> But, as usual, it might end up late
<mjg59> superm1: Either mount --bind /dev/bus/usb /proc/bus/usb or get the software fixed
<mjg59> Anything that uses libusb will already work fine
<liw> mjg59, do you know off-hand why a laptop suspend and hibernate would work in testing (10+ times in a row) but fail when used for real, overnight?
<mjg59> liw: No
<superm1> mjg59, okay i'll bug the upstream author then.  Thanks :)
<mjg59> liw: I've heard other people hitting that, but never been able to reproduce it
<liw> mjg59, I seem to have a 100% repeatable case, go me
<AlexC_> great, thanks mjg59
<liw> https://wiki.ubuntu.com/DebuggingKernelSuspend seems like a clear set of instructions for me to test this... except it only works for suspends up to about three minutes, it says
<frostburn> RAOF, well .09 doesn't work either lol
<kagou> good morning
<dholbach> hi kagou
<kagou> what's up dholbach
<dholbach> kagou: doing great - how are you?
<kagou> fine
<dholbach> mdke: you might want to refer to the motu team, not the ubuntu-dev team
<dholbach> (in your blog post)
<seb128> pitti: do you accept new packages again? pidgin and gnome-power-manager might be worth considering
<pitti> seb128: I'll rather wait for slangasek on those; he didn't accept them over night, and I don't want to disrupt his stragegy now
<seb128> k
<seb128> I though you were the one who accepted the packages this morning
<doko> is detection of 1920x1200 screens supposed to work?
<tepsipakki> doko: what panel?
<tepsipakki> at least dell panels have some issues
<doko> tepsipakki: new iMac 24"
<popey> my dell works
<popey> out of the box
<tepsipakki> doko: does the X server get it right without xorg.conf?
<tepsipakki> popey: what model?
<popey> tepsipakki: I would need to boot it to check again, i have not done so for a few weeks
<popey> it's a dell inspiron xps gen 2, with an nvidia 6800Go
<tepsipakki> popey: ah, so a laptop.. I meant that some desktop panels (like 2007WFP) reports bogus edid-data
<tepsipakki> or at least xresprobe fails there
<popey> ah, sorry
<jono> digg people - http://digg.com/linux_unix/Ubuntu_Open_Week_Announced
<popey> woot
* popey diggs
* Fujitsu falls in.
<pitti> gpocentek: hello; do you have some time to test the Xubuntu RC images, or know some people who would?
<liw> pitti, I'm in the middle of an upgrade test, but after it's done, I could test an RC image
* ogra sighs
<liw> ogra?
<pitti> liw: well, I'd rather like you to help with edubuntu and kubuntu testing TBH
<ogra> pitti, my HW is freaking out again, i couldnt do a server install on real HW yet
<pitti> hardware sucks
<ogra> stgraber apparently had a successfull virtuqalbox install thoiugh
<liw> pitti, sure, I'm here to test anything that needs testing
<pitti> liw: can you please coordinate with ogra for edubuntu testing?
<pitti> and with heno?
<pitti> DVDs are undertested, too
<ogra> liw, edubuntu-server i386 or amd64 would be appreciated
<ogra> phew ... DVDs ...
<ogra> huge downloads
<liw> pitti, sure, I'm on #ubuntu-testing for heno
<gpocentek> pitti: sorry I really don't have time
* pitti hugs liw, thanks
<liw> eek, hugging
<pitti> gpocentek: no problem; but do you know some other Xubuntu devs who could?
<StevenK> liw: Point him at the debconf wiki page. :-)
<pitti> liw: you better get used to it :)
<ogra> liw, we're the hugging company
<liw> StevenK, http://wiki.debian.org/HugAFinn that one? not specific to debconfs
<gpocentek> pitti: well Lionel can't, and I wonder if Jani really cares... so I can't think of anybody else :/
<StevenK> liw: Yes, that one. It was the simplest way to get you to remember without spoiling it
<gpocentek> pitti: when should this be done? I might find some time tonight
<liw> StevenK, you devious one :)
<pitti> gpocentek: yesterday, ideally :/
<ogra> gpocentek, Rc was scheduled for today
<pitti> gpocentek: RC will happen in a few hours
<pitti> l
<ogra> l?
<pitti> EFOCUS, sorry
<gpocentek> then sorry but I can't :/
<pitti> hm, maybe we should not announce the Xubuntu RC images then
<gpocentek> if they are not tested that's certainly the better choice
<pitti> would be embarassing if they had some grave bugs and we'd announce them, yes
<gpocentek> but I'm not in the Xubuntu team anymore so my POV doesn't really matters
<StevenK> mvo: Do you have a sec for several dorky apt questions?
<Keybuk> oops, haven't got quite used to the fact that xchat-gnome sits there asking you for the server you want to join yet
<seb128> Keybuk: ?
<seb128> Keybuk: in the preferences you can select to autoconnect to the servers and chans you want
<Keybuk> seb128: err, oh yeah :)
* Keybuk feels silly
<Keybuk> I was looking for a Server List dialog
<Keybuk> like X-Chat ordinary has
<cjwatson> Riddell: on bug 145226, do you think it's possible that I just need to wait a bit to give dcopserver a chance to start up?
<ubotu> Launchpad bug 145226 in oem-config "Kubuntu OEM DCOP error" [High,Confirmed]  https://launchpad.net/bugs/145226
<cjwatson> I'm sure I tested this and it worked for me
<DktrKranz> could a buildd-admin give back aolserver4-nsopenssl on amd64? it should be ok now
<mvo> StevenK: yes (just came back from lunch)
<StevenK> mvo: I see something strange using sbuild on amd64
<StevenK> mvo: When it comes time to unpack the .debs, it's done in all caps
<Mithrandir> DktrKranz: given-back.
<DktrKranz> Mithrandir, thanks
<mvo> StevenK: I heard about this a couple of days ago too . does it only happen with sbuild? or pbuilder as well?
<StevenK> mvo: I've not seen it with pbuilder, only sbuild, and only when building for amd64
* persia has also seen such behaviour
<StevenK> As has soren and RAOF
<mvo> StevenK: is there a bug filed about this already?
<StevenK> mvo: Hm. I'm not sure.
<Riddell> cjwatson: what is dcop being used for?
<doko> ogra: installing from the edubuntu dvd live session using ubiquity doesn't install the client chroot, correct?
<sivang> anyone has an idea for the phone numbers in the montreal office ?
<cjwatson> Riddell: KDE whines if it's not there. See the original bug 145226
<ubotu> Launchpad bug 145226 in oem-config "Kubuntu OEM DCOP error" [High,Confirmed]  https://launchpad.net/bugs/145226
<ogra> doko, correct
<Riddell> cjwatson: but KDE isn't running, the oem-config app is qt only
<Riddell> or is kdesu used?
<dendrobates> Has anyone done a successful cdrom install of Gutsy on a Sun T2000?
<cjwatson> Riddell: kdesu isn't used at that point, only in oem-config-prepare
<seb128> jamiemcc: hi, should random png icons be indexed by tracker?
<ion_> How should it decide not to index some images?
<lool> seb128: I've uploaded a workaround for RB in my newly created PPA and called for testing; perhaps it would be a good idea to start talking to the release team about pushing it, and even upload it so that they can review it and let it enter the archive soon after we hear from someone?
<seb128> lool: if you are confident that the patch will work correctly and not create a regression yes
<seb128> lool: maybe ask slangasek about it?
<lool> seb128: Ok
<lool> seb128: The patch looks really innocent
<lool> slangasek: w00t, around?
<lool> slangasek: Could you check the debdiff I attached to #116990?
<lool> I don't know whether it properly works around the problem, but at least it causes no regression here
<seb128> lool: the patch looks fine to me but I'm not really a gstreamer guy so I'm not sure of what side effect the volume element can have there
<seb128> lool: maybe attach the patch on bugzilla also for upstream input?
<lool> seb128: Ah right
<lool> Anyway it's meant to be a workaround, not a fix
<seb128> lool: right but upstream might want to also consider it for the time being
<seb128> though they should probably not, that's rather the distro job to apply workarounds for users
<seb128> at least they will know we apply a workaround if we do ;)
<lool> (sent)
<jamiemcc> seb128: random pngs?
<seb128> jamiemcc: I did apt-get source nautilus
<seb128> and I was wondering if that's normal that tracker doesn't list any of the png in the source directory
<seb128> nor source files
<seb128> it's idle and tracker-stats indicates "Images: 0"
<jamiemcc> seb128: will check...
<seb128> I was just doing some random testing on a gutsy RC install and tried to figure a way to test tracker easily
<seb128> I though that unpacking a source would make the sources and images being indexed
<seb128> but that's not the case
<jamiemcc> seb128: should do
<seb128> the .xsession-errors has "CRITICAL **: tracker_indexer_get_hits: assertion `query->words` failed" lines, dunno if that's revelant
<jamiemcc> seb128: that means you are searching on a stopword
<jamiemcc> seb128: will have that tideid up
<kagou> seb128, same problem here
<iwj> dholbach: It looks like the API of python-distutils-extra has changed incompatibly and now human-theme FTBFS.  Bug 135299.  I had a quick look but it's not obvious to me what to do and the python-distutils-extra documentation is a bit scant.  Do you know anything about it ?
<ubotu> Launchpad bug 135299 in human-theme "autopkgtest gutsy human-theme: erroneous package!" [High,Confirmed]  https://launchpad.net/bugs/135299
<jamiemcc> seb128: seems to work here fine although Im on soon to be released 0.6.4 version
<dholbach> iwj: yes, I can fix it
<iwj> dholbach: Or just tell me what to do.  I think bug 135315 looks like the same thing.
<seb128> jamiemcc: it's too late to get a new version in gutsy now, RC is today
<ubotu> Launchpad bug 135315 in feisty-gdm-themes "autopkgtest gutsy feisty-gdm-themes: erroneous package!" [Undecided,New]  https://launchpad.net/bugs/135315
<jamiemcc> seb128: I know but it contains some critical fixes, memory leaks and crash fixes
<seb128> jamiemcc: well, right, might be considered for a stable update after gutsy but that will not be on the CD
<jamiemcc> seb128: ok
<kagou> seb128, have you created a bug for this problem ?
<seb128> jamiemcc: is there any SVN patch I can try that would fix the "no source, no image gets indexed"?
<seb128> kagou: no, I'm talking to upstream on IRC right now :p
<seb128> kagou: I'll file a bug when I know what is going on
<lool> seb128: Should I look into the new gcalctool, push it into sid and then propose an UVF for it in Ubuntu?
<kagou> ok
<jamiemcc> seb128: Im not sure whta the problem is there  - can I send patches for some critical issues with 0.6.3?
<seb128> lool: we will not get new versions now but will package GNOME 2.20.1 in gutsy-updates
<TheInfinity> hello ... is there any chance to get more current madwifi drivers in ubuntu with guty? or will it be the same version all 7.10 release?
<seb128> lool: feel free to package it for Debian but that's of not real use, we will want to keep the changes to a minimal now (we will do merges with Debian in hardy) and we can't sync because of lpi anyway
<lool> seb128: Okay; so that would be just after release?
<seb128> lool: yes
<seb128> jamiemcc: if the bug are in launchpad can you attach the patches there and give the bug numbers?
<jamiemcc> seb128: sure
<lool> Err does anybody else have tracker /twice/ in the deskbar-applet preferences?
<seb128> jamiemcc: thanks
<lool> I have it one time in French one time in English
<lool> "Recherche Tracker" and at the bottom, disabled, "Tracker Live Search"
<jamiemcc> lool: there are two options for deskbar search with tracker
<seb128> lool: yes, that's expected, one is to run the tracker search tools, the other one is supposed to list results directly in deskbar
<dholbach> iwj: I uploaded a pseudo-diff to http://daniel.holba.ch/temp/pseudo-diff - if you need more help with that, let me know
<lool> seb128: I see; any reason the selection was this way around?  The other way around would be more similar to Spotlight or Google Desktop Search
<TheInfinity> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/125919 <-- or better saidf - will this bug be solved till release?
<ubotu> Launchpad bug 125919 in linux-source-2.6.22 "[Gutsy Tribe 2]  Wireless adapter not detected on MacBook Pro rev.3 (santa rosa)" [High,Triaged] 
<iwj> dholbach: I'll give that a go and let you know :-).
<iwj> Thanks.
<dholbach> anytime :)
<lool> seb128: Ok, got the reason, it's completely broken haha
<seb128> we need a bug fix cycle :/
<lool> In fact tracker is completely broken for me; it keeps indexing stuff it's not supposed to index, it's running all the time when I'm in front of the computer and not when I'm not; stracing it sometimes reveals it's loading the system immensely to update it's database, but doesn't look at any new file
<seb128> lool: do you have 0.6.3?
<lool> Yes
<jamiemcc> lool: whats it indexing that it should not?
<lool> jamiemcc: Dirs I told it not to index, such as pbuilder, ccache and the like
<jamiemcc> lool: you need to restart trackerd after changing options
<jamiemcc> killall trackerd
<lool> jamiemcc: I rebooted in the mean time...
<jamiemcc> lool: sre those dirs in the no watch option?
<lool> Is it supposed to index shell scripts?
<jamiemcc> yes
<seb128> jamiemcc: ok, I've some debug information, the log has a "ERROR: execution of prepared query InsertWatch failed due to constraint failed with return code 19"
<lool> Bah it really can't find words in documents I have from day one on this host
<seb128> "pausing indexing while client requests or external disk I/O take place"
<seb128> and then several "CRITICAL **: scan_directory: assertion `tracker_is_directory (uri)' failed"
<jamiemcc> seb128: thats caused by having overlapping watch dirs in tracker-preferences
<jamiemcc> its fixed in svn
<seb128> jamiemcc: that's a stock gutsy RC install with nothing changed
<seb128> ok, do you know if there is a bug on launchpad about that already? ;)
<jamiemcc> bug 148520
<ubotu> Launchpad bug 148520 in tracker "Trackerd starts but shows a lot of errors while indexing directories." [Medium,Fix committed]  https://launchpad.net/bugs/148520
<lool> It seems tracker segfaults before indexing; might explain why it's always running while I'm in front of the computer and why it didn't index some files
<jamiemcc> lool: anything in ~/.local/share/tracker log file?
<lool> jamiemcc: I'm uploading an apport crash report; I guess it'll be merged with the pile of strstr() crashes
<seb128> jamiemcc: .config/tracker/tracker.cfg has no overlaping directories not, it has only the user one listed
<lool> jamiemcc: no log file there, no
<jamiemcc> lool: there should be a tracker.log file in there
<lool> ls .local/share/tracker
<lool> data  lool_tracker_lock
<lool> And data has a common.db, and that's all
<seb128> jamiemcc: looks like tracker doesn't like the directory rename
<seb128> jamiemcc: like mv nautilus nautiluscopy it doesn't notice the new one
<iwj> dholbach: The file ubuntu-wallpapers.xml.in doesn't appear in the source package.
<iwj> dholbach: And your setup.cfg change seems to expect it.
<dholbach> iwj: sorry... I guess you can leave the file names as they are
<seb128> jamiemcc: does it try to be smart and no reindex in this case? What happen if it didn't index it yet?
<dholbach> iwj: I just diffed a branch where I had made it work again and a broken one (and forgot to update the file names to make more sense for you)
<iwj> OIC
<jamiemcc> seb128: do you still get errors on rename in log?
<soren> Hm. I'm about to put the Jeos generation magic stuff onto Launchpad. Wouldn't it be most sensible to make the code branch owned by core-dev?
<jamiemcc> seb128: if it gets that error then it wont be watching it
<seb128> jamiemcc: no, when I mv it there is nothing in the log
* lool goes rebooting to see whether tracker decides to create a log afterwards
<seb128> jamiemcc: ok, so it just ignore it for a reason, I've no overlapping watch dirs in the config
<iwj> dholbach: Well, I've tried various random permutations and it's still not working.  Best error message I can get is a syntax error running    intltool-merge -x po index.theme.in build/share/gnome-background-properties/index.theme
<seb128> jamiemcc: that's reliable with apt-get source, doing a copy of the source dir works correctly with tracker though
<jamiemcc> seb128: dunno - it stores the db for whatit watches in /tmp/tracker-pid
<jamiemcc> seb128: if a dupicate is detected you get that error from the db
<iwj> I changed merge_desktop_files= to xml_files= because it doesn't recognise the former any more but I do wonder if that's just wrong.
<mvo> does anyone object if I add a conflict for nvidia-settings against nvidia-glx and nvidia-glx-new? the later two have their own /usr/bin/nvidia-settings
<Amaranth> mvo: wow, that never got fixed?
<dholbach> did you also change the imports, the [build_i18n]  thing and cmdclass entries?
<iwj> dholbach: Yes.
<iwj> That part works.
<iwj> Or seems to anyway.
<mvo> Amaranth: apparently not :)
<dholbach> hang on... index.theme is not an xml file
<iwj> Indeed.
<dholbach> let me find out what distutils-extras expects there
<iwj> OK, thanks.
<dholbach> desktop_files= maybe?
<seb128> jamiemcc: the log has a "orig not found in DB" error before the "InsertWatch failed due to constraint" error
<jamiemcc> seb128: can you file bugs and I will get patches for your stuff - it could be while doing its indexing its getting messed up - I will delay indexing of new stuff until after initial indexing is comploeted
<iwj> dholbach: That worked.
<dholbach> iwj: great
<seb128> jamiemcc: orig = nautilus-2.2.0.orig, which is the name used on unpack before the renaming
<seb128> jamiemcc: ok, I'll open a bug
<dholbach> glatzor is the main python-distutils-extra person
<iwj> dholbach: The resulting .deb has some things in usr/share/locale/ which weren't there before.
<pochu> thekorn, mjg59: mind trying liferea 1.4.4-0ubuntu2 from http://ppa.launchpad.net/pochu/ubuntu/pool/main/l/liferea/ ? It fixes your issues (crash when adding local feed, and data loss upon forced termination, and a couple of fixes). If it works fine for you (it does for me) I'll ask for an exception.
<iwj> glatzor: Would you be able to help me out with porting some of our packages to the current gutsy python-distutils-extra ?
<dholbach> iwj: translations that were stripped and put into the language packs?
<iwj> dholbach: Ah, of course.
<iwj> Which means I don't need to care.
<dholbach> yooohoo :)
<iwj> Let me just actually diff the actual files.
<glatzor> for sure, iwj. but I thought that I already provided diffs for all corresponding packages after the api break
<glatzor> iwj: which one is affected?
<mvo> hey glatzor!
<glatzor> hello mvo
<iwj> glatzor: I'm fixing up human-theme right now.  I think in fact I've managed to fix it properly.
<seb128> jamiemcc: bug #151584
<ubotu> Launchpad bug 151584 in tracker "doesn't index apt-get source directories" [Undecided,New]  https://launchpad.net/bugs/151584
<mvo> glatzor: I did a displayconfig-gtk upload with a small fix today
<thekorn> pochu, wow thanks, will test this version in a minute
<glatzor> mvo: fine
<glatzor> when will the langauge pack freeze be in place?
<thekorn> pochu, this fixes bug 151217 for me, thanks
<ubotu> Launchpad bug 151217 in liferea "[gutsy]  liferea-bin crashed with SIGSEGV while trying to a new feed" [Medium,Confirmed]  https://launchpad.net/bugs/151217
<pochu> thekorn: so does for me :) thanks for testing.
<cjwatson> Riddell: oem-config is almost happy now that I've switched dcopserver and kwin around, but there's a strange partial grey background: http://people.ubuntu.com/~cjwatson/tmp/oem-config.png
<cjwatson> Riddell: is there something else I should be calling?
<Riddell> err, ouch
<Riddell> no idea what could cause that
<bddebian> Heya
<pitti_> meh, who has stolen my nick
* Hobbsee ate it.  sorry
<pitti> Hobbsee: don't worry, I just killed pitti and reinstated myself :)
<Hobbsee> :)
<tkamppeter> pitti, ping
<pitti> hi tkamppeter
<tkamppeter> pitti, today I got a bug report (bug 151510) which breaks the "printing just works" experience and the usability of system-config-printer (and also the web interface) severely:
<ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Critical,Fix committed]  https://launchpad.net/bugs/151510
<lool> pitti: Not sure who gets the subscription notifications exactly, but I subscribed the release team to #151351 and pinged slangasek on IRC (but he was probably not yet online)
<tkamppeter> pitti, if you go into system-config-printer, go to the server settings, and there mark that you want to see shared remote printers nothing happens.
<pitti> tkamppeter: hm, it does work for me; cups switches to "Port 631" and listens on all ifaces
<Hobbsee> lool: kylem, didnt you update -intel to fix the G33 -14 kernel problem?  i'm sure i ack'd that fix.
<tkamppeter> pitti, it is because CUPS changes all the "Brows..." settings in cupsd.conf correctly but does not change the "Listen localhost:631" to "Port 631", so that it actually listens to the broadcasts of the remote CUPS servers.
<Hobbsee> kylem: if so, why has lool reported 151351?
<lool> Hobbsee: It's since that revert that I get the problem personally
<lool> Hobbsee: I don't get the problem with -13
<tkamppeter> pitti, have you really ONLY marked the option to listen to broadcasts and NOT the option to share your local printers?
<Hobbsee> lool: it wasnt a revert.
<pitti> tkamppeter: I just tried that, and it does for me
<pitti> tkamppeter: oh, no; I always enable both
<lool> Hobbsee: Ah, I see what you mean, I have the latest intel
<Hobbsee> lool: what is your latest version fo xserver-xorg-video-intel?
<Hobbsee> lool: ubuntu6?
<lool> Hobbsee: I got that intel is broken in -13 too
<lool> Hobbsee: Yes, as stated in the bug report
<lool> Hobbsee: I'm fully up to date gutsy
<Hobbsee> oh, my bad.
* Hobbsee waits for kylem then
<pitti> lool: thanks
<tkamppeter> pitti, and for your tests stop CUPS, delete /var/cache/cups/remote.cache and start CUPS, otherwise you see the remote printers from the cache.
<pochu> Keybuk: re: bug 151570, I think pitti intentionally disabled it for beta because it was eating IO and CPU, but maybe we should re-enable it now?
<ubotu> Launchpad bug 151570 in tracker "No tracker index in LiveCD session" [Wishlist,New]  https://launchpad.net/bugs/151570
<pitti> tkamppeter: but shuoldn't enabling cups only open the UDP port to the general wild, and not the TCP one, too?
<pitti> pochu: no, it was intentionally disabled in general on the live system
<pitti> pochu: it kills performance and isn't that useful
<tkamppeter> pitti, what doi you mean with "enabling cups"?
<Keybuk> pochu: I mean that there should be an index on the CD *already*
<Keybuk> ie. a pre-generated one
<pochu> Keybuk: oh, misunderstood the report then.
<tkamppeter> pitti, I have simply made the patch as small and simple and as close to upstream as possible to avoid regressions. I did not try to add a new security feature.
<pitti> tkamppeter: erm, s/enabling cups/enabling browsing/, sorry
<pitti> tkamppeter: right, I just wonder why it does it that way in the first place
<pitti> tkamppeter: when I only enable browsing, I get
<pitti> tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     4816/cupsd
<pitti> udp        0      0 0.0.0.0:631             0.0.0.0:*                          4816/cu
<pitti> ...psd
<pitti> which looks just right to me; hmm
<tkamppeter> pitti, then post a feature request/security bug report upstream so that CUPS gets corrected after the Gutsy release (and perhaps in Gutsy also as security fix).
<pitti> tkamppeter: sorry, but I won't accept that patch
<pitti> tkamppeter: it would mean that users would implicitly share their printers even if they only enabled browsing and left sharing disabled in the UI
<pitti> that's both wrong and, even worse, we don't even tell them
<pitti> tkamppeter: since printers are shared by default, and only the "localhost only" default keeps them from being actually shared
<pitti> tkamppeter: there was a recent bug about that, remember?
<tkamppeter> pitti, No there is no BrowseAddress set and also the <Location /> allows only access from localhost. So no one can print on your local printers while you are listening to remote broadcasts.
<pitti> tkamppeter: ah, so it additionally changes "Allow localhost" to "Allow @LOCAL" when you enable sharing
<pitti> that's new in 1.3, too
<pitti> man, upstream really deserves a good beating, they regress their architecture with every release
<iwj> doko: I'm looking at bug 135515.  While investigating that, I discovered bug 151596.  There seem to be many of these dict-* packages.  Were they autogenerated somehow ?  There seem to be systematic problems.
<ubotu> Launchpad bug 135515 in dict-af "autopkgtest gutsy dict-af: erroneous package!" [High,New]  https://launchpad.net/bugs/135515
<ubotu> Launchpad bug 151596 in dict-af "executables in binary package, not rebuilt during build" [High,Confirmed]  https://launchpad.net/bugs/151596
<pitti> tkamppeter: anyway, not your fault
<pitti> tkamppeter: I'll commit the patch and get it uploaded
<pitti> tkamppeter: is that a fix from upstream?
<tkamppeter> pitti, no, but I loggen in already on the upstream tracker to report the bug and post the fix.
<tkamppeter> kagou, are you here?
<pitti> tkamppeter: ah, thanks
<Hobbsee> oy, LaserJock.
<nicolai__> hi
<Hobbsee> LaserJock: i hope you're going to do your ritual post-release awards.
<StevenK> Maybe I'll even get one this release
<tkamppeter> pitti, Canonical should let you go to the next Printing Summit, so that you can talk with Mike Sweet directly ...
<pitti> tkamppeter: uploaded
<tkamppeter> pitti, thanks. Waiting for your upstream bug report about CUPS' security policy ...
<pitti> tkamppeter: I'll file one about this particular bit
<pitti> better to do it step by step
<doko> iwj: ouch. how important is this for gutsy (given that we build arch-indep packages on i386)?
<doko> not autogenerated, just packaged at the same time
<iwj> Err, well, they're FTBFS due to missing build-depends too.
<iwj> Seems to be a lot of identical stuff in them.
<doko> iwj: which missing b-d?
<iwj> libmyspell-dev
<iwj> Now should be myspell-tools
<iwj> At least that's what I assume.  It's not entirely clear to me yet but ifrench-gut just needed its B-D fixing up.
<iwj> So I suppose the same is probably true for dict-af.
<pitti> seb128: wow, the apport retracers actually seem to behave now
<seb128> pitti: indeed, but we stopped apport notification so we less bugs now
<pitti> seb128: heh, that could be it, too
<seb128> get
<pitti> BenC: poor kernel team, the gutsy bugs just don't let you go... :/
<BenC> pitti: I meant to ask you, are all the right hooks for apport in upstream kernel now?
<zul> pitti: no difference than other release ;)
<pitti> BenC: last time I checked only in -mm
<doko> iwj: ok, so the right fix seems to be a b-d on hunspell-tools
<iwj> Not myspell-tools ?
<pitti> BenC: I doubt that they made it to -22; you would have noticed, there should have been merge conflicts
<iwj> And of course fixing the clean target.
<doko> iwj: do you have a list of all these failures?
<iwj> doko: https://edge.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=datecreated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=ian%2Bubuntu-autopkgtest&field.omit_dupes=&field.has_patch=&field.has_no_package=
<iwj> (sorry)
<iwj> And then search for dict, I suppose.
<iwj> I'm happy to take care of it but I do need to be sure we know what we're doing first :-).
<doko> iwj: I'm taking care of the dict-* packages
<iwj> doko: You said hunspell-tools rather than myspell-tools.  Is there a significant difference ?
<iwj> OK
<doko> iwj: yes, hunspell is the newer myspell
<iwj> doko: Since I have this fix to ifrench-gut too and if one of hunspell and ispell is being removed or something then I should make the right fix.
<iwj> Ah.
<iwj> So b-d on hunspell is better ?
<iwj> Assuming it works.
<ogra> iwj, meeting ?
<Keybuk> fontconfig is stupid
<iwj> ogra: 1600Z wasn't it ?
<Keybuk> it has that silly /etc/fonts/conf.avail directory of config files
<Keybuk> and then you make symlinks in /ets/fonts/conf.d to select which ones you want
<ogra> iwj, well, its running :)
<cjwatson> iwj: 1500Z
<iwj> ogra: OK, thanks :-).
<doko>   * build myspell-tools with myspells (un)much and the perl scripts
<doko>     for people who either cannot use hunspells (un)munch or need either
<doko>     /usr/bin/i2myspell or /usr/bin/is2my-spell.pl. ispellaff2myspell
<doko>     is in both and remains here, too
<Keybuk> a moronic scheme that seems to have started somewhere near apache, and infected other packages (including Debian's udev :p)
<iwj> I can only get one timezone right in any 24h period.
<Keybuk> except fontconfig goes one better, by *shipping* the symlinks in its own package
<doko> iwj: ^^^ so if it can be built with hunspell, it should be built
<Keybuk> so it actually prevents you from being able to disable the conffiles after all
<Keybuk> d'oh
<iwj> doko: OK, will look after the meeting.
<lool> pitti, Hobbsee: (this is urgent) turns out 151351 is caused by the combination of xserver-xorg-video-intel not being reverted and kernel being reverted; kylem thought you didn't approve the kernel for RC and would have pushed xorg-intel later to go with the kernel in the archive
<lool> pitti, Hobbsee: this means G33 support is currently broken in the RC CD; is there time to review xserver-xorg-video-intel with a patch disabeld and rebuild the CDN
<lool> s/CDN/CD?
<MrMazda> anyone know why kernels have CONFIG_FRAMEBUFFER_CONSOLE=m instead of =y?
<BenC> pitti: I mean for 8.04
<pitti> lool: hm, that was a misunderstanding then; we were asked to let it in
<Hobbsee> lool: why did the kernel get reverted?  i dont reclal ever discussing the kernel for the RC.
<pitti> BenC: let's hope so; I'll check it soon
<BenC> wonder if it made it into 2.6.23
<Hobbsee> excluding some stuff with lamont
<seb128> bug #151351
<ubotu> Launchpad bug 151351 in linux-source-2.6.22 "Corrupted screen on G33 with -14 kernel; regression from -13" [High,New]  https://launchpad.net/bugs/151351
<lool> pitti, Hobbsee: I can't explain the misunderstanding, but my tests and the clarifications I just had with kyle made it clear that it's clearly broken right now
<Hobbsee> lool: fair enough.
<lool> I'm going to reboot to test the proposed fix
<cjwatson> pitti: (#ubuntu-meeting) kubuntu oem is nothing to do with permissions, it's switching the order of dcopserver and kwin startup
<pitti> ah, I see
<cjwatson> pitti: I'm just trying to figure out why doing that also causes some visual corruption; I think I need to run kdesktop or some such too
<pitti> so it seems I got it totally wrong then: the impact is not too bad, but the solution is non-trivial
<Riddell> I don't know how oem-config does its background
<Riddell> possibly it's doing something weird and not drawing a background, but I wouldn't think so
<cjwatson> lool: rebuilding the CDs at this point involves delaying the RC
<cjwatson> pitti: I don't think it's all that hard, just needs another half-hour or so of my time
<cjwatson> should be about three lines in total
<Kmos> cjwatson: I think one day of delay to have something better isn't a problem..
<cjwatson> Kmos: http://wiki.ubuntu.com/TimeBasedReleases
<Kmos> for me ofcours, as a Ubuntu user
<cjwatson> then it's another day for something else
<cjwatson> and another day for something else
<pitti> not to mention breaking the schedule of stuff after it (final, UDS, etc.)
<cjwatson> and then something breaks in the thing that you tried to fix and you need to spend another few days sorting that out
<Kmos> cjwatson: yes.. but if there are really important things, else people will test the RC and report a lot of bugs that are already fixed.. but they can be updated after the release
<Kmos> so isn't a problem
<Hobbsee> cjwatson: and at this point, risks delaying the final.
<Hobbsee> Kmos: dude, no.
<Kmos> so i think it should be released in time
<Hobbsee> Kmos: they should be reading the release notes, which highlights these bugs.
<jojo4u> ... speaking of the RC, I am eagerly avaiting it. is there some news on it?
<Kmos> Hobbsee: yeah, that too
<cjwatson> jojo4u: it's not the end of the day yet
<cjwatson> jojo4u: it will be announced on mailing lists when it is released
<lool> Hobbsee, pitti: fix confirmed to be working
<pitti> lool: \o/
<jojo4u> which lists? ubuntu-devel-announce?
<pitti> lool: so, please get it uploaded soon, so that it gets into the archive quickly after RC
<pitti> lool: thank you
<slangasek> lool: bug #116990: I'm certainly a bit nervous about side-effects from such a change, but I don't see how those can be avoided and still fix this bug; please upload ASAP so we have maximum opportunity to detect regressions before final
<ubotu> Launchpad bug 116990 in rhythmbox "Rhythmbox sound problems (clicking/snapping/crackling) when not using crossfading backend" [High,In progress]  https://launchpad.net/bugs/116990
<slangasek> pitti: also, care to give a second opinion on 116990?
<lool> Could someone please sponsor http://people.ubuntu.com/~lool/packages/xserver-xorg-video-intel/2:2.1.1-0ubuntu7/sid/
<pitti> slangasek: will do after meeting
<Keybuk> mdke: https://wiki.ubuntu.com/Evms
<cjwatson> jojo4u: yes
<cjwatson> or ubuntu-announce, both are low-traffic
<jojo4u> ok, thank you very much *subscribing*
<lool> pitti, Hobbsee: so any change to get this in for RC?
<lool> Ah it was uploaded by Kyle already
<pitti> lool: no, post-RC
<pitti> lool: it would delay the release by at least a day or so
<lool> Ok
<Keybuk> wow, dapper had wobbly windows!
* Keybuk watches ubiquity remove language packs and shuffle its window size around as it does so
<ogra> yeah, that was an early version :)
<ogra> the screensaver used it too
<ogra> (even without removong packages :) )
<highvoltage> Anyone know whether Gobuntu will also be released on the 18th? There's been questions about it on the gobuntu-devel mailint list, but no answers yet.
<cjwatson> highvoltage: the answer is yes
<highvoltage> cjwatson: great, thanks.
<cjwatson> evand: ^-- could you open the lines of communication with gobuntu-devel a bit? :)
<pitti> evand: btw, did anyone test http://cdimage.ubuntu.com/gobuntu/daily/20071010/ ?
<pitti> IOW, should we include it into the announcement?
<evand> cjwatson: will do
<lool> slangasek: seb128 is sponsoring the rhythmbox upload
<seb128> lool: already uploaded and listed on #ubuntu-release ;)
<lool> Ah, I'm not on -release
<lool> (I am now)
<evand> pitti: I tested it, yes
* Hobbsee notes that if anyone comes in there requesting new versions of things, etc, we *will* shoot you
<evand> pitti: I think it would be appropriate to include in the announcement, but do I have time for testing i386 as well (I just tested amd64)?
<cjwatson> evand: start now :)
<pitti> evand: please; I doubt that the various partitioning schemes etc. differ, but at least one default test should be made
<evand> ok, pulling down the image no
<evand> w
<pitti> slangasek, evand: can you two please coordinate the inclusion of Gobuntu into the announcement?
<evand> sure
<AlinuxOS> pitti, hello, where can I download RC for testing ?
<pitti> AlinuxOS: see topic
<AlinuxOS> pitti, :D
<AlinuxOS> ah thanks.
<pitti> AlinuxOS: it links to instructions and the images
<slangasek> evand: draft is https://wiki.ubuntu.com/GutsyGibbon/RCAnnouncement, fyi
<evand> do you mind if I edit that straight, or would you prefer I pastebin the changes for gobuntu?
<slangasek> straight editing is fine, I assume that I won't need to revert /all/ your changes ;)
<evand> heh
<Hobbsee> nixternal: did you write teh kubuntu section of that?
<Hobbsee> someone has, and they dont know KDE - or they've only read what the marketing is.
<slangasek> evand: off the top of my head, I guess we should have a highlights section for Gobuntu saying "this is the first release of Gobuntu, $short_description_here"?
<Hobbsee> besides, strigi is off by default now.
<Riddell> strigi is still installed by default
<slangasek> Hobbsee: it's inherited from the info from past milestones
<Riddell> Hobbsee: it reads fine to me
<evand> slangasek: indeed, I was thinking something along the lines of "this is the first release of Gobuntu, a version of Ubuntu that follows the 7(?) freedoms outlined by the FSF."
<Hobbsee> Riddell: one would assume that people would look to find strigi running, not whether it's installed or not
<evand> actually, there might be some text on w.c.c to steal, I'll check in a moment
<Hobbsee> slangasek: that doesnt mean it doesnt suck :P
<Riddell> Hobbsee: one might look for it in the menus :)
<pitti> lool: please manually close the -intel bug, there is no LP: #1234 in the changelog
<Hobbsee> Riddell: pillars of KDE sounds like KDE4 marketing - with no particular mention of what it is, or hwo to use it.
<Hobbsee> Riddell: one might.  if one uses menus.
<lool> pitti: Ok
<Riddell> it's konqueror's default search item too
<pitti> lool: thanks
<Riddell> those are only summaries, more information is in the link below
<lool> pitti: It's already "fix released"
* ogra dances
<ogra> yay
<slangasek> Hobbsee: I think my point might be that if things that were treated as key talking points in earlier milestones go away, someone needs to speak up (as you're doing now) :)
<ogra> finally one install i got through without anyy HW dying
<slangasek> evand: hmm, hopefully something without a question mark in the middle? :)
<Hobbsee> slangasek: :)
<evand> haha, we'll see
<cjwatson> evand: classically, there are four freedoms outlined by the FSF
<evand> cjwatson: thanks
<LaserJock> Hobbsee: indeed I shall ;-)
<Hobbsee> LaserJock: :D
<ogra> seb128, did you hear about any scrollkeeper-update eats 100% CPU bugs ? seems LaserJock got hit by it with a fresh gutsy install
<seb128> ogra: no, or nothing new recently, scrollkeeper crash or behave badly every now and then, we get a few bugs every cycle, that's random
<LaserJock> so it's just my luck?
<seb128> ogra: we started switching to rarian and we will probably demote scrollkeeper to universe next cycle
<seb128> LaserJock: probably yes
<seb128> LaserJock: for how long is it using CPU?
<seb128> scrollkeeper-update is not the faster command in the world, it can take some time
<LaserJock> until I kill it
<seb128> ok, so no luck for you ;)
<slangasek> ogra: are we a go for RC on Edubuntu?
<slangasek> Riddell: ^^ ditto Kubuntu?
<LaserJock> it was starting up multiple copies too
<ogra> slangasek, looks good to me ...
<Riddell> slangasek: I'm happy
<ogra> addon i386 could need a test and amd64 dvd is missing ...
<LaserJock> seb128: and I don't know if it's your area but my panel doesn't show up until I click the desktop
<ogra> but since the amd64 variant of the addon was tested good i'm not sorried here
<LaserJock> seb128: ogra said that it was an nvidia thing maybe, but I've got ATI
<ogra> *worried
<LaserJock> ogra: I did i386 addon
<ogra> ah
<ogra> cool
<seb128> LaserJock: that's a compiz thing
<LaserJock> k
<ogra> slangasek, i'm fine then ...
<seb128> LaserJock: should be fixed with the new compiz which is not on the CD but has been accepted
<slangasek> ogra, Riddell: sweet, thanks
<LaserJock> compiz was a disaster for me anyway
<LaserJock> so I had to get rid of it
<LaserJock> it kept shadding Firefox everytime it loaded a new page
<LaserJock> shading
<ogra> weird
<LaserJock> it's like it put Firefox in the background while it was loading the page
<cjwatson> ogra: amd64 dvd missing as in untested?
<cjwatson> it seems to be present, at least
<LaserJock> and then when it was done it'd bring it forward
<ogra> cjwatson, as in unteasted, yes
<ogra> gah
<ogra> untested
<pitti> untoasted?
<doko> cjwatson: I just ran the live session, testing the installer after the meeting
<cjwatson> doko: which, edubuntu amd64 dvd?
<ogra> cjwatson, but i'm fine for RC with it ... i know the CDs are fine
<doko> yes
<cjwatson> ok, cool
<mertiki> Hi everyone, I worked on a bug in libqt3-mt and found the problem, and uploaded a debdiff to fix this into launchpad. This would be important that this bug is fixed before Gutsy hit stable, does someone can look at this?
<mertiki> 145709
<ogra> oh, wow
<ogra> doko, you rock
<mertiki> doko : I sended you a mail about this, you were one of the last person who worked on that package
<doko> mertiki: Riddell is your man
<mertiki> doko : thanks, is Riddell here sometime?
<slangasek> evand: how goes the edit?
<jojo4u> mertiki: he is loggin in
<ubudev> who can tell me how to send my program using launchpad???
<mertiki> jojo4v : thanks :)
<evand> slangasek: slowly, I'm trying to type an announcement to gobuntu-devel and test the i386 image at the same time. I'll focus on this though.
<Hobbsee> ubudev: you probably want #launchpad
<Kmos> kmos@bash:~$ totem
<Kmos> Error: Failed to send command: 500 command not parseable
<cjwatson> ubudev: https://help.launchpad.net/ has documentation
<slangasek> evand: ok, thanks
<Kmos> when I click on more inforation about plugins
<ubudev> thanks
<Kmos> i got that error
<Hobbsee> Kmos: and this is not a support channel, as you well know.
<Hobbsee> has anyone else filed a bug about it, or is it a local problem?
<Kmos> Hobbsee: i'll check
<mertiki> Riddell : When you'll be there, can you take a look at bug #145709 ( there's 2 debdiff, make sure you take the good one )
<ubotu> Launchpad bug 145709 in qt-x11-free "7.10: Qt3 ~/.qt owner root and missing qtrc result result in ugly appearance" [Undecided,In progress]  https://launchpad.net/bugs/145709
<Kmos> and report it if there isn't any report yet
<iwj> cjwatson: So I'm looking at this package and AFAICT it's completely barking.  There are these random decimal numbers in usplash-theme-ubuntu.c for the text colour.  Do they correspond to anything anywhere ?  They don't appear to be indices into the pixel tables in (say) usplash_1024_768.png.c.
<mekius> bryce: btw, I got the autodetection working for the X video driver.  I had added the entries in the discover data files, but apparently I updated the files for version 2 of discover and only version 1 of the library was installed.  I installed version 2 and it uninstalled version 1, but I then reinstalled version 1 without any conflict, very strange.
<mekius> iwj: they should be grabbing colors from the background image
<mjg59> iwj: The images should be palletised
<iwj> mjg59: Yes.
<mjg59> My recollection is that the colours should just be palette entries
<iwj> I mean, the numbers in usplash-theme-ubuntu.c don't seem to be indices into eg usplash_1024_768_palette.
<mjg59> How odd.
<mjg59> The theming stuff was all done by someone other than me, so I'm afraid I can't help there...
<iwj> Everyone agrees that it comes up as darkish blue, right ?  The usplash text box for (eg) you should remove the CD now or please type in your boot passphrase.
<cjwatson> it's been a while since I looked at it
<cjwatson> I see it as darkish blue in vmware, yes
<mjg59> Yes
<iwj> I'm looking at  .text_{background,foreground,success,failure}   which are all various shades between orange and green.
<iwj> Err, except background which is black.
<iwj> If you look them up in what is allegedly the palette, that is.
<pitti> iwj: darkish blue> yes, for CD checksum tests, passphrase input, and "take out CD"
* cjwatson digs through usplash drivers
<mantiena-baltix> glatzor, hi
<mantiena-baltix> mjg59, hi
<mjg59> mantiena-baltix: Hi
<glatzor> evening mantiena-baltix
<iwj> svgalib/gl/grlib.c contains a gl_setpixel and a gl_setpixelrgb of which latter uses gl_rgbcolor which does some bitfield munging depending on the depth.  But that doesn't seem to be what's going on either.
<cjwatson> that's what's called ...
<mantiena-baltix> glatzor, ready to talk about displayconfig-gtk crashes ? ;)
<cjwatson> usplash_text does gl_setpixel
<iwj> cjwatson: Right.  gl_setpixelrgb is just gl_rgbcolor followed by gl_setpixel on the result.
<cjwatson> what calls usplash_set_palette?
<iwj> Which suggests that the pixel value is a set of bitfields.
<mantiena-baltix> mjg59, why your virtual-screen patch still not included into official Ubuntu packages?
<mjg59> Is it also blue if using framebuffer?
<mjg59> mantiena-baltix: It's uploaded, but we're frozen right now
<iwj> cjwatson: usplash_setup
<sladen> iwj: (I specifically refused to touch usplash until a month ago, and I'm regretting it already).  The "decimal numbers" are palette entries to reuse for other things.  the RGB triplets are fetched from the image file
<cjwatson> (usplash desperately needs an active maintainer)
<iwj> sladen: But they're not, or at least not in the obvious way.
<mantiena-baltix> mjg59, oh, so, we should wait until release candidate will be released ?
<mjg59> Yes
<iwj> sladen: Something is dark blue and the relevant entries aren't even nearly dark blue.
<glatzor> mantiena-baltix: could you point me to the corresponding bug reports? we could also switch to the #ubuntu-desktop channel since it is more calm
<pitti> hm, how does one test this thing? I tried "sleep 5; sudo usplash_write TEXT_URGENT hello" on VT1 and "sudo usplash" on VT2"
<pitti> sladen: ^ any idea?
<pitti> erk, s/_/-/ might help
<cjwatson> no, it's usplash_write
<iwj> Of course it could be that gl_setpixelrgb just doesn't work.  Nothing seems to call it.
<mjg59> iwj: Does the same issue occur if using a framebuffer?
<iwj> mjg59: I have no idea.
<pitti> no, that didn't help
<cjwatson> pitti: usplash_write's argument parsing is crackful, IIRC
<cjwatson> pitti: try usplash_write 'TEXT-URGENT hello'
<pitti> cjwatson: I meant, it's TEXT-URGENT, not TEXT_URGENT
<cjwatson> oh, and yes it is TEXT-URGENT rather than TEXT_URGENT, I misunderstood you
<sladen> pitti: sudo usplash -c & sleep 1 ; sudo usplash_write PULSATE
<pitti> cjwatson: yes, that helped
<pitti> thank you
<pitti> so, except that my usplash screen is now distorted since I reinstalled gutsy two hours ago, and I cannot read the font at all, it works
<Riddell> mertiki: how does adding /etc to qt's packaging help it?
<sladen> pitti: "distorted?"
<Riddell>  /etc should already exist long before qt is installed anywhere
<pitti> slangasek: looks like pixels get shifted within an 8x8 block or so
<sladen> cjwatson: it is one of the most embarassying bits of code mjg59 has ever written, yes.
<iwj> mjg59: Can I tell it to use a framebuffer on the boot command line ?
<mjg59> iwj: vga=791 should work
<mjg59> But people have been complaining it doesn't
<sladen> mjg59: is there a way to /not/ get usplash to use the theme and instead to use the testcard?
<nixternal> Hobbsee: https://wiki.kubuntu.org/GutsyGibbon/RC/Kubuntu
<mjg59> sladen: No
<Whoopie> mjg59: didn't follow the whole discussion, but on my laptop, usplash verbose output is blue if I don't use framebuffer, but it's orange with framebuffer.
<cjwatson> wouldn't building the initramfs without the theme do it?
<cjwatson> Whoopie: oh dear, that suggests that the svga and bogl drivers behave differently
<cjwatson> Again
<Hobbsee> nixternal: looks nice - you may want to touch up the mailout, though
<sladen> there are two sets of images that can be used, to two sets of backends
<Whoopie> cjwatson: do we still use bogl? I thought everything is done with svga now.
<cjwatson> Whoopie: framebuffer => bogl
<cjwatson> or maybe it's the other way round
<iwj> Bah!  Foiled by the broken mirror _again_.
<nixternal> Hobbsee: roger that
<mjg59> Whoopie: Ok, that sounds like it's an svgalib issue
<mjg59> Whoopie: No, framebuffers are all bogl
<cjwatson>         fd = open("/dev/fb0", O_RDWR);
<cjwatson>         if (fd < 0) {
<cjwatson>                 usplash_operations = &usplash_svga_funcs;
<cjwatson>                 return;
<cjwatson>         }
<cjwatson> so yeah, svga only used if framebuffer not present
<cjwatson> iwj: still want the i386 DVD? it'll be finished burning here in about 10 minutes
<sladen> but the livecd always loads a vga16fb ?
<sladen> (or in theory, always does?)
<pitti> mdz, evand, cjwatson: should gobuntu go on releases.u.c.?
<pitti> slangasek: CC: ^
<cjwatson> pitti: I think it's a matter of whether the mirrors have space for it at this point
<iwj> cjwatson: Bring it to the pub.
<cjwatson> pitti: somebody should ask IS whether they can accommodate the size increase with/without it
<pitti> cjwatson: assuming they have, isn't it a question of official support?
<iwj> I'll have to run your amd64 one across tomorrow.
<cjwatson> iwj: not sure yet whether I'll be there tonight
<sladen> it would be politically ideal if gobuntu /did/
<cjwatson> but I can at least stop down with the DVD, I guess
<pitti> right
<iwj> cjwatson: No, I can come round tomorrow to exchange.
<cjwatson> pitti: I think it would be correct for Gobuntu to go on releases.u.c, if there's room
<mjg59> sladen: No
<mjg59> sladen: Alternative loads a vga16fb
<mjg59> But only just before starting the installer
<cjwatson> (and doesn't use usplash at that point anyway)
<sladen> mjg59: ...does that mean that there isn't a fb on the livecd then, and the svgalib gets used?
<mjg59> Yes
<mjg59> That's why it's in more than 16 colours
<sladen> mjg59: what what is /normally/ getting used on the install, vesafb or svgalib aswell?
<mjg59> sladen: svgalib
<mdz> pitti: no, not worth the risk
<sladen> mjg59: ls -l /dev/fb* || echo svgalib  ... hmmm
<cjwatson> mdz: which risk?
<mdz> pitti: there is not enough of a need for mirroring to justify risking filling up mirrors
<cjwatson> ah
<cjwatson> we can still link it clearly from releases.u.c
<cjwatson> as we do with xubuntu
<pitti> mdz: ok, I see
<cjwatson> mdz: btw, what do you think about punting edgy to old-releases.u.c, even though it's still supported?
<cjwatson> I think that would help
<sladen> mdz: in that case, spin it "to preserve the true freedom of gobuntu", we request mirrors to mirror gobuntu separately so they can be fully aware of the difference, and perhaps even choose their own even-freeier-hosting for Gobuntu"
<mdz> cjwatson: no objections at all
<mdz> cjwatson: I don't think the URL makes a big statement about whether something is supported or official
<mdz> cdimage.ubuntu.com is just as official as releases.ubuntu.com
<mdz> hell, that's where the official release DVDs live
<mdz> for exactly the same reason (mirror space)
<cjwatson> I should probably start on that now then
<doko> iwj: all dict-* packages fixed; had a look at the packages which fail in gcj. How much memory does your autobuilder have?
<iwj> doko: 1Gby
<iwj> doko: dict-*>  Thanks a lot.
<doko> iwj: could you recheck with 2GB? I know that gcj is a memory hog on amd64
<iwj> doko: Blimey.
<iwj> doko: I'll see what I can do.
<doko> iwj: just one package (ant for example)
<iwj> doko: Right, I'll get back to you.
<doko> iwj: looking at the other dictionaries now (if you didn't start yet)
<iwj> I'm on ifrench-gut.
<evand> pitti: gobuntu i386 works, though for some reason usplash didn't start
<iwj> Are there others that are broken ?
<pitti> evand: hm, not start at all? or time out due to vmware slowness?
<evand> maybe vmware slowness
<sladen> evand: if you can start it without quiet, do any messages popup before usplash bombs out?
<doko> iwj: myspell-lv myspell-sl ispell-czech
<pitti> iwj, cjwatson: ok, I got the cryptsetup initramfs hook to just make the password prompt disappear when it was successful; that avoids even more untranslatable text, etc, and IMHO is a good enough feedback; WDYT?
<pitti> iwj, cjwatson: the alternative is a single [OK]  on the screen (the input text and response disappears in any case; we cannot write it below the prompt)
<iwj> pitti: Oh, absolutely.
<iwj> Having it disappear is just fine.
<pitti> but i'd prefer a clean screen again
<pitti> iwj: ok, thanks; doing that then
<iwj> Excellent.
* pitti wonders whether he should kill the horrible UUID string, too
<iwj> doko: Ah.  Err, OK, well, I'll finish ifrench-gut and leave those to you then, unless you'd prefer me to take them on ?
<pitti> "Enter password for sda5_crypt" is intimidating enough with out the trailing "(/dev/disk/by-uuid/yayayada1234)"
<iwj> pitti: Oh, it might have some security value.
<iwj> Err, I think.
<doko> iwj: I will do these, most likely just requesting syncs
<iwj> I agree it's a bit horrid but let's not make unnecessary changes at this stage.
<evand> sladen: it moves way too quickly for me to read.  Is this logged somewhere specific?  syslog?
<pitti> iwj: well, I'd keep the sda5_crypt, but the UUID?
<pitti> iwj: assuming that the machine doesn't even get that far if the UUID is wrong (I'll check that), it is a little too much IMHO
<iwj> pitti: That might have some value in stopping you being tricked somehow.  Err.  I haven't thought clearly about this
<iwj> I'm trying to avoid having to think clearly about it IYSWIM :-).
* pitti checks the code where it gets the value from
<iwj> Hmm.
<iwj> If you recognise the UUID then you can avoid typing the passphrase into things which don't know it.  But all such things are either (a) the right place to type it or (b) some different hardware which you ought to notice or (c) trojanned code on your hardware somehow which can read the uuid anyway.
<iwj> So I think it's fine to remove it.
<slangasek> Riddell: wrt your latest change to the RCAnnouncement, this is wording that's been present in multiple previous announcements and signed off (at least implicitly) by a number of people; could you please not make changes of that sort without discussion?
<iwj> pitti: Would you please reject my ifrench-gut upload ?  It's the wrong one.
<pitti> iwj: so, it reads the value from the initramfs configuration file
<iwj> Yes, but you can find the value on the hard disk too.
<pitti> iwj: so, if someone can modify your initramfs, then it doesn't matter any more
<iwj> Right.
<Riddell> slangasek: ok, but I've noticed people being confused by it
<iwj> Well, I was thinking a malicious USB stick.
<pitti> iwj: and if someone modifies the UUID, the device won't be found (since it's hardcoded in initramfs) and the thing just blows
<iwj> But if you don't notice the stick you've lost anyway since the stick can find the uuid out of your hard disk or initramfs
<pitti> iwj: but wouldn't that scenario be "untrusted stick, trusted initramfs"?
<slangasek> Riddell: then I think discussion is definitely in order, I just don't want to go around changing wording after it's already passed by ubuntu-doc in its previous form :)
<iwj> pitti: If the BIOS boots from the stick then you lose.
<slangasek> Riddell: in this case, could you shoot a quick note to ubuntu-doc && mdz about the change?
<pitti> iwj: ifrench-gut> rejected
<iwj> The question is just does the uuid in the prompt help, and it doesn't in this case.
<iwj> pitti: Thanks.  ubuntu2 is on its way.
<mdz> slangasek: happy to ack it quickly here
<mdz> I'll have a look
<pitti> iwj: right, that's what I mean
<iwj> pitti: Then we are in agreement.
<pitti> since it reads that very information from the thing (initramfs) you have to trust anyway
<pitti> iwj: splendid; I'll remove it then for eye-friendlyness
<mdz> slangasek: I think 'and' is more correct than 'or', but I agree with s/our/a/
<slangasek> ok, thanks
<mdz> slangasek: now that I read it, and since you're there, "distinction" would be better than "separation"
<iwj> cjwatson: Did you want me to suggest a wording for the partman-crypto passphrase setup page ?
<slangasek> mdz: ack, changed
<tkamppeter> I tried out displayconfig-gtk on my laptop with Intel i915 because before I never could get the display content onto a projector on the external VGA port.
<cjwatson> iwj: I hadn't got that far yet, was going to look tomorrow
<iwj> cjwatson: OK, well, let me know if you do.
<tkamppeter> But after configuring a 1024x768 flat panel as the second screen, mirroring the first screen I got only a demo of Bulletproof X. Then reconfiguring from the tool started under the VESA fallback I got back to normal but with the external monitor not configured.
<doko> pitti: subscribed you to bug 137260
<ubotu> Launchpad bug 137260 in language-support-he "autopkgtest gutsy language-support-he amd64: erroneous package!" [High,New]  https://launchpad.net/bugs/137260
<cjwatson> iwj: thanks, will do. I was planning to scratch my head and see if there was a way to preserve at least some of the existing translations.
<pitti> doko: thanks
<iwj> cjwatson: Mmm.
<iwj> cjwatson: I think that translation damage is just a consequence of adding features like this to the base set at a late stage.
<cjwatson> iwj: po-debconf translates paragraph by paragraph, so that property would be satisfied by making sure new text is added as a new paragraph
<cjwatson> if that turns out to be possible
<cjwatson> yes, but I think if we're concerning ourselves with making text more comprehensible then we should try to preserve what translations we can as part of that, otherwise it may be self-defeating
<iwj> cjwatson: paragraphs> Ah, yes, that makes sense.
<doko> iwj: bug 150052, looks like util-linux is not installed (getopt), but util-linux is priority required
<ubotu> Launchpad bug 150052 in mbr "autopkgtest gutsy mbr: erroneous package!" [High,New]  https://launchpad.net/bugs/150052
<glatzor> bryce: urgent ping
<cjwatson> doko: mbr build-deps linux32 which util-linux conflicts/replaces/provides; I wonder if that's causing a problem?
<cjwatson> (but surely the provides ought to be sufficient)
<doko> Investigating util-linux
<doko> Package util-linux has broken dep on linux32
<doko>   Considering linux32 9998 as a solution to util-linux 5108
<doko>     Reinst Failed because of protected linux32
<doko>   Removing util-linux rather than change linux32
<doko> cjwatson: ^^^, ok leaving this to iwj, seems to be a problem with the test builder
<Mithrandir> "removing util-linux" doesn't really look like a great idea.
<mjg59> glatzor: What's up?
<glatzor> mjg59: I fixed three major bugs in displayconfig-gtk
<glatzor> mjg59: And I need somebody to upload
<glatzor> and confirm
<Whoopie> mjg59: albert23 from #ubuntu-motu tested my usplash patch for uswsusp. two things: 1) his /etc/uswsusp.conf had the UUID for resume device (mine had /dev/sdaX), 2) it also hangs for him at 100% progress bar on resume.
<Whoopie> mjg59: do you have time to look into it?
<mjg59> Whoopie: Nope
<mjg59> glatzor: Diff?
<glatzor> mjg59: would you like to upload?
<Mithrandir> Whoopie: hanging on 100% is known, alt-sysrq-k fixes it.
<Mithrandir> "fixes"
<doko> iwj: the auto builder doesn't run debian/rules clean before starting the build. is this intended?
<Mithrandir> works around it at least.
<glatzor> mjg59: I committed the changes to the official branch of displayconfig
<Whoopie> Mithrandir: known for usplash?
<mjg59> glatzor: Which is where?
<glatzor> mjg59: https://code.edge.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu
<Mithrandir> Whoopie: uswsusp+usplash, yes.
<glatzor> mjg59: quite awkward bugs :/ why is there no stealth mode for changelogs :)
<iwj> doko: Yes.
<mjg59> glatzor: Ok. It's not getting in before rc, so you should speak to the release team
<iwj> doko: That is, it's intended and IMO correct.
<iwj> doko: I understand why pbuilder does it but it's not supposed to be needed.
<doko> iwj: ok, fixing scim-pinyin
<iwj> doko: Oh, thanks.
<glatzor> mjg59: sorry, but I am not familiar with post-rc uploads, could you name me a person to contact?
<Whoopie> Mithrandir: nice, worked indeed.
<mjg59> glatzor: slangasek is probably sensible at this time of day
<Whoopie> Mithrandir: do you know the reason for the hang? anybody tried to debug?
<Mithrandir> Whoopie: I've talked on and off with the kernel team about it for eight months or so
<Whoopie> Mithrandir: so it just happens on some laptops or PCs?
<Mithrandir> Whoopie: I only use uswsusp on my laptop
<slangasek> mjg59: why should I be any more sensible this time of day than at others?
<mjg59> slangasek: You're unlikely to have started drinking at this stage
<slangasek> hmm, unfortunate but true
<doko> iwj: your list shows duplicates as well
<iwj> doko: Yes.
<iwj> doko: autopkgtest bugs are sometimes dupes of other bugs but if you eliminate dupes they don't show up at all.
<doko> iwj: ok, even those whith fixed reports =)
<iwj> That's a bug in LP.
<iwj> Bug 147754
<ubotu> Launchpad bug 147754 in malone "searching including duplicates uses wrong status" [Undecided,New]  https://launchpad.net/bugs/147754
<iwj> (I can't believe it's still Undecided FFS)
<iwj> doko: The only way to fix it is to unduplicate the autopkgtest report, manually set the status, and reduplicate it.
<iwj> bdmurray: AYT?
<iwj> bdmurray: Any progress on your LP DB access ?
<Whoopie> Mithrandir: is there a bug report for this issue?
<Mithrandir> Whoopie: unsure.  I think I filed one, but it's ages ago
<doko> iwj: Dependency is not satisfiable: c++abi2-dev  -> dependency on a virtual package; do you want to have this fixed for gutsy?
<slangasek> evand: "for a certain user type" - what type is that? :)
<slangasek> evand: perhaps this can be written as: "For experienced Linux enthusiasts, Gobuntu will act as the test bed for developing a user-friendly operating system with no compromise in terms of the open source philosophy."?
<evand> wfm
<pitti> tkamppeter: did you see Mike's response to http://www.cups.org/str.php?L2557 ?
<ubotu> CUPS bug 2557 in Core CUPS Software "CUPS daemon is not set to listen on port 631 in the whole network when user wants CUPS to show printers" [Priority moderate,Closed w/o resolution] 
<pitti> tkamppeter: I think I'll reject the cupsys upload for now
<iwj> doko: No, I think we should punt on those.
<iwj> doko: There's also automaken and err at least one other.
<iwj> doko: I don't want to just update all of the packages to say `automake1.9' or whatever because that's making a rod for our own back.
<doko> ok
<slangasek> evand: just to make sure I understand this the right way around: does gobuntu include artwork for usplash?
<iwj> doko: We really want a coherent way of centrally determining the correct thing to use.
<doko> iwj: ok, setting these to confirmed.
<evand> slangasek: yes, but it's currently not working on i386
<evand> it worked last I checked (last night) on amd64
<iwj> doko: Thanks.
<iwj> doko: Thanks for your help btw :-).
<evand> the usplash artwork, that is
<slangasek> evand: ok; just wanted to make sure that the "and" in that sentence wasn't meant as an "or"
<Amaranth> does gobuntu have the patched kernel and such that gnusense has?
<doko> iwj: heh, just while doing test installs ...
<evand> Amaranth: it's just ubuntu - restricted at the moment
<Amaranth> ah
<iwj> doko: Lucky you.  Whenever I do test installs I spend the whole day writing bug reports :-).
<evand> but the goal is to get the restricted bits of the kernel into restricted
<evand> much has already been done there, iirc
<Amaranth> i know ompaul told me gnusense had a bunch of files patches out of the kernel because they were basically closed firmware pretending to be code
<Amaranth> patched*
<iwj> Not that I _mind_ writing bug reports but it doesn't leave much time for thinking about coding too.
<evand> Amaranth: I do recall that as well, but I *believe* there may have been some false positives there as well.
<doko> well, it's just two dvds I'm currently testing
<pitti> lool: re bug 116990: wouldn't it be safer to reduce the default volume to 90% to avoid the clipping?
<ubotu> Launchpad bug 116990 in rhythmbox "Rhythmbox sound problems (clicking/snapping/crackling) when not using crossfading backend" [High,In progress]  https://launchpad.net/bugs/116990
<pitti> lool: that helps on my machine, the machine of a friend of mine, etc.
<sladen> who the hello made these themes, the progress bar overlaps the text area, so gets scrolled up
<evand> which themes?
<doko> asac: how do I fix this "unknown network interface "eth0=eth0" thing?
<sladen> okay, nailed the edubuntu off-centered ness
<sladen> did somebody say it's still there on xubuntu?
<geser> pitti: is the list of packages which aren't build on a architecture available somewhere?
<cjwatson> Amaranth: Gobuntu shares the same archive, so it's unlikely to be practical to make that kind of invasive kernel change; packages that need bits removed for them for Gobuntu need to be split up
<cjwatson> Amaranth: (which should hopefully mean there's a little more quality control on what gets removed, since it's more effort)
<sladen> ubuntu has overlapping text box too?
<lool> pitti: Yes, some submitter confirmed that reducing the sound level work, on the other hand you don't want people to get crackling sound when they pump up the volume :)
<lool> pitti: Also, all workarounds so far only hide the real problem which seems to be alsa related (we should build an alsa test suite or an utility that people can run to test the sound output at various sample sizes)
<lool> pitti: So I'm not sure of the benefits we would get from lowering the default volume instead of forcing a 16bits sample size
<sladen> pitti: how much churn do you want, several of the themes have text-box areas that overlap with the progress-bar region.  Hence the progress-bar will get "scrolled" during integrity check or verbose boot
<sladen> pitti: (I'd prefer not to fix it, since it's not the common-case)
<tkamppeter> pitti, so bug 151510 is perhaps a false alarm? Or can it be that the behaviour is caused by AppArmor and opening the tCP port surrounds the problem?
<ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
<bdmurray> I think people do use the check cd boot off the CD a fair bit and it is something we ask reporters to do as a part of the triaging process.
<lool> pitti: I'm adding an alsa test case to the bug report
<lool> Did someone get hangs during the gutsy install under virtualbox?
<lool> Mine hung at "Detecting file systems" (15%) and is stuck since an hour or so
<crbrocket> #ubuntu-server
<crbrocket> oops sorry
<Pici> tsk tsk
<sladen> lool: report in launchpad
<sladen> lool: the question is not whether anyone else got hangs.  If *you* got hangs, then that is a bug
<sladen> bdmurray: noted;  in that case we might want to consider fixing the text-box overlap for the others themes aswell
<sladen> bdmurray: can you make that point in the bug report if you want me to 'sell' it to pitti
<lool> sladen: I diagnosed it a little, and it's specific to xfs
<lool> Err reiserfs, sorry
<sladen> lool: just. say. no.
<sladen> lool: anyone who runs it should be locked up
<sladen> lool: however, sadly, that doesn't mean it's not still a bug
* popey looks at his reiserfs usb disk
* elmo looks at popey
* popey wonders why the hell he did that
<popey> it's 750G of madness in a box
<mertiki> Riddell : The libqt3-mt package doesn't create config files in the /etc/qt3 folder. This result in ugly huge fonts. When applying the debdiff, the package now create the config files
<mertiki> Riddell : adding "/etc" in the libqt3-mt.install file in the source package fix the problem in that way. The problem seems to be just about missing config files in /etc/qt3 folder as you can read in the bug report
<lool> If anyone succeeded or failed with reiserfs in another environment than virtualbox, would be nice to comment in
<lool> bug #151670
<ubotu> Launchpad bug 151670 in partman-partitioning "Crashes when creating reiserfs filesystem" [High,New]  https://launchpad.net/bugs/151670
<gnomefreak> have we released RC yet?
<lool> Don't think so
<gnomefreak> i didnt either but the http://releases.ubuntu.com/releases/7.10/ looks like it
<mertiki> Riddell : You can look by yourself by installing the actual libqt3-mt package and use Qt3 programs like hplip or virtualbox, the fonts will be huge. The /etc/qt3 folder has too restrictive permissions and doesn't contain the config file "qtrc".
<slangasek> gnomefreak: it's en route
<gnomefreak> slangasek: ty
<jpatrick> mertiki: Riddell's out for tonight (last time I saw), so it may take a while to respond
<mertiki> jpatrick : thanks
<gnomefreak> slangasek: u.d.a ML will have it right? so i know when to add it to /topic in #ubuntu+1
<slangasek> by u.d.a you mean ubuntu-devel-announce?
<gnomefreak> yes
<slangasek> the announcement actually goes to ubuntu-announce
<gnomefreak> ah ok
<gnomefreak> i think im there too if not i will be :)
<pochu> slangasek: re: liferea - thekorn and I have tested it, and it works fine (I've been running it for ~ 8 hours). Ok to upload so you can review it?
<slangasek> pochu: yes
<davmor2> bryce: ping
<pochu> Any core-dev around to upload liferea for me? Please please :-) ---> http://emilio.pozuelo.org/~deb/
<pwnguin> liferea fix?
<pwnguin> i hope it fixes google search rss's
<pochu> pwnguin: what's up with that?
<pitti> tkamppeter_: no, apparmor doesn't control network connections
<pitti> geser: list of non-built packages> yes, http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_outdate.txt
<pitti> sladen: hm, hard to say without seeing a patch; but I trust your common sense to decide about intrusiveness :)
<pitti> tkamppeter_: I didn't reproduce it yet, since I don't have remote printers ATM; I could fake some on my laptop, of course
<geser> pitti: I'm trying to find out why imaze doesn't get build on amd64
<geser> pitti: I guess it's listed in P-a-s
<pitti> geser: yeah, probably
<geser> pitti: is P-a-s visible somewhere for mere mortals?
<pitti> geser: not on people.u.c. apparently; let me check
<pwnguin> pochu: https://answers.edge.launchpad.net/ubuntu/+question/14715
<Mithrandir> geser: http://cvs.debian.org/srcdep/Packages-arch-specific?root=dak&view=markup
<pitti> geser: imaze-xview: !ia64 !amd64
<geser> Mithrandir: does the Ubuntu buildds use the same list as Debian?
<pitti> geser: that's the only one
<geser> pitti: thanks
<pitti> geser: yes
<Mithrandir> geser: yes
<Mithrandir> as you can see, lpia is in that list.  lpia doesn't exist in Debian.
<sladen> pitti: http://www.paul.sladen.org/ubuntu/upload/edubuntu-artwork-usplash_0.1.0-52sladen1.debdiff  etc
<pitti> sladen: yay hardcoded values :)
<geser> Mithrandir: if I understand the P-a-s list correctly, it's lists binary packages (unless prefixed with %). What happens when one binary from a multi-binary package is listed there?
<geser> does it get build on that arch at all?
<pochu> pwnguin: looks like *that* search doesn't have any results... and that's why it doesn't have any items ;) Try this one, for example: http://video.google.com/videofeed?type=search&q=linux&so=0&num=20&output=rss
<tkamppeter_> pitti, I am downdating CUPS now to the unpatched version and try to reproduce the bug 151510 ...
<ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
<pitti> tkamppeter_: thanks
<pwnguin> pochu: i promise it has results
<smurf> Any good idea what to do about bug 126499? "Some machines with RAID will not boot after upgrading to gutsy" is something we might want to avoid ...
<ubotu> Launchpad bug 126499 in mdadm ""No devices listed in conf file were found" due to mdadm RAID1 array UUID different from actual UUID reported by vol_id" [Undecided,New]  https://launchpad.net/bugs/126499
<pwnguin> pochu: it's derived from http://video.google.com/videosearch?q=label%3AengEDU . mozilla has an rss icon in the url box, and renders the listings decently
<Keybuk> how embarassing
<Keybuk> I was doing an upgrade chain run in vmware
<Keybuk> and forgot how far I'd got
<Keybuk> I had to check About Ubuntu to see which release it had been upgraded to :-)
<tkamppeter_> pitti, I have retested now and it works correctly also with the old version. So kagou's and my observations on bug 151510 are a bad coincidence.
<ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
<pitti> tkamppeter: ah, good; so rejecting the cups upload was warranted
<Keybuk> ENOMVO :-(
<tkamppeter> pitti, CUPS is indeed listening to the broadcasts, even with "Listen localhost:631".
<pitti> tkamppeter: *phew* that relieves me somewhat
<tkamppeter> pitti, seems that I can mark bug 151510 invalid
<ubotu> Launchpad bug 151510 in cupsys "IPP Printers shared are not automatically shown" [Medium,New]  https://launchpad.net/bugs/151510
<tkamppeter> And perhaps report an upstream bug on documentation. Somehow it must be told to the user that the Listen/Port directives do not need to be opened only for capturing broadcasts.
<pitti> tkamppeter: so I wonder what kagou's problem was then
<Kopfgeldjaeger> n8
<pitti> doko: bug 91848 ack'ed
<ubotu> Launchpad bug 91848 in subversion "segfault when importing libsvn.wc in python 2.4 on feisty/amd64" [Medium,In progress]  https://launchpad.net/bugs/91848
<tkamppeter> pitti. I am wondering, too. Both config files look OK for me.
<stgraber> mathiaz: postgresql and mail server testcases are now on the tracker
<mathiaz> stgraber: thanks !
<pochu> pwnguin: I see, I'll report it upstream.
<pwnguin> pochu: thanks
<pochu> pwnguin: http://sourceforge.net/tracker/index.php?func=detail&aid=1811856&group_id=87005&atid=581684 , in case you want to follow up.
<ubotu> Gaim bug 1811856 "Liferea doesn&#039;t properly work with google search feeds" [Pri: 5,Open] 
<pochu> Gaim?
* pochu rofl
<pwnguin> what?
<pochu> the bug report ^ look at the link
<pwnguin> oh, it probably decided sf was the gaim bugtracker
<pwnguin> instead of 50 billion project's bugtracker
<pochu> hehe, right.
<pwnguin> im not sure what i'd follow up on that bug report
<pwnguin> does LP track sf?
<pochu> Not yet, although you can link a bug report to it.
<pochu> But the status isn't scanned.
<calc> slangasek: wanted to double check that lifrea-1.4.4-0ubuntu2 that pochu has prepared is ok for upload by you, he mentioned he got your approval
<calc> slangasek: i was going to sponsor the upload if it is ok
<slangasek> calc: even if he hadn't, there's nothing that prohibits uploading
<calc> slangasek: ok :)
<calc> pochu: i'll upload it once my current transfer is done, it will probably be 20-30m
<pochu> calc: sure, ty :)
* ..[topic/#ubuntu-devel:slangasek] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy release freeze in effect | Gutsy RC released, please test
<pitti> \o/ RC
<pitti> congrats, everyone
<ion_> Ditto
* seb128 hugs pitti
* mathiaz hugs pitti
#ubuntu-devel 2007-10-12
<jojo4u> ... well the release candidate is on cdimage/release.ubuntu now. but no reference on the main page or devel-announce or the wiki. is this intentional? just wondering. gratulations btw, my first test was very positive, no bugs to report ;)
<TheMuso_> jojo4u: It was announced on ubuntu-announce
<slangasek> also, what "main page" are you referring to?
<jojo4u> http://www.ubuntu.com/testing/gutsybeta
<slangasek> that's hardly a main page, that's a page specific to the beta. :)
<jojo4u> http://www.ubuntu.com/ -> the countdown links to it
<slangasek> ah, so it does
<mathiaz> slangasek: it links to beta. Is there a place on ubuntu.com for rc ?
<slangasek> mathiaz: http://www.ubuntu.com/testing/710rc, referenced from the announce mail
<mathiaz> slangasek: may be the countdown link should point to http://www.ubuntu.com/testing/710rc ?
<slangasek> um, quite
<slangasek> I just didn't know that link was there until it was pointed out
<slangasek> I've pinged the webmaster
<jojo4u> thnx, just spottet the "latest news". there are many ways to rome I guess
<asac> doko_: please give me more details :)
<tonyyarusso> I just wanted to offer a thought for consideration after installing the Gutsy RC.  I was able to enable desktop effects, which was nifty, but there was no way to configure them.
<tonyyarusso> Someone in #ubuntu+1 informed me that I needed to install compizconfig-settings-manager.  While I understand not having this installed by default, I would propose including a button on the same display screen with the radio buttons for enabling effects for easily installing it, rather than having to ask on IRC.
<tonyyarusso> btw, I installed by upgraded from Feisty, and it was flawless, so that's nice.
<tonyyarusso> I would place the button exactly in the spot that the "Preferences" button appears after installing that package.
<tonyyarusso> Is there anyone awake who could field a feature request for Gutsy?  (super-easy to implement; would make things a bit easier, relating to desktop effects)
<Burgundavia> tonyyarusso: kind of late for that kind of thing
<tonyyarusso> Burgundavia: Yes, I know.  But as requested, I installed the RC and am finding bugs ;)
<tonyyarusso> Or at least, I'd consider it a bug.
<tonyyarusso> Burgundavia: any idea who's in charge of gnome desktop effects related stuff?
<Burgundavia> sebastian, I think
<tonyyarusso> ok
<tonyyarusso> Burgundavia: aww crud.  The thing I wanted to do would require promoting something from universe to main.  Definitely too late for that.
<tonyyarusso> I'll add it to my Hardy wishlist I guess.
<Burgundavia> yep, that is likely too late for that
<tonyyarusso> :(
<tonyyarusso> Burgundavia: my complaint is that there is no way to configure stuff other than gconf-editor yet.  compizconfig-settings-manager looks _really_ nice, so I was hoping there would be an easy way to install it with a button next to the dialog for enabling compiz in the first place, but oh well.
<Burgundavia> ahh
<Burgundavia> yes, that is definitely hardy stuff
<ajmitch> there were some proposals of how to do that
<RAOF> tonyyarusso: Do you really think that compizconfig-settings-manager looks *nice*? :)
<tonyyarusso> RAOF: yeah, it got the job done pretty effectively for me.  Why?
<RAOF> tonyyarusso: It just seems like a horrible hodge-podge of settings to me.  You need to crawl around to find anything, it's not obvious where you should find stuff...
<tonyyarusso> ajmitch: My thought was to put a button on the screen (in the same position as the "Preferences" one appears after installing ccsm) for adding it, which would jump to the package manager stuff.
<RAOF> The settings themselves aren't obvious...
<tonyyarusso> RAOF: They're leaps and bounds better than gconf keys, as well as having no settings options whatsoever.
<RAOF> I mean, it's a large step up from gconf-editor, sure, but it's not actally very nicj :)
<frostburn> the settings manager used to be absolutely horrible, tabs and scrolling eww
<frostburn> and scrolling through tabs
<tonyyarusso> RAOF: Well, I wouldn't mind if someone wanted to put more UI work into it, but I also wouldn't complain personally as is.
<frostburn> tonyyarusso, you sound like a happy volunteer!
<tonyyarusso> frostburn: Hehe.  I'd be happy to poke around and give feedback and whatnot, but unfortunately I don't code (yet at least)
<tonyyarusso> Starting to read diveintopython though.
<Alpha_Cluster> Is there anyone around that would be willing to look into what should be a easy to solve bug in "Screen and Graphics"?
<tepsipakki> nice, our ubuntu-mirror (HP 380G5, dapper) crashes under load
<dholbach> good morning
<mdke> morning dholbach
<dholbach> hey mdke
<mdke> dholbach: thanks for your comment on my blog; what's actually the difference between ubuntu-dev and ubuntu-motu?
<dholbach> mdke: ubuntu-dev is not used any more afaik, motu is
<mdke> dholbach: would it be a good idea to make that clear on the ubuntu-dev team page?
<mdke> it's not used at all?
<dholbach> I don't think it is
<mdke> it should be retired then I guess
<dholbach> yeah, although it isn't exactly easy to retire a team in LP
<dholbach> at least a note would be good
<LaserJock> ubuntu-dev is used
<dholbach> for what?
<LaserJock> it's just not used for people
<LaserJock> ~ubuntu-dev = all Ubuntu developers
<dholbach> oh ok
<LaserJock> it's ~motu + ~ubuntu-core-dev
<mdke> LaserJock: in that case, it should be an umbrella team containing only ~motu and ~core-dev, rather than including individuals...
<LaserJock> mdke: that's what it is
<mdke> no, it has loads of individuals as direct members too
<\sh> good morning
<LaserJock> but Mark said that to transition we'd let the existing people expire out
<LaserJock> rather than explicitly deactivating them
<LaserJock> of course it's times like this that makes that confusing ;-)
<mdke> expiring out will take until like 2009!
<LaserJock> something like that yeah
<LaserJock> 2 years from the last person
<mdke> is it actually used by soyuz?
<LaserJock> not by soyuz
<LaserJock> it's just helpful when we're dealing with Ubuntu developers as a whole
<LaserJock> like if people want to have a bzr branch that everybody can work on
<mdke> right. removing the individuals sounds sensible to me
<LaserJock> probably, I guess we weren't thinking it'd cause problems when the decision was made
<LaserJock> I don't know, talk to the boss ;-)
<LaserJock> I'm pretty sure everybody's been moved around so that ~motu == MOTU
<\sh> ha...I just found my birthday present...http://scr3.golem.de/?d=0710/Sharp_KarminTV&a=55334&s=2
<mdke> dholbach: anyway, I've updated the text, thanks :)
<mdke> LaserJock: thanks for the explanation
<dholbach> mdke: thanks
<dholbach> doko_: can you take a look at bug 151677?
<ubotu> Launchpad bug 151677 in bash "Support purge in apt-get auto completion" [Undecided,New]  https://launchpad.net/bugs/151677
<dholbach> soren: I subscribed you to bug 151650
<ubotu> Launchpad bug 151650 in dovecot "dovecot is not restarted when remove dovecot-pop3d or dovecot-imapd" [Medium,In progress]  https://launchpad.net/bugs/151650
<dholbach> slangasek, bryce: do you know if bug 148231 was the xresprobe upload that got accepted yesterday?
<ubotu> Launchpad bug 148231 in xresprobe "[gutsy]  bad modes in xorg.conf" [High,Triaged]  https://launchpad.net/bugs/148231
<dholbach> calc: bug 135086?
<ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
<mdke> dholbach: I'd quite like to do another ubuntu-docs upload, who do I need to talk to about requesting that?
<doko> dholbach: keep cool, just released RC ... ;p
<dholbach> mdke: slangasek, pitti, Riddell, hobbsee, Mithrandir, cjwatson
<dholbach> doko: I *am* cool ;-)
<dholbach> hiya sabdfl
<sabdfl> howdy folks, dholbach
* StevenK waves to sabdfl 
<dholbach> heya seb128
<seb128> hey dholbach
<mdke> hello Hobbsee
<Hobbsee> hiya mdke, StevenK, dholbach, seb128 and sabdfl
<mdke> Hobbsee: I'd quite like to upload a new version of ubuntu-docs to fix a broken link on one of the help pages, bug 144796, it's a pretty straightforward text-only change to the package; is that going to be doable?
<ubotu> Launchpad bug 144796 in ubuntu-docs ""Glossary of Windows terms" link doesn't work" [Medium,Confirmed]  https://launchpad.net/bugs/144796
<seb128> hey Hobbsee
<mdke> Hobbsee: if it sounds possible, I'll put up a debdiff
<sabdfl> howdy Hobbsee
<Hobbsee> erk, there's a fire!  so much red!
<Hobbsee> mdke: looking
<mdke> thanks
<Hobbsee> mdke: should be fine, but you'll have to find someone else to do the actual accepting.  sabdfl may be able to shove it thru once you've uploaded it.
<Hobbsee> mdke: or various other people that i've learned are useful for this :)
<mdke> Hobbsee: no rush from my end, no need to bother him. I'll need someone to do the uploading too :)
<Hobbsee> mdke: ah, ok, throw up a debdiff, and i can upload it from here
<Hobbsee> ah, then pitti can accept it
<Hobbsee> morning pitti!
* Hobbsee hugs pitti
<StevenK> Morning pitti
* mdke nods, pitti is the hero
<Hobbsee> assuming my internet doenst go bung, of coruse.
<LaserJock> pitti pitti he's our man, if he can't do it slangasek can!
<pitti> Good morning
<Hobbsee> LaserJock: pitti can always do it.
* pitti hugs Hobbsee and mdke 
<pitti> hey LaserJock
* mdke hugs *
<pitti> wow, what a warm welcome
* LaserJock bows to pitti
<Hobbsee> pitti: :)
<LaserJock> that reminds me, I was going to write a blog post about pitti
<Hobbsee> as long as you dont write a blog post about me :P
<pitti> LaserJock: eww, don't blame me so publicly :)
<Hobbsee> but, if you do, be sure to include a decent name that i can string into my alias.
<LaserJock> heh
<pitti> LaserJock: http://dailyrevolution.net/?p=779 BTW :)
<LaserJock> Hobbsee: you still owe me ;-)
<Hobbsee> LaserJock: oh do i now?
<StevenK> pitti: Got a sec to glance at a debdiff for virtualbox-ose-modules?
<pitti> Hobbsee: so, what shall I accept?
<pitti> StevenK: sure
* pitti purges some stuff from unapproved
<Hobbsee> pitti: the ubuntu-docs upload, after it actually gets uploaded.
<Hobbsee> pitti: tbh, i'm surprise you let me accept stuff at all :)
<StevenK> pitti: http://launchpadlibrarian.net/9945255/virtualbox-ose-modules_3.dsc.diff
<StevenK> pitti: I didn't write the debdiff, but I want a second opinion
<LaserJock> pitti: haha, that's great
<Hobbsee> pitti: haha, nice
<Hobbsee> guten morgen mvo!
<pitti> hey mvo
<Hobbsee> LaserJock: i can just keep ignoring the request.
<LaserJock> you can run ... but you can't hide from ... LaserMan!!!!
<mvo> hey Hobbsee pitti!
<StevenK> Bah, Canonical isn't based in Montreal
<pitti> StevenK: eww, doesn't that mean that the modules will silently break on upgrades, instead of being made obvious with a package conflict?
<StevenK> pitti: Yes, that's my thought too
<pitti> StevenK: ah, you still install them under /lib/modules/<version>, so they won't break
<StevenK> pitti: Makes it harder to see at a glance "Oh, it's broken due to ABI bump"
<pitti> but still, there's a reason we do it for the main kernel and lum
<pitti> StevenK: frankly, I'd rather discuss that with the kernel team, but this smells at least inconsistent, if not even bad
<pitti> StevenK: well, depmod & friends are fine of course
<StevenK> pitti: To my mind, the kernel team have signed off on the current approach
<dholbach> hi pitti
<StevenK> pitti: And you've voiced concerns as well, so my way stays and Daniel's debdiff gets left out.
<pitti> StevenK: when we reduce it to the postinsts, it looks good
<ajmitch> hi :)
<slangasek> dholbach: yes, 148231 is the xresprobe bug that was fixed
<StevenK> pitti: I have postinsts already - it calls depmod -A
<dholbach> slangasek: I'll mark fix released
<StevenK> pitti: I'm happy to show you a debdiff between 2 and 3 if you want to see it.
<pitti> StevenK: ah, good
<StevenK> Well, 2 doesn't have postinsts, but 3 will
<StevenK> Actually, I'm curious if debian/postinst will work for all binary packages.
<slangasek> dholbach: you might want to mark it as a duplicate of the other bug?
<dholbach> slangasek: which? can you do that? I just wanted to get it off the sponsoring list as it doesn't need sponsoring any more
<sabdfl> Hobbsee: now would not be a good time for me to be shoving anything through ;-)
<sabdfl> best to ask slangasek or other RC-specialists
<Hobbsee> sabdfl: depends if you have a member of the release team's permission, no?
<Hobbsee> sabdfl: as in, the story is slightly different if a release team member is asking you to do the manual work in accepting an upload, no?
<LaserJock> Hobbsee: you ever heard of advisor knobs?
<LaserJock> *hear
<sabdfl> i'd rather not be trying something i've never done before, 6 days before a release ;-)
<Hobbsee> LaserJock: advisor knobs?
<cjwatson> LaserJock: err, ubuntu-dev *is* used by Soyuz; it's the team permitted to upload to universe+multiverse
<Hobbsee> sabdfl: ah, i thought you'd done it before :P
<sabdfl> nup
<LaserJock> cjwatson: hmm, perhaps yes. I thought that'd changed, but that would mean that core-devs couldn't upload to Universe
<cjwatson> I suspect sabdfl would have to get a drescher account first
<cjwatson> not that that would be hard by policy, but it would have to happen :)
<Hobbsee> oh indeed.
<Hobbsee> i'm thinking that the policy could easily be bent for the boss, if required :P
* Hobbsee thought he had an account regardless, for some reason
<cjwatson> (actually, hmm, the Soyuz UI would be up to letting an LP admin accept changes now as long as they didn't require overrides ...)
<Hobbsee> cjwatson: NEAT!!!
<liw> what's this? six days before release? oh dear, I'm going to have to spend the entire weekend if I want to finish my kernel rewrite in Python
<pwnguin> whats the point of an RC if you cant fix bugs?
<LaserJock> Hobbsee: grad students put "advisor knobs" on the instruments, so that when the advisor comes down to the lab they have something to turn
<pwnguin> hah
<Hobbsee> LaserJock: ah right, yes.
<LaserJock> Hobbsee: of course the knobs don't go to anything ;-)
<StevenK> Like a "boss screen" for games
<Hobbsee> LaserJock: in sound engineering, we do that by tweaking knobs on an unused channel, or unused aux
<Hobbsee> works a charm
<Hobbsee> "Yes, i do know what every knob on this desk does"
<liw> LaserJock, I've heard DJs have that for people who come complaining about too much/little bass/tremble
<Hobbsee> liw: unused channel.  yep.
<pwnguin> LaserJock: is the knob for the advisor or the student to turn?
<sladen> we could let sabdfl move the position of the progress bar back and forwards---then that's only one step away from turning it into a game of pong
<LaserJock> pwnguin: advisor
<LaserJock> so they think they're helping without screwing up the students experiment
<kagou> pitti, Hi,  i point you a apparmor bug (seems to be) Bug #151190
<ubotu> Launchpad bug 151190 in cups-pdf "cups-pdf fails for non-standard home directories" [Undecided,Incomplete]  https://launchpad.net/bugs/151190
<liw> if sabdfl has too much free time, I have a few QA things in mind he could spend it on... :)
<slangasek> dholbach: oh... n/m, that's the only bug and it just wasn't closed properly in the changelog I guess.  so yeah, please mark it as fix released
<dholbach> slangasek: done
<StevenK> Oh come on debhelper, you really want to install debian/postinst in *both* packages...
<pitti> kagou: well, that doesn't sound quite like a bug, much more proves that AA works :)
<Hobbsee> pwnguin: large amounts of bikeshedding.  duh.
<Hobbsee> slangasek: as per our conversations yesterday, and your desired wish not to be impaled, you're going to email u-d/u-m about the impending hard freeze today, i take it?
<sladen> well the desktop is /a bit/ dark this time, what colour should it be?
<kagou> pitti, you can see like that :)
<slangasek> Hobbsee: for values of "today" that include "after I actually make it to my bed and catch a few hours of sleep", yes
<cjwatson> mvo: I'm not happy about this ubiquity patch to remove forked implementations of apt progress helper functions at this point in the cycle. Could you please describe exactly what the problems were that weren't fixed in the forks?
<Hobbsee> slangasek: yes, of course :)
<Hobbsee> slangasek: today being any value of friday, in any timezone, that you choose.
<slangasek> heh
<mvo> cjwatson: my idea with the patch was that the mythbuntu folks use it, I don't think it should go into our CDs at this point
<mvo> cjwatson: that should read "that only they use it"
<cjwatson> mvo: ok. but if there's a real problem it's fixing, I'm interested in that too - however the patch is demonstrably buggy in at least one respect, since ubiquity's run() implementation expects updateInterface() to return boolean
* Hobbsee stabs stupid people
<Hobbsee> dholbach: do you want the honours?
<Hobbsee> oh, you got it
<StevenK> Hobbsee: That's a lot of people to stab.
* StevenK hides
<pwnguin> you better hide
<Hobbsee> StevenK: indeed.  but they might stay out of my workplace then though
<dholbach> Hobbsee: hm?
<pwnguin> theres someone with a knife after you!
<Hobbsee> dholbach: nutters_who_decide_to_assign_to_ubuntu_dev++
<dholbach> ah right
<Hobbsee> pwnguin: there are often people after me.  they've not suceeded yet.
<pwnguin> excuse me
<Hobbsee> although not with knives, i'll admit.  i'm probably nto very good to chop up.
<Hobbsee> :)
<pwnguin> StevenK: you better hide, someone with a knife is after you!
<mvo> cjwatson: ok, give me some minutes to look at it again in detail
<mvo> cjwatson, evand: we should try to have a hack session about the python-apt inside ubiquity and what can be done to make it easier for you and to remove the workaround that accumulated over time and are either fixed in python-apt or really need to be fixed there :)
<cjwatson> mvo: agreed
<seb128> ogra: what happened to the other gnome-power-manager fix you wanted to upload?
<asisak> Is it still possible to upload bug fixes to universe and get them into gutsy during the weekend?
<asisak> Bug 144175 renders Tilda almost unusable.
<ubotu> Launchpad bug 144175 in tilda "tilda stays like a gray window" [Medium,Fix committed]  https://launchpad.net/bugs/144175
<cjwatson> asisak: during the weekend yes, but you should get code review
<cjwatson> after the weekend it will get dubious
<asisak> What do you mean by code review?
<pwnguin> people read the diff
<asisak> Okay, but should I ask that here after I am ready? Or how?
* Starting logfile irclogs/ubuntu-devel.log
<gnomefreak> seems that on apt-cache search jigdo-lite brings up 2 packages jigdo-lite and  jigdo but when you go to install it says package not found. brb trying to get a bug on it
<pitti> seb128: btw, since my last reinstall (fresh RC), I get the blue Gnome session splash instead of the brown one; this can't be right?
<seb128> pitti: blame the artwork guys, I think they dropped the Ubuntu splash
<pitti> ENOKWWII
<seb128> pitti: since we don't use splash by default on gutsy
<fabbione> slomo: ping?
<pitti> hm, so why do I get it?
<seb128> pitti: that's a new install? no idea
<pitti> seb128: with my existing home directory, of course
<pitti> seb128: but before the reinstall I had the normal brown splash
<seb128> pitti: so that's probably a local gconf config
<Chipzz> Mithrandir: partial reverse DNS delegation works with CNAME/PTR's
<Mithrandir> Chipzz: there's no need to tell me how DNS works, I know DNS quite well
<Chipzz> Mithrandir: you can't delegate reverse DNS for a subnet smaller than /24 without CNAME's
<seb128> pitti: gconftool-2 --get /apps/gnome-session/options/show_splash_screen ?
<pitti> true
<Riddell> pitti: my internet is dodgey today, sorry for the delay
<Chipzz> Mithrandir: ah sorry in that case L(
<Mithrandir> Chipzz: assuming IPv4 and not assuming very evil hacks, true.
<Chipzz> :)
<seb128> pitti: likely an user config change
<pitti> seb128: thanks, I unset it
<seb128> pitti: that's still a bug though, we are breaking existant config by not shipping the image
<Riddell> pitti: the only changes in arts are things which older versions had in patches and autoconf randomness
<pitti> mdke, dholbach: I have a pending OO.o upload which changes the .desktop file Names to the ones in Feisty (e. g. Base -> Database, Impress -> Presentation); that breaks UI, so what's your opinion about it?
<pitti> Riddell: ok, accepting then
<seb128> pitti: the splash was in feisty-session-splashes
<pitti> seb128: right; I don't remember setting it explicitly
<dholbach> pitti: best to mail mdke about it
<gnomefreak> mvo: bug 151905 might fit in with you but im not real sure if anyone wants to take a look feel free
<ubotu> Launchpad bug 151905 in ubuntu "jigdo - archive mirror error - missing 37 files" [Undecided,Confirmed]  https://launchpad.net/bugs/151905
<dholbach> pitti: he's at work
<pitti> ok
<dholbach> pitti: I don't know much about it
<seb128> pitti: dholbach did that change
<seb128>  ubuntu-artwork (38) gutsy; urgency=low
<seb128>  .
<seb128>    * debian/control: don't depends on feisty-session-splashes, we don't show
<seb128>      the splash screen any more.
<pitti> ah, it's all dholbach's fault :)
<seb128> indeed ;)
* seb128 hugs dholbach
<pitti> maybe we should revert that; it's only 80 kB
<dholbach> on a call right now
<pitti> and fix it propely in hardy
<seb128> right
<pitti> mvo: can you please update the status of 120957? it is verification-done, but has New/Invalid tasks
<ogra> seb128, /etc/gdm/gdm.conf has SuspendCommand=/usr/sbin/pmi action sleep (here at least) ... that should be SuspendCommand=/usr/sbin/pmi action suspend (else you end up with two standby entries in the gdm menu apparently )
<mvo> pitti: checking
<ogra> seb128, gdm fix uploaded btw
<pitti> mvo: vmware-kernel-modules is gone from gutsy; do you think I should remove vmware-player, too, since it's uninstallable anyway?
<seb128> ogra: "standy"?
<ogra> err
<ogra> gpm
<ogra> seb128, standby
<seb128> ogra: right, what do you mean?
<seb128> you have 2 suspend menu items?
<mvo> pitti: do we sitll have it in the archive? if not, it will get removed in the "remove obsoletes" stage
<ogra> seb128, yeah, in the gdm menu
<seb128> ogra: weird, the wrong comment should not create an extra item
<pitti> mvo: vmware-player source adn binaries are, but they are unisntallable since edgy (since we only had the 2.6.15 modules)
<seb128> ogra: the action should just not work
<mvo> pitti: we have it so that people can use vmware-player-kernel-modules and build their own?
<ogra> seb128, i had a bug report about a missing icon in the menu ... it turns out i have two standby items, one witout icon, it changes if i change to the value "pmi capabilities" returns for me
<pitti> mvo: ok *shrug*
<ogra> which is hibernate and suspend (not sleep)
<pitti> mvo: if we had a source package which would build the kernel modules, that would make sens
<pitti> e
<seb128> ogra: what happens if you change gdm.conf to have suspend correctly?
<ogra> the second item goes away
<seb128> weird, I've only one item here, will fix it anyway
<ogra> i'll do so accordingly in edubuntu-artwork ...
<ogra> who cares for xubuntu nowadays ?
<seb128> not sure, the xubuntu team seems not really active at the moment
<ogra> yeah, i noticed that during RC testing
<mvo> pitti: if we don't have one, then shouldn't vmware-player be removed from the archive?
<pitti> mvo: that's what I was asking you about :)
<mvo> pitti: I always thought that there is one in the archive :) in this case we should get rid of it I think
<mvo> pitti: let me check with fabbio (the new 3rd party master)
<pitti> thanks
<mvo> pitti: thank YOU (and sorry that I'm a bit slow today)
<pitti> mvo: understandable after the RC pressure *hug*; thanks
<cjwatson> gnomefreak: your confirmation is hardly a confirmation; you need to install jigdo-file, not jigdo-lite ... but in any case I've duplicated the bug
<Chipzz> seb128: btw, I noticed in a recent upgrade that gdm.conf dropped the -br argument to the X server; is that intentional?
<seb128> Chipzz: how recent?
<cjwatson> gnomefreak: I think you misread jigdo-file as jigdo-lite in the apt-cache search output
<Chipzz> lemme check
<seb128> Chipzz:
<seb128> $ grep "/usr/bin/X " /etc/gdm/gdm.conf
<seb128> command=/usr/bin/X -br -audit 0
<seb128> command=/usr/bin/X -br -audit 0 -terminate
<seb128> command=/usr/bin/X -br -audit 0
<Chipzz> seb128: just did dpkg-deb -x of gdm_2.20.0-0ubuntu3_i386.deb
<Chipzz> StandardXServer=/usr/bin/X
<seb128> Chipzz: do you actually see the grid?
<Chipzz> I noticed this when cleaning up *.dpkg-* cruft in /etc
<Chipzz> seb128: no
<seb128> "[server-Standard] 
<seb128> name=Standard server
<seb128> command=/usr/bin/X -br -audit 0
<seb128> "
<seb128> it should use that
<Chipzz> uhu
<Chipzz> StandardXServer is a fallback
<seb128> right
<Chipzz> but shouldn't that use -br too?
<seb128> no opinion on that, maybe
<seb128> I didn't try if adding arguments to the server name works
<seb128> doesn't look important enough to be changed now
<Chipzz> ok, understandable :)
<Chipzz> just wanted to notify you about it ;)
<seb128> thanks
<iwj> seb128: Would you mind renewing my ubuntu-main-sponsors membership ?
<seb128> iwj: I've changed it to not expire now
<seb128> not sure why it had an expiration date before
<iwj> seb128: Thanks.  Why knows.
<iwj> doko: I see dict-en-za has ftbfs in autopkgtest (haven't checked the buildd).
<iwj> doko: Did you want me to deal ?
<doko> iwj: it's still at "needs building" https://edge.launchpad.net/ubuntu/+source/dict-en-za/20070206-2
<iwj> doko: Oh, actually, the version numbers are wrong.
<iwj> doko: Hmm.  That's unfortunate, really.
<iwj> doko: Did you set the bug to Fix Released manually ?
<iwj> doko: Ie, autopkgtest filed bug 151897 against 20070206-1 but you uploaded -2.  I assume that autopkgtest must have decided to test it almost immediately the bug was marked Fix Released and found it still had the old version.
<ubotu> Launchpad bug 151897 in dict-en-za "autopkgtest gutsy dict-en-za: erroneous package!" [High,New]  https://launchpad.net/bugs/151897
<ogra> pitti, did you reject both edubuntu artwork 0.1.0-53 uploads ?
<pitti> ogra: no, I accepted one
<ogra> https://launchpad.net/ubuntu/gutsy/+source/edubuntu-artwork doesnt show it
<doko> iwj: closed in the changelog
<iwj> doko: Harrmf.
<ogra> i'll wait then
<pitti> ogra: hm
<doko> iwj: sorry if that confuses autopkgtest ;p
<iwj> doko: No, that's the right thing to do.  I will file a bug against LP with a task for autopkgtest too for a workaround.
<pitti> ogra: ah, it's still in accepted; needs another publisher run
<ogra> good
<iwj> doko: Can you forward me the Accepted mail for dict-en-za, if you still have it ?
<pitti> ogra: at freeze times, we (unfortunately) don't have that "sources goes straight in and builds from accepted" feature :(
<ogra> pitti, fine with me, i can ask :)
<doko> iwj: done
<iwj> doko: Thanks.
<ogra> pitti, there is also a g-p-m upload in the unapproved queue
<pitti> ogra: how much has this been tested?
<pitti> oh, he's not here
<pitti> there's not even a bug number in the changelog
<norsetto> seb128: re. bug 69800 I can confirm that it is just a matter of replacing the tarball with the upstream tarball. Just built and installed a package with that (details in the bug report).
<ubotu> Launchpad bug 69800 in sensors-applet "Please package original icons from source" [Wishlist,Confirmed]  https://launchpad.net/bugs/69800
<jojo4u> I have a suggestion about ubuntu.com. the counter on the right still links to beta instead of the rc. slangasek pinged the webmaster 12 hours ago, perhaps he's absent? and on the rc announcment page https://wiki.ubuntu.com/GutsyReleaseNotes leads to nowhere (should probably be https://help.ubuntu.com/community/GutsyUpgrades)
<cjwatson> jojo4u: the webmaster's in the US, it probably just hit his evening and he isn't up yet
<jojo4u> no, problem, main reason was to add the wrong link
<cjwatson> jojo4u: good catch on the dead link in the announcement. I've added a redirect to GutsyGibbon/ReleaseNotes.
<cjwatson> sigh, man-db 2.5.0 turned out to be buggier than I'd hoped
* cjwatson suspects a quick 2.5.1 may be in order
<iwj> Riddell: There seem to be bunches of autopkgtest bugs appearing due to some problem with kdelibs4-dev.  Do you know what this is about ?
<iwj> doko: Now this is weird.  Did you attempt to fix ispell-czech ?
<doko> iwj: I requested a sync
<iwj> And did you set the bug to Fix Released at that time, or what ?
<doko> iwj: pitti did after syncing. I used the very same report to notify ubuntu-archive
<iwj> "Is this kind of thing going to happen every time we use the improbability drive^W^Wbug system ?"
<doko> :-)
<iwj> 20040229-4 is the new or old version ?
<doko> old
<doko> 4.1 is the new
<iwj> Grgh.
* iwj turns autopkgtest off.
<iwj> I'll leave it off for an hour or two for the publisher to run.
<iwj> Or it'll just refile all of these bugs.
<iwj> doko: fyi, 151925 is the bug I've filed against LP and autopkgtest about this behaviour.
<iwj> bug 151925
<ubotu> Launchpad bug 151925 in autopkgtest "Bugs set to Fix Released by changelog-closes-bugs before fixed version is published" [Medium,Confirmed]  https://launchpad.net/bugs/151925
<pitti> iwj: do you think we can do some mobile MIR today? (bug 149275)
<ubotu> Launchpad bug 149275 in tasks "First cut of source packages for -mobile promotions" [Undecided,New]  https://launchpad.net/bugs/149275
<pitti> iwj: I propose we look at the packages, mark the innocent and good ones, and set their tasks to confirmed?
<iwj> My http request is important to Launchpad.  Please wait ...
<iwj> Cor blimey.
<iwj> These aren't proposed to be promoted for gutsy, are they ?
<pitti> iwj: I'm not sure
<pitti> Mithrandir, StevenK: what's the target for above MIRs?
<iwj> If not then is there any reason why it can't wait until after the release ?  Now isn't quite the time for this kind of work.
<StevenK> If you want to, or just mark for promotion and do the actual promotion for Hardy
<Mithrandir> pitti: it's not urgent, so waiting for hardy is fine
<pitti> I just had the impression that it was quite important; do we need any of this for gutsy?
<pitti> Mithrandir: ah, ok; thanks
<StevenK> pitti: Important-ish, but not worth breaking your back over.
<pitti> iwj: so, false alarm then; I just spotted it on my TODO list, which I had to pretty much neglect in the last days
<iwj> StevenK: There is a difference between important and urgent.
<iwj> StevenK: The question is, does it matter to postpone this work until after the gutsy release ?
<StevenK> iwj: Indeed. I did not mention either in the bug.
<StevenK> iwj: I filed the bug so that it was some place I wouldn't forget about.
<iwj> StevenK: OK, that's the nice answer, thanks :-).  Remind us again after we're done with gutsy.
<iwj> doko: I don't think I understand what's happening in bug 151662 but whatever it is it doesn't look good.
<ubotu> Launchpad bug 151662 in mbr "autopkgtest gutsy mbr: erroneous package!" [High,New]  https://launchpad.net/bugs/151662
<iwj> autopkgtest complained about this before and I thought it was archive skew but it has done the same thing again.
<Keybuk> mvo: I had a thought on the evms issue
<iwj> AFAICT the problem is some kind of dependency tangle surrounding util-linux and linux32.
<bluefoxicy> o.o hi Keybuk
* bluefoxicy waves and then wanders off to work.
<Keybuk> bluefoxicy: hi :-)
<Keybuk> mvo: would evms be still removed if they had universe in their repository list?
<soren> iwj: WAsn't linux32 superceded by util-linux?
<cjwatson> iwj: mbr build-depends on linux32 which is provided by util-linux
<cjwatson> iwj: I don't understand why autopkgtest feels it has to remove util-linux and install linux32 instead
<iwj> cjwatson: It's using apt's dependency resolver.
<cjwatson> but the trivial fix would be to build-dep on util-linux (>= 2.13) | linux32
<cjwatson> I'll do that
<ubuntu_demon> Hi. I think I have found a Gutsy kernel bug which might be very important (causing data-loss)
<iwj> apt-get build-deb mbr seems to DTRT.
<iwj> s/deb/dep
<cjwatson> iwj: would you rather I left it there as a test case?
<iwj> cjwatson: Err, I don't think I understand the situation well enough yet to have an opinion.
<cjwatson> I have the fix here
<ogra> hmm, r-m doesnt think i'm using my broadcom firmware (which i actually do, installed via r-m)
<soren> cjwatson: That's what Debian has done, fwiw.
<cjwatson> I didn't notice they'd taken my patch
<soren> cjwatson: I don't know about that. I just noticed they have util-linux (>= 2.13) | linux32 :)
<cjwatson> they did, I suggested that build-dep as a possibility
<soren> Why? util-linux is essential an provides linux32?
<cjwatson> out of a vague sense that a virtual build-dep might break something
<cjwatson> like autopkgtest ;)
<ubuntu_demon> Any kernel devs around I could talk to ? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/151938
<ubotu> Launchpad bug 151938 in linux-source-2.6.22 "gutsy kernel is causing data-loss.somehow related to SATA (media-error)" [Undecided,New] 
<cjwatson> ubuntu_demon: #ubuntu-kernel, but they're mostly on US time so you'll have to wait a bit
<soren> cjwatson: Well, you were clearly spot on :)
<bddebian> Heya
<cjwatson> iwj: all I need to know is whether, *if* it turns out that this is a bug in autopkgtest's build-dependency resolution, changing the package will make it more painful for you to fix it by removing your test case
<iwj> mvo: Looks like bug 151662 might be something to do with gdebi.  apt-get build-dep mbr  does something different to what you see gdebi doing there.
<ubotu> Launchpad bug 151662 in mbr "autopkgtest gutsy mbr: erroneous package!" [High,New]  https://launchpad.net/bugs/151662
<ubuntu_demon> cjwatson: Okay thanks. I will return tonight. I think it might be an important bug because it is causing data-loss
<Amaranth> ubuntu_demon: Wow you really didn't want the bug to stall in 'Incomplete', that's a lot of info :)
<iwj> cjwatson: OIC.  Yes,
<iwj> cjwatson: I think I'm coming to the conclusion that it is such a bug and yes please don't remove my test case.
<ubuntu_demon> Amaranth: I have the sense that this bug might be important
<Amaranth> ubuntu_demon: Do you get those errors in gutsy too or only when mounting the gutsy partition in feisty?
<cjwatson> iwj: ok, I've noted that in the bug, thanks
<iwj> cjwatson: Ta.
<soren> iwj: I'm curious.. How are you calling apt now if not as "apt-get build-dep" ?
<ubuntu_demon> Amaranth I'm not sure whether I get those bugs in Gutsy too.
<iwj> soren: That doesn't work for autopkgtest because autopkgtest wants to be able to use a .dsc rather than downloading stuff.  So it uses a Python module which is party of gdebi.
<mvo> iwj: oh? thanks. let me check
<soren> iwj: Oh, I see.
<mvo> Keybuk: yes, we force its removal, but if the upgrade fails because of errors in packages the cleanup stage is not run because we can not be sure about the state of the system. but I guess that is wrong in the evms case
<iwj> mvo: The actual python scriptlet I use isn't in that transcript but I can tell you what it was if you want.  It's just the standard thing for getting gdebi to do build deps, as you advised me to do.
<ubuntu_demon> I'll return tonight on irc to try to talk to kernel developer(s). Bye!
<mvo> iwj: I wonder if there is a bug in the parsing of arch specific build-deps in gdebi, let me check that
<soren> mvo: It's not an arch specific build-dep that's causing the problems here, though.
<soren> mvo: Of course the arch specific build-deps might be confusing it so much that it doesn't get the non-arch-specific ones right anymore. :)
<mvo> iwj: does the log actually contain the build-deps that got installed (/me maybe a little bit blind today)
<cjwatson> mvo: in your upgrade tests, have you encountered these debconf segfaults that keep cropping up in sporadic bug reports?
<cjwatson> they're clearly not debconf's fault (debconf is pure Perl) but I have no idea whose fault they are
<iwj> mvo: I can't see it, no.  But you can see the debug output.
<iwj> (I don't know why the b-d installation itself isn't shown.)
<Riddell> iwj: sorry, missed your comment.  I don't know why kdelibs should break things, do you have an example?
<iwj> Riddell: bug 151924 for example.
<ubotu> Launchpad bug 151924 in kdemultimedia "autopkgtest gutsy kdemultimedia: erroneous package!" [High,New]  https://launchpad.net/bugs/151924
<Ixan> anyone tried mounting a micro sd card? getting some strange output from dmesg
<mvo> cjwatson: I haven't seen them myself, no. but I was doing less tests than usually because of compiz madness^Wwork. liw did a bunch too, maybe he has seen some?
<cjwatson> liw: ^--
<cjwatson> I'm wondering if it's something to do with different frontends; do either of you test that?
<cjwatson> different debconf frontends that is
<mvo> iwj: I just checked on amd64 and it looks like the problem is that one of the build-dep marks util-linux (essential) for removal. that confuses the hell out of pbuilder at least
<mvo> iwj: both the regular build-dep script and the gdebi based one
<iwj> mvo: The final build-dep is linux32.
<cjwatson> mvo: mbr build-deps on linux32; util-linux conflicts/replaces/provides linux32
<Riddell> iwj: no idea, kdelibs4-dev is certainly installable since I compile packages against it most days
<cjwatson> mvo: it looks like it's insisting on installing the real package rather than realising that the virtual package is already installed
<iwj> E: Build-Depends dependency for kdemultimedia cannot be satisfied because no available versions of package kdelibs4-dev can satisfy version requirements
<Riddell> iwj: oh, is this new today?
<mvo> iwj: yeah, I just checked, gdebi will not want to continue if there is a conflict with a essential package. I can fix that for you. how urgent is this? i.e. should I do that today?
<iwj> Riddell: It may be.
<iwj> mvo: Err, it's not urgent no.
<iwj> mvo: That is I don't think it is.
<Riddell> iwj: it's probably the 3.5.8 builds if it is, they all got let through at once and some will need to wait for kdelibs to build
<iwj> mvo: But I'm still not sure I understand why it doesn't just use the linux32 provided by util-linux which is already installed.
<iwj> Riddell: OIC
<iwj> Riddell: OK, just archive skew then.
<Riddell> iwj: yes, that one is 3.5.8, so it should sort itself out by the end of the day
<mvo> iwj: that is a good question, but the problem seems to affect both apt and gdebi
<iwj> mvo: Yes.
<Kopfgeldjaeger> hi
<liw> cjwatson, I haven't seen debconf segfaults
<Kano> hi, did someone test radeon x700 se or intel g33?
<Kano> with latest rc...
<Kano> x700se has major problems with the ati xserver used, also g33 does not work correctly with compiz enabled
<Kano> i definitely had no issues with a lenny backport of the intel driver on etch (+beryl as no compiz fusion would work with etch)
<Kano> the latest ati xserver would work too...
<Kano> fully ubuntu specific issues
<Kano> of course you could blacklist both in your compiz script but...
<Kano> thats not the cause of the problem
<Kano> hmm your current intel driver even has issues on gdm, so not compiz related at all...
<Kano> http://kanotix.com/files/fix/ubuntu/ubuntu-intel-g33.png
<Kano> lower part of screen is bad...
<Mithrandir> Kano: which kernel and xserver-xorg-video-intel version?
<Kano> Mithrandir: ubuntu rc
<Mithrandir> Kano: known bug, already fixed.
<Kano> with current snapshot?
<Mithrandir> fixed in the archive at least.
<stgraber> Kano: a new xserver-xorg-video-intel as been uploaded this morning (or was it yesterday ?)
<Kano> ok, will try online update...
<Mithrandir> stgraber: I approved it last evening, UTC-time
<Kano> why do you have got fglrx blacklisted in compiz startscript and do not simply check for aiglx support
* Hobbsee waves
<stgraber> hi Hobbsee
<Keybuk> mvo: BBZZZZTT
<mvo> Keybuk: hu?
<Kano> Mithrandir: ok, updated intel driver works, what about a new ati driver?
<Hobbsee> Kano: for?
<Keybuk> mvo: installed feisty, made sure universe was enabled and installed evms
<Keybuk> upgraded to gutsy
<Keybuk> evms was *not* removed
<mvo> *urgh*
<Kano> Hobbsee: x700se, even much more major that problem
<Hobbsee> bug #?
<Mithrandir> Kano: I haven't seen any.
<Kano> fully screen error when compiz runs
<Kano> but only on ubuntu...
<Kano> no problem with sid, when using radeon instead of ati it even runs with pure etch...
<Kano> also with amd64 there is no splash screen
<Kano> with i386 iso it works
<Hobbsee> which bug #?
<mvo> Keybuk: checking now. sorry
<Kano> Hobbsee: did not check out your images all the time, because i primary use only the kernel from ubuntu
<mvo> Keybuk: can you send me the upgrade logs please (/var/log/dist-upgrade/*)?
<Kano> btw. the current ntfs-3g is not 1.913 but 1.1004
<Kano> http://www.ntfs-3g.org/releases.html
<Hobbsee> and we're 6 days from releaes.
<cjwatson> Kano: I looked at 1.1004 and decided not to include it
<Kano> # fix: unwritten sparse file regions could get corrupted if the end of a write wasn't aligned to cluster boundary. Sparse files are very rarely used, most typically by bittorent clients.
<Hobbsee> we're not idiots, you know.
<Kano> so you like that error
<cjwatson> no, 1.913 had been better tested
<Kano> funny
<cjwatson> (on Ubuntu)
<cjwatson> Kano: http://wiki.ubuntu.com/TimeBasedReleases
<mantiena-baltix> hi all
<Kano> when you use bittorrent then you should not use ubuntu ;)
* mode/#ubuntu-devel [+o cjwatson]  by ChanServ
<cjwatson> Kano: either be constructive, or leave
<cjwatson> our release cycle is well-documented and it is not always possible or sensible to include the latest version of every piece of software
<Kano> cjwatson: i have my own repository - therefore i update it the day a new ntfs-3g comes out
<Hobbsee> Kano: yes, and we are nto your repository - and thank goodness for that.
<cjwatson> we haven't yet been using ntfs-3g long enough to develop the sort of total trust in it required to do that kind of thing
<Kano> why not?
<cjwatson> why not what?
<cjwatson> we haven't yet been using it long enough because that is a fact
<Kano> well ntfs-3g is one of the most important drivers
<cjwatson> it's not subject to "why"
<cjwatson> we don't ship the latest upstream kernel either, since we haven't had time to test it
<cjwatson> very few projects issue perfect releases
<cjwatson> if ntfs-3g were perfect, it wouldn't be shipping bug-fix releases :-)
<cjwatson> that's just a function of being human
<Kano> sure, but then add em
<cjwatson> no, sorry
<cjwatson> we'll upgrade to ntfs-3g 1.1004 in our next release
<Kano> the only thing that changes is the libary name
<cjwatson> (or whatever's current by then)
<Kano> everytime +1
<Kano> very huge change
<pitti> Kano: this particular fix could very well become an SRU if it is important, but blindly taking the entire release is not appropriate now
<mantiena-balt> pitti: you added "OnlyShowIn=GNOME;" into displayconfig-gtk.desktop.in ?
<Kano> debian is slow too, they dont have that package yet, maybe the maintainer is too busy with other things
<pitti> mantiena-balt: me? no
<Kano> not even in mentors, maybe he is on holiday...
<Kano> the usual delay is only a few days not >1 week...
<mantiena-balt> pitti: so, maybe you can remove "OnlyShowIn=GNOME;" from displayconfig-gtk.desktop.in ? It's a problem because displayconfig-gtk isn't visible in Xubuntu :(
<pitti> hm, glatzor is not here
<Kano> why is iwlwifi_rc8021_simple loaded when there is a card in the system with p54pci (saidly prism54 is loaded too wrongly)
<pitti> mantiena-balt: I guess it was meant to supppress showing in KDE
<Kano> and that shows of course errors in dmesg
<pitti> mantiena-balt: would "NotShowIn=KDE;" work? <- Riddell
<Hobbsee> LaserJock: from sevilla, i'm unconvinced that canonical was hiding information - more that it was just utterly and totally disorganised, and never asked for any help either, so stayed disorganised.
<Riddell> pitti: yes, it would
<mantiena-balt> pitti: I understand, that this is because of KDE, but all other desktop environmens should have visible displayconfig-gtk
<xhaker> hey jono, check our sweet ubuntu table http://www.flickr.com/photos/7661871@N07/1551047647/in/set-72157602384597065/
<pitti> mvo: is displayconfig-gtk maintained in bzr? There's no Xs-Vcs header
<evand> xhaker: that's awesome!
<xhaker> evand: I know!
<popey> xhaker: that's great!
<xhaker> evand: thanks ;)
<pitti> mvo: eww, yes, and I cannot commit to it
<xhaker> I'm typing at those tables right now, Ubuntu-pt goodness
* mode/#ubuntu-devel [-o cjwatson]  by cjwatson
<xhaker> It's the first ever Forum about open source here at Lisbon
* xhaker tries to put things in context
<popey> xhaker: i want to ask you a question in prv but you are not identified with services...
<pitti> -OnlyShowIn=GNOME;
<pitti> +NotShowIn=KDE;
<pitti> mantiena-balt, Riddell: ^ ok that?
<xhaker> popey, will do.. using web irc
<mantiena-balt> mvo, pitti: for me is OK, I don't use KDE :)
<Riddell> pitti: looks good
<pitti> great
<pitti> uploaded
<pitti> Riddell: could you please review and accept it from the queue?
<Kano> ati card with error is: 1002:5e4f, which would at least boot ubuntu when i blacklist it in compiz startup script (which disabled splash for amd64), no go with compiz, also needed to kill X once to get the menu
<StevenK> Hmph. The buildds are being KDE'd
<Hobbsee> StevenK: it's a feature.
<StevenK> Apparently.
<ogra> pitti, did you notice my ping for g-p-m ?
<Hobbsee> it's a precursor to openoffice
<pitti> ogra: no, I didn't
<StevenK> calc was talking about that.
<pitti> ogra: I asked a question about it, but didn't notice an answer
<StevenK> I just want to see virtualbox-ose-modules actually build.
<ogra> ah
<mantiena-balt> pitti, mvo: so, I don't need to report the bug about "OnlyShowIn=GNOME;" in displayconfig-gtk.desktop.in ?
<ogra> i'm testing here, so i was on and off
<ogra> pitti, what was the question
<pitti> ogra: it looks quite intrusive; how much has this been tested? also, there's no bug# in the changelog; it should be at times like this
<StevenK> pitti: Could I impose on you to bump virtualbox-ose-modules up the buildd queue?
<pitti> StevenK: what's your offer?</blackmail nag>
<ogra> pitti, because i havent found all bugs yet, there are plenty of brightness and suspend bugs it fixes
<StevenK> pitti: I don't kill you in your sleep? :-P
<ogra> pitti, it will close a huge number ....
<Hobbsee> pitti: you're rooming with him.  do you want sleep at all during UDS?
* StevenK high fives Hobbsee 
<pitti> eww, I didn't consider that, right
<Hobbsee> StevenK: ^5
* StevenK chuckles
* popey wonders who the poor unfortunate soul is that he is rooming with
<ogra> pitti, it will be in 2.20.1 anyway
<Kano> Hobbsee: against which packages i should report the ati bug? only against the xserver? splash does only work on 32 bit
<Hobbsee> popey: dunno.  but you might get killed in your sleep, so be careful
<pitti> ogra: hmkay
<popey> :)
<ogra> pitti, i just think it makes sense to have it now :)
<Hobbsee> Kano: i'd guess xserver-xorg-video-ati
<ogra> instead of having annoying brightness behavior
<Kano> but your splash is not the xserver...
<Hobbsee> Kano: then usplash. leave both tasks open, so someone can guess where it is.
<Hobbsee> seems that it only happens with the ati driver, no?
<pitti> ogra: oh, it fixes that, too? great, I used to killall gnome-power-manager to get rid of that
<ogra> pitti, the backend returned uint for a lot of functions ... while the frontend was changed to expect int
<pitti> ogra: hm, it doesn't do that for me any more on latest gutsy, but I'll have another look at it
<ogra> pitti, matthew fixed that for one brightness function, but not for the rest
<mantiena-balt>  pitti, mvo: I must go, please report a bug if you can forgot to removv "OnlyShowIn=GNOME;" in displayconfig-gtk.desktop.in
<pitti> does it deal with a lot of very large numbers? surprising
<ogra> and upstrea apparently didnt notice before final release
<StevenK> Ha. How do you not notice that?
<ogra> pitti, no, it doesnt, thats why it is all int after the patch
<pitti> ogra: ok, accepted
<ogra> which is the right thing
<pitti> thanks
<ogra> thanks for accepting :)
<seb128> gpm accepted?
<pitti> seb128: don't tell me it's all wrong! :)
<ogra> now why cant i group buglusts by one line in one attachment :P
<seb128> pitti: no, actually I wanted this fix as well for gutsy if possible, thanks ;)
<pitti> mmm, buglust
* ogra wonders how to find all the related bugs now
<StevenK> pitti: Saying that sentence with a New Zealand accent means it makes sense. :-)
<xhaker> http://www.formatds.org/ubuntu-pt-1st-free-software-forum-lisbon/
<Kano> #151974
<Kano> bug 151974
<seb128> bug #151974
<ubotu> Launchpad bug 151974 in xserver-xorg-video-ati "ATI Technologies Inc RV410 [Radeon X700]  [1002:5e4f]  - no compiz support" [Undecided,New]  https://launchpad.net/bugs/151974
<seb128> Kano: what about it?
<Kano> just added it
<seb128> Kano: and?
<seb128> Kano: #ubuntu-devel is not a chan to list all the bugs filed, we have a bot on #ubuntu-bugs for that ;)
<seb128> mvo: ^ might be interest by this one
<Kano> your server has timeout issues to add a uplash bug, have got no time now
<Kano> bye
<Hobbsee> LaserJock: you rock  @ http://ubuntuforums.org/showthread.php?p=3520311 btw
<mvo> seb128: 151974 you mean?
<seb128> mvo: yes
<mvo> pitti: I can add you to the team, sec
<mvo> pitti: it should have a header now, no?
<mvo> pitti: added
<pitti> mvo: no
<StevenK> pitti: virtualbox-ose-modules -14 built, can you NEW it, and NBS out -13 at your leisure?
<pitti> cjwatson: lum-cell NEWed
<pitti> StevenK: done
<cjwatson> ta
<pkern> Could we please get https://bugs.launchpad.net/bugs/121653 into the release notes?
<ubotu> Launchpad bug 121653 in linux-source-2.6.22 "[gutsy]  Suspend to Ram does not work on Z61m" [Wishlist,Confirmed] 
<pkern> As in s2r broken with ATI fglrx?
<StevenK> pitti: Thank you!
<dholbach> MOTU Q&A session in 13 minutes in #ubuntu-classroom
<ogra> pkern, yes, known limitation of fglrx
<ogra> (it never worked, so not really worth a note)
<jdong> ogra: pardon? worked 95% of the time on Feisty and Edgy
<pkern> ogra: It worked in feisty and is a regression, kthx
<jdong> ogra: this time it's really really broken
<ogra> with fglrx ?
<pkern> No official comment from a dev so far.
<jdong> ogra: absolutely
<pkern> ogra: Yes.
<ogra> sorry, but thats really news for me as fglrx never sopported suspend afaik
<ogra> ati surely does ...
<mjg59> pkern: I don't know how more official you want it to be
<jdong> with a few acpi-support tweaks (i.e. never POST'ing or vbesave) then it worked for me in feisty
<pkern> mjg59: I want a comment on that very bug, tagged it won't fix and mentioned it in the release notes.
<jdong> I traveled with that laptop for half a year
<mjg59> pkern: It's an issue with a driver we can't support in any real sense.
<pkern> mjg59: There are more and more people commenting on this bug.
* mjg59 shrugs.
<pkern> mjg59: I know that.  But please state that Ubuntu will not offer SLAB kernels and that this bug will not be fixed for Gutsy.
<pkern> mjg59: Currently people are making assumptions on and on.
<pkern> mjg59: And are running into the bug when upgrading.
<Hobbsee> pkern: you can say that yourself - you're a MOTU
<pkern> Hobbsee: That's kernel core stuff.
<Hobbsee> pkern: you class as a ubuntu developer
<Hobbsee> yeah, but do they care?
<pkern> Hobbsee: I already left my comments there.  And I want it documented why a SLAB flavour would be insane, then I'm fine.
<mjg59> pkern: "A" SLAB flavour?
<mjg59> We'd need one for every existing flavour
<Hobbsee> pkern: release noting that would be good.  you might want to email slangasek with the words you want in there for it.
<pkern> mjg59: Yeah well, I know. Maybe it would not be necessary for all, though.
<mjg59> pkern: And then leave all the -rt people with fglrx complaining that we don't care about them?
<pkern> I.e. -generic on amd64, not -{server,rt,xen}.
<cjwatson> pkern: I have added it to the release notes.
<pkern> cjwatson: Thanks a lot!
<mjg59> pkern: So no, we're not doubling the number of kernel flavours to maintain just because fglrx is buggy
<pkern> mjg59: It would be at least a workable solution for laptop users, yeah.
<mjg59> We've always been clear that restricted drivers cannot be offered with the same level of support as open ones
<pkern> Instead of compiling an own kernel for Gutsy and redo that on every Ubuntu kernel update.
<Hobbsee> mjg59: but cant you just fix the world, and give everyone ponies?
<Hobbsee> really, it seems like that's what htey're asking for in the bug
<iwj> My http request is important to Launchpad ...
<iwj> ... the database server knows I am waiting ...
<ogra> pitti, do we have any blocker bugs about tracker on NFS servers ?
<iwj> ... we are sorry but my http request could not be completed at this time.
<ogra> pitti, seems sbalneav has some bad issues going on
<pitti> not that I know of
<ogra> hmm
<sbalneav> Hey, any way to set a global exclude for all users for trackerd?  I upgraded one of my servers here to test and trackerd's killing my NFS home server :)
<ogra> sbalneav, i think there was a gconf key ...
<ogra> but i wonder if there shouldnt be an option i tracker to exclude networked dirs
<ogra> *in
<sbalneav> probably.  I've got 3 users who dragged the load in the nfs server up above 7
<sbalneav> can't imagine what will happen when I convert the other 85 :)
<ogra> rm -rf /home/* ;) solves all issues :P
<ogra> nothing to index ... no load :)
<ogra> honestly i'd remove tracker ...
<sbalneav> That may be the solution.
<pkern> cjwatson: Thanks for suggesting not to upgrade. That's fine for me.
* pkern is happy now.
<mvo> Keybuk: the reason that evms got not removed in your case was that you had packages depending on it and the upgrader is trying to be too clever. thanks for catching this, I'm preparing a update now
<StevenK> pitti: So, ScottK and I have a question.
<StevenK> pitti: Until which point can we reasonably say "Okay, fine" to UVFe's?
<ScottK> Ones that have important bug fixes in them.
<StevenK> Er, yeah. :-)
<Hobbsee> StevenK: archives close on monday.  real, rock solid freeze.
<StevenK> Hobbsee: Which is four days before release. No bug fixes after Monday?
<Hobbsee> StevenK: correct.
<Hobbsee> StevenK: although it'll be monday american, of course
<ScottK> Hobbsee: Is there a time on Monday?
<r_rehashed> Hi all. i have reported a small bug in gnome-utils. here it is https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/150984
<ubotu> Launchpad bug 150984 in gnome-utils "Title of the 'Similar words' frame in gnome-dictionary gets overlapped by the Close Frame and Sort icons, when the frame is re-sized" [Low,Incomplete] 
<Hobbsee> ScottK: i didnt see one.
<r_rehashed> i would like to fix it myself
<persia> Is there a plan to try to clear https://bugs.launchpad.net/~ubuntu-archive beforehand?
<seb128> r_rehashed: hey, first we should agree that's a bug
<r_rehashed> can anybody guide me on on how to get the source etc.?
<seb128> r_rehashed: I don't really get the point to limit the user possibilities
<Hobbsee> ScottK: if you wish to peruse the meeting log, you're welcome
<seb128> r_rehashed: if the user want to reduce over the text limit why do you can to forbid him doing so?
<r_rehashed> seb128: the overlapping looks ugly. u want to keep it that way?
<seb128> r_rehashed: what do you suggest which doesn't limit the action?
<ScottK> Hobbsee: Which meeting?
<seb128> r_rehashed: between ugly or not possible I prefer ugly
<Hobbsee> ScottK: ubuntu community developer meeting, or something.  i dont remember exactly what i'ts called
<seb128> r_rehashed: now if you have a way which let the user move the sidebar where he wants without looking ugly feel free to describe it
<Hobbsee> was yesterday, logs should be in the usual places
<ScottK> Hobbsee: OK.  Thanks.
<Hobbsee> ScottK: he's been warned about sending mails out to good places, or being impaled.
<r_rehashed> seb128: couldn't we let the user slide the pane fully like in nautilus, yet have the text not get overlapped?
<Hobbsee> so, we should see something soonish.
<ScottK> Hobbsee: Sounds good.
<r_rehashed> seb128: u don't want to stop the user's ability to slide the pane fully to the boredr, right?
<seb128> r_rehashed: correct
<r_rehashed> seb128: so if we make it like it is nautilus, woudn't it be fine?
<r_rehashed> seb128: like it is in*
<seb128> r_rehashed: I'm not sure, it masks the close button the nautilus way
<seb128> r_rehashed: anyway if you want to experiment, you can add a deb-src source in your apt.list
<seb128> r_rehashed: you can use system, administration, software sources for that
<seb128> apt-get source gnome-utils
<seb128> sudo apt-get build-dep gnome-utils
<r_rehashed> seb128: thank you
<seb128> sudo apt-get install devscripts
<seb128> cd gnome-utils-2.20.0
<seb128> debuild
<pitti> StevenK: you mean FFs?
<r_rehashed> seb128: thanks a lot :)
<pitti> StevenK: that's hard to answer in a general fashion
<seb128> r_rehashed: no problem
<pitti> StevenK: if the new upstream version only fixes a bug in an obvious manner, it's fine
<pitti> StevenK: the default answer should be "no" nowadays, though
<StevenK> pitti: It is.
<StevenK> pitti: The question was more, at which point is it unreasonable to ask you/the release team to allow something in
<ScottK> StevenK: Looks like Monday "afternoon" for some TZ's definition of afternoon based on the meeting logs.
<pitti> StevenK: for universe and main/not on CD, I'd say Wednesday; for stuff on CD: Sunday
<StevenK> pitti: Asking as motu-uvf, but okay, ScottK and I will make sure the other -uvf people know.
<r_rehashed> seb128: the bug is still there in 2.20 ? i use gnome 2.18
<seb128> r_rehashed: yes
<r_rehashed> ok
<pitti> yay! a rosetta tarball
<StevenK> pitti: Thanks
<StevenK> pitti: And -14 is done, so -13 can be killed if not already
<pitti> StevenK: if motu-uvf approves, I'm fine with waving it though the queue
<ScottK> StevenK: So how about Universe hard freeze Monday with motu-uvf to approve all uploads after that (upstream, revision, anything)?
<StevenK> ScottK: Sounds perfect.
<ScottK> Then Tue/Wed we can ack stuff if it REALLY needs to get in.
<StevenK> ScottK: Update the topic in -motu, or shall I?
<ScottK> Hobbsee: Sound good to you ^^^
* persia requests UTC time references for "Monday" and "Tue/Wed"
<iwj> Maybe I should set myself a quota of 10 bugs for each test case, and then go on to the next one.
<StevenK> iwj: Oh, good catch with that Linda bug.
<iwj> StevenK: Well, that's automatic testing for you :-).
* StevenK grins
<soren> pitti: Could you give lib{nss,pam}-ldap a nudge? It's just documentation changes.
<iwj> Speaking of which I should turn autopkgtest back on.
<ScottK> StevenK: Go for it.
<pitti> soren: ok, I'll do that in a bit
<soren> pitti: Thanks.
<Hobbsee> persia: bug slangasek and such for them.  i dont have them.  i havent seen beyond what's in that meeitng.
<persia> Hobbsee: My request is for S{cott,teven}K regarding their updates to the MOTU header.  Not for the real archive time.
<Alpha_Cluster> Hobbsee: I have a small but rather annoying but in Gutsy that has been getting ignored tonyyarusso told me to talk to you do you have a bit to look at it?
<sladen> Alpha_Cluster: bug number normally helpful
<Hobbsee> Alpha_Cluster: possibly, but a bug # would be really useful
<Alpha_Cluster> its bug #139800
<ubotu> Launchpad bug 139800 in ubuntu "Screen and Graphics sets resolution wrong" [Undecided,Confirmed]  https://launchpad.net/bugs/139800
<sladen> useful!  must remember that word :)
<Alpha_Cluster> sorry i have a tendency to forget importent hyperlinks in messages
<sladen> Alpha_Cluster: responded on the bug report asking for some information
<Alpha_Cluster> responded :)
<Alpha_Cluster> btw A
<sladen> Alpha_Cluster: and it scrolls when your mouse goes near the edge?
<Alpha_Cluster> yep
<Chipzz> sladen: mjg59 has a partial fix for that
<Chipzz> sladen: at least for gdm
<Alpha_Cluster> I would like to point out again that the virtual command being put into the xorg.conf is not being formated the same as the rest of hte file is that supposed to be that way?
<Chipzz> sladen: mantiena-baltix has been complaining practically non-stop for the past 2 days about it now :P
<Chipzz> Alpha_Cluster: the bug is known, a fix exists for gdm, but the desktop is not going to be fixed for gutsy iirc
<Chipzz> (gdm is, possibly)
<sladen> Chipzz: is there an existing bug number to dup it against
<Chipzz> not sure
<Chipzz> mjg59: ping?
<Alpha_Cluster> Chipzz: that is dissapointing to hear because i have had this happen a few times and have people who i have helped install that literally are not guna install gutsy do to this bug.
<Chipzz> sladen: I'll ask mjg59
<sladen> oops, 87 open for displayconfig-gtk
<mvo> sladen: and a lot duplicates
<mvo> sladen: that is of the 87 a bunch are duplicate or bug in the guidance-backend
<mvo> it needs cleanup
<Chipzz> imho there is a fix, which is putting the highest resolution first in the list of resolutions, but I doubt that's correct
<mjg59> There is a fix, which is getting rid of non-randr1.2 drivers
<Alpha_Cluster> couldnt you just not use virtual?
<mjg59> Alpha_Cluster: Upgrade gdm
<Chipzz> the gist of the problem (as I understand it) is that X will not allow resolutions higher than the highest resolution specified in the list of resolutions for a particular bit-depth
<Chipzz> but
<Alpha_Cluster> the problem is not affecting me in gdm its the problem that its happening outside of gdm whne im in gnome itself
<Chipzz> the resolution the user chooses may be lower than the highest resolution possible
<Chipzz> but if we restrict the set of resolutions to the resolution specified, you can't get a higher resolution without restarting X
<Chipzz> so specifying the highest resolution possible is correct
<mjg59> Alpha_Cluster: Upgrade gdm
<Alpha_Cluster> um ok ill try
<Chipzz> problem is when drivers do not implement xrandr correctly, and scroll when switching to a lower res
<mjg59> Chipzz: No, they implement it correctly
<Alpha_Cluster> im diong a fresh install from rc right now
<Chipzz> mjg59: does that sum it up correctly?
<mjg59> They just implement an older version
<mjg59> Alpha_Cluster: It's not in rc
<Alpha_Cluster> ill upgrade after i install
<mjg59> Ok
<Alpha_Cluster> my current devel version is horriblely out of date
<Chipzz> mjg59: but apart from my last statement I'm correct, right?
<mjg59> Chipzz: Not really
<ogra> Chipzz, well, there are cases where you need virtual scrolling
<Chipzz> ugh :)
<mjg59> ogra: No there aren't. At least, there shouldn't be - it's impossible with any of the newer drivers.
<ogra> mjg59, i noticed ... that somewhat forces e to i810 on the classmate :(
<ogra> s/e/me/
<ogra> mjg59, still there are such cases
<mjg59> ogra: Eh? No, scrolling isn't the right solution there.
<ogra> mjg59, dont tell that to me
<mjg59> If there's an issue with our applications not being able to work at that screen resolution, then we need to fix the applications
<ogra> scrolling is what they want
<ogra> (optionally)
<mjg59> Intel? Well, they can't have it.
<ogra> they can with all other distros
<mjg59> It's their employees who developed this
<ogra> and its a main demand
<mjg59> They won't be able to in the near future
<ogra> they will, they have access to the source :)
<mjg59> Well, no.
<ogra> you mean they cant patch it ?
<ogra> :)
<mjg59> I mean the only people in Intel that could alter this behaviour are the people who implemented this behaviour in the first place
<mjg59> randr1.2 simply doesn't have the ability to implement this functionality
<ogra> i agree that the apps should be able to handle 800x480 ... but reality is that 90% of our apps dont
<mjg59> Given the screen size, it would make more sense to run UME on it
<ogra> probably
<mjg59> But we probably won't be shipping i810 in hardy
<mjg59> So there's going to have to be some other solution
<ogra> well, hardy is another release :) currently i'm looking into gutsy
<ogra> which will only be a demo
<ogra> so all options are still open
<ogra> (for hardy)
<ogra> UME would make sense but is missing educational app integration atm
<ogra> why cant i edit gnome-power-m,anager bugs anymore
<ogra> grmpf
<ogra> "You are not the bug assignee nor the maintainer of gnome-power-manager (Ubuntu), and therefore cannot edit this bug's status."
<ogra> GRR
<Hobbsee> ogra: try logging in
<ogra> uuuh
<Hobbsee> ogra: LP probably ate the cookie.
<ogra> whats that
* ogra wrecks his brain for the password
<Hobbsee> pwsafe -up launchpad.....
<iwj> cjwatson: /var/log/installer/syslog added to bug 152012 fyi
<ubotu> Launchpad bug 152012 in ubiquity "ubiquity messes with sound volume" [Undecided,New]  https://launchpad.net/bugs/152012
<mathiaz> is aptitude full-upgrade a supported method to upgrade from feisty ?
<ogra> mathiaz, i dont think so
<mathiaz> ogra: ok. Thanks. That's what I thought.
<ogra> i dont think we support any upgrade ethod beyond u-m officially anymore
<mvo> pitti: I have a final update-manager upload for review, all nice and safe
<mathiaz> ogra: I guess that apt-get dist-upgrade is not supported either.
<ogra> right
<mvo> mathiaz: only if people read the release notes carefully and follow it, but generally we prefer people to use our upgrader
<pochu> Could anyone please upload liferea for me? It's been approved by slangasek.
<pochu> slomo, calc ^ ?
<ogra> http://www.ubuntu.com/getubuntu/upgrading
<pochu> err, link: http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu3.dsc
<ogra> Manual command-line upgrade (not recommended)
<ogra> Please note - this method is less reliable. If you use this method, you MUST be prepared to fix problems manually, such as packages being unexpectedly removed, apt crashing unexpectedly, etc. Using Update Manager (see above) is likely to be much less problematic.
<ogra> (it doesnt really say "we dont support it")
<mathiaz> ogra: hum...
<ogra> (it should though :) )
<ogra> imho
<ogra> we sell it as "not recomended"
<mathiaz> I've got a bug report (bug 148586) about an aptitude full-upgrade that install l-u-m-386 instead l-u-m-server.
<ubotu> Launchpad bug 148586 in apparmor "Depends on linux-ubuntu-modules-386" [Medium,Incomplete]  https://launchpad.net/bugs/148586
<ogra> but not as "not supported"
<mathiaz> ogra: in the sense "it's not tested, but it may work for you..."
<ogra> right, if you know how to solve smaller probs
<ogra> mathiaz, i bet he hasnt got the linux-server package installed (only -image-server)
<mathiaz> ogra: hum... may be
<ogra> even though i dont understand how he gets the -386 one
<mathiaz> ogra: well... I'm not sure what really happened as the reported mentionned he needed 3 rounds of upgrades..
<ogra> yeah
<mathiaz> where are the logs for an aptitude full-upgrade ?
* ogra never used aptitude 
<Keybuk> heh, Epiphany's history dialog lets you search your history for phrases and mass-delete the results ...
<Keybuk> now there's somebody who understands their use case
<Keybuk> :p
<ogra> at least not while knowing it (i think d-i uses it dsomewhere)
<pitti> mvo: ok; please get it uploaded, we'll review it in the queue
<pitti> Keybuk: phreaks...
<mvo> pitti: thanks
<sbalneav> Hmmm, slight regression gnome file-save dialogue
<ogra> mathiaz, i guess what hapened is: he has the linux-image-server package (but not linux-server so no dep on *any* l-u-m) ... the upgrae pulled in apparmor and the first package that fulfilled apparmor-modules was l-u-m-386
<Keybuk> sbalneav: ?
<sbalneav> If you do a "save-as", and tha name of the file's filled in...
<mathiaz> ogra: right. That makes sense.
<ogra> mathiaz, check what heppens if he installs linux-server
<sbalneav> and you click on one of the file locations to change the directory where you're saving...
<sbalneav> it erases the filename.
<mathiaz> ogra: I'll try to to an aptitude full-upgrade to find where the logs are and reproduce his problem.
<mvo> pitti: it should be in the queue now (the latest upload is it)
<slangasek> ArneGoetje: this ttf-dejavu upload seems to include changes to combining forms for a number of non-standard codepoints in DejaVuCondensedSansBold, in addition to the ligature changes; is this intended?
<pitti> mvo: ok; please ask slangasek for further processing, I'm off
<mathiaz> soren: I've uploaded the dovecot package at http://people.ubuntu.com/~mathiaz/packages/.
<slangasek> ArneGoetje: same applies to DejaVuCondensedSans.  Accepted anyway; if it is a side-effect it seems a low-risk one since these aren't standard Unicode codepoints, and the fix is an important one, but perhaps you want to look into why this changed
<sbalneav> Keybuk: Where should I file that against?  libgtk2.0-0?
<mvo> slangasek: if you have a moment, I would appreciate a review of my latest update-manager upload.
<Keybuk> sbalneav: sounds reasonable
<mdke> hi Keybuk, thanks for investigating that evms bug so thoroughly, appreciate it
<lool> slangasek: Around?
<lool> slangasek: Hmm switching to -release
<slangasek> mvo: logging.debug is presumably well away from the UI and therefore not affected by string freeze...?
<sbalneav> Ah, already seems to be reported Bug #93396
<ubotu> Launchpad bug 93396 in gtk "[Feisty]  File save dialog delets filename when changing directory" [Unknown,Confirmed]  https://launchpad.net/bugs/93396
<Keybuk> imagine, translatable debug messages
<mdke> I don't think strings which are away from the UI are automatically free from string freeze; documentation frequently includes strings outside the UI which appear on command line; translators also assiduously translate commands, messages and so on
<mdke> still, debug messages obviously have an incredibly low priority
<slangasek> mvo: update-manager accepted
<maxb> I've just fallen victim to the default dput config, and accidentally uploaded a personal package to upload.ubuntu.com. Is there somewhere I should send an apology to?
<pochu> maxb: it will be automagically rejected.
* pochu looks for a volunteer to upload liferea :) http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu3.dsc
<superm1> slangasek, i'm assuming its going to be too late to request a sync for something that would be NEW from debian that got added recently, correct?
<slangasek> superm1: yes
<superm1> okay i'll defer it for hardy then, thanks
<zul> slangasek: i have another xen-3.1 update for tonight sometime
<zul> fyi
<slangasek> eew? :)
<zul> slangasek: thats a common response :)
<Keybuk> mhb: err?
<Keybuk> mhb: any particular reason you deleted my comment from your blog post?
<Keybuk> or are they in some way moderated, and I can't see them after posting?
<song> my emacs23 told me : cannot open  load file: term/x-win please help me...
<ion_> Great error message. :-)
<song> :'(
<song> how can i fix it?
<ion_> For starters, please read the topic.
<song> i'm sorry ,but i just want some help....please
<ScottK> song: Try #ubuntu
<zul> or somet emacs related channel but this isnt the right channel
<song> ok.....
<superm1> slangasek, I had a debdiff for a few bugs on lirc that pitti said that we might be able to slip in post RC.  he wanted my normal sponsor ( keescook ) to look it over first, and then said that after you or him review it, we can see if it can be slipped through.  keescook looked it over, so would you mind taking a glance?
<slangasek> superm1: sure, link to the debdiff please?
<superm1> slangasek, its attached to bug 147440, http://launchpadlibrarian.net/9863359/lirc-ubuntu7-ubuntu8.debdiff . there is a build log attached there too
<ubotu> Launchpad bug 147440 in lirc "cannot make lirc_i2c kernel module" [Wishlist,Triaged]  https://launchpad.net/bugs/147440
<mvo> slangasek: thanks! yes, logging.debug() is just internal so that I have a idea what goes wrong
<keescook> slangasek: it looks rather large, but most of it is just fixing missing settings for certain remote drivers
<pochu> keescook: do you have a moment to upload liferea for me?
<keescook> pochu: sure, where can I look at it?
<pochu> keescook: http://emilio.pozuelo.org/~deb/liferea_1.4.4-0ubuntu3.dsc Thanks a lot.
<slangasek> superm1: so the fix for 147440 is just an autoreconf?
<superm1> sladen,  yeah there ended up being a few typos in the Makefile for pvr150
<sistpoty> mvo: thanks for your explanation about the package description translation update. where can I file bugs? (just found a very strange german description for etherboot)
<slangasek> presumably not typoes, since I don't see any changes there to non-autogenerated files
<mvo> sistpoty: could you put it into a pastebin pleae?
<sistpoty> mvo: sure, give me sec
<superm1> slangasek, well moreover i should have worded that better, the first time around the Makefile was copied from lirc_mceusb2, and then hand sed s/lirc_mceusb2/lirc_pvr150/g 's
<mvo> sistpoty: easiest is to fix it directly in rosetta, we plan to make the description part of the package translation instead of the big ddtp translation template that we currently use
<mvo> sistpoty: but that depends on changes in launchpad ;)
<superm1> slangasek, this time it was properly autoreconfed
<sistpoty> hehe
<keescook> pochu: you've tested the resulting build of liferea with these changes?
<keescook> (the diff is rather large)
<sistpoty> mvo: http://pastebin.ubuntu-nl.org/40441/ the german somehow has oversized lines, but very funny is "Urlader".
<pochu> keescook: yep
<sistpoty> (in the short desc.)
<mvo> sistpoty: the funny lines are known, its a bit difficult to fix. my take on this that the application (synaptic, apt-cache) should word-wrap
<sistpoty> mvo: right, ok thx
<slangasek> superm1: er, what testing has there been of the patch for 148756?  granted the gpio module doesn't currently work, but are you sure this can't cause anything worse than not working?
<mvo> sistpoty: "urlader" is perfectly valid, but its very funny. I once read a tannenbaum textbook in german that was fully translated. it took me a while to discover that "uhren" means "timers"
<slangasek> superm1: other than that, it looks ok for upload
<superm1> slangasek, well on another bug there is a new method of doing things via dev/input that is documented.  i'm going to move it to the wiki pages
<mvo> sistpoty: it was *very* strange :) full of "unterbrechungen" and stuff like that
<sistpoty> mvo: well, we've got a few "everything must be german profs" at our uni, but I haven't heard urlader yet though ;)
<superm1> slangasek, so this is a better solution than the current not working
<sistpoty> mvo: hehe
<superm1> slangasek, i can't anticipate any troubles worse than the current situation at least.
<sistpoty> mvo: or "tor" for port
<slangasek> superm1: ok
<superm1> thanks slangasek
<sistpoty> mvo: as a prof of our uni said
<keescook> superm1: I'll upload it shortly.
<mvo> sistpoty: haha, that is nice too :)
* mvo leaves for the evening
<keescook> slangasek, superm1: lirc uploaded
<asac> stgraber: would be cool if you could test hidden network with the package mentioned in bug 50214
<ubotu> Launchpad bug 50214 in network-manager "can't connect to hidden network" [High,In progress]  https://launchpad.net/bugs/50214
<keescook> pochu: liferea uploaded (thanks for the fixes!  I've hit the data loss bug myself.)
<mathiaz> keescook: could you have a look at my apparmor bzr branch and merge it in ubuntu-core-dev ?
<keescook> mathiaz: sure!
<keescook> mathiaz: what do you think about the kde abstraction changes?  I figure we could get that in too?
<pochu> keescook: and thanks for the upload! :)
<mathiaz> keescook: which one ?
<superm1> thanks keescook
<keescook> mathiaz: someone pointed out that our current kde abstractions use /opt (from the suse profiles)
<mathiaz> keescook: yes. I've found it
<mathiaz> keescook: bug 148309
<ubotu> Launchpad bug 148309 in apparmor "KDE abstraction is Suse-specific, does not work on Ubuntu" [Low,Confirmed]  https://launchpad.net/bugs/148309
<mathiaz> keescook: the profile removes a lot of lines from upstream.
<mathiaz> keescook: should we keep them and add new ones ?
<keescook> mathiaz: comparing now...
<keescook> (seems also like qt4 should be handled)
<mathiaz> keescook: is qt4 already packaged ?
<keescook> mathiaz: yeah, qt4-x11
<keescook> slangasek, mathiaz: apparmor uploaded.
<mathiaz> keescook: thanks ! :)
<keescook> mathiaz: you bet, thanks for the reminder.  :)
<soren> Could someone clarify the backports policy for me? Can I - as a member of core-dev - upload stuff to -backports without asking anyone's permission?
<soren> https://wiki.ubuntu.com/BackportRequestProcess
<ScottK> JFTR, he has permission from an ubuntu-backporters member (me).
<soren> Sure. This was meant as a general question.
<ScottK> Understand.
<\sh> keescook, time to review some CVE fixes for the last hours of this day? :)
<keescook> \sh: you bet, I was just making my way through some bugs
<\sh> keescook, ok..I'll send the debdiffs for wzdftpd*(dapper,edgy,feisty) fixing two CVEs...just waiting for my testbuilds
<\sh> and if someone is so nice...there is a wzdftpd upload (sponsored by pkern) waiting for letting it through it fixes one remote exploit, too :)
<pochu> slangasek: liferea uploaded, FYI :-)
<slangasek> pochu: cheers
<sistpoty> slangasek: btw.: you really should become a MOTU *cough* ;)
<soren> slangasek: Are you even actually an Ubuntu member? :)
<soren> If not, that's surely the first step :)
<sistpoty> it goes hand in hand, I'd say ;)
<sistpoty> (alongside would have been better englisch, I guess)
<sistpoty> -s
<slangasek> sistpoty: on the todo list, but I sorta have a couple of important deadlines at work right now...
<slangasek> soren: yes
<sistpoty> slangasek: hehe, sure, but I'm no longer available soon enough to just wave you through though :P
<sistpoty> (damn, haven't mention that I take bribes as well *g*)
<\sh> keescook, bug #151946 ready to review
<ubotu> Launchpad bug 151946 in wzdftpd "CVE-2007-5300 remote denial of service" [Medium,Fix committed]  https://launchpad.net/bugs/151946
<\sh> good night folks
<ogra> night \sh
<keescook> \sh_away: thanks!  I'll check it out.
<unggnu> hi all
<unggnu> I think that gnome-power-manager locking settings aren't that well choosen. If you don't want to lock screen on suspend oder hibernate you have to use gconf-editor while there is a great screen saver based locking option. I have uploaded a debdiff under Bug #150777 to fix this. It would be great if this could make it to Gutsy so it is possible to set with one GUI option locking behaviour.
<ubotu> Launchpad bug 150777 in gnome-power-manager "in gutsy, screen locks on lid close even when gconf option is turned off" [Undecided,New]  https://launchpad.net/bugs/150777
<slangasek> Riddell: I don't understand the changes to the conflicts/replaces lines in the latest kde-guidance upload, this isn't mentioned in the changelog?
<slangasek> oh, file moved between packages, I see
<slangasek> Riddell: ignore me :)
#ubuntu-devel 2007-10-13
<superm1> slangasek, would you be able to release mythbuntu-control-centre before this weekend from the 'waiting for distro manager' since there won't likely be any RM's around this weekend?
<slangasek> superm1: I assumed Hobbsee would be around this weekend?
<superm1> slangasek, oh didn't know Hobbsee could release it
<superm1> don't worry then
<superm1> sorry to bother you :)
<slangasek> no worries
<xhaker> woohoo, more pictures of the first FreeSoftwareForumLisbonUbuntuPT http://picasaweb.google.com/xhaker/FirstFreeSoftwareForumLisbon
<lamont> kdeadmin _BUILD_-depends: lilo? say what?
<slangasek> keescook: ah, hmm; libpam-ldap and libnss-ldap now share /etc/ldap.conf, do they?
<keescook> slangasek: via other packages, yes
<keescook> slangasek: ldap-auth-config
<slangasek> heh, a separate package?
<slangasek> didn't trust the pam and nss packages with the job? :)
<keescook> slangasek: well, they handled things differently, were a fork from upstream, caused headaches for "regular" GUI apps that wanted the standard config method, etc
<keescook> slangasek: work was done by jdstrand and dendrobates mostly, IIRC.
<slangasek> keescook: oh, I agree that the two packages should share a config file, I just don't understand why a separate package was needed for this as opposed to fixing the existing debconf support...
* keescook is not a debconf expert :)
<keescook> slangasek: I'm sure they're be interested in a review of their work.
<mekius> We have a custom live cd and the OEM who we are dealing with wants a way to auto-install onto the drive into a finished state.  Is there anything in place at all to do this type of thing?
<mekius> Normal installation would require OEM mode, install, rum oem-config-prepare on the installed drive
<mekius> this is based on gutsy btw
<mekius> If noone here knows, can I get an email address of someone who would know anything about how to acheive this?
<Burgundavia> mekius: you are trying to install a custom iso install?
<mekius> Well it is a custom live cd based on gutsy.  We had it worked out where they would image a hard drive install, but apparently they decided that wouldn't work out at the last minute.
<Burgundavia> umm, why a live cd?
<mekius> We plan on offering a community edition of the CD as well
<Burgundavia> oh
<Burgundavia> this really isn't a great time to be searching for advice from the installers devs, as we are so close to release
<Burgundavia> try a few days after Gutsy releases
<mekius> Burgundavia: Unfortunately I only have a few days to make this work.  I guess I will need to figure out a way to script this :/
<persia> mekius: If email is good, you might also try searching the ubuntu-derivatives archives (https://lists.ubuntu.com/archives/ubuntu-derivatives/), or mailing there if there's nothing similar.
<mekius> persia: List seems a bit small
<_MMA_> mekius: 'tis. Lemmie see if I can get someone to give you some help.
<mekius> _MMA_: Sorry about the persistence, just last minute changes :P
<reitblatt> think I might have found a (reproducable) bug that keeps people from booting a new Gutsy install due to a easily fixable typo
<reitblatt> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/138325
<ubotu> Launchpad bug 138325 in initramfs-tools "Unable to mount root fs after upgrade to 2.6.22-11.32" [High,Triaged] 
<mekius> _MMA_: If everyone is busy I'd hate to be a huge bother.
<_MMA_> mekius: I PM'ed a friend. If he can help, he'll contact you.
<mekius> _MMA_: Ok, thx
<_MMA_> mekius: Please PM me your email address. Might not happen tonight but maybe tomorrow. Fate on a Friday night isnt the best time for most.
<_MMA_> s/Fate/Late
<mekius> _MMA_: Yes, it sucks for me too :)
<_MMA_> mekius: I think that what Burgundavia was getting at was, why a live disk? I think this would be pretty easy to preseed a Alt disk.
<_MMA_> s/this/it
<mekius> _MMA_: Yes I know, but by the time they even mentioned this we were far to in to it.
<_MMA_> Hopefully the amount of work required to fix your situation isnt more than needed to preseed a Alt disk.
<mekius> _MMA_: Yeah, I'm hoping the same :)
<mekius> _MMA_: I had looked a bit into the preseed stuff, but wasn't sure if this would work right.
<_MMA_> mekius: Ok. From my Googling there looks to be alot of info on it. Sorry. I have to run. I gave your info to my guy with instructions to read here. Ill tap him tomorrow as well to see if he can help. For now, I gotta run.
<mekius> _MMA_: I actually have another idea.  I can give them a DVD that contains a hard drive image of the installed system and have some software to copy this to the hard drive.  Do you know of anything that can do this sort of thing?
<mekius> i guess i could just do a dd?
<persia> mekius: I think you'll still want partitioning before dd.
<mekius> hmm, can dd capture the whole disk?
<_MMA_> persia: You should be able to also set that up. Like this maybe? http://www.hands.com/d-i
<_MMA_> Oh wait that presseded via the network.
* _MMA_ looks again.
<mekius> I think dd will work
<mekius> I could just add a menu option to gfxboot to copy the image that I have on the dvd over to the hard drive eh?
<mekius> hmm, actually :/
<mekius> the dd image will probably be the size of the hard drive won't it :/
<TheMuso> mekius: Yes
<TheMuso> mekius: Have you looked into any of the partition imaging tools available?
<TheMuso> If they can be scripted, tey may be useful.
<mekius> TheMuso: Honestly I don't know what is available :)
<mekius> TheMuso: But anything that can make a hard drive image, including MBR and such, and is the size of the data on the disk would work great :)
<TheMuso> mekius: apt-cache is your friend.
<TheMuso> apt-cache search even
<TheMuso> Or your GUI package manager of choice.
<mekius> TheMuso: I'm actually not an Ubuntu/Debian user :)
<mekius> I'm just working on a project using Ubuntu as it's base :)
<TheMuso> Ah ok.
<_MMA_> mekius: arch usually?
<mekius> _MMA_: Not sure if you mean Archlinux, but that is what I use :)
<_MMA_> Yeah.
<mekius> how did you guess?
<_MMA_> From the /whois.
<mekius> ah :)
<mekius> anyone use replicator before?
<ion_> No, but i saw them in Stargate.
<mekius> hehe
<mekius> partimage is close, but i'd have to either script install grub or dd the MBR from the installed system :/
<persia> mekius: If you can guarantee the target structure, dd MBR works
<mekius> persia: in this case it is the same hardware that I have in front of me
<mekius> persia: So I believe it would work, it just sounds like a lot of work and testing I don't have time for heh, damn :(
<persia> mekius: quick & dirty isn't always quick :(  Preseeding the alternate CD is the real solution, but it may be more difficult to show interim progress that way (more of a binary option).
<mekius> persia: Well the issue is we have modified the live cd quite a bit
<mekius> so I would need to modify the alternate in the same way and then setup the preseed as well
<mekius> How much time does it take to setup a preseed given I don't have a clue how it works :)
<mekius> Well I looked into it a bit I guess, but haven't actually used it before
<mekius> Making all our changes to the alternate cd would be pretty insane as well :/
<mekius> persia: I can see your point though
<mekius> Thanks everyone for ideas, hopefully will help me out with this :)
<mekius> persia: Can the live cd be preseeded?
* persia doesn't know
<mekius> ok
<mekius> Sounds dumb of course :)
<LaserJock> I don't think it can
<mekius> But I wonder if there is a way to boot it this way :/
<LaserJock> there's nothing to preseed I don't think
<mekius> Hmm, alright :/
<LaserJock> doesn't preseeding answer the debconf questions that come up during installation?
<TheMuso> LaserJock: Yes.
* persia thinks it can also so dpkg --set-selections
<LaserJock> so, the LiveCD doesn't do any package installation, so there's nothing for it to preseed
<mekius> https://wiki.ubuntu.com/Ubiquity/Automation
<mekius> seems there are plans
<mekius> but doesn't look like anything has been touched yet
<TheMuso> As it is, preceeding is used for {k,x,ed,gob}untu to set which desktop task to install for tasksel.
<mekius> TheMuso: That's all that works atm?
<slangasek> that's all it needs to be used for
<mekius> the link i posted said it was accepted for gutsy
<mekius> but it doesn't seem like it is
<mekius> slangasek: Given one doesn't need a live cd and an automatic install CD
<slangasek> stuff that's not flavor-specific doesn't need preseeding, because the debconf defaults get set within the package instead
<mekius> Well I need a way for them to pop in a disk and it installs within as little time as possible, but the only way to do this i guess is to make an alt cd
<mekius> which is gonna take forever
<slangasek> sorry, "make" an alt CD?  what do you need to make?
<mekius> We have modifed the live cd HEAVILY
<mekius> I mean ripped things out and replaced quite a bit
<mekius> Therefore I would need to do the same to the alt image so I can preseed it
<mekius> They asked for it too late anyway
<slangasek> ah
<mekius> most of it is packaged
<mekius> but some isn't
<mekius> due to time constraints mostly
<superm1> mekius, what are you looking to install while on the live disk install?
<superm1> during the mythbuntu install, we do install items via the live disk onto the new filesystem
<superm1> based upon selections
<mekius> Well I need an automated install
<mekius> If possible without even having to enter X
<slangasek> right, in that case it sounds to me like the Live CD was the wrong starting point for you :/
<mekius> slangasek: Well we needed a live cd for future plans, but I agree it ended up not being good now.
<mekius> slangasek: Too late now, but I guess i'll have to spend all weekend working on this shit again
<chris_punches> BANANA PHONE!
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<slangasek> !op
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<TheMuso> !ops
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
* persia wonders why it takes two seconds to spit a line.
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<mekius> sigh
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<Pici> I called !staff in -ops
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<mekius> persia: he has a lot lined up, it is only due to lag that you don't get them all at once heh
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<persia> But:  foo
<persia> foo
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<chris_punches> http://www.youtube.com/watch?v=rwvz1LNZ5OQ
<slangasek> mekius: actually, it's probably an anti-flood measure on the part of the abuser
<slangasek> er - an anti-flood countermeasure, I mean
<xjkx> If i make a custom cd just adding SOME packages and changing nothing else, do i have to change the name of the distro?
* mode/#ubuntu-devel [+o mneptok]  by ChanServ
* mode/#ubuntu-devel [+b *!*@*chrispunches*]  by mneptok
* mode/#ubuntu-devel [-o mneptok]  by mneptok
<xjkx> i'd remove packages too
<mneptok> sorry 'bout that.
<xjkx> mneptok, are you a dev? if so, what do you think?
<mneptok> xjkx: i'm not a coredev, but i play one on TV ...
<mekius> slangasek: There is an --automatic option for ubiquity
<mekius> slangasek: It says it respects the seen flag, do you know what that means?
<slangasek> mekius: debconf stores information about whether a given debconf question has been shown to the user
<mekius> ah
<joejaxx> Good Evening All
<YokoZar> I just wanted to make sure everyone is aware that UDS this year will be in the United States during Halloween.  I may or may not be dressing as a Heron.
<bddebian> heh
<r_rehashed> hi all. what's the command to set the path for a particular directory?
<persia> r_rehashed: 1) That question is hard to answer as asked, and 2) This isn't a help channel
<r_rehashed> set path=/home/... ?
<r_rehashed> persia: ok
<r_rehashed> persia: can i IM you please?
<joshin247> I'm here cause no other irc channel had anyone of significant intelligence as what is in here
<joshin247> and i have a problem
<joshin247> or not
<Kopfgeldjaeger> hi
<seb128> does anybody else get network issue to the ubuntu domain?
<ogra> seb128, i had some timeouts on help.u.c
<Burgundavia> fridge has been giving me some timeouts as well
<StevenK> seb128: Yeah, I can't reach launchpad
<bluekuja> had problems with planet as well
* Hobbsee waves
<pochu> heya Hobbsee
* Hobbsee ponders actually doing this interview
<blubblablub> please help me: http://www.pennergame.de/ref.php?refid=9290332
<Hobbsee> holy cow, why must people be idiots.
<persia> Hobbsee: consider it a compensatory control to reduce the quantity of mad scientists.
<Hobbsee> persia: was thinking of the spammer earlier
<Hobbsee> nice timing, ompaul
<ompaul> Hobbsee, ;-)
<Hobbsee> ompaul: any chance i could abuse your staff privs?
<ompaul> Hobbsee, pm
<Hobbsee> superm1: i cant approve things in current status, btw.
<Hobbsee> superm1: revert that :)
<superm1> huh?
<superm1> Hobbsee, revert which?
<Hobbsee> [23:37]  <Hobbsee> superm1: i cant approve things in current status, btw.
<superm1> Hobbsee, oh you can?
<Hobbsee> i can now, yes
<superm1> Hobbsee, okay cool.  well i'm going to have one more control centre upload to work around a bug that was just discovered this morning, and i should be done uploading for the gutsy cycle then :)
<Hobbsee> oh, meh.  just after i accepted yours tuff, too :)
<superm1> haha.
<superm1> these users, they gotta report these things sooner!
<Hobbsee> hehe
<coastGNU> [Bug 152243]  It seems that there is a bug in linux-ubuntu-modules-2.6.22-14 I would judge as a grave bug.
<ubotu> Launchpad bug 152243 in linux-ubuntu-modules-2.6.22 "prism p54pci broken in 2.6.22-14" [Undecided,New]  https://launchpad.net/bugs/152243
<mjg59> coastGNU: That doesn't look immediately like a fatal issue. What's the actual problem?
<coastGNU> mjg59: Due to this bug a p54g card will only be recognized as wlan0_renamed. This long name is shortened to wlan0_ren and by this you can't establisch a conection to a wlan anymore. networkmanager and wicd also don't support such long names fr NICs. And what is more fatal the name of the card is shortened to wlan0_ren in /etc/network/interfaces.
<coastGNU> mjg59: So all users who bought eg. a WG511-V3 because it's a prism based card and don't need ndiswrapper are lost here.
<Hobbsee> coastGNU: anyone who bought a netgear card is a muppet anyway.
<coastGNU> mjg59: There is an old bugreport [bug #144079]  which looks quite the same.
<ubotu> Launchpad bug 144079 in linux-ubuntu-modules-2.6.22 "[gutsy]  2.6.22-12 breaks rt2x00 driver with rt2500 based card" [High,Fix released]  https://launchpad.net/bugs/144079
<Hobbsee> because they like changing their chipsets at random, and have very, very sucky drivers.
<Hobbsee> but for all other prism-based cards...
<coastGNU> Hobbsee: Not those who buy a WG511-V3, it's a prism GT card
<Hobbsee> and the v2's were either marvell or prism.
<Hobbsee> which is just a pain.
<coastGNU> Hobbsee: Yes, know this, I'm in the Hardware buisiness...
<Hobbsee> they're all prism, until netgear has a brilliant idea to change the chipset without changing the revision number, or any of the other info.
<Hobbsee> (grrr)
<coastGNU> Hobbsee: But SMC does the same, so who to blame...
<nixternal> my PrismII works just fine, but I prefer the Orinoco based cards
* Hobbsee wonders who smc is
* Hobbsee hasnt ended up picking up a smc card.
<mjg59> coastGNU: No, it doesn't look the same. What's the actual problem you're having?
<coastGNU> Nicke: Orinoco based cards for beyond 802.11g? (54MBit and higher bandwith)
<mjg59> The name is entirely unrelated to that issue, as far as I can tell
<coastGNU> mjg59: have a look to the attachment I made to the bugreport
<mjg59> coastGNU: Yes. I don't see what that has to do with the problem you're describing.
<mjg59> As is, you've attached a log which shows some errors and then a working driver
<coastGNU> mjg59: I didn't mention the maming problems, sorry
<coastGNU> mjg59: s/maming/naming/g
<mjg59> The naming problem looks completely unrelated to that
<coastGNU> mjg59: But after blacklisting p54g it's gone, the naming problem.
<mjg59> coastGNU: I've seen cases where p54pci and prism54 pick different mac addresses
<coastGNU> mjg59: Different MAC? *Thats weird* indeed, I'l have a look at this.
<mjg59> coastGNU: Try looking at /etc/udev/rules.d/70-persistent-net.rules
<coastGNU> mjg59: Holla, youre right! The mac in pers.-net.rules for eth0 is wrong but ifconfig eth0 shows the right MAC
<coastGNU> mjg59: What is irritating to me, there are rules for prism54 but not for p54pci
<mjg59> coastGNU: The rules are generated on the fly
<coastGNU> mjg59: So "You can modify it, ..." only takes effect till the next boot? My interpretation was that the rule lines are persistend and every new device will bring a new line?
<mjg59> That's the idea. It's clearly confused for some reason. Try just nuking all the entries.
<coastGNU> mjg59: hhhm, so by doint so you would say there is a chance that this nasty maning problem will disappear?
<mjg59> It's more likely to be connected to that than the errors you're seeing
<coastGNU> mjg59: s/maning/Naming/g
<sladen> coastGNU: debugging... trying will help find out
<coastGNU> sladen: Right, was more a rethoric question... pardon me
<Mirv> mjg59: hi, dunno if you have any time to continue on bug 86666 (vbe trace was added 1st of Sep), it has somehow gotten even worse since the crash happens now even when using vga= parameter
<Mirv> ubotu timed out... https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/86666
<RichW> Do ubuntu accept gpl v3 applications into their repositorys?
<ScottK> Yes.
<RichW> Thanks
<rohan> the problem of volume control using laptop keys bouncing between 0% and 11% on intel HDA cards - someone told me it is already known. has a bug been filed where i can help out ? or do i file a bug ?
<albertito> hi! I think I found a bug in bash_3.2-0ubuntu11_amd64.deb, or at least a regression from ubuntu7. My suspect is upstream patch 20, but I can't confirm it yet (it just look suspicious, but it may also be some other change in ubuntu8 to 10)
<albertito> Where can I get the .deb for all those missing versions (ubuntu8 to 10) so I can bisect which one is the culprit?
<rohan> albertito: archive.ubuntu.com
<rohan> it might have the older version on the mirror, not deleted
<albertito> the bug is triggered by the main bash completion script. At the beginning, it tries to set a read only variable, which should just fail and keep on going. But in ubuntu11, it's interrupting the scripts' flow. That means not only bash_completion doesn't run, but also my .bashrc stops after doing . /etc/bash_completion
<albertito> rohan: thanks, I'll look in there
<albertito> rohan: no luck :S just ubuntu7 and ubuntu11
<rohan> albertito: hmm.. strange. bash-completion is working perfectly here
<albertito> rohan: are you sure it's reloading it properly? it works the first time because the variable is not read only yet. But if you do source /etc/bash_completion, it _seems_ to work, but actually doesn't run to completion
<albertito> rohan: I'll try to create a simpler test case
<rohan> albertito: tell me what exactly to do ? source /etc/bash_completion after it's already done once ?
<pochu> albertito: you can find them in launchpad
<albertito> rohan, pochu: ok, I've got a testcase: http://pastebin.com/m28350bdd
<albertito> let's say you put that in a bug-tc.sh file (no need for it to be +x)
<albertito> on ubuntu7, it runs up to completion (it manages to echo 3)
<albertito> on ubuntu11, it doesn't and stops before echo 2, after trying to set the  variable
<rohan> albertito: no, here i get output till 3
<albertito> well, I forgot the important part: you do source bug-tc.sh once, it should work in both 7 and 11. You do it again, and 7 works but 11 fails
<albertito> rohan: what bash version?
<albertito> rohan: try a second time in the same bash session
<rohan> i tried 4 times
<rohan> ubuntu11
<rohan> bash:
<rohan>   Installed: 3.2-0ubuntu11
<albertito> rohan: ok, that's weird. You're using "source" to run it, right?
<rohan> no
<rohan> ./
<rohan> albertito: aha, now i get the bug
<rohan> first time it runs till 3, not 2nd time onwards
<albertito> rohan: ok, the bug shows up whith source, that's the whole problem (and why it matters for bash_completion)
<albertito> rohan: glad to hear, I was about to reboot for a memtest86 =)
<rohan> albertito: hehe ;)
<albertito> rohan: well, that same thing happens on the bash_completion, at the beginning, you can see the same { ... } || . trick
* Chipzz has some problems with bash_completion too...
<Chipzz> but different kind
<rohan> albertito: ok, but here bash_completion seems to be working fine
<albertito> rohan: it doesn't _say_ anything, but it won't work. That shows up when I modify my .bashrc _after_ loading the bash completion, and it dies. If you do an echo after the . /etc/bash_completion, it will run when you open a shell, but not when you reload the bashrc with . ~/.bashrc
<albertito> rohan: that's because it worked the first time, when the shell opened
<rohan> but doing source /etc/bash_completion doesn't give any errors
<albertito> rohan: if you try to reload it, not only it won't run, but it will also stop the script that's running it (in my case .bashrc)
<albertito> rohan: it doesn't
<rohan> oh, it silently fails ?
<albertito> rohan: try this: put an echo 1 after the ". /etc/bash_completion" in your .bashrc
<albertito> rohan: start a shell, you will see the 1. Then run source .bashrc, you won't see it
<albertito> rohan: yes, it fails silently
<rohan> yes, albertito , the problem occurs exactly as you told
<albertito> rohan: thanks for the confirmation =)
<rohan> albertito: once you file a bug, please give me the url. i'll confirm it :)
<albertito> rohan: I wanted to see which bash version was it, so I can report it properly, but I can't find the deb packages for ubuntu8 to 10
<rohan> hang on, i think i know
<albertito> rohan: well, it's already reported :S https://bugs.launchpad.net/ubuntu/+source/bash/+bug/149527
<ubotu> Launchpad bug 149527 in bash ".profile not sourced anymore" [High,New] 
<rohan> albertito: have a look https://bugs.launchpad.net/ubuntu/+source/bash/3.2-0ubuntu11
<rohan> albertito: ok, how about adding your test case ?
<rohan> albertito: also look at https://bugs.launchpad.net/ubuntu/+source/bash/3.2-0ubuntu8
<albertito> rohan: I will do that. Thanks a lot!
<rohan> albertito: i think ubuntu8 was never released as a deb
<albertito> rohan: great, there are the .debs, I'll bisect and report that along with the testcase
<rohan> oh, where did you find the ubuntu8 debs ? i couldn't find them :-/
<albertito> rohan: but there's the .dsc, the diff and the tar.gz, that's enough for me to build a package
<rohan> ah yes
<albertito> rohan: well, here are the resulting binaries: https://bugs.launchpad.net/ubuntu/+source/bash/3.2-0ubuntu10/+build/400201
<albertito> rohan: https://bugs.launchpad.net/ubuntu/gutsy/i386/bash/3.2-0ubuntu10
<albertito> rohan: I guess there must be .debs also for the other ones who got built
<rohan> yes, but methinks ubuntu8 9 never got built
<albertito> rohan: both are there: https://bugs.launchpad.net/ubuntu/gutsy/i386/bash/3.2-0ubuntu8 and 9
<rohan> yes, but the resulting binaries for i386 ?
<albertito> rohan: maybe they were never uploaded to the repositories or something like that? (I'm not very keen on how that works)
<albertito> rohan: I see http://launchpadlibrarian.net/7683203/bash_3.2-0ubuntu8_i386.deb
<rohan> oh ok
<rohan> my observation is poor ;)
<albertito> rohan: mine is worse, I have just downloaded the i386 packages, and I need amd64 =)
<rohan> albertito: :D
<rohan> albertito: just out of curiosity, do you use snd-hda-intel ?
<albertito> rohan: ok, the bug is between 10 and 11. I'll try to remove the patch I think it's suspicious and build a new package
<albertito> rohan: I actually do
<rohan> albertito: do you experience the bug i mentioned above ?
<albertito> rohan: but I'm not using ubuntu's kernel
<rohan> i'm not using ubuntu's sound driver either
<rohan> it's a hotkeys issue
<albertito> rohan: I think I missed it, what bug?
<rohan> albertito: 00:57 < rohan> the problem of volume control using laptop keys bouncing between 0% and 11% on intel HDA cards - someone told me it is already known. has a bug been filed where i can help out ? or do i file a bug ?
<albertito> rohan: I haven't experienced it, I don't have a laptop, here it's a standard desktop system. Volume control seems to work just fine
<rohan> albertito: oh, you don't have volume control keys on the keyboard ?
<albertito> rohan: no, I don't
<rohan> oh, ok
<rohan> those keys are the problem. volume control is otherwise fine
<albertito> rohan: sorry, I can't confirm that :S I have a normal siemens keyboard here, no fancy keys
<rohan> ok :-s
<rohan> ok, the bug is filed at https://bugs.launchpad.net/ubuntu/+bug/152286
<ubotu> Launchpad bug 152286 in ubuntu "Gusty Beta update stopped laptop Fn Volume Control" [Undecided,New] 
<albertito> well, I was right about the patch, the 20 was the culprit. I'll post in the bash bug
<rohan> albertito: cool :)
<albertito> rohan: thanks a lot =)
<adam0509> do someone know where to send a mail to the Self-Appointed Benevolent Dictator for Life ?? (mark shuttleworth of course) ?
<Mithrandir> adam0509: https://edge.launchpad.net/~sabdfl says mark@canonical.com.
<adam0509> thank u
<albertito> rohan: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/149527/comments/5
<ubotu> Launchpad bug 149527 in bash ".profile not sourced anymore" [High,New] 
<ScottK> Mithrandir: If you're up for accepting packages, I'd appreciate it if you would accept mergeant and griffith.
<rohan> albertito: cool :)
<rohan> albertito: let's wait for someone to reply now
<albertito> rohan: let's hope so. Thanks a lot for all your help!
<Mithrandir> ScottK: accepted
<rohan> albertito: hardly any, i must say :D
<ScottK> Mithrandir: Thanks.
<CarlFK> week ago installed gutsy daily build. just clicked on 'install updates" - installed a bunch.  when done, I rebooted.  it shut down, started up and dropped me to a root prompt.
<CarlFK> no networking, only one VT
<CarlFK> anyone want anything from the box before I nuke it?
<neh> CarlFK: I have a machine that has no networking in gutsy, not sure if it's the same problem as yours. I filed a bug though: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/151815
<ubotu> Launchpad bug 151815 in linux-meta "No functional network devices" [Undecided,New] 
<janimo> a release manager please approve the xubuntu-default-settings upload: it removes a buggy plugin from the default panel. thanks
<Creteil> hi all
<slangasek> TheMuso: what's going on with espeak?  pitti asked for the package to be uploaded, no one seems to have done this yet?
<Creteil> i have generated a new kernel package with CFS, now when i use it, i have 4 modules that does not load saying "disagrees about version of symbol struct_module"
<Creteil> the 4 modules that does not load are : apparmor, snd_hda_intel, iwlwifi_mac80211 & iwl3945
<albertito> Creteil: did you rebuilt your modules using the new kernel?
<mjg59> Creteil: They're built from a different package
<mjg59> You need to rebuild linux-ubuntu-modules as well
<Creteil> albertito : i have booted on the new kernel and then recompiled the linux-ubuntu-modules, installed it, rebooted and error message stay ...
<TheMuso> slangasek: I know. Since I don't have a regular core dev to work with, I subscribed ubuntu-main-sponsors to get it uploaded by someone.
<mjg59> Creteil: Then you haven't built linux-ubuntu-modules against the correct kernel headers
<Creteil> oh, maybe I have found my error, let me explain and you can confirm if it was my mistake ...
<Creteil> mjg59 : I think it's exactly the problem, but let me explain in details
<Creteil> after rebuilding kernel, I have obtained 3 packages (kernel, kernel-dbg & headers)
<Creteil> then i have 1st installed just the kernel one
<slangasek> TheMuso: ok, thanks; I'll see if I can't chase that up this weekend
<Creteil> some seconds after that, the update manager say there is 1 package to update (obviously it was the kernel)
#ubuntu-devel 2007-10-14
<Creteil> well, rebooted on the new kernel and installed the new headers package generated during kernel rebuilding and this time update manager saying there is 1 package broken
<TheMuso> slangasek: Thanks a lot.
<Creteil> so i have removed the headers package i have generated the same time i have rebuilded the kernel and compiled module with probably old headers ...
<Creteil> mjg59 : does it make sense to you ?
<mjg59> Yes
<Creteil> mjg59 : so if i understand properly i have just to reinstall the headers packages generated the same time i rebuilded the  kernel, the recompile l-u-m again this one ? true ?
<mjg59> Yes
<Creteil> thanks, i immediatly give it a try, compiling, dpkg -i the new package, rebooting and come back here to thank you :-)
<Creteil> mjg59 : btw how do you clean the already made compilation of l-u-m ?
<mjg59> fakeroot debian/rules clean
<Creteil> mjg59 : thanks
<Kopfgeldjaeger> n8
<Creteil> mjg59 : well, recompiled l-u-m against new headers, dpkg -i the new modules, now it's time to reboot, stay tuned i come back ...
<TheMuso> Hmm, interesting. I see my ubuntustudio uploads were accepted, one closing the bug, but I haven't received anything from Soyuz, so far as I've seen...
* TheMuso checks again
<TheMuso> And nothing on gutsy changes either...
<TheMuso> Ah well.
<Creteil> mjg59 : always up ?
<ScottK> TheMuso: Hobbsee was accepting via the LP web ui and there's a bug where stuff accepted via there webui forgets to get sent to changes.
<TheMuso> ScottK: Ok thanks.
<Creteil> mjg59 : bad news, even all things seems to be well (compilation, installation) the computer boot, but stay blocked at 'Starting log daemon ...' since i have installed the new modules ... however booting without splash and with vga=normal parameter, i can see iwl3945 loading properly (these one is part of the new module i have compiled).
<Creteil> mjg59 : do you have any idea on where I can made mistake ?
<Creteil> back
<TheMuso> doko_: Thanks.
<janimo> any release manager around?
<Hobbsee> yeah, some of us
<Hobbsee> janimo: ^
<janimo> Hobbsee: I read your mail to devel
<janimo> I'd like an upload approved
<Hobbsee> janimo: right
<Hobbsee> oh, i see what i've written.  i can still ask others to approve, etc.
<Hobbsee> (which i didnt stick in the mail.  damn)
<luca> hi everyone
<luca> I would like to add a hack into knetworkmanager but I do not have any programming competence whatsoever...can someone help me or tell me where to go for starting? :)
<janimo> Hobbsee: so I'd like xubuntu-default-settings which I uploaded last night to get approved
<janimo> thanks
<Hobbsee> slangasek: if you're still around...please ^
<Mithrandir> accepted
<Hobbsee> thanks Mithrandir
<sladen> luca: generally you'll need the source code (easy: apt-get source knetworkmanager) and some help and guidance (start at #kubuntu, and look around for Qt, KDE and NetworkManager related programming resources and IRC channels)
<luca> sladen thanks
<luca> I would like to add a simple hack - after suspension the program should switch to "offline mode" and then again to "online mode" - there is a known bug which makes the applet not detectin the wireless networks around otherwise
<luca> (it's knetworkmanager only - wlassistant functions after suspension without glitches)
<luca> sladen where would apt-get source put the source package?
<Hobbsee> current directory
<luca> Hobbsee thanks
<luca> now I just have to understand how to hack it :P
<luca> can someone point me to some good online qt resources please?
<Mithrandir> luca: this channel is for development of Ubuntu, not development on Ubuntu.
<luca> ok sorry :) a good channel then would be what? I am asking here because both in #kubuntu and in #kde I am not recieving answers
<pwnguin> hi luca
<luca> hi
<pwnguin> oh, luca's a common name in italy i guess. i know Debian developer with the same first name
<luca> yep it is
<pwnguin> i really dont know where qt developers lurk though. #qt maybe?
<luca> maybe
<luca> tryin in ubuntu-motu now
<luca> I'll try #qt thanks though :D
<Hobbsee> #kde-devel would be a decnt idea
<Hobbsee> no, not #ubuntu-motu
<luca> thanks :)
<Burgundavia> am I cracked or did we back away from shipping Gnash by default?
<luca> hope not
<Burgundavia> doesn't appear to be installed on my machine
<sladen> it was in the release notes
<Burgundavia> it was, which is so odd
<minghua> I don't think my beta install has gnash installed by default either.
<minghua> I also don't remember reading "gnash installed by default" in release notes.
<persia> only mozilla-plugin-gnash depends on gnash, and it doesn't appear to have any reverse dependencies excepting education-standalone
<Burgundavia> but that was the plan, I thought
<minghua> I think it's better not installed by default.
<Burgundavia> meh
<Burgundavia> has anybody noticed deskbar applet crashing and hanging a lot?
<sladen> Burgundavia: it's not a case of whether anyone else has noticed.  If *you* have experienced deskbar crashing and hanging then that is a bug and needs filing
<Burgundavia> well, I have seen a lot of general instability
<sladen> "general instablity" is about as hard as "general FUD" to fix
<Burgundavia> yes, I know that
<Burgundavia> hence why I haven't filed a bug yet
<Burgundavia> ugh, how do I run gdb on an applet?
<pochu> Burgundavia: look for the process, and attach it
<pochu> gdb --pid=number
<Burgundavia> got it
<Burgundavia> typical. Just when I get the dbgsym package installs, I cannot replicate the crash
<ogra> pitti, !
<pitti> hi
<Burgundavia> hey ogra
<Burgundavia> hey pitti
<ogra> pitti, i'm doing the last fine tuning on g-p-m settings ... there is an option to lock the gnome keyring after suspend/hibernate (we already lock the screen) should that be on or off ?
<ogra> s/after/before/
<ogra> (its a new option)
<StevenK> Morning pitti
<k0001> hello people =)
<pitti> hi StevenK
<k0001> i have a little problems, and i'd like to know how can i help you
<pitti> ogra: what's the upstream default?
<ogra> upstream default is to use screensaver settings for all locking
<ogra> we dont do that, which means i have four more fine grained options to set
<pitti> that makes some sense
<ogra> i dont think g-s-s does any geyring locking
<ogra> *keyring :)
<k0001> my nautilus keep dying randomly (sometimes after 5 minutes, sometimes after 1 hour) when browsing a ssh remote server, and i have to manually `pkill nautilus` so that it gets fully functional again, how can i help with this? (using up-to-date ubuntu gutsy (gnome 2.20))
<ogra> k0001, file a bug
<pitti> meh, palmer is dead
<ogra> or comment on an existing one if someone already had the same prob
<Burgundavia> pitti: I am running into a nasty bug with deskbar, apparently seen by others by so far impossible to trace source: https://bugs.edge.launchpad.net/ubuntu/+source/deskbar-applet/+bug/150559
<ubotu> Launchpad bug 150559 in deskbar-applet "[gutsy]  deskbar applet locks up during first search after startup" [Medium,Incomplete] 
<k0001> ogra, and what useful information could i provide  (for debugging or whatever )
<k0001> ?
<ogra> the people getting the bugmail for nautilus will tell you :)
<k0001> ok ogra , thanks =)
<ogra> there are some wiki pages about debugging program crashes as well with some hints :)
<persia> k0001: You'll probably get better answers to questions about correct information for a bug in #ubuntu-bugs.
<k0001> oh, thanks persia , i'll ask there then
<k0001> keep the good work =)
<Burgundavia> about the start hammering away at the reason, but I wonder if I can find the cause, how do I tag it for a release manager to look at?
<rulus> Hi, my pc boots incredibly slow except when I press ctrl+alt+f1 upon boot. Can this be a usplash bug (usplash doesn't work either)? Both problems occur on the RC, beta worked fine.
<ogra> does anyone else have suid warnings fron gtk in his ~/.xsession-errors ?
* ogra wonders where they come from
<Kmos> ogra: I've :)
<Kmos> http://pastebin.com/d7fe6f5b3
<Kmos> ogra: http://pastebin.com/d7fe6f5b3
<ogra> Kmos, thanks
* ogra thought it was xgl related ... but apparently you dont have xgl or compiz running there
<Kmos> ogra: nop.. only metacity =) my video card doesn't support compiz
<ogra> looks like something that even starts before the gdm session
<Kmos> exactly
<Kmos> because the process isn't running anymore
<Kmos> there is a way to see what process was in a PID ?
<Kmos> kmos      4838  0.0  0.6  26760  6960 ?        Ssl  10:15   0:00 x-session-manager
<Kmos> root      4940  0.0  0.4   6288  4364 ?        S    10:15   0:00 ddclient - sleeping for 140 seconds
<Kmos> i've only that, it's somethingin the middle
<Kmos> *something
<Kmos> another thing
<Kmos> Oct 14 10:32:29 kmos ntpd_initres[5562] : ntpd returns a permission denied error!
<Kmos> at syslog
<ogra> hmm
<Kmos> check if you've the same
<ogra> well, even then, how should htpd use gtk ?
<ogra> its gtk thats complaining
<ogra> *ntpd
<Kmos> it's another error
<Kmos> not related to gtk
<ogra> i dont run ntpd anyway
<Kmos> i need to check LP
<ogra> Oct 14 11:30:55 laptop ntpdate[5981] : step time server 91.189.94.145 offset -6.676236 sec
<ogra> Oct 14 11:33:29 laptop ntpdate[6234] : adjust time server 91.189.94.145 offset -0.006585 sec
<Kmos> it's nice
<ogra> ntpdate works fine here though
<ogra> (its executed automatically on ifup if you dont have ntpd installed)
<unggnu> hi all
<unggnu> Does it make sense to mark all the i810 driver resolution and external monitor bugs as a duplicate of this one bug #13514
<ubotu> Launchpad bug 13514 in linux-source-2.6.15 "No keyboard with 2.6.10-4-386-SMP (Hoary)" [Medium,Invalid]  https://launchpad.net/bugs/13514
<unggnu> ups sorry, wrong bug
<unggnu> bug #135141
<ubotu> Launchpad bug 135141 in xorg "Gutsy: Intel should be preferred over 810" [High,Fix released]  https://launchpad.net/bugs/135141
<ogra> so, its apparently the capp to gdmflexiserver in /etc/gdm/PreSession/Default thats causing the setuid warning
<ogra> *call
<ogra> which is weird, since gdmflexiserver actually isnt suid
<Kmos> ogra: that's strange..
<ogra> Kmos, Bug #152577
<ubotu> Launchpad bug 152577 in gdm "call to gdmflexiserver in /etc/gdm/PreSession/Default causes gtk setuid warning" [Undecided,New]  https://launchpad.net/bugs/152577
<Kmos> ogra: nice
<ogra> feel free to confirm if you can reproduce
<Kmos> ogra: i set it also to medium
<Kmos> /etc/X11/Xsession.d/40guidance-displayconfig_restore: 11: /usr/bin/displayconfig-restore: not found
<Kmos> this isn't a problem os displaygtk-config ?
<Kmos> *of
<ogra> Kmos, so can you confirm it goes away if you comment the two commands ?
<ogra> (you didnt say that in the bug comment)
<Kmos> ogra: i need to restart X, i'll do it later
<Kmos> kmos@bash:~$ dpkg -l /usr/bin/displayconfig-restore
<Kmos> No packages found matching /usr/bin/displayconfig-restore.
<ogra> its in displayconfig-gtk (which you probably dont have installed)
<Kmos> the problem is that i've it installed
<Kmos> :)
<Kmos> displayconfig-gtk is already the newest version.
<mjg59> Kmos: -S
<Kmos> kmos@bash:~$ dpkg -S /usr/bin/displayconfig-restore
<Kmos> dpkg: /usr/bin/displayconfig-restore not found.
<Kmos> ok
<mjg59> Anyway, it's an issue with guidance-backends
<mjg59> Probably harmless
<ogra> its from kde-guidance :P
<ogra> (/usr/bin/displayconfig-restore)
<ogra> well, it could need a 2>/dev/null or so to be quiet
<ogra> in the session script
<ogra> mjg59, since i have you here, any opinion on locking gnome-keyring during hibernate/suspend ? g-p-m offers that now
<mjg59> I have no opinion on it
<mjg59> I suspect that changing it now would be too late
<ogra> well, changes can go in until tomorrow ... and its a trivial gconf default key change
<mjg59> But we have no idea how it interacts with the user experience
<ogra> i need to turn off locking on blank by default anyway (apparently thats an upstream default now and g-p-m sees brightness changes as screen blanking)
<ogra> well, it will pop up a gnome-keyring PW dialog directly after you unlocked the screen after suspend/hibernate
<ogra> i think we should disable it since we already go with the locking by default
<mjg59> I think it's too late to change it
<ogra> ok
<Dekans|screen> hey
<Dekans|screen> I have a little trouble
<Dekans|screen> it seems that nvidia-glx depends on i386 kernel on Gutsy
<ogra> then i'll only set the /apps/gnome-power-manager/lock/blank_screen key to false ...
<mjg59> Dekans|screen: No it doesn't
<Dekans|screen> et restricted-manager(-kde) requires the i386 kernel too
<Dekans|screen> yesterday it was the case
<mjg59> No it wasn't
<Hobbsee> uh, no it doesnt.
<ogra> it depends on nvidia-kernel-1.0.9639
<ogra> which is provided by any of the linux-restricted-modules-2.6.22-14- packages
<Dekans|screen> I couldn't launch restricted-manager, because of my kernel
<Dekans|screen> and when i installed nvidia-glx, i had i386 kernel installed
<Dekans|screen> and no 3D acceleration on i686 kernel
<Dekans|screen> look :
<Dekans|screen> ~$ install nvidia-glx
<Dekans|screen> Les NOUVEAUX paquets suivants seront installs:
<Dekans|screen> linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 nvidia-glx nvidia-kernel-common
<ogra> try that: "sudo apt-get install nvidia-glx linux"
<Dekans|screen> Les NOUVEAUX paquets suivants seront installs:
<Dekans|screen>   linux linux-image-2.6.22-14-386 linux-restricted-modules linux-restricted-modules-2.6.22-14-386 linux-restricted-modules-2.6.22-14-generic linux-restricted-modules-generic
<Dekans|screen>   nvidia-glx nvidia-kernel-common
<Dekans|screen> the same :/
<ogra> no, it installes the right modules (-generic flavor) alongside
<Dekans|screen> yes but the -386 shouldn't be installed
<Hobbsee> sarah@LongPointyStick:~$ rdepends linux-restricted-modules-386
<Hobbsee> linux-restricted-modules-386
<Hobbsee> Reverse Depends:
<Hobbsee>   restricted-manager-core
<Hobbsee>   linux-386
<Hobbsee> ...interesting?
<ogra> mjg59, i noticed matthiaz had the ssame prob with the apparmor modules ... if linux and l-r-m isnt installed they somehow pick -386 as their first option
<Dekans|screen> okay
<Dekans|screen> so l-r-m must be installed first
<ogra> restricted-manager-core --> Recommends: linux-restricted-modules-generic | linux-restricted-modules-386
<ogra> Hobbsee, thas fine
<Hobbsee> ogra: ah yes, just found that.
<Hobbsee> ogra: are linux and l-r-m virtual packages, or actual packages?
<ogra> dont get tricked by the rdepends option (ask colin how often he corrected me on that :P )
<Hobbsee> oh, i was still getting back to that bit :)
<ogra> linux-restricted-modules-generic/-386 are virtual, yes
<ogra> linux-restricted-modules-2.6.22-14-* arent ...
<Dekans|screen> i test it
<ogra> Dekans|screen, just uninstall linux-image-2.6.22-14-386 and linux-restricted-modules-2.6.22-14-386 afterwards
<Hobbsee> Dekans|screen: i cant reproduce this - using a -generic kernel, and isntalling nvidia-glx
<Hobbsee> Dekans|screen: what version of nvidia-glx?
<ogra> Hobbsee, but you have the linux package installed i suspect
<ogra> (before even trying)
<Hobbsee> ogra: nope.
<ogra> oh
<ogra> intresting
<Dekans|screen> Hobbsee: 9639
<Hobbsee> ?
<Dekans|screen> without -386 packages X server doesn't run
<Dekans|screen> Hobbsee: nvidia-glx is the 9639 version of nvidia driver
<ogra> thats the recent one
<ogra> Dekans|screen, the complete version sting would be more helpful though
<Dekans|screen> yes sure :p
<ogra> dpkg -l nvidia-glx
<Dekans|screen> 1/1.0.9639+2.6.22.4-14.8
<Dekans|screen> 1:1.0.9639+2.6.22.4-14.8
<ogra> yeah thats current
<Dekans|screen> it's what i said
<Dekans|screen> no 3D acceleration on generic kernel
<Dekans|screen> :(
<Dekans|screen> i don't wanna install the 386 one
<Dekans|screen> so there is a real dependency problem
<ogra> so you have a system with plain -generic now ? no -386 bits there ?
<ogra> (but l-r-m-generic installed)
<Dekans|screen> no -386
<Dekans|screen> and l-r-m installed
<Dekans|screen> all -generic
<Dekans|screen> and nvidia-glx installed succesfully
<Dekans|screen> but X server doesn't load
<ogra> and if you reboot to -generic it doesnt work ??
<Dekans|screen> i am on -generic
<Dekans|screen> i have jsute the -generic kernel
<Dekans|screen> and I just rebooted
<Kopfgeldjaeger> hi
<Hobbsee> hiya
<ogra> hmm
<ogra> ogra@laptop:~$ uname -a
<ogra> Linux laptop 2.6.22-14-generic #1 SMP Wed Oct 10 06:00:47 GMT 2007 i686 GNU/Linux
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 nvidia-kernel-common
<ogra> seems i can reproduce that ...
<ogra> especially odd is:
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx linux
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   linux-image-2.6.22-14-386 linux-restricted-modules linux-restricted-modules-2.6.22-14-386 linux-restricted-modules-2.6.22-14-generic
<ogra>   linux-restricted-modules-generic nvidia-kernel-common
<ogra> though ...
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx linux-restricted-modules-2.6.22-14-generic
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 nvidia-kernel-common
<ogra> seems fine
<ogra> err
<Dekans|screen> fine ?
<ogra> no, i'm blind
<Dekans|screen> but i you install l-r-m -generic
<Dekans|screen> nvidia-glx no requires -386 pacakges for installation
<ogra> no, it doesnt
<ogra> as several people told you now
<Dekans|screen> but it's still unusable on -generic kernel :/
<ogra> it depends on nvidia-kernel-1.0.9639 (which is provided by all l-r-m packages)
<Dekans|screen> but it doesn't work
<Hobbsee> ogra: oh, well there's the bug then.
<ogra> Hobbsee, where ? i dont see it yet
<Hobbsee> ogra: if it depends on a provided package, it'll pick the first lot of all of them, rather than the one that might be correct.
<Hobbsee> sarah@LongPointyStick:~$ search nvidia-kernel-1.0.9639
<Hobbsee> linux-restricted-modules-2.6.22-14-386 - Non-free Linux 2.6.22 modules on 386
<Hobbsee> linux-restricted-modules-2.6.22-14-generic - Non-free Linux 2.6.22 modules on x86/x86_64
<Hobbsee> linux-restricted-modules-2.6.22-14-rt - Non-free Linux 2.6.22 modules on Realtime kernel
<Hobbsee> linux-restricted-modules-2.6.22-14-xen - Non-free Linux 2.6.22 modules on Xen
<ogra> all i see is that the wrong deps are picked
<Hobbsee> exactly - and they are, because it depends on something provided by multiple packages
<mjg59> Do you have linux-generic installed?
<Hobbsee> apt isnt smart enough to figure out *which* of the ones it's provided by it should take, so takes the first.
<ogra> Hobbsee, yeah, but if i: LANG=C sudo apt-get install nvidia-glx linux ... with linux-generic installed it shouldnt pick -386
<Dekans|screen> it's not only a dependency problem
<mjg59> How are you managing to not have l-r-m installed if you have linux-generic installed?
<ogra> oh, wait i have linux-image-generic, not plain -geneic
<mjg59> Right. You're doing it wrong.
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx linux-generic
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 linux-restricted-modules-2.6.22-14-generic linux-restricted-modules-generic nvidia-kernel-common
<ogra> doesnt chaneg it
<ogra> *change
<mjg59> If linux-generic is installed, is it happy? If not, there's an issue with the l-r-m generic package.
<ogra> you mean if its there before installing nvidia-glx ?
<mjg59> Yes
<ogra> well, that automatically pulls in l-r-m anyway
<Hobbsee> mine seems to behave properly - i cant reproduce the bug at all
<Hobbsee> but i've seen the similar thing with apt, where it picks the wrong language.
<ogra> the thing is that nvixia-glx seems to insist to install -386 in case there is no l-r-m-generic
<Dekans|screen> mjg59: with l-r-m generic already installed, nividia-glx doesn't require -386, but the driver doesn't works
<ogra> and i noticed the same prob with apparmor-modules
<Dekans|screen> -s
<Fujitsu> I'm not sure how that can be worked around...
<Fujitsu> You can't specify conditional dependencies like that.
<ogra> specifying linux-restricted-modules-2.6.22-14-generic or linux-restricted-modules-generic should fulfill the dep and not make it want to install -386
<ogra> looks like a package system bug to me
<ogra> Fujitsu, well, i dont package either of them :) i just stumbled across the same prob twice which made me look into it
<ogra> (i dont have any nvidia HW here :) )
<Dekans|screen> I have a nvidia Geforce 4 mx
<Dekans|screen> and nvidia-glx driver desn't work
<Hobbsee> ogra: nice use of uname -r if you can do it would be a good way to solve the bug.
<Dekans|screen> even once installed succesfully
<ogra> Hobbsee, dynamically in a dependency ?
<Dekans|screen> do you read me ?
<Hobbsee> ogra: yeah.  but i dont know if it's possible, i've not tried it
<ogra> the only thing i see that working would be a postinst script or so ... seems very hackish
<Mithrandir> Hobbsee: that's certainly not possible.
<Hobbsee> Dekans|screen: that's then a different issue, and we dont tend to be the X people.
<Hobbsee> Mithrandir: fair enough.
<Hobbsee> it was certainly there with the (if you can do it) - because i wasnt sure it was possible.
<ogra> Dekans|screen, i'm mainly intrested in the dependency thing sorry, no X help here
<Mithrandir> ogra: it probably works if you do apt-get install linux-generic nvidia-glx?
<ogra> Mithrandir, nope
<Dekans|screen> maybe the dependencies are due to this problem ....
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx linux-generic
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 linux-restricted-modules-2.6.22-14-generic linux-restricted-modules-generic nvidia-kernel-common
<ogra> Suggested packages:
<ogra> Mithrandir, ^^^^
<mjg59> Dekans|screen: No. If you have linux-generic installed (which you should do) there are no dependency issues.
<ogra> and no, there is no -386 package anywhere on my system ... neither a half installed one or so
<Dekans|screen> mjg59: yes :/
<mjg59> So any problems you may have with it not working are unrelated to dependencies
<Dekans|screen> the package itself is buggy
<Dekans|screen> this bug is already on launchpad
<Dekans|screen> but not the dependency issue
<ogra> that seems to affect more than only nvidia-glx
<Hobbsee> ogra: the mashed deps?
<ogra> yeah
<Hobbsee> ogra: yeah, there was a bug about it about sword always being in arabic by default.
<ogra> bug 148586
<ubotu> Launchpad bug 148586 in apparmor "Depends on linux-ubuntu-modules-386" [Medium,Incomplete]  https://launchpad.net/bugs/148586
<ogra> same issue it seems
<Hobbsee> or maybe it was bibletime
<Hobbsee> yup, found it.  https://bugs.edge.launchpad.net/ubuntu/+source/bibletime/+bug/72116
<ubotu> Launchpad bug 72116 in bibletime "Bibletime installation defaults in Arabic" [Undecided,Fix released] 
<ogra> thats edgy ?
<Hobbsee> likely.  it probably was that long ago
<Hobbsee> i fixed that in feisty, but didnt fix the underlying problem in apt.
* ogra somehow misses the relation to l-r-m 
<ogra> oh, ah
<ogra> ok
<Hobbsee> now you see?
<ogra> i should read the bug forst :)
<ogra> *firts
<ogra> bah
<Hobbsee> The recommends are sword-comm, sword-dict and sword-text, which are virtual packages which can be provided by several different packages.
<Hobbsee> There are 14 different packages that provide the sword-text component: http://packages.ubuntu.com/edgy/virtual/sword-text
<Hobbsee> the first is the arabic, so apt selects the arabic, in brain-dead fashion.
<Hobbsee> same with l-r-m, as the i386 comes first
<ogra> well, the language pack should care for that ... as in our case with l-r-m should be handled by linux-generic as mjg59 says
<Hobbsee> i'd guess that the nvidia thing goes l-r-m-i386 | -generic | -rt | -xen.
<ogra> well, the bug here is that linux-restricted-modules-2.6.22-14-generic fulfills the dep
<Hobbsee> oh indeed, but i think it tries the -i386 first
<ogra> so  apt-get install nvidia-glx linux-restricted-modules-2.6.22-14-generic shouldnt demand -386 at all
<Hobbsee> says "oh, that's not installed, try that before anything else"
<ogra> WOAH
<ogra> !!!
<Hobbsee> it works here, but i havent been able to reproduce the bug at all :)
* ogra cant belive it
<Hobbsee> woah what?
<Hobbsee> what'd you find?
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install nvidia-glx linux-restricted-modules-2.6.22-14-generic
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   linux-image-2.6.22-14-386 linux-restricted-modules-2.6.22-14-386 nvidia-kernel-common
<ogra> versus .....
<ogra> ogra@laptop:~$ LANG=C sudo apt-get install linux-restricted-modules-2.6.22-14-generic nvidia-glx
<ogra> Reading package lists... Done
<ogra> Building dependency tree
<ogra> Reading state information... Done
<ogra> The following extra packages will be installed:
<ogra>   nvidia-kernel-common
<ogra> since when does order matter here ?
<Hobbsee> does apt fill the dependancies in the order that it's done?
<ogra> it shouldnt ?
<Hobbsee> ie, package 1, do deps, package 2, add deps, ...?
<Hobbsee> would surprise me if it didnt.
* Fujitsu suspects aptitude would work better.
<Hobbsee> sometime, i want to sit down and read the entire apt/libept source, and then hopefully sanitize some of the quirks out of it.  but seeing as i dont have time for that anytime soon...
<luk_> lol
<Hobbsee> i've figured out the reasons for most of it's quirks - or at least, what they are, but i dont have the code-knowledge to go and fix them - and they tend to be hard to explain.
<ogra> i dont think it did regard the commandline order in former releases ....
<ogra> but i might be wrong (never tested that)
<Fujitsu> ogra: I doubt that would have changed recently, but I wouldn't know.
<ogra> to sad mvo isnt here
* Hobbsee notes that she has to write a mini-aptitude soon.  argh.
<Fujitsu> Hobbsee: Why?
<Hobbsee> Fujitsu: computing assignment.
<Fujitsu> Ah.
<Fujitsu> Sounds like fun.
<bluefoxicy> Does anyone have a quick-and-dirty way for me to rebuild an entire repository from scratch?
<bluefoxicy> I specifically want to rebuild main for Gutsy, or at least all packages installed when ubuntu-desktop is installed.
<bluefoxicy> My goal is to fiddle with compile flags and do boot chart tests; I want an i586 and i686 compiled base system for boot chart benching in particular
<mjg59> We're CPU-limited during boot?
<persia> bluefoxicy: `for package in $(cat ubuntu-desktop-seed) do apt-get --build install $package; done` is a very bad way to do that.
<bluefoxicy> mjg59:  No, old old argument.  And general curiousity.
<bluefoxicy> mjg59:  (disclaimer:  OpenSuSE seems to be built entirely for i586)
<mjg59> What extra instructions does i586 get you?
<bluefoxicy> hell if I know.
<mjg59> I can't see any reason why building for i586 would be preferable to building for i486
<mjg59> We optimise for 686. anyway
<Hobbsee> damned wifi kill switch
* Hobbsee wonders why it's so hard to get it to turn back on
<bluefoxicy> I know.  There's some CMOV insn on i686 specifically that apparently gets used in optimized code but I doubt it's significant
<mjg59> We support machines that don't have CMOV
<bluefoxicy> yeah I know.
<mjg59> It's an optional part of the 686 ABI
<bluefoxicy> mjg59:  I'm peeking at http://linux.1wt.eu/kernel/2.4/lkup/x86-emu/2.4/patch-2.4.25-wt2-emux86-0.3 actually to figure out what the technical difference is :)
<bluefoxicy> Besides, there's other kinds of fun stuff to do once you can rebuild ubuntu from scratch.  Like fiddle with gcc flags that tend to break things :D
<bluefoxicy> (I used to run gentoo, and reinstall 10 times a week)
<StevenK> bluefoxicy: Dig up.
<bluefoxicy> (I'm sure you can guess why)
<bluefoxicy> StevenK: ?
<StevenK> bluefoxicy: As in, "That's a nice hole you've dug yourself into." :-)
<bluefoxicy> StevenK:  why?  I like fiddling with things and seeing what comes out.
<sladen> rulus: what's the bug number?
<unggnu> hi all
<unggnu> What do you think about this Bug #150777 according security.
<ubotu> Launchpad bug 150777 in gnome-power-manager "in gutsy, screen locks on lid close even when gconf option is turned off" [Undecided,Confirmed]  https://launchpad.net/bugs/150777
<unggnu> Maybe screensaver locking should be activated per default so it would give same security like before but more flexibility.
<Hobbsee> it's not a decision to be made at this point of the release cycle, that's for certain.
<unggnu> :(
<unggnu> It is not a huge change.
<Hobbsee> unuggu: that patch is a major change in the default security policy (no locking for anybody instead of locking for everybody after suspend/hibernate), please discuss such massive changes with the security people via the ubuntu-devel-discuss or ubuntu-devel lists first.
<unggnu> And Feisty needs gconf-editor changes too
<Hobbsee> and it's not a milestoned bug
<Hobbsee> !timebasedreleases
<ubotu> Ubuntu releases a new version every 6 months. Each version is supported for 18 months to 5 years. More info at http://www.ubuntu.com/ubuntu/releases & http://wiki.ubuntu.com/TimeBasedReleases
<unggnu> Hobbsee, If screen saver locking is activated per default there is no different behavior.
<unggnu> but Ok, embarrassing but easy to fix for people who know where to edit gconf
<Hobbsee> this is not the mailing list, btw.
<Hobbsee> you were told what to do
<highvoltage> is Gobuntu shipping with IceWeasel and IceDove?
<Hobbsee> good question.  does #gobuntu know?
<highvoltage> Hobbsee: currently, it seems that I AM #gobuntu :)
<Hobbsee> oh, so it probably doesnt exist.
<highvoltage> Hobbsee: looking at the gobuntu-desktop metapackage, it seems that it is still firefox and thunderbird
<Hobbsee> i thought there was an irc channel for it
<highvoltage> Hobbsee: also, I can't find iceweasel and icedove in the ubuntu archives :/
<Hobbsee> yes, i suspect they're not ther
<Hobbsee> i'm unsure of the status of gobuntu - perhaps ask on their mailing list
<highvoltage> Hobbsee: seems like the first version of Gobuntu will have FF and TB then
<highvoltage> Hobbsee: I have a few weeks back, and I was told that it will be Iceweasel, etc. perhaps I should just ask again..
<Hobbsee> highvoltage: who knows if development stalled, or something.  *shrug*
<sladen> it would be a bit embarassying it Goubuntu goes out with stuff it shouldn't be doing
<highvoltage> Hobbsee: Evan comfirmed that Gobuntu will indeed be shipping on the 18th, but I think sladen might be right, I don't think Gobuntu will be shipping like we'd all want it to in this release
<unggnu> Hobbsee, done, I hope in the right way :)
<popey> :S
<highvoltage> sladen: also, you have excess vowels :)
<popey> better than having excess bowels
<highvoltage> indeed!
<Spads> word on the street is sladen is a ruminant
<highvoltage> Peter Petrelli
<highvoltage> sorry, accidental paste!
<rulus> sladen, I did not file a bug report yet
<sladen> rulus: that probably needs to be the next course of action;  anything on IRC will get scrolled off the top of the screen...
<rulus> sladen: I'm working on it
<sladen> rulus: btw, is boots incredibly slowly because it's performing a fsck?
<rulus> sladen: no I think not
<rulus> sladen: I shall attach dmesg's of both quick and slow boot
<rulus> sladen: shall I file it against usplash? because I really don't know if both problems (slow boot, no usplash) are related.
<rulus> it's bug 152643, I'll attach dmesg in a minute
<ubotu> Launchpad bug 152643 in ubuntu "[gutsy]  slow boot except when pressing ctrl+alt+f1" [Undecided,New]  https://launchpad.net/bugs/152643
<sladen> rulus: [   28.721183]  EXT3-fs: mounted filesystem with ordered data mode.     115seconds...
<rulus> I'm no expert :)
<sladen> rulus: hence ~40 seconds + 115seconds fsck == ~164 slow boot
<rulus> sladen, yes it takes 2m50s wich is 164s
<sladen> rulus: you can read off the number of seconds from the first column of the dmesgs
<sladen> rulus: they're pretty similar except for the additional 2minutes of disk check
<rulus> yes I knew that, but I didn't extract the disk checking thing
<sladen> rulus: can you try repeating the experience.  Obviviously, it would be a bug if usplash always caused a fsck
<rulus> sladen, repeating? I tested it a few times and it always boots up in ~2m50s
<rulus> sladen, except when pressing ctrl+alt+f1 that is
<sladen> rulus: could you test once more?  We know /why/ the boot can either be 40seconds, or 160seconds.  Such a direction relationship (or interaction) between fsck and usplash is a very interesting case
<rulus> sladen, ok, I'll test again
<rulus> sladen, always ~2m50s, pressing ctrl+alt+f1 seems to break the process and let boot continue immediately
<sladen> rulus: is something sitting at a prompt when you switch over
<sladen> rulus: is there anything on the console when you switch?
<rulus> sladen, yes there is, I'll check the exact text now
<rulus> sladen, 3 lines from kinit, last one says "kinit: No resume image, doing normal boot..."
<Hobbsee> guten morgen, pitti!
* pitti hugs Hobbsee and wishes her a good Monday
* Hobbsee hugs pitti back, and wishes for a monday better than the last
<stgraber> hi pitti
<pitti> Hobbsee: hey, I just returned from Sunday afternoon cake&coffee at my parent's :)
<pitti> hi stgraber
<albertito> what's the criteria for deciding if a bug gets "nominated for release"? who decides that? (I just saw that on launchpad and got curious about how that socially worked)
<Hobbsee> pitti: sounds like fun
<stgraber> ogra: I'm trying today daily builds and see that there is the "suspend" option available in the live environment, is that wanted ? (hibernate isn't there though)
<sladen> stgraber: suspend will probably work;  hibernate needs swap, boot commandlines and the like all setup
<bluekuja> pitti: around?
<bluekuja> pitti: just wanted to let you know nagios-plugins upload is a security fix and it's linked to bug #152624
<ubotu> Launchpad bug 152624 in nagios-plugins "Buffer overflow in check_http.c (CVE-2007-5198)" [Undecided,Confirmed]  https://launchpad.net/bugs/152624
<luk_> uploaded to Debian unstable earlier today...
<bluekuja> yeah, exactly
<DktrKranz> luk_, merged from that :)
<bluekuja> merged from incoming
<bluekuja> ^^
<Hobbsee> okay, who added frozen bubble?
<Hobbsee> that's seriously cool - and addicting.
<bluekuja> Hobbsee: you still cant approve?
<Hobbsee> bluekuja: technically, i can, but i've been asked not to, until one of the bugs in launchpad gets fixed.
<Hobbsee> (it's not generating mail)
<bluekuja> aww oki
<bluekuja> yeah, seen your mail
<bluekuja> on the ml before
<Hobbsee> yup
<mhb> Keybuk: sorry for not approving your post at that time, I was in a train.
<mhb> Keybuk: (your comment on my blog about hiding blueprint names)
<Keybuk> mhb: heh, wasn't worried about the approving bit - just caught me by surprise when it vanished on another machine :p
<Whoopie> Hi, with latest subversion from feisty-proposed, I get the following error: "svn: Unbekanntes URL Schema fr 'http://svn.tuxonice.net/hibernate-script/trunk'"
<Whoopie> "svn: unknown URL schema"
<Whoopie> is that a known issue?
<pochu> Whoopie: yes, it is.
<pochu> bug 152394
<ubotu> Launchpad bug 152394 in subversion "ra_dav missing in subversion" [High,In progress]  https://launchpad.net/bugs/152394
<Whoopie> pochu: ok, thanks
<pitti> kylem: still here by chance?
<kylem> yes.
<Kopfgeldjaeger> n8
<sladen> power consumption up---well at least we have a challenge for the next one
<slangasek> ogra: does this gnome-power-manager 2.20.0-0ubuntu6 upload correspond to a bug #?
#ubuntu-devel 2008-10-06
<NCommander> StevenK, ping?
<ScottK> NCommander: Would you please have a look at http://launchpadlibrarian.net/18240816/buildlog_ubuntu-intrepid-hppa.openexr_1.6.1-3_FAILEDTOBUILD.txt.gz
<ScottK> NCommander: lamont fixed glib2.0.
<NCommander> Wow, how?
<NCommander> ScottK, your not a DD, are you?
<ScottK> No
<ScottK> Need to find time to work on T&S.
<NCommander> Argh
<NCommander> I need a DD to help update my packages
<ScottK> Should be no rush unless you've got RC bug fixes for Lenny.
<NCommander> ScottK, more approaching the end of my NM process, and some of my packages have had outstanding patches for awhile
<NCommander> After three failed RFS attempts, I gave up
<NCommander> (the patches were rolled into Ubuntu however after I became active here)
<ScottK> Right.  How about openexr?
<LaserJock> we're just under FF right? no need to get every upload approved yet
<ScottK> Right.
<ion_> I wonder how to debug LP #278188?
<ubottu> Launchpad bug 278188 in linux "irda broken on Thinkpad T23 with 2.6.27-4-generic, works with 2.6.24-16-generic" [Undecided,New] https://launchpad.net/bugs/278188
<ion_> benc: You seem to have made some commits to nsc-ircc. Any thoughts?
<StevenK> NCommander: Pong
<dinx> morning
<Hobbsee> morning dinx
<dinx> :)
<pitti> Good morning
<pitti> Hobbsee: 277419 seems to have been sorted out, thanks tseliot
<Hobbsee> pitti: ah, cool!
<NCommander> wgrant, poke
<StevenK> doko: I worked on cacao, can you look over what I did?
<doko> StevenK: nice, what should I look at?
<StevenK> doko: Just want a second pair of eyes on it. http://people.ubuntu.com/~stevenk/cacao/
<doko> StevenK: do have debdiff with just the debian part and a dokg -c of the source package?
<doko> avoiding to type
<StevenK> doko: From the last package in Ubuntu (0.98-2) or Debian (0.99~rc5) ?
<doko> StevenK: the last one in Ubuntu should be ok
<StevenK> doko: http://people.ubuntu.com/~stevenk/cacao/cacao_0.99.3-0ubuntu1.debdiff
<doko> StevenK: hmm, I asszme this is the patched version in the source, isn't it?
<StevenK> doko: There's a patch needed?
<doko> ahh, ok, there are no patches
<doko> StevenK: looks fine, now you could update to the head of the 1.0.x branch ...
 * doko ducks
<doko> (http://mips.complang.tuwien.ac.at/hg/cacao/)
<sleepster> I would like to add a package to the ubuntu repository.. does it take a long time?
<doko> StevenK: preparing a source package
<doko> StevenK: http://people.ubuntu.com/~doko/tmp/cacao_0.9.4~20081006.orig.tar.gz
<lukehasnoname> ping pitti
<StevenK> doko: How is that cacao related to the 0.99.3 I downloaded?
<doko> taken from the 1.0.x branch (which will become 0.99.4)
<StevenK> Oh, so it should be 0.99.4~20081006, rather than 0.9.4
<pitti> pinging me and then disappearing?
<StevenK> doko: You'd rather use the 1.0.x branch than 0.99.3?
<lool> pitti: The trigger is committed in upstream hal
<pitti> lool: \o/ thanks, I'll merge that
<doko> StevenK: yes, as seen in the cacao-oj6 package. there will be a 0.99.4 release next week
<StevenK> doko: Can you repack the tarball? It ought to be 0.99.4... rather than 0.9.4
<doko> oops
<doko> StevenK: done
<lool> pitti: Eh it's the work of Michael, not mine
<pitti> cjwatson_: what was the  component again which is responsible for copying the jockey installed packages to the installed system?
<cjwatson> pitti: err ... jockey (debian/jockey.ubiquity)
<pitti> cjwatson: *headdesk* thanks
<pitti> cjwatson: my current woe is bug 258486
<ubottu> Launchpad bug 258486 in casper "X fall in failsafe mode after install if nvidia restricted drivers are installed during LiveCD session in intrepid" [Undecided,In progress] https://launchpad.net/bugs/258486
<pitti> cjwatson: in short, we copy nvidia-* from the live system, but not /var/lib/dkms/
<pitti> thus after booting the installed system, there are no nvidia.ko modules, and DKMS doesn't even know about them since they aren't registered
<pitti> cjwatson: so I wondered whether I should just copy /var/lib/dkms/ to the target system
<pitti> cjwatson: can I just use file copying to /target/, or is there a special command for this, like apt-install?
<pitti> if that's too messy, we can alternatively completely disable jockey on the live system again
<tkamppeter> pitti, have you seen my new CUPS BZR upload for Debian and Ubuntu? Can you put it into Debian and Intrepid? Thanks-
<pitti> tkamppeter: I got your mail, yes
<tseliot> pitti: have a look at the last 2 commits of my jockey-generic branch when you have the time
<pitti> hey tseliot, good mornign
<tseliot> morning
<pitti> tseliot: great work!
<pitti> tseliot: clicking on the details button raises AttributeError: 'KDEUI' object has no attribute 'current_driver_name'
<tseliot> pitti: do we have a test for this?
<pitti> tseliot: unfortunately not
<tseliot> pitti: maybe it's better if we discuss this in private (so as not to flood the ubuntu-devel
<pitti> right
<NCommander> pitti, I got a question you can answer
<NCommander> pitti, is it possible to retroactively bump something up to main?
<pitti> NCommander: sure, we do that all the time (called "main inclusion request"), https://wiki.ubuntu.com/MainInclusionProcess
<NCommander> For something already released?
<NCommander> (this needs a promotion in dapper, fiesty, and gutsy)
<StevenK> Hmmm
<StevenK> Not sure we can/will do that
<pitti> NCommander: nope, we won't do that
<NCommander> Argh
<NCommander> Any ideas how to fix this problem then?
<lukehasnoname> I have to say
<lukehasnoname> no, I don't have to say.. let me think about what I was going to say before I say it.
<NCommander> pitti, I personally don't care too much about it being broken in feisty or gutsy, but dapper still has two years of support left, it would be nice if we could get it fixed there ... :-/
<pitti> NCommander: well, what *is* the problem?
<NCommander> xfprintf requires a2ps to actually print
<NCommander> THis broken in gutsy
<NCommander> (obvious Xubuntu users don't print)
<NCommander> pitti, now there is only one or two apps that actually use xfprint4, so its not a huge issue but ...
<pitti> NCommander: oh argh, xubuntu-meta is in main for dapper/feisty/gutsy, so we can't even pull it in there
<pitti> hmm
<NCommander> The problem fixed itself when we got bumped to universe
<NCommander> (and someone added a2ps to the Depends)
<NCommander> Now correct me if I"m wrong, but a promotion to main won't break things since main will always be enabled. Is there any way we could possibly get an exception to the no old release promotion rule?
<NCommander> ^- pitti
<NCommander> (a2ps is pretty deeply wrapped around xfprint4, it would be a major PITA to fix that)
<pitti> NCommander: I don't want to decide that on the spot; that has to be discussed with the soyuz guys (whether it's possible in the first place), and with some more archive admins
<NCommander> Right, no, that I understand, but I just want to know if at all its a possibility, or I should give up hope via this method, and look for some other way to resolve it :-)
<StevenK> pitti: It starts a dangerous precedent
<NCommander> StevenK, how often would a package need to be bumped to main to fix a bug in an SRU?
<StevenK> doko: Right, 0.99.4~20081006 builds
<StevenK> doko: So, I hit up pitti to approve it, or now what? :-)
<asac> hmm ... are there use-cases for not having "lo" iface upped?
<StevenK> asac: No, stuff breaks if it isn't
<pitti> asac: it might happen if you don't have any network support compiled into your kernel, perhaps? (for really small embedded devices)
<asac> yeah ... i wonder if there might be corner cases ;)
<pitti> asac: but I can't imagine it on anything which also uses network-manager
<asac> pitti: ok. but if there is network support, and "lo" interface can be upped, it should be upped i guess :)
<pitti> oh, yes
<ion_> Could someone please sponsor http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
<ubottu> Launchpad bug 278195 in opensync "Incorrect encoding for the synchronized entries" [Unknown,Confirmed] https://launchpad.net/bugs/278195
<asac> is sudo ifconfig lo up always the right thing to do?
<cjwatson> pitti: copying files to /target is fine if it's necessary
<cjwatson> pitti: (how come /var/lib/dkms doesn't get generated when installing those packages, the same way as it does normally?)
<cjwatson> NCommander: it could be done if there were a newer version of the package in -updates
<cjwatson> NCommander: I'm not even sure how it would be represented otherwise, or if Soyuz can technically do it without a newer version
<NCommander> It seems Soyuz can't
 * NCommander just asked
<pitti> cjwatson: I need to find that out; currently exploring options, but I haven't reproduced it yet
<doko> StevenK: I thought he did approve it before?
<NCommander> cjwatson, so could we upload a X.1 of a2ps which can be bumped to main, and then simply add the depends?
<cjwatson> NCommander: in theory
<pitti> cjwatson: apt-install will do a full install, including postinst, I assume
<cjwatson> pitti: yes
<cjwatson> pitti: note that it uses DEBIAN_FRONTEND=noninteractive though
<pitti> that should be ok, nvidia-glx-* don't use debconf
<NCommander> cjwatson, I'm asking now to see if thats a possibility
<pitti> tseliot: any idea about bug 258486 ?
<StevenK> pitti: So, can I beg you to look at a new upstream Cacao?
<ubottu> Launchpad bug 258486 in jockey "X fall in failsafe mode after install if nvidia restricted drivers are installed during LiveCD session in intrepid" [Undecided,In progress] https://launchpad.net/bugs/258486
<pitti> StevenK: new features? if so, please attach a changelog to the bug
<pitti> tseliot: it seems that after copying nvidia-glx-*, the target system doesn't get the modules built (presumably because they aren't registered to dkms)
<tseliot> pitti: I have added a comment there. Without a log and some other details I can't see what failed
<NCommander> cjwatson, they say in theory its possible, although bigjools wasn't sure if archive admins could do the necessary promotion
<NCommander> (i.e., it might require some black magic)
<pitti> tseliot: ok; I'll try to fake it in a VM
<cjwatson> NCommander: pretty sure we can
<StevenK> pitti: Looking at the NEWS file, it's mostly bug fixes
<StevenK> pitti: Do you want NEWS or ChangeLog, or both in a bug report? Keeping in mind I'm doing this for NBSage, and 0.98-2 FTBFS
<NCommander> cjwatson, so now that the techinical part of the promotion is sorta resolved, whats the next step? I assume a post to -devel to discuss it?
<tseliot> pitti: I guess that the system doesn't copy what was built by DKMS (/var/lib/dkms, the symlinks, etc.)
<cjwatson> NCommander: I suppose so
<tseliot> pitti: s/system/installer/
<cjwatson> tseliot: but why aren't those regenerated when the package is installed in /target?
<cjwatson> tseliot: the hook that does this doesn't copy files, it calls apt-get install (eventually)
<tseliot> cjwatson: yes, they are rebuilt if the driver is in the dkms tree in /var/lib/dkms
<cjwatson> tseliot: the driver gets there in the first place by installing a package
<tseliot> cjwatson: ok, I'll try to reproduce the problem here
<cjwatson> tseliot: why doesn't installing the package in /target work?
<tseliot> cjwatson: it should work. I'll see if I can track down the problem
<cjwatson> thanks
<liw> on Thursday and Friday last week, I tried upgrading my desktop machine from hardy to intrepid; both times it crashed hard, and from syslog and other things it seemed that the fglrx kernel module was the problem; last night, I restored the original state, removed the restricted kernel modules and restricted from sources.list, ran the upgrade again, and now it worked
<liw> I should file a bug about that, but... any other suggestion?
<pitti> StevenK: whatever is detailled enough to list/describe all the relevant new features
<pitti> StevenK: and I'd like to have doko's "OK" for that update, he's the expert
<doko> pitti: ok (I asked fot it =) )
<doko> will let us drop the cacao copy from cacao-oj6
<StevenK> pitti, doko: Bug 278957
<ubottu> Launchpad bug 278957 in cacao "FFe for cacao" [Undecided,New] https://launchpad.net/bugs/278957
<pitti> StevenK: thanks; bug updated
<NCommander> StevenK, here's the proof of concept https://dogfood.launchpad.net/ubuntu/+source/basket - its possible to promote in a pocket
<NCommander> ^_ pitti
<pitti> NCommander: ah, nice
<NCommander> We're waiting on dogfood's backend to generate apt files
<NCommander> Still need to make sure nothing nasty breaks
<NCommander> But from first glance, it can be done
<StevenK> I figured it could be made to work
<NCommander> We knew it was possible
<StevenK> NCommander: Now you get to prepare uploads to -proposed
<NCommander> StevenK, and you get to upload them :-)
<NCommander> The thing I was worried about if your promote a pocket it might affect the main archive
<StevenK> NCommander: Do I? :-P
<NCommander> (i.e., if I promote something in release, then backports and updates get prompted automagicially)
<NCommander> er promoted
<tseliot> cjwatson: does the Ubuntu installer dump a log anywhere?
<NCommander> pitti & StevenK: I got confirmation that publisher does the right thing w.r.t. to promotion in a pocket
<cjwatson> tseliot: /var/log/installer/syslog
<tseliot> cjwatson: ok, thanks
<tkamppeter> pitti, can you fix bug 271286 in Intrepid, otherwise driver auto-download is nearly non-functional.
<ubottu> Launchpad bug 271286 in jockey "Jockey should not only get "recommended" drivers from OpenPrinting" [Undecided,In progress] https://launchpad.net/bugs/271286
<pitti> tkamppeter: it's on my list, yes
<Adri2000> pitti: how often does the -sru team check main sru bug reports?
<pitti> Adri2000: I check the upload queue every few days, and read the bug mail
<wgrant> NCommander: Hi. Did #launchpad solve your issue?
<Adri2000> pitti: if few days < 1 week, you probably missed vsftpd :)
<NCommander> wgrant, yes, it proved that promotion in a pocket will not cause the archive to self-destruct
<wgrant> NCommander: So I read.
<NCommander> (a pity ... *shot*)
<StevenK> pitti: Mind binary NEWing cacao-source? I don't think I should do it since I prepared it
<pitti> StevenK: it was just a sync, wasn't it? so don't worry about it, but I'll do it now
<pitti> hmm
<pitti> cocoplum.ubuntu.com: forward host lookup failed: Unknown host
<slangasek> .c.c
<pitti> wasn't that the new drescher?
<pitti> ah
<slangasek> but you could just pass it off to the guy on archive duty today :)
<pitti> oh yeah, this "delegate" thing; admittedly I'm bad at that
<liw> delete, delegate, do... the GTD mantra :)
<liw> there's a defer there somewhere too... I need to re-read the book
<pitti> StevenK: looks ok, accepted
<StevenK> pitti: It wasn't a sync, though
<cjwatson> pitti: cocoplum.canonical.com
<cjwatson> oh, slangasek said, only more coded
<directhex> can a core dev please decline the release nomination on https://bugs.launchpad.net/ubuntu/+source/mono/+bug/278946 ?
<ubottu> Launchpad bug 278946 in mono "Please update to Mono 2.0" [Undecided,New]
<pitti> cjwatson: yep, got it from slangasek; thanks
<Hobbsee> directhex: declined.
<directhex> thanks Hobbsee.
<Hobbsee> directhex: you're welcome
<directhex> Hobbsee, it's a big sexy new upstream release, but it's tens of thousands of commits newer, and an upstream which needs a lot of patching..... and it's already october
<Hobbsee> directhex: indeed.
<StevenK> Heh
<NCommander> directhex, I'd run in horror if there was a FFe on that
<directhex> NCommander, so would i, and i'm the mono guy
<directhex> NCommander, trust in pkg-mono. even if i don't know what i'm doing, slomo and meebey do :p
<NCommander> directhex, I know enough that I should be a mono guy, I fixed evolution-sharp
<NCommander> remember that one :-)?
<directhex> oh, grand announcement: the final obstacle to syncing mono (build-dep on libgda2) should now be gone, it ought to be syncable for jaunty once 2.0 packages land
<directhex> jaunty will have a nice mono stack. more syncing, mono 2.0+, moonlight, mono-basic
<pitti> directhex: great work!
<wgrant> Is there a good reason for the NM connection editor to not be in System->Preferences?
<sebner> pitti: what do you think, granting all FFe for mono 2.2 (March) :P
<pitti> ...
<directhex> sebner, i'm laughing because it's true :). seriously though, we've spoken to upstream & they should now be MUCH more approachable when it comes to concerns over upstream releases versus distro freezes
<sebner> directhex: hrhr :)
<directhex> they're generally being a much better-behaved upstream, we even have our own packagers mailing list now to discuss things like downstream patches
<sebner> directhex: great to hear. hope they stick to the roadmap though
<directhex> sebner, the fewer patches we need to apply, the more likely we are to be able to even consider FFes (for minor versions only, of course). making sure they're warned *in advance* of freezes lets them know which versions will be installed on thousands of machines
<sebner> directhex: hehe
<directhex> e.g. "1.2.6" means "ubuntu 8.04", "1.2.2.1" means "debian etch", "1.2.2" means "SLES10"
<sebner> directhex: let's hope for 2.2 means ubuntu 9.04 :P
<directhex> sebner, well, whatever. the important thing from our perspective is, first and foremost, the best platform for desktop apps like f-spot and tomboy. cool new upstreams is a secondary concern
<sebner> directhex: of course
<slangasek> pitti: wow, still 8 distinct crasher bugs in console-kit-daemon?
<pitti> slangasek: on my triage rave on Friday I identified about three (of which one should be fixed in the latest version, and the other was the double close()), and some less frequent ones
<pitti> the one in the creation of its gazillion threads doesn't seem fully fixed yet, though
<tseliot> cjwatson, pitti: for some strange reason no nvidia-glx-VER package was installed after the installation of Ubuntu. Any ideas?
<pitti> tseliot: you enabled the nvidia driver on the live system and then installed?
<pitti> tseliot: in the bug report the reporter said that the package itself was installed, thuogh
<tseliot> pitti: yep. And the modified xorg.conf is still there
<tseliot> pitti: maybe he was referring to the modalias files?
<pitti> tseliot: that's possible, yes
<tseliot> pitti: after all they are named nvidia-177-modaliases, etc. and nvidia-common too might be misleading
<pitti> tseliot: after installing the driver under the live system, they should appear in /var/cache/jockey/installed_packages; maybe something was missing there?
<tseliot> pitti: there's nothing there but maybe the cache was emptied
<pitti> tseliot: I mean *in* the live system
<pitti> (the cache dir isn't copied to the installed system)
<tseliot> pitti: I am sure that the driver was installed and the the module was built because when this happens you can hear the login sound and network manager says that it disconnected and reconnected to the internet
<tseliot> pitti: too late, I have installed Ubuntu in Virtualbox. I can try the livecd again
 * tseliot tries the livecd again
<tkamppeter> pitti, I have uploaded an new system-config-printer package. Can you start this version and do the following:
<tkamppeter> pitti, click "New Printer", select an arbitrary detected printer, Forward, "Search for a printer driver to download", Make and Model: "HP LaserJet 3390", Search, Forward,
<tkamppeter> pitti, then you see on the next screen a description of the downloadable PPD for the HP LaserJet 3390. Can you make Jockey providing the same info when it has found a printer driver?
<pitti> tkamppeter: can you please put that information into a bug report? I'll look into it
<tkamppeter> pitti, there is already a bug report, I could add there that I implemented rthe display of the info in s-c-p.
<pitti> tkamppeter: that works, too
<slangasek>   dpkg --compare-versions $2 lt 3.1-pre11-1 || return 0
<slangasek> [...]
<slangasek>   dpkg --compare-versions $2 lt 3.2-pre9-4 || return 0
 * slangasek coughs
<cjwatson> I hope that code is only run in cases where $2 may not be empty
<slangasek> yes
<slangasek> it's still broken, though :)
<cjwatson> well, yes :)
<siretart> slangasek: in case you're processing the NEW right now, the 'ffmpeg' package is targeted for multiverse (whereas 'ffmpeg-debian' should stay in main)
<tseliot> pitti: /var/cache/jockey/installed_packages contains only nvidia-glx-177 (which is ok, I guess)
<pitti> tseliot: ah, I just fixed the boilerplate text in the KDE window if no driver is available
<slangasek> siretart: I saw ffmpeg in the new queue and started sobbing into my beer
<pitti> tseliot: that sounds fine
<pitti> tseliot: that list should get installed into the target system
<siretart> slangasek: if you have any question about that package, I'm happy to answer them
<pitti> tseliot: by /usr/lib/ubiquity/target-config/31jockey_pkgs (shipped by jockey-common)
<siretart> slangasek: as for potential or maybe patent problems, we have far worse examples already in multiverse, so I wouldn't expect THAT to be a problem
<tseliot> pitti, cjwatson: is it possible that the cache is wiped before ubiquity takes that list?
<tseliot> pitti: shouldn't that file say "apt-get install" ?
<pitti> tseliot: no, apt-install is a d-i command
<tseliot> pitti: ok, I just wanted to be sure
<tseliot> pitti: I thought I had fixed the problem with the KDE ui when no handlers are available
<slangasek> siretart: I'm primarily bothered by the code duplication.  So, all 6 of these libraries have to be rebuilt to enable the fuzzy stuff?
<pitti> tseliot: the crash, yes, but not the boilerplate elements like License: (license)
<pitti> tseliot: oh, maybe in your branch, indeed
<pitti> tseliot: I noticed it in GTK, too, and just fixed it in both
<tseliot> pitti: aah, that
<pitti> tseliot: anyway, I'll merge from your's again now
<tseliot> pitti: ok
<siretart> slangasek: I'm aware of the code duplication and I already have a plan to avoid that, or at least to make it managable. For intrepid this is the best solution I've come up with. for jaunty I promise to have a better solution
<siretart> I have sketched that plan on the pkg-multimedia mailing list, however alioth seems down, so I cannot give you the reference right now
<cjwatson> tseliot: which cache?
<slangasek> siretart: ok.  the new queue is behind freeze exceptions on my todo list, but I won't run screaming from it then :)
<siretart> thanks!
<tseliot> cjwatson: /var/cache
<cjwatson> tseliot: any particular bit of it?
<tseliot> cjwatson: /var/cache/jockey/installed_packages
<cjwatson> tseliot: ubiquity doesn't wipe /var/cache, in general
<tseliot> cjwatson: that's created by jockey (even in the livecd) when you install a driver
<pitti> so the file is created in the live system,but a following ubiquity install doesn't install the packages it mentions?
<tseliot> cjwatson: I'm not blaming it on ubiquity, I'm just trying to figure out what might have gone wrong in the installation process
<cjwatson> if /var/cache/jockey/installed_packages exists, I don't see any reason that code shouldn't work
<cjwatson> tseliot: I would like to see the installation log though
<tseliot> cjwatson: http://pastebin.com/m1afbdb4c
<pitti> should the script appear there? or anything like "target-config"?
<pitti> should the script appear there? or anything like "target-config"?
<cjwatson> tseliot: I have a suspicion that this only works if the packages in question are on the CD
<tseliot> cjwatson: if the DVD installer is available I can try it and see if I can reproduce the problem with it too
<cjwatson> I'm not quite sure though
<cjwatson> tseliot: it would be worth putting set -x at the top of the script so that we get a shell execution trace
<cjwatson> actually, no, the above comment (packages in question on the CD) ought to be false
<cjwatson> can you check /var/lib/ubiquity/apt-installed please?
<tseliot> cjwatson: there's no such directory in my system
<cjwatson> tseliot: even after the installer has run?
<tseliot> cjwatson: I'm using the installed system. Shall I boot into the installer, install again and see if I can find that file?
<cjwatson> tseliot: please
<tseliot> ok
<tkamppeter> pitti, bug 269454 updated
<ubottu> Launchpad bug 269454 in jockey "show printer driver support contacts, status, and unsupported color mode warning" [Undecided,Confirmed] https://launchpad.net/bugs/269454
<pitti> tkamppeter: danke
<liw> I'd like to get system-cleaner in intrepid updated to a bug-fixed version (274715, 274717, 275034); should I discuss this with release managers before asking for a sponsor to upload?
<slangasek> tseliot: on bug #220563, why do we not simply promote screen-resolution-extra to be a dependency of gnome-control-center?
<ubottu> Launchpad bug 220563 in gnome-control-center "Useful dual-head configuration requires manual editing of xorg.conf to set Virtual" [Low,Fix released] https://launchpad.net/bugs/220563
<slangasek> tseliot: given that it's already a recommends and therefore installed by default
<tseliot> slangasek: of course I have no objections on this. I would like to know what seb128 or bryce_ think of it
<seb128> tseliot: about what?
<slangasek> seb128: gnome-control-center Depends: screen-resolution-extra, instead of adding extra code to g-c-c to handle s-r-e being absent
<slangasek> it's not a difference in CD size at all, we'd just be promoting a Recommends to a Depends
<seb128> right, that would work for me too
<tseliot> oh, and BTW s/objections on/objection to/
<seb128> but there is no real point to do that
<seb128> it should be a recommends
<slangasek> the point would be to not write extra code and add additional UI strings just to keep it as a recommends
<seb128> recommends are installed by default, they just give the flexibility to users who don't want those to uninstall
<slangasek> (well, the code is written; but we wouldn't have to include it)
<seb128> what changing to a depends would bring?
<slangasek> seb128: it would solve the error condition in bug #220563
<ubottu> Launchpad bug 220563 in gnome-control-center "Useful dual-head configuration requires manual editing of xorg.conf to set Virtual" [Low,Confirmed] https://launchpad.net/bugs/220563
<tseliot> seb128, slangasek:  this is the link to the FFE: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/275977
<ubottu> Launchpad bug 275977 in gnome-control-center "Setting the Virtual resolution should be easier" [Wishlist,Confirmed]
<seb128> slangasek: I would say it's a minor issue and can be delayed to next cycle, it's only a bug for people who don't install recommends
<tseliot> slangasek: aah, the extra strings are the problem
<slangasek> tseliot: eh, you also subscribed ubuntu-release to bug #220563 and sent a debdiff there...
<ubottu> Launchpad bug 220563 in gnome-control-center "Useful dual-head configuration requires manual editing of xorg.conf to set Virtual" [Low,Confirmed] https://launchpad.net/bugs/220563
<tseliot> slangasek: yes, I was suggested to do so but at that point I couldn't unsubscribe ubuntu-release from the 1st bug report
<tseliot> cjwatson: the installation process is not complete yet, however I can see both apt-installed (which contains also nvidia-glx-177) and the jockey_installed filed in /var/cache/jockey/
<tseliot> cjwatson: would you like to see the full apt-installed file? Or is there any other file  you would like to have a look at?
<cjwatson> tseliot: the former - apt-installed should be short
<cjwatson> I have to take the dog out now, but will follow up when I get back
<cjwatson> tseliot: is the nvidia-glx-177 package installed in /target?
<tseliot> cjwatson: let me check
<tseliot> cjwatson: if I do ls /target/var/lib/dpkg/info | grep nvidia
<pitti> tseliot: you can sudo chroot /target and use dpkg -s, dpkg -L , etc.
<slangasek> ummm.  why does firefox want to use 'bazaar' as a handler for diffs?
<tseliot> cjwatson: only nvidia-common and the nvidia-VER-modaliases files show up. No trace of nvidia-glx-177 or nvidia-177-kernel-source
<Keybuk> soren: since updating desktop to Intrepid Beta, NFS mounts aren't mounted anymore on boot?
<liw> Keybuk, they are for me (but I have two default routes, which messes other things up)
<tseliot> pitti: right
<tseliot> cjwatson, pitti: dpkg --list | grep nvidia confirms that the package wasn't installed
<pitti> tseliot: would be interesting to check whether /usr/lib/ubiquity/target-config/31jockey_pkgs was actually run; sth. like "set -x" and "exec 2>/tmp/jockey.txt
<tseliot> pitti: shall I reinstall Ubuntu?
<pitti> tseliot: maybe cjwatson will have additional ideas when he returns; but for now we don't even know whether the script doesn't run, or whether apt-install fails, right?
<pitti> tseliot: so yeah, if it doesn't cause you trouble, changing the script that way and reattempting the installation would be interesting
<tseliot> pitti: yes. I find it a bit weird that the package is in apt-installed though
<pitti> tseliot: oh!
<pitti> tseliot: ok, then I'm pretty sure that the script itself ran
<soren> Keybuk: Oh dear. Soething you could look into? I've started paternity leave today..
<pitti> soren: oooh! congratulations, and good luck! *hug*
<kwwii> seb128: I guess we should talk sometime about the gnome-themes package...bascially, we need to remove everything except the high-contrast themes
<seb128> kwwii: could you mail the ubuntu desktop list? I don't like how things are being decided without public discussions there
<wtgee> Hola all...I am trying to become an ubentero and gpg doesn't seem to be sending the keys or doing anything...pilot error?
<kwwii> erm, ok but mark wanted me to report to him on wendesday about how far we are with this :-)
<slangasek> seb128: is it your opinion that f-spot should not be updated for intrepid?  I'm likely to refuse this FFe request unless someone on the desktop team speaks up on behalf of it
<cjwatson> pitti: right, if it's in apt-installed then the target-config script ran; that was the point of that test
<seb128> kwwii: you can tell him that such changes should be discussed somewhere so the community doesn't feel excluded etc
<Hobbsee> kwwii: is that dreary wallpaper *really* the final one?
<cjwatson> pitti: so that suggests to me that install_extras is busted, *again* - sigh
<Hobbsee> (speaking of changes not being discussed in public)
<seb128> slangasek: no, I think it should be upgraded but I'm not wanting to do the upgrade ;-)
<kwwii> Hobbsee: no
<slangasek> seb128: ah, heh :)
<Hobbsee> kwwii: oh thank goodness.  What's the new one like?
<Hobbsee> kwwii: and when will it land?
<kwwii> Hobbsee: it is one that everybody loves :p
<Hobbsee> oh, bah.
<kwwii> Hobbsee: asap
<seb128> kwwii: the change is an half an hour work so there is no issue to do it, I would just like a public mail about the suggested changes and the rational before doing that so we don't have "what the heck are you doing" bugs and comments
<Hobbsee> kwwii: hope you haven't seen brainstorm then.  or the forums :P
<Hobbsee> kwwii: excellent!  Where can we see it?  :)
<pitti> cjwatson: ok, I'll add the current findings to bug 258486
<ubottu> Launchpad bug 258486 in nvidia-graphics-drivers-173 "X fall in failsafe mode after install if nvidia restricted drivers are installed during LiveCD session in intrepid" [Undecided,Invalid] https://launchpad.net/bugs/258486
<pitti> cjwatson: should that be ubiquity, or some d-i component?
<stgraber> slangasek: bug 278399 and bug 278425 for LTSP
<cjwatson> pitti: ubiquity
<ubottu> Launchpad bug 278399 in ldm "[UVFe] ldm (2.0.12 -> 2.0.13)" [Undecided,New] https://launchpad.net/bugs/278399
<kwwii> Hobbsee: I am going to use one of the pics on the wiki, either one from rico or thorsten
<ubottu> Launchpad bug 278425 in ltsp "[UVFe] ltsp (5.1.22 -> 5.1.25)" [Undecided,New] https://launchpad.net/bugs/278425
<ogra> stgraber, you should probably mention that the "cosmetic change" in ldm fixes a regression
<Hobbsee> kwwii: i look forward to seeing it, as there are many pics on the wiki.
<seb128> slangasek: upstream seems to expect the new f-spot version being shipped in the distros coming and blogged about that, and I would argue that f-spot is buggy enough anyway so new versions are not a stability issue anyway
<stgraber> ogra: oh ? I didn't know :)
<kwwii> Hobbsee: something like https://wiki.ubuntu.com/Artwork/Incoming/Intrepid/Earthenibex_wallpaper
<slangasek> seb128: ok; I don't see that anyone currently on that bug is offering to prepare the package, though
<wgrant> kwwii: That's nice, but it'd need to be scaled down a bit to make the desktop usable.
<ogra> stgraber, the password entry moved to the side with a patch early in the dev cycle, that patch centers it again
<Hobbsee> kwwii: nice
<seb128> slangasek: right, I'll try to see if some of the active desktop team contributors is wanting to do it in the next days
<ogra> stgraber, oh, and we should probably also get a fix for bug 277331 in
<ubottu> Launchpad bug 277331 in ltsp "'ltsp-build-client' should pull from *-updates repository by default" [Undecided,New] https://launchpad.net/bugs/277331
<ogra> i think the "--copy-sourceslist" fix is the best way to go
<ogra> (i.e. using that as default option if not on CD)
<kwwii> wgrant: yeah, that was my thoughts as well
<ogra> meh, does anyone else see errors when trying to install devscripts ?
<ogra> http://paste.ubuntu.com/54610/
<stgraber> ogra: hmm right, that may break ltsp-cluster though
<stgraber> ogra: as I add a PPA to the sources.list, not sure if that will be overwritten or not
<kwwii> http://bazaar.launchpad.net/~t-w-/ubuntu-artwork/thorwils_backgrounds/annotate/32?file_id=rsc_ibex_woodblock.j-20080927154856-l2xo5c38l0j5uun8-6 might be better in that regards
<ogra> stgraber, add it after the copy-sourceslist plugin ran then
<stgraber> ogra: anyway, for now best is to get both packages uploaded, the remaining bugs can be fixed without changes to upstream release (they are Ubuntu specific)
<ogra> yeah
<Hobbsee> ogra: i *do* hope that pastebin, if linked to the line above, wasn't a serious question.
<ogra> Hobbsee, it was, the recomends of devscripts are *insane*
<Hobbsee> ogra: i'm aware of that.  But you didn't give the error from above.
<ogra> Hobbsee, it tires to install an MTA, isnt that error enough ?
<Hobbsee> ogra: surely, then, that's a bug about "devscripts wants to install a MTA".  Saying that there are "errors when installing devscripts" implies a packaging error, and packaging uninstallability.
<ogra> Hobbsee, additionally all of these packages run invoke-rc.d inside a chroot ..
<liw> ogra, invoke-rc.d is supposed to be run
<liw> ogra, invoke-rc.d then calls policy-rc.d to see if it should do anything
<Hobbsee> which is a fix someone will probably want to delve in quickly, rather than the longer process of figuring out which ones can be removed, and dealing with any mailing list complaints because of your changes.
<mok0> ogra: the application "gamgi" is in ubuntu universe for ii. You may want to include it in your edubuntu seed
<ogra> liw, all of them *require* proc to be mounted for invoke-rc.d
<ogra> thas not really kosher for chroots imho (beyond the fact that i dont want an mta just because i unpack and resign a source package)
<liw> ogra, hm, how do they require /proc in a way that no other packages require?
<ogra> devscripts pulls in a massive amount of extra crap through its recommends
<Keybuk> soren: I'm not home that much between now and release :-/
<ogra> it used to be a slim thing
 * ogra doesnt get why he would need x-www-browser in a chroot for example 
<jcristau> it's ok, you don't need devscripts in a chroot either
<ogra> liw, no, but they simply require /proc ... which wasnt the case before ... when installing devscripts in hardy you get a small set of packages for manually fiddling with packages, when installing it in intrepid i get 100M more or so
<ogra> which is just a waste
<ogra> jcristau, if i work on packages for lpia i *need* a chroot with devscripts
<Keybuk> err
<Keybuk> why is there a discussion about /proc being required or not? :p
<Keybuk> /proc is always mounted
<ogra> Keybuk, my discussion point isnt /proc (though i dont like to have it required now) my point is that i dont want my chroots to explode by 100s of megabytes to silly recommends
<Keybuk> it's required
<ogra> its never been mounted in my chroots up to now
<Keybuk> so many things break if it's not there
<Keybuk> like ps, pidof, killall, etc.
<ogra> and if we *require* it chroot should be patched to mount it yutomatically
<ogra> *automatically
<Keybuk> that's not a bad idea (well, dchroot)
<Keybuk> I'm actually strongly considering having Upstart hard-coded to mount /proc and /sys
<jcristau> schroot already does that afaik
<Keybuk> since the overhead of /bin/mount is faintly ridiculous for a single syscall
<ogra> anyway, i dont see why i should need to buy bigger disks for the ten chroots i use for development for different purposes because they suddenly require a gig more on disk together
<Keybuk> jcristau: you appear to be correct
<liw> I don't see big differences in the Depends of devscripts in hardy vs intrepid
<Keybuk> ogra: use schroot ;)
<ogra> liw, we didnt use any recommends of them
<ogra> look at the recommends
<liw> ogra, sure, but you don't _have_ to install recommends
<ogra> we should have a devscripts-light or some such then
<liw> ogra, how do you install devscripts?
<ogra> apt-get install devscript
<ogra> (and yes, i'm aware of the apt option)
<ogra> my point is that people wont expect that and that there are others that even have scripts that keep their chroots up to date automatically ... havng a chroot filled with 100s of MB of crap isnt a good idea imho
<Keybuk> do you mean MB or MiB?
<cjwatson> I'm amazed you've managed to get by for so long without /proc mounted in your chroots; I've been mounting it in my development chroots for years
<ogra> especially with stuff that totally isnt needed for ubuntu package development
<cjwatson> ogra: you could just use apt-get --no-install-recommends install devscripts
<ogra> Keybuk, that think with the M in the beginning :P
<cjwatson> if you don't like them, that is the proper answer
<liw> Keybuk, that was lame. You owe me an explanation of why I get two default routes under intrepid (when using bridging).
<slangasek> or you could configure your chroot to always use --no-install-recommends
<ogra> cjwatson, yes, i said i'm aware of that above
<Keybuk> liw: nuffin' t'do wi' me guvna
<slangasek> which is sorta the sensible thing to do anyway
<cjwatson> ogra: the option is there for people like you :-)
<ogra> slangasek, no, because i want the recommends for the other packages
<slangasek> ogra: in a dev chroot?  I assert that you do not :)
<cjwatson> ogra: if everyone demands that their use case needs to be the default, we will never be able to satisfy everyone
<ogra> i might test installability :)
<liw> would anyone be willing to sponsor an upload of system-cleaner from REVU for me? 1.10 in REVU fixes several bad problems that are in the 1.8 version in intrepid
<slangasek> recommends-by-default gives wrong results for any sort of build-dep checking
<ogra> cjwatson, i just dont want it to regress so badly
<Keybuk> . o O { why does blogs.msdn.com need to use such a small font? }
<cjwatson> ogra: for most people, I assert that it's an improvement
<Keybuk> cjwatson: my use case should be the default, and so should yours ;)  everyone else can customise <g>
<ogra> having exim in a chroot is an improvement ?
<doko> tkamppeter: when did hplip-gui introduce the dependency on python-reportlab?
<slangasek> liw: why is it on REVU, rather than an LP bug + ubuntu-universe-sponsors?
<ogra> or subversion ?
<Keybuk> (the fact that we completely disagree on everything makes that a humorous statement)
<slangasek> liw: I thought REVU was only used for new packages
<cjwatson> ogra: not having scripts installed that won't run is an improvement
<liw> slangasek, I thought REVU was supposed to be used for all uploads
<cjwatson> ogra: you're microfocusing on the problem you see rather than the reasons behind it
<ogra> ... or www-browser
<cjwatson> Keybuk: :-)
<ogra> cjwatson, well, that microfcusing results in several 100M per chroot on my disk :)
<cjwatson> ogra: only because you're stubbornly refusing to use the option to make it not do so ...
<cjwatson> www-browser is a little silly; bts only needs sensible-browser
<cjwatson> and works fine with w3m
<slangasek> liw: in my experience, it's only used for new packages; I don't know if using the ubuntu-universe-sponsors queue will get it uploaded faster in practice, but it improves the chances of me looking at it personally, given that I would have to look up where REVU is located :)
<liw> slangasek, right. I'm now looking for the next elusive wiki page to describe this :)
<ogra> well, i see i wont convince anyone here  ...
<liw> slangasek, it's as if all development docs were distributed in a maze of small hypertext pages, all alike
<cjwatson> ogra: I agree that there are problems, but it would be much better to address them calmly rather than railing against recommends (which were always supposed to be installed along with the package in normal situations, per policy) and throwing around big numbers
<slangasek> liw: https://wiki.ubuntu.com/SponsorshipProcess
<ogra> even though it feels like adding mono to build-essential ... i guess i'll have to live with it
<cjwatson> no, you could use the option
<slangasek> liw: feel free to link to that from whatever page failed to inform you of it :)
<cjwatson> you don't have to live with it
<ogra> thats whyt i mean by live with it
<ogra> though i would prefer to have the old devscripts behavior back and just have a "devscripts-full" for the recommends
<cjwatson> there is no point to --no-install-recommends if we're just going to take every package with recommends and split it into foo and foo-full
<liw> ogra, to get that done, you probably want to talk this over with devscript maintainers in Debian
<cjwatson> (I know you didn't say that, but it's the logical conclusion)
<liw> (it's unlikely to happen, but that'd be the right place)
<ogra> yeah, i get that
<tseliot> cjwatson: is there any other file (in the live system) you would like to have a look at or can I shut down virtualbox?
<cjwatson> tseliot: /target/etc/apt/sources.list and a listing of the files in /target/var/lib/apt/lists/ would be nice
<cjwatson> (I was just getting back to you ...)
<slangasek> pitti: it appears we still don't have a viable set of packages for ekiga 3.0? :( (#274085)
<soren> pitti: Thanks! :)
<soren> Keybuk: Ok. I'll try to look into it. Is there are bug report about it?
<Keybuk> soren: I wouldn't know what to put in one other than "FAIL"
<cjwatson> pitti,tseliot: it does look as if *no* packages are being installed by install_extras
<soren> Keybuk: Can I see your /etc/network/interfaces, please?
<Keybuk> soren:
<Keybuk> auto lo
<Keybuk> iface lo inet loopback
<Keybuk> --
<ogra> do we still maintain a blacklist for compiz ?
<ogra> it appears that compiz it used by default on geode systems, that doesnt work
<ogra> hmm, ENOMVO
<Keybuk> ogra: /usr/bin/compiz is still a shell script
<Keybuk> and it still has a driver _whitelist_
<ogra> weird ...
<Keybuk> what driver are you using?
<ogra> i have reports from someone using ubuntu-mobile on a geode based system
<tseliot> cjwatson: did you get the links to the sources.list and the other files or shall I post them again? (I've noticed that you were disconnected)
<ogra> and he complains about the massively slow effects
<ogra> apparentl its a AMD Geode LX800
<ogra> should use the nsc driver iirc
<ogra> which definately isnt in that whitelist
<cjwatson> tseliot: I wasn't disconnected - it was a netsplit that we were on opposite sides of
<soren> Keybuk: That's it? Nothing commented out or anything?
<Keybuk> soren: the wired card is brought up by NM
<cjwatson> tseliot: I didn't get them, but please put them in the bug
<tseliot> cjwatson: ok
<soren> Keybuk: Yeah, I guessed.
<jcristau> ogra: compiz wouldn't even start on a geode, afaik
<Keybuk> soren: logs suggest Network Manager brought up the wired during the boot as usual; and didn't wait for login
<ogra> jcristau, hmm, i wonder why he complains about slow effects then, od we default to have composite on in metacity now ?
<ogra> *do
<Keybuk> ogra: apt-get source metacity
<Keybuk> ogra: apt-get install less
<ogra> :P
<cjwatson> Keybuk: miaow
<mok0> ogra, did you see my shout ~45 minutes ago?
<soren> Keybuk: You never responded to this: 12:58:24 < soren> Keybuk: That's it? Nothing commented out or anything?
<tkamppeter> doko, I think hplip-gui always depended on python-reportlab. What is the problem?
<Keybuk> soren: that's it, nothing commented out
<Keybuk> sorry, I thought that was implied by "NM brings the interface up"
<soren> Keybuk: I just wasn't sure if that was a response to that since you only took two seconds to see my question, think up a response, and then type it :)
 * soren bows to Keybuk's mad typing skillz
<ogra-n800> grr, so a simple killall firefox killed my laptop now
<ogra-n800> oh fun and after reboot i have no graphics output at all
<ogra-n800> hmm, second reboot works... at least i see usplash
 * ogra checks for upgrades
<Keybuk> did you have /proc mounted? :p
<ogra> pfft
<ogra> ok, i'm behing on kernel ... that might be it
<Keybuk> I actually ask, because killall defaults to killing *all* processes if you don't <g>
<ogra> well, there was clearly somethng wrong with the graphics after rebooting
<Hobbsee> wubi pops up a dialog when you put an ubuntu cd into a windows machine, asking if you want to install it, doesn't it?
<ogra> i probably forgot to unmount proc in the chroot i used before though :P
<evand> Hobbsee: umenu does.  Wubi is an option in umenu.
<Hobbsee> evand: cool :)
 * Hobbsee edits brainstorm more
<liw> soren, do you happen to know about network configs? my desktop is using a setup copied from KVM's wiki page and under intrepid I'm now getting double routes (which means packets go nowhere in some cases)
<soren> Keybuk: Hypothesis: Before I "fixed" mountnfs, do you think it might have tried to mount the nfs mounts straight away (like say when it brought up lo), and then only actually finished mounting it when the network came up?
<soren> liw: I'd blame NetworkManager. :)
<liw> soren, hmm, I can try removing that
<soren> liw: Either that, or try commenting out the nic's in /e/n/i.
<liw> soren, which nic? eth0?
<soren> liw: the one that gets configured twice.
<Keybuk> soren: it looped waiting for a network device to come up I thought :p
<ogra> soren, err
<ogra> we use that in ltsp ... please dont break it
<soren> Keybuk: A cursory galnce at the code at least suggests that it'd bail unless it was configuring the final interface marked "auto".
<ogra> (assuming you talk about the one in initramfs-tools)
<soren> ogra: I'm not.
<ogra> phew, ok
<ogra> then ignore me :)
<soren> ogra: I'm talking about /etc/network/if-up.d/mountnfs
<ogra> ah
<soren> Keybuk: ...but to be perfectly honest, I've not read all the code. I just saw the very clearly wrong path in there, fixed it, saw that it removed an error message, and thought all was good.
<soren> Keybuk: I'm kind of wondering why it worked before. :/
<liw> soren, hmm, right, if I disable NM (/etc/init.d/NetworkManager stop), then the double route doesn't happen, so now I need to figure out how to tell NM to not touch eth0 (the rules of which seem to have changed again)
<ogra> liw, it should manage eth0
<liw> ogra, why?
<ogra> liw, it has a handler for /e/n/i now, but thats buggy, afaik asac is working on a fix
<ogra> liw, because thats the central point for handling interfaces now ... it's supposed to handle all of them centrally
<ogra> even on commandline systems
<asac> ogra: i enabled it now
<liw> ogra, I don't understand you at all now; NM has had a handler for /e/n/i for a long time now, and NM most certainly has no business at all touching eth0 on my desktop
<asac> ogra: will send a mail to -devel after lunch
<ogra> good
<asac> liw: upgrade to latest NM ... default is "unmanaged" mode
<liw> asac, define latest? this is upgraded today
<asac> liw: so if you do nothing NM should stop managing devices in eni
<asac> liw: the present is: network-manager 0.7~~svn20081004t225044-0ubuntu1 ... everything else is the "past"
<asac> :)
<liw> asac, is that a very recent upload?
<asac> liw: uploaded 1h ago? :-P
<liw> no wonder it isn't on my local mirror, then :)
<asac> liw: < liw> ogra, I don't understand you at all now; NM has had a handler for /e/n/i for a long time now, and NM most certainly has no  business at all touching eth0 on my desktop
<asac> liw: in intrepid LP: #< liw> ogra, I don't understand you at all now; NM has had a handler for /e/n/i for a long time now, and NM most certainly has no  business at all touching eth0 on my desktop
<asac> oops
<asac> liw: LP: #256054
<asac> ;)
<Keybuk> soren: before, the boot used to mount nfs mounts in an /etc/network/if-up.d script
<Keybuk> I wonder
<Keybuk> asac: NM still runs those, right? :)
<soren> Keybuk: Right. That's what I touched.
<soren> I was just about to ask that.
<soren> I don't see networkmanagerdispatcher anymore.
<asac> Keybuk: yes. thats the idea
<Keybuk> asac: how are they run?
<asac> soren: its a dbus action now
<asac> /usr/lib/NetworkManager/nm-dispatcher.action
<asac> Keybuk: ^^
<Keybuk> what's a "D-Bus Action" ?
<asac> Keybuk: /usr/share/dbus-1/system-services/org.freedesktop.nm_dispatcher.service
<asac> so service ;)
<Keybuk> err
<Keybuk> so what causes that to be executed?
<Keybuk> because it's so not running here
<asac> dbus activation?
<Keybuk> but that used to listen to D-Bus signals before
<Keybuk> did someone replace the D-Bus signals with method calls on the dispatcher?
<asac> Keybuk: yes. now its auto activated and shuts down when finished
<Keybuk> and what does the dispatcher do now?
 * ogra reboots
<asac> Keybuk: same as before. running /etc/NetworkManager/dispatcher.d/
<guysoft42> hey all, i seem to have the following error in my repository when running $ reprepro check:Internal error of the underlying BerkleyDB database:  Within packages.db subtable hardy|main|i386 at c_get(DB_NEXT): DB_PAGE_NOTFOUND: Requested page not found . what to do?
<Keybuk> asac: ok
<Keybuk> need to reboot after a kernel update, so let me see if it actually runs that
<asac> soren: Keybuk: if you see particular issues, let me know
<doko> tkamppeter: could you check the cover generation with this package (new upstream version): https://edge.launchpad.net/ubuntu/intrepid/+queue?queue_state=1&queue_text=python-reportlab
<asac> didnt test for the last month or so, but last time i looked it worked quite well
<ogra> shriek
<ogra> starting virtualbox turned all my gtk into QT !!!!
<soren> Keybuk: I see the script running.
<soren> Keybuk: I put a "echo foo > /tmp/ping" at the top of mountnfs, and that worked.
<soren> Keybuk: (just tested it for my gprs connection)
<ogra> ah, no, it just made gnome-settings daemon crash
<asac> ogra: so you mean s/QT/plain GTK theme/ :)
<ogra> :)
<soren> Keybuk: I'm in a hospital room right now with nothing but a gprs connection, so it's kind of hard to debug much right now. I'll take a peek when I get home and find some free time.
 * Keybuk hugs dkms
<Keybuk> now it works, I like it
<ogra> ah, better
<madduck> how are the chances of intrepid being released before 20 october?
<ogra> so now, why cant i enable compiz
<slangasek> madduck: ... zero?
<ogra> heh
 * madduck is trying to schedule a study involving ubuntu people so as to not conflict with the final sprint...
<slangasek> madduck: https://wiki.ubuntu.com/IntrepidReleaseSchedule
<ogra> even before oct 30th according to the schedule
<Keybuk> madduck: Intrepid is released on the _30th_ of October
<madduck> ah, i didn't know about that page
<Keybuk> slangasek: temped to make a https://wiki.ubuntu.com/JauntyReleaseSchedule with just "WHEN IT'S READY HA HA HA" on it :p
<Keybuk> asac, soren: ok machine came back after reboot
<Keybuk> so NM is definitely bringing up the interface before login
<madduck> Keybuk: that would not be an acceptable answer to my question in this case, funny person you! :)
<Keybuk> nm-dispatcher did call 01ifupdown, which did a run-parts on /etc/network/if-up.d
<Keybuk> soren: mountnfs was called for eth0, but appears to have not done anything
<Keybuk> ah, my bad
<Keybuk> let's try another reboot
<slangasek> superm1: blah, why are the packages in the bluetooth ppa not using ppa version numbers? (evolution, totem)
<Keybuk> madduck: could you not schedule your thingy to co-incide with UDS?
<madduck> Keybuk: my study will run for several weeks (although the individual involvement totals at a few hours)
<Keybuk> soren: interesting ...
<madduck> Keybuk: what would be the benefit of making it happen in sync with UDS?
<Keybuk> mountnfs never called mount
<Keybuk> madduck: ease of participation from ubuntu people?
<madduck> Keybuk: i'd say that UDS might actually make it harder for people to work on my study, just judging from my own summit/conference experience.
<ogra> Keybuk, ogra@osiris:~$ compiz --replace
<ogra> Checking for Xgl: not present.
<ogra> Detected PCI ID for VGA:
<ogra> Checking for texture_from_pixmap: Segmentation fault
<ogra> not present.
<ogra> thats on a i965
<madduck> Keybuk: so you think UDS would make it easier for people to participate?
<Keybuk> madduck: well, they'd be already there?
<Keybuk> I don't know what you're asking them to participate in?
<ogra> i assume its shouldnt really segfault
<madduck> an email discussion; you should have gotten a message about it, didn't you?
<madduck> Keybuk: ^
<madduck> Keybuk: <20080926143635.305A34524@piper.oerlikon.madduck.net>
<Keybuk> oh, is that what that is?
<madduck> yes
<Keybuk> I confess that is sitting unread in my inbox
<madduck> I confess it's rather lengthy and scary. :)
<tseliot> ogra: does glxinfo segfault too?
<ogra> yes
<Keybuk> soren: ooooh, I have a *fun* bug report to write
<Keybuk> something, during the upgrade process, must have edited /etc/fstab
<Keybuk> and left it without a final newline
<madduck> Keybuk: but it's a very cool method, I think, you might get a chance to look at it still. I did extend the deadline till Thursday...
<Keybuk> it appears that mountnfs ignores the last line if it doesn't have a final newline
<slangasek> that's the email that says "I'd like to take 5 minutes of your time" and then includes 10 minutes worth of text with a request at the end? ;)
<tseliot> ogra: and what card model do you use?
<Keybuk> so it ignored my nfs mount :p
<madduck> anyway, sorry for the OT and thanks for all the help.
<madduck> I will consider UDS when making scheduling plans too.
<tseliot> ogra: and what driver?
<ogra> tseliot, i965GM/GL960
<ogra> intel i guess
<ogra> i have no xorg.conf
<Keybuk> (see also: why parsing fstab in shell a hundred times during boot is *BAD*
<ogra> yep, Xorg.0.log says intel
<Keybuk>  in fact, why parsing fstab at all and not using getfsent() is *BAD*)
<tseliot> ogra: can I see the Xorg.0.log?
<ogra> tseliot, http://paste.ubuntu.com/54643/
 * ogra has a conf call now ... back soon
<jcristau> heh. '(II) NVIDIA GLX Module  173.14.12'
<tseliot> ogra: type sudo apt-get remove nvidia-173-kernel-source
<tseliot> jcristau: right
<superm1> slangasek, oops.  wasn't really estimating how long this whole process would be taking, i'll delete/readd those packages then
<ogra> tseliot, oh, where di that come from ?
<ogra> i surely didnt instal it manually
<slangasek> superm1: ok :)
 * ogra purges 
<tseliot> ogra: it might be a Recommends of some package you have installed
<slangasek> superm1: so will the 4.x stuff magically fix my inability to connect with gnome-phone-manager, or to run btsco, both of which worked in hardy and are basically the only bluetooth things I have that need to work?
<ogra> for me only one out of four devices works :(
<superm1> slangasek, well what did you use btsco for?
<superm1> slangasek, and what did you do with gnome phone manager?
<slangasek> superm1: er, I used gnome-phone-manager for connecting to my phone, and now it doesn't work
<slangasek> superm1: and I used btsco to get a device that ekiga could talk to, and now btsco doesn't work
<slangasek> (with the packages currently in intrepid)
<superm1> slangasek, connecting to your phone and sending address books, or which?
<superm1> ah
<slangasek> gnome-phone-manager> dialing, actually
<superm1> oh it provided a handsfree profile?
<superm1> that's pretty interesting..
<slangasek> I haven't tested the address book syncing yet, I guess I should test that too
<slangasek> yes, g-p-m integrates with evolution address book even
<azeem> out of curiousity, what is g-p-m using for sync?
<Keybuk>             os.rename("/etc/fstab.intrepid","/etc/fstab")
<Keybuk> ...
<Keybuk> for 10 points, spot the obvious error
<tseliot> superm1: did you have a look at my nvidia-xconfig?
<superm1> as for the sco stuff, if we end up with the latest pulseaudio it can enumerate bluetooth devices, but i'm not sure we will end up with it
<slangasek> but I don't use it all that much, I haven't settled on a workflow that doesn't make me hate computers
<Keybuk> err
<slangasek> azeem: it doesn't do syncing
<Keybuk> the less obvious error than me pasting the wrong line ;)
<Keybuk>             open("/etc/fstab.intrepid","w").write("\n".join(lines))
<Keybuk> ^ that line
<azeem> slangasek: ah, k
<superm1> tseliot, i glanced at it but didn't check it yet
<tseliot> superm1: ok, no problem
<slangasek> Keybuk: missing trailing newline?
<liw> Keybuk, you mean the error of overwriting a sysadmin's manually created file?
<superm1> slangasek, oh also regarding an earlier ping, i dont think that list is exhaustive of all cards that are transitioned over
<Keybuk> liw: "fixing" a file is a perfectly valid upgrade case ;)
<liw> (that was the obvious one for me... the newline problem I had to think about)
<Keybuk> slangasek: exactly
<liw> Keybuk, overwriting /etc/fstab.intrepid is not valid :)
<Keybuk> slangasek: where do we file bugs on the magic dist upgrader tarball?
<slangasek> Keybuk: against project 'mvo', innit?
<slangasek> or update-manager, maybe :)
<Keybuk> slangasek: he's on holiday
<Hobbsee> slangasek: you can't file bugs against people.  I've long considered this a bug.
<ScottK> Hobbsee: They'd need a significantly bigget DB server if that was allowed.
<ScottK> bigget/bigger
<cjwatson> it's been update-manager in the past, yes
<Keybuk> slangasek: bug #279093
<ubottu> Launchpad bug 279093 in update-manager "Removes trailing newline from /etc/fstab" [Critical,New] https://launchpad.net/bugs/279093
<pitti> cjwatson: ah, tzdata 2008g-1 just hit incoming; shall I sync that to intrepid?
<liw> slangasek, incidentally: unless it's PEBKAC, #278963 may need some bug fixing attention before release
<pitti> cjwatson: (that should fix Argentinia, too, I'll double-check that)
<cjwatson> pitti: oh, yes please if it fixes the argentina thing
<liw> Argentina has messed up their time zone again?
<slangasek> superm1: right, upgraded; and bluetooth-applet gives me the option to 'set up a new device', but doesn't show any devices and gives me no option to refresh the list...
<pitti> cjwatson: (there first was a 2008f-2 for argentinia, and then 2008g shortly afterwards)
<cjwatson> liw: yes, basically the government missed their deadline ...
<liw> cjwatson, they should just switch to utc like all sensible people...
<superm1> slangasek, the refresh should be constantly happening
<superm1> if it's not showing anything for your device, are you sure the device doesn't require a reset quirk (as a lot of bluetooth devices do); did it need to be reset in the past for magic to happen?
<slangasek> superm1: ah, I suppose it's not going to show my bluetooth headset because I didn't have it in pairing mode, meh
<liw> . o O (BT could have been such a wonderful technology...)
<slangasek> superm1: ok, the upgrade and a re-pairing through the wizard lets me get g-p-m connected to my phone; so far that's an improvement
<slangasek> but, er, previous versions of g-p-m allowed initiating calls, this one only seems to implement SMS
<pitti> cjwatson: confirmed, 2008g fixes it
<slangasek> (that, or I'm thinking of one of the 12 other bluetooth things I tested to try to find something that works, but I don't think so)
<pitti> cjwatson: synced, intrepid task closed
<slangasek> superm1: who do I hurt for these new buttons in GNOME preferences dialogs that consist of icons with no tooltips?
<slangasek> like this lovely "i" in a circle, the universal symbol for "information", which I know from previous bluez-gnome versions actually means "trusted device" :P
<rom1v> hi
<superm1> slangasek, that would be upstream.  slytherin offered to write a patch to put in tooltips though
<rom1v> when ubuntu starts, where is the call to "compiz" (to launch compiz)?
<slangasek> superm1: who upstream?  I've not noticed GNOME upstream as a whole to be afflicted with this particular brand of insanity in the past
<superm1> slangasek, upstream bluez, they're the ones that author this
<slangasek> superm1: as in, Marcel?  Hmm, that doesn't explain why things like unlabelled +/- buttons also appear in the keyboard prefs dialog
<superm1> slangasek, yeah as in marcel
<slangasek> welp, btsco still fails
 * liw is hit by boot-time fsck. again.
<soren> Keybuk: Interesting. Something completely knackered my /etc/hosts recently as well.
<Keybuk> "completely knackered" ?
 * liw hopes it wasn't python-fstab
<soren> Keybuk: When I opened it today, I found 7-8 identical lines reading: "# Do not remove the folliwing line...blahblahblah... 127.0.0.1 something something" I forget what it read exactly, but something along those lines.
<soren> ...and nothing else.
<superm1> slangasek, i'm pretty sure upstream is much more preferable to using the native sco support in bluez anyhow.. btsco is a third party universe project isn't it?
<Keybuk> soren: mine appears to have
<Keybuk> ~30 blank lines added to the end
<slangasek> superm1: I know upstream doesn't *want* me to use btsco, but that opinion is worth bupkis when the apps I'm trying to use aren't compatible with bluetooth alsa virtual devices
<soren> Keybuk: Very odd. I have 8 blank lines at the end now.
<soren> :$
<superm1> slangasek, well we'll see if TheMuso ends up setting up  the latest pulseaudio -  which includes bluetooth support.  if nothing else, that part should be better by jaunty..
<liw> asac, upgrading to the current version of network-manager did fix my double route problem, thanks
<rom1v> could someone help me?
<asac> liw: do you use bridging?
<liw> asac, yes
<asac> ok
<slangasek> superm1: well, I should at least do some testing of audio output, here; if I can remember how to configure gstreamer for bluetooth, either...
<superm1> i had a changer script for that; it's on another comp though.  mterry might have it handy
<pitti> tkamppeter: that means that the pdftoraster workaround in 1.3.8-11ubuntu1 is obsolete now and can be overridden by trunk, right?
<ogra> yay, compiz love
<tseliot> \o/
 * ogra hugs tseliot ... thanks a lot 
<tseliot> ogra: you're welcome. Knowing what installed the nvidia driver would be nice too
<cjwatson> rom1v: init reads /etc/event.d/rc2 which tells it to run /etc/init.d/rc which calls /etc/rc2.d/S30gdm which starts gdm which reads /etc/gdm/gdm.conf which tells it to run /etc/gdm/Xsession which calls /etc/X11/Xsession.d/50x11-common_determine-startup which reads /usr/share/gnome/autostart/gnome-wm.desktop which tells it to run /usr/bin/gnome-wm which decides which window manager to run, possibly compiz
<cjwatson> rom1v: HTH, but next time please don't ask support questions on a developer channel :)
<rom1v> great answer ! thank you :)
<rom1v> I need that because I think in a future realease, ubuntu should call "nvidia-settings -l" just before launching compiz
<ogra> tseliot, well, /var/log/apt/ only has info about the removal, so it must have been theer since a while
<Nafallo> cjwatson: wow :-)
<rom1v> if graphical card is nvidia
<cjwatson> rom1v: similarly, bug reports => bug tracking system
<rom1v> (else nvidia settings are not used by compiz)
<asac> soren: Keybuk: those empty lines are a bug in NM ... shouldnt happen that frequently anymore after latest upgrade though (except when you change the hostname)
<cjwatson> err, I missed out gnome-session running between /etc/X11/Xsession.d/50x11-common_determine-startup and reading /usr/share/gnome/autostart/gnome-wm.desktop, though
<rom1v> I already reported that, but I will add this line "nvidia-settings -l" where it should be, then propose a patch
<ogra> oh, less isnt autodetecting .gz files anymore ?
<Keybuk> asac: ?! why is NM even _writing_ to /etc/hosts?
 * ogra was used to that 
<tjaalton> are hald/gdm startup priorities going to change for intrepid? there are bugs where people don't have a working keyboard/mouse before restarting X
<asac> Keybuk: it doesnt do that anymore ... except when you change the hostname ;)
<tseliot> ogra: ok. Let me know if that happens again.
<Keybuk> asac: oh, change the hostname in NM?
<Keybuk> I noticed something deleted my custom bits from there
<ogra> tseliot, will do
<Keybuk> and I now appear to have the machine's hostname twice
<asac> Keybuk: yeah ... now you can do: echo newname > /etc/hostname ... or send a dbus-send ... to change it through NM
<Keybuk> once on 127.0.0.1 where it should be
<Keybuk> and another time on 127.0.1.1 ?!
<ogra> 127.0.0.1 should only be localhost, no ?
<Keybuk> ogra: no?
<ogra> while 127.0.1.1 should be the actual hostnale
<ogra> *name
<Keybuk> that's just bogus
<Nafallo> ogra: yes
<Keybuk> I got rid of 127.0.1.1
<Keybuk> and it's come back
<liw> asac, I'm now ready to install nm with my phone and gprs, over a cable (after I have a bite to eat); is it useful to do that before I flash the phone to a current (only two years old) firmware?
<liw> asac, or should I flash the phone first?
<Keybuk> ogra: why can't 127.0.0.1 be the hostname? :)
<asac> liw: what phone is that? we should at least try to do it without firmware upgrade imo
<ogra> Keybuk, no idea, i just noticed it is like that when i installed this laptop with hardy
<liw> asac, nokia e61; I will flash the phone first then, no worries
<asac> liw: why flash first?
<Keybuk> 127.0.1.1 isn't even _valid_
<ogra> thogh checking now it apparently has changed
<ogra> ogra@osiris:~$ cat /etc/hosts
<ogra> 127.0.0.1	osiris	localhost.localdomain	localhost
<ogra> 127.0.1.1	osiris
<liw> asac, er, sorry, I misread
<Keybuk> it just happens to work because of a freak of the way that Linux implements the loopback network device
<asac> liw: lots of users will most likely not flash their phone ;) ... so lets try unmodified if possible
<ogra> i know in hardy there was only "localhost.localdomain localhost" for 127.0.0.1
<Keybuk> asac: is NM setting the hostname to be 127.0.0.1 or 127.0.1.1? :?p
<cjwatson>    127.0.0.0/8 - This block is assigned for use as the Internet host
<cjwatson>    loopback address.
<cjwatson> RFC3330
<liw> asac, lots of people with that firmware version _will_ flash their phone, since it has bugs that make one assume Nokia has never, ever made a phone before... things like the red phone button not hanging up on a call
<ogra> and 127.0.1.1 had the hostname ...
<asac> Keybuk: would have to look. maybe both?
<Nafallo> exactly. 127.0.0.0/8 is valid.
<rom1v> cjwatson: in gnome-wm, don't you think the special case handling for dapper upgrades should be removed?
<asac> Keybuk: whats the difference of 127.0.1.1 and 127.0.0.1?
<cjwatson> rom1v: not my code
<Keybuk> cjwatson: that's quite new? RFC1700 only ever allowed 127.0.0.1/32 ?
<cjwatson> rom1v: file a bug if you want it changed
<rom1v> yes, I imagine :)
<asac> why would anyone not want either?
<liw> asac, so yeah, I'll try first without flashing, I'll report any problems/patches later
<rom1v> ok, I will (not for that problem, but for nvidia problem)
<ogra> Keybuk, i think windows did it since ages like that
<ogra> cant be *that* new
<asac> liw: right. first step: 1. does NM detect your phone. if not -> patch hal-info  :)
<asac> then it becomes interesting i guess
<cjwatson> Keybuk: RFC1700 says:
<cjwatson>       (g)   {127, <any>}
<cjwatson>          Internal host loopback address.  Should never appear outside
<cjwatson>          a host.
<Keybuk> cjwatson: why do Debian set the hostname to a different IP though?
<cjwatson> Keybuk: Debian bug 316099
<ubottu> Debian bug 316099 in netcfg "Please give system hostname IP address 127.0.1.1" [Unknown,Closed] http://bugs.debian.org/316099
<cjwatson> it's to work around other problems
<Keybuk> so the reverse of the hostname is the hostname?
<Nafallo> Keybuk: Sept. 2002 by the looks of it.
<cjwatson> http://lists.debian.org/debian-boot/2005/06/msg00639.html is the root of the thread
<Keybuk> the thread doesn't really specify any problems though
<cjwatson> there is something wrong with the setup, but I don't think just reverting that netcfg change is the right answer; we'll just get a different set of problems
<Keybuk> the thread starts with a "should always" assertion
<cjwatson> I'm afraid I don't have the references to hand, but I remember that thread coming after an enormous series of problems due to hostname reversal problems
<Keybuk> but that seems to be the only thing made true by the way it's set up
<cjwatson> the netcfg change replaced those problems with a smaller set of problems
<Keybuk> well, normally you'd have
<Keybuk> IP  FQDN  HOSTNAME
<Keybuk> so a lookup of "IP" or "HOSTNAME" replies "FQDN"
<Keybuk> e.g.
<Keybuk> 87.194.19.205  quest.netsplit.com quest
<Keybuk> but if doing DHCP, there's an adversion to putting the hostname in that file
<Keybuk> since the IP could be anything
<cjwatson> the desired properties were (a) reverse(127.0.0.1) == localhost (b) reverse(forward(system hostname)) == system hostname
<Keybuk> in theory, you should never have the hostname in that file ;)
<cjwatson> that makes forward(system hostname) == 127.0.0.1 impossible
<Keybuk> but I guess there are(were?) things that relied on it being there?
<cjwatson> yes
<cjwatson> still are; I believe sudo is one
<rom1v> cjwatson: https://bugs.launchpad.net/ubuntu/+bug/215876 (my last comment)
<StevenK> sudo only warns now, I think
<ubottu> Launchpad bug 215876 in ubuntu "compiz & nvidia-settings" [Undecided,New]
<Keybuk> I can't think of any problem that would actually caused by the lookup look resolving to localhost or 127.0.0.1
<Keybuk> other than someone's aesthetics being offended
<cjwatson> rom1v: I would appreciate no longer being part of this conversation; it is not my area
<rom1v> ok, sorry
<cjwatson> Keybuk: so what is the problem it's causing now?
<cjwatson> other than your aesthetics, that is :)
<Keybuk> cjwatson: well, now, something is sticking it back in my hosts file
<ogra> heh
<Keybuk> which means it's got two different IPs
<Keybuk> and now local traffic is actually going to 127.0.0.1 not the real IP
<Keybuk> which broke my apache virtual setup :p
<cjwatson> ok, that's entirely separate from the installer doing it to start with
<Keybuk> yeah, I'm only wondering why it got added twice
<cjwatson> maybe update-manager is being overenthusiastic or something
<Keybuk> cjwatson: NM apparently?
<Keybuk> I can't find it in update-manager
<ogra> likely nm
<Keybuk> I didn't have it in /etc/hosts at all
<ogra> with its new setting of hostnames philosophy
<Keybuk> now it's come back twice
<Keybuk> (and annoyingly removed my own custom entries)
<ogra> Keybuk, yep, its definately NM, booting without usplash even tells you it sets the hostname
<ogra> and it just mangled my 127.0.0.1 line in /etc/hosts
<ogra> adding the hostname on front of "localhost.localdomain   localhost"
<ogra> instead of just setting 127.0.1.1 only
<asac> ogra: have you tried the latest NM?
<ogra> the one that hasnt built yet ?
<ogra> no
<asac> ogra: it has ;)
<ogra> i upgraded 1h ago
<ogra> ah, there it is
 * ogra installs
<asac> ogra: be sure you restarted NM and killall nm-system-settings
<ogra> i'll reboot after changing the 127.0.0.1 line in /etc/hosts
<ogra> asac, erm
<ogra> ogra@osiris:~$ wc -l /etc/hosts
<ogra> 42 /etc/hosts
<ogra> it changed the 127.0.0.1 line again *and* added 31 newlines to the end of the file
<asac> ogra: was it 41 before you rebooted? or 31?
<ogra> it was 11 lines
<asac> ogra: ok
<asac> so 127.0.1.1 is what debian uses as loopback address?
<ogra> and only one empty one in the middle
<ogra> (between ipv4 and v6 settings)
<ogra> the 31 empty ones got appemded apparently
<ogra> *appended
<asac> ogra: are you 100% sure that those got appended in this reboot?
<ogra> pretty, yes, my vim had a tilde after the last line while editing
<asac> ogra: ok. so you did what? remove 127.0.0.1 line from hosts?
<ogra> no
<ivoks> ogra: you are lucky... my /etc/hosts has 310 lines; most of them empty :)
<ogra> i changed:
<ogra> 127.0.0.1   osiris  localhost.localdomain   localhost
<ara> if any one is interested in testing infrastructure, cr3 is giving now a session at #ubuntu-classroom
<ogra> to:
<ogra> 127.0.0.1   localhost.localdomain   localhost
<ogra> then rebooted
<asac> ok let me try
<ogra> and have: 127.0.0.1   osiris  localhost.localdomain   localhost
<ogra> plus the empty lines
<ivoks> asac ogra i can confirm this; same thing happens to me
<davmor2> ï»¿if any one is interested in testing infrastructure, cr3 is giving now a session at #ubuntu-classroom
<kirkland> Riddell: hi, are you around?  Can I get you to promote musica to the universe archive?  It's in the queue.
<asac> ogra: is ifupdown enabled in /etc/NetworkManager/nm-system-settings.conf ?
<ogra> [main]
<ogra> plugins=ifupdown,keyfile
<ogra> [ifupdown]
<ogra> managed=false
<ogra> never touched it
<asac> yeah
<asac> thats fine
<Ng> hmm, is showing avahi network printers still off by default in intrepid?
<asac> i cannot reproduce by restarting NM and nm-system-settings
<asac> i will look in code now
<Riddell> kirkland: let me look
<Ng> where by "avahi" I probably don't mean avahi, I mean whatever broadcasting cups does
<asac> ogra: is your /etc/hostname updated through some other mean during startup?
<kirkland> Riddell: thanks!
<ogra> i didnt manually restart them, but rebooted, probably it behaves differently in that case
<ogra> asac, not on purpose at least
<kirkland> Riddell: slangasek asked me to ask someone else; he was swamped ;-)
<kirkland> Riddell: and you helped me with update-motd last time
<soren> Keybuk: I haven't followed the discussion (kind of in the middle of something here).. Is the mountnfs thing sorted, or do I still need to look into it?
<Riddell> siretart: ffmpeg in queue?
<Keybuk> soren: I've blamed dist-upgrader
<Keybuk> soren: the shell code in mountnfs is buggy in so many ways
<Keybuk> so there's no point even trying to mitigate the problem there
<asac> ogra: yeah. only reason i could see that it behaves differently is when hostname isnt set at all at the time NM starts
<kirkland> soren: Keybuk: nfs mounts not happening on boot?
<asac> ogra: but i am looking at code now
<ogra> asac, well, /etc/init.d/hostname.sh sets it
<Keybuk> kirkland: yes
<kirkland> soren: Keybuk: i saw this just last night on my mythfrontend upgrade from hardy to intrepid
<asac> ogra: can you please paste your /etc/hosts?
<ogra> though it doesnt change the file, but calls hostname
<soren> Keybuk: Ok.
<Keybuk> ogra: that only writes to /proc/hostname
<Keybuk> kirkland: can you ssh to it?
<ogra> Keybuk, yeah
<kirkland> Keybuk: yes
<asac> most likely calls hostname based on what currently is in /etc/hostname ?
<Keybuk> kirkland: do you have a final newline in /etc/fstab ?
<ogra> asac, http://paste.ubuntu.com/54665/
<Keybuk> asac: needlessly more complicated than that, but yes
<ogra> pastebin cuts off the empty lines
<siretart> Riddell: yes
<kirkland> Keybuk: i did, but I deleted it
<siretart> Riddell: it is targeted for multiverse
<Keybuk> kirkland: you deleted it?!
<Keybuk> kirkland: the newline or fstab? :p
<Riddell> siretart: don't we already have an ffmpeg?
<siretart> Riddell: 'ffmpeg-debian' should stay in main, however
<kirkland> Keybuk: the trailing newline :-)
<Keybuk> why did you delete it?
<siretart> Riddell: 'ffmpeg' contains 'replacements' libraries with the excluded encoders in, plus linking to some other stuff in multiverse
<Keybuk> anyway, that file won't work if it doesn't have a trailing newline :)
<kirkland> Keybuk: because i have a vimrc that highlights in bright red trailing whitespace of any kind and i tend to prune things like that
<asac> ogra: ok. so the problem comes up  when you remove the "osiris" from the first line?
<siretart> Riddell: that's basically the implementation of the plan I crafted some months ago
<ogra> asac, right, it gets re-added
<soren> kirkland: When you say it had a trailing newline, do you mean that you had an empty line at the end?
<siretart> Riddell: are you currently processing it?
 * soren is not even sure how he'd get vim to save a file without a trailing newline..
<cjwatson> :set binary noeol
<soren> cjwatson: That's handy. Thank you.
<rom1v> cjwatson: thank you very much for your help, I know it's not your piece of code, but the information you gave me allowed me to fix the problem :)
<cjwatson> I've never heard of vim highlighting a trailing newline though
<cjwatson> rom1v: no problem
<cjwatson> because, err, it isn't really trailing whitespace on a line :)
<rom1v> but I imagine, no chance that the fix will be included in intrepid?
<Keybuk> indeed, vim tends to vaguely mention if you *don't* have a trailing newline
<Keybuk> [noeol] in the buffer
<Riddell> kirkland: the licencing is incomplete.  there's no GPL included.  index.php suggests its GPL 3 and CC2.5 but debian/copyright says GPL2+ with no mention of CC2.5
<asac> so the debian way of doing things is to have the hostname mapped to 127.0.1.1 ?
<Keybuk> and when you save it, puts one in anyway :p
<kirkland> Riddell: ah, right, icons are CC2.5
<asac> and 127.0.0.1 only mapping to localhost and localhost.localdomain?
<Keybuk> asac: no localhost.localdomain iirc
<Keybuk> 127.0.0.1 localhost
<Keybuk> 127.0.1.1 hostname
<Keybuk> BUT ONLY if 127.0.1.1 exists
<kirkland> Riddell: i'm not sure how that happen, i'll clean it up immediately.
<Keybuk> if 127.0.1.1 does not exist, do not add it
<soren> Keybuk: It does indeed. Quite annoying if you've been editing binary files (%!xxd + %!xxd -r style).
 * ogra had localhost.localdomain in a fresh hardy install
<asac> Keybuk: ok.
<Riddell> kirkland: rejecting.  please [have upstream] add full licence texts to the upstream tar, and ensure debian/copyright matches
<asac> i remember that debian systems had localhost.localdomain as well
<kirkland> Riddell: thanks.
<Keybuk> ogra: my hardy and intrepid installs don't have it - my pre-hardy does; so I assumed that it's gone
<Keybuk> I vaguely remember someone saying that it was invalid
<Keybuk> cjwatson: ?
<asac> yeah. i remember a bug about that. but i think it was a reverse lookup order thing
<Riddell> pitti: any sign of a new langpack upload?
<pitti> ArneGoetje: ^ we do have a newer base export and a delta tarball; can you please prepare an upload?
<cjwatson> Keybuk: I don't think it's changed recently
<cjwatson> Keybuk: what was your pre-hardy install originally?
<Keybuk> cjwatson: err, warty I think :p
<ogra> heh
<Keybuk> that one _has_ localhost.localdomain
<cjwatson> Keybuk: right, I think it went away in dapper
<Keybuk> I knew it had gone away at some point ;)
<cjwatson> Thomas Hood's change was Nov 2005
<cjwatson> (and there are dapper changes just above it in the changelog)
<cjwatson> asac: ubiquity/scripts/install.py line 1479+ has current rules
<Keybuk> why is NM doing this anyway?
<cjwatson> asac: or netcfg/netcfg-common.c:netcfg_write_common
<Keybuk> this is a bit "aha! I see you changed a file! I shall go do more stuff that you were about do do anyway, so when you edit the file, you'll be slightly puzzled"
<cjwatson> (the former is a transcription of the latter really)
 * ogra confirms in a freshly installed hardy vm there is only localhost, no trace of localdomain
<asac> ok
<Keybuk> there is no localdomain, only zul
<ogra> i think fedora uses localhost.localdomain still
<asac> and suse as well
 * ogra guesses it comes from there
<Keybuk> asac: so what, exactly, is NM doing?
<Keybuk> it's watching you edit /etc/hostname (or setting /proc/hostname ?) and editing /etc/hosts to match?
<asac> Keybuk: do you want the code?
<ogra> intrestingly my hardy /etc/hosts has: "127.0.1.1 ubuntu.local ubuntu"
<Keybuk> ogra: that's wrong on so many levels
<Keybuk> ogra: having .local in there may actually break things :p
<ogra> smells like avahi addition
<ogra> Keybuk, its a fresh install
<Keybuk> oh dear :)
<ogra> my hardy reference VM
<asac> Keybuk: it watches /etc/hostname and changes done there are propagated to /etc/hosts ... yes.
<Keybuk> asac: "why" ?
<asac> Keybuk: all this landed to support dynamic updated hostnames
<ogra> Keybuk, so you can change the hostname from NM
<asac> e.g. from dhcp and ppp and so on
<ogra> on the fly
<Keybuk> ogra: no, if it was doing that, it wouldn't _need_ to watch /etc/hostname ;)
<ogra> which gets funnny if done from a running X session
<Keybuk> asac: but doesn't changing the hostname underneath running things break them?
<Keybuk> sudo springs to mind
<asac> Keybuk: it breaks Xauth ... but thts a bug in how we start local x sessions
<cjwatson> ogra: the only way the installer could do that is if you (or something) told it your domain was "local"
<Keybuk> here's a better question
<Keybuk> it watches /etc/hostname ...
<ogra> cjwatson, i didnt
<Keybuk> does it actually look to see if you *set* that as the hostname? :p
<cjwatson> "or something"
<asac> Keybuk: at best join #nm ;)
<ogra> its a plain alternate install
<asac> thats the best place to get input from the master ;)
<Keybuk> asac: I just don't see what it's fixing here
<Keybuk> while seeing a lot of breaking
<asac> Keybuk: there might be glitches here and there. especially since debian does it different
<Keybuk> if you get a DHCP response with a hostname, why would you edit /etc/hostname?
<Keybuk> you'd just set /proc/hostname directly
<asac> Keybuk: assume hosts is properly rewritten and xauth is fixed. what other breakage is left?
<Keybuk> and since you're on an active network, there's no need to put that in /etc/hosts
<asac> Keybuk: no
<Keybuk> why no?
<asac> Keybuk: we dont edit /etc/hostname
<soren> Why is it that we want the hostname to change based on dhcp, by the way?
<asac> when you get dhcp response
<cjwatson> ogra: I'm just describing the behaviour of netcfg. I'm not saying you're not seeing what you're seeing, but I don't see anything in the installer that could possibly do that so I'm suggesting that perhaps the cause is something else
<Keybuk> asac: exactly
<Keybuk> so what is NM watching again? :P
<Keybuk> you said NM was watching for /etc/hostname changes ...
<Keybuk> but we *don't* edit /etc/hostname
<asac> Keybuk: NM edits /etc/hostname for instance ... or you do that in vi
<ogra> cjwatson, yeah, i didnt mean to argue with you about that :)
<Keybuk> but why would NM edit /etc/hostname?
<Keybuk> that's just wrong
<Keybuk> tbh, it's not entirely clear to me why you even need to change the system hostname
<Keybuk> but I can appreciate that it would be nice in some situations
<asac> Keybuk: so: NM applet gets a widget "hostname" where you can change your hostname
<Keybuk> at most, dynamic hostname is a change to the *current* hostname
<Keybuk> (ie. set /proc/hostname)
<asac> Keybuk: that gets sent to NM daemon, which propagates that request to the system integration plugin ... which then updates hostname
<soren> I don't even want it to do that.
<Keybuk> you don't need to put that in /etc/hostname, since you can guarantee it's not permanent
<Keybuk> and you don't need to put that in /etc/hosts either
<Keybuk> asac: sure, that makes sense as a method
<Keybuk> but you said it was watching the system and doing this itself automatically as well?
<soren> I dont' see the point, really. It messes up samba url's, .local hostnames, etc., etc.
<asac> Keybuk: right. so. given that nothing touches /etc/hostname exept NM through that dbus method or you through "vi", i dont see that the "watching" is a issue on its own
<Keybuk> asac: but other things will touch /etc/hostname
<Keybuk> like the sysadmin
<Keybuk> and NM should not be going and mucking around on its own
<asac> Keybuk: what you complain about is that the hosts rewrite is buggy atm ;)
<Keybuk> hell, I can touch /etc/hostname by using bzr :)
<Keybuk> no, I'm complaining that it does it at all
<Keybuk> if *I* change /etc/hostname, *I* will change /etc/hosts
<Keybuk> I don't need NM being smart
<cjwatson> I agree that a sysadmin intentionally editing /etc/hostname and /etc/hosts in sequence is going to get desperately confused by something doing the latter for him
<Keybuk> especially since it could break things in the process
<cjwatson> we definitely shouldn't be applying inotify watches to files in /etc like this
<Keybuk> cjwatson: not to mention the sysadmin is likely racing NM
<cjwatson> yes
<cjwatson> it doesn't matter how correct the file rewrite is
<Keybuk> it's valid for NM to apply a change to /etc/hostname and /etc/hosts because it was *told* to by method call
<Keybuk> I cannot understand a scenario where NM would be told to do this by anything other than a "Change Hostname" button
<Keybuk> and I cannot understand any scenario where NM would apply the change automatically because of something else it saw happen
<asac> Keybuk: so why do you touch /etc/hostname using bzr? without wanting your hostname to be like that?
<Keybuk> asac: I frequently fiddle in /etc yes
<Keybuk> and even better
<Keybuk> I often deliberately change a hostname
<asac> Keybuk: but if you change /etc/hostname you probably want your hostname to be like that
<Keybuk> and *DO NOT WANT IT APPLIED UNTIL THE NEXT REBOOT THANKS*
<Keybuk> asac: and I know to edit /etc/hosts as well
<Keybuk> because I'm clearly clever enough to know about /etc
<cjwatson> asac: turn it around: what justification does network-manager have for this surprising behaviour?
<cjwatson> network-manager is the thing that's changing here, and therefore it has the burden of proof
<cjwatson> it sounds like a "because it can" justification, and really, it's not useful to the sorts of people it's trying to "help"
<asac> the idea is to keep /etc/hostname in sync. i have no strong opinion on whether it should automatically apply the changes or not.
<Nafallo> the hostname are set during install. stop messing with it. kthxbai.
<Keybuk> this is also a good example of "it's best to get bogus behaviour right on the first try, otherwise people notice it" :-)
<ogra> not true
<asac> Nafallo: this is about something else. not about messing with hostname ;)
<ogra> yu can set hostnames by dhcp :P
<Keybuk> ogra: but you would never apply that to the disk
<Keybuk> the whole point of a DHCP hostname is that it's _dynamic_
<ogra> nah, to /proc
<Keybuk> you don't need it to hit the disk
<Keybuk> just set /proc/hostname and carry on
<Keybuk> it doesn't even need to be /etc/hosts - because the best bit is that it's only active all the time you're on that network anyway
<asac> Keybuk: again, dhcp hostname will not write to /etc/hostname :)
<stgraber> but it'll updated /etc/hosts right ?
<cjwatson> asac: that's what Keybuk is saying too
<asac> yeah, wasnt 100% sure if he said "DHCP doesnt need to do that - but NM is wrong" or "NM doesnt do that right now" :)
<Keybuk> you were justifying NM's strange behaviour as being for dynamic hostnames
<Keybuk> <asac> Keybuk: all this landed to support dynamic updated hostnames
<asac> Keybuk: yeah. that was the root cause why hostname support landed ;)
<Keybuk> and I was illustrating that none of this is necessary for that
<Keybuk> so all of this complex and error-prone editing of files is entirely unecessary
<Keybuk> and indeed potentially really quite dangerous
<Keybuk> consider a sysadmin doing a "bzr update" of their /etc
<Keybuk> bzr applies a diff to /etc/hostname
<Keybuk> and then to /etc/hosts
<Keybuk> MEANWHILE NM starts dicking around with it
<asac> Keybuk: yeah. NM approach is that you always get dynamic behaviour unless your system integration plugin says something different ;)
<asac> Keybuk: thats why the ifupdown plugin provides a hostname (fixed hostname)
<Keybuk> all that's going to happen is pain and misery
<Keybuk> asac: ???
<asac> Keybuk: also ifupdown provides write support so you can set your hostname through UI or dbus
<Keybuk> asac: I have no problem with that code
<Keybuk> asac: *what* is watching /etc/hostname for changes?
<asac> Keybuk: the inotify thing was a request by upstream. i dont mind to make it a configure option
<asac> configure - runtime config option
<Keybuk> if we can turn that off, I would feel much happier
<Keybuk> I don't think we want that on
<asac> Keybuk: thats not a problem at all. and i never said that your request is unreasonable. i just wanted to understand why users dont want the hostname to be updated if /etc/hostname changes
<asac> and if users dont want that if its really something that mainstream users dont want :/
<cjwatson> the hypothetical mainstream user won't care either way - if we're doing our job right they'll never hit this case
<Keybuk> asac: I think that the kind of user who is updating /etc/hostname knows about /etc/hosts
<cjwatson> the only users that care are non-mainstream
<asac> Keybuk: only reason i currently see for keeping inotify thing on is when some third party tool updates /etc/hostname and runs sethostname on its own while NM is running, that NM internal state about hostname might gets out of sync and _might_ (not sure) cause wierd behaviour.
<Keybuk> asac: the users that don't just want a button that says "Change Hostname"
<Keybuk> asac: it can update NM's state - that's fine -- it shouldn't go and rewrite /etc/hosts though (!!)
<Keybuk> because the third party tool could be *also* doing that
<Keybuk> hell, if they're on XFS, they could end up with null bytes where their /etc/hosts used to be <g>
<asac> Keybuk: ok. but then it becomes difficult. for dhcp/dynamic host updates NM probably has to update /etc/hosts
<Keybuk> asac: no it doesn't
<Keybuk> think about it
<Keybuk> it doesn't need to *touch* /etc/hostname *or* /etc/hosts
<Keybuk> they can stay as they were
<Keybuk> if it's a dhcp/dynamic hostname, it's only valid as long as the dhcp lease
<Keybuk> thus only ever needs to be set as the system hostname
<Keybuk> when the dhcp lease expires, you simply set the hostname back to whatever is in /etc/hostname
<Keybuk> and because that hostname is only valid all the time there's a network connection
<Keybuk> it _does_not_ need to be in /etc/hosts
<asac> Keybuk: and how does the reveser lookup work when dhcp lease is active?
<Keybuk> the hostname is only in /etc/hosts so you can lookup the hostname while there's no network connection
<Keybuk> asac: using this wonderful invention called "DNS"
<asac> ok.
<Keybuk> iirc. dynamic hostname over DHCP actually involves a DNS lookup anyway, so you know that works
<Keybuk> in fact, in most situations with dynamic hostname - the daemon doing dhcp also happens to be doing dns :)
<Keybuk> (dnsmasq or something)
<Keybuk> example
<Keybuk> your behaviour
<Keybuk> I have a hostname "laptop"
<liw> is /proc/hostname really /proc/hostname or /proc/sys/kernel/hostname?
<Keybuk> I boot up, my machine is called "laptop"
<Keybuk> liw: the latter, I was shortening
<Keybuk> I log onto a network
<Keybuk> I'm given the hostname guest-2341
<Keybuk> that's ok, I guess
<Keybuk> my laptop battery runs out
<liw> (fwiw, I fully agree with Keybuk about /etc/hosts and /etc/hostname handling: NM has no business touching them)
<asac> Keybuk: right. all agreed. so only thing that might be confusing (though definitly a corner case) is when some external tool updates /etc/hostname, and user/admin wants to change hostname in nm-applet and doesnt see the actual hostname ;)
<Keybuk> when I boot again, my machine is now called guest-2341 and hardcoded as such everywhere (!!)
<asac> but that is neglectable i think ;)
<Keybuk> my way:
<Keybuk> my machine is called "laptop"
<asac> (or fixable through some other mechanism)
<Keybuk> I log onto a network, and am given guest-2341
 * liw also doesn't want his hostname to change, ever, and will be cross at anything that changes it, thank you very much
<Keybuk> but this time, since neither /etc/hostname or /etc/hosts was touched - it's just changed online
<Keybuk> if I run out of power, and boot again
<Keybuk> my machine is _still_ called "laptop"
<Keybuk> asac: like I said, it's ok if NM updates its own internal data
<Keybuk> but arguably if it's showing the current hostname by reading /etc/hostname, it's broken anyway
<Keybuk> it should be just calling gethostname() :P
<asac> Keybuk: well. the current way would work too ... e.g. dhcp will only update /etc/hosts, but when you bootup /etc/hostname gives you "laptop" again so /etc/hosts is rewritten to "laptop" :)
<asac> but i dont want to argue that
<asac> i am not really a friend of inotify to update system configs on the fly
<asac> its what upstream doesn and i implemented it that way. i can make that an option for sure
<jcristau> /etc/hosts shouldn't be rewritten at all...
<liw> asac, please do disable any editing of /etc/hosts by default, thanks :) I'll buy you a beer :)
<asac> jcristau: i will carry that to NM maintainer. its always hard to stand in for something that isnt my idea ;)
<asac> at best join #nm which even allows flames according to /topic :)
<stgraber> hmm, let's just keep the good old (and well working) behavior at least for Intrepid, right ? :)
<liw> asac, and I appreciate your being in between two difficult parties, your colleagues on the one hand and NM upstream on the other
<TuniX12> who is responsible for artwork in ubuntu?
<Pici> The artwork team.
<Keybuk> TuniX12: please ask questions in #ubuntu-art
<Pici> #ubuntu-art
<TuniX12> the new theme and specially wallpapers are realyy horrible and unprofessional
<Keybuk> TuniX12: so is your spelling, and your asking of the question in this channel even when you've been asked not to
<TuniX12> keybuk: sorry english is not my native language can you speak french you i dont think so!
<Keybuk> oui ;)
<TuniX12> oO
<cody-somerville> Qui ne peut pas parler ces jours au franÃ§ais ?
<Keybuk> maintenant, posez votre question dans #ubuntu-art s'il vous plait
<Keybuk> kwwii: clearly, a fan
<ogra> Keybuk, hey, this is an english speaking channel :)
<mathiaz> mdz_: how long does the TB meeting last usually? 1 hour or 2 hours?
<ogra> tjaalton, i got contacted by a guy working on touchscreen support upstream at freedesktop, apparently he is trying to unify all tablet and touchscreen drivers into evdev
<ogra> tjaalton, he is willing to work closely with us in jaunty
<mathiaz> mdz_: because tomorrow's TB meeting is scheduled from 14:00 to 16:00 UTC (on the fridge) and the Server Team meeting is scheduled to start at 15:00 UTC.
<mathiaz> mdz_: So I'd like to know if the Server Team should start one hour later (16:00 UTC)
<slangasek> superm1: well, from what I've been able to track down, there's a regression in bluetooth audio support in 2.6.27... alsa fails with "BT_SETCONFIGURATION failed : Input/output error(5)"
<cjwatson> seb128: any objection to me just reverting the problematic change in intltool (bug 275795)? there's been no response from upstream yet ...
<ubottu> Launchpad bug 275795 in intltool "po/Makefile creation regressed in 0.40.4" [Undecided,New] https://launchpad.net/bugs/275795
<superm1> slangasek, so nothing to do with bluez 4.x however
<superm1> slangasek, perhaps within the transition from hci_usb to btusb in 2.6.27
<slangasek> superm1: right, it just means that I can't test it either way
<slangasek> without doing kernel archaeology
<superm1> was that 2.6.27rc8 or rc7?
<superm1> i know btusb had some delta to rc8
<slangasek> it was 2.6.27-4-generic :-P
<superm1> okay so that's rc7
<seb128> cjwatson: did it break any other build? did you workaround that in ubiquity? I would prefer waiting for upstream comment if there is nothing which push us to revert the change
<slangasek> superm1: ok, I can try later with 2.6.27-5-generic then
<cjwatson> seb128: I worked around it by reverting the change on my laptop, but that's no good as soon as somebody else needs to regenerate ubiquity's autotools
<cjwatson> seb128: at least oem-config would suffer the same problem; I don't maintain enough other intltoolish stuff to know
<seb128> cjwatson: I pinged upstream on IRC about the bug, what about reverting tomorrow if he doesn't reply?
<cjwatson> seb128: sure, that would be fine
<seb128> ok, let's do that then
<cjwatson> thanks
<seb128> cjwatson: <dobey> seb128: i'll fix it and make a release today.
<cjwatson> seb128: hooray
<cjwatson> found a new code drop of the totem BBC plugin in my spam-bin :-( so I'll be uploading that shortly once I've tested it a bit
<liw> asac, regarding my phone: I connect USB cable, tell phone to use USB for "IP through traffic" ("IP lÃ¤pivienti" in Finnish, I don't know what the phone says in English), NM notices it, starts doing dhcp on it, but never gets a response
<liw> asac, so now I don't know what to do next :)
<cjwatson> gar, running autoconf in totem produces a 30000+-line diff to 70_autotools.patch. (Running autoreconf is more like 70000+ lines.) What on earth were people using to autoconfiscate this?
<Keybuk> if you look at the original files, you should be able to tell
<cjwatson> it seems to be more reordering than actual changes
<Keybuk> I was more thinking of the great big version stamp ;)
<Keybuk> which would /directly/ answer your question, if perhaps not /helpfully/
<asac> liw: ok. did you use the wizard to configure your connection?
<cjwatson> seb128: is there a standard tool that people use to update autotools patches in desktop packages? the intuitive (to me) autoreconf -fi; quilt refresh produces lots of diffs that indicate people weren't using quilt to do it
<liw> asac, nope, it started doing dhcp on its own
<Keybuk> cjwatson: don't use -f ...
<cjwatson> Keybuk: ok, but irrelevant to my question
<Keybuk> but </broken record that people are long since past ignoring>
<cjwatson> -diff -Nurb totem-2.24.1/bindings/Makefile.in totem-2.24.1.new/bindings/Makefile.in
<cjwatson> ---- totem-2.24.1/bindings/Makefile.in  2008-10-01 16:00:53.000000000 +0200
<cjwatson> -+++ totem-2.24.1.new/bindings/Makefile.in      2008-10-02 00:16:29.000000000 +0200
<cjwatson> +Index: bindings/Makefile.in
<cjwatson> +===================================================================
<cjwatson> +--- bindings/Makefile.in.orig
<seb128> cjwatson: the totem autotools patch is only a configure update, usually we only run autoconf for those and aclocal too when required
<cjwatson> ++++ bindings/Makefile.in
<cjwatson> I'm talking about diffs like these
<cjwatson> seb128: what do you use to generate the patch file though? it doesn't look like quilt refresh
<asac> liw: so you ran into the "recommends dont get installed on upgrade bug" :) ... please see if installing libmbca0 and then creating a new connection helps
<asac> (selecting your proper provider in the wizard)
<cjwatson> (you plural)
<seb128> cjwatson: I tend to use cdbs-edit-patch because I dislike quilt (sometime that requires commenting the debian/rules quilt line though)
<seb128> cjwatson: but the other debian pkg-gnome guys use quilt
<liw> asac, it was already installed
<ogra> pitti, superm1 did any of forget you adjust my samsung Q1U patch to the new hal-info upload ? seems the samsung keyboard stuff now ended up in the toshiba area ...
<cjwatson> this was done by norsetto by the looks of things
<liw> asac, version 0.0.3~bzr42-0ubuntu2
<asac> liw: which applet version?
<asac> network-manager-gnome
<ogra> *any of you
<seb128> cjwatson: dunno how he did it then, but using quilt should work correctly
<liw> asac, 0.7~~svn20081005t082522-0ubuntu1
<asac> ok. all restarted i assume?
<liw> asac, rebooted and everything
<asac> liw: anyway. please go to connection editor and create a new connection. then you should see a wizard?
<asac> (new mobile broadband)
<nxvl> cjwatson: you already fix this issue, right? ->https://bugs.edge.launchpad.net/ubuntu/+source/debian-installer/+bug/279127
<ubottu> Launchpad bug 279127 in debian-installer "Corrupted screen in Intrepid server installer" [Undecided,New]
<liw> asac, what is the connection editor called in Finnish? (I don't understand nm-applet's UI...)
<cjwatson> seb128: it works, it's just ugly :-) I like to produce minimal debdiffs when working on other people's packages
<nxvl> i remember to see a patch somewhere but i can't find the bug
<liw> asac, or rather, where is it in the menu?
<cjwatson> nxvl: I did?
<BenHoltz> Hey guys, Question...  How far our of RC1 would you guys say we are?
<BenHoltz> out*
<cjwatson> BenHoltz: http://wiki.ubuntu.com/IntrepidReleaseSchedule
<superm1> ogra, i've only touched one fdi file with my upload, you'll have to see if pitti did anything though
<nxvl> cjwatson: i remember to see a patch when i was fixing the partman-ext3 issue, i think it was from you
<liw> asac, right mouse button menu, third item?
<asac> liw: right click on applet ... edito connections
<asac> yeah
<asac> liw: there is amobile broadband tab and you can create new connections there
<ogra> superm1, well, was it 30-keymap-misc.fdi ?
<nxvl> cjwatson: but i can be wrong
<superm1> ogra, no :)
<BenHoltz> ï»¿cjwatson: I guess a better question would be is it worth my time to do the upgrade now, or are there still Major holes left
<cjwatson> nxvl: oh, Dustin fixed that, bug 277153
<ubottu> Launchpad bug 277153 in mdadm "confirmation screen contains string errors when there are md or raid partitions" [Medium,Fix released] https://launchpad.net/bugs/277153
<cjwatson> nxvl: (feel free to dup)
<ogra> superm1, then it was pittis fault i guess :)
<nxvl> cjwatson: thank you!
<liw> asac, ok, done that, now I have one for my operator, and it say "ei koskaan" ("never" in Finnish)
<nxvl> i knew i saw a patch
<asac> liw: yeah. thats ok. (it tells you when you last used that connection)
<seb128> cjwatson: that's a good intend but don't bother about the autoconf patches format just use whatever tool is easier for you
<asac> liw: try to connect to it in the applet (the connection should be there)
<cjwatson> BenHoltz: from beta onwards we generally say that reasonably competent users can give it a go and report problems to us; there are of course still problems
<liw> asac, the UI doesn't make it at all clear what the "never" thing is... but that's less important than getting this to work
<cjwatson> seb128: ok, thanks
<liw> asac, I don't see any connection in the applet, should I disable the non-NM-managed networking first?
<BenHoltz> ï»¿cjwatson: Thank you sir! I will give it a go and let you know when I find anything that's not in the bug tracking.
<BenHoltz> and open a new bug along with it.. ;)
<cjwatson> well, don't let me know personally, I don't want to be a clearing-house for all bugs :)
<asac> liw: hmm. maybe try that. after changing the config you can sudo killall nm-system-settings to reread it
<BenHoltz> hahaha
<BenHoltz> thanks again...
<asac> liw: do you have ppp0 or something configured in /etc/network/interfaces?
 * BenHoltz disappears so productive work can go on without his pesky interruptions.
<liw> asac, I only have lo, eth0, and br0 in /e/n/i
<liw> asac, after the sudo killall, NM is again trying to do dhcp on eth1, which seems to be the phone
<asac> liw: ok. try to disable it. but unless its a bad applet bug it appears that NM just doesnt see your device at all
<asac> liw: eth1 is your phone?
<liw> asac, eth1 appears when I attach the phone and disappears when I detach it
<asac> liw: i doubt it ... also dhcp is not run on 3G ... thats ppp that doing the IP shuffleing
<asac> liw: wow
<liw> asac, disable it? disable what? how?
<asac> liw: /etc/NetworkManager/nm-system-settings.conf ... managed=true
<asac> liw: then killall like above
<liw> asac, perhaps I am choosing the wrong option in the phone, when I connect the usb cable?
<asac> liw: what options are available?
<liw> asac, should I use "PC suite" or "data transfer" or "ip tunnel" (I think tunnel is a better translation)?
<asac> try PC suite
<asac> that sounds familiar ;)
<liw> asac, now I get... in syslog, from the kernel, things like "usb 1-2: bad CDC descriptors" and "cdc_acm 1-2:1.10: ttyACM0: USB ACM device"
<liw> and more
<asac> liw: ok. and NM doesnt see your phone?
<liw> asac, correct, it does not see my phone
<asac> liw: do you get a result by: hal-find-by-capability --capability modem
<asac> ?
<liw> asac, yes
<mathiaz> cjwatson: I've udpated the description of some tasks used in the server install (tomcat, samba and virtualization). Should a new version of taskel be uploaded ?
<asac> liw: could you paste please
<asac> liw: also the tail of syslog when plugging the phone in would be helpful
<ogra> liw, that looks like a prob with the driver rather than NMs fault
<liw> asac, copying by hand, since the machine has no network... /org/freedesktop/Hal/devices/usb_device_421_44d_noserial_if0_0_serial_unknown_0
<ogra> "usb 1-2: bad CDC descriptors" is definately a driver message
<asac> liw: i need the complete output ;)
<liw> asac, just a minute, I'll put it back online
<liw> asac, http://paste.ubuntu.com/54694/
<asac> liw: ok. and the capability output?
<liw> asac, what's that?
<asac> 18:54 < asac> liw: do you get a result by: hal-find-by-capability --capability modem
<asac> liw: oh sorry ;)
<asac> lshal -u `hal-find-by-capability --capability modem`
<asac> liw: ^^
<liw> asac, just a minute
<cjwatson> mathiaz: ok, I'll do that soon
<liw> asac, http://paste.ubuntu.com/54696/
<asac> liw: yeah ok. you need to adjust modem fdi
<asac> liw: edit /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi
<asac> search for nokia
<asac> and add your product_id there
<ogra> hmm
<liw> asac, do I need to restart hal or something before I try again?
<kirkland> Riddell: hey, i've cleaned up the licensing inconsistency, new version pushed onto the queue
<asac> i think restart is enough.
<ogra> madwifi needs a SUSPEND_MODULES="ath_pci" andtry for pm-utils ... does anyone have an idea in which package to put that ? l-r-m or pm-utils rather ?
<seb128> cjwatson: oh, I noticed that my totem local source was outdated that's why I said we usually run only autoconf, you need the automake update for the new plugin, I just run autoreconf (using no argument) in those cases, I noticed that you have Makefile.in changes in the bbc patch, we usually prefer to split source changes and autotools updates, it makes easier to do update (the source changes usually apply easily and we can regenerate the autot
<seb128> ools changes)
<ogra> *entry
<asac> liw: ^^ you should be able to see the result in the lshal above: GSM should be in the command_sets (in addition to V.250 which you already had)
<mathiaz> cjwatson: great - thanks !
<superm1> ogra, that sounds like a regression wrg to needing to remove the module prior to suspend.  i thought it was suspend safe in the past?
<Riddell> kirkland: accepted
<ogra> superm1, no idea i didnt use it before
<kirkland> Riddell: outstanding, thanks so much
<ogra> superm1, the prob is that ath5k gets loaded even if its blacklisted ... so on resume ath5k replaces ath_pci
<ogra> which results in non working wlan on devices that dont work with ath5k
<superm1> ogra, oh that's quite an interesting problem with ath5k loading
<liw> asac, whee! now it works
<superm1> ogra, did you bug the kernel guys about that yet?
<ogra> superm1, yeah, especially that it doesnt respect blacklisting
<liw> asac, should I file a bug with a patch? network-manager?
<ogra> not yet, it was low on my todo
<liw> asac, or rather: hal-info ?
 * ogra takes that over to -kernel
<asac> liw: yeah please against hal-info
<asac> liw: pitti will apply that upstrem and in our package
<asac> liw: thanks for testing ;)
<asac> liw: ip tunnel is definilty iteresting though :)
<liw> asac, I assume it is related to wifi on the phone
<asac> liw: if you understand what that does  let me know ,)
<liw> now that I think abou tit
<asac> liw: yeah. if you get it working that would be cool :) ... if its just dhcp that doesnt work you could also create a connection with static IP
<asac> liw: you know where the connection editor is ;) in case you want to play a bit with it
<liw> asac, the phone has no wifi to connect to...
<asac> liw: oh ok :)
 * asac has to run bbl
<liw> asac, the phone has some kind of "connection editor" inside it, too... which is a) way confusing and b) crashes
<james_w> liw: hey, is your system-cleaner update bugfix-only?
<liw> james_w, yes
<liw> james_w, in my opinion, anyway
<james_w> hmm, I spy displaying the version number at startup, sounds like a feature to me :-)
<liw> james_w, that's a bug fix, it prevents people from claiming they have updated to a new version when they haven't :)
<james_w> liw: looks like it to me. Size of diff isn't so important, just makes review harder. I'm looking at it now.
<james_w> liw: that argument works for me :-)
<liw> asac, https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/279182
<ubottu> Launchpad bug 279182 in hal-info "Nokia E61 info for hal-info" [Undecided,New]
<jcastro> kees: Is this the only bug for tracking getting webcams to work? https://bugs.edge.launchpad.net/ubuntu/+bug/260918/
<ubottu> Launchpad bug 260918 in ubuntu "[needs-packaging] libv4l" [Wishlist,Confirmed]
<jcastro> kees: wrt. your post to -devel a month ago
<Ng> does firefox have any gvfs support?
<kees> jcastro: afaik, yes.  pgraner was looking into it as well
<jcastro> kees: ok, I was just checking the calendar. :D
<kees> jcastro: yeah, it's making me nervous
<jcastro> especially since stemp had it in his ppa for about a month
<jcastro> maybe at UDS we need to discuss PPA->distro workflow smoothage or something
<cjwatson> seb128: OK, I'll try to unpick those
<kirkland> tkamppeter: ping
<kirkland> tkamppeter: got your message in the bug, i can pull the data you want, right quick, if you're around
<kirkland> Keybuk: okay, sorry distracted...  I added a trailing carriage return to my /etc/fstab, nfs mounts still not happening automatically on boot
<kirkland> Keybuk: was that supposed to 'solve' the problem?
<lukehasnoname> In Intrepid 64 bit, how can I rid myself of the error caused by bug #273833
<ubottu> Launchpad bug 273833 in v86d "v86d missing from initramfs" [High,Triaged] https://launchpad.net/bugs/273833
<lukehasnoname> First, can I get around it and boot, and second, how can I fix it? Booting up to a terribly loud system error beep at 4am does not make the roommate happy.
<Keybuk> kirkland: it solved my bug
<Keybuk> you obviously may have a different bug :-)
<kirkland> Keybuk: looks so
<kirkland> Keybuk: i'll dig, this one is bothering me ;-)
<tkamppeter> kirkland, yes, I am here.
<Keybuk> I debugged by added
<Keybuk> exec 2>/var/run/nfsmount.$IFACE
<Keybuk> set -x
<Keybuk> to the top of the script in /etc/network/if-up.d
<cjwatson> lukehasnoname: as far as I know, the bug as described is mainly cosmetic. If you're getting an error beep, have you considered the possibility that you in fact have a different bug (even if the output above is the last thing you see on the console)?
<cjwatson> lukehasnoname: pretty much everyone running intrepid experiences bug 273833, and most of us can boot
<ubottu> Launchpad bug 273833 in v86d "v86d missing from initramfs" [High,Triaged] https://launchpad.net/bugs/273833
<kirkland> tkamppeter: http://pastebin.ubuntu.com/54711/
<lukehasnoname> Something simple that I didn't try: Can I just hit "Enter" and move past the error?
<lukehasnoname> and point taken about the "different bug"
<cjwatson> lukehasnoname: since you're probably encountering something different and as yet undetermined, it's hard to say ...
<lukehasnoname> hm
<cjwatson> one easy way to find out ;-)
<lukehasnoname> Well, I'm already installing hardy because I got pissed
<lukehasnoname> >_>
<lukehasnoname> but I might try again with the beta, depending on my mood when I get home
<cjwatson> well, intrepid is for people eager to find out the reasons behind problems ;-)
<tkamppeter> kirkland, foomatic-rip generates temporary files with names foomatic-sdfhjsfg, but why are they created in /dev/shm? What is /dev/shm good for?
<slytherin> hi all, is there any workaround for bug #276349? I am not able to use the alternate CD image for daily upgrade.
<ubottu> Launchpad bug 276349 in apt "intrepid alternate CD make apt print out a warning" [Low,Triaged] https://launchpad.net/bugs/276349
<cjwatson> slytherin: I don't think so at present
<lukehasnoname> cjwatson: I'm aware. I'll consider what's been said, though assuming my hardy install isn't broken, I'll probably stick with that at least until the 30th.
<siretart> \o/ ffmpeg accepted! thanks for that!
<lukehasnoname> thanks
<cjwatson> lukehasnoname: the risk is that it may be a problem nobody else is encountering, and so won't get fixed :-(
<lukehasnoname> damnit, don't guilt me into testing....
<kirkland> tkamppeter: /dev/shm is a tmpfs filesystem in memory
<lukehasnoname> UGH
<kirkland> tkamppeter: high speed, not written to disk
<kirkland> tkamppeter: i symlink my /tmp to /dev/shm
<kirkland> tkamppeter: shm = shared memory
<lukehasnoname> I'll be back on later, class is over.
<kirkland> tkamppeter: perms on /dev/shm are drwxrwxrwt
<tkamppeter> kirkland, then you manual deviation of the standatd config causes the bug, probably all programs which use an added security architecture, like AppArmor or SELinux would break on your system, as long as you do not manually correct all the config files for these architectures.
<kirkland> tkamppeter: i should be able to add the appropriate label or something /dev/shm, no?
<tkamppeter> kirkland, but CUPS is AppArmor-protected, it can only write to locations which AppArmor allows via the /etc/apparmor.d/usr.sbin.cupsd file.
<mdz_> mathiaz: it lasts anywhere from 30 minutes to 2 hours depending on the agenda
<tkamppeter> You must edit this file to get your printing working again.
<mdz_> mathiaz: if you are only available for the first part of the scheduled time, then just let us know and we should be able to accomodate you by ordering the agenda accordingly
<tkamppeter> kitkland and Intrepid has a lot of files in /etc/apparmor.d, you probably also need to edit the files of other programs, too.
<jdstrand> kirkland: fyi, symlinks are 'normalized' to the actual path in apparmor (by design)
<kirkland> jdstrand: should /dev/shm be added to some swath of profiles?
<mathiaz> mdz_: well - I'm not planning to attend the TB meeting. I'm interested to know if the Server meeting shoudl be moved one hour later.
<kirkland> jdstrand: i didn't think my linking /tmp -> /dev/shm was all that unusual
<jdstrand> kirkland: I only caught the tail end of this...
<kirkland> jdstrand: cups/printing stopped working for me last week
<tkamppeter> kirkland, the new foomatic-rip solves the problem by checking several temporary file locations, including /var/spool/cups/tmp, so installing the new foomatic-rip should also solve the problem.
<kirkland> jdstrand: with tkamppeter's help, i think we've narrow the problem to the fact that my /tmp is a symlink to /dev/shm
<kirkland> tkamppeter: cool, thanks.
<kirkland> jdstrand: i'm just wondering if we might see any other problems creep up
<jdstrand> kirkland: it may not be unusual, but it is non-standard, and off-hand, I am uncomfortable giving that access by default
<jdstrand> kirkland: but you should see all the errors in /var/log/kern.log if it is indeed part of the problem
<mdz_> mathiaz: the average meeting is <=1 hour, so there will only be a conflict for especially long-running meetings
<mdz_> mathiaz: i.e. I don't think it's necessary to move it
<kirkland> jdstrand: okay, i'll beware
<mdz_> mathiaz: it has always been at this time. so if you haven't noticed a problem, that's not expected to change
<mathiaz> mdz_: ok.
 * ogra curses once more about quilt
<radix> when upgrading using update-manager or do-release-upgrade, does it upgrade including -updates from the new distribution?
<geser> Hi, is a core-dev around who has some time to sponsor bug #264554?
<ubottu> Launchpad bug 264554 in xen-3.3 "libxen3 and libxen3-dev both include /usr/lib/libblktap.so" [High,Confirmed] https://launchpad.net/bugs/264554
<zul> geser: ill do it right now
<geser> zul: thanks
<slytherin> radix: -updates have packages only after the new release is made. It is of no use for development release.
<ogra> radix, while slytherin is right, ${next release}-updates lines are by default in sources.list after a dist upgrade (even in development releases)
<radix> ogra: thank you
<slytherin> cjwatson: am I correct to assume that it is you who implemented 'last good boot' feature?
<ogra> slytherin, that was BenC iirc
<cjwatson> slytherin: no; what led you to that conclusion?
<slytherin> cjwatson: I was confused probably.
<cjwatson> (ogra is correct)
<slytherin> ogra: cjwatson: any idea what all changes did it involve? I am using grub2 currently and the entries are not added to menu.
<ogra> slytherin, there were docs about it on the wiki and there was a blueprint for it
<ogra> (dont ask for URLs though)
 * slytherin searches
 * cody-somerville hides.
<tjaalton> ogra: sÃ¸ren hauberg? cool, wonder if it would replace wacom_drv though, but likely evtouch at least
<ogra> tjaalton, yeah, soren
<ogra> well, he wasnt aware that there are six drivers we'll go over them in jaunty
<ogra> evtouch is only one
<slytherin> ogra: not able to find anything related to last-good-boot in wiki or blueprints. Didn't even find any link on BenC's blog. :-(
<ogra> https://wiki.ubuntu.com/KernelTeam/removing-old-kernels
<slytherin> ogra: thanks, I will see if I can modify grub2 to include the feature.
<ogra> best tal to BenC
<ogra> *talk
<slytherin> sure
<kirkland> tkamppeter: thanks, fix verified, printer works with foomatic-rip updates!
<slytherin> is any archive admin around? I am waiting for some java libs to be moved to universe to work on their rdepends/reverse-build-depends.
<ahasenack> jibel: nice call on #278518, that was bugging me a while. We have others which I can now trace to the root cause
<ahasenack> jibel: thanks
<jibel> ahasenack: you're welcome
<Laney> asac: Is this FF bug reported? Seeing this when downloading things: http://orangesquash.org.uk/~laney/ff
<asac> Laney: locale?
<Laney> asac: en-gb
<Laney> asac: Hmm, getting it on the about dialog too
<james_w> Laney: have you updated today?
<Laney> james_w: Yep
<Laney> I didn't restart though.
<james_w> I'm seeing that too, and it often happens when firefox updates and you don't restart
<Laney> Strange, I've never had it before
<Laney> Oh, restarting did fix it ;)
<Laney> asac: Never mind.
<Laney> thanks james_w
<james_w> which-pkg-broke isn't hinting at anything mozilla related updating for me today though
<james_w> and there wasn't a firefox restart notification, but there was a system one.
<Laney> No there wasn't a firefox one, hence why I didn't restart it
<sebner> james_w: new kernel update ;)
<Laney> Grr, this PA bug is irritating
<asac> Laney: from which version did you upgrade and are you using ubufox?
<Laney> asac: FF didn't update today, and yes I am
<asac> Laney: ok. could you look in /var/log/apt/term.log to see if you got language pack updates today?
<asac> or maybe extension packages
<james_w> asac: I got language-packs, and totem-mozilla
<asac> james_w: so you had the same issue?
<asac> (today)
<james_w> asac: yeah, it sounds like it
<james_w> e.g. view source gives XML parsing error: undefined entity
<Laney> asac: I got language-pack-en updates if that's what you're after
<Laney> can't see anything else
<Laney> language-support-translations-en
<Laney> Oh no, ignore that last one, that was later
<TheMuso> sbeattie: I am well aware of that bug. It doesn't always occur, and there are other symptoms and behaviors, as it is a race condition. I will be looking at it today.
<RAOF> TheMuso: Have you heard anyone else complain that the alsa->pulseaudio routing breaks skype on x86-64?
<BenHoltz> hey guys, are there known issues with compiz?
<cjwatson> err, yes - https://bugs.launchpad.net/ubuntu/+source/compiz/+bugs
 * BenHoltz asked a dumb question..
<cjwatson> I suspect you wanted to ask a more specific question
<BenHoltz> haha
 * ScottK suspects wanting a more specific answer.
<desrt> +1 colin's jerkpoints :)
<BenHoltz> I'll go ask in #ubuntu+1
 * BenHoltz just read topic and is leaving disgracefully...
* mthaddon changed the topic of #ubuntu-devel to: Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | bazaar.launchpad.net down from 22:00 UTC 
* mthaddon changed the topic of #ubuntu-devel to: bazaar.launchpad.net down from 22:00 UTC for up to 4 hours | Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.co
<wgrant> Which fruit is replacing vostok?
<cjwatson> desrt: I wasn't actually trying to be a jerk, I figured I might as well give him a useful link as well as gently suggesting that he might want to be more specific :)
<spm> wgrant: crowberry
* Laney changed the topic of #ubuntu-devel to: bazaar.launchpad.net down from 22:00 UTC for up to 4 hours | Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com
<wgrant> spm: Aha.
<Laney> What should that link be?
<james_w> Laney: HelpingWithBugs I believe
<Laney> Works for me
* Laney changed the topic of #ubuntu-devel to: bazaar.launchpad.net down from 22:00 UTC for up to 4 hours | Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for https://wiki.ubuntu.com/HelpingWithBugs
* cjwatson changed the topic of #ubuntu-devel to: bazaar.launchpad.net down from 22:00 UTC for up to 4 hours | 8.10 beta released | archive: Feature Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> just saving a few characters ...
* cjwatson changed the topic of #ubuntu-devel to: bazaar.launchpad.net down from 22:00 UTC for up to 4 hours | 8.10 beta released | archive: Feature Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<wgrant> Poor Edgy. Always forgotten.
<RAOF> Heh.
<ajmitch> is it EOL?
<cjwatson> might have something to do with it being EOL, yes :)
<cjwatson> don't think the fine distinction is worth precious topic space, though
<wgrant> I assumed so.
<wgrant> Probably.
<ajmitch> next you'll be complaining that we don't answer questions about warty in here
<RAOF> wgrant: Any luck with Mouse->Touchpad tab?
<wgrant> I saw somebody complaining about Hoary's repos vanishing when they finally purged the archive of the old distroseries last year.
<wgrant> RAOF: tjaalton is working on a new backport of XI property stuff to our xserver, which will hopefully help to fix it.
<RAOF> Cool.
<dx9s_work> anybody here working on bug 191027
<ubottu> Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Confirmed] https://launchpad.net/bugs/191027
 * wgrant fixed that locally by changing to PulseAudio in gstreamer-properties.
<dx9s_work> it's weird.. seen several "work-arounds" ... mine was the most recent...  'asoundconf set-pulseaudio' .. and that solved it for me .. no changing anything else . no alsa updates (outside what is available on the dev branch for intrepid) ...
<dx9s_work> was curious as to pulseaudio and when it is starts during an xsession... the first work around was to stop and restart the user-space pulseaudio server... the 'asoundconf set-pulseaudio' doesn't require restarting the first pulseaudio server (however it starts during logging into machine via gdm/ start of X session)
<dx9s_work> also, another thing to note. reguardless if 'asoundconf set-pulseaudio' or removing the .asoundrc* from homedir ... when openning 'alsamixer' it shows the pulseaudio "master" volume... so in either case, alsa somehow defaults to forwarding non-specific sound hardware to the pulseaudio server... an 'alsamixer -c 0' will bring up the REAL hardware mixer ...  where as 'alsamixer' will default to pulseaudio .. (with OR without the 'asoundconf set-pu
<dx9s_work> lseaudio')
<dx9s_work> wgrant, does any of this make sense?
<asac> Laney: ok thx
<TheMuso> grrr latest updates have broken my MacBook Pro backlight control. I saw a hal update, will have to dig further.
<bryce_> TheMuso: the hal change that just now went in was for dell studio systems only
<TheMuso> bryce_: the last hal change I have is the latest merge from Debian.
<bryce_> TheMuso: ah okay nevermind, then that is suspicious
<bryce_> TheMuso: and actually the hal change I sponsored was to hal-info, not hal.
<TheMuso> bryce_: Right, I am referring to pitti's upload.
<TheMuso> I'll dig deeper.
<bruce89> #159996
#ubuntu-devel 2008-10-07
<slangasek> superm1: well, looks like my headset isn't attaching any better with 2.6.27-5
<stgraber> slangasek: is that SCO ?
<slangasek> stgraber: yes
<stgraber> ok, got some problem with mine as well, haven't tried with today's kernel though
<slangasek> hmm, I'm getting stack traces in /var/log/syslog that point to an apparmor issue
<stgraber> attaching using alsa and the alsa-bluez thing (.asoundrc) didn't quite work (I got sound but microphone was crappy) and using btsco just didn't work at all
<slangasek> bluez-alsa doesn't work at all for me, I get errors trying to connect
<stgraber> seems to attach correctly here with btsco but I can't make any sound to come through the headset
<TheMuso> superm1: I am not keen on updating pulseaudio this close to release.
<stgraber> doh, no my btsco seems to have crashed (process is I/O wait ...)
 * calc hates LP downtime :\
<calc> i forgot it was currently down and tried to commit
<directhex> so, who likes the idea of a SRU for gnupg2 for pretty much every currently supported release? :)
<ScottK> No.
<ScottK> Why?
<directhex> it may (i repeat, may, am trying to confirm) be the cause of an infuriating problem in *completely* unrelated software
<slangasek> jdstrand: is there a way that I could bypass apparmor_socket_sendmsg in the kernel without having to rebuild the kernel?  I'm trying to rule out apparmor interaction as the source of some bluetooth problems
<sbeattie> slangasek: I think you need to add "apparmor.enabled=0" to the kernel boot line
<slangasek> sbeattie: thanks, testing
<sbeattie> that IIRC should cause apparmor to not register its LSM hooks.
<slangasek> gar
<slangasek> asac: do you know if anyone, at any point, has ever *tested* the keyfile plugin to NM?  Because it's still uselessly broken for me
<superm1> TheMuso, i didn't think so.  not a highly critical issue anyhow.  Jaunty will hopefully introduce nice bluetooth headset support then :)
<superm1> stgraber, ah i don't have any headsets with mics.  i've only used stereo audio with mine (i have bluetooth headphones)
<superm1> slangasek, that's too bad.  well nonetheless no changes over the bluez 3.x packages currently sitting in intrepid though right?
* mthaddon changed the topic of #ubuntu-devel to: Intrepid beta released | archive: Feature Freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> superm1: not as far as I can tell, but then, it's not clear to me whether this is a solvable problem with one version over the other...
<slangasek> superm1: I would obviously be a lot more enthusiastic about approving an exception if either version was doing useful things for me :/
<stgraber> superm1: oh, you have stereo headsets using SCO and not A2DP ? (I thought A2DP was done for stereo headsets and supposed to provide a better quality for these)
<slangasek> I didn't think SCO would even do stereo...?
<stgraber> slangasek: if it does, I didn't know either :)
<dx9s_home> hey what talk have you guys had about building kernels with 64GB support (PAE) in 32-bit side???
<dx9s_home> and make it offical kernel (instead of people like me, DL the ubuntu patched kernel source and recompiling the kernel with usually one or two option changes)
<dx9s_home> was wondering what compatibility issues might pop up if the generic kernel has PAE enabled and what CPU issues it would cause ? ...
<persia> dx9s_home, PAE requires HW support.  I believe it is enabled in the -server kernel (although I may be mistaken)
<dx9s_home> I don't think so.
<dx9s_home> but I could be wrong too
<dx9s_home> crap  sorry
<persia> dx9s_home, This is being discussed at http://brainstorm.ubuntu.com/idea/1553/ : you may want to follow the discussion there.
<dx9s_home> what I was going to say before I pressed the wrong button
<dx9s_home> PAE is available on Pentium PRO and newer cpus.. what if it's enabled and by CHANCE a PAE enabled kernel runs on 486 .... would it crash?
<stgraber> root@data:~# cat /boot/config-2.6.24-19-server | grep 64G
<stgraber> CONFIG_HIGHMEM64G=y
<stgraber> root@data:~# cat /boot/config-2.6.24-19-server | grep PAE
<stgraber> CONFIG_X86_PAE=y
<dx9s_home> thanks stgraber ... I wasn't sure...
<dx9s_home> okay ... yes... "CPU too old" see that now
<dx9s_home> but PAE is fairly common now ... (like I said... Pentium Pro and newer Intel CPU's and forget where on AMD side... I don't know about some of the fairly strange x86 CPU's... those might not have PAE yet)
<slangasek> "Pentium Pro" - that's incorrect
<dx9s_home> so for desktop... the only was is to go with custom compiled kernel each time
<slangasek> there are lots of newer chips that don't support PAE
<dx9s_home> true
<slangasek> well, wikipedia says it's specifically the Pentium Ms that don't support it (heh, figures)
<dx9s_home> for some.. the option to go 64-bit native bypasses the need for PAE.. but for those that still want 32-bit kernel (for various reasons, like wine or things like non-64-bit code... from commercial sources [closed source]) ...
<stgraber> just install the server kernel, what's the problem with it ?
<persia> dx9s_home, wine runs on Ubuntu amd64.  There's also support for some third-party 32-bit binaries (read the wiki entry for skype).  Alternately, install the -server kernel.
<dx9s_home> not optimized with desktop in mind
<slangasek> PAE is not a desktop technology
<dx9s_home> well a while ago (on my first AMD64).. I did some benchmarks.. and running 32-bit code under a 64-bit kernel (dual mode).. you incur a performance penalty during context switches to-from 32<->64 -bit ... it hurts performance .. but it possible to run both at same time (I know)... I suspect that the new "VT" things helps some
<dx9s_home> I know.. but PAE on "desktop" machines is common... (and desktop machines with 4G+ memory is more common)
<ajmitch> doesn't PAE itself have some overhead?
<dx9s_home> some
<dx9s_home> it has memory limits where a "Segment/selector" of memory cannot point to more than 4G at a time
<dx9s_home> aka cannot directly point to and "offset" more than 4G for any one memory pointer
<persia> ajmitch, Indeed it does.
<dx9s_home> so . basically I am not making any sense... and will continue to custom compile a PAE kernel for desktop support ... was hoping to convince talking about 32-bit kernels with PAE and optimized for desktop (or perhaps even RT)
<persia> dx9s_home, You may want to look at linux-rt for the latter.
<dx9s_home> still no PAE
<superm1> stgraber, ah no, my headset does use a2dp, that's right
<stgraber> superm1: ok, would have been stranged otherwise :) so SCO is really broken at the moment ...
<superm1> stgraber, well i'll rummage around for my old headset for my mobile phone, that should be using sco
<persia> I thought btsco was no longer encouraged for use, as a2dp has become sufficiently mature.
<stgraber> yes, I've been testing with my Logitech HS05. It used to work just fine with .asoundrc in Hardy
<stgraber> persia: as I understand it SCO and A2DP are two different bluetooth protocol and far from all devices offer both. (I don't know much about bluetooth though)
<dx9s_home> stgraber, that sounds correct
<johanbr> Yes, SCO and A2DP are different.
<dx9s_home> I have a headphone that provides A2DP and the Hands Free Profile (Moto's S9) ... and that can cause some problems...
<johanbr> There are a number of different ways of using SCO. The recommended one seems to be to use the bluez audio service, but last I tried it didn't work all that well.
<superm1> stgraber, okay so I dug up my mono headset thing i used to use with my mobile.  sco is less attractive than a2dp indeed :(
<stgraber> hehe :) but I tend to like to use SCO when I want a quick way of doing some skype/twinkle/...
<stgraber> I like the idea of having the same device for my cell and my lappy
<superm1> stgraber, well it would be nice if somehow this would segfault or something useful
<superm1> 'ALSA lib pcm_bluetooth.c:1619:(bluetooth_init) BT_GETCAPABILITIES failed : Input/output error(5)' simply isn't useful to me
<persia> superm1, At least it's a hint : what does the BT_GETCAPABILITIES macro do?  Perhaps the device in question doesn't support the target profile?
<slangasek> superm1: it's bluetoothd itself that fails, so there's stuff in the logs; but I haven't been able to make any progress from there
<slangasek> (and it still fails after disabling apparmor, so the apparmor stack trace is a red herring)
<superm1> slangasek, my bluetoothd isn't crashing from this at least
<superm1> slangasek, so you must be pulling yours down harder
<slangasek> I didn't say it was crashing
<slangasek> merely failing
<slangasek> Oct  6 17:57:39 dario bluetoothd[6163]: link_key_request (sba=00:19:7D:E9:26:00, dba=00:1A:0E:02:B7:54)
<slangasek> ^^ that's what I get
<slangasek> Oct  6 17:57:49 dario bluetoothd[6163]: Unable to lock headset
<slangasek> Oct  6 17:57:49 dario bluetoothd[6163]: config failed
<slangasek> superm1: anyway, not to change the subject, but freeze exception granted :)
<superm1> ah that's more interesting then.  i'll see if i'm seeing simliar
<superm1> slangasek, okay great.  i'll get things in order to get things uploaded tomorrow
<TheMuso> superm1: Please send me the alsa-lib bits. I may have to do another alsa-lib upload, so its easier if I do it all at once.
<TheMuso> superm1: if thats ok with you.
<superm1> TheMuso, there should be a debdiff on that bug
<superm1> TheMuso, if you want to extract the patch from there
<TheMuso> superm1: oh, ok. I'll have a look.
<superm1> stgraber, interesting, i cleared out /var/lib/bluetooth and repaired.  this time it does register as SCO for me: http://paste.ubuntu.com/54863/
<superm1> still doesn't play properly, but at least registering the right service this time
<savvas> just a quick question, is it normal that gnome is 2.24 and gnome-system-tools is 2.22 in intrepid?
<lukehasnoname> so is it weird to anyone that when I rsync from a backup to my /home/luke directory, it breaks something to where I can't start any graphical apps? MTI-COOKIE or something error
<persia> lukehasnoname, You probably copied your Xauthority file.
<wgrant> lukehasnoname: That's not weird if you erase or overwrite .Xauthority, no.
<lukehasnoname> hmmm <_<
<lukehasnoname> *adds an --exclude*
<lukehasnoname> OK, the exclude option is terribly documented
<lukehasnoname> rsync master@192.168.10.100:/home/backup/ /home/luke/ --exclude ~/.wine/ --exclude ~/.Xauthority
<lukehasnoname> rsync master@192.168.10.100: /home/backup/ /home/luke/ --exclude ~/.wine/ --exclude ~/.Xauthority
<lukehasnoname> It tells me it's skipping . and doesn't do anythin
<StevenK> You probably want rsync -a
<lukehasnoname> aw hell, yes. I'm tired.
<lukehasnoname> I usually use -avh
<StevenK> -avh is good
<dx9s_home> what about removing and recreating the .Xauthority ? or am I missing something (not entirely impossible)
<lukehasnoname> if I'm doing it over anything more than my local router -avzhe ssh
<lukehasnoname> dx9s_home: possible
<erast> NCommander: nexenta-on package which includes full nexenta kernel sources uploaded into hardy repository now, its very initial, so don't expect much... the work will continue
<ScottK-laptop> NCommander: Any suggestions on http://launchpadlibrarian.net/18275920/buildlog_ubuntu-intrepid-sparc.kdebase-workspace_4:4.1.2-0ubuntu5_FAILEDTOBUILD.txt.gz
<ScottK-laptop> NCommander: I'm heading to bed, but I'll read the scrollback in ~6 hours.
<pitti> Good morning
<mvo> hey pitti!
<StevenK> Morning pitti!
<ion_> Hi
 * pitti hugs the lot
<pitti> mvo: hey Mr. Foundations Team :)
<StevenK> pitti: Is the NBS list getting updated since the drescher -> cocoplum move?
<pitti> StevenK: oh, good point; apparently not
 * pitti pokes
<ion_> Anyone feel like sponsoring http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
<ubottu> Launchpad bug 278195 in gnokii "Incorrect encoding for the synchronized entries" [Undecided,New] https://launchpad.net/bugs/278195
* cjwatson changed the topic of #ubuntu-devel to: 8.10 beta released | archive: Feature Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
 * cjwatson puts his topic changes from last night back
<dholbach> pitti: somebody told me that xvfb was unhappy in intrepid - is there a bug filed for it?
<pitti> dholbach: I don't know details, I'm afraid
<dholbach> OK, thanks
 * StevenK notices the foo directory on NBS and looks at pitti 
<pitti> StevenK: that was my rsync test
<StevenK> Heh
<StevenK> dholbach: I've heard that, and have a rebuild pending due to it. Anything you find out I'd be happy to know
<dholbach> StevenK: alright
<NCommander> pitti, you around?
<stefanlsd> Does anyone have an idea why my computer insist's of cpu-stepping to minimum (i'm on power).  cpufreq-selector -g performance fixes it, but need to run it manually everytime. running intrepid on a dell vostro 1500
<RAOF> mvo: It seems there's been an compiz upload that doesn't appear in lp:~compiz/ubuntu.  Would you like me to roll that in to bzr?
<mvo> RAOF: let me check, maybe just a forgoten push?
<seb128> hey mvo!
<mvo> RAOF: hm, no. so please add it
<mvo> hey seb128
<RAOF> Once that's done, I can add an LP bug number to the XDG_CONFIG_DIRS fix; people are hitting it.
<mvo> RAOF: ok, cool
<mvo> RAOF: we should probably branch the tree, I had hoped to get 0.7.8 FFE accepted and the current bzr is based on this
<seb128> mvo: it didn't get accepted?
<mvo> seb128: oh, sorry. I'm 18h late, I was granted now
<mvo> ^--- RAOF (bug 273923)
<ubottu> Launchpad bug 273923 in compiz "freeze exception for 0.7.8" [Undecided,Confirmed] https://launchpad.net/bugs/273923
 * mvo does a little dance
<seb128> mvo: ah ok, didn't know about that, I was just being curious ;-)
<RAOF> mvo: Yeah, I noticed that FFe grant :)
<RAOF> But, not having core-dev powers... ;)
<mvo> seb128: took a bit (because of beta freeze in between etc)
<seb128> mvo: if you upload this one and doesn't fix my keyboard focus issue on workspace switching before intrepid I'll find you ;-)
 * seb128 hugs mvo
<mvo> RAOF: right, just let me know when you are finished with bzr and I do the final upload :)
<mvo> seb128: *cough*
<mvo> seb128: I can't remember if we talked about it, but IIRC you reported a bug about it, right?
<seb128> mvo: I don't think I reported a bug but you said you were getting the issue when being quicker than the animation display
<mvo> seb128: yes, but not always, I could reproduce it sometimes, but not reliable
<RAOF> mvo: You might want to clarify what 029_compiz_manager_decoration.patch does; I'm pretty sure it doesn't blacklist an Intel driver, which is what the changelog entry says :)
<seb128> you need to be quicker ;-)
<mvo> heh :)
<seb128> mvo: btw do you know about totem crashing on intrepid intel card when using compiz?
<mvo> seb128: no, I have a machine that I could test that with though
<mvo> seb128: its still running hardy, but I guess its a good time to test this anyway
<RAOF> mvo: I'm not _entirely_ sure what to do here; should I retrospectively alter the changelog, or add a new "whoops" entry to the current log?
<seb128> mvo: The error was 'BadAlloc (insufficient resources for operation)'.
<mvo> RAOF: 028_ has "+T="$T 8086:2e02 " # Intel Eaglelake" for me
<mvo> seb128: hm, sounds like something with exa again :/
<RAOF> mvo: Yes, but the changelog entry _after_ that talks about 29_compiz_manager
<seb128> mvo: should I try XAA?
<RAOF> mvo: Which is removing the starting of the decorator from the script (It's the 0ubuntu12 log entry)
<mvo> RAOF: hm, I guess retro correcting is ok in this case (if its a obvious typo from me, maybe with a changelog entry about the changelog :)
<mvo> seb128: do you get the error yourself?
<seb128> mvo: yes
<mvo> seb128: aha, cool. please put Xorg.0.log somewhere, I would like to have a look
<seb128> mvo: http://people.ubuntu.com/~seb128/Xorg.0.log
<pitti> Hi NCommander
<NCommander> pitti, think you can tackle a usplash question?
<NCommander> pitti, I'm trying to figure out if there has been any recent changes in usplash to make it work while a machine is coming out of hibernation. I somehow got roped into looking at this bug in Debian :-)
<pitti> NCommander: there haven't been any changes to usplash recently, no
<NCommander> Darn. I was hoping it was something non-Debian specific
 * NCommander pulls out his hacking toolbelt and dives in to fix it
<pitti> NCommander: there might have been some in sysvutils in Debian, to integreate *splash more tightly, but we didn't merge for a while
<NCommander> I think its an issue with initramfs on Debian
<mvo> seb128: "  * Disable 01_fix_compiz_video.diff, since it appears to be obsolete
<mvo>     by now.
<mvo>  ^--- from the xserver-xorg-video-intel changelog. looks like its not quite obsolete by now ;)
<NCommander> Since if you kill the usplash commands there, it seemingly resolves the hang
<RAOF> mvo: Compiz pushed; please check there's no glaring problems :)
<seb128> mvo: bad xorg guys!
<NCommander> pitti, http://img262.imageshack.us/my.php?image=screenshotqi1.png - is that a bug against libpam0g, debian-installer, or something else :-)
<mvo> thanks RAOF!
<mvo> seb128: hm, is that your machine with the i965?
<seb128> mvo: yes
<pitti> NCommander: what does that have to do with usplash?
 * mvo scratches his head
<pitti> NCommander: and what's the bug there? that's a legitimate debconf question?
<NCommander> pitti, is it susposed to prompt for restarting services during an inital installation?
<NCommander> pitti, oh, that wasn't with usplash, just something that popped up while we were talking
<pitti> NCommander: oh; no, of course not
<StevenK> NCommander: My machine does usplash during resume
<NCommander> StevenK, Debian?
<seb128> mvo: I can try rebuild the intel driver using this patch if you want
<StevenK> NCommander: Of course not
 * NCommander falls over
<mvo> seb128: hm, that patch was for older cards, the i965 should not make a difference, but you could still try it (should be build quickly)
<StevenK> NCommander: Who's my employer, again? :-P
<NCommander> Right, stupid question.
<mvo> seb128: the patch is still in the series file
<seb128> mvo: ok will do that
<mvo> seb128: please also enable 11_textured_video
<seb128> mvo: both in the same run?
<mvo> seb128: yes (quicker this way)
<mvo> RAOF: I updated the changelog again and I think its now good to go
<tseliot> pitti: can you merge from my jockey-generic branch?
<RAOF> mvo: Hah!  I obviously need to aptutude update!
<seb128> re
<pitti> tseliot: hm, didn't you just introduce the Disable dri2 thing because it breaks something else?
<mvo> RAOF: heh :)
<seb128> mvo: not good, when stating playing a video the screen turn to whole gray and I had to reboot
<tseliot> pitti: dri2 was removed by the current Xorg and it breaks nvidia-settings and nvidia-xconfig which share the same parser
<pitti> ah, so we don't need it any more
<mvo> seb128: *ick*
<pitti> tseliot: removeOption() will not error out if the option doesn't exist?
<mvo> seb128: that is nasty
<seb128> pitti: is video playing working under compiz on your laptop?
<pitti> seb128: trying
<tseliot> pitti: no, it won't
<pitti> seb128: yes, both windowed and fullscreen
<seb128> pitti: hum, ok
<pitti> seb128: I didn't dist-upgrade today yet, though
 * pitti does now
<seb128> me neither
<seb128> it's broken for some weeks
<pitti> Version: 1:0.7.7+git20080807-0ubuntu12
<pitti> oh, I had noticed that
<pitti> "I would have", I mean
<pitti> indeed there's a new compiz today
<pitti> I was about to reboot to the hardy kernel anyway, I'll test it alongside
<mvo> pitti: you have a i945, right? not a i965?
<pitti> mvo: right
<mvo> seb128:  it may only affect i965 (but that is useful information for sure)
<pitti> seb128: oh, btw, I'm running the slightly older -intel driver (ubuntu4), since ubuntu6 is broken for me
 * pitti will file a report soon, he just discussed it with tjaalton so far
<seb128> I'm wondering if anybody looks at the intel bugs
<liw> mvo, welcome back; system-cleaner 1.10 was uploaded yesterday :)
<seb128> https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs sorted by new bugs, most of the first page looks like it has not been triaged
<mvo> liw: sounds like I'm right back in time!
<rom1v> hi
<rom1v> is there a chance that this fix would be included in intrepid : https://bugs.launchpad.net/ubuntu/+bug/215876 ?
<ubottu> Launchpad bug 215876 in ubuntu "compiz & nvidia-settings" [Undecided,New]
<sivang> liw: hi
<sivang> liw: you develop system cleaner ?
<liw> sivang, yes
<Hobbsee> mvo: perhaps you might add rom1v's fix to your upload
<mvo> Hobbsee: I'm collecting changes currently. what bugnumber is this one?
<Hobbsee> [19:48] <rom1v> is there a chance that this fix would be included in intrepid : https://bugs.launchpad.net/ubuntu/+bug/215876 ?
<ubottu> Launchpad bug 215876 in ubuntu "compiz & nvidia-settings" [Undecided,New]
<mvo> Hobbsee: I have anohter one for firefox that needs to be added as well
<mvo> thanks Hobbsee
<Hobbsee> mvo: you're welcom
<Hobbsee> e
<mvo> rom1v: hello! thanks for your patch. I think this came up before and I was wondering why this is not added to the Xsession.d from the nvidia-settings package?
<sivang> liw: nice, how do you know which kernel to remove and which one to leave ?
<rom1v> mvo, do you think it is better to add it to the Xsession.d ?
<liw> sivan, system-cleaner does not special case kernel packages, so it removes those kernels that are no longer available in the archive
<rom1v> maybe, I just make a patch which works, but if you think it should be on another place, feel free :)
<mvo> rom1v: I don't know a great deal about nvidia-settings, but it sounds like this would be useful for metacity users as well (or people running stuff like afterstep etc)
<rom1v> I think it's only for composite wm
<rom1v> but not sure
<mvo> rom1v: aha, thanks. I have a look, thanks
<sivang> liw: ah I see, thanks
<sivang> liw: I once created a spec, https://wiki.ubuntu.com/SystemCleanUpTool that's why I'm happy to see that there's already a tool uploaded :)
<rom1v> mvo: when you have some more details about that, could you comment the bug ?
<james_w> is anyone else noticing evolution sending two copies of emails?
<james_w> I only have a suspicion so far...
<pitti> james_w: one for the recipient, one for the NSA?
<james_w> heh :-)
<liw> sivang, cool :)
 * sivang notices there's now a last-good-boot mechanism in grub, easing solving the left over kernels problem
<liw> sivang, yup
<sivang> liw: is there a tool already to remove old kernels ? or to notify when there's a last-good-boot ?
<persia> superm1, stgraber: Re: SCO connectivity: http://marc.info/?l=linux-bluetooth&m=122309203608203&w=2 may be interesting : supposed to be resolved in 4.11
<liw> sivang, as far as I understand, the new approach to kernel packaging will take care of old kernels in the future, and system-cleaner's orphaned package removal will take care of currently obsolete kernel packages
<rom1v> mvo: do you think removing the code "# special case handling for dapper upgrades (this runs only once after the upgrade)" in /usr/bin/gnome-wm has a risk?
<sivang> liw: but can a situation arise where a user boots a kernel from an orphaned kernel package ?
<sivang> liw: since then removing obsolete kernel packages might do harm
<liw> sivang, that can happen with any package that system-clenaer thinks is cruft; that's why the user needs to confirm the list
<mvo> rom1v: no, that should be fine now
<sivang> liw: right
<sivang> liw: I'm thinking along the lines of huristics similar to the popularity contest, but for actual usage of packages.
<sivang> liw: (not for kernel packages obviously)
<liw> sivang, that might be interesting
<cjwatson> that's excessive, system-cleaner should just check the running kernel version (if it doesn't already)
<rom1v> ok, could you take care of it (I'm just a simple user)?
<cjwatson> I believe apt-get autoremove already checks that
<sivang> cjwatson: was that addressed to us ? :)
<cjwatson> yes
<mvo> update-manager does for sure
<sivang> how is packages usage measured?
<sivang> not installation, usage.
<sivang> btw, big hi(s) mvo , cjwatson
<mvo> hey sivang :)
<sivang> cjwatson: apt-get autoremove checks the running kernel version?
<liw> is there still a chance that a Main Inclusion Request for system-cleaner could be approved for intrepid?
<lool> liw: I don't see it in https://bugs.edge.launchpad.net/~ubuntu-mir
<lool> liw: Is ubuntu-mir subscribed?
<liw> lool, I haven't filed one yet, I'm wanting to know if MIRs have any chance of being approved for intrepid or if I'd be wasting everyone's time by writing one (but perhaps asking about that is wasting time)
<lool> You're going to have to write anyway, don't you?  :)
<liw> true, I guess :)
 * liw goes write one
<cjwatson> sivang: that does indeed appear to be what I said, although it's just a memory and I haven't yet found evidence for it
<cjwatson> so I may be mistaken
<sivang> cjwatson: okay
<pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ is current now
<StevenK> Woot!
<StevenK> Ugh, it's even bigger now
<persia> Most of it is without rdepends though...
<StevenK> Most of it is are two kernels, which you can't rely on rdepends for.
<Tonio_> hi !
<pitti> StevenK: -4 can be killed, and -5 as soon as d-i moves to -6
<StevenK> What about the ports kernel?
<StevenK> Has d-i moved to 2.6.25-2?
<StevenK> cjwatson: ^
<StevenK> seb128: gimp is in main, and libgegl-0.0-dev is in universe
<seb128> StevenK: you are stating to obvious ;-)
<StevenK> Heh
<seb128> StevenK: didrocks is working on writting the required mirs, the gegl one is written, still need the babl one
<StevenK> What is it with library names that sound like random letters
<didrocks> StevenK: gegl is the new "engine" of gimp
<persia> libsdfj23c02a ?
<StevenK> didrocks: I know
<didrocks> StevenK: sorry, I was thinking you were speaking about them :-)
<cjwatson> StevenK: yes
<cjwatson>   * Move ports architectures to 2.6.25-2 kernels.
<cjwatson>   * Move mainline architectures to 2.6.27-5 kernels.
<StevenK> cjwatson: Excellent, thanks.
<StevenK> pitti: Okay, binning -4 and -1 kernels
<pitti> (NB that the kernel is at -6 already)
<cjwatson> they've released -6 ? sigh
<StevenK> Hah
<StevenK> -meta is still -5
<pitti> The "ABI spreading like Tribbles" release :)
<StevenK> Hmmm. LRM is still -5, too
<cjwatson> I'll commit the d-i update for -6, but won't upload it until more kernel bits are in
<cjwatson> it can't be NBS-removed until l-r-m and -meta are uploaded anyway
<StevenK> Right.
<Riddell> pitti: do you know when language packs will be uploaded?
 * liw says "whee" in a small voice, having filed his first MIR
<pitti> Riddell: ArneGoetje is coordinating that now; "soon"
<Riddell> ArneGoetje: very soon would be nice, I have no idea if KDE translations are working
<StevenK> Chug chug chug
 * cjwatson deals with 2.6.27-6 binaries in new
<StevenK> Which means LRM is probably in DEPWAIT
<StevenK> seb128: Are gimp-{gnomevfs,libcurl,python} really NBS or are they a side affect of gimp being in DEPWAIT?
<cjwatson> yes
<BenC> cjwatson: is there a linux-meta uploaded already?
<BenC> cjwatson: I just did an upload for -5 to add -virtual, I don't want it getting lost
<StevenK> BenC: You uploaded a -5 kernel?
<BenC> No, linux-meta
<ion_> benc: I wonder how to debug LP #278188?
<ubottu> Launchpad bug 278188 in linux "irda broken on Thinkpad T23 with 2.6.27-4-generic, works with 2.6.24-16-generic" [Undecided,New] https://launchpad.net/bugs/278188
<cjwatson> BenC: well, you can read https://launchpad.net/ubuntu/+source/linux-meta as well as I :-)
<cjwatson> BenC: somebody'll need to do an ABI bump following that of course, but I don't see one yet
<BenC> cjwatson: for some reason I was thinking it would be kept in NEW, but that doesn't happen to linux-meta
<cjwatson> indeed
<BenC> cjwatson: thanks, I follow up with a -6 ABI bump later
<cjwatson> you should be able to see that on https://launchpad.net/ubuntu/intrepid/+queue FWIW
<cjwatson> linux-meta *binaries* are in NEW mind you ...
<StevenK> Due to -virtual?
<cjwatson> yes. processed now
<ogra> asac, hmm, with MN managing static /e/n/i devices we need to make sure dhcp3-sever (and probably dnsmasq) start after NM
<ogra> *NM
<ogra> at least dhcpd reiles on having an interface available on startup
<StevenK> Come on cocoplum, go faster.
<ogra> i think atm the debian/rules use default for dh_installinit ... which results in S25 ... NM has S30
<ogra> (debian/rules of dhcpd)
<RAOF> So... should /usr/sbin/NetworkManager again decide to consume 1.4GB RSS, what can I do to debug?
<Keybuk> RAOF: do you know what RSS means?
<RAOF> I may be using the wrong term.
<RAOF> That's the "Resident" column.
<Keybuk> are you sure it's not 1.4 MB? :-)
<RAOF> Virtual was something like 2.4GB.
<Keybuk> use massif to identify the memory usage pattern
<RAOF> Yes.  Because loadav was 15, and it didn't manage to switch to a VT, even after 3 minutes of frantic thrashing.
<asac> ogra: dhcp-server?
<asac> ogra: you say now that NM supports system configurations we should see if we can enable any server apps properly?
<asac> hmm
<StevenK> pitti: A *whole* bunch of stuff flushed out
<ogra> asac, no, i say that i currently get a lot of complaints from ltsp users that their dhcpd doesnt start :P
<ogra> asac, dhcpd has a builtin check ... it looks for a static device with an ip and compares this IP to its config, if a subnet declaration is found for one of the running devices it starts up ... thats our default setup
<RAOF> Aha.  Massif is in valgrind.
<ogra> asac, if the device isnt up, which is the case atm, dhcpd just fails to start and doesnt serve anything on such a device
<ogra> asac, even though you plan to switch off managed mode, it will still be possible to turn it on, if people do so, dhcpd needs to start after NM
<ogra> asac, i'm not sure how critical a static IP is for other services, but dhcpd wont work without one
<ogra> so its initscrip needs to start after NM
<rom1v> mvo: you're right, https://bugs.launchpad.net/ubuntu/+bug/215876 I think it would be better to add this script in Xsession.d (last comment)
<ubottu> Launchpad bug 215876 in ubuntu "compiz & nvidia-settings" [Undecided,New]
<pitti> StevenK: \o/
<StevenK> pitti: I just counted. 200 binaries
<asac> ogra: why isnt the device up?
<asac> ogra: ifup/ifdown should still bring it up
<asac> i havent touched that yet
<asac> ogra: i think the problem might have been that NM did down and up the interfaces
<asac> ogra: but that should be fixed since yesterday. you want "unmanaged" mode
<bond`> pitti: can you have a look at bug #276472?
<ubottu> Launchpad bug 276472 in linux "cp -p on CIFS mount does not preserve timestamp" [Undecided,Incomplete] https://launchpad.net/bugs/276472
<asac> ogra: does that match what you want ?
<ogra> asac, right, but users that installed from an alpha have it managed from NM ...
<asac> ogra: yeah. anyway. now it shouldnt happen anymore, which doesnt mean that we shouldnt move dhcp-server to be started after NM (if its possible)
<ogra> asac, also, it is possible that you switch to managed if you want ... we should make sure it works in that case
<asac> ogra: would be nice to have dhcp working without ifupdown
<liw> users installing from alphas have a lot of things they need to tweak... but perhaps I can entice someone to write a system-cleaner plugin to clean that up? ;-)
<ogra> asac, you can do that by forcing dhcpd it a specific interface in /etc/defaults, but that omits the selftest and i dont think we want to tinker with defaults
<ogra> just make sure it doesnt start if no interface is up
<ogra> for which you give a possibility in the current setup
<ogra> its not that hard to move dhcpd's init to S31
<ogra> and we might decide to switch to managed mde in jaunty ... so it would save us one transition ...
<ogra> *mode
<asac_> 12:44 < ogra> just make sure it doesnt start if no interface is up
<asac_> 12:48 < asac> ogra: so would there be a problem to start dhcp-server later?
<asac_> 12:48 < asac> ogra: NM cannot be started before dbus is up. thats for sure
<asac_> 12:49 < asac> ogra: we could then put some love in the NM init script ... so it waits for a while giving NM a chance to connect
 * pitti already sees Keybuk jump at asac "don't sleep in init scripts" :)
<asac> ogra: so would there be a problem to start dhcp-server later?
<asac> ogra: NM cannot be started before dbus is up. thats for sure
<asac> ogra: we could then put some love in the NM init script ... so it waits for a while giving NM a chance to connect
<ogra> asac, i dont think there would be a prob starting it later
<ogra> the prob atm is that it will never start if you switch to managed mode
<ogra> and its trivial to solve by moving the initscript to S31
<asac> ogra: coudlnt dhcp server be told to retry through if-up.d scripts?
<ogra> no ide, i guess rewriting its selftest would be a quite big patch
<ogra> which is what i think this would involve
<asac> ogra: ;) ... we could just run dhcp-server start in ifup.d and dhcp-server stop in ifdown.d
<ogra> well, how would that work for people not having NM ?
<ogra> ifup would care i guess ?
<asac> ogra: as of now, would dhcp-server break if you run ifdown eth0; wait a bit; ifup eth0 ?
<asac> ogra: or is it just important that the interface is up when dhcp-server initially gets started?
<ogra> if its initscript tries to start inbetween it would break
<ogra> it expects a static iface with IP
<ogra> right
<ogra> the latter
<asac> ogra: ok, but its just a startup check?
<asac> ogra: so yes, moving dhcp-server back sounds reasonable
<asac> ogra: but:
<asac> we either have to make NM init script wait until its online (or some time has passed to give up)
<asac> _or_
<asac> we could make the dhcp-server script do that
<asac> (e.g. wait a bit in case the interface isnt up yet)
<ogra> what does NM do ? if its static it shouldnt wait for anything
<asac> ogra: it starts a daemon. it should connect quite snappy, but still its a race :)
<asac> and races always come with a risk to be lost :)
<ogra> indeed
<asac> ogra: so better wait for 5 or 10 seconds, testing whether nm-online is true
<asac> ogra: /usr/bin/nm-tool  | grep State:\ connected
<ogra> in a while loop ?
<asac> ogra: for the moment that would be safe. for more sophistication i would need to ship the "nm-online" tool
<asac> which does the looping for a certain timeout for oyu
<ogra> and wrpped with a grep for managed=true
<asac> ogra: if you want to do that, then yes.
<ogra> i'll assemble a mail with that and follow up on your RFC
<asac> ogra: my ifup -a patch would spit out a warning if its "managed"
<asac> $ ifup -a
<asac> WARNING: ifup -a is disabled in favour of NetworkManager. Set ifupdown:managed=false in /etc/NetworkManager/nm-system-settings.conf.
<ogra> right, but people might want managed mode for whatever reason ...
<ogra> so to make sure we dont break the world the above seems a sane solution
<asac> ogra: yes. what i am trying to say is that you dont need to parse the conf on your own
<asac> you could use ifup to do that (where we have to include a iniparser anyway)
<asac> ogra: but well. in general we agree i think. its just a matter on how to do it
<ogra> well, reply to the mail once i sent it :) i guess its safer to hold the rest of the discussion on the ML
<asac> "details" .-Ã
<ogra> yeah
<pitti> asac: your smiley needs some urgent medical treatment
<ion_> âº
<ogra> pitti, nah, its a germanized smiley, it uses umlauts :)
<asac> pitti: i am rambo :)
<ogra> asac, a rambo pirate eh ? looks like you use a oatch over the left eye
<ogra> *patch
<asac> hehe ;)
<asac> pitti: any preferred way i should set the status/milestone/importance for 3G hal-info tweaks?
<pitti> asac: for which kind of bugs?
<asac> pitti: missing product id
<pitti> those you'd like to get committed upstream and uploaded to intrepid?
<asac> pitti: typical bug would be #279182
<asac> pitti: not sure about upstream. we surely want them in intrepid to support as many phones/devices as possible
<pitti> asac: generally, if you want me to do that, assign it to me; I don't use importance a lot, and milestone is kind of useless now, too, since there's just one left :)
<asac> pitti: you committed all upstream, so i guess you want to send them upstream
<StevenK> Ahh. pitti langpack'd the i386 builders again.
<pitti> asac: yep
<asac> pitti: ok. i will assign those that get filed through me then.
<pitti> asac: so, subscribing me is fine, or just apply proper patches to hal-info and upload, which I can just take and apply upstream later on
<asac> oh
<asac> pitti: ok.
<cjwatson> Riddell: has KDE stopped honouring /etc/default/locale? bug 278634
<ubottu> Launchpad bug 278634 in ubiquity "[Intrepid Beta] KDE does not use the language selected during install" [Undecided,New] https://launchpad.net/bugs/278634
<Riddell> cjwatson: I don't know, until we get language packs uploaded that actually contain some translations I can't really test properly
<cjwatson> Riddell: it's easy to see in System Settings, even without language packs
<liw> lool, heh, you're on a rampage; thanks for all the bugs
<Riddell> mvo, ArneGoetje: where does incomplete-language-support-foo get copied to /var/lib/update-notifier/user.d/ ?
<siretart> seb128: re bug #279398, didn't you say at some point that you wanted to switch gstreamer0.10-ffmpeg to use the internal ffmpeg copy?
<ubottu> Launchpad bug 279398 in ffmpeg-debian "nautilus crashed with SIGSEGV requesting properties over ssh" [Medium,New] https://launchpad.net/bugs/279398
<seb128> siretart: right, but I decided against it, I'm already too busy so I'll just wait for next cycle and the update ffmpeg version
<siretart> seb128: okay. I reassigned that bug to gstreamer0.10-ffmpeg.
<seb128> siretart: why?
<seb128> siretart: gstreamer0.10-ffmpeg uses the system ffmpeg no?
<seb128> siretart: and libavcodec51: /usr/lib/i686/cmov/libavcodec.so.51 is a libavcodec51 library
<siretart> seb128: since you are the one who reassigns most of the bugs to ffmpeg-debian; unless I'm given an example file to reproduce, I cannot really do much about it, since I need to reproduce it
<siretart> seb128: see bugtrail. it seems to me that gstreamer0.10-ffmpeg is passing garbage to libavcodec. garbage in, segfault out
<siretart> seb128: that's another point: can we please disable apport reports from natilus thumbnailer?
<wgrant> Or fix the bugs...
<seb128> siretart: why? we don't get many of those do we?
<siretart> seb128: most of the crashes are of course somehow valid. however we need an example so that we can forward them to upstream
<siretart> seb128: I have the feeling that most of the reports in ffmpeg where of them. I triaged all of them for now
<ScottK-laptop> mvo: I have an KDE upgradability question that might need solving in update-manager if you have a moment to discuss.
<siretart> seb128: but since in almost all cases I had to reject the bug, I think we shouldn't bug users in the first place to submit them to lanchpad
<mvo> Riddell: IIRC the installer copies that file if it can not get networking (not 100% sure though)
<seb128> siretart: well, that's true for any crash bug, usually without steps to reproduce a one time bug is not easy to work on
<mvo> ScottK-laptop: sure
<seb128> siretart: that's not a good reason to reject those though
<seb128> siretart: do you have a stock reply for ffmpeg bugs which points to instruction that we could use when reassigning those? so we would reassigning bugs as incomplete and it's easy to clean those up when there is no reply
<ScottK-laptop> mvo: We have cases were a package has move from using kde4libs to kde5libs, and so the -dev package now depends on kde5libs-dev, but it's not co-installable with kde4libs-dev (which is still around and valid since we have to support some KDE 3 stuff still).
<wtgee> Hola...anybody else reported that the timer in sudoku is not working?  I didn't see a bug.
<ScottK-laptop> mvo: So if someone has, for example, libkdegames-dev installed and upgrades from Hardy, then upgrade will fail because libkdegames-dev in Intrepid needs kde5libs-dev and that can't be installed due to the presence of kde4libs-dev
<ScottK-laptop> mvo: We can't use replaces because it doesn't actuall.
<mvo> ScottK-laptop: right, you need conflicts in this case it seem. and they clash on the filename namespace?
<ScottK-laptop> mvo: So I was considering some kind of rule for upgrading kde -dev packages that would allow the KDE libs -dev package to be force upgraded.
<ScottK-laptop> Yes.
<mvo> ScottK-laptop: that sound not optimal for reasons that go beyond upgrading :)
<mvo> ScottK-laptop: I can add code to update-manager that force -dev upgrades for certain packages
<ScottK-laptop> Well I didn't go back and consider redesigning the packaging at this point.
<mvo> ScottK-laptop: what happens currently? are they held back (not upgraded) or does the upgrader complain that it can not calculate the upgrade?
<ScottK-laptop> Held back and not upgraded
 * mvo nods
<mvo> ScottK-laptop: ok, if you want such a rule, its trivial for me to add it, especially if there is a pattern or a list of package names
<ScottK-laptop> So it'd be if kde5libs-dev is wanted and kde4libs-dev is installed, go ahead and force it.
<ScottK-laptop> mvo: Does that work or do you need a list of the packages that would depend on it?
<kwwii> seb128: so nobody responded about the themes package yet...I am sure we will hear people when we actually split them out, but if nobody has anything to say about it in advance it must not be soo bad
<seb128> kwwii: right
 * Riddell notes it's kdelibs5-dev and kdelibs4-dev
<ScottK-laptop> Riddell: Thanks.  I swear I was going to double check that.
<mvo> ScottK-laptop: that should be fine, the list would be nice, but I can generate it here too. I will add the packages to my (kubuntu) test system to ensure that the rule work etc :)
<ScottK-laptop> mvo: Thanks.  Would you like that in the form of a bug?
<seb128> kwwii: I'll do the change tomorrow, I just wanted to let them some chance to reply before and I'm quite busy today
<davmor2> mvo: is there a fix in compiz to allow the screensaver to work?
<nxvl> pitti: hi!
<nxvl> pitti: would you like to take a look at Bug #279425 please?
<ubottu> Launchpad bug 279425 in dbus "please update dbus to 1.2.4" [Undecided,New] https://launchpad.net/bugs/279425
<kwwii> seb128: excellent, thanks for the help :-)
<pitti> nxvl: I got the bug mail; will do ASAP
<seb128> kwwii: you're welcome!
<nxvl> pitti: thank you!
<mvo> ScottK-laptop: yes, would be good. please give me the bugnumber once its added, its enough if its very short (just the "make update-manager force kdelibs4-dev->kdelib5-dev upgrade")
<ScottK-laptop> mvo: Will do.
<mvo> davmor2: could you be a bit more specific (or point me to a bug)? screensaver seems to work for me with compiz
<cjwatson> Riddell: mvo is correct; pkgsel and ubiquity do it
<rom1v> mvo: I don't know if you saw my message, I think you're right : https://bugs.launchpad.net/ubuntu/+bug/215876 (last comment), adding a script to Xsession.d would be better
<ubottu> Launchpad bug 215876 in ubuntu "compiz & nvidia-settings" [Undecided,New]
<davmor2> mvo: bug 253367
<ubottu> Launchpad bug 253367 in compiz "Intrepid: Ubuntu screen saver kicks in then switches off again" [Undecided,New] https://launchpad.net/bugs/253367
<ogra> davmor2, i see that as well on the samsung Q1U
<ogra> (also intel)
<davmor2> mvo: screen fades to black as soon as it has gone black it shoots back to desktop again
<ogra> but dont see it on the laptop ... intel as well
<ogra> its definately dpms misbehaving but i doubt its the intel driver
<ogra> mvo ^^^
<ogra> in cae you need a tester
<mvo> rom1v: yes, I have seen it, thanks! that should probably be reassinged to nvidia-settings at this point so that it is added there. I vaguely remember this came up before, have you looked in the bugreports for nvidia-settings if that was ever discussed?
<davmor2> mvo: also if I enable the Nvidia binary for my other test desktop and enable compiz same thing again.
<mvo> ScottK-laptop: thanks!
<davmor2> ogra: disable compiz and it works fine
<mvo> davmor2: my desktop seems to be fine, let me have a look
<ogra> davmor2, i'll try
<mvo> ogra: thanks, dpms is a good hint
<davmor2> mvo: Is there anything I can do to lower it down a bit for you?
 * ogra disables compiz on -mobile and waits
<mvo> davmor2: what video card/driver to you have?
<pitti> nxvl: in fact, it just happens to be next on my list, doing now :)
<rom1v> mvo: bug 108060
<rom1v> ?
<ubottu> Launchpad bug 108060 in nvidia-settings "Custom nvidia-settings changes should be automatically loaded on log in" [Wishlist,Triaged] https://launchpad.net/bugs/108060
<nxvl> pitti: \o/
<pitti> seb128, mvo: just for the record, video playback WFM for current compiz, too
<seb128> pitti: bah
<pitti> nxvl: wrt your diff.gz, I'll augment the changelog with some real change descriptions, if you don't mind?
<nxvl> pitti: as in the changes added? sounds good to me
<siretart> seb128: the reason to reject was either - lack of answer or - sorry, was a partially transferred file
<mvo> excellent, thanks pitti
<siretart> seb128: as for stock responses, see http://ffmpeg.org/bugreports.html for bug reporting guidelines
<davmor2> nvidia 7200 is the one and it's intel in the box I reported from initial I'll get the exact model in a couple of seconds for you
<davmor2> mvo: ^
<mvo> davmor2: what driver is used there -177 ? or a older one?
<seb128> siretart: ideally ffmpeg should not crash on non incomplete videos
<ScottK-laptop> mvo: Bug #279621
<ubottu> Launchpad bug 279621 in update-manager "make update-manager force kdelibs4-dev->kdelib5-dev upgrade" [Medium,Confirmed] https://launchpad.net/bugs/279621
<seb128> -non
<davmor2> mvo: the latest and recommended so I think it is the 177
<siretart> seb128: true. however without example file, there is no point in even trying to forward such bugs
<siretart> seb128: that's why I propose to disable apport for thumbnailer crashes
<seb128> siretart: right, so either we disable apport and will never get a reply or we use stock replies and set those to uncomplete and let a chance to users to provide enough informations to fix an issue
<seb128> siretart: it's your call as ffmpeg maintainer
<mvo> davmor2: hrm, I have that too on my desktop
<seb128> siretart: we can reassign bugs asking for an example using a stock reply appropriate and ask to reopen if the submitter has the informations
<mvo> davmor2: desktop/laptop or both ? (if you see it on two machines)?
<seb128> siretart: the number of crashers we get is manageable
<mvo> davmor2: I also wonder if it might be only affecting new installs (or is this a upgraded machine)?
<siretart> seb128: okay, then let's try that
<seb128> siretart: ok good, do we have a stock reply somewhere on the ubuntu wiki for ffmpeg bugs? https://wiki.ubuntu.com/Bugs/Responses lists the common ones
<davmor2> mvo: New installs (I'm an iso tester) both are desktop
<davmor2> mvo: intel is an 83945 G/GZ
<seb128> siretart: ah, there is a "xine-lib and ffmpeg bugs", do the reply looks good enough to you?
<siretart> what's the link? let me check
<mvo> davmor2: thanks. and it happens only with compiz, not when you disable effects?
<davmor2> s/83945/82945 sorry
<seb128> siretart: https://wiki.ubuntu.com/Bugs/Responses#xine-lib%20and%20ffmpeg%20bugs
<davmor2> mvo: that is correct
<davmor2> ogra: how about you ^
<mvo> davmor2: thanks, anything in ~/.xsession-errros when it happens?
<ogra> davmor2, still waiting for dpms
<ogra> davmor2, oh now it starts ... one more second
<ogra> yep, seems to work fine with compiz off
<siretart> seb128: yes. that response should be okay for most cases, I'd think.
<ogra> fades properly and doesnt come back
<seb128> siretart: ok, let's try that then, if that doesn't prove efficient we will just add an apport hook to ignore those
<davmor2> mvo: http://www.davmor2.co.uk/esys-lshw.html
 * Keybuk discovers /sys/dev
<davmor2> mvo: I'll check ~/.xsession-errors in a second for you
<cjwatson> Keybuk: hey, that's kind of handy
<Keybuk> cjwatson: udev upstream just grew a /dev/{block,char}/maj:min -> /dev/node mapping too
<Keybuk> quite a nice round-trip
<Keybuk> if you have a sysfs devpath, read "dev" to get maj:min, and readlink /dev/{block,char}/maj:min to get the device node name
<ScottK-laptop> pitti: If you have a moment, I could use a bit of advice on how to fix this: http://launchpadlibrarian.net/18194120/Traceback.txt - Should python-dbus do something other than raise an exception here or should Guidance catch the error and ? retry/wait/die
<ScottK-laptop> pitti: Someone said you were having similar problems with Jockey.
<Keybuk> if you have a /dev path, stat() to get maj:main, and readlink /sys/dev/{block,char}/maj:min to get the sysfs devpath
<pitti> ScottK-laptop: "similar in jockey" only in the sense that I got crash reports about unavailable policykit-kde-agent
<pitti> ScottK-laptop: IMHO python-dbus DTRT here, and guidance should intercept it and die gracefully
<pitti> ScottK-laptop: or just let it die like it does now, the exception message is clear enough (will cause some apport bug spam, though)
<ScottK-laptop> pitti: Some aspects of Guidance seem to work when hal is missing, so I'll try and see what the most useful direction to go in is.
<ScottK-laptop> pitti: Thanks.
<siretart> seb128: thanks
<seb128> siretart: you're welcome
<davmor2> mvo: Nothing in ~/.xsession-errors
<davmor2> mvo: I should say nothing new in ï»¿~/.xsession-errors
<mvo> davmor2: ok, I'm rsyning the current livecd and check if I can reproduce it from it (I don't have a new install atm)
<davmor2> mvo: the intel card is still doing on the smoketest from yesterday
<mvo> davmor2: I just tested it on a upgraded intel system and the screensaver is fine there
<mvo> davmor2: live-cd is next
 * StevenK sighs at mit-scheme
<StevenK> No fair requiring sysctl changes to build
<davmor2> mvo: any joy?
<mvo> davmor2: still burning the disk
<davmor2> okay cool :)
<munkey092092> hello?
<munkey092092> are you interested in stuff you can develop which is not in it?
<munkey092092> i got a ubuntu some time ago and it said it was completely compatable with windows but not with my 3g modem which installs as a mass storage device and automatically installs a windows driver 2000 xp or viste it is a huawei 3g modem mebbe yous want to know this stuff
<munkey092092> these modems are 3.6Mb broadband and v cheap
<munkey092092> huawei E220 hsdpa modem (wireless)
<jsgotangco> strange, i have the same modem and it works fine on ubuntu and even debian :-) its already in the kernel
<ogra> Keybuk, meep ... one question about udev rules, ltspfs is synced from debian now, when i packaged it i used to use 080 for the custom rules, from debian it comes in with 050, i happen to remember somewhere in my head that this isnt good numbering
<Keybuk> ogra: Debian and Ubuntu use different, incompatible, rule numbering
<siretart> Keybuk: section 1 says "keep intact all the notices that refer to this License and to the absence of any warranty"
<ogra> right, so 080 was the right one, right ?
<ogra> for custom overriding rules
<Keybuk> depends what you want to use in the rules
<Keybuk> siretart: and "give any other recipients of the Program a copy of this License"
<Keybuk> siretart: section 2 says "You must cause any work that you distribute or publish[...]to be licensed[...]under the terms of this License."
<ogra> Keybuk, http://paste.ubuntu.com/55029/
<ogra> Keybuk, also intesting is that ENV{ID_TYPE} doesnt seem to work
<cjwatson> ogra: neither 050 nor 080 is correct in Ubuntu - we use two-digit rule numbers. check /etc/udev/rules.d/
<cjwatson> and I think Debian tend to use an underscore as a separator too
<cjwatson> dh_installudev knows about the differences
<Keybuk> ogra: reading
<siretart> Keybuk: which is according to schily also the case here.
<ogra> cjwatson, yeah, the package uses that
<ogra> actually it doesnt set any numbering
<ogra> hmm
<siretart> Keybuk: please note that he considers cdrtools as a mere collection of more or less independent programs and libraries
<Keybuk> ogra: other than ID_TYPE, that can go anyway
<Keybuk> ogra: anywhere, sorry
<Keybuk> though 80 would be where I'd put it
<siretart> Keybuk: the real tricky point is that we are discussion license compatibility in a pretty complicated case here.
<ogra> right, i think i remember that you suggested that for my package ... i wonder though where dh_installudev gets the 50 from now ... there is no number set at all
<Keybuk> siretart: I understood his argument to be
<Keybuk> foo is GPL, source is GPL, binary is GPL
<cjwatson> ogra: 50 is the default unless you tell it otherwise
<ogra> ah
<cjwatson> ogra: following /etc/udev/rules.d/README
<persia> Who knows python python and would like the scheduling in #ubuntu-meeting to work?
<Keybuk> it links to libbar which has source under CDDL, but you can pretend the binary is GPL
<Keybuk> right?
<Keybuk> ogra: for ID_TYPE to work, it probably _has_ to be 80
<siretart> mkisofs source is GPL, binaries of mkisofs are GPL as well.
<cjwatson> indeed, this is documented in dh_installudev(1) ...
<Keybuk> siretart: but mkisofs links to non-GPL libraries?
<ogra> Keybuk, yeah, that was my thought
<ogra> stgraber, ^^^
<liw> persia, hm? the bot needs fixing?
<stgraber> ogra: oh, will give that a try
<siretart> Keybuk: GPL section 2 does only talk about "the Program or any portion of it", not about additional libraries it links to
<ogra> cjwatson, thanks a lot, i'll fix that then
<ogra> stgraber,   80   rules that run programs (but do not load modules)
<ogra> stgraber, from /etc/udev/rules.d/README
<persia> liw, Indeed.  Google iCal sends a single announcement for recurring events that needs more parsing.  Work in progress is at https://code.edge.launchpad.net/~tsimpson/+junk/Webcal but is stalled.  Help appreciated.
<liw> persia, hm, not something I know much about, I'm afraid
<persia> liw, Awww.
<persia> Anyone else?
<siretart> Keybuk: it does specifcally not use "the whole Program" as elsewere in the text. schily claims that this wording is used here on purpose
<liw> persia, I'd be happy to spend a few days learning about iCal, but you'll have to convince cjwatson I should do it :)
<persia> cjwatson, Can liw fix the bot?
<cjwatson> err, a few days is a bit much
<liw> indeed
<persia> pity
<cjwatson> does it really need liw to be an iCal expert, or just a general python hacker? does somebody else already know the necessary iCal stuff?
<stgraber> ogra: rebuilding the squashfs, let's hope it did the trick
 * ogra hopes
<stdin> ical is not too complicated, it's the data processing that's mind-melting
<stdin> s/data/date/
<liw> stdin, in what way?
<stdin> liw: in iCal you can have a rule where an event repeats on the first Thursday and second Tuesday of the month. working that out properly is, erm, not easy
<liw> stdin, hmm, I could have a look then; cjwatson, an hour is ok, I hope?
<cjwatson> sure
<liw> tomorrow, then
<persia> liw, cjwatson: Thank you.
<stdin> ical.py and rrule.py are the guts (uses python-dateutil and included icalendar module)
<liw> stdin, can you e-mail me (lars@ubuntu.com) how to reproduce the problem so that I can be sure I'm fixing it?
<liw> stdin, alternatively, will you be around in about 22 hours?
<stdin> the google iCal is http://tinyurl.com/6mzmbr, just try parsing it with the ical module
<stdin> 22hours = 14:22 for me, so yeah
<stdin> (probably anyway)
<stdin> liw: http://pastebin.com/f4379d83e is a small test run to see what events it sees
<liw> stdin, thanks! I'll look at it tomorrow, now I need to go celebrate Xmas
<liw> (with a company that went bankrupt in 2001)
<nxvl> seb128: can you please take a look at Bug #273396
<ubottu> Launchpad bug 273396 in gtkhtml3.14 "Spell check mark everything as wrong" [Low,Confirmed] https://launchpad.net/bugs/273396
<seb128> nxvl: I'm already building a patched package
<seb128> nxvl: usually no need to ping on IRC when bugs are fixed we do read the bug mails ;-)
<nxvl> seb128: oh ok, since i attached a patch inthere
<nxvl> :P
<mvo> davmor2: hrm, the livecd does not have a screensaver of course (well, it does, but no locking)
<nxvl> \o/
<seb128> nxvl: ah, didn't get this one yet
<persia> mvo, can't it be locked if one manually forces the setting of the password for the ubuntu account?
<nxvl> seb128: then IRC was needed
<nxvl> :D
<mvo> persia: yeah, I will fiddle a bit
<seb128> nxvl: yeah ;-)
 * nxvl HUGS seb128 
<nxvl> seb128: if you are preparing and upload please include that, is a really annoying bug
<persia> mvo, Oops.  My mistake.  casper-bottom/22screensaver disables locking in gconf + kdesktoprc
<davmor2> mvo: this is just the standard SS the blank screen that comes as standard once installed.  However you get the same thing on Livecd too it still fade during install and on my nvidia it stays blank and on the intel it wakes up
<seb128> nxvl: oh, already uploaded, when I said I was building a patched package that was to do an upload ;-)
<mvo> persia: hrm, I enabled it again in gconf and it still won't lock
<persia> Odd.  With that unset, and a password for ubuntu, it ought, I'd think.
<nxvl> seb128: ok, i will update the patch in s bit
<mvo> persia: it doesn't - oh well
<Riddell> persia: what's this?
<kwwii> TheMuso, seb128, mvo, pitti...heck, anyone :-) We need to revert the -sounds package
<persia> Riddell, Trying to figure out how to lock the screen from the liveCD.
<ogra> mvo, it wont lock if no PW is set
<ogra> kwwii, what id you do ? put a farting sound into gdm ?
<mvo> ogra: hrm, I set one, maybe its lying to me
<seb128> nxvl: what do you want to update?
<nxvl> seb128: the patch i attached to that bug report
<seb128> nxvl: what patch?
<ogra> mvo, hmm, i just know gss and xss were patched to not lock with no pwd when i maintained them ...
<ogra> not sure how thats done now
<seb128> nxvl: I've the feeling we have a communication issue there
<nxvl> seb128: yup
<nxvl> Bug #273396 -> i've attached a patch into it
<ubottu> Launchpad bug 273396 in gtkhtml3.14 "Spell check mark everything as wrong" [Low,Fix released] https://launchpad.net/bugs/273396
<mvo> ogra: no luck, I created a different user even
<ogra> did you unset the gconf key ?
<seb128> nxvl: and as said before I alread uploaded a patched version, it was building when you pinged me
<ogra> its a system wide one iirc
<nxvl> seb128: oh! a patch fixing that issue, ok, i thought you were building a one fixing another issue
<seb128> nxvl: sorry I would have used your debdiff if I had read the bug comment before uploading
<nxvl> seb128: you were right, communitcation issue
<seb128> nxvl: we just worked on the same issue around the same time ;-)
<nxvl> seb128: no problem, i just want that annoying bug fixed
<nxvl> so
<seb128> alright
<nxvl> thank you!
 * nxvl HUGS seb128 
 * seb128 hugs nxvl
<ogra> mvo, ah, no it has sudo -u $USER ... its a user setting
<mvo> ogra: I toggled the key too, yes
<kwwii> ogra: haha, no...apparently the sounds are very window-ish (/me has no windows and therefor didn't catch it)
<ogra> well, the vista sounds were made by robert fripp iirc ...
<ogra> that would honor us :)
 * calc will be making a new OOo ppa upload today after verifying the build
<calc> should only affect ppa users :)
<cody-somerville> calc, shouldn't affect anyone ;]
<zul> slangasek: ping can we get a FFE for drbd8 please?
<slangasek> zul: that's on the top of my list to look at today
<zul> slangasek: thanks
<evand> asac: is it a bug if continuous calls to udevadm trigger; udevadm settle causes this: http://evalicious.com/tmp/udevbug.png
<kirkland> seb128: hey
<kirkland> seb128: there's a couple of people complaining about the fact that the ~/Private encrypted mount creates an icon on their desktop
<kirkland> seb128: i'm wondering if there's an easy way that we could blacklist the ecryptfs ~/Private mount from generating that icon when mounted?
<stgraber> slangasek: hey, did you have a chance to look at the exceptions for ldm and ltsp ?
<slangasek> stgraber: not yet, no
<seb128> kirkland: we could teach gio to ignore those mounts easily
<seb128> kirkland: we get quite some bugs about unmounting not working on those directory
<kirkland> seb128: right...  for unmounting to work, it needs to call /usr/sbin/umount.ecryptfs_private
<seb128> kirkland: is that something which will be standard in intrepid? whoever worked on the spec should have though about nautilus integration from the start
<kirkland> seb128: well....  i worked on the spec, and specifically intended it for servers
<kirkland> seb128: but quite a number of people latched onto it as useful for the desktop
<seb128> ok, fair enough
<kirkland> seb128: my apologies for lack of nautilus integration, but that's not my strong suit or focus
<stgraber> ogra: fix confirmed to work for ltspfs, do you do the packaging change or do you want me to do it ?
<seb128> is there easy instructions on how to configure that somewhere?
<kirkland> seb128: as yourself, run "ecryptfs-setup-private"
<kirkland> seb128: logout, login
<seb128> kirkland: that's alright and quite understandable
<kirkland> seb128: that's pretty much it
<kirkland> seb128: there's a question in the alternate/server installer that does this for you
<kirkland> seb128: i don't think cjwatson ever ended up putting it on the desktop installer
<kirkland> cjwatson: ?
<seb128> kirkland: ok, I'll give it a try later and see if it's easy to ignore those
<kirkland> seb128: thanks much
<seb128> no problem
<kirkland> seb128: let me know if there's anything i need to do on the ecryptfs-utils side
<kirkland> seb128: or if you have any questions/problems
<seb128> ok I will
<kirkland> seb128: there's a community effort on making a python-gtk gui for it
<kirkland> seb128: i plan on integrating that in Jaunty
<kirkland> seb128: too late for Intrepid, i think
<seb128> right it's late not for this cycle
<nxvl> seb128: are there plans on including gimp2.6 for intrepid?
<cjwatson> kirkland: not as yet
<seb128> nxvl: it has been uploaded yesterday?
<nxvl> really?
<nxvl> ah yes
<seb128> nxvl: yes, why?
<nxvl> :D
 * nxvl HUGS seb128 
<nxvl> seb128: i still have 2.4.7 on my sistem
<nxvl> system*
<seb128> nxvl: it didn't build yet, gegl and babl need to be promoted, mir bugs have been filled and I pinged pitti who said he would have a look today
<nxvl> ohh
<nxvl> ok
 * nxvl HUGS seb128 again
<seb128> ;-)
<nxvl> intrepid desktop will rock!
<seb128> indeed ;-)
<ogra> stgraber, if you like to
<seb128> lool: speaking about gimp and gegl I noticed you commented on the bug, the package comes from debian so you should probably ask there
<stgraber> ogra: ok, will do. Won't take long, it's a simple change to the packaging.
<ogra> right, just a change to the dh_installudev line
<ogra> ping me for uploadin
<ogra> g
<slangasek> zul: could you please provide the information requested in https://wiki.ubuntu.com/FreezeExceptionProcess for the drbd FFe?
<zul> slangasek: yep
<nxvl> seb128: it looks like the update wasn't the solution (gtkhtml one)
<directhex> confirmation from one user that removing gnupg-agent fixes f-spot.
<stgraber> ogra: https://www.stgraber.org/download/ltsp/
<james_w> does anyone know if it's possible to set an inotify watch on a file that doesn't exist yet?
<stgraber> oh, wrong one :)
<stgraber> ogra: https://www.stgraber.org/download/ubuntu/ltsp/
<stgraber> this one should be better
<ogra> stgraber, tsk, buy a proper cert :P
<stgraber> I did a test build on amd64, package content after that was ok
<Daviey> james_w: you can set it on the location, at least
<stgraber> ogra: oh, right you can also use http:// :) and the cert is valid, it's just cacert so you need the cacert root certificate (not default in firefox, unfortunately)
<Daviey> james_w: ie, watch for a new file, then react to it via grep or similar
<ogra> i wasnt serious :)
<james_w> Daviey: you can set it on the parent directory with IN_CREATE, and get notified when a new file appears below it apparently, but the code I am looking at sets it on the file, and I can't determine if that is legal from the documentation.
<james_w> Daviey: have you seen it set on a non-existent file?
<stgraber> ogra: yeah, well a couple of co-worker were like, you should buy a real certificate, self-signed certificates are bad ... but they didn't realise it's not a self-signed certificate :) it's just a cert authority they don't have.
<ogra> uploaded
<stgraber> ogra: and buying a *.stgraber.org can be quite expensive for basically my website and my webmail :)
<Daviey> james_w: pass.. sorry no idea
<stgraber> ogra: cool, thanks
<james_w> Daviey: never mind, thanks for the help
<james_w> I guess I should write a test case
<ogra> stgraber, yeah, i know a guy who made millions with that cert stuff :)
<stgraber> ogra: oh, really. I wonder who ? :)
<ogra> hehe
<james_w> yeah, you can't set an inotify watch on an open file.
<james_w> on a non-existent file I mean.
<pitti> superm1: did you send 03_dell_studio.patch (hal-info) to upstream? I didn't see it on the list, but it might have slipped my attention
<pitti> superm1: unless there was an objection, I'd just commit it upstream, to get rid of our hal-info patches
<superm1> pitti, i sent it upstream, and matthew garret commented on it
<superm1> pitti, he said not to detect specifically on a line of computers unless there is a known conflict
<superm1> pitti, but i had assumed he committed it as not detecting on that line then
<slangasek> superm1: how's bluez 4.x coming along?
<superm1> slangasek, i'm doing a retest of SCO stuff on upstream's 4.12, they had claimed it should be working
<superm1> slangasek, and i'll upload after i make sure it's clean for input things (whether or not sco is)
<slangasek> ok
<pitti> superm1: ah, I see, http://lists.freedesktop.org/archives/hal/2008-October/012330.html
<pitti> superm1: it's not committed yet
<pitti> superm1: oh, sorry, it is; nevermind me
<pitti> superm1: argh, my first look was right; it's not committed
<pitti> superm1: I got confused, there is this line already:
<pitti>           <append key="input.keymap.data" type="strlist">e013:f23</append> <!-- FIXME Fn+Left arrow Auto Brightness -->
<pitti> superm1: but your's was e00c:f23
<slangasek> zul: is there an upstream changelog for drbd?  That's probably what's going to be most useful for reviewing
<zul> slangasek: yeah ill attach it sorry about that
<superm1> pitti, yeah these newer laptops unfortunately changed that a few of those keys keycodes
<slangasek> zul: n/p, thaks
<slangasek> n
<pitti> superm1: does the FIXME mean that the e013 is actually invalid, or they apply on older models?
<pitti> superm1: do you still have that thread or latest reply, and could bounce it to me? then I can answer without breaking the thread
<superm1> pitti, it means that it's valid but the key doesn't do anything useful
<superm1> pitti, yeah i can bounce you into the thread
<superm1> pitti, on the windows side there is a little "tooltip" that pops up telling you that your keyboards light has been turned off, or  the ambient sensor is adjusted (as though you don't already know), but that's what that keycode is for - if such a thing is added in linux
<zul> slangasek: done
<slangasek> thanks
<pitti> superm1: got it, thanks
<superm1> thanks pitti
<pitti> superm1: done, and replied; thanks
<lool> seb128: Indeed
<seb128> lool, pitti: anybody of you could look for the babr and gegl mir today or tomorrow?
<nxvl> seb128: ping
<seb128> nxvl: hello
<seb128> nxvl: I tried the fix here, did you restart evolution?
<nxvl> seb128: yup, i think... :D anyway, i was thinking doesn't evolution need to be rebuilded?
<nxvl> heh
<nxvl> i just got the update
<nxvl> :P
<seb128> nxvl: no, the composer is a gtkhtml widget
<nxvl> really?
<nxvl> isn't it a library?
<seb128> gtk is a library too and it has widgets
<seb128> a widget is an object
<seb128> you can have it in a library
<nxvl> oh!
<nxvl> i need to read more about gnome development
<nxvl> \o/ it works
 * nxvl HUGS seb128 once again
 * nxvl is starting to think that he has hug seb128 a lot today
<seb128> yeah, I was thinking that too ;-)
<seb128> but good to know that's working!
<nxvl> :D
<digistyl3_> anyone familiar with alsa and pulseaudio in intrepid?
<superm1> slangasek, okay i've dropped bluez itself into NEW.  once it clears through the queue and is in the appropriate component, i'll upload more.
<pitti> superm1: ah, already exercising your new superpowahs? :-)
<superm1> pitti, :)
<pitti> halp plz! how can I ask git for the equivalenze of "bzr ignored", i. e. display a list of files which aren't tracked?
<superm1> pitti, 'git status', achieve what you are looking for?
<pitti> nope
<pitti> it doesn't show me anything, and --help doesn't help either
<pitti> ah, seems "git ls-files -o" does the trick
<slangasek> superm1: ah hrm, bluez is sourceful new?  why do source packages have to change names :(
<superm1> slangasek, it's because bluez-libs and bluez-utils are one package now
<seb128> uploading the new bluez stack? good ;-)
<slangasek> superm1: am I going to fail if I try to match the code up by hand for a source check?
<superm1> slangasek, what does that mean?
<slangasek> superm1: it's in sourceful new, so I have to make sure it's ok for the archive; is it non-trivial to correlate the contents of the new bluez package with the two old packages, if I try shuffling dirs around?
<psusi> is there a way to have buildd build a private bazaar branch?  like if I want to link a bug report to a test fix package, rather than pbuildering it myself and uploading it as an attachment?
<superm1> slangasek, yeah it's likely non-trivial, you will get to a state where the directories will correlate, but not necessarily "all" of the content
<slangasek> superm1: bluez-audio is being renamed to bluez-alsa (with split contents)?
<slangasek> superm1: I raise this because I'm not clear on what the upgrade path will look like for users who had bluez-* installed in hardy, but not bluetooth; it looks to me like it will regress on upgrade
<RAOF> psusi: No.  It's not possible to have a buildd build a _public_ bzr branch.  The best you can do is a PPA.
<psusi> err, yea... that's what I meant.... personal branch..
<psusi> like code.launchpad.net/~Phillip Susi/package/branch.... how would I request that?
<superm1> slangasek, bluez-utils should pull it in as a transitional package
<slangasek> ok, I suppose that should cover the vast majority of cases
<slangasek> (accepted, btw, and watching for the binaries)
<superm1> slangasek, okay great, as soon as binaries clear I'll get the rest of the stuff uploading
<slangasek> tseliot: bug #275977 appears to have an ack from pitti; are you waiting on us for anything else before upload, or do we just need bryce to poke it?
<ubottu> Launchpad bug 275977 in gnome-control-center "Setting the Virtual resolution should be easier" [Wishlist,Confirmed] https://launchpad.net/bugs/275977
<tseliot> slangasek: bryce has just uploaded the packages
<slangasek> ah
<tseliot> slangasek: thanks for your interest ;)
<slangasek> tseliot: the bug is still open, though?
<tseliot> slangasek: maybe the other report was closed. Let me check
<tseliot> slangasek: maybe should set them to fix released manually
<tseliot> we
<slangasek> tseliot: please do so, I assume you know what upload fixed it better than I do :)
<tseliot> slangasek: ok
<slangasek> superm1: these binary packages all have changelog files symlinked to the one in the bluetooth package; that's wrong, the changelogs will be missing unless the user installs bluetooth, which is not a dependency
<slangasek> superm1: is there a "common" package that everything deps on?
<slangasek> superm1: libbluetooth3, probably?
<superm1> slangasek, most of them libbluetooth3.  this is likely a side effect of cdbs though, nothing I had changed at least.  how do you correct that?
<slangasek> hmm, this problem didn't exist in bluez-utils before.  Let me have a look at debian/rules, if I can still find it while we're mid-publish
<superm1> (i'll just do a second upload if it ends up being too late to catch in the first)
<directhex> i need a FFe for mono. security update.
<slangasek> directhex: bugfixes don't require FFe
<directhex> oh, good
<directhex> then i'll be hunting for a sponsor.
<slangasek> superm1: I don't see anything obvious that explains why this is happening to the changelogs :/
<slangasek> pitti: do you know what in cdbs would automatically symlink changelogs to the copies in another package?  This is happening in bluez, without a dependency between the packages
<slangasek> superm1: fwiw, I bet if you moved the libbluetooth3 binary package to be the first in debian/control, it would magically work right :-P
<slangasek> superm1: oh, and the description of the bluetooth package should probably not be 'Blueooth support' :-)
<superm1> slangasek, okie dokie, i'll move it around.  you going to grab it midpublisher, or should I just upload a second update?
<slangasek> superm1: it has to be a second update
<superm1> slangasek, okay
<slangasek> there's no mid-publisher grabbing I can do to make it disappear, I was just grabbing the source to look at :)
<superm1> slangasek, i'll actually hold off and queue this up in bzr for the end of the week.  upstream has a few bug fixes that they are working on at their development summit
<calc> OOo 3.0.0~rc4-1ubuntu1 now in the ppa :)
<directhex> calc, intrepid ships with 2.4 or a 3.0 rc?
<wst> calc: Nice, thanks! Will try them as soon as they have been built!
<calc> directhex: 2.4.1
<calc> directhex: 3.0 still isn't released yet, maybe next week though, but is too late to be in intrepid
<wst> no openoffice3 package in universe or something like that either?
<directhex> calc, absolutely fair enough (people are on at me for mono 2.0, so i know i know)
<calc> wst: building with versioning doesn't work anymore, but we might put it in backports to override 2.4.1, not sure yet
<wst> ah ok thanks
<calc> directhex: hopefully mono is slightly more stable than OOo in the general case though ;-)
<calc> directhex: up until last week they were still finding major blocker bugs
<directhex> calc, well, our diff.gz is a little bit smaller, but still full o' patches
 * calc bets they will find plenty of major bugs for OOo 3.0 a few weeks after its released
<calc> directhex: heh :)
<directhex> mono 2.0 only shipped yesterday
<calc> OOo diff.gz is up to ~ 100MB now
<directhex> calc, i noticed
<calc> hmm 95.4MiB for rc4
<calc> directhex: ah
<wst> calc: do you also want bug reports for these packages anywhere? or are there enough known issues already :-)
<calc> wst: if you file bugs make sure to use the help->report a bug so that it properly includes apport information
<calc> wst: but i'm sure there will be plenty of bugs in them, heh
<calc> wst: it shouldn't be too buggy from a packaging standpoint, but from upstream though it probably is
<wst> hehe ok we will find out :-)
<calc> it should be installable in probably ~ 6-10hr
<emgent> heya
<calc> emgent: hi
<emgent> calc: good morning :)
<calc> emgent: its 5pm here :)
 * calc heads off to clean up his house, will watch irc though
<emgent> hem.. sorry calc :)
<NCommander> superm1, so I can take it the bluetooth transition is now being uploaded inbulk :-)?
<superm1> NCommander, well in bulk would be a nice for loop to do it all, i'm double checking each of them locally and submitting patches to appropriate upstreams before i upload each
<superm1> NCommander, but please do upload the one you touched
<NCommander> superm1, I'm not an MOTU :-)
<superm1> NCommander, oh. become a MOTU already.
<superm1> ;)
<NCommander> superm1, haven't been in one full release cycle yet
<NCommander> (DIF jaunty is my application date, the email written, I just need to do the time now)
<superm1> NCommander, at least feels like you've been with us a while, but that's probably because you're so productive
<superm1> NCommander, good to hear
<NCommander> superm1, I'm trying to break 50 uploads before intrepid releases :-)
 * NCommander hears multiple gunshots from all directions
<NCommander> superm1, I'm finishing my NM application, so my services as a DD will be much more useful until DIF jaunty since I can help do NMUs if necessary to get patches to fly in reverse
<superm1> NCommander, ah yeah, that's a good point
<TheMuso> superm1: Oh you got core-dev? Congrats!!!
<bddebian> And get yelled at by other DDs for NMUing their packages :)
<superm1> TheMuso, yup, thanks :)
<NCommander> bddebian, you obviously saw that bug then :-)
<NCommander> That teachs me to post a debdiff to help someone else
<superm1> slangasek, it looks like there is a separate SRU bug for nautilus-sendto.  isn't that part of the bluez 4.x 4.x exception?  I'm not sure why it was filed separately
<bddebian> NCommander: No, it happens to all of us :)
<slangasek> superm1: I didn't file it :)
<NCommander> bddebian, yeah well, your AM wasn't CCed for the entire 10 email flame war
<superm1> slangasek, should I upload it then, or do you/rest of ubuntu-release want to look at it separately then?
<slangasek> superm1: and haven't even looked at it, yet; I guess there are separate upstream changes that someone thinks need blessing?
<superm1> slangasek, yeah.  didn't realize nhandler_ popped it on a different bug
<bddebian> NCommander: Who is your AM?
<NCommander> bddebian, huggie
<bddebian> Ah
#ubuntu-devel 2008-10-08
<Gast_304_> Bitte spendet mir was, hab grad erst neu angefangen. Brauche jeden Cent um mir ein Bier zu holen!!! http://www.pennergame.de/change_please/7842526/
<Gast_304_> Bitte spendet mir was, hab grad erst neu angefangen. Brauche jeden Cent um mir ein Bier zu holen!!! http://www.pennergame.de/change_please/7842526/
<Gast_304_> Bitte spendet mir was, hab grad erst neu angefangen. Brauche jeden Cent um mir ein Bier zu holen!!! http://www.pennergame.de/change_please/7842526/
<cody-somerville> lol
<cody-somerville> He sure got us!
<superm1> TheMuso, when were you planning on doing that ALSA upload with the merged bluetooth stuff?
<stgraber> slangasek: thanks for approving the freeze exceptions
<hechicero> holaaaaaaaaa
<slangasek> good morning
<slangasek> stgraber: n/p :)
<hechicero> I need your help
<TheMuso> superm1: Very soon, just testing the changes on a 32-bit only arch.
<TheMuso> that I need to make.
<slangasek> superm1: just granted the freeze exception on nautilus-sendto, if you're handling that one
<stgraber> Is hppa known to be broken ? I had an iTalc build that FTBFS because of broken dependency.
<stgraber> The following packages have unmet dependencies: imagemagick: Depends: libmagick10 but it is not going to be installed
<slangasek> yes, TTBOMK everything from glib2.0 on up the tree is broken on hppa, at least
<stgraber> hmm, ok
<slangasek> imagemagick looks to be up-to-date, though
<stgraber> that was yesterday, maybe it got solved
<stgraber> https://edge.launchpad.net/ubuntu/+source/italc/1:1.0.9.1-0ubuntu2/+build/731156
<slangasek> ah, no, libmagick10 depends on glib2.0 as well, interesting :)
<stgraber> hehe, so that explains :)
<TheMuso> superm1: we will need to get the bluetooth alsa-plugins either into ia32-libs, or create a bi-arch bluez-alsa package.
<TheMuso> superm1: alsa-lib uploaded.
<mathiaz> slangasek: does this ring a bell: http://paste.ubuntu.com/55144/?
<mathiaz> slangasek: someone is trying a -server install in #ubuntu-server but it fails because of dmraid.
<slangasek> mathiaz: not to me, no
<mathiaz> slangasek: is it normal that it doesn't fetch the Packages file from the cdrom?
<slangasek> mathiaz: easily explained, though; dmraid isn't on the server CD but dmraid-udeb is, so it's probably an apt-install call that fails and dmraid needs to be seeded for server
<slangasek> mathiaz: ah, that; there's been some fiddling with Packages/Releases in intrepid for reasons of space right up to the beta, so some warnings are to be expected at least
<slangasek> mvo has been working on it
<mathiaz> slangasek: hm ok - the latest daily iso seem to have dmraid on them.
<stgraber> we had the same problem with LTSP on Alternate
<stgraber> it made the LTSP install to file as only .gz versions of Release and Packages are available
<slangasek> mathiaz: ah; someone fixed the seed post-beta, then?
<slangasek> stgraber: right, that one was in the errata IIRC
<stgraber> I think so yes
<Chipzz> slangasek: btw, that doesn't explain why it wants to install dmraid in the first place
<slangasek> is it not a case of installing on hardware that needs dmraid?
<Chipzz> the server has solid hardware raid, where the RAID is seen as a SCSI drive. not some cheapass half-baked crap raid ;)
<slangasek> ah
<Chipzz> Dell Poweredge 2650
<slangasek> then a bug should be filed on dmraid for that
<Chipzz> Dell Perc
<Chipzz> slangasek: http://chipzz.safehex.be/syslog
<slangasek> mathiaz: do any of the server tests include a networkless install?
<mathiaz> Chipzz: the beta doesn't have the dmraid package on the cd. The latest -server iso do include it.
<Chipzz> slangasek: btw, the same hardwrae did not work after installation on hardy - it DOES work on debian etch though
<mathiaz> slangasek: not that I know of.
<Chipzz> mathiaz: yeah I'll try the latest daily
<mathiaz> slangasek: at least my testing always uses networks.
<mathiaz> slangasek: should this be added as a test case?
<Chipzz> just mentioning this as a seperate issue
<slangasek> mathiaz: sounds like something that ought to be added to the checklist, yeah
<slangasek> mathiaz: since these are all cases that would be silently resolved when a network is availabel
<slangasek> le
<Chipzz> slangasek: I think something is bugged with the initrd, as that was where it was failing with hardy
<Chipzz> failed to mount the root partition
<slangasek> could you file a bug about that?
<Chipzz> I can, but I want to try the latest beta first
<Chipzz> (obviously)
<Chipzz> or should a bug be filed against hardy too?
<slangasek> hardy is meant to be supported beyond the end of intrepid's support cycle, so it'd be nice to catch & fix such issues
<Chipzz> slangasek: btw, if needed I could give you "console access"
<Chipzz> the thing has a remote access controller
<Chipzz> requires IE and java though :(
<stgraber> superm1: You're a mythbuntu guy right ?
<Chipzz> I tried to upgrade the DRAC firmware tonight, which *should* have fixed it, but alas
<slangasek> Chipzz: I'm afraid I don't have time to look at this directly, hence encouraging you to file bugs :)
<Chipzz> sure :)
<Chipzz> I meant more along the lines of: "if needed"
<Chipzz> I'll be glad to have to bloody thing installed *at all* really
<Chipzz> sigh
 * Chipzz swears
<Chipzz> no network interfaces detected??
<slangasek> Intel GigE?
<Chipzz> yeah
<stgraber> update your kernel :)
<stgraber> (if you can)
<Chipzz> stgraber: with te installer?
<Chipzz> stgraber: daily installer image
<stgraber> well, anything that's a kernel with e1000 back in should work
<Chipzz> slangasek: can this be fixed after installation? I suppose so?
<stgraber> today's daily for instance
<Chipzz> stgraber: trying the latstes daily as we speak
<Chipzz> that's what failing in the first place
<Chipzz> *latest
 * Chipzz swears again
<Chipzz> it dropped me to the checklist
<Chipzz> I select "Detect disks"
<Chipzz> I select "Partition disks"
<Chipzz> which does the same as "Detect disks" and subsequently drops me back to the checklist
<Chipzz> disk-detect: FATAL: Module dm_mod not found
<Chipzz> fail :P
<Chipzz> erm
<Chipzz> current daily appears to be severly broken?
<Chipzz> # ls /lib/modules/
<Chipzz> 2.6.27-4-generic
<Chipzz> # cd /cdrom/pool/main/l/linux
<Chipzz> # ls *2.6.27-4*udeb | wc -l
<Chipzz> 4
<Chipzz> ???
<Chipzz> only 4 kernel udebs for the running kernel?
<Chipzz> that won't work :P
<Chipzz> there are modules for 2.6.27-5
<slangasek> yes, there were image build failures all around today; 2.6.27-4 was meant to already be superseded, I'm not sure why the initramfs has the wrong kernel if that's the case
<Chipzz> should yesterdays image work better?
<slangasek> yesterday's won't have networking
<slangasek> but it should be intact otherise
<slangasek> w
<Chipzz> I can live with that I guess
<Chipzz> I can then use the previous cd to chroot into the installed image and run apt-get upgrade :P
<Chipzz> haxxx++
<Chipzz> :P
<Chipzz> going out for a smoke
<zul> slangasek: drbd8 ok for ffe?
<superm1> stgraber, that's what they tell me at least
<superm1> slangasek, yeah i'll take care of uploading the nautilus-sento sru tomorrow
<superm1> TheMuso, ah that makes an interesting problem.  i'm wondering how necessary it is though considering alsa stuff isn't working on sco (only a2dp)
<TheMuso> superm1: I don't know, but if skype has a remote chance of working, its worth doing.
<superm1> TheMuso, well if I get my headset to operate via SCO, sure
<superm1> TheMuso, upstream will be having a bug fix release later this week that should be more optimistic, so i'll see then
<superm1> TheMuso, how does skype even operate on 64 bit though?
<superm1> all 32 bit compat libraries?
<stgraber> superm1: ok, can you please update https://wiki.ubuntu.com/Testing/Cases when you have time ?
<TheMuso> superm1: Using ia32-libs/lib32asound
<superm1> stgraber, i'll defer that to tgm4883.
<stgraber> superm1: I had a note "Add Mythbuntu to the tracker" but I'd like to know the details, so for each testcases please add a line to the table
<stgraber> superm1: ok :)
<slangasek> zul: acked in the bug
<slangasek> superm1: did you have any more info on "sco is supposed to work" from upstream?
<superm1> slangasek, yeah they're at a summit right now working on a few audio related bugs
<slangasek> heh, k
<CarlFK> is there python module that wraps or binds or anything to expose what dpkg does?
<lifeless> the apt module is the closest I know of
<StevenK> There's python-apt
<CarlFK> I am surprised to find         p1 = Popen(['dpkg', '--get-selections'], stdout=PIPE)
<CarlFK> yeah, i figured as much
<CarlFK> if self.isstr(pkglist) == True:  oh my...
<CarlFK> er... before I jump on coding style.. ï»¿if self.isstr(pkglist): would be preferred, right?
<CarlFK> how should I submit a patch for /usr/lib/python2.5/site-packages/NvidiaDetector/nvidiadetector.py ?
<CarlFK> open a bug report in lp and attach it mabye...
<superm1> StevenK, there's still something odd with this bluez upgrade since adding bluez-utils back in as a transitional.  it doesnt seem to be transitioning.  bluez-utils keeps getting held back unless you explicitly say to install it
<superm1> StevenK, do you have any suggestions on what's missing from the transition?
<StevenK> Hmmm
<superm1> I thought perhaps it needed a conflicts/replaces on a bunch of the old no longer present packages, so I put that into the ppa, added the ppa as a source and attempted dist-upgrade, but same thing
<StevenK> superm1: You're using apt-get upgrade?
<superm1> StevenK, apt-get upgrade, apt-get dist-upgrade, trying to use update-manager
<superm1> StevenK, none of them want to offer me bluez-utils.
<StevenK> dist-upgrade shouldn't hold back bluez-utils
<superm1> yeah that's what i thought; and why this seems so perplexing
<slangasek> superm1: what's the full output of 'apt-get install bluez-utils'?
<superm1> slangasek, http://paste.ubuntu.com/55173/
<superm1> i'm wondering if perhaps having the recommends on "bluetooth" is what's throwing things
<slangasek> superm1: I think for starters, you should Replaces: bluez-input/bluez-network/bluez-serial, without bothering with Conflicts: to force removal
<slangasek> the Conflicts aren't required and get in the way; the packages ought to be autoremovable afterwards anyway
<superm1> slangasek, they *do* conflict though
<slangasek> why?
<superm1> slangasek, they provide the same libraries that are in the bluez package now
<slangasek> no, that's what Replaces: is for
<slangasek> Replaces: means "the files from this package should supersede the files in the other package"
<slangasek> so you don't need the Conflicts: to accomplish this
<superm1> Hum, i've always seen the combination together conflicts/replaces.  You are referring to the "bluez" package, correct?  (Not adding this stuff to bluez-utils transitional package)
<slangasek> yes
<StevenK> Conflicts/Replaces is for libraries, usually, when they provide the same files
<StevenK> And you only want one installed at a time anyway
<superm1> so likely this should cover the case entirely?  I'll upload a test src package to the PPA to ensure it's resolved right.
<slangasek> the combination of conflicts/replaces together has a subtly different meaning; it's often useful to do because if you only have a Replaces:, then installing and subsequently removing a replacing package has unexpected effects
<slangasek> but in this case, that's completely irrelevant
<slangasek> + blacklist  cherry # we do not like red fruits
<slangasek> pitti: ^^ what a terrible regression to introduce in an SRU!
 * Hobbsee steals, and eats, the blacklisted strawberries.
 * Mithrandir tickles Hobbsee and while she recovers, steals the not-yet-eaten strawberries.
<Hobbsee> oy!
 * Hobbsee puts Mithrandir through the Industrial Blender (tm)
<Mithrandir> oi!
<Mithrandir> I'm not blendable!
<Treenaks> Will Mith Blend!
<Treenaks> ;)
<Hobbsee> Mithrandir: Industrial Blender does not seem to agree with your claim.
<Mithrandir> Hobbsee: Industrial Blender seems to have spit me out in one piece.
<Hobbsee> good!  Then i'll have the strawberries back.
<Mithrandir> I've already eaten them.
<Mithrandir> you can have some grapes, but you'll have to pick them yourself.
<Mithrandir> they're quite good, though
<Hobbsee> they're not overly interesting...
<Hobbsee> erichj: I think you want #ubuntu-kernel
<Treenaks> Hobbsee: wow, you're a mind-reader :)
<Hobbsee> Treenaks: no, but I do sometimes read #ubuntu+
<Hobbsee> Treenaks: no, but I do sometimes read #ubuntu+1
<erichj> thanks Hobbsee
<Hobbsee> erichj: you're welcome.  They may not be up yet, either.
<Treenaks> Hobbsee: it still looks cool ;)
<Hobbsee> Treenaks: :)
<pitti> Good morning
<Hobbsee> pitti!
<StevenK> Morning pitti
<NCommander> StevenK, I've offically had my first cold day in hell bug in Debian
<pitti> slangasek: cdbs symlink> yes, that's an Ubuntu modification in /usr/share/cdbs/1/rules/debhelper.mk
<pitti> slangasek: eww, that indeed shouldn't happen
<StevenK> NCommander: Hah
<NCommander> StevenK, its an NMU, its a new upstream release, and its needed to clear a blocker in lenny
<NCommander> If that isn't cold day in hell criteria, I have no idea what is
<pitti> slangasek: SRU regression> hm, would you accept pineapples instead?
<slangasek> pitti: blacklisting pineapples would be ok
 * pitti ÉÄ±×ÉÉ¹ÊsnÉ oÊ sÇÊÉÊ
<StevenK> Haha
 * StevenK kicks gnuradio's upstream.
<NCommander> pitti, ok, I missed the joke, can to explain?
<pitti> NCommander: I went through great efforts to make it readable from the southern hemisphere
<StevenK> They seem to use memcpy() and such all over the place, but don't include <string.h> ?
<NCommander> StevenK, did I methon that in the process of releasing a new upstream, there is ALSO a soname bump
 * NCommander turns his laptop upsidedown
<pitti> slangasek: I have to discuss that with the kernel guys then; they do like pineapples
<NCommander> pitti, you have WAY too much time on your hands
<slangasek> pff, fruity kernel people
<NCommander> we need a blueberry kernel module
<NCommander> THat would be delicious.
<StevenK> Mango!
<slangasek> s/blueberry/marionberry/
<pitti> NCommander: I just have a weird way of naming kernel modules in test suites :)
<NCommander> pitti, no kidding.
<NCommander> Just as long as it isn't a lemon
<NCommander> ;-)
<NCommander> pitti, you have weird test suites, I get weird bugs
<StevenK> slangasek: So, who on the server team should I be bugging for this myobdc FTBFS?
<slangasek> StevenK: whoever uploaded the new version of mysql that broke the ABI?
<slangasek> StevenK: have you filed a bug yet about libmysqlclient15off being broken?
<StevenK> I was planning on
 * StevenK does so
<StevenK> slangasek: Bug 280011 if you want to stamp it and do stuff with it
<ubottu> Launchpad bug 280011 in mysql-dfsg-5.0 "libmysqlclient15off ABI changed without SOVER bump?" [Undecided,New] https://launchpad.net/bugs/280011
<StevenK> slangasek: Maybe adding more information since I'm not really clear on the issue.
<slangasek> StevenK: "upstream dropped ABI entry points without changing the soname"
 * StevenK thinks about dropping it in zul's lap
<StevenK> slangasek: Is it worth milestoning?
<slangasek> StevenK: yes
<StevenK> slangasek: Done.
<NCommander> superm1, ping
<StevenK> gr_fft_vcc.cc:78: error: 'memcpy' was not declared in this scope
<StevenK> SIGH
<NCommander> lool, you around?
<slangasek> StevenK: #include <string.h> kthx :)
<NCommander> lool, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494316
<ubottu> Debian bug 494316 in libsmbios1 "libsmbios 2.0" [Wishlist,Open]
<StevenK> slangasek: But I've had to do it for like 30 files
<slangasek> StevenK: yes, it's a shame the compiler didn't lart the author when it was first written? :)
<StevenK> Right
<StevenK> Maybe I need to write a Perl script.
<StevenK> Search every file that contains memcpy() and doesn't contain <string.h>
<NCommander> slangasek, being able to use memcpy() without string.h was one of those long standing GCC quarks :-)
<NCommander> slangasek, speaking of quirks, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/firefox-3.0/+bug/275410 - I'm just curious if this still needs any other work
<ubottu> Launchpad bug 275410 in firefox-3.0 "firefox wrapper script breaks sensible-browser, gnome-www-browser, and firefox-3.0" [High,Triaged]
<slangasek> NCommander: I was hoping asac would ack the fix and roll it into his next update, seeing how there are no Vcs headers for the package and he's listed as the maintainer, not core-dev
<NCommander> Ah. I just wanted to make sure that didn't get forgotten since its currently breaking a few things in Xubuntu nicely
<slangasek> I'd suggest following up with asac directly; it won't be forgotten, anyway
<anilg> Tim Spriggs is building an auto builder for Nexenta, and has created  a web interface for browsing packages..
<anilg> It also lists the ubuntu repository
<anilg> you can open a package by selecting the letter, see the various versions available, and expand it to see the dependencies
<anilg> http://builder.tajinc.org/?f=package_index
 * StevenK kicks gnuradio and wields grep
<anilg> ex : http://builder.tajinc.org/?f=package_status&view_method=name&package_name=g%2B%2B
<slangasek> StevenK: hrm, gnuradio, does that mean someone fixed python-wxgtk2.6?
<StevenK> slangasek: python-wxgtk2.6 was broken?
<slangasek> StevenK: if 'import wx' not working is broken, yes
<liw> StevenK, find . -name '*.c' | while read x; do if grep -q memcpy "$x" && ! grep -Fq '<string.h>' "$x"; then echo "bad: $x"; fi; done
<StevenK> liw: I was half-way through writing that ...
<StevenK> liw: Thanks :-)
 * StevenK fixes it to be -name '*.c' -o -name '*.cc'
<liw> if it's C++ it should probably include something like <cstring>, shouldn't it?
<StevenK> The amount of .cc files that are using stdio.h / stdlib.h rather than iostream in this source is scary
<pitti> yay for properly written C++ then :/
<StevenK> Tell me about it :-(
<StevenK> And gtklookat has defeated me again, but I'm not sure what to do about it, since upstream seems to have dumped it, and the API/ABI has changed a lot
<mvo> shows how much people like iostream too
<Mirv> pitti: as per last comment in bug 268674, 20080929 language packs should be removed from hardy-proposed since they (or part of them) do not have firefox translations anymore
<ubottu> Launchpad bug 268674 in language-pack-fi-base "[intrepid] Firefox Finnish localization non-existent in the package, other locales available" [Critical,Confirmed] https://launchpad.net/bugs/268674
<ubottu> Error: Launchpad bug 20080929 could not be found
<pitti> Mirv: ah, only the Finnish ones, or all of them?
<Mirv> pitti: I haven't checked others, asac's comment sounds like it would affect others, too
<pitti> bah; yay for stability
<Mirv> pitti: hmm, like with 8.10, also 8.04 some have translations (eg. swedish) and apparently some don't. so I don't know which ones are affected, but Finnish at least.
<Mirv> if the launchpad export format has changed it should theoretically affect more than one language...
<anolis> my system is semi broken.. i can't get x to load because my graphics modules need to be recompiled but i can't install kernel-source or linux-headers
<wgrant> anolis: This isn't a support channel.
<anolis> oh.. where is the support channel... sigh
<RAOF> anolis: /topic - #ubuntu for dapper-hardy, #ubuntu+1 for Intrepid
<anolis> thanks
<slangasek> tjaalton: bug #260675: do you have kernel commit access, or what more needs to happen to move this along?
<ubottu> Launchpad bug 260675 in wacom-tools "[intrepid] Wacom Xorg module is incompatible with the kernel module shipped in kernel packages." [Undecided,Invalid] https://launchpad.net/bugs/260675
<tjaalton> slangasek: nope, I've sent it to ubuntu-kernel@ and it was ack'ed but apparently hasn't been committed yet
<slangasek> ok
<cjwatson> liw: find -name '*.c' | xargs grep -l memcpy | xargs fgrep -L '<string.h>' is easier both to read and to write, I think :)
<liw> cjwatson, if you know about -L, yes :)
<liw> hm, I mistakenly sent that e-mail from @canonical.com (because evolution is confused and gets the address wrong when I reply-to-list), but usually the list manager has stopped such a mail and I've resent... now it didn't
<liw> I wonder why?
<wgrant> liw: ubuntu-devel should whitelist email addresses owned by developers registered on Launchpd.
<wgrant> +a
<liw> wgrant, I haven't changed those
<liw> hm, but I have @canonical there
<wgrant> Maybe you got caught in some update lag last time.
<liw> I havent' changed my e-mail addresss there for over a year, afaik
<wgrant> Hmmm.
<liw> I can't seem to change it at all
<stefanlsd> slangasek: thanks for the input on bug #25588 - i've suggested that par2 remains in suggests and we mark this invalid, as par2 is really optional.
<ubottu> Launchpad bug 25588 in backuppc "Backuppc should recommend par2 instead of suggesting" [Undecided,New] https://launchpad.net/bugs/25588
<Koon> asac: fyi, we'll be pushing soon a new release of openvpn to fix more rc8/rc9 regressions. Shouldn't affect n-m-openvpn but I thought it would be good to let you know. See bug 279655 for details.
<ubottu> Launchpad bug 279655 in openvpn "[FFe] Merge openvpn 2.1_rc11-1 from Debian" [Undecided,Confirmed] https://launchpad.net/bugs/279655
<cjwatson> wgrant: liw isn't in ubuntu-dev so isn't covered by the auto-whitelisting
<liw> with wgrant's help on #launchpad I did manage to change my e-mail settings, though (and removed all the addresses that LP is not, in my opinion, allowed to register for me :)
<wgrant> cjwatson: Oh, true, oops.
<cjwatson> liw: lars@c.c is on the ubuntu-devel whitelist - relatively close to the bottom so I presume it's fairly recent
<cjwatson> liw: should lars@u.c be there as well?
<liw> cjwatson, lars@ubuntu.com is how I'm subscribed, so that should be OK; lars@canonica.com is not supposed to e-mail the list ever, so it should not be on the whitelist, either
<cjwatson> ok, I've flipped them
<liw> thanks
<asac> Koon: ok. please test with NetworkManager thoroughly ;)
<liw> in any case, not a big problem, I was just surprised at the new behavior
<Koon> asac: I'm on it :)
<cjwatson> the whitelist is generally maintained by "hey, that person is sensible, why am I having to moderate their mail"
<cjwatson> so it's whatever address happened to be on the most recent sensible mail
<liw> cjwatson, I think you may want to smack anyone who thinks I'm reasonable
<liw> cjwatson, I've cancelled via mailman all the @canonical mail I've sent, when it has been caught up in the moderation queue, as far sa I know
<tkamppeter> pitti, have you seen my mail?
<pitti> tkamppeter: yes, I did
<cjwatson> liw: I have duly smacked myself
<liw> cjwatson, :)
<pitti> superm1: if you have a minute today, could you please test the jockey in hardy-proposed for b43 and wl?
<pitti> superm1: would be great to get that verified soon, so that -21 can move to -updates
<stefanlsd> slangasek: if an application is in main, can a recommends and suggests be in universe?  it just cant be in build-depends or depends?
<cjwatson> stefanlsd: suggests can, recommends can't
<cjwatson> (now that recommends are installed by default)
<stefanlsd> cjwatson: thanks. :)
<pitti> stefanlsd: suggests is ok, recommends isn't
<asac> Mirv: please test http://people.ubuntu.com/~asac/rosetta/fi.tar.gz
<Mirv> asac: looks good so far, installed it and everything seems to work
<Mirv> asac: also the location bar google search works now
<Riddell> ArneGoetje: when are you going to upload language packs?
 * pitti giggles at Soyuz -- "Estimated build start: 0 seconds ago", and that for 5 minutes already
<sistpoty|work> mvo: gtk2hs finally can be upgraded :) thanks for your help!
<asac> calc: do you have bug 272772 on your radar still?
<ubottu> Launchpad bug 272772 in ubuntu-docs "packages that Depend/Recommend/Suggest firefox (meta-package) must alternatively Depend/Recommend/Suggest abrowser" [High,Fix committed] https://launchpad.net/bugs/272772
<mvo> sistpoty|work: excellent, thanks a lot for the fix :)
<asac> mdke: ^^ that bug is fix committed for ubuntu-docs. whats the status on that?
<sistpoty|work> mvo: heh, np ;)
<Hobbsee> pitti: FYI, it seems that the module name has changed back (you fixed https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/246969 )
<ubottu> Launchpad bug 246969 in module-init-tools "[Intrepid] snd_pcsp module causing lockup when running as a VMWare guest" [Medium,Fix released]
<ogra> asac, and chance that we see the upstream fix for bug 269188 in intrepid ?
<ubottu> Launchpad bug 269188 in firefox "Extreme slowness, "Firefox is already running" error for >3 users launching Firefox in LTSP environment" [Unknown,Fix released] https://launchpad.net/bugs/269188
<Hobbsee> pitti: or at least, on my system it has
<asac> \sh: could you look at #277175 please?
<pitti> Hobbsee: gdm?
<pitti> Hobbsee: oh, that
<asac> ogra: i asked you to help me to evaluate that issue ;)
<asac> ogra: well at least the extreme slowness part
<ogra> asac, well, that fixed apparently
<pitti> Hobbsee: right, I get pcspkr again, but snd_pcsp still exists
<ogra> *thats
<Hobbsee> pitti: ah, right.
<asac> ogra: so its the urandom issue?
<Hobbsee> pitti: so they both do now.  brilliant :-\
<ogra> asac, seems teh fix is changing FF to use /dev/urandom instead of /dev/random
<ogra> asac, right
<asac> ogra: i cant believe that this is the only issue here :/
<ogra> i'm not sure, i also suspect the xcb changes to play a rold but have no clue how to verify that
<asac> ogra: given that /dev/random was used before i dont see how this might have popped up just now
<ogra> especially since people complain about openoffice in hardy as well
<apachelogger> pitti: hey, would be awesome if you could please take a look at bug 267599 without the plugin google talk is not working in Kopete, so we should get it in main for Intrepid.
<ubottu> Launchpad bug 267599 in qca2-plugin-ossl "Main Inclusion Report for libqca2-plugin-ossl" [Undecided,New] https://launchpad.net/bugs/267599
<ogra> *role
<pitti> apachelogger: I saw the bug mail, but I'm pretty swamped ATM (and I already did some MIRs today, *hint* *hint* team members)
 * apachelogger pokes asac doko and lool with the mir bug ^
<apachelogger> :P
<wgrant> Are we going to have syncs processed at some point?
<asac> apachelogger: runtime dependency of jabber, does that mean it gets loaded through dlopen?
<\sh> bug #277175
<ubottu> Launchpad bug 277175 in ia32-libs "ia32-libs is missing libgnutls26" [High,Triaged] https://launchpad.net/bugs/277175
<apachelogger> asac: good question, will have to check, I am not sure if kopete loads the plugin or libqca2
<asac> apachelogger: what jabber feature is broken/gets cured by this?
<asac> or is jabber completely broken now in kopete?
<apachelogger> asac: ssl encryption
<apachelogger> other than that it works
<asac> hmm ... wasnt ssl incompatible with GPL?
<seb128> wgrant: I'll do those today yes, why?
<wgrant> seb128: Just wondering, as there are lots pending.
<seb128> wgrant: ubuntu was frozen for a while for beta
<wgrant> seb128: Right, but that was almost a week ago now.
<wgrant> Anyway, as long as they get done fairly soon, all is good.
<seb128> wgrant: well, people have been busy since apparently, will do those today sorry about the delay
<wgrant> Thanks.
<seb128> you're welcome
<\sh> asac: I'm on it
<asac> \sh: great!
<ogra> \sh, and not done yet ? slacker !
<ogra> :)
<\sh> ogra: bah ,->
<asac> hehe
<apachelogger> asac: the plugin is LGPL
<asac> since we add more and more to ia32-libs, maybe we should just add all libs from main there? :-D
<ogra> we could drop everything from it and just call debootsrap --arch i386 from the postinst :)
<\sh> asac: I wonder if we need to replace libgnutls13 to libgnutls26 or just add libgnutls26...I do now the first shot
<asac> \sh: hmm ... i would say adding the new lib might be safer
<asac> apachelogger: how does the plugin use openssl? doesnt it link against it?
<apachelogger> asac: it does
<apachelogger> asac: kopete links against QCA, QCA tries to load the ossl plugin, which is in fact a qplugin and gets loaded via http://doc.trolltech.com/4.3/qpluginloader.html
<RainCT> mvo: Hey, I discovered the specification about the debdelta/etc stuff yesterday and I was wondering: is there anything working already? (ie, I know that some of the tools work but could I use them right now to update my system?)
<jg> ping superm1
<asac> apachelogger: what was used for ssl support before?
<apachelogger> asac: qca-tls
<apachelogger> along with libqca1c2
<mvo> RainCT: there is some code based on aptsync available, but its pretty crufty - it would be interessting to resurrect it
<RainCT> mvo: I don't think I can help with that, but I'm *very* interested in it :P
<asac> apachelogger: is there no gnutls based option available?
<apachelogger> asac: nope http://delta.affinix.com/qca/
<Riddell> mvo: why does update-manager-core have /usr/lib/python2.5/site-packages/UpdateManager/Core/DistUpgradeFetcherCore.py and /usr/lib/python2.5/site-packages/DistUpgrade/DistUpgradeFetcherCore.py ?
<mvo> Riddell: that should be just a symlink, no?
<Riddell> mvo: not here
<morgs> asac: Any chance of getting this fixed? https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/277564
<ubottu> Launchpad bug 277564 in xulrunner-1.9 "python-xpcom not available for xulrunner 1.9" [Undecided,New]
<mvo> Riddell: hm, at least it should be identical (its a symlink in the source)
<asac> morgs: we dont have a package split for it, but in theory python-xpcom should be in the xulrunner-1.9 package
<asac> morgs: and also, last i heard is that python-xpcom isnt really maintained upstream anyway.
<morgs> asac: We're actively using it for Sugar, so there's some chance of it getting maintained...
<morgs> I'll check if it's in
<cody-somerville> slangasek, james_w: I dreamt last night that your changes to policykit caused a regression and broke my production machine on upgrade :P
<james_w> cody-somerville: nightmare
<ogra> cody-somerville, you should start taking drugs to sleep dreamless then :P
<james_w> morgs: it's in there, and you can import it by changing sys.path
<morgs> james_w: OK, I'll check the sugar-hulahop packaging then
<cody-somerville> ogra, I should try that. Drugs not to sleep at all only seem effective for so long :P
<ogra> lol
<asac> morgs: dpkg -L xulrunner-1.9 | grep python
<morgs> asac: thanks!
<mvo> cjwatson: could you please merge from my debian-cd branch again (lp:~mvo/debian-cd/mvo) ? it reverts the change to remove the hashes from the Release file for the uncompressed file. I added code to update-manager now to deal with that on upgrades and will prepare a update for hardy-updates of apt
<superm1> StevenK, slangasek: it appears that dropping the conflicts did help, just had to do it on 3 of the binary packages to be useful.  thanks
<superm1> jg, momentary pong?
<superm1> pitti, yeah i should be able to take a look at some point today
<pitti> superm1: thanks
<\sh> asac: uploading...
<jg> superm1: just filed a bug against the XT; the graphics is glacial.  bug #280158.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/280158/+text)
<jg> glxinfo reports the software renderer is being used, and x11perf -aatext is also very slow (30Kchar/second).
<ogra> liw, do you mean to only have if-up/down.d scripts instead of having the initscript at all ?
<ogra> liw, re -> dhcpd
<liw> ogra, that's going into more detail than I know much about
<liw> ogra, also, implementation details :)
<ArneGoetje> Riddell: when they are ready. (hopefully friday... but with the current export delays it can be later)
<ogra> well, you say only bring it up if the interface is up ... that wuld mean to me to have it called from a if-up/down.d script and just not have any rcX.d links
<ogra> makes sense though
<ArneGoetje> Riddell: the upstream translations for the KDE packages are not fully imported into Rosetta yet anyways...
<cjwatson> mvo: ok, will do, thanks
<mvo> cjwatson: thanks, this should make it (finally!) work
<Riddell> ArneGoetje: sakes.  do you know why not?
<ArneGoetje> Riddell: because the database server is overloaded and the queue doesn't get smaller as long as new pakages are being uploaded.
<pitti> zul: did you see the patch in bug 228693? can you please review it and upload if it is good? thanks!
<ubottu> Launchpad bug 228693 in bacula "[SRU] bacula-director-pgsql postinstall broken" [Medium,Fix released] https://launchpad.net/bugs/228693
<zul> pitti: yes its on my todo list
<pitti> zul: good; no hurry, I just wanted to ensure it didn't get lost
<Riddell> do we still have ntp running at startup?
<pitti> Riddell: we have ntpdate in network/if-up.d/
<pitti> but AFAIK we never installed the ntp daemon by default, at least on desktops?
<Riddell> pitti: does that work with networkmanager do you know?
<pitti> Riddell: I'm not 100% sure with 0.7, but it definitively did with hardy and 0.6
<Riddell> seems to also be in dhcp3/dhclient-exit-hooks.d/ntpdate
 * pitti tests
<pitti> Riddell: confirmed, if-up.d/ is still run by n-m
<Riddell> thanks pitti
<seb128> pitti, thekorn: is that a known bug?
<seb128> launchpadbugs/buglistbase.py", line 160, in _add
<seb128>     url = bugpage.following_page
<seb128> AttributeError: 'list' object has no attribute 'following_page'
<seb128> the i386 retracer is crashing on that
<seb128> wgrant: syncs processed now
<Riddell> mvo: I want to upload update-manager but DistUpgrade/DistUpgradeVersion.py and DistUpgrade/mirrors.cfg seem wonky  http://muse.19inch.net/~jr/tmp/update-manager.debdiff
<mvo> Riddell: oh, give me a sec, forgot to push
<Riddell> mvo: also sould I care about this?  http://paste.ubuntu.com/55288/
<mvo> Riddell: should be harmless
<thekorn> seb128: no, I have never seen it, let me check the code
<mvo> Riddell: I pushed the version information changes, should be good now
<Riddell> mvo: what revision do I want?  I get "Tree is up to date at revision 1103."
<mvo> Riddell: sec, I check
<mvo> Riddell: please try now (my bad, r1104)
<Riddell> got it
<seb128> thekorn: thanks
<Riddell> mvo: groovy, uploaded
<asac> apachelogger: ok sorry was dragged away ;). final question: can i test it with not too much effort?
<mvo> Riddell: thanks
<mdz> pitti: the FDI fix has most of my hotkeys working again (suspend/lock/battery/hibernate), but I seem to have a different problem with my brightness keys
<mdz> they come through as XF86MonBrightnessUp and XF86MonBrightnessDown, but nothing happens
<mdz> I wonder if gnome-power-manager is meant to be listening to those?
<munckfish> calc: hi you got a sec? I'm struggling with the OpenOffice !x86 ftbfs problem (bug 273268) and I'd dearly love any direction you could give me.
<ubottu> Launchpad bug 273268 in ubuntu-ps3-port "ftbfs on all !x86 archs" [Critical,Confirmed] https://launchpad.net/bugs/273268
<thekorn> seb128: fixed in rev 164 of the main py-lp-bugs branch
<seb128> thekorn: thanks!
<calc> munckfish: still here?
<munckfish> calc: hi yes I am
<munckfish> calc: I've been trying to dig and see if I can identify where the linker paths are set for the JDK native libs
<calc> munckfish: yes i have a fix for the path problem that may allow ppc/sparc to build
<munckfish> which the "bean" module needs to link with
<munckfish> calc: oh great!
<calc> munckfish: but ppc usually fails to build OOo when java is enabled so i might have to completely disable java again
<munckfish> calc: ok
<munckfish> is that a last resort?
<munckfish> I guess it is - that would be fine with me - my priority is being able to install Ubuntu at all
<munckfish> :D
<Riddell> mvo: apt-auth-failure.note seems unreliably gnomeish
<calc> munckfish: yea, OOo uses java for a lot parts so turning it off isn't great, but if ppc still can't build with java then i might have to do that
<Riddell> mvo: what does it do?
<Riddell> and can we replace it with a script which can run kde equivalents?
<mvo> Riddell: give me a sec, I need to check
<munckfish> calc: so what's the next step? How soon could you test out your fix?
<mvo> Riddell: I think we should add a /usr/share/apt/apt-auth-failure-retry.sh that trys to detect the desktop used and does the right thing. for jaunty we can use Packagekit
<Riddell> mvo: I wonder if smarter will volunteer to write that :)
<smarter> Riddell: I can try ;)
<smarter> what do we use for automatic updates in Kubuntu now? update-notifier-kde?
<smarter> adept batch is gone; no?
<Koon> ogra: about your dhcp3 bug 280123 -- NetworkManager is at S30 and dhcp3-server at S40 so the initscript should be ok -- or I am missing something ?
<ubottu> Launchpad bug 280123 in dhcp3 "dhcp3-server needs initscript adjustment for network manager managed mode" [Undecided,New] https://launchpad.net/bugs/280123
<Ng> mvo: when update-manager says the changelog isn't available yet and I should use launchpad, could it not just do that for me? :)
<apachelogger> asac: do you have a gmail account?
<Riddell> smarter: hmm, good question, I've been meaning to add that (to install-package)
<mvo> Ng: it could, but I have not done that because there is a risk that with too many people that may kill LP because of the hit
<mvo> Ng: but there is a bugreport where people wondered the same - I should talk to #launchpad and hear their opinion I guess
<asac> apachelogger: why?
<asac> evand: yes. i think that bug is known
<calc> munckfish: have to merge some other changes then may be able to upload it by later tonight, takes several hours to build
<asac> evand: it also happens if you restart hal afaict
<calc> anyone know why a PPA build would show that it worked but the binaries not show up?
<apachelogger> asac: google talk would be the easiest way to test I think
<calc> oh never mind
<calc> it just finished right before i loaded the page
<apachelogger> seeing how kopete can't even fall back to unencrypted connection because google doesn't support it
<asac> apachelogger: i have a jabber account with ssl ;) ... i just wondered what i need to install etc.
<asac> or if i need to rebuild something in the archive (i guess not)
<evand> asac: ok, noted.  Thanks
<asac> evand: bug 274470 ;)
<ubottu> Launchpad bug 274470 in network-manager-applet "[Intrepid] Network interfaces duplicates" [Undecided,New] https://launchpad.net/bugs/274470
<evand> ah, much appreciated.  Subscribed.
<asac> evand: if someone now would properly triage this, it would be much better :-D
<asac> but i will do that now :)
<apachelogger> asac: install kopete -> start it -> settings -> configure -> add account -> jabber -> enter acocunt info -> go to connection tab -> tick encryption setting -> next -> finish -> you should get an error about the encrption stuff -> quit kopete -> install libqca2-pluign-ossl -> start kopete -> connect -> should work
<asac> apachelogger: ok. and the reason we need this is because kopete is now on kde4, right?
<munckfish> calc: "takes several hours to build" --> understatement. That was one of my big concerns with this one - the only powerpc hardware I have is my PS3.
<apachelogger> asac: yes, qca2 is for Qt 4, qca was for Qt 3
<munckfish> calc: and that only has 256MB of RAM - consequently everything seems to take double the time to compile. :D
<munckfish> calc: ok thx for your help
<calc> munckfish: probably on a ps3 it would take days
<calc> munckfish: it takes 3-4hr on a 6gb c2d 2.8ghz system
<munckfish> calc: yes I think you're right
<asac> apachelogger: ok done
<slytherin> any archive admins around? I am looking for some java libs to be moved to universe.
<apachelogger> asac: works?
<apachelogger> ah
<apachelogger> asac, pitti: thank you both :)
<slangasek> cody-somerville: tell us more about this lack of faith your subconscious has in us
<cody-somerville> slangasek, probably has to do with the bug that a number of packages had awhile back with directories not existing in /var/run/
<lool> superm1: Hey, around?
<superm1> lool, hi
<kees> anyone know why screen-resolution-extra is part of "contrib"?  I don't think that's right.
<ogra> Koon, oh, i looked at the package, it called dh_installinit with default values, though the ifup/down stuff is still open
<ogra> but that indeed makes it easier
<Koon> ogra: somehow it changes that in postinst. ugly.
<ogra> Koon, aha, yeah, definately ugly
<tseliot> kees: screen-resolution-extra is now part of X11 (the Section in the control file)
<slangasek> cjwatson: what does this debian-cd build error point to?: debian-installer has kernel ABI 2.6.27-4-generic, but no corresponding udebs are
<slangasek>  on the CD!
<superm1> pitti, provided I remove linux-backports-modules-* that SRU looks good.  It can't enter -updates with everything else though until the LBM thing is sorted
<kees> tseliot: so it is!  thanks.  vrms hates me slightly less now.  ;)
<directhex> yay, i got mentioned on boycottnovell.com's frontpage. woo!
<tseliot> kees: hehe
<pitti> superm1: hm, that thing still didn't build yet?
<pitti> superm1: bumped the build prio
<superm1> pitti, ok, i'll keep this machine at intrepid to watch for when it shows up
<superm1> er hardy
<Chipzz> slangasek: I managed to install the machine - in the end :P
<slangasek> Chipzz: yay :)
<Chipzz> through some very ugly hacks though
<Chipzz> it involved creating my own sources.list and: while : ; do cp sources.list /target/etc/apt ; done
<Chipzz> (during the base install)
<Chipzz> slangasek: I did notice some other brokenness too though
<Chipzz> for one, grub-installer either not getting run at all, or getting run on the wrong disk
<Chipzz> and v86d not being installed, while needed (? maybe just invoked) by the initramfs
<CarlFK> Chipzz: I just had grub-installer troubles too.  --recheck seemed to be the solution.  https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/280270
<ubottu> Launchpad bug 280270 in grub-installer "alt installer: Running 'grub-install  --no-floppy  "(hd0)"' failed." [Undecided,New]
<Chipzz> CarlFK: I didn't get any errors though
<Chipzz> actually I installed twice (encrypted lvm config not to my liking); the first time, I needed t boot into rescue mode and run grub-installer, the second time I just did it before finishing the installation
<Chipzz> one question though: is dmraid used exclusively for software raid, or is it used somehow with lvm/encrypted lvm too?
<doko> calc: the ooo3 help packages need a dependency on ooo (>= 3.0~rc)
<CarlFK> Chipzz: I also have had problems when I booted from a usb stick, and so grub saw that as the boot device to install to.  could that be your problem?
<CarlFK> no clue about dmraid
<Chipzz> no
<Chipzz> booting from cd
<Chipzz> (for the installation)
<Chipzz> hardware raid once installed
<CarlFK> well, that's all I got.  im just a user.
<Chipzz> me too - but a user with a lot of clue ;)
<CarlFK> sometimes I have a clue.
<Chipzz> CarlFK: btw, my problem was during ubuntu-server install
<Chipzz> ie not related to ubiquity
<CarlFK> mine was alt-installer - pretty sure the same installer
<geser> kees: -5 was also affected by that kernel bug, will try out -6 soon
<kees> geser: hrm, the -5 I was running had the changes I put in -6, so I'm hoping you don't see it in -6.
<jdong> compiz lords, what the hell is horizontal scrolling supposed to do in compiz opacity?
<jdong> oh FFS
<jdong> alt-leftscroll lowers the window focus, alt-rightscroll raises it.
<jdong> who thought of that?
 * jdong whines in bug 279679
<ubottu> Launchpad bug 279679 in compiz "Opacity plugin usability degraded by alt-button6 lower window binding" [Undecided,New] https://launchpad.net/bugs/279679
<mterry_> doko: What's the story with liveconnect and openjdk these days?
<doko> not yet working
<mterry_> doko: OK  :)
<slangasek> evand: I see you commented on bug #14135 back in May; do you know if this problem is addressed by the UUID changes?
<ubottu> Launchpad bug 14135 in grub-installer "Grub Install Failure" [High,Confirmed] https://launchpad.net/bugs/14135
<evand> yikes, there's a poorly titled bug
<evand> there appears to be plenty of different problems in there, but it will fix cases where grub fails due to changes to the BIOS device ordering.
<evand> slangasek: ^
<slangasek> evand: ok; could you close the bug with that explanation, so I'm not relaying?
<slangasek> (if you think it should be closed, that is)
<evand> will do
<slangasek> thx
<evand> well, I'll make a note to close it once the UUID changes are in, asking users to file new, separate bugs, should they still experience problems
<slangasek> the UUID changes aren't in?
<evand> slangasek: They're in grub proper, but update-grub doesn't write them yet.  I'm fixing that though.
<slangasek> evand: ok
<brandon|work> is the winbind package maintainer in here?
<jcristau> that would be slangasek
<slangasek> lies
<slangasek> Ubuntu doesn't have package maintainers :-)
<brandon|work> heh
<brandon|work> slangasek: if I make a bug in launchpad for winbind, will you be cc'ed to it?
<slangasek> brandon|work: no
<brandon|work> hrm
<slangasek> because I don't maintain the package... :)
<brandon|work> oh
<brandon|work> ok
<elisboa> Hi; how do I create a package from scratch?
<elisboa> I want to create a package named squid-conf, which only carries a squid.conf file
<elisboa> Then, it diverts it from squid on preinst script and reverts in postrm
<mathiaz> mvo: hi - what's your opinion on bug 84918?
<ubottu> Launchpad bug 84918 in unattended-upgrades "package should set up sensible config" [High,Triaged] https://launchpad.net/bugs/84918
<mvo> mathiaz: we install it by default so we can not enable it by default IMO. but we should ask a debconf question I think
<mathiaz> mvo: ok. And then the debconf question could be preseeded in the installer.
<mvo> mathiaz: yeah, that would be good. not sure we should do it for intrepid though, its a bug that is open for some time already :/
<mvo> mathiaz: on the desktop its very simple, there is a checkbox for it in software-properties
<mvo> but I guess on the server that is not a ideal solution
<mathiaz> mvo: http://people.ubuntu.com/~mathiaz/update-policy.png <- this is the installer step
<mathiaz> mvo: if the user chooses Install security updates automatically, unattended-upgrade is installed.
<mvo> mathiaz: oh, nice! out of curiosity, "manage with landscape" means they need a subscription, right?
<mathiaz> mvo: correct
<mvo> mathiaz: installed or installed and setup?
<mathiaz> mvo: as of now, it's only installed
<mathiaz> mvo: but not setup - which is defintely not what is expected
<mvo> heh :)
<mvo> yeah
<mathiaz> mvo: so a debconf question could be added to unattended-upgrades to ask if the system should be setup automatically
<mvo> mathiaz: I think that would be best, yes
<mathiaz> mvo: another option would be to add another package that would enable automatic updates
<mathiaz> mvo: the debconf question would default to *not* enable automatic updates
<mvo> mathiaz: right, putting the config in nother package (or part of it) would work too
<mvo> mathiaz: I think *not* enable by default is the right choice, it should be a concious decision IMO
<mathiaz> mvo: I agree with that. OTOH the first few times I installed the unattended-upgrades package on my servers I was surprised it wouldn't work OOTB
<mvo> right
<mvo> maybe the right answer is *enable* by default but override that (via preseeding) in the desktop install
<mathiaz> mvo: that would make most sense IMO
<mvo> mathiaz: ok, I'm uneasy about it at this point, but I'm fine with that in the next cycle
<pwnguin> slangasek: is there a tracking bug for PAMConfigFrameworkSpec?
<mathiaz> mvo: uneasy about enable by default or adding a debconf question?
<mvo> mathiaz: enabling it by default and adding code to the various installers so that they DTRT
<mathiaz> mvo: ok - so what about adding a debconf question defaulting to *not* enable by default and adding a line in pkgsel to preseed the debconf question to *enable* unattended-upgrades in the server installer if the user chooses the correct option?
<mvo> mathiaz: sounds good to me
<mathiaz> mvo: ok - I'll prepare a debdiff for unattended-upgrade and will run it by you.
<mvo> mathiaz: its mantained in bzr at sftp://mvo@people.ubuntu.com/home/mvo/public_html/bzr/unattended-upgrades/unattended-upgrades--mvo/ but it should really go into ~ubuntu-core-dev/
<mvo> mathiaz: excellent, debdiff is fine
<mathiaz> mvo: are you sure your bzr branch is up-to-date? the last commit date is 2007-01-23
<mvo> mathiaz: sorry, my bad (its late here). its actually lp:~ubuntu-core-dev/unattended-upgrades/ubuntu
<mathiaz> mvo: ah - much better :) - thanks
<mvo> thank you!
<sbeattie> slangasek: is there a reason alternate cds aren't building?
<slangasek> sbeattie: yes, but not a reason I've been able to analyze; I pung cjwatson1 about it earlier
<slangasek> pwnguin: no, is there expected to be?
<pwnguin> slangasek: well, i was just curious if there was any tracking of the task or progress;
<pwnguin> ive noticed fprint doesn't set anything up (universe package pulled from experimental). wanted to check if it was planned or rejected or simply ignored :)
<sbeattie> slangasek: was guessing the following probably had something to do with it:
<sbeattie> Adding the selected packages to each CD :
<sbeattie> /usr/share/debootstrap/functions: line 177: [: =: unary operator expected
<sbeattie> /usr/share/debootstrap/functions: line 373: : command not found
<sbeattie> (from http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/intrepid/daily-20081008.log)
<slangasek> sbeattie: I didn't think so, but I'll double-check
<slangasek> sbeattie: yeah, that goofy failure is present in successful builds to
<slangasek> pwnguin: the initial spec is implemented, except for hooking it into the GUI; the only package that I think we still need to try to get updated to interface with this for intrepid is libpam-krb5
<ScottK> pitti: If apport is making public bugs dupes of private ones is that an apport bug or a Launchpad one?
<NCommander> ScottK, are you going to be at UDS?
<NCommander> (^- StevenK too)
<RainCT> Is someone coming to Mozilla Camp Europe? :P
<NCommander> RainCT, not after the blocker that happened at the last one :-)
<james_w> ScottK: it's always done that hasn't it? Or is this a private bug that you can't see?
<wgrant> seb128: Great! Thanks.
<ScottK> NCommander: No.
<NCommander> ScottK, pity, I'm figured out who to try and room w/
<ajmitch> it generally gets allocated
<ScottK> james_w: I could see the private bug, but it does seem wrong to dupe the public bug to the private one.
<ScottK> Last time we got asked for preferences if we had them.
<wgrant> ajmitch: But one can make requests.
<ajmitch> wgrant: if you care enough, sure
<seb128> wgrant: you're welcome
<wgrant> ...
<wgrant> I think I regret posting on ubuntuoforums now.
<NCommander> wgrant, what happened?
<wgrant> Somebody decided I was a good person to email for help with fglrx on Intrepid, and emailed it to all of my public email addresses.
<mrooney> wgrant: :)
<directhex> wgrant, it's a bad place. currently i'm trolling it a little.
<mrooney> maybe it is better to not stop posting but just to provide a different email address on your profile, one not so primary
<wgrant> mrooney: No, no, they trawled far and wide for these.
<wgrant> Probably Launchpad and keyservers.
<mrooney> wgrant: oh haha, how clever!
<mrooney> sounds like a good idea
<ajmitch> wgrant: because you're obviously a helpful person
<geser> kees: the kernel bug still happens with -6
<mrooney> wgrant: I will start suggesting on all new bug reports that users email you directly for help!
<kees> geser: ugh, that's bad.  do you have a workload you've been able to reproduce it with?
<geser> no :( I didn't find out yet under which circumstances it happens
<kees> geser: yeah, I'm at a loss to create it too.  I tend to notice it most doing builds, but not lately.  :(
<RainCT> NCommander: blocker?
<NCommander> RainCT, ?
<geser> kees: I've also got some errors about ata resetting this time before this happened, but I don't know if it's related nor if it's the kernel or a upcoming hardware problem
<kees> geser: hrm
<RainCT> >> <NCommander> RainCT, not after the blocker that happened at the last one :-)
<geser> kees: I wonder why only we both see this problem
<NCommander> RainCT, oh, the last Mozilla camp had a landslide block the road, which was a blocker bug on Bugzilla
<RainCT> NCommander: ah, right, I think I saw that bug :)
<kees> geser: no clue.  you run amd64, right?
<RainCT> NCommander: but such things don't happen in Barcelona ;)
<NCommander> You could have a sinkhole form instead
<geser> kees: yes, but I guess some more people run intrepid on amd64 besides us both
<kees> geser: I suspect that might be part of it, but I know a lot of devs run with it.  intel hardware?
<geser> no, amd64 x2
<RainCT> NCommander: bah, firemen.. :P
<NCommander> RainCT, yes, yes I am :-)
<geser> kees: http://paste.ubuntu.com/55415/ that are the ata errors I got this time
<kees> geser: that's upsetting-looking.  :(
<geser> I'll see tomorrow if it also happens with -1 and if not then I blame the kernel
<slangasek> RainCT: mozilla camp europe is in BCN?
 * slangasek yearn
<RainCT> slangasek: yep
<slangasek> RainCT: are you in Barcelona yourself?
<RainCT> slangasek: not in the city, but in the province (20-40 minutes from there)
 * slangasek nods
<RainCT> good night
<cjwatson> slangasek: yikes. My guess is that the seed checkouts on rookery have somehow become screwed; I'm looking into that possibility now
<slangasek> ok, thanks
<cjwatson> hmm, no, not that
<cjwatson> 13527 Oct04 /bin/sh -c for-project ubuntu-server cron.daily; for-project ubuntu-server cron.ports_daily
<cjwatson> slangasek: that's the culprit
<cjwatson> every so often, check_out.py seems to get stuck in a futex, and a CD image build gets stuck as a result
<slangasek> ah
<cjwatson> it then keeps the archive lock held, so nothing else gets to sync
<slangasek> right; kill the britney process, then?
<cjwatson> yep, I've done that now
 * slangasek nods
<slangasek> thanks, now I know to look for that in the future
<cjwatson> this only started happening relatively recently (weeks, maybe small number of months)
<slangasek> that also seems to be an incentive to try getting an updated version of britney in, maybe
<cjwatson> yes
<cjwatson> I'm at a loss to know what could be causing this though
<cjwatson> the usual cause for things getting stuck in futexes, IME, is buggy signal handlers
<cjwatson> but britney doesn't have any signal handlers
<cjwatson> nor does it seem to have locks, semaphores, or mutexes; although I suppose python might
<slangasek> hmm, yes
<radix> mathiaz: hi, I think I'm ready with the branch
<radix> mathiaz: I guess it's getting pretty late, do you want to chat about it tomorrow?
<NCommander> ScottK, can I steal an upload from you?
<cjwatson> slangasek: (I've kicked off a new Ubuntu server build at kirkland's request, and Ubuntu alternate for good measure)
<slangasek> oops, I already did the latter :)
<kirkland> cjwatson: outstanding, thanks
<superm1> NCommander, i was going to upload your libpam-blue thing, but your debdiff didn't apply cleanly.  did you do it backwards? (debdiff new_dsc old_dsc)
<cjwatson> slangasek: huh, I didn't see it in ps
<slangasek> I suspect it had already finished
<cjwatson> slangasek: oh, you must have done it as your own user rather than as cdimage?
<NCommander> superm1, argh, possibly. YOu can grab it from the bluetooth PPA
<cjwatson> ... or that
<NCommander> superm1, speaking of bugs, your bug in Debian on libsmbios should be resolved :-)
<slangasek> aaaaaand amd64 is oversized again
<cjwatson> slangasek: thanks for merging mvo's debian-cd branch, too
<slangasek> n/p
<superm1> NCommander, yeah I got a notification on it.  glad that's finally taken care of
<superm1> thanks for poking around
<NCommander> superm1, I'm working with Debian QA to try and make patches flow in reverse to Debian
<NCommander> superm1, I can respin the debdiff, but its probably easier to grab it from the bluetooth PPA
<superm1> NCommander, i'll grab it from the PPA later tonight then
<doko> the first applets using LiveConnect load, see the openjdk PPA (6b12~pre1-0ubuntu4~ppa5)
<slangasek> ok, what the heck are libbabl and libgegl doing on the CDs post-beta?
<directhex> gimp 2.6?
<slangasek> probably
<directhex> gimp 2.6 uses gegl
<directhex> no idea what babl is
<slangasek> a dep of gegl
<directhex> let me guess. the cd's too big again?
<slangasek> of course
<directhex> sorry. i'll do what i can for jaunty
<ion_> Ah, finally! Awesome. (Gimp on GEGL, that is)
<cjwatson> directhex: CDs, err, kinda need to be fixed for 8.10 ;-)
<directhex> cjwatson, well, yeah, sure, that'd be neat. but my TODO is very specific!
<slangasek> ion_: bloating the CDs post-beta -- not awesome!
<ion_> Heh
<slangasek> well, xscreensaver doesn't belong on here, let's see what happens when we get rid of that...
<lycannyc-work> Hey everyone is there a workaround for Network Manager? or being able to go online?
<kees> which package installs the "Kde" debconf frontend?
<kees> (and how would I figure this out for myself next time?)
<slangasek> kees: "debconf" :)
<slangasek> kees: but it's only used if libqt-perl is installed
<slangasek> s/it's only used/it can only be used/
<kees> slangasek: heh, okay libqt-perl it is.  :)
<kees> slangasek: actually, that seems to be un-true
<kees> I have both libqt-perl installed and debconf
<kees> slangasek: I'm trying (unsuccessfully so far) to reproduce 270626
<slangasek> kees: you have them installed, and dpkg-reconfigure debconf doesn't give you 'Kde' as an option?
<RAOF> Anyone feel like uploading a new gnome-desktop-sharp2 to unbreak libgnomedesktop2.20-cil (bug #280365)?
<ubottu> Launchpad bug 280365 in gnome-desktop-sharp2 "libgnomedesktop2.20-cil missing dependencies, dllmap" [Medium,Confirmed] https://launchpad.net/bugs/280365
<kees> slangasek: it gives the option, but won't use it.  it says it's falling back
<slangasek> huh
<kees> debconf: unable to initialize frontend: Kde
<kees> debconf: (--- No method to call for :)
<kees> debconf: falling back to frontend: Dialog
<slangasek> I've never seen that before
 * kees is magic
<kees> I just assume I'm missing some critical KDE thing (since I'm all Gnomey)
<elmo> kees: because you made debconf smile?
<kees> elmo: hehe
<kees>                 $@=~s/\n.*//s;
<kees> that kills the useful part of the error message!  sheesh
<directhex> RAOF, i'd love to, but unfortunately...
<RAOF> directhex: You're welcome to check the (obviously correct!) debdiff :)
<slangasek> gar, xscreensaver has been a recommends of xscreensaver-gl since August, how the heck was it being kept off the CDs before? :P
<NCommander> slangasek, deep magic :-)
<NCommander> Which reminds me, asac you around?
<slangasek> oh, of course; let me just find the 'deep magic' button on my keyboard
<directhex> RAOF, intrepid has /usr/lib/libgnome-desktop-2.so.7foo ?
<RAOF> directhex: .7foo?
<RAOF> directhex: It certainly has /usr/lib/libgnome-desktop-2.so.7
<directhex> RAOF, yeah, looks like. sure, debdiff seems minimal & simple to me
<RAOF> Bah!  Don't scare me :)
<RAOF> Hm.  I seem to be missing a space in the changelog entry.
<james_w> kees: smells a bit like bug 279020. Unfortunately that doesn't give much more information.
<ubottu> Launchpad bug 279020 in debconf "libpam-ck-connector post-install fails --  No method to call for : QApplication::new" [Undecided,New] https://launchpad.net/bugs/279020
<asac> NCommander: yeah ;)
<kees> james_w: might be fixed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481642
<ubottu> Debian bug 481642 in libqt-perl "PerlQt-based applications refuse to start !" [Grave,Closed]
<NCommander> asac, whats the status on uploading slangasek's firefox fix?
<asac> NCommander: its fix committed
<asac> NCommander: actually there were concerns which we currently discuss
<NCommander> Ok, thats good
<NCommander> asac, http://pastebin.ca/1223194
<asac> #
<asac> +-        default: /* error */
<asac> #
<asac> ++        default: / * error * /
<asac> ??
<slangasek> asac: what are the concerns?
<slangasek> ah, no, this /is/ a new recommend of xscreensaver-gl
 * slangasek fix0rates
#ubuntu-devel 2008-10-09
<asac> slangasek: not much of a problem in the patch itself ... more about the fact that we try to keep firefox-3.1 branch more or less in sync with our firefox-3.0 branch
<slangasek> asac: ok, just checking :)
<asac> slangasek: well. one maybe issue is that its a bashism isnt it?
<slangasek> bryce: mumble, why did xscreensaver 5.07-0ubuntu1 just now appear in the archive with a changelog dated from 28Aug?
<asac> i think its ok to use bash in general, but we tried to prevent that in the past
<slangasek> asac: %% and ## are not bashisms, if that's what you mean
<slangasek> those are posix; the bashism is //
<asac> slangasek: ok. then all fine
<bryce> slangasek: probably because it had been sitting in the sponsor queue for a long long time
<asac> its just that we also have to look what we can do better in the future. all this is a bit hairy. especially considering that we still have patches that hard code what gets written into gconf for the www-browser user preference :)
<slangasek> bryce: :/
<asac> and we would like to have a better $0 ... if possible ;)
<slangasek> and the changelog lacks any mention of the changed Recommends:, sigh
<slangasek> bryce: in fact, this upload clobbered the changes from 5.05-1ubuntu2... checking to see if any other fixes went missing...
<slangasek> nope, just that one
<bryce> slangasek: need me to do anything?
<slangasek> bryce: I've got it, thanks... I'm just my usual grumbly self about regressions introduced in non-obvious ways :)
<bryce> slangasek: ok cool, sorry about not catching that.
<ion_> Heh, the acpi package still uses old-style changelog entries.
<bryce> is there an easy way to check what versions of a package were included in a given alpha release?
<StevenK> bryce: The .manifest
<bryce> ah thanks
<bryce> hmm, where can I find .manifest's for alpha3 and alpha4? not spotting them immediately on cdimage.ubuntu.com
<cjwatson> or .list if you're looking at alternate/server installs
<cjwatson> they aren't published anywhere unfortunately
<bryce> hrm
<bryce> I've got a reporter who says an issue did not exist in alpha 3, and started appearing with alpha 4, so to upstream the bug I'd like to translate that into the appropriate package version numbers
<cjwatson> what package do you care about?
<bryce> xserver-xorg-video-ati (and xorg-xserver)
<cjwatson> we have an archive of alpha-4 (but for some reason not alpha-3) on antimony
<bryce> (hmm, maybe I should start snapshotting version numbers of X packages)
<cjwatson> xorg-xserver> YM xserver-xorg? or xserver-xorg-core?
<bryce> xserver-xorg-core
<cjwatson> alpha-4 had xserver-xorg-video-ati 1:6.9.0+git20080802.1f3eee36-1ubuntu1, xserver-xorg-core 2:1.4.99.906-1ubuntu3
<Hobbsee> bryce: you can check dates of uploads corresponding to the release schedule too, if you wanted to.
<cjwatson> yeah, that's probably the easiest approach
<Hobbsee> (assumign it didn't get updated terribly often)
<bryce> excellent thanks.  Yeah from the changelog it looks like we had perhaps 6.9.0-1 in alpha3
<bryce> Hobbsee: yeah that's what I've usually done, but it's a touch ambiguous in this case
<Hobbsee> bryce: darn :(
<bryce> -ati was updated pretty frequently both by us and debian, and we sync'd from them for much of this cycle so the changelog dates don't necessarily indicate when the package was present in our archives
<bryce> but I think this info is sufficient, thanks
<cjwatson> look at the publication dates in LP
<bryce> (this is for bug #264462 btw)
<ubottu> Launchpad bug 264462 in xserver-xorg-video-ati "Radeon Driver fails to load on 2 Sep daily [ATI HD3870]" [High,Triaged] https://launchpad.net/bugs/264462
<cjwatson> https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati
<bryce> ah good point
<cjwatson> you can hover over the date to get an exact date and time
<cjwatson> confusingly when it says "superseded" that gives you the upload time of the *next* package in chronological order in that series
<cjwatson> i.e. it gives you current publication state plus the time when it changed to that state
<bryce> hum, interesting
<ScottK> NCommander: Sure thing.
<ScottK> NCommander: Which?
<NCommander> ScottK, we decided not to fix in intrepid (which I don't get but yeah ...)
<ScottK> NCommander: OK.  Wanna update amule?
<NCommander> New upstream?
<ScottK> NCommander: Yeah.
<NCommander> You writing the FFe?
<ScottK> No, you are.
<NCommander> I am?
<ScottK> I'll give it a first ack though.  See Bug 260471
<ubottu> Launchpad bug 260471 in amule "[intrepid] update aMule to version 2.2.2" [Medium,In progress] https://launchpad.net/bugs/260471
<ScottK> Part of what 'update' entails.  I just don't have the time.
<NCommander> Does Launchpad accept .bz2 original tarballs yet?
<NCommander> ScottK, I think we can simply sync from experimental
<ScottK> NCommander: I'm fine with whatever works.
<Hobbsee> defien 'works' here? :P
<ScottK> Please steal it from me.
<NCommander> ScottK, can we straight sync from Debian?
<ScottK> Meaning people don't wine a motu-release about amule being old again.
<ScottK> NCommander: Dunno.  You tell me.
<NCommander> from experimental?
<NCommander> I know we can from sid
<Hobbsee> yes, you can.
<ScottK> It's technically possible.
<NCommander> But I never requested from experimental
<Hobbsee> of course, you can sync it yourself, too.
 * NCommander is seeing if the Ubuntu diverance is still needed
<NCommander> Hobbsee, some of us aren't MOTU
<Hobbsee> NCommander: bribes accepted.
 * ScottK kicks NCommander in the appropriate place to get his application in.
<NCommander> ScottK, I was told I won't pass the vote until I've been in a full cycle
<NCommander> (two 0s, and a -1 are likely)
<NCommander> That's DIF jaunty
<ScottK> NCommander: Is you have enough sponsors speaking for you, my predication is it won't matter.
<Hobbsee> NCommander: if you're unlucky, someone (*glares at Mithrandir) will put you forward anyway.
<NCommander> Hobbsee, I can be sponsored for MOTUship without doing anything?
 * NCommander got UDS sponsorship that way
<TheMuso> NCommander: If your work and your demonstrated abilities are exceptional.
<Hobbsee> NCommander: sure.  I mean, you have to talk about it afterwards, but you don't have to be teh first one to send mail applying for it.
<Hobbsee> NCommander: oh, you're coming?  excellent.
<Hobbsee> NCommander: how normal that is, i'm not sure.
<Hobbsee> NCommander: oh, and people might just stop sponsoring your stuff, and tell you to apply instead :P
<NCommander> Hobbsee, then they are only shooting themselves in the foot :-)
 * NCommander is coding in x86 ASM
<NCommander> Hobbsee, I'm writing my application :-)
<emet> NCommander, AT&T or Intel syntax?
<NCommander> AT&T
<NCommander> :-)
<RAOF> NCommander: I hope that's real mode ASM.  None of this flat-memory-model laziness!
<NCommander> I need it to compile in GAS
<NCommander> RAOF, thats my core dev application
<NCommander> This one will simply be an ELF application
<NCommander> Hrm
<NCommander> Or
<NCommander> I could write a amd64 ASM app
<emet> gas can compile Intel syntax too
<NCommander> Oooh
<NCommander> That must be a relatively new feature
<RAOF> You know what you really want to do?  Raw CIL!
<NCommander> Ew
<emet> NCommander, what are you doing in assembly may I ask? I'm learning x86 assembly right now, so maybe can share code or something
<NCommander> emet, I'm writing my MOTU application
<NCommander> :-)
<emet> in assembly? O_o
<TheMuso> heh
<NCommander> Yes
<NCommander> In assembly
 * Hobbsee wonders if MOTU applications are automatically rejected if they are written in brainfuck.
<NCommander> Actually
<NCommander> That idea did cross my path
<NCommander> But x86 is more like 32-bit brainfuck
<emet> no if you do anything useful in brainfuck that deserves a medal
<NCommander> mcasadevall@blacksteel:~/motu-application$ gcc test.s -m32
<NCommander> /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libgcc.a when searching for -lgcc
<NCommander> Yah know
<NCommander> Screw it
<NCommander> brainfuck it is
 * NCommander writes an application to change ASCII strings to brainfuck
<emet> as -o test test.s
<NCommander> emet, no, I'm on x86_64
<emet> oh okay
<NCommander> I mean
<NCommander> I could write it in x86_asm
<NCommander> er
<RAOF> NCommander: Got gcc-multilib installed?
<NCommander> x86_64
<Hobbsee> emet: i recently saw an application that wrote out the beer song.
<Hobbsee> and a few other interesting ones.
<emet> that's cool
<NCommander> Is there a brainfuck compiler in Ubuntu?
 * NCommander notes that would be a preq
<emet> yes
<NCommander> Hrm
<NCommander> x86 asm or brainfuck
<NCommander> hrm ...
<emet> beef
<emet> !info beef
<emet> :o
<ubottu> beef (source: beef): flexible Brainfuck interpreter. In component universe, is extra. Version 0.0.6-1 (hardy), package size 7 kB, installed size 60 kB
<Hobbsee> NCommander: or both :P
<Hobbsee> NCommander: half in one, half in teh other?
<NCommander> We really have a package with fuck in its description in Ubuntu?
<emet> !info bitchx
<ubottu> Package bitchx does not exist in hardy
<emet> :o
<ScottK> That one was removed due to it's  consistent security history, IIRC
<stdin> NCommander: it's a language
<stdin> well, kinda
<emet> notice the size too
<emgent> http://www.reghardware.co.uk/2008/10/08/asus_eee_box_virus/
<emgent> nice.
<NCommander> Ok, I do remember x86 ASM
 * NCommander just managed to write hello world 
<ion_> emgent: Heh
<jturek> hey guys anybody get "wireless event too big" messages in their virtual console running intrepid?
<jturek> bug 267063 was filed about it, and i put in my dmesg output in that bug as well
<ubottu> Launchpad bug 267063 in linux "iwl4965 - wireless event too big (366) and 2.6.27-2 regression" [Medium,Triaged] https://launchpad.net/bugs/267063
<jturek> it still exists in 2.6.27-6
<jturek> is there a console based program to view and edit bugs?  or is it best to use Lynx/Links
<ScottK> Not for Ubuntu.
<ScottK> Launchpad works pretty well with no css in text based browsers, however.
<jturek> ScottK - Thanks
<jturek> Scott what text browser is maintained and renders sites the best?  Links/Lynx/Elinks
<jturek> ?
<TheMuso> jturek: IMO elinks is the best.
<lukehasnoname> cjwatson: Bug #96435 , I added a comment for you to look at, as maintainer of the bug. I don't know if you get emails at every post.
<ubottu> Launchpad bug 96435 in oem-config "[apport] oem-config-dm crashed with XStartupError in run()" [Medium,Confirmed] https://launchpad.net/bugs/96435
<pitti> Good morning
<StevenK> Morning pitti
<pitti> ScottK: private bug dups>neither really; I still think we shouldn't make crash bugs public by default
<yao_ziyuan> i wonder,
<yao_ziyuan> when setting up flashplugin-nonfree,
<yao_ziyuan> it downloads http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_install_linux_091508.tar.gz
<yao_ziyuan> does it then check some fingerprint?
<yao_ziyuan> because i'm in china,
<yao_ziyuan> and i'm concerned if this download can be altered in the middle by the government
<Treenaks> it checks the md5sum
<yao_ziyuan> Treenaks: what is the source of the md5sum?
<Treenaks> yao_ziyuan: the package
<Treenaks> yao_ziyuan: it checks the md5sum of the .tar.gz first, then of the libflashplayer.so (plugin) file
<Treenaks> and there are 2 md5sums in the postinst in the package
<yao_ziyuan> but does it check the package's fingerprint before checking the .tar.gz?
<yao_ziyuan> the package itself's md5sum
<yao_ziyuan> i think so.
<TheMuso> yao_ziyuan: apt/dpkg checks the md5sum before unpacking the package.
<Treenaks> yao_ziyuan: yes, apt will warn you if the package's GPG signature doesn't match (and won't install the package)
<yao_ziyuan> good
<yao_ziyuan> i just ctrl+break and used sudo torify apt-get install -f to make sure
<Treenaks> yao_ziyuan: it's very hard to get apt to install packages that don't match the md5sum/sha1sum from the (gpg-signed) packages file
<wgrant> TheMuso: dpkg won't check a sig.
<wgrant> apt will.
<TheMuso> wgrant: Right, wasn't quite sure where in the stack it is checked, but that makes sense.
<wgrant> Unless you say yes to the 'COULD NOT BE AUTHENTICATED' warning.
<wgrant> In which case you are strange.
<Treenaks> wgrant: selectively paranoid :)
<yao_ziyuan> i think displaying a line "md5sum of flashplayer....tar.gz verified" can calm users like me
<wgrant> TheMuso: dpkg does check the md5sums, but the md5sums in the .deb aren't signed.
<TheMuso> wgrant: yeah true.
<Treenaks> wgrant: but if the hash of a .deb doesn't match the hash in the Packages file, apt will complain even harder than 'could not be authenticated', and just refuse to install
<Treenaks> afaik
<wgrant> Treenaks: Oh, true.
<wgrant> Treenaks: It'll give "Hash sum mismatch"
<wgrant> Or something similar.
<wgrant> But one can easily enough fake unsigned Packages files.
<Treenaks> just deny access to the signature file
<Treenaks> I think?
<wgrant> Treenaks: Quite possibly.
<yao_ziyuan> i pay close attention to apps who download executables from their own websites
<yao_ziyuan> like sun java's autoupdate, firefox's check for browser update
<wgrant> Those apps should generally be shot unless they're apt.
<yao_ziyuan> adobe reader's auto update
<Treenaks> yao_ziyuan: Ubuntu's firefox doesn't do that check, I think
<yao_ziyuan> i know
<wgrant> Treenaks: It does for extensions.
<yao_ziyuan> extensions are https
<yao_ziyuan> if an extension doesn't use a https update link, firefox will disable updating it
<wgrant> Ah, good.
<Treenaks> yao_ziyuan: Debian/Ubuntu people tend to be very paranoid about downloaded software as well
<StevenK> pitti: I get a timeout error trying to give back linux-restricted-modules-lpia, can you wave buildd.py at it?
<pitti> StevenK: done, but it's in depwait; nothing to kick here
<StevenK> pitti: Yeah, it did itself, thanks.
<NCommander> Hey StevenK
<seb128> pitti: hey
<pitti> bonjour seb128
<seb128> pitti: the retracer is chocking on bug #279171
<ubottu> Bug 279171 on http://launchpad.net/bugs/279171 is private
<seb128> pitti: rather the duplicate checking doesn't like it, can't download because needs > 1 value to unpack error
<seb128> pitti: is that a known bug?
<pitti> seb128: ah, it's because the original reporter changed the description to have stuff below the apport report, fixing
<seb128> pitti: thanks!
<pitti> seb128: description updated, should work now
<seb128> pitti: "Report is a duplicate of #277616 (fixed in version 0.5~beta1-0ubuntu3)"
<seb128> pitti: danke schÃ¶n
<seb128> siretart: hey, do you tag bugs for retracing sometime?
<seb128> siretart: the retracers are just set up for hardy and intrepid, so no need to tag crash sent before that, launchpad doesn't show who tagged bugs but I came accross an old bug you triaged recently why was tagged for retracing so in case you added the tag
<persia> seb128, Is that a disk space issue, or just convenience?  I'd think ideally the retracers would cover all supported releases + the development release.
<seb128> persia: the retracer are lot of maintainance work, and eat some gigabytes of ram and load the porter box a lot already
<seb128> persia: I'm limited to the intrepid instance and stopping those every now and then to run the hardy ones
<seb128> because hardy and intrepid on i386 and amd64 makes the box explode under the load
<siretart> seb128: oh, I see
<siretart> seb128: what shall I do with failed retraces then?
<seb128> it's not worth the trouble to try to set retracers for older version right now seeing how many bugs we can on before hardy versions
<persia> seb128, Completely understood.  Thanks for the explanation.
<seb128> siretart: clean those manually
<seb128> I'm wondering what to do after intrepid though
<seb128> we will need to keep hardy, intrepid retracers
<persia> And jaunty.  Could more hardware be requested?
<seb128> siretart: I usually ask if the bug still happens on the current version and to attach an updated stacktrace or use apport to send a new report if that's the case
<seb128> persia: right and jaunty, I was listing the non current versions to have retraced
<seb128> persia: not sure if hardware is the reply there, ideally those should be moved to a non porter box and we reworked and optimized
<seb128> persia: we are spending way too much time to fix upgrade issues, fighting python-launchpad-bugs which make those crash, etc, it would be nice to have something better
<seb128> but that would require somebody have some free cycles to spend on those
<seb128> cycles not in sense of ubuntu cycles, just some days should be enough ;-)
<persia> How do the retracers work?  Is there source people can fiddle with?
<pitti> persia: we are also limited by the availability of dbgsym packages
<persia> pitti, That's an ongoing bug.  Haven't we generated -dbgsym for most packages yet?
<pitti> persia: we did, but we still don't have them for e. g. gutsy
<siretart> seb128: with 'cleaning' you mean 'removing the core dump, unmark the bug as private and ask submitter for a manual retrace', right?
<persia> pitti, Sure.  I'm more thinking about the future than the past.
<seb128> siretart: right
<seb128> siretart: <seb128> siretart: I usually ask if the bug still happens on the current version and to attach an updated stacktrace or use apport to send a new report if that's the case
<siretart> seb128: okay. I've already done so for some bugs in the past. will keep that up for future ones. thanks for notifying me
<seb128> siretart: you're welcome ;-)
<frafu> Hello seb128. Today, the update of ubuntu intrepid shipped a new version of gdm. Could you please tell me whether there was a with the patch supplied in bug#264834, or was there any other problem?
<seb128> frafu: hi, looking
<seb128> bug #264834
<ubottu> Launchpad bug 264834 in gdm "RFE: Add gesture to start onboard and mousetweaks at login (patch supplied)" [Undecided,New] https://launchpad.net/bugs/264834
<seb128> frafu: oh, there is just too many bugs open to keep track of everything, the sponsor team should be subscribed if there is something to sponsor
<frafu> ok; I was not aware of it; I just subscribed ubuntu-main-sponsors to it. Correct?
<seb128> frafu: right
<frafu> thanks
<seb128> you're welcome
<seb128> the patch will likely be uploaded today
<frafu> good news
<asac> Riddell: could you look if there are more changes for knetworkmanager?  there appears to be still a bunch of complains in 259278
<asac> Riddell: also ... have you tried the kde 4 nm? i think wstephenson said to me that he properly migrated the dbus api to the latest there
<asac> while hschaa only updated a few things he thought were necessary to get the minimum features working again
<Riddell> there's no new changes in knetworkmanager
<Riddell> kde 4 nm is still at a very early stage
<asac> ok
<asac> Riddell: is knetworkmanager used at all in kubuntu by default? reason is that i hear quite small amount of noise because of all these knetworkmanager issues
<asac> could also be that most works now and that the noise left is because they have other issues (and just happen to use knetworkmanager)
<mdz> does anyone happen to know how the LCD backlight brightness can be adjusted from userspace on Lenovo thinkpads?
<mdz> I'm trying to work out what's causing bug 280646
<ubottu> Launchpad bug 280646 in linux "ACPI brightness events no longer work on ThinkPad T61" [Undecided,New] https://launchpad.net/bugs/280646
 * Hobbsee presumes the answer is not function+up?
<Hobbsee> or the applet?
<mdz> Hobbsee: the bug is that the hotkeys aren't working, so I'm looking for how it's supposed to work behind the scenes
<Riddell> asac: yes it's the default, it works for me, what's the noise?
<mdz> e.g. what command can I run to manually set the brightness
<Hobbsee> mdz: ahh.  No idea, then :)
<mdz> my research so far seems to indicate that it isn't handled in hardware on this model, and something in userspace needs to handle the ACPI event and tell it what to do
<mdz> the applet doesn't work either, I guess I can check what that's trying to do
<TheMuso> mdz: Is there anything in sysfs that allows you to tweak it by echoing values to something?
<Hobbsee> mdz: no idea on whether it'll work on that particular machine, but editing /proc/acpi/video/VGA/LCD/brightness is supposed to do it.
<Hobbsee> ie, sudo echo ân 100 > /proc/acpi/video/VGA/LCD/brightness for full brightness.
<TheMuso> Hobbsee: I thought all that stuff was in sysfs now.
<mdz> hobbsee: was just looking at that, will try
<Hobbsee> TheMuso: may well be. *shrug*.  I already said above i had no idea, so now i'm back to guess work :)
<mdz> hobbsee: yep, that works
<asac> Riddell: mostly people claiming that it doesnt work in the bug i posted
<Hobbsee> mdz: \o/
<mdz> hobbsee: so the next question becomes, what maze of scripts is supposed to twiddle that value and where is it going wrong?
<Hobbsee> mdz: now that one, i really have no idea about...
<TheMuso> I guess it depends on what the fdi files refer to, but stuff like that is in /usr/lib/hal afaiu.
<cody-somerville> mdz, What graphics chipset does your T61 have?
<mdz> cody-somerville: intel
<mdz> 945GM
<mdz> sorry, GM965
<mdz> all of my hardware info is on the bug
<Hobbsee> mdz: starting point may well be /etc/acpi/thinkpad-brightness-up.sh, but that could be a red herring too.
<mdz> hobbsee: that seems to be for ibm-acpi, which is for older/IBM thinkpads
<mdz> lenovo ones explicitly don't use those, and use the standard acpi events instead
<Hobbsee> ah
<Hobbsee> well, you can certainly see if the event is getting generated...
<Hobbsee> oh, which you already have.
<mdz> now I wonder why I have two VID devices
<mdz> one of which works and one of which doesn't
<Hobbsee> one relates to actual hardware, and the other doesn't?  The scripts are trying to use the one not pointed to real HW?  *shrug*
<mdz> hobbsee: one is for the onboard graphics, one for the mini-pcie I think
<mdz> I'm going to reboot and see if I still have two on an older kernel
<Hobbsee> ahhh
 * Hobbsee wonders why a mini-pcie slot counts as a VID device.
<mdz> I am trying to figure this out as I go, everything I know is in the bug
<persia> Hobbsee, Perhaps there's an e.g. TV out card in the miniPCIe slot?
<Hobbsee> persia: possibly.
<cody-somerville> what does m mean in /boot/config-<version>?
<StevenK> Module
<cody-somerville> So CONFIG_ACPI_VIDEO=m in there means that option is enabled?
<persia> cody-somerville, It means a module is built for it, which may or may not be inserted at runtime.
<persia> cody-somerville, lsmod can help determine what is actually inserted at any given time.
<cody-somerville> So from http://launchpadlibrarian.net/18362442/ProcModules.txt it looks like CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO aren't in there?
<persia> cody-somerville, From the lack of response, I suspect none of us has a handy CONFIG_* -> module name mapping.  Maybe?
<cjwatson> you need to look in the relevant Makefile for that
<mdz> starting to look like a gnome-power-manager issue
<cody-somerville> mdz, Does adding http://pastebin.ubuntu.com/55573/ to /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi fix your problem?
<ogra> isnt that gone upstream already ?
<mdz> cody-somerville: no change
<mdz> I just noticed this:
<mdz>     <match key="linux.sysfs_path" contains="/sys/devices/virtual/backlight/acpi_video">
<mdz>       <merge key="laptop_panel.brightness_in_hardware" type="bool">false</merge>
<mdz>     </match>
<mdz> but I have /sys/devices/virtual/backlight/acpi_video[01], not acpi_video
<mdz> toggling that doesn't fix it though
<mdz>   laptop_panel.brightness_in_hardware = true  (bool)
<mdz> cody-somerville: I'm already getting this by default:
<mdz>   laptop_panel.brightness_in_hardware = false  (bool)
<mdz> which I believe is correct
<mdz> cody-somerville: what do you see in g-p-m --verbose when you use your brightness keys?
<mdz> cody-somerville: and lshal -m?
<mdz> I get nothing in either
<cody-somerville> mdz, Nothing is written.
<mdz> cody-somerville: but it works?
<cody-somerville> On my laptop on Hardy, yes.
<ogra> mdz,  <match key="linux.sysfs_path" contains="/sys/devices/virtual/backlight/acpi_video"> matches all that contains that path, so also acpi_video[01]
<mdz> this used to work for me, too, and I can't work out where it's broken
<ogra> hardy used only half of hal for thinkpads ... the other half was hotkeysetup
<mdz> ogra: ah, of course
<mdz> cody-somerville: does sudo acpi_fakekey 224 change your brightness?
<cody-somerville> Not on my Aspire, no.
<mdz> https://bugs.edge.launchpad.net/ubuntu/+source/hal/+bug/267682/comments/86
<ubottu> Launchpad bug 267682 in hal "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Fix released]
<cody-somerville> mdz, http://www.nabble.com/T61-Brightness-keys-with-2.6.26-not-working-(NVIDIA)-td18577619.html seems to indicate that enabling CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO results in both brightness keys create proper acpi / key events AND change the brightness in both X and console. I assume you've already verified that those options are enabled in your kernel build?
<mdz> cody-somerville: they are; that's just video.ko which is loaded and working
<mdz> so that person's problem seems to have been a simpler one (no acpi video support)
<cody-somerville> mdz, `echo down > /proc/acpi/ibm/brightness` decreases your screen brightness, right?
<mdz> cody-somerville: no, I don't have that file.  that's for older thinkpads where brightness is handled by firmware
<mdz> I have this:
<mdz> [   20.635444] thinkpad_acpi: Lenovo BIOS switched to ACPI backlight control mode
<mdz> [   20.635446] thinkpad_acpi: standard ACPI backlight interface available, not loading native one...
<mdz> cody-somerville: and writing 0-100 to /proc/acpi/video/VID1/LCD0/brightness changes the brightness
<mdz> cody-somerville: the brightness applet does work
<mdz> pitti: this is starting to look like a hal issue; do you have any ideas? (bug 280646)
<ubottu> Launchpad bug 280646 in hal "ACPI brightness events no longer work on ThinkPad T61" [Undecided,New] https://launchpad.net/bugs/280646
<ogra> smells like hal or gpm wasnt properly prted here ... note that it doesnt use /proc for anything anymore so i'd suspect the proper sysfs translation is missing
<ogra> *ported
<cody-somerville> mdz, is http://www.klabs.be/~fpiat/linux/debian/Etch_on_Thinkpad_T61.html referring to the old setup or new setup?
<ogra> etch is as old as edgy
<cody-somerville> mdz, That page reports the issue is fixed in Lenny (and the Lenny page says the brightness stuff just works)
<ogra> lenny is somehow like hardy with some intrepid bits, so that might be intersting, though lenny still makes full use of acpi-support etc
<mdz> cody-somerville: they're running an older BIOS on that page
<mdz> by about 9 months.  could be that theirs works differently
 * ogra thinks its hard to compare debian and ubuntu wrt power management
<ogra> there must be a sysfs path equivalent to /proc/acpi/video/VID1/LCD0/brightness
<ogra> that *should* be what gpm/hal uses
<kagou> tkamppeter, is there a way to auto-detect shared network printer (here, a printer server box, sharing 2 printers by lpd) ?
<mdz> ogra: isn't that what /sys/devices/virtual/backlight/acpi_video is?
<ogra> no idea, i have no IBM hw here, does it do what you expect on console ?
<mdz>  /actual_brightness there gets changed when I press the keys
<mdz> but the display brightness doesn't change
<cody-somerville> mdz, did you say that you have more than one laptop_panel device?
<mdz> cody-somerville: yes
<ogra> can you echo any values or "up/down" into any of the sub files to make it work ?
<ogra> like you cn do with /proc/acpi/video/VID1/LCD0/brightness
<ogra> iirc the change that gpm and hal completely ignore /proc only came with intrepid
<cody-somerville> mdz, Will you try blacklisting video in /etc/modprobe.d/blacklist and rebooting and seeing if that fixes the two laptop_panel device issue?
<ogra> so hardy might have had a mishmash reading from /sys and writing to /proc
<mdz> ogra: yes, acpi_video1
<ogra> hm, if you change the above mentioned .fdi to match acpi_video1 instead of acpi_video, does it work ?
<mdz> ogra: (acpi_video0/brightness does nothing)
<mdz> ogra: as you pointed out, that would be a no-op
<ogra> probably the "contains" stuff isnt working right
<ogra> though i wouldnt understand why unless hal's matching is broken
<mdz> ogra: it's working fine, that value is set to false in lshal
<mdz>   laptop_panel.brightness_in_hardware = false  (bool)
<ogra> ah, k
<ogra> but apparetnly gpm/hal isnt using acpi_video1 as its target for value writing ...
<cody-somerville> blacklisting video should leave you with only one
 * ogra has to attend the mobile meeting now ... will be a bit distracted
<ogra> http://www.mail-archive.com/ibm-acpi-devel@lists.sourceforge.net/msg01097.html is a thread on ibm-acpi-devel discussing that
<ogra> according to that thread its a kernel issue
<pitti> mdz: looking
<pitti> mdz: when did that stop working, just a few days ago, or together with -evdev?
<pitti> mvo: is bug 19021 on track for the release?
<ubottu> Launchpad bug 19021 in synaptic "Should run dpkg --configure -a automatically" [Medium,Triaged] https://launchpad.net/bugs/19021
<pitti> mvo: (you didn't mention it in your milestone list)
<pitti> mvo: oh, not RC, nevermind
<pitti> ogra: please upload the hardy SRU fixes for bug 258110 to intrepid ASAP
<ubottu> Launchpad bug 258110 in cmpc "Camera application cannot record video" [Critical,In progress] https://launchpad.net/bugs/258110
<pitti> mvo: bug 257947 is fix released upstream, does it mean it's fixed by the load of compiz packages you just uploaded? (if so, then the bug wasn't auto-closed for some reason)
<ubottu> Launchpad bug 257947 in firefox-3.0 "After install of 8.10 alpha 4 Firefox opens with tool bar under top panel." [Undecided,Confirmed] https://launchpad.net/bugs/257947
<ogra> pitti, they are in intrepid ... they are upstream
<pitti> ogra: oh, can you please close the intrepid tasks then and say so in the bug? thanks
<ogra> will do
<ogra> the fixes are both backports from newer upstream :)
<mvo> pitti: dpkg --configure -a is not cirticial, I think it should be postponed
<mvo> pitti: the compiz fix must be imported as a patch (its small) I will do that soonish
<pitti> mvo: ah, it was post 0.7.8?
<mvo> pitti: yes
<pitti> mvo: likely to land this week?
<mvo> pitti: yes
 * pitti hugs mvo, thansk
<mvo> chhers
<kagou> hi pitti :) do you know if our cups version support the  MAC Rendezvous ?
<pitti> kagou: you mean bonjour? yes, it does for discovery
<pitti> mvo: bug 278112 seems harder, not even reproducible by you?
<ubottu> Launchpad bug 278112 in compiz "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112
<kagou> pitti, indeed :) Thanks ! So i will check that more carefully
 * ogra can reproduce
<ogra> but has no cue where to look deeper
<ogra> *clue
<pitti> kagou: you have to enable it in BrowseProtocols
<kagou> mmmh ok pitti , it's de-activated
<mvo> pitti: yes, the screensaver one is more difficult, I was able to reproduce it on a test-system but for me 0.7.8 fixed it, I will try on a different machine (with a different driver)
<pitti> ogra: does 0.7.8 fix it for you as well?
<ogra> pitti, i havent upgraded the samsung yet, lets see
<tkamppeter> kagou: "BrowseProtocols cups dnssd" in cupsd.conf makes CUPS broadcasting with both IPP (for Linux/unix clients) and DNS-SD/Bonjour (for Mac OS X clients).
<ogra> geeez !
 * ogra sees scrollkeeper going away
<ogra> \o/
<kagou> tkamppeter, the default protocol (if not specified) is cups ?
<kagou> tkamppeter, seen in http://www.cups.org/documentation.php/ref-cupsd-conf.html#BrowseRemoteProtocols :
<kagou> The default protocol is CUPS dnssd for BrowseLocalProtocols and  for BrowseRemoteProtocols
<tkamppeter> kagou, yes. This is CUPS' standard IPP broadcasting.
<kagou> tkamppeter, ok. Do I need to had additional package for dnssd support on cups server ?
<kagou> tkamppeter, ok. Do I need to add additional package for dnssd support on cups server ?
<jmichel> I am creating an Ubuntu package with dpkg-buildpackage... it seems that after I called dpkg-buildpackage once and get an error, I cannot modify any files afterwards
<tkamppeter> kagou, AFAIK not
<cjwatson> jmichel: that's not normal. what happens when you try to modify those files?
<jmichel> Actially, I can modify files but changes are not taken into account
<cjwatson> jmichel: does the package use a patch system? look in debian/patches/
<kagou> thanks tkamppeter, so I have a problem here. I will investigate it before report it
<jmichel> cjwatson: there is no debian/patches
<jmichel> cjwatson: It seems I need to change version in configure.ac to get my changes to be considered
<jmichel> I thought dpkg-builpackage was keeping a version of my files somewhere but I cannot find where?
<jmichel> Lets say I build a software "app-4.0" with dpkg-builpackage in a tmp folder, then I erase everything from the tmp folder, then do some changes in the Makefile.am and recopy my new version of "app-4.0"... dpkg-builpackage will still use the old Makefile.ac that is not even in my project anymore!?!
<jmichel> sorry Makefile.am
<jmichel> But from where does that old file comes from?
<jmichel> Then if I just rename my folder "app-4.0.1" and change version in configure.ac to 4.0.1 it will instantly start to use my changes
<kagou> tkamppeter, so, after installation of bonjour in a windows box to verify that it can see bjour shared printers I : 1/ added "BrowseProtocols cups dnssd" in /etc/cups/cupsd.conf 2/ restart cups
<kagou> but s-c-p do not show bonjour printers, and I don't see usefull informations in cups access/error logs
<jmichel> Could someone just give me a hint about what is this feature and if I can delete the file "cache ?" create by dpkg-builpackage
<kagou> any ideas to investigate this problem ?
<kagou> tkamppeter, just for information : s-c-p is the default printer tool in mandriva 2009 :)
<tkamppeter> kagou, great to hear that.
<tkamppeter> kagou for s-c-p to show Bonjour printers in the New Printer wizard one of the backends needs to detect them. The backend for that is /usr/lib/cups/backend/dnssd, and this backend needs avahi-utils to work.
<kagou> ok tkamppeter. avahi-utils is installed. But using it, "avahi-browse -a" do not report bonjour printers
<kagou> so cups seems to be innocent ^^
<cjwatson> jmichel: dpkg-buildpackage doesn't keep any kind of cache, believe me. I've no idea what your problem is
<cjwatson> jmichel: perhaps you could post a tarball of your working directory and instructions on how to reproduce the problem
<kagou> thanks pitti and tkamppeter. I'v reported the bug on avahi #280754
<kagou> https://bugs.edge.launchpad.net/ubuntu/+source/avahi/+bug/280754
<ubottu> Launchpad bug 280754 in avahi "Can't find bonjour printers" [Undecided,New]
<jmichel> cjwatson: I think my solution was only to delete the .dsc file and the tar.gz file from the upper folder prior to restart the build
<cjwatson> jmichel: still doesn't make sense though, unless you're invoking dpkg-buildpackage in a bizarre way or the package is doing something crazy
<seb128> kagou: ps ax | grep avahi?
<cjwatson> to build a binary package from a source tree, you would normally use 'dpkg-buildpackage -b -rfakeroot' (or just 'debuild -b')
<kagou> seb128, avahi-daemon is running
<seb128> kagou: the exact line?
<seb128> kagou: that's the status which interests me there
<kagou> avahi-daemon: running [satori.local]
<seb128> ok, running, so that's a different bug that the one I was having
<jmichel> cjwatson: I was not using -b so does it try to build source + binary ?
<elmo> can we make -rfakeroot the default of dpkg-buildpackage when run as a normal user?
<cjwatson> jmichel: yes, although even then it wouldn't unpack the old source package again
<wgrant> elmo: It is.
<wgrant> At least in Intrepid.
<wgrant> Maybe in Hardy too. I forget.
<kagou_> seb128, avahi     7434  0.0  0.0   2888  1500 ?        Ss   15:45   0:00 avahi-daemon: running [satori.local]
<kagou_> avahi     7435  0.0  0.0   2888   496 ?        Ss   15:45   0:00 avahi-daemon: chroot helper
<cjwatson> wgrant: so it is - dpkg 1.14.7, so >=hardy
 * cjwatson has some very old habits
<seb128> kagou_: <seb128> ok, running, so that's a different bug that the one I was having
<elmo> yay, so it is
<wgrant> cjwatson: I still do it too.
<wgrant> But whenever anybody brings it up in channel I remember that it's the default now.
<wgrant> And remind myself not to forget it next time.
<wgrant> But I inevitably do.
<elmo> ok, how about making dpkg-dev depend/recommend on fakeroot? :-P
<cjwatson> I'm currently trying to get over explicitly specifying compression (-z or -j) when uncompressing files with tar
<wgrant> Recommend sounds good.
<jmichel> cjwatson: thanks for your help... I will try to reproduce the problem and post something more specific...
<wgrant> cjwatson: When did that change!?
<ogra> wgrant, while i see you here, to swtich off synaptics you just need to unset input.x11_driver with hal-set-property for the udi of the touchpad
<persia> -z -j is optional now?
<elmo> yes
<wgrant> ogra: Will that work at runtime?
<ogra> wgrant, not sure why you say it doesnt work
<ogra> sure
<wgrant> ogra: Also, that's not quite what syndaemon does.
<ogra> its hal :)
<cjwatson> wgrant: tar 1.15, apparently - 2004
 * wgrant rereads the thread.
<cjwatson> * Compressed archives are recognised automatically, it is no longer
<cjwatson> necessary to specify -Z, -z, or -j options to read them.  Thus, you can
<cjwatson> now run `tar tf archive.tar.gz'.
<wgrant> cjwatson: Arrrrgh.
<ogra> wgrant, i'm not sure though that it will work properly for re-enabling without setting all options again manually, but essentially thats what i would do
<ogra> and you could just read the .fdi to re-enable the options
<elmo> reported dpkg-dev/fakeroot as #280758
<wgrant> ogra: I suspect it's somewhat nicer to use the XInput property, rather than removing the device...
<ogra> requires some coding though
<wgrant> elmo: I suspect it should recommend, yes.
<wgrant> ogra: syndaemon needs to do it whenever typing occurs - vanishing the device sounds expensive and overkill.
<ogra> wgrant, well, hal is used for everything nowadays, why go back to old stuff ?
<wgrant> ogra: XInput properties were just backported to Xserver 1.5... they're brand new.
<ogra> wgrant, i thought more about a checkbox in the touchpad props to disable it completely
<wgrant> ogra: There's one there now.
<ogra> ah, yeah
<wgrant> I know, because I wrote that bit of code and am fixing it for the new property API right now.
 * ogra didnt look at  that capplet for ages
<wgrant> Heh.
<ogra> but still i dont see a reason to run a separate daemon if you have hal
<jcristau> i don't think fiddling with hal would work at runtime anyway
<ogra> jcristau, it works fine for touchscreen calibration
<wgrant> jcristau: Perhaps unsetting the driver would work, but I doubt setting the other properties would.
<wgrant> Hmmm.
<ogra> where you have to set the calibrate property on and off
<ogra> wgrant, sure, you can just iterate over the options with hal-set-property
<wgrant> ogra: Does the driver really respect that?
<ogra> afaik thats what is done anyway on hal startup, should work at runtime as well
<jcristau> ogra: you can do that, and X won't care
<wgrant> It seems a bit odd that we've finally grown two independent methods of setting runtime properties within 6 months of each other
<ogra> jcristau, it *works* with evtouch :)
<jcristau> weird..
<ogra> afaik its the whole purpose of using hal that you can change configs at runtime
<ScottK> pitti: I'd like to see someone involved in breaking kdebluetooth step up to help fix the problem.
<seb128> did anybody look if fedora has a patch?
<seb128> they have the new bluez for some time now
<ScottK> I didn't know that.  I'll look.
<seb128> they did the change before ubuntu and several of the patches which have been used are fedora changes
<dholbach> seb128: http://daniel.holba.ch/harvest/handler.py?pkg=kdebluetooth
<ogra> jcristau, http://paste.ubuntu.com/55658/
<ogra> jcristau, thats the wrapper i use for ev_calibrate ... works just fine
<pitti> http://daniel.holba.ch/harvest/handler.py?pkg=kdebluetooth doesn't look very relevant, though
<jcristau> ogra: that's not 'at runtime', you start another X server :)
<seb128> dholbach: I'm not the one looking for changes and I know where to look for fedora changes but thank you ;-)
<dholbach> *nod*
<ogra> jcristau, for the calibration tool, the setting applies to the running server
<ogra> you cant calibrate at the rinning display sadly
<tjaalton> ogra: the hal settings are used only when the xserver starts
<ogra> i'll work with soren hauberg for jaunty to fix that stuff
<ScottK> seb128: They still have the KDE3 version of kdebluetooth.
<tjaalton> not runtime, for that there is properties now
<wgrant> tjaalton: That's what I thought - thanks for confirming.
<jcristau> ogra: the hal settings apply to the server where you start evcalibrate
<ogra> tjaalton, then i wonder why it works
<ogra> hmm
<jcristau> ogra: then presumably evcalibrate talks to the device driver somehow
<jcristau> and *that* applies to the running x server
<ScottK> Actually no. I think they have both.
<ogra> yes, in raw mode
<ogra> but only if calibrate is set to true
<ogra> jcristau, hmm, you might be right
<ogra> evcalibrate only writes to /etc/evtouch/config btw, which then gets iterated over by hal-set-property ...
<jcristau> ok.. i have no clue about evtouch.
<ogra> i patched it a lot :) so it works at all after four years
 * ogra thinks nobody in debian or ubuntu ever tried to actually use it :)
<ogra> but soren seems to work on a cairo based calibration tool and tries to unify all touchscreen drivers into using evdev, so thats an interim solution anyway
<wgrant> Um, any idea why gdb is segfaulting? How is one meant to debug that sort of thing?
<ogra> with the new mobile images we just gained a big tester community for such stuff so touchscreen support should rule in jaunty timeframe :)
<persia> wgrant, Generate a core file, and then hope gdb doesn't segfault when processing it?
 * wgrant hopes to make touchpad support rule similarly.
<wgrant> persia: It segfaults when run even with no args. I might reboot once this build finishes.
<persia> wgrant, Which gdb, which arch?
<ogra> wgrant, easy, you get enough test reports :) touchscreens werent really widely used unti now
<wgrant> persia: 6.8-3ubuntu2, intrepid/i386.
<wgrant> ogra: True. But some touchpads are very, very strange.
<ogra> yeah
<wgrant> Hopefully the autoscaling in master will fix most cases of that.
<doko> ubuntu-archive: when the openjdk-6 upload hits binary NEW, please move the openjdk-6-source-files package into main, and the icedtea6-plugin package into universe
<persia> wgrant, Try downgrading to 6.8-3ubuntu1, and use that to troubleshoot the 6.8-3ubuntu2 binary?
<wgrant> persia: I'll try that once the build finishes. Thanks.
<mdz> pitti: it stopped working a while ago, around the same time as evdev (I had assumed it was the same bug)
<wgrant> ogra: Anyway, back to syndaemon... syndaemon doesn't exist just to allow people to turn the touchpad off - it will watch for key presses and turn the touchpad off while they are occurring, so HAL can't do it.
<persia> wgrant, How is "keypress" defined?  I've a device with a touchscreen next to a touchpad, and the touchpad is where the palm would rest for stylus use.
<wgrant> persia: It checks for any differences in the keymap state.
<wgrant> This can of course be easily altered, and I ended up rewriting most of it today anyway.
<persia> Ah, that's fairly flexible, but not quite enough to cover this fairly irregular case.  Perhaps you'd have some time at UDS to look at it, and see what might make sense?
<wgrant> Sure. That's only a small bit of the code.
<wgrant> Users also seem to want to be able tell something to disable the touchpad when they have an external mouse plugged in. We can't accommodate everything, but it would be nice and probably not unthinkably difficult to cover the common cases.
<ScottK> seb128: No.  No relevant patches in Fedora.
<seb128> ok, that was worth looking
<ogra> wgrant, yeah, might make sense
<wgrant> ogra: Which bit?
<persia> wgrant, That's hard.  I can imagine a device with a USB-connected "mouse" of some sort as well as a touchpad, where the user would want both to work.
<wgrant> persia: Yes, it is difficult. It needs some thought.
<ogra> wgrant, the monitoring of kbd events
<wgrant> ogra: It's not great, but it has been that way since at least 2004, and users seem to like it.
 * ogra would still prefer hal being able to handle it on the fly :)
<wgrant> Why is it hal's business?
<ogra> but since thats apparently not working ...
<ogra> because hal handles the devce and its options
<wgrant> hal should be abstracting my hardware, not handling complex logic like that.
<ogra> *both* devices actually
<wgrant> hal handles the device and its initial options.
<ogra> right, and it should also handle option changes on the fly
<wgrant> XInput device properties are the better way to set things at runtime - but they unfortunately don't persist.
<wgrant> It would have to be redesigned.
<ogra> it is redesigned atm :)
<ogra> being called devicekit
<wgrant> I haven't heard much about that effort lately.
<ogra> hal's original author (davidz) is working fulltime on devicekit atm
<ogra> together with the move of dbus in the kernel you should have a lot more opportunities to adjust HW settings on the fly
<tjaalton> that would basically mean that devicekit should know about how to change X input device properties.. not likely to happen
<wgrant> Perhaps the xorg.conf-style options should go away and DeviceKit should use XInput properties instead.
<wgrant> tjaalton: Why not?
<tjaalton> wgrant: just a thought
<ogra> tjaalton, i think david has that in mind
<tjaalton> ogra: ok, in that case I'll shut up :)
<wgrant> That would be an excellent solution, IMO.
<ogra> hal wasnt designed as a config tool, thats what devicekit will do afaik
<tjaalton> k, so g-s-d and the kde equivalent wouldn't have to duplicate efforts
<wgrant> That would really clean up some of the mess that we have with input device config.
<ogra> g-s-d ?
<tjaalton> gnome-settings-daemon
<ogra> thats used for the session
<ogra> gtk options and the like
<tjaalton> yes
<ogra> i dont think a HW handling tool can ever replace it
<wgrant> And for configging all of your X devices.
<ogra> right, these peieces should be in hal already :)
<wgrant> At the moment it talks directly to X for setting mouse and keyboard properties.
<wgrant> They can't be.
<tjaalton> ogra: I meant the properties stuff, not general session things
<wgrant> Yet.
<ogra> right, thats what devicekit might/should solve
<wgrant> (in this case properties doesn't just mean the new XI device properties)
<ogra> on a low level
<wgrant> As long as there's a way for user apps to make changes to the running config...
<ogra> so your session doesnt need to care, apart from providing guis for it
<ogra> which will happen through dbus calls
<wgrant> Right. Makes sense.
<ogra> handled through consolekit/ploicykit ACLs
<jcristau> something still needs to happen through X11..
<ogra> pfft X11 :)
<ogra> modprobe xorg :)
<ogra> mvo, 0.7.8 seems to not fix it for me
<ogra> though i still think its xorgs/the intel dirvers fault of not handling dpms right
<ogra> mvo, oh, i didnt get .8 in my upgrade, sorry, still 0.7.7 here
<pitti> mdz: ok, so it wasn't the recent hal-info upload; so the thinkpad_acpi fdi hack didn't cover this, although the kmod is resonsible for setting the brightness as well?
<ogra> slangasek, what about the removal of uswsup ? i still see it in my daily images, wasnt it supposed to be removed from the archive ?
<mvo> ogra: yeah, I'm waiting for the publisher
 * ogra joins the waiting ... lines up at the bus stop :)
<nxvl> asac: hi! is there a wiki or something on how to patch firefox?
<ScottK> nxvl: Try #ubuntu-mozillateam
<asac> nxvl: -> #ubuntu-mozillateam
 * ScottK high fives asac.
<nxvl> thank you!
<mvo> ogra: plugins-main is done, plugins-extra is still pending
<ogra> yay
 * asac high tens ScottK ;)
<asac> hehe
<mdz> pitti: sorry, have been on the phone all afternoon. off now.
<mdz> pitti: I'm not entirely sure how it's supposed to work
<kirkland> BenC: ping
<mdz> pitti: there is an ACPI event generated, and hal is receiving that (but not generating an event)
<kirkland> BenC: dendrobates has assigned me https://bugs.launchpad.net/bugs/257739, in soren's absence
<ubottu> Launchpad bug 257739 in linux "intrepid guest install with virtio net doesn't work" [Critical,Confirmed]
<mdz> pitti: there is also an X keysym event being generated, and I can see that with xev, but nothing reacts to it
<kirkland> BenC: in that bug, cjwatson posted a conversation between he and soren, the net of which was that soren need to talk to you (or the kernel team) about the virtio drivers
<theBishop> was leaving "Message Notification" in Pidgin Off by default a conscious development decision?  If so, I think it was a terrible idea.
<mdz> pitti: I see the values change in sysfs, but the brightness doesn't actually change.  it DOES change if I write to one of the two sysfs acpi_video devices
<kirkland> BenC: I'm trying to determine if that conversation took place, and if anything came of it?
<cjwatson> BenC: basically I felt that the block and net bits of virtio-modules should be folded into block-modules and nic-modules
<cjwatson> BenC: which would save a lot of d-i-side juggling
<BenC> cjwatson, kirkland: I was sure soren posted updates for that to kernel-team@ and that we had integrated it
<cjwatson> aha, I didn't see that
<cjwatson> let me check
<cjwatson> virtio_blk and virtio_net are still in virtio-modules
<cjwatson> virtio_net is in nic-modules (duplicating virtio-modules, which is a bug), which may solve the network part
<cjwatson> it still doesn't really look quite right
<kirkland> cjwatson: BenC: for what it's worth, the storage part looks to be a regression between Beta and today.  ie, the beta iso detects the vda disk, and today's iso does not
<cjwatson> liw: how are things looking with lool's comments on system-cleaner for main (279554)?
<kirkland> BenC: is there more to be done on my side, or am i just waiting for kernel-team@ to take soren's changes?
<BenC> kirkland: Can you find the changes, make sure the still apply, and forward them to me directly?
<kirkland> BenC: i'll track them down
<BenC> kirkland: thanks
<kirkland> BenC: actually, the only thing I've seen from Soren recently on kernel-team@ is https://lists.ubuntu.com/archives/kernel-team/2008-August/002892.html
<kirkland> BenC: which looks unrelated
<BenC> kirkland: Hmm...ok, if you know all the changes that need to happen, can you pop out a diff?
<kirkland> BenC: i don't know all the changes, as I'm still coming up to speed as soren's backup on this, but i'm working on it
<kirkland> BenC: most immediately, i notice that this is a regression since the beta iso came out
<kirkland> BenC: ie, the beta iso server installer autodetects a virtio disk, and today's does not
<kirkland> BenC: i'm hoping that that's something simple to track down
<BenC> kirkland: any changes in that regard in our packaging?
<kirkland> BenC: our = kernel?
<cjwatson> that's bizarre, let me see if I can find history
<BenC> kirkland: right
<kirkland> 2.6.27-4 vs 2.6.27-6
 * cjwatson fishes down the relevant udebs
<cjwatson> ok, the kernel udeb layout is essentially the same
 * cjwatson <- very confused
<kirkland> cjwatson: i'm handling virtio network and virtio hard disk as separate problems at the moment
<cjwatson> oho!
<cjwatson> somebody unfixed the virtio-modules priority change I did
<kirkland> cjwatson: i found the no-disk-detected very easy to reproduce
<cjwatson> BenC: for the short term, could you make virtio-modules Priority: standard? that's why it regressed
<cjwatson> I'd changed the overrides in the archive, but that didn't get preserved across ABI changes
<cjwatson> I'll fix it again now
<cjwatson> kirkland: ^- I think that should fix both of them
<kirkland> cjwatson: very nice, thanks
<BenC> kirkland: done in the kernel as well
<cjwatson> thanks!
<kirkland> cjwatson: any chance we can turn the crank on the server iso build?
<cjwatson> I'll look at the udeb layout
<cjwatson> kirkland: needs a publisher run first
<kirkland> cjwatson: okey doke
<cjwatson> so at least two hours now :(
<kirkland> cjwatson: i was about to buzz off to lunch
<kirkland> cjwatson: that's okay, i still have many hours left in my work day ;-)
<kirkland> cjwatson: i would very much appreciate being able to crank through another round of testing this afternoon, if at all possible
<kirkland> BenC: thanks, man
<BenC> kirkland: np
<cjwatson> BenC: I think it's something like http://paste.ubuntu.com/55700/
<cjwatson> but I should probably test-build that
<cjwatson> test-building on ronne now
<BenC> cjwatson: that's the patch I was thinking of, thanks
<ion_> Any pointers about how to debug LP #278188? Thanks.
<ubottu> Launchpad bug 278188 in linux "irda broken on Thinkpad T23 with 2.6.27-4-generic, works with 2.6.24-16-generic" [Undecided,New] https://launchpad.net/bugs/278188
<cjwatson> BenC: I just knocked that together a few minutes ago, although soren might have produced the same thing :)
<BenC> cjwatson: fooled me :)
<asac> soren: i think i know why nfs doesnt come up for NM
<asac> soren: or did you already figure that out?
<cjwatson> mvo: do you have any idea why the Apttermlog.gz in bug 269182 seems to have somebody running 'vim /boot/grub/menu.lst' by hand in the middle of it?
<ubottu> Launchpad bug 269182 in grub "package linux-image-2.6.27-3-generic 2.6.27-3.4 [modified: lib/modules/2.6.27-3-generic/modules.pcimap lib/modules/2.6.27-3-generic/modules.dep lib/modules/2.6.27-3-generic/modules.alias lib/modules/2.6.27-3-generic/modules.symbols] failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/269182
<cjwatson> mvo: I noted that the failure appears right after they exit the shell and was wondering if that could be connected
<mdz> bryce: ping
<mvo> cjwatson: I suspect (without looking at it yet) that it might be someone using the ucf option "get a terminal"
<cjwatson> mm, I suppose it must be
<cjwatson> I was trying to figure out if maybe something was interfering with the fd on the X socket
<mdz> pitti: we have a breakthrough in bug 280646; it is related to the gconf numlock setting
<ubottu> Launchpad bug 280646 in hal "ACPI brightness events no longer work on ThinkPad T61" [Medium,Triaged] https://launchpad.net/bugs/280646
<mdz> beginning to look like an evdev issue
<mvo> cjwatson: I think liw had a bug where fglrx got loaded during the upgrade and that killed (froze) his X
<cjwatson> mvo: I'm not seeing anything in dmesg; it's a shame syslog isn't included in apport reports
<mvo> cjwatson: the reporter has a ati card as well and had fglrx installed - but dkms failes during the install so its probably something else
<NCommander> ScottK, working on amule. I got called to a massive fire last night
<cjwatson> fglrx (8.522): Installing module.^M
<cjwatson> .......(bad exit status: 7)^M
<cjwatson> informative ;-)
<mvo> cjwatson: I have seeen similar "frontend lost connected" in the past in connection with ucf, I think it was the diff feature then. but it might simply a usability problem (someone just closing the debconf dialog for example)
<mvo> cjwatson: one issue that silbs ran into was that she clicked "cancel" in a debconf prompt and that makes the script fail (at least that is what I concluded from the logs)
<cjwatson> well, that depends on the client
<cjwatson> I don't think it's the case here
<cjwatson> I've asked the reporter if they closed the terminal window, though
<mvo> cjwatson: ok, that would make sense (closing the widnow)
<slangasek> ogra: no, uswsusp will be dropped as a recommends: of pm-utils (soon), it's not going to be dropped from the archive
<cjwatson> mvo: can we disable the close button on that window? I doubt it's a good idea to use it :)
<mvo> cjwatson: I was think that too, for debconf gnome, disable close button and cancel button
<cjwatson> actually, I was trying to do that for ubiquity (in its standalone mode) a while back, and couldn't find out how
<cjwatson> if you happen to know, please tell me :)
<mvo> cjwatson: self.window_main.window.set_functions(gtk.gdk.FUNC_MOVE) (the second window is the gdk-window)
<mvo> that is what I use in update-manager
<mvo> (in the release upgrader)
<cjwatson> mvo: aha! thanks a lot
<mvo> cjwatson: cheers, I have a look at debconf now
<mdz> does anyone know how num lock works in this day and age? input layer? X?
<mrxmike> all intrepid (64bit) beta releases (alternative/normal) installers crash on my system  >  Intel D945GLCF Atom motherboard (with atom 330 proc)
<mrxmike> are you guys (devs/ canonical) aware of this?
<asac> soren: ok i think i fixed it ;)
<mdz> mrxmike: I don't happen to know; have you looked to see if there is a bug open?
<mrxmike> mdz: not yet
<mdz> if there is no bug open, then it is safe to say we are not aware
<cjwatson> mrxmike: if it's consistent across all installers, it's likely to be a kernel bug, so start at https://bugs.launchpad.net/ubuntu/+source/linux
<mdz> mrxmike: does the 32-bit build work?
<mrxmike> mdz: havent tried yet, its 64bit.. so i wanna enjoy 64bit
<mrxmike> :)
<mdz> mrxmike: the intrepid desktop kernel doesn't have all of the drivers you'll want for Atom; the mobile bulids should
<mrxmike> mdz: huh?
<mdz> mrxmike: the folks who work with atom hang out on #ubuntu-mobile
<mdz> mrxmike: I'm not familiar with that particular motherboard, but we provide a separate kernel for LPIA (Atom)
<mrxmike> LPIA=?
<mrxmike> low power IA?
<cjwatson> yes
<mrxmike> well... i would like to use this system as a server...
<mrxmike> i dont think ubuntu-mobile is suitable for that? :o
<mdz> mrxmike: then why are you installing ubuntu desktop? :-)
<mrxmike> i tried both server and desktop
<mrxmike> i didnt mention the word 'desktop'
<mrxmike> :-)
<ogra> slangasek, bah :(
<mdz> ogra: do you know if the intrepid generic kernel works on Atom?
<cjwatson> mrxmike: you mentioned alternative (by which I guess you meant alternate), which installs the Ubuntu desktop. :-)
<mrxmike> i tried the normal server intrepid version
<mrxmike> 64bit
<mrxmike> and the alternative 64bit desktop version
<ogra> mdz, yes, it does
<ogra> mdz, ubuntu-mobile uses -generic by default, we have plenty atom users with mobile
<cjwatson> mrxmike: even on systems capable of 64-bit operation, 32-bit is more appropriate for many uses, so it's worth trying out
<mdz> ogra: oh, good.  mrxmike will be pleased
<mrxmike> ok, well ... the kernel (of the livecd) does start with acpi=off
<mrxmike> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm, i red over ogra's comment
<mdz> ogra: who uses -lpia then?  ubuntu-mid?
<mrxmike> generic=unmodified= same as unbuntu desktop
<mrxmike> isnt it?
<pwnguin> arg
<mdz> does anyone know how to track down which process is setting a particular gconf key?
<ogra> mrxmike, xactly
<mdz> mrxmike: depends on what you mean by "unmodified" (relative to what?)
 * ogra read that as unmodified relative to desktop :)
<mrxmike> mdz: relative to what its forked of within the ubuntu stall ;P
<mdz> mrxmike: parse error
<mathiaz> mvo: did you get a chance to take a look at bug https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/84918 ?
<ubottu> Launchpad bug 84918 in unattended-upgrades "package should set up sensible config" [High,Triaged]
<bryce> mdz, sounds like some progress is made on the brightness key issue?  Need something done for X?
<mdz> bryce: that's why I'm looking for you
<cjwatson> mrxmike: the output of 'sudo dmidecode' and 'sudo lspci -vvnn' (and 'dmesg', probably) can be useful in isolating machines that need acpi=off and either fixing them or making that the default
<mdz> bryce: it's starting to smell a bit like evdev
<mdz> bryce: please have a look at bug 280646
<ubottu> Launchpad bug 280646 in hal "ACPI brightness events no longer work on ThinkPad T61" [Medium,Triaged] https://launchpad.net/bugs/280646
<bryce> yep looking now
<bryce> so, you think -evdev is not updating the numlock status correctly?
<mdz> bryce: whatever is watching num lock and setting the gconf key seems to be failing to unset it
<mdz> bryce: can you test whether the gconf key gets unset for you when you toggle numlock off?
<bryce> sure
<mdz> bryce: just run the gconf command in the bug and toggle it on and off. what happens?
<bryce> hmm, I get 'true' / 'false' / 'true'
<bryce> er sorry, reverse that
<bryce> 'false' / 'true' / 'false'
<Treenaks> bryce: that's not reverse, that's inverse :)
<ogra> Treenaks, arguing with a native english speaker ?
<Treenaks> *hides again*
<ogra> thats what i call brave :)
<bryce> mdz, timo has a thinkpad, let me see if he can reproduce
<cjwatson> that could even be an xkeyboard-config bug ...
<bryce> ah too bad, he doesn't have access to his laptop
<mdz> bryce: I can reproduce it here and am happy to help track it down; what can I do?
<H|V_3ala2> hey
<H|V_3ala2> any1 here?
<bryce> well, colin's right that it's not certain which component is to blame
<cjwatson> although I wouldn't expect xkeyboard-config to be responsible for getting the key as far as gconf
<bryce> cjwatson: yeah, though I'd have said the same of -evdev
<H|V_3ala2> any dr watson here?
<bryce> give me a few minutes to poke through the -evdev source
<H|V_3ala2> ACPI: DMI BIOS year==0, assuming ACPI-capable machine,,,,,,,,,,,,,????
<cjwatson> bryce: likewise; surely gconf gets it from something hal-ish
<mdz> bryce: some general guidance on how num lock is handled now would be helpful
<mdz> where the state is stored
<mdz> in the input layer, in the X keyboard driver, etc.
<mdz> cjwatson: fwiw hal itself knows nothing of that key
<mdz> (s/key/gconf &/)
<mdz> H|V_3ala2: no one is here
<bryce> could also be a fault in xserver
<bryce> mdz, -evdev has special handlers for numlock, and passes it up to the xserver.  evdev doesn't do a lot of processing - it's only 3000 lines total.
<mdz> at times like this, I wish I could do an indexed search of all of the source code in Ubuntu
<mdz> gnome-settings-daemon knows about it
<ogra> .oO(wouldnt that be a great sabdfl pet project for launchpad ?)
<bryce> mdz, yeah these multi-component bugs can be frustrating
<mdz> bryce: gnome-settings-daemon has a callback which sets this key
<bryce> mdz, xserver communicates key changes to x11 clients, so I'm wondering if gnome-settings-daemon is that key
<bryce> er s/key/client/
 * bryce hmms
<superm1> if you kill gsd, you can usually intercept a lot more keypresses
<superm1> eg via xev
<mdz>  http://paste.ubuntu.com/55736/ is the handler
<mdz> bryce: what's kbev->state.locked_mods?
<cjwatson> mdz: I've occasionally used google code search for such purposes
<bryce> mdz, sounds like a bitmask for lockable modifier keys (num lock, scroll lock, caps lock)
<bryce> er, bit field
 * bryce needs more coffee
<cjwatson> finds libgnomekbd, sabayon, gnome-applets, control-center and some irrelevant stuff on first page
<cjwatson> yeah, I believe locked_mods is just the modifiers that are locked
<cjwatson> (search> for /desktop/gnome/peripherals/keyboard)
<bryce> libgnomekbd is probably the one to look at
<mdz> oh god
<bryce> gnome-control-center probably only comes into play when making configuration changes
<mdz> numlock_xkb_callback is getting called for *every* *keypress*
<bryce> ew
<cjwatson> does it just chain through all its key callbacks every time or something?
<bryce> mdz, is that in gnome-settings-daemon?
<mdz> bryce: yes
<mdz> cjwatson: http://paste.ubuntu.com/55738/
<CarlFK> I am looking for python PyCon march 09, chicago speakers.  Anyone in here have any interested?  something about how ubuntu will deal with py3.0 would be great
<mdz> cjwatson: gdk_window_add_filter(NULL, ...)
<mdz> null filter == all events
<bryce> who else has been able to reproduce this bug?  Is it truly Thinkpad T61-specific?  If so maybe we need to examine how the T61 handles numlock keys differently?
<mrxmike> mdz: the 32bit version seems to work fine
<cjwatson> oddly, the pygtk version of add_filter doesn't have that null argument
<bryce> CarlFK: probably you want to ask on the ubuntu-devel-discuss@ mailing list
<mdz> bryce: read the bug; there is a person there who was able to reproduce it
<cjwatson> mdz: NULL as first arg just means all windows, not all events
<cjwatson> http://library.gnome.org/devel/gdk/stable/gdk-Windows.html#gdk-window-add-filter
<cjwatson> there may not be a way to install a filter for just one key ...
<CarlFK> bryce: will do. thanks
<mdz> cjwatson: you're right, but the effect is the same
<mdz> cjwatson: the filter func gets called for every event
<mdz> this is apparently as intended
<mdz> cjwatson: this makes for a very interesting exercise in trying to use breakpoints
<bryce> mdz, okay he says he has a thinkpad t61 in another bug.  interesting
<cjwatson> one way xkeyboard-config could come into it would be if the lock modifier isn't properly set when numlock is engaged
<bryce> I wonder how num_lock is working differently on T61's than on other systems
<cjwatson> since in general the keysym for a given key may be different when numlock is engaged versus when it isn't, it does have to go through xkeyboard-config
<ahasenack> bryce: which bug? I'm on a T61 right now
<bryce> ahasenack: 280646
<cjwatson> anyway, I really have to spend some time with my family, they're starting to forget what I look like
<bryce> ahasenack: see comment 21 for steps to reproduce
<mdz> pitti: the guest session has turned out to be very useful for debugging
<mdz> bryce: in a guest session, i confirmed that I see a KeyEvent for the numlock key when numlock state is on, but not when it's off
<bryce> mdz, via xev?
<mdz> bryce: yes
<bryce> ahhhh
<ahasenack> bryce: hmm, I'm on hardy
<bryce> ahasenack: you *might* be able to reproduce it by setting your keyboard driver in xorg.conf to "evdev".  Alternatively, booting an intrepid live-cd could be sufficient
<ahasenack> bryce: that gconf --get command always returns "No value set for ..." here
<ahasenack> bryce: I'll get the live cd
<mdz> ahasenack: how curious
<mathiaz> radix: I've looked at your 1.0.23 branch and it looks good.
<bryce> ahasenack: ok sounds like you'd need to boot the live-cd
<mathiaz> radix: I've made some editorial changes to the changelog (adding some LP numbers)
<ahasenack> bryce: is the beta one enough?
<bryce> ahasenack: yep
<ahasenack> oh, I have it already :)
<mdz> bryce: can you confirm that you see a keypress event both times whet toggling it on/off?
 * ahasenack burns
<mdz> I'm going to do some console debugging, brb
<mathiaz> radix: there is also a new scriptcontent library that doesn't seem to be used anywhere in the code.
<mdz> bryce: I can reproduce on the console
<mdz> 'input-events 1' shows num lock the first time, and not the second
<bryce> mdz, I do get keypress events when toggling it on and off both
<ahasenack> bryce: wait, I forgot my brain in my bed
<jmichel> when building a library with dpkg-builpackage, the resulting deb file doesn't contain the files
<mdz> I have now officially come full circle back to the kernel (where I started!)
<jmichel> it seems when the script is installing my library it does so in /debian/tmp
<ahasenack> bryce: the gconf tool command does work as shown in that command, but I have no issues with backlight on my lcd
<ahasenack> in that comment, I mean
<mdz> ahasenack: so you can reproduce the gconf/num_lock breakage, but your brightness hotkeys still work?
<ahasenack> mdz: right
<jmichel> but the files in the deb archive are taken from /dedian/mylib and /debian/mylib-dev
<jmichel> any help would be appreciated
<ahasenack> mdz: via gconf it's always true afterwards, but the backlight continues to be controlled via its keys as usual
<mdz> ahasenack: please attach the output of "sudo dmidecode" and "dmesg" to the bug
<bryce> ahasenack: the brightness level thingee is a regression in intrepid
<ahasenack> mdz: right, I'm still on hardy, just burning the intrepid live cd
<mdz> ahasenack: you tested the backlight keys on the beta CD, right?
<ahasenack> mdz: in the next 15min or so
<bryce> ahasenack: so no surprise you don't have that problem - but presumably if you upgraded right now, you'd have it
<mdz> ahasenack: oh
<mdz> so the num lock bug is older, but something else broke the brightness keys when the gconf key is set
<mdz> that's useful to know
<bryce> mdz, tried booting an older kernel?
<ahasenack> and it's maybe not related
<H|V_3ala2> ACPI: DMI BIOS year==0, assuming ACPI-capable machine
<H|V_3ala2> sos
<H|V_3ala2> sos
<mdz> H|V_3ala2: this is not a support channel, please go to #ubuntu
<mdz> bryce: I did, but only to verify that the brightness keys didn't work
<mdz> bryce: I'll check the num lock issue on 2.6.24
<mdz> brb
<radix> mathiaz: hi, sorry, was afk
<radix> mathiaz: actually, the scriptcontent library is used by the server... the server uses the client code as a library
<radix> mathiaz: btw, did you see my most recent change? you may have missed it, since I just added it recently. it makes --purge clean up a bunch of stuff
<mathiaz> radix: hm - ok. But it's not used in the client at all.
<radix> mathiaz: right, it's not used in the client application yet
<radix> but it will be
<mathiaz> radix: ok.
<mathiaz> radix: I'm reviewing lp:~radix/landscape-client/intrepid-1.0.23/
<mathiaz> radix: revno 93
<radix> yep, that's the one
<radix> ah
<radix> mathiaz: it's at 95 now
<radix> 94 and 95 are the --purge fixes
<radix> (for bug #121182)
<ubottu> Launchpad bug 121182 in landscape-client "Client should remove /var/lib/landscape if --purge is used" [Undecided,In progress] https://launchpad.net/bugs/121182
<lukehasnoname> BenC: Know a workaround for bug #273833 ? I can't boot because of it
<ubottu> Launchpad bug 273833 in v86d "v86d missing from initramfs" [High,In progress] https://launchpad.net/bugs/273833
<mathiaz> radix: ok - I'll update the branch then.
<ogra> lukehasnoname, you should be able to boot if you drop splash from the grub commandline
<ogra> it will only affect usplash
<lukehasnoname> ogra: How would i do that, in a nutshell? I want to know for sure what to do, since if I run into something I don't know I'll have to boot back to Vista to get back here.
<mdz> bryce: do you see events in lshal -m when you use your brightness hotkeys?
<mdz> ahasenack: do you?
<ogra> hit esc at if "GRUB" appears on the top left of your screen, go to the kernel you want to boot, hit "e" edit the line, hit b to boot
<lukehasnoname> mk
<bryce> mdz, nope, nothing prints out from lshal -m when I use the brightness keys
<lukehasnoname> I hope I'll be on intrepid next time I talk to you
<ahasenack> mdz: you want me to try in hardy or would you prefer to wait a bit for me to boot into intrepid beta live cd?
<ahasenack> bryce: are you on a t61 too?
<bryce> ahasenack: no I don't have a t61
<mdz> bryce: interesting, gpm_button_filter_x_events in gnome-power-manager doesn't even get called when that gconf key is set, regardless of the keyboard state
<mdz> ahasenack: both please
<mdz> bryce: can you confirm that on your laptop?
<ahasenack> mdz: on hardy, where it's currently working: http://pastebin.ubuntu.com/55747/
<mdz> ahasenack: output of "sudo lsinput" please?
<ahasenack> mdz: which package has it?
<mdz> ahasenack: input-utils
<bryce> mdz, sure; is there an easy way to check that or did you just hack the code directly?
<jmichel> Anyone know where I should go for some help using dpkg-buildpackage? maybe another IRC channel ?
<ahasenack> mdz: http://pastebin.ubuntu.com/55748/ (still on hardy)
<mdz> bryce: I used gdb
<ogra> jmichel, #ubuntu-motu probably
<bryce> mdz, btw I've browsed through xkeyboard-config but nothing jumps out as worth investigating.  the handling of keyboard stuff for evdev has changed of course, but there's little that's thinkpad-specific or num-lock specific that looks suspicious
<jmichel> ogra: thx
<mdz> ahasenack,bryce: I don't see anything in lshal -m even when it is working for me (ie. numlock_on=false)
<ahasenack> mdz: numlock is not on here, but gconf still thinks it is
<mdz> bryce: any guesses why the numlock_on key in gconf seems to affect whether the GDK filter gets called?
<mdz> bryce: surely gdk doesn't check that gconf key
<mdz> perhaps something else is listening for changes to that key
<cjwatson> I don't suppose that numlock_on being set means that the keyboard firmware filters out the key ...?
<cjwatson> surely not though, you said it worked in hardy
<bryce> mdz, well it sort of sounds like something is incorrectly applying the locked modifier keys when checking those hotkeys
<cjwatson> but it rather sounds like it's not making it to gdk
<mdz> cjwatson: google code search is nice, thanks
<bryce> mdz, in which case I'd wonder if capslock or scrolllock would produce similar misbehavior?
<cjwatson> bryce: I suggest that we need a hacked evdev with extra printfs
<cjwatson> it would be very interesting to know whether it's reaching evdev at all, and if so what it looks like on the way in and out
<mdz> bryce: works fine with caps lock on
<cjwatson> printf debugging is usually a good first line of attack once you have a starting hypothesis :)
<mdz> ahasenack: I would appreciate if you could file a separate bug report about the num lock event issue ("ubuntu-bug linux" on the intrepid live CD) while we continue to chase the brightness key part of the problem
<ahasenack> mdz: ok
<ahasenack> mdz: I'm just about to reboot into intrepid, just finishing something else up
<bryce> mdz interesting, yes I can reproduce what you mentioned about gpm_button_filter_x_events not getting called when numlock is on.
<radix> mathiaz: anything else we should discuss about the package?
<mdz> bryce: by "numlock" do you mean the keyboard state, or the numlock_on gconf key?
<NCommander> jdong & ScottK: can one of you ack a backport?
<mathiaz> radix: not that I can think of for now
<bryce> mdz, keyboard state
<radix> mathiaz: should I be doing anything else?
<mdz> bryce: ok, interesting
<bryce> cjwatson: ok I can hack something up for testing, let me get some food first
<mdz> bryce: but your brightness keys still work, presumably because you're getting an event via hal?
<mdz> I wonder why I don't get a hal event
<mathiaz> radix: not really.
<radix> mathiaz: ok, thank you very much! I appreciate your patience :)
<mathiaz> radix: on a related note, is there a way the tests could be enabled in the build process?
<mathiaz> radix: but this is not a showstopper for intrepid
<radix> mathiaz: not in the very short term, unfortunately - the problem is the dependency on a session dbus running
<radix> mathiaz: it's something I definitely want to do, though
<radix> mathiaz: if you want to run the tests yourself, you can use "trial -r glib2 landscape" while in the root of the source tree, assuming you have a dbus session bus running
<radix> I need to figure out a way to start and stop a bus while the tests are running automatically
<mathiaz> radix: ok - I may try that.
<radix> and get the tests to connect to that particular bus address
<mathiaz> radix: anyway it's not a showstopper for intrepid
<radix> ok
<mdz> bryce: I could possibly understand it not being called when the keyboard state is set, but I find it very puzzling that toggling the gconf key changes the behaviour
<mdz> bryce: I think I agree with cjwatson that an instrumented evdev would be enlightening
<ScottK> NCommander: Can you fix openexr on hppa?
<NCommander> On the todo list
 * NCommander is working on one crisis at a time :-)
<NCommander> ScottK, sorry for running off last night, working fire, and a massive one at that
<mdz> aha!  it's gnome-settings-daemon meddling
<ScottK> NCommander: Bug?
<mdz> if I STOP gnome-settings-daemon and toggle the gconf key, the brightness keys continue working
<NCommander> ScottK, huh?
<ScottK> NCommander: What's the bug for the backport you need ack'ed?
<NCommander> There are a LOT of bugs, over 25% that are confirmed/in progress, so I would really like to see some of these move
<NCommander> its the talloc backport, its a blocker on another one
<NCommander> ScottK, https://bugs.edge.launchpad.net/hardy-backports/+bug/269161
<ubottu> Launchpad bug 269161 in hardy-backports "Please backport talloc 1.2.0~git20080616-1 from hardy to intrepid" [Low,Confirmed]
<ScottK> OK.  I'll have a look at that one.  I don't have time for a general sweep through them now.
 * NCommander nods
<ScottK> NCommander: I feel a little nervous about a samba backport.  Have you tested that?
<NCommander> I did awhile ago. The package probably been updated since then, so it needs to be retested
<mdz> bryce: gnome-settings-daemon propagates the gconf numlock state to XKB via XkbLockModifiers
<cody-somerville> NCommander, stop trying to break stuff :P
<NCommander> cody-somerville, I did that all last night
<ScottK> NCommander: You can make one bug for a backport of multiple packages.  Please update this one to cover both and once it's tested, I'll approve them together.
<NCommander> ok
<andreas> mdz: so, after booting into intrepid-beta live, I got brightness setting working, but no OSD
<andreas> mdz: also, lshal -m doesn't report any event while I change the brightness settings
<mdz> andreas: does changing the numlock setting have any effect?
<andreas> mdz: no. Still no event on lshal -m, still no osd, and brightness setting continues working
<andreas> mdz:the osd works for other stuff, though, like volume setting via the volume hotkeys
<mdz> andreas: this is crazy
<mdz> it's like there are six different ways that this COULD work, and some of them are always broken
<mdz> andreas: which keyboard layout do you use?
<mdz> slangasek: do your brightness keys work?
<andreas> mdz: on hardy I use brazilian abnt2 + thinkpad, but on in trepid now it's standard us with no dead keys
<mdz> andreas: try changing it on intrepid to match your hardy config?
<bryce> mdz, right even with g-p-m not breaking, the brightness changes were taking effect
<bryce> mdz, interestingly I can see it skipping through multiple steps in each keypress... which is probably wrong... but unrelated to this problem
<mdz> bryce: your keys may work in hardware
<mdz> bryce: lshal | grep laptop_panel.brightness_in_hardware
<mdz> bryce: in which case g-p-m is just getting notification of the change and displaying the OSD
<mdz> (the part which is broken for andreas)
<bryce> $ lshal | grep laptop_panel.brightness_in_hardware
<bryce>   laptop_panel.brightness_in_hardware = false  (bool)
<bryce>   laptop_panel.brightness_in_hardware = false  (bool)
<bryce>   laptop_panel.brightness_in_hardware = true  (bool)
<andreas> mdz: so, the exact layout is not available under system->preferences->keyboard (it's missing the Thinkpad variant)
<mdz> bryce: I'm guessing your laptop doesn't actually have three LCDs...
<andreas> mdz: other than that, the behaviour is the same
<bryce> hmm, I can also confirm that with numlock set, the keys work but the OSD doesn't display
<bryce> mdz, heh
<bryce> mdz, not today
<andreas> I get two answers only for that lshal | grep ..., and both are true
<bryce> mdz, so what's the next step - still want the instrumented -evdev, or is it looking like g-s-d is responsible?
<mathiaz> radix: when purging landscape-common, why not just rm -rf ${LOG_DIR} ?
<radix> mathiaz: I wasn't sure if that was bad, I couldn't really find much policy documentation about what to do during purge
<mdz> bryce: I still want to know what evdev is doing
<radix> mathiaz: I was under the impression that that command in particular would be bad because $LOG_DIR is actually a directory in the package
<slangasek> mdz: yes, though they work by indeterminate means; I think they're being handled in hardware against my wishes
<mathiaz> radix: hm - correct - may be rm -rf ${LOG_DIR}/*?
<radix> mathiaz: sure, that would work
<_Zeus_> mathiaz: is the /* nessecary?
<radix> I guess it's a matter of being conservative.. if someone puts a random file in /var/log, then it won't be deleted the way I have it
<bryce> looks like the three devices with the brightness_in_hardware are /org/freedesktop/Hal/devices/computer_backlight_0, /org/freedesktop/Hal/devices/computer_backlight, and /org/freedesktop/Hal/devices/dell_lcd_panel
<mathiaz> radix: right - OTOH that means if a new log file is added, one has to remember that the postrm script needs to be updated.
<mdz> bryce: right, so yours are being handled in hardware, so you've no problem changing the brightness, but you can reproduce the problem in that the OSD doesn't display (for the same reasons)
<radix> mathiaz: yeah, true. but then, what would landscape-client do? it can't remove *, because it would remove sysinfo.log.
<bryce> alright, one instrumented -evdev coming up...
<mdz> bryce: that should give you enough to chase this on your own
<mdz> I'm going to have to quit soon, my wrists are shot
<mathiaz> radix: hm - good point
<radix> mathiaz: maybe we could separate them out into different log directories, that would definitely make it easier from this perspective
<radix> but that would require some more source changes
<mathiaz> radix: right - it may not be worth the trouble.
<cjwatson> _Zeus_: the reason for the /* is that the directory itself is shipped in the package
<cjwatson> _Zeus_: as was said just a couple of lines above :)
 * andreas goes back to hardy
<_Zeus_> cjwatson: oh, oh.  didn't see that
<kirkland> cjwatson: it's been a couple of hours... is there somewhere I can check the status of those server iso re-spins?
<kirkland> cjwatson: i don't see anything here: http://cdimage.ubuntu.com/ubuntu-server/
<kirkland> cjwatson: anything meaning a second spin sync'd out yet
<cjwatson> that's 'cos I didn't start them. give me a minute ...
<kirkland> cjwatson: :-)  kthx
<cjwatson> the couple of hours was until it was worthwhile starting them
<james_w> I'm back at looking at the pm-utils/uswsusp issue
<james_w> never mind, I need to look at the new upstream in more depth to work out what will happen next cycle before asking that question
<sebner> james_w: btw, I'll check this ssmtp thing tomorrow :)
<james_w> sebner: thanks. An alternative would be asking the security team whether it even matters for uploads to development releases
<sebner> james_w: why not? besides looks like a SRU back to Dapper
<james_w> sebner: dapper? I was expecting just hardy.
<sebner> james_w: well 2.62 and 2.61 is affected and dapper also has 2.61 IIRC
<sebner> james_w: yep, unfortunately. so we just can ignore edgy and feisty
<mdz> bryce: any luck?
<james_w> sebner: sure, have you done security updates before?
<sebner> james_w: once but my mentor is from the SRU team so I'll talk to him tomorrow
<bryce> mdz, still instrumenting and reviewing code...  I did run across one unfinished piece of code that I'm curious about
<bryce> mdz, I've also reviewed -evdev changes in git upstream, and there's a couple changes I wonder might have an effect.  It may be worthwhile to test the upstream git -evdev
<sebner> james_w: if that's ok for you!?
<james_w> sebner: of course
<sebner> james_w: fine. and thx for the hint with the correct changelog thing (also I haven't seen that many in this manner though ;))
<james_w> no, I think it more for security updates to stable release, but it can't hurt
<sebner> james_w: ah ok. but developement or not. it's a bug/security issue and it should be fixed ASAP
<james_w> yeah
<slangasek> pitti: hmm, how about if I re-upload samba with -v so that we can supersede 4.6 without losing the tracking :)
<mdz> bryce: did you try it?
<bryce> mdz, hang on
<mdz> bryce: I just did.  no change.
<bryce> :-P
<bryce> ok, thanks
<bryce> I'll finish building debs of it anyway
<slangasek> pitti: (done, please consider accepting ubuntu4.7 once it reaches the queue)
<mdz> bryce: I just built it from git and copied the .so
<mdz> bryce: interestingly, that crashed the X server
<mdz> bryce: I have a .crash from that if you want it
<bryce> http://bryceharrington.org/ubuntu/EvdevBug280646/
<bryce> that's the instrumented deb.  the git snapshot will take a couple more minutes
<mdz> bryce: can you upload the source?  I'm on amd64
<cjwatson> kirkland: btw, that server CD build finished a while ago, sorry I forgot to mention
<cjwatson> kirkland: you may have noticed already ;-)
<kirkland> cjwatson: already pulling it ;-)
<kirkland> cjwatson: watch -n 60 wget http://cdimage.ubuntu.com/ubuntu-server/daily/current/MD5SUMS -O- ;-)
<cjwatson> hah
<mdz> kirkland: --differences --cumulative
<bryce> mdz, source and amd64 debs -> http://bryceharrington.org/ubuntu/EvdevBug280646/
<mdz> bryce: brb
<kirkland> mdz: right ;-)
<mdz> bryce:
<mdz> (II) [bwh] EvdevReadInput()
<mdz> (II) [bwh] Posting keyboard event
<mdz> (II) [bwh] PostKbdEvent: value=1
<mdz> (II) [bwh] Posting keyboard event code=233, value=1...
<mdz> (II) [bwh] Posting keyboard event
<mdz> (II) [bwh] PostKbdEvent: value=0
<mdz> (II) [bwh] Posting keyboard event code=233, value=0...
<mdz> bryce: I've emailed you the full log
<bryce> ok thanks
<crazychenz> hello
<bryce> is the above from hitting numlock, or from toggling the brightness keys?  (or both?)
<mdz> bryce: brightness
<crazychenz> i was curious if anyone could explain or point to what  the configparams file does when building glibc 2.7
<bryce> mdz, do you get the same output regardless of numlock state?
<mdz> bryce: looks exactly the same
<bryce> wow interesting
<mdz> bryce: by the way, would you mind deleting the bit of that log with my password in it? :-P
<bryce> mdz, yikes, sure
<bryce> mdz, btw, do you have a high limit on your credit card?
<mdz> bryce: http://paste.ubuntu.com/55780/
<mdz> that's brightness up, brightness down, num lock, brightness up, brightness down, num lock
<jdstrand> cjwatson: hi! I noticed your comment about patch systems in an openssh bug. what is the advantage of not using a patch system in this particular case? (if this has been beat to death, feel free to tell me :)
<mdz> bryce: code=151 appears to be the Fn key
<mdz> 233 is brightness up, 232 is brightness down
<cjwatson> jdstrand: I avoid patch systems in all my packages where possible
<cjwatson> jdstrand: when dpkg-source -x natively extracts with the patches pre-applied, I'll change my position
<cjwatson> jdstrand: until then I object to the confusion caused
<cjwatson> yes, I realise my position is at variance with many other people here
<mdz> bryce: what's 'value='?
<mdz> bryce: is that press/release?
<jdstrand> cjwatson: interesting. you just want to quickly get at the actual working code
<mdz> bryce: if so, what's value=2?
<cjwatson> jdstrand: no, I think users deserve to be able to get at the actual working code without having to guess how to apply patches
<cjwatson> jdstrand: I've wasted too much of my life guessing debian/rules invocations to get patch systems to give me the code that's actually compiled
<cjwatson> the very very slow move to standardise on 'debian/rules patch' is helping a bit
<jdstrand> cjwatson: fair enough. curious if you are aware of 'what-patch'
<cjwatson> as is the new requirement in Debian policy to describe the patch system in use in a standard place
<cjwatson> jdstrand: yes, I am
<cjwatson> however, it only names the patch system, and doesn't tell you how to use it; and it misses out all the weird cases, things like bash
<jdstrand> cjwatson: I find when doing security updates for patchless systems, I end up doing a lot of manual 'stuff'. do you happen to have any scripts, etc for dealing with patchless systems?
<cjwatson> how come? patchless systems are the simplest, they're a strict subset of everything else
<cjwatson> you need fewer scripts, not more
<jdstrand> cjwatson: I guess I'm thinking more of extraction
<cjwatson> yes, if you want to break out individual patches, that takes some manual work
<cjwatson> but that's really only when you're sending things upstream, and I regard the hard work there as an incentive to keep the number of patches down
<cjwatson> it can also be mitigated by revision control
<jdstrand> true enough
<cjwatson> I don't understand why you would need to worry about that for security updates; can you explain?
<jdstrand> cjwatson: eg, if I am comparing with/pulling from Debian
<cjwatson> I would have thought you'd largely just want to apply the patch (massaging it into place as necessary)
<cjwatson> debdiff is a fine comparison tool, and works best on patchless packages because you don't get the diff-of-a-diff effect
<bryce> mdz, well... this -evdev code isn't very well documented (i.e. no comments)... however it appears to be something relating to the modifier level I'm guessing?
<jdstrand> cjwatson: sure, and I find myself going to snapshot.debian.net and doing just that
<bryce> value=2 _seems_ to correspond to a test if ctrl/alt/shift/capslock/scrolllock is pressed
<bryce> +/numlock
<cjwatson> jdstrand: that seems a perfectly normal way to work, to me
<jdstrand> cjwatson: well, I get to play with all the different philosophies, so I was wondering what I was missing with patchless
<cjwatson> bryce: it's not something like the modifiers as in keymaps(5) is it?
<cjwatson> jdstrand: simplicity, and that revision control works best when you aren't trying to shoehorn patches into it
<cjwatson> jdstrand: your revision control can just be a straightforward branch from upstream
<bryce> cjwatson: again, I'm just piecing together guesses here, but yes sounds like similar
 * jdstrand nods
<bryce> i.e.:
<bryce>     if (value == 2 &&
<bryce>         (ev->code == KEY_LEFTCTRL || ev->code == KEY_RIGHTCTRL ||
<bryce>          ev->code == KEY_LEFTSHIFT || ev->code == KEY_RIGHTSHIFT ||
<bryce>          ev->code == KEY_LEFTALT || ev->code == KEY_RIGHTALT ||
<bryce>          ev->code == KEY_LEFTMETA || ev->code == KEY_RIGHTMETA ||
<bryce>          ev->code == KEY_CAPSLOCK || ev->code == KEY_NUMLOCK ||
<bryce>          ev->code == KEY_SCROLLLOCK)) /* XXX windows keys? */
<jdstrand> cjwatson: I won't take up any more of your time. thanks! :)
<cjwatson> jdstrand: ideally, patches would be something exported from the revision control system (e.g. bzr looms); all other things being equal they are strictly less convenient than just modifying the code directly (as you would in any normal project, or e.g. if you were the upstream developer); the reason people like them is essentially because they provide a crude form of revision control
<cjwatson> but nowadays we ought to be able to put together more sophisticated ways of doing that kind of thing
<bryce> not sure what value=0/1 is; keyboard up/down events ??
<cjwatson> jdstrand: I'm waiting for a cscvs bug fix before I can get openssh imported into bzr, at which point I'll probably start experimenting with looms for it
<jdstrand> cjwatson: I'd agree with that, once Ubuntu is in bzr, this probably become a non-issue
<cjwatson> (at the moment it's in cvs, ugh)
<cjwatson> I don't want to convert it to bzr until I can make it be a proper branch from upstream though
<jdstrand> sure-- that would be a serious pain :)
<munckfish> guys are we going to be import upstream git repositories into bzr too?
<munckfish> E.g. kernel?
<bryce> (or xorg)
<cjwatson>   'value' is the value the event carries. Either a relative change for
<cjwatson> EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
<cjwatson> release, 1 for keypress and 2 for autorepeat.
<cjwatson> linux/Documentation/input/input.txt
<bryce> cjwatson: aha thanks
<bryce> autorepeat?
<cjwatson> munckfish: git imports are a high-priority feature goal for the Launchpad code team
<cjwatson> munckfish: (so yes, though not just yet since it's not ready)
<bryce> ah okay I understand, autorepeat makes sense here
<munckfish> cjwatson: blimey so the kernel team are going to swap to using bzr too? Or will it just be a front end on Launchpad?
<cjwatson> munckfish: that remains to be seen
<munckfish> cjwatson: ;)
<bryce> ok, so 0 = keyup, 1 = keydown, 2 = keyhold
<cjwatson> munckfish: they have a good deal of workflow built up around git and I don't imagine they'll be able to switch overnight
<munckfish> yeah I thought so
<bryce> cjwatson: I'm willing to guinea pig xorg
<bryce> cjwatson: we only manage 3-4 packages in git presently
<bryce> (and personally I find it a bit frustrating, so look forward to doing it with bzr)
<cjwatson> Debian xorg is all in git, isn't it?
<bryce> yes
<cjwatson> it'd probably be good to be able to merge from them easily before switching
<cjwatson> although working in bzr would be no worse than working outside revision control, in cases where you do that
<cjwatson> it's also possible to do rolling imports from git to bzr today with git fast-export | bzr fast-import -, but you may have to be prepared to throw away the branch in the future
<cjwatson> (that's what I'm doing with debian-policy)
<bryce> ok, going to reboot with the instrumented evdev and see if I get the same results as mdz.  brb
<mdz> bryce: I have some new information
<mdz> bryce: if I start a guest session, run xkbwatch (shows nothing), then press num lock (some things light up), then press num lock again, then some of the indicators in xkbwatch are still lit
<mdz> if only I knew what any of them meant
<mdz> bryce: can you recommend an alternative to xkbwatch which uses names rather than blinking lights?
<bryce> mdz, no but I can investigate that for you
<bryce> meanwhile, one difference I notice between your log and mine, is when I do brightness up, I see 8 of the code=233 lines
<bryce> whereas you see 2
<bryce> (II) [bwh] Posting keyboard event code=233, value=1...
<bryce> (II) [bwh] Posting keyboard event code=233, value=1...
<bryce> (II) [bwh] Posting keyboard event code=233, value=0...
<bryce> (II) [bwh] Posting keyboard event code=233, value=1...
<bryce> (II) [bwh] Posting keyboard event code=233, value=0...
<bryce> (II) [bwh] Posting keyboard event code=233, value=0...
<bryce> (II) [bwh] Posting keyboard event code=233, value=1...
<bryce> (II) [bwh] Posting keyboard event code=233, value=0...
<mdz> cjwatson: do you know how to dump the current X modifier state?
<bryce> mdz, xkbwatch.c is a tiny program.  how about I just hack it into printing the values
<lifeless> does anyone know of a trivial-to-use isolate-this-shell-script-please command ?
<mdz> bryce: if you like
<mdz> lifeless: for what value of 'isolate'?
<lifeless> something that will just put a mutex around the script basically, resets on reboots, but otherwise only allows one instance to run
<bryce> mdz, well if you'd find it useful?
<lifeless> mdz: ^
<mdz> bryce: I'm starting to become convinced that it is simply the num lock modifier which gets stuck on
<mdz> bryce: but I'm left to wonder why the X server has a num lock modifier at all
<mdz> given that it seems to be handled at a lower level than X
<mdz> and X doesn't actually notice whether it's on or off in the hardware
<munckfish> hi calc did you get a chance to test out that build fix for the !x86 ftbfs?
<bryce> mdz, ok well here's a patch for xkbwatch - http://bryceharrington.org/ubuntu/EvdevBug280646/x11-xkb-utils-xkbwatch-dbg.patch
<bryce> it prints numbers rather than names tho
<ScottK> superm1: Thanks for you kdebluetooth fixes.  I guess based on your mail I don't need to tell you we aren't there yet.
<ScottK> superm1: Do you know if there's a bug already on the solid issues?
<superm1> ScottK, I'm not sure.  I just installed KDE on a test machine and started grepping around until I found where problems were
<ScottK> superm1: OK.  pitti had the one you fixed on the Intrepid RC bug list.  I think we need an appropriate one for the remaining problems to replace it.
<superm1> ScottK, could you summarize that into another bug then?  Probably mark any crasher bugs that are using solid-bluetooth in some way too.
<ScottK> OK.  Let me see what I can do.
<superm1> ScottK, i'll try the small diff that I came up that will cover some more of the solid changes after it finishes building, but I know that there are some other bigger API changes, so it will probably be better to wait for the solid bluetooth authors to update the rest
<superm1> assuming they'll be doing it in a timely fashion
<kirkland> cjwatson: excellent, virtio disk is autodetected again in the installer
<kirkland> cjwatson: i'm chasing down another problem, though.  the install succeeds but the installed disk won't boot
<ScottK> superm1: What's your LP ID?
<kirkland> cjwatson: i'm looking at the grub install bit
<superm1> ScottK, superm1
<ScottK> superm1: Bug #280997 pointed at you.
<ubottu> Launchpad bug 280997 in kdebase-workspace "solid-bluetooth needs update for bluez 4.x" [High,Confirmed] https://launchpad.net/bugs/280997
<ScottK> pitti: Please use this bug now to track the KDE Bluetooth RC issue ^^
<ScottK> superm1: Gotta run and fix dinner.  See you later.  Thanks for looking into it.
<superm1> okay see ya ScottK
<ScottK> asac: Did the new Network-Manager get tested with Knetworkmanager before it was uploaded?  Bug #280919
<ubottu> Launchpad bug 280919 in network-manager "NetworkManager 0.7~~svn20081008t224042-0ubuntu1 breaks Knetworkmanager" [Undecided,Confirmed] https://launchpad.net/bugs/280919
<lfaraone> Hey, what is the package in which the ~/Examples files are kept?
<superm1> example-content i believe
<TheMuso> Yes, example-content.
<lfaraone> superm1: thanks
<lfaraone> What format would a patch have to be in for a file in example-content? The speex file has crappy quality.
<lfaraone> ( would a FFE be needed for bug 208561 ? )
<ubottu> Launchpad bug 208561 in example-content "Speex Audio file is a non-ideal bit-rate" [Low,Triaged] https://launchpad.net/bugs/208561
<crimsun> lfaraone: doubtful, though it's more wishlist
<lfaraone> crimsun: ah, good.
<lfaraone> crimsun: what kind of patch is needed? standard debdiff? (the reporter wants to help fix, I've offered to mentor)
<wgrant> What is the size delta?
<wgrant> A debdiff won't work -- it's binary.
<crimsun> you'd need to upload an entirely new source package with it re-encoded from the source
#ubuntu-devel 2008-10-10
<lfaraone> wgrant: well, we don't have the source file, so we don't know. it'll probabbly be a few kb less
<slangasek> er, what exactly is the plan of action here?  You want to re-encode using a source format that's not available?
<lfaraone> slangasek: well, we're wondering if it's recorded anywhere where the file came from.
<slangasek> the copyright file states it came from http://librivox.org/
<asac> ScottK: unlikely that the regression window really is the latest upload. at least if its a knetworkmanager specific issue
<asac> ScottK: read: no dbus api changes in the last upload
<lfaraone> slangasek: ah, we got it, it's on archive.org
<asac> ScottK: do you use a "hybrid" setup, e.g. one connection managed by ifup/ifdown and the wireless with NM?
<bryce> mdz, I've sorted out why the OCD doesn't display - it's a bug in gnome-power-manager
<bryce> hmm, no mdz
<bryce> cjwatson: so mdz's bug is a combination of two bugs - one is a thinkpad t61 kernel bug, that it's not propagating numlock key changes up properly (verified this with whot upstream), the other bug is local to gnome-power-manager where it's not bothering to grab keys with modifiers (it's grabbing with modmap=0 instead of modmap=AnyModifier)
<mathiaz> slangasek: is there a reason why /var/lib/samba is created in the samba package rather than the samba-common package?
<mathiaz> slangasek: it seems that libpam_smbpass segfaults if /var/lib/samba doesn't exists - see bug 260687
<ubottu> Launchpad bug 260687 in samba "Purging samba breaks login (pam_smbpass.so segfaults)" [High,Confirmed] https://launchpad.net/bugs/260687
<slangasek> mathiaz: it's a bug that was overlooked until recently; feel free to fix it
 * StevenK uploads most of the remaining libbluetooth2 transistion
<StevenK> superm1: ^
<slangasek> TheMuso: "812KB" - yeah, we don't have that to spare, please solve this another way for intrepid
<NCommander> StevenK, how much is left on that transition
<StevenK> NCommander: Um. Let me answer that after these process and the publisher finishes, roughly sixty minutes
<calc> i sliced the end of my finger with a serated bread knife, oops :(
<calc> that'll teach me not to stick my fingers where i can't see what is there
<NCommander> ScottK, I'm attacking openexr
<NCommander> No promises though, this is an ugly test failure
<calc> there was a knife stuck between boxes stacked in my garage, tried to pick up box and ouch
<StevenK> calc: You okay?
<calc> StevenK: yea it wasn't deep so i just cleaned it well, makes it a little harder to type without using that finger
<calc> i'm starting to get the hang of it, heh :)
<TheMuso> ouch
<calc> i thought i had cut myself on the cardboard until i looked under the box, lol
<NCommander> lamont, ping?
<StevenK> You know it's nearly midnight, right?
<NCommander> StevenK, not really
<NCommander> StevenK, time is relative afterall
 * StevenK teaches NCommander about "time zones"
<NCommander> as I said, time is relative ;-)
<NCommander> And there is only one true timezone and UTC is its name
<realist> NCommander: some astronomers may disagree with you.
<NCommander> *on earth
<NCommander> On Mars, UMT rules, and sols define the days ;-)
<NCommander> ScottK, I did some initial debugging on openexr; the main issue seems to be a race issue in glibc (it appears to me that some of the pthread() functions aren't working appropriately). I'm running the test suite on glibc as we speak. If you need this package uploaded, and you don't care about it supporting threads (due to the borked glibc), I can give you a patch to prevent it from calling make check on HPPA
<StevenK> NCommander, superm1: The last two libbluetooth2 transistion packages are libpam-blue and ussp-push
<StevenK> NCommander: If you prepare an upload to Intrepid proper, I'll sponsor it.
 * NCommander does that
<StevenK> NCommander: Just libpam-blue, since you fixed it, you deserve the upload for it
<NCommander> StevenK, http://pastebin.ca/1224354
<NCommander> StevenK, I haven't test built it yet (not on my intrepid box)
<NCommander> Care to do that for me?
<NCommander> ANd yes, its a big diff just because the upstream inlined ****loads of unneeded crap that had to go
<StevenK> That's nasty
<NCommander> Well, if upstream is willing to inline autotools changes ...
<StevenK> I'd prefer you update the date of the changelog, but *shrug*
<StevenK> NCommander: libpam-blue uploaded
<NCommander> \o\ /o/ \o/ <o> >o<!
<pitti> Good morning
<StevenK> pitti: I have belted the NBS list down to 7 affected packages
<StevenK> It will jump again since 2.6.27-7 got uploaded
<pitti> slangasek: samba with -v> WFM
<pitti> ScottK: nominated 280997 for intrepid
<geser> good morning pitti
<pitti> StevenK: rocking
<dholbach> good morning
<persia> StevenK, As an admin, could you subscribe the Bluetooth team to bluez bugs? ( https://bugs.launchpad.net/ubuntu/+source/bluez/+subscribe )
<StevenK> persia: Done
<dholbach> ogra: speaking of admins: can you please unsubscribe edubuntu-members from thin-client-manager bugs and subscribe some edubuntu-bugsquad instead?
<dholbach> I could unsubscribe edubuntu-members myself, but I'd prefer if some other team was subscribed at the same time
<geser> good morning dholbach
<dholbach> hiya geser
<persia> slangasek, It was suggested that you might have a useful comment for bugs 281135 and 281144
<ubottu> Launchpad bug 281135 in bluez-libs "Please remove bluez-libs from Intrepid" [Low,Confirmed] https://launchpad.net/bugs/281135
<ubottu> Launchpad bug 281144 in bluez-utils "Please remove the bluez-utils source from Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/281144
<lukehasnoname> Is there a reason linux-generic is being held back on my beta install of 8.10?
<persia> lukehasnoname, Have you checked on what it depends?  Is everything available?
<lukehasnoname> I'll check.
<geser> lukehasnoname: try "sudo apt-get install linux-generic" and it should tell you why it can't be installed
<lukehasnoname> geser: I ran the install and I didn't get errors
<persia> lukehasnoname, In that case it probably included a new dependency : update-manager won't install those except when doing a distribution upgrade.
<lukehasnoname>   bluez-cups bluez-utils evolution evolution-common gimp gimp-data gvfs   gvfs-backends libgimp2.0 libpisock9 linux-headers-generic obex-data-server   totem totem-gstreamer totem-mozilla totem-plugins ubuntu-desktop
<lukehasnoname> Those are all being held back, in addition to the linux-generic packages that were previously held back. Any clue on specifics?
<geser> lukehasnoname: it probably wants to add or remove packages
<persia> lukehasnoname, Try running aptitude or synaptic or similar interactive tool to investigate.
<geser> "sudo apt-get dist-upgrade" and check very carefully what it wants to remove (or add)
<fabbione> morning guys
<lukehasnoname> ehh I already pushed ahead with apt-get upgrade. I'll still check that though.
<mvo> cjwatson: are you ok with http://paste.ubuntu.com/55921/ ?
<liw> mvo, in update-manager, you seem to be using gettext.gettext rather than gettext.install/gettext.translation. the latter is strongly recommended by the python stdlib docs. do you have a reason to prefer gettext.gettext?
<mvo> liw: no strong reason, that I what I used in C and I'm familiar with.
<liw> mvo, ack, that's a good reason
<mvo> liw: what is the advantage of using the alternative form?
<mvo> liw: is there something to read up? pydoc gettext seems to be not that informative
<liw> mvo, "more flexibility and greater convenience than the GNU gettext API" says file:///usr/share/doc/python2.5/html/lib/node732.html
<liw> mvo, the flexibility probably means just that the newer API allows easily switching between languages, or supporting several concurrently
<tseliot> pitti: I have fixed this bug in jockey, can you have a look at my branch? https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/280147
<ubottu> Launchpad bug 280147 in jockey "crash without interaction" [Undecided,New]
 * mvo waves to tseliot
<mvo> liw: aha, cool. thanks. I will keep that in mind :)
<tseliot> mvo: hi :-)
<liw> mvo, I'm not sure the "greater convenience" applies to modules, just for applications, but we'll see; since the new API is the recommended one, I'll do system-cleaner with it, and we can compare notes some day
<mvo> liw: sounds good!
<liw> I have found a surprising dearth of documentation on this
<mvo> liw: gettext in python? yeah, it seems that everybody just copies what he found other code. I find it also slightly anoying that gtk.glade needs its own bindtextdomain() calls (or at least it needed when I wrote the code)
<liw> mvo, I think I saw a note somewhere saying that it might not be needed anymore, but who knows... writing such a doc (or a patch to python's stdlib docs) would be a good upstream contribution
 * mvo nods
<cjwatson> mvo: hmm, disabling cancel altogether sort of worries me. Could you wrap that in an environment variable that update-manager sets for now, and send it upstream to see what Joey thinks of it?
<cjwatson> mvo: the rest is OK although would it be worth allowing GDK_FUNC_RESIZE and GDK_FUNC_MAXIMIZE too?
<cjwatson> mvo: oh, trivial things: there's some tab damage visible there, and debconf is in bzr (lp:~ubuntu-core-dev/debconf/ubuntu)
<StevenK> pitti: What do you think about bugs 281135 and 281144?
<ubottu> Launchpad bug 281135 in bluez-libs "Please remove bluez-libs from Intrepid" [Low,Confirmed] https://launchpad.net/bugs/281135
<ubottu> Launchpad bug 281144 in bluez-utils "Please remove the bluez-utils source from Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/281144
<cjwatson> liw: I think gettext.translation makes more sense for modules in the same way that C libraries using gettext need to use dgettext - it gives you separate control over the domain in use
<cjwatson> hmm, although python gettext offers dgettext too
<cjwatson> dunno then :)
<cjwatson> lifeless: lock shell script> there's a 'with-lock-ex' command in chiark-utils-bin
<mvo> cjwatson: thanks, I will forward it to joeyh and wrap it for now
<cjwatson> lifeless: or there's the lockfile-* suite in lockfile-progs; IME those are more annoying to use though
<liw> lifeless, I use lockfile(1) from procmail for locking in shell scripts
<nijaba> Hey there. Would you think that bug #150872 should be targeted for intrepid?
<ubottu> Launchpad bug 150872 in partman-target "Installer should not list removable media in /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/150872
<cjwatson> nijaba: no, it would break things if done for intrepid
<cjwatson> nijaba: removable media is listed for a good reason right now
<cjwatson> nijaba: apt-cdrom has no way to discover the CD drive dynamically
<nijaba> cjwatson: ok, thanks, might be worth mentioning the issue in the release notes then and usb-creator help/doc/whatever as well
<cjwatson> nijaba: Evan is already aware of the issue and it's possible that some minor hack just for USB could be possible
<cjwatson> but we can't just strip those lines out across the board.
<liw> static device names seem to be a problem in every case, these days
<cjwatson> mvo: btw, on that debconf patch, wouldn't it be better to attach a realize signal handler rather than calling realize?
<mvo> cjwatson: http://paste.ubuntu.com/55931/ <- updated version
<mvo> cjwatson: realize-handler> hm, good point
<cjwatson> so $this->win->signal_connect("realize", sub { $this->win->window->set_functions(blah); }) or something # TEST THIS
<mvo> if we continue this, I will actually lern perl along the way ;)
 * mvo adds it
<fabbione> cjwatson: do you remember on the fly what source/udeb has partman_devices ?
<mvo> cjwatson: thanks, works fine, if its otherwise ok I will upload
<pitti> tseliot: bah, this Python unicode() vs. UTF-8 handling keeps driving me nuts
<tseliot> pitti: is the error message handled by the kde ui?
<tseliot> kde or gtk
<pitti> tseliot: why is wrapping the string into unicode() the right fix here?
<pitti> tseliot: it looks like a wrong encoding in a translation to me?
<tseliot> pitti: kde uses QStrings
<pitti> tseliot: but this isn't KDE, this is just simple "print" to stdout
<pitti> stderr, but same thing
<tseliot> pitti: where do you take the error message from?
<cjwatson> fabbione: partman-base
<pitti> tseliot: self.string_unprivileged
<cjwatson> fabbione: it's parted_devices, BTW
<pitti> tseliot: it calls AbstractUI._("english string")
<fabbione> cjwatson: oh yes.. parted_devices sorry.. but i know you are much quicker than me there :) thanks
<cjwatson> pitti: if this is a Qt frontend, anything you get back from Qt as a QString tends to have to be wrappped in unicode() :(
<cjwatson> I ran into that in a big way in ubiquity
<pitti> cjwatson: that also affects the standard _() function?
<cjwatson> pitti: oh, or for printing to stdout, there is some really annoying stuff you have to do
<cjwatson> no, this is separate
<pitti> right, I assumed that much
<cjwatson> # Avoid having to do .encode('UTF-8') everywhere. This is a pain; I wish
<cjwatson> # Python supported something like "sys.stdout.encoding = 'UTF-8'".
<cjwatson> def fix_stdout():
<cjwatson>     import codecs
<cjwatson>     sys.stdout = codecs.EncodedFile(sys.stdout, 'UTF-8')
<cjwatson>     def null_decode(input, errors='strict'):
<cjwatson>         return input, len(input)
<cjwatson>     sys.stdout.decode = null_decode
<cjwatson> and then call fix_stdout somewhere
<pitti> I'll try to reproduce the error first, I guess
<tseliot> pitti: ok, wrong fix then ;)
<pitti> cjwatson: thanks; I think I saw that so many times already, but it still didn't settle in my brain
<tseliot> pitti: my previous commit is still useful though (to blacklist nvidia 71 and 96)
<pitti> tseliot: yeah, I'll merge that
<tseliot> ok
<cjwatson> pitti: see also http://ewx.livejournal.com/457086.html (read the comments)
<pitti> tseliot: hm, I don't get the crash with de_DE.UTF-8 (same as the reporter), and I get proper umlauts on stderr
<pitti> tseliot: with both the GTK and KDE frontends
<tseliot> pitti: it might depend on the locale. I had a similar problem with Envy with a Turkish guy
<pitti> tseliot: right, I know, but I'm using the very same locale as the reporter
<tseliot> ah
<tseliot> ok, it would be nice if we could reproduce the problem
<pitti> tkamppeter: I fixed the hpgl regression and uploaded 1.3.9 to debian and intrepid
<cjwatson> pitti: unfortunately python people don't appear to understand how encodings actually conventionally work in Unix and regard all this as not-a-bug
<pitti> too many MacOS X programmers amongst them? :-/
<tkamppeter> pitti, great, it contains also an important fix in pstops.
<cjwatson> specifically they don't understand that stream encodings are supposed to be set by the environment not (in some undefined way) by the terminal [even though in some entirely different ideal world the latter might be how it ought to work]
<tkamppeter> pitti, why does "bzr pull"W not show it?
<pitti> tkamppeter: I just pushed like 10 seconds ago
<cjwatson> and that there have to be ways to override it since the environment can be wrong
<tkamppeter> pitti, sorry, I was 1 minute too early
<cjwatson> actually, python does set stdout's encoding from the environment, but *only if stdout is a terminal*. This is clearly mad since putting | less after your program can cause it to stop working.
<pitti> indeed I just tried that, but it still works
<tseliot> pitti: is it worth catching the exception then? (not that I like it...)
<pitti> $ PYTHONPATH=. gtk/jockey-gtk --check 2>&1 |cat
<pitti> Sie sind nicht berechtigt, diese Aktion auszufÃ¼hren.
<cjwatson> it depends on your environment
<cjwatson> the reporter might have the locale set but not in fact have the locale generated, for example
<pitti> ah, that's a good thing to ask in the bug report
<cjwatson> I really would suggest just clobbering it with something like the rune I suggested above
<cjwatson> python is known-broken in this area and you have to set things explicitly
<cjwatson> if sys.stdout.encoding were writable it would be much more pleasant
<pitti> cjwatson: right, I just don't feel good about hardcoding UTF-8, since users might actually use an ISO, KOI-8, or whatever encoding in their locale
<cjwatson> pitti: use locale.getpreferredencoding() in place of 'UTF-8' then
<cjwatson> (I haven't tested that but I think it should work)
<pitti> this raises a severe deja-vu for me; I think I got that like half a year ago in apport
<cjwatson> pitti: confirmed, http://paste.ubuntu.com/55934/
<cjwatson> you might want to do the same for stderr
<pitti> cjwatson: nice, thanks!
<pitti> StevenK: hm, those are duplicates?
<pitti> StevenK: looking at checkrdepends bluez-libs intrepid
<YokoZar> So, a game I've been preparing for Intrepid for some time (Spring) just made a release, and I have a package ready.  Is there still enough time to upload it to Intrepid, or will it be rejected?  (this is a completely new package)
<persia> pitti, Note that libbluetooth3 is now provided by the bluez source.
<persia> YokoZar, It's decidedly late.  you might appeal to MOTU SRU, but it's unlikely.
<pitti> -- intrepid/universe i386 deps on libbluetooth2:
<pitti> ussp-push
<pitti> and some in main/universe on eternally-lagging hppa
<ogra> mvo, 0.7.8 didnt fix it for me :/
<StevenK> pitti: Yup, ussp-push is the last one
<StevenK> I fixed the rest today
<pitti> however, there are a couple of more unfixed things in bug 276343
<ubottu> Launchpad bug 276343 in ussp-push "Rebuild for libbluetooth2 -> libbluetooth3 transition" [Undecided,Fix committed] https://launchpad.net/bugs/276343
<pitti> StevenK: so once the transition is complete, then the package can go, sure
<pitti> but it seems most of them should be closed?
<StevenK> pitti: Yeah, most of the bugs should be sorted. I forgot to add the bug number to the my buildX uploads
<StevenK> Hmmm
<StevenK> Should do this through the mail gateway
<pitti> it just occurred to me that our gnutls13 -> gnutls26 transition is still outstanding, too
<pitti> *sigh*
<pitti> otherwise we'd again have two gnutls versions in stable
<StevenK> What's needed for that?
<persia> That's a bundle, including curl
<StevenK> Whee
<StevenK> pitti: Let me finish dealing with bluetooth first
<pitti> I am just doing process-removals, and that reminded me
<StevenK> Ah
<persia> Is there any good tool that could identify transitions underway?  While completing them all is maybe hard, having a list would be a good start.
<StevenK> persia: NBS, mostly
<persia> StevenK, That only covers cases where there isn't a source name transition.  I'm wondering if just checking packages that build-depend against a given -dev have binaries that depend on the associated lib.
<pitti> the gnutls13 source is still there, so that won't appear as NBS
<persia> Same for bluetooth, or other stuff
<StevenK> pitti: Right, but we have rdepends
<pitti> StevenK: you know checkrdepends?
<StevenK> pitti: Of course
<StevenK> Right, that mail should set everything aside from ussp-push to Fix Released.
<StevenK> Where the ussp-push source has gone, I don't know
 * pitti needs to run out for some errands, bbl
<ScottK> asac: About NM, not on purpose I don't use a hybrid setup.  Everyone who tried it (there were three of us, IIRC) saw similar issues on Kubuntu.
<asac> ScottK: hybrid == /etc/network/interfaces has a configuration ;)
<ScottK> asac: It says auto eth0.  Does that count?
<asac> ScottK: if there is no iface eth0 ... line then it shouldnt
<ScottK> Nope
<ScottK> The only iface line I have is for lo
<asac> ScottK: please paste your route -n output when you see these packet losses
<ScottK> OK.  Will do.
<asac> ScottK: i have received other complains, but couldnt reproduce here except for a hybrid setup
<asac> ScottK: for me "wired" interfaces always have a metric/prio of "1" and wireless have a metric/prio of "2"
<mvo> could some native speaker/UI expert review those strings: http://paste.ubuntu.com/55942/ ? its for the upgrade note about the new fusa applet that replaced the logout button
<asac> which should tie-break the path the packages travel - assuming that both interfaces provide a route to the same net
<ScottK> OK.
<asac> ScottK: are you using NM 0.7 on intrepid right now? if so, please post the routing right away :)
<asac> (even if you dont see the package loss right now9
<StevenK> asac: gnash is still on your list, right?
<ScottK> asac: Will do
<ScottK> asac: In the bug or pastebin?
<james_w> mvo: http://paste.ubuntu.com/55946/
<mvo> james_w: excellent, thanks! is the text ok? understandable etc?
<james_w> mvo: "got" -> "has been", "on the standard location" -> "in the standard location"
<james_w> mvo: yeah, but you might want a UI review if you can find somebody
<mvo> james_w: I will try, I had hoped that mpt is around
<ScottK> asac: I added it to Bug #280919
<ubottu> Launchpad bug 280919 in network-manager "NetworkManager 0.7~~svn20081008t224042-0ubuntu1 breaks Knetworkmanager" [Medium,Incomplete] https://launchpad.net/bugs/280919
<james_w> mvo: yeah, is seele around?
<james_w> does anyone know if it's possible to get rmadison to really show me just source records. It seems to recognise "source" as an architecture, and has a "source and binary" option that I'm not selecting, but it still shows me all architectures.
<james_w> looking at the php it seems to proxy directly to "dak ls" calls
<mvo> ogra: what video driver is this?
<ogra> mvo, intel
 * ogra goes to debug it more
<ogra> might be gpm
<ogra> or just a bug in xorg wrt dpms
<cjwatson> james_w: it actually proxies to madison-lite for us; it's probably a madison-lite bug if it doesn't work. That said, 'rmadison -a source linux' seems to DTRT. What's your example?
<james_w> cjwatson: ah, I was running against Debian
<james_w> it does indeed seem to work for Ubuntu
<asac> ScottK: thanks. the routing looks fine. but as you said in the bug you didnt have problems with that?
<cjwatson> james_w: ahright
<ScottK> asac: Yes.  Riddell just reported he has no wired connection either right now.
<cjwatson> it's rather unusual for madison-lite to work *better* than dak ls ...
<asac> ScottK: ok. you dont see an AP ... but thats a different issue (if not a general knetworkmanager bug)
<ScottK> So I think there is a real problem here, not sure exactly what as I couldn't replicate the laggy behaviour I saw yesterday.
<asac> ScottK: you could try to load iwl4965 with disable_hw_scan=1 ... and see if you get more reliable scans
<liw> davmor2, rumor tells me you have an acer aspire one... does it require non-free drivers?
<ScottK> Could be.  Others have no wired at all, so don't take my success as meaningful.
<asac> (but thats a different bug)
<Riddell> actually my eth0 seems to have disappeared completely
<asac> ScottK: others == users that currently see this problem?
<ScottK> I think that's probably unrelated
<Riddell> dmesg doesn't show it
<davmor2> liw: I do indeed, goes and double checks
<ScottK> asac: Yes.  Riddell and regreening at least.
<asac> Riddell: e1000?
<asac> ;)
<asac> Riddell: if you see packet loss please put your route -n to the bug
<Riddell> asac: fortunately not
<asac> Riddell: if eth0 is gone its obviously a driver issue. if wireless is the only iface used, its unlikely that slowness is a NM problem
<asac> at least ii dont see how it could be :/
<Riddell> I have no eth0 but I have something called pan0
<asac> Riddell: but that doesnt show up in NM right?
<asac> Riddell: pan0 :(
<Treenaks> Riddell: pan0 is bluetooth-related
<asac> Riddell: hal-find-by-capability --capability net.80203
<Riddell> oh.  bluetooth.
<asac> if that doesnt show up anything then NM cannot know your wired
<asac> for wireless its: hal-find-by-capability --capability net.80211
<Riddell> asac: that shows up nothing indeed
<asac> for 3G mdoem its: hal-find-by-capability --capability modem
<Riddell> the wireless one shows something
<asac> Riddell: yeah. what chipset has your wired?
<Riddell> 00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection
<Riddell> "Kernel modules: e1000e"  erk
<asac> ha ;)
<asac> i knew it :-D
<asac> wasnts e1000e fixed?
<asac> Riddell: is that driver loaded (e.g. lsmod | grep e1000) ?
<persia> Yes, but the key to restore broken firmware wasn't pushed (IIRC)
<asac> oh ... so Riddell has a broken firmware ;) ... not that cool
<Riddell> asac: yes
<Riddell> shows how often I use ethernet
<asac> Riddell: ok i think you should talk to rtg
<asac> Riddell: and your wireless issues are?
<Riddell> asac: my wireless is all good
<asac> ok. then there is no NM regression at least :)
<Riddell> well other people have troubles we havn't got to the bottom of yet
<liw> if I add translatable strings to my code, the .pot file needs updating; do I just re-create it from scratch using xgettext or what?
<cjwatson> gettext supplies a Makefile that can do it
<liw> /usr/share/gettext/intl/Makefile.in?
<cjwatson> you don't want to copy it around by hand if you can help it ...
<liw> or possibly /usr/share/gettext/po/Makefile.in.in, hmm
<liw> cjwatson, yeah, I really really don't want hundreds of lines of excessively complicated Makefiles :)
<cjwatson> I guess you aren't using automake
<liw> this is for a Python program, so no
<cjwatson> you could use gettextize
<cjwatson> and see what it does and whether you can massage the result to be acceptable
<cjwatson> usually you just leave its results in po/ and forget about it
<cjwatson> to directly answer your original question, it ultimately comes down to recreating it using xgettext and using msgmerge to update the .po files
<liw> . o O (someone needs to document this really well)
<cjwatson> info gettext
<liw> cjwatson, I have been reading that, and I find it to be confusing
<cjwatson> while I sympathise with a detestation of autogenerated Makefiles, in this case it is orders of magnitude less wasted time than doing it by hand, IME
<liw> might be because it's a complicated process, of course
<liw> cjwatson, that's possibly true, but then I need to deal with the massive headache of keeping the autogeneration of the Makefile working
<cjwatson> I find that easier than keeping the .pot/.po files working without that
<liw> gettextize won't work without autotools being used, it seems
<cjwatson> you could look at how debconf does it
<cjwatson> it has a by-hand Makefile for this
<cjwatson> copying somebody else's by-hand work is probably easier than duplicating it :)
<liw> I return to my point that someone needs to document this well :)
<liw> as far as I can see, there needs to be something that updates the .pot file with new strings (and removes old ones?), then based on that updates the .po files (adds missing strings, marks changed strings as fuzzy?); that doesn't sound like it should require autotools or hordes of Makefile magic
<cjwatson> update .pot files with new strings => xgettext; update .po files => msgmerge; you also need something to compile .po to .gmo files; you might want to support 'make install' and/or 'make dist'; sometimes people want to disable i18n or enable only certain languages; and some people want to support systems where GNU gettext is not already installed
<cjwatson> also some maintainers only want to rebuild .pot manually rather than automatically
<cjwatson> or want to update it only if the .pot changed non-trivially (i.e. more than just the creation date or whatever)
<cjwatson> (which avoids vcs noise)
<liw> are .gmo files the same as .mo files or is this some fourth type of file?
<cjwatson> once you do all of that you're actually not that far off the complexity of gettext's po/Makefile.in.in
<cjwatson> info gettext C-s gmo
<liw> ack, they're gnu's extended and embraced version of .mo, good :)
<liw> cjwatson, all that complexity could surely be wrapped in tools less awful than autotools, I'm sure; anyway, I don't want or need most of the complexity, so I'll go some simpler route
<mvo> liw: check out python-distutils-extra if you look for something that does the i18n in system cleaner
<liw> mvo, that looks like useful for the parts that are involved in installing the .mo files; does it take care of generating the .mo files from .po files, too?
<mvo> liw: yes
<liw> cool
<mvo> liw: it should do all that is required, if not, file a bug against it
<mvo> (or let glatzor or me know about the problem)
<liw> mvo, is it also involved in updating .po files from .pot?
 * liw goes read docs
<mvo> liw: yes, it should do all that, check gnome-app-install setup.cfg and setup.py for a example
<mvo> liw: + po/POTFILES.in and you should be done
<mvo> liw: it also supports desktop files and desktop file i18n
<asac> Riddell: if people have troubles ask them if they are running a hybrid setup (meaning: 1 device managed in /etc/network/interfaces and the other in NM)
<Riddell> asac: right
<asac> Riddell: that setup is know to have metric issues i still have to sort somehow
<liw> mvo, "setup.py build_i18n --merge-po" seems to require a po/POTFILES.in, which does not support wildcards; is that intentional?
<mvo> liw: po/POTFILES.in is required, not sure about the wildcards, it uses intltool internally, not sure if that supports them or not (I guess not if you have problems with it)
<liw> mvo, ah, so it's just intltool-update that uses that, ok
<mvo> liw: yeah, its just a (thin) wrapper around the intltool* stuff
<alkisg> mvo, has anyone reported that in intrepid beta update-manager  doesn't *ever* close itself but just hangs in the "ldconfig deferred processing" phase?
<mvo> alkisg: yes - that bug is milestoned
<alkisg> (ogra told me to tell you, he also saw that yesterday)
<ogra> mvo, ah, great, i wasnt sure
<mvo> bug 280236
<ubottu> Launchpad bug 280236 in update-manager "update-manager --dist-upgrade gets stuck at the end" [High,Triaged] https://launchpad.net/bugs/280236
<ogra> mvo, btw i just removed gnome-screensaver and still see the issue ... i'll run a dbus-monitor session now to see if there are any events keeping it from proerly doing dpms
<alkisg> mvo, ogra, thanks.
<mvo> ogra: oh, that is interssting
<liw> mvo, yay! ./usr/share/locale/fi/LC_MESSAGES/systemcleaner.mo
<mvo> liw!
<Treenaks> Does anyone know from which package network-manager(-gnome?) gets the available UTMS/GPRS network list?
<Treenaks> I can't find it in network-manager{,-gnome}
<alkisg> mvo, and another somewhat serious one, gparted (and the installer) can't create smaller partitions on empty disks (tried on different 3 PCs). I had to create 1 full-disk partition, shrink it, then create others and then run the installer...
<mvo> alkisg: oh, is that reported already?
<alkisg> mvo, I saw something similar reported, but only for the installer, not the backend lib which is used (and I think the fault is there... libparted is it?)
<cjwatson> alkisg: I've never heard of such a bug (I co-maintain the installer); it must be hardware-specific. Can you refer me to the bug number?
<alkisg> It's usually reported as ubiquity crashed, with auto-collected debug data
<alkisg> I've sent one myself, and was considered a duplicate
<alkisg> let me find it...
<cjwatson> I'm not sure why that would be a crash, unless there's something more than what you described above
<lool> liw: Good :)
<lool> liw: Do you need sponsoring for system-cleaner with i18n?
<liw> lool, when it's done, yes
<alkisg> This is the main one: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/260001 (I think it's the same symptoms as mine),
<ubottu> Launchpad bug 260001 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader()" [Undecided,New]
<cjwatson> configure_bootloader has nothing to do with creating partitions!
<alkisg> And this one's mine: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/278019
<ubottu> Launchpad bug 278019 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader() (dup-of: 260001)" [Undecided,New]
<alkisg> cjwatson, read mine, I'm not really sure if they're the same
<cjwatson> this sounds like the problem where libparted sometimes forgets to change the partition type
<alkisg> cjwatson, yes, that's what I got
<cjwatson> I've tried to figure that out multiple times and haven't got anywhere; I can give it another shot, I suppose
<cjwatson> describing it as "can't create smaller partitions on empty disks" is a bit overly broad though :)
<cjwatson> it only happens if you're creating the partition at the same position as something that used to be NTFS
<alkisg> But I also tried (in another system) to just create an ext3 partition with 100Gb size (disk = 640Gb), and it couldn't. Not the installer, not gparted.
<cjwatson> alkisg: that's a different problem and I'd like to know about it
<cjwatson> (with logs etc.)
<cjwatson> seriously, I create partitions less than the size of the disk all the time :)
<alkisg> cjwatson, ouch, this morning I've setup the system, and it's on a lab I'm not responsible for...
<cjwatson> although not on 640GB disks; it could be an overflow of some kind
<alkisg> It has 2 disks, I'll remove one and reproduce it, but I can only do it next weekend. Is this ok?
<cjwatson> it'll have to be :)
<cjwatson> thanks
<alkisg> thank you guys.
<cjwatson> I'll see if I can replicate the NTFS partition type thing today
<Treenaks> (answer to my question: libmbca + mobile-broadband-provider-info)
<AnAnt> Hello, how can I make some look at a bug that was filed a month ago: bug #267217
<ubottu> Launchpad bug 267217 in compiz "Compiz segmentation faults after Intrepid update" [Undecided,New] https://launchpad.net/bugs/267217
<AnAnt> ?
<Laney> *make* someone?
<kwwii> first he'd have to find me :p
<asac> is intltool really not installable on hardy amd64 ;)? my NM ppa build thinks it cannot install it :/
<kwwii> seb128: I just put some new packages in my ppa: ubuntu-wallpapers, human-theme, and ubuntu-artwork
<kwwii> seb128: so once they are tested a bit I will be bugging you :-)
<kwwii> seb128: if nothing crazy happens these will be the last updates
<Keybuk> killall pulseaudio
 * Keybuk makes the world a better palce
<ogra> haha
<Keybuk> it was doing that thing where no other application can start, again
<seb128> kwwii: ok
<ogra> seb128, btw, the volume control applet and brigthness are applet not closing their rulers anymore by default, is that a upsteam decision ?
<ogra> meh
<ogra> seb128, btw, the volume control applet and brigthness are applet not closing their rulers anymore by default, is that a upsteam decision ?
<seb128> ogra: dunno about the brightness but the volume one is an upstream choice
<ogra> (you need to click the applet again to close it)
<Treenaks> ogra: instead of working menu-like, you mean?
<ogra> while i appreciate it on mobile because its helpful if you dont hit the rules first time with your finger, i find it pertty annoying on laptop/desktop
<ogra> *ruler
<ogra> Treenaks, yep
<seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=553249
<ubottu> Gnome bug 553249 in mixer "Dock windows dangle when the panel autohides." [Normal,Unconfirmed]
<ogra> doesnt look like anyone will fix it in time, thats indeed quite bad with autohiding
 * ogra personally just saw it as an annoyance he could live with, just wanted to know it was intentional
<ogra> mvo, sooo, removing gpm fixes the issue, looking at the log i see xorg loads DPMS for the intel driver, i guess we have a concurring situation between xorg and gpm both wanting to handle DPMS (we had that before)
<ogra> tjaalton, ^^^
 * ogra will now try to put something in place that unsets DPMS for X and instal gpm again and see if that fixes it as well to prove that
<tjaalton> ogra: xset -dpms
<ogra> tjaalton, ah, right, i was starting to play with hal-set-property stuff in gdm Init :)
<ogra> thast easier indeed
<ogra> and probably more effective as well :)
<mvo> thanks ogra, could you please add that to the bugreport?
<ogra> mvo, if i'm sure ...
<ogra> i just remembered that clash from before, i'm not sure yet that it is the cause, and compiz surely plays a role as well, as switching to metacity solves it
 * ogra twiddles thumbs waiting for gpm
<ogra> hmm
<ogra> no gpm reaction ...
<ogra> hah, now it kicked in
<ogra> mvo, so "xset -dpms" makes it work ...
<ogra> tjaalton, can we default to have the driver not using it ?
<ogra> though i guess that gets us probs in gdm
<persia> If the issue only happens in a compiz session, perhaps compiz could xset -dpms ?
<ogra> yeah, hat sounds sane
<ogra> *that
<jcristau> actually it doesn't
<persia> jcristau, I trust you more than I when it comes to X.  Why is it not sane?
<jcristau> maybe i just don't understand the problem though..
<ogra> jcristau, the driver wanting to set xorg dpms values concurring to gpm wanting to do the same
<persia> But only with compiz?  With metacity, this issue doesn't exist?
<tjaalton> DPMS in xserver has been enabled by default two years ago
<Treenaks> ogra: (is this gpm the console mouse thing?!)
<ogra> persia, right
<ogra> Treenaks, gnome-power-manager ...
<Treenaks> ogra: ah, sorry ok :)
<emgent> evening
<ogra> jcristau, we had that prob before though at times where dpms was handled by gnome-screensaver, that functionallity moved over to gpm within the last year
<jcristau> i think it'd be more sane to understand the bug and fix it than to disable dpms..
<ogra> you dont disable it
<ogra> gpm stil cares, you just move the trigger out of X
<persia> Well, you're disabling it in X, and expecting something else to handle it.
<ogra> right
<jcristau> there's an interface for that in some extension, iirc
<persia> On the other hand, if X is doing it, and doing it right, perhaps it makes more sense for other things not to do it.
<ogra> persia, that would mean to hack up hal/gpm
<ogra> either hal/gpm is broken in combo with compiz and dpms or X is ...
<ogra> well
<persia> ogra, Indeed.  Something is the culprit.
<ogra> s/X/the intel driver/
<jcristau> the driver, really?
<ogra> i dont care on which side we fix it, atm i'm just trying to nail down the issue properly :)
<persia> :)
<ogra> jcristau, it could as well be that gpm or hal dont use the right backend interface ...
<ogra> if you say there is an interface
<ogra> all i can say that switching off either of the dpms handlers fixes the issue
<ogra> +is
<jcristau> they probably do, if it works without compiz
 * ogra looks at compiz plugins
<pitti> zul: was linux-xen really meant to be uploaded to intrepid? It's version number is 2.6.27-1~ppa2
<zul> pitti: no it wasnt
<pitti> zul: if it was a dput error, I can just reject it; if it was deliberate, please fix the version
<pitti> ah, ok
<zul> misfire on my part
<pitti> alright, saves me some reviewing :)
<pitti> zul: thanks
<zul> np
<pitti> so, I accepted libv4l source and binaries in the same publisher cycle; kees, what's necessary now to make v4l work again?
<StevenK> pitti: Ah, since you're here. Now do we want to kill gnutls13 dead, or just demote it to universe?
<pitti> StevenK: oh, everything in main uses 26 now?
<StevenK> pitti: No, there's a bunch of stuff in main that uses 13
<pitti> StevenK: I'll demote it for now; if someone wants to do the work of completing the transition, that would be good, but not really critical
<StevenK> pitti: All up, it's 59 source packages, main + universe
<persia> I think we should target getting it killed completely.  Orphans in universe tend to get the least possible support.
<pitti> should be like 5 or 6 packages in main
<ogra> hmm, nothing in compiz touches dpms
<pitti> persia: true that
 * StevenK checks
<pitti> StevenK: I just finished doing new, I'm fine with doing the transition for main right now
<pitti> oh, erm, cjwatson, do you know whether we have a release meeting today?
<StevenK> pitti: Meh, I have a script that can do and upload it in about 5 minutes.
<pitti> StevenK: oh, ok, please do that then :)
<StevenK> pitti: Longer if you'd rather test them and confirm they don't pull in 13
<pitti> StevenK: I don't want to stop you, just wanted to take some bits off your shoulders
<StevenK> Shrug
 * lamont mutters at NCommander that yes, the current thinking is that there is a bug in the NPTL/hppa implementation
<StevenK> I *like* doing NBS
<cjwatson> pitti: as far as I know; it's on the calendar
<pitti> StevenK: ok, please go ahead then; seems I need to prep for the meeting, and I still need to do SRU, too
<pitti> StevenK: that's 59 binaries, sources looks more like 30
<StevenK> I had it has 59 sources
<pitti> hm, maybe
<StevenK> 9 sources in main
<pitti> StevenK: anyway, gnutls13 and opencdk10 were removed from Debian long ago, so if anything breaks, they have the patches
 * ScottK supports persia's suggestion about killing it.
<pitti> agreed
<james_w> I think 13->26 might have been one where the API changed but the -dev package didn't change name because the fallout was small
<pitti> right, it stayed libgnutls-dev
<persia> james_w, That would mean we have about 60 packages that might FTBFS.  Let's try to get them all updated by Monday.  Between StevenK, ScottK, pitti, you, and I we ought be able to do it.
 * StevenK has the list
<james_w> persia: let me find the transition bug first
 * StevenK is about to deal with main
<pitti> agreed; upload them all wholesale, and then collect the pieces which broke
<StevenK> All sixty of them?
<james_w> persia: that should tell us what did in Debian, and whether we have the fixed packages
<ScottK> Sure.
<StevenK> Okay
<StevenK> I can do that soonish
<mvo> ogra: I suspect it might be because compiz switches on some 3d stuff that then makes the dpms more sensitive or something
<pitti> StevenK: it might be worth going through them and compare if Debian just has a new revision; then we should sync instead
<persia> StevenK, Thanks.  And the rest of us will look at FTBFS fallout, and help port.
<ogra> mvo, yeah, might be
<james_w> pitti: did libv4l go to main?
<StevenK> pitti: That's a little harder
<pitti> StevenK: unless they did something weird, of course
<ogra> mvo, at least in gpm there were no changes to dpms since nearly a year according to the changelog
<pitti> james_w: no, universe; is there an MIR for it already?
<StevenK> pitti: It's very easy for me to bump them buildX
<StevenK> to buildX
<pitti> StevenK: ok, do that then; we can check for syncs for the ones which FTBFSed
<StevenK> Right
<james_w> pitti: I don't think so, so that would be the next step
<StevenK> It's a little more work, but not much
<StevenK> I'm just going to assume they build
<pitti> StevenK: ok, convinced
<StevenK> Using changelog entry of "No-change rebuild for libgnutls13 -> libgnutls26 transistion."
<StevenK> Unless james_w finds a bug first
<james_w> give me two minutes, I should be able to
<StevenK> james_w: If I put the bug number in the changelog entry, the janitor will try and close tasks for each of those packages in that bug
<StevenK> I'm also ignoring gnash, since I know it FTBFS, and asac will update it.
<james_w> http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2008-May/001420.html
<james_w> lynx is usually the pain
<asac> StevenK: it should work ... try: bzr branch lp:~gnash/gnash/ubuntu.head; cd ubuntu.head; ./debian/build_head
<StevenK> I was talking about 0.8.2-0ubuntu3
<james_w> StevenK: but I can't find a tracking bug, so please go ahead and we'll work with the fallout
<StevenK> james_w: Aye
<StevenK> I can make a bug
<persia> StevenK, Why not only put the packages that FTBFS in the bug, due to the "Can't unsubscribe" bug in LP.
<StevenK> persia: That works
<StevenK> I'll make a bug of the ones that FTBFS
<persia> Please subscribe the rest of us to it :)
<StevenK> Heh, yes
<ScottK> Also subscribe NCommander to it.  He loves FTBFS.
<StevenK> asac: Or I can just upload the bzr head of gnash to intrepid :-P
<persia> Hrm.  Maybe just subscribe cruft-busters : that's most of us, and includes other interested parties.
<StevenK> persia: Good point
<james_w> StevenK: subscribe me (james-w) as well please
<persia> james_w, You're not a cruft-buster?
<james_w> nope
<cjwatson> bryce: 207881 recently got reopened and is on the release-critical list
<cjwatson> TheMuso: are you on top of 204272? it has zillions of duplicates and looks serious
<ogra> kwwii, whoops, you renamed NewHuman ?
<StevenK> pitti, persia, james_w, ScottK: Uploading
<pitti> go, StevenK, go :)
<persia> StevenK, Thank you :)
 * StevenK grins
<persia> Puts you over 200, doesn't it?
<StevenK> persia: Or very close ot
<StevenK> s/ot/to/
<cjwatson> bryce: 274045 appears to have a patch, if you haven't seen it
 * StevenK pushes packages uphill
<ion_> Does anyone feel like sponsoring http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
<ubottu> Launchpad bug 278195 in gnokii "Incorrect encoding for the synchronized entries" [Undecided,New] https://launchpad.net/bugs/278195
<tjaalton> cjwatson: upstream doesn't test with old chips, so regressions are possible
<StevenK> Haha
<StevenK> curl has already failed on sparc
<StevenK> Right, curl has also failed on lpia and powerpc, so we have our first victum
<StevenK> Er, victim
<StevenK> configure.ac:105: required file `./config.guess' not found
<StevenK> configure.ac:105: required file `./config.sub' not found
<StevenK> Sigh
<tjaalton> wha-at, we have nouveau now?
<ogra> looks like :)
<persia> nifty
<bugabundo_work1> ogra: hi
<tjaalton> well, AIUI it doesn't even build
<tjaalton> libdrm-dev(inst 2.3.1-0build1 ! = wanted 2.3.1+git+20080706+401f77a-1)
<tjaalton> hehehe
<bugabundo_work1> ogra: ping
<ogra> tjaalton, well, someone synced it (looks like slangasek )
<ogra> bugabundo_work1, yes ?
<persia> RAOF, Can this be made to work?
<bugabundo_work1> ogra: can you help filipegarcia with his touch device?
<filipegarcia> hello
<ogra> probably, lets take that to #ubuntu-mobile though
<bugabundo_work1> maybe we can go to another #... its kinda offtopic here
<bugabundo_work1> ok ogra... thanks
<filipegarcia> yes
<filipegarcia> thank you
<tjaalton> persia: not without a newer libdrm and drm modules for the kernel
<persia> tjaalton, That was my previous understanding, but I figured that the maintainer of the nouveau PPA would probably have some idea why we have a nouveau sync :)
<StevenK> superm1: Can you track down ussp-push at some point, it's only thing left for bluetooth
 * StevenK goes to bed. I'll deal with fallout from build failures in the morning
<aliases123> hi um. this might be unrelated but i thought i would raise this anyway here.... some of the pdfs http://www.ubuntu.com/system/files/u35/Openbravo-final.pdf has the title microsoft powerpoint at the top.
<aliases123> i'm considering filing a bug.
<radix> mvo: hi, can I bug you to take a look at a smart patch?
<asac> mdke: there? -> http://people.ubuntu.com/~asac/3g-wizard-screenshots/
<tjaalton> persia: I'm trying to find the bug number..
<mvo> radix: sure
<radix> mvo: it's bug #279343
<ubottu> Launchpad bug 279343 in landscape "Small smart fixes need to go in the Intrepid package" [High,In progress] https://launchpad.net/bugs/279343
<radix> mvo: it's a debdiff to include an upstream version 1.1.1, which are some fixes that are important for the usage by landscape
<radix> (but they're general bug fixes, not really specific to landscape)
<mvo> radix: reading it now
<radix> awesome, thanks
<mathiaz> mvo: could you review the branch I've pushed for bug 84918?
<ubottu> Launchpad bug 84918 in unattended-upgrades "package should set up sensible config" [High,Triaged] https://launchpad.net/bugs/84918
<mvo> mathiaz: will do, its on my list for today
<mathiaz> mvo: great - thanks !
 * mvo just needs to finish a update-manager upload
<tseliot> mvo: will my script be included too?
<pitti> mdz: TBH, I'd just upload the g-p-m fix; easy enough to revert if it causes regressions...
<mdz> pitti: ok
<mdz> pitti: done
<pitti> mdz: do you want to send the CFT, or shall I take that?
<mdz> pitti: if you could do it, I would be grateful, as my wrists are quite sore already after yesterday
<pitti> mdz: no problem, consider it done
<mdz> pitti: I just saw the "new improved logout button" update-notifier action
<mdz> pitti:  but pressing "perform this action now" has no visible effect
<mdz> s/perform/run/
<pitti> mvo: ^ hmm; shouldn't gconf changes be visible immediately? or does it need a panel restart?
<mvo> Riddell: have you made up your mind about kdm-kde4 ?
<pitti> mvo: if the latter, mabye that can become part of the script?
<pitti> mdz: does killall gnome-panel update it for you?
<mdz> pitti,mvo: I just restarted my panel and it is still unchanged
<Riddell> mvo: mm, what was the question again?
<mvo> mdz: none at all? that is odd, it should present a dialog in both in success or failure case
<mvo> mdz: do you have /usr/share/gnome-panel/migrate-fusa-config.py ?
<mvo> mdz: is that 755 ?
<mdz> mvo: -rw-r--r-- 1 root root 2486 2008-10-10 13:47 /usr/share/gnome-panel/migrate-fusa-config.py
<mvo> Riddell: you mentioned earlier it should be purged on upgrade?
<mdz> good guess
<mvo> mdz: thanks, that explains it :/
<mvo> mdz: could you make it 755 and see if that makes it more happy?
<mvo> mdz: I will fix this here right away (and wonder why it worked for me)
<mdz> mvo: now I get a dialog: "no logout button found"
<pitti> mvo: locally built package, I figure
<mvo> mdz: aha! what does your panel look like? did you customize it before?
<mdz> mvo: I have added some applets
<mdz> mvo: but I have a fusa applet and a logout applet
<kees> pitti: what's left are the libv4l patches that have been collected for various applications -- I think pgraner and wouter attached details to the bug and sent to ubuntu-devel
<Riddell> mvo: kdm (in intrepid) and kdm-kde4 (in hardy) both contain /etc/kde4/kdm.  kdm in intrepid conflicts with kdm-kde4 in hardy.  will kdm-kde4 get removed first then kdm installed?  in which case purge is good
<mvo> mdz: it is (currently) very careful, if the logout button is in a different place than in the original config, it will fail. could you sent me a "gconftool --dump /apps/panel" please?
<mdz> mvo: it is at the upper right, and I doubt it has moved...
<mdz> mvo: but this is a very old install (upgrade from Debian) so anything is possible
<mdz> mvo: emailed
<mvo> mdz: the gconf dump will tell me I think. I can make the checks less strict I think
<pitti> mdz: CFG sent
<pitti> mdz: CFT, too
<mdz> pitti: thank you
<mvo> Riddell: hm, I'm not 100% sure
<pitti> mvo: can we replace the logout applet with fusa regardless of its position?
<Riddell> mvo: lets not purge then
<mvo> Riddell: ok
<mvo> pitti: yes
<Riddell> I'll make sure to test upgrades do the right thing with init scripts and updating /etc/kde4/kdm
 * pitti doesn't envy the buildds now; they got StevenK'ed (gnutls), doko'ed (hardy SRUs for gcc/gcj/gnat), and will now be ArneGoetje'd (langpacks)
 * jdong is having his dreams of a non-X11-attached trackerd shattered
<jdong> is there a way to start dbus-daemon properly at the CLI?
<superm1> wgrant, have you already looked to see if bryce's patch to GPM improved the situation on your hardware?  my mirror will be lagging by a day once it's done building
<luisbg_> superm1, <ScottK> Kudos for superm1 for the work he's done so far, but we're still at zero bluetooth capability in KDE currently.
<luisbg_> a few minutes ago in #ubuntu-meeting
<mvo> pitti: http://paste.ubuntu.com/56025/ is the current text for the notification - do you think there should be more?
<mvo> mpt: : I would like your opinion on http://paste.ubuntu.com/56025/  and suggestions for improvements :)
<mpt> "functionality", eh
<superm1> luisbg, what meeting is going on in there right now?
<mvo> mpt: not a good word?
<mpt> mvo, no
<pitti> cjwatson: I'll change the jockey handler to succeed and display itself only if the version > 2:8.532, FYI; then it will auto-fix itself once we put a fixed one into intrepid-updates
<mpt> mvo, why are we even asking this question?
<mpt> If we weren't confident that it's a better design, we shouldn't be doing it at all
<mvo> mpt: that is a long story, basicly because we don't want to mess with the users configuration automatically without further questions. and also because people might have shared /home paritions where this change breaks when they boot a older version (or a different version) of linux
<mpt> mvo, hang on, I need to yell at Ted about this, brb
<mvo> mpt: pitti and tedg have more background on this, I'm little more than the messenger
<pitti> cjwatson: oh, except that jockey is currently too dumb to do that; but well, we'll need a jockey SRU anyway to add the -modaliases dependency, so it wouldn't actually help
<mvo> mpt: haha
<stefanlsd> Anyone working on bug #274049
<ubottu> Launchpad bug 274049 in ubuntu "after an sudo apt-get dist-upgrade in Intrepid I have this problem" [Undecided,Confirmed] https://launchpad.net/bugs/274049
<pitti> mvo: I think it should also say "Please note that after that, your configuration will not work any more with earlier Ubuntu releases."
<stefanlsd> heh. not the best description :)
<cjwatson> mpt: the shared /home thing really is important, and is hard for the software to know about
<mvo> pitti: right, that needs to be in too, maybe mpt can come up with a more positive wording for it
<mpt> ok, so it's not a new improved logout button, there is no longer a logout button...
<pitti> there is, it just became less useful
<mpt> There is? Why? What does it do?
<dholbach> stefanlsd: updated the bug
<dholbach> stefanlsd: nothing life-threatening
<stefanlsd> dholbach, cant log into my X
<dholbach> stefanlsd: I don't think that's related
<seb128> mpt: why? because upstream has applets to open the 2 dialogs they use
<mpt> I don't understand
<mpt> Ted just told me that the logout button is not an applet, it's compiled into the panel
<ogra> yep
<mpt> so if we're removing it from the Intrepid version of the panel
<mpt> then we don't need to change anyone's configuration at all, it just won't appear in Intrepid.
<bluefoxicy> Hey guys
<bluefoxicy> Scott Kaplan is willing to give a statement releasing the Wilson-Kaplan algorithm implementations as LGPL
<seb128> mpt: we don't want to remove the upstream code because it's creating divergence and some upstream guys like the upstream way and would be complaining if we were doing that in ubuntu
<bluefoxicy> these work much better than LZO for compressed memory
<ogra> mpt, and what would provide the logout button then ? note that fusa breaks in real multiuser setups like ltsp, most ltsp users i know deliberately remove fusa
<seb128> mpt: we don't use it but the code is still there
<mpt> ogra, the design is that Log Out, Shut Down etc are in the status menu *instead of* a Log Out button.
<mpt> So asking what the Log Out button is a non-sequitur.
<mpt> What the Log Out button should do, rather.
<ogra> indeed
<mpt> seb128, so why don't those upstream guys download and install the upstream version of gnome-panel instead?
<mpt> If they didn't say anything when Ted posted about our design originally, why are they trying to mess it up now?
<seb128> mpt: are you suggesting we want to discourage upstream hackers to use ubuntu?
<mpt> seb128, no, I just don't understand what they're proposing.
<seb128> mpt: there is a miscommunication there, that has nothing to do on the design, we just keep the upstream code available but don't use it
<mpt> I assume they're not proposing that Ubuntu offer two different panel items for logging out.
<seb128> mpt: upstream doesn't use any session or user switching on their gnome-panel layout
<seb128> mpt: they don't suggest anything for ubuntu
<mvo> even if we compile out the logout button we still need to think about setups without the fusa applet and have a way to auto add it there
<seb128> mpt: the green man launcher is an upstream object though
<mvo> e.g. I don't have fusa on my laptop and would be suprised if my logout button disappers
<mpt> mvo, sure, but that's what the upgrade script does, right?
<mpt> it ensures that the menu is there
<seb128> mpt: the issue there is upgrade, not new installs
<seb128> mpt: right, because we have been abusing the upstream object before to open a custom ubuntu session dialog
<seb128> mpt: now we dropped this session dialog so the object opens the upstream dialog
<seb128> mpt: we need to figure what to do what the object is in the configuration before upgrade
<seb128> mpt: is that clear?
<mpt> seb128, not show it when running Intrepid.
<wtgee> wow, the latest round of updates absolutely borked my comp
<mpt> (But still show it if, for example, using the same home folder with 8.04 or another distribution.)
<wtgee> Basically it killed all of gnome
<mpt> mvo, are you able to include illustrations in this question? That would really help
<mvo> mpt: sure, give me a sec, I can make a screenshot
<seb128> mpt: "not show it when running Intrepid.", that's what mvo's tool does basically
<mvo> mpt: http://people.ubuntu.com/~mvo/tmp/Screenshot-Untitled Window.png
<wtgee> Did anyone else just get borked on updates?
<mpt> mvo, http://paste.ubuntu.com/56038/
<tseliot> mpt: try with this link: http://people.ubuntu.com/~mvo/tmp/Screenshot-Untitled%20Window.png
<mpt> tseliot, thanks, I saw it
<mpt> (Deskbar FTW)
<mvo> mpt: the tools we have to show this can't handle inline images currently. sorry for this
<mpt> mvo, oh, what did you mean by including illustrations?
<mvo> mpt: I thought you wanted a illustration about what it looks like currently :)
<mpt> ahhh
<mpt> :-)
<tseliot> it won't look as good as in the screen shot but it's doable with debconf
<mpt> mvo, can you at least change the text? "Run this action now" is a bit dire
<mpt> the button text, I mean
<mpt> (and what does "Close" do?)
<mvo> mpt: that needs code changes, but it can be done.
<mvo> mpt: close closes the dialog
<mpt> Ok, so no illustrations, but the same text: http://paste.ubuntu.com/56040/
<bryce> slangasek, cjwatson: regarding the -fglrx issue (bug 247376), if it does come in post-release, there is the question of if we're going to go ahead with an SRU of it.
<ubottu> Launchpad bug 247376 in ubuntu-release-notes "undefined symbols when trying to load fglrx" [Undecided,Fix released] https://launchpad.net/bugs/247376
<Keybuk> bryce: I have a very strange error message when trying to run an X application
<mvo> mpt: ok, I start adding code to make the button configurable, but it will be "replace" and "close" I'm afraid. I put this on the list of things to discuss at uds so that we can make the whole thing more flexible
<Keybuk> "Maximum number of clients reached"
<cjwatson> bryce: we should just not promise that we'll do so
<cjwatson> bryce: that way we have the flexibility of deciding later
<Keybuk> quest scott% xterm
<Keybuk> Maximum number of clients reachedxterm Xt error: Can't open display: :0.0
<cody-somerville> Keybuk, I had that the other day
<cody-somerville> Keybuk, I had to restart to fix it
<Keybuk> this is the third of fourth time I've had it in the last few days
<mpt> mvo, ok
<Keybuk> since upgrading to Intrepid, basically
<bryce> Keybuk: yep there's a bug open on that; kees had run into it earlier.  Unfortunately not an easy thing to fix
<Keybuk> bryce: why is the maximum number so low?
<Keybuk> xlsclients says I have 28 (if I open one more xtern, I can't run xlsclients)
<kees> Keybuk: the number is 256; strange that you've hit it so quickly.  I wonder why xlsclients is lying to you so hard.
<bryce> Keybuk: I don't remember what the exact number is but it's considerably larger than that
<bryce> thousands iirc
<bryce> ok, not quite thousands ;-)
<mvo> mathiaz: merged with slight adjustment (10auto-update -> 20auto-update to win over 10periodic)
<kees> Keybuk: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/260138
<ubottu> Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Unknown,Confirmed]
<Keybuk> I was just looking at 263211
<Keybuk> which suggests gnome-screensaver is leaking client connections which it's marked as permanent
<mathiaz> mvo: great - thanks.
<Keybuk> xrestop does indeed say I have 255 clients
<Keybuk> whereas xlsclients clearly lies
<Keybuk> bug #263211
<ubottu> Launchpad bug 263211 in gnome-desktop "apps-wont-open-due-to-maximum-clients-reached-error" [High,Triaged] https://launchpad.net/bugs/263211
<Keybuk> Yes, I've been doing some debugging too, and in my setup gnome-screensaver is the culprit as well. Specifically it calls gnome_bg_create_pixmap() (from libgnome-desktop) with root == TRUE, which ends up creating a new connection to the X server, calling XSetCloseDownMode() to change to RetainPermanent, and then disconnecting. And in that case the X server keeps the client data structures around forever.
<Keybuk> slangasek: I'd like to raise this as Release Critical ?
<kees> Keybuk: ewwww
<slangasek> there's a maximum-client limit for X?
<slangasek> eew?
<cjwatson> Keybuk: I've approved the bug nomination
<cjwatson> eww> seconded, I never knew that
<Keybuk> I guess in the 70s you couldn't fit 256 windows in memory :P
<Keybuk> of course, the fact gnome-screensaver is consuming them all after just a day or so is doubleplusbadw
<kees> slangasek: I meant by "eww" in response to the leak, not the rc-request.  :)
<mathiaz> what's the state of autopkgtest? Is this still run?
<Keybuk> bryce: I don't suppose there's a way to tell X to free a client? :p
<persia> mathiaz, It hadn't been run at the time of the last QA Team meeting.  heno was looking into scheduling a run.
<slangasek> Keybuk: perhaps it's specific to your screensaver choice?
<Keybuk> slangasek: I'm using the F-Spot Photos screensaver iirc
<slangasek> I have a theory
<slangasek> :-)
<mathiaz> persia: ok - the dovecot package has some tests. But the ones in qa-regression-testing are newer/better. So I was wondering if the debian/tests/ could just be dropped from the package.
<bryce> Keybuk: not sure.  I'd use pkill myself ;-)
<Keybuk> bryce: there's no process for these clients
<persia> mathiaz, I'd rather not drop debian/tests, just because I'm a believer in robust QA, with many different ways of testing stuff.  On the other hand, if those tests are broken...
<Keybuk> slangasek: I just set the screensaver to blank screen, and activated it a bunch of times
<Keybuk> that seems to be still exhausting the clients
<mathiaz> persia: well - they're not broken AFAICT.
<cjwatson> mathiaz: all other things being equal, it's a better model to have tests in the packages themselves than in some separate repository (that has to be kept in sync as things change, etc.)
<cjwatson> mathiaz: so I think we should update debian/tests/ rather than removing it
<mathiaz> jdstrand: kees: ^^?
<mathiaz> does the current tests in q-r-t work with autopkgtests?
<kees> afaik, there is nothing actually _running_ the tests in debian/tests/, so it doesn't do any good there
<cjwatson> kees: that would just require starting up autopkgtest again
<kees> they're not build-time tests, they're run-time tests, that need all sort of other deps to run, etc
<kees> cjwatson: right -- that's the main question I think -- is autopkgtest operational?
<cjwatson> kees: heno would know; I don't see an obvious reason why it shouldn't be
<mathiaz> kees: if autopkgtest is operational should the tests/ in the package be updated to match the one in q-r-t?
<jdstrand> and, I'd have to check for dovecot specifically, many tests in q-r-t are destructive, and not necessarily written for running outside of a chroot/vm
<mathiaz> kees: or the tests be moved from q-r-t to debian/tests/ ?
<mathiaz> jdstrand: I think that's the environmet autopktest is designed for
<kees> mathiaz: yes, until there is a strong censensus about how autopkgtest works, I want all the q-r-t tests in one place: the bzr repo.
 * jdstrand hasn't used autopkgtest yet
<kees> mathiaz: the security team uses them for testing things all the way back to dapper, so i'm against splitting stuff out into separate packages.
<Keybuk> bryce, slangasek: http://paste.ubuntu.com/56045/
<Keybuk> gnome-screensaver seems to consume 2 clients every activation
<Keybuk> on my laptop it seems to consume 1
<kees> Keybuk: yeah, confirmed, I see 1 per activiation.
<Keybuk> obvious difference there might be that my desktop has two monitors, so it simply consuming clients twice as fast
<cody-somerville> Keybuk, hey, same story here
 * cody-somerville has two monitors.
<Keybuk> cody-somerville: have you hit a problem recently of apps just failing to start or open windows?
<cody-somerville> Keybuk, yes. It says too many clients or something
<cjwatson> kees: what's wrong with keeping both?
<cjwatson> kees: as persia said, testing often benefits from multiple approaches
<mathiaz> kees: ok - so it may be useful to teach autopkgtest about the existance of q-r-t.
<Keybuk> bryce: so is there any way to kill things like the following?
<superm1> Keybuk, I just hit that situation an hour or two ago too
<Keybuk> 44 - <unknown> ( PID:  ?   ):
<Keybuk> 	res_base      : ox2800000
<Keybuk> 	res_mask      : ox1fffff
<kees> cjwatson: I don't mind keeping both as long as the bzr tree is the primary.
<superm1> (i've got two monitors here) - so it did happen pretty quick
<Keybuk> superm1: how many monitors do you have? :)
<mathiaz> cjwatson: in the case of dovecot, I'd be tempted to just merge the tests from q-r-t in debian/tests/.
<Keybuk> I guess those with one have 200 screensaver activations before they get DoS'd
<Keybuk> which is slightly longer than the kernel team take to upload a new kernel right now :p
<Keybuk> those ricers amongst us with two only have 100 screensaver activations, so get more suck and fail
<superm1> i've been S3'ing this laptop the last few nights and opting to not do kernel reboots, so that explains things :)
<persia> kees, Running autopkgtest takes a lot of resources.  We typically only do one or two runs per development cycle.  This one got missed due to various issues, but we'll try to get it run before release.
<jdstrand> mathiaz: if you are going to do that, also consider test-dovecot.py
<jdstrand> mathiaz: oh wait, that is 'general'. nm
<jdstrand> (though it would all have to be updated it seems)
<cjwatson> mathiaz: so, JeOS ...
<mathiaz> cjwatson: yes - so I don't know if a new option should be created or existing ones be updated.
<seb128> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=555701 ?
<ubottu> Gnome bug 555701 in libgnome-desktop "libgnome-desktop:gnome_bg_create_pixmap() leaks pixmaps and X clients" [Normal,Unconfirmed]
<Keybuk> seb128: yes, that's linked on the bug
<cjwatson> I think it's important to have a minimal install option that isn't just for VMs
<mathiaz> cjwatson: my goal here is to have a way to boot the -server iso and get a sytem with -virtual and -minimal installed.
<bryce> Keybuk: let me ask around.
<cjwatson> I am OK with there also being a minimal install option for VMs
<mathiaz> cjwatson: aggreed. Could CLI be used for that ?
<seb128> Keybuk: ah ok, I just read that you mentionned the issue, I didn't know that you knew about the bug ;-)
<cjwatson> mathiaz: "Install a command-line system" is only present on non-server CDs, because it is a daft question to ask on a CD where the default install gives you a command line
<mathiaz> cjwatson: ok - so cli.seed is just for the alternate cd.
<cjwatson> why not just "Install a minimal system" and "Install a minimal virtual machine"
<mathiaz> cjwatson: WFM.
<cjwatson> mathiaz: turning off standard is a bit harder
<Keybuk> it appears this code is unchanged since its merge into libgnome-desktop
<mathiaz> cjwatson: how was this done in Hardy JeOS ?
<cjwatson> mathiaz: tasksel, by design, generally tries to keep standard installed. Can we leave it there for "Install a minimal system"?
<cjwatson> mathiaz: HACK OF DEATH
<mathiaz> cjwatson: ok - and it would be too late in the release cycle to implement a similar hack for intrepid?
<cjwatson> mathiaz: actually, I'm not sure how it was done
<cjwatson> mathiaz: don't wanna
<cjwatson> mathiaz: oh, we did it by having a separate CD that didn't include standard
<cjwatson> mathiaz: so that won't work when merged into the server CD. It sucked as an approach anyway
<persia> Doing it right would mean fiddling with debootstrap, wouldn't it?
<cjwatson> no, why?
<Keybuk> *sigh*
<cjwatson> debootstrap doesn't install standard
<Keybuk> ok, this wasn't a one-liner that introduced this
<persia> Oh.  Hm.
<Keybuk> these gnome-screensaver functions didn't even exist in hardy
<ogra> Keybuk, note that you might also still have xscreensaver installed
<ogra> (which supersedes gss, unless that code changed)
<Keybuk> I do not
<cjwatson> mathiaz: I'll poke tasksel to export a new interface to make this work
<ogra> Keybuk, manually removed it ? it was pulled in until recently
<Keybuk> ogra: no, only -data and -glx are installed
<mathiaz> cjwatson: is this something that can be implemented for intrepid?
<cjwatson> mathiaz: yes
<ogra> Keybuk, ah, lucky you ... u-m just removed it for me right now
<ogra> i had it since upgrading
<mathiaz> cjwatson: great. I'll work on adding the -virtual kernel packages to the server-ship seed.
<Keybuk> u-m may have removed it for me when I upgraded to Intrepid last week?
<ogra> it didnt with yesterdays run for me
<ogra> the fix must be new
<cjwatson> mathiaz: "work on"? is it hard? :)
<mathiaz> cjwatson: oh no. It just needs to be done :D
<cjwatson> mathiaz: remove the jeos seed while you're at it
<cjwatson> mathiaz: is this i386 only, or amd64 too?
<cjwatson> linux-virtual | 2.6.27.6.7 | intrepid/universe | amd64, i386
<cjwatson> apparently both. the jeos seed only had it for i386
<mathiaz> cjwatson: right.
<cjwatson> mathiaz: is there a bug number for this?
<mathiaz> cjwatson: no. Should I file one?
<cjwatson> no need, was just wondering
<ogra> wow, cool ...
 * ogra just noticed #ubuntu-meeting
<ogra> that makes me like utf8
<ScottK> Interesting to watch even if I can't understand a bit of it.
<ogra> yeah
<Keybuk> why does their writing change when you highlight it in X-Chat?
<ogra> LTS vs RTL setting ?
<ogra> *LTR
<Keybuk> "Add support for showing the desktop background behind the unlock dialog."
<Keybuk> seems to be the culprit commit
<Keybuk> seb128: adding a proposed patch to bug #263211
<ubottu> Launchpad bug 263211 in gnome-desktop "apps-wont-open-due-to-maximum-clients-reached-error" [High,Triaged] https://launchpad.net/bugs/263211
<Keybuk> does it look sane to you?
<seb128> Keybuk: looking
<seb128> Keybuk: looks fine to me if it's working for you just upload ;-)
<Keybuk> I certainly don't get the leak
<Keybuk> I don't get the background image behind the lock dialog either
<Keybuk> but then I didn't before
<Keybuk> and it's not clear to me from the code how that is supposed to work :p
<seb128> Keybuk: I'm not sure either but I pinged upstream on IRC
<Keybuk> I ping'd jon over twitter, since he wrote the patch
<Keybuk> k, uploaded
<ogra> over twitter ... heh
<seb128> Keybuk: I pinged soren on #control-center asking him to have a look at the bug but it doesn't seem to be around
<Keybuk> ogra: I don't think that I have his cell number
<seb128> Keybuk: ok, upstream bug moved to gnome-screensaver now and the comment suggest your change is correct
<Keybuk> yeah, that's what I thought
<Keybuk> it looked like g-ss just really wanted a pixmap with the background image, and he passed root=TRUE "because that sounded right"
<Keybuk> when root=TRUE seems to really mean "this will be the real and only root window, so make it specially"
<dholbach> james_w: will you update launchpadlib before release? :)
<james_w> dholbach: done :-)
<dholbach> nice
<bryce> Keybuk:  try  e.g., xkill -id 0x2800000
<lycannyc-work> hey everyone, i just ran the last update and my gdm doesnt have gnome in the sessions so when i log in it just stays in the brown screen
<_Zeus_> !support
<ubottu> The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
<_Zeus_> !intrepid
<ubottu> Intrepid Ibex is the code name for Ubuntu 8.10, due October 30th, 2008 - Warning lots of broken software between now and October 30th! - Use #ubuntu+1 for support, *NOT* #ubuntu
<_Zeus_> my bad
<pitti> slangasek: gimp unwebkitified
<pitti> slangasek: if you have a minute, can you please look at my dbus and coreutils (hardy) SRUs? I don't want to process my own uploads
<pitti> kees, james_w: v4l promoted, go wild
<james_w> thanks pitti
<pitti> well, as wild as you can get with basically no buildd power :)
<ScottK> pitti: I just noticed there is still a restricted-manager-kde file in my /etc/xdg/autostart (along with the jockey-kde one).  Shouldn't that have been removed at some poiint?
<kees> pitti: saweeet, thanks
<hwilde> help I need to spike my cpu,   got benchmarks?
<slytherin> why is cups-pdf no more in main or installed by default in intrepid?
<lool> bryce: i'm pushing a new xorg with a trivial drop of deps of video-all on lpia
<bryce> lool, ok
<lool> 386473ff0251ff894aa
<_Zeus_> ??
<slangasek> pitti: unwebkitified> awesome!
<slangasek> pitti: yes, looking at those SRUs, thanks
<Keybuk> lool: nice passphrase
<lool> Keybuk: don't mock git
<Keybuk> quite.
<Keybuk> why use simple revision numbers when a SHA-1 will do
<NCommander> Keybuk, talking about monotone/git?
<NCommander> ScottK, I looked at openexr
<NCommander> ScottK, its not pretty (and not a problem with openexr itself)
<ScottK> NCommander: I saw debian disabled the test suite on some archs.
<NCommander> ScottK, the issue is threading
<NCommander> Something in glibc broke on 2.8 that causes threads in some situations it seems to not properly lock and respect mutexs
 * NCommander had a similar issue with glib and trying to compile it
<NCommander> It *might* just be my HPPA box, but looking very closely at the test results, it works fine without threads, or threads that aren't working together
<NCommander> ScottK, do you just want to kill the test suite since the issue isn't with openexr specifically? (the test failures go away on glibc 2.7)
<ScottK> NCommander: It seems a popular solution, but I'm not qualified to judge.
 * ScottK summons the spirit of lamont for an opinion.
<NCommander> ScottK, have you prepared the necessary sacrifices?
<ScottK> NCommander: I gave a user Postfix advice on #ubuntu-server this morning.
 * NCommander reads from the book of HPPA
<NCommander> Thou should give advice on sendmail, the most evilest of SMTP daemons. Only then shall the first sacrifice be met
<ScottK> Well I think friends don't let their friends use Sendmail.
<persia> Erm.  sendmail isn't evil, it just wants to be placated before it will play nice.
<NCommander> persia, go write a config file without using M4 macros, then tell me that again with a straight face
<persia> Actually, I was opposed to the whole transition to m4 for sendmail config, and stopped being a mail server admin about at that point, as much as possible.
<stgraber> slangasek: I'll need a new freeze exception for LTSP, fixing regression from pre-FF that we have now fixed upstream (and were missing in the previous upload)
<stgraber> slangasek: I'm test building, I'll then file a bug for it
<slangasek> stgraber: is this just fixing the one bug?
<slangasek> if so, please just upload
<NCommander> persia, you must LIKE pulling teeth. Sendmail's config format makes my brain hurt (its like COBOL. THere is only one sendmail config and its edited and modified millions of times)
<stgraber> slangasek: 3 regressions fix, one bug fix and two small upstream changes (and a mythbuntu packaging fix): http://paste.ubuntu.com/56084/
<slangasek> stgraber: what do you mean by "pre-FF regression", exactly? "regression that happened before FF", "regression in the current version relative to the version present at FF"...?
<stgraber> slangasek: something that was fixed before FF but we broke with the last upload
<slangasek> ok
<stgraber> basically these changes were done in .diff.gz and didn't get upstream so were missing in the last upload
<slangasek> tsk
<slangasek> stgraber: from the changelog alone I can't say for sure "this shouldn't need a freeze exception", so please go ahead and file a bug if you believe that's best
<ndube> hello all
<ndube> i am currently attempting to install 8.10 beta from the alt cd
<ndube> The installer does not see any of my HD if I have more than one plugged in. If I have only one HD plugged in, the installer see's it fine. Any Ideas?
<stgraber> slangasek: ok, will file a bug and attach the diff.
<_Zeus_> !intrepid | ndube
<ubottu> ndube: Intrepid Ibex is the code name for Ubuntu 8.10, due October 30th, 2008 - Warning lots of broken software between now and October 30th! - Use #ubuntu+1 for support, *NOT* #ubuntu
<ndube> sorry, wrong irc
<slangasek> pitti: I don't see a coreutils SRU in the queue
<stgraber> slangasek: bug 281415
<ubottu> Launchpad bug 281415 in ltsp "[UVFe] ltsp (5.1.25 -> 5.1.27)" [Undecided,New] https://launchpad.net/bugs/281415
<NCommander> ScottK, what's your interest in openexr anyway?
<ScottK> NCommander: It's a broken build-dep of kde4libs so I need it to build before I can start to get KDE4 building again on hppa.
<james_w> kees: hey, do you have hardware to test these patches?
<lamont> ScottK: sup?
<ScottK> lamont: openexr is FTBFS on hppa.  NCommander says it's broken threading stuff.
<ScottK> lamont: So it looks like Debian gave up on the openexr test suite on several archs and so the question is would that be reasonable for hppa.
 * ScottK looks at NCommander for details on his threading findings.
<lamont> it's kde... :-)
<NCommander> lamont, the test suite works fine until it tries to use multiple threads to write out files
<NCommander> lamont, probably some mutex fun. I suspect its a glibc problem since it doesn't happen with glibc 2.7, nor does this same behavior manifest on any other architecture where the test suite is run
<ScottK> lamont: Yeah, I'm trying to do my bit to help out ports and get KDE built on hppa.
<NCommander> lamont, I did manage to get a HPPA box from HP with Ubuntu, so I'm helping with porting issues as well ;-)
<kees> james_w: yuppers
<kees> james_w: that's why I originally started the thread on u-devel.  I wanted to turn "ack, my webcam isn't working" into something constructive.  :)
<james_w> kees: great, I'll defer to the person who is actually able to test them
<kees> james_w: that's why I started with xawtv: it's small and easy to test.
<james_w> heh :-)
<directhex> NCommander, porting work? having fun, i hope? :p
<lamont> NCommander: NPTL/hppa haz issues
<NCommander> lamont, that's putting it mildly. It would have been nice if they stayed with linuxthreads until the NPTL bugs were ironed out
<directhex> NCommander, feel free to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240272 :)
<ubottu> Debian bug 240272 in mono "mono_0.30.2-1(hppa/unstable): FTBFS: needs porting work for hppa" [Serious,Open]
<NCommander> mono is in PAS
<NCommander> (although there was a WIP port for hppa at some point)
<directhex> PAS?
<NCommander> Packages-arch-specific
<directhex> man, 0.30.2? that bug be OLD
<NCommander> directhex, and something like that has to be done in upstream, since porting mono requires writing a new HAL layer
<NCommander> Oh
<NCommander> wait
<NCommander> O_o;
<NCommander> Why do we need such an antique?!
 * NCommander was thinking 1.32 or something
<directhex> i don't know if anyone's tested since
<directhex> i was just working on mono bugs today. 6 debian bugs should be closed within hours, and then i'll do a merge
<lamont> NCommander: there was a push to move all of ubuntu to NPTL with edgy... that'd be why there's no edgy/hppa or feisty/hppa
<NCommander> lamont, even the debian dudes weren't that crazy, NPTL is only just available with lenny, and I didn't think they were making the transition until squeeze
<NCommander> I knew there were threading issues with NPTL/hppa, but I didn't realize they were THAT ba
<lamont> they knew they could make the transition partially because ubuntu had already
<lamont> well, it's probably just one bug. :-(
<lamont> OTOH, it seems to be in a very popular place, whereever it is
<NCommander> lamont, pthread_join()
<NCommander> I was able to get a consistent hang when joining thread without fail
 * NCommander notes that didn't happen on the buildds
<lamont> see: popular
<directhex> popular. on hppa? humour!
<lamont> directhex: if all 4 of us use it, it's ubiquitous.
<NCommander> lamont, I also got an ia64 box ;-)
<NCommander> (there is a port that see absolutely no love at all)
<directhex> lamont, i was about to ask if you'd run an unofficial hardy buildd on it for me to use for my third party repo, then i remembered the past few minutes & what's on my repo...
<directhex> NCommander, i love itanium!
<cjwatson> mathiaz: I've uploaded the unattended-upgrades/enable_auto_updates installer integration
<mathiaz> cjwatson: awesome ! thanks :)
 * NCommander drops his RS/6000 on directhex 
<NCommander> I can understand mono
<NCommander> But ia64 is the end result if i386 raped powerpc, and powerpc didn't get an abortion.
<directhex> jms@orac:~> mono --version | grep Arch
<directhex> 	Architecture:  ia64
<directhex> :)
<lamont> directhex: give me xen on hppa with a commitment and history of support, and I'll get you a an hppa ppa buildd
<directhex> lamont, yeah, about that... :/
<lamont> NCommander: ia64 is the result of the hppa engineers meeting with intel engineers and coming up with what hp's engineers thought hppa should have been originally
<NCommander> lamont, I dunno, the one look I took at the ia64 instruction set made me think of my x86 ASM book
<directhex> jms@orac:~> grep -c IA-64 /proc/cpuinfo
<directhex> 256
<NCommander> The real problem with that architecture is the mythical compilers that can optimize amazingly well
<directhex> jms@orac:~> icc --version | head -1
<directhex> icc (ICC) 10.1 20080312
<NCommander> directhex, obviously your not too familar with the long development history of the ia64 architecture ;-)
 * lamont kinda lived it
<directhex> NCommander, i'm aware of performance benchmarks, and i know this box did to the competition what spielberg/lucas did to indianna jones
<NCommander> raped and killed it?
<lamont> directhex: originally or lately?
<NCommander> oh wait, that was star wars
<directhex> lamont, lately
<directhex> NCommander, no, indy too
<NCommander> I could watch the 4th one without puking
<NCommander> lamont, BTW, the test suite on HPPA is nice and pretty with glibc
<lamont> ok
<NCommander> I can see why its disabled by default
<persia> Wait, the *gcc* testsuite is disabled by default on hppa?  How can that be safe?
<NCommander> persia, glibc
<NCommander> persia, and yes it is
<NCommander> and no it isn't.
<persia> Err, yes, but even so.
<persia> Oh, good.
<NCommander> persia, glibc FTBFS during its test suite
<persia> That's better.
<NCommander> (well, technically it hung, but)
<slytherin> hi, can anyone please tell me why cups-pdf was moved to universe in intrepid?
<directhex> slytherin, a deal with microsoft means ubuntu now only supports the microsoft XPS format instead of PDF!
<slytherin> directhex: what deal, no one asked me before making it. :-P
<directhex> slytherin, sorry, there was beer, and y'know...
<jdstrand> slangasek: do you have a reference as to why ruby1.9 is in main? I can't seem to find one, and http://www.ruby-lang.org/en/downloads/ seems to consider 1.9 'Developer version (experimental)'
<slangasek> jdstrand: only by traversing germinate output
<NCommander> directhex, you remind me of Miguel de Icaza
<jdstrand> slangasek: that should be something I can do, no? (I don't know how, but can learn)
<directhex> NCommander, miguel's a nice guy. with me, you need to filter through a few layers of sarcasm to see the point of what i'm saying.
 * NCommander watches his sarcasm meter explode
<slangasek> jdstrand: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/all , look for ruby1.9
<slangasek> looks like we blame rrdtool
<jdstrand> slangasek: thanks
<directhex> NCommander, i'm currently fighting the most crack-smoking example of debian bickering i could have imagined. it's making me tetchy
<slytherin> directhex: still dealing with the moonlight ITP?
<directhex> slytherin, the package is ready & functional in its current form (and designed for syncability), but we're leaving it a little for the bunfight over removing anything tangentially related to a software patent somewhere in the world from debian
<directhex> ii  libmoon0       0.8.1+dfsg-1   open source clone of Microsoft Silverlight
<NCommander> didrocks, link?
<NCommander> oh, moonlight?
<NCommander> Yeah well, Debian is dyin. Netcraft confirms it */meme*
<directhex> NCommander, netcraft? hells, that's it then :|
<directhex> NCommander, first they came for BSD...
<NCommander> then Debian
<NCommander> Then Vista
<NCommander> :-/
<persia> Debian is *so* not dying.  Debian is more lively and dynamic now than in some time.
<directhex> NCommander, explain the "BSD is dying" meme to persia
 * NCommander uses his favor you owed me on fixing the mono segfaults on this
<NCommander> directhex, please explain the "BSD is dying" meme to persia ;-)
<stgraber> slangasek: I just updated the bug to include a new upstream including one more bugfix (and no additional feature this time :))
<directhex> persia, slashdot is full of links which are all pretty much like the following: http://bsd.slashdot.org/comments.pl?sid=228247&cid=18495137
<NCommander> Neat, I didn't even have to sudo it!
<directhex> persia, see http://en.wikipedia.org/wiki/Slashdot#Culture
<directhex> persia, "netcraft confirms * is dying" is a meme.
<NCommander> persia, generally speaking, when Something is Dying. Netcraft confirms it, it means that pretty much the opposite is true
 * NCommander notes Lenny is pretty kick ass. Now only if they would release it ;-)
<directhex> NCommander, if the wingnuts actually manage to get their "remove all patent-encumbered software of any kind from the archive" GR approved...
<NCommander> Uh
<NCommander> So there goes FAT32 support
<directhex> and double clicking. and gecko.
<NCommander> Booting off a CD, JFS2 (IBM did release that one to the community though)
<ScottK> directhex: If they do that, there won't be any left.
<NCommander> And it still won't be free to the FSF :-)
<directhex> NCommander, releasing things to the community is a trap. don't you know?
<NCommander> ScottK, well, thats the current discussion on d-devel
<ScottK> Yeah.
<directhex> NCommander, fsf's gobuntu installs mono by default :)
<bytor4232> Should startupmanager be included as a base (k/x)ubuntu install?  It seems like a very useful package.
 * NCommander notes the FSF's crack pipe has to have some serious good **** in it for them to consider Debian non-free
<directhex> NCommander, firmware blobs! and fonts!
<NCommander> Not in Debian
<NCommander> Both are in non-free
<NCommander> That's why my laptop runs Ubuntu
<jcristau> directhex: there's no such GR...
<directhex> jcristau, not yet. read your d-devel.
<jcristau> i did. i ^Red that thread
<jcristau> :)
<NCommander> directhex, I personally think the FSF got pissed since Debian declares GDFL non-free
<slytherin> NCommander: directhex: the discussion is becoming off-topic here. :-)
<directhex> slytherin, sorry
<cjwatson> NCommander: disputes between the FSF and Debian over freeness go back about a decade before that
<cjwatson> (I was already typing, figured I'd finish ...)
<NCommander> cjwatson, point retracted :-)
<Laney> Which VNC server is enabled by the Prefs->Remote Desktop applet? I'd like to enable it from the commandline
<slytherin> Laney: vino
<slangasek> directhex: um, there's no GR on the table for removing "all patent-encumbered software"
<Laney> slytherin: Ah, I thought that was the client. Thanks
<slangasek> and why would you think such a GR would pass, anyway?
<directhex> slangasek, yet. and because TEH PATENTZ!
<slytherin> Laney: client is vinagre
<Laney> Just found that out ;)
<slangasek> directhex: let me rephrase.  "why do you hold such a low opinion of the Debian community that you think such an insane GR would pass?" :P
<directhex> slangasek, i don't, i like to mock
<directhex> slangasek, look at it this way. on the scale of hypocrisy, what's the single worst package you could be maintainer for if you were arguing that a browser plugin cloning a non-free  one, which doesn't support all sites & is therefore worthless, shouldn't be permitted into the archive?
<slangasek> directhex: SIGVERB grammar overflow
 * slangasek grows the stack and manages to parse, but still doesn't know the answer
<directhex> slangasek, guy arguing that moonlight should be forbidden from entering the debian archive. package maintainer. argues that it clones a closed browser plugin (which is Bad(tm)) and doesn't work on all sites ever (and is therefore worthless). which is the most facepalm-worthy package he could maintain?
<persia> flashflugin-nonfree?
<slangasek> ruby?
<directhex> persia, gnash. but close.
<persia> Could someone please give-back compiz-fusion-plugins-extra on lpia ?
<ScottK> persia: Done
<persia> ScottK, Thank you.
<ScottK> No problem.
<ScottK> NCommander: Did you come to any conclusion about openexr?
<slytherin> any archive admins around?
<persia> slytherin, Generally, you'll do better to request the thing you want, rather than scaring them away like that :)
<slytherin> :-)
<slytherin> persia: nothing new, same old move to universe bugs. :-)
<wgrant> superm1: I'm fairly sure it won't - I know exactly why one of the bugs happens, and the other one is probably a kernel bug.
<superm1> wgrant, did you already punt it by rtg?
<wgrant> superm1: I haven't, but I will when I see him.
<wgrant> superm1: The lots and lots of keypresses seem to be caused by X never seeing the key released, thus invoking key repeat.
<wgrant> And I was advised it was probably a kernel bug.
<superm1> wgrant, OK, well if you don't get a chance to at some point or get busy with something else, leave the notes on a bug and at least point me at it and I'll bring it up as I talk to rtg weekly
<ScottK> I can tell OpenOffice.org has caught up with MS Office.  OOO Writer's autocorrect feature is really annoying me.
<wgrant> superm1: Kernel freeze is unfortunately close :(
<wgrant> When is your next talk with him?
<superm1> thur
<superm1> so probably if you talk to him sooner, that's better
<wgrant> OK, I'll poke him when I see him.
<wgrant> Assuming he is the right person..
<superm1> well for reproducing on dell hardware he should be
<superm1> he has most interesting platforms
<wgrant> Ah, good.
<wgrant> Heh.
<ScottK> superm1: Any luck on solid-bluetooth yet?
<superm1> ScottK, the API changes are rather large.  I'm not sure i'll be able to make enough intelligent changes in a timely fashion.  it would really be a task better for someone more familiar with solid
<superm1> ScottK, I'll keep futzing, but I do have other tasks i'm working on concurrently
<ScottK> superm1: I get the impression that upstream isn't excited about dealing with it at the moment.  Unfortunately we don't have anyone on the KDE side that understands the API changes.
<ScottK> superm1: Perhaps if we could find someone who understands solid to pair your with, between the two of you, you could get to something more than what we have now?
<superm1> ScottK, well I'm catching up on all the API changes too, but that would probably be useful.
<superm1> ScottK, what i'm wondering is what the F10 folks are planning on doing about this
<superm1> ScottK, given they're still broke...
<ScottK> I'm not sure they're aware.
<ScottK> The one Fedora KDE person that hangs out with us didn't know of problems.
<ScottK> superm1: Would you consider idling in #kubuntu-devel and let's see who turns up?
<superm1> sure
<emgent> heya
#ubuntu-devel 2008-10-11
<ScottK> slangasek or any other archive admin that might happen to be around: libfile-temp-perl was deleted this morning and now libmime-tools-perl and thus amavisd-new are uninstallable.  No bug to hint why it might have been removed.
<slangasek> hrm
<slangasek> StevenK: do you know anything about that? ^^
<superm1> ScottK, just uploaded a new mimi-tools that should help
<superm1> mimi? mime
<slangasek> ah, no, https://launchpad.net/ubuntu/+source/libfile-temp-perl/0.20-1ubuntu1 shows the reason
<slangasek> pitti: why was libfile-temp-perl deleted?
<ScottK> superm1: Great.  That should help.
<ScottK> It looks to me like the version conflicts for perl-modules should have been bumped too then.
<ScottK> superm1: Bonus points for fixing it in a backports friendly way.
<superm1> ScottK, blame that mostly on debian.  when laga caught it breaking stuff, I saw debian did it nice so figured lets do it nice too :)
<lycannyc-work> whats the work around for the update that removed all the gnome panel stuff?
<wgrant> lycannyc-work: Install ubuntu-desktop and xserver-xorg-input-all. Or watch for these removals in the first place and stop them.
<wgrant> I'm surprised how many people got caught in that 3 hour window.
<persia> There's a lot of testers out there at this point.
<wgrant> A lot of testers who blindly upgrade, too.
<lycannyc-work> ^^^
 * Twigathy_ wonders if the ipconfig / NFS root bug will still be present in 8.10...
<persia> Well, that's because someone suggested that `apt-get dist-upgrade` was a useful command.
 * Twigathy_ has not had time to test :|
<lycannyc-work> i reinstalled hardy on my other partition since i have no net whatsoever on intrepid at the moment
<lycannyc-work> im trying to chroot and its still not working, failed to fetch
<wgrant> lycannyc-work: What's the actual error message? (this is better in #ubuntu+1)
<jcristau> persia: it is. there's a reason it asks for confirmation though.
<persia> jcristau, Yeah, so you press return a few times.  Although I'm a long-time aptitude user, I rather like just how much update-manager refuses to upgrade lots of things, and encourages the user to to investigate in synaptic.  It strikes me as the right solution.
<persia> Mind you, it gets a little too aggressive about removals for dist-upgrades in my opinion, but for regular daily upgrades, it's pleasantly conservative.
<ScottK> persia: apt-get dist-upgrade is a useful command.  Reading what it says it's going to do before agreeing to is is also useful.
<persia> ScottK, Well, I suppose.  I tend to only use it when things are somewhat broken.
 * wgrant hopes that users will only do it once.
 * ScottK just mistyped ... greater long term flexibility and discovered that flammability comes up right next to flexiblilty in the spelling correction options.
<stgraber> slangasek: hmm, I was just wondering, we have a bugfix release of ltspfs that'll be released soon but it'll also introduce some missing or out-of-date documentation. Does that require a freeze exception or is considered as bugfix-only ?
<slangasek> stgraber: how does introducing missing or out-of-date documentation qualify as a "bugfix release"...?
<stgraber> slangasek: well, we have 0.5.3 in Ubuntu, 0.5.4 adds the missing doc and 0.5.5 is the bugfix-only :)
<ScottK> stgraber: I gather you're trying to say it will provide documentation that is currently missing/outdated?
<stgraber> ScottK: yep and fix a bug that made it segfaulting in some cases
<slangasek> stgraber: then that doesn't count as bugfix-only
<ScottK> i.e. make it better (your sentence parsed rather the opposite to me)
<ScottK> Fixing docs isn't a bugfix?
<slangasek> hrm?  oh, I should be parsing that the other way?
 * slangasek shakes his fist
<slangasek> yes, fixing docs is a bugfix
<ScottK> I read it the other way too at first.
<slangasek> stgraber: yes, that's fine then
<stgraber> slangasek: ok, thanks.
<slangasek> why is update-notifier telling me "(null)"?
<Hobbsee> hmmm, mvo's not here.  I was going to ask if he had plans to force https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/254840 to be fixed, by including -evdev as a required package in the installer.
<ubottu> Launchpad bug 254840 in xorg-server "[intrepid] mouse and keyboard stop working under gdm and gnome" [Medium,Fix released]
<wgrant> Can somebody running a recent (less than 12 hours out of date) Intrepid installation try to run 'xinput list-props "<Some input device that you have>"' and tell me if you get fetch failures or other X errors?
<stgraber> wgrant: X Error of failed request:  BadDevice, invalid or uninitialized input device
<stgraber> wgrant: something like that ?
<wgrant> stgraber: You have xserver-xorg-core 2:1.5.1-1ubuntu3, xserver-xorg-input-evdev 1:2.0.99+git20080912-0ubuntu3, and have restarted X since upgrading?
<stgraber> system is up to date (from a few minutes) but I haven't restarted X yet, will do and tell you if it improved
<wgrant> Ah, that would do it.
<wgrant> I'm sort of hoping that you'll get an error.
<wgrant> (a different one from this)
<stgraber> wgrant: Device Enabled:		Fetch failure
<wgrant> AHA!
<stgraber> btw, what's the easiest way to know the current color depth ? I have some doubts my video card is configured correctly at the moment
<wgrant> A non-forum machine that exhibits it. Finally.
<wgrant> stgraber: Which device are you attempting to list?
<stgraber> Synpatic touchpad
<stgraber> *Synaptic
<stgraber> xinput list-props "SynPS/2 Synaptics TouchPad"
<wgrant> stgraber: What if you list some other device that doesn't use the synaptics driver?
<stgraber> same with "PS/2 Generic Mouse"
<stgraber> and same with the keyboard
<jcristau> stgraber: xdpyinfo?
<jcristau> (tells you the depth, among other things)
<wgrant> stgraber: What if you run 'xinput set-int-prop "SynPS/2 Synaptics TouchPad" "anything at all" 8 1'? You might get a more useful error.
<stgraber> stgraber@castiana:~$ xinput set-int-prop "SynPS/2 Synaptics TouchPad" "anything at all" 8 1
<stgraber> stgraber@castiana:~$
<wgrant> Blink.
<stgraber> jcristau: ok, so my problem doesn't seem to be color depth as it returns "24 planes" for the root window which I assume = 24bit
<wgrant> xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Synaptics Two-Finger Scrolling" 8 1 0
<wgrant> See if you can vertically two-finger scroll after you run that.
<stgraber> jcristau: When watching videos it looks like I'm limited to 16bit and the gdm login screen looks the same (haven't checked if it's not just an issue with the theme itself though)
<stgraber> ok, according to "file", in the case of gdm, the theme is the problem.
<stgraber> so I'll go back at checking my mplayer options then (probably something wrong there as I had to tweak it to run without XV ... bad radeon hd)
<persia> slangasek: Because /var/lib/update-notifier/user.d/fusa-applet.note doesn't include a "Name: " header.
<wgrant> stgraber: Did setting that property do anything?
<persia> It also doesn't include a DisplayIf: or DontShowAfterReboot: header, either of which is probably at least confusing.
<stgraber> wgrant: nope, standard vertical scrolling still work but two-finger scroll doesn't
<wgrant> stgraber: But it didn't give you an error?
<stgraber> no
<wgrant> Grrr.
<slangasek> persia: thanks, will file a bug
<wgrant> stgraber: Can you grab http://www.qeuni.net/f/1/2008/getprop, and run it like './getprop 2 "Wheel Emulation Y Axis"', replacing 2 with the numerical ID of your non-Synaptics mouse?
<stgraber> wgrant: http://ubuntu.pastebin.com/f4f7283b7
<wgrant> Blurgh.
<wgrant> What.
<wgrant> Um.
<wgrant> 41 doesn't exist any more.
<wgrant> So I guess libxi must be wrong.
<stgraber> wgrant: oh, just thought of something
<stgraber> wgrant: you may want to compile your binary again in 64bit or give me the source
<stgraber> as I'm running 64bit and I don't think lib32 is up to date
<wgrant> getprop.c, same place.
<wgrant> Ahh, that would do it.
<wgrant> Sorry.
<wgrant> You need to link it against Xi
<wgrant> gcc -o getprop -lXi getprop.c
<stgraber> stgraber@castiana:~$ ./getprop 3 "Wheel Emulation Y Axis"
<stgraber> stgraber@castiana:~$
<wgrant> OK, "Synaptics Off" with the ID of your Synaptics device.
<stgraber> same result ...
<wgrant> OK, so the Get is actually failing.
<wgrant> Hmmm.
<stgraber> strace shows some: -1 EAGAIN (Resource temporarily unavailable)
<wgrant> As does mine.
<wgrant> stgraber: Can you grab getprop.c again, try it out on your mouse again, and tell me the result?
<wgrant> 27
<wgrant> Damn.
<stgraber> stgraber@castiana:~$ ./getprop 3 "Wheel Emulation Y Axis"
<stgraber> result: 0
 * wgrant wonders both why it occurs at all, and why it won't occur on any of his boxes.
<wgrant> stgraber: There's an even more verbose version there now. Try it on both properties I've referenced here.
<stgraber> wgrant: http://paste.ubuntu.com/56161/
<wgrant> That should never be able to happen.
<wgrant> jcristau: Any ideas how to debug this further?
<wgrant> The only difference between our setups that I can of is the arch. But surely not...
<jcristau> format 51 is unexpected...
<wgrant> jcristau: Isn't it never, ever meant to not be a multiple of 8?
<wgrant> Even on failure?
<jcristau> i was looking at libxi, i'll look at the server now..
<wgrant> I don't think it can be libxi's fault.
<wgrant> And ProcXGetDeviceProperty is fairly large.
<jcristau> wgrant: i'd step through ProcXGetDeviceProperty in gdb
<wgrant> jcristau: I've never run X in a debugger before... and I have no hardware that this afflicts.
<jcristau> x runs mostly fine in gdb, except it's better to attach the debugger after startup (because xkbcomp bonghits), and you need to do it from ssh
<jcristau> the 'no hardware' part is harder :)
<wgrant> Yes...
<wgrant> None of my five machines here exhibit the problem, which is mighty confusing and annoying...
<jcristau> i'd offer to build stuff with the patches and play here, but it's 4am already :/
<wgrant> Ew.
<wgrant> jcristau: Pretty much everybody reporting the error mentions that they're running amd64.
<wgrant> None of my i386 machines exhibit the problem.
<wgrant> This is unlikely to be a conincidence.
<wgrant> -n
<persia> wgrant, How much information do you need to track it?  I'm sure there's not a few people who have amd64 & synaptics, and would be willing to test.
<wgrant> persia: I don't believe it's just Synaptics people, actually.
<persia> You think it affects any input device?  Just things that look like mice and keyboards to HAL?
<wgrant> Looking through HWDB submissions for all of the people complaining about this and the previous version of the error on the bug are either running amd64 or on the same hardware that others are running amd64 on.
<persia> I'm more than happy to attach a wide variety of input devices on amd64 with up-to-date hardy.
<wgrant> persia: It should affect input device properties in general.
<wgrant> Synaptics just happens to be the main user.
<wgrant> evdev provides various properties on any mouse.
<wgrant> So a touchpad is not required.
<superm1> wgrant, do you have a good test case?  I can help out with and amd64 live cd if need be
<jcristau> persia: this is intrepid, not hardy
<persia> Right. s/hardy/intrepid/
 * persia is not thinking clearly, as it's getting on quarter past thirty-five
<jcristau> xtrace can also be helpful, but it doesn't seem to support XI
<persia> Anyway, I've mice, touchpads, keyboards, joysticks, and several things somewhere inbetween on intrepid.  What's the test case?
<wgrant> superm1: Ideally: On the same machine, on both i386 and amd64 Intrepid beta live CDs, run 'xinput list', find your mouse, and 'xinput list-props "Your Mouse Name Here"'
<wgrant> On the beta I expect that you will get a BadDevice on amd64. As of last night, it's different.
<persia> Is there a special reason to use beta vs. current?
<wgrant> Current live CDs aren't guaranteed to work.
<wgrant> Nor exist.
<jcristau> or, wireshark, on a server that listens on tcp.
<wgrant> And people aren't likely to have both an i386 and amd64 instance on one machine, so live CDs are required.
<persia> Oh.  I overwrote my betas.  Today's liveCD doesn't exist, but yesterday's does, and there's an ubuntu-mobile image for today which can do i386 X testing.
<wgrant> That should do.
<wgrant> You just need X, evdev and xinput.
<persia> That's all standard.  I'm about 60% done with today's ubuntu-mobile image download, so I'll plug in a variety of things that X thinks are mice, and collect.  Probably be about 30 minutes for both amd64 and i386.
<wgrant> Any single mousey device should do.
<persia> Even easier then :)
<persia> Confirmed the BadValue on amd64 at least.
<wgrant> OK, good.
<wgrant> This would explain why it was impossible to reproduce.
<persia> Yeah, seems to affect any arbitrary pointing device, or at least the two I've tried so far.
<wgrant> Actually, it should affect anything - all input devices should have a property to disable them
<wgrant> That's not encouraging...
<persia> OK.  Attaching some pointing devices appears to restart X, which can't be good.
<wgrant> 13:25:41 < wgrant> That's not encouraging...
<wgrant> Indeed...
<wgrant> Now we need to see if it still happens on i386.
<persia> unfortunately, it killed my download, and it was overwriting, so it'll be a bit :(
<persia> Interesting, I get two different kinds of errors.  The touchpad and mouse get BadValue.  The FPS controller gets "Fetch Failure".
<wgrant> Some controllers have a habit of killing X on button press.
<wgrant> Might not be unrelated.
<wgrant> Oh dear.
<persia> It appears that the Saitek Pro Gamer Command Unit is such a controller.
<wgrant> persia: Anything like http://ubuntuforums.org/showthread.php?t=943898?
<superm1> wgrant, any particulars on X versions necessary, or just the general information?
<wgrant> More amd64 showing up there...
<persia> wgrant, No, that's a gamepad.  I'll try that next.
<wgrant> superm1: Something upgraded in the last 12 hours would be excellent.
 * persia is trying a hybrid mouse/keyboard combo now
<superm1> wgrant, would today's dailies suffice?
<superm1> i can grab i386 and amd64 of each
<persia> superm1, Indeed.
<wgrant> superm1: I'm not entirely sure when they are generated.
<superm1> wgrant, well what package needs to be upgraded on them?
<superm1> i'll grab the daily, and upgrade that one package
<superm1> and restart X
<wgrant> superm1: xserver-xorg-core, libxi6, xserver-xorg-input-evdev, xinput.
<persia> superm1, I didn't see an i386 daily yet today (I'm not watching amd64).  You might get yesterday.
<wgrant> That should pull in new g-c-c, g-s-d, and a couple of other related things.
<superm1> persia, oh well they're oversized
<superm1> that will make this more difficult i think...
<wgrant> Grab an older daily, then?
<superm1> yeah
<persia> Yeah, I can reproduce crashing X with a game pad :)  Just press a button.
<wgrant> persia: Bug #274203
<ubottu> Launchpad bug 274203 in xorg-server "Joystick detected as mouse, crashes X" [Undecided,Fix released] https://launchpad.net/bugs/274203
<persia> Oh, it's not detecting as a mouse, it's using the X joystick input interface,
<persia> Hrm.  Or maybe it is.  I'm confused.
<wgrant> What does lshal give as its capabilities?
<persia> I'm low on USB ports, I'll let you know when the dd for the i386 boot completes.
<wgrant> Thanks.
<persia> I don't suppose there's some useful set of information that could be collected about a USB input device?  I've all but two varieties I've seen for sale, and would be happy to contribute data points.
<persia> (the two missing being the 6D CAD controller and the Jog/Shuttle controller)
 * wgrant moves that sort of thing to the kernel, so doesn't quite know.
<persia> It belongs in the kernel?  They all get recognised, and usually work in most cycles (although I've not been fiddling with them much during intrepid).  I was thinking more HAL/DeviceKit level.
<wgrant> Ah.
<wgrant> Maybe -joystick needs an fdi file to claim them.
<persia> For joysticks, that would make sense.
<persia> I'm not sure what to do with FPS controllers, but they're fairly nonstandard anyway.
<persia> gamepads are effectively joysticks, as far as the kernel is concerned.
<wgrant> What do you mean "FPS controllers"?
<persia> Like the Belkin n52 or the Saitek Gamer Pro Command Unit.  They're sorta half-keyboards with maybe a D pad, or a joystick or a trackpoint for the thumb.
<wgrant> Oh.
<wgrant> Interesting.
<persia> The idea is that you put your left hand on one, and the right hand on a mouse when playing a FPS.
<wgrant> I've no idea, then.
<persia> There's a wide variety of them : I only have two, as I don't really play FPS games much, and they aren't useful for much else.
<wgrant> I guess they'd best show up as a joystick and keyboard.
<persia> Or a mouse and keyboard, or just a joystick, or just a keyboard, depending on the internals.
<persia> I'd like some sensible mapping for them generally (which is why I have two with different internals), but just fixing joysticks is probably all that makes sense for intrepid.
<persia> Anyway, rebooting for i386 tests (won't be on IRC), and will get lshal on the gamepad.
<wgrant> Thanks.
<persia> wgrant, Must it be the same computer, or just the same input device?  I don't seem to be able to boot this one off USB.  I can rerun the tests on something I can boot either way, or just run i386 on the same input devices on another computer.
<wgrant> persia: Ideally the identical hardware.
<persia> Hrm.  OK.  I'll try to set that up then.
<wgrant> Of course, if it fails on i386, that will do fine.
<wgrant> But I don't think it will.
<persia> Let's try that first then, as it's easier :)
<Connecting> aaaaaafdsfdf
<Connecting> d
<Connecting> v
<Connecting> dd
<Connecting> fddd
<Connecting> d
<Connecting> d
<Connecting> ddddddddddddddddddddddd
<Connecting> ddddddddddddd
<Connecting> ddddddddd
<wgrant> Hobbsee: ^^
<Connecting> dd
<Connecting> d
<Connecting> dddddddddddd
<Connecting> dddddddddddddddddddd
<Connecting> dddddddddddddddddddddddddd
<Connecting> ddddddddddddddddddddddddddddd
<Connecting> ddddddddddddddddddddddddddddddddddddddddddddd
<persia> Hobbsee, vv
<Connecting> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
<Connecting> dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
<stgraber> thanks
<desrt> ...
<Connecting> hi
<desrt> Connecting; welcome back
<desrt> Hobbsee; maybe ban the username
<Hobbsee> desrt: nah, this will work
<desrt> i love people
<desrt> they're totally awesome :)
<ajmitch> hugs all around for the special people
<Hobbsee> Connecting: spammed the channel.  And i can see you're from ppp-70-247-119-16.dsl.rcsntx.swbell.net, so there's no need to hide on mibbit.
<Hobbsee> Connecting: don't spam, and you won't get kicked.
<Hobbsee> hey desrting
 * desrt is silenced :(
<Hobbsee> desrt: yes, yes you are - or at least, on that host
<desrt> oh well :)
<desrt> i didn't know about that.  pretty cool service.
<ajmitch> when not abused
<Hobbsee> desrt: yeah
<Hobbsee> ajmitch: well, it's hard to abuse it, as their IPs show up as well.
<desrt> i wonder what it is about web and tor that makes people more likely to abuse
<Hobbsee> so you can just silence mibbit, and block their IP.
<Hobbsee> it used to be more abusable
<desrt> like... do people avoid doing it over normal IRC because they're worried about sullying the good name of their IP address?
<Hobbsee> desrt: well, if your IP address is very dynamic, you can get around bans more easily
<Hobbsee> desrt: mibbit's been improving their stuff, which means they're one of the few web-based IRC services that are allowed into ubuntu channels
<Hobbsee> desrt: the fact that everyone's now uniquely identifiable helps.
<desrt> it's cool how freenode actually tries to work with services like tor, etc instead of klining them
<Hobbsee> indeed.
<wgrant> persia: Everything's working?
<persia> Never mind.  The i386 image I have won't even boot on i386 HW :/
<wgrant> Special.
 * wgrant looks for other willing victims with amd64 hardware and the ability to boot into both i386 and amd64 Intrepid.
 * ajmitch has 1 of the 4 criteria
<wgrant> ajmitch: You're a willing victim?
<ajmitch> I have amd64 hardware
 * ScottK is currently a bit distracted having discovered that the entire Dilbert archive since the start of 1992 is available online through their web site.
<wgrant> ScottK: Haha.
 * ScottK is 0 for 4 anyway.
<ajmitch> ScottK: thanks, now you've distracted half the people who were here
<ScottK> Not kidding.  Up to 1994 so far.  http://dilbert.com/fast/
<wgrant> ajmitch: I think you underestimate.
<ajmitch> quite likely
<ajmitch> but I have to hope that some of the rest have stronger wills than I do
<ScottK> The interesting thing is the plain, simple, no fancy graphics version of their archive is linked to off the main page a Linux/Unix.
<ScottK> As you see from the link, internally they just call it fast.
<wgrant> It lives up to its name.
<StevenK> slangasek: I know I go mad and delete stuff, but it wasn't me :-)
 * wgrant decrufts StevenK.
<StevenK> Right.
<StevenK> Seven FTBFS out of 59 sources
<persia> wgrant, I can't get any errors on i386.  The gamepad doesn't crash.  lshal says the gamepad uses evdev and provides 'input' and 'input.mouse'.  Note that the gamepad axes do not move the pointer (the pointer is moved on amd64)
<wgrant> persia: Excellent! Thanks.
<persia> StevenK, Only 7?  That's not nearly as frightening as it looked yesterday.
 * wgrant removes amd64 from the archive, fixing the problem.
<persia> wgrant, Erm.  Is there another way to solve this?  I'm willing to crash my system *lots* of times to 1) make joysticks/gamepads not crash, and 2) generally make whatever thing you're trying to do with input properties work better.
<superm1> wgrant, well i've got you i386 data, but amd64 isn't booting right now
<superm1> wgrant, is the i386 useful without amd64, or you need both?
<persia> Both from identical hardware is apparently ideal.
<wgrant> Ideally both.
<superm1> okay, i'll keep futzing here
<StevenK> Right. checkrdepends for libgnutls13 is *much* better.
<StevenK> Bug filed
<wgrant> I suspect something wrong in xserver's ProcXGetDeviceProperty, but I can't see anything obvious.
<StevenK> persia: There's seven, do we want to dole out one or two and assign those tasks to people who want to help?
<StevenK> superm1: Since you're here, where's ussp-push? :-)
<persia> StevenK, Sure.  I'm always happy to assign people work.  What's the bug number?
<superm1> StevenK, on TODO ;)
<StevenK> persia: I'll paste in here when LP creates it
<superm1> StevenK, i think that was one of yours before too, i dont have logs from building it locally at least
<StevenK> superm1: Neither do I
<superm1> StevenK, hum.  phantom build.
<StevenK> superm1: I was going to ask you who uploaded it to the PPA
<persia> Does it FTBFS?
<superm1> StevenK, is it still on the PPA?
<StevenK> steven@liquified:~/ubuntu/bluetooth-cruft/ussp-push% grep FAILED current
<StevenK> FAILED [dpkg-buildpackage died]
<StevenK> superm1: Not that I can see
<superm1> StevenK, okay well i'll take a look after I get this box booting amd64
<persia> I just checked the deleted packages : it looks like it was never in the PPA.
<StevenK> Oh.
<StevenK> obex_socket.c:(.text+0x97a): undefined reference to `hci_remote_name'
<StevenK> What's the fix for that, it's a simple one
<StevenK> persia: Bug 281561
<ubottu> Launchpad bug 281561 in nufw "libgnutls13 transitions build failures" [Undecided,New] https://launchpad.net/bugs/281561
<StevenK> persia: There is tasks for all seven, I'd suggest you dole them out. I'd like one, please.
<StevenK> superm1: Right, test building my ussp-push changes.
<persia> StevenK, Do we know which architectures are affected?
<StevenK> persia: For the ones I've filed, most of them are.
<StevenK> There was one other build failure, which was hppa, so I'm ignoring it
<persia> hppa belongs to people with hppas
<persia> StevenK, So, you can have curl.  I know it's one of your favorites.
<StevenK> Oh, yay
<StevenK> :-P
<persia> ScottK, Up for libtunepimp, or is there one you'd rather?
<StevenK> I was thinking about the curl build failure while I was out. I think it's a one line patch
<persia> This is the advantage of your previous experience with curl :)
<ScottK> I'd rather finish fixing amavisd-new and kdvi for right now.
<StevenK> superm1: ussp-push uploaded
<persia> ScottK, OK.  Any of the gnutls13 ones you want for later?
<ScottK> Looking
<StevenK> Oh, damn. Forgot to put the bug into ussp-push's changelog
<persia> NCommander, You about at this hour?
<superm1> wgrant, http://paste.ubuntu.com/56182/
<ScottK> persia: Just for grins I'll have a look at kio-sword.  It's KDEish anyway.
<superm1> that was more of a pain than i expected.  stupid nv being selected bug
<persia> ScottK, Thanks.
<StevenK> Right, I think curl is fixed.
<persia> StevenK, You want another one, I haven't assigned them all yet.  You can have kazehakase if you like.
<superm1> StevenK, okay great.  i'm guessing it was an easy fix then
<StevenK> superm1: Yeah, one line patch
<superm1> StevenK, okay cool, good
<StevenK> superm1: That closes all of the transition bug tasks
<persia> That means the removal bugs can be processed.  Now we just need solid sorted.
<StevenK> persia, superm1: Can one of you sort out https://bugs.launchpad.net/bugs/191704
<ubottu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Fix released]
<StevenK> One guy is complaining it's missing with 4.12-0ubuntu2. I suspect that's indented
<superm1> StevenK, yeah it's intentional
<persia> Anyone from the docteam about?
<superm1> StevenK, that functionality is provided directly from bluetoothd and the wizard
<StevenK> persia: Taking kazehakase
<persia> StevenK, Great.  That's them all assigned then.  Thanks.
<superm1> StevenK, if people really want hidd and throw arms up, the binaries can be put into a NEW bluez-compat package, but people really shouldn't be needing them...
 * persia goes off to find the docteam
<StevenK> superm1: I think you should reply to that bug saying that it shouldn't be needed, and if stuff doesn't work, file a new bug
<persia> No, there's a documentation bug.  help.ubuntu.com specifically mentions hidd
<StevenK> Ahhhh
<StevenK> It probably ought not to
<persia> The bug isn't currently triaged ideally : I'll chase the docteam, and try to get it sorted.  We *really* need solid fixed to do it right.
<StevenK> solid is a package?
 * persia digs up the bug
<persia> bug #280997
<ubottu> Launchpad bug 280997 in kdebase-workspace "solid-bluetooth needs update for bluez 4.x" [High,Confirmed] https://launchpad.net/bugs/280997
<persia> See, before the transition bluetooth was broken for everything but OBEX for some people.  After the transition, bluetooth is broken for KDE.
<superm1> solid is part of the massive kdebase-workspace library
<persia> Being broken for KDE is bad because 1) it annoys people, 2) it delays my plans for kubuntu-mid, and 3)
<persia> It leads to annoying blog posts.
 * persia misses Qtopia
<ScottK> persia: All I know is I have less bluetooth than I had before.
<persia> ScottK, Right.  Which devices were you using?  Just the phone, right?
<ScottK> Yes
<ScottK> This was going to be the first release I could actually use it.
<ScottK> It was a wonderful week while it lasted.
<ScottK> persia: It leads to accurate blog posts.
<persia> That's what I thought.  If you had a keyboard or mouse, you'd have more bluetooth, but this isn't ideal.
<ScottK> No, I wouldn't.  I'd still be at zero.
<persia> Would you?  I was able to connect with the command line to my keyboard.
<ScottK> I wouldn't have minded so much if it'd been tested with KDE and known to break it and the options considered and it was decided it needed to be done.
<persia> Anyway, not important.  The important thing is to fix it.
<ScottK> The thing is it's not the first time it's happened this cycle and the predominant response from Ubuntu devs seems to be 'tough'.
<ScottK> Not the best way to build togetherness.
<persia> Understood, although as I said before, having anyone respond to the call for testing would have been a good step.
<persia> No, that's not good.
<ScottK> And if someone had said "And we need it tested by ..." it would have been on a different place on my list.
<persia> This was the first I heard about it, and while I'm wishing someone tested it, I do sympathise.
<persia> OK.  I can see that.
<ScottK> I said I'd test it, but I had no idea when it needed to be done by and the upload came as a total suprise.
<persia> That puts a different light on things.
<persia> I'd seen calls for testing with no response, and I'd seen lots of traffic in -motu and here about it.
<persia> I hadn't seen you commit to testing, and then not be checked with before upload.
 * StevenK uploads curl
<ScottK> persia and StevenK: kio-sword has a happy ending.  It's not yet been ported to KDE4 and can't work with the remainind KDE3 bits we have in Intrepid, so we get to remove the package.
<StevenK> \o/
<StevenK> ScottK: Won't fix the FTBFS bug and file a removal bug
<persia> Excellent.
<ScottK> Already did the wontfix.  It has to get dropped from Ichthux-meta first.
<persia> jd failes to FTBFS for me.  StevenK: what did you do differently?
<StevenK> Argh. Ichthux again
<persia> If I try to process the open sync request, it FTBFS, but if I just recompile the current intrepid package it works.
<persia> StevenK, NBS again?
<StevenK> persia: I just added a changelog entry for jd and uploaded it
 * persia hunts LP
 * persia also goes to find the ichthux people
<StevenK> persia: Ah ha. I uploaded 1:1.9.9-080415-3build1 which broke, and james_w uploaded 1:1.9.9-080415-3ubuntu1 which built
<ScottK> persia: I already talked to txwikinger
<ScottK> He's going to take care of it.
<persia> Oh.  Cool.  Thanks.
<persia> StevenK, As usual, you're faster than I.  I suppose I need to swap packages with james-w then.
<NCommander> persia, I am now
<StevenK> NCommander: You haz a bug
<persia> NCommander, I gave you one of the gnutls13 killing FTBFSs
<NCommander> persia, cool, but I'll look it into tommorow unless there is a pressing concern to do it tonight. (just came back from the bar ...)
<persia> NCommander, No pressing concern.  pitti gave us a green light to rebuild ~60 packages to drop gnutls13 yesterday, and we're nearly done.  One of them (nufw) is yours.  You can get to it tomorrow or so.  I think pitti wants to remove the gnutls13 source on Monday.
<NCommander> Its' nice seeing the cruftbuster group getting used :-)
<ajmitch> NCommander: if you just came back from the bar, I won't bug you now about a rebuild FTFBS
 * persia likes having a handy list of people who can be assigned bugs
<NCommander> ajmitch, I'm just buzzed, not drunk
<StevenK> persia: gnash is still outstanding
<ajmitch> NCommander: libtool acting silly, your specialty
<StevenK> persia: I didn't touch that one, but I want to hit up asac
<NCommander> ajmitch, build log?
<persia> StevenK, I thought asac had a plan for that.
<StevenK> persia: Since it's now holding up libtool and gnutls
<StevenK> persia: He does, I just can't remember what it is
<persia> libtool too!  That's not ideal.
<ajmitch> NCommander: http://paste.ubuntu.com/56205/
 * ajmitch didn't have time to look at it any further than saying 'oh bother'
<NCommander> oh
<NCommander> THAT issue
<ajmitch> I thought you'd recognise something
<NCommander> Shouldn't be that hard to fix
<persia> rezound never seems to make it through a transition intact, for some reason.
<ajmitch> persia: right, this is one of the cups ones
 * NCommander tries building nufw
<ajmitch> NCommander: so, from 'not hard to fix', got any info?
<NCommander> ajmitch, the usual issue if the md5 macros aren't getting pulled in
<NCommander> *MD4
<NCommander> Two ways to fix
<NCommander> Remove the changes to configure.ac to prevent requiring relibtoolizing the package
<NCommander> Run libtoolize -I/usr/share/*libtool-ver*/m4 or something like that, and PRAY you get a working libtool
<NCommander> persia, finished with nufw
<persia> NCommander, patch?
<NCommander> Didn't need one
<NCommander> It just rebuild without issue
<persia> Just give-backs?
<NCommander> Retesting in pbuilder just incase thats a fluke
 * persia gives it back
<NCommander> Yeah
<ajmitch> NCommander: sounds suitably evil
<NCommander> I op for the former if its possible
<NCommander> (i.e. courier)
<NCommander> The later is sometimes necessary though (i.e. php-clamav)
 * persia decides to sponsor 214512 rather than doing a give-back
<NCommander> wait
<NCommander> Hold on that give-back
<NCommander> Might be a false negetive
<NCommander> I haven't updated my system within 48 hours
<persia> Err, yeah, you'll want to do that :)
<NCommander> (pbuilder is pulling in a bunch of updates now that I'm testing with that)
<NCommander> yeah
<NCommander> :-)
 * NCommander blames the booze
<NCommander> libgnutls-dev is already the newest version.
<persia> NCommander, If you do need a patch, consider adding also Dave Love's patch from 214512.  If you don't need a patch, tell me, and I'll upload.
<NCommander> Give it five minutes and I'll know
<NCommander> (pbuilder pulling build-deps)
<persia> NCommander, Does it help if I tell you that it only FTBFS on sparc, powerpc, and hppa?
<NCommander> -_-;
<NCommander> That WOULD be helpful ;-)
<persia> https://launchpad.net/ubuntu/intrepid/+source/nufw/2.2.15-1build1
<NCommander> persia, oh, that fix is trival
<persia> Thought so.  Wrap with Dave's http://launchpadlibrarian.net/13274956/nufw.diff, slap on a changelog entry, and post it.
<NCommander> er
<NCommander> Scratch that
<NCommander> I can't
<NCommander> PPC box is dead ATM
<persia> Hrm?
<NCommander> Leave me subscribed
<persia> sparc/hppa ?
<NCommander> hppa just has issues ;-)
<NCommander> And the sparc box I have access to is spooky which is hardy
<persia> OK.  Another day then.
<NCommander> Yeah
 * NCommander marks it Fix Committed, and Wishlist
<NCommander> Not strictly right, but it is fixed on amd64/i386 :-)
<persia> Hrm?  Why Fix Committed?
<NCommander> Hrm
<NCommander> Maybe in progress
<persia> That sounds better.
 * NCommander recommends you ignore me :-)
<NCommander> ajmitch, is the package I need to try building in the archive, or where do I need to get the source?
<wgrant> superm1: Excellent. Thanks. Same hardware, with around the same version of Intrepid?
<superm1> wgrant, exact same hardware.
<superm1> wgrant, i installed the packages you indicated to the latest on the archive
<wgrant> superm1: Great, so it's confirmed. Thanks for your help.
<persia> So it's that amd64 is broken?
<superm1> wgrant, yesterday's daily of amd64, and then a fully up to date i386 "install"
<NCommander> persia, thanks for subscribing me
<superm1> wgrant, so what did I confirm exactly?
<superm1> what's broke?
<persia> superm1, Getting input properties on amd64
<superm1> ah
<wgrant> So some internal bit of xserver is broken on amd64.
<wgrant> Or some lib is broken, I guess.
<wgrant> But that seems less likely, AFAICT.
<persia> Any way to track it down easily, or is it a matter of attaching gdb to X, and digging through the noise?
<wgrant> Monitoring the conversation would work - it's not too difficult, because TCP can be used.
<ajmitch> NCommander: yes, rezound, in the archive. Only change I did was changing libcupsys2.dev to libcups2-dev, iirc
<wgrant> But it will likely end up as an unfortunate session with gdb.
<StevenK> Hmmm.
<persia> wgrant, I don't understand the parts, but I'm comfortable with GDB, have affected hardware, and a willingness to test.  What should I do?
<StevenK> superm1: libgnomebt0 is now in NBS, and gnome-phone-manager requires it.
<superm1> StevenK, why is it NBS?
<StevenK> superm1: Because it part of gnome-bluetooth
<superm1> gah
<superm1> that's not cool :(
<StevenK> -- intrepid/main build deps on libgnomebt0-dev:
<StevenK> nautilus-sendto
<StevenK> -- intrepid/universe build deps on libgnomebt0-dev:
<StevenK> gnome-phone-manager
<persia> superm1, Erm.  Didn't we discuss that oddity of a dependency when we were looking at PPA uploads?
<superm1> oh that's even worse.
<superm1> persia, not this one
<superm1> persia, we were talking about build order dependencies
 * persia can dig up logs, if required
<superm1> StevenK, given nautilus-sendto is broke, too, i think gnome-bluetooth needs to be reinstated that means, and we'll have to resolve it's problem
<StevenK> Grumble
<superm1> <sorry>
<persia> The problem with gnome-bluetooth is that it's not been maintained for three years.
<StevenK> superm1: Are you coming to UDS? *evil grin*
<superm1> StevenK, yeah i am
<superm1> persia, agreed
<StevenK> Right. I'll get you.
 * superm1 hides in advance
 * NCommander looks forward to seeing what you folks look like at UDS
<slangasek> StevenK: you're not supposed to tell him that until after you've passed the TSA checkpoint
<StevenK> Haha
<StevenK> Soyuz, please grow an undelete feature
<persia> Isn't that called dput?
<cprov> StevenK: we can use copy-package.py to undelete stuff
<persia> Ooh.  Even better :)
<StevenK> cprov: Sweet!
<slangasek> methinks cprov has a highlight on 'soyuz'
<StevenK> Haha
 * wgrant agrees with slangasek.
<persia> This is a good thing, as it comes with excellent solutions
<NCommander> StevenK, well, if your fast, you can download the package before its deleted ;-)
<persia> So, aside from the problems I had with gnome-bluetooth in Breezy, what's the new problem with it?
<StevenK> I have locally anyway
<wgrant> persia: OK, you basically need to ensure your X likes TCP connections, export DISPLAY=localhost:0.0, fire up Wireshark or similar on lo, and run various xinput actions.
<ScottK-laptop> NCommander: Any conclusions on openexr?
<NCommander> ScottK-laptop, talking with lamont, override the test suite
<NCommander> Its NPTL thats broken, which means threading in general pretty borked
<persia> wgrant, Is it safe to run wireshark in the X session, or should I be looking for tcpdump or similar in a VC?
<ScottK-laptop> NCommander: Debdiff me?
<wgrant> persia: As long as you run Wireshark with DISPLAY set to something normal it won't use TCP, so it will be fine.
<NCommander> ScottK-laptop, I can't testbuild the change ATM, so I'm just going to add hppa to the NOTEST list, and hope for the best
<persia> OK.  So start wireshark in a normal session.  Open a special xterm with DISPLAY set to localhost0:0. and perform some mousing?
<ScottK-laptop> NCommander: Sounds reasonable.
<wgrant> persia: I set DISPLAY to localhost:0.0 in another gnome-terminal tab, then 'xinput list-props 3'
<wgrant> Your integer may vary.
<persia> RIght.
<wgrant> Wireshark then very nicely dissects the X packets for me, giving all of the arguments.
<wgrant> It's rather nicer than I expected
<StevenK> Wireshark is *GOOD*
<wgrant> Not security-wise.
<wgrant> But it is very useful otherwise.
<wgrant> I just hadn't used it for X before.
<NCommander> ScottK, http://paste.ubuntu.com/56216/
<wgrant> Actually, even better, use my getprop thing which should minimise the number of extraneous requests.
<wgrant> http://www.qeuni.net/f/1/2008/getprop.c
<NCommander> ScottK, I'm test building now just to make sure I didn't break i386's build
<wgrant> gcc -o getprop -lXi getprop.c
<wgrant> ./getprop <some device ID> <some property name>
<persia> OK.  What do I need to do to make my X like localhost?
<wgrant> persia: System->Administration->Login Window->Security->Deny TCP connections to XServer.
<wgrant> persia: You'll likely need to restart X afterwards.
<wgrant> I've been seeing that all too frequently today.
<StevenK> Haha
 * StevenK resurrects gnome-bluetooth
<persia> StevenK, Now, check if gnome-phone-manager actually works for you.
<StevenK> persia: I can't
<StevenK> I need to wait for the publisher
<wgrant> StevenK: Grab the binaries from LP?
<StevenK> That requires thinking
<wgrant> Point.
<persia> Not much thinking...
<persia> wgrant, ./getprop segfaulted.  Want a trace?
<persia> Or the TCP dump?
<wgrant> persia: Can you run something like xcalc?
<wgrant> There's a total of no error checking in there, so if it can't connect to the server it should just die bloodily.
<persia> Sure.  Works fine.  7*3=21
<wgrant> persia: Does getprop work if you use a more normal DISPLAY?
<persia> I see lots of keyboard and mouse events in wireshark.  It's just your code that segfaults.
<persia> No.  segfaults normally too.
<wgrant> persia: Which version of libxi6 do you have installed?
<persia> 2:1.1.3-1ubuntu4
<wgrant> libxi-dev?
<wgrant> That's very interesting that it should segfault.
<persia> 2:1.1.3-1ubuntu4
<wgrant> You aren't specifying an invalid device? I guess a backtrace would show the issue.
<persia> Oh, that's probably it.
<persia> That works sanely.
<persia> Sorry :)  Now, I've a clean TCP trace of the getprop interactions.  What info do you want?
<wgrant> The request and response of the GetProperty call.
<persia> Just the interpreted X11 data?
<wgrant> (the digested X11 dump that wireshark gives)
<wgrant> Yes.
<StevenK> persia: I don't have an Intrepid virtual machine, and gnome-phone-manager wants dbus, which doesn't work through a chroot
<persia> http://paste.ubuntu.com/56220/
<persia> StevenK, And it wants bluetooth, which is tricky with either virtual machines or chroots.  Don't you have an intrepid machine with bluetooth around somewhere?
<wgrant> persia: Which property did you try to get?
<StevenK> persia: My Jax, but that's hard to get working
<persia> I just did ./getprop 4
<persia> Should I have done something else?
<persia> StevenK, Yeah, that doesn't work very well.  I thought you had one of those Samsung slabs.
<wgrant> persia: I'm surprised that didn't segfault... It wants a second argument - the name of the property. "Device Enabled" should do for anything.
<StevenK> persia: Oh, I keep forgetting the Q1 has Bluetooth
<persia> heh
<wgrant> One of the more informative quit messages I've seen lately.
<StevenK> There is, too
<wgrant> It's the warmest day for a while down here, with no rain predicted for another 24 hours.
<StevenK> Tropical day here
<StevenK> Hot and humid and storm clouds gathering
<persia> wgrant, `./getprop 4 "Device Enabled"` produces the exact same dump.
<wgrant> Charming.
<StevenK> Few cracks of thunder, so it probably break soonish
<ajmitch> wgrant: mid-30s?
 * didrocks hugs NCommander (you are the only one who hl me by error :))
<wgrant> ajmitch: 25Â°C
<didrocks> (morning)
<wgrant> persia: Oh, of course, it's GetDeviceProperty, which doesn't seem to be showing up.
<wgrant> I guess Wireshark doesn't know about it... let's see what I can find.
<persia> heh.  hppa beat ia64 for gss.
<wgrant> hppa has been beating ia64 for a few days.
 * StevenK can't fix kazehakase.
<ajmitch> so has the minor X breakage been fixed? I should really upgrade the laptop to intrepid
<ajmitch> StevenK: can't?
<wgrant> I was very surprised when I saw "ia64: Needs building" and "hppa: Succesfully built (DONE)" last night.
<wgrant> ajmitch: g-c-c and g-s-d were uninstallable for 3 hours last night... is that what you mean?
<StevenK> I have added a patch that should fix it, but doesn't
<persia> wgrant, after GetProperty, I have InternAtom, QueryExtension, and several XInputExtensions, if any of those would help you.
<ajmitch> wgrant: more the removal of input drivers
<wgrant> ajmitch: Right, same thing.
<wgrant> That's all fixed.
<wgrant> It was never really broken, just needed three publishers to settle down.
<persia> StevenK, Does it fail in a non gnutls place, or in the same place?
<wgrant> persia: I'm grabbing the Wireshark source to see if I can teach it about XI properties.
<persia> StevenK, james-w had to do some reordering of some includes for jd, if I'm properly mapping discussion times to upload times.
<StevenK> persia: It never did
<wgrant> Or maybe xtrace. That looks easier.
<StevenK> persia: It failed due to GTK symbol deprecation
<persia> wgrant, OK.  I intend to go outside today.  Should I do that sooner, or later?
<StevenK> persia: It still does, just in a different place
<wgrant> persia: Sooner is probably good.
<persia> StevenK, Ah, so it was probably FTBFS before the transition?
<persia> wgrant, OK.  I'll do that, and pull a new version of whatever you end up patching this evening.
<wgrant> persia: Sounds good.
<persia> So, who knows GTK well and can fix kazehakase?
<StevenK> persia: I have a patch that should fix it.
<persia> StevenK, Yes, but it doesn't, right?
<StevenK> I think it just needs a second pair of eyes
<persia> OK.  Who knows GTK well and can look at StevenK's patch for kazehakase?
<StevenK> http://people.ubuntu.com/~stevenk/kazehakase/
<wgrant> in 8
<wgrant> Damn.
<wgrant> persia: Around again?
<persia> wgrant, Just got back.
<wgrant> persia: Hi.
<wgrant> persia: When you have time, grab and install http://www.qeuni.net/f/1/2008/xtrace_0.9.1-1+wgrant1_amd64.deb.
<wgrant> When run, it will run a proxy X server on :9 - run getprop on that display, and we can see what's going to/from the xserver.
<persia> wgrant, How did you construct that without amd64?
<wgrant> persia: I have no local amd64 machine, but stratos is amd64.
<persia> Oh, right :)
<persia> So just xtrace, or does it take arguments?
<wgrant> Just xtrace.
<wgrant> It should sit there and tell you which display it's running on.
<persia> It's running on :9
<wgrant> Sounds right.
<persia> Then set something to localhost:9.0 and run getopts
<persia> Err getprop?
<wgrant> export DISPLAY=:9
<wgrant> Then getprop as usual, yes.
<wgrant> xtrace will display all of the X traffic, then terminate.
<persia> ./getprop 4 "something" : what's the something again?
<wgrant> XIGetDeviceProperty is the problematic call, so that request and response would be nice.
<wgrant> "Device Enabled"
<persia> core dump.
<wgrant> What coredumped?
<persia> getprop
<wgrant> Is xtrace still running?
<persia> Yep.
<wgrant> Hum. gdb getprop and see where it fails?
<wgrant> Probably XGetDeviceProperty, because device or display might be NULL.
<persia> #0 in XInternAtom #1 in main
<wgrant> display is NULL?
<persia> Ah.  I missed a character.  Right.  Sorry.
 * wgrant likes nice easy fixes like that.
<persia> OK.  That worked.  I thought export DISPLAY=9 was wrong, but figured you knew better than I, and failed to consider that I wasn't reading carefully :)
<persia> I've an xtrace
<wgrant> OK, pastebinit if it's not too huge.
<persia> http://paste.ubuntu.com/56244/
<wgrant> OK, that makes sense, and shows it's not entirely on crack.
<wgrant> Device 0 isn't a real device, so won't have properties. Can you try one which does?
<wgrant> (it is informative, however, in that it correctly notifies us that it doesn't know about the property)
<persia> I asked for device 4, which was my touchpad.
<persia> http://paste.ubuntu.com/56245/ is the other terminal
 * StevenK returns
<wgrant> Hmmm.
<wgrant> "deviceid=0"
<persia> http://paste.ubuntu.com/56246/ was xinput list
<wgrant> That's what's being sent.
<wgrant> It looks like the server might actually be fine.
<StevenK> Awww. No one fixed my kazehakase annoyance
<wgrant> persia: Here's mine, for example: http://paste.ubuntu.com/56247/
<persia> wgrant, That's odd.
<persia> wgrant, That's for your keyboard, or a pointing device?
<wgrant> persia: 4 is my touchpad.
<persia> same as I, but the output is quite different.
<wgrant> I note that you have an xorg.conf entry for your touchpad, but I doubt that matters here.
<wgrant> What if you do it to your keyboard?
<persia> http://paste.ubuntu.com/56249/ is my keyboard (device 5)
<wgrant> Hmmm.
<jcristau> property=0x5("BITMAP") type=0x6d("Device Enabled")
<jcristau> the 0x5 should be device
<jcristau> and the 0x6d should be the property, afaict
<wgrant> Yes.
<wgrant> That's what I'm noticing.
<persia> RIght.  That is correct for the keyboard.  Now look at 56244
<wgrant> I can't see that it's a problem with xtrace, but one would have to inspect in Wireshark to be sure.
<wgrant> persia: Do you still have a trace in Wireshark?
<persia> OK.  Is that just running wireshark again, and running against localhost:0.0 ?
<persia> Not now, but I can regenerate.  Hold on.
<wgrant> Yep.
<wgrant> You need the second-last XInputExtension request.
<mdke> asac_: i see it, but can you explain more?
<persia> "opcode: Unknown (146)\nundecoded\n"
<wgrant> persia: I need the hex after and including 0x92 0x27.
<wgrant> If you select "undecoded" it should be selected.
<mdke> persia: on your post in #ubuntu-doc, we don't currently have any bluetooth documentation in ubuntu-docs, it might be a good idea to add some (judging from the confused results you get if you search for "bluetooth" in yelp). It might fit as a section in "Internet and Networks" I guess
<persia> 46 8e 92 27 06 00 04 00 00 00 6d 00 00 00 00 00 00 00 13 00 00 00 00 00 00 00
<wgrant> Hmmm.
<persia> mdke, I was just going to ask you about that.  How do I do that?
<wgrant> persia: Was the 46 8e part of the undecoded too?
<wgrant> Wait.
<wgrant> Huh.
<persia> wgrant, Yep.  There's more before that, but I thought 2 bytes was probably enough left context.
<wgrant> What the...
<mdke> persia: are you interested in writing the material yourself? If so the best way is to checkout https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation. If not, the best way is just to file a bug
<wgrant> jcristau: Something is going very, very wrong, probably in libxi..
<wgrant> It should be property, type, offset, length, device.
<wgrant> But yours shows device first.
<wgrant> Wow.
<persia> mdke, I'm not really interested in writing it, but I'm sufficiently interested in it being written that I'll be the author if nobody else has time.  Ideally, I'd collaborate with someone.
<persia> mdke, Bug against which project?   ubuntu-doc?
<wgrant> device, property, offset, type, length, I think.
<mdke> persia: ok, filing the bug is a good start then, we'll mark it as a task for new contributors and hopefully someone will pick it up. Yes, project is ubuntu-doc
<mdke> persia: gtg for now but feel free to email the list as well if you want to follow up
<persia> mdke, OK.  I'll watch the bug, and note that I'm willing to collaborate.  If I don't hear anything, I'll poke the list, and if that also fails, try to write something.
<persia> mdke, Thanks for the explanation.
<persia> wgrant, I've been fiddling with the wireshark interface, and it appears "undecoded" starts at "27" in the above string.
<wgrant> persia: Sounds right. I was just misreading it.
<wgrant> But it certainly seems to have a strange order.
<persia> I'll take your word for it.  I don't understand what I'm reading here :)
<wgrant> /usr/include/X11/extensions/XIproto.h is useful.
<wgrant> xGetDevicePropertyReq correctly represents things on i386.
<rom1v> hi, since yesterday (or 2 days ago), compiz + nvidia is unusable
<rom1v> screen is not refreshed
<persia> rom1v, Did you file a bug?
<rom1v> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/281065
<ubottu> Launchpad bug 281065 in compiz "window contents don't refresh until window is clicked" [Undecided,Confirmed]
<rom1v> I commented a reported bug 5 hours before
<ubottu> Launchpad bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released] https://launchpad.net/bugs/5
<persia> rom1v, OK.  You probably want to chat with the folks in #ubuntu-bugs about it.
<rom1v> ok, thank you
<persia> rom1v, Good luck.
<rom1v> ;)
<wgrant> persia: What does the GetProperty request look like?
<Laney> persia, superm1: Do you know what's going on with gnome-bluetooth? Looks like it was removed and then put back.
<persia> Any specific part, or you want the whole thing?
<persia> Laney, gnome-phone-manager depends on it : it shouldn't have been removed.
 * Laney was eyeing up the NBS list
<Laney> k
<wgrant> persia: The whole thing from the start of the X request (ie. the bit selected when you select the X11 item)
<persia> hex?
<wgrant> Yes please.
<persia> 14 00 06 00 99 00 00 00 17 00 00 00 1f 00 00 00 00 00 00 00 00 e1 f5 05
<wgrant> That's in the right order.
<crushy> join #plone
<persia> wgrant, So it's libxli that's changing the order, or something else, or just confusing?
<wgrant> persia: It doesn't look like xserver's problem.
<persia> OK.  Somewhere else then?
<wgrant> xserver is returning correctly, given the crap that the client is giving it.
 * wgrant is looking.
 * ogra hugs pitti for the quick ltsp response :)
<persia> wgrant, I'm out for the night, and won't be about much tomorrow.  Feel free to mail me if you want me to test something specific, or catch me tomorrow night.
<wgrant> persia: Thanks for your help today,.
<persia> wgrant, No, thanks for investigating this.  I'd like it to work right, and want to move on to the attaching-joystick-crashes-the-system once we get mice working.
<persia> Ideally we could swap laptops for a couple weeks, but there's all that water...
<wgrant> They can swim, I'm sure.
<persia> heh
<james_w> StevenK: hey, you around?
<StevenK> james_w: I am
<james_w> StevenK: kazhehakase is due to GTK_DISABLE_DEPRECATED
<james_w> I've got a candidate fix, but I gave up fighting dpatch last night
<StevenK> james_w: I had a patch that stopped using the deprecated macros
<james_w> even better
<StevenK> james_w: If you'd like, we can sit down together and discuss care and feeding of dpatch, if you like.
<StevenK> james_w: (At UDS, I mean)
<james_w> I'd like it if it didn't try and convert an existing diff to a context diff when I add a hunk to it
<StevenK> http://people.ubuntu.com/~stevenk/kazehakase/
<james_w> I've never seen it before
<fta> wgrant, hi, what do you suggest for my evdev issue ?
<StevenK> james_w: That's my source for it, but it still fails, and I'm not sure where it's picking up the deprecated macros from if I'm patching them out
<StevenK> james_w: You're using dpatch-edit-patch ?
<wgrant> fta: Which evdev issues?
<fta> wgrant, the one you just commented on in the forum
<james_w> StevenK: yeah
<wgrant> fta: Oh, right. Umm... make your computer slower.
<wgrant> I'm not sure how it should be fixed.
<wgrant> There's a bug on it somewhere.
<fta> wgrant, i'd like it to be faster ;)
<directhex> any objections to me merging mono 1.9.1+dfsg-4? it's a bugfix-only release
<james_w> we have -3?
<directhex> yeah, intrepid has -3
<directhex> well, 3ubuntu2
<james_w> directhex: I don't think that would be a problem, assuming the fixes in -4 are worthwhile.
<directhex> james_w, http://svn.debian.org/viewsvn/pkg-mono/mono/trunk/debian/changelog?rev=3719&view=auto
<james_w> yeah, that looks worthwhile
<directhex> trying to determine whether we can backport another fix before tagging for upload
<Riddell> ArneGoetje: you're doing langpacks now?  bug 281779 is important
<ubottu> Launchpad bug 281779 in language-pack-kde-en "entry.desktop is in wrong directory" [Critical,Confirmed] https://launchpad.net/bugs/281779
<ScottK-laptop> slangasek, pitti, and superm1: Following up on our discussion about libfile-temp-perl from yesterday, the new mime-tools hit depwait.  It looks like Soyuz's versioned provides problem has resurfaced: http://launchpadlibrarian.net/18424754/buildlog_ubuntu-intrepid-i386.mime-tools_5.426-1ubuntu1_MANUALDEPWAIT.txt.gz
<ScottK-laptop> libfile-temp-perl(inst =*=PROVIDED=*= ! >= wanted 0.18)
<ScottK-laptop> Actually a different incarnation, not the exact same one again.
<superm1> ScottK-laptop, so it is surely a bug in soyuz though?
<ScottK-laptop> superm1: Yes.  I agree.
<ScottK-laptop> It was more FYI for you.
<superm1> ok thx
<cprov> ScottK-laptop: launchpad-buildd bug, right ?
<ScottK-laptop> cprov: Presumably.
<cprov> ScottK-laptop: sbuild strikes again :(
<ScottK-laptop> We had a problem similar to this before that caused problems with perl modules (yes)
<cprov> I remember.
<ScottK-laptop> So it's kind of out of my hands to fix ...
<cprov> ScottK-laptop: https://bugs.edge.launchpad.net/launchpad-buildd/+bug/184565 ?
<ubottu> Launchpad bug 184565 in launchpad-buildd "sbuild believes that "inst 0.0.6-3.1 ! >= wanted 0.0.5"" [High,Fix released]
<ScottK-laptop> cprov: Similar.
<ScottK-laptop> I'm guessing this will be another one for infinity to look at though.
<cprov> ScottK-laptop: okay, could you or superm1, please file a new bug on lp-buildd ?
<cprov> ScottK-laptop: no doubt ;)
<ScottK-laptop> cprov: Bug #281796 if you'd please give it an appropriately urgent importance.  I think it's safe to confirm it too.
<ubottu> Launchpad bug 281796 in launchpad-buildd "Soyuz appears confused by versioned depends and virtual provides (again)" [Undecided,New] https://launchpad.net/bugs/281796
<cprov> ScottK-laptop: done, thanks, I will talk to infinity Mondy.
<cprov> Monday, even (keyboard from hell)
<asac> mdke: there?
<mdke> asac: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<asac> mdke: oh ... so yes. you think we can get that in the documentation or is all over?
<asac> mdke: those screenshots are about the mobile broadband wizard (3g)
<asac> mdke: when user plugs his device in for first time he sees the bubble and can click configure
<asac> mdke: next steps are wizard pages. and finally a confirmation that the new connection was added
<ArneGoetje> Riddell: I'm not sure how to fix that... is entry.desktop not an upstream file?
<Riddell> ArneGoetje: yes but it shouldn't be hard to create one, it's just [KCM Locale]\nname=Whatever
<Riddell> ArneGoetje: well, fix what?  the location of the file must be decided somewhere in the language pack scripts
<Riddell> ArneGoetje: and the existance of the file for languages we have but which aren't upstream as I say shouldn't be hard to fix
<ArneGoetje> Riddell: does this only affect languages which don't exist in upstreram?
<Riddell> ArneGoetje: does which, we have two related issues :)
<ArneGoetje> Riddell: ?
<Riddell> ArneGoetje: 1) location of file is wrong for en_GB and possibly others
<Riddell> 2) no file for languages we add, like the all important en_CA
<ArneGoetje> Riddell: well, that loks like a bug in the export script from rossetta then... no?
<Riddell> ArneGoetje: you tell me, it's your area :)
<ArneGoetje> Riddell: (I don't really know when that file is generated, I hear from its existence for the first time now.
<Riddell> ArneGoetje: don't you have access to the scripts that makes the language packs?
<ArneGoetje> Riddell: I do have access to those scripts which do the final packaging, yes.
<Riddell> ArneGoetje: does grep show up anything?
<Riddell> ArneGoetje: are they public somewhere?
<ArneGoetje> Riddell: I'm searching...
<ArneGoetje> Riddell: seems I need to ask pitti and jtv about those...
<Riddell> ArneGoetje: ok, I expect pitti knows all, he usually does :)
<ArneGoetje> Riddell: the wrong locations seems to be a bug in langpack-o-matic... they are in the extra-files/kde-$lang.tar tarballs. But I have no idea where those tarballs come from...
<Riddell> ArneGoetje: probably unrelated question.  in locale terms what does en@quot and en@boldquot mean?
<ArneGoetje> Riddell: no idea. ask the guy who made it. :P
<ArneGoetje> Riddell: @ just denotes a variant. Means something is different from the default 'en'. What exactly is different can only be found out by looking into the locale file itself.
<glade88> hi.. I recently had multiple X crashes with Kubuntu Intrepid
<glade88> X kept restarting until I did a hard reboot
<Zen_Clar`> How can I find the changes made to a program by the Ubuntu guys?
<dholbach> Zen_Clar`: zless /usr/share/doc/<package>/changelog.Debian.gz
<Zen_Clar`> Thanks.
<liw> evand, or someone else who might know: when usb-creator creates the usb stick, does it put grub on it?
<evand> liw: syslinux
<liw> evand, yeah, found that out later... I had some trouble getting a usb-creator created stick to boot, but I got it to work now
<liw> evand, looking at 274076, by the way
<liw> evand, I am seeing /dev/sdc1 (the usb stick; sda and sdb are SATA hard disks) mounted twice inside initramfs, this is probably a problem
<evand> liw: indeed, I poked at that a bit but didn't get anywhere yet
<liw> evand, I don't see evidence of double-mounting in the casper.log you attached to the bug report, though
<evand> hrm
<liw> evand, but there is a bind mount (which is conspicuosly missing from me): would that be enough to prevent a re-mount?
<emgent> evening
<evand> liw: If it's double mounted, I am pretty sure.
<liw> evand, I tested: a bind mount does not prevent re-mounting
<evand> ah, hrm
<liw> double-mounting the same filesystem is surely an error, so my test is probably irrelevant for the original bug
 * liw reboots the desktop
<liw> evand, I need to leave now, but I'm subscribed to the bug, and would be happy to help when I'm back
<evand> liw: much appreciated.  I'll give it another look over this afternoon after I'm done with ubiquity/grub work.
<evand> anyone else running amd64 experiencing constant flashplugin-nonfree crashes?
<zul> i get sound cutting in and out sometimes
<psypointer> hi
<psypointer> will there be a bugfix for https://bugs.launchpad.net/ubuntu/+bug/181221 in hardy?
<ubottu> Launchpad bug 181221 in kdebase "The application unknown (nspluginviewer) crashed and caused the signal 11 (SIGSEGV) (dup-of: 174343)" [Undecided,New]
<ubottu> Launchpad bug 174343 in nspluginwrapper "Flash player 9.0 r115 crashes nspluginwrapper in Konqueror" [Undecided,Confirmed]
<psypointer> (it also crashs in mozilla)
<Riddell> psypointer: flash is provided by adobe not us
<psypointer> Riddell: yep, i know. but it seems to be a nspluginwrapper issue - on other platforms the flashplayer works ..
<Riddell> if it crashes in mozilla, it's not an nspluginwrapper issue
<psypointer> oh.. damn. it doesn't crash in mozilla. i'm sorr
<psypointer> y
<alkisg> In an acer aspire 5920g laptop, some keys worked in hardy but do not work in intrepid. E.g. the brightness key does change the brightness but also echoes a "Â±"... I have both ubuntu versions installed, can I look for the differences somewhere and file a bug with a proposed fix?
<philipp> hi
<philipp> i encounter a strange issue with 8.10: i have a lot of segmentation fault errors.... software crashes very often....
<kebomix>  i have problem while compress file in ZIP format , it give me this Error "An error occurred while adding files to the archive." , any one help me with that
#ubuntu-devel 2008-10-12
<cathyal> whoever is on x-chat
<RAOF> persia: Was your ping here a couple of days ago re: nouveau?
<persia> RAOF, yes, in the sense of "was the sync a good thing?"
<RAOF> When I saw the intrepid-changes notification, I immediately came in here and asked why it had been syncd :)
<RAOF> s/here/#ubuntu-motu/
<RAOF> I don't think it'll be bad, it just won't build unless we potentially break all free 3d.
<RAOF> (_Still_ needs a libdrm git snapshot)
<RAOF> Oh, and we'd actually need to build the kernel module.
 * Hobbsee wonders why more people aren't test building before uploading.
<RAOF> That's a fair question.
<Hobbsee> particularly for stuff that's never supposed to be working anyway
<persia> So we should probably unsync it?
<Hobbsee> oh, someone has reported the system-occasionally-doesn't-boot bug.  I"ve been meaning to report that
<persia> In the "hardware detection" phase?  I've never been able to reproduce reliably enough to call it a bug.
<Hobbsee> persia: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/263059/
<ubottu> Launchpad bug 263059 in linux "[regression] 2.6.27-6 sometimes fails to boot (iwl3945 issue?)" [High,Confirmed]
<Hobbsee> yeah
<Hobbsee> it's better htan it used to be, though
<persia> Hrm.  That hardware isn't in the device that sometimes hangs for me.
<wgrant> I've never seen it, but I reboot rarely enough that I might not have had a chance.
<Hobbsee> i used to have about 1 boot out of 5 succeed.
<persia> wgrant, That's probably it.  I've never seen it except on things I most use for testing.
<ScottK> lamont`: So now that openexr is built on hppa, I retried kde4libs.  FTBFS twice due to GCC segfaults in different places in the build.  I give up.
<MacSlow> anybody with a clue where polkit-dbus is suppose to come from?
<MacSlow> I can't find it neither at freedesktop.org nor at svn.gnome.org
<MacSlow> thanks in advance!
<james_w> MacSlow: hey, it's part of policykit
<james_w> MacSlow: are you reporting bugs, or just after the source?
<MacSlow> james_w, just needing to compile it
<MacSlow> james_w, no bugs
<james_w> MacSlow: it's built from the policykit source package
<james_w> libpolkit-dbus0 is the package I believe
<MacSlow> james_w, but which configure option causes polkit-dbus to be built and installed?
<james_w> MacSlow: none I think, you just need the dbus libs installed
<james_w> and it's libpolkit-dbus2 for the Intrepid package
<MacSlow> james_w, I'm looking at PolicyKit upstream atm and there is no src/polkit-dbus ... ???
<MacSlow> was that dropped from PolicyKit?
<james_w> it's in the 0.9 version I have here
<james_w> src/polkit-dbus/polkit-dbus.h etc.
<MacSlow> james_w, I grabbed PolicyKit from gitweb.freedesktop.org earlier today and there's no PolicyKit/src/polkit-dbus
<MacSlow> james_w, only the deb source from intrepid has that
<MacSlow> I'm confused
<james_w> so there isn't
<MacSlow> hm... looking at "git log" from upstream PolicyKit libpolkit-dbus was merged with libpolkit
<MacSlow> in july this year
<james_w> http://cgit.freedesktop.org/PolicyKit/commit/?id=2a35667777841f7ea1ef2912963962f04955f9e6
<MacSlow> yeah
<MacSlow> *sigh*
 * james_w hopes this isn't face-browser related :-)
 * MacSlow coughs loudly
<james_w> MacSlow: are you at the hackfest this weekend?
<MacSlow> jup...
<MacSlow> actually the hackfest is over since yesterday and right now is the summit
<MacSlow> I wanted to go to bed, but all that dbus, ck, pk mess is keeping me up
<MacSlow> so polkit-gnome isn't up to speed with polkit
<james_w> is it not?
<james_w> that commit said policykit would be broken for a bit
<MacSlow> polkit-gnome upstream still requires polkit-dbus
<james_w> rubbish
<james_w> how was the UE sprint?
<MacSlow> yeah *sigh*
<MacSlow> intense
<MacSlow> lots of good ideas, lots of work to do
<james_w> excellent
<NCommander> hola persia
<NCommander> ajmitch, I won'tbe able to get to your FTBFS until at least tommorw, I lack access to an Ubuntu box ATM
<ajmitch> NCommander: no rush
 * ajmitch has been looking at other stuff anyway
<NCommander> ajmitch, if you wish it done tongiht, please provide one (1) SSH account to an intrepid box or equivelent ;-)
<NCommander> ajmitch, I can also attempt to teach you about libtool ;-)
<ajmitch> I already know enough to run away screaming thanks
<NCommander> But M4 and shell-independent scripting is awesome :-)
 * NCommander notes though sometimes its easier to port a shell to a system them port a script to a shell
<ajmitch> sigh, looks like the previously useful NZ ubuntu mirror is now horribly out of date
<NCommander> Hrm
<NCommander> ajmitch, a little over a week behind
<NCommander> ajmitch, the other NZ mirror however is only six hours behind
<ajmitch> or more
<NCommander> Launchpad says its only six hours since the last push
<ajmitch> which one are you looking at as the 'other'?
<NCommander> Ubuntu mirror "Ftp-citylink-co-nz"
<NCommander> deb http://nz.archive.ubuntu.com/ubuntu/ YOUR_DISTRO_SERIES_HERE main
<NCommander> "Six hours behind"
<NCommander> nz2 is a week behind
<ajmitch> right, nz2.archive.ubuntu.com used to be a better option
<ajmitch> better peering, same ISP as my home DSL, more frequent updates
<NCommander> Well, launchpad says its still syncing with ftp-master
<NCommander> (last check in 3-4 hours ago)
<ajmitch>      mdadm | 2.6.7-3ubuntu5 | http://nz2.archive.ubuntu.com intrepid/main Sources
<ajmitch>      mdadm | 2.6.7-3ubuntu7 | http://archive.ubuntu.com intrepid/main Sources
<ajmitch> definitely over a week, the mirror admin used to be in the nz loco channel too
<ajmitch> anyway, it's only relevant for my screwed up pbuilder configs now
<NCommander> change .pbuilderc and then pbuilder update --override-config ;-)
<ajmitch> and anything I've had to build :P
<NCommander> It could be worse
<ajmitch> yes
<mcasadevall> james_w, ping
<ScottK-laptop> mcasadevall: So I retired kde4libs on hppa after openexr built (thinks)  FTBFS twice with GCC segfaults in different places in the package.  I think I give.
<StevenK> Yay, ICE
<mcasadevall> Yeah ...
<mcasadevall> Even I would call it quits after that
<mcasadevall> Once NPTL is somewhat more settled on HPPA, it might be possible to help fix up the port
<mcasadevall> Until that time ...
<ScottK-laptop> What decade does that happen in?
<StevenK> When someone cares to fix the toolchain, I guess
<StevenK> hppa is more than able to keep up and not affect general Ubuntu issues -- Dapper proved that
<wgrant> Isn't hppa ahead of ia64 at the moment?
<wgrant> Or is that just because everything fails?
<StevenK> Mostly everything fails on hppa
<superm1> why is it still kept in the buildd farm?  Is there really enough real world usage to justify it?
<mcasadevall> superm1, its probably easier to leave it up than dismantle the buildds
<mcasadevall> StevenK, the main issue is that NPTL on hppa is notoriously unstable, to the point that the Debian port continued using LinuxThreads all the way to glibc 2.7
<NCommander> StevenK, since HP pushes HP-UX on HPPA more than Linux, there has been relatively little corperate support for the architecture as far as I can tell (although lamont would easily know more than I do)
<StevenK> bdale, too
 * NCommander is just sad thatarm still isn't an architecture
<StevenK> No, arm is a body part
<StevenK> :-P
<ScottK-laptop> http://en.wikipedia.org/wiki/Known_Space#ARM
<StevenK> ScottK-laptop: Did you file a kio-sword removal bug?
<ScottK-laptop> StevenK: No txwikinger said he'd do it after he cared for the rdepends.
<ScottK-laptop> There are some sword packages that depend on it and it's in the ichthux meta package.
<StevenK> Ah, kay
<StevenK> Looks like I missed libflashsupport, too
<ScottK-laptop> An action passed is an action completed.  ;-)
<ScottK-laptop> Can't that one be removed?
<StevenK> I dunno, can it?
<StevenK> I think james_w filed removals for pnet and pnet-assemblies, too
<ScottK-laptop> StevenK: Reading debian/changelog for this upload, I think investigating removal is a better use of time than fixing: https://launchpad.net/ubuntu/+source/flashplugin-nonfree/10.0.12.10ubuntu1
<StevenK> desktop-multiplier requires it
<StevenK> But only on i386
<StevenK> ScottK-laptop: It looks like libflashsupport makes Pulse + Flash happier
<superm1> well at least it's supposed to.
<ScottK-laptop> StevenK: From what little I know about it, I think the theory and the practice were different.
<StevenK> ScottK-laptop: I'd like to confirm that first
<ScottK-laptop> Of course
<Hobbsee> StevenK: libflashsupport is generally a pain, and the first thing to do to solve flash-based crashes is to remove it.
<Hobbsee> you don't need it, and it crashes less if you don't ahve it.
<StevenK> Ah ha.
<StevenK> So it should be gotten rid of
<StevenK> ScottK-laptop, Hobbsee: One of you file a bug
<StevenK> :-P
 * ScottK-laptop is roughly one minute from going to sleep, so Hobbsee, would you please?
<wgrant> libflashsupport works fine often.
<StevenK> See. Conflicting information
<Hobbsee> wgrant: do you even use flash? :P
<wgrant> Hobbsee: No, but other family members do.
<Treenaks> On amd64, flash works fine when it works.. but that's only 50% of the time
<Treenaks> the other 50% I get a grey rectangle in the web page..
<Treenaks> ScottK2: (wow, you're high :P)
<Treenaks> ScottK2: (~8611m)
<mdke> asac: I don't think we have any documentation for that type of connection, so it shouldn't be a problem. But the thing to do is to email the ubuntu-doc mailing list; there is someone who takes particular care over the internet documentation so he will take a look
<ogra> Keybuk, did udev drop /dev/video support ?
<ogra> grep video /etc/udev/rules.d/* doesnt reveal any rule that would create a /dev/video0 apparently
<ogra> hmm, might as well be the kernel, i dont even see my webcam with the current uvcvideo driver anymore
<TuX_Claudiu> hi, i have a problem, i'm unable to find my floppy device in /dev, i tried to install my grub on floppy, but i don't have any floppy in /dev how do i fix this ?
<TuX_Claudiu> i'm using ubuntu 8.10
<persia> TuX_Claudiu, Have you tried #ubuntu+1 ?
<TuX_Claudiu> nope
 * ogra really doesnt get where his webcam went ... 
<ogra> i dont even see it in lsusb anymore
<ogra> The following NEW packages will be installed:
<ogra>   autotools-dev{a} bsdmainutils{a} debhelper{a} ...
<ogra> hmm, what does the {a} mean ?
 * ogra hasnt seen that before
<ion_> Automatically installed, probably.
<persia> Indeed.  Automatic.  It means they will be automatically removed when rdepends are removed.
<persia> (theoretically : the logic isn't quite perfect)
<ogra> well, makes sense
<ogra> hmm
 * ogra wonders why the profile bootoption doesnt create any readahead file anymore
<ogra> ogra@osiris:~$ ls -l /etc/readahead/boot
<ogra> -rw-r--r-- 1 root root 0 2008-10-12 17:25 /etc/readahead/boot
<persia> ogra, Are you about for a bit?
<ogra> persia, probably rebooting here and there, but apart from that, yes
<persia> ogra, we're discussing bug #281984 in -motu, and think we have a fix : otherwise network breaks on upgrade for most users (we think), and doesn't restore unless network manager is working.  Could you sponsor it once the testing is complete?
<ubottu> Launchpad bug 281984 in ifupdown "Updating ifupdown to 0.6.8ubuntu10 breaks non-NM configurations that have /etc/NetworkManager/nm-system-settings.conf" [Critical,In progress] https://launchpad.net/bugs/281984
 * ogra looks
<ogra> did you talk to asac ?
<ogra> seems he is running an outdated version of NM
<james_w> he's not running NM
<ogra> well, thats required
<ogra> afaik
<james_w> what's required?
<ogra> nm
<james_w> join -server and say that :-)
<ogra> ofr setting routes etc
<ogra> it wont touch static devices, but manages all setting beyonf that
<ogra> *beyond
<persia> ogra, No, the logic is wrong.  It *always* manages all devices, even when it's not installed.
<ogra> well, that case should simply not happen :)
<ogra> it should be installed
<persia> apt-get install network-manager && apt-get remove network-manager
<ogra> at least the commandline pieces, you dont need the applet
<persia> Not on a server.
<persia> For Jaunty, network-manager might be able to go on a server, but 0.7 doesn't do system-level stuff yet : it's still session-level.
<ogra> nope
<ogra> since 0.7 it does all the system level stuff
<persia> Oh, right, but we have 0.6.8.
 * persia was confused.
<ogra> nope
<ogra> we have 0.7 in intrepid
<persia> ifupdown (0.6.8ubuntu10) intrepid; urgency=low ... Alexander Sack <asac@ubuntu.com>  Thu, 09 Oct 2008 16:46:47 +0200
<ogra> ogra@osiris:~$ dpkg -l network-manager|grep ii
<ogra> ii  network-manager                            0.7~~svn20081008t224042-0ubuntu2      network management framework daemon
<persia> *you* have 0.7 installed.
<ogra> yes, from the standard archive
<persia> Oh, so do I.  Now I'm very confused.
<ogra> with the recent updates
 * persia looks at the seeds
<ogra> it can even set your hostname etc
<ogra> (which i think alex patched out for now)
<persia> Looking at the seeds, it appears that network-manager is only installed for kubuntu, ubuntu desktop, ubuntu mid, ubuntu mobile, and xubuntu (although I don't have a local copy of the mythbuntu seeds : I should fix that)
<ogra> well, what exactly the prob now ?
<superm1> persia, it is installed for mythbuntu as well
<james_w> if I have a remote server, and I once installed network-manager, and then removed, but did not purge it, and I upgrade to the latest ifupdown and reboot
<ogra> if the user has created a /etc/NetworkManager/nm-system-settings.conf thats his own fault
<superm1> persia, in our desktop seed: desktop: * (network-manager-gnome)
<persia> If /etc/NetworkManager/nm-system-settings.conf is present, and network-manager not installed, ifupdown doesn't manage interfaces
<ogra> why would it be present ?
<james_w> then it will see /etc/NetworkManager/nm-system-settings.conf and "ifup -a" won't work, so I won't get networking on boot
<persia> apt-get install network-manager && apt-get remove network-manage
<jcristau> ogra: because nm is removed but not purged.
<ogra> unless you played with it, in which case i exepct you to know how to cleanly remove it
<persia> ogra, Except the standard advice for quite a while when dealing with network-manager issues was to remove it.
<ogra> jcristau, well, if you are able to install it on a server to tiner with it i wuld expect you to be capable to bring your system into a clean state
<ogra> *tinker
<james_w> ogra: ok, how about I don't want nm to manage my devices to I edit that file and delete the managed line? In that case neither nm nor ifupdown will manage my devices, again giving me no networking
<ogra> why would you want to have that file at all ?
<jcristau> ogra: and other people expect removed packages to not get in the way
<ogra> if it doesnt exist ifupdown DTRT
<ogra> as well so if you installed it and it has the right option in it (which is the default)
<ogra> the only breakage will happen if you *manually edited the file*
<persia> ogra, OK.  Let's ignore that.  We've a logic test that looks for the string "managed" and defaults to true if the string isn't found.  Surely that's a bug, right?
<ogra> or if you used a development version of NM in which case i would expect you to know that you use a *development* version and can cope with it
<persia> (it also returns true if the string is found)
<ogra> persia, no, since managed is *off* in the default file since two versions of NM
<ogra> the only way that breaks is that you had installed NM durin the dev cycle
<persia> ogra, Ignore the context.  The logic in the check is wrong.
<ogra> the current package and the released version will have the right setting ... so it doesnt matter if the file is removed or not
<ogra> since it will always default to make ifup -a work
<ogra> WARNING: ifup -a is disabled in favour of NetworkManager.
<ogra>   Set ifupdown:managed=false in /etc/NetworkManager/nm-system-settings.conf.
<persia> ogra, No, because the logic is wrong.  Instead of defaulting to make ifup work, it defaults to break ifup.
<ogra> is what the bug says
<ogra> no
<persia> Yes, the bug doesn't describe the issue very well.
<persia> Read the code.
<ogra> it defaults to make ifup -a work
<persia> "int managed = iniparser_getboolean (ini_dict, "ifupdown:managed", -1);" shoud be "int managed = iniparser_getboolean (ini_dict, "ifupdown:managed", 0);"
<ogra> because either the file doesnt exist or it has "ifupdown:managed=false"
<persia> By passing "-1" as the default, the default for managed becomes TRUE
<james_w> ogra: of course they are not the only two cases
<ogra> james_w, what are the others ?
<ogra> if you have changed the file manually i expect you to know what you are doing ... the same goes for an unreleased ubuntu version
<persia> Right.  Ignore the context.
<persia> The behaviour you describe is how it should work.
<ogra> the bug itself, being  "ifupdown:managed=true" is fixed
<persia> It's not how it currently works.  It currently defaults to TRUE.
<ogra> if a user removed nm before the fix went in he might have that setting as true, but thats the nature of a development release, it has bugs and you are supposed to be able to cope with that or not use a unreleased distro
<james_w> ogra: while the defaults may work fine, the system fails open, as you can end up with nothing managing your interfaces.
<ogra> persia, it doesnt
<persia> ogra, -1 doesn't evaluate to TRUE in C?
<ogra> ogra@osiris:~$ grep true /etc/NetworkManager/nm-system-settings.conf
<ogra> ogra@osiris:~$
<persia> ogra, Right.  No issue there.  It's the check in ifupdown that has the issue.  "int managed = iniparser_getboolean (ini_dict, "ifupdown:managed", -1);" shoud be "int managed = iniparser_getboolean (ini_dict, "ifupdown:managed", 0);
<ogra> if the file exists it will by default be false
<ogra> if the file doesnt exist it doesnt matter at all
<james_w> ogra: while a user should be expected to be able to fix things if they are running a development release, can't we fix things when it is a clear bug, we know the fix, and it is small and non-invasive?
<persia> The code is passing -1 as the default value.  That's TRUE.  It doesn't matter what is in the configuration.
<ogra> james_w, all i say is that NM is fine
<james_w> ogra: I agree, the bug is in ifupdown, I've never said nm was doing anything wrong.
<ogra> well, ask asac what he thought :)
<ogra> he made the ifupdown change
<james_w> ogra: it's a small logic bug in the change he made. I doubt someone would pass "-1" if they wanted a true value, "1" would be much more usual.
<james_w> right, the user that reported the bug confirms the fix, is a core-dev willing to upload the fixed package?
<cjwatson> Riddell,ArneGoetje: en@quot and en@boldquot are variants of English messages with different kinds of quotation marks; run 'info gettext' and press Ctrl-s @quot
<cjwatson> Riddell,ArneGoetje: I think you have to go through some contortions to get them to work in Ubuntu though; they at least don't seem to work out of the box, unless I'm missing something. I wouldn't worry about them
<ogra> james_w, if it doesnt break the behavior :)
<ogra> james_w, there is still time to revert it, i would go ahead
<james_w> ogra: nope, it shouldn't break anything that currently works
<james_w> ogra: well, I can't go ahead, I'm asking for someone to sponsor it.
<ogra> oh
<ogra> james_w, you are not core-dev ??
<ogra> geez ... about time, eh ? :) where is the fix
<james_w> I've only been a MOTU for two weeks :-)
<james_w> the fix is in the bug report
<persia> And we're *very* glad to have you :)
<ogra> the bugreport is a ranting chaos ...
<persia> Ignore the report.  The fix is good.
<ogra> ah
 * ogra had to reload the report :)
<ogra> uploaded
<persia> ogra, Thank you.  Sorry for the confusion of the report.
<ogra> yeah, the anti NM ranting got me quite confused
<james_w> thanks ogra
<ogra> lest see if asac kills me tomorrow :)
<persia> ogra, If he complains, just blame james_w :)
<ogra> the changelog already does that enough i think :)
<james_w> persia told me too :-p
<persia> OK.  Blame me then :)
 * persia looks for another changelog entry to avoid being in
 * ogra cries ...
 * ogra wants his webcam back
<stgraber> oh, you broke a webcam ?
<stgraber> or just the driver :)
<ogra> stgraber, its simply gone
<ogra> i have a builtin cam in my display frame on the laptop
<dmb> any of you know the last release that used linuxthreads as opposed to nptl?
<stgraber> ogra: USB wired (as in, it's exposed as a usb device) ?
<ogra> i cant see it anymore, not in lsusb nor in lspci or any other HW detection tool
<ogra> it used to use uvcvideo and was/is a usb device afaik
<ogra> i only used it once to test it in hardy
<ogra> loading uvcvideo doesnt reveal anything in dmesg either
<stgraber> hmm, ok. I have some uvcvideo webcams at the office, I'll give that a try tomorrow. Though last video conference we had (1-2 weeks) it worked correctly.
<ogra> well, there is also a transition away from /dev/video going on apparently
<ogra> but that still doesnt explain why lsusb doesnt see it
 * ogra gets a hardy livecd
<evand> slangasek: is there a trick to preparing grub from bzr for an upload?  The clean rule removes files that are in the repository.
<directhex> dmb, has ubuntu EVER done that?
<directhex> dmb, NPTL became the norm when 2.6 kernels became the norm
<slangasek> evand: well, I use bzr builddeb, and never run the clean rule in my working directory
<fbond> Hi, I just upgraded to Intrepid and am seeing some funny issues with my network.  I'm trying to debug to see if I can figure out exactly where the problem is.  I suspect the b43 driver.  I have a wireshark trace of the problem.  Is anyone able to assist me in debugging?
<fbond> Actually, nm, let me do some process-of-elimination tests to implicate b43...
<evand> yay, after struggling with bzr bd for a bit, I got it working.  Thanks slangasek
<Chipzz> fbond: 1) it's weekend and 2) #ubuntu+1 (cfr topic)
<superm1> StevenK, well given bug 281580 we might have to bring a bluez-compat package it looks.  I'm definitely against putting those binaries in the main package though.
<ubottu> Launchpad bug 281580 in mactel-support "[Intrepid] New Bluetooth Wizard fails to pair with Apple Keyboard..." [Medium,New] https://launchpad.net/bugs/281580
<superm1> StevenK, i've got two of these keyboards though, i'll experiment with them in the wizard.  i know they are finicky to get into pairing mode sometimes
<superm1> oh well actually mine are both aluminum, the newer ones.
<emgent> ScottK-laptop: ping
<dmb> directhex, just trying to build this application that depends on linuxthreads
<dmb> sheepshaver for ppc requires linuxthreads, or it crashes
<dmb> well, not crashes, but errors on the build
<cjwatson> I think in early releases of Ubuntu we did build with 2.4 compatibility in glibc for at least some architectures, which resulted in linuxthreads by default
<dmb> cjwatson, you happen to know which release possible for ppc?
<cjwatson> I'm looking, but it's sort of hard to tell at this distance
<dmb> yeh
<cjwatson> certainly no later than dapper, probably earlier
<dmb> yeh, i looked into dapper, uses nptl there also
<cjwatson> nothing really has any excuse for still requiring linuxthreads
 * cjwatson fishes down ancient .diff.gzs from LP
<dmb> cjwatson, indeed, basically, what they did was copy and paste some stuff from linuxthreads into there implementation, changed the structs a bit, and some more
<dmb> obviously bad programming practice
<cjwatson> dmb: I'd have to actually build a chroot to be sure of it, but it looks to me as if we enabled NPTL on powerpc in Ubuntu 5.10
<dmb> hmm
<dmb> you can usually tell by looking at at the libc6-dev package and looking at /usr/include/pthread.h and seeing if in the comments it mentions linuxthreads
<dmb> where can you find the old release stuff?
<dmb> its not in archive.ubuntu.com
<cjwatson> phone
<cjwatson> dmb: I was looking at the source packages, not the binaries, so I was looking for debian/sysdeps/powerpc.mk
<cjwatson> with GLIBC_PASSES and/or *_add-ons variables mentioning nptl
<cjwatson> dmb: https://launchpad.net/ubuntu/+source/glibc has the publishing history - only the final release and some post-release updates for pre-dapper, but good enough for this purpose
<dmb> oh
<cjwatson> dmb: installable archives of end-of-life releases are at http://old-releases.ubuntu.com/ubuntu/
<cjwatson> so you could probably double-check libc6-dev from there
<jspiro> just curious: do you offer downloadable preinstalled VMs of ubuntu?
<cjwatson> jspiro: http://isv-image.ubuntu.com/vmware/ has VMware images for some older releases, although not for 8.04 (yet? I'm not sure, I don't run that site any more)
<jspiro> cjwatson:  cool, they should market that site more for home users who want to run Ubuntu in VMware to try it.
<cjwatson> I believe it's actually quite prominent in the VMware appliances download site
<cjwatson> at least it used to be
<gaspa> cjwatson, pitti: i've patched usplash for #219867 (and probably other)...
<gaspa> basically 'status' overflow without any check.
<gaspa> but i'm wondering what's the expected behavior with a status command that overflow...
<cjwatson> well, presumably there are two bugs here
<cjwatson> one is that usplash just leaves text hanging around the screen on overflow, rather than either cutting it off or arranging to scroll it
<cjwatson> the other is that initscripts prints a message that we know will overflow usplash
<cjwatson> I'd be inclined to say that usplash should cut off the message at the borders of the region it's going to scroll; pitti might feel differently
<gaspa> cjwatson: well, the problem is in the fsck steps. classical initscript behave correctly.
<cjwatson> it's in /lib/init/usplash-fsck-functions.sh, right? that file is owned by the initscripts binary package
<gaspa> yep.
<gaspa> cjwatson: couldn't we wrap status too? I simply did this way. ( I'm ready to change my patch as well )
<gaspa> ... probably it involves problems with newlines, or redrawing of the status...
<cjwatson> gaspa: well, that would work too I guess
<cjwatson> it's been a bit too long since I was in the internals of usplash to say
<cjwatson> I'd rather pitti reviewed it
<cjwatson> (if he has time)
<gaspa> ok, i'd ask him what he think about that...
<ogra> bah, no bluetooth love at all on my laptop
 * ogra just tried his dongle for the first time with the new bluez stack ... but it looks more loike blues than bluez
<asac> ogra: persia: whats up on the front? is my iniparser wrong and should use ,0?
<asac> james_w: ^^
<james_w> asac: yeah, I believe so, I requested the upload of that change
<asac> james_w: do you have that change somewhere?
<asac> james_w: or was it uploaded?
<james_w> asac: it was uploaded, you can find the diff attached to bug 281984
<ubottu> Launchpad bug 281984 in ifupdown "Updating ifupdown to 0.6.8ubuntu10 breaks non-NM configurations that have /etc/NetworkManager/nm-system-settings.conf" [Critical,Fix released] https://launchpad.net/bugs/281984
<asac> james_w: look at the debdiff ;)
<asac> http://launchpadlibrarian.net/18464705/ifupdown_0.6.8ubuntu10_0.6.8ubuntu11.diff.gz
<asac> whoever uploaded it, eliminated the _darcs directory :-P
<james_w> oops, yeah, I should have warned them about that
<asac> james_w: well. i bumbed into this and it wasnt really nice
<bunnyto> I LOVE you guys... i LOVE UBUNTU!!! if you all were girls i would....
<asac> i mean that things refused to not remove _darcs unless i built with -iNOTHING -INOTHING :)
<james_w> heh :-)
<asac> anyway. i think we should resurrect that.
<asac> whats the reason to change dpkg-source in such a way that it removed _darcs automatically?
<ogra> asac, my fault, what did i do wrong ?
<jspiro> bunnyto:  thank you.
<jspiro> i guess
<jspiro> see, the only problem with your comment is that i'm a guy.
<jspiro> :)
<asac> ogra: you bumped into the (imo) new behaviour that you need to add a fake -iNOTHING -INOTHING in order to make dpkg-source keep your vcs dir ;)
<asac> ogra: i will resurrect that. so not a big problem..
<ogra> i pulled the source package, dpkg-source -x'ed, cd'ed into it, ran patch -p1 <../blah.diff and ran dpkg-buildpackage
<ogra> ouch, ok
<asac> ogra: yeah. dpkg-buildpackage will strip _darcs if you dont tell different
<ogra> ok, i'll keep that in mind, really sorry for that
<asac> ogra: i was quite confused when reviewing my debdiffs before uploading
<asac> ogra: heh. no problem at all ;)
<bunnyto> is possible to upgrade from 8.04 to 8.10 ?
<pwnguin> bunnyto: yes. #ubuntu+1 can help you with that
<bunnyto> thanks guys!! keep the good work!!! damn.. i wish you all were girls.. dammit.... i would... THANKS!!
<jmillikin> I have a one-line patch that I'd like to get into gst-plugins-base package; is that easy? There's an off-by-one error that's preventing all my album art from displaying.
<jmillikin> Reported upstream at http://bugzilla.gnome.org/show_bug.cgi?id=556066 , but haven't bothered with a launchpad bug
<ubottu> Gnome bug 556066 in gst-plugins-base "Last byte of FLAC image buffer chopped off" [Normal,Unconfirmed]
<johanbr> How does usb-creator determine what's a USB disk? It doesn't seem to want to recognize my SD card.
<pwnguin> uh
<pwnguin> it depends on how your system is built
<pwnguin> sometimes, SD readers will export USB mass storage to the OS
<cjwatson> it looks in hal: storage.bus == usb, storage.removable, and storage.drive_type == disk
<pwnguin> sometimes, they expect drivers to handle the real work.
<johanbr> Yes I just found "if (dev.PropertyExists('storage.bus')"
<johanbr> Whereas my SD card has   storage.bus = 'mmc'  (string)
<pwnguin> that would be not usb
<cjwatson> pwnguin: you're stating the obvious a bit :)
<cjwatson> johanbr: bug 280336
<ubottu> Launchpad bug 280336 in usb-creator "support for SD cards and removable media" [Undecided,New] https://launchpad.net/bugs/280336
<johanbr> cjwatson: Oh, someone beat me to it. :) Thank you.
<cjwatson> seems to be the same
<cjwatson> interestingly storage.removable == false there
<pwnguin> cjwatson: ok, captain knows everything; whats the difference between sd boot and usb boot?
<cjwatson> pwnguin: does it matter? if the BIOS supports it, it would be nice for usb-creator to be able to generate bootable images on it
<johanbr> pwnguin: Well, your bios needs to able to boot from your card reader for the former.
<cjwatson> pwnguin: and if you're going to be rude you can leave
<johanbr> And I also have storage.removable == false. That sounds like a bug somewhere.
<cjwatson> yeah, I think I agree there
<cjwatson> though I wonder if it's necessary for usb-creator to check storage.removable
<cjwatson> johanbr: storage.removable.media_available is true though
<cjwatson> (at least in newz2000's lshal)
<johanbr> same for me
<johanbr> I suppose it's true that the reader itself it not removable. At least not very easily. :)
<johanbr> *is not
<cjwatson> the definition of storage.removable in hal-spec-properties is "Media can be removed from the storage device", though
<pwnguin> removable versus hotpluggable
 * ogra sighs ... i knew i had the solution how to prevent the stripping of translations from sourcepackages but i cant find the runes to put into debian/rules anymore
<cjwatson> hmm
<cjwatson>          * As discussed on lkml, GENHD_FL_REMOVABLE should:
<cjwatson>          *
<cjwatson>          * - be set for removable media with permanent block devices
<cjwatson>          * - be unset for removable block devices with permanent media
<cjwatson>          *
<cjwatson>          * Since MMC block devices clearly fall under the second
<cjwatson>          * case, we do not set GENHD_FL_REMOVABLE.  Userspace
<cjwatson>          * should use the block device creation/destruction hotplug
<cjwatson>          * messages to tell when the card is present.
<cjwatson> (drivers/mmc/card/block.c)
<pwnguin> so does that mean usb is broken?
<johanbr> What does "removable block device" mean in this context?
<pwnguin> probably device node
<cjwatson> I don't have the lkml context, dunno
<pwnguin> ie /mnt versus /media
<cjwatson> ogra: export NO_PKG_MANGLE=1
<cjwatson> neither /mnt nor /media is a device node ...?
<ogra> my builtin readers are all plain PCI devices
<ogra> not attached to USB
<ogra> cjwatson, thanks a lot, i searched myself to dead
<pwnguin> cjwatson: what i mean is that /mnt is expected to be static, and /media is "removable media"
<johanbr> This discussion has nothing to do with mount points.
<cjwatson> pwnguin: hmm, that just takes us back to the question though
<bunnyto> when is going to be released 8.10?
<pwnguin> but indeed, the lkml context would be helpful
<cjwatson> bunnyto: http://wiki.ubuntu.com/IntrepidReleaseSchedule
<ogra> https://wiki.ubuntu.com/IntrepidReleaseSchedule
<ogra> heh, to slow
<pwnguin> cjwatson: what i can see though, is that hotpluggable is set for both my sd card and usb drive
<johanbr> Think I found the lkml discussion: http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/be696fb615c95ddf
<cjwatson> so I think "permanent block devices" means that /dev/cdrom is the same no matter what CD you insert, and doesn't change depending on the media
<cjwatson> I'm not familiar with how MMC is different
<johanbr> "However, when we insert and remove a MMC card, we create and destroy the block device itself.  Therefore, as far as the block layer is concerned, the device itself is being inserted and removed, so telling the block layer that the media is removable is just silly."
<cjwatson> anyway, a different question is what usb-creator is trying to achieve with this check
#ubuntu-devel 2009-10-05
<virtuald> d- as in cd-rom? it's just another acronym nobody understands
<Pici> disk-bus
<jdong> desktop bus.
<jdong> or probably just the D bus these days
<chrisccoulson> james_w - do the reporters get a dialog with what looks like a D-Bus error in them?
<lamont> cjwatson: bug 442480 closed
<ubottu> Launchpad bug 442480 in console-setup "Recent update to console-setup is causing packages to FTBFS" [Undecided,New] https://launchpad.net/bugs/442480
<cjwatson> lamont: thanks
<lamont> cjwatson: you OK with a mass-giveback?
<cjwatson> mass give-back as long as it's zero-score would be fine, I think. The queue was kinda long last I checked
<lifeless> what package should rfkill switch bugs be filed on? my D430 kill switch kills the bluetooth & wifi, but when the normal position is restored it doesn't re-enable them
<lifeless> so, one needs to do "echo 1 | sudo tee /sys/devices/virtual/rfkill/rfkill1/state" which is a little kludgy
<ScottK> lifeless: Works here (also D430)
<ScottK> lifeless: 32 bit or 64 bit?
<lifeless> ScottK: 64
<superm1> lifeless, there is a bug already opened on that
<ScottK> Hmmm.  I'm on 32
<lifeless> superm1: ok, cool
<superm1> it's a kernel bug against the dell-laptop kernel module
<lifeless> superm1: for the record, where should I have looked?
<lifeless> superm1: thanks
<superm1> lifeless, bug 430809
<ubottu> Launchpad bug 430809 in linux "[Dell Latitude D430, iwl3945] Wireless can't be activated after disabling kill switch" [High,Triaged] https://launchpad.net/bugs/430809
<lamont> Preparing to replace texlive-latex-base 2007.dfsg.2-4ubuntu1 (using .../texlive-latex-base_2007.dfsg.2-4ubuntu1_all.deb) ...
<lamont> Reinstalling deleted mandatory conffile color.cfg
<lamont> cp: cannot stat `/usr/share/texlive-base/color.cfg': No such file or directory
<lamont> dpkg: error processing /srv/royal.buildd/home/buildd/build-karmic-autotest/chroot-karmic-autotest/var/cache/apt/archives/texlive-latex-base_2007.dfsg.2-4ubuntu1_all.deb (--unpack):
<lamont>  subprocess pre-installation script returned error exit status 1
<lamont> dear texlive.  DIEDIEDIE
<lamont> was that my outside voice?  sorry
<lamont> meh.  nm
<qw30> Gnometris 2.28.0 is a PIECE OF SHIT!
<qw30> it doesn't do SHIT
<Amaranth> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<qw30> the game area
<qw30> doesn't do
<qw30> SHIT
<hyperair> heh what's this about?
<qw30> in the terminal I get
<qw30> (gnometris:8489): ClutterGLX-CRITICAL **: Unable to make the stage window 0x4400042 the current GLX drawable
<qw30> Does anyone know what this shit means?
<Kalifa> '-'
<qw30> OH BOB SAGET!
<jdong> O_O
<LaserJock> so gwibber seems quite messed up these day :/
<LaserJock> is it going to make it into the final release as default?
<LaserJock> and I'm not understanding the gwibber-daemon thing
<superm1> dtchen, when you get a min can you pop in #mythtv to chat a little about the current situation with pulseaudio w/ mythtv and karmic.  see http://svn.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/audiopulseutil.cpp for what's currently being done about it
<geofft> any ~ubuntu-sru people here? I'm waiting for an SRU for... almost two months? :-(
<m4t> hi. im in the process of compiling an older cross compilation toolchain. several things fail with gcc-4, so i installed gcc-3.4 and have been passing it via CC=gcc-3.4
<m4t> i'm wondering though, if there is a way to manage symlinks in /usr/bin, eg, to have gcc point to 3.4 then be able to switch it back to 4.x
<m4t> update-alternatives doesn't seem to recognize 3.4 as a provider of 'cc'
<geofft> Mine is a symlink to gcc-4.3 directly; it doesn't use update-alternatives (/etc/alternatives/gcc)
<geofft> so I'd just change the symlink by hand.
<m4t> actually you're right about it not using that
<m4t> i forgot about the symlink chain that would point to an intermediate link in /etc
<somebody__> Hi, is it possible to catch N-key rollovers and have them passed to an application?
<somebody__> Please
<somebody__> By the way
<somebody__> Hello
<sharms> somebody__: wrong channel for that question, I would find a programming related channel
<somebody__> They said in #perl that it depends on the OS's handling
<somebody__> I've been to programming and back
<m4t> cool wel the toolchain built
<m4t> thanks
<jdong> somebody__: Ubuntu OS related questions still don't go here...
<jdong> this is for development OF Ubuntu, not ON Ubuntu or FOR Ubuntu
<somebody__> I'm trying to add this application to my official stack for Ubuntu
<somebody__> It will help the many that use Ubuntu
<jdong> well once you are ready to begin packaging of the software, #ubuntu-motu would be glad to help
<jdong> but this place is not the right place to ask Ubuntu related programming questions; the topic is for coordination of the development of ubuntu itself
<jdong> developers tend to read everything that's said in here and would appreciate a better signal to noise ratio
<somebody__> For goodness sakes. The other channel is noisy and being of no help
<geofft> besides, people in here probably don't know as much about GUI stuff with perl as they do about systems programming :)
<somebody__> Do you have any idea what kind of noise a screen reader can generate when in an IRC room
<somebody__> ?
<somebody__> I am trying to improve Ubuntu as a whole for those in my comunity
<jdong> that isn't the topic of this channel either.
<somebody__> Is that really a crime
<somebody__> ?
<ScottK> somebody__: It's not a crime, but trouble getting help elsewhere doesn't magically put your question on topic for this channel.
<somebody__> Which channel is it on topic for then?
<somebody__> I'm not here to cause trouble
<somebody__> I've been Googling for some time now and this is my last resort
<somebody__> If you have a lead for me to follow, by all means post it here
<nixternal> somebody__: I would look at handling via xorg input for the keyboard..also find the source for 'stickey support' in KDE as it has rollover stuff in there but I am sure is probably used via the Solid library for KDE...I don't know of any floss apps that support it to even look at...maybe find some old games that have since been open sourced that might have supported it...but ya, I have to agree a bit, this chan isn't best suited for this 
<somebody__> Thanks fo your help
<dholbach> good morning
<dholbach> slangasek: did you have a chance to check out the acpi-support sponsoring bugs?
<dholbach> 425155 and 432578
<pitti> Good morning
<stvo> pitti: good morning
<pitti> hey stvo
<pitti> kees: xsplash> yes, both you and lool ignored Vcs-Bzr:; I'm committing both of your changes now, but please do respect it in the future, otherwise we'll continue to drop patches
<pitti> kees: why is setresuid() any better than setuid()? I find the latter easier to use, and it should do the same for a root process
<dholbach> what does the release team say about bug 440203
<ubottu> Launchpad bug 440203 in onboard "Freeze Exc. Req. - New release - diff.gz supplied" [Undecided,New] https://launchpad.net/bugs/440203
<lool> pitti: Yeah sorry, I realized there was one when kees mentionned it in a random other bug; I think I was too stressed by the beta critical issue and just uploaded
<pitti> don't worry, committed now
<lool> thanks
<ebroder> Anybody from ubuntu-sru around who could ACK bug #330766? It's affecting our site deployment, and we've already tested the fix
<ubottu> Launchpad bug 330766 in pulseaudio "pulseaudio hangs, prevents login, home as ntfs" [Unknown,Fix released] https://launchpad.net/bugs/330766
<hyperair> hmm lyx seems to fail miserably with ibus
<hyperair> at least, with ibus active, the open/save dialogs don't work
<al-maisan> Good morning!
<chrisccoulson> hey dholbach - about bug 406077:
<ubottu> Launchpad bug 406077 in gnome-python-extras "Should build gda module" [Wishlist,Confirmed] https://launchpad.net/bugs/406077
<chrisccoulson> i've done a MIR already for this one - bug 432715
<ubottu> Launchpad bug 432715 in libgda4 "[MIR] libgda4" [Wishlist,Fix committed] https://launchpad.net/bugs/432715
<sianis> hi
<dholbach> chrisccoulson: ah ok
<dholbach> chrisccoulson: I'll let seb128 decide :)
<dholbach> or somebody else desktop-y
<seb128> dholbach, what?
<seb128> dholbach, ETOOMUCHTODO
<chrisccoulson> dholbach - thanks:)
<dholbach> seb128: python-gda built from gnome-python-extras
 * seb128 fighting over 1000 bug emails from the weekend
<seb128> dholbach, I let you decide ;-)
<dholbach> so glom can be built
<dholbach> bah
<seb128> what is to decide?
<seb128> doit?
<dholbach> yeah, doit probably
<dholbach> I didn't review too closely
<seb128> did anybody see bug #442348 before?
<ubottu> Launchpad bug 442348 in gdm "GDM doesn't let live user (casper) entering live system" [Undecided,New] https://launchpad.net/bugs/442348
<seb128> dholbach, the changes looked fine to me when I reviewed those some days ago
<darkham> please change the splash...
<darkham> i know you can do MUCH better...
<darkham> :)
<Amaranth> darkham: Unless you have an alternative you want us to look at this is the wrong place
<dholbach> bug-report-via-irc is not supported yet :)
<darkham> Amaranth, http://www.youtube.com/user/madsrosendahl#play/uploads/3/XlCVrtgxVcI
<darkham> please contact him, they've many good ideas
<Amaranth> darkham: We don't know how long the boot will take so that animation is impossible
<Amaranth> and way too over the top
<darkham> the animation can't be in syncro withn boot?
<darkham> it can't be clocked?
<AnAnt> Hello, I have a question about texlive
<AnAnt> I see ubuntu did a change to texlive-base
<AnAnt> http://changelogs.ubuntu.com/changelogs/pool/main/t/texlive-base/texlive-base_2007.dfsg.2-4ubuntu1/changelog
<AnAnt> I suspect that Debian recently fixed this bug in texlive-bin instead: http://packages.debian.org/changelogs/pool/main/t/texlive-bin/texlive-bin_2007.dfsg.2-7/changelog
<AnAnt> the bug is something to do with "5-years is too old"
<cjwatson> presumably it's not that important exactly where it's fixed, and we can just resync in lucid?
<AnAnt> ok
<AnAnt> another thing, I filed a bug LP 438031
<ubottu> Launchpad bug 438031 in texlive-bin "texlive-bin won't compile against libpoppler 0.12" [Undecided,New] https://launchpad.net/bugs/438031
<AnAnt> I suspect that luatex too won't compile against libpoppler 0.12, since it has the same problematic code portion that is in texlive-bin
<AnAnt> but I didn't try yet
<pitti> Riddell: can you ack/nack bug 442571?
<ubottu> Launchpad bug 442571 in kipi-plugins "FFe for kipi-plugins 0.7.0" [Wishlist,New] https://launchpad.net/bugs/442571
<Riddell> I can, he's got another one coming up too
<Amaranth> Riddell: So how many bug reports did you get about amarok not being installable? :)
<pitti> Keybuk, cjwatson: does https://code.edge.launchpad.net/~tormodvolden/casper/inspect-dm/+merge/11423 look sensible to you? I'm afraid I don't know too much about the boot mount process to see possible regressions
<cjwatson> pitti: I was already in the middle of reviewing that
<pitti> nice timing, thanks
<ebroder> Can someone from ubuntu-release look at bug #429445?
<ubottu> Launchpad bug 429445 in zephyr "[Karmic FFe] Sync zephyr 3.0~rc.2544-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/429445
<lucas> siretart: gah, I meant ruby1.9, not 1.9.1...
<lucas> could someone give-back ruby1.9 on i386? it failed in an unexpected way, and built fine everywhere else
<pitti> lucas: done
<pitti> hi tkamppeter
<Riddell> Amaranth: havn't noticed any, what's wrong with it?
<Amaranth> Riddell: Last time I checked it depended on amarok-common which doesn't seem to exist
<tkamppeter> pitti, hi
<Amaranth> Riddell: weird, must have been an archive issue because the source package says it should exist and it does now without any changes to the package
<Amaranth> But all weekend people were popping into #ubuntu+1 asking about it
<cjwatson> maybe it was in universe
<cjwatson> or maybe it was in the NEW queue
<cjwatson> the latter's actually quite plausible - since it's an architecture: all binary package, non-i386 users would have seen amarok being uninstallable until amarok-common passed through NEW
<Amaranth> cjwatson: That would be exactly it
<Riddell> nothing new about it, probably amd64 buildds were ahead of i386
<pitti> tkamppeter: did you recently see bug reports about graphics in PDF files not being printed? I just filed bug 443026, and wondered how widespread the regression is
<ubottu> Launchpad bug 443026 in cups "Does not print graphics in PDF documents; after pdf2ps it works" [Undecided,New] https://launchpad.net/bugs/443026
<tkamppeter> pitti, I see this for the first time now. The only way to discover what is happening is to run the filters one by one to find the culprit. PDF handling software seems to be EXTREMELY fragile and doing one change seems to introduce 20 regressions. Here a good regression testing infrastructure needs to be introduced.
<cjwatson> pitti: I can't seem to get the fix for bug 395079 working. I'm trying http://paste.ubuntu.com/286135/, but gnome-mount -o locale=en_GB.UTF-8 still seems to be just ignored; and I don't understand how volume.fstype.alternative gets used, given that in Ubuntu we want ntfs-3g to be the default NTFS implementation (indeed, it clearly is, by virtue of being /sbin/mount.ntfs)
<ubottu> Launchpad bug 395079 in ntfs-3g "[KDE4][Karmic] Error mounting ntfs volume from dolphin's resources panel" [Undecided,Triaged] https://launchpad.net/bugs/395079
<seb128> hum, bug #442742
<ubottu> Launchpad bug 442742 in language-pack-kde-es-base "Update of 20091003 have 15.4% of the translations from 20090926" [Critical,Confirmed] https://launchpad.net/bugs/442742
<chrisccoulson> cjwatson - that won't work in karmic, as HAL doesn't do the mounting anymore
 * seb128 kicks launchpad which timeout on bug reassign
<chrisccoulson1> grrr, stupid 3g connection again
<chrisccoulson1> cjwatson - there is also already a fdi file in the source, which i wrote last cycle - debian/25-ntfs-3g-policy.fdi
<chrisccoulson1> it just isn't installed at the moment
<ion> Hi zul. Online?
<zul> ion: yes will get to your debdiff today
<ion> zul: Alright :-)
<cjwatson> chrisccoulson1: whoops, so there is, but it doesn't use the new scheme pitti linked to
<cjwatson> oh, hmm
<cjwatson> I hate fdi files
<cjwatson> chrisccoulson1: so what's ntfs-3g supposed to do now? I'm thoroughly lost ...
<chrisccoulson1> cjwatson - me too. i'm not sure what happens in KDE now
<chrisccoulson1> is it still using HAL for mounting?
<cjwatson> search me
<chrisccoulson1> if all ubuntu flavours are using DK-disks, then the fdi file should not be needed
<chrisccoulson1> it's not needed for ubuntu, but i really don't know about kubuntu
<cjwatson> where does dk-disks get its mount option lists?
<chrisccoulson1> i hate fdi files too. HAL mounting is horrendously over-complicated ;)
<chrisccoulson1> cjwatson - the mount options are currently hard-coded in dk-disks
<cjwatson> ok
<cjwatson> Riddell: above conversation - can you shed any light?
<chrisccoulson1> they're not configurable yet, so if the mount options are wrong, you'll need to patch dk-disks
<cjwatson> locale= will deal with 90% of the complaints
<Riddell> KDE isn't using devicekit
<Riddell> it's still using HAL
<chrisccoulson1> ah, so it defaintely needs a fdi file then
<chrisccoulson1> s/defaintely/definately
<cjwatson> chrisccoulson1: so if I just revert your ntfs-3g change that stopped installing the fdi file, that should be good enough and won't break gnome?
<chrisccoulson1> cjwatson - possibly. it shouldn't have any effect in gnome, as we're not using HAL for that anymore
<cjwatson> I think at this point that stands a good chance of making it Somebody Else's Problem which will make me happy. :)
<pitti> re
<pitti> cjwatson, chrisccoulson1: KDE still uses hal for mounting, through solid
<pitti> cjwatson: GNOME does not use hal at all any more, so changing FDI files is fine from Ubuntu's perspective
<pitti> chrisccoulson1 already said that, sorry
<simon-o> james_w: Hi, is there anything I can do to get bug 428254 sponsored?
<ubottu> Launchpad bug 428254 in powertop "powertop crashed with SIGSEGV in strstr()" [Medium,Confirmed] https://launchpad.net/bugs/428254
<liw> I'm worried about two seemingly random crashes within the Python interpreter with computer-janitor, bug 420307 and bug 435580 -- any suggestions? ideas?
<ubottu> Launchpad bug 420307 in computer-janitor "computer-janitor-gtk crashed with SIGSEGV in gdk_window_set_geometry_hints()" [Medium,In progress] https://launchpad.net/bugs/420307
<ubottu> Launchpad bug 435580 in computer-janitor "computer-janitor-gtk crashed with SIGSEGV in realloc()" [Medium,New] https://launchpad.net/bugs/435580
<tseliot> Keybuk: any ideas on bug #439138 ?
<ubottu> Launchpad bug 439138 in xorg-server "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Confirmed] https://launchpad.net/bugs/439138
<tseliot> Keybuk: strace reports repeated (failing) calls to ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) where fd 5 is /dev/tty7.
<james_w> simon-o: I'll get to it
<james_w> simon-o: sorry for the delay
<ebroder> Can anybody from ubuntu-release look at bug #429445?
<ubottu> Launchpad bug 429445 in zephyr "[Karmic FFe] Sync zephyr 3.0~rc.2544-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/429445
<simon-o> james_w: thanks. I wasn't sure if there was something missing from me.
<pitti> ebroder: you're better off with just subscribing u-r to the bug
<tkamppeter> pitti, did you see my last message and my comment on bug 443026?
<ubottu> Launchpad bug 443026 in cups "Does not print graphics in PDF documents; after pdf2ps it works" [Undecided,New] https://launchpad.net/bugs/443026
<pitti> tkamppeter: is there a way to display a cups raster file?
<pitti> tkamppeter: would it help if I revert cups/evince/splix/gs to the jaunty version and see in which particular package the regression is?
<doko_> seb128: did you see this python2.6 error "error writing to ..." yourself?
<seb128> doko_, no
<ttx> kirkland, nurmi: ok, I'll file bugs for the issues I found and comment on the already-filed
<kirkland> ttx: cool
<nurmi> great
<tkamppeter> pitti, CUPS Raster files can be visualized with RasterView: http://www.easysw.com/~mike/rasterview/index.html
<pitti> nice, thanks
<pitti> tkamppeter: that saves a lot of paper :-)
<tkamppeter> I cannot imagine that SpliX is the culprit, if the rasterization by pdftoraster conserves the drawing, SpliX, which converts CUPS Raster to the printer's raster format should not loose the drawing.
<pitti> tkamppeter: so it seems it's most likely an evince bug?
<tkamppeter> Only filters which can loose the drawing are pdftopdf and pdftoraster.
<nurmi> dustin,ttx: can we work with revno 911 today (i.e. use a package based on r911)?
<tkamppeter> pitti, for me it really looks more like an evince problem, as Ghostscript and my PDF printers have problems wityh the file.
<ttx> nurmi: would that one fix the DB borkage issue ?
<nurmi> dustin,ttx: there was a problem with database startup < 911, introduced by an SSL database connection fix
<nurmi> ttx: i believe so, yes
<ttx> kirkland: could you update your merge to that version, and publish in PPA ?
<kirkland> nurmi: are you working on this credentials lost fix?
<kirkland> ttx: i can do that; i'll also try to fix the orig.tar.gz too
<nurmi> trying to reproduce
<tkamppeter> pitti, another problem is that from the PDF of evince the filters are not able to produce a PostScript which PostScript printers understand, see bug 419143. The PostScript files get embedded fonts which the printers cannot parse.
<ubottu> Launchpad bug 419143 in evince "Printing from evince (and perhaps other GTK apps) to PostScript printers is broken" [Low,New] https://launchpad.net/bugs/419143
<kirkland> nurmi: you're trying to reproduce this credentials issue?
<nurmi> kirkland: yes
<kirkland> nurmi: cool
<kirkland> nurmi: i'll cherrypick that one, once you have something for me
<kirkland> nurmi: ttx: i need to reboot and make a pot of coffee before i tackle this new merge; give me 15 minutes
<ttx> sure
 * kirkland reboots
<nurmi> kirkland: same here (coffe, at least :)
<ttx> nurmi, kirkland: DB borkage on upgrade issue is bug 443125
<ubottu> Launchpad bug 443125 in eucalyptus "Upgrade to r908 loses admin credentials" [High,Triaged] https://launchpad.net/bugs/443125
<ttx> nurmi, kirkland: No autoregistration if first startup is at boot-time is bug 443118
<ubottu> Launchpad bug 443118 in eucalyptus "No autoregistration on first startup after ISO install" [High,Triaged] https://launchpad.net/bugs/443118
<jcastro> https://wiki.ubuntu.com/UbuntuOpenWeek/Prep <-- still looking for speakers for openweek!
<ttx> + I added a comment about the 16-minute timeout on bug 439251
<ubottu> Launchpad bug 439251 in eucalyptus "Eucalyptus restart is needed after autoregistration of components" [High,Triaged] https://launchpad.net/bugs/439251
<ttx> nurmi: which ones of these should a merge at level 911 fix ? just 439251 ? or also 443125 ?
<nurmi> ttx: i havn't been able to reproduce 443125 yet, and so i'm not sure what is going wrong
<nurmi> ttx: however, it should fix 439251
<ttx> anyone: what would be the right way to specify that an upstart script should start when all networking is up and running ? I don't mind if it starts after everything else.
<ScottK> lamont: Was libmaven-clean-plugin-java on your maven bootstrapping list?  I have users screaming the world as we know it will end if maven doesn't get updated and we need that one.
<dholbach> uery pitti
<simon-o> ScottK: If you need help on the Maven update, just ping me. I use Maven fairly often.
<slacker_nl> hello, against which package do I need to report a bug for packages installed by the minimal installation CD?
<ScottK> simon-o: The biggest problem is the manual bootstrapping.  Because we don't allow binary uploads like Debian does, it's more complex for us.
<pitti> /msg dholbach thanks for that s3kr1t information!
<ScottK> Mostly just waiting for lamont
<kirkland> nurmi: ttx: okay, i'm redoing the merge now
<kirkland> nurmi: ttx: let's make sure that we resolve the two conflicts properly
<kirkland> http://paste.ubuntu.com/286252/
<kirkland> http://paste.ubuntu.com/286253/
<kirkland> nurmi: ttx: for http://paste.ubuntu.com/286252/, i'm going to take upstream's change
<kirkland> nurmi: ttx: ie, the second stanza in the conflict
<kirkland> nurmi: ttx: agreed?
<seb128> mdke, hey
<seb128> mdke, got a minute to discuss menu items naming?
<ttx> kirkland: sounds sane
<nurmi> kirkland: nod
<kirkland> nurmi: ttx: and http://paste.ubuntu.com/286253/ ?
<nurmi> kirkland: in the eucalyptus-cc.in diff, we want the 'sed' line that has 'ThreadsPerChild 1', but the preseed stuff should also remain
<ttx> first line of MERGESOURCE and the rest of TREE
<nurmi> ttx: nod
<kirkland> ttx: nurmi: ack
<ttx> kirkland: also see my remark about the boot-order patch
<ttx> nurmi: would upgrading from 854 need to rebuild to wsdl stubs ?
<kirkland> ttx: nurmi: http://paste.ubuntu.com/286256/
<rcaskey> hey all, any tips for a gnome-session that does not run metacity, gnome-panel, or fail in any obvious way? I'm wondering if the root cause is perhaps gnome-settings-daemon?
<kirkland> nurmi: can you take this difference and apply upstream, to remove the conflict for the next time we merge?
<rcaskey> dist-upgraded to karmic at the beta, and then started having problems
<nurmi> kirkland: i'll give it a try; i want to see what happens when that file doesn't exist (node-preseed.conf) as it will only be there on ubuntu installs
<rcaskey> ** (gnome-settings-daemon:3019): WARNING **: Failed to acquire org.gnome.SettingsDaemon
<rcaskey> ** (gnome-settings-daemon:3019): WARNING **: Could not acquire name
 * rcaskey is a sad boy
<kirkland> nurmi: okay, one more thing ...
<seb128> rcaskey, you have one already running?
<kirkland> nurmi: could you go through https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus, and update any bugs that you expect to be solved in this r911 upload
<kirkland> nurmi: please assign them to me (kirkland) and mark them "in progress"
<rcaskey> seb128, yes, hrmm, wasn't before the reboot though
<rcaskey> gnome-session is still failing silently though
<nurmi> kirkland: will do, looking now
<ttx> Keybuk: about upstart not reloading /etc/init/*.conf on "restart" (see https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430883/comments/1): was that behavior changed by the 0.6.3-6 update ?
<ubottu> Launchpad bug 430883 in upstart "Can start, but not restart, a stopped Upstart job" [Low,Fix released]
<nurmi> kirkland: if the bug is already 'in progress' and assigned to you, leave it be?
<kirkland> nurmi: yes; i'm doing this same thing in parallel :-)
<kirkland> nurmi: i want double coverage on it, though; as I'm documenting this in the changelog
<rcaskey> seb128, killing that old copy and rerunning gnome-session produces the same results
<rcaskey> (polkit-gnome-authentication-agent-1:3236): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'
<rcaskey> or more to the point, if you killal gnome-settings-daemon and then rerun gnome-session you get (gnome-settings-daemon:3449): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
<nurmi> kirkland: done
<kirkland> nurmi: rock, thanks
<kees> pitti: actually, you're right -- setuid() when called by root is the same as setresuid().
<kirkland> nurmi: glad i asked; you had a few on your list that i didn't
<kees> pitti: I'm used to using it on set-uid-root processes, though, where that does not happen.  (i.e. real-root setuid==setresuid, effective-root setuid!=setresuid)
<kirkland> nurmi: https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/439251
<ubottu> Launchpad bug 439251 in eucalyptus "Eucalyptus restart is needed after autoregistration of components" [High,In progress]
<kirkland> nurmi: any idea what revno fixes that?
<nurmi> if I'm correct, it should be 892
<nurmi> kirkland: i believe this was a symptom of the database race problem
<kirkland> nurmi: cool
<nurmi> kirkland: i have a proposed general solution to the preseed stanza: http://paste.ubuntu.com/286274/
<nurmi> kirkland: line 128
<nurmi> if both the module (mod_alias) and the node-preseed.conf files are there, it will add the configuration to httpd-cc.conf
<nurmi> otherwise, it will skip
<kirkland> nurmi: is this already in this merge?
<kirkland> nurmi: or are you asking me to add that?
<nurmi> kirkland: no, i'm proposing it for the next, unless you would like me to commit this now as 912
<kirkland> nurmi: if you think it's safe, please go ahead and commit
<kirkland> nurmi: i'll just merge again
<nurmi> kirkland: it is safe (tested) from a eucalyptus init script perspective, but I don't know how to test the upstart conversion part
<nurmi> kirkland: at some point, the init scripts must be getting converted to upstart scripts
<nurmi> kirkland: if you think that adding this bit to the regular init script will translate properly to /etc/init/eucalyptus-cc.conf, then I'll commit
<kirkland> nurmi: let me think on it for a minute
<lamont> ScottK: yeah - I wanted to get the chroots happy and such - then I had intarwebs issues at home this weekend
<lamont> so... today/tomorrow for maven - the downside is that it means a crowbar for i386 buildds (--> manual)
<lamont> ScottK: otoh, i386 is down to almost nothing left in the queue
<ScottK> lamont: I understand.  I'd appreciate that one.  I could always boot strap it locally and do an upload with an embedded binary if you'd prefer?
<kirkland> nurmi: ttx: okay, testing the local build now
<kirkland> nurmi: let's hold off on merging that hypotetical r912 at the moment
<kirkland> ttx: oh, wait, there was a patch you told me that I should drop...
<kirkland> ttx: where was that?  email or in irc?
<ttx> kirkland: email, ubuntu-devel. boot-order.patch
<ttx> applies to old init scripts, iirc
<kirkland> nurmi: also, do we need to refresh the WSDL stubs?
<nurmi> kirkland: nope
<kirkland> nurmi: good
<kirkland> mdz: around?
<kirkland> mdz: i have a couple of questions about your eucalyptus upstart scripts
<mdz> kirkland, yes, but on the phone. what can I do for you?
<lamont> ScottK: the trick is to add the debs to the chroot, manual everything, build them, upload them, and then put the old chroot back and auto-mode
<mdz> kirkland, I can answer asynchronously
<kirkland> mdz: that's fine
<ScottK> lamont: Yes.  Please.  It's more than just the one package (I assume you know this already)
<kirkland> mdz: 1) eucalyptus-cc.upstart:exec apache2 -f /var/run/eucalyptus/httpd-cc.conf -D FOREGROUND
<kirkland> mdz: nurmi asked why this was being started in the foreground...  is this linked to some upstart logging, or some such?
<lamont> yeah - I have a lizt
<lamont> list, too
<kirkland> mdz: i'
<mdz> kirkland, that's by design
<mdz> kirkland, upstart expects that
<kirkland> mdz: okay, thanks; glad I checked; i was inclined to drop that
<mdz> it lets it monitor and stop the process
<cjwatson> mdz: unless you use 'expect fork' or 'expect daemon' or whatever ...
<cjwatson> you don't *have* to run upstart jobs in the foreground
<kirkland> mdz: 2) ttx and I were wondering if perhaps we're attempting registration too soon, before the tcp/ip stack is functional; wondering if we should push registration back (or have it depend) on networking
<kirkland> mdz: i was curious if you had an opinion or input on (2)
<kirkland> mdz: i don't have proposed changes on that one yet
<ttx> kirkland: if you are in them, fix /etc/init/eucalyptus-walrus-registration.conf so that it uses ipaddrs.conf as the others do
<ttx> kirkland: can't seem to reproduce first-boot registration failure on subsequent boots, maybe some DHCP racing is involved here
<kirkland> ttx: okay, can do
<ttx> kirkland: do you have an ETA for a r911-based package in PPA ?
<kirkland> ttx: i'm building locally right now, should be done with that in 2-3 minutes
<ttx> I'd like to test if the admin credentials lost on upgrade issue is still there
<kirkland> ttx: i'm pushing to ppa as soon as my local build succeeds
<ttx> kirkland: ok
<kirkland> ttx: though i'll add your ipaddrs.conf change too, if you like
<kirkland> ttx: that shouldn't affect the build
<ttx> kirkland: that's cosmetic, the key to upgrading to r911 is that db upgrade issue
<ttx> kirkland: so the sooner I get a r911 package, the better ;)
<kirkland> ttx: local build done; attending your ipaddrs.conf
 * ttx reinstalls from CD to get prstine state and one more autoregistration test
<kees> slangasek: on upgrades, libpam0g prompts for service restarts.  should we adjust that (as done for libc, I think) to not prompt in update-manager ?
<ScottK> +1 for that
<OberonKing> sorry folks, i'm have a issue with the last 2 livecd, alpha 6 and beta don't boot, make the boot process but freeze... can't even enter to a console (ctrl+f1)
<OberonKing> i try noapic, nolapic, ....etc and nothing
<mdz> kirkland, I committed a patch to get rid of the error redirect for euca_conf during registration.  that should make it obvious if that's what's happening
<OberonKing> ohh, i forget, in virtualBox work without problems.
<mdz> kirkland, my gut reaction is, let's test that hypothesis before we try to fix it that way
<kees> slangasek: oh, nevermind, I'm reading 278117 now; it seems like this is only done if the services are non-default
<kirkland> mdz: ack, that sounds perfectly reasonable
<kirkland> ttx: uploaded to my ppa
<kirkland> ttx: also, pushed to bzr+ssh://bazaar.launchpad.net/~kirkland/eucalyptus/r911/
<ScottK> kees: Since there is no other option that "OK" and there's no way to go back at that point, asking seems somewhat pointless to me.
<kees> ScottK: well, you can change the list of services, but it should only appear when non-default services are installed
<mdz> kirkland, do you have an ETA for the new snapshot of eucalyptus landing in karmic?
<kirkland> mdz: i just pushed to my PPA; i plan on testing that there, and then uploading to karmic, and asking for an ISO respin immediately thereafter
<ScottK> kees: I supose.  I upgraded a server over the weekend and was somewhat disappointed to find it waiting for me to OK when I got back to it.
<kirkland> mdz: i expect all of that to happen within my workday
<ttx> mdz: there is a regression in there
<mdz> ttx, bug#?
<ttx> bug 443125
<ubottu> Launchpad bug 443125 in eucalyptus "Upgrade to r908 loses admin credentials" [High,Triaged] https://launchpad.net/bugs/443125
<kirkland> mdz: right, pending the fixage of that regression, of course
<kirkland> mdz: as we understand it, nurmi and team are working on that in the upstream code right now
<ttx> mdz: I also hit  bug 443118 on current dailies
<ubottu> Launchpad bug 443118 in eucalyptus "No autoregistration on first startup after ISO install" [High,Triaged] https://launchpad.net/bugs/443118
<ttx> which is the ont that prompted kirkland's query about eucalyptus boot order
<mdz> kirkland, if nurmi is working on it, please assign the bug to him
<ttx> mdz: I reinstall now to test upgrade to r911
<kirkland> mdz: done; actually, he's trying to reproduce it at the moment
<mdz> kirkland, are you holding off pushing to /ubuntu until all known issues are resolved?
<kirkland> mdz: yes
<ttx> mdz: I would hold until bug 443125 is fixed.
<ubottu> Launchpad bug 443125 in eucalyptus "Upgrade to r908 loses admin credentials" [High,Triaged] https://launchpad.net/bugs/443125
<kirkland> mdz: i have lp:~kirkland/eucalyptus/ubuntu in the mean time
<kirkland> mdz: unless you'd like me to push there?
<ttx> the others (autoregistration stuff) will need some iterations
<kirkland> mdz: i suppose at this point we're committed to merging up to r9xx anyway
<mdz> kirkland, if we're committed anyway, then I see no harm in pushing ahead
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,New]
<dupondje> could somebody give this bug a look ? Its like the most annoying bug in Karmic :(
<kirkland> mdz: okay; i was concerned about pushing something with a suspected regression; though I guess pushing to bzr is very different than uploading a broken package (which we won't do of course)
<ttx> kirkland: ack
<nurmi> mdz: kirkland: ttx: we believe we have diagnosed and fixed #443125
<mdz> kirkland, if you're unsure about merging to /ubuntu, you could create a new branch under ~ubuntu-core-dev
<kirkland> $ bzr push lp:~ubuntu-core-dev/eucalyptus/ubuntu
<kirkland> Pushed up to revision 649.
<mdz> kirkland, I ask because it's not ideal that the current working tree is only writable by you
<ttx> nurmi: you mean in >=r911 ?
<kirkland> mdz: ah, right; that makes perfect sense
<kirkland> mdz: will do that in the future
<kirkland> mdz: this time, i've pushed our main tree up to r649
<mdz> kirkland, does that match what's currently in your PPA?
<ttx> confirming bug 443118 for the third install today
<ubottu> Launchpad bug 443118 in eucalyptus "No autoregistration on first startup after ISO install" [High,Triaged] https://launchpad.net/bugs/443118
<nurmi> ttx: yes, the bug was still in 911.  912 has the fix.  911 has fixes for many of the other bugs, though, and so i think it is worth a try (as long as we're not upgrading from 854, but instead installing package from scratch)
<kirkland> mdz: yes
<mdz> ttx, your ISO is still using r854, right?
<ttx> mdz: yes.
<ttx> mdz: testing the latest with some purge/start-restart-diversion/install/reboot setup didn't exhibit the bug
<kirkland>     *   Start in 7 hours (2505) What's this?
<mdz> ttx, I would be interested to see what shows up in the logs once euca_conf-error-output.diff is applied
<mdz> ttx, maybe you could patch that in post-install and pre-reboot as a test?
<kirkland> ttx: mdz: without a build priority bump, it will be a long time before my eucalyptus ppa packages build
<mdz> kirkland, ->lamont
<ttx> kirkland: could you bump to 912 ? then I'll test that the regression is gone
<kirkland> ttx: i don't see r912 yet
<ttx> I hold my upgrade, non need in testig if the regression is gone in 911 if nurmi says it's fixed in 912
<cjwatson> kirkland: I'll bump prio
<kirkland> lamont: could you give my PPA eucalyptus builds a shot of amphetamines?
<kirkland> cjwatson: cheers, thanks (lamont -> nevermind)
<ttx> cjwatson, kirkland I'd prefer you to bump 912
<kirkland> cjwatson: okay, hold a sec
<ttx> since I have no use for the 911-based
<nurmi> kirkland: should be pushed, sometimes it takes LP a few minutes to update
<kirkland> ttx: r912 doesn't exist yet
<kirkland> ttx: nurmi: okay, i got it
<kirkland> re-uploading
<ttx> mdz: my test setup is on the regression issue right now, since it's the one blocking the new version to reach the ISO
<kirkland> ttx: nurmi: what bug number does r912 close?
<ttx> kirkland: bug 443125
<ubottu> Launchpad bug 443125 in eucalyptus "Upgrade to r908 loses admin credentials" [High,Triaged] https://launchpad.net/bugs/443125
<nurmi> https://launchpad.net/bugs/443125
<ubottu> Launchpad bug 443125 in eucalyptus "Upgrade to r908 loses admin credentials" [High,Triaged]
<kirkland> ttx: mdz: uploaded to my ppa
<kirkland> cjwatson: i'll ping you in a minute, when LP figures out it needs to build a eucalyptus ppa package for me
<kirkland> mdz: my merge changelog last week was a bit of a stub; here's what we're working with now: http://pastebin.ubuntu.com/286320/
<cjwatson> kirkland: ok, I'm on a call so expect a bit of latency
<kirkland> cjwatson: okay eucalyptus 1.6~bzr912-0ubuntu1~ppa1 in https://edge.launchpad.net/~kirkland/+archive/ppa is waiting to build
<ttx> kirkland: my test setup is ready to test the new upgrade. I'll be afk for a few waiting for your PPA to publish a 912-based one
<ttx> kirkland: just ping me when done.
<cjwatson> kirkland: bumped
<kirkland> ttx: cool
<kirkland> cjwatson: thanks man
<cyphermox> I'm looking at bug #404616 which we identified and possibly fixed during the global jam here. I fixed the bug in a bzr branch in my lp user, but what is the correct workflow from there? Should I still be creating a debdiff and subscribing ubuntu-main-sponsors, or is a merge proposal for the bzr branch that holds its packaging code enough?
<ubottu> Launchpad bug 404616 in libgweather "Weather forecasts are incomplete/invalid for Montreal, Quebec, Canada" [Undecided,Confirmed] https://launchpad.net/bugs/404616
<lamont> kirkland: actually, no, I can't.
<lamont> that's a losa thing
<lamont> keytool: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
<lamont> dear java.  why do you hate me?
<lamont> doko_: where does that library live?  and can someone fix ca-certificates-java to actually DEPEND on that package?
<lamont> ScottK: maven will be much easier to build if the packages were installable...
<kirkland> ttx: nurmi: mdz: build done, available at https://edge.launchpad.net/~kirkland/+archive/ppa
<nurmi> kirkland: trying
<doko_> lamont: is this in a chroot without mounted /proc?
<ttx> kirkland: trying
<kees> slangasek: for your consideration, logwatch FFe: 443252
<lamont> doko_: sigh
<lamont> yeah
<lamont> &)^*^&(^%(&^) java
<lamont> and the rest that need /proc
<ttx> kirkland: bug 443125 is *not* fixed in 1.6~bzr912-0ubuntu1~ppa1
<ubottu> Launchpad bug 443125 in eucalyptus "Upgrade to r908 loses admin credentials" [High,In progress] https://launchpad.net/bugs/443125
<kirkland> nurmi: ^
<nurmi> kirkland: still trying the upgrade
<nurmi> ttx: kirkland: we could reproduce with 911, but not with 912 (should have fixed)
<kirkland> ttx: nurmi: FYI, i'm installing from today's iso
<YokoZar> Wow, I just confirmed a bug and assigned it to myself.  I said that it affects me too, and I'll take care of it.  I then realized I was the reporter about 2 months ago.
<lamont> doko_: if it _NEEDS_ /proc, it should better assert that in preinst, no?
<ttx> kirkland, nurmi: installed todays ISO, test the euca-* commands work, upgrade to 1.6~bzr912-0ubuntu1~ppa1, and that same command no longer works.
<ttx> and sudo euca_conf --get-credentials returns an empty file.
<lamont> http://paste.ubuntu.com/286342/ <-- doko
<doko_> lamont: I can do that, but maybe after karmic
 * ttx will be back in a few hours
<kees> Riddell: who maintains skim?
<lamont> nm
<Riddell> kees: you're making an assumption
<kees> Riddell: hrm.  well, it currently ftbfs and it's in main.  should I assign it to ubuntu-desktop?
<Riddell> kees: assign  to me if  you  like,  "jr"
<kees> Riddell: ok, cool.  thx!
<Riddell> kees: for koffice the upstream insists 1.6 is supported and have proved it by supplying  a  patch to disable the xpdf stuff, so I guess we'll go with that
<fbond> statik: Hey, FYI, python-spawning (in your PPA) does not depend on python-greenlet (but should).
<statik> hi fbond: you are correct. rmcbride had taken over working on that package, he may even have a corrected version in REVU right now
<statik> i should delete the old stuff out of my ppa though
<statik> or even better, i'll copy rmcbrides newer package there
<rmcbride> statik: the version I have in REVU has corrected deps, but I'm uploading the 0.8.12 version to REVU now, since the previous one is still in queue and needs to be replaced
<fbond> statik: Okay, thanks.  If you put the updated package in your PPA I would be thankful.
<fbond> rmcbride: Does spawning have VCS somewhere?
<nurmi> ttx: kirkland: mdz: strangeness - if I use the 912 'cloud' package, i'm seeing ttx's problem (admin creds don't last through the upgrade).  If i use eucalyptus*.jar that are built from 912 source, i am not seeing the problem
<kirkland> nurmi: we need to diff that
<nurmi> kirkland: i'm going to need some time to track this down
<kirkland> nurmi: okay
<kirkland> nurmi: what's your approach?
<kirkland> nurmi: i recommend starting with the source we're using for the jar in the package, versus what you're using where you don't see the problem
<nurmi> kirkland: nod
<nurmi> kirkland: i want to start with a clean 854 install, then build 912 upstream and confirm that the bug is fixed
<kirkland> nurmi: where are the source files in question?
<nurmi> kirkland: then, from 854 install, i want to try the 912 used to create packages
<nurmi> clc/modules/authentication/src/main/java/com/eucalyptus/auth/CredentialEntities.groovy
<nurmi> clc/modules/authentication/src/main/java/com/eucalyptus/auth/CredentialProvider.java
<lamont> i386 buildds on manual for a bit
<nurmi> clc/modules/msgs/conf/scripts/startup.groovy
* lamont changed the topic of #ubuntu-devel to: i386 buildds on manual for bootstrap of maven |Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<rmcbride> fbond: I'll have to go look. I got the stuff I worked from from pypi and it's been a few days
<mdz> kirkland, lamont, did you sort out how to get that build reprioritized? we'll need to do that more times before we're done
<kirkland> mdz: cjwatson did it for me
<kirkland> mdz: lamont said he couldn't
<cjwatson> surprised lamont couldn't
<kirkland> mdz: yes, it's built now, regression still in the subject package
<cjwatson> anyone in launchpad-buildd-admins should be able to
<mdz> lamont, who in a US time zone can do that for kirkland the next time?
<kirkland> mdz: nurmi is sorting that out, as he's not seeing it in his upstream build of r912, but is seeing it in the ubuntu build thereof
<cjwatson> mdz: kees can
<kirkland> mdz: i'm parsing the diff now
<cjwatson> (by virtue of TB membership)
<kees> just let me know which and when
<jcole> hi guys, package evolution-mapi in karmic is currently unusable and does not work... it look like debian has a newer version (requires a newer evolution so i couldnt install)... how do i go about requesting a working version of evolution-mapi?
<mdz> kirkland, can you explain 01-wsdl-stubs.patch to me?
<lamont> well.   they will be manual shortly
<kirkland> mdz: no, I cannot.  soren, nurmi: can either of you guys help here?  what's with:
<kirkland> -rw-r--r-- 1 kirkland kirkland 14M 2009-10-05 09:31 debian/patches/01-wsdl-stubs.patch
 * kirkland notes the *14M*
<mdz> kirkland, based on earlier comments, I think ttx is more familiar with it
<lamont> mdz/kirkland/cjwatson: rescoring is me or any duck.  permanently blessing a ppa (if doable) would be losa/gsa
<kirkland>  351 files changed, 322953 insertions(+)   <---- that's scary
<kirkland> lamont: oh, definitely don't need a permanent blessing
<kirkland> lamont: just a couple of rescores
<cjwatson> lamont: rescoring is any launchpad-buildd-admins member, since I can do it and don't have a duck
<slacker_nl> if you see some random string coming from me, my cats are jumping on my keyboard btw
<slacker_nl> ahh, they changed the channels already
<statik> fbond, spawning is on bitbucket: http://bitbucket.org/fzzzy/spawning/overview/ also donovan recently started actively hacking on it and merging patches recently
<slacker_nl> cats :/
<kirkland> sudo killall cat
<highvoltage> -9
<pitti> doesn't work
<pitti> remember, you have to do
<pitti> for i in `seq 7`; do killall cat; done
<ScottK> doko_: Any suggestions on http://paste.ubuntu.com/286360/ ?
<mdz> kirkland, it's a bunch of autogenerated code from the looks of it
<mdz> not sure why it's patched in
<ogra> lool, the display properties notification icon is still completely coloured (testing your icon-theme package)
<mdz> pitti, haha
<kirkland> pitti: LoL :-)
<jcole> ill just "apt-get source evoltion-mapi" from debian unstable, "apt-get build-dep evoltion-mapi; dpkg-build-package" and see if i get luck... ill add it to the internal repos if success
<doko_> ScottK: doesn't look like a valid module name, no not on first look
<ScottK> doko_: The confusing part is this is a rebuild, so something has changed.
<ScottK> The only change is build-dep libode0-dev -> libode-dev
<ScottK> So something is getting confused somewhere....
<ScottK> doko_: ^^
<nurmi> kirkland: okay, it looks like the newest package isn't installing some code from r912
<kirkland> nurmi: oh?
<nurmi> kirkland: on my system, the /etc/eucalyptus/cloud.d/scripts/startup.groovy is not the same as the one from the source tarball
<doko_> ScottK: I try to have a look this week ...
<rmcbride> fbond: I dont see a reference to any sort of VCS for python-spawning at pypi.
<ScottK> doko_: Thanks.
<ScottK> doko_: I have a vague hunch that the axiom FTBFS may be related.
<doko_> persia, ttx: see bug #443292, any help appreaciated
<ubottu> Launchpad bug 443292 in ubuntu "sync, merges and FFe's need for getting maven built" [Undecided,New] https://launchpad.net/bugs/443292
<kirkland> nurmi: can you pastebin a diff of those two?
<nurmi> kirkland: i'm trying a new install, i can get the diff back in a moment...
<nurmi> it looked like the file from 854
<lool> ogra: Ok; I am not sure how that one is considered; would you mind filing a bug against humanity-icon-theme?
<lool> ogra: thanks for testing!
<kirkland> nurmi: hmm, i might have screwed up the merge
<ogra> lool, will do, ibus is also coulored, but i dont think it is handled by any theme (though probably more often used than the display properties in the notification area)
<nurmi> kirkland: not sure if this is related, but last time i tried a 'bzr builddeb', i did notice that it was grabbing a source tarball from the toplevel directory, instead of using the source from the bzr co itself
<ogra> hmm, is my gdm supposed to be all black nowadays ?
<ogra> looks quite ugly
<nurmi> kirkland: http://pastebin.ubuntu.com/286372/
<nurmi> kirkland: diff of the two
<nurmi> kirkland: startup.groovy s
<kirkland> nurmi: cool, i think i see what i did wrong
<kirkland> nurmi: looks like it was my fault; i only have merged r912
<kirkland> nurmi: whereas i did r911 correctly
<kirkland> nurmi: i did that last bit asleep at the wheel
 * nurmi is motivated to get more coffee, right back :)
 * lamont kicks the intarwebs
<lamont> kirkland: ah ok... it sounded like you wanted something more earlier
<kirkland> lamont: nope, just a build bump
<kirkland> lamont: i'm about to need another one
<fbond> statik: Thanks.
<fbond> rmcbride: Thanks.
<kirkland> lamont: please bump these 3:
<kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276910
<kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276911
<kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276912
<ogra> lool, what about vino, do you want a bug for it too (also completely coulored)
<james_w> Riddell: the description of qt-sdk is truncated
<lool> ogra: Sure
<lool> ogra: kind of depends whether it's an app or a system service
<lool> Again not entirely clear in the case of vino
<james_w> Riddell: would you like to fix it later or before it gets out of the queue?
<ogra> well, its installed by default
<lool> rhythmbox, banshee, tomboy are clearly in the app camp
<ogra> and it uses the notification area by default
<kirkland> nurmi: this one should be better
<lool> ogra: Yes but we only care about system services for b&w icons
<ogra> indeed
<kirkland> nurmi: as soon as lamont ushers it up in the build queue
<Riddell> james_w: in debian/control  ?
<james_w> Riddell: yeah
<Riddell> james_w: I see, please reject
<james_w> done
* lamont changed the topic of #ubuntu-devel to: Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<kirkland> lamont: just curious if you caught those last few messages from me; i see you just rejoined
<lamont> through :39, yes
<lamont> after that, no.
<lamont> and in about an hour, I'm goona head home to beat the intarwebs up
<kirkland> <kirkland> lamont: please bump these 3:
<kirkland> <kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276910
<kirkland> <kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276911
<kirkland> <kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276912
<lamont> kirkland: rescored
<kirkland> lamont: thanks
<kirkland> nurmi: okay, i'm testing the latest package
<kirkland> nurmi: ubuntu@cluster:~$ sudo euca_conf --get-credentials mycreds.zip
<kirkland> [sudo] password for ubuntu:
<kirkland> ERROR: you need to be on the CLC host and the CLC needs to be running.
<kirkland> nurmi: oh, wait
<kirkland> it just came
<free> pitti: hi!
<free> pitti: have a minute to talk about #347983?
<nurmi> kirkland: are the amd64 packages built?  I'm still seeing them as 'needs building' but i might be looking in the wrong place
<nurmi> kirkland: https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276910
<lamont> nurmi: you're looking in the right place -
<lamont> OTOH, already running builds kinda win, and the dispatcher seems a tad slow
<nurmi> lamont: great thank you
 * lamont needs to look at the right architecture - i386 is the one with an idle ppa buildd - the amd64 buildds are all happily building along.
<lamont> once they finish their current builds, kirkland's builds will win
<kirkland> nurmi: okay, i've tested the new upload
<kirkland> nurmi: i'm not able to run instances
<kirkland> nurmi: http://rookery.canonical.com/~kirkland/cloud-output.log
<nurmi> does that ssh key exist? (mykey)
<nurmi> kirkland: i.e. does euca-describe-keypairs show it?
<kirkland> nurmi: my fault, i found it
<nurmi> btw, is this from an upgrade from 854?
<kirkland> nurmi: yes
<kirkland> nurmi: okay, i have a running instance on 1.6~bzr912-0ubuntu1~ppa2 (!!)
<nurmi> kirkland: aw yeah
<kirkland> nurmi: give it a poke, let me know if you see any obvious regressions
<nurmi> i'll be running through our full QA here in a second
<kirkland> nurmi: i'm going to eat a bite of lunch, and upload to karmic thereafter, assuming we don't detect any regressions
<nurmi> kirkland: and this is as an upgrade from 854 (iso)?
<nurmi> kirkland: wait you already answered that, nvm
<kirkland> nurmi: yes, today's iso (854) upgraded to these PPA packages
<kirkland> nurmi: it's not DoA, which is good
<kirkland> nurmi: ETA on your QA testing?
<kirkland> nurmi: ideally, i'd like to wait for that before pushing to karmic
<nurmi> assuming this works out of the box, i can be done with short-term testing in an hour
<kirkland> nurmi: assuming that'll be done in ~1 hour or so
<kirkland> nurmi: par-fect
<kirkland> nurmi: i'll cross my fingers and get something to eat
<nurmi> kirkland: awesome, thanks dustin
<kirkland> mdz: fyi, initial testing on r912 looks good, i have running instances here
<mdz> kirkland, good good
<kirkland> mdz: upgraded from r854, anyway
<kirkland> mdz: nurmi is putting it through the Eucalyptus Systems QA suite
<kirkland> mdz: that should conclude in roughly an hour
<kirkland> mdz: i'll upload to karmic thereafter, and ask for an iso respin
<kirkland> mdz: unless you want that in progress in parallel
<kirkland> mdz: i have not detected any regressions, have seen ttx's issues solved
<kirkland> mdz: this upload is thought to fix ~12 bugs
<mdz> kirkland, whatever is best in your judgement
<kirkland> mdz: i will wait for nurmi
<nurmi> kirkland: mdz: doing eucalyptus tests now
<kirkland> nurmi: hunting for leftovers now
<mdz> nurmi, do you have a separate bug number for 443125 upstream or are you using the same one?
<nurmi> mdz: same one, we learned about this bug this morning
<mdz> nurmi, and it's meant to be fixed by r912? I don't see a bug number in the commit message
<nurmi> mdz: it is, the committer did not put in a bug number into the revision
<mdz> nurmi, understood, I'll just update the bug accordingly
<arand> Can I view the security queue for ubuntu, or is it non-public?
<jdstrand> arand: as in what is in our build queue? that is non-public
<nurmi> mdz: thank you, appreciated
<arand> jdstrand: so that is a separate section compared to the public https://launchpad.net/ubuntu/jaunty/+queue ?
<jdstrand> arand: yes, we build in a private ppa
<arand> Okay, one learns something new...
<ttx> kirkland: why did you reopen bug 436313 ? It was fixed, the merge just confirms the fix ?
<ubottu> Launchpad bug 436313 in eucalyptus "SC registration through web UI fails" [High,In progress] https://launchpad.net/bugs/436313
<kirkland> ttx: then i misunderstood your comments
<kirkland> ttx: i assumed this was fixed in a revision >> 854
<kirkland> ttx: i found that revision in the upstream commit log
<ttx> kirkland: yes, it was fixed in a rev>>854, but applied to our branch
<mdz> ttx, can you explain about 01-wsdl-stubs.patch?
<kirkland> ttx: cool, i'll close it then
<ttx> mdz: there is a trick because eucalyptus needs some C code generated from wsdl descriptions
<ttx> mdz: it uses wsdl2c which uses some unpackaged axis2 java code
<ttx> so if upstream changes wsdl descriptions, the patch needs to be refreshed
<mdz> ttx, is there any kind of check in place so that we notice when that happens? it should probably fail the build
<ttx> mdz: I don't think there is, it bit soren once already
<ttx> mdz: more info with soren
<nurmi> mdz: ttx: the trigger for that (C auto-gen stuff) would be if any of the wsdl files changes (<eucalyptus-src>/wsdl/*)
<nurmi> ttx: mdz: kirkland: okay, our short-term tests have passed with the latest package from this morning (1.6~bzr912-0ubuntu1~ppa2)
<kirkland> nurmi: cool
<kirkland> nurmi: i'm uploading to karmic then
<kirkland> nurmi: as I'm happy with the prodding i've done
<kirkland> nurmi: i'll ping you again as soon as we get a new ISO
<LLStarks> hi.
<nurmi> kirkland: great!
<LLStarks> i find it infuriating that i need to have a genuine package installed to file a bug against it.
<hyperair> ..this is just great. now i can't file bugs on launchpad manually?
<hyperair> what's the big idea?
<LLStarks> what if i am using a ppa version but i need to use ubuntu-bug?
<hyperair> my my, looks like we're both ranting about the same issue
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/443961
<ubottu> Launchpad bug 443961 in apport "Given that ubuntu-bug is now needed for all bug reports, non-genuine packages should be allowed." [Undecided,New]
<doko_> lucas: do you understand the ruby1.9 build failure on i386?
<lucas> doko_: there was an upstream bug + patch
<lucas> doko_: bug #443044
<ubottu> Launchpad bug 443044 in ruby1.9 "ruby1.9 fails to build on i386" [Undecided,New] https://launchpad.net/bugs/443044
<doko_> lucas: thanks! I'll upload
<kirkland> crap
<kirkland> mdz: eucalyptus build failed
<kirkland> The following packages have unmet dependencies:
<kirkland>   default-jdk: Depends: default-jre (= 1.6-30ubuntu5) but it is not going to be installed
<kirkland>                Depends: openjdk-6-jdk (>= 6b11) but it is not going to be installed
<kirkland> doko_: hey
<mdz> kirkland, on which arch(es)?
<kirkland> mdz: all
<kirkland> doko_: is our jdk/jre in flux right now?
<kirkland> https://edge.launchpad.net/ubuntu/+source/eucalyptus/1.6~bzr912-0ubuntu1
<kirkland> mdz: ^
<doko_> kirkland: no, java-access-bridge was uploaded, but that did add only a dependency. I don't know of anything else
<kirkland> doko_: http://launchpadlibrarian.net/33058735/buildlog_ubuntu-karmic-amd64.eucalyptus_1.6~bzr912-0ubuntu1_FAILEDTOBUILD.txt.gz  <---- any ideas?
<mdz> kirkland, doko,   openjdk-6-jre: Depends: libaccess-bridge-java-jni but it is not going to be installed
<doko_> kirkland: http://people.canonical.com/~ubuntu-archive/testing/karmic_probs.html
<mdz>   libaccess-bridge-java-jni: Depends: libaccess-bridge-java (>= 1.26.2-1ubuntu1) but it is not installable
<mdz> E: Package libaccess-bridge-java has no installation candidate
<doko_> ahh, it's in universe, please promote
<kirkland> doko_: ah
<doko_> ubuntu-archive: ^^^
<kirkland> doko_: one minute, i'll push
<cjwatson> done
<kirkland> cjwatson: thanks
<kirkland> cjwatson: do i need to re-upload to retrigger the build?
<mdz> doko_, what bug is that change meant to fix? I don't see a bug reference in the changelog
<cjwatson> kirkland: no
<cjwatson> kirkland: there's a retry button in launchpad
<kirkland> cjwatson: awesome, thanks
<doko_> mdz: the jni bindings require the java files, or else the bridge doesn't work
<kirkland> cjwatson: cool, never noticed taht!
<doko_> kirkland: only for buildd admins
<cjwatson> kirkland: wait an hour for the main promotion to take effect, of course
<cjwatson> doko_: false
<kirkland> cjwatson: okay
<cjwatson> doko_: if you're able to upload a package, you're able to retry a build too
<doko_> cjwatson: then it did change
<cjwatson> doko_: a year or two ago, yeah. rescoring is still restricted
<doko_> ahh, ok
<cjwatson> which might be what you're thinking of
<doko_> yep
<mdke> seb128: I'm around now if you can
<kirkland> mdz: okay, as this stands, i will be several hours before I'm able to receive and test a new ISO
<seb128> mdke, hey
<mdke> hiya
<seb128> mdke, so what is your issue with the gedit naming?
<mdke> seb128: I was just putting the thought out there, that it is inconsistent with the other menu entries which don't use the application name, also it seems to me that it looks ugly to start a menu entry with a small letter
<mdke> seb128: but it's an issue for the desktop team to decide, as the docs team we'll just adapt to the decision, whatever it is
<mdke> but we'll need to make string changes to update the docs
<seb128> mdke, we have quite some applications using "software name function"
<mdz> kirkland, I understand, it's not your fault
<mdke> seb128: I was comparing it with the other basic applications in the Accessories menu, like Calculator, Terminal etc
<mdke> seb128: but yeah, it's true for the Internet menu
<mdke> (and others)
<seb128> we are in a situation were it's mixed and they are trying to fix it now I think
<seb128> I agree it's a bit late for this cycle
<seb128> I'm not strongly opposed to delay the gedit change to next cycle
<mdke> seb128: it's not a huge issue from a docs point of view either, I've checked and I think we only have one string which uses "Text Editor". I suppose the easiest is to go with upstream and hope that they fix the inconsistency in future cycles
<seb128> mdke, you are not the first on to mention than having the title starting with a small letter is weird though so I'm not sure, I will think about it until tomorrow
<mdke> seb128: ok - as long as you post to the bug report, we'll pick it up
<mdke> seb128: thanks
<seb128> thank you for bringing the issue!
<mdke> anytime. I'm good at bringing issues :(
<slangasek> cjwatson: so, I guess ubuntu-desktop is being held back here due to the libgd2-(no)?xpm conflict... any thoughts on how to resolve this?
<cjwatson> hmm, I guess I'll tell you once it filters down to my mirror :)
<cjwatson> we could try dropping -noxpm's priority, ISTR apt pays some attention to that
<slangasek> ok, lowering to extra
<kirkland> kees: can you make https://edge.launchpad.net/ubuntu/+source/eucalyptus/1.6~bzr912-0ubuntu1/+build/1277101 build now?
<kees> kirkland: one moment...
<kees> kirkland: when palmer, rothera, or vernadsky finish, eucalyptus will build.  I don't have the ability to cancel a running build.
<kirkland> kees: cool, thanks.
<kees> kirkland: (I've scored it high to build next...)
<kirkland> great, thanks
<kees> kirkland: now building
<kirkland> kees: outstanding
<kees> that was fun! first time I've used that super-power.  ;)
<kirkland> kees: oh, we can exercise that some more, if you want more fun in your superhero life
<kirkland> slangasek: okay, could you push a server ISO build for me, with eucalyptus 1.6~bzr912-0ubuntu1 ?
<kirkland> slangasek: please, and thanks!
<slangasek> kirkland: queued
<kirkland> slangasek: cheers
<jono> directhex, around?
<directhex> jono, give or take, sure
<nurmi> kirkland: regarding lp bug 439364 - trying to register 'localhost' with walrus is not valid (for the reasons we've discussed).  the bug is currently marked 'high/incomplete', should it be closed or do you feel that there is further action here?
<ubottu> Launchpad bug 439364 in eucalyptus "Internal error registering local walrus" [High,Incomplete] https://launchpad.net/bugs/439364
#ubuntu-devel 2009-10-06
<soren> Keybuk: Does your closing bug #372864 as fFix released mean that you added a getty for hvc0?
<ubottu> Launchpad bug 372864 in upstart "conf: Put a getty on hvc0" [Wishlist,Fix released] https://launchpad.net/bugs/372864
<Keybuk> no, it means the upstart task is closed
<soren> But..
<soren> upstart also provides /etc/init/tty
<soren> *.init?
<Keybuk> I don't think upstart should provide a job for everything anyone can think of
<Keybuk> if you want an hvc0 tty job, it should go in something else
<soren> Um... I don't really see why, really.
<cjwatson> d-i creates an hvc0 job if you're installing on that type of console (FWIW)
<soren> I thought it was quite elegant that it could be shipped alongside the regular tty? things so that when run in an environment that has hvc0, it woudl dld Just Work.
<Keybuk> because otherwise we end up shipping a job file for every single user's random wishlist
<soren> cjwatson: Oh, really?
<slangasek> Keybuk: hey, since you're around - how can I get an interactive shell out of an upstart job at boot time for debugging?  I'm sure I saw you telling people how to do this before in connection with mountall, but I can't figure it out now
<cjwatson> soren: finish-install/finish-install.d/90console
<Keybuk> slangasek: http://upstart.ubuntu.com/wiki/OMGBroken
<slangasek> Keybuk: thanks!
<cjwatson> soren: BTW I'm *so close* to getting vmbuilder working with grub2 ...
<soren> cjwatson: Oh, your grub2 branch doesn't work?
<cjwatson> that was a chroot-grub branch
<cjwatson> it copes with grub2 in the host, but still installs grub in the guest. That much is fine
<cjwatson> now I'm working on grub2 in the guest too
<soren> cjwatson: Ah, ok. I didn't look at it yet, I just saw it trickle in.
<cjwatson> chroot-grub is still worth merging, I think (indeed, I'm basing this grub2 branch on it)
<soren> Keybuk: I really think shipping the hvc0 job by default is sensible, and I think your argument about "every user's random wishlist" is needlessly antagonistic. I'm waaaay too tired to argue about it now, though. Tomorrow, perhaps?
<soren> cjwatson: Sure, sure, I'll look at it shortly. Tomorrow, hopefully.
 * cjwatson nods
<Keybuk> soren: it sounds like this is already solved
<Keybuk> the installer creates that file
<soren> Keybuk: If one uses the installer, yes.
<cjwatson> I suspect soren is using vmbuilder or similar, which doesn't use installer code and would require reimplementation of the same ...
<soren> Well, there's that, but also upgrades.
<soren> Or virtual machines converted from physical ones.
<soren> I really don't think it belongs in the installer now that we can actually trigger on the availability of the device in the upstart job itself.
<slangasek> pitti, kenvandine: do you know whether gnome-power-manager does the equivalent of 'pm-powersave' at startup?
<Keybuk> soren: I'm not saying you can't do this in an upstart job
<Keybuk> I'm just saying the upstart package is the wrong place for it
<Keybuk> just like we don't ship /etc/init/dbus.conf in the upstart package
<soren> Keybuk: I realise.
<soren> Keybuk: And I disagree.
<ion> How about a xen-guest-stuff package that is strongly recommended to be installed on guests?
<ion> update-manager could even install that when it notices itâs being run within a guest.
<soren> I think that is silly.
<soren> None of my VM's run update-manager (they're server VM's).
<soren> ..and so far, we've managed just fine without such a package.
<ion> % dpkg -S =do-release-upgrade
<ion> update-manager-core: /usr/bin/do-release-upgrade
<ion> Thatâs on a server.
<soren> You hardly run do-release-upgrade regularly.
<ion> Well, as regularly as you upgrade to a new release. :-P
<soren> It's for doing full distro upgrades.
<soren> That hardly counts as "when it notices itâs being run within a guest"
<ion> When do-release-upgrade notices itâs being run within a guest
 * soren sighs
<Keybuk> soren: worth pointing out, I guess, that I plan to remove the tty* jobs from upstart too
<Keybuk> they were only there because they came from sysvinit via inittab
<soren> Keybuk: See, that's a good argument.
<soren> Keybuk: Where would they go?
<Keybuk> soren: into the package that ships getty
<Keybuk> and it'll be just getty.conf
<soren> Keybuk: Ok.
<Keybuk> there's no reason for having the separate files at the moment
<soren> I'm not insisting on putting hvc0 in the upstart package. I just think it belongs where the tty? jobs are, and that's been upstart for the last couple of years.
<Keybuk> I don't think I agree with that
<Keybuk> because I still don't think every single person wants getty trying to run on that device
<soren> ?!?
<soren> Why on earth not?
<soren> That's what it's for?
<soren> Well, that or a root prompt or something.
<soren> ...but I didn't think that was really what was being discussed.
<Keybuk> that's my point - I've seen a lot of argument that the console of a virtual machine should not be getty but sulogin directly
<soren> That may be perfectly reasonable.
<Keybuk> and I wouldn't want to ship upstart upstream with a fixed configuration that's not what everyone wants
<Keybuk> RH have that neat /etc/consoles solution
<Keybuk> start on tty-device-added
<Keybuk> stop on tty-device-removed KERNEL=$KERNEL
<Keybuk> instance $TTY
<Keybuk> pre-start exec grep -w $TTY /etc/consoles
<Keybuk> exec /sbin/getty $TTY 38400
<Keybuk> ;-)
<soren> Sorry, I'm having trouble following this discussion. I'm not sure whether we're discussing shipping an hvc0 job at all, shipping it in a binary package built by the upstart source package in Ubuntu, shipping it in the upstart upstream tarball, whether it will run a getty or sulogin, or perhaps something entirely different. I think I'm going to give up for today and pick it up again tomorrow :)
 * soren calls it a day
<mbiebl> slangasek: dk-power calls pm-powersave
<mbiebl> and it's tied to the battery state
<slangasek> mbiebl: ok; part of my problem figuring this out is that devkit-power is mispackaged, leading to gnome-power-manager being statically linked against libdevkit-power-gobject
<slangasek> mbiebl: so will dk-power get called on gpm startup, or only on battery state chage?
<slangasek> change
<mbiebl> dk-power will be dbus autostarted  I guess by gdm's gpm instance
<mbiebl> and whenever the battery state changes, dk-power will call pm-powersave true|false
<arand> What is it that keeps changelogs lagging so much in publication? Why would they be anything but simultaneous to package publication?
<mbiebl> afaik it's not g-p-m that triggers the pm-powersave call
<mbiebl> slangasek: btw, what's the mispackaging in dk-power?
<mbiebl> I don't see g-p-m being statically linked against libdevkit-power-gobject (at least on sid)
<slangasek> mbiebl: -dev package has no dep on the shared lib package
<mbiebl> slangasek: should have been fixed in 010-2
<slangasek> mbiebl: so there's no guarantee that devkit-power will call pm-powersave on startup, to set an initial configuration?
<slangasek> (I'm asking because I want to remove some more redundancy out of acpi-support)
<mbiebl> to answer that definitely, I'd have to check the dk-power code
<slangasek> mbiebl: 010-2> well, Ubuntu has 010+git20090913-0ubuntu1; I guess it jumped versions before 010-2 was out, so Ubuntu doesn't have the merge
<mbiebl> pitti told me that he had merged that
<slangasek> well, he hasn't :-)
<mbiebl> next upload will be fixed then
<slangasek> I'm fixing it in Ubuntu right now
<mbiebl> slangasek: just checked
<slangasek> mbiebl: it's called from dkp_daemon_startup, so I guess we're good :)
<mbiebl> dk-power set's an initial state
<slangasek> woohoo
<mbiebl> yep
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/443404
<ubottu> Launchpad bug 443404 in software-properties "add-apt-repository insists on downloading GPG key even if keyserver is down. If keyserver is down, add-apt-repository can't proceed." [Undecided,New]
<mbiebl> slangasek: I remember. 011 was supposed to be released today and we wanted to sync at this version again
<slangasek> mbiebl: ok
<dtchen> directhex: (RE: disabling pulse and using alsa-lib pcm.default) potentially racy. you'd want to actually disable autospawn and killall pulseaudio before trying that.
<dtchen> superm1: (RE: libmyth/audiopulseutil.cpp) do you still need my input?
<superm1> dtchen, well I think i came up with a solution actually.
<ScottK> dtchen: Did you see my ping on wvstreams?
<dtchen> ScottK: yes, i'm processing backscroll FIFO
<ScottK> dtchen: OK.  Just wanted to make sure you saw it.
<superm1> it seems that PULSE_INTERNAL needs to be set in the environment when pulseaudio is getting suspend otherwise ALSA:default still goes through pulseaudio
<dtchen> superm1: yes, but that's still racy
<superm1> dtchen, well there are AV sync issues if things are allowed to go through pulseaudio still
<superm1> they're not immediately noticable, but with an hour recording w/ comm skip turned off, they turn up
<ajmitch> dtchen: need me to test any more HP patches?
<superm1> so this is the easier solution
<superm1> (for now given time period)
<dtchen> superm1: right. suboptimal, but nothing really resolving by late october.
<dtchen> resolvable*
<dtchen> ajmitch: soonish, hard to give an ETA right this moment
<superm1> dtchen, it would be best if during lucid if upstream could try to help look over mythtv code to help recommend changes to fix these types of things for the next release though
<ajmitch> dtchen: alright, ping me on irc if you need testing someday
<dtchen> superm1: indeed
<dtchen> ajmitch: sure thing
<jono> Has anyone got a broken Network Manager?
<jono> ahhh
<jono> I see a new package
 * jono dist-upgrades
<dholbach> good morning
<stooj> Morning Daniel
<pitti> Good morning
<pitti> free: sure
<free> pitti: heya
<pitti> slangasek: g-p-m> pm-powersave support was hacked into dk-power some months ago, so it's supposed to; it doesn't work any more?
<slangasek> pitti: mbiebl_ has confirmed that it's there - I was asking the question because I wanted to be sure some broken code in acpi-support was truly redundant before hacking it out
<pitti> ah, good; I read the rest of the scrollback
<free> pitti: so should I include a SRU-compiant description in each bug involved in the SRU? (with rational, impact, etc.)
<pitti> slangasek: so, shall I merge and fix the broken lib dep?
<pitti> slangasek: dk-p 011 was supposed to be released yesterday, so I'd just update to the final version (just three changes compared to our git snapshot), and sync to sid
<pitti> free: right, but please be very picky; this is intrepid, thus neither the current stable nor current LTS; it should get as few changes as possible
<slangasek> pitti: well, I've uploaded devkit-power to fix it - if you have another reason to merge, go ahead, as long as you don't drop that fix :)
<pitti> slangasek: no, I fixed that in Debian's git already
<pitti> thanks
<free> pitti: okay, I'm also going attach a stripped diff containing only the actual changes
<free> pitti: because many of them were test code, which doesn't even end up in the packages
<pitti> free: test code is fine
<free> pitti: okay, I'll update the bugs you pointed out. Shall I update the description or attached a comment? or it's the same?
<free> s/attached/attach/
<pitti> free: description is preferred, but it doesn't matter so much
<pitti> free: but please add proper Ubuntu tasks; so far the bugs just have upstream tasks which aren't even "fix released"
<pitti> and it's not clear which fixes are in jaunty/karmic already, etc.
<pitti> free: and as I said, the intrepid upload should backport three or so of the most important fixes, not a complete backport of a new version
<free> pitti: so that means open new bugs affecting the relevant releases?
<pitti> free: not new bugs; new tasks
<free> pitti: okay
<pitti> free: and please close the upstream tasks as appropriate
<pitti> free: ideally for an SRU, the upstream and karmic ubuntu task need to be "fix released"
<pitti> we don't put stuff into stables which hasn't even been tested in the latest karmic release yet
<pitti> (landscape-client is the obvious exception, which has a standing "new version allowed" permission in the SRU policy)
<free> pitti: so the thing that we specifically QA-ed this version we're proposing as SRU, the QA process was rather strict
<free> pitti: so we'd rather prefer to see this smart package accepted, as the changes are bug-fix only, no new features
<pitti> free: but with this many changes it's utterly hard to guarantee that there are no regressions for users of the current version
<pitti> free: you also changed things like the .desktop file, which suddenly make a new menu entry appear for people who have it installed
<free> pitti: I and Gustavo Niemeyer are possibly available to help reviewing each single change
<free> pitti: okay, we can strip these user-visible things
<pitti> free: why not just have a few targetted patches, like the jaunty upload?
<pitti> that's so much safer
<pitti> free: https://wiki.ubuntu.com/StableReleaseUpdates#It%27s%20just%20a%20one-line%20change!
<pitti> and the "When" section below
<free> pitti: because we QA-ed those changes already, and we would need to re-do it
<free> pitti: also note that the landscape-client accepted in -proposed depend on that version of smart or above
<free> pitti: so that would need to change as well
<pitti> free: no, it doesn't
<pitti> I reviewed the debian/control changes, and it doesn't bump any smart dependency?
<pitti> oh, sorry, it does
<pitti> yes, that needs to be fixed
<free> pitti: yeah
<hoonteke> I'm in the process of learning how to create and package .debs.  I'm using pbuilder right now, but running into some problems.  The tutorial I'm following appears to be borked in relationship to my setup.  I'm new enough to the process that I'm not sure what questions to ask or how to start diagnosing.  Is there a better tutorial than https://wiki.ubuntu.com/PbuilderHowto ?
<pitti> free: oh, I see; the dependency even moved from one package to the other
<hoonteke> (I'm getting stuck on the pdebuild step, which errors out with Make ..[127])
<pitti> the new landscape-client is very intrusive, with conffile changes and everything; but it has a standing exception, so I didn't complain there
<free> pitti: smart is a critical component of landscape-client
<pitti> free: right, but it's not _only_ a component of landscape-client, other users might use it as well
<pitti> sure, we don't support it officially, but that's not a reason for us to break it in stables
<free> pitti: why break? we're pretty confident that the changes are sane, and they've been out and QA-ed since months
<free> pitti: they are in jaunty and karmic already, except those two patches in the jaunty SRU
<pitti> free: well, we have this strict "minimal changes" policy for a reason; we've been burned more than once already
<free> pitti: http://lists.labix.org/pipermail/smart-labix.org/2009-March/003875.html
<free> pitti: yes, I understand that
<pitti> and half-a-megabyte diffs are far far away from "minimal changes to fix critical bugs only"
<free> pitti: it's actually ~800 lines, if you consider only installed code
<pitti> right, and most of the chagnes there are neither appropriate nor necessary for an SRU
<free> pitti: okay, I'll try to limit it to the strict necessary, thanks for your feedback
<pitti> free: I'm sorry that this caused redundant work; for future updates to stables, please just subscribe the SRU team to the relevant bugs right away, then we can discuss it beforehand and avoid that
<free> pitti: good point
<maxb> It's my subjective impression based on watching boot messages, that karmic seems to intermittently but often fail to properly unmount the root FS - the kernel always seems to be doing journal recovery on mount. Any thoughts on where I should file / look for a bug on this?
<seb128> could somebody look at bug #444216 and see if they know what's going on?
<ubottu> Launchpad bug 444216 in gnome-keyring "package libpam-gnome-keyring 2.28.0-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 143" [Undecided,New] https://launchpad.net/bugs/444216
<seb128> there is thousand of "Use of uninitialized value $reply" debconf lines in the log
<seb128> it seems that something is looping there
<slangasek> seb128: hum, yes, killing the debconf frontend is a good way to make a debconf-based program loop :)
<seb128> slangasek, do you know what package is responsive for displaying the dialog which confused the user there?
<slangasek> pam
<seb128> ok, let me reassign the bug there
<seb128> the issue seems that the dialog was not clear to the user
<seb128> slangasek, thanks
<ogra> is gdm really supposed to be in this awful black and white theme now ? or is that just my system
<seb128> design decision
<slangasek> (the package that libpam-gnome-keyring calls in its postinst, of course :)
<ogra> looks horrid :/
<slangasek> seb128: well, I think that's more likely than there being a bug in pam-auth-update here, but I can't see how to make the dialog clearer
<liw> ogra, I was assuming that was a bug, but didn't get around to reporting it yet... *sigh*
<seb128> slangasek, I've not seen the dialog but the user said that one option need to be selected? In which case the dialog should have a widgets allowing to pick one option only rather than what is has now?
<slangasek> seb128: no, *at least* one option must be selected
<slangasek> it's a multiselect
<slangasek> anyway, the user's already done something wrong to see this dialog at all
<seb128> slangasek, the bug is confusing, "I selected them all, only to be informed that I need to select at least one."
<slangasek> (setting debconf priority to medium or below)
<seb128> that seems to be a bug at least
<slangasek> I don't believe that's what actually happened, though :)
<slangasek> I've tested this code rigorously
<seb128> ok, so feel free to ask for details or close the bug as "don't close the debconf frontend in a brutal way" ;-)
<slangasek> I think the submitter just wasn't paying close attention
<slangasek> yep, will do
<seb128> thanks
<wgrant> pitti: If Soyuz was to reject binary uploads containing a ddeb without corresponding deb, would the world end? I guess no normal source should get into that situation, but I imagine that some stranger packages might...
<pitti> wgrant: it really shouldn't happen (TM), though
<pitti> even the handcrafted linux ddebs follow that naming schema
<wgrant> It makes things much much simpler for everybody if we can reject those, but the consequences if the assumption proves untrue are... bad.
<pitti> wgrant: I'd say, do it like this, at least for now
<pitti> wgrant: in all the years when we have used ddebs this case didn't come up
<wgrant> pitti: Wouldn't any extra ddebs enter the archive without question with the current setup?
<mok0> Netsplit!
<mikejones>        _
<mikejones>  _ __ (_) __ _  __ _  ___ _ __ ___
<mikejones> | '_ \| |/ _` |/ _` |/ _ \ '__/ __|
<mikejones> | | | | | (_| | (_| |  __/ |  \__ \
<mikejones> |_| |_|_|\__, |\__, |\___|_|  |___/
<mikejones>          |___/ |___/
<mok0> mikejones: keep the tone please
<dholbach> thanks cjwatson - I tried but did not have enough power
 * ogra hands dholbach a mars bar ... 
<ogra> ... so you are prepared next time :)
<pitti> wgrant: they would, yes
 * mvo thinks ogra watches to much advertisement
<free> pitti: how do I add intrepid/jaunty tasks to a bug, I can't figure it out from the LP UI
<pitti> free: "Target to release", right below the yellow task table
<cjwatson> you probably don't have the privilege to do so yourself
<cjwatson> you can "nominate for release"
<pitti> free: ^ I'll approve your nominations
<free> okay thanks
<pitti> does anyone have a firewire device here?
<davmor2> pitti: meh sorry one thing I don't have
<lifeless> ArneGoetje: around?
<lifeless> if so, do you knowwhy https://translations.edge.launchpad.net/ubuntu/karmic/+source/xulrunner-1.9.1/+pots/xulrunner-1.9.1/la/1885/+translate and
<lifeless> much of the rest of that pot, have english values listed as the translations?
<lifeless> ArneGoetje: I'm asksing asking you because you are credited by LP
<ArneGoetje> lifeless: The only reason I'm credited is because I uploaded the upstream translations and copied the other incomplete translations from xulrunner-1.9 over. I have no stakes in actually translating this language.
<lifeless> ArneGoetje: so I think a mistake was made somewhere
<lifeless> la is not english
<lifeless> but there are very many strings marked as translated with the translated version being english
<ArneGoetje> lifeless: I guess it's one of the incomplete translations and XPI format for strings that have no translations fall back to English
<lifeless> ArneGoetje: _ugh_ - so we get it marked as translated?
<ArneGoetje> lifeless: that's a requirement of XPI files. There needs to be a string there.
<ArneGoetje> lifeless: bbl, need to go for lunch now.
<lifeless> ArneGoetje: and we import from the xpi, with no change of importing fom upstreams translatio data?
<mdz> ttx: if the post-start fails, that will log an error in syslog
<mdz> ttx: are you seeing that error?
<mdz> we could increase or remove the timeout if it is too short
<ttx> mdz: yes
<ttx> and it doesn't prevent registration from running.
<ttx> it seems like the test we are using always fails, so increasing timeouts won't help :)
<ttx> mdz: like I said, it's so strange I want another pass at testing
<mdz> ttx: really? that test was succeeding for me
<mdz> it's been modified since then, though
<ttx> mdz: ithe CC test works. the SC/Walrus ones seem to fail. I want to confirm that on a pristine install though, I may have been hacking around that one for too long
<ttx> mdz: filed bug 444504 about that
<ubottu> Launchpad bug 444504 in eucalyptus "Autoregistration through upstart, while working, uses strange ways" [Medium,New] https://launchpad.net/bugs/444504
<james_w> has anyone uploaded any maintainer script changes in the last 24 hours?
<cjwatson> directhex: does the gettext build failure ring any bells with you? http://launchpadlibrarian.net/31807601/buildlog_ubuntu-karmic-i386.gettext_0.17-6ubuntu2_FAILEDTOBUILD.txt.gz
<cjwatson> directhex: that was built a little while back, but I reproduced it on my laptop
<directhex> cjwatson, i seem to recall removing support for it a while back - gettext's c# bindings barely function, and are for use with dotgnu (mono has much more robust bindings already)
<directhex> it's far more work to make the bindings bundled with gettext actually properly buildable than to ignore them & write them off. and there are no rdeps
<directhex> aha, thought so
<directhex> i recognise this as i worked on it with sanvila@debian
<directhex> 0.17-7 removed all mono stuff
<seb128> hum, something seems to clear tmp on upgrades since today, anybody has a clue what change could do that?
<directhex> and you're on 0.17-6ubuntu2, so...
<cjwatson> directhex: ha, so the right answer is a merge. ok.
<directhex> cjwatson, it might've been an easy fix. check the 0.17-7 diff
<cjwatson> will do, thanks
<cjwatson> just been trying to clear up a few build failures this morning
<seb128> slangasek, those weird pam bugs could be also due to this tmp cleaning on upgrade issue
<seb128> bug #444252 is gconf-schemas breaks due to that
<ubottu> Launchpad bug 444252 in gconf "gconf-schemas: OSError: [Errno 2] No such file or directory" [Undecided,Confirmed] https://launchpad.net/bugs/444252
<kirkland> ttx: how's today's iso?
<ttx> kirkland: not too bad :)
<kirkland> ttx: :-)  i was hoping for some good news
 * kirkland is tired of waking up to bad news every day
<seb128> slangasek, bug #444252 for the record is probably something to track
<ubottu> Launchpad bug 444252 in ubuntu "tmp cleaned during upgrades and breaking installations?" [High,Confirmed] https://launchpad.net/bugs/444252
<seb128> it's collecting duplicates quickly
<ttx> kirkland: actually it's surprisingly not too bad.
<kirkland> ttx: :-)
<kirkland> ttx: i'm very happy to hear that
<ttx> kirkland: using a collection of unrelated bugs, autoregistration actually works
<ttx> kirkland: see bug 444504
<ubottu> Launchpad bug 444504 in eucalyptus "Autoregistration through upstart, while working, uses strange ways" [Low,Triaged] https://launchpad.net/bugs/444504
<kirkland> ttx: now you're just getting picky!  :-)
<kirkland> :-P
<ttx> kirkland: i'm not really kidding. if we fix any of these bugs without fixing the others, autoregistration might fail :)
<kirkland> ttx: funny enough, i believe you
<ttx> kirkland: I committed a few fixes on the branch
<ttx> kirkland: an update to rev913 should help us, though it's a confusing mutifix rev
<ttx> kirkland: would you agree that is the upstart jobs post-start scripts fail to detect a working setup, then we should not try registration ?
<kirkland> ttx: i agree
<kirkland> ttx: as for "rev913"
<kirkland> ttx: i don't think we should merge any more upstream
<kirkland> ttx: i think we need to cherry pick whatever commit r913 is
<ttx> kirkland: however if I fix that without fixing bug 443325, that would break autoregistration
<kirkland> ttx: apply it in our branch, and release 0ubuntu2
<ubottu> Launchpad bug 443325 in eucalyptus "/services/Heartbeat fails on exception" [Undecided,Fix committed] https://launchpad.net/bugs/443325
<kirkland> ttx: merging is a pain in the ass at this point
<kirkland> ttx: see the mistake i made after i had merged 911, and then you asked me to merge 912, and I missed a step
<ttx> r913 is several fixes unfortunately. With the usual blank space noops
<ttx> so its quite confusing
<kirkland> ttx: that's fine, it can still be cherry picked
<ttx> The last one I encountered is bug 444352, some db deadlock on reboot
<ubottu> Launchpad bug 444352 in eucalyptus "DB deadlock on reboot prevents EMI from being started" [Medium,New] https://launchpad.net/bugs/444352
<ttx> we'll need nurmi on that one as well.
<Darxus> How do I do a kernel abi bump?
<Darxus> For bug #424927.
<ubottu> Launchpad bug 424927 in linux "[needs-packaging] include Brain <censored> Scheduler" [Wishlist,Confirmed] https://launchpad.net/bugs/424927
<mdz> cjwatson: thoughts on what the apport field name should be for bug 364649?
<ubottu> Launchpad bug 364649 in installation-report "Please include installation media build number in installation logs" [Wishlist,Fix released] https://launchpad.net/bugs/364649
<mdz> I was thinking UbuntuInstallationOrigin or UbuntuInstallationMedia or some such
<Darxus> I believe I answered my abi question (in the bug).
<cjwatson> mdz: prefer media over origina
<cjwatson> -a
<cjwatson> mdz: how about MediaInfo to match the file name?
<cjwatson> or InstallationMediaInfo
<cjwatson> I'd prefer not to have Ubuntu there, it's implicit in the fact that the bug is being reported from Ubuntu and it saves the usual questions about Kubuntu etc.
<mdz> cjwatson: "info" seems redundant. how about InstallationMedia?
<mdz> I think it's not obvious that that means "this is the installation medium which was used to install the system", hence the "origin" attempt
<beuno> mdz, would "source" be too confusing?
<Riddell> mvo: is hardy upgrade enabled in  the dist upgrade  tool?
<cjwatson> InstallationMedia or InstallationMedium sounds fine. "source" already has an overloaded meaning here, namely an apt source
<mdz> cjwatson: done, with InstallationMedia
<mdz> beuno: yes, I agree with cjwatson that it would be
<mdz> pitti: I've committed the trivial apport change to add InstallationMedia to Ubuntu bug reports; it is of course not critical for 9.10 but should be quite safe if you need to do another upload (and is tested)
<cjwatson> (apport field names are developer-facing more than user-facing and so developer jargon such as "apt source" is relevant)
<mvo> Riddell: should be, but not in the meta-release file
<dotblankalt> hey guys when is /dev/shm mounted?
<dotblankalt> cause its not in fstab
<cjwatson> in karmic, mountall does t
<dotblankalt> in 9.04 the asus touchpad acpi button broke and SHMClient is broken because of it
<mdz> cjwatson: it does? its man page doesn't document that fact
<dotblankalt> i fixed the touchpad button by using xinput instead but the latest update overwrote my changes to /etc/acpi/asus-touchpad.sh
<Riddell> mvo: no meta-release doesn't need changed, we patch adept to look for karmic
<cjwatson> dotblankalt: in 9.04, I believe it was the responsibility of /etc/init.d/mountdevsubfs.sh
<lool> slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner, davidm, cody-somerville, jdong: Hi; we have a serious upgrade issue post-beta; LP #444252 it seems a package upgrade clears /tmp, potentially erasing open user data; there are a bunch of dups; is this escalation worthy?  seb128 and james_w know more about the bug
<ubottu> Launchpad bug 444252 in ubuntu "tmp cleaned during upgrades and breaking installations?" [High,Confirmed] https://launchpad.net/bugs/444252
<cjwatson> mdz: mountall? its manual page doesn't document very much as yet ;-)
<cjwatson> ./src/mountall.c:218:   { "/dev/shm",                 NULL,        FALSE, "tmpfs",       "nosuid,nodev",                    NULL         },
<cjwatson> ./src/mountall.c:231:   "/dev/shm",                     /* Built-in */
<mvo> Riddell: ok, give it a go, but it should work. I added a auto-upgrade test profile for kubuntu and that looks ok too (also I did not do extensive testing, just looked if everything upgrades clearnly
<kees> lool: yeah, seems serious to me.  mountall erases /tmp if it mounts it.
<lool> I'm bumping the bug to critical
<seb128> kees, oh, you know what is creating the issue?
<cjwatson> mountall doesn't run on upgrade though does it?
<kees> seb128: no, but I saw mountall mentioned just now
<dotblankalt> ok
<dotblankalt> well I just tested the asus-touchpad on an aspire one
<dotblankalt> the button doesnt send any acpi events in acpi_listen
<dotblankalt> but the touchpad is disabled
<cjwatson> kees: the mountall discussion was independent, I thought
<dotblankalt> In the g51vx and others when the touchpad event fires synclient fails
<cjwatson> mountall clears /tmp at boot (with a grace period), but that's as intended. Clearing files from a running system on upgrade is quite a different matter ...
<kees> cjwatson: ah, well, it also jumps to mind as something that clears /tmp, but... I don't think it has changed recently.
<Pau_Gasol> juego de boxeo online http://www.kobox.org/kobox-fande-Nourine.html
<dotblankalt> I think the aspire one got around by doing this at the bios level
<dotblankalt> but alot of asus's touchpad buttons dont work in 9.04
<kees> seb128: are they all evolution failures?  (working my way through the dups...)
<kees> ah, no, ok
<mdz> cjwatson: that bug where the cloud install used -generic instead of -server is fixed now, right?
<cody-somerville> kees, the update-gconf-defaults might have been spawned by the evolution upgrade
<cjwatson> mdz: yes
<cody-somerville> oh wait
<cody-somerville> theres a g-p-m bug in there too
<cjwatson> mdz: I fixed it more or less on the spot during the last discussion
<kees> cody-somerville: yeah, though it's not clear if the gpm is related?
<rgreening> greg-g: ping
<mvo> lool: re #444252 - if its a maintainer script, the list is pretty small of of possible candidate, see https://bugs.edge.launchpad.net/ubuntu/+bug/444252/comments/6
<ubottu> Launchpad bug 444252 in ubuntu "tmp cleaned during upgrades and breaking installations?" [Critical,Confirmed]
<Keybuk> mvo: the one that calls shutil.rmtree() isn't a prime suspect? :)
<jdong> LOL
<kees> Keybuk: that's what I was looking at currently...
<cjwatson> that only nukes a temporary directory created with tempfile.mkdtemp though
<Keybuk> cjwatson: the traceback suggests it's failing partway through
<Keybuk> ie. the directory existed when it started
<Keybuk> no?
<mvo> Keybuk: heh - seb128 said gconf-schemas has not changed in months
<Keybuk> did shutil change?
<Keybuk> just a thought
<cjwatson> Keybuk: almost as if something's racing with it
<Keybuk> cjwatson: possibly
<Keybuk> or that it's screwed things up
<mvo> its also odd because in one of the logs brasero is installed and that calls gconf-schemas too
<Keybuk> is all of /tmp being wiped - or just that gconf directory?
<seb128> I'm wondering if bug #444452 and bug #444216 are not similar issues
<ubottu> Launchpad bug 444452 in pam "package libpam-gnome-keyring 2.28.0-0ubuntu2 failed to install/upgrade: il sottoprocesso vecchio script di post-installation Ã¨ stato terminato dal segnale (Interrupt)" [Undecided,New] https://launchpad.net/bugs/444452
<ubottu> Launchpad bug 444216 in pam "package libpam-gnome-keyring 2.28.0-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 143" [Undecided,New] https://launchpad.net/bugs/444216
<cjwatson> Keybuk: the traceback is basically right at the start of rmtree
<james_w> Keybuk: if I'm seeing the same issue then it is all of /tmp
<james_w> and perhaps /tmp itself, it's not clear
<cjwatson> all it does before that is os.path.islink, really
<Keybuk> fair enough
<kees> Keybuk: (unrelated to /tmp issue) where is deadline vs cfq handled during boot?
<kees> my system seems to be all deadline, but I was expecting cfq
<Keybuk> kernel default
<Keybuk> I believe they've changed it back to cfq again in -12
<kees> do you know how long has it been deadline?
<kees> Keybuk: ah, just -11
<lool> mvo: Good point; I checked devicekit-power's, evolution's and dmraid's scripts and didn't see anything thouhg
<cjwatson> devicekit-power seems like the kind of thing that might prod something asynchronouslsy
<cjwatson> but it's really not clear ...
<lool> Did someone confirm that the whole of /tmp gets cleared?
<seb128> no
<seb128> <seb128> james_w, you got tmp totally wiped, ie no directory there?
<james_w> I don't know
<seb128> <james_w>  when I looked I had /tmp/orbit-jw2328
<seb128> that's what we have from #ubuntu-desktop before
<james_w> I went to open the bug report when seb was talking about it, and gnome-open told me that it couldn't talk to orbit
<james_w> so I did "ls /tmp" and saw just that one path
<lool> Ok so it might not be rm -rf /tmp after all
<james_w> well something is removing at least most of /tmp, if not all of it
<lool> james_w: No pulse-* keyring-* then
<lool> james_w: Ok
<james_w> my working assumption was that it created that path as it found that it didn't exist
<lool> There was a python update at that time
<lool>  -- Matthias Klose <doko@ubuntu.com>  Sun, 04 Oct 2009 21:28:36 +0200
<lool> It could be that these are the first updates we're seeing with this new python
<seb128> lool, we did start getting bugs only today though
<lool> seb128: Yeah exactly
<seb128> lool, I doubt it, we got lot of uploads yesterday
<seb128> and probably lot of people who upgraded after weekend and got those
<seb128> oh, you mean one upgrade to get the new python and one later to run into troubles?
<seb128> hum...
<lool> Yes
<pitti> mdz: apport change> thanks; I'm certain I'll do another bug fix upload for karmic
<james_w> the python diff doesn't look very suspicious to me
<james_w> oh, there were two uploads
<lool> I tried sudo apt-get install --reinstall brasero libdevkit-power-gobject1 devicekit-power  usplash evolution-common evolution
<lool> Couldn't reproduce
<lool> (usplash instead of dmraid to trigger an update-initramfs)
<lool> Oh .tmp empty!
<seb128> lool, what did you do?
<bdrung_> Keybuk: what's the progress of the unit policy?
<lool> Either that sudo did it, or installing dmraid did it
<lool> sudo didn;t
<mvo> lool: dmraid is something that is common in the reports
<mvo>  the diff looks harmless
<seb128> lool, you seem to be getting closer
<lool> mvo: yes, I almost mentionned it
<mvo> update-initramfs maybe?
<Keybuk> bdrung_: deferred
<lool> Just installing dmraid is enough to reproduce
<bdrung_> Keybuk: i read that. when will you work on it?
<Amaranth> Confirmed, installing dmraid wiped my /tmp
<Amaranth> but the directory still exists
<Keybuk> bdrung_: when I am not busy
<bdrung_> Keybuk: newer? ;)
<bdrung_> s/newer/never/
<mvo> yeah, same here, but it seems to be happening when update-initramfs takes place
<Amaranth> yeah
<Keybuk> bdrung_: after the releas
<bdrung_> Keybuk: k, thanks. let me know, when you work on it.
<mvo> I see a trace of /tmp/mkinitfamfs-3432 and mkinitramfs_3234
<mvo> and now its gone
<Amaranth> but that was last changed on the 3rd
<cjwatson> update-initramfs shouldn't be doing anything in parallel ...
<ogra> tedg, hmm, am i supposed to see pidgin in my indicator applet even though i dont have it installed ?
<mvo> I was doing things in parallel (installing and watching /tmp) :)
<Amaranth> it's nice how things recover from /tmp going away :)
<lool> It seems to be before update-initramfs
<lool> At the time where this is run:
<lool> + echo update-initramfs: Generating /boot/initrd.img-2.6.31-11-generic
<lool> I already lost my /tmp
<lool> perhaps at the very beginning of mkinitramfs
<Amaranth> But it would have to be something else changing
<Amaranth> Because the update of initramfs-tools would have called update-initramfs and wiped everything on the 3rd
<tedg> ogra, no, but the chances are you installed while there was a bug that it didn't uninstall.  The bug if fixed, but that doesn't help :)
<tedg> ogra, you can just rm -rf /etc/indicators/
<kees> hrm.  in a chroot, installing dmraid did not wipe my /tmp
<kees> Amaranth, lool: did anything else install with dmraid when you installed it?
<Amaranth> just the library
 * kees boots a VM
<Amaranth> libdmraid1.0.0.rc15
<lool> kees: libdmraid
<ogra> tedg, ok, i'll watch it
 * Amaranth is wondering the sanity of testing this on his actual system now
<mvo> for me its gone around the time when udevadm trigger --subsystem-match=block --action=change is called
<mvo> (so right after update-initramfs -u)
<mvo> ok, so udevadm trigger and tmp is empty
<james_w> hmm
<lool> mvo: You confirmed that command kills it?
<james_w> on a "sudo strace -f aptitude reinstall dmraid"
<Amaranth> Confirmed
<mvo> udevadm trigger --subsystem-match=block --action=change
<james_w> I see /tmp go and then mkinitramfs stuff
<kees> Keybuk: how/when does mountall run?
<Amaranth> `sudo udevadm trigger --subsystem-match=block --action=change` and my /tmp is empty again
<james_w> that's before that
<Amaranth> james_w: it's asynchronous, I think
<cjwatson> I was under the impression that any use of udevadm trigger on a live system had been quite clearly announced as a bug
<lool> Amaranth: here too
<james_w> Amaranth: update-initramfs is?
<Amaranth> james_w: no, the other call
<Keybuk> kees: on boot
<Keybuk> cjwatson: indeed
<james_w> Amaranth: yes, but update-initramfs runs first
<cjwatson> as in, this is exactly the sort of thing you should expect to happen when you run udevadm trigger
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
<james_w> and presumably that is the bit that puts the mkinitramfs dirs in /tmp
<kees> Keybuk: ok, just verifying.
<cjwatson> mind you
<cjwatson> that says "change is completely safe"
<cjwatson> while Amaranth says that udevadm trigger --subsystem-match=block --action=change breaks his world
<Keybuk> cjwatson: ...except for block devices ;)
<Keybuk> well, except for *RAID* block devices and stuff
<cjwatson> Keybuk: ... on a Tuesday
<mvo> mine too
<lool> cjwatson: hahaha
<Keybuk> precisely
<lool> openoffice!
<Keybuk> in general anything other than udev calling udevadm trigger is bad
<lool> mvo: packagekit!
<cjwatson> ok, so what's calling it?
<lool> cjwatson: dmraid postinst
<lool>     # Activate existing arrays now.
<lool>     udevadm trigger --subsystem-match=block --action=change
<Keybuk> (though there's definitely a mountall bug that it wipes /tmp more than once <g>)
<lool> Keybuk: what can we use instead?
<cjwatson> so dmraid is in the category of "I've installed udev rules and want udev to do something about it"
<Keybuk> it's probably "right"
<kees> yeah, isn't this the correct invocation, according to the ubuntu-devel email?
<Keybuk> but something's always going to blow up
<Amaranth> But dmraid also hasn't been updated for some time
<Keybuk> there isn't a correct solution to this
<Keybuk> unfortunately the real answer is probably "reboot" right nwo
<lool> So we should drop the call and add a reboot required touch?
<lool> actually update-initramfs probably does that anyway
<cjwatson> mm, surely if you're upgrading dmraid you either have your arrays working about as well as you might expect, or will be content to reboot
<cjwatson> I don't know that a reboot is always required, only if your arrays aren't there
<cjwatson> but that's a recovery-type operation anyway
<ogra> update-initramfs definately doesnt ... that would be horrid :)
<Keybuk> why not just run whatever it is the udev rules run?
 * kees cringes at "reboot" being a solution to anything on a linux system
<Keybuk> if dmraid is trying to activate raid devices, isn't there just a dmraid --scan type thing?
<ogra> kees, you are so old school :)
<kees> :)
<cjwatson> dmraid-activate %k, apparently
<cjwatson> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_TYPE}=="disk", ENV{ID_FS_USAGE}=="raid", KERNEL=="hd[a-z]|sd[a-z]", \
<cjwatson>         RUN+="/sbin/dmraid-activate %k"
<kees> this seems a bit off-topic.  what is _wiping_ /tmp as a result of --action=change ?
<Keybuk> kees: mountall probably ;)
<kees> Keybuk: so it's not just at boot, then?
<cjwatson> or there's dmraid -ay
<Keybuk> since that WHEEE EVERYTHING CHANGED! also happened to tell mountall that you changed the root filesystem ;)
<kees> so mountall should not wipe /tmp if it's already mounted...
<Keybuk> kees: not sure why it didn't go away
<Keybuk> but sometimes it hangs around if there's something in fstab it wants to mount but can't yet
<Keybuk> probably your dmraid devices, ironically
<Amaranth> None of these packages have been updated recently though
<Amaranth> mountall, udev, dmraid, etc
<kees> it could just be people doing the beta install.
<Keybuk> kees: yeah I said that above
<Amaranth> So why did it start blowing up now?
<lool> cjwatson: I could run that I guess
<james_w> Amaranth: dmraid was uploaded yesterday
<james_w> Amaranth: about 2 hours before the bugs started showing up
<Amaranth> hrm, mine says september
<cjwatson> dmraid -ay sort of concerns me, though. isw arrays have special handling in dmraid-actvate
<james_w> this morning I mean
<cjwatson> honestly, I think it would be safer just not to do anything in the postinst
<kees> Keybuk: ah, ok.  so, bug in mountall, then?  doesn't sound like we need to change dmraid?
<lool> cjwatson: is -a for all or for activate?
<Amaranth> oh, the changelog is out of date (aptitude changelog)
<cjwatson> lool: activate
<lool> Ok no -activate man page
<lool> no --help
<cjwatson> lool: but as stated I'm not convinced that it's the right answer
<ogra>   * debian/dmraid-activate: Remove the special-casing of the root
<ogra>     device which breaks in many situations and leaves the raw devices
<ogra>     exposed.
<ogra> very suspicious
<lool> cjwatson: Ok to upload a dmraid commenting out the udevadm call?
<lool> I have that ready here as a stopgap
<cjwatson> lool: it's fine by me, I think it would be by and large safe
<cjwatson> needs a comment though!
<kees> uhm, is the ubuntu-devel email incorrect then?  we're removing functionality from dmraid due to a mountall bug?
<Darxus> dch -i doesn't work in the linux-image packages because debian/changelog is overwritten by debian.master/changelog.  Is there a reason I shouldn't file a bug about that?
<Amaranth> Darxus: Because it's expected?
<lool> cjwatson: Of course
<kees> Darxus: should not file a bug because that source package is not designed to work with dch
<lool> http://paste.ubuntu.com/287086/ what I uploaded
<sistpoty|work> Darxus: use -c debian.master/changelog as dch argument
<cjwatson> kees: is this functionality that is ever needed? enabling arrays on package upgrade?
<cjwatson> seems kind of bizarre to me
<kees> cjwatson: on _upgrade_ no, but install, yes?
<Darxus> Where is that behavior in the linux image packages documented?
<cjwatson> even that seems kind of odd to me
<lool> cjwatson: Do you think this bug is worth an incident writeup?  we closed the bug in roughly one hour, so I'm not sure whether it needs it
<kees> cjwatson: why? you've installed the software to handle a device; I would expect the devices to appear.
<cjwatson> although fixing dmraid to do this only on fresh install seems to me as if it would fix this bug
<cjwatson> oh, no, not quite
<kees> the bug is mountall's... it should not clear a mounted /tmp.
<cjwatson> lool: I don't think it needs it, personally
<lool> kees: That's my feeling as well
<Amaranth> So add an also affects for mountall to keep track of it
<cjwatson> kees: right, but udevadm trigger is historically a painful thing to call and we *should* be avoiding it wherever possible
<lool> slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner, davidm, cody-somerville, jdong: incident closed, bug fix uploaded
<seb128> lool, thanks
<pitti> lool: merci
<Keybuk> lool: "incident"  we're pre-release?
<kees> cjwatson: should a follow-up to the ubuntu-devel email be sent then?  it seems like dmraid qualifies as a caller of trigger.
<Keybuk> ie. _still_in_development_
<kees> Amaranth: yeah, I would say the dmraid "fix" should be reverted once mountall is fixed.
<Darxus> Can I file a bug for dchi needing a -c argument being undocumented?
<pitti> lots of more innocent people testing beta now, though
<Keybuk> so?
<cjwatson> kees: up to Keybuk, I'm not all that familiar with the innards
<Keybuk> kees: I'd say that any use of udevadm trigger is a bug
<Keybuk> and should be removed wherever possible
<kees> Keybuk: I'm not in a position to debate that; but having mountall wipe /tmp after it's in use is a bug regardless.  :)
<Keybuk> it's always going to have unwanted side-effects
<Keybuk> because you're in effect saying "go do whatever you want, have fun!"
<Keybuk> extreme case
<Keybuk> udevadm trigger could result in a reboot ;)
<kees> Keybuk: if the trigger thing is always a bug, then a follow-up to the email describing when/how to use it should be made.
<Keybuk> udevadm trigger -> block device now available that's listed in fstab -> fsck runs -> fsck indicates filesystem was repaired and reboot required -> reboot
<kees> email says, e.g. ""change" is completely safe."
<Keybuk> kees: the e-mail is out of date
<Keybuk> we do more as a result of udev events now
<kees> :P
<Keybuk> feel free to follow up
<kees> I would except I don't know what's "current".  :)
<Keybuk> there's zero point in e-mailing anyway
<Keybuk> nobody reads them
<kees> Well, I do.  :P
<Darxus> Is debian/README.source the right place to document the need for a -c argument to dch ?
<Keybuk> or they argue the toss when they're caught ignoring them
<kees> Darxus: that's probably the best, yes.
<smoser> can someone with commit access please revert slangasek's commit at http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.karmic/revision/1581 ? the changes required in kernel are available now.
<Darxus> kees: Thanks.
<kees> Keybuk: how do I find out what mountall is waiting on?
<Keybuk> kees: gdb
<kees> Keybuk: would you normally expect mountall to exit soon after boot on a "normal" system?
<Keybuk> yes
<cjwatson> smoser: done
<Keybuk> though, admittedly, it doesn't for me here <g>
<Keybuk> probably a bug
<kees> yeah, me either
<smoser> thank you cjwatson
<cjwatson> mountall's still running here too, I don't have anything much complex
<cjwatson> ... oh, apart from those NFS mounts
<ogra> mountall --daemon --tmptime=0
<ogra> here as well
<kees> I have a VM with /, /proc, and swap in fstab and it's running.  ;)
<ogra> what does --daemon mean
<ogra> i dont have anything apart from / and /home here
<cjwatson> ogra: I think you should probably read the source
<Keybuk> ogra: a daemon is a special type of UNIX process
<Keybuk> they run it what we call the "background"
<Keybuk> you see, UNIX is a multi-tasking operating system
<Keybuk> so many different things can all run at once
<Keybuk> isn't that clever :P
<ogra> Keybuk, oooh and i thought soemthing mystically :P
<ogra> like religious or so :P
 * ogra was meaning if it is supposed to run in daemon mode even without any networked FSes 
<ogra> ok, apparently it is
<seb128> tedg, hey
<cjwatson> Keybuk: I'm actually a bit baffled by bug 435707, having gone through the logs again in light of that most recent comment
<ubottu> Launchpad bug 435707 in mountall "/forcefsck doesn't check root filesystem when passno=0" [Low,New] https://launchpad.net/bugs/435707
<cjwatson> Keybuk: I still think the fix you merged from me is correct, but I no longer think it has anything to do with that bug :-) The log shows mountall getting past that point in run_fsck
<Keybuk> does it run fsck? :)
<cjwatson> it says it does
<Keybuk> does it run it with -f ?
<cjwatson> spawn: fsck / [820] - but the log message is obscured and doesn't print the arguments
<cjwatson> actually, why aren't we getting a debug message from the spawned child?
<cjwatson> there should be one immediately before the execvp
<Keybuk> probably usual stdio fuckage
<Keybuk> I fixed that in trunk
<cjwatson> r47?
<cjwatson> I think you might also need a flush after the nih_debug
<Keybuk> don't you get a flush on exec anyway?
<cjwatson> Keybuk: no
<Keybuk> surely you must do?
<cjwatson> why so?
<cjwatson> certainly nothing specifies it, and glibc's execve stub is pretty simple and doesn't do it
<Keybuk> otherwise what takes care of that?
<Keybuk> your stdio buffers don't magically get passed via shared memory to the exec()d process that obviously knows what to do with them <g>
<cjwatson> (it would have to be in the libc)
<cjwatson> you're supposed to flush before exec
<Keybuk> where does it say that?
<cjwatson> it's implicit in the fact that exec doesn't flush :)
<Keybuk> cjwatson: it doesn't say that it doesn't
<cjwatson> reality does, though ...
<Keybuk> I'll take your word for it ;)
<pitti> lifeless: so what are you looking for, desktop translation wise?
<lifeless> pitti: the mechanism; ted has a bug where the indicator menu entries are not being translated
<lifeless> they are from the desktop files, and if he sets a domain for the menu process, they don't translate
<tedg> pitti: seb128 is saying that removing the textdomain setting makes it work for him.
<kees> pitti: should apport use launchpad.net instead of edge?
<pitti> tedg: what's the .desktop file?
<pitti> kees: for what?
<lifeless> pitti: several
<tedg> pitti: evolution-mail, pidgin, etc.
<lifeless> one example is evolution-2.28
<seb128> tedg, it works on a simple testcase though
<seb128> I wrote one this morning which does the same init
<seb128> ie setlocale, bindtextdomain and textdomain
<seb128> and things are correctly translated
<pitti> lifeless: hang on, I thought we're talking about the indicator applet .desktop file?
<kees> pitti: bug 440576
<ubottu> Launchpad bug 440576 in apport "After karmic upgrade, apport sends me to bugs.edge.launchpad.net instead of the real launchpad" [Undecided,Invalid] https://launchpad.net/bugs/440576
<seb128> I need to try again your code
<lifeless> pitti: nope, about the things it shows which are refleccted via g_app_info
<seb128> gdesktopapp basically use gkey which use gettext
<pitti> kees: apport doesn't do anything in particular for edge; the reporter is probably in lp-beta-testers?
<pitti> oh
<lifeless> that should be either calling dgettext or binding and restoring the domain
<lifeless> pitti: so we just wanted to know where the strings to go help in debugging/building hypothesis
<pitti> now I know what you are talking about
<pitti> so that code reads the .desktop files?
<seb128> I already explained to tedg how those are working...
<lifeless> seb128: yup, we get that
<seb128> pitti, no, it uses gdesktopapp which use gkey
<seb128> which is the glib change you wrote
<lifeless> seb128: sorry if we are treading somewhat the same path
<seb128> that works fine on a small testcase there
<bdmurray> Keybuk: the "usb-id" messages in bug 443282 are the normal part or is it something else?
<ubottu> Launchpad bug 443282 in upstart "No xsplash, I get console boot messages instead" [Undecided,Won't fix] https://launchpad.net/bugs/443282
<pitti> if you do that parsing manually, you have to use dgettext yourself, yes
<tedg> seb128: Yeah, I tried to explain it to lifeless, that's why he's confused now ;)
<kees> pitti: ./apport/crashdb_impl/launchpad.py:            launchpad_instance = EDGE_SERVICE_ROOT
<lifeless> pitti: no, we don't, we're using the standard api
<seb128> who would like to parse those manually anyway?
<Keybuk> bdmurray: kernel bug of some kind
<pitti> kees: oh, that; but that's not related to where the browser sends you to, it's been there forever
<pitti> kees: mainly because there is no production launchpadlib API (or at least hadn't been until recently)
<kees> hrm, good point
<bdmurray> Keybuk: so that bug should have a linux bug task opened then?
<Keybuk> if you like
<bdmurray> Maybe I'm confused but there was a call bug bugs to be reported regarding boot messages.  Where do these belong?  Do we not want all of them?
<Keybuk> bdmurray: whoever did the call didn't think that far ahead
<smoser> anyone know how much space a full ubuntu mirror takes ?
<Amaranth> smoser: doesn't debmirror tell you before it starts?
<smoser> Amaranth, i dont know. but i just now saw http://www.ubuntu.com/getubuntu/mirror/1  ("A "full archives" mirror is around 210")
<lool> smoser: What part?
<smoser> i think the link above has what i was asking, lool.
<lool> ok
<pitti> rickspencer3, kenvandine: FYI, bug 436591 is the one I meant (empathy crasher); it's already on the targetted list
<ubottu> Launchpad bug 436591 in empathy "empathy crashed with SIGSEGV in g_cclosure_marshal_VOID__VOID() when using indicator-applet 0.1 to display an active conversation" [High,In progress] https://launchpad.net/bugs/436591
<lool> Keybuk: so from reading the discussions here, you dont want a mountall task on that bug?
<kenvandine> pitti, i will am looking at that
<Keybuk> lool: I've said repeatedly that I accept that there's a mountall bug here *as well*
<pitti> Keybuk: right, just because of the "make sure it's targetted" that came up during the meeting
<Keybuk> though at this point I've lost all track of bug numbers
<Keybuk> and am just going to go around at release time and close any I think I've fixed
<lool> Keybuk: Ok so I'm adding a task, do what you think is best with it
<Darxus> I'm really surprised launchpad didn't email me when my build completed.
<pitti> Darxus: since that's the common case, it just mails you if it failed
<Darxus> pitti: That's good.  And I can set an alarm based on when it predicts the build will start... but since it takes so long some times, and I'm generally anxious to have it done, it would be nice to get an email.
<dupondje> are there known problems with apparmor & dhclient3 ?
<dupondje> http://paste.ubuntu.com/287038/ <- can't get these fixed :s
<LaserJock> anybody know what the CLI name of "Universal Access Preferences" is?
<slangase`> seb128: pam-auth-update shouldn't be touching /tmp at all
<seb128> slangase`, there is nothing in debconf using tmp which could get confusing on tmp wiping?
<Amaranth> LaserJock: gnome-at-properties?
<LaserJock> Amaranth: hmm, doesn't seem to be it
<slangase`> seb128: no, it has its own /var/cache dir, no reason to write anything at all to /tmp
<seb128> slangase`, ok, so ignore me, I just though that the timing was suspicious
<Amaranth> LaserJock: grep "Universal Access" /usr/share/applications/*
<Amaranth> LaserJock: then open that file and check the Exec
<slangase`> "udevadm trigger" -hahaha
<slangase`> lool: nice bug
<slangase`> lool: you still have a task open on mountall; is that an issue or not?
<seb128> slangasek, we got 2 of those pam bugs today btw, reassigned your way
<LaserJock> Amaranth: no help
<Amaranth> LaserJock: I've never heard of it
<Amaranth> slangasek: Technically the bug is that mountall wipes /tmp on an already running system, the dmraid change is a workaround
<LaserJock> Amaranth: I mean, the grep returns nothing
<Amaranth> LaserJock: Right, I figured that
<Amaranth> LaserJock: Was saying I've never heard of anything called "Universal Access Preferences"
<Amaranth> I have "Assistive Technologies"
<Amaranth> but that's gnome-at-properties
<cjwatson> there's a "Universal Access" *menu* ...
<slangasek> seb128: hmm, more of that pam bug?  Ok, maybe it does have something to do with /tmp, in a way I don't understand
<Amaranth> cjwatson: not here
<slangasek> maybe the debconf GNOME frontend breaks when /tmp goes away
<cjwatson> Amaranth: provision for one anyway
<Amaranth> Right, but empty
<seb128> slangasek, yes
<cjwatson> slangasek: debconf in general uses /tmp
<slangasek> oh
<slangasek> drat, then :)
<slangasek> ok, I'll mark them as dupes
<seb128> slangasek, thanks
<cjwatson> not that I can remember exactly where
 * Amaranth should probably log out to fix his /tmp getting wiped eventually
<cjwatson> I'm sure it's somewhere other than in the dialog and editor frontends
<Amaranth> but lunch sounds more important right now
<LaserJock> Amaranth: it's in my systray and I can't figure out where it came from or how to get rid of it
<Amaranth> LaserJock: oh, that's gnome-at-properties
<cjwatson> speaking of menus, why do I have a duplicate Calculator item at the top level of Applications?
<Amaranth> LaserJock: uncheck the first box there
<Amaranth> LaserJock: the app itself is gnome-at-visual
<LaserJock> Amaranth: it is unchecked :(
<LaserJock> Amaranth: and gnome-at-visual is not running
<slangasek> cody-somerville: seen that xubuntu livefs builds are failing?  Looks like a seed ordering problem, maybe
<Amaranth> LaserJock: Well I'm stumpted
<Amaranth> err, stumped :P
<LaserJock> Amaranth: hmm
<slangasek> cody-somerville: oh, no - I guess this is an already-fixed bug in xubuntu-gdm-theme, and the ports just need to catchu p
<slangasek> cjwatson: hmm, seen bug #444587?  Seems to be a regression caused by your latest grub upload
<ubottu> Launchpad bug 444587 in grub "grub fills disk space in karmic (540MB) (dup-of: 444703)" [Undecided,New] https://launchpad.net/bugs/444587
<ubottu> Launchpad bug 444703 in grub "package grub 0.97-29ubuntu57 failed to install" [Undecided,New] https://launchpad.net/bugs/444703
<Amaranth> Every install of grub comes with a free desktop ISO ;)
<cjwatson> slangasek: blink. Will look, thanks
<cjwatson> I certainly didn't change anything directly related to that
<slangasek> oh; I didn't look too deeply, I thought 'objcopy' was kind of a red flag word :)
<cjwatson> that was only in the configure script
<slangasek> ok
<Darxus> Hah, damn, telepathy-idle FTBFS... the irc piece of empathy, the default chat client in karmic.
<cjwatson> reproduced in a local build, but dinner is ready so it'll have to wait
 * slangasek nods
<cjwatson> might be able to backport another piece from grub2 for that
<LaserJock> is there a place that gnome lists what apps to restore from a session?
<cjwatson> slangasek: at least the .deb compresses well ;-)
<slangasek> indeed!
<cjwatson>  size 1892884 bytes: control archive= 6106 bytes.
<cjwatson>  Installed-Size: 526916
<cjwatson> 285x compression
<cjwatson> slangasek: actually, sod it - fixing now
<cjwatson> might not hurt to crank grub 0.97-29ubuntu58's build priority up some
 * cjwatson goes to eat
<lifeless> seb128: this translation thing; is it release critical?
<lifeless> seb128: we're assuming it is for now, but if its not, we have some rc stuff we would switch to
<seb128> lifeless, no it's not, I've a one liner workaround
<lifeless> seb128: ok, thanks. Thats disabling the indicators own translations?
<tkamppeter> pitti, there still seems to be a problem with USB printing, see bug 420015, comment #105, user tells that he has to set /dev/bus/usb/*/* permissions manually so that printer gets discovered and new udev rules did not make it into current udev.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/420015/+text)
<seb128> lifeless, I will need to test, it's commenting the textdomain call
<seb128> lifeless, don't bother with that bug for now
<lifeless> seb128: we suspect that will disable the translation for 'm' etc beside the time data
<seb128> lifeless, thanks for letting me know I will check that but I want to try debugging it first, I've a working testcase and I know how it's supposed to work so I will give it a try
<seb128> ie a standalone gtk code with the same locale init code works correctly
<pitti> tkamppeter: hm, current cups runs the usb backend as root again; that still doesn't work?
<lifeless> seb128: right, I
<seb128> I will keep you guys updated tomorrow
<lifeless> 've been looking at the glib patch
<pitti> tkamppeter: also, I thought we'd use usblp again?
<lifeless> seb128: and i'm happy to follow through and debug it directly too
<lifeless> seb128: I think its g_dgettext perhaps.
<lifeless> I think I may know what it is
<seb128> lifeless, oh ok, what is it?
<seb128> it's weird that my testcase is working then
<lifeless> look at g_dgettext in devhelp
<slangasek> ArneGoetje, pitti: language-pack-gnome-bo uninstallable, breaking livefs builds?  Known issue?  (related to our space problem?)
<lifeless> it disables all translations if the application doesn't have a translation
<lifeless> so if the indicator-messages-service isn't translated *itself*, it won't show trnslations for anything else either
<seb128> lifeless, define "the application doesn't have a translation"
<seb128> lifeless, ie if there is no mo file to use?
<seb128> lifeless, ok, easy to try, add a dummy string to translate and see if that fixes the issue
<lifeless> seb128: I'm reading devhelp, so I can't define "the application doesn't have a translation" very well
<lifeless> but yes, I think a mo file - even an empty mo file - for the indicator-messages-service domain will make it work
<pitti> slangasek: presumably; it just stopped in the middle of generation
<lifeless> seb128: if your test case has a mo file for your test local, that would be why it works
<lifeless> seb128: here's how I'd test - change the DOMAIN that indicator-messages-service binds to to be something that is translated
<lifeless> e.g. gnome-panel or something
<seb128> lifeless, the testcase was using a dummy domain for the textdomain calls
<seb128> lifeless, thanks for the hints, I will play with that after dinner
<lifeless> or install glib dbgsym and breakpoint translated = g_dgettext (key_file->gettext_domain,
<seb128> right
<lifeless> then see if it returns the orig value even though the domain etc has been set right
<seb128> did you guys try that?
<lifeless> no, I was prepping to do that when we realised that the behaviour of g_dgettext was relevant
<lifeless> and read up on it.. with shocking results;)
<seb128> anyway as said I've a good idea how to look at the returned string etc so I will play with that later
<lifeless> cool
<seb128> I need to go for dinner now
<lifeless> good luck
<seb128> bll
<seb128> bbl
<seb128> thanks
<seb128> you too for the next issue you will tackle ;-)
<tormod> TheMuso, I reopened bug 440846 with a debdiff, can you please take a look?
<ubottu> Launchpad bug 440846 in speech-dispatcher "speech-dispatcher is very verbose about not being started" [Undecided,Confirmed] https://launchpad.net/bugs/440846
<pitti> Keybuk: is /sys/class a list of subsystems, or are "class" and "subsystem" different concepts?
<ElNerdoDeGeek> Hey, who should I contact concerning a possible (fairly major) Wubi feature?
<lool> slangasek: Task on mountall is just to track the fact that it's also a mountall bug that it shouldn't blow /tmp like that when already mounted
<lool> slangasek: But fixing one or the other seems enough the drop the bug from its critical status
<slangasek> lool: ok - can the mountall task be triaged to something more appropriate than new/undecided, then?
<lool> slangasek: There was a longer discussion here between Keybuk and others and I didn't follow the specifics of the mountall issue
<lool> slangasek: Sure; I'll confirm + assign keybuk
<lool> Sorry I kind of disappeared for other calls after doing the dmraid upload :)
<lool> done
<tkamppeter> pitti, I am only telling what was reported in bug 420015, but perhaps this user has fallen into an infinite loop of trying to get his USB printer recognized.
<ubottu> Launchpad bug 420015 in cups "usblp Kernel module needs to be removed and /dev/bus/usb/*/* made accessible for USB printers to work with CUPS 1.4.x" [High,Fix released] https://launchpad.net/bugs/420015
<slangasek> pitti: would be interested in a quick FFe review of bug #238555 if you can spare the time
<ubottu> Launchpad bug 238555 in pm-utils "pm-utils doesn't reload hdparm.conf after a suspend" [Undecided,Confirmed] https://launchpad.net/bugs/238555
<pitti> slangasek: replied in the bug
<slangasek> pitti: thanks
<slacker_nl> hello, I just noticed /etc/apt/preferences.d i take it the logic behind that dir is the same as /etc/apt/sources.list.d
<slacker_nl> does anyone have any documentation regarding this change?
<slacker_nl> never mind, found it http://osdir.com/ml/debian-bugs-closed/2009-07/msg03476.html
<geser> slacker_nl: sources.list.d is for additional repository snippets, while preferences.d is for pinning snippets
<slacker_nl> geser: that's what I'm saying, same logic as sources.list.d, but then for pinning
<slacker_nl> i know enough
<slangasek> pitti: hdparm_is_on_battery> yes, you divined my intent accurately, sorry if this was opaque :)
<slangasek> pitti: I note you didn't mark the FFe as 'confirmed' - I've followed up again responding to some of your comments, is that enough for an FFe now?
<mathiaz> slangasek: hey - could update the links to test cases on the iso tracker?
<slangasek> mathiaz: yes, what links?
<mathiaz> slangasek: http://testcases.qa.ubuntu.com/Install/UECInstall
<mathiaz> slangasek: ^^ should be replaced with two urls
<mathiaz> slangasek: http://testcases.qa.ubuntu.com/Install/ServerECluster for "Install (UEC Cluster Controller)"
<mathiaz> slangasek: http://testcases.qa.ubuntu.com/Install/ServerENode for "Install (UEC Node)"
<mathiaz> slangasek: is that enough info?
<slangasek> mathiaz: yes, thanks
<sandberg_> Anyone with experience of Policykit and DBus?
<sandberg> I'm having some issues with policykit (bug #439552), seems like this involves UID checking of DBus connections. The strange thing is that I have two installations of Karmic and only the one upgraded from Jaunty is affected by the bug.
<ubottu> Launchpad bug 439552 in policykit-1 "Policykit authentication dialog not responsive to clicks on the 'Authenticate' button" [Undecided,New] https://launchpad.net/bugs/439552
<Darxus> Screen just crashed on me :/
<slangasek> Keybuk: bug #427356 still has a 'cups' task open; is that still on the agenda for 9.10?
<ubottu> Launchpad bug 427356 in cups "Boot Performance Updates" [Undecided,Confirmed] https://launchpad.net/bugs/427356
<slangasek> mathiaz: tracker test case links updated
<tormod> sleep/hibernate: if I press my sleep key, gpm does the job its way, if I use the menu, it's done another way by indicator-session. shouldn't this be unified?
<slangasek> tormod: both are supposed to be done via devicekit-power -> pm-utils; is this not the case?
<tormod> slangasek, I noticed the way they turn on the screensaver is different
<slangasek> ah, that's possible :/
<slangasek> since that's GNOMEy and therefore not part of what devicekit-power will handle
<slangasek> I think that should be a bug report, definitely
<tormod> there was recently added stuff to indicator-session but not the same stuff as in gpm
<tormod> ok, I can file a bug. on indicator-session maybe? can i-s call gpm to get the same path run?
<kirkland> mdz: today's Eucalyptus testing is looking good
<kirkland> mdz: i have a cluster + 2 nodes going now
<kirkland> mdz: installed from today's ISO
<kirkland> mdz: auto registration worked flawlessly
<kirkland> mdz: having issues with the UEC image, it won't run
<kirkland> mdz: the eucalyptus images are working fine though
<slangasek> tormod: I don't know whether there's a path it can invoke, but that shouldn't be a barrier to getting the bug filed on indicator-session and getting people's eyeballs on it :)
<tormod> slangasek, I filed bug 444931
<ubottu> Launchpad bug 444931 in indicator-session "indicator-session executes another suspend procedure than gnome-power-manager" [Undecided,New] https://launchpad.net/bugs/444931
<mathiaz> slangasek: thank ya
<sroecker> just filed a new bug 444962 that will confuse many beta testers
<ubottu> Launchpad bug 444962 in shared-mime-info "shared-mime-info-0.7-ubuntu1 update is broken" [Undecided,New] https://launchpad.net/bugs/444962
<tormod> slangasek, should I make a new debdiff for bug 384875?
<ubottu> Launchpad bug 384875 in laptop-mode-tools "ships two different sleep.d hooks" [Low,Fix released] https://launchpad.net/bugs/384875
<slangasek> tormod: I'm just now merging/reviewing your branch; I figured I'd fix up the conffile handling myself afterwards
<slangasek> tormod: is there anything in the upstream sleep.d script that we should worry about merging?
<slangasek> I guess both scripts are trivial :)
<tormod> slangasek, the only difference is that upstream calls laptop_mode auto force and not only auto
<tormod> can't remember right now, but we have some Ubuntu changes wrt auto and force
<slangasek> tormod: well, no; the main difference is that it respects disabling laptop-mode via /etc/default...
<tormod> slangasek, yeah I meant other than the obvious :)
<slangasek> ok :)
<tormod> we also ship a power.d/laptop-mode, I am to tired to think about why and if :)
<slangasek> heh, ok
<jbernard_> ive been taking a look at some of the FTBFS problems, cmake builds fine now with the latest version of libxmlrpc-core-c3-dev, we could remove that from the list
<tormod> slangasek, if you have time, maybe you can look at my debdiff for bug 430121
<ubottu> Launchpad bug 430121 in acpid "package acpid 1.0.6-9ubuntu6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/430121
<cjwatson> jbernard_: not easy to just remove something from the list, it's generated from an automatic build pass
<cjwatson> jbernard_: if it builds fine now, great
<cjwatson> unfortunately http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html doesn't have any annotation facility at the moment, which is probably impeding serious work on it
<cjwatson> wgrant: ^- would it be incredibly painful to add something?
<slangasek> tormod: I wonder if bug #384875 is the reason some people have been reporting that their disks are still spinning down when they shouldn't :/  (laptop-mode calls hdparm -S 10)
<ubottu> Launchpad bug 384875 in laptop-mode-tools "ships two different sleep.d hooks" [Low,Fix released] https://launchpad.net/bugs/384875
<cjwatson> I mean, today I glanced down the list and fixed various things in main
<cjwatson> but if I were to do more than that, I'd almost certainly hit diminishing returns as I start to run into things that other people have fixed
<tormod> slangasek, possible
<slangasek> cjwatson: "already fixed" - I thought packages that are superseded by newer versions in the archive are supposed to be removed from that page already?
<cjwatson> oh?
<jbernard_> i believe this is true
<cjwatson> hmm, so they are, in that case I take it back
<jbernard_> but in cmake's case, it failed because of another package
<jbernard_> so it wasn't picked up
#ubuntu-devel 2009-10-07
<slangasek> tormod: is the change in 430121 still required?  upstart-job has been fixed so that 'invoke-rc.d $foo start' doesn't fail when the job is already started
<tormod> slangasek, I saw this yesterday
<slangasek> tormod: ok; well I don't think this patch is the right way to fix the problem, invoke-rc.d should *not* be failing so we should get to the root of what's causing it to fail
<wgrant> cjwatson: Adding comments is difficult, but I want to do it eventually. Versions superseded in the primary archive are in a separate table, as that's fairly useful and much much easier.
<tormod> slangasek, isn't it failing just because upstart already restarted it?
<slangasek> tormod: it shouldn't be, see my above comment
<slangasek> 'invoke-rc.d $foo start' on a service that's already started is *not* supposed to fail
<tormod> slangasek, ok I see
<wgrant> If something is on the list but now builds fine in the primary archive, I guess it's reasonable to retry it to make it disappear.
<slangasek> tormod: when you saw this yesterday, was this part of a full dist-upgrade from jaunty?
<tormod> slangasek, not from jaunty, just a week or two old karmic
<slangasek> tormod: ah, so you could indeed have already had the old upstart-job installed
<slangasek> tormod: a full apt term.log would be helpful to confirm this
<cjwatson> wgrant: yeah, I hadn't realised the latter - that does help a lot
<slangasek> tormod: if upstart was at a version lt 0.6.3-4 when acpid was being configured, that explains why you still saw the problem
<tormod> slangasek, I attached the dpkg.log
<tormod> slangasek, yes it went from 0.6.3-1 to 0.6.3-7
<slangasek> tormod: ok, great - I'll close this bug out as a duplicate, thanks
<slangasek> er, no
<slangasek> I didn't have a bug open before :-)
<chrisccoulson> seb128 - i didn't want to disturb the meeting on #ubuntu-desktop. so, our current default gconf setting for g-p-m screen locking is "/apps/gnome-power-manager/lock/use_screensaver_settings = true", which means that if a user disabled locking in the screensaver preferences, the screen will no longer lock on suspend either
<chrisccoulson> and the log attached to bug 428115 shows that is the likely reason for the issues there
<ubottu> Launchpad bug 428115 in indicator-session "Does not lock screen on lid close when using gdm autologin" [High,Fix released] https://launchpad.net/bugs/428115
<seb128> chrisccoulson, could you add a comment on the bug saying that?
<chrisccoulson> yeah, can do
<seb128> thanks
<seb128> that would make sense to explain the issue
<chrisccoulson> yeah, it should do:)
<seb128> I'm not sure if it makes sense from an user perspective
<seb128> ie if you want suspend to not lock screen because you told the screensaver to behave this way
<cjwatson> jbernard_: I'll retry cmake, hopefully that will get it off the list
<cjwatson> (as wgrant suggested)
<chrisccoulson> seb128 - yeah, that's confusing, but we can easily flip that key and have g-p-m use it's own policy
<jbernard_> cjwatson: cool, thanks
<chrisccoulson> seb128 - i had a response back already, and it is a user config issue
<chrisccoulson> but the behaviour is still confusing
<seb128> chrisccoulson, ok, good to have that sorted, you rock!
<cjwatson> wgrant: does the row shading mean anything? it doesn't seem to just alternate
<chrisccoulson> heh, thanks ;)
<wgrant> cjwatson: It does alternate. But I forgot to fix it so that it's done after the list is split.
<wgrant> cjwatson: Fixing.
<cjwatson> ah, ok
<cjwatson> thanks
<slangasek> pitti: AFAICS, devicekit-power never grew a quirks database in time for karmic; does pm-suspend just magically work on everyone's hardware now without any arguments, or are the complaints going somewhere that I'm not noticing?
<james_w> pm-utils still uses hal I thought?
<chrisccoulson> i thought it was the other way around?
<slangasek> pm-utils never used hal
<slangasek> g-p-m used hal to assemble the commandline to pass to pm-utils
<slangasek> maybe pm-utils is smart enough to do this on its own now, I dunno
<slangasek> oh, it does
<slangasek> /usr/lib/pm-utils/sleep.d/00auto-quirk
<slangasek> james_w: thanks :)
<slangasek> pitti: ^^ ignore me, james_w knows
<james_w> Halsectomy knows all
<james_w> I just happened to discover this the other day while trying to suspend with the dbus server broken in gdb and then spending ages finding out that pm-utils was hung waiting for a response from HAL
<slangasek> that means all our quirks are now properly shared across all suspend methods without having to add any code, awesome
<slangasek> james_w: haha
<gbear14275> I was wondering if someone could pass a link to me or some information about the upcoming 9.10 server edition?  I tried to download it from this link: http://uec-images.ubuntu.com/releases/9.10/  but its broken.  I found this page: http://uec-images.ubuntu.com/releases/karmic/beta/  but am not sure what version I'm looking for.  Can someone tell me about the upcoming server versions or by chance point me to the "regular" ser
<andersk> Is it known that usplash doesn't quit when fsck fails so badly that it asks you to run fsck manually?
<slangasek> andersk: bug #432237, linked from the beta overview?
<ubottu> Launchpad bug 432237 in mountall "difficult to recover from filesystem errors" [Critical,In progress] https://launchpad.net/bugs/432237
<Darxus> Is it really not possible to change a ppa name?  I have to create a new one and copy the contents?
<Darxus> Wow, three minutes after upload, my package is building.  You people must be slacking.  Last time was eight hours.
<superm1> so what is actually supposed to control whether usplash starts prior to xsplash?
<superm1> sometimes i've been seeing it and sometimes not
<slangasek> superm1: USPLASH=yes somewhere in /usr/share/initramfs-tools
<slangasek> (currently, it's on if cryptsetup is installed, and AFAIK off in all other cases)
<superm1> slangasek, hmm interesting.  i've been seeing it right after a fresh install sometimes on misc daily disks, wonder if that's a bug somewhere then.  i'll have to check again off a recent daily
 * lamont wonders how to tell gdm to _NOT_ show the pretty users-list crap.. make me type my username...
<lamont> or at the very least, don't show me all the users with locked passwords
<liw> or let me configure it to not make an awful bleeping noise when it brings up the login window...
<al-maisan> Good morning!
<jdong> can a KDE dude enlighten me on why the default KDE window decorations are so.... 1990's? :-/
<jdong> I've never been the one to nitpick UI prettiness but it seems like everyhing ELSE about KDE is remarkably shiny
<liw> hm, my karmic desktop machine has developed an annoying habit of not bringing its statically configured network interface up
<dholbach> good morning
<superm1> pitti, ping.  would you be able to help look at an apport report for a mythtv bug and help figure out why symbols aren't getting properly applied?  All of the QT debug symbols get applied perfectly, but the mythtv ones are just showing up "No symbol table info available"
<superm1> https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/445173
<ubottu> Launchpad bug 445173 in mythtv "mythfrontend.real crashed with SIGSEGV in QMutex::lock()" [Medium,New]
<pitti> Good morning
<pitti> slangasek: confirmed, pm-utils still uses the hal quirks DB; that's still on the list of getting ported (also, my favourite option is to put the quirks right into pm-utils, not into dk-power)
<pitti> superm1: yes, I can have a look into the retracer logs; I'll comment on the bug
<superm1> thanks pitti
<pitti> superm1: replied
<superm1> pitti, ah okay.  thanks.  won't need the retrace this time since upstream tracked it down already from another report, but we've been having a lot of these bug have broken lately.  how soon is the plan for proper soyuz support of ddebs then?
 * pitti eyes wgrant
<ttx> pitti: hey -- if you could trigger a server ISO respin, I would win a couple hours in my testing :)
<wgrant> superm1: I hope to have the code in LP for 3.1.10, but it will need IS work and buildd changes rolled out as well.
<wgrant> superm1: What's the problem here?
<pitti> ttx: do you want ports as well? or just amd64/i386?
<ttx> pitti: just amd64/i386.
<pitti> ttx: running; should be there in some 10 mins
 * ttx hugs pitti
<pitti> you're welcome
<superm1> wgrant, pitti said this: https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/445173/comments/5
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/445173/+text)
<wgrant> superm1: Ah, right.
<wgrant> So, it will be several weeks, but not much longer.
<superm1> okay.  well if this comes up again with some other reports before that i'll raise it with pitti
<pitti> ttx: there:
<pitti> http://cdimage.ubuntu.com/ubuntu-server/daily/20091007/
<ttx> pitti: \o/ yay, more UEC testing...
<seb128> does anybody has an idea about bug #441167?
<ubottu> Launchpad bug 441167 in gdm "package gdm 2.28.0-0ubuntu11 failed to install/upgrade: pam asked for password as it was configured with pam_mount" [Undecided,New] https://launchpad.net/bugs/441167
<seb128> there is a pam_mount password prompt during the postinst
<seb128> not sure if that's due to gdm calling su gdm to write the gconf key for the theme
<pitti> superm1: su does create a PAM session, yes
<pitti> sorry, seb128
<pitti> seb128: perhaps we should use "sudo -u gdm command" instead?
<seb128> pitti, I'm wondering if we should rather try to use a gtkrc or something
<seb128> those su calls create tons of issues
<pitti> seb128: sure, we can just ship the .gtkrc in the .deb
<seb128> gconftool call issues when there is no dbus session bus
<seb128> .gvfs permissions issues
<pitti> right, we had that (--direct, etc.)
<seb128> now password prompts
<pitti> seb128: I'm fine with a .gtkrc
<seb128> pitti, I need to test that though because gnome-settings-daemon is running and I'm not sure .gtkrc will be used or if g-s-d will overwrite things
<seb128> ie what wins between gtkrc and gconf keys applied by gsd
<pitti> seb128: wouldn't/shouldn't the file be owned by root?
<pitti> gdm shouldn't be able to change it
<seb128> what file?
<pitti> the .gtkrc one
<pitti> if it's shipped in the .deb, it's be root:root
<pitti> s/be//
<seb128> well you can change the permissions in the package if needed
<chrisccoulson> seb128 - g-s-d currently has it's own specific settings for the GDM user (but the keys are shipped by GDM, in a special location). g-s-d uses these settings in the GDM session because g-s-d is started with a --gconf-prefix option. i wonder if we could exploit this for the theme (perhaps with a small patch)
<chrisccoulson> that would avoid messing around with user gconf keys in the postinst and gtkrc's and everything
<seb128> chrisccoulson, are those settings not only gconf datas in the gdm user dir?
<chrisccoulson> seb128 - no, they're global i think. i can't check right now, but if you have a look in your user session, i think you should see /apps/gdm/simple-greeter/settings-manager-plugins, which are the GDM specific settings fro g-s-d
<chrisccoulson> if thats the case, then i can't see why we couldn't do something similar for the theme
<seb128> chrisccoulson, oh, thanks for the hint
<chrisccoulson> yeah, i just checked the package contents, and they're just installed like any other gconf schema
<seb128> excellent
<pitti> kees: gdm has a Vcs-Bzr: *cough*
<pitti> kees: (committed now)
<seb128> pitti, working on gdm changes?
<pitti> seb128: just committed kees' upload
<seb128> pitti, ok, I was not sure if you were cleaning on if you noticed because you started on other changes
<pitti> seb128: no, I just habitually check bzr if someone outside of ~ubuntu-desktop uploads a gnome package :) (I follow -changes)
<seb128> ok good :-)
<chrisccoulson> heh, yes, i've been caught by branches being out of date before ;)
<soren> X is chewing up 100% cpu on my laptop. Is there something like xrestop that can give me a hint about which X client might be keeping the X servr so busy?
<pitti> soren: I didn't find xrestop helpful for that; I just kept killing programs until I found it
<pitti> fortunately the responsible program usually also has some CPU usage
<pitti> (and most often it's firefox..)
<soren> The ubuntuone syncdaemon was also eating 100% cpu, but that wasn't the culprit. X is still at it.
<soren> ...and firefix isn't running.
<pitti> soren: so! X is desperately waiting for firefox!
<soren> Some kind of top-like application for IPC would probably help somewhat. I expect the offending process will be talking a lot to the X server.
<soren> pitti: Heh.. That would be freaky :)
<soren> Ah, right.
 * soren was just reminded how annoyed X gets if you try to strace it.
<jtimberman> i just did an apt-get upgrade on my karmic system, and now networking doesn't start up, complains that /var/run/network/ifstate doesn't exist. is this a known issue?
<Koterpillar> Where can I get the Ubuntu source for gnome-keyboard-applet? I did apt-get source gnome-applets, but I can't find it there.
<chrisccoulson> Koterpillar - libgnomekbd
<chrisccoulson> that's the source package name
<seb128> chrisccoulson, the applet is in gnome-applets no?
<chrisccoulson> i thought the applet was shipped as part of libgnomekbd
<chrisccoulson> yeah, the binary package is gkbd-applet
<Whoopie> bryce: Hi, I think your latest changes to wacom-tools were not applied as the patch is not in the series file.
<mr_pouit> pitti: Bug #445236 << Apparently this old bug (fixed in gutsy) has come back in karmic. Any idea? (something dropped in hal?)
<ubottu> Launchpad bug 445236 in thunar "thunar hangs when opening large USB vfat drives" [Undecided,New] https://launchpad.net/bugs/445236
<pitti> mr_pouit: it has never really been a hal bug; but I noticed that as well
<pitti> we worked around it in hal by supplying a magic vfat option back then
<pitti> "usefree" IIRC
<pitti> this was fixed in a later kernel, but apparently it came back
<pitti> bug 133567
<ubottu> Launchpad bug 133567 in hal "nautilus hangs on accessing vfat drives - statfs() blocks for a long time" [High,Fix released] https://launchpad.net/bugs/133567
<joaopinto> aren't debian/control files utf-8 encoded ?
<pitti> they ought to
<liw> http://www.debian.org/doc/debian-policy/ch-controlfields.html -- yes, they must be
<joaopinto> UnicodeDecodeError: 'utf8' codec can't decode bytes in position 39-41: invalid data
<joaopinto> parsing thunderbird-locale-mk 1:2.0.0.14+1-0ubuntu2
<liw> sounds like a bug, that
<joaopinto> you mean a packaging bug ?
<liw> yes
<liw> joaopinto, indeed, the thunderbird-locale-nb-no package has text in what looks like iso-8859-1 (latin1)
<liw> (isutf8 can be a handy tool for finding such, even if I say so myself)
<joaopinto> ok I will add some failsafe code to encode with replace on errors, and then file bug reports
<citrus212> hi there
<citrus212> i need help getting the 'mouse over w/thumbnails' KDE package onto gnome
<Riddell> ?
<Riddell> citrus212: it's a  feature  not a package, you would need to code the same feature in gnome or use KDE
<liw> what does this feature do?
<cjwatson> #ifdef HAVE_STRNLEN
<cjwatson> # ifndef strnlen
<cjwatson> int strnlen(const char *str, size_t size);
<cjwatson> # endif /* !strnlen */
<cjwatson> what on earth is the point of that, other than to cause build failures?
<cjwatson> (librcc)
<doko__> seb128: what are the keywords for hidden gnome/kde entries in .desktop files?
<doko__> heh
<doko__> we should collect these "best of build failures"
<chrisccoulson1> doko__ - are you referring to the "OnlyShowIn" key?
<doko__> chrisccoulson1: yes, I think that's what I do want
<doko__> chrisccoulson1: can these be enabled using the menu editor?
<chrisccoulson1> doko__ - i think they're hidden completely, so they won't show in the menu editor either
<chrisccoulson1> although i'm not 100% certain there
<soren> cjwatson: Perhaps it's meant for the case where HAVE_STRNLEN is a lie?
<soren> cjwatson: Where did you see this?
<ogra> doko__, if you just dont want to have it shown at all: Hidden=true
<cjwatson> soren: 12:58 <cjwatson> (librcc)
 * soren cleans his glasses
<cjwatson> soren: it's just wrong. configure detected strnlen (in this case). Either it's a function or a macro, so given the #ifndef, it must be a function. Either the system declaration is the same, in which case it's pointless, or it's different, in which case it will fail.
<cjwatson> asac: could you fix the test rebuild failure in http://launchpadlibrarian.net/32107043/buildlog_ubuntu-karmic-i386.mobile-broadband-provider-info_20090622-0ubuntu1_FAILEDTOBUILD.txt.gz ? I'd do it myself but it's in a bzr branch I can't commit to. I think you just need to either build-depend on automake1.10 or change debian/rules to use 1.11 (preferably the latter)
<asac> cjwatson: yes. i am updating that package today anyway to get latest data. thx!!
<hyperair> hmmm i'm missing a libglib2.0-0. amd64 must have ftbfsed eh
<cjwatson> hyperair: seems to have succeeded, maybe just a bit behind
<hyperair> ah i see
<cjwatson> finished three hours ago, though ...
<cjwatson> not in NEW
<hyperair> imo there should be some synchronization in place to ensure arches don't get left behind. leads to some annoying dependency problems
<cjwatson> doko__: what should we do about the pychecker build failure? it's full of stuff that changed in python2.6 - do we need to adjust the test suite for that, or do we need to make it only work with python up to 2.5 since it looks like nobody's really added 2.6 support yet?
<cjwatson> doko__: I can probably take care of it, but wouldn't mind some direction if you've handled this kind of thing before
<doko__> cjwatson: python2.5 only, I don't see it maintained upstream
<cjwatson> ok, so build-dep on python2.5 and make it use python2.5 for the regression test - should be straightforward
<liw> mvo, #226967: I assume that can be marked "Fix Released" now?
<kagou> can we still request a sync for a package in universe ?
<cjwatson> kagou: yes, if it meets feature freeze criteria or you get an exception
<kagou> thanks cjwatson, I'v reported #445413 (you have done the precedent sync from 0.9.8 in #384380 ). I'm looking at feature freeze criteria
<mvo> bug 226967
<mvo> bug #226967
<ubottu> Launchpad bug 226967 in update-manager "Upgrade tool fails to recover after kernel panic in mid-upgrade" [High,Fix committed] https://launchpad.net/bugs/226967
<seb128> doko__, what do you want to do? usually we use NoDisplay
<doko__> seb128: hmm, ogra mentioned Hidden=true ...
<ogra> Hidden might be old
<seb128> doko__, so you want those to be listed in the menu editor or not?
<ogra> my knowledge in that area is a bit rusty
<doko__> seb128: yes, the user should be able to show it again
<seb128> Hidden=true will make those not considered for mimetypes associations etc too
<seb128> doko__, so NoDisplay is what you want
<doko__> seb128: ok thanks
<doko__> everything not using the command line is scary, maybe except OOo ,p
<ogra> haha
<mvo> cjwatson: does https://bugs.edge.launchpad.net/ubuntu/+bug/442262/comments/7 looks like a bug in debconf to you? or something in the integration in aptdaemon?
 * liw is scared by OOo
<ubottu> Launchpad bug 442262 in software-center "Software Center always fails to install packages" [Undecided,Incomplete]
<tkamppeter> pitti, hi
<cjwatson> mvo: would it be possible to get 'DEBCONF_DEBUG=.' output? it looks as though debconf got an error when trying to read from the other end of the passthrough fd
<cjwatson> mvo: it's a bug that it carries on and spews warnings, but fixing that would just tidy up the output, not actually fix it
<mvo> cjwatson: thanks, I have not yet managed to reproduce it, I will try that and add the output
<cjwatson> lines 65-66 are:
<cjwatson>         $reply = <$readfh>;
<cjwatson>         chomp($reply);
<cjwatson> and undef from <> means error or EOF
<pitti> hey tkamppeter
<tkamppeter> á¹itti, in bug 441897 it looks like that during the update of the CUPS package (Jaunty -> Karmic or within Karmic) the cupsd.conf file got empty.
<ubottu> Launchpad bug 441897 in cups "Brother printer MFC-230 C not detected with drivers installed in Karmic, worked in Jaunty" [Undecided,Incomplete] https://launchpad.net/bugs/441897
<tkamppeter> pitti, AFAIR there are also other reports about this problem.
<spaetz> pitti: thanks for driving bug 430694 forward. It was giving me a hell of a time :-
<ubottu> Launchpad bug 430694 in linux "agpgart-intel not loaded before drm sometimes, causes KMS to fail" [Medium,Confirmed] https://launchpad.net/bugs/430694
<spaetz> :-)
<pitti> spaetz: wasn't me really
<spaetz> no, but you are nagging Tim Gardner :)
<pitti> tkamppeter: ugh, that sounds serious; could it be a fallout from the "cleans /tmp/ on upgrade" bug that was fixed yesterday?
<spaetz> And I am just happy that the bug is being taken care of
<tkamppeter> pitti, I have already heard about wiped cupsd.conf before yesterday.
<tkamppeter> pitti, where got a '"cleans /tmp/ on upgrade" bug' get fixed yesterday?
<bfox> cjwatson: ping?
<cjwatson> bfox: hello?
<cjwatson> bfox: if it's about what I think it's about, haven't had a chance to look yet ...
<bfox> cjwatson: okay, thanks
<pitti> tkamppeter: bug 444545
<bfox> cjwatson: I know you're busy  ;)
<ubottu> Launchpad bug 444545 in evolution "package evolution 2.28.0-0ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (dup-of: 444252)" [Low,Invalid] https://launchpad.net/bugs/444545
<ubottu> Launchpad bug 444252 in dmraid "tmp cleaned during upgrades and breaking installations?" [Critical,Fix released] https://launchpad.net/bugs/444252
<pitti> tkamppeter: but that could only be relevant if cups tried to do stuff in /tmp/ and died in the middle of rewriting cupsd.conf
<pedro_> does anybody know if the ubuntu wiki is on some kind of read only mode? I'm trying to create a page and i'm getting a nice error
<tkamppeter> pitti, does any "udevadm trigger ..." call wipe /tmp? And why should this affect /etc/cups/cupsd.conf?
<pitti> tkamppeter: any udevadm trigger which triggers block devices
<pitti> tkamppeter: there are only two reasonable ways it could get empty: (1) either you have an unmodified conffile and dpkg dies in the middle of unpacking a new version
<pitti> or (2) cups rewrites it on a cupsctl change and dies in the middle of it
<pitti> (1) is unlikely, given that the reporters actually use it, and cups just can't keep its bloody fingers from that conffile
<pitti> and dpkg is pretty robust agianst that, too
<liw> doesn't dpkg always write first to a new file, then move that over the original?
<pitti> (2) could happen with anything; but if it coiincides with the time when we had that /tmp bug, it might be related
<liw> (any program -- except database engines -- updating an important file in-place is probably buggy)
<liw> is gutsy still supported?
<Pici> No.
<Pici> !gutsy
<ubottu> Ubuntu 7.10 (Gutsy Gibbon) was the seventh release of Ubuntu. End Of Life: April 18th, 2009. See !eol and !upgrade for more details.
<liw> !dapper
<ubottu> Ubuntu 6.06 LTS (Dapper Drake) was the fourth release of Ubuntu. Desktop support ended on July 14th 2009, Server support will end in June 2011. See !upgrade for upgrade instructions
<liw> any Spanish speakers who could look at bug #444979 (filed against update-manager)? looks like lirc and ntfs-3g failed to upgrade for some reason
<ubottu> Launchpad bug 444979 in update-manager "crash a program" [Undecided,New] https://launchpad.net/bugs/444979
<beuno> liw, looking
<kirkland> ttx: yo
<ttx> kirkland: hey
 * mvo hugs liw for doing u-m triage
<beuno> liw, he says "no idea, the error got triggered in fusa, lirc, and other dependencies"
<liw> mvo, I don't like doing it, though... I was down to 775 open bugs and then something brought it back up to 775 :(
<pitti> 775 - 775 == 0, hmm
<liw> er, 776 for the second instance
<mvo> liw: its no fun, I do not enjoy it either
<mvo> hard work
<liw> mvo, yeah
<LaserJock> mdz: do you want me to edit the release manifest wiki page or just reply to the email you sent?
<mdz> LaserJock, both please
<ttx> kirkland: I've committed a few fixorz that should make autoregistration more consistent
<kirkland> ttx: cool
<kirkland> ttx: uploaded?
<kirkland> ttx: i uploaded your fixes from yesterday?
<ttx> kirkland: no, I want to test it more
<ttx> kirkland: yes, btw, don't forget to debcommit --release when you do so
<ttx> kirkland: your final changelog for ubuntu2 wasn't in the branch
<ttx> kirkland: I committed it.
<ttx> kirkland: I cherrypicked the Heartbeat fix
<kirkland> ttx: okay, what about kees' euca_rootwrap?
<ttx> kirkland: looks like it's working, but i want to do the full test run
<ttx> kirkland: didn't test it
<kirkland> ttx: i think we're going to need to pull that in too
 * liw wishes for a feature in LP that would uncompress files (so it would be easier to look at log files, without having to download + uncompress locally)
<ttx> kirkland: I'm tseting a little more and will give you the go-ahead to release my changes, together with whatever you want from your day
<LaserJock> mdz: the sign off is for the just the announcement or on the whole release (.iso, etc.)?
<kirkland> ttx: cool, thanks for doing that
<kirkland> ttx: we'll pull the euca_rootwrap fixes too
<ttx> kirkland: I didn't work on "wtf after the reboot" style bugs
<kirkland> ttx: test that, and upload (hopefully)
<mdz> LaserJock, the whole thing
<ttx> I think you need to debug those with Dan
<mdz> LaserJock, who can say "yes, it's ready"
<LaserJock> mdz: ok
<kirkland> ttx: please assign to me any bugs you want me to work on with dan
<ttx> I think they are already assigned to you..; let me check
<ttx> hmm, why does the wiki hate me
<ttx> "[Errno 31] Too many links: '/srv/wiki.ubuntu.com/www/data/pages/MeetingLogs(2f)Server(2f)20091006'"
<elmo> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<elmo> god damn it moin
<ttx> elmo: :)
<robbiew> lmao
<LaserJock> mdz: done, thanks for bringing that up
<LaserJock> mvo: does software-center use the app-install-data data?
<mvo> LaserJock: yes
<joaopinto> already saw 2 reports about mysql server upgrade failing, anyone knows a bug about it ?
<joaopinto> ops, ignore me :P
<Riddell> cjwatson: does reorg just affect packages in main?  universe  stays much the same?
<cjwatson> no
<cjwatson> it's entirely possible (and may be useful) for a package set to contain stuff in universe
<cjwatson> probably best to read the spec for details
<cjwatson> seb128: are we planning to pull in mm-common from Debian? gtkmm-documentation from git seems to require it
<seb128> cjwatson, I don't know about this one but I will have a look, I would say that we should from a quick look right now
<seb128> what do you think?
<cjwatson> I think it may only be necessary for building from git, not quite certain
<cjwatson> maybe we should sync it and stick it in universe, if that's accurate
<lamont> if some enterprising soul could go stomp on bug 445530, my life would be much better.
<lamont> since (nearly?) EVERY package using python-support is FTBFS in rebuildability testing
<ubottu> Launchpad bug 445530 in python-support "dh_pysupport -a fails in private/movemodules with python2.6" [Undecided,New] https://launchpad.net/bugs/445530
<cjwatson> (I'm just looking at gtkmm-documentation's build failure, and trying to reproduce with git so that I can file an upstream bug ...)
<blackxored> enrico, ping
<jjardon> hello, I can't install epiphany-browser (It's not in the archive), is this intentional?
<jtimberman> i just did an apt-get upgrade on my karmic system, and now networking doesn't start up, complains that /var/run/network/ifstate doesn't exist. is this a known issue?
<ScottK> jjardon: It is, but it's in Universe in karmic.
<jjardon> ScottK, ah, ok. The problem is I can't install epiphany-webkit neither
<ScottK> Well my advice would be install KDE, so I'm probably not the best one to help you.  Help with Karmic is in #ubuntu+1.
<jjardon> ScottK, Maybe I'm wrong but I think that epiphany-browser is not in universe
<ScottK> I see there is source, but now binaries, so I'm not sure what's up with that
<blackxored> ScottK, it's not on karmic/universe version 2.28.0-4?
<ttx> kirkland: proposed 0ubuntu3 so far is working alright for me
<blackxored> ScottK, the source only ?
<kirkland> ttx: good
<ScottK> What I see in rmadison is epiphany-browser |   2.28.0-4 | karmic/universe | source
<ScottK> Perhaps the binary package name changed.
<blackxored> ScottK, yes that's what I see, odd :(
<james_w> ftbfs?
<blackxored> probably
<ScottK> No idea.
<LaserJock> slangasek: what was the issue with libgd2-xpm causing a conflict between ubuntu-desktop and edubuntu-server?
<LaserJock> slangasek: is that something that Edubuntu can fix?
<james_w> blackxored: https://edge.launchpad.net/ubuntu/+source/epiphany-browser/2.28.0-4ubuntu1
<sebner> ScottK: blackxored : In NEW is -4ubuntu1 fixing a FTBFS so this might be the issue
<blackxored> sebner, james_w thanks but point to jjardon ;)
<ScottK> OK, well we've pretty well exhausted my interest in the Gnome web browser.
<lamont> 2 bugs filed, 49 to go
<jjardon> thank you all :)
<james_w> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<james_w> really annoying
<mvo> if someone uses a rtl language I would appreciate feedback if the latest software-center works with that as expected (it should :)
<jtimberman> is this not the place to ask about bugs in karmic?
<Pici> jtimberman: Please use #ubuntu+1 for karmic support and discussion
<ogra> ok, thats totally not funny ... if your system clock is at 1970 but your disk was mounted with proper clock setting your system goes into constant reboots
<ogra> /dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
<ogra> /dev/sda1: ***** REBOOT LINUX *****
<ogra> /dev/sda1: 138868/469568 files (0.1% non-contiguous), 590241/1875580 blocks
<ogra> mountall: fsck / [575] terminated with status 3
<ogra> mountall: System must be rebooted: /
<ogra> init: mountall main process (341) terminated with status 4
<ogra> rm: cannot remove `/forcefsck': Read-only file system
<ogra> init: mountall post-stop process (648) terminated with status 1
<ogra> [42949430.100000] Restarting system.
<ogra> where is keybuk when i need him :(
<ogra> that looks serious
<ogra> hmm, great after the 100th reboot it trashed the rootfs completely and cant mount it anymore
<ttx> kirkland: just add anything you want (reasonably tested) to it, upload, and /quit plop
<ttx> arrh
<ttx> make that just /quit plop
<james_w> http://launchpadlibrarian.net/31896337/buildlog_ubuntu-karmic-i386.k3b-i18n_1.0.5-1ubuntu1_FAILEDTOBUILD.txt.gz
<james_w> is --without-arts the right thing to do now that we have dropped it?
<sistpoty|work> james_w: I assume it is (though I'm by far no kde expert, maybe #kubuntu-devel might give better information ;))
<Riddell> james_w: hum, that doesn't match the k3b version we're using
<Riddell> james_w: mm, that should probably be removed from the archive
<james_w> even easier then
 * cjwatson removes linux-ports from the archive. die
<mathiaz> slangasek: could you have a look at bug 445453?
<ubottu> Launchpad bug 445453 in drbd8 "[FFE]: Please sync drbd8 2:8.3.3-0ubuntu1 (main) from PPA" [Undecided,New] https://launchpad.net/bugs/445453
<cjwatson> lamont: oddly, 'from hashlib import md5' works here
<cjwatson> lamont: I suspect it needs libssl0.9.8
 * cjwatson does a minimal bootstrap to check
<lamont> cjwatson: you can even do variant=buildd :-p
<lamont> http://paste.ubuntu.com/287931/ <-- cjwatson: wb --list order (ish), and not pysupport or arch-not-in-list, so far
<lamont> if you see any in the list after quilt that especially interest you, holler
<cjwatson> I think the problem is that /usr/lib/python2.6/lib-dynload/_hashlib.so is in python2.6 rather than python2.6-minimal
<cjwatson> doko__: ^- do you agree?
<cjwatson> lamont: I know I just fixed a few of those. Interested in gfxboot-theme-ubuntu
<doko__> cjwatson: I'll have a look later, does this have time until tonight?
<cjwatson> doko__: no rush!
<doko__> cjwatson: would a dependency on libopenssl in -minimal be ok?
<cjwatson> doko__: it's already priority: important - it would just mean it'd have to move to priority: required
<lamont> cjwatson: build-depends: cpio, not declared
<cjwatson> lamont: ah, ok
<lamont> cjwatson: was old chroot tarball cruft
<cjwatson> lamont: can fix that easily
<doko__> cjwatson: which report/package is this?
<cjwatson> doko__: bug 445530
<ubottu> Launchpad bug 445530 in python-support "dh_pysupport -a fails in private/movemodules with python2.6" [Undecided,New] https://launchpad.net/bugs/445530
<cjwatson> that's odd though, python-support Depends: python
<lamont> cjwatson: if your doing that, the other cpio winner is qt-x11-free
<cjwatson> lamont: is python2.6 installed at the point when python-support breaks?
<cjwatson> lamont: same question for libssl0.9.8
<lamont> libfile-find-rule-perl-perl <-- stutter
<lamont> checking
<james_w> if I /proc/<pid>/fd/<n> is a socket
<james_w> how do I find out what other tasks are attached to the socket?
<elmo> lsof or netstat
<cjwatson> lamont: fixed gfxboot-theme-ubuntu. In the last few days I've fixed at least gettext, icu, libiodbc2, pychecker, netpbm-free, elilo, grub, kexec-tools, and smartmontools, and removed linux-ports - so you can skip all those
<lamont> ta
<lamont> python2.6-minimal is build-essential, python2.6 is not
<cjwatson> indeed, but python-support depends: python depends: python2.6
<cjwatson> so it's weird that it wouldn't be installed
<cjwatson> I still think it's probably wrong for python2.6-minimal to ship a .py without the matching .so, but this seems independent
<pmatulis> what's the password for user 'ubuntu' in a jaunty live session?
<cjwatson> pmatulis: none
<pmatulis> the shadow file shows an encrypted one and i want to ssh into the session
<cjwatson> as in, blank
 * doko__ is away for 3h ...
<cjwatson> it's an encrypted blank password. You may have to reconfigure sshd to allow that
<pmatulis> ahh
<cjwatson> PermitEmptyPasswords yes
<pmatulis> cjwatson: thank you
<jdstrand> kees: were you involved in the gcc update on hardy?
<smoser> cjwatson, i'm looking at bug 444598. mdz suggested consulting you.
<ubottu> Launchpad bug 444598 in vm-builder "rename uec kernel/ramdisk for automated downloading or easier doc" [Low,Confirmed] https://launchpad.net/bugs/444598
<jdstrand> kees: I ask cause I'm having problems building icu on amd64, and think it is because I cannot install gcc-multilib
<LaserJock> cjwatson: am I correct to assume that Edubuntu's supported seed only needs to list packages that are not already in the Ubuntu supported seed?
<jdstrand> kees: gcc-4.2-multilib: Depends: lib32gcc1 (>= 1:4.2.4-1ubuntu3) but 1:4.2.3-2ubuntu7 is to be installed
<cjwatson> smoser: reasonable, but I'm about to finish up for the day - do you think you could mail me?
<lamont> cjwatson: btw... I filed bugs for everything thru quilt on that list, so... fix-released status for a number of bugs would be appropriate
<smoser> sure.
<lamont> if you don't kill them first, I'll go back after I get done with this round of bugfiling
<cjwatson> LaserJock: there's very little actually in the Ubuntu supported seed directly ...
<mdz> smoser, I suggested you ask him about matching source for the binaries; not sure if that's the same bug or not
<smoser> you're right, mdz, it is different bug.
<kees> jdstrand: I did touch gcc in hardy, yes
<kees> jdstrand: checking...
<jdstrand> kees: actually, it may be a problem with my mirror
<jdstrand> gcc-4.2 | 4.2.4-1ubuntu3 | http://debmirror hardy-security/main Sources
<jdstrand> (that is good)
<kees> jdstrand: oh, er.
<jdstrand>   Version table:
<jdstrand>      1:4.2.3-2ubuntu7 0
<jdstrand>         500 http://192.168.2.2 hardy/main Packages
<jdstrand> kees: let me look into it more before you waste time on it. sorry for the noise
<kees> jdstrand: yeah, it _should_ be ok:    gcc-4.2 | 4.2.4-1ubuntu3 | file: hardy-security/main Packages
<kees> jdstrand: anyway, let me know if you don't resolve it and I can dig more.
<slangasek> LaserJock: moodle->php5-gd->libgd2-xpm; it's not something Edubuntu can fix
<mathiaz> cjwatson: hi!
<jdstrand> kees: universe/g/gcc-4.2/lib32gcc1_4.2.4-1ubuntu3_amd64.deb
<mathiaz> cjwatson: I've just done a ./edit_acl.py -P karmic-ubuntu-server query from the ubuntu-archive-tools bzr branch
<jdstrand> kees: for some reason the binary is in universe here. I'll look into it and get it fixed up
<kees> jdstrand: oh, did lib32gcc1 fall out of main?
<mathiaz> cjwatson: and it seems that there are some missing things related to server in there (like mysql-dfsg-5.1 and openldap)
<jdstrand> kees: it looks like it
<kees> jdstrand: that's odd.  I didn't have anything to do with that!  :)
<jdstrand> kees: no, you wouldn't :)
<jdstrand> kees: again, thanks and sorry for the noise
<mathiaz> cjwatson: is this on purpose or the package set is not up-to-date yet?
<kees> jdstrand: np
<cjwatson> mathiaz: a lot of source packages that ship core libraries are necessarily in core, not ubuntu-server
<cjwatson> mathiaz: although the package sets are indeed a bit out of date at the moment; I have a terminal session over there -> in the process of fixing it up
<kirkland> cjwatson: we're hitting a weird avahi issue with our current eucalyptus testing
<kirkland> cjwatson: possibly a regression, possibly just something randomly wrong this time
<kirkland> cjwatson: pinging cluster.local, resolving over avahi is resolving to two different addresses, from different machines
<kirkland> cjwatson: 169.254.169.254 in the "broken" case
<kirkland> cjwatson: 10.1.1.131 in the "working" case
<kirkland> cjwatson: this is making the retrieval of the node-preseed fail
<kirkland> cjwatson: as the installer cannot wget from 169.254.169.254
<kees> kirkland: 169.254... is a link-local address.
<kirkland> cjwatson: actually, from the same host, pinging cluster.local is sometimes resolving to 169.254.169.254 and sometimes to 10.1.1.131
<kees> kirkland: in theory, the 10.1.1.131 machine should have the link-local until it gets the 10.x address?
<kees> (both should reach the machine?)
<cjwatson> kirkland: I don't know exactly how avahi orders its resolution; in theory you should get all the possible names, but when I tried the obvious fix to euca_find_cluster to try to prefer some over others, I was only seeing one
<ScottK> cjwatson: Your gettext merge from yesterday now causes cvs to be installed with lintian due to lintian depends gettext and gettext recommends cvs  (see gettext (0.17-7)).  Would you mind if I moved that back to suggests?
<cjwatson> kirkland: it has a debugging environment variable, you can see what it says I guess
<cjwatson> ScottK: yes, I would
<cjwatson> ScottK: I'd prefer we just left it there and sucked it up
<cjwatson> I don't want people getting confused because it's a recommendation in Debian and a suggests in Ubuntu ...
<ScottK> cjwatson: OK.  It seems a bit much to me that every Lintian user now gets cvs,....
<cjwatson> maybe one of these days gettext will stop shipping an embedded cvs repository
<cjwatson> but until then I do feel that it's kind of bad form to ship gettext in a state where it doesn't work for building packages that use it (indeed, there's a bug asking for it to be moved from suggests to depends ...)
<cjwatson> this isn't a veto or anything, but you asked :)
<ScottK> Well it's not the kind of thing I'm going to ignore your opinion on.
<slangasek> oh, is that why cvs is on my system now <purge>
<ScottK> Yep
<cjwatson> I agree the indirect dep from lintian is annoying
<lamont> gettext is annoying
<cjwatson> the alternatives are worse
<ScottK> Given what you've said, I can see this is the least bad approach available.
<cjwatson> I wonder what it'd take to turn that CVS repository into something else upstream
<MacSlow> bryce, greetings
<MacSlow> bryce, where's the Xorg/Mesa/drivers edgers PPA again?
<bryce> MacSlow, xorg-edgers is at https://edge.launchpad.net/~xorg-edgers/+archive/ppa
<MacSlow> bryce, thanks!
<bryce> MacSlow, however note that it's already beyond mesa-7.6.  I'm working on pulling in the debian package of that release; should be up in a ppa before long
<MacSlow> bryce, it's about trying to narrow down a bug in intel's (i965) GLSL compiler in their driver
<bryce> MacSlow, ah gotcha; yeah for that you'll probably want to use xorg-edgers.
<lamont> seb128: so how do I teach firefox that when I minimize it, or start it and move the mouse out of it while it's thinking about rendering a page, that I DON'T WANT IT TO STEAL FOCUS WHEN IT FINISHES RENDERING (AND IT UNMINIMIZES TOO)
<lamont> just curious
<seb128> dunno, I don't work firefox nor wms, try asking asac or mvo about those ;-)
<lamont> (that's with metacity)
<lamont> heh. ok
<ogra> you start it with --dont-steal-my-focus-you-damned-bastard
<lamont> ogra: if only firefox really had such an option
<ion> bryce: Does the edgers repo have KMS support for ATI?
<ogra> heh
<lamont> seb128: it's on my screen, it must be yours. :-D
<bryce> ion, in fact Karmic has KMS support, you just need to boot with the radeon.modeset=1 kernel parameter
<ion> bryce: Ooh! Nice.
<bryce> it's still a bit buggy though; xorg-edgers may be less buggy
<alex-weeej> is apt daemon staying?
<seb128> staying where? for karmic? yes
<alex-weeej> that's cool
<alex-weeej> does it support the same interfaces as packagekit?
<alex-weeej> for application integration
<alex-weeej> such as "halp i need plugins"
<seb128> alex-weeej, you want to talk to mvo or glatzor about that
<alex-weeej> ok
<alex-weeej> also one more quick one
<alex-weeej> my MacBook Pro 5.4 from a few months ago has an NVidia HDA sound card that isn't supported by Karmic's kernel.
<alex-weeej> but it is in the upstream alsa driver
<alex-weeej> is it too late to support this hardware by backporting the driver?
<alex-weeej> actually it's the snd-hda-intel driver, so i guess there could be regressions :/
<ion> bryce: Is radeon.modeset=1 supported with 2.6.31-12-generic-pae?
<ion> bryce: It says it's unknown boot option.
<bryce> ion, supported with the current Karmic kernel.  If you're using some other random kernel YMMV
<ion> bryce: My bad; the kernel says that but the driver still seems to respect that value. The real error is later in dmesg; it says "[drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL", "radeon 0000:01:05.0: PCI INT A disabled", "radeon: probe of 0000:01:05.0 failed with error -22". The GPU's RS780M/RS780MN [Radeon HD 3200 Graphics].
<ion> bryce: It's the current karmic kernel; the generic-pae variant.
<bryce> ion, I'm really tied up doing a mesa merge at the moment, but if you can reproduce the problem with the stock (non-pae) kernel, do file a bug about it and I'll investigate when I have some time
<ion> bryce: Alright, i'll test with -generic.
<bryce> ion, we have found other random little bugs with -ati kms in testing, which is why we've not yet switched kms on by default yet.  What you've found might just be yet another one of those bugs.
<kirkland> cjwatson: okay, so we're looking for alternative approaches to solving this now...
<kirkland> cjwatson: in eucalyptus-cc.eucalyptus-cc-publication.upstart, I see
<kirkland> exec avahi-publish -s $(hostname) _eucalyptus._tcp $CC_PORT txtvers=1 protovers=1.5.0 type=cluster
<kirkland> cjwatson: the $(hostname) is being used for the "name" parameter of avahi-publish
<kirkland> cjwatson: i don't see where that field is actually being used anywhere
<kirkland> cjwatson: we're thinking about overloading that field with $CC_IP_ADDR
<kirkland> cjwatson: and modifying euca_find_cluster to use that input as the cluster's ip addr
<kirkland> cjwatson: do you have any objections to this?
<cjwatson> kirkland: none, if it works
<kirkland> cjwatson: cool, thanks
<cody-somerville> Can an arch all package specify architecture restricted relationship?
<cody-somerville> *relationships
<slangasek> cody-somerville: no
<slangasek> arch-restricted relationships are parsed by dpkg-gencontrol (so don't end up in the binary package control file), not by apt/dpkg
<LaserJoc1> cjwatson: why did adding ship-addon to dvd fix bug #439383 ?
<ubottu> Launchpad bug 439383 in edubuntu-meta "edubuntu dvd 20090929.2 cli install failed with lvm+crypt setup" [Undecided,Fix released] https://launchpad.net/bugs/439383
<LaserJoc1> cjwatson: couldn't we just use ship from ubuntu.karmic?
<ion> bryce: Reported http://launchpad.net/bugs/445717
<ubottu> Launchpad bug 445717 in linux "radeon.modeset=1 fails" [Undecided,New]
<mathiaz> slangasek: could you have a look at the smart upload to jaunty-proposed?
<mathiaz> slangasek: it blocks landscape-common that was accepted in jaunty-proposed
<slangasek> mathiaz: there seems to be a lot of state related to that SRU that I would have to get up to speed on; would it be reasonable to wait for pitti?
<mathiaz> free: what's the bug number that prevents landscape-common to be upgraded?
<mathiaz> slangasek: smart not being accepted in jaunty-proposed holds back landscape-common
<free> mathiaz: hhm I don't understand this
<slangasek> mathiaz: well, sure, but it's -proposed? :)
<free> mathiaz: bug 444743 ?
<ubottu> Launchpad bug 444743 in landscape-client "landscape-common cannot upgrade; unmet dependancies" [Undecided,Confirmed] https://launchpad.net/bugs/444743
<free> mathiaz: or #347983
<mathiaz> slangasek: ok - if that's fine by you, we can wait for pitti
<slangasek> mathiaz: I'm not bothered by temporarily uninstallable packages in -proposed; but if you tell me you guys need to get this fixed today to be able to test it, that's another matter
<mathiaz> free: ^^?
<mathiaz> free: I think we can wait until tomorrow
<free> yes sure
<mathiaz> free: make sure that all relevant bugs related to smart have been documented correclty acccording to the SRU policy
<free> mathiaz: it's just that somebody opened the bug, and I wanted to make sure there wasn's some other problem
<mathiaz> free: and then ask pitti to process the jaunty-proposed smart update
<free> mathiaz: that has been done
<mathiaz> free: If I have time today I'll try to upload the intrepid smart SRU as well
<free> mathiaz: sweet! thanks
<debfx> slangasek: could you have a look at https://code.launchpad.net/~debfx/acpi-support/fix-lp387750/+merge/12466 - it adds kde4's powerdevil to the list of power managers
<sbeattie> speaking of, do we have the ability to test the landscape-common SRU when it becomes available?
<free> mathiaz: (that will need another landscape-client upload for intrepid-prosed as well, see bug 347983 and lp:~free.ekanayaka/landscape-client/intrepid.fix-347983)
<ubottu> Launchpad bug 347983 in smart "update intrepid and jaunty to landscape-client 1.3.2.3" [Medium,Fix committed] https://launchpad.net/bugs/347983
<mathiaz> free: ok
<free> sbeattie: how you mean?
<sbeattie> free: just trying to figure out the who and the how of verifying all the fixes.
<free> sbeattie: well, you'll need a Landscape account, and to go through each bug
<free> sbeattie: they've been QA-ed already thought, see https://wiki.ubuntu.com/LandscapeUpdates
<free> s/thought/though/
<kirkland> cjwatson: i'm confused as to when does debian/local/euca_find_cluster.c get built?
<kirkland> cjwatson: i didn't see it build with bzr builddeb
<kirkland> cjwatson: hmm, okay, it's part of the udeb build
<slangasek> debfx: fwiw, that commandline scares me :)
<slangasek> debfx: I did look at it before, but the commandline made me postpone it
<slangasek> debfx: one improvement I see is that you should be able to avoid the export by stringing the commands together in a slightly different manner
<mdz> say, isn't rhythmbox supposed to be able to extract and encode CDs these days?
<seb128> mdz, what gstreamer-plugins-base0.10 do you have?
<seb128> mdz, libgstreamer-plugins-base0.10-0
<mdz> ii  gstreamer0.10-plugins-base                 0.10.24.3-1ubuntu1                         GStreamer plugins from the "base" set
<seb128> mdz, ok, update, it has been fixed in karmic today
<mdz> seb128, oh, thanks
<mdz> seb128, shouldn't you be in bed soon? ;-)
<mdz> I upgraded just a few hours ago, I guess I must have just missed it
<debfx> slangasek: I just noticed it doesn't work when there are multiple kded4 running
<slangasek> debfx: that was going to be my next question :)
<seb128> mdz, give us another slot to hire an extra desktop team GNOME maintainer and I will go to bed earlier ;-)
<debfx> slangasek: is there an easy way to get the uid/username of a process?
<seb128> mdz, joke aside I'm still looking at a gconf issue but will try to stop not to late ;-)
<slangasek> debfx: ps -o user= <pid>
<debfx> slangasek: wouldn't it be sufficient to add kde4d to the pidof list, can't imagine anyone wants acpi-support power managment when he's running kde
<slangasek> debfx: that would be inconsistent with how we handle the other desktops, though
<directhex> oh, are the colours all wrong for fullscreen video via the moz totem plugin for anyone else?
<mok0> debfx: of course, if can become superuser, you can go to /proc/<pid> and get ALL kinds of nice info about the process
<mdz> seb128, you already got one, and he should be awake soon :-)
<seb128> mdz, right, I'm waiting for him, with 3 of us we could do 8 hours shifts ;-)
<smoser> slangasek, ping
<smoser> when i use the 'checksum-directory', it will overwrite MD5SUMS, right?
<slangasek> smoser: yes
<smoser> asking because i'd like to have MD5SUM of uncompressed and compressed image
<slangasek> smoser: why?
<slangasek> we only ship a compressed image
<smoser> and only compressed is around when it runs.
<slangasek> having a checksum of the uncompressed image provides only minimal security
<smoser> no terribly good reason
<smoser> other than it takes on the order of 10 minutes to uncompress that image
<mdz> kirkland, FYI I did a cloud install with 20091007.1 and auto-registration appears to have worked perfectly
<slangasek> (in fact, since you're only shipping unsigned md5sums, I would argue it provides *no* security :)
<slangasek> smoser: I think we should only provide one md5sum per file in the index, and drop the md5sum for the uncompressed images
<smoser> slangasek, that will be fixed. i guess i dont have a terribly good argument. i'm not so much interested in security here only in convienence of having the uncompressed md5sum around.
<smoser> once you've uncompressed it, theres kind of no going back to get the original that you could have verified
<smoser> (where "original" = "compressed")
<smoser> and i've been in that situation before, trying to identify this 10G binary and decide if I have to pull the 500M again.
<smoser> so, thats the best i can do.
<smoser> i'll change scripts to use checksum-directory today
<slangasek> ah, I see
<slangasek> I would've assumed that you keep the compressed image around next to it
<smoser> yes. that would make sense :)
<smoser> but 'gunzip' and its gone.
<slangasek> right, taking with it your target for rsync :)
<slangasek> if you feel strongly about it, we can patch checksum-directory to recognize that .gz images should also be uncompressed and checksummed, but I think that's just going to slow down publishing inconveniently
<mdz> seb128, hmm, even after upgrading, I'm having some problems with CD extraction
<mdz> rhythmbox doesn't seem to even see the CD
<mdz> sound-juicer only sees the internal drive, not the external one (only one option in the drop-down)
<mdz> if I rename sr1 to sr0 (!), sound-juicer works, but still not rhythmbox
<seb128> mdz, is the cdrom listed in gvfs-mount -li or the computer location?
<smoser> for now i do not feel strongly enough.
<mdz> seb128, gvfs-mount -li shows only /dev/sr0
<mdz> (which is now the external drive)
<seb128> mdz, is the other drive listed in devkit-disks --dump or not?
<mdz> seb128, devkit-disks --dump shows both
<seb128> mdz, ok, can you open a gvfs bug with the devkit-disks --dump and gvfs-mount -li logs?
<mdz> also ejecting in sound-juicer didn't work, but eject(1) did
<mdz> seb128, certainly
<seb128> mdz, thanks
<mdz> seb128, there don't seem to be any apport hooks for the gvfs packages; would you accept a patch which attached devkit-disks --dump and gvfs-mount -li to gvfs bugs by default?
<seb128> mdz, yes, looks a good idea, in fact pitti has an interactive hook for devices detections issue he wrote during distro sprints
<seb128> the gvfs could probably be based on that
<seb128> maybe check with him before writing one
<mdz> pitti, ^^ when you're around next
<seb128> mdz, ubuntu-bug storage
<seb128> in fact
<seb128> apport-symptoms: /usr/share/apport/symptoms/storage.py
<mdz> seb128, bug 445787 FTR
<ubottu> Launchpad bug 445787 in gvfs "USB DVD writer is not visible to gvfs" [Undecided,New] https://launchpad.net/bugs/445787
<seb128> mdz, thanks
<seb128> mdz, the interactive hook seems rather made to direct the bug at the right place, getting logs would probably be easy though if you want to send a patch for that ;-)
<seb128> mdz, do you have disks in those drives?
<mdz> seb128, right, it picks the package, then will run whatever hooks the package provides
<debfx> slangasek: http://paste.ubuntu.com/288100/ should work
<mdz> seb128, I had ejected it when I ran the commands; should I get the output with media inserted as well?
<seb128> mdz, "  has media:                   0" for both sr0 and sr1
<seb128> mdz, that would be nice yes, at least in the one you want to use
<mdz> seb128,   has media:                   1 (detected at Wed 07 Oct 2009 09:44:15 PM BST)
<mdz> seb128, attached to the bug as well
<seb128> mdz, and it's still not in gvfs-mount -li or in the computer location?
<mdz> seb128, correct
<mdz> computer:/// only shows one CD/DVD reader and it is the internal (empty) one
<cjwatson> LaserJoc1: ship-addon looked more appropriate to me (normally dvd is a superset of nearly everything else), but I'm sure ship would work too
<cjwatson> LaserJoc1: it just needs to (transitively) include d-i-requirements
<debfx> slangasek: updated the merge request
<LaserJoc1> cjwatson: ok, I just was trying to avoid using addon stuff for the DVD
<mdz> cjwatson, I have a ubiquity install which is hung at "Configuring apt"
<cjwatson> LaserJoc1: I remember not being sure
<cjwatson> mdz: evand fixed that a few hours ago, I'm about to upload
<mdz> cjwatson, ok, thanks
<cjwatson> mdz: bug 445385
<ubottu> Launchpad bug 445385 in ubiquity "Installer hangs at 80% on "Configuring apt"" [Critical,Confirmed] https://launchpad.net/bugs/445385
<seb128> mdz, do you have a sr1 entry in fstab?
<mdz> seb128, perseus:[~/Music] grep sr /etc/fstab
<mdz> zsh: exit 1     grep sr /etc/fstab
<seb128> mdz, hum ok, I don't know offhand then, I will look at the code tomorrow and ping you back
<seb128> or rather comment on the bug
<mdz> seb128, sure, thanks
<LaserJoc1> cjwatson: the seed soup is a bit hard to untangle this far up :-)
<cjwatson> if you have to untangle your soup, you're Doing It Wrong
<LaserJoc1> cjwatson: I'm trying to figure out how to get everything on the DVD, but only what we need
<LaserJoc1> cjwatson: we jumped from a 300 MB addon to a 3+ GB DVD so I'm trying to keep things as light as I can
<LaserJoc1> as well as keep the maintanence low, trying to rely on Ubuntu's seeds as much as possible
<mdz> mathiaz, kirkland, ping?
<mdz> oh, neat, that worked: LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha armel+imx51 (20091007)
<mdz> I hadn't actually seen bugs come in with that apport data
<smoser> slangasek, just fyi, i just remembered that i had put a script in ~vmbuilder/bin named 'build-nightly' that takes a single arg (the suite) and should build correctly
<cjwatson> LaserJoc1: seems reasonable enough to get rid of the addon stuff if you want, certainly
<rickspencer3> cjwatson, just saw this question in #ubuntu-x
<rickspencer3> <jbarnes> how do I disable services at boot in the brave new world of native upstart scripts?
<rickspencer3>  the services applet seems to have disappeared
<rickspencer3> is there a link or something I could point him to?
<chrisccoulson> rickspencer3: bug 433701
<ubottu> Launchpad bug 433701 in gnome-system-tools "services-admin should be disabled" [Low,Fix released] https://launchpad.net/bugs/433701
<chrisccoulson> it was disabled because it doesn't work with upstart jobs
<rickspencer3> right
<robbiew> hmm
<rickspencer3> so what do we do?
<rickspencer3> edit init.conf or some such?
<chrisccoulson> it needs some effort to port it
<rickspencer3> yeah
<chrisccoulson> although the upstream developer might already be working on it
<chrisccoulson> i didn't realise so many people found this tool useful
<rickspencer3> this is jbarnes asking, so I'm sure he can manage editing a conf file or whatever
<rickspencer3> i just don't know where to point him
<chrisccoulson> i'm not sure either
<chrisccoulson> i don't know how you disable services anymore and stop them running on subsequent boots
<rickspencer3> put a file in /etc/intit ?
<chrisccoulson> yes, if you want to add a service. but does he want to disable one?
<rickspencer3> would you not just rename it>
<rickspencer3> ?
<chrisccoulson> possibly, but i haven't tried
<slangasek> mv /etc/init/$foo.conf /etc/init/$foo.conf.disabled
<rickspencer3> thanks slangasek
<rickspencer3> :)
<robbiew> and the voice from above speaks
<robbiew> lol
<chrisccoulson> heh
 * slangasek gets down off the step stool
<chrisccoulson> i've never felt compelled to mess around with the services on my machine ;)
<slangasek> sometimes you have to debug them :)
<slangasek> (well, s/you/we/)
#ubuntu-devel 2009-10-08
<statik> hi slangasek, i'm searching for a sponsor for this couchdb patch, any chance it's something you could help with? https://bugs.edge.launchpad.net/ubuntu/+source/couchdb/+bug/439499
<ubottu> Launchpad bug 439499 in couchdb "OAuth-authenticated database replication crashes, HTTP404" [Undecided,In progress]
<slangasek> statik: happy to
<slangasek> statik: I wonder why there's a VERSION= token in couchdb-bin.postrm at all, it's completely unused...
<statik> slangasek, huh that might be a leftover
<statik> thanks for your help
<natewiebe13> im getting "[Firmware Bug]: ACPI : Invalid BIOS _PSS frequency : 0x0 MHz" from beta.. anyone know why? both on live and alternate
<cyberix_> I read about Debian's plans for going multi-arch
<cyberix_> I suppose this means Ubuntu will go too, as changing all the packages would be insane
<cyberix_> So, what I'm worrying about is, how the transition will go
<ion> https://wiki.ubuntu.com/MultiarchSpec
<cyberix_> thank you
<slangasek> huh, there's somewhere that one can read about Debian's plans for multiarch? :)
<slangasek> (that doesn't point back at the Ubuntu wiki page? :)
<LaserJock> I wonder how much need there is for multiarch these days
<slangasek> plenty
<slangasek> people still use 32-bit flash, and that depends on ia32-libs, and ia32-libs is a festering boil
<LaserJock> I thought the demand was mostly for things like Flash and java
<slangasek> that's the primary desktop case, yes
<LaserJock> but isn't there 64bit flash coming down the pike?
<slangasek> maybe someday
<slangasek> oh, and wine is all 32-bit, too
<LaserJock> I don't know, I just remember it being such a pain to have amd64 and now I hardly notice the difference
<LaserJock> although that could be because of ia32-libs
<TheMuso> Skype is also 32-bit, and likely will only be so for a while.
<slangasek> popcon says ia32-libs is the 2179th most popular Ubuntu package
<Amaranth> LaserJock: 10.1 should have official support for 64-bit on linux, windows, and OS X
<slangasek> and the single largest :-P
<Amaranth> LaserJock: but they aren't even to a beta of that yet
<slangasek> cyberix_: so where were you reading about multiarch?
<LaserJock> slangasek: really, that big?
<slangasek> LaserJock: you really don't know what goes into ia32-libs, do you :)
<LaserJock> I do, but I didn't think it was *that* much
<slangasek> 553M	/home/lp_archive/ubuntu/pool/universe/i/ia32-libs/ia32-libs_2.7ubuntu15.tar.gz
<Amaranth> LaserJock: ia32-libs is basically a copy of GTK+ and everything in the stack below that
<slangasek> Amaranth: and pulseaudio, and...
<Amaranth> oh, and pulseaudio
<Amaranth> yeah
<Amaranth> pain
<Amaranth> 64-bit users without 5mbit broadband need not apply
<slangasek> the .deb is only 29MB
<Amaranth> really?
<slangasek> but the source tarball has to include all the sources
<slangasek> it's just impossible to *maintain*, because it's the equivalent of having to upload an ISO
<Amaranth> yeah, that'd be an all day event for me
<LaserJock> yeah
<TheMuso> I hope I never have to touch that hunk of junk again. :)
<TheMuso> Its about a 3-4 hour upload for me at least, if not longer.
<JanC> adobe's 64-bit alpha flash plugin is more "stable" than their stable 32-bit plugin  :P
<slangasek> shtylman: in bug #424132 you said you would poke the dev if this wasn't fixed by alpha6... any updates there?
<ubottu> Launchpad bug 424132 in openoffice.org "[kubuntu] OOo KDE file dialog is utterly broken." [Critical,Confirmed] https://launchpad.net/bugs/424132
<Amaranth> JanC: Except for all the people who get segfaults when it loads
<JanC> Amaranth: eh?
<JanC> never seen that  ã
<JanC> actually, never heard about that
<JanC> Amaranth: is it related to certain hardware or such?
<Amaranth> no idea
<shtylman> slangasek: unfortunately no... points 1 and 2 I fixed, but still unable to track down why nothing has no next. The last three points I believe to be related.
<shtylman> slangasek: I have asked several developers and we still have no fix
<shtylman> slangasek: the interesting thing is that text *does* appear when using something other than the oxygen style
<shtylman> slangasek: but that doesn't fix the new folder bug and other issues not listen on that report
<slangasek> shtylman: ok.  are you still taking responsibility for this (as you're assigned), and can you perhaps follow up to the bug with information about the current status?
<shtylman> slangasek: will do... I will read through the bug report and see what I can comment on and what has been addressed
<slangasek> shtylman: cheers
<kirkland> slangasek: StevenK: hi guys... could one of you please spin a new server daily iso immediately?
<slangasek> kirkland: spinning
<slangasek> kirkland: why "immediately", btw?  if you were waiting for package publishing, note that we can track that on our side
<mathiaz> slangasek: right
<mathiaz> slangasek: a new eucalyptus package has been uploaded - we'd like to have it included on the next isso
<mathiaz> slangasek: so I think we need to wait for the new package to be published
<slangasek> ok, so the build I've just started is useless? :)
<mathiaz> slangasek: 1.6~bzr916-0ubuntu1
<mathiaz> slangasek: I have the regret to announce that this is probably the case
<kirkland> slangasek: whoops, sorry
<kirkland> slangasek: i got triggerhappy
<slangasek> right; queueing up another build against 916 instead
<kirkland> slangasek: sorry for the inconvenience
<slangasek> I'll relay your apologies to the build server
<LaserJock> where is the CD boot menu items determined?
<TheMuso> LaserJock: I think gfxboot-theme-ubuntu is probably what takes care of that.
<cyberix_> LaserJock: I think Debian's original multiarch proposal states that the spec isn't only about hardware architectures, but about software architectures as well
<cyberix_> LaserJock: I recall them mentioning support for Windows executables or something
<cyberix_> wild dreams, might be
<cyberix_> but maybe part of it makes sense
<cyberix_> they are also talking about emulating hardware
<cyberix_> so eventually you could have a package that supports running PowerPC or Gameboy applications :-D
<cyberix_> The page in Ubuntu Wiki says: "Ubuntu 9.10 introduces support for installing packages from multiple architectures on a single system. This makes a wider array of 32-bit applications available to users of 64-bit Ubuntu."
<cyberix_> How accurate is this?
<cyberix_> I mean, I see no marks of the specification being applied to current beta release of 9.10
<cyberix_> s/marks/signs/
<TheMuso> cyberix_: Its not going into 9.10
<cyberix_> TheMuso: That is the impression I got, but I'm not sure if that sentence refers to something else
<ScottK> It was planned at one point.
<cyberix_> so should we change that to 10.04 then
<ScottK> I'd leave it for the guy that has to deal with it.
<cyberix_> ok
<cyberix_> I'll get some sleep for a change
<cyberix_> good night
<slangasek> kirkland, mathiaz: ISO built
<smoser> can someone please approve my mail to ubuntu-devel (Subject: size of uec images)
<kirkland> slangasek: got it, thanks
<mathiaz> slangasek: could you have a look at bug 445714?
<ubottu> Launchpad bug 445714 in image-store-proxy "[FFE] Image Store Proxy must handle compressed images" [Undecided,New] https://launchpad.net/bugs/445714
 * spaetz sighs. It seems that brightness special keys will be broken in karmic for quite a few models
<tgpraveen> is KMS there for ATI cards or not?
<mohanohi> hi..
<mohanohi> whats the package name for The Color transformation Language in ubuntu?
<pitti> Good morning
<mohanohi> whats the package name for The Color transformation Language in ubuntu?
<pwnguin> colorfilter?
<pwnguin> or are you referring to the language it uses? cuz that's pure shader langage
<mohanohi> pwnguin: yeah..
<mohanohi> pwnguin: ramenhdr uses it..
<mohanohi> pwnguin: i have downloaded the source package
<mohanohi> pwnguin: but donno where to extract it in my ubuntu OS..
<pwnguin> oh i like this already
<mohanohi> pwnguin: what?!!?
<mohanohi> pwnguin: is the package in ubuntu?
<pwnguin> no, just reading the homepage
<dholbach> good morning
<mohanohi> pwnguin: ok.. can you tell me where to extract the header files and library files
<pwnguin> for ramenhdr?
<pwnguin> holy crap. i like it, but those build deps are wild
<mohanohi> pwnguin: yeah...
<pwnguin> intel tbb is probably a blocker
<pwnguin> or
<pwnguin> its packaged and older than i think
<pwnguin> mohanohi: since this isn't directly related to ubuntu core development, perhaps we should move the conversation to #ubuntu-motu?
<mneptok> !info libtbb-dev
<ubottu> libtbb-dev (source: tbb): parallelism library for C++ - development files. In component universe, is extra. Version 2.1~20080605-1 (jaunty), package size 75 kB, installed size 528 kB
<mneptok> !info libtbb2
<ubottu> libtbb2 (source: tbb): parallelism library for C++ - runtime files. In component universe, is extra. Version 2.1~20080605-1 (jaunty), package size 52 kB, installed size 172 kB
<mneptok> ^^^^^^^
<pwnguin> good to know
<pwnguin> should be fine then. development / library headers generally end with -dev
<mohanohi> pwnguin: i am in ubuntu-motu
<siretart`> morning
<siretart`> lool: are you working on the armel/neon patches for ffmpeg? or are you aware of someone working on them?
<siretart`> bug 383240 for reference
<ubottu> Launchpad bug 383240 in ffmpeg "Integrate and enable ARMv5TE/v6/VFP and NEON optimisations from ffmpeg trunk for armel" [Medium,In progress] https://launchpad.net/bugs/383240
<ogra> siretart, lool is travelling today (and might have coppy internet over the weekend until monday)
<mvo> uff, gettext has a recommends on cvs now
 * mvo reads bug #506022
<ubottu> Error: Launchpad bug 506022 could not be found
<liw> mvo, uh, say what? oh, and it's a debian bug
<pitti> Keybuk: good morning
<pitti> Keybuk: you said that your bug mailbox is overflowing, so please excuse the IRC ping: just posted a question for you in bug 439138 comment 67
<ubottu> Launchpad bug 439138 in upstart "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Invalid] https://launchpad.net/bugs/439138
<geser> pitti: Hi. Does the DMB already also MOTU applications or will this be merged in the future and the MC is still responsible (for now)?
<pitti> geser: I think the latter, but I'm not really sure
<pitti> dholbach: ^ do you know?
<cjwatson> pitti,geser: the latter
<mdz> pitti, what can I do to help diagnose bug 445846
<ubottu> Launchpad bug 445846 in gdm "gdm doesn't set the correct keyboard layout in the session" [Undecided,Incomplete] https://launchpad.net/bugs/445846
<pitti> mdz: I think I know what's going on, but I'd like you to confirm; I just replied to the bug
<pitti> mdz: so if you could check the gconftool line I gave you, that will do it (and also the command to unset it, and then try again if it works then)
<Riddell> kees: the  upstream fix for koffice is to remove pdf import so I've done that in karmic
<Keybuk> pitti: no, you can't, but you shouldn't need to
<Keybuk> that bug is full of people misinterpreting the problem
<Keybuk> and it has nothing to do with console-setup
<Keybuk> so far the bug can be summarised by "adding dependency on $RANDOM_THING_THAT_TAKES_SOME_TIME solves the problem for me!"
<Keybuk> you may as well solve it by sticking "sleep 60" in there somewhere
<Keybuk> at some point, maybe even today, I'm going to sit down - read the X source, and figure out what it actually *really* needs
<Keybuk> I'd hoped someone else would do that so I didn't have to, but meh
<ogra> Keybuk, i had a very weird bug yesterday, due to having to test a jaunty kernel on a default karmic install, the ext4 FS didnt work 100%, mountall got in a constant reboot loop and i had no chance to get into the system anymore
<ogra> (mountall called fsck, fsck died, system rebooted ... same game over and over)
<Keybuk> it doesn't reboot it fsck dies
<pitti> Keybuk: well, it's not that random; it loops on ioctl VT_ACTIVATE while the underlying console went away or was changed; I just don't understand what else would even touch vt7, we have a hackish patch in gdm to not use vt 1 to 6
<Keybuk> it only reboots if fsck completes successfully after repairing the root fs
<ogra> yes, and says its usual ************** REBOOT LINUX ***************
<Keybuk> pitti: console-setup doesn't touch vt7
<Keybuk> pitti: I can tell this without looking, because cjwatson wrote it, and he's smart
<Keybuk> but since one should look
<Keybuk> warcraft scott% grep ACTIVE /etc/default/console-setup
<Keybuk> ACTIVE_CONSOLES="/dev/tty[1-6]"
<ogra> Keybuk, right, but wouldnt it make sense to have mountall to respect some kind of kernel cmdline option so you can forcefully disable fsck ?
<Keybuk> pitti: it honestly wouldn't surprise me if the real culprit turns out to be cryptsetup
<ogra> Keybuk, the system was fine, the filesystem wasnt corrupt, my clock was wrong and the last mount time was in the future
<Keybuk> or something else that's using "console owner" :)
<Keybuk> (ie. it could be mountall)
<Keybuk> ogra: if that was the case, you would have been given a shell, not rebooted
<ogra> due to the fact that it couldnt be mounted (caused by fsck dying to early and rebooting) it got into that endless loop
<pitti> Keybuk: hm, I have cryptsetup installed, but no encrypted partitions at all
<ogra> i didnt get a shell
<Keybuk> though maybe it shouldn't just reboot, but let you have a shell ;)
<ogra> yes :)
<Keybuk> pitti: that doesn't matter - if cryptsetup is run, it "steals" the console
<ogra> thats what i mean
<Keybuk> stealing the console while X is running can be bad
<ogra> any way of mounting the disk to actually fix the stamp
<pitti> ok
<Keybuk> pitti: stealing the console is the only way I know to actually "hang up" a tty
<Keybuk> opening it, writing to it, mucking around with it, etc. are all safe
<Keybuk> but starting something that attempts to become the foreground process group for /dev/console, when vt7 is active (which X is the fg pg for) can go wrong
<Keybuk> this is why "console" in Upstart is bad
<pitti> Keybuk: so, I'll ask in the bug whether the reporters have cryptsetup installed, and I'll also test it here again
<Keybuk> yeah
<pitti> it's at least another data point
<Keybuk> it needs some genuine debugging - please don't rush a fix to this one
<Keybuk> lots of things will "appear" to solve it
<pitti> Keybuk: the other obvious candidate is usplash, I guess?
<pitti> (although that should be on vt8)
<ogra> pitti, btw, was there a final decision if usplash gets enabled by default again ?
<ogra> (/me needs to prepare an arm specific change if not, we surely want it there)
<pitti> ogra: the most recent decision I'm aware of is still the one from UDS: let it run when required (cryptsetup et al) or after a timeout when X doesn't start fast enough
<pitti> but right now it just seems to start unconditionally again
<pitti> either that, or the timeout is working :) (can't say with my 85 second boot)
<ogra> right, on armel we're about 8-10sec in the initramfs, its between 10 and 13secd until X comes up
<ogra> and the vendor kernels spit out messages where we dont want to see any ...
<ogra> so usplash is a clear yes for me on that arch
<slangasek> pitti: it's not unconditional if you have cryptsetup installed...
<pitti> ah, so that might be it
<slangasek> (i.e.: "cryptsetup is installed" is the condition under which it runs)
<pitti> well, I have crytpsetup, but no encrypted partitiosn
<pitti> slangasek: I had thought that only the prompt would actually cause it to start up; but that might look bad indeed
<slangasek> in theory it's possible to tweak the cryptsetup initramfs hook to not set USPLASH=yes unless needed
<pitti> something for lucid perhaps
<slangasek> but it looked hairy and I couldn't bring myself to work on it
<pitti> it'd just be nice to be able to install cryptsetup by default again
<cjwatson> pitti: in yesterday's foundations meeting, we decided to enable it by default for karmic and revisit for lucid; the action is mine
<pitti> since it's useful for encrypted USB sticks and the like, even more so since we finally have a GUI tool to set them up
<pitti> cjwatson: sounds like a safe approach for karmic, thansk
 * ogra hugs cjwatson 
<ogra> prevents me from adding ugly hacks :)
<pitti> slangasek: we probably don't need to enable usplash on the fly during boot; making the USPLASH= value dependent on an empty/nonempty /etc/crypttab should be sufficient
<pitti> but anyway, that's lucid beautification
<slangasek> pitti: it wouldn't be enabled on the fly - we have enough information at initramfs generation time to tell us whether it's needed for the root fs
<slangasek> except that the way the initramfs scripts are put together, we currently don't get that information until well after we've set USPLASH=yes :)
<pitti> tseliot: would you mind re-owning lp:screen-resolution-extra to ubuntu-core-dev?
<pitti> tseliot: I'd like to fix the policykit breakage (bug 435709), but I can't push to it
<ubottu> Launchpad bug 435709 in screen-resolution-extra "Needs porting to policykit-1" [Undecided,Triaged] https://launchpad.net/bugs/435709
<pitti> tseliot: I'd also add a proper Vcs-Bzr: tag
<tseliot> pitti: sure
<tseliot> pitti: I don't think I can as launchpad allows me to set the owner to either myself or to a team I'm a member of (and I'm not a core-dev)
<pitti> tseliot: oh, perhaps just ubuntu-dev
<pitti> should be fine for now
<tseliot> pitti: I can't choose that either. Maybe if you add me to Jockey hackers I can set the group to that (just an idea) or we can use some other team
<pitti> tseliot: oh, you aren't a MOTU?
<tseliot> pitti: nope
<pitti> whee, you really ought to
<tseliot> yes, I know
<tseliot> I'll apply for MOTU too then
<pitti> tseliot: well, let me just push my branch to ~ubuntu-core-dev, and we merge back and forth, shall we?
<tseliot> slangasek: did you have a look at my addition to the release notes (about DontZap)?
<pitti> ~ubuntu-desktop would be more appropriate actually
<tseliot> pitti: ok
<slangasek> tseliot: not yet, I'm afraid; it's still on my todo list, however
<slangasek> (release notes work starts in earnest this week)
<pitti> tseliot: for testing, just calling ./policy-dontzap.py should give me the status, right? now it just hangs with changing the mouse cursor and doesn't do anything
<tseliot> slangasek: ok, good
<tseliot> pitti: make a backup of your xorg.conf and then type: python /usr/share/screen-resolution-extra/policyui.py 2048x2048
<tseliot> don't use the dontzap code (as we don't use it in Ubuntu)
<pitti> tseliot: oh, that works; (it's actually lying since on intel that's not necessary any more)
<pitti> tseliot: right, I just looked for something to test the new policykit stuff, and ./policyui.py just hangs the same way
<pitti> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PolicyKit.AuthenticationAgent was not provided by any .service files
<tseliot> pitti: gnome-display-properties decides whether it needs to call screen-resolution-extra or not
<pitti> hah
<pitti> tseliot: ok, that should do, thanks!
 * tseliot can't reproduce the problem here... :-(
<pitti> tseliot: oh, I know why it hangs; I tried ./policy-dontzap.py, it's executable, but doesn't have a hashbang line
<pitti> tseliot: don't worry, I know the problem (you certainly have policykit-gnome installed)
<pitti> tseliot: in fact, that exception was _exactly_ what I wanted )
<tseliot> pitti: ah, very good then. Thanks for working on this
<pitti> tseliot: pushing to lp:~ubuntu-desktop/screen-resolution-extra/ubuntu now; I'll let you know when you should pull into main
<tseliot> pitti: ok
<tseliot> pitti: maybe we should add a dependency on either policykit-1-gnome or on policykit-gnome to screen-resolution-extra
<pitti> tseliot: yes, I'll do that (but I'll port it to pk-1)
<tseliot> ok
<tseliot> seb128: that should fix bug #446199
<tseliot> ^^
<ubottu> Launchpad bug 446199 in screen-resolution-extra "gnome-display-properties hangs when trying to set VirtualScreen size" [Undecided,New] https://launchpad.net/bugs/446199
<tseliot> pitti: do you mind if I assign the bug to you (as you're working on it)?
<pitti> done
<tseliot> pitti: shall I pull your changes into main now?
<pitti> tseliot: no, I just started; I'll ping you when they are done
<tseliot> ah, ok, I was wondering what that "done" stood for
<seb128> tseliot, pitti: thanks for fixing the display thing
<ttx> pitti: about bug 439138, I experience it and I use cryptsetup. Can't disable it for testing though.
<ubottu> Launchpad bug 439138 in upstart "[karmic] Xorg 100% CPU utilization -- only after first login" [High,Invalid] https://launchpad.net/bugs/439138
<pitti> tseliot: hm, fun; your d-bus methods (setDontZap etc.) don't actually call _check_permission(), thus everyone can just call them without auth
<tseliot> pitti: you can remove it if you want as it's really useless now
<pitti> tseliot: no, that's actually a security bug..
<tseliot> pitti: yes, I picked that up
<pitti> tseliot: I want to fix it to actually use PK :)
<tseliot> pitti: ok, maybe it's better to do that at this point
<mvo> tseliot: have you heard of a problem like #439594 ?
<pitti> tseliot: it's the only sensible point to check that
<mvo> bug #439594
<ubottu> Launchpad bug 439594 in update-manager "X crashes while upgrading from Jaunty to Karmic using update-manager" [Undecided,New] https://launchpad.net/bugs/439594
<tseliot> let me check
<mvo> tseliot: apparently when using fglrx while fglrx got upgraded
<tseliot> mvo: oh, that's really something you should ask superm1 about
<mvo> tseliot: ok, I may be able to setup a system to test this, but it is some work so I want to know more about it first :)
<tseliot> mvo, pitti: also I was thinking that maybe I should remove nvidia-common's debconf interface from the kernel postinst and simply rely on Update Manager to migrate drivers (bug #292606). What do you think?
<ubottu> Launchpad bug 292606 in nvidia-common "dkms - error when installing custom kernel" [Medium,New] https://launchpad.net/bugs/292606
<tseliot> users who dist-upgrade from the command line would be on their own though
<pitti> tseliot: hm, not sure; I like people not getting messed up completely if they use aptitude or apt-get dist-upgrade
<pitti> tseliot: does  it cause troubles?
<tseliot> pitti: it looks like DKMS doesn't flush the stdout and causes nvidia-common to get an invalid reply about the driver it should recommend
 * tseliot -> lunch
<mvo> superm1: could you please let me know if you heard about bug #439594 or if you have a simple way to test this?
<ubottu> Launchpad bug 439594 in update-manager "X crashes while upgrading from Jaunty to Karmic using update-manager" [Undecided,New] https://launchpad.net/bugs/439594
<pitti> tseliot:  7 files changed, 57 insertions(+), 236 deletions(-)
<pitti> tseliot:  :)
<pitti> tseliot: done, please pull from lp:~ubuntu-desktop/screen-resolution-extra/ubuntu
<mdz> pitti, since about yesterday, nautilus is opening PDF documents with gedit on my system, which doesn't work so well. evince is not even visible in "Open with...".  known issue?
<mdz> in fact, .odp and .mp3 are being opened with gedit as well
<james_w> https://edge.launchpad.net/ubuntu/+source/shared-mime-info/0.70-0ubuntu1 possibly?
<happyaron> hi team, who can sync ibus and ibus-m17n? (pitti approved it yesterday)
<james_w> uploaded 42 hours ago
<james_w> happyaron: is it urgent?
<mdz> 0.60-2 to 0.70-0ubuntu1  (420.2 KiB) eek
<happyaron> james_w not very, but it contains the first pot file for translations in ibus package
<james_w> happyaron: have patience then, it will be done today or tomorrow I expect
<happyaron> james_w: thanks, :)
<james_w> mdz: probably easiest to try and downgrade?
<james_w> I'm not sure how much caching, if any, is done, so a session restart may be required?
<seb128> mdz, what libglib2.0-0 version do you run?
<seb128> mdz, and did you restart nautilus since you upgraded glib?
<mdz> seb128, ii  libglib2.0-0                               2.22.2-0ubuntu1                            The GLib library of C routines
<mdz> mdz      27013  0.0  0.6 570612 20948 ?        S    Oct06   0:21 nautilus
<mdz> restarting nautilus now
<seb128> mdz, restart nautilus
<mdz> seb128, that fixed it, thanks
<seb128> you're welcome
<soren> mdz: fwiw, the vast majority of that the shared-mime-info diff is translations and updated autotools stuff.
<mdz> soren, looks like it wasn't the cause either, thankfully
<mdz> I'm about due for a reboot
<cjwatson> mdz: you're not the first to report that, I saw a report of it the other day
<cjwatson> mdz: bug 444962
<ubottu> Launchpad bug 444962 in glib2.0 "shared-mime-info-0.7-ubuntu1 update is broken" [High,Fix released] https://launchpad.net/bugs/444962
<cjwatson> ah, heh, hadn't seen it reassigned
<soren> I had a somewhat similar problem yesterday as well. I tried to open a pdf with evince from the command line, and it refused, claiming it didn't know how to handle application/octet-stream documents.
<soren> An apt-get upgrade fixed it for mem.
<soren> me..
<doko_> seb128: do you plan new gtk+2.0 uploads? if not I would like to re-upload for an arm rebuild
<seb128> doko_, before karmic yes, today maybe not
<doko_> same with glib2.0
<seb128> same reply
<doko_> ok
<seb128> do you need a quick rebuild or that can wait for the next changes?
<tseliot> pitti: ok
<mat_t> pitti: hey
<mat_t> pitti: do you know why we don't ship human icon theme anymore?
<seb128> mat_t, it's not used by default and take space on the cd which we use for other things,ie translations
<mat_t> seb128: who made this decision?
<seb128> mat_t, to use humanity by default? ask djsiegel
<mat_t> seb128: to remove human
<seb128> mat_t, to not install human by default, it was a requirement to switch to humanity to win cd space, pitti did the change
<seb128> mat_t, is there any issue with that?
<mat_t> seb128: ok, so was that pitti's decision?
<seb128> mat_t, collection distro decision if you want
<seb128> collective
<seb128> cds are what they are and we have to make the default install use one
<seb128> mat_t, do you have an issue with not having it installed by default?
<seb128> mat_t, open a bug and talk to pitti or slangasek I guess...
<mat_t> seb128: ok, I'm not saying the decision is wrong, but anything that affects the user experience on a large scale should be consulted with the design team
<seb128> mat_t, it doesn't affect anything? it just don't list an extra theme which is not used by default...
<seb128> mat_t, using humanity was a user design team request
<mat_t> seb128: the potential consequences are, if the icon is not present in humanity, it will be replaced by gnome default, which is less consistent
<seb128> mat_t, and that has been discussed with djsiegel without doing the change
<mat_t> seb128: I'm only talking about removing human
<seb128> mat_t, we specifically checked with the design team that human was not required as a fallback for humanity
<mat_t> seb128: with whom?
<seb128> djsiegel when he did the request
<seb128> and some of the icon guys were on the channel too
<mat_t> seb128: ok, I see
<mat_t> seb128: please don't understand me wrong, I know the importance of disk space, but decisions like that must be confirmed with ivanka
<seb128> mat_t, the request came from djsiegel
<seb128> mat_t, next time send whoever is deciding to discuss the changes?
<seb128> mat_t, I think djsiegel was representing your team there
<mat_t> seb128: ok, I see your point. I'll pass that on.
<tevox562> hi
<seb128> mat_t, we didn't do anything out of making the change your team request one day before beta freeze in a hurry
<tevox562> hi can someone help me??? and sry for my bad english ^^
<seb128> mat_t, don't get me wrong but we made efforts to accomodate changes request from your team coming very late, ie the day of the beta freeze, not sure we can take blame there
<mat_t> seb128: Absolutely. I was only asking where the request came from. I know you guys did a lot to accomodate late changes.
<tevox562> bb
<seb128> mat_t, ok thanks, and please let us know now if other changes are required
<mat_t> seb128: thanks seb!
 * ogra notes that "importance of diskspace" is a funny phrasing ... 
<seb128> you're welcome, sorry for the confusion there
<ogra> there simply is none :)
<slangasek> smoser: you understand that the difference in download size between a 2GB tar.gz and a 10GB tar.gz is going to be minimal, right?
<tseliot> pitti: ok, I pulled from your branch and pushed to my branch
<pitti> tseliot: thanks
<smoser> slangasek, yes.
<slangasek> smoser: btw, I've already poked the tar -S code into the build script (but haven't committed it yet), that was the easiest way for me to do an empirical test ;)
<smoser> but the 2G have other advantages
<tseliot> pitti: thanks for working on it. Please upload it when you can
<slangasek> smoser: ok, just making sure that was the case :)
<pitti> tseliot: already done :)
<tseliot> even better
<smoser> big advantage is that per default UEC settings, you could only run 10G images on a "large" instance type
<pitti> mdz: gedit problem> seems settled now?
<smoser> with 2G we can run on any of the sizes.
<pitti> hi mat_t
<mat_t> hey pitti - all clear now, just talking to seb128 about it atm
<mat_t> :)
<pitti> mat_t: that was discussed with kwwii, and it seemed quite obvious to replace human with humanity; it actually just fell off the CD by itself, since human-theme moved dependency from human to humanity
<seb128> pitti, seems that humanity doesn't have as many icons that human
<pitti> mat_t: ah, the fallback issue actually came up in #u-desktop, and we were told that the coverage should be pretty much identical now
<mdz> pitti, yes, thanks to seb128
<seb128> so dropping human means some fallback go to very different icons
<pitti> hm, when we did the switch we were told it had..
<mat_t> pitti: ok, understood. In case there's a need to "bring back" human, what are the consequences? Lang packs?
<seb128> mat_t, do you have a list of problematic icons?
<pitti> mat_t: I'd rather just copy the missing icons from human
<pitti> shipping an extra 2.5 MB just because of 5 missing icons makes little sense
<slangasek> smoser: also, I'm fiddling with trying to get make-web-indices give sensible output for UEC; rough draft at http://uec-images.ubuntu.com/karmic/current/; but I'd like to clarify the file naming scheme before committing (and committing to) this, see my reply to your other email :)
<seb128> ups, xchat-gnome crash
<mat_t> pitti: it's also the question of giving users more choices.
<seb128> mat_t, what pitti said, if we can get a list of problematic icons those could perhaps be added to humanity?
<seb128> mat_t, they can install the package from any package management tool
<mat_t> seb128: is there an easy way of finding out which ones are missing?
<seb128> mat_t, well, you are the one who noticed issues?
<seb128> which ones are those?
<mat_t> seb128: well, casual users will never know how to do it
<seb128> mat_t, I guess we can make the list of icons in both themes and diff easily
<seb128> mat_t, do casual user need to change theme?
<cjwatson> we can't give users an arbitrary amount of choice on the CD
<cjwatson> and we don't in other cases where we might otherwise like to
<mat_t> ok, again, I'm not saying we should bring back human. I just need to know the potential consequences if such request comes in
<cjwatson> indeed, in most cases we just pick the best thing and deliver that on the CD; I think that's even in Ubuntu's founding principles somewhere :)
<mat_t> If the consequence is, for example, not having another language on the CD, it's not worth even thinking about.
<cjwatson> languages are about the only thing we can remove without even more difficult knock-on consequences, and the size of human-icon-theme is (off the top of my head) roughly a language's worth
<slangasek> 1.4M - yep
<cjwatson> we passed the point where we had any other significant slack in our CD images several releases ago (although I thought we'd bought quite a bit this time round by moving help to language packs?)
<slangasek> soren: if by "extracted image" you mean "gunzipped", then you were perfectly clear
<soren> slangasek: Then I'm confused :)
<doko_> ttx: did see that /usr/lib/java/swt.jar is handled by an alternative, which is bad on it's own. question is, if this jar is used by some eucalyptus package directly, or if the versioned jar is used?
<mat_t> cjwatson: thx
<slangasek> cjwatson: that just means that we have a respectable number of languages on the CD now, which we hadn't for some time
<ttx> doko_: looking
<cjwatson> slangasek: fair point
<slangasek> soren: gzip is a streaming compression algorithm - it doesn't have any idea of sparse files
<soren> slangasek: I know.
<slangasek> soren: so TTBOMK, when you gunzip something, it writes out every zero, it doesn't create a sparse file on output
<soren> Indeed.
<slangasek> so feeding this back into tar -S isn't going to do anything useful either :)
<soren> Hence the "gunzip -c $file | cp -sparse=always /dev/stdin $out" trick.
<soren> Oh.
<slangasek> oh, ok
<soren> I see what you mean now :)
<slangasek> I haven't looked at the scripts, didn't realize you were doing such tricks
<ttx> doko_: DEB_JARS := swt-gtk-3.4.2
<smoser> slangasek, just replied.
<soren> cjwatson: You mentioned something about grub2 support in VMBuilder. Is this something you're working on?
<doko_> ttx: ok, thanks
<ttx> doesn't use swt.jar at all.
<slangasek> smoser: sorry, by "version" I meant "ubuntu-uec-karmic" - or, preferably, "karmic-uec" if we get the naming schemes lined up
<slangasek> smoser: -virtual and -server> - these packages aren't co-installable at the same ABI version
<smoser> ture...
<smoser> true even
<smoser> slangasek, the other thing i'd like to know, when looking at directory output is if the kernel actually changed from yesterday. if it did not, then there is no reason for me to do get a new one.
<smoser> so, with kernels named:
<slangasek> smoser: will having the version number in the description field give you that?
<smoser> $version-$arch-{vmlinuz,initrd}-$flavor
<smoser> slangasek, yeah, other than having to dig it out
<smoser> and guessing which package in that list with "linux" in it is the one that i care about
<cjwatson> soren: I have been working on it, but it's blocked on a backport of a grub2 change I made upstream a day or two ago to make grub-install --grub-probe= actually do something useful
<slangasek> smoser: what I'm envisioning here is: karmic-uec-i386-vmlinuz-generic-pae  <datestamp> <size> UEC kernel for 32-bit computers (linux-image-2.6.31-12-generic-pae 2.6.31-12.80)
<slangasek> smoser: and the last part can be a link directly to the launchpad page, too
<smoser> ok. so you're saying the html listing output did the digging for me.
<smoser> thats fine as long as the digging is done "server side"
<slangasek> yes, that's the idea
<soren> cjwatson: Do you think it's something we could have for Karmic?
<slangasek> if you're just grabbing the image, you have a known filename to grab
<slangasek> if you want more info, pull up the index and it gives you the details
<cjwatson> soren: I think so, yes
<smoser> slangasek, yeah, that works.
<soren> cjwatson: Cool. Can I assign https://bugs.edge.launchpad.net/vmbuilder/+bug/410886 to you, then?
<ubottu> Launchpad bug 410886 in vm-builder "VMBuilder doesn't work with grub2" [High,Confirmed]
<cjwatson> soren: sure thing
<soren> cjwatson: Awesome. Thanks so much!
<smoser> the only thing less than ideal for me then is that i'd like for the "flavour" displayed to be '-server' rather than '-generic-pae'
<smoser> but maybe thats not worth it
<smoser> ie, i'd like '-server' and '-ec2' versions. but you've solved everything else i can think of.
<slangasek> smoser: ok, cool; if you want to adjust the build scripts to spit out the new filenames, I can work up the index code
<slangasek> smoser: hmm, but -generic-pae is the name of the kernel flavor, so listing it as "-server" seems misleading?
<superm1> mvo, i've not seen bug 439594 or heard any reports of it so far other than this one, i think that Andreas speculation sounds very sound though
<ubottu> Launchpad bug 439594 in fglrx-installer "X crashes while upgrading fglrx from Jaunty to Karmic using update-manager" [High,New] https://launchpad.net/bugs/439594
<superm1> could update-manager inhibit the screensaver just to be safe?
<smoser> well it does come from the -server metapackage
<smoser> linux-server.
<smoser> err... in this case it would be -virtual
<smoser> and that is consistent for i386 and amd64
<slangasek> smoser: ah; for now please just use the kernel ABI name (server, generic-pae) and if there's time I'll see if we can convert that to -virtual before final
<smoser> i'm happy enough with that.
 * cjwatson tries for a usplash that doesn't leave both console and X horribly busted
<mvo> superm1: thanks, I will add code for that, it would also be nice to be able to reproduce it
<MacSlow> What's the location/name of the local blacklist for kernel-modules (for wifi-chips)?
<slangasek> MacSlow: create your own ".conf" file under /etc/modprobe.d/ ?
<MacSlow> slangasek, can it be /etc/modprobe.d/<anyname>.conf ?!
<slangasek> yes
<MacSlow> slangasek, thanks
<alejandro> hello people
<smoser> slangasek, can you pastebin me a 'tar -S' diff ?
<alejandro> I'm doing a metadistro
<smoser> or otherwise send it.
<alejandro> with Ubuntu 9.04
<alejandro> and i want to up gdm
<slangasek> smoser: $ cd ~vmbuilder/ec2-nightly/automated-ec2-builds/ && bzr diff ? :-)
<alejandro> what do i have to modify to make it????
<alejandro> I guess something like /etc/gdm/gdm.conf\
<alejandro> /etc/gdm/gdm.conf
<alejandro> change tty=7 to tty=4 or to another tty
<slangasek> smoser: "bzr diff -c -1", now (change committed)
<smoser> is tar -S incompatible with -z?
<alejandro> I don't know
<smoser> oh... i see . you want to pass the rsyncable.
<slangasek> smoser: right
<dholbach> any reason why pan is in main? :)
<alejandro> the gdm is the one in chroot
<cjwatson> robbiew: you might be glad to hear I found a nice solution to the console logging problem
<seb128> dholbach, no, any reason why abiword is in main?
<robbiew> cjwatson: \o/
<cjwatson> robbiew: turns out that all the legacy init scripts have their output redirected to the console by way of /etc/lsb-base-logging.sh (which I knew once, but had forgotten)
<robbiew> ha!
<dholbach> seb128: I dunno :)
<dholbach> was just surprised
<cjwatson> robbiew: so I make that honour a CONSOLE environment variable, and make /lib/init/splash-functions (owned by usplash and conveniently sourced by /etc/init.d/rc) set that if usplash was ever running on the system
<seb128> dholbach, same question about gftp too
<cjwatson> job done
<seb128> dholbach, we have lot of things in main for no good reason I think
<robbiew> nice!
<dholbach> seb128: we should purge them :)
<seb128> dholbach, demote you mean?
<dholbach> yeah
<seb128> dholbach, I can see user unhappy about dropping those...
<cjwatson> I've abandoned the idea of releasing vt8 for the moment, since this has the property that you get all the init script output nicely piled up on vt8 for future perusal, independent of console switches
<dholbach> well, we don't remove them :)
<seb128> dholbach, yes fell free
<robbiew> cjwatson: ok
<seb128> ie gftp was in universe it could be synced for example when I looked we only had a langpack change
<cjwatson> robbiew: there's still a noticeable period between usplash stopping and X starting, but I can't do much about that; as far as I can tell, that represents the time for which gdm is scratching its nose and working out what to do
<robbiew> cjwatson: np
<cjwatson> I tried having X start up without shutting usplash down first, but the result of that was a completely hosed console afterwards, since X didn't know what mode to restore
<cjwatson> (*why* does X still have to be responsible for mode restoration in these days of KMS?)
<smoser> mdz, you have a link to info on increasing inodes ?
<cyberix_> LaserJock: multiarch may also turn out to be usefull when Adobe refuses to build a 128bit flash player for Ubuntu
<robbiew> cjwatson: heh...okay.
<cjwatson> cyberix_: we're not short of use cases for multiarch, I don't think ;-)
<danlii> I need some help; I upgraded my router to 9.10, and now hardly any services will start automatically, bind9 won't start at all and the network traffic is super slow, 28 kB/sec on a 10 Mbit line... I see nothing wrong in the syslog or dmesg. What could have gone wrong? Oh, also, it didn't insert kernel 2.6.31 into the grub menu, I had to do that myself too.
<LaserJock> cjwatson: I made the mistake of idly wondering if it was still needed last night ;-)
<Pici> danlii: #ubuntu+1 is the support channel for Karmic
<danlii> Pici: ok, thanks...
<mdz> smoser, not as such, but I have a vague notion that this is what the resize_inode filesystem feature is about
<cjwatson> resize_inode is for online resize, I don't think it has anything to do with sparse files?
<smoser> cjwatson, the question is if i create a filesystem for 2G, and give it the default number of inodes for 2G, is there a way to resize it up to 10G and grow the number of inodes
<smoser> under the presumption (possibly unimportant or wrong) that the actual use of this resized 10G filesystem would result in running out of inodes.
<smoser> i may just have years old data in my head and this is all just magic now.
<smoser> there is 'resize_inodes' in mke2fs, and info about reserving space, but i wasn't able to find anything that clearly said "when you resize the fs, you can also increase inodes by...."
<cjwatson> ah
<cjwatson> resize_inode actually means that an inode is reserved for the purposes of online resize
<cjwatson> smoser: my memory is that online resizing adds block groups, which contain their own block and inode tables, but I'm not absolutely sure; a quick test with tune2fs ought to confirm it
<ArneGoetje> asac: langpacks ran through, you can test the mozilla part.  When you are done, ping pitti or me to upload them.
<smoser> was just doing that.
<smoser> and it "just works"
<asac> ArneGoetje: where?
<pitti> ArneGoetje: oh, I'm already uploading
<pitti> ArneGoetje: they are complete again
<ArneGoetje> asac: rookery
<smoser> create 1M file, mke2fs it. dumpe2fs shows 'Inode Count: 128'
<ArneGoetje> pitti: oh... you are too fast. :D
<pitti> well, I want this bug fixed, it keeps killing kittens^W^Wgenerating bug spam
<ArneGoetje> pitti: +1
<smoser> truncate file to 100M. resize2fs file 100M. dumpe2fs shows 'Inode Count: 1664'
<superm1> pitti, i just had another crash report for mythtv that still is missing the symbols in the retrace.  can you take a look again? bug 446337
<ubottu> Launchpad bug 446337 in mythtv "mythfilldatabase crashed with SIGSEGV in QMutex::lock()" [Medium,New] https://launchpad.net/bugs/446337
<MacSlow> bryce, greetings
<MacSlow> bryce, do you happen to know if the driver for ATI (R300) in xorg-edgers is newer then jan-2009? If not I'll look myself... just wondering if you know by heart
<Christoph_vW> does anyone know if minor updates to mono will be included in karmic? currently it is using 2.4.2.3 afaik - which sucks badly - even simply things like ToolTips are broken in this version
<pitti> superm1: meh, libmyth-0.22-0 is still not in the Packages.gz index :-(
<Christoph_vW> simple*
<smoser> anyone know of an easy way to compare a string like '1G' '100M' (or anything that can be read by resize2fs) to an actual integer ?
<smoser> i'm wanting to take: http://launchpadlibrarian.net/32792682/resize-uec-image
<asac> ArneGoetje: a full path would be helpful ;)
<superm1> pitti, is it maybe something about that package that is causing it to not  show up in this Packages.gz over and over?  it's section or something?
<smoser> and make it resize up or down.  but in order to do that, i have to know if the string the user is giving me is larger than, or smaller than the size of the file now.
<pitti> superm1: clearly apt-ftparchive hates me
<smoser> (to know when to truncate)
<Christoph_vW> smoser: guess you will have to parse it before and convert it to the same base uint
<ArneGoetje> asac: /srv/language-packs.ubuntu.com/karmic/support-base/
<asac> doesnt exist
<asac> only sources-base
<ArneGoetje> asac: /srv/language-packs.ubuntu.com/karmic/sources-base/
<ArneGoetje> asac: sorry
<asac> ArneGoetje: where is the log?
<asac> ArneGoetje: and where the export?
<pitti> asac: log is at /srv/lp.u.c./logs/karmic.log
<pitti> asac: the tarball is already deleted (the cron job script does that), but you can easily re-download it if you need it
<pitti> asac, ArneGoetje: btw, if you ever unpack a release tarball from LP, pretty please rm -r it again when you are done; they are space hogs
<LaserJock> cjwatson: do you know what would be causing: Invalid release file: no entry for multiverse/binary-i386/Packages during "Install Base System" of d-i
<cjwatson> LaserJock: not at the moment, sorry, deep in something else ...
<LaserJock> cjwatson: np
<superm1> pitti, whenever you get that sorted out, can you rerun the retracer on that?  it's a very fresh build and should hopefully be useful to upstream. thanks
<Christoph_vW> smoser: you could replace M/G/...  with sed or awk
<slangasek> smoser: I believe I have make-web-indices tweaked to where it'll DTRT for files using the naming scheme discussed, but I'm EOD here - once you have a chance to tweak the vmbuilder output, drop me a ping on IRC and I can test the make-web-indices part
<smoser> yeah, mainly i was wondering if htere was already a 'human2bytes' program that i could just use.
<Christoph_vW> maybe with awk '{gsub(/M/,"*1024*1024",$2); print $2}'
<smoser> slangasek, ok.
<Christoph_vW> does anyone know if  mono will be upgraded to newer 2.4.x minor versions im karmic?
<Christoph_vW> or will at stay at 2.4.2.3 with some security fixes only?
<kees> Riddell: heh, ok
<pitti> asac: btw, you also have a lot of temp files in rookery:/tmp/; it seems that po2xpi always created a temp dir, but doesn't clean it up (I just deleted gazillion po2xpi* and xpitranslations.* dirs)
<asac> pitti: owned by langpack-o-matic or me?
<pitti> asac: you; I already removed the langpack owned dirs
<pitti> asac: but it would be nice to fix the script to clean up, so that it doesn't keep eating space
<asac> ArneGoetje: so the 3.5 and 1.9.1 langpacks were empy because i had a busted data link. i will disable firefox and xulrunner for 9.10 too ... so we dont need to remove it from launchpad yet for those that want to still carry their changes over
<asac> pitti: yes, thats for sure. could be that i forgot to readd a remove or something while debuggin at some point
<asac> i will check that
<pitti> asac: danke
<asac> ArneGoetje: kick it off again please
<asac> ArneGoetje: if you can fast skip the rest and just try mozilla that would help speed things up i guess.
<sladen> cjwatson: what is X doing trying to restore a video mode; surely that is (only) being done by KMS now?
<cjwatson> sladen: good question and I have no idea (nor do I have time to go and find out)
<cjwatson> lots of things are firmly in the "-> lucid" category for me right now. :)
<cjwatson> .oO <mdz> that's a hoary problem
<hunger> Any chance to get gdb 7.0 in karmic? Probably too late, it only came out today.
<Riddell> pitti: could you eye up adept in hardy-proposed when you have a moment, I'd like to get it tested toot sweet, bug 439706
<ubottu> Launchpad bug 439706 in adept "support hardy to karmic upgrades" [Undecided,New] https://launchpad.net/bugs/439706
<pitti> Riddell: uh, let's hope that this goes well, since we don't truly support that
<pitti> Riddell: skipIntrepid now means "skip intrepid and jaunty"?
<Riddell> pitti: right
<pitti> good, will do an SRU round after I'm done with my current task
<jcastro> Riddell: we have an openweek kubuntu netbook session, want any more?
<jcastro> cody-somerville: ... and we have no xubuntu sessions if you want to do one
<Riddell> jcastro: we do?
<jcastro> Riddell: ScottK is doing one.
<Riddell> jcastro: how about something along the lines of "getting KDE 4 ready for the LTS" ?
<lool> siretart: around?
<jcastro> Riddell: sure, add yourself please! https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
<bryce> MacSlow, yes
<bryce> pitti, slangasek:  FFe on the -intel 2.9.0 upload is bug 446080; the package is assembled and ready for upload if it is approved
<ubottu> Launchpad bug 446080 in xserver-xorg-video-intel "FFe for updating -intel to 2.9.0" [Wishlist,Confirmed] https://launchpad.net/bugs/446080
<pitti> bryce, slangasek: I went through the changelog yesterday, and it looks fairly good; the b43 addition is already in, or at least planned anyway, right?
<bryce> pitti, correct
<bryce> pitti, it's not in yet but Intel requested it so it's on the todo list
<pitti> bryce: people are starting to test mesa now, so let's get it uploaded now
<bryce> alright
<smoser> slangasek, http://uec-images.ubuntu.com/karmic/20091008.4/ has renamed output, please verify that it is in line with what you were expecting
<smoser> and http://uec-images.ubuntu.com/karmic/20091008.5 has a 'tarball packed' output
<smoser> oh, and regarding kernel/initrd names. i did name them with '-virtual' for flavour. this is because i took the information from the package that provided it, rather than the file name
<smoser> which i think is more valid
<Darxus> Screen just died on me again.  I hit ctrl-d at an unfortunate time so I don't have the error message it through when it crashed.  Something about not having something to attach to.
<Darxus> 	5695.pts-0.dancer	(10/03/2009 12:59:33 PM)	(Dead ???)
<Darxus> There's no useful debugging I can do of a dead session, right?
<robbiew> cjwatson: when should I expect to see the console message related changes and usplash enabled for boot?
<cjwatson> robbiew: just need to do another reboot to test this latest batch of changes to make shutdown reliable; distracted by another project atm
<siretart> any cryptsetup guru around to triage bug 446517? I'm pretty sure that the bug is valid, I'm unsure how severe it actually is. I believe that many other bugs are actually because of this
<cjwatson> robbiew: today or tomorrow I think
<ubottu> Launchpad bug 446517 in cryptsetup "/lib/cryptsetup/checks/vol_id depends on vol_id" [Undecided,New] https://launchpad.net/bugs/446517
<robbiew> cjwatson: np...and thanks
<cjwatson> I'm having to do a brutal kludge to get shutdown working reliably, because of what looks like a race in gdm shutdown
<robbiew> cjwatson: well, fwiw, shutdown experience is a lucid thing ;)
<robbiew> not karmic :D
<cjwatson> robbiew: regressions are a "not right now" thing, though ;-)
<robbiew> touche!
<cjwatson> (to be clear, this is me trying to get the shutdown back to at least as good a state as the last upload)
<kees> robbiew: I heard you had a patch for redirecting startup text to tty6?  which bug is that for?  (I suspect 444362 should be a dup of it)
<robbiew> kees: don't need it
<robbiew> kees: cjwatson has a fix for this now
<cjwatson> kees: bug 440871
<ubottu> Launchpad bug 440871 in grub-installer "Add "console=tty6" to default grub kernel command line" [Wishlist,Confirmed] https://launchpad.net/bugs/440871
<cjwatson> and yeah, it'll fix that bug
<cjwatson> well, maybe except for ufw
<cjwatson> they're not really dups though, how about I just close both bugs with this upload
<kees> cjwatson: sure
 * kees still prefers having usplash do the hiding...
<cjwatson> kees: we will
<cjwatson> kees: the fix is two parts. (a) turn usplash on by default again as agreed in the last foundations meeting (b) force all init script output to tty8 if usplash was ever started
<robbiew> kees: patience grasshopper
<cjwatson> well, ever this boot
<cjwatson> the only thing that doesn't account for is upstart jobs that use 'console output'
<cjwatson> and the only one of those that's really relevant I think is ufw
<jdstrand> ufw should be quiet unless there is an error
<robbiew> nice
<cjwatson> ufw should be quiet
<cjwatson> when we're in splash mode
<jdstrand> ie, if it is disabled or enabled, it is quiet
<cjwatson> it using console *at all* creates problems
<kees> robbiew: heh, I didn't know usplash was being re-enabled.  :)
<jdstrand> if there was an error in running the firewall, it speaks up
<robbiew> oh...and apparently the kernel team will fix the "quiet" tag to hide kernel console messages...but will still log to dmesg
<kees> cjwatson: sweet
<mathiaz> free: hi - looking at the landscape-client/smart intrepid SRU
<cjwatson> (so Keybuk says)
<mathiaz> free: how much QA has been done for the new version of smart?
<free> mathiaz: hey
<mathiaz> free: IIUC it's not a 1.2 - only backported patches
<cjwatson> as in, using the console output command requires upstart to do things that cause problems
<kees> <rant>also, can I get colors and a progress bar back in usplash?</rant>
<free> mathiaz: the patches that were included are basically the ones from 1.2.0 that affect landscape-client
<cjwatson> I think it would probably be best to make it use the LSB init script functions (which I think should still be usable in an upstart job) for its output, and then it won't have to do the console output thing
<free> mathiaz: and that have been subject to the QA process outlined in the LandscapeUpdate document
<mathiaz> free: right - have the new combination of packages been through the landscape extended SRU process?
<jdstrand> cjwatson: it is unclear to me whether I should change ufw (again). I tried to comply with a quiet boot, but thought that if loading the firewall caused an error, that is worth mentioning. is this a wrong assumption?
<cjwatson> jdstrand: it's worth mentioning, but not where ufw is currently mentioning it
<stgraber> anyone familiar with the way upstart works ? I'm trying to make Karmic work in OpenVZ and for now all I get is a single "init" process and nothing else in the container
<free> mathiaz: I have tested them personally on an intrepid machine
<cjwatson> jdstrand: I will prepare a patch
<free> mathiaz: but they didn't go through the whole process again
<stgraber> I tried sending the "startup" event manually but get a "Event failed" error ...
 * jdstrand is curious where it should mention it, but will wait for the patch
<free> mathiaz: the patches are really the same that we already QA-ed though
<cjwatson> jdstrand: if usplash is running, it should use one of those usplash OHMYGOD commands to display text on the splash screen
<mathiaz> free: right - I think it would be worth going through an full cycle of QA again - from the -proposed repository this time
<mathiaz> free: so I'm going to upload the new packages to intrepid-proposed
<cjwatson> jdstrand: if usplash is not running, it should put it on tty8 with the rest of the init script output (or at least where the init script output will be once I finish this patch set)
<mathiaz> free: and ask that the full Landscape SRU process be done agains the package published in -proposed
<jdstrand> cjwatson: ok, thanks for the explanation
<cjwatson> jdstrand: this means (a) most users will see it because it will be on the splash screen as an error (b) people won't complain about ugly text-mode text on the screen (c) Keybuk can continue his campaign to get rid of the console command from upstart
<free> mathiaz: you mean re-doing the QA for intrepid-proposed or also for jaunty-proposed?
<mathiaz> free: only for intrepid-proposed
<free> mathiaz: that's fine
<free> mathiaz: I'll ask andreas to help me with that
<mathiaz> free: IIUC the packages that are now in jaunty-proposed are the same as the one that have already been QA
<free> mathiaz: exactly
<mathiaz> free: however the packages that are about to land in intrepid-proposed are *not* the same
<free> mathiaz: also true, some more QA is due
<mathiaz> free: that's why I'd rather have them QAed again - once they're in intrepid-proposed
<free> mathiaz: sounds fine to me
<jcastro> mathiaz: any more openweek sessions?
<mathiaz> jcastro: hm - I'll look at the wiki page again
<mathiaz> jcastro: when is the deadline?
<jcastro> mathiaz: like 2 weeks ago. :D
<jcastro> mathiaz: COB today would be great
<mathiaz> jcastro: ok - when is the *real* deadline?
<jcastro> today
<jcastro> we would like to announce today
<free> mathiaz: btw the hard-deadline for karmic uploads is like next week? we would still have a few patches for the current karmic version of landscape-client
<mathiaz> jcastro: ok - I'll have a look at the schedule once I'm done with landscape
<mathiaz> free: HardFreeze is next Thursday
<free> mathiaz: okay
<mathiaz> free: note that only *bug* fixes are accepted now-a-days
<jcastro> mathiaz: <3, I'll need a short bio from you too, but you can just mail that to me
<free> mathiaz: yes, they're karmic-specific bug fixes
<mathiaz> jcastro: "this dude is great - come listen to him! - jcastro" <- would that work?
<jcastro> yes
<mathiaz> free: sure
<kees> Riddell: thanks for fixing skim!  That lets me check off "rebuild all ELFs in main since introducing hardening flags" finally.  that was the last package.  :)
<LaserJock> anybody happen to know if the current Ubuntu Alternate daily installs?
<mathiaz> jcastro: only spot left are on Fri, Nov 6 - I won't be available that day
<jcastro> :(
<mathiaz> jcastro: so I'll skip this OpenWeek
<jcastro> ok
<Amaranth> ugh, I'm going to have to stay awake until 3am to go to this meeting
<mathiaz> free: could you comment on the status in karmic for bug 268261, bug 236884, bug 388577, bug 389001?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/268261/+text)
<ubottu> Launchpad bug 236884 in smart "need to set proxy for smart too" [Undecided,Fix committed] https://launchpad.net/bugs/236884
<ubottu> Launchpad bug 388577 in smart "The presence of /var/lib/rpm makes the reporter crash" [Undecided,Fix committed] https://launchpad.net/bugs/388577
<ubottu> Launchpad bug 389001 in smart "Timeout option can kill active connections that are still transferring data" [Undecided,Fix committed] https://launchpad.net/bugs/389001
<mathiaz> free: all the bugs that are fixed in the intrepid smart sru need to be fixed released in karmic
<mathiaz> free: could you make sure that the status are correct?
<free> mathiaz: I'm having a look now..
<mathiaz> free: great - I've gone through some of them
<mathiaz> free: if you mark them as fixed released, please add a statement why this has been the case (eg: included in 1.2-4 which is karmic)
<free> mathiaz: alright
<free> mathiaz: I guess most of them don't have a karmic task? like https://bugs.launchpad.net/landscape-client/+bug/268261
<ubottu> Launchpad bug 268261 in landscape-client "add timeout for smart connections" [High,Fix released]
<free> mathiaz: I don't have the permission to add a karmic task I think
<mathiaz> free: karmic == development
<mathiaz> free: for the bug above, you need to make sure it's not incomplete
<free> mathiaz: so just mark the toplevel item as "Fix released"?
<mathiaz> free: yes - top-level for smart (Ubuntu)
<free> cool
<Turl> hello, can anyone confirm this? https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/442378
<ubottu> Launchpad bug 442378 in gnome-power-manager "gnome-power-manager settings have no "on battery" tab" [Undecided,New]
<beuno> Turl, I can see it just fine
<apachelogger> asac: I am not sure we should change the string at this point, so I suppose karmic will ship with the free icon... you still need to make the firefox packages conflict&replace the installer :)
<free> mathiaz: bug 388577 is fixed in the smart package in the jaunty-proposed queue
<ubottu> Launchpad bug 388577 in smart "The presence of /var/lib/rpm makes the reporter crash" [Undecided,Fix committed] https://launchpad.net/bugs/388577
<Turl> beuno: are you on AC Power or on battery power?
<free> mathiaz: Jaunty is now marked as "Fix committed", I'm not sure if I should turn it into "Fix released"?
<asac> apachelogger: whats the problem with that string? its not a translatable string
<beuno> Turl, I can see it on both
<asac> apachelogger: also without that icon you cannot even name it firefox
<mathiaz> free: nope - jaunty status are fine
<Turl> beuno: and if you boot from battery power, does g-p-m believe it's on AC power? mine does
<apachelogger> hm
<asac> apachelogger: if its not possible we can probably also use "firefox" ... as he said. but i dont see why we couldnt try to get permission to change that string
<free> mathiaz: okay, so all bugs have the correct status now
<mathiaz> free: they're fix committed because they've been accepted in -proposed
<asac> its a trademark string -> no translations
<apachelogger> asac: which string was he meaning anyway :)
<free> mathiaz: oh okay
<mathiaz> free: they will be moved to fix released once they're in -updates
<beuno> Turl, I need to stop doing what I'm doing now to test that, so I can't say right now  :)
<Turl> asac: by chance, are you talking abot karmic's firefox saying 'shiretoko' on the title?
<asac> apachelogger: you probably use "firefox" ... and he wants it to be "mozilla firefox"
<free> mathiaz: makes sense
<Turl> beuno: right, thanks anyway :)
<asac> Turl: no. are you running dailies?
<apachelogger> asac: yeah, well, every occurance of that is translatable
<Turl> asac: nope
<apachelogger> desktop file stuff is, the heading is and the description as well
<free> mathiaz: it's a rather peculiar way of using the "Fix committed" term :)
<Turl> asac:   Installed: 3.5.3+build1+nobinonly-0ubuntu3
<mathiaz> free: the important part here is that bugs fixed in an SRU have to be fixed in the development release (*first* usually)
<apachelogger> asac: so changing the string basically fuzzyfies about all strings
<apachelogger> s/string/strings
<mathiaz> free: this is why pitti was asking for the status in karmic
<free> mathiaz: yes, that was clear to me
<free> mathiaz: I didn't introduce anything that wasn't already in karmic, both for jaunty and intrepid
<mathiaz> free: having the bug status set correclty helps the sru team
<asac> apachelogger: do you have the screens still i can look at?
<asac> mine are gone in the backup archive :/
<Turl> asac: any idea why it says 'shiretoko' ?
<free> mathiaz: thanks for the explanations, I'll remember it for the next time
<apachelogger> asac: http://aplg.kollide.net/images/snapshot019.png
<asac> Turl: what does it say in help -> about?
<asac> apachelogger: yes. so you cannot use the string that way
<asac> it suggest that its a Kubuntu Firefox
<asac> and you cannot use the free icon in combination with the trademark
<Turl> asac: Firefox Version 3.5.3 Mozilla Firefox for Ubuntu canonical - 1.0 ....
<asac> Firefox installer would have been fine
<asac> or Mozilla Firefox installer
<asac> i will cehck with him if its still ok
<apachelogger> hum hum
<Turl> (btw, why is canonical on lowercase?)
<asac> apachelogger: in worst case we can export pos and sed it and import
<apachelogger> asac: IMHO that would be best case though, Kubuntu apps get rarely translated as it is
<asac> apachelogger: yes. so checking the translation status in launchpad would be a good first step
<asac> like: how many translations are there already etc.
<apachelogger> asac: https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+pots/kubuntu-firefox-installer
<asac> Turl: thats a bug then for you ... can you file one and assign to me (asac) ... and ping me with bug id?
<Turl> asac: I've already filled one
<Turl> filed*
<Turl> asac: https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/444176
<ubottu> Launchpad bug 444176 in firefox-3.5 "firefox's window title says "Shiretoko" and not "Firefox"" [Undecided,New]
<asac> Turl: you probably tried witha  fresh profile?
<Turl> asac: nope, I didn't - let me try that
<asac> thx
<Turl> mhm, a newly created profile says 'Mozilla Firefox'
<asac> Turl: can you grep for Shiretoko through the .mozilla folder?
<Turl> sure asac
<Turl> Binary file .mozilla/firefox/8l8jtiya.default/extensions/langpack-es-AR@firefox.mozilla.org/chrome/es-AR.jar matches
<Turl> Binary file .mozilla/firefox/8l8jtiya.default/formhistory.sqlite matches
<Turl> Binary file .mozilla/firefox/8l8jtiya.default/places.sqlite matches
<asac> Turl: can you still reproduce by using the original profile?
<asac> back that up so it stays reproducible
<Turl> mhm, how can I test that?
<Turl> you mean, mv .mozilla and relaunch firefox?
<asac> Turl: what did you do to do a new profile?
<Turl> asac: closed firefox, firefox -P and create one there
<asac> Turl: yes. so run firefox -P again and choose the default profile
<Turl> yeah, the default one is my main profile, the one that says Shiretoko
<Turl> I'm using it now again
<asac> Turl: so backup your  .mozilla directory. i will ask further things on bug later. now dinner
<Turl> asac: moving .mozilla to some other place and then opening firefox makes it work fine (title says 'mozilla firefox')
<asac> Turl: i just wanted you to back it up ... so when we start trying things we can still keep reproducing when things are suddenly fixed
<Turl> ok
<Turl> asac: mhm, I rm'ed a langpack extension on the extensions folder in my profile, and it now says Mozilla Firefox
<asac> Turl: where did you get that langpack from?
<asac> anyway out for a while bb i 30 minutes or so
<Turl> asac: I guess from mozilla's ftp, as karmic firefox is in english now :/
<Turl> asac: from here iirc: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-firefox-3.5.x-l10n/
<soren> Are people generally converting their bzr branches to the 2a format? It seems a bit early since only Karmic ships bzr > 2.0, but the package branches are in that format, and they're kind of hard to work with, if the upstream project is using an older format, for instance.
<LaserJock> yeah, it would be nice to have some general guidelines for what we're supposed to do
<jdong> soren: I've been doing so; though the 2a format I should point out is supported by earlier releases too
<jdong> though possibly not as stable...
<soren> jdong: Oh, really? How far back?
<jdong> 1.16-ish?
<soren> Aha!
<soren> ./repository.py:    'Bazaar repository format 2a (needs bzr 1.16 or later)\n',
 * soren rmadisons
<soren> So as far back as... <drum roll>
<jdong> soren: well presumably Ubuntu bzr users would be taking advantage of the Bazaar PPA anyway
<jdong> I'd be more concerned about other distro users
 * soren taps fingers
<soren> I don't use the bzr ppa. Never have.
<soren> I don't expect other people to either.
<LaserJock> it'd be good to know how it'd effect Debian
<soren> Ah. Jaunty is 1.13, so Karmic is the first to support it.
<LaserJock> testing has 1.17 at least
<soren> Yeah.
<jdong> bad assumption about the bzr PPA then :D
<jdong> *revises* presumably bzr users are used to the 90 bazillion format changes per second of their favorite DVCS!
<jdong> (haha love you, bzr devs; it's still my favorite!)
<ScottK> bzr 2.0 is a no change backport for Jaunty.  Just needs some rdpends testing.
#ubuntu-devel 2009-10-09
<TheMuso> c/
<TheMuso> asac: When you get a chance, could you please try Daniel's proposed fix for your issue with the audio clicking If it works for you, I'll go ahead and upload the fix to karmic.
<Darxus> Why do both lubuntu and xubuntu exist?
<TheMuso> Whats lubuntu?
<TheMuso> Xubuntu is Ubuntu with an XFCE desktop.
<Darxus> Lubuntu is Ubuntu with an LXDE desktop.  Same target audience, lower hardware requirements.
<Darxus> Both official Ubuntu variants.
<TheMuso> Right.
<Darxus> https://wiki.ubuntu.com/Lubuntu
<TheMuso> Darxus: Well they exist because people feel there is aneed to have those desktops on an Ubuntu base.
<Darxus> Yeah but why both?  Like, what are the advantages the two have over each other?
<TheMuso> I don't know.
<TheMuso> You'll have to ask the respective devs of the derivatives.
<Darxus> Okay, thanks.
<mgunes> Good day all. http://people.ubuntu.com/~ubuntu-archive/removals.txt seems to have disappeared after the switch to people.canonical.com. Is the list of archive removals available elsewhere now?
<TheMuso> mgunes: Try people.canonical.com?
<mgunes> TheMuso, it's not there.
<cjwatson> mgunes: it disappeared well before that; the data is stored in Launchpad now
<TheMuso> mgunes: ah ok
<cjwatson> (although unfortunately for each individual package, not a full list like we used to have)
<mgunes> cjwatson, I though so and was clicking around Soyuz, but haven't found it so far
<mgunes> ah, per package
<cjwatson> should be in the publishing history
<mgunes> cjwatson, thanks, will check.
<cjwatson> see bug 159585 for the history of this change
<ubottu> Launchpad bug 159585 in soyuz "lp-remove-package.py does not log removals to our standard place" [Medium,Fix released] https://launchpad.net/bugs/159585
<mgunes> thanks; that looks informative.
<slangasek> smoser: yep, that's what I was looking for, thanks
<slangasek> smoser: I see .6 is using the all-in-one tar approach, though?
<smoser> slangasek, both
<smoser> all in one, and then 'unpacked' for Gustavo
<slangasek> smoser: that's not what I see in the .6 directory - I only see the .tar.gz there
<slangasek> smoser: oh... n/m, I missed the "unpacked" subdir
<phretor> hi
<phretor> I wandering why cherokee is now 0.9.22 and Jaunty is stick on 0.11.6 - isn't it quite old?
<TheMuso> phretor: Because once a release like jaunty is released, software in jaunty is not updated to new versions.
<phretor> TheMuso: I see, I am not aware of the release engineering, sorry. However, I get updates almost weekly when software gets updated. Why you say that?
<StevenK> phretor: They get updated for security fixes or critical bug fixes, not to update them to new versions.
<StevenK> phretor: There are very very few exceptions to that.
<phretor> StevenK: I see, you are right. Anyways, what would you recommend to do not to disrupt the distribution but have updated packages when needed?
<mathiaz> phretor: https://help.ubuntu.com/community/UbuntuBackports
<StevenK> phretor: Either requesting backports, or a simpler way is to use a PPA
<phretor> StevenK: exactly, especially because cherokee is 0.11.6 on backports. It's quite up to date on PPA
<phretor> thanks for your support
<Darxus> I'm very concerned about Karmic's behavior when booting with screwed up video drivers.  Everything before it would try starting X a couple times, then give up and drop you to a shell login.
<Darxus> Karmic, apparently, just flickers uselessly forever.
<bryce> Darxus, I believe that is because in the gdm rewrite they dropped the functionality that used to permit falling into that failsafe session
<dave----> hi
<dave----> for encryption in karmic
<dave----> i recommend the default installer now use twofish-xts-benbi
<dave----> AES will soon be broken.
<dave----> also, if you upgrade cryptsetup to 1.1.0rc2
<dave----> you can hash the password with sha512
<dave----> so eg
<dave----> cryptsetup -i 10 -y -h sha512 -S 512 luksFormat /dev/sdx
<dave----> my bad
<dave----> cryptsetup -i 10 -y -h sha512 -S 512 -c twofish-xts-benbi luksFormat /dev/sdx
<dave----> cryptsetup -i 10 -y -h sha512 -s 512 -c twofish-xts-benbi luksFormat /dev/sdx  s ,  not S
<dave----> would be nice if thoes were the defualts for the automated crypto installer
<dave----> i would also like to include that the new version of cryptsetup has the luksSuspend command
<dave----> wich will wipe the crypto key, and "freeze" the crypted volume
<dave----> this is extremely useful for hibernation mode
<[reed]> dave----: you should file a bug
<Darxus> [    6.540427] nvidia: disagrees about version of symbol module_layout
<Darxus> I watched dkms rebuild that module, how would it have a different symbol version?
<Amaranth> Darxus: well, it's not all recompiled, just the wrapper
<dave----> [reed], it is no bug
<Darxus> Amaranth: So what do I need to do?
<dave----> but i believe the latest ubuntu aims for the cutting edge
<[reed]> dave----: launchpad bug
<[reed]> everything is tracked on launchpad as a bug
<[reed]> even RFEs
<dave----> do you think anyone will listen
<dave----> ive doe extensive testing with 1.1.0rc2
<[reed]> who knows, but I can promise you that nothing will ever change just based on some random talk on IRC. still requires a launchpad bug
<dave----> it works fine, all of the commands, but im no cryptographer, so i did everything testing wises short of cryptanalysis
<dave----> i mailed the developer
<Darxus> dave----: Please do file a bug.
<dave----> Darxus, i will
<dave----> can you point me to a specifc pplace to file it?
<Amaranth> dave----: `ubuntu-bug cryptsetup`
<dave----> also i would like to have some people test 1.1rc2 *before* the karmac release
<dave----> so if anyone here using an encrypted system can manually upgrade
<dave----> its here http://code.google.com/p/cryptsetup/downloads/list
<dave----> i  have done a lot of testing , 5 different systems , running juanty, and karmic
<dave----> 1.1rc2 seems to be "stable enough" and, it is still fully backwards compatible (tested)
<Darxus> Still a release candidate though?
<astronut> does anyone know if i can find a backport of libopenbabel 2.2.3 for jaunty?
<astronut> google isn't returning anything useful
<Darxus> Well, have you tried jaunty backports?
<astronut> it didn't appear in http://packages.ubuntu.com/jaunty-backports/allpackages
<Darxus> Okay.  You know it might be easy to rebuild yourself?
<astronut> Darxus: yes, except i don't have an ubuntu system - i'm IM-supporting a friend who's new to linux - i put ubuntu on her netbook a few days ago
<astronut> i don't have an ubuntu pbuilder set up or anything
<Darxus> Ah.
<astronut> mind doing me a favor? ;-)
<Darxus> Heh.
<Darxus> It is *so* past my bedtime.
<astronut> fair enough
<astronut> i should be able to debootstap a pbuilder
<Darxus> Hold on...
<astronut> it's past mine too, i have class in like 7 hours
<Darxus> You should be able to just install build-essential, and apt-get build-dep libopenbabel...
<Darxus> then apt-get source libopenbabel, cd into it, and run debuild.
<astronut> mmm, i just have to do it over IM
<astronut> wget + dpkg would be easier, but fair enough
<Darxus> It's like 3 commands :)
<Darxus> Plus a cd.
<astronut> ya, it was a libstdc++ that was the problem for karmic, so it should build
<astronut> and a dget
<astronut> :-P
<astronut> since the apt-get source will pull the wrong one
<astronut> anyway, i'll walk her through it
<Darxus> Pull the wrong what?
<astronut> Darxus: it'll pull the jaunty version, i'm not getting her to edit her sources.list
<Darxus> Oh, right, hah.
<Darxus> Well, I'm in my jaunty box at work now...
<astronut> http://archive.ubuntu.com/ubuntu/pool/main/o/openbabel/openbabel_2.2.3-1.dsc
<Darxus> Adding deb-src's for karmic isn't dangerous :P
<pitti> Good morning
<astronut> having someone modify sources.list via IM is
<astronut> i'd have her install openssh but i don't want to mess w/ her router via IM too
<dave----> Darxus, yes it is still a release candidate, however if it gets "mainstreamed" into karamac , it wont be for long
<astronut> Darxus: you also forgot devscripts (debuild)
<Darxus> Yeah well, the thing that looks up packages for commands you execute is awesome :)
<astronut> Darxus: not installed here
<dave----> Darxus, also if there any willing testers here for rc2 it will speed up its development into a final release
<astronut> it's ubuntu-specific?
<Darxus> E: Unable to find a source package for libopenbabel
<Darxus> Weird.
<Darxus> I must be too tired for this.
<astronut> libopenbabel3/libopenbabel-dev
<Darxus> li... yeah....
<geofft> libraries almost always have soname numbers in the package name.
<Darxus> $ apt-get source libopenbabel-dev
<astronut> geofft: and usually also the -dev name, which suprised me
<Darxus> E: Unable to find a source package for openbabel
<wgrant> geofft: Not often in the source.
<astronut> oh, and i meant 2 not 3
<Darxus> http://packages.ubuntu.com/karmic/libopenbabel-dev  exists
<geofft> But doesn't apt-get source take a binary package name?
<wgrant> geofft: It takes either.
<astronut> yes - the -dev is a binary
<Darxus> deb-src http://mirrors.ccs.neu.edu/ubuntu/ karmic main restricted universe multiverse
<Darxus> is in my sources.list.
<Darxus> I ran aptitude update...
<astronut> http://packages.ubuntu.com/karmic/libopenbabel-dev
<astronut> http://packages.ubuntu.com/source/karmic/openbabel
<Darxus> Bah.
<Darxus> What, do you just extract the tarball and run patch?
<astronut> huh?
<Darxus> Yeah that worked.
<wgrant> Darxus: dpkg-source -x blah.dsc
<Darxus> Ah, thanks.
<Darxus> Although untarring and running patch seems to have worked.
<Darxus> astronut: Oh!  You could just upload a source package to a launchpad ppa, and have it build for jaunty.
<astronut> Darxus: i think signing up for launchpad and creating a ppa would be more timeconsuming that debootstrapping a pbuilder
<Darxus> astronut: Building.
<astronut> Darxus: oh, awesome
<astronut> Darxus: it'd be really sweet if someone ran a network of pbuilders like the ones anibal has set up for sponsorship in debian
<astronut> you can jus temail it a link to a dsc and it downloads/builds the package
<Darxus> It hasn't died yet.
<astronut> man, the new thinkpad's thinklights are BRIGHT in the dark
<astronut> white instead of yellow
<Darxus> astronut: Did you get what I said about using a launchpad ppa to do this?
<astronut> 01:41 < astronut> Darxus: i think signing up for launchpad and creating a ppa  would be more timeconsuming that debootstrapping a pbuilde
<Darxus> Heh.
<Darxus> I'm also not sure how  you'd get the unmodified source package into the ppa....
<Darxus> Still building.
<Darxus> I should've just built the source package and uploaded it to my ppa.
<Darxus> It's running tests, that should be good.
<Darxus> Ah dammit, I don't have my keys on that machine to build a source package to send to ppa.
<Darxus> Still building...
<astronut> Darxus: don't worry about it
<Darxus> But I'm so close...
<Darxus> Maybe.  Maybe it'll take a couple more hours.
<dave----> are there any devs in here that are interested in the automated crypto installer?
<Darxus> Oh, looks like it's done compiling and now it's building the package.
<ArneGoetje> asac: tar tvfz /srv/language-packs.ubuntu.com/karmic/sources-update/language-pack-de/data/mozilla.tar.gz <- still looks pretty empty
<Darxus> Running lintian.
<Darxus> astronut: I have debs, uploading.
<Darxus> astronut: http://www.chaosreigns.com/ubuntu/jaunty/
<Darxus> astronut: Let me know how that goes.  My email is darxus@chaosreigns.com, and I'll check logs.
<Darxus> I'm going to bed.
<astronut> thanks
<astronut> Darxus: looks like it was good
<pitti> ArneGoetje, asac: why is there a updated-packages in langpack-o-matic from last night? we just uploaded langpacks yesterday with a fresh base export?
<mvo> pitti: hm, changelog purge for universe is done, but only  ~350mb
<pitti> mvo: hey; sadly yes, no noticeable change in df; but thanks for trying!
<ttx> pitti: good morning
<ttx> pitti: could you trigger a -server ISO spin for me ?
<ttx> (i386/amd64)
<soren> If not, I can.
<ttx> soren powa
<pitti> sure, so shall I or soren?
<soren> I'll do it.
<ttx> you guys sort it out ;)
<pitti> ack
<soren> ttx: Running.
<ttx> soren: not sure I should thank you for enabling more eucalyptus testing chores, but here it is, thank you
 * soren tips his hat in ttx' direction
<superm1> mvo, just wanted to provide a friendly reminder, can you remember to upload update-notifier before the weekend if you end up with no other things to change in it other than my hal fix?
<superm1> i'd upload it myself, but i've no idea how to do a new release with it :)
<dholbach> good morning
<mvo> superm1: thanks, I have not forgoten :) I will upload it today
<mvo> hey dholbach
<dholbach> hi mvo
<joaopinto> mvo, how do we setup a proxy for aptd, apt.conf.d ?
<joaopinto> tks tks, no manpage for aptd :P
<mvo> joaopinto: yes, but I'm fixing this right now
<mvo> joaopinto: contributions welcome ,)
<joaopinto> I hate manpages sorry :|
<joaopinto> I mean, writting them
<mvo> joaopinto: the frontend will just tell the gconf settings to aptd
<mvo> joaopinto: should be fixed today
<ArneGoetje> pitti: mozilla translations are empty. and the current run still fails. asac needs to check his scripts again
<pitti> oh, I see
<ttx> soren:  CD spinned -- current still points to the previous one though. Any manual interaction needed ?
<soren> ttx: Not that I know of, but I'm still rather new to this.
<soren> pitti: ^ ?
<pitti> it should be updated automatically
<ttx> ok, I guess it will happen[tm]
<pitti> current -> 20091009
<pitti> it is current, at least on cdimge
<ttx> not from here
<soren> ttx: Where?
<ttx> http://cdimage.ubuntu.com/ubuntu-server/daily/current/ -> 20091008
<pitti> hm, seems cdimage.u.c. is either still syncing, or broken
<soren> Odd.
<pitti> ttx: right, I just checked on antimony (master image)
<ttx> and now it's ok
<ttx> it just synced.
<robert_ancell> dholbach, do you if there is supposed to be a motu meeting now?
<soren> ttx: http://cdimage.ubuntu.com/ubuntu-server/daily/current/ still shows me yesterday's images.
<ttx> hmm me too
<soren> Meh, it'll probably sort itself out shortly.
 * ttx wonders if he didn't hit momnetarily the wrong link
<ttx> yes
<dholbach> robert_ancell: yes, I'm sorry - I'll chase people up
<robert_ancell> dholbach, thanks
<davmor2> ttx: Have the dust started to settle on uec now?  Is it worth reviewing the docs or shall I leave it till next week?
<ttx> davmor2: we still need to update them to reflect the latest bundling for UEC images delivery
<ttx> davmor2: next week should be alright... and the tests on the tracker should be aligned by then
<davmor2> ttx: Cool okay.  That will tie it in nicely then with RC
<dholbach> I just did an upgrade of my server to karmic - dpkg segfaulted - everything segfaults now
<dholbach> I think I'm thoroughly screwed now
<ion> Ouch
<dholbach> and the server is 500km away from here
<StevenK> dholbach: When did dpkg segv?
<dholbach> StevenK: http://people.ubuntu.com/~dholbach/log
<asac> ArneGoetje: i looked last night. and it was a permission problem
<asac> fixed it already
<asac> at least from what i can tell
<StevenK> dholbach: Yeah, that's pretty bad. :-(
<soren> dholbach: What kind of hardware is that?
<dholbach> soren: it's a vserver, i386 running on it
<ion> dholbach: The last time the exact same symptoms (pretty much identical log) happened to me was almost ten years ago: libc.so got corrupted when upgrading due to faulty hardware.
<soren> dholbach: vserver? As in http://linux-vserver.org/ ?
<dholbach> soren: yes, I think
<soren> dholbach: Wow. I haven't heard of anyone actually using that before :)
<soren> dholbach: Who offers these?
<mvo> ion: I got a similar report some days ago, jaunty->karmic and a crash early from dpkg
<dholbach> soren: net-lab.net
<mvo> I really hope dholbach manages to get the crash file from the dpkg segfault (and that there is one)
<siretart`> soren: dholbach: I'm using vserver with hardy w/o problems so far.
<siretart`> dholbach: what kernel is your vserver running on?
<sistpoty|work> is there something wrong with de.archive.ubuntu.com? (got 403 at 141.76.2.130, http://de.archive.ubuntu.com karmic/main Packages, 141.76.2.131 times out)
<dholbach> siretart`: 2.6.29.4-vserver2.3.0.36.14-demou-nfct-100hz-nopre-something
<dholbach> s/demou/domu
<siretart`> hm. at least hardy works with the stock debian vserver kernel.
<dholbach> hardy worked, jaunty worked too and I'm that once libc works again, karmic will work too :)
<dholbach> ...I'm sure...
<siretart`> then it would be very interesting to know what kernel requirements karmic's libc has
<dholbach> why do you think it's a kernel problem?
<siretart`> not sure, but I'd like to rule that out first. it seems to me the most obvious difference to a 'normal' ubuntu chroot
<dholbach> mvo: the other dpkg crash - where did that happen?
<mvo> Riddell: do you have any objectitions if I change the autostart file of the policykit auth agent from "OnlyShowIn=GNOME;XFCE" to include KDE as well?
<mvo> Riddell: background is bug #444661
<ubottu> Launchpad bug 444661 in software-center "[kde] Software-center run as normal user" [Medium,Confirmed] https://launchpad.net/bugs/444661
<steveire> Hey, there doesn't seem to be a #gtk channel to speak of. Where do I go for pygtk help?
<steveire> I want to execute a callback when a selection is made in a treeview
<Chipzz> look on irc.gnome.org
<Chipzz> #pygtk and #gtk+
<thekorn_> pitti: hi, when a user tries to mount an external volume in a karmic live session he is asked for a password, this password is empty. Is this intended, and if so would it be possible to show a small hint about it?
<steveire> There's no more than 5 people in any of the chanels
<steveire> 3pygtk is just me
<steveire> #pygtk
<dholbach> steveire: try irc.gnome.org
<steveire> ok
<steveire> dholbach: There's some berlin ubuntu event on soon right?
<dholbach> steveire: http://ubuntu-berlin.de lists them all
<steveire> Oct 31, ok
* mthaddon changed the topic of #ubuntu-devel to: Codehosting/Codebrowse down 10:00-10:30 UTC for hardware maintenace | Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.u
<ArneGoetje> asac: did you fix it before or after 22:00 our time?
<asac> ArneGoetje: after
<asac> 2.5am
<ArneGoetje> asac: so, I need to run the build again
<mvo> james_w: about bug #444661 - can you see any reason to keep the onlyshowin=gnome;xfce ? given that  kde does not have a agent?
<ubottu> Launchpad bug 444661 in policykit-1 "[kde] Software-center run as normal user" [Medium,Confirmed] https://launchpad.net/bugs/444661
<asac> ArneGoetje: try the xpis only. permissions were definitly busted ... and should be fine now ... i think its reasonably likely that it works now.
<james_w> mvo: no, I think it should be done
<asac> ArneGoetje: but run -xpi only if you can to get quicker feedback
<mvo> james_w: cool, thanks. I can prepare a upload unless you have other pending changes
<james_w> mvo: however, if you are going to switch software-center by default then they may not appreciate gnome on the CD
<ArneGoetje> asac: yupp
<james_w> mvo: or is it a runtime thing?
<mvo> james_w: software-center will not be default on kde, I don't think they would like that :)
<mvo> too much "import gtk" in it
<james_w> ah, of course :-)
<james_w> please go ahead then
<mvo> its just so that people who want to play with it can use it on kde too
<mvo> james_w: great, thanks
<james_w> no, thank you
<Riddell> mvo: that seems fine with me
* mthaddon changed the topic of #ubuntu-devel to: Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<pitti> thekorn_: it's "intended" in the sense that the user should still authorize it, but of course in this case it would make sense to not show a password input at all
<thekorn_> pitti: right, this is especially confusing in cases where you first enter a wireless network (you are asked to choose a password for gnome-keyring there), and I guess most user will try to enter this password into this policykit dialog
<thekorn_> pitti: what's the right target for this bugreport, policykit?
<pitti> thekorn_: pk-1-gnome, yes
<thekorn_> super, thanks pitti
<ArneGoetje> asac, pitti: mozilla translations look good now. uploading.
<pitti> yay
<nxvl> Keybuk: for some reason when i boot my computer i'm not getting the swap mounted, any idea why?
<nxvl> Keybuk: i've 6 512 Mb encrypted LVM partitions for swap, not even one mounted
<pitti> cjwatson: CD health check> hm, I don't understand how the sysvinit binary can be so sticky; it disappeared from karmic weeks ago..
<Keybuk> nxvl: usually you get one mounted ;)
<asac> ArneGoetje: great. also excluding the 3.0/1.9.1 things worked?
<asac> ArneGoetje: have you checked if zh-trans etc. is good too?
<cjwatson> pitti: I can have a look; I didn't realise it was that long ago
<cjwatson> pitti: are you sure that it wasn't only NBSed out recently?
<pitti> cjwatson: at least a week ago
<cjwatson> not, say, post October 3?
<pitti> cjwatson: I was going to do it last Friday or so, but then it was already gone
<asac> ArneGoetje: pitti: can you add me to the lang-pack-o-matic group or something? i would like to move the .xpi data to a place where we all can write
<pitti> asac: ArneGoetje and I can't, needs an RT
<pitti> asac: please CC me, to ack it
<asac> thx
<nxvl> Keybuk: usually i got all 6 mounted, but since i upgraded to karmic i get none
<cjwatson> pitti: well, it's not in antimony's mirror any more
<asac> pitti: what should i be asking for?
<cjwatson> pitti: last DVD build that worked was last Saturday
<asac> pitti: e.g. whats the exact group name
<pitti> asac: you want to become member of the "langpack" group
<pitti> cjwatson: is there an NBS removal lag from antimony by any chance?
<pitti> hm, no, I suppose it uses Packages.gz
<cjwatson> pitti: it rsyncs the whole mirror, actually
<cjwatson> it *should* use Packages for its own bits
<cjwatson> pitti: from what I can see, though, it looks as if the next DVD build should get rid of it
<pitti> cjwatson: ok; I'm fine with just ignoring it, seems it isn't something obvious then
<pitti> cjwatson: thanks
<nxvl> Keybuk: the weirdest part is that using swapon it works fine, so i assume is something in the boot process, i suspect that swap is trying to be mounted before my disk get's unencrypted/mounted?
<asac> Keybuk: how to detect if the the current system has upstart? really want to fix NetworkManager upstream build system to do the right thing
<Keybuk> asac: I'm not sure there is a way ;)
<Keybuk> init --version | grep Upstart? :)
<Keybuk> but that won't work on our buildds, for example
<asac> Keybuk: ok. so i guess that means we probably want --with-upstart-init ... now i need to find something for debian/rules so my packages are backportable without touching ... hmm
<Keybuk> I wouldn't worry about doing this "upstream" just yet
<Keybuk> e.g. Fedora have an older Upstart than us, so they wouldn't be able to use it
<asac> Keybuk: well. problem is that i run backports which are now broken ;)
<Keybuk> really, can't you just use the older dh_installinit on the older versions?
<pitti> asac: should bug 429835 be fixed by your recent xpi langpack fixes?
<ubottu> Launchpad bug 429835 in langpack-o-matic "[MASTER] chrome error when viewing untrusted https site using firefox with non en-US locale on karmic" [Undecided,Confirmed] https://launchpad.net/bugs/429835
<asac> pitti: ack
<pitti> \o/
<asac> pitti: its the po2xpi processor that has a bug. those whitelisted dont have it and the rest is produced from .xpis
<asac> but i have a fix for po2xpi ... so devmode will be fine in lucid right from start
<asac> Keybuk: i will think about it. maybe i can get that info from dh_installinit or some other upstartified debhelper thing in debian/rules and then pass --with-upstart or something to upstream tree?
<asac> Keybuk: do you know about debian plans wrt upstart?
<Keybuk> asac: no idea
<Keybuk> Debian "plan" to adopt it
<Keybuk> but only if the Debian maintainer (mbiebl) makes a bunch of changes the Debian sysvinit maintainer wants
<Keybuk> and assumedly only if someone from the freebsd side ports it
<asac> ok i will check with mbiebl directly. would be great to have something one can use at some point to figure if we have upstart
 * Keybuk certainly won't be holding his breath ;)
<asac> on packaging level would be good enough i think ... dont need to be a real upstream solution
<asac> thx
<lamont> Oct  9 05:04:22 rover3 gnome-session[4322]: devkit-power-gobject-WARNING: unhandled property 'RecallUrl' <-- I suspect logcheck needs some karmic-love
<ArneGoetje> asac: yes, works
<lamont> Reinstalling deleted mandatory conffile color.cfg
<lamont> cp: cannot stat `/usr/share/texlive-base/color.cfg': No such file or directory
<lamont> sigh
<lamont> oh. sigh.
<frafu> Hi, I am co-maintainer of onboard, the onscreen keyboard shipping by default with karmic. Onboard is hosted on launchpad, that is also used for the translations. A new version with a corresponding branch and series hit karmic several days ago. However, the language pack update from yesterday is still shipping old onboard.mo files. Could anybody please tell me what I have to do to get the new translation files into the language pack?
<james_w> frafu: #ubuntu-translations might have your question reach people more familiar with the process
<james_w> bug 447141
<ubottu> Launchpad bug 447141 in policykit-1-gnome "Karmic live session: User is asked for a password when trying to mount an external volume although this password is empty" [Undecided,New] https://launchpad.net/bugs/447141
<frafu> james_w: thanks; I am going to #ubuntu-translations
<james_w> should we ship a casper script to allow everything without password on the live cd?
<cjwatson> james_w: we already try to, but it tends to get out of date
<james_w> ah
<james_w> in which package does that live
<asac> ArneGoetje: nice. thats great. one more verification: if you set export LANG=es/pt/zh (nothing more) ... what es coutry code are used?
<cjwatson> see e.g. 44pk_allow_ubuntu
<cjwatson> james_w: casper itself, scripts/casper-bottom/
<asac> what es/pt/zh ...
<james_w> if we want *everything* then it is easier with polkit-1
<james_w> thanks cjwatson
<cjwatson> I suspect that pk_allow_ubuntu needs to be updated for polkit-1
<james_w> yes, I can look at that
<cjwatson> asac: those aren't valid values for LANG on their own ...
<asac> true
<asac> but its good to test the default anyway
<asac> in case you have es_RARECOUNTRY set and we dont have a langpack it will fallback to whatever it would choose with just es
<ArneGoetje> asac: in that case, just es.
<asac> oh ;)
<asac> hehe
<frafu> james_w: #ubuntu-translations gets created when I try to join it. Are you sure about the name?
<asac> ArneGoetje: just almost got me. i think the es is just a hook still
<james_w> frafu: #ubuntu-translators, sorry
<asac> ArneGoetje: physically we ship es-ES es-AR etc. and have a hook that maps es to es-ES
<ArneGoetje> asac: the default fallback is: strip off the country code
<ArneGoetje> asac: except for special cases, like zh_*
<asac> ArneGoetje: yes. but we use upstream xpis
<ArneGoetje> asac: in the case where we have upstream xpis, those get used, of course
<asac> so we definitly have a hook in the po2xpi processort to propery hook up the default
<frafu> james_w: thanks again
<ArneGoetje> asac: ?
<asac> ArneGoetje: i am trying to tell you that the fallback for es could be wrong ;) ... so we should verify that
<ArneGoetje> asac: in which ase would it be wrong?
<ArneGoetje> asac: ah, ok, I see what you mean...
<ArneGoetje> asac: because we ship es-ES.xpi and not es.xpi... so the fallback should be es_ES:es
<ArneGoetje> asac: good point. I guess we need to specify this for all cases where the upstream xpis have coutry codes...
<asac> ArneGoetje: yep. so the po2xpi appends a magic mapping to the install.rdf of whatever we have configured to be the default
<asac> ArneGoetje: you can just check in the install.rdf if there are locale es ... mappings below the es-ES ones
<ArneGoetje> asac: oh, I see
<asac> ArneGoetje: right. so you can check all that have multiple country codes. if you want some default to be changes just let me know
<ArneGoetje> asac: ok
<ArneGoetje> asac: I don't see any fallback langcode in the install.rdf files
<asac> ArneGoetje: sorry. my mistake ... chrome.manifest
<ArneGoetje> asac: ok
<ArneGoetje> asac: also, there are no fallbacks set
<ArneGoetje> asac: do we need fallbacks in them? Aren't the upstream XPIs supposed to be complete?
<asac> no they are not. upstream uses random fallback ... but they are not really into shipping multi lang setups
<asac> so its not a problem for them
<asac> ArneGoetje: where is the mozilla.tar.gz?
<asac> i cannot find it in sources-base
<ArneGoetje> asac: sources-update
<smoser> slangasek, MD5SUMS file has empty size in 20091009
<smoser> (adn others also)
<asac> ArneGoetje: there are: ./usr/lib/firefox-addons/extensions/langpack-es-ES@firefox-3.5.ubuntu.com/chrome.manifest
<asac> ArneGoetje: http://paste.ubuntu.com/289291/
<asac> ArneGoetje: we dont need to do that for languages that only have one country code, because the "random" fallback automatically choosen is always right ;)
<ArneGoetje> asac: es-AR and the others don't have
<asac> ArneGoetje: on the default has that.
<asac> only
<ArneGoetje> asac: you confuse me
<J_P> hi all
<J_P> ubuntu 9.10 have python 2.x as default right? In 10.04 LTS will be python 3.x as default?
<beuno> J_P, I don't think it will have 3.x, no
<J_P> beuno: :-(
<J_P> beuno: are you talking about 10.4?
<beuno> J_P, yes. Python 3.x is a big transition, I don't think it will be done in an LTS
<J_P> beuno: I think in next LTS will be great idea, because LTS will be support for 5 years.. and 5 years 2.x will be obsolete
<beuno> J_P, it's only a great idea of our applications work in 3.x, which most of them don't
<J_P> beuno: but in worse situation, 3.x will be in sources to be installed via apt right..
<beuno> J_P, yes. In fact, it's already there in karmic
<beuno> maybe even jaunty can't remember
<J_P> beuno: yes, in jauty has python 3.0.1
<steveire> This is what I was looking for Gtk help for a few hours ago by the way: http://steveire.wordpress.com/2009/10/09/holy-grail-no-thanks-weve-already-got-one/ I figured out what I needed.
<pitti> slangasek, cjwatson: any objection against having ntfsprogs installed by default? it would allow people to change labels on NTFS partitions through the GUI
<pitti> (I'd add it as a recommends to devicekit-disks
<joaopinto> mvo, I think it would make sense to have an option on software-center to clear the apt cache, I don't think there is a gui to achieve it right now
<cjwatson> pitti: I don't mind, if we have the space and if ntfs-3g is still the default for mount (should be)
<joaopinto> hum, something odd here, did an aptdcon --upgrade-system, and update-manager is still showing pending updates
<mvo> joaopinto: have you restarted update-manager since?
<mvo> joaopinto: iirc aptdcon will perform only the equivalent of a apt-get upgrade (so there won't be new dependencies instaled by that)
<joaopinto> mvo, no, but I used the "Check for updates" button
<joaopinto> so both should have the same cache info
<mvo> joaopinto: right, maybe there were just new updates on the server between installing via aptdcon and clicking check?
<joaopinto> mvo, ah ok, its a kernel package, it maybe related to a dist-upgrade
<joaopinto> mvo, nope, I have retried, so it must be to the upgrade process difference
<dholbach> so regarding the messed up upgrade (dpkg segfaulted during libc configuration, now everything segfaults, bug 444484?): I had somebody replace libc6 on the system, but everything's still segfaulting
<ubottu> Launchpad bug 444484 in dpkg "dpkg crashed upgrading libc6" [Undecided,New] https://launchpad.net/bugs/444484
<dholbach> any idea what I could test or get replaced?
<joaopinto> it's a new kernel, -13, which is not puslled by s-c
<joaopinto> pulled
<dholbach> http://people.canonical.com/~dholbach/log is the log of the jaunty->karmic upgrade
<robbiew> Keybuk: is it a big deal to add the drivers under /usb/storage to "MODULES=MOST" for the initrd image?
<Keybuk> robbiew: shouldn't think so
<Keybuk> it's like 300K
<robbiew> cool...could you do that?  Not that urgent, but would like it in for Karmic
<Keybuk> actually, not even that, because usb-storage.ko is the biggest
<Keybuk> is there an associated bug#?
<robbiew> 419231
<robbiew> bug 419231
<ubottu> Launchpad bug 419231 in initramfs-tools "2.6.31-6.25 and later can not boot my USB drive, missing ums_cypress.ko" [Medium,Triaged] https://launchpad.net/bugs/419231
<cjwatson> slangasek: do you know what's happening with the latest comment in bug 431248?
<ubottu> Launchpad bug 431248 in portmap "NFS not mounted" [High,Fix released] https://launchpad.net/bugs/431248
<Keybuk> robbiew: done
<robbiew> thanks!
<cjwatson> ogra: what would be a good way to reliably detect the situation in bug 364273? I'd like to clear this up for karmic
<ubottu> Launchpad bug 364273 in ubuntu-release-notes ""eject the CD" text is wrongly displayed on systems where the install media is re-used as boot media for the installed system" [Undecided,Fix released] https://launchpad.net/bugs/364273
<directhex> am i misremembering that ubuntu is a bit more lenient over creative commons' viability for main/universe than debian?
<ogra> cjwatson, phew, hard, we could set a flag in the livesystem i.e. /.livemedia_is_boot from flash-kernel in case we actually re-use the install media
<Laney> the only freeness difference I know of is over gfdl invariant sections
<ogra> cjwatson, i cant imagine a general case to actually "detect" it
<LaserJock> directhex: I think Ubuntu took the free CC 2.5 licenses but Debian only considers > 3.0 free I believe
<cjwatson> ogra: well, what's the condition in the installer? "installing to other partitions on the installation medium"?
<directhex> LaserJock, right, okay
<ogra> cjwatson, no, in that special case install media is different from target media (SD vs USB disk) we just truncate the boot partition on the install media here
<ogra> cjwatson, this is done by flash-kernel-installer.postins which could set some kind of marker that could be read by usplash
<ogra> *postinst
<cjwatson> ogra: s/usplash/casper/ actually
<ogra> yah
<ogra> *yeah even
<cjwatson> ogra: hmm, partman knows what the installation medium is though
<ogra> right, but it doesnt know the install medium is being truncated and abused as a "boot floppy"
<cjwatson> ogra: oh, we don't create partitions on the medium?
<ogra> the actual work has to be done by the bootloader installer though it's surely valuable info for that program to know about it
<ogra> nope
<ogra> we dont touch the mediums partition table at all
<cjwatson> ogra: ok. can you point me to the specific code in flash-kernel-installer that does this? is it the fconfig call?
<ogra> babbage install: boot from SD .... install to USB disk, bootloader modifies bootloader partition on SD ....
<cjwatson> maybe we should just make this conditional on babbage-board in casper, rather than messing about
<ogra> itÃs several fis calls in combination with dd
<cjwatson> we always act this way on Babbage, right?
<ogra> currently we do
<ogra> it might change once we have a driver for mtd flash devices
<cjwatson> ok, in that case I'll just make it conditional on that for now
<ogra> wont change for karmic anymore though
<cjwatson> I just want the bug off my list really :)
<ogra> fis_dev=/dev/mmcblk0 is hardcoded ... if you can carry the info from partman over it should be easy to make it conditional based on comparison
<ogra> so later once we use /dev/mtd0 or something and it differs from the install media then it would dtrt
<cjwatson> ogra: I'll just hardcode it in casper for now; it can be modified later
<cjwatson> thanks for the advice
<ogra> thanks for asking, i totally had forgotten about that one
<ogra> so may last minute kernel issues on my plate :/
<ogra> (and i'm at the maemo summit this weekend which doesnt help getting forward)
<cjwatson> it's been on the foundations list for ages
<slangasek> cjwatson: 431248> requires further follow-up; I think I know what the race condition is, I probably need Scott's help there
<Keybuk> hmm?
<Keybuk> slangasek: the most obvious problem being that there's nothing that happens after rpc.* have been started ?
<Keybuk> so if ifup is faster, it wins?
<slangasek> Keybuk: yes - and in fact, I think one user having this problem is doing NFS root and never brings up any network interfaces, heh
<cjwatson> slangasek: should the NFS jobs have 'normal exit 0 1' or something? I see a certain amount of console noise from them here
<cjwatson> rpc_pipefs idmapd gssd all complain about pre-start exiting 1
<slangasek> cjwatson: no; I use exit 1 in the pre-start script to avoid starting the actual daemon, since extra forks in 'script' make upstart very unhappy
<Keybuk> slangasek: I've got a fix for that already :)
<Keybuk> (the race)
<cjwatson> what is the correct way for a pre-start script to exit in such a way that (a) the main process doesn't run and (b) it's silent?
<Keybuk> cjwatson: there isn't one
<Keybuk> actually, sorry
 * Keybuk rereads the question properly
<Keybuk> || { stop; exit 0; }
<cjwatson> aha
<Keybuk> "stop" called inside a job's own scripts will set the status to be stopped
<Keybuk> so even though you exit 0, it won't result in the process being started
<cjwatson> wow, I never knew that stop implicitly checked the job name
<cjwatson> not documented :)
<Keybuk> (likewise you can call "start" inside a post-stop script to restart it)
<slangasek> oh, cool
<slangasek> Keybuk: as for the race, what's the fix?  are you going to upload that, or do you want to throw it at me?
 * cjwatson cleans up usplash.upstart then
<Keybuk> slangasek: two secs
<leszek> hi
<mdz> Complete report (recommended; 185.6 MB)
<leszek> how to change the logo displayed in the new gdm in karmic ? (the distribution logo)
<superm1> mdz, i'm not convinced that calculation is right with appor-cli.  mine said 512mb or so the other day, but it really only ended up being between 50 and 70 that were attached when it was done
<mdz> superm1: interesting.  the attached files will be a bit smaller because they're decoded, but I've never seen that big a discrepancy
<mdz> smoser: re: bug 415019, I added it to the general hook such that we should get this data for every bug report from an EC2 instance, regardless of whether it's the ec2-init package or not. is it not working for you?
<ubottu> Launchpad bug 415019 in ec2-init "need apport hooks for ec2-init" [Wishlist,Confirmed] https://launchpad.net/bugs/415019
<smoser> mdz, i've not tried it.
<smoser> i will right now. it should be in beta ?
<cjwatson> Keybuk: do you know anything about the status of bug 438962? Steve put it on the release meeting agenda. The user said that (a) upgrade to a bit before beta broke (b) fresh install with beta worked -
<ubottu> Launchpad bug 438962 in udev "upstart/mountall does not boot after mounting crypto disks" [High,Confirmed] https://launchpad.net/bugs/438962
<cjwatson> Keybuk: - do you think it's fixed, or is there still a lurking upgrade problem?
<mdz> smoser: it's in apport 1.9.1-0ubuntu3 and later (25 September)
<Keybuk> cjwatson: I know nothing about it
<Keybuk> someone who knows about cryptsetup should review it
<cjwatson> hmm, ok
<smoser> mdz, how do you recommend i test this ? just call ubuntu-bug with a package and then make the created bug invalid ?
<Keybuk> slangasek: still working out how to deal with rpc.statd
<mdz> smoser: APPORT_STAGING=1 ubuntu-bug ec2-init
<mdz> smoser: that will report the bug to staging.launchpad.net (whose database gets tossed every day)
<mdz> to avoid putting noise into the production LP
<smoser> ah..
<Keybuk> slangasek: basically the idea is to start the nfs bits when mountall finds an nfs partition not the other way round
<smoser> i just created one already, and tagged it invalid. i'll remember staging in the future.
<Keybuk> slangasek: so idmapd.conf would contain  "start on local-filesystems and mount TYPE=nfs4"
<mdz> smoser: if there is information which is specific to ec2-init which you want to collect, or if there is general EC2 info you want to add, I'm happy to help out
<mdz> smoser: did it work?
<Keybuk> slangasek: gssd.cof "start on local-filesystems and started portmap and (mount OPTIONS=*krb5*...) etc.
<Keybuk> slangasek: statd is the tricky one
<smoser> mdz, yes. bug 447325
<ubottu> Launchpad bug 447325 in apport "testing a ubuntu-bug report on ec2" [Undecided,Invalid] https://launchpad.net/bugs/447325
<smoser> was created. and has the ec2 info
<Keybuk> slangasek: one way would be to have in statd.conf "start on started portmap or mount TYPE=nfs"
<mdz> smoser: if you want to make any changes or see how it works, grab lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu and look in data/general-hooks/ubuntu.py
<smoser> thanks.
<Keybuk> slangasek: but then you'd need in portmap.conf "start on local-filesystems and (net-device-up IFACE=lo or starting statd)
<Keybuk> but I'm not sure that works :)
<lamont> why does karmic not see my thumbdrive when I plug it in?
<mdz> smoser: it looks at the AMI to check if it is EC2 or UEC presently; you might want to update it to use your script
<leszek> lamont, karmic switched from hal to devickit to handle hardware just like your thumbdrive, which one is it ?
<smoser> mdz, the only issue with looking just doing a blind grab for http://169... is that could be firewalled off or some other issue that made for long timeout
<smoser> thats why i was thinking best to check somethign else first.  its also possible that such a seemingly arbitrary http request could have other negative effects (although i can't really think of many)
<cjwatson> lamont: your autotest bugs don't consistently seem to have version numbers in them (e.g. bug 445578)
<ubottu> Launchpad bug 445578 in libspectre "FTBFS: aclocal-1.10: not found" [Undecided,New] https://launchpad.net/bugs/445578
<lamont> cjwatson: call it more consistenly don't have them.
<cjwatson> could that be changed? :)
<lamont> I suppose
<lamont> http://paste.ubuntu.com/289372/
<lamont> you need me to go fix all the bugs there?
<mdz> smoser: is it good enough for 9.10?
<cjwatson> lamont: only if you have time
<cjwatson> having the list *somewhere* will do for now ...
<lamont> cjwatson: the autotest mailing list got copys of all the failed builds
<lamont> including > 2000 from powerpc.. :(
<lamont> thnaks
<cjwatson> lamont: *nod*
<mdz> smoser: we will probably want to reconsider tagging the bugs ec2-images in the long run
<slytherin> cjwatson: I tried doing more investigation in oversized CD images. Didn't find anything useful. Surprisingly there is only one file different between powerpc and ps3 image. Yet powerpc image is oversized and ps3 is not.
<smoser> i see you've got the package check for ec2-init. i think this is definitely fine for karmic.
<smoser> james_w, i think that 'bzr branch lp:ubuntu/apport/karmic' is not up to date with package state of apport in karmic
<james_w> smoser: please use lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu for appport
<james_w> we're /almost/ at the point where you won't have to be aware of that
<Keybuk> cjwatson: hah!
<Keybuk> it so *is* documented
<Keybuk> from init(5)
<Keybuk> well, kinda
<Keybuk> I think I document the "start" one ;)
<smoser> james_w, fair enough. i'll be happy when you're there.
<cjwatson> Keybuk: aha. I expected to find it in initctl(8)
<Keybuk> cjwatson: it probably should be mentioned there
<Keybuk> but initctl is used by sysadmins
<Keybuk> that trick is for config authors
<lifeless> has anyone observed an error about lsb_release.py when python packages are upraded?
<ion> Yeah, iâve been ignoring it.
<mdz> smoser: use debcheckout and you don't have to think about where the branch is
<lamont> interestingly, unplugging the thumbdrive and reinserting it made things work.  do.not.want.to.know
<smoser> mdz, thanks. was unawre.
<ScottK> lamont: What's the status on maven bootstrapping?
<lamont> ScottK: broken last I looked at it, buried behind other things atm
<lamont> as in it was FTBFS when I tried, big time
<lamont> doko was looking into it
<ScottK> OK.
<ScottK> I just approved another FFe for maven stuff, so maybe now ....
<doko__> lamont, ScottK: pending, waiting for syncs
<ScottK> OK.
<ScottK> doko__: Is it just 444714 you are waiting on or is there more?
* lamont changed the topic of #ubuntu-devel to: ppa rolling outage | Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<lamont> sorry 'bout that
<doko__> ScottK: 443292 has the references for the bugs, although there might be still some missing, if these introduce new deps
<ScottK> Thanks.
<doko__> and it will get worse for lucid because packages in unstable have maven b-d's which are in karmic main :-/
<robbiew> Keybuk: cjwatson: if my machine requires an fsck, should I be notified by usplash?  I just ran into this, and the system basically hung at usplash and then went blank.  I couldn't switch VTs, however a CTRL-ALT-DEL rebooted.  I booted into recovery mode, was prompted to run fsck, and rebooted fine.
<cjwatson> robbiew: yes, you should
<robbiew> :/
<cjwatson> sounds like a definite usplash bug
<cjwatson> I'll try to arrange to trigger it here and debug
<billybigrigger> anyone had any problems with the dailies lately?
<billybigrigger> im going to go ahead with a clean install
<billybigrigger> wrong chan
<billybigrigger> :P
<slangasek> Keybuk: so is it mountall that emits 'mount'?
<Keybuk> slangasek: yes
<robbiew> cjwatson: fyi - that filesystem failure apparently occurred in the middle of a dist-upgrade...so it could have been a fluke thing.
<slangasek> Keybuk: in which case, to support noauto mounts, I think what we really want is start on local-filesystems *or* mount TYPE=nfs4, no?
<ion> 5. enter root pass and watch a CRAP
<ion> Bug reports â¥
<evand> bryce: was the live CD portion of BulletProofX ever implemented?
<bryce> evand, nope
<evand> Is there a technical reason for this, or has it been a matter of insufficient time?
<evand> Do you know offhand if there's a bug number for it somewhere?
<bryce> evand, mostly it is just lack of time, however I think the recent gdm2 rewrite may have broken it entirely (haven't had a chance to check)
<bryce> evand, I don't anyone filed one on the feature, but it belongs to the 'xorg' package
<billybigrigger> any known problems with the today's daily cd?
<billybigrigger> i booted up the disc, into the install menu, then it complained about it couldn't mount my cdrom
<ScottK> billybigrigger: Sure.  Look at ll the open bugs in Launchpad
<ScottK> billybigrigger: Help for Karmic is in #ubuntu+1
<ScottK> slangasek: I'm a little confused by your changes on Bug 419839.  I know, for example, for Quassel that there isn't a fix committed.  I don't  know if there is actually anything that needs doing.
<ubottu> Launchpad bug 419839 in kdepim "Ensure proper usage of icons in the messaging menu" [Medium,Fix committed] https://launchpad.net/bugs/419839
<evand> bryce: thanks for the pointers, I've moved bug 433951 over to xorg.
<ubottu> Launchpad bug 433951 in xorg "Ubuntu Installer Exits When Monitor Cannot Be Identified" [Undecided,New] https://launchpad.net/bugs/433951
<dtchen> evand: i'm happy to file a bug about the usb-creator symptom i'm describing (just lacked time and wanted to check first if you were aware): if there is larger-sized removable media, e.g., dvd, (un)mounted when i attempt to use usb-creator to write an iso to a thumb drive, i'm unable to choose the iso as the source
<evand> dtchen: I'm slightly confused.  Exactly what happens when you try to select an ISO?
<rgreening> dtchen: can you confirm if that happens for the usb-creator-kde too? or just the gtk? (I expect both....)
<rgreening> :)
<dtchen> rgreening: it occurs for both frontends.
<LaserJock> where do people go to report bugs against the .isos? like problems with seeds or the build process itself and is it possible to file a bug against a non-Ubuntu distro? like Kubuntu, etc.
<dtchen> evand: ok, use case is: i have an unmounted dvd in the drive. i open usb-creator, select the unr daily iso, and attempt to write it to a 2 GB usb thumb drive. usb-creator tells me that it can't write to the thumb drive because the destination lacks sufficient space.
<ScottK> LaserJock: Most of the seed type bugs seem to get filed against *-meta.
<dtchen> evand: in fact, whether the dvd is mounted is irrelevant, since i need to remove the disc from the drive to prevent it from being chosen as the source in usb-creator
<evand> dtchen: I'm just not seeing how the DVD has any bearing on usb-creator.
<LaserJock> ScottK: I noticed that, even when they aren't for packages that are built from -meta
<evand> dtchen: can you not just press the other button and select an ISO?  Or are you saying even if you do that, internally usb-creator is still using the DVD image, and removing the DVD disc from the drive causes the problem to disappear?
 * rgreening tries to duplicate here
<dtchen> evand: the latter. selecting the desired unr iso appears to do nothing.
<evand> dtchen: can you file a bug please and attach ~/.usbcreator.log
<evand> I'm assuming this is on Karmic?
<dtchen> evand: sure, will do that tonight. yes, and also reproducible in trunk
<evand> dtchen: much appreciated
<slangasek> ScottK: the only thing I changed on 419839 was to target it to karmic because it was already on the desktop team's report
<ScottK> slangasek: OK.  Thanks.
<james_w> if there are two process connected with stdin/stdout pipes
<james_w> so the parent gives instructions to the child on its stdin
<james_w> and the parent writes without and explicit flush
<james_w> while the child is doing an fgets on its stdin
<james_w> is that going to cause issues?
<james_w> like say, deadlock 75% of the time (fingers crossed)
<james_w> well, 75% of the time for some people, and apparently never for most
<slangasek> writes without explicit flush, then waits for the child to take an action?
<james_w> yeah
<slangasek> yep
<james_w> the parent does:
<james_w>   write (session->child_stdin, response, response_len);
<james_w>   if (add_newline)
<james_w>     write (session->child_stdin, newline, 1);
<james_w> to pass the password down to the child, which is in the middle of a pam_authenticate session
<slangasek> you probably want an unbuffered fd there, no?
<james_w> the parent then expects the child to finish the session
<james_w> ah, let me find if it is doing that
<slangasek> right, the parent should force it either by doing unbuffered I/O, or by closing the fd after it's done with it
<cjwatson> (a) the write is not guaranteed to write everything in one go
<cjwatson> (b) fgets may not get the whole line in one go
<james_w> the child is:
<james_w>           if (fgets (buf, sizeof buf, stdin) == NULL)
<james_w>             goto error;
<slangasek> cjwatson: fgets should only give a short read if the buffer is too small?
<james_w> I can't see it setting the I/O unbuffered, g_spawn_async_with_pipes doesn't say it returns unbuffered pipes (and I'm pretty sure it doesn't), and I don't think there's a way to set unbuffered by default
<james_w> the return of write is the number of bytes written?
<slangasek> yes
<james_w> so we need that loop which handles EAGAIN as well
<james_w> I'll stick this in a PPA and ask the reporter to test
<james_w> it certainly smells fishy
<james_w> thanks for your help
<cjwatson> slangasek: if there aren't enough bytes to read right now, it'll stop
<cjwatson> so I tend to err on the side of paranoia when fgets'ing from pipes
<slangasek> cjwatson: fgets?  that's not what the manpage says (and not how I remember it's supposed to work)
<slangasek> unless by "stop" you mean "block" :)
<cjwatson> the man page says that it stops on EOF
<james_w> how can you tell that fgets hasn't?
<james_w> look for \n?
<cjwatson> what is EOF on a pipe but read-returned-0?
<cjwatson> indeed that's the *definition* of EOF
<chrisccoulson> hey slangasek
<chrisccoulson> just saw your g-s-d bug
<slangasek> cjwatson: ah, hmm
<chrisccoulson> GDB probably can't find the gdk_x_error symbol, because the GDK stuff hasn't been loaded yet
<chrisccoulson> (it's in a module that loads after it starts)
<slangasek> chrisccoulson: this is the case even if I attach to a running process
<chrisccoulson> hmmm:/
<slangasek> chrisccoulson: oh; but this time, it worked
<chrisccoulson> excellent:)
<slangasek> apparently it wasn't long enough after startup before
<slangasek> ok, let me go break it
<chrisccoulson> i was going to ask if you could edit the desktop file and add the --sync option, so apport gets it
<chrisccoulson> but it doesn't matter now if its working
<james_w> what's the flush() call to go with write()?
<slangasek> well shit, that's no good
<slangasek> I broke X instead
<chrisccoulson> in what way?
<chrisccoulson> if it's frozen when GDB breaks, then that sometimes happens when debugging X errors  - i normally run GDB on a separate console from my X session
<slangasek> chrisccoulson: X segfaulted
<chrisccoulson> hmm, that's not good
<slangasek> if it had just hung, I could've killed it from vt1 :)
<slangasek> (killed gdb, that is)
<chrisccoulson> it might be best to append "--sync" to the Exec line in /etc/xdg/autostart/gnome-settings-daemon.desktop, restart your session and trigger the crash outside of GDB
<chrisccoulson> and then apport normally catches a good trace
<chrisccoulson> anyway, dinner time. bbl
<slangasek> chrisccoulson: thanks for the hints
<slangasek> bryce: hmm, and apport says nothing about this X segfault
<doko__> what kind of thing restarts couchdb all the time?
<james_w> doko__: as your user, or the system daemon?
<doko__> james_w: system daemon, stopped gdm as well
<james_w> don't know then
<lifeless> how do you make cupsys start on boot now ?
<slangasek> doko__: hmm, why do you have the system daemon installed?
<slangasek> lifeless: cupsys -> cups, and it should start by default?
<doko__> slangasek: not intentional, that's an armel babbage installation from about four weeks ago
<bryce> slangasek, unfortunately for some reason we've not sorted out, apport only catches a portion of X crashes.
<SKB> hello, i've got some sort of weird policy issue after compiling dbus. Might it be because i haven't supplied some arguments i don't know to ./configure?
<joaopinto> SKB, you were already told this is not the proper channel for such question
<joaopinto> please try #dbus
<ScottK> dtchen: I saw http://0pointer.de/blog/projects/guide-to-sound-apis mentioned on #debian-release and thought you might be interested.
<slangasek> bryce: waah.
<bryce> slangasek, you can help us fix it in dallas if you wish 8-D
<lifeless> slangasek: does not
<lifeless> slangasek: neither does exm4 or openssh
<slangasek> lifeless: then your system isn't actually booted :)
<slangasek> lifeless: something has blocked the startup before it got to starting rc
<slangasek> you only think your system is booted because we start gdm before triggering the sysvinit stuff
<slangasek> lifeless: what does 'runlevel' claim?
<lifeless> 2
<slangasek> interesting
<slangasek> lifeless: 'sudo status rc'?
<slytherin> Who is in charge of ubuntu-meta seed? gstreamer0.10-schroedinger needs to be removed from -desktop as gst-plugins-bad version that provides it is not available in karmic.
<lifeless> $ sudo status rc
<lifeless> rc stop/waiting
<MacSlow> bryce, hi there
<MacSlow> bryce, I'm trying to find the apt line for sources.list for the xorg-edgers ppa, but can't find it on the page
<bryce> hi MacSlow
<MacSlow> bryce, can you help me out?
<bryce> deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
<bryce> deb-src http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
<MacSlow> thx
<ScottK> MacSlow: Please file a bug on soyuz too.
<bryce> MacSlow, it appears the LP folks hid that information for you
<bryce> MacSlow, you click on the 'Technical details' link to see it
<MacSlow> ScottK, bryce: Ok, so then it's really not just me :) *phew*
<bryce> sounds like you could alternatively add 'ppa:xorg-edgers/ppa' to your Software Sources
<bryce> guess they hid the apt lines to make the page less cluttered or something *shrug*
 * ScottK is on vacation from filing LP bugs as it just got to frustrating to try and document what's wrong with the U/I.
<slytherin> kenvandine: It might be too late already, but is there any plan to merge gst-plugins-bad0.10 from Debian? The schroedinger plugin has moved to -bad.
<bryce> pitti are you still awake?
<MacSlow> bryce, so it is me after all *sigh*
<ScottK> MacSlow: No, it's not just you.
<slangasek> lifeless: versions of upstart and sysv-rc packages?  service ssh status?
<mathiaz> Riddell: hey - could you have a look at bug 418342?
<ubottu> Launchpad bug 418342 in mysql-dfsg-5.1 "akonadi-server prevents install of mysql-server-5.0" [Low,Fix released] https://launchpad.net/bugs/418342
<mathiaz> Riddell: it seems that the mysql-server side is set correctly now
<mathiaz> Riddell: akonadi dependencies need to be updated
<lifeless> 0.6.3-7 2.87dsf-4ubuntu8
<lifeless> slangasek: I've started ssh alterady
<lifeless> $ sudo service ssh status
<lifeless>  * sshd is running
<lifeless> slangasek: I'll check next boot to be entirely accurate about this; I know that exim4 and cups *were not* starting a few boots back, because I had to start them to email and print, respectively.
<ejat> can someone look at bug 447116
<ubottu> Launchpad bug 447116 in gnome-system-monitor "close while trying to run gnome-system-monitor" [Undecided,New] https://launchpad.net/bugs/447116
<ejat> and bug 446492
<ubottu> Launchpad bug 446492 in inkscape "crash while launching / starting inkscape (core dumped)" [Undecided,New] https://launchpad.net/bugs/446492
<slangasek> lifeless: right; definitely not reproducible here so far, so if it recurs for you we'll have to do some digging into the rc script
<ejat> thanks ..
<lifeless> slangasek: kk
<Darxus> You guys remember the days when, if your video driver failed to load, you were presented with a low resolution X using vesa or something, and asked if you wanted to reconfigure your display?
<Darxus> Currently, instead, you are presented with a flickering screen, forever.
<Darxus> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/431166
<ubottu> Launchpad bug 431166 in gdm "karmic gdm restarts X infinitely when video driver fails to load" [Low,Confirmed]
<Darxus> Can I increase the priority?  High?  Medium?
<Mez> grr... Xorg eating CPU cycles.
<Mez> it's at 100% just after loading.
<davmor2> Mez: you don't need anything else if you have bling though right
<Amaranth> Mez: intel?
<Mez> Amaranth: SiS gfx.
<Amaranth> oh
<Mez> davmor2: I don't have bling.
<Amaranth> so it's not going to be compiz related :)
<Mez> nope.
<davmor2> Mez: what no colours in you terminal?
<Mez>  1239 root      20   0  171m  32m 7568 R   99  3.7  32:57.21 Xorg
<Mez> :'(
<Mez> not good.
<Mez> Only after an update too.
<Darxus> There's a bug open to package something packaged on debian-multimedia.org.  Is there a way to sync from that archive, or should I grab the source, rebuild the source package, and upload it to my ppa?
<Mez> wtf? It didn't even update the driver I'm using.
<Mez> disable glx + dri2 - normal usage again
 * Amaranth wonders how Mez even has DRI2
<fagan> Any software center devels around? Im looking to squash a bug and I want someone to point me to where the apt stuff is handled. Its for https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/438870
<Mez> Amaranth: me too... it was in my xorg.conf tho
<ubottu> Launchpad bug 438870 in software-center "Downloads should start when the previous one ends" [Wishlist,Confirmed]
<Amaranth> fagan: Looks like mvo isn't here, you'll have to try to find him again on monday
<fagan> Ah ok
<davmor2> Mez: would that coincide with the xorg update?
<kristianpaul> hello
<kristianpaul> last ubuntu version how % of debian sid is ?
<Darxus> How do I include the .orig.tar.gz in an upload to launchpad / ppa?
<Darxus> It's a new package.
<Darxus> Think I found the answer.
<cjwatson> Darxus: build with the -sa option
<Darxus> Yeah, thanks.
<Darxus> So is it possible to sync from debian-multimedia.org archives?
<cjwatson> Darxus: yes, on request
<aweisberg> Does anyone know why the libc6-dbg package now (changed 8.04 between 9.04) puts libc.so in /usr/lib/debug/lib and no longer works with LD_LIBRARY_PATH=/usr/lib/debug? I see the description of the packaged was also changed to no longer mention using LD_LIBRARY_PATH.
<Darxus> cjwatson: Awesome.  After I test this, and lucid opens, I'll do a sync request.
<slogg_k> Hi
<slogg_k> this may be the wrong place to ask, but I'm new to lower level X programming and I was hoping someone could point me in the right direction --
<slogg_k> I would like to write a simple program that will let me swap axes on my touchpad input.
<lfaraone> pitti: if I wanted to patch in the functionality described in bug 357847, would I want to put it in as a symptom in apport-symptoms, or would I want to add the functionality to ubuntu-bug in apport?
<ubottu> Launchpad bug 357847 in apport "ubuntu-bug wish: allow to just point at the window of a buggy application" [Wishlist,Triaged] https://launchpad.net/bugs/357847
<johanbr> slogg_k, try #xorg
<slogg_k> okay, thnks for redirect.
* lamont` changed the topic of #ubuntu-devel to: Ubuntu 9.10 Beta released! | Archive: frozen briefly for armel toolchain massaging; FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* slangasek changed the topic of #ubuntu-devel to: Ubuntu 9.10 Beta released! | Archive: FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<directhex> i'm a terrible human being. can archive-admin absolve me of my sins?
<slangasek> so, will this change to nfs-utils fix the race conditions, or will it deadlock my boot horribly...
<slangasek> directhex: no, but we can give you penance
<mneptok> directhex: say 15 "hail sabdfl's" and spend 10 weeks exclusively on EFnet
<directhex> slangasek, what's the spiritual cost of accidental-NEW-upload absolution?
<slangasek> directhex: pretty sure it involves ablutions with beer
<sistpoty> haha
<directhex> slangasek, well, fly yourself to the london or banbury karmic release parties, and you can have a pint!
<sistpoty> slangasek: just drafting the mail regarding ftbfs... are ftbfs in main RC?
<slangasek> pretty sure it's cheaper to buy my own pint here. :)
<slangasek> sistpoty: en masse, yes, since they impede security support
<directhex> slangasek, that wouldn't be fine british ale, though!
<sistpoty> slangasek: ok, thanks
<slangasek> directhex: correct, it would be tasty Oregon porter
<sistpoty> slangasek: http://paste.ubuntu.com/289560/ (I've signed this on behalf of both release teams... maybe you'd like to add/correct things?)
<slangasek> sistpoty: "that karmic will not release until the build failures in main have..." uh - we'll release on schedule, the only question is how bad of a week we have before that :)
<sistpoty> slangasek: that's why I asked if a FTBFS is RC... being not a native speaker doesn't help to transform your answer in a good text :P
<slangasek> sistpoty: how about "the number of build failures in main definitely needs to be brought *way* down from its current level before we release at the end of the month"?
<sistpoty> slangasek: thanks! sounds great!
<sistpoty> slangasek, ScottK: http://paste.ubuntu.com/289566/
<slangasek> sistpoty: looks good to me
<slangasek> hrm, do we no longer get an apt term.log now with aptd?
<billybigrigger> anyone working on vdpau in karmic?
<billybigrigger> is it supported in ubuntu yet?
<sistpoty> slangasek: do you want to send it out? might have a bigger impact on core-devs than coming from a motu ;)
<ScottK> sistpoty: Looks good to me
<sistpoty> thanks ScottK
<slangasek> sistpoty: hmm, I fundamentally disagree that this *should* be the case (heh, I don't think I knew you weren't core-dev), but if you want to have me send it, ok - can you bounce it to me in email so I can just re-send?
<slangasek> oh, there's my term.log; apparently it's hella-buffered
<sistpoty> slangasek: well, I'm a core-dev nowadays, but mainly active in universe... ;) will send it to you
<slangasek> sistpoty: ok, thanks!
<sistpoty> slangasek: sent
<sistpoty> (unless my kmail is going insane again)
<sebner> sistpoty: it's kde .. what do you expect :P
<sistpoty> sebner: it's worth than that... for undisclosed reasons this is lenny's kde running remote via ssh *and* having it's homedir on nfs :P
<sebner> sistpoty: EPIC FAIL. That can't work :P
<smoser> james_w, or anyone who might know
<smoser> for some reason:
<smoser> bzr+ssh://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/
<smoser> != http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<directhex> billybigrigger, it's packaged. why?
<slangasek> smoser: because codehosting is having problems staying in sync :/
<slangasek> cjwatson: do you have an overview of the latest mountall upload?
<slangasek> it appears the latest changes there now cause my system to deadlock on boot, while bringing up lo
<billybigrigger> directhex, ok, so what players support it?
<billybigrigger> directhex, i see i have nvidia-185-libvdpau:
<billybigrigger>   Installed: 185.18.36-0ubuntu4 on a fresh install by default
<billybigrigger> but as far as my reading goes, i see it's not supported in vlc, and i have to compile it in with mplayer? it doesn't come built in ubuntu's mplayer package correct?
<directhex> billybigrigger, that might be the case. siretart?
<Amaranth> last time I checked, yeah
<Amaranth> latest gstreamer apparently has support for it but we don't have that either
<billybigrigger> so the api is there, but no players have support for it yet? :P
<Trewas> one problem with vdpau is probably that it requires compiling packages against specific version of the driver, all of them have separate -dev packages
<Darxus> Oh, what about vdpau?
<Darxus> The mplayer package was updated to support it.
<billybigrigger> ?
<billybigrigger> mplayer:
<billybigrigger>   Installed: 2:1.0~rc3+svn20090426-1ubuntu9
<Darxus> It should be whatever's in karmic.
<cjwatson> slangasek: only what I can see in bzr
<slangasek> cjwatson: ok
<Darxus> billybigrigger: I'm looking for the bug to confirm the version.
<billybigrigger> well it must not be enabled by default
<billybigrigger> gmplayer gives me ~%43 cpu usage
<billybigrigger> where as vlc on the same video file is around 30
<Darxus> billybigrigger: Yeah, hold on...
<billybigrigger> np
<sistpoty> billybigrigger: is vdpau the nvidia decoding support?
<Darxus> $ cat ~/.mplayer/config
<Darxus> vo=vdpau,gl2,
<Darxus> vc=ffh264vdpau,ffmpeg12vdpau,
<billybigrigger> i can see vdpau as an available driver in mplayer, but i can't configure it, or no way of "selecting" it
<Darxus> sistpoty: Yes.
<billybigrigger> sistpoty, yes
<Darxus> billybigrigger: The way to do it on the commandline is -vo vdpau.
<sistpoty> billybigrigger: hm... I'm not entirely sure that's working yet (too bad I don't recall exactly what siretart told my last week, since I've switched to ati recently)
<sistpoty> billybigrigger: anyways he's got the answers ;)
<Darxus> mplayer (2:1.0~rc3+svn20090426-1ubuntu7) karmic; urgency=low
<Darxus>   * enable VDPAU on i386 and amd64 (LP: #437039)
<billybigrigger> could not initialize video filters -vf or video output -vo
<marcty_> can someone help me troubleshoot nfs? everything was working fine, dont know what changed, but I cant mount my nfs share. host/client can both communicate, but the mount request just hangs forever.. i see this on the client after a long while: nfs: server filer-1 not responding, timed out
<billybigrigger> mplayer -vo vdpau INPUT works great
<billybigrigger> %4 cpu
<billybigrigger> adding those options to ~/.mplayer/config cause it to crash on startup
<Darxus> Huh.
<marcty_> nothing on the server except it shows aauthenticated mount request
<marcty_> Oct  9 15:29:12 DAT-001 mountd[10503]: authenticated mount request from ....
<marcty_> thats all I seeee
<billybigrigger> Darxus, running mplayer with -vo vdpau works
<billybigrigger> can't get mplayer gui to work with it though
<Darxus> billybigrigger: Cool.
<Darxus> I don't know if I've ever seen the mplayer gui :)
<billybigrigger> hmm
<billybigrigger> seems the gui doesn't read ~/.mplayer/config?
<slangasek> oh, geez
<slangasek> why is "/srv" listed as a required FHS filesystem? :P
#ubuntu-devel 2009-10-10
<dtchen> ScottK: indeed, i've been linking to it in my presentations ever since lennart first mentioned it
<sistpoty> Riddell: mind taking a look at the FFe bug #419465 (haven't heard feedback from vorian since some time)
<ubottu> Launchpad bug 419465 in plasma-widget-fancytasks "New upstream release plasma-widget-fancytasks 0.9.8" [Wishlist,New] https://launchpad.net/bugs/419465
<sistpoty> Riddell: likewise for bug #432725
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/432725/+text)
<slangasek> lifeless: any NFS filesystems in your /etc/fstab?
<superm1> pitti, we're still not getting good retraces: https://bugs.edge.launchpad.net/ubuntu/+source/mythtv/+bug/447513
<ubottu> Launchpad bug 447513 in mythtv "mythfrontend.real crashed with SIGSEGV in sws_scale()" [Undecided,New]
<superm1> er well this one doesn't have a coredump
<superm1> bad example i guess
<happyaron> can anybody have a look at bug 445211 and bug 445217 (pitti approved them)
<ubottu> Launchpad bug 445211 in ibus-m17n "[freeze exception]sync ibus-m17n 1.2.0.20090930-1 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/445211
<ubottu> Launchpad bug 445217 in ibus "[freeze exception]please sync ibus 1.2.0.20090927-2 from Debian" [Undecided,Confirmed] https://launchpad.net/bugs/445217
<lifeless> slangasek: nope
<fale> I'm uploading a package on the ppa, but it says: "Uploading boost1.40_1.40.0-2ubuntu0.tar.gz: 38856k/38857k" since ~30 minutes ago :(
<fale> what's wrong?
<wgrant> fale: That's sometimes a router problem, sometimes a server problem, but mostly a question for #launchpad.
<fale> wgrant: thankyou
<slangasek> lifeless: any remote filesystems of any sort?  Are there any 'mountall' processes hanging around, and did the problem end up being reproducible?
<joaopinto> erm, /var/lib/dpkg/lock is becoming unexpectedly locked after apt-get installs, anyone experienced this ?
<Phurl> here is a new tool I made to upload translation strings to launchpad http://fmtyewtk.blogspot.com/2009/10/launchpadupload-launchpad-translation.html
<lamont> keybuk: about?
<lamont> keybuk/slangasek: wondering which of the changes in util-linux 2.16-1ubuntu4 I want for debian, and which are ubuntu-specific
<happyaron> can anyone sync ibus/ibus-m17n, it has been approved several days
<unimatrix> are there any plans to make update manager able to check for updates without inputing the password?
<unimatrix> should i report that as a bug?
<mdke> unimatrix: it does that in karmic now, doesn't it?
<unimatrix> mdke: it used to! but now it's back to the old way again
<sebner> doko_: bdrung : It seems to be that the last eclipse upload b0rked it
<darkham> some artwork change until the 29?
<bdrung> sebner: please remove ~/.eclipse
<bdrung> and try again
<sebner> bdrung: ah, shame on me. fixed it. thanks :)
<bdrung> sebner: i dunno why it crashed, but the workaround is easy
<sebner> bdrung: yeah, shouldn't be though
<sebner> ok now eclipse crashed xd
<bdrung> ?
<sebner> bdrung: dunno, scrolled up and down, switched back to xchat and then is died
<bdrung> sebner: do you have a crashlog?
<sebner> bdrung: http://paste.ubuntu.com/290121/
<bdrung> sebner: LD_LIBRARY_PATH=/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client:/usr/lib/jvm/java-6-openjdk/jre/lib/i386:/usr/lib/xulrunner-1.9.0.14:/usr/lib/xulrunner-devel-1.9.1.3:/usr/lib/xulrunner-devel-1.9.1.3 does not look good
<bdrung> sebner: we currently use a workaround for detecting xulrunner
<sebner> bdrung: can't reproduce it though
<bdrung> sebner: can you remove xulrunner-1.9?
<sebner> bdrung: done
<bdrung> sebner: please file a bug report if you experience the bug again (and if you can reproduce it). thanks
<sebner> bdrung: will do, thx for your help
<bdrung> np
<bdrung> sebner: you can join #eclipse-linux if you want to talk to all eclipse packagers
<sebner> bdrung: something like "Uhhh thanks for updating" ;) , nahh you are doing great work. I don't have a problem to use upstream binary or Netbeans though
<bdrung> thanks. the eclipse package is not the easiest
<bluefoxicy> that's interesting
<bluefoxicy> ifI have 2 AIM accounts, pidgin forgets about buddies on the first when I sign into the second, and fails to display them.
<unimatrix> bluefoxicy: pidgin is hopeless, i'm glad they've switched to empathy
<bluefoxicy> eh
<bluefoxicy> I find empathy's UI remniscent of the playtoy shit I had on Mandrake 6
<directhex> both suck. move your friends to irc
<unimatrix> irc sucks just as much :)
<bluefoxicy> heh empathy looks like crap AND it doesn't have any obvious option to put tabs on the side
<bluefoxicy> that won't work
<bluefoxicy> I have 27 tabs open in one window
<unimatrix> the obvious workaround is to reduce the amount of your friends then
<slangasek> lamont: ehm... I think you want approximately none of them at this point, almost all of those changes are upstart-only and the remainder are probably hard to pick out
<Darxus> Does it ever get easier to remember ot upload the source package instead of the binary?
<Darxus> It would be nice if dput caught that.
<jdong> what's the best way in Python to execute a .desktop file?
<lamont> slangasek: kernel timezone for vfat love?
 * lamont afk
<slangasek> lamont: oh, if that's in there, I guess you want it :)
#ubuntu-devel 2009-10-11
<lifeless> slangasek: EUNKNOWN for now
<lifeless> slangasek: I'll track it
<jono> james_w, ping?
<james_w> hey jono
<jono> james_w, hey, is USB Creator pretty buggy right now? every time I plug my USB stick in it says the device needs to be formatted, and I have formatted it a bunch of times already
<jono> when click the Format button it doesnt format it
<james_w> you formatted it as fat32, or something else?
<jono> ext3
<renatokrause> Good night,
<renatokrause> My name is Renato and I'm Brazilian. I'm a developer for several years I am very interested in contributing to the development of Ubuntu. I wonder if anyone can help me on that interest. It would be very useful some indication of reading. I work with forensics and notice that both in Debian and Ubuntu packages are missing some good for the forensic work.
<renatokrause> Thank you very much.
<slangasek> lifeless: ok; am keen to not release with such a bug, so please do and let me know :)
<slangasek> renatokrause: you may want to have a look at https://wiki.ubuntu.com/ContributeToUbuntu as a starting point
<renatokrause> slangasek: I'm part of the Brazilian forum of Ubuntu and perform translations for Brazilian Portuguese through Rosetta. However I would like to contribute to forensic packages for both distributions that use daily: Ubuntu and Debian.
<renatokrause> slangasek: I could send someone to the packages that I have just managing to myself?
<slangasek> renatokrause: that page includes pointers on getting involved with package maintenance in Ubuntu ("Maintaining Ubuntu")
<engla> renatokrause: and for Debian perhaps this can help http://mentors.debian.net/
<renatokrause> slangasek, engla: thank very much
<lifeless> slangasek: I have another bug to file; a rather more severe one with graphics ;)
<lifeless> slangasek: but I just got of a plane, I'll probably gather data and file tomorrow morning
<slangasek> lifeless: ok
<lifeless> slangasek: suspend resume and colours come back borked; lockups etc.
<slangasek> lifeless: is this newly upgraded to karmic?
<lifeless> slangasek: no
<slangasek> huh
<lifeless> oh, also odd flickering of the screen, like th entire image when black for a single grame
<lifeless> *frame*
<lifeless> slangasek: I've been tracking karmic for a few months
<slangasek> I'm not aware of any changes to suspend/resume support recently that should affect that
<slangasek> (unless you have a very strange race condition between your video and hdparm)
<lifeless> slangasek: I'm assuming its the intel driver update from thursday
<slangasek> oh, ok
<Darxus> When I delete a package from a ppa, will it eventually let me upload that package again with the same version?
<Darxus> Is the problem the time it takes to delete, or some version enforcement?
<nixternal> Darxus: it should eventually...didn't think it took that long in the past
<Darxus> nixternal: I don't know how long it takes, it never occurred to me to wait at all before.
<Darxus> Thanks.
<wgrant> Darxus: It will never let you upload the same version again.
<Darxus> wgrant: Thanks.
<Darxus> That's very unfortunate.
<wgrant> And while you can upload an older version eventually, it is strongly discouraged.
<wgrant> Why?
<Darxus> I'm going to have to rebuild my patched version of the linux package just to match the version dependancies of the linux-meta package :/
<wgrant> It's different => it's not the same version => it should have a different version number
<Darxus> Not that unfortunate in the grand scheme of things.
<Darxus> Yeah, I understand the logic.
<Darxus> But I'm also confident nobody has downloaded the broken package.
<wgrant> Why does linux-meta have such strict dependencies?
<wgrant> Hm, it does seem to. How odd.
<Darxus> wgrant: It's just the way the package builds, it requires kernel packages with an exactly matching version.
<nixternal> wgrant: didn't it used to?
<Darxus> Nah, it makes sense.  That's what it's there for - depending on current versions of related packages.
<wgrant> Darxus: Wait, it only depends on the same ABI.
<Darxus> Ohhh.
<wgrant> Darxus: It doesn't depend on the same revision.
<Darxus> Right, thanks.
<Darxus> A lot :)
<Darxus> I hate waiting for the kernel to rebuild.
<wgrant> Darxus: the metapackages (linux, linux-image, linux-image-generic) depend on the precise versions of each other.
<Darxus> Makes sense.
<wgrant> But linux-image-generic only depends on linux-image-2.6.31-12-generic - no particular version.
<Darxus> Right.
<Darxus> Also makes sense.
<wgrant> nixternal: I don't believe so.
<nixternal> I thought it did...though I don't use PPAs much
 * wgrant checks the code.
<Darxus> Heh.
<wgrant> nixternal: It doesn't look like it ever allowed that.
<wgrant> And it certainly doesn't now.
<Darxus> Sweet!  Dependancies resolved.
<wgrant> Great.
<Darxus> Hopefully the next linux source package increments the version more than two so I can match it again :/
<Darxus> Er, at least two.
<Darxus> I suppose I could ask.
<wgrant> Why are you using an identical version?
<Darxus> Because I'm just creating a patched copy of the linux source package, called linux-bfs.  Just nicer for them to match.
<Darxus> I'm adding bfs1 to the abi, and don't mind incrementing that.
<wgrant> Ah.
<wgrant> As long as you have that in there somewhere.
 * jdong wishes the scheduler were pluggable :)
<Darxus> wgrant: Well, it's in the source and all binary package names.
<Darxus> The renaming was a pain.
<wgrant> There's already linux-rt, linux-ports... surely it wasn't that hard?
<Darxus> Heh.
<Darxus> I haven't looked at linux ports, but linux-rt is just a single image package.  linux builds a bunch.
<Darxus> Ah, yeah... doing something with linux-ports-source would've been a lot easier, but less thorough.
<Darxus> And I have delusions of this patch eventually getting applied to the linux source package in main :)
<lifeless> slangasek: its reproducible
<lifeless> slangasek: even screen-cleanup isn't running.
<lifeless> slangasek: is there a log that will show what script is blocked? [I suspect I know... - its the full disc encryption task being a muppet]
<slangasek> lifeless: no, early boot logging is hard; but if you can post your fstab and your crypttab, we might be able to make sense of that (and link it to one of the existing bug reports)
<hyperair> hmm it would be nice if the /var/run/reboot-required file contained the name of the package which requested its reboot
<dvoid> anyone here working on the new software store system ?
<Darxus> Wow, the kernel bug list is scary:  http://qa.ubuntu.com/reports/ogasawara/kernel-buglist.html
<Darxus> I guess that makes it easier to understand the size of the diff against upstream.
<dvoid> im trying to find some one to contact about the appstore system?
<wgrant> dvoid: Just ask here, and someone will answer if they know.
<dvoid> ubuntus webpage lacks email addresses :(
<wgrant> Personal email is very probably not a useful medium;
<dvoid> well , does anyone know who do contact about commercial software in the appstore?
<dvoid> im a developer and i want my software in there when its ready
<Darxus> Is appstore any more than a rumour?
<Nafallo> are you referring to 'ubuntu software center' by any chance?
<dvoid> yes yes
<dvoid> theres talk about support for commercial software in the future
<Darxus> This is it:  https://wiki.ubuntu.com/AppCenter
<dvoid> m
<Darxus> It got renamed Software Center, yes.
<dvoid> ;)
<Darxus> "in version 3, it will offer commercial software."
<Darxus> Version 1 starts in Karmic.
<Darxus> dvoid: You may have a while to wait.
<dvoid> yea
<Darxus> dvoid: At the top of that page it says it was created by MatthewPaulThomas, which is a link.  Did you try clicking it?
<dvoid> yea im about to send an email to him......if i cant find anyone else
<Darxus> dvoid: What software are you selling?
<dvoid> games
<Darxus> Why do you want to find someone else?
<dvoid> dont know if he's the man to talk to :)
<dvoid> but i guess ill give him a call
<Darxus> dvoid: "October 2010: 3. Provide the ability to purchase software from within the Center."
<dvoid> bah..like 1year away :S
<Darxus> - https://wiki.ubuntu.com/SoftwareCenter#October%202010
<Darxus> 06:26AM < Darxus> dvoid: You may have a while to wait.
<dvoid> well well, it would be nice to have everything ready the day it launches ;)
<Darxus> dvoid: Please read more of that page before contacting anybody.
<dvoid> Darxus, yea, doing it
<Darxus> Integrating sales into Ubuntu sounds terrible to me.
<Darxus> Heh, the version of software center in Karmic (the release currently in beta, being released on the 29th) is 0.5.0.
<dvoid> biggest problem i see is...ubuntu only
<Darxus> dvoid: What do you mean?
<Darxus> Oh, you're only selling to ubuntu users.
<Darxus> Yeah, I have no sympathy.
<Darxus> dvoid: Why wait for this feature to sell your software?
<dvoid> yea..im currently not a ubuntu user. prefer opensuse, so for me a commercial appstore for linux , that only works on ubuntu is kind of a fail
<dvoid> Darxus, not saying im going to wait for it. im just saying i want to use it
<Darxus> Your perspective is weird.  Nothing is preventing you from selling to users of every distro and operating system and distro right now, and ubuntu is planning to offer you an easier way to sell to their users, and you're complaining.
<Darxus> I also honestly don't understand why anybody uses anything but Ubuntu, but variety is clearly healthy, so keep it up.
<dvoid> lol
<penguin42> has  a change to way non-root partitions are fsck'd and mounted happened in the last few weeks?
 * penguin42 has just seen something where a partition wasn't mounted by the time I got to a desktop; but then mounted itself a bit later
<taavikko> Does someone think that the following is a bug?: install adblock-plus, launch guest-session, open firefox (in guest-session) firefox opens a tab containing the filter subscriptions...
<penguin42> taavikko: Those sound like private data to me
<tgpraveen> bug
<tgpraveen> file it
<taavikko> no it isn't, since on the original user the subscriptions are already made. quest-session just shows the tab, where you could add one
<penguin42> oh, it doesn't show the actual subscriptions?
<taavikko> nope, just the tab, where you could add one, it's just a usability issue
<penguin42> oh
<taavikko> sorry, my bad explanation :)
<blueyed> How can I log the output of mountall during boot? "exec mountall --daemon $force_fsck $fsck_fix $tmptime &> /tmp/mountall-debug" .. well,  /tmp will not exist..
<blueyed> It's a pity that /var/log/boot does not work..
<taavikko> tgpraveen: do you still this should be filed? and if yes, against what?
<tgpraveen> taavikko: yeah if personal data is not revealed ie the usr's subscriptions then don't file a bug
<taavikko> ok, thanks. still a bit of usability issue remains..
<cjwatson> blueyed: my usual trick is to observe that /dev/.initramfs/ is writable
<blueyed> cjwatson: thanks. do you think that my redirect mentioned above might work then, or could it break mountall altogether?
<cjwatson> blueyed: it should work but you have a bashism
<cjwatson> &> won't work here
<blueyed> ah, ok, thanks!
<cjwatson> you need >/dev/.initramfs/mountall-debug 2>&1
<ion> also add --debug
 * penguin42 wonders if it's mountall which was responsible for not mounting my other partition
<blueyed> ion: That might help, yes. Thanks. Hopefully I will have logs the next time.
<blueyed> penguin42: likely
<penguin42> blueeyed: Is there anything that documents it ?
<penguin42> ah yes I'm seeing this  https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/439604
<ubottu> Ubuntu bug 439604 in mountall "boot process isn't paused while fsck runs on partition: boot process is completed with fsck running in the background preventing partition from mounting" [Low,Triaged]
<ion> The screen is blank for 15â20 seconds between usplash disappearing and xsplash appearing on my quite new laptop. I wonder what can be done about it?
<cjwatson> ion: yes, I commented on that in at least one bug somewhere - gdm seems to be scratching its nose for those 15-20 seconds rather than starting X
<cjwatson> ion: either we figure out why gdm is being so inefficient (or maybe sreadahead is eating all the I/O or something?), or we move the emission of the starting-dm event to inside gdm itself rather than in its upstart job
<penguin42> the startup scripts for the X session are quite large and complex , but 15seconds is a bit heavy
<cjwatson> ion: at the moment there's no way to get rid of the blank screen there entirely, but we can shrink the window
<ion> cjwatson: That happens with sreadahead disabled as well. Incidentally, disabling sreadahead makes my system boot 5.5 seconds faster.
<cjwatson> penguin42: the X session starts after the X server
<cjwatson> so that's not really relevant I think
<cjwatson> there's quite a large gap here before the X server even starts
<ion> (I mentioned the sreadahead slowdown in bug #432089.)
<ubottu> Launchpad bug 432089 in sreadahead "performs poorly on slow HDD" [High,Triaged] https://launchpad.net/bugs/432089
<chrisccoulson> is anyone here having difficulty connecting to upload.ubuntu.com?
<james_w> yes
<james_w> ping is ok, but ftp not it seems
<chrisccoulson> ah, so it's not just me then:)
<chrisccoulson> thanks!
<james_w> well, I tested when you asked
<elmo> try now
<chrisccoulson> elmo - yup, working now:)
<Darxus> There was a bug reported today (now resolved), and I subscribed the guy who recently merged the package against which the bug was reported.  Was it appropriate of me to subscribe him to the bug?
<crypt-0> Darxus, im filing my crypto bug
<Darxus> crypt-0: Do I know what you're talking about?
<crypt-0> alt nick : dave---
<crypt-0> i want to improve the default crypto installer
<Darxus> Oh, right.
<Darxus> Cool.
<Darxus> Gimme the number when it's submitted.
<Darxus> (Just so I can subscribe.)
<crypt-0> the old cryptsetup can only hash passwords with SHA1, which is belied to be quite insecure
<crypt-0> the new one , will be able to hash with any hash supported by libgcrypt
<Darxus> Cool.
<crypt-0> such as SHA256, SHA512, and Whirlpool
<crypt-0> it is still a release candidate, but i have tested it THOROUGHLY on Juanty
<crypt-0> also,
<Darxus> Right, I was going to ask to confirm you were the guy who wanted something important replaced with a release candidate :)
<crypt-0>     * Adds luksSuspend (freeze device and wipe key) and luksResume (with provided passphrase).
<crypt-0>     luksSuspend wipe encryption key in kernel memory and set device to suspend (blocking all IO) state. This option can be used for situations when you need temporary wipe encryption key (like suspend to RAM etc.) Please read man page for more information.
<crypt-0> Darxus, yes, but if it is well tested by the dev team , it should be no problem
<crypt-0> as i mentioned, if it gets "mainstreamed" into ubuntu it wont be a Release Candidate for long
<Darxus> Hehe, yes, I remember.
<crypt-0> So you will not include a release candidate in the repos?
<Darxus> I have no say.  And I won't suggest that it be refused.
<crypt-0> i think the potential bugs highly outweigh the the usage of SHA1
<Darxus> I think that wording was poor.
<crypt-0> What should i file it under?
<Darxus> I'm not arguing with you on the appropriateness, just pointing out that it's a little scary.
<Darxus> I don't know.
<Darxus> Does it apply to more than one package?
<crypt-0> [bugs ] as in it crashes or fails to do something non-critical
<crypt-0> Darxus, No, just cryptsetup, unless you have cryptsetup packaged somehow into more than one package
<crypt-0> a recent version of  libgcrypt is recommended, but i assume that has already been upgraded
<crypt-0> (and a recent kernel, as recent (or a little older) than Juanty's kernel)
<Darxus> libgcrypt11 1.4.4-2ubuntu2
<crypt-0> but Jaunty, and karmic are more than recent enough, so that didnt even need to be mentioned :)
<Darxus> Kernel 2.6.31
<crypt-0> yes i know
<Darxus> I suspect just filing it against the cryptsetup package would be good.
<crypt-0> can you give me a url to it
<crypt-0> i dont file bugs often
<crypt-0> i usually dump the app when it segfualts and submit it
<crypt-0> or run strace on it and gz the the results of it crashing
<Darxus> Run: apport-cli cryptsetup
<Darxus> Bug reporting tool.
<crypt-0>  suspends active device (all IO operations are frozen) and wipes encryption key from kernel. Kernel  version
<crypt-0>               2.6.19 or later is required.
<crypt-0> thats the newest required kernel to do everything
<crypt-0> Juanty is already past that
<crypt-0> Darxus, in other words
<crypt-0> people can use the suspend and hibernate options on thier encrypted laptops with no fear of cold boot, however they will need the passphrase upon wakeup
<Darxus> Right.
<crypt-0> Red Hat (or maybe some other distro) , I believe has already done this according to the author of dm-crypt
<crypt-0> more than 6 months ago
<crypt-0> even if i cant get the cryptsetup upgraded, i can at least repleace the ugly defualts
<crypt-0> Darxus, does the karmic crypto installer have a write urandom to disk, and or a wipe option before encryptig?
<crypt-0> (however the urandom should be done *after* encryption)
<Darxus> No idea.
<Darxus> I'm really not who you need to convince.
<crypt-0> cant figure out how to file a bug
<crypt-0> $ apport-cli cryptsetup
<crypt-0> No pending crash reports. Try --help for more informatio
<crypt-0> because ther are no crashes , or bugs that i have found
<crypt-0> and ive reviewed the code'
<jdong> ubuntu-bug cryptsetup you mean?
<Darxus> crypt-0: Yeah, try what jdong said.
<Darxus> jdong: Why didn't apport work?
<jdong> Darxus: apport only works when something crashes and is caught
<Darxus> Weird.
<crypt-0> im filing it already
<crypt-0> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+filebug#form-start
<Darxus> So there's no way to report a bug from the commandline if there wasn't a crash?
<jdong> Darxus: no, ubuntu-bug is the command to do so
<jdong> apport has nothing to do with reporting bugs
<Darxus> jdong: Doesn't that require a gui?
<jdong> Darxus: not that I'm aware of
<Darxus> Well, ubuntu-bug is in the apport package.
<jdong> Darxus: right, ubuntu-bug forces apport to collect info
<mdz> ubuntu-bug is the part of apport which is used for reporting non-crash bugs
<dutchie> anybody mind reviewing https://code.edge.launchpad.net/~jshholland/software-center/fix-manpage/+merge/13186?
<Darxus> Huh, ubuntu-bug does work without a gui.
<crypt-0> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/448918
<ubottu> Error: This bug is private
<crypt-0> wtf
<crypt-0> the bug isnt private
<crypt-0> Darxus, can you get to : https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/448918
<ubottu> Error: This bug is private
<crypt-0> ?
<crypt-0> stfu ubottu
<tgpraveen> wtf is a private bug
<crypt-0> no idea
<crypt-0> can anyone get to it
<crypt-0> or is the bot just lame?
<dutchie> crypt-0: I can't see it
<tgpraveen> crypt-0: I can't either
<crypt-0> WTF
<tgpraveen>                                                                     Not allowed here               Sorry, you don't have permission to access this page.           You are logged in as tgpraveen.
<james_w> crypt-0: what are the tags on the bug?
<crypt-0> try again
<crypt-0> should work now
<james_w> crypt-0: it was private as you marked it as a security vulnerability
<Darxus> crypt-0: I can see it now, thanks.
<crypt-0> insecure Ubuntu crypto installer defaults ( cryptsetup )
<crypt-0> yes i know i marked it as a security vulnerability
<crypt-0> it must have marked it private by default
<Darxus> crypt-0: The "as" in james_w's sentence meant "because".
<crypt-0> i dont consider hashing a 256 bit passphrase with SHA1 secure, because #1 SHA1 is broken since 2005, and #2 SHA1 is only 160 bits wich effectiveley makes 256 bit crypto worth 160 (or much less, 2,000 times less according to SHA1 break report)
<crypt-0> Darxus, ah ok
<Darxus> crypt-0: Nobody here is arguing with you.
<crypt-0> yes, ive reached that conclusion
<Darxus> Heh.
<crypt-0> a lot is missed on IRC, like tone of voice , etc
<crypt-0> easy to misunderstand things
<Darxus> Yup.
<Darxus> Good thing it keeps us out of striking range :)
<crypt-0> "marked it as a security vulnerability" <<< assumed he was saying it shouldn't be
<crypt-0> and made an ass of myself
<crypt-0> brb
<crypt-0> :)
<Darxus> crypt-0: You might want to add more details on how easy it is to crack SHA1 to that bug.
<james_w> I don't think that is needed
<Darxus> "Less than six letter password is cracked within minutes"
<crypt-0> the break of SHA1 is no secret
<crypt-0> also the -15 will make breaking a less than 6 digit password much longer than minutes
<crypt-0> * -i 15
<crypt-0> the -i 15 will make it take 15 seconds to mount the volume, however it will provide better security to those with weak passwords
<crypt-0> you can probably last a few days with -i 600 with a 6 digit pass :P
<crypt-0> default it -i 1
<crypt-0> it doesn't make it weak password magically "more secure"
<crypt-0> but what it does do is increase the amount of CPU power needed to brute force it, making it theoretically "more secure"
<crypt-0> it will slow scriptkiddes down a lot
<dutchie> anybody mind reviewing https://code.edge.launchpad.net/~jshholland/software-center/fix-manpage/+merge/13186?
<Darxus> crypt-0: Yeah that's cool.
<Darxus> Although... still, a 6 digit password should take more than a few days on one computer :/
<crypt-0> Darxus, "You might want to add more details on how easy it is to crack SHA1 to that bug."
<slangasek> ScottK, siretart: emacs23 has now stolen the 'emacs' binary from the emacs22 source package, and made it uninstallable in main.
<crypt-0> check it now, i did
<Darxus> crypt-0: Cool.
<Darxus> crypt-0: Heh, I can see that you've edited the description 8 times.
<crypt-0> had to get the bugs out of the bug report
<crypt-0> :)
<crypt-0> i want to make sure it is cleaned up and proper.
<jdong> hahaha :)
<crypt-0> 9 now changed a . to a ,
<Darxus> Heh.
<crypt-0> its all correct now, notice nothing important changed, like the reference command syntax, just grammatical and punctuation errors
<crypt-0> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/448918
<ubottu> Launchpad bug 448918 in cryptsetup "Insecure Cryptsetup defualts" [Undecided,New]
<dtchen> surely "weak" instead of "insecure"?
<dtchen> the latter can apply to just about any context
<superm1> slangasek, mind glancing over bug 448981?  i'd like to get this assigned to the right package and if it's easy to fix, fixed for everyone's live media builds tomorrow. basically all of the weekend's builds (10-10 and later) are broke right now
<ubottu> Launchpad bug 448981 in mountall "/var/run/dbus is not getting populated on live CDs" [Undecided,New] https://launchpad.net/bugs/448981
<crypt-0> dtchen, should be fixed now
<Darxus> I was just going to ask what the "weak" tag was.  Where are such things documented?
<dutchie> anybody mind reviewing https://code.edge.launchpad.net/~jshholland/software-center/fix-manpage/+merge/13186?
<joaopinto> dutchie, +.TH SOFTWARE-STORE 1 "0.13" "October 2009" <- STORE ?
<dutchie> ah, missed that one
<dutchie> fixed and pushed
<slangasek> superm1: hmm, cody-somerville reported the same yesterday on #ubuntu-release; it sounds like the directory is being taken out from underneath dbus after dbus has started
<slangasek> superm1: mountall is probably the right package, let me see if I can pin it down
<superm1> slangasek, cool sounds good
<mdke> slangasek: sorry to do this *again*, but bug 444853 might require your attention
<ubottu> Launchpad bug 444853 in gnome-user-docs "gnome-user-guide-pl: Depends: gnome-user-guide (= 2.26.0+svn20090323ubuntu5) but 2.28.0+git20090921ubuntu1 is to be installed" [High,New] https://launchpad.net/bugs/444853
<cjwatson> slangasek: I think that dbus needs to 'start on (local-filesystems and virtual-filesystems)'
<cjwatson> since /var/run is the latter
<salty-horse> hi. I'd like to file a bug for this problem, but I'm not sure what's the technical name for those terminals: http://ubuntuforums.org/showthread.php?p=8086412
<slangasek> cjwatson: right - though I wonder if local-filesystems shouldn't imply virtual?
<slangasek> (i.e., is it ever reasonable to send the local-filesystems signal before virtual-filesystems are all up?)
<mdke> slangasek: actually having tested the bug in karmic, I can't reproduce it. Perhaps it is because -pl has been removed in your last change to gnome-user-docs (because there are no -pl translations upstream) - no doubt that will get reinstated when -pl translations are added from Launchpad
<slangasek> mdke: yes, it's because the package has been removed from karmic and the user has some old repo in sources.list.  when are these translations going to be re-added from Launchpad?  (Why wasn't this done sooner?)
<mdke> slangasek: usually, it's done somewhere between non-langpack and langpack translation deadlines
<mdke> so that translations done after they are exported aren't lost
<slangasek> mdke: ah.  well, the side-effect of not pulling them in earlier is that the package has to go through at least one round of NBS + new queue <shrug>
<mdke> hmm
<mdke> slangasek: sorry about that
<slangasek> (plus whatever bug reports from users complaining that their language has gone missing :)
<mdke> slangasek: for the next release I think we should talk about reverting the change whereby the packages are split out into separate languages
<slangasek> sure
<mdke> for this release, we'll just have to lump it :(
<slangasek> yeah, the NBS/NEW isn't a big deal, it's just a bit inefficient - but it sounds like there are enough other reasons to do it that way around (for now)
<mdke> what's NBS, incidentally?
<mdke> ah, I see it
<mdke> yeah, that's a pain
<mdke> slangasek: do you think it might be helpful for https://wiki.ubuntu.com/ReleaseChecklist to have a column with "status" so that items can be marked as done when appropriate? For example, the ubuntu-docs ones tend to get done well before release so if you like I can mark them as "done" when that is the case.
<cjwatson> slangasek: if virtual filesystems are all guaranteed to be mounted immediately, then I do sort of agree that it might be useful to have some kind of hierarchy, to simplify stuff further up the stack
<cjwatson> though probably not a hierarchy any deeper than that, so I don't know how useful that would be
<cjwatson> s/mounted/mountable/
<lifeless> slangasek: around?
#ubuntu-devel 2010-10-11
<BUGabundo> nite guys
<BUGabundo> this was fun
<JoeCoolNetbook1> Can I make a suggestion about the top panel's UI?
<ion> Sure. Of course, if you make it here, itâll get lost in the noise.
<JoeCoolNetbook1> Where can I go so it'll actually get discussed on, etc, ion?
<persia> That's tricky.
<persia> brainstorm is probably best for discussion.
<micahg> !brainstorm | JoeCoolNetbook1
<ubottu> JoeCoolNetbook1: Post your ideas for Ubuntu at http://brainstorm.ubuntu.com and vote for the ones you like!
<persia> A bug with a technical solution is probably best for implementation.
<JoeCoolNetbook1> It's pretty simple.  If you have Wireless and Bluetooth, to disable or enable the wireless radios, you have to right click on the icon, to disable or enable the bluetooh radios, you have to Left click on the icon.
<JoeCoolNetbook1> It's inconsistent.
<persia> Oh.  I think there's already a bug about that.
<persia> Something about replacing nm-applet with something indicatory
<RAOF> Yeah, that's nm-applet being a notification area icon, rather than an indicator.
<persia> JoeCoolNetbook1, Currently, it's possible to make them consistent with right-click, but not in a harmonious colour scheme without extra work.
<persia> But it's very likely to end up being consistent left-click for Ubuntu Desktop and Ubuntu Netbook.
<JoeCoolNetbook1> Can I vote on it?
<RAOF> By and large we don't really prioritise based on voting.
<RAOF> I'd expect that to be done for Natty, though.
<JoeCoolNetbook1> 11.04?
<RAOF> Yeah.
<persia> By and large?  Do we ever prioritise based on anything approaching voting?
<RAOF> Bug heat is partially calculated based on voting, and has *some* impact :)
<RAOF> Brainstorm has voting, and that has occasionally been referenced.
<persia> Oh.  I didn't know any developers looked at that.  I suppose there is some means of populist feedback then :)
<JoeCoolNetbook1> And another thing, In the Wireless Internet drop-down, there's "Connected" and "available".  There are (for me) two sections - Mobile BroadBand and Wireless Networks.
<RAOF> _I_ generally don't look at brainstorm, but Jorge (at least) does, and that translates into UDS discussions sometimes :)
<persia> Yeah, that's in dire need of an entire re-think, but it's *hard*
<JoeCoolNetbook1> Those two are in Bold, and then there's a subsection of "available" networks, but it looks like a horizontal rule.
<persia> RAOF, I considered that memetic drift, but yeah, I can see how it might have a vote-based component.
<JoeCoolNetbook1> I think that should be switched to where "Mobile Broadband" and "Wireless Networks" are distinct sections with their own horizontal rules, and "avialable" a clear subset, in bold
<JoeCoolNetbook1> With indentations of course
<jcastro> iirc the techboard has a todo to look at as fa as looking at brainstorm proposals
<persia> jcastro, Yes, but the TB is no longer in charge of setting the UDS agenda (unless I missed something)
<RAOF> JoeCoolNetbook1: I suspect that we'll be discussing the indicatorfication of network manager at UDS, and that #ayatana (and the mailing list) would be the place to discuss mockups.  As persia said, it's hard UI design.
<JoeCoolNetbook1>  Hard meaning difficult?
<RAOF> Yeah.
 * persia mumbles about wired modems, wireless ISDN, PANs, wired networks, packet radio, IrDA, and other means of moving bits)
<RAOF> But also in the sense of serious, technical.
<JoeCoolNetbook1> I don't know if it's really that difficult.
<ajmitch> persia: you forgot pigeons
<persia> Also in the sense of steady, unchangeable: there's huge semantic investment in the current model, which ends up either excluding a lot of use cases *or* becoming quickly unwieldy
<JoeCoolNetbook1> It took me a week to figure out how it tried to display hierarchy.  Hierarchy should be very obvious and is pretty basic in UI design.
<persia> ajmitch, I don't know of an implementation of RFC1149 that doesn't involve human operators and standard HID.
 * persia looks more closely at RFC2549 to see if any new developments reduced the need for HID
<RAOF> JoeCoolNetbook1: The difficult part is not so much in finding ways the current UI is sub-optimal; it's in actually finding a *good* UI :)
<JoeCoolNetbook1> Anything is better than what it is now, though.
<JoeCoolNetbook1> How are things decided on and implemented in Ubuntu?
<RAOF> That's manifestly not true; that applet is an *improvement* on what came before.
<RAOF> JoeCoolNetbook1: A small set of stuff is decided at UDS; mostly what gets implemented is what people care enough about to implement.
<RAOF> (Like all open source)
<persia> RAOF, I can't agree with that entirely.  For Studio it's not used because of the unexpected processor demand profile (although gnome-nettool is even more frightening as an interface)
<JoeCoolNetbook1> RAOF, do you have a screenshot of how it was before?
<persia> Even stuff that gets decided at UDS gets decided because people claim at UDS to care enough to implement it.
<RAOF> JoeCoolNetbook1: Not off the top of my head, no.
<RAOF> I'm tautologically surprised nm-applet has an unexpected CPU usage.
<persia> heh.  Anyway, comes from unpredictable environment and failure-recovery modes.  gnome-nettool just fails dead until the user does something.
<persia> Most folk much prefer http://xkcd.com/416/
 * ajmitch still has a laptop that has wifi configured manually in /etc/network/interfaces
<micahg> wow, I didn''t know Ubuntu made it into xkcd
<ajmitch> micahg: ubuntu & debian have been mentioned a few times
<ajmitch> http://xkcd.com/797/ being a nice example :)
<JoeCoolNetbook1> I don't think Ubuntu is this niche distro anymore.
<micahg> ajmitch: heh, yeah, I noticed that one recently
<JoeCoolNetbook1> So having something done is a matter of doing it and commiting it into the repository and hoping it doesn't get reverted?
<RAOF> Mostly, getting something done is a matter of getting it done upstream.
<RAOF> Although, with an indicator there won't be an existing upstream, so it'd be a matter of writing the code, packaging it up, getting it in the archive, and then getting it installed by default.
<persia> No need to bother with the last.
<persia> if it works well, and it's not installed by default, one can still use it.
<persia> And if it works really well, lots of people will clamour to get it installed by default.
<RAOF> This is correct.
 * persia points at the neverending rythymbox vs. banshee vs. available space on a CD debate
<RAOF> That would be easy: just ship IronPython instead of cpython!  You get banshee *and* pick up some useful CD space :P
<RAOF> And make some people's heads explode, which is always gratifying.
<persia> Yeah, but can you do that and have rhythmbox too?
<dholbach> good morning
<pitti> Good morning
<pitti> shadeslayer: ok, understood; please upload then
<pitti> slangasek: hello
<\sh> moins
<pitti> still suspiciously quiet on the bug/mail/SRU front -- the calm before the storm?
<\sh> pitti: they all need to find their towles ;)
<\sh> pitti: good morning and congrats to the very well performed 10.10.10 release :)
 * pitti checks again...
<pitti> nope, Earth not destroyed by Vogons yet
<Hobbsee> perhaps there just aren't bugs
<pitti> \sh: good morning! yeah, kudos to Robbie, Kate, Colin, Jonathan!
<\sh> pitti: have a look at mice folks in your house ;)
<pitti> https://edge.launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text= ... c'mon!
<pitti> \sh: no, they always want to put my head in medical devices
<\sh> pitti: hehehe...I think we should invite all of them to "The Restaurant at the End of the Universe"
<pitti> RAOF: ooh, so it's xorg-evdev after all? nice that finally there might be a solution
<RAOF> pitti: Well, the dude says that it's fixed using the input drivers from xorg-edgers.  evdev *does* synthesise button events in some cases, but those none of those codepaths look like they ever send a DOWN without also immediately sending a corresponding UP.
<RAOF> Having a diff to stare at would be much appreciated, if just the newer -evdev makes it work :)
<pitti> RAOF: indeed
<pitti> RAOF: but I now had several people try, and none of them got EV_KEY BTN_* events for those keys
<pitti> RAOF: is it remotely possible that this interferes with the utouch bits?
<pitti> they certainly generate events, don't they?
<RAOF> They do, but they generate special gesture events.
<pitti> Rejected:
<pitti> udev_163-1.dsc: format '1.0' is not permitted in natty.
<pitti> ??
<pitti> wgrant: ^ what does that want to tell me?
<\sh> woot?
<wgrant> pitti: natty isn't initialised yet.
<pitti> and I was so close to claiming the "first natty upload" trophy
<pitti> wgrant: ah, ok :)
<\sh> phew...I thought we had to transform all 1.0 src format pkgs into 3.0 ;)
<wgrant> What it actually means is that source format 1.0 is forbidden (as are 3.0 (native) and 3.0 (quilt)).
<wgrant> Right.
<wgrant> Hopefully it will be initialised soon; I'm not sure why it isn't yet.
<\sh> wgrant: take you time ;) I need to have time to play with our new toys...I wonder if it's possible to pimp my new RSH5TEPN of Samsung with Ubuntu Unity ;)
<apw> pitti, are we safe to start the work items collector for natty now?  i am struggling to find my own blueprints since someone renamed them all for the tracks stuff
<pitti> apw: yes, I think we are
<pitti> should be a mere copy of maverick.cfg with the trend lines reset and s/maverick/natty/g
<apw> pitti, yeah you doing that or shall i
<pitti> apw: please do
<apw> pitti, ok about to commit the new config, might it be safest to copy everything before the run :)
<pitti> apw: "safest" yes, but we already have several copies of the DBs, so it shouldn't be a high risk
<apw> pitti, ok pushed
<apw> pitti, does the thing run at the top of the hour or the top of the next these days
<pitti> 05 */2 * * *
<pitti> so, should run in 7 minutes
<apw> in UTC ?
<pitti> BST
<apw> ahh good
<pitti> platform@lillypilly:~$ date
<jackyalcine> hello?
<pitti> Mon Oct 11 09:58:33 BST 2010
* jackyalcine changed the topic of #ubuntu-devel to: Hmm
* jackyalcine changed the topic of #ubuntu-devel to: I didn't know you could change the topic!
* apw changed the topic of #ubuntu-devel to: Archive: {{Kate to make major update in this space!}} | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<apw> skaet, i assume the archive is still frozen ?
<wgrant> The archive doesn't exist yet.
<skaet> apw, starting into the tasks today to open up Natty and get us back into development mode.
<apw> wgrant, heh well the overall archive does :)  i really mean we are in release freeze
<apw> i restored the topic from the most recent set that i could find
<apw> but the first stanza is missing :)
<apw> skaet, i'll let you figure out what the state of the archive is then :)  and update the topic here
<pitti> skaet: (the original idea was that you have the honor of updating /topic to "10.10.10 released!!111!" :) )
<jackyalcine> where do i find application development for ubuntu?
<skaet> pitti,  It was Robbie's release, so it only seemed fair for him to have the honors - 'sides I was head's down focusing on UEC images at the time.  ;)
 * skaet is slow this morning.... just notice the topic in this forum...   heh
<apw> skaet, we only noticed cause someone typed int he wrong place and it became 'hmmm' for a bit
<skaet> pitti, apw, -  ok, lets see if the permissions let me...  robbie's on a plane today.
<jackyalcine> ??
<jackyalcine> no one's answering my question.
<pitti> jackyalcine: that's because it's way too unspecific
<dholbach> you could try #ubuntu-app-devel
<zooko> Dear Ubuntu devs: way to go on Maverick! Thank you!
<apw> pitti, it looks like all-projects does not make the output directory before trying to fill it, but i didn't get the error messages to me, am i on the wrong list ?
<pitti> cp: cannot create regular file `/home/platform/public_html/workitems/natty/natty.db.new': No such file or directory
<pitti> ah, indeed
<pitti> apw: To: martin.pitt@ubuntu.com, work-items-tracker-hackers@lists.launchpad.net
<pitti> apw: but I only got the PM, too
<pitti> perhaps it takes a while to get through the filter
<apw> and its not in the archive either
<pitti> hm, I guess we could actually shelve maverick.cfg now
<pitti> mkdir'ed
<apw> pitti, yeah i was wondering, i suspect we can definatly stop maverick after tommorrow -- dunno if there are items which may close now the release is out and we want hoovered up
<pitti> right, there might still be some cleanup actions left
<apw> pitti, oh and it seems to take less than an hour, indeed less than half on its 'not at midnight' configuration
<pitti> apw: ah, presumably because all milestones are in the past now, so it wouldn't actually update any chart any more
<pitti> (for maverick)
<apw> pitti, ahh good point :)
<apw> pitti, i don't see any emails other than your test on the lists the errors are meant to go to
<graviti> ?
<pitti> apw: hm, then perhaps lillypilly can't send there, or platform@lillypilly isn't allowed to post
<macno> I found a broken mirror of http://releases.ubuntu.com mirror.anl.gov
<macno> where's the right place to report it?
<persia> macno, To the mirror.anl.gov administrators.
 * persia hunts to see if there is handy contact info
<dholbach> mirrors at ubuntu.com afaik
<macno> ok, found an email address. mailing them
<persia> https://launchpad.net/~argonne-mirror/+members seem to be the folks.
<shadeslayer> pitti: ill need sponsorship, also, ill need to package newer versions since upstream wants to ship latest versions
<pitti> hah! so I can claim the first natty upload after all: https://edge.launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=
<shadeslayer> oooh
<shadeslayer> pitti: ok i need confirmation, can we upload choqok 0.9.90 and qoauth 1.0.1 to lucid-proposed?
<pitti> shadeslayer: please do
<shadeslayer> maverick has 0.9.85 and qoauth 1.0
<pitti>     cur.execute('''CREATE INDEX work_items_assignee_milestone_idx on work_items(assignee,milestone)''')
<pitti> sqlite3.OperationalError: index work_items_assignee_milestone_idx already exists
<shadeslayer> ( ill then ask for a  upload of 0.9.90 and qoauth 1.0.1 to backports )
<pitti> collect failed for ./config/natty.cfg
<pitti> shadeslayer: oh, hang on; I thought you meant the maverick versions
<shadeslayer> no :)
<shadeslayer> thats why i need confirmation
<pitti> shadeslayer: then we need maverick SRUs at the same time
<pitti> but it might be easier to do it in two steps
<pitti> (for verification)
<pitti> apw: ^ see WI tracker error above; did yuo perhaps ^C a run, or so?
<pitti> looks strange
<pitti> apw: perhaps we should kill the natty db and start over?
<shadeslayer> pitti: well, do you think theyll survive SRU's ?
<shadeslayer> choqok and qoauth that is
<shadeslayer> ( for maverick )
<pitti> can't say without at least seeing a changelog and a rationale
<pitti> if maverick's versions work, then it's safer and easier to bakcport them, than trying to lift two releases to new versions
<shadeslayer> well, for rationale i just have "Upstream says so" :P
<shadeslayer> thats what im thinking
<pitti> cjwatson: if you have a minute, would you mind reviewing bug 653568 for SRU?
<ubottu> Launchpad bug 653568 in udev (Ubuntu Maverick) "mounting hardware encrypted usb stick failes" [Undecided,Fix committed] https://launchpad.net/bugs/653568
<shadeslayer> ok so i put maverick versions into lucid and then maverick-backport for new versions of choqok and qoauth?
<Riddell> ok, keep it simple then, go with what we have in maverick for lucid-proposed
<Riddell> and new versions in maverick-backports
<Riddell> (unless we know of a good reason to update the maverick version)
<shadeslayer> right then ...
<shadeslayer> Riddell: https://launchpad.net/~rohangarg/+archive/experimental/+packages?field.name_filter=&field.status_filter=published&field.series_filter=lucid : qoauth and choqok packages from there
<pitti> apw: I'll try that now
<Riddell> shadeslayer: ok
<shadeslayer> thanks :)
<cjwatson> skaet: did updating the topic here not work for you then?
<cjwatson> pitti: udev> dodne
<cjwatson> done
<pitti> cjwatson: cheers
<cjwatson> lool: hm, these error handling patches you merged into MoM are entirely broken :-(
<cjwatson> can't have been tested
<pitti> uh, we open a new release, and no debhelper to merge -- must be Debian freeze :)
<lool> cjwatson: these https://code.launchpad.net/~kgoetz/merge-o-matic/mom-misc/+merge/20202 ?
<lool> hmm no the previous one I guess
<cjwatson> surprisingly, exit does seem to exist at top level, but is undocumented.  I think using it is probably bad style
<cjwatson> the bit that's actually broken is a finally handler.  fixing up ...
<lool> cjwatson: Reading the diff, I can see why they are bogus now
<lool> the open change seems broken too
<lool> I'm trying to find the merge request
<cjwatson> lool: which one?
<cjwatson> (which open change)
<lool> cjwatson: No sorry, checked trunk and it's ok
<cjwatson> ok, I committed fixes as r176 and r177, please double-check?
<lool> I couldn't find the bug or merge request where I thought we discussed this
<cjwatson> oh, also, those exception prints should go to stderr not stdout, fixing
<lool> I remember *not* running merge-o-matic, I only did a patch level review, but I thought I had asked whether he had tested this
<lool> I wonder if this was over email
<cjwatson> I must say I don't understand the point of an exception handler that just prints the exception and exits
<cjwatson> all that does is suppress the traceback
<cjwatson> which makes it harder to debug problems
<lool> cjwatson: I agree
<cjwatson> I suppose if we know what the problem is ...
<lool> cjwatson: Looked at r177 and 176, looks fine; sorry about that
<lool> I just can't find where I discussed this branch; it seems there was no merge request for the branch, so it seems like a lesson that I should keep more references in my commits and ensure there's a merge request or a bug to track changes
<mvo> doko: can you have a look at bug #657937 please? I suspect this guy is having a local build libc6 leftover, but if not it might be something serious
<ubottu> Launchpad bug 657937 in update-manager (Ubuntu) "release update to maverick removes libc6-i686" [Undecided,Incomplete] https://launchpad.net/bugs/657937
<doko> mvo: not seen before
<mvo> doko: ok, I (strongly) suspect a user problem then
<dholbach> highvoltage, ~ubuntu-dev is indirect member of edubuntu-bugs (Ubuntu Core Development Team â Edubuntu Developers â Edubuntu Bugsquad), that's currently why bug mail for edubuntu-bugs goes to ubuntu-reviews@list.u.c (https://lists.ubuntu.com/archives/ubuntu-reviews/2010-October/000707.html) - can we change this somehow?
<mvo> jibel: it seems the -fsystafile exit 2 error is not that uncommon (just looking over the upgrade logs). do you know more about this yet?
<mvo> jibel: huge THANKS btw for your triage effort :)
<jibel> mvo, hey, great release !
<jibel> mvo, most of the time the archive is corrupted for some reason and simply cleaning the cache and reupgrading is enough. The problem is 'some reason'
<jibel> mvo, I haven"t been able to reproduce it
<mvo> jibel: ok, thanks. I keep wondering if I should add a additional checksum step after writing the data to disk. currently its checksumming the data arriving from the network, but not if what is written to disk matches as well. this opens up this type of issues I suppose (typically bit flip errors afaict)
<jibel> mvo, The only way I've been able to reproduce the problem was to download the archive, then corrupt it by hand before running the unpack stage, this very looks like a hw error.
 * mvo nods
<mvo> thanks jibel
<jibel> mvo, btw we have 3 main upgrade issues but which I think are non issues.
<jibel> mvo bug 639933
<ubottu> Launchpad bug 639933 in update-manager (Ubuntu) "10.04 -> 10.10beta: could not install the upgrades - Couldn't configure pre-depend x11-common for x11-xkb-utils, probably a dependency cycle." [Low,Triaged] https://launchpad.net/bugs/639933
<jibel> This is caused by a package in kubuntu-ppa/backport. I don't know which.
<jibel> bug 631426
<ubottu> Launchpad bug 631426 in update-manager (Ubuntu) "Upgrade 10.04 -> 10.10 failed due to "the essential package 'ubuntu-minimal' can not be found anymore" (in.archive.ubuntu.com releated?)" [Medium,Confirmed] https://launchpad.net/bugs/631426
<jibel> This one is weird, and looks like a problem to access the servers for users in india.
<jibel> bug 555729
<ubottu> Launchpad bug 555729 in blcr (Ubuntu Maverick) "package blcr-dkms does not support 2.6.33 or more recent kernels" [Undecided,In progress] https://launchpad.net/bugs/555729
<jibel> Users complaining that blcr is blacklisted.
<jibel> mvo, and that's all for update-manager release upgrades bugs.
<mvo> jibel: thanks, that looks pretty good actually, I had no luck so far with the first one, but I can give it a fresh try, my brain is much recovered since last week :)
<apw> pitti, sorry was out dropping off the last team member to the plane
<apw> pitti, did that sort it out, i don't think i have access to hit ^c on a run
<pitti> apw: sure, it's all under ~platform now
<pitti> apw: but let's see; didn't get another error yet
<jibel> mvo, I installed kubuntu and all the packages from backport, it will be finished in a few minutes. There's also a possibility that an obsolete kubuntu package is blocking the upgrade.
<apw> pitti, i believe the first time it ran there were no milestones for natty which might have been the issue, cjw sorted that out before the later runs
<ScottK> pitti: I have a SRU question - I've got a pending microversion update for clamav in lucid-proposed (same as current Maverick).  This has a regression that I'm about to upload an SRU for to Maverick.  Can I go ahead and update the clamav in lucid-proposed or should I wait for the Maverick SRU I'm about to upload get verified first?
<pitti> ScottK: not for my sake; please upload fixes for both
<ScottK> OK.  Will do.
<ScottK> Just hit dput on maverick-proposed.  I'll update lucid proposed next.
<GPenguin> lets say i notice a significant performance problem with "GtkTextView - Add text" within Ubuntu releases, then where would i go to find some support in investigating this further?
<GPenguin> e.g. a benchmark for 1000 cycles takes 100 seconds compared to other systems with 20 to 40 seconds
<GPenguin> might explain why applications like synaptics are so sluggy
<GPenguin> but i dont know enough to research this on my own
<ScottK> GPenguin: You might have more luck in #ubuntu-desktop.
<GPenguin> ScottK: is that not just a copy of #ubuntu where you consume a lot of replies that lead nowhere?
<ScottK> GPenguin: That's a development channel, not a user channel.
<GPenguin> ah, ok
<ScottK> pitti: clamav in queue for maverick and lucid-proposed
<jibel> mvo, I can't reproduce 639933 with all of kubuntu-ppa/backport installed. I'll compare the held packages of each report ... but later
<dholbach> https://wiki.ubuntu.com/UbuntuOpenWeek starting in 13 minutes in #ubuntu-classroom
<Riddell> thanks for testing jibel
<mvo> jibel: many thanks
<ari-tczew> natty pocket has been opened \o/
<highvoltage> dholbach: eek, yes we can
<dholbach> thanks highvoltage
<doko> pitti: please copy eglibc from -proposed to natty. I don't plan an eglibc upload for natty
<cjwatson> ari-tczew: will be a little while longer before it's open to general uploads though - need to get the toolchain in place first
<cjwatson> doko: I can do that if you like
<ari-tczew> cjwatson: oh, nice if you do this faster :)
<cjwatson> doko: done
<cjwatson> ari-tczew: faster than ...?
<ari-tczew> cjwatson: ah, misunderstood from my side. I thought that you are going to prepare toolchain, so I thought that you will do this faster than doko.
<cjwatson> oh, no, doko is doing that, I'm just driving the archive
<cjwatson> gcc-defaults and binutils are already in place, so I would have a hard time doing it faster ;-)
<pitti> doko: ah, cjwatson beat me to it
<Book_em_Dano> I've been working on patching a package, LP: #640755, and came across a couple of errors while lintian was running.  I was wondering if someone could expound on the errors and what I need to do to fix them.
<Book_em_Dano> the errors are: E: gdecrypt_0.7.2.2-0ubuntu6_source.changes: bad-ubuntu-distribution-in-changes-file maverick
<Book_em_Dano> W: gdecrypt source: newer-standards-version 3.9.0 (current is 3.8.4)
<OdyX> Book_em_Dano: update your lintian
<Book_em_Dano> I'm using the lastest version of lintian in karmic; I'm trying to patch a package for use in maverick
<pitti> cjwatson: I assume it was that which caused bug 655463 to be closed in maverick, i. e. we'll reopen?
<ubottu> Launchpad bug 655463 in eglibc (Ubuntu Lucid) "strstr broken for some inputs on pre-SSE4 machines" [High,In progress] https://launchpad.net/bugs/655463
<cjwatson> pitti: oh, yes, please do.  the natty task should be closed though
<cjwatson> Book_em_Dano: just ignore those
<pitti> cjwatson: ack
<cjwatson> Book_em_Dano: those are essentially "lack of time-travel to tell lintian's karmic about newer things"
<cjwatson> er, karmic's lintian
<cjwatson> Book_em_Dano: to get more information about any lintian message, run 'lintian-info' and copy-and-paste the line you're confused about into it
<ogasawara> pitti: Re: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/647071/comments/11 , are you seeing this on an i386 or amd64 box?  3 patches touch the i915 driver so I can build you a test kernel with those reverted to see if they are the culprit.
<ubottu> Launchpad bug 647071 in linux (Ubuntu Maverick) "0-day Maverick Kernel Upload" [High,Fix committed]
<pitti> ogasawara: actually I haven't seen it for a few hours now, so don't worry too much about it for now
<pitti> ogasawara: I'm on amd64
<ogasawara> pitti: ok, I'll build you a test kernel anyways in case it returns.  How often was it happening at first?
<pitti> ogasawara: if I'm able to reproduce, I'll boot with drm.debug=0x02 (or whatever that was called like)
<pitti> ogasawara: I saw it flicker about 3 or 4 times
<pitti> with perhaps a minute or two in between
<pitti> I'm not sure why it only happened back then
<pitti> I had kvm open, that was the primary difference to what I have now
<achiang> superm1: i wanted to follow-up on https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/655275
<ubottu> Launchpad bug 655275 in dkms (Ubuntu) "allow 32-bit module build on 64-bit host" [Undecided,New]
* skaet changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<hyperair> dpkg: version '/etc/ufw/applications.d' has bad syntax: invalid character in version number
<hyperair> interesting error message there
 * hyperair assumes dpkg --compare-version /etc/ufw/applications.d or something
<brendan0powers> Would I ask about creating an ubuntu derivitave here?
<cjwatson> brendan0powers: https://wiki.ubuntu.com/DerivativeTeam/Derivatives has various information, including contacts under "Getting Involved"
<cjwatson> lool: I'm just going to revert these error handling changes, sorry.  I've already had my first instance of an error message I couldn't debug because it was just bare exception text with no context
<brendan0powers> cjwatson: thanks!
<lool> cjwatson: It makes sense to me; sorry for the hassle
<achiang> is update-manager the only truly supported way to move from LTS to LTS? (hardy to lucid), or can you just s/hard/lucid/ in your sources.list, and then do apt-get update ; apt-get dist-upgrade?
<lool> cjwatson: I didn't care about the changes, I think I got to them because they were in the ~ubuntu-core-dev review queue at some point
<cjwatson> achiang: you can certainly try the latter, and in many cases if things fail that way it's still a bug; but you may have to explicitly resolve some problems by hand.  We recommend update-manager essentially because it saves us writing out release notes that say "first run 'apt-get install dpkg apt', then ..."
<cjwatson> (I'm oversimplifying a great deal here)
<achiang> ta
<jdstrand> hyperair: that sounds like bug #618410
<ubottu> Launchpad bug 618410 in ufw (Ubuntu) "/etc/ufw/applications.d has wrong syntax" [Undecided,Fix released] https://launchpad.net/bugs/618410
<hyperair> hmm
<hyperair> i can't look at it at the moment though
 * jdstrand either
<hyperair> my dear browsers have been knocked out of commission by massive i/o generated by dpkg.
<pitti> kees: ah, I can do the pocket copying of the kernel for you if needed; so we need to sync that with the USN publication?
<bilalakhtar> Natty is open?
<cjwatson> no
<shadeslayer> bilalakhtar: toolchain is being uploaded
<cjwatson> it exists, and the toolchain is being prepared
<bilalakhtar> ah
<cjwatson> an announcement will be sent when it's open
<bilalakhtar> So it should be open by Friday, right?
<shadeslayer> cjwatson: is it this fast ever release ?
<shadeslayer> like .. 10.10 was just released
<nigelb> bilalakhtar: relax :p
<shadeslayer> *every
<bilalakhtar> nigelb: I am addicted to development :)
<nigelb> hrm, better 'Don't Panic'
<cjwatson> shadeslayer: it's usually pretty fast nowadays, though it can take time to get the toolchain built and such
<shadeslayer> bilalakhtar: dont worry, youll get to flex your MOTU muscles :>
<shadeslayer> cjwatson: ah ok
<cjwatson> shadeslayer: for certainly at least the last several releases, we've started this open-and-preparing-toolchain phase the day after release
<shadeslayer> cjwatson: ah ok .. didnt know
<cjwatson> for instance lucid released the Tuesday after karmic release (which was a Thursday)
<cjwatson> err
<cjwatson> not released, opened :-)
<cjwatson> karmic similarly
<cjwatson> and in fact the same for jaunty.  so I don't know where this idea that it will take at least a week to open natty (which I've seen repeated several times the last few days) has come from
<shadeslayer> right, i can see GCC building for natty :D
<shadeslayer> should be done in a few minutes i think
<cjwatson> maverick opened nine days after lucid released, but was an aberration in recent history.  I think that was something to do with UDS being the next week so we were busy preparing
<cjwatson> shadeslayer: the toolchain is more than just gcc-4.4, particularly as gcc-4.5 will be default for natty
<shadeslayer> cjwatson: yes, but gcc is the fundamental block of the toolkit right?
<cjwatson> "particularly as gcc-4.5 will be default for natty"
<ari-tczew> I remember toolchain issue on maverick start.
<cjwatson> what you see building will only be used by a few packages
<ari-tczew> Archive open was delayed due to bug in toolchain.
<shadeslayer> ok
<bilalakhtar> sorry I missed the middle part
 * bilalakhtar guesses the discussion
<kees> pitti: don't worry about USN publication; given it's a 0-day, I may stick the USN for maverick entirely.
<kees> *skip
 * BUGabundo secretly wants #ubuntu+1 to reopen.  $ lsb_release -a Ubuntu natty (development branch)
<BUGabundo> oh goody.... natty X is awesome.. already frozen twice
<ari-tczew> BUGabundo: I don't understand what is awesome in natty? It's the same as maverick at this moment.
<BUGabundo> ari-tczew: could be
<BUGabundo> with newer glibc
<ebroder> Grr. With proprietary drivers turned on, plymouth appears to be able to set a custom 16-color palette, but as soon as the drivers are loaded, they reset the VGA mode to the default palette
<ari-tczew> ebroder: bug 653274
<ubottu> Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed] https://launchpad.net/bugs/653274
<ebroder> ari-tczew: I've seen that too. But right now I'm using a custom plymouth theme, and it doesn't seem to fall back on text mode. I get graphics, they're just low color
<ebroder> What's weird is that the graphics get rendered with a palette of 16 custom colors, but once udev is activated (I think it's udev - I'm not sure), the splash gets redrawn with the palette of 16 fixed colors
<mawst> Hey nice move removing OSS from the kernel while the kernel compile guide hasn't been updated since 9.10.
<mawst> Anyone wanna give me a hand adding OSS?
<mawst> :D
<ScottK> mawst: Support is in #ubuntu.
<mawst> Where's the channel to bitch at devs for removing modules?
<mawst> :D
<crimsun> mawst: Fedora did it ages ago; there's a bug that documents the move; there's a blueprint that links the bug.
<mawst> Fedora is anus.
<mawst> Many things still work better with or REQUIRE oss.
<mawst> padsp isn't the be all end all fix.
<ogra_ac> crimsun, !
<crimsun> no one said padsp is the be-all end-all.
<mawst> So what's the alternative to "welp, you're boned"?
<crimsun> the be-all end-all is fixing the damned application to not require OSS.
<mawst> haha yeah because linux users can convince commercial devs to do that.
<mawst> We can't even convince our devs to not break things.
<mawst> *wink*
<crimsun> anyhow, I'm afraid we're off-topic here, so if you're requiring snd-*-oss, take a look at the ubuntu-audio-dev PPA, which contains daily builds of linux-alsa-driver-modules that still have the oss compat bits enabled.
<highvoltage> mawst: please uphold the Ubuntu Code of Conduct in this channel, or you will be asked to leave
<ogra_ac> crimsun, do you have any idea if alsactl store/restore is supposed to call init ?
<mawst> You can't fire me I quit!
<crimsun> ogra_ac: it can but doesn't according to Debian's and Ubuntu's current config
<ogra_ac> and if so, when it calls that (before or after setting the mixers)
<mawst> ScottK, are you from netlink?
<ogra_ac> crimsun, hmm, k
<ogra_ac> crimsun, i have an audio bug where a card only works if i call init explicitly
<ogra_ac> and only after the mixers have been set
<ogra_ac> i was wondering if i see any kind fo race
<crimsun> ogra_ac: well, there are two things that will happen for Natty: firstly, we'll drop calling the crufty initscript from the udev rule (invokes alsactl -I restore; the -I bypasses calling init); secondly, we're going to migrate as many of the quirks over to the init database.
<ogra_ac> crimsun, bug 637947
<ubottu> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) "no sound devices on current ES2.0 boards" [High,Confirmed] https://launchpad.net/bugs/637947
<ogra_ac> well, i currently care for maverick i want to SRU a fix
<ogra_ac> so we'll have more suerspace control in natty ?
<ogra_ac> great
<ogra_ac> *userspace
<mawst> Wouldn't installing oss4 via synaptic add it to the kernel?
<crimsun> ogra_ac: hum.  I'm pretty sure you're also being bitten by the alsa-lib regression, too (for which I'm preparing an SRU candidate now); see bug #652035
<ubottu> Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card" [Medium,In progress] https://launchpad.net/bugs/652035
<ogra_ac> hmm
<crimsun> ogra_ac: specifically the part about non-existent alsa card configurations leading to the bug you're seeing
<ogra_ac> we'll have a meeting tomorrow at 15:00 UTC with the omap4 alsa driver dev and ASoC upstream, i'll bring that up
<ogra_ac> if you feel like participating, we'll meet in #ubuntu-arm
<crimsun> ogra_ac: there's already a candidate set of debs in my ppa if you want to test, and the reporter has confirmed the fix for his hardware
<ogra_ac> oh, sweet
<ogra_ac> yes, i'll test that tomorrow
<crimsun> ogra_ac: would love to but it's during my work hours :/
<ogra_ac> understood, i'll test the fix tomorrow if my boards are set up again (i just returned from dallas and am still sorting things)
 * ogra_ac puts a cross reference in his bug
<stgraber> ogra_ac: enjoying transatlantic flights that much that you want 4 in the same month ? :)
<ogra_ac> stgraber, haha
<ogra_ac> yeah
<ogra_ac> collecting miles !
<highvoltage> heh
<stgraber> ogra_ac: btw, did you book your flight to Bangor ?
<ogra_ac> stgraber, ugh, no, still not, will have to do that tomorrow first thing
<ogra_ac> to much stuff going on in my life
<stgraber> ok :) let me know when you know what time you'll be landing
<ogra_ac> yeah, worst case i can afford a rental car for the few days
<George_e> Hey, I just wanted to thank everyone for making 10.10 a huge success - I love the new look!
#ubuntu-devel 2010-10-12
<BUGabundo> ahhh my pillow called... she wants me back. see you tomorrow Âµfriends
<RoAkSoAx> Hi all i was wondering if we can file SRU's already
<poolie> i'd like to know that too; https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/513432 is getting a lot of dupes and i'd love to get the sru into maverick updates
<ubottu> Launchpad bug 513432 in bzr (Ubuntu) "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Undecided,Confirmed]
<TheMuso> Yes we can, there are already SRUs in the proposed queue.
<RoAkSoAx>  cool thanks for the tip TheMuso :)
<poolie> TheMuso: what do we have to do to actually get it sponsored?
<poolie> posting on the bug doesn't seem to be enough
<TheMuso> poolie: Go through the process to get the bug ready for an SRU, upload a debdiff/point to a branch, and subscribe ubuntu-sponsors. This is from the top of my head, so the wiki page on SRUs may say otherwise.
<hyperair> okay, this is getting annoying. why do i have to answer the same debconf questions thrice during do-release-upgrade?
<ScottK> Which ones?
<persia> hyperair, In each and every case that's surely a bug.  The cases I've found previously were usually an artifact of the maintainer assuming "no answer" and "unanswered" were identical semantically (which is especially annoying for drop down selections that invite "None" as an option)
<hyperair> ScottK: flashplugin-installer.
<micahg> there's a debconf question in flashplugin-installer?
 * ScottK doesn't recall seeing any.
<micahg> there is a debconf config...
<micahg> I don't recall ever seeing it ask a question though
<hyperair> micahg: there's one asking whether or not to download
 * ScottK wonders what the priority of the question is?
<hyperair> ScottK: not sure, but it kept popping up during do-release-upgrade
<ScottK> hyperair: Right, but it doesn't for others, so I'm wondering if you've got a non-standard priority set.
<persia> hyperair, And you answered it each time?  It's probably worth replicating the experience with DEBCONF_DEBUG=developer to find out why it couldn't remember what you said the first time.
<hyperair> persia: i'll give it a go later.
<hyperair> i've finished answering the questions.
<hyperair> ScottK: i didn't do anything funky with my env
<hyperair> or set anything in /etc
<hyperair> how do you change it besides that env var persia said anyway?
<ScottK> OK.
<ajmitch> ScottK: on lucid the priority looks to be medium
<persia> hyperair, You'd have to create a new environment and redo the upgrade: you can't easily reconstruct later, as the DB state changed.
<persia> My environment variable is about cluttering output, not about setting priority.
<hyperair> persia: i'll redo it later, i've a btrfs snapshot.
<hyperair> persia: i screwed my upgrade last night, so i'm really thankful for btrfs snapshots right now =p
 * ajmitch would tend to blame btrfs for all problems in that case :)
<hyperair> ajmitch: heheh i don't think btrfs has anything to do with debconf.
 * ScottK may be using adobe-flashplugin now, so perhaps that's the difference.
<ajmitch> I think 'debconf-show debconf' will show the priority that's being used, unless do-release-upgrade changes that
<hyperair> maybe.
<hyperair> honestly speaking, i use the 64-bit flash cp'd directly, so i'll probably manually undo all that later
<pitti> Good morning
<\sh> good morning pitti
<pitti> apw: got tons of WI tracker spam during the night; found the problem now
<pitti> fixed, db purged
<slangasek> pitti: hey there
<slangasek> pitti: had a question - do you have an existing Best Practices example for the use of dpkg --path-{in,ex}clude?
<pitti> slangasek: indeed I have: https://wiki.ubuntu.com/ReducingDiskFootprint#Drop unnecessary files
<slangasek> pitti: awesome, thanks!
<pitti> slangasek: the test suite has some more, but with above example it's really everything it's meant to do
<slangasek> pitti: you don't see any reason to include changelog files?  I don't remember if the GPL's requirements to mark modifications apply to binary packages or just to source
<pitti> slangasek: well, if you apply this to a server of your's, you probably won't sue anyone because you removed them yourself?
<pitti> slangasek: if we apply that to systems that we distribute, we need to check that, of course
<pitti> I don't know off-hand
<pitti> if it's sufficient to provide an easy way to display the changelog, that'd be nice
<slangasek> pitti: my current proposed use case is distributed Linaro images :)
<pitti> it's high on my list to investigate for lowering the default footprint
<slangasek> default?
<pitti> Ubuntu standard install, I mean
<pitti>     a) The work must carry prominent notices stating that you modified
<pitti>     it, and giving a relevant date.
<pitti> that's what I see in the GPL
<slangasek> I'm not particularly keen on the idea of removing all this stuff from a default install
<pitti> slangasek: oh, just talking about changelogs for now
<slangasek> yeah, I'm not keen on *those* being removed from a default install either
<pitti> the wiki page is meant for customized projects which are really tight on space
<slangasek> ohwell, the wiki page at least gets me where I'm going for right now - thanks
<pitti> slangasek: but changelogs are taking several MBs, and are something most users really don't care about; so if we can provide a seamless way for those wo do, they would be a good candidate IMHO
<slangasek> pitti: in the case of local packages, the changelog is the only place that records the origin of the package after the fact
<slangasek> since dpkg doesn't track origin info, and apt can only tell you about currently-downloadable packages
<pitti> ah, I see what you mean
<pitti> slangasek: no, my intention is not to use dpkg filters for those
<pitti> if we do that, it should be for ubuntu packages only
<slangasek> I'm not sure how the dpkg filter can distinguish
<slangasek> but ok, at least it's on the radar :)
<pitti> like, pkgbinarymangler could remove them and add a stanza and a link to the online changelog to copyright, and/or we provide a script "pkg-changelog <pkgname>" or similar
<slangasek> ah, sure
<pitti> slangasek: I don't think dpkg filters are approriate for a standard Ubuntu install, due to the reason you stated
<pitti> this was written for OEM projects primarily
<pitti> kees: ok, can pocket-copy
<dholbach> good morning! :)
<pitti> hey dholbach, wie gehts?
<dholbach> hey pitti, sehr gut - ist nur irgendwie schnell etwas kalt geworden hier :)
<pitti> indeed *shudder*
<\sh> well, it's getting warmer again here in KA
<\sh> good morning dholbach :)
<dholbach> hey \sh
<dholbach> highvoltage, I'm getting more edubuntu-bugs mails now :)
<dholbach> and while I like more edubuntu bugs activity... :-P
<persia> pitti, slangasek: just FYI: there exist several packages in Ubuntu where the changelog for just that package is measured in megabytes.
 * cjwatson fixes MoM to handle multiple entries with different versions in a single Sources file (as often happens in Debian now)
 * ogra hopes persia doesnt refer to anything shipped on the CD
<persia> ogra, I didn't check: I just unpacked every binary package, extracted the changelog, put the size in a report, and sent it to the LP folks arguing about whether it belongs in librarian or the DB.  I couldn't even say which packages have that issue.
 * pitti wonders whether we should just have an ubuntu-changes@ ML
<geser> +1 on this, I've to resubscribe for the next -changes ML after each release
<persia> can we have both?
<pitti> YokoZar: question for you in bug 622220
<ubottu> Launchpad bug 622220 in icoutils (Ubuntu Lucid) "some .exe files do not show icon" [Undecided,New] https://launchpad.net/bugs/622220
<persia> I believe several folks like having the SRU changes going to release-specific lists.
<doko> pitti: could you look at the cdbs merge for natty?
<pitti> doko: yes, can do
<geser> I'd be even happy if the new -changes list is initialized with the subscribers of the previous one
<pitti> geser: *nod*
<pitti> doko, cjwatson: cdbs merge done, tested, uploaded
<pitti> doko, cjwatson: if it's alright with you, I'd like to prepare and upload a new pkgbinarymangler, too, before we open the floodgates?
<cjwatson> sure
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
 * hyperair looks at his never-ending ubuntu upgrade and thinks that dpkg should totally be made into a libdpkg which can be used by apt directly instead of execving
<tkamppeter> pitti, there is a small problem with CUPS, bug 485383.
<ubottu> Launchpad bug 485383 in cups (Ubuntu) "Zebra driver not found AMD64" [Undecided,Incomplete] https://launchpad.net/bugs/485383
<tkamppeter> the CUPS PPD generator /usr/share/cups/drv/sample.drv needs the /usr/share/cups/ppdc/*.h files which are in cups-ppdc and there is no dependency or seed assuring that this package is installed.
<tkamppeter> pitti, there are principally two possibilities to fix: Moving the files to cups-common or making cups-common depending on cups-ppdc.
<tkamppeter> pitti, both solutions have no regression potential (it is only adding some data files), so I think this should be done as an SRU for Maverick. WDYT?
<pitti> tkamppeter: what other files are in cups-ppdc?
<pitti> it's tiny, so instead of pulling it in by default (and adding another changelog, package entry, etc.) we could just merge it into cups-common indeed
<pitti> (for natty onwards)
<pitti> for SRUs, a dependency change sounds fine
<tkamppeter> pitti, some executables to manipulate PPDs, but they are never called by the PPD listing and extraction processes of CUPS.
<pitti> tkamppeter: hm, then moving the two .h sounds fine to me
<pitti> tkamppeter: I'm just confused, I thought we now ship pre-built compressed PPDs for everything?
<tkamppeter> pitti, not everywhere, only if one saves a significant amout of space. If there are already PPD generators (CUPS, HPLIP non-PostScript, ...) with efficient source data or only very few PPD files (pxljr) I did not introduce compressed archives.
<tkamppeter> pitti, moving the .h files from cups-ppdc to cups-common would be sufficient, but needs appropriate versioned conflicts, so that it goes smoothly through an update.
<pitti> tkamppeter: ah, I see
<pitti> tkamppeter: sure, moving files sounds fine then (and they shoudl be Replaces:, not Conflicts:)
<tkamppeter> pitti, for the SRU I sugges simply letting cups-common depend on cups-ppdc.
<pitti> tkamppeter: I agree
<cjwatson> Replaces> yes, I was about to say the same thing.  You should generally also add Breaks, per current Debian policy
<pitti> tkamppeter: erm, cups, not cups-common? not necessary for client side only, or is it?
<pitti> cjwatson: pkgbinarymangler uploaded
<cjwatson> ta
<pitti> it removes the buildinfo.gz files for now (to counteract the new cdbs)
<cjwatson> still need to fix perl before we can open
<pitti> I hope I can get to adding the PNG/SVG compression into this soon, too
<pitti> but no time yet
<pitti> but I expect most desktopish packages to get rebuilt several times anyway
 * cjwatson nods
<tkamppeter> pitti, is really only needed by the CUPS server, I came to cups-common as /usr/share/cups/drv/sample.drv and /usr/share/cups/ppdc/*.defs are in cups-common (which is probably not correct).
<pitti> lamont: do we have pkgbinarymangler version pinned right now? I uploaded a new version for natty
<pitti> tkamppeter: right, seems these should all be moved to cups then?
<pitti> lunch, bbl
<lool> Is natty open for any upload?
<persia> lool, Not yet, but that just means you get stuck in UNAPPROVED.  This might be fine, or it might mean you unexpectedly FTBFS because the environment changed since you test-built.
<bilalakhtar> lool: no, toolchain is being uploaded
<persia> You can check the current status at https://launchpad.net/ubuntu/natty
<persia> (there's likely also some way to do that with the LP API, if you want to make a little indicator widget that shows the current state of the current development target)
<lamont> pitti: dunno - let me go look
<lamont> pitti: no holds on pkgbinarymangler since you promised to not mangle it
<lamont> doko: so about this openjdk-6/armel thing...  what all needs to be built on the panda board to make things happy, and can we arrange to do that for natty?
<highvoltage> stgraber: which team do we have to update contact address for to stop the edubuntu-spam?
<doko> lamont: do all the buildds already run on panda boards?
<doko> the change is easy, just undo the reversion of the upstream change
<persia> highvoltage, Just the bugs team ought to work: if not you probably want to clean up which teams are subscribed to stuff.
<persia> highvoltage, Actually, you might need one for the -dev team if you assign bugs to that team.
<lamont> doko: I have one buildd that is a panda board.  it falls over regularly and is completely not ready for production.  hence we get to coordinate the upload and build.  OTOH, if your upload is known to fail on bbg3 boards, that simplifies things a little, since if it tries there, it won't succeed and require a re-upload
<lamont> I tried building openjdk-6 on the panda board (in a ppa) with just the debian/rules blocker removed, and that was insufficient, so I decided to wait for you
<highvoltage> dholbach: I think it will be right now, let me know if you get more spam
<doko> lamont: that doesn't work. as soon as I upload eglibc with the upstream patch reverted, java fails on *every* buildd
<doko> so we have to delay this until we change all buildds to the panda boards
<lamont> ogra: so that panda board, not so much use ^^
<ogra> lamont, you tried running from SD as i suggested ?
<ogra> i know it will be slow as hell but should be stable
<ogra> i guess you have some HW issue with your USB on that board, all boards we tried yet didnt expose the hdparm issues for example
<dholbach> highvoltage, rock on! :)
<lamont> ogra: the issue is that once we build java with the panda, then you get no java-using builds that succeed on any bbg3 board.
<lamont> or so doko tells me
<lamont> and one panda board, with or without SD, isn't gonna cut it
<persia> doko, Is the problem bbg3-specific or imx51-wide?
<doko> ogra, lamont: apparently the java failures are only seen with the babbage kernel. as long as we have these as buildds, we can't do anything. I don't have any feedback from the kernel team yet
<ogra> doko, right, it seems nobody there has a clue
<ogra> thats why i sent lamont the panda
<ogra> but he has USB issues with it
<lamont> ogra: well, it's been doing ok for a while now, maybe it settled down
<lamont> the threats seem to be working
<ogra> and the prob is that its a 6 layer board for which we dropped support with the latest kernel, so he cant upgrade the image we gave him
 * ogra wonders why his IRC connection is so bad
<ogra> great
<ogra> the only purpose of that board was to build java once
<persia> But how would that help, if the result wouldn't be able to run on anything else?
<ogra> after that we can send it back to TI, we cant use it much anyway
<doko> lamont: so you could try to install the binaries from https://launchpad.net/ubuntu/+source/eglibc/2.12.1-0ubuntu3/+build/1948672 to check if it is fixed with the kernel you are running on the omap board
<lamont> doko: and beyond that we just need the debian/rules blocker gone?
<doko> lamont: ?
<pitti> lamont: cheers, thanks for checking
<lamont> doko: once I install the binaries from eglibc, then what do I do to test whatever it is you want me to test?
<lamont> it'll be a bit later today - breakfast plans
<doko> lamont: java -version should not segfault
<lamont> awesome
<lamont> I like the simple tests
<doko> :-)
<lamont> doko: save me grepping Contents.gz?  where does java-version come from?
<doko> lamont: <space>
<doko> openjdk-6-jre-headless
<lamont> ta
<lamont> dpkg -S had nothing to say to me on the subject
<tgardner> Riddell, could you have a look at linux-lts-backport-maverick in Lucid? It should have gone to main, not universe.
<pitti> tgardner: the source was in universe, so I NEWed the binaries to universe, too
<tgardner> pitti, what should I have done to direct the package to main?
<cjwatson> pitti: ???  I put the source in main!
<cjwatson> at least I'm sure I did
<cjwatson> tgardner: not your fault.
<cjwatson> you couldn't have done anything differently
<pitti> linux-lts-backport-maverick | 2.6.35-22.34~lucid1 | lucid-proposed/universe | source
<tgardner> cjwatson, also, does it need to be seeded so it doesn't get reaped?
<cjwatson> pitti: blink.  I agree with tgardner, it should just be moved en-masse to main
<pitti> cjwatson: sure, no problem; doing now
<cjwatson> tgardner: no, because the component-mismatches stuff doesn't run on lucid any more
<pitti> tgardner: ^
<cjwatson> (I mean, theoretically maybe, but it isn't going to fall out if you don't.)
<tgardner> cjwatson, pitti: thanks. I'll be uploading a meta package as well later today.
<pitti> tgardner: done
<cjwatson> hmm.  looking through shell history, there's no evidence that I put it in main, so it's probably my fault
<pitti> cjwatson: I usually use the +queue page for that, you didn't use that?
<cjwatson> no, because reviewing it involved diffing against the current linux source package in maverick and I didn't want to download that over ADSL.
<cjwatson> the "do everything through the web interface" shtick does rather assume good bandwidth
<pitti> cjwatson: I mean for overriding
<cjwatson> I was already logged in at a shell, so I just accepted it there
<pitti> cjwatson: I generally use +queue for overriding kernel binaries, since it's much faster/easier than with kernel-overrides
<cjwatson> kernel-overrides is very fast these days.
<pitti> (different use case, I know)
<cjwatson> and +queue will get it wrong if we ever have to override sections in advance of kernel source, so I'd really rather you used kernel-overrides, and at some point we'll port that to be an API script
<pitti> anyway, /me creates natty chroot to find out what broke pkgbinarymangler in natty
<apw> oh no, not pkgbinarymangler ... seal that back in the 9th circle
<pitti> apw: well, it just FTBFSed, thanks to the picky test suite
<apw> pitti, there is a god :)
<superm1> achiang, if you need it for an oem project, go ahead and apply it  there on your OEM repos
<superm1> achiang, but keep in mind that some drivers you can't ship in pre-built form anyway
<hyperair> huh, how did /var/crash disappaer >_>
<hyperair> what are the permissions and ownership of /var/crash?
<pitti> hyperair: the upstart job creates it if apport is enabled
<pitti> (which it isn't for the final maverick)
<pitti>     mkdir -p -m 1777 /var/crash
<doko> tgardner, apw: will there be a new linux-libc-dev before opening natty?
<hyperair> pitti: well, ubuntuone-client or something had a script failin due to missing /var/crash.
<apw> doko, a good question, thats a little chicken and egg i guess as we make new ones as part of the kernel build
<tgardner> doko, seems like there ought to be. note that it'll change at least once more when the kernel rolls to 2.6.37
<doko> apw, tgardner: well, I would like to see build problems with new kernel headers from the start, I wouldn't care if the kernel is untested or not working at all ;)
<tgardner> doko, actually, it works pretty good. apw and I have been running it for weeks
<doko> it's these time when I whish the headers would be built from a separate source
<doko> tgardner: then just upload?
<apw> yeah well one of us needs to blink first :)
<tgardner> apw, you wanna fire up the first package to make the upload rights are working?
<tgardner> make sure*
<apw> tgardner, sure thing
<doko> apw: note that gcc-4.5 is the default now
<tgardner> apw, you might wanna think about dropping the brcm staging patches. it doesn't work well enough yet for the real world
<pitti> mdeslaur: can you please forward the patch for bug 456710 to Debian? I just merged the package (I was TIL)
<ubottu> Launchpad bug 456710 in aide (Ubuntu Karmic) "aide chokes on UTF-8 characters in pathnames in config file" [Undecided,Fix released] https://launchpad.net/bugs/456710
<pitti> mdeslaur: and you know better what exactly the patch was for
<mdeslaur> pitti: hmm...I thought I did...let me search for it
<cjwatson> apw: we checked packageset permissions, BTW, so your upload permissions should work fine
<pitti> mdeslaur: the other fix for comments in apt sources was accepted
<apw> cjwatson, thanks :)
<mdeslaur> pitti: done, thanks!
<pitti> mdeslaur: great, thanks
<raphink> hi guys
<raphink> I've got a question about linking bindings to a shared library that was produced in the same source package
<raphink> as in, the install target wasn't called yet, so the .so is still in .libs, but I need to link the bindings (a PHP module in that case) to it, but libtool ignores stuff in .libs
<raphink> I ended up copying the .so in obj/ to build the PHP module and removing it afterwards
<raphink> is there a cleaner way to do this?
<mdeslaur> pitti: what does "TIL" mean?
<pitti> mdeslaur: touched it last
<mdeslaur> oh, hehe...thanks
<raphink> anyone has an answer?
<persia> Could you do something with the library loading environment variables at build time, or would that result in undesireable path elements later at runtime?
<raphink> I've tried to add a -I flag
<raphink> but libtool ignores it
<raphink> I've checked libtool's code, it specifically removes anything that contains .libs
<raphink> another option would be to have two different install targets, but it gets the packaging quite more complicated
<raphink> persia: see, you get to be the one answering ;-)
<cjwatson> raphink: I thought you were supposed to pass the .la file to libtool when linking
<cjwatson> that's how it works for me anyway ...
<raphink> well that works for i386
<persia> raphink, Sure, but other, wiser, folk correct me when I make mistakes.
<raphink> but not with amd64
<raphink> because it complains about -fPIC
<cjwatson> so build the shared objects with -fPIC :-)
<cjwatson> they generally should be anyway
<raphink> which is set and works with .so, but fails with .la (I have no idea why, I spent hours trying to figure out why the static lib didn't inherit the -fPIC)
<cjwatson> linking with the .la shouldn't normally cause linking against the static library
<raphink> ah, right it's .a right?
<cjwatson> .a => static library, .la => libtool archive
<raphink> right
<raphink> ok, so .la and .so are in .libs after the build
<raphink> so I pass -I/path/to/.libs
<raphink> and it's ignored by libtool
<cjwatson> why -I?
<raphink> sorry
<raphink> -l I mean
<cjwatson> that doesn't make sense either
<raphink> wait, let me check before I say more stupid things ;-)
<Laney> MoM should probably exclude *build*
<cjwatson> -L would make some sense, but it's more usual to just put /path/to/.libs/libfoo.la on the link line directly
<raphink> yes, -L
<persia> Does that not create a path entry in the library?
<Laney> although I guess it won't be a problem after autosync happens
<cjwatson> Laney: bug 366532.  and indeed not
<ubottu> Launchpad bug 366532 in Merge-o-Matic "Please don't list xbuildy packages on merges.ubuntu.com" [Undecided,Confirmed] https://launchpad.net/bugs/366532
<raphink> but then libtool ignores .libs, so it ends up linking against the .a which doesn't work for amd64 because of -fPIC
<persia> Laney, It's a feature that MoM doesn't exclude *build* because it helps us catch stuff on the blacklist, stuff that failed-to-sync, etc.
<cjwatson> raphink: there should be a .la file outside .libs for you to use
<raphink> ok
<raphink> let me check
<raphink> I'll have to rebuild to see I think
<cjwatson> for instance in bzr trunk of man-db, src/Makefile.am sets LIBMAN = $(top_builddir)/lib/libman.la
<Laney> persia: It's a misappropriation of the merge list, though. We have MDT to catch these cases (or if unsuitable, should modify it to do so).
<raphink> ok
<raphink> let me check cjwatson
<persia> Laney, I guess.  I use MDT to determine what to merge most of the time anyway.  But for folk who like their merges predigested, I'm not sure MoM isn't more useful for blacklist stuff anyway.
<cjwatson> I'm inclined to agree with Laney; AFAICT it's an oversight that we don't exclude *build*
<raphink> persia: you mean chdist ?
<cjwatson> especially since one bit of MoM already does
<cjwatson> ./generate-patches.py:78:            if search(".*build[1-9]+$", our_source["Version"]):
 * Laney branches
<cjwatson> too late ;-)
<Laney> :)
<hyperair> hmmm
<hyperair> i see some interesting new things in /etc/default/grub
<Laney> 1-9+ isn't quite right though
<hyperair> what's BadRAM?
<Laney> build10?
<cjwatson> hyperair: info grub
<persia> [0-9]+ might be better.
<hyperair> cjwatson: okay thanks.
<cjwatson> Laney,persia: fixed
<cjwatson> let me know if that works out ok
<persia> cjwatson, Thanks for the quick change.
<Laney> thanks
<Laney> I wish I could remember how to show the diff introduced by the latest commit in bzr
<Laney> cf `git show'
<cjwatson> if it causes a practical issue with blacklisted stuff, we can figure something out
<cjwatson> bzr di -clast:
 * Laney memorises
<cjwatson> or 'bzr alias show="log -v -p -n1 --long"' and then 'bzr show -rlast:'
<persia> 95% of blacklisted stuff is because we pull upstream faster than Debian, and Debian pulls from us.
<persia> The other 5% is probably caught by MDT, and needs manual merging anyway.
<ari-tczew> hey, what's the status of toolchain?
<cjwatson> ari-tczew: nearly done, just waiting for gcc-4.5 to finish on armel and I needed to reupload perl with a fairly obscure fix
<cjwatson> oh, and python is going in first too apparently
<ari-tczew> ok thanks
<Laney> can we upload stuff to the queue?
<cjwatson> Laney: yes
<Laney> good to know
<persia> Laney, You won't be able to know it builds with gcc-4.5 on armel though :)
 * Laney now has armel hardware ;-)
<Laney> reminds me to poke at ghc there
<persia> heh
<\sh> micahg: pingeling -> zend-framework 1.10.8 official backports??? :)
<micahg> \sh: as in the backports pocket?
<\sh> micahg: yepp...from 10.10.10 to 10.04
<joaopinto> cjwatson, could you please look at bug 568067 ? I believe you were the one checking it about 6 months ago, it was pre-release time so it did not get any attention
<ubottu> Launchpad bug 568067 in geoip (Ubuntu) "Default timezone for the country 'PT' is wrong, should be 'Europe/Lisbon'" [Undecided,New] https://launchpad.net/bugs/568067
<tgardner> cjwatson, I've uploaded linux-meta-lts-backport-maverick. Is the package name linux-image-server-lts-backport-maverick sufficient for the point release DVD ?
<SpamapS> <sigh>
<SpamapS> http://jira.mongodb.org/browse/SERVER-1764
 * hyperair pings cwillu_at_work 
<SpamapS> "Now I don't mean fully static, i.e. pthread, libc, etc.. are still dynamic. but boost, pcre, spidermonkey will by default be not only static, but the source will be in the mongo repo so we can pin to versions, etc.."
<SpamapS> Something has to be done
<hyperair> cwillu_at_work: were you the one who worked on the btrfs + grub issue? it seems to be around with maverick =(
<SpamapS> Every single upstream thinks its ok to embed library source code in their tarballs now. :-/
<raphink> there, finally reproduced my issue :-)
<raphink> cjwatson, persia
<raphink> http://pastebin.com/YTcFjfeN
<raphink> it tries to link against the .a
<raphink> even though there is a .la
<raphink> not with the exact same name though
<raphink> rpinson@condor:~/packages/db/db5.0-5.0.26$ ls obj/*.la
<raphink> obj/libdb-5.0.la  obj/libdb_cxx-5.0.la  obj/libdb_java-5.0.la  obj/libdb_tcl-5.0.la
<raphink> maybe that's the issue cjwatson?
<raphink> hmm no, symlinking libdb_cxx.la doesn't help
<raphink> cjwatson, persia: the problem is that the following line seems to search for a .a
<raphink> libtool: relink: cc -shared  .libs/db4.o   -L/home/rpinson/packages/db/db5.0-5.0.26/obj -L/lib -L/usr/lib -ldb_cxx -lstdc++  -Wl,-rpath -Wl,/lib   -Wl,-soname -Wl,db4.so -o .libs/db4.so
<ari-tczew> cjwatson: hmm, does your last change did this on MoM? Updated Merges: 0
<cjwatson> tgardner: should be
<cjwatson> raphink: dunno any more, sorry.  maybe one of the .la was built with libtool disable-shared or something?  hard to tell from here.
<tgardner> cjwatson, cool
<raphink> ok cjwatson, thanks
<raphink> I end up having to copy the .so to get it to work though
<raphink> for some reason
<cjwatson> ari-tczew: what's wrong with that?
<cjwatson> that's what I'd expect given that no universe merges have been uploaded yet
<raphink> persia: any idea ?
<Laney> It doesn't look like there has even been a run since the latest changes anyway
<cjwatson> shouldn't think so, no
<persia> cjohnston, Why does main/universe matter in that context?  the relatively small number of merges + the squeeze freeze is likely more significant.
<persia> raphink, Sorry, you were at the edge of my knowlege of library packaging when you started,and I'm lost.
<ari-tczew> cjwatson: I didn't say wrong. I just saw refresh in MoM.
<cjwatson> persia: YM cjwatson HTH
<raphink> persia: ok, my ack copying the .so to build the PHP module works fine, I don't know if that's acceptable
<cjwatson> persia: it matters because the page that displays "0 updated merges" is https://merges.ubuntu.com/universe.html.
<ari-tczew> cjwatson: I never understood what's the difference between outstanding and updated merges.
<raphink> s/ack/hack/
 * persia finds egg,and carefully applies to face
<cjwatson> ari-tczew: "outstanding" => never uploaded this cycle; "updated" => uploaded this cycle, but there's been another change on one side or the other.
<raphink> o_O
<ari-tczew> cjwatson: hmmm, did this one worked in the past, or you fixed this in MoM trunk?
<cjwatson> ari-tczew: that's how it's been for years
<cjwatson> (and working for years in my experience)
<Laney> MoM's interface is really rather stable
<ari-tczew> cjwatson: So I'm not too perceptive.
<cjwatson> https://code.launchpad.net/+branch/merge-o-matic shows what I changed recently
<ari-tczew> cjwatson: are you interested in merging proposed changes to MoM?
<ari-tczew> yes I know and I'm looking on this right now
<cjwatson> ari-tczew: not desperately, I was just trying to get it minimally working for natty opening
<cjwatson> I don't know the code that well; if you can get hold of Keybuk he's better to review actual work
<ari-tczew> cjwatson: ok, I only asked, because MoM looks like orphaned.
<cjwatson> "maintenance mode"
<achiang> superm1: well, i'm more interesting in finding out why you think my approach is wrong
<superm1> achiang, i seem to remember running into issues on an early rhel 5.x version where modules were compiled for i386 but certainly wouldn't load into an i686 kernel (errors while modprobing saying it didn't match).  since you and mjg say that it should work,  i want to determine why I was running into that behavior first
<ari-tczew> cjwatson: about revision 182. does it should prevent produce *buildX versions in MoM?
<superm1> trunk isn't stable for dkms right now anyhow, haven't had enough time to fix it yet either
<cjwatson> joaopinto: I've filed a sysadmin ticket
<cjwatson> ari-tczew: yes, after the next time it regenerates
<ari-tczew> cjwatson: so next MoM update will remove *buildX packages?
<cjwatson> ari-tczew: should do
<ari-tczew> ok understand
<achiang> superm1: if you build the module on an i386 host, i could see *maybe* it wouldn't load  on an i686 install. but then again, my patch doesn't change that anyway
<achiang> superm1: passing ARCH=i386 to a kernel makefile *doesn't* say "use i386 vs i686 compiler flags". it *does* say, "use 32 bit build, not 64-bit build"
<achiang> superm1: to understand why, you just need to go read the top-level kernel makefile
<bdmurray> pitti: is there a natty branch for apport yet?  I'm not finding one and would like to propose a merge.
<pitti> bdmurray: it hasn't changed, lp:~ubuntu-core-dev/ubuntu/maverick/apport/ubuntu
<pitti> oops, sorry
<pitti> I  keep forgetting that I use the package branches
 * pitti pushes
<pitti> bdmurray: pushing lp:~ubuntu-core-dev/ubuntu/natty/apport/ubuntu now
<pitti> will still take a bit, though; not sure why those don't get stacked
<pitti> finished
<cjwatson> bdmurray,pitti: jml is working on sorting out package branches in general, too
<pitti> cjwatson: this one is a bit special; it's not lp:ubuntu/apport (although having that would be nice)
<pitti> same like udev
<bdmurray> pitti: thanks
<cjwatson> pitti: right, I realised that part-way through typing but figured my comment was still useful
<pitti> cjwatson: yes, it's still good to hear
<pitti> but right now we don't really have a perfect story about packages whose upstreams are in bzr
<pitti> bdmurray: got the MP, thanks
<ari-tczew> yay, toolchain is not ready yet and developers have done some merges! greetz to pitti and cjwatson
<ari-tczew> or maybe these packages are a part of toolchain?
<cjwatson> ari-tczew: the merges that have landed in the archive are part of the toolchain (in the wider sense; packages we'd like to have in place before opening the floodgates)
<cjwatson> ari-tczew: why are you being confrontational about it, though?
<cjwatson> or possibly s/confrontational/sarcastic/
<ari-tczew> cjwatson: ekhm, there is no sarcasm
<cjwatson> ok, I read it as such; apologies then
<hyperair> oh for the love of.. why is ureadahead a dependency of ubuntu-minimal?
<hyperair> it was recommends before!
<cjwatson> it was never recommends as far as I can see
<hyperair> hmm? really?
<hyperair> i remember managing to remove it.
<cjwatson> I just went back through the bzr logs of the seeds
<cjwatson> it used to be more desktopish.  but anyway, you can remove ubuntu-minimal ...
<cjwatson> ari-tczew: well, in that case, there are *lots* more merges from me in the queue waiting to be flushed. ;-)
<ari-tczew> cjwatson: so hearing about planning a lot of merges is beauty for my ears.
<hyperair> cjwatson: ah, i see. ubuntu-minimal got installed for some reason or other.
<ari-tczew> I love to looking how number of remaining merges is falling down.
<cjwatson> ari-tczew: right, earlier I thought you were saying something like "why are you guys doing merges when the toolchain isn't ready yet?". :-)
<pitti> ari-tczew: no, the merges that I uploaded will wait until natty is thawed; not part of the toolchain (except for cdbs and pkgbinarymangler, these are in)
 * bilalakhtar got pinged for ^^
<cjwatson> https://launchpad.net/ubuntu/natty/+queue?queue_state=1 is what's waiting to be flushed, FWIW
<bilalakhtar> People have begun uploading for natty? But the toolchain is still being uploaded, right?
<ari-tczew> cjwatson: I just looked on this page. :)
<cjwatson> bilalakhtar: you can upload, it just gets held in the queue
<bilalakhtar> cjwatson: Of course one can upload, but there are high chances of FTBFS
<ari-tczew> hmmm, I'm not convinced to uploading packages if toolchain is not ready. It can output FTBFS.
<cjwatson> probably not that high
<ari-tczew> oh, bilalakhtar :)
<cjwatson> relatively simple C packages aren't that likely to regress
<cjwatson> personally I'd rather get a jump on merges as soon as possible in order to try to get the initial pass done by UDS
 * bilalakhtar checks the release process
<cjwatson> anyway, we should be open tomorrow evening with any luck.  if that works out then it'll be the fastest opening I can remember
<cjwatson> though the weekend timing helped there
<cjwatson> dinner
<ari-tczew> so natty is longer development cycle than other releases :)
<ari-tczew> due to earlier maverick's release date
<bilalakhtar> ari-tczew: yes, and that's good news for us
<ari-tczew> bilalakhtar: do you plan work on reduce merges?
<bilalakhtar> Just like jono started Operation Cleansweep for maverick, we should have another operation to reduce the number of merges down to 5 or below
<bilalakhtar> ari-tczew: yes, that's what I was thinking about
<ari-tczew> nice
<seb128> lamont, there?
<lamont> sup?
<bilalakhtar> OC was for patches, this operation should be for natty merges
<seb128> lamont, can you stop https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+build/1994816?
<seb128> lamont, it built in 19 minutes on i386
<seb128> lamont, seems it's building again and again on amd64 for some reason or that the build is having an issue
<seb128> lamont, the log is updating but it never finish building
<lamont> seb128: one gtk+3.0/amd64 build slapped upside the head.  sadly, I have little-to-no visibility to see what it's really doing
<seb128> lamont, ok thanks
<seb128> I will do another upload in a bit let's see how that one goes
<scott-work> Ng: hi!  Allow me to introduce myself, I am currently project lead for Ubuntu Studio.  Cory Kontros told me to talk to you about getting access the ubuntustudio.org website in order to change the release information/notes for Maverick
<YokoZar> pitti: I could upload icoutils to lucid for SRU then
<BUGabundo> oias
<misha680> quick question: does the Ubuntu _merge_ process merge _new_ packages in unstable or _only those already present in Ubuntu_? Thank you
<cjwatson> misha680: both
<misha680> cjwatson: oh thank you, good to know
<misha680> cjwatson: sorry one more quick question. I am working on a package that is going into a Debian Pure Blend (Debian Med). Do you by any chance know if "Debian Pure Blends" are included in this process? I believe they use standard repos but not 100% sure
<cjwatson> misha680: I'm going to have to look up exactly what Debian Pure Blends do
<cjwatson> misha680: as a general rule we only merge from the Debian archive (there are exceptions, but the Debian archive is the only one we actively track)
<schwarzkopf> is there a linux tool for full tilt poker ?
<cjwatson> misha680: http://blends.alioth.debian.org/blends/ch-about.en.html indicates that Debian Pure Blends are strict subsets of the Debian archive, so in that case yes they'll be included
<misha680> cjwatson: thank you so much!
<cjwatson> schwarzkopf: this is a channel for development of Ubuntu; please try #ubuntu, https://answers.launchpad.net/ubuntu, or http://ubuntuforums.org/
<wgrant> Does anybody use dput's don't-upload-to-the-same-place-twice feature?
<cjwatson> I don't use dput, but it's saved me mistakes in dupload a few times.  (Of course I also know how to override it when it's wrong.)
<RAOF> No.  In fact, I should probably work out how to override that, 'cause I push to places which don't mind overwriting quite frequently.
<wgrant> Right.
<wgrant> And won't everything be smart enough to reject duplicate uploads this decade?
<cjwatson> In my case I like it not because the server is going to fall over, but because it occasionally saves me time-consuming uploads
<cjwatson> oh yegods, careless of me to end up TIL on ppp
 * cjwatson pushes that firmly to the back of his merge queue
<wgrant> Hah.
<ajmitch> wgrant: REVU happo;y accepts duplicate uploads, for a good reason
 * ajmitch cannot type either
<wgrant> Well, true
<wgrant> But that's not a case for preserving dput's behaviour.
<SpamapS> does anyone else find the tracks for UDS-N completely perplexing?
<kklimonda> what do you mean?
 * cjwatson unbreaks MoM
<SpamapS> Well, the ideas I have for UDS sessions are "enhance upstart for server usage" .. is that "cloud" or "other" ?
<RoAkSoAx> SpamapS: other :) I put mine under "Other"
<SpamapS> Also I'd like to discuss the idea of upstream-managed ppa's ... is that Application Selection Defaults or Ubuntu the Project ?
<smoser_> why isn't that foundations ?
<SpamapS> there is no foundations track
<SpamapS> or server track
<smoser_> err... i forget what the topics are
<smoser_> have to see my list
<SpamapS> http://summit.ubuntu.com/uds-n/
<RoAkSoAx> SpamapS: as long as you appoint jib as the reviewer...
<SpamapS> I think I'll just treat "Cloud" as "Cloud & Server" .. other is already HUGE
<kklimonda> SpamapS: isn't there a "Application Developers" track? upstream-managed PPAs would fit it perfectly
<RoAkSoAx> SpamapS: i put mine under "other" and set jib as the reviewer
<SpamapS> kklimonda: Yes there is. I guess I hadn't thought of Drizzle or MongoDB as an application.. but thats what it is.
<RoAkSoAx> btw... Natty is not yet open for development yet right?
<SpamapS> No, but soon IIRC
<RoAkSoAx> ok thanks :)
<SpamapS> It shows up as an actual distro now
<cjwatson> hopefully tomorrow
<cjwatson> (late, not early)
<RoAkSoAx> awesome :)
<SpamapS> cjwatson: so, do you just get all of your sleep during a winter hibernation period, or have you discovered a way to avoid it altogether?
<cjwatson> I do it in the mornings, when hackers are all asleep and don't notice
<SpamapS> I'd tell hackers that too if I had discovered the secret. They'd all want it.
<gtm> hi...is there someone able to export a driver from jaunty to be imported in lucid or maverick?
<TheMuso> gtm: If its an open source driver, it should already be in lucid or maverick no?
#ubuntu-devel 2010-10-13
<RAOF> gtm: What driver is it?
<RAOF> Too slow :)
 * BUGa_vacations headbangs on bitlbee
<ScottK> SpamapS: I think almost everything is other (for UDS sessions)
<SpamapS> ScottK: at least that makes it simple which track you want to attend. ;)
<ScottK> SpamapS: It's never simple for me.  I'm interested in a broad range of topics and am not bound by a job description to narrow my focus.
<SpamapS> ScottK: right, for you its always been this easy the. :)
<RoAkSoAx> I preferred the previos uds tracks naming conventions
<RoAkSoAx> Does fixing a missing pkg-config file installation in a package enought for a SRU?
<rneese> hey guys
<rneese> small issue I think needs fixing
<rneese> php5 pkg
<rneese> it should not force you to use apache when you apt-get install php5
<rneese> as there are other web servers out there
<micahg> rneese: it doesn't
<rneese> php5 should be its own install
<rneese> yes it does
<RAOF> RoAkSoAx: That sounds like a reasonable candidate for me; safe (as such things can be), correct, and fixes other people's builds.
<rneese> The following extra packages will be installed:
<rneese>   apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common libapache2-mod-php5 libaprutil1-dbd-sqlite3 libaprutil1-ldap libcap2 php5-common
<rneese>   ssl-cert
<rneese> thats with apt-get install php5
<micahg> !pastebin | rneese
<ubottu> rneese: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<sanduz2> i agree with rneese, if any of that stuff is not necessary for php5, id like to see it removed as well. many people are not using apache these days
<RAOF> rneese: You're looking for php5-cli
<micahg> rneese: apache is the default, if you have another webserver, you don't want to install the php5 package which is a metapackage
<RoAkSoAx> RAOF: awesome, thanks ;)
<rneese> where do i get php5-fpm
<micahg> rneese: you need one of these: http://pastebin.ubuntu.com/512071/, apache is first, hence it's the default
<RAOF> micahg, rneese: You can happily install the php5 metapackage and use a different web server; you just need to manually specify what web engine you want (php5-cgi, php5-fpm, etc).
<rneese> I am using nginx
<micahg> RAOF: I know that, we hashed this out a while back on the -server ML
<rneese> Couldn't find package php5-fpm
<micahg> rneese: you probably want php5-cgi
<micahg> rneese: php5-fpm is only in maverick and up
<rneese> it should be on lucid
<rneese> need it
<sanduz2> so if we just want the pure php5 for use in any webserver, the only thing we need is php5-fpm?
<sanduz2> (im on mav)
<rneese> if 10.04 uses 5.3.3 then php5-fpm should be in pkgs
<micahg> rneese: this is off topic for this channel, try #ubuntu-server
<micahg> rneese: 10.04 has 5.3.2
<micahg> sanduz2: unless you want FastCGI, you probably want php5-cgi
<sanduz2> oh, hm. im using cherokee so im not sure what to get. thanks
<RoAkSoAx> cjwatson: http://releases.ubuntu.com/.manifest is again showing maverick ISO's only instead of all the other releases ISO's too
<persia> wgrant, I've been saved a couple times by dput's marker that something was uploaded.  I'd much prefer it didn't go away.
 * ScottK too.
 * ScottK has also foud it useful as a reminder of where stuff was uploaded sometimes.
<james_w> probably making it smarter about urls would be a good compromise
<persia> james_w, How do you mean?
<james_w> IIRC it thinks that if you upload to ppa.launchpad.net once then you don't want to upload there again, even if you are uploading to a different path
<persia> Oh, that's clearly a bug.
<james_w> plus making the error message clearer would be a good thing to do
<persia> Mind you, I don't like PPAs in general, so I'm not particularly excited about fixing that one :)
<hifi> whats up with maverick and libgdk-pixbuf2.0? it's missing the .la file for linking
<persia> Didn't it switch to pkg-config or something?
<hifi> actually I'm a bit confused as my home natty compiled freeciv without problems but my maverick can't
<hifi> and the packages are still the same
<hifi> (not counting the toolchain)
<pitti> Good morning
<ajmitch> morning pitti
<\sh> moins
<dholbach> Good morning! :)
<jsgotangco> dholbach: good night :)
<dholbach> hey jsgotangco
<dholbach> long time no see :)
<ajmitch> very long time, how are you?
<jsgotangco> yep startup work kept me out of irc
<jsgotangco> dholbach: i could have joined UDS now if i learned the dates sooner
<dholbach> jsgotangco, ugh... hopefully next time - it'd be great to see you again!
<jsgotangco> dholbach: i'm actually in the US now but have already scheduled some stuff during those dates
<dholbach> ahh ok
<dholbach> hey shang
<shang> dholbach: hey!!!
<shang> dholbach: how's going?!
<dholbach> shang, how are you doing?
<jsgotangco> dholbach: i dunno probably if you'll be in LA anytime after that
<dholbach> jsgotangco, there's no LA plans right now :)
<shang> dholbach: I am doing alright~ Congrats to the new release ~
<jsgotangco> hehe
<shang> dholbach: how about u? how's everything going for ya?
<dholbach> shang, very good very good - it's just ....ing cold here :)
<shang> dholbach: LOL, already?!
<dholbach> yeah, it's down to 4Â°C already
<jsgotangco> wow
<shang> dholbach: come visit Taiwan then, 30 right now (feels like 42)
<dholbach> holy cow :)
<shang> dholbach: wow, that is kind ...ing cold!!
<dholbach> sounds much better :)
<shang> I am not sure about better, but HOTTER for sure!!
<shang> :D
<jsgotangco> and humid
<dholbach> doko_, are we there yet? :)
<persia> dholbach, No.
<doko_> ?
<dholbach> doko_, I was just checking what was going on with natty :)
<shang> humid is about right!!
<doko_> no new gnome, so everything is fine
<dholbach> doko_, not yet
<majeru> hi there, I'm having a problem with 10.10 on my Dell T3500. it constaltly panics with the default 10.10 kernel
<majeru> the 10.04 kernel works fine
<persia> majeru, Support is in #ubuntu, help tracking down bugs in #ubuntu-bugs
<majeru> persia: I asked in Ubuntu a few days ago about this issue, it was a lot of noise and noone answered
<majeru> I'll try #ubuntu-bugs, though
<majeru> thanks
<cjwatson> RoAkSoAx: that's normal around releases.  but we can probably put it back now ...
<cjwatson> RoAkSoAx: (done)
<nigelb> g28
<ChrisH> I was asked from a friend on the option running ubuntu-mobile on a simvalley MOBILE XP-25 (currently installed with WM6). She is not an expert in Linux but using ubuntu on her Desktop for a longer time very happy. Any experience on this specific device? Or an URL to find find hints on ubuntu-mobile on specific devices.?
<persia> ChrisH, I'll recommend not attempting to run ubuntu-mobile anywhere.  Nobody is currently supporting it.
<persia> If you need a phone UI, the current best selection is kubuntu-mobile.
<persia> But that phone can't run current Ubuntu anyway: we no longer support that processor.
<persia> For future support requests, I'll recommend #ubuntu for general stuff, and #ubuntu-arm for ARM-architecture-specific questions.
<ChrisH> persia: Thanks for that feedback. So the sum-up: She needs to stay with WM6 as this old HW/CPU is no longer supported.
<persia> Not in Ubuntu.  Might be for OE or Debian.  I have no familiarity with that specific device.
<ChrisH> ubuntu-mobile pointed to ubuntu-devel as followp, thats the reason I am asking here.
<persia> Yep.  I don't fault you asking here for that reason: most folk asking for support would get shunted to #ubuntu immediately.
<hyperair> urgh. something happened to pulseaudio between lucid and maverick and now i'm getting superb underrun problems whenever system load goes up
<persia> Are you sure it was pulse, and not ALSA or the kernel?
<persia> Maybe test with JACK to help isolate?
<hyperair> persia: it's a custom kernel which hasn't changed since my lucid install.
<hyperair> persia: i've merged in alsa-next things during my last build
<persia> And you're also maintaining local ALSA userspace?
<hyperair> no i'm not.
<hyperair> hmm should i?
<hyperair> it didn't cause problems with lucid, which should have an older alsa userspace.
<persia> If you're maintaining a special ALSA kernelspace setup, I'd think it'd make sense to stay in sync.
<hyperair> hrm
<diwic> a newer kernel than userspace shouldn't pose a problem
<hyperair> i didn't think it would make a difference though
<persia> diwic, Theoretically :)  We've had issues with that before which led to a decision to continue to update the userspace stuff up through KernelFreeze rather than just FeatureFreeze.
<hyperair> =\
<diwic> for underrun problems you can make a PA verbose log to see if the underrun is between app -> PA or PA -> ALSA
<diwic> persia, okay, I assume there are always bugfixes we need to pull in
<persia> diwic, Basically, yeah.  Most of the upstream development is roughly in sync, so sometimes something gets fixed half here and half there, etc.
<persia> (and getting half a fix often results in a regression, because the one expects things the other doesn't supply)
 * doko curses 1pixel wide resize borders
<ion> doko: Super+middle mouse button
<ion> They should scrap the borders altogether whenever shadows are available.
<persia> ion, That pushes windows to the back of the stack for me.
<pitti> persia: alt+middle mouse (resize) and alt+left mouse (move) WFM
<pitti> but on a laptop, middle mouse is no easier than trying to grab a window border with a touchpad
<pitti> so for resizing you are doomed on a laptop either way
<ion> Whoops, alt indeed.
<ion> pitti: alt-F8
<pitti> ah
<persia> pitti, Ah, yes.  Alt+ works fine.  Super+ less so.
 * persia usually just uses Alt+space to get a useful menu
<persia> And Alt+space works for *any* pointer device you like :)
<bilalakhtar> Hi ari-tczew
<ari-tczew> hi bilalakhtar
<bilalakhtar> So as it was discussed yesterday, at the most Natty should be open my Friday, right?
<bilalakhtar> *by
<cjwatson> yes, I would expect so
<persia> It's really an unknowable date, but "soon", as it depends on everything actually working as the base is set.  Used to take 2-3 weeks, so this time is fast, really.
<cjwatson> it hasn't taken 2-3 weeks for a long time.
<cjwatson> I posted the figures for the last several releases here a day or two ago.
 * soren is still impressed when it's less than that.
<persia> True.
 * persia too
<tgardner> Does soyuz have a known issue? I can't get any of the normal package info from https://edge.launchpad.net/ubuntu/+source/linux-lts-backport-maverick
<cjwatson> tgardner: not one I've seen before
<cjwatson> I don't know what's up there
<tgardner> cjwatson, whom should I point at it?
<cjwatson> bugs.launchpad.net/soyuz
<wgrant> tgardner, cjwatson: The info there only updates daily.
<wgrant> Oh.
<wgrant> Another issue.
<persia> And this package hit the bad time?
<wgrant> That is an odd one.
<wgrant> tgardner: For now you want https://edge.launchpad.net/ubuntu/+archive/primary/+sourcepub/1333666/+listing-archive-extra
<wgrant> Not sure exactly what has gone wrong, though.
<tgardner> wgrant, just file bug #659882
<ubottu> Launchpad bug 659882 in Soyuz "No package information is displayed" [Undecided,New] https://launchpad.net/bugs/659882
<tgardner> filed*
<wgrant> tgardner: Do you mean the list of binaries that appears at the top of the page, or the broken expander next to the package version?
<tgardner> cjwatson, since you're the morning archive admin according to the wiki, I assume you'll process the maverick NEW queue sometime today?
<tgardner> wgrant, both
<cjwatson> sucks to be me
<nigelb> heh
<wgrant> tgardner: So, they're separate issues.
<wgrant> tgardner: The broken expander is because it exists only in PROPOSED.
<tgardner> wgrant, from a naive user point of view, they are one and the same.
<wgrant> The missing binary list is probably just because it is new, and the cron job hasn't cached its data yet.
<wgrant> Probably, yes.
<tgardner> wgrant, as for the binaries, its been over 24 hours since it was published.
<cjwatson> tgardner: linux-linaro/maverick-proposed/armel accepted
<wgrant> tgardner: Ah, OK, got it.
<wgrant> That one is a bit of both.
<wgrant> Sigh.
<tgardner> cjwatson, thanks. I was actually more interested in the lts meta package escaping purgatory
<cjwatson> oh, well, you said NEW, that one's in UNAPPROVED
<cjwatson> but I can look at that too
<tgardner> hmm, guess I should become aware of the difference between the 2 queues
<cjwatson> wait, I don't see the LTS metapackage anywhere
<cjwatson> current state is that maverick-proposed NEW is empty; UNAPPROVED has five items, cluster-glue, ubuntu-sso-client, simple-scan, xfce4-indicator-plugin, and linux-meta-linaro
<tgardner> cjwatson, I wonder if soyuz gobbled it up. I'll re-upload i a minute.
<cjwatson> tgardner: oh, wait, never mind.  it's the *lucid-proposed* NEW queue, of course
<cjwatson> wouldn't make sense for it to be in maverick :)
<tgardner> cjwatson, right. sorry if I wasn't clear.
 * ari-tczew is still waiting for opened natty.
<Keybuk> ARE WE THERE YET?
 * cjwatson passes ari-tczew an ice-cream
<ari-tczew> cjwatson: why ice-cream? :P
<cjwatson> "are we there yet?"  "can I have an ice-cream" :-)
<ari-tczew> oh, Keybuk. are you still maintainer of MoM?
<Keybuk> no...
<cjwatson> currently waiting for linux to finish building so that we have a fresh linux-libc-dev; then test-build something against that to make sure the world hasn't collapsed; then open if it works
<jdstrand> cjwatson: hi! is it ok to pocket copy things to natty now, or should I wait until natty opens?
 * jdstrand may get an ice-cream for that question
<cjwatson> jdstrand: if the copy is with binaries, it's ok
<cjwatson> I already did that for a few things
<jdstrand> cjwatson: cool, thanks
<cjwatson> which packages?
<jdstrand> cjwatson: virtinst and vm-builder, when they are done building
<cjwatson> from -security or -updates, I take it?
<jdstrand> well, -proposed actually
<cjwatson> hm, do we have to copy from -proposed?
<cjwatson> I guess if you're keeping an eye on it
<jdstrand> no, we don't. though as you said, I am keeping an eye on it
<jdstrand> (a very close one I might add)
<cjwatson> ok then
<cjwatson> incidentally, re ice-cream, security's monopolisation of powerpc buildds is slowing natty opening up by several hours ;-)
<jdstrand> heh
<jdstrand> well, tbh, those particularly builds originated from people outside of our team
 * cjwatson improves his life with  bzr alias build-merge="bd -S --package-merge"
<jdstrand> s/particularly/particular/
<chrisccoulson> cjwatson, sorry about that :(
<chrisccoulson> (taking over the buildd's)
<jdstrand> what a weird error message from scp:
<jdstrand> $ scp -r /tmp/foo sec-maverick-amd64.:/tmp1/
<jdstrand> scp: /tmp1/: Is a directory
<jdstrand> it actually is *not* a directory...
<jdstrand> (it doesn't exist)
<Chipzz> jdstrand: but that behaviour shouldn't surprise you?
<Chipzz> even if the error message isn't exactly clear
<jdstrand> Chipzz: the behavior no. the error message telling that /tmp1 is a directory when it isn't, yes
<cjwatson> it's actually from open()
<cjwatson> 21548 open("/nonexistent/", O_WRONLY|O_CREAT|O_LARGEFILE, 0755) = -1 EISDIR (Is a directory)
<cjwatson> man page says:
<cjwatson>        EISDIR pathname refers to a directory and the access requested involved
<cjwatson>               writing (that is, O_WRONLY or O_RDWR is set).
<cjwatson> so evidently the kernel checks that before it checks whether it exists
<cjwatson> not really directly scp's fault
<cjwatson> well, maybe it is, it's using O_CREAT of course
<cjwatson> https://bugzilla.mindrot.org/show_bug.cgi?id=1768
<ubottu> bugzilla.mindrot.org bug 1768 in scp "scp: wrong error message when destination directory ends with a slash and is missing" [Normal,New]
<cjwatson> heh, forwarded by me so I should have known ;-)
<jdstrand> hehe
<jdstrand> it certainly isn't a devastating bug, which is why I only mentioned it in passing :)
<cjwatson> I attached a patch there, but would prefer to wait for upstream to review/apply it
<amikrop> Hello, since I installed the proprietary nVidia drivers, my boot splash image disappeared, the boot resolution got too low, and I get ugly big letters instead. So, I installed startupmanager to fix that. But when I set resolution 1600x1200 (and other options such as "use splash image" and "no text during boot") I get a "out of sync" from my screen instead of the boot logo. Any help, please? What can I set as options to startup manager?
<amikrop>  to get my old nice boot splash graphics back? My screen resolution is 1920x1080.
<Keybuk> amikrop: if you want hi-res graphics, don't use the proprietary nvidia drivers
<amikrop> Keybuk: I have to. Can't I have a nice boot logo? I have big ugly letters instead (which are out of correct order, too).
<Keybuk> no
<ari-tczew> amikrop: might be your issue bug 653274
<ubottu> Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed] https://launchpad.net/bugs/653274
<amikrop> ari-tczew: thanks, I 'll have a look :)
<amikrop> ari-tczew: so, do you think that will help? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/653274/comments/13
<ubottu> Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver" [Undecided,Confirmed]
<ari-tczew> amikrop: I didn't use this one, so I won't give a warranty.
<ari-tczew> you can use this one on your responsibility
<amikrop> ari-tczew: which one did you use?
<ari-tczew> amikrop: nothing. I still have ugly plymouth screen.
<amikrop> ari-tczew: Every nVidia & Ubuntu user does, right? That is about 1/2 of Ubuntu users. Isn
<amikrop> Isn't that a critical bug?
<amikrop> It looks unprofessional and broken.
<Riddell> mdke: do you know how to get docs translations from po files to docbook?
<ari-tczew> amikrop: probably it's related to closed nVidia drivers. IMO it's high priority bug (not critical) and I agree, that a huge of Ubuntu users use this drivers, though Jockey suggests automatically instalation these drivers.
<ari-tczew> but core developers think that this bug is not in their responsibility.
<pitti> it's got little to do with "think"
<pitti> it's a closed-source driver
<pitti> we can't modify it
<ari-tczew> pitti: so bug should be reported upstream, right?
<pitti> ari-tczew: they are well aware of KMS
<pitti> but they won't/can't switch to it
<pitti> because of licensing issue
<pitti> (the kernel APIs necessary for this are GPL only, as far as I remember)
<ari-tczew> pitti: so release maverick with that ugly element - booting step making bad feedback about Ubuntu.
<ari-tczew> and Canonical should do everything to workaround this problem
<amikrop> pitti: I agree :S
 * pitti pats his intel card
<amikrop> it's very bad marketing, if anything
<amikrop> pitti: since there are workarounds (tinker with startupmanager or vga=xxx boot option) why couldn't they be default?
<amikrop> I mean, such options should be added automatically by the installation of the nvidia package
<pitti> they could, presumably
<cjwatson> the problem with setting a non-VGA-text graphics mode in GRUB is that it causes quite a few systems to oops at boot
<amikrop> pitti: It would be very good if they would
<cjwatson> we tried, and had to back it out
<tseliot> pitti: if the bootsplash is the problem, then Nvidia should just provide an fb device, no need for KMS
<cjwatson> we'll try again, but it's reliant on kernel improvements
<cjwatson> so, as ever, it's not quite that simple ...
<amikrop> cjwatson: could you please help me set startupmanager if I tell you some information about my screen, resolution, etc?
<apw> cjwatson, is your team aware of this blueprint: https://blueprints.edge.launchpad.net/burg/+spec/burg-as-default-bootloader
<cjwatson> apw: it doesn't surprise me, but I'm not interested
<cjwatson> burg is very much less well-maintained
<apw> cjwatson, fair enough indeed
<cjwatson> amikrop: no, I don't know enough about nvidia, sorry
<tgardner> that, and we've just barely gotten onto grub2.
<cjwatson> burg is a one-man fork by a developer who couldn't work with the grub2 team
<cjwatson> it has one or two appealing features which have got people interested, but it's better to work on grub2 which has a development team and a future
<apw> works for me
<amikrop> cjwatson: who could help me? I am basically looking for what to set to StartUp-Manager's Display->Resolution, Display->Color Depth and Advanced->Bootloader menu resolution as values. My screen resolution is 1920x1080 and depth color (I think) 24
<cjwatson> amikrop: I'm afraid I don't know, sorry
<amikrop> apw: could you help me, please?
<cjwatson> you could ask by methods other than IRC (e.g. askubuntu.com, the forums, ...)
<amikrop> cjwatson: aha
<cjwatson> asking on IRC is an "I hope there's somebody around in this channel right now who knows the answer" kind of deal
<apw> amikrop, yeah i have never used startup manager
<apw> is the effort worth it?  it can only be there for a few seconds
<amikrop> apw: I would like to see a nice graphic for a few seconds, than some big ugly displaced letters. There are only for a few seconds there, but they are there on every boot. That is, thousands of seconds, summed up :/
<amikrop> Anyway, I 'll try to tinker with StartUp-Manager. Thanks, everybody.
<slangasek> persia: megabyte changelog files> yeah, I know :/
<amikrop> Hmm, can't I find the Plymouth options nouveau used, and apply them now (to the proprietary drivers), as well?
<night_fox1> Hello! I'm doing this project which uses object recognition and classification in images to automatically create metadata, which can then be used to search a collection of images. It seems as though the best way to implement this would be as part of an existing search tool, like Tracker. So, I what the situation is in terms of gnome search tools in ubuntu, and if the ubuntu developers were...
<night_fox1> ...considering maybe introducing another search tool in a future version?
<night_fox1> Sorry, the start of that last sentence should have read "So, I was wondering what the situation is..."
<night_fox1> hello?
<lool> doko: Hey, I'm merging newlib and I think we can drop the override of confargs_spu; mind confirming?  The new rules look like this http://paste.ubuntu.com/512471/ and I think the first confargs_spu from Debian is actually ok; would you confirm?  (especially --target=/--program-prefix=; the rest definitely seems correct)
<doko> lool: can you check with a build on davis that it does build? debian newlib changes didn't always work out well
<lool> doko: I tried kicking a build in a non-virtual PPA
<lool> but for some reason my upload didn't reach it
<lool> I wonder whether uploads to natty PPAs work already
<ogra_ac> lool, TI complains too
<ogra_ac> (about maverick packages though)
<lool> ogra_ac: What's happening for them?
<ogra_ac> there might be a general issue with arm PPAs
<ogra_ac> nothing, see #ubuntu-arm
<slangasek> doko: are there any blueprints for UDS-N about toolchain version selection?
<slangasek> doko: I'm assuming there needs to be an ongoing discussion about whether Ubuntu should use the Linaro GCC builds, and that it's not a foregone conclusion :)
<lool> ogra_ac: They seem to mention that builds don't start; my upload isn't even accepted here
<doko> slangasek: no, just going forward with 4.5 now. I think it's late for 4.5, but yes, we should have an evaluation what to do with 4.6. maybe 4.4 linaro was a special case because it had the whole cs patches too
<slangasek> doko: when you say "late for 4.5", what do you mean?  Do you mean it's too late for Ubuntu to take the Linaro patches for gcc 4.5?
<lool> actually I have an error message:
<lool> Cannot build any of the architectures requested: i386 amd64 armel ia64 powerpc
<lool> sparc ppc64 all
<doko> slangasek: well, already started with 4.5 linaro for natty, and we had the linaro bits in maverick too
<doko> anyway, afk now
<slangasek> doko: oh, so the patches are already there so there's nothing to discuss? :-)
<slangasek> doko: ok, cheers
<doko> slangasek: there is, for 4.6, and there are definitely changes in the branches which are non-optimization changes
<slangasek> doko: ack
<smoser> stgraber, around ?
<jdstrand> cjwatson, pitti, slangasek, kirkland, james_w`, Riddell, StevenK: fyi-- as per the kernel-team@ mailing list, there is a backported maverick kernel in lucid-proposed now. I wanted to bring to your attention bug #660077. This bug is for an apparmor SRU that needs to be pushed before/at the same time as the lucid-proposed backported kernel
<ubottu> Launchpad bug 660077 in apparmor (Ubuntu Maverick) "update AppArmor to 2.5.1 for backported maverick kernels" [High,In progress] https://launchpad.net/bugs/660077
<highvoltage> â Edubuntu Meeting in about 30 minutes
<highvoltage> (oops, I just realised I pasted that here, it was meant for another channel)
<ScottK> jcastro: Does it take some special magic to get LP to update status from remote Bugzillas?  It looks like we aren't getting updates from the clamav bugzila.
<jcastro> the bugwatch could be broken
<jcastro> it's supposed to be automagic
<jcastro> deryckh on #launchpad should know for sure
<lifeless> we're about to do an LP upgrade
<lifeless> you will want to wait for after that :)
<lifeless> ScottK: older bugzillas need a plugin, newer ones have it built in, and LP need an account on the bugzilla
<ScottK> lifeless: Is there some LP person who can investigate such things?
<ScottK> (I'm certainly not in a position to make LP accounts on remote bug trackers)
<lifeless> ScottK: I suggest filing a question on answers.lp.net/malone
<ScottK> lifeless: Will do.  Thanks.
<lifeless> ScottK: that will end up with folk that know fairly quickly.
<ScottK> Thanks.
* Chex changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Launchpad down/read-only from 22:00 - 00:00 UTC for a cod
* Chex changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | Launchpad down/read-only from 22:00 - 00:00 UTC for a code update
<Chex> third times the charm.
<BUGabundo> spammer
<BUGabundo> :)
<Amaranth> Is it just me or is launchpad logging everyone out after about 5 minutes?
<BUGabundo> no idea
<micahg> Amaranth: launchpad is about to undergo an upgrade
<Amaranth> micahg: Did they break something with the last one? This has been happening for some time now
<micahg> Amaranth: are you on edge?
<Amaranth> micahg: Yeah
<micahg> Amaranth: I've noticed some session issues recently, but I'm hoping they'll be fixed with this release
<Amaranth> it boots me off non-edge too
<Amaranth> Otherwise when I go to non-edge it would have automatically redirected me to edge
<micahg> Amaranth: me too, there was some type of notice of consolidating edge/production into 1 URL, but idk when that'll happen
<Amaranth> What the hell
<Amaranth> I just logged in on one bug then opened another and it wasn't logged in...
<Amaranth> Oh well, if it's still broken after the upgrade I'll file a bug or something
<wgrant> Amaranth: I've seen some reports of this happening to some users since the DB maintenance last week. But only a couple.
<wgrant> (everyone's sessions were dropped last Wednesday and Thursday, but some have apparently been having subsequent issues)
<wgrant> If you still see strangeness after the release, please file a bug.
<Amaranth> wgrant: How long is a session supposed to last?
<wgrant> Amaranth: A year, I think, except when the session DB is cleared.
<Amaranth> Ok, I know it has been less than that for me for longer than a week
<wgrant> Odd. I remain logged in for months without trouble.
<replicasex> Hey guys, really quick question and I'll be out.  Is the new version of xorg currently in 10.10 going to be pushed to 10.04?  Because it didn't play well with my system and the nvidia driver, just wondering if I'll have to watch out for that update.
<ion> It wonât. Thatâs pretty much the point of stable releases.
<replicasex> ion, thank you very much.  I really appreciate the ubuntu community :D  I'll let you get on with your day
#ubuntu-devel 2010-10-14
<SpamapS> darn it.. just when I thought I'd help out with the bug triage lp goes ro..
<micahg> SpamapS: relax, you caught the tail end of it :)
<SpamapS> micahg: unfortunately I also caught the tail end of my time for today.. :-P
 * SpamapS decides to use ip over avian carrier, which should make his ajax calls take long enough where lp will be rw by the time snowflake and mr. chirpy get there.
<micahg> SpamapS: you know there's an RFC for that, right?
* Chex changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment
* Chex changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<crimsun> hmm.
<crimsun> ogra_ac: do you need to roll an additional card config into alsa-lib for maverick-proposed?
<BUGa_BDAY> when did totem stop making and allowing bookmarks?
<persia> crimsun, From the dicussions I saw ~13 hours ago, I believe that was the expressed desire: to add /usr/share/alsa/init/sdp4430 (or similar), with an appropriate patch to 00main.
<mattyb> fta: you around?
<micahg> mattyb: probably not for another 2-3 hrs
<mattyb> Thanks.
<crimsun> persia: hmm, ok.  That would be alsa-utils, then.
<persia> OK.  I'll add an alsa-utils task to 637947.  I think the total solution was some kernel changes, the 652035 SRU, and the alsa-utils file.
<persia> (i was hoping for kernel changes so that the alsa-utils change wasn't required, but it doesn't seem like that will happen)
<crimsun> ok.  [ubuntu/maverick-proposed] alsa-lib 1.0.23-1ubuntu2.1 (Waiting for approval)
<crimsun> gone for a couple days.
<persia> crimsun, Thanks a lot.
<pitti> Good morning
<pitti> jdstrand: ah, thanks for the ping
<geser> Guten Morgen pitti
<YokoZar> pitti: Should I upload a -proposed icoutils then?
<pitti> YokoZar: sure
<pitti> if it's necessary
<dholbach> Good morning!
<pitti> hey dholbach
<geser> Good morning dholbach
<dholbach> hey pitti, hey geser
<pitti> micahg: I need some more info in bug 625801
<ubottu> Launchpad bug 625801 in gnome-web-photo (Ubuntu Lucid) "gnome-web-photo missing required libxul.so" [Medium,Fix committed] https://launchpad.net/bugs/625801
<apw> cjwatson, ok that overnighter also failed to build for a new error, i have a fix for the error it hit, but am flying blind fixing it as i cannot do a full build on the porters due to chroot issues... do we want to hope this fixes it en-toto or wait for the porters to be fixed
<apw> s/fixing it/testing it properly/
<Laney> doko: can you look at bug 660257?
<ubottu> Launchpad bug 660257 in ghc6 (Ubuntu) "linking fails with binutils 2.20.51.20101009-0ubuntu1: cannot use --sysroot" [Undecided,New] https://launchpad.net/bugs/660257
<pitti> mr_pouit: would you like me to apply the "eject button" thunar patch to the PPA? (http://bugzilla.xfce.org/show_bug.cgi?id=3658)
<ubottu> bugzilla.xfce.org bug 3658 in core "icon for eject volumes on side pane" [Enhancement,Resolved: fixed]
<pitti> oh, it got committed upstream \o/
<pitti> odd, I didn't get a mail about it
<bilalakhtar> What happened? Where is dholbach?
<pitti> mr_pouit: so, not so urgent then, it'll just flow in with new upstream versions then
<TheMuso> c
<persia> So, I'd like to call some python from a postinst: is there a best-practice method for where to put the python script?
<doko> Laney: ok, fixing with next upload
<Laney> doko: thx, will you reassign?
<zyga> mvo, is it normal that extras.ubuntu.com key is not installed by default? the key missing here is 16126D3A3E5C1192
<mvo> zyga: it should be there, do you have ubuntu-extras-keyring (the package) installed?
<mvo> zyga: is that a server install?
<zyga> mvo, no it's unity install
<zyga> mvo, ubuntu-extras-keyring installed 2010.09.27
<zyga> mvo, any place I could look to understand why the key is not picked up
<dholbach> http://ubuntuforums.org/showthread.php?t=1588889 mentions it too
<YokoZar> pitti: made that icoutils upload
<mvo> zyga: could you please try a apt-get install --reinstall ubuntu-extras-keyring? there was a bug in the package during mav that prevented it from getting applied
<zyga> mvo, yup
<zyga> mvo, that fixed it
<zyga> wow, new django
<zyga> (offtopic but important for me)
<Kaoruchan> any bug on 10.10?
<soren> I have a problem with a daemon written in Python. It depends on a python library package, and like most daemons it starts itself in its postinst. However, the python-support is deferred (using dpkg triggers), so once the daemon tries to start itself, the python module hasn't been python-support'ed, so it's nowhere to be found.
<soren> I can't imagine I'm the first to encounter this. What's the trick?
<StevenK> I thought there was a way to force a trigger to run
<soren> To trick python-support into running from the daemon's postinst?
<soren> StevenK: There is. update-python-modules -p, iirc.
<soren> I just wasn't sure if that was kosher.
 * soren assumes it is and adds it
<SpamapS> Doesn't dh_python2 fix this by just installing the .pyc files in the .deb in the right places?
<soren> I sure hope not.
<cjwatson> why do you hope not?
<cjwatson> though as it happens I think byte-compilation is still run-time in dh_python2
<soren> Becuase there's only supposed to be .pyc files for the python version that the end user has installed.
<soren> python version_s_, I mean.
<soren> ...and a bunch of other reasons.
<cjwatson> yeah.
<cjwatson> http://www.python.org/dev/peps/pep-3147/ will help.
<soren> Basically all the reasons why this stuff happens at isntall time.
<soren> I've added a call to "update-python-modules --post-inst" after #DEBHELPER# in my base python package (on which the daemon's package depends). That should take care of business.
<cjwatson> dh_python2 should fix this differently, though; byte-compilation is kind of a red herring
<soren> I've always wondered how much processing time is saved on that account. Do we have any numbres on that?
<cjwatson> relying on a trigger to make the package usable is obviously wrong; it means that the package is lying when it says it's configured
<SpamapS> I thought the way they did it was by putting the .py's in /usr/share/pyshared, and then putting .pyc's in the appropriate /usr/lib/python$ver dirs in the .deb .. I could be wrong.. still wrapping my head around the 3 or 4 ways to build python packages. :-P
<soren> cjwatson: Right. That's what python-support does, though.
<cjwatson> SpamapS: dh_python2 doesn't rely on a trigger
<cjwatson> soren: so don't use it. :)
<soren> cjwatson: It's not (just) me.
<soren> It's /every/ python package in my dependency chain.
<SpamapS> cjwatson: right, which is why it is "the new hotness" .. but I don't recall how it does that. ;)
<soren> If just one of them uses python-support, I'd be screwed.
<cjwatson> ah.  unlucky.  working around it with update-python-modules is probably fair enough for now, and hopefully it won't be a problem a couple of releases down the line
<cjwatson> SpamapS: um.  not using triggers involves *less* effort. :-)
<cjwatson> triggers are a fancy optimisation, wrong in this context
<cjwatson> dh_python2 just does the straightforward thing of pycompile in the postinst instead
<SpamapS> cjwatson: I think we're both saying the same thing, but my snark and your precision is producing a lot of confusion for me. ;)
<cjwatson> (and yes, there's a bunch of stuff about getting the installation paths exactly correct, but in this context that's kind of a side issue IMO)
<SpamapS> cjwatson: I don't think dh_python2 does byte compiling in postinst.. I'm fairly certain the .pyc's are *in the .deb*
<persia> Oughtn't be.
<SpamapS> You simply define the supported versions of python and it byte compiles for all of them.
<wgrant> I really hope not.
<wgrant> We'd then need to rebuild the other half the archive when we introduce Python 2.7.
<SpamapS> would that be so bad? Simple maintainer scripts vs. rebuilds every few years?
<persia> SpamapS, Yes.
<StevenK> SpamapS: Yes, because .pyc files can be different per architecture, and most python packages are arch-indep.
<SpamapS> I mean, we have to rebuild stuff when ABI's change all the time. python's just another ABI, no?
<persia> Because we change something related to supported python versions or default python versions nearly every cycle, and we very much don't rebuild that much of the archive each release.
<wgrant> Such core libraries rather rarely break ABI.
<wgrant> For good reason.
 * SpamapS *IS* still talking out his arse on how he thinks dh_python2 works, so please, do not get your torches and pitchforks yet
<StevenK> And ignoring that problem, it also means you effectively double the size of each python package in the archive
<cjwatson> SpamapS: look at /usr/share/debhelper/autoscripts/postinst-pycompile, which dh_python2 substitutes into postinsts.
<cjwatson> in fact the header of dh_python2(1) says this too: "dh_python2 - calculates Python dependencies, adds maintainer scripts to byte compile files, etc."
<SpamapS> cjwatson: indeed, I was just starting to understand dh_python2's source. I guess I was just confused by POX's presentation saying that dh_python2 had "all files in the package": http://people.debian.org/~piotr/dc10_slides.pdf
<cjwatson> I think he means that it doesn't have a symlink forest for the .py files
<cjwatson> hence the "dpkg friendly" bit - it means that you can look at where you're loading the .py file from, and use 'dpkg -S' without having to follow symlinks around
<SpamapS> Right, thats much better. :)
<ari-tczew> pitti: could you merge cdbs?
<pitti> ari-tczew: I already did
<pitti>       cdbs | 0.4.89ubuntu1 |         natty | source, all
<ari-tczew> pitti: ah, nice!
<ari-tczew> MoM sucks
<ari-tczew> pitti: so cdbs is a part of toolchain? where can I find a fulllist packages related to toolchain?
<pitti> ari-tczew: I don't know whether there's a written-down list
<pitti> compilers (gcc, g++, gdc, gcj, etc.), perl, python, debhelper, cdbs, kernel (for linux-libc-dev), binutils, glibc
<cjwatson> there isn't, to my knowledge, it's just the stuff that practically everything build-depends on and that tends to have substantial changes which we want in place early
<cjwatson> (e.g. not (say) sed because it hardly ever changes in ways we care about)
<persia> I'm certain there isn't a written down list, and creating one would be tricky except by looking at the set considered "toolchain" just after an archive opens.
<cjwatson> pitti's list above is roughly what I think of
<cjwatson> ari-tczew: MoM sucks> why's that?  it doesn't list cdbs, because pitti already merged it.  this seems correct.
<ari-tczew> cjwatson: it lists quilt, for example
<ari-tczew> also annoying bug which shows comments added in the past
<cjwatson> that's odd, and I will have a look.  perhaps in future you could phrase this as a bug report rather than a thoroughly unhelpful snark.
<ari-tczew> cjwatson: bug 596599
<ubottu> Launchpad bug 596599 in Merge-o-Matic "MoM shows previous comments" [Undecided,Confirmed] https://launchpad.net/bugs/596599
<cjwatson> yes, I meant the quilt bit.  I already knew about the comments bug.
<ari-tczew> ok I'll report a next bug
<cjwatson> don't bother now, I'm looking at it
<cjwatson> I didn't specifically mean "must be a bug report on launchpad", I meant "must actually contain detail rather than just being rude about it"
<ari-tczew> okok
<ari-tczew> btw. awesome knowledge
<cjwatson> quilt seems like a stale merge left over from the past.  I'm not sure yet whether this is due to a current bug, or an old bug that wasn't cleaned up after properly
<cjwatson> hmm, it's in merge-blacklist.txt
<cjwatson> I think that must be stale, given that it's in sync
<cjwatson> I've removed it from merge-blacklist.txt, so the stale merge should be removed when MoM next runs
<cjwatson> thanks for the report
<micahg> pitti: commented on the bug
<seb128> lamont, hey
<seb128> lamont, https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+build/1994816
<seb128> seems you didn't stop the build yesterday or that didn't work?
<seb128> it's building still for 2 days
<seb128> same issue on https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+build/1996029
<seb128> not sure what's going on
<seb128> the i386 version built in less than 20 minutes
<smoser> stgraber, ping
<ari-tczew> huh, linux source exists in queue
<cjwatson> not any more :)
<SpamapS> So, it seems I b0rked php5-pgsql in maverick.. I've prepared an SRU.. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/660227  anybody want to help speed that one in to maverick-updates?
<ubottu> Launchpad bug 660227 in php5 (Ubuntu) "php5-pgsql crash on getting an error back from postgres" [High,In progress]
<ari-tczew> SpamapS: subscribe ubuntu-sponsors
<SpamapS> ari-tczew: I've been told on multiple occasions not to do that if using UDD.
<ari-tczew> SpamapS: you can set reviewer as ubuntu-sponsors, then you don't need subscribe sponsors to bug.
<ari-tczew> and you can do it inversely: subscribe ubuntu-sponsors to bug, but not assign as reviewer
<SpamapS> ari-tczew: ok. I'll add them to the merge proposal then
<zul> SpamapS: or you could ask me
<mdeslaur> does anyone have any idea what could be causing bug #647404?
<ubottu> Launchpad bug 647404 in udev (Ubuntu) "Udev worker error during boot "worker [XX] did not accept message -1 (Connection refused), kill it" [Undecided,Confirmed] https://launchpad.net/bugs/647404
<SpamapS> zul: ^^ see above for where I asked you, and anybody else in here. ;)
<mdeslaur> it's really annoying
<SpamapS> zul: I was going to wait an hour or so before I started pumping narwhals narwhals into your mumble until you agreed to help me. ;)
<zul> SpamapS: can you make a debdiff for me?
<ari-tczew> zul: just download diff from bug.
<ari-tczew> SpamapS: ah, bug in debian/changelog. change ubuntu10 to ubuntu 9.1
<SpamapS> zul: you're so stubborn
<ari-tczew> cjwatson: could you merge usbmount?
<cjwatson> ari-tczew: I guess, but doesn't coolbhavi have first refusal on it?  he touched it last
<cjwatson> it's not a package I remember touching before, so not entirely sure why you're asking me
<lucidfox> Anyone here with lwn.net subsription?
<persia> lucidfox, https://wiki.ubuntu.com/Membership/LWN can get you one quickly enough.
<nigelb> lucidfox: yes
<lucidfox> Bah, bureaucracy... I just want to look at one article
<lucidfox> nigelb, could you pastebin http://lwn.net/Articles/409033/ for me?
<lucidfox> you can link it in PM
<persia> lucidfox, Up to you, really :)
<ari-tczew> cjwatson: dunno, I didn't ask coolbhavi. I've looked into code and it's strange to merge (for me). You're familiar with similiar packages, so I pinged you.
<nigelb> lucidfox: doesnt hurt to send marianna a mail :)
<tumbleweed> lucidfox: I've asked LWN's corbert about this in the past, he's totally ok with sharing links publically: http://lwn.net/SubscriberLink/409813/5ff58cc12efd02fa/
<cjwatson> ari-tczew: by convention, the person listed as touched-it-last on merges.ubuntu.com gets to merge it first.  if you want to merge it, you should ask that person to ensure that you aren't duplicating work.  otherwise, it's generally up to them to hand it off to somebody else if they don't want to do it.
<cjwatson> so I'm not going to grab a package I'm unfamiliar with in the first few days of the release cycle unless and until the touched-it-last person says they can't do it (and even then, I have far too many of my own merges to do)
<ari-tczew> cjwatson: ok I'll ask with coolbhavi. btw. probably you have to merge a lot of reds packages from main? (MoM UI)
<cjwatson> the installer always shows up as high on that list, since it uses the Priority field differently from everything else
<cjwatson> I've already uploaded 34 merges, it's just that most of them are waiting in the queue until the toolchain's sready
<cjwatson> *ready
<ari-tczew> aha
<alecu> hi all, is there a plan for process isolation for apps installed from untrusted sources (ie, universe, propietary stuff from the software center)?
<alecu> I've seen that iOS and sugar from the olpc already have something like this, using different unix users for each process.
<kklimonda> alecu: I'm not convinced that the "mobile" model (as done by iOS and Android) is something desirable on Desktop systems. But there have been an acknowledgment of this issue in the recent disussion about application review board so it may be discussed at the UDS.
<johanbr> alecu, how would that work? programs need to able to read and write your files after all
<superm1> johanbr, on android, the app has to request permissions to use your SD card, otherwise it has a partitioned off directory it's allowed to write to on the data partition
<kklimonda> right, the main problem is that both iOS and Android were build from base with isolation in mind.
<alecu> johanbr, right, they need to read some files, but surely not every file.
<johanbr> alecu, right, but how could you tell which ones?
<johanbr> maybe I'm weird and like to use acrobat reader to read pdfs stored in /usr/lib...
<Chipzz> what are pdfs doing in /usr/lib?
<alecu> johanbr, then you are an advanced user and may disable this kind of checks :-)
<pitti> Chipzz: I only have /usr/lib/pymodules/python2.6/cherrypy/tutorial/pdf_file.pdf
<kklimonda> alecu: then everyone is going to disable it the moment they encounter the first problem.
<Chipzz> pitti: looks like a packaging bug to me ;)
<pitti> *nod*
<Chipzz> pitti: that should probably be in /usr/share/doc
<kklimonda> alecu: one way to do it would be to force all applications to be shipped with apparmor profiles. But who's going to write them? It's not exactly an easy thing to do it right :)
<alecu> kklimonda, perhaps have a (kinda restrictive) default apparmor profile
<Chipzz> johanbr: but anyway, since pdfs are arch indep, they should go in /usr/share at the very least. a pdf in /usr/lib is a bug
<kklimonda> it would require us to patch GLib and Gtk+ to provide useful error messages when software tries to access something it has no access to.
<alecu> kklimonda, also, I would not trust apps from the moment they are being installed. I should not trust even the script that is run as root when the package is installed.
<kklimonda> alecu: I don't know if apparmor has a "default profile" at all and how would that work? Applications have to access dozens of files outside of $HOME to work.
<alecu> kklimonda, I don't mind those system files.
<alecu> kklimonda, I'm worried about my personal files
<alecu> kklimonda, it's the stuff in $HOME I want to protect
<alecu> my keyring, my personal files.
<pitti> not allowing universe apps to access $HOME sounds pretty useless, though
<Chipzz> kklimonda: read access to /etc/* and /usr/lib/lib*so*, no access otherwise sounds sane I think?
<kklimonda> alecu: right, it can be done already using apparmor (evince doesn't have access to keyring etc.)
<alecu> I think there are a lot of small details concerning this, and I don't know enough about this, only that some systems are doing it in a safe(?) way.
<alecu> so, I'm only proposing that if enough people is interested we may ask for a slot at uds
<kklimonda> Chipzz: read access to all folders so file dialogs work as expected is also required. And some other things, you can take a look at /etc/apparmor.d/usr.bin.evince to see how could an application be locked in.
<kklimonda> alecu: what systems? if you think about iOS and Android then it's not really the same.
<kklimonda> I don't even know of Fedora have a SELinux in deny (or however it's called) mode by default.
<alecu> kklimonda, I'm thinking about iOS, Android, sugar (as used in olpc) and web browsers.
<alecu> so, any system that can run apps from an untrusted sources.
<kklimonda> neither Windows nor Mac OS X has such a mechanism in place.
<alecu> kklimonda, right, not yet.
<kklimonda> sugar may be worth taking a look at as it's a linux distribution to some extent (isn't it?)
<alecu> sugar is a user interface written in python that runs on top of linux
<kklimonda> android also runs on top of linux but is a completely different beast so that description is misleading :)
<alecu> kklimonda, btw: the designer of the sugar security mechanism is working at apple now :-)
<alecu> kklimonda, right! I'm not saying we should use exactly the same mechanism that any of those uses
<kklimonda> the question is how can it be done when we already have both a huge number of existing applications and full platform.
<alecu> I would not worry about "how" yet :-)
<alecu> I want to understand if this is really needed.
<kklimonda> it si
<kklimonda> it is even
<alecu> My gut feeling being that we will be running more and more apps from untrusted sources.
<kklimonda> indeed
<alecu> and that I should only allow a very small set of apps near the more sensitive stuff (my keys)
<johanbr> right... I guess limiting access to some of the sensitive stuff should be doable (encryption keys, maybe browsing history, ...)
<kklimonda> it's actually pretty complicated stuff - some application store passwords in gconf so you would have to be able to limit access to gsettings, same with desktopcouch..
<alecu> I need to do some more reading on bitfrost and the security model of qubes... :-)
<ari-tczew> cjwatson: next case, ffmpeg-php exist in MoM, but package is up-to-date
<stgraber> smoser: pong
<smoser> stgraber, so i'm pinging about a "desktop in the cloud" session
<smoser> if you would be interested in helping to host one, and have interest in possibly doing something further with the -desktop images for natty
<stgraber> smoser: I guess it'd be nice if we can have someone to package properly either x2go or freenx for natty. Then we can make a good desktop image using it.
<smoser> yeah. x2go is a mess. i poked around the other day just trying to find source.
<jcastro> robbiew: rickspencer3: davidm: davidbarth: pgraner: Riddell: jiboumans: ara: we are running the scheduling script today
<stgraber> smoser: it'd probably be interesting to host a session like that, hoping to find someone with interest and time to do the packaging
<jcastro> the more blueprints you accept before EOD today the less manual scheduling you will need to do
<smoser> and i know you mentioned it not really building from source.
<ara> jcastro, what's the script for?
<jcastro> it will autoschedule all the sessions you've accepted in the grid
<jcastro> after that you have to drag them on there yourself
<stgraber> smoser: yeah, it's a bit of a mess. I guess it builds fine on the developer's machine with all source packages unpacked in the same directory. Trying to build them individually doesn't seem to work at all.
<jcastro> which isn't hard
<jcastro> it's just an FYI
<smoser> there is just so much potential for coolness there.
<stgraber> smoser: yep
<smoser> especially with the added browser plugin
<smoser> alright.
<smoser> i'll add a blueprint stgraber
<smoser> thanks.
<davidbarth> jcastro: ok; oubiwann is concerned as well ^^
<seb128> cjwatson, do you know if there is any work to port debconf away from libgnome?
<seb128> ideally it would use plain gtk only
<seb128> cjwatson, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542175
<ubottu> Debian bug 542175 in debconf "Port GNOME frontend to GtkAssistant" [Normal,Open]
<seb128> cjwatson, https://bugs.edge.launchpad.net/ubuntu/+source/debconf/+bug/415038
<ubottu> Launchpad bug 415038 in Baltix "port GNOME frontend to GtkAssistant" [Undecided,New]
<seb128> cjwatson, is there any change you could take over this bug in natty?
<seb128> or add it to your review list?
<cjwatson> ari-tczew: ffmpeg-php is on the sync-blacklist because of an .orig.tar.gz mismatch.  I've removed the merge directory manually
<cjwatson> seb128: nobody's working on it right now, but it probably wouldn't be horribly hard.  I'll add it to my list
<seb128> cjwatson, the bug has a patch so with some luck it's only reviewing and commiting
<seb128> cjwatson, thanks ;-)
<cjwatson> yeah, janimo's patch looks like a decent start
<davidm> jcastro, you might want to hold off another day, but that is up to you.
<cjwatson> seb128: (though just queueing up in the browser for now, as I'm trying to catch up on vast piles of e-mail)
<seb128> cjwatson, (no hurry, but I would like to drop libgnome from the CD this cycle if possible and it's one of the remaining users)
<seb128> seems we could at least drop the perl bindings easily
<SpamapS> mathiaz: hey, I just had an epiphany about your seed cleanup voting/commenting app
<BUGa_bday> bye guys. bday party
<kirkland> slangasek: did you tell me that a tool exists that draws upstart job dependencies?
<slangasek> kirkland: yes, but it turns out it wasn't very good
<kirkland> slangasek: bad enough to be useless, or just not very good?
<ogra_ac> kirkland, isnt that tool called Keybuk ?
 * ogra_ac wonders about Keybuks drawing capabilities
<mathiaz> SpamapS: shoot!
<slangasek> kirkland: bad enough that I didn't see any use in it; it doesn't distinguish between AND and OR dependencies, has no information about what generates various events except for the start/stop ones, and only graphs statically based on the files on disk - so isn't useful for analyzing anything that happens during an actual boot
<slangasek> kirkland: I hinted the author to to improve it along these lines, didn't get a response
<ahs3> slangasek: do you recall the name of the tool?  i'd rather improve something than re-invent it?
<slangasek> ahs3: honestly, I don't think you'll lose much time re-inventing; but let me see if I can find it
<ahs3> slangasek: if you can't, no worries.  i've sorta hacked something together already (but it ain't pretty)
<barry> does anybody know when $ does anybody know when $UBUNTU_MENUPROXY started showing up in the default user environment, and where it comes from?
<SpamapS> mathiaz: so, the way you approached it was basically "identify which ones need to go" right?
<mathiaz> SpamapS: yes
<SpamapS> mathiaz: what if you turn it around and require everything to get at least one vote to stay?
<mathiaz> SpamapS: well - things are pulled in automatically
<mathiaz> SpamapS: because of dependencies/recommends
<SpamapS> nobody wants to stick their neck out for something that might hurt others by removing, but I'm sure everybody has strong feelings for what they want to keep.
<SpamapS> mathiaz: IIRC, it was mostly about the things that were seeded, not the dependencies that had been pulled in. no?
<mathiaz> SpamapS: right - the thing is that the list of what is *pulled* in is short
<mathiaz> SpamapS: it was mainly about the dependencies/recommends pulled in
<SpamapS> ah
<mathiaz> SpamapS: the goal is to clean up what's in main and really look why things are pulled in
<SpamapS> yeah, same thing then
<mathiaz> SpamapS: the actual list of packages we want is short and available from all the preseed files
<SpamapS> if nothing else, have an up/down vote, and things with 0 points or less would be good candidates for close examination
<SpamapS> also what was the feeling on comparing it to popcon ?
<mathiaz> SpamapS: popcon is not a reliable source of information :/
<SpamapS> mathiaz: I figured as much.
<mathiaz> SpamapS: the goal is more about identifiying recommends that could be dropped
<SpamapS> mathiaz: ah, by simply moving them to Suggests ?
<mathiaz> SpamapS: yes
<SpamapS> mathiaz: so still.. I think any recommends that don't get votes up would be good to move to suggests.
<mathiaz> SpamapS: agreed
<mathiaz> SpamapS: now the thing is to identify which are recommends
<mathiaz> SpamapS: and that includes going through the whole list of 300+ packages
<SpamapS> mathiaz: rdepended_packages=$(apt-cache rdepends `list of seeded packages` | sort -u)
<SpamapS> if package not in rdepended_packages and not in seeded_packages then recommended = True
 * SpamapS would probably dump it into sqlite just to make it simple.
<mathiaz> SpamapS: http://bazaar.launchpad.net/~mathiaz/+junk/get-server-pkgs/files
<mathiaz> SpamapS: ^^ this is the script I've used to generate the list of srv packages IIRC
<mathiaz> SpamapS: it uses the germinate output which has more info then apt-cache IIRC
<mathiaz> SpamapS: especially to figure out why something has been pulled into main
<mathiaz> SpamapS: http://people.canonical.com/~ubuntu-archive/germinate-output/
<mathiaz> SpamapS: ^^ has the complete chain for each package
<YokoZar> pitti: My new icoutils SRU got rejected because it's in main, can you upload for me (just a simple backport of the maverick package is all it is)
<SpamapS> mathiaz: ah nice, ok well I just thought if that effort was going to continue in natty that we should look at how to get more data.
<GPenguin> sabdfl: when did you last spoke in an interview about the importance of a well working IRC Council?
<GPenguin> sabdfl: it seems like you tend to delegate community related topics to other people and focus on new features instead. but i would be very curious about a few things that affect the _people_
<sabdfl> who are the underscore people?
<GPenguin> sabdfl: mainly german people who use Ubuntu as this group is a tricky, as we have a history like no other country
 * ogra_ac glares at GPenguin and wonders what he talks about 
<sabdfl> history is history, we all have it, we all share it, we all come from the same monkey, the same time ago
<GPenguin> sabdfl: i think that i remember, that one of your driving reasons to start Ubuntu as project was, that Debian as a project suffered a lot from social problems. and to me, it seems like we are going there in the german community
<GPenguin> and i am a bit helpless with the IRC Council and the Community Council who seem to underestimate the problem
<sabdfl> no, Ubuntu is not a critique of Debian in any sense, but if I can help avert a social issue in the Ubuntu Germany community, let's talk
<GPenguin> sabdfl: would you prefer a query or can we speak open here on channel?
<highvoltage> I'm not sure what GPenguin's problem(s) is, but he was going on about germans in #ubuntu-irc earlier today too... http://irclogs.ubuntu.com/2010/10/14/%23ubuntu-irc.txt
<GPenguin> highvoltage: i think sabdfl and me are adult enough to manage the conversation without your help
<GPenguin> my main point is, that the english speaking community seems to have somebody in Jono Bacon who inspires them, who keeps them motivated and on track
<GPenguin> and i think such a person is missing for most germans
<GPenguin> somebody who holds up morals and ethics in the most social way
<GPenguin> i think because of our history, we are tricky
<GPenguin> and i observed that many newbies suffer from angry helpers
<GPenguin> i think this is because most self organized channels recruit the wrong people who their access lists
<GPenguin> people who "process" help requests quickly on the one side, but also people who dont understand the social side of everything
<GPenguin> other nationalities dont seem to have this problem as much as we germans do
 * ogra_ac doesnt see that problem as a member of the german community and someone who frequently is in #ubuntu-de
<GPenguin> we dont need to count people for the moment
<ogra_ac> sorry, but i fail to see a single of the points which you talk about above in that channel
<GPenguin> we can do that later if thats needed
<GPenguin> ogra_ac: if you dont see a point then why do you join me?
<ion> â¦
<ogra_ac> GPenguin, well, you dont accept other opinions ?
<GPenguin> ogra_ac: "i dont see your point" is not an opinion. is a disturbance
<ogra_ac> i just stated that i have a completely different view of the german community
<GPenguin> ogra_ac: i missed that point, sorry
<GPenguin> but we can take a poll later of how many people are happy and how many people are unhappy in the german community
<ogra_ac> (and just on a sidenote this conversation doesnt really belong into the ubuntu development channel)
<GPenguin> for a start we can measure how often the term "troll" is used on that channel
<GPenguin> ogra_ac: are you an ubuntu member or just a friend of one of the channel operators from #ubuntu-de?
<GPenguin> ogra_ac: tell them i said hi
<ogra_ac> i am an ubuntu member and have several firends who are ... i have no idea if any of them is a channel operator in #ubuntu-de
<ogra_ac> i'm usually just lurking there and help out where i cn if i have time
<ogra_ac> as most of the other people do there
<GPenguin> ogra_ac: thats nice.
<ogra_ac> and i fail to see any different behavior to other ubuntu channels i'm in
<GPenguin> ogra_ac: so you had your point. thanks for sharing it
<ogra_ac> its usually friendly and helpful to all people in there
<GPenguin> i know other people who have a different opinion about this. and this opinion spreads across many different IRC networks, that german linux channels are hostile
<GPenguin> and i can prove it later when that is needed
<GPenguin> i worked on this topic since march this year
<highvoltage> GPenguin: either way, this topic doesn't belong on this channel, please take it elsewhere
<ogra_ac> ++
<GPenguin> highvoltage: yes, i am still waiting for feedback from sabdfl
<GPenguin> ogra_ac: no need to donate karma, you can use /ignore
<ogra_ac> GPenguin, no, since i do work in this channel (like everyone else whi is actively speaking here) and i told you above that this conversation is offtopic ... i just expressed my agreement
<GPenguin> ogra_ac: you can and you will have to use /ignore
<GPenguin> ogra_ac: otherwise i get the impression that you try to troll me while i try to talk to sabdfl
<sabdfl> back, sorry, was on a call
<sabdfl> GPenguin: this is an open channel, about development, in which highvoltage is a leader
<sabdfl> happiness for all is not always the goal in a group that wants to get something done
<sabdfl> because sometimes folks show up that don't have the same direction in mind
<sabdfl> the group then has to choose, between getting what it set out to do, done
<sabdfl> or trying to keep those folks happy
<sabdfl> have you raised your concerns with the irc council in an ameil to their list?
<sabdfl> email, sorry
<sabdfl> and beyond them, have you done the same with the CC?
<sabdfl> that's the process
<GPenguin> i wrote about 6 emails in total during the last 12 months. and the feedback was disappointing. exactly thats why i make some noise now, here and there. until the right people are looking into the problem that does exist.
<GPenguin> everybody tries to ignore the problem
<GPenguin> and thats alright if you guys do not continue to invite more and more people to IRC channels that cant handle the people
<sabdfl> how would you describe the problem?
<GPenguin> its a combination of personality problem ("i want to become a bastard operator from hell") and a burnout problem on the helper side
<GPenguin> its not new people anymore who join the chat room, its somebody who is too stupid to handle linux, its somebody who is aiming to cause trouble (a troll), etc.
<GPenguin> but its still potential contributors after all
<GPenguin> more and more people use Ubuntu who need guidance and not just a quick "do this and that"
<GPenguin> but the helpers on channel are not ready for that
<GPenguin> i am maybe not the right person to suggest this, but i would try a whole different approach. i would make channels like #ubuntu and #ubuntu-de a welcome area only
<GPenguin> people can get in touch with an advisor there and _then_ move on to specialized channels for support questions
<GPenguin> and helpers move from channel to channel aswell to avoid burnout
<mathiaz> kirkland: could you reject the openldap upload I did to maverick-proposedÃ
<mathiaz> kirkland: ?
<kirkland> mathiaz: looking ....
<kirkland> mathiaz: http://launchpadlibrarian.net/57612955/openldap_2.4.23-0ubuntu3.1_source.changes ?
<mathiaz> kirkland: yes
<kirkland> mathiaz: done
<mathiaz> kirkland: ta!
<mathiaz> kirkland: if ubuntu3.1 has been rejected from the queue, can I reuse ubuntu3.1 for the next upload?
<mathiaz> kirkland: or should I use ubuntu3.2 now?
<kirkland> mathiaz: better to use 3.2
<mathiaz> kirkland: ok
<kirkland> mathiaz: though if its rejected, technically you can use 3.1
<kirkland> mathiaz: i find it better to just use 3.2
<mathiaz> kirkland: right - but include 3.1 and 3.2 changelog entries in the .changes file?
<kirkland> mathiaz: yeah
<mathiaz> slangasek: while working on bug 658227 a debconf question needs to be reintroduced in debian/slapd.templates
<ubottu> Launchpad bug 658227 in openldap (Ubuntu Maverick) "upgrade process does not upgrade underlying BDB format from 4.7 to 4.8 (so slapd aborts with "Program version 4.8 doesn't match environment version 4.7" error message)" [High,In progress] https://launchpad.net/bugs/658227
<mathiaz> slangasek: that leads to the po files to be generated and updated
<mathiaz> slangasek: is that acceptable for a SRU?
<mathiaz> slangasek: http://paste.ubuntu.com/513398/ <- is the diff
<slangasek> mathiaz: I'm less worried about the template/translation diff than I am about the related code - had you pruned the code that went with that template, or was it just the template itself that was accidentally cut?
<mathiaz> slangasek: a bit of both :/
<mathiaz> slangasek: so the template was accidently removed
<mathiaz> slangasek: however it was also removed from slapd.config
<mathiaz> slangasek: but *not* from slapd.script-common
<slangasek> ok
<mathiaz> slangasek: which is the reason why it shows in the SRU - as the SRU will trigger the code path
<mathiaz> slangasek: should the slapd.config be also re-added?
<mathiaz> slangasek: should the slapd.config *code* be also re-added?
<slangasek> mathiaz: if you're not going to readd the slapd.config code, there's no sense in readding the template IMHO - you might as well just drop the check :)
<slangasek> (which I think would be worse)
<slangasek> so: yes, please readd the slapd.config code
<slangasek> mathiaz: has mathijs's merge of the slapd.d code helped much for having the packages back in sync for natty?  I haven't looked at how much his commits differ/resemble yours
<mathiaz> slangasek: hm - I haven't looked at this yet
<slangasek> no hurry
<mathiaz> slangasek: I think it's probably in good shape
<mathiaz> slangasek: natty might see the re-unification of the debian and ubuntu openldap packages
<slangasek> that would be nice :)
<hallyn> jcastro: hi, question on blueprints
<hallyn> dlezcano created https://blueprints.launchpad.net/lxc/+spec/server-natty-lxc-production-ready before the new naming rules were sent out
<hallyn> should it/can it be renamed?
<jcastro> yep
<jcastro> click on Edit Details
<jcastro> if you don't have permissions I can do it for you
<hallyn> i dont' think i do
<jcastro> hallyn: oh, it needs to be accepted first
<jcastro> I can do both if you want?
<hallyn> jcastro: that'd be great, thanks!
<jcastro> what track is it going in?
<hallyn> cloud i assume
<jcastro> hallyn: ah I see the problem, it's set as a blueprint under lxc in launchpad, not ubuntu, so we can't really edit it.
<jcastro> hallyn: I recommend registering a new one under ubuntu
<jcastro> https://blueprints.edge.launchpad.net/sprints/uds-n/+addspec
<jcastro> and then just copy and paste the text
<hallyn> and then i can still assign it to him?
<jcastro> unless you happen to be talking to the guy now and can tell him to move it
<jcastro> yep
<hallyn> ok, thanks, trying right now
<jcastro> is he attending UDS?
<jcastro> if so make sure you check "participation essential" so the scheduler doesn't double book him with another session
<hallyn> yup, he is
<hallyn> so 'For: ubuntu' then for all blueprints/
<hallyn> jcastro: so if it's largely a community blueprint, but server team is interested, should the team be 'server'?
<hallyn> (i.e. name cloud-server-n-containers-finetune)
<jcastro> hallyn: yeah
<hallyn> cool, thanks, created - https://blueprints.edge.launchpad.net/ubuntu/+spec/cloud-server-n-containers-finetune
<Amaranth> grr, going to kill launchpad
<Amaranth> I really don't want to clear all my cookies :/
<hallyn> jcastro: i don't see a 'participation essential' checkbox...
<jcastro> hallyn: when you subscribe him to the blueprint?
<jcastro> hallyn: got it
<jcastro> done
<hallyn> oh, i see, i ahdn't subscribed him...  sorry
<hallyn> jcastro: thanks
#ubuntu-devel 2010-10-15
<GanonKiller> can anybody here help me?
<TheMuso> GanonKiller: Just ask your questino. If people are around and can assist, they will.
<TheMuso> question
<GanonKiller> well pulseaudio keeps crashing
<GanonKiller> i am trying to fix it
<GanonKiller> i removed pulseaudio before & it killed gnome
<TheMuso> How does it keep crashing? have you filed a bug?
<GanonKiller> yes i have filed a bug report
<TheMuso> Do you have the bug number handy?
<GanonKiller> how do i find that out?
<TheMuso> GanonKiller: If you know your launchpad username, then go to http://launchpad.net/~username/+subscribedbugs and you should find it there, unless you decided to unsubscribe yourself from the bug once you filed it. :)
<GanonKiller> i subscribed ... i just dont remember my info
<TheMuso> GanonKiller: Check your email, you might have some email regarding the bug, which can tell you what bug number it is.
<GanonKiller> ok... well i sent the bug report via terminal command
<TheMuso> Ok, let me see fi i can find it...
<bencc> why ubuntu doesn't download and install packages in parallel?
<GanonKiller> well.. i think i need to change my sound profile
<TheMuso> bencc: If you are using more than one mirror, I believe apt can download in parallel, as to why it doesn't download in parallel normally, I am ont entirely sure. As for installing, packages have to be installed in a specific order, to make sure dependencies are correctly resolved, as the install process of one package may rely on a previously installed package to complete.
<bencc> TheMuso: the download order could be optimized so apt can install undependent packages while it downloads others
<TheMuso> bencc: For parallel download I agree, but not for installing.
<TheMuso> It needs all packages to be present to be able to work out the installation order.
<bencc> TheMuso: I don't think so
<bencc> TheMuso: if you want to upgrade apache and mysql at the same time
<TheMuso> bencc: Others know more about this than I do, but I am pretty sure that this is just not possible.
<bencc> it's possible that they don't share the same package so you can start upgrading mysql while downloading apache
<bencc> TheMuso: I'm 99.99% positive it's posible
<bencc> and I'm 100% positive it'll be cool
<TheMuso> bencc: You might want to read up on apt and dpkg then, to find out how they currently do things.
<bencc> too complicated...
<RAOF> :)
<bencc> the fact that it's complicated doesn't mean my idea isn't simple or can't be done
<bencc> trust me, it's the best thing since slice bread
<RAOF> I would have thought the implementation of your idea being complicated *did* mean that the idea wasn't simple, in practice :)
<RAOF> You'd need to do some deep dpkg diving; there's a bunch of global state in the form of package databases that you'd need to be sure won't be corrupted by multiple accesses.
<bencc> RAOF: make things as simple as possible but not simpler than that
<bencc> RAOF: now you are complicating stuff
<bencc> I don't need multiple accesses
<RAOF> Yes, you do.
<bencc> no, I don't
<GanonKiller> which is better... tunapie2 or rhythmbox?
<bencc> you are just arguing for the sake of argument
<TheMuso> GanonKiller: Ok I can't find any bugs that were recently filed against pulseaudio that have you're name, Dewey Van (Taken from whois on IRC). So unless you have a bug number, I am unable to help you further at this point.
<bencc> probably tunapie2, because the 2
<GanonKiller> ok
<bencc> just kidding
<RAOF> You're installing two packages at once; that means you need to be able to access the package database (and debconf database, and such) from two separate installs.
<bencc> RAOF: I'm not
<GanonKiller> i will take off rhythmbox
<RAOF> You're not installing two packages at once?
<RAOF> I thought that was your idea?
<bencc> RAOF: no. I'm downloading and installing at the same time
<bencc> it's different
<bencc> installing two packages at once will be stupid
<bencc> (I'm not)
<RAOF> That would indeed be easier; it's probably not *that* difficult.
<bencc> right
<bencc> and it's very very cool
<RAOF> Why don't you find out, by writing the patch? :)
<bencc> maybe I will
<bencc> do you want to help me with that
<bencc> to share the glory
<bencc> ?
<GanonKiller> ok.. i installing the other pulseaudio devices & removing rhythmbox
<RAOF> bencc: No, sorry; I've got other projects on my plate.
<bencc> RAOF: like what?
<bencc> what can possibly be more important than that?
<TheMuso> ...like making your graphics work properly?
<taggart> bencc: it's usually a good idea to have all the debs sitting on your disk before starting to install, in case something goes wrong that fucks up the network or something
<RAOF> Any number of things?  C# bindings for libpulse, hacking on Do, gobject-introspection bindings for C#...
<taggart> the odds of that are low, but I've definitely had situations where I was glad they were already there
<GanonKiller> is there to invert the 3d desktop cube?
<TheMuso> taggart: Please be careful of your language in here, and abide by the Ubuntu code of conduct.
<taggart> actually for really big upgrades I do "apt-get -d upgrade" first and get all the packages
<taggart> TheMuso: bite me
<bencc> RAOF: what is Do?
<RAOF> http://do.davebsd.com/
<RAOF> bencc: Your idea sounds cool, but it's somewhat of a micro-optimisation.
<GanonKiller> hmmmm the alsa plugin is having issues... the volume is moving on its own
<bencc> RAOF: ok
<bencc> Do looks cool
<ion> themuso: The CoC doesnât explicitly say anything about which words are good and which are bad. Thatâs very subjective.
<TheMuso> ion: Ok.
<bencc> I'm sure they don't want us to say fuck
<bencc> oops :)
<RAOF> I think it's a pretty safe call that the word in question falls under âbadâ.
<ion> Okay, i admit it was disrespectful towards the package that broke network. taggart: Please apologize to the package.
<persia> No.  There are no rules for that in the CoC, that's about respect and raising disputes quickly and avoiding personal attacks and stuff.
<persia> Not using certain words is about our IRC guidelines.
<persia> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<TheMuso> GanonKiller: When you say your alsa volume is moving on its own, what program are you looking at and using when it does this?
<GanonKiller> i forgot where to change the sound type?
<GanonKiller> oh lol... pulse audio volume control
<GanonKiller> dang sound
<GanonKiller> i did install the vlc-plugin-pulse
<GanonKiller> the alsa-playback volume keeps moving on its own
<BUGa_29plus1> one of this days I'll get why PM tools work fine, and system suspend/hibernate doesn't
<TheMuso> GanonKiller: When you are using vlc?
<GanonKiller> i am using VLC right now with tunapie2
<GanonKiller> how do i restart the sound server'/
<TheMuso> GanonKiller: Why do you want to restart it?
<GanonKiller> it killed
<TheMuso> right, as you previously stated.
<GanonKiller> sudo: /etc/init.d/alsa-utils: command not found
<GanonKiller> i cant restart
<TheMuso> GanonKiller: Please reproduce the problem following this procedure: https://wiki.ubuntu.com/PulseAudio/Log and !pastebin it somewhere.
<TheMuso> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<GanonKiller> heh... now my sound works
<GanonKiller> it turns the sound controller was controlling the app
<GanonKiller> *turns out
<GanonKiller> the volume was all the way down
<GanonKiller> i also had to change the output
<GanonKiller> thanks for your help muso
<dasKreech> Hallo. Who would I speak to about a dead official Ubuntu server?
<persia> Which one?
<dasKreech> speglar.simnet.is
<dasKreech> Let me call the person with the issue
<dasKreech> persia: This is the person querying the server
<dasKreech> You can get more information from them
<Guest64905> This is Reykjavik,,,, do you read me?  over.........
<persia> You could send a note to mirrors@ubuntu.com.  Someone might be active in #ubuntu-mirrors.  The admins at Siminn hf are the folks that really need to sort it.
<dasKreech> :-)
 * dasKreech leaves persia and Guest64905 :)
<Guest64905> Yea thank you
<Guest64905> Simnet.is is a big ISP  its dificault to talk to them... the other server is in the uneversety
<Guest64905> ubuntu.lhi.is
<persia> Guest64905, So, it looks like the administrator for that mirror has no public address on LP.  You could try sending a note to mirrors@ubuntu.com reporting the mirror outage.  You might find someone active in #ubuntu-mirrors (but I suspect not the Reykyavik admins at this hout)
<Guest64905> Thank you I try
<persia> You could try using https://launchpad.net/ubuntu/+mirror/speglar.simnet.is-archive has a base set of information to contact the contact person, but without a public address, I presume they don't prefer to be contacted that way.
<persia> Good luck!
<RAOF> Oh, accursed heisenbug.
<Guest64905> I am sending mirrors@ubuntu.com a message.... the ubuntu.lhi.is  server is in the Icelandic part of this huge networ
<Guest64905> http://www.nordu.net/ndnweb/nordunet___canarie_announces_icelink.html
<RAOF> What are my options for hunting down a memory corruption bug?  Bug #651294 seems to be caused by something outside the resource code scribbling random(?) values over the memory held by the resource pointer, leading to badness when trying to free the resource.
<ubottu> Launchpad bug 651294 in xorg-server (Ubuntu) "X crash on KDM logout (still - yes, really)" [High,Confirmed] https://launchpad.net/bugs/651294
<persia> RAOF, Well, if you happen to have a copy of the entire memory space, you can hope to find something meaningful in the otherwise random scribbling.
<RAOF> Or, I guess, set up some gdb watches on that memory address, and just eat the abysmal performance.
<persia> If you can reproduce, you can run large chunks of stuff through memory profilers (e.g. valgrind) at fairly slow speeds.
<persia> gdb is less abysmal than valgrind :)
<persia> But if you know the address that's being scribbled, it's not quite random ...
<RAOF> Oh, no.
<RAOF> The address is fixed; what's beeing written there seems random.
<RAOF> Or, rather, I know the address of the resource struct, and somewhere between being added and being freed something is scribbling on it.
<persia> In that case, you don't even need gdb: you could just poll that address repeatedly and spit out some output when it changes somewhere.
<persia> (still performance-bad, but less bad than all of gdb)
<RAOF> I might try the gdb watch approach; as I understand it, that _should_ get me a backtrace of what's actually doing the scribbling.
<RAOF> Sadly, it also means logging out of X will take in excess of 12 hours.
<persia> I doubt it.
<persia> Unless you are also running the scribbling bit inside gdb.
<persia> Depends whether your issue is localised to a single process or not.
<RAOF> I presume it is, but I guess that it's not guaranteed to be the case
<RAOF> Barring a kernel bug, though, a second process couldn't scribble over X's memory, right?
<RAOF> I guess it decided that poking /dev/mem or whatever it is is a fun way of communicating.
<TheMuso> Wow. New binutils in natty is calling for more bits to be explicitly linked... At least thats what I am currently looking at in a test pulseaudio build...
<persia> RAOF, char *x = 32489716; x='Q';
<RAOF> SIGSEGV?
<persia> Yeah, well, if it was that clean, we wouldn't have to worry so much about PIC and PIE :)
 * persia isn't going to show something that really works here, and points at exploit documentation for those really interested
<persia> But if you can reproduce it reliably, there's a good chance that it is one process.
<RAOF> Yeah.  It's going to be something in the X server.
<RAOF> Or, I guess it could be kwin doing something totally rediculous.
<persia> Could try trapping each with GDB over a multi-day period (one try each), and see if you can catch it.
<GanonKiller> i am having trouble opening a rar file
<GanonKiller> i have have 7zip installed & cant find the prog
<TheMuso> GanonKiller: #ubuntu for support, you were helped earlier because you had a crash, but this is a general support query.
<GanonKiller> sorry
<TheMuso> This channel is for development.
<TheMuso> No proble,/.
<TheMuso> problem
<robert_ancell> Is natty open for uploading?  I can't find any information either way...
<nigelb> robert_ancell: /topic in -motu says it is
<robert_ancell> nigelb, thansk
<nigelb> np
<persia> robert_ancell, The formal answer to that question is always available from LP: e.g. https://launchpad.net/ubuntu/natty
<robert_ancell> persia, yeah, I've been looking at that but would it show there if it was in a freeze?
<persia> robert_ancell, "Status" was "Pre-release Freeze" about 6 hours ago.
<persia> https://launchpad.net/ubuntu/maverick may be an interesting comparison
<robert_ancell> persia, ah, thanks
<bilalakhtar> Why not change this channel topic to reflect the fact that natty is open?
<persia> Just nobody did it.
<bilalakhtar> persia: I am doing it now
* persia changed the topic of #ubuntu-devel to:  10.10 released on 10/10/10 at 10:10:10UTC!! | Natty is open, more SRUs for Maverick | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<persia> Oh, heh, me too :)
<bilalakhtar> :D
<mneptok> persia: gÃ¼naydin, effendi. nasilsin?
<persia> Decidedly unurgaric :p
<pitti> Good morning
<ion> that.
<pitti> YokoZar: what was the bug ref # again?
<YokoZar> pitti: 6222220
<YokoZar> err 622220
<persia> RAOF, Would you have an interest in https://blueprints.launchpad.net/ubuntu/+spec/hardware-arm-n-irregular-input-device-handler ?  Might be udev hinting, might be fiddling with gizmod or similar.
<RAOF> Hm.  Looks interesting, but I've no experience with arm hardware.
<persia> From the perspective of knobs and buttons, it's not that different from anything else.
<persia> Just /dev/input/event entries.
<pitti> YokoZar: uploaded
<persia> Adding "arm" is mostly intended to explain why someone should consider it critically important :)
<YokoZar> pitti: thanks
<pitti> hooray, natty thawed?
 * pitti yays at the wave of "accepted" mails
<persia> Almost 9 hours ago :)
<dholbach> good morning! :)
<bilalakhtar> dholbach: Good morning!
<dholbach> hey bilalakhtar
<smb> pitti, There is a ti-omap4 proposed kernel for maverick waiting to be accepted which ogra has been winching about all along yesterday. Could you do him the favor and accept it? ;-)
<pitti> right, it's been 15 hours since I processed SRU, high time :)
 * pitti looks
 * pitti tries to ignore the gazillion new .gitignore files
<pitti> smb: hm, why does this have several new source files, like arch/arm/mach-omap2/powerdomain.c ?
<pitti> or arch/powerpc/include/asm/immap_86xx.h (must be really important for omap..)
<smb> pitti, could this be a result of me doing a orig.tar.gz the first time?
<pitti> ah, perhaps
<pitti> sound/soc/omap/mcpdm.[hc] are also new
<pitti> so, this needs some more testing then
<smb> pitti, Oh, actually they did some sound stuff
<smb> but as it is arm I have no idea what they do anyways
<pitti> not in the changelog
<pitti> anyway, sending builddwards
<smb> pitti, Thanks, they seemed quite keen to have it till Monday for some reason
<smb> and as it is a topic branch and this kernel is only used on some few board, regression potential is low
<persia> smb, pitti Regression potential is effectively zero, as nothing that kernel supports is currently available retail.
<pitti> right, that's why I'm not too concerned about it; I just wondered about the diff
<persia> From the bug descriptions, sound/soc/omap/mcpdm.[hc] are required to make sound work at all.
<ogra> pitti, that kernel change goes together with the alsa-utils upload
<pitti> ah
<ogra> (same bug)
<lool> doko: I have a build of newlib for ppc in a native PPA; do you want the build log over email to proof-check it?
<ogra> mvo, is sw-center set to "always on top" ? (see bug 661003)
<ubottu> Launchpad bug 661003 in software-center (Ubuntu) "Debconf dialogs are hidden" [Undecided,New] https://launchpad.net/bugs/661003
<mvo> ogra: no, but it sounds like debconf should be
<mvo> ogra: its probably focus stealing prevention
<ogra> mvo, hmm, k
<mvo> ogra: and yes, not cool ./
<ogra> well, minor usability glitch
<ogra> would be worse if it was not shown at all :)
<persia> for some values of minor.
<mvo> true that
<mvo> (the not shown at all)
<cjwatson> TheMuso: your linking question: see http://wiki.debian.org/ToolChain/DSOLinking
<cjwatson> doko: ^- you might want to include a note about that in your mail about natty opening
<doko> lool: fine it it does build
<doko> cjwatson: yes, have to update it first
<poolie> hi
<poolie> can someone _please_ help us get SRUs for https://bugs.edge.launchpad.net/bzr/+bug/636930 ?
<ubottu> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo'" [High,Triaged]
<cjwatson> poolie: sponsoring; will still need approval from another ubuntu-sru team member
<cjwatson> but this will move it forward at least
<poolie> thanks
<pitti> I'll review it
<poolie> it doesn't have to be today in particular
<poolie> i just don't want it to stall forever
<pitti> I'm doing SRU review every day now anyway, due to the maverick rush
<poolie> pitti, how would i find out or establish a regular contact for this?
<\sh> mom is already running?
<cjwatson> \sh: yes
<pitti> poolie: hm, not sure; we should perhaps discuss on u-devel@, to find a permanent sponsor
<\sh> cjwatson: thx :)
<cjwatson> might be better for maxb to seek per-package upload rights, if he's going to be a regular uploader
<poolie> there are ubuntu devels who upload it, but nobody in the canonical platform team, and i think nobody who will regularly SRU
<poolie> i'm going to work on getting per-package upload rights myself
<cjwatson> doesn't have to be the canonical platform team
<pitti> seems so far we mostly got them through Debian autosyncs?
<poolie> right, which is good, i think
<cjwatson> definitely
<poolie> that works pretty well, but the main snag is SRUs
<cjwatson> (in fact, I spy 2.3.0~beta2-1 in the pending natty sync queue)
<poolie> we really want to do bugfix releases that fit well with SRUs, but i always seem to have to pester people to get them sponsored
<poolie> so i think we must be doing something wrong
<alkisg> Which Ubuntu package inserts "%admin ALL=(ALL) ALL" to /etc/sudoers? That line is not present in Ubuntu fat chroots...
<maxb> What do I need to do to be eligible for per-package upload rights? I've been getting bits and pieces sponsored here and there for a while, but never quite in sufficient volume to consider myself MOTU-eligible.
<cjwatson> any time we find ourselves assembling a permanent sponsorship arrangement, we should probably be reaching for per-package upload instead
<lool> doko: Thanks; uploading
<cjwatson> alkisg: the installer - specifically user-setup
<alkisg> Thank you cjwatson
<maxb> Not, of course, that MOTU would help for bzr
<cjwatson> maxb: https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage
<pitti> maxb: your sponsor needs to vouch that you have sufficient experience with the package you want to upload yourself
<pitti> maxb: that's the main bit, and then some paperwork
<cjwatson> poolie would surely be a shoe-in for bzr upload rights, and I expect maxb wouldn't have much difficulty either
<cjwatson> (shoo-in?)
<persia> Sponsoring of SRUs has always lagged a lot: many folk don't seem to focus on that.
<ari-tczew> now should be enough subscribe ubuntu-sponsors. devs can review bug and patch. if it's acceptable, can upload
<ari-tczew> acceptable => test case exists in bug, patch is correct with policy and built fine
<poolie> i know, but it basically never seems to happen without coming in here and asking several times
<poolie> i know you're not lazy, so it suggests something is disconnected
<persia> poolie, I suspect it's a perception that bzr is cared for by someone, and so everyone leaves it to whoever cares for bzr.
<persia> Except, since nobody actually cares for bzr, this fails.
<persia> per-package upload rights is definitely the right fix in this case.
<poolie> i don't think regular uploads are a problem, it's only or mostly SRUs
<poolie> and aiui per-package uploads won't help with that? or will they
<persia> I believe they help from the date that you get per-package.
<pitti> poolie: PPU works just as well for SRUs
<persia> So it may not help with maverick, but it will help with natty, ... once they release.
<persia> pitti, Does it?  All the way back?
<pitti> persia: it's another step in edit-acl.py, but yes
 * persia was under the impression that packagesets were per-release
<poolie> ok, brilliant, we should definitely do that then
<pitti> persia: they are
<persia> pitti, Ah, so it *can* be done that way :)
<pitti> persia: but we can edit them per-release
<cjwatson> PPU isn't packagesets though
<cjwatson> give me an example of somebody with PPU?
<persia> cjwatson, It isn't?
<cjwatson> preferably LP username
<persia> cyphermox
<pitti> tkamppeter?
<persia> Except we fail
<pitti> till-kamppeter is the LP username
<persia> ~till-kamppeter
<cjwatson> sorry, I should say, PPU isn't necessarily packagesets.  it's perfectly possible to grant people direct upload access to a single package without creating a set for it
<cjwatson> archive permissions can be attached to components, packagesets, or packages
<cjwatson> cyphermox => ~mathieu-tl, and he has upload rights via team membership for a package set; package set access does have to be release-specific
<poolie> so with PPU, maxb or I could upload to -proposed, and then someone from ~ubuntu-sru would check it, and copy to -updates?
<cjwatson> (though we can always go back and extend things for older releases)
<persia> cjwatson, Did all of cyphermox's permissions get moved to packageset?  He applied for PPU something like three times.
<cjwatson> ~till-kamppeter has PPU access to several source packages, and that access isn't release-specific
<cjwatson> persia: yes, I checked
<persia> Ah, OK.
<cjwatson> poolie: right
<cjwatson> (modulo LP bugs; not many people use per-package upload permissions for SRUs, so you may be trailblazing)
<persia> poolie, Note that this is the same procedure every Ubuntu developer needs to follow (even SRU members, who ask their peers to do the second part)
<cjwatson> right.  the SRU queue is better tended than the sponsors queue, I think, largely thanks to pitti being a hero
<maxb> poolie: You missed a step, we could upload to -proposed, it would hit the queue, ~ubuntu-sru would accept it, it would need verification, and *then* it would be copied to -updates
<persia> maxb, Extra points for process knowledge !
<poolie> ok, i was oversimplifying a bit; but the big difference is that as cjwatson said it will get into a queue that's more actively polled
<poolie> per https://wiki.ubuntu.com/ArchiveAdministration#Stable release updates
<cjwatson> and a step forward in the process
<poolie> so if you two will be so kind as to put this one into proposed, we'll see about getting PPU for next time
<poolie> and 2.2.2 should also have clean test suites both in package build and after installation
<persia> poolie, And just to be clear, PPU is a one-time hurdle.  We'll expect you to act as an Ubuntu Developer in full faith once it's granted, but you won't have to revisit the process repeatedly (except potentially iterating per-person)
<poolie> sure
<poolie> i have fixed a few bugs in other packages recently
<poolie> well, for years, but more so recently
<poolie> so, perhaps i should go for something more general afterwards
<persia> Best to apply for things as you find that folks sponsoring you do so confusedly expecting you to have done it already :)  You'll likely end up with larger and larger portions of the archive over time.
 * cjwatson flushes the initial natty sync queue
<poolie> :)
<cjwatson> I only had to beat sync-source.py with a stick once.  Do you think Debian is frozen?
<lool> I don't understand why https://launchpad.net/ubuntu/+source/newlib/1.18.0-6ubuntu1 doesn't have any armel and amd64 build records
<lool> it did build on amd64 and armel in a non-virtual PPA
<cjwatson> it's in Packages-arch-specific
<cjwatson> %newlib: i386 powerpc ppc64
<bilalakhtar> doko_: there? What about the change you mailed about?
<lool> cjwatson: Oh ok; this is new then, as ithad built in maverick
<cjwatson> does it build on other architectures in Debian?  if so, the best fix would be to file a bug on buildd.debian.org about that
<cjwatson> lool: see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571256
<ubottu> Debian bug 571256 in buildd.debian.org "buildd.debian.org: add Packages-arch-specific-version for newlib" [Normal,Open]
<lool> Yup, just found it in the Pas git log
<cjwatson> hm, the bug appears to be "it builds but I didn't think it was useful"
<cjwatson> maybe talk to Arthur about that?
<lool> why no explanation?
<cjwatson> read down to the end of the bug
<cjwatson> (that's all I know)
 * lool searches for RM bug
<lool> Debian #597234
<ubottu> Debian bug 597234 in ftp.debian.org "RM: newlib [ia64 amd64 hurd-i386 kfreebsd-i386 kfreebsd-amd64 sparc] -- ANAIS; excluded, see #571256" [Normal,Open] http://bugs.debian.org/597234
<lool> not anything more
<lool> I poked the Pas bug
<cjwatson> hence my suggestion to talk to Arthur :)
<\sh> guys, when I get such a build error like http://paste.ubuntu.com/513753/ <- what needs to be done for natty? I saw some uploads by Doko with a similar changelog entry...is there any doc on how to fix this?
<ari-tczew> someone ping me?
<bilalakhtar> ari-tczew: 13:19 < cjwatson> hence my suggestion to talk to Arthur :)
<TheMuso> cjwatson: thanks
<persia> \sh, maybe http://wiki.debian.org/ToolChain/DSOLinking ?
<cjwatson> ari-tczew: I didn't mean you (I'd have spelled your name right :-) ); I was referring to the Debian bug above
<gusnan> My GTK program get the following: http://paste.ubuntu.com/513757/ during build - does someone know anything about this?
<bilalakhtar> gusnan: install the libgdk-pixbuf packages
<bilalakhtar> gusnan: but for such questions, go to #ubuntu-app-devel
<bilalakhtar> not here
<\sh> persia: thx a lot friend :)
 * persia is just an advanced backscroll filter sometimes
<ari-tczew> cjwatson: ok then :)
<\sh> persia: lol
<gusnan> bilalakhtar, thanks.
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, how are you?
<tkamppeter> fine, have you asked for me?
<pitti> no, I didn't
<persia> tkamppeter, We were using you as an example of a per-package uploader.  Sorry for the noise.
<pitti> ah, right
<tkamppeter> pitti, what about bug 485383?
<ubottu> Launchpad bug 485383 in cups (Ubuntu) "Zebra driver not found" [Undecided,Triaged] https://launchpad.net/bugs/485383
<tkamppeter> pitti, as you ahve all kinds of BZR repos for that, can you prepare a CUPS SRU only adding a cups-ppdc dependency to cups?
<pitti> tkamppeter: feel free to push to bzr+ssh://bazaar.launchpad.net/~ubuntu-printing/cups/maverick/
<pitti> tkamppeter: (sorry, we have a deadline today, no time for Ubuntu)
<tkamppeter> pitti, for Debian?
<pitti> neither, I'm afraid :)
<tkamppeter> pitti, pushed it up now, rev 910.
<tkamppeter> pitti, SRU is uploaded to the queue now.
<ari-tczew> doko: ping
<sladen> mvo: would it be feasible to tweak update-manager to check for machine >= i586 and refuse to attempt the upgrade if it is noticed?
<sladen> mvo: at the moment function 10.04 machines get hosed on upgrade to 10.10 once libc6 gets installed and starts generating illegal instruction traps
<mvo> sladen: *gar*
<mvo> sladen: sure, definitely
<mvo> sladen: do you have more info what to check for in cpuinfo ? or a bug reference?
<mvo> sladen: not the kind of message I was hoping for on a friday afternoon ;)
<Ian_Corne> :)
<sladen> mvo: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186
<ubottu> Launchpad bug 587186 in eglibc (Ubuntu) "libc6 upgrade fails: illegal instruction" [High,Fix released]
<mvo> sladen: thanks!
<mvo> sladen: so it looks like checking the flags section for cmov should do the trick?
<persia> Does 10.10 run on the VIA C7M chips?  I seem to remember they weren't quite i686 but had cmov.
<persia> (mind you, I'm remembering from intrepid, so I might be incorrect: C7M was the chip in early EeePCs)
<mvo> persia: I don't know :) any help on this is welcome how to reliable detect it
<mvo> persia: so either cpufamilty 5 -> fail or cpufamily 6+ and not cmov -> fail?
<persia> Anyone have a first-generation EeePC or similar device with C7M?
<mvo> (5 or less)
<persia> mvo, I think so, but I worry about this special case that was cpufamily 5 + lots of extensions (including cmov).
<persia> That said, could be not so many folks have them, really.
<persia> mvo, if nobody volunteers with testable hardware for my corner case, I'd go ahead with the rule you described: maybe we get another bug, maybe we don't.
<mvo> yeah, it will certainly help a lot of people and that worst that can happen is that people need to stay whereas currently it will break for them
<mvo> so we error on the safe side
 * mvo adds this code
<mvo> thanks persia!
<mvo> and sladen
 * persia points at sladen, having mostly gotten in the way with an untestable corner case
<ogra_ac> stgraber, are you here ?
<popey> persia: which specific eee pc, I thought they started with underclocked 900MHz celerons. Don't recall any having VIA CPUs
<persia> It would have been the very first model: the second model switched from VIA to Intel.
<persia> There is other C7M stuff out there (the Aigo MID, etc.), but I thought the Eee was the biggest seller.
<persia> Mind you, within a couple months, Atom was released, and everyone switched to that, so I may be hoping to allow a nigh-insignificant number of folks to upgrade.
<popey> I'm certain the first model (of which I had two) were 900MHz celerons underclocked to 600MHz. The model number was 701.
<persia> OK.  I was also thinking of the 701s.  if you're sure they were celerons, then I misremember, and it doesn't matter, because all the other things I believe to have shipped with C7M required proprietary drivers for enough components that we've never supported them well.
<popey> yes, other C7M devices were around at the same time
<popey> I recall them being compared in performance tests
<popey> can't imagine there's many of them about though.
<persia> I hope there either aren't many, or I misremember the odd config so that they can't actually run maverick.
<systemofadown> my pc has better performance than a 8-core pc in fabonacci
<systemofadown> fibonacci?
<cjwatson> the latter
<ogra_ac> whats the prefix for preformance- specs ? a spec search for that term doesnt reveal anything
 * ogra_ac wants to know if his spec fits the scheme 
<cjwatson> I wouldn't have expected naÃ¯ve implementations of Fibonacci's algorithm to parallelise; the traditional x[n] = x[n - 1] + x[n - 2] implementation has an inherent limit on parallelisability.  Obviously you can implement it using Binet's formula for the closed form and parallelise that way (should you care).
<persia> ogra, "other"
<ogra_ac> persia, really ? why is it listed as track ?
<persia> Oh my.  It wasn't a track 6 hours ago.
<ogra_ac> it was when i looked yesterday
<ogra_ac> i just cant find any specs for it
<persia> (or else I somehow didn't read it, and did notice the layout looked unbalanced, meaning there was a very strange blind spot)
<cjwatson> goodness me.  two hours later, and the initial autosync queue flush is only up to luatex
<persia> a-l in two hours is better than usual though.
<cjwatson> this is just the flush step; I don't remember how long that usually takes.  the bit that normally takes ages is constructing the syncs
<cjwatson> (because sync-source falls over whenever it encounters something that needs manual resolution, and then you have to start again from the beginning, so it has worst-case quadratic time
<cjwatson> )
<seb128> tkamppeter, hi, do you have a vcs for system-config-printer?
<geser> cjwatson: is this with NEW packages or only existing ones?
<cjwatson> existing
<ogra_ac> pitti, did the alsa-utils SRU go through (i have some TI devs waiting for it)
<ogra_ac> pitti, to proosed that is
<ogra_ac> *proposed
<seb128> tkamppeter, could you drop the depends on python-gnome2?
<persia> ogra, https://launchpad.net/ubuntu/maverick/+queue?queue_state=3 is a handy way to see recent acceptances into -propsed
<seb128> tkamppeter, https://code.edge.launchpad.net/~mterry/ubuntu/maverick/system-config-printer/gtkbuilder/+merge/37621 as well
<persia> ogra, And according to https://launchpad.net/ubuntu/maverick/+queue?queue_state=1 it's still pending
<ogra_ac> persia, no alsa-utils ...
<ogra_ac> yeah
<persia> Right.  Just want to give you tools to be able to say "hey pitti, could you approve that?" rather than "did you approve that?"
<ogra_ac> persia, i did the former this morning, thats why i asked ;)
<persia> Oh, so with the tools you could even have reached "Why didn't you approve it yet" :)
<ogra_ac> heh
<pitti> yeah, yeah, I'll get to it :)
<ogra_ac> thanks :)
<ogra_ac> i know you are busy spec writing ...
<doko> cjwatson, pitti: any feedback/corrections on http://paste.ubuntu.com/513846/ ?
<pitti> ogra_ac: actually not; I'm busy finishing my bug assignments on my current OEM project by UDS :)
<pitti> doko: looks fine to me
<ogra_ac> oh
<ogra_ac> pitti, i'm just writing a spec for arm thin client implementations btw, might be helpful to have some input from you at UDS :)
<werber> http://www.uk.spmgame.com/partner.php?ID=267046
<werber> http://www.uk.spmgame.com/partner.php?ID=267046
<pitti> is that the new guerilla marketing strategy?
<ogra_ac> heh
<cjwatson> doko: looks OK
<cjwatson> doko: (I'll fix libdebian-installer for --no-as-needed, BTW)
<cjwatson> and syslinux
<cjwatson> and newt
<pitti> ogra_ac: please reupload alsa-utils with -v; it covers two versions
<pitti> (rejected)
<ogra_ac> -v for the changelog you mean ?
<ogra_ac> will do
<pitti> right
<doko> cjwatson: note, it's --no-add-needed
<cjwatson> doko: sorry, yeah, I always get those confused
<doko> cjwatson: me too :) it's now renamed to --no-copy-dt-needed-entries
<doko> could somebody approve the email to u-d-a?
<ogra> pitti, done
<pitti> doko: looking
<pitti> doko: flushed
<benste> hi folks, could someone explain me which authentification is used for GDM Settings, software center and expanded user settings ? - I'm only getting a box asking to authentificate without the possibility to enter my pasword - but don't know where to start troubleshooting
<mvo> persia: I just found a blog post by someone telling the world that his via c7m works with 10.10, so we should be fine there
<persia> nenolod, You may find #ubuntu is a better place to ask.  This isn't a support channel.
<persia> mvo, Well, actually, the opposite, because I think c7m is family5 + cmov, which I think fails the test.
<persia> I might be wrong, but I remember having some issues with the ubuntu-mid images on c7ms when we did tests for i686.
<persia> So I fear the SRU would prevent some folk from updating who otherwise might be supported.
<mvo> persia: I got the cpuinfo from that cpu, it says family 6 so we are good. but who knows, there might be multiple versions of that cpu :/ I was not able to find a "repository" of cpuinfo output
<persia> mvo, Then I'm completely wrong.  Sorry to have raised the issue.
<mvo> persia: its all good (in fact, great) - I added a test-case for this to the u--m repository and to be honest, this kind of change makes me nervous, so any hint/blocker/issue should be followed and checked
<persia> mvo, Heh, OK.  I feel better knowing that your increased peace of mind made up for your increased work :)
<mvo> persia: peace-of-mind++
<tkamppeter> seb128, I will have a look into it. What is the problem of python-gnome2?
<seb128> tkamppeter, it's legacy old technology and system-config-printer stopped using it
<seb128> tkamppeter, the depends is buggy, it just makes some old component still be pulled in for no reason
<tkamppeter> seb128, OK. Is this only needed for Natty or also as SRU? The use of Glade is already removed upstream and Tim Waugh (upstream author) will also do some file renamings soon to not have wrong impressions. The removal of python-gnome2 and Glade dependencies is no problem for me.
<seb128> tkamppeter, only natty
<seb128> tkamppeter, thanks
<cjwatson> doko: I can't reproduce the problem with libdebian-installer in https://wiki.ubuntu.com/RobSavoye/GoldFixes; it builds fine in an up-to-date natty chroot
<doko> cjwatson: yes, maybe he didn't finish the check. found two others which didn't need fixing
<cjwatson> doko: is the python3.1 sync on cocoplum yours?  if so you can flush it now, I'm done with the initial autosync (at least of main, would like to move on to contrib / non-free / other related stuff)
<tkamppeter> seb128, so I remove python-glade2 and python-gnome2 from the dependencies of system-config-printer-gnome. Do I need to put any replacement or to remove more?
<seb128> tkamppeter, grepping in the source you need to depends on
<seb128> tkamppeter, on python-gnomekeyring
<seb128> jobviewer.py:    import gnomekeyring
<doko> cjwatson: done
<cjwatson> ta
<tkamppeter> seb128, thanks.
<seb128> tkamppeter, you're welcome
<tkamppeter> seb128, new s-c-p uploaded.
<seb128> tkamppeter, thanks!
 * pitti makes seb128 a honorary member of https://edge.launchpad.net/~ubuntu-cruft-busters
<seb128> pitti, ;-)
<chrisccoulson> lamont - you there?
<cjwatson> doko: syslinux also works unmodified in natty, but at least newt fails
<cjwatson> (missing -ldl by the looks of it)
<cjwatson> doko: can I mark things as done directly in RobSavoye/GoldFixes?
<doko> cjwatson: I think that would be good
<cjwatson> pitti: can we disable the "no work items defined" mails until after UDS?
<cjwatson> apparently some specs have been accepted prematurely
<ogra_ac> just to be sure, i didnt recieve any release meeting mail or cancellation, there is none today, right ?
<cjwatson> so I understand
<ogra_ac> thanks
<pitti> cjwatson: sure, no objection; I just have about zero time right now, need to fix an apt regression today which causes OEM builds to fail
<cjwatson> pitti: what would be your preferred approach?  is a new configuration key overkill?
<cjwatson> (happy to implement whatever)
<pitti> cjwatson: we could just temporarily comment out the warning message about the "no WIs"
<cjwatson> pitti: ok, fair enough - done
<doko> ERROR: 90 tests were run,
<doko> 71 failed unexpectedly.
<doko> 8 tests were skipped.
<doko> hmm, tar ...
<cjwatson> er - really done now
<cjwatson> initial autosync pass has finished for existing packages, FWIW
<pitti> yay
<pitti> cjwatson: not that many this time, I figure?
<cjwatson> I didn't count, TBH
<cjwatson> didn't seem too bad
<sebner> cjwatson: 3 days waiting for a buildmachine is pretty normal so bad :P
<SpamapS> ttx: I don't see a "web scale" blueprint yet, should I be adding that?
<cjwatson> doko: are you going to merge debconf, or should I?
<cjwatson> (happy to)
<cjwatson> cody-somerville: you're marked as touched-it-last for base-installer due to that change for live-installer, but most of the changes there are mine - do you want me to handle the merge?
<cody-somerville> cjwatson, You're more than welcome to do it if you'd like. I won't have time to get around to it today or early next week for sure.
<cjwatson> cody-somerville: ok, no problem
<ggeorgy> Hi !!! :D
<ggeorgy> i installed ubuntu 10.10 and is great! But why the logout sound not work???
 * hyperair points at #ubuntu
<hyperair> actually it sounds like a potential bug. maybe you could report it on bugs.launchpad.net/ubuntu/+source/gnome-session (i think that's what's responsible for logout sounds)
 * hyperair loves the way sabdfl phrased "odd super-self-interested muppet who expects me to singlehandedly make his wet dreams of technology kfuturism come true"
<ggeorgy> the logout sound not worked also in  ubuntu 10.4 !!!
<hyperair> ggeorgy: file a bug, please
<ggeorgy> i think this bug alreay reported but the problem will not be resolve
<hyperair> do you have the bug number?
<ggeorgy> no
<cjwatson> cody-somerville: ... you're lucky too, it's a conflict-resolution-and-a-half
<ggeorgy> i reported that bug #661385
<ubottu> Launchpad bug 661385 in gnome-session (Ubuntu) "the logut sound dont play on ubuntu 10.10 !!!!" [Undecided,New] https://launchpad.net/bugs/661385
<doko> cjwatson: please go ahead, I'm done for today
<ggeorgy> ok
<cjwatson> doko: ok, thanks
<bilalakhtar> doko: hi
<ttx> SpamapS: sure
<kirkland> cjwatson: hi there;  i have a couple of questions about multiverse, if you have a second ...
<kirkland> cjwatson: ahs3 has been working on building paravirtual drivers for Windows
<kirkland> cjwatson: Windows guests running in Ubuntu KVM can install these PV drivers and take advantage of PV disks, network, and memory ballooning
<kirkland> cjwatson: the source code for the drivers themselves are GPL
<kirkland> cjwatson: but we're not able to cross compile them on Linux
<kirkland> cjwatson: ahs3 has to build them in a Windows VM
<kirkland> cjwatson: the output is a little ISO (11MB, I think)
<kirkland> cjwatson: we're trying to decide the best way to make this ISO available
 * ahs3 listens attentively...
<kirkland> cjwatson: one way would be through an Ubuntu package, that drops the ISO somewhere reasonable in /usr/share, and then the user can make that available to guests
<kirkland> cjwatson: by hot-add of a virtual cdrom to the guest
<kirkland> cjwatson: alternatively, we could, perhaps, just publish the ISO somewhere on ubuntu.com, or in the wiki or documentation
<kirkland> cjwatson: I was looking to bounce this off of you (or someone) first, though
<cjwatson> I'm trying to understand what your question about multiverse is
<cjwatson> oh, you're asking whether you can put binaries built ex-archive from GPLed software in multiverse?
<SpamapS> sounds to me like it would have to have  Build-Depends: windows
<kirkland> cjwatson: yes, right
<ogra_ac> sounds ok imho
<kirkland> cjwatson: so we can publish the source, but the buildd's ain't gonna build it
<ScottK> We have plenty of binary only stuff in Multiverse.
<cjwatson> ogra_ac: he asked me
<ogra_ac> cjohnston, yes
<ogra_ac> err cjwatson
<cjwatson> I think you should ask a lawyere
<cjwatson> *lawyer
<kirkland> cjwatson: alrighty
<kirkland> cjwatson: i'm really not that concerned about the legal distribution question -- i think we're clear
<kirkland> cjwatson: i'm more wondering about the ubuntu policy on such matters
<cjwatson> binary-only in multiverse is fine, but whether you can distribute GPLed binaries when I'm not sure we can distribute "the scripts used to control compilation and installation of the executable" (GPLv2 s. 3) ...
<kirkland> cjwatson: something that's built once somewhere
<kirkland> cjwatson: gotcha;  ahs3: do you have any more info about this part?
<kirkland> ahs3: ie, the licensing of the source and the required build tools
<ahs3> kirkland: the source is _all_ GPL2
<cjwatson> how far down does "scripts" have to go, and are the resulting executables contaminated by linking with system components?
<cjwatson> as in is there something like libgcc that gets statically linked into the resulting binaries?
<ahs3> there are components of the Windows DDK (Driver Development Kit) that are included, and are covered by a freely redistributable clause in the DDK
<cjwatson> freely redistributable doesn't meet the terms of the GPL
<cjwatson> hence - ask a lawyer, this isn't a field I'm used to
<cjwatson> more used to dealing with proprietary code on top of a free OS
<kirkland> cjwatson: okay, thanks
<ahs3> correct.  there's a note in the DDK about an exception to the GPL that's been approved
<kirkland> ahs3: we'll need to talk to amanda brock, canonical legal counsel
<SpamapS> Yeah, I'd bet this needs to be LGPL'd if it links any software like that.
<ahs3> i have to go look it up again, but the RH folks had this covered in the docs in the source
<cjwatson> so do you mean that the source code is actually GPL plus special exception for the Windows DDK?  An exception in the Windows DDK licensing wouldn't be enough
<cjwatson> if that's the case, it would be OK in multiverse; however, distributability aside, I wonder if a package is really the best way to distribute this
<ahs3> afaiui, the former.  agreed, the DDK licensing would not be sufficient
<cjwatson> as in most convenient
 * SpamapS likes the idea of an iso that is hot-added to the VM as a CD-ROM
<cjwatson> if you're integrating it tightly in other packages, then a package would be reasonable
<SpamapS> thats definitely how the VMware folks prefer to distribute guest enhancements.
<SpamapS> and it works really nicely
<ahs3> hrm.  these would only be useful pre-installed in a windows guest -- which we obviously can't redistribute
<SpamapS> ahs3: they can't be installed after the fact?
<ahs3> that's the only tight integration that makes sense
<SpamapS> like, during install you get the slow SCSI emulation.. but after the drivers are in, you get the hotness?
<ahs3> SpamapS: they can, but not automagically.  there are manual steps involved :(
<ahs3> right.  you get the slow stuff during install.  shut down your VM, restart it with the virtio incantations, then update the drivers in the guest
<ahs3> all the ISO does is allow you to attach it to the VM easily so you can get the "new" drivers
<SpamapS> Doesn't windows have some kind of "load disk drivers from a CD" mechanism that could be leveraged?
<ahs3> possibly.  that's way past my windows expertise, tho....
<achiang> ahs3: SpamapS: i've definitely seen that option in the windows installer
<SpamapS> I know win2k had it as I had a very new server with a totally unsupported RAID and was able to install using the extra CD-ROM from the mfgr.
<SpamapS> so thats even more compelling an argument for the ISO
<SpamapS> and if possible, formatting it as a windows driver disk
<SpamapS> which, it may already be, as the same thing would be necessary for adding the driver manually later
<Isaick> Is there an easy way to add/remove environment variables when creating an install package?
<ahs3> SpamapS: yeah, i don't think there's any special format for a driver disk.
<cjwatson> Isaick: our policy manual says that programs distributed in packages must not depend on particular environment variables being set in order to work
<cjwatson> Isaick: why do you need this?
<ahs3> SpamapS: so, if we just dropped the iso in /usr/share/blahblah, you'd find it useful?
<Isaick> cjwatson: I've created a python app that I plan on installing in /opt/.  I need to be able to append the /opt/[app] directory to the PYTHONPATH variable.
<cjwatson> Isaick: you should either distribute a wrapper script that sets the environment variable, or you should make your top-level Python program prepend to sys.path
<cjwatson> setting PYTHONPATH for everything isn't the right fix for that
<cjwatson> Isaick: if you lay out your files right, you may not even need that - for example, one package I maintain has its modules in /usr/lib/germinate which isn't on sys.path.  however, I don't need to set PYTHONPATH or modify sys.path to make this work; I just make /usr/bin/germinate be a symlink to /usr/lib/germinate/germinate.py
<cjwatson> this may or may not be appropriate
<Isaick> cjwatson: I'll take a look.  Thanks for the info
<kirkland> jdstrand: ping
<jdstrand> kirkland: yes?
<kirkland> jdstrand: wondering if you had a couple of minutes to de-NEW a package to universe for me
<jdstrand> kirkland: what package?
<kirkland> jdstrand: https://edge.launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=bikeshed
<jdstrand> kirkland: sure
<kirkland> jdstrand: awesome, thanks
<psychicist> hi, I know this isn't a support channel but I have a question pertaining to ubuntu 10.4(.1) i386
<psychicist> today I have had two issues with people calling me and saying that they lost sound
<psychicist> in one case it was solved by applying updates and in the other case sound has stopped working after applying updates
 * ScottK notes you didn't actually ask a question.
<psychicist> so I was wondering if anyone in the ubuntu teams is aware of these problems and what to do about them
<ScottK> Generally we are very interested to find out about post-release updates causing regressions.
<ScottK> Do you have access to details of the system that lost sound/know what package updates they installed?
<psychicist> I am typing on that system now, is there a place where I could find that information?
<psychicist> I see /var/cache/apt/history.log, is that what you need?
 * hunger just finished the first round of natty upgrades:-)
<ScottK> I'm not the best person to answer sound questions.
<psychicist> okay, is there anyone who does know more about the sound system or a mailing list where I could contact the person(s) responsible for the sound system?
<ScottK> psychicist: Open a shell and type "ubuntu-bug".
<ScottK> It will give you point and click options to specifically collect information for a sound related bug.
<ScottK> Once you're done.  Give us the bug number here.
<SpamapS> hmm, so natty is open.. when does 'do-release-upgrade -d' start working?
<kklimonda> around alpha?
<SpamapS> ah
 * SpamapS dist-upgrades ;)
<Quintasan> barry: ping
<kirkland> Spads: sudo sed -i s/maverick/natty/g /etc/apt/sources.list ;-)
<kirkland> SpamapS: ^
<kirkland> Spads: sorry
<psychicist> ScottK: it took me some time to fill in all the information, but here it is #661427
<ScottK> psychicist: Thanks.
<SpamapS> kirkland: :%s/maverick/natty/g in vim about the same time as you sent that. ;)
<ScottK> Bug 661427
<ubottu> Launchpad bug 661427 in alsa-driver (Ubuntu) "[NFORCE - NVidia nForce2] ALSA test tone not correctly played back" [Undecided,New] https://launchpad.net/bugs/661427
<kirkland> SpamapS: heh
 * SpamapS will wait for mongodb to finish building before he goes any further though.
<barry> Quintasan: pong
<ScottK> !regression
<SpamapS> doh.. filled my vm's disk..
<ScottK> Maybe that's not the right one.
<Quintasan> barry: I'm trying to update SIP package and I want to send it to Debian, I was wondering in which section in rules I should put dh_python3
<ScottK> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<ScottK> See Bug 661427 for details.
<ubottu> Launchpad bug 661427 in alsa-driver (Ubuntu Lucid) "[NFORCE - NVidia nForce2] ALSA test tone not correctly played back" [Undecided,New] https://launchpad.net/bugs/661427
<ScottK> psychicist: ^^^ That should get someone who knows better than I do to look at it.
<slangasek> ScottK, psychicist: what update caused the regression?
 * ScottK looks at psychicist.
<slangasek> this is filed against alsa-driver, but I don't see an alsa update in the attached log
<ScottK> (all I know is he showed up with a regression)
<slangasek> or even anything sound-related
<ScottK> slangasek: That's the default when you file a bug about sound.
<slangasek> sure
<ScottK> <psychicist> today I have had two issues with people calling me and saying that they lost sound
<ScottK> <psychicist> in one case it was solved by applying updates and in the other case sound has stopped working after applying updates
<ScottK> ^^^ is what he said when he arrived.
<barry> Quintasan: i'm actually not sure, i haven't done one of those yet.  if ScottK doesn't know off the top of his head, i will find out
<psychicist> slangasek: I have attached a log of the updates I applied on this system just a few hours ago, I don't know if it was alsa-driver or something else, because as far as I know nothing sound-related was updated
<psychicist> but sound has stopped working nonetheless
<slangasek> psychicist: when did sound stop?  Immediately after applying the updates?  After a reboot?
<Quintasan> barry: well, the debian's wiki says it should be before any dh_strip but I can't find any direct dh_strip, well I'll just put it before them and see what happens
<psychicist> slangasek: I am not sure about that, I rebooted after applying these updates
<slangasek> psychicist: I see no indication that this regression is related to the latest round of updates.  When was your last reboot prior to this?  Also, please attach /var/log/apt/term.log to the bug report (I've followed up to the bug with a request for this information)
<slangasek> afk, back shortly
<barry> Quintasan: let me know how it goes :)
<ScottK> Quintasan: If there's a direct reference to dh_pysupport, put it just after that.
<Quintasan> ScottK: okay
 * Quintasan hopes the universe won't explode after pbuild
<jdstrand> a/win 14
<barry> Quintasan: here's an example from markupsafe which has been converted to dh_python2 and dh_python3: http://pastebin.ubuntu.com/514095/
<ScottK> (however we don't want to pysupport -> dh_python2 in Ubuntu without concurrence from the Debian maintainer)
<Fitzsimmons> how do you add a menuitem to an existing appindicator? I'm pretty sure gwibber and pidgin are doing this, but I can't find the code for it
<barry> ScottK: right.  hopefully soon :)
<Quintasan> barry: well, it seems it's read to go, can you paste me the control file somewhere as well?
<kirkland> jdstrand: thanks
<barry> Quintasan: http://pastebin.ubuntu.com/514103/
<psychicist> ScottK: slangasek: thanks for your help, I will try a reinstall on another partition on Sunday and see if the problem can be reproduced
<sistpoty> resizing an ext4 fs: 5$, resizing lvm underneath it: 10$, recovering data from backup: priceless :)
<SpamapS> sistpoty: :)
<nemo> I know this has come up before.
<nemo> (and there are a few bugs on it)
<nemo> buuuut
<nemo> # ls -lh .xsession-errors
<nemo> -rw------- 1 1000 1000 373G 2010-08-26 13:11 .xsession-errors
<Quintasan> barry: thanks, my internet is slower than a turtle crawling today
<nemo> just throwing it out there :)
<Quintasan> >373G
<sebner> huhu sistpoty =D
<Quintasan> No, how did you manage to get it so big? :O
<nemo> Quintasan: good question
<nemo> I'm trying to figure that out
<nemo> unfortunately, seeking through a 373GiB file takes a while
<nemo> dd seek=381931 bs=1M count=1 .xsession-errors
<Quintasan> Why not just rm -rf it?
<nemo> Quintasan: I want to see what is in it before I erase it
<nemo> Quintasan: this was on an ubuntu machine that was left idle for a while
<Quintasan> >a while
<nemo> it disturbs me that this sort of thing could happen to a machine just sitting there
<nemo> Quintasan: a while like.... a few weeks to a month
<nemo> or so
<Quintasan> ...
<Quintasan> @_@
<Quintasan> 383GB of text in a month?
<Quintasan> I don't think I can even download that much
<nemo> regardless, xsession-errors should have some sort of cap
<nemo> like any log file
<Quintasan> -rw------- 1 quintasan quintasan 1,5M 2010-10-15 22:47 .xsession-errors
<nemo> rolling limit of, oh, 5 megs or something
<nemo> not sure if ubuntu has any control over that
<nemo> Quintasan: I know. that's not atypical
<nemo> mine at home is less than a meg
<nemo> with an uptime of 26 days
<nemo> but the fact that it happens at all...
<barry> Quintasan: no worries
<nemo> man. I wish dd could tell me how far it had seeked into the file.
<kklimonda> sending USR1 signal doesn't show that?
<nemo> nope
<nemo> not for seek
<nemo> does tell me it has been running for 52 minutes now
<kklimonda> :)
<sistpoty> hi sebner
<nemo> hmmmm
<nemo> you know
<nemo> maybe I should have just started from the start
<nemo> Starting Oracle Universal Installer... Checking installer requirements... Checking Temp space: must be greater than 400 MB. Checking monitor: must be configured to display at least 256 colors    Failed Could not execute /usr/X11R6/bin/xdpyinfo Checking if CPU speed is above 300 MHz.    Actual 2992 MHz    Passed
<nemo> etc etc
<nemo> Some optional pre-requisite checks have failed (see above). Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n] Continue? (y/n) [n]
<Quintasan> Oh god...
<nemo> repeat Continue? (y/n) [n]
<nemo> for line after line after line
<Quintasan> tail -n 50>
<nemo> TBH I'm not sure why the "Oracle Universal Installer" is running - much less as this user
<Quintasan> ?
<nemo> Quintasan: tried that first, that hung forever so I decided to try dd w/ a large block size
<nemo> aaaanyway, a process spamming STDERR should not fill up a disc like this :-p
<Quintasan> No wonder, no normal text processing expects 300+ GB file
<Quintasan> text processing app*
<Quintasan> nemo: a request from #ubuntu-pl -> "Pastebin it ;)"
<nemo> haha
<nemo> here we have a clue
<Quintasan> Years worth of reading
<nemo> the .xsession-errors has this not far from the continues.
<nemo> near the top of the file
<nemo> Wed Aug 25 15:54:02 2010
<nemo> the last date in the file?
<nemo> -rw-------  1 1000 1000 400485761024 2010-08-26 13:11 .xsession-errors
<nemo> so. in about 3 days. it generated 373GiB of spam
<nemo> if it really is those 20 characters, repeated...
<nemo> that's around 75k repeats of the message in the log
<nemo> per second
 * nemo rechecks his math
<Quintasan> no, seriously, this is some sort of a record
<nemo> yep. 75k or so repeats per second
<nemo> I'm astounded the machine functioned
<nemo> I'm guessing some incredibly stupid shell script in that installer, running in a loop,
<nemo> I wonder if by any chance that was actually part of an attempted install
<Quintasan> at least you know that your machine is powerful when it comes to printing the text to a file :P
<nemo> you know. there are a few bugs on this issue...
<nemo> but I'm thinking this one might give it a little more profile
<nemo> there really is no reason whatsoever this file should have gone beyond even a few megabytes before starting to truncate
<Quintasan> nemo: post it on planet
<nemo> planet?
<Quintasan> Ubuntu Planet
<Quintasan> You are not a member yet?
<nemo> maybe. dunno
<nemo> I don't use that stuff very often
<nemo> woah. wait
<nemo> I fail at math
<nemo> or rather, calnedars
<jpds> Doesn't sound like it's Ubuntu's fault.
<nemo> that was from the 25th at 16h to the 26th 13h - really it was 21Â¼h or so
<nemo> jpds: well. I suppose in the sense that .xsession-errors behaviour is not ubuntu's decision
<nemo> ok. that was really 256KiB/s written
<Quintasan> nemo: Why don't you release it as a book? :D
<nemo> it'll compress really well
<nemo> jpds: doesn't mean ubuntu couldn't choose to add truncation
 * nemo looks into what options there are for that file
<nemo> MAX_XSESSION_ERROR_BYTES
<nemo> hmmm
<nemo> maybe it *is* ubuntu's fault :)
<nemo> http://ubuntuforums.org/showthread.php?t=980958 - clearly this wasn't the only case
<nemo> ah. gdm does its own purging
<nemo> looks like this problem spans distros. no one has offered a decent solution
<Quintasan> 400 505 700 352 <- I counted the number of characters in this file, assuming each is char is 1 bit
<nemo> er. you mean 1 byte right
<Quintasan> oh yes
 * Quintasan can never get this right
<nemo> also, the number of characters is presumably same as the number of bytes. divide by 20 and you get how many times that continue message shows up in there
<nemo> thus my estimate of 256,000 repeats of the message each second while that log was active
<nemo> looks like bugs have been filed on this for over 6 years, with no solutions offered
<nemo> so clearly this one is not going to be solved tonight
<Quintasan> :O
<Quintasan> nemo: can you compress it?
<nemo> heh
<nemo> probably
<Quintasan> or just tell me how long it would take to compress it :D
<nemo> jpds: IMO the simple solution would be for xinit to change from:
<nemo> looks like bugs have been filed on this for over 6 years, with no solutions offered
<nemo> oops
<nemo> er. to continue
<nemo> to change from:
<nemo> exec >"$ERRFILE" 2>&1
<nemo> to:
<nemo> exec 2>&1 | head -c 5000000 > "$ERRFILE"
<nemo> then after the 500,000
<nemo> presumably the rest would just disappear into the void
<nemo> er. the 5,000,000
<Quintasan> >probably
<nemo> I believe I will file a bug asking if this would be feasible
<Quintasan> attach your log as proof :P
 * Quintasan is curious how long it would take to compress this
<nemo> https://bugs.launchpad.net/ubuntu/+source/x11-apps/+bug/661494
<ubottu> Launchpad bug 661494 in x11-apps (Ubuntu) "Request to limit xinit writes to .xsession-errors to some reasonable value, such as 10 megs" [Undecided,New]
<nemo> hopefully that's an appropriate place to file it
<Quintasan> well, it's time to go to bed
<Quintasan> night
<Quintasan> nemo: well, I hope you get some response on this bug :)
<nemo> me too :)
<plasmasolutions> Hi@allI've got a problem: I used the gconf-sharp in a project some time ago...and I'd like to continue development but realized that this assembly is not packaged with ubuntu any more.. What's the appropriate replacement for this?
<plasmasolutions> Maybe it's assembled in another assembly?
<nemo> well. dd has been running for 1h 40m.  I think I'm going to give up on reaching the end of this file
<nemo> I'm going to assume it consists of exactly what I suspect it does
<nemo> a cat of the file just scrolled that endlessly until I got bored
<ajmitch> plasmasolutions: it's still there, hasn't been removed at all
<ari-tczew> please any core-dev open task on lucid in bug 626379
<ubottu> Launchpad bug 626379 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in g_main_context_dispatch()" [High,Fix released] https://launchpad.net/bugs/626379
<directhex> um... does anyone else experience CRAZY cpu load from dbus-daemon in maverick?
<nemo> directhex: not personally, but have you tried ltrace -S or similar to see what it is doing?
<plasmasolutions> Another question: Does anyone knows if it's possible to change another users gconf entry through gconf-sharp?
<plasmasolutions> Specifically in this case: changing the background image of gdm through gconf-sharp
<Pilif12p> Hey guys. Are there any bindwood developers in here? If so, doesb http://crash-stats.mozilla.com/report/index/bp-9f94cd73-56c7-4381-b09a-86a2f2101014 look like it's related to it?
<directhex> nemo: i'll try that next time
<directhex> problem is, when dbus misbehaves, yer screwed. try restarting it without doom
<nemo> directhex: I've restarted it before
<directhex> kills gdm, for one
<nemo> that's doom? :)
<plasmasolutions> Anyone a hint? Or idea how to do it?
<nemo> what irritates me about dbus, personally, is it moderately complicates cron jobs
<nemo> plasmasolutions: personally I have a loathing for the language, so really can't be of much help :)
<nemo> (no familiarity)
<directhex> plasmasolutions: this is a channel for development of, not on, ubuntu. try #mono on gimpnet
<sistpoty> ari-tczew: is it a problem under lucid in the first place?
<ari-tczew> sistpoty: I don't understand the question.
<sistpoty> ari-tczew: you want a lucid task, right? my question is, if the bug is found in lucid as well (still reading the bug report though)
<ari-tczew> sistpoty: yes, it exist in lucid.
<sistpoty> ari-tczew: ok, thanks, task opened
<ari-tczew> sistpoty: thanks
<cjwatson> Pilif12p|afk: it might be worth trying #ubuntuone, since those guys work on bindwood
#ubuntu-devel 2010-10-16
<psusi> cjwatson, we're still using gparted 0.6.2 and 0.6.4 is out and fixes the long standing bug with dmraid disks.  Would it help if I were to get 0.6.4 built and tested and request a merge, or does debian need to update first?
<vish> oubiwannÂ¦ hi, i see a lot of UDS sessions for gestures, they all seem to be about multi-touch... is anyone looking into triggering some of those gestures with mouse/touchpad?
 * vish not volunteering .. ;)
<wgrant> vish: Note that some newer touchpads are multitouch.
<vish> yea
<vish> but some of the basic swipe gestures, could be tried with holding one of the buttons or both
<vish> there is a Firefox extension which does that..
<ari-tczew> cjwatson: could you remove pyclamd and pyexiv2 from MoM?
<kalkin-> hi
<kalkin-> can perhaps ubuntu compile php5 with --with-curlswrappers ?
<kalkin-> it would be really helpfull
<ari-tczew> kalkin-: file a bug, developers will review your request. it will be approved or declined
<kalkin-> ari-tczew: where should i file it?
<kalkin-> i have no idea about ubuntu developer stuff
<ari-tczew> kalkin-: on launchpad/ubuntu to php5?
<kalkin-> k, i can google launchpad
<kalkin-> normally i use gentoo on servers :)
<ari-tczew> kalkin-: https://launchpad.net/ubuntu/+source/php5/+bugs
<kalkin-> thanks
<kalkin-> i will do it
<kalkin-> but another question
<kalkin-> i'm build php *.deb packages from source
<kalkin-> i checked out with apt-get source php5
<kalkin-> installed all dependencies
<kalkin-> changed debian/rules to contain the --with-curlwrappers
<kalkin-> but when i'm running sudo dpkg-buildpackage -j16 i get the following error
<kalkin-> http://nopaste.info/701d703bf6.html
<kalkin-> i build like this php packages for ubuntu php5-5.2 and it worked
<kalkin-> but with php5.3 it doesn't work
<kalkin-> anymore
<kalkin-> becuase the build process fails
<kalkin-> any idea?
<sladen> kalkin-: that's only a partial log
<kalkin-> sladen: the whole log is REALY long
<sladen> kalkin-: first result from a quick google is  http://ubuntuforums.org/showthread.php?t=874013
<kalkin-> sladen: thanks, but it doesn't really help me
<sladen> kalkin-: right, and neither does an incomplete log file help me to help you :)
<kalkin-> sladen: how much i want to see? :)
<sladen> kalkin-: http://paste.ubuntu.com/ shouldn't have any limit
<kalkin-> i will just build it again and show you the whole log
<kalkin-> filled out the bug on launchpad
<kalkin-> how long it takes someone to react on this, and will be the switch added to current version?
<kalkin-> fuck i just noticed i use 10.4 lts
<kalkin-> it probably wouldn't added to lts
<kurrata> hi, i have 2 questions. i made my own .deb file and installed it. Why i cant find it in software center as installed package. And 2nd question. How do i get that screenshot to show in software center when i am installing package? http://codepad.org/1KHsIFrm control file
<kalkin-> kurrata: what says aptitude search $YOURPACKAGE ?
<kurrata> kalkin- aptitude has it under unknows section
<kalkin-> has it an i in front of package?
<kurrata> yes it has
<kalkin-> then it's installed
<kurrata> hi, i have 2 questions. i made my own .deb file and installed it. Why i cant find it in software center as installed package. And 2nd question. How do i get that screenshot to show in software center when i am installing package? http://codepad.org/1KHsIFrm control file
<kalkin-> with section you mean somethink like gnome kde ect...?
<kurrata> i know that its istalled, i can run it it just doesnt show up in software center
<kalkin-> in the aptitude ncurses frontend?
<kurrata> kalkin- yea
<kalkin-> kurrata:  and software center has no category unknown?
<kurrata> it has only 1 category ubuntu supported nothing else
<kalkin-> i'm not really in this gui stuff, never run an ubuntu desktop, but AFAIK is software center just another frontend for apt
<kalkin-> hmm no idea, but perhaps some one else could help you
<kurrata> not using ubuntu to but need to make .deb file
<kalkin-> sladen: aehm, the output is something like 41MB
<kalkin-> here the last 1k lines from the ouput http://files.blase16.de/output2
<ari-tczew> doko: can we sync package python-profiler from Debian unstable?
<ScottK> ari-tczew: We don't generally manually remove packages from MoM.  If there is something that shouldn't be there, just leave a comment.
<kalkin-> k now i'm puzlled
<kalkin-> how the hell are you building the php deb packages?
<kalkin-> i just downloaded with apt-get source php5
<kalkin-> and run dpkg-buildpackage -J16 -D
<kalkin-> and it fails
<kalkin-> with the same error
<kalkin-> this way would every mainter build his package, and because there're php5 packages i think it should be build this way
<kalkin-> *should be possible to
<Amaranth> wgrant: Kept logging me out, filed bug 661748
<ubottu> Launchpad bug 661748 in Launchpad itself "keeps logging out" [Undecided,New] https://launchpad.net/bugs/661748
<rafaelsf80> disconnect
<rafaelsf80> connect localhost
<ari-tczew> kalkin-: change what you want, debuild -S, then pbuilder-dist maverick .dsc file
<ari-tczew> kalkin-: you want change one flag, might be debian/rules satisfy you
<cjwatson> ari-tczew: pyclamd and pyexiv2 removed, for the next run
<ari-tczew> cjwatson: thanks! could also remove nautilus-image-converter and ilohamail? both on universe
<cjwatson> ScottK: they needed to be removed because they were on the sync-blacklist so MoM wasn't processing them and the merges were stale
<cjwatson> ari-tczew: nautilus-image-converter done, but if I remove ilohamail I think it will just come back - that's genuine version confusion.  why not just merge it as 0.8.14-0rc3sid6.1ubuntu1 or something?
<ari-tczew> cjwatson: previously merger messed d/changelog :/ take a look
<cjwatson> oh of course, it can't be merged as that version because it's less.  but in any event I can't simply remove it for the reason I just gave.  I suggest leaving the comment there and putting up with it
<kalkin-> ari-tczew: i added my flag to debian/rules
<cjwatson> it'll sort itself out eventually as time goes on
<ari-tczew> kalkin-: cool
<kalkin-> but i'm building with dpkg-builpackage is it wrong?
<ari-tczew> kalkin-: as I said, use debuild -S for build source package, then cd .. and pbuilder-dist maverick *.dsc
<kalkin-> i will try it after this compile run is over
<kalkin-> ari-tczew: thanks for the hint
<kalkin-> hope it works
<ari-tczew> if your change doesn't provide ftbfs, it will work
<kalkin-> ftbfs?
<ari-tczew> kalkin-: Failed To Build From Source
<cjwatson> category: acronyms that obscure meanings for the uninitiated
<kalkin-> hehe
<ari-tczew> 2 days natty opened and 150 merges reduced! thanks to all people involved
<cjwatson> yeah, the progress is pretty good.  most of the ones I have left are in the "irritatingly hard" set
<ScottK> cjwatson: Ah. I see.  Thanks.
<cjwatson> it's a MoM bug of course, it should at least process sync-blacklist to the extent of removing any merges on it ...
<Quintasan> barry: well, it builds but I'm not sure if guys in debian want this :P
<ari-tczew> cjwatson: update: 177 the number of reduced merge since natty start. (560-383=177)
<ari-tczew> and this number is growing up
<rooligan> will libreoffice be included in Natty if it is stable then? Or will OpenOffice.org keep being the office suite of Ubuntu?
<fagan> rooligan: Id say it will be
<fagan> Libreoffice is stable BTW because its a fork of openoffice it is more or less the same code
<fagan> so there shouldnt be anything stopping including it
<rooligan> fagan: ok, thanks to you :-)
<cjwatson> rooligan: see the LibreOffice initial press release
<fagan> cjwatson: I was just about to say that
<cjwatson> I'd copy and paste Mark's comments from that but the PDF reader on my phone doesn't seem to want to let me
<cjwatson> http://www.documentfoundation.org/pdf/tdf_release.pdf, anyway
<rooligan> cjwatson: thank you!
 * nigelb helps
<nigelb> "               Office productivity software is a critical component of the free software
<nigelb> desktop, and the Ubuntu Project will be pleased to ship LibreOffice from The Document
<nigelb> Foundation in future releases of Ubuntu.
<cjwatson> he wasn't specific about which release of course, that will depend on how things work out operationally, but I imagine the desktop team will be pretty interested
<nigelb> There's a bit more, but that's the relevant bit
<cjwatson> ta Nigel
<nigelb> np :)
<fagan> Well cjwatson there shouldnt really be anything to stop it from it from being a drop in replacement to open office
<geser> what's the difference between OO.org and LibreOffice?
<fagan> geser: less oracle
<fagan> more google and novell
<fagan> (I think google)
<penguin42> is there anything explicitly removed from LO so that some OOo scripts etc might not work?
<fagan> penguin42: Im pretty sure they are removing all of the old star office extention crap
<penguin42> fagan: Ah OK, I was thinking more Java stuff - but from a distro side I guess it's tricky to replace a package if it might break some random set of users
<fagan> penguin42: well the java stuff too I think
<fagan> there are a few things that are linked to star office that they dont want at all
<fagan> its probably in the announcement somewhere
<fagan> http://www.documentfoundation.org/pdf/tdf_release.pdf
<ScottK> I'm guessing the initial effort will be mostly to integrate the go-oo patches that we already shipped.
<cjwatson> fagan: nothing major, I imagine, but it is likely to take a while.  OOo was a beast to package; LO will probably be better since one of their goals is to make the build saner (and they've already integrated go-oo changes to that end), but even so it's hardly a five-minute job
<cjwatson> plus, most of our OOo packaging comes from Debian at the moment, which is frozen
<penguin42> if they could make it build in a finite amount of space and time maybe it would attract more people to work on it
<cjwatson> though google indicates that there's already been packaging work on the Debian side
<cjwatson> e.g. http://bzr.debian.org/pkg-openoffice/packages/libreoffice/3.3.0/experimental/ - Rene on the ball as usual
<Ganonkiller> i am currently trying to get my gps card to work on meerkat... its a ETAK GPS Card ET-GPS1
<Ganonkiller> are the drivers still supported?
<fagan> Ganonkiller: support questions are supposed to be asked in #ubuntu
<Ganonkiller> i meant to ask if the drivers were developed for meerkat support
<fagan> Ganonkiller: well thats something to ask the upstream linux developers we are downstream
<fagan> so its still off topic for here
<Ganonkiller> geez
<fagan> Ganonkiller: I hate to be bad but thats the way its done. We dont really know everything that goes on in the Linux kernel so we cant answer questions like that
<Ganonkiller> i just wanted to know if the drivers are still supported?
<Ganonkiller> nobody in #ubuntu is helping me
<fagan> then id suggest just trying out the maverick live cd to make sure
<Ganonkiller> nothing there
<fagan> I mean testing it out and seeing if it works for yourself
<ScottK> barry: It would be nice if you could have a look a numpy sooner rather than later to see if we can reasonably split it or if we need to promote matplotlib to Main.
<GoHawks> o
 * psusi groans at the lack of documentation of the patches in lvm2
<sanduz2> you all need to break up #ubuntu into more specific topics, the amount of people and conversation that goes there is unworkable
<JohnPlay> hello
<JohnPlay> how do i upgrade my ubuntu 10.4 to 10.10
<penguin42> JohnPlay: See http://www.ubuntu.com/desktop/get-ubuntu/upgrade    but please note that the right channel for support is #ubuntu
<JohnPlay> [doko]: thanks
<JohnPlay> i meant OK
<psusi> hrm... dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below.  it says warning, so it should continue with the build no?  but then after the diff:
<psusi> dh_makeshlibs: dpkg-gensymbols -plibdevmapper1.02.1 -Idebian/libdevmapper1.02.1.symbols -Pdebian/libdevmapper1.02.1 -v2:1.02.55-0ubuntu1 -c2 returned exit code 2
<psusi> what exactly is going on with this makeshlibs stuff?  it is trying to make sure there is no abi change?
<psusi> but it looks like only new symbols were added, so should be ok no?
<ebroder> psusi: the makeshlibs stuff is also used for generating accurate library version dependencies
<ebroder> (i.e. if a executable uses a particular symbol, the package should depend on library (>= when that symbol was added))
<ebroder> So you need to update the .symbols file whenever new symbols are added, so that information is accurate going forward
<psusi> ok... how do I do that?
<ebroder> There should be a .symbols file in the debian directory. The format should be fairly obvious
 * ebroder doesn't have an example in front of me to follow along
<psusi> don't see one...
<ebroder> What package is this?
<psusi> lvm2
<psusi> ok, seems there are a few different ones for different binary packages it builds
<ebroder> Right
#ubuntu-devel 2010-10-17
<psusi> can I just run patch against that file and paste in the diff output?
<ebroder> If you're jumping across multiple upstream versions, it's better to take the time and track down the specific upstream versions where the new symbols were added
<penguin42> don't suppose anyone knows the nm or objdump magic to show which version of a symbol something either declares or wants?
<psusi> why bother if they weren't packaged?
<ebroder> psusi: You don't know that they weren't
<psusi> I don't think you can do that penguin... you can just see that it needs a symbol, which is why it is important that symbols not change, only add new ones, then you can see what version the new one was added with this symbol file apparently
<psusi> ebroder, well they aren't in debian or Ubuntu ;)
<ebroder> psusi: There exist packages outside of Debian and Ubuntu
<psusi> I don't think I care enough to bother... especially since I"m taking it from .54 to .74, so 20 upstream releases
<psusi> updating the symbols on each one would be a royal pita
<penguin42> (readelf is the answer to symbol versions)
<lool> Hmm looks like linux-source-2.6.36 was put in universe instead of main
<ogra_ac> usual hiccup
 * ScottK is learning about fixing linker failures.
<ScottK> So far ~ half the Universe packages I've touched FTBFS with the new linker behavior.
<ogra_ac> fun
<ebroder> This is the one where you...start linking libraries you only indirectly depend on?
<ebroder> Or is it stop?
<psusi> new linker behavior?
<ScottK> ebroder: It's the indirect one.
<ScottK> psusi: See doko's "Natty open for development" message to u-d-a.
<psusi> k
<ebroder> Wait - are we switching to gold, or just changing how the old linker works?
<vadi21> debuild is trying to sign with an invalid email that's not set in the changelog nor DEBEMAIL. Where else could it be getting it from?
<psusi> so if I understand this correctly, if you call function foo in lib bar, and you link to lib bar but not lib snoz, but lib bar does... in gcc 4.4 the linker ended up mashing them all together and thus, resolving references you make to libsnoz?  and now it doesn't?
<ScottK> ebroder: Apparently changing how the old one works.
<ScottK> psusi: Yes.
<ebroder> Wait, is that it, or is it s/function foo in lib bar/function foo in lib snoz/?
<psusi> goofy... so basically the fix is to add the -l directives that should have been there all along but weren't?
<ScottK> We've gone a couple of cycles now without a toolchain change that made us fix  a bunch of stuff to get things that built before to build again.
<ScottK> psusi: Yes.
<ebroder> "Developers are frequently lazy; film at 11"
<psusi> as evidenced by the several quilt patches in lvm2 that have no documentation
<psusi> fortunately, I managed to either fix to apply, or determine upstream integrated already, about half of them
<psusi> the other half... not sure what they are for so if they didn't cleanly apply, I just dropped for now
<psusi> it's funny, at first I didn't like the buttons on the left of the window thing... but I went to the Renesas DevCon this week and there was a lab using Fedora... I kept trying to click the left when the buttons were on the right
<psusi> wohoo!  new version of lvm merged, built, and running... now to finish the changelog entry, push the branch to lp and see if I can get someone to review and merge it ;)
<psusi> after I play with merging snapshots a bit...
<micahg> has anyone seen something like this in natty? http://pastebin.ubuntu.com/514787/
<wgrant> micahg: GCC 4.5's behaviour has changed.
<micahg> wgrant: I know, but this seems unusual with 2 libraries having the same symbols
<wgrant> ld won't let you link against symbols that you only pull in indirectly.
<micahg> oh, right, I guess that's what it is :-/
<wgrant> http://fedoraproject.org/w/index.php?title=UnderstandingDSOLinkChange
<micahg> wgrant: great, thanks
<ArneGoetje> cjwatson: Hi! I have a problem with grub2 from a freshly installed Maverick to boot Windows XP: when just pressing enter on the WinXP entry in the boot menu, WinXP cannot find autochk and fails to boot. However, if I select the entry in the boot menu, press 'e' and then crtl+x without changing anything, then WinXP boots without problems. Any idea?
<ArneGoetje> cjwatson: forget it... configuration mistake. :) 'insmod parttool' and 'insmod'chain' were missing.
<ArneGoetje> cjwatson: gaa... no, that didn't fix it, problem is still there... anyways: bug #662015
<ubottu> Launchpad bug 662015 in grub2 (Ubuntu) "WinXP fails to boot from boot menu, but boots fine from edit mode" [Undecided,New] https://launchpad.net/bugs/662015
<cjwatson> ArneGoetje: bizarre.  no ideas off the top of my head, unfortunately ...
<ari-tczew> cjwatson: could you remove from merge-o-matic/main these packages? libfile-basedir-perl , myspell-sk
<cjwatson> ari-tczew: done
<ari-tczew> thanks
<geser> cjwatson: I'm currently merging vim and asking myself if the python3 interpreter support should also be enabled for the basic builds or still only the python2 one?
<cjwatson> geser: good question, I don't know.  does it add dependencies not currently in main?
<cjwatson> and do they conflict in any way?
<geser> probably not (have to check the b-d to be sure) but it build-depends on python3-dev which is already in main
<cjwatson> I suppose it would add libpython3.1 or something to vim's footprint
<cjwatson> but it doesn't seem obviously wrong to me to enable python3 support
<geser> cjwatson: probably no conflict as for ALLINTERPRETERS both get enabled
<doko_> not, if a vim package ends up with dependencies on both 2 and 3
<geser> we changed in the the past NOINTERPFLAGS to enable python also in the basic builds and now there is also an option for python3
<cjwatson> doko_: does that mean "not obviously wrong" or "no we shouldn't do it"?
<doko_> I'm wondering if it's even possible to configure with both interpreters, and what you end up with. so I don't know about the former, but we shouldn't do that, if it results in a binary/package pulling python3 on the cd's. if a separate binary package is built, which is not on the CD, ok
<geser> which vim variant is on the CDs?
<cjwatson> vim is on the server CD, not desktop
<cjwatson> vim-tiny is on everything
<geser> I'll do a test-build and check the resulting dependencies then
<geser> cjwatson: vim gets now compiled with "--with-modified-by=NAME       name of who modified a release version" set to the Debian Vim maintainers mailing list. Should I left it like this or set it to ubuntu-devel-discuss@ ?
<cjwatson> I don't know, use your judgement
<ari-tczew> cjwatson: could you remove xf86-input-evtouch and mochikit from merge-o-matic/universe?
<ari-tczew> cjwatson: also could you take a look why zsh-beta exist in merge-o-matic/universe as Updated merges?
* elmo changed the topic of #ubuntu-devel to: forums and wiki down for 5m for emergency maintenance |  10.10 released on 10/10/10 at 10:10:10UTC!! | Natty is open, more SRUs for Maverick | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for h
* elmo changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | Natty is open, more SRUs for Maverick | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dan4dm> hi, i'm working on a ubuntu-based distro, trying to change the distro name in ubiquity. (the files use a ${RELEASE} variable, not sure where that's set.) anyone know where to set it? (if this isn't the right channel, pls advise the right one!)
<dan4dm> (to be more exact, it's the distro name displayed in the ubiquity gui screens that i'd like to change)
<geser> doko_, cjwatson: I've tried compiling vim 7.3 with dynamic loading of python2 and python3. The resulting deb has no dependency on python (or libpython) at all and vim tries loading libpython2.6 or libpython3.1 when one uses :py or :py3 commands. It this acceptable to let both enabled (with dynamic loading)?
<sladen> dan4dm: are the strings coming from debian-installer underneath?
<sladen> dan4dm: but  apt-get source ...  && grep -r 'RELEASE ?='
<dan4dm> AHA got it
<dan4dm> it's in /usr/share/ubiquity/ubiquity/misc.py    !
<dan4dm> thanks
<penguin42> tumbleweed: Are you sure about marking kicad for lucid as invalid, won't the lucid-updates build of libwx-gtk break the kicad that's there at the moment?
<tumbleweed> penguin42: it started up fine for me with libwxgtk2.8-0=2.8.10.1-0ubuntu1.2
<penguin42> that's curious, I wonder how that works
<penguin42> tumbleweed: Could you do   readelf -s libwx_gtk2u_aui-2.8.so.0 | grep -i _ZTI12wxAuiToolBar   and the same on the kicad ?
<tumbleweed> penguin42: can't see any linkage to libwx_gtk2u_aui at all in the lucid version
<penguin42> hmm well that would explain why it didn't break
<penguin42> although what the heck a KDE app is doing being linked to a gtk library I'm not sure
<penguin42> ah, it's not KDE
<penguin42> hmm oh well, if it works
<dan4dm> http://gitorious.org/puredyne-packages/pa
<dan4dm> (wrong channel sorry)
<geser> doko_: did the "buffer overflow" checker in gcc-4.5 got improved compared to gcc-4.4? As I've trouble to compile my merged vim package in natty because of a "buffer overflow" when trying to run the binary. Compiling it with gcc-4.4  or gcc-4.5 -O0 works. (The current vim package in the archive shows the same problem when getting build in natty)
<geser> doko_: it seems to be relate with the usage of "di_key[1]; /* key (actually longer!) */" as last member of a struct (di_key gets overflowed on purpose)
<mattn> hi
<mattn> where can i report a bug in gi18n-lib.h in ubuntu 10.10?
<mattn> i can't find a suitable bug tracker for thsi
<ansgar> mattn: libglib2.0-dev: /usr/include/glib-2.0/glib/gi18n-lib.h (on Debian at least).  dpkg -S <file> and apt-file search <file> are helpful.
<penguin42> mattn: Then just run ubuntu-bug libglib2.0-dev
<mattn> thanks
<penguin42> mattn: #ubuntu-bugs for help reporting bugs, #ubuntu for general support
<lyhana8> hi there, am I in the right place to ask for package patching?
<penguin42> lyhana8: Generally if it's a bug or wishlist add a bug
<lyhana8> penguin42: it's about a patch on the ATI driver package
<lyhana8> the bug is marked as fixed
<lyhana8> patch is to be done on fglrx kernel module to compile again on kernels with CVE-2010-3081 fixed
<ubottu> The compat_alloc_user_space functions in include/asm/compat.h files in the Linux kernel before 2.6.36-rc4-git2 on 64-bit platforms do not properly allocate the userspace memory required for the 32-bit compatibility layer, which allows local users to gain privileges by leveraging the ability of the compat_mc_getsockopt function (aka the MCAST_MSFILTER getsockopt support) to control a certain length value, related to a "stack pointer underflow" issue,
<lyhana8> (as explain by someone on #ati)
<Kartagis> hello
<Kartagis> as I was installing 10.10 the other day, I noticed a translation mistake
<lyhana8> I need this one to work on ubuntu 10.04 n_n
<penguin42> lyhana8: Well you can file a bug or comment on that bug; you could try asking in #ubuntu-x or #ubuntu-kernel as well
<lyhana8> penguin42: k, thx
<micahg> Kartagis: please file a bug against the package and open a project task for ubuntu-translations
<Kartagis> micahg, okay thanks
<Kartagis> micahg, the package? I'm talking about installation. what package would that be?
<micahg> Kartagis: ubiquity I think
<Kartagis> okay thanks
<Kartagis> bye
<BUGabundo> hi everyone
<penguin42> Hi Bugs
<Ian_Corne> Hello BUGabundo :)
<BUGabundo> olÃ¡ Ian_Corne
<BUGabundo> you won't believe what I've been up all weeking
<BUGabundo> uploading pics and preping blog post
<Ian_Corne> :D
<BUGabundo> you will drewl
<BUGabundo> python-paramiko:
<BUGabundo>   Depends: python-crypto (>=2.1.0-2) but 2.0.1+dfsg1-4ubuntu2 is to be installed
<BUGabundo> ahh natty.... to good to be true
<kklimonda> :D
<Ian_Corne> I upgraded just fine :)
<kklimonda> BUGabundo: you should wait at least till a1 ;)
<BUGabundo> your just weak
<kklimonda> hell yeah! I like my system in usable state ;)
<BUGabundo> mine is
<ogra_ac> wont be for long i guess ;)
<ogra_ac> not much stuff uploaded to natty yet
<BUGabundo> it always is till feature freeze LOL
<BUGabundo> that's why I hate stable releases
<BUGabundo> they give me more probs then devel stuff
<ogra_ac> and there will likely be lots of build failures due to toolchain changes
<BUGabundo> ofc
<kklimonda> well, the feature freeze means "upload all the crack you can now, before it's too late" ;)
<ogra_ac> .... but you will get what you asked for :)
<BUGabundo> ogra_ac: but I've been doing this since 2007
<BUGabundo> so nothing is new to me
<BUGabundo> I know my away around most repo related probs
<BUGabundo> and what else breaks, goes into LP or nagging a dev
<cjwatson> ari-tczew: xf86-input-evtouch, mochikit, zsh-beta merges removed.  (zsh-beta showed as Updated because it's been uploaded in natty.)
<cjwatson> "orbital-eunuchs-sniper"?  package names get weirder and weirder
<lifeless> cjwatson: they'll become ship names before long
<lifeless> I could see milter renamed as 'the-grey-area' for instance
<cjwatson> :-)
<cjwatson> sendmail => The GCU You Really Didn't Want To Do That, Did You
<lifeless> cjwatson: nice
<BUGabundo>   PID MINFLT MAJFLT      VSTEXT  VSIZE  RSIZE  VGROW  RGROW  MEM CMD     1/4
<BUGabundo> 25926     38      6      48656K   1.1G 373.1M     0K   160K   9% chromium-brows
<BUGabundo> 30302      0      0        500K 589.5M 317.9M     0K    -8K   8% eog
<BUGabundo>  2927   4841      3      48656K   1.0G 286.4M     0K  1268K   7% chromium-brows
<BUGabundo> 10956    145     11      48656K   1.1G 264.7M     0K   440K   7% chromium-brows
<BUGabundo>  1525    389     18         35K 864.1M 213.8M     0K  1232K   5% java
<BUGabundo> stupid chromium
<ScottK> cjwatson: This might not be a bad time to re-run your very stale merges script and point out ones that ought to be looked at.
#ubuntu-devel 2011-10-10
<sammy> brand new package with no existing version in Ubuntu's repositories (will be uploaded with the .orig.tar.gz file): debuild -S -sa <- that means no existing version of this package of this version, right? if bob1.2 is in ubuntu, and i'm making a package for bob1.4 (not in ubuntu), I should be using -S -sa, not -S -sd, right?
<RAOF> -sa means "include .orig.tar.gz in the _source.changes file", which means "I'm going to upload an .orig.tar.gz for this", which is what you need to do when that version is not in the archive yet, yes.
<sammy> RAOF: huzzah, thank you. and to be clear, when I set the version number, I only need to do it in the changelog? debuild will pull the -ubuntu1ppa1 from there? I couldn't figure out where else to define the version.
<RAOF> The changelog entry is what defines the version.
<sammy> fantastic. yay for my first package from sid built for ubuntu
<sammy> now if only my mail admin would fire up courier-authdaemond which didn't start at reboot so I can check my email, confirm my new pgp key and upload it...
<didrocks> good morning
<nigelb> Morning didrocks!
<didrocks> hey nigelb
<nigelb> Exciting week :)
<pitti> Good morning
<sammy> oh I knew I had one more: it says if this can be used in any version I dont have to append natty... I'm assuming thats not the case for most things? if it should be obvious to me, its not. I'm guessing that only stands true for some things like low-level libraries with few if any dependencies
<sammy> (sorry I'd ask in ubuntu-packaging but theyre all asleep)
<RAOF> Or if it builds against stable-ABI; many things which build against GNOME would qualify there.
<sammy> this is an erlang program, ejabberd. hm. well a quick search on launchpad shows every ppa version lists the distribution. I assumed as such.
<dholbach> good morning
<YokoZar> does ticking the ubuntu-restricted-extras tickbox at install time enable s3tc?
<RAOF> No.
<RAOF> Bah, too slow.
<RAOF> Hm, thinking of which...
<infinity> dholbach: That Pilot day won't work for me, I'm on vacation.  Want to swap me a week later or something?
<dholbach> infinity, sure - just move it somewhere else in the calendar
<dholbach> I can do it too if you like
<infinity> dholbach: Go ahead.  I don't want to much with your scheduling mojo.
<rbasak> Can someone look at bug 862129 please - I've found tons of duplicates and there are more coming in daily. I think it's going to break a significant number of upgrades to oneiric, though I'm not clear under what circumstances it occurs.
<ubottu> Launchpad bug 862129 in samba (Ubuntu) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<dholbach> infinity, I'd love if it was just everybody's scheduling mojo and not mine :)
<dholbach> anyway
<dholbach> moved it a week later :)
<dholbach> err, two weeks later
<dholbach> there might be more important things than patch piloting at UDS
<dholbach> alright - time to go and walk the dog - see you in a bit
<Riddell> pitti: how can I test jockey driver install on a system where no non free divers are needed?
<pitti> Riddell: copy http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/view/head:/examples/fake.modaliases to /usr/share/jockey/modaliases/fake
<jussi>  /access
<jussi> cjwatson: ping
<Riddell> pitti: hmm, it still doesn't list any
<cjwatson> jussi: yes?  (please include content with pings)
<pitti> Riddell: you might need a "sudo killall jockey-backend" after installing the file, the backend keeps running for a while
<Riddell> oh aye
<jussi> cjwatson: sorry. Scott has deactivated himself from the ops team for here, just wanted to double check that its ok to remove him from the access list?
<pitti> Riddell: if it still doesn't work, does "apt-cache show fglrx" work? is this a live system with no restricted package indexes perhaps?
<cjwatson> jussi: yes
<cjwatson> if he deactivated himself then that's fine
<rbasak> Can someone look at bug 862129 please? I've found many duplicates and a new one comes in about once a day. I think it's going to break a significant number of upgrades to oneiric given how many bug reports we're getting from testers.
<ubottu> Launchpad bug 862129 in samba (Ubuntu) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<slangasek> tseliot: hey there - why is the /usr/share/grub-gfxpayload-lists/blacklist/00_header not sufficient to explain how to blacklist cards?
<slangasek> tseliot: I don't understand why you want to re-add a slave link to an empty blacklist file; if you actually need it, you could add it back to the packaging then?
<tseliot> slangasek: because this is a feature OEM should be able to use without my involvement. If they want to blacklist a card, they simply put the id in that file and that's it
<slangasek> tseliot: ah.  Well, I'm not sure I agree this is the way to do it, but ok :)
<tseliot> slangasek: ok, I'll make sure to change all proprietary drivers (8 packages) so that they have our changes
<slangasek> tseliot: ok.  Note that CD mastering is already in progress, and I don't think reverting this warrants restarting that process, so nvidia-current (the one I converted already) should be done to oneiric-proposed or held until precise
<tseliot> slangasek: I don't think the drivers are on the cd. Are you referring to the dvd image?
<slangasek> tseliot: they're on mythbuntu, ubuntustudio, and DVDs (maybe only on the Kubuntu DVD?)
<slangasek> maybe that change could still be accepted... should be coordinated with #ubuntu-release, anyway
<OdyX> pitti, tkamppeter: would it make sense (aka "would you have time") to discuss http://wiki.debian.org/Teams/Printing/RethinkingTheStack before oneiric's release?
<slangasek> but even so, it's not a critical fix so I don't think it warrants a final freeze exception
<tseliot> slangasek: ok. It's not a critical fix as only nvidia-current will get the bootsplash, the other 7 driver still won't (unless there are other regressions that my previous changes caused, that is)
<slangasek> tseliot: setting FRAMEBUFFER=n in the initramfs also breaks initramfs prompting for anyone with a crypted root filesystem
<slangasek> so I think the other packages ought to be fixed for that as well
<tseliot> slangasek: no doubt they should be fixed, the only question is when the fix should land
<slangasek> tseliot: if they're not on the images, there's still time to fix them before release
<slangasek> fglrx-installer seems to also affect the kubuntu DVD
<tseliot> slangasek: I can do it today. I expect the -updates flavours not to be on any image but the non -updates flavours should affect the images, as you said
<tseliot> as in fglrx-updates vs fglrx
<slangasek> tseliot: right, only fglrx and nvidia-current are on any images, the other variants (-updates, and the older nvidia flavors) are not
<tseliot> slangasek: so, shall I upload only fglrx and nvidia-current to oneiric-proposed and the rest to oneiric?
<slangasek> tseliot: I think that's best, yes
<tseliot> slangasek: ok, thanks for your help
<slangasek> tseliot: thank you :)
<akgraner> Hi all!
<akgraner> So open week is next week - if anyone can add a session you think new users or end users would like to know about and you all would like to share as it relates to Ubuntu or more specifically the 11.10 release please let me or jcastro know or please add your session to the open week schedule
<akgraner> I know it's a busy week for everyone, but Open Week is really popular and the community loves it...
<spy6> hi there
<spy6> are there already 11.10 pre-release images available?
<pitti> spy6: we are just rebuilding everything; but you can subscribe to images on http://iso.qa.ubuntu.com/qatracker/build/ to help out with testing
<pitti> spy6: note that these are not the official images until they are announced
<pitti> and they might change, be broken, etc.
<spy6> pitti: thats okay ... in most cases an upgrade after the release might help
<spy6> pitti: hmm ... if subscribed, the link for the image is published via mail?
<pitti> spy6: you'll get notifications about new images, yes
<fishor> hallo all, i investing some time to make vp8 work better. there are some patches upstream now (gstreamer), but there are also some not. In current ubuntu beta, gstreamer webm and matroska muxer has one bug. If you create high quality vp8 stream it will be partially brocken. I have a patch to fix it. This patch will not go to upstream becouse i need to make it per stream choice, not per file (as long term solution). my question do will actual
<fishor> ly accept this patch?
<brendand> i'm wondering is there a known bug in Gtk where if a child dialog hides itself when it's already hidden then the parent gets hidden as well/instead?
<seb128> bah, interaction with kernel bugs is ridiculous, it's an incomplete-new pingpong with a robot on every kernel upload :-(
<ogra_> not only with uploads :/
<didrocks> seb128: yeah +1 for me, and I still have my wifi driver randomly not loading correctly for the sprint
<didrocks> since*
<doko> soren, \o/
<herton> broder: hi, can you confirm bug 848687 is fixed with natty -proposed (2.6.38-12.51) kernel, and set the verification tag there?
<ubottu> Launchpad bug 848687 in linux (Ubuntu Natty) "DRI applications hang after DPMS standby on i965" [Undecided,Fix committed] https://launchpad.net/bugs/848687
<mvo> if there is anyone here speaking hebrews, could you please have a look at https://launchpadlibrarian.net/82484100/update-notifier-he.png and tell me if that string is correct ? and correctly line broken too?
<dholbach> mvo, I don't, but shouldn't they all be justified to the right side?
<dholbach> mvo, you could try asking in #ubuntu-il
<mvo> thanks dholbach
<mvo> dholbach: that is a excellent idea
<soren> doko: Yeah :)
<Laney> doko: your temporary patch to drop the darcs test suite on ppc, can I get rid of it now?
<Laney> doing an upload to work around the test failures
<doko> Laney, yes, I think so. ftbfs on armel too
<Laney> yep, should fix that
<Laney> also I am no longer convinced tests-use-bash does anything meaningful
<Laney> the test harness forces bash anyway
<bdmurray> Should bug 870214 be assigned to a package?
<ubottu> Launchpad bug 870214 in Ubuntu "iSCSI root installation creates manual eth0 configuration + long boot" [Undecided,New] https://launchpad.net/bugs/870214
<cjwatson> bdmurray: open-iscsi would be a decent start
<broder> herton: let me see if any of my coworkers actually tested it like they said they would. if not, it was easy to reproduce - i can get you an answer in about 15 minutes or so
<herton> broder: ok, thanks
<broder> herton: yep, coworkers forgot :). hunting down the machine with the problem now
<bambee> pitti: ping, language-selector-0.54 breaks language-selector-kde
<ScottK> There we go.
<bambee> "* LanguageSelector/LangCache.py [change not affecting KDE]:" -> it breaks language-selector-kde
<ScottK> bambee: Did you file the bug yet?
<ScottK> pitti was asking me how to test it.
<bambee> just type "kcmshell4 language-selector"  (reproducible : always) , let me open a bug first.
<pitti> bambee: ah, I tried to click on Region etc, and nowhere there it offers to install languages
<bambee> systemsetting -> locale-> system language (something like that)
<pitti> ok, ETA 12 mins for downloading
<broder> herton: i'm updating the bug now, but the fix is good. thanks for pinging me
<herton> broder: cool, thanks for checking it
<pitti> bambee, ScottK: I get: The service 'System Languages' does not provide an interface 'KCModule' with keyword language-selector/language-selector.py'.. is that what you see as well?
<pitti> ah, get it -- no sys.argv, hmm
<pitti> bambee: is there a bug report for this already?
<bambee> pitti, ScottK : bug 871922
<ubottu> Launchpad bug 871922 in language-selector (Ubuntu) "language-selector-kde crashes on startup" [Undecided,New] https://launchpad.net/bugs/871922
<pitti> ScottK, bambee, debfx: thanks, fix uploaded
<jdstrand> pitti: hey, I noticed that /run/motd is getting created with group read permissions via /etc/init/mounted-run.conf. I'm thinking this is because of the default umask of 0002, but was wondering where mounted-run.conf is getting its umask. do you know off-hand?
<jdstrand> pitti: asking you cause it seems you were driving the bp. feel free to tell me to go away if desired
<pitti> jdstrand: not off-hand, no; but apparently through pam then
<jdstrand> hmm
<pitti> jdstrand: perhaps upstart launches all services through PAM?
<jdstrand> wonders why that upstart script is getting run through pam
<jdstrand> maybe
<pitti> would make sense for some kinds, such as having locale settings
<jdstrand> jhunt: ^ can you comment?
<jdstrand> that file could conceivably be localized
<jdstrand> pitti: thanks
<jdstrand> run-parts' man page says it defaults to 022. I wonder if that is still accurate
<pitti> jdstrand: oh, you think it's from run-parts or within udev?
<pitti> I had assumed that the entire udev process runs under 002, and just passes that to its children
<jdstrand> pitti: well, mounted-run.conf does this: [ -d "/etc/update-motd.d" ] && run-parts --lsbsysinit /etc/update-motd.d > /run/motd &
 * pitti wonders if one can determine the umask from /proc
 * jdstrand was wondering the same
<jdstrand> if remove the file then do 'sudo start mounted-run', it is created 0022
<jdstrand> so it might be update manager that is doing it... (guessing, and trying)
<pitti> jdstrand: attaching gdb to a process and "call umask()" seems to do the trick
<jdstrand> cool, thanks
<pitti> hmm, no
<pitti> udevd runs with umask 022
<jdstrand> granted, this isn't a problem in and of itself; I just find it curious
<jdstrand> aha
<jdstrand> if I ssh 127.0.0.1, then it gets changed
<jdstrand> so, pam_motd
<jdstrand> (where pam_umask is called easlier in the stack)
<pitti> tseliot: nvidia-graphics-drivers is an SRU without a bug link, can you please reupload with a bug link?
<pitti> tseliot: or to oneiric final? (we need to respin anyway)
<pitti> tseliot: but even then a bug would be appreciated, it's quite a complex change
<tseliot> pitti: ah, if you need to respin, I'd prefer oneiric final. I'll also add a reference to bug #854967
<ubottu> Launchpad bug 854967 in nvidia-graphics-drivers-updates (Ubuntu) "boot to rescue mode in Oneiric" [High,Triaged] https://launchpad.net/bugs/854967
<pitti> tseliot: thanks
<tseliot> pitti: please reject both fglrx-installer and nvidia-graphics-drivers
<pitti> tseliot: want to reupload fglrx-installer to final as well?
<pitti> tseliot: ack, done
<tseliot> pitti: yes, sure
<pitti> tseliot: fglrx-updates has a copy-paste error in changelog ("nouveau"), but the actual debian/rules seems fine
<pitti> tseliot: in case you want to fix on reupload
<pitti> (of fglrx)
<tseliot> pitti: sure, I can fix that one too if you reject it
<pitti> tseliot: nah, accepted
<tseliot> pitti: ok
<tseliot> pitti: I've just re-uploaded both nvidia-graphics-drivers and fglrx-installer
<pitti> tseliot: cheers
<tseliot> pitti: thanks for your help
<pitti> tseliot: hm, bug 854967 has tasks for all the other versions, too
<ubottu> Launchpad bug 854967 in nvidia-graphics-drivers-updates (Ubuntu) "boot to rescue mode in Oneiric" [High,Triaged] https://launchpad.net/bugs/854967
<tseliot> pitti: there were two bug reports which overlapped a bit. I fixed both
<pitti> tseliot: ah, so you need to manually close out the other tasks
<tseliot> pitti: right
<jdstrand> pitti: fyi, filed bug #871943 in case you are curious
<ubottu> Launchpad bug 871943 in pam (Ubuntu) "pam_motd somtimes inherits umask of user (via pam_umask)" [Undecided,New] https://launchpad.net/bugs/871943
<jdstrand> pitti: I should have said 'fyi (in case you're curious): file bug 871943'
<jdstrand> meh
<jdstrand> filed
<jdstrand> I can't type. Hopefully the bug is worded better :)
<jhunt> jdstrand: upstart isn't pam-aware (yet :)
<jdstrand> jhunt: yeah, took me a bit, but I got to the bottom of it (bug 871943). thanks!
<ubottu> Launchpad bug 871943 in pam (Ubuntu) "pam_motd somtimes inherits umask of user (via pam_umask)" [Undecided,New] https://launchpad.net/bugs/871943
<bdmurray> stgraber: should bug 813065 not be set to Fix Released based on comment #9?
<ubottu> Launchpad bug 813065 in ubiquity (Ubuntu Oneiric) "Live session switches to VT console briefly" [High,Fix released] https://launchpad.net/bugs/813065
<sivang> hi all
<sivang> i know this is not a devel question, but perhaps there are ubuntu devs who know me who could let me surf their couches around the dates of Nokia world (22oct 24, 27 to 31st oct) ? :)
<sivang> in London or area
<jdstrand> pitti: sorry to bother you again, but I added a comment to https://blueprints.launchpad.net/ubuntu/+spec/umask-to-0002. I feel like there is a bug here, but I'm not sure where
<jdstrand> pitti: I noticed that /etc/dpkg/origins/* were group writable with 6.4ubuntu4, but not 6.4ubuntu5. I tracked this down to dpkg-source -x applying a umask, which is different for various developers. eg, mvo apparently is using 0002, but cjwatson 0022
<micahg> natty vs oneiric dev machine?
<jdstrand> of course dpkg-source clearly says it will do that, but the changed default umask in the distro is changing permissions for installed packages
<jdstrand> micahg: doubtful-- I would think cjwatson is using oneiric
<jdstrand> one could argue it is a packaging bug if it doesn't set the permissions correctly, and that is true, but I worry that this could result in security issues (eg, something that should have group read only, but all of a sudden gets group write)
<cjwatson> I'm using oneiric but I have an explicit umask 022 in .bash_profile for some reason
<cjwatson> base-files is probably unusual here since it doesn't use debhelper - it should set the right perms explicitly
<cjwatson> practically everything else uses dh_fixperems
<cjwatson> -e
<pitti> jdstrand: I guess dh_fixperms might not change the permissions of conffiles?
<cjwatson> irrelevant since base-files doesn't use it
<pitti> ah
<jdstrand> tbh, I forgot about dh_fixperms in my worrying
<jdstrand> :)
<cjwatson> bootstrapping reasons I think
<pitti> jdstrand: this particular case shoudl be harmless as it's group root, right?
<jdstrand> pitti: so far, yes
<cjwatson> and the current state is what we want too
<jdstrand> cjwatson: 'current state' -- you mean whatever we have in the directory?
<jdstrand> oh, current state of ubuntu5?
<cjwatson> I mean 6.4ubuntu5 is the current version and has mode 0644 which is what we want, so it's not RC
<jdstrand> yes, agreed
<cjwatson> but we should definitely fix debian/rules to be explicit here
<jdstrand> ok, I'll file a bug
<cjwatson> I suggest filing a precise alpha-1 bug?
<cjwatson> yeah
<cjwatson> um, how are you getting non-group-writable in 6.4ubuntu5?
<cjwatson> lp_archive@cocoplum:~$ dpkg -c ubuntu/pool/main/b/base-files/base-files_6.4ubuntu5_i386.deb | grep origins/u
<cjwatson> -rw-rw-r-- root/root       114 2011-07-08 17:13 ./etc/dpkg/origins/ubuntu
<cjwatson> (still, not RC since it's group root, as pitti says)
<jdstrand> I looked at my own system compared to a VM with ubuntu4
<jdstrand> then I looked at the tar.gz of each and noticed the disparity
<cjwatson> perhaps the permissions aren't changed on upgrade; that wouldn't surprise me
<jdstrand> no
<jdstrand> ar x ... ; tar -ztvf ./data.tar.gz shows they are group writable
<jdstrand> so I guess it is happening on the buildd
<jdstrand> fyi, filed 871977
<jdstrand> ok, I updated my comment in the bp
<Laney> stgraber: ping to publish package set script somewhere
<stgraber> Laney: yep, just read the backlog of the DMB meeting
<Laney> just getting my actions out of the way :P
<stgraber> Laney: I pushed it at https://code.launchpad.net/~developer-membership-board/+junk/packageset-report/ last week
<Laney> awesome!
<jdstrand> while most use dh_fixperms, some subset will use 'dh_fixperms -Xfoo' resulting in bug #872000
<ubottu> Launchpad bug 872000 in apache2 (Ubuntu) "/etc/apache2/mods-available/suexec.load has group read" [Undecided,New] https://launchpad.net/bugs/872000
<jdstrand> still not security relevant, but not desirable either
<SpamapS> is there an easy way to have sbuild add extra deps to a chroot before resolving build deps?
<broder> SpamapS: i've done it with --chroot-setup-commands "dpkg --force-depends -i /path/to/*.deb" --chroot-setup-commands "apt-get install -f -y"
<broder> it wasn't pretty
<broder> i think RAOF said he had a script to do it also
<broder> the better approach would probably be to use apt-ftparchive to build a temporary repo and use --chroot-setup-commands to add it to the sources.list
<SpamapS> its a pain when trying to prepare an upload to a PPA with a lot of extra build deps
<broder> SpamapS: i went and checked debbugs to see if someone had requested this already, but was too irresponsible to actually file a bug about it, so that might be a good thing to do
<broder> rleigh is generally awesome and responsive, though wishlist bugs probably get less love
<RAOF> SpamapS: You mean add an extra, possibly local, repository of build-deps?
<bdrung> Laney: http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info.git
<bdrung> tumbleweed, Laney: i pushed the haskell rewrite
<Laney> what brought this about?
<bdrung> tumbleweed: the short and long description needs to be updated
<Laney> night
<bdrung> Laney: it's faster than the python version (~ six times)
<RAOF> SpamapS: http://paste.ubuntu.com/705623/ is what I use, along with /etc/schroot/local-packages/fstab: http://paste.ubuntu.com/705622/ and /etc/schroot/local-packages/config: http://paste.ubuntu.com/705621/
<SpamapS> RAOF: thanks, that at least confirms for me that this is really hard. ;)
<RAOF> Heh.
<RAOF> Once you've dumped those in, though, it's easy to create a chroot conf like http://paste.ubuntu.com/705628/ :)
<bdrung> tumbleweed: besides the description update, is there something that needs to be done before release d-i 0.3?
<slangasek> SpamapS: "covered by clouds" - hah!
<SpamapS> slangasek: I qualified it. :)
<slangasek> SpamapS: oh, that was a "hah" of amusement at the analogy, if that wasn't clear :)
<SpamapS> slangasek: right, I was thinking it was a hah! of "fat chance".. ty either way, for reading.
<ScottK> zul: I think your xen upload needs to go to -proposed and not -release.
 * ScottK rejects.   Please reupload.
<zul> ScottK: how come?
<ScottK> Because everything is pretty locked down for the release right now.
<ScottK> In Main I don't think we're accepting anything not worth holding the release for.
<zul> ScottK: k
#ubuntu-devel 2011-10-11
<mdeslaur> infinity, slangasek: I've put some test packages that enable amd64 flash here, and would really appreciate your invaluable comments, especially for the oneiric version : https://launchpad.net/~mdeslaur/+archive/64bitflash
<pitti> Good morning
<ajmitch> morning pitti
<pitti> ev: congrats, bcmwl wifi is now rather painless indeed!
<pitti> ev: seems it's one tiny step away from perfection :) (bug 872119)
<ubottu> Launchpad bug 872119 in ubiquity (Ubuntu) ""Error occurred while copying the network settings" on bcmwl machine" [Undecided,New] https://launchpad.net/bugs/872119
<micahg> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<dholbach> good morning
<ev> pitti: argh. that one is entirely my fault and will take all of two seconds to fix
<pitti> ev: not a dealbreaker; it makes it a whole lot more easy to use broadcom cards :)
<pitti> ev: does that only affect bcmwl, or other wifi (such as intel), too?
<ev> pitti: the copying of network-manager's brain to the installed system is broken, so it'll affect any card
<ev> so the user will have to re-enter their wifi password
<ev> and they'll all see that error dialog
<pitti> ev: that more or less just copies /etc/NetworkManager/system-connections/*, or is there more to it?
<ev> pitti: correct
<micahg> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ev> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
<tumbleweed> can someone in ubuntu-branches please reject https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107
<tumbleweed> and mark https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-sru/+merge/72410 as merged (or whatever we do for SRUs targetted at the release branch)
<tumbleweed> https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/75850 is also uploaded
<tumbleweed> https://code.launchpad.net/~rye/ubuntu/natty/bindwood/update-firefox-6-compat-fix/+merge/76055 appears to be rejected
<doko> Laney, did you sort out the cairo-dock debian/upstream miscommunication?
<tumbleweed> cjwatson / james_w: two more to mark Merged: https://code.launchpad.net/~brunoqc/ubuntu/natty/lfm/lfm-fix-786491/+merge/77859 https://code.launchpad.net/~jtaylor/ubuntu/natty/singularity/fix-576504/+merge/78286
<tumbleweed> that's it
<Laney> doko: no, we should get on that as well
<pitti> tumbleweed: done all but the bindwood one; what's with that one?
<tumbleweed> pitti: I guess micahg is the pbest person to answer that one, but I'm assuming the fix is going into a different sourcepackage...
<slangasek> jamespage: before setting plymouth:debug, were you able to reproduce bug #849414 consistently?
<ubottu> Launchpad bug 849414 in plymouth (Ubuntu Precise) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Incomplete] https://launchpad.net/bugs/849414
<jamespage> slangasek: I was able to; however I appear to have stopped hitting that issue
<slangasek> jamespage: so reverting plymouth:debug doesn't cause it to reappear either? :(
<jamespage> slangasek, I running with it off now with no issues
<jamespage> slangasek, so I was thinking about what had changed; I was getting an ugly text based splash when I saw the issue
<slangasek> ah
<jamespage> setting debug turned that off - and the issue went away
<slangasek> that's helpful info :)
<slangasek> right, I don't think setting debug turned it off, I think something else I did turned it off :)
<slangasek> and your debug change just happened to coincide with other initramfs fixes
<jamespage> slangasek, quite possibly
<slangasek> jamespage: you could try re-breaking the graphics display by removing the plymouth-theme-ubuntu-logo package
<jamespage> slangasek, sure - give me a couple of minutes
<jamespage> slangasek, do you want me to turn debug on as well?
<slangasek> jamespage: I'd try first without turning on debug (in case it's timing-sensitive), then if that reproduces the issue, turn on debug
<jamespage> slangasek, ack
<jamespage> slangasek, hmm - not able to reproduce
<slangasek> jamespage: and it was 100% reproducible before?
<jamespage> slangasek, yes - I turned debug mode on an off and the came and went
<slangasek> jamespage: can I get apt logs, plus a big "here's where I turned on debugging" arrow, to try to work out what else changed on your system?
<slangasek> jamespage: also, what's your video?
<jamespage> slangasek, video is ATI Mobility Radeon HD 5400 Series
<slangasek> jamespage: binary video drivers?
<jamespage> slangasek, digging logs now
<jamespage> slangasek, not sure whether its relevant but when I got the issues I had a really low res text based splash as well
<jamespage> when I just tested it was much higher res
<jamespage> slangasek, http://paste.ubuntu.com/706151/
<jamespage> slangasek, I think I first saw this issue on the 04/11 (indeed that is the date of the crash file that jhunt and I looked at earlier)
<jamespage> I turned debug mode on then  - and did a few reboots and could not reproduce
<slangasek> oh heh
<slangasek> higher res> so you've got vesafb loading and a framebuffer console, that's going to change things for sure
<jamespage> slangasek, thats what I figured
<slangasek> jamespage: this is with the cryptsetup package installed, right?
<jamespage> slangasek, no
<slangasek> hmm
<slangasek> not sure why you would have gotten plymouth text without vesafb in that case
<slangasek> are you using binary drivers?
<jamespage> slangasek, yes
<jamespage> slangasek, just to prove it - https://launchpadlibrarian.net/81898994/firegl-crash.jpg
<slangasek> :-)
<jamespage> thats from a diff bug
<jamespage> looking at what i wrote on bug 865984
<ubottu> Launchpad bug 865984 in Ubuntu "firegl_sig_notifier crash on shutdown or reboot" [Undecided,New] https://launchpad.net/bugs/865984
<hallyn_> slangasek: if you get a moment, can smoser and I ping you about a glibc bug and the likelyhood of it being considered fixable by upstream?
<jamespage> I appear to have had a vesafb/framebuffer console until shortly before the 04/11
<jamespage> I raised that bug the same day I did the plymouth debug stuff
<slangasek> hallyn_: just ask directly please :-)
<cnd> seb128, is there still time to get the libgrip fix into oneiric? or should it be an sru?
<seb128> cnd, sru
<cnd> ok
<seb128> cnd, which is fine we already got a stack of srus uploaded
<seb128> including compiz
<cnd> ok
<cnd> I'll prepare an sru upload then
<pitti> Laney: wow, I wouldn't have expected breezy to top the upload score -- we had way fewer devs back then
<pitti> Laney: well, maybe we uploaded 25 sets of langpacks :)
<Laney> yeah, not sure what that is about
<Laney> let me do the last query but s/oneiric/breezy/
<pitti> actually, it would be interesting to filter out all language-pack-* stuff
<Laney> the data is all in udd ;-)
<tseliot> slangasek: I'm seeing a lot of complaints on arm from apps such as gconf and metacity looking for gconfd-2 in /usr/lib/i386-linux-gnu/libgconf2-4/ instead of using /usr/lib/arm-linux-gnueabi/libgconf2-4/. There must be something wrong with my multi-arch setup here. Any ideas? (not a symlink works around the problem)
<hallyn_> mdeslaur: Bug 871847, I assume needs to wait for an SRU at this point?  :)
<ubottu> Launchpad bug 871847 in virt-viewer (Ubuntu) "Bad port '0' upon connect qemu+ssh" [High,Confirmed] https://launchpad.net/bugs/871847
<hallyn_> slangasek: ok, i'm about to be afk for a few mins, but the problem basically is that grantpt in glibc starts out with a check for whether /dev/pts/{ptnum} is a valid slave.  WIth /dev/pts being hardcoded.  So if you call grantpt on /chroot/dev/pts/0, and /dev/pts/0 does not exist, the call will fail.
<mdeslaur> hallyn_: yep, universe just went into freeze
<hallyn_> mdeslaur: zounds!
<hallyn_> ok, thanks :)
<Laney> pitti: I don't think langpacks appear in -changes?
<pitti> Laney: they don't
<Laney> then they wouldn't be in these stats
<pitti> Laney: ah, it's based on -changes@, not soyuz
<hallyn_> slangasek: this is only a problem when using a newly cloned devpts, so i'm not sure if glibc will deem that valid?
<Laney> right
<Laney> maybe autosyncs were announced back then?
<slangasek> tseliot: uh? i386-linux-gnu vs. arm-linux-gnueabi, what's that about?  You're saying you have an arm system, with i386 packages installed?
<pitti> Laney: was just going to say :)
<hallyn_> slangasek: the workaround is doable but hacky - gotta fork, unshare a new mounts ns (with privilege), bind-mount /dev/pts, and then do the grantpt
<pitti> Laney: right, see https://lists.ubuntu.com/archives/breezy-changes/2005-April/thread.html
<bdmurray> stgraber: should bug 813065 be Fix Released - comment 9 leads me to think no
<ubottu> Launchpad bug 813065 in ubiquity (Ubuntu Oneiric) "Live session switches to VT console briefly" [High,Fix released] https://launchpad.net/bugs/813065
<slangasek> hallyn_: why do you call grantpt against a chroot?
<pitti> for the other months, too
<slangasek> I don't think I understand the problem, sorry
<Laney> let me exclude that then
<tseliot> slangasek: no, they're all for arm
<hallyn_> slangasek: libvirt's parent process sets up /dev/pts/0 in the container's rootfs as a console for 'virsh console' to connect to
<Laney> a much different picture emerges
<stgraber> bdmurray: comment #9 was before Steve sent me a merge proposal fixing it properly which got merged and uploaded (comment #10)
<hallyn_> slangasek: though in any case, since thamanpage doesn't mention anything, glibc definately is *wrong*.
<Laney> pitti: http://paste.debian.net/135733/
<slangasek> tseliot: but you said "There must be something wrong with my multi-arch setup here" - have you *done* some special multiarch setup?
<bdmurray> stgraber: okay then what is going on with bug 871936?
<ubottu> Launchpad bug 871936 in ubiquity (Ubuntu) "Live session switches to VT console [nvidia]" [Undecided,New] https://launchpad.net/bugs/871936
<pitti> Laney: still respectable, compared to warty and hoary
<hallyn_> slangasek: (but glibc might demand the manpage fix rather than the code fix :)
<Laney> it's actually remaining fairly steady
<stgraber> bdmurray: I'm not sure, maybe slangasek has an idea but AFAIK ubiquity-dm now does the right thing, it may simply be an nvidia specific flicker bug
<tseliot> slangasek: no, I did nothing at all to set up multiarch. It's just that somehow apps are looking for that path
<Laney> but oneiric moves up to fifth :-)
<slangasek> hallyn_: heh, indeed... I don't know, sorry
<hallyn_> slangasek: nm, i guess i should join the m-l rather than bug you about it :)  thanks
<slangasek> tseliot: what's the exact error message?
<tseliot> slangasek: "failed to activate configuration server: Failed to execute program /usr/lib/i386-linux-gnu/libgconf2-4/gconfd-2: Success
<bdmurray> stgraber: okay the patch didn't seem hardware specific to me
<tseliot> slangasek: this comes from gnome-settings-daemon, metacity, etc.
<stgraber> bdmurray: indeed, it fixes flickerless for any graphic card that does work correctly with flickerless
<stgraber> bdmurray: which AFAIK isn't the case of nvidia
<hallyn_> heh, i see, there really is no m-l
<slangasek> tseliot: does i386-linux-gnu show up anywhere in config files under $HOME?
<hallyn_> libc-alpha it is.  (weird name)
<seb128> slangasek, tseliot: I know what it is
<slangasek> seb128: oh?
<seb128> slangasek, well, maybe not
<seb128> slangasek, /usr/share/dbus-1/services/org.gnome.GConf.service is in gconf2-common which is arch all
<seb128> but "Exec=/usr/lib/libgconf2-4/gconfd-2" there
<slangasek> jamespage: when you said "04/11", you meant "04/10", right?
<slangasek> seb128: hmm
<jamespage> slangasek, hrm - yep
<tseliot> seb128, slangasek: but then how would it look for i386-linux-gnu ?
<seb128> tseliot, the arch all is built on i386
<seb128> so it would have the i386 path
<slangasek> tseliot: I don't know; and I've not seen such an error on amd64
<seb128> but that doesn't seem to be it
<seb128> the .service has non multiarch paths
<seb128> that was just an idea, ignore me ;-)
<tseliot> seb128, slangasek: having a hardcoded path shouldn't be too good anyway
<ogra_> slangasek, i think i saw the same issue being discussed in #linaro this weekend
<ogra_> there must be a bug open for it already
<seb128> tseliot, ogra_, slangasek: is linaro or somebody shipping a multiarched version of gconf?
<seb128> our libgconf is not on multiarch
<tseliot> that's a good question
<seb128> but it seems the service in arch all binary would lead to that question if somebody did a multiarch build without changing it to arch any
<ogra_> seb128, no idea, i think they are still working on switching their image builds to oneiric
<seb128> that's the only way I could explain it
<ogra_> (linaro is one release behind since they do monthly releases)
<seb128> question->error
<seb128> ogra_, well, we need multiarched gconf
<seb128> so that's not being "behind"
<tseliot> slangasek: and no, I can't find any references to i386 in $HOME
<slangasek> jamespage: are you sure you don't have cryptsetup installed?
<seb128> it seems somebody has a custom multiarch version of gconf
<ogra_> the error showed up for them after switching to oneiric
<slangasek> tseliot: hmm
<seb128> ogra_, can you ask them their version of gconf?
<ogra_> i didnt follow that deeply, but i know they opened a bug
<jamespage> slangasek, yes - http://paste.ubuntu.com/706181/
<slangasek> seb128: what do you mean by "multiarched gconf"?  We should only have one copy of the daemon running...
<tseliot> ogra_: right, I can only reproduce the problem in oneiric
<seb128> slangasek, the service is dbus activated, if the path was multiarch specific but they have a .service in arch:all that would lead to such issues
<slangasek> ok
<seb128> slangasek, dbus would be trying to spawn the i386 location
<slangasek> right; so when multiarching gconf, the daemon should be split out of the library package...
<seb128> or the .service should be in an arch:all binary
<seb128> so it gets the right location for each arch
<tseliot> the latter sounds easier
<seb128> slangasek, the daemon is already splitted out of the library
<seb128> the issue is that the dbus service which has the service location is in gconf2-common arch:all
<seb128> we should just move the .service with the daemon when we multiarch it
<seb128> well, that's just guess work on what their issue is, but "/usr/lib/i386-linux-gnu/libgconf2-4/" doesn't make sense if gconf has not been changed for multiarch
<seb128> so I guess somebody did that work in a ppa or something
<seb128> ogra_, tseliot, slangasek:
<seb128> https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09
<seb128> "Convert to multiarch, gconf: DONE"
<seb128> so yeah, "linaro bug" I guess
<ogra_> seb128, i dont see that bug here and have no issues
<ogra_> i just saw it being discussed by the linaro gusy
<seb128> ogra_, well that didn't land in Ubuntu for sure
<ogra_> *guys
<seb128> ogra_, their workitem is DONE so I guess they have their own version somewhere
<seb128> in any case not an Oneiric issue ;-)
<ogra_> oh, its a linaro spec
 * ogra_ missed that
<ogra_> there it is
<ogra_> bug 871892
<ubottu> Launchpad bug 871892 in Linaro "org.gnome.GConf.service contains i386 pathname" [Undecided,New] https://launchpad.net/bugs/871892
<tseliot> ogra_, seb128, slangasek: that's the exact bug that I'm seeing here
<seb128> tseliot, what do you use? linaro or Ubuntu?
<ogra_> it was actually discussed yesterday ...
<tseliot> seb128: ubuntu
<seb128> tseliot, dpkg -l | grep gconf
<ogra_> seb128, linaro builds their oneiric images from our archive plain, no additions but HW bits yet
<ogra_> they only start to work on oneiric this week
<seb128> ogra_, that doesn't make sense, gconf is not multiarch in Ubuntu, if it was I would knew it
<ogra_> seb128, right
<tseliot> seb128: it doesn't seem to return anything
<seb128> tseliot, you don't have gconf installed? how did you do your install?
<ogra_> seb128, i dont kno wabout multiarch, what i know is that linaro only starts working on a release once ubuntu released it
<seb128> we still have a stack of things in the default install using it
<ogra_> so atm what they use should be plain ubuntu
<ogra_> since they only switched image builds to oneiric this week
<seb128> ogra_, well with their own layer or ppa on top I guess
<ogra_> for kernel and bootloaders,. yep
<seb128> ogra_, seeing  https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09 they need multiarch conversions over what oneiric has
<ogra_> but no desktop bits yet
<ogra_> right, that might be, i can only comment on what i observed ... i dont work in linaro :)
<tseliot> seb128: apt-cache show gconf shows the installed size among other things
<tseliot> seb128: err... gconf2
<seb128> tseliot, how did you do your install? it's puzzling that you don't have gconf installed... are you sure you didn't type dpkg -l | grep gconf?
<seb128> type->typo
<tseliot> seb128: yes, I typed it 3 times. I used our installer (which is probably the same as linaro)
<ogra_> no
<ogra_> linaro doesnt use any installer, they just install a metapackage in a chroot and tar that up
<tseliot> ogra_: we're doing something similar, through the usual live-helper though
<ogra_> well, ubuntu installs tasks etc ... might get you minimally different results
<seb128> slangasek, just for the record it's indeed a linaro ppa with a multiarched version which has the .service in the arch all binary
<seb128> slangasek, i.e not an Ubuntu bug (tseliot get the issue on a custom build, not on an Ubuntu install)
 * tseliot nods
<slangasek> seb128: ah, heh
<slangasek> jamespage: did you for any reason set FRAMEBUFFER=y manually in your initramfs config?
<jamespage> slangasek: no - I've not touched it
<slangasek> jamespage: mmk
<stgraber> SpamapS: I just posted the generate /etc/network/interfaces to bug 870214
<ubottu> Launchpad bug 870214 in open-iscsi (Ubuntu Oneiric) "iSCSI root installation creates manual eth0 configuration + long boot" [High,New] https://launchpad.net/bugs/870214
<stgraber> SpamapS: is it normal that the boot waits for 2 minutes with a /etc/network/interfaces like this one?
<slangasek> jamespage: oh - could you try setting 'gfxpayload=text' manually in your /boot/grub/grub.cfg, instead of the default gfxpayload=$linux_gfx_mode?
<jamespage> slangasek: OK
<SpamapS> stgraber: it is normal that it would be waited on if eth0 doesn't exist
<SpamapS> stgraber: since we're waiting for the full configuration of eth0. While its waiting, has eth0 been initialized by the kernel?
<stgraber> SpamapS: hmm, I don't know for jamespage's setup, but I'm pretty sure eth0 existed in his case
<stgraber> SpamapS: it's netboot with root on iscsi, so yes eth0 is initialized by ipconfig in the initramfs
<SpamapS> Hm, so is it possible that we never get an 'ifup eth0' for that?
<SpamapS> I would have thought 'ifup -a' would catch it in /etc/init/networking.conf
<stgraber> sadly my test environment here lets me install over iscsi but not boot from it (I'm missing my usual PXE server ;))
<stgraber> oh, actually I guess I can extract the kernel and initrd and have kvm boot that directly
<jamespage> stgraber, SpamapS: I still have one of the test images locally if you want me to poke it in any way
<slangasek> SpamapS, stgraber: there should still be a network-device-add event which should still cause upstart to trigger an 'ifup eth0' - but what happens if you run 'ifup eth0' for this?
<SpamapS> I'd guess then that the problem is ifup -a doesn't, for whatever reason, see eth0 as needing to come up.. and so doesn't execute the if-up.d jobs.
<slangasek> it's not even an ifup -a
<slangasek> it's /etc/init/network-interface.conf
<SpamapS> Oh so you still get the network-device-added ?
<slangasek> of course
<slangasek> that comes from udev from coldplugging
<SpamapS> well then wtf :)
<SpamapS> is it possible thats happening before virtual-filesystems ?
<slangasek> no
<SpamapS> ah right, udev starts on virtual filesystems
<stgraber> jamespage: is commented the two lines for eth0 in /etc/network/interfaces fixing the issue for you?
<stgraber> (looking for a workaround)
<jamespage> stgraber: rings a bell - lemme try
<stgraber> slangasek, SpamapS, jamespage: Current discussion here (with Daviey) is that we could probably just release note the workaround for now, then SRU a fix if that doesn't involve changing /etc/network/interfaces, otherwise just have it fixed for P
<stgraber> assuming commenting these lines workarounds the issue for jamespage
<jamespage> stgraber: I don't think that its an issue thats going to impact alot of people so thats prob fine
<jamespage> slangasek, just tried gfxpayload=text == no seg fault
<stgraber> jamespage: yeah, it's also a case where if you boot a server, you'll already wait 5 minutes for your BIOS, waiting 2 minutes for your first boot shouldn't be too bad (assuming you know the workaround and apply it then)
<slangasek> jamespage: did you get the 640x480 text again?
<jamespage> slangasek, I think so - ssd so boots fast - lemme double check
<jamespage> stgraber: commenting the entries in /etc/network/interfaces works around the issue for me
<stgraber> SpamapS: ok, so we at least have a workaround
<slangasek> stgraber: why do we want this 'manual' entry in /e/n/i?
<stgraber> slangasek: I can't think of a good reason for that, though I still think "inet manual" should work as it's valid syntax
<slangasek> should work, but it's meant for interfaces where you're going to actually *do* something via up/down rules
<slangasek> AFAICS this is a misuse of it; so if we can fix the bug by dropping that generated entry...
<jamespage> slangasek: double checked - did boot in 640x480 text mode
<slangasek> jamespage: and still no crash?  Great, I'll mark the bug as fixed ;P
<jamespage> slangasek: no crash
<stgraber> slangasek: well, then I'll be happy to file another bug when I upgrade my servers where I have "inet manual" with a post-up and pre-down entry
<stgraber> as they'll be affected by the same bug with a config that actually does something
<slangasek> stgraber: or open an ifupdown task to go with the open-iscsi one
<slangasek> and we can fix open-iscsi pre-release, and fix ifupdown post-release
<SpamapS> slangasek: agreed on that, an empty manual entry is a place holder we don't need
<SpamapS> Could it be that ifupdown agrees, and ignores it?
<slangasek> dunno, testing
<andreasn> jcastro, ping
<jcastro> andreasn: hi
<slangasek> SpamapS: I do see if-up.d scripts being run for my ifup of a manual interface, anyway
<slangasek> SpamapS: and 'ifup foo' gets me a static-network-up event, so... dunno
<slangasek> stgraber: ^^
<SpamapS> what about the upstart udev bridge
<slangasek> stgraber: I'd suggest throwing some debugging into /etc/network/if-up.d/upstart to dump to a per-interface log file and see what's going on
<SpamapS> is it racing with udev ?
<SpamapS> like..
<SpamapS> it starts on starting udev ..
<stgraber> jamespage: can you try that ^
<SpamapS> but does it return before its actually bridging?
<slangasek> SpamapS: no, it always starts *before* udev and sits waiting on the netlink socket
<slangasek> er
<slangasek> SpamapS: I hope not :P  I guess I can look
 * SpamapS peeks at it too
<stgraber> slangasek: still working on getting my laptop back into a usable stage (for some reason my last reboot broke something) and then I'll try to get a complete iscsi setup for testing
<slangasek> stgraber: ok :)
<SpamapS> slangasek: no, as I would have expected, it adds the udev monitor before daemonizing
<slangasek> SpamapS: right - I think we would be hearing about more things broken than just this, otherwise :)
<SpamapS> if booting with --verbose , do we see the network-device-added event ?
<slangasek> stgraber, SpamapS: I've changed my mind; there are legitimate corner case reasons why we want the entry for the interface... so network-manager doesn't even try to touch it :P
<slangasek> stgraber: so I don't think we should change open-iscsi for release, but instead just SRU ifupdown (once we figure out what the problem is!)
<stgraber> slangasek: sounds good. I'll mark the bug as invalid for open-iscsi, we already have a task for ifupdown and the release notes
<hallyn_> smoser: I emailed the glibc-alpha m-l about the grantpt issue.  We'll see what they say
<jamespage> stgraber, I logged some debug output with the manual entry in /e/n/i present and commented - neither generates any log data for eth0 from  /etc/network/if-up.d/upstart
<hallyn_> (I'm expecting a spanking, tbh, but hopefully not)
<jamespage> only get a file for lo
<stgraber> SpamapS: ^
<smoser> hallyn_, link ?
<hallyn_> smoser: http://www.cygwin.com/ml/libc-alpha/2011-10/msg00008.html
<SpamapS> jamespage: can you boot with --verbose and look in /var/log/boot.log for the net-device-added event ?
<jamespage> SpamapS, sure
<slangasek> stgraber, jamespage, SpamapS: I notice that open-iscsi installs an if-up.d hook of its own
<slangasek> which sorts lexically before upstart
<slangasek> I wonder if it's broken?
<SpamapS> the lo hook fired...
<slangasek> well, the hook special-cases lo ;)
<stgraber> slangasek: oh, actually, the upstart script shipped by open-iscsi looks like it could break the boot
<slangasek> oh excellent
<slangasek> Oh dear
<stgraber> I didn't even notice that thing before but that can explain a lot of things ;)
<stgraber> http://paste.ubuntu.com/706245/
<stgraber> I'm guessing that as the interface is already in /run/network/ifstate, it's going to be entirely ignored by ifupdown and so we won't get the event...
<slangasek> yes, it forcibly bypasses if-up.d, it writes to /run/network/ifstate without locking, and it fails to use a proper 'instance' declaration for network-interface
<stgraber> I'm wondering if just removing it would be enough
<slangasek> stgraber: so it looks like an open-iscsi-specific failure after all
<stgraber> jamespage: can you try that? ^
<jamespage> stgraber: just doing the verbose boot - one second
<slangasek> cjwatson: you seem to have written /etc/init/iscsi-network-interface.conf; do you recall why you were trying to prevent /etc/network/if-up.d scripts from being run for an iscsi interface?
<stgraber> slangasek: we are going for dinner now, if it's confirmed that it works fine without the upstart job, I'll just remove it and upload to -proposed
<slangasek> bug #457767
<ubottu> Launchpad bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released] https://launchpad.net/bugs/457767
<slangasek> stgraber: enjoy :)
<SpamapS> slangasek: I would concurr with stgraber's assessment, this script does look like its our culprit.
<SpamapS> slangasek: or, your assessment, somebody's
<slangasek> SpamapS: yep - question is how we fix it... we shouldn't just drop it without taking care on upgrade to make sure users don't have configuration for the interface in /etc/network/interfaces that's going to cause the system to blow up on next boot
<SpamapS> yeah this bug-ectomy requires some delicate scalpel work
<SpamapS> I'm not sure why the author wanted to avoid the *.d scripts
<slangasek> "the author" being cjwatson
<SpamapS> ok, so we can ask him. :)
<SpamapS> because that is precisely the issue we have, is that they were avoided
<slangasek> yep
<jamespage> SpamapS, stgraber, slangasek: --verbose boot - http://paste.ubuntu.com/706249/
<slangasek> jamespage: yep, that's consistent with our theory.  kill /etc/init/iscsi* and try again?
<jamespage> slangasek, appears to be much happier
<jamespage> stgraber: ^^
<jamespage> no network failsafe and I can see log data for eth0 as well as lo
<slangasek> jamespage: thanks; can you send that info to the bug?
<jamespage> slangasek, done
<slangasek> jamespage: cheers :)
<jamespage> np
<SpamapS> slangasek: I don't see anything in the default server install that would be "bad" during if-up.. I was thinking though, don't we need to make sure eth0 is never brought down?
<slangasek> SpamapS: certainly
<SpamapS> I don't think it will be brought down but wondering if maybe some scripts down/up the interface.
<slangasek> nothing should for interfaces not explicitly configured to have such things done
<slangasek> (e.g., bridge interfaces)
<SpamapS> just trying to reason why we'd want to avoid those scripts
<SpamapS> a lot of them make some pretty strong assumptions
<SpamapS> though one might be able to argue that most iSCSI root boxes don't share the iscsi interface with the general network connection... it should still be possible
<slangasek> well, as cjwatson admits in his comment, this is a layering violation... and now it's biting us :)
<slangasek> jamespage: I've struck out as far as finding anything in your apt log that will explain it; the only relevant change I see is fglrx, and the only effect that had should have been reproducible with the gfxpayload change.  Could you try downgrading fglrx to version 2:8.881-0ubuntu3, to see if it does bring back the segfault?
<hallyn_> smoser: do you mind if i fwd your testcase for the libvirt pty probelm to the m-l?
<smoser> oh sure, they'll have a field day.
<smoser> :)
<hallyn_> do you have your latest version somewhere?
<hallyn_> otherwise i can just use the first version, that's fine.
<smoser> i ended up trashing the instance that had your iprovements
<smoser> https://gist.github.com/1251979 is where ih ad what i had.
<hallyn_> smoser: thanks much
<micahg> pitti: what was the question for me, I seem to have missed it?
<micahg> pitti: it seems that librpc-xml-perl was demoted prematurely
<micahg> pitti: oh, nevermind..
<micahg> cjwatson: when we merge dpkg for P, are we going to get the hardening flags emitted like Debian is doing?
<cjwatson> slangasek,SpamapS,stgraber: all I can really say from this vantage is that it caused a problem at the time, as noted in the comment in the script; I'm having trouble parsing my comment about /etc/network/*.d/ scripts, so it's entirely possible I was just confused
<cjwatson> micahg: I intend to keep the flags in the environment for precise, because otherwise we'll have to convert too many packages to avoid lossage
<micahg> cjwatson: i.e. different behavior than Debian?
<cjwatson> micahg: for P, yes
<cjwatson> although packages that have been converted to the new scheme in Debian shouldn't break; at worst, they'll have the flags specified twice
<micahg> cjwatson: is this for stuff we already have in our environment or everything?  My concern is that Debian is starting to abandon hardening-wrapper usage and starting to use the dpkg buildflags
<cjwatson> micahg: packages that ask for dpkg-buildflags output will get it, don't worry
<micahg> cjwatson: awesome, thanks :)
<cjwatson> I'm just not going to remove stuff that wew already have in our environment
<cjwatson> not until Q
<micahg> yeah, that makes sense for an LTS
<cjwatson> stgraber: it's possible I regarded manual as a hack and didn't want to depend on it
<cjwatson> but I don't appear to have recorded my thought process very clearly, sorry
<micahg> cjwatson: maybe we should just leave it in the env unless it'll break stuff, ideally we do want hardening by default (but we can save that discussion for UDS Q :))
<cjwatson> stgraber: I am a little concerned that there may be upgraded systems around that don't use the manual method
<cjwatson> micahg: the things in the environment at the moment aren't hardening
<micahg> ah
<cjwatson> they're default optimisation settings and -Wl,-Bsymbolic-functions
<cjwatson> we want to migrate to dpkg-buildflags in the long term because it offers more flexibility
<cjwatson> for example it will make it easier to test-build the world with different compiler flags without having to use a compiler wrapper
<SpamapS> cjwatson: its probably worth a review of the other methods and if-up.d scripts to see if they do anything we might perceive as dangerous to an iSCSI root.. if we can't find anything.. maybe just axe the upstart job.
<cjwatson> actually
<cjwatson> so the problem was that if you did an install with the installer acquiring its network settings by DHCP, before my hack in partman-iscsi, it got 'iface eth0 inet dhcp'
<cjwatson> then when you did 'ifup eth0', it ran dhclient, which tore the interface down and set it back up again
<cjwatson> and the world imploded
<cjwatson> I think you should ignore my comment about .d scripts, it seems to be a red herring
<kees> micahg: yeah, the trick is watching for packages that convert from hardening-wrapper/-includes to dpkg-buildflags to make sure they include +pie,+bindnow
<cjwatson> so what this upstart job does is force ifup to do nothing for that interface, even if /etc/network/interfaces is misconfigured
<cjwatson> removing that *might* be safe, but I would prefer to have say an 'ifpretendup' interface in ifupdown
<cjwatson> or 'ifup --pretend' or whatever
<micahg> kees: right, that's what I was asking about in my meek way :)
<cjwatson> which would force the interface to be considered up (in ifstate) but not actually do any work
<cjwatson> then we could use that in the upstart job (and fix the instance bug) and it would then be able to emit the right upstart event
<cjwatson> although a temporary hack that might do the job for now would be to emit that event by hand
<cjwatson> not the right fix but it would kill the delay
<cjwatson> and should be no worse than what was there before
<kees> micahg: I'd like to figure out some way to do build regression testing in Debian and Ubuntu that would alert when a package suddely stopped building with a flag or something, but it's seriously non-trivial to get right
 * jdstrand waves to kees
<kees> hi jdstrand! :)
<micahg> kees: emit the build flags at build time, then have LP parse the logs and fail if there's a regression?
<jdstrand> :)
<kees> micahg: yeah, but right now the bulk of that isn't visible in ubuntu's builds since we enforce it in the compiler without flags
<ajmitch> you'd want to build the same source both with & without flags to narrow the cause of build failures down
<stgraber> cjwatson: http://paste.ubuntu.com/706334/ for the workaround?
<slangasek> stgraber: that doesn't solve the issue.  If we're going to try to use this as a workaround, we ought ta have this job just call /etc/network/if-up.d/upstart with the right args
<slangasek> (net-device-up is not the event we care about, it's static-networking-up)
<hallyn_> smoser: well...  resposne was not unexpected but still unfortunate :)   pls let me know if my patched libvirt worked for you
<cjwatson> yeah, may as well not add *more* layering violations I guess
<cjwatson> does my proposed interface extension to ifup sound reasonable longer-term though?
<cjwatson> (static-network-up not static-networking-up ...)
<slangasek> cjwatson: what does "pretend" give you that just getting the interface properly set as "manual" would not?
<slangasek> because the upstart hook may not be the only one we care about running
<slangasek> I dunno, would we want avahi-autoipd to run?
<cjwatson> may be misnamed, what I want it to do is not actually do the main body of manipulating the interface
<cjwatson> I'm happy for it to run all the hook scripts
<cjwatson> (as I say I think my two-year-old comment was misleading)
<slangasek> well, perhaps not unless we FIX that hook.. again... since it's adding a stupid route instead of bringing up an address
<stgraber> cjwatson, slangasek: http://paste.ubuntu.com/706338/
<cjwatson> useless use of env :-)
<stgraber> oh, indeed ;)
<slangasek> :)
<slangasek> otherwise, provided that works I think it looks good
<cjwatson> do we need to handle ipv6?
<cjwatson> appreciating the irony of me asking stgraber this
<slangasek> :-)
<slangasek> the hook doesn't distinguish by addrfam
<cjwatson> I'm guessing open-iscsi is far too stupid to handle ipv6
<stgraber> haven't seen any hardware doing IPv6 PXE yet
 * ajmitch didn't think PXE was specced yet for ipv6
<cjwatson> it is
<cjwatson> well, ish
<ajmitch> oh? that's useful
<cjwatson> it is in uefi, I'm not sure about bios
<cjwatson> although only a uefi version nobody has yet
<cjwatson> so still chocolate teapot level of usefulness
<stgraber> jamespage: still around?
<slangasek> regardless, the upstart hook fires once for each interface and doesn't care about address family; no point trying to make the open-iscsi job fancy
<jamespage> stgraber, yep - running iscsi root tests :-)
<stgraber> jamespage: awesome. Can you move the upstart script back into /etc/init, revert the changes to /etc/network/interfaces (so we have the inet manual in there) and apply this diff: http://paste.ubuntu.com/706339/?
<jamespage> stgraber, just cooking one now - no problem
<stgraber> jamespage: then try again but with "inet dhcp" instead of "inet manual" and check that it works too and finally with the two lines commented again
<stgraber> that should cover most of the use cases ;)
<jamespage> stgraber: all three of those test cases work great with the patch applied
<jamespage> \o/
<stgraber> yeah!
<smoser> hallyn_, tested your suggested patch
<smoser> http://paste.ubuntu.com/706342/
<smoser> is what i get
<stgraber> skaet, slangasek, cjwatson: Should I push that fix to -proposed and if Daviey really wants it we copy it and rebuild server?
<smoser> you should be able to easily recreate this now that we know how to make it so that /dev/pts/0 wont be availalble.
<cjwatson> stgraber: yes please
<cjwatson> 22:26 <slangasek> stgraber: ^^ so open-iscsi to -proposed please :)
<cjwatson> (#ubuntu-release)
<bdrung_> andersk: mozilla-devscripts fixed
<ev> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<andersk> bdrung_: Alright, trying that.
<hallyn_> smoser: ok, don't know why, that's gonna be lower priority
<bdrung_> andersk: how long will your test take?
<andersk> bdrung_: Almost done, I think.
<andersk> I recompiled xul-ext-lightning after adding âBreaks: ${xpi:Breaks}â to all its debian/control stanzas, and ended up with what appears to be the right thing.
<andersk> And the result installs and works.
<bdrung_> andersk: last chance to prevent the upload of m-d 0.29
<andersk> I say ship it!  :-)
<achiang> when does DIF usually occur relative to opening the archive?
<micahg> achiang: 7-9 weeks in
<achiang> micahg: ok, thanks
<achiang> 7-9 weeks to get a new package in then. :-/
<micahg> achiang: no, you can request new stuff up to feature freeze, DIF is the automatic sync
<achiang> oh, how long is feature freeze?
<micahg> achiang: 2 months before release
<achiang> micahg: ok thanks
<micahg> achiang: the earlier the better though :)
<achiang> micahg: yes, it's a somewhat tricky package, and i'm going the debian route
<achiang> micahg: if i can't get it into debian before feature freeze, is there an ubuntu way to get it into universe?
<micahg> achiang: sure, REVU is still open for the moment
<bdrung_> but the debian way is the easier way
<achiang> bdrung_: yes, i got my package's dependency into debian just last week
<achiang> bdrung_: but that took a while. i'm concerned about this new package i'm working on
<bdrung_> achiang: what package?
<achiang> bdrung_: https://forge.betavine.net/scm/?group_id=76 -- wader-core is a drop-in, API compatible replacement for ModemManager
<achiang> bdrung_: it supports Vodafone modems really well
<Laney> you can probably ask the same sponsor to look at this one
<achiang> Laney: yes, that was my plan
<sammy> anyone using auth-update-config and authing from ldap?
<sammy> supposedly its changes to common-password in pam.d should allow using passwd to change ldap passwords. everything else is running smoothly
<sammy> nm google is my friend :)
<bdrung_> andersk: released :)
<andersk> Cool.  How are we going to handle rebuilding the extension packages against the new version?
<bdrung_> andersk: it requires manual work (adding ${xpi:Breaks})
<bdrung_> andersk: m-d will be synced to precise. for which release do you need this feature?
<andersk> bdrung_: I dunno, is oneiric likely to see Firefox 8 or Thunderbird 8 as an SRU?
<bdrung_> yes
<andersk> The status quo seems to be that a Thunderbird 8 SRU in oneiric will break Lightning, like Thunderbird 7 did during the dev cycle, and it would be nice to have the package manager detect that before it causes a real problem.
<micahg> andersk: we'll be SRUing lightning at the same time
<bdrung_> micahg: will you SRU mozilla-devscripts too?
<bdrung_> micahg: or just patch the heavy stuff in?
<micahg> bdrung_: not planning on it
<chrisccoulson> What feature in mozilla-devscripts?
<bdrung_> chrisccoulson: m-d 0.29 adds a ${xpi:Breaks}
#ubuntu-devel 2011-10-12
<TheMuso> /c/c
<twb> I'm trying to do some pinning for the first time in a few years; last time I tried it didn't work on Ubuntu because there were no release aliases (stable/testing/unstable).
<twb> But this looks like it should work, and I can't see what I'm doing wrong: http://paste.debian.net/135875/
<twb> Is there some gotcha I don't know about, like "pinning doesn't work at all in lucid" ?
<pitti> Good morning
<ScottK> Good morning.
<dholbach> good morning
<pitti> SpamapS, RAOF: did either of you accept postgresql-common into oneiric-proposed?
<pitti> someone did, but didn't run sru-accept
<pitti> anyway, running it now
<RAOF> Nope, but I guess oneiric-proposed is now open for sru business, isn't it.  Time for me to start checking that queue.
<pitti> RAOF: right, it is; we already accepted quite a number of SRUs, see the HTML report
<tseliot> cjwatson, pitti: do you know what package sets up the admin group in ubuntu?
<pitti> hm, it's not sudo
<ogra_> isnt it base-files or some such ?
<ogra_> some d-i component at least
<pitti> it's nowhere in /var/lib/dpkg/info/*.postinst, so I guess it's in the installer
<cjwatson> user-setup
<ogra_> ah
 * ogra_ knew it was something with a dash in the middle :)
<tseliot> ok, thanks everyone
<mdeslaur> pitti: the postgresql 8.4.9 update is failing to build on armel. The regression test fails horribly. Any ideas?
<mdeslaur> pitti: ie: http://paste.ubuntu.com/706647/ , http://paste.ubuntu.com/706648/
<pitti> mdeslaur: ugh, no; haven't see that one yet; that's a regression from .9, i. e. .8 worked in the same environment?
<mdeslaur> pitti: yeah, .8 compiled fine on the armel builders
<mdeslaur> pitti: unless something changed on the builders since .8 was compiled
<pitti> mdeslaur: does it affect all releases? i. e. lucid/maverick/natty?
<mdeslaur> pitti: yes
<mdeslaur> pitti: 8.3 compiled fine on hardy armel though
<pitti> ok, then it's very likely a regression in .9
<pitti> built fine on sid, though (https://buildd.debian.org/status/fetch.php?pkg=postgresql-8.4&arch=armel&ver=8.4.9-1&stamp=1317049566)
<pitti> mdeslaur: I'll try that in a porter chroot
<mdeslaur> pitti: thanks
<mdeslaur> pitti: the way it's failing could be a lack of resources on the builders
<pitti> I wonder whether the shm settings changed
<pitti> mdeslaur: oh, the buildds changed
<pitti> mdeslaur: we now have panda board
<pitti> s
<pitti> previously (until a few weeks ago) we had another kind
<pitti> mdeslaur: anyway, I'll try on the porter box
<mdeslaur> oh!
<mdeslaur> pitti: ok, let me know
<pitti> mdeslaur: I think all the arm builders which are on "manual" are the old ones
<pitti> mdeslaur: do you have the builds in a PPA or so, where you can retry them easily?
<mdeslaur> pitti: is porter a panda board?
<pitti> I wonder if we could temporarily set the panda boards on manual and reactivate one of the old ones to grab the build
<pitti> to see whether that's the difference
<mdeslaur> pitti: yes, there in the security PPA, I can retry them
<pitti> mdeslaur: don't yet, need to ask lamont first
<pitti> mdeslaur: no, kakadu (porter) is a babbage (MX51)
<mdeslaur> lamont: although pandas are quite cute, it turns out they can be pretty mean
<pitti> lamont: are the old babbage armel buildds really down, or just disabled to let the pandas build everything?
<pitti> lamont: i. e. can I reactivate one of the babbages to let teh postgres update build?
<pitti> also, do we have a panda porter box?
<pitti> mdeslaur: 8.4.9 build running on kakadu now; will take a bit, though
<mdeslaur> pitti: thanks
<cjwatson> pitti: scheat
<pitti> cjwatson: bisecting :) not sure whether we want to wait with the security update until postgres works on panda; I guess not?
<lamont> pitti: infinity stuck all the non-pandas on manual so that pandas win
<pitti> lamont: ah, but they still work
<lamont> you could certainly stuff something on one of the ones listed as manual
<pitti> lamont: thanks
<pitti> mdeslaur: kakadu still building; shall we try this, to have some parallelism?
<lamont> pitti: I've been failing to bring the bbg3 boards back when they fall over, since they're not suitable for a datacenter.  if they're not DISABLED in launchpad, they're live
<pitti> lamont: cool, thanks; wanted to be sure I won't set anythign on fire by reenabling them
<mdeslaur> lamont: is there a way I can force a PPA rebuild to a specific builder?
<lamont> it was done entirely for build time minimization
<pitti> mdeslaur: I'll do taht
<lamont> mdeslaur: you get someone with buildd admin privs to encourage it
<pitti> mdeslaur: if you can stand by with retrying (don't yet), I'll set up teh buildds accordingly
<pitti> lamont: on it
<mdeslaur> pitti: ok, let me know
 * pitti looks for a suitable bait -- aah, this candy over here!
<pitti> mdeslaur: ok, please retry the build now
<pitti> should land on actinidiaceae
<mdeslaur> pitti: ok, have retried lucid
<mdeslaur> pitti: yep, it's on actinidiaceae
<pitti> mdeslaur: ok, https://launchpad.net/builders/actinidiaceae now "building private source"
<pitti> I reset the buildds
<mdeslaur> pitti: ok, cool, now we wait
<pitti> for some reason https://launchpad.net/builders just stopped working for me (I get "forbidden")
<pitti> perhaps LP now forbids me seeing this as soon as there's a private build running?
<mdeslaur> pitti: yeah, apparently when there's a security build going on that whole page gets forbidden
<mdeslaur> pitti: I wasn't aware of the change, but someone mentioned it this week
<pitti> that's new, though; I used to be able to see it
<pitti> it's not that secrect, though, https://launchpad.net/builders/actinidiaceae still shows it
<mdeslaur> it's not a very good change, it should still work, but simply not say what's building IMHO
<pitti> also, "yes, we are building security updates" -- that's not exactly a secret?
<pitti> mdeslaur: it never did
<pitti> it just said "private build"
<mdeslaur> so, it's broken
<pitti> it's never really been an information leak
<pitti> except that you coudl have timed it and thus make some guesses
<mdeslaur> meh
<pitti> but now I can still time the time that the page has "forbidden" for me :)
<pitti> (imagine some less ridiculous word repetition there)
<mdeslaur> right, not a big difference :)
<frafu> Hi, could anybody please tell how I can submit a package to proposed as requested here: https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/872374/comments/1
<ubottu> Ubuntu bug 872374 in onboard (Ubuntu Oneiric) "Feature Freeze exception request: new version with GI, gsettings,..." [High,New]
<charlie-tca> frafu: probably better to ask in #ubuntu-motu or #ubuntu-devel, actually.
<charlie-tca> ooops
<charlie-tca> sorry, wrong channel
<frafu> It is a package from main; should I nevertheless ask in MOTU?
<tumbleweed> !sru | frafu
<ubottu> frafu: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<charlie-tca> no, here should be correct
<frafu> What does 'Use Nominate for series' mean? It is in the procedure to get it into sru.
<tumbleweed> frafu: already done on that bug, it adds a task for the series (oneiric task below the "onboard (Ubuntu)" yellow bar
<frafu> tumbleweed: Has it also already been submitted to -proposed? (I suppose that it means release-proposed!?
<tumbleweed> frafu: that would be an upload to oneiric-proposed, that someone will have to sponsor for you. Procedure is to subscribe ubuntu-sponsors and wait. But seeing as there's some urgency here, maybe a core-dev lurking here now can sponsor it (I'm not a core-dev)
 * tumbleweed has been saying that a lot recently. Maybe I should apply... (but I don't touch main much...)
<frafu> tumbleweed: Thanks for the explanation.
<pitti> mdeslaur: build finished just fine on kakadu
<pitti> mdeslaur: seems we need a panda porter box to figure this out then
<mdeslaur> pitti: ok, let's see if actinidiaceae builds it
<pitti> mdeslaur: fun, now I can see the /builders page again although it's still building
<mdeslaur> how odd
<mdeslaur> maybe it's not related to the security build
<infinity> pitti: We have a panda porter box.
<infinity> pitti: scheat.
<pitti> ooh
<pitti> I thought when cjwatson said this he meant "cheat", for trying to work around the FTBFS
<slangasek> "scheat"?  are we now naming machines after Homestar Runner characters?
<infinity> Ask Nafallo. :P
<Nafallo> infinity: no, lamont.
<Nafallo> slangasek: arabic stars currently
<infinity> Nafallo: You didn't get to name these ones?
<Nafallo> infinity: I choose not too.
<Nafallo> infinity: I got to name Zavijava yesterday though, so I'm content
<slangasek> Nafallo: where's omar-sharif then
<Nafallo> slangasek: double name. likely vetoed :-)
<slangasek> snerk
<Nafallo> that compiz in -proposed btw. are there loads of bugs about it?
<Nafallo> I just downgraded to confirm that was what kept stealing my windows and hiding them someplace else.
<slangasek> Nafallo: do you mean to ask "where do I report that the -proposed compiz is broken"? :)
<infinity> I think that's exactly what he meant.  It gets lost in translation from the original Swedish Chef.
<Nafallo> slangasek: nope. more of a "have anyone seen this, or do I need to file a new bug"
<Nafallo> infinity: b0rk bork b0rkie.
<slangasek> no, you need to mark an *existing* bug as verification-failed so that the SRU team knows not to copy it to -updates
<infinity> That assumes there's an SRU bug open forit.
<slangasek> Nafallo: by taking https://bugs.launchpad.net/bugs/748840 for example, explaining the regression in the comments, replacing 'verification-needed' with 'verification-failed' in the tags, and linking to a bug report for the new behavior if you have one
<ubottu> Ubuntu bug 748840 in unity "Windows should not automatically be focused when opened if the focus is on another application" [Critical,Fix committed]
<slangasek> infinity: why would we accept something into -proposed without an SRU bug?
<Nafallo> hopefully the bug is listed in the changelog then
<slangasek> yes, that's how it works
<infinity> slangasek: We really shouldn't.  Just sayin'. :P
<slangasek> infinity: oh, btw
<slangasek> Binary files i386/usr/share/man/man8/pam_shells.8.gz and amd64/usr/share/man/man8/pam_shells.8.gz differ
<infinity> *^$!%
<infinity> Also: fuck.
<Nafallo> hrm. loads of bugs in the changelog, but none for the SRU itself I don't think.
<slangasek> Nafallo: it doesn't matter, we don't *want* placeholder SRU bugs in the changelog
<infinity> No, but each of those bugs will need verification, so pick one and fail it. :P
<slangasek> yes
<Nafallo> heh
<infinity> slangasek: Here's a question, do the differing files match the differences from the last build?
<slangasek> infinity: the good news is, armel and i386 are the same this time... so we're down to one random variation instead of two :P
<slangasek> infinity: checking
<infinity> slangasek: (ie: is this deterministic and repeatable, and we just don't know how to determine the repeatable steps yet?)
<infinity> slangasek: The part where armel wasn't as broken as last time, while amd64 is, is a bit shaky already. :/
<slangasek> infinity: yes, amd64's pam_shells.8.gz came out the same in both runs
<infinity> Unless it relates to what machine it built on...
<slangasek> but *different* than when I run gzip here
<infinity> slangasek: Same machine for both amd64 builds?
<infinity> (And different for both armel builds?)
<slangasek> haven't looked; will look later
<infinity> I can look.
<bdmurray> why are duplicates of bug 870281 still coming in?
<ubottu> Launchpad bug 870281 in flashplugin-nonfree (Ubuntu Oneiric) "installer crash when user choose to install additional software: http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.3.183.10.orig.tar.gz doesn't exist" [High,Fix released] https://launchpad.net/bugs/870281
<bdmurray> would it just be an out of date mirror?
<bdmurray> http://nl.archive.ubuntu.com/ubuntu/ oneiric/multiverse flashplugin-downloader i386 10.3.183.10ubuntu5
<charlie-tca> It still happens on some fresh installs
<slangasek> bdmurray: yep, sounds like an out-of-date mirror then
<infinity> slangasek: amd64 builds were both on allspice, armel builds were on a babbage (broken) and a panda (not broken).
<slangasek> bdmurray: escalate to IS?
<infinity> slangasek: I don't know what this means, but it might at least mean this wouldbe debuggable with hardware access.
<bdmurray> slangasek: oh?
<slangasek> bdmurray: current version of the package in the archive is 11.0.1.152ubuntu1, so nl mirror seems to be out of date; so that needs to get fixed, or the mirror taken out of the mirror list
<bdmurray> slangasek: right, in #ubuntu-mirrors now
<slangasek> ok
<bdmurray> slangasek: I've found 3 so far that are out of date
<slangasek> yuck
<davmor2> mvo, pitti: hey guy I got an issue with jockey and ati (post-release updates) it won't install the driver paste.ubuntu.com/706773 is jockey log,  I'm assuming there is no driver and that is the issue but I expect it to install the current and then update to the latest if I select it.
<didrocks> barry: hey, I tried your "from __future__ import unicode_literals", but I still get some "UnicodeEncodeError: 'ascii' codec can't encode character", I guess that's due to the launchpad results I get, any trick?
<barry> didrocks: wow, sorry, i've forgotten the details of our previous chat ;)
<didrocks> barry: well, notC related for this time, but I raised that we recently got random UnicodeEncodeError: in oneiric (since starting september I would say) in various python apps (software-properties, apport, oneconfâ¦) without any code change
<didrocks> barry: and there, I have one when trying to write to a file, the data comes from launchpad, I guess I need to decode in ascii with just ignoring unicode character, or is there a smarter way?
<barry> didrocks: ah right.  i was also musing with mvo about this i think.  i wondered whether the default encoding for the file had changed.
<barry> didrocks: i don't remember how the data comes from lp.  is it utf-8 text, latin1 or ascii text, bytes?
<barry> i guess not ascii text though :)
<didrocks> barry: it's utf-8 from what I remember (but it's not only with launchpad, the issue happened recently with loading translation for instance)
<barry> didrocks: right, i'm remembering now
<barry> didrocks: do you have an example that i can try to reproduce here locally?  i can recommend a hammer to keep you going (basically using errors='replace' or errors='ignore'), but since this is coming up in several cases, it might be better to dig in a little on what's going on
<didrocks> barry: if you are not afraid by using a french locale, yeah :)
<barry> didrocks: well, maybe in a vm :)
<barry> didrocks: english locales already freak me out :)
<didrocks> barry: ahah ;) just "bzr branch lp:oneconf", and apply this patch to remove my workaround: http://paste.ubuntu.com/706780/
<didrocks> barry: then ./oneconf-query --help should badly fail
<didrocks> (on french locale)
<barry> didrocks: cool.  it'll take a little bit to get the vm fired up, and i need to run out for lunch.  let me get started on this and i'll ping you in a little while
<didrocks> barry: sure! enjoy your lunch :)
<barry> didrocks: thanks!  (not fun though, i have to get my car emissions inspected :)
<barry> -- and i'm already a month late
<didrocks> urgh :/
<barry> yeah, when they threaten to suspend your registration, it's time to finally do it :)
<barry> didrocks: anyway, is there a bug that i can comment on when i have some more information?
<didrocks> barry: well, I closed it with the workaround, I'll open one and ping you back with it
<barry> didrocks: perfect. feel free to subscribe me to it too
<didrocks> will reference other recent issues we have as well
<didrocks> sure
<SpamapS> pitti: I didn't.
<pitti> davmor2: this log shows that the fglrx-updates driver has been installed just fine
<pitti> davmor2: what's wrong with it?
<davmor2> pitti: Jockey exits and says check the log
<davmor2> pitti: also the interface says that it isn't installed
<pitti> davmor2: can you please file a bug with that log and a description what happened? (need to run out in about 10 mins)
<pitti> davmor2: I see one error there, but I need to discuss that with tseliot first
<davmor2> pitti: yeap no worries
<pitti> davmor2: please let me know the number here
<davmor2> pitti: will do
<tseliot> here I am
<pitti> thanks
<pitti> davmor2: the driver package is installed, though
<pitti> tseliot: it says
<pitti> ERROR: xorg:fglrx_updates: get_alternative_by_name(fglrx-updates) returned nothing
<tseliot> pitti: that should be correct if the package hasn't been installed yet
<pitti> tseliot: so either it's calling the nvidia-common alternatives handling wrongly (i. e. returning None is valid), or some symlinks are broken on that box?
<pitti> tseliot: but it was
<pitti> dkms completed and all that
<pitti> it's before calling set_alternative(), though
<pitti> tseliot: it's in ./data/handlers/fglrx.py line 90 apparently
<pitti> tseliot: i. e. XorgDriverHandler.enable(self) finished, which does all teh "install pacakge" stuff
<pitti> so it aborts and doesn't call set_alternative
<pitti> admittedly I'm not sure what that does
<pitti> davmor2: does the driver actually work?
<tseliot> pitti, davmor2: the output of "update-alternatives --display x86_64-linux-gnu_gl_conf" and of "update-alternatives --display i386-linux-gnu_gl_conf" might help
<davmor2> pitti: unfortunately I need the system up and running so I installed the standard one after I got the logs for you so I'm not sure,  I have a spare ati box to my left I can try it again there and capture it all for you
<pitti> ok, thanks
 * pitti waves good night then
<tseliot> ok, I guess I'll take off too then
<Nafallo> slangasek: hey. I spoke to didrocks, and my bug is fixed already. he has a pending upload waiting to be accepted. just FYI etc :-)
<Nafallo> infinity: ^--
<infinity> Nafallo: Accepted to get people testing the new one.
<Nafallo> infinity: \o/ ^-- didrocks :-)
<didrocks> thanks infinity, Nafallo :)
<didrocks> infinity: you need the new compiz and new compiz-plugins-main
<infinity> didrocks: Yeah, I accepted both.
<didrocks> thanks :)
<mdeslaur> pitti: postgresql successfully built. Could you redirect the two other armel builds, so I can push the update while we investigate?
<slangasek> Nafallo: ok - did you still mark the bug verification-failed? :P
<Nafallo> slangasek: I did, but revert once it didn't fix the issue.
<mdeslaur> lamont: looks like pitti is gone. Could you redirect my two postgresql builds to the old armel builders?
<Nafallo> slangasek: it seems to be some combination bug with various compiz packages involved. I poked didrocks instead when I got confused enough :-)
<didrocks> slangasek: there is a new bug covering this issue in the latest upload (it's a regression)
<slangasek> didrocks: is it a regression between the version in the release pocket and the one in the proposed pocket?
<didrocks> slangasek: right
<infinity> mdeslaur: Did you two determine earlier that postgres fails on pandas?
<slangasek> didrocks: then it is CRITICAL to document this on one of the SRU-linked bug reports from the previous upload with the verification-failed tag
<infinity> mdeslaur: Any plan to debug that on scheat?
<slangasek> otherwise, SRU team members who aren't sitting here in this conversation right now don't know not to publish it
<mdeslaur> infinity: pitti was looking for a panda server he could play with to figure it out
<cjwatson> (and might not remember even if they were in this conversation - I process SRUs to -updates mostly in robot mode)
<infinity> mdeslaur: That would be scheat.
<didrocks> slangasek: hum? the new upload in -proposed overwrite the previous version, ,isn't it?
<infinity> mdeslaur: I told him about it too. :P
<Daviey> uh?
<mdeslaur> infinity: do you have the magic permissions required to redirect my two builds to the old builders for now?
<Daviey> didrocks: re-using the same version string for a -proposed upload that was rejected?
<infinity> mdeslaur: Where are these builds you needed bounced to specific machines?
<cjwatson> oh, if there's a new version in -proposed already, that should be fine
<didrocks> Daviey: no, a new upload with a new version as the version in -proposed has been published
<Daviey> ahh. cool.
<mdeslaur> infinity: they are in the security ppa, postgresql-8.4 on maverick and natty
<didrocks> cjwatson: yeah, there is no chance the previous version to be published in -updates, right?
<infinity> mdeslaur: I might not have access to your PPA.  But if you retry them, I'll make sure they land where they need to be.
<mdeslaur> infinity: ok, hitting the retry button now
<cjwatson> didrocks: no
<didrocks> thanks cjwatson
<mdeslaur> infinity: done
<infinity> mdeslaur: And done.
<infinity> mdeslaur: Just the two builds, right?
<mdeslaur> infinity: one started on actinidiaceae, and the other on adoxaceae
<mdeslaur> infinity: yeah, just those two. Thanks a bunch.
<infinity> mdeslaur: I'm not in the security team anymore, so all I see is "Private Source". ;)
<infinity> mdeslaur: But thanks for confirming.
<mdeslaur> infinity: t0p s3cr3t
<slangasek> didrocks: has the new upload to -proposed been accepted into -proposed yet?
<cjwatson> slangasek: yes, it's in the publishinghistory
<slangasek> cjwatson: ok then :)
<slangasek> infinity: loving this bug now
<slangasek> infinity: are there magic ssseeee2222 optimizations in zlib1g?
<slangasek> (did I get enough esses in that?  I'm not sure)
<infinity> slangasek: I really hope not.
<infinity> slangasek: Also, I couldn't reproduce it on kakadu. :/
<Nafallo> I tried out didrocks new binaries. They work for me. what do I need to do next? :-)
<infinity> slangasek: So, my babbage versus panda theories are tenuous.
<slangasek> You assume all babbages are broken the same way? ;)
<infinity> slangasek: *headdesk*
<Laney> bdmurray: your script seems to hit bugs multiple times, for example bug 871548
<ubottu> Launchpad bug 871548 in guichan (Ubuntu) "Library does not load in Ubuntu 11.10 due to missing symbols" [Medium,Fix released] https://launchpad.net/bugs/871548
<bdmurray> Laney: it doesn't check to see if the sponsors team has been removed yet
<bdmurray> Laney: I'll see if I can squeeze that in today
<Laney> awesome
<Laney> :-)
<bryceh> jml, are you still experiencing bug #849782?  seems our diagnostics aren't turning up anything useful so far, and I'm wondering about maybe forwarding it upstream if it still occurs.
<ubottu> Launchpad bug 849782 in xserver-xorg-video-intel (Ubuntu) "Screen jitters every so often, especially when laptop under load" [Medium,Incomplete] https://launchpad.net/bugs/849782
<davmor2> pitti: sorry for the delay work got in the way, doing the 64bit install on the spare box now I'll let you know once I file the bug the number
<slangasek> seb128: 736153> oh, you assigned this to freetype?  freetype doesn't choose the glyphs, fwiw
<seb128> slangasek, fontconfig does? ;-)
<slangasek> no, pango
<seb128> hum, k
<seb128> I've not clue about fonts :p
<slangasek> freetype just renders the glyph it's asked for :)
<seb128> slangasek, feel free to reassign at the right place, g-c-c was just wrong ;-)
<seb128> slangasek, thanks
<slangasek> yep - reassigned already
<slangasek> but it's fontconfig - picks which fonts to use; pango - picks which glyphs are needed for a string; freetype - turns those glyphs into graphics
<davmor2> pitti: bug 873058 with recorded video, if there are any logs etc that you need I've not added the driver this time, so I can do any tests that you need doing
<ubottu> Launchpad bug 873058 in jockey (Ubuntu) "Jockey fail to install binary ati driver (post release) version" [Undecided,New] https://launchpad.net/bugs/873058
<jml> bryceh: yes, I am.
<jml> bryceh: whenever my system is under load or when I'm watching youtube videos
<jdstrand> broder: hi! you have a work item from https://launchpad.net/ubuntu/+spec/security-o-catch-all: "[broder] write a script to report -backports packages that need an update due to -security"
<jdstrand> broder: whatever happened to this?
<jdstrand> broder: iirc, you weren't in the session, but ScottK said it was something you were already working on
<bryceh> jml, great thanks
<jml> bryceh: I can demonstrate in Orlando, if that will help
<bryceh> jml, maybe...  I'm guessing that the issue is that the driver's not able to keep the gfx pipeline full 100% and when it isn't the monitor glitches
<bryceh> but I'm not sure  how to prove or disprove that, so it's kind of a useless guess :-/
<bryceh> jml, what I think I'll do is forward your bug upstream; maybe they can shed more light on it
<jml> bryceh: ok. thanks.
<bryceh> jml, oh one thing you could doublecheck... boot a natty livecd and just verify that you definitely aren't seeing the issue in natty
<jml> bryceh: ok. I can do that. (although not tonight, I'll make a note.) I'll also try to reproduce on a clean oneiric live stick, as I don't think I have yet.
<bryceh> that'll help eliminate any chance it's just hardware (e.g. degraded power supply), and firm up the known-good side of the regression
<bryceh> jml, thanks
<jml> bryceh: I'm guessing the fix won't be in the release anyway :)
<bryceh> jml, nope
<bryceh> jml, chance of an SRU though.  we'll see
<barry> cr3: ping
<cr3> barry: pong, what's up?
<barry> cr3: did we talk recently about UnicodeEncodeErrors with i18n?
<cr3> barry: that rings a bell but I wouldn't remember the specifics though
<barry> cr3: okay, i was talking to didrocks earlier today about a similar problem, which i figured out.  i thought at the time maybe it was mvo i'd talked to, but now i think it was you.  anyway, i could forward you the message i sent to didrocks about it if you care, or you can just read my blog post about it when i publish it :)
<cr3> barry: I haven't found a place for blogs in my life, so I'd be very interested in an email forward. thanks for following up!
<barry> cr3: will send...
<broder> jdstrand: yeah, sorry - didn't happen. should be postponed
<broder> bah. it would be nice if do-release-upgrade would drop me to a shell or something to recover instead of just bailing when something went wrong
<jdstrand> broder: ok
<slangasek> bdmurray: hmm, does apturl work for you at all?
<slangasek> fails for me with a missing-icon error
<bdmurray> slangasek: yes it seems to work for me
<slangasek> ok
<slangasek> guess I should file a different bug :)
<tumbleweed> broder: that is something that should be quite easy to do in a UDD query
<broder> tumbleweed: hmm, i hadn't thought of that
<broder> i was going to go do awful things with lplib
<broder> but i still won't have time to implement it before tomorrow
 * tumbleweed just tried a few ideas, but they are turning up 0 results. That could just mean that the backports team is on top of things... :P
<broder> unlikely
<broder> SpamapS: what's the deal with the network configuration thing? i thought i just needed to remove eth0 from /etc/network/interfaces and let NM deal...
<tumbleweed> Laney: do you know anything about the ubuntu_sources UDD import? It only has the release pocket (and has some pretty unecessary columns)
<broder> geez...i don't think i've ever broken my system this badly on an upgrade before...
<Laney> no
<SpamapS> broder: indeed, that should do it.
<Laney> i only did the ubuntu_upload_history one
<Laney> lucas: ^^^
<broder> i think.../run isn't getting bind-mounted onto /var/run...
<SpamapS> lrwxrwxrwx 1 root root 4 2011-10-08 19:20 /var/run -> /run
<SpamapS> no, its a symlink
<broder> mine isn't
<SpamapS> I did upgrade a long time ago..
<SpamapS> so its possible I missed one of those "hey everybody if you already upgraded do this" emails
<broder> no, it looks like that's what the base-files postinst is supposed to do
<broder> ...i wonder what would happen if i changed my sources.list entries back to natty and re-ran the upgrade
<broder> nope
<ajmitch> broder: how badly have you broken it?
<broder> well, apparently the /var/run -> /run migration code didn't run, so i'm going to go with "badly"
<slangasek> broder: is /etc/rc6.d a mess?
<slangasek> do you have vmware packages installed?
<broder> slangasek: i do!
<broder> (rc6.d is not a mess)
<slangasek> yeah, vmware has decided you don't need a shutdown "sequence", hth
<slangasek> broder: are you sure it's not a mess? possibly with 'reboot' and 'umount' scripts running in parallel? :P
<slangasek> is this a leading question?
<slangasek> bug #858122
<ubottu> Launchpad bug 858122 in sysvinit (Ubuntu) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged] https://launchpad.net/bugs/858122
<slangasek> hmm, except there was another bug that talked explicitly about the vmware problem
<broder> oh good grief
<broder> slangasek: so is there a reasonable way to clean this up, or do i have to settle for the unreasonable way of just fixing up /var/run and /var/lock by hand?
<slangasek> broder: well, you can fix rc6.d by hand and then reboot... then /etc/rc6.d/S60umountroot will take care of it for you
<slangasek> realistically you need to reboot afterwards anyway, so that might be simplest
<slangasek> not finding the bug that explains vmware being at fault, hrm
<broder> weird that this only happened on one of my machines - i upgraded another one with vmplayer installed and that was fine
<broder> maybe it's workstation specific? i've only ever had that installed on this one, though i don't currently
<slangasek> that sounds correct
<broder> err, "don't have it installed currently"
<slangasek> broder: you do have reboot with a link of something like S03reboot though, right?
<slangasek> instead of S90 like it's meant to have?
<broder> yeah
<slangasek> yeah, that's the symptom
<broder> the whole order is screwed up - almost all of htem are S03, except for urandom and casper which are S04
<slangasek> heh
<slangasek> been getting much disk corruption on reboot lately?
<broder> wouldn't have noticed
<broder> dbus wasn't starting because /var/run/dbus/pid was sticking around
<broder> it goes downhill from there pretty quickly
<broder> actually, i guess one of my disks got ejected from the raid 1...
<slangasek> right, I mean corruption *prior* to upgrade... since the rc6 screwup probably happened some time in the past
<slangasek> oh, here it is. https://bugs.launchpad.net/ubuntu/lucid/+source/sysvinit/+bug/616287
<ubottu> Ubuntu bug 616287 in sysvinit (Ubuntu Natty) "umountfs doesn't cleanly unmount / on reboot" [High,Triaged]
<slangasek> https://bugs.launchpad.net/ubuntu/lucid/+source/sysvinit/+bug/616287/comments/93
<bryceh> GrueMaster, here's your next airline cost-cutting move - http://www.huffingtonpost.com/2011/10/12/ryanair-removing-toilets-planes-seats_n_1006604.html
<GrueMaster> NOOOOOOOO!!!!!!!!
<bryceh> but if no loo, just do the Depardieu
<slangasek> Ryanair, motto: "We love to fly on a different airline"
<sladen> GrueMaster: I assume it's going to hit the same issue as the last time around: the airframe is certified for X seats, and that's the same X that Ryanair already have fitted.  There is a mandated ratio of X passengers to Y staff â¦ and so would require an additional member of staff too
<GrueMaster> I'd say charge extra for the toilets and consider them "Executive Class".
#ubuntu-devel 2011-10-13
<pitti> Good morning
<nigelb> Morning!
<pitti> mdeslaur, infinity: I can replicate the postgresql test suite failure on scheat
<pitti> mdeslaur: do you still need some builds?
<ajmitch> morning pitti
<pitti> debfx: can you please reupload kde4libs with -v4:4.7.1-0ubuntu3 to include the previous -proposed changelog?
<didrocks> good morning
<ejat> pitti : u here ?
<pitti> ejat: hello
<ejat> pitti : just wanna check with u pgsql 9.1 package in lucid ..
<ejat> doesnt have conf folder in /etc
<ejat> just have /etc/postgresql-common not /etc/postgresql/9.1/main
 * ejat we should i check? or should i reinstall ? 
<ejat> where*
<pitti> ejat: the /etc/ bits are not shipped in the .deb
<pitti> ejat: if you install postgresql-9.1 from scratch, it will create a 9.1/main cluster through the postinst
<pitti> ejat: but not on upgrade or if you already have some configuration bits there
 * ejat fresh install lucid .. 
<pitti> ejat: please have a look at /usr/share/doc/postgresql-9.1/README.Debian.gz
<ejat> so need manual do the /etc ?
<pitti> ejat: no, you shouldn't for a fresh install
<ejat> but in natty it ship in the .deb right ?
<pitti> no
<pitti> we haven't shipped it in the .deb since sarge, and never ever in Ubuntu
<ejat> owh ..
<pitti> ejat: perhaps you can do
<pitti> sudo apt-get purge postgresql-9.1
<pitti> sudo apt-get install postgresql-9.1
<pitti> capture the whole output
<ejat> ok .. /me trying â¦
<pitti> and put that inot a bug report?
<ejat> ok .. thank pitti  .. its work after purge n reinstall â¦
<ejat> just wondering y that could be happen?
<pitti> the most likely cause is that there were some files left in /etc/postgresql/ from previous installations
<dholbach> good morning
<cousin_luigi> hello
 * cousin_luigi has just a simple question: is gnome-session-fallback gnome3 based?
<didrocks> cousin_luigi: yes, it's the gnome3 one
<cousin_luigi> didrocks: gnome3 people are telling me it's unity-based
<didrocks> cousin_luigi: they are wrong then, it's pure usptream one, we even didn't add indicators by default
<ogra_> else it would be called unity-session-fallback, or ubuntu-session-fallback :)
<cousin_luigi> didrocks: http://i.imgur.com/SWwLI.jpg <- it's this one
<cousin_luigi> ogra_: I guessed as much:)
<cousin_luigi> didrocks: may I quote you on that?
<didrocks> cousin_luigi: sure, for the above bar though, it's a bug in appmenu-gtk, you need to remove appmenu-gtk to workaround it
<didrocks> but then, you have the gnome-session-fallback experience
<cousin_luigi> didrocks: appmenu-gtk, got it
<cousin_luigi> didrocks: that's what I actually crave:)
<didrocks> cousin_luigi: ok, without a screenshot, wasn't obvious ;-)
<cousin_luigi> didrocks: Ok, removing both appmenu-gtk and appmenu-gtk3 did the trick. Do you think that glitch will be solved in 11.10 final?
<didrocks> cousin_luigi: no, it's too late for finale, maybe in a SRU, better that you ping Cimi and tedg on #ayatana
<cousin_luigi> didrocks: SRU?
<didrocks> cousin_luigi: stable release update
<cousin_luigi> ah ok
<cousin_luigi> will do
<didrocks> thanks :)
<cousin_luigi> ok, I'm happy with my new desktop
<cousin_luigi> thanks everyone
<cousin_luigi> bbl
<tgardner> pitti, sconklin was complaining to me last night that a bunch of kernel packages got copied to universe. 'rmadison -S linux|grep universe' shows some stuff that absolutely should be in main (like all i386/amd64 packages at least)
<tumbleweed> broder: Worked out why my backports udd queries weren't getting verly far. Lany: Backports uploads don't appear to be imported. I'm guessing they don't hit -changes?
<Laney> not sure
<Laney> there were some manual ones lately
<Laney> have a look at hardy-changes and see if you can see nginx
<Laney> it might just be that no-change ones aren't announced, like syncs
<Laney> seems not, file a soyuz bug?
<tumbleweed> Laney: http://paste.ubuntu.com/707228/ yeah, I guess so. Obviously having -backports in ubuntu_sources is preferable, but this would be nice too
<Laney> i think it would be nice to have both
<tumbleweed> grumble, can't get to lp (ZA's international connectivity is pretty screwed right now, the big, cheap, undersea cable is down). I'll do it later...
<Laney> in the meantime udd can be improved to pull from all pockets
<debfx> pitti: ok, I have reuploaded kde4libs
<tumbleweed> Laney: found bug 59443
<ubottu> Launchpad bug 59443 in Launchpad itself "Soyuz should send announce messages for backports to different list" [High,Fix released] https://launchpad.net/bugs/59443
<Laney> weird
<tumbleweed> basically they are currently purposely /dev/nulled
<rye> may i draw some attention to the upgrade process - in case the upgrade from natty to oneiric is done via wifi, the whole process whill signal about the error since networkmanager disconnects wifi during upgrade (why?), and flashplugin fails to install due to missing network connection. This was filed as bug #859373 but I experienced this yesterday while upgrading my netbook
<Laney> another fix is to make it use lplib instead of the mboxes
<ubottu> Launchpad bug 859373 in update-manager (Ubuntu) "flashplugin-installer upgrade failed during Oneiric upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/859373
<tumbleweed> Laney: if there's a way to do that efficiently...
<Laney> but that is a pain because lp doesn't expose launchpad-bugs-fixed/closes so you have to parse the changelog yourself
<tumbleweed> that too
<tumbleweed> although, you can get at the changes file from the lp api
<tumbleweed> (if there is one)
<Laney> doesn't always exist
<mvo> rye: hrm, this is a tricky one, let me have a look
<rye> mvo, yeah, i was not able to reconnect to wifi, i am now writing a usb key to re-test this
<pitti> sconklin: linux binaries in universe> ah, the LP randomness again :/ fixing..
<pitti> debfx: thanks
<pitti> sconklin: hm, which ones in particular? the hardy flavors have always been in universe; should linux-image-2.6.32-21-preempt be in main?
<rye> mvo, basically there are 2 issues - 1 - wireless network drops during upgrade, 2 - flash player is unable to download and user finds installation to be interrupted. Outdated packages removal step is not run.
<tkamppeter> pitti, can you have a look at bug 653132? The one where the original poster does not answer any more.
<ubottu> Launchpad bug 653132 in system-config-printer (Ubuntu Oneiric) ""Add Printer" dialog requests root password if user is not in Configure Printers group" [High,Fix committed] https://launchpad.net/bugs/653132
<mvo> rye: thanks, it would be nice to know if NM always drops the connection and if it comes back once NM (or dbus even?)  is in "configured" state again
<rye> mvo, this does not happen on wired connections though
<mvo> rye: I see in the log that network-manager-pptp is used, did you use that as well?
<rye> mmm is it ok that http://releases.ubuntu.com/ point to mirror.anl.gov? :)
<rye> mvo, no, in my case it was a regular wifi connection with no vpn
<cjwatson> rye: yes, over IPv6
<debfx> pitti: could you please reject kde-runtime, I forgot to include the bug number in the changelog
<infinity> debfx: Done.
<debfx> thanks
<infinity> pitti: I already fixed the kernel-in-universe thing, it was just waiting on the publisher to agree.
<infinity> pitti: In fact, it seems to be fixed now.
<pitti> ah, thanks
<pitti> tkamppeter: still on my list (but I shouldn't be a bottleneck here, anyone can test this0
<mdeslaur> pitti: hi! No, I got all the remaining builds switched to the old builders yesterday, so I'm good to release. We do need to get this sorted out before the next release though.
<infinity> pitti: Do you have plans to debug the portgres issue on scheat?  If and when we ditch all the babbages, we kinda need psql to build/work.
<pitti> infinity: yes, that's on my list
<rye> mvo, if you are here - just started update to oneiric, nm applet has lost connection to NetworkManager
<rye> mvo, any logs i can provide?
<rye> mvo, nm-tool: WARNING **: _nm_object_get_property: Error getting 'WimaxHardwareEnabled' for /org/freedesktop/NetworkManager: (9) Property "WimaxHardwareEnabled" of interface "org.freedesktop.NetworkManager" isn't exported (or may not exist)
<mvo> rye: cyphermox is probably interessted in this as well, so NM lost connection at what point? can you see if the network-manager package is currently being upgraded? or maybe dbus itself?
<rye> i guess I need to file a separate bug
<mvo> rye: do you use Wimax at all? I wonder if its a gconf -> gsettings migration issue?
<rye> mvo, no i don't use wimax at all
<rye> mvo, .xsession-errors are full of nm-applet-related messages
<rye> but i can't pastebin :-/
<mvo> rye: could you add them to the bugreport please? (once you get the network back)
<rye> mvo, sure
<mvo> ta
<rye> mvo, hm, I see that NetworkManager pid is still 417 which may suggest it is the old one
<rye> mvo ooh. NetworkManager[417]: <warn> error requesting auth for org.freedesktop.NetworkManager.use-user-connections: (0) GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.NetworkManager.use-user-connections is not registered
<mvo> rye: that sounds like its the culprit!
<rye> mvo, once nm gets this it shuts down the network connection :-/
<smoser> is anyone able to run virtualbox on oneiric ?
<rye> mvo, happens during install libnm-gtk-common
<mvo> rye: do you mind if I paste some of this into the report?
<rye> mvo, sure, i can create a new bug, i suppose if i restart NM i will get the network back
<rye> mvo, the installation is supposed to keep networking, right? or we never promised that?
<mvo> rye: cyphermox is probably a good person to look into a fix for this, but I think we should try to keep the network up as hard as we can
<soren> smoser: I had the GUI up a couple of days ago. Didn't run any VMs, though.
<mvo> rye: stuff like mscorefontsinstaller also need network to continue
<soren> smoser: Is that a useful answer at all?
<mvo> rye: plus there might be people doing remote upgrades
<smoser> soren, not really. http://paste.ubuntu.com/707304/
<rye> mvo, oooops... and things like landscape
<rye> ok, got wired connection, going to pastebin everything
<soren> smoser: Gimme a sec.
<rye> .xsession-errors: http://pasteubuntu.com/707306/
<rye> syslog: http://paste.ubuntu.com/707307/
<rye> and dpkg.log: http://paste.ubuntu.com/707309/
<rye> mvo, ^
<mvo> rye: thanks a bunch, I wonder what package org.freedesktop.NetworkManager.use-user-connections is part of, maybe its enough to ensure its registed early enough
<rye> well, i suppose not many people would want to remotely upgrade on wifi
<rye> mvo, is there any place we can put this to errata or warning. Having people booooing the installer that upgrades and says "sorry, failed" w/o being able to direct them to a written word is something I'd like to avoid :)
<mvo> rye: we can put the problem that NM may loose network connection during the upgrade and that makes flashplugin-downloader fail  into the release notes, skaet is currently preparing them for the final announcement afaik. I would absolutely want to fix this at the NM level if at all possible
<rye> mvo, wireless only
<rye> mvo, and, probably if vpn is used then it is also affected, the only way upgrade can finish properly is wired/direct
<mvo> thanks rye, do you think you could write up a sentence or two for https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#Known_issues ?
<rye> mvo, so the question is - should I file a new bug, detailing the network loss and make the flashplayer download failure a duplicate?
<mvo> rye: I think we can keep the flasplugin one, I added a network-manager bugtask for it
<rye> mvo, ok
<mvo> rye: but if you prefer to create a fresh one, thats fine for me as well, it just sounds like unneeded work :)
<soren> smoser: It totally crashed and took X with it when I tried to run anything.
<smoser> soren, haha. you fell for my trap :)
<rye> mvo, i forgot we can add bug tasks
<smoser> nah... it doesn't start for me.
<soren> Lucky.
<smoser> refuses to start a vm.
<smoser> soren, well, for me, i opened bug 873330
<ubottu> Launchpad bug 873330 in virtualbox (Ubuntu) "virtualbox wont start vms, complains about missing /dev/vboxdrv" [Undecided,New] https://launchpad.net/bugs/873330
<rye> mvo, I don't have access to edit that :(, "If you are using wireless connection during the upgrade, the network manager may disconnect the network resulting in some packages being incompletely installed. Please use wired connection (LP:859373)."
<cyphermox> rye: mvo: looking at backlog now, what about network?
<cyphermox> rye: is it still about your issue while upgrading?
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> yeeeeeeehaw!
<rye> cyphermox, it is now more than flashplayer, basically in case machine is using wireless network it will drop it during upgrade leading to package manager complaining that the install finished, but there were failures
<mvo> cyphermox: check https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/859373/comments/7
<ubottu> Ubuntu bug 859373 in update-manager (Ubuntu) "flashplugin-installer upgrade failed during Oneiric upgrade" [Undecided,Incomplete]
<rye> and yeah, CONGRATULATIONS on the release!
<cyphermox> shouldn't be dropping while downloading stuff (or any time for that matter)
<rye> cyphermox, no, it gets dropped when it upgrades nm stuff
<pedro_> congrats all :-)
<rye> cyphermox, i suppose VPN, Wireless and 3G connections are going to be disconnected, wired works
<cyphermox> rye: which also shouldn't be happening; we don't even restart nm when we upgrade, precisely to avoid such issues
<OdyX> Congratulations pals !
<rye> cyphermox, i reproduced it twice, unfortunately
<cyphermox> rye: oh, I believe you
<cyphermox> rye: I'm just trying to think of what case would warrant this to fail
<rye> cyphermox, you can see the logs and it looks like PolicyKit blocks something
<cyphermox> I'll re-install natty on my system and give it another shot
<cyphermox> yeah
<rye> cyphermox, nm notices that and faints, bringing user's network down
<cyphermox> rye: makes sense
<cyphermox> rye: but why this bit in policykit fails doesn't
<cyphermox> I'm rebooting my desk laptop now to try and reproduce this
<pitti> is precise open for upload yet?
<pitti> (SCNR)
<pitti> congrats everyone!
<OdyX> pitti: nah nah nah, first help me refactor the printing stack. /me hidz.
<pitti> heh
<siretart> congratulations!
<akgraner> Thanks y'all!  :-)  Loving the new release :-)
<ogra_> AN IT LOVE YOU !!!
<ogra_> *loves
<ogra_> geezy, my typing ...
<ogra_> infinity, so where can i download the precise armhf images now ?
<ogra_> *g*
<sladen> just updated and rebooted.  Can't get past GDM now
<sladen> X died and takes me back to GDM after a few seconds
<sladen> can't get LightDM to come up at all
<sladen> bryceh: ring any bells?
<sladen> bryceh: ah, full / partition
<cyphermox> rye: ok, I understand the issue now
<rye> cyphermox, yeah, and cleanup process does not finish, to a casual user it looks like the upgrade failed
<cyphermox> rye: does it?
<cyphermox> is it completed at that point?
<rye> cyphermox, yes, basically the system is in usable state, but the dialogs are all telling about incomplete upgrade. I don't know what post-insall routines are running after upgrade though. After reboot the network is working
<cyphermox> ok
<cyphermox> the issue is that we no longer ship the use-user-connections policy and at that point NM isn't yet restarted so it hasn't migrated configs
<mvo> cyphermox: could we continue shipping this policy as a workound for the bug?
<cyphermox> mvo: that's exactly what I'm working on now, I just want to test to make sure it fixes the issue before the system is rebooted after upgrade
<cyphermox> mvo: I've already sent a text for a release note entry to skaet
<mvo> cyphermox: thanks, you rock :)
<cyphermox> mvo: not enough yet :)
<Riddell> mvo: btrfs causing upgrade breakage? bug 873411
<ubottu> Launchpad bug 873411 in update-manager (Ubuntu) "Unable to upgrade to 11.10 using kpackagekit" [Undecided,New] https://launchpad.net/bugs/873411
<mvo> Riddell: meh, apparently :/
<mvo> Riddell: I ask for more info
<cyphermox> mvo: you responsible for the (I'll say new because I never noticed that before) large upgrade overview window that opens? Here I just can't click "Ask me later": it doesn't react
<mvo> cyphermox: anything in ~/.xsession-errors when you do that?
<cyphermox> I'll check in a second; maybe it's also just missing updates since I only just installed natty on that system
<cyphermox> mvo: http://paste.ubuntu.com/707399/
<mvo> thanks cyphermox
<slangasek> stgraber: ping
<mvo> cyphermox: fyi https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/873424
<ubottu> Ubuntu bug 873424 in update-manager (Ubuntu) "ask me later fails" [Medium,In progress]
<stgraber> slangasek: pong
<cyphermox> ah, fun
<doko> pitti, uploads should be possible, will land in unapproved for precise
<slangasek> stgraber: hi there!  release is out, time to get to work on the next one right? :)
<pitti> doko: oh, wow! was really more of a mock question, but great; I'll upload cdbs/debhelper
<stgraber> slangasek: sure :)
<slangasek> stgraber: I've been playing a bit more with this ubiquity-dm/plymouth bug in the background over here
<ogra_> slangasek, wheer are the images, i want to test !
<stgraber> slangasek: is it still broken?
<pitti> heh, the second doko mentioned it, https://launchpad.net/ubuntu/precise/+queue?queue_state=1 got filled with 5 more packages :)
<slangasek> stgraber: so what I've found by capturing that process list is that neither ubiquity-dm *nor* the X server has actually exited when expected... I think there may be two parts to this issue. 1) instead of server.terminate() like you used in the signal handler, we're calling kill_if_exists(server.pid, signal.SIGTERM) before calling reboot... I don't know if that's supposed to do the same thing, but it doesn't seem to actually work?  2) the
<slangasek> ... signal handler doesn't actually exit ;)
<cjwatson> please don't go accepting uploads yet though
<cjwatson> (-> archive admins)
<slangasek> stgraber: but it's slow to iterate because we only hit the 'reboot' call in ubiquity-dm at the end of an install... if you can suggest a way to short-circuit this, that would speed up the debugging
<cyphermox> mvo: if I may add something, the release notes button also doesn't really send one to the release notes page, but rather to a wiki-syntax document on archive.u.c which contains the same text as the check-new-rellease-gtk presents; I'll open the bug report
<stgraber> slangasek: oh right, having a sys.exit(0) in there sounds useful :)
<stgraber> slangasek: in theory, the current kill_if_exists should be equivalent to .terminate() (wasn't quite sure of the reason behind that function as terminate()'s behaviour is identical)
<stgraber> slangasek: having the .wait() shouldn't make much difference either...
<slangasek> shouldn't it?  does .terminate() already wait?
<cjwatson> don't underestimate the possibility that I might not have known about a library function when I wrote something
<stgraber> no, my understanding is that terminate() doesn't wait, it just sends SIGTERM if the process still exists
<stgraber> cjwatson: it's a >= 2.6 feature, that probably explains it
<cjwatson> ah, yes, could be
<stgraber> slangasek: could it be that SIGTERM isn't enough for X to die?
<stgraber> slangasek: ok, quick test shows that X dies on SIGTERM, so that's not the problem (at least in a VM). Not sure why X is still running then
<jbicha> is there a chance that we could use xz by default for Precise packages?
<seb128> jbicha, define by default?
<seb128> jbicha, you can use .xz, soyuz handle it fine
<cjwatson> jbicha: no
<jbicha> well we use bz2 now right? and xz is just opt-in
<seb128> jbicha, i.e GNOME will likely use .xz
<cjwatson> such a change would be inappropriate in an LTS cycle
<seb128> Debian is already switching to it
<cjwatson> you are welcome to do it in individual packages
<jbicha> cjwatson: do you know of any specific breakage it would cause?
<seb128> Debian -> Debian pkg-gnome
<cjwatson> jbicha: that is not the relevant standard
<cjwatson> and yes actually I do
<cjwatson> it would break debootstrap
<cjwatson> even if we fixed that it would render debootstrap non-portable
<seb128> just curious, but what do we call "default" there?
<jbicha> ok, just thought I'd ask those who knew instead of proposing it to a mailing list
<cjwatson> jbicha: there was a discussion on debian-devel not that long ago
<cjwatson> seb128: dpkg's default
<seb128> oh ok, I was on orig uploads, ignore me ;-)
<jbicha> I should probably subscribe to that list too
<cjwatson> welcome to do it in individual packages> as long as they aren't part of the base system, that is
<jbicha> I believe Fedora does it for their RPMs and there are always questions about how we can squeeze out a little more space on the CDs
<cjwatson> mostly we care about the desktop CD now and .deb compression is mostly irrelevant there.
<cjwatson> and xz-ing the squashfs makes it non-rsyncable which is a huge QA pain.
<jbicha> cjwatson: by base system you mean the low-level plumbing? I set ubuntu-docs to xz for instance
<slangasek> stgraber: SIGTERM> sure, anything's possible.. I don't think I'll test that one on my running X server, however ;)
<cjwatson> jbicha: base system == anything installed by debootstrap
<cjwatson> ubuntu-docs is not that
<jbicha> ok, thanks for answering :)
<slangasek> stgraber: I think what would help most is if someone could give me a way to short-circuit ubiquity - e.g., causing it so clicking on the 'install' button causes an immediate sys.exit(0) so I don't have to go through the tedious install-to-disk process
<slangasek> stgraber: btw, what I have also noticed is that as soon as the ubiquity job enters state 'stopping' (i.e., before the process is even signalled), this unblocks kdm - which means that in the normal shutdown case we absolutely have to make sure we kill the X server *before* calling reboot
<dobey> is precise archive up already such that we can upload to it?
<cjwatson> dobey: you can upload, it'll be a while before it's acceptedthough
<slangasek> (from what I see, kdm also changes to target 'stop' at the same time so it doesn't spawn another X server or anything, but it *does* cause plymouth to start immediately thereafter)
<dobey> cjwatson: ah ok. just started seeing precise packages on launchpad /ubuntu/+source/foo pages. :)
<tkamppeter> pitti, bug 653132 isverified by larsu.
<ubottu> Launchpad bug 653132 in system-config-printer (Ubuntu Oneiric) ""Add Printer" dialog requests root password if user is not in Configure Printers group" [High,Fix committed] https://launchpad.net/bugs/653132
<cjwatson> dobey: mostly copies as a result of initialisation
<pitti> tkamppeter: ah, great
<dobey> cjwatson: yeah. was just checking to see if our oneiric SRUs made it to -updates yet and saw it so wondered if was usable yet. :)
<cjwatson> it isns't
<dobey> yep, thanks
<pitti> dobey: btw, in the first couple of days we'll just copy SRUs to both oneiric-updates and precise
<pitti> so no need to worry about the "needs fix in dev release first" part
<dobey> pitti: not worried about that really. just curious, as We want to make a consistent release plan for u1 :)
<tkamppeter> pitti, could you already pass the fixes of bug 653132 and bug 860691 to -updates as for CUPS the next SRU is already queued and for system-config-printer I am already preparing a new one. Thanks.
<ubottu> Launchpad bug 653132 in system-config-printer (Ubuntu Oneiric) ""Add Printer" dialog requests root password if user is not in Configure Printers group" [High,Fix committed] https://launchpad.net/bugs/653132
<ubottu> Launchpad bug 860691 in cups (Ubuntu Oneiric) "cupsd crashed with SIGSEGV in main() straight after boot and then periodically." [Medium,Fix committed] https://launchpad.net/bugs/860691
<pitti> tkamppeter: can do some tomorrow morning, I'm running out for today
<tkamppeter> pitti, OK, then tomorrow morning.
<slangasek> cjwatson: how long do I have to wait before I delete ia32-libs from precise? ;)
<cjwatson> slangasek: you can do it now
<slangasek> whooo
<infinity> slangasek: What do we plan to do about lucid->precise migration for people with ia32-libs installed?
<slangasek> oh, spoilsport
<infinity> I know.
<infinity> I hate me too.
<slangasek> ok, then I can immediately convert it into an empty package depending on ia32-libs-multiarch, have ia32-libs-multiarch depend on all the libs currently included, and just let it be uninstallable until they're all converted?
<infinity> That sounds vaguely reasonable.
<slangasek> infinity: don't you have a gzip bug to catch :-P
<infinity> I thought that was your baby.
<slangasek> oh btw, what's the verdict on plymouth hating everyone you work with?
<infinity> Also, I have parties to attend and such.
<slangasek> :-)
<infinity> To be fair, it hates people I don't work with as well.
<infinity> And I couldn't find a magical combination of anything that could give David both a console and X.  I'm less convinced that it's your problem, and more convinced that it's just kernel+nvidia = ha ha ha for consoles right now.
<infinity> I'll make sure he files bugs, though.
<slangasek> ok
<slangasek> kernel+nvidia is working perfectly fine here for me
<infinity> I'd love to know how.
<slangasek> so it's either specific to the card, or specific to the exact nvidia driver package he has installed
<infinity> Though his system could be uniquely special.
<slangasek> (is he using nvidia-current, or one of the legacy ones?)
<infinity> current.
<slangasek> how about Daviey's issue?  I haven't seen a bug for that either
<slangasek> Daviey: you owe me a bug for your plymouth problems :)
<infinity> I didn't really look at his.  I'll ask him to file a bug too.
<infinity> I don't work for Daviey, he can deal with his own crap. :P
 * Daviey perks up
<slangasek> Daviey: infinity claims that plymouth doesn't give you love on your system; I don't believe such claims until I see the bug reports :)
<Daviey> slangasek: I don't have plymouth problems, i have "my boot experience sucks" problems.
<slangasek> oh
<slangasek> what is your boot experience?
<Daviey> slangasek: >4 mins to lightdm.. with nothing to look at.. i want some plymouth prettyness,.
<Daviey> I also have no tty's.
<slangasek> oh, really
<slangasek> I'd ask you to send me a boot chart, but I remember how that went last time
<Daviey> They are there.. ie, if i login blind, i can restart processes.
<slangasek> right
<slangasek> please 'ubuntu-bug plymouth' me
<Daviey> for soley no theme on boot?
<slangasek> yes
<slangasek> frankly I'll probably wind up triaging it off somewhere else, but I know the plymouth apport hooks give me the info I need in order to do that :)
<Daviey> slangasek: bug 873475
<ubottu> Launchpad bug 873475 in plymouth (Ubuntu) "No graphical plymouth shown during boot or shutdown." [Undecided,New] https://launchpad.net/bugs/873475
 * Daviey wonders if slangasek will shout at him for his grub config
<slangasek> Daviey: we shall see! :)
<slangasek> Daviey: cool, you have the same issue as davidm
<slangasek> Daviey: entirely unrelated, but you might want to clean out /etc/udev/rules.d/86-hpmud-*: your boot.log is full of udev noise due to deprecated syntax
<slangasek> Daviey: I can confidently say that this is Not My Fault, as you're using uvesafb ;)
<dobey> hrmm
<dobey> what is the .pc/ directory and having patches applied within the bzr branch for a package nonsense for?
<chrisccoulson> heh, that's the main reason i hate full source branches
<dobey> chrisccoulson: the u1 packages don't do this
<dobey> afaik
<SpamapS> some do, some don't
<slangasek> cjwatson: what causes gfxterm to be set by default in grub2?  I can't work out where it comes from
<SpamapS> its madness, IMO
<dobey> SpamapS: can we make it so that none do?
<slangasek> cjwatson: ah, n/m, just found it... what alternatives are there, though?
<SpamapS> dobey: I believe it just depends on the source package settings
<dobey> masochism=True?
<slangasek> cjwatson: ignore that question too ;)
<SpamapS> dobey: debian/source/local-options you can put 'unapply-patches'
<SpamapS> dobey: there are severely differing points of view on this.. some like that the changes are bzr-managed for annotate/bisect/etc.
<dobey> SpamapS: it's a debuild thing rather than a bzr-builddeb thing?
<SpamapS> well bzr-builddeb just calls the same things as debuild.. so.. yes
<SpamapS> dobey: I find it maddening done either way... and prefer unapplied.. but I've learned to just deal. :p
<dobey> well there's nothing in debian/ to indicate it should be this way.
<dobey> it is beyond maddening
<SpamapS> I believe its just the default for dpkg-source to apply them
<SpamapS> so the importers do it
<dobey> weird
<dobey> ah, so it seems to be
<dobey> :(
<dobey> makes it like 10x more work to say, replace a patch with a slightly different one
<broder> on the flip side, it forces you to make sure the patch applies properly
<dobey> how so?
<dobey> not any more than debuild -S does, no?
<qwertologe> hello! i  developed a new ripper and search for someone who is able to package it and bring it into ubuntu... anybody here?
<highvoltage> qwertologe: hi! someone on #ubuntu-packaging will be able to poing you in the right direction.
<highvoltage> qwertologe: it may be a bit quiet in there today though, today was release day so many people are taking some well deserved rest
<qwertologe> thanks a lot!
<highvoltage> you're welcome
<highvoltage> oops, s/poing/point/
<broder> dobey: so, are you complaining about source format 3.0 (quilt) or udd's handling of it? for the latter, it always seemed reasonable to me that the udd branch match what you get if you apt-got source'd the package, so given that, the patches *should* be applied
<broder> i'm more ambivalent about 3.0 (quilt) applying patches by default
<slangasek> the problem is that 3.0 (quilt) is a real pain to map into VCSes
<slangasek> in that it actually has to be mapped, and no one's doing this yet, including udd
<broder> yeah, that's a reasonable point
<dobey> broder: udd.
<dobey> apt-get source applies patches by default?
<broder> for 3.0, yes
<dobey> ugh
<dobey> broder: then We are complaining about both
<slangasek> dobey: apt-get source applies patches by default if you declare in debian/source/format that you want a 3.0 (quilt) source packages.
<slangasek> -s
<slangasek> if you don't do that, then they're not applied by default
<slangasek> now, the trend and the preference in Debian policy is for having patches applied by default, so that if you want to do things like archive-wide code inspection you don't have to guess what magic target name in debian/rules applies patches
<slangasek> but as long as there are impedence mismatches like this one, it's reasonable to continue using quilt by hand in debian/rules
<broder> i'd also argue that it lowers the barrier to entry for new contributors at the cost of making more advanced manipulations a bit more difficult
<dobey> broder: not trying to do advanced manipulation. simply want to make a change, generate a patch, and throw it in debian/patches. but instead, the process is now significantly more difficult.
<broder> dobey: really? i think it's quite easy
<broder> (a) grab the branch
<broder> (b) patch the source
<broder> (c) run bzr bd -S
<dobey> broder: it's easy if you don't mind having insane patch complexity
<broder> (d) quilt rename -P debian-changes-crap my-awesome-patch
<broder> (e) run bzr bd -S again
<slangasek> hum?  bzr bd -S runs in a copy of the tree
<slangasek> so it doesn't spit out the patch for you
<broder> oh, true - fine, debuild -S :)
<dobey> bzr diff -p 1 > debian/patches/42_blah_blah.patch
<dobey> bzr revert
<dobey> bzr add
<dobey> but that's not the problem
<dobey> the problem is that having patches applied in-tree, encourages inter-patch dependencies, which is bad.
<dobey> the more patches you have, the more problematic it is
<bdmurray> slangasek: I'm writing a bug pattern for bug 873397 to prevent further reporting of it
<ubottu> Launchpad bug 873397 in ubiquity (Ubuntu) "installing 11.10 with 3rd party software results in a crash" [Low,Incomplete] https://launchpad.net/bugs/873397
<bdmurray> its just due to load on archive.canonical.com
<slangasek> bdmurray: ah, ok
<slangasek> for p, we should make sure ubiquity fails gracefully
<bdmurray> slangasek: could bug 870643 be related to that one?
<ubottu> Launchpad bug 870643 in flashplugin-nonfree (Ubuntu) "package flashplugin-downloader 11.0.1.152ubuntu1 failed to install/upgrade: wget: unable to resolve host address `archive.canonical.com'" [High,Confirmed] https://launchpad.net/bugs/870643
<slangasek> bdmurray: that doesn't look like an archive-side load issue, just a client-side DNS issue
<jtaylor> hi, can this propsal be denied, it was already merged into -proposed https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/79330
<jtaylor> see https://launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=
<jtaylor> thx
<rye> slangasek, bug in network manager
<rye> slangasek, bug #859373
<ubottu> Launchpad bug 859373 in update-manager (Ubuntu) "flashplugin-installer upgrade failed during Oneiric upgrade" [Undecided,New] https://launchpad.net/bugs/859373
<rye> bdmurray, re: bug #870643
<ubottu> Launchpad bug 870643 in flashplugin-nonfree (Ubuntu) "package flashplugin-downloader 11.0.1.152ubuntu1 failed to install/upgrade: wget: unable to resolve host address `archive.canonical.com'" [High,Confirmed] https://launchpad.net/bugs/870643
<bdmurray> rye: so the string to look for is "NetworkManager.use-user-connections is not registered"
<rye> bdmurray, yes, but it is in syslog/.xsession-errors
<bdmurray> oh well that's lame
<slangasek> so, er, upgrading libnm breaks the running session?
<rye> bdmurray, otoh this may not be the case
<rye> slangasek, yes, confirmed twice during upgrade, wifi definitely dies, i wonder whether dns settings on wired connection are going away too :(
<slangasek> I guess cyphermox just tried it
<james_w> jtaylor, done
<jtaylor> thx
<rye> bdmurray, wait, i may be too fast with this - the apport was able to send the report, right, so that may not be the same
<rye> looking at the duplicates
<rye> bdmurray, hm, maybe that's a real DNS issue in these cases
<rye> but it is a bit suspicious that network fails at the end of installation from livecd, ok, i withdraw my comment, sorry
<dobey> rye, slangasek, bdmurray: there was some weird network issue a minute ago. "apt-get update" gave errors about archive.canonical.com lists here. subsequent apt-get update worked fine though, and apt-get upgrade just worked fine (and still have network)
<dobey> rye: the archive.canonical.com was probably real network issue :)
<bdmurray> right archive.canonical.com is suffering some load issues
<rye> dobey, but DNS... is archive.canonical.com the nameserver for itself :) ?
<dobey> rye: no idea. dig thinks local server is DNS for everything here. :)
<sladen> Laney: I seem to have failed to get to the London party.  Still around in Nottingham?
<SpamapS> pitti: when you're back around.. I see an upload for cups today, but 1.5.0-8ubuntu1 was uploaded 4 days ago.. are we doing a mass release of verified things into oneiric-updates before the 7 day wait period, or do we just treat these SRU's as "business as usual" ?
<RPG-Master> Does anyone here work on BleachBit?
<RPG-Master> I've created a new icon for them and I have no idea how to suggest it/give it to them.
<sladen> RPG-Master: I don't work at Bleachbit.  But if you file it against  http://launchpad.net/ubuntu-branding/+filebug  with a bit more context I can follow it up and see if I can make contact
<RPG-Master> sladen: Is their some way I should do that on BleachBit's Launchpad? Or do matters of icons best go through ubuntu-branding?
<RPG-Master> This is really my first time contributing to anything.
<sladen> RPG-Master: they don't have to.  But at the moment I don't have background information to direct you to a more specific place, and at this stage I'd like to get it in the bug tracker so that it doesn't get lost
<sladen> RPG-Master: if you file the bug, and attach your icon, along with other information about what it should replace then we can look into it
<RPG-Master> sladen:  OK, I will. Thanks for the help. :)
<slangasek> SpamapS: I would not recommend skipping the 7-day waiting period except for OMGkittens issues... if anything, doing so would make it harder to trace regressions to SRUs, coming on the heels of the release
<Laney> sladen: Been at the beer festival, will be there again on Saturday...
<SpamapS> slangasek: ok.. I couldn't remember if we did that for "0-day" SRU's or not.
<RPG-Master> sladen: Here's my bug: https://bugs.launchpad.net/ubuntu-branding/+bug/873750
<ubottu> Ubuntu bug 873750 in ubuntu-branding "Suggested new icon for BleachBit" [Undecided,New]
#ubuntu-devel 2011-10-14
<lamont> doko: any thoughts on bug 873515?
<ubottu> Launchpad bug 873515 in lazr.uri (Ubuntu) "installing python-lazr.batchnavigator renders "import lazr.uri" unusable" [Undecided,New] https://launchpad.net/bugs/873515
 * hyperair groans. irssi is so hard to use now that my alt+` key has been hijacked by unity.
<TheMuso> hyperair: Working here for me in unity-2d.
<hyperair> TheMuso: alt-grave is getting in my way =\
<hyperair> TheMuso: alt-grave is my keybinding for active-window
<hyperair> active_window i mean
<hyperair> and typical unity style, it's beautifully hardcoded inside the code so i can't disable it
<TheMuso> Ah ok.
<pitti> SpamapS: for important ones I think we can be a little more lenient, because a lot more devs are running -proposed as well now and report problems; but in general the standard rules apply
<didrocks> good morning
<dholbach> good morning
<pitti> cjwatson: is someone already merging dpkg? if not, want me to?
<slangasek> pitti: cjwatson has said he's taking care of it
<pitti> slangasek: ok, thanks
<slangasek> as there are bits that need reverting and he knows what they are, I'd wait for him
<cousin_luigi> hello
<siretart> err, do we officially support natty->oneiric upgrades? I was under the impressen not, but bug #859373 seems to imply so.
<ubottu> Launchpad bug 859373 in network-manager (Ubuntu Oneiric) "flashplugin-installer upgrade failed during Oneiric upgrade" [Medium,In progress] https://launchpad.net/bugs/859373
<geser> siretart: how else should an upgrade from natty to oneiric be done?
<cousin_luigi> bbl
<RAOF> siretart: We don't support maverick?oneiric upgrades (without going through natty), but how else would natty users be able to update? :)
<siretart> geser: err, sorry. not enough coffee yet, today.
<siretart> I mixed the order of natty and maverick
<geser> :)
<pitti> OdyX: cups should already recognize PPDs in /usr/share/ppd/; dh_pyppd putting PPDs into /usr/lib/cups/driver/ sounds seriously wrong, as PPDs are not drivers
<OdyX> pitti: please amend the wikipage, I can't focus on that today (sorry).
<pitti> OdyX: ah, sure
<doko_> lamont, hmm, no, doesn't tell me much
<OdyX> pitti: http://wiki.debian.org/Teams/Printing/RethinkingTheStack fwiw
<pitti> OdyX: right, that's what I'm reading ATM
<OdyX> great; thanks for your proofreading !
<pitti> OdyX: done, left some remarks there; the stuff that I don't commented on looks good to me; thanks!
<doko_> barry, ^^^ bug bug 873515 ?
<ubottu> Launchpad bug 873515 in lazr.uri (Ubuntu) "installing python-lazr.batchnavigator renders "import lazr.uri" unusable" [Undecided,New] https://launchpad.net/bugs/873515
<doko_> lamont, hmm, can't see it on osageorange anymore
<OdyX> pitti: now that I got drawned into looking into this; will Cups look in /usr/share/ppd/compressed/* or only under /usr/share/ppd/ ?
<pitti> OdyX: all subdirs; there are already a few
<OdyX> pitti: hmm. Does it look for "compressed" PPDs ?
<OdyX> pitti: it doesn't seem to, at least here.
<pitti> OdyX: perhaps it additionally needs the /usr/lib/cups/driver/foomatic-db-compressed-ppds driver?
<pitti> OdyX: I had assumed that foomatic-db-compressed-ppds actually shipped somethign like *.ppd.gz
<pitti> but it doesn't seem to
<pitti> so perhaps I misunderstood this package entirely then
<OdyX> pitti: foomatic-db-compressed-ppds is a pyppd-compressed archive of PPDs
<OdyX> pyppd creates a python script with an embedded base64'ed xz-archive
<OdyX> then you can "execute" it to either get the list or extract a specific PPD
<OdyX> that's probably why tkamppeter put the compressed PPDs as "Cups drivers" at the first place.
<tkamppeter> pitti, OdyX, CUPS searches /usr/share/ppd recursively for ready-made PPDs, uncompressed or single PPD file gzipped, it searches /usr/lib/cups/driver/ for executables which are PPD generators ("<excutable> list" has to list all PPDs the generator is capable to generate, <executable cat <PPD UIRI>" generates the requested PPD on stdout), and it searches /usr/share/cups/drv/ for .drv files, which are source files for CUPS' PPD compiler, pp
<tkamppeter> dc. All this CUPS reports as available PPDs (via "lpinfo -m" or equivalent IPP requests from printer setup tools).
<OdyX> tkamppeter: okay, is there a reason "PPD generators" are cups-specific ?
<tkamppeter> OdyX, no. If they do not link against libcups they work perfectly well with no piece of CUPS installed. A non-CUPS printer setup tool (does such a thing exist as an upstream-maintained free software?) has only to find all the PPD generators, and run them with 'list' and 'cat' as described. PPDs itself can be used with non-CUPS spoolers using foomatic-rip.
<OdyX> tkamppeter: couldn't they be shipped under /usr/share/ppd/generators/ and have cups look there then ?
<OdyX> .oO(Especially when the content is not architecture-specific (/usr/lib/). )
<tkamppeter> OdyX, this would require CUPS to be patched, then better symlink to /usr/lib/cups/driver. Another problem is that CUPS produces error messages when anything which is not .ppd or .ppd.gz is in the /usr/share/ppd/ tree.
<tkamppeter> OdyX, how are non-CUPS Debian users setting up printers? Are there special tools which they use?
<tkamppeter> OsyX, and which non-CUPS spoolers are actively maintained and supported under Debian?
<OdyX> tkamppeter: honestly, I don't really know (nor care), but I just feel that putting non-cups-specific PPDs under /usr/lib/ â¦ cups/ is wrong and should be fixed.
<OdyX> tkamppeter: I guess lpr is the only one, but don't know really.
<directhex> hmph. what's the process for debugging audio issues?
<tkamppeter> OdyX, which flavor of lpr, LPRng or some old LPD thingy?
<OdyX> "lpr" was last uploaded as NMU and hasn't evolved since oldstable; "lprng" was maintainer-updated since stable but is "RFA", "gnuspool" is new to wheezy
<OdyX> tkamppeter: that's not important I'd say; what stays is that Debian hasn't taken a decision to go Cups-only (and will probably not), so I'm very fine to drop PPDs in favor of pre-processed drivers, those should just be available (too) under a known place
<tkamppeter> pitti, as you have passed cups and s-c-p to -updates, can you approve the next -proposed packages of cups and s-c-p today? Thanks.
<tkamppeter> OdyX, what is "RFA"?
<pitti> tkamppeter: cups yes; s-c-p is still in proposed; it's not a critical bug and had large changes, so we should wait the full 7 days
<OdyX> tkamppeter: "request for adoption", it's the step before "Orphaned"
<tkamppeter> OdyX, so it means that it is unmaintained and Debian is searching for a maintainer?
<OdyX> tkamppeter: RFA means it's maintained but the maintainer is looking out for someone to take over maintainership (There's no such thing as "Debian is searching" :->)
<tkamppeter> OdyX, looking at downloadable gnuspool releases upstream, it seems that this is the most recent attempt to introduce a new printing system but the upstream authors have already given up again, as there is now one year without new releases.
<OdyX> tkamppeter: yes, and ? My opinion is: if we can do non-cups-specifics, we should.
<tkamppeter> OdyX, OK, so let us move the compressed PPDs into a CUPS-neutral place and symlink them to /usr/lib/cups/driver/
<OdyX> tkamppeter: what about /usr/share/ppd/compressed/ + patching cups to avoid warnings there ?
<tkamppeter> OdyX, would be a solution, pitti, WDYT?
<tkamppeter> OdyX, did you say anything else in the last few minutes? I rebooted after my upgrade to Oneiric.
<OdyX> tkamppeter: no
<jkbys> pitti, could you take a look at bug 873401?
<ubottu> Launchpad bug 873401 in ubuntu-defaults-builder (Ubuntu) "Check disc for defects failed with a iso images built using ubuntu-defaults-image" [Undecided,New] https://launchpad.net/bugs/873401
<pitti> jkbys: I saw it, will have a look at some point
<jkbys> pitti, thank you
<Daviey> Has merges.ubuntu.com been updated for P-Series?
<FourDollars> How to push this patch into SRU of 11.10 ? https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028
<ubottu> Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,In progress]
<tkamppeter> pitti, can accept the proposed SRU for bug 872527? Thanks.
<ubottu> Launchpad bug 872527 in cups (Ubuntu Precise) "InputSlot PPD option generally does not work in CUPS 1.5.x" [High,Fix committed] https://launchpad.net/bugs/872527
<pitti> yes, yes -- I don't run SRUs every hour, sorry
<pitti> tkamppeter: done
<tkamppeter> pitti, thanks.
<OdyX> tkamppeter, pitti: we need to discuss this more in-depth; I'll send a mail to debian-printing@l.d.o CC'ing the maintainers of the various print spoolers we mentionned to gather more opinions.
<lamont> doko_: you may need to reinstall one of the packages inside that chroot again
<lamont> doko_: I don't remember if I left it broken or not
<cjwatson> pitti: I'm a fairly substantial amount of the way through the dpkg merge now
 * doko_ curses the libnih1 use of private glibc symbols
<htorque> hello all! stuff uploaded to oneiric-proposed won't show up in precise, right?
<infinity> htorque: Not by default, but you can request it to be copied over.
<infinity> htorque: Though, usually, you want newer upstream versions in precise anyway.
<htorque> infinity: thanks for the info :-)
<pitti> htorque: in the first days, we'll copy oneiric-proposed to both -updates and precise (as long as the versions are equal and we are still frozen)
<pitti> to ensure we don't drop patches
<infinity> pitti: Yeah, but that "first few days" bit isn't exactly well-documented. ;)
<infinity> It just sort of happens until it stops happening.
<htorque> pitti: i just asked because i wanted to test the -proposed fix for bug 858056 and i'm already on precise on one system (don't ask why :P).
<ubottu> Launchpad bug 858056 in unity-lens-applications (Ubuntu) "Dash - "Apps Available for Download" recommends a program that is already installed" [Medium,New] https://launchpad.net/bugs/858056
<htorque> but the question is answered here: https://launchpad.net/ubuntu/+source/unity-lens-applications/+publishinghistory
<pitti> htorque: ah, I copy stuff to -proposed after verification
<pitti> i. e. at the same time as to -updates
 * apw just tried to upgrade a natty box to oneiric using the popup box from update-manager, and it said that it couldn't do it cause i likely had unresolable package problems, any idea how to find out what the underlying packages even are
<mvo> apw: could you pastebin your /var/log/dist-uprade/apt.log please?
<apw> mvo, http://paste.ubuntu.com/707977/ ... note i am doing a dist-upgrade now to the latest natty packages to ensure its not related to that, just in case that has changed the log
<sd_ubuntu__> Hi! I'm new at ubuntu community. Could I start a work with you?
<OdyX> sd_ubuntu__: as in all free software communities: find an itch to scratch, then scratch it.
<sd_ubuntu__> OdyX: but I read the code of conduct and it should collaborate. I just wanna help in something free that I received
<sd_ubuntu__> OdyX: but I'd like to know where it nedds more help
<sd_ubuntu__> (sorry if my english is not good)
<sd_ubuntu__> *we should collaborate
<apw> sd_ubuntu__, there really is everything available, and all of it needs help, so it really is about what interests you as you won't stay doing something for nothing that you don't like doing
<sd_ubuntu__> apw: ok. I'd like to packaging ...
<mvo> apw: so it seems its rather unhappy about the flashplugin, if you provie the /var/log/dist-upgrade/*apt-clone* file I will try to reproduce and see if I can find a global solution
<sd_ubuntu__> apw: but I think is a work to do together...
<apw> mvo, on it
<apw> mvo, in pm
<mvo> thx
<Daviey> slangasek: We are getting a flurry of bugs regarding the samba issue.
<jdstrand> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<Daviey> slangasek / infinity: 28 dupes, bug 862129
<ubottu> Launchpad bug 862129 in samba (Ubuntu) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<bdrung> how long will precise be frozen?
<cjwatson> bdrung: shouldn't be too much longer, but dpkg does need to build
<bdrung> cjwatson: ETA? hours or days?
<cjwatson> dunno
<cjwatson> not really in the mood for a mad rush and time estimates and all that at the moment, after the release sprint
<cjwatson> apw: are you folks expecting to upload a new linux-libc-dev before precise opens for general uploads?
<apw> cjwatson, i was expecting a kernel upload shortly, but i am currently unsure if the current kernel is tested
<apw> i assume that the tool chain as it is now, wasx built with the old one too
<cjwatson> yes
<cjwatson> well, um
<cjwatson> thinking about it I don't know what was in the PPA it was built in
<cjwatson> https://launchpad.net/~ubuntu-toolchain-r/+archive/ppa doesn't have a kernel
<cjwatson> and no extra dependencies there, so yeah, it would have built against oneiric's kernel
<apw> cjwatson, in theory at least linux-libc-dev is backwards compatible so i don't think it matters ...
<cjwatson> I don't mind leaving it for later
<apw> cjwatson, yeah i don't think there is sufficient difference to worry about, and we'll have cycles round compiler and kernel in the next weeks
<apw> we should have a get together at UDS with doko to work out what the best order is and how we can achieve that in combination with the toolchain pre-preparation
<cjwatson> bdrung: ... also I plan to knock off early today and vanish for the weekend, so if we're opening, somebody else is going to do it :-)
<pitti> bdrung: note that you can already upload, if you want to get stuff off your hard disk
<bdrung> pitti: will that end up in the new queue?
<pitti> bdrung: no, in unapproved
<pitti> bdrung: https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<bdrung> ah, ok
<pitti> bdrung: we'll flush that once precise opens
<pitti> bdrung: unless it's actually NEW, of course (state=0)
<ntr0py> Is there a way to get Gnome3 to use BGR instead of RGB subpixel rendering?
<debfx> pitti: would you approve bug #873396 for a SRU?
<ubottu> Launchpad bug 873396 in kubuntu-default-settings (Ubuntu Precise) "akonadi shouldn't be launched on startup" [Undecided,New] https://launchpad.net/bugs/873396
<lamont> is there some way under compiz to convince it that just because I launched a terminal window, does not mean that I want it to have focus?
<doko> kees, I don't understand yet https://launchpadlibrarian.net/82793515/buildlog_ubuntu-precise-armel.eglibc_2.15~pre1-0ubuntu1_FAILEDTOBUILD.txt.gz
<doko> from https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+packages
<kees> doko: hunh. looks like a static build? the _guard is the value that the stack protector looks for when checking for overflow, which means it wasn't included in the linkage...
<kees> doko: I wonder what changed
<doko> kees, yes, but anything is built with -fno-stack-protector -U_FORTIFY_SOURCE
<kees> doko: yeah, that's really odd
<kees>  /build/buildd/eglibc-2.15~pre1/resolv/gethnamaddr.c:974: undefined reference to `__stack_chk_guard'
<kees> what's actually on that line of the code?
<kees> I wonder if they started using the _guard for non-stack purposes
<doko> and apparently it's ARM only
<davmor2> any audio guru's about?  I have a huge issue on oneiric fresh install,  skype/mumble/voip I sound like a chipmunk worked perfectly in natty :(
<directhex> dholbach, off the top of your head, do you know what software is used for the irc bot during UDW? the one that collects questions in one channel, which the session leader can then page through & have show up in the moderated channel?
<dholbach> jussi, ^ do you know?
* cjwatson changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<cjwatson> have fun
<cjwatson> oh dear, sync-source is busted
<pitti> yay precise
<Daviey> erm, is -changes mailing list working properly?
<Daviey> Ah, i'm being a bit unfair, it was only shown 9 mins ago.
<Daviey> Accepted
<jussi> directhex: I dont know, but nhandler did a lot of work with it. I suspect it was rbot, but I could be totally off with that. Im pretty sure its not supybot though.
<frewsxcv> is there any reason why ubuntu hasn't updated their releases in their rsync mirror?
<cjwatson> frewsxcv: could you be more specific?
<dobey> should We bug someone to get a couple SRUs that were supposedly going to be 0-day, copied over to oneiric-updates? :)
<cjwatson> frewsxcv: I'm not seeing anything obviously out of date ...
<frewsxcv> http://mirrors.kernel.org/ubuntu-releases/oneiric/ pulls from rsync://<country-code>.archive.ubuntu.com/releases
<frewsxcv> as does my mirror http://mirrors.calpoly.edu/ubuntu-releases
<cjwatson> ubuntu-releases should be pulling from rsync.releases.ubuntu.com, not rsync.archive.ubuntu.com
<cjwatson> I have no idea what <countrycode>.archive.ubuntu.com/releases might happen to point to :-)
<cjwatson> the primary rsync mirror of releases definitely has 11.10 on it
<frewsxcv> cjwatson: what is the rsync module for rsync.releases.ubuntu.com
<cjwatson> releases, I believe
<cjwatson> #ubuntu-mirrors might be able to help more with mirroring specifics
<cjwatson> (since there may be something better than you pulling directly across the Atlantic; I can't see what us.releases.ubuntu.com::releases/ currently has since it's hit its client limit
<cjwatson> )
<frewsxcv> thanks cjwatson
<smoser> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser, jdstr
<smoser> TheMuso, mdeslaur i think that merge request at https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/fix-duplicate-battery/+merge/67466 should be moved to 'merged', right?
<smoser> as it seemed to be only relevant for natty and is fixed there.
<mdeslaur> smoser: yep
<mdeslaur> smoser: I don't have the required magic wand to change that
<smoser> nor do i
<mdeslaur> :(
<smoser> i guess maybe that is bug 728012
<ubottu> Launchpad bug 728012 in Launchpad itself "ubuntu developers are not able to reject merge proposals on official packaging branches they can upload to" [High,Triaged] https://launchpad.net/bugs/728012
<mdeslaur> smoser: ah, yes, thanks for the bug link
<jdstrand> @pilot out
<jdstr> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<Quintasan> pitti: Can I have you accept two uploads for bug #872506 ?
<ubottu> Launchpad bug 872506 in kde4libs (Ubuntu Oneiric) "SRU tracking bug for KDE 4.7.2" [Undecided,Fix committed] https://launchpad.net/bugs/872506
<jdstrand> Quintasan, pitti: hold on on that one
<jdstrand> this needs patches for a security update
<Quintasan> jdstrand: Which one exactly?
 * jdstrand is getting them
<Quintasan> jdstrand: Which package needs patches? https://wiki.kubuntu.org/Kubuntu/Ninjas/Packaging <- we have this many :)
<jdstrand> kde4libs
<Quintasan> I see
<debfx> jdstrand: which security update? bug #857437?
<ubottu> Launchpad bug 857437 in kde4libs (Ubuntu) "Embargoed security issue (until 10/3)" [Undecided,In progress] https://launchpad.net/bugs/857437
<jdstrand> debfx: yes
<jdstrand> I attached the debdiff I am using for 4.7.1 to the bug
<debfx> jdstrand: I'm pretty sure the fix is included in 4.7.2
<jdstrand> I checked the debdiff in LP. let me recheck
<Quintasan> quick google shows that 4.7.2 has it
<jdstrand> hmm, http://launchpadlibrarian.net/82652015/kde4libs_4%3A4.7.2-0ubuntu1_4%3A4.7.2-0ubuntu2.diff.gz is less than complete
<jdstrand> Quintasan, debfx: ah, well if it has them, please respond to my comment in the bug and ignore me :)
 * Quintasan researches futher
<debfx> jdstrand: that's just a follow-up upload, http://launchpadlibrarian.net/82564105/kde4libs_4%3A4.7.1-0ubuntu3_4%3A4.7.2-0ubuntu1.diff.gz is the 4.7.1->4.7.2 diff
<jdstrand> oh, I missed that
<jdstrand> let me look
<jdstrand> ok, yes, it has it
<jdstrand> pitti, debfx, Quintasan: ignore me. 4.7.2 is fine
<broder> slangasek: oh geez. i think i figured out what vmware is doing that's breaking everything
<broder> http://paste.ubuntu.com/708153/
<slangasek> broder: right, yes, that was actually clear to me; sorry for not communicating it
<broder> slangasek: ok; i didn't know if you had seen the actual code in question or not. unfortunately, i don't see any good way to trick the installer into doing something reasonable
<slangasek> (the nature of the damage to rc6.d was apparent on first glance)
<slangasek> no, there's no good way to trick it
<slangasek> it needs to be stabbed in the face
<slangasek> calling insserv is not an acceptable thing for any package to do
<broder> will my system still function if i move the insserv binary out of the way?
<slangasek> AFAIK yes
<slangasek> since insserv is only meant to be called by update-rc.d, and only if the .legacy-bootordering flag is *not* set
<SpamapS> hmm... since ScottK is taking a break, who will take charge over backports?
<Laney> the rest of the team
<Laney> but it would be good to have another administrator
<Laney> someone needs to make oneiric-backports ...
 * Laney does
<Laney> there we go
<smoser> pitti, wonder if you're ok with me uploading https://code.launchpad.net/~evfool/jockey/stringfixes/+merge/73737 just to finish it off ?
<smoser> actually, never mind. ill let you handle that.
#ubuntu-devel 2011-10-15
<DoctorPepper> hi guys !!
<DoctorPepper> agateau:  are you awake ?
<jsimmons> So what's the deal with pkg-config and lib/lib64
<jsimmons> should .pc files not be installed underneath there, actually is lib64 used at all anymore?
<htorque> good morning, everyone! can anyone explain to me, why the package 'emerald' has been removed from oneiric due to FTBFS, when that version seems to have been successfully built?
<htorque> see https://launchpad.net/ubuntu/+source/emerald/0.8.8-0ubuntu1
<jbicha> htorque: bug 831111
<ubottu> Launchpad bug 831111 in emerald (Fedora) "emerald version 0.8.8-0ubuntu1 failed to build in oneiric" [Undecided,New] https://launchpad.net/bugs/831111
<htorque> jbicha: oh, so something *after* that upload changed in oneiric that broke emerald?
<jbicha> htorque: yes, quite a few FTBFS issues are for packages that did build at one time
<htorque> jbicha: k, that makes sense. just never have seen a package getting kicked out because of that before. thanks!
<valavanisalex> Hi All, just wanted to check that the new Debian package of espresso will auto-sync into Precise.  There was an old Ubuntu package with the same name, that was deleted long ago: https://launchpad.net/ubuntu/+source/espresso/+publishinghistory
<tumbleweed> valavanisalex: It's not entirely automatic, the archive admins can review a list of new packages in Debian and select to sync the ones they want. They'll probably notice there was a different package previously published, and so sync it /me waits for a more complete reply from an archive admin
<valavanisalex> tumbleweed: Thanks... so should I file a sync request and subscribe archive admin, or do I just wait?
<tumbleweed> wait and see, unless you have any particularly ugent desire to see it synced
<valavanisalex> tumbleweed: OK, I'll wait and see.  It would be nice to have it, but not desperately urgent.  I'll file a sync request in a few weeks if I need it.  Thanks for your help
<tumbleweed> broder: we now have all pockets in the UDD ubuntu_sources table: http://paste.ubuntu.com/708481/
<tumbleweed> (not that that's the query you actually want to use, of course)
<Daviey> Does syncpackage not attribute the requestor?  Isn't this kinda bad in situations where a ubuntu delta is dropped?  There is no accountability.
<Daviey> (overiding the upload requires --no-lp)
<bdrung> Daviey: it does not yet  attribute the requestor
<bdrung> Daviey: they appear on https://launchpad.net/~bdrung/+synchronised-packages , but not on https://launchpad.net/ubuntu/+source/mozilla-devscripts/0.29
<wgrant> Daviey, bdrung: The data is stored now, but not yet exposed in the UI except on +synchronised-packages.
<spartan-11510> Hi
<spartan-11510> i've a little question
<Snicksie> hi spartan-11510 :) just ask :p
<spartan-11510> In C how i must make for launch a program but i need to detach of the terminal
<spartan-11510> Sorry for my english
<spartan-11510> because if i fork( after i've zombie
<spartan-11510> maybe is'nt the good channel bt i think you can help me
<stgraber> spartan-11510: http://www.enderunix.org/docs/eng/daemon.php is probably a good starting point
<spartan-11510> i'm forced to use daemon ?
<spartan-11510> i know this way but my program would be finish a day...
<stgraber> by the way #ubuntu-devel is for the development of ubuntu itself not for software development on ubuntu
<spartan-11510> sorry
<stgraber> you can also start it in the background
<jtaylor> you might also want to look at the screen or nohup programs which detach programs from the terminal
<spartan-11510> in fact my programm launch a kate or gedit but if the user want to close terminal he can't
<stgraber> indeed. Sorry, I'm typing a lot slower than usual, on my cell phone...
<spartan-11510> but i think i will make a execv with nohup
<spartan-11510> thank you for your help
<spartan-11510> And another question this one on this channel. What's appenned on this channel? i've never see chatting
<stgraber> we mostly talk in there when we work- not much over the weekend
<spartan-11510> ok
<tumbleweed> a large chunk of the ubuntu developers work for canonical, and want their weekends to themselves :P
<stgraber> not all of us :) some still monitor IRC outside of work
<stgraber> but indeed the weekend just after release tends to be quiet
<nigelb> getting over the hangover and all that :P
<stgraber> yeah... :)
<stgraber> though the hardest was friday morning :)
<nigelb> heh
<nigelb> I always imgained the release team sleeping Thursday to Monday :P
<nigelb> *imagined
<stgraber> if only... we were all bsck at the office at 9am...
<nigelb> Respect.
<stgraber> *back
<sladen> was that an ivanka?
<nigelb> drat
<nigelb> missed her.
<sladen> spartan-11510: 48 hours after release.  Everyone (regardless of employer) is probably dead
<broder> tumbleweed: cool, i'll play with it some, though the query you're making is not exactly the one i want to make
<tumbleweed> broder: yeah I know :)
<broder> even though it would be really slow to run, i think it would be much faster to just build the report in lplib
<broder> faster in terms of development
<tumbleweed> yeah, sometimes I can spend hours trying to do what I want in SQL. I find it har dto think in
<broder> does udd have publishing history or just current state?
<tumbleweed> we have publishing history, but not for security, because backports uploads don't get announced on a mailing list
<tumbleweed> I think Laney needs to write a lplib based importer for history
<broder> i guess you could probably do it in reverse - find all packages in backports pockets whose original version hasn't been superseded
<tumbleweed> err "not for backports"
<tumbleweed> that sounds like the way to go
<broder> anyway, maybe i'll try to write something once i'm better caffeinated
<MNichie> At risk of being completely off-topic, I have general question about Ubuntu development:  Some open source projects have a system where users can donate resources and tie bug-fix requests to the donation.  Does Ubuntu offer anything like this?  This is one bug in Unity that has been confirmed since April, but it has never been assigned to a dev.
<penguin42> MNichie: You could try asking canonical - see www.canonical.com
<mull> Hi, does anyone happen to know how large a complete mirror of oneiric is?
<mull> ( https://wiki.ubuntu.com/Mirrors doesn't mention anything newer than Lucid )
<tumbleweed> mull: my rule of thumb: 50G per architecture per release (very very innacurate, because some packages are shared between architectures and releases)
<mull> tumbleweed, are you including src in your estimate?
<tumbleweed> mull: no, I count that as another arch for those heuristics
<mull> ok
<mull> thanks for the data point
<tumbleweed> if you want to know exactly how big it is, try and debmirror it with --verbose, it'll tell you how much it wants to download
<SpamapS> hrm something broke my resume from suspend in the last week of 11.10
 * SpamapS guesses nvidia-current is to blame
<DoctorPepper> hi guys !!!
 * penguin42 shakes DoctorPepper
<DoctorPepper> agateau:  are you here ?
#ubuntu-devel 2011-10-16
<Bijanbina> hi every body
<micahg> there seems to be a weird delay with syncs going to -changes now
<tumbleweed> LP doesn't seem to know the date that oneiric was released in distro_series.datereleased
<DoctorPepper> agateau:  are you here ?
<Daviey> wgrant: How can i check to see who did a sync based on a package, rather than looking at a person?
<tumbleweed> Daviey: you can't yet. bug 861488
<ubottu> Launchpad bug 861488 in Launchpad itself "Mention sync requester on package version page" [High,Triaged] https://launchpad.net/bugs/861488
<Daviey> tumbleweed: Gah, i hoped there was /something/.  /me screenscrapes.
<tumbleweed> precise-changes will have the information
<Daviey> tumbleweed: have you checked?
<Daviey> sync's aren't showing on -changes.
<tumbleweed> they were early, but much delayed
<tumbleweed> *earlier*
<Daviey> tumbleweed: I sync'd socat >30hrs ago.. it's not on -changes.
<lamont> unity login: how do I get it to stop showing all the users on the machine?
<Philip5> maybe slightly off topic but anyway, after i updated to oneiric and use pbuider and make a new container with create then is pulls repositories from both i386 and amd64 sources even though i create a amd64 chroot. anyone experienced this too?
<debfx> Philip5: that is expected behavior, see https://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes#A32-bit_compatibility_on_amd64_systems
<Philip5> debfx: aha, but can i force it to just use one type of arch repositories?
<debfx> Philip5: you can disable it by commenting out the line in /etc/dpkg/dpkg.cfg.d/multiarch
<micahg> Philip5: it's supposed to use both now in an amd64 chroot I think
<Philip5> maybe i just have to setup my local repository to use both too then
<Philip5> if this is the new way to do it
<geser> lamont: try "greeter-hide-users=true" in the [SeatDefaults] section in /etc/lightdm/lightdm.conf
<geser> lamont: http://wiki.ubuntuusers.de/Lightdm has a list of configuration options (the page is in german; don't know of an english one)
<yanom> this is the Ubuntu developers channel right?
<wgrant> Daviey, tumbleweed: Ah, it's exposed through the API already, it seems.
<wgrant> eg. https://launchpad.net/api/devel/ubuntu/+archive/primary/+sourcepub/2002013
<wgrant> creator_link
<tumbleweed> ah, so *that's* what crator_link is. The docs aren't very clear :P
<wgrant> tumbleweed: pub.package_creator created the package, pub.creator created the publication.
<wgrant> Seems somewhat slightly clear :)
<tumbleweed> except that creator_link is only filled out on syncs
<wgrant> Yes, uploads/overrides don't populate it yet, unfortunately. It's only a few weeks old.
<tumbleweed> wgrant: While we're talking LP: I don't know who where the date was supposed to come from, but oneiric's datereleased (via API) is None
<Daviey> wgrant: ah, wonderful - thanks
<DoctorPepper> agateau:  are u  here ?
#ubuntu-devel 2012-10-08
<infinity> soniah: None of those changes look Ubuntu-specific in the least, have you proposed the patch to the Debian maintainer?
<infinity> soniah: He actually literally JUST did an upload to Debian, and he's on IRC right now as jamessan.
<soniah> infinity - no - I didn't realise I should push it to Debian.
<infinity> soniah: We try to make sure all our (non-Ubuntu-specific) patches end up pushed to Debian, so it really makes sense to just start there, IMO.
<infinity> soniah: Makes sense doubly-so right now, since Ubuntu is in a freeze leading up to a release, so uploading for cosmetic fixes seems less likely.
<soniah> infinity: I'm just learning IRC - how would I contact jamessan? I see he's on lindbohm.freenode.net
<sladen> soniah: /query jamessan
<soniah> infinity: thanks!
<soniah> infinity: he's away, but thanks anyway. All part of the learning, that's why I'm starting packaging :-)
<infinity> soniah: Well, the "correct" way to contact him about it would be to file a Debian bug with your patch, and rationale. ;)
<infinity> soniah: I was just suggesting IRC, since I knew he was quite recently around.
<infinity> soniah: That said, most people like him probably read their queries when they wander back to their computers, so it doesn't hurt to contact him even if he's marked "away".
<infinity> soniah: And happy learning.  Always good to see new blood to replace the old folks like me. :P
<Darxus> What needs to be done to get this sensors-applet package in the quantal archives?  It got a FFE, and was apparently uploaded to New:  Bug #1049343
<ubottu> Launchpad bug 1049343 in sensors-applet (Ubuntu) "FFe: Un-blacklist and merge sensors-applet 3.0.0-0.2 (universe) from Debian testing (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1049343
<infinity> Darxus: It needs reviewing in the queue.  I'll get there.
<Darxus> infinity: Thanks.
<Darxus> I don't suppose there's any of that process I can see?  A list of the contents of the queue?
<Darxus> Ooh https://wiki.ubuntu.com/ArchiveAdministration
<Darxus> https://launchpad.net/ubuntu/quantal/+queue  Nice.
<dholbach> good morning
<pitti> james_w: thanks!
<pitti> Good morning
<soren_> infinity: Thanks for doing the qemu-kvm rebase for me.
<infinity> soren_: No big deal.  I didn't want it to get forgotten after being superseded.
<infinity> soren_: (It was a bit of a sore point for me, as my eglibc SRU had just been superseded by a security update around the same time)
<soren_> infinity: Cool. The first day or so after uploading it, I checked the unapproved queue every once in a while to see if it moved, but eventually I got distracted.
<mnencia> Is this the right channel to ask a question about Debian Unstable -> Ubuntu  package sync process?
<geser> yes
<mnencia> I'm the Upstream of a package which was just accepted in Unstable (barman) . Given that it's an application for PostgreSQL disaster recovery (no interaction with other applications) there is any chance to have it in universe for the upcoming release or i need to setup a private repository for make it available to users?
<geser> mnencia: given that we are short before the release, it's too late to get it directly into the next release but should fit fine into the backports repository
<mnencia> geser: ok thanks
<infinity> Actually, wait.
<infinity> mnencia: Completely new source, doesn't affect any others?
<mnencia> completely new. only has a dependency (python-argh) which is also completely new
<Laney> Given pre-release backports is already a thing, you can use that
<infinity> Laney: Yeah, but syncing new stuff into universe that has no effect on other packages is perfectly reasonable, IMO.
<infinity> Also, lolz to "python-argh".
<infinity> Looks like I named it.
<Laney> Not massively bothered, but this is the kind of thing that backports is best at (and doesn't involve getting exceptions from the RT)
<Laney> so, go ahead with whichever way you fancy given that infinity will give you the FFe :P
<infinity> True, but the RT is well-represented right here (and I'm about to give it an exception).
<Laney> and NEW it too!
<infinity> With bonus-points for awesomely-named packages.
<infinity> I'll hold off on barman until LP knows about the current version in Debian, but I synced python-argh.
<infinity> mnencia: ^^
<mnencia> infinity: thanks
 * ogra_ glares at -changes ... there is a package called python-argh ? 
<ogra_> tsk
<Laney> ARGH!
<ogra_> :)
<infinity> ogra_: I intend to write python-blah, python-bleh, and python-fuck, and it will match the naming scheme of the majority of my test .c files and scratch directories.
<ogra_> the latter wont comply with family friendliness though
<infinity> I'll claim it's French.
<ogra_> so you support seb128's secret strategy ?
<infinity> No, but that's because technical French sounds silly.
<infinity> If I could get my pretty prose in French, but my technical writing in English, I'd probably be happy.
 * pitti mumbles tÃ©lÃ©charger
<infinity> (Or the latter in German, even)
<seb128> did you try technical German before says that?
<seb128> saying
<cjwatson> My test files and scratch directories tend to be called things like x, y, and t
<cjwatson> I think there's something in policy about single-character names :)
<pitti> heh, I use /tmp/x, /tmp/y for files, or /tmp/p for patches
<GunnarHj> jamespage: Hello! Could you please help with a merge of a simple patch clean-up MP?
<GunnarHj> jamespage: https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/drop-patch-43/+merge/128371
<infinity> My names tend to be representative of how frustrated I've become with a problem.
<jamespage> GunnarHj, sure
<pitti> infinity: doesn't that collide with lazyness at some point?
<infinity> Eventually, they lose all semblance of creativity and just start repeating expletives.
 * jamespage forgot to pilot out - but had time
<jamespage> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<GunnarHj> jamespage: great
<GunnarHj> jamespage: Sometimes you are lucky. ;-)
 * dupondje is sad about the fact quantal doesn't seem to be able to open his new Samsung S3 :(
 * dholbach hugs jamespage
<jamespage> GunnarHj, any particular reason for merging those two patches?
<jamespage> they seem quite unrelated
<jamespage> morning dholbach!
<dholbach> hey :)
<dupondje> pitti: as you seem to be the gvfs guy, any idea's on how to debug gvfs not able to mount my Samsung S3 (Android MTP) ?
<dupondje> also see https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422
<GunnarHj> jamespage: It started with an attempt to build the package without patch 43, and then I discovered that patch 48 didn't apply. Well, to the purpose they are unrelated. Just an attempt to simplify things.
<pitti> dupondje: doesn't it provide mass storage?
<ubottu> Launchpad bug 903422 in udev (Ubuntu Precise) "Mount / Provide access to Android 4.x (Ice Cream Sandwich and above) MTP devices" [High,Confirmed]
<dupondje> pitti: Android 4+ doesn't have mass storage anymore
<dupondje> only PTP or MTP
<pitti> dupondje: gvfs doesn't support MTP; the closest thing is PTP through the libgphoto backend
<pitti> dupondje: I have CyanogenMod 9, which is Android 4 (ICS), and mass storage works fien
<pitti> fine
<dupondje> libgphoto2 doesn't support MTP ?
<pitti> Rhythmbox does, though libmtp
<pitti> but that's not gvfs
<dupondje> pitti: seems there are apps to re-enable mass storage on ICS
<pitti> dupondje: I think listing files etc. should be possible through libgphoto, but ICBW
<dupondje> but default is MTP
<pitti> I dont' have any MTP devices, so I never tested thsi
<pitti> I only have a PtP digicam
<pitti> dupondje: ah, maybe cyanogenmod has that by default then
<dupondje> Well, with PTP I can see my files on the device itself, SD card shows empty
<dupondje> and with MTP, it sees the device, shows in nautilus, but unable to mount it
<pitti> dupondje: do you see it in 'gphoto2 --auto-detect'?
<pitti> dupondje: if not, try running it as root and see if that makes a difference
<jamespage> GunnarHj, so the setproxy call is no longer required?
<dupondje> pitti: yes it shows
<pitti> dupondje: gphoto2 --list-cameras at least lists Â»Samsung Galaxy Nexus/Galaxy S i9000/i9250, Android 4.0 updatesÂ«
<dupondje> that also matches the S3
<GunnarHj> jamespage: you mean set_locale().
<jamespage> GunnarHj, yeah - sorry - brain misfired then
<jamespage> I think I see
<GunnarHj> jamespage: In standard ubuntu it should be disabled - has been for a while.
<jamespage> GunnarHj, patch 48 completely removes that function  - I see now
<dupondje> pitti: but gphoto2 --summary fails for example
<pitti> dupondje: so it seems libgphoto2 doesn't handle it then
<GunnarHj> jamespage: But if you want to use upstream GNOME interface for language/locales settings it's needed.
<pitti> dupondje: does it work any better in Rhythmbox? that uses libmtp, which should be more suitable
<pitti> dupondje: at least for the music part?
<dupondje> It gives failed to lock usb I tought :) (not on my quantal pc atm)
<dupondje> pitti: well, mainly need it to move my pics I made on my phone :)
<seb128> can you browse over bluetooth as a workaround?
<dupondje> seb128: haven't tested that. Tested to send the pics over bluetooth to my pc, but it fails also :(
<jamespage> GunnarHj, this is just housekeeping right?
<GunnarHj> jamespage: Indeed.
<mvo> barry, pitti: can I ask you for your opinion about bug #1058038? the issue is that dbus activated aptd is runnig without lang/language from the auto-activation. that means that the default encoding for the filesystem is "ascii" instead of something more sensible like utf-8. python sets this once that interpreter startup apparently so any subsequent changes to env will not get honored afaict. so it seems we can either set the default system lan
<mvo> guage on dbus activiation or add a wrapper around aptd that sources /etc/default/locale - wdyt?
<ubottu> Launchpad bug 1058038 in aptdaemon (Ubuntu) "<class 'UnicodeEncodeError'>: 'ascii' codec can't encode characters in position 18-25: ordinal not in range(128)" [Medium,Confirmed] https://launchpad.net/bugs/1058038
<pitti> mvo: yeah, that's something that annoys me in Python 3 as well
<pitti> mvo: I fought with this too often, and as a consequence I now always open those kind of files in binary mode and call .decode('UTF-8') explicitly
<pitti> mvo: if you don't need py2 suport, you can use open('file.txt', encoding='utf-8')
<cjwatson> Simpler to open them with encoding="UTF-8")
<cjwatson> Yeah
<pitti> mvo: but thaht doesn't work with py2
<cjwatson> There are workarounds for that if you need them
<pitti> 'rb' and .decode('UTF-8') works everywhere
<cjwatson> Cumbersome as hell though :)
<pitti> *nod*
<cjwatson> Any way we can pass the language across dbus activation?
<cjwatson> er, locale
<pitti> but as aptdaemon still builds a py2 package, it might be unavoidable
<mvo> pitti, cjwatson: just to double check, will that work with utf8 *filenames* as well? I get e.g. os.stat() errors for a utf8 encoded filename when running without LANG/LANGUAGE on python startup
<pitti> mvo: not sure, but I don't think it will
<pitti> I'm not aware of a way to pass the client locale to the activated d-bus service
<pitti> and either way that wouldn't make sense, as the service is already running when the next client calls (which might have a different locale)
<pitti> a feasible thing might be a SetLocale() d-bus method?
<mvo> pitti: well, I just need it to have a sensible sys.getdefaultfsencoding()
<GunnarHj> jamespage: Simply to make that alternate build a little easier. If you approve the MP, those who need the set_locale() call can just add it. https://launchpad.net/~gunnarhj/+archive/misc/+sourcepub/2704893/+listing-archive-extra
<mvo> pitti: so that this is set to utf-8 instead of ascii so that stuff like os.stat() works (and open() too)
<cjwatson> There really needs to be a sys.setdefaultencoding()
<mvo> pitti: its probably really a bug in python as changing locales apparently never changes the filesystem encoding, I will ask barry about it
<pitti> mvo: my gut feeling at this point of the release cycle is to just set it to UTF-8
<mvo> cjwatson: yeah
<pitti> mvo: that will at least not break any case that currently works (with ASCII default), and we never really supported non-UTF8 locales in Ubuntu anyway
<mvo> pitti: I tend to agree, not sure how much upstream will like that though
<pitti> mvo: and perhaps for trunk/r-cycle add a SetLocale() method?
<cjwatson> Or else there needs to be a way to break the caching when we change Python's locale at run-time
<mvo> pitti: but I think that its a much more sensible defalt than ascii
<cjwatson> That might be a good idea anyway
<mvo> cjwatson: yeah, that would be the cleanest I think, ensuring this is reset on setlocale()
<pitti> yeah, a locale.setlocale() call ought to change the fs encoding, too
<mvo> ok, I can look into that
<pitti> just saying that if all else fails, hardcoding utf-8 shoudl avoid 99% of the problems with a really trivial/safe patch?
<pitti> (past beta2 and all that..)
<jamespage> GunnarHj, OK - so I commented on the merge pre your last comment in channel
<jamespage> GunnarHj, I think the housekeeping makes sense but I indicated it should be deferred
<mvo> pitti: the patch for this is probably trivial, its just that I'm slightly concerned about upstreams reaction to it, but +1 for trying it
 * mvo will have lunch first and look at it afterwards
<tkamppeter> I have a problem with Avahi, bug 1059286, this is a major issue for the release and it seems that no one had a look at it yet.
<ubottu> Launchpad bug 1059286 in avahi (Ubuntu) "avahi-daemon takes 100% CPU right after boot and at every restart of CUPS" [Critical,New] https://launchpad.net/bugs/1059286
<jamespage> GunnarHj, but it sounds like you need it for your alternate build right?
<seb128> tkamppeter, nobody is maintaining avahi in Ubuntu...
<tkamppeter> Is Avahi serving for any essential functions in a Ubuntu desktop system?
<tkamppeter> I know that CUPS uses it to broadcast printer info (mainly to Apple clients) and to discover network printers. Is it used for anything else?
<seb128> tkamppeter, it's use for services discovery (music in rhythmbox, shares in nautilus)
<pitti> pulse can use it to discoover remote audio sources/sinks, and RB for remote DAAP music shares
<GunnarHj> jamespage: Yes, it would be nice.
<pitti> as well as Telepathy's salut module (talking to other computers on same network)
<jamespage> GunnarHj, in which case it needs better justification and ideally a bug ref in the changelog
<jamespage> remember the release team have to review every upload to quantal
<jamespage> so it needs to be made clear as to why this change is required.
<tkamppeter> pitti, and this functionality can get compromised by Avahi blowing up all the time.
<GunnarHj> jamespage: Ok, it makes sense to me.
<GunnarHj> jamespage: I'll submit a bug where I explain the reason behind the 'clean-up'. Thanks for your time!
<jamespage> GunnarHj, np
<tkamppeter> pitti, is apport using avahi? Now I have both avahi-daemon and apport spinning up (now I know why one needs a quad core CPU).
<dupondje> pitti: just chatting with libgphoto2 dev's and seems like thing may be improved in 2.5.0 version. But I guess its way to late for that now :)
<pitti> tkamppeter: no, it's not
<pitti> dupondje: you could try building it from source and testing it with the gphoto2 command line tool? If it works, then perhaps there's an upstream commit or two to backport
<tkamppeter> pitti, avahi-daemon only spins up if you have very many queues (in my case 17), so the problem affects users who want to set up a print server. A workaround which works for me is having avahi-daemon always running under strace and shooting the log to the moon (/dev/null). Perhaps we should do this in Quantal.
<pitti> tkamppeter: running under strace is hardly a solution :)
<pitti> tkamppeter: does it keep using 100% CPU forever, or just for a few seconds until it announced all its queues?
<tkamppeter> pitti, it is a workaround, not a fix.
<pitti> tkamppeter: does it stop spinning when you stop cupsd?
<pitti> i. e. is it cups constantly telling avahi about printer queues, or is it avahi itself?
<tkamppeter> pitti, it keeps the 100% forever, even after stopping CUPS.
<pitti> tkamppeter: some debugging ideas: attach strace to a spinning avahi-daemon;watch the console when you start avahi-daemon in a terminal
<seb128> use gdb to see if you get details about what it's spinning on...
<tkamppeter> pitti, I already did and attached the result to the bug report. See bug 1059286.
<ubottu> Launchpad bug 1059286 in avahi (Ubuntu) "avahi-daemon takes 100% CPU right after boot and at every restart of CUPS" [Critical,New] https://launchpad.net/bugs/1059286
<seb128> it seems to be spammed by "HP Photosmart C8100 series" detection
<seb128> tkamppeter, if you use "avahi-browse-domains -a", does it keep listing the same thing?
<tkamppeter> seb128, while it is spinning avahi clients cannot access at all. avahi-discover simply hangs and only errors out when avahi-daemon gets killed.
<seb128> tkamppeter, weird
<seb128> it looks like something DoS avahi with printer notifications though
<seb128> not sure if something is remote or if it's cups
<semvoz> hello :)
<tkamppeter> seb128, pitti, I have done the gdb test three times now and when I interrupt, it always interrupts in the same function, with the same backtrace (but at different queue names).
<tkamppeter> seb128, pitti, can we consider this also as a security vulnerability, as avahi-daemon can get broken by a DoS.
<pitti> if something keeps firing requests at it, it's a DoS, yes
<tkamppeter> pitti, seb128, but it seems that CUPS does not keep firing, as after stopping CUPS avahi-daemon keeps spinning.
<seb128> tkamppeter, does it stop if you disconnect "HP Photosmart C8100 series" from the network?
<tkamppeter> seb128, pitti, printer was totally crashed (touch screen not responding), restarted printer, restarted avahi, restarted cups, spinning again ...
<seb128> tkamppeter, if you disconnect the printer does it stop?
<tkamppeter> seb128, pitti, Turning of printer, still spinning.
<seb128> hum, k :-(
<seb128> tkamppeter, you seem to be the only one having the issue and avahi didn't change a lot in the recent cycles, I think what is creating the issue is something on your local setup DoSing the service, it's not happening to every user if that's a consolation
<tkamppeter> Restarted avahi-daemon, restarted cups, avahi-daemon spinning again.
<seb128> if you strace avahi it's still listing those same requests?
<pitti> you could also try dbus-monitor --system to see which process is talking to avahi that much
<tkamppeter> pitti, does avahi get all its requests via D-Bus?
<pitti> locally, yes; remotely it gets them through DNSSD network packets
<tkamppeter> pitti, seb128, it sends a message containing the service names of all local print queues several 100 times a second.
<seb128> tkamppeter, "it"?
<seb128> cups?
<tkamppeter> seb128, where did you find messages it received? I do not find them as it is too busy sending the announcement of all CUPS queues.
<tkamppeter> seb128, "it" = avahi-daemon.
<seb128> tkamppeter, can you pastebin a bit of the log?
<tkamppeter> seb128, pitti, it is attached to bug 1059286, comment #6.
<ubottu> Launchpad bug 1059286 in avahi (Ubuntu) "avahi-daemon takes 100% CPU right after boot and at every restart of CUPS" [Critical,New] https://launchpad.net/bugs/1059286
<seb128> tkamppeter, that's not a dbus-monitor log
<seb128> tkamppeter, dbus-monitor should start lines with e.g "signal sender=:1.6"
<seb128> tkamppeter, you can install,run d-feet to find out what :1.6 is
<seb128> tkamppeter, well :1.6 -> the sender
<tkamppeter> seb128, sorry, that is the strace log.
<seb128> tkamppeter, install, run d-feet, use the menu to connect to the system bus, select the sender id on the left pane and look at the top of the right pane
<tkamppeter> seb128, pitti, on the D-Bus nearly nothing is happening: http://paste.ubuntu.com/1267303/
<seb128> tkamppeter, hum, and on the session bus (dbus-monitor --session)?
<seb128> tkamppeter, I wonder if some of your printer spam it over the network with dnssd
<seb128> tkamppeter, does it stop if you disconnect from your local network?
<tkamppeter> seb128, keeps on spinning if I do "Disable Networking" in the Network manager menu.
<seb128> tkamppeter, no crazy activity in dbus-monitor --session
<seb128> tkamppeter, something is spamming avahi with printer queue discovery, those requests must come from somewhere (are you sure it's not cups?)
<tkamppeter> seb128, have it running now and it is very calm, minutes passing by without anything happening ...
<seb128> tkamppeter, it stopped spinning cpu you mean?
<tkamppeter> Now I have two avahi-daemons in top, one spinning at 100 % and the other spinning at -166%, so I got an extra 2/3 of a CPU core by avahi-daemon.
<tkamppeter> seb128, nothing stopped spinning, it keeps spinning.
<tkamppeter> Here is the top output: http://pastebin.ubuntu.com/1267316/
<tkamppeter> seb128, pitti ^^
<seb128> tkamppeter, I don't know what is sending those requests if it's neither the network nor cups
<seb128> tkamppeter, maybe try to stopping both network and cups and restart avahi and see if it keeps happening...
<seb128> tkamppeter, btw, could you look at https://errors.ubuntu.com/bucket/?id=%2Fusr%2Flib%2Fcups%2Fdriver%2Fopenprinting-ppds%3AUnicodeEncodeError%3A%3Cmodule%3E%3Amain%3Als
<seb128> tkamppeter, I don't find an openprinting-ppds package in quantal to open a bug,assign it to you but it's high on https://errors.ubuntu.com/
<tkamppeter> seb128, cannot see the link, login system is totally broken.
<tkamppeter> seb128, openprinting-ppds is a binary package of foomatic-db.
<seb128> tkamppeter, ok, the bug is https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/1014852
<ubottu> Launchpad bug 1014852 in foomatic-db (Ubuntu) "openprinting-ppds crashed with UnicodeEncodeError in ls(): 'ascii' codec can't encode character '\ufffd' in position 92: ordinal not in range(128)" [Undecided,Confirmed]
<tkamppeter> seb128, seems that the built-in uncompressor of openprinting-ppds stopped working, probably depending on locale.
<tkamppeter> seb128, pitti, avahi-daemon does not stop to spin when stopping CUPS and stopping the network.
<tkamppeter> seb128, pitti, I have also shut down all virtual machines.
<seb128> tkamppeter, that doesn't make sense, those printing queue requests have to come from somewhere
<seb128> tkamppeter, try rebooting, maybe you have lot of requests queued in dbus and it's still processing those...
<seb128> we had the issue with libreoffice recently, it was spamming dbus so much with menu stuff that it was still spinning cpu for a long time after the requests sent
<seb128> stopped
<tkamppeter> seb128, pitti, strace log of avahi-daemon spinning after stopping cups and turning off networking: http://pastebin.ubuntu.com/1267337/
<seb128> tkamppeter, reboot and try on a freshly started state please, your system might have queue hours of backlog at this point
<seb128> tkamppeter, reboot and try on a freshly started state please, your system might have queue hours of backlog at this point
<tkamppeter> seb128, pitti, strace log of avahi-daemon spinning after stopping cups and turning off networking: http://pastebin.ubuntu.com/1267337/
<dupondje> pitti: just testing my phone on my other laptop (Precise), and its working
<dupondje> so seems like a regression :(
<dupondje> Hmz, well 'working', I see the device, can mount it, I see the folders, but everything is empty :p
<seb128> dupondje, hum, I doubt it's new, https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/972311 and such started before precise
<ubottu> Launchpad bug 903422 in udev (Ubuntu Precise) "duplicate for #972311 Mount / Provide access to Android 4.x (Ice Cream Sandwich and above) MTP devices" [High,Confirmed]
<dupondje> seb128: well indeed, but in Precise I can mount it, in Quantal even that is not possible
<seb128> :-(
<dupondje> joy, and now nautilus crashed, and it doesnt work again :p
<dupondje> ah well :(
<tkamppeter> as usual, I am floating between the channels.
<tkamppeter> seb128, I have done so now: Stopped cupsd, keeps spinning, stopped network, keeps spinning, attached strace to avahi-daemon, log of some seconds (<10 sec): http://pastebin.ubuntu.com/1267347/.
<tkamppeter> pitti, ^^
<seb128> tkamppeter, those strace log have a sin_addr=inet_addr("224.0.0.251") ... what machine is that, your computer?
<tkamppeter> seb128, pitti, 2 MB of log per second.
<dupondje> seb128: thats multicast addr
<tkamppeter> seb128, pitti, I have done so now: Stopped cupsd, keeps spinning, stopped network, keeps spinning, attached strace to avahi-daemon, log of some seconds (<10 sec): http://pastebin.ubuntu.com/1267347/.
<tkamppeter> seb128, pitti, 2 MB of log per second.
<seb128> tkamppeter, well, something, somewhere on your local network or system is sending those requests
<seb128> tkamppeter, can you pastebin a ps aux of your box?
<seb128> tkamppeter, you can try using ethereal as well to see if something on the network is sending those
<tkamppeter> seb128, pitti: ps auxwww: http://pastebin.ubuntu.com/1267354/
<seb128> tkamppeter, what is tprintdaemon?
<seb128> tkamppeter, can you stop it in case that's due to it?
<tkamppeter> seb128, simply killing tprintdaemon does not stop the spinning.
<seb128> tkamppeter, can you stop hp-systray as well?
<tkamppeter> seb128, stopped hp-systray spinning goes on.
<seb128> tkamppeter, ok, I don't know then, wait for a bit in case it's backlog being still cleared, otherwise I would recommend next to install wireshark and to try to see if there are network trames corresponding to that activity listed
<seb128> to try to figure what is sending those
<tkamppeter> seb128, I have installed wireshark but it does not find my network interface. It is eth2.
<tkamppeter> seb128, for me it also looks like that avahi-daemon does not get flooded by anything. It still spins under complete isolation (no cupsd, no network, ...) It stops spinning immediately when restarted (and with this the network traffic should not change). It starts spinning when cups is started and keeps spinning until killed from then on, independent what one does to try to stop it.
<tkamppeter> seb128, and the strace log only shows that avahi-daemon is sending out messages, no hint that it receives messages.
<seb128> weird
<seb128> dunno, I need to run for an hour or so, bbiab
<pitti> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<stokachu> if something is in the unapproved build queue is it just a matter of waiting for someone to approve it?
<stokachu> or is there anything else from my side I would need to do
<pitti> stokachu: you mean the unapproved queue? the release team reviews that regularly
<pitti> (we have unapproved and build queues, but not an unapproved build queue)
<ev> mpt: even factoring out RecoverableProblem reports, 12.10 is pretty high. (See http://poppy-dev.local, ignoring the line starting too early)
<ev> ~0.12 for the past two days
<ev> I'm going to back-populate the previous days to give us more information
 * dholbach hugs pitti
 * pitti hugs dholbach back
<pitti> mvo: wrt. https://code.launchpad.net/~vericalcroft/ubuntu/quantal/app-install-data-partner/misc-depends-added/+merge/125288, is there a Vcs for this?
<pitti> mvo: this looks like a change which doesn't warrant an upload by itself
<pitti> oh, indeed, the MP is against the UDD branch
<pitti> I'll just commit it to Vcs-Bzr:
<pitti> mterry: ^ FYI
<pitti> mterry: (as you commented on this)
<mpt> ev, so that's the "by 12.04 standards" line for the past 3 days?
<pitti> mvo: except that Vcs-Bzr: doesn't exist, hmm
<ev> mpt: yeah
<ev> hacked into place for now
<mpt> ev, so RecoverableErrors are about 1/7 of the total
<ev> I'll clean that up, back populate, and create separate all collected and by 12.04 standards lines
<mpt> (1 - 0.12/0.14)
<ev> indeed
<ev> was just looking at the raw numbers
<ev> for the 7th
<mvo> pitti: meh, I will add one, sorry for that
<ev> 225 RecoverableProblem reports
<ev> 5201 Crash reports
<pitti> mvo: hm, and lp:app-install-data-commercial  seems out of date
<pitti> mvo: should this perhaps just use the UDD branch now?
<pitti> mvo: I'm happy to do an upload with dropping Vcs-Bzr: and adding the misc:depends thing
<pitti> (and yay for wasting time on such trivialities)
<ara> We would need sponsorship for Checkbox, if anyone is free:
<ara> https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.8/+merge/127923
<mvo> pitti: no strong opinion either way (branch vs udd). feel free to upload or I can do it later (once I finished wrestling aptdaemon)
<stokachu> pitti: ah yes, the unapproved queue
<pitti> mvo: ok; I think it's easier to use the UDD branch
<tkamppeter> seb128, pitti, what I guess what is happening I commented on bug 1059286 now: For me it looks like that avahi-daemon falls into an infinite loop sending out certain messages repeatedly (there are several 100 messages per second announcing the available CUPS queues) and does not listen any more to requests (loop does not go through the code for listening). Therefore avahi-discover cannot connect and also CUPS is not able to unregister it
<tkamppeter> s printers on shutdown. This leaves avahi-daemon continue to spin and announce CUPS queues.
<ubottu> Launchpad bug 1059286 in avahi (Ubuntu) "avahi-daemon takes 100% CPU right after boot and at every restart of CUPS" [Critical,New] https://launchpad.net/bugs/1059286
<xclaesse> seb128, does ubuntu patch glib, something related to GDBus ?
<xclaesse> seb128, I've got that problem: https://bugs.freedesktop.org/show_bug.cgi?id=55761#c1
<ubottu> Freedesktop bug 55761 in tp-glib "Use GTestDBus instead of home made with-session-bus.sh" [Normal,New]
<xclaesse> my code works with glib 2.34.0 from git, but not from ubuntu package
<xclaesse> hm, could be some modules that have side effects
<pitti> xclaesse: we do have some patches, but not against dbus
<pitti> xclaesse: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/glib2.0/debian/patches/
<pitti> xclaesse: mostly test suite fixes, translation, and multi-arch
<xclaesse> pitti, yeah, I'm suspecting modules that gets loaded and uses gdbus
<xclaesse> pitti, is there a way to know what modules gets pulled by any glib process?
<pitti> xclaesse: check /proc/pid/maps ?
<pitti> dholbach: for stuff like https://code.launchpad.net/~logan/ubuntu/quantal/nodm/debian-merge/+merge/128406, you don't push the branch?
<pitti> dholbach: or mark them as merged manually?
<dholbach> ah sorry, I didn't
<dholbach> I can mark it as merged
<pitti> dholbach: I can as well if you want me, just wondering about what went wrong here
<dholbach> usually I wait for the importer to mark it as merged for me ;-)
<dholbach> or rather import it
<pitti> import yes, but the importer won't notice that MP
<dholbach> ok, I'll bear that in mind until next time
<dholbach> I wish we had push-to-build
<pitti> bzr: ERROR: Unable to unapply quilt patches for 'other' tree: rmdir: failed to remove `.pc/force-ruby1.8': No such file or directory
<pitti> go, bzr merge
 * pitti downloads diff, cleans it, and applies manually
<Sweetshark> lamont: scheat is fed up with compiling libreoffice and remounted /home read-only. In protest it left interesting jabbering in dmesg. Maybe remount/reboot it?
<Sweetshark> cd ..
<ahasenack> SpamapS: hi,
<ahasenack> SpamapS: do you know why only the precise packages were uploaded? bug #1053057
<ubottu> Launchpad bug 1053057 in landscape-client (Ubuntu Oneiric) "Client queues up lshw calls if talking to old server" [Undecided,New] https://launchpad.net/bugs/1053057
<ahasenack> SpamapS: and landscape-client is gone from the sponsoring queue at http://reqorts.qa.ubuntu.com/reports/sponsoring/
<ahasenack> so no-one else will look at it I think
<SpamapS> ahasenack: they were all uploaded, but only precise was approved
<SpamapS> ahasenack: we are really far behind on SRU's so its likely we're just skipping the non-precise releases to try and get maximum impact on precise's backlog
<ahasenack> SpamapS: ok, I suppose it's still in some list/report that someone looks at?
<cjwatson> wookey: slang2 uses 'dh $@ --with autotools_dev', so your patch for that is unnecessary
<cjwatson> wookey: All the others are uploaded (some still in the unapproved queue) now
<SpamapS> ahasenack: http://people.canonical.com/~ubuntu-archive/pending-sru.html and at the bottom you will find links to the queues
<SpamapS> ahasenack: I see it in 11.10, 11.04, and 10.04
<ahasenack> SpamapS: thanks
<wookey> cheers colin. I've binned that one from my list too.
<pitti> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dupondje> pitti: http://pastebin.com/d3dRmqx3 this is what happens when I connect my device
<mlankhorst> bdmurray: that apt bug would actually be high or critical since it's a blocker for 12.04.2 :-)
<pitti> dupondje: btw, you might be interested in gnome bug 666195 :)
<ubottu> Gnome bug 666195 in general "Mount / Provide access to Android 4 (Ice Cream Sandwich, ICS) MTP devices" [Enhancement,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=666195
<dupondje> pitti: yep just read it :)
<dupondje> Quantal+1 is smilin :p
<dupondje> pitti: something new, gphoto2 --summary works if I execute it in the first seconds the device is connected
<hallyn> jodh: hey, when you get a chance, could you comment in bug 1056927 ?  (then un-assign yourself :)
<ubottu> Launchpad bug 1056927 in libvirt (Ubuntu) "'started libvirt-bin' event occurs before libvirt networks available" [Medium,New] https://launchpad.net/bugs/1056927
<jodh> hallyn: done.
<hallyn> jodh: thanks
<wookey> doko: gcc stage2 build is falling over building libgcc1 due to not finding 'bit/predefs.h'.
<wookey> Is that something I should expect to see needed at this point? There is one in the libc-headers unpacked under arm64-toolchain-cross-base/debian/tmp/ (usr/include/aarch64-linux-gnu)
<wookey> but I don;t see anything telling the build to look in that dir. So either the build-line is missing a -isystem or it's trying to build something it shouldn't at this stage
<wookey> which means eglibc stage1 completed :-) so I am making (slow) progress :-)
<barry> is anybody else seeing recent terrible regressions on window animation speeds?  e.g. bug 1063980
<ubottu> Launchpad bug 1063980 in unity (Ubuntu) "Regression in animation speed" [Undecided,New] https://launchpad.net/bugs/1063980
<infinity> wookey: The location for that file is correct, you may be missing multiarch foo in your gcc build?
<infinity> wookey: (Long weekend here, so I'm running off again, but we'll touch base tomorrow on all of this)
<wookey> infinity: good - it's slow progress with no one to share the pain with :-)
<wookey> wife is away tonight so I'll hack some more until fed up
<doko> wookey, what does build/gcc/xgcc -Bbuild/gcc/ -v -c foo.c say about the include dirs?
<wookey> doko: sorry, was on phone. build log is here: http://wookware.org/files/gccstage2faillog
<wookey> --includedir=/usr/aarch64-linux-gnu/include
<wookey> and --with-build-sysroot=/home/wookey/linaro/armv8/toolchain/quantalnew/arm64-cross-toolchain-base-1.89/debian/tmp which combined with above should find it
<doko> wookey, I'm confused. you talk about stage2 for a cross compiler?
<robert_ancell> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<doko> wookey, best thing would be to ask hrw about this. maybe this is something which just works by chance in his setup.
<wookey> OK. He's mostly fogotten how all it all works :-)
<wookey> something about the armel setup makes it work.
<wookey> I'm jujst trying to work out what's missing/different/wrong
<wookey> there is build-gcc1, build-gcc2, build-gcc3 rules in the toolchain bootstrap package. It's failing on build-gcc2
<wookey> export LD_LIBRARY_PATH=${CURDIR}/debian/tmp/$(PF)/$(HOST_GNU_TYPE)/${CROSS_GNU_TYPE}/lib/:${CURDIR}/debian/tmp/usr/lib:${CURDIR}/debian/tmp/lib
<wookey> cd gcc && DEB_CROSS_NO_BIARCH=yes WITH_BUILD_SYSROOT=${CURDIR}/debian/tmp DEB_STAGE=stage2 PKG_IGNORE_CURRENTLY_BUILDING=1 BACKPORT=false dpkg-buildpackage  -b -uc -us -d
<wookey> which loks plausible to me
<wookey> I don;t know what PKG_IGNORE_CURRENTLY_BUILDING=1 does, and hrw couldn't remember
<wookey> don't worry - I was just wondering if you'd go 'ah yes, that's probably X'
<doko> wookey, I'll try to have a look, but it's not priority for me until the quantal release
<wookey> sure
<cjwatson> wookey: PKG_IGNORE_CURRENTLY_BUILDING tweaks a behaviour of pkgbinarymangler; there's a rationale for why one might do that in its changelog
<cjwatson> (don't know if it's the same reason as here)
<hallyn> so, this is hillarious...  when you create a volume group called 'kvm' and with a LV called 'root', it creates /dev/kvm/root (-> ../dm-0).  Obviously that's trouble if you also want to use kvm.
<hallyn> should there be a blacklist to prevent the /dev/kvm dir from being created?
<hallyn> i.e. is that "just life suckign", or an actual bug in the lvm2 package?  (it happened to a user on the libvirt mailing list)
<mbiebl> hallyn: heh, I'll guess I name my next vg dri0 :-)
<SpamapS> hallyn: that does seem like a good idea (blacklisting known paths)
<hallyn> mbiebl: :)
<hallyn> SpamapS: i'm wondering if it's already beign done...
<hallyn> (for some paths, that is)
<hallyn> well i guess i'll file a bug and see what lvm2 folks say :)
<hallyn> then i'm outta here - ttyl
<hallyn> filed bug 1064099
<ubottu> Launchpad bug 1064099 in lvm2 (Ubuntu) "should /dev/vg directory names have a blacklist" [Undecided,New] https://launchpad.net/bugs/1064099
<wookey> doko: I've worked it out - it's multiarch vs old includedir paths. Now I just have to work out wherre in that epic build system to fix it...
#ubuntu-devel 2012-10-09
<rsalveti> tjaalton: seems -omap 4.1 is working as expected at panda
<rsalveti> didn't have any issue with it
<rsalveti> tjaalton: saw it's available at debian packaging git tree, but not yet pushed to debian
<rsalveti> tjaalton: want to manually sync it?
<tjaalton> rsalveti: ok, will do. also, is unity working for you on the panda?
<robert_ancell> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Godo morning
<pitti> (erk, and hapy tpying!)
<RAOF> Goodo!
<dholbach> good morning
<trijntje> Hi all, can someone tell me where translations for the package gcr show up? I'm trying to complete the translations but I'm not sure about a number of strings
<trijntje> these strings to be specific: https://translations.launchpad.net/ubuntu/quantal/+source/gcr/+pots/gcr/nl/+translate?batch=10&field.alternative_language-empty-marker=1&old_show=all&show=untranslated&start=0
<dholbach> freeflying, happy birthday! :)
<sarnold> trijntje: the 'gcr' package's Homepage field points here: https://live.gnome.org/GnomeKeyring
<sarnold> the Description says, in part, "This package contains the certificate viewer and prompter service."
<trijntje> sarnold: thanks, I'll try asking in the gcr irc channel
<freeflying> dholbach: thanks :)
<hrw> wookey: I switched to PKG_IGNORE_CURRENTLY_BUILDING=1 in 1.57 version. It replaced NO_PKG_MANGLE=1 and gave us ddebs
<hrw> wookey: can give you #linaro irc log of my discussion with lool about that switch.
<lool> hrw: This is fairly old, right?  ISTR we had to patch pkgbinarymangler, but that should be all in Ubuntu precise at least
<hrw> lool: it was natty time
<lool> yeah
<lool> I thought maverick, but whatever, it's "old"  :-)
<infinity> And today's confusingly useless use of cat award goes to:
<infinity> cat /build/buildd/sssd-1.9.1/debian/sssd.upstart.in > /build/buildd/sssd-1.9.1/debian/sssd.upstart
<tjaalton> no idea why cat instead of cp :)
<infinity> tjaalton: No idea why a .in at all, if it's not mangled on its way to being the real deal.
<tjaalton> infinity: it's the same line on debian too, there's an initscript for debian
<tjaalton> cat $(CURDIR)/debian/sssd.$(INIT).in > $(CURDIR)/debian/sssd.$(INIT)
<infinity> tjaalton: Seven kinds of special. :)
<cjwatson> Maybe it was mangled once and somebody didn't undo it enough *shrug*
<infinity> Yeah, did an 's/sed "expression"/cat/', assuming they may need to bring the sed back some day?  Dunno.
<infinity> Just rather entertaining.
<infinity> (The things one notices while watching build logs at 2am)
<tjaalton> well, is it allowed for packages to ship upstart files on debian? and would it then include both upstart and sysv initscripts on ubuntu?
<tjaalton> I'd gladly get rid of that hack
<infinity> tjaalton: Oh, I see what you're doing now.  Selecting one or the other, check.
<tjaalton> right
<tjaalton> instead of a diff
<infinity> tjaalton: I do believe it's perfectly reasonable to ship foo.upstart in debian/, and vorlon's submitted many a patch to do that, but I'm no expert on what the status of that is.
<infinity> slomo: ^
<infinity> slangasek: ^
<infinity> slomo: Ignore that, tab completion fail.
<slangasek> it's now valid in unstable; until recently it wasn't
<tjaalton> I recall there being a policy update about that..
<tjaalton> ah
<slangasek> (unstable and testing)
<tjaalton> slangasek: ping re acpi-tools review, what to do with them :)
<tjaalton> acpi-support
<slangasek> tjaalton: whimper; ENOTIME for the next couple of days, do whatever you think is best
<tjaalton> slangasek: cool, I'll just upload, it's a no-brainer
<infinity> tjaalton: If it's a no-brainer, any one of us no-brains will happily review it in the queue. ;)
<tjaalton> infinity: heh, understood :)
<tjaalton> bug 804109, fwiw
<ubottu> Launchpad bug 804109 in acpi-support (Ubuntu) "drop synaptics from racy /etc/acpi/asus-touchpad.sh" [Medium,Triaged] https://launchpad.net/bugs/804109
<pitti> RAOF, infinity: can I bribe one of you to review the SRU upload for bug 1016121? the crowd is getting angry :)
<ubottu> Launchpad bug 1016121 in ubuntu-defaults-builder (Ubuntu Precise) "wrong architecture (i386,amd64) packages downloading" [Undecided,In progress] https://launchpad.net/bugs/1016121
<infinity> pitti: Sure.  I accept bribery in the form of kittens.
<infinity> pitti: (It's my SRU day in ~6h anyway, but I'll check this one now)
<pitti> infinity: http://cdn.memegenerator.net/instances/400x/28050481.jpg
<infinity> pitti: Straightforward enough to me and, as an added bonus, I know exactly what that patch does. :P
<pitti> infinity: meeow!
 * pitti purrs happily
<infinity> pitti: Oh, wow, a custom lolcat just for me.  I feel special.
<infinity> pitti: And accepted.
<pitti> cheers!
<pitti> xdatap1: so is that one patch you pointed out enough for you, or do you actually need the quantal ubuntu-defaults-builder in precise?
<pitti> in the latter case, why don't you just use the quantal pacakge as it is?
<xdatap1> pitti, we use the amazon cloud for building the images, so using the standard package from archive would be better.
<pitti> xdatap1: quantal's version also has some adjustments for newer live-build, so I don't know whether it'd actually work with the precise live-build version
<xdatap1> pitti, also we are planning to continue using precise cloud instances for building the CD, so we would need ubuntu-defaults-build to move on with the new features
<pitti> xdatap1: I guess for now it might be best if we target individdual bug fixes that you need to precise, and I wrap them up in the next SRU?
<xdatap1> pitti, if this is better I'm fine with it. But as far I can see all the changes from 0.31 to 0.38 makes sense in precise
<xdatap1> pitti, on the same context, we need also the patch from this: https://bugs.launchpad.net/bugs/1062423
<ubottu> Launchpad bug 1062423 in live-build (Ubuntu) "Precise version.sh doesn't know about Quantal" [Undecided,New]
<pitti> xdatap1: e. g. 0.32 says "Adjust for live-build interface changes." which looks quantal only
<xdatap1> pitti, mmm, yes, you're right
<xdatap1> pitti, let's recap then. Patches for bug #1016121 , bug #1048207, bug #1062423 and if possible Bug #1029279 but I'm using a workaround for this so it's not urgent
<ubottu> Launchpad bug 1016121 in ubuntu-defaults-builder (Ubuntu Precise) "wrong architecture (i386,amd64) packages downloading" [Undecided,Fix committed] https://launchpad.net/bugs/1016121
<ubottu> Launchpad bug 1048207 in ubuntu-defaults-builder (Ubuntu) ""el complete" in langpacks.txt breaks build" [Undecided,Fix released] https://launchpad.net/bugs/1048207
<ubottu> Launchpad bug 1062423 in live-build (Ubuntu) "Precise version.sh doesn't know about Quantal" [Undecided,New] https://launchpad.net/bugs/1062423
<ubottu> Launchpad bug 1029279 in ubuntu-defaults-builder (Ubuntu) "/usr/share/syslinux/themes/ubuntu-quantal/isolinux-live/*': No such file or directory from precise" [Undecided,New] https://launchpad.net/bugs/1029279
<pitti> xdatap1: 1016121 is in -proposed; marked 1048207 for next SRU round; 1062423 looks like a missing dependency?
<pitti> xdatap1: i. e. you need syslinux-themes-quantal
<pitti> if you want to build quantal images
<xdatap1> pitti, correct me if I'm wrong, I wouln't have all syslinux-themes-<version> packages in Precise in the future, don't I? So wouldn't make sense pointing to syslinux-themes-precise for all the version I build?
<cjwatson> xdatap1: You really need to build quantal images in a quantal system - it's totally unsupported to do otherwise
<pitti> xdatap1: no, you need to install them from quantal
<cjwatson> xdatap1: Why not use a quantal chroot?
<pitti> but as I said before, it's really easier to just take the quantal pacakge
<pitti> at least live-build, u-d-b and syslinux-themes-* for the target releas
<cjwatson> xdatap1: We build all Ubuntu images in a host system that's, oh, I don't even know what it is, one of precise/lucid/hardy
<cjwatson> xdatap1: With chroots matching the release we're building
<xdatap1> phone, brb
<xdatap1> back
<xdatap1> cjwatson, pitti: let me rephrase the topic. The Italian team builds these localized images with ubuntu-defaults-build. From this cycle we try to use amazon cloud instances because building in local machine and then upload on the server it's way too long, takes nearly two hours
<pitti> xdatap1: right, but surely you can install some additional packages there from the target release?
<xdatap1> cjwatson, pitti : ubuntu-defaults-build do create a chroot for the target version. The bug #1029279 imho depends on the fact that the script ss looking for the directory on the host system and not inside the chroot.
<ubottu> Launchpad bug 1029279 in ubuntu-defaults-builder (Ubuntu) "/usr/share/syslinux/themes/ubuntu-quantal/isolinux-live/*': No such file or directory from precise" [Undecided,New] https://launchpad.net/bugs/1029279
<xdatap1> cjwatson, pitti : btw the general problem is. May we continue to update ubuntu-defaults-build on precise so that we can keep using precise for building next versions?
<pitti> xdatap1: as I said, that's not enough -- you also need live-build, the syslinux theme, and possibly some dependencie of those
<xdatap1> pitti, so the short answer is "probably no"? I mean, it appears difficult to build a precise+3 on precise, don't you think?
<cjwatson> xdatap1: I think it's a waste of time
<pitti> right
<cjwatson> xdatap1: I know ubuntu-defaults-builder creates a chroot - I mean that you should have another level of chroot to run ubuntu-defaults-builder in
<cjwatson> That will be so much less hassle for you and us
<cjwatson> And it will (modulo setup) work fine because it matches what we do
<xdatap1> the steps would be, then: precise cloud image -> ubuntu+n chroot -> ubuntu-defaults-build -> ubuntu+n chroot -> iso
<xdatap1> at the end it would have two chroots
<xdatap1> is it correct?
<xnox> xdatap1: yes.
<xnox> xdatap1: the last chroot is "implementation detail" of how to create an livecd-iso.
<xdatap1> ok. I need to think about it. As far I can see it's not sustainable for us in the long run. :\
<xdatap1> unless I create something that makes it automatic...
<xnox> xdatap1: there is sbuild juju charm that can create the first chroot. With small changes you can make the whole process as quick as: juju deploy livecd-build. and wrap your current build script in `schroot -c $target-distro`
<xnox> xdatap1: and juju will bring your livecd building instanace up, set it up and download the scripts you want, and clean up afterwards.
<xdatap1> xnox, thanks, I'll check for it. The problem is that quantal is next week
<xnox> xdatap1: for added bonus you will then be able to use it not only with EC2 but locally with lxc containers....
<xnox> xdatap1: yeah, I see.
<xnox> xdatap1: but... I am running quantal on EC2. There are quantal ec2 images published for each milestone. Use those?!
<xdatap1> pitti, anyway, we'll need the patch for bug #1048207 because it affects also precise builds and we'll need it for the point release
<ubottu> Launchpad bug 1048207 in ubuntu-defaults-builder (Ubuntu Precise) ""el complete" in langpacks.txt breaks build" [Undecided,New] https://launchpad.net/bugs/1048207
<pitti> right
<xdatap1> pitti, thanks, you're an hero!
<xdatap1> xnox, quantal ec2 images? where is it? I can't find it in the list
<xnox> xdatap1: http://iso.qa.ubuntu.com/qatracker/milestones/238/builds filter on the left for "Ubuntu Server EC2" only, for the quantal beta-2 milestone. The ami's are listed per region/arch in the right hand column.
<cjwatson> xdatap1: I can't believe it wouldn't be sustainable.  It involves a tiny amount of sysadmin effort once every six months to create the new chroots; they can be simple enough that you can keep them up to date automatically
<cjwatson> xdatap1: Again, this isn't a theoretical exercise, it's what we do in production and it's easy
<xnox> cjwatson: i think they do tear down and back up the EC2 instance ;-) so really they should puppetize / jujufy / etc it.
<cjwatson> If you have no persistent storage, indeed, it would be a bit more effort
<xnox> xdatap1: maybe there is a better way to find devel EC2 amis... but I don't know.
<cjwatson> But not desperately much
<xdatap1> with the last hint xnox gave me I should have solved. I'll check it out. Thanks ;)
<wookey> where is the equivalent of Debian's PTS for ubuntu? How do I find out if gcc-4.7_4.7.2-3ubuntu1 is headed for quantal or not?
 * wookey is having much fun with multiarch and compiler version skew across arches
<cjwatson> https://launchpad.net/ubuntu/+source/gcc-4.7
<cjwatson> Can't tell you intent, but then nor can the PTS
<wookey> right. cheers
<cjwatson> You'd have to ask doko
<doko> it's meant for -updates, not uploaded to -proposed to avoid accidential migration before the release. found in the ubuntu-toolchain-r/ppa PPA
<wookey> OK. but right yes _ i just found the PPA, which should solve my problem if it has arm builds too - ah yes it does.
<doko> wookey, there is bug, the packages don't build Go. but I assume you don't care
<wookey> I've got apt in a right state - interesting to see if it can sort itself out
<wookey> doko: correct :-)
<wookey> PPAs are a really good idea :-)
<BadDesign> Is there a repo that has a built GCC 4.7.2 ?
<doko> seb128, did you have a chance to look at libgtk2-perl?
<BadDesign> https://launchpad.net/~ubuntu-toolchain-r/ seems no to have it yet
<seb128> doko, I had a look but I didn't manage to figure what is wrong (yet ... then got sidetracked in "need to land before freeze" issues)
<BadDesign> for precise, Ubuntu 12.04, I mean.
<doko> not yet. buildd resources are needed elsewhere
<BadDesign> mda
<zyga> pitti: udisks2 support landed in checkbox
<zyga> pitti: with GUdev help
<pitti> zyga: yay you!
<zyga> pitti: thanks a lot for helping me out :)
<pitti> no worries
<zyga> pitti: I hope that we can soon fix usb-creator too
<rsalveti> tjaalton: unity is working fine for me
<tjaalton> rsalveti: on stock quantal?
<rsalveti> tjaalton: yes
<rsalveti> a few bugs, like a black line at the top of the screen, but working
<tjaalton> huh, doesn't work at all here, compiz crashes
<tjaalton> rsalveti: what dri driver do you have? llvmpipe isn't actually built atm, and it doesn't seem to work either
<rsalveti> tjaalton: well, I'm using the pvr-omap4 driver
<tjaalton> right
<rsalveti> don't think llvmpipe would work at this point on arm
<rsalveti> not enough to be called as usable
<tjaalton> nope
<ogra_> what i was wondering though is why cant we fall back to swrast
<ogra_> shouldnt that just kick in
<tjaalton> that's what happens now, and compiz crashes
<ogra_> (i know it wont be usable but iu would actually expect more than a dead screen)
<ogra_> ah, so its compiz
<rsalveti> I don't think we ever got compiz working with swrast with opengles
<ogra_> yeah, i wasnt aware its the client side thats at fault :)
<jdstrand> seb128: hey, what changed recently that makes everything want write access to dconf? I know about pam-xdg-support but the thing is, applications that never needed @{HOME}/.../dconf/user (eg, evince (bug #1062531)) now need it
<ubottu> Launchpad bug 1062531 in evince (Ubuntu Quantal) "apparmor prevents evince from accessing /run/user/" [High,Confirmed] https://launchpad.net/bugs/1062531
<seb128> jdstrand, it's weird, nothing should have changed out of the location of the db... I need to check with desrt
<seb128> jdstrand, but on that evince bug: apparmor="DENIED" operation="open"  name="/run/user/<user>/dconf/user"
<seb128> jdstrand, doesn't "open" mean it's having issue to access it to read?
<seb128> jdstrand, I think the evince error message is buggy (checking)
<jdstrand> seb128: it could be access(), it could be open()
<seb128> jdstrand, yeah, that errors is displayed when "  fd = open (filename, O_RDWR | O_CREAT, 0600);" fails
<jdstrand> it could be creat()
<jdstrand> seb128: is that in library code or in evince?
<seb128> jdstrand, it's in libdconf
<seb128> d-conf's client library
<jdstrand> sigh
<seb128> jdstrand, the way dconf works is that the daemon is only used for write, reading is done through direct mmaping of the db by the client through the lib
<jdstrand> I'm tempted to just add a deny rule
<seb128> jdstrand, do we need to restrict /run/user/<user> access at all?
<seb128> we don't restrict ~/.config access do we?
<mdeslaur> jdstrand: all gnome apps will need that directory, it's for d-conf shared memory...it should go in the gnome abstraction
<jdstrand> well that's great
<mdeslaur> jdstrand: the glib g_get_user_runtime_dir() now returns that directory now that the env var exists
<jdstrand> cause that's yet another hole in the profile since, you know, know the confined application can write to gsettings
<jdstrand> evnce worked just fine without the denial prior to this though
<seb128> mdeslaur, it's not only GNOME, gsettings is a glib level api (so could be used by e.g qt or KDE clients)
<jdstrand> s/, know/now/
<mdeslaur> jdstrand: that's because when the new env var isn't set, it defaulted to the user cache directory in his home
<seb128> jdstrand, well, it was writing to gsettings, the db was just in ~/.config, how is that different?
<mdeslaur> jdstrand: but that's less than ideal, as the directory isn't cleaned up on reboot
<jdstrand> mdeslaur: I understand-- evnice doesn't have access to the oroginal value
<jdstrand> apparmor_parser -p /etc/apparmor.d/usr.bin.evince|grep dconf
<jdstrand> returns nothing
<jdstrand> and there were no apparmor complaints
<jdstrand> today, there are apparmor complaints
<mdeslaur> jdstrand: well, you had @{HOME}/** rw,
<seb128> jdstrand, I don't understand the issue ... it was in .config which is not restricted in access, so it's normal there were no complain?
<jdstrand> this is true
<seb128> jdstrand, shouldn't just /run/user/<user> be whitelisted the same way?
<seb128> it's technically part of the user's owned dirs
<mdeslaur> jdstrand: /run/user/$USER is the new place where apps will put all their temp stuff
<jdstrand> seb128: my point was that I thought it *was* restricted in access. it isn't just evince-- it was a bunch of things. I have several profiles that are not shipped in ubuntu that all of a sudden need the access. I need to look at this more
 * jdstrand sighs again
<seb128> :-(
<jdstrand> (it shouldn't be in the gnome abstraction, cause we don't want to expand write access, but I'll fix the profiles)
<mdeslaur> jdstrand: It should probably go in the user-tmp abstraction
<seb128> jdstrand, you technically don't need write access there?
<mdeslaur> jdstrand: huh? it's a temp dir? why wouldn't apps get write access in there?
<jdstrand> seb128: we don't want the gnome abstraction itself to have the write access, no. maybe in another abstraction. but that doesn't matter for this. we'll figure something out
<seb128> jdstrand, well, why do you need "write"? the client lib is only reading the db, the writes go through dbus to the service
<Riddell> pitti: ok with this change to apport? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2103?start_revid=2103
<jdstrand> seb128: filename, O_RDWR | O_CREAT will file if not given 'w'
<jdstrand> s/will file/will fail/
<seb128> oh, I see, right :-(
<jdstrand> seb128: are you planning an upload of evince anyway?
<seb128> jdstrand, no, I've nothing planned for it
<jdstrand> ok
<pitti> Riddell: sure, if that works for you; I'll apply it to trunk, and check with the test suite
<doko> barry, talked with jdstrand about getting python3.3 into main already in quantal (needed in r anyway). reason is to build python3-stdlib-extensions for 3.3. we should then strive to get rid of 3.2 in r
<doko> will start the opening of r with 3.3 as a supported version
<danimo> notification area people: ping?
<danimo> looks like there is a pretty bad bug with QSystemTray in 12.04
<danimo> related to the way SNI treats menus with separators
<smoser> slangasek, could you take a look at https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1060296
<ubottu> Launchpad bug 1060296 in mountall (Ubuntu) "'df /' reports Filesystem '-'" [Undecided,Confirmed]
<ev> mpt: as it turns out, we're inserting quite a few package failures into the database. For 20120928 there were 97395 12.04 crashes and 2107 package installation failures. We don't get a signature for these yet, so they wont appear on the front page.
<ev> mpt: http://poppy-dev.local - I'm running that back-population in the background
<ev> so you should slowly see past days appear
<mpt> ev, what's a "package failure"? installation?
<ev> yes
<mpt> ev, so they haven't been showing up in the table, but have they been showing up in the graph?
<ev> mpt: correct, but not showing them in the graph is being fixed right now
<xnox> ev: thunderbird and rhythmbox have their "own" crash dialogs (thunderbird tries to report to mozilla, rhythmbox want to restart itself). and those don't seem to be getting through to whoopsi and apport, do they?
<ev> xnox: correct; we filter those out in apport
<mpt> ev, so are there any examples of package installation failures in the poppy-dev table? Nothing jumps out at me.
<xnox> =(
<ev> xnox: see /etc/apport/blacklist.d
<ev> mpt: no, package installation failures wont show up in the table yet
 * xnox would report to launchpad, but not mozilla....
<ev> feel free to come over if I am being confusing :)
<chrisccoulson> xnox, why? feel free to report to launchpad, but your bug won't get fixed
<ev> xnox: Mozilla is much better equipped to handle problems in Firefox than we are
<chrisccoulson> indeed :)
<chrisccoulson> they have a lot more people looking at crashes than we do
<mpt> ev, even so, we should be collecting them for statistical purposes
<chrisccoulson> (ie, they have more than one person looking at firefox crashes) ;)
<mpt> (Firefox and Thunderbird crashes, I mean)
<xnox> but they do not have the same privacy as we do.
<ev> mpt: agreed
<ev> filing a bug for that now
<xnox> but... rhythmbox hiding it's own crashes?
<ev> xnox: hm? Elaborate please.
<barry> doko: +1 from me.  also: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-python33
<ev> mpt: thoughts on getting two dialogs for firefox crashes?
<ev> seeing as how Mozilla will pop up one as well
<mpt> One with a broken icon
<mpt> I am familiar with it
<mpt> and one that never, ever, works for me
<mpt> but I digress
<mpt> ev, ideally we'd just hook in to theirs
<ev> mpt: please feel free to update https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395 with your thoughts
<ubottu> Launchpad bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New]
<josh__> Any idea if there will be fix for fglrx Bug #1058040 in final Ubuntu 12.10 release? Or we will have to use open source drivers? Thanks.
<ubottu> Launchpad bug 1058040 in fglrx-installer (Ubuntu) "fglrx-installer does not support HD2000-4000 "legacy" cards" [Undecided,Confirmed] https://launchpad.net/bugs/1058040
<xnox> ev: when rhythmbox crashes, it shows a rhythmbox crash saying "rhythbox crashed <quit> <restart>" and no apport / whoopsie dialogs. Can you check if you have rhythmbox crashes over the year?
<xnox> maybe it has been crashing at decoding mp3 and that's blacklisted though =/
<seb128> xnox, ev: rb shouldn't block apport, some software do because they trap the signal to do custom handling, we usually patch those to restore the signal to not hijack apport
<seb128> xnox, ev: or said differently "that's a bug"
<ev> :)
 * xnox did seb128 join us?! =)
<seb128> xnox, well, go on https://errors.ubuntu.com/ and enter "rhythmbox" in the text entry
<ev> xnox: https://errors.ubuntu.com/?package=rhythmbox
<seb128> quite some rb issues there
<xnox> hmm...
<ev> damn, seb128  beat me to it :)
<ev> but yeah, seems like we're getting reports for it
<seb128> ev, your solution is nicer though, one click away and I learnt something ;-)
<ev> seb128: yeah, I really need to document (beyond the old post to ubuntu-devel) the URL parameters
<ev> or rather, just make the URL change to match the selected filter
<ev> so you learn them all the same
<ev> I think mpt suggested that a while back
<cjwatson> Yeah, I wish more pages did that
<seb128> xnox, I get an apport dialog if I kill -11 $(pidof rhythmbox)
<seb128> ev, yeah, I like when urls reflect your queries ;-)
<seb128> it also makes firefox's awesome more awesome
<seb128> since it remembers the things you query most about and rank them higher
<ev> sounds like we have consensus :) - adding to my todo list
<ev> oh nice
 * xnox same with chromium....
<mpt> ev, yes, in bug 1020580 (should that be a separate bug?)
<ubottu> Launchpad bug 1020580 in Errors "Permanent URLs for most common problems view" [Undecided,Fix committed] https://launchpad.net/bugs/1020580
<cjwatson> I don't generally remember URLs any more; I bang bits of them into firefox and it reads my mind
<ev> mpt: yeah, probably
<ev> as we can consider permanent URLs done
<ev> cjwatson: hahaha
 * xnox can see a new "virus" popping up which clears user search history.... that will be pain.
<mpt> ev, reported bug 1064398
<ubottu> Launchpad bug 1064398 in Errors "errors.ubuntu.com URL parameters are secret" [Undecided,New] https://launchpad.net/bugs/1064398
<ev> mpt: thanks
<seb128> ev, what does "red background" means again? and greyed background?
<seb128> ev, it would be really good to have a color code somewhere on the page for people like me who can't make sense of the color code ;-)
<stgraber> dholbach: heya
<stgraber> dholbach: I'm looking at libxml2 in the queue, it's introducing a new binary package without any FFe or even any bug linked to it at all. Do we actually need that udev in Ubuntu?
<stgraber> *udeb
<dholbach> stgraber: I didn't create the udeb
<dholbach> stgraber: that must be something automatic during the build
<cjwatson> it's had a udeb for ages, I thought
<stgraber> http://launchpadlibrarian.net/119213170/libxml2_2.8.0%2Bdfsg1-5_2.8.0%2Bdfsg1-5ubuntu1.diff.gz
<ev> red/pink -> possible regression
<ev> grey -> not showing up in the latest version yet
<doko> stgraber, it's just autogenerated when built on ubuntu
<ev> seb128: indeed, it's on my list :)
<doko> WITH_UDEB := $(shell dpkg-vendor --derives-from Ubuntu && echo yes)
<doko> ifdef WITH_UDEB
<doko> $(if $(shell grep -q libxml2-udeb debian/control || echo yes),$(shell cat debian/control.udeb >> debian/control))
<doko> TARGETS += udeb
<doko> else
<doko> $(if $(shell grep -q libxml2-udeb debian/control && echo yes),$(shell sed -i /libxml2-udeb/,\$$d debian/control))
<cjwatson> there's certainly a udeb in the archive right now
<doko> export DH_OPTIONS = -Nlibxml2-udeb
<doko> endif
<seb128> ev, oh ok, I though pink was that, I wouldn't have guessed the grey one ;-)
<seb128> ev, thanks
<dholbach> stgraber: so it looks like it's business as usual :)
<cjwatson> yeah, that looks like autoregenerated control file
 * Laney does a sad about libxml2 going out of sync
<cjwatson> generated control is a curse from the pits of hell
<dholbach> Laney, the change is forwarded
<stgraber> hmm, ok, so it's just the diff being confusing...
<smoser> doko, roaksoax says you moved freeipmi to main earlier today. is this transient: http://paste.ubuntu.com/1269287/
<ev> seb128: sure thing
<cjwatson> smoser: something is odd because freeipmi-common is missing from the archive at the current version
<smoser> right. i hvae no idea how i would fix such a thing. i'm guessing you do.
<Daviey> Candidate: 1.1.5-3 == not current version.
<smoser> right.
 * cjwatson checks build logs
<cjwatson> I strongly suspect that somebody overrode it between components twice in one publisher cycle
<cjwatson> And thereby caused Launchpad to forget that it exists
<Daviey> cjwatson: That will be me and doko doing the operation concurrently
<cjwatson> Yeah, it's Superseded
<doko> smoser, should be
<cjwatson> Concurrently isn't a problem if you both do the same thing
<cjwatson> Daviey: Somebody needs to do a no-change upload of freeipmi to resurrect this
<doko> ouch
<Daviey> cjwatson: for reference, is the a LP bug to track this feature?
<chrisccoulson> mpt - did you report a bug for the broken icon? ;)
<cjwatson> There is, somewhere - it's well-known by the relevant people
<cjwatson> It's obviously not a feature :-P
<mpt> ev, seb128: red/pink can also mean "private bug report"
<cjwatson> I think it's either bug 180218 or related to it
<ubottu> Launchpad bug 180218 in Launchpad itself "override mismatch race needs to be fixed" [High,Triaged] https://launchpad.net/bugs/180218
<seb128> mpt, same color for "potential regression" and "private bug"?
<cjwatson> Ah, bug 347279 is clearer
<ubottu> Launchpad bug 347279 in Launchpad itself "overrides on architecture-independent binaries in a single architecture leads to superseding the package on other architectures" [Low,Triaged] https://launchpad.net/bugs/347279
<mpt> seb128, I discovered that only by accident :-)
<cjwatson> Perhaps
<Daviey> uploaded.
<seb128> mpt, I see ;-)
<mpt> for example bug 1030456
<ubottu> Error: Launchpad bug 1030456 could not be found
<mpt> indeed
<mpt> chrisccoulson, no, I was never quick enough to get a screenshot :-)
<davmor2> mpt: screencast it?
<mpt> good idea
<mpt> Now, how to trigger a bug in Firefox/Thunderbird...
<chrisccoulson> mpt, heh, it doesn't matter too much. i'll send a patch upstream for it in a bit. it's probably only a 1-line fix
<chrisccoulson> mpt, crashme ;)
<chrisccoulson> mpt http://code.google.com/p/crashme/
<chrisccoulson> it even allows you to pick the type of crash to trigger
<mpt> oh cool
<mpt> ok, got a screencast
<mpt> chrisccoulson, reported bug 1064423
<ubottu> Launchpad bug 1064423 in firefox (Ubuntu) ""Submitting your report..." shows missing-icon icon" [Undecided,New] https://launchpad.net/bugs/1064423
<chrisccoulson> mpt, thanks
<mpt> chrisccoulson, now what should I do about the error report submission never working? Any obvious troubleshooting steps?
<mpt> Every time, it's "There was a problem submitting your report.", both in Firefox and Thunderbird
<chrisccoulson> mpt - are you sure the submission doesn't work? you don't get any feedback
<mpt> and then the window disappears half a second later
<chrisccoulson> mpt, do you have any reports in about:crashes?
<chrisccoulson> the missing icon is my fault btw, we don't install it in the package
<chrisccoulson> i thought you were referring to the icon on the launcher :)
<mpt> chrisccoulson, yes, going back to January last year -- but that I can remember, it has *always* said "There was a problem submitting your report"
<chrisccoulson> mpt, hmmm, do you use a proxy by any chance?
<mpt> chrisccoulson, and when I follow any of the links, crash-stats.mozilla.com gives me a 404 error.
<mpt> chrisccoulson, no, I'm at the Canonical office
<seb128> mpt, well I guess Canonical has some proxying going on there
<chrisccoulson> i should come in to the canonical office one day
<chrisccoulson> mpt - ok, the icon fix was a trivial fix: http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1396
<mpt> seb128, elmo says no it doesn't :-)
<mpt> chrisccoulson, \o/
<mpt> seb128, reported bug 1064436 about the pink.
<ubottu> Launchpad bug 1064436 in Errors "Improperly-fixed bugs and private bug reports shown the same way" [Undecided,New] https://launchpad.net/bugs/1064436
<tkamppeter> seb128, hi
<seb128> mpt, thanks
<seb128> tkamppeter, hey, how are you?
<mpt> chrisccoulson, would you like a bug report about the failed submissions? (Or should I report that at b.m.o instead?)
<chrisccoulson> mpt, you can report it to launchpad for now
<chrisccoulson> mpt - i guess you have libcurl3 installed?
 * mpt wonders why "apt-cache show" doesn't show whether the package is actually installed
<tkamppeter> seb128, fine, I want to ask you about bug 1014852. I cannot reproduce it. According to the original poster it happened right after restarting the system but /usr/lib/cups/driver/openprinting-ppds is not executed during system start.
<ubottu> Launchpad bug 1014852 in foomatic-db (Ubuntu) "openprinting-ppds crashed with UnicodeEncodeError in ls(): 'ascii' codec can't encode character '\ufffd' in position 92: ordinal not in range(128)" [High,Confirmed] https://launchpad.net/bugs/1014852
<mpt> chrisccoulson, yes, it's installed
<seb128> tkamppeter, "after restarting" might be when the user get notified about the issue, it doesn't mean it's when it happened
<mpt> chrisccoulson, reported bug 1064445
<ubottu> Launchpad bug 1064445 in firefox (Ubuntu) "Crash report submission never works" [Undecided,New] https://launchpad.net/bugs/1064445
<chrisccoulson> thanks
<tkamppeter> seb128, what is different to my system is that the user has /usr/bin/python3.2mu and I have /usr/bin/python3. What is the difference between the two.
<smoser> Daviey, you uploaded?
<cjwatson> smoser: and I accepted
<cjwatson> if you mean freeipmi
<smoser> yes
<seb128> tkamppeter, python3.2-minimal: /usr/bin/python3.2mu
<smoser> thanks.
<cjwatson> tkamppeter: python3 is a symlink to python3.2 which is a symlink to python3.2mu
<cjwatson> in other words: nothing
<smoser> my mirror just hadnt been updated i guess.
<cjwatson> tkamppeter: looking only at the top line of the traceback, the difference is almost certainly locale
<cjwatson> tkamppeter: Try with LC_ALL=C
<seb128> tkamppeter, $ LANG=en_US python3 /usr/lib/cups/driver/openprinting-ppds list  > /dev/null
<smoser> is there any way that those builds can be bumped in priority
<seb128> seems to trigger it
<smoser> i know i'm being impatient. but "start in 54 minutes"
<seb128> or C as cjwatson said
<cjwatson> smoser: ARM has a lot of work to do to catch up
<smoser> cjwatson, fair enough.
<cjwatson> smoser: I've rescored but I don't know how much difference it will makek
<cjwatson> A bit
<chrisccoulson> mpt, do you have a ~/.mozilla/firefox/Crash\ Reports/submit.log file?
<mpt> chrisccoulson, yes. Except for the very first, every line is of the form "[Wed 17 Aug 2011 12:43:10 BST] Crash report submission failed: Failure when receiving data from the peer"
<tkamppeter> seb128, cjwatson, it seems that it requires a "XXX.UTF-8" locale, on standard (non-UTF-8) locales it works. Is there a way in Python to ignore the system's locale and use ones own, for example always "en_US.UTF-8"?
<cjwatson> tkamppeter: no; you could arrange to start it with LC_ALL=C.UTF-8 or something, but that's really the wrong answer as this is exposing a bug in this Python code
<cjwatson> It's assuming a particular default encoding
<cjwatson> But I don't have time to teach this now, too much critical-path stuff :(
<jcastro_> Laney, I can confirm HP sent me a bill for September btw.
<Laney> :(
<Laney> lfaraone|sh: ^
<chrisccoulson> mpt, thanks. i might have to give you a custom build to try, with more verbose output from libcurl
<mpt> sure
<cr3> could someone point me to a common process for maintaining the debian/changelog file? I tend to keep the next version at the top of the file, with a section for each person and a bullet for each merge request. the problem is that when a person submits two merge requests, the second one has a conflict because of the second entry in the changelog file :(
<ScottK> cr3: The problem is that bzr doesn't handle debian/changelog's well.
<ScottK> I think it's going to hurt no matter how you do it.
<pitti> they are usually trivial to resolve
<cr3> pitti: ... by a human :)
<cr3> ScottK: would it work better if every entry had its own minor-minor version, and all those minor-minor versions would be collapsed when releasing the minor version?
<ScottK> I don't know, but what you're doing is the right way to do a changelog
<ScottK> Personally, I'd be worried someone would forget to consolidate them.
<cr3> ScottK: unfortunately, it's causing lots of time doing busy work that I would rather spend doing productive work :(
<cjwatson> cr3: bzr-builddeb comes with a plugin that automatically resolves changelog merges
<cjwatson> or there are other tools such as dpkg-mergechangelog
<cjwatson> (bzr-builddeb uses dpkg-mergechangelogs under the covers, in fact)
<cr3> cjwatson: thanks, I'll definately have a look!
<pitti> cr3, cjwatson: TBH I find that this makes things worse
<pitti> it definitively tries (I usually don't get conflicts)
<pitti> but it's not very good at it, cleaning up its result usually takes me longer than a simple conflict resolution would
<slangasek> smoser: bug #1060296> I'm going to need access to a machine to reproduce this on; could you get me an instance today?
<ubottu> Launchpad bug 1060296 in mountall (Ubuntu) "'df /' reports Filesystem '-'" [Undecided,Confirmed] https://launchpad.net/bugs/1060296
<smoser> slangasek, i can do that right now.
<cjwatson> pitti: certainly I prefer resolving the conflicts, but apparently cr3 doesn't )
<cjwatson> :)
<cr3> pitti: do you mean bzr-builddeb/dpkg-mergechangelogs makes things worse? I'm playing with it and it doesn't seem to be doing much: dpkg-mergechangelogs debian/changelog.BASE debian/changelog.THIS debian/changelog.OTHER :(
<mitya57> cjwatson: can it happen that grub2 asks where to install itself during precise->precise upgrades?
<mitya57> bug 1064483
<ubottu> Launchpad bug 1064483 in grub2 (Ubuntu) "Grub 2 update install bug" [Undecided,New] https://launchpad.net/bugs/1064483
<cjwatson> mitya57: well, since you're asking, it clearly does.  It shouldn't normally, unless devices have been moved around
<cr3> cjwatson: the reason resolving conflicts has become particularly annoying is after integrating tarmac into the review process, which handles running unit tests and merging when they pass. the merging part is failing often enough that it's causing lots of noise
<cjwatson> mitya57: But I can't look at it now
<Laney> cr3: A workflow I like is to have something else generate the changelog from the commit messages
<Laney> (a workflow that I have with git-buildpackage, so no code for bzr I'm afraid)
<cr3> Laney: that might work with git that supports something like folding commits, I think, but doesn't work as well with bzr when making one change with several commits
<Laney> Well, you can have metadata to ignore particular changes
<Laney> or the inverse
<mitya57> cjwatson: so I'll ask the reporter whether they had touched their devices :/
<cjwatson> mitya57: the leading - indicates some kind of odd bug I guess
<cjwatson> Dunno, sorry, no mental bandwidth
<smoser> slangasek, ubuntu@ec2-50-16-176-255.compute-1.amazonaws.com
<smoser> and i just noticed that the problem persists after a reboot, and cloud-init will not modify /etc/fstab on second boot.
<cr3> barry: quick python question for you: map() returns a list in python2 and an iterator in python3, so I started wondering if there was a naming convention to obviate when the caller should expect to receive a list or an iterator?
<slangasek> smoser: this VM doesn't have / listed in /etc/mtab at all; that wasn't the symptom you supported?
<slangasek> smoser: s/supported/reported/
<slangasek> smoser: is the rootfs being mounted rw by the initramfs?  (didn't we have a discussion about this previously?)
<cjwatson> Daviey,smoser: freeipmi is all built and published everywhere now; I just demoted the stray binaries on component-mismatches
<smoser> slangasek, i would not think it is mounted rw.
<smoser> http://paste.ubuntu.com/1269682/
<smoser> thats console output of that instance
<slangasek> smoser: ok
<smoser> console shows
<smoser> [    3.223291] EXT4-fs (xvda1): re-mounted. Opts: (null)
<cjwatson> Does anyone know nvidia well enough to know whether http://paste.ubuntu.com/1269699/ is the right fix for a build failure?
<pitti> hm, tseliot, but he's offline already
<xnox> cjwatson: looks correct. haven't seen the build-failure though.
 * xnox was fighting with pycuda once
<xnox> cjwatson: this is pycuda... hmm.
<cjwatson> It doesn't seem to result in /usr/lib/nvidia-current/ being hardwired into binaries, which I think is good given that my main worry was interop with nvidia-current-updates
<cjwatson> So I think this is probably good
<xnox> cjwatson: note my post to debian-devel. after it's build it will not be installable.
<cjwatson> Surely if you have nvidia-current installed it does the ld.so.conf.d thing
<cjwatson> And you might have to narrow down "my post to debian-devel" for me
<slangasek> smoser: thanks, I see what's happening now
<cjwatson> Oh, you mean ubuntu-devel
<cjwatson> xnox: How's it uninstallable, then?  I just did 'dpkg -i *.deb; apt-get -f install' on my test debs in a clean chroot
<cjwatson> And apt is happily downloading stuff rather than throwing an error
<xnox> cjwatson: and the recommendation to s/opencl-icd/nvidia-current|fglrx/
<xnox> cjwatson: yes. ubuntu-devel.
<cjwatson> xnox: pycuda's dependencies don't mention opencl anywhere
<xnox> cjwatson: wait, cuda is nvidia specific. it's the opencl which is not installable right now.
<xnox> cjwatson: pycuda will be fine, indeed.
<cjwatson> Right.  I don't really care about nvidia, just trying to fix build failures :)
<ogra_> heh
<cjwatson> OK, uploading this, thanks
<xnox> cjwatson: do you agree with the tumbleweed's suggestion about opencl?! or is there a long history behind different package names in ubuntu/debian for these "graphics card" related packages?
<cjwatson> xnox: I know nothing about the nvidia packaging in Ubuntu
<cjwatson> xnox: You want tseliot for that
<xnox> ok.
<barry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<ara> pitti, ping?
 * ara knows is already  a bit late for pitti
<slangasek> smoser: did I brick the VM? :)
<smoser> slangasek, maybe.
<smoser> it takes 4 minutes to get an update dconsole log
<smoser> http://paste.ubuntu.com/1269837/ is what it shows right now.
<smoser> cjwatson, does install set hardware clock ?
<smoser> if so, where does it get its time from?
<cjwatson> https://wiki.ubuntu.com/HardwareClock
<cjwatson> When we wrote that wiki page we understood it
<cjwatson> I've long since paged it out
<slangasek> smoser: spiff.  so, it's been 4 minutes now; any sign of what it's doing?
<smoser> http://paste.ubuntu.com/1269858/
<smoser> General error mounting filesystems
<slangasek> smoser: neat.  ok, let's see if I can figure out where that segfault came from, since that didn't happen here
<smoser> slangasek, i can get you back to that system if you'd like.
<smoser> if that would help
<smoser> or i can just get you another
<slangasek> smoser: I think the problem is only going to be reproducible at boot due to the nature of the race I'm trying to fix; so whatever's easiest for ou
<slangasek> you
<slangasek> oh, I see the bug, meh
<slangasek> I misspelled 'mnt' - too many vowels
<slangasek> smoser: so, I have another package to test as soon as there's a vm to test it on
<smoser> ubuntu@ec2-54-242-41-174.compute-1.amazonaws.com
<smoser> slangasek,
<slangasek> ta
<slangasek> smoser: ok, fixed
<slangasek> smoser: dunno if you want to pick up that mountall .deb from the VM and put it through further exercising before I upload?
<slangasek> seb128: your update-notifier upload reintroduced bug #1003100
<ubottu> Launchpad bug 1003100 in update-notifier (Ubuntu Quantal) "package-data-downloader: KeyError: 'paquetes'" [High,Triaged] https://launchpad.net/bugs/1003100
<smoser> slangasek, you have a diff ?
<seb128> slangasek, "reintroduced"? :-(
<seb128> slangasek, well, I've no code change ... is that a buggy translation?
<slangasek> seb128: yes
<seb128> slangasek, I basically copied the launchpad po files over the source and uploaded
<seb128> slangasek, sorry about that, do you know why that was not fixed on launchpad as well by then to avoid that sort of issue? or how I could have seen that before uploading?
<slangasek> seb128: unfortunately we have no sane way of marking that string as not-for-translation
<seb128> :-(
<slangasek> seb128: it probably wasn't fixed on launchpad because the process for getting such things fixed is opaque to me
<seb128> slangasek, it's easy enough, it's "get $translator to edit the string"
<seb128> slangasek, or "tell dpm and let him do magic" ;-)
<slangasek> right, so who's $translator?
<slangasek> this is what I mean by opaque :)
<seb128> well
<seb128> did you open a bug on language-pack-(gnome-)$locale?
<slangasek> no; does that do any good?
<seb128> well, it usually gets you a translator to fix the string on launchpad for you ;-)
<slangasek> ok
<seb128> can you give me the string,locale to fix?
<slangasek> seb128: " $packages", and quite a few locales it seems :/
<seb128> slangasek, do you have the diff or revision of the previous fix?
<slangasek> ast gl hr ko nl pl pt_BR pt ro ru sq tr uk
<seb128> urg
<seb128> should we just revert my update?
<slangasek> there are some legitimate translation updates in there too
<slangasek> I'll hand-revert each of these
<seb128> slangasek, thanks, and sorry about break it ... I tested before upload but only in french ... do you have any idea how to regression test that in the futur?
<slangasek> seb128: AIUI it shouldn't be locale-dependent at all; the template that this gets applied to is a .desktop-style file containing all the translations
<slangasek> so I would expect the error to show everywhere
<seb128> slangasek, hum, I did dpkg -i the debs here without issues and installed upgrades since
<slangasek> yeah, the bug only triggers when there's a notification to be sent
<slangasek> which is only in case of failure
<seb128> ok
<slangasek> maybe I can quickly extend the test suite to check the template
<seb128> it seems like the sort of things that could have a test in the source
<slangasek> yeah
<slangasek> ultimately the darn string needs to somehow be marked as not-for-translation, but last time I looked at this I couldn't come up with a supported way to do that
<cjwatson> I thought I vaguely remembered suggesting one
<cjwatson> Maybe not
<cjwatson> I might be able to prod each of those in LP
<cjwatson> Though that's quite a lot of URLs to click through
<seb128> well, if you have the string number it's just replacing $string in the URL
 * cjwatson is a translations admin for hysterical raisins
<seb128> I think the string number is the same between locales
<cjwatson> Oh, good point
<cjwatson> That makes it only slightly less laborious :-)
<Daviey> cjwatson: thanks muchly
<ev> pitti: any idea what could be causing this? https://pastebin.canonical.com/76089/ - unfortunately I can't reproduce it, but it's in a code path entirely from inside apport-retrace. That is, by this point daisy has already written the crash report for apport-retrace to process.
<ev> pitti: http://paste.ubuntu.com/1269950/  is the obvious solution, but seems a bit hammer-ish
<cjwatson> slangasek: I've fixed all those in Launchpad; how well it'll stick I don't know
<ev> err sledgehammer, that is
<ev> but maybe we should do that anyway to guard against failing to properly encode elsewhere?
<ev> I can't see a gap in apport's encoding either
<slangasek> cjwatson: thanks; I'm nearly there on a test case in the source, had to reboot because I made lvm unhappy
<slangasek> smoser: sorry, no time to split the patch out; if the binary .deb's not useful to you as-is, I'll just upload it to the queue
<smoser> slangasek, thats fine.
<barry> cjwatson: do you have any opinion on bug 1064279?  you changed the build-dep on libtk-img to libtiff-dev (i.e. libtiff5-dev) but that apparently broke libtk-img.  the patch suggests reverting that (which i still need to test).  your changes doesn't provide a rationale
<ubottu> Launchpad bug 1064279 in libtk-img (Ubuntu) "Cannot load img::tiff" [Undecided,New] https://launchpad.net/bugs/1064279
<sam-c> on bet ubuntu studio now
<sam-c> on beta
<sam-c> waiting for 12.10
<jtaylor> barry: probably simplest to revert it
<jtaylor> upstream has not ported to tiff5
<jtaylor> and I guess its a bit too late to do it ourselfs
<barry> jtaylor: that's what i'm thinking.  i'm just testing it now
<jtaylor> I can test to, I'm using ds9 pretty much daily
<jtaylor> nice that its in the archive now
<slangasek> seb128: ok, update-notifier uploaded, now with test suite actually run at build time (!) and with a test that bails if the translations are broken
<jtaylor> barry: ds9 works fine with the change reverted
<barry> jtaylor: cool, thanks for the confirmation
<seb128> slangasek, excellent, thanks a lot for that ;-) and sorry for breaking it...
<cjwatson> barry: we were trying to mass-convert the archive to tiff5
<barry> cjwatson: ah, thanks.  i've uploaded the patched package
<cjwatson> barry: are there any rdepends?  be careful ...
<barry> Reverse-Depends
<barry> ===============
<barry> * libtk-img-dev
<barry> * mcu8051ide
<barry> * saods9
<barry>  
<barry> and this does fix saods9
<barry> libtk-img-dev has no r-d itself
<jtaylor> cjwatson: no rdepend links depends on libtiff
<jtaylor> should be fine
<jtaylor> hm wait is apt-cache rdepends  recursive?
<jtaylor> -r
<barry> jtaylor: reverse-depends but that's not recursive afaict
<cjwatson> no
<cjwatson> you have to do actual analysis
 * barry thinks someone should file a bug :)
<jtaylor> hm ugly, but at least not so many rdeps
<jtaylor> ok all rdepends don't link tiff
<cjwatson> ok
<jtaylor> didn't check dlopen though
<alexcunn> is anyone here in charge of the beginners dev group?
<TheMuso> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, TheMuso
<barry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
#ubuntu-devel 2012-10-10
<TheMuso> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Godo morning
<pitti> ev: apport patch> NB that the data can already be bytes, and in most cases, should be; you seem to have hit a corner case where a string is recognized as binary data
<pitti> ev: is this running with py2 or 3? looking at _is_binary() it should work alright with py3
<pitti> ev: for the py2 case, it looks like a "if isinstance(string, unicode)" check is missing?
<pitti> ev: would it be possible for me to get the .crash file it was trying to reprocess? I'm afraid it's not quite obvious which kind of data caused this
<gogo_> Hello, any idea if we will be able to install catalyst legacy drivers in Ubuntu 12.10? There is a thread about this on reddit --> http://www.reddit.com/r/Ubuntu/comments/11743j/ubuntu_developerstesters_please_comment_on_status/
<RAOF> gogo_: Short answer -no.
<RAOF> gogo_: Although the free drivers for those cards aren't terrible.
<gogo_> RAOF: Oh, what happens when a user having these old cards tires to install catalyst driver in Ubuntu 12.10? I think Ubuntu still shows an option to install fglrx for legacy cards, which gives users a broken experience.
<gogo_> tries*
<RAOF> gogo_: It shouldn't; we (should) only display the proprietary drivers as an option if the proprietary drivers actually support the card they're using.
<RAOF> (Also, that thread is somewhat out of date; the free drivers in Quantal should support full acceleration up to < radeon 78xx (and possibly 3D for the 78xx & 79xx cards, although I've not tested that and I'm not sure how well it works).
<gogo_> RAOF: Thanks for the info, I am installing Ubuntu 12.10 now; will check out open source drivers.
<dholbach> good morning
<diwic> infinity, I got a build error email from Launchpad this morning, it says pulseaudio failed building on quantal/armhf, but when I click on the build log I get a "lost something?" page. Is it anything I should do anything about?
<cjwatson> diwic: that means it's been retried, and in this case it succeeded, so ignore it
<diwic> cjwatson, ok, thanks
<alkisg> Hi, 4 out of 5 times this file cannot be found and is breaking firefox upgrade, where can I report a web-server related problem?
<alkisg> http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_11.2.202.243.orig.tar.gz
<cjwatson> (assuming this wasn't a PPA - I'm checking the primary archive)
<diwic> yep, it was the primary archive
<diwic> alkisg, +1, I'm seeing the same problem this morning
<alkisg> diwic: to solve it I put wget in a while loop... it succeeded that way :-/
<sarnold> alkisg: some mirrors had it, some mirrors didn't?
<alkisg> sarnold: yes, for example:
<cjwatson> There are only two hosts behind archive.c.c
<diwic> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic
<alkisg> 91.189.92.150 => not found, 91.189.92.191 found
<cjwatson> right, kudan has it, sadalbari doesn't
<cjwatson> I'll ask our sysadmins
<alkisg> Thank you cjwatson
 * dholbach hugs diwic
<diwic> dholbach, thanks, still unsure of what to do with it :-/
<i3d> The latest update seem to have changed the behavior of df output
<i3d> df does not print root filesystem anymore
<dholbach> diwic, I think that even if you can't upload a patch directly, it's still useful to check some of the patches and find somebody who can get them in - basically try to help nudge the patch along
<diwic> dholbach, or maybe redo them as SRUs
<dholbach> yes
<dholbach> many of the people who are submitting patches don't know all the correct procedures yet
<dholbach> so whatever helps them get their change in is much appreciated
<i3d> http://pastebin.com/AnW9g5zj would some wise minds take a look and see what might be the problem?
<cjwatson> i3d: strace -s 1024 please to see full strings.  but isn't /dev/sda5 your root fs?
<i3d> cjwatson: ok search on 12.10 bugs and I think I found it... https://bugs.launchpad.net/ubuntu/quantal/+source/mountall/+bug/1060296
<ubottu> Launchpad bug 1060296 in mountall (Ubuntu Quantal) "'df /' reports Filesystem '-'" [High,In progress]
<i3d> looks like it is a legit issue
<i3d> right that is my root fs... but after the latest update, it becomes -
<i3d> hopefully will get fixed soon..
<cjwatson> i3d: ah, right - yeah, Steve's working on that
<i3d> cool thanks cjwatson !
<elixey> i'm on ubuntu server 12.04 and running     cat /proc/sys/kernel/random/entropy_avail     will steadily decrease estimated entropy in the system
<elixey> btw, that stuff doesn't occur in debian 6.0
<elixey> why does it happen?
<elixey> what possible use could there be
<sarnold> elixey: it doesn't? o_O
<elixey> sarnold, have you triedit?
<sarnold> elixey: no debian machines around :/
<elixey> why wouild it happen in ubuntu sarnold
<mvo> cjwatson: sorry if that got answered already, but is someone looking at bug #1064545 - if not I can do that now
<ubottu> Launchpad bug 1064545 in update-notifier (Ubuntu) "package-data-downloader crashed with KeyError in convert(): 'paquetes'" [High,Confirmed] https://launchpad.net/bugs/1064545
<seb128> mvo, slangasek fixed that yesterday no?
<seb128> mvo, https://launchpad.net/ubuntu/+source/update-notifier/0.125
<seb128> https://launchpad.net/ubuntu/+source/update-notifier/0.126 fixes the build
<sarnold> btw, elixey's problem answered: http://lkml.indiana.edu/hypermail/linux/kernel/1004.0/01031.html
<mvo> seb128: oh, ok, the bug is not closed and no bug references, this is why I was confused, if its done, I will leave it as is
<seb128> mvo, sorry for breaking it, "it's just translations updates" ... you tricked me there :p
<mvo> seb128: ehhh, sorry !
 * seb128 hugs mvo, no worry
 * mvo hugs seb128 back
<seb128> mvo, on the good side Steve added tests for that issue so it will not happen again ;-)
<mvo> seb128: great!
<mvo> seb128: if you are certain its the one of the bug, would you mind closing the bug?
<seb128> mvo, doing it
<mvo> ta
<cjwatson> mvo: yeah, what seb128 said :-)
<seb128> mvo, it still feel weird that "$package" is marked as a string to translate when the translation should be "$package", it's a translator trap for sure
<cjwatson> Yes, it should be untranslatable; if you want to figure out how to make it so, I'm sure slangasek would appreciate it
<mvo> seb128: I haven't looked at this at all
<seb128> cjwatson: right, I'm pretty sure that if it's done this way it's because there is no trivial solution though :-(
<seb128> cjwatson, slangasek: one workaround could be to make the package build hack the pot at the end of the build to drop that string from the template so it wouldn't show on launchpad...
<ev> pitti: yeah, I was hopeful to look over a .crash file, but they're surprisingly absent on the retracer boxes.
<ev> pitti: I'll see if I can force it to happen again
<pitti> ev: oh, doesn't it download the report from somewhere?
<cjwatson> seb128: I bet this libgtk2-perl failure is related to https://bugzilla.gnome.org/show_bug.cgi?id=616997
<ubottu> Gnome bug 616997 in recent-files "gtk_recent_manager_add_item() is slow" [Major,Resolved: fixed]
<cjwatson> That's the obvious change in Gtk+ 2.24.12
<pitti> ev: AFAICS this coudl happen if you have an unicode (py2) / str (py3) object with characters < 32
<ev> pitti: apols, my brain is still warming up
<pitti> ev: is your retracer using py2 or py3?
<ev> I was thinking of the .crash file for apport-retrace itself
<ev> py2
<pitti> ev: ah, ok; that's relieving, as it really ought to work for py3
<seb128> cjwatson, http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=1070c5849e45433ad66c076e0bf692d936813a31 then ?
<ev> pitti: I think it's time to switch to py3 on them, once this issue is sorted
<cjwatson> seb128: Yeah, I suspect that commit broke it.  I'm having a look round to figure out how to adapt the Perl tests now
<cjwatson> (I suspect this is just a test bug)
<diwic> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<diwic> might continue later
<cjwatson> Though, I dunno, seems non-ideal that you can't call gtk_recent_chooser_set_current_uri right after gtk_recent_manager_add_item any more
<seb128> right...
<cjwatson> I guess because reload_recent_items hasn't been called
<cjwatson> But I suppose this is kind of the point of that bug fix - don't guarantee that items show up in the chooser immediately, because it's too slow
<cjwatson> Could just have the test forcibly emit the changed signal, maybe
<seb128> I'm still surprised it was that slow before (looking at the number on the bugzilla comments), even sequential adding for the entries shouldn't take that long... anyway those who fixed it this way know that part of GTK and probably did the right thing
 * cjwatson tries adding $manager->signal_emit('changed');
<cjwatson> That looks happier
<cjwatson> Result: PASS
<seb128> cjwatson, \o/
<cjwatson> I'll test that a bit more, send to upstream/Debian, upload
<seb128> thanks
<wmp> hello
<wmp> i have problem with linker and boost, i cant compile program. this is linker error and my package list: http://paste.ubuntu.com/1270735/ with: http://paste.ubuntu.com/1270737/
<cjwatson> Sweetshark: I've copied libreoffice from quantal-proposed to quantal; based on the changelog, does that mean that bug 1062448 can now be untargeted from quantal (if not closed)?
<ubottu> Launchpad bug 1062448 in libreoffice (Ubuntu Quantal) "soffice.bin crashed with SIGSEGV in lucene::index::IndexFileNames::fileNameFromGeneration()" [High,Triaged] https://launchpad.net/bugs/1062448
<glatzor> tyhicks, hello
<tyhicks> glatzor: Hi
<glatzor> tyhicks, I run an ecryptfs protected home dir on my debian wheezy system and run into the corrupted files on disk full error
<glatzor> tyhicks, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+%09690071
<glatzor> tyhicks, you mentioned that some patches to fix this problem have been applied in ubuntu. but I still get the problem with the patches applied
<glatzor> tyhicks, are there any further patches missing?
<tyhicks> glatzor: You applied the 3 patches mentioned at the bottom of that bug?
<jibel> jodh, I attached a more complete stack trace to bug 1060249 if it helps. It occurs on every upgrade.
<ubottu> Launchpad bug 1060249 in debconf (Ubuntu Quantal) "frontend crashed with signal 5 in free_pending_nulls()" [High,Confirmed] https://launchpad.net/bugs/1060249
<glatzor> tyhicks, right.
<jodh> jibel: thanks!
<glatzor> tyhicks, with the applied patches the command to fill up the disk failed correctly by a disk full error. I used dd if=/dev/zero of=disk-full bs=1M
<glatzor> tyhicks, but without the patches the dd command tries to write for ever
<tyhicks> glatzor: With the patches applied, it sounds like things are working correctly. Why do you think there is still a problem?
<glatzor> tyhicks, because I still get files of zero size in $HOME/.Private/ that cause problems
<tyhicks> glatzor: If you have DEBUG level kernel logging enabled, you'll still see a "Valid eCryptfs headers not found ..." message at times but then those files are properly handled now. Can you confirm that you're actually still getting zero length files and not just seeing that message in the logs?
<tyhicks> glatzor: FYI, see https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/957843/comments/22
<ubottu> Launchpad bug 957843 in eCryptfs "files in eCryptFS Private directory get corrupted" [High,Fix released]
<tyhicks> glatzor: Those two extra patches don't fix the problem that you're seeing, but they're needed if you carry the other three patches
<glatzor> tyhicks, Is it ok if I add this conversation to the bug? I will try with the other two patches
<tyhicks> glatzor: Sure
<tyhicks> glatzor: I'm going to have to step away shortly. If you're sure that you're still seing zero length files, please file an upstream eCryptfs bug at https://bugs.launchpad.net/ecryptfs/+filebug and I'll take a look at it tomorrow.
<tyhicks> glatzor: Please include the steps that you're doing to hit the bug and also what you're doing to verify that zero length files are still a problem after those patches are applied
<glatzor> tyhicks, thanks!
<tyhicks> glatzor: thank you!
<diwic> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic
<Riddell> pitti: were you not doing to delete the -kde-xx-base packages?  I still see them
<diwic> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> Riddell: hm, I thought I did
<pitti> Riddell: hmm, WTF; I did run that long remove-packages command; digging out the shell command and trying again
<cjwatson> pitti: do you think you could take bug 1061924?
<ubottu> Launchpad bug 1061924 in udev (Ubuntu Quantal) "Need Antenna quirks for some platforms" [High,Triaged] https://launchpad.net/bugs/1061924
<pitti> Riddell: do you still have the list of packages that you make? http://paste.kde.org/562928/ timed out
<pitti> cjwatson: hm, I guess udev is just about as wrong a package to put that in as any other?
<cjwatson> Quite ...
<pitti> that could be made a lot more elegant and efficient, but of course that'd need access to the actual hw
<cjwatson> I expect it would be very short if a udev rule rather than an upstart job
<cjwatson> (which seems to be what they're suggesting)
<pitti> the main issue is that these crappy workarounds tend to be sticky
<pitti> we'll never really get rid of them any more
<cjwatson> mm, if you want to punt it I have no problem with that - it's just on the foundations rls-q-tracking list and I wasn't totally sure what to do with it
<pitti> cjwatson: I'll ping jmleddy and see whether we can at least turn it into an udev rule on the PCI device
<pitti> that woudl be at least much less hideous than calling dmidecode, lspci, and twice grep
<cjwatson> Yeah
<pitti> cjwatson: followed up on the bug, subscribed, and pinged jmleddy
<cjwatson> thanks
<pitti> Riddell: removed for good now; https://launchpad.net/ubuntu/+source/language-pack-kde-aa/+publishinghistory and https://launchpad.net/ubuntu/+source/language-pack-kde-zh-hant-base/+publishinghistory both confirm
<pitti> hm, DEB_BUILD_OPTIONS=noopt seems to work for hardly any package these days :(
<xnox> pitti: file debbugs =)
<cjwatson> I thought that if anything noopt coverage should be improving due to dpkg-buildflags support
<pitti> yeah, that's what I thought as well; what does seem to work is CFLAGS="-g -O0" debian/rules build
<cjwatson> Using dpkg-buildflags is almost certainly the right fix for packages that fail to handle it
<cjwatson> If any such packages already use dpkg-buildflags, that's worth investigating
<spartan-11510> Hi
<spartan-11510> i've a litlle question on packaging. When you have a java software, do you create a shell for launh the software, because you must write "java -jar archive.jar"
<spartan-11510> ?
<Riddell> pitti: lovely thanks
<Sweetshark> cjwatson: untargeted, not closed for bug 1062448. I still have to investigate, if this still shows up in other more rare scenarios.
<ubottu> Launchpad bug 1062448 in libreoffice (Ubuntu Quantal) "soffice.bin crashed with SIGSEGV in lucene::index::IndexFileNames::fileNameFromGeneration()" [High,Triaged] https://launchpad.net/bugs/1062448
<dupondje> telepathy-haze types can't be configured in the Online Accounts?
<mpt> ev, could you kick off another graph update perhaps?
<ev> mpt: sure, though I'm likely to request a deployment of the view that http://poppy-dev.local has tomorrow
<cjwatson> Sweetshark: ok
<cjwatson> spartan-11510: You can use something like jarwrapper; http://www.debian.org/doc/packaging-manuals/java-policy/x85.html
<cjwatson> Or a wrapper script if you prefer, yes
<spartan-11510> cjwatson: thank's for your advice. i'll looking for jarwrapper
<ev> mpt: I'm getting OOM running the 12.04 variant (I'm also back populating the other graph at the same time), so I'll leave it as just 12.10 for now
<mpt> ev, you mean from calculating the "by 12.04 standards" line?
<cjwatson> spartan-11510: If you use javahelper, jh_exec can help with this.  See /usr/share/doc/javahelper/tutorial.html for a worked example
<ev> oh, are you asking me to update the graph on errors.ubuntu.com or poppy-dev.local?
<mpt> ev, e.u.c
<ev> right
<cjwatson> (I've not done this much myself - I just know where the tools are :-) )
<mpt> ev, to see if all mvo's bug fixes made a dent :-)
<ev> so then I mean that updating errors.ubuntu.com for 12.04 is using too much memory because I'm already updating poppy-dev.local for days gone past
<mpt> ev, you do the errors.ubuntu.com calculations on your own machine?
<ev> mpt: yes, because the cron job that would otherwise do them is broken
<mpt> I see
<ev> and I haven't gotten around to submitting a branch of memento to fix it
<cjwatson> Sweetshark: That bug doesn't seem to be untargeted ... you probably need to mark the quantal task won't-fix
<cjwatson> (with an explanation of course)
<mpt> ev, thanks for the update ... and here I was thinking the line might dip down :-/
<cr3> hi folks, are there projects that share common bzr ancestry upstream (lp:project) and downstream (lp:ubuntu/project)?
<pitti> I don't know any; for that to work, you'd need to force-overwrite the auto-importer UDD branch with a custom-created branch
<pitti> since bzr learned about "import-upstream" this should actually work
<pitti> but I'm not aware of anyone doing that yet
<pitti> so if someone knows a package that does that, I'm interested as well
<cr3> pitti: after every release, I sync checkbox from upstream to downstream by overwriting just about everything except .bzr/ of course. at that point, I was thinking of pushing lp:ubuntu/checkbox to lp:checkbox and use common ancestry from that point onward, at the cost of losing some bzr history
<xnox> cr3: no, but you can have your own downstream branch that does that.
<xnox> cr3: for a native package, that might actually work.
<pitti> cr3: we do use packaging branches derived from lp:project, but so far we have pushed them to e. g. ~ubuntu-desktop/indicator-applet/ubuntu instead of to lp:ubuntu/indicator-applet
<pitti> cr3: then you can just do "bzr merge" for updating to a new upstream version, etc.
<xnox> cr3: or you can simply request lp:ubuntu/checkbox to point to lp:checkbox. Any reason not to develop directly on the lp:ubuntu/checkbox and abandon the lp:checkbox?
<barry> cr3: you might get on #udd and ask there.  many of us have wanted something like this for forever
<pitti> if the packaging branch has the pristine-tar data, it should be okay to force-overwrite push it to the UDD branch
<pitti> xnox: not if lp:checkbox doesn't have the packaging
<pitti> upstream branches usually shouldn't have packaging
<cr3> xnox: yes, after FF, we still want to be able to push changes that won't necessarily land in the current development release of ubuntu
<xnox> and tags matching all versions ever uploaded in ubuntu/debian.
<xnox> pitti: *cough* lp:ubiquity
<pitti> xnox: that's native
<cr3> pitti: lp:checkbox does have packaging though, how's that a problem?
<pitti> well, I guess you could treat checkbox as native, too
<pitti> cr3: if it's only used in Ubuntu, and you don't need another packaging branches for PPAs etc., that's fine
<pitti> cr3: but "real" upstream projects don't, otherwise you'd have to maintain spec files, Debian, Ubuntu, and whatnot packaging all upstream
<xnox> for me the biggest problem was the upstream-tarball when $upstream-tag !=  tarball contents and therefore need for pristine-tar tarball commit on top of the tag and then somewhere down the line I was getting fileid conflicts =/ and I gave up.
<cr3> pitti: I think lp:checkbox is special in that it's native (has packaging) and  not native (lp:checkbox != lp:ubuntu/checkbox), which is something I'd like to cleanup at some point
<cjwatson> cr3: grub2 is mostly done that way except that I don't have the packaging branch in lp:ubuntu/grub2, but in a nearby branch
<cjwatson> cr3: while openssh isn't in bzr upstream, there's an import in lp:openssh and it's bzr all the way down to lp:ubuntu/openssh
<cjwatson> so yeah, openssh is pretty much an example of the kind you're looking for
<cr3> cjwatson: do you have a non-ubuntu branch somewhere for development that might only land in a daily ppa before going into lp:ubuntu/grub2?
<cjwatson> No
<cjwatson> I don't bother
<cr3> openssh sounds more similar then, I'll have a look at that project first
<cjwatson> For openssh, I have a separate tarball branch that I merge each upstream tag into and which corresponds to the various little differences in the released tarball
<cjwatson> grub2 is a bit more haphazard because I haven't yet bent the Debian maintenance branch entirely to my will
<cr3> cjwatson: I like what I'm seeing in the openssh branches, would it make much difference in my case if the debian/ directory was maintained both upstream and downstream?
<cr3> cjwatson: my motivation for maintaining it in both places is to have upstream packages built daily
<cjwatson> If you're doing that you're basically talking about a native package with occasional forks
<cjwatson> I think if anything that probably simplifies it
<cr3> cjwatson: exactly, forks usually happen from FF onwards
<cjwatson> Ah, indeed, checkbox *is* native per its versioning
<cjwatson> So yeah, as long as you make sure to tag lp:ubuntu/checkbox before each upload the importer probably shouldn't overwrite it
<cr3> cjwatson: indeed, but I think I'm doing some things that aren't strictly native. not sure what though
<cjwatson> But I would definitely start with the full upstream history rather than throwing it away in favour of the auto-imported package history
<cjwatson> Personally
<cjwatson> cr3: Not sure how you could be without an orig :-)
<cjwatson> cr3: The alternative is that you could do like we do in ubiquity: only use lp:checkbox, and between FF and release occasionally have feature branches or "next" branches or similar, which you can build in a PPA if you want too
<cr3> cjwatson: so, once quantal is released and we start with fresh packages for the next release, would that be a good time to talk to someone about replacing lp:ubuntu/checkbox with a fresh branch of lp:checkbox, so that both share the same ancestry from that point onward?
<cjwatson> Good time yes, but you don't need to talk to anyone about it - somebody with upload privileges can bzr push --overwrite
<cjwatson> OK, you might need to talk to your sponsor
<cjwatson> But not an admin or anything
<cr3> cjwatson: I think my team likes the separation between lp:checkbox and lp:ubuntu/checkbox, except for the lack of common ancestry that's making patching time consuming and error prone
<cjwatson> Yeah
<cjwatson> It's simpler for native packages because it's just bzr merge and you don't bother about quilt patching or similar
<cr3> cjwatson: ok, roadmr might have upload rights by then but we'll make sure to talk with a sponsor beforehand just to be extra sure
 * cr3 should also fill paperwork to have upload rights one of these days
<cr3> pitti, xnox, cjwatson: thanks for all the advice, much appreciated!
<cr3> barry: I had a python question for you: map() returns a list in python2 and an iterator in python3, so I was wondering if there was a naming convention to make it clear whether a function I write returns a list or an iterator.
<barry> cr3: nope :)
<cr3> barry: this could easily be mentionned in the docstring of the function, but it's annoying to have to read the docstring every time someone just wants to call something like get_foos
<barry> cr3: you could always just treat the return as an iterator, and list()-ify it if you needed a concrete list.  it does some wasted work in py2, but is at least consistent
<xnox> cr3: there are ~15 tags missing in lp:checkbox as compared with lp:ubuntu/checkbox probably the "post-ff-mini-forks", so for history/archive I'd push lp:ubuntu/checkbox to lp:~/ubuntu/quantal/checkbox/old-branch or something
<xnox> cr3: although, lp:ubuntu/quantal/checkbox will be your history if you do it right after release. so ignore me.
<cr3> barry: the problem is that I've seen this degrade into people either always returning lists (return list(map(float, results))) or always calling list() to check for the length (if list(get_foos()))
<xnox> barry: did I not see apis .get_iter() .get_items() for such cases?!
<cr3> xnox: right but, just for my edification, what tags might I be missing? a tag everytime the version was bumped?
<xnox> cr3: http://paste.ubuntu.com/1271221/
<cr3> xnox: I would be afraid of falling into hungarian notation that way :(
<barry> xnox: well, iter(obj) would be the api for .get_iter() right?
<xnox> cr3: '-' missing in the trunk. '+' extra tag in the trunk.
<barry> i guess it depends on whether the api really (usually) wants concrete lists or iterators... or both :)
<xnox> barry: well, actually to be memory efficient by default i'd do the other way round. call list() for the .get_items() such that my iter api is actually yield statements for performance.
<barry> xnox: me too.  i think that's the rationale for python3 by default returning iterators
<cr3> xnox: yes, some changes upstream were backported downstream into new versions. does that make sense?
<barry> call list() if you need a list (or tuple() etc as the case may be)
<cjwatson> I would tend to not bother with a list variant.
<doko> infinity, https://launchpadlibrarian.net/119386939/buildlog_ubuntu-quantal-armhf.mercurial-buildpackage_0.9_FAILEDTOBUILD.txt.gz
<xnox> barry: i've seen another pattern of returning a single item or list of items. And the code everywhere to check if not isinstance list result = [item] *sigh* to _always_ have lists...
<doko> dpkg-shlibdeps: warning: /lib/arm-linux-gnueabihf/ld-linux.so.3 has an unexpected SONAME (ld-linux-armhf.so.3)
<doko> dpkg-shlibdeps: error: no dependency information found for /lib/arm-linux-gnueabihf/ld-linux.so.3 (used by debian/mercurial-buildpackage/usr/bin/mercurial-tagversion)
<barry> xnox: sigh ;)
<cjwatson> I think I looked at that mercurial-buildpackage failure and it went into my WTF bin
<infinity> doko: Is it shipping pre-compiled binaries?  That's the only way that can happen.
<doko> infinity, no
<infinity> doko: Well, it just plain can't be getting any of its own binaries linked with that SONAME if it's all built fresh.  Unless it's using a broken compiler.  Did we fail to fix one? :P
 * infinity looks.
<doko> infinity, using haxe
<infinity> doko: So, yes, we failed to fix a compiler.  Fun.
<cjwatson> With one (1) reverse-build-dep.
<infinity> Luckily, that's literally the only thing that build-deps on it.
<cjwatson> Niche.
<infinity> Heh.
<infinity> Oh, and it likely doesn't even need patching, just rebuilding.
<infinity> I'll give that a quick whirl in a sec too.
<infinity> doko: Thanks for the heads-up.
<cjwatson> Where's it even getting the linker path from?
<cjwatson> No relevant matches for ld- or ld.so anywhere ...
<infinity> I don't find it in the source, so I'm guessing it hunts it down during build time, then hardcodes it for future linking.
<xnox> cr3: well cherry-picked. yeah =)
<infinity> I didn't bother looking too hard, cause I suspect a rebuild will magically fix it.  We'll see.
<cjwatson> It might actually be in neko instead.
<infinity> Oh, is haxe just a frontend to evil?
<infinity> Indeed, it may be.
<infinity> dpkg-source: info: applying debian-changes-1.8.1-6ubuntu1
<infinity> ^-- We're pro.
<cjwatson> Not that I see a linker path in neko either ...
<infinity> No, but neko does seem like a more likely candidate for doing real work.
<infinity> I'll play with both.
<cjwatson> Yeah, maybe it does some godawful build-time thing to work out the linker path.
<cr3> barry: is calling list() on something that is already a list a noop until it is modified, copy-on-write, or is a completely new list always created?
<barry> cr3: a completely new list object is created
<barry> >>> x = list((1, 2, 3))
<barry> >>> y = list(x)
<barry> >>> x is y
<barry> False
<barry>  
<cr3> barry: thanks! I should've tried that myself :)
<xnox> barry: hm... if only this would happen to kwargs & dictionaries passed to functions.... so confusing. but I am now used to "abusing" that for fun and profit =)
<barry> xnox: right, that's kind of a different effect.  default arguments are evaluated at def time
<iainfarrell> kthxbai
<slangasek> mvo: ping re bug #1016643
<ubottu> Launchpad bug 1016643 in apt (Ubuntu Quantal) "add-apt-repository downloads gpg key in an insecure fashion" [High,Triaged] https://launchpad.net/bugs/1016643
<mvo> slangasek: about if that needs a apt-key patch as well? I would appreciate double checking the diff I put in there and welcome feedabck from https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1016643/comments/12 - I would love to be able to disable it in adv as well
<ubottu> Launchpad bug 1016643 in apt (Ubuntu Quantal) "add-apt-repository downloads gpg key in an insecure fashion" [High,Triaged]
<slangasek> mvo: right, the question is whether more is needed than the software-properties fix.  I'm coming to this a little cold, I mostly just know that it's on our quantal bug list - how does 'apt-key adv' relate to software-properties?
<slangasek> ah, that's how s-p invokes apt-key
<slangasek> mvo: so what's insecure about the current behavior?
<bdmurray> cjwatson: so using your test on quantal I received the following message from apt 'W: Some index files failed to download. They have been ignored, or old ones used instead.' and then I ran 'chdist apt-get captive-portal update' again but without the proxy and it succeeded
<cjwatson> bdmurray: That sounds basically awesome
<bdmurray> I'll do some looking at bug reports to see if I can find any recent incidents of the bug too
<stokachu> infinity: http://paste.ubuntu.com/1271408/
<ev> pitti: finally able to reproduce it on one of the retracer boxes. It's gdb hitting a corrupt stack, as far as I can tell
<ev> http://people.canonical.com/~evand/tmp/f269837a-116f-11e2-9d07-2c768aafd08c.crash
<ev> pitti: a retrace on my local machine produces http://paste.ubuntu.com/1271445/
<ev> but on the retracer we get ?^VQ^H just below __PRETTY_FUNCTION__
<pitti> ev: oh, so that works?
<pitti> ev: is the errors.u.c. retracer running under LANG=C?
<ev> I tried that locally - no such luck (LANG=C)
<ev> I even built a precise chroot
<ev> but I can only trigger it on the retracers
<ev> it's definitely the gdb output though
<ev> the quantal version of gdb has a better message:
<pitti> ev: I don't see broken strings in that .crash file, I guess that's why it didn't trigger
<pitti> ev: anyway, I'll play around with that tomorrow morning, I'm about to run out for today
<ev> pitti: "Cannot access memory at address 0x100000007"
<ev> pitti: sure thing - thanks!
<ev> (which is why I was led to believe it might be a combination of running precise and something else that causes it to surface on the retracer box)
<ev> that message appearing just below __PRETTY_FUNCTION__ that is
<pitti> good night everyone!
<ev> g'night pitti
<ion> nighte
<ev> mpt: october 5th was the first day we had the separate counters for each problem type
<ev> and that landed part way through the day
<ev> so I'll just need to go back and redo that day
<darkcrow666> Hi !
<darkcrow666> What do you have in mind when you still use compiz ?
<bdmurray> seb128: could you have a look at bug 1048059?
<ubottu> Launchpad bug 1048059 in udisks (Ubuntu) "Unable to mount" [Undecided,Confirmed] https://launchpad.net/bugs/1048059
<Kano> hi, where is that gcdx64.efi file mentioned in the grub2 changelog?
<Kano> found it, most likely you lost
<Kano> chain can load any efi binary
<Kano> where is shim
<Kano> the signed version of course ;)
<stgraber> Kano: apt-get install shim-signed
<Kano> good, i guess i have to use kvm to verify what i think, but most likely your system is broken
<slangasek> Kano: my understanding is that the load_image call goes through the SB verification chain
<Kano> why would you use the linux call?
<Kano> i have got no interest in using it. but chainloader
<slangasek> I didn't say anything about linux
<Kano> ok, why did you patch efilinux in it?
<slangasek> sorry, what are you talking about?
<slangasek> you were asking about shim and gcdx64.efi
<slangasek> that's nothing to do with efilinux
<Kano> yes, can that includes chain(loader)
<Kano> with chainloader you can start efi binaries on an efi system
<slangasek> yes, and chain uses load_image, and load_image fails if the image doesn't verify
<Kano> verify against what? do you check now signatures for the kernel?
<Kano> at least you could not verify any initrd
<slangasek> Kano: if you find an exploit that allows unsigned code to be run in BootServices, please let us know and we'll fix it
<Kano> would not help anything if it is a binary that is out now
<slangasek> of course it would
<Kano> btw, in the ubuntu + debian grub 2.00-7 is a stupid bug
<Kano> or better 2 bugs
<Kano> http://kanotix.com/files/fix/efi/grub-2.00-7-debian-bugs.txt
<Kano> one thing is, it calls efibootmgr even if grub-pc is installed but the system is booted via efi (not necessaryly via grub)
<slangasek> Kano: we have a bug tracking system, please report these there
<Kano> the other thing is, the use of -w is not needed and absolutely critical when you use a hd with mbr
<Kano> it kills the serial
<Kano> you can use efi partition with mbr hd as well, it just needs to be a primary one
<Kano> with those 2 bugs combined you get directly a system that only boots grub, no win, no other bootloader you specified because the serial of hd is used inside the nvram
<Kano> and inside win bootloaders
<Kano> as soon as you install that grub
<Kano> bbl
<seb128> bdmurray, hey, I will have a look, thanks for pointing it
<bdmurray> seb128: thanks I've an upgraded system where /media/$username/ doesn't exist if that is any hlep
<seb128> bdmurray, well, that's not an issue, they should be created by udisk when needed
<seb128> bdmurray, it's rather a pitti's topic (he maintains the udisk stack) but I will check the bug details and see with him
<jibel> SpamapS, is bug 1021471 fixed for you with kernel 3.5.0-17.28 ?
<ubottu> Launchpad bug 1021471 in Linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
<SpamapS> jibel: I haven't had a chance to fully test it yet
<jibel> I still get it with lxc
<SpamapS> jibel: hard because I have to test with b43 instead of wl which is.. less than reliable ;)
<SpamapS> jibel: do you have a wl based network connection?
<jibel> SpamapS, no, I've a wired connection
<SpamapS> jibel: and does refcount == 2 ?
<jibel> driver is an r8169 exactly, refcount = 1
<SpamapS> jibel: its possible other drivers than wl have the problem. :-/
<SpamapS> jibel: only way to tell is to run 3.6 and make sure the problem is gone there
<SpamapS> or at least, that is one way
<SpamapS> anyway, need to get lunch... starting to hear rumbles
<jibel> I'll try on another machine, but on my main desktop I can reproduce it very reliably just by creating an lxc container and shutting it down with poweroff
<jibel> SpamapS, ack, I'll try 3.6
<slangasek> smoser: hey, so is mountall looking happy for you now?  I'm feeling a little disoriented with no mountall bugs from you in my queue and fear that something is wrong ;)
<Daviey> hah
<Daviey> slangasek: He understood that for any change he wanted, you mandated a fork removal. :)
<slangasek> heh
<smoser> i actually havne't tested your latest.
<smoser> let me check.
<slangasek> heh, ok :)
<ScottK> Not testing is the easiest way not to get bugs.
<mlankhorst> Testing is the easiest way to get bugs?
<ScottK> No, convincing someone else to test is often easier than testing yourself.
<Sweetshark> anyone with glib knowledge around?
<geofft> Is pesign / sbsign / something Debian-packaged already perchance?
<geofft> (I noticed shim was packaged recently.) The packaging is probably trivial, but it'd be nicer to just use Ubuntu's :)
<cjwatson> geofft: sbsigntool, yes
<geofft> aha, singular, unlike the thing on OBS. Thanks!
<cjwatson> the upstream name is singular :)
<psusi> cjwatson, you think porting partman to parted3 will happen for 13.04? ;)
<cjwatson> psusi: dunno, I guess we should get round to it
<cjwatson> but now is the worst time to ask
<psusi> it seems I'm going to become co-maintainer of parted
<cjwatson> Then perhaps you might like to help with porting partman :)
<cjwatson> Not sure where I put that preliminary patch
#ubuntu-devel 2012-10-11
<icedtea> Anyone know how to fix this? E: Couldn't download packages: python-minimal python2.7-minimal sysvinit-utils
<icedtea> when running pbuilder create
<icedtea> oh nevermind
<pitti> Good morning
<pitti> bdmurray: followed up to bug 1048059
<ubottu> Launchpad bug 1048059 in udisks2 (Ubuntu) "Adding ACLs to /media/$user does not work" [Undecided,Incomplete] https://launchpad.net/bugs/1048059
<pitti> Riddell: btw, did you see my response to your apport-kde patch? it's still dubious to me
<pitti> ev: apport-retrace crash> reproduced in a test case, and fixed in http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2514
<pitti> ev: you are running retracers out of trunk, I presume? so this should just work
<dholbach> good morning
<iulian> Morning dholbach.
<dholbach> hey iulian
<mvo> ev: quick question - I use the recoverable errors mechanism in software-center right now to learn about the failure that people get when installing stuff - I would like to break it down further, can I use a string like "resolve-failed", "no-policykit" etc for the error and send that as "Traceback" or does it need a real traceback, i.e. will I just have to make up a bunch of exception? the ration is that it current just sends a TransactionFaile
<mvo> d which apparently put them all into the same bucket
<mvo> ev: or can I have some other "signature" mechanism to help the thing that looks for the dupes to sort them into the right buckets?
<mpt> mvo, while we're on that subject, can you explain the difference between what you're using RecoverableError for, and the built-in <https://wiki.ubuntu.com/ErrorTracker#install-fails>?
 * mpt wonders if it's actually that the latter isn't implemented yet
<mvo> mpt: the s-c mechanism will kick in even if no apt/dpkg is touched, i.e. if there is no policykit authentication agent running in the session or if there is a dependency resolve failure
<Riddell> pitti: yeah I'm not entirely convinced by the apport change but it seemed to work
<pitti> Riddell: but dropping the sys.exit() seems wrong, it always exits with 0 now?
<mpt> mvo, does that mean it's possible for a single installation request to trigger both errors?
<mpt> (ev is afk atm)
<Riddell> pitti: I just copied what apport-gtk does, that has no sys.exit()
<pitti> Riddell: hm; curious that the sys.exit() causes a problem
<pitti> Riddell: what's the crash anyway? I do get an error message, but I get it no matter whether it calls sys.exit() or not
<pitti> python3: Fatal IO error 2 (Datei oder Verzeichnis nicht gefunden) on X server :0.0.
<pitti> Riddell: that's "(file or directory not found)"
<tsdgeos> is there any chance the poppler 0.20.5 that i released yesterday finds it way to quantal? it has lots of crash fixes that could be CVE classified if we issued CVEs :D
<mvo> mpt: I need to double check - it could be
<Riddell> pitti: it's a crash somewhere in the python binding code, previously it ran sys.exit then it ran the qt mainloop which confused it
<pitti> Riddell: the qt mainloop was dead code; sys.exit() doesn't return
<cjwatson> apw: So, the desktop amd64 image should now boot with a signed kernel, assuming I got the scripting right at oh-god-o'clock last night, but the server image is a different story
<cjwatson> apw: What do you think about having linux-signed emit a kernel-signed-image udeb?
<espirit> Hello. ATI legacy driver is not working properly on toshiba l500. Unity is failing to start and screen resolution is broken.
<apw> cjwatson, well i guess i'd have to make it manually (the udeb), but i guess its feasable
<Riddell> pitti: hmm, and now I add it back the crash doesn't occur :(
<cjwatson> apw: It'd basically be a vector for getting it into /dists/quantal/main/installer-amd64/current/images/
<apw> cjwatson, is there somewhere i can read about what has to be in a udeb
<cjwatson> Just ship /boot/vmlinuz-*
 * apw pokes the nest to see what happens
<cjwatson> There's doc/devel/modules.txt in the d-i source tree but it's probably not hugely useful for kernel stuff
<cjwatson> Put Package-Type: udeb, Section: debian-installer, Priority: extra in the control stanza
<cjwatson> Call it kernel-signed-image-$(ABI)-di
<cjwatson> Should basically be it
<apw> ok ... sounds doable ...
<mvo> ev: aha! DuplicatesSignature is the one I can use I guess - I will try that nw
<apw> cjwatson, http://people.canonical.com/~apw/misc/linux-signed-image-3.5.0-17-generic-di_3.5.0-17.28+signed2_amd64.udeb does that look like the sort of thing?
<cjwatson> apw: linux-signed-image -> kernel-signed-image please to match the kernel-image udeb
<infinity> apw: Except that, for whatever reason, the naming con... yeah.
<cjwatson> Fairly historical but it would help my sanity some
<apw> yeah no problem
<apw> so dh seems to grok udebs, i am slightly supprised
<cjwatson> Yeah, ages ago :)
<infinity> debhelper and debian-installer both sprung from the same bearded mind, it would be odd if they didn't get along.
<cjwatson> Most of the d-i packages tree is dh(1) with rather few overrides these days
<cjwatson> apw: Possibly add "Provides: kernel-signed-image" for reasons to do with the d-i build system I haven't had enough coffee to explain properly :-)
<apw> cjwatson, i am in your hands, whatever you need :)
<cjwatson> (I can't remember if that's strictly needed but it would be regular and wouldn't hurt)
<cjwatson> apw: Everything else looks fine
<cjwatson> Though obviously the proof will be in actually managing to construct images using it
<cjwatson> But probably simplest to do that with it in the archive - I see no other structural problems
<infinity> cjwatson: Were you going to try to make netboot work with SB too, or is that way out of scope for the next N hours before you give up on quantal? :P
<cjwatson> infinity: This should handle netboot as a side-effect
<cjwatson> With any luck
<infinity> Cute.
<cjwatson> infinity: Well, the netboot mini.iso
<Daviey> please don't break it :)
<infinity> Yeah, I was thinking actual netboot.  I assume SB also diddles with PXE?
<cjwatson> infinity: Actual netboot will take longer - I have a to-do item to test GRUB efinet
<cjwatson> infinity: UEFI netbooting is a kind of separate thing with its own protocol stack
<infinity> This doesn't surprised me.
<infinity> Nor surprise.
<cjwatson> I've only stuck my toe in it so far
<infinity> But it doesn't also provide a PXE emulation layer?
<Daviey> cjwatson: How well standardised to you expect it to be?
<infinity> Oh, but maybe enabling such a beast wouldn't require signed images.
<cjwatson> infinity,Daviey: no idea to either of those, would have to read the spec in detail
<cjwatson> which I do not have time for right now :)
<infinity> Daviey: It's bound to be more standardised than PXE.
<apw> Daviey, that sounds like a server thing, i think i'd ask Daviey about it :)
<cjwatson> My breakfast is more standardised than PXE.
<infinity> Daviey: Which is basically just "the world attempting to mimick Intel's behaviour, badly".
<Daviey> apw: he's a joker, who doesn't know jack.
<apw> Daviey, we'll have to introduce him, jack is a nice fellow
<Daviey> infinity: with arm doing it worse :)
<infinity> cjwatson: Anyhoo.  Sounds like another d-i upload in the offing, there's an armadaxp ABI bump building, if you'd like to do that too.
<cjwatson> infinity: So, if we're lucky, it works in the signed images, with some configuration yet to be determined.  If we're unlucky, R + quantal-updates.
<cjwatson> infinity: Yeah, was on my list.
<infinity> Daviey: u-boot's PXE emulation was a last-minute hacking "here, have this, cause you're a bunch of whiney gits who don't think that bootp+tftp is cool enough for you", don't complain about it. :P
<infinity> Daviey: Real UNIX admins <3 bootp+tftp.
<apw> infinity, it was a simpler time
<Daviey> infinity: I was one of the whiney poeple that complained the pxelinux implementation didn't respect enough of the pxelinux standard :)
<mlankhorst> infinity: yeah I set up my wndr3800 router for that, it points netboot to my boot server :-)
<infinity> Daviey: It's almost kinda halfway functional now, thanks to all of the bugs/whining from your team.
<mlankhorst> netboot ftw
<infinity> Daviey: Nowhere near as feature-complete as actual PXE (and never will be), but it seems to mostly DTRT now.
<apw> cjwatson, ok if you are happy i'll chuck this in the queue
<cjwatson> apw: Yep
<cjwatson> apw: Do you think there's any hope at all of bug 1065263 getting in, or are we toast at this point?
<ubottu> Launchpad bug 1065263 in linux (Ubuntu) "wrong stride for efifb on some systems" [High,Triaged] https://launchpad.net/bugs/1065263
 * apw will look at the fixes there next
<cjwatson> Basically hunting for ways in which we might manage to QA the server image on SB
<cjwatson> Though we may end up waiting for stgraber to unpack on Friday anyway
<Daviey> cjwatson: I didn't think Server/SB was a requirement for 12.10?  Is it compelling to squeeze it in?
<cjwatson> I'd been given to understand that some level of SB support was a requirement across the board for 12.10
<cjwatson> Daviey: feel free to clarify with Rick
<cjwatson> Plus, it should be nearly there anyway
<cjwatson> (Except netboot, which is an unknown quantity)
<Daviey> cjwatson: I'm not pushing against it.. I thought when we discussed it before, it was a Destkop deliverable for 12.10... :)
<cjwatson> I guess I've run into bureaucracy again.
 * cjwatson goes for breakfast and coffee
<Daviey> But weehaaa, value added :)
<mvo> mpt: I fixed that it would also report dpkg errors now, thanks for this hint
<mpt> mvo, you mean that before it would, but now it won't?
<mvo> mpt: yes
<mpt> ok
<cjwatson> Daviey: it's just, things I don't want to be doing a week before release rather than fixing RC bugs:
<cjwatson>  * arguing about whether something is a required deliverable or not
<cjwatson> if somebody else wants to do that and tell me the answer, awesome
<Daviey> cjwatson: That is what i was /trying to help with.  If it's something that isn't needed, perhaps time is best spent elsewhere?
<cjwatson> and you may well be right; but OTOH I'd be surprised if the efifb bug didn't show up in some desktop use cases too
<Daviey> (shrug*
<cjwatson> I really like to get the server installer working because it's a lot easier to debug than ubiquity, too
<cjwatson> Plus don't like leaving jobs incomplete
<Daviey> right!
<Stecchino> unity-2d seems to mess with drag and drop within my Qt application. Anyone know how to prevent/fix this?
<doko> pitti: would you care if I point some gnome/gtk/vala universe issues?
<pitti> doko: I'd rather you send them #ubuntu-desktop-wards, TBH
<pitti> I can look into an FTBFS or two, but I'm already doing more disto work than intended
<cjwatson> doko: (pitti isn't desktop team any more)
<doko> cjwatson, but vala specialist ;)
<pitti> steep career -- touch vala once, and you are a specialist :)
<cjwatson> If somebody could fix avant-window-navigator, I'm really reluctant to remove that since I get the impression it's widely used
<cjwatson> That'd probably be one of the more valuable things to do
<pitti> uh, I remember looking at that at the beginning of precise already
<doko> cjwatson, I don't see the ftbfs ...
<cjwatson> It doesn't fail right now, but it requires a version of vala that's slated for removal
<cjwatson> It's on the ubuntu-archive bug list
<Stecchino> my d'n'd problem is prevented when the dock is not hidden. Turned of auto-hide for now. But supprised there is no bugfix
<lool> cjwatson: UEFI bricks Samsung laptop bug > I've attempted to identify x86 UEFI contacts at Samsung by pinging Samsung folks working on UEFI for ARM, but no luck so far; we're now passing the bug to their management in case they know someone but Samsung is so big...
<cjwatson> Thanks
<doko> sse2 isn't default, even for amd64???
<doko> hmm, seems so
<tsdgeos> what's the command to know which packaging branch a package has?
<jml> pitti: btw, I've commented on your unittest blog post. I've got an answer that I think you might like.
<tsdgeos> pitti: i have a patch for 0007-add-lightdm-support.patch in accountsservice that you originally did (or so says http://anonscm.debian.org/gitweb/?p=collab-maint/accountsservice.git;a=history;f=debian/patches/0007-add-lightdm-support.patch;h=da802bd00494292baa5c512adcb550a6f7b3b08b;hb=HEAD ) what do i do with it?
<pitti> jml: hey, thanks; vila was just pointing out testtools as well, thanks!
<pitti> jml: I'll mention this when I bring this up with upstream, whether they like that additional module
<pitti> jml: it's indeed a lot more elegant
<jml> pitti: thanks. all that is pretty much lifeless's design. now that I've been using it, it's very hard to go back.
<pitti> tsdgeos: it's from mterry; I suggest you attach it to a bug, and then we assign that to Mike?
<tsdgeos> ok, works for me
<pitti> tsdgeos: thanks!
<tsdgeos> tx
<jml> pitti: making things out of composable pieces turns out to be a great idea
<pitti> jml: indeed; and it would have been surprised if I were the first one to run into this
<pitti> jml: *want in py3 by default*
<jml> *sigh*
<jml> I've had difficulty getting stuff into Python
<jml> but very much support it in principle, and we've made sure the licenses are all good for that.
<jml> I guess that's mostly because I've been lazy, and not super willing to engage on python-ideas.
<xnox> jml: talk to barry and jobs done ;-)
<pitti> jml: oh, http://pkgs.fedoraproject.org/cgit/python-testtools.git/
<pitti> jml: so it's in Debian, Ubuntu, Fedora -- good 'nuff :)
<pitti> jml: (but would still be nice, of course)
<jml> pitti: oh neat.
<pitti> jml: they don't seem to build it for py3, though
<ev> mpt: the graph is fixed: http://poppy-dev.local/
<jml> pitti: a shame.
<jml> pitti: because we take Python 3 support pretty seriously
<pitti> jml: yeah, and I write pretty much everything in py3 these days, so let's see how much that hurts with getting tests upstream ;)
<ev> well, I still need to change the calculation to make "by 12.04 standards" be "all collected" - "recoverable problems", but the 5th is back to normal
<jml> pitti: good grief, I think you're the first person I've heard say that.
<pitti> jml: really? we have made great progress in py3-ification in quantal
<mpt> ev, brilliant
<pitti> jml: in a default install we are down to two packages that use py2 still, I think (systme-config-printer and ubuntuone)
<jml> pitti: I guess most of the people I talk to don't target quantal for their work.
<cjwatson> If launchpadlib were ported I'd use py3 for everything.
<jml> cjwatson: oh. hmm. interesting. I've got a half-formed plan to burn launchpadlib and have some kind of phoenix rise from its ashes.
 * cjwatson dislikes non-incremental plans :-)
<jml> cjwatson: yeah, me too.
<jml> cjwatson: but there seems to be a fad for porting things to new APIs and languages for incremental benefit
<doko> infinity, cjwatson: did you give back google-glog this morning? failed again, but builds locally ;-/
<cjwatson> doko: no
<Daviey> can't we just have it in a non-python language ?
<jml> Daviey: like Python 3? :P
<mpt> ev, it won't matter once "by 12.04 standards" is dotted, but for now it might be clearer if "all collected" was layered on top instead of underneath.
<Daviey> jml: No, like erlang.. or soemthing
 * cjwatson looks sidelong at Daviey
<jml> cjwatson: more seriously, writing testable code that performs well with launchpadlib is way trickier than it has to be, and I think that's a direct result of the Python API making network calls appear transparent.
<cjwatson> jml: I think what concerns me is the ordering of your plan.
<doko> pitti: if you want to help with systme-config-printer ... there's still a dependency which needs conversion
<jml> cjwatson: ashes first, phoenix second?
<cjwatson> Something new's all well and good, but launchpadlib is production code and we can't afford to have it die before any replacement is ready.
<jml> cjwatson: oh yeah, sure, I didn't actually mean kill launchpadlib. I don't know how I would even do that or what it would mean.
<jml> I guess a new release of launchpadlib that totally broke API compatibility would do the trick. I don't know why anyone would do that though.
<ev> mpt: fixed
<pitti> ev: hey Evan, how are you? did you see my apport ping this morning?
<mpt> splendid
<ev> pitti: I didn't until you mentioned it just now
<ev> wonderful!
<ev> thanks so much
<pitti> no worries
<ericbutters> hi. init: mounted-proc main process (1268) terminated with status 1
<ericbutters> anyone?
<barry> jml, pitti talk to me!  we're starting to look for fun projects for py3.4 :)
<ericbutters> got that w/ 11.10 12.04.1 and 12.10 beta2
<ericbutters> btw, ubuntu-core
<jml> barry: put testtools & fixtures into core Python.
<jml> barry: also, if you could make function definition an expression that'd be great too.
<jml> barry: the bit of testtools under discussion here is the 'details' API, which allows attaching arbitrary content to test results.
<barry> jml: the first two would be great.  the last would be cool too, but probably harder to get through the gauntlet.  but that's the kind of big ideas we're looking for.  have you seen the recent discussion on generator based concurrency?  we have a group of 4 dc pythonistas ready to sprint on big fun stuff
<jml> barry: no, I haven't. I assume dash's post was relevant though <http://washort.twistedmatrix.com/2012/10/coroutines-reduce-readability.html>
<jml> barry: oh, actually, if you want bonkers crazy big ideas, I've got two more:
<jml> barry: persistent (i.e. immutable) data structures ala Clojure. (esp for dicts)
<jml> barry: do something about the Python module system: http://washort.twistedmatrix.com/2011/01/modules-in-python-good-bad-and-ugly.html (see also follow-ups)
<barry> jml: that's a very nice blog post.  current thinking is generator-based with 'yield from' being an enabling syntax in 3.3.  the examples i've seen so far are (imho) much easier to read and reason about than deferred/callback style.
<jml> barry: so, with iterCallbacks at least, you can't easily express "do a & b concurrently, and when they are both done, do c"
<jml> barry: and that's pretty important.
<barry> the module post is interesting.  i think 3.3's switch to importlib provides a great opportunity for more experimentation.  there is almost no built-in magic any more (the sys caches are still there, but we have thoughts about how to get rid of some if not all of them.  to radical for 3.3, but maybe we can do something about them in 3.4)
<barry> jml: these are all great ideas.  exactly the kind of thing we're collecting
<jml> barry: glad you think so. :)
<doko> jbicha, in June you synced google-glog, dropped ubuntu changes, and didn't look at the build failure :-/
<jml> barry: re immutable data structures, that can be done easily enough without language changes, but to do it fast probably requires CPython extensions.
<barry> jml: do you have a reference for that?
<doko> now looking at the arm build failures too
<jml> barry: and, also, you wouldn't believe how many things there are on PyPI that implement dict helpers.
<jml> barry: reference for what exactly?
<barry> clojure's immutable data structures
<jml> barry: oh, umm, not really. it's a btree that shares structure. I think it's actually a solution to an exercise in Cormen's "Intro to Algorithms". https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentHashMap.java
<jml> barry: and there's an explanation of how it works in _The Joy of Clojure_.
<barry> jml: cool
<jml> barry: actually, iirc, dash wrote a pure Python implementation.
<doko> jtaylor, Riddell: could you have a look at the komposer ftbfs on i386?
<Riddell> doko: despite its name, there's nothing KDE in that package :)
<doko> ohh :-/
<ScottK> You probably want micahg or someone that knows mozilla stuff.
<ericbutters> anyone here use ubuntu-core armv7hfp?
<ogra_> ericbutters, some do, its a cheap way of getting a chroot (not of much use for anything else since many bits are missing for a proper rootfs though)
<ericbutters> where can i find xubuntu (xfce) or lubuntu for arm?
<ogra_> we only build images for a few arches, on what SoC are you trying to run it ?
<ericbutters> S5PV210 (samsung)
<ericbutters> i got fedora-arm console image running
<ericbutters> and installed lxde
<ogra_> http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/20121008/quantal-preinstalled-desktop-armhf+ac100.tar.gz has a lubuntu tarball ...
<ericbutters> orga_ thank you.. i will try.. did you read my first post regarding mounted-proc?
<ogra_> after untarring run: touch <dir or mountpoint>/var/lib/oem-config/run
<ogra_> ericbutters, most likely you are missing config options,. the tarball is originally for the ac100, look in /boot/ for the configuartion file and compare it to your config options
<ogra_> (modulo the arch specific oprions indeed)
<ogra_> ericbutters, oh, and there is an #ubuntu-arm channel btw
<ericbutters> ogra_ ui :) nice!
<stgraber> cjwatson: oh, btw, one thing I noticed yesterday. We're adding memtest86 to grub even on EFI systems, but it requires linux16/initrd16 which don't exist
<cjwatson> stgraber: awesome
<cjwatson> stgraber: I'll fix that
<stgraber> cjwatson: thanks
<barry> mvo: i'm sorry, i'm not sure if we finished our discussion from yesterday about python-apt
<ScottK> doko: For google-glog is there a reason you only changed the build-dep to add it for i386 and not arm* as well?
<doko> ScottK, still ftbfs with it
<ScottK> OK.  Thanks.
<cjwatson> mvo: Does bug 1056752 still need to be open in Ubuntu?
<ubottu> Launchpad bug 1056752 in Ubuntu Quantal "Package description translations export not working" [High,Triaged] https://launchpad.net/bugs/1056752
<mvo> cjwatson: closing it now, that is fixed and uploaded
<cjwatson> Thanks
<mvo> barry: I think I'm good with python-apt, thanks. I ran into another aptdaemon issue today and tracked it down to http://paste.ubuntu.com/1273298/ - py2 seems to be rather unhappy about unicode DBusExceptions()
<mvo> barry: this seems to be the root behind bug #846044
<ubottu> Launchpad bug 846044 in aptdaemon (Ubuntu Quantal) "software-center crashed with UnicodeEncodeError in get_dbus_message(): 'ascii' codec can't encode character u'\xfc' in position 65: ordinal not in range(128)" [Critical,Fix released] https://launchpad.net/bugs/846044
<barry> mvo: dang.  i cannot wait until we can kill py2 once and for all.  let me know if you want some input or help with that problem.
<mvo> barry: I'm knocking up a patch right now (I hope)
<barry> ;)
<pitti> mvo: btw, you know that "to knock up" == "make pregnant" in US English, right? :-)
<mvo> pitti: I had no idea!
<pitti> mvo: better get a room, you and your patch!
 * mvo will refrain from using that phrase again in the future
<mvo> pitti: ;)
<pitti> mvo: no worries, I fell into that trap as well
<pitti> mvo: but after I learned about it I finally understood the title of that Futurama episode
<mvo> pitti: not a happy story right now anyway me and my patch not sure that there is going to be a long term future
<pitti> ("Kyf gets knocked up a notch")
<mvo> pitti: haha
<pitti> lol
<ScottK> You could say "Knock together a patch" with no unfortunate connotations.
<Laney> or "whip up"
<ScottK> Whip up is good.
<micahg> doko: I was tempted to file a removal request for kompozer, upstream is dead
<cjwatson> OMG this package has per-function changelogs
<cjwatson> verbose much
<ScottK> micahg: Please do.
<micahg> ScottK: Bug #1065547 , have fun :)
<ubottu> Launchpad bug 1065547 in kompozer (Ubuntu) "Please remove kompozer from quantal and blacklist" [Wishlist,Confirmed] https://launchpad.net/bugs/1065547
<ScottK> thanks.
<micahg> FWIW, the Debian maintainer is subscribed to the bugs, so maybe he'll fix it now :)
<ScottK> I was thinking about not blacklisting since if it comes back, it'll surely be fixed ~somewhat.
<micahg> RC bug filed 18 months ago with no NMU...doubtful
<ScottK> OK.
<Laney> still, doesn't seem a particular need to blacklist
<micahg> ok, fine, skip the blacklist
<cjwatson> Yeah, nowadays blacklisting is for "never in Ubuntu again, no really".
<cjwatson> e.g. for kfreebsd-* it's quite reasonable
<cjwatson> But because we used to have to use the blacklist much more, people are in the habit of massively overusing the blacklist and it creates a maintenance problem for the future.
<hallyn> stgraber: will it matter for us at all if we take Dwight's patch to switch 0.8.0-rcX with 0.8.0.rcX ?
<ScottK> micahg: Done.  Please fix the recommends in ezgo-network.
<micahg> ScottK: is a missing recommends a problem? we have no diff ATM
<bdmurray> pitti: thanks I commented on the bug too
<cjwatson> hdf-eos5 is officially awful
<cjwatson> Insanely repetitive code, and it seems to use memmove if and only if it doesn't need to
<smoser> cjwatson, can you confirm that i should not need to specify anything special to have dpkg unsafe-io used during installs
<cjwatson> smoser: confirmed
<smoser> why does installaiton take so long.
<smoser> i know, it is completely not helpful an di have no data. but it justseems like install takes longer than it should.
<Daviey> cjwatson: In the last hour, i've just had two netinstalls fail to boot.  Do you think it is SB related?
<Daviey> seemingly stuck at bios
<cjwatson> It seems unlikely but I suppose I cannot rule it out
<cjwatson> smoser: Why doesn't the server team profile it then
<Daviey> It's two differ net
<cjwatson> I can't do everything for you!
<Daviey> It's two different machines, which were reliably working earlier today.. has anything changed
<smoser> cjwatson, i cant be expected to give actual data!
<smoser> i want to make arbitrary unsubstantiated claims!
<cjwatson> Daviey: SB is the obvious thing, I suppose; they might object to the extra certificate data at the end of the kernel
<Daviey> Oh
<cjwatson> I did test in BIOS kvm but who knows
<cjwatson> Daviey: We keep multiple versions of d-i images for this kind of reason
<cjwatson> Daviey: Compare old and new kernels to see if that's all it is
<Daviey> smoser: Do you want to try stripping some noise from the kernel command line?
<smoser> noise?
<Daviey> or that..
<Daviey> smoser: Don't we have some essential things that can be removed
 * Daviey needs to dash for 20-30 mins
<cjwatson> The kernel command line hasn't changed recently
<Daviey> cjwatson: Sorry, this is a MAAS based install. :)
<cjwatson> Sorry, not my fault that you can't get your overly complex infrastructure to do a simple test
<highvoltage> hie hie
<cjwatson> Surely it can manage a different installer version
<smoser> surely it cannot.
<smoser> cjwatson, where would i get an older installer to start poking
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/
<cjwatson> 181 is unsigned kernel, 183 is signed kernel
<cjwatson> I assume you know which bits under that you're using
<cjwatson> probably something under images/netboot/
<smoser> cjwatson, thanks. i can figure that out.
<cjwatson> ok.  if that turns out to be it then I can either do a straight revert or else (preferably if I have the time) come up with something to ship unsigned for BIOS and signed for UEFI
<cjwatson> smoser: fwiw if we didn't have to support minimalvm then the base squashfs could be much more extensive and I expect it would be rather quicker as a result.
<cjwatson> it was that way during quantal for a while until we realised that it broke minimalvm.
<cjwatson> (alternatively some kind of multi-squashfs scheme, but that's not been a road down which very much success has ever lain ...)
<smoser> oh shoot.
<smoser> ugh
<cjwatson> hmm
<cjwatson> (never mind, misread)
<smoser> we *should* hvae been installing precise
<cjwatson> in relation to slowness, or to boot failures?
<smoser> actually both.
<smoser> jus ignore me for the moment.
<smoser> cjwatson, but for slowness, precise should still have unsafe-io, right?
<cjwatson> smoser: Yeah
<cjwatson> debootstrap rather than squashfs-base, though, which makes some difference
<smoser> some.
<smoser> but just watching syslog messages of install
<smoser> just seems slower
<micahg> cjwatson: is a missing recommends for kompozer a problem (it shows up on the NBS list), we're in sync on the package now (ezgo)
<ScottK> micahg: Technically, yes, but if there's no diff, meh.
<cjwatson> We can break missing Recommends if we need to
<cjwatson> Better not to if possible, but yeah, what ScottK said
<micahg> right
<cjwatson> I'll NBS that now
<micahg> thanks
<tkamppeter> slangasek, hi
<johanbr> Hi. What's the preferred method for submitting a bug if apport hangs while collecting the information? Just submit the bug manually?
<slangasek> tkamppeter: hi there
<tkamppeter> slangasek, does cups crash often for you? In which situation?
<doko> Laney, https://launchpadlibrarian.net/119497991/buildlog_ubuntu-quantal-armhf.cabal-debian_1.25-1_FAILEDTOBUILD.txt.gz
<slangasek> tkamppeter: it crashes once a day for me
<doko> runhaskell not available on arm?
<Laney> doko: indeed
<doko> ok, thanks
<Laney> you can use ghc manually
<slangasek> tkamppeter: I had speculated that it might have been related to cron.daily and logrotate-based force-reload, but that doesn't seem to happen at the right time of the morning
<tkamppeter> slangasek, does it happen once a day? At random time points? Always the same time?
<slangasek> tkamppeter: I always get the crash notice in the morning; I don't know if it's always at exactly the same time; today's crash file has a timestamp of 8:04, the main cups process started running at 07:53; the access log appears to have been rotated at 07:48
<slangasek> tkamppeter: testing to see if I can reproduce the crash by running invoke-rc.d force-reload
<tkamppeter> slangasek, you can find the exact time point of the crash by the segfault message in /var/log/syslog.
<tkamppeter> slangasek, if I run "sudo invoke-rc.d cups force-reload" I do not get a crash, but I also do not have a crash report every morning.
<slangasek> tkamppeter: I haven't gotten a crash /yet/ after doing a force-reload; but that does not seem surprising, given the gap in time between the process starting and the crash file written
<slangasek> tkamppeter: I don't have any mention of this crash in syslog (though, I'm not using the stock syslog config)
<slangasek> tkamppeter: ok, I found it in /var/log/apport.log, apport was invoked at 7:53
<slangasek> so something changed the timestamp on the crash file afterwards
<slangasek> (I blame whoopsie)
<slangasek> tkamppeter: so that corresponds to the time when the current cups process started; but there's still a gap of 5 minutes between when the log file was rotated and the crash happened, which doesn't make much sense
<sarnold> slangasek: could you fiddle with the ulimits in the cups startup to let it dump core, so you could at least get a stack  trace out of it?
<sarnold> (that might be tomorrow, of course, but a core in the morning is a good way to start the day...)
<tkamppeter> slangasek, perhaps crash notices emitted by the kernel can also appear in kernel.log, dmesg, ... would be an alternative place for uses who suppress these messages in syslog.
<slangasek> tkamppeter: also, the apport log shows that it did crash again in response to my most recent reload - apport just didn't re-report it
<slangasek> sarnold: it *is* dumping core, to apport
<sarnold> slangasek: ah, good :)
<tkamppeter> slangasek, I have 3 bug reports now with similar stacktraces: bug 1034045, bug 1061457, and bug 1051799. Probably therefore Launchpad does not take more of these.
<ubottu> Launchpad bug 1034045 in cups (Ubuntu) "cupsd assert failure: *** glibc detected *** /usr/sbin/cupsd: free(): corrupted unsorted chunks: 0x00007f3dc478c0f0 ***" [High,Triaged] https://launchpad.net/bugs/1034045
<ubottu> Launchpad bug 1061457 in cups (Ubuntu) "cupsd crashed with SIGSEGV in find_subtree_recurse()" [Medium,Incomplete] https://launchpad.net/bugs/1061457
<ubottu> Launchpad bug 1051799 in cups (Ubuntu) "cupsd crashed with SIGSEGV in dbus_connection_dispatch()" [Undecided,Incomplete] https://launchpad.net/bugs/1051799
<tkamppeter> slangasek, sarnold, the crash happens in D-Bus code called by Avahi code called by CUPS code. Within the D-Bus code the crash happens on different places but the path in the Avahi and CUPS code seems to always be the same.
<tkamppeter> slangasek, sarnold, all other known CUPS crashes seem to be fixed with only this one remaining.
<tkamppeter> slangasek, it seems probable that the problem is somewhere in Avahi or D-Bus.
<tkamppeter> slangasek, sarnold, according to the stacktraces the problem happens for sure on the shutdown of CUPS (can also be the shutdown part of a reload).
 * slangasek nods
<smoser> anyone know what would be adding a foreign arch for me?
<doko> unit222.pas(30067,17) Fatal: Procedure too complex, it requires too many registers
<doko> nice compiler ...
<slangasek> smoser: is the foreign arch i386?
<smoser> yes
<smoser> i take a cloud imge, which seems not to have it enabled, do some stuff (not including 'dpkg --add-architecture') and seems like now i have it.
<smoser> yes. i know. i'm being very vague today.
<slangasek> smoser: well, I would expect it to be enabled by default even on the cloud image
<smoser> how does it get enabled?
<smoser> it seems not enabled in our quantal images
<smoser> but on precise it is
<slangasek> hmm
<slangasek> good question, I don't remember offhand
<cjwatson> smoser,Daviey: any news / more detail on this netinstall failure?
<smoser> well, it wasn't precise.
<smoser> err... it wasn't quantal
<Daviey> It was precise..
<Daviey> So it clearly couldn't have been related. :/
<cjwatson> That's a relief of sorts
<cjwatson> Yeah, I'm pretty sure I didn't do anything that could have accidentally added SB to precise :)
<cjwatson> (although come 12.04.2 ...)
<smoser> well thats good.
<slangasek> smoser: dpkg itself enables it on new installs
<smoser> weird.
<smoser> then i wonder why i dont get it.
<smoser> it is something i'd *like* disabled.
<smoser> :)
<smoser> so i'm happy with that in the cloud images for now.
<smoser> but i didn't understand it
<smoser> in precise dpkg lays down the file in /etc/dpkg.d/multiarch
<smoser> err.. /etc/dpkg/dpkg.cfg.d/multiarch
<tkamppeter> slangasek, as I cannot reproduce the cups bug, I need as much info about your printing environment as possible. Which printers do you have which servers, which OSes, which connection types?
<slangasek> tkamppeter: do you just want printers.conf attached to the bug?
<tkamppeter> slangasek, yes, this would be a first step, but also tell which IP is your Quantal box, which IPs, OSes are the remote print servers and which printers are on which server.
<slangasek> tkamppeter: doesn't printers.conf tell you which printers are on which server?
<tkamppeter> slangasek, at least if all queues are defined there and not implicit queues appearing by CUPS Broadcasting/Browsing.
<slangasek> tkamppeter: hmm; I assumed they all were, but it turns out all of them are there *except* for the default one (which is the only one that's live)
<slangasek> tkamppeter: oh, no, that one's there too
<slangasek> I missed <DefaultPrinter vs <Printer
<tkamppeter> slangasek, so please attach your printers.conf.
<slangasek> tkamppeter: done
<tkamppeter> slangasek, you have two PSC-750 at home?
<slangasek> tkamppeter: no, I have one printer with multiple queues
<slangasek> only one of which is actually in use
<tkamppeter> slangasek, Can you stop CUPS, move /etc/cups/printers.conf to another directory, do "sudo rm /var/cache/cups/*", and start CUPS again?
<tkamppeter> After that clean out any traces from CUPS crashes (the stopping of CUPS could have caused one) and then force-reload CUPS. Does it crash now?
<slangasek> tkamppeter: yes, still crashes
<tkamppeter> slangasek, this means that the presence or absense of your print queues does not make any difference. Stop your CUPS daemoon again, move back your printers.conf and, clear the cache again and start CUPS again.
<tkamppeter> slangasek, are you also sure that your observed crash is a fresh one and not a crash from before moving away printers.conf?
<slangasek> tkamppeter: yes, absolutely certain; I'm tracking /var/log/apport.log
<slangasek> tkamppeter: I'm afraid I don't have time to debug this further right now, though; if you have other things for me to try, can you send them to the bug and I'll pick it up later?
<tkamppeter> slangasek, it is perhaps easier to identify crashes when starting the CUPS daemon manually, running "sudo stop cups" at first and then starting "/usr/sbin/cupsd -f".
<tkamppeter> slangasek, OK.
<jtaylor> are people aware of the grub not finding windows? there is someone reporting every other day in +1
<jtaylor> not that we get another 10.10 situation
<xnox> jtaylor: incorrect efi chainload?
<jtaylor> no idea, fix seems to be to unmount windows before running update-grub
<xnox> jtaylor: no idea. What was the 10.10 situation?
<jtaylor> a similar issue was found a few days before release
<jtaylor> and iso recreation takes ages
<jtaylor> and it was the 10.10.2010 release so no delay possible :)
<xnox> it surely was 9 or 11 somewhere anyway.
<jtaylor> if I recall correctly iso respin took a couple days
<slangasek> jtaylor: has anyone filed a bug report about this yet?
<jtaylor> slangasek: bug 1051306 probably
<ubottu> Launchpad bug 1051306 in os-prober (Ubuntu) "windows not found unless partion is mounted" [Undecided,Confirmed] https://launchpad.net/bugs/1051306
<slangasek> (+1 is not how to report bugs if you want the developers to know about them...)
<slangasek> jtaylor: isn't that bug description the opposite of what you said above?
<jtaylor> yes confused me too
<jtaylor> there seem to be two issues
<jtaylor> and I can't reproduce any of them
<slangasek> hmm
<slangasek> xnox: how's your os-prober-fu?
<xnox> slangasek: well... i was poking it recently to fix reuse/reinstall options in quantal.
 * slangasek nods
<slangasek> xnox: can I assign this to you for investigation?
<xnox> slangasek: why?
<slangasek> bug #1051306
<ubottu> Launchpad bug 1051306 in os-prober (Ubuntu Quantal) "windows not found unless partion is mounted" [Critical,Confirmed] https://launchpad.net/bugs/1051306
<xnox> slangasek: I wonder if this is the same as windows is hybernated and everything is giving a fizzy fit mounting it under linux. Although we only want very read-only mode...
<slangasek> xnox: wouldn't the 'mount -t auto' fail too in that case?
<hallyn> SpamapS: upstart question.  What is supposed to stop a network-interface-security job for a particular interface?
<hallyn> jdstrand: ^ you might also know
<xnox> slangasek: yeah, it would have. Something odd is going on.
<slangasek> hallyn: nothing, as written; why do you need it stopped?
<SpamapS> Hm
<hallyn> slangasek: because if you start and stop containers repeatedly, they become a nuisance?
<hallyn> see bug 1065589
<ubottu> Launchpad bug 1065589 in lxc (Ubuntu) ""initctl list" shows 11974 instances of network-interface-security after two days of uptime" [Medium,Triaged] https://launchpad.net/bugs/1065589
<SpamapS> I could see a desire to run those steps again if the interface is brought down/up 
<slangasek> hallyn: ah, heh
<SpamapS> LOL
<SpamapS> sorry
<SpamapS> lol
<SpamapS> given that the pre-start *also* has a guard in the first line..
<slangasek> the guard is there to ensure that these tasks are run once before any network interface is brought up
<slangasek> the whole purpose of the job is "apply apparmor policy before letting the network in"
<SpamapS> seems logical that we would stop it on stopping network-interface INTERFACE=$INTERFACE
<hallyn> shoudl it just be a task?
<slangasek> so it's fine to stop it again on, say, 'stopped network-interface $INTERFACE'
<SpamapS> actually yeah, why not a task if the guard is there?
<slangasek> a task might work
<SpamapS> it wouldn't change the semantics of anything depending on its started event, because it has no main process
<SpamapS> in fact, one might wonder why its not a task and why it doesn't do its job in the main process
<hallyn> slangasek: that would take care of 1/3 of the problem (per capita in terms of # left-over jobs :)
<hallyn> uh, 2/3
<slangasek> SpamapS: because nobody suggested that before now? :)
<hallyn> there is still the problem that there is no net-device-down event for the veths that are passed into the container.
<hallyn> but that's for either the kernel or lxc to tkae care of
 * slangasek nods
<hallyn> i'll go hang out in ubuntu-kernel tod iscuss that one :)
<hallyn> slangasek: should i open a bug against upstart for that you think?
<hallyn> the -security one
<slangasek> hallyn: no, the job belongs to ifupdown
<slangasek> :)
<stgraber> hallyn: assign it to me, though I doubt that'll be fixed for 12.10 release, best I can do is zero-day SRU I guess (not that it's really that urgent, we've had that problem forever and only noticed it now)
<hallyn> stgraber: right, and it can be worked around from userspace with a slow daemon :)
<hallyn> thanks guys
<stgraber> hallyn: right, we can easily write something looking at /sys/class/net and stopping the job for any interface that doesn't exist
<hallyn> and (for the other 1/3) sending net-device-down signal
<hallyn> bug 1065684
<ubottu> Launchpad bug 1065684 in ifupdown (Ubuntu) "network-interface-security.conf should be a task" [Medium,Confirmed] https://launchpad.net/bugs/1065684
<jibel> SpamapS, fyi, following yesterdays chat, I filed bug 1065434 . I haven't tried 3.6 yet
<ubottu> Launchpad bug 1065434 in linux (Ubuntu) ""unregister_netdevice: waiting for lo to become free. Usage count = 1" after LXC container shutdown" [Medium,Confirmed] https://launchpad.net/bugs/1065434
<stgraber> doko: aren't our armel chroots/builders supposed to be armv5?
<stgraber> doko: I'm trying to figure out what's going on with liburcu/ust. ust is trying to build with "dmb" and fails as it's not around on armv5 but looking at the configure, it thinks it's building on armv7
<stgraber> doko: https://launchpadlibrarian.net/119499520/buildlog_ubuntu-quantal-armel.ust_2.0.4-1ubuntu1_FAILEDTOBUILD.txt.gz is the relevant build log
<hallyn> stgraber: (and slangasek) well sadly just turning network-interface-security into a task doesn't work.  netdev doesn't come up on reboot when i do that.
<slangasek> netdev?
<hallyn> the network devices don't come up
<slangasek> hallyn: did you also move it from 'pre-start script' to 'script', which IIRC was part of SpamapS' suggestion?
<hallyn> nope
<hallyn> didn't recall him saying that, but yes my guess was that pres-tart doesn't happen for task...
<slangasek> that might help
<hallyn> yeah
<hallyn> will try.  (waiting for new instnace to spin up :)
<hallyn> yeah that seems better  :)  thanks
<doko> stgraber, enoclue. I love verbose build logs \o/
<doko> stgraber:
<doko> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
<doko> #ifndef __ARM_ARCH_5TEJ__
<doko> #error "no arm5 here"
<doko> #endif
<doko> $ gcc -E -dM - < /dev/null | grep ARM_ARCH
<doko> #define __ARM_ARCH_5T__ 1
<mlankhorst> fail \o/
<doko> stgraber, and there is another bogus test above
<infinity> doko: That's awesome.  I can only assume that whoever wrote it didn't know what any of the letters meant.
<infinity> doko: Cause, while I can see value in testing for 5TE (and, indeed, many people write for and require some insns that only E brings), does *anyone* wrote for Jazelle?
<infinity> s/wrote/write/
<YokoZar> stokachu: I just added about 97 "me too's" to https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 for you ;)
<ubottu> Launchpad bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress]
<YokoZar> stokachu: I'm wondering if I could get a status update, as I was considering starting work on it myself
#ubuntu-devel 2012-10-12
<pitti> Good morning
<ScottK> Good morning.
<dupondje> xnox: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422
<ubottu> Launchpad bug 903422 in gvfs "Ubuntu does not work with Samsung Galaxy phones (needs update to libmtp)" [Wishlist,In progress]
<dupondje> ubuntu does not use libmtp, but gphoto2 to access the devices via gvfs
<ScottK> pitti: I would appreciate it if you could have a look at Bug #1065827 and let me know if we're missing something from our seeds or if it's an actual jockey problem.
<ubottu> Launchpad bug 1065827 in jockey (Ubuntu) "Kubuntu 12.10 bcmwl install failure" [High,New] https://launchpad.net/bugs/1065827
<pitti> ScottK: so detection and attempt to install seemed to work alright; let me look at your desktop image's pool
<pitti> ScottK: hm, all seems to be there; if you try "sudo apt-get install bcmwl-kernel-source" on the live system, does apt also try to download it from the network?
<pitti> ScottK: do you see the CD source in /etc/apt/sources.list?
<ScottK> Looking
<ScottK> It's not in the sources.list.
<ScottK> Which would explain it.
<ScottK> So which package owns that problem?
<ScottK> (and the apt-get install obviously doesn't work)
<pitti> ScottK: is that in the live system or installed system?
<ScottK> pitti: Live
<pitti> ScottK: yesterday we had the topic for the installed system, where it's not entirely clear whether or not it should be there
<pitti> ScottK: hm, somewhere in our live-build configuration then
<ScottK> I have an install in progress on the system right now.
<ScottK> I asked for non-free stuff to be installed during the install, so I'll know shortly if that works or not too.
<ScottK> Then I'm going to have to crash because it's almost 2AM here.
<ScottK> pitti: Thanks for helping out.
<ScottK> It didn't install there either.
<wzssyqa> I generate an iso with simple-cdd, while installing, it always ask me to insert a CD when the installation is nearly finished
<dholbach> good morning
<shuerhaaken> Hello. Anybody has this issue on quantal where some elements like some GtkLabels or GtkDrawingareas or the background of tabs are painted black with adwaita? See here: http://imgur.com/l8q0N
<xnox> dupondje: ok, then add appropriate gphoto2 task as well. sorry about that. That bug is a mess ;)
<dupondje> xnox: gphoto2 claims to support the Samsungs
<dupondje> it actually works (partly) when using gphoto2 commandline
<dupondje> xnox: but it seems the MTP on the device needs calls within a few seconds after connecting
<dupondje> else it goes into /ignore mode :p
<xnox> dupondje: I don't have a device to test, it's just that cz<tab> was complaining that it doesn't work.
<dupondje> its not working no (with gvfs/nautilus) indeed
<dupondje> which is quite annoying
<dupondje> surely because ALOT of people have a Samsung Android
<xnox> dupondje: i think laura wanted mtp more to sync music and stuff.
<xnox> dupondje: well i didn't migrate to android phones yet. and i gathered it was about samsung galaxy nexus
<dupondje> nope
<xnox> all?
<dupondje> Samsung devices with Android 4.x
<dupondje> so alot
<dupondje> prolly 3.x also, but nobody uses MTP on those (as it has Mass Media option)
<xnox> what changed?
<dupondje> where Android 4.x only has MTP/PTP
<xnox> well in the udev rules by libmtp I can clearly see galasy S and nexus 4.0 updates
<xnox> dupondje: i'll look into mtp output from laura and check what's wrong later.
<dupondje> xnox: btw, it 'worked' on precise
<dupondje> was able to open my device in Nautilus
<dupondje> but everything was empty :p
<xnox> dupondje: for some value of 'worked'... I'd call that 'crashed with less flames'
<dupondje> :)
<dupondje> its quite annoying an device that is used so much is broken on Ubuntu
<seb128> patches are welcome ;-)
<seb128> or you can offer me a device and I will look at the bug :p
 * seb128 only has a dumb bada old phone
<dupondje> heh seb128  :)
<dupondje> seb128: alot of things have been fixed in new gphoto2 version
<dupondje> upstream requested to test that first, but its quite some work (new api)
<dupondje> so gphoto2 / libgphoto2 needs to be recompiled
<seb128> yeah, that's not going to happen for quantal
<dupondje> and also gvfs should be adjusted/recompiled
<dupondje> if we know the new version is ok, then we can check to maby cherry pick a patch
<dupondje> but first should need to test the newest version
<seb128> yeah...
<seb128> dupondje, do you know if fedora uses the new version?
<seb128> it might be easier to boot a live image from f18 to test
<seb128> tseliot, hey, how are you?
<seb128> tseliot, could you look at bug #1061659?
<ubottu> Launchpad bug 1061659 in nvidia-settings-updates (Ubuntu Quantal) "package nvidia-settings-updates 304.43-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/nvidia-settings.1.gz', which is also in package nvidia-settings 304.51-0ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1061659
<dupondje> LATEST BUILD
<dupondje> 2.5.0-3.fc18
<dupondje> newest version :)
<dupondje> i'll try it this evening :)
<tseliot> seb128: hi, yes, it's on my todo list. I'll fix it soon
<seb128> tseliot, thanks, I assigned the bug to you, I hope it's ok
<seb128> dupondje, thanks, let me know how it goes
<tseliot> seb128: sure, thanks
<dupondje> hmz, any idea why in usb-creator-gtk, the 'Write image' button is grayed out
<xnox> dupondje: not enough space on the target?
<xnox> dupondje: no source/target selected?
<dupondje> xnox: .iso is 700MB
<dupondje> usb stick is 3,8GB
<dupondje> and I can only select the source from commandline :s
<xnox> dupondje: I have no idea =) use dd or file a bug.
<dupondje> lol
<dupondje> xnox: without chaning anything, I started it again now, and it works
<dupondje> wt... :p
<dupondje> ahhh, it only works for Ubuntu images it seems :(
<jibel> jodh, I added a detailed test case to https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1060249/+text to reproduce from Precise without a full upgrade.
<ubottu> Launchpad bug 1060249 in debconf (Ubuntu Quantal) "frontend crashed with signal 5 in free_pending_nulls()" [High,Confirmed]
<jodh> jibel: thanks very much!
<om26er> cjwatson, Hey! you will be patch pilot today ?
<cjwatson> Oh, I suppose I ought to be
<cjwatson> Not clear how much I can get done given that we're hard-frozen for release
<cjwatson> But maybe some SRU processing or something
<cjwatson> What's up?
<om26er> cjohnston, i have a SRU for bamf https://code.launchpad.net/~om26er/ubuntu/precise/bamf/SRU_for_lp_1026426/+merge/129405
<om26er> fixes 1026426 a critical one
<om26er> bug 1026426
<ubottu> Launchpad bug 1026426 in bamf (Ubuntu Precise) "LibreOffice Unity integration (launcher and switcher) is broken" [Critical,Triaged] https://launchpad.net/bugs/1026426
<om26er> oops
<cjwatson> OK, I'll finish up what I'm currently working on and then start piloting
<om26er> cool
<diwic> I'd like bug 973014 to be SRUed as well
<ubottu> Launchpad bug 973014 in gst-plugins-bad0.10 (Ubuntu Quantal) "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [Undecided,Confirmed] https://launchpad.net/bugs/973014
<dupondje> seb128: its broken in FC18 also :(
<seb128> dupondje, ok, so not likely fixed by the new stack...
<seb128> dupondje, thanks for testing
<dupondje> indeed, but I don't know if the bug is really in gphoto2
<dupondje> guess it gvfs <-> libgphoto2 interaction that is bit broken
<seb128> dupondje, I guess the real fix is for gvfs to get a mpt backend (seems to be worked upstream by some contributor)
<dupondje> yep I saw that :)
<cjwatson> jamespage: I don't suppose the eigenbase-resgen build failure means anything to you?
<jamespage> cjwatson, funny you should say that - I was just looking
<jamespage> I can't reproduce it
<cjwatson> Reproduces exactly for me in sbuild
<jamespage> cjwatson, hmm
<jamespage> cjwatson, i386 or amd64?
<cjwatson> jamespage: i386
<cjwatson> it's an arch-all build, so that's what you want
<jamespage> cjwatson, I don't disagree but I can only fit so many schroots in my tiny SSD
<jamespage> fortunately I have one of those
 * jamespage tries again
<cjwatson> That's what I have a big external disk for
<jamespage> cjwatson, well at least I can repo now
<cjwatson> jamespage: cool
<jamespage> cjwatson, that is a puzzler
<mpt> Keep gvfs away from my backend, thanks very much
<xnox> mpt: =))))))))
<xnox> slangasek: cjwatson: do you remember a bug or something about ubiquity unmounting /target not in a clean way resulting in journal replay on first boot/mount ?
<cjwatson> xnox: I don't think so, although I can imagine that as a side-effect of all sorts of other things
<xnox> cjwatson: ok. that seems to be that bug 1065034 is kind of a result of unclean fs (install, do not boot, try to reinstall). if the fs is actually clean, we proceed fine.
<ubottu> Launchpad bug 1065034 in ubiquity (Ubuntu) "'ubuntu ubiquity: umount: /tmp/tmp.h3NCLhoxSh: not mounted' during a Reinstall attempt on a previously manually partioned vm installation" [High,Confirmed] https://launchpad.net/bugs/1065034
<cjwatson> Could all be a side-effect of this GRUB bug, several layers down the line ...
<xnox> cjwatson: so the bug is not nearly as bad.
<cjwatson> I think you need a good deal more analysis, at any rate
<cjwatson> e.g. shell tracing of where that's happening
<xnox> yeah. that's what I am doing now.
 * xnox well as well as ubiquity tracing as it does call out to os-prober by itself.....
<xnox> ok.
<slangasek> cjwatson: which grub bug is "this" grub bug?
<cjwatson> Sorry
<cjwatson> slangasek: bug 1051306 - Windows detection (or indeed grub-mount handling of anything) fails in the presence of a symlink to a directory
<ubottu> Launchpad bug 1051306 in grub2 (Ubuntu Quantal) "Windows not found unless partition is mounted" [Critical,Triaged] https://launchpad.net/bugs/1051306
<cjwatson> *just* tracked it down that far
<cjwatson> As it happens I have a /cdrom symlink in my / which triggers this - it's at least somewhat filesystem-independent
<cjwatson> (Though obviously it has to support symlinks at all)
<cjwatson> Given that grub-mount is used by ubiquity and os-prober in various places, I can easily imagine this causing confusion about what's mounted
<cjwatson> Particularly in the presence of mounts on subdirectories
<cjwatson> I may be wrong, it's just a theory at this point
<slangasek> cjwatson: aha, ok
<cjwatson> slangasek: Do you agree with my continued assessment that this is RC?
<slangasek> cjwatson: yes
<cjwatson> It doesn't affect all cases of detecting Windows, but I strongly suspect quite a few, and is likely to have all kinds of weird side-effects
<cjwatson> om26er: ... sorry, I'm going to have to postpone my piloting shift
<cjwatson> Not that I was on time anyway
<om26er> cjwatson, no problem, i'll catch Clint ;-)
<seb128> om26er, you should start by subscribing ubuntu-sponsors so it shows up on http://reports.qa.ubuntu.com/reports/sponsoring/
<om26er> seb128, now subscribed ubuntu-sponsors to both bugs
<stokachu> slangasek: hey im getting a lot of pressure for having bug 1013211 and bug 1036834 uploaded and pushed into precise, is there anything we can do to get this going?
<ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu Precise) "[FFe] Please transition libgnomecanvas to multi-arch" [High,In progress] https://launchpad.net/bugs/1013211
<ubottu> Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] https://launchpad.net/bugs/1036834
<stokachu> both are in quantal but theres been no movement on precise
<slangasek> doko: ^^ were you looking at sponsoring 1013211?
<ScottK> IIRC there was some push back on gdb.
<stokachu> the gdb one has conflicting comments
<doko> slangasek, is this for q? I'm not sru release. I think I did upload it
<slangasek> stokachu: the gdb one is probably all me, though; I'm unlikely to get a chance to look at it before release
<doko> gdb was rejected by bad pitti
<stokachu> slangasek: ok, libgnomecanvas is the high prio one atm anyway
<slangasek> stokachu: ah, oh
<slangasek> stokachu, doko: right, I see libgnomecanvas in the queue and today's my SRU day (once I'm through with 12.10-related fires), so I'll get that moving
<doko> stokachu, libgnome for p is alreay done?
<stokachu> doko: libgnome is done libgnomecanvas is not though
<doko> infinity, slangasek: sbsigntool promoted to main. Please fix the i386 configury properly, using the $host macros, not fiddling around with uname and then fixing it ...
<doko> slangasek, where should sbsigntool be seeded?
<slangasek> doko: i386 configury> bah, hadn't noticed that; could you please file a bug on the package to track it? I'm not likely to get to this before release
<slangasek> doko: also, would you please stop promoting packages before they're seeded ;)
<stokachu> doko: if possible could we get bug 1013211 pushed into precise-proposed today?
<ubottu> Launchpad bug 1013211 in libgnomecanvas (Ubuntu Precise) "[FFe] Please transition libgnomecanvas to multi-arch" [High,In progress] https://launchpad.net/bugs/1013211
<infinity> doko: Sorry, the i386 thing was just a hack to fix jk's worse hack, I meant to bring it up with him using a ruler.
<stokachu> ive got clients ready to test and verify
<doko> slangasek, why? as long as pitti has left, they're not demoted again ;p
<slangasek> doko: they generate email spam to me!
<slangasek> doko: and sometimes yes, I do demote things I see there
<stokachu> err sorry
<stokachu> missed that comment from slangasek
<stokachu> slangasek: thanks for taking a look at that
<slangasek> doko, cjwatson: how about supported-installer-common for sbsigntool seeding (for the time being)?
<infinity> Seems as good as any.
<infinity> Or supported-hardware-common
<slangasek> doko, infinity: seeded, thanks
<doko> hmm, the uefi packages are already in supported-installer-common
<slangasek> yep
<slangasek> not sure why arm bootloaders are in hardware, but x86 bootloaders are in installer. :-P
<infinity> Just cause.
<cjwatson> slangasek: Yep
<infinity> Maybe someone was making the distinction between ARM bootloaders being, essentially, the BIOS (so, "hardwareish")?  I dunno.
<infinity> Should I be suspicious that the one arch where remctl is FTBFS in Ubuntu happens to be the one arch that was hand-built and uploaded by the maintainer in Debian?
<xnox> infinity: you can copy-package from debian archive into ubuntu archive using lp api right?! =)
 * xnox hides
<cjwatson> No, because LP doesn't import the binaries :-P
<cjwatson> Just as well.
<xnox> cjwatson: good! =)
<doko> infinity, builds fine on i386 in wheezy
<cjwatson> infinity: Can you make anything out of the rakudo build failure?  It keeps failing in different places, from what I can tell, and it built fine on scheat.
<infinity> cjwatson: Means nothing to me, at a glance.  But if it's failing in different spots, obviously the solution is to give it back once an hour until release.
<infinity> cjwatson: Oh, and smb4k fixed and testbuilding here.
<infinity> (Well, potentially fixed, testbuil will tell me for sure)
<cjwatson> infinity: excellent, I have your blessing then ;-)
<cjwatson> smb4k> great.  We're getting close
<ev> mpt: the deployment is blocked on me sorting out setting the browser history when the user changes the table
<ev> right now it's getting stuck in a loop once you get back to the first query
<cjwatson> infinity: I've got an armel build failure trying to link to __aeabi_i2d; is that a "wrong floating-point mode" error?
<infinity> cjwatson: Missing -lgcc?
<cjwatson> Oh, hmm, this is trying to link with ld
<infinity> cjwatson: Except, that should be implicit on ARM, I thought...
<cjwatson> I wonder if it's safer to switch to gcc generically or to add -lgcc
<infinity> cjwatson: Oh, not so implicit if not linking with gcc.
<TheLordOfTime> what's the package that contains most of the dev tools for ubuntu, such as gcc compiler libraries and the likes?
<sarnold> TheLordOfTime: build-essential
<infinity> cjwatson: Adding -lgcc means arch-guarding it, or having an unnecessary dep on other arches.  Using gcc should just DTRT, unless it's a package that's doing something very clever for very good reasons.
<cjwatson> It's Java-related; it's more likely to be doing something stupid for bad reasons.
<infinity> Hah.
<cjwatson> (And actually this is a Debian-specific patch to boot.
<cjwatson> )
<cjwatson> doko: Does http://paste.ubuntu.com/1275250/ ring a bell, on armel?  That's java3d after I fixed it to link with gcc rather than ld.  I'm wondering if there's a java-config script it needs to be using or something ... full build log in my homedir on scheat
<infinity> cjwatson: Looks more like a link order as-needed issue.
<cjwatson> Possibly -ljvm before -ljawt I guess
<infinity> cjwatson: Well, and -o foo in the wrong part of the link line.
<cjwatson> Since when did the position of -o foo matter at all?
<cjwatson> Position of input objects, sure, but they're all at the start here.
<infinity> cjwatson: Oh, indeed.  I could also just be half asleep.
<ogra_> youre such a pessimist
<ogra_> could have said half awake :)
<cjwatson> Switching -ljvm and -ljawt makes no difference.
<cjwatson> And I doubt moving them any earlier would help.
<silverarrow> hi
<silverarrow> I am looking for more extensive info on how to troubleshoot audio driver issues
<silverarrow> there something with the new kernel and snd-aoa drivers for powerpc I cannot figure out
<silverarrow> they usual fixes described on FAQ  pages does not work
<infinity> cjwatson: Hrm, well, maybe there was a reason they were using ld raw...
<silverarrow> I don`t get any response on the forum either
<doko> cjwatson, will have a look tomorrow. afk
<slangasek> jamespage: hey, do I understand correctly that bug #1053770 is being addressed by changing the "minimum requirements" documentation rather than shrinking the install?
<ubottu> Launchpad bug 1053770 in ubuntu-docs (Ubuntu Quantal) "ubuntu-server install takes up too much space" [High,In progress] https://launchpad.net/bugs/1053770
<jamespage> slangasek, yes
<slangasek> jamespage: ok, cheers - should we mark it 'wontfix' for ubuntu-meta/
<jamespage> slangasek, done
<jdstrand> mdeslaur, jjohansen, sarnold: I was just looking at bug #1058356
<ubottu> Launchpad bug 1058356 in cups (Ubuntu) "fails to install when kernel does not provide block_suspend capability" [Undecided,Confirmed] https://launchpad.net/bugs/1058356
<jdstrand> so, as the summary says, precise kernels don't have block_suspend, but quantal does
<jdstrand> the quantal cups profile has a rule that uses block_suspend
<mdeslaur> we're trying to run quantal userspace on a precise kernel?
<jjohansen> oh fun
<jjohansen> mdeslaur: more like quantal policy
<mdeslaur> -ENOTSUPPORTED
<jdstrand> and while dh-apparmor is smart enough to use 'apparmor_parser ... | true', /lib/init/apparmor-profile-load does not use '|| true', so when people upgrade from precise to quantal, cups is restarted, but that fails, so the job fails, and then the bug bites
<mdeslaur> oh, hrm
<slangasek> at minimum, this would be an issue on upgrade
<slangasek> right
<jdstrand> so the 12th our fix is to add || true to /lib/init/apparmor-profile-load
<mdeslaur> jdstrand: I'm ok with that
<jdstrand> slangasek: these days, upstart will log the error output, correct?
<slangasek> jdstrand: stdout and stderr from any upstart job will by default wind up in /var/log/upstart, yes
<jdstrand> ok, then I think || true is ok myself
<jjohansen> jdstrand: well we should really fix it so that the parser can handle this
<jjohansen> not saying that || true isn't the solution for today
<jdstrand> yeah
<jdstrand> agreed on both counts
<sarnold> jjohansen: how does the parser/kernel interface report "unsupported capability"?
<jdstrand> ok, let me bring this up in #ubuntu-release. I'll probably open a new bug for apparmor_parser
<jjohansen> jdstrand: it is
<jjohansen> sarnold: when the parser is built it auto extracts the list of capabilities known from the includes, the apparmor kernel module exports the mask of capabilities it supports :/
<sarnold> jjohansen: by name or by number?
<sarnold> (the exports-the-mask...)
<jjohansen> sarnold: number, I had thought kees had made that a names list
<sarnold> one hopes they're one-and-the-same, but ...
<jjohansen> sarnold: well hrmm you would hope but I am not sure that is guaranteed for all architectures.  I know its not for rlimits
<sarnold> the downside is, even if it does printk()/audit() 'unsupported capability in profile', the profile itself may still deny e.g. cap_sys_admin, if that was the capability required on earlier systems.
<sarnold> jjohansen: oooh, ouch.
<jjohansen> sarnold: so ideally we would patch the kernel to have a names mask as well but can always fall back to the current numeric mask
<jjohansen> sarnold: I don't follow
<sarnold> jjohansen: is block_suspend a brand-new interface that didn't exist in older kernels? or was it split out of cap_sys_admin?
<jjohansen> sarnold: ah, got it. We need a mapping for things like that :/
<sarnold> jjohansen: that's almost related to cbolt'z profile versioning -- except kernel versioning.
<jjohansen> sarnold: yeah a similar but different problem
<slangasek> jdstrand, jjohansen: so I'm questioning the analysis on bug #1058356 now
<ubottu> Launchpad bug 1058356 in upstart (Ubuntu Quantal) "fails to install when kernel does not provide block_suspend capability" [High,Fix committed] https://launchpad.net/bugs/1058356
<slangasek> I don't think this is a precise->quantal upgrade issue at all
<slangasek> it's not reproducible at all in the Ubuntu QA jenkins runs
<jdstrand> slangasek: it was reported via a QA jenkins run
<slangasek> jdstrand: for indicator-session CI, *not* the daily upgrade testing runs that we do
<jdstrand> tedg_ reported it
<slangasek> tedg_ is not Ubuntu QA :)
<slangasek> the desktop upgrade tests do *not* show this failure
<jdstrand> sure, but I am testing it now regardless
<jdstrand> (ie, the test case for the sru)
<jdstrand> so give me a few minutes
<smoser> slangasek, are you planning on bringing 643286 back to precise?
<slangasek> smoser: ENOSUCHBUG?
<smoser> gar
<smoser> bug 643289
<ubottu> Launchpad bug 643289 in nfs-utils (Ubuntu Precise) "idmapd does not starts to work after system reboot" [High,Triaged] https://launchpad.net/bugs/643289
<smoser> better.
<slangasek> smoser: that's the idea, yes; but I was waiting for you to tell me if the latest mountall in quantal holds together :)
<smoser> well.
<smoser> $ df -h /
<smoser> Filesystem      Size  Used Avail Use% Mounted on
<smoser> /dev/vda1       9.9G  1.1G  8.5G  11% /
<smoser> which is nicer than '-'
<slangasek> smoser: well I know I fixed that particular bug... more looking for stress-test feedback
<slangasek> since you seem to exercise mountall in ways we have not previously conceived ;)
<claw_> hey guys i am missing pxechain.com in syslinux in 12.04 LTS
<smoser> well our quantal "ephemeral" images sem functional at the moment
<xnox> claw_: i saw your bug. but everyone is busy making quantal release right now. I have a mental note to look at it. but can't promise anything.
<smoser> and the only issue that i'd seen in 2.41 was the  mtab issue.
<slangasek> smoser: ok
<claw_> xnox, that would be great thank you very much
<slangasek> smoser: flagged in my brain to follow through on that SRU then, thanks
<jdstrand> slangasek: ok, I can confirm that the simple test case of copying the quantal cups profile into place on precise causes the restart to fail. now I will attempt a precise to quantal upgrade
<slangasek> jdstrand: ok, curious
<smoser> slangasek, thanks. the only real raeson i'm asking is tha tmy fix for bug 1031065 depends on that.
<ubottu> Launchpad bug 1031065 in cloud-init (Ubuntu Precise) "cloud-init-nonet runs 'start networking' explicitly" [Medium,Triaged] https://launchpad.net/bugs/1031065
<slangasek> smoser: yeah, I know
<claw_> xnox, but i did not open a bug request... it was an mail to the devs mailing list which was not accepted yet i guess
<cjwatson> the pxechain problem in 12.04 is Debian #663302
<ubottu> Debian bug 663302 in syslinux "include extra modules" [Normal,Fixed] http://bugs.debian.org/663302
<cjwatson> So that should be reasonably easy to SRU since it's fixed in quantal
<cjwatson> (not that I have time right now)
<xnox> claw_: hmm... maybe I saw the email. if there is no bug report. open one please. using `ubuntu-bug syslinux`
<xnox> claw_: otherwise it will be lost.
<xnox> claw_: sorry, ignore me. see cjwatson's comment.
<cjwatson> no, you were right the first time, it's a good idea to file a bug anyway
 * xnox will use improt-debian-bug ;-)
<cjwatson> in particular if you file it that means you'll be notified when there's a package in precise-proposed available for testing
<ScottK> So claw_ should still see cjwatson's comment.
<cjwatson> xnox: Better for somebody who cares directly to file it, and then they'll get told about testing
<xnox> claw_: after all the chit-chat, please file a bug referencing the debian bug linked above.
<xnox> =)
<kees> jjohansen: I thought it was a bitmask, but rlimit was a name list?
<kees> $ cat /sys/kernel/security/apparmor/features/capability
<kees> 0xffffff
<kees> $ cat /sys/kernel/security/apparmor/features/rlimit/mask
<kees> cpu fsize data stack core rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime
<jjohansen> kees: yep
<jjohansen> kees: for some reason I was thinking we did the name list with caps too
<jjohansen> kees: I will probably add a new file with the names
<kees> jjohansen: yeah, I thought I did too. There was some reason it wasn't that way, but it eludes me now.
<kees> cool
<claw_> the problem was fixed by debian on 8th May or earlier
<cjwatson> Right, which is why it's fixed in 12.10
<claw_> its a server system i want to have some LTS
<cjwatson> Certainly - please file a bug about it and we'll get it backported
<claw_> i will thanks
<xnox> Ooohhh we have SHA-3 the Keccak hash =)
 * xnox best name ever
<micahg> better than Pebcak hash :)
<jdstrand> slangasek: so, like I said, I can readily reproduce with the new apparmor profile and the old upstart. it is curious as a do-release-upgrade worked fine, so I am back to being confused as to how people are actually hitting this in the real world. that said, I think it is still worthy of an SRU since this is like the 3rd time I've seen this bug
<jdstrand> slangasek: but I have downgraded the priority
<jdstrand> it's a trivial SRU, we recognize the deficiency in apparmor_parser and this should help whatever corner cases that people are hitting
<slangasek> jdstrand: ack.  Strange for it to not reproduce in the upgrade
<jdstrand> yeah. it has been a head-scratcher since people say they see it on upgrade, but yet I don't see it
<jdstrand> I thought it might have something to do with the fact that the postinst has 'start cups'
<jdstrand> (as opposed to restart)
<jdstrand> and maybe upstart was being smat
<jdstrand> smart
<jdstrand> and if it was running, not running the apparmor bit
<slangasek> postinst has 'start cups' because prerm has 'stop cups'
<jdstrand> which would mean people would have to have cups stopped. but even then, the postinst as || true after start
<slangasek> so cups should never be running at that point
<jdstrand> ok, well, still. there is an || true
<jdstrand> so, yeah, I don't know what corner case this is, but we can recognize the class of bug due to apparmor_parser and avoid the problem going forward
<slangasek> right, as long as you're happy that the apparmor_parser change is per se correct
<slangasek> and not simply a workaround for a bug
<jdstrand> I believe it is correct for the current state of apparmor_parser
<slangasek> if it's a workaround with negative side effects, it might be worth figuring out exactly what bug it's really working around
<jdstrand> we would like to fix that, and when we do, we will remove this from upstart
<jdstrand> oh, I might add that cups does not go unconfined
<slangasek> right - the previous apparmor profile still applies, as expected?
<jdstrand> it isn't removed
 * slangasek nods
 * xnox hopefully now migrated to znc proxy.
#ubuntu-devel 2012-10-13
<cjwatson> infinity: Hah!  rakudo/armhf finally stuck to the wall
<cjwatson> On about the fourth or fifth try
<cjwatson> Not totally reassuring, but ...
<infinity> cjwatson: Haha.  Seriously?
<infinity> cjwatson: Good job clicking retry, I guess?
<slangasek> cyphermox: do you happen to know how to make dnsmasq answer bootp (not dhcp) requests?
<cyphermox> not by memory
<cyphermox> I suspect it's hidden somewhere in its monstrous manpage
<slangasek> cyphermox: is this configurable via dnsmasq.conf, or only by commandline?  (I find a -M option on the commandline)
<slangasek> heh
<cyphermox> both
<cyphermox> -M, --dhcp-boot=[tag:<label>,]<nom de fichier>,[<nom de serveur>[,<adresse de serveur>|<nom du serveur tftp>]]
<cyphermox> (sorry, in french)
<slangasek> ah, looks like my root problem may be not using --bootp-dynamic
<cyphermox> but basically you'd use the long option name with the seetings
<cyphermox> ah
<slangasek> I think
 * cyphermox is playing with quagga, doing a presentation on advanced networking config in Quebec city tomorrow
<slangasek> I'll trade you that for getting grub2 to pxe boot under efi ;)
<cyphermox> wooo
<slangasek> right, got an address from bootp now
<slangasek> that's progress
<cyphermox> can I help? my desktop is setup with efi already
<slangasek> cyphermox: sure; grab http://archive.ubuntu.com/ubuntu/dists/quantal/main/uefi/grub2-amd64/current/gcdx64.efi.signed, pxe boot it, and see if you can teach it to find any other files over pxe ;)
<cyphermox> by grub2 to pxe boot, you mean using whatever commands are available in grub to grab a kernel somewhere, or is it something else?
<slangasek> s/pxe/tftp/
<slangasek> not just the kernel, but also the grub.cfg
<cyphermox> fun.
<cyphermox> that might actually be something fun to demo tomorrow, too
<slangasek> if you manage to get this working for tomorrow, I'm buying the beer in CPH :)
<cyphermox> haha
<cyphermox> doesn't grub need to be looking for some variable (dhcp option or whatever) to know where to get the grub.cfg?
<slangasek> that's part of the challenge! :)
<slangasek> at this point, I'm just trying to get to where grub is reading files from tftp
<cyphermox> ok
<cyphermox> I think the option thing might be 209
<slangasek> that seems to be an option particular to pxelinux
<slangasek> option 17 is "root path"
<slangasek> and grub parses this
<slangasek> there's also an "extensions path"
<slangasek> (option 18)
<cyphermox> NBP is too big to fix in free base memory
<cyphermox> oops
<slangasek> heh, and that's just the bootloader
<cyphermox> getting farther
<cyphermox> slangasek: what is the difference between that grub file and efilinux.efi?
<slangasek> cyphermox: the fact that it's grub, not efilinux
<cyphermox> good answer ;)
<slangasek> and thus is likely to actually support tftp after :)
<cyphermox> well, seems to be too big for my device to allow loading it
<cyphermox> unless it's just because it's not passing the file size
<cyphermox> .. in 512byte blocks
<slangasek> cyphermox: looks like dnsmasq doesn't send a magic value at the start of the vendor section of the bootp packet that grub is counting on
<Whoopie> Hi, I enabled the proposed repository some time ago. I just recognized that two packages (language-pack-de-base and language-pack-gnome-de-base) are held back for a longer time as they are not installable. So my question is when new language packages are pushed to the proposed repo.
<obounaim> Good morning.
<doko> cjwatson, infinity: java3d - adding "-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed" should help. you are missing -shared when replacing ld with gcc and linking a shared lib. and drop the explicit -lc. see scheat:~doko/tmp
<RobOakes> Does anyone know the best channel to ask Ubuntu related packaging questions in?
<lifeless> #ubuntu-packaging ?
<RobOakes> lifeless: Thanks, that makes good sense.
<espirit> Hello. There are no available drivers in "Additional Graphics" tab for my ATI Radeon HD Mobility Graphics card (4xxx). Is this a bug?
<espirit> but they were available in jockey in 12.04
<ScottK> espirit: Make sure you have the latest as there was a bug that might affect that fixed yesterday.
<espirit> Yes. Just ran an update manager. But still no available drivers.
<ScottK> Not sure what's supported for ATI this cycle.  You might ask in #ubuntu-x.
<espirit> ScottK: Ok. Thank You.
<rmk> Hi guys.  What's the "pool" structure used for within the archives?
<rmk> I need to setup a local mirror of selected versions and am figuring out what I need
<SpamapS> rmk: the pool structure is just how the .deb files are arranged by default..
<rmk> So I don't necessary need to mirror it for use by apt, right?
<lifeless> apt-ftparchive is your friend
<lifeless> or one of the mirror tools
<SpamapS> rmk: right, something like  apt-ftparchive relative/path/to/debs http://yourmirror/docroot/that/leads/there
<SpamapS> rmk: that will spit out a Packages file
<SpamapS> rmk: man apt-ftparchive .. its a big man page, but a pretty straight forward process
<rmk> OK thanks.  Yeah I was planning to use rsync initially.
<SpamapS> rmk: if you just want a full mirror, then there are many ways to get that done: https://wiki.ubuntu.com/Mirrors#Mirror_Guidelines
<rmk> Right I read that page but I'd rather not mirror 600GB or whatever, when I need a fraction of it (oneiric, precise)
<SpamapS> rmk: apt-mirror makes that pretty easy
<rmk> Yeah this looks handy, thanks for the tip
#ubuntu-devel 2012-10-14
<cannonball> SpamapS: I don't know if you saw the followup email, but I was able to get the Quantal version of cups 1.6.1 to build on precise (is that right? 12.04)
<cannonball> I had to comment on one line of the apparmor profile for the cupsd binary, but then it started up just fine using my old cupsd.conf.  Now the ios 6 devices see the printer instantly.
<cannonball> I also think that your method looks a LOT simpler than the way that I did it, but I now have a _slightly_ better understanding of what is going on during deb builds.
<cannonball> Just slightly though...there's still a lot going on in the background (tons and tons of dh* commands rolling by) that I don't yet grok. :-)
<cannonball> Thanks for the feedback, see you at a LUG or maybe SCALE.
<micahg> doko_: new cairo-5c in Debian still fails on quantal
<micahg> doko_: sounds like you already know this :), nevermind
<cjwatson> doko_: Thanks for sorting out java3d.
<Mirv> something wrong with the universe repo? bug #1066445
<ubottu> Launchpad bug 1066445 in apt (Ubuntu) "Crashes doing update or upgrade operations" [Undecided,Confirmed] https://launchpad.net/bugs/1066445
<jibel> Mirv, confirmed on a fresh install on amd64
<jibel> thanks
<doko> Laney, there are some haskell ftbfs on arm, which don't look like the usual timeouts, e.g. https://launchpadlibrarian.net/119722073/buildlog_ubuntu-quantal-armhf.haskell-chell_0.3-1build1_FAILEDTOBUILD.txt.gz
<PN1> hi, i've uploaded a new media player to Ubuntu Software Center 2 day ago but my status is pending review. anyone knows why is it taking so long to show?
<SpamapS> PN1: there are a ton of other apps in front of yours waitin for review is probably the cas.e
<cjwatson> doko: already known, reported upstream (http://hackage.haskell.org/trac/ghc/ticket/7316), and not likely to be fixed for 12.10.  I already removed all the out-of-date binaries affected by this.
<lamont> apt-get -qq update
<lamont> Segmentation fault (core dumped)
<lamont> that does not happy make
<lamont> having quantal/universe in the sources.list at the same time as having quantal/main seems to cause that
<penguin42> lamont: Seems fine here
<lamont> penguin42: it's quite possibly mirror issues
<lamont> as in my mirror
<penguin42> lamont: http://paste.ubuntu.com/1279419/ is my sources.list
<lamont> that it's working well elsewhere tells me it's likely just me and that I'm special. :(
<lamont> no worries.
 * lamont digs deeper
<jibel> lamont, bug 1066445
<ubottu> Launchpad bug 1066445 in apt (Ubuntu Quantal) "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Critical,Confirmed] https://launchpad.net/bugs/1066445
<lamont> fact
<lamont> 0x00007ffff7b4dd20 in pkgCacheGenerator::ListParser::NewProvides(pkgCache::VerIterator&, std::string const&, std::string const&, std::string const&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
<jibel> it seems to be triggered by the record for grub-ieee1275 in universe
<lamont> though interestingly, apt-get update seems happy if universe is there and main is excluded
<skaet> lamont,  what were you starting from?   we're trying to figure out the pattern.
<Laney> doko: no, that is the usual
<lamont> skaet: the last reboot-requiring (desktop) upgrade on the machine was probably yesterday morning (-0700)
<lamont> since the reboot was 18 hours ago
<lamont> skaet: when I commented out universe and did the dist-upgrade, it installed debian-installer, nothing more
 * lamont reboots his irc box, brb
<jamin> got caught by a pretty nasty regression when I upgraded from 12.04 to 12.10: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1066324
<ubottu> Launchpad bug 1066324 in grub2 (Ubuntu) "core.img too large for embedding with msdos partition style" [Undecided,New]
<jamin> for some reason, 12.10's core.img generation results in larger files than 12.04's
<jtaylor> had that too :/
<jtaylor> or still have it, but I resized my boot sector to fix it
<jamin> so, combinations that worked perfectly under 12.04 no longer work under 12.10 and sadly you don't find out (or at least I didn't) until you try to reboot
<jtaylor> when did you setup the partitioning of your machine?
<jtaylor> if you pay attention during upgrade you do find out
<jamin> it's changed over time
<jamin> jtaylor, had no warning during the upgrade...
<jtaylor> there should be a message that core.img is to large
<jtaylor> but its easy to overlook
<jamin> if there was, I overlooked it... should be pretty big blocker
<jtaylor> it kind of sucks that you land in a rescue prompt then instead of grub being left unchanged
<jamin> as for the partitioning, I migrated the system into purely LVM during its 12.04 lifetime... but had no issues with grub after
<jamin> yes... if grub had been unchanged it would still have worked... and rescue prompt is rather useless at this point
<jamin> had to move the system to a GPT partition table to resolve it
<jtaylor> just sizing it to a sane size is enough
<jtaylor> unfortunately that takes ages
<jamin> even though there was a full 1M at the start of the drive before the first partition
<jtaylor> ok that is different than what I had
<jtaylor> sizing it to 1M fixed it for me
<jamin> it's solved for me now, but I can't image that I'm the only person that has everything residing inside LVM with an MSDOS style partition table
<jtaylor> cjwatson: you may want to look into that again ^
<jtaylor> I hit it at the time bug 1051154 was opened, after resizing and the bug being closed I didn't bother about it anymore
<jamin> would love to know why the core.img has increased in size from 12.04 though...
<ubottu> Launchpad bug 1051154 in grub2 (Ubuntu) "mdraid1x core image too large for minimal MBR?" [High,Fix released] https://launchpad.net/bugs/1051154
<jtaylor> but my core.img is still larger than 32k
<jamin> jtaylor, yea, I read that report... seemed like an off by 1 bug based on the feedback... but that doesn't seem to be what I'm running into
<jamin> jtaylor, what's the exact size of yours now?
<jtaylor> 33294
<jamin> odd, even larger than mine... so if your's fit, mine should have
<jtaylor> I now have 2024 sectors at the start
<jtaylor> it where 64 before
<jamin> maybe there wasn't a full 1M free at the start before I moved to GPT...
<jtaylor> what does sudo fdisk -l /dev/boot-device say for the start?
<jamin> could have sworn there was
<jamin> I've repartitioned the device now
<jamin> booted to a live-cd attached an external drive and pvmoved all the volumes off the internal drive... then repartitioned as GPT and pvmoved them all back
<jamin> though I think I saved the partition table layout as a precaution... let me see
<jamin> jtaylor, looks like it started at 63
<jamin> found the backup file... *sigh*
<jtaylor> I'm going to mark it critical, my machine was not partitioned to long ago (about 1-2 years) so its probably a not to uncommon thing
<jtaylor> and very hard to fix for inexperienced users
<jamin> very
<jamin> I believe that everything in lvm is one of the automatic partitioning configurations for partman isn't it? or does that one keep /boot out?
<jtaylor> don't know
<jtaylor> I too use lvm, probably its somehow related to it
<jtaylor> would explain why there aren't more reports of this
<jamin> it is related to lvm... if you rebuild core.img without the lvm module it's small enough to fit
<jamin> and looking at the automated recipes, they all appear to have /boot outside the lvm volume
<cjwatson> jamin,jtaylor: it'll definitely fit in 1MB.  As for the case where you only have 63 sectors at the start, no Ubuntu installer for the last few years will produce that layout by default, and I'm afraid I have approximately zero likelihood of being able to fix it by release
<jtaylor> cjwatson: figured as much, as it only appears to affect lvm feel free t reduce the importance or set it won't fix
<jamin> cjwatson, then it's safe to say that a number of people are going to wind up with unbootable boxes
<cjwatson> jamin: yes
<cjwatson> but I can't fix it
<cjwatson> not in time anyway
<cjwatson> we'll have to release-note it
<jamin> even if it's not "fixed" in an automated fashion is it not possible to have it seriously error in an in your face sort of fashion?
<cjwatson> not in time
<cjwatson> I mean, that's the only terribly plausible way to "fix" this at all
<cjwatson> but I have sooooooo many things to do
<cjwatson> of course people would complain about the resulting upgrade failure too, and it's not like moving partitions around is an easy thing to do
<jamin> how about an upfront check?
<cjwatson> it would at best defer the upgrade failure
<cjwatson> or defer the boot failure
<jamin> something at the start of the upgrade process that checks for only 63 sectors on the drive?
<cjwatson> if somebody else wants to attempt that ...
<cjwatson> it won't be me
<cjwatson> (and of course plenty of layouts do still work fine with 63 sectors, particularly after I fixed the off-by-one error in grub-setup)
<jamin> any reason the core.img increased in size?
<cjwatson> no very straightforward way to tell which in advance, without having the upgraded code
<cjwatson> grub 1.99 -> 2.00 - various bug fixes which involved bigger code
<jamin> guessing it's not possible to get it back down to 12.04 size
<cjwatson> no single cause
<cjwatson> it may be possible but requires serious work; I looked and there was no single obvious smoking gun
<cjwatson> just general drift
<jamin> I'd think a blanket warning for any 63 sector configuration would be better than waiting to see which can no longer boot
<cjwatson> I don't mind if somebody else wants to do that
<cjwatson> like I say, it's simply not physically possible for it to be me at this point, due to lack of hours
<jamin> yea, understood... just thinking of the fallout if this hits any decent number of users
<cjwatson> nearly every boot loader bug is critical for those it hits
<jamin> agreed, just never seen one from an upgrade like this
<cjwatson> yours is likely because of the combination of GPT and LVM; I'm fairly sure MBR and LVM fits
<jamin> nope... was MBR and LVM that caused it
<cjwatson> oh, wait, your grub-install debug output was from after you moved from GPT
<jamin> moved to GPT to resolve it
<cjwatson> way to file a confusing report :P
<jamin> yes
<jamin> sorry... couldn't file from a non-bootable system
<cjwatson> better not to mention the grub-install debug output then - I'll delete it from the description as it's actively misleading
<jamin> sounds like I could have stayed with MBR if I'd just moved my partitions down to start at 1MB in
<cjwatson> Yes
<jamin> sorry... wanted to show which modules were being used
<cjwatson> That's the default partitioner configuration since 10.04
<cjwatson> Now, gparted may be stupid
<cjwatson> I mean the actual Ubuntu installer partitioner
<jamin> gparted puts it at 1M
<cjwatson> Confusing given jtaylor's comment, unless that was a more recent fix
<jtaylor> I think I used gparted in default config for my setup
<jamin> I'd replaced the drive and migrated the installation from rotation to ssd
<cjwatson> Bear in mind that gparted may have different defaults for SSD
<jtaylor> but maybe I also left the boot partition at stock settings
<jtaylor> its been a while
<cjwatson> libparted typically tries to pick up the topology from the driver
<cjwatson> *drive
<cjwatson> So this kind of thing basically only affects people who've done by-hand partitioning with non-default tools, or who've upgraded since before 10.04
<jamin> think I may have used cfdisk to layout the partition on this SSD originally
<cjwatson> Yeah, cfdisk is dark-ages stuff
<jamin> seeing that now... =(
<cjwatson> I don't believe it's really kept up with modern alignment requirements and such
#ubuntu-devel 2013-10-07
<pitti> Good morning
<TripSec> pitti, Good morning
<TripSec> sudo apt-get install git, how do I access the dl?
<pitti> "dl"?
<ming> I added a comment when I use "gpg --gen-key", so should I add the comment in the ~/.bashrc when I export the DEBFULLNAME  ? I always need to add the comment to the changelog when I ues "dch".
<ming> by myself.
<slangasek> ming: well, consider this article - maybe you want to add a UID to your keyring that doesn't have the comment: http://www.debian-administration.org/users/dkg/weblog/97
<dholbach> good morning
<doko> barry, given back and it did build
<cjwatson> ming: Or you could add DEBSIGN_KEYID=<whatever your key ID is> to ~/.devscripts so that small mismatches don't matter, though the debian-administration.org post above is very sensible too
<pitti> xnox, slangasek: is there some special sauce which gets poured over the install images on releases for EFI/secureboot?
<pitti> xnox, slangasek: I tried to install my new x230 with saucy beta 1 and saucy daily, and they both are unbootable; /boot/efi/ is completely empty
<pitti> xnox, slangasek: installing raring and dist-upgrade worked without a hitch, and I have a working /boot/efi/
<xnox> pitti: it should just work, signed shim is uploaded in the archive and should be identical / present on all daily images.
<pitti> is that a bug, or expected due to some "special sauce"?
<xnox> pitti: i'd be expecting it to be a bug.
<pitti> xnox: I don't think that shim was the problem actually; I disabled TPM/SecureBoot/CSM etc. in the setup and it still didn't work; empty EFI partition doesn't sound good, right?
<xnox> pitti: good thing to test, is if booting saucy image, actually boots it in EFI mode.
<pitti> xnox: it did
<pitti> I set it up for "EFI only boot", got the grub-like start screen, and had /sys/firmware/efi, and dmesg babbled about EFI stuff
<pitti> ubiquity created an efi partition, but it was empty
<cjwatson> That suggests that the installation wasn't as successful as it thought it was.  There are probably errors somewhere in syslog
<xnox> pitti: if in the logs (can you mount and check them?) grub-installer failed, you probably want cjwatson.
<pitti> ok; I remembered too late to chroot in and save logs, will do that at a test reinstall
<pitti> I guess I could make a backup of the EFI partition, dd it to zero, run the saucy installer, collect logs
<pitti> I guess it's somehow possible to fix up the install manually, but the only recipes I found were rather complicated (and simple install-grub failed in chroot under live system with "cannot map BIOS drive" or so)
<cjwatson> pitti: you should be able to retrieve the logs from a live CD or equivalent
<pitti> *nod*
<cjwatson> the partman log would be useful as well since it's possible it didn't create/mount an EFI partition
<pitti> cjwatson: I meant after I did that it's certainly possible to manually create the EFI partition, so that I don't have to go back and install raring+upgrade
<cjwatson> depends on the failure
<mlankhorst> I hope mesa 9.2.1 gets accepted :) it fixes only updating the 1024x1024 topleft corner correctly in the tf2/hl2 games with nouveau drivers. \o/
<seb128> xnox, hey, just checking fur that apturl/update-manager issue is still on your todolist right?
<xnox> seb128: yes.
<seb128> xnox, great
<infinity> mlankhorst: Lemme have a look.
<infinity> smartboyhw: Did you really mean to add ardour3 to ubuntustudio-audio and not remove ardour?
<smartboyhw> infinity, yes we do
<smartboyhw> Ardour 2 sessions can't be opened again in Ardour 2 if they are opened in Ardour 3 once.
<smartboyhw> So, no.
<smartboyhw> No removal of Ardour 2.
<smartboyhw> (Until after 14.04, that is)
<infinity> smartboyhw: Kay.  Just looks a bit weird to have both, but your call.
<seb128> mardy, hey, did you receive any bug/are you aware of any issue with uoa/google account? mine keeps asking me to reauth (well, "keeps", I saw that basically once a day for a week, where it used to be weeks before I have to reauth again)
<seb128> pitti, ^
<mardy> seb128: are you using evolution?
<pitti> mardy: for me it's worse now, asking every few hours
<pitti> but I just installed a new computer yesterday, so it could be that my old gsettings or whatnot (I didn't move them to the new computer) kept the thing alive
<seb128> mardy, no, but I've an e-d-s account configure for calendar
<pitti> mardy: not using evo here (as in the application)
<seb128> configured*
<mardy> seb128: that's it :-(
<pitti> but I enabled evo in the online accounts settings
<seb128> mardy, that was not happening until recently, do you know what changed?
<mardy> pitti: yep, so it's EDS
<mardy> seb128: I didn't have a chance to investigate it yet, it's https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1210866
<ubottu> Ubuntu bug 1210866 in evolution (Ubuntu) "Ubuntu Online Accounts integration broken in Saucy" [Undecided,Confirmed]
<mardy> pitti: ^
<pitti> mardy: ah, thanks! /me subscribes
<mardy> seb128, pitti: it's due to an EDS upgrade
<seb128> mardy, 3.6 to 3.8?
<pitti> mardy: I'll try disabling the three EDS options for the google account in the account settings
<seb128> well 3.6 didn't have uoa integration
<mardy> seb128: most likely that
<seb128> I wonder if we should turn off uoa in eds, for saucy, then
<seb128> Laney, pitti, mardy: ^
<mardy> seb128: what EDS version was there in raring?
<seb128> 3.6.4
<seb128> that didn't have uoa support yet
<Laney> I've been avoiding using it because it was so flaky
<Laney> with 2fa anyway, think it's ok without that
<mardy> Laney: right, it's most likely due to 2fa
<mardy> upstream has fixed the issue in 3.9.something, by switching to Oauth
<Laney> yeah
<Laney> so I'd be in favour of turning it off
<seb128> shrug
<seb128> mardy, we are not sure we are going to update to 3.9 for the LTS btw :/
<seb128> is there any way to fix that issue on 3.8?
<mardy> seb128: not even if we start testing it very early?
<mardy> seb128: well, the immediate solution I think would be not installing evolution-data-server-uoa
<seb128> mardy, well, I'm suggesting staying on 3.8 (still being discussed), it's likely the version the next RHEL is going to use and it would be nice to align with them, since that's liking going to get more fixes than other series
<seb128> mardy, would you suggest installing the goa support then?
<seb128> or none of those?
<mardy> seb128: backporting the fix might be possible, but it will be a lot of code
<mardy> seb128: I'd say none
<seb128> mardy, ok, let's see next cycle, I need to look at how much changes in eds 3.10 and it depends on e.g gtk 3.10 (which we are not likely going to have)
<Laney> Yeah, we could probably selectively take stuff if it's worth it
<seb128> Laney, do you have some spare cycles today? Want to test building e-d-s without the depends on uoa/goa (or just force removal) and test if evolution works correctly/can add a calendar?
 * seb128 already has a long todo for the day
<Laney> mmm, ok
<seb128> Laney, thanks
<seb128> Laney, basically I think we agree on dropping uoa from the default install, I just wonder if we need to keep goa or not (it might be that some of the files in there are needed for calendaring, it already turned out that uoa was not working without the goa binary)
<Laney> did we have g before?
<seb128> yes
<Laney> probably just go back to that situation
<seb128> raring didn't have uoa yet (that got added to 3.8
<seb128> so we were just building with goa and not splitting binaries
<seb128> Laney, well, one of the things we wanted to avoid was to have goa-daemon running in Unity session
<rbasak> pitti: I filed bug 1235189 the other day. I think your stdout/err pipe thing regressed all non-null drivers.
<ubottu> bug 1235189 in autopkgtest (Ubuntu) "adt-run broken except when used with adt-virt-null" [Undecided,New] https://launchpad.net/bugs/1235189
<pitti> rbasak: ah, thanks; adding to my bug fix pipeline
<pitti> I ought to write some test cases for at least the chroot runner
<rbasak> I'm hoping to land adt-virt-lxc soon, and also adt-virt-kvm. With uvtool in Saucy now together with your pass-through of the cloud image, this should be much easier. Then I imagine a dep8 test for the kvm runner would be relatively straightforward to do (the lxc one will still have an external dependency on the lxc rootfs image)
<mlankhorst> can someone kill the mesa-9.1.7-1ubuntu1 upload to raring-proposed? I forgot to open a sru bug for it :)
<pitti> mlankhorst: it's not in https://launchpad.net/ubuntu/raring/+queue?queue_state=1&queue_text=
<infinity> (I may have beaten you to it)
<mlankhorst> ah ty
<tvoss_> pitti, ping
<pitti> hello tvoss_
<mlankhorst> ok any sru admin can approve the new mesa I uploaded to raring then? :P
<smoser> infinity, i did commit sane lp:software-properties and re-upload. re-review would be appreciated.
<smoser> thanks.
<cjwatson> roaksoax: Do you know what's happening with getting pacemaker rebuilt against current libraries?  (cf. http://people.canonical.com/~ubuntu-archive/nbs.html)
<cjwatson> We're running out of time
<roaksoax> cjwatson: ill take a look
<roaksoax> cjwatson: you mean pacemaker-mgmt?
<cjwatson> roaksoax: Yeah
<Laney> what do I need to make the release upgrader happy to remove a package? ISTR that versioned C&R isn't enough to avoid partial upgrades
<cjwatson> C+R is fine
<cjwatson> see update-manager 1:0.184
<Laney> ah, good
<Laney> ta
<arges> hallyn: hi
<hallyn> arges: hi (mtg about to start)
<arges> hallyn: ok real quick is there a wiki/pointer to some qemu tests I can run before i submit my sru to qemu-kvm ?
<arges> or should i just use upstream tests
<hallyn> arges: lp:qa-regression-testing  cd scripts; sudo python test-qemu.py
<arges> hallyn: perfect! thanks
<TJ-> According to bazaar importer system "usbutils" has failed to import since July 2012, which means the bzr branch is OUT-OF-DATE. What is the procedure for getting this fixed?
<stokachu> is there a public repo for code used to create launchpad builders?
<stokachu> i know sbuild mimics it but i thought launchpad has some special adjustments
<smoser> stgraber, if i file a FFE for software-properties , can i have it re-evaluated please?
<stgraber> smoser: once the FFe is accepted, sure, we can even accept it from the Rejected queue then
<smoser> ok.
<cjwatson> stokachu: lp:launchpad-buildd
<smoser> stgraber, can i just turn bug 1233486 into a FFE bug ?
<ubottu> bug 1233486 in software-properties (Ubuntu) "add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Medium,In progress] https://launchpad.net/bugs/1233486
<cjwatson> stokachu: I don't think it's worth trying to set up locally though - the cases where sbuild in the archive isn't close enough are very rare
<stgraber> smoser: yep, add [FFe] to the title and subscribe ~ubuntu-release
<cjwatson> (Unless you're actually hacking on the builders)
<smoser> thank you
<stgraber> cjwatson: that reminds me I need to publish my sbuild-launchpad-chroot script at some point (schroot hook that makes you use the Launchpad buildd chroots and keep them up to date as they change on the server side)
<stokachu> cjwatson: ok cool, im trying to figure out why mysql fails to build due to unittests but builds in launchpad just fine
<stokachu> me and another engineer ran into the same build issue locally
<cjwatson> stokachu: The one case that bites people from time to time is that LP builders are blocked from accessing network resources other than ftpmaster.internal and archive-team.internal
<cjwatson> (I don't know exactly how - that isn't in lp:launchpad-buildd)
<stokachu> ah maybe thats it then
<cjwatson> stokachu: So in the unusual case that a package tries to access something on the network and falls back to some other behaviour if it fails ... bit of a long shot though
<cjwatson> stokachu: Is this PPAs or the primary archive?
<smoser> stgraber, done. thanks.
<stokachu> cjwatson: primary archive
<stokachu> and its just a couple of unittests that fail causing the whole build to error
<stokachu> the code builds fine
<stokachu> chiluk: do you have a log of those unittests that failed locally still?
<chiluk> let me check
<cjwatson> stokachu: Different kernel version?  The primary archive builders will be on precise.
<cjwatson> (The base system, that is.)
<stokachu> the host was precise that i was on when it happened
<stokachu> not sure about chiluk's environment
<chiluk> mine is precise + 3.11 (eek)
<cjwatson> The buildds are on 3.2
<chiluk> I have two different logs, but they fail in two different spots.
<cjwatson> If it's racy then maybe the buildds just got lucky.
<chiluk> not sure..
<chiluk> so the end of my logs say to look at /tmp/buildd/mysql-5.5-5.5.32/builddir/mysql-test/var/log/warnings
<chiluk> but I failed at getting those out of pbuidler before it cleaned things up.
<chiluk> http://paste.ubuntu.com/6205439/
<chiluk> http://paste.ubuntu.com/6205443/
<chiluk> cjwatson stokachu ^^ those are the output from my builds... Unfortunately they are not the error logs.
<chiluk> infinity says he was able to build just fine though..
<cjwatson> Don't use pbuilder to reproduce Launchpad failures
<cjwatson> Use sbuild
<cjwatson> You might as well at least *try* to be accurate :)
<chiluk> cjwatson understood.
<chiluk> you asked for logs
<chiluk> and that's all I had..
<chiluk> my sbuild env is a bit fubar..
<chiluk> actually my whole system is a bit fubar at the moment.
<rbasak> I do my builds and dev work on a cloud instance, with a script to set one up.
<rbasak> Makes stuff reproduciable.
<chiluk> I was planning on re-installing today, since so many things are wrong with it... *(too many broken cross dependencies between ppas)
<chiluk> cjwatson, stokachu was using sbuild.
<rbasak> I have had issues with mysql. I suspect it's a race.
<chiluk> my machine must be winning that race!
<rbasak> ISTR there being some recent commits to debian vcs to fix some stuff related to that.
<cjwatson> That failure looks like a DNS argument
<cjwatson> -mysqlcheck: Got error: 2005: Unknown MySQL server host 'not_existing_host' (errno) when trying to connect
<cjwatson> +mysqlcheck: Got error: 2003: Can't connect to MySQL server on 'not_existing_host' (errno) when trying to connect
<chiluk> the first one looks like that.
<chiluk> the second one does not.
<chiluk> I eventually just ended pushing it up to a launchpad ppa
<cjwatson> ok, don't know enough about mysql to help further
<roaksoax> cjwatson: bug #1236414
<ubottu> bug 1236414 in pacemaker-mgmt (Ubuntu) "[FFe] New Upstream Release (2.1.2) to support pacemaker 1.1.10" [Undecided,New] https://launchpad.net/bugs/1236414
<jodh> ogra_: to rule out gcc attribute issues, it would be helpful to run the nih tests on mako/maguro.
<ogra_> what are the nih tests ?
<jodh> ogra_: "make check" for the libnih package.
<jodh> ogra_: I can now recreate the problem, so don't bother with that.
<ogra_> oh !
<ogra_> on grouper ? great !
<ogra_> now that i trashed my beautiful image with all these build deps ...
<ogra_> :)
<jodh> ogra_: there are 2 problems - I can't recreate the udev kernel issue, but I can recreate the issue whereby the session init doesn't release memory.
<ogra_> yay
<ogra_> do you use Mir ?
<ogra_> i would expect it to grab the vsync events too on nvidia
<ogra_> jodh, touch /home/phablet/.display-mir ... and reboot ...  to switch it on
<jodh> ogra_: I'll concentrate on the session init bug; the udev issue is not an upstart bug.
<ogra_> jodh, btw, the test build i had started before you told me not to just failed three tests
<jodh> ogra_: please raise a bug and one of the upstart devs will review :)
<ogra_> jodh, well, i'm building on a writable made phone fs ... not sure how valid this actually is
<jodh> ogra_: as long as /tmp is writeable and you aren't using overlayfs, should be valid.
<ogra_> ok
<slangasek> pitti: any luck figuring out that EFI install issue?
<pitti> slangasek: no, not yet; that'll take a few hours as I'll have to trash/reinstall my machine, and I had a lot of post-holiday catch-up to do today
<slangasek> pitti: ok
<cjwatson> roaksoax: Thanks for the pacemaker-mgmt upload.  I'm a bit concerned that you've dropped all the changes from debian/changelog (and possibly the rest of debian/?) in favour of whatever was upstream.  Was that intentional?
<cjwatson> roaksoax: "bzr di -c12 lp:ubuntu/saucy-proposed/pacemaker-mgmt" to see what I mean
<cjwatson> roaksoax: In particular you have reintroduced python-central which is a regression
<cjwatson> roaksoax: (But please don't just fix that on its own - the whole previous packaging should be restored and merged back in)
<roaksoax> cjwatson: yeah so the changes to debian/changelog were unintentional
<cjwatson> Looks like debian/copyright has been de-UTF-8-ed as well
<roaksoax> cjwatson: yeah. I'll fix that
<cjwatson> roaksoax: It looks like a symptom of unpacking the new upstream tarball and not restoring the previous packaging over the top of the debian/ directory it shipped
<iraycd> Hi
<iraycd> I'm new to development
<roaksoax> cjwatson: so I did uupdate ../<pkg>.orig.tar.gz
<iraycd> I'm a web developer
<cjwatson> roaksoax: It's possible uupdate got very confused by the (anomalous) presence of an upstream debian/ directory
<iraycd> Which is the best book to learn ubuntu development
<iraycd> :)
<iraycd> ??
<roaksoax> cjwatson: that's probably what happened. I'll get that fixed
<sarnold> JackYu: ah, thanks for the chinese-calendar explanation :)
<cjwatson> roaksoax: Still, lots of tasty NBS removals
<cjwatson> iraycd: Ubuntu development isn't really geared towards having books that are even slightly up to date.  It's probably better to start somewhere like https://wiki.ubuntu.com/UbuntuDevelopment
<iraycd> cjwatson: I know that. But it's difficult for me to follow. Can you tell me few keywords that I need to be familiar
<cjwatson> I don't do the web development end of things, so I probably can't give you much more specific advice
<iraycd> cjwatson:  :-) . Nice answer. What version control do most of the ubuntu developers workon? where do I need to host the project?
<iraycd> cjwatson: Can I use python for developing an app?
<cjwatson> bzr, though git is also popular.  Wherever you like, though we offer launchpad.net for hosting (which supports bzr).  yes.
<sarnold> iraycd: this seems popular for python-based web applications: http://en.wikipedia.org/wiki/Django_(web_framework)
<iraycd> Django is a web framework. How can I use it in native application development?
<sarnold> iraycd: ah, sorry, I thought you wanted to do web development stuff on ubuntu. :)
<iraycd> :P
<iraycd> I use ubuntu for web development. :P
<iraycd> I want to develop native apps
<iraycd> I want to make a music player
<iraycd> I like clementine. But it isn't so user friendly
<ogra_> iraycd, i bet you want to be in #ubuntu-appp-devel then ;)
<ogra_> (as the channel topic here suggests)
<dobey> -p
<sarnold> how many 'p's in that?
<ogra_> dunno, want some more ? i have a bag full :)
<sarnold> hehe :)
<iraycd> ogra_: Okay. Cool. This is IRC for Core OS development? :P
<ogra_> yeah :)
<iraycd> Cool
<iraycd> I will get updated from you guys
<iraycd> :)
<iraycd> bedrocklinux.org
<iraycd> I hope this is useful to you guys
<iraycd> :)
<stokachu> cjwatson: did vlan support ever make it into the debian installer?
<stokachu> ive seen some references to vconfig but not actual configuring the vlan
<cjwatson> stokachu: not AFAIK
<stokachu> cjwatson: ok thanks
<roaksoax> cjwatson: ok so this is the diff between the older debian/ and the fixed package: http://pastebin.ubuntu.com/6205805/
<cjwatson> roaksoax: I expected to see the removed debian/changelog entries back
<cjwatson> roaksoax: oh I misunderstood, sorry, disregard
<cjwatson> roaksoax: yep, that looks much cleaner, thanks
<roaksoax> cjwatson: and this is with what is currently in archive: http://paste.ubuntu.com/6205816/
<roaksoax> cjwatson: np! sorry about that!
<sarnold> seb128,pitti, the retracers look dead again
<cjwatson> doko: Could you please merge libapache2-mod-perl2 from unstable (or tell me I can)?  All the changes look appropriate, and we need the -D APACHE24 change to get at least one other package to build (libapache2-authcookie-perl)
<doko> cjwatson, ok, looking
<doko> cjwatson, uploaded
<zyga> slangasek: hey
<zyga> slangasek: I'm on saucy mountall
<slangasek> zyga: ok?
<zyga> slangasek: I've added a comment with all the details
<zyga> slangasek: not really, I'll do a few more reboot cycles
 * sarnold read "I'm on a saucy meatball", which sounded pretty good..
<zyga> slangasek: I'll test with static IP
<slangasek> on top of spaghetti, all covered with cheese
<zyga> slangasek: it all smells like UDP packets going to /dev/null to me + a timeout on top
<zyga> slangasek: quick question:
<slangasek> zyga: cute, ok
<zyga> slangasek: should the 'S - skip M - manual' prompt show up all the time?
<zyga> slangasek: when is it being displayed?
<zyga> slangasek: is it time based or some event based?
<slangasek> zyga: time based; if mountall waits for the mount for 3 seconds, it pops the prompt
<zyga> ok
<zyga> slangasek: after my network is working normally mount -a finishes in <1s
<slangasek> zyga: so your mountall.log has two boot runs in it; in one, /home is 'remote', in the other it's 'nowait'.  Are these both from mountal 2.51, and did you change /etc/fstab in between?
<zyga> slangasek: yes, no
<slangasek> hmm
<slangasek> *very* strange
<zyga> slangasek: I didn't touch fstab all day
<zyga> slangasek: all I did is reboot twice
<zyga> slangasek: (now)
<slangasek> so mountall parsed /etc/fstab differently each time(!)
<zyga> slangasek: I rm -f the log file before doing that
<zyga> slangasek: huh!!
<zyga> slangasek: I'll reboot and make sure I was doing that
 * zyga would like to rewrite mountall in python, with unit tests and such...
<slangasek> would not be accepted in python
<zyga> ok, brb
<slangasek> unit tests welcome, though
<zyga> yeah I know
<zyga> in C that's crap though (writing tests)
<zyga> slangasek: maybe rust? :D
<zyga> anyway, brb - rebooting
<zyga> reboot, stuck, I'll poke around
<zyga> slangasek: ok, I'm in the recovery shell, all filesystems are mounted, mountall doesn't see that
<zyga> slangasek: I take that back, /home/zyga/source isn't mounted
<zyga> slangasek: another hint, the log file I'm looking at shows that /home/zyga/source waits for /home
<zyga> slangasek: then /home gets mounted
<zyga> slangasek: but /home/zyga/source is never mentioned again
<slangasek> hmm
<zyga> slangasek: does mountall support that scenario?
<slangasek> it's certainly meant to :)
<zyga> slangasek: yeah, try_mount: /home/zyga/source waiting for /home
<zyga> slangasek: then I see stuff like: run_mount: /home: already mounted
<zyga> slangasek: as if mountall tried to mount home again
<slangasek> zyga: also, this is not the first time that I've seen evidence of NM declaring interfaces "up" before they're up.  Is there any chance you could try dumping ifconfig state to a log file at the point of /etc/network/if-up.d/upstart being run?
<zyga> slangasek: absolutely!
 * zyga mutters something about network manager being ready for servers 
<slangasek> zyga: what's the context of these 'already mounted' messages?  You said you're in recovery shell; so is this from mountall running before you entered the recovery shell?
<zyga> slangasek: I'm in tty6 that I've changed to show up early
<zyga> slangasek: and I'm looking at mountall.log with less
<slangasek> ok
<zyga> slangasek: I didn't run the recovery shell this time, sorry for being inprecise
<zyga> slangasek: so before net-device-up gets sent -- you want me to dump ifconfig, right?
<slangasek> yes
<zyga> slangasek: is /tmp mounted at that time?
<zyga> slangasek: should be, right?
<slangasek> zyga: not guaranteed; just write it out under /run
<slangasek> (which is guaranteed)
<zyga> slangasek: ok, thanks
<zyga> slangasek: ok rebooting
<zyga> slangasek: ok, looking at the new eth0.log -- it seems to be fine, I see my address and mask ok
<zyga> slangasek: anything you want to look for in particular?
<zyga> slangasek: if you want I can allow you to ssh into this box -- it's driving me nuts really :)
<zyga> slangasek: http://pastebin.com/JT3FN8eY
<zyga> slangasek: that's my mountall.log
<zyga> slangasek: http://pastebin.com/XGEj7Zn0
<zyga> slangasek: that's mount
<slangasek> zyga: so address and mask are there, but nfs still didn't mount right on this boot?
<zyga> slangasek: note that mountall says 3/8 remote while all remotes are mounted now
<slangasek> hmm
<zyga> slangasek: it's mounted after a moment
<zyga> slangasek: not when I initially log in via tty6
<zyga> slangasek: as my home is set to /
<zyga> slangasek: I can patch/build mountall if you give me hints as to what we could try
<zyga> slangasek: also please tell me if I should upgrade any of the packages that got affected by libc6 upgrade
<zyga> slangasek: I'll add ping silverbox before that event gets sent
<slangasek> replied on the bug, I think you probably want to rebuild mountall against precise to drop the deps (should build fine without changes)
<zyga> ok
<slangasek> currently reviewing this log to see if I an spot anything
<slangasek> I do know we get duplicate 'mounting' events for network mounts that are in progress when another network device comes up, but that's just a nuisance that shouldn't have any impact in this case
<zyga> ok
<zyga> I'll reboot and rebuild mountall
<zyga> slangasek: ping and ifconfig look ok, I'm sending one packet and it's working
<zyga> slangasek: maybe name resolver fails? my fstab uses names, not IPs
<slangasek> zyga: so what I don't understand (and can't reproduce here) is, why, when 'mount -tnfs' is called before the interface is up, does mount not fail immediately with an error?
<slangasek> zyga: do you have your names in /etc/hosts?
<zyga> slangasek: nope
<slangasek> hmm
<zyga> slangasek: my local DNS knows about those though
<slangasek> how local is local?  loopback?
<zyga> slangasek: well LAN, not local
<slangasek> ok
<zyga> slangasek: ah wait
<zyga> slangasek: I have silverbox (the NFS server) in /etc/hosts
<zyga> slangasek: so it's fully static, sorry, I forgot I did that
<slangasek> right
<slangasek> so I bet the difference between my config and yours is that mount.nfs behaves differently on a name resolution failure vs. server unavailable
<stokachu> anyone familiar with gns3 and if I have to actually pay to get a IOS to emulate a network configuration?
<zyga> slangasek: server unavailable is what? packet loss? NACK reply from the server?
<stokachu> i just need to test some vlan functionality
<slangasek> in fact, it's probably because mount itself handles network issues gracefully with an immediate error, whereas once we know the address and have passed it to the kernel, the kernel's nfs mounter code does something irritating
<slangasek> zyga: "server unavailable" being "no response" or "no route to host"
<zyga> a
<zyga> ah
<slangasek> in this case, it should actually be "no route to host"
<slangasek> because the first time through, we're trying to mount your NFS shares before *any* network is up
<zyga> slangasek: why is that (why do we try)? isn't that mountall-net.conf?
<slangasek> zyga: well, in theory we could have network interfaces that are up before mountall, and which never trigger retries via mountall-net
<slangasek> so we always try all the mounts immediately
<zyga> slangasek: ah, I see
<slangasek> but that runs us into problems when the mount helpers (or the kernel) misbehave, like this
<zyga> slangasek: ok, just confirmed that before net-device-up eth0 I have working DNS and ifconfig
<slangasek> zyga: anyway, workaround: drop silverbox from /etc/hosts, see if that doesn't fix it for you ;)
<zyga> ok
<zyga> slangasek: some hairy code I suspect!
<zyga> slangasek: there's a lot of bugs on nfs and mounting on launchpad
 * zyga reboots without any LAN entries in /etc/hosts
<zyga> !!!
<zyga> I think it worked, not sure yet :)
<slangasek> expected behavior: you'll have errors in mountall.log that say 'mount.nfs: failed to resolve server silverbox: No address associated with hostname" // "mountall: mount /nas/foo [pid] terminated with status 32", but as soon as eth0 is up they'll mount correctly
<zyga> slangasek: the S/M prompt showed up for split second then went away
<slangasek> ok
<zyga> slangasek: still looking at plymouth-text though
<zyga> slangasek: ok it's stuck, looking at log files
<slangasek> could be the /home/zyga/source again
<slangasek> that sounds like a bug in mountall that I haven't heard about before
<zyga> slangasek: oddly source is mounted now, still reading logs
<zyga> slangasek: last line in mountall log is remote 3/8 again
<zyga> slangasek: reading earlier to see what's up
<slangasek> yuck
<slangasek> I would like this log :)
<zyga> slangasek: http://paste.ubuntu.com/6206297
<zyga> slangasek: I'll rm and reboot to make sure I don't read stale stuff
<zyga> slangasek: same situation, looking at logs again
<zyga> slangasek: log from ONLY the last boot http://paste.ubuntu.com/6206309
<zyga> slangasek: question -- why does mountall say we have 8 remote fs? -- mounta | grep silverbox
<zyga> slangasek: question -- why does mountall say we have 8 remote fs? -- mounta | grep silverbox | wc -l prints 9
<slangasek> zyga: because one of them wasn't marked bootwait
<zyga> ah
<slangasek> (/nas/archive)
<zyga> slangasek: ok, I'll rebuild mountall now, unless you want me to do something else
<slangasek> zyga: still reading logs, go ahead :)
<slangasek> zyga: ok, done reading logs and grr. I'm going to have to think for a bit about how to catch this bug
 * zyga downgraded all packages to precise
 * zyga calls it a day
<zyga> slangasek: I'll rebuild and test more in the morning, thanks for the help slangasek!
<slangasek> zyga: sure thing
<halfie> I was wondering how you guys invoke "libfaketime" during the build process? is there a package / script which is responsible for this?
<slangasek> halfie: we don't
<slangasek> however, if one were to do so, you'd use the 'faketime' wrapper command
<halfie> slangasek, oh, weren't some of you guys working on doing Reproducible Builds thing?
<slangasek> there certainly may be people working on that, but nothing is currently being done for the Ubuntu archive in that capacity
<halfie> I see. thanks!
<cjwatson> doko: thanks!
<cjwatson> doko: um, don't see it though
<cjwatson> halfie: work on that is mostly happening in Debian
<halfie> cjwatson, oh, yes, they are the "upstream" in this case. but I don't have access to there devel channel ;(
<cjwatson> halfie: eh, sure you do
<cjwatson> halfie: it's on OFTC.  But you might be better off with mailing lists anyway ...
<halfie> that is pretty weird. they seem to have #debian on freenode which is active.
<halfie> will go to oftc one
<cjwatson> I think that's to collect people who don't bother checking what network it's on :)
 * halfie is guilty!
<cjwatson> I mean, IRC channels exist as soon as somebody joins them
<halfie> right, but you mean 1500 people are wrong at the same time :P ?
<cjwatson> I wouldn't expect #debian to be a developer channel
<cjwatson> it'll be way too noisy
<cjwatson> and yes, I don't see how that's an implausible statement :)
<cjwatson> https://wiki.debian.org/IRC
<halfie> heh, will try my questions on oftc. I want to do my home-work before I start posting on the mailing list.
<tarpman> halfie: spoiler: cjwatson is going to troll you by also being the person who answers you there :)
<halfie> LOL
<halfie> I am struggling with a hex diffing tool here ;( .. trying to figure out the differences in builds.
<slangasek> zyga: hey, you don't have any custom jobs keying on 'mounted' events, do you?
<cjwatson> doko: ah, sorry, I see it in unapproved now
<smoser> someone able to just reject cloud-init https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=cloud-init
<smoser> utlemming found an issue that we'll have to fix, so no need to waste resources on reviewing it.
<cjwatson> smoser: done
<smoser> thanks cjwatson
<slangasek> cjwatson: so I'm seeing strange behavior with grub under SecureBoot on saucy; it seems 'recordfail' is being set somewhere, even though it's not in /boot/grub/grubenv (according to 'grub-editenv /boot/grub/grubenv list'), and I get the boot menu with no timeout for the first option
<slangasek> ('set'/'echo $timeout' show no timeout value set)
<slangasek> cjwatson: does this sound familiar at all
<slangasek> ?
<slangasek> cjwatson: also, I'm very confused by the usage of make_timeout() in /etc/grub.d/00_header... which seems to take two arguments, ignoring the first
<bdmurray> doko: could you have a look at bug 1234218?
<ubottu> bug 1234218 in gcc-4.8 (Ubuntu) "4.8 doesn't throw -Wreturn-type anymore for wrong returns in macros" [Undecided,New] https://launchpad.net/bugs/1234218
<brainwash> which system application/daemon tells network-manager to change its state (awake/sleep) when suspending or resuming?
<cjwatson> slangasek: you mean timeout is set to -1?
<cjwatson> slangasek: make_timeout> I think that was to try to reduce the delta against upstream
<slangasek> cjwatson: I mean 'echo $timeout' returns an empty string, and the grub menu behaves as if it's set to -1
<cjwatson> That's not recordfail then
<cjwatson> recordfail sets it to -1
<slangasek> ok
<cjwatson> pastebin /boot/grub/grub.cfg?  (though may not be able to look right now, getting late)
<slangasek> any idea why recordfail itself is set?
<slangasek> sure, one sec
<slangasek> cjwatson: http://paste.ubuntu.com/6206949/
<cjwatson> recordfail?  Depends when you're checking
<cjwatson> It's *always* set on exit from GRUB
<cjwatson> The point of it is that it's set on boot loader exit and cleared on successful boot
<cjwatson> I can't see why timeout would be empty here; again, seems to depend when you're making your observations
<cjwatson> Oh, are you making your observations from a command prompt accessed via 'c'?  The menu code has probably modified $timeout before you got to look at it, in that case
<cjwatson> If recordfail is set in such a command prompt, then it must be being loaded from a grubenv file somewhere; you might like to check whether $prefix/grubenv is actually the one you checked earlier
<slangasek> cjwatson: I was checking from within the grub shell, 'recordfail=1' showed up in 'set'
<slangasek> and yeah, I just realized I have two disks in this machine... and /boot/efi/efi/ubuntu/grub.cfg is pointing to the wrong one
<slangasek> I wonder how that could be
<slangasek> hrm, no, it is the right disk
<slangasek> or rather, it's a partition *on* the right disk, but not actually the one that's used as the rootfs or /boot or /boot/efi :P
<cjwatson> can't remember how that works right now - maybe try sh -x'ing grub-mkconfig
<slangasek> ack
<cjwatson> (big hammer but it's what I usually do unless I know exactly what I'm looking for)
<slangasek> anyway, seems like a tractable bug now, I just need to figure out where grub got the bright idea to look at a partition that's not mounted... and why that partition isn't in my fstab
<slangasek> thanks for orienting me :)
<slangasek> wow, this partition is special, tune2fs -l doesn't even list a creation date for the filesystem
<cjwatson> maybe there are clashing uuids or something
<slangasek> not that I see
<slangasek> this uuid didn't show up anywhere except on this partition I didn't know I had
<slangasek> what's crazy is that it has a full complement of kernels on it, that something must have copied over there
<slangasek> stgraber: would you mind taking a look at bug #1234132 and let me know if you agree with the analysis there?
<ubottu> bug 1234132 in dnsmasq (Ubuntu) "dnsmasq needs to trigger mountall rescan of network mounts" [Undecided,Triaged] https://launchpad.net/bugs/1234132
<stgraber> slangasek: sounds right, dnsmasq itself is a universe package that IIRC doesn't even ship an upstart job. People installing that package usually get into a lot of weird issues which we sometimes try to accomodate (as was done in lxc, libvirt and NM) but it's not something we should be investing a lot of effort on (since we don't have any product shipping with that package)
<slangasek> stgraber: right - do you agree that this is something the dnsmasq package should handle, though, by signalling mountall?
<stgraber> slangasek: I'm not aware of how mountall works in that regard but if SIGUSR1 is the usual way of telling it network is ready, then I guess it'd be appropriate
<slangasek> ok
<slangasek> (yeah, it is)
<slangasek> thanks :)
<stgraber> assuming dnsmasq starts after the network is ready and can actually resolve stuff by that time (which I doubt it reliably is at the moment)
<slangasek> dnsmasq always starts unconditionally *after* the network is up, since it's only started in runlevel 2
<slangasek> so the network comes up, mountall very quickly tries to mount, and (in this config) gets a dns failure
<stgraber> and doesn't retry?
<slangasek> no, because mountall only retries when there's a network event telling it that it should
<stgraber> ah right, and you'll get the network event once ifupdown is done but that'll be slightly before dnsmasq actually starts
<slangasek> yes
<stgraber> dnsmasq should actually be starting as early as it can and have an if-up.d hook to get it to reload whenever a new interface is brought up, that'd fix the problem in a sane way
<slangasek> no, we can't start dnsmasq earlier, it'll just fall over for use cases where e.g. /var is a separate partition
<stgraber> ah and since /var is not guaranteed to be a mountpoint it can't depend on that...
<slangasek> the current configuration, which is 'start dnsmasq after the filesystem is up', is the only reasonable default behavior.  If someone then both wants to use dnsmasq as their only resolver, *and* has network mounts that will block the filesystem event, that's their problem to disambiguate locally :P
<stgraber> well, or we could have dnsmasq start on local-filesystem and if dnsmasq depends on a network filesystem to work, then that's clearly their bad :)
<slangasek> is it?  today, that works
<slangasek> why should you be disallowed to run dnsmasq as a server with /var on nfs?
<stgraber> didn't you just say it doesn't? dnsmasq when installed ensures its the only DNS server, so based on what you said above, that currently doesn't work
<slangasek> "ensures it's the only DNS server" - that's only the case once dnsmasq has started though, I think?
<stgraber> (if 127.0.0.1 is registered in resolvconf, everything else gets ignored)
<slangasek> yes, but it's not registered in resolvconf until dnsmasq starts, right?
<slangasek> so before dnsmasq starts, this all still works, using the DHCP-provided settings
<stgraber> you're indeed correct about dnsmasq/resolvconf. It still won't quite work because the DHCP client also needs /var, so networked /var is bound to be a problem :)
<stgraber> unless someone made dhclient less stupid lately and it now survives not being able to write its lease file
<slangasek> stgraber: ok, so not DHCP; but /var on NFS, static interfaces in /e/n/i with dns server info, and dnsmasq installed -> works
<stgraber> right, that should work
<slangasek> right.  so to preserve that (admittedly marginal) use case while supporting Klaus's use case, we have to not move dnsmasq up in the boot order, but instead retrigger mountall once dnsmasq is available
<slangasek> cjwatson: ok, looks like this is a problem with grub-install that's in some way specific to lvm.  This system was installed with ubuntu-server and custom LVM; under those conditions, grub-install skips all the load.cfg handling, but apparently doesn't clean up any existing /boot/grub/efi/EFI/ubuntu/grub.cfg (which I presume was there from a previous install attempt)
<slangasek> oops, that path is not quite right
<cjwatson> slangasek: OK, I can believe that
<slangasek> cjwatson: bug #1236625 filed
<ubottu> bug 1236625 in grub2 (Ubuntu) "grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root" [Undecided,New] https://launchpad.net/bugs/1236625
#ubuntu-devel 2013-10-08
<goodwill> pardon me ...
<goodwill> when I build my own ppa package from an existing package on a system I get this
<goodwill> the current version (1.4.1-1~ppa1) is earlier than the previous one (1.4.1-1)
<sarnold> goodwill: ~ is "special" -- it means "earlier than"...
<cjwatson> That's ignorable if you're aware that anyone with your package installed will by default be upgraded to the newer version
<cjwatson> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
<goodwill> so I want my package to supercede it
<cjwatson> the URL I just gave has advice
<goodwill> I've read it
<goodwill> before
<sarnold> goodwill: (think of it as an easy way to take version 1.2 from a newer release and then package 1.2~12.04, 1.2~12.10, 1.2~13.04, and be certain that they will be upgraded to '1.2' when the distribution is upgraded...)
<cjwatson> goodwill: but you haven't followed its advice
<cjwatson> goodwill: so read it again :)
<goodwill> I think I am not understanding it
<cjwatson> goodwill: in one sentence: delete the ~
<goodwill> oh damn
<goodwill> that right
<goodwill> so blind
<goodwill> did not see
<goodwill> thank you
<goodwill> sorry to be a bother
<cjwatson> np
 * goodwill headdesks for pebcac
<pitti> Good morning
<pitti> sarnold: they look fine from here
<pitti> infinity: hey Adam, how are you?
<infinity> pitti: Alive.  You?
<pitti> infinity: I just filed an FFE which I hope should be mostly formal/trivial (bug 1236708), WDYT?
<ubottu> bug 1236708 in ofono-phonesim (Ubuntu) "FFE: new binary package for automatically setting up phonesim" [Undecided,New] https://launchpad.net/bugs/1236708
<pitti> infinity: much better after a good night's sleep :) didn't get much over the long weekend with these French guys/girls and their wine
<infinity> pitti: Yeah, looked like a good time.
<infinity> pitti: As for ofono-phonesim, it's unseeded, so not subject to FF anyway.  But approved nonetheless.
<pitti> infinity: oh, is that so? I thought FF applied to the whole archive, just the barrier was much lower for unseeded
<pitti> anyway, thanks
<infinity> pitti: Unseeded stuff is auto-accepted.
<infinity> pitti: Anyhow, close your bug in your changelog (or by hand), etc.
<pitti> *nod*
<sarnold> pitti: good morning :) see e.g. https://bugs.launchpad.net/bugs/1235927 and https://bugs.launchpad.net/bugs/1235597 -- roughly one day and two days old, coredumps are still attached and no tracing
<ubottu> Ubuntu bug 1235927 in weston (Ubuntu) "weston crashed with SIGSEGV in eglGetDisplay()" [Undecided,New]
<ubottu> Error: ubuntu bug 1235597 not found
<pitti> sarnold: ah yes, it seems there is a bad ddeb which it keeps trying to download
<sarnold> pitti: excellent; I'm curious about the empathy-chat one, that might represent something more than the usual busted software. hehe. :)
<sarnold> pitti: thanks for investigating
<pitti> I twiddled the Packages.gz on ddebs, let's see how it works now
<pitti> sarnold: seems happier now, 474 crashes to catch up with..
<pitti> sarnold: thanks for pointing out!
<sarnold> pitti: oh man, my email in the morning is going to be something impressive. heheh. :) thanks!
<dholbach> good morning
<rbasak_> xnox: hey, any chance you could take a look at bug 1209493 for me please? It's a straightforward merge with a dep8 test added. Just pushing it for final freeze.
<ubottu> bug 1209493 in subversion (Ubuntu) "[FFe] libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493
<infinity> rbasak: Oh, I missed my pilot day yesterday, I can do it.
<rbasak> infinity: thanks!
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, infinity
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<infinity> There, now the stats bot will be happy. ;)
<infinity> A changelog delta that goes all the way back to hoary.  Not bad.
<infinity> rbasak: Nice dep8 test, too.
<rbasak> infinity: thanks. I just noticed one minor mistake though (though it'll still pass I think).
<rbasak> It's needs-root, but I used sudo. Do you mind dropping the sudos, please?
<infinity> Sure.
<infinity> It would fail to pass if sudo wasn't installed.
<rbasak> Right
<infinity> Otherwise, would be a no-op and work fine.
 * rbasak tested the test with adt-virt-lxc on a cloud image, where sudo is installed
<rbasak> I think our infrastructure uses cloud images too. But it shouldn't be there really.
<infinity> rbasak: I like that it tests svnadmin, svn, and the apache module all in one go, though.
<rbasak> It's a happy consequence. I didn't feel that I could test the apache module without testing both checkouts, commits and plain HTTP. And that involved the other pieces ;)
 * infinity has never seen the trailing-dot chown notation.  Does that actually work?
<rbasak> It works, though the manpage seems to refer to colons only
<infinity> rbasak: Yeah, I mean "user." as opposed to "user.group" or "user"
<rbasak> user: is documented
<infinity> Looks like user. sets group to the user's primary group?  Maybe.
<rbasak> Right
<infinity> Learn something new every day.
<rbasak> Though I never realised that "." was non-standard as opposed to ":".
<slangasek> I thought there used to be a 'user:.' syntax, but that seems to have gone away
<slangasek> (and it meant the same thing anyway, IIRC)
<infinity> rbasak: . can be ambiguous on systems where people use . in usernames.
<rbasak> Given that . isn't mentioned on the manpage, I shall start using : instead
<infinity> rbasak: Hence :
<rbasak> Ah, that makes sense. Thanks.
 * slangasek nods
 * infinity will change your . to a : in this test too.
<rbasak> Thank you!
<infinity> .. And reference the FFe in the changelog.
<rbasak> +  * Includes changes from Debian nmu5 and nmu6 to restore the Apache module
<rbasak> +    (LP: #1209493). Thanks to James McCoy for the Debian NMUs.
<infinity> Oh, you did further down.
<infinity> Yeah.
<ubottu> Launchpad bug 1209493 in subversion (Ubuntu) "[FFe] libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493
<infinity> rbasak: I can trust that you test-built this a few dozen times and not do it myself? :P
<rbasak> I have test built it, yes. And the dep8 test passes in my environment at least.
<infinity> Alrighty, up she goes.
<rbasak> Oh, one note. The tests failed in a PPA build, but pass in sbuild and (presumably) the buildds.
<rbasak> (the "nocheck" tests, that is)
<rbasak> I didn't investigate that further. I presume it's OK.
<infinity> Why allow-stderr?
<infinity> I mean, other than your test using set -x
<rbasak> I find "set -x" really handy for writing these tests
<infinity> Mmkay.
<rbasak> To remove allow-stderr I have to drop "set -x" and then debugging gets really tedious
<infinity> Yeah, I'm all for verbose (ish) logs, so whatever works for you.
<rbasak> Thank you!
<slangasek> rbasak: exec 2>&1; set -x ?
<slangasek> though perhaps that gives no practical difference from allow-stderr :)
<infinity> Yeah, not really.
<slangasek> (if the bit that's set -x is at the top level)
<infinity> Just confuses people who don't grasp FD redirection.
<infinity> Which is, like, everyone who hasn't hacked on something joeyh or I wrote.
<rbasak> I never considered that might work. I wasn't aware of where the "set -x" output came out from. I always presumed that it was at a higher level and not affected by redirection in the same shell.
<slangasek> rbasak: shell fd redirection is actually a very thin syntax on top of the C fd interfaces :)
<mlankhorst> can someone approve mesa to raring-proposed?
<ogra_> slangasek, i heard rumours that you wanted to take a look at bug 1235649 ? did you do anything in that direction already (any info that the europe shift could pick up from you ?)
<ubottu> bug 1235649 in upstart (Ubuntu Saucy) "session upstart leaks massive amounts of memory on Ubuntu Touch" [Critical,Confirmed] https://launchpad.net/bugs/1235649
<rbasak> That makes sense
<rbasak> It would take extra work to make "set -x" independent I suppose
<slangasek> infinity: didn't Tollef write the debconf fd redirection madness?
<infinity> slangasek: I suppose he might be to blame.
<infinity> slangasek: There are any number of us silly enough to have done such a thing.
<slangasek> ogra_: just synced with jodh on that, actually; unfortunately I didn't get a chance to look at it today
<ogra_> ok
<slangasek> infinity: well, Tollef at least recanted afterwards ;)
<slangasek> that whole "you can accidentally break the debconf frontend by writing to stderr" thing...
<Caelum> Hello, I added a comment to this bug https://bugs.launchpad.net/ubuntu/+source/gedit-plugins/+bug/1165742 it's marked as 'fix released' but it's not fixed, could someone please change the status?
<ubottu> Ubuntu bug 1165742 in gedit-plugins (Ubuntu) "Synctex plugin was not built in raring" [Low,Fix released]
<infinity> Caelum: Set back to confirmed.
<Caelum> infinity: thank you very much!
<infinity> Caelum: So, it looks like (for gedit-plugins), this should be fixed in saucy.
<Caelum> excellent
<infinity> init: /home/buildd/build-PACKAGEBUILD-4962761/chroot-autobuild/etc/init: Configuration directory deleted
<infinity> I thought that was fixed...
<infinity> Silly upstart mucking about in my buildd chroots.
<FourDollars> xnox: Hi, I made https://code.launchpad.net/~fourdollars/ubuntu/precise/upower/fix-lp-bug-1153488 for https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1153488. Could you help me to review it?
<ubottu> Ubuntu bug 1153488 in upower (Ubuntu) "Treats bluetooth input device batteries as batteries" [Low,Fix released]
<slangasek> infinity: I thought we only fixed the bit where pid 1 would crash after mucking ;p
<slangasek> infinity: I think I have this fixed in the Debian packaging branch, which I haven't uploaded yet because I'm waiting for a maintainer upload of libnih...
<xnox> FourDollars: But description should be changed to include information as required for StableReleaseUpdates, you can use a handy template as a starting point https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template . The testcase is the most important bit.
<xnox> FourDollars: the bug is not nominated for Precise series, I'll do that for you.
<FourDollars> xnox: I see. Thanks.
<xnox> FourDollars: the proposed branch, seems to have more patches than to simply fix the bug in question. E.g. there are no pygtk depreciations in precise and etc. (but that's at first glance only). Is there only the minimal patch you can pick up for the SRU to fix the bug in question (and nothing else?!)
<xnox> FourDollars: your branch proposal should end up in the sponsorship queue http://reqorts.qa.ubuntu.com/reports/sponsoring/ and patch pilots should pick it up.
<xnox> Oh............
 * xnox realises I've been piloting for a week now?!
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mlankhorst> lol
 * Laney gives xnox a World's Best Sponsor mug
<xnox> dholbach: do you think we can make udevbot to automatically do "@pilot out" 8 hours later on the person, and ping them if they wish to continue?
<xnox> Laney: will you be in London next week? =)
<Laney> no
<slangasek> xnox: amazing you didn't run out of fuel
<dholbach> tsimpson, ^ do you know if what xnox asked can be done?
<Laney> not cool enough for that :P
<seb128> xnox, hey, is that apturl still on your todolist?
<tsimpson> dholbach: hmm, it may be possible. but it would require a complete redesign of the code (it's very simple right now)
<dholbach> xnox, ^
<infinity> slangasek: I suspect the maintainer of libnih isn't willing to admit he's MIA? :P
<xnox> infinity: no.
<xnox> he is not admitting that =)
<Laney> do some salvaging :P
<xnox> infinity: but then again, i'm not sure a MIA ping was officially filed.
<slangasek> infinity, xnox: well, I haven't filed the bug against the Debian package for this either
<slangasek> so I should maybe do that
<tsimpson> http://bazaar.launchpad.net/~tsimpson/+junk/udevbot/view/head:/plugin.py is the code (if anyone's interested in working on it)
<FourDollars> xnox++ LOL
<xnox> seb128: yes, but not highest priority.
<seb128> xnox, shrug, should we try to ask help to somebody else for it?
<xnox> seb128: you could, yes.
<seb128> it sucks to have apturl and package installs though it not working
<xnox> seb128: true, but that could be SRUed, even 0-day SRU.
<seb128> slangasek, hey, is there anyone in foundation that could help on 1200775 (some update-manager refactoring created issue for apturl and installing packages doesn't work anymore in saucy, which impacts e.g samba install from nautilus-share, or codec installs)?
<xnox> =)
<cjwatson> slangasek: I'm pretty sure the debconf fd redirection madness is joeyh's fault
<cjwatson> slangasek: Also pretty sure it's writing to stdout that can break it, not writing to stderr :)
<Laney> https://launchpadlibrarian.net/152824149/buildlog_ubuntu-saucy-arm64.gstreamer0.10_0.10.36-1.2ubuntu1_FAILEDTOBUILD.txt.gz
<Laney> is that some known arm64 failure mode?
<cjwatson> Laney: Yes, the APM hardware (or kernel, we're not 100% sure) isn't absolutely reliable - but the failures are AFAWCT always accompanied by dmesg indications, so infinity hacked launchpad-buildd to grep for those
<cjwatson> Laney: I gather that one's gone wrong a few times so it may need to be built on the very-slow-but-eventually-reliable sim
<Laney> That's the first FTBFS mail I've had about it
<Laney> False
<Laney> I got two at once so mentally disregarded one of them
<wgrant> There should have been three :/
<Laney> I'd trust your logging over my mail client
<apachelogger> mh, could bug 1209031 be an ubuntu-desktop bug maybe? doesn't apply to any of the kde printer setup tools it seems
<ubottu> bug 1209031 in printer-applet (Ubuntu) "no way to add lpd/lpr printers on saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209031
<Riddell> apachelogger: I'll remove printer-applet shortly
<apachelogger> \o/
<ogra_> pitti, do you happen to know a way to tell dbus to ignore certain events (specifically a uevent on the system bus)
<seb128> ogra_, what are you trying to do?
<seb128> ogra_, do you debug/dbus-monitor or do you code?
<ogra_> seb128, trying hard to be less desparate over bug 1234743
<ubottu> bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus when playing mp4" [Undecided,Incomplete] https://launchpad.net/bugs/1234743
<pitti> ogra_: hang on, are we talking uevents or dbus signals here?
<pitti> (not that you could ignore either)
<ogra_> (this isnt related to mp4 at all its happening constantly and kills the Mir sessions)
<pitti> ogra_: uevents are emitted from the kernel through netlink, you can't really ignore them I'm afraid
<ogra_> pitti, well do you happen to have a maguro ?
<pitti> ogra_: no, mako
<ogra_> ah, sad
<ogra_> the system bus is saturated with VSYNC events from the graphics driver
<pitti> ogra_: hm, dbus doesn't directly relay uevents
<ogra_> and i fear the driver communication actually uses the uevents internally which means we cant disable them on the lowest level
<pitti> ogra_: is that being done by some service, like perhaps upstart?
<ogra_> i guess upstart guides them onto the bus yeah
<pitti> i. e. something which listens for uevents and sends them via dbus
<pitti> as you can use uevents as upstart conditions, that might happen; aside from that I only know the subsystem specific ones like for "block" or "power_supply" which are getting (kind of) repeated on dbus
<diwic> seb128, hi, I'm doing some experiments with indicator-sound and I'm wondering if you know where to read debug output (or similar) from that service?
<ogra_> http://paste.ubuntu.com/6209230/
<ogra_> about 100/sec of these i'd say
<pitti> ogra_: ah, so it's upstart indeed
<ogra_> yeah :/
<pitti> ogra_: but 100/s is a kernel bug; it will cause loads of wakeups and never let the device sleep, so I'm afraid we can't really work around that in userspace
<ogra_> pitti, it stops as soon as the screen blanks
<ogra_> it might only be 60/s
<seb128> diwic, ~/.cache/upstart/dbus.log I would guess, since it's dbus activated
<ogra_> since i think thats the vsync frequency thats hardcoded in the driver
<pitti> ogra_: you see the same in "udevadm monitor -e --kernel" I suppose?
<pitti> ogra_: eek, emitting a change uevent on every frame? at least that explains the frequency
<seb128> diwic, or you can "stop unity-panel-service", stop indicator-sound-service, run it by hand and start unity-panel-service
<ogra_> pitti, yeah, less cruft around the single message though
<seb128> diwic, you need to stop/start ups otherwise it's going to respawn the service before you manage to run it by hand
<ogra_> pitti, right, and i fear the binary PVR driver actually needs that
<pitti> ogra_: that started happening with a recent kernel?
<seb128> diwic, oh; export INDICATOR_ALLOW_NO_WATCHERS=1 if you do run by hand
<pitti> ogra_: that would be evil, bad, and wrong.. did that just not occur to anyone else before, or did that just start recently?
<seb128> diwic, otherwise indicator services do exit
<diwic> seb128, thanks
<infinity> pitti: I suspect it was done on devices that don't run udev, and no one thought of the insanity this would cause on a real Linux userspace.
<infinity> pitti: (Not that that excuses the abuse of the interface in that manner)
<diwic> seb128, your advice seems to work
<ogra_> pitti, it was always there but recently got heavily exposedthrough bug 1235649
<ubottu> bug 1235649 in upstart (Ubuntu Saucy) "session upstart leaks massive amounts of memory on Ubuntu Touch" [Critical,Confirmed] https://launchpad.net/bugs/1235649
<seb128> diwic, great
<seb128> diwic, yw ;-)
<pitti> ogra_: hm, so we never ran power tests on that device then, and saw that udev and upstart were spinning all the time then?
<pitti> ogra_: *sigh* @ driver devs :/ But I honestly have no idea how to workaround it
<diwic> seb128, my experiments, at a later stage, might need some design input before being merged, do you know who I should talk to when I get that far?
<infinity> ogra_: have you actually tried removing the offending kernel code that omits the event to see if the PVR driver explodes?  Or are you just assuming it will?
<seb128> diwic, try mpt I would say
<ogra_> infinity, colin king did ... bug 1234743
<ubottu> bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus when playing mp4" [Undecided,Incomplete] https://launchpad.net/bugs/1234743
<xnox> pitti: ogra_: i thought one can apply netlink filters. And don't we simply need to filter/ignore that one in upstart-udev-bridge => and thus it will not be re-emitted as :sys:udev-event.
<diwic> seb128, ok, thanks!
<seb128> diwic, yw!
<ogra_> xnox, that might be enough thats why i was asking pitti for a filter to dbus :)
<pitti> xnox: we'd also need to ignore it in udev itself, to keep that from spinning
<pitti> otherwise udev would constantly keep processing rules
<pitti> that's assuming that we care even a little bit about power usage, of course
<ogra_> infinity, my suspicion is that PVR uses the uevent to actually do syncs, which is why i look for an alternative solution
<xnox> pitti: we care about power usage, but chopping off at udev-dridge, will save us upstart event in pid1 and re-emit over dbus to session-upstart and event there.
<pitti> xnox: I think netlink allows you to filter by subsystem etc., but not sure it can filter out particular drivers
<xnox> pitti: at least that should be a chunk.
<pitti> xnox: yes, but that leaves everything else that actually listens to uevents
<ogra_> subsystem would be rather bad
<xnox> pitti: my impression from "documentation" by keybuk was that it's fairly flexible http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/
<ogra_> given the vsync comes from a platform device
<pitti> no, we can't quiesce everything from platform
<pitti> xnox: yeah, hence the "I'm not sure"
<xnox> pitti: well, i haven't coded socket filters yet =) so i am also hypothetical.
<pitti> we'd need to tell udev's netlink socket "get all uevents except that one"
<xnox> pitti: keybuk starts with filter of "pass through nothing", then "pass through everything" and then "pick one"
<TJ-> Can someone review the merge proposal for bug #1235162 ?
<ubottu> bug 1235162 in systemd (Ubuntu) "Regression: Persistent net names via /etc/udev/rules.d/70-persistent-net.rules fail" [High,Triaged] https://launchpad.net/bugs/1235162
<pitti> TJ-: can do, just not right now (queueing)
<TJ-> pitti: Many thanks
<ritz> cyphermox hi, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1186273
<ubottu> Ubuntu bug 1186273 in network-manager (Ubuntu Raring) "DUN via bluetooth fails" [High,Triaged]
<ritz> could this be pushed into precise
<xnox> pitti: doesn't mir listen to that vsync udev event and needs it? thus we shouldn't be removing it at udev level? or does mir directly subscribe to kernel events (not udev events)
<xnox> ?
<pitti> xnox: err, what?
<pitti> xnox: last time I talked to the mir developers they didn't even know about uevents; they do input device detection with inotify on /dev/ (!), which causes "nice" race conditions
<xnox> pitti: interesting. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/11
<ubottu> Ubuntu bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus when playing mp4" [Undecided,Incomplete]
<xnox> pitti: unless that was fixed in powerd.
<xnox> upload.
<ogra_> Mir needs VSYNC
<ogra_> but not via dbus or upstart
<ogra_> xnox, mako does not spill these uevents (thanks to a likely saner driver) and Mir works fine there
<pitti> ogra_: well, but I hope Mir doesn't expect VSYNC messages as uevents?
<ogra_> no, then mako wouldnt work
<ogra_> the dbus-monitor --system log there is pretty quiet
<ogra_> (just some cpufreq noise)
<pitti> tvoss: ^ any idea here? I hope Mir doesn't actually expect vsync uevents, and that's just a quirk of the maguro driver?
<sforshee> pitti: I think it's the userspace side of the android graphics driver that's expecting the events
<xnox> sforshee: then why is it needed with Mir?
<xnox> sforshee: (sure it might be needed for surfaceflinger)
<pitti> sforshee: ok; that would explain why mako doesn't have that problem, but maguro does
<sforshee> isn't mir still using the android drivers?
<pitti> yes, I believe it does
<xnox> sforshee: ah, I see.
<xnox> never mind me then.
<sforshee> pitti, xnox: look at hardare/ti/omap4xxx/hwc/hwc.c in the android sources
<tvoss> pitti, not really, let's cross-check with kdub once he is online, though
<cyphermox> ritz: ack, will do soon
<ritz> thank you
<xnox> pitti: updated bug report with help by ogra_'s testing. Dropping that event in upstart-udev-bridge - reduces init/session-init memory usage, but systemd-udev is still spinning at like 5% CPU usage, whilst the screen is on.
<jodh> xnox: I don't think that patch belongs in upstream as it is entirely ubuntu-specific.
<xnox> jodh: sure, ok. i will probably have to write one for udev as well and then we will pick one.
<jodh> xnox: I discussed yesterday a plan to allow filtering for the udev bridge, but that is somewhat unlikely to be happening in the next couple of days :)
<lesshaste> hi..
<lesshaste> hi
<lesshaste> what is happening with xpdf? It is 100% broken in 13.04  but this doesn't seem to be urgent
<lesshaste> is it now deprecated as a pdf viewer?
<xnox> jodh: it would be nice, if we could drop some kind of udev.rules file that would do the matching and not emit the event to us.
<jodh> xnox: yeah
<soren> lesshaste: It was moved from main to universe in Edgy.
<lesshaste> ah.. and universe is not supporteD?
<xnox> jodh: replace upstart-udev-bridge with udev.rules that do initctl emit ?
<lesshaste> I should know that
<ritz> dobey hi, https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/926763
<ubottu> Ubuntu bug 926763 in software-center (Ubuntu) "Cannot install local packages (.deb files) without network connection (offline)" [Medium,Triaged]
<soren> lesshaste: It's sort of supported.
<lesshaste> soren, ok.. so never working at all seems bad :)
<ritz> could you please look this up
<lesshaste> soren, I mean, it's not like it works for some people
<soren> lesshaste: It comes with no guarantees. If someone feels like it, they can work on it.
<lesshaste> soren, ok but surely it should just be removed if it is never works for anyone?
<lesshaste> it doesn't seem good QA otherwise
<soren> lesshaste: Sure.
<soren> Man... I haven't used xpdf for over 6 years, probably.
<jodh> xnox: it's a though :)
<soren> lesshaste: Hm.. Someone seems to care about it.
<lesshaste> ah.... https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/943195   .. status triaged for raring
<ubottu> Ubuntu bug 943195 in xpdf (Ubuntu Raring) "xpdf.real crashed with SIGSEGV in GooHash::hash()" [High,Triaged]
<soren> lesshaste: It's been updated half a dozen times this year.
<lesshaste> which I assume is a precursor to actually releasing it
<lesshaste> soren, well.. as I say.. I don't think the 13.04 version works for anyone
<soren> lesshaste: I just tested it. It works for me.
<lesshaste> soren, the 13.04 version?
<soren> Oh, wait. I'm on 13.10.
<lesshaste> aha
<lesshaste> it would be nice if there were tests before release
<lesshaste> it might involve some imagination for how to do that automatically I suppose
<soren> It certainly would.
<lesshaste> or even tests after release :)
<soren> Oh, there were.
<soren> You did them. Just now.
<lesshaste> right but 13.04 is not new
<lesshaste> it just looks bad
<lesshaste> the report seems to be from 2012-02-29
<lesshaste> unless I am reading the wrong date
<lesshaste> ok so now I just need to ask someone to get it past Triage :)
<lesshaste> where someone is Dmitry Shachnev
<lesshaste> I think
<lesshaste> soren, thanks in any case.. out of interest was " It certainly would." in reply to the tests before release or the imagination comment?
 * mitya57 reads
<mitya57> lesshaste: it's in review queue, https://launchpad.net/ubuntu/raring/+queue?queue_state=1
<mitya57> someone from the SRU team should approve it
<soren> lesshaste: Both, I guess.
<lesshaste> mitya57, ok, thanks.
<lesshaste> soren, well crashing on startup shouldn't be too  hard to test
<lesshaste> although clearly easier for some applications than other
<lesshaste> s
<smartboyhw> Is somebody willing to sponsor https://launchpad.net/bugs/1236111 SRU?
<ubottu> Ubuntu bug 1236111 in ubuntustudio-default-settings (Ubuntu) "Help icon in 12.04.3 launcher menu opens 404 page" [Medium,Triaged]
<soren> lesshaste: If xpdf was the only package in the archive, sure. There's just more than 20000 other packages to worry about.
<mitya57> smartboyhw: shouldn't it be Type=Link instead of Type=Application?
<soren> lesshaste: And each flavour of Ubuntu has its own recommended pdf viewer. Neither use xpdf.
<smartboyhw> mitya57, in the current version of such line it is Application also...
<mitya57> smartboyhw: that's wrong and it's a hack, i.e. exo-open can be not always available
<mitya57> see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
<mitya57> (I've just posted that link to the bug as well)
<smartboyhw> mitya57, what should be the correct fix then?
<smartboyhw> Not quite getting the idea, since we've been using it...
<lesshaste> soren, sure but does every package have at least one person who cares about it?
<lesshaste> soren, I mean doesn't...
<mitya57> smartboyhw: Type=Link, URL=...
<smartboyhw> mitya57, OK
<mitya57> Also I can't find that file in the current bzr branch
<mitya57> Was it renamed?
<smartboyhw> mitya57, yes, renamed to ubuntustudio-help.desktop (same dir)
<lesshaste> soren,   you make it sound like one person would have to write a test for all the packages which I agree would not be realisttic
<mitya57> smartboyhw: http://paste.ubuntu.com/6209737/
<mitya57> that's lp:ubuntustudio-default-settings
<smartboyhw> mitya57, ok, I mean the quantal version-.-
<smartboyhw> Saucy version moved to another pacakge
<smartboyhw> (ubuntustudio-menu)
<smartboyhw> (Same thing still, anyhow)
<mitya57> Ah, well, anyway from changelog I see we should ask Len Ovens if there was any reason for using exo-open
<smartboyhw> mitya57, please check the new debdiff
<smartboyhw> mitya57, I'll talk to OvenWerks on this
<mlankhorst> ping, can anyone accept my mesa 9.1.7 uppload to raring-proposed?
<mitya57> smartboyhw: thanks, better now. Does it work?
<smartboyhw> mitya57, wait, need to boot up a VM...
<mitya57> yes, it would be nice if you tested it before I upload it :)
<smartboyhw> mitya57, doesn't work, it says it can't execute the child process
<mitya57> what's the error message?
<smartboyhw> (no such file or directory!?)
<smartboyhw> Probably need a url prefix
<smartboyhw> (or that sort of thing)
<smartboyhw> mitya57, ah, my fault
<smartboyhw> mitya57, ACK, tested
<lesshaste> soren, just in case it is interesting.. it seems you can test things using http://mywiki.wooledge.org/BashFAQ/068 plus echo $?
<mitya57> smartboyhw: uploaded
<lesshaste> 139 means SIGSEGV
<roaksoax> jdstrand: howdy! quick question about apparmor. So a package postinst is running apparmor_parser, however, installing this package from the installer fails with a message: "Warning: unable to find a suitable fs in /proc/mounts, is it mounted?"
<roaksoax> any ideas?
<jjohansen> roaksoax: apparmor uses securityfs
<jjohansen> so you need to mount securityfs to be able to load policy
<smartboyhw> mitya57, thank you
<roaksoax> jjohansen:
<roaksoax> jjohansen: right, but obviously during the install we don't do that.. do we?
<smartboyhw> And thank you for the guidance:)
<roaksoax> jjohansen: is there any other package that you know of that does that on install? (uses apparmor_parser)
<jdstrand> roaksoax: anything that ships apparmor policy. cups, mysql, bind, etc
<jdstrand> roaksoax: most use dh_apparmor to run apparmor_parser in postinst
<roaksoax> jdstrand: so I guess a apparmor_parser XYZ || true would solve my issue during install
<roaksoax> jdstrand: so I guess a "apparmor_parser XYZ || true" (adding the || true) would solve my issue during ISO install
<roaksoax> jdstrand: and on reboot, the profile will be loaded?
<jdstrand> roaksoax: that would, yes. what are you adding a profile to?
<roaksoax> jdstrand: maas-dhcp has the apparmor profile, and since it is now being installed on CD install, it was failing due to the lack of the "|| true
<jdstrand> roaksoax: take a look at /var/lib/dpkg/info/tcpdump.postinst and /var/lib/dpkg/info/tcpdump.postrm for what dh_apparmor does
<jdstrand> roaksoax: I might suggest just using dh_apparmor
<roaksoax> jdstrand: will do! thanks!
<slangasek> zyga: hey, any luck with that new mountall?
<zyga> slangasek: hey, I was busy all day with Qt, I'll finish my daily work and try mountall soon
<zyga> slangasek: I wanted to wait till you're around anyway :)
<slangasek> ok
<roaksoax> jdstrand: so does this make sense to you? http://paste.ubuntu.com/6209989/
<doko> pitti, https://launchpadlibrarian.net/152857384/buildlog_ubuntu-saucy-arm64.postgresql-9.1_9.1.9-5_FAILEDTOBUILD.txt.gz   I thought I did update that, could you have a look (out of date config.*)
<jdstrand> roaksoax: without testing it, it does, however, I think that /etc/apaprmor.d/usr.sbin.dhcpd is already shipped by isc-dhcp-server
<roaksoax> jdstrand: yeah it is, we only install something in /etc/apparmor.d/dhcpd.d/maas
<roaksoax> jdstrand: and rerung the dhcpd profile
<roaksoax> so maybe no need to use dh-apparmor
<jdstrand> roaksoax: ah, yes. dh_apparmor is for a full profile, not a profile snippet
<jdstrand> roaksoax: sorry, I didn't realize
<roaksoax> jdstrand: no worries :) thanks though!
<jdstrand> roaksoax: using '|| true' with apparmor_parser is reasonable though-- that is what dh_apparmor does
<roaksoax> jdstrand: yup! that's what I did! thanks
<slangasek> seb128: 1200775> sorry, I don't think we have any spare cycles to work on that right now :/
<seb128> slangasek, :-(
 * seb128 misses mvo
<seb128> speaking of mvo ;-)
<seb128> mvo, hey!
<mvo> hey seb128!
<seb128> mvo, wie gehts?
<mvo> seb128: great, thanks! just optimized a "program" with a student of mine, we got from 37min runtime to 3sec :P and now I relax with some apt merges
<seb128> ahah
<mvo> seb128: and you?
<seb128> mvo, I'm good thanks! things are bit crazy before release, as usual
<mvo> seb128: I vaguely remember that, indeed !
<seb128> mvo, I was trying to see if slangasek had somebody to look at bug #1200775 (update-manager changes that made apturl unhappy)
<ubottu> bug 1200775 in update-manager (Ubuntu) "apturl-gtk crashed with AttributeError in __init__(): 'InstallBackendAptdaemon' object has no attribute 'connect'" [High,Confirmed] https://launchpad.net/bugs/1200775
<mvo> seb128: but it looks very good AFAICT, all my machines run saucy since days
<mvo> (eh, weeks/months depending on the machine)
<mvo> seb128: let me see
<seb128> mvo, but there isn't anyone, which lead me to say "/me misses mvo", just before you joined ;-)
<seb128> mvo, danke
<mvo> seb128: hrm, more tricky than i had hoped, but I make some progress
<seb128> mvo, ;-)
<stgraber> dobey: so is that waste of buildd time really necessary?
<dobey> yes
<wolter> Any software-properties developer here? I am trying to modify add-apt-repository to accept comments but I am running into problems with sys.stdout.detach (file object has no method detach)
<sarnold> wolter: oof, looks like a python2 vs python3 deal: https://wiki.python.org/moin/PortingPythonToPy3k
<wolter> sarnold: sure that was the problem! Thanks. I couldn't test it anyway because the trunk version seems to be very different and incompatible with my current system
<sarnold> wolter: woo :)
<wolter> (I will just upload a branch and have the devs test it if they will.)
<wolter> For enthusiasts, lp:~wolterh/+junk/add-apt-repository-comments
#ubuntu-devel 2013-10-09
<genii> Getting repeated W: Failed to fetch gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_saucy_main_binary-amd64_Packages  Hash Sum mismatch  all today.
 * genii grabs a coffee and heads out again
<infinity> genii: Just tested that it works here.  Broken transparent proxy in the way?
<sarnold> d'oh..
<infinity> Tiiiiming.
<sarnold> infinity: hrm, I just manually downloaded the Release, Release.gpg, and main/binary-amd64/Packages.gz file and I also get hash mis-matches.
<infinity> sarnold: Curious that apt didn't complain at me...
<sarnold> infinity: is there a better way to do this than hand or adding them to apt sources.list? (apt already takes long enough, hehe :)
<infinity> sources.list and apt is the "better way".
<sarnold> darn :) hehe
<infinity> roaksoax: Want to make sure there's a bug subscriber for djorm-ext-pgarray, so I can promote it?
<roaksoax> infinity: argh... i though someone had already subscribed maas-maintainers to it
<roaksoax> let me check
<roaksoax> infinity: it is already
<infinity> Hrm, does that post-date mterry's comment?
<infinity> Possibly.
<infinity> Anyhow, cool.
<infinity> Can you do the same for curtin too, so we don't have to ask later? :)
<roaksoax> infinity: sure
<sarnold> infinity: apt agrees with me: W: Failed to fetch gzip:/var/lib/apt/lists/partial/ddebs.ubuntu.com_dists_saucy_main_binary-amd64_Packages  Hash Sum mismatch
<infinity> sarnold: apt here disagreed with you.  Weird.  Let me try again.
<sarnold> infinity: so hooray / darn :) -- no transparent proxy going on here, at least none that I know of. (comcast might be doing something silly of course but that seems unlikely)
<sarnold> infinity: I -do- have apt-cacher-ng going, but the other 303 sources fetch just fine.
<infinity> http://paste.ubuntu.com/6212028/
<sarnold> infinity: does the public key error mean the hash check won't be performed?
<sarnold> infinity: or would apt report both in that case?
<infinity> No, they should be performed regardless.
<infinity> But I can import the key and try again.
<infinity> sarnold: Huh.  No, you're right.  With the key added, it fails.
<infinity> Oh, because my chroots don't ignore auth failures, so it ignores that entire Release file.
<infinity> Silly me.
<infinity> pitti: ddebs are all hashsum mismatchy, please fiz.
<infinity> pitti: Or fix.
<sarnold> infinity: I'm surprised apt didn't report "E: .." rather than "W: "..
<infinity> Indeed, that should be an E with strict checking, and a W without.
<infinity> Though, at least the behaviour appears to be correct, just not the message.
<sarnold> aha
<sarnold> thanks :)
<pitti> doko_: p-9.1> ah, that needs a dh_autoreconf?
<pitti> infinity: erk, more of that? the ddeb-retriever is stuck anyway, I'll have a look
<infinity> pitti: I'd go to --with autotools-dev for psql, personally, but up to you.
<infinity> s/to/for/
<pitti> infinity: ah, I don't know; if that works, sure
<pitti> it just needs to be backportable all the way to lucid
<pitti> (and squeeze)
<infinity> pitti: lucid?  srsly?
<pitti> yes
<infinity> pitti: Then you might want to fake what dh_autootools-dev_* do and manually find-and-replace all config.{sub,guess} :P
<infinity> Cause the dh commands definitely weren't there in lucid.
<pitti> ack
<infinity> pitti: (Or just ship config.{sub,guess} updates as a patch/diff, but then it doesn't magically work for the next new port)
<pitti> infinity: I'll just ship a patch
<infinity> pitti: Make sure you get 'em all, if there's more than one.
<pitti> 9.3 has a newer config.{guess,sub}, and we'll get that from the next release on
<pitti> just checked, there's just one
<infinity> pitti: 9.3's might not be new enough still, depending on how new newer is.
<infinity> pitti: (ppc64el was added quite recently)
<pitti> timestamp='2013-04-24'
<pitti>     ppc64:Linux:*:*)
<pitti>         echo powerpc64-unknown-linux-gnu
<pitti> that's not enough?
<infinity> Nope.
<infinity> That's big-endian.
<pitti> ok, so I'll update both
<pitti> infinity: is ppc64el something we'll (soon) care about in D/U?
<infinity> pitti: Yep.
<infinity> pitti: Debian for sure, Ubuntu possibly.
<pitti> thanks (some fodder for the changelog)
<infinity> pitti: I've just been using generig changelogs along the lines of "Do blah blah to config.sub" ... "to enable new ports."
<infinity> pitti: Cause, well, if you do it in a fashion that automated at build time (instead of in a patch), it's good for all new ports. :P
<pitti> right, but we automate all the backports, and so everything needs to work on old releases
<infinity> pitti: Sure, you could just manually copy config.foo at build time, as some packages do.
<infinity> slangasek: Why the moutall fakesync instead of a real sync?
<pitti> infinity: well, my suspicion is that new ports will need some manual care anyway, as they need the corresponding asm for fast mutexes
<infinity> slangasek: And with different sources, no less...
 * infinity reuploads with the same source as Debian...
<pitti> infinity: if you are reviewing syncs in the queue, I left some explanations about upower in #u-release
<slangasek> infinity: oh, I suppose that did regenerate the sources; well, the contents were the same, so yeah.  But anyway, how do you do a real sync from incoming?
<infinity> slangasek: I unpack the debian sources, dpkg-genchanges -S > ../foo_source.changes, change the target to saucy, sign the .changes (but not resign the .dsc) and upload.
<infinity> slangasek: Pretty sure syncpackage or something has an option that tries to do that automagically, but I dunno.  I've been doing it manually for 9 years.
<slangasek> infinity: right, that was actually what I meant to do, I just goofed by regenerating the .dsc along the way
<slangasek> but I hear some people still don't consider that a "real" sync :)
<infinity> slangasek: It won't report in the UI and mailing lists quite the same, but if the dsc/diff/orig are byte-identical and retain the original sig, I don't care. :P
 * slangasek nods
<dholbach> good morning
<diwic> pitti, hi
<pitti> hello diwic
<diwic> pitti, hi! It looks like you're the author of dh_modaliases
<pitti> yes, indeed
<diwic> pitti, I have a question about it finding module aliases directly in the .ko file
<diwic> pitti, are there any naming conventions w r t the package name and the .ko file?
<diwic> pitti, or how would dh_modaliases know which .ko files to scan for aliases?
<pitti> diwic: no naming conventions really; it's usually <upstream-source-name>-dkms
<pitti> diwic: it just scans the entire binary package for *.ko files and adds all their modaliases
<pitti> if that doesn't work (like for nvidia, which has completely broken modaliases), you need a manual list
<diwic> pitti, okay, thanks
<diwic> shawnwang, <pitti> diwic: it just scans the entire binary package for *.ko files and adds all their modaliases
<diwic> shawnwang, just trying to understand why you don't think that would work for us?
<diwic> shawnwang, i e I don't think we need to manually generate debian/modaliases
<diwic> shawnwang, dh_modaliases would just do the right thing if it does not find such a file.
<shawnwang> diwic, but if I don't put the modaliases, it won't generate oem-audio-hda-daily-dkms.substvars
<diwic> pitti, ^ do you know how to troubleshoot that?
<shawnwang> diwic, it shows "Can't stat debian/oem-audio-hda-daily-dkms: No such file or directory"
<pitti> addsubstvar() is called in both cases, and both update that map
<pitti> that sounds like you might be calling it too early?
<pitti> i. e. before dh_install etc?
<pitti> of course it can only scan the binary package if it already exists
<diwic> pitti, does it have to be done as part of the dkms build here?
<pitti> if you use dh, then "dh --with modaliases" should DTRT
<pitti> diwic: what do you mean? I thought dkms was used to build the actual *.ko files from the source (which is shipped in the foo-dkms.deb)
<diwic> pitti, sorry, you always have to think twice with the double packaging that comes with autobuilding dkms packages on launchpad
<pitti> yeah
<pitti> if all that your ubuntu source pacakge does is to copy around the source C files, then dh-modalises won't work
<diwic> pitti, ah...you're right
<pitti> you'd need to build it once, scan for the modalises, and stick them into debian/foo.modalises
<pitti> (i. e. the static variant)
<diwic> pitti, yeah, and that's exactly what shawnwang's trying to do
<shawnwang> pitti, add dh_install, It works now.
<diwic> shawnwang, you're right and I'm wrong. We need to do it your way, because we shouldn't ship the .ko files, just the source
<pitti> I believe I once wrote some "debian/rules update-modaliases" stanza for some driver which does that
<diwic> shawnwang, hmm, so we could run dh_install just to make dh_modaliases happy, and then throw away whatever dh_install installs?
<pitti> if only I could remember which one
<shawnwang> diwic, ok, I will do some test about dh_install and dh_modaliases
<pitti> well, if running dh_install installs something which you don't want, you have a bug in your debian/*.instlal files
<pitti> (but that's entirely unrelated to dh_modaliases)
<diwic> shawnwang, ok, thanks. If you don't come to a conclusion I
<diwic> shawnwang, ok, thanks. If you don't come to a conclusion I'll merge it as it is
<shawnwang> diwic, ok... cool
<diwic> pitti, thanks for explaining it to me
<shawnwang> pitti, thank you
<pitti> no worries; sorry, dh_modaliases scanning doesn't really work with dkms
<pitti> if you have an idea how to generalize that, I'm all ears
<pitti> seems in nvidia, bcmwl, etc. we just ship static modalises
<diwic> pitti, dh_modaliases --files-to-scan=path/to/*.ko ?
<pitti> i. e. debian/foo.modaliases
<pitti> but would you actually have *.ko files in a dkms package? all it does is to install a few *.c files from the orig.tar.gz?
<diwic> pitti, that way you could to a test build, call dh_modaliases on that, and then throw away the .ko files
<pitti> ah, for manual operation
<diwic> pitti, the test build could be done as part of the build even if it is thrown away
<diwic> pitti, it is a good test case, to see if your c files actually compile, too :-)
<pitti> diwic: indeed; if you debian/rules calls dkms build into a tmpdir
<dholbach> can somebody from the release team have a look at 1235737?
<seb128> dholbach, try #ubuntu-release and bonus point if you use "bug <nnn>" so the bot gets the title and url ;-)
<dholbach> hey seb128 :)
<seb128> dholbach, hey ;-)
<seb128> hum, did anyone got a conffile prompt when upgrading evince?
<dholbach> seb128, not me
<pitti> I upgraded this morning, no conffile prompts
<pitti> (nor did I get any in the past few weeks)
<Laney> same
<Laney> what was the diff?
<pitti> doko_, infinity: postgresql-9.1 updated; I'll do the sid upload/saucy sync tomorrow, then 9.1.10 will get announced upstream
<pitti> (bug 1237248)
<ubottu> bug 1237248 in postgresql-9.1 (Ubuntu Raring) "New upstream microreleases 9.1.10, 8.4.18" [Undecided,New] https://launchpad.net/bugs/1237248
<pitti> (the sid upload contains the config.* update)
<seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1237281
<ubottu> Ubuntu bug 1237281 in evince (Ubuntu) "usr.bin.evince conffile diff prompt on upgrade" [Undecided,New]
<Laney> seb128: that flags=complain stuff wasn't in the distro package
<seb128> Laney, I probably used aa-complain usr.bin.evince at some point I guess
<seb128> I never edited that file manually though
<Laney> how can dpkg tell that?
<Laney> a tool editing is still editing
<seb128> well, we should provide tools that create conffile diffs
<seb128> or those files shouldn't be conffiles
<seb128> Laney, but thanks for pointing that out, I had forgotten about the aa-complain
<seb128> but I guess that's due to it
<seb128> we *shouldn't* provide tools...
<seb128> (rather)
<Laney> I think people who know enough to muck about with apparmor profiles like that can handle the prompt
<seb128> Laney, ok, fair enough, thanks for the hint, as said I had no idea I ever touched that config
<Laney> sure, np
<Laney> :-)
<seb128> Laney, I guess my issue is https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/117852
<ubottu> Ubuntu bug 117852 in apparmor (Ubuntu) "Conflict in profiles in complain mode when upgrading apparmor-profiles" [Wishlist,Won't fix]
<Laney> sounds like it
<Laney> old bug!
<seb128> yeah
<seb128> so it seems like I had my profile in complain mode for ages, I didn't know
<Laney> i guess it's likely not updated very often
<seb128> I tried to turn it off once to test a bug and to see if it was an apparmor thing
<seb128> I probably screwed up and did a config change
 * seb128 has not a lot of clue about apparmor
<Noskcaj> pitti, Do we want symbols for pygobject or is there a reason they've not been generated?
<infinity> pitti: How fresh are our langpacks?  Do we need another export for release?
<pitti> infinity: I think we do; we advertise LanguagePackTranslationDeadline for Oct 10, so I guess we should build fresh ones on Oct 11
<pitti> Noskcaj: we do want them; they should be in python{,3}-gobject-dbg
<pitti> Noskcaj: err, python{,-3}-gi-dbbg
<FourDollars> pitti: Do you have any plan to patch or backport upower to Ubuntu 12.04,12.10,13.04?
<Noskcaj> pitti, ok. I've just made some of the ones for the standard package, i'll finish them tomorrow
<pitti> FourDollars: not from my side; there are some quite intrusive patches in there
<pitti> FourDollars: if someone wants to backport individual fixes, I'm happy to assist/review, though
<FourDollars> pitti: I see.
<FourDollars> pitti: Actually I have https://code.launchpad.net/~fourdollars/ubuntu/precise/upower/fix-lp-bug-1153488 that needs someone to review it. Could you help me?
<pitti> FourDollars: we definitively don't need stuff like 05-stop-calling-deprecated-g_type_init.patch in SRUs
<pitti> FourDollars: and we need Launchpad bugs (with SRU information) for all changes
<infinity> pitti: Alright, can you make sure that happens, so I can not care about chasing it up? :)
<pitti> infinity: yes, that's on my TODO list
<FourDollars> pitti: I will cherrypick it is because without it there will be some merge conflict.
<infinity> pitti: My hero.
<FourDollars> pitti: OK. I will go to see what information I should add on it.
<pitti> infinity: according to https://translations.launchpad.net/ubuntu/saucy/+language-packs we ought to get a fresh -base export on Oct 10 or 11 now, so that'll fit
<pitti> FourDollars: not sure whether the locale fixes are important enough for SRU; they are not "obviously safe" and don't fix critical bugs, so TBH I'd rather leave them out
<pitti> i. e. if it suddenly starts exposing UTF-8 names to clients, these might crash in turn as they haven't seen/expected non-ASCII data so far
<FourDollars> pitti: I thought there are all relative to that bug.
<pitti> FourDollars: likewise, I'd treat detection of bluetooth input devices as a new feature, not truly a major bug in precise (but if you want/need that for some OEM stuff, it's probably ok)
<pitti> but only for precise, not for non-LTS
<FourDollars> pitti: OEM reports lots of Bluetooth device issues. That is why I am working on it.
<xnox> FourDollars: usually one has multiple issues fixed in a single upload, hence multiple entries/comments in the changelog, multiple patches etc. For SRU, one has to decide which is the _least_ amount of changes that need to be cherrypicked to solve a particular bug in a stable release.
<FourDollars> xnox: Regarding to Bug 1153488, there are some Bluetooth keyboards not showing in the power indicator, or there is some Bluetooth mouses showing in the power indicator but with the wrong type.
<ubottu> bug 1153488 in upower (Ubuntu Precise) "Treats bluetooth input device batteries as batteries" [Undecided,New] https://launchpad.net/bugs/1153488
<FourDollars> xnox: The merge proposal I provided is to correct the type and the name of Bluetooth devices.
<lool> pitti: So
<lool> pitti: we use this ubuntu-unity/daily-build PPA to stage CI-ed touch uploads
<lool> pitti: these get copied to -proposed once they pass automatic or currently manual testing
<pitti> lool: packages can ship a hook which either always redirects bug reports to an LP project, or only if the package isn't an Ubuntu one (so that you can share the hook with Ubunut)
<lool> pitti: when we test these, we're getting crash files but apport wont let us them send them to launchpad because binaries come from PPA
<xnox> FourDollars: no, you made a merge proposal that copies all changes from the upload that happens to fix the bug you care about. But it also has 3 or 4 other unrelated patches.
<FourDollars> xnox: So I think that is the least amount of changes I need.
<xnox> FourDollars: no, it is not.
<pitti> lool: unity already does that (/usr/share/apport/package-hookssource_unity.py)
<pitti> lool:
<pitti>     if not apport.packaging.is_distro_package(report['Package'].split()[0]):
<pitti>         report['CrashDB'] = 'unity'
<FourDollars> xnox: So I need to open other bug report. Right?
<xnox> FourDollars: no, you need less changes in your merge proposal.
<lool> pitti: so it's not my archive
<lool> pitti: problem is we'd need to drop the hook when copying to distro
<seb128> no you don't
<pitti> lool: why?
<seb128> apport.packaging.is_distro_package
<lool> pitti: so perhaps we can test for PPA build in CurrentlyBUilding and set the hook when it's PPA
<pitti> lool: that's what the first line does
<xnox> FourDollars: please modify the bug report description with test case, how to reproduce the original bug and verify that the proposed branch fixes it. I've asked you to do that before.
<pitti> lool: i. e. "redirect to project ONLY if it is not an ubuntu packag
<lool> pitti: well what if you have other PPA enabled and you get that hook?
<xnox> FourDollars: at the point you can see that e.g. dropping extra patches still resolves the bug you care about.
<lool> pitti: I dont want to get reports from people with random PPAs
<FourDollars> xnox: I see.
<lool> pitti: that's why I wanted a cmdline flag to override W
<lool> TW
<pitti> lool: ah, then you can check the origin flag in the Package field
<lool> *BTW*
<xnox> FourDollars: Remember our conversation when I pointed you to: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ?
<pitti> lool: no, no, no
<FourDollars> xnox: Yes.
<lool> pitti: even if it's very secret
<lool> pitti: or let's protect it by cryptography
<lool> or we hide it with steganography in the source
<pitti> lool: you can always vi the .crash report and re-send it through ubuntu-bug
<pitti> (and drop UnreportableReason)
<lool> if you have this combination of newlines in your email email address, it can be sent
<pitti> so there's already a way
<lool> pitti: ah perfect
<lool> pitti: thanks!
<pitti> but it shouldn't be an officially blessed CLI
<lool> technical means, social abuses
<pitti> lool: but as I said, you can also do stuff in the hook like "if Package field contains "[origin: PPA-unity-daily-build" then send it to LP
<pitti> to match your use case
<pitti> lool: look at your Package field, what does it say?
<lool> pitti: sorry dont have one handy
<lool> pitti: will check when I have one
<lool> pitti: this is for a class of packages rather than one specific one
<pitti> lool: if we limit the match to that specific PPA, we can also add that logic to /usr/share/apport/general-hooks/ubuntu.py
<pitti> lool: i. e. "anything from that PPA", or matching by name/regexp etc.
<lool> pitti: ok
<ritz> hi , does upstart emit event for suspend/resume ?
<xnox> ritz: yes.
<ritz> xnox thanks, I am unable to see this in cook book, from a quick grep http://upstart.ubuntu.com/cookbook/
<FourDollars> xnox: pitti: I have updated the description of https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1153488 .
<ubottu> Ubuntu bug 1153488 in upower (Ubuntu Precise) "Treats bluetooth input device batteries as batteries" [Undecided,New]
<xnox> ritz: actually looking at $ man 7 upstart-events
<xnox> ritz: I don't see it.
<ritz> aah
<ritz> thanks
<xnox> ritz: why would you want a suspend/resume events anyway? =)
<xnox> ritz: everything should get back as it is.
<ritz> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1184262
<ubottu> Ubuntu bug 1184262 in network-manager (Ubuntu) "network-manager has decided that networking is disabled, cannot be re-enabled from lightdm" [High,Confirmed]
<pitti> FourDollars: you'll need a separate for the unicode ones (or drop these patches), and drop teh g_type_init() one (as that's really not releavant for SRU)
<ritz> xnox quick hackish workaround
<FourDollars> pitti: OK.
<xnox> ritz: right, so pm-utils package has direcotries with scripts that are executed on suspend/resume, hibernate/thaw.
<ritz> aah
<ritz> thanks
<xnox> ritz: so network-manager or user should just add scripts there.
<xnox> ritz: see /usr/share/doc/pm-utils/README and /usr/share/doc/pm-utils/HOWTO.hooks.gz and etc.
<xnox> ritz: you can ship things in /usr/lib/pm-utils/sleep.d/ (for packages) or in /etc/pm/sleep.d (for administrator).
<xnox>  I think.
<xnox> ritz: yeap, see $ man 8 pm-suspend.
<ritz> xnox++  thanks
<FourDollars> pitti: I opened https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1237329 and I am going to revise my merge proposal.
<ubottu> Ubuntu bug 1237329 in upower (Ubuntu) "Apple Wireless Keyboard/Mouse are not listed as its original name. It stripped non-ascii characters (UTF-8 valid)." [Undecided,New]
<xnox> FourDollars: right i see, then you can have multiple bugs in the SRU, but then the whole SRU will wait on all bugs to be verified before it gets accepted.
<xnox> FourDollars: so i guess that bug is for the utf-8 patch?
<FourDollars> xnox: yes.
<xnox> FourDollars: cool.
<FourDollars> xnox: pitti: https://code.launchpad.net/~fourdollars/ubuntu/precise/upower/fix-bluetooth-1153488-1237329/+merge/190086
<doko> seb128, could you forward the two unity-* ftbfs to somebody? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130917-saucy.html
<FourDollars> xnox: pitti: Is there anything needed to improve?
<doko> these still ftbfs, all others did succeed when given back
<seb128> sil2100, Mirv: ^ unity-lens-music and unity-scope-github ftbfsing is known?
<seb128> doko, ^
<sil2100> seb128, doko: looking, but 17 hours ago the unity stack built fine, hm
<pitti> FourDollars: looks fine now, thanks; I adjusted the tasks for the new bug
<FourDollars> pitti: Thank you.
<seb128> sil2100, those are rebuilt of what is currently in saucy, not from trunk
<seb128> sil2100, we didn't get an upload of unity-lens-music since 2013-06-21 ... is that normal?
<seb128> sil2100, https://launchpad.net/ubuntu/+source/unity-lens-music
<Mirv> there haven't been commits to trunk since June
<seb128> Mirv, weird that the daily build is working then? or is it not rebuilding if there are no change?
<Mirv> seb128: exactly, it only rebuilds if there's a change
<seb128> Mirv, so I guess it's why there is no issue in the stack
<doko> Mirv, I'm retrying now, but I already did on Oct 1
<doko> Mirv, unity-scope-github still ftbfs
<seb128> doko, the music lens one is being worked on, should be fixed today
<doko> seb128, do you want to care about gtk2-engines and gmime?
<seb128> doko, not especially, I've already and endless todo
<seb128> doko, the unity-lens-music issue has been fixed in their trunk, now we just need a landing of the unity stack to happen
<doko> seb128, thanks!
<seb128> yw
<OrokuSaki> Hi! When I run surface flinger, I get a screen, but I get a EGL_BAD_CONTEXT when running unity8. My screen initializes, but my OpenGL Renderer does not. My device is an HP Touchpad.. and its using a custom graphics.c, do you think the graphics.c could be the an issue?
<OrokuSaki> So I cannot watch 720p or 1080p videos...
<OrokuSaki> And since an update to the mediaservice.. I cannot watch 480p
<OrokuSaki> When I switch to Mir, I get an error that seems to be related to the graphics.c
<OrokuSaki> I do not develop, so I can't argue. =)
<OrokuSaki> still playing with udev rules
<OrokuSaki> Lastly, I would like to try cm-10.2 sources.. but.. I guess there is no way to switch Ubuntu Touch to 10.2?
<xnox> OrokuSaki: i think you want #ubuntu-touch channel.
<PaowZ_> Hi there ! I'm trying to control the way udev populates /dev for a special device. I mean, I have a barcode reader which appears as a HID appliance in /dev. The thing is an event handler is attached to this device and every inputs are seen as keyboard inputs which, of course, I don't want..
<PaowZ_> any clue ??
<xnox> PaowZ_: barcode readers are usually, simply keyboards.
<xnox> PaowZ_: you scan a barcode yet, it acts as a keyboard that simply "types out" the barcode's digits/numbers.
<PaowZ_> xnox: Indeed, this is what I noticed. But this behavior doesn't suit me..
<PaowZ_> I need to "mute" barcode redirection towards text fields..
<PaowZ_> I can already get a file descripteur on /dev/hidraw* to read barcode inputs, but I don't need the content to be typed into any text field..
<jdstrand> hallyn: hey, I only just now noticed bug #1227937 needed a response from me. I've done that though I doubt I am much help. I think stgraber needs to get involved
<ubottu> bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,New] https://launchpad.net/bugs/1227937
<jdstrand> hallyn: please see my comment though (comment #2)
<hallyn> doesn't ring a bell, checking
<hallyn> jdstrand: i don't understand.  if the lxc-container-default poilcy is defined, then it's defined...  if the container could enter it, it's defined.  no?
<hallyn> hm, screen is wonky.  one sec
<hallyn> jdstrand: does the ubuntu touch install run a normal upstart setup at boot, and normal lxc packages?  who is starting that container, and when/how?
<xnox> hallyn: see lxc-android-config package.
<xnox> hallyn: there is an upstart job, which well in the end does "lxc-start -n android"
<xnox> hallyn: so it's started as root.
<xnox> jdstrand: maybe /etc/init/lxc-android-config.conf need to specify with apparmor profile to use?
<hallyn> xnox: jdstrand: yeah that's a but in lxc-android-config
<hallyn> it needs to wait started lxc
<hallyn> /etc/init/lxc.conf is the one which loads the apparmor profiles
<hallyn> i'll comment in the bug - thanks guys
<xnox> ogra_: ^ looks like we will be starting android lxc container later in the boot process.
<xnox> ogra_: unless we override lxc start on condition.
<ogra_> xnox, we cant really
<ogra_> we dont use the normal lxc jobs at all i think
<hallyn> then you can manually load the profiles as the lxc.conf does
<xnox> ogra_: right, then we should load the apparmor profiles.
<hallyn> or we could create an lxc-apparmor upstart jbo which does the loading, which everyoen can wait on
<hallyn> but it's too late probably to get that into saucy
<hallyn> it's the nicest way to handle it long term
<ogra_> i thought we had our special apparmor handling since months
<ogra_> please talk to jdstrand, i know he added some stuff for our container a while ago
<xnox> ogra_: jdstrand is the one saying there is lxc-start running un-confined. with or without special profiles, if we don't load it, we don't get it =/
<xnox> (unless i don't understand bug #12279)
<ubottu> bug 12279 in gnome-control-center (Ubuntu) "no way to emulate a 3 button mouse?" [Low,Fix released] https://launchpad.net/bugs/12279
<xnox> (unless i don't understand bug #1227937)
<ubottu> bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,Confirmed] https://launchpad.net/bugs/1227937
<ogra_> xnox, well, whatever is set up atm, was planned to be kept for this version
<ogra_> afaik
<jdstrand> actually, I have never touched the lxc/apparmor configuration on touch
<jdstrand> honestly, I know little about it
<pitti> linux-signed-image-3.11.0-12-generic (3.11.0-12.18) wird eingerichtet ...
<pitti> warning: file-aligned section .text extends beyond end of file
<pitti> warning: checksum areas are greater than image size. Invalid section table?
<ogra_> jdstrand, hmm, who did that then, mdeslaur ?
<pitti> apw, xnox ^ just cosmetical, or something to worry about?
<jdstrand> I filed that bug last month cause I noticed the profile was loaded but the process unconfined
<ogra_> jdstrand, right,, and iirc on purpose
<jdstrand> I have made changes to the system writable paths for apparmor in lxc-android-config
<ogra_> because there was no way to fix it at that time
<xnox> pitti: i think that's ok, let me upgrade my laptop and let you know.
<jdstrand> ogra_: no one responded in the bug that it was intentional
<ogra_> jdstrand, i dont remember who did that change anymore ... and i didnt know about that bug at all
<jdstrand> ogra_: but vila today saw a denial that I thought was because the profile was actually in effect
<jdstrand> he saw it in ci, but on intel of all things, so I don't really know what is going on
<hallyn> jdstrand: no one would respond in that bug bc it was against lxc, and noone at lxc knows about that assumption...
<jdstrand> maybe that is an unrelated bug that should be filed
<xnox> jdstrand: well if lxc-android-config is stopped, and started, the second invocation will be now confined as the lxc-start profile is loaded.
<hallyn> if you want it to be unconfined, then is lxc.aa_profile set to unconfined in the container config?
<xnox> jdstrand: as by that time lxc job has run and loaded the profile.
<ogra_> xnox, ugh
<hallyn> but just hoping that you run before lxc.conf runs, yeah that's racy
<stgraber> xnox: the LXC container for Ubuntu touch runs with lxc.aa_profile=unconfined
<ogra_> xnox, lxc-android-config is not designed to ever be stopped ...
<jdstrand> xnox: sure. I filed the bug cause I saw what seemed like a race condition-- it is quite unusual (and dangerous) to have a profile that is loaded but not applied to the process because of what you just described. you end up with all kinds of weird bugs
<ogra_> xnox, your devices would vanish underneath you
<hallyn> stgraber: have you seen bug 1227937 happen?
<ubottu> bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,Confirmed] https://launchpad.net/bugs/1227937
<jdstrand> either don't apply the policy at all, or fix it so it is always applied
<xnox> ogra_: oh, i see.
<vila> jdstrand: does that mean my issue is completely different and I should investigate further while you discuss yours ?
<jdstrand> ogra_: right, that is what I was afraid of, so I didn't try to stop the container :)
<ogra_> yeah, dont :)
<stgraber> hallyn: I didn't see that bug but I don't know why we care since we explicity set the container as lxc.aa_profile = unconfined to begin with
<ogra_> we only stop it  on shutdown
<jdstrand> vila: your issue is definitely different. the lxc policy needs some missing rules
<hallyn> stgraber: that wasn't clear to me until just now
<jdstrand> vila: but your issue was possibly never seen because of the issue we're discussing
<vila> jdstrand: haaaa, now we're talking business ;) So the change Mirv pointed you at may have uncover "my" issue ?
<jdstrand> vila: well, there was in the uploads yetsterday that should have caused that
<jdstrand> was nothing*
<jdstrand> vila: you should have been seeing that issue all along (dbus mediation has been in effect since august)
<xnox> pitti: mostly harmless
<hallyn> vila: ok i'll wait for more info from you in the bug
<jdstrand> vila: I should clarify-- nothing in the apparmor related uploads
<stgraber> jdstrand: so I agree we've got a race there but the race shouldn't matter since the container runs unconfined anyway
<pitti> xnox: ack, thanks
<jdstrand> stgraber: ok, can you comment on that in the bug?
<vila> hallyn: meh, I'm confused, are you saying I should use that bug to track my issue ?
<jdstrand> vila: can you file a new bug with your denial?
<hallyn> uh, or, if you don't want to, mark it invalid
<vila> jdstrand: will do
<hallyn> vila: ok, nm :)
<jdstrand> stgraber: perhaps you can look at vila's bug when he files it? there is a system bus apparmor denial when lxc-container-default is in effect
<vila> hallyn: I'll file a new bug once I have a better idea on what is going on (it may well be that the problem is elsewhere)
<hallyn> jdstrand: so shall i mark bug 1227937 invalid?
<ubottu> bug 1227937 in lxc (Ubuntu) "lxc-start is unconfined but has a profile defined" [High,Confirmed] https://launchpad.net/bugs/1227937
 * hallyn confused
<jdstrand> hallyn: I'm not sure it is invalid-- I think it is not high priority. eg, what would happen if lxc-start did have its profile in effect sometime in the future when it did matter?
<vila> jdstrand: what's lxc-container-default ?
<hallyn> jdstrand: if you have lxc.aa_profile = unconfined, then nothing would change
<jdstrand> I don't know-- how all the lxc apparmor containers work together
<hallyn> jdstrand: lxc-start will see that it is unconfined, and do nothing.
<jdstrand> hallyn: yes, what I am saying is if someone did 'lxc.aa_profile = somethingelse'
<hallyn> jdstrand: if it becomes confined, then it will switch the profiles.  (so, if kernel relabels it, as it should)
<jdstrand> hallyn: all of a sudden this bug is potentially important
<hallyn> jdstrand: then the caller had a bug for not waitint on lxc
<hallyn> but it's not a bug
<hallyn> it's a mis-use
<hallyn> the only inconvenience is that aa gets loaded later bc it's tied in with setting up networking
<stgraber> jdstrand: then lxc-android-config should wait for lxc to finish, but that's not currently required and would possibly slow down the boot process on the phon
<jdstrand> hallyn: so the fact the lxc-start has a profile defined for enforce mode, but starts before that is in effect is not a bug? how is that possible?
<jdstrand> it is a bug waiting to bite someone
<hallyn> stgraber: for s+1 I think we should split up lxc.conf to have a separate loading of aa policy earlier than lxc-net runs
<stgraber> lxc-start should fail if the profile isn't ready for use
<jdstrand> note, I'm not saying it is important for saucy for the reasons mentioned. I am only saying I don't think the bug is invalid
<jdstrand> (and perhaps the bug isn't against lxc)
<hallyn> hm.
<hallyn> from ubuntu pov you're right.  but upstream lxc can't say "if no profile don't run"
<stgraber> root@castiana:~# lxc-start -n tpl-saucy-amd64 -s lxc.aa_profile=blah
<stgraber> lxc-start: Permission denied - failed to change apparmor profile to blah
<stgraber> so the upstream behaviour is already correct
<hallyn> then ubuntu behavior should also be correct
<stgraber> (ENOPERM is a bit odd though ;))
<jdstrand> stgraber: can you answer vila's question about lxc-container-default?
<jdstrand> (or hallyn)
<hallyn> thoug i'm quite certain there is going to be a race in there depending on exactly when the running lxc-start gets re-labeled
<stgraber> vila: that's the apparmor profile applied to a standard container on Ubuntu which prevents the container from causing harm to the host
<vila> jdstrand: found it, it's in apparmor, I thought it may have been the default config since otto (my main suspect here doesn't use the default lxc config)
<vila> stgraber: thanks
<jdstrand> vila: well, it is an apparmor profile, yes (I didn't know that was your question). however the package that ships that policy is lxc (ie, lxc may need to be updated to address your apparmor denial)
<stgraber> jdstrand: so is your dbus stuff allowed by default in apparmor or does any confined job now has to allow it?
 * stgraber tries dbus in a saucy container
<vila> jdstrand: yeah, thanks, that's where I found it (searching lxc for all installed files)
<jdstrand> vila: and what I didn't know is that policy is in effect and how
<vila> jdstrand: but I still don't know what is denied, the only apparent symptom in the end is that we can't start the X server
<hallyn> probably dbus
<hallyn> grumble :)
<jdstrand> stgraber: any confined process needs to have dbus rules if it uses dbus. the apparmor dbus abstractions allow wide access
<jdstrand> stgraber: eg: cat /etc/apaprmor.d/abstraction/dbus
<jdstrand>   /{,var/}run/dbus/system_bus_socket rw,
<jdstrand>   dbus bus=system,
<stgraber> jdstrand: that's going to suck for LXC...
<jdstrand> stgraber: so if you don't want fine-grained access, just add #include <abstractions/dbus> to the profile
<stgraber> jdstrand: because we do verbatim backport down to precise
<jdstrand> stgraber: the dbus abstraction exists on precise
<jdstrand> stgraber: as does dbus-session
<jdstrand> stgraber: so you can safely add those to the profile and it will all work
<jdstrand> the only potential gotcha is that saucy introduced the dbus-accessibility abstraction which doesn't exist on precise
<jdstrand> but if you don't need it, don't add it to the lxc apparmor policy
<stgraber> jdstrand: we need any dbus traffic alloewd by default as we have no clue what our users may do in their container
<stgraber> since dbus isn't considered harmful for ths host, it should just be alloewd in there...
<stgraber> jdstrand: so it sounds like we want just "dbus," added to the policy, but I guess that'll only work on saucy and higher, right?
<jdstrand> stgraber: then I suggest on saucy and higher you use 'dbus,' in the profile and omit that in raring and lower
<jdstrand> stgraber: yes
<stgraber> ok, time for some debhelper magic then
<stgraber> jdstrand: and will that also blow up in our users' face if they run saucy on an older kernel?
<jdstrand> we've had to deal with that in firefox for some time
<jdstrand> saucy userspace on an old kernel is fine
<stgraber> cool
<jdstrand> the problem is new policy on old userspace
<jtaylor> is it too late to revert vim back to 7.3? :/
<jtaylor> its new "faster" regexp engine is attrociously slow for the common use case of syntax highlighting
<jtaylor> its basically unusable
<jtaylor> in saucy
<pitti> jtaylor: oh? I'm using vim all the time for everything, haven't noticed yet
<pitti> jtaylor: what kind of files do you see this on?
<jtaylor> pitti: are you using easytag?
<pitti> no
<pitti> jtaylor: well, I use the application for changing music tags, but I guess that's not what you mean
<jtaylor> not that one :)
<jtaylor> vim-easytag allows to use ctags data for highlighting
<jtaylor> very useful, but with 40k tags and vim 7.4 you now have 0.5s lag on scrolling and permantently 100% cpu uage of vim :/
<jtaylor> and 40k tags is not much
<jtaylor> mh debians slightly newer vim version is crap too
<jtaylor> I'll check with upstream, but looking at the new engine its probably not easy to fix ...
<Laney> get it filed and we can SRU when possible
<Laney> final freeze is tomorrow, reverting probably wouldn't be so wise
<cjwatson> I haven't found current vim in saucy to be unusable at all and I use it (with syntax highlighting) all the time
<Laney> Me neither, but I don't use easytag
<cjwatson> but indeed not with easytag
<jtaylor> how do you get highlighting of function names?
<cjwatson> sounds like a good candidate for a release note though
<cjwatson> I don't find I need highlighting of function names ...
<jtaylor> easytag uses a vim regex with lots of |, which seems to be the cause of the slowness
<jtaylor> each | pattern causes lots of copies and page faults
<psusi> is anyone able to merge my fix for bug #1237169 before the final freeze?  it's a fairly simple cherry picked upstream commit
<ubottu> bug 1237169 in Sound Juicer "CD Drive widget does not show selected drive" [Medium,New] https://launchpad.net/bugs/1237169
<xnox> slangasek: so upstart-socket-bridge doesn't seem to work as I thought. Whilst "start on socket" causes the socket to be created, the UPSTART_FDS is not set, when doing "start myjob". Ideally, i'd like the job to be instantly started, and not wait for something to connect.
<dobey> is there a way to see who accepted an upload to the archive? the reject e-mail says who rejected, but accept e-mails don't say who accepted
<xnox> dobey: no. I don't think so, you can ask in #ubuntu-release.
<mdeslaur> psusi: sure, one sec
<xnox> dobey: is it actually anything recent, or just binary accept?
<dobey> xnox: it's recent as in uploads i made yesterday afternoon
<crass> not sure if this should be in app-devel, but doing "backportpackage -s saucy -w openvpn openvpn" is dying on an exception... could anyone help with this?
<mdeslaur> psusi: looks good, building now and will upload it in a few minutes
<psusi> mdeslaur: thanks
<mdeslaur> psusi: uploaded
<slangasek> xnox: well, I refer you to the DebConf discussions about the socket bridge API :)
<xnox> slangasek: hm... please remind me. I had a couple.
 * xnox ponders to disable console service in android container.
<slangasek> xnox: oh, just that the upstart way is incompatible with systemd and not useful in current form :)
<xnox> slangasek: gotch.
<xnox> slangasek: i'm always thinking to do on file event /dev/socket/qemud, socat /dev/socket/qemud to get it emitted =)
<xnox> s/always/almost/
<doko> pitti, would you mind enabling a verbose build for systemd?
<vila> hallyn, stgraber: -C option for lxc-ubuntu-cloud is gone in saucy ? Sucks for me :-(
<vila> hallyn, stgraber: hmm, may be not, surely not even, but it's not recognized by lxc-create anymore, what's the new trick to provide userdata to a container ?
<hallyn> vila: make sure you pass it after '--'
<smoser> vila, its better now!
<hallyn> the option is for the template, not for lxc-create
<smoser> http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html
<smoser> but it should be passable to create also
<smoser> actually.
<smoser> should be backwards compat
<hallyn> smoser: I think vila is doing 'lxc-create -t ubuntu-cloud -C' instead of '-- -C'
<vila> yeah
<smoser> did that work previously?
<vila> yes
<smoser> no.
<smoser> really?
<vila> I was doing: sudo lxc-create -n lxc-precise-server-pristine -t ubuntu-cloud -- -r precise -a amd64 -C
<vila> on raring for sure and probably early days of saucy
<smoser> and that does not work now ?
<hallyn> that should work.  it's still in the code
<smoser> i intended to make that work
<vila> smoser: nope, and the error message is cryptic: lxc-create: container creation template for lxc-precise-server-pristine failed
<vila> hallyn: can't find it anymore in lxc-ubuntu-cloud
<hallyn> vila: it's done through the hook now
<hallyn> vila: saucy?
<vila> hallyn: but looking at the sources... it may be via ubuntu-clloud-prep also I don't know the syntax... yeah
<vila> so, how does that work ?
<vila> hallyn: yes saucy
<hallyn> pixe dust
<vila> hallyn: if that was an answer, it went way above my head ;)
<vila> hallyn: oh ! pixie dust as in Peter Pan ?
<hallyn> right.  smoser is peter pan.
<hallyn> ok so i'm on the ubuntu-lxc ppa, but lemme try that command
<smoser> $ lxc
<smoser> The program 'lxc' is currently not installed.  You can install it by typing:
<smoser> sudo apt-get install lxc
<hallyn> vila: oh, you might have the bug i introduced (bad untar option)
<hallyn> but no, i'm seeing the same thing without that bad code
<vila> fresh saucy updated hmm, already ~11 hours ago damn, what a day
<vila> hold on, the option is still in the script, something else is wrong indeed (too long day, probably looked in the bad place),
<vila> anyway, if I don't use the option lxc-create succeed so there is still an issue when using it
<smoser> vila, hallyn
<smoser> http://paste.ubuntu.com/6214719/
<smoser> bugger
<vila> ha, running with -d (and adding -x in ubuntu-cloud-prep) I get: well, smoser beat me to it and probably knows what the issue is
<sarnold> my kingdom, my kingdom, my kingdom for a ' 0'.
<smoser> yeah.
<smoser> vila, i'm wondering, though, why do you use -C ?
<vila> smoser: works far better with that ;)
<vila> smoser: because I customize the lxc by parameterizing cloud-init
<vila> smoser: so after the lxc-create, I mount some userdata for lxc-start
<smoser> ah. i see. well, now we have clone hooks for that.
<smoser> and it does just what you want.
<vila> smoser: i.e. mount some userdata ?
<smoser> yeah.
<smoser> reaad my blog post.
<smoser> create a source, clone with '--userdata', start.
<vila> AAAAAARGH
<vila> I'm even subscribed to that blog but that .... reader marked the article as read !
<smoser> the clone hooks are really neat.
<smoser> they were added exactly to do what i think you're doing.
<hallyn> smoser: are you sending a patch or should I just push it?
<vila> hallyn: push it, I tested it and morally approve it ;)
<hallyn> vila: yeah i'm only asking for credit reasons :)
<smoser> hallyn, typing bug.
<smoser> you can do the patch/fix if you want
<hallyn> ok, i'll just push it without an email to the list then.  ths
<hallyn> thx
<smoser> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1237543
<ubottu> Ubuntu bug 1237543 in lxc (Ubuntu) "lxc-create (or clone) of cloud template with '--cloud' exits failure" [Undecided,New]
<vila> will that land in time for saucy or should I carry that fix ?
<smoser> i think it will land. relase team will ack it
<vila> cool
<vila> just reading ubuntu-cloud-prep a bit slower, indeed, just provide the *file* and boom ! no need to juggle with mount myself, great
<vila> smoser: I should send you my code ;) I was handling a cache for kvm, no need for lxc ! Already provided ! I was mounting /var/lib/cloud/seed/nocloud-net, not needed anymore !
<vila> thanks guy, you made my evening ;) Will EOD in peace now
<smoser> handling a cache for kvm ?
<smoser> vila,
<vila> smoser: for the images
<smoser> ah. so 'uvtool' is rbasak's work on that
<smoser> iuvtool goal is magic just like lxc-create. we're working on it.
 * hallyn adjusts the tablecloth strategically keeping vmbuilder out of sight...
<hallyn> all right, lunch.  bbl
<vila> smoser: good to know will track that
<stgraber> hallyn: we uploaded lxc at the same time with a different change :) I just rejected both our uploads and I'm doing one with both changes now.
<vila> hallyn: but... I was told vmbuilder was dead so I build a... simple thing around cloud-init as I care only about ubuntu
<hallyn> stgraber: cool, thanks :)
<hallyn> vila: yes.  +1
<vila> hallyn: ha, pfew, you scared me
<brainwash> it looks like the updata-manager does not support restarting via logind yet -> bug 1232363
<ubottu> bug 1232363 in update-manager (Ubuntu) "Update Manager Restart button fails on xubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1232363
<slangasek> sabdfl: quorum> lol
<slangasek> xnox: bug #1237556 looks like a regression from your cryptsetup change
<ubottu> bug 1237556 in cryptsetup (Ubuntu) "cryptsetup removed from initrd.img on upgrade to 13.10" [Undecided,New] https://launchpad.net/bugs/1237556
<slangasek> xnox: seems that cryptsetup isn't being completely excised from the initramfs?
<brainwash> slangasek: hey, got a minute or so to take a look at update-manager and add support for restarting via logind? bug 1232363
<ubottu> bug 1232363 in update-manager (Ubuntu) "Update Manager Restart button fails on xubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1232363
<slangasek> brainwash: by "add support" do you mean "write support", or "apply a patch"? I don't see any patches linked from that bug
<brainwash> slangasek: I assume it's basically copy and pasting the consolekit definition and changing the dbus call, like http://lpaste.net/94086
<slangasek> brainwash: well, I have no idea; if you have a patch that's been tested, confirmed to fix xubuntu, and not regress ubuntu, I'd be happy to sponsor it
<slangasek> but whereas sponsoring only takes a minute, I don't have the time to develop / test the fix
<brainwash> slangasek: ok, we'll test it and report back, thanks :)
<sarnold> is there a better person to poke for broken us-east-1 ec2 broken package repository than IS RT?
<slangasek> zyga: haven't heard from you in a bit; did the new mountall turn your machine into a kumquat?
#ubuntu-devel 2013-10-10
<pitti> Good morning
<pitti> doko_: verbose systemd build> can do
<pitti> infinity: err, how is https://launchpad.net/ubuntu/+source/libgphoto2/2.5.2-0ubuntu5/+build/4964722 a "failed to build"?
<pitti> infinity: the build log got debs and ends with "built successfully" !?
<infinity> pitti: Yeah, and then my lp-buildd hack failed it hard due to segvs in the ringbuffer.
<infinity> pitti: I admit that I didn't make that overly verbose.
<pitti> ah
<infinity> pitti: But it's a temp hack until we get some more stable buildds going.
<pitti> what does that grep for?
 * pitti has some trouble actually finding a segfault in the log
<infinity> pitti: It's right at the end.
<infinity> conftest[6966]: unhandled level 2 translation fault (11) at 0x00000008, esr 0x92000006
<infinity> conftest[10403]: unhandled level 2 translation fault (11) at 0x00000008, esr 0x92000006
<infinity> pitti: Nothing you can do about it, don't worry.  We're working on it.
<pitti> ah, I thought something during the tests or so crashed, but apparently not
<pitti> infinity: ack, thanks
<infinity> Those conftests are collateral damage from the segv checker not being able to be smart.
<infinity> Turns out that's actually a subtle glibc bug, and those segv on all arches. :P
<infinity> I'm testing an upload for that right now.
<wgrant> infinity: Well, the test doesn't exactly segv on all arches... it just accidentally fails to build on most/all of the other archs :)
<infinity> wgrant: Potayto, puhchicken.
<pitti> infinity, ogra_: https://android.googlesource.com/kernel/msm/+/57195292 sounds promising for the "uevents for vsync" madness?
<infinity> pitti: Yeahp, shame it's for the wrong driver.
<infinity> (But hopefully this is a trend)
<infinity> pitti: Does umockdev-testbed/script_replay_socket_stream rely on a specific kernel feature that might not be enabled on my arm64 buildds?
<pitti> infinity: well, I surely do hope that we have unix sockets there
<pitti> otherwise, nothing I can think of
<pitti> infinity: do we have a porter box for arm64 to investigate this?
<pitti> doko_: done now; OOI, why do you need this? (it built fine on arm64)
<pitti> doko_: (done in git, not uploaded yet)
<infinity> pitti: No, we don't officially have any of the hardware we have. :P
<dholbach> good morning
<Noskcaj> Are we still aiming to make 14.04 only ship python3?
<cjwatson> Noskcaj: on images, yes if possible, in the archive, that's a pipe dream and isn't going to happen
<cjwatson> not that it's a bad idea to port things, just might as well have realistic expectations
<Noskcaj> cjwatson, I mean on the images. Is the spreadsheet to-do list still current?
<cjwatson> I doubt anyone's looked at the spreadsheet for some time
<cjwatson> wow, there's still a lot on the images :-/
<cjwatson> I guess the bulk of that is U1 (<- twisted)
<Noskcaj> I'll see if i can port testdrive one the gtk3 transition for it is finished. Although i really need one of the old devs to help with that
<Noskcaj> kirkland, speaking of which, is there any chance you'll ever have the time to help with gtk3 and python3?
<ogra_> pitti, i added a comment with the link to bug 1234743 ... thanks
<ubottu> bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus when playing mp4" [Undecided,Incomplete] https://launchpad.net/bugs/1234743
<xnox> slangasek: yeah, I believe it's the bug report from the same person who was contacting me in private. Will investigate.
<ogra_> WHEEE !
<ogra_> http://review.cyanogenmod.org/#/c/28068/
 * ogra_ dances
<tvoss> ogra_, ;)
<ogra_> xnox, looks like we can drop the uevent filtering again if the above works
<xnox> ogra_: wow =)
<xnox> that's nice!
<xnox> ogra_: is that how the rest of platforms work?
<ogra_> xnox, dunno, and i'm not sure yet it will help us ... its not for a maguro kernel and i dont know if our PVR driver will get along with that change
<ogra_> only trying it out will revel that ... i'll do that later today
<infinity> That's not the only driver that's seen that change, so there's some comfort in that.
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<pitti> ogra_: oh, that looks promising!
<Riddell> how do I do a three way conditional in make?  I want to set something different for armhf in this http://paste.ubuntu.com/6217149/
<cjwatson> else ifeq
<cjwatson> Riddell: though watch out for backwards conditional syntax there as the first branch is currently "all architectures other than powerpc"
<cjwatson> and should really be written as $(filter powerpc,$(DEB_HOST_ARCH)) rather than $(filter $(DEB_HOST_ARCH),powerpc), otherwise it's a trap for anyone trying to extend that
<cjwatson> actually maybe it's OK either way
<Riddell> cjwatson: why do we use that backwards syntax with filter, why not just ifeq ($(DEB_HOST_ARCH),amd64) ?
<pitti> Riddell: I guess the idea is if you want to extend matching to other architectures
<pitti> Riddell: i. e. "powerpc ppc64" or similar
<henrix> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, Laney
<cjwatson> Riddell: what he said
<cjwatson> Riddell: but a plain ifeq is fine too if you don't expect that *shrug*.  However it's not especially unlikely that we'll have a ppc64el port at some point soonish
<ev> chrisccoulson: hi. Are you familiar with apparmor and lxc? We're having some trouble talking to dbus when lxc confined: http://paste.ubuntu.com/6217202/
<xnox> bdmurray: can I or you somehow search all ubiquity bugs and check if "GET/HEAD requests should not include body." is in the syslog ?
<xnox> bdmurray: i think i am managing with ubuntu-bugpatterns. Wrote my first pattern and the search is running.
<ev> pitti: thanks for clarifying the apport-retrace stuff!
<pitti> ev: yw :)
<doko> pitti, postgres ping?
<pitti> doko: waiting for the upstream release announcement (folks are in the US)
<jtaylor> can one get a list of package versions installed during adt tests?
<jtaylor> I wondering about the scipy failure, the only change which falls in this 3 hour timeframe is glibc update
<jtaylor> but I can't imagine how that could cause this type of failure
<jtaylor> but I have no idea if it ran with ubuntu2 or ubuntu3
<infinity> jtaylor: Seems more likely that it's a sketchy non-deterministic test, rather than glibc breaking it.
<jtaylor> might be, but it worked reliably for a long time
<infinity> jtaylor: It ran against the latest glibc.
<infinity> jtaylor: https://jenkins.qa.ubuntu.com/job/saucy-adt-python-scipy/ARCH=i386,label=adt/50/console
<infinity> jtaylor: Click "full log" at the top of the log.
<infinity> jtaylor: Then you can see it doing some upgrading and installing bits.
<jtaylor> thx
<infinity> pitti: Erm, the adt systems are qemu right, not xen?
<pitti> infinity: yes
<infinity> pitti: Then why do the i386 VMs have libc6-xen installed?
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix
<pitti> infinity: (re from dinner) err -- they certainly aren't supposed to; checking
<ogra_> pitti, the omapbf patch is a no go ... seems something actually makes use of the uevents on the other side
<ogra_> *omapfb
<ogra_> *sniff*
<pitti> infinity: ah, it's in the cloud images already: http://cloud-images.ubuntu.com/saucy/current/saucy-server-cloudimg-i386.manifest
<infinity> pitti: Kay.  Theoretically shouldn't do any harm (or, indeed, load at all) on a non-xen system, but it looked odd.
<pitti> infinity: that seems a bit questionable indeed; but we can certainly purge that from the auto-package-testing VMs as we know they won't run on xen
<pitti> infinity: is that causing some test failure troubles?
<infinity> pitti: It shouldn't be.  If it is, it's my bug. :P
<pitti> infinity: heh, ok
<infinity> pitti: It was more just something I noticed in passing, looking at an i386 log.
<Riddell> pitti: are you still incharge of langpacks?
<pitti> Riddell: yes
<Riddell> pitti: could it be possible to include kubuntu-patched-l10n in language-pack-xx ?
<mvo> hi, I keep getting firefox crashes on my saucy box "g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting." - is this a known saucy issue? http://paste.ubuntu.com/6217833/ - I have it in gdb
<Riddell> pitti: we use upstream translations for almost everything but there is a couple of patches with i18n which get extracted into kubuntu-patched-l10n only nothing then installs the kubuntu-patched-l10n .po file
<xnox> mvo: do you have matching latest kernel & apparmor  in saucy?
<xnox> mvo: if not fully dist-upgrade and reboot.
<pitti> Riddell: you mean that package installs its own translation domain?
<pitti> Riddell: and we should install that into the langpacks? or you need this package as a dependency? (which would be harder, and I think you should just seed it)
<mvo> xnox: I think so, I upgraded yesterday or so and restarted since
 * mvo double checks
<Riddell> pitti: it includes kubuntu-patched-l10n.pot in the source and that gets put into launchpad where nothing else happens with it
<pitti> Riddell: ah
<pitti> Riddell: yeah, no problem
<zyga> slangasek: hey
<zyga> slangasek: looking at mountall 2.52 now
<pitti> WARNING: unknown translation domain: kubuntu-patched-l10n
<pitti> Riddell: ^ ack
<pitti> Riddell: added to overrides and rolled out
<Riddell> pitti: that warning seems scary but it means everything is ok?
<pitti> Riddell: as it happens I'm waiting for LP to give me a full new export, for building the saucy final langpacks; should happen this evening or tomorrow morning
<pitti> Riddell: it meant that the po files are in the tarball, just that langpack-o-matic previously didn't know what to do with it
<pitti> as it isn't appearing in any binary package
<zyga> slangasek: do I need debhelper 9.20120410 or can I keep using the old one from precise?
<zyga> slangasek: ok, apparently standards version and debhelper weren't that relevant, rebooting to check
<zyga> slangasek: success on first try, this looks promising
<henrix> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<apw> tvoss, hey, would you be a good person to ask about location-service and platform-api.  if i am reading this right, they seem to have developed a mutual build dependancy preventing them building on powerpc
<cjwatson> I wouldn't expect that stack to build on powerpc
<tvoss> apw, powerpc?
<ogra_> aww, bad, so no map apps on powerpc phones then
<cjwatson> don't they end up at qtdeclarative sooner or later?
<cjwatson> mir isn't built on powerpc, various other things in that stack probably aren't either
<cjwatson> apw: I'd pick something else ;-)
<tvoss> cjwatson, that's my understanding, too
<apw> tvoss, they seem to have Architecture: any in 'em but hey
<cjwatson> tvoss: circular build dependencies are bad news in general, though; they're a pain when bootstrapping new ports
<apw> cjwatson, will do
<cjwatson> apw: A bunch of things are Architecture: any when they aren't intrinsically restricted themselves
<tvoss> cjwatson, I can break that package up post freeze
<cjwatson> This is generally fine
<tvoss> apw, would that be fine for you?
<cjwatson> tvoss: (The new port we're bootstrapping right now, I confidently predict you will care about it rather soon)
<apw> tvoss, i will poke something else, it sounds like you have it on your radar
<tvoss> cjwatson, as long as it is after this week, I'm happy to care about it :)
<cjwatson> apw: missing powerpc builds are only a problem if the same package used to build so it's blocking proposed-migration
<mdeslaur> ogra_: oh darn, and here I was building my own powerpc phone! I managed to get it down to 8 kg
<apw> cjwatson, ack
<cjwatson> ev: would you mind fixing https://launchpadlibrarian.net/153264198/buildlog_ubuntu-saucy-arm64.libtimezonemap_0.4.0.1_FAILEDTOBUILD.txt.gz ?  I don't have commit access to the branch ... basically the problem here is a general one exposed by the particular setup of our arm64 builders at the moment; you can see the real problem if you search for "segmentation fault" in the log
<cjwatson> it looks like the test either needs to tolerate not being able to open that file, or it needs to take an argument to let it read that file from the build tree during tests, possibly both
<ev> we have tests?!
 * ev looks
<cjwatson> well, sort of a test
<ev> cjwatson: still making sense of the code, but I'll take care of it
<cjwatson> ta
<ev> cjwatson: how's that http://paste.ubuntu.com/6218121/
<cjwatson> ev: LGTM aside from indentation, thanks
<ev> oh man
<bdmurray> xnox: for future reference I have a local collection of ubiquity bug attachments and descriptions for quick searching
<ev> WHO USES TABS ANYMORE
 * apw for one
<xnox> ev: https://plus.google.com/109160032876474505377/posts/2K7iAEALrSH
<ev> HAHAHAHA
<xnox> bdmurray: ah, I see. I think my bugpatter sucked, can you still do a search for that string?
<bdmurray> xnox: yes, and they are already consolidated
<xnox> bdmurray: ah, cool. thanks a lot.
<ogra_> mdeslaur, hey, thats still lighter than my sparc phone ;)
<jdstrand> ev: looking at http://paste.ubuntu.com/6217202/-- lightdm is running in the container?
<ev> jdstrand: I'm not sure, but stgraber followed up with Mirv: https://pastebin.canonical.com/98867/
<jdstrand> ok
<jdstrand> thanks
<jdstrand> tyhicks: curious: https://pastebin.canonical.com/98867/. it seems odd to me that lxc would all of a sudden start seeing this-- is that because AF_UNIX wasn't mediated it was just being passed though with no dbus mediation, but now that it is, dbus is getting mediated? that seems odd to me
<jdstrand> tyhicks: I don't think it requires a lot of time to investigate since lxc was updated-- I just find it weird since we have had dbus mediation since august but lxc only saw it after the recent kernel/dbus uploads
<jdstrand> tyhicks: s/only saw/seemingly only saw/
<tvoss> ogra_, remind me, who was looking into the upstart memory issues?
<ogra_> tvoss, several people
<ogra_> (in a mtg, more details later)
<tvoss> ogra_, ack
<ogra_> tvoss, so cking was originally looking at the kernel side of this bug, i did too today (to find we cant fix it there) ... jodh fixes the "Â§upstart doesnt free memory on dbus disconnect", xnox did already add a filter for the uevent to upstart-udev-bridge to avoid upstart picking up all the uevents and he is now looking into a netlink filter to do the same for udevd (since that still consumes 5-10% CPU while the screen is on thanlks to t
<ogra_> he event spam)
<ogra_> tvoss, so with xnox finishing that the bug should be worked around enough to be fine for release (we should re-visit the kernel part in T)
<cking> that sounds most fine
<xnox> yeap. Not sure if i will have the udev fix today or not.
<ogra_> cking, well, i would like to get rid of the event rather sooner than later or hide it on a lower level at least
<cking> indeed
<ogra_> filtering on all levels wont stop the traffic
<ogra_> and i strongly assume thats what kills our performance on maguro
<doko> mterry, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207 why committed and not fixed? it's promoted
<ubottu> Ubuntu bug 1203207 in mir (Ubuntu) "[MIR] mir" [Undecided,Fix committed]
<mterry> doko, oh right, it was pre-promoted
<mterry> doko, changed
<tvoss> ogra_, okay, trying to understand this ... why do we accumulate memory somewhere in userspace?
<ogra_> tvoss, bug 1234743 causes 60 uevents per second (one for each vsync) ... upstart-udev-bridge picks it up
<ubottu> bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,Incomplete] https://launchpad.net/bugs/1234743
<ogra_> tvoss, due to bug 1235649 each of the uevents gets accumulated in ram by the session upstart
<ubottu> bug 1235649 in unity (Ubuntu Saucy) "uevent spam causes session upstart to consume massive amounts of memory on Ubuntu Touch" [Undecided,New] https://launchpad.net/bugs/1235649
<ogra_> tvoss, additionally udevd gets some load due to processing all these udevents
<ogra_> *uevents
<tvoss> ogra_, in my perfect little world, fixing 1235649 would help
<tvoss> ogra_, modulo udevd being quite busy
<ogra_> tvoss, the fix for 1235649 means that upstart just frees the ram on disconnect ... there is no proper way to prevent it from collecting valid uevents
<ogra_> tvoss, we added an improper filtering mechanism for this, but the real fix would be to fix 1234743
<tvoss> ogra_, sure, agreed
<ogra_> tvoss, we only work on hiding the fallout
<ogra_> the traffic is still happening and will eat performance
<zyga> stgraber: ping
<zyga> stgraber: is it safe to use _lxc from ubuntu-precise with a updated version of python-lxc from trunk?
<zyga> slangasek: hey, it works, did a dozen reboots, no hangs anymore
<slangasek> zyga: spiff
<zyga> slangasek: will this come to ubuntu precise?
<stgraber> zyga: we build and usually support current LXC on all supported releases starting with precise, so yes, running current LXC on precise should be fine
<zyga> stgraber: I mean -- just the pure python bits while the _lxc module comes from 12.04 stock (0.8 IIRC)
<slangasek> zyga: dunno, I would need to age it a bit to watch for further regressions and by then it might be too late to be worth it
<stgraber> zyga: stock precise doesn't have python3-lxc
<stgraber> zyga: and doesn't have the liblxc0 library you need for that either
<tyhicks> jdstrand: No, the dbus message sending/receiving mediation point is completely separate from the AF_UNIX connect() mediation point
<zyga> stgraber: it has here?
<stgraber> zyga: that's because you're pulling it from the precise-backports ;)
<tyhicks> jdstrand: adding in the AF_UNIX connect() mediation point wouldn't suddenly cause dbus message send/receive denials
<zyga> ah, it's from backports
<zyga> :)
<zyga> slangasek: hmm, so precise is going to stay broken?
<zyga> slangasek: don't our customers hit that or anything? I mean the next LTS is 6 months away
<slangasek> zyga: clearly they don't, since you're the first person to report this issue
<zyga> slangasek: wow, nobody uses nfs nowadays :)
<zyga> slangasek: is the bug specific to nfs btw?
<slangasek> zyga: it probably affects all network filesystem types
<zyga> slangasek: ceph?
<slangasek> if mounted at boot time via /etc/fstab, I don't see why it wouldn't be affected
<slangasek> but it's not as simple as "if you have network filesystems, you hit this bug"
<slangasek> I have network filesystems mounted at boot, since before precise, and never hit this bug
<zyga> slangasek: ah, so it was caused by that nested mount point?
<zyga> stgraber: lxc-create hangs on flock -x 200, any idea why that may happen?
<zyga> stgraber: works on my desktop, hangs on my server (both 12.04)
<slangasek> zyga: honestly, there were so many things that were just slightly wrong that I'm not going to try to untangle that right now and tell you what the root cause was
<cjwatson> slangasek: reviewing your grub branch for bug 1236625
<ubottu> bug 1236625 in grub2 (Ubuntu) "grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root" [High,In progress] https://launchpad.net/bugs/1236625
<slangasek> cjwatson: what'd I do wrong? :)
<cjwatson> slangasek: I'm not convinced that --target=efi_hints always outputs a single drive name suitable for use in $root
<slangasek> right, I didn't know if it did either
<cjwatson> slangasek: in fact it seems to explicitly output delimiter-separated names
<zyga> slangasek: fair enough :)
<slangasek> cjwatson: cut -f1 ?
<cjwatson> possibly but I wonder if there's a better way
<zyga> slangasek: but IIRC after dropping all exotic cases it was still hanging with just a bunch of mount points
<cjwatson> just reading through that code closely now
<slangasek> zyga: well, one of the issues we did find in your case was "names resolvable before the network is up"
<zyga> slangasek: ah, right
<cjwatson> slangasek: you know, I'd almost be more comfortable using the search.fs_uuid path anyway
<cjwatson> (if it works)
<cjwatson> slangasek: the hints mean that it shouldn't be inefficient - it'll try the hinted locations first
<slangasek> cjwatson: yeah, it will work
<cjwatson> slangasek: you could even reduce a lot of the complex duplicated code, then
<slangasek> could you?
<cjwatson> Could the test on line 641 just become "if no abstraction || (efi && uefi_secure_boot && -e efi_signed)"?
<slangasek> let me check
<slangasek> yeah, seems plausible; want me to test that here?
<cjwatson> yes please :)
<cjwatson> that avoids having to copy the horrible regex and stuff
 * slangasek nods
<slangasek> cjwatson: well, efi_signed is only set at line 837
<cjwatson> yeah, you'll need to hoist that up, but that'e asy
<cjwatson> *that's easy
<cjwatson> $source_dir and $efi_suffix are already defined
<cjwatson> by the if block ending line 512 at the latest
<slangasek> cjwatson: yeah, it found its brain on reboot.  Want me to update the patch?
<cjwatson> please, then I'll be happy to merge
<cjwatson> sorry for the delay, the copied code entirely melted my brain before I realised it was copied :)
<slangasek> ah :-)
<zyga> brb
<slangasek> cjwatson: branch updated
<infinity> pitti: Can you upload your fixed umockdev?
<bdmurray> cjwatson: is the v-done tag in bug 1234705 for every release?
<ubottu> bug 1234705 in apt (Ubuntu Raring) "apt-ftparchive writes SHA256 checksums in place of SHA512 in Sources" [High,Fix committed] https://launchpad.net/bugs/1234705
<cjwatson> bdmurray: Yes
<cjwatson> slangasek: You meant to include MokManager bits in that latest version?
<slangasek> cjwatson: hnngh no, sorry
<cjwatson> (should I anyway?  but if so it should be a separate patch)
<slangasek> cjwatson: there's a separate mp for that open
<cjwatson> whoops, better look at that too then :)
<cjwatson> I think it will be just after final freeze though :(
<slangasek> cjwatson: cruft removed, repushed
<cjwatson> (but I'll go for an exception, I think it's reasonable)
<cjwatson> slangasek: any chance you could quickly refactor https://code.launchpad.net/~vorlon/ubuntu/saucy/grub2/mokmanager-support/+merge/187148 to make the mokmanager changes be a separate ubuntu_* patch on top?  I might coalesce when I merge into Debian, but I find that having changes to the Debian patches not be in separate patches is a recipe for me getting confused
<slangasek> cjwatson: looking
<cjwatson> slangasek: ok, got to EOD now as I'm already late, but I can merge this later tonight
<cjwatson> slangasek: (already merged your first branch)
<slangasek> cjwatson: thanks - and mokmanager branch re-pushed now
<cjwatson> slangasek: thanks
<cjwatson> slangasek: ok, you're in luck, uploaded, but somebody else will have to tend grub2-signed
<cjwatson> uploading anyway
<slangasek> cjwatson: ack, thanks :)
<mdeslaur> ev: might want to check out 1238139 to make sure
<hallyn> this is odd - i'm on a precise system, doing 'apt-get build-dep qemu-kvm'.  it says it can't find source package.  apt-cache show qemu-kvm indeed doesn't show the source pkg name (which is qemu-kvm)
<sarnold> hallyn: deb-src lines in your sources.list ?
<hallyn> yup
<hallyn> oh well, using dpkg-checkbuilddeps by hand...  i seem to have messed something up earlier
<ev> mdeslaur: that code hasn't changed in literally years. I'd be quite surprised if this were true. I'll endeavour to look at it tomorrow
 * ev home
<mdeslaur> ev: yeah, I have the same feeling
<dobey> hallyn: "apt-cache show" doesn't show the "Source:" entry for packages where source name == binary name
<sarnold> I wish it did, that'd make grep ^Source a lot more useful..
<hallyn> dobey: interesting.  like sarnold i wish it did :)
<hallyn> thx
<stgraber> hallyn: just do apt-cache showsrc <binary package name>
<stgraber> and grep ^Package on that one
<dobey> yeah
<slangasek> bdmurray: do you have a reproducer for bug #1024590?
<ubottu> bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed] https://launchpad.net/bugs/1024590
<bdmurray> slangasek: unfortunately, no
<slangasek> bdmurray: ok.  looking at the code, I'm not sure why this is valid in the first place... this is a subclass of Gtk.Treeview, which http://www.pygtk.org/docs/pygtk/class-gtktreeview.html says is a subclass of Container, and http://www.pygtk.org/docs/pygtk/class-gtkadjustment.html says gtk.Adjustment applies to various things but not to GtkContainer.
<mino> hi :) how does dhclient get called? Where is the script that parses the network config? I have a problem that dhclient is not listening on a second dhcp interface if i use vlans
<ekarlso> is there a way to create a "bootstrapped" / initial debian folder inside a source folder ?
<lifeless> ekarlso: make-dpkg or something like that exists, I forget the name
<lenios> ekarlso, dh-make ?
<bdmurray> pitti: Do you have any opinion on the SRU of bug 1215911?
<ubottu> bug 1215911 in initramfs-tools (Ubuntu Raring) "wait-for-root fails to wait for plain /dev/sdaX partitions." [Medium,Fix committed] https://launchpad.net/bugs/1215911
<ricardobarbosams> hi
<ricardobarbosams> i try deploy router proxy-arp
<ricardobarbosams> but not working
<ricardobarbosams> i set /proc/sys/net/ipv4/all/proxy_arp
<ricardobarbosams> exists any module for kernel for working?
<ricardobarbosams> my version ubuntu 13.04
<sarnold> ricardobarbosams: does "sysctl -a | grep proxy_arp" show you anything interesting or unexpected?
<ricardobarbosams> root@ubuntuDELL:~# sysctl -p | grep proxy_arp
<ricardobarbosams> net.ipv4.conf.eth0.proxy_arp = 1
<ricardobarbosams> net.ipv4.conf.eth1.proxy_arp = 1
<ricardobarbosams> root@ubuntuDELL:~#
<ricardobarbosams> in tcpdump displaying the request arp, but not response
<ricardobarbosams> 17:41:15.262145 ARP, Request who-has 172.16.200.3 tell 172.16.200.2, length 46
<ricardobarbosams> 17:41:16.262597 ARP, Request who-has 172.16.200.3 tell 172.16.200.2, length 46
* Laney changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen, final freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<CyclicFlux> Good day all. I have a bit of a prob, and had a question or two.
<CyclicFlux> While upgrading from 12.04, to 12.10, my electricity went out causing my system to lose power. Recovery appears to work
<CyclicFlux> could I do a chroot, and then continue the upgrade process?? Or is it best to do it with a Ubuntu 12.10 alternative install Disk.
<slangasek> CyclicFlux: define "recovery"?  If the system boots, you may as well try 'dpkg --configure -a && apt-get -f install && apt-get dist-upgrade'.  Worst case is that you lose the time it takes trying to run, and have to resort to a reinstall; best case is that it completes successfully
#ubuntu-devel 2013-10-11
<pitti> Godo morning
<pitti> infinity: can do, yes
<pitti> bdmurray: I wouldn't have bothered with quantal/raring, for precise it sounds fine to me; but it's already in -proposed now anyway :)
<pitti> infinity: btw, I synced postgresql-9.1, that should build on arm64 now
<infinity> pitti: \o/
<infinity> pitti: Will look shortly.
<pitti> infinity: meh, still no export on https://translations.launchpad.net/ubuntu/saucy/+language-packs
<pitti> wgrant, StevenK: ^ could you please check whether this is running, or something went wrong?
<wgrant> 2013-10-10 11:31:31 ERROR   Uncaught exception while exporting PO file 2444794
<pitti> argh
<wgrant> DB thing, it seems
<pitti> apparently the delta packs run like clockwork, so so PO file 2444794 apparently hasn't been touched for a while
<wgrant> Nah, nothing particular to that pofile, I don't think
<wgrant> Just a DB glitch
<pitti> wgrant: the last export also took about a day longer than expected, but eventually arrived; did that get restarted manually or did it somehow recover from that error?
<wgrant> pitti: I haven't manually scheduled one in months. You sure it just wasn't the export that happens a couple of days later?
<pitti> wgrant: it could have very well been that
<pitti> but time is more critical now with the final release around the cordner
<pitti> corner
<wgrant> IIRC saucy happens tue/thu
<wgrant> Might have to kick a special one off now
<pitti> that would be good, so that we can build them Monday morning (or I kick them off on Sunday)
<pitti> infinity: ah darn, missed the final freeze for psql? I was waiting for the LP import of the sid upload, but it didn't happen until I had to leave
<pitti> infinity: well, I guess it can stay in -proposed and we 0-day update it to -updates if you don't want it in the release any more
<infinity> pitti: Nah, it's all good.
<infinity> pitti: Bonus points if it actually builds.
<pitti> infinity: well, I refreshed config.guess/sub to latest saucy autotools-dev; I'm not sure it'll actually work there, let's see what the tests say
<pitti> infinity: in 9.3.1 I saw a log entry "add arm64 s_lock code", we might want to backport that
<infinity> Other than random segfaults and, of course, compilers needing to be ported, most stuff has Just Worked, so I have high hopes.
<infinity> I don't much care if anything's *optimised* for arm64 right now, so if 9.3.x will make it to 14.04, that's cool.
<infinity> sarnold: Have you looked at #1220434?  Looks like the last MIR of the cycle.
<pitti> infinity: yes, 9.3 will be in 14.04
<infinity> pitti: Kay.  So, if this 9.1 build works at all, we win.
<infinity> pitti: More concerned about it because it's part of the base bootstrap loop, not because I think people will want to run psql on their simulators. :)
<pitti> infinity: at the worst case I can reupload with a trivial change to add arm64 to the 'test failure is okay' list in debian/rules
<pitti> (currently hurd and kfreebsd)
<bdmurray> pitti: I meant the verifying the fix for the bug
<pitti> bdmurray: it's certainly not verified until it gets tested with the actual binaries from -proposed
<pitti> (guard against weird build failures, etc.)
<pitti> infinity: OOI, did you find out why gid=tty now magically works?
<pitti> (or does it?)
<pitti> wgrant: just to avoid misunderstandings, did you kick off a new export now?
<wgrant> pitti: I poked ops about it, haven't got a response yet, will repoke once UK appears I guess.
<pitti> wgrant: ah, thanks
<pitti> hm, why is consolekit still being installed by default
 * pitti checks germinate
<infinity> pitti: It works fine for me.  I can't figure out what WASN'T working before I rebooted.
<infinity> postgres (27651): /proc/27651/oom_adj is deprecated, please use /proc/27651/oom_score_adj instead.
<infinity> pitti: Yell at your upstream about that. :P
<infinity> pitti: This is 2013, I shouldn't still be seeing those messages.
<infinity> pitti: (Build went fine on arm64, though)
<pitti> wow, already built?
<pitti> it takes some 10 minutes with all the tests even on my machine
<pitti> ah, time flies fast this morning
<pitti> yay
<pitti> infinity: upstream is on BSD :)
<pitti> infinity: yeah, I've got a bug for oom_adj
<infinity> pitti: My inability to recreate the broken situation I had with the new eglibc leads me to believe I just had something weird going on locally.  But I dunno.
<pitti> infinity: (btw, I uploaded umockdev earlier)
<infinity> pitti: Thanks.
<infinity> pitti: You apparently have fans, because mir build-depends on it.
<pitti> heh, yeah
<pitti> I could actually also make upower build-dep on it, now that we have it in Debian, too
<infinity> pitti: component-mismatches was your code, right?
<pitti> infinity: I wrote the SVG/html report on top of it
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<pitti> not c-m itself
<pitti> I thought that was part of LP?
<infinity> Ahh, hrm.  I'm trying to figure out why the c-m python script appears to be crashing on a binary that doesn't exist. :P
<pitti> ah no, that was NBS
<infinity> Oh.
<infinity> I bet it's because germinate's still crashing on pepo.
<infinity> wgrant: Did anyone look into that?
<wgrant> infinity: Colin said he might, but I suspect he was a bit busy.
<Guest3903> i'm seeing quite serious issues while trying to install kubuntu using beta2 or latest ISO  -- looks like it's failing in some partition parsing, so the installer is completely stuck after the "Prepare" step
<Guest3903> i have filed a bug here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446
<ubottu> Ubuntu bug 1238446 in ubiquity (Ubuntu) "Ubiquity is stuck after "Prepare" step" [Undecided,New]
<Guest3903> could someone help me debug, or populate the bug report and make it more useful? thanks
<dholbach> good morning
<Guest3903> hi dholbach: i am facing a serious ubiquity bug on the livecd. could you help me out? or at least help me provide a better bug report?
<Guest3903> i have filed a bug here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446
<ubottu> Ubuntu bug 1238446 in ubiquity (Ubuntu) "Ubiquity is stuck after "Prepare" step" [Undecided,New]
<dholbach> Guest3903, I just had a look at /usr/share/apport/package-hooks/source_ubiquity.py - and if you could find an upstart/ubiquity.log and/or casper.log and/or oem-config.log that'd probably help
<dholbach> Guest3903, but this is just me doing guesswork - I'm not an expert
<Guest3903> dholbach: i am still on the livecd, so if you can tell me where, i can try
<dholbach> Guest3903, also in /var/log - like the other log files you added
<Guest3903> Attached /var/log/casper.log
<Guest3903> i dont' see an upstart/ubiquity.log
<dholbach> oSoMoN, happy birthday! :)
<Guest3903> i have a feeling i can resolve the problem by clearing out all my partitions, but i thought i'd rather file the bug so that if it's a ubiquity problem, it can be fixed
<infinity> Guest3903: What filesystem is/was on that partition?
<infinity> Guest3903: Was it XFS?
<Guest3903> no
<Guest3903> infinity: there are 4 partitions, all of them are either vfat or NTFS
<Guest3903> infinity: just added that info to the bug report
<infinity> Fun.
<Guest3903> yea, the XFS errors confused me too
<infinity> Oh, there isn't even an sda4 (well, it probably exists as an extended container)
<infinity> The plot thickens.
<Guest3903> well, does GPT even have concept of an extended partition?
<Guest3903> infinity: also, curiously, parted crashes while trying to print the partition table
<infinity> Oh, this is GPT?  I missed that on the first.
<infinity> pass...
<infinity> Maybe GPT doesn't deal well with having holes in the numbering scheme?
<infinity> Guest3903: What does /proc/partitions have to say about it?
<Guest3903> infinity: udpated report
<Guest3903> infinity: sda4 seems to be partition of unknown type with flag "msft-reserved" -- unlikely to be a hole
<infinity> Guest3903: Yeah, I found that in the partman log too.  No idea what that is.  Maybe a place where they stuff filesystem snapshots or something?
<infinity> Guest3903: Anyhow, your simple way forward is just to blow up the partition table.  But if you're keen on debugging and fixing that, you might try asking xnox about it when he's around in an hour or two.
<xnox> infinity: "in an hour or two" phhhh
<infinity> Or right now. :P
 * xnox yawns
<Guest3903> infinity: yes, i'd rather help fix it if i can :)
<xnox> Guest3903: i don't see anything obvious. And indeed it's strange that gpt partition table gives you head-aches.
<Guest3903> and interestingly, the 13.04 installer did not have any issues on this exact setup
 * xnox ponders why there is Permission Denied.
<xnox> Guest3903: all of them are unmounted right?
<Guest3903> xnox: yes, "mount" does not show any sdaX partitions mounted
<xnox> Guest3903: ok. And what are the labes on /dev/sda2 and /dev/sda1 ?
<xnox> *labels
<Guest3903> xnox: sda1 is "SONSYS" and sda2 is "Recovery", type vfat and ntfs respectively
<oSoMoN> dholbach: thanks :)
<Guest3903> i have a feeling that SONSYS is the EFI System partition, Recovery the OEM "windows recovery" partition, no clue about msft-reserver, and the last partition my actual windows install, xnox
<jderose> xnox: since you're around... any ideas as to why the OEM user isn't getting removed by oem-config after the user config runs? my highest priority item the next week is getting this fixed (on behalf of System76)... so please task me with whatever will help :)
<xnox> Guest3903: infinity: so couple of things are weird. Cause EFI is usually first, not /dev/sda3, and parted thinks they are called "/dev/sda1	Å¾Ã©" and "/dev/sda2	9"
<jderose> xnox: and a quick question: is there a way to make ubiquity do more verbose logging during the user config?
<Guest3903> xnox: both look like EFI, though it's impossible: https://dpaste.de/ADXx
<Guest3903> xnox: i think sda1 is ESP for sda2 "recovery" OS, and sda3 is ESP for sda4/sda5 "windows" OS
<xnox> jderose: i wonder if it is a side-effect of ubiquity starting a logind session. Let me get you version numbers such that we can test downgrading oem-config "between the install & prepare for final shipping" stage.
<Guest3903> xnox: and if i power my laptop using "assist" button, the recovery ESP kicks in and starts the "recovery" OS (which is windows recovery mode)
<Guest3903> if i power on using the power button, windows starts as usual
<xnox> jderose: yes, more verbose mode would be, I still think "debug-ubiquity" at kernel cmdline, https://wiki.ubuntu.com/DesktopCDOptions
<jderose> xnox: yeah, my hunch is it's related to the new PAM stuffs in ubiquity-cm, but i don't have enough ubiquity knowledge to grok what's really going on :)
<xnox> jderose: oh right, yeah.
<xnox> jderose: you can't delete a user with active pam session.
<xnox> jderose: we usually hang out on #ubuntu-installer, but I guess we can continue here.
<jderose> xnox: so bits of the user config are running as the OEM user then?
<xnox> cjwatson: infinity: so ubiquity-dm opens a pam/login session for the oem-config user.... thus can't delete it whilst it's well still logged in. Where/how should the user account be deleted? oem-config/post-stop?
<Guest3903> xnox: any more useful info i can provide/
<xnox> Guest3903: what's the output of "$ sudo parted -l" ?
<Guest3903> xnox: https://dpaste.de/7vqi same error pretty much
<infinity> xnox: Yeah, if there's a point where we shut down that session, that's when we should delete the user, I guess.
<xnox> jderose: so what happens is that machine boots normally -> starting lightdm even is emitted in upstart, oem-config job starts and blocks lightdm. Oem-config job checks for magic file, and start ubiquity-dm as root. At that point ubiquity-dm creates a pam session for the oem-config user ( i think). At the end of the ubiquity-dm run, it deletes the user.
<xnox> *not user but session.
<xnox> infinity: right, let me look at that code path and check if I can close the pam session earlier, before deleting the user.
<xnox> Guest3903: i think your bug is against parted and or windows. So partition/filesystem labels really should not have multiwide characters / unknown encoding.
<xnox> Guest3903: if you can boot into windows, open partitioning/admin utilties and try to rename or remove partition labels of whatever is /dev/sda1 and /dev/sda2 in windows.
<xnox> Guest3903: then somehow reboot or check that windows still works.
<Guest3903> but kde partition manager seems to understand the labels fine, xnox.. so it could be a partition thing?
<xnox> Guest3903: then boot up the 13.10 live cd and see what's there.
<Guest3903> *parted thing
<xnox> Guest3903: hm, we do have old parted.
<Guest3903> sounds like a regression still, because 13.04 installer worked on the same setup. i should probably try redoing that to test
<xnox> Guest3903: what does kde partitioner manager say? maybe screenshot, or copy strings?
<Guest3903> xnox: kde partition manager screenshot is in the report
<Guest3903> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238446/comments/13
<ubottu> Ubuntu bug 1238446 in ubiquity (Ubuntu) "Ubiquity is stuck after "Prepare" step" [Undecided,Confirmed]
<xnox> Guest3903: well, you can fetch /var/log/installer/* from the installed 13.04 and check if the partitions were named the same back when you did 13.04 install. Not much has changed in parted stack in the installed in 13.10.
<Guest3903> argh. https://launchpadlibrarian.net/153474755/snapshot1.png
<Guest3903> xnox: i don't have the installed system any more, sorry.. i could try running the 13.04 installer again i guess
<xnox> Guest3903: strange.
<Guest3903> i am sure it worked, though, because i cloned my current disk from the same disk image used when i had installed 13.04
<jderose> xnox: so when i use debug-ubiquity, does this additional logging go into syslog, or are there other log files i should be looking at?
<xnox> jderose: /var/log/installer/oem-config i think =/ or look at other files under /var/log/installer/*
<xnox> jderose: there should also be /var/log/upstart/[oem-config|ubiquity].log
<jderose> xnox: upstart/ubiquity.log - http://paste.ubuntu.com/6221392/
<jderose> not sure if that ValueError is related or not
<xnox> i don't think so.
<xnox> it's probably from the "normal/first install"
<xnox> not from oem-config run.
<Guest3903> whoa, the parted in 13.10 is 3 years old! the lates t release was also in 2012 .. any idea why i
<Guest3903> any idea why we have such an old release?
<xnox> Guest3903: because FS code was removed in the new major parted series, and debian-installer is not ported yet to the new world order.
<Guest3903> xnox: ah i see
<Guest3903> xnox: ok, i am going to try booting the kubuntu 13.04 iso to see if it actually works or i'm just misremembering
<Guest3903> can't think of anything else useful to do :)
<Guest3903> apart from booting to windows and changing the partition labels as you suggested
<xnox> Guest3903: or change the labels using KDE partition manager & reboot the installer again.
<Guest3903> but parted is not tripping up on the labels, is it? it's tripping up on the device names right
<xnox> no, device names are fine.
<xnox> i think.
<xnox> infinity: it's hallarious but purely from packaging I'm failing to see where "ubiquity" ui is actually started upon oem-config-firstboot. lol.
<jderose> xnox: i attached a tarball of all of /var/log after running the user config (and with the debug-ubiquity boot arg) - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166
<ubottu> Ubuntu bug 1231166 in ubiquity (Ubuntu Saucy) "oem config user remains the default user after full oem installation" [High,Triaged]
<xnox> jderose: thanks.
<jderose> xnox: well, makes me feel a little better about me struggling to find my way around ubiquity :P
<xnox> infinity: bug #624888
<ubottu> bug 624888 in ubiquity (Ubuntu) "if oem user is logged in more than one tty when oem-config is set up, the oem user is never completely removed" [Undecided,Fix released] https://launchpad.net/bugs/624888
<infinity> xnox: Did the s/deluser/userdel/ thing get reverted, or does userdel now shut you down too?
<jderose> infinity: i looked at that earlier today... currently it's using userdel, in oem-config-wrapper i believe is the script
<xnox> infinity: does it know about systemd?
<xnox> infinity: well logind.
<jderose> if the problem is trying to delete the OEM user when that user is logged, can the userdel bit be moved to later stage?
<infinity> xnox: Effed if I know.
<infinity> xnox: uderdel is pretty dumb, it's not meant to know about much at all.
<infinity> xnox: Does userdel perhaps just need a '-f' to fix the bug?
<jderose> it's being called with `userdel --force --remove oem`
<xnox> jderose: || true
<infinity> I guess force needs to be taught to force harder...
<jderose> well, yeah, that bit too :P
<xnox> so we don't fail, on not removing oem-config user.
 * xnox will move it to post-stop exec line in upstart job and check what happens.
<jderose> yeah, that seems a bit fragile... better to get a loud error in that case so regressions are noticed sooner
 * xnox goes to find coffee
<jderose> xnox: infinity: thanks for your help on this! much thanks from System76 :D
<Guest42952> xnox: i was wrong, 13.04 ubiquity has the exact same problem. it's stuck after "preparing"
<Guest42952> and parted also errors out with the same message
<Guest42952>  and yet again kde partition manager works perfectly
<infinity> Guest42952: Can you try relabelling to test xnox's theory that the hang is due to multibyte chars?
<infinity> Guest42952: We can argue if that's a bug that parted (or something) can't read those labels, and it probably is, but it would be nice to prove it first. :)
<Guest42952> well kde partition manager is not allowing me to change labels
<Guest42952> but if both blkid and kde partition manager can read the labels fine, it has to be a Parted issue, right?
<infinity> I'm not convinced that parted's problem is the labels just yet.
<pitti> seb128: bonjour, Ã§a va ?
<pitti> seb128: did you already talk to the release team about 3.10.1 bits next Monday?
<seb128> pitti, salut, oui, et toi ?
<pitti> seb128: je vais trÃ¨s bien, merci
<seb128> pitti, no, I planned to just SRU those, we don't have so much 3.10 anyway
<pitti> seb128: ok, then I perhaps upload gnome bug 709223 as a patch right now
<ubottu> Gnome bug 709223 in general "problem with toggleref thread-safety" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=709223
<pitti> seb128: I'll release pygobject 3.10.1 on Monday with that (and a memleak fix)
<seb128> pitti, if you want it in the release, today seems a better bet than monday in any case
<seb128> who knows we might not get respins after monday
<infinity> Monkeys may fly, too.
<infinity> (But I appreciate the enthusiasm and confidence)
<pitti> oh, I thought it was the pigs who can fly, but perhaps that doesn't work in Canada? :-)
<xnox> pitti: britain is a funny place.
<xnox> infinity: or not yet?
<xnox> =)
<pitti> in Canada they say "Adams can sleep"
<infinity> pitti: It is, and the monkeys traditionally do something slightly less tasteful.
<infinity> xnox: Not in London until Sunday.
<xnox> pitti: The Adams family, tudutudutudu.
<Guest42952> infinity: anything else i can provide to help?
<pitti> oh those mental pictures *off*, *off*!
<infinity> Guest42952: Not sure, TBH.  Hence why I pointed you at xnox.  Not my area of expertise. :)
<Guest42952> fair enough. xnox, anything else that could help debug/
<xnox> not really no.
<Guest42952> ok. thanks for all the help, xnox, infinity!
<tvoss_> pitti, pin
<tvoss_> g even
<pitti> hey tvoss_
<jderose> er, what did i do... now oem config is launching the ubiquity installer rather than the user config... hmm, time to unbork my VM i guess
<tvoss_> pitti, mind having a look here: https://bugs.launchpad.net/mir/+bug/1238417
<ubottu> Ubuntu bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Confirmed]
<pitti> tvoss_: queueing
<tvoss_> pitti, ack and thx
<jderose> xnox: so what were you moving to post-stop?
<xnox> jderose: i am investigating at the moment.
<jderose> xnox: please let me know if there is anything you want me to try/test
<xnox> jderose: there is also kernel cmd line option "debug-oem-config" in addition to "debug-ubiquity"
<jderose> ah, okay, i'll try that too. my VM is again submitting to my will, so i'm ready to go
<jderose> xnox: is there any use in using debug-oem-config and debug-ubiquity together, or should I just use debug-oem-config?
<xnox> i think you just need "debug-oem-config" but debug-ubiquity will not hurt.
<jderose> okay, i just tried without the "|| true" bit, hopefully the failure will log something useful...
<jderose> xnox: attached another /var/log tarball - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166
<ubottu> Ubuntu bug 1231166 in ubiquity (Ubuntu Saucy) "oem config user remains the default user after full oem installation" [High,Triaged]
<xnox> jderose: i think that should work: http://paste.ubuntu.com/6221565/
<xnox> jderose: so, "before shipping to use"
<xnox> jderose: modify /etc/init/oem-config.conf to include the bits at the end from "post-start script ... end script"
<xnox> jderose: then reboot, do end user config, and observe that oem-config user is removed.
<jderose> xnox: okay, trying now...
<jderose> xnox: yup, that fixes it!
<jderose> oem isn't in passwd or group, and /home/oem has been removed
<jderose> user login works as expected
<xnox> jderose: good.
<xnox> jderose: we do keep ubuntuone package for the end user configuration. but it's a separate package from oem-config, FYI.
<jderose> yeah, i saw the plugin is in a separate binary package... first thing i tried was removing it, just in case that was the problem :P
<jderose> but we'll leave it in place, btw
<jderose> xnox: what's the best way for me to help with this? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1237694 <= my next highest priority
<ubottu> Ubuntu bug 1237694 in System76 "Installation fails without Internet" [Critical,Triaged]
<xnox> jderose: i'm working on bug #1226912 at the moment
<ubottu> bug 1226912 in ubiquity (Ubuntu Saucy) "ubiquity starts but does not appear" [High,Confirmed] https://launchpad.net/bugs/1226912
<jderose> (also, BTW, i'm not 100% sure 2.15.21 was what introduced that regression)
<xnox> hm.
<jderose> xnox: so does this only happen when you "try ubuntu first" rather than directly choose "install ubuntu"? I think i hadn't noticed this because i tend to use the latter
<xnox> jderose: no, if you press Esc at boot splash and select "try ubuntu without changing your computer" text menu item.
<xnox> jderose: or e.g. if you select that on an UEFI machine.
<jderose> gotcha
<pitti> bdmurray, stgraber, ScottK: would you mind ack'ing the psql microrelease uploads for all stables? (they have a MRE, and nothing out of the ordinary, so it should be rather straightforward); bug 1237248
<ubottu> bug 1237248 in postgresql-9.1 (Ubuntu Raring) "New upstream microreleases 9.1.10, 8.4.18" [Undecided,New] https://launchpad.net/bugs/1237248
<jderose> xnox: okay, my brain is mush and i need sleep now, but i'll do what i can to help out on these ubiquity bugs tomorrow, and next week. thanks again!
<xnox> jderose: no worries. Thank you.
<pitti> infinity: I uploaded apport to disable crash reporting to LP for final release (as per release checklist); it needs to go into the final image, but not necessarily today yet, so please accept whenever it's convenient
<infinity> pitti: Yeahp, thanks.
<infinity> pitti: To be clear, this is just disabling the "open a web browser and file a bug and make me hate you for it" part, not the reporting to errors.ubuntu.com, right?
<pitti> infinity: correct, the whoopsie/daisy parts stay
<pitti> infinity: same procedure as last release (and the ones before..)
<infinity> pitti: Yeah, it's gotten a bit fuzzy with whoopsie in the mix.  I think we even had one release (or most of one) where we never had the web browser bits.  I liked that cycle. :P
<pitti> infinity: before whoopsie we completely disabled apport, to avoid the CPU overhead
<infinity> pitti: No, I meant during a dev cycle, we didn't re-enable the browsery bits once.
<pitti> then we had that rather long and heated discussion, I admitted defeat, and now it's done like that ever since
<pitti> infinity: we usually didn't do before alpha-2
<infinity> Anyhow, no big deal.  Current situation works.  Thanks for the upload.
<pitti> but it's a matter of some gut feeling "it's time now"
<ev> slangasek, pitti, others: I'm finding it hard to find time for bug 1235436. Is anyone available to help out?
<ubottu> bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,New] https://launchpad.net/bugs/1235436
<xnox> ev: i think it's a funny integration with ro-system images. You cannot rely on file being present or not. Instead you should check if contents of it is zero / non-zero. Or some such. As we can make that file available by default, and allow users over-writting its content, but not completely delete the file.
<xnox> ev: this is similar to the timezone changes not persisting across ro-system upgrades bug.
<xnox> ev: how is /etc/init/apport-noui.conf created at the moment?
<ev> xnox: it's shipped as part of apport
<xnox> sorry, i mean the /etc/apport/autoreport.
<xnox> that shipped as well?
<xnox> ev: i think will be SRUing that bug report.
<ev> xnox: oh dear. We need to add that to the writable paths - it's created by system-settings
<pitti> it's not in the current images at least
<pitti> so, another victim of our hacked-up /etc? :-/
<xnox> ev: and you can't test with [ -e ], as system-image updates are ro, and bind-mounted. If user "deletes" the bind-mount, it would be recreated on reboot.
<xnox> ev: but you can make it writable, thus one needs to check it's contents, or some such. Which means that maybe you can reuse existing whoopsie config file which is parsable and add "auto=True" key to it.
<ev> xnox: can you please add your thoughts to the bug so we're tracking this in a single place?
<xnox> ev: ok.
<ev> thanks, just trying to manage calls and chatting here at the same time
<xnox> ev: and then there is the race to fix of multiple apports tracing the same thing =)))))
<ev> I'm going to lose some details :)
<pitti> xnox: nah, let's not automatically modify conffiles
<xnox> pitti: hm, good point.
<pitti> (sorry, just half a brain cell here either, it seems today is the day when I get bombarded with "OMGcanyoulookintobugXXXXX" requests)
<xnox> ev: right after I make ubiquity to stop spinning in an infinite loop.
<xnox> pitti: ditto =)
<pitti> but please let's not do any knee-jerk addition of files o writable-files
<pitti> the current implementation for handling files there is quite frankly rather broken and not maintaintable at all
<pitti> ev: I'd rather move the file to /lib or something
<pitti> ev: or an alternative lookup path to /userdata, or whichever path we actually have left for putting data into
<pitti> as we essentially said "/etc/ is not for configuration any more", I guess /userdata is the logical replacement
<ev> pitti: I honestly don't mind where we put it
<ev> definitely deferring to your better judgement on this :)
<infinity> pitti: I'm emptying out the stragglers in the NEW queue, and there's an oddity there from you.
<infinity> pitti: You removed flphoto from saucy because it "didn't work with libgphoto 2.5+" and then, on the same day, you uploaded a no-change rebuild, which got cause in NEW because you'd already removed the previous version.
<infinity> pitti: So, which is it? :)
<infinity> s/cause/caught/
<pitti> infinity: I think the reupload was an error, I probably just forgot to rm it from my local "to rebuild"  folder, sorry
<tvoss_> pitti, wondering: which value is adjusted by upstart when defining an oom adjustment for a job?
<ogra_> tvoss_, how does that matter, since we artificially set it to what we like from lightdm
<ogra_> (which is -10 for all apps started by the session currently)
<ogra_> tvoss_, http://bazaar.launchpad.net/~mad-wol/upstart/oom-score-stanza/revision/1280
<ogra_> tvoss_, "/proc/%d/oom_score_adj", getpid ());
<ogra_> it seems to also just use the /proc node
<ogra_> (and defaults to 0 as you can see in the code)
<ogra_> tvoss_, if you want to allow users to set it you will have to change the kernel i fear
<tvoss_> ogra_, not users, u8, but I think I found a way
<ogra_> u8 runs as phablet
<ogra_> since it gets started by the session upstart process
<ogra_> which runs as phablet as well
<tvoss_> ogra_, yup, but we can use setcap
<ogra_> ah, that could possibly work
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen, final freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach
<roadmr> hello folks! I was following the procedure to secure-boot over pxe (https://wiki.ubuntu.com/UEFI/SecureBoot-PXE-IPv6) and found what appears to be a typo in shim.efi.signed, it tries to load "grubx64.efi(", I found this by monitoring the tftp log file after it failed to load "grubx64.efi"
<GridCube> I wonder why "users" list two times any user name, i understand that users list currently logged users to a system, so it means that my user is logged twice?
<xnox> slangasek: ^ see roadmr message.
<dobey> GridCube: #ubuntu is for asking for help on ubuntu. the one user listed multiple times is because of virtual terminals and such (if you have terminal windows open, for example)
<GridCube> oh correct! dobey :D i opened a bunch of terminals and i got a bunch of my names, thanks a lot. (and sorry for using the wrong channel)
<ice9> I want to start with Ubuntu development so where to find simple bugs to start with?
<rbasak> ice9: try looking for bugs tagged 'bitesize'. Eg: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize&orderby=-date_last_updated&start=0
<mardy> seb128, Laney: about the EDS integration with UOA, I just forwarded you a patch
<seb128> mardy, I was just reading that, what did you ask to mbarnes? if it would be easy to backport the fix?
<mardy> seb128, Laney: it's a backport of the OAuth support for calendar, to 3.8
<mardy> seb128: yes, and he did this in a very few minutes
<seb128> hehe
<mardy> seb128: so I guess it's not tested, but that's up to us
<seb128> the guy is a rockstar ;-)
<seb128> mardy, right
<seb128> mardy, it's too much of a diff for saucy anyway
<seb128> mardy, but let's land early next cycle (then maybe backport it)
<mardy> seb128: maybe we can keep it in -proposed, and give it quite some time for testing before pushing it to everyone?
<seb128> mardy, yes, just not for saucy since we are frozen for release since yesterday
<mardy> seb128: sure
<seb128> mardy, but I'm keeping it on my todo for after next week
<mardy> seb128: thanks
<roadmr> xnox: perhaps I could file a bug about the shim problem? is lp:ubuntu/shim-signed a good place for that?
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen, final freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> ev: I could kick in some time for buG #1235436, but would want pitti's and your guidance on architecture
<ubottu> bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,New] https://launchpad.net/bugs/1235436
<ev> slangasek: happy to provide guidance, I just don't want to see it fall on the floor as I transition. It's best that more than my eyes are watching its progress.
<slangasek> roadmr, xnox: that's no typo in shim.efi.signed; that wiki page was a bit optimistic, and assumed that we would get the fixed shim back signed from MS in a timely fashion
<slangasek> roadmr: i.e., this is fixed in shim 0.4-0ubuntu4, but we've been waiting 2 weeks for a signature
<slangasek> ev: so if I were to take a stab at this, I would do what I described, having whoopsie scan directly and give whoopsie an 'autoupload' config option.  Where should that option live for whoopsie? Should it reuse /etc/apport/autoreport, or would you like an /etc/whoopsie/autoreport?  Or do you disagree with having whoopsie directly handle this?
<ev>  /etc/default/whoopsie?
<ev> slangasek: or either of those. I'm not fussy
<ev> though pitti and xnox discussed concerns over using /etc on touch
<ev> since it's not writable
<slangasek> ev: /etc/default/whoopsie has the difficulty that it's owned by the whoopsie package, so how do we configure it differently for phones vs. notphones
<slangasek> so, probably needs to be a separate file
<infinity> Writing to /etc at runtime is wrong even on classic UNIX systems.
<slangasek> (and what was supposed to own that file anyway, since /etc/apport/autoreport still doesn't exist?)
<ev> slangasek: *nods*
<infinity> At least, I assume we're talking about runtime settings here.
<ev> slangasek: it's created by system-settings
<ev> but it should be already populated
<slangasek> oh?
<ev> we got agreement from legal on that, provided we mention it in the first use dialog
<ev> and it should be - it's in the spec
<infinity> Which belong in user configs or system-wide stuff in /var (or whatever crazy Android equivalent the phone is currently using)
<xnox> ev: we don't have first use dialog.
<ev> though no one implemented that, did they
<xnox> yet.
<ev> wooooo
<slangasek> heh
<ev> priorties
<slangasek> so, by default we have no mention of it, which means by default we can't turn it on?
<xnox> slangasek: ev: does that file has contents? we can bind mount it and writable, but then it's always present but has content that can be changed.
<ev> slangasek: we should check with legal - maybe there's a way out of this
<slangasek> xnox: to be determined
<ev> it'd be really awful if we had it off by default
<ev> as that pretty much guarantees it wont get used
<slangasek> ev: I'm not going to try to circumvent the legal guidance here
<slangasek> because I agree with it ;)
<ev> *nods*
<slangasek> for now, I'll focus on sorting out the backend
<slangasek> is system-settings supposed to have a toggle for this?
<ev> though I am curious as to why you were seeing apport-noui running if nothing was creating that file
<ev> yes, and it does
<ev> I wrote it
 * ev checks on the actual phone
<slangasek> ev: because I created the file myself for testing ;)
<ev> oh right
<ev> and here I was worried it was all going to hell in a handbasket
<ev> (not that it isn't :-P)
<ev> yup, it's there
<ev> security and privacy -> diagnostics
<slangasek> ev: ah, so the toggle is there, and it's selected, but it doesn't seem to control /etc/apport/autoreport since I don't have that file
<ev> slangasek: on a call, sorry!
<roadmr> slangasek: oh I understand, I'll wait for the next version then, rather than filing a bug.
<roadmr> slangasek: (re: the "typo" in the shim)
<ogra_> slangasek, so since i dont think that we will fix the ureadahead bug before release, would you be very opposed if i shipped an override upstart job for ureadahead (from lxc-android-config or ubuntu-touch-session) that mounts and unmounts debugfs at a place like like /dev/.ureadahead dynamically from pre-start/post-stop scripts ?
<slangasek> ogra_: er, what would doing that help?
<ogra_> slangasek, it generates proper pack files on the phone here
<slangasek> yes, I'm opposed to it because we analyzed the bug and showed that the debugfs mount had nothing to do with the failures
<stgraber> right, it'd generate the packs and then never use them and then generate them all over again the next boot since at the time ureadahead starts it won't find them
<slangasek> ogra_: did the problem of /var/lib/ureadahead not being mounted before ureadahead starts get solved?
<ogra_> stgraber, oh ? why ? they are in a rw dir
<ogra_> stgraber, that would surely be mounted already once the upstart job fires
<stgraber> ogra_: ureadahead starts before any of the bind-mounts are applied
<ogra_> well it definitely works fine on my maguro with such a hacked up upstart job
<ogra_> stgraber, ?
<ogra_> stgraber, dont you mount them in the initrd ?
<stgraber> no
<ogra_> oh
<stgraber> mountall mounts those
<stgraber> (note, we had that very discussion at least once already ;))
<ogra_> slangasek, nope, my job would have to start later
<ogra_> stgraber, right, i just noticed that i had a modified start on line in my test code
 * ogra_ would really like to get these 10sec faster boots :/
<slangasek> certainly; but you're not going to get that unless you manage to write pack files that actually get read again
<slangasek> and that's not something that lends itself to a quick'n'dirty change
<ogra_> so i would need to write them to a temporary space and copy them ...
<slangasek> /sys/kernel/debug, btw, should almost always be mounted before the local filesystems
<slangasek> no
<slangasek> "temporary space and copy" means that they again won't be in the right place on the next boot
<stgraber> the real fix there is to get the initrd to mount /var/lib/ureadahead (I believe that was the conclusion of the discussion we had last time)
<stgraber> since that's the only way to have that directory readable and writable early enough for ureadahead
<ogra_> ok
<cjwatson> That's also a workaround, but a better one
<ogra_> me grumbles about the metapackage update he just runs ...
<ogra_> I: Checking Release signature
<ogra_> gpgv: Signature made Fri Oct 11 18:36:48 2013 CEST using DSA key ID 437D05B5
<ogra_> gpgv: BAD signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
<ogra_> i get that pertty often in recent times
<ogra_> (a second fresh run usually works then)
<stgraber> cjwatson: it's not pretty I agree but I can't think of a cleaner way of doing it since / is read-only and so can't possibly contain the pack files. ureadahead is meant to start before mountall so can't depend on anything mounted by mountall, therefore we need the kernel, the initrd, upstart of ureadahead itself to mount the pack file location. The least ugly option being the initrd.
<stgraber> *or
<cjwatson> stgraber: Clint offered the general outline of a solution in https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/523484/comments/34 which I think would be viable
<ubottu> Ubuntu bug 523484 in ureadahead (Ubuntu) "ureadahead requires /var on root filesystem" [Medium,Triaged]
<stgraber> cjwatson: that'd mean the very early boot wouldn't benefit from ureadahead but it seems like an acceptable compromise to have a solution which works for everyone
<stgraber> though I don't think we should attempt something like that for saucy
<cjwatson> stgraber: ureadahead is "start on starting mountall" anyway, and not very much else runs while mountall is running; I don't think it would delay it much unless the fs containing /var/lib/ureadahead is unreasonably slow to mount
<cjwatson> stgraber: There are probably some complexities related to ureadahead-other
<cjwatson> stgraber: Yeah, I thought about taking a day or two and doing it, but I think it's too risky now
<stgraber> sounds like something that should be done in early 14.04
<cjwatson> Yep, we definitely should, that bug has dragged on way too long
<stgraber> ogra_: http://paste.ubuntu.com/6223336/ should (untested) give you a working ureadahead and also fix the fsck flag you mentioned the other day.
<ogra_> stgraber, awesome !
<ogra_> i'll test that on the weekend
<ogra_> (and take care of landing it on monday)
<stgraber> cjwatson: I commented in the bug and milestoned for 13.11 so it hopefully ends up on a list somewhere and we don't forget about it for 14.04
<cjwatson> stgraber: thanks
<sarnold> infinity: no, I haven't looked at curtin 1220434 yet
<slangasek> xnox: why the reopen of the dbus task on bug #1234731?
<ubottu> bug 1234731 in dbus (Ubuntu) "calling 'initctl set-env -g' from within an upstart job is lost" [High,New] https://launchpad.net/bugs/1234731
<cjwatson> jdstrand: hmph, I wish I'd noticed earlier that apparmor/saucy has started pulling Python 2 back into standard, when raring had relegated it to desktop
<jdstrand> why is it doing that?
<cjwatson> For the sake of one script that would probably take five minutes to port
<jdstrand> we wrote everything for python3
<cjwatson> /usr/sbin/apparmor_status
<cjwatson> #!/usr/bin/python
<jdstrand> that should be py3
<jdstrand> hrm
<cjwatson> certainly doesn't seem to require anything 2-specific
<jdstrand> yeah, that script is bi-lingual no less
<jdstrand> we did it that way intentionally
<jdstrand> but obviously got part of it wrong
<jdstrand> cjwatson: it is a one character fix that I would be happy to upload
<jdstrand> of course, I'd probably need a landing request and everythign else
<mdeslaur> lol @ bilingual python
<infinity> jdstrand: I'm all for the one-charater fix and no more python2.7 in standard, BTW.
<linux> It will be great if ubuntu have on login option to choose effects ccsm like
<linux> minimum , medium , maximum with all posibilities like fire , wather , cube ... etc that will be great in unity for new users like girl and boys
<Noskcaj> There's spam on http://qa.ubuntuwire.com/bugs/rcbugs/ again
<Noskcaj> Also, is there any chance we could sync libtar? it fixes a CVE and nothing else
<slangasek> Noskcaj: libtar would be allowed in if someone synced it, yes
<Noskcaj> slangasek: Is there any chance you cpuld, or at least file a bug. I'm not able to do anything other than irc curretly
#ubuntu-devel 2013-10-12
<slangasek> Noskcaj: looking
<slangasek> Noskcaj: it's not correct that it only fixes a CVE; there are changes to thread support handling, which I'm in no position to vet at the moment
<Noskcaj> oops, ok
<sarnold> I believe there's more work to be done to fix the security issues: http://www.openwall.com/lists/oss-security/2013/10/11/8
<infinity> pitti: I just vomited a little at that udev/hv patch.
<infinity> pitti: How do these people not have a kernel driver that's doing the right thing here?  Letting userspace manage cpu/memory hotplug sounds like madness.
<infinity> pitti: Aaanyhow, now that that's out of my system, closing my eyes and pressing "accept".
<c_korn> hello, a question regarding gensymbols. when building a package there is a warning: "warning: debian/liboyranos0/DEBIAN/symbols doesn't match completely debian/liboyranos0.symbols.amd64" but running "dpkg-gensymbols -pliboyranos0 -Pdebian/liboyranos0" does not do anything.
<mdeslaur> yesterday's iso gets stuck at the timezone selection screen...is that a known issue?
<sladen> mdeslaur: file it
<sladen> mdeslaur: dups can be sorted out later
<mdeslaur> sladen: thanks
<mdeslaur> bug 1239127 for the curious
<ubottu> bug 1239127 in ubiquity (Ubuntu) "20131011.1 iso gets stuck at timezone selection screen" [Undecided,New] https://launchpad.net/bugs/1239127
<Laney> wgrant: did you forward the gst-base change?
<reaby> hello everybody, i'm new to this, and found out that it's very challenging to create a new launcher (shortcut) to desktop
<reaby> could it be possible for next release to have easier way ?
<reaby> thanks.
<reaby> native linux apps are fairly easy since you can just make a link, but a wine app or launcher for minecraft is impossible to do
<reaby> what i tried for minecraft was to do a bash script to launch it, but even if i put executable flag for the file, it still wants to open the file at gedit
<reaby> and when i try to change the file opener, there is no way to "just open"
<reaby> and if i try the search button from internet is just crashes
<doko> Laney, pitti: any chance to have a look at the gmime test failure?
<doko> looking at 2.6.18
<doko> same failure with this version
<Laney> doko: probably https://git.gnome.org/browse/gmime/commit/?id=bb1c6094e04ce54de52289cd5ba7f9b73694ef1f
<Laney> let me try this
<Laney> seems to work
<doko> Laney, please upload
<Laney> sec
<Laney> just being killed on hitman
<Laney> ok, I died :( /me uploads
<Laney> done, it is
<halfie> hi, do you guys turn on "-Werror=format-security" by default in Ubuntu?
<halfie> cjwatson, are you around?
<halfie> what do you guys think about "prelink" in general? is there demand for it from Ubuntu users?
<Noskcaj> halfie, I don't think we do because Werror has many false positives. One of the more experienced devs might actually know.
<halfie> Noskcaj, oh I see. I was told that it had very very few false positives. weird.
<halfie> if it has known false positives then I can't "fight" to get it enabled.
<Noskcaj> Well, when Werror get false positives, it makes things FTBFS
<halfie> yes ;(
<slangasek> prelink defeats ASLR and modifies files owned by the package system; it should be avoided.
<slangasek> Noskcaj, halfie: we absolutely do turn on -Werror=format-security by default
<Noskcaj> slangasek, Thank you for knowing far more than i do about this stuff
<slangasek> Noskcaj: that's not the same as turning on -Werror generally, it's about treating a specific class of warnings as errors
<Noskcaj> ok
<halfie> slangasek, how do I verify / see the default flags? (I am a Fedora guy ;( )
<cjwatson> they always show up in gcc -dumpspecs, although reading that takes practice
<slangasek> halfie: 'dpkg-buildflags' tells you the defaults; build logs for individual packages should show how these flags are actually applied, though many packages misbehave and hide their compiler commandlines in the output
<halfie> slangasek, yes, prelink is the first thing I remove. I am trying to get Fedora to disable it and give the choice to the user instead.
<slangasek> Fedora uses prelink? oy
<halfie> slangasek, BY DEFAULT!
<cjwatson> (my answer is the default for the compiler; slangasek's answer is the default for package builds, at least those that honour dpkg-buildflags)
<halfie> :-(
<halfie> cjwatson, both answers are useful for me. thanks!
<halfie> so, I have two action items. 1) do *not* use prelink by default 2) enable "-Werror=format-security" by default.
<slangasek> man, that sounds like a lot of work - maybe you should just switch to Ubuntu instead ;)
<halfie> slangasek, I did run Ubuntu for some years :-) ... I get paid to work on Fedora these days ;) have to be "loyal", right? :D
<halfie> (but I am trying to pick-up Ubuntu packaging stuff)
<halfie> Ubuntu also has "-Bsymbolic-functions" turned on. I have read that "it is permitted for users of the shared library to override a symbol (function name or global variable) with their own versions." ... how is this overriding actually done?
<soren> I'm confused. I'm looking at an ELF binary that doesn't seem to have an RPATH set ("objdump -x `which binary` | grep RPATH" is silent), says it needs libwhateverclient.so. libwhateverclient.so resides in /usr/lib/whatever, which isn't in /etc/ld.so.conf. Somehow it manages to find it anyway.
<soren> "ldconfig -v | grep libwhatever" is also silent.
<soren> Oh, hang on. Now it doesn't work anymore.
<soren> what the..
<soren> Eeeek.
<soren> postinst has: "ldconfig /usr/lib/whatever"
<soren> Running "ldconfig -v" restored normalcy.
<soren> That's a first.
<soren> (and hopefully last)
<mdeslaur> soren: wow
<infinity> soren: Eww, seriously?
<infinity> soren: Is this packaged IN THE ARCHIVE?
<soren> infinity: Gosh, no.
<soren> infinity: It just has a built-in facility for producing (some sort of) debian packages.
<infinity> soren: Some sort of, indeed.
<soren> Ok, so according to http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html, it's fine for this package (let's call it "whatever") to have binaries specify /usr/lib/whatever as an RPATH.
<soren> Nonsense.
<soren> Or is it? Man, my packaging-fu is really rusty.
<infinity> soren: Yeah, a self-contained RPATH like that is fine.
<soren> No, my initial statement seems accurate... but how does that work with multiarch?
<infinity> soren: With multiarch, the rpath should also be multiarch?
<soren> infinity: Let's pretend that I'm an idiot...
<infinity> soren: lib in /usr/lib/$(triplet)/package
<infinity> soren: And RPATH of same in binary.
<infinity> soren: Not that it would matter desperately if it was /usr/lib, since your binary is /usr/bin (which isn't multiarch already), and the exlicit allowance here is for private libraries *in the same package*.
<infinity> (If you choose to read that as "from the same source package", which might be valid, then yeah, you could multiarch the private libs package, and use a multiarch RPATH).
<soren> infinity: Ah, ok. Yeah, it was the bit about the binary being in a non-multiarch location that got me confused.
<soren> Does one of the dh_* things remove rpath automatically?
<infinity> Not that I know of, unless someone made dh_strip more clever.
<infinity> I used to build-dep on chrpath and strip it myself.
<soren> I just wonder why my more proper debian packaging spits out binaries without this rpath set.
<soren> Now I know better where to look. Thanks.
<infinity> Oh, is the RPATH set in upstream's binaries, but stripped in yours?
<infinity> Curious.
<soren> Yeah.
<soren> This thing is a treasure trove of curiosities.
<infinity> soren: The only debhelper/rpath mention I see is:
<infinity> debhelper (7.3.9) unstable; urgency=low
<infinity>   * cmake: Avoid forcing rpath off as this can break some test suites.
<infinity>     It gets stripped by cmake at install time. Closes: #538977
<infinity>  -- Joey Hess <joeyh@debian.org>  Sat, 01 Aug 2009 15:59:07 -0400
<soren> Yeah, saw that. Maybe I'm full of it. The only RPATH I see mentioned now is pointing to my dev area (presumably, as Joey also mentions, for testing).
<soren> I wonder how this is mean to work anywhere.
<infinity> Well, it's meant to "work" due to that postinst snippet and a funamental misunderstanding that subsequent ldconfig calls will make it explode. :P
<infinity> It's not the first upstream who doesn't understand ldconfig.
<infinity> I've been in a long and heated debate with McAffee over their insistence that it's not a bug for one of their random crap libraries to claim an SONAME of ld-linux.so.2
<infinity> You can guess what happens to user's systems on the next ldconfig run after installing their software.
<mlankhorst> well
<mlankhorst> not much any more, I guess
<infinity> *rimshot*
<soren> infinity: whuh?
 * soren falls asleep, confused
<slangasek> halfie: overriding the symbol is done by simply providing a symbol of the same name in your application, which then takes precedence in the linker resolution
<Noskcaj> What is the best way to see what things on the iso still need porting to python 3?
<infinity> Noskcaj: germinate, or walking package dependencies would be the "right" way, but fiddly if you're not sure how.  The simple way would be to install ubuntu-desktop and ubuntu-live in a chroot and then "apt-get remove libpython2.7-minimal" and see what goes with it. :P
<cjwatson> soren: man-db does that very thing (although with RUNPATH, not RPATH - which means it remains overrideable using LD_LIBRARY_PATH) for its private libraries.
<cjwatson> (Not sure my last attempt at that got through.)
<ersi> Noskcaj: If you start pulling in that mess, feel *very* free to write up findings. I got "Help with porting to python3" on my TODO (albeit not at the top spots)
#ubuntu-devel 2013-10-13
<rohan> i just installed kubuntu 13.10, and I can't connect to any network device: network manager applet fails with "IP configuration was unavailable"
<ScottK> cyphermox: ^^^ didn't you just update that?
<int_ua> Can someone quickly confirm that /etc/network/if-post-down.d/avahi-daemon is a symbolic link to `../if-up.d/avahi-daemon' in 13.04 current version?
<int_ua> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1230056
<ubottu> Ubuntu bug 1230056 in avahi (Ubuntu) "/etc/network/if-post-down.d/avahi-daemon is a symbolic link to `../if-up.d/avahi-daemon'" [Undecided,New]
<int_ua> leaving now, feel free to confirm the bug on LP
<pitti> infinity: udev/hw patch> yeah, me too; see my concerns on the bug, but it seems we don't have a better solution ATM :/
<pitti> infinity: also, that's for guests, not the hypervisor
<pitti> infinity: I built and tested final langpacks FYI; uploading now, recruited another amd64 builder to help out
<infinity> pitti: Lovely, thanks.
<pitti> infinity: uh, didn't actually expect you to be online at this time ..
<infinity> pitti: I'm in London.
<pitti> ah, release sprint, I take it
<infinity> Of a sort.
<pitti> ev, slangasek: I'm still not entirely sure how to work with /etc/ on phablet; my gut feeling is that we should declare /userdata the new /etc there, and store the flag file there (and have the upstart job or whoopsie check both /etc/ and /userdata)
<pitti> ogra, stgraber: ^ would that be reasonable?
<infinity> pitti: You should treat /etc the same way you should on a proper UNIX system.  It's for root's configuration.
<pitti> s/root/global/ (in the sense of "not per-user")
<infinity> pitti: And since we have a readonly root, and no root configuration, whatever you're doing is either runtime configs (/var or some approximation) or user configs (/home or some approximation), both of which probably map to "userdata" in an Android layout.
<pitti> but as we made it readonly, it doesn't really do that any more
<pitti> infinity: /var is r/o as well, though (modulo some explicit exceptions)
<infinity> pitti: No, /etc isn't for "global" configs even, as readonly root is perfectly valid at runtime on any UNIX system.  Not sure when people decided this wasn't true.
<pitti> i. e. /not-quite-var
<infinity> pitti: So, any time someone says "we're storing runtime configs in /etc and now we can't", the real question here is "why were you?"
<infinity> pitti: Pretty much only the packaging system should touch /etc (or root at a console, by hand), but never a runtime configuration thingee, in an ideal world.
<pitti> infinity: I think especially files in /etc/default/ have a very good justification; how else would an admin change some behaviour on a global scope? (default keyboard, locale, whether or not to upload crash reports, timezone, whatnot)
<infinity> (I realise we violate this all over the place)
<pitti> I heavily disagree, but oh well, it's Sunday evening and I'm about to AFK again ..
<pitti> there needs to be some place to put this kind of config, and that has been /etc/ in the past few decades
<pitti> we now apparently want that to be something else, but the whole archive won't magically adjust to that :)
<infinity> People faught hard in Debian for readonly /etc, even coming up with strange things like resolvconf (which we now ship by default).
<infinity> Arguing that it should be readonly, except not when you want to write to it, doesn't quite work. :)
<pitti> I'm not arguing that it should be r/o in the first place :)
<infinity> True.  But most of it is happily r/o-capable.
<pitti> we shoudl eliminate all the crap in /etc/ which isn't configuration
<pitti> infinity: that's just because a lot of stuff in there should never be there
<infinity> Perhaps /etc/default should itself just be bindmounted elsewhere in an r/o-/etc config.
<pitti> /etc/init.d, /etc/init/, /etc/hosts, and what not
<pitti> or almost all of /etc/dbus-1/
<pitti> anyway, langpacks uploaded and all accepted, builders are busy
<pitti> I'll move allspice back to amd64 duty tomorrow morning
<pitti> good evening everyone!
<cjwatson> i386 can have roseapple too unless any amd64 builds materialise.
 * cjwatson prefers nice short queues
<c_korn> hello, a question regarding multiarch. on my build server running 12.04.3 I try to build a package of a game with a precompiled i386 executable for ubuntu 13.10 (using a schroot). sbuild fails however: sbuild: warning: can't parse dependency libogg0:i386 . I have set multiarch-support as Pre-Depends. what am I doing wrong here? (sbuild version: 0.62.6-1ubuntu2)
<FliesLikeABrick> hi all - http://ipv6.torrent.ubuntu.com/ the IPv6-only tracker for ubuntu seems to be broken, all of the torrent links yield 403/forbidden
<FliesLikeABrick> who is the right person to report that to?
<FliesLikeABrick> said more concisely: who maintains the official ubuntu torrents/trackers?
<infinity> FliesLikeABrick: You probably want #canonical-sysadmin, though I wouldn't count on much activity there until Monday.
<FliesLikeABrick> thanks infinity, will head over there tomorrow
<cjwatson> c_korn: dependencies on *specific* foreign architectures aren't permitted by the multiarch spec (https://wiki.ubuntu.com/MultiarchSpec).  You probably want to just build the package as a normal _i386.deb with plain libogg0 etc. dependencies (preferably generated by shlibdeps), and let users install it using multiarch
<benishor> Hi all. I upgraded today from 13.04 to 13.10 and ran into the following issue: I have a simple opengl + freeglut3 program that compiles just fine, but at runtime yields:  Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
<benishor> can anybody help me out with this please? it seems to be triggered by having glut linked
<benishor> here's the output of strace: http://hq.scene.ro/strace.txt
<benishor> and here's output from LD_DEBUG=all http://hq.scene.ro/ld_debug.txt
<benishor> same program was running ok on 13.04. any clues on what can I do to fix this?
<c_korn> cjwatson: ok, so I change the Architecture from any to i386? or just let it fail to compile on amd64? do I need to set Multi-Arch ?
<cjwatson> c_korn: If it's i386-only, Architecture: i386 is fine.  I wouldn't set Multi-Arch
<cjwatson> c_korn: Alternatively, you might look at how skype is packaged in partner
<c_korn> cjwatson: the skype package just has "Architecture: i386 amd64" and depends on skype-bin which has "Architecture: i386" and "Multi-Arch: foreign"
<cjwatson> Right, that's the alternative approach
<cjwatson> The i386-only executable bit is in skype-bin
<cjwatson> I think that was mainly in order to support upgrades from pre-multiarch versions
<c_korn> so the (empty) skype package exists so you can just sudo apt-get install skype on amd64 without having to specify :i386 because it pulls skype-bin from i386 because of Multi-Arch: foreign?
<infinity> apt-get install skype-bin would work without :i386 anyway, since it doesn't exist on amd64.
<infinity> That layout was purely to support upgrades from series' where there used to be a skype:amd64 package.
<c_korn> hum, so just one i386 package without setting multi-arch should be enough for 13.10 ?
<c_korn> ah, ok
<cjwatson> If you don't have to do that, then I think you can just have a single package with Architecture: i386 and you don't need to bother with M-A (unless you're expecting dependencies from other-arch packages on yours)
<c_korn> hum, I cannot imagine that another package has a dependency on a game
<cjwatson> Though Multi-Arch: foreign isn't wrong as long as it exports only architecture-independent *interfaces*
<cjwatson> (execing a binary counts as such, generally)
<c_korn> ah, so M-A: foreign is wrong for a library which has specific i386 and amd64 symbol files?
<infinity> Libraries should be packaged to be MA:same or not MA at all.
<c_korn> hum, ok
<infinity> And binaries where the expected result differs per arch can't be foreign.
<cjwatson> https://wiki.debian.org/Multiarch/Implementation
<cjwatson> infinity: Right, hence "generally" :)
<cjwatson> But you're right to call out that case
<cjwatson> Basically Architecture is about the implementation and Multi-Arch is about the interface
<cjwatson> to oversimplify
<c_korn> thanks, bookmarked that site.
<infinity> Anyhow, in the case of a game that builds on a single arch, foreign would be quite appropriate, on the off chance that someone else wanted to make a "all-the-cool-games" package that depended on it.
<infinity> But if that seems unlikely to happen, no MA is fine too. :P
<cjwatson> I'm all for the whole archive ending up multiarch-tagged at some point
 * infinity nods.
<c_korn> btw, is it /usr/lib/${DEB_HOST_MULTIARCH}/games now ?
<cjwatson> /usr/lib/${DEB_HOST_MULTIARCH}/games/ seems like an odd path.  Aren't the executables normally in /usr/bin/games/ (which hasn't changed with multiarch)?
<c_korn> the executable needs to be in the same dir as its game data. so I cannot put it in /usr/games but place it in /usr/lib/... and make a symlink into /usr/share/games . then there is a script in /usr/games which just starts the exe (via symlink) in /usr/share
<infinity> c_korn: Are you sure that you can't just get away with the cwd being the data dir?
<c_korn> hum, I can give it a try. but assuming it does not work. where should I put the binary ?
<infinity> ie: have your /usr/games/bin/foogame wrapper do "cd /usr/share/games/foogame && /usr/bin/games/foogame.real"
<infinity> If they have to live together, then /usr/lib/foogame seems reasonable for both data and game binary.
<infinity> And then the wrapper that calls it.
<cjwatson> Anyway: things that aren't Multi-Arch: same don't need to have $DEB_HOST_MULTIARCH in their paths, generally.
<cjwatson> Since they by definition don't need to be coinstallable.
<infinity> c_korn: I'm assumiing this is a binary blob you don't have source for?  Cause if you have source, the answer is "fix it to look for its data in /usr/share".
<c_korn> yeah, if I had the source I would fix it like that
<c_korn> infinity, cjwatson: thanks for your help. the whole M-A is more clear to me know. I will read the spec.
<noobster> Hi all! I am having a issue on a new install of 12.04 server x64 trying to mount a NFS mount from another 12.04 server x64. The mount in fstab mounts with no errors, but when I try to copy data onto it it freezes?? I know the nfs-server is running fine because I have a mount in ESXi5 for ISO and caqn copy a 700MB 12.04 iso to that datastore in 10 sec. Any thought on howto troubleshoot?
<noobster> it doesn't crash te whole machine cause I can ssh into the box but can not run df, ls or du
<noobster> here is the syslog error... http://pastebin.com/upF3TCHd
<noobster> 3.2.0-54-generic x64
<xnox> ev: can I build whoopsie without valgrind?
#ubuntu-devel 2014-10-06
<pitti> Good morning
<pitti> cjwatson: add systemd to minimal> TBH I don't understand the purpose -- it's not necessary in e. g. a schroot, and dependencies should do the rest
<pitti> cjwatson: we still haven't discussed what we do with the "init" metapackage; if we are going to adopt it, we should IMHO seed this and only this instead
<pitti> doko_: RAM on autopkgtest machines> 1 GB by default, 4 GB for large packages like eglibc, libo, linux
<doko_> pitti: ahh, how can this be raised?
<doko_> python2.7 assumed >= 4GB on amd64 systems
<pitti> doko_: I'll just add a little config snippet; 3.4 too?
<pitti> doko_: 2.7's test currently succeeds; did you add a workaround for that which you want to drop?
<doko_> pitti, sure. no, reverted the upstream patch
<doko_> can you re-upload after the reversal?
<doko_> will be online again tonight
<pitti> doko_: config pushed, next 2.7 run will have 4 GB
<pitti> doko_: sorry, reupload what?
<pitti> doko_: oh, you mean revert https://launchpad.net/ubuntu/+source/python2.7/2.7.8-9ubuntu1 ? sure, can do that
<pitti> doko_: btw, we can only set that for x86, ppc64el and armhf machines just don't have that much RAM; for that the test should be fixed
<pitti> doko_: uploaded
<doko_> sure
<doko_> thanks
<ari-tczew> pitti, bdrung, tumbleweed: about script syncpackage: it's not possbile to sync some packages, seems to be a reason of FFe. e.g. syncpackage mugshot - http://paste.ubuntu.com/8505156/ - looks fine and I should get an e-mail about sync processed, but I didn't get it. There is no that synced package on Launchpad, as well. is it a bug, or everything is fine?
<doko_> ari-tczew, https://launchpad.net/ubuntu/utopic/+queue?queue_state=1
<darkxst> pitti, hey, do you know if accountsservices sets LANG prior to display manager firing up?
<pitti> darkxst: "set" where? the system default locale is supposed to be in /etc/default/locale, and DMs are supposed to read that
<ari-tczew> doko_: is it autoblocked by bot?
<pitti> ari-tczew: we are in pre-release freeze
<pitti> ari-tczew: thus uploads of all packages that are in any of a derivative get caught in unapproved for release team review
<darkxst> pitti, gdm (3.14) is overriding LANG with the value read from accountsservies, which on Ubuntu breaks badly
<darkxst> I've disable that, but is it correct to assume, LANG is fine at that point
<pitti> darkxst: oh, you mean for the started session, not for the DM UI itself
<darkxst> pitti, yes for the started session
<pitti> darkxst: yes, if you can talk to accountsservice the language should be correct
<pitti> it just reads some config files
<ricotz> darkxst, hi, i reverted that in my earlier snapshot too, but i am suprise it didnt hit me this time, meaning ~uptoic1 works here
<ricotz> ~utopic1 ;)
<ricotz> pitti, hi
<pitti> hey ricotz, wie gehts?
<darkxst> pitti, no, Ubuntu accountservices only store the language (en_US) not the full locale (en_US.UTF-8) as needed for LANG
<ricotz> pitti, danke gut, ich hoffe dir auch! :)
<darkxst> ricotz, I don't see how it could work when it ends up LANG="en_US" or what not
<pitti> yeah, that value is broken
<darkxst> pitti, accountsservice is broken?
<darkxst> I always though ubuntu patched that compared to other distros
<ricotz> darkxst, no idea, but it didnt happen this time LANG is correctly set to de_DE.UTF-8
<pitti> darkxst: not to my knowledge (but it's been a long time since I touched it)
<pitti> my workstation has
<pitti> ANG=de_DE.UTF-8
<pitti> GDM_LANG=de_DE
<pitti> LANGUAGE=de_DE
<pitti> (forgot to copy the first "L", sorry)
<pitti> which looks correct
<ricotz> pitti, it is related to gdm 3.14
<ricotz> darkxst, i guess you are running the complete set of gnome3-staging
<ricotz> (additionally g-s and mutter git master)
<darkxst> pitti, lightdm seems to set LANGUAGE with the value from accountsservice
<darkxst> and there are horrible hacks in g-c-c/u-c-c to deal with that also
<darkxst> ricotz, just gnome3-staging, but its unrelated to g-s and mutter
<darkxst> ricotz, if gdm doesn't have a saved_language it falls back to querying setlocale for it
<darkxst> but if there is a saved_language (which is a direct copy of what comes form accountsservices that will alway be used
<darkxst> I think I will just leave it as it now, but if further bugs pop up, will have to teach gdm about Ubuntu's patched accountservice
<darkxst> g-c-c won't be a probablem we explicitly set the correct LANG there
<mardy> Laney: hi! A hopefully quick packaging question: I now have a package which contains an application + a QML module
<mardy> Laney: maybe in the future I'll split the QML module out, but not now
<mardy> Laney: in the debian/control file, should I add a "Provides: qtdeclarative5-online-accounts-plugin1.0" (this is the module name), even if that package does not exists=
<mardy> ?
<mardy> Laney: my goal is that other packages could start depending on that
<Laney> hi mardy, I guess you could do but note that Provides don't work with versioned relationships so Depends: qml-blah (>> 1.0) won't get your package.
<Laney> Also there are more Qtish people like mitya57 and Mirv who could probably give more specialised advice here
<mitya57> mardy: yes, provides will be nice, but please use the new naming scheme (qml-module-foo)
<Laney> (FYI I think the package naming scheme is more like qml-module-foo now)
<Laney> ha
<Laney> I was just checking the UITK and that hasn't been renamed
<Laney> did we not go and update existing packages?
<mitya57> That is tracked in bug 1342031, I think
<ubottu> bug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,Triaged] https://launchpad.net/bugs/1342031
<Laney> 'kay
<mardy> Laney: thanks a lot!
<mardy> Mirv: hi! What is your opinion? ^
<Mirv> mardy: so you have a binary package that provides both QML module and something else? if nothing depends on "qtdeclarative5-online-accounts-plugin1.0", yes please use qml-module-online-accounts1.0 for example (but that depends on the exact installation location of the QML module)
<mardy> Mirv: the module import path is "Ubuntu.OnlineAccounts.Plugin 1.0"
<Mirv> mardy: so eg. if your install path is /usr/lib/*/qt5/qml/Ubuntu/OnlineAccounts.1.0, then the package name would be qml-module-ubuntu-onlineaccounts1.0
<mardy> Mirv: OK, there's a ".Plugin" more, so I guess qml-module-ubuntu-onlineaccounts-plugin1.0
<Mirv> mardy: I think you might want to drop the ".Plugin", nothing else uses such, they are all loadable QML modules
<Mirv> mardy: most of the new naming is explained in https://launchpad.net/bugs/1342031
<ubottu> Launchpad bug 1342031 in ubuntu-system-settings-online-accounts (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,In progress]
<Mirv> although Ubuntu's specialty is using the version number so that multiple versions of the same module could be co-installed
<Mirv> upstream doesn't use those
<mardy> Mirv: it's a bit different here, the "plugin" does not refer to the fact that this is a QML module; it's really part of the API name (it's an API for developing _plugins_ for Online Accounts)
<Mirv> mardy: ah! :)
<Mirv> mardy: then it makes sense, but probably the install dir should be Ubuntu/OnlineAccounts/Plugin.1.0 then?
<mardy> Mirv: we have Ubuntu.OnlineAccounts.Plugin and Ubuntu.OnlineAccounts.Client (and I'll also remove this module in the process)
<mardy> Mirv: yes, that's the install dir
<Mirv> mardy: ok, then your suggestion was completely correct, thanks!
<mardy> Mirv: actually, it's just Ubuntu/OnlineAccounts/Plugin, with no version number
<Mirv> mardy: if you do not install into versioned directory, you may not be planning on co-installable multiple versions and you shouldn't used "1.0" in the package name either?
<mardy> Mirv: yes, I think that any future version will be compatible, so I don't need the version number
<Mirv> ok
<apw> are we aware the screensaver in utopic stopped working completely ...
<pitti> WFM; in fact, after suspend I get both the old gnome-screensaver layout and afterwards the lightdm layout (sometimes)
<apw> pitti, so you get screen saver if you just sit an wait for it; more than one of us has found the blanking and locking there has stopped
<pitti> apw: ah, I'm not using that, so cannot say
 * pitti tries
<apw> but why would you get gnome-screensaver now?  we don't use that any more
<pitti> apw: I take it you verified that locking is actually enabled in settings?
<apw> pitti, yep, double checked, because the unity update rebound my keybindings back to the default; because that is polite
<pitti> I changed it to lock after 30 s, and nothing happens indeed
<pitti> (but without disabling the screen)
<pitti> I'll now try with switchign off screen after 1 min and locking after 30 s
<apw> pitti, yeah that is the config i have enabled now for testing ...
<apw> fthis is filed as bug: #1377847
<pitti> apw: confirmed here, nothing happens
<pitti> this is a fresh utopic install from yesterday here
<pitti> (with my ancient config, though)
<apw> pitti, that is good info for the bug :)
<ubottu> bug 1377847 in unity (Ubuntu) "unity screen saver no longer blanks nor locks automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1377847
<pitti> apw: confirmed with a fresh account, followed up
<apw> pitti, good thought
<pitti> seb128: peux-tu voir Ã  bug 1377847 ?
<ubottu> bug 1377847 in unity (Ubuntu Utopic) "unity screen saver no longer blanks nor locks automatically" [High,Confirmed] https://launchpad.net/bugs/1377847
<pitti> seb128: ou plÃ»tot, quelqu'un d'Ã©quipe du bureau :)
<seb128> pitti, hey, that's one for bregma/Trevinho rather (unity team), but yeah I can ping them about it
<seb128> or maybe it's due to the g-s-d/gnome-desktop/u-s-d update
<seb128> Laney, ^
<pitti> seb128: cheers
<pitti> seb128: I'm not sure how much we still use gnome-screensaver (we still install it by default, and I sometimes see it)
<pitti> seb128: is that still involved at all, or does unity itself do everything now?
<seb128> pitti, I'm on vac today, just ran IRC to have a look at the backlog, I can look at it more tomorrow if nobody picks it up before that
<pitti> seb128: after suspend I still see g-s-s (and then unity, i. e. entering password twice), so something still triggers it at least
<pitti> seb128: ah, cheers
<pitti> seb128: not that urgent, but I figure this shoudl be fixed for the release
<seb128> pitti, I don't think we use g-s, we keep it for a11y iirc since the unity lock screen is less accessible
<seb128> sure should be
<LocutusOfBorg1> cjwatson, sorry, about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659734
<ubottu> Debian bug 659734 in xfonts-scalable-nonfree "xfonts-scalable-nonfree: use dh_installdeb maintscript support" [Wishlist,Open]
<LocutusOfBorg1> Applying this patch gives me a lintian error with "you should build-depend from debhelper, even if you only build arch independent packages"
<LocutusOfBorg1> so I didn't apply that part
<LocutusOfBorg1> is that ok for you? (I would like to request a sync)
<Laney> pitti: seeing two prompts sounds like a unity/gnome-screensaver bug, please file it and ping Trevinho to look
<Laney> the other thing may be gnome-desktop3 fallout
<Laney> darkxst: looks like org.gnome.SessionManager.Presence is broken by IdleMonitor breakage ?
 * Laney tries reverting that change
<darkxst> Laney, what is broken exactly?
<Laney> idle timeout screen locking in unity
<Laney> yes, now I have a locked screen
<darkxst> Laney, Presence and IdleMonitor arent the same thing are they
<Laney> IdleMonitor drives Presence no?
<darkxst> Laney, oh yeh, that would make sense
<Laney> yeah ...
<darkxst> do so gnome-desktop probably trying to call mutter dbus api for idle monitor
<cjwatson> LocutusOfBorg1: that part of the patch was essentially resynchronising with an error introduced by the previous NMU, I think; keeping debhelper in Build-Depends rather than Build-Depends-Indep is fine, but make sure that you do so in debian/control.in so that debian/control can be correctly regenerated
<LocutusOfBorg1> yes of course
<LocutusOfBorg1> I used meld to look at both packages
<LocutusOfBorg1> they are fine now :) thanks for explaining, I don't want to comment on the bug since you are here :)
<pitti> cjwatson: is there some way of telling ssh to not block on background processes to terminate?
<pitti> cjwatson: sometimes tests spawn things like dbus-daemon or other daemons when you run them through ssh, and then ssh never finishes
<pitti> $ ssh -o StrictHostKeyChecking=no -o CheckHostIP=no localhost -- "bash -ec 'sleep 5 & disown; echo done'"
<pitti> ^ reproducer
<pitti> I didn't find something appropriate in ssh_config nor google :(
<pitti> (just the same question)
<pitti> this doesn't happen with similar "remote auxverbs" like schroot, chroot, or lxc-attach
<rbasak> pitti: does "-n" help?
<rbasak> That's my usual first attempt when ssh has oddness to do with that kind of thing.
<pitti> rbasak: no, it doesn't
<pitti> (above reproducer is harmless and shoudl work everywhere; you can replace localhost with something else, of course)
<pitti> my first guess is that it's got something to do with the background process still using ssh's PTY
<cjwatson> pitti: -f sort of
<cjwatson> though that exits even earlier
<pitti> cjwatson: yeah, then I don't get proper stdout/err from the command
<pitti> nor an exit code
<pitti> and the ssh command still lingers on
<pitti> -T also doesn't help (to disable PTY allocation)
<apw> pitti, i assume yout want the echo done output but not the output of sleep 5
<cjwatson> ssh -o StrictHostKeyChecking=no -o CheckHostIP=no localhost -- "bash -ec 'sleep 5 </dev/null >/dev/null 2>&1 & disown; echo done'"
<cjwatson> works properly
<apw> pitti, so i think you just need to redirect stdin,out,err for that
<cjwatson> apw: snap
<apw> what he said
<cjwatson> this is essentially ssh observing that, well, you asked for stdin/out/err and something still has them open
<cjwatson> so get all your semantics in sync
<pitti> apw: right
<pitti> hmm
<pitti> NB that the "sleep 5; disown" is just a simple reproducer; in real tests I don't have control over that
<pitti> e. g. upstart's tests leak an init process and 4 dbus-daemons
<cjwatson> right so disconnect those from stdin/out/err
<cjwatson> or rather, get the tester to do that, IMO
<pitti> I do redirect the entire output of the test command, but I think I haven't redirected stdin; that might be it
<cjwatson> ssh keeps channels open until they are "dead"
<cjwatson> i.e. nothing has them open any more
<pitti> ok, so since I can't control what a test does, but I still want its stdout/err, I think this doesn't help; I also played around with putting a pkill -g into trap, but that ruins the exit status
<rbasak> Would it be reasonable to fail a test that leaves stuff running that is still connected to stdin/out/err when it finishes?
<rbasak> Or to kill any processes that still do?
<apw> pitti, ah it is uncontrolled children that tests start.  hmmm.
<pitti> rbasak: that's what happens right now (it hits the test timeout, kills everything, and fails)
<apw> pitti, so, how about disconnecting the two, shove the tests output into a fifo
<pitti> of course we can hunt down tests that do that, but it's going to be a lot
<apw> pitti, and read that and emit that into your stdout, until the thing exits, then simply stop doing it, and exit
<rbasak> pitti: I mean automatically. With lsof for example, but preferably something less hacky?
<pitti> apw: yeah, I guess I'll need to add even more tee's and redirects into the already complex plumbing :)
<pitti> but at least now I know what it's waiting for, so thanks all
<apw> pitti, running tests from other people sucks...
<cjwatson> pitti: all the relevant processes should be in the same control group, I think
<cjwatson> and you can preserve the exit status in a trap easily enough
<cjwatson> save it in a variable, exit $thing ...
<pitti> *nod*
<apw> as long as you don't kill yourself by accident :)
<cjwatson> heh, yeah
<pitti> right now I'm roughly doing test_program 2> >(tee -a /tmp/my_test_stderr >&2) > >(tee -a /tmp/my_test_stderr);
<pitti> so that I see live output and also keep their stdout/err in files (as test artifacts)
<pitti> I suppose I could turn this around, only write to files, and tee those in the outside for live output
<pitti> it's not as nice due to buffering not being by-line any more, but it shoudl avoid that
<pitti> err, second my_test_stderr is obviously my_test_stdout
<pitti> ah no, I can't tee them "outside", as that "outside the test" is still "inside ssh"
<pitti> pipeline plumbing is hard :)
<apw> pitti, as you are teeing their output anyhow, they will be "not connected to a terminal anyhow" right?  and it is only tail or whatever on that log, its output mode which defines buffering
<apw> or as i say if you tee them into a fifo you may keep the current buffering mode
<pitti> apw: right, the actual test program will only have the fifos as their stdout/err, but the tees use ssh's
<pitti> apw: so indeed redirecting to the files *only* and then tee'ing them in background processes should work better
<pitti> err, not tee'ing then, just cat'ing
<pitti> cjwatson, apw, rbasak: thanks for your input! I have some things to try now
<apw> pitti, tailing, but you may need to keep tee in the loop, teing to a fifo, and reading that in ssh, to keep the buffering the same
<pitti> so AFAIUI the main thing to avoid is to connect the test (and all of its subprocesses) to ssh's stdin/out/err
<pitti> which should already be the case due to the redirection to tee
<apw> yep, that is your killer
<apw> pitti, well the issue is tee will propogate the issue, ie if tees input survives, then its connection to its output survives, whcih is sshs channel so that stays open
<pitti> test_program </dev/null 2> >(tee -a /tmp/my_test_stderr >&2) > >(tee -a /tmp/my_test_stdout);
<pitti> AFAICS test_program shoudl not see any of ssh's pipelines? (and this doesn't work, I added the </dev/null)
<pitti> apw: ah, of course
<pitti> so I just need to kill the tees after test_program exits
<apw> so you either need to hard kill both tees if you can find them
<apw> or add a new fuse in the gap, which is what i proposed the fifo for
<pitti> pkill -g $$ tee?
<pitti> yay, that by and large works (just need to properly handle the exit status)
<pitti> bazinga!
<pitti> apw: thanks so much, I was totally missing the "backpropagation" of stdout liveliness through tee
<apw> pitti, great :)
<rbasak> pitti: I'm just reviewing this thread: https://lists.ubuntu.com/archives/technical-board/2014-July/001972.html
<rbasak> pitti: I think there's a little confusion there that I've only just realised.
<rbasak> There were two things we requested not too far together in time.
<rbasak> 1. An MRE, which was granted, and which we've excercised. But this wasn't this thread - there was another thread.
<rbasak> 2. A larger exception for pushing new upstream feature releases as SRUs. This is what this thread was about.
<rbasak> But in https://lists.ubuntu.com/archives/technical-board/2014-August/001992.html you approved the MRE, but not the larger exception.
<rbasak> And so the larger exception was inadvertently left hanging I think.
<rbasak> pitti: are you satisfied with the QA situation to grant the more major exception on the list, please?
<rbasak> Or does this need to go to a TB meeting?
<pitti> rbasak: ah yes, it was always meant to be "new versions", not just microreleases
<pitti> rbasak: we just don't have a separate list for that
<pitti> rbasak: wiki page updated
<Saviq> ogra_, hey, you told mzanetti it's not good to do dist-upgrade when testing a silo, can you explain?
<ogra_> Saviq, it isnt good to do dist-upgrade at all ... it will fail on many cases where packages have writable bind mounts for files ...
<apw> pitti, you used to be jockey king, where did the functionality from that go ... is it ubuntu-drivers-common ?
<pitti> apw: right, the logic is in u-d-common, the UI in software-properties-gtk
<Saviq> ogra_, oh well, yeah, but how do we test silos otherwise? ;)
<ogra_> Saviq, robrus ci tools from phablet-tools have some work-arounds for this (ignoring sources.list and only pulling from silos etc) with which you *can* use dist-upgrade ... by default you shouldnt though
<Saviq> ogra_, yeah, I'm generally using robru's tool, it failed for me today though
<ogra_> Saviq, for packages known to cause issues .... like lxc-android-config, we have instructions how to install them from recovery
<apw> pitti, and does it still automatically offer things like jockey used to do; like bcmwl
<ogra_> (where you have no bind mounts)
<Saviq> ogra_, yeah, ok, so it's more about dist-upgrade when it upgrades more than just the silo, if we're testing just unity8 (so yeah, maybe not dist-upgrade but install the relevant packages), it should be fine to use apt?
<ogra_> Saviq, technically even making the image permanently writable will already taint your tests
<ogra_> Saviq, yeah, that should be fine
<Saviq> ogra_, sure, once we get images from silos things will be better again ;)
<ogra_> yeah
<ogra_> that will solve everything :)
<Saviq> ogra_, and I'm flashing fresh before installing the silo every time
<pitti> apw: yes, it should; there's "ubuntu-drivers autoinstall" (which we run in the installer), and you  should see drivers in software-properties-gtk
<pitti> apw: I don't have any on my laptop, but you can test it with /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk
<pitti> (that pretends to have a broadcom wifi, an nvidia, and an ati card)
<apw> pitti, thanks
<rbasak> pitti: thanks!
<X1> ey bros
<X1> i have the known problem/bug with mounting cryptswap at the startup, lubuntu 14.04, it says,  dev/mapper/cryptswap1 not ready or present, found many threats to that topic, but nothing really helped, someone has a link to solve the problem, or can help me? would be nice!
<bdmurray> ted: what would put the first key in this crash on the error tracker? https://errors.ubuntu.com/oops/f10688a8-4ccc-11e4-b8ba-fa163e707a72
<ted> bdmurray, Not sure what you mean by first key
<ted> bdmurray, Oh, you mean the /usr/bin/media-hub-server key?
<bdmurray> ted: right, that seems wrong
<ted> Hmm, yeah. Not sure, seems like a parsing bug.
<ted> Like that's part of the stack trace.
<bdmurray> ted: it looks like the SAS to me
<ted> Sorry, yes.
<ted> bdmurray, My device is flashing right now, did you see if media hub has an apport hook?
<bdmurray> ted: it doesn't look like it, so its probably whoopsie
<bdmurray> ted: its not a recoverable problem so its not that either
<ted> bdmurray, Yeah, wonder if it's been a bug that it's had for a while, but got filtered out by the key filter we removed a while back.
<smoser> anyone seeing screensaver not dimming screen on utopic or is it just me
<smoser> ie, i leave laptop for night, and its unlocked and screen on in the morning.
<pitti> smoser: bug 1377847
<ubottu> bug 1377847 in gnome-desktop3 (Ubuntu Utopic) "unity screen saver no longer blanks nor locks automatically" [High,Confirmed] https://launchpad.net/bugs/1377847
<smoser> pitti, thanks.
<Riddell> Laney: you've been spotted in real life 17:48 < Helen> when i was in the pub (in nottingham) on friday one of the bar staff was wearing a debian conference tee shirt from portland.  think she said her boyfriend works for ubuntu
<Laney> lolz
<Laney> who is that?
<infinity> Someone wears that shirt in public?  To work?
<Riddell> Laney: just a member of the quaker geek cabal keeping an eye on things, you have to watch out for the quiet ones
<Laney> She told me someone was asking about it
<Laney> I had the person killed, but must have missed one. Thanks for the info
<maswan> Hey, I wear debconf shirts to work. I prefer giving talks to people stuck in the centos/sl-swamps too. :)
<Riddell> a debian t-shirt is a sign of quality bar staff in any bar worth your money
<Laney> infinity: You mean you don't just pull the first t-shirt from the pile every morning?
<infinity> Laney: I give careful consideration to not looking like a tool. :)
<maswan> They are also appropriate for gala dinners, IME.
<Laney> ouch
<smb> Can someone check the xen package in Utopic. Somehow the publishing history claims it should be moved to release but its not there (xen-4.4.0-0ubuntu8)
<cjwatson> smb: fixed, as per #ubuntu-release, just in case anyone only sees scrollback from this channel
#ubuntu-devel 2014-10-07
<Logan_> the Debian BTS makes me sad
<Noskcaj> Logan_, Where's the problem in a website from the 90's that can only be controlled by email? ;)
<ScottK> It does it's job well enough and has features that LP for all it's web shininess doesn't.
<Logan_> ScottK: it often fails for me
<ScottK> Do you use bts?
<Logan_> no, but I probably should
<Logan_> but control@bugs.debian.org is so unpredictable sometimes
<Logan_> like, I tried to merge a bug in src:package with a bug in package
<Logan_> so first I did: affects bug2 src:package
<Logan_> and then I merged
<Logan_> but it said that bug2 affects package, not src:package
<Logan_> so then I did: affects bug1 package
<Logan_> and tried to merge
<Logan_> but it said that bug2 affects src:package, not package
<Logan_> and then I cried
<infinity> Logan_: You probably wanted reassign, not affects.
<Logan_> fffff
<Logan_> I've even used that in the past
<Logan_> ugh
<Logan_> if there were a GUI, I wouldn't have confused the two :(
<infinity> One could write a GUI that effectively just pinged commands off the control bot.
<infinity> But the bts CLI tool is pretty friendly, from what I hear.
<infinity> (I've been using control@d.o for so long that I don't really care)
<infinity> @b.d.o, even.
<udevbot> Error: "b.d.o," is not a valid command.
<infinity> udevbot: SUPER HELPFUL, THANKS.
<udevbot> Error: "SUPER" is not a valid command.
<Logan_> :3
<ScottK> Logan_: Try bts.  It makes it a lot easier.  Plus man bts is a lot handier documentation then a web page.
<Logan_> will do :P
 * infinity goes to bed at a sensible hour for the second night in a row, and wonders if this will last...
<infinity> Fingers crossed.
<sarnold> for "yes" or for "no"? :)
<infinity> sarnold: I'm hoping for yes, but history isn't on my side here.
<sarnold> infinity: aha :) good luck
 * ScottK notes he's in a later timezone than infinity and figures he's missed sensible.
<ScottK> Best go to be at an unreasonable hour then.
<pitti> Good morning
<pitti> slangasek: bug 1377698> ack, will fix ASAP
<ubottu> bug 1377698 in util-linux (Ubuntu) "/etc/default/rcS: UTC=no is being ignored" [High,Triaged] https://launchpad.net/bugs/1377698
<zyga> pitti: hey :)
<pitti> hey zyga, how are you?
<jdstrand> cjwatson: hey, I'm trying to figure out some corruption that sometimes happens in /var/cache/apparmor and /var/lib/apparmor/profiles and I started thinking about click-system-hooks and apparmor upstart job interactions
<jdstrand> cjwatson: click-system-hooks.conf has 'start on filesystem' and apparmor.override has 'start on starting lightdm'
<jdstrand> cjwatson: they are both tasks
<jdstrand> cjwatson: aiui, both could end up calling aa-clickhook depending on the circumstances (the apparmor upstart job may run aa-clickhook -f)
<cjwatson> You should probably have a lock or something.
<jdstrand> cjwatson: so, that is one idea. I also wondered if the upstart jobs should change in some way
<cjwatson> jdstrand: How would you suggest?  I don't think click-system-hooks can safely move later, and I don't think apparmor.override should be waiting for click-system-hooks.  I'm also reluctant to try to complicate the Upstart jobs for this because that seems fragile.
<cjwatson> jdstrand: And also adding anything more that further complicates the impending transition to systemd seems like a bad idea ...
<jdstrand> cjwatson: I wasn't sure what to suggest, which is why I wanted to ask
<jdstrand> I'll think about the lockfile
<jdstrand> cjwatson: how grumpy will click-system-hooks be if apparmor exited non-zero? where would it be logged, in /var/log/upstart/click-system-hooks.log?
<jdstrand> cjwatson: s/apparmor/the apparmor system hook/
<cjwatson> jdstrand: It will exit 1 and log to /var/log/upstart/click-system-hooks.log.  Life will otherwise go on.
<cjwatson> jdstrand: (In particular, a single hook failing doesn't stop it running other hooks.)
 * jdstrand is trying to decide if it should exit(1) if the lock exists or block
<cjwatson> jdstrand: I think you need to block, because the currently-in-progress run may not be operating on up-to-date input information.
<cjwatson> And if you exit(1) then nothing else might generate the required profiles until the next boot.
<jdstrand> right
<cjwatson> Better to have startup be a bit slower than to be wrong, I think
<jdstrand> I was leaning towards that
<jdstrand> ok, thanks for the input
<cjwatson> np
<zyga> pitti: hey, quick question
<zyga> pitti: what is the best way that a process can reliably confine and kill all the children it has forked?
<zyga> pitti: is the only reliable way to use a control group?
<zyga> pitti: or can this be done in a less complicated way?
<zyga> pitti: the only other thing I've considered is a session (setsid) but I think that's pretty easy to escape
<pitti> zyga: haha
<pitti> zyga: that's the very question that has kept me up yesterday and last night -- https://plus.google.com/u/0/107564545827215425270/posts/bAm9jiYE3JB
<pitti> zyga: you can trivially escape both sessions and process groups (most daemons do that)
<zyga> pitti: I know, I read that :)
<pitti> zyga: ah :)
<pitti> zyga: so, without cgroups you can't (reliably)
<zyga> pitti: right, and I think our focus is the same
<pitti> zyga: for ssh I kill all processes that have an fd open to ssh's terminal
<zyga> pitti: my goal is to also kill test payload leftovers
<pitti> as that's my main concern (stop ssh from hanging)
<zyga> pitti: hmm, there's more and more overlap between plainbox and adt :)
<zyga> pitti: is there a way to ask for a control group without being root?
<pitti> no
<zyga> pitti: nothing we can ask systemd for?
<zyga> pitti: via dbus/
<pitti> zyga: my hilariously hideous patch for unblocking ssh is http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=3f685f54 (you may vomit now)
<pitti> it's ugly as hell, but so far the best I could come up with with normal user privs
<zyga> pitti: interesting
<zyga> pitti: yes, it's not terribly elegant
<zyga> pitti: hmm
<zyga> pitti: sigh, the main target is to reliably test touch but there we don't have systemd at all :/
<zyga> pitti: thanks, this is educative, we may be left with something similar
<zyga> pitti: btw, maybe we could consider merging adt and plainbox later on, we seem to try to do the same thing (setup, execute and teardown a test session) (just a thought)
<zyga> pitti: I won't be able to go to the sprint but I'd like to talk about that one day
<pitti> zyga: yeah, with the autopilot tests that I ran through autopkgtest on the phone I haven't seen any hangs -- apparently our tests are well behaved and don't leak processes :)
<pitti> but in principle this sohuld affect the phone as well; it's an ssh specific problem, not specific to nova or adb
 * zyga was chasing after a few 'leaking' dbus-launch sessions 
<zyga> pitti: well, it's not like adb will care but we'd like to make sure that running a session of N tests, we don't stockpile processes around
<pitti> zyga: I meant autopkgtest's setup script for adb (i. e. running autopilot tests on the phone) vs. nova (running autopkgtests in the cloud)
<pitti> nevermind, was mostly loud thinking
<zyga> pitti: thanks, I'll keep an eye out to autopkgtests
<zyga> pitti: and steal some good ideas you have there :)
<Saviq> pitti, hey, is there a way to apport-retrace click crashes yet?
<pitti> Saviq: no, there isn't
<pitti> Saviq: well, you can manually run apport-retrace on the device of course, but not automatically through LP bugs or errors.u.c.
<pitti> Saviq: (and manually install all necessary debug pacakges)
<Saviq> pitti, well, yeah, that manual apport-retrace is what tsdgeos was trying to do
<Saviq> and got http://paste.ubuntu.com/8513258/
<pitti> Saviq: we have zero support for click packages, implicit dependencies, and system-images so far
<Saviq> Package will never be filled will it?
<pitti> it also doesn't have a core dump
<pitti> presumably that's a .crash which has never been sent through apport-cli, but for clicks that doesn't help either
<tsdgeos> pitti: it does have a core dump
<tsdgeos> or so apport-cli says
<pitti> as there is no Package:/Dependencies: for clicks
<pitti> ah
<pitti> anyway, apport-retrace (or apport reports) won't help you much for now
<tsdgeos> pitti: note the error is "doesn't have some of this things" not "doesn't have any of this things"
<tsdgeos> the only thing missing is actually Package
<pitti> and Dependencies:
<pitti> and apport being able to download and unpack clicks or system images
<pitti> and us not having ddebs for older system images, nor an index for it, etc.
<pitti> the latter is being worked on, but it's a huge project
<pitti> and we haven't really talked at all about apport in a click/system-image world yet
<tsdgeos> ok
<brainwash> pitti: just curious, can I install systemd from unstable? do I have to add the ubuntu delta?
<brainwash> I assume that there will be some problems with 215 or 216 in utopic
<pitti> brainwash: without the Ubuntu delta you'll most probably create some havoc in /usr/share/doc, introduce unsupported udev config files, and break initramfs
<brainwash> sounds great :>
<pitti> brainwash: rather use darkxst's systemd 215 package PPA (not sure where he keeps that)
<brainwash> tim?
<brainwash> the gnome guy?
<brainwash> let me check
<pitti> brainwash: if you want to boot systemd, that's the only thing you need; for booting with upstart you need to rebuild systemd-shim
<pitti> yes
<brainwash> it's a minimal systemd only system
<pitti> brainwash: if it's a throwaway system without complicated "need to wait for this root partition" setup, you can try the debian package
<pitti> brainwash: but don't try this on your desktop workstation, it's rather involved to sidegrade back to the ubuntu version as you need to clean up some conffiles
<darkxst> it's 214 and was unit293's merge who messed up the merge a little, but it works
<brainwash> I'm aware of that
<brainwash> ok, thanks for the info
<brainwash> a ppa with systemd from unstable + ubuntu delta would be quite handy
<darkxst> brainwash, ppa:darkxst/sd214
<brainwash> yep, found that one :)
<darkxst> its missing some of the ubuntu delta though
<brainwash> but it should work, right? someone has actually tested it I'd guess
<darkxst> a few of us have been running it for quite some time without issues, but its never had (nor ever will) get mass testing
<pitti> brainwash: so, as long as you only install that in a place which doesn't need to survive a dist-upgrade and isn't production, that's fine
<pitti> I expect to do a merge with Debian at the end of October, after utopic's release
<pitti> so first thing in V
<pitti> i. e. git rebase -i'ing the Ubuntu branch and fixing the conflicts
 * pitti pats proper VCS packaging :)
 * darkxst still waiting on sjoerd to move pkg-gnome to git ;) that should make things a lot easier ;) 
<doko> cjwatson, bdmurray: please subscribe foundations to the babeltrace bug reports
<cjwatson> doko,bdmurray: done
<apachelogger> pitti: http://paste.ubuntu.com/8514115/ any objections to this? changes PPA to PPAS, appending multiple --ppa arguments to that and then looping in add_ppas to add multiple ppas to the ubuntu-defaults.list
<arges> Trevinho: ChrisTownsend: hey i'm reviewing the upload for libindicator/trusty and there isn't any bugnumber associated with that. Can you fix that and re-upload?
<ChrisTownsend> arges: Hmm, ok.  I wasn't involved in this SRU, but I'll follow up w/ Trevinho and bregma.  Thanks for pointing that out.
<arges> ChrisTownsend: cool np
<bregma> arges, yeah, the ci-train didn't pick up the bug number for some reason, I'll see about fixing it
<arges> bregma: great : )
<pitti> apachelogger: sure, no problem
<brainwash> darkxst: I've encountered a dependency problem, "systemd-sysv : Depends: systemd (= 208-8ubuntu7) but 214-0ubuntu1~utopic9 is to be installed"
<LocutusOfBorg1> hi ubuntu developer, I'm wondering if I can request a sync for a package I maintain directly here rather than filing a bug...
<LocutusOfBorg1> I just updated the copyright file and did a little change in cmake, making it cmake 3.0 compatible
<LocutusOfBorg1> (I also have some other syncs to request, but I still need to work on them)
<pitti> brainwash: well, you have to install all of your built binaries :)
<brainwash> pitti: systemd-sysv is missing in the list of built packages :/
<doko> cjwatson, lintian complains about license-problem-gfdl-invariants errors in Ubuntu. can we just remove this check for Ubuntu?
<brainwash> pitti: it's darkxst's systemd ppa
<pitti> brainwash: ah, maybe he based this off the trusty version then which indeed didn't yet build -sysv
<brainwash> pitti: ah, from the changelog: "Don't build the systemd-sysv package for now."
<cjwatson> doko: It's case-by-case, not a blanket permission, AIUI
<mdeslaur> doko: you regressed my bash security update in utopic
<mdeslaur> doko: oh, wait, no you didn't, sorry
<doko> mdeslaur, how?
<mdeslaur> doko: are you planning on going up to patch -30?
<doko> yes
<mdeslaur> doko: great, thanks
<mdeslaur> I'm going to switch the stable releases to the final upstream patches also
<tvoss> pitti, hallo :)
<doko> mdeslaur, uploaded
<mdeslaur> doko: cool, thanks!
<Saviq> charles, are calendar reminders supposed to work properly yet? I saw your branch for valarm triggers, but reminders here seem to not take timzone into account, that known? I couldn't find a relevant bug
<slangasek> pitti: cheers
<pitti> slangasek: good morning; fix is in -proposed
<charles> Saviq, wrt timezones, that sounds like what I reported in https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1291225/comments/4
<ubottu> Launchpad bug 1291225 in Ubuntu Calendar App "autopilot tests fail when run in UTC+1 timezone" [High,Confirmed]
<Saviq> charles, hmm wonder if it's only for repeating events then
<charles> Saviq, would Mihir be the person to assign 1291225 to?
<charles> that is, dyk how calendar-app is creating those events?
<Saviq> charles, could be, yeah
<slangasek> pitti: hmm, is it?  I don't see util-linux in proposed
<pitti> slangasek: https://launchpad.net/ubuntu/+source/util-linux/2.25.1-3ubuntu2
<flexiondotorg> If I wanted a package syncing from Debian does it have to be in testing or can it be pulled from unstable?
<pitti> flexiondotorg: it can be pulled from anywhere (usually unstable)
<flexiondotorg> OK, I have a few MATE packages that I would really like sycning.
<flexiondotorg> What is the process?
<cjwatson> flexiondotorg: requestsync(1)
<flexiondotorg> cjwatson, Thanks. Installing...
<tzero> are PPA keys supposed to match personal keys? I thought I was following the packaging guide, but apt gripes about unauthenticated packages after `apt-add-repository`ing.
<flexiondotorg> cjwatson, pitti Just out of interest is it possible to requestsync for 14.04?
<pitti> flexiondotorg: no, we don't do that (https://wiki.ubuntu.com/StableReleaseUpdates)
<flexiondotorg> pitti, Interesting. So if Ubuntu MATE earns it official status during the 15.04 cycle there is not prospect of ever releasing an official 14.04.2 version of Ubuntu MATE?
<cjwatson> tzero: Launchpad generates a PPA key for each user the first time they create a PPA.  It would be inappropriate to have your personal key used by Launchpad to sign archives - you'd be relinquishing control of it
<pitti> flexiondotorg: oh, we can SRU into stables, but we don't use syncs for that
<flexiondotorg> SRU?
<pitti> flexiondotorg: technically it would be possible, but not policy-wise; mostly, the version numbers would collide with the development release, and we also don't do wholesale updates, we backport fixes
<pitti> flexiondotorg: stable release update, see the wiki page above
<flexiondotorg> pitti, Thanks.
<flexiondotorg> So, if I have people crying out for a 14.04 version I should probably provide that based on my "build system"?
<slangasek> pitti: ah, there it is - thanks
<slangasek> pitti: so on systemd, is the init script also masked?
<flexiondotorg> pitti, Can you confirm this is correct before I raise any others? https://bugs.launchpad.net/ubuntu/+source/mate-panel/+bug/1378421
<ubottu> Launchpad bug 1378421 in mate-panel (Ubuntu) "Sync mate-panel 1.8.1+dfsg1-1 (universe) from Debian unstable (main)" [Undecided,New]
<slangasek> pitti: (and does systemd avoid the /etc/adjtime nonsense?)
<tzero> cjwatson: hmm, the build log on lp says that it couldn't verify signature. Since I had just created and uploaded that key when the package was submitted, maybe the key hadn't propagated yet. Is it correct that I sign the package source, launchpad verifies it, builds binary packages with the PPA key, and then endusers verify their apt-retrieved files against that PPA key?
<doko> barry, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg   the system-image seed is still incomplete, could you work on the remaining MIRs?
<doko> seb128, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  indicator-datetime should drop the indicator-applet recommendation, or file the appropriate MIRs
<seb128> doko, ?
<doko> seb128, it's an ubuntu-desktop package, so who should I contact instead?
<seb128> doko, it's just that component-mismatch seems buggy
<seb128> indicator depends didn't change for cycles
<doko> looking ...
<seb128> they depends on indicator-applet | indicator-renderer
<seb128> which is provided by unity
<seb128> which is in main
<doko> Recommends: indicator-applet | indicator-renderer
<seb128> yeah
<seb128> what I just wrote
<seb128> unity Provides indicator-renderer
<seb128> which is a | in there
<doko> yes, but then unity needs to be in the first place
<seb128> why?
<doko> err, because the first alternative counts for things like britney, and mismatches, and other stuff
<seb128> you are sure?
<doko> yes
<seb128> I think britney e.g try the second one if the first one is not available
<doko> cjwatson, ^^^
<seb128> as long as one is ok the condition is ok
<doko> afaiu one real package needs to match
<seb128> those indicator-applet | indicator-renderer depends are like that on indicators for cycles iirc
<seb128> that has never been an issue
<doko> no, it was a component mismatch for at least the past two release cycles
<seb128> usually when componant mismatch has such output it's because unity become un-installable on some arch
<doko> jamespage, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  kazoo needs a MIR
<jamespage> doko, it does and its pending security team review:
<jamespage> https://bugs.launchpad.net/ubuntu/+source/kazoo/+bug/1296607
<ubottu> Launchpad bug 1296607 in kazoo (Ubuntu) "MIR: python-kazoo; new taskflow version needs python-kazoo from universe" [Undecided,New]
<doko> jamespage, oops, sorry
<jamespage> doko, np - I think for once server team are actually up-to-date with MIR's
<doko> jamespage, no, https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935  ;-P
<ubottu> Launchpad bug 1108935 in websockify (Ubuntu) "[MIR] websockify" [High,Incomplete]
<jamespage> doko, oh - - that was yesterday - will look
<jamespage> soooo clooosee
<cjwatson> tzero: specifically what build log are you talking about?
<cjwatson> doko: I was working on the indicator-applet mess, please leave it alone :)
<doko> seb128, ^^^
<cjwatson> though I've forgotten what state it's in
<cjwatson> it was https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1367719 but I investigated and determined that it's not a germinate bug after all.  I'll have to reinvestigate though as I didn't keep notes, sorry.  Can't right now as dreadful internet
<ubottu> Launchpad bug 1367719 in germinate (Ubuntu) "germinate (maybe?) fails to detect a closed loop on a package currently being processed" [Undecided,New]
<cjwatson> Oh, I remember, it was actually coming in from Recommends of something in supported-hardware-desktop
<cjwatson> I was considering http://paste.ubuntu.com/8515539/ but infinity wasn't happy with the fragility of that
<cjwatson> doko,seb128: so really, nothing to do with unity
<seb128> cjwatson, ok, thanks, so we can keep the "Recommends: indicator-applet | indicator-renderer", we don't need the first option to be in main?
<doko> cjwatson, I don't understand the diff. isn't that for another component mismatch?
<doko> or is this the first chunk?
<cjwatson> seb128: yes, just leave it
<seb128> cjwatson, thanks
<cjwatson> doko: It's a bit of a "you are not expected to understand this" patch :)
<cjwatson> doko: Some Recommends chain from supported-hardware-desktop (I forget which) is operating in a context where unity and the Ubuntu desktop's default indicator stack aren't seeded, and so it ends up expanding legitimately to the other possible stack
<cjwatson> doko: So the first bit of the patch disables recommends for that seed, and the second fills out some things that go missing as a result
<cjwatson> doko: But this is really a bit too fragile, and I need to figure out a better answer
<doko> ahh
<pitti> slangasek: yes, there's /lib/systemd/system/hwclock.service and service strips off .sh suffixes
<pitti> (that's a no-op just to mask the init.d script)
<pitti> slangasek: there are references to adjtime in the source, I think timedatectl --adjust-system-clock writes it; but I haven't checked in detail
<pitti> sorry, need to leave for today
<pitti> flexiondotorg: LGTM
<tzero> cjwatson: under Package build summary, there's the "Completed builds" section. For each arch, there's a "see the log" link in the results. The URI is https://launchpad.net/~username/+archive/ubuntu/ppa/+builds?build_state=built
<cjwatson> tzero: No, I'm not asking for how to find them in general, I'm asking for the URL to a single example build that you're observing failing
<cjwatson> tzero: I know how to navigate Launchpad in general
<cjwatson> tzero: You said "the build log on lp says that it couldn't verify signature", and I want to resolve that to a specific message in context
<tzero> cjwatson: oh, woops. can I /notice it to you?
<cjwatson> tzero: Can't you just paste the URL here?
<cjwatson> Presumably it's a public build
<tzero> sure, http://goo.gl/L2Czjf
<cjwatson> tzero: Oh, so are you referring to "gpgv: Can't check signature: public key not found"?
<cjwatson> and the line below
<tzero> right
<cjwatson> tzero: OK, so that matters not at all.  The signature on the .changes has already been verified by Launchpad well before it gets to that point, and the build doesn't need to separately verify it; that's just code we haven't made any special arrangements to turn off since it doesn't really matter
<cjwatson> tzero: You sign the upload; Launchpad verifies that signature; the Launchpad build manager dispatches builds from its queue to workers in its build farm and retrieves the results; Launchpad publishes successful builds to archives including PPAs, signing them with the appropriate keys; when end users fetch archive indices they are verified against the appropriate key
<cjwatson> tzero: Binary packages themselves aren't signed, just the index files
<cjwatson> tzero: (But the index files contain hashes of the binary packages, so there's a chain of trust all the way down)
<tvoss> cjwatson, who would be the right person to ask about pkgstriptranslations?
<tzero> cjwatson: cool, that makes sense
<cjwatson> tvoss: pitti
<seb128> tvoss, pitti might have called it a day, if you ask on the channel others might be able to help you
<YokoZar> So I put in a new Wine upload last night and I noticed that the one I put in a few months ago never made it past -proposed.  I believe cjwatson once told me that Wine uploads had to be approved manually because the cross-arch dependency confuses the autotest into thinking it's uninstallable.
<smoser> does this address mean anything special: fe80::5054:ff:fe92:d68
<Ajkthx> they are nuclear launch codes
<sarnold> fe80 is link-local, right?
<smoser> yeah, its link local.
<smoser> os i'm trying to boot a cloud image with ipv6
<smoser> and setting /etc/network/interfaces like this:
<smoser>  http://paste.ubuntu.com/8516509/
<smoser> when the system comes all the way up, it has the above address for eth0
<smoser> anyone have theories on that ?
<smoser> if i log in and
<smoser>  ifdown eth0; ifup eth0
<smoser> then it comes up properly
<geser> smoser: is this the only address on this interface?
<smoser> yeah.
<smoser> http://paste.ubuntu.com/8516541/ <-- ip addr output
<geser> my interfaces file for vmware-image (with trusty) looks similar but also has an ipv4 stance and the ipv6 address gets set up upon boot without problems
<smoser> geser, right. the goal is actually to *not* have ipv4 at all.
<smoser> stgraber, around ?
<smoser> anyone able to make sense of comment 12 at https://bugs.launchpad.net/cloud-init/+bug/1377005 ?
<ubottu> Launchpad bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New]
<smoser> it seems that without ipv4, 'auto' isn't working right.
<geser> smoser: see also bug #1352255
<ubottu> bug 1352255 in ifupdown (Ubuntu) "Impossible to configure network interface with only IPv6 address" [Undecided,New] https://launchpad.net/bugs/1352255
<smoser> geser, thank you.
<slangasek> right, sounds like a duplicate
<slangasek> that is, bug #1377005 sounds like a duplicate of this one
<ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
<smoser> yeah.
<slangasek> smoser: so, my earlier question: what do you get with 'ifdown eth0 && ifup --allow auto eth0'?
<slangasek> this is what /etc/init/network-interface.conf does, and is not the same thing as a plain 'ifup eth0'
<slangasek> this will let us isolate it to ifupdown itself, vs. the boot scripts
<smoser> slangasek, it comes up
<smoser> with the desired address
<slangasek> ok
<smoser> i have to run. thanks for your  help
<tzero> are package.init scripts supposed to be automatically detected and included in a package, or do I have to specify them explicitly?
<tzero> everything I've read seems to suggest the former
<tzero> gpg is also being a PITA
<tzero> moreover, adding "override_dh_installinit: \n \t dh_installinit" shows that it runs after dh_installchangelogs and before dh_perl; without those lines, nothing
<slangasek> tzero: what command are you running, and what do you mean by "nothing"?  posting your source package and/or your build log would help
<tzero> slangasek: I added that override to see where dh_installinit was supposed to show up. Build log is here -> http://sprunge.us/NQfE , and only a configuration file, the binary, and the dh_make generated docs are included in the package
<tzero> ${packagename}.init and ${packagename}.default both exist in the debian/ directory, but neither are included
<slangasek> tzero: well, I would want to see the whole source package to try to debug this.  dh_installinit should be called unconditionally via dh, unless there's something in debian/rules overriding it
<slangasek> tzero: you might compare with the output of 'dh binary --no-act'
<tzero> slangasek: hmm, `fakeroot dh binary` added the files. Could it be my override_dh_auto_configure ? that's the only section in rules except for the default %
<slangasek> well if you posted your debian/rules, I might be able to tell you ;)
<tzero> slangasek: oops, that's here -> http://sprunge.us/gGAN
<tzero> it's not that first hacky sed either :(
<slangasek> tzero: ok, so your previous build log certainly shows 'fakeroot debian/rules binary' being called, which should be enough to trigger dh_installinit being called.  I'm not sure why your build log doesn't show this; the only reason I know of for commands to be skipped is if they're already seen in the debian/*.debhelper.log, but your build log also includes debian/rules clean
<slangasek> tzero: if 'fakeroot dh binary' worked for you now, does it also now work end-to-end?
<slangasek> tzero: oh.  this is output from bzr bd, isn't it?
<slangasek> tzero: in which case, the problem is you haven't added the debian/*.init to the repo
<tzero> slangasek: the buildlog waz `bzr bd -v -- ` output
<infinity> Ahh, that wonderfully intuitive behaviour. :)
<infinity> tzero: For a bit more verbosity to what Steve said, "bzr bd" first does an export of the repo to a clean location before building.  Cruft (and something you didn't 'bzr add' is "cruft") won't be included in that.
#ubuntu-devel 2014-10-08
<tzero> OHH bzr is like git and the bzr bd is just some convenience thing so you have to type bzr more?
<infinity> "so you have to type bzr more"... I like that.
<tzero> `bzr status` = ... unknown: the missing files -.- hahaha
<infinity> That belongs in the docs.
<infinity> tzero: bzr is a revision control system, yes, and "bzr bd" is essentially just shorthand for "bzr export $location && cd $location && dpkg-buildpackage"
<tzero> oh man, totally burned. That makes more sense now. Thanks a zillion, I was just cruising through the guide and didn't realize it
<psusi> can anyone tell me where the ubuntu mesa sources are?  the bzr repo on lp is out of date and the Vcs-Git: header points to the debian repo
<lamont> who do we know who knows gtk, dbus, and network interfaces to some degre?
<lamont> https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/1377963 annoys me
<ubottu> Launchpad bug 1377963 in sflphone (Ubuntu) "sflphone choses the wrong IP for a SIP connection" [Undecided,New]
<pitti> Good morning
<pitti> Mirv, tvoss: https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_trust-store_1.1.0+14.10.20141007.4-0ubuntu1.diff
<pitti> tvoss: ordinarily *.mo files must *not* go into libraries, as the files would conflict on the next soname bump
<tvoss> pitti, ah, where do I put them?
<pitti> tzero: so this is only they should normally go into some arch: all -common package, or perhaps trusty-store-bin or so
<tvoss> -bin?
<pitti> tvoss: this only works because we strip translations for main packages and for X-Ubuntu-Use-Langpack: yes pacakges
<Mirv> pitti: shouldn't the same probably be for usr/share/core/trust/mir?
<pitti> so this landing only works if this is true
<Mirv> they are already there in the lib* packages, but sounds wrong
<pitti> Mirv: location-service works fine
<tvoss> pitti, I will move the translations to the -bin package
<pitti> Mirv: correct; any file in a libfooN package must be versioned (in dir or file name)
<pitti> otherwise different sonames aren't co-installable
<tvoss> pitti, Mirv I can fix that, too
<Mirv> tvoss: yeah, /usr/share/core/trust/mir/prompt_main.qml can't be there. thanks.
<pitti> Mirv, tvoss: anyway, landing that now would be ok provided that you add a X-Ubuntu-Use-Langpack: yes marker to debian/control's Source:
<pitti> as otherwise the translations won't be stripped and go to langpacks, but the package would ship them by itself
<tvoss> okay, preparing breakfast real quick, on it after that
<pitti> tvoss: and please while you are at it, can you add the "use langpack" marker?
<tvoss> pitti, sure
<pitti> unless the sources are in main
<Mirv> pitti: they are in main
<pitti> Mirv: aah, ok (and good!)
<pitti> Mirv: right, that explains why they get stripped
<Mirv> I was surprised too, they sounded like "probably not MIR:d" :)
<pitti> yeah
<tvoss> pitti, Mirv pushed the marker for location-service
<pitti> tvoss: wb
<tvoss> pitti, Mirv will tackle trust-store after breakfast
<pitti> tvoss: no worries, sorry about the marker
<tvoss> pitti, all good
<pitti> tvoss: you don't need it, the packages are in main (quite surprisingly)
<tvoss> pitti, Mirv the silo needs manual ack'ing, so no one can accidently land as is
<pitti> tvoss: all main packages use langpacks by default
<tvoss> pitti, oh :)
<Mirv> tvoss: I also marked the silo back to "not tested"
<tvoss> Mirv, great, thank you
<pitti> tvoss: I'm not quite sure whether that was actually MIRed, or just wrongly NEWed
<tvoss> pitti, nope, on purpose, both are in main
<tvoss> including MIRs
<pitti> nice
<tvoss> Mirv, pitti https://code.launchpad.net/~thomas-voss/trust-store/fix-1354092 has got the changes to .install files
<tvoss> Mirv, pitti would appreciate a quick review
<Mirv> it would help of course if tvoss would stay online :)
<pitti> heh, he's got a tendency to drop off, yeah ;)
<pitti> looking (was in a HO)
<pitti> Mirv: the X-Ubuntu-Use-Langpack: yes should be dropped again, and I don't quite understand the install.$arch symlinkery, but this LGTM
<pitti> /summon tvoss
 * Mirv HO now
<Mirv> pitti: so LGTM without changes and Langpack: yes to be removed for next release?
<seb128> pitti, why does the X-Ubuntu-Use-Langpack use needs to be dropped?
<pitti> seb128: well, not *need*, but it's not necessary
<pitti> seb128: I falsely assumed that these packages were in universe, like so many others
<seb128> oh, that's in main
<seb128> yeah, me too, just looked at it
<pitti> one package to get it right! :-)
<Mirv> "we've a relatively recent touch package that is in main o_O"
<pitti> ok, I need to run for some errands, back in ~ 45 mins
<pitti> Mirv: if tvoss comes back, would you mind relaying the above to him?
<Mirv> let's wait for tvoss to be back, anyhow
<Mirv> sure
<seb128> technically the update doesn't need to be rejected on that
<pitti> cheers
<seb128> could be fixed in the next landing
<pitti> seb128: no, it doesn't
<pitti> seb128: but it's already not yet proposed, so it might just as well get cleaned up while he's at it
<seb128> right
<pitti> tvoss: wb
<tvoss> pitti, hey there
<pitti> tvoss: the X-Ubuntu-Use-Langpack: yes should be dropped again, and I don't quite understand the install.$arch symlinkery, but this LGTM
<tvoss> pitti, ack, will remove the marker again
<pitti> tvoss: sorry about the confusion
<tvoss> pitti, no worries, all good
<tvoss> pitti, pushed both location-service and trust-store
<tvoss> pitti, could you approve both MPs once you are happy?
<pitti> tvoss: ack'ed https://code.launchpad.net/~thomas-voss/trust-store/fix-1354092/+merge/235299
<pitti> tvoss: what's the other MP?
<tvoss> pitti, https://code.launchpad.net/~thomas-voss/location-service/fix-1354092/+merge/235225
<pitti> tvoss: erledigt
<tvoss> pitti, \o/
<tvoss> pitti, Mirv kicked silo rebuild
<Mirv> tvoss: thanks! and good that you asked for the approvals since that means we'll be able to ack the packaging changes even though it's in main.
<sil2100> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sil2100
<cjwatson> YokoZar: I see infinity fixed wine1.6 for you; I fixed it a bit harder so that nobody should have to manually bump that version again.
<doko> Sweetshark, any update on https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 ?
<ubottu> Ubuntu bug 1349859 in libixion (Ubuntu) "[MIR] libixion (b-d of liborcus)" [Undecided,Incomplete]
<doko> Laney, pitti: you signed paramiko, now in dep-wait
<doko> jamespage, swift ftbfs
<pitti> doko: oh argh, sorry about that; so we either need to sync python-alabaster (FFE) or just remove the new paramiko from -proposed (also fine, it's not that important)
<pitti> doko, Laney ^ and as paramiko is in main, I tend to the latter, given where we are in the release cycle; ok?
<doko> well, it's a sphinx theme, I have no problem with that. just write a MIR then
<pitti> can do that too (we'll need it in V anyway)
<doko> synced
<jamespage> doko, hmm
<pitti> doko: thanks, will review package and write MIR shortly
<jamespage> doko, OK looking - I did not see that locally
<sil2100> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * sil2100 lunch o/
<doko> barry, could you take care of the python-eventlet ftbfs? you seem to be involved upstream already, see https://github.com/eventlet/eventlet/issues/135
<Sweetshark> doko: whops, that slipped by under the radar in post-conference-mail-avalanche -- will look into it,
<doko> Sweetshark, thanks, and please have a look at the two dict-* ftbfs at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
<Sweetshark> doko: willdo
<doko> apw, could you have a look at the arm64 crash ftbfs http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html ?
<apw> doko, hmmm that is needs building ... so there is no log
<rbasak> doko: while you're looking at ftbfs from the test rebuild, I was planning on tackling some of the server ones this week.
<rbasak> doko: is there anything you're working on from that list right now?
<doko> apw, ahh, I just gave it back
<apw> doko, ack, i'll wait on it exploding again
<doko> rbasak, no, just pinging people
<rbasak> I need some help with the libecap one. It's a mismatched symbols file. I have a fix, but how do I verify that it's safe?
<rbasak> Marking some more symbols optional fixes it: http://paste.ubuntu.com/8520625/
<rbasak> Is it safe just on the basis that the source hasn't changed?
<doko> I've never seen issues removing the destructor symbols
<doko> great packaging, two year old source ....
<rbasak> How do I know what type of symbols they are?
<rbasak> (I understand that C++ mangles the names; I don't know how to match them up to their prototypes)
<rbasak> So I have no idea what _ZN7libecap7MessageD0Ev might mean for example.
<mlankhorst> run it through c++filt
<mlankhorst> ~$ echo _ZN7libecap7MessageD0Ev | c++filt
<mlankhorst> libecap::Message::~Message()
<rbasak> Oooh
<doko> $ c++filt _ZTVNSt3tr121_Sp_counted_base_implIPN7libecap7adapter7ServiceENS_11_Sp_deleterIS3_EELN9__gnu_cxx12_Lock_policyE2EEE
<doko> vtable for std::tr1::_Sp_counted_base_impl<libecap::adapter::Service*, std::tr1::_Sp_deleter<libecap::adapter::Service>, (__gnu_cxx::_Lock_policy)2>
<rbasak> I didn't know about that
<sergiusens> cjwatson: is there any wiki talking about switching your sources list to devel?
<cjwatson> sergiusens: no, haven't advertised it much because there are still a few problems I haven't had a chance to fix up
<sergiusens> cjwatson: right, that was my followup question, advertising :-) thanks
<rbasak> doko: sorry, I'm still not comfortable with this. I don't really follow the bigger picture of how to determine that these symbols really aren't needed.
<cjwatson> I have regrettably forgotten the details, would have to try it again for a while to remember them ...
<rbasak> The package includes all the headers, which makes it awkward.
<rbasak> doko: if you're happy with my diff, then I guess I can upload that.
<rbasak> Or else, I don't really see the point of having the symbols file in the first place if we just change it to accomodate when needed.
<barry> doko: yeah.  unfortunately, i'm not sure what the upstream fix really is.  it's probably not simple.  if i have time
<doko> rbasak, agreed for c++ symbols files, but c symbol files should be fine
<doko> go ahead with the upload
<doko> my libabigail upload is still stuck in NEW
<rbasak> doko: OK - you mean an upload to drop this c++ symbols file entirely, or just to mark the disappearing symbols as optional as in my diff?
<doko> well, optional shouldn't hurt from my point of view
<rbasak> OK
<pitti> doko: I reviewed the alabaster source package and filed bug 1378830 FYI
<ubottu> bug 1378830 in alabaster (Ubuntu) "[MIR] alabaster" [Undecided,New] https://launchpad.net/bugs/1378830
<rbasak> Thanks
<doko> pitti, looking
<doko> pitti, promoted
<pitti> doko: danke
 * pitti accepts the gazillion langpacks in unapproved
<Laney> doko: not the version I synced
<smoser> slangasek, i just posted some debug info at bug 1377005.  looks like 'startpar' is at least involved.
<ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
<smoser> so your comments woudl be appreciated.
<smoser> hm.. but reading what startpar is, maybe thats not that helpkful. maybe you see other info in that ubg
<smoser> bug
<geser> smoser: hmm, could you check if a "pre-up sleep 5" in your inet6 stance makes a difference (without a ipv4 stance)
<geser> if it's really a race condition
<smoser> geser, thats a good suggestion. will try.
<smoser> geser, does'nt seem to make a difference. still failed. when the ipv4 stanza was below the ipv6, but ipv6 had 'sleep 5'
<geser> hmm
<doko> barry: http://launchpadlibrarian.net/186832595/python-eventlet_0.13.0-1ubuntu2_0.13.0-1ubuntu3.diff.gz
<pitti> smoser: hey, how are you?
<pitti> smoser: what's the recommended way to enable restricted/multiverse with cloud-init? do I need to parse the existing sources.list to make some guesswork what the primary mirror is, or can I use some $mirror variable/macro in "apt_sources:"?
<pitti> smoser: i. e. I need to refer to the default of "apt_mirror" in apt_sources
<barry> doko: ah, just skip the tests.  okay cool, i'll apply
<barry> (or did you already?)
<doko> barry, no, just the one patch, fixed the sslwrap
<barry> doko: ack. i'll forward that upstream.  thanks
<smoser> pitti, you shoudl be able to use a boothook to write/edit/re-write /etc/cloud/templates/sources.list.ubuntu.tmpl
<smoser> and if you l ook at that file, it should be obvious to you.
<doko> rbasak, can't we just sync blas?
<rbasak> doko: the previous revision seemed to have some more major changes to me.
<rbasak> doko: we could sync it if the release team is happy with that.
<doko> ok, I'll take it as it is
<rbasak> OK thanks
<doko> Saviq, Mirv: qtdeclarative-opensource-src, any reason why this is still built using gcc-4.8? what kind of symbol changes were this?
<Saviq> doko, IIRC building it with 4.9 resulted in ABI breakage, which is tricky with apps in the store
<Saviq> but don't quote me on that...
<Saviq> tsdgeos, do you remember â?
<doko> Saviq, how do you want to cope with that in the future?
<doko> because we won't keep 4.8 forever
<Saviq> doko, yeah of course, I'm not sure what the plan on that is... the problem is that we try to maintain backwards compatibility, which in this case would mean keeping multiple binaries
<Saviq> or we'd have to break backwards comp
<Saviq> but I'm totally out of the loop on those things, cjwatson can you comment on that â?
<doko> well, then I don't understand why you didn't start freshly with 4.9. but maybe this is too late now
<tsdgeos> Saviq: i think you or someone mentioned some c++11 thing
<tsdgeos> which is probably not used in qt
<pitti> smoser: cheers
<Saviq> doko, yeah, we were well past that, and of course didn't foresee such an issue
<Mirv> Saviq: doko: we already landed 4.9 qtdeclarative to rtm (just today) and didn't encounter any problems, so I expect any future ubuntu release to drop that 4.8 usage too
<cjwatson> Saviq: I don't know about that
<Saviq> Mirv, ok then, I must've remembered wrong
<doko> Mirv, hmm, but why not to utopic then?
<Mirv> doko: it's a new feature that landed
<doko> Mirv, maybe I misunderstand, but what is the new feature?
<Mirv> doko: precompiling qml magic
<Mirv> from ricmm
<doko> Mirv, but this is not in the Ubutu package, correct?
<Mirv> doko: yes
<Mirv> so certainly ubuntu package could diverge and now build without that feature but also dropping the 4.8 usage
<doko> Mirv, so no reason not to switch to 4.9 for the utopic release
<Mirv> doko: no particular reason, it would just need a round of building and symbol updates
<doko> Mirv, would you have time for that this week?
<Mirv> doko: possibly yes. I'll add a landing line for that so I don't forget. and the diverged packages need to be tracked a bit, plus I've a third packaging branch for 5.3.2 (for v-series)...
<doko> cool, thanks
<doko> Mirv, ohh, and please see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html  the qt* ftbfs. can you address this for utopic too, or somebody else?
<infinity> Mirv: Erm, aren't RTM changes meant to be in utopic before (or in parallel to) the RTM landings?
<infinity> Mirv: If qtdeclarative has moved to 4.9 in RTM, I sure hope this is also heading to utopic yesterday. :P
<Mirv> infinity: not really, many landings are currently made rtm first. plus this can't land as is to utopic, and the gcc 4.9 switch was made as a sidetrack of the actual landing.
<Mirv> at some point I assume landings to rtm will continue while ubuntu sides waits for v-series to open
<infinity> Mirv: Okay, let me rephrase.  It was a matter of policy that things that were meant to happen in both happen in both at the same time, or the distro first.  Why are we breaking that policy?
<infinity> Mirv: RTM-specific hacks are a different story, but this doesn't fall into that.
<seb128> because utopic is more frozen than rtm
<seb128> and rtm work can't stop on that
<infinity> seb128: BS. It could be sitting in the queue.
<seb128> we need to open v-serie and land there
<seb128> sit and never been accepted
<seb128> what's the point?
<Mirv> infinity: in general, to get rtm bugs fixed faster it's now often the other way around, landing utopic (queue) secondarily. in this specific case, I wasn't sure if a change like this is wanted to utopic or not, but apparently the answer is yes
<infinity> seb128: The queue has 5 items, only one of which is older than 7 hours, 3 are an hour old.  So, while I get the point you're trying to make, it's not actually valid.
<seb128> I was not speaking about delays in the queue review
<Mirv> and rtm first so that QA can start their work as early as possible
<cjwatson> it doesn't strictly have to be actually in utopic; it just has to be queued somehow somewhere in such a way that it will definitely not get lost
<seb128> but about features that are not ok for utopic
<seb128> those should go in v
<seb128> but that's not open for uploads yet
<cjwatson> (in a way that's a bit better than "honestly yes I promise")
<seb128> or is it?
<cjwatson> seb128: not possible at present
<seb128> k, but does it make sense to upload features that are not ok for utopic to utopic queue?
<cjwatson> (also the singular of series is series)
<seb128> those are just going to be rejected since they shouldn't go in that serie
<infinity> cjwatson: Yeah, I'm fine with that too, of course, but I'm assuming this "it's only in RTM" thing usually means "only in RTM, and might get lost if people forget to merge back".
<infinity> seb128: No, if it's obviously not okay for U, it shouldn't be uploaded to U, as Colin says, but a distro branch where it's committed and won't get lost should also definitely happen.
<seb128> right
<seb128> nobody said that didn't happen
<seb128> and it's different from "need to get in utopic first"
<infinity> Anyhow, this 4.9 change is a bit of a unique snowflake, as we've been pushing for that to be completed throughout the whole cycle.
<infinity> If it can get done, it should get done, so we don't have to deal with the potential pain between U and V being incompatible somehow.
<Mirv> I'll get that in the queue in the morning
<infinity> Mirv: <3
<smoser> barry, you just want to fix bug 1295833 for me ?
<ubottu> bug 1295833 in bzr-fastimport (Ubuntu) "Import error in exporter.py - fastimport.helpers" [High,Triaged] https://launchpad.net/bugs/1295833
<smoser> it looks like someone just has to do it. per the last comment there.
<barry> smoser: i'll take a look
<slangasek> smoser: sorry, I can't tell in your logs on bug #1377005 what the differences are between good and bad wrt networking
<ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
<slangasek> smoser: and nothing startpar-related jumps out at me
<doko> seb128, Laney: please could you have a look at the glibmm2.4 ftbfs, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
<seb128> doko, k
<seb128> Laney, we should probably update that to 2.42 to match glib, wdyt?
<Laney> I guess
<doko> who is the proper person to ask for the unity-* ftbfs?
<seb128> doko, depending of the package
<doko> same for ido
<seb128> the lens/scope probably thostr's team
<seb128> the webapp one, dbarth
<seb128> ido, bregma
<seb128> or ted
<Laney> https://code.launchpad.net/~laney/unity-lens-music/notify-notification/+merge/235434
<doko> seb128, which ones of ido, unity-lens-music, unity-scope-manpages, unity-webapps-qml do you want to look at?
<doko> bregma, ^^^
<seb128> Laney, let me ack/do a landing for that one
<Laney> k, cool
<Laney> I forgot about it to be honest, but seems that nobody is watching those merge proposals
<smoser> slangasek, i cna't tell either.
<smoser> you have any thoughts on where to go ? i collected /var/log/upstart/* also, and
<smoser>  http://paste.ubuntu.com/8522008/
<smoser> ie, no hints there either.
<seb128> Laney, yeah, music lens didn't move for like a year, I guess that's deprecated/not maintained
<Laney> desktop eh
<seb128> it's also that the people who worked on those components left (e.g mhr3)
<doko> barry, could you have a look at https://launchpadlibrarian.net/184782940/buildlog_ubuntu-utopic-i386.dirspec_13.10-0ubuntu2_FAILEDTOBUILD.txt.gz ?
<slangasek> smoser: ok, but you said "startpar is involved", and I wasn't sure what you meant by that... startpar is always running at boot, but I don't see anything going wrong with it
<smoser> slangasek, right. the one thing that was different in the  logs
<smoser> was the location of startpar
<slangasek> ok
<smoser> which i think was actually related to the location of mounted proc
<smoser> not sure though
<slangasek> smoser: so do you have a /var/log/upstart/network-interface-$iface.log?
<smoser> nothign there.
<smoser> which means it didn't have output
<slangasek> yes
<smoser> so i know its probably red-herring
<smoser> but
<smoser> these 3 things happen before 'EXT4-fs (vda1): re-mounted. Opts: (null)' in bad case , and after in good case
<smoser> init: startpar-bridge (mounted-proc--stopped) state changed from post-stop to waiting^M
<smoser> init: Handling stopping event^M
<smoser> init: startpar-bridge (mounted-dev--stopped) state changed from stopping to killed^
<smoser> although i'm not certain order between event and message written to /dev/console is guarnateed (ie, if upstarts writing to /dev/console is intermixed with kernels in a determinable order)
<slangasek> yes, it's not guaranteed, and I don't see anything there that looks suspicious
<smoser> any wild guesses or thoughts are appreciated.
<slangasek> smoser: so in the failure case, what does /run/network/ifstate show after boot, and what's the output of 'sudo initctl list | grep network-interface'?
<doko> pitti, postgresql-9.4 autopkg test failure, blocks python3.4
<ScottK> mitya57: Why is it too late on sphinx-issuetracker?
<kenvandine> doko, did you mean to drop  Multi-Arch: allowed in gdb?
<cjwatson> (^- I investigated, it's not mentioned in the changelog and might be a merge accident)
<kenvandine> doko, ubuntu-system-settings has a build dep on gdb:any, so we have a FTBFS
<YokoZar> cjwatson: Thanks for the fix to britney :)
<smoser> slangasek,
<smoser> $ cat /run/network/ifstate
<smoser> eth0=eth0
<smoser> lo=lo
<slangasek> smoser: and eth0 is your test ipv6-only interface?
<smoser> http://paste.ubuntu.com/8522838/
<smoser> right.
<smoser> if youre interesetd in re-creating
<smoser> i just pushed instructions to https://code.launchpad.net/~smoser/+junk/lp-1377005
<slangasek> curious/annoying
<smoser> recreates with just downloading an image, modifying it a bit
<smoser> and running in kvm (even with user networking)
<slangasek> not going to have time to try to reproduce it right now
<smoser> yeah, well if you ahve time (and i'd much appreciate it, or anyone else),
<smoser> http://bazaar.launchpad.net/~smoser/+junk/lp-1377005/view/head:/README
<smoser> is honestly how much effort it takes.
<cjwatson> YokoZar: np
<cjwatson> Which Ubuntu flavours still use consolekit (if any)?
<cjwatson> Trying to work out whether the proper fix to bug 1334916 is to actually put effort and thought into it, or drop the patch ... I suspect the latter is the right answer eventually but maybe not yet
<ubottu> bug 1334916 in openssh (Ubuntu) "sshd-ConsoleKit integration patch causes abrupt termination of multichannel sessions" [Undecided,New] https://launchpad.net/bugs/1334916
<Unit193> mate-power-manager and lxsession-logout (Mate Ubuntu, Lubuntu) dep on it.
<cjwatson> Unit193: Right, I was trying to work out the extent to which the dependencies were real/interesting - the point of the consolekit patch is so that you can interact with things like policykit over ssh, but if it's just a few things that realistically you would only ever manipulate from a logged-in desktop, then that's less concerning
<infinity> cjwatson: From the package names, it sure sounds like it's the latter.
<smoser> slangasek, well, heres some more info. http://paste.ubuntu.com/8523098/ <-- output of 'ifup --verbose' in both cases with attached commentary.
<Unit193> Alright, pardon me.
<cjwatson> Unit193: no, don't apologise, I wasn't very clear and it's useful information ...
<cjwatson> I guess maybe I should be trying to figure out whether policykit might ever care
<slangasek> smoser: um?  '$ sudo ifup --verbose
<slangasek> ifup: Use --help for help
<slangasek> '
<slangasek> smoser: oh, ifup --verbose --allow-auto, ok
<smoser> well. yeah.
<smoser>  's,ifup --allow auto,ifup --verbose --allow auto,'
<smoser> well, there goes my ethtool theory. i 'chmod -x /sbin/ethtool' without it makign a difference.
<infinity> smoser: Those logs are identical...
<smoser> well, order is important.
<infinity> smoser: cut and paste fail, or were they really identical?
<smoser> oh shoot.
<smoser> yeah.
<smoser> fail.
<smoser> re-attaching corrected
<geser> and I was wondering why I didn't see any difference between GOOD and BAD
<smoser> reload
<smoser> and ihave to go now.
<infinity> geser: I thought I was maybe just failing to parse, so fed them both to diff, which lies less often than my eyes.
<smoser> later.
<infinity> smoser: "reload"?  It's a pastebin.
<smoser> oh.
<smoser> see bug
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1377005
<ubottu> Ubuntu bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New]
<smoser> sorry for confusion
<smoser> i have to run
<infinity> Ahh.
<infinity> Toodles.
<cjwatson> pitti: BTW thank you for all your effort making adt-virt-qemu etc. work well.  This is so much less unfun than uploading-and-praying, or hoping that the schroot runner is a good enough approximation.
<slangasek> smoser: so the ordering should only matter if something happens during the ipv4 bring-up that undoes the ipv6 bring-up.  But what about the case where there's *only* ipv6?
<smoser> slangasek, i can get that. but i think that something in the ipv4 bringup is just providing time in some way preparing system for ipv6 to come up.  ie, if the 'modprobe net-pf-10' not blocking. anyway, yeah, i can get that though.
<smoser> but actually, the "just ipv6" is not going to be differen tthan ipv6 then ipv4 in that its busted. and clearly wasn't ready at ipv6 bringup time.
<smoser> so, yeah, i dont think ipv4 "un-does" ipv6, i think it provides something (possibly just time) to make system ready for ipv6.
#ubuntu-devel 2014-10-09
<Unit193> pitti: Howdy.
<pitti> Good morning
<pitti> hey Unit193
<pitti> cjwatson: oh, thank you!
<pitti> doko_: ah, sorry; corresponding postgresql-9.4 will be uploaded today; I'll sort out python3.4 in the meantime
<rbasak> doko: can you sponsor me a sync of icu please? This will fix the open-vm-tools FTBFS from the rebuild test.
<rbasak> doko: OOI, do you have a rebuild button in your rebuild test? Or do we want a no-change rebuild of open-vm-tools anyway, to build against a newer icu?
<rbasak> No real changes - just compiler flags regressed in Utopic and are fixed in unstable.
<doko> rbasak, done
<rbasak> Thanks!
<Saviq> seb128, ideas about app updates in settings stuck at 0%?
<Saviq> that's mako rtm
<seb128> Saviq, yes, remove your U1 account and add it back
<Saviq> seb128, yay
<doko> dobey, pitti: please could you have a look at the dirspec ftbfs and autopkg test failure?  https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-dirspec/lastBuild/? and http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html
<seb128> Saviq, they revoked the sso token earlier this week and the settings app fails at letting you know that you hit an auth error
<Saviq> kk
<seb128> Saviq, bug #1378678
<ubottu> bug 1378678 in ubuntu-system-settings (Ubuntu) "updates panel doesn't deal with invalid u1 tokens" [High,New] https://launchpad.net/bugs/1378678
<doko> jibel, pitti: weren't libreoffice autopkg tests ignored?
<pitti> doko: they were as long as they were failing, but now they started succeeding; already retried
<pitti> one of these days I have to get behind that weird "tar: unexpected EOF" thing, it's utterly hard to reproduce locally
<doko> pitti, and s3ql and skimage too
<Saviq> seb128, yup, helped, thanks
<pitti> doko: yep, already queued (there's some lag, tons of tests are running ATM)
<seb128> Saviq, yw!
<pitti> doko: dirspec> yes, looks like simple pep-8 issues, queueing
<doko> pitti, yep, but ftbfs too
<pitti> doko: right,  I meant "queueing for today's work"
<pitti> doko: I'm watching python3-defaults excuses, btw
<doko> looking ...
<pitti> doko: oh, I thought that's what you were concerned about
<doko> ahh yes, I am
<Saviq> ricmm, hey, so, do we need to do anything to benefit from QML compilation?
<ricmm> no
<Saviq> ricmm, so it compiles it on first use and cache, or?
<ricmm> Saviq: yea, first use it compiles and caches
<Saviq> coolz
<ricmm> further uses use the cache unless it needs to recompile something
<xnox> jdstrand: slangasek: in /etc/pam.d/sudo shouldn't the pam_env.so lines be "session" rather than "auth"?
<xnox> cause at the moment it looks like variables set in /etc/environment as not present under $ sudo -i
<xnox> yet it was suppose to be working per these bugs
<xnox> bug #25700
<ubottu> bug 25700 in sudo (Ubuntu) "sudo does not read /etc/environment on interactive logins (directly, not through pam_env)" [Medium,Fix released] https://launchpad.net/bugs/25700
<xnox> bug #982684
<ubottu> bug 982684 in sudo (Ubuntu Quantal) "sudo, pkexec don't apply global environment settings from /etc/environment" [Medium,Fix released] https://launchpad.net/bugs/982684
<xnox> bug #1301557
<ubottu> bug 1301557 in sudo (Ubuntu) "sudo not setting environment variables in /etc/environment" [Undecided,Confirmed] https://launchpad.net/bugs/1301557
<pitti> jamespage: just making sure: you got the swift regression notification mail?
<Laney> pitti: He uploaded ubuntu3 to fix the test
<jamespage> pitti, I did indeed - resolved now
<doko> jamespage, I see you looked into https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695296 in the past. the package ftbfs with the current tests. do you want to take a look?
<ubottu> Debian bug 695296 in libunwind "libunwind: Add test suite execution on amd64" [Normal,Open]
<jamespage> doko, no capacity right now - there is a trick to it tho - there's a readme in debian
<doko> jamespage, ugh, how do you suggest to do that for the Debian buildds?
<jamespage> doko, well most buildds don't have apport enabled right?
<doko> no
<pitti> jamespage: ah, thanks
<jamespage> doko, sorted?
<doko> jamespage, libunwind?
<jamespage> yeah
<doko> no
<jamespage> oh
<doko> nmu'ed to Debian; ignoring test results. not a regression, because the testsuite wasn't run before
<doko> I think I'll updat tp the trunk for the v-series
<pitti> doko, dobey: fixed dirspec uploaded (waiting for RT review), and forwarded upstream: https://code.launchpad.net/~pitti/dirspec/pep8/+merge/237776
<doko> pitti, thanks!
<doko> barry, could you have a look at the flask ftbfs in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140912-trusty.html ?
<barry> doko: yep
<pitti> mvo, cjwatson: hmm, my chroot with click installed now produces failures like http://paste.ubuntu.com/8526692/ -- does that ring a bell?
<pitti> mvo, cjwatson: oh sorry, I figure this is a false alarm; /etc/schroot/default/nssdatabases copies passwd, and I don't have the user locally
<arges> hallyn: good morning
<arges> debfx: looking at your bug 1379346
<ubottu> bug 1379346 in libvirt (Ubuntu) "Error creating a VM: internal error: No PCI buses available" [Critical,In progress] https://launchpad.net/bugs/1379346
<hallyn> arges: yo
<arges> hallyn: hitting the above bug ^^ didn't know if you were already looking into it, but looks like debfx already has a patch, so I'm working on it now
<hallyn> arges: nope hadn't seen that
<arges> hallyn: yup, testing the patch now.
<hallyn> arges: huh.  i swear i used to have tha tpatch
<hallyn> arges: could you please add the trusyt and utopic machine types too?
<hallyn> then +1 from me. thanks debfx !
<arges> hallyn: so the prefix needs to be ubuntu || trusty || utopic   for utopic?
<arges> hallyn: ' qemu-system-x86_64 -machine ? ' only shows me ubuntu prefixes plus pc-* where trusty/utopic are postfixes
<hallyn> arges: no, || pc-i440fx-trusty || pc-i440fx-utopic
<hallyn> (sorry i hate those mt names :)
<arges> ah since its STREQ
<arges> hallyn: ok i'll add those
<hallyn> thx
<arges> hallyn: actually there is a condition that says 'STRPREFIX(def->os.machine, "pc-i440")' so I would assume that would catch pc-i440fx-trusty right?
<hallyn> jdstrand: sarnold: rharper: just a check, have you had any luck in either reproducing or bisecting the qemu corruption issue?
<hallyn> arges: d'oh
<hallyn> yes
<hallyn> so th eoriginal patch is good
<arges> its ok : ) i'll test the patch anyway
<rharper> hallyn: I've not tried in a while now
<hallyn> rharper: ok.  i've not seen it in awhile, though i have to work a vm pretty long+hard to get corruption
<kenvandine> doko, i think that arm64 build of gdb is hung
<doko> kenvandine, I'm tracking it
<kenvandine> doko, thx
<cjwatson> kenvandine: waiting for infinity to wake up
<jdstrand> hallyn (and sarnold and rharper): I have reproduced so much that I had to downgrade again. I don't have a simple reproducer though so I wasn't able to bisect
<jdstrand> ie, it just happens sometimes
<jdstrand> I went a whole weekend in a script and it was fine. then, I went to work on Monday and lost VMs
<arges> hallyn: ok works for me, i'm going to have sforshee confirm and then i'll upload it
<hallyn> arges: thanks
<hallyn> jdstrand: ok, now that i have working serverstack maybe i can try reproducing there next week.  (couldn't keep sacrificing my server)
<sforshee> arges, hallyn: that fixes the problem for me too
<arges> cool
<sforshee> arges: thanks a bunch
<slangasek> xnox: /etc/pam.d/sudo> I don't know off hand, but I do know that my $LANG is being set from /etc/default/locale when I run either sudo -s or sudo -i on utopic
<slangasek> xnox: hmm nope, testing shows the setting is coming from somewhere else
<slangasek> inherited from the caller in fact
<dpm> cjwatson, slangasek, do you know if it's possible to mirror a PPA? Some app developers in China tell us that it's very slow for them to download the SDK from the SDK team's PPA
<cjwatson> dpm: it's just an apt archive, debmirror can do it
<cjwatson> (or at least I assume it can, it would be very surprising if not ...)
<dpm> ok, thanks cjwatson
<doko> kenvandine, done
<kenvandine> doko, thanks!
<smoser> geser, slangasek i posted some more info to bug 1377005.
<ubottu> bug 1377005 in cloud-init "Breaks machine without IPv4: "Route info failed"" [Undecided,New] https://launchpad.net/bugs/1377005
<smoser> i cannot figure out what is removing addresses. something is doing it, and without the 'ip' command.
<slangasek> smoser: btw, why did this bug not get marked as a duplicate of the other known bug?
<smoser> no good reason.
<smoser> well, jtv said he didn't think it was. (but i disagree)
<smoser> and also cloud-init *does* put that annoying comment in the console about route info
<smoser> so that should be fixed anyway for cloud-init.
<smoser> if you want to dupe it yo ucan
<smoser> what could possibly be removing that address?
<pitti> smoser, cloud folks: is there any hope to re-fix nova boot --file (bug 1376176)? it makes it really hard to inject a script into instance creation, especially as precise's cloud-init doesn't yet support write_files:
<ubottu> bug 1376176 in python-novaclient (Ubuntu) "regression: nova boot --file does not work" [Undecided,New] https://launchpad.net/bugs/1376176
<smoser> pitti, i suspect that your cloud has just disabled that as injection.
<smoser> so theres 2 ways that happens on the backend.
<pitti> smoser: it's canonical bootstack
<pitti> ah, perhaps
<smoser> a.) the nova compute (through libguestfs) would insert it itself.
<pitti> so write_files in userdata doesn't work either :(
<smoser> b.) the files are presented through config-drive, and cloud-init would have to handle them.
<slangasek> smoser: removing that address> at this point I have no guesses.  But it has to be either something triggered via ifupdown, or the kernel itself
<smoser> can you let me into an instance real quick ?
<pitti> ok, I guess I'll stop using cloud-init then, but instead wait for ssh and remote-execute the script through that :)
<smoser> slangasek, yeah, i think kernel. but that just seems absurd.
<smoser> so i didn't say it out loud
<pitti> smoser: ah, so it might not be a regression in nova, but a proprerty of bootstack
<pitti> smoser: it worked with HP cloud, but I lost access to that, so I can't compare
<pitti> smoser: thanks
<slangasek> smoser: ipv6 addressing is very magic in the kernel and I would not rule it out :)
<smoser> pitti, can you launch one and let me in? i can see if its fixable. it probably *is* a property of openstack. and a *fix* in my mind.
<pitti> smoser: 172.19.0.77 if you want to play around with that
<pitti> smoser: (bog standard utopic i386 image)
<pitti> smoser: but anyway, I figure running the script through ssh might be quite a bit more robust anyway
 * pitti needs to leave for today, but thanks for the heads-up!
<smoser> pitti, permission denied ?
<smoser> slangasek, fix found
<smoser>  rm -f "$MOUNTPOINT/etc/sysctl.d/10-ipv6-privacy.conf"
<smoser> fun bug.
<rbasak> doko: fyi, I'm deep into the python-greenlet armhf FTBFS right now. I can work around it fine but am doing some more analysis toward sending a fix upstream.
<doko> stgraber, please have a look at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140914-utopic.html  libparse-debianchangelog-perl
<doko> jpds, mdeslaur: please could you have a look at the strongswan ftbfs, and if updating from debian would help?
 * mdeslaur looks
<mdeslaur> jpds: any ideas?
<mitya57> ScottK: too late to merge new Sphinx (which apparently can also break some stuff), and that's the only thing why I needed -issuetracker.
<stgraber> doko: I doubt I'll have much time before release week in Washington, on vacation, conference and sprinting until then
<doko> bah
<stgraber> also, I don't know that package, I'm probably an accidental TIL on it :)
<doko> looking at the merge then ...
<stgraber> thanks
<stgraber> I may have some time for packaging work on Sunday during my train ride to DÃ¼sseldorf but that's going to very much depend on how good a cell signal I get and what kind of roaming deal I can get :)
<doko> stgraber, you could have spent the time arguing here instead by saying that it can be synced ;-P
<stgraber> oh, it can? :) as I said, I don't know that package and my cell phone isn't particularly great to look things up
<bdmurray> cjwatson, infinity, slangasek: Here are the search results for /etc/os-release. http://paste.ubuntu.com/8527959/
<infinity> bdmurray: checkbox's usage might be interesting to look more closely at.
<infinity> Definitely a longer list than I expected.
<slangasek> how many of these packages are in ubuntu-rtm?
<slangasek> (ubuntu-rtm is still a subset, right?)
<slangasek> checkbox isn't in rtm
<infinity> Ahh, fair point.  At least for now.
<slangasek> bdmurray, infinity: complete list of the named packages that are actually in rtm: http://paste.ubuntu.com/8528017/
<slangasek> base-files is obvious; apport is the reason we're proposing the change; the others bear a closer look to be sure
<slangasek> augeas just references it in terms of a configuration file, doesn't care about the contents
<bdmurray> gnome-control-center uses it to display the name
 * slangasek nods
<slangasek> qtcreator uses NAME and VERSION_ID to compose a platform name for the platform in its PluginManager API; that may need further checking
<slangasek> bdmurray: qtcreator looks clean; none of the plugins in rtm care about the platformName (which is good, they shouldn't)
<slangasek> kde-runtime only uses it for drkonqi, which never runs in a phone context
<slangasek> (and it's probably informational as well)
<bdmurray> slangasek: plymouth doesn't seem relevant does it?
<slangasek> util-linux supports pulling variables from here into agetty configs, so that's not relevant
<slangasek> bdmurray: looking
<slangasek> bdmurray: yeah, plymouth is display-only
<slangasek> bdmurray: systemd is clean
<bdmurray> slangasek: okay, I'm not clear on how packagekit uses it
<slangasek> bdmurray: packagekit is possibly a concern, pk_get_distro_id() returns it in its api and it's also in pk_engine_daemon_get_property DistroId
<slangasek> cjwatson, mvo: ^^ do you know if our packagekit use on the phone will be unhappy if distro_id changes?
<sarnold> hallyn: sorry, I never had any luck finding a reliable-enough reproducer in the time I've put into it..
<mvo> slangasek: I don't I would have to investigate (tomorrow)
<mvo> slangasek: I doubt it (there is config file for backend selection), but cjwatson may know more
<hallyn> sarnold: yeah, grumble, ditto.  i guess if nothing else works i'll jus thave to buy a second colo to run the tests on, bc we have GOT to figure this out
<infinity> slangasek: Err, isn't distro_id just the ID field from os-release?
<infinity> slangasek: Or no?
 * infinity goes to look at the source.
<infinity> Ahh, poorly named function, it definitely wants ID and VERSION_ID.
 * DistroFeud Ywans
<DistroFeud> a friend of mine tells me ubuntu dev work is mostly done by upstream debian packagers
<cjwatson> slangasek: looks like that's only used by the service pack stuff, which we don't care about
<cjwatson> (packagekit)
<slangasek> cjwatson: within packagekit, yes, but it was also in the api so I wasn't sure
<slangasek> bdmurray: ^^ anyway, looks like we can conclude os-release is safe to change
<bdmurray> slangasek: okay, the general ubuntu hook in apport uses lsb_release -sc but that's just for adding a tag so meh
<geser> smoser, slangasek: your last analysis helped in finding the source of your ipv6-only network problem: bug #994931
<ubottu> bug 994931 in linux (Ubuntu Utopic) "Altering use_tempaddr drops all IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/994931
<smoser> geser, yeah, odd though. i really thought i understood it.
<smoser> but then i thought that adading this would fix it:
<smoser> pre-up f=/etc/sysctl.d/10-ipv6-privacy.conf ; [ ! -f "$f" ] || sysctl -e -p "$f"
<smoser> but it did not.
<smoser> oh.
<smoser> i see why.
<smoser> no i dont
<smoser> i thought the above would basically set it before 'ip addr add' happened, and then it wouldn't be set to a different value.
<geser> smoser: could you add a check if the sysctl was set to the expected value in your ip wrapper?
<smoser> well, /var/log/upstart/ shows it to have been set
<smoser> and it doesn't fail.
<smoser> but yeah, that would be a reason. but i can just extend it . to read the values. too (hat 'pre-up' )
<smoser> geser, well, it reads them back at the settings it wrote. (ie, it sure thinks it sets them to '2' in pre-up).
<geser> hmm
<smoser> i suspect net.ipv6.conf.eth0.autoconf=0 now. as ifup does that based on autoconf setting.
<smoser> trying that now.
<smoser> nop. i dont knwo . something fishy there.
<geser> and without the ipv6-privacy.conf file it works?
<smoser> yeah. i know. i dont trust me either :)
<smoser> it definitely works. just doing a mv of that file to .disabled.
<geser> hmm, this sounds like even with the pre-up command the sysctl value gets set at the wrong time but I can't imagine why
 * DistroFeud YWANS
#ubuntu-devel 2014-10-10
<Unit193> pitti: Howdy.
<pitti> bdmurray, slangasek: FYI, I did an RTM grep for lsb_release/lsb-release/os-release usage in http://people.canonical.com/~pitti/tmp/rtm-archive-grep-lsb_release/
<pitti> Good morning
<zyga> pitti: congratulations on cludified adt, this is a major achievement!
<pitti> zyga: thanks! it's very rewarding to finally see it working :)
<zyga> pitti: do you have nova at home or were you using a public provider?
<pitti> zyga: I tested on Canonical Bootstack
<zyga> bootstack?
<zyga> how many *stacks do we have/
<pitti> zyga: too many :)
<pitti> zyga: I've heard of {Canoni,Prod,Boot,Dev}Stack, there's probably more
<pitti> zyga: a few months ago I've tested it on HP cloud, but I don't have credentials any more
<StevenK> pitti: ScalingStack
<pitti> StevenK: ah, of course
<LocutusOfBorg1> sil2100, lucene++ accepted in debian/unstable
<cjwatson> pitti: speaking of adt, do you have an idea how long it takes for ci.debian.net to pick up new Testsuite: autopkgtest packages?
<cjwatson> pitti: I'm itching to see openssh results there to make sure they match my local ones :)
<pitti> cjwatson: it's supposed to do a full run every day, but I often found there's a two day delay until it catches up with new versions or packagess
<cjwatson> righto
<pitti> cjwatson: ci.d.n uses the schroot runner, so if it works for you locally the chance is quite high that it'll work there
<pitti> cjwatson: that's not yet in Ubuntu, right? https://jenkins.qa.ubuntu.com/job/utopic-adt-openssh
<cjwatson> right, about to file an FFe for it
<cjwatson> pitti: oh, I have "Restrictions: isolation-container" - is it possible that ci.d.n will just skip it then?
<pitti> cjwatson: yes, it will
<cjwatson> bah, right
<pitti> cjwatson: I hope for ci.d.n we can move to a cloud-based runner, now that that stuff works; after all, ci.d.n is already running on EC2
<cjwatson> let me know if you think that's wrong?  the regression tests have to start sshd on a high port
<cjwatson> which by my reading is isolation-container
<pitti> I'll talk to Antonio soon, I'd like to test this on EC2 and adjust the setup script if necessary
<pitti> cjwatson: why wouldn't that work in a schroot?
<cjwatson> pitti: well, README.package-tests says "isolation-container: The test wants to start services or open network TCP ports"
<pitti> cjwatson: as a rule of thumb, I found that pretty much every test which isn't "needs-root" can be made to work in schroot
<cjwatson> it's also needs-root :-)
<cjwatson> that was unclear actually, strictly, it just needs unpassworded sudo
<pitti> cjwatson: so if it wants to open port 22, that will obviously not work in schroot as the openssh package already claims that (and the host itself, too)
<cjwatson> right, it's not trying to use port 22 indeed
<pitti> cjwatson: ah, I wrote that as most developers and schroots have a policy-rc.d
<pitti> ci.d.n's doesn't, so services from postinst actually do start up
<cjwatson> so does isolation-container really just mean wants to start services on their default ports?
<pitti> (that's not very robust of course, but meh, it seems Antonio manages to keep it running :) )
<pitti> cjwatson: at least in a container that's guaranteed to work, while in schroot it's between "depends on the config", and "may work or not depending on what's running on the host"
<cjwatson> yeah it'll break if somebody's opened port 4242 for something else
<pitti> cjwatson: but anyway, I've long lobbied for moving away from schroot in ci.d.n production; I'll talk to Antonio soon, we now have several better alternatives
<cjwatson> but, well, I guess I can try
<pitti> I wrote a debci LXC backend not too long ago, unfortunately Debian's LXC packages kind of suck
<pitti> I guess that's why it's not being used widely yet
<sunweaver>  as the maintainer of MATE in Debian, I would love to support  flexiondotorg with pushing MATE into Ubuntu and make UMR happen.
<sunweaver> hi!
<sunweaver> so my question is: what does it need for a DD to become a Ubuntu developer (i.e. gain upload rights to the archive / universe area of the archive)?
<mlankhorst> see ubuntu motu documentation :P
<doko> Sweetshark, seb128: thanks for the libixion upload, however it is still incomplete: https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859
<ubottu> Ubuntu bug 1349859 in liborcus (Ubuntu Utopic) "[MIR] libixion (b-d of liborcus)" [High,Confirmed]
<mlankhorst> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
<seb128> Sweetshark, ^ what doko wrote on that bug
<Riddell> anyone know why this ubiquity test fails? (caused by casper upload) https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubiquity/lastBuild/ARCH=amd64,label=adt/
<Riddell> it says "adt-run [10:04:29]: ERROR: unexpected error: test dependencies are unsatisfiable"
<Riddell> but I don't know how to see what is unsatisfiable
<cjwatson> it would be very helpful if autopkgtest were more verbose about that ...
<cjwatson> pitti: ^- can you help?
<Riddell> cjwatson, pitti: ubiquity test depends on universe packages oem-config-kde oem-config-remaster, might that be the issue?
<cjwatson> not in itself
<pitti> looking
<pitti> cjwatson, Riddell: well, there's the whole apt problem solver debugging output there, it's just quite hard to read
<pitti> some libwebkitgtk arch desync, or some binNEWing going on or so?
<pitti> if there's some better way to tell apt "please tell me what's wrong so that a human can understand" I'm all ears
<pitti> ah, https://launchpad.net/ubuntu/+source/webkitgtk/2.4.6-1ubuntu1/+build/6449387 just finished 30 mins ago, while amd64 finished muhc earlier
<cjwatson> oh maybe the problem is that the apt problem resolver output is way up there compared to the final error from autopkgtest
<pitti> I bet it was just hte usual temporary uninstallability from mismatching arch:all
<cjwatson> not obvious to go and look for it
<pitti> yeah, I know; it's all just a single apt-get install call, not sure if the ordering can be influenced
<pitti> I'll give it another 20 mins or so for publishing and then retry
<pitti> mvo: hm, so the unattended-upgrades test regression that holds back the new apt is quite persistant, I'm afraid (https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/38/ARCH=amd64,label=adt/console)
<pitti> it always works on i386 and always fails on amd64
<pitti> that smells like i386 and amd64 being out of sync in building or binNEWing, but I don't see anything relevant in https://launchpad.net/ubuntu/utopic/+queue?queue_state=0
<pitti> and apparently it's not due to the new webkit-gtk
<pitti> that caused uninstallability with ubiquity, but that's fixed now
<pitti> cjwatson, Riddell ^ FTR
<pitti> cjwatson, bdmurray: I'm looking into bug 1365079
<ubottu> bug 1365079 in apport (Ubuntu) "apport should gather package information about click packages" [Medium,Triaged] https://launchpad.net/bugs/1365079
<pitti> cjwatson: for mapping an exe path to a click, would this be suitable:
<pitti> - parse all root= from /etc/click/databases/*.conf
<pitti> - check if the exe path starts with any of those root dirs
<pitti> - if not â discard, not packaged
<cjwatson> pitti: click pkgdir PATH
<cjwatson> pitti: or in fact probably click info PATH
<pitti> cjwatson: oh splendid -- much easier, thanks!
<pitti> cjwatson: right, click info $exepath, and taking nae and version from it is what I'm after
<cjwatson> pitti: you'll either get non-zero exit (and exception junk on stderr) or zero exit + json output
<pitti> ack, so in fact implementing this is quite simple, the test case will be much more work :)
<cjwatson> heh
<cjwatson> in fact this interface is mentioned in the bug description ;-)
<pitti> cjwatson: ah indeed; reading helps *brown paperbag*  TGIF!
<Riddell> pitti: is there a handy retry button somewhere?
<pitti> Riddell: yes, on http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ ; but for that you need the company VPN :/
<pitti> (we're working hard on gutting Jenkins and the entire current setup, though)
<pitti> Riddell: so I guess the button for now is "pitti, jibel: please retry <src> tests"
<pitti> Riddell: but I'm watching all failures anyway and retry ones like ubiquity
<Riddell> lovely
<mvo> pitti: hm, thanks! I have a look (once this image build is finished that I'm currently testing)
<linoge> Hi there, I want to customize ubiquity in order to install another debian based distro (Canaima GNU/Linux) from it. Is that possible?
<ejat> anyone can help with this http://paste.ubuntu.com/8532798/
<shadeslayer> mhall119: whom do I bug about the email that you get when you submit a CDA :P
<shadeslayer> . If your application is approved, we contact you.
<shadeslayer> grammatically incorrect ^^
<cjwatson> well, inelegant anyway ...
<flexiondotorg> I have a merge I want to propose a merge for lp:ubuntu/indicator-application-gtk2
<flexiondotorg> But LP says "This branch is not mergeable into lp:ubuntu/indicator-application-gtk2." when I try and submit the proposal.
<flexiondotorg> How should I go about submitting my merge? Raise a bug and attach a patch?
<seb128> hum
<seb128> cjwatson, that cinnamon-menus, "Install typelib files in multiarch libdir" ... I though we didn't start that transition for utopic?
<cjwatson> oh hmm
<seb128> our gir doesn't support multiarch afaik
<cjwatson> sorry I assumed that was so obviously excellent we must have done
<seb128> well, it was late and still had issue
<cjwatson> it seems to ftbfs so I guess we can just leave it
<seb128> k
<cjwatson> however it'll be an issue for the pile of mate syncs in the queue, probably
<cjwatson> *sponsoring queue
<seb128> let me have a look to those
<cjwatson> I already synced mate-panel so I'll keep an eye on it and see if it needs to be fixed up.  there were other problems
<seb128> k
<cjwatson> the gir change will make some cross-building/cross-installing changes a lot easier once it does land
<seb128> indeed
<seb128> mvo wanted it this cycle
<seb128> but it was late and still having a bunch of issue in Debian, I think Laney decided it was too much work/too late and preferred to delay to next cycle
<cjwatson> ok, reverting that bit of the mate-panel sync for now
<cjwatson> keeping the new upstream though
<cjwatson> thanks for keeping an eye on that
<seb128> yw!
<mhall119> shadeslayer: CDA?
<Riddell> tseliot: ping?
<shadeslayer> mhall119: Community Donation Application
<mhall119> ah, that would be msm I think
<Riddell> tseliot: can we have sddm added to nvidia-prime's alternative depends?
<shadeslayer> mhall119: ack :)
<Sweetshark> bye Sweet5hark.
<Riddell> tseliot: I just uploaded it to utopic
<tseliot> Riddell: ok but I don't think it will actually support Nvidia optimus systems
<Riddell> tseliot: why not?
<tseliot> Riddell: does it allow to run scripts when X is stopped or launched?
<Riddell> tseliot: it runs scripts in Xsession.d if that's what you mean?
<tseliot> Riddell: no, I mean exactly what I said. This is the equivalent config file for lightdm: http://paste.ubuntu.com/8533397/
<tseliot> Riddell: display-setup-script and display-stopped-script are the relevant fields
<Riddell> tseliot: hmm are you able to join #kubuntu-devel to discuss?
<tseliot> Riddell: sure but I have a conference call in 3 minutes
<Riddell> mvo_: app-install-data due to be updated before RC?
<seb128> is there a standard dh/rules variable for "srcdir"?
<rbasak> seb128: make's $(CURDIR)?
<rbasak> Or else, I'm not sure I understand the question.
<seb128> rbasak, if building out of the srcdir, is CURDIR pointing to the source dir or the build dir?
<seb128> that rules has
<seb128> 	dh $@ --with click,translations --fail-missing -- -B build
<seb128> e.G "-B build"
<seb128> and I want to copy something from build/... back to the srcdir
<rbasak> seb128: I think CURDIR points to the top level. So $(CURDIR)/debian/rules should find the right file, for example.
<rbasak> I don't know about click, though.
<seb128> rbasak, thanks
<seb128> that's a deb
<rbasak> (I'm not entirely sure)
<rbasak> Though the cwd (pwd output) should also be the same as $(CURDIR), unless you've changed it.
<rbasak> So just in debian/rules, "cp build/foo ./" should also work.
<seb128> rbasak, no, I've having an override on a dh_ helper, and it's running from the "build" directory (the one specified with -B)
<rbasak> seb128: -B to what command?
<seb128>   dh $@ --with click,translations --fail-missing -- -B build
<seb128> dh -- -B build
<seb128> to dh
<seb128> that makes dh_ subcommand be run from build/
<rbasak> Ah, I'm not familiar with that.
<rbasak> Though if debhelper is changing it in response to that call, you might still have $(CURDIR) set. I'm not sure if make exports that or not.
<seb128> I'm going to try
<seb128> but using ../<dir> works
<seb128> and turns out in fact I don't even need to copy that file after all, the binarymangler is smart enough to handle the pot being in build/
<seb128> but I wanted to know the answer for next time anyway ;-)
<rbasak> :)
<seb128> rbasak, thanks for the help!
<rbasak> np
<goodwill> ppetraki: ping
<ppetraki> goodwill, pong
<LocutusOfBorg1> sil2100, for your information, is it ok if I upload on debian a new lucene++ with this fix?
<LocutusOfBorg1> https://github.com/luceneplusplus/LucenePlusPlus/pull/76/files
<LocutusOfBorg1> it should fix hurd and kfreebsd build failures
<slangasek> smoser: so did geser's pointer to bug #994931 help?  and does it suggest any workarounds (e.g., setting the desired use_tempaddr value before bringing up the interface?)
<ubottu> bug 994931 in linux (Ubuntu Utopic) "Altering use_tempaddr drops all IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/994931
<slangasek> smoser: fwiw I'm not able to reproduce this problem on a utopic kernel by changing the value of use_tempaddr on my running interface
<smoser> slangasek, well, no . it dos not suggest work arounds.
<smoser> slangasek, you are changing use_tempaddr.all ?
<goodwill> ppetraki: is there any sense of multipathing netboot will be addressed in 12.04? https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004243
<ubottu> Ubuntu bug 1004243 in debian-installer (Ubuntu) "multipath installs not working" [High,Confirmed]
<ppetraki> goodwill, nice comment ;)
<adam_g> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<adam_g> bug #1379201 breaks openvswitch dkms update on precise
<ubottu> bug 1379201 in openvswitch (Ubuntu) "openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build [error: too many arguments to function âip_select_identâ]" [Undecided,Confirmed] https://launchpad.net/bugs/1379201
<ppetraki> goodwill, unless someone picks it up, I don't think so. you might be able to convince hallyn to take a look
<ppetraki> goodwill, come to think of it, you don't really need to be on a mp system to debug this, just a vm with the right switches. It looks like the udeb is built wrong.
<adam_g> hallyn, jamespage ^ zul assigned it to himself but i dont know the status.
<zul> adam_g:  will look at it
<SpamapS> cjwatson: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1378658 .. seen this bug? It was just recently reported by one of our developers. It sounds like something you might understand. :)
<ubottu> Ubuntu bug 1378658 in grub2 (Ubuntu) ""no such device" error from grub2 search command" [Undecided,New]
<ScottK> zul: Are you taking care of 1379201?
<zul> ScottK:  yes im working on it
<ScottK> OK.  Thanks.
<smoser> bug 1379201
<ubottu> bug 1379201 in openvswitch (Ubuntu) "openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build [error: too many arguments to function âip_select_identâ]" [Undecided,Confirmed] https://launchpad.net/bugs/1379201
<smoser> slangasek, it does indeed appear that utopic does the right thing.
<smoser> so i expect that both bugs then are fix-released in utopic
<slangasek> smoser: aha - so it does come down to the kernel bug with use_tempaddr?
<slangasek> smoser: and does pushing the same value to use_tempaddr have any effect?  i.e., if we had it pre-set before ifupdown ran, would that work around it?
<geser> I did some tests with my trusty vm yesterday and used sysctl to change the value and "ip addr show" to show the ipv6 address
<geser> changing the value flushed the address but re-running the same command didn't
<slangasek> right, cool
<ari-tczew> hello
<geser> you can "play" with this during runtime, just assign an ipv6 address and the change the use_tempaddr to see your address gone
<ari-tczew> There is a one sync request with following change:  debian/gir1.2-mate-menu.install: + Install typelib file into the multiarch libdir. (Closes: #763243). Would it seem to need a FFe request?
<smoser> geser, yeah.. .but i dont know why my 'pre-up' command then didn't fix it.
<smoser> oh. i do know why now.
<smoser> funny. because yesterday i didn't realize that cloud-images have
<smoser>  /etc/sysctl.d/99-cloudimg-ipv6.conf
<smoser> which sets those 2 values to '2'.
<smoser> err.. that sets it to zero.
<smoser> hm..
<geser> '2' == 0?
<smoser> so yeah, the 'pre-up' would have set the values to '2' if that file existed.  then, they'd get reset to '2' and then to '0'.
<smoser> so in a cloud image right now, we first set them to 2 (enabled) and then milliseconds later set them to 0.
<smoser> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756
<ubottu> Ubuntu bug 1068756 in cloud-init (Ubuntu) "IPv6 Privacy Extensions enabled on Ubuntu Server by default" [Medium,Triaged]
<slangasek> hee
<geser> so your pre-up sets it to 2, ip sets the address and then procps (started by upstart) processes the other sysctl files and sets it back to 0, flushing your ipv6 address?
<smoser> well, the pre-up was setting to 2. the ip set the address. then procps setting to '2' again per 10-ipv6-privacy.conf. then setting to '0' per 99-cloudimg-ipv6.conf.
<smoser> and its the 2 -> 0 change in that case that was killing the addresses.
<smoser> i just verified on utopic you can flip values back and forth to your whim and not destroy addresses.
<smoser> so as such, i'm going to mark bug 994931 as 'fix-released'
<ubottu> bug 994931 in linux (Ubuntu Utopic) "Altering use_tempaddr drops all IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/994931
<smoser> in utopic.
<smoser> slangasek, or geser you know why procps-instance.conf is
<smoser> start on virtual-filesystems or static-network-up
<smoser> why the "or static-network-up". it would seem that on a normal boot that is going to run more than once.
<slangasek> smoser: yes, we run it more than once because it's not possible to apply the sysctl settings to network devices before those devices are available
<smoser> oh. because some of the settings have some.value.$IFNAME.value
<smoser> ?
<slangasek> so we run it once as early as possible to apply the settings that we can, then run it a second time after the network is up
<slangasek> yep
<slangasek> ideally there would be a way to apply these settings in-line with each interface bring-up
<slangasek> but /etc/sysctl.conf doesn't lend itself to this
<slangasek> not sure if systemd has tried to solve this problem
<smoser> well, sed -n "/.$INTERFACE./p" /etc/sysctl.d/* | sysctl -p -f -
<slangasek> yeah, horrible layering violation ;)
<goodwill> ppetraki: well its a magical land :)
<goodwill> ppetraki: so should I ping hallyn ?
<goodwill> ppetraki: I am trying to debug it and get to the cause ... but its twisted one
<ppetraki> goodwill, yeah, he's good
<ppetraki> goodwill, so a quick search is showing no udeb for multipath
<goodwill> ppetraki: where are you searching?
<goodwill> hallyn: ping
<dx> hey #ubuntu-devel! do packages in universe have to go through the same SRU process as packages in main?
<geser> dx: yes
<cjwatson> SpamapS: don't have a lot of time just now, sorry.  is it reproducible in qemu?
<slangasek> ev, bdmurray: is https://errors.ubuntu.com/problem/d7b8b576c9b773cd5d822e833534e98fba85e30d == bug #1345569 ?
<ubottu> bug 1345569 in apport (Ubuntu) "recoverable_problem crashed with ValueError in add_proc_info(): invalid process" [High,Fix released] https://launchpad.net/bugs/1345569
<ahoneybun> mhall119, still need track leads?
<mhall119> I haven't started recruiting them yet, but yes
<ahoneybun> oh ok just let me know
<bdmurray> slangasek: yeah, that looks the same to me
<bdmurray> slangasek: this is the error associated with the bug - https://errors.ubuntu.com/bucket/?id=/usr/share/apport/recoverable_problem%3AValueError%3Aadd_proc_info%3A/usr/share/apport/recoverable_problem%4070%3Amain%3Aadd_proc_info
<slangasek> bdmurray: so should we reopen bug #1345569, given that this crash is being reported against apport 2.14.7-0ubuntu5?
<ubottu> bug 1345569 in apport (Ubuntu) "recoverable_problem crashed with ValueError in add_proc_info(): invalid process" [High,Fix released] https://launchpad.net/bugs/1345569
<slangasek> bdmurray: (presuming yes and reopening with comment)
<xnox> slangasek: right, i think sudo's pam config is incorrect. I'll submit patch to security for review, but it's too late for utopic, will wait for Tasty Topi
<slangasek> those are the wrong letters
<slangasek> you mean Very Tasty Velociraptor
<xnox> oh yeah.
<xnox> we should pull an android and drop the code name and just call it: V for Vendetta
<xnox> slangasek: please remove btrfs-tools from utopic-proposed.
<xnox> FFe bug didn't get approved and it's stuck in NEW, and I'd rather make a new point release upload and make it hit the queue properly
<xnox> stuck in proposed that is, blocked by tag.
<xnox> or i guess it doesn't matter if i have a proper on in the unapproved queue.
<slangasek> xnox: ok.  I guess you don't think it would be preferred to approve the FFe at this point?
<slangasek> fwiw that FFe bug is a bit sparse on justification
<xnox> slangasek: oh, i'd love for the FFe approved, it's just i'll have 3.16.2 to upload now. So i'd want FFe approval against 3.16.2.
<xnox> slangasek: justification is that it slipped my radar whilst employed, and ideally btrfs bug-fixes should match the kernel release =))
<slangasek> xnox: right, ideally they would, but ideally this would be figured out before freeze
<slangasek> xnox: and I don't think that ideal is sufficient justification for an FFe
<slangasek> xnox: so if that's all you've got then yes, I'll remove it from -proposed ;)
#ubuntu-devel 2014-10-11
<xnox> go for it
<infinity> YokoZar: How safe is the ~ubuntu-wine PPA?  I'm considering taking 1.7 for a test drive, but don't want to blow anything up. :P
<infinity> Meh, you only live once...
<Logan_> Laney: would it be possible to get gtk+2.0 2.24.24 into utopic?
<Logan_> er, 2.24.25
<Logan_> it has a pretty critical bugfix
<Logan_> oh nvm it looks like you backported the fix from the new release
<SpamapS> cjwatson: Thanks for any time you can spend. I'll ask the author. I believe it is indeed reproducable in a VM.
<Bluefoxicy> Are there any barriers to packaging the Android SDK in Ubuntu Universe or Multiverse?
<hallyn> goodwill: I was afk friday, am traveling today/tomorrow, sorry.  pls feel free to subscribe me to the bug if there's a bug you're working with.
<goodwill> hallyn: hello
<goodwill> hallyn: ppetraki recommended I talk to you
<hallyn> but really i've not touched multipath since about precise time.  but i don't htink anyone else has either, so i'm happy to take a look monday afternoon
<goodwill> hallyn: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004243
<ubottu> Ubuntu bug 1004243 in debian-installer (Ubuntu) "multipath installs not working" [High,Confirmed]
<goodwill> hallyn: its been kinda open for 2 years, it seems multipath installs are broken
<goodwill> hallyn: I've been trying to debug, but for now I am just learning about debian installer
<hallyn> have you pinged cjwatson?  (though i gather he's also traveling or something)
<hallyn> goodwill: ok let's chat on monday
<goodwill> hallyn: I have not
<goodwill> hallyn: thank you for your response
<goodwill> hallyn: let's chat monday
<goodwill> :)
<goodwill> hallyn: fwiw, I am happy to help test, I got the hardware ... but right now I am monkey with a gun when trying to figure it out
<hallyn> goodwill: awesome, i have no hardware, so that'll be immensely helpful
<hallyn> thanks - talk to you then
<hallyn> (i'll be at the mercy of linuxcon's network, so hopefully it goes well)
<infinity> hallyn: Poke me about that bug when you see me in Germany, it looks suspiciously like it might be my bug.
<infinity> hallyn: (The multipath one)
#ubuntu-devel 2014-10-12
<Logan_> pitti: doesn't look like the retracer marked Bug 1379974 properly as a duplicate - might be because the duped report has a ton of duplicates already, so an LP problem?
<ubottu> Error: Launchpad bug 1379974 could not be found
<darkxst> Laney, what happened with bug 1370755?
<ubottu> bug 1370755 in tracker (Ubuntu) "[FFe] Re-enable libmediaart build dep" [Undecided,New] https://launchpad.net/bugs/1370755
<CanYouFTLTN> hi ubuntu-devel
<pitti> Logan_: yeah, I got several LP timeout exceptions in the retracers
<Laney> darkxst: don't know, guess the release team missed it
<darkxst> Laney, except you were going to approve it?
<Laney> is my reply not good enough?
<darkxst> no, I mean you said you would approve it]
<Laney> just did
<darkxst> ok, thanks ;)
<darkxst> and bug emails are quite slow ;)
<hallyn> slangasek: hi, new cgmanager package at mentors has the patch which bug submitter claims fixes debian bug 757348   (http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-1.dsc)
<ubottu> Debian bug 757348 in cgmanager "systemd: with SysV init, can no longer suspend and shutdown from lightdm" [Grave,Open] http://bugs.debian.org/757348
<slangasek> hallyn: grabbing
<hallyn> though there's someone also claiming an install bug, but not sure hotel wifi is suitable to reproducing htat
<hallyn> thanks!
<slangasek> hallyn: uploaded
<Pwnna> does anyone know if there's a notify feature for procfs?
<Pwnna> i guess that doesn't really make any sense
<geofft> what are you trying to do? I believe inotify doesn't work, but there are things like the proc connector for process creation etc.
#ubuntu-devel 2015-10-05
<robert_ancell> mbiebl_, You seem to be the last to touch realmd - can you apply so we can keep in sync? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800928
<ubottu> Debian bug 800928 in realmd "realmd: FTBFS with GLib 2.45.7" [Normal,Open]
<pitti> roaksoax: yes, don't use trusty's autopkgtest -- use wily's package, the deb can be installed on anything >= precise
<pitti> roaksoax: in production I just run it straight out of git
<pitti> smoser: I was on the snappy sprint last week, there's now a huge backlog to look into (which includes this bug)
<FourDollars> Ubuntu doesn't have the mmc udeb like https://packages.debian.org/unstable/mmc-modules-4.2.0-1-amd64-di in Debian so it causes problems when we use debian-installer on some platforms with eMMC storage only. :-(
<pitti> sarnold: restarting; the machine has an incredible load right now, it apparently crashed on some timeout
<roaksoax> pitti: ok, cool, thanks!
<dholbach> good morning
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
 * smb notes the trusty-proposed repo seems to miss a signed grub2 upload 
<flexiondotorg> dholbach, Thanks for the sponsoring!
<doko> pitti, did you override the libxml-libxml-perl autopkg test failure? and the xslt one?
<dholbach> flexiondotorg, no worries
<pitti> doko: no, I fixed the reason why they fail
<pitti> doko: and re-ran them
<doko> ohh, nice
<pitti> doko: same for some of the ruby failures (the ones which only failed on i386 and amd64)
<pitti> doko: we had "git" installed on the VM testbeds, which enabled the additional "check gem deps" test; these aren't run in LXC (armhf/ppc64el) and Debian as there "git" isn't installed
<pitti> and it's not a test dep
<doko> pitti, setup of the test env?
<pitti> doko: so IMHO we should ignore those for now, as we don't have anyone in Ubuntu actively working on these tests
<doko> argh
<pitti> doko: yep -- the cloud images contain more and more stuff, so my "purge" list becomes longer over time :)
<doko> pitti, so there is no minimal cloud-image?
<pitti> doko: nodejs is a block-proposed, infinity wanted to do some additional manual testing
<pitti> doko: ruby is a mess, the other excuses look fairly reasonable now
<pitti> doko: no, I use the standard cloud images and minimize the stuff which we don't need
<doko> mvo, would it be ok to merge apt again? or else I have downgrade the b-d in libept
<mvo> doko: I think thats ok, I can do that later today
<doko> ta
<hrw> hi
<hrw> will 15.10 have support for 32bit uefi in x86-64 install iso?
<davmor2> hrw: not sure I follow that. UEFI as far as I am aware is not bit dependant, so amd64 is the only one that supports UEFI and secureboot
<FourDollars> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1341944
<ubottu> Launchpad bug 1341944 in grub2 (Ubuntu) "32-Bit UEFI bootloader support needed" [High,Triaged]
<hrw> davmor2: http://i.imgur.com/fRdyE2A.jpg
<FourDollars> hrw: Check https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1341944
<hrw> FourDollars: reading. thanks
<FourDollars> hrw: YW
<hrw> FourDollars: full of "me too" without any "we work on it"
<FourDollars> hrw: You are right.
<dholbach> chrisccoulson, Laney, seb128, Mirv: you all commented on https://bugs.launchpad.net/ubuntu/+source/ninja-build/+bug/1473680 - do you have any objections to a newer version of ninja-build going in?
<ubottu> Launchpad bug 1473680 in ninja-build (Ubuntu) "Please update Ninja from Debian" [Undecided,Confirmed]
<seb128> dholbach, none from me
<hrw> FourDollars: not suprised I am
<FourDollars> hrw: Me neither.
<Mirv> dholbach: no objections
<hrw> bye
<Laney> dholbach: do it if you are happy
<chrisccoulson> dholbach, none from me
<bzoltan_> cjwatson: how do you like the changes in my MR? https://code.launchpad.net/~bzoltan/click/add_overlay_ppa/+merge/272428
<bzoltan_> zbenjamin: happy-happy-joy-joy -> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5477761/+listing-archive-extra
<bzoltan_> zbenjamin:  now the standalone qmake extras package is available from the overlay ppa, so once the new click ^^ is out we can push the  single packaged IDE out.
<zbenjamin> bzoltan_: and did you fix the src package of qtcreator-plugin-ubuntu?
<bzoltan_> zbenjamin: not yet... that will come after click
<cjwatson> bzoltan_: surely you don't need to duplicate the whole script!
<cjwatson> bzoltan_: there's plenty of commonality, you only need the if for the bit in the middle.  good programming practice involves not duplicating things like this
<cjwatson> bzoltan_: I mentioned this in my previous review, when I said that you could split into multiple finish.write calls
<bzoltan_> cjwatson: imo it is not that big deal...but I do as you wish
<cjwatson> bzoltan_: it is a big deal
<cjwatson> bzoltan_: otherwise a year from now it'll be "why were fixes applied in one branch but not the other?"
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bzoltan_> cjwatson: I am not challengig you :)
<cjwatson> mvo: ^- fwiw, I'm going to need somebody who isn't me to land this new click version once bzoltan_ has it fixed up ...
 * pitti hugs dholbach
<bzoltan_> cjwatson: done... took some time to test it, but i hope now it is what you though of
<mvo> cjwatson: sure, I can land it
 * dholbach hugs pitti back :)
<mvo> bzoltan_: just ping me when this is ready
<bzoltan_> mvo:  it is ready from my side ... it is up to cjwatson to approve it :)
<mvo> bzoltan_: I thought I read that there is some duplication that needs cleanup first? but maybe I misread?
<bzoltan_> mvo:  my middle name is "Lightning" :) for a reason
<mvo> lol
<cjwatson> Let's see.
<bzoltan_> cjwatson: thank you
<cjwatson> Thanks for persevering; merged.
<cjwatson> (into lp:click/devel)
<caribou> pitti: have time to sponsor my upload for Bug #1470399 ?
<ubottu> bug 1470399 in systemd (Ubuntu Trusty) "udev duplicates entries in 70-persistent-net.rules" [High,In progress] https://launchpad.net/bugs/1470399
<doko> cyphermox, cjwatson: grub is dep-wait on automake1.9 (removed).  I assume just backporting 0.97-68 would be the correct solution?
<doko> or would it need more build fixes?
<infinity> Oh wow, grub is in desperate need of a merge.
<pitti> caribou: will do
<caribou> pitti: thanks!
<cjwatson> infinity: Historically painful because it included the auto-upgrade saga
<cjwatson> doko: Let me see if I can cherry-pick a few things.
<infinity> cjwatson: Yeah, I've not looked at why it's so far behind, just saw that it was, plus has 66 ubuntu revisions.   That's a contender for the d-i oops award.
<caribou> infinity: you had some concerns over Bug: #1432871
<ubottu> bug 1432871 in coreutils (Ubuntu) "`df` shows bind mounts instead of real mounts." [Low,In progress] https://launchpad.net/bugs/1432871
<infinity> caribou: Just concerns about it being sanely fixed in an upstreamable way.  The theory is that the current proposed patch is from upstream?  I haven't looked yet.
<caribou> infinity: yes, AFAIK, chiluk got the patches accepted upstream
<caribou> infinity: there's a new debdiff in the ubg
<caribou> s/ugb/bug/
<smoser> pitti, sorry that i sounded like a nag. thanks for getting back to me.
<pitti> smoser: no worries, nagging is fine; just saying that it still takes a bit
<pitti> smoser: is the network up in teh cases where /run/resolvconf/resolv.conf doesn't have the nameserver?
<smoser> yeah, network is up, as otherwise there'd be no root filesystem (iscsi)
<pitti> smoser: collecting/attaching the journal from a "good" vs. "bad" case is also a good first step (I assume you already have the iscsi setup)
<smoser> well, the linked bug has example on how to run it from scratch on a new install .
<smoser> ie, easy enough to recreate.
<smoser> i actually haven't ever *caught* it working
<pitti> smoser: ah, so I suppose open-iscsi's startup scripts need to call resolvconf then, as nothing else is calling it then?
<smoser> well, i've had evidence of it workign hough. which i admit is weird.
<pitti> smoser: i. e. they trick ifupdown to think that it already brought up ethN, so /etc/network/if-up.d/000resolvconf would never run
<pitti> (unless you have other interfaces)
<smoser> ie, once a 'wget http://dns.entry/' didn't work, and i went in to see why. and other time it did.
<smoser> i'll poke a bit at it.
<cjwatson> doko: uploaded grub 0.97-29ubuntu67, should be happier
<smoser> pitti, how do i collect what you want ?
<smoser> collecting/attaching "the journal"
<pitti> smoser: just "sudo journalctl > /tmp/journal.txt", or mostly equivalently, attach /var/log/syslog
<pitti> (this has previous boots in it etc., but simple enough)
<smoser> i'll attach to bug
<smoser>  http://paste.ubuntu.com/12689381/
<pitti> smoser: but resolvconf doesn't actually print anything when it runs; so debugging with making it print something would indeed be more useful
<smoser> that is pass (/etc/resolv.conf populated)
<smoser> k
<pitti> smoser: i. e. add as set -x to /sbin/resolvconf to see what it's doing and when it runs during boot?
<smoser> ok.
<seb128> doko, can you retry the telepathy-gabble builds on the test builds? should be fixed with the libnice update
<seb128> doko, can you retry the url-dispatcher build on armd64 as well?
<smoser> pitti, ok. attached journalctl of pass and fail
<doko> seb128, done
<seb128> doko, thanks
<smoser> pitti, i think i've diagnosed problem. i'm not sure how you want to solve it.
<smoser> see comment in bug
<smoser> is there a way to get output of udev-event fired commands ?
<smoser> ie, resolvconf there did write 'report_error' to its stderr, but that  never made it to journalctl
<cjwatson> Odd_Bloke: do you know if anyone has got anywhere with https://rt.admin.canonical.com/Ticket/Display.html?id=84711 ?
<Odd_Bloke> cjwatson: I don't think we've got anywhere with it; let me take some time to look at what they're actually asking for.
<cjwatson> basically a manifest-upgrade mojo spec
<cjwatson> in whatever runs those environments
<kruger> hi, someone can help me to rebuild a uefi cdrom? i've got an error which say: "(initramfs) Unable to find a medium containing a live file system" Any hints?
<bdmurray> How can I sort out / look into the Launchpad automatic translations being out of date for ubuntu-release-upgrader?
<bdmurray> cyphermox, slangasek: How can I sort out / look into the Launchpad automatic translations being out of date for ubuntu-release-upgrader?
<slangasek> bdmurray: no clue, I'm afraid
<slangasek> possibly a pitti question
<kruger> hi, someone can help me to rebuild a uefi cdrom? i've got an error which say: "(initramfs) Unable to find a medium containing a live file system" Any hints?
<cyphermox> kruger: that has nothing to do with uefi, fortunately :)
<cyphermox> kruger: did you indeed get a grub menu rather than a graphical splash when booting your CD?
<cyphermox> bdmurray: I don't know either, last upload was my first time ever touching ubuntu-release-upgrader :)
<kruger> cyphermox, no i've got a splash image because i've themed grub2
<cyphermox> kruger: fair enough, just making sure you don't expect it's booting uefi when it's not -- as long as it's indeed grub2, then you are in UEFI
<cyphermox> as for the live filesystem, that's a matter of the squashfs file that is typically in casper/
<cyphermox> if it's not the same filename, or not present, you'd need to pass an extra parameter in your preseed file, or on the command-line when starting the kernel
<bdmurray> cyphermox: Its about "Launchpad automatic translations update" not really being up to date so isn't ubuntu-release-upgrader specific.
<kruger> cyphermox: when i boot in standard bios mode all boot fine, but not when i choose uefi boot
<cyphermox> kruger: I suppose it's the command-line for grub then
<cyphermox> kruger: try passing 'live-media-path=' with the path to where your squashfs file is, on the kernel command-line
<kruger> cyphermox: in grub.cfg i've got this: http://pastebin.com/xk1G6rXx
<kruger> cyphermox: ok i try
<kruger> cyphermox: nothing to do
<tjaalton> hallyn: why is libvirt-bin stopped on package upgrade? seems to kill all running instances too
<tjaalton> either that or bug 1342083
<ubottu> bug 1342083 in libvirt (Ubuntu Trusty) ""Failed to create chardev" due to apparmor DENIED execute of "/usr/lib/pt_chown"" [Undecided,Fix committed] https://launchpad.net/bugs/1342083
<infinity> tjaalton: Why/how is your /dev/pts mounted incorrectly?
<hallyn> tjaalton: stopping libvirt-bin should absolutely not stop your instances
<infinity> tjaalton: (pt_chown is only called by glibc when creating ptys if /dev/pts isn't mounted with correct permissions)
<tjaalton> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
<infinity> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
<infinity> Note the gid and mode.
<tjaalton> where does it come from?
<infinity> tjaalton: That points at you likely having mounted a /dev/pts in a chroot by hand at some point, or a script having done so incorrectly.
<infinity> (Sadly, /dev/pts is, by default, a shared instance mount, so mounting a fresh one with incorrect options breaks your root mount too)
<tjaalton> hum, sbuild
<cyphermox> kruger: it would go better if you could print me a list of the contents of your image, but essentially that's the idea; you set live-media= or live-media-path=, depending on how it's set up. you may want to look at the source for the casper package.
<infinity> sbuild does it right.
<tjaalton> I don't do other that schroot/sbuild
<infinity> Well, I sbuild/schroot all day, and don't have any issues, unless your schroot has a local fstab modification.
<infinity> (by default, it's a bindmount, and thus DTRT)
<tjaalton> /etc/schroot/default/fstab:/dev/pts        /dev/pts        none    rw,bind         0       0
<infinity> Right, that works fine and wouldn't alter your boot-time mount options.
<infinity> But if you're positive that you didn't ever manually mount a /dev/pts (maybe a quick by-hand abuse of an unpacked chroot tarball or something?), we really should hunt down what broke it.
<tjaalton> uptime is only a month, running wily
<infinity> Cause I intend to drop pt_chown from glibc soon (it's a glaring security hole waiting to be exploited), and if people are breaking /dev/pts still, they get no more ptys after I do that.
<tjaalton> since.. a month or so
<tjaalton> hallyn: ok so you're off the hook then, I guess :)
<infinity> Well, he's not off the hook, really.
<infinity> Cause his apparmor profile should have allowed you to run pt_chown, and it didn't.
<infinity> So, a bit of WTF there too.
<tjaalton> well ok
<tjaalton> still, I'll reboot and see what I have
<infinity> Still, you wouldn't see the bug if your /dev/pts was sane.
 * infinity nods.
<tjaalton> yeah
<infinity> Do you use virt-install?
<infinity> I wonder if it does something dumb.
<tjaalton> sometimes
<infinity> Cause it basically debootstraps in a chroot, then converts it to a qemu image, right?
<infinity> Or something along those lines?
<infinity> So, it might be mounting /dev/pts in the chroot with incorrect options.
<tjaalton> what about piuparts?
<infinity> Also possible.
<infinity> I had planned to hack util-linux to force sane default mount options for devpts filesystems if none were specified, not sure how that dropped off my TODO. :/
<tjaalton> I'll check after a reboot
<tjaalton> sane pts, kvm instances start fine
<tjaalton> now piuparts..
<tjaalton> boom
<infinity> Laney: Hey, desktop guy.  What broke my desktop today? (fonts are wrong, and LIM aren't LI)
<tjaalton> hm, where did firefox & libreoffice launchers go from my left panel
<infinity> tjaalton: Yeah, confirmed the bug in the piuparts source.  Whee.
<tjaalton> cool
<sarnold> pitti: thanks for tracking down the recalcitrant retracers; 1502431 is now several days withuot tracing
<tjaalton> infinity: no way to fix the mount without rebooting?
<infinity> Laney: And firefox is unthemed...
<infinity> tjaalton: You can remount it with the correct options.  Or use piuparts after I feed you a patch. ;)
<tjaalton> heh, ok
<infinity> tjaalton: http://paste.ubuntu.com/12692496/
<infinity> tjaalton: Can you apply that 1-liner to /usr/sbin/piuparts and show me "mount | grep devpts" after a run?
<tjaalton> ok
<tjaalton> infinity: devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
<tjaalton> all good
<infinity> tjaalton: Ta.
<tjaalton> should it not bind-mount it instead?
<infinity> tjaalton: It probably should bind-mount most of its mounts, but I was going for minimally-invasive, not knowing the code or what it does.
<tjaalton> right, ok
<infinity> tjaalton: piuparts uploaded.  Thanks for the public whine and debugging. ;)
<infinity> tjaalton: I don't suppose you have any insight as to why my GTK theme's gone sideways after an upgrade/reboot?
#ubuntu-devel 2015-10-06
<pitti> Good morning
<sarnold> good morning pitti :)
<pitti> sarnold: just looking again, there are 195 unretraced issues; for some reason I now get tons of hash sum mismatches/download errors from Launchpad debs
<sarnold> pitti: ugh :/
<pitti> bdmurray: the downloaded debs say "None of the range-specifier values in the Range request-header field overlap the current extent of the selected resource."
<pitti> bdmurray: whatever that wants to tell me :/
<TJ-> pitti: Client user agent is asking for  e.g. byte-range 1000000-1005000 but the resource on the server is only 999999 bytes long
<sarnold> but why would apt download byte ranges instead of the entire file?
<TJ-> multiple connections?
<pitti> I suppose this is from the fallback for downloading debs/ddebs directly from Launchpad
<tjaalton> infinity: no u-s-d running?
<tjaalton> infinity: that's usually the case, or such. it can't/doesn't load the prefs
<tjaalton> and thanks for fixing piuparts :)
<pitti> smoser: is there some way to disable the overlayroot=tmpfs? With merely dropping it I can't log into the VM at all any more
<pitti> smoser: or maybe use a permanent overlay?
<doko> pitti, looking at the failed autopkg tests triggered by python-apt ... these seem to succeed, but the status update seems to be delayed for some hours
<doko> sitter, https://launchpad.net/ubuntu/+source/kde4libs/4:4.14.12-0ubuntu2
<sitter> brrr
<tjaalton> how to disable apparmor temporarily? aa-status shows profiles are in enforced mode even after "stopping" apparmor, same thing if I try aa-complain /etc/apparmor.d/*
<jjohansen> tjaalton: desktop/server?
<tjaalton> jjohansen: desktop
<jjohansen> tjaalton: stop does nothing to apparmor
<tjaalton> ok
<tjaalton> how useful :)
<jjohansen> you can use teardown
<jjohansen> which will unload all the profiles
<jjohansen> tjaalton: its because stopping apparmor puts the system in a bad state, you can't just restart it
<tjaalton> jjohansen: yep, that seems to work
<jjohansen> you need to restart all the servcies as well
<jjohansen> tjaalton: you can also use apparmor=0 on the grub kernel command line to disable it for that boot
<tjaalton> yeah noticed that, didn't want to reboot
<tjaalton> debugging an issue running tests in sbuild
<tjaalton> fails on ubuntu, works on debian
<tjaalton> (sssd)
<tjaalton> so trying this just for fun
<pitti> barry: python-pex fails on armhf/ppc64el now: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#wheel
<pitti> barry: it seems there is no "./script" to run there?
<pitti> barry: it succeeds on i386/amd64, so this looks like a built file; maybe the file exists, but it has a nonexisting hash-bang, i. e. missing test dep?
<dholbach> good morning
<tjaalton> when trying to upload to my own ppa I get "Half-converted block: incoming --> ~%(ppa)s", using dput-ng
<tjaalton> anyone know how to fix it?
<tjaalton> all the other ppa's in .dput.cf work
<wgrant> tjaalton: What's your dput commandline and your .dput.cf?
<wgrant> PPAs haven't required a custom .dput.cf for many years.
<wgrant> Since, like, Jaunty or something.
<tjaalton> wgrant: this is the "default" ppa which doesn't work http://pastebin.com/KZQQsfCw
<tjaalton> and note i'm using dput-ng
<tjaalton> could just be a bug in it actually
<cjwatson> That's not the default dput-ng config though
<wgrant> tjaalton: Hm, nowadays it's just "dput ppa:tjaalton/ppa"
<wgrant> I don't know if dput-ng supports that syntax, but I'd hope so...
<cjwatson> Not if you've manually modified incoming like that though
<tjaalton> yeah could be I've messed it since it started complaining
<cjwatson> The default is   incoming = ~%(ppa)s
<cjwatson> you probably want to set it back to that and use ppa:tjaalton/ppa or ppa:tjaalton/ubuntu/ppa
<tjaalton> so can't just use "dput alias foo_sources"=
<tjaalton> ?
<wgrant> If you want to have a stanza for each PPA you can.
<tjaalton> since it still complains even if I change incoming to "incoming = ~%(ppa)s"
<wgrant> What exactly does your config look like, and what is the command you're running?
<wgrant> If you have a variable in incoming, you need to have a value for that variable in the commandline.
<tjaalton> ahah, so can't use that then
<tjaalton> it's like on pastebin
<wgrant> The pastebinned version doesn't use a variable, though.
<tjaalton> no, since apparently it wouldn't work
<wgrant> With that one, you can indeed just "dput ppa whatever.changes"
<tjaalton> nope
<tjaalton> doesn't work
<wgrant> It does, if it's in the right config file.
<tjaalton> my "test" ppa with "~tjaalton/test/ubuntu" works
<wgrant> Unless dput-ng doesn't let you override existing stanzas, or something weird like that.
<wgrant> Most people just use the default 'ppa' stanza in /etc/dput.cf, which uses the variable.
<tjaalton> oh
<tjaalton> yeah now I see that /etc/dput.cf has the same stanza name
<tjaalton> yep, and having it in .dput.cf doesn't override the default, so had to rename mine
<tjaalton> then it works
<tjaalton> thanks :)
<wgrant> Interesting.
<wgrant> With normal dput, ~/.dput.cf wins.
<Laney> infinity: Did you fix it?
<Laney> It sounds like unity-settings-daemon went south
<tjaalton> wgrant: guess I'll file a bug against dput-ng
<tjaalton> now to the real issue.. certain sssd tests fail to run on launchpad and my own sbuilder created by mk-sbuild, but pass fine with the howto from https://wiki.debian.org/sbuild
<pete-woods> pitti: hey! another PR for dbusmock https://github.com/martinpitt/python-dbusmock/pull/13/files
<pete-woods> landing into the overlay vital (fixes important deficiency in connection activation)
<pete-woods> thanks for your time, in advance! :)
<infinity> Laney: unity-settings-daemon appears to be running.
<Laney> anything in ~/.cache/upstart/unity-settings-daemon.log?
<cjwatson> tjaalton: I'd start by diffing the installed package sets in the chroots (or maybe even diff -ru'ing the chroots)
<infinity> Laney: (unity-settings-daemon:1355): GLib-GIO-CRITICAL **: g_dbus_proxy_get_object_path: assertion 'G_IS_DBUS_PROXY (proxy)' failed
<infinity> Laney: Over and over.
<infinity> Laney: That's it.
<Laney> Sounds bad
<tjaalton> cjwatson: actually, it might be caused by the overlay, I'll test that first. Testing it with sid and on sid, so the package sets should be identical :)
<cjwatson> Oh, you mean sid passes but wily fails
<cjwatson> OK, certainly could be all kinds of reasons for that
<tjaalton> sid passes on sbuild with a tarball based chroot, fails with sid on my own ubuntu host and a sid vm with overlay-sbuild
<tjaalton> so building sid on wily fails (has always failed), building sid on sid w. tarball works
<lavii> hello to all
<lavii> as i am completely new to the ubuntu development. I am intrested in to fixing the bugs. so please help me form where i will start ???????
<cjwatson> tjaalton: There's no particular guarantee that the package sets are identical and you should check
<cjwatson> lavii: https://wiki.ubuntu.com/UbuntuDevelopment has various starting points
<lavii> sir, i start studying the packing guide
<tjaalton> cjwatson: ok
<lavii> cjwatson: thanks sir
<pitti> pete-woods: ack, will look; I have another one pending too
<pete-woods> pitti: I think there might still be some TODOs in jonas' powerd one
<cpaelzer> lavii: I totally like the doc cjwatson referred to, on top I sometimes like to read the same in "multiple views", so if you want you can also look at http://packaging.ubuntu.com/html/index.html especially section 4 and 5
<lavii> cpaelzer: Yes sir i also studying that sections....
<doko> Mirv, qtmake's defaults seem to be wrong on arm64:
<doko> $ fgrep -r -- -m64 /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++-64/
<doko> /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++-64/qmake.conf:QMAKE_CFLAGS            = -m64
<doko> /usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++-64/qmake.conf:QMAKE_LFLAGS            = -m64
<doko> there is no -m64 on this architecture
<seb128> mvo_, hey, saw bug #1503052? unsure if that's fixed with your rebuilds, but if some abi changed shouldn't the package name change or the library breaks on things?
<ubottu> bug 1503052 in aptitude (Ubuntu) "aptitude does not start - symbol lookup error" [Undecided,Confirmed] https://launchpad.net/bugs/1503052
<sitter> doko: kde4libs should be fixed in new upload. thanks for pointing it out
<tjaalton> cjwatson: ok, so extracted the tarball and made it an overlay schroot and tests pass there fine. package diff doesn't show much http://pastebin.com/kaQYx7E7
<cjwatson> ok, you probably know better than I do at this point :)
<tjaalton> heh, ok
<tjaalton> I'll let upstream replicate the setup and figure out why they fail
<infinity> Laney: Very helpful analysis. :P
<Laney> infinity: Sorry, I got distracted :(
<Laney> infinity: Does the problem still happen after a restart of unity-settings-daemon (and/or your session)?
<Laney> If so, maybe a backtrace with G_DEBUG=fatal-criticals would be good
<Laney> Assuming those criticals are current and the log isn't stale...
<infinity> Laney: So, killing u-s-d mostly fixed it, and relogging then was happy.  But rebooting returned it to the broken state.
<infinity> Laney: Which might point to something racey going on.
<mvo_> seb128: I have a look. the problem is that the abi name between debian and ubuntu was the same but the abi was actually incompatible because of a slightly different patchset for the gcc5 transition
<infinity> Laney: But also need sleep, so maybe I'll try to come up with a consistent reproducer tomorrow and file a bug.
<pitti> hey infinity!
<Laney> If it's giving you criticals you can find out where those are coming from with G_DEBUG=fatal-criticals
<pitti> infinity: what still needs to happen for bug 1435466?
<Laney> might point out what is racing with what
<Laney> infinity: 'night
<pitti> infinity: oh, nevermind then -- good night!
<Laney> Or maybe there are more warnings/criticals at startup time
<ubottu> bug 1435466 in nodejs (Ubuntu) "nodejs fails to build on arm64 due to libv8 dependency" [Undecided,Fix committed] https://launchpad.net/bugs/1435466
<Laney> Also unity-settings-daemon --replace --debug is good to know
<infinity> seb128: There is a Breaks from libapt-pkg to aptitude.
<Laney> But not that helpful if replacing doesn't fix the problem
<infinity> seb128: Which is probably good enough for upgrade, now that it's all migrated.  THere was just a window where it kinda went a bit oops.
<infinity> pitti: See my PPA with all the build failures, or for a good example, see node-srs in wily-proposed compared to sid.
<Laney> srs business
<pitti> infinity: ah, so it's not just missing manual testing, but fixing tons of packages too
<seb128> mvo_, thanks
<infinity> pitti: There's something fishy going on where forking gcc from node build scripts is breaking on Ubuntu but not Debian, need to sort out if (a) that's a regression we can blame on node4, and then decide how/when to fix it.
<mvo_> seb128: sorry for this, there was no better way to fix this (because it was already broken)
<seb128> mvo_, no worry
<infinity> mvo_: aptitude is fine how with the rebuild, AFAICT, I'd just close that bug if I were you.  We could have been more anal with an exact shlibdep version to force the issue, but I don't see this being a real problem for upgrades now that the world has migrated.
<Mirv> doko: ok. do you think it's used somewhere? I googled a bit and https://codereview.qt-project.org/#/c/81010/ ended with "Abandoned, It is actually not needed, jsu a matter of calling the non-64 mkspec"
<Mirv> (from a Debian maintainer)
<doko> Mirv, but the non-64 mkspec is missing a lot of the defines and includes in qplatformdefs.h
<infinity> mvo_: The problem would have been that aptitude migrated before apt (due to the lack of exact shlibdep), I suspect, but I'm not really worried about that upgrade order being a problem now.
<mvo_> infinity: yeah, I just checked in a schroot, looks fine in wily-current
<Mirv> doko: ok. if you could file a Debian bug against qtbase-opensource-src to state what's needed/missing I can discuss with the pkg-kde folks to see whether it needs an upstream bug report or what.
 * doko is removing libav 
<didrocks> doko: hey, did you get any progress on python 3.4.3 regression in trusty with barry?
<doko> didrocks, no, didn't get feedback from barry
<didrocks> doko: do you mind checking with him again? this regression is hurting badly in particular people using python in professional environment
<doko> didrocks, yeah, can ping him again
<didrocks> thx
<doko> Mirv, https://bugs.launchpad.net/debian/+source/qtbase-opensource-src/+bug/1503207
<ubottu> Launchpad bug 1503207 in qtbase-opensource-src (Ubuntu) "qtmake's linux-g++-m64 spec sets -m64 on aarch64-linux-gnu" [Undecided,New]
<Mirv> doko: thanks!
<smoser> pitti, i'm sorry. what was your question ?
<smoser> wrt disable overlayroot=?
<smoser> pitti, what i was doing to persist changes is just to mount-image-callback the original image and then make changes and then boot a new one. but i'll poke for a minute on getting a overlay to a disk.
<pitti> smoser: right, that's what I've done
<pitti> smoser: so this particular one is fixed now, but I'm sure the next bug will come :)
<smoser> pitti, where is 'fix-committed' committed ?
<pitti> smoser: as in "it's in proposed" (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#open-iscsi)
<pitti> smoser: I'm looking at the nova arm failure, just doing too many things at once
<smoser> pitti, thanks.
<smoser> i added some stuff to http://bazaar.launchpad.net/~smoser/maas/maas-ephemeral-sniff/revision/21
<smoser> mainly:
<smoser> a.) link to xkvm for you
<smoser> b.) suport for OVERLAY_DISK so you can get changes persisted.
<smoser> pitti, do you think just creating the /run/resolvconf/interface is the right thing to do ?
<smoser> rather than 'resolvconf --enable-updates'
<smoser> oh. wait.l that doesn't even do the mkdir itself.
<pitti> smoser: cool, thanks!
<smoser> i guess this is fine. unfortunate that we code that path in 2 places now.
<pitti> smoser: yes, like that we don't duplicate the --enable-updates, and don't break update-rc.d disable resolvconf
<pitti> smoser: this just puts the info into /run, and when resolvconf starts up for real, it'll see it
<pitti> smoser: worked fine in my testing, even with the additional "sleep 5" in resolvconf's unit to make it guaranteed-later than the udev rules
<pitti> smoser: yes, it's indeed not elegant, but with all the poking in ifupdown's innards that's going on there it doesn't make things much worse..
<smoser> yeah, i think its fine.
<smoser> it was guaranteed after 'mounted MOUNTPOINT=/run' in upstart boot
<smoser> which was when rsolvconf ran.
<smoser> its good. thank you.
<pitti> smoser: how was that guaranteed?
<smoser> because openiscsi ran after that.
<pitti> smoser: /run is pretty much the first thing that gets mounted (in fact, already by initramfs), so this isn't any real ordering restriction
<sil2100> doko: I'm looking now into the ubuntuone-client-data amd64 build failure, filling in a bug to track it
<sil2100> doko: I generally fill in a bug for every FTBFS I'm working on if anything
<pitti> smoser: right, but so did the udev rules; we just didn't have these rules in the past, but an upstart job
<smoser> pitti, in upstart *resolvconf* job ran on  mounted /run. so it ran very early, and that would block other stuff.  anything afeter virtual-mounts or whatever that event was.
<smoser> right.
<pitti> smoser: ah, resolvconf's upstart job blocked the udevadm trigger job?
<pitti> that would have done it (but sounds a bit odd)
<pitti> smoser: I thought about ordering resolvconf.service before systemd-udev-trigger.service, but it seemed unnecessary serialization
<pitti> smoser: it would work too, though
<smoser> pitti, well, we get to do this again for networkd :)
<pitti> smoser: heh, argh yes
<smoser> other parts of this setup will break there too.
<smoser> cloud-initramfs-dyn-netconf reads initramfs 'ip=' stuff and writes /etc/network/interface style files.
<popey> Got a bug for you lovely foundations people :) - just install nvidia-current on my MacBook Pro running 15.10 and now I can't type in my LUKS password. text doesn't go in the box, but over the top of the plymouth splash... http://imgur.com/mlCVqpL
<seb128> popey, 1386005 ?
<seb128> popey, seems like slangasek / cyphermox were looking at it at least
<cyphermox> popey: please file a new bug report
<cyphermox> use apport, so we got all that we need...
<popey> cyphermox: file the bug against plymouth?
<cyphermox> yes please
<popey> ok
<barry> didrocks: i'd like to get doko's opinion on LP: #1500768
<ubottu> Launchpad bug 1500768 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU break requests" [High,Triaged] https://launchpad.net/bugs/1500768
<popey> cyphermox: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1503306
<ubottu> Launchpad bug 1503306 in plymouth (Ubuntu) "Cannot enter LUKS passphrase after installing nvidia-current" [Undecided,New]
<popey> cyphermox: let me know if there's anything else you want from it
<cyphermox> popey: thanks.
<popey> np
<cyphermox> oh yay, I think I see a possible fix
<didrocks> barry: doko: another option, as the python new release introduces a regression, if this can't be fixed properly, is to revertâ¦
<seb128> barry, didrocks is right, you can't land a regression through -updates and deal with it through -backport letting LTS users with broken code by our fault
<seb128> barry, either we fix the components that are impacted, through -updates, or if we can't then we revert the change
<didrocks> while we are speaking about it, I have yet another bug opened due to thisâ¦
<didrocks> https://github.com/ubuntu/ubuntu-make/issues/156
<seb128> barry, LTS doesn't claim to be perfect, we prefer stability/not breaking exising users over fixing bugs that were there
<seb128> barry, let the incompatibile behaviour change to people doing serie upgrades, users on stable updates should be able to run production code without having risk to hit failures because things become incompatible
<sil2100> doko, seb128: working on this now https://bugs.launchpad.net/ubuntu/+source/python-traceback2/+bug/1503311 <- will try merging from debian as they have a "fix"
<ubottu> Launchpad bug 1503311 in python-traceback2 (Ubuntu) "FTBFS due to failing unit tests" [Undecided,In progress]
<barry> seb128, didrocks which is why i want to get doko's opinion on the bug.  i didn't land python 3.4.3,  so i don't know what's involved in reverting that specific change.  i suspect it's better to update requests and urllib3 than revert a security fix in python tho.  i'm willing to help with requests and urllib3
<didrocks> barry: my specific issue is that the regression is in distro for a couple of weeks, I did the debug and found the issue a week ago now and despite multiple pings, nothing is movingâ¦
<seb128> barry, are we sure that urllib3 is the only thing that is/can be impacted?
<didrocks> also 3.4.3-1ubuntu1~14.04.1 isn't in the security pocket, but -updates
<didrocks> the latest security update is 3.4.0-2ubuntu1.1
<didrocks> which was working fine
<didrocks> so reverting wouldn't have security impact (or it's been handled the wrong way, via the wrong channel)
<barry> no, i don't know what else might be affected.  there aren't any negative comments in python bug 22417 and this one was only found by us so far afaict
<ubottu> bug 22417 in valgrind (Ubuntu) "valgrind doesn't work with gstreamer based apps" [Medium,Fix released] https://launchpad.net/bugs/22417
<barry> https://bugs.python.org/issue22417
<slangasek> seb128, didrocks: there doesn't appear to be a bug tagged 'regression-update' for this SRU? https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-update&orderby=-id&start=0
<slangasek> (if an SRU has a regression, this is the preferred escalation path)
<slangasek> because yes, if there's a regression we should remove the package from -updates until the regression is fixed
<seb128> slangasek, yeah, barry said he would look at it and didrocks trusted that it would be handled
<seb128> we should have tagged it directly
<barry> well, i did look at it
<seb128> doing that now
<seb128> barry, well, it's a regression in a SRU of a LTS, it can break production code, it ought to be dealt with and not delayed :-/
<barry> i've found discussions in requests about the issue and they pointed to urllib3 which required a change to handle the issue
<seb128> barry, if the fix is not obvious the proper thing to do is probably to revert the SRU while the solution is being worked
<seb128> slangasek, didrocks, barry, tagged now
<didrocks> thanks seb128
<slangasek> thanks
<didrocks> barry: not only found only by us, see the duplicate + the bug above
<didrocks> barry: so, users (in corporate environment via proxy) gets this at least
<slangasek> didrocks, seb128, barry: so as there's a confirmed regression in python3.4 in trusty-updates, I'm going to back this package out again; debugging should happen in -proposed, not in -updates where it will continue to impact users
<seb128> slangasek, thanks a lot
<seb128> and +1 on debugging should happen in proposed
<barry> okay, but what i'm trying to say is that i didn't upload it so i want to get some opinion from the person who did
<didrocks> thanks slangasek
<slangasek> barry: getting opinions regarding the proper fix from the uploader is fine; but the policy to revert first when faced with a regression in -updates that isn't immediately fixed needs to not be a matter of opinion
<seb128> barry, yeah, sorry you got pulled in while trying to help, no blaming there, we should just have removed it from -updates by standard procedure and then let doko, who did the upload, sort out the regression
<barry> seb128: thanks
<bdmurray> pitti: Do you have any idea why the "Launchpad automatic translations update" would be running for ubuntu-release-upgrader but really be out of date?
<bdmurray> see bug 1502529
<ubottu> bug 1502529 in ubuntu-release-upgrader (Ubuntu) ""Upgrading Ubuntu to version " not translated" [Undecided,Confirmed] https://launchpad.net/bugs/1502529
<bdmurray> cjwatson: Do you have any idea why the "Launchpad automatic translations update" would be running for ubuntu-release-upgrader but really be out of date?
<cjwatson> bdmurray: There's no record of Launchpad ever having done a direct commit for that branch.  Why do you believe it to be running?
<bdmurray> https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk r2906 says there was an automatic translation update
<cjwatson> Oh, that's not the branch you quoted in the bug
<cjwatson> bdmurray: https://translations.launchpad.net/ubuntu-release-upgrader/trunk/+pots/ubuntu-release-upgrader/sv/+translate?batch=10&show=all&search=Upgrading+Ubuntu is where it actually comes from
<cjwatson> bdmurray: I suspect that it's sharing translations with vivid rather than with wily, because https://translations.launchpad.net/ubuntu shows the translation focus as vivid
<cjwatson> wgrant: ^- shouldn't we have updated that to wily at some point?
<bdmurray> hunh
<cjwatson> so pretty sure that's the root cause but I'm not sure of the usual process here
<bdmurray> cjwatson: okay, that's interesting
<sil2100> doko: looking for a sponsor of a sync to fix a FTBFS for wily: https://bugs.launchpad.net/debian/+source/python-traceback2/+bug/1503311
<ubottu> Launchpad bug 1503311 in python-traceback2 (Ubuntu) "Sync request of python-traceback2 1.4.0-3 from Debian testing: FTBFS due to failing unit tests" [Undecided,Confirmed]
<seb128> could somebody retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013/+build/8093872 ?
<cjwatson> seb128: done
<seb128> cjwatson, thanks
<kruger_> the uuid present in ".disk/casper-uuid-generic" is hardcoded inside the kernel (vmlinuz) on the dvd?
<genii> There's a bug in juffed which has been fixed since Nov 4 2014, the current package for Vivid has it, but Trusty and Utopic still don't ... is there some standard timeline for it to go into trusty/utopic universe ( where it normally is) or backports or is that not bothered with normally? ( bug 874479 ) In this case the fix was to install shared libs to /lib/x86_64-linux-gnu/  instead of legacy /usr/lib64/
<ubottu> bug 874479 in juffed (Ubuntu) "Cannot be run" [Undecided,Fix released] https://launchpad.net/bugs/874479
<sarnold> genii: it probably just takes someone preparing, building, testing debdiffs, then subscribing sponsors or asking for it to be handled during someone's patch piloting time
<genii> sarnold: OK, thanks
<wgrant> cjwatson: Translations are shared between series within a context, and then additionally between all linked contexts. The translation focus setting just affects links in the web UI, and it is managed by Ubuntu's translation people.
<doko> sil2100: done
<sil2100> doko: thanks!
<ginggs> hi, who can i bug about a MIR (LP: #1421209)?
<ubottu> Launchpad bug 1421209 in nvidia-modprobe (Ubuntu) "[MIR] nvidia-modprobe" [Undecided,New] https://launchpad.net/bugs/1421209
<sarnold> ginggs: probably tyhicks, when he returns from vacation; I doubt we'll have time to get to this one before 15.10 is released, though.
<ginggs> sarnold: thanks :(
<sarnold> ginggs: why do they have their own package for it rather than just a udev script and instructions "add this line to your /etc/modules"?
<ginggs> i have no idea
<sarnold> it'd be worth pressing nvidia for an answer on that one; there's a reasonably good chance I'll do the security team portion of the MIR and I'm certainly going to be looking for an answer to that question :)
<cjwatson> wgrant: Hm.  That was my best guess.  Do you know why that ubuntu-release-upgrader trunk translation matches 15.04 rather than 15.10 then?
<wgrant> cjwatson: Because the English string is different.
<ginggs> sarnold: thanks, I've just passed that on to tseliot
<wgrant> 15.04 vs 15.10
<sarnold> ginggs: thanks!
<wgrant> ubuntu-release-upgrader trunk says 15.04, so it shares with Ubuntu's 15.04 string
<wgrant> cjwatson: Looking over scrollback, it seems that the underlying problem is that the template is not updated in the upstream project.
<wgrant> cjwatson: The translations being exported are current for the upstream project.
<wgrant> The template in wily just happens to be different.
<cjwatson> wgrant: aha, right, that would make sense, I wonder why wily differs
<cjwatson> bdmurray: ^-
<wgrant> Well
<wgrant> The most likely problem is that someone is that someone just hasn't uploaded the new template to the ubuntu-release-upgrade project.
<wgrant> (or the autoimport is disabled, or not approved, or something)
<wgrant> It seems reasonable that wily's template should refer to wily's version.
<cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/po/ubuntu-release-upgrader.pot still shows the 15.04 string
<wgrant> That'd do it.
<cjwatson> Right, I meant I wonder why trunk differs from wily
<cjwatson> Suggests somebody goofed
<wgrant> And here I was trying to investigate a potential translation sharing bug!
<wgrant> That's a nice easy solution.
<cjwatson> Looks to me that somebody needs to regenerate the .pot and commit it to trunk
<cjwatson> The source file is correct: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/data/gtkbuilder/DistUpgrade.ui
<wgrant> Aha
<cjwatson> So it probably got regenerated as part of a source package build somewhere
 * cjwatson explains the situation in https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1502529
<ubottu> Launchpad bug 1502529 in ubuntu-release-upgrader (Ubuntu) ""Upgrading Ubuntu to version " not translated" [High,Confirmed]
<wgrant> Thanks.
<cjwatson> infinity: https://code.launchpad.net/~cjwatson/ubuntu-archive-publishing/inline-release/+merge/273622 if you get a minute
<wgrant> cjwatson: The things to remember about sharing are that only translations for identical English strings are shared, and the rules defining the sharing subset are documented in the large comment in _queryPOTemplates
<wgrant> And if anyone ever removes a Packaging link, you can be reasonably confident that translation sharing is broken even within the distro or product for both ends of that link without manual intervention.
<cjwatson> Yeah.  Particularly great since literally anyone can change Packaging links
<wgrant> :D
<infinity> cjwatson: Looks reasonable, though "(re-)signing $CANDIDATE inline" seems a little harder to parse than just "(re-)signing $INRELEASE" would be, no?
<infinity> cjwatson: All looks logically sane, though.
#ubuntu-devel 2015-10-07
<robert_ancell> tdaitx, hey, are you working on bug 1503450 at the moment? I didn't see your branch
<ubottu> bug 1503450 in Mir "mesa FTBFS due to missing Requires in mirclient" [High,Triaged] https://launchpad.net/bugs/1503450
<tdaitx> robert_ancell, yeah, I made a mistake fetched ubuntu/mir/, thus the merge had a lot of differenced and conflicts, I'm redoing it for lp:mir now
<robert_ancell> tdaitx, ok, I'll delete my branch - I added some comments on the bug.
<tdaitx> robert_ancell, nice! just saw your comments, thanks for the help =)
<robert_ancell> tdaitx, np, thanks for finding the issue :)
<tdaitx> robert_ancell, I had a feeling that Requires.private might be better, but I'm not that familiar with pkgconfig
<robert_ancell> Requires.private is super confusing
<tdaitx> robert_ancell, I saw your commit now, go ahead with it... I'm acquiring experience and evidence to apply for ubuntu dev, but your commit is way better, so go ahead =)
<robert_ancell> tdaitx, ok
<tdaitx> robert_ancell, btw, your commit still uses Requires instead of Requires.private
<robert_ancell> tdaitx, ah, I forgot the last commit!
<tdaitx> =)
<ScottK> slangasek: If the python3.4 regression made it to updates, shouldn't another SRU be uploaded that reverts the regression?  Simply removing it from updates doesn't get the regression off the systems where it was installed.
<slangasek> ScottK: yes, but as the SRU was a new upstream version I've not been eager to initiate the 3.4.3.really.a.ball.of.lint dance.  I will do so if there's no progress in a day or so
<ScottK> OK.
<ScottK> I'm a bit surprised Ubuntu is doing full version updates of Python.  I'm not particularly surprised it didn't end well.
<sitter> pitti: http://autopkgtest.ubuntu.com/packages/k/kdevelop/wily/armhf/ probably needs a retry? Temporary failure resolving 'ftpmaster.internal'
<pitti> bdmurray: I'll look in the bug and reply there, but it seems cjwatson already responded with the reason
<pitti> sitter: yes, retrying
<pitti> Good morning
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<dholbach> seb128, dpm: https://translations.launchpad.net/ubuntu/ says translation focus is vivid - is that right?
<seb128> dholbach, I guess that should be changed to wily
<dpm> dholbach, seb128, done, well spotted
<seb128> thanks
<dholbach> thanks
<rbasak> Any thoughts on an eventual SRU for bug 525674? Appropriate? Patch too invasive?
<ubottu> bug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed] https://launchpad.net/bugs/525674
<rbasak> infinity: ^
<pitti> rbasak: oh my, please
<pitti> rbasak: it doesn't seem very invasive to me, it merely runs the apt-check bits in the background, no?
<pitti> i. e. ( existing code ) &
<pitti> (and yes, agreed that it is really annoying)
<cpaelzer> the only other than the ( existing code ) & is the try to fix concurrent updates
<cpaelzer> this became more obvious with the async version, but was broken before as well for multi logins
<pitti> cpaelzer: ah, by redirecting into $tmpfile first, and atomically moving to $stamp
<cpaelzer> pitti: that was the idea
<cpaelzer> pitti: and a cleanup added on rbasak first review to avoid stale files in /tmp
<pitti> for stable SRUs this seems fine; for wily and upstream, coud this perhaps move into /etc/cron.daily/apt or a similar daily cronjob?
<pitti> running this check on every login seems like a waste
<cpaelzer> pitti: I wanted to keep the update policy as close to the original as possible - anyone can later on move the check somewhere else
<cpaelzer> but for the given update I'd keep it small
<cpaelzer> it is a first step to move the updating somewhere else, but for now just tries to fix the immediate issue
<pitti> ack
<rbasak> pitti: yeah it just moves things to the background, but though I like the approach and I can't find anything wrong with it, it feels like it's ripe for odd bugs to crop up to me. IOW I wouldn't be surprised if something came up.
<rbasak> I guess a cronjob is reasonable, given that it's always going to be out of date on first login.
<pitti> the obvious change in behaviour is that the first time that you log in it won't show up, but that seems fine
<pitti> it's almost certainly right after a fresh install
<pitti> right
<pitti> the cronjob avoids concurrency and blocking login at the same time, so structurally it seems even easier to me
<rbasak> What's almost certainly right? cpaelzer's patch?
<pitti> but this is running as user, so it doesn't take an apt lock, does it?
<rbasak> It does run as root.
<pitti> rbasak: I mean the first login is almost certainly after a fresh install, i. e. it doesn't matter if it doesn't do the check there
<rbasak> Ah
<pitti> I meant "right after" -> immediately after, not "it is right"
<rbasak> I meant first login after a while, ie. when it's slow.
<cpaelzer> still it takes no apt lock
<pitti> yay language ambiguities :)
<cpaelzer> the call to apt-check runs fine as user, so no apt lock involved
<rbasak> On a default system, what runs apt-get update to keep that up to date?
<cpaelzer> rbasak: yeah this would be the right place to update the file ...
<pitti> rbasak: supposedly /etc/cron.daily/apt ?
<rbasak> ie. is installing unattended-upgrades or similar required to keep this updated, or are we running regular apt-get updates already?
<pitti> ah, is that being called through PAM? otherwise, how can it run as root when you log in as user?
<pitti> rbasak: we've done for many years
<rbasak> Yeah update-motd is a PAM module
<cpaelzer> actually in /etc/cron.daily/apt is even already a function that updates a marker update_stamp in case anytihng interesting had changed
<cpaelzer> it updates various timestamps after autoclean, unattended-upgrade, dist-upgrade, ...
<cpaelzer> pitti: rbasak: that would be just the spot to update the info for the motd
<cpaelzer> so again not very invasive ...
<cpaelzer> it would also avoid having to create a new daily cron and so on
<rbasak> Crossing an abstraction boundary here.
<cpaelzer> rbasak: between packages?
<rbasak> Which is OK, but maybe quite a bit of this functionality needs to move into the package supplying /etc/cron.daily/apt
<rbasak> cpaelzer: right
<rbasak> Or maybe all of the logic even
<cpaelzer> rbasak: but you are right and it would be an issue - the apt-check command is part of update-notifier and not apt (despite its name)
<rbasak> Ah
<rbasak> And we can't really have apt depend on update-notifier
<cpaelzer> so it would force everybody (apt is always there) to have update-notifier :-/ not what I want
<rbasak> OK so the logic has to stay in update-notifier
<cpaelzer> yes
<rbasak> What's the cleanest way to cross the boundary?
<rbasak> update_stamp
<rbasak> mvo: ^^ any opinion?
<cpaelzer> rbasak: the cleanest is probably to use as few dependencies as possible and just do a bi-daily update or so
<rbasak> Maybe have an update-notifier cron.daily job check update_stamp as left by apt's cron job, and if it is newer than the cached motd then update it?
<cpaelzer> no hooks or relying on knowing another packages file names
<rbasak> cpaelzer: that sounds reasonable
<rbasak> I think we prefer to use cron.daily where possible, so everything runs at once
<cpaelzer> rbasak: to bad there is no ordering in there
<cpaelzer> rbasak: running AFTER each cron.daily/apt would be great
<cpaelzer> wait a second
<cpaelzer> there is a /etc/cron.daily/update-notifier-common - WTF
<pitti> oh, I'm in the news! http://lwn.net/Articles/657345/
<mvo> rbasak: sorry, wasn't following - if apt-check needs to move e.g. into apt itself we can consider that. I need double check if its a good fit
<mvo> pitti: woah!
<rbasak> mvo: I'm not sure apt-check itself needs to move, but we want to change the logic around when the update-motd stuff happens
<rbasak> mvo: so it doesn't block login. So from cron maybe, but not sure where the best fit is.
<rbasak> Preferably after apt-get update runs
<rbasak> brb
<didrocks> pitti: with a great smile, as usual :)
<pitti> and one of my favourite T-shirts :)
<didrocks> pitti: classic Monkey Island ;)
<cpaelzer> rbasak: if we want to be "just after" updates we would need to move apt-check to the package "apt"
<cpaelzer> rbasak: but if we want to keep it simle we can just hook into the already existing /etc/cron.daily/update-notifier-common
<mvo> rbasak, cpaelzer: we could add apt-check --human-readable as a hook into APT::Update::Post-Invoke-Success
<cpaelzer> rbasak: still for now keeping the fix as simple as it is might be ok - on the other hand nothing stays longer than a good workaround :-/
<mvo> and make it write the data to a file that is just cat on login
<mvo> this way its always up-to-date and can still be part of u-m-common
<mvo> the downside is a lightly slowe apt-get update, but then the cache is hot so it should be fine
<mvo> (unless I miss something)
<cpaelzer> mvo: ah so one could hook just after an update with APT::Update::Post-Invoke-Success without a reverse dependency
<cpaelzer> yet I see a small fix getting more and mre complex :-)
<cpaelzer> pitti: seems to be monkey island day - just got this refferred this morning https://chinstrap.canonical.com/~smb/askme-2.png
<pitti> cpaelzer: you fight like a cow!
<smb> I am shuddering :-P
<pitti> oh the times -- I can't be grateful enough to the makers of ScummVM
<mvo> cpaelzer: yeah, exactly. this might actually reduce complexity but yeah, its different from what was done before
<cpaelzer> mvo: well /etc/apt/apt.conf.d/ seems rather clear - just looked into that
<cpaelzer> mvo: do you know how the new numbers are made up there - just pick one for ordering?
<pitti> cpaelzer: as I said, I think this fix is still good for stables; it's just not very elegant
<pitti> (for the future, I mean)
<pitti> not elegant> the whole current architecture I mean, not the fix in particular
<cpaelzer> pitti: I can read your shirt's text - so I'm obliged to like to over-engineer
<cpaelzer> and I like the APT::Update::Post-Invoke-Success approach mvo suggested
<mvo> cpaelzer: yeah, just one for ordering
<kruger> hi, i've rebuild a ubuntu dvd with a new kernel version (taken from ubuntu source) but i'm unable to boot in uefi mode -i've got (initramfs) error-, but i'm able only to boot in bios mode. Whats' wrong?
<cpaelzer> rbasak: maybe the fix as is for SRU (if we want it as SRU) and the more complex but eventually cleaner one for wily&upstream ...
<cpaelzer> mvo: regarding slower apt-get update - we can still keep it asynchronous, so it shouldn't add a reasonable delay
 * mvo nods
<rbasak> cpaelzer, mvo: I like the APT::Update::Post-Invoke-Success idea. You're suggesting the update-notifier packaging dropping something into /etc/apt/apt.conf.d/ that sets it, right? And the script will just cache the result for the update-motd script later?
<rbasak> So cpaelzer's patch for the SRUs, and this for Wily/Wily+1?
<pitti> that sounds wonderful
<cpaelzer> rbasak: yes
<rbasak> +1
<cpaelzer> rbasak: ok, that sounds like an agreement - I'll come up with some code for that
<pitti> then it would run exactly once, exactly when needed, and there's no collision from multiple logins, or delays of those
<rbasak> It's really elegant. The cache should be hot (and we could background it if needed as cpaelzer says), and then the cached output will always be current.
<rbasak> Right.
<rbasak> If backgrounding then need to be careful about collisions.
<rbasak> I find the "watershed" program really handy for this. IMHO it should be somewhere more common.
<rbasak> mvo: would multiple things that set APT::Update::Post-Invoke-Success in apt.conf.d add to the list or override?
<rbasak> Ah, nm. I think the manpage is telling me that it will append.
<cpaelzer> rbasak: there are already 4 in my current system
<pitti> rbasak: flock from util-linux? it's okay to just fail if it's already running
<pitti> watershed seems like a very rare corner case -- ISTM that either you only ever want one run (potentially triggered several times), or serialize all triggered runs
<pitti> watershed runs the program once or twice, which I find a bit odd?
<pitti> ah, this is to "mop up" the extra requests with just one extra run, I see
<pitti> nevermind
<pitti> but in this case flock is better
<rbasak> pitti: say I run apt-get update twice, and we async the apt-check. If apt-check hasn't finished by the time my apt-get update finishes, I want to run it again to get it up to date.
<rbasak> pitti: so I think watershed is the correct logic here ideally. But it's not worth pulling in a dependency just for that.
<pitti> running apt-check twice in a row sounds like a waste, isn't it?
<rbasak> Not if the first one started too early to produce up-to-date results
<rbasak> As another example I use watershed + rsync to trigger an rsync when a new file arrives.
<rbasak> Cheap and nasty 1-way realtime replication
<cjwatson> infinity: Thanks, fixing and taking that as an approve vote.
<infinity> cjwatson: I didn't look at it with context.  Is that limited to dirty suites, or will it magically create InRelease files for all old suites on first run?
<cjwatson> infinity: All of them.
<cjwatson> Which I think is what we want?
<cjwatson> It does end up changing ordinarily immutable stable suites, but only to the tune of creating that file
<infinity> cjwatson: yeah, that's fine.  Lemme just quickly look at context.
<infinity> cjwatson: Okay, gpg_opts is responsible for key-picking, shiny.  Have you tested that the double-signing trick works for InRelease as well as detached sigs?
<infinity> (Don't see why it wouldn't, but would be nice to make sure apt won't barf, since it'll suddenly favour InRelease as soon as it leaps into existence)
<cjwatson> Not specifically, but let me try.
<xnox> arges: your core-dev membership is expiring in 9h
<infinity> Which reminds me, I need to cargo-cult that bit for ubuntu-cdimage and re-sign some history.
<xnox> soren and james_w expired =( oh well.
<Laney> I usually check the mail to see if expired people were active
<cjwatson> infinity: OK, after signing wily's Release file with both my old and new personal keys: http://paste.ubuntu.com/12703167/
<cjwatson> which looks fine to me
<cjwatson> Let me just try with trusty and precise to make certain
<cjwatson> I think precise has InRelease support disabled
<apw> pitti, are you able to get a ps listing out of one of the lxc hangers, as the logs are not complete (according to stgraber)
<infinity> cjwatson: Huh.  Does apt warn about a single missing key on the detached sigs too?
<cjwatson> trusty behaves the same way except that I have to use a short key ID to apt-key del
<cjwatson> infinity: Pretty sure I remember it doing that
<infinity> cjwatson: That seems kinda crap, as retiring one from the keyring entirely would make double-signed suites throw warnings.
<infinity> cjwatson: But if it behaves the same for both, that's not a problem for today.
<cjwatson> Yep, it sure does.
<cjwatson> (schroot -c trusty-amd64 -u root, apt-key del 437D05B5, apt-get update)
<infinity> cjwatson: Speaking of.  Can we drop the old sig (and key) for 16.04?  Pretty sure we can.
<cjwatson> I assume we'd stop double-signing if we were doing that.
<cjwatson> infinity: Should be able to.
<cjwatson> infinity: Let's do it when we open?
<infinity> And yeah, we should stop double-signing and drop the key together, given the warning being otherwise very scary. :P
<infinity> cjwatson: Is there any argument for rotating a new key in, rather than just dropping the old one?
<cjwatson> Possibly, but we'd need to generate one.
<infinity> Well, yes.
<infinity> But I think Bluefin has nearly enough shards to do that.
<cjwatson> I think we would have three at the release sprint, if we warn a couple of sysadmins.
<cjwatson> Right, and precise ignores InRelease, as I remembered.
<cjwatson> So this looks fine.
<infinity> cjwatson: Excellent.  +1 from me, then.
<cjwatson> Let's blow stuff up while I have plenty of day left. :-)
 * infinity is going to go grab a bit of food, since sleep has completely eluded him.
<infinity> cjwatson: I'll be back in time to see the world burn.
<hyperair> why do you think there'll be any world left to burn?
<cjwatson> Deployed.
<infinity> Ahh, a quick proposed-only run too.
<infinity> Handy.
 * infinity watches.
<cjwatson> Haha it's resigning dapper
<cjwatson> pepo FTW
<cjwatson> (not that it matters, it won't be mirrored)
<infinity> Yeah. ;)
<infinity> cjwatson: Throwing stuff at a PPA to see how apt loves the new ftpmaster.
<cjwatson> It'll be fiiiine.
<infinity> cjwatson: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
<cjwatson> Looking good so far.
<infinity> That really shrinks the apt-get update output.
<infinity> cjwatson: I don't see precise ignoring it at all...
<infinity> cjwatson: It totally favoured InRelease.
<infinity> (But also seems to have worked)
<cjwatson> Definitely ignored it here, but OK.
<infinity> https://launchpadlibrarian.net/220504260/buildlog_ubuntu-precise-amd64.hello_2.7-2_BUILDING.txt.gz
<cjwatson> Oh
<cjwatson> Baseline precise
<cjwatson> It was disabled in precise-security
<infinity> Ahh, cute.
<infinity> Not that I care, as we implicitly trusty ftpmaster.internal.
<infinity> But a bit entertaining that we're using, I assume, an insecure codepath.
<cjwatson> Yeah, I think it's not particularly worse than before, AIUI it's not like the natty thing where any signed material anywhere can be used to construct a compromise.
<cjwatson> Now I wonder how many layers of caching are between me and archive.u.c
<infinity> cjwatson: Looks happy across the board.
<cjwatson> Great.  An update here hasn't spotted it yet, but I guess syncproxy will take a while to catch up.
<cjwatson> Thanks for the test.
<infinity> syncproxy runs in < 2m, IIRC, but frontends are a little more slack.
<pitti> apw: yes, I can start the test and then lxc-attach to it to do anything you (or stgraber) likes
<apw> pitti, i think there are two existing ones jammed right now (well were last i looked)
<apw> pitti, but i think the ones which are working are the lxc ones, it is the proper instance ones which are jamming
<pitti> apw: lxc-in-cloud-instance (i386, amd64) work fine; lxc-in-lxc (armhf, ppc64el) hang indeed
<cjwatson> infinity: There was a lot of mirroring infrastructure to fix up.  Hopefully I got it all.
<pitti> apw: running the test locally fails fast, so I guess it's trying to download something and fails on the proxy or something such
<infinity> cjwatson: Oh.  Balls.  You did fix all the 2-stage scripts to exclude InRelease, I hope?
<cjwatson> infinity: Yes
<cjwatson> Or at least I certainly tried
<cjwatson> infinity: See the enormous pile of private MPs attached to the bug for misc deployment stuff
<infinity> cjwatson: Including ports, which doesn't use the one from the charm because reasons.  Or was that us.ports?
<cjwatson> infinity: Yes, I got ports
<cjwatson> And us.ports
<cjwatson> us.ports is the weird one, I think.
<infinity> cjwatson: So, they worked around the juju issue that wasn't allowing them to actually deploy to mirror frontends before? :P
<cjwatson> infinity: https://rt.admin.canonical.com/Ticket/Display.html?id=84674
<infinity> cjwatson: Yeah, ports itself is a syncproxy (so, magicmirror), us.ports uses a fork of the 2-stage mirror script instead of the generic one, for some reason or other.
<cjwatson> I think they may have done it by hand again.
<cjwatson> Get:1 http://archive.ubuntu.com wily InRelease [218 kB]
<cjwatson> aha
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/wily/ shows differing timestamps though, why
<cjwatson> I guess rsync doesn't update them if the file contents haven't changed
<infinity> magicmirror resets some timestamps.
<infinity> Because lamont.
<cjwatson> Oh, I removed that but maybe it hasn't been deployed
<cjwatson> https://code.launchpad.net/~cjwatson/canonical-magic-mirror/remove-timestamp-hacking/+merge/272718
<infinity> ...
<infinity> How is InRelease *older* than Release?
<cjwatson> Because magic-mirror knows to touch Release/Release.gpg but not InRelease
<infinity> Oh, right.  So, it is the lamont bit.
<infinity> Gross.
<infinity> We fixed that on the publisher side ages ago, right?
<cjwatson> Except I thought I'd got a magic-mirror change deployed to touch InRelease, actually
<cjwatson> So that's a bit weird
<cjwatson> infinity: I did the last bit of the fix quite recently.
<apw> your removal is unmerged
<infinity> It is, but it should be touching InRelease, looking at the current code.
<infinity> So a bit WTF.
<infinity> Oh, but that was recent too.  So maybe never actually deployed.
<cjwatson> apw: Right, I know the removal is unmerged but indeed the previous allegedly-deployed version touched InRelease
<cjwatson> Chasing that up
<pete-woods> pitti: is there anything I can do to help expedite the dbusmock stuff? write the release notes, perhaps? I've checked the tests with pep8, pyflakes, etc already
<sil2100> pitti: ping! Hey, we didn't seem to get langpack-o-matic translations yesterday uploaded to the overlay
<sil2100> pitti: did anything happen to those?
<infinity> cjwatson: So, I'm kinda hoping this is coincidence, but we also seem to have blown up the frontends. :P
<cjwatson> ?
<infinity> apt-get update is now downloading at a snail's pace.  Or not at all.  Undecided.
<infinity> I thought it was a local thing, but another user just complained.
<cjwatson> Maybe they're remirroring lots or something?
<infinity> Or deleting half the archive.
<infinity> cjwatson: Can you reproduce, or am I and said user just going insane?
<cjwatson> I can
<cjwatson> Though I wouldn't normally put much stock in a network problem visible from behind my ADSL
<cjwatson> (Or what could easily be a network problem)
<infinity> Okay, load must be through the roof.  telnet just took 10s to get apache to say hi on one of them.
<infinity> This seems like a bad sign.
<cjwatson> See #is-outage
<doko> pitti, please override node-srs's autopkg test again (triggered by gdal)
<doko> infinity, or you ^^^
<pitti> sil2100: I rebuilt the -base packages manually to fix the desktop translations, so the cronjob didn't run again
<pitti> sil2100: I can run it manually if needed
<sil2100> pitti: yes, please :)
<pitti> sil2100: running
<sil2100> We're in freeze so we want to build out image candidate
<sil2100> Thanks!
<rvr> pitti: Cool, thanks!
<didrocks> slangasek: doko: shouldn't we rather upload a revert for bug #1500768 matching the previous content of -security as the faulty SRU has been released for quite a while (and so most of people upgraded to it) and there is no assignee anymore working on it?
<pitti> doko: done
<ubottu> bug 1500768 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU break requests" [High,Triaged] https://launchpad.net/bugs/1500768
<sil2100> barry: ^
<doko> didrocks, I'm looking at it, and I think we should not yet
<didrocks> doko: can you assign yourself to this bug please? The regression is already around for a couple of weeks
<doko> didrocks, nobody told me until recently
<didrocks> doko: last week was my first ping for you about it
<doko> "couple of weeks" != last week
<didrocks> doko: the issue started when python3.4 hit -updates, so a couple of weeks
<didrocks> doko: then, time for me to debug it (didn't want to blame python before checking it's not my side), I did debug it when I could
<didrocks> and found the exact interaction issue last Tuesday (so a week ago)
<didrocks> but people DO experience it for a couple of weeks
<didrocks> which is what matters here IMHO
<infinity> jibel, pitti, Laney, apw: Can you guys reply to that release sprint email, so clan knows what's up?
<infinity> jibel: You especially, since I wasn't sure if you wanted to come, or send a minion, or both.
<seb128> when/where is it?
<infinity> seb128: London, release week.  Unless you meant where's the mail, in which case, it was sent to the people mentioned. :P
<seb128> no, just curious
<seb128> desktop team is in London next week
<seb128> but that's one week before
<seb128> so maybe Laney wins the right to have another week in the office ;-)
<pitti> infinity: not quite sure yet; I've been/will be travel quite a lot these days, and at the weekend before we have a big family event in Dresden
<Laney> replied, ta for the reminder
<infinity> pitti: Sure.  If you think it's not going to work for you, cyphermox might be a better choice.
<infinity> pitti: But he's also a more expensive choice, so I need to make that call soon. ;)
<cyphermox> oi
<lamont> infinity: the lamont bit was just updating it to be faster at merging all of hte stay of execution files
<lamont> stay of execution predates me\
<infinity> lamont: I think the lamont thing I was blaming you for was the timestamp mangling in magicmirror.  Which was totally you.
<infinity> lamont: But that was hours ago, and I blame you for a lot of things, so maybe I'm mistaken. :P
<lamont> infinity: I have no memory of that action.
<infinity> lamont: There's a bug log that has memory on your behalf. ;)
<lamont> I'll believe that
<infinity> lamont: https://bugs.launchpad.net/launchpad/+bug/1033581
<ubottu> Launchpad bug 1033581 in ubuntu-archive-publishing "Publisher should set modification times on Releases et al" [Low,Fix released]
<xnox> barry: 3.5 not default?
<xnox> =(
<barry> xnox: it will be for xnoxian xenomorph
<xnox> barry: but i need it now =) to reproduce openstack bugs which modify ordereddicts whilst interating it ;-)
<xnox> fine, i can fille with it.
<xnox> =)
<barry> :)  it is supported for wily, so just `python3.5`
<cpaelzer> mvo: pitti: rbasak: you were such a great help this morning - FYI on the bug https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674 is the fix as discussed. Any review is welcome
<ubottu> Launchpad bug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed]
<morphis> bdmurray: seb128 told me you're the one who can add me to the bugsquad team :)
<rbasak> cpaelzer: thanks! Based on your comment this sounds good. I'll review the patch.
<pitti> cpaelzer: replied
<cpaelzer> piiti: thanks will, read it and agree to you - I'll come with a modified version the next days
<pitti> cpaelzer: it's pretty much bikeshedding at this point; I don't like that indirection/new script particularly much, but it's not at all wrong
<pitti> so if you prefer having it, keep it :)
<cpaelzer> pitti: I have removed one indirection on my own, just missed the other opportunity
<cpaelzer> pitti: and all that is training in packaging and versioning to me :-)
<pete-woods> pitti: thanks very much for the work on dbusmock! :)
 * pete-woods watch rmadison python-dbusmock now ;)
<pitti> pete-woods: I didn't upload it yet (sorry, being over-pinged)
<pete-woods> I understand
<pitti> pete-woods: if it's urgent, you can always cherry-pick and directly upload to the overlay, no?
<pete-woods> I can see you're really busy just from this channel
<pete-woods> I have no power, so can't upload to the overlay
<pete-woods> kinda wish I could operate dbusmock via the citrain
<pete-woods> but I guess that makes having it in debian harder?
<sil2100> barry: hey hey! I'm slowly tackling some python-* FTBFS from the wily test rebuild if you don't mind :)
<sil2100> barry: https://bugs.launchpad.net/ubuntu/+source/python-pysaml2/+bug/1503698 is on my plate once I'm finished with some touch tasks
<ubottu> Launchpad bug 1503698 in python-pysaml2 (Ubuntu) "FTBFS due to broken unit tests" [Undecided,In progress]
<barry> sil2100: excellent!  ping me if you need review/sponsorship
<pitti> pete-woods: I uploaded a cherry-pick to the overlay, that's the fastest way
<pete-woods> pitti: awesome, this is very much appreciated!
<pete-woods> pitti: it'd be super awesome to be able to pass template parameters in through the main command line when you do python -m dbusmock -t mytemplate ????
<pete-woods> but my python-fu isn't so great
<pete-woods> I'd be happy to work on the feature
<pete-woods> if you had a suggestion of how to encapsulate the parameters
<pete-woods> maybe as json?
<pitti> pete-woods: there's no proper data types with plain strings, so only strings would work properly; JSON is also not typed
<pete-woods> it's not?
<pitti> pete-woods: ah, it can tell apart ints and strings indeed
<pete-woods> I thought it had all the types of javascript
<pete-woods> bool, string, array, number, etc
<pete-woods> and also dict
<pete-woods> it might not be perfect
<pitti> pete-woods: so I guess it's one of json (ugly to type), gvariant-ish like "gdbus", or just live with strings and int only
<pitti> most properties are simple, after all
<pitti> pete-woods: but in the end it seems easier to change them after instantiation via some d-bus calls?
<pete-woods> pitti: that involves standing up separate comms channels, right? e.g. to remove some of the default setup
<pete-woods> I saw this as a way of supporting the existing parameters mechanism that is already supported by most of the modules
<pete-woods> sorry, templates
<pete-woods> without the need to modify all of the templates, to add the capability to remove the default setup
<pete-woods> e.g. in the case of ofono, it adds a modem by default
<pete-woods> which you don't always want
<pete-woods> but it already has a parameter to avoid it adding the default modem
<tdaitx> rbasak, any updates on the squid3 merge?
<popey> cyphermox: got another one of these plymouth bugs from a friend who bought a brand new thinkpad x1. first update (14.04) broke it :S https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1503716
<ubottu> Launchpad bug 1503716 in plymouth (Ubuntu) "Display corruption during boot process" [Undecided,New]
<pete-woods> something as simple as this? https://github.com/pete-woods/python-dbusmock/commit/b511c1d98c09e054816544b7aa52be0dec4b615c
<cyphermox> popey: ok
<cyphermox> I think I have a fix for your bug from yesterday, I'm going to try it here now and upload
<cyphermox> this new one will probably take more time, plymouth doesn't change much, and lots of issues are really graphical display driver problems
<davmor2> popey: do you know if it is optimus
<popey> no, pure Intel I believe
<pitti> pete-woods: seems okay to me (just needs a test case)
<pete-woods> pitti: cool (and also to work ;) )
<pitti> pete-woods: and please also a test case for ill-formatted params; I guess it should make clear somewhere that it needs to be a dictionary, etc.
<pete-woods> pitti: yeah, will add tests as thorough as I can manage
<pete-woods> might need some pointers where my python is lacking
<davmor2> pete-woods: well for a start you are not hissing enough
<pete-woods> :D
<pitti> pete-woods: https://pbs.twimg.com/media/B329uElIAAEarI2.png
<pete-woods> pitti: that png was too quickly to hand :p
<pitti> pete-woods: sssssSSS sSSSssSSSS ssssssSS SS sssS
<pitti> pete-woods: err, I meant "I had a bookmark for it" :)
<pete-woods> ha!
<davmor2> pete-woods, pitti: you'll appreciate this http://search.cpan.org/~iamcal/Acme-Python-0.01/Python.pm
<pete-woods> davmor2: I'm amazed how so many people have the time to create these things!
<pitti> yeah, as if brainfuck wasn't enough :)
<kruger> the kernel provided in the dvd (vmliz.efi) is compiled with some
<kruger> the kernel provided in the dvd (vmliz.efi) is compiled with some
<kruger> specific parameters?
<ogra_> kruger, try in #ubuntu-kernel
<kruger> ogra_: thank you
<bdmurray> morphis: Did you mean the bug control team?
<morphis> bdmurray: basically I wanted to assign a bug to some one else
<bdmurray> morphis: Are you an upstream developer or bug triager for an upstream project? If so which one.
<pete-woods> pitti: how about something like this? https://github.com/pete-woods/python-dbusmock/commit/ba9e044f84f095dcb2d6f0ddb451c5ccc196b5e8
<pete-woods> created a PR at any rate: https://github.com/martinpitt/python-dbusmock/pull/15/files
<kruger> i'm unable to recreate a vmlinuz.efi for boot in the uefi mode (in bios mode boot fine) any hints?
<bdmurray> xnox: Do you have any plans to finish bug 1433013?
<ubottu> bug 1433013 in upstart (Ubuntu) "Super -> exec vs Alt-F2 -> exec have different environment" [Medium,Confirmed] https://launchpad.net/bugs/1433013
<kruger> i try to explaim better: i've recompiled the vmlinuz.efi, but i'm unable to boot the dvd in the uefi mode, i'm kicked in busybox shell (initramfs). In bios mode boot fine. Any hints?
<xnox> bdmurray: not immediately
<morphis> bdmurray: depends on how you define that, I am going to maintain bluez and doing development on ofono
<kruger> someone can help me about the issue with vmlinuz.efi?
<doko> Laney, slangasek: is there any policy when/how to remove finished/almost finished transition trackers to done?
<slangasek> doko: none that I know of; for gcc5 I generally moved them out when I knew they were 100% done in -proposed
#ubuntu-devel 2015-10-08
<pitti> Godo morning
<didrocks> doko: slangasek: still nobody assigned himself on bug #1500768, people are seriously unhappy to be left broken
<ubottu> bug 1500768 in python3.4 (Ubuntu Trusty) "python3.4.3 SRU break requests" [High,Triaged] https://launchpad.net/bugs/1500768
<seb128> SRU team, slangasek, what's the standard way to deal with SRUs that got removed from -updates because of regressions but that users already installed? should a bumped version from the old content be uploaded or do we let those users on the buggy version (which currently make them not got a security update)
<didrocks> I think we should revert
<didrocks> so yeah, please advise on the best way to handle this :)
<seb128> arges, hey, I just saw your comment on bug #1376212 and replied, let me know if I should reupload with a different version
<ubottu> bug 1376212 in libmtp (Ubuntu Trusty) "BQ Aquaris E4.5 Android Phone not recognised by libmtp" [High,In progress] https://launchpad.net/bugs/1376212
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hi seb128
<doko> pitti, please could you disable the gcc-* autopkg triggers for linux? I don't think it makes sense to run these for gcc-arm-none-eabi, gcc-snapshot, gcc-4.7, etc
<pitti> doko: ah, so only keep those for gcc-5? sure
<pitti> doko: also, it seems wolfe-07 is segfaulty again, I'll reboot that
<pitti> although, same issue on others
<doko> pitti, yes, until we move to gcc-6
<kruger> hi, i've recompiled the vmlinuz.efi, but i'm unable to boot the dvd in the uefi mode, i'm kicked in busybox shell (initramfs). In bios mode boot fine. Someone can help me?
<pitti> doko: done in http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/518; the next britney run should drop the tests and promote gcc-arm-none-eabi
<flexiondotorg> dholbach, Many thanks for the sponsoring.
<dholbach> keep up the good work! :)
<pete-woods> pitti: any chance you could publish the dbusmock stuff from into wily, as well as the overlay? atm my silo only builds for vivid (although technically we don't test wily atm, we're still doing dual landings) https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-051/+packages
<Laney> that bazaar.l.n link is 500ing for me
<pitti> pete-woods: added to my TODO list
<pete-woods> pitti: thanks!
<Laney> oh wow, I opened it with a ;
<dholbach> flexiondotorg, did you start working on your application for upload rights or membership already? :)
<flexiondotorg> dholbach, On my list for Tuesday next week. I have joined the bug squad already though :-)
 * dholbach hugs flexiondotorg
<dholbach> excellent :)
<pitti> pete-woods: 0.16-1 uploaded to sid, I'll sync it in some 8 hours when it's in LP
<pete-woods> pitti: awesome, thanks!
<pete-woods> will probably nag for a backport to the overlay when I get round to using it
<alexlist> Hi... I need gcc-5.2 on 15.04, and I'm trying to backport the wily package to vivid. However, that one depends on g++-5 and gnat-5, which are not available in vivid... chicken-egg-problem? How do I suggest I create a 5.2 package for 15.04? http://pastebin.ubuntu.com/12713816/
<alexlist> s/I suggest/you suggest/
<rbasak> Looks like you'll have to hack the package to break the loop.
<rbasak> Once done, you should be able to rebuild with your new g++-5 to have something based on the same source package again.
<rbasak> Others probably know more.
<rbasak> Or maybe just hack things around to get the binary g++-5 installed on 15.04 first?
<rbasak> (before rebuilding)
<alexlist> gcc-5-base in 15.04 was probably used as a stepping stone for the transition... but I haven't followed the details...
<infinity> pitti: Is there any way to prioritize rerunning the 3 tmpfail linux autopkgtests?
<pitti> infinity: I don't know off-hand how to jump the queue with amqp, but I'll check this
<pitti> infinity: is there a particular urgency? there's a block-proposed bug so far
<pitti> otherwise we could just hint it; the queues are still catching up from last night's KDE uploads
<pitti> ah, and qt now added another 600 or so
<infinity> pitti: It's a bit of a chicken and egg, since they don't clear their block-proposed until all testing (adt and their own) passes. ;)
<pitti> ah, ok
<attente> hi, i'm trying to cross-compile gtk+3.0 for armhf in a schroot, but i keep getting "E: Build-dependencies for sbuild-build-depends-gtk+3.0-dummy could not be satisfied."
<attente> full build log is here: http://paste.ubuntu.com/12714336/
<caribou> pitti: should sbuild run autopkgtests when I build a package locally ?
<pitti> caribou: not by default; I know some people have created hooks to do that, though
<caribou> pitti: ah, ok. Should PPA build do it ?
<caribou> (sorry, I'm new at autopkgtest & trying to add it to one of my package)
<pitti> caribou: no, there's no PPA integration with autopkgtest right now
<caribou> k
<caribou> so adt-run is the only way to test it
<pitti> I'm planning to add the machinery for this soon, but it's both a bandwidth issue, and more importantly there's nothing to trigger the tests right now
<pitti> (we'll do that for the overlay PPA, for example)
<alexbligh1> "cpan2deb --build InfluxDB" gives "Module::Build::Tiny version 0.039 required--this is only version 0.034 at Build.PL line 6" on vanilla 14.04; am I doing something daft?
<flexiondotorg> cjwatson, Are you the right person to ask to take a look at the merge proposal please?
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-logo/+merge/272432
<cjwatson> flexiondotorg: Somebody else in ~ubuntu-cdimage, please
<flexiondotorg> cjwatson, OK. Thanks.
<flexiondotorg> Laney, And chance you could review/merge https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-logo/+merge/272432 please?
<sysrex> hi, since I have seen some bugs not being updated
<sysrex> I plan to submit the update  to tomcat 7.0.55
<flexiondotorg> infinity, Can you help me out please? https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-logo/+merge/272432
<infinity> flexiondotorg: After I grab some breakfast, yep.
<flexiondotorg> infinity, Thank you :-)
<rbasak> infinity: any opinion on https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/304393 / https://bugzilla.redhat.com/show_bug.cgi?id=103401 ? "According to Ulrich Drepper, daemons requiring specific ports in the 600-1023
<ubottu> Launchpad bug 304393 in cups (Ubuntu) "rpcbind grabs ports used by other daemons such as cupsd" [Undecided,Confirmed]
<ubottu> bugzilla.redhat.com bug 103401 in distribution "RPC (on boot) port selection collisions between various applications" [Urgent,Assigned]
<rbasak> range need to be started before any daemons using bindresvport."
 * rbasak wonders who cares about 0 < ports < 1024 nowadays anyway
<cjwatson> it's an easy way to defend against the class of local-root escalation attacks where you find a way to get a system service to crash and then start up your own version of it to capture credentials
<cjwatson> (and yes, this means that >=1024 services don't have this protection, but most of the things where you might most easily escalate to root are under that ...)
<infinity> rbasak: Lots of opinions, but I doubt any are the opinion you want.
<pitti> mvo: I complain
<pitti> mvo: now that you've trained me for months to use "sudo apt update/upgrade" this doesn't work under precise
<pitti> mvo: (just kidding, of course -- big hug!)
<james_w> juliank: hi, mvo says that you may be a good candidate to mange python-apt on pypi, would you like to do that?
<rbasak> infinity: still, I@m interested
<juliank> james_w: What for? I'm not a huge fan of duplicated distribution mechanisms
<juliank> Especially with the current releases being tightly coupled to APT releases
<james_w> juliank: python now requires the tarball to be uploaded to pypi, rather than just put on Launchpad
<juliank> Not sure what you mean. python-apt is not maintained at all on Launchpad anymore.
<james_w> ah
<james_w> well anyone installing it via pip is even further behind then
<juliank> We release directly from git to Debian and sync to Ubuntu
<juliank> I've always told people that's not a supported use case.
<juliank> It's also registered twice on pypi, AFAICT
<juliank> https://pypi.python.org/pypi/apt
<juliank> and
<juliank> https://pypi.python.org/pypi/python-apt
<james_w> yeah
<attente> Saviq: hey, did you ever find a workaround for https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1318627?
<ubottu> Launchpad bug 1318627 in lightdm (Ubuntu) "lightdm does not cross-build" [Undecided,Won't fix]
<infinity> flexiondotorg: Merged and pulled on cdimage.
<Saviq> attente, afraid not, reading Dimitri's reply it's either not building it whole, or just building it native
<attente> Saviq: ok, thanks. so is my only option basically to build packages directly on an ubuntu touch device?
 * infinity looks at this twisty maze.
<infinity> cjwatson: How often is lillypilly:~cjwatson/bzr/debian-cd/ubuntu updated?
<cjwatson> infinity: 9/15 * * * *    bzr-mirror
<Saviq> attente, or PPA, or qemu, but a nexus4 does fine (nexus7 even finer), I can only recommend to debootstrap a chroot in $HOME, otherwise you'll end up missing more space on / rather soon (and you'll need to reinstall deps on reflash, and OTA will likely break... all kinds of reasons)
<Saviq> attente, qemu will take a long time and if anything tries to thread during the build (like tests or something), that generally fails, too
<attente> Saviq: ok, i'll try the PPA route first, thanks!
<seb128> attente, I usually do test build on porter boxes, which is also an option
<Saviq> attente, note that if your PPA is virtualized (the default), we've seen trouble with that sometimes, too
<Saviq> i.e. IIRC virt PPAs build in qemu, so the same applies
<Saviq> yeah, /me always forgets porter boxes
<attente> ah. ok, thanks guys
<Riddell> pitti: various test regressions many false positives from kde frameworks 5.15, I assume you're onto them?
<cjwatson> Saviq: currently, yes
<pitti> Riddell: I'm handholding/retrying the regressions, yes
<pitti> Riddell: there were tons last night due to uninstallability, most are back to green, but there's still a bunch left
<pitti> Riddell: but queues are still awfully long, will still be some hours until they get their turn for re-running
<Riddell> "I know how to queue, I'm British"
<pitti> :)
<pitti> infinity, doko, Riddell: FYI, all current regressions on people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.htm (mostly fallout from temporary uninstallability or flakyness) are re-queued; please don't re-re-queue, as the queues are already awfully long
<infinity> pitti: I'll keep my hands off.
<flexiondotorg> infinity, Thanks for the review and merge :-)
<flexiondotorg> infinity, Any idea if a new package will be made in time for 15.10?
<flexiondotorg> Those images changes were for 2 reasons.
<flexiondotorg> Firstly, one of the image resolutions was just plain wrong.
<flexiondotorg> The other is the Acceesible Computing Foundation evaluated Ubuntu MATE for accessibility.
<flexiondotorg> We passed, but there were findings.
<flexiondotorg> The most important was that people with low vision would struggle with the boot screen.
<flexiondotorg> Because the contrast of the graphic wasn't high enough.
<infinity> flexiondotorg: A new "package" of what?  Those bits are just for ISOs.
<flexiondotorg> infinity, Cool :-)
<flexiondotorg> So new package build required?
<flexiondotorg> Did. Not. Know. That.
<flexiondotorg> infinity, Many thanks.
<infinity> flexiondotorg: debian-cd isn't packaged, that commit was directly to the cdimage build machine, next daily will pick it up.
<flexiondotorg> I'll get the ACF to test again.
<flexiondotorg> infinity, Perfect. Thank you.
<flexiondotorg> infinity, My cousin is blind and uses Ubuntu MATE. I work hard to ensure Ubuntu MATE is a truly a11y OS :-)
<infinity> flexiondotorg: Probably less effort to just get a new cousin.
<infinity> flexiondotorg: (But, seriously, it's nice to see people making sure things like that work properly)
<flexiondotorg> infinity, You're a bad man. Go and sit in the corner and consider what you've done ;-)
<infinity> flexiondotorg: :)
<infinity> flexiondotorg: If you and your cousin are feeling generously community-oriented, testing a few flavours for stupid "we don't notice because we can see" screwups would be a nice Christmas gift. ;)
<flexiondotorg> Funny you should mention that.
<flexiondotorg> We are considering do precisely that when we get together at Christmas.
<flexiondotorg> In conjunction with the ACF.
<flexiondotorg> Recently even some traditionally poor desktops have started to significantly improve a11y.
<flexiondotorg> Hint, the Unity dash. Not a11y.
<barry> i'm going to start looking at the wily rebuild ftbfs's.  configglue is up first
<barry> anybody else working on any of these?
<ginggs> barry: not right now, but i have fixed a couple
<barry> ginggs: great, thanks!  i don't want to duplicate work.  i'll post here as i take a look at each
<ginggs> are you looking at: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151001-wily.html or http://qa.ubuntuwire.com/ftbfs/ ?
<barry> ginggs: the former
<ginggs> that's a week old now :)
<barry> ginggs: the bottom of the page says it was last updated today at 18:19 +0000
<barry> doko: which ftbfs link should we be working off of? ^^
<ginggs> sorry, i thought that was static
<barry> ginggs: yeah, i think the latter is the list actually failing right now, while the former is what would fail if an actual full archive rebuild were done
<ginggs> so the latter includes (Proposed) packages, e.g. fontmatrix which was RM'd from Debian more than a year ago,what can we do to clean those up?
<sil2100> barry: hey! Could you review/sponsor https://bugs.launchpad.net/ubuntu/+source/python-pysaml2/+bug/1503698 ? Their test suite is really really strange, but at least it builds now ;)
<ubottu> Launchpad bug 1503698 in python-pysaml2 (Ubuntu) "FTBFS due to broken unit tests" [Undecided,In progress]
<barry> sil2100: yes, but let me finish this one first
<sil2100> Thanks! :)
 * sil2100 goes EOD now
<cjwatson> ginggs: must've been some reason fontmatrix wasn't removed, let me see
<cjwatson> ginggs: ok, fontmatrix was only removed from testing, not unstable - we don't auto-follow that
<ginggs> cjwatson: ok, thanks
<ochosi> cjwatson: hey, could you take a peek/review this MR? would be great if we could still get this into wily! https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
<cjwatson> ochosi: could you ask somebody else in ~ubuntu-cdimage?  I'm only there as a backup now
<ochosi> oh i see
<ochosi> right, we've just been trying to get someone to rev this for a while, so i guess i started at the top of the list
<ochosi> slangasek: hey! would you mind reviewing this MR? https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
<slangasek> ochosi: hi, queuing it to look at
<ochosi> slangasek: thanks a bunch! would be great if we could get this in
<doko> ginggs, barry: they are different, and complement each other, so every fix is welcome
<barry> doko: ack
<slangasek> Unit193: hi, I think I'm going to need you to explain to me what xubuntu core is
<tdaitx> slangasek, libecap 1.0.1 was deleted, I now need sponsoring for LP: #1504200, after that LP: #1496223 and LP: #1502178 need to be sponsored as well
<ubottu> Launchpad bug 1504200 in squid3 (Ubuntu) "libecap2 FTBFS due to gcc5 transition" [Undecided,New] https://launchpad.net/bugs/1504200
<ubottu> Launchpad bug 1496223 in linux (Ubuntu) "squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch" [High,Triaged] https://launchpad.net/bugs/1496223
<ubottu> Launchpad bug 1502178 in squid3 (Ubuntu) "update squid from 3.3.8 to 3.3.14" [Undecided,New] https://launchpad.net/bugs/1502178
<Unit193> slangasek: Like Xubuntu desktop, but less additions.  ochosi or knome can answer a few questions, barely got this going out.
<slangasek> ochosi: ok, for you to explain then :)
<slangasek> why does xubuntu need two different image builds?
<ochosi> slangasek: we didnt really enjoy "outgrowing" the size of legacy media, i.e. the CD and wanted to make it easier for folks to get a slimmer version of xubuntu that's still functional. so it'll help people with low bandwidth as well as those who still have older machines and have to install from CD
<ochosi> and yeah, ofc there are other ways, but we felt this was offering people an easy and really user-friendly way to get xubuntu
<slangasek> ochosi: ok; and why did you not take what you've done to make xubuntu-core smaller, and make that the "xubuntu" image instead, with everything else downloaded from the archive?
<slangasek> ochosi, Unit193: btw we historically had both CD and DVD media for flavors, *without* using a different project name.  I think it would be better to do the same here, rather than creating two discrete projects in cdimage
<ochosi> well there are other issues too ofc, people without any connectivity can't download anything, so giving them a richer version that includes e.g. LibreOffice made sense to us
<ochosi> what's the problem/downside of having two discrete projects in cdimage?
<slangasek> ochosi: that they show up as two distinct projects at the top level, when AFAICS they aren't
<ochosi> yeah true, they aren't. is there any other way to offer the two isos separately?
<slangasek> ochosi: you would see http://cdimage.ubuntu.com/xubuntu/daily-live/ vs. http://cdimage.ubuntu.com/xubuntu/dvd/ for daily images, and xubuntu-15.10-desktop-$arch.iso vs. xubuntu-15.10-dvd-$arch.iso for release images
<ochosi> Unit193: thoughts?
<slangasek> tdaitx: one minor tweak, libecap2v5 should Replaces: libecap2 in addition to the Conflicts:
<gQuigs> anything I can do to help with archive package removal? (https://bugs.launchpad.net/~ubuntu-archive/+bugs?field.searchtext=remove)
<ochosi> slangasek: anyhow, i gotta let Unit193 take it from here again, gotta get some rest. thanks for taking a look and don't hesitate to add your comments to the MR directly!
<gQuigs> for example, one not reported by me.. .https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/1405906
<ubottu> Launchpad bug 1405906 in nspluginwrapper (Ubuntu) "please remove nspluginwrapper from Ubuntu" [Undecided,Confirmed]
<tdaitx> slangasek, ouch! right, forgot about that
<tdaitx> slangasek, let me fix it...
<knome> slangasek, i'm told that other people need to go to bed and other stuff, so i'm jumping in on the xubuntu core discussion
<slangasek> tdaitx: fixed locally and uploaded
<knome> slangasek, i can't see a reason why it couldn't be two different ISOs built with the same product name
<knome> slangasek, at least as long as we can have a word what the names for the subproducts are
<slangasek> knome: the convention would be "desktop" vs "dvd"
<knome> slangasek, is there a reason why that couldn't be something else?
<knome> slangasek, because neither of those *really* describe what we're after with core
<slangasek> knome: these names are part of the cdimage code, and changing them to something else would require making the code more complicated
<knome> right
<slangasek> which is not to say I'd veto it
<slangasek> but I'd want to see it first
<knome> sure
<knome> the more i think of it, the more it makes sense to put them under the same product name
<knome> but i'd really like to see something like "desktop" and "core"
<knome> how and with what names and descriptions we point people to those ISOs is a documentation/marketing issue anyway
<knome> slangasek, how would you suggest we go forward from here?
<knome> slangasek, do we need changes on the merges, and who/what team should we contact about getting the naming scheme and related script discussion started?
<slangasek> knome: I'd like to see a proposed patch that does this as two images under the xubuntu product, with whatever code changes you're looking for to support different names that "desktop" and "dvd" if that's the way you're going
<knome> slangasek, i don't understand much of the code side here, but would the code changes required be in the same pacakges as the merges are currently done?
<slangasek> knome: to ubuntu-cdimage, yes
<knome> slangasek, cheers, i'll pass the message on
<knome> slangasek, thanks for the insight and comments!
<sarnold> gQuigs: I think subscribing https://launchpad.net/~ubuntu-archive is the recommended step
<gQuigs> sarnold: yup, that bug list is those subscribed to ubuntu-archive
<gQuigs> I guess what can I do to help that team with them?
<sarnold> gQuigs: oh. /me facepalm
<gQuigs> sarnold: if I think they're ready to be removed (no more questions needs to be asked), is triaged a good place to put them ?  not sure if there is a different policy for these
<sarnold> gQuigs: good question, that list is a lot longer than I expected :)
<gQuigs> sarnold: https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/1405906 is a good example, it even ftbfs...
<ubottu> Launchpad bug 1405906 in nspluginwrapper (Ubuntu) "please remove nspluginwrapper from Ubuntu" [Undecided,Confirmed]
<sarnold> gQuigs: I've always poked infinity directly in the past when I've wanted a package removed from the future, but that may not scale to the size of that list :) hehe
<gQuigs> yup, the last package I got removed was him...
<gQuigs> IIRC
<cjwatson> worst case, we normally do a full pass over archive bugs just before release
<sarnold> also works
<gQuigs> interesting, seems like an odd time - why not just after a release?
<gQuigs> (for the next one, obviously)
<gQuigs> I'll bbl, but if any of you think of anything I can add to those bugs to make them easier, let me know
<cjwatson> gQuigs: just before because that way the removed packages aren't in the release
<slangasek> tdaitx: could I get dep3 headers for each of the patches under debian/patches for squid3?
<slangasek> tdaitx: (fix-logical-not-parentheses-warning)
<tdaitx> oh, don't tell me I forgot those?
<tdaitx> yeah, I did
<tdaitx> slangasek, fixing that now
<tdaitx> slangasek, done... I had the dep3 locally, I probably forgot to regenerate the debdiff at the time
<tdaitx> and thanks for the heads up
<tdaitx> =)
#ubuntu-devel 2015-10-09
<slangasek> tdaitx: squid3 uploaded and in the queue
<tdaitx> slangasek, thanks!
<pitti> Good morning
<pitti> coreycb: the neutron i386 regression is quite stable (http://autopkgtest.ubuntu.com/packages/n/neutron/wily/i386/), and it doesn't look like just a race condition; can you please have a look?
<pitti> coreycb: until then the package is stuck in -proposed (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#neutron)
<pitti> Riddell: bumping the force-badtest for cantor, but there's a bunch of new regressions
<pitti> Riddell: kservice in particular
<pitti> Riddell: so I went through everything else and adjusted hints etc.;  kservice is the remaining regression that's relevant
<dholbach> good morning
<seb128> hey dholbach ;-)
<seb128> happy friday!
<dholbach> hey seb128
<dholbach> and the same to you :)
<mardy> seb128: hi! Do you have a minute to talk about bug 1453549?
<ubottu> bug 1453549 in shotwell (Ubuntu) "Cannot publish to Facebook" [High,Confirmed] https://launchpad.net/bugs/1453549
<seb128> mardy, hey, sure
<mardy> seb128: so, I got no reply from Yorba :-(
<seb128> :-(
<seb128> that was sort of expected
<mardy> seb128: yesterday i created a new facebook key, and got it reviewd and approved by facebook
<seb128> they didn't reply on the shotwell list since june
<seb128> oh, nice
<mardy> seb128: the latest commit here switches to the new key: https://code.launchpad.net/~mardy/shotwell/lp1453549
<Laney> someone posted on desktop-devel-list yesterday(?) about API keys
<mardy> Laney: oh, I'll have a look then
<Laney> it doesn't immediately solve this problem but maybe the idea of having them owned by some group is good and can help to avoid it in future
<seb128> Laney, was that about shotwell?
<seb128> because IRC discussions were about goa I think
<mardy> seb128, Laney: my idea was to distro-patch it with the new key, and comment on the upstream bug about the new key I created and asking who wants to maintain it
<seb128> at least the ones between Bastien and Xavier
<seb128> mardy, +1 from me
<Laney> it is a general idea
<Laney> even if they have one specific case which motivates it
<mardy> seb128: I wonder if you would be willing to take care of releasing a new shotwell with the uoa patch from https://code.launchpad.net/~mardy/shotwell/lp1453549 ?
<seb128> mardy, yes, I can do that
<mardy> seb128: thanks a lot, I'll comment on the upstream bug then
<seb128> mardy, thanks
<seb128> mardy, your branch doesn't merge fine on the vcs, there is a conflict in 06_uoa.patch
<mardy> seb128: where can I find the latest shotwell branch for ubuntu?
<seb128> mardy, hum, your patch change is only changing the ClientId?
<mardy> seb128: yes
<seb128> mardy, lp:~ubuntu-desktop/shotwell/ubuntu
<seb128> apt-get source tell you that ;-)
<seb128> (or debcheckout)
<seb128> mardy, it's ok, I can change the Id manually
<mardy> seb128: ah, that will be way faster :-) thanks
<seb128> mardy, yw
<pete-woods> pitti: backport of 0.16 to vivid overlay kthx? promise won't ask for more landings for at least an hour
<pitti> pete-woods: lol
<pitti> pete-woods: the overlay has the NM fix -- you need the CLI params one too?
<sysrex> hello all, I am looking to backport ubuntu 7.0.55 to 14.04 what would be the best approach?
<tsdgeos> cjwatson: you working on launchpad right? how hard would be to make the " 1 branch dependent on this one. " link in https://code.launchpad.net/~aacid/unity8/new_dash_navigation work?
<cjwatson> tsdgeos: That's an interesting failure mode ... probably not very hard, could you please file a bug about that?
<infinity> seb128: Why is that unity-settings-daemon changelog such a cluster#%@$?
<tsdgeos> cjwatson: would be https://bugs.launchpad.net/launchpad/+bug/496056 i guess
<ubottu> Launchpad bug 496056 in Launchpad itself "Dependent branch list is empty" [Low,Triaged]
<tsdgeos> just that that one doesn't work anymre
<cjwatson> tsdgeos: Ah, yes, it is that bug.  Indeed I was just thinking "I wonder if this ever worked?".
<tsdgeos> cjwatson: i'd say no :D
<tsdgeos> i have a look a few years ago
<tsdgeos> ~1.5
<tsdgeos> but my unexistant knowledge of the language launchpad is written and of launchpad itself made it basically impossible for a 1 hour bugfix :D
<cjwatson> tsdgeos: Lots of things in Launchpad would be accessible to a casual contributor, but this probably isn't one of them; merge proposals have quite complex code around them to make the database queries halfway efficient.
<pitti> pete-woods1: done
<pete-woods1> pitti: :D
<cjwatson> tsdgeos: Ah, indeed, I see you filed https://bugs.launchpad.net/launchpad/+bug/1277469 then, and that was marked as a duplicate.
<ubottu> Launchpad bug 496056 in Launchpad itself "duplicate for #1277469 Dependent branch list is empty" [Low,Triaged]
<tsdgeos> cjwatson: right, that one :)
<rbasak> slangasek, tdaitx, infinity: ah, I was just about to do the squid3 merge, but I see the latest upload yesterday. Shall I leave it?
<rbasak> Since we'll want it next cycle and you won't be in for a while I might as well start it I guess, but let me know if you want it uploaded now or not.
<GunnarHj> happyaron: Any chance that you can upload the patch at bug #1481025 soon? language-selector-gnome, which I uploaded yesterday, depends on it.
<ubottu> bug 1481025 in im-config (Ubuntu) "Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback" [Medium,In progress] https://launchpad.net/bugs/1481025
<happyaron> GunnarHj: just did it
<GunnarHj> happyaron: Great, thanks!
<happyaron> :)
<cjwatson> tsdgeos: OK, I think I have most of a fix but I should really finish off the other urgent things I was working on before diving into writing tests ...
<tsdgeos> cjwatson: cool and sorry for derailing you :)
<pete-woods> any chance a packaging expert could help me out with this one? https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1472186 (http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk.15.10/view/head:/debian/control)
<ubottu> Launchpad bug 1472186 in indicator-network (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [High,Confirmed]
<seb128> infinity, because I backported individual commits to the vcs with --author and the CI train seems to want to credit individual commiters rather than using the mp description/commit message
<seb128> unsure how to workaround it
<seb128> infinity, I can manually fix the changelog/merge the vcs if you want
<GunnarHj> happyaron: I see in the diff that you picked the old patch instead of the one I prepared, so currently there is a mismatch compared to the l-s code.
<GunnarHj> happyaron: What's the reason for that choice? How do we deal with it now?
<morphis> seb128: ping
<coreycb> pitti, on it, thanks
<seb128> morphis, hey
<morphis> seb128: you ever looked at obexd on desktop since we updated to bluez5?
<seb128> morphis, no, is it not working?
<morphis> seb128: it looks suspicious
<morphis> the bluez-obexd package provides a systemd user service file
<morphis> but we still depend on upstart for the session jobs
<seb128> no dbus activation?
<pitti> sitter: do you have an idea about the kservice regression? http://autopkgtest.ubuntu.com/packages/k/kservice/wily/amd64/ (but on all arches) -- this is what keeps most KDE uploads in -proposed
<pitti> FAIL!  : KSycocaTest::dirTimestampShouldBeCheckedRecursively() 'newTimestamp > oldTimestamp' returned FALSE. ()
<morphis> seb128: that is what I thought too: http://paste.ubuntu.com/12723307/
<pitti> but this isn't just a flaky timing issue, it consisently failed on all arches for 7 times
<sitter> pitti: that's a new test. will have to take a closer look
<pitti> sitter: ah, it's new, not a regression?
<pitti> sitter: want me to force-badtest this then for this version, or want to keep everything in -proposed for now?
<sitter> pitti: best force for now please
<seb128> morphis, the obexd binary is active on my user session on wily
<sitter> Riddell: did you upload kservice rc1 or rc2? it appears to me rc2 should fix http://autopkgtest.ubuntu.com/packages/k/kservice/wily/amd64/
<pitti> sitter: hinted
<sitter> cheers
<seb128> morphis, it's on the session bus, so -y -> -e
<morphis> ah right
<morphis> works now, sorry for the noise :)
<seb128> no worry ;-)
<Saviq> morphis, hey, we noticed with mzanetti there's issues with pairing a BT keyboard on krillin (works fine on mako/flo) - you never get a PIN dialog and the settings app just says "connected", when it's really not
<Saviq> morphis, is that a known issue? otherwise what can we provide to help fix that?
<morphis> Saviq: that is know
 * Saviq tries on stable in the mean time
<Saviq> oh ok
<morphis> I have fixes for that
<morphis> but we will land those together with the BlueZ 5 work
<Saviq> morphis, and it's a krillin specific bug?
<morphis> Saviq: needs changes on the kernel to get that working
<morphis> Saviq: yes
<Saviq> ack
<Saviq> thanks
<morphis> Saviq: if you want I can give you a device tarball with those changes
<seb128> morphis, is that going to be fixed before bluez5?
<Saviq> morphis, if you need me to test, sure, not pressing for me
<morphis> seb128: not with ota7
<seb128> k :-/
<morphis> and we're trying to get all bluez5 stuff into ota8
<seb128> right
<Riddell> sitter: I uploaded kservice rc2, the one that's currently on the kde server, and it does have the patch which should fix the test
<seb128> I wonder if the fix would also fix prompting with my car not working
<seb128> looking forward bluez5 to land ;-)
<morphis> seb128: no
<morphis> that is something different
<seb128> k
<seb128> maybe bluez5 fixes it though
<morphis> seb128: btw. I've updated the silos with some fixes for the authentication/pin problem
<sitter> Riddell: so why is it failing then? :P
<seb128> morphis, I saw, thanks, I've it on my list to try with those updates
<Riddell> sitter: good question, I'm trying to recreate it
<pitti> sitter, Riddell: kde landing, brace for impact :)
 * sitter hides under desk
<sitter> Riddell: passes here
<cousteau> Request for openjdk-8 to be added to the LTS repos, since Java 7 is EOL'd?
<cousteau> (or where should I direct my request/suggestion?)
<Riddell> sitter: test fails here building the package from the archive, and git doesn't build it seems to have a change in it which isn't in the tar
<Riddell> sitter: what do you do that passes?
<sitter> I build first and then adt-run on the built tree
<sitter> also I run it in a docker container
<Riddell> sitter: build what? the package from the archive?
<sitter> yup
<Riddell> spooky
 * Riddell installs the built packages then runs the tests again
<sitter>     QTest::qWait(1000); // remove this once lastModified includes ms
<sitter> timing problem?
<sitter> although that wouldn't really explain why it fails consistently
<sitter> Riddell: uff, wrong version >.<
<Riddell> sitter: ?
<sitter>  /tmp/kservice-5.14.3
<sitter> pull-lp-source gave me the wrong version for some reason xD
<Riddell> tsk
<sitter> Riddell: it's failing because of qt 5.4
<sitter> and I can reproduce now
<sitter> upstream build against qt 5.4 also fails the test https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/89/console
<sitter> qt 5.5 for comparision https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/94/console
<Riddell> well spotted
<Riddell> sitter: I guess the only thing to do is e-mail the frameworks list and the Xuetian Weng dude who's been working on it
<sitter> yeah
<Riddell> sitter: I'll send an e-mail
 * sitter looks into why that testsuite rebuilds the buildtree
<sitter> Riddell: ^ fixed that in unstable
<Riddell> I always assumed there was a good reason for that, I just never worked out what it would be
<Riddell> sitter: ooh?
<sitter> Riddell: http://anonscm.debian.org/cgit/pkg-kde/frameworks/kservice.git/commit/?h=kubuntu_unstable&id=d96d6f3641b9166f352003fb5d968e2d622264dd
<sitter> testsuite rebuilt the tree for no good reason
<Riddell> genius
<Riddell> sitter: all the frameworks seem to have this
<sitter> Riddell: just some
<sitter> one of them probably needed it and from there on out it was bad copynpaste :P
<Riddell> sitter: but I feel like it would be good to have tested in the ubuntu archive before changing it all, there might be a perfectly rational explanation
<sitter> the openbox testsuite needs to be put into pkg-kde-tools really
<sitter> Riddell: could just do it for 5.16
<sitter> after wily
<Riddell> yep
<smoser> anyone have a suggestion on how to check in python "is systemd service X running" ?
<jrwren> smoser: shell out. :)
<cjwatson> smoser: python3-systemd is a thing apparently
<cjwatson> hm though its online docs don't document such an operation
<sil2100> seb128: hey, I saw you posting a bug on debian about this: https://bugs.launchpad.net/debian/+source/telepathy-glib/+bug/1504506 <- are you working on this bug currently? :)
<ubottu> Launchpad bug 1504506 in telepathy-glib (Ubuntu) "FTBFS due to failing unit tests" [Undecided,In progress]
<jrwren> honestly, subprocess.call('systemctl','status'... may be best.
<seb128> sil2100, Laney is, he sent a patch upstream and said he would handle Debian/Ubuntu uploads
<sil2100> seb128: excellent, thanks o/
<gQuigs> smoser:  I wonder if you can just read the journal of a specific service maybe ? (https://github.com/systemd/python-systemd)
<seb128> sil2100, yw, assigned to Laney so other don't duplicate work
<cjwatson> Shelling out to systemctl is probably easiest TBH
<sil2100> btw. I see that python-pex autopkgtests are failing, blocking wheel in -proposed right now
<sil2100> Is anyone looking into those right now?
<didrocks> cjwatson: gQuigs: you should prefer using "show" rathen than "status". status is supposed to be human-readable and not for parsing
<didrocks> rather*
<cjwatson> didrocks: I didn't specify any particular thing
<cjwatson> didrocks: and it was smoser who was actually trying to do it
<didrocks> right, backlogged fully now, so smoser ^
<sil2100> barry: hey! I see that the new wheel sync seems to cause some autopkgtests fail for python-pex and therefore got blocked in -proposed
<sil2100> barry: for instance: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/armhf/p/python-pex/20151008_212123@/log.gz
<smoser> yeah. i think i'll shell out.
<sil2100> barry: this is a bit worrying: Resolving interpreter :: Setting up interpreter /usr/bin/python3.5 :: Interpreter cache resolving wheel<0.25.0,>=0.24.0 Could not find compatible interpreter <- could this be related to the failure?
<smoser> i think i just need 'reload-or-restart'. and through shell.
<smoser> thanks ffor feedback
<sil2100> barry: the version you pulled in is 0.26.0-1, maybe we'd need some fixes/changes to python-pex too? Should I look into that or is it worked on already?
<sil2100> barry: I actually see a new python-pex in -proposed
<barry> sil2100: i just uploaded pex 1.0.3-2ubuntu1 but i guess it doesn't solve the problem.  i wonder if its a problem with the armhf and ppc platforms
<slangasek> rbasak: up to you whether you think the squid3 merge should still be done this cycle; the blocking bugs have been resolved now, we weren't sure of an eta for the (big hairy) merge
<rbasak> slangasek: thanks. Now that I've looked at it, it's even more hairy, so I'm going to decline to push it in this late now. I'll have it ready for early next cycle.
<rbasak> infinity: ^
<sil2100> barry: I see that all autopkgtest archs for the new python-pex are failing
<sil2100> barry: btw. any package I could help out and pick up to fix the FTBFS? ;) I prefer to ask since I see many of the failures are already worked on,
<barry> sil2100: dang.  and i specifically ran adt-run on that package before i uploaded it :(
<gQuigs> would we recommend people to use systemctl not service in new releases?
<barry> sil2100: i started with configglue, but just haven't gotten very far and too many other things got pushed on my stack. :(  it's an upstream incompatibility.  see LP: #1504288 if you'd like to take a look
<ubottu> Launchpad bug 1504288 in python-configglue (Ubuntu) "Test suite failure with Python 3.4 & 3.5" [Undecided,New] https://launchpad.net/bugs/1504288
<sil2100> barry: on it then!
<barry> sil2100: thanks!  i'm getting some lunch now :)
<sil2100> Have fun ;)
<ben___> newb launchpad/bzr question -- but how do I see the source for changes after a package is released? e.g., using libvirt as an example, `bzr branch lp:ubuntu/trusty/libvirt` shows me the code for the release package (libvirt 1.2.2-0ubuntu13), how do I checkout the code for the updates package (libvirt 1.2.2-0ubuntu13.1.14)?
<ricotz> doko, hi, maybe you could take a look at merging aptitude 0.7.3-1
<cjwatson> ben___: The system for doing automatic imports into bzr is not very robust and is unmaintained, so it often breaks.  We plan to replace it with a similar system for importing into git at some point, but haven't started on that yet.  In the meantime it's more reliable to just fetch the source package; use "pull-lp-source" from the ubuntu-dev-tools package, or for just a quick diff to the last version you can start from ...
<cjwatson> ... https://launchpad.net/ubuntu/+source/libvirt
<ben___> cjwatson: thanks, that makes more sense.
<hjd> cjwatson: Is pull-lp-source working again? (Last time I tried, I ran into bug 1453330)
<ubottu> bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [High,Triaged] https://launchpad.net/bugs/1453330
<hjd> Or wait... that might be the debian-part of it only...
<cjwatson> I believe that's only pull-debian-source, and in any case you can work around it by specifying a version
<cjwatson> IIRC
<hjd> tested now, and pull-lp-source seems to work fine at least. So ignore my comment above :)
<ben___> yep, working here as well
<barry> pitti: don't suppose you might still be around?
<knome> slangasek, hullo! we have now updated the merge proposal for xubuntu core at https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
<knome> slangasek, should have changes you asked for, and if you want to discuss the way things have been done there, i brought krytarik, the author of the newest changes here :)
#ubuntu-devel 2015-10-10
<rbasak> pitti: does http://autopkgtest.ubuntu.com/packages/n/nut/wily/amd64/ need a retry? I don't see why it wouldn't be able to find python-unit as it's in the release pocket and hasn't changed recently. I haven't tried locally.
<jtaylor> hm how do I get systemd to log info level stuff?
<jtaylor> I'm trying to figure out why it won't disable my dm devices properly screwing up my caches
<jtaylor> but no logs even though the code has some as info level
<jtaylor> I put info into the config file
<CromFr> Hello! Does anyone knows what HUD uses to fetch the window menu list independently from the used widget toolkit?
<CromFr> GTK3+ & Qt applications expose thir menu list through dbus but most applications dont
<T0rch> Can anyone here tell me when 16.04 branch will be created?
<T0rch> Hopefully a few days after 15.10 will be released ?
<knome> a week or so after
<T0rch> thanks !
<jamespage> anyone aware of any issues with package upload signing?
<jamespage> "The signer of this package is lacking the upload rights for the source package, component or package set in question." ?
<jamespage> well not the  signing - I checked that
<jamespage> nope I managed to expire my ubuntu-core-dev membership
<jamespage> that was a bit of an oversight
<jamespage> stgraber, infinity: erm - I managed to overlook my expiring ubuntu-core-dev membership - how do I go about getting that re-instated?
<jamespage> (the new launchpad headers on mails are great - autofolder management is less so)
<stgraber> jamespage: I'll fix that for you
<jamespage> stgraber, thankyou!
<stgraber> done
<jamespage> ta
 * jamespage adds another exclusion to his mail filters
#ubuntu-devel 2015-10-11
<hades08> hi
<hades08> how to put apparmor in complain mode under ubuntu-core / snappy ? apparmor_parser -C ?
<hades08> im trying to enable /dev/ppp in a lxd container but it doesnt work , anyone could help plz ?
<hades08> ubuntu-core-launcher not working neither
<hades08> could someone give me a hint about how to put apparmor in complain mode with ubuntu-core ? :P
#ubuntu-devel 2016-10-10
<Anja> does anyone have any idea how Qt finds its default theme on ubuntu?
<pitti> Good morning
<pitti> mwhudson: do you have an idea about the uninstallability in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20161010_031813@/log.gz ?
<Mirv> doko: oSoMoN: cjwatson: re bug #1630906 the upstream fix seems to start segfaults on armhf and i386, even if it fixes arm64. those autopkgtest runs have it consistent. could only CONFIG_ARM64_VA_BITS=48 be reverted in kernel 4.4?
<ubottu> bug 1630906 in linux (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,Confirmed] https://launchpad.net/bugs/1630906
<pishuilu> Hi,all. Who can help to upload ubiquity-slideshow pacakge to ubuntu. The url is https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html. Thanks!
<pitti> wgrant, cjwatson: the arm64 buildds seem to have some troubles?
<wgrant> pitti: A bit. Investigation is underway.
<pitti> ack, thanks
<wgrant> pitti: But the queue is pretty clear, so I don't think it should be blocking anything?
<wgrant> Unless I've missed something.
<pitti> wgrant: no, it's not, I just noticed
<pitti> wgrant: if there are some nagios/alarm bells on those, I'll stop shouting in the future
<wgrant> pitti: We've turned off automated gardening so we can assess the remaining failure modes manually.
<pitti> wgrant: yours are also running under 4.8 or the fixed 4.4.23 now?
<wgrant> Since they're no longer falling over at an incredible rate with an impossible to diagnose failure.
<wgrant> pitti: Same as yours.
<pitti> wgrant: they both work wonderfully for my instances
<wgrant> Right, these don't appear to be kernel issues.
<wgrant> More general OpenStack ones.
<mwhudson> pitti: no
<mwhudson> pitti: i was trying to repro locally and failing
<mwhudson> but i think my mirror was out of date
<mwhudson> GRARARARRA "tar: Unexpected EOF in archive"
<LocutusOfBorg> good morning folks, question:
<LocutusOfBorg> src:daemontools has an ubuntu delta
<LocutusOfBorg>   * Merge with debian, remaining diff:
<LocutusOfBorg>     - add upstartification
<LocutusOfBorg>   * Fix upstart job as not in event.d anymore (LP: #688054)
<ubottu> Launchpad bug 688054 in daemontools (Ubuntu) "svscan is not started when the package is installed" [Undecided,Fix released] https://launchpad.net/bugs/688054
<LocutusOfBorg> can we drop it on next debian upload?
<pitti> LocutusOfBorg: yes, I suppose so
<mwhudson> pitti: where did you suspect the tar: Unexpected EOF in archive problem was coming from again?
<pitti> mwhudson: I suspect some bug/race condition in qemu's 9p
<mwhudson> pitti: is there somewhere i can put a sleep or something to try to confirm/ameliorate?
<pitti> mwhudson: no, I already tried to put sleeps, syncs etc. everywhere, didn't help
<pitti> well, "everywhere" â I might have missed something of course
<mwhudson> pitti: i'm getting the problem like 80% of the time
<mwhudson> pitti: i'm wondering if it would be less painful to set up devstack and use --- nova or something :(
<pitti> mwhudson: you could actually use ssh too
<pitti> mwhudson: i. e. start the autopkgtest-yakkety-something.img in qemu (with -snapshot), install your ssh key, and then use the ssh runner
<LocutusOfBorg> thanks pitti
<mwhudson> pitti: so this command passed for me: autopkgtest -d --shell --test=docker-in-lxd -B --apt-pocket=proposed=src:docker.io --apt-upgrade docker.io --- qemu ~/adt-yakkety-amd64-cloud.img
<mwhudson> (eventually)
<mwhudson> pitti: can you see how that would differ from prod infrastructure?
<pitti> mwhudson: not really, uninstallability doesn't sound like a proxy issue; I'll retry the tests, and if it still fails run it manually on the infra
<mwhudson> pitti: thanks
<pitti> although the last test only ran ~ 10 hours ago
<pitti> no, ~ 5 hours
<mwhudson> yeah
 * pitti runs it manually right away
<pitti> mwhudson: --test is --testname I presume
<mwhudson> pitti: uh, that was the command i ran
<mwhudson> i suppose it gets expanded to --testname, yeah
<mwhudson> pitti: but running all the tests makes sense i guess
<mwhudson> (the other one has been passing)
<pitti> mwhudson: also, this install failure is in the lxc container, not outside
<mwhudson> pitti: yes
<mwhudson> i copy /etc/apt from outside to container
<mwhudson> which is a hack, i guess,  but it works on my machine (tm) :)
<pitti> mwhudson: I have the failure in a running instance now
<mwhudson> pitti: can you coerce it into explaining why the uninstallable things are uninstallable?
<pitti> mwhudson: oh, it deletes the container after the failed test, it seems
<mwhudson> oh ups, yes it would i guess
<mwhudson> still you should be able to re-make it
<mwhudson> pitti: comment out defer 'lxc delete --force docker' and run debian/tests/docker-in-lxd by hand?
<pitti> running
<pitti> mwhudson: OOI, why does this need root?
<mwhudson> pitti: configuring lxd requires root i think
<pitti> E: Package 'containerd' has no installation candidate
<pitti> E: Package 'runc' has no installation candidate
<pitti> E: Package 'cgroupfs-mount' has no installation candidate
<pitti> E: Package 'cgroup-lite' has no installation candidate
<pitti> E: Package 'ubuntu-fan' has no installation candidate
<mwhudson> pitti: that doesn't make any sense on the face of it
<pitti> Get:9 http://ftpmaster.internal/ubuntu yakkety/universe amd64 Packages [7736 kB]
<pitti> it does download the universe Packages, hmm
<pitti> and I see it in /var/lib/apt/lists/ftpmaster.internal_ubuntu_dists_yakkety_universe_binary-amd64_Packages
<mwhudson> maybe the preferences/pinning are screwed up?
<pitti> and running apt update again then works
<mwhudson> pitti: you ran apt update and then the install worked?
<pitti> yes (in the container)
<pitti> but it already ran update before
<mwhudson> errrr
<pitti> err, WTH
<mwhudson> pitti: maybe deleting /var/lib/apt/lists/* before the first update?
<pitti> mwhudson: I duplicated the apt update call now, and look what I see: http://paste.ubuntu.com/23302146/
<mwhudson> pitti: just total guessing though
<pitti> mwhudson: so the second time switches away from ftpmaster.interla
<mwhudson> whuh
<pitti> infra runs with --mirror=http://ftpmaster.internal/ubuntu
<pitti> so it's like sources.list gets changed after the first apt update run
<pitti> mwhudson: could that be cloud-init running in the background?
<pitti> mwhudson: changing mirror in sources.list underneath would totally explain it
<mwhudson> pitti: ... i ... suppose ... so?
<mwhudson> pitti: cloud init logs have anything?
<mwhudson> in the container i mean
<pitti> mwhudson: do you really need ubuntu-daily:yakkety, or would images:ubuntu/yakkety/amd64/ suffice?
<pitti> mwhudson: just running it again to check c-i logs
<mwhudson> pitti: i imagine the images: would be fine yeah
<pitti> # cat /etc/apt/sources.list
<pitti> ## Note, this file is written by cloud-init on first boot of an instance
<pitti> and it has archive.u.c.
<mwhudson> pitti: hnnngh
<pitti> but I think you copy in the host's /etc/apt/sources.list, which has ftpmaster.internal
<mwhudson> pitti: yeah i did
<mwhudson> pitti: i guess i could sleep for 60s before doing that but ...
<pitti> Oct 10 08:32:05 docker [CLOUDINIT] handlers.py[DEBUG]: finish: modules-final: SUCCESS: running modules for final
<pitti> mwhudson: nah -- if you wait, then poll for /var/lib/cloud/instance/boot-finished
<mwhudson> or use the images: image which doesn't have cloud-init?
<pitti> mwhudson: right; let me check that here
<mwhudson> pitti: however, does this explain the actual failure?
<pitti> mwhudson: yes, totally
<mwhudson> ok :)
<pitti> mwhudson: apt update ran against ftpmaster.internal, then cloud-init finishes in the middle and changes sources.list to archive.u.c.
<pitti> for which apt has no data
<mwhudson> oh right
<mwhudson> i'm sure glad i didn't spend any more time figuring this out because i would never ever have figured it out on my own :)
<pitti> mwhudson: images: is only half as big, and has a lot less crap pre-installed, so you actually have a stronger test that docker.io's dependencies are correct
<pitti> #lxc launch ubuntu-daily:${suite} docker -p default -p docker
<pitti> lxc launch images:ubuntu/${suite}/amd64 docker -p default -p docker
<pitti> works fine
<pitti> mwhudson: I suppose you want to use `dpkg --print-architecture`
<mwhudson> ah yes
<pitti> mwhudson: so in between poling for boot-finished and using images: I'd actually tend towards the latter, but your choice
<mwhudson> me too
<pitti> mwhudson: can you upload this, and I'll review/handhold through the queues?
<pitti> what a fun bug :)
<mwhudson> sure
<pitti> mwhudson: thanks!
<mwhudson> -0ubuntu15, man
<pitti> mwhudson: getting closer to hitting the biggest natural number?
<mwhudson> pitti: but somehow staying the same distance away
<brendand> pitti, hey - are you aware of the issue with overlayfs that impacted autopkgtest (at least when using a qemu runner), recently?
<pitti> brendand: no, I'm not (works fine locally), what was that about?
<brendand> pitti, i'm right in thinking that the qemu test runner uses an overlayfs?
<pitti> brendand: no, it uses qemu-img overlay
<pitti> overlayfs is too brittle
<brendand> hmm
<pitti> doko: any objections to removing gnat-4.9? it got removed in Debian, only rdepends is spark which I'm rebuilding against libgnat-6
<pitti> doko: (I'm currently running process-removals)
<brendand> that was a wrong assumption then
<pitti> doko: Debian also removed gcc-4.9, but this has rdepends still: gcc-4.8 (dep gcc-4.9-base, curiously) and gcc-4.9-cross; I suppose at least the latter could also be dropped?
<doko> pitti: we don't have to remove it now ...
<pitti> doko: no, not "have to", I just thought some cleanup before releasing can't hurt (I left gcc-4.9)
<pitti> mwhudson: green â¥ : http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#docker.io
<pishuilu>  cyphermox: Hi, can you help to upload ubiquity-slideshow pacakge to ubuntu? The url is https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
<cjwatson> Mirv: This is a thing you'd have to talk to the kernel team about
<cjwatson> Mirv: #ubuntu-kernel maybe?
<pishuilu> Hi,all. Who can help to upload ubiquity-slideshow pacakge to ubuntu. The url is https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html. Thanks!
<pitti> chrisccoulson: are you aware of the firefox and thunderbird FTBFSes? (stuck in -proposed for a while)
<pitti> doko, jbicha: you synced debtags, but the Debian version drops python-debtagshw and python3-debtagshw -- do you know whether there's a replalcement? (software-center and ti-omap4-software-channel
<pitti> ... depend on those)
<pitti> willcooke, seb128: ^ is software-center actually still a thing? or should this get removed now, in favor of gnome-software?
<pitti> one reverse-depends (ti-omap4-software-channel, looks obsolete too) and oneconf recommends it (can be ignored)
<pitti> ogra_: do you know, do we actually want to keep ti-omap4-software-channel ?
<willcooke> pitti, seb128 -  I think it can probably go now from X onwards
<pitti> willcooke: yes, only talking about y here
<seb128> I would keep it
<ogra_> pitti, well, not sure ... perhaps til 12.04 gets dropped ?
<seb128> it still support things gnome-software
<pitti> ogra_: again, talking about y here, not precise :)
<seb128> it still supports things gnome-software doesn't
<seb128> does it do any harm in universe?
<ogra_> pitti, i dont think there was ever anything else than 12.04 packages in the PPA
<ogra_> perhaps 12.10 ... but thats EOL
<pitti> seb128: not much right now, aside from blocking debtags in -proposed (not that urgent, but that's how I spotted it)
<seb128> why aiming at deleting it and not any of the other stack of cruft we have here?
<pitti> ogra_: ti-omap4-software-channel | 0.1 | yakkety/universe | source, all
<pitti> ogra_: ^
<seb128> why does it block it?
<seb128> oh, I see in backlog
<seb128> hum
<pitti> seb128: well, my question is rather whether we actually want to release it with y, given that nobody seems to maintain it any more
<seb128> it's still used even unmaintained
<pitti> seb128: nevermind the debtags thing, that's just how I noticed
<seb128> I would keep it
<ogra_> pitti, oh, the package ... yeah, kill that with bleach
<pitti> ogra_: ack
<ogra_> i wasnt even aware it still is in the archive :P
<ogra_> it is useless
<pitti> spring^Wfall cleaning day ;)
<ogra_> (for anything but 12.04)
<pitti> process-removals this morning, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt now
<pitti> (must be release week..)
<enrico> sad to see it go. It's maintained in debian, and meh.
<enrico> (debtags)
<seb128> enrico, I don't think anyone is deleting it, just that the update has no python bindings binaries
<pitti> enrico: how do you mean? I'm not talking about removing debtags, just software-center
<enrico> ah, ok, I though you were talking about debtags. I guess the highlights gave me a partial version of the chat thread
<enrico> sorry about the noise
<seb128> pitti, is any flavor still using software-center btw?
<pitti> seb128: no, it's not seeded anywhere
<seb128> k, well your call then, it seems a bit late to delete what was a major piece of software for Ubuntu without asking first if somebody wants to take over it
<seb128> and I think it's still nicer to use than gnome-software, more polished&reliable ... but I guess people who want polished&reliable are on the LTS and can still use it there
<pitti> I can still do that on u-devel@, but I'm not very hopeful; we tried to port it to py3 for many years and never found a real maintainer
 * pitti will ask
<seb128> thanks
<jbicha> if we're going to drop software-center because no one cares to do specific maintenance for it, let's do it at the start of a cycle rather than the end to give ~6 months for somemone to step up
<jbicha> pitti: bug 1616379
<ubottu> bug 1616379 in software-center (Ubuntu) "software-center depends on python-debtagshw, which is not built anymore" [High,Confirmed] https://launchpad.net/bugs/1616379
<pitti> jbicha: ah, thanks for pointing out
<seb128> barry, hey, small follow up to your email but the goal for those cycles was to get software-center out of the iso/in universe, I don't think anyone really carred about keeping it there
<barry> seb128: ack
<cpaelzer> I have recently seen a lot of auto-bug reports which aside the actual issue seem to contain an apport issue around "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 10006: invalid continuation byte" or similar
<cpaelzer> is that a known issue?
<pitti> cpaelzer: not on my radar, no
<pitti> barry: I synced python-pex, btw
<pitti> barry: tests pass again
<pitti> barry: also, happy thanksgiving
<barry> pitti: saw that, thanks!  and usa thanksgiving isn't until next month :)
<pitti> barry: oh, what's today's holiday then?
<pitti> oh, Columbus day
<barry> pitti: yeah, that's the official federal name of it, although there's a semi-movement to change the name to indigenous people's day
<bdmurray> flexiondotorg: Are you working on 1623856?
<flexiondotorg> bdmurray, Yes.
<bdmurray> flexiondotorg: cool, thanks
<pitti> cpaelzer: hah, I bent virt-qemu to my will now when using user/password login
<chrisccoulson> pitti, re thunderbird - I'm looking at that now
<chrisccoulson> Not sure what to do about firefox though. powerpc and s390 are endianness issues. And ppc64 is a crash on startup which causes the startup cache compilation to fail
<chrisccoulson> I'm not sure I can spend time on powerpc-specific firefox issues
<seb128> chrisccoulson, pitti, the current release pocket version has no s390x/powerpc build either, the issue is only ppc64el there
<seb128> it would migrate with that one
<xnox> pitti, is there anything better than $ systemd-analyze dot ? the output is a rat's nest.
 * xnox applies patterns
<jderose> chiluk: FYI, the package in your PPA fixes things for my use case, thanks! https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,In progress]
<pitti> xnox: what do you want to do?
<pitti> xnox: you can limit it to targets, or only show a particular part -- you ceratinly don't want the entire graph in all details
<xnox> yeah
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<smoser> am i missing something here ?
<smoser> dhclient-script (http://paste.ubuntu.com/23304770/)
<smoser> does
<smoser>  ip -6 addr flush dev ${interface} scope global permanent
<smoser> doesnt it need to do:
<smoser> err.. sjhoot
<smoser> it does this:
<smoser>  p -6 addr add ${new_ip6_address}
<smoser>  ip -6 addr add ${new_ip6_address}
<smoser>     dev ${interface} scope global
<smoser> when i think it needs to do
<smoser>  ip -6 addr add ${new_ip6_address}/${new_ip6_prefix}
<smoser>   dev ${interface} scope global
<smoser> without the prefix, we get an address with /128
<smoser> like:
<smoser>  fd42:83bb:a360:8010:8fda:82f7:5cdc:fb8a/128
<smoser> https://kb.isc.org/article/AA-01141/0/How-to-workaround-IPv6-prefix-length-issues-with-ISC-DHCP-clients.html seems relevant
<brendand> i have a xenial system that doesn't want to update anything, even though there are clearly new versions of lots of packages in -updates. i'm particularly seeking a new version of lxd
<brendand> -updates is definitely in sources.list
<mwhudson> pitti: yeah, it migrated finally
<mwhudson> and it's just waiting for sru team attention in xenial too i think
<brendand> apt update says: http://paste.ubuntu.com/23304826/
<rbasak> brendand: and apt-cache policy?
<brendand> rbasak, only knows about the old version
<brendand> i'm starting to suspect a proxy
<smoser> well, filed this : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1632096
<ubottu> Launchpad bug 1632096 in isc-dhcp (Ubuntu) "dhclient-script does not respect ip6_prefixlen" [Undecided,New]
<brendand> yup, definitely a caching proxy. i'm getting an old version of http://archive.ubuntu.com/ubuntu/pool/main/l/lxd/ even with wget
<tsimonq2> hmmmmm, am I the only person who has had problems with DNS in Yakkety?
<tsimonq2> seems to be DNS...
<brendand> was the 27th of may release day for xenial?
<brendand> now it all makes 'sense' (kind of)
<brendand> archive.ubuntu.com on this host is not the actual archive.ubuntu.com - the ip address is different
<brendand> and when i wget on my system from the same ip as on the system that won't update, i do indeed get a version of archive.ubuntu.com from the 27th of may
<brendand> system that won't update: 64 bytes from archive.ubuntu.com (91.189.91.15): icmp_seq=9 ttl=44 time=211 ms
<brendand> my system: 64 bytes from yukinko.canonical.com (91.189.88.162): icmp_seq=1 ttl=62 time=11.4 ms
<rbasak> Those are both Canonical IPs, so talk to Canonical IS I guess?
<brendand> and here's etc/hosts : http://paste.ubuntu.com/23304972/
<brendand> bingo
<brendand> sigh
#ubuntu-devel 2016-10-11
<cpaelzer> pitti: thanks, successfully verified your fix for bug 1630963 against the autopkgtest git
<ubottu> bug 1630963 in autopkgtest (Ubuntu) "issues using user and password in adt-virt-qemu" [Medium,Fix committed] https://launchpad.net/bugs/1630963
<pitti> cpaelzer: yay, thanks
<pitti> good morning
<cpaelzer> good morning pitti
<cpaelzer> and good morning everybody else
 * cpaelzer feels embarrassed for forgetting his manners by working from home :-/
<ginggs> morning pitti! eso-midas has been failing autopkgtests on s390x for a while now, could you do something to let motif migrate please?
<pitti> ginggs: hints updated
<ginggs> pitti: danke!
<ricotz> chrisccoulson, hi
<doko> apw: any update on xfsprogs?
<ricotz> chrisccoulson, isn't thunderbird 45 effected by https://bugzilla.mozilla.org/show_bug.cgi?id=1251576 too? and please pick up thunderbird 45.4.0
<ubottu> Mozilla bug 1251576 in General "GCC6 - TB crashes due to removed null pointer checks for "this"" [Normal,New]
<doko> chrisccoulson: and please remove the hardening b-d ...
<apw> doko, oh thanks for the reminder, looking at it now
<rbasak> Is there a simple but non-hacky cross-distro way to determine whether to install to /usr/local/lib64 or /usr/local/lib by default? Currently an upstream is testing for the existence of /lib64, but we have that for a ld-linux-x86-64.so.2 symlink, so they install into /usr/local/lib64 which we don't have as a path in ld.so.conf.
<rbasak> It's a hand-rolled Makefile build system
<sladen> rbasak: have a look what configure/autoconf do
<sladen> rbasak: I expect it is just to check the presence of one and use the other if not
<rbasak> I can't find the logic in autoconf :-/
<rbasak> Clearly it searches there when looking for libraries, but I can't find the bit that decides where to install stuff. Is that usually autoconf?
<cjwatson> That's more likely to be automake, if it's detected at all rather than something that you tell it.
<cjwatson> Er, I think.
<rbasak> I couldn't find a reference in automake, but I have just found something in libtool that looks promising
<cjwatson> Maybe I'm wrong there.  lib64 has always been a hideous hack, so I question the assumption that it will be handled well :-)
<cjwatson> I believe that RPM passes an appropriate --libdir to configure rather than expecting configure to detect it.
<cjwatson> (Source: https://fedoraproject.org/wiki/Packaging:RPMMacros)
<cjwatson> s/RPM/the Fedora packaging system/
<rbasak> It seems that libtool tries to parse ld.so.conf itself, though I can't get that to work locally. And it'd fail anyway since we use a .d.
<rbasak> But I think it'd fall back to not using a lib64, so that'd work for us anyway.
<cjwatson> IMO attempts to detect whether to install lib64 are best off being burned.
<rbasak> I wonder how things work on RH-based systems when not using RPM.
<pitti> cjwatson: do you have an idea how to find out what pulls perl+rename into standard? (http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt) no package in standard depends on either of those, and it's not seeded
<pitti> and we really don't want to make perl come back..
<cjwatson> pitti: Will look, give me a bit.
<pitti> it's also not seeded anywhere
<rbasak> cjwatson: I appreciate your response, thanks. Now I'm confident I'm not missing something that everyone knows :-)
<cjwatson> rbasak: ICBW of course, my attitude to lib64 has always been one of lofty indifference
<rbasak> cjwatson: but the problem is: what do I send upstream to fix this, if they're already expecting to detect lib64? If I remove that, they'll (reasonably) worry about breaking something.
<cpaelzer> outside rpm isn't too far from rpm - at least looking at their recommendation "rpm --eval '%{_libdir}'"
<cjwatson> Yeah, I don't know :-/
<cjwatson> pitti: germinate says (seeded) dnsutils Depends: libbind9-140 Depends: libdns162 Depends: libisc160 Depends: libxml2 Recommends: xml-core Depends: perl Recommends: rename
<rbasak> cpaelzer: ah, thanks! So I could concoct something based on that call, and it it fails or doesn't have lib64 in the output, then lib64 isn't in use? That sounds like it might work.
<pitti> cjwatson: argh -- cheers
<cpaelzer> rbasak: but be aware that on ubuntu that still gives you /usr/lib64
<pitti> cjwatson: so looking at germinate is the way to find out
<cjwatson> pitti: Yes, priority-mismatches is based on germinate output
<rbasak> cpaelzer: you mean if rpm is installed on Ubuntu?
<cpaelzer> yes
<pitti> cjwatson: ah, I see it in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.yakkety/standard now; thanks!
<rbasak> I wonder if one might consider that a bug in rpm's behavior on Debian/Ubuntu.
<rbasak> It'd still be better than what they're doing currently, since they're already assuming lib64 just because /lib64 exists
<cpaelzer> rbasak: unfortunately you said non hacky
<cpaelzer> rbasak: dirname $(ldd /bin/true | grep libc | awk '{print $3}')
<cpaelzer> rbasak: would do on fedora, centos, ubuntu and probably others
<cpaelzer> rbasak: but I understand you don't want to suggest such :-)
<cpaelzer> rbasak: or maybe you want if it is less broken than the current -e test
<rbasak> That does sound like the most non-hacky and reliable suggestion so far, thank you :)
<rbasak> Given that it seems that there is no non-hacky solution
<cpaelzer> rbasak: put the grep search into the awk to not get called stupid
<cpaelzer> I always only realize that later :-)
<rbasak> ldd /bin/true|awk '/libc\.so/{print $3}'|grep lib64 >/dev/null 2>&1  # maybe?
<rbasak> As I need a test rather than the path.
<cpaelzer> rbasak: how about: ldd /bin/true|awk '/libc\.so/{print $3}'|grep -q '^/lib64'
<cpaelzer> rbasak: less redirections
<rbasak> I didn't think "grep -q" was portable though - for example to BSD?
<cpaelzer> rbasak: and some insurance from ...lib64... strings
<cpaelzer> rbasak: is that your scope
<cpaelzer> rbasak: ok then not -q
<cpaelzer> rbasak: but I'd prefer the '^/lib64'
<rbasak> And I figured that if lib64 appeared anywhere for libc, then we're in lib64 mode.
<cpaelzer> rbasak: ok for me
<rbasak> cjwatson, cpaelzer, sladen: thank you for your help! Now I just have about three other painful but now-offtopic related things to fix :-/
<doko> hmm, iptraf doesn't show any interface besides lo in y ...
<cpaelzer> I beg a pardon if that it a faux pas by itself, but is there a reasonable way to get root permission in d/rules execution?
<cpaelzer> I'd want to use that for a bit weird autotest requirement
<cjwatson> cpaelzer: it's not possible in general; use autopkgtests instead for that kind of thing
<cpaelzer> cjwatson: thanks
<cjwatson> you can do "Restrictions: needs-root" there
<cpaelzer> cjwatson: yeah I have that for other tests already
<cpaelzer> the charm would ahve been to have that executed on the just built code - I'd like to avoid to build it just again for the adt
<cjwatson> yeah ideally you would have a test that you could run on the as-installed code instead
<cpaelzer> in that sense I already have it covered in a test run that we use to verify package uploads (with far more tests)
<cpaelzer> cjwatson: actually that might be a great idea - for Z* I might tihnk on putting the test program into the -dev package
<cpaelzer> cjwatson: is that in general kind of "ok" ?^^
<cjwatson> possibly, I don't know your specific situation
<cjwatson> you could also consider building only the test program in the autopkgtest
<cjwatson> openssh does a sort of partial build of itself in its autopkgtests in order to be able to build the regression tests
<rbasak> The link to the spec from http://dep.debian.net/deps/dep8/ appears broken
<rbasak> pitti: ^
<cjwatson> though possibly shipping them would be better
<rbasak> But IIRC there's a test restriction or something similar that specifies that the test needs a "built tree"
<cjwatson> right, you certainly *can* do that
<cjwatson> but it's better design to avoid it if possible
<rbasak> That in theory will mean that no rebuild is required, but in practice we do I think?
<cjwatson> especially if the build is slow
<caribou> bdmurray: rbasak: Regarding LP: #1629644, nothing came back from the bug reporter about the potential regression
<ubottu> Launchpad bug 1629644 in multipath-tools (Ubuntu) "Trusty: failure to detect device with 0.4.9-3ubuntu7.14" [High,Incomplete] https://launchpad.net/bugs/1629644
<caribou> I have another SRU to upload for multipath-tools, should I just disregard this bug & go on with the new SRU ?
<rbasak> caribou: I see no others claiming to be affected in that report or any other reports, so I'd go ahead and disregard.
<caribou> rbasak: thought so too; thanks!
<pitti> coreycb: what's the justification for the python-pycadf sync?
<coreycb> pitti, hi, sorry for the late sync.  it's not critical but the pycadf sync aligns us with the version that upstream has been testing with.  it really just includes a minor typo fix of invalid chars in a config file.
<nacc> smoser: re: LP: #1632340, we'll need a source patch like 75336788 added
<ubottu> Launchpad bug 1632340 in usd-importer "stacktrace fail import cloud-utils" [High,Confirmed] https://launchpad.net/bugs/1632340
<stgraber> pitti: hmm, so could it be that some of that user session work this cycle is causing me to loose all my open windows (as in, all processes die) when some bits of unity crash? it used to be that compiz would crash, respawn and all would be fine, but now it respawns with a clean desktop...
<slangasek> stgraber, mdeslaur, infinity, kees: TB meeting in 16; but I suspect infinity is not actually available to chair this week because release?
<jderose> infinity: are you expecting another round of ISO spins now that 4.8.0-22 has landed?
<pitti> stgraber: certainly could be that this is missing some tweaks; the intention is that gnome-session.service is the "session leader", i. e. if that crashes everything is gone; but compiz/unity should actually restart by itself and not take everything else down with it
<pitti> stgraber: mind filing a bug with the details?
<xnox> stgraber, i guess unlike upstart, the cgroup is respawned and everything is scoped into the compiz one, instead of patiently waiting for it to come back.
<Laney> pitti: Isn't it that unity7 is in ubuntu-session.target.requires/ ?
<Laney> (Not exactly sure what that means with Restart=on-failure though)
<pitti> yeah, that could be it -- maybe we need Wants=?
<stgraber> pitti: what should I file that bug against? also not sure how much information I can provide. I suspect you can reproduce it by sending SIGSEG to compiz though.
<stgraber> obviously, it'd be better if compiz didn't crash, but given that we've failed at making that happen in the past 4 years or so, dealing with it crashing is a good idea :)
<pitti> coreycb: you're right, the diff is "fairly harmless"
<pitti> stgraber: unity for now (as that ships the file), please assign to me
<seb128> stgraber, pitti, I doubt it's systemd session, that was reported before we started that transition
 * pitti will have a look later, just grabbing some dinner
<stgraber> seb128: oh? still a yakkety regression though right? pretty sure my xenial desktop respawned compiz properly a couple of days ago
<seb128> I don't think so
<stgraber> maybe a different bug then, I have compiz crashes every week or so and never lost all my windows as a result of it, so something definitely changed
<seb128> stgraber, bug #1613297 is the one I know about, unsure if that's what you get
<ubottu> bug 1613297 in unity (Ubuntu) "unity --replace crashes/closes some applications (but not all) since 16.04" [High,Triaged] https://launchpad.net/bugs/1613297
<stgraber> seb128: I "think" it's unrelated as I explained in https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1632386 just now
<ubottu> Launchpad bug 1632386 in unity (Ubuntu) "On yakkety, a unity crash and respawn kills all windows" [Undecided,New]
<seb128> stgraber, could well be, I just mentioned it in case that was useful
<seb128> stgraber, do you also have a report about the u-p-s taking compiz down issue?
<Pharaoh_Atem> I'm getting a weird issue when I attempt to build uw-imap for Ubuntu 14.04
<seb128> Trevinho, willcooke, ^ is that known? sounds like an annoying one
<stgraber> seb128: I wish I did but for whatever reason, I don't see any crashes in /var/crash/
<Pharaoh_Atem> https://paste.fedoraproject.org/448671/62025631/
<seb128> stgraber, get a vt with gdb attached to compiz until next one?
<Pharaoh_Atem> the thing is, according to the full build log, the dev packages it's talking about are installed: http://kinginuyasha.enanocms.org/downloads/uw-imap-obsbuild.log
<willcooke> seb128, not known to me.  But Trevinho is your man
<Trevinho> seb128: mhmh... Well it's all due about  the season being dependent on unity 7
<stgraber> seb128: yeah, I'll try to remember to keep that going (I unfortunately reboot this machine very frequently for kernel testing)
<Pharaoh_Atem> I don't suppose anyone here knows how to fix d-shlib issues?
<seb128> Trevinho, but unity segfaulting should lead to a respawn, not to a job stop, no?
<nacc> Pharaoh_Atem: possibly it's related to: https://lists.debian.org/debian-user/2003/05/msg00029.html
<nacc> Pharaoh_Atem: maybe the versions don't match between what is in the package deps and what is in trusty?
<Trevinho> seb128: yes....
<Pharaoh_Atem> nacc: that makes no sense, since the package is rebuilt from trusty universe for trusty
<Pharaoh_Atem> the uw-imapd package seems to be broken out of the gate on trusty
<nacc> Pharaoh_Atem: so you're just doing a rebuild?
<Pharaoh_Atem> yes
<Pharaoh_Atem> our system doesn't have access to ubuntu universe for trusty, so I did an import to rebuild them
<gQuigs> hi there, can someone on the SRU team please review the vlan upload?  (aka, https://launchpad.net/ubuntu/xenial/+queue?queue_state=1)
<gQuigs> it's from bug - https://bugs.launchpad.net/debian/+source/vlan/+bug/1224007
<ubottu> Launchpad bug 1224007 in vlan (Ubuntu Xenial) "mtu not always set properly on bond/vlan interface" [Medium,In progress]
<nacc> Pharaoh_Atem: hrm, a test rebuild in a trusty schroot worked?
<Pharaoh_Atem> nacc: that's weird
<Pharaoh_Atem> it's not like the package set is any different
<nacc> Pharaoh_Atem: did you try doing it in a PPA?
<Pharaoh_Atem> no
<Pharaoh_Atem> the only difference between my environment and Launchpad's is probably the lack of updates being applied (because it needs to work with 14.04 base)
<infinity> jderose: Yes.
<jderose> infinity: okay, thanks! you expect a respin today then?
<infinity> jderose: Very soon, yes.
<powersj> infinity, does that include the server iso?
<pitti> across the board, we got a new kernel
<pitti> (plus other things which affect all flavors/images)
<powersj> pitti, ok thanks!
 * infinity just spent the last half hour "debuggin" why his internet was broken until he realized it was his laptop that was acting up.
<infinity> I feel smart today.
<doko> apw: xfsdump needs the same love as xfsprogs
<nacc> smoser: did you see my MR feedback?
<smoser> whoops
<smoser> didn't change commit after i researchdd
<smoser> funny
<smoser> will fix
<smoser> pushed
<smoser> ok, now pushed.
<nacc> smoser: thanks
<nacc> smoser: merged, with a fixup commit on top, check out master when you can
<smoser> so what will uyou do about dpkg parsing ?
<smoser> that sucks.
<nacc> smoser: not much i can do
<smoser> one thing i thought is we could allow for manual
<nacc> well, beyond the fixup i documented above
<smoser> in event of parse fail, ask user
<nacc> that's what hte fixup is, basically
<nacc> ah
<nacc> that won't work for cron :)
<smoser> no it wont, but we expect it to only ever happen for first run
<smoser> as new archive tools wont let crap in
<nacc> maybe
<nacc> we have a fixup method already, though
<nacc> i'd rather not add a second
<smoser> oh?
<nacc> yes, i mentioned it above?
<nacc> smoser: re: LP: #1632340, we'll need a source patch like 75336788 added
<ubottu> Launchpad bug 1632340 in usd-importer "stacktrace fail import cloud-utils" [High,Confirmed] https://launchpad.net/bugs/1632340
<nacc> smoser: we have a facility to patch the 'source' from a published version
<nacc> smoser: and provide a range of versions to which that patch applies
<nacc> as typically it gets fixed eventually
<smoser> nacc, ok. yeah.
<nacc> smoser: it's the most generic solution rbasak and i could could come up with :)
<nacc> smoser: i need to run a quick errand, but i can look at what's needed for the source patch after that and hopefully get you something imported by EOD
<Pharaoh_Atem> nacc: it doesn't seem to work even when OBS is building an Ubuntu VM to do the build: https://build.opensuse.org/package/live_build_log/home:Pharaoh_Atem:u1404_stuff/uw-imap/xUbuntu_14.04/x86_64
<Pharaoh_Atem> do you have a build log showing what was installed in the schroot?
<chiluk> thanks jderose for reporting back.
<jderose> chiluk: np, thanks for the fix!
<chiluk> cyphermox can I get some upload lovin on https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,In progress]
<cyphermox> chiluk: that seems very wrong to me
<chiluk> ok .. one sec..
<slangasek> upload lovin seems wrong to you?
<cyphermox> no, that particular upload lovin'
<cyphermox> chiluk: it should be fine to do ip=eth0 or ip=BOOTIF
<chiluk> correct.
<cyphermox> doesn't appear to work for me.
<chiluk> I think my fix still works with those.
<chiluk> cyphermox: I'll get back to this in 20 minutes or so.. sorry in a meeting.
<cyphermox> if you set ip=eth0, DEVICE is unset.
<cyphermox> you also don't want to set DEVICE=BOOTIF if you got ip=*:...BOOTIF, as "BOOTIF" is just a placeholder for an actual device name
<cyphermox> oh, actually
<cyphermox> screw ip=eth0; it's not in that case stanza
<cyphermox> but this appears to break for ip=:::::BOOTIF, I think
<chiluk> right cyphermox.. that's why I doesn't apply.
<chiluk> s/I/it/
<chiluk> I'll look at BOOTIF.. although I don't know if that's a valid use case either.
<chiluk> really I'd like to completely rewrite the whole configure_networking section at this point.
<chiluk> there's a lot of failed use cases.
<cyphermox> which?
<cyphermox> I will do rewriting later
<chiluk> for example :a:b:c:d:device:blah:yada: fails.
<chiluk> because it is missed by the ::::*) case statement
<chiluk> it should be :.*:.*:.*:.* o something like that.
<cyphermox> it's not meant to be caught by that
<chiluk> or there should be a separate if in the catchall.
<chiluk> also previously ip=::::eth0:dhcp may have been failing since :dhcp wasn't being stripped.
<chiluk> I tried to keep the fix as minimal as possible so as not to introduce too much change all at once.
<cyphermox> I'm not sure that should be supported
<chiluk> I think all things in kernel docs should be supported.
<cyphermox> seems to me like all you really need in that case is
<cyphermox> if ! echo "${IP}" | grep -q 'BOOTIF\|dhcp$\|any$\|on$'; then
<cyphermox> 	DEVICE="${IP#*:*:*:*:*:*}";
<cyphermox> fi
<chiluk> my kingdom for a bash shell during boot.
<chiluk> =~ is your friend..
<jderose> chiluk: hehe :)
<chiluk> cyphermox.. I was starting to look at the upstream debian project for this.. why is Ubuntu so diverged from debian?
<chiluk> long story?
<chiluk> ideally all our changes should go in there.. and then trickle back down.
<cyphermox> all we need to care about here is this particular switch case, where one does simple dhcp, until we look at everything else in Z and finish ripping out klibc
<cyphermox> this divergence is because klibc/ipconfig doesn't do IPv6, and we need something that does
<cyphermox> so in that aspect, we don't overly need to care about ::::device:proto, because that does to another switch case which just does ipconfig as it did before
<cyphermox> maybe we're missing one :
<chiluk> cyphermox this line NEW_DEVICE=${IP#*:*:*:*:*:*}   should be
<chiluk> NEW_DEVICE=${IP#*:*:*:*:*:}
<cyphermox> no
<cyphermox> or why?
<chiluk> because it's not regex matching right?
<chiluk> I could be wrong on this.
<chiluk> I did want to point it out though.
<chiluk> I checked both and both seem to function..
<chiluk> but # = strip matching from front.
<chiluk> the last * matches the device...
<chiluk> do you know why both work.
<cyphermox> I don't
<cyphermox> but we don't need to overthink it if it passes proper testing
<chiluk> yeah I think without the * is more correct in that I think the shell is just trying to be smarter than the user since the final * would match all remaining chars
<chiluk> just saying.. something I noticed.
<cyphermox> wfm
<cyphermox> looks like what you're missing is more or less just handling BOOTIF, and dropping the [ ] around your if
<cyphermox> chiluk: so something like this: http://paste.ubuntu.com/23309789/
<chiluk> ok.
<chiluk> so that was another thing..
<chiluk> ip=BOOTIF wouldn't hit that case stanza at all.
<chiluk> ip=:::::BOOTIF would.
<cyphermox> yes
<chiluk> but I'm not sure if that's valid... /me rtfm
<cyphermox> it most definitely is
<cyphermox> and if it wasn't in the doc, then it was supported before and needs to continue working
<nacc_> jgrimm: can you or lamont verify LP: #1611923 for x?
<ubottu> Launchpad bug 1611923 in python-django (Ubuntu Xenial) "http.request does not support ipv6-formatted ipv4 addresses" [Medium,Fix committed] https://launchpad.net/bugs/1611923
<chiluk> yeah cyphermox it's definitely not in the kernel documentation.
<chiluk> I'm checking debian docs now.
<balloons> micahg, you about?
<balloons> mwhudson, in order to upload the mongodb to trusty we'll need signoff from the backporter's team. I suspect micahg can help
<mwhudson> balloons: ok
<mwhudson> balloons: afaict the package meets all the criteria on https://wiki.ubuntu.com/UbuntuBackports so this shouldn't be too big a deal i hope
<balloons> mwhudson, ack. So we should mark the bug confirmed then.. Actually I think they may even just upload it
<Unit193> Except the whole not-enough-backporters thing.
<balloons> hey Unit193!
<Unit193> Howdy
<mwhudson> balloons: i guess https://bugs.launchpad.net/trusty-backports/+bug/1583740 doesn't explain how it meets the criteria
<ubottu> Launchpad bug 1583740 in trusty-backports "mongo client is missing" [Undecided,New]
<mwhudson> balloons: might be better to file a fresh bug?
<balloons> mwhudson, did you run the backport tool against it?
<mwhudson> balloons: no
<balloons> presumably that's how the bug was filed eh?
<mwhudson> balloons: eh no, that's the same bug as was used for the SRU
<balloons> mwhudson, ahh.. Then I agree. File a new bug with the tool.
<mwhudson> balloons: i don't know how the trusty-backports task got added
<balloons> me neither ;-)
<balloons> unless I did it
<mwhudson> balloons: you added it!
<balloons> lol, there it is!
<mwhudson> balloons: in june :)
<balloons> ROFL
<mwhudson> balloons: so do you want me to run the requestbackport tool or will you?
<balloons> mwhudson, I assume I did which is how it happened, but.. I've no idea at htis point
<balloons> mwhudson, please run with it if you can. I really have to EOD
<balloons> mwhudson, a new bug, with the tool sounds sanest for everyone
<balloons> it's simple to do
<mwhudson> balloons: ok
<mwhudson> uh why does requestbackport think i want to backport it to xenial as well
<mwhudson> heh i haven't actually installed the trusty packages, i guess i should do that :)
 * mwhudson afk for 15
<rbasak> 7/w #maas
#ubuntu-devel 2016-10-12
<cpaelzer> good morning
<doko> Mirv: looking at https://launchpadlibrarian.net/289272540/buildlog_ubuntu-yakkety-amd64.qliss3d_1.4-2_BUILDING.txt.gz
<doko> there's a X11 header check, but it looks like it's triggered by CHECK_QT4, so some qt4 dev package seems to be missing an x11 -dev dependency
<Mirv> doko: I haven't spent many minutes with Qt 4 since initial 2012 qtchooser work, but there is just two dev packages libqt4-dev and libqt4-opengl-dev. the former does recommend libqt4-opengl-dev that depends on Mesa dev than depends on X11 dev
<Mirv> it does not seem there would be anything related changed in Debian after last Ubuntu merge
<doko> Mirv: ok, adding libx11-dev gets me one step further: https://launchpadlibrarian.net/289273657/buildlog_ubuntu-yakkety-s390x.qliss3d_1.4-2ubuntu1_BUILDING.txt.gz
<doko> now complaining about missing shared qt libs
<doko> Mirv: add the libqt4-opengl-dev b-d doesn't help
<Mirv> so it has built in Debian six months ago, before qt4-x11 4.8.7+dfsg7. dfsg7 added -std=gnu++98 as a workaround for GCC6, maybe that could affect something negatively
<pitti> Good morning
<Mirv> or as it's using autotools for some reason, they'd need to be updated or qmake used instead (there is qliss3d.pro in addition to the autotools files)
<handsome_feng> Hi, gays, Good morning !Because of some issues found in test today, we have updated the theme package,  Could anyone help to upload this: package: ubuntukylin-theme, Code : https://code.launchpad.net/~zctgbhu/ubuntukylin-theme/16.10 Release: https://launchpad.net/ubuntukylin-theme/16.10/1.6.2 , Thank you !
<doko> Mirv: ahh, that's failing because *no* libs can be found in /usr/lib anymore ;-P
<doko> ++ ls '/usr/lib/*.a'
<doko> + QT_IS_STATIC=
<doko> + test x = x
<doko> + QT_IS_STATIC=no
<doko> + test xno = xno
<doko> ++ ls '/usr/lib/*.so'
<doko> + QT_IS_DYNAMIC=
<doko> + test x = x
<doko> + as_fn_error 0 '*** Couldn'\''t find any Qt libraries' 4119 5
<doko> + as_status=0
<doko> so this qt config test is horribly broken :-/
<tmus> I've disabled resolved completely, using dnsmasq instead. But if I connect to a VPN, the domain provided as "dns-search" from the VPN server, is the ONLY domain that's resolved by the DNS on the VPN connection, causing a lot of things to not work... Can I send ALL DNS queries the way of the VPN?
<tmus> This worked fine in 16.04
<pitti> tmus: could be fallout from bug 1592721
<ubottu> bug 1592721 in network-manager (Ubuntu Xenial) "Don't write search domains to resolv.conf in the case of split DNS" [Medium,Fix released] https://launchpad.net/bugs/1592721
<pitti> tmus: NM uses dnsmasq by default again in 16.10, FTR
<tmus> pitti, good to hear that resolved was pulled - i like the idea, but not ready yet imho...
<pitti> tmus: it's still being used on the server
<pitti> tmus: for NM we need a proper DNS plugin for split-horizon DNS, which didn't exist until two weeks ago
<pitti> we'll get that in Z
<tmus> pitti, cool...
<pitti> tmus: but your issue sounds like an NM-internal change (the above bug)
<tmus> having read through the bug, this is clearly related, but not the same problem
<tmus> For my VPN (this particular VPN anyway), i'm not split-tunnelling. Still, only DNS requests to my VPN's primary search-domain goes to the VPN DNS
<tmus> (we have a looot of internal domains - but only the primary resolves correctly)
<tmus> looking through syslog, it's clear that dnsmask is asked to use the VPN provided DNS servers *only* with the provided search-domain
<tmus> actually it may be the same but now that i'm reading it the second time
<tmus> pitti, can I msg you 10 lines of log to explain?
<pitti> tmus: you can, but I suggest to put them on the bug instead and discuss there (busy with release stuff)
<tmus> pitti, fair enough :)
<pitti> cpaelzer: btw, you need https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=40cb56b9 as well if you have any tests that reboot
<cpaelzer> thanks pitti
<cpaelzer> pitti: I was broken on s390 due to other things then, but happy on amd64 with my tests that did not include reboots
<seb128> mardy, hey, is https://errors.ubuntu.com/problem/cdb7a4fc6d47e3ba3ce18606745c27933f9a7f57 something you are aware of? it's the nÂ°1 error on e.u.c for 16.10
<seb128> could be a qt issue, webbrowser seems to have a similar report
<seb128> Mirv, ^ do you know about those reports?
<mardy> seb128: I really wasn't, thanks
<seb128> mardy, yw
<mardy> Mirv: it's QNetworkManager, and happens during destruction...
<mardy> Mirv: the first reports are from Oct 2nd and happen with older versions of signon too. So I guess it's due to some Qt landing...
<seb128> mardy, Mirv, webbrowser has the same issue so it would suggest a qt bug rather than a signon one
<Mirv> seb128: yes, bug #1630765 , happens after bug #1618590 got fixed. there's silo 2054 that is in QA's hands that includes a cherry-pick from Qt 5.8 which however upstream doesn't seem suitable for their 5.6 criteria, but we might accept that workaround
<ubottu> bug 1630765 in webbrowser-app (Ubuntu) "webbrowser-app crashed with SIGSEGV in QNetworkConfiguration::~QNetworkConfiguration()" [Medium,Confirmed] https://launchpad.net/bugs/1630765
<ubottu> bug 1618590 in Canonical System Image "scoperunner crashed with SIGSEGV in QObject::disconnect()" [Critical,Fix committed] https://launchpad.net/bugs/1618590
<Mirv> latest discussion about what the workaround would be hiding is at https://codereview.qt-project.org/#/c/172173/ , thanks to Michael from our side for providing valgrind trace to upstream
<seb128> k
<seb128> which I guess means it's not going to be fixed for release
<Mirv> I guess no. reverting to the previous version would bring the scoperunner crash-on-exit back.
<Mirv> ubuntu-qa: have you started looking at silo 2054 for desktop (and xenial+overlay phone)?
<davmor2> Mirv: nope still in the queue
<Mirv> I was hoping there'd be a real fix by now, but it starts to look like we'd need to stop unloading those plugins
<morf> hi
<morf> is it possible to install ubuntu mobile to samsung galaxy s5 (klte)?
<pragomer_1> Getting error "/init line 7 can't open /dev/sr0 no medium found" when booting via pxe.. here's my menu-entry:http://pastebin.com/3EJ4cPdp    Whats wrong?
<ginggs> tseliot: the libcuda-8.0-1 provides seems to have fallen out of the nvidia driver somewere between 361 and 367
<bdmurray> jbicha: Why did you reopen the yakkety task for bug 1619188?
<ubottu> bug 1619188 in casper (Ubuntu Yakkety) "Unattended upgrades can break persistent live media" [Medium,Triaged] https://launchpad.net/bugs/1619188
<jbicha> bdmurray: because I assumed it was broken on yakkety too, but I'll re-close it now
<bdmurray> jbicha: I just booted a yakkety live cd again and -security is commented out and the script is +x so its good.
<jbicha> bdmurray: good, I'm glad yakkety works at this point :)
<tseliot> ginggs: I don't recall removing it, or maybe I simply imagined adding that?
<tseliot> ginggs: BTW, is that only for yakkety?
<tseliot> I actually said "I have just uploaded your changes", so it's just me losing that change somehow
<ginggs> tseliot: yes, it is only for yakkety (for now - maybe commit to git for xenial and include with next upload so we can put cuda in backports)
<tseliot> ginggs: ok, thanks
<ginggs> i was definitely in 361 https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/361.45.11-0ubuntu4
<ginggs> *it
<tseliot> ginggs: yes, I probably used a slightly older branch as a base when creating the one for the 367 series
<tseliot> ginggs: uploaded. I managed to find the same commit from the 361 branch. Go figure...
<ginggs> tseliot: thanks!
<tseliot> thanks for making me notice
<nacc> can anyone see clearly why osgearth and qgis haven't migrated from trusty-proposed to trusty? All other archs have, and update_excuses/update_output say they are 'successful' and in the 'final' list.
<nacc> sorry, specifically on armhf only
<chiluk> cyphermox.. debdiffs in lp 1631474 ... modified per your recomendation.... I also did a bit more testing..
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,In progress] https://launchpad.net/bugs/1631474
<chiluk> not exactly what you asked for, but I felt it flowed better this way.. I claim personal preference.. I also improved the comment in case the next guy doesn't think like I do.
<slangasek> nacc: that sounds somewhat related to the changes pitti was just making to britney this week
<slangasek> nacc: oh, also, I'm not sure if we actually do migration of binaries using proposed-migration for stable releases
<slangasek> it might require a manual copy
<nacc> slangasek: ok, i was just surprised the other archs migrated but armhf hadn't
<nacc> slangasek: maybe it just needs a manual poke? should i be asking #ubuntu-release instead?
<slangasek> nacc: no, #ubuntu-release is busy with releasing ;)  I'm having a look at these
<Laney> nacc: I think they're just random builds that happened after the release
<slangasek> nacc: "the other archs migrated" - except they didn't, because what Laney said
<nacc> slangasek: yeah, i was hesitant to interject there today :)
<nacc> Laney: ah
<Laney> We deleted some similar ones in xenial earlier today
<Laney> Not sure how they got retried; didn't think that was available for released suites (but ICBW there)
<nacc> ok, had a user in #ubuntu wonder why qgis wasn't installable on armhf in trusty
<nacc> Laney: except for osgearth, it's not a rebuild? or do you meant something else
<Laney> Build failure that later succeeded
<nacc> ah!
<nacc> slangasek: Laney: thanks for the explanation!
<slangasek> nacc: ah yeah I can't work out how to actually copy these in to trusty-updates, because copy-package operates on source packages and there is no source in trusty-proposed.  Punting until a launchpad wizard can look at it (post-release)
<slangasek> (my best idea so far is to copy the source /back/ from trusty release into trusty-proposed, so that there's then a source package that can be copied; but that sounds like a good way to make launchpad very angry about publication history)
<infinity> slangasek: copy-package -e $ver --force-same-destination --from-suite=trusty-proposed -b foo
<nacc> slangasek: ack, i'll put it on my todo to follow-up on later
<slangasek> infinity: when the source was never previously in trusty-proposed?
<infinity> slangasek: If it ever existed in trusty-proposed, LP will magically find it and put it back.
<slangasek> ah
<slangasek> ok
<slangasek> yeah this is "random arch build caught up post-release"
<slangasek> so it was never in -proposed
<slangasek> errr wait
<infinity> Sure it was.
<slangasek> everything builds in -proposed these days
<infinity> EVerything starts out in proposed.
<slangasek> hee
<slangasek> thanks
<nacc> smoser: heh, your cloud-utils import kind of forced me to rethink the solution we had. It's now a bit more abstracted in the code and handles your particular case better (it was a real bug in the old implementation). When we do a source patch, we need to do it anywhere we might encounter that published version, including when we are lookingat the parents of a new import
<slangasek> Copy candidates:
<slangasek> <hang>
<slangasek> ah there it is
<smoser> nacc, so uploaded ?
<nacc> smoser: testing my fix now :)
<smoser> you have a feel / guess for how many packages might need "source patch" ?
<nacc> smoser: and then need to actually clean up my changelog etc, but i think it's working
<nacc> smoser: so far we've hit 3
<smoser> 3/~50
<smoser> :-(
<nacc> smoser: yep
<nacc> smoser: not great, not terrible (IMO)
<smoser> $ proxy curl --silent http://archive.ubuntu.com/ubuntu/dists/xenial/main/source/Sources.xz | xzcat | grep ^Package: | wc -l
<smoser> 2470
<smoser> 6% failure rate on 2400 packages is 144
<smoser> without touching universe. so yeah, maybe its not bad, but if in fact we have to manually patch 144 things, that sucks.
<nacc> and i'm not sure it's on my roadmap to support importing all of main :)
<nacc> as of right now, i'm focused on server packages
<nacc> i'm not saying it's not a problem
<smoser> what about just going on ?
<smoser> warn: could not import package at version X.
<nacc> then we'd have an inaccurate history
<nacc> there are algorithmic guarantees we are trying to assert :)
<nacc> we do orphan packages in some cases
<smoser>  --allow-failed-imports
<smoser> given the archive seems to have started rejecting things like that, its probably mostly a historic problem.
<nacc> it's exclusively historic
<nacc> smoser: feel free to file a bug :) as of right now, i'm not convinced it's a large enough issue to warrant adding a flag, or changing the algorithm again
<smoser> nacc, alternatively i could convince you otherwise by changing that pipe command above to just loop over usd-import <package>
<smoser> and file individual bugs :)
<nacc> that would also be fine
<nacc> smoser: it would be interesting to run that with --no-push, tbh, it'll probably take a few days to complete
 * smoser tries
<nacc> smoser: ok, cloud-utils can import with my fix(es). Want me to push now, or are you ok with waiting while I clean up my changelog
<smoser> nacc, not really a hurry
<smoser> just if i'm going to look at code now, i first run usd-import
<nacc> smoser: ok, i should be able to push in about 20 minutes, it's not that complicate of a change, i just want to verify it a bit
<jderose> chiluk: something seems slightly wonky with latest initramfs-utils from your PPA (at least for my use case); i added a comment to the bug
<chiluk> thanks jderose
<chiluk> jderose: can you get me full console log output?...
<jderose> chiluk: yeah, what's the best way to do this?
<chiluk> check to see if the errors are showing in /var/log/syslog or kern.log.. I suspect neither.
<jderose> chiluk: or what's the place to dump this from if i don't have a serial console setup? after the boot i can mount a usb drive, copy it over to that
<jderose> chiluk: okay, i'll just grab everything from /var/log
<chiluk> dumping serial console would be the best .. as I don't think the messages you are seeing get dumped into /var/log
<slangasek> nacc: so these packages are uncopiable, even with infinity's hint, with an error about 'binaries conflicting with the existing ones'.
<jderose> chiluk: i'll try to get serial console smart in the mean time, but no promises :)
<chiluk> that would be awesome jderose...
<nacc> slangasek: hrm, that's odd, because rmadison says there are no binaries for armhf?
<slangasek> nacc: certainly
<chiluk> jderose what is your /proc/cmdline as well?
<slangasek> nacc: it's a strange error, and there certainly should never have been /different/ binaries with the same version number
<nacc> slangasek: agreed -- do you want me to file a bug?
<slangasek> nacc: against launchpad, sure
<nacc> slangasek: ok, thanks!
<jderose> chiluk: "initrd=initrd.img-4.4.0-36-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0"... so the only "weird" thing i'm doing is using net.ifnames=0, not sure if that's effecting anything or not
<chiluk> ah jderose I think what's happening is htat you are now going through the full all_net_bootable device bringup loop.
<chiluk> which wasn't functioning correctly before.
<jderose> chiluk: okay, so this is working as expected, despite making stuff take a bit longer?
<chiluk> yeah ... jderose ... give me one second.
<nacc> slangasek: LP: #1632800
<ubottu> Launchpad bug 1632800 in Launchpad itself "qgis and osgearth stuck in trusty-proposed for armhf" [Undecided,New] https://launchpad.net/bugs/1632800
<chiluk> jderose ... I'm going to give you a script to run on your machine ..  we may have to strip out some additional devices.
<chiluk> it also could just be possible that it's now trying all your devices for a dhcp server.
<chiluk> instead of just the one you want.
<jderose> chiluk: FYI, this was PXE booting a machine with one Ethernet and one WiFI nic
<chiluk> jderose can you run http://paste.ubuntu.com/23313997/  for me?
<chiluk> and tell me the output?
<jderose> chiluk: is it okay to run it after the full boot completes, or does in need to be run early, like in the initramfs stage?
<chiluk> after full boot should be good enough.
<jderose> okay, just a sec...
<chiluk> I just want to see if you have any odd devices..
<chiluk> and the order in which they come up.
<chiluk> cyphermox... hold off for a second... Looking at jderose's use case ..
<chiluk> yeah so looking into it jderose I suspect the initramfs may be attempting to bring up your wlan device as well.
<chiluk> the solution to that would be using ip=:::::eth0:dhcp instead of simply ip=dhcp
<chiluk> which is actually more correct than it was previously.
<jderose> chiluk: you're script is just outputting "eth0"
<chiluk> hmm. I expected you to have multiple devices..
<chiluk> and one failing.
<chiluk> jderose: do you get the same errors if you use ip=:::::eth0:dhcp ??
<chiluk> jderose.. for your use case nothing much has changed between 8.3+lp1631474 and 8.3+lp1631474b2 ..
<cyphermox> chiluk: too late.
<chiluk> you should be following the same logic path with both commits.
<chiluk> it's ok cyphermox.. I think we have something else at play here with jderose.
<cyphermox> my guess is there are timeouts -- the right way to figure this out is to get all the logs
<chiluk> cyphermox: does that mean you've made the upload?  I think we are still safe with the debdiffs as they are currently in the bug.
<cyphermox> yes, it's done, and yes, that part is correct
<jderose> chiluk: okay, "ip=:::::eth0:dhcp" seems to work fine, no unexpected delay
<jderose> but "ip=dhcp" still works differently than it previously did
<chiluk> cyphermox ^^^ sounds to me like we're now correctly processing  all_netbootable_devices ..
<chiluk> but running all_netbootable_devices for him only yeilds eth0.
<chiluk> which is odd.
<cyphermox> what other devices are there?
<chiluk> cyphermox: running all_netbootable_devices  only shows eth0..
<chiluk> which is why I'm confused..
<chiluk> jderose you said there was a wireless card in there as well right?
<cyphermox> yes, what other interfaces should there be?
<jderose> cyphermox: just a wifi NIC, although `ifconfig -a` isn't actually showing the device for whatever reason
<chiluk> probably lacks drivers
<cyphermox> well, then that's the reason -- the driver is probably missing
<cyphermox> "missing" == not loaded yet
<chiluk> but that' doesn't explain why ip=dhcp causes errors where ip=:::::eth0:dhcp does not.
<chiluk> at least for him.
<jderose> maybe so. seems `wifi-tools` isn't install by default on ubuntu server, so that might be the problem too
<chiluk> jderose what do you see in /sys/class/net/*   ?
<jderose> chiluk: just "eth0" and "lo"
<cyphermox> jderose: please open a bug and add all the output you have on screen as you try to boot
<jderose> cyphermox: sure, but i might not have time till tomorrow
<chiluk> that's fine.. jderose.. something else is going on in your boot case..
<jderose> chiluk: gotcha, thanks. seems like i can just use "ip=:::::eth0:dhcp" and be fine
<chiluk> feel free to ping me or cyphermox jderose when you have all thte logs grabbed.
<jderose> okay, will do
<dmj_s76> infinity: In doing upgrade testing xenial->yakkety, the updater complains that it can't authenticate.  Is that expected currently?
<slangasek> dmj_s76: certainly not; can you be more specific?
<dmj_s76> So running do-release-upgrade -d
<dmj_s76> gpg: BAD signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
<dmj_s76> Authentication Failed
<dmj_s76> Authenticating the upgrade failed.  There may be a problem with the network or with the server.
<dmj_s76> Similar authentication failure message when using the graphical updater
<slangasek> dmj_s76: ok, could that mean that you have (or did have) a captive portal in the way that is corrupting the download?  Do you see a similar failure from 'sudo apt update'?
<chiluk> slangasek can I get sru approval for https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474  initramfs-tools ?  you look to have approved the previous sru for initramfs-tools.
<ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu Yakkety) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,In progress]
<slangasek> chiluk: ENOTIME; grab the sru staffer du jour?
<chiluk> will do.
<chiluk> I understand you guys are knee deep in release time.
<dmj_s76> slangasek: Actually checking into that
<dmj_s76> slangasek: apt update works fine
<tsimonq2> Who is responsible for yaboot nowadays?
<dmj_s76> slangasek: infinity: Sorry to worry you guys.  It was a caching issue on our network.
<slangasek> dmj_s76: so I suspected, thanks for confirming :)
<dmj_s76> Had to wait to confirm on our end but wanted to give you a heads up in case it was an issue blocking testing for others
<slavanap> I'm Windows developer. I want to implement Ubuntu File Manager right click extension. Where should I start? Which docs should I read first?
<tsimonq2> slavanap: I would join #ubuntu-desktop if I were you :)
<cjwatson> This isn't my field, but I think "nautilus extensions" would probably be good search terms here
<tsimonq2> that too ^
<cjwatson> (and "apt search nautilus extension" shows several existing ones that you could perhaps use as example code - again, not my field so I don't know which ones are best)
<slavanap> tsimonq2, thanks for advice! :)
<slavanap> cjwatson, got it! Thanks!
<nacc> rbasak: took a while, but i think i've got the framework for upload/ tagging going now
<nacc> rbasak: although something i've got is provoking a pygit2 segfault :)
#ubuntu-devel 2016-10-13
<ginggs> would someone with universe upload rights and fast internet, please 'dget https://launchpad.net/~ginggs/+archive/ubuntu/testing/+files/nvidia-cuda-toolkit_8.0.44-0ubuntu1~ppa3.dsc' , remove '~ppa3' from the changelog and upload?
<ginggs> warning: 2.5GB of source tarballs
<ginggs> alternatively, is there a way that the orig*.tar.gz can be copied from my PPA into the archive?
<ginggs> nvm, i made a plan (nvidia-cuda-toolkit)
<pitti> Good morning
<doko> apw: fyi strace ftbfs on arm64 due to header changes in 3.8
<mwhudson> good morning pitti
<pitti> hey mwhudson, how are you?
<doko> chrisccoulson: new thunderbird crashed for me 4-5 times today, always when Shift-deleting emails / email threads
* infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> smoser: quick question for you, re: importer
<smoser> k
<nacc> smoser: we're considering moving the importer's actions (when using an existing repository or not) into a importer/ namespace -- so that i don't need to worry about branch collisions between the 'upstream' git tree and locally. I'm wondering if you think it's better to leave that remote configuration in the repository locally or if it's better to just delete it out of the repository configuration,
<nacc> since it's only valid to use with the importer itself
<smoser> i'm not sure i follow. 'remote configuration' and how would you colide with upstreams ? if someone did : git remote add upstream git-rul-here
<nacc> 'upstream' here being ~ubuntu-server-dev eventually
<nacc> currently ~usd-import-team
<nacc> 'importer upstream'
<nacc> aka usd-clone 'origin'
<nacc> you can ignore the details, i think
<nacc> smoser: just which, in your opinion is better, if you use usd-import on an existing directory -- i'm starting to think we don't want to 'leak' the importer's namespace
<smoser> oh. i see.
<smoser> if you ran import on an existing directory, it'd start tagging ubuntu/ stuff. and that could collide.
<nacc> smoser: that way the user can do whatever they want (or not) in that git tree, and the importer just reuse existing objects if possible
<nacc> smoser: yeah
<smoser> i think dont do that.
<nacc> smoser: yep, me too
<smoser> you could make itconfigurable
<nacc> yeah, true
<smoser> usd-import --prefix=importer/
<chiluk> cyphermox can you explain to me how we got so far diverged from debian initramfs-tools?
<chiluk> there are tons of changes?
<cyphermox> because we need ipv6 support in initramfs-tools.
<chiluk> cyphermox it seems to me that a lot of the changes seem like valid features that I'd expect debian to want.
 * cyphermox shrugs
<chiluk> cyphermox is debian not willing to accept ipv6  support?
<cyphermox> any other things predate me, I think
<chiluk> has anyone tried to push this back up there?
<cyphermox> I don't know
<slangasek> it's been several years since we've done any work on this
<chiluk> cyphermox ... recent changes not-withstanding.. not talking about all that..
<cyphermox> it's a complicated thing, and I haven 't exactly reviewed all of initramfs-tools aside from the little changes I made
<slangasek> it's a lot of work, given that Debian never integrated udev into their initramfs the way we did
<chiluk> slangasek how is it that you monitor all channels at all times?
<slangasek> magic
<slangasek> or technology?
<chiluk> do you have a highlight set for cyphermox or initramfs-tools?
<slangasek> chiluk: just happened to be in the right window at the right time
<chiluk> ok fine..
<cyphermox> hehe
<slangasek> and you can't prove otherwise
<cyphermox> chiluk: slangasek is watching to see where I screw up
<cyphermox> ;)
<tsimonq2> and I'm watching to see when you guys screw up so I can learn :P ;)
<tsimonq2> or when you guys succeed, either one ;)
<chiluk> don't give us so much hope tsimonq2
<cyphermox> chiluk: fwiw, I'm preparing a revert of all the recent changes in initramfs-tools for xenial
<cyphermox> and I'll get back to my dark little corner to 1) cry myself to sleep, and 2) fix it a different way that won't be as dangerous.
<chiluk> cyphermox: pulling ipv6 from xenial ip options?
<cyphermox> essentially, yes
<chiluk> I'd be ok with simply removing that one liner.  I like the rest of the changes.
<cyphermox> reverting what regresses.
<cyphermox> what one liner?
<chiluk> cyphermox: do you have a bug open about this?
<cyphermox> I'll be using bug 1631474
<chiluk> I feel a strange ownership in all this initramfs stuffs now.
<ubottu> bug 1631474 in initramfs-tools (Ubuntu Yakkety) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,Fix committed] https://launchpad.net/bugs/1631474
<cyphermox> chiluk: I'm not throwing it all out, we'll just integrate it slightly differently.
<chiluk> so you want to revert back to 8.2 essentially right?
<cyphermox> it's going to be a good opportunity to not have to deal with the cruft from ipconfig
<cyphermox> to 8.1
<cyphermox> 8.2 is where I started to put things in.
<chiluk> I'll review 8.1->8.4 but I think you fixed a lot of stuffs in that timeframe.
<chiluk> it would be nice if we actually suppored static assignment with ip= variable.
<chiluk> i'm pretty sure that still fails.
<chiluk> going forward that is.
<cyphermox> I think it would be a very misguided thing to use tbh
<cyphermox> so my personally opinion is that it needs to die in the flames of hell.
<cyphermox> (static assignment via ip= magic)
<chiluk> well I'm fairly certain it will fail unless it's going down some weird path I did not code inspect.
<cyphermox> it just calls ipconfig with the right parameters, and that is supposed to work.
<cyphermox> not that I tried it, but we haven't changed it -- setting ip=1.2.3.4:1.2.3.5:something:something:yadda:yadda would just do ipconfig -t $sometimeout  $IP
 * cyphermox realizes this is kind of hand-wavy
<cyphermox> not setting ip= at all (ie. you don't write anything) should do straight DHCP, via ipconfig, again as ipconfig -t timeout $device
<chiluk> cyphermox as with static assignment as it stands now it would call ipconfig -t ${ROUNDTTT} -d $IP    which should fail since -d would have the full $IP and not simply the interface
<chiluk> cyphermox: oh nm.. I see that ipconfig understand the IP=:::: awesome-sauce
<cyphermox> device being whatever BOOTIF= set, or "" in which case ipconfig will try the bring up all devices (using logic in C similar to what I did in all_netbootable_devices()
<cyphermox> chiluk: yes
<cyphermox> AFAIK none of that ip= stuff is touched by the kernel at all, it's only meant for ipconfig
<chiluk> yeah anyhow I really think this all needs to be re-engineered.
<chiluk> preferably with some test-cases set up.
#ubuntu-devel 2016-10-14
<nacc> rbasak: if you get a chance take a look at the latest commits on lpusip:memcached#ubuntu/yakkety,{-proposed}
<nacc> rbasak: those are achieved with the importer/ namespace implemented and with upload/ tag support (so in this case, I had the upload/ tag in my local repository that i then used as the basis for import)
<halvors1> Hi. There is core dumps in systemd for last patch for systemd in xenial as well as yakkety.
<halvors1> What happend here? Everything worked just fine before the "security update" and the last "change" in yakkety way after the freeze zone...
<sarnold> halvors1: what bug number?
<halvors1> sarnold: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1633274
<ubottu> Launchpad bug 1633274 in systemd (Ubuntu) "Systemd-networkd crashes with core dump" [Undecided,New]
<sarnold> halvors1: very nice, thanks
<halvors> I don't know exactly how yakkety is affected as well, the bug seems to be appearing only when i attach the VTI interface to a physical interface.
<Bluefoxicy> I can't find the bug for "flash is completely broken in 16.10"
<pitti> Good morning
 * Mirv frequently refreshes https://launchpad.net/ubuntu/+series
 * acheronuk prays for a slight break with the animal theme (zombie)
<rbasak> nacc: nice!
<rbasak> Interesting that the commit date appears to go backwards.
<rbasak> (in ubuntu/yakkety)
<rbasak> I guess that's just a consequence of the test using historical data in this case.
<tsimonq2> cyphermox: Hello, what should I reply with here? https://www.reddit.com/r/Lubuntu/comments/57eg8q/vpn_icon_in_applet_tray/
<tsimonq2> cyphermox: Afair, that's your specialty ;)
<brendand> tsimonq2, ask them to post 'nmcli conn'
<tsimonq2> brendand: ok
<pitti> smoser: I revisited bug 1629797 and now sent a D-Bus patch upstream which solves this in a more intrusive, but also much more elegant way, FYI
<ubottu> bug 1629797 in dbus (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,Triaged] https://launchpad.net/bugs/1629797
<pitti> smoser: so I'll see to getting this into z and Debian unstable soon, and at some point we can backport it to x and lose that workaround in cloud-init.service
<rbasak> pitti: do you have a link to the upstream patch please? I'm curious.
<vip> hello
<pitti> rbasak: I linked it from the bug, freedesktop bug 98254
<ubottu> Freedesktop bug 98254 in core "Deadlock/timeout if early boot services try to connect to D-Bus" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=98254
<rbasak> Thanks!
<smoser> pitti, link to upstream in the bug ?
<pitti> smoser: I did
<coreycb> pitti, hello, bug 1623107 is ready for another look if you have a chance
<ubottu> bug 1623107 in python-pylxd (Ubuntu Xenial) "[SRU] python-pylxd 2.0.5" [Undecided,In progress] https://launchpad.net/bugs/1623107
<pitti> coreycb: http://launchpadlibrarian.net/289337158/python-mock-services_0.2-0ubuntu3_0.2-0ubuntu0.16.04.1.diff.gz looks a bit strange -- why did you remove the changelog?
<pitti> coreycb: this is a build dep only, right? so it'll go into universe
<coreycb> pitti, hmm, confused.. I didn't think python-mock-services existed in xenial
<coreycb> pitti, it is a build dep only, yes.  I adjusted the changelog from yakkety so that the version is < yakkety
<pitti> coreycb: I mean normally you'd take the y package, add a new changelog record for 0.2-0ubuntu3~16.04 (or ~xenial) and keep the rest
<pitti> coreycb: but, nitpicking
<coreycb> pitti, yeah I should have done that
<pitti> coreycb: accepted; I'll let it build and binNEW it after that, then pylxd should start building
<coreycb> pitti, thanks
<coreycb> infinity, RAOF:  hello, any chance one of you could put xenial nova and neutron* in your sru review list for next week?
<pitti> coreycb: â¦done
<coreycb> pitti, thanks again
<smoser> is there some tool that i can point at a changelog and it will download me the right orig tarball from launchpad ?
<smoser> i'm aware of pull-lp-source, but basically want to run 'get-orig-source' in some directory, have it read the debian/changelog, and downlaod the .orig.tar.gz (or .tar.xz)
<smoser> probably of the last non-UNRELEASED version
<pitti> no, I don't think there's something that general
<pitti> well, uscan --download-current-version --rename
<pitti> that shold actually do what you want
<cjwatson> only if it actually matches upstream
<cjwatson> I'd be inclined to build something out of dpkg-parsechangelog + dget
<nacc> smoser: to make it easier to build with teh importer, right?
<smoser> yeah.
<smoser> i just git clone, but then build says E_NO_ORIG_TARBALL
<cjwatson> I always preferred the pristine-tar approach to this personally, although I've sensed that falling out of favour a bit
<nacc> rbasak: yeah, i think that's an artifact of my local git-dsc-commit reconstruct having been done a few days ago, and the publish actually haveing occurred a week ago
<cjwatson> and it does require tool support
<nacc> cjwatson: right, that's what i was considering adding, although it will slow down our importer more
<cjwatson> (all my git-dpm-managed packages have a pristine-tar branch that stores deltas versus commits on the upstream branch)
<nacc> smoser: but agreed, it's a needed functionallity
<smoser> i'm working on one.
<rbasak> I imagined a tool that would use a cache somewhere in .git, and populate that if required, only on user demand.
<nacc> rbasak: ack, i'm just worried about how large that cache might get, and it's a bit of complication to the 'importer' code proper -- i guess it could live in a different tool, though
<barry> smoser: http://paste.ubuntu.com/23323900/
<rbasak> Different tool is what I had in mind. Though if somehow the same cache could be used for both, that would be nice.
<barry> that's what i've been using for a while now.  requires chdist.  not sure it's what you want, but you can easily run `gbp build-package` over the result
<smoser> barry, thanks.
<nacc> rbasak: ack, agreed
<nacc> rbasak: at the minimum, i think the importer can stash the 'last' imported debian and ubuntu orig tarballs in there
<nacc> rbasak: as those seem the 'most' valuable for the development side
<rbasak> Yeah, but in smoser's clone use case, his cache would start off empty.
<nacc> ack, we'd need to have a separate tool still, no matter what i tihnk
<nacc> which is good, as 'building' is different from 'importing' :)
<nacc> smoser: in your c#3 to LP: #1633114, doesn't that leave the trailing maintainer entry
<ubottu> Launchpad bug 1633114 in usd-importer "provide debian/changelog information in commit messages" [Medium,Triaged] https://launchpad.net/bugs/1633114
<rbasak> Perhaps even a tool that shares its cache with pull-lp-source?
<rbasak> Using ~/.cache (XDG-ized) etc perhaps.
<rbasak> But YAGNI, perhaps.
<smoser> cjwatson, dget would require deb-src lines, right ? nacc that was by design
<smoser> shoot
<smoser> sorry, cjwatson . that was just in by buffer
<cjwatson> er possibly, yeah
<smoser> nacc, that was by design, as it is in the commit Author
<smoser> right?
<nacc> smoser: i agree, but it *does* leave the line in my case -- but in your comment
<nacc> *but not
<nacc> http://paste.ubuntu.com/23324002/
<nacc> git diff import/1.4.1-1^..import/1.4.1-1 -- debian/changelog | sed -e '/^[+]/!d' -e 's/^[+]//' -e '/^ /!d'
<smoser> alright...
<smoser> so
<smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp_4.3.3-5ubuntu14.dsc
<smoser> dget https://launchpad.net/ubuntu/+archive/primary/+files/isc-dhcp_4.3.3-5ubuntu14.dsc
<smoser> always fails for me, and i have to pass '-u'
<smoser> what is the right way to m ake it pass ?
<bdmurray> happyaron: Are you about? Your fcitx upload has no Launchpad-Bugs-Fixed in it.
<smoser> nacc, did you figure it out ? i probably changed something and didn't update what i put inthe comment
<nacc> smoser: no, i just wanted to make sure i wasn't missing something obvious, i can tweak the regexs
<nacc> smoser: for dget, wouldn't it need to know the public key for whoever uploaded that version? is that what is' verifying?
<nacc> *it's
<cjwatson> smoser: there isn't necessarily a good reason to expect that you'll have the necessary public key, for Ubuntu.  For Debian, where that tool was written, they're generally in the debian-keyring package.
<cjwatson> smoser: transport security is probably OK in this case ...
<smoser> cjwatson, yeah. thats what i was thinking. i justdidn't know if in general i was missing some obvious thing.
<rbasak> nacc: do you have SRU information for bug 1629241 please?
<ubottu> bug 1629241 in strongswan (Ubuntu Trusty) "crash strongSwan in Ubuntu Trusty" [High,In progress] https://launchpad.net/bugs/1629241
<nacc> rbasak: let me fill it out
<smoser> https://gist.github.com/smoser/fa77f61a2b650d115b5fc2a8ab028ede
<smoser> nacc, cjwatson that is probalby over-engineered in many ways, but works for me.
<smoser> bad thing is that it downloads more than just the dsc and the orig tarball (gets the debian tarball too)
<rbasak> nacc, caribou: you have both uploaded an SRU for multipath-tools in Trusty for different bugs. Could you coordinate and consolidate these into one upload, please?
<rbasak> So I propose to reject both from the queue unless you object?
<caribou> rbasak: I'm fine with it, I'll ping nacc to coordinate
<nacc> rbasak: fine with me, sorry about that!
<nacc> rbasak: LP: #1629241 updated; however, I'm not sure the test case is sufficient
<ubottu> Launchpad bug 1629241 in strongswan (Ubuntu Trusty) "crash strongSwan in Ubuntu Trusty" [High,In progress] https://launchpad.net/bugs/1629241
<rbasak> nacc: will you be able to exercise that test case if required? If not, I suggest asking the reporter to commit to doing the SRU verification - otherwise we sometimes end up stuck blocking other SRUs and have to reject it in the end.
<rbasak> bdmurray: any opinion?
<bdmurray> rbasak: The reporter verified from a PPA so I think they are willing
<caribou> nacc: I just pulled your source, want me to merge it with mine (got two patches)
<rbasak> caribou, nacc: sounds like you could have fun with the git workflow there :-)
<caribou> rbasak: nacc: this is something that came up within our team : how do we handle post-merge uploads to dev
<nacc> rbasak: bdmurray: yeah, they already were very prompt in our testing
<nacc> *prior testing
<rbasak> bdmurray: OK, so shall we accept that one?
<nacc> caribou: fine with me, thanks!
<caribou> rbasak: nacc: do we keep using the git repo or just debdiffs
<nacc> caribou: yeah, that's on my todo list for today (hopefully)
<nacc> caribou: using the git workflow for bugfixes
<caribou> nacc: ok, will merge both & post the debdiff in a few minutes
<nacc> caribou: debdiffs will also still be supported and handled, but if one knows to use the git repo (and hopefully that population grows), then MRs can be used, etc.
<caribou> nacc: here is the debdiff : http://paste.ubuntu.com/23324297/
<nacc> caribou: looks good to me!
<caribou> nacc: ok, uploading
<caribou> rbasak: nacc: ok, merged multipath-tools trusty SRU uploaded
<rbasak> Thanks!
<nacc> apw: query on the overlay stuff in y -- given that overlayfs is no longer recognized, should there be something that goes into /etc/schroot/chroot.d/ and post-install of an appropriate kernel ensures that it says overlay for each schroot? I guess that could be a sbuild change. Wasn't sure if there was already a bug for this
<nacc> apw: i'll re-ask that in #ubuntu-kernel
<nacc> smoser: if we import a version and it's a copy-forward from another release, do you want the most recent chagnelog entry to be present still?
<rbasak> nacc: could you add SRU paperwork to bug 1628723 please?
<ubottu> bug 1628723 in multipath-tools (Ubuntu Trusty) "Trusty: multipathd SIGSEGV on path addition or removal" [High,In progress] https://launchpad.net/bugs/1628723
<rbasak> caribou: looks like someone messed with the bug status in bug 1621835, but it should have been Fix Released in the development release if it already has the fix.
<ubottu> bug 1621835 in multipath-tools (Ubuntu Trusty) "multipathd reconfigure does not update /etc/multipath/wwids file on trusty" [Medium,In progress] https://launchpad.net/bugs/1621835
<nacc> rbasak: done, similar statement regarding testing as the strongswan one (they already tested via PPA)
<rbasak> OK, thanks.
<smoser> nacc, i guess all the interim, wouldnt you think ?
<nacc> smoser: what do you mean by interim? e.g., 1.4.25-2ubuntu1 published in x, then copied to y, what do you think should be in y's importer commit message
<nacc> keeping in mind that x's commit message may also be affected by your choice (because it was copied from x-proposed)
<smoser> hm..
<smoser> i dont know.
<nacc> smoser: yeah it's tricky, if we say it's the most recent changelog entry (whcih corresponds to the version in that import), then i have to probably use dpkg-parsechangelog or similar manual munging (btw, i'm basically taking the middle route on that issue, after talking with rbasak, i'll add some manual fallback in the code if dpkg-parsechagnelog fails, so hoepfully we won't need source patches anymore
<nacc> (but we'll still keep that support around))
<nacc> smoser: if we say it's the diff, it might be empty often
<smoser> when would it be empty ?
<smoser> only rally on "first copy to branch"
<nacc> and every series starts with that :)
<nacc> and some series get no updates
<nacc> so it depends on 'often'
<nacc> i'm fine either way, just trying to match what you expect
<nacc> diff is probably easier for me to code, tbh
<nacc> smoser: let me generate an example tree and we can use that as the basis for discussion
<smoser> nacc, another possibity is to just push this to a tool
<smoser> that looks at git log debian/changelog
<nacc> smoser: sorry, i'm a bit confused; i thought the point was you wanted to see the corresponding changelog entry in the `git log` ?
<smoser> right. i did.
<smoser> and i do think that woudl be useful.
<smoser> but if you can't figure out the right way to do it, i thin it may be sufficient to say "thats a user problem"
<nacc> smoser: ah ok :)
<nacc> smoser: i think i can get us something that is useful, and i agree in principe that our current `git log` output is not the most helpful
<smoser> so lets say i had a fix for a bug (bug 1629972)
<ubottu> bug 1629972 in MAAS "networking stop incorrectly disconnects from (network) root filesystem" [Undecided,Triaged] https://launchpad.net/bugs/1629972
<smoser> where would i upload that ?
<smoser> shall ijust upload it to yakkety-proposed ?
<nacc> smoser: iiuc, based upon prior discussions, you can just upload to ubuntu and it will dtrt?
<nacc> smoser: ah but you mean because z isn't open yet?
<smoser> right
<nacc> good question :)
<slangasek> smoser: yes, yakkety-proposed for now.  I guess this is an SRU candidate regardless, right?
<smoser> slangasek, yes.
<slangasek> then definitely yes :)
<nacc> slangasek: process-wise, given that the 'development release' should always have the fix first, how is the devel release defined right now?
<nacc> *for an SRU, I mean
<nacc> smoser: any idea why the single-quote escape isn't working? http://paste.ubuntu.com/23324761/
<smoser> to escape single ticks you need '\''
<smoser> but probably best to avoid the shell interpretation
<smoser> unless you're just asking about you typing things.
<smoser> or if you prefer, "" can do same as \ there: echo 'you can'"'"'t do that.'
<nacc> smoser: well, i mean if i do git commit -m '<result of git-diff>' and git-diff contains '
<nacc> smoser: it doesn't go so hot :/
<smoser> but why are you passing that to the shell
<nacc> smoser: sorry, not sure i understnd? we use subprocess.call(shell=True) throughout th eimporter
<smoser> yeah, thats wrong.
<smoser> almsot always
<nacc> smoser: i could switch those around, but i ran into plenty of other issues
<smoser> almost always better to not have the shell involved.
<nacc> smoser: ok, so not using the shell, i probably need to pass absolute paths to everything?
<nacc> smoser: as just switching shell=True off broke just about every subprocess call :)
<smoser> yeah, because you invoke with "git log" rather than ["git", "log"]
<nacc> smoser: ah ok
 * nacc switches over to shlex.split
<smoser> nah.
<smoser> just drop the shell
<smoser> i promise, it will only get in the way.
<nacc> dropping the shell requires me to switch everything to []
<nacc> which i just did by using shlex.split
<nacc> the only ones that still use shell are those using pipes
<nacc> i will change those over later
<nacc> lol, shlex.split also has an issue with nested '
<smoser> nacc, http://paste.ubuntu.com/23324843/
<smoser> that handles ithink all but the pipes
<smoser> ican fix those too
<nacc> smoser: right, that is what shlex.split() is supposed to be doing :)
<nacc> let's just say it doesn't work so hot :)
<nacc> ok i'll do the same locally
<smoser> well, no.
<smoser> it is actually doing the righ tthing
<smoser> its splitting as the shell would split
<smoser> which is why you have bug for bug compatibility
<nacc> even if i use shlex.quote first, it bugs out
<nacc> it's fine
<nacc> i'm changing to your format
<slangasek> nacc: we batch-copy packages forward from yakkety-proposed to z-proposed once it opens
<smoser> bah
<smoser> slangasek, i remember at soem point in the long past making changes to dhclient so that if it failed to get a lease it would die
<tsimonq2> smoser: bah
<smoser> and exit failure
<smoser> but it seems it does nto do that now
<smoser> dhclient -v -4 ... echo $?; seems to say 0
<smoser> http://paste.ubuntu.com/23325534/
<slangasek> smoser: did you forget the -1 option?
<slangasek> not according to your pastebin
<smoser> no. i typo'd -4 for -1 above
<slangasek> ok
<smoser> do you remember doing this too ? or did i make it up.
<smoser> the man page seems to say it will act like i expect
<slangasek> smoser: dhclient was always supposed to work that way on -1, we changed other things to make use of that behavior
<slangasek> smoser: so clearly that's misbehaving per manpage; file a bug with deets?
<smoser> deets ?
<slangasek> details ;)
<nacc> heh
<smoser> people commonly over-guess on my hipness factor.
<smoser> thats either because a.) i just look hip
<smoser> b.) i'm more lame than people expect is possible.
<slangasek> you've apparently ruled out c) slangasek uses dated slang to keep people guessing if he's retro or just old
<nacc> all of the above?
<dobey> when people say "deets" it makes me think of https://en.wikipedia.org/wiki/DEET
<smoser> https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1633619
<ubottu> Launchpad bug 1633619 in isc-dhcp (Ubuntu) "dhclient -1 exits 0 when no lease found" [Undecided,New]
<srwarren> Does anyone know how/why/when /etc/default/locale is created when running the Ubuntu installer?
<srwarren> Related, if a system is being installed a different way, e.g. by untaring a root file system .tar file supplied by Canonical, what's the suggested way of creating config files like that; just untar another overlay .tar with manually created file content, do something at first-boot, or ?
<nacc> smoser: if you're around: https://git.launchpad.net/~nacc/ubuntu/+source/memcached
<nacc> smoser: that has changelog entries
#ubuntu-devel 2016-10-15
<lamont> why did firefox quit giving me completions?
<tsimonq2> lamont: could you please be more specific?
<sarnold> lamont: tyhicks saw that too, two days ago, I don't think he figured out any correlations. chrisccoulson suggested focussing another window; I think I heard restarting firefox fixed it.
<happyaron> bdmurray: ah sorry again, will re-upload with ubuntu tools..
<hjd> Has there been any announcement on when the z-archive will open?
<Unit193> Likely after it gets a name..
<hjd> Ah :) Makes sense.
#ubuntu-devel 2016-10-16
<adgellida> hi. I have qt c++ code, I need to upload to launchpad, github and uappexplorer. Any help please?
<adgellida> I have launchpad and github repo
<adgellida> bye!
<maxagaz> hi
<maxagaz> libpng12 is not anymore in yakkety, but we still need it for applications like wps office
<maxagaz> it's now been replaced by libpng16
<maxagaz> can we have both ?
#ubuntu-devel 2017-10-09
<xorpad> yeah... I want to know what happened to the ubuntu touch recovery
<xorpad> You based it on the worst known recovery and removed all the features, when you click backup/restore it's jokes that it tricked you and it's mot going to do a backup
<xorpad> this is horrible, whoever is responsible needs to be talked to very sternly
<xorpad> It's disgusting how cirppled and unusable the system went between vivid and xenial
<xorpad> Now I have to write something useful and relevant to the ubuntu touch community before we can even think about pushing people to xenial, yeah that's right people are still using vivid because you keep putting out images and source but you don't seem to care about the quality of it
<xorpad> your system partition binaries have dead symlinks in them, including mount, making it impossible to boot the system because you can't mount the partitions
<xorpad> worst project management I've seen in a reputable organization like this
<xorpad> it's something I would expect from some fork of a fork of mint
<dobey> why are you here complaining about a dead product?
<xorpad> dobey, because they messed with what i was working on
<dobey> and i have no idea what you're even talking about
<xorpad> then ask questions that will have a meaningful answer
<xorpad> lots of people can't afford nice new phones, they deserve support
<dobey> that seems to be some advice you should perhaps follow
<dobey> how is going on some tirade about a recovery image and vivid going to solve your problem, if you even actually have one?
<xorpad> you ask me why i'm complaining about you turning a perfectly working product into one that doesn't work, and has a total lack of functionality
<xorpad> My problem is that I need to make a recovery that does things aside from looking like unity
<dobey> i still have no idea what you're talking about, or why you're saying "you" or why you're doing so in this channel
<xorpad> You being the ubuntu devs
<xorpad> if you're not one of them, than you have nothing to worry about, but this is pure idiocy, and whoever made the decision needs to know they messed up
<xorpad> a lot of people depend on free opensource software and a lot of us put our faith in ubuntu
<dobey> you are being rude
<xorpad> well, whoever made this decision messed up and I wanted them to know it
<xorpad> that's all
<Son_Goku> xorpad, but wasn't all the ubuntu touch stuff forked by the ubports
<Son_Goku> ?
<xorpad> Ubuntu keeps making snapshots and new versions, so not completely
<blahdeblah> That's just an automated process
<dobey> it sounds like xorpad wants to change the recovery to something other than the ubuntu recovery for some reason, and expects it to behave like it would on an android phone, even though it's not android
<blahdeblah> Canonical doesn't support Ubuntu touch any more
<xorpad> blahdeblah, yeah that's pretty clear from the lack of caring about the builds
<dobey> i'm surprised that stuff is still running, really
<Son_Goku> I am too
<Son_Goku> I thought all that stuff was shut off back in June?
<blahdeblah> Drop us a ticket at rt@ubuntu.com and we can probably make it stop. :-)
<dobey> even when the phone was supported, some of the channels were automated builds for build testing only, and not to be used on real devices generally
<xorpad> Okay, whatever... i just won't put any faith in ubuntu anymore
<dobey> but then, there seems to be quite a few automated things that were set up for phone/unity stuff, still running, that i would expect to be dead now as well
<Son_Goku> welp
<xorpad> whatever, whoever is making these, tell them I was here
<xorpad> and what I said
<xorpad> because decisions like this shouldn't even be considered by someone on a project like Ubuntu
<blahdeblah> It's a build server, and I can say on its behalf that it doesn't care about you or me or anything. :-)
<dobey> i still don't know what you were actually trying to say
<xorpad> that the code was great and now it's not functional in so many ways
<dobey> nobody has any idea what "decision" you're takling about
<dobey> you've been very vague
<xorpad> the decision to replace part of the firmware that was purpose built and useful it's something that pretty much does nothing
<Son_Goku> xorpad, I can pretty much guarantee that it was bitrot that did that
<dobey> still lost
<Son_Goku> most of the folks (if not all of them) who worked on the Touch project were laid off
<Son_Goku> dobey: the initialization and system recovery code broke in the automated builds
<Son_Goku> basically, bitrot for the Ubuntu Touch firmware images
<xorpad> it didn't break, it was replaced by useless code
<Son_Goku> ... hence, broken?
<xorpad> no it does exactly what it is programmed to do
<xorpad> it's very obvious it was done on purpose
<xorpad> this wasn't a bug in an automated system
<xorpad> it was someone telling ubuntu phone and devs that ubuntu doesn't care about their own stuff
<dobey> still no idea what you're talking about
<xorpad> well, then you're not the person i should be talking to and you can ignore me
<xorpad> I've said what I had to say, I'm done, if you don't get it, fine
<dobey> there is absolutely nobody you should be talking to, because there is nobody to talk to
<dobey> none of that changes the fact that ubuntu is still not android
<xorpad> Someone programmed the replacement that doesn't do anything other than joke about how it doesn't work
<xorpad> and I'm not running android
<xorpad> I'm running ubuntu
<xorpad> Simply with a kernel module to handle android drivers so it can run on android devices
<dobey> the same recovery image was used on ubuntu phones for roughly 3 years
<xorpad> And then it was replaced with one that has zero functionality
<dobey> "and then" ?
<dobey> ubuntu phone has been a dead project for 6 months
<dobey> i am pretty certain nobody replaced the recovery image in that time
<xorpad> well, the official site is still providing snapshots
<xorpad> so someones still working on it
<dobey> nope
<dobey> the only people working on ubuntu phone images, are ubport
<dobey> ubports
<xorpad> No, so people who aren't affiliated with ubuntu can post images and snapshots and products on ubuntu.com?
<dobey> no
<dobey> as was previously stated, some automated thing is apparently still running if daily images are being built there
<xorpad> then you're not telling the truth, or your not aware of it
<xorpad> this was not an automated thing
<xorpad> It was a complete replacement of a product wiht one that literally tells jokes about how it doesn't work
<dobey> i seriously doubt that
<xorpad> well, that
<xorpad> is why i'm here complaining
<xorpad> because someone did it
<xorpad> if it wasn't supposed to happen cannonical should track down who's messing with stuff that goes up on their official ubuntu site
<dobey> and what image in what channel are you even talking about?
<dobey> can you perhaps NOT be vague in a single accusation you're going to throw out?
<xorpad> no, i'm done with people who have no idea what's going on
<xorpad> as you clearly don't
<LargePrime> lol
<LargePrime> i see you trolling
<dobey> wtf
<LargePrime> <xorpad> this is horrible, whoever is responsible needs to be talked to very sternly
<LargePrime> highlarious
<Son_Goku> I doubt anyone knows anything about ubutouch anymore
<Son_Goku> at least anyone working at Canonical
<dobey> uhm
<dobey> even so
<dobey> even the last "devel-proposed" image for mako on system-image.u.c is a year old
<dobey> and well, for all the other devices too
<dobey> so sounds like someone broke their own junk and then is looking to blame someone else
<dobey> and last "stable" channel release was feb 2017
<dobey> and staging was apparently april 22
<dobey> wahtever
<dobey> so weird
<tjaalton> doko: hi, next hwe stack update to xenial needs a fix to binutils so llvm-5.0 doesn't ftbfs on arm64
<tjaalton> I'll file a bug
<ricotz> tjaalton, doko, hi, you can find built packages at https://launchpad.net/~ricotz/+archive/ubuntu/mozilla/+packages
<tjaalton> probably doesn't fix powerpc ftbfs?
<ricotz> I can't test those
<ricotz> same for s390x
<tjaalton> I'll push this binutils to x-staging
<ricotz> could you do trusty and zesty as well which will be needed too
<tjaalton> I don't need trusty
<ricotz> firefox does
<tjaalton> and don't care much about zesty at this point :)
<ricotz> don't be narrow minded here, those backports are not only for X ;)
<tjaalton> x-staging is
<ricotz> right, but this whole backport-request isn't
<tjaalton> my tracker bug is #1716203
<tjaalton> do you have another?
<ricotz> another bug report, no
<tjaalton> ok
<tjaalton> i'll ask for a s390x builder
<cjwatson> jbicha: stuck cron job following last weekend's network event; fixed, thanks
<seb128> hum, would be nice if somebody was reviewing the artful queue, things have been sitting there since friday mostly :-/
<xnox> Laney, sil2100, slangasek - https://bileto.ubuntu.com/#/ticket/2981 does not have autopkgtest results, how do I request them to be triggered? (i mean all the reverse-depends....)
<xnox> i expected for them to be available by now
<slangasek> xnox: they should have been available nearly immediately; I'm not sure what happened there and don't have time to dig today, unfortunately
<sil2100> xnox: I need to look into that later on, it's not the first time this happens - I'll try finding some time later today
<Laney> xnox: I don't know how that triggering stuff works, think that my results didn't come back last time
<tkamppeter> xnox, have you seen bug 1721839
<ubottu> bug 1721839 in systemd (Ubuntu) "Services asked for by UDEV do not get triggered" [Critical,New] https://launchpad.net/bugs/1721839
<rbasak> niedbalski: around?
<tkamppeter> Anyone here who can help on a systemd issue? Bug 1721839
<ubottu> bug 1721839 in systemd (Ubuntu) "Services asked for by UDEV do not get triggered" [Critical,New] https://launchpad.net/bugs/1721839
<xnox> tkamppeter, so if the SYSTEMD_WANTS is correct in udevadm info output, it means you got the udev rules correct.
<xnox> tkamppeter, next you need to figure out the .device unit name in systemd which matches that particular udev device and get the status of it
<xnox> tkamppeter, it maybe that the .device, from systemd point of view, is not "started" and therefore said .device units' .wants are not started
<xnox> tkamppeter, you can use something like $ systemctl list-units '*.device' | grep pci
<xnox> to find your printer, and check the state of that unit. is it active & plugged?
<xnox> possibly a device unit is configured for one of the other udevadm entries, the one that was not tagged systemd?
<tkamppeter> xnox, the printer was plugged and turned on at that time, as it appeared in the udevadm output.
<tkamppeter> xnox, I can also start the service manually with "sudo systemctl start XXX.service".
<xnox> tkamppeter, i am not asking about the physical real world state.
<xnox> tkamppeter, i don't want you to start services by hand
<xnox> tkamppeter, i want to see the status of the systemd .device unit corresponding to the udevadm device
<xnox> the two are separate
<tkamppeter> xnox, starting services by hand was only a test to find out in which stage it fails.
<xnox> and confusingly the systemd .device unit state can be "unplugged offline" or "plugged online" and that matters whether wanted corresponding .service files are started or not
<xnox> tkamppeter, what is the output and states of all of your systemd .device units?
<xnox> $ systemctl list-units '*.device' | pastebinit
<tkamppeter> xnox, "systemctl list-units" has in its output:
<tkamppeter> â udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2x2d2.service                 loaded failed failed    Automatic USB/Bluetooth printer setup (-devices-pci0000:00-0000:00:14.0-usb2-2x2d2)
<tkamppeter> xnox, http://paste.ubuntu.com/25707724/
<xnox> cool (that output got trimmed, but it looks ok)
<xnox> tkamppeter, now you need to figure out why that service failed, as it seems like it was attempted to be started (impossible to know now if automatic, or by you manually, as one needs to reset-failed to get back to clean state after the printer is unplugged)
<xnox> tkamppeter, what is $ systemctl status udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2x2d2.service ?
<xnox> or e.g. journalctl -u udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2x2d2.service
<xnox> tkamppeter, note that the stuff after @ seems like an incomplete device unit, eg. it doesn't start with sys- (not sure if you need that or not)
<xnox> and do note there are %i and %I substitution variables available which can pass the instance name verbantim or systemd-UN-escaped
<tkamppeter> xnox, What I did today is only plugging and turning on the printer, I did not try to start the service manually. On the other day when I started it manually it was correctly working after the manual start.
<tkamppeter> The udev-configure-printer UDEV rules file and systemd .service files are the same as in 17.04 and there they worked.
<tkamppeter> xnox ^^
<tkamppeter> xnox, so does %i mean verbatim and %I systemmd-UN-escaped? Or vice-versa?
<tkamppeter> xnox, here is a complete list-units paste: http://paste.ubuntu.com/25707920/
<tkamppeter> xnox, the problem is that automatic start does not work whereas manual start works.
<tkamppeter> All data which I pasted for you today is without doing any manual start attempt.
<tkamppeter> xnox, systemctl status udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2x2d2.service --> http://paste.ubuntu.com/25707960/
<tkamppeter> xnox, journalctl -u udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2x2d2.service --> http://paste.ubuntu.com/25707972/
<xnox> Laney, is there some manual way to run britney? for it to list what tests/packages it would test if it were asked to migrate libseccomp?
<xnox> such that I would be able to run those tests manually
<xnox> i guess i can by-hand look at the reverse-deps
<tkamppeter> xnox, did you get my pastes?
<xnox> tkamppeter, yes, and then you dropped out of irc.
<tkamppeter> OK, I am back now.
<xnox> tkamppeter, it looks like the .service unit was started, did run, and did try to accells /sys/devices....
<xnox> tkamppeter, but that - for whatever reason - has failed.
<xnox> maybe the printer/device was not yet "ready enough|
<xnox> maybe the printer/device was not yet "ready enough"
<xnox> thus you need to somehow debug that unit, to see why it is failing when systemd starts it, at the time it does.
<Laney> xnox: not that I know of
<tkamppeter> xnox, I have found the cause of the problem now: The directory which needs to get accessed by udev-configure-printer is: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-2, note that the second last character is a dash. UDEV/systemd(?) inserts for the %i in the second line of the udev-configure-printer@.service file: -devices-pci0000:00-0000:00:14.0-usb2-2x2d2, replacing each slash by a dash and the original dash by "x2d" (should it not be "\x2d"? Not su
<tkamppeter> re what gets inserted for the %I in the ExecStart line, but udev-configure-printer ends up with a /sys/devices/pci0000:00/0000:00:14.0/usb2/2x2d2 which it does not find as the "x2d" is not turned back into a dash.
<xnox> tkamppeter, sigh
<xnox> let me see if there is an option to unbreak that
<tkamppeter> xnox, so the problem is the escaping, either UDEV or systemd do it wrong and it is a regression as in 17.04 it worked.
<xnox> tkamppeter, it might be a bug-fix actually
<tkamppeter> xnox, this will probably break all UDEV/systemd interaction with all USB devices, probably even with all PCI hardware.
<Laney> xnox: reverse deps and reverse testsuite-triggers
<Laney> and the package itself
<xnox> tkamppeter, i believe when systemd-escape is called it should be called with "-p --template=...." options
<xnox> tkamppeter, '-p' makes the mangling to be path like, but let me test things here.
<xnox> tkamppeter, can you paste me the udev-configure-printer@.service unit?
<tkamppeter> xnox, here we go: http://paste.ubuntu.com/25708406/
<xnox> tkamppeter, that unit file is invalid
<xnox> tkamppeter, it is not a shell
<xnox> tkamppeter, you cannot execute multiple commands with ';' or use shell builtins
<tkamppeter> Here is the UDEV rules file /lib/udev/rules.d/70-printers.rules: http://paste.ubuntu.com/25708425/
<xnox> tkamppeter, why do you have sleep 1 there? why is not a separate line?
<xnox> tkamppeter, you really should not have arbitrary sleeps =/
<xnox> but that's besides the point
<tkamppeter> xnox, this was to try out whether it was really due to the printer not ready.
<tkamppeter> xnox, the original does not have the sleep 1
<xnox> tkamppeter, note that in systemd ExecStart is not executed by shell, but by direct exec
<xnox> you should have had something like
<xnox> ExecStart=/bin/sleep 1
<xnox> ExecStart=/lib/udev/udev-configure-pirnter add %I
<xnox> but that's for future reference
<xnox> maybe even ExecStartPre=/bin/sleep 1
<tkamppeter> xnox, here is the original .service file: http://paste.ubuntu.com/25708443/
<tkamppeter> xnox, this is the one with which I observed the escaping problem.
<tkamppeter> \xnox, and as we have observed the escaping problem now, we have a possible cause, the thing of printer-not-ready was an assumption before discovering the escaping problem.
<tkamppeter> xnox ^^
<xnox> tkamppeter, yeah sure.
<tkamppeter_>  xnox, if I run the systemd-escape commad on the command line by hand, the x2d replacing the dash at the end of the path is actually a \x2d, but it seems that in the further processing the \ gets lost and the unescaping breaks
<xnox> tkamppeter_, i'm struggling to create a full dance of udev rule et.al.
<xnox> tkamppeter_, could you please try changing the udev rule to call `systemd-escape -p --template=udev-configure-printer@.service %p` ?
<xnox> tkamppeter, also i wonder if we need to quote the SYSTEMD_WANTS="'%c'" rather than just ="%c"
<xnox> but it does smell like a regression
<tkamppeter> xnox, adding -p I already tried without success.
<xnox> tkamppeter, sigh
<tkamppeter> xnox, am I right that after changing a UDEV rule file it is enough to get the change being used if I run "sudo systemctl restart udev"?
<xnox> no
<xnox> tkamppeter, $ udevadm control --reload
<xnox> and one needs to reset the failed unit state as well
<xnox> and then unplug/replug printer
<tkamppeter> How do I reset the failed unit state?
<tkamppeter> xnox ^^
<xnox> tkamppeter, read manpages?! =) $ systemctl reset-failed myunit.service
<xnox> https://www.freedesktop.org/software/systemd/man/systemctl.html#reset-failed%20%5BPATTERN%E2%80%A6%5D
<tkamppeter> xnox, tried the reset-failed, tried to restart udev and systemd and nothing happens, no new entry in journalctl -u, last entry is from an hour ago:
<tkamppeter> Oct 09 13:12:10 till-x1carbon systemd[1]: udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2x2d2.service: Unit configuration has fatal error, unit will not be started.
<xnox> that is odd, unplugging printer, reseting the unit, plugging printer in, should trigger the unit again
<xnox> "fatal error" is that unit still with bad =sleep 1?
<tkamppeter> I have removed the sleep 1 and after that restarted systemd and udev and also replugged the printer.
<tkamppeter> xnox ^^
<tkamppeter> xnox, udevadm monitor --environment gives now
<tkamppeter> SYSTEMD_WANTS='udev-configure-printer@-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2.service' printer.target
<tkamppeter> xnox, so here the backslash is in.
<xnox> tkamppeter, that's good, but paths should really be encoded using -p option, such that this unit name is @devices.... rather than @-devices
<xnox> tkamppeter, as in systemd leading slash is discarded, unless it's the only thing hence, for example mount units for / /var /var/lib are encoded as -.mount var.mount var-lib.mount
<xnox> tkamppeter, but it does smell like there maybe parsing regression in udevd and/or systemd codes
<tkamppeter> xnox, adding -p ...
<xnox> tkamppeter, is there a way for me to have a fake usb printer in udevadm?
<xnox> tkamppeter, can i fake add usb printer to like a VM?
<tkamppeter> xnox, now I get SYSTEMD_WANTS='udev-configure-printer@devices-pci0000:00-0000:00:14.0-usb2-2\x2d2.service' printer.target
<tkamppeter> xnox, journalctl -u 'udev-configure-printer@devices-pci0000:00-0000:00:14.0-usb2-2\x2d2.service' gives:
<tkamppeter> -- Logs begin at Mon 2017-10-09 09:07:44 -03, end at Mon 2017-10-09 14:52:12 -03. --
<tkamppeter> -- No entries --
<tkamppeter> xnox, and systemctl status 'udev-configure-printer@devices-pci0000:00-0000:00:14.0-usb2-2\x2d2.service':
<tkamppeter> â udev-configure-printer@devices-pci0000:00-0000:00:14.0-usb2-2\x2d2.service - Automatic USB/Bluetooth printer setup (devices-pci0000:00-0000:00:14.0-usb2-2\x2d2)
<tkamppeter>    Loaded: loaded (/lib/systemd/system/udev-configure-printer@.service; static; vendor preset: enabled)
<tkamppeter>    Active: inactive (dead)
<xnox> tkamppeter, inactive (dead) sounds good, no? it ran and quit?
<xnox> or never ran.....
<xnox> but note that the decoding is bad anyway
<xnox> the subject should be %i and it's not good
<xnox> actually not sure
<xnox> tkamppeter, i do not have any time today to look into this properly, i will come back to the back report sometime this week.
<xnox> tkamppeter, i have a few more urgent systemd things to look into
<tkamppeter> xnox, can you arrange it before Final Freeze on Thursday, so that Artful will have this fixed?
<xnox> tkamppeter, no, i cannot commit to that.
<xnox> tkamppeter, if you want to escalate, you can tag the bug rls-aa-incoming for core/foundations management to prioritise and assign it.
<xnox> tkamppeter, at the moment we are focusing on critical bugs only, that are preventing first-boot, install, reboot.
<tkamppeter> Does it mean I set the tag "rls-aa-incoming"? Have I also set another tag and/or subscribe the bug to someone?
<tkamppeter> xnox ^^
<xnox> tkamppeter, rls-*-incoming is away for canonical, to escalate issues cross-teams at canonical. Bugs tageed with such a tag will end up on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-aa-incoming-bug-tasks.html
<xnox> tkamppeter, which all teams review during their sprint-board loading and commit to fixing for a timeframe
<xnox> tkamppeter, this has been going on.... since like forever, at least since precise? if not before that
<xnox> tkamppeter, there are such reports for every realease
<xnox> ....
<tkamppeter> Added the tag now.
<tkamppeter> xnox, otherwise we have to make it an early-term (0-day, 1st week, 1st month, ...) SRU.
<tkamppeter> xnox, would be bad if the 17.10 will not have USB printer auto setup for all its life.
<tkamppeter> xnox, should we tell in the Release Notes that 17.10 is without automatic USB printer setup and that it is worked on it for an early SRU?
<xnox> tkamppeter, do edit the release notes, the known issues section, with a link to this bug. if we fix it before release we can remove that note
<tkamppeter> xnox, Release Notes edited.
<xnox> tkamppeter, thanks =/ and sorry
<tkamppeter> xnox, I could ask willcooke whether you could expense a USB printer so that you can test for fixing it as SRU shortly after release. WDYT?
<xnox> tkamppeter, ha
<xnox> tkamppeter, no way =) i think it should be doable to reproduce with "ls@.service" and udev rules that does SYSTEMD_WANTS for any device by calling systemd-escape --template=ls@.service %p
<xnox> tkamppeter, since one should be able to ls all the dev paths
<xnox> tkamppeter, and then i will need to plug in as many usb sticks as i can find
<xnox> =)
<tkamppeter> xnox, OK, then we have a way to do it. Take some time after Final Freeze and let us get an early SRU.
#ubuntu-devel 2017-10-10
<doko> rbasak: pcre3 still ftbfs on s390x, same test failures as -5
<doko> mwhudson: could you demote golang-1.7 for 17.10?
<ricotz> doko, good morning
<seb128> wgrant, hey, could you kick an artful langpack build? I checked the full export box, going to do another of those for the iso
<doko> tjaalton: can resteasy now be synced?
<tjaalton> doko: yes, since ubuntu has resteasy3.0 too
<tjaalton> or do we
<tjaalton> doko: I haven't pushed resteasy3.0 to ubuntu, it seems
<tjaalton> and debian NEW processing is fairly slow
<doko> is it?
<tjaalton> what is?
<mwhudson> doko: can i?
<mwhudson> doko: i thought that took an AA
<mwhudson> doko: um seems someone has done it
<mwhudson> about a week ago
<doko> mwhudson: I can't see anything
<mwhudson> doko: do you mean demote to universe (already happened) or delete?
<doko> mwhudson: ohh, apparently it already happened last week
<doko> mwhudson: but yes, cleaning up would be nice as well
<doko> mwhudson:
<doko> Reverse-Build-Depends
<doko> =====================
<doko> * docker.io                     (for golang-1.7-go)
<doko> * golang-github-gopherjs-gopherjs  (for golang-1.7)
<doko> LocutusOfBorg: what needs to happen with the ldc packages? I still see gir-to-d and sambamba
<rbalint> LocutusOfBorg: i prepared the u-u merge: LP: #1722426
<ubottu> Launchpad bug 1722426 in unattended-upgrades (Ubuntu) " Please merge unattended-upgrades 0.98 (main) from Debian unstable (main) Edit" [Undecided,New] https://launchpad.net/bugs/1722426
<LocutusOfBorg> doko, gir-to-d needs remove on ppc64el, because... ldc doesn't really work there at all
<LocutusOfBorg> it can't compile an hello world main
<LocutusOfBorg> and sambamba I don't really care, leaf new package, it can go demoted to proposed and fixed in debain
<LocutusOfBorg> debian
<mwhudson> doko: wtf, docker.io i need to upload that anyway
<mwhudson> doko: no idea what that gopherjs thing is about but 1.7 is gone in unstable i think so...
<mwhudson> oh no maybe it isn't gone in unstable, it should be though
<doko> mwhudson: no still there, and has a RC issue. lazy maintainers ;p
<LocutusOfBorg> rbalint, .
<mwhudson> doko: RoM is the best kind of RC bug fix
<mwhudson> although apparently the bug is fixed but not closed?
<rbasak> doko: :-/
<rbasak> doko: at least it's no worse.
<wgrant> seb128: Kicked off.
<seb128> wgrant, thanks
<rbasak> doko: AIUI pcre3 is fundamentally broken wrt. assumptions and compiler optimisation. Given the other fix, I wonder if bumping back to -O1 would work around the s390x segfault? Else it might need a deep dive to find a specific optimization that might be causing the problem.
<rbasak> doko: I have limited time to work on this I'm afraid. I was just driving by and saw a contributed patch that looked plausible.
<bmw> rbasak: I wanted to check in about Certbot SRU packages again
<bmw> would you have time to hop on a call sometime in the next week or two to figure out a plan for the rest of the work we have to do?
<bmw> I think we need to make python-letsencrypt (and maybe python-letsencrypt-apache) packages and perhaps debug the letsencrypt build failures if you haven't already
<mdeslaur> kees, infinity, stgraber, slangasek: TB meeting in 10
<rbasak> bmw: thank you for pinging. Yes, we should chat. Sorry, I've been travelling for various reasons. Catching up on certbot has been on my list but I've mostly been firefighting since I've been back :-/
<bmw> no worries
<bmw> I'll send around a Doodle or something to find out when everyone is available
<rbasak> Sure. Thank you for sorting this. Sorry it hasn't landed yet. So many twists and turns :-/
<bmw> I think/hope we're getting close!
<dmj_s76> tjaalton: I'll try to get the kbl firmware tested this afternoon or tomorrow.  Xenial has a newer kernel now, so 4.4 *shouldn't* be a blocker there anymore.  (Need testing to know for sure)
<tjaalton> dmj_s76: ah, good
<smoser> bdmurray, hey. so we have uploaded cloud-init to zesty and xenial.
<smoser> i'd like to request you to review that and make sure that it is what you were expecting
<smoser> i realize your SRU day is thursday, so we understand if it needs to wait until then
<smoser> the sru bug is bug 1721847
<ubottu> bug 1721847 in cloud-init (Ubuntu Zesty) "sru cloud-init 2017-10-06 (17.1-18-gd4f70470-0ubuntu1)" [Medium,Confirmed] https://launchpad.net/bugs/1721847
<bdmurray> smoser: I'll see if I can get to it early but I need to wrap something else up for the release.
#ubuntu-devel 2017-10-11
<doko> rbasak: hi, did you team had a look at the ftbfs from the test rebuild?
<doko> rbasak: at least pacemaker, tgt, memcached
<cpaelzer> doko: still working on the libvirt one as you know
<cpaelzer> back today (for one day) to check how the upstream discussion on a fix continued
<cpaelzer> I did not hear anybody picking up any of those you listed on the rally
<cpaelzer> doko: on openvswitch I know that jamespage is having the same issue on the 2.8.1 he is working on
<cpaelzer> doko: I'd also add strongswan to the list of things to really look at
<cpaelzer> doko: I added a trello card and will discuss with the team today
<cpaelzer> most of them look like the new gcc7 "printf will truncate" ...
<cpaelzer> rbasak: https://trello.com/c/AUbprZ20 ^^
<doko> LocutusOfBorg. xnox: I don't think that ignoring the pcre3 tests is ok ...
<LocutusOfBorg> doko, it is, since ulimit in porterbox works
<LocutusOfBorg> the stack is not sufficient, the test would pass with an ulimit -s 16384
<LocutusOfBorg> but if you have a way to increase it... I'm all ears
<seb128> there are a bunch of desktop fixes in the artful queue if somebody feels like letting those in? ;-)
<andyrock> bdmurray: hey! I just got this issue: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1368911
<ubottu> Launchpad bug 1368911 in apport (Ubuntu) "Apport crashes when writing to stderr: UnicodeEncodeError: 'ascii' codec can't encode character '\xc1' in position 130: ordinal not in range(128)" [Medium,Triaged]
<andyrock> I'm running Artful
<andyrock> so there is a suggested fix on comment #1
<andyrock> what do you think?
<seb128> wgrant, hey, can you kick another langpack build? we had some template missing that should be resolved now...
<jbicha> seb128: did you see LP: #1721359 too?
<ubottu> Launchpad bug 1721359 in simple-scan (Ubuntu) "Simple Scan translations are not synced with upstream" [Undecided,New] https://launchpad.net/bugs/1721359
<seb128> jbicha, yeah, letting robert comment on that one since he's upstream&downstream
<seb128> wgrant, or maybe wait a bit more and we do another one tomorrow or friday, still some things waiting to be imported
<wgrant> seb128: Let me know when you want it kicked off.
<Sargun> What's the process for getting a package updated in Ubuntu? Specifically: https://packages.ubuntu.com/artful/libnl-3-200
<Sargun> A minor version update, so it'd have to end up in 18.04
<powersj> Sargun: we are in final freeze right now, so after artful goes out and archive is open for the b-release someone could upload a new version.
<Sargun> Sounds good.
<sarnold> Sargun: https://wiki.ubuntu.com/StableReleaseUpdates is probably the best starting point
<seb128> wgrant, k, templates got imported so if you could trigger another artful langpack export that would be nice
<Sargun> sarnold: Yeah, it's a little more complicated unfortunately, because the maintainer / repo location have changed.
<sarnold> oh :/
<Sargun> libnl
<Unit193> You ever figure out what's going on in 1617535? 0_o
#ubuntu-devel 2017-10-12
<seb128> xnox, hey, is bug #1721839 an upstream systemd regression you think? should it be reported there?
<ubottu> bug 1721839 in systemd (Ubuntu) "Services asked for by UDEV do not get triggered" [High,Confirmed] https://launchpad.net/bugs/1721839
<xnox> seb128, i am aware of that bug, but i currently do not have time to look into it, focusing on installer not working with static ips at the moment.
<xnox> seb128, it smells like it, but i have not confirmed that; nor tested systemd master/v235;
<seb128> xnox, k
<seb128> so we can blame pitti right? ;-)
<xnox> seb128, totes!
<doko> rbasak: please could you walk over the list of ftbfs (main) for the last test rebuild and see what can to be fixed?  http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170922-artful.html and http://qa.ubuntuwire.org/ftbfs/
<doko> I mean, somebody from the server team
<doko> jamespage: ^^^ same for the openstack team
<Unit193> http://paste.openstack.org/show/xmFYlAoCdY1cOlu3G4Ds that's a bit cleaner network-manager.postinst in the case nplan isn't installed.
<jamespage> doko: have a fix for the openvswitch s390x ftbfs which I've just uploaded - coreycb can you take a look at the neutron-* and swift failues ^^
<coreycb> jamespage: sure np
<Unit193> ogra_: BTW, finally tested '3', it works!  Not as obvious as 'text', but far better than the systemd target!
<ogra_> oh my
<ogra_> so the old "all runlevels are the same on debian" paradigm is actualy dead then
<Unit193> Perhaps overall not exactly what one hopes for, but it has a nice upside. >_>
<coreycb> doko: are the rebuilds against artful-updates or is there a PPA I need to be based on?
<seb128> bdmurray, hey, I find that the is very little rhythmbox reports on e.u.c for artful could you check if there is a retracing problem behind or if we just don't get a lot of users/reports for it?
<fuser> Hello. This is how my terminal looks now: https://i.imgur.com/hJqtWi6.png
<fuser> (ubuntu 17.10)
<fuser> The white is the terminal background color, the thickness of the border varies when I ctrl+ and ctrl-. I really doubt this was there before, I think I would have noticed.
<fuser> Ive been on 17.10 for a long time, this is new. Might be nvidia driver update?
<nacc> fuser: you want #ubuntu+1
<fuser> thanks
<smoser> is this table available in json
<smoser>  http://autopkgtest.ubuntu.com/packages/o/open-iscsi/artful/amd64
<smoser> or some thing ?
<smoser> other than http scraping
<smoser> nacc, ^ ? do you know ?
<nacc> smoser: not that I know of
<nacc> smoser: i *think* there might be a an archive tool that shows the same results
<nacc> smoser: or does parse
<bdmurray> seb128: Is it just rhythmbox or would apport not having been enabled in Artful for a while caused this?
<bdmurray> smoser: they show up in update_excuses yaml
<smoser> bdmurray, ?
<smoser> i'm interested in json or something describing all the runs so that i can grab all the files and look at them, or do something other than browse
<bdmurray> smoser: people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.yaml
<bdmurray> smoser: that's the same content as update_excuses.html although I guess it only has failures
<smoser> bdmurray, thanks.
<smoser> so if i were interested in filing a feature request that i would expect would probably never get done...
<smoser> where would i file ?
<seb128> bdmurray, dunno, other applications are low, so maybe low number of users of desktop apps and apport was not working/being enabled recently
<bdmurray> smoser: Oh the frontpage says SQLite database with results
<smoser> bdmurray, front page ?
<bdmurray> http://autopkgtest.ubuntu.com/
<smoser> downloading 191M now :)
<smoser> bdmurray, not that you have a real care, but i dont see in the results any artifacts or log urls.
<jackpot51> GRUB no longer builds on artful
<cjwatson> jackpot51: that comment would be most helpful if it came with an indication of exactly which version of the GRUB source code were involved and a pastebin of the error
<cjwatson> you must have that information so don't make other people guess :)
<jackpot51> Don't worry, I already have a patch to fix it. Newest version in artful doesn't build due to errors such as the one seen at the end of this log: https://launchpadlibrarian.net/340649401/buildlog_ubuntu-artful-amd64.grub2_2.02~beta3-4ubuntu6pop0_BUILDING.txt.gz
<jackpot51> Just want to get your attention
<jackpot51> I will make a launchpad bug with the patch attached
<cjwatson> that's already fixed upstream too
<cjwatson> and in Debian
<jackpot51> Oh, then just need to wait on the sync
<cjwatson> well it's probably a complicated merge
<cjwatson> cyphermox mentioned this to me a couple of weeks ago so I assumed they were going to cherry-pick it ...
<jackpot51> Is there a launchpad bug?
<cjwatson> dunno
<cjwatson> the upstream commit is 07662af7aed55bcec448bc2a6610de1f0cb62100
<cjwatson> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=07662af7aed55bcec448bc2a6610de1f0cb62100, more helpfully
<seb128> slangasek, xnox, do you know if there are plan to enable systemd persistant journal for next cycle?
<slangasek> seb128: hi, so we have the persistent journal on our "ideas" for 18.04 roadmap; we haven't committed to it, and it's my position that we shouldn't enable persistent journal by default unless we also disable syslog to disk by default
<slangasek> seb128: which makes it a bit more controversial, and requires us to think it through carefully and discuss widely before taking a decision.  Is there a push to enable it from the desktop side, and if so what is that?
<jbicha> Ubuntu 17.10's default log viewer is now gnome-logs instead of gnome-system-log, gnome-logs is systemd journal only
<mwhudson> it would sure be nice if autopkgtest-virt-qemu actually worked :(
<cyphermox> jackpot51: I sponsored grub2 for tdaitx earlier
<cyphermox> cjwatson: ^
<cyphermox> I was waiting for a grub2-signed, but I guess I should stop waiting and just do it now
<tdaitx> cyphermox, sorry, I didn't realize you needed it that soon
<tdaitx> I was working on the openjdk security updates
<cyphermox> tdaitx: it should be uploaded with grub2, since otherwise it will stick in proposed
<cyphermox> tdaitx: don't worry about it, I'll do it now
<cyphermox> it's tiny
<tdaitx> cyphermox, ack, I can stop and do it now as well, as aiming for EOD
<tdaitx> *was
<cyphermox> bah, don't worry about it
<tdaitx> ok, tks cyphermox
<juliank> oh, I already he apt SRUs are already 13 days in the queue and I have not verified them. Slow /me - time is moving to fast, aargh
<juliank> I kind of write scripts and run them with sh -x in a docker container for validating things and then add the output to the bug as a comment :D
<juliank> with before/after comparisons :D
<cjwatson> cyphermox: ta
<jackpot51> Thanks cyphermox
<xnox> jbicha, slangasek - most of our images have systemd journal enabled.
<xnox> slangasek, i was going to enable rsyslog precise journald plugin such that journald logs are in syslog, with matching identical timestamps, and do nanotimestamps by default.
<sarnold> _persistent_ journal? or just journal?
<xnox> slangasek, if we are going to break people, i'd rather do it for the good. E.g. making syslog timestamps precise will break most people's logrotate/logwatch
<xnox> sarnold, currently we have journald set at auto -> which means it logs to /run/log, unless /var/log/journal exists. If /var/log/journal exists, it rotates early-boot logs from /run/log to /var/log/journal and then keeps logging on disk.
<xnox> sarnold, we are discussing enabling it by default, meaning that /var/log/journal exists. It auto-rotates, compresses, and garbagge collects on both /run and /var/log such that it never uses "too much" of ram and/or disk space.
<sarnold> aha, so it's 'yes except no one knows how to enable it' :)
<sarnold> xnox: thanks
<xnox> sarnold, yes, and journal thus is only available for the current boot, and after reboot past boots are gone.
<xnox> sarnold, sucks for debugging and kernel lock ups and oopses and history or services crashing restarting.
<xnox> sarnold, or on my systems i get something like less than than 2 weeks of logs, as my VPS does not have much RAM.
<xnox> sarnold, many of our cloud images have /var/log/journal enabled.
#ubuntu-devel 2017-10-13
<mwhudson> what's with the armhf autopkgtest queue length?
<ginggs> slow armhf is slow
<seb128> thanks to whoever has do an update from the langpacks
<infinity> seb128: I believe that's sil2100, though he's been quiet about it. :)
<seb128> he's not even on IRC :p
<infinity> seb128: That might explain the quiet.
<jibel> I noticed that the locale is wrong when booting with the default language on the livecd. Submitted bug 1723404
<ubottu> bug 1723404 in livecd-rootfs (Ubuntu) "Wrong locale ' UTF-8' in /etc/locale.gen on desktop live image" [Undecided,New] https://launchpad.net/bugs/1723404
<seb128> jibel, so, about /etc/locale.gen being buggy/having no value when booting the current artful I notice something changed around locale-gen in http://launchpadlibrarian.net/339014783/livecd-rootfs_2.459_2.460.diff.gz
<seb128> slangasek changed livecd-rootfs
<seb128> unsure if that could create that issue though
<seb128> but sounds like that's something foundations should understand better
<jibel> could it cause the problem with the terminal?
<jibel> seb128, ^
<jibel> yes
 * jibel answering to himself
<seb128> I think it could
<seb128> did you confirm?
<slangasek> yeah, that's my fault
<jibel> seb128, if you fix locale.gen regenerate the locale, and the locales properly it starts
<seb128> that makes sense
<didrocks> at least, it's only one issue :)
<slangasek> it'll be a bit before I could fix it today; I was planning to fix it to properly default to C.UTF-8 without generating any locale in the default case
<seb128> slangasek, good morning, you won bug #1723404 then :-)
<ubottu> bug 1723404 in livecd-rootfs (Ubuntu) "Wrong locale ' UTF-8' in /etc/locale.gen on desktop live image" [Undecided,New] https://launchpad.net/bugs/1723404
<slangasek> thanks
<seb128> thank *you*!
<jibel> yw
<seb128> jibel, you can dup /invalid the other bug
<jibel> done
<seb128> thx
<slangasek> seb128, jibel: actually, proposed fix just uploaded, if someone wants to sanity-check it in the queue
<slangasek> jibel, seb128: sorry, was offline while plenarying; any opinions on that casper upload?
<seb128> slangasek, it seems to work, I tried by doing a break=casper-bottom and sedding the changes/editing /etc/default/locale and then booting
<seb128> so +1 from me
<slangasek> nice
<slangasek> self-accepting, then
<seb128> thanks
<coreycb> doko: i just uploaded a new neutron-vpnaas for artful which should fix the build error. i wasn't able to recreate any of the other neutron-* or swift FTBFS.
<sunweaver> hi all.
<sunweaver> I need a build log of a specific package in Ubuntu artful (src:package: pakcs).
<sunweaver> where do I find the build logs?
<sunweaver> THANKS!
<cjwatson> sunweaver: https://launchpad.net/ubuntu/+source/pakcs and follow links
<cjwatson> sunweaver: the version under the artful section takes you to https://launchpad.net/ubuntu/+source/pakcs/1.14.2-1; pick an architecture under "Builds"; and the build log is linked from there
<sunweaver> cjwatson: thanks so much!
<coreycb> doko: have you seen anything like this in artful by any chance? https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1722553
<ubottu> Launchpad bug 1722553 in python-openstackclient (Ubuntu) "openstack command raises exception referencing gi.repository and gnome bug 709183" [Undecided,Confirmed]
<xnox> rbasak, https://www.goodreads.com/book/show/242472.The_Black_Swan =)
<rbasak> xnox: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=regression-update
<xnox> rbasak, what i'm trying to say, it is not possible to predict, ahead of time, if HA will blow up or not, and how.
<xnox> rbasak, any kernel update can cause HA to break, yet we do them blindly and fix things up quickly when they do break.
<xnox> rbasak, hence risk assessment should rely on tangible things.
<rbasak> xnox: it is absolutely possible to think about it
<rbasak> xnox: when you know and understand exactly what you're proposing to change, and when you are able to look into some of the complex use cases that can be identified.
<rbasak> This *is* a tangible thing.
<rbasak> It's not just "any kernel update". It's a specific and understood behaviour change.
<rbasak> For example: for Neutron, you could ask our OpenStack QA guys to simply try it.
<rbasak> Not even a PPA is needed.
<xnox> rbasak, there is no change to uevents/netlink events as all of them are still generated, thus any existing software that needs to monitor ip address changes, already does so, and is unaffected.
<xnox> rbasak, asking OpenStack QA people to try Neutron with said sysctl on is a bit of a waste of time, as one needs to specifically be triggering/causing assignment of multiple ip addresses, issued for the same subnet/netmask, by the same dhcp server ttl (or lack of) and removing/updating those.
<rbasak> xnox: you seem to be limiting your analysis to "needs to monitor ip address changes"
<rbasak> Perhaps I misunderstand the scope of the change, but IMHO, that's your job to explain it well in the bug, and to explain why the scope is not wider.
<xnox> rbasak, if i add 4 ip addresses from different netmasks they are all primary and are all unaffected/unchanged.
<xnox> rbasak, if i add an ip address that matches all all basis (issued by the same dhcp server, for the same interface, for the same netmask, etc) kernel designates that duplicate ip address as secondary; which is only discoverable post-factum from the uevent/netlink qeuries.
<xnox> primary & secondary address operate just fine; apart from only the primary one used as source address routing, never secondary. but one can accept connections/data on the secondary address.
<xnox> this is all on ipv4 only.
<xnox> when asking to removing primary address, it removes matching secondary addresses. which is surprising event, but is observable via netlink/uevent.
<xnox> change of behaviour is bad.
<xnox> but change of behaviour where it's not the same on all Ubuntu variants is even worse, when certain installer/packagesets/configs are in use, is even more confusing.
<xnox> the net change here is that when requesting to remove 1 address, only that address is removed - previously kernel would also remove other addresses that were not requested to be removed.
<xnox> from the group of same interface, same netmask, same network, same dhcp issuer.
<xnox> rbasak, was above word-salad, same/similar to what was your understanding of the scope of change prior to word-salad?
<xnox> rbasak, also if you don't understand the scope of the change, why are you assesing the risk of it, instead of asking "i don't understand what this is changing, please elaborate again?"
<xnox> surely we should first make sure everyone understands the proposed change, before debating if it is a good idea or not...
<rbasak> I'm not assessing the risk of it. I'm assessing the areas where you have either not assessed the risk of it or not shown it to be out of scope.
<xnox> rbasak, O_o
<xnox> the bit about existing code / old code -> code that tries to change ip address, therefore must be either monitoring removal of ip address; or removing first, then adding. cause otherwise with with all default linux kernels "add new, rm old" does not work.
<xnox> for a trivial case of add 10.0.0.1; add 10.0.0.2; rm 10.0.0.1 => one has to do add .1 rm .1 add .2, unless we apply this sysctl.
<ogra_> rbasak, note that the main scope is Ubuntu Core and that the issue was discovered by a customer that has 10000s of IoT devices out there already ... note also that OTOH only UbuntuCore uses systemd-networkd in xenial yet (distro stayed with the old stuff for 16.04)... we *could* just stay with the interim hack we use in Core to set this sysctl option
<ogra_> (it is just ugly to diverge)
<xnox> but using this syclt, does not break the old code; as doing add .1 rm .1 add .2 still works.
<xnox> ogra_, false
<ogra_> xnox, which part ?
<xnox> rbasak, ogra_ - we have multiple bare metal and virtualised clouds using netplan & networkd in xenial.
<xnox> in production.
<ogra_> oh
<ogra_> i didnt know
<rbasak> ogra_: so this is the part I don't like: changing behaviour on *all* Ubuntu developments for the sake of a bug in a package that is only used by a very small subset of those use cases.
<ogra_> i thought we were the only ones ... ignore that then
<xnox> however, most clouds use static ip addresses and do not change them. hence unaffected.
<rbasak> all Ubuntu deployments
<xnox> dhcp v4 with changing ip address with intermetint connectivity is more in scope for IoT / Core, hence it is reasonable that that product has discovered this issue first.
<rbasak> Users do crazy things with Linux networking
<xnox> ogra_, yes, the scope of change is everyone.
<ogra_> yeah, users are crazy :)
<rbasak> It feels risky to me to tweak a default from under their feet
<rbasak> I'm not saying that we shouldn't SRU something.
<rbasak> We absolutely should.
<xnox> rbasak, i find sysctl's madness =) espacially since we often do not control neither the kernel, nor sysctls from userspace.
<rbasak> But it doesn't seem very difficult to limit this in scope.
<ogra_> xnox, i personally could live with the current solution and you could just skip xenial ... but i dont know how these others you mentioned would be impacted
<xnox> and kernel defaults seem to be broken by design, often.
<ogra_> (seemingly only Core users complained yet)
<xnox> ogra_, haha, no. i find it appauling that you backdoor images and build core in a way that does not match the ubuntu archive.
<ogra_> (and they have a fix in next weeks core snap)
<xnox> not in terms of series of bytes, but in terms of net effect & result.
<ogra_> xnox, that will even get worse, "base" snaps were exactly designed to diverge even moe
<ogra_> the core as you know it will soon go away
<ogra_> xnox, note that core has always used extra icing on top btw https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<mitya57> tjaalton, hi! Will you mind if I backport https://cgit.freedesktop.org/xorg/xserver/commit/?id=885636b7d42b3c7b into Artful package?
<mitya57> Or too late and better to do it as SRU?
<nacc> mitya57: i believe it's final freeze now
<nacc> (possibly /topic needs an update)
<mitya57> nacc: I know it is final freeze, but bugfixes should be OK, and the release team can push them to 0-day SRUs.
<pdeee> rbasak, nacc we have a Certbot SRU call now if either of you are joining
<fenevadkan> Hi
<fenevadkan> just upgraded to Artful
<fenevadkan> and I cannot login with neither lidghtm nor gdm if using nvidia driver
<fenevadkan> if I remove nvidia drivers I can login, but it is just terrrribly slow
<fenevadkan> is there no hardware acceleration in nouveau??
<rbasak> pdeee: argh! Sorry. Still there?
<tjaalton> mitya57: file a bug for sru with steps to reproduce
<rbasak> bmw: ^
<bmw> rbasak: unfortunately no, we wrapped up 10-15 mins ago
<bmw> we did a little more digging into the different issues we wanted to resolve
<rbasak> Well, now I owe you. I'll sort something out.
<bmw> OK thanks
<bmw> it ended up still being productive for us as we chatted about the relevant issues and started talking about other packaging problems
<bmw> but for the SRU, we looked into shim packages
<bmw> python-letsencrypt is only really useful for people using third party plugins installed through other means with the current packages from Ubuntu xenial
<bmw> we looked at the server side numbers for people doing that, and we saw 16 certs issued that way out of around 100k
<bmw> in your mind, is that worth creating this package?
<bmw> we can probably reach out to the people (or more likely individual) who are doing that and warn them about upcoming changes
<bmw> as for python-letsencrypt-apache, our issues there would be resolved by making python-letsencrypt-apache a virtual package that installed python-certbot-apache
<bmw> my knowledge of .deb packaging is pretty limited, but our Debian maintainer thought that'd be extremely easy to do
<bmw> and finally the package build failures
<bmw> our Debian package maintainer thought that shouldn't really be a problem as long as we ensure all packages transition together cleanly to the production repos
<bmw> there have been a few times only a subset of the packages have made it to Debian sid or backports and that has caused issues, but otherwise, the build failures seemed normal and expected to him
<bmw> we can talk more about that with our Debian maintained in #letsencrypt-dev if you want though
<bmw> regardless, I hope this info dump helps!
<rbasak> It does, thanks. I'll move over to the other channel.
<est31> https://packages.ubuntu.com/xenial/wine-mono0.0.8
<est31> https://packages.ubuntu.com/zesty/wine-mono0.0.8
<est31> what happened here?
<est31> the wine-mono package is not available in zesty
<jbicha> est31: yes we share wine packaging with Debian now, which doesn't have that package
<est31> jbicha: the issue is, I can't seem to be able to run mono applications with wine
<est31> dot net that is
<est31> err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed
<est31> archlinux wiki says "it copies wine over automatically from the wine-mono package" -- that's not how it works in ubuntu apparently
<sarnold> looks like it's in both wine and wine-development packages https://codesearch.debian.net/search?q=GetRuntimeHost
<est31> sarnold: right wine and wine-development only differ in the version of wine
<sarnold> est31: which -might- work out in your favour for zesty, since the wine-development is much newer in zesty..
<est31> its not about versions
<est31> its about having mono or not
<est31> I guess I need to figure out a way to install it manually then...
<sarnold> est31: oh? I think it's worth trying wine-development on zesty, at least that one symbol appears in the packaging http://paste.ubuntu.com/25733931/
<est31> sarnold: thats the symbol throwing the error
<est31> if you look at the source code you can see sth like if(there is mono) {fine!}  else{ ERROR}
<sarnold> est31: Oh :(
<est31> at least you can install it manually :)
<est31> but its a packaging issue basically
<est31> a) all the other distros have it
<est31> b) upstream wine installs it automatically
 * est31 nags debian
#ubuntu-devel 2017-10-14
<rbasak> slangasek, bdmurray: FYI I just filed bug 1723562. Was there some effort to make sure kernel autoremove is good recently, perhaps so that we're definitely good by B-series?
<ubottu> bug 1723562 in apt (Ubuntu) "Kernels get stuck in "manual" state and fail to autoremove after disk full condition" [High,Triaged] https://launchpad.net/bugs/1723562
<bdmurray> rbasak: We have been working on it but ran into a bit of a snag w/ autoremoves behavior
<slangasek> "stuck in manual state" - that's not something I've seen recently?
<slangasek> rbasak: indeed, you say this was an EOL installation... there has certainly been work in this area, so what EOL release was being run exactly?
<rbasak> slangasek: Wily
<rbasak> slangasek: if you think it's fixed, then treat my report as Incomplete I guess.
<doko> coreycb: no, didn't see that, or can't remember
<doko> coreycb: just gave back swift, still ftbfs
#ubuntu-devel 2017-10-15
<Unit193> ricotz: Thanks for looking into ESR.
<jbicha> LocutusOfBorg: what should we do with gir-to-d? just drop the ppc64el binaries?
<jbicha> LocutusOfBorg: tilix doesn't work in -proposed LP: #1721101 so maybe it'd be better to just wait until 18.04 now
<ubottu> Launchpad bug 1721101 in tilix (Ubuntu) "tilix crashes on execution" [Undecided,Confirmed] https://launchpad.net/bugs/1721101
<hwpplayer1> Sorry what do we use on contribute page before downloading Ubuntu images
<hwpplayer1> Do we have any machine learning feature ?
<hwpplayer1> Sorry what do we use on contribute page before downloading Ubuntu images Do we have any machine learning feature ?
<hwpplayer1> Who develops this page ?
<ReedK0> any place on freenode to find paid devs?
<ReedK0> for a little ubuntu proggy
<LocutusOfBorg> jbicha, yes, delaying is probably the best thing to do
<infinity> pitti: Imagine a world where autopkgtest passed its own tests. ;)
<mitya57> Lots of armhf autopkgtests are failing with: no space left on device.
<mitya57> I donât know whom to ping, but please look :)
<sabdfl> infinity, it's been ages, hope you are well, think you probably want to look at https://bugs.launchpad.net/ubuntu/+source/keyboard-configuration/+bug/1723806
<ubottu> Launchpad bug 1723806 in keyboard-configuration (Ubuntu) "1.108ubuntu15.4 hangs on upgrade" [Undecided,New]
<sabdfl> -proposed update hangs dpkg-configure and hence blocks further updates for me
<sabdfl> as a trade, you'll be pleased to know, i have a list of b* adjectives :)
<infinity> sabdfl: That's a solid trade.  I'll have a look when I get back from dinner.
<sabdfl> infinity, it looks like 15.4 is actually the fix, and the one that hung was 15.3
<sabdfl> another machine went through fine with 15.4
<sabdfl> infinity, were you at the rally?
<infinity> sabdfl: I wasn't.  Bereavement prevented it.  Or, made it less viable.
<infinity> sabdfl: Sad that I missed it, but life's like that sometimes, I guess.
<infinity> sabdfl: Anyhow, I have 5 minutes to get to somewhere 15 minutes away for a family gatheting, so catch you later. :)
#ubuntu-devel 2018-10-08
<Saviq> hey all, is there a "canonical" way to set up cgroups on Ubuntu? I can see we don't have "cgrulesengd" set up as a service, is just running `cgconfigparser` on boot and using `cgexec` the recommended approach?
<sub526> .
<sub526> Hi All, during "sudo apt-get install test_pkg", I'm getting the error "dpkg: error processing archive /var/cache/apt/archives/test_pkg_1-1_amd64.deb (--unpack)" and "trying to overwrite '/usr/sbin/w1_test', which is also in package test_pkg2. Any idea, how to overcome this error?
<alkisg> Don't create 2 packages that ship the same file :)
<sub526> alkisg: But the other package is not installed in my PC.
<alkisg> sub526: are you sure? dpkg -L test_pkg2; dpkg -S /usr/sbin/w1_test
<alkisg> Note though that this channel is for developing ubuntu itself, I don't think it is for helping with package development in ubuntu...
<sub526> alkisg: Sorry, i did not check properly. Yes, the same file was already installed by other package.
<Trevinho> sil2100: hey, when you've a sec can you check the ubuntu-themes sru for bionic please?
<sil2100> Trevinho: hey! I'll try to find a few moments after lunch ;)
<Trevinho> thanks :)
 * jbicha looks disappointingly at bos02
<Laney> most of all it's let itself down
<Laney> (back)
<jbicha> Laney: https://launchpad.net/builders/ still says cleaning
<Laney> a buildd admin needs to reset them, but the cloud itself is back
#ubuntu-devel 2018-10-09
<seb128> wgrant, cjwatson, hey, is there a way to know who is tweaking the translation template sharing details on launchpad? or to lock those settings down? looks like the "sharing with main serie" has been enabled for most desktop packages again, but that points to buggy/outdated code import on launchpad and prevent source package templates/translations to be imported, which result in outdated/buggy ubuntu translations :/
<seb128> I'm chasing down those manually now, which is tedious and leading to no change rebuilds
<didrocks> seb128: speaking of which (and maybe related to your question), I guess you noted as well that GNOME Shell has some part of the UI in English, correct?
<seb128> didrocks, yeah, that was discussed on the desktop channel some days ago and an upstream bug in gnome-shell, we need to get the .1 update
<didrocks> ok, great :)
<sbraz> hi, can someone explain what the +esm1 stands for here? https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-7099.html
<ubottu> The tls.checkServerIdentity function in Node.js 0.10.x before 0.10.47, 0.12.x before 0.12.16, 4.x before 4.6.0, and 6.x before 6.7.0 does not properly handle wildcards in name fields of X.509 certificates, which allows man-in-the-middle attackers to spoof servers via a crafted certificate. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7099)
<sbraz> my currently installed version is "4.2.6~dfsg-1ubuntu4.2" without the +esm1 part, which makes pakiti think that my system is vulnerable
<sbraz> Extended Security Maintenance i guess? still, why doesn't the installed version match the version in the advisory?
<cjwatson> seb128: I don't really know the details of this but AFAIK none of that kind of thing has a very useful audit log
<cjwatson> sorry
<seb128> cjwatson, no worry, I was sort of expecting it was the case based on the previous cycles conversations with William when that sort of issues happen
<seb128> I'm probably going to write a script that goes through the pages (or use the launchpad api if it works for that, I need to have a look) and dump the sharing status
<xnox> sbraz, hi. What's published in ubuntu can be seen here https://launchpad.net/ubuntu/+source/nodejs
<xnox> sbraz, i don't know how Extended Security Maintenance works, you'd need to contact ESM support if you have that, and something is missing.
<sbraz> xnox: yes and this page doesn't list the version https://packages.ubuntu.com/xenial/nodejs doesn't either
<sbraz> xnox: and https://people.canonical.com/%7Eubuntu-security/cve/2015/CVE-2015-8860.html says "released-esm" for ubuntu 16 which doesn't make sense, 16 is still fully supported, isn't it?
<ubottu> The tar package before 2.0.0 for Node.js allows remote attackers to write to arbitrary files via a symlink attack in an archive. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8860)
<xnox> sbraz, fully supported, but we only provide security support for main.
<xnox> sbraz, node-tar and nodejs are from universe.
<sbraz> xnox: so that ESM feature can be useful for xenial too?
<xnox> sbraz, looks like it, it seems to cover more. you should contact canonical sales about ESM.
<xnox> sbraz, i.e. https://buy.ubuntu.com/ has a chat thing and phone numbers too.
<sbraz> xnox: what bothers me is that those esm packages which are not free are listed in https://people.canonical.com/~ubuntu-security/oval/com.ubuntu.xenial.cve.oval.xml
<jdstrand> sbraz: Ubuntu 16.04 is still officially supported by Canonical for main/restricted and community supported for universe/multiverse. UA customers may receive updates beyond what is officially supported
<jdstrand> sbraz: can you clarify why their inclusion in the oval data bothers you?
<sbraz> jdstrand: it's always a bit frustrating to see vulnerable packages on my servers, i didn't even know ESM was a thing until today
<sbraz> i thought a vanilla up-to-date ubuntu to have no vulnerable packages
<sbraz> i assume if i were to run bionic, this wouldn't be an issue?
<JamieBennett> sbraz: right
<jdstrand> sbraz: nodejs is in universe and thus community maintained. packages that are community supported are kept up to date to the level that the community has invested time in them
<jdstrand> sbraz: you might be interested in https://wiki.ubuntu.com/SecurityTeam/FAQ#Official_Support
<jdstrand> how does that page not say anything about esm... /me adjusts
<sbraz> jdstrand: i understand, it's just that i never had to think about all this before; it just worked as expected in the past, it's the first time i stumble on that kind of package/vulnerability
<rbasak> Nothing has been taken away. You're just noticing more because Canonical are publishing more information for their customers and making some of that information public.
<jdstrand> right
<xnox> sbraz, "in the past" you had vulnerable packages in universe installed and there were no updates for those available - neither gratis, nor paid. And well, was vulnerable to CVEs applicable to universe.
<sbraz> xnox: i'm not saying it was better, just that i hadn't noticed :)
<xnox> =))))))
<sforshee> LocutusOfBorg: so I just got told about shared folders not working in Vagrant because of removing the vbox-guest-dkms modules from the kernel, bug 1796647
<ubottu> bug 1796647 in cloud-images "Shared folders cannot be mounted in ubuntu/cosmic64 due to missing vbox modules" [High,Confirmed] https://launchpad.net/bugs/1796647
<sforshee> the kernel packaging continues to say that it provides virtualbox-guest-modules, which it shouldn't
<LocutusOfBorg> sforshee, the kernel should contain them... why did it drop them=
<LocutusOfBorg> ?
<LocutusOfBorg> it has been using vboxvideo from the intree driver, and everything else from vbox modules
<LocutusOfBorg> IIRC
<sforshee> LocutusOfBorg: we've talked about this several times ... we're using the upstream drivers now, you said you didn't want to seed vbox-guest
<sforshee> there should still be time to pull them back in though
<LocutusOfBorg> ok but only vboxvideo is upstream right now
<LocutusOfBorg> I remember some of them being upstreamed IIRC
<sforshee> we must have gotten some wires crossed, I thought you said the others weren't important to ship in the kernel
<LocutusOfBorg> vboxvideo is important if you want a good resolution
<LocutusOfBorg> and yes, others are not fundamental, unless you want copy-paste from guest to host and such features
<Odd_Bloke> sforshee: As a sidenote, we do need these drivers in the official Ubuntu Vagrant image, which I think would preferably not rely on the DKMS modules.  (Not a hard requirement AFAIK, but would maybe nudge us more to retaining them.)
<sforshee> right ... I'm also now recalling that there was a conflict because the modules shipped upstream and in the dkms package have duplicated names
<sforshee> both ship vboxguest.ko iirc
<sforshee> so probably we'll need to rename vboxguest that comes from the dkms package, is that going to cause issues?
<LocutusOfBorg> why? is it causing problems?
<LocutusOfBorg> they have different directories, so there is no clash wrt apt side
<LocutusOfBorg> and my vboxvideo has higher priority, something I want to have :)
<sforshee> the kernel build infrastructure does not expect modules with the same name when it is building, and does not handle it properly. I can't remember the specifics off the top of my head
<sforshee> I'm thinking it can't find symbols exported from one or the other
<LocutusOfBorg> mmm so you are talking about the build farm...
<LocutusOfBorg> interesting
<sforshee> not the build farm, all the makefiles and scripts which build the kernel
<sforshee> it may be some kind of namespacing thing, like I said I can't remember the exact details now
<LocutusOfBorg> but you don't have to copypaste my vboxvideo from vbox source tree, just the others
<sforshee> but I am thinking that something failed to link because it wanted exported symbols from one of the vboxgues modules but wasn't seeing them because they were masked by the other vboxguest module
<LocutusOfBorg> I don't know...
<sforshee> the simple way to avoid it though is to rename one of them
<LocutusOfBorg> what about providing "virtualbox-guest-video" kernel module?
<LocutusOfBorg> and let the others come from my vbox source package?
 * LocutusOfBorg has to leave shortly
<sforshee> that doesn't fix it, we were already doing that
<sforshee> anyway, let me look into it
<LocutusOfBorg> ok
 * LocutusOfBorg leaves
<caravena> Hello... What does it mean?: 'rls-cc-incoming'
<caravena> ^ Trevinho: Hello :-)
<caravena> -> https://bugs.launchpad.net/bugs/1796422 You added the tag 'rls-cc-incoming'
<ubottu> Launchpad bug 1796422 in vte2.91 (Ubuntu) "Crash at encoding change" [Undecided,Confirmed]
<infinity> vorlon, mdeslaur, kees, stgraber: Tee Bee.
<mdeslaur> infinity: ack
<jbicha> caravena: it's used to suggest that that bug should be a priority for fixing for the CC (Cosmic) release
<jbicha> bugs with that tag will show up on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
<jbicha> bugs can be fixed without that tag too
<caravena> jbicha: Excellent! Thank you
#ubuntu-devel 2018-10-10
<tsimonq2> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: tsimonq2
<tsimonq2> This is more of an experiment for now, but I'm following what cyphermox set out in his email: https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040501.html
<tsimonq2> Maybe the bot can eventually be updated to distinguish +1 vanguards vs Patch Pilots but I'll also be looking at the sponsorship queue.
<tsimonq2> Ah, I see not much SRU processing lately but it's understandable given the state of the development cycle...
<sarnold> woah a patch pilot
<sarnold> this takes me back :)
<tsimonq2> Yeah, hehe
<tsimonq2> sarnold: If you're around, how's this apparmor profile look? bug 1788102
<ubottu> bug 1788102 in ntpsec (Ubuntu) "ntpsec's ntpd fails to write ntp.drift file because of apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/1788102
<tsimonq2> I don't personally know enough about apparmor so your opinion on it either way would be welcome.
<sarnold> tsimonq2: lgtm, richard's usually on the ball
<tsimonq2> Cool.
<tsimonq2> sarnold: Uploaded to the queue, thanks!
<sarnold> tsimonq2: woot, thanks :)
<tsimonq2> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots:
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-release/2018-October/004611.html
<cyphermox> tsimonq2: I did ask how we could update the bot code to distinguish (or replace, since patch pilot is largely a dead thing)
<tsimonq2> cyphermox: I don't even know where the code is for it. :/
<coreycb> doko: i know python3.7 will be the default in the next ubuntu release, but out of curiosity will it also have python3.6 available?
<xnox> coreycb, no, the plan is python3.7 only
<xnox> coreycb, for 19.04 that is.
<coreycb> xnox: ok thanks, and yes 19.04 is what I was curious about
<coreycb> xnox: just formulating an email upstream
<xnox> coreycb, does that have some implications? as in, why are you asking? =)
<coreycb> xnox: well i'm going to try to enable py37 tests upstream. there might be some push back because not not all tests are passing yet from recent py36 enablement.
<coreycb> xnox: looks fairly trivial to enable, but a decent amount of busy work across many projects. getting fixes may be another story. hopefully i can convince them it needs to be enabled and get community focus on fixes soon.
<rbasak> juliank: thank you for the version regression report. I wonder if we could perhaps add this to the pending sru report? Or should it be separate?
<juliank> rbasak: I don't think it's something to consider in the SRU reporting. It also applies to security updates, and for those, there sometimes are valid reasons to temporarily have the new release in a stable release first
<juliank> but not sure
<xnox> well, a new archive report to be run and published on ~ubuntu-archive
<rbasak> I just wondered about when someone will look.
<xnox> juliank, you do know ubuntu-archive-tools repository?
<rbasak> If left to the AAs then I suppose they have their own separate reports to check for all the other wrong things too
<juliank> xnox: yes
<xnox> add it there =)
<juliank> I think optimally it should also query security thing and check if any CVEs are fixed in older releases, but not in newer.
<juliank> xnox: I will soon
<juliank> rbasak: I'm not sure if there's anything actionable for the SRU team except for not releasing an SRU until it has a higher version number in later releases
<rbasak> juliank: it might be useful to block releasing to updates (from proposed).
<juliank> Maybe britney could check that automatically
<rbasak> I know I've accepted from the queue into proposed before with the caveat of "not in updates until fixed in <future>"
<rbasak> There is talk of having britney do the release to updates, for all the extra britney checking too.
<xnox> it's not actually something we'd want to block on.
<xnox> it is legit for something to be good in one release, and stuck in proposed in another, as long as we sort it out eventually.
<xnox> a separate report for now, would be good enough.
<rbasak> xnox: I'm talking about something different - when the fix isn't in a future release (not even proposed), but the SRU is uploaded to a previous release.
<juliank> the problem if the versioning in an SRU is wrong though, and it's in proposed, is that you can't go back to an older version number AFAIUI
<xnox> rbasak, which is nothing to do with this report.... cause it acts on what's accepted, not what's proposed.
<juliank> i.e. I upload -ubuntu0.1 to bionic, then -ubuntu0.16.04.1 to xenial
<juliank> I'd have to upload -ubuntu0.0.16.04.1 to xenial to fix the mess I created
<rbasak> Oh, I see.
<juliank> xnox: It does show you if the new release has a proposed one though
<juliank> i.e. those would be greyed out a bit
<juliank> in html
<xnox> but like it doesn't look at the queue
<juliank> yeah
<tsimonq2> rbasak: Britney doing the release to updates> Oooh, I'm curious about that. Autopkgtests and all? Or just a seven day aging period plus bug tags being in order? Is there discussion about this somewhere that I could read up on? :)
<rbasak> tsimonq2: AFAIK, it's just something people have mentioned should happen. I don't know that anyone's working on it, and so I don't believe there are any other details.
<xnox> tsimonq2, it is running, and does report adt regressions, but i don't think we actually use "unblock" to release sru
<tsimonq2> That would be cool.
<rbasak> Hmm. On the lines of something being in development -proposed, I have a case where something is in development unapproved but with an SRU ready to go.
<rbasak> I presume that's OK as well, but it'd be nice to see it in cosmic-proposed since then it's "guaranteed" to land.
<rbasak> I wonder if block-proposed and an accept is appropriate?
<rbasak> Or easier if a release team member could review systemd unapproved in Cosmic please?
<rbasak> xnox: do you have a git tree or similar for systemd anywhere? Trying to match up pieces of your delta with the changelog.
<rbasak> xnox: on that point, given you don't mention the patch names in the changelog, it'd be nice if you used Bug-Ubuntu dep3 headers to help match things up.
<xnox> rbasak, no, we don't use dep3 headers, we use git-buildpackage quilt to manage them
<xnox> the git is at
<xnox> rbasak, https://code.launchpad.net/~ubuntu-core-dev/+git/systemd
<xnox> and it is indeed broken by change by commit, and changelog is git-dch managed too
<rbasak> xnox: thanks! Just as I've finished breaking down your upload manually :-/
<rbasak> I'm not sure that's a reason to not have dep3 headers though
<xnox> (the no-dep3 thing kind of comes from debian.... cause their patchset is large, and then we add things ontop and interweb upstream cherrypicks)
<rbasak> You can add dep3 to patches that you add though, surely?
<xnox> rbasak, well there are topics, so upstream cherrypicks are first, then debian topic debian-specific-patches and then debian topic UBUNTU- prefix is ubuntu-specific stuff
<rbasak> eg. debian/patches/core-move-enforcement-of-the-start-limit-into-per-unit-type-code-again.patch has one, just with no Bug-Ubuntu.
<xnox> but gbp pq import/export doesn't process those
<xnox> and they don't end up in the changelog
<xnox> LP: # -> do
<xnox> cause gbp pq, tries to ensure that patches are `git am`ble & `git format-patch`able & dpkg `quilt-applicable`
<xnox> rbasak, if gbp pq gains dep3 support, that would be nice.
<rbasak> Yes but AIUI none of that prevents you from adding Bug-Ubuntu dep3 headers
<rbasak> Put it in the commit message and it'll end up in the quilt patch, no?
<xnox> i'd still have to put in LP: #, as well
<rbasak> Yes you would.
<rbasak> As you would when adding dep3 headers and not using git.
<xnox> have you heard of DRY?! =)
<rbasak> All I'm saying is it makes it difficult to review.
<xnox> LP: # urls are clickable on all ubuntu terminals
<rbasak> dep3 solves the problem, allowing reviewers to match things up.
<xnox> do you not use gnome-terminal?
<rbasak> An LP reference in the changelog doesn't tell me what the corresponding quilt patch is.
<xnox> i'm not sure how dep3 helps here
<rbasak> Some people put the quilt patch name in the changelog entries. You do not, which is fine, but then I'd like dep3 to help me match things up.
<xnox> yeah cause that is only visible in the git repo
<rbasak> Which I didn't have before, and Vcs-Git doesn't point to it.
<rbasak> In any case, AIUI, uploads are expected to follow convention and stand on their own without VCS.
<xnox> sure
<sforshee> LocutusOfBorg: it turns out that the upstream vboxvideo does not have dependencies on vboxguest like I thought, so we can just disable it
<sforshee> I've sent patches to start using the dkms drivers again - https://lists.ubuntu.com/archives/kernel-team/2018-October/095882.html
<sforshee> Odd_Bloke: ^
<xnox> cause like our ./debian/git-cherry-pick script which we use for cherrypicking things from upstream, and injecting it in the right place in the quilt stacks doesn't autogenerate stanzas either
<xnox> as we use plain `git cherry-pick` there
 * xnox ponders if that can grow "better" referencing integration
<rbasak> I don't think it's OK to blame your tooling. As we established, it's trivial for you to add dep3 in your commit messages like everyone else does.
<rbasak> (AFAIK, everyone else using dep3 currently writes them by hand)
<xnox> rbasak, the only patch with dep3 i see, was actually contributed to the upload and was not done by me. and doesn't actually follow systemd packaging conventions.
<xnox> but i tend to take contributions as is, if they apply correctly and work correctly, cause i value their contibutions to systemd packaging.
<xnox> thus dep3 header in that one patch is exception, in systemd, rather than the norm.
<rbasak> xnox: my request still stands. Please use dep3 headers when uploading SRUs, since it makes reviewing easier.
<LocutusOfBorg> sforshee, did you take vboxvideo from which package?
<LocutusOfBorg> I added a kernel 4.18 patch in 5.2.18
<xnox> https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=6a8b3e99b74704b66a5f9422a828f58f532ac3af https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=cc8f39042c5b47bc853b7450f3fe80467dd5897c https://git.launchpad.net/~ubuntu-core-dev/+git/systemd/commit/?id=fd832930ef280c9a4a9dda2440d5a46a6fdb6232
<Odd_Bloke> sforshee: \o/
<Odd_Bloke> sforshee: When might I expect to see that land?
<sforshee> LocutusOfBorg: using the upstream vboxvideo still, as in bionic
<sforshee> Odd_Bloke: can't say for sure, but we'll have to upload it very soon to be in the release
<sforshee> LocutusOfBorg: I updated the drivers from 5.2.18-dfsg-2 in those patches
<LocutusOfBorg> ack
<Odd_Bloke> sforshee: Cool, thanks!
<rbasak> xnox: the AutomountResult enum in src/core/automount.h doesn't form part of any ABI does it?
<rbasak> (or API even)
<rbasak> xnox: same question with {busname,mount,path,service,socket,swap,timer,unit} - it's all the same pattern.
<xnox> rbasak, internally they are enums/states et.al. externally they are all encoded/decoded/shown as a single string.
<rbasak> OK, thanks. As long as the numbers are internal :)
<xnox> rbasak, as per their abi stability guides, they are free to remove/add/change those strings. but it is guaranteed to remain a string.
<rbasak> Thanks. Handy for you to know the answer without me having to dig :)
<xnox> the abi is like `is-failed` which knows which strings are "bad" and which ones are "good"
<xnox> for every unit type.
<xnox> it's meant to be informational
<cyphermox> tsimonq2: thanks for looking at slideshow :)
<tsimonq2> cyphermox: No problem. :)
<dgadomski> mwhudson: hi, could you please also release the fix for bug #1749289 to xenial?
<ubottu> bug 1749289 in ubiquity (Ubuntu Xenial) "Installer stops after pressing Cancel on Select a language screen during OEM install" [Undecided,Confirmed] https://launchpad.net/bugs/1749289
<ogra> vorlon, identity crisis ?
<vorlon> stuck settings in the client that I'm trying to shake loose
<rbasak> Would it be acceptable in Ubuntu for a package to dynamically add an extra binary package not listed in debian/control through debian/rules? The reason is that I want to keep in sync with Debian but build an extra split out binary package to stay in universe.
<rbasak> (in Debian this wouldn't happen so I don't think there's an issue there)
<tsimonq2> Why is it not possible to list it in debian/control?
<rbasak> Because it wouldn't be appropriate to build the binary package on Debian.
<sarnold> wouldn't taht just turn into a delta in debian/rules?
<rbasak> Yes it would.
<rbasak> But we do that already in other places, using dpkg-vendor
<tsimonq2> Ohh, I catch your drift.
<rbasak> Means that Debian and Ubuntu build from the same source, which is convenient. Saves doing merges etc.
<tsimonq2> That personally sounds doable but I guess I'd defer to an archive admin. :)
<sarnold> I dislike it, but not enough to be annoying about it. :)
<tsimonq2> ^
<rbasak> ISTR someone saying that Debian disallowed this. But it might be OK for Ubuntu. The only reason to do this is caused by Ubuntu's main/universe distinction.
<rbasak> I think the alternatives is for sarnold to +1 our MIR from a security perspective, or to keep doing package merges forever.
<sarnold> heh, which one? :)
<rbasak> bug 1781529
<ubottu> bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New] https://launchpad.net/bugs/1781529
<tsimonq2> As someone once said, "Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy." so I guess I'd be curious to say if Policy has a specific rule around it. :)
<sarnold> aha, dunno if I can get there today or not. I didn't sleep well last night :/
<rbasak> I'll finish writing my reply. My question was prompted in writing a reply :)
<sarnold> haha :)
<tsimonq2> rbasak: Oh, I just recalled that dbgsym packages aren't mentioned in d/control.
<tsimonq2> So while they're "special" packages, it should mean that it's permissible under policy.
<rbasak> Reply written in the bug.
<rbasak> vorlon or infinity: ^ please could you tell me if this is acceptable? See bug 1781529 comment 7.
<ubottu> bug 1781529 in mecab (Ubuntu) "[MIR] mecab" [High,New] https://launchpad.net/bugs/1781529
<tsimonq2> infinity: ^ (since, if I recall correctly, he only gets pings if the message starts with his name.)
<sarnold> rbasak: very nice reply, thanks :)
<rbasak> sarnold: thanks. Over to you I guess? If you want to nack the MIR on security grounds, that's fine - we'll find some way, and if we can't, we'll either continue merging or continue without mecab support.
<vorlon> rbasak: binary packages produced by a source package are expected to be listed in the debian/control shipped in the source package
<rbasak> vorlon: "expected", or "must"? I'm aware of the expectedness; that's why I'm asking :)
<vorlon> rbasak: must
<rbasak> OK, thanks
<vorlon> it's bad to have packages listed in debian/control that you never build, but that's less bad than building packages you don't list in debian/control; the latter breaks cross-references in the indices
<rbasak> I could list it in debian/control and then never build it, but then I'd be foisting that on Debian, which seems inappropriate.
<xnox> vorlon, nvidia-* packages currently shadow each other ;-)
<vorlon> xnox: yes; which is permitted for the same reason it's permitted for gccs, you shouldn't have to reupload the old package in order for a new package to take over its binaries
<vorlon> mdeslaur: why did woff2 have a no-change rebuild in bionic-security? should we copy it forward to cosmic? (cf juliank's post)
<juliank> vorlon: he did upload 1.0.2-1build1 to cosmic a few hours or so ago
<vorlon> ah, well then
<vorlon> still wondering what the no-change rebuild was for :)
<juliank> Yeah, it would have been useful to have "for ..." in the changelog
<sarnold> iirc it was so that we could do a security update on webkit2gtk https://launchpad.net/ubuntu/+source/webkit2gtk/+changelog
<jbicha> vorlon: we moved woff2 to main
<vorlon> ah
<vorlon> moving to main does not require a rebuild, only a pocket copy
<jbicha> ok, good to know. We don't do it very often :)
<mdeslaur> vorlon: if you only do a pocket copy, you break ubuntu-support-status
<vorlon> oh?
<vorlon> ok
<mdeslaur> since the installed package on people's systems still comes from universe
<jbicha> vorlon: if you have time, brotli binaries need to be moved to main in xenial too LP: #1795077
<ubottu> Launchpad bug 1795077 in brotli (Ubuntu Xenial) "Backport brotli 1.0.3 to Ubuntu 16.04 LTS" [Medium,Fix committed] https://launchpad.net/bugs/1795077
<jbicha> and woff2 (SRU wasn't accepted yet) LP: #1795094
<ubottu> Launchpad bug 1795094 in woff2 (Ubuntu Xenial) "Backport woff2 to Ubuntu 16.04 LTS" [Medium,In progress] https://launchpad.net/bugs/1795094
<sarnold> jbicha: do we really? I thought webkit2gtk added new toolchain dependencies that meant we can't support it in trusty any longer?
<jbicha> sarnold: we never announced that webkit2gtk/xenial was unsupported so maybeâ¦
<jbicha> latest webkit requires gcc6 and no one's volunteered to backport that to xenial yet
<jbicha> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
<mdeslaur> it's a bit more complicated than that...we can't just backport gcc6
<mdeslaur> the stdlibc++ library on xenial is provided by gcc5
<jbicha> I admit I don't know what that library means
<rbasak> coreycb: would you prefer me to wait for neutron in bug 1795424 before reviewing? Or are you happy with releasing bits at a time?
<ubottu> bug 1795424 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1795424
<rbasak> coreycb: or, given they all get tested together, maybe it's better to wait in the general case?
<coreycb> rbasak: thanks for taking a look. i'd really like to include neutron as it has some critical bug fixes.
<coreycb> rbasak: it's all regression tested, i think we can mark the remaining neutron bug as verification-done since it passed regression testing.
<rbasak> coreycb: there's still two more days left to age for neutron
<coreycb> rbasak: ah, right. well i think you can hold off and we can get those all released together fri or mon.
<rbasak> OK, thanks.
<coreycb> rbasak: thanks
<rbasak> coreycb: it'll be Mon. We generally don't release on Fridays.
<coreycb> rbasak: ok makes sense
<rbasak> juliank: I appreciate the impact statement in bug 1796081 :)
<ubottu> bug 1796081 in dpkg (Ubuntu Bionic) "dpkg frontend locking" [Undecided,In progress] https://launchpad.net/bugs/1796081
<vorlon> jbicha: brotli overrides done
<jbicha> thanks
<mwhudson> dgadomski: oh i didn't realize it affected xenial too
<mwhudson> dgadomski: is it in git for xenial yet?
<xnox> libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include -I../.. -g -O2 -DNDEBUG -DZDOT_RETURN -c _hrr_c0_66.cc -o _hrr_c0_66.o
<xnox> virtual memory exhausted: Cannot allocate memory
<xnox> but builds fine in debian.... compiler bug? PIE or some such making it explode?
<xnox> mwhudson, vorlon, doko - any suggestions on where to go from here?
<mwhudson> !?
<mwhudson> xnox: package, architecture, etc?
<xnox> bagel, all arches
<xnox> cosmic
<xnox> did --no-parallel build in xnox/nonvirt ppa and also fails on all arches
<mwhudson> huh
<vorlon> yeah, virtual memory exhausted would seem to imply you're out of address space rather than out of physical memory
<mwhudson> sounds compiler bug-like to me
<vorlon> and the compiler in question is... mpicxx?
<mwhudson> what is mpicxx? mpi as in the multi process thing?
<mwhudson> yes, seems so
<xnox> yeah, openmpi implementation c++ compiler....
<mwhudson> xnox: tried locally?
<mwhudson> it's a different version of libmpich-dev, 3.3~b2-6  vs 3.3~b2-7build1
<xnox> mwhudson, well can't remember now. rerunning build in unstable chroot; then will rerun build in our chroot; then will see if libmpich-dev makes a difference.
<mwhudson> changes between the versions are trival so it would only be if mpicxx built with gcc-8 is broken or some such fun
#ubuntu-devel 2018-10-11
<dgadomski> mwhudson: yes, it's in xenial branch on https://git.launchpad.net/ubiquity
<realitix> Hello, I tried this patch and it works great, if Nish Aravamudan is here, can you merge it ? https://bugs.launchpad.net/ubuntu/+source/tomcat8/+bug/1644144
<ubottu> Launchpad bug 1644144 in tomcat8 (Ubuntu Xenial) "Tomcat 8.0.32 has ClassLoader Issues" [Medium,In progress]
<rbasak> sil2100: o/ thank you for opining on the openscap bug. I think your points are quite convincing, and I'm inclined to accept the SRU now. Do you have any objection? I wondered if it was within the SRU's remit to make this decision, but as you point out all fixes are regressions for people relying on broken behaviour, so I think that making that decision is an SRU team judgement call now.
<sil2100> rbasak: I don't think I have any objections to accepting it - as I said I also have mixed feelings, but saw this potential 'invalid usage' case here. If you have the same feeling here, I guess it should be good to go to -proposed
<rbasak> OK, thanks
<cpaelzer> rbasak: waveform: I depleted my py-foo - is one of you around that could help me debug a hang in a cpython  .so  (bug 1797324)?
<ubottu> bug 1797324 in update-manager (Ubuntu) "Software Updater show empty panels, stuck in ProblemResolver.resolve of apt_pkg.cpython-36m-x86_64-linux-gnu.so" [Undecided,New] https://launchpad.net/bugs/1797324
<TJ-> cyphermox: shim-signed (1.37~18.04.2+15+1533136590.3beb971-0ubuntu1) in bionic-proposed declares Depends: "shim (= 13-0ubuntu2)" - shouldn't that be "shim ( = 15+1533136590.3beb971-0ubuntu1)" ? Users reporting the package is listed by "apt list --upgradable" but never upgraded .
<waveform> cpaelzer, I can take a quick look if you want?
<cpaelzer> waveform: I'm about to leave for lunch
<cpaelzer> waveform: would you be available for a HO later on
<waveform> sure - ping me when you want
<cpaelzer> we could look together with me sharing the console
<cpaelzer> ok, also need to sort a virsh thing - will ping you
<cpaelzer> thanks for the offer
<waveform> no prob :)
<cpaelzer> waveform: I'd be back
<waveform> cpaelzer, right - I'm here (got tea :)
<cpaelzer> I sent you a HO link in a query
<cpaelzer> whenever you are ready
<TJ-> cpaelzer: did you see the last comment on your bug about a possible fix?
<cpaelzer> not yet TJ, refreshing
<cpaelzer> TJ-: rbalint_: it doesn't exactly look like the same problem, but I'll ive it a try still after the debugging session we have atm
<cpaelzer> rbalint_: do you have a ppa of that somewhere or do I have to put the one in -unapproved into one?
<rbalint> cpaelzer, but if sil2100 could process it in his sru shift today ... :-) (update-manager)
<rbalint> cpaelzer, i don't have it in ppa, sorry
<cpaelzer> it is in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3472 now
<sil2100> rbasak: will try, but I'm a bit busy busy this week - will hand it over to someone else if I don't make it today
<rbasak> rbalint: I think that was for you ^
<rbalint> rbasak, it could be you, too ;-)
<rbasak> :)
<rbasak> pitti: hi! Would you mind taking a glance at bug 1796407 please? I think I understand the report and I'm treating it as effectively a feature request, but wondered if you had any comment.
<ubottu> bug 1796407 in postgresql-common (Ubuntu) "pg_wrapper doesn't work when -p is used" [Wishlist,Triaged] https://launchpad.net/bugs/1796407
<pitti> rbasak: hello! ugh, that's been a while, I'll need to spend some time to get into that code again; I kept a tab for it as a reminder
<rbasak> Thanks!
<cyphermox> TJ-: shim-signed it is supposed to be =15~ etc.; it had failed to build due to the messing around we did with a revert, looks like the right stuff is in -updates right now...
<cyphermox> no, I'm thinking of xenial with the ftbfs
<cyphermox> anyway, shim looks like it's in place and has the right Depends...
<TJ-> cyphermox: I wasn't sure but the user was getting such weird symptoms I wondered if that may be responsible
<cyphermox> well, if it says =13 it's clearly wrong
<TJ-> cyphermox: I think I misread the user's "apt-cache show" - it listed for multiple versions and only captured the last one, which was for shim-signed 1.34.9+13-0ubuntu2
<TJ-> cyphermox: so that wasn't the cause of the user problem then
<cyphermox> no, the problem is something else
<cyphermox> shim-signed was promoted, but not shim
<cyphermox> that's what the problem is
<TJ-> cyphermox: ahhh, that was my other thought but local apt-cache policy seemed to show both packages matched versions in bionic-proposed
<cyphermox> in proposed, yes, but not in updates
<TJ-> cyphermox: ahhh! good point, the user may not have -proposed enabled. doh! should have thought of that.
<cyphermox> it became really noticeable, I can't deploy bionic in maas.
<bdmurray> Laney: Did you see my comment on bug 1797384?
<ubottu> bug 1797384 in ubuntu-release-upgrader (Ubuntu) "release upgrader has no icon in gnome-shell dock" [Undecided,New] https://launchpad.net/bugs/1797384
<Laney> bdmurray: no, but yes that'd probably be fine :-)
<tjaalton> hum, a qemu vm clone still gets the same ip from dhcp even though the hostname changed
<tjaalton> and mac
<tjaalton> ah, because of /etc/machine-id
* Unit193 changed the topic of #ubuntu-devel to: Archive: Final Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots:
#ubuntu-devel 2018-10-12
<rbasak> xnox: thank you for the certbot snap issue. Sorry I only just noticed it - I need to sort out the email to which my GitHub account is linked.
<xnox> rbasak, no worries! basically mostly care because i do use arm64, and because their provided ppa is crap and has way too many backports of things which simultaniously breaks aws APIs python libraries.
<xnox> (as shipped in xenial & bionic, i guess aws APIs snap would be fine, but currently use the system one)
<rbasak> That's interesting. I'd appreciate more detail on that, because I want them to take on the snap, so it'd be useful to identify genuine shortcomings in their current approach.
<rbasak> Especially because they're currently reviewing how they recommend/provide deployment
<rbasak> xnox: could you file that as a bug upstream perhaps?
<xnox> there is one
<xnox> https://github.com/certbot/certbot/issues/5234
<tarzeau> what would be the reason for ubuntu cosmic to not pick up mm3d 1.3.10 from debian?
<tarzeau> and cloudcompare, colmap updates?
<xnox> tarzeau, as per https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseSchedule automatic imports from debian stopped on 23rd of August, the date of Debian import freeze.
<xnox> tarzeau, mm3d was uploaded on 8th of September.
<xnox> others probably similar?
<xnox> none of them are seeded, so it might make sense to sync them in....
<TJ-> doko: could you glance at the libc6-armhf-cross unpack failures in bug #1797557 - appears to be caused by the Bionic cross-toolchain upgrades in Bug #1769657
<ubottu> bug 1797557 in cross-toolchain-base (Ubuntu) "Bionic updates break upgrade/install/unpack" [Undecided,New] https://launchpad.net/bugs/1797557
<ubottu> bug 1769657 in gcc-defaults-ports (Ubuntu) "update toolchain packages for bionic" [Undecided,New] https://launchpad.net/bugs/1769657
<tarzeau> ahhhh for 18.10... i forgot about that
<xnox> tarzeau, would you want me to sync them into cosmic? or are they good enough as it is?
<tarzeau> xnox: the cloudcompare -2 revisions enables plugins and it's much better
<tarzeau> xnox: protracker sync would be great also (-140 in debian, not in testing yet)
<tarzeau> xnox: for colmap i'm not sure, you can try
<tarzeau> and mm3d would also be great to have the 1.3.10 (new upstream fixes lots of bugs)
<xnox> colmap - has a new binary =/ so might get stuck in NEW review.
<tarzeau> xnox: pushover sync would be great too
<tarzeau> xnox: skip it then
<tarzeau> thanks a lot! let me check what other things would be useful for users
<tarzeau> ah modplugtools -3 uses libopenmpt instead of libmodplug
<tarzeau> what about packages in debian experimental non-free, they don't get synced at all, right?
<tarzeau> qtractor 0.9.2-1 would also be good
<xnox> tarzeau, experimental is not synced no. but you can use $ requestsync from ubuntu-dev-tools to open standardized launchpad bugs to do so.
 * tarzeau installs ubuntu-dev-tools to try requstsync
<xnox> it needs a launchpad account, and will authenticate with launchpad. i hope you do have a launchpad account.
<xnox> but otherwise it is API / command line driven.
<tarzeau> yes i'm lenin
<tarzeau> if you can sync ballerburg too, it comes with .desktop menu system now
<tarzeau> xnox: did you take care of the syncs, or should i do anything else?
<xnox> tarzeau, they have been accepted, you should be able to see their progress at https://pad.lv/u/PKG
<xnox> tarzeau, they need to build / publish / pass autopkgtest / pass britney before they migrate, if they migrate.
<xnox> tarzeau, i think i got most of them.
<tarzeau> xnox: yay very cool! thank you.
<tarzeau> xnox: so for protracker (i added an appstream data file, i wonder if it appears in the gnome software thing)
<xnox> juliank, Laney filed this https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1797579 including a funny looking patch
<ubottu> Launchpad bug 1797579 in ubiquity (Ubuntu) "ubiquity removes packages for non-en_US english locales" [Undecided,New]
<xnox> juliank, could you look at that?
<Laney> come to #ubuntu-installer
<xnox> juliank, we have been discussing things in #ubuntu-installer, but you are not there =)
<Laney> that's The Place
<wxl> infinity: i bet you know the answer to this: we need to use `gio` to set an attribute of our installer's .desktop file, preferably before the desktop session starts. how do we go about this?
<wxl> calasettings is in
<wxl> i'm going to lunch
<wxl> could you rebuild images when lximage-qt is in release, @tsimonq2 ?
<wxl> aw heck wrong channel
 * wxl cries
<tsimonq2> wxl: If I'm awake.
<tsimonq2> Still recovering :(
<caravena> Cool!!! -> https://wiki.ubuntu.com/Bugs/Responses
<wxl> vorlon: you have any ideas on the question above re: needing to set file metadata on the installer .desktop file on our iso?
<vorlon> wxl: I have no idea what that refers to or why it would be needed
<vorlon> an "attribute"?  like a filesystem xattr?
<wxl> vorlon: no, the backlog would help but to reiterate, i need to set `metadata::trusted` with `gio`. it's something that pcmanfm-qt uses to allow one to just double click on an executable and run it rather than giving a dialog that asks if you want to execute or open (i.e. edit)
<wxl> vorlon: i'm no gio expert, but as i grok it that's hidden away in the virtual file system, so it's not like i can just copy over some config file
<jbicha> wxl: look in casper's package, scripts/casper-bottom/25adduser
<jbicha> https://git.launchpad.net/ubuntu/+source/casper/tree/scripts/casper-bottom/25adduser#n81
<wxl> oh hah that's exactly what i need!
<wxl> so i just need to add calamares.desktop to the for and i'm done. cool. thanks jbicha !
<jbicha> casper-bottom is where most of the config is for stuff that only affects the live system on the iso
<juliank> xnox, Laney sounds scary. do you think it's related to my minimizing stuff?
<juliank> probably should discuss this closer on Monday, I joined #ubuntu-installer now
<tarzeau> gnome-software and plasma-discover miss a feature called "community support", like add missing description, icon, screenshot for locally installed packages (an easy way to fill out, and submit)
<tarzeau> half of the packages installed at my place show the brown box icon and well, nothing else
<xnox> juliank, possibly
<xnox> juliank, cause i don't think ubiquity learned to mark those lang packs as manual installed
<xnox> if they happen to be pre-installed in the livefs and still needed post-install
#ubuntu-devel 2018-10-13
<wxl> no, that installs it
<wxl> but do see that code installs those to Desktop?
<wxl> ugh stupid /etc/skel
<wxl> everytime i hear that i just want to strangle agaida
<wxl> in any case, that's kind of a problem
<wxl> it will have to happen after the copy over
<wxl> so somewhere i need to run a `gio` command to the in-place file before the session (well, pcmanfm-qt) starts
<wxl> so tell me where to point at
<wxl> i guess i could do a postinst
<wxl> you blocked at all? see `rfkill`
 * Unit193 taps on wxl.
<wxl> ughhhhhhhhhhhhhhhhhh
<Unit193> Should really learn to use your IRC client. :)
<jbicha> wxl: I believe that's what that file already does
<wxl> jbicha: wrong channel, sadly (for me)
<jbicha> you're not still talking about the calamares gio thing?
<wxl> i am but that was all meant for #lubuntu-devel. we had to hash a few things out first before coming up with the final solution
<jbicha> ok have fun :)
<wxl> thanks. your help at least led me in the right direction jbicha.. just needed another step first
#ubuntu-devel 2018-10-14
<jbicha> mitya57: please consider adding ubuntu-core-dev to https://launchpad.net/~ubuntu-gnome-flashback
<jbicha> I needed to do a rebuild of gnome-panel & wanted to push my change to the git repo
<mitya57> jbicha: I invited ubuntu-core-dev. Not sure who can approve it now, maybe the DMB?
<jbicha> done. Thanks! :)
<mitya57> I forgot that you are a DMB member. So thanks to you too :)
<xnox> rbasak, dpkg-source --commit is how i write manual patches, and that auto-generates Bug-Debian and Bug-Ubuntu lines. they are not written by hand, they come processes from the debian/changelog.
#ubuntu-devel 2019-10-07
<popey> tseliot: good morning - bug 1846995 hit me when going 19.04 to 19.10 - Seems dkms problems with the kernel in 19.10
<ubottu> bug 1846995 in nvidia-graphics-drivers-390 (Ubuntu) "package nvidia-dkms-390 390.129-0ubuntu1 failed to install/upgrade: installed nvidia-dkms-390 package post-installation script subprocess returned error exit status 10" [Undecided,New] https://launchpad.net/bugs/1846995
<tseliot> popey, good morning to you. Let me have a look
<rbasak> waveform: o/
<waveform> rbasak, hi!
<rbasak> waveform: how's u-boot looking?
<waveform> rbasak, good - fixed up the CM3 issue and retested everything (2, 3, 3+, 4, CM3, CM3+ on armhf and arm64) over the weekend. Just finishing off the last couple of bits from your review at the mo, though I might prod you with a couple of questions in a bit
<rbasak> Great, thanks!
 * rbasak is just planning his week
<tseliot> popey, I know where the problem lies. It's the new compiler flags. I am not sure why this isn't fixed in the kernel. sforshee ^^
<popey> tseliot: thanks. is there a workaround? I'm kinda stick mid-upgrade now.
<tseliot> popey, yes, set gcc-8 as your compiler ("sudo ln -fs gcc-8 /usr/bin/gcc"), and try again
<popey> tseliot: thanks, will try that
<popey> tseliot: that worked, thank you!
<tseliot> :)
<LocutusOfBorg> is syncpackage broken?
<LocutusOfBorg> syncpackage -f fswatch returns
<LocutusOfBorg>   ubuntutools.archive.DownloadError: Signature on fswatch_1.14.0+repack-12.dsc could not be verified
<LocutusOfBorg> not sure if LP is to blame or something else is broken...
<seb128> LocutusOfBorg, I think the script is buggy in eoan, I've hit that issue, it works on other Ubuntu series still iirc, I ended up hacking the .py locally to skip the verification or using my other laptop on bionic...
<LocutusOfBorg> seb128, I'm using bionic, but my ubuntu dev tools is updated...
<LocutusOfBorg> mapreri, ^^
<RikMills> tseliot: is this known? https://www.reddit.com/r/Ubuntu/comments/deij1t/errors_when_i_tried_to_upgrade_to_ubuntu_1910/
<RikMills> tseliot: I guess the upgraders are hitting this LP: #1845772
<ubottu> Launchpad bug 1845772 in nvidia-graphics-drivers-430 (Ubuntu) "package nvidia-dkms-430 430.50-0ubuntu1 failed to install/upgrade: installed nvidia-dkms-430 package post-installation script subprocess returned error exit status 10" [High,Confirmed] https://launchpad.net/bugs/1845772
<jibel> RikMills, it's a stock disco upgraded to eoan with nvidia drivers?
<RikMills> jibel: just went to ask and they have deleted their post. I'll try an upgrade later to see if I can hit it
<jibel> RikMills, k, keep me posted
<tseliot> RikMills, the bug report shows that the module failed to build. I suspect it's because of the new flags in gcc 9
<RikMills> tseliot: I just reproduced it in a disco -> eoan test upgrade
<tseliot> RikMills, can upload your make.log to the bug report, please?
<tseliot> e.g. /var/lib/dkms/nvidia/430.50/build/make.log (it depends on the driver you're using)
<RikMills> tseliot: will do.
<RikMills> make.log added
 * tseliot looking
<tseliot> RikMills, it's definitely LP: #1830961
<ubottu> Launchpad bug 1830961 in nvidia-graphics-drivers-430 (Ubuntu) "Kernels & kernel drivers fail to build with gcc-9 [error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible]" [Critical,Fix released] https://launchpad.net/bugs/1830961
<RikMills> tseliot: thanks :)
<RikMills> so jist of that is we need the kdernel fix backported to 19.04 before 19.10 gets released?
<RikMills> *kernel
<RikMills> umm. yep
<waveform> rbasak, fyi - I've just replied on the ticket to all the review points and I'm currently testing an updated version of the package
<repz> hi there, does anybody know if it's possible to retrieve CI / build steps for a package on launchpad ?
<repz> I can only retrieve the buildlog
<sarnold> what is missing from the build log?
<repz> buildlog is 'only' the output of the build
<repz> not compilation steps
<repz> or I am missing something
<sarnold> repz: well, which build log are you looking at now and what information is it missing that you expected to find?
<repz> I am looking for zsh build log but I am seeing that everything is packed through a specific builder, I thought there would be a 'simple' CI file. (I am discovering the official package building process atm).
<sarnold> repz: are you looking for autopkgtest results? eg http://autopkgtest.ubuntu.com/packages/zsh
<repz> no, basically I wanted to compile zsh to get latest version and I wanted to check how it's being officially packed first
<sarnold> aha; if you have the deb-src lines in your apt sources configured correctly, "apt source zsh" will download the files needed to build it yourself
<repz> oh thanks but im not sure as of what to do next neither where it's been downloaded ?
<repz> ok in current directory
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
#ubuntu-devel 2019-10-08
<seb128> hum, some autopkgtest seem to be failing due to 'rules extract failed with exit code 1' errors, does anyone know what's that's about? e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20191008_021409_ed1a2@/log.gz
<seb128> Laney, juliank, vorlon, ^ do you know?
<seb128> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/f/flatpak-builder/20191007_190748_9c67a@/log.gz is another one with another package
<juliank> seb128: looking
<seb128> hey juliank, thx
<juliank> seb128: I can't find that phrase in the code, ugh
<juliank> so I'm confused :D
<juliank> ah found i
<juliank> it's rules %s failed
<seb128> what is a rule in this context?
<seb128> it seems to just want to unpack a source from the archive
<juliank> seb128: it's a complex shell/awk script combo that's embedded int he autopkgtest code
<seb128> did it change recently?
<juliank> seb128: i see a change from ddstreet on sep 26 for https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1845157
<ubottu> Launchpad bug 1845157 in autopkgtest (Ubuntu) "runner/autopkgtest fails to setup env with binary packages moved to another packge, and different source/binary versions" [Undecided,Fix committed]
<juliank> seb128: this commit https://salsa.debian.org/ci-team/autopkgtest/commit/020ec6285a836d20ab799742649712f7224d61c8
<seb128> pitti, ^ is that a regression from that commit
<juliank> I really should make it print the output of the failing script
<pitti> seb128: bonjour, Ã§a va ?
<juliank> seb128: acked in debugging, rerunning
<seb128> pitti, salut, trÃ¨s bien et toi ?
<pitti> seb128: Dan indeed found a regression, he sent a follow-up to fix it
<seb128> juliank, thx
<seb128> pitti, ah, would it match those  'rules extract failed with exit code 1' errors I mentioned before?
<pitti> seb128: je vais bien aussi ! on a passÃ© un grand week-end dans les Alps
<seb128> ah, chouette :)
<pitti> seb128: hmm, I don't think so -- he sent https://salsa.debian.org/ci-team/autopkgtest/merge_requests/64
<pitti> which would be about grabbing a binary package from the wrong source
<seb128> ah
<seb128> pitti, the error I saw are like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20191008_021409_ed1a2@/log.gz
<juliank> ok https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/ppc64el/s/systemd/20191008_073006_b5371@/log.gz
<seb128> 'autopkgtest [02:13:58]: @@@@@@@@@@@@@@@@@@@@ apt-source systemd
<seb128> blame: systemd
<seb128> badpkg: rules extract failed with exit code 1'
<seb128> juliank, ah
<seb128> pkgs=
<seb128> not good :p
<juliank> So the awk returns no result
<pitti> I don't think that systemd has that complex "same binary from different sources on different architectures" structure
<pitti> I merged Dan's fix in the meantime
<pitti> I suggest running the command locally with -d, to see what it's doing
<pitti> the log has the exact command line for that reason
<seb128> pitti, julian just did that in the url he shared
<seb128> seems like he's debgging now so let's see if he figures out why the awk call is return an empty set
<juliank> I cherry picked that commit, and will retry now
<juliank> the binaries are all linux-any so it makes sense they fail
<juliank> sort of
<juliank> also that's what was discussed in #ubuntu-release last night
<seb128> juliank, let me know if/when you test if that fixes it so I can retry other things :)
<juliank> seb128: well, systemd on ppc64el is still running, so it seems fine
<seb128> juliank, it's taking longer than the previous try for sure, good sign then :)
<juliank> seb128, Laney: I rebased our branch in https://code.launchpad.net/~juliank/autopkgtest/+git/development/+merge/373801 and pushed that to the (cloud) worker, please reset branch to it
<juliank> seb128: FWIW, I need to apply this on armhf lxd builder too
<Laney> yeah they were fixing that when I left off last night
<juliank> and done
<Laney> good that it got done :>
<juliank> I forwarded both workers to that branch
<Laney> the branch format that LP generates
<Laney> with a : separating the repository and branch name
<Laney> is it possible to paste that into git somehow?
<juliank> no
<juliank> you gotta replace the : with a space and then pass it to git fetch
<juliank> or pull
<Laney> right
<Laney> that's what I do
<Laney> I was just wondering if there was some trick I didn't know, which is why LP renders it in that way
<cjwatson> No, I picked that format as a concise way to represent the repository/branch combination that also made sense when rendering things like lists of merge proposals
<cjwatson> IIRC GitHub uses a similar format
<cjwatson> git has no native equivalent that doesn't involve awkward spaces so it was a compromise
 * Laney nods
<jamespage> doko: looking that that pbr test regression for python-defaults - python-stestr py2 support was dropped via autosync from debian afaict
<jamespage> which is blocking the autopkgtest and rebuilding the package
<jamespage> choices are - drop py2 support from pbr (lots of reverse-depends still, near release so discounted), drop py2 testing from python-pbr (minimal change, unblocks proposed)
<doko> jamespage: I'd say reduce the testing ...
<jamespage> doko: agreed - its the minimal impact change for this point in the cycle - just uploaded
<jamespage> I'm not quite sure how python-stestr got into the release pocket bearing in mind there where still reverse-build-depends
<jamespage> but hey ho
<cjwatson> I don't think proposed-migration considers build-depends
<doko> and autopkg test dependencies either
<mwhudson> i don't think britney looks at Sources at all does it?
<mwhudson> oh no, it does
<mwhudson> not sure what for, mind
<RikMills> jibel: LP: #1847228
<ubottu> Launchpad bug 1847228 in ubiquity (Ubuntu) "Installer crashes at partitioning stage" [Undecided,New] https://launchpad.net/bugs/1847228
<RikMills> looks like impact of the xfs changes on KDE front end
<RikMills> s/xfs/zfs
<jamespage> doko: we're seeing https://bugs.python.org/issue38368 from python-pysnmp4 under the 3.7 rc in eoan
<jamespage> sahid: I've updated https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1847036 with those details
<ubottu> Launchpad bug 1847036 in python3.7 (Ubuntu) "changeme.py crashed with SIGSEGV" [Undecided,New]
<doko> ok
<jamespage> doko: https://bugs.launchpad.net/ubuntu/+source/python3.7/+bug/1847036 covers it
<ubottu> Launchpad bug 1847036 in python3.7 (Ubuntu) "changeme.py crashed with SIGSEGV" [Undecided,New]
<doko> jamespage: yes, I also something similar in python-ipaddress
<RikMills> jibel: in kubuntu, the minimal install option has also vanished
<Laney> known
<Laney> we've been discussing it in #ubuntu-desktop
<RikMills> Ah, I missed that. Sorry. There has been a lot of chat in there this morning
<Laney> stupid installers /o\
<mwhudson> maybe we can just ship ssds with ubuntu on to everyone
<Laney> mail -s "great idea to reduce installer development costs" mark@ubuntu.com
<rbasak> xnox: another claimed fallout from the OpenSSL Bionic update: bug 1832998. Please could you take a look?
<ubottu> bug 1832998 in pure-ftpd (Ubuntu) "Pure-FTPd Breaks with OpenSSL v1.1.1" [Undecided,Confirmed] https://launchpad.net/bugs/1832998
<xnox> rbasak:  sure
<rbasak> Ta!
<xnox> rbasak:  upstream refactored and fixed everything in .48, fedora disabled tlsv1.3 at first, and then backported all the fixes.
<xnox> rbasak:  not sure if those backports apply cleanly to 46
<xnox> rbasak:  i am thinking to just disable tlsv1.3 with a smalish patch
<rbasak> xnox: sounds reasonable
<rbasak> Especially to fix the regression - if someone wants to work harder to enable it later, then we could do that as a separate future upload
<rbasak> mdeslaur: ^ any opinion please?
<mdeslaur> disabling tlsv1.3 sounds reasonable to me too
<rbasak> Thanks!
<paride> cpaelzer, what do you think of qemu-system-X recommending (=> installing by default) qemu-system-gui, which in turn has a bunch of GUI related dependencies (gtk, fonts, x11 stuff...)?
<cpaelzer> paride: I think that is how we recently do it
<cpaelzer> paride: there was a bug, it sounds familiar
<paride> cpaelzer, found it https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789670
<ubottu> Launchpad bug 1789670 in qemu (Ubuntu) "qemu-system-* Recommends qemu-system-gui" [Wishlist,Won't fix]
<cpaelzer> yep, the default is make it work nice
<cpaelzer> people interested in minimizing can remove it (as it is a recommends)
<cpaelzer> wow was that discussion that long ago ...
<paride> almost 1 year :)
<rcj> Can I get a sponsor for https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1847300 as I can't do the merges/uploads?
<ubottu> Launchpad bug 1847300 in livecd-rootfs (Ubuntu) "[backport] magic-proxy: dump proxy log to stdout on failure" [Undecided,New]
<rcj> Can I get a sponsor for https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1847300 as I can't do the merges/uploads?
<rcj> whoops (sorry on the double post)
<rbasak> thedac: o/
<rbasak> thedac: any chance you can retest from my PPA please?
<rbasak> thedac: this one is very close to my intended upload to the archive today/tomorrow for Eoan.
<thedac> rbasak: Sure, I'll kick off a test right now.
<rbasak> Thanks!
<Odd_Bloke> Can packages in main Recommend packages in universe, or does that prompt promotion of the Recommend'ed package?
<Laney> The second one :(
<Odd_Bloke> Thanks!
<infinity> Odd_Bloke: Recommends prompts promotion because we install recommends by default, and we don't want the behaviour to change depending on if you did or didn't enable universe.
<infinity> Odd_Bloke: Suggests doesn't prompt promotion because it's not installed by default.
<Odd_Bloke> Yep, makes sense!
<Odd_Bloke> Thanks! :)
<infinity> rcj: Why have you not at the very least applied for PPU for livecd-rootfs by now? (or, roll up your sleeves, get a little dirtier in the archive in general, and go for core-dev)
<infinity> rcj: Which is to say, sure I can look at those MPs and sponsoring, but also, SLAAAAACKER.
<thedac> rbasak: 8.0.17-0ubuntu2~dev2 for mysql-server-8.0 and mysql-router looks good to me. My tests pass.
<rcj> infinity: thank you on both counts
<infinity> rcj: I've never been thanked for calling someone a slacker before.  This is new territory.
<rcj> I keep telling myself that I've been too busy but it's annoying me and I just need to make time.
<rcj> And if I had PPU for livecd-rootfs I wouldn't be wasting you on sponsorship when I need an SRU for this infinity ;)
<vorlon> infinity, kees, stgraber, mdeslaur: TB meeting in 10?  (we have agenda items)
<mdeslaur> ack!
<kyrofa> Hey juliank, we chatted a few weeks back about https://bugs.launchpad.net/ubuntu/+source/urdfdom-headers/+bug/1817595 . It should be in a better state now, and Jose is a DM and is happy to help with any autopkgtest regressions that may pop up with it
<ubottu> Launchpad bug 1817595 in urdfdom-headers (Ubuntu Bionic) "[SRU] urdfdom-headers and urdfdom should not use locale dependent parsing for floating point numbers" [Undecided,Confirmed]
<juliank> kyrofa: sponsored
<kyrofa> Thank you juliank :)
<Odd_Bloke> rcj: You still need the SRU team and AAs even with PPU, so it's not a surefire way of avoiding infinity. ;)
<rcj> Odd_Bloke: I don't want to avoid infinity, I just don't want to waste him unnecessarily.  Also, I'd like to scratch my own itches.
<seb128> cking, hey, would be nice if you reported your gnome-calendar/disk issue upstream on https://gitlab.gnome.org/GNOME/gnome-calendar/issues
<mwhudson> can i get a core-dev review on https://code.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/+merge/373789
<juliank> mwhudson: lgtm
<rbasak> xnox: here's another one incoming via ddstreet: bug 1799345
<ubottu> bug 1799345 in sylpheed (Ubuntu Eoan) "Sypheed not (or no longer) using SNI for SSL connections" [Medium,In progress] https://launchpad.net/bugs/1799345
<rbasak> Do we have a tag for these? I'd like to create one if not. "bionic-openssl-1.1" OK?
<xnox> rbasak:  "IMAP connection to imap.gmail.com over SSL returns self-signed certificate." ergh whaaaaaat?!
<xnox> ha
<xnox> that's neat
<xnox> "connecting to imap.gmail.com over SSL, I get a warning embedded in the SSL certificate: "Subject: /OU=No SNI provided; please fix your client./CN=invalid2.invalid ""
<xnox> rbasak:  anyway, providing SNI is the right thing to do, and that's in unapproved queue already?!
<Unit193> Yeah, I've seen that before.
<sarnold> cute :)
<Unit193> https://repo.or.cz/alpine.git/commit/08fcd1b86979b422eb586e56459d6fe15333e500 would likely fix it, but that doesn't directly apply I don't think.
#ubuntu-devel 2019-10-09
<seb128> mwhudson, bug #1845571 ... if fixing it properly isn't an option, what about reverting the casper change that created the issue for this cycle?
<ubottu> bug 1845571 in partman-auto (Ubuntu Eoan) "ubiquity offers installation media as an install target" [High,Triaged] https://launchpad.net/bugs/1845571
<Tuxist> hi i have problem with dak and ubuntu especaily with ddeb packages they seems not to be supported any dak alternative ?
<Laney> ddstreet: xnox: do you see any problem if we delete the systemd-upstream autopkgtest results from when it used to use pi_tti's PPA? they are all quite old, right?
<seb128> sforshee, hey, how likely are we going to see that tpm kernel bug fixed in 19.10 before release?
<ddstreet> Laney i think that's fine; it looks like there are over 3000 test results per arch using the ~upstream-systemd-ci team ppa, so any older than that are unlikely to be needed for anything
<Laney> ROOOOOOOOOOOOCK ONNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
<ddstreet> Laney and you'll keep the results from ~upstream-systemd-ci, right?
<Laney> yeah
<ddstreet> awesome.  thnx!
<Laney> we just got a note from IS asking us to stop using all the bytes on the planet
<sforshee> seb128: the bug is fixed in the eoan-proposed kernel, which should be about ready to promote ...
<seb128> sforshee, ah nice, thx
<ddstreet> Laney i see you approved freeze exceptions for a couple ubuntu-kylin packages (which I uploaded yesterday), it looks like he has 2 more that need excptions lp: #1847391 and lp #1847101, can he have exceptions for those?  I can upload them if so
<ubottu> Launchpad bug 1847391 in kylin-nm (Ubuntu) "[FFe] Please sync kylin-nm 1.0.3-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1847391
<ubottu> Launchpad bug 1847101 in ubuntukylin-theme (Ubuntu) "[UIFe] Please upgrade ubuntukylin-theme to 1.8.3" [Undecided,New] https://launchpad.net/bugs/1847101
<ddstreet> he said he is also going to apply for upload rights for his pkgs too, which he definitely needs to do
<ddstreet> i'm not asking for myself, so if you have any concerns about giving exceptions i am fine with that
<Laney> ddstreet: yep, sounds fine to me (feel free to paste into the bugs)
<ddstreet> thanks!
<xnox> Laney:  yes old.
<xnox> Laney:  imho they should be purged frequently. No idea if we can track if like a PR was closed and delete those. Or like if we can purge things older than 3 months.
<seb128> doko, do you know if that's a known problem on current e with valgrind?
<seb128> --6234-- WARNING: Serious error when reading debug info
<seb128> --6234-- When reading debug info from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.0:
<seb128> --6234--    debuginfo section duplicates a section in the main ELF file
<seb128> same for gtk and some other libs
<seb128> and the result is lack of debug symbols
<seb128> (that's on amd64)
<rbasak> rafaeldtinoco: not sure whose triage it'll come up on next, but the reporter responded to bug 1846714. Since you're our haproxy expert now, could you take a look please to judge importance?
<ubottu> bug 1846714 in haproxy (Ubuntu Disco) "Merge "BUG/MEDIUM: server: Also copy "check-sni" for server templates."" [Undecided,New] https://launchpad.net/bugs/1846714
<rafaeldtinoco> rbasak: doing it
<rafaeldtinoco> rbasak: you are evil
<rafaeldtinoco> its been some time now i dont have to google for 3 acronyms in the same sentence
<rafaeldtinoco> lol
<rafaeldtinoco> rbasak: let me handle it #)
<rbasak> :)
<rbasak> rafaeldtinoco: no need to do it right now, we can just tag it and move on
<rafaeldtinoco> nah, let it hang there for sometime, ill keep it open and do it by eod then
<rbasak> rafaeldtinoco: I'm only asking because I thought you might immediately understand the issue and therefore understand its priority
<rbasak> Thanks :)
<bdmurray> sil2100: bug 1847313 is a duplicate of bug 1813354
<ubottu> bug 1847313 in ubuntu-release-upgrader (Ubuntu) "update to 19.04 to 19.10 terminal " [Undecided,New] https://launchpad.net/bugs/1847313
<ubottu> bug 1813354 in ubuntu-release-upgrader (Ubuntu) "release-upgrader unable to deal with sources.list entries of "deb mirror://"" [Medium,Confirmed] https://launchpad.net/bugs/1813354
<sil2100> bdmurray: good to know, thanks o/
<infinity> jibel: Why is zfs a unique snowflake in how we're seeing/installing tools?
<infinity> jibel: Everything else (other than ext4, whose tools are essential) ships tools in live-common, not *-desktop, and said tools are removed if unused.
<ahasenack> if I *have* to parse text output from a tool, because it doesn't use an exit status for a particular error condition, what's the right way to set the locale to "neutral"?
<ahasenack> LC_ALL=C LANG=C <command>?
<Faux> Sounds reasonable. TERM=dumb may help sometimes.
<infinity> ricotz: Was dropping all the libvala* files from debian/ intentional in this vala upload...?
<ricotz> infinity, how do you mean?
<infinity> vala-0.44.8/debian/libvala-0.46-0.install
<infinity> vala-0.44.8/debian/libvala-0.46-0.symbols
<infinity> vala-0.44.8/debian/libvala-0.46-dev.install
<infinity> vala-0.44.8/debian/libvaladoc-0.46-0.install
<infinity> vala-0.44.8/debian/libvaladoc-0.46-0.lintian-overrides
<infinity> vala-0.44.8/debian/libvaladoc-0.46-0.symbols
<infinity> vala-0.44.8/debian/libvaladoc-0.46-data.install
<infinity> vala-0.44.8/debian/libvaladoc-0.46-dev.install
<infinity> vala-0.44.8/debian/vala-0.46-doc.install
<infinity> vala-0.44.8/debian/valac-0.46-vapi.install
<infinity> ricotz: ^-- All those files got dropped.
<infinity> ricotz: That seems suboptimal.
<infinity> (debdiff is your friend)
<ricotz> huh, where did they came from
<ricotz> I didn't built the package, seb128 picked it up from debian salsa
<ricotz> I guess something went wrong when building 0.44.8-0ubuntu1
<ricotz> infinity, so those files should never have been there
<ricotz> infinity, the content of 0.44.9-0ubuntu1 looks good that way
<infinity> ricotz: Oh, huh.  I just realised those files are for a future version of vala.  Special.
<infinity> ricotz: Maybe the previous upload was an aborted attempt to merge with unstable, and then the uploader decided against it and didn't clean up. :P
<ricotz> maybe some gbp hiccup
<petersaints> Hi guys! I have a question regarding the inclusion of the NVIDIA proprietary drivers into the Ubuntu 19.10 Eoan Ermine ISO. From what I've read and tested, the Live session still boots using the nouveau drivers by default. The NVIDIA drivers are only enabled after installation. Is there any way to use the NVIDIA proprietary drivers in the Live
<petersaints> session before installation?
<xnox> petersaints:  actually when the installer selects them, they are installed both for the live session and the target, but i'm not sure there is anyway to "live" switch from one to the other without like killing the desktop.
<xnox> petersaints:  i guess in theory, one could switch to tty1 and orchestrate a switch. But by default, no the debs are not "pre-installed" in anyway shape or form to boot live session into them, as the user must agree to EULA to use/install them.
<xnox> * any way, shape, or form
<petersaints> Ok. I thought that there could be some "nonfree" boot flag that I could enable to directly boot into a Live version with the NVIDIA proprietary drivers.
<xnox> petersaints:  no, cannot do from legal reasons, not technical ones.
<xnox> petersaints:  we do not pre-link nvidia modules for the users.
<petersaints> It's not that the nouveau drivers don't work for me. I just wanted to test the latest GNOME 3.24 didn't leak memory with NVIDIA drivers.
<xnox> petersaints:  i agree it would be nice, you might want to open a bug report requesting that against ubiquity (ie. ubuntu-bug ubiquity or over at https://bugs.launchpad.net/ubuntu/+source/ubiquity )
<xnox> petersaints:  such that it's not forgotten, and discussed the blockers in doing it. Most likely the bug will stay open, or be closed as wont-fix / opinion.
<petersaints> This is not Ubuntu specific, but GNOME Shell has a number of issues when running with the NVIDIA proprietary drivers. For instance, if I snap two windows side by side and move the divider between the two back and forth for a little while GNOME Shell memory usage keeps increasing and even after you stop it's never reclaimed.
<petersaints> However, if you use the nouveau drivers or an Intel GPU the problem doesn't occur.
<infinity> I'd act surprised, except no, I won't.
<petersaints> Ehehe... I've been able to make my PC run out of memory just with this little trick
<petersaints> That's why I've been using KDE for the past 2 years or so, but from time to time I check if it has been fixed... but nope!
<infinity> Have you tried figuring out how to report it to nvidia?
<petersaints> I'm not sure whose fault it is. I commented about it in a GNOME Shell bug report some time ago.
<infinity> Granted, it would end up low on their TODO list, which is roughly: 1) Windows gaming performance, 2) Windows desktop stability, 3-97) Count money, 98) Linux gaming performance, 99) Linux desktop stability.
<infinity> But it's still worth a shot.
<sarnold> maybe linux desktop got shoved off the list when they started making a play for datacenters
<petersaints> but considering that the problem doesn't occur with other drivers it's probably their fault
<petersaints> there were some GNOME Shell leaks that were not driver specific, but the most sever ones have been fixed by now.
<infinity> petersaints: Well, "fault" and "blame" are hard to pinpoint when you're talking the bizarre interaction between renderering applications, OpenGL/Vulkan/etc stacks, low level drivers, kernels, firmware, sketchy hardware.
<petersaints> The only thing NVIDIA cares a little bit in Linux is probably CUDA performance for their Quadros and Teslas.
<infinity> petersaints: Really, every layer is grudgingly responsible for working around all the bugs in every other layer in both directions.  It's a "fun" space to work in, if you don't value clean solutions and general sanity.
<infinity> A large chunk of nvidia/amd 3D drivers are hackish workaround for crap software (mostly games, but desktops too!), like, ridiculously large amounts of code.  And every one of those hacks breaks someone else's equally sort-of-legit non-bug-but-kinda-bug hack elsewhere. :P
<petersaints> infinity yeah, I said fault in a broad sense. As in, where do I need to make the smallest change to make the problem go away without blowing stuff for every other scenario. For instance, to fix stuff to work better with the NVIDIA proprietary driver you could end up inadvertently breaking something else.
<xnox> petersaints:  so.... you say that nvidia drivers are bad for gnome-shell, we don't use them by default, and you don't want to use them by default, yet want installer to boot into nvidia..... to test things?
<infinity> xnox: To test is that combination now works.
<infinity> s/is/if/
<xnox> petersaints:  i'm just trying to understand the reasoning behind your nvidia ubiquity request.
<infinity> To be fair, it's a pretty niche use-case. :)
<petersaints> exactly, to test if the problem  still occurs without having to perform an install
<petersaints> I was just asking if there was already a process to make it happen
<petersaints> it's not worth it to implement it just for my super edge case
<sarnold> on the other hand maybe "download this, dd it to usb, reboot, wiggle your mouse for ten minutes" is a decent enough reproducer script that someone would *do* it :)
<infinity> petersaints: Sadly, no.  It would have to happen at very early boot (once one driver claims the card, it's basically busted for the other until a pretty hard reset), and at early pre-module boot, it's not really feasible to present you with informed consent sort of "do you want this non-free stuff, and do you bow to your nvidia overlords?"
<petersaints> Manjaro has been the distro where I have tried a few times if the problem is still there
<petersaints> they have a nonfree boot option for drivers and they bundle the nvidia  proprietary drivers
<xnox> petersaints:  you could try with booting 'break=bottom" when you boot installer, and press esc and edit the boot entry.
<infinity> Fun.
<petersaints> sadly, the last time I tried a couple of months ago still no luck
<infinity> Manjaro is a much smaller target than us, and we're trying to be on the right side of the copyright sketch involved.
<xnox> petersaints:  then you can bind mount proc, sys, dev, dev/pts, run into /root/* and chroot into there.
<xnox> cdrom pool should be configured
<xnox> and install nvidia drivers
<xnox> i think that might do it.
<xnox> exit the shell
<infinity> That would do, yes.
<petersaints> @xnox thanks for the tips, but it's too much of a hassle for what it is :P
<udevbot> Error: "xnox" is not a valid command.
<petersaints> @infi
<udevbot> Error: "infi" is not a valid command.
<xnox> and see if you boot with nvidia sutff, check settings, about this computer to ensure it's nvidia
<infinity> This episode of IRC is not Twitter has been brought to you by udevbot.
<xnox> petersaints:  well, i'm at release sprint next week with my nvidia capable laptop, i just might try all of that =)
<xnox> udevbot well job =)
<udevbot> Error: "well" is not a valid command.
<petersaints> infinity: sure, I wasn't aware of the legal stuff. I was under the impression that you had struck a deal with NVIDIA for the inclusion of the drivers. If that's not the case, it makes sense to be cautious.
<infinity> petersaints: It's less about nvidia and more about how you interpret the linking bits in the GPL.
<petersaints> xnox nice, but I believe that it must be an NVIDIA-only laptop like mine. I have a 6700HQ and a GTX 1060. The Intel GPU is completely disabled on my laptop. Only the NVIDIA GPU works and all output comes from it.
<infinity> petersaints: We link the drivers at install, with your consent, so it's the end-user (who isn't bound by the license) linking, not Ubuntu/Canonical (who are the distributor, and are bound by it).
<infinity> It's a fine line and vaguely sketchy distinction, but there you go.
<infinity> The best part about it all is that we *did* link the drivers in our build farm, so we could sign them.  Strip off the sig.  And throw away the binaries that we refuse to ship to you.
<infinity> So we can reattach the sig to the identical binary we create with your consent on your system.
<xnox> and perform signed secureboot with lockdown
<petersaints> infinity: that's quite a loot of hoops you go through to make things work without cross the line.
<xnox> petersaints:  NVIDIA-only laptop sounds sketchy. Are you sure you don't have any options in uefi bios menus to enable integrated graphics?
<petersaints> * lop of hoops
<infinity> An nvidia-only laptop would be the most power-hungry thing known to man.
<infinity> But maybe he meant it's nvidia-only because he hard disabled the Intel graphics in the BIOS?
<infinity> Which, see point 1:  Power hungry.  But I guess everyone has their reasons.
<petersaints> xnox: Nope. This is an ASUS ROG GL502VM and it was built this way in order to allow G-Sync.
<infinity> Oh.
<petersaints> you can't G-Sync from an Intel GPU and the laptop panel is G-Sync enable (60Hz which is kind of useless for G-Sync but oh well)
<infinity> Yeah, "gamer" laptops, all bets are off there.  Heat and power consumption aren't concerns, they're points of pride. :)
<infinity> If you can't bake cookies on the bezel, are you really gaming?
<petersaints> I've read that later models, such as the GL504 can switch between NVIDIA exclusive mode and hybrid GPU mode.
<petersaints> The battery isn't too bad for what it is. I can squeeze 4h out of it on Windows with ThrottleStop.
<petersaints> On Linux I get half of that!
<infinity> If nvidia would just admit that Freesync is the much saner (and far more widely adoptable strategy), they could standardize, and everyone would have nice things.
<petersaints> actually they now support FreeSync
<infinity> Do they support it without registry hacks now?
<infinity> Cause they used to "support" it in the sense that you could force it. :P
<petersaints> I think so. You now have different levels of certification
<petersaints> G-Sync, G-Sync Compatible and I think it tries to work with any FreeSync monitor on a best try basis
<petersaints> https://www.theverge.com/2019/3/12/18251980/how-to-install-nvidia-g-sync-unsupported-freesync-monitor
<petersaints> I have a crappy LG 75Hz FreeSync monitor but I can't use G-Sync with it because it doesn't have DisplayPort. It's HDMI and FreeSync over HDMI only works with some AMD specific extensions to the standard.
<petersaints> However, in theory, if I the monitor had a DisplayPort input it could work with my laptop's GTX 1060
<infinity> "AMD specific extensions" ... AMD wrote the standard, so I suspect that's okay. :P
<infinity> The Display-Port specific protocol is Adaptive Sync.
#ubuntu-devel 2019-10-10
<cpaelzer> ahasenack: the replies on the ZFS fallocate case seem good, lets see what further happens
<cpaelzer> it seems to get partially philosophic about "lying to userspace" :-)
<cpaelzer> jamespage: there are no ovs 2.12 release notes yet - what do you think we should add as link to our release notes?
<cpaelzer> oh the link already works http://openvswitch.org/releases/NEWS-2.12.0
<cpaelzer> well I'lla dd this then
<seb128> k, so network-manager's autopkgtest started failing on eoan/i386 because linux-headers-generic went missing
<seb128> which I expect is a wanted archive change?
<seb128> does anyone know the recommended alternative/what the pkg should install/do instead?
<seb128> Laney, ^ can you mark the n-m i386 test buggy until I figure out what we should be doing without an i386 kernel?
<Laney> seb128: guess so
<Laney> you probably want vorlon for this
<seb128> vorlon, ^
<seb128> help please :)
<seb128> Laney, thx
<Laney> I'll do the hint for now
<Laney> would be good to have an update and some advice on what to do in general
<seb128> thx
<seb128> right
<seb128> would also have been nice to some announce of such changes happening that late in the cycle but I will stop batting this drum I did it enough
<cpaelzer> xnox: thanks for your words on openssl
<cpaelzer> reads good and I feel better now
<cpaelzer> I'll give the DEFAULT@SECLEVEL a test somewhen soon
<cpaelzer> I knew you'll be the one with the best answers being involved in all of this, but it also provides a chance for anyone else to speak up :-)
<xnox> cpaelzer:  there is nothing new in them =) it's just repeats of things that were said in Brussels & Malta
<cpaelzer> I haven't heard about dh-keysize being known or the related potential workaround yet
<cpaelzer> maybe I haven't heard all in Brussels/Malta or was in different sessions at the time
<cpaelzer> I remember we talked in Paris (and before) about the reasoning being long term maintainability
<xnox> cpaelzer:  dh-keysize was not known explicitely, it was more of a general what-if given the set of new key-exchange and encryption algos introduced, and their priority / order / size has changed.
<xnox> cpaelzer:  and given that tlsv1.3 is siletnly enabled, so slightly higher level concern than dh-size.
<cpaelzer> yep
<ahasenack> cpaelzer: I can use a workaround of some sort: use zvols, libvirt has integration for that
<ahasenack> each vm will get its own zvol, instead of a qcow2 image
<cpaelzer> I'd have wondered if apparmor for these work
<cpaelzer> does it?
<cpaelzer> but surely if that works for you, feel free to do so
<ahasenack> well, I installed eoan on a vm using this scheme
<cpaelzer> without manually tweaking apparmor
<cpaelzer> nice
<ahasenack> that was the extent of my testing, and I also snapshotted the volume, but using zfs, not libvirt's snapshot
<cpaelzer> that should be enough, then the labelling changes I did a while ago might pay off
<cpaelzer> I haven't tested it in regard to zvols back then
<cpaelzer> two positive news in sequence much better than the rest of the morning, keep going ahasenack and xnox :-)
<doko> seb128: hmm, why is valgrind expecting debug info in the shared libs, they should be stripped anyway?
<seb128> doko, I don't know but those warnings might not be the issue, there is something weird going on though with glib/gtk symbols from my testing, unsure where to start to figure it out though :/
<doko> valgrind is rebuilt after the glibc upload, so that should be ok
<doko> seb128: when did you start seeing these?
<seb128> doko, I didn't do much valgrind debugging on eoan so I can't really tell, I tried to use it on gnome-calendar yesterday and it failed to give me anything useful ... could also be something to do with gnome-calendar though, I will try on some other gnome binaries
<doko> seb128: and mono/s390x, I didn't upload, just synced the python2 removal over there. contacted debian/upstream and xnox for now
<seb128> doko, thx
<xnox> doko:  ftbfs in debian too, just attempted a rebuild in sid chroot with sbuild
<tarzeau> requestsync doesn't work for me anymore but i'd suggest to not release proposed fasttracker2 with 19.10, either take the 1.00 or don't release
<tarzeau> dphys-config; aptitude-robot-session
<tarzeau> https://bugs.launchpad.net/debian/+source/fasttracker2/+bug/1815447
<ubottu> Launchpad bug 1815447 in fasttracker2 (Ubuntu) "upstream does not wish a stable release of the software yet" [Undecided,In progress]
<seb128> doko, thanks for that next cycle archive opening email, it's useful to see what's going on!
<seb128> fossfreedom, hey, did modern toolbar used to be default for rhythmbox-plugin-alternative-toolbar? it's not in 19.10 atm and I wonder if that's a regression/some distro default we lost on the way, do you know maybe?
<fossfreedom> It's the default for budgie as of a couple of days ago. I will have to look later to see what happened with ubuntu gnome... driving at the mo'
<HokarPokar> Hey guys. I'm trying to write a piece of code that can detect keypresses in background, for any application opened. Does anyone know of an API in ubuntu that can help me achieve this ? The long term goal is to map those sequential keypresses to a command, pretty much like keyboard shortcuts. Except that, keys in keyboard shortcuts need to held
<HokarPokar> down. What I want is to detect a certain sequence of keypresses and then, map that to a command
<HokarPokar> The subtlety that I am not aware of is, how to detect keypresses for all the applications in ubuntu.
<rbasak> HokarPokar: you're probably looking for some API against X11 or one of the toolkits that wraps it. But you're offtopic here. Try Stack Overflow maybe?
<rbasak> It won't be Ubuntu specific either - just specific to X probably.
<xnox> HokarPokar:  sounds like you are trying to implement a keylogger
<xnox> HokarPokar:  or look at other similar launchers, like https://en.wikipedia.org/wiki/GNOME_Do or gnome-settings-daemon
<xnox> HokarPokar:  cause one can setup a few keyboard shortcuts there. Study their source cod?
<xnox> *code?
<HokarPokar> xnox It does look like I'm implementing a key logger sort of thing. But the intention is different. I want to map certain sequences of key press events to commands.
<HokarPokar> @xnox
<udevbot> Error: "xnox" is not a valid command.
<HokarPokar> xnox Can I share a question I just posted on stack overflow ? It has all the details. I hope that doesn't count as promotion
<xnox> really don't care =) i don't work on graphical level stack
<sarnold> HokarPokar: what's your question url? I can't spot it in the list of SO questions
<seb128> vorlon, hey, unsure if you saw the ping earlier? I'm unsure what should happen to the network-manager i386 autopkgtest now that the kernel headers are not installable?
<seb128> would welcome some help
<vorlon> seb128: I thought Laney had already hinted it?
<vorlon> seb128: I think we should add a permanent badtest hint for network-manager on i386, because running i386 as a host OS is no longer supported
<seb128> vorlon, Laney said he hinted that version but was unsure what we were supposed to do
<vorlon> seb128: and in fact this is the hint Laney already added
<seb128> vorlon, k, so nothing to do from the source? I'm asking because I want to do an upload to include a bug fix, so I was wondering if I should do any change to the autopkgtest while I'm at it
<vorlon> seb128: I don't think you should bother with sourceful changes
<seb128> vorlon, k, wfm. L_aney reply this morning was "I'll do the hint for now, 	would be good to have an update and some advice on what to do in general"
<vorlon> ack
<seb128> vorlon, sounds like 'just hint those" is what is recommended then
<vorlon> indeed
<seb128> vorlon, thanks!
<vorlon> and I'll write a longer answer to a mailing list later
<seb128> great
<seb128> vorlon, thx for the ubiquity review, I need someone to merge for me since I don't have commit rights to that vcs if you want also to do that step... ;)
<fossfreedom> seb128: re alternative-toolbar - at some-point in this cycle gnome-shell or Ubuntu has changed this key from True to False https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Settings.html#Gtk.Settings.props.gtk_shell_shows_app_menu    - the plugin is relying on that to set the CSD header - it is defaulting to the compact toolbar instead. Two ways to solve this.  One: I could perhaps look instead for "GNOME" in the session
<fossfreedom> environment variable - or alternatively the distro can force the modern toolbar via a gsettings override like this https://github.com/UbuntuBudgie/budgie-desktop-environment/blob/master/debian/budgie-desktop-environment.gsettings-override#L10
<seb128> fossfreedom, thx
#ubuntu-devel 2019-10-11
<DarkTrick> Hello
<DarkTrick> I face a problem with menulibre. Is launchpad the correct place to file a bug?
<cjwatson> If it's a package in Ubuntu, then the first resort should normally be "ubuntu-bug menulibre", yes
<DarkTrick> Problem description: You can add items, but you can never remove them, because you need higher rights for removing. However running menulibre as sudo won't work
<cjwatson> (which goes to Launchpad, but possibly adding some debug information along the way
<cjwatson> )
<DarkTrick> cjwatson, thank you :)
<Unit193> It's python, so any traceback when you try to remove an item would be good too.
<DarkTrick> The button is greyed out
<bluesabre> Too late now, but hovering the delete button tells you why its greyed out :\
<bluesabre> Oh, he said that too
<bluesabre> I should make that just hide things
<tarzeau> did others have also outages with dhcp (systemd-networkd) and 18.04 LTS?
<tarzeau> apt upgrade would just hang since systmd blocks
<tarzeau> (only had it on 15/200 machines)
<TJ-> there's an annoying and spammy bug in gvfs with a fix upstream from 18 months ago still affecting 18.04 and possibly later; could we get this fixed? bug #1752091
<ubottu> bug 1752091 in gvfs (Ubuntu) "gvfsd-metadata[1703]: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed" [Undecided,Confirmed] https://launchpad.net/bugs/1752091
<TJ-> What am I missing with sbuild ? man-page says building from a .dsc or an extracted source package should be the same, but for an extracted source directory it calls dh clean which fails since the build-deps aren't intended to be installed expect inside the schroot. I even tried running dpkg-source -b . which created a ../XXX.dsc so it must be sbuild itself complaining
<Odd_Bloke> We've introduced package builds into the ubuntu-advantage-tools upstream CI, and we spend a chunk of time performing a debootstrap so we have an environment sbuild can use.  Do we have that same debootstrap output available for download as a tarball from somewhere, to speed up our CI a little?
<xnox> Odd_Bloke:  one can use launchpad api to download launchpad chroot as a tarball.
<xnox> Odd_Bloke:  look for chroot_url on https://api.launchpad.net/devel.html
<xnox> Odd_Bloke:  there is also an sbuild package to autofetch and use those sbuild-launchpad-chroot
<Odd_Bloke> Ahh, OK, nice.
<Odd_Bloke> xnox: Thanks!
<xnox> Odd_Bloke:  and like cpc team are building those now, and they are available from http download elsewhere too
<xnox> Odd_Bloke:  check with them. but that might not include all the releases you want
<Odd_Bloke> As we're using sbuild, sbuild-launchpad-chroot sounds like the easiest option.
#ubuntu-devel 2019-10-12
<Ark74> hello! great night!
<Ark74> I've seen that the network-manager package for Xenial is signed using this key:
<Ark74> pub   4096R/F0210224A744BE93 2014-06-16 [revocada: 2016-08-16] | uid    Marc Deslauriers <marcdeslauriers@videotron.ca>
<Ark74> but that key has being revoked
<Ark74> I get: gpgv: Signature made Fri Nov  2 13:52:40 2018 CST using RSA key ID A744BE93
<Ark74> gpgv: Can't check signature: public key not found
<Ark74> would this count as a bug?
<valorie> xenial?
<valorie> is that still supported?
<Unit193> For 557 more days.
<valorie> if so, I would get so
<valorie> guess!
<Ark74> So, if it is so, I need to fill a bug, right?
<valorie> Ark74: easiest way to file a bug report is in the commandline: ubuntu-bug network-manager
<valorie> and then just follow the prompts
<valorie> you can mark it security because it is
<alkisg> Hi, snapd doesn't run in the new ltsp, with "cannot create lock directory /run/snapd/lock: permission denied". I'm thinking it might be related to the writable overlay root that ltsp uses:
<alkisg> 29 0 0:25 / / rw,relatime shared:1 - overlay overlay rw,lowerdir=/root,upperdir=/run/initramfs/ltsp/up,workdir=/run/initramfs/ltsp/work
<alkisg> That /root there comes from: nfsroot=server:/srv/ltsp/images mounts the images directory, and ltsp then loop-mounts a squashfs.img file inside it, and applies a  tmpfs overlay over it
<alkisg> What can I do in the LTSP code to help snapd detect IsRootWritableOverlay() or whatever else it needs?
<infinity> alkisg: /run should be a tmpfs, not just a directory on your root overlay.
<cjwatson> Ark74: It's not a bug that source packages uploaded years ago were signed with keys that have since expired.  The security model for fetching packages doesn't depend on developer signatures; rather, developer signatures authenticate uploads to the archive, and then the archive is signed (starting with the signature in the InRelease file) and apt trusts that.
<cjwatson> Ark74: We aren't in general going to go round reuploading source packages to old releases of Ubuntu just to provide a new developer signature.
<cjwatson> (expired or revoked, either way)
<alkisg> infinity: /run is a tmpfs created by initramfs-tools; I'm putting my mount in /run/initramfs as systemd has this path hardcoded and doesn't unmount it on shutdown, as it does for other paths
<alkisg> It's supposed to be the correct path for initramfs-tools and dracut to mount their file systems, except for root, of course
<alkisg> I don't think the /run path is related though, as the previous ltsp also used /run and didn't have issues with snap; but it was using nbd, not loopback over nfs (we changed to that as it's a lot more stable)
<alkisg> Ah btw, I believe /run/snapd is using mount namespaces or something else, and it appears with different permissions for each app or each user (I'm not using snap so I don't know the details)
<alkisg> And maybe this has some issues with overlayfs, and maybe IsRootWritableOverlay() function is trying to apply some heuristics to work around those issues, and fails to catch the loopback over nfs case...
<Ark74> cjwatson, oh, ok.  I need to study more the apt/gpg trust mechanism, thanks for the clarification.
<infinity> alkisg: You misunderstood.  I don't mean the run in the initrd that has your mountpoints, I mean the /run in the running system should be a tmpfs mounted at /run :P
<infinity> (Not confusing at all)
<alkisg> infinity: the initramfs moves /run to the real file system, so  it's the same thing
<infinity> alkisg: Well, overlayfs shouldn't be in play at all then?
<alkisg> infinity: initramfs mounts proc, sys, dev, run, and root; the script/init-bottom/ltsp code loop-mounts /root/squashfs.img to /run/initramfs/blah, and creates a tmpfs there for up/work etc, and mounts the result with overlayfs in /root
<alkisg> Then control goes back to initramfs-tools, which calls pivot_root to /root
<alkisg> It's the same thing that casper does for live CDs, except now it comes from nfs
<alkisg> I see that snap has code to special-case some overlayfs file systems, so maybe it would need to add ltsp there, but I don't know the logic so I'm not sure
<alkisg> That's why I was looking for some guidance, to avoid spending e.g. a week understanding how snap works and why it special-cases overlayfs rootfs...
<infinity> alkisg: Right, what I'm saying is that if your /run is a tmpfs pivoted from the initrd, then overlayfs is irrelevant, at least for the error you were talking about.
<alkisg> infinity: the problem is /, not /run
<alkisg> Hrm
<infinity> "/run/snapd/lock: permission denied"?
<alkisg> Or maybe you're right, and I'm looking in an unrelated part
<alkisg> But then I've no idea why snapd doesn't like ltsp
<alkisg> We're not doing anything more than that overlay
<alkisg> The permission denied is probably due to mount namespaces
<alkisg> But I don't know how these work, how per-user or per-app namespaces are handled
<alkisg> And why they break in ltsp :/
#ubuntu-devel 2019-10-13
<alkisg> It seems like snapd is trying to confine the snap to the rootfs using apparmor, and that fails, because it's trying to confine it in /up instead of /run/initramfs/ltsp/up. It might be related to LP bug 1703674.
<alkisg> Full information, including apparmor denied errors: http://termbin.com/fdy9
<ubottu> Launchpad bug 1703674 in AppArmor "inconsistent required directory rules needed with overlayfs" [Undecided,New] https://launchpad.net/bugs/1703674
<alkisg> As ltsp loop-mounts /root/squashfs.img over /root in initramfs/init-bottom, maybe some "root mount" information gets hidden, and snapd fails to properly detect it...
<rkta> I wrote a patch to add an option to force ISO8601 week numbers to ncal from bsdmainutils. The patch is related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926437 . What should I do to submit it? First time ever contributing, docs are confusing. :)
<ubottu> Debian bug 926437 in bsdmainutils "bsdmainutils: ncal week numbering for 2019 is off by one" [Important,Open]
<pokui> Hey all, any chance https://github.com/torvalds/linux/commit/8f5914bceef03827c3feb413874b2e6f29c821be will get merged into the ubuntu kernel sources any time soon? In the meantime I'm building a custom kernel so I can install onto a new mac mini's internal SSD.
<valorie> pokui: you might ask in #ubuntu-kernel
<valorie> keeping in mind it's a weekend
<pokui> valorie: thanks. I'll leave the query and wait.
<valorie> cool
