#ubuntu-devel 2005-08-08
<jordi> can anyone here confirm liblaunchpad-integrration is GPL?
<lexhider> seems so, check /usr/share/doc
<Seveas> Where can i find the specification of the changelog format?
<Seveas> Or isn't that format all that strict?
<ogra> Seveas, probably the debian policy docs
<ogra> (i have no link)
* Seveas looks through them
<Seveas> but no luck yet in finding anything
<ogra> but its pretty strict, vim shows wrong lines instantly, there must be a spec
<mdz> jordi: debian/copyright
<jordi> mdz: this box is Debian
<jordi> the Broken OS
<mdz> jordi: apt-get source launchpad-integration
<mdz> baz get jamesh@..../...
<jordi> ooh, that baz thing :P
<mdz> jordi: get used to it :-P
<dholbach> ok pals, i'm off to bed - see you around
<jordi> yeah man
<infinity> Kamion : libdebian-installer fails on ia64 because ia64 doesn't support -gstabs (for reference, neither for ppc64, so that'll fail if/when it ever becomes a supported debian/ubuntu build target)
<infinity> Kamion : s/neither for/neither does/
<elmo> what the heck is using stabs?
<elmo> stabs is so fucking 60s
<bddebian> elmo: Can I get white-listed for kate notifications?
<infinity> Only if you get her name right.
<infinity> Poor thing.
<bddebian> ?
<elmo> bddebian: yeah, you're in the whitelist locally; I'll sync it tomorrow
<elmo> bddebian: it's katie, not kate
<bddebian> Oh, OK, thank you
<bddebian> Ohhh katie, sorry
* bddebian pets katie
<glick> hello
<bddebian> Hello glick 
<glick> excuse me, twice now, i have tried to backport wxpython2.6.3 to hoary and after like an hour and a half of building i get a segmentation fault when it processes the tex files and tries to convert them to html
<glick> and it of course deletes the entire build tree that it created so far so i have to start over again
<glick> anyone kow whats going on with this?
<bddebian> Use -nc if you don't want it to clean your build-tree
<glick> bddebian, but i dont know if it still has important things to build, i dont know if without that ill be able to install it
<glick> this is the eror line
<glick> /bin/sh: line 1:  4845 Segmentation fault      LD_LIBRARY_PATH=../objs_gtk_sh/lib: ../objs_gtk_sh/utils/tex2rtf/src/tex2rtf ../docs/latex/wx/manual.tex ../docs/wx-manual.html/wx2.6-manual.html -twice -html
<glick> make: *** [build-doc-stamp]  Error 139
<infinity> glick : Backtrace it in gdb.
<glick> infinity, im not sure what i would backtrace, its not like it dropped a core file
<glick> and it sucks to have to do that again with no result
<infinity> glick : Sure, but you can re-run that one line without restarting the build.
<infinity> glick : So, do the build until it fails, then re-run that one bit in gdb, and backtrace the segv.
<glick> infinity, not really cause all the stuff has been deleted
<infinity> glick : No, nothing gets deleted until you re-start the build and debian/rules clean is run again.
<infinity> (Well, unless that package has a really broken build system that cleans on failure, but that would be retarded...)
<glick> infinity, it says.. after that line clearning the build enviorbment removing directory so and so
<glick> i think i might jsut say screw wxpythin
<glick> look for another gui framework
<bob2> you're using pbuilder?
<bddebian> ?
<infinity> He was talking to glick.
<bddebian> Aye
<glick> bob2, yes i was
<bob2> there you go then
<glick> bob2, i was told to use pbuilder
<bob2> either don't use it, or configure it to not destroy the build tree on failure
<bob2> I recommend not using it
<bob2> using pbuilder is fine, as long as you know what it's for and what it does
<glick> i dont really i just wanted the latest version of wxpython :)
<glick> does anyone here also do any development for Windows?
<camilotelles> glick, I do
<glick> camilotelles, is there any documentation on how one would access the cdrw on windows for example in your code if you wanted to write a burnner app
<camilotelles> glick
<camilotelles> Image Mastering API
<glick> camilotelles, where can i read up on that?
<camilotelles> glick, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/image_mastering_api.asp
<bddebian> Ack, my eyes, my eyes..
<glick> camilotelles, where are these functions available?
<glick> do i have to buy .NEt to access these?
<camilotelles> bddebian, take easy, i'm only asking a question :)
<bddebian> :-)
<camilotelles> glick, i think this is from the base system.
<glick> damn there arnt any examples 
<glick> i forget windows isnt linux and everyone is a closed source/shareware asshole
<whiprush> more than likely we're all nice people and you're just offtopic. :)
<camilotelles> glick, whiprush is right. 
<netdur> poeple, I don't know if you know about new icons or not... but take a look, it worth! http://nuovext.pwsp.net
<bob2> so, backports people
<bob2> apparently someone backported smeg to hoary
<bob2> which apparently neccessitated a newer pyxdg
<bob2> said new pyxdg breaks gnome-app-installer
<Amaranth> oh, i may or may not have given them the pyxdg package that's in the old backports :P
<Amaranth> i can't remember
<Amaranth> but it's still a problem in the new repo
<mdz> bob2: Mez is the person to talk to
<srbaker> do i seriously need a bugzilla account to VIEW bug reports?
<srbaker> oh, thank god
<bddebian> You shouldn't
<bddebian> Ohh
<srbaker> 12613 is fucking ridiculous.
<srbaker> Ubuntu ships with pre-release software, and there's actually a discussion about it when it starts breaking shit
<jdub> srbaker: chill, please
<srbaker> jdub, hey, i'm chilled.
<srbaker> jdub, i just want to know when i'll be able to get work done wihout having to spend my days building custom packages for my co-workers
<srbaker> sigh
<jdub> pfft
<jsgotangco> pfft?
<jsgotangco> heh hi btw
<srbaker> jdub, okay, i'm sorry for being a bit impatient.
<srbaker> jdub, i was under the understanding that this was a solved problem, and then i looked at the bug and saw otherwise.
<srbaker> jdub, this is the source of a huge amount of pain for our entire team
<jdub> srbaker: so would you be willing to test an updated package to ease our concerns that it would be inappropriate for hoary-updates?
<srbaker> absolutely.
<jdub> i really think that's all it comes down to
<srbaker> all six of us would gladly.
<srbaker> i didn't see any mention of update packages on the bug.  just multiple suggestions to "use backports"
<srbaker> i do *not* use backports, because they are unstable and buggy.
<Lathiat> What's this about?
<srbaker> Lathiat, hoary shipped with a pre-release hoary.
<jdub> ok, so perhaps grab the backports build, and then comment on the bug about your testing
<Lathiat> srbaker: hoary? 
<Lathiat> you mean ruy?
<Lathiat> *ruby?
<jdub> Lathiat: ruby
<srbaker> ruby
<Lathiat> ah right
<Lathiat> i thought so
<srbaker> sorry
<jdub> (i totally understand horrored distrust of backports)
<srbaker> jdub, heh.  you don't know the half of it.  our entire development team has standardized on ubuntu.  there have been...  some annoyances.
<srbaker> and some major fucking problems.
<srbaker> most of them have been since traced back to backports usage :P
* Lathiat laughs
<jdub> productive feedback always appreciated
<srbaker> jdub, so the ruby in backports is the "officially" sanctioned package then/
<jdub> mmm, ugly backports pain
<jdub> srbaker: well, no, but if it tests well, we could push it in hoary-updates
<srbaker> hrm
<jsgotangco> (hate to admit, but i use the ruby in backports for rails)
<srbaker> okay, i'll take a look at it
<jdub> which then would be official, supported, etc.
<jdub> but we really can't do it on a whim
<srbaker> currently we're using packages that i built from debian sarge.
<jdub> which i think makes sense
<mdz> hoary-backports is likely to become a staging area for hoary-updates in some cases
<jdub> and is the kind of trusted state you'd expect for a supportable platform :-)
<jdub> mdz: rock
<srbaker> jdub, makes sense but this is a huge problem for us and many others, and it's been almost a month with no hint at the possibility of an official resolution
<jdub> srbaker: mm, but it is kind of a quiet bug
<srbaker> alright, i'm biased. 
<jdub> srbaker: i mean, you haven't even commented :-)
<srbaker> jdub, i haven't needed to.  my co-workers have.
<mdz> we can't be held responsible for the fact that they fixed some particularly interesting bug 2 days after we froze ruby
<jdub> ok
<jdub> mdz: though, to be fair, we did ship a pre-release (trusting debian unstable in the process)
<mdz> this happened 4 months before release; if someone had mentioned it during that time, this would have been easy to fix
<srbaker> mdz, imho, if there's a "pre" in the version number, it should be closely watched for updates and included.
<srbaker> shipping pre-release software just seems stupid.
<mdz> there are lots of pre-release packages which go out with stable releases
<mdz> it's at the discretion of the maintainer, and they usually know what they are doing
<srbaker> i know.  it's frightening
<jdub> srbaker: understand the POV, but there are different ways of looking at things from the "shipping a supportable distro" POV too
<lexhider> hi, jdub: If I remember correctly bug #12050  is a duplicate of a bug you commented, I was having trouble finding it.
<srbaker> jdub, okay.  thanks for being helpful.  sorry to be a prick, but this has been an ongoing PITA
<srbaker> jdub, it's been the source of a lot of problems at work
<jdub> srbaker: s'ok. but we are usually not so diplomatic in reaction to this kind of behavior, so please don't take this as a useful strategy for getting your problems solved in ubuntu. :-)
<srbaker> jdub, heh, of course not.  keep in mind to you this is the first time you've seen it, and i apologize for not taking this into consideration.  for me, this is a month-old problem with a seemingly simple solution
<jdub> lexhider: hrm, there's a few of these
<srbaker> jdub, also, i was under the impression that at least two of my co-workers have bitched in here about it already and were basically told to fuck off
<lexhider> jdub: it's hard to search for duplicates when it takes so long. ;)
<jdub> lexhider: kind of annoying to be getting the big .js file from https ;)
<mdz> srbaker: it may seem simple to you, but there is a lot of potential for breakage in blindly including an enormous patch in a stable release
<srbaker> mdz, true, but it seems unlikely that software will depend on a bug in a pre-release that was only in the world for a couple days 
<mdz> srbaker: if someone behaved inappropriately (CoC) toward them, I'd like to hear about it (with quotes)
<jdub> srbaker: there could be bugs in the changes between pre and final
<mdz> srbaker: certainly not, and I would be unlikely to object to fixing that bug
<mdz> srbaker: but I do object to blindly including an enormous, unauditable patch
<jdub> srbaker: as an upstream, i am totally happy for distros to be fundamentally untrustworthy of my prissy version number statements about stability ;-)
<srbaker> mdz, i'll ask around.  i think it was more of a general dismissal than inappropriate behaviour.
<srbaker> jdub, fair enough.
<srbaker> okay, then this brings me to my next question
<mdz> srbaker: if you know what the specific bug is, and can help us to isolate a patch, that would help to move things forward
<srbaker> can we pay canonical for specific focus on the things that trouble us?
<mdz> but this isn't going to fly:  52 files changed, 6277 insertions(+), 279 deletions(-)
<srbaker> we lose money when ubuntu gets in our ways, and it's been doing so quite a bit lately.
<srbaker> (well, me.  others have different problems of different sizes)
<jdub> srbaker: yeah, you can - yay for support :-)
<srbaker> could we perhaps pay for the day or three that it would take to audit and include this patch?  and how much would it cost?
<jdub> srbaker: in fact, if you want to email me about what you're doing, and the problems you've faced, that would be really helpful -> jeff.waugh@canonical.com
<srbaker> jdub, this ruby one has been the show stopper.  there have been other issues, but i am unable to pin them on ubuntu because my co-workers aren't as strict about package integrity as i am
<mdz> srbaker: why would you want to do that, instead of getting your bug fixed directly?
<srbaker> mdz, well, my assumption is that the reason this bug is taken less seriously than others is a matter of business.  if we pay for your time, then we can pick what bugs are addressed in that time, no?
<jdub> mdz: (customers setting priorities for bug fixing through a commercial transaction...)
<srbaker> that's how i've done with other commercial vendors in the past
<jdub> srbaker: hrm, not a matter of business that the bug has not been fixed yet
<srbaker> RH, in particular has been great at this.
<mdz> srbaker: of course you could get your bug fixed as part of a support arrangement, but I don't see why you would insist on fixing the methodology
<srbaker> mdz, i don't care about anything but the right version of ruby being in hoary :)
<mdz> srbaker: that's not a support issue
<srbaker> and if paying for it will make it happen more quickly, i'm sure i can convince the right people to cough up the dollars to make it happen
<srbaker> mdz, we seem to disagree over whether shipping a pre-release known-buggy piece of software is stupid then.
<mdz> if what you need is a stable and supported Ubuntu build of a certain version of ruby, we can certainly provide that
<mdz> but it won't force a decision about what gets included in the official releases
<mdz> srbaker: yes, we do.  it is not as simple as that.
<srbaker> so the policy of including pre-release known-buggy software isn't seen as a problem then?
<jdub> srbaker: (it's not a policy)
<mdz> known-buggy?
<jdub> srbaker: in some cases, we need to ship pre-release software (or patches out of cvs) to be able to support things; in this case, it was largely a timing and feedback issue
<jdub> srbaker: but this is just to explain why it is the way it is; it doesn't really impact whether we can fix it or not
<jdub> :-)
<mdz> there was no bug reported about this issue until last month, which was three months after Hoary released
<mdz> and there still isn't a proper bug report; just a request for a new version (which is why it ended up with backports)
<srbaker> "you shipped a pre-release buggy version of X" is a proper bug report
<srbaker> and the appropriate fix is to ship the non-pre-release version
<jdub> srbaker: the "buggy" bit is the proper bug :-)
<jdub> srbaker: if the differences were small, that would be a no-brainer, but they were not, so it has to be more carefully considered (and tested)
<jdub> so the way forward, i think,
<jdub> is to ask the affected users to test an updated package
<jdub> so we can be comfortable shipping it in hoary-updates (and thus an officially supported fix)
<srbaker> okay, well we'll test it.  does this mean that ruby1.9pre might make it into breezy though?
<mdz> no, that is not a proper bug report.  a proper bug report would be "this bit of ruby isn't working properly; here's a test case demonstrating the problem"
<jdub> srbaker: well, the timing issues are going to be different, i'm sure
<Lathiat> mdz: that wouldnt be entirely effective in this case
<jdub> what's in breezy atm?
<Lathiat> as rails does a version check
<Lathiat> 1.8.2-1 in breezy
<jdub> Version: 1.8.2-1
<Lathiat> mdz: think firefox
<mdz> Lathiat: I'd be happy to patch that out
<jdub> and we're already UVF
<Lathiat> breezy's ruby+rails setup works fine
<jdub> srbaker: so there's no problem at all in breezy
<Lathiat> mdz: right but if someone wants to use a gem, they get the same problem
<jsgotangco> yeah it works fine in breezy
<mdz> jdub: unless, of course, we pull a new version in order to fix a known bug
<jdub> srbaker: again, there is no "we ship pre-release software" policy - it came straight from debian sid
<jdub> mdz: yeah
<Lathiat> yeh ive successfully used rails on breezy
<srbaker> so have i.
<Lathiat> its a shame the bug wasnt caught pre-hoary
<jdub> srbaker: and crucially, it survived the testing process :)
<ajmitch> Lathiat: I think rails didn't have that check until after hoary released
<Lathiat> ajmitch: It must have, because the version in hoary whinges
<jdub> ajmitch: damn, like that bloody firefox page!
<Lathiat> jdub: like i said a minute ago, "think firefox". :)
<jdub> haha
<Lathiat> ... and dont kill me for the pain and suffering that results.
<jdub> ok
<jdub> party time
<mdz> Lathiat: that means that no one tested rails, and since it's in universe, it wasn't a priority for centralized QA
<jdub> later :)
* fabbione goes back rebuilding his garden room
<Lathiat> mdz: indeed
<ajmitch> mdz: sadly the people that want to use those packages won't find the bugs until it's too late for the MOTUs
<mdz> ajmitch: I don't think that's inherently true
<mdz> lots of users test software that's important to them in ubuntu pre-releases
<mdz> that's absolutely the best way to ensure that the next ubuntu release is high-quality in the ways that matter to you
<ajmitch> as long as enough people test & report the bugs for fixing, we're ok
<ajmitch> rails just seemed to slip through, I think
<srbaker> rails didn't have the version check until 0.13.1
<jsgotangco> its all in breezy though
<srbaker> good!
<srbaker> we're planning on migrating the office to breezy upon freeze, and spending a week hammering it, iirc.
<ajmitch> srbaker: right, that's what I thought, so it's a case of using post-hoary rails with hoary ruby
<mdz> that's wonderful; that way you can be certain that when it releases, the ruby stuff is up to par
<jsgotangco> yeah me an ogra were talking about ruby/rails stuff a few days ago
<srbaker> ajmitch, yeah.  it also broke some other software that doesn't actually check but crashes with the bug.  i think alexandria was affected.
<jamesh> you could just use zope3 :)
<jsgotangco> *grin*
<jamesh> that's what we're using
<ajmitch> jamesh: why not, packages are in debian experimental iirc :)
<ajmitch> not sure if they've been imported to breezy yet
<jamesh> ajmitch: we aren't actually using a packaged version of zope3
<ajmitch> jamesh: I wouldn't expect you to at the moment
<srbaker> zope.  hehe
<srbaker> i don't think zope can handle the kind of traffic we do.  otherwise, i'd suggest it
<srbaker> well, not on a manageable amount of hardware
<srbaker> jdub, okay, thanks for easing my mind on this.  much better than the feedback my co-workers were getting when they checked it out
<srbaker> i won't care anyways.  everyone else on my team is staying with ubuntu.  they ordered me a mac today. :P
<jsgotangco> lol
<jsgotangco> srbaker: if its any help to you, my colleagues at work are ruby/rails people as well and using them on breezy at the moment
<jsgotangco> aside from the other guys using it on windows
<srbaker> jsgotangco, yeah, i know breezy is pretty decent, but i'm not willing to risk it
<jsgotangco> yeah
<srbaker> we have enough problems with supposedly stable software :P
<srbaker> jsgotangco, how many rails developers at your work?
<jsgotangco> 4, not really rails-dedicated btw
<jsgotangco> not including me, i just dived in and getting my feet soaked
<srbaker> ahh
<srbaker> well, we're under the impression that we're currently the biggest rails dev shop outside of 37signals.  we're 6
<Amaranth> ooh, new gamin
<srbaker> 6, fulltime
<srbaker> and well, we do more traffic than anyone on the internet except 44 sites, so we're also big in that way
<pitti> Good morning
<pitti> Hi mdz_ 
* mdz connects from his desktop for the first time in over a month
<doko> good morning
<pitti> Hey doko
<doko>  hplip (0.9.4-2) unstable; urgency=low
<doko>  .
<doko>    * Matthias Klose <doko@ubuntu.com>:
<doko>      * hplip-base should also replace files in hplip-data (<< 0.9.3)
<doko>      * Run HPLIP daemons as non-root user (optional, default as run as root)
<doko>        (closes: #320936)
<doko> pitti: ^^^ for your statistics
<pitti> doko: thanks! :-) Can you please send the patch to Debian, too?
<sivang> morning all
<doko> pitti: 0.9.4-2
<Lathiat> doko, pitti: statistics?
<pitti> doko: oh, I see :-)
<pitti> doko: so can we make it the default in Ubuntu somehow?
<doko> it already is
<pitti> Lathiat: https://wiki.ubuntu.com/DerootificationStatus
<pitti> doko: you are so great! :-)
<Lathiat> pitti: ah
<sivang> hi Lathiat , pitti 
<ajmitch> hi pitti 
<Lathiat> yo sivang 
<pitti> doko: added to the wiki page
<calc> btw is there any bug reports about firefox on amd64 being unstable starting in the past week or so?
<calc> its crashing pretty frequently on my box
<pitti> calc: do you have the latest libcairo1? Try to upgrade
<calc> 0.6.0-0ubuntu2
<calc> afaik i have all the current stuff
<Amaranth> "it's in breezy right now but unfortunately X doesn't work" ;)
<calc> X kinda works ;)
<calc> at times
<calc> i don't restart X often since it has a habit of breaking
<Amaranth> no, one of the lugradio guys said this
<Amaranth> talking about cairo and gtk
<calc> heh
<Lathiat> X works
<Amaranth> latest episode
<Lathiat> as long as you hack up mkfontdir
<Amaranth> no, that's fixed too
<Amaranth> but this was recorded probably 2 or 3 weeks ago
<Lathiat> thats fixed?
<Lathiat> since when?
<Lathiat> i dont remember seeing an X update
<Amaranth> xfont-utils or something
<sivang> pitti: can I ask you something about effecting packaging dependencies wrt launchpad integration? 
<pitti> sure
<Amaranth> what is launchpad-integration for exactly?
<Amaranth> say 'integrating with launchpad' and i may have to smack you silly :P
<sivang> Amaranth: install file-roller and find out :)
<Amaranth> how could i not have that installed? :P
<sivang> pitti: we need to create a helper function (like jamesh did for UIManager and glade) for bonnobo ui apps
<sivang> Amaranth: hehe, after you isntalled, go to "Help" and see Launchpad smiling at you :)
<Amaranth> sivang: nice, first thing i see is 'domain name mismatch' :P
<Amaranth> that really needs to get fixed, it scares people away
<sivang> Amaranth: bah, well what domain does it look for?
<sivang> Amaranth: https://wiki.ubuntu.com/LaunchpadIntegration as well
<Amaranth> err, maybe that's not what it says anymore, i clicked ok without reading
<Amaranth> because i'm used to that stupid error
<Amaranth> shit, now it won't do until until i start a new browser session
<Amaranth> which i can't do because i have sessionsaver
<sivang> Amaranth: weird never happend to me
<Amaranth> ah
<Amaranth> i see
<sivang> pitti: however, bonnobo brings in ORBit, libgnome, libbonobo, gnome-vfs, etc
<Amaranth> launchpad.ubuntu.com but the cert is for launchpad.net
* Amaranth facepalms
<sivang> pitti: and the current lib mainly depends on Gtk stuff, so would it be wise to toss this utility in another lib/package? 
<sivang> Amaranth: tell that to stub , at #launchpad
<sivang> Amaranth: I bet he'd like to know , or you have to refresh your cache or something
<sivang> Amaranth: they changed the domain 2 days ago IIRC
<pitti> yay, new gamin
<Amaranth> yeah, i'm about to start beating it to death :P
<Amaranth> (testing it)
<JaneW> hi all, I need to respond to an e-mail enquiry... will Breezy have twinview in xorg enabled?
* Treenaks points JaneW at daniels 
<daniels> JaneW: no.  we do not ship the nvidia binary driver by default, and will never do so.
<daniels> JaneW: as to the general question of dual-head ... i guess breezy+1 or whenever someone gets time to do XorgAutoconfiguration.
<highvoltage> daniels: unless the license changes, of course ;)
<Treenaks> highvoltage: i.e. never
<highvoltage> Treenaks: good point.
<bob2> GNNNNNNNNNNNNNNNNR
<bob2> kernel update + suspend to disk = losing all state with no warning
<Lathiat> bob2: thats why you should use suspend2
<daniels> bob2: yeah, that really shits me off
<Lathiat> if you try to boot an image with the wrong kernel it gives you a chance to back out
<daniels> bob2: i'd love a little thing that blocked on input saying 'if you want to get back to your old session, reboot onw'
<daniels> 'else press enter'
<daniels> Treenaks: s/never/no time soon/
<Burgundavia> daniels, where is status of the completely free ati drivers with 3d for newer cards?
<Burgundavia> daniels, 9600 and similar series
<daniels> Burgundavia: breezy+1
<daniels> Burgundavia: 'generally works great' for agp, 'utterly non-functional' for pcie
<bob2> daniels: yeah
<Burgundavia> so they are making good progress on that?
<bob2> Lathiat: except then I have to deal with crackaddled Frozen Bubble splash screens
<Lathiat> bob2: eh?
<Burgundavia> daniels, not asking for breezy, just didn't get a good sense from the various pages and lists I visited
<daniels> Burgundavia: yeah
<bob2> maybe that's just what neal has on his laptop
<bob2> but having the kernel throw images at me scares me
<bob2> er, nigel
<\sh> morning
<Lathiat> yeh you dont need that
<Lathiat> its an optional feature, obviously
<Lathiat> the default mode is a text mode
<Lathiat> runs a little progressbar and tells you what its doing
<Lathiat> i havent used it in ages tho
<Lathiat> suspend to ram does the trick
<JaneW> daniels: thanks. The guys says he is looking for something that  'when I plug a projector into my laptop it will configure to display my lcd screen on the projector at the best resolution the projector will handle.  Windows currently does that and it really needs to be in ubuntu.'
<Lathiat> last time i used it was on my 266mhz gateway laptop
<daniels> JaneW: breezy+1 super-optimistically.  breezy+2 possibly.  breezy+3 probably.  breezy+4 maybe.  it's a frigging hard problem space.
<daniels> JaneW: one of the things I'd love to spend development time on, but I don't have any
<Lathiat> yeh that sounds nasty
<JaneW> daniels: ok thanks and understood ;)
<Lathiat> theres like 4 separate problems that jump into my head off the bat
<daniels> a) initial detection of devices, b) binding them to the same driver, c) reconfiguring on the fly, d) having the driver detect plug events, e) if doing xinerama, how to deal with accel etc; if doing mergedfb, how to set independent modes
<Lathiat> do projectors reliably provide their maximum resolution with the autodetection magic?
<daniels> sure, but again, difficult problem space
<daniels> it's not viable to detect stuff like that with vbe, since you only get access to the first head
<Lathiat> ah, right
<daniels> so basically you have to split every driver into, say, libi810 and i810_drv, and be able to load libi810 from userspace and poke deeply into the card configuration
<daniels> which sucks
<Lathiat> so is that a implementation limitation as opposed to a hardware limitation?
<daniels> correct
<daniels> all our problems are implementation limitations
<Lathiat> right
<Lathiat> and sucky drivers
<Lathiat> which, i guess is an implementation limitation. :)
<daniels> while it's *better* than v3 in every respect, the xfree86 v4 architecture still sucks at multiple outputs
<Burgundavia> daniels, I cannot seem to find the page that I saw regarding those drivers. Where would I find them again?
<daniels> Burgundavia: r300.sf.net
<Lathiat> is there still a way to bind random graphics cards together "properly" like twinview style / what windows does ?
<Lathiat> s/still//
<Burgundavia> daniels, thanks
<bob2> Lathiat: isn't that just xinerama
<bob2> ?
<Lathiat> bob2: where you can drag windows between both screens?
<bob2> also, gnome-update thing is nifty with the terminal widget
<daniels> Lathiat: xinerama lets you do that, dude
<bob2> Lathiat: X has been able to do that since like 2001
<Lathiat> daniels: really? hrm
<daniels> the problem with xinerama is that the one screen -> one device assumption is hardcoded pretty solidly into X
<Lathiat> whatever i did the 1 time it ried it must have not been using that
<daniels> so you don't get 3D acceleration on both heads, etc
<Lathiat> right
<daniels> mergedfb/twinview solve this by cheating it into one device for two screens
<Lathiat> or overlays
<Lathiat> heh yeh
<daniels> Lathiat: just acceleration in general
<Treenaks> daniels: but people _are_ working on a new/better system right?
<daniels> the former being for radeon/sis, the latter being for nv
<daniels> Treenaks: slowly, yes
<daniels> Treenaks: all the EGL work is shoving us in a far more sensible direction
<Lathiat> twinview has an annoying bug on my laptop
<Lathiat> i cant make my internal LCD the primary display no matter how hard i try
<Treenaks> EGL? is that like XGL?
<daniels> Lathiat: see me not care :P
<Lathiat> daniels: heh
<Lathiat> i can do a two-screen setup thing, but i couldnt move things between windows, didnt realise you could not have that happen, cus i didnt care much at the time
<daniels> Treenaks: egl is embedded gl, which is a subset of the GL API.  mesa are implementing EGL, plus extensions to deal with mode-setting, et al.
<Treenaks> daniels: yay for http://wiki.x.org/wiki/XorgGlossary :)
<daniels> Treenaks: http://people.freedesktop.org/~ajax/dri-explanation.txt is also brilliant
<Treenaks> ooh nice
<craig> Hey
<seb128> elmo: gdesklets-data gperiodic gnome-build (experimental) intltool syncs please
<Treenaks> daniels: weren't they working on some XAA-replacement as well?
<Treenaks> ah EXA
<craig> How do i install smb iam new to linux..Thank You in advance:)
<Burgundavia> daniels, is that r300 stuff in breezy?
<Burgundavia> craig, that is a question for #ubuntu
<craig> yes
<daniels> Burgundavia: no
<craig> if iam in the wrong place 2 ask questions just say so and i will leave:)
<bob2> this channel is for development discussion; try #ubunut
<bob2> er, #ubuntu
<craig> ok thank you 
<Burgundavia> daniels, thanks
<JaneW> does anyone know anything about dist-upgrade? I have another enquiry and am not too certain about what the guy is going on about...
<mvo> JaneW: please forward it to me (or /msg me)
<bob2> can't you just tell these people to email ubuntu-users?
<JaneW> mvo: ok I'll fwd to you, thanks
<JaneW> bob2: yes I guesss I could, but they want to feel special ;P
<Lathiat> ooh gamin update
<Lathiat> wonder if it works
<mvo> elmo: can you please sync synaptic from debian/unstable (ok with Kamion, bugfixes only)
<niran> mvo, are all your nifty api additions to python-apt going to be in breezy?
<mvo> niran: yes, I'll work on it today. unfortunately the api will change a bit to make it conform to PEP08 (python style guides). but I'll let you know about that (and provide a patch)
<niran> mvo, ok, cool
<JaneW> hi all, I have added another table to the BreezyGoals page, called deferred. If your goal is being deferred (can't be finished in time for Breezy) - please move it to this table, so that we can keep track of it.
<jsgotangco> *stress*
<JaneW> If your goal is mostly complete, but some part of it have been, or are to be deferred, please lists these portions on the deferred table... this will allow goals that are as finishsed as they are going to be to be listed as complete, while still keeping track of additional work that needs to be picked up on later.
<JaneW> jsgotangco: :P
* JaneW *CRACKS WHIP*
<daniels> is there a column for 'won't happen until someone gets assigned a decent amount of time to work on it [which won't happen]  or it gets bountied'?
<JaneW> daniels, sure, put it in the deferred table and make a note about it, and suggest it gets bounties etc, a lot of these deferred items are exactly because there hasn't been enough time to complete them - or on some cases even start them.
<daniels> JaneW: this is the 'even start them' one
<JaneW> daniels: wich one?
<JaneW> s/wich/which
<seb128> daniels: VideoRoadmap ? :)
<daniels> FUCK
<daniels> *ahem*
<daniels> JaneW: this wiki is a goddamn blast from hell.  keeps killing firefox.
<daniels> seb128: pick one of 'working X' or 'xine'
<daniels> seb128: i.e. not this week, probably not next week
<daniels> will have to sneak it in pretty close to feature freeze
<daniels> JaneW: VideoRoadmap is 'daniels to do Xine before feature freeze', XorgAuthentication is to be deferred, and probably FasterNetworkedX as well (i'm just overseeing that and smacking Tollef if he comes up with a crap solution, not doing anything of value development-wise)
<seb128> daniels: no problem for me, keep working on xorg, that's just to know what to do with the wiki
<seb128> so JaneW stop the pressure :p
<daniels> seb128: cool
<daniels> seb128: yeah, I'd just edited that before firefox came crashing down (quite literally)
<Lathiat> whats needed for video stuff?
<seb128> the wiki is public
<seb128> read the spec?
<doko> daniels: surely that's an xorg bug well hidden in libxkb or somewhere else ;-P
<seb128> that's VideoRoadmap
<daniels> doko: it's a firefox bug -> seb's problem
<daniels> he's hindering my productivity
<seb128> daniels: use epiphany-browser ? :)
<seb128> hum
<daniels> seb128: heh.  you've got me there.
<doko> lol, daniels is complaining about _that_ ? :-)
<seb128> do we have a reason to keep automake-1.4 with the higest alternative?
<sivang> seb128: would you say it'd be wise to put the bonnobo ui apps helper function to add ui elements in another lib? jamesh suggested that because of the dependencies this may bring in current lib, ofcourse for the python scripts it will depend on the same "binary" 
<seb128> sivang: yeah, probably
<Kamion> infinity: huh, libd-i uses -gstabs? boggle. Is -ggdb safe as a replacement?
<sivang> seb128: bonnobo brings in ORBit, libgnome, libbonobo, gnome-vfs, etc
<sivang> seb128: k
<sivang> seb128: thx
<doko> seb128: I stumbled about that prio as well. but maybe you break now more things than you fix, maybe just use a build-conflict
<seb128> doko: that's not a build issue, that user getting both installed, running ./autogen.sh for GNOME stuff or using anjuta and getting errors
<daniels> seb128: 1.6 or 1.7 would be *far* more sensible.  of course, the easiest solution is to just not have 1.4 installed at all.
<seb128> cf https://bugzilla.ubuntu.com/show_bug.cgi?id=13146
<seb128> sivang: yeah, I know what bobono pulls
<seb128> daniels: any reason to not prefer 1.9?
<daniels> seb128: yes, because it breaks shit horribly
<doko> Kamion: I don't know of any restrictions, but maybe the size of the debugging info is bigger with -ggdb
<daniels> seb128: i sat down a month or two ago with another of the X guys, and we worked out that 1.6 was the sweet spot, though sort of slowly moving to 1.7
<Kamion> it's going to be stripped anyway, it's just for in-tree debugging
<daniels> seb128: so we try to support 1.6 through 1.8 or maybe 1.9
<daniels> seb128: but SO MUCH STUFF is backwards-incompatible
<daniels> seb128: it's like automake people are just bored, and really bitter
<seb128> bah
<daniels> 'so, what's the plan for 1.10?'
<daniels> 'LET'S BREAK SHIT.  I HATE MY EX-WIFE AND THE WORLD IN GENERAL.'
<seb128> so better to keep 1.4 for the moment so
<daniels> seb128: 1.6 or 1.7 would be best
<daniels> seb128: better to throw 1.4 away and forget it existed
<daniels> with such relics of the past as xfree86
<seb128> k
<seb128> I'll ping mdz about this when he's around
<daniels> i think eric dorland or whoever the automake maintainer is in debian decided to throw away 1.4 just recently
<seb128> sivang: I'm wondering if that's worth doing a library instead of patching 4-5 apps using bonobo for menus
<siretart> daniels: that was about automake 1.5, iirc. automake 1.4 is too widly used for dropping yet
<daniels> siretart: not that many people still use 1.4, at all
<siretart> more than 1.5
<daniels> sure
<daniels> but no-one uses 1.5 at all
<JaneW> daniels: that's not the wiki, it's your flash extension :)
<seb128> daniels: #228604 is about this
<daniels> JaneW: don't have flash installed
<JaneW> ok, well then the wiki sucks ....
<daniels> JaneW: right
<sivang> seb128: we have also the applets...and the translations.. whenever soething changes it will cause great work per app
<sivang> seb128: or even if launchpad url changes..
<JaneW> seb128: it's not me making the pressure, it;s the deadline, and sides I am trying to find a way to EASE it...
<seb128> JaneW: I'm pretty sure everybody knows about the different freezes :)
<bob2> daniels: just be glad it's not zwiki
<bob2> daniels: or it'd be your firefox and the app server that crashed
<seb128> doko: cairo/glitz uploaded
<doko> seb128: Did notice. thanks!
<seb128> np
<JaneW> daniels: if you are having wiki problesm mail me with updates - I am happy to apply them.
<daniels> bob2: lpwiki!
<daniels> JaneW: see the line 16min ago
<JaneW> seb128: wtf is that meant to me?
<JaneW> s/me/mean
<daniels> JaneW: upstream version freeze, feature freeze, code freeze, preview freeze, etc
<JaneW> daniels: VideoRoadmap, ok will do.
<JaneW> daniels: yes... so?
<daniels> JaneW: and the FasterNetworkedX stuff
<daniels> JaneW: er, was just relaying what seb said
<JaneW> daniles: ok
<seb128> JaneW: hum, cool, I was not agressing you or something. 
<JaneW> seb128: yes but I don;t know what seb128 is implying...
<Amaranth> seb128: glade was doing a bad thing setting up bonobo docks for my menus? :)
<JaneW> seb128: ask highvoltage I am pretty agrro atm ;)
<daniels> http://swik.net/
<sivang> Amaranth: your doing Smeg ?
<seb128> JaneW: I just say than I'm not sure than pushing people all the time will make thing changing faster, if people don't update stuff that's probably because they are busy with other stuff (like daniels with xorg)
<Amaranth> sivang: ?
<sivang> Amaranth: sorry, disregard
<JaneW> seb128: not to flog a dead horse, but I am trying to get the BreezyGoal tables organised for mdz before next friday, he is concerned that everyhting looks unfinished while in a lot of cases the goal is basically finished, but it;s been agreed to defer some parts of the spec.
<seb128> right
<JaneW> seb128: I am not pushing people, I am asking them to let me know if anything is not going to be finished in time for Breezy so that I can keep a list of it, and not let it get lost.
<pef> hello
<Kamion> for breezy+1 we need to seriously think about triaging the results of brainstorming before using the entire output of a brainstorming session as inputs to (a) max out the conference schedule as hard as possible (b) max out the development schedule as hard as possible
<Kamion> if that makes sense
<daniels> also one thing that would make more sense is not budgeting everyone's entire time towards stuff that seemed like a good idea in april
<ogra> Kamion, it does...
<daniels> six months is a hell of a long time, and many more urgent/worthwhile things may come up itmt
<daniels> (and not just triaging, some of them *cough*LaptopPowerManagementorwhatever*cough* need quality filtering also, and they need to be written up beforehand to avoid 'so, what's this all about then?' 'you tell me' '...'-type sessions)
<bob2> proposers should come to the session, too
<bob2> or at least very strictly specify what they thing the spec should implement
<daniels> yes
<bob2> having to guess what someone wants from a short description is highly stressful
* sivang -> launch
<sivang> err, lunch
<JaneW> Kmaion: I second that
<JaneW> Kamion even
<JaneW> we are looking at ways to make the process work much better next time.
<Kamion> great
<bob2> making room for oxford-style meetings would be cool, too
<ogra> we should also make clear to the feature requesters that we have *not* 6 months for development...
<doko> Riddell: ping
<Treenaks> ogra: but like 4-ish?
<\sh> will there be another ubuntu conf for breezy +1?
<Kamion> yes
<Riddell> doko: hi
<ogra> Treenaks, yup
<\sh> Kamion: the place is known?
<Kamion> no
<ogra> Treenaks, or even 3
<Kamion> (not to me, anyway)
<Treenaks> \sh: *points at JaneW*
* Lathiat mumbles perth, australia
<Lathiat> its the obvious place!
<Kamion> I doubt it will be the same country twice in a row
<Lathiat> yeh well i was being stupid anyway :)
* ajmitch starts putting aside some $$ for conference :)
<Amaranth> how do i kill gnome-panel and make it stay dead so i can start it in gdb?
<doko> Riddell, \sh: I did create a wiki page CxxLibraryResync to track the status of C++ libs compared to unstable. Please could you update this (when the KDE stuff starts to float to unstable)
<Lathiat> Amaranth: you dont? :)
<Amaranth> Lathiat: haha
<Amaranth> seb128: latest gnome-panel upgrade makes the panel crash after editing menus with smeg
<ajmitch> doko: what is suggested depends for wxpython  now?
<Lathiat> man i have like 7 lines in my tray
<Lathiat> whats with that
<Treenaks> Amaranth: does smeg update the desktop files atomically?
<Amaranth> err, what?
<bob2> Lathiat: better snort it before the cops come!
* Lathiat laughs
<Treenaks> Amaranth: do you do "open, write, close, rename" or "open, write close
<Amaranth> that second one
<Treenaks> Amaranth: you should probably create a temp file somewhere, and move that to the right place when you're done writing
<Amaranth> Treenaks: thats not why it dies
<Treenaks> Amaranth: so the menu stuff never sees a partially-written file
<Amaranth> Treenaks: that's not it, it's monitoring closes
<Riddell> doko: ok, will do
<doko> ajmitch: good question. do you need a specific version, i.e. 2.4 or 2.6?
<Amaranth> Treenaks: and it dies when i remove ~/.local/share/applications/ so it's something else
<Treenaks> Amaranth: ok :) just checking possible causes :)
<bob2> winkle: 29
<bob2> hrm
<ajmitch> doko: 2.4 for my package at the moment, so I put libwxgtk2.4-1-python in 
<ajmitch> but there are a number of packages on the unmet deps list for me to work through
<doko> ajmitch: yes, maybe I should add a provides: python-wxgtk2.4, and python-wxgtk2.6
<pitti> hi
<ajmitch> hi pitti 
<Amaranth> now this is odd
<Amaranth> it went from crashing to just ignoring me
<Amaranth> yay it works
* Amaranth hugs seb128 
<Amaranth> d'oh
<seb128__> what ?
<Amaranth> My menus updated. Once. :/
<Lathiat> gnome panel is useless at updating things
<Lathiat> i think its gamins fault
<Amaranth> no, seb128 just uploaded a new gnome-menus that almost fixed it
<Lathiat> ahh
<seb128__> "almost"?
<Amaranth> like i said, it worked once
<Amaranth> the first time i edited something with smeg the menus updated
<Amaranth> i closed smeg, reopened it, and tried again, nothing
<JaneW> \sh?
* JaneW is having a nightmare of a week *sob*
<JaneW> how many things can go wrong!?
<janimo> Janew, whistle: always look on the bright side of life :)
<Amaranth> seb128__: For the first time ever my gamin debug log shows the gnome_vfs_monitor_add() stuff getting through from gnome-menus, i guess that's a good thing
<seb128> cool
<seb128> gamin 0.1.3 is supposed to fix some of the previous b0rkage
<seb128> and new gnome-menus is built with gamin now
<seb128> so using both should kind of work
<daniels> JaneW: eh, you could get home one night and discover that you were actually moving out that night
<Amaranth> total rewrite of the inotify backend just hit CVS :)
* JaneW sings 'Life's a piece of shit, When you look at it."
<JaneW> daniels: that happened to you?
<seb128> Amaranth: when?
<daniels> JaneW: yeah.  moving the rest of the bits tonight, my bed arrives tomorrow.
<seb128> Amaranth: 0.1.3 is from yesterday
<JaneW> ;)
<Amaranth> supposedly a couple hours ago
<Amaranth> it doesn't use the polling backend anymore
<seb128> Amaranth: after 0.1.3?
<Amaranth> yeah
* JaneW 's poo, is broken and leaking, the roof was leaking, the oven broke last night when I was trying to cook a meal for my sister who is here to stay with 5 week old baby.
<JaneW> just got oven repair guy in who tells me we need to break out a piece of the wll to fix it! wtf!
<JaneW> etc
<JaneW> for the rocord the POOL is broken not poo ;))
<Amaranth> shit, another crash
<Amaranth> seb128: what dbg packages should i get to make this backtrace useful?
<shackan> hi
<seb128> Amaranth: backtrace of what app?
<Amaranth> gnome-panel
<Amaranth> or whatever the menus run as
<shackan> gnome is driving me nuts
<Amaranth> right now it just gives me http://rafb.net/paste/results/HDGcMh46.html which seems less than useless
<shackan> apt-get upgrade refuses to install updated versions for x and gnome, why ?
<bob2> you know "upgrade" doesn't take any arguments, right?
<seb128> Amaranth: gnome-panel-dbg .. do you want to push it upstream? I get it too, so if you don't I'll bother them with it :p
<Amaranth> shackan: because you need to install/remove extra things to install them
<Amaranth> seb128: i'll let you do it :)
<seb128> k
<shackan> bob2, I'm not *that* noob
<crispin> is the new gnome 2.12 menu editor in breezy ? and if so what package is it in ?
<seb128> crispin: gmenu-simpler-editor from gnome-menus and it sucks
<Amaranth> :)
<seb128> crispin: try smeg
<Amaranth> oh, that reminds me
<Amaranth> smeg is in gnome cvs now
<crispin> seb128: heh, ok :-)
<shackan> it just says "the following packages have been kept to the current version"
<seb128> yeah, I've noticed on #commits
<shackan> with a long list of gnome and x stuff (among others)
<Amaranth> shackan: if you don't understand how to upgrade you should probably stick to hoary for now
<shackan> I'd love to
<crispin> seb128: should it be in the menu hierarchy somewhere ? (I can't find it)
<shackan> but I need breezy for a project I'm developing right now
<Amaranth> crispin: no, right click on a menu entry and it comes up
<Amaranth> which is foreshadowing how bad it is :)
<Amaranth> shackan: Do you need X and etc for this project?
<crispin> Amaranth: ahh, I was right clicking on the actual menu entry, not the top-level "Applications" entry
<seb128> crispin: right click on the panel menus
<Amaranth> oh, you have to click on the panel?
<Amaranth> that's lame
<shackan> well, no, I need HAL and DBus, but I need somewhere to write my code in, you know.. so I also need gnome
<seb128> crispin: basically you can mask/show a menu entry that's all, sucker
<Amaranth> if you need X to work i'd wait for the next colony cd
<crispin> oh dear, I installed smeg, and gnome-panel crashed :-)
<Amaranth> crispin: yep, this is called a gnome-panel bug :)
<crispin> at least that means gamin notified it :-D
<seb128> crispin: gnome-panel seems to crash on menu updated yeah
<seb128> updates
<shackan> probably colony 3 will be out after my deadline is over.. grr, thaks anyway
<shackan> *thanks
<Amaranth> deadline?
<shackan> right, project have deadlines, indeed... :)
<shackan> *projects
<Amaranth> shackan: dist-upgrade
<Amaranth> shackan: from there you're on your own
<crispin> smeg only seems to update the actual menus when you quit it, but it is better :-)
<Amaranth> crispin: in 0.8 it'll do it when you click the 'Save' button :)
<crispin> IMO it should do it immediately, but at least thats a start
<Amaranth> crispin: the GNOME folks seem to agree with you but i hate instant apply
<seb128> why?
<Amaranth> plus it'd probably double the ammount of code i have implementing it sanely
<Amaranth> seb128: *shrug*
<Amaranth> i can't put it into words at 5:30am :)
<seb128> ah ah
<Amaranth> btw, pyxdg is going to need a bunch of patches to make it behave properly
<doko> ajmitch: you should depend on python-wx2.4, or python-wx2.6
<Mez> mvo: ping
<Kamion> elmo: please sync libdebian-installer 0.32 from Debian incoming
<mvo> Mez: pong
<Kamion> fixes that ia64 build failure
<Mez> mvo: gksu doesnt seem to include gksudo anymore
* Amaranth heads for bed
<mvo> Mez: what version?
<Mez> mvo: whatever versions in breezy atm...
<Mez> mvo: I'm getting errors that it doesnt exist
<Mez> mvo: that is, assuming it's meant to be in the gksu package
<mvo> Mez: I have it here (1.3.0-1ubuntu2). what does "dpkg -L gksu" say?
<Mez> dpkg -L gksu
<Mez> says it's not insalled
<Mez> weird
<Mez> synaptic says it is
<Mez> o_O
<Mez> apt-get says it isnt
* Mez slaps synaptic
<Mez> sorry for wasting your time mvo
<Mez> weird greying out of the screen
<mvo> Mez: synaptic did show a package as installed that wasn't? that sounds odd 
<niran> is there a simple way to get baz to add all the files in a directory that aren't already added?
<niran> i've just been scripting it to get it to add each file at a time to get past the errors
<niran> ad it feels dirty.
* sivang --> back
<sivang> seb128: when you have time, please refresh the sources for the the helper lib, we've modified it to point at launchpad.net instead of launchpad.ubuntu.com, thanks
<seb128> could you have the discussion about that on this chan? thanks
<seb128> jamesh: around?
<jamesh> seb128: yeah
<sivang> seb128: ah that was just less then one line change, that's all
<sivang> seb128: but yes, ofcourse :)
<seb128> jamesh: could you push mdz's patch for labels (you were Cc:ed on the mail) or give me a commit right on the baz archive so I can do it?
<seb128> sivang: speaking about all the discussion for lpi, like the bonobo lib, etc
<seb128> sivang: there is no point to keep that as private discussion
<sivang> seb128: ofcourse, I discussed that here with you, about an hour ago, no?
<seb128> you start saying you discussed about it with jamesh
<seb128> could you discuss than on this chan rather, so you don't have to ping people to summarize discussions
<jamesh> seb128: just reading.  hadn't got round to those emails (I've been catching up after the flight
<seb128> jamesh: k, thanks. That's basically a 2 line changes to menu items title/tooltip
<jamesh> yeah
<jamesh> seb128: I can't easily give you write access to my archive, but you can easily create your own branch
<sivang> seb128: k, sorry if we did
<seb128> jamesh: and I'm having issues with gnome-games atm. They are setgid games which break the /proc/... opening
<sivang> seb128: you're trying to patch them for lpi ? (gnome-games)
<seb128> sivang: np, that's just that I'm listed by as leading this spec so I need to know what happens. If you guys discuss stuff without me all the time that's not going to work. Better to discuss here so I'm on phase with is beeing done
<seb128> sivang: I've already patched it, it just doesn't work because of the setgid
<seb128> s/with is/with what is/
<sivang> seb128: ah I see, ok. What about the labels changes? what is it about?
<seb128> -    { "LaunchpadAppInfo", NULL, N_("Launchpad Info"),
<seb128> +    { "LaunchpadAppInfo", NULL, N_("Get Help..."),
<seb128> -    { "LaunchpadAppTranslate", NULL, N_("Translate This Application ..."),
<seb128> +    { "LaunchpadAppTranslate", NULL, N_("Translate This Application..."),
<jamesh> sivang: decision about the exact text for the labels
<sivang> jamesh: ah, then I can create diffs for it and send you for commit, if that's not too much overhead 
<jamesh> hmm
<seb128> jamesh: k for baz, fine with me :)
<sivang> seb128: that's all the changes that are needed?
<seb128> yep
<jamesh> Steve's mail says the menu item should be "Get Help Online..."
<sivang> seb128: k, on my way
<seb128> sivang: it doesn't need you
<sivang> seb128: ah ok
<seb128> sivang: mdz sends a patch
<seb128> s/sends/sent/
<Kamion> mvo: any thoughts on the download progress thing? is it feasible?
<seb128> jamesh: hum, right .. use that probably
<mvo> Kamion: I haven't thought about it that much but I think we can do it. it needs to be available from aptitude, right?
<Kamion> yeah
<sivang> seb128: why are gnome games setgid ?
<Kamion> I think the main issue would be determining how much of the progress bar space to use for the download step
<Kamion> either you hardcode that in apt, or we have multiple progress bars emitted by apt and have base-config use waypoints to glue them together the way base-installer does with debootstrap's progress indicators
<mvo> Kamion: what about two progress bars? one saying "downloading changes" and one "installing stuff"? or is that a stupid idea?
<Kamion> mvo: that's absolutely fine, if you can get it into the protocol
<Kamion> I think that's better actually, because then base-config can easily be tweaked to use different amounts of a consolidated progress bar for it depending on what works, or to just have two physically separate progress bars
<seb128> sivang: to write scores to /var/games
<Kamion> it's just a matter of how to clearly distinguish when apt is starting the "installing stuff" stage
<mvo> Kamion: ok. what about using the "status" field in the protocol and adding "downloading" as a new status? then the usual description (what package, total percentage, human readable string(?)
<jamesh> seb128: probably the best way to solve the problem is to add an API to tell liblaunchpad-integration what the source package name is
<jamesh> then it could short circuit some of the lookup it is doing
<seb128> yeah
<Kamion> mvo: if I can be guaranteed that the last entry in the downloading progress bar is 100 so that I can safely distinguish when the new bar is starting, that's fine ...
<sivang> jamesh: what does that mean? :)
<seb128> that means having a function to specify the package name
<seb128> so it doesn't have to search for it
<sivang> seb128: ah
<seb128> ie: the gnome-games patch would use this function to specify "gnome-games"
<jamesh> sivang: the helper library can deduce the correct URLs based on one of a number of pieces of info
<mvo> Kamion: you will know when it switches from "status" to "download" (probably "status" should be renamed to something better as well)
<jamesh> s/helper library/helper app/
<mvo> Kamion: ups :) the other way around of course
<jamesh> the library currently passes the PID, but could be modified to pass the source package name instead (if it knows what that is)
<sivang> jamesh: so that measn you'd have to incroporate your python logic into the c library for finding this info?
<jamesh> sivang: nope.
<Kamion> mvo: ok
<jamesh> sivang: add an API like this_is_my_source_package_name("...")
<sivang> Kamion: I owe you this from last night, ii  oem-config-locale            0.13ubuntu4
<mvo> Kamion: do you have a good idea for something better than "status"; "dpkg" is probably too specific, "installing" misses the point when it comes to removals; "package-manager" does not sounds righ
<Kamion> sivang: thanks
<sivang> jamesh: so in every patched app I use this API call to specify the source package of the app I'm patching ?
<jamesh> sivang: It'd probably be better to make it optional (so that all the existing app patches continue to work)
<seb128> sivang: could you focus on the bonobo changes, I'm almost done with the GtkUIManager patches, don't bother with them
<jamesh> sivang: just use it where it is actually necessary (e.g. gnome-games)
<sivang> jamesh: ok
<sivang> seb128: ok
<Kamion> mvo: not really
<Kamion> mvo: pmstatus?
<sivang> seb128: I suggest we update the wiki page with packages that are done
<mvo> Kamion: pmstatus sounds better 
<seb128> sivang: yeah, I've planned to do so
<sivang> seb128: becasue I was going to do epiphany, would be nice to see what you already did in order not to duplicate work
<sivang> seb128: either way, I'll concentrate on boonbo now
<seb128> sivang: I've uploaded it some days ago
<seb128> sivang: and you asked before starting file-roller/gedit I thought you would do the same for other packages
<sivang> seb128: no it's ok, I havn't really did anything with it, I will ask you about it next time
<seb128> sivang: what is "clock", "fish", etc?
<martinhj> I have upgraded gnome-menus to the latest in the breezy repo, but the menu update dosn't work as it should: I get "The Application "gnome-panel" has quit unexpectedly." and have to restart the menu application.. When the new menu appears I also get a "I've detected a panel already running,
<martinhj> and will now exit." error message
<martinhj> is this common and known error?
<seb128> yep
<seb128> it crashes on update
<martinhj> ok
<seb128> gnome-session-remove gnome-panel
<seb128> gnome-panel
<seb128> that should restart it
<martinhj> yeah, but it works anyway... Only with the "detected a panel already running"-error that just reappears if I hit OK
<martinhj> but anyway, that steps you described got rid of it
<marcin> hi all
<marcin> I got a question 
<marcin> I would like to create a package for ubuntu and I wonder what is a preferred method
<azeem> cdbs
<marcin> should I follow maint-guide and use simple scripts in rules file
<sivang> seb128: applets that I found in the desktop seed
<marcin> or maybe I should use cdbs scripts?
<marcin> azeem: so cdbs?
<seb128> sivang: fish is an universe package ...
<seb128> marcin: depending on what you do, for GNOME we use cdbs by example :)
<seb128> sivang: BTW I've updated the wiki list
<azeem> marcin: I suggest you look at a couple of preexisting packages which mutually the same level of complexity and see how they do things
<mvo> Kamion: what kind of information should we present to the user? "Downloading %li of %li", "Downloading %li of %li (%s time remaining)"; or rather show the download rate? all of it?
<azeem> eh, s/mutually/roughly/ or something
<sivang> seb128: fish in universe is a scriping language, AFAICT
<seb128> sivang: that's my point, as said some time ago this is a list of sources packages
<marcin> well I plan to package something 'overcomplicated' - some packages for emacs
<seb128> sivang: ie: I've listed "gnome-games", not the pile of games, same for gnome-utils and the pile of utils 
<sivang> seb128: I'm trying to find the source package for the fish applet (the one that just takes cpu time :) but cant ..:-/
<sivang> seb128: it may be part of gnome-applets
<seb128> gnome-panel: /usr/lib/gnome-panel/fish-applet-2
<Kamion> mvo: I'd skip the time remaining bit, and just have "Downloading <package>" and the percentage of total estimated download time in the percentage field
<Kamion> actually, no, not the percentage of total estimated download time, that might decrease
<Kamion> just the percentage of total bytes downloaded
<sivang> seb128: ok, so shall I list this as "gnome-panel" ?
<Kamion> hmm, I suppose progress bars often include time remaining indicators
<Kamion> so maybe "Downloading <package> (%s time remaining)"?
<seb128> sivang: yeah, you can make a list of what need to be patched like "gnome-panel (fish)" ... 
<sivang> seb128: ok
<mvo> Kamion: "Downloaded %i of %i (%s time remaining)"? I can't attach a package name because it may download more than one pkg in parallel.
<Kamion> oh, ok
<Kamion> yeah, that's fine then
<sivang> Kamion: OEM_CONFIG_DEBUG=1 doesn't seem to produce more then what I have already sent you, though
<ogra> Edubuntu Meeting starting in #ubuntu-meeting
<ogra> in case someone is interested
<sivang> seb128: I'm trying to find the wanda fish just to glance at its bonnobo code, but can't find it int hte source pkg gnome-panle
<seb128> sivang: gnome-panel-2.11.90/applets/fish/
<seb128> pitti: around?
<seb128> pitti: gst should be alsa by default?
<martinhj> is it any plans to move cdrdao in to main from universe and make nautilus depend on it? Copy disc for Audio cd-s depends on it.. "File image creation failed Could not run sub process: Failed to execute child process "cdrdao" (No such file or directory)."
<seb128> please open a bugzilla about this on n-c-b
<sivang> seb128: doh, I'm braindead
<jamesh> seb128: would the new autoaudiosink be a better choice?
<martinhj> n-c-b?
<mvo> Kamion: it's in michael.vogt@ubuntu.com--2005/apt--progress-reporting--0 (see README.progress-reporting for the format). I tested it lightly with aptitude, it should work
<mvo> (the download progress reporting that is)
<seb128> jamesh: BBB recommends to not use it with the current version ... I'll ping him again on next one
<jamesh> martinhj: the bug would be that the nautilus-cd-burner package doesn't depend on cdrdao when it should
<pitti> seb128: no, gst should default to esd
<seb128> pitti: the wiki is not clear
<seb128> " done: dmix by default, gstreamer->alsa"
<seb128> you put this description !?
<pitti> seb128: it was an option, but dmix is not mature enough to actually do that
<Kamion> mvo: you clear APT::Keep-Fds entirely in dpkgpm.cc - doesn't that break people who're trying to set APT::Keep-Fds on the command line?
<seb128> pitti: k, that's what I thought, but since the goal page states other way ...
<janimo> Kamion is there an uptodate baz branch of apt? the ones on arch.ubuntu.com do seem dates
<janimo> err,dated
<Kamion> janimo: nothing to do with me
<mvo> Kamion: IIRC I clear it after the dpkg run. but it still is probably wrong (/me checks again)
<Kamion> janimo: http://people.debian.org/~mdz/arch/apt@packages.debian.org/ is upstream
<Kamion> and in fact has the Ubuntu branch too
<Kamion> mvo: right, seems to me that will break debconf passthrough
<mvo> Kamion: yes, I'll fix it now
<Kamion> thanks
<CarlFK> hi Kamion - just sending you "baseconfig from stuck breezy install" 
<martinhj> seb128: Now the cdrdao-bug is filed, but I could not change the "Target Milestone" to "Ubuntu 5.10"
<seb128> milestone is not something for users
<seb128> that's up to the maintainer to decide when he wants to fix an issue
<seb128> thanks for the bug
<martinhj> no problem at all, it is the least I could do
<Kamion> CarlFK: hmm, the menu-mapping file looks fine. Could you also send /var/log/base-config.log?
<CarlFK> comming up
<Kamion> mvo: hooray, works great
* mvo beams
<mvo> now I only need to fix this "$$"*/($ fd problem you just mentioned. it turns out to be harder than expected
<Kamion> I need a new debconf to make the progress bar UI not *totally* suck, but apart from that ...
<Kamion> mvo: is it a problem with deleting items from configuration lists?
<mvo> Kamion: yes, libapt seems to not support it at all
<Kamion> mvo: Configuration has a copy constructor - maybe you could back up _config and then restore it, or something
<Kamion> or back up the APT::Keep-Fds tree, I guess
<Kamion> except libapt doesn't seem to support reinserting subtrees either, ugh
<Kamion> maybe you could Clear() it and then go through the backup subtree reinserting all the elements ...
<mvo> Kamion: I'm considering to just add "Clear(List, value)" to support removing certain values from lists
<CarlFK> Kamion - http://thwackugh.personnelware.com/carl/temp/base-config.log 
<CarlFK> I think I see "my" problem
<CarlFK> wait... wget not found?
* sivang -> back
<Kamion> wget is only there after the package selection step runs successfully; it's not part of the base system
<Kamion> which implies pkgsel fell over, which implies the image is just hosed *shrug*
<CarlFK> is that "new"?
<Kamion> no
<Kamion> well, not very. breezy.
<CarlFK> ah
<Kamion> yesterday's image had broken aptitude/libsigc++ depends, I think
<Kamion> which would've broken pkgsel, so it may've been that
<Kamion> should be fixed today
<Kamion> there's no output from pkgsel in your log at all ...
<luis_> sweet.
<luis_> my dep problems after a hoary->breezy upgrade are so bad that they crashed synaptic. :)
<[linesca] > jbailey: Hi
<jbailey> [linesca] : Heya!
<[linesca] > jbailey: you got time to look at these blades
<jbailey> [linesca] : Yup, that's what I'm here for. =)
<[linesca] > jbailey: cool.  I have a clean install of Ubuntu.  What you want next ?
<jbailey> [linesca] : A clean install that doesn't boot, right?
<[linesca] > jbailey: Right
<jbailey> Kamion mentioend rescue mode on the CD yesterday, lemme try that.
<jbailey> (I'm just trying it locally)
<jbailey> Hmm.
<[linesca] > jbailey: OK, I am new to Ubuntu.... I take it at the boot option just enter rescue
<jbailey> Need an i386 boot cd rather than amd64, gimme a sec to burn it.
<jbailey> [linesca] : Looks like it.
<[linesca] > np
<mdke> Riddell, ping
<Riddell> mdke: hi
<mdke> Riddell, hello :) did you see that email from a Geoffrey Ready, pointing out the mistake on the -uk homepage?
<Kamion> [linesca] : yes
<Riddell> yes
<[linesca] > Kamion: cool ta
<mdke> Riddell, better change "Britain" to "UK" or Kamion will get you...
<CarlFK> Kamion - just ran the same install using the new iso - still no wget, but it did let me "exit the base sys config" without erroring 
<Kamion> did it throw you into aptitude?
<CarlFK> no.  put me at a login: prompt
<Kamion> I think I'm really going to have to look at this myself, sorry - it's too hard to debug remotely
<CarlFK> oh yeah, you said wget isn't sposed to be there, so that is fine too
<Kamion> no, it's not fine
<Kamion> it's not supposed to be there before pkgsel runs successfully, but finish runs after pkgsel
<Kamion> so that implies pkgsel failed, which should not have happened without kicking you into aptitude or displaying some reason why it failed or something
<CarlFK> ah
<[linesca] > Kamion Jbailey: I am now in rescue mode
<jbailey> [linesca] : Lovely, my CD burn just finished and I'm rebooting.
<Kamion> mvo: can I inject my own commands into the apt status protocol assuming I prefix them with _ or something?
<[linesca] > Jbailey: Perfect timing :)
<jbailey> I haven't played with resuce mode before.  I usually go into the menu and load the drivers that I need and such
<Kamion> mvo: I'd like to be able to use _start and _stop to control my debconf progress bar widget
<Kamion> jbailey: it's really just an automation of that
<jbailey> Kamion: Ah, sweet.
<Kamion> I got bored of explaining to people how to do it themselves
<mvo> Kamion: yes, that should be ok
<Kamion> and got somewhat bored of doing it myself, for that matter
<Kamion> mvo: thanks
<jbailey> Kamion: ;)
<Zomb> hi
<Zomb> mozilla in Hoary (sec. update) dies with: INTERNAL ERROR on Browser End: No manager for initializing factory?
<Zomb> a known problem?
<siretart> any extensions installed?
<bob2> did you restart it after updating it?
<Zomb> siretart: nothing special. Dies even on fresh user accounts.
<CarlFK> Kamion - do you want ssh access to the box?
<Kamion> CarlFK: nah, it's ok, I'll look at the problem later today
<Kamion> but I'm writing other code just now
<jbailey> Kamion: Ooo, aside from the black on white text, this is just lovely.
<Kamion> jbailey: oh, in the shell, you mean? yeah, bterm ...
<Zomb> oh, Ubuntu packages are not an option, using upstream firefox again
<CarlFK> no prob - I just wanted a box I could try to build transcode on, and I think I have that now
<jbailey> Kamion: Thanks for the hack. =)
<sivang> [linesca] : what machines do you try to install on?
<jbailey> [linesca] : Cool, so now do:
<jbailey> [linesca] : mount /proc
<[linesca] > sivang: HS20 Blade
<jbailey> [linesca] : Actually mount /sys is better
<Zomb> oh, sorry, it's caused by java
<[linesca] > jbailey: got the whole lot mounted at the moment
* jbailey waffles for a bit tryinig to remember the best way to find out which scsi driver is powering sd
<jbailey> [linesca] : cd into /proc/scsi
<jbailey> If you do ls -al, there should be a directory or two in there, what are they?
<[linesca] > jbailey: hold two, phone is going
<jbailey> [linesca] : I'm patient
<[linesca] > customers.......!
<sivang> [linesca] : I an trying to make mine work on the pSeries :)
<jbailey> [linesca] : I'm not allowed to rant about customers in Ubuntu channels ;)
<[linesca] > jbailey: life would be so much easier if they were not aloowed to touch stuff :)
<[linesca] > sivang: nice
<[linesca] > jbailey /proc appears empty
<jbailey> [linesca] : Umm.   You said earlier you had the whole lot mounted.  Did you do a mount -a?
<jbailey> That  ought to have caught it...
<[linesca] > jbailey: just mounted root fs from rescue dialogue
<jbailey> Oh, I see. =)
<jbailey> Please type mount /proc
<zul> jbailey: you rant anyways :)
<jbailey> zul: Only about you, dear, and last I checked you weren't a customer. =)
<[linesca] > jbailey: sorry, I am in.....It contains device_info mptscsih scsi sg usb-storage
<jbailey> *grumble*
<jbailey> I wonder why initrd-tools didn't load that?
<bddebian> Howdy
<mdke> tseng, http://tseng2.ath.cx/~ubuntu-docs/ is lost again
<doko> seb128: according to main inclusion queue glitz is already approved for main. Kamion, mdz, elmo: please move it to main
<jbailey> [linesca] : Let's actually check first to make sure that this is really the problem.
<jbailey> [linesca] : 'cause I'm fairly certain that I dealt with mptscsih a year ago.
<jbailey> [linesca] : Please do mkinitrd -k -o /tmp/foo
<[linesca] > jbailey: done
<jbailey> [linesca] : Hop into the directory that it told you about.
<[linesca] > jbailey /proc/scsi ?
<jbailey> No, the mkinitrd command should've told you that the temp directory for /tmp/SOMETHING
<[linesca] > jbailey : done
<jbailey> [linesca] : There should be a modules and a modules.2 file in there
<jbailey> [linesca] : cat them please and look for mptscsih ?
<[linesca] > jbailey: it is in both
<luis_> daniels: do you have a report of xlibs pre-installation scripts failing?
<jbailey> [linesca] : This really sounds like it's not the problem we're having then.
<jbailey> [linesca] : Please do a mount -a
<jbailey> [linesca] : Is your keyboard ps/2 or usb?
<[linesca] > Jbailey: PS/2
<ogra> luis_, tons :)
<jbailey> [linesca] : Cool.  Please edit (using vi or whatever) /etc/mkinitrd/mkinitrd.conf
<jbailey> You'll see a "DELAY=0" in there, please change it to 5
<mdke> elmo, have recovered the linode server, is there any chance you can point http://docteam.ubuntu.com at it?
<[linesca] > jbailey: customers again, back in two
<jdthood> Has anyone reported problems starting the latest OOo?
<jbailey> jdthood: It doesn't install for me, so.. =)
<jdthood> 'OpenOffice.org cannot be started due to an error in accessing the OpenOffice.org configuration data.  Please contact your system administrator.  The following internal error has occurred: GetStorage, name: "No Content!'
<luis_> works fine here, except for the normal 'longer to startup than any other app on this machine by a factor of 2, at least'
<jdthood> OOo version 1.1.4-5ubuntu1 except for -debian-files which is still 1.1.4-3+2ubuntu1 in the archive
* pitti grumbles at control-center FTBFS
<daniels> luis_: like fifty
<daniels> luis_: you can have some of mine if you like
<[linesca] > jbailey: sorry about that  it is done
<jbailey> [linesca] : Cool.  So I'll get you to do
<jbailey> [linesca] : mkinitrd -o /boot/initrd.img-$(uname -r)
<jbailey> [linesca] : And then reboot.  The will put in a five second pause at startup
<jbailey> [linesca] : First time, I want you to try letting it continue to see if it really is just the scsi bus waking up slowl.
<jbailey> [linesca] : And failing that it will also let us drop into a shell to polke around.
<[linesca] > jbailey: np
<[linesca] > jbailey: that failed :(
* jdthood sighs and installs OOo from hoary
<jbailey> [linesca] : did it say 'pauasing for 5 seconds' ?
<[linesca] > np: yep, I am now in a shell
<jbailey> [linesca] : But just waiting for 5 seconds gave the same failure as before? 
<[linesca] > jbailey: Yes it did
* Kamion sighs and reaches for the big strace -f hammer
<Kamion> on base-config. grumble.
<Kamion> 99MB trace, whee
<pitti> Morning lamont!
<mvo> Kamion: I commited the fixed apt--progress-reporting to baz. it should keep your fds now. please report any problems you may find :)
<Kamion> mvo: great, thanks. I'm fighting with FIFO handling in base-config at the moment; will test once I've resolved that
<elmo> mvo: ?
<mvo> elmo: ?
<elmo> mvo: is this apu-* stuff planned for main?
<mvo> elmo: eventually, but universe is fine for now, I haven't done the MainInclusionReport stuff (yet)
<mvo> Kamion: thanks
<elmo> mvo: not to be a kill joy or anything, but a couple of things scare me
<elmo> mvo: 'update' is very generic as a username isn't it?
<elmo> mvo: and can  this random editing of /etc/sudoers possibly be policy compliant?
<mvo> elmo: probably not, but it's meant for clients that should be automatically managed
<mvo> elmo: if the admin has to walk over for each client and edit sudoers (and sources.list and friends) by hand there wouldn't be much point in having the package
<mvo> (IMO)
<elmo> well, sure, I can see why you're doing it; it's just well...
<mvo> elmo: I'm open for better ideas of course. I think I will (at least) add a big fat warning in the package description of the client that it should _only_ be installed if the machine should be part of a apu network
* mvo is away for 30min now, sorry
<jdthood> pitti: #12276 is assigned to alsa-driver.  What should be done about it?
<pitti> jdthood: well, it's a bug in the kernel drivers; it should probably be reported upstream
* Kamion -> town for a bit
<mdz> doko: according to main inclusion queue, glitz was already promoted
<pitti>      glitz | 0.4.3+cvs20050728-1ubuntu1 | http://archive.ubuntu.com breezy/universe Sources
<pitti> hm, obviously not yet
<elmo> doko: ?
<doko> mdz: according to http://people.ubuntu.com/~lamont/buildLogs/libc/libcairo/0.6.0-0ubuntu3/libcairo_0.6.0-0ubuntu3_20050803-1548-i386-failed.gz, not yet
<doko> elmo: pong
<elmo> doko: are you sure all these c++ libs, only have the c++ transition as the ubuntu change?
<elmo> [Updating]  imagemagick (6:6.2.3.1-1ubuntu1 [Ubuntu]  < 6:6.2.3.4-1 [Debian] )
<elmo> and that's a UVF
<doko> elmo: ouch. I did check those, and mentioned these with new upstream versions explicitely. obviously I missed imagemagick
<elmo> the rest are safe to sync tho, right?
<doko> elmo: yes, all do have the very same library package name
<mdz> elmo: glitz doesn't seem to show up in anastacia output, though libcairo build-deps on it
<elmo> mdz: the libcario upload probably post dates the last cron.sync run
<elmo> rerunning it
<elmo> mdz: you can rerun cron.sync arbitrarily, but just be careful you don't clash it with cron.daily or germinate + anastacia will get all kinds of confused
<elmo> unfortunately (esp. with edubuntu) it's really too  slow to run every cron.daily
<ogra> elmo, anything i can do to not be the bad guy here ? 
<ogra> :)
<mdz> oh, I didn't realize this was a new situation
<mdz> I assumed from the fact that it already had a main inclusion report, and that doko expected it to be promoted, that it had been this way for a while
<elmo> Date: Wed,  3 Aug 2005 00:25:13 +0200
<elmo>    * debian/control, debian/rules:
<elmo>      - build with glitz.
<elmo> I'm guessing based on that changelog
<elmo> ogra: it's not edubuntu particularly, germinate's just not very fast.  well and jackass is getting a bit old in the tooth
<doko> mdz: libatomic-ops was built with gcc-3.3, not 4.0
<jamesh> there's not that much of a reason to link cairo to glitz
<ogra> elmo, time for an upgrade ;)
<jamesh> given that the current plan for acceleration is for Cairo to use RENDER, and have the X server accelerate RENDER using glitz
<seb128> jamesh: according to doko OO.o wants it
<doko> jamesh: OOo2 wants a glitz enabled cairo, if cairo is enabled at all for the OOo2 build.
<mvo> elmo: I thought a bit about the problem (with apu-client) and I'll do it differently now. thanks for your comments
<elmo> mvo: ok - mind if I reject the existing packages for now?
<mvo> elmo: fine with me
<elmo> doko: grr
<elmo> taglib in Debian is producing libtagc0
<elmo> as opposed to our libtagc0c2
<mdz> elmo: could anastacia delimit the binaries with spaces rather than commas, for better cut-and-pasteability?
<elmo> mdz: sure, done
<mdz> thanks
<doko> elmo: correct, I need to rebuild the depending package (streamtuner)
<azeem> is libtagc0 a C++ library?
<azeem> there is libtagc1c2 in Debian
<azeem> eh, libtag1c2
<elmo> azeem: I think it's a C++ in C thing
<elmo> there's something about it in the changelog
<azeem> so the Debian NMU was incorrect?
<elmo> no
<elmo> or, rather I don't know
<elmo> or much care - I'm just going to trust doko, and beat him up later if he's wrong ;)
<azeem> well, Ubuntu and Debian transition in a different way
<elmo> azeem: err, no they don't?
<doko> according to the changelog, it does have a C API, so the name should not be changed. I'll check aggain
<azeem> 17:54 < elmo> as opposed to our libtagc0c2
<azeem> well, *shrug*
<elmo> azeem: right, but it was an unrecoginsed C++ implemented in C thing
<elmo> we still transition in the same way, when we both recognise real C++ libraries
<azeem> aha.
* azeem makes a face as if he'd understood
<doko> elmo: I still look healthy ;)
<lamont> The following packages have unmet dependencies:
<lamont>   archdetect: Depends: libdebian-installer4 (>= 0.31)
<lamont>   kbd-chooser: Depends: libdebian-installer4 (>= 0.31)
<lamont> sucks to be amd64
<Kamion> lamont: what's that, a d-i build?
<Kamion> libdebian-installer4 |       0.31 |        breezy | amd64, hppa, i386, powerpc, sparc
<lamont> yeah, this mornings
<Kamion> I assume a retry would work
<Kamion> but libdebian-installer4 0.31 has been there for a while
<lamont> probably
<Kamion> like, four or five days
<Kamion> -rw-r--r--  1 lamont buildd 14455 Jul 28 16:49 libdebian-installer_0.31_20050728-1648-amd64-successful.gz
<elmo> it's been failing for several days now
<elmo> the d-i daily build I mean
<Kamion> Unpacking libdebian-installer4 (from .../libdebian-installer4_0.30_amd64.deb) ...
<Kamion> doesn't it auto-'apt-get update'?
<Kamion> 'cos I have no idea where it's getting that .deb from unless it's its local cache
<elmo> modern sbuild does - I would hope ours is synced enough to do that
<dilinger> is there a backports site for hoary/ubuntu?
* dilinger is not looking forward to building evolution 1.2.3 for hoary
<lamont> elmo: modern buildd does
* lamont checks to see if BuildDI is a bad boy
<elmo> err, buildd right
* lamont beats his head on the desk in shame
<lamont> good catch elmo
<lamont> Kamion: and thanks for pointing me in the right direction
<Kamion> ah, good, glad it wasn't my fault ;)
<ogra> dilinger, talk to Mez, he should make a wikipage with a list 
<lamont> Kamion/elmo: you want an amd64 daily today, then?
<Kamion> lamont: *shrug* can live
<elmo> lamont: not fussed
<seb128> elmo, Kamion: can you move libexif12 to main? soname change ...
<elmo> seb128: done
<seb128> thanks
<seb128> (s/can/could)
<doko> pitti: when was our meeting with carlos, I remember 16:30 UTC ?
<carlos> doko, in 40 minutes
<doko> ah, ok
<carlos> but I'm already here so if you want to do it earlier, is ok for me
<pitti> doko: 1730 UTC, I think
<pitti> carlos: I still need some time to discuss with jdthood 
<carlos> ok
<nomeata> Why is murphy suddenly not accepting my mails?     SMTP error from remote mailer after end of data:    host murphy.debian.org [146.82.138.6] : 550 Error:    improper use of 8-bit data in message header
<elmo> nomeata: err, -ECHAN
<Kamion> elmo: crap, I entirely forgot something about the ubuntu-base split. Could you please add "Task: ubuntu-standard" headers to the breezy Packages files for stuff in germinate's 'standard' outputs, the same as is done for ubuntu-desktop?
<Kamion> this might be one reason CarlFK's network installs have been going a bit weird
<elmo> Kamion: ok - mostly done, will finish/test when this cron.daily is over
<Kamion> elmo: cool, thanks
<Kamion> sometime, kubuntu-standard and kubuntu-desktop Task lines would be nice too, although I appreciate the potential combinatorial explosion
<elmo> and edubuntu-* presumably too?
<Kamion> yeah
<elmo> ok
<Kamion> although I'm not sure if there's a target for netboot installs of edubuntu
<Kamion> it doesn't matter for CD image installs, debian-cd fills stuff in itself
<nomeata> elmo: oops. right. I have to get used to being in two -devel channels now :-)
<ogra> Kamion, people smart enough to use netboot should be able to just install edubuntu-server and edubuntu-desktop on top of a minimal system...
<Mez> infinity or lamont, ping
<ogra> so one netinstaller iso should be enough...
<Kamion> ogra: I don't particularly want netboot to be for people who are "smart enough"
<Kamion> ogra: the point is base-config goes wrong in a non-obvious way
<ogra> oh
<ogra> ok
<Kamion> that said, there aren't actually netboot images available for Kubuntu or Edubuntu with the appropriately-twiddled preseeds at the moment, so you're right that the bar is somewhat higher than it is for Ubuntu netboot
<ogra> yes, but i'm rather interested in a liveCD/DVD iso then in a netboot one to be honest
<ogra> s/but//
<Kamion> right, if that's the main target then that's fine
<Riddell> I get quite a few requests for netboot kubuntu
* Kamion nods
<Kamion> I'll try to sort that out closer to release, but my feature freeze targets have to take priority at the moment
<pkern> Does anyone know where I could get source-dependencies for sbuild to get it building for hoary?
* azeem just touched the file it looked for
<elmo> yeah
<pkern> k
<elmo> source-dependencies are obsolete
<pkern> elmo: Also with the stock buildd instead of the debian-admin one?
<elmo> debian-admin one is the stock one now; at least AFAIC
<lamont> Kamion: the daily chroot updates at 0215 DCT made the chroot generally current..
* lamont makes a note to get ia64 boot options together and off to Kamion today or tomorrow.
<pitti> doko_, carlos:  #ubuntu-meeting?
* sivang --> back
<elmo> argh cron.sync is such a hideous freakin mess
<ogra> eeek, glitz broke my pbuilder ?
<seb128> how?
<ogra> checking for gtk+-2.0 >= 2.0.0... Package glitz was not found in the pkg-config search path. Perhaps you should add the directory containing `glitz.pc' to the PKG_CONFIG_PATH environment variable Package 'glitz', required by 'cairo', not found
<ogra> configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; 
* ogra will just wait
<seb128> sure, waiting is the wait to get bug fixed
<seb128> I guess that libcairo1-dev should Depends on libglitz-dev
<ogra> seb128, glitz isnt in main yet if i understood correctly
<seb128> no, that's not the issue you have
<ogra> oh
<seb128> cairo.pc probably mentions glitz
<ogra> likely... according to the error
<seb128> Requires: fontconfig libpixman xrender libpng12 glitz
<ogra> yup
<seb128> and glitz is main atm
<ogra> oh... it wasnt this morning iirc
<Kamion> I don't understand, glitz is in main now and it does sound as if libcairo1-dev should depend on libglitz1-dev if its .pc file has that dependency
<Kamion> oh, sorry, seb128 said that
<seb128> <seb128> I guess that libcairo1-dev should Depends on libglitz-dev
<seb128> I'm fixing atm
<Kamion> I thought ogra said that and seb128 contradicted, so I got very confused, whoops
<ogra> Kamion, i just misunderstood the error seb128 clearified...
<seb128> fix uploaded
<elmo> Kamion: ok, all done - {,k,e}ubuntu-{desktop,standard} tasks - can you check override.breezy.main.extra and make sure it looks sane?
<mxpxpod> is there a way to get horizontal scrolling using the microsoft bluetooth explorer mouse in xorg?
<Kamion> elmo: yes, looks pretty much OK to me
<sabdfl> jbailey: hiya - could you fix bzr in breezy please?
<bddebian> Wow, now that is a greeting :-)
<sabdfl> usually followed by kthxbye ;-)
<trygvebw> wow, it works :D
<jbailey> sabdfl: Yes, dear. =)
<sabdfl> thanks honey ;-)
<bddebian> heh
<Treenaks> And the predictions come true :) Novell is going to create "OpenSuse", to get more community participation
<Treenaks> http://news.com.com/Novell+seeks+outside+help+with+Linux/2100-7344_3-5816079.html
<sabdfl> bddebian: he gets this much tenderness because his hair is longer than mine
<sabdfl> yay! good for them, finally
<Treenaks> yeah, maybe it'll fix the issues I'm having with suse on my work desktop
<Treenaks> sabdfl: and they copy well:
<Treenaks> sabdfl: Novell plans to distribute Suse Linux CDs in magazines, at trade shows and meetings, and possibly by sending them to those who just ask.
<sivang> hehe
<bddebian> sabdfl: Scary ;-)
<Treenaks> -- news.com.com.com
<sivang> sabdfl: how does it feel to be a pioneer :)
* sivang knows that no-one would steal his love for ubuntu
<jbailey> sabdfl: Ah.  By 'fix' you mean put it in there at all? =)
<elmo>        bzr |  0.0.5-2.1 | breezy/universe | source
<jbailey> Ah, a pile of failed builds.
<sivang> Treenaks: so nice to see that Ubuntu doesn't need to be "open" , it already is :)
<Treenaks> sivang: I mailed the link sounder :)
<Treenaks> +to
<HiddenWolf> Ah, well, it's good for the linux community in general
<HiddenWolf> Just hope that not too many people get put off by them. :P
<maswan> heh. OpenUbuntu. that just looks weird.
<Treenaks> maswan: that's just too goatse I guess
<maswan> a 3-handed goatse as logo?
<Treenaks> maswan: Well, "open" -> "more open" -> "goatse"
* Treenaks perls on :)
<bddebian> Better make sure there's no Unixware code in there.. ;-P
<HiddenWolf> About that opensuse thing, I think we can say they did an Ubuntu. How about adding that to wikipedia. ;)
<martinhj> mjg59: ok, I have now tested ACPI events with vanilla 2.6.12.3 from kernel.org on my Acer TravelMate 620.. it works with that kernel, but not with Ubuntu one... I have done some more testing also.. want me to write a bug-report on it?
<mvo> Kamion: did you had a chance to test the improved apt--progress-reporting code? does it keep your fds now?
<Kamion> mvo: I got somewhat sidetracked by realising I had to rewrite a chunk of base-config before I could test it
<Kamion> and further sidetracked by a piece of my network randomly failing for no good reason, so I had to rig up an alternative route via my laptop
<mvo> mdz: just a FYI: apt--progress-reporting contains some more changes to better support net-installs. could you please have a look and consider a merge (once kamion had a chance to do some more testing)?
<mvo> Kamion: ok, no problem. thanks for the update
<Kamion> I'm still on it, though, but only have about fifteen more minutes this evening
<mvo> that's fine, I should stop working too, I'm not 100% concentracted anymore
<Kamion> I'm fine, the freaking world keeps breaking that's all :P
<mvo> heh :)
<mdz> mvo: it changes the API
<mdz> I guess since I haven't released 0.6.40, that's OK
<mvo> mdz: the api? what bit?
<mdz> mvo: Configuration::Clear()
<mdz> it adds two new functions
<mdz> anyway, the soname is already updated in mainline, so it's OK
<mdz> mvo: I've merged to patch-22
<mvo> mdz: yes, it breaks the abi, but the other change did that too
<mdz> mvo: that's what I just said
<mvo> mdz: yes, sorry (was not quick enough). thanks for merging
<mvo> mdz: the two new cleaers where needed because apts configuration class let you not remove a single element from a configuration list. only complete subtrees 
<dholbach> hellas
<pitti> Hi dholbach
<dholbach> hey pitti :)
<ogra> ol
<janimo> hey daniel
<dholbach> janimo: !!! :)
<dholbach> janimo: had some xfce action today?
<janimo> am doing it just now :)
<janimo> hope to get it in shape these days
<janimo> then I'll need to close lots of bugs
<dholbach> :)
<siretart> fabbione: ping
<siretart> does anyone know how fabbione is doing? I haven't read him since some time..
<bddebian> I usually see him come on late at night my time
<mdz> siretart: fabbione is on holiday
<siretart> ah, that explains
<siretart> mdz: I have a friend you would like to offer sparc hardware and hosting to ubuntu, for buildd
<mdz> siretart: fabbione would be the person to talk to about our sparc needs
<siretart> ok. Then my memory didn't fool me this time :)
<pitti> yay, l-restricted modules, thanks mdz!
<siretart> woohoo!
<doko> elmo, mdz, Kamion: please promote libtagc0 to main (package name changed back from libtagc0c2)
<\sh> evening
<sivang> evening \sh , what's cooking ? ;)
<\sh> sivang: well..I just ate some turkish food :) lamacun + dner
<\sh> doko: ping
<doko> pong
<\sh> doko: do I understand the CxxLibraryResync list correct, that we sync all libs back from debian?
<ogra> Mez, somebody asked for a list of all backportaed packages today, could you make a wikipage with a list ? its not the first time this was asked here
<doko> yes, if there are no new upstreams at the moment. however, that's low priority. I just want to have these cases syncs, where the package name in ubuntu and debian diverges
<janimonoses> ogra, what do I need for bugzilla edit privilege?
<Burgundavia> ogra, a page already exists. Look in CategoryArchive on the wiki
<janimonoses> does bugzilla not share accounts with wiki/launchpad?
<ogra> janimonoses, nope
<ogra> janimonoses, please see https://wiki.ubuntu.com/HelpingWithBugs
<janimonoses> so can you enable me editong bugs?
<janimonoses> ok I'll look
<\sh> doko: so we will take the transitioned package from debian and put our ubuntuX version postfix to it? right now it confuses me more then it's helping me
<ogra> janimonoses, i'll enable you again
<ogra> janimonoses, whats your bugzilla login ?
<janimonoses> jani dot monoses at gmail.com
<ogra> janimonoses, use the power wise ... youre empowered ;)
<janimonoses> ogra, thanks :)
<doko> \sh: no, we request a sync from unstable, which usually elmo does handle, without changing the source. the goal is to have these packages autosynced again
<janimonoses> ogra, I logged out then in and still cannot change the resolution field.in fact it is not shown
<janimonoses> ogra, nevermind I see it now
<\sh> doko: ok...but only then, if there is no new upstream release, only debian changes
<mdz> doko: aspell is broken now
<doko> mdz: I'll have a look
<pitti> good night, guys
<mdz> doko: it seems to need a newer dictionaries-common
<janimonoses> no way to control bugzilla by email?
<Amaranth> no
<ogra> hmpf...
<doko> mdz: no, d-c is ok. we now need to sync the dictionaries from unstable. I'm preparing a list
<mdz> doko: The following packages have unmet dependencies:
<mdz>   aspell: Depends: dictionaries-common (> 0.40) but 0.30.2 is to be installed
* Natja is away: Occup
<doko> mdz: yes, just found it
<yann__> seb128  o/
<seb128> hi
<dholbach> hey seb128 :)
<seb128> daniel ! :)
<dholbach> woohoo! :)
<seb128> re dholbach
<seb128> :)
<dholbach> seb128, the gnome-inator is back :)
<doko> mdz: checked, that dictionaries-common-0.49.2 builds and installs fine on breezy. proposing this one for breezy. is an upload urgent, or can the sync wait until tomorrow?
<mdz> doko: does it need a merge or just a sync?
<mdz> argh, the new unionfs seems to break ltsp completely
<doko> mdz: sync only
<mdz> doko: I see no reason to wait
<mdz> if it will unbreak breezy
<elmo> eh, that doesn't mean upload it, instead of getting it synced tho
<doko> elmo: correct
<mdz> elmo: I see no reason to wait [before requesting a sync] 
<dholbach> we're 8 minutes before the motu meeting - if you're interested.... :)
<niktaris> mdz, 
<mdz> ogra: can moodle use php5-gd rather than php4-gd?
<ogra> mdz, i'll be looking at it soon... currently gcompris is on the surgery table here
<dholbach> ogra: a scalpel won't do - you'll need a welding apparatus or something :)
<doko> ogra: you're breaking it down in components?
<mdz> ogra: anastacia output is at people.u.c/~mdz/anastacia.txt
<ajmitch> doko: do you mind boa-constructor being imported from experimental after some testing?
<mdz> ogra: that shows which packages want to enter main (and thus need review and reports)
<ogra> dholbach, yes, i recognized... i just tried a patch cvs vs debian package... its HUGE !
<doko> ajmitch: not at all
<ogra> mdz, ok, i'll go through it
<doko> ajmitch: using wx2.4 or 2.6 ?
<martinhj> with the new battstat-applet, when my battery is fully charged, the icon turns into a battery again even with the power cord connected..
<niktaris> mdz, everything is ok with d-i (was missing a file) what would be needed to make casper work (besides putting it into d-i). It seems to load but complains about not finding the preinstalled session
<ogra> MOTU meeting starts in #ubuntu-meeting
<ajmitch> doko: 2.6
<mdz> niktaris: you need to provide an ext2+cloop filesystem image
<mdz> that is sort of the core of a live CD, the filesystem image
<niktaris> mdz the cloop filesystem is there. What do you mean by ext2 ?
<doko> mdz: do you care about UVF for monotone (0.20 FTBFS in breezy, 0.21 compiles)
<mdz> niktaris: cloop is not a filesystem
<mdz> doko: UVF is pretty relaxed for universe
<doko> ajmitch: you do use wxversion for the the selection of the wx version?
<niktaris> mdz a compressed filesystem
<doko> mdz: fine.
<doko> elmo: please sync monotone
<mdz> niktaris: cloop compresses a file, any file.  in the case of casper, that file must be an ext2 filesystem.
<ajmitch> doko: that's why was asking what is best, I wasn't sure what changed with recent wx
<ajmitch> doko: it currently depends on wxpython2.6-0
#ubuntu-devel 2005-08-09
<doko> ajmitch: please make sure, that before an import of wx, you call:
<mdz> ogra: you forgot to include sdl-image1.2 in the tuxpaint main inclusion report
<elmo> ajmitch: did you get the libsdl-sound bug report, btw?
<mdz> Riddell: qca-tls has a main inclusion report, but it is neither seeded nor pulled in by a dependency
<ogra> mdz, i havent worked on the list yet, i'll update it soon, there is more stuff to add
<ajmitch> elmo: which one?
<elmo> #1628, IIRC
<doko> elmo: if you're still awake, please sync gcc-defaults from unstable (again), and java-gcj-bootstrap (from incoming)
<elmo> https://launchpad.net/malone/bugs/1628
<ajmitch> ok, will fix
<doko> wow, l-r-m in the build logs ...
<niktaris> mdz, do I need to change anyting in initrd.gz or someplace else?
<Riddell> mdz: hmm, I'm sure I added it to the seeds.  I'll do that now
<elmo> doko: meh, done
<doko> elmo: thanks :)
<Amaranth> holy crap, l-r-m
<tseng> Amaranth: huh?
<Amaranth> linux-restricted-modules
<Amaranth> i don't think it should be trying to build on ia64...
<tseng> i dont see it on -changes
<ogra> tseng, look harder, its there :)
<tseng> oh
<tseng> i sitll have a search up
<tseng> for sebastian
<Amaranth> it built on i386, ppc, and amd64
<tseng> which is suprisingly very active :)
<tseng> or, not suprising
<mdz> niktaris: I'm not sure, since I don't know where your initrd.gz came from
<mdz> Riddell: ok, I'll go ahead and move it
<mdz> jdub: what's the story with howl?
<niktaris> mdz, it's a standard sarge initrd.gz from the netinstall iso
<Riddell> mdz: I've added to seed now
<mdz> Riddell: are the gnupg2 dependencies coming back, or can gnupg2 move out to universe?
<janimonoses> anyone encountered build breakages in the ./configure stage when pkg-config checks fails even if the package providing the .pc file is supposed to be installed according to the log?
<janimonoses> see latest xfprint4
<janimonoses> http://people.ubuntu.com/~lamont/buildLogs/x/xfprint4/4.2.2-1/xfprint4_4.2.2-1_20050803-1759-i386-failed.gz
<mdz> Riddell: likewise for libassuan, pinentry, pcsc-lite and some others which originally came in as kubuntu deps for hoary
<Riddell> mdz: depends if we want to support s/mime x.509 stuff in kmail
<dholbach> we're having a discussion over packaging standards might somebody join us for an answer everybody can live with afterwards? :)
<ogra> could any more experienced packager join the motu meeting for one topc... ?
<mdz> Riddell: what changed between hoary and breezy?
<jdub> md	mdnsresponder is apsl2
<Riddell> mdz: as far as I remember amu added depends on kleopatra to kdepim and build-depends on gpgsm for hoary but removed them again before the final hoary
<shaya> mdz: you here?
<shaya> couldn't parse your unionfs bug
<mdz> shaya: yes, I am
<mdz> shaya: which part was unclear?
<shaya> where it actually oopsed in unionfs code for one
<mdz> stand by
<mdz> unfortunately I have no way to cut and paste, since it's from a PXE boot of a system with no serial port
<mdz> I'll bring up the full trace
<shaya> hmm
<shaya> it could very well not be oopsing in unionfs code, but that makes it much harder to debug
<mdz> shaya: are you saying that the assertion failure is innocuous?
<shaya> no
<shaya> you didnt post the assertion
<shaya> oh
<shaya> didnt see that
<shaya> woops
<niktaris> mdz, talking about unionfs... did you know that fabian franz added unionfs support to casper ?
<mdz> the subject was a bit mangled because the mailing list rejected it the first time
<mdz> niktaris: no, he never sent me any patches
<mdz> I have a half-finished implementation in my working directory here
<mdz> shaya: EIP is at unionfs_open+0x3507+0x79d1
<niktaris> I can point you to a link if you want
<shaya> yes
<shaya> I see it now
<mdz> I don't know why that doesn't show up in the call trace
<shaya> mdz: is this repeatable w/ plain nfs and tmpfs and unionsfs?
<shaya> i.e. no pxe
<mdz> I'll give it a try
<shaya> perhaps just set it up plain and chroot into it?
<mdz> yep, going to try that
<shaya> makes it easier to reproduce
<niktaris> mdz, http://debian.tu-bs.de/knoppix/skolelive/d-i/
<niktaris> there is a casper.diff
<mdz> niktaris: it doesn't add unionfs support, so much as replace the existing device-mapper code with unionfs code
<mdz> my implementation adds it and allows for the method to be selected at runtime
<mdz> but I don't think it will make it into breezy
<shaya> mdz: unionfs is still a bit rough around the edges to say the least :)  I get stuck from time to time trying to solve bugs just to get my research done
<niktaris> mdz I tried fabian's capser and it work only the locale didn't seem to go to the system...
<mdz> shaya: yes, it's reproducible in a normal setup as well
<mdz> shaya: different call trace
<mdz> but then, I have no idea what the first call trace looks like in the netboot setup, because I get about 10 in a row
<shaya> yea
<shaya> mdz: once an assertion is thrown, you are dead
<shaya> i.e. I've had it oopse forever on me
<shaya> :)
<shaya> or at least it seemed like forever until I power cycled the machine to get it to move on
<niktaris> mdz, changed the initrd. still no go. var/log/syslog says something about the ext2 module missing
<shaya> an assertion basically causes it to oops and it can get caught in a chain
<mdz> shaya: 1.0.12a had been fairly solid; I encountered a few bugs but nothing which was a showstopper for me
<mdz> this latest one has completely killed ltsp development for me
<shaya> so why use .13?
<shaya> why not stick w/ .12a?
<shaya> mdz: other option might be to binary search the snapshots for where the problem was introduced?
<mdz> shaya: because I didn't know that .13 was broken until we upgraded to it
<shaya> :(
<shaya> can't downgrade?
<mdz> we certainly could
<shaya> mdz: in regards to ltsp stuff, paper my group http://www.ncl.cs.columbia.edu/publications/mobicom2004_fordist.pdf
<mdz> it involves a whole new kernel release
<mdz> and fabbione is away
<shaya> speaking of which, there's no restricted modules yet
<shaya> haven't been able to run new kernel b/c of that
<shaya> need my atheros
<mdz> shaya: I guess you don't read breezy-changes
<shaya> there's no more restricted?
<tseng> shaya: mdz is the hero of the day.
<shaya> oh there is
<shaya> today
<mdz> shaya: breezy-changes is a mailing list which notifies you of uploads to breezy
<shaya> wow
<shaya> mdz: aptitude does a good job of that as well :)
<shaya> and the package has hit the archives
<shaya> yay
<shaya> or not
<shaya> weird
<shaya> seemed like it pulled restriced's packages.gz for a change
<shaya> mdz: what I generally like to do when I hit an assertion like that is printk the upper dentry's d_name.name (and perhaps parent as well) to get an idea of what I'm dealing with
<shaya> check if the files been deleted (if it's been unhashed) and some other junk
<mdz> shaya: it's only there on powerpc at the moment, due to a bug
<shaya> hmph
<shaya> and here I was getting my hopes up to reboot today
<mdz> I just uploaded a fixed version
<shaya> do aspell-bin and aspell-en packages not exist anymore?
<shaya> weird that the library was rebuilt but not those packages
<dholbach> good night everybody
<mdz> shaya: I wonder what it is about my setup which is different; clearly 1.0.13 works for others
<mdz> shaya: is it working for you?
<shaya> I acutally haven't used it yet
<shaya> as in paper mode
<shaya> so have a working snapshot that does my needs
<shaya> I also use it with GFS
<shaya> which brings about its own world of hurt
<mdz> it seems to work for me with tmpfs-over-ext3
<mdz> so maybe it's nfs-related
<shaya> or unionfs not understanding tmpfs semantics
<shaya> I mean nfs
<shaya> each fs seems to have their own semantics for different funcitons
<shaya> such as d_revalidate
<shaya> GFS returns a failure if you try to revalidate a deleted dentry
<shaya> though every other fs I tried doesn't seem to care
<shaya> there's no good documentation that says what the func is supposed to do
<shaya> mdz: can you recompile unionfs w/ a small patch?
<shaya> just wondering what dentry it's failing on
<shaya> printk("dentry %s in %s\n", dentry->d_name.name, dentry->d_parent->d_name.name);
<shaya> sticking that right before the assertion
<shaya> like 438 in commonfops.c
<mdz> yeah, I can try that
<shaya> then you can try to do some post portum by looking at the underlying FSs and seeing what's there
<shaya> mortum
<shaya> anyways, off I go for a bit
<mdz> shaya: interesting; it produces some warnings (which are turned into errors) with gcc-4.0
<mdz> /home/mdz/src/unionfs-1.0.13/subr.c: In function create_whiteout:
<mdz> /home/mdz/src/unionfs-1.0.13/subr.c:51: warning: pointer targets in passing argument 2 of strncat differ in signedness
<mdz> /home/mdz/src/unionfs-1.0.13/subr.c: In function unionfs_refresh_hidden_dentry:
<mdz> /home/mdz/src/unionfs-1.0.13/subr.c:279: warning: pointer targets in passing argument 1 of lookup_one_len differ in signedness
<ogra> mdz, is unionfs separated from the kernel ? i thought it was a module
<mdz> ogra: unionfs is a module which is built with the kernel
<ogra> mdz, why do you build it with gcc-4.0 then ? the kernel uses 3.4 afaik
<mdz> ogra: because gcc-4.0 is the default and I forgot to force it
<ogra> ah, i jus had the case yesterday with ndiswrapper on amd64.... :) (we should add amd64 to the target arches for ndiswrapper btw)
<Lathiat> who handles the white listing for breezy-changes?
<ogra> Lathiat, see the Uploads wikipage
<Lathiat> ogra: i did, and i emailed a few days ago and waiting, wondering if i can annoy someone about it
<ogra> Lathiat, elmo sits on the other end of this mail adress if it didnt change yet...
<Lathiat> i mean it might have been added silently, i assumed i'd get a reply
* ogra cant remember if he got one for whitelisting
<lexhider> am I meant to report breezy goals via bugzilla or malone?
<lexhider> s/goals/bugs
<bob2> malone for universe, bugzilla for main
<|QuaD-> hmm, my X ALMOST works... it loads the server, just shows jibberish and can't use the keyboard to switch to terminal (though i did change my xorg.config to have kbd)
<shaya> I haven't been able to switch to vt terminal for a while
<shaya> as well
<shaya> so if anyone knows the fix, I'm all ears
<|QuaD-> shaya: does gnome/kde work for you?
<shaya> yes
<lexhider> me neither, I hadn't notice until you just said then.
<shaya> everything works besides switching VTs
<ogra> shaya, i dont remember it correctly, but something about installing xkeyboard-config and xkbutils
<|QuaD-> lexhider: do you have the same problem i do?
<ogra> shaya, en_US keyboard ?
<shaya> hmm
<shaya> how come nothing pulls in xkbutils?
<ogra> shaya, lost in transition currently ;)
<|QuaD-> how do we restart our xserver (or start it) without startx?
<ogra> gdm should work... it does here
<bob2> |QuaD-: X
<|QuaD-> ogra: it doesn't here.... i might have fixed it, how do i restart X?
<|QuaD-> thanks bob2 
<lexhider> |QuaD-, no, same as shaya, xorg is working for me on breezy
<lexhider> |QuaD-, X instead of startx?
<lexhider> or sudo /etc/init.d/gdm start
<lexhider> for "System->LogOut->Hibernate" is the "save current setup" option irrelevant???
<ogra> it doesnt stop your session
<ogra> so i would say its irrelevant
<lexhider> ok, will file bug.
<lexhider> gee bug reporting is a pain over dialup
<bob2> s/bug reporting/& with bugzilla/
<lexhider> yes
<jdub> with *our* bugzilla
<bob2> heh, most places don't have > 1000 products
<glyph> What is the policy that Canonical has regarding synchronizing bzr with upstream packages?
<Lathiat> the product thing needs to be converted to use ajax :)
<bob2> glyph: how do you mean?
<glyph> bob2: I mean, I run a few open source projects, several of which Ubuntu synchronizes, and we are attempting to diagnose why one of our SVN repositories has been crashing 3 times a day for the last 2 days
<glyph> bob2: one suspect is repository synchronization scripts
<bob2> glyph: it's bazaar, not bzr
<bob2> and it's not Ubuntu the distro synchronising it :)
<bob2> but ok
<bob2> try asking in #launchpad
<glyph> bob2: thanks
<glyph> bob2: the problem here is really that svn's logging is so bad that we can't figure out what's happened locally
<bob2> ouch
<bob2> it doesn't even log connections?
<Lathiat> glyph: firewall the sync server? ;p
<lexhider> Currently LeftAlt+Foo does stuff and RightAlt+Foo doesn't. Is this just a breezyXorg is shaky issue or a genuine bug?
<jasoncohen> there was a lot of talk on the ubuntu forums about better autopackage support. I just tested installing newest versions of gaim, gaim-vv and inkscape from autopackages and it worked perfectly and all i had to do was double click, enter root passwd (no sudo support that i'm aware of) and let it install. Any clue what these people were talking about?
<jasoncohen> anyone know why synaptic shows the ubuntu icon next to backports packages? i would imagine this isnt' expected behavior as the ubuntu icon should only be for officially supported packages in main & restricted
<ogra> jasoncohen, file a bug, i think synaptic just isnt adjusted to the new situation yet
<jasoncohen> ok
<lexhider> daniels: Currently LeftAlt+Foo does stuff and RightAlt+Foo doesn't. Is this just a breezyXorg is shaky issue or a genuine bug?
<daniels> lexhider: to some degree, probably a genuine bug.  which layout are you using?
<OddAbe19> daniels, any idea when xorg 7 beta will enter breezy... and any idea of when glx (glx gears/etc) will enter?
<OddAbe19> i've got people wondering on AIM
<tseng> glxgears is useless.
<Lathiat> tseng: whys that?
<OddAbe19> glx in general
<OddAbe19> so people can play games/use gl stuff
<lexhider> daniels, pc105 setup as dvorak, kb is Microsoft natural
<tseng> Lathiat: it has no practical value
<OddAbe19> it shows if GLX is working
<OddAbe19> anyway
<tseng> its in the same class as kde-mr-potato-head
<OddAbe19> instead of saying glxgears is useless, what about my release date question
<bob2> isn't it a little late to be moving to a new major entirely repackaged version of X?
<OddAbe19> we still have 3 months, I have true faith in the X team
<OddAbe19> :-)
<Lathiat> OddAbe19: err, no
<tseng> Lathiat: hm bruce perens is into the Rails scene now
<daniels> OddAbe19: a) it's already there for the most part, b) gl support is totally complete.  glxgears and glxinfo aren't in because I'm incredibly spiteful.
<daniels> OddAbe19: but you can play all the actual GL games you want.
<daniels> lexhider: um, dude, you said pc105
<daniels> lexhider: pc105 -> right alt used as level3
<OddAbe19> cool
<OddAbe19> thanks
<daniels> lexhider: if you want right alt as alt, use pc104
<lexhider> daniels, I'm a bit clueless on this stuff, is that the righ answer.
<daniels> lexhider: (and edit /etc/X11/xkb/symbols/us and remove the include(ralt_level3_multikey) line)
<daniels> lexhider: yes
<lexhider> daniels, ok, is it a bug that pc105 was setup by default instead of pc104? s/pc104/pc105 in xorg.conf?
<daniels> lexhider: did you select the 'dvorak' layout?
<lexhider> yep
<lexhider> daniels, no ralt_level3_multikey in us file.
<daniels>     include "level3(ralt_switch)"
<lexhider> daniels, all 3 instances?
<daniels> lexhider: only the one in dvorak
<lexhider> ok
<lexhider> restarting X back in a minute
<lexhider> daniels: did s/pc104/pc105 in xorg.conf and removed that line from /blah/blah/us, on gnome login given error dialog about XKB configuration, and another dialog to choose whether to use X or gnome keyboard settings
<daniels> lexhider: did you choose X?
<lexhider> daniels: I haven't done either yet
<daniels> choose X
<lexhider> daniels, ok, RightAlt+Foo still not doing anything.
<daniels> lexhider: cool
<lexhider> daniels, cool?
<Lathiat> mdz: champion
<infinity> mdz : Would it be okay to sync devscripts so we can get a debdiff that actually works with the new dpkg-dev?
<mdz> infinity: yes
<infinity> Hrm, I could be on crack, but I could have sworn I saw a thread on ubuntu-devel a while back about people's X cursors getting messed up.  Can't for the life of me find it now, and a freshly upgraded breezy machine is displaying the problem.
<infinity> Maybe it was in the channel..
<Amaranth> infinity: libxcursor-dev
<Amaranth> infinity: install that and cursors work again
<shaya> mdz: I found what's causing your bug :)
<infinity> Amaranth : <blink>
<shaya> unsure how to fix it, but at least found it :)
<infinity> Oh, man, that is wrong on so many levels.
<Amaranth> infinity: this is called a bug :)
<infinity> That means something is loading libXcursor.so?
<infinity> <shudder>
<Amaranth> KILL IT
<Amaranth> woo
<Amaranth> my panel doesn't crash anymore and it updates correctly
<Burgundavia> mine doesn't
<Amaranth> latest gamin and gnome-menus?
<Burgundavia> yep
<Amaranth> have you logged out since upgrading?
<Burgundavia> no
<Amaranth> when i killed gamin and the panel to get them to reload it started crashing
<Amaranth> i rebooted into windows and now back, works perfectly
<whiprush> working sweet here also.
<Burgundavia> jdub, fridge? is it unplugged?\
<daniels> infinity: right, that'd be libX11 being shit
<daniels> remind me to look at it when I have more than 3% battery
<infinity> daniels : Do you have more than 3% battery now, huh, huh?
<sivang> MOrning all
<highvolt1ge> morning, sivang 
<sivang> highvoltage: High Jono, how's the desktop hacks coming? 
<sivang> s/High/hi
<infinity> daniels : Care to lay the smack down on bug 13162, since it's something you feel so strongly about?
<sivang> highvoltage: oops, I confused you with someone else I think
<infinity> daniels : Oh, nevermind, I'm SO behind the times, you already closed it.
<highvoltage> sivang: it depends :)
<highvoltage> sivang: i'm doing a bit of stuff for edubuntu, but i think you might have confused me with jonathan riddel?
<sivang> highvoltage: Hmm, no, I confused you with someone called Jono Bacon , he's an author
<daniels> infinity: no, because I have no idea where my charger is.  i already told you this. :P
<daniels> infinity: must be in one of the seven or so blue bags, I figure.
<Lathiat> ugh gnome-panel is crashign when application files get added
<pef> hello
<Burgundavia> daniels, would you mind setting the record straight on this thread? http://www.ubuntuforums.org/showthread.php?t=54249
<daniels> Burgundavia: the server hasn't been moved over to the modular kit yet, hence no exa.  that'll happen sometime this month.
<Burgundavia> ok
<Burgundavia> thanks
<Burgundavia> daniels, the other question that I know will come up on the forums is binary drivers. Will those break with modular?
<daniels> Burgundavia: nvidia no, ati yes
<Burgundavia> rofl
<Burgundavia> ok
<daniels> Burgundavia: iirc ati haven't yet released a fglrx that works with the libdl-based loader
<daniels> (aka 'dlloader')
<Lathiat> bah who cares about ati
<daniels> evidently not trolls
<Burgundavia> thanks again
<Burgundavia> I have informed the forums
<daniels> np
<Amaranth> So what happens if ATI doesn't release a new driver before october?
<m0ns00n> Hello
<sivang> does anybody know what's the probability of lossing data when resizing and ext3 partition?
<sivang> ogra: is parted stable enough?
<Treenaks> sivang: depends on lots of things
<Treenaks> sivang: (mountedness at resize-time being one..)
<bob2> you should have backups, even if you're not poking your partition table
<bob2> so use your fear of resizing asa good excuse to backup now
<Lathiat> so.. is it possible to get xine to play mp3s?
<sladen> Lathiat: yes
<Lathiat> sladen: how?
<sladen> xine *.mp3
<Lathiat> thanks you were so helpfull
<sladen> Lathiat: what are you not seeing working?
<Lathiat> sladen: totem-xine doesnt recognise it
<Lathiat> i assume it was ripped out
<Amaranth> it's a bad mp3 file?
<Lathiat> "there is no plugin to handle this movie"
<Lathiat> Amaranth: nope, no mp3s will play
<Amaranth> err
<Amaranth> afaik xine isn't moving to main, i don't think anything got removed from it
<Lathiat> hrm
<Lathiat> it used to work
<Lathiat> i think it just hasnt worked since i reinstaslled
<Lathiat> hrm, why does rhythmbxo depend on totem?
<Amaranth> afaik it should only depend on the playlist parser
<Amaranth> but maybe it uses totem to play things now :P
<Lathiat> thats what i thought
* sladen hunts
<Lathiat> Amaranth: ffs, you seein ggnome panel crash everytime the applications directory changes?
<Lathiat> everytime i install a package now it dies
<Amaranth> Lathiat: i was until i restarted
<Lathiat> hrm maybe i need to restart
<Amaranth> logging out might work too
<Amaranth> as long as gnome-panel and gam_server stop completely it should come back on fine
<Lathiat> i usually logout and then drop to a console and pkill -u lathiat
<Lathiat> of course, my ctrl+alt+f1 isnt working atm
<sladen> [pid   798]  open("/usr/lib/xine/plugins/1.0.0/xineplug_decode_mad.so", O_RDONLY) = 16
<Lathiat> anyone else have that problem?
<Lathiat> sladen: do you have the problem that it wont play them?
<Amaranth> Lathiat: nope, try reinstalling xkbutils and/or xkeyboard-config
<sladen> libxine1: /usr/lib/xine/plugins/1.0.0/xineplug_decode_mad.so
<sladen> Lathiat: no.  They've always ''just worked'' for me.
<Lathiat> hrm
<Lathiat> i have that file, fo r1.0.1 tho
<Lathiat> have i picked up som eevil backport or something somehow
<sladen> probably not.  Admittedly I'm looking from a Debian install
<Lathiat> ah right
<Lathiat> thats not goign to help much. :)
<Lathiat> Amaranth: hrm, xkbutils isnt installed
* Amaranth passes out
* Natja is away: Pas l, pas loin
<pitti> Good morning
<siretart> hi pitti. good morning seb128 
<pitti> Hi seb128 
<seb128> hey siretart pitti
<siretart> fabionne working on holidays? ;)
<sivang> hey seb128 , pitti , siretart 
<siretart> hi sivang 
<sivang>  bob2 : right, I should
<Amaranth> seb128: gnome-panel still crash for you?
<seb128> yep
<seb128> not for you?
<Amaranth> nope
<Amaranth> after i restarted it all started working perfectly
<seb128> weird
<seb128> upstream has fixed it anyway
<Amaranth> heh, bug #?
<Amaranth> i couldn't find it
<Amaranth> seb128: btw, what ever happened to bug 310270? you found the problem and proposed a solution, seems to have been ignored
<mdke> i have to manually set my wireless channel each time I boot. is this a bug?
* Natja is back (gone 00:23:12)
<bob2> mdke: ipw2?00?
<mdke> bob2, the driver is acx_pci
<mdke> it doesn't associate unless it set the channel by hand
<mdke> it/I
<bob2> ah
<mdke> i think that is worth a bug report
<Lathiat> yeh thats a bug
<seb128> Amaranth: federico has some other stuff to do for work atm, but he said he will reply on that but not before thursday
<Amaranth> today or next week?
<seb128> today
<koke> who I have to ask for a mailing list??
<Amaranth> jdub?
<bob2> your topic doesn't fit any of the existing ones?
<koke> ok, thanks
<seb128> pitti: any special requirement for python bindings on main stuff? I've put pycairo on the list for main
<pitti> seb128: that's mostly trivial stuff anyway
<Kmorph> have to bail out. see you guys later!
<seb128> pitti: cool, thanks
<trygvebw> hihi
<Amaranth> seb128: good news, the pyxdg dev is back and we're getting things figured out for a new release
<seb128> nice
<tepsipakki> how come the "single-user-mode" sets up networking and mounts all that's in fstab?
<tepsipakki> seems to be the same in debian, but why...
<trygvebw> is there an easy fix for the xkb issue in breezy?
<tepsipakki> that's not very su to me..
<Amaranth> trygvebw: xkb issue?
<Amaranth> trygvebw: you scared daniels away
<trygvebw> :p
<Amaranth> either that or he hit Ctrl-W again
<trygvebw> Amaranth: xkb wont work correctly when i start X, no ae's or oe's etc :p
<trygvebw> :p
<tepsipakki> install xkbutils
<Amaranth> make sure xkbutils and xkeyboard-config are installed
<Amaranth> if they are, reinstall them
<trygvebw> i'm pretty sure they're already installed
<trygvebw> if not a dist-upgrade might've uninstalled them :p
<trygvebw> *checking*
<tepsipakki> i'm pretty sure they aren't ;)
<tepsipakki> nothing depends on them
<trygvebw> you were right :p
<trygvebw> thanks :)
<tortoise_> is an upgrade to breezy safe now??
<ogra> checking for python module gnome.canvas... no
<ogra> configure: error: *** pygtk installed but not visible from python
<ogra> GAH !
<ogra> seb128, ^^^ did they rmove it completely now ??
<ogra> remove even
<ogra> jamesh, ping ? 
<seb128> python2.4-gnome2: /usr/lib/python2.4/site-packages/gtk-2.0/gnomecanvas.so
<seb128> you want this maybe?
<ogra> gar gar gar.... 
<ogra> seb128, can you imagine in how many places i have to fix that in 43MB gcompris source ?
<ogra> *sigh* (deeply)
<seb128> what?
<ogra> gnome.canvas
<seb128> >>> import gnome.canvas
<seb128> __main__:1: DeprecationWarning: Module gnome.canvas is deprecated; please import gnomecanvas instead
<seb128> >>>
<ogra> changing to gnomecanvas
<seb128> but it works
<seb128> install python2.4-gnome2
<seb128> no need to change anything
<ogra> python-gnome2-dev is a dependency... 
<seb128> and changing "gnome.canvas" by "gnomecanvas" is not a big deal anyway
<ogra> so it should work
<seb128> read the config.log 
<seb128> what package is that?
<ogra> yep
<ogra> gcompris *shudder*
* seb128 downloads
<ogra> the current source doesnt build on gcc-4.0 systems... i'm patching cvs on top of it...its very ugly...but complies
<ogra> compiles too
<seb128> what does the config.log says?
<seb128> I'll download that later if required
<ogra> i'll have to build again, my pbuilder doesnt leave a config.log 
<ogra> seb128, nope, its ok, i'll fix it, thanks for the tip... i was just worried gnomecanvas dissapeared completely in favor of cairo
<seb128> nop
<seb128> and deprecated stuff are not trashed anyway
<ogra> oki... nice to know :)
<trygvebw> :/
<trygvebw> i installed all xkb packages, but i still recieve that startup error :(
<Amaranth> trygvebw: System->Preferences->Keyboard, layout tab, reset to defaults
<trygvebw> ill try
<trygvebw> okay
<trygvebw> us layout works, but when i change i get that xkb message again and the keyboard layout settings program crashes :(
<trygvebw> with this in the console:
<trygvebw> ** (gnome-keyboard-properties:7035): CRITICAL **: XkbGetKeyboard failed to get keyboard from the server!
* Kamion bangs his read repeatedly against debconf's redirection weirdnesses
<Kamion> s/read/head/
<trygvebw> heh
<trygvebw> and in addition, xorgconfig is *gone*
<pitti> elmo: centericq sync, please
<mvo> seb128: thanks for fixing #6088 (gaim)
<mvo> s/gaim/gamin/
* mvo grumbles about too similar package names
<trygvebw> wtf
<seb128> I'm not the one which fixed it, I've just updated the package, but thanks :)
<trygvebw> there is no /etc/X11/xkb/symbols on my system :O
<trygvebw> what is the name of the most important xkb packages?
<tepsipakki> install xkeyboard-config
<tepsipakki> as advised
<trygvebw> yah
<trygvebw> it was installed already
<tepsipakki> reinstall it
<trygvebw> ive written my new problem above
<trygvebw> oh wait
<trygvebw> moment
<trygvebw> trying to relog
<trygvebw> hm
<trygvebw> i still get that message on gnome-start, and keyboard settings still crash :(
<trygvebw> this is after reinstall xkeyboard-config
<trygvebw> *reinstalling
<trygvebw> okay, x works now :D
<trygvebw> had to reinstall xlibs, xbase-clients, xkbutils and xkeyboard-config
<pitti> elmo: wordpress sync, please
<janimo> elmo please sync the xfce4 package (a meta), dropping ubuntu changes, thanks
<elmo> pitti / janimo: done
<tseng> whiprush: dude, wouldnt it make more sense to do at least half the rhythmbox/itunes howl stuff with gnomevfs?
<Riddell> elmo: could you sync qt4-x11 from debian (or should I ask permission for new packages first?)
<tseng> Riddell: new universe is ok for now
<Riddell> ok, please sync elmo 
<Mez> lamont/infinity: ping
<\sh> elmo: ping do u have any new informations about the linodeservers?
<seb128> pitti: what's going on with languages packs?
<carlos> seb128, near there
<seb128> carlos: what do you mean?
<pitti> seb128: the last hoary tarball was unusable, so I still have no data; yesterday I asked mdz for a talk about the final structure decision
<carlos> seb128, Breezy import should be finished today or tomorrow, we restarted the process yesterday
<seb128> k
<carlos> and I hope the issues martin raised will be fixed also this week
<seb128> pitti: grumpf ... I understand that's not an easy situation, but translators, users, etc expect getting to get translations updates now
<seb128> pitti: not easy to catch up on what do do when you have no idea of what is not translated and what is due to language-packs
<seb128> k, so this week guys?
<pitti> I'll just go with the split approach if no miracle happens by tomorrow
<seb128> thanks
<Mez> why was libexif deleted?
<seb128> Mez: soname change
<Mez> ah fair enough :D
<Mez> whats the new name?
<seb128> Mez: apt-cache search libexif?
<seb128> it's libexif12
<ogra> seb128, still no luck for me with gcompris... its quite strange, configure runs fine on my system, but breaks in the pbuilder... i've put up the config.log here: http://www.grawert.net/gcompris_config.log
<ogra> seb128, and this is my Dep line: Build-Depends: libgnomeui-dev (>= 2.6.1.1-4), debhelper (>= 4.2.3), libxml2-dev, libao-dev, libvorbis-dev (>= 1.0.0-2), gnuchess, texinfo, texi2html, dh-buildinfo, libassetml-dev (>= 1.1-2), python2.4-dev, python-gtk2-dev, python-gnome2-dev, libsdl-mixer1.2-dev, libxml-parser-perl, libxrandr-dev
<ogra> seb128, could you have a look why it doesnt find gnomecanvas ?
<seb128> ogra: and if you hack the configure to change gnome.canvas by gnomecanvas?
<ogra> didnt work
<ogra> its very strange...
<jdthood> For ALSA purposes we want to add a second .asoundrc file.  We have thought of calling it either '.asoundrc.foo' or '.foo.asoundrc'.  Can anyone think of a reason to prefer one or the other?
<ogra> it works with gnome.canvas locally
<ogra> (i.e. not in the pbuilder)
<jdthood> ... or does anyone have a better suggestion?
<jdub> jdthood: easier to find if it's .asoundrc* ?
<sabdfl> jdub: congrats dude!
<ogra> oh, yes... jdub when do you open a church now ? :)
<jdthood> jdub: Is that a lot easier than .*.asoundrc?  ;)
<jdthood> jdub: I am mainly wondering whether or not there is a precedent already set by some other program that has multiple .*rc files.
<ogra> jdthood, .asoundrc* finds you both files, .*.asoundrc doesnt
<jdthood> ogra: Ah, true
<jdthood> I should have said '.*asoundrc'
<ogra> :)
<lifeless> dark: is x unfucked yet ?
<lifeless> bah
<lifeless> ... is x unfucked yet ?
<tseng> dont ask daniel
<tseng> he's been claiming its been unfucked for weeks.
* tseng wonders if xfce4 will be installable now
<Treenaks> well, it's unfuckedish for me
<ogra> did xfce already build ?
<Treenaks> so he could be right, as I mess with my config manually
<tseng> ogra: thats just a meta package
<ogra> tseng, yes, but a look at the buildlogs says its fine... try it :)
<tseng> boo, kernel update
<ogra> and l-r-m update :)
<tseng> hm no abi break
<Treenaks> l-r-m update?
<tseng> ogra: is lrm built?
<Treenaks> tseng: yes, it built.. but I think it's NEW
<tseng> oh, right
<ogra> yes, but for the last version... it needs a rebuild for the new one i guess
<ogra> there was a linux-meta update afterwards
<Treenaks> 2.6.12-6 -- more ABI breakage?
<tseng> -6 is not an abi bump, dude.
<ogra> err, s/linux-meta/linux-source
<Treenaks> tseng: hm..
<tseng> that would be -7
<Treenaks> I thought it used to be -5
<tseng> 5 was on 28 Jul
<janimo> tseng/ogra xfce is in the process of becoming installable :)
<tseng> janimo: :)
<tseng> ive been waiting a long time to play with the new 4.2 stuff
<tseng> *shiny*
<janimo> tseng, but that stuff was in hoary did you know?
<janimo> 4.2.1.1
<tseng> i havent had hoary in months
<janimo> I am on breezy too but I didn't update to broken xfce4 so I still run the hoary packages
<tseng> heh
<janimo> only the past days did I have time fro ubuntu, but I will have even more shortly ;)
<tseng> great.
<jdub> sabdfl: thanks!
<jdub> ogra: haha
<ogra> :)
<janimo> anybody got the power to force a rebuild of some packages w/o upload?I see lamont is away
<janimo> or what is the interval failed builds are retried
<ajmitch> hi all
<janimo> hi ajmitch
<ajmitch> mpt: .br now?
<mpt> ajmitch: For the past 2.5 weeks and the next few months, yes
<ajmitch> mpt: well it'll be a welcome change from nelson for awhile :)
<ogra> mpt, months ? 
* ajmitch guesses mpt got sick of election year back home
<mvo> seb128: is there a known problem with gtk2.7 and the treeview? I get some odd stuff here with a pygtk custom treemodel
<seb128> nop
<seb128> what "odd stuff"?
<mvo> seb128: columns without content, I'm debugging it right now, maybe my treemodel code
<seb128> k
<ogra> eeek
<ogra> tar: gcompris-7.0.0PRE1/boards/music/background/Brahms__Johannes_-_String_Quartet_C_minor__Op_51_mvmt_4.ogg: file name is too long (max 99); not dumped
<Mez>  hmmles
<Mez> if theres a buildlog saying something built successfully
<Mez> then it shouldnt show up as still building in the lists ... should it?
<mvo> seb128: here is what it looks like, can't reproduce it on hoary http://people.ubuntu.com/~mvo/bad-treeview.png
<seb128> mvo: the empty lines?
<mvo> seb128: yes. happens after I call row_inserted() in pygtk it seems
<herve> hmm... I had a selection list out its box in firefox
<herve> but this could have been a gecko bug
<Mez> any news on the GTK bug tht makes all the fonts look massive
<seb128> Mez: there is no such bug known
<seb128> mvo: do you have a small example for this ubg?
<Mez> seb128, I'mn in breezy, and well, my FF fonts are massive compared to what they were in hoary/what they are in konqueror
<Mez> I'm not too sure if it's only in FF...
<Mez> but in FF it's not just stuff rendered by GTK
<Mez> by FF *
<Mez> It's like, buttons and menus and stuff
<Mez> I share the same home drive between hoary and breezy and it looks different on breezy
<winkle> maybe the autohinter is turned on?
<Mez> autohinter?
<ajmitch> Mez: I had large fonts, but that problem seems to have gone away recently
<ajmitch> fonts appeared to be out by about 2 pt
<Mez> ajmitch, tha'ts about right yeah
<herve> Mez, I saw Mozilla with like 72pt menu bar a few times
<Mez> I've still got the problem like
<Mez> hmm
<Mez> one sec
<mvo> seb128: I figured it out. its a gtk problem that is triggered when I set "fixed_height" mode
<mvo> seb128: it's not strictly a gtk bug, but seting fixed_height too early result in this funny screen
<seb128> k
<seb128> ajmitch: dpi setting was not used by pango/cairo before cairo 0.6 
<Mez> http://dev.kubuntu.org.uk/~mez/screenies/bug.png
<ajmitch> seb128: which is probably why it disappeared after only a couple of days
<Mez> thats a screeny of my problem (comparison between FF and Konq
<tseng> Mez: is that really a "bug"?
<Mez> tseng: yes...
<lamont-away> janimo: which package?
<Mez> tseng: It's showing everything BIGGER than it should be
<Mez> all my settings are the same
<Mez> btu FF is showing it bigger (And all the internal fonts)
<Mez> It's a real pain in the ass.. and looks f**king ugly, and make my browsing prettry unbearable
<Mez> + it throws off the layout of MANy webpages
<Mez> It extends to like, menus aswell
<seb128> does it happen under GNOME ?
<seb128> or is a that kubuntu specific?
<Mez> seb128: gnome wouldnt install for me in breezy, so I havent been able to try yet
<ajmitch> Mez: you haven't backported gtk+ recently have you?
<Mez> ajmitch, this is in breezy
<Mez> theres no backports for breezy
<ajmitch> ok..
<Riddell> Mez: try starting your session using gdm
<Riddell> it's because kdm tries to ask the monitor for pixels per inch while gdm just sets it to a fixed value
<Mez> Riddell, I prefer gdm over kdm and FF iss etup to use the system setting for dpi
<Mez> I changed it to use  /96dpi and now the font looks right in webpages but not in the application itself
<janimo> lamont-away, xfce4-session xfce4-utils
<seb128> lamont-away, infinity: could you push libgphoto2 gthumb eog gimp nautilus builds, they need a retry now than libexif12 is to main
<lamont-away> seb128/janimo: done
<lamont-away> well..
<lamont-away> seb128: I need to look at gimp in a bit - I didn't have any logfile for the trivial give-back
<lamont-away> janimo: xfce4-* given-back
<janimo> lamont-away, thanks, what does given back mean is it a problem?
<tseng> janimo: it means he is building it again.
<tseng> given back to the buildd
<lamont-away> janimo: when a build fails for any reason, the buildd is done with it until told otherwise.
<lamont-away> certain failures are automatically dealt with, others require infinity/me to deal with them.
<janimo> ok I was afraid it was given back to me :)
<lamont-away> janimo: nah - if i was giving it back to you, I'd give you (admittedly pretty terse) reason why it was FTBFS (and would remain so until you re-uploaded)
<janimo> lamont-away  is the distinction described somewhere or is it just secret ancient unwritten foo ?
<seb128> lamont-away: thanks
<lamont-away> build-depends that are missing are automated.  If something you build-depend on is uninstallable because it, in turn, depends on something that is uninstallable, that case isn't automated.
<martinhj> seb128: seen mjg59 latly? I have runned some tests on my computer which he was interested in.. now I haven't seen him active here for many days
<lamont-away> likewise, genuine errors in the compilation are manual, since they are likely to be, well, source-change-requiring
<seb128> martinhj: nop
<janimo> lamont-away, thanks for the info
<lamont-away> np.  that's still way-incomplete, but is a pretty high-level overview
<lamont-away> and on that note, /me -> work
<tseng> have a good one, lamont-away 
<janimo> elmo please sync xffm4, thanks
<Mez> Riddell, still same with gdm
<tseng> mdke: ubuntu-doc is up. linode rebooted me
<tseng> mdke: beta system as i said
<martinhj> does Ubuntu apply any more patches than those in linux-patches-ubuntu-x.x.x?
<Mez> elmo/mdz: ping
<bob2> Mez: oi
<Mez> oi?
<bob2> Mez: python-xdg in some "backports" repository is broken
<janimo> elmo, please sync unison, unison-gtk (gtk2 at last)
<bob2> and makes gnome-app-installer crash
<Mez> bob2: whats the source package?
<bob2> ...presuambly python-xdg
<mako> Treenaks: that's so funny about the suse starting to send free cds
<bob2> Amaranth: fill Mez in on details, kthx
<Mez> pyxdg
<Mez> bob2 - it's in the unofficial it seems :D
<mako> clearly, they're trying to compete with ubuntu
<bob2> ah, indeed, my apologies
<Mez> I'll have a look I need to doa svn update
<mako> the problem with that idea, of course, is that they'll be sending suse cds
<bob2> thanks
<mako> that's basically like sending hate mail
<mako> well, not that bad.. but still ;)
<Mez> wb lamont
<jordi> mako: heh
<philiKON> doko, ayt?
<bob2> he's been idle 14 hours, tho
<bddebian> Hello
<pitti> philiKON: he is away until tomorrow afternoon (ca 1400 UTC)
<philiKON> ic
<philiKON> thanks
<Kamion> lamont: (moving from #debian-devel) yeah, that's fine, build a new daily if you like
<Kamion> WOOHOO, base-config progress bar AND a passthrough question
<lamont> Kamion: well, neither mckinley kernel is booting on my mckinley.... so I'm gonna install an itanium kernel, and if that fails, then I'm gonna be mad
<Kamion> with a fairly seriously hacked-up debconf, but there you go ...
<tseng> Kamion: :)
<ogra> seb128, ping
<seb128> pong
<seb128> Amaranth: around?
<ogra> seb128, the dependency line from python-gnome2-dev seems strange: Depends: python (<< 2.5), python (>= 2.4)
<ogra> shouldnt there be python-gnome2 in ?
<seb128> yeah, probably
<ogra> phew... and i was starting to go crazy with the gcompris error...
<ogra> seb128, thanks :)
<JaneW> Please note that there will be a special BreezyGoals update meeting tomorrow: ** 19:00 UTC on Friday 5 August 2005 in #ubuntu-meeting **
<seb128> grumpf, what a nice day/time for a work meeting :p
<pitti> argh
<seb128> friday evening
<seb128> pitti: oh, you too :)
* pitti cancels the pub meeting
<mvo> JaneW: I may not be able to make it at that time (but I'll try)
<pitti> JaneW: we know that we slack with the goals, but isn't that punishment a bit too harsh? :-)
<JaneW> pitti: I agree, can you suggest another time tomorrow when Matt's up?
<seb128> maybe if we all update the wiki now they will move it? :)
<JaneW> 16:00?
<JaneW> seb128: :P
<seb128> 16:00 would be nicer imho
<pitti> JaneW: we should ask mdz himself; if necessary, I'm available at 1900, too
<Kamion> sorry, can't make 19:00 on Friday
<JaneW> he said he's happy with 19:00
<JaneW> Kamion: 16:00?
<mvo> JaneW: slightly better but I'll only have 1h then. I'll travel from 17:00UTC-20:00UTC :/
<JaneW> 15:00?
<Kamion> 16:00 works as long as it's relatively short; I have to leave no later than 17:15
<Kamion> I have a meeting at 17:30 with the priest who's marrying us
<Kamion> perhaps a bit more notice could be given of whole-team meetings so that we have time to find a suitable time
<JaneW> yes time would be nice, but we are just deciding to do this now...
<JaneW> ok 15:00 or 16:00 we'll go with the consensus...
<Kamion> any chance of using e-mail rather than IRC for this?
<JaneW> ok 15?
<JaneW> Kamion: for you maybe, but I have tried e-mail with very limited success ...
<Kamion> many people avoid paying attention to IRC when concentrating on work, and those that do pay attention may well be asleep
<Kamion> with e-mail, people at least have a chance to object; if they don't object, then silence implies consent
<Kamion> but silence-implies-consent is pretty harsh for stuff decided on IRC
<JaneW> oic, I thought you wants the meeting via e-mail
<Kamion> oh no, clearly not
<Kamion> for deciding a time, I mean
<JaneW> sure I am about the send an e-mail off, I was just feeling the waters first
<Kamion> ok, good
<seb128> pitti: around?
<pitti> yes :-)
<seb128> pitti: are you busy?
<pitti> seb128: no, I just finished my third cocktail and wonder what to do :-)
<pitti> seb128: not more busy than usual, dealing with neverending security holes
<seb128> pitti: is pycairo something easy to review for you? I would like to push pygtk/cairo this week 
<pitti> seb128: I'm sure that's trivial; I also need to finish the libnotify review
<JaneW> Please note that there will be a special BreezyGoals update meeting tomorrow: ** 15:00 UTC on Friday 5 August 2005 in #ubuntu-meeting **
<seb128> k, so if you can push that somewhere on your planning for today/tomorrow that would be nice
<seb128> JaneW: thanks :)
<pitti> seb128: btw, did you see the page? https://wiki.ubuntu.com/MainInclusionReportLibnotify
<seb128> pitti: yeah, I've pointed it to upstream this morning, he said he wish he had a ppc to debug the hang issue
<pitti> seb128: did you test the package already? does it work?
<pitti> seb128: no worries, I'll look into it
<pitti> seb128: the package = pycairo
<JaneW> seb128: glad to see you smiling.
<pitti> JaneW: thanks, 1500 is much more human on weekends :-) this is pending confirmation from mdz?
<seb128> pitti: pycairo? the package example works fine and pygtk 2.7.2 build happily with it
<pitti> seb128: ok, sounds good :-) then it's just a little bureaucrazy, I do it now
<JaneW> pitti: mdz doesn;t love the time, but said he'll conceed because it's short notice and friday :)
<JaneW> we'll most likely be holding these meeting weekly now, most probably on a Thursday (possibly 20:00UTC)
<tseng> weekly..?
<tseng> does this involve all goals?
<ogra> tseng, indeed
<pitti> seb128: odd, a DD created the package and the changelog starts last year, so why isn't it in Debian?
<JaneW> yes
<dholbach> hellas!
<pitti> Hi dholbach 
<dholbach> martin! how are you?
<pitti> fine, and you? how's the thesis?
<seb128> pitti: cairo API still moving, not really, useful, etc et was waiting
<seb128> pitti: he has sent an ITP some days ago and will upload the package to Debians oon
<dholbach> pitti: coming on fine, today i feel much more confident :)
<dholbach> sb! :)
<seb128> pitti: the same maintainer as cairo/glitz, he maintains his packages here: http://cairographics.org/packages/debian/unstable/
<seb128> dholbach: hey
<Kamion> 20:00 UTC on Thursday? suck
* mvo is away for a bit
* sivang --> back for some long time :)
<jasoncohen> pitti, does CAN-2005-0806 apply to hoary's evolution? The CVE says it applies to 2.0.3 but it shows in http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html
<pitti> jasoncohen: probably not, but I didn't check
<pitti> jasoncohen: that's one of those "it's just a plain bug" things that have very low priority in my todo list
<jasoncohen> pitti, i was wondering why ubuntu doesn't have something like fedora where security issues are marked by severity so users have an idea how important it is to upgrade
<pitti> jasoncohen: well, I explain it using standard terms like "local/remote attacker" and "Denial of Service"/"Arbitrary code execution"
<pitti> jasoncohen: that are objective terms, as opposed to my gut feeling what's important and what not
<pitti> jasoncohen: the importance depends on which software the user actually needs and for what...
<pitti> jasoncohen: do you really think it would make a big benefit?
<pitti> jasoncohen: and if so, which criteria we should use for classification?
<jasoncohen> pitti, well- i asked only because i often get the sense users don't install security updates in a timely fashion because they don't understand their importance
<pitti> jasoncohen: but debian/ubuntu makes it so easy...
<HiddenWolf> pitti: ask yourself if any new novice would know / notice update-manager
<jasoncohen> pitti, for example users will clamor for the latest security updates on firefox but other system packages they'll leave unpatched as they don't understand the description of the security flaw. If there was something that said "critical" or "very imortant", users might be more likely to update
<pitti> jasoncohen: ok, so let's just take today's apache upgrade - how would you rate it?
<jasoncohen> pitti, i also think there should be something to identify update-manger for a new user- perhaps a popup that says "Security updates are available" with an option to close the popup...sounds too much like windows- but new users don't upgrade. i see it all the time
<pitti> jasoncohen: a few percent of the users actually use apache as proxy, for them it is critical if they server a net, or irrelevant if they just use it for themselves
<pitti> jasoncohen: users ignoring u-m? that's an interesting thing, I didn't think about that yet
<Kamion> users don't upgrade Windows either though ...
<jasoncohen> well, i'm not that worried about apache...one would hope that a server user would be a little more knowledgeable 
<jasoncohen> Kamion, more do because it annoys you if you don't :)
<pitti> well, mvo could use libnotify if security updates are available
<Kamion> it took me six months to train my parents to install updates rather than ignoring them
<HiddenWolf> pitti, jasoncohen: thos windows poups are noticable, and they work well.
<jasoncohen> HiddenWolf, i agree- i think we need them
<pitti> HiddenWolf: like libnotify`
<pitti> ?
<jasoncohen> the red circle isn't an obvious enough descriptor
<HiddenWolf> pitti: not familiar with it. They give you a little comic-style text-baloon coming out of the notification area, from the application that requests user intervention. They grab attention, and direct it to the icon responsible - will dissapear either after action is taken or after a little while (configurable)
<HiddenWolf> pitti: that's how winxp does it ^
<jasoncohen> can we do something like that?
<jasoncohen> i actually think the same thing should be done when you insert a new hardware device- "something like HP 750xi printer detected. Click here to configure your printer". That actually was discussed as a breezy goal
<jasoncohen> pitti, honestly, i think *most* new users ignore the update manager or don't know about it
<pitti> jasoncohen: that bubble is what I currently do for new sound cards
<HiddenWolf> I especially like it that the notification comes out of the icon responsible for it. That connects the warning to an icon, so later on, if you see the icon, you'll know it's updates waiting for you.
<jasoncohen> they dont' know there are updates since the only "message" is the red circle
<pitti> ok, I talk to mvo to add libnotify support
<jasoncohen> pitti, also, is there any way to limit update-manager to security updates?
<HiddenWolf> jasoncohen: stick to stable. ;)
<pitti> jasoncohen: for stable releases there will be only scurity updates anyway
<jasoncohen> perhaps security/bugfix updates. backports users might not want to upgrade through update-notifier
<jasoncohen> they also might be less likely to update if they see updates every few days
<Kamion> actually that's not true, base-config includes hoary-updates in sources.list by default as well as hoary-security
<Kamion> but we generally want people to take updates from hoary-updates by default
<jasoncohen> pitti, by default a user will receive updates from hoary-security and hoary-updates. but now that backports is official, we must recognize its presence
<jasoncohen> it would be very easy to do
<HiddenWolf> unfortunatly he has a piont. :P
<Kamion> backports / development release users might well want to upgrade through update-notifier (especially once it / something similar learns to dist-upgrade), but they probably won't want to be nagged about it by popup windows
<HiddenWolf> Kamion: notifications should be configurable of course.
<Kamion> sensible defaults > configuration
<jasoncohen> just have a choice for "View Security & Bug Fix Updates Only" and then if the user enables that have it read from /etc/apt/sources.list.security which only needs to have hoary-security and hoary-updates
<HiddenWolf> Kamion: true, but you'll bug the hell out of people using development versions if you default it to 'stable' settings.
<jasoncohen> Kamion, or- if libnotify were intelligent, it could only create a popup IF the update was from hoary-security or hoary-updates
<HiddenWolf> While we're at it, in ~6 months time, will *something* popup a notice that warty is obsolete?
<jasoncohen> Kamion, update-manager will be able to do a dist-upgrade and there will be a simple distribution upgrade path- the user will be notified a new version exists and they'll be able to upgrade without any configuration changes through update-manger
<Kamion> HiddenWolf: obviously - perhaps you are mistaking what I think "sensible defaults" would be
<Kamion> jasoncohen: hasn't been done yet though
<jasoncohen> cron-apt works the same way- you can use an altnerative sources.list for security updates only
<jasoncohen> Kamion, it's a breezygoal...i'm hoping very much that it gets done
<Kamion> breezy goal doesn't imply gets done, unfortunately
<Kamion> let's hope so, but still
<jasoncohen> well- what's nice for new users is that http://niran.org/code/soc/ did get done
<Kamion> jasoncohen: and in any case I said "once [it]  learns to dist-upgrade", so I did know about the goal already
<jasoncohen> we will see a dramatically improved gnome-app-install that has a comprehensive discription + possibley homepage and screenshots for every app with a .desktop file and it will be organized well and easy to use for new users
<jasoncohen> and i talked to the developer of that breezygoal last night. he's about done
<jasoncohen> he's also developed a way for users to install software from a developer's website using synaptic. you click a link which loads an xml file that tells synaptic to install package. it can't add repos so it should be secure
<HiddenWolf> jasoncohen: nice!
<HiddenWolf> I can see a load of problems with that, but nice!
<jasoncohen> it'll be very cool for the wiki pages
<jasoncohen> we'll hopefully be able to add a link to install packages right from the wiki page
<Kamion> erm
<jasoncohen> i would love to do that on my multimedia page
<pef> bye !
<Kamion> so you know the way Ubuntu comes with no firewall preconfigured, because users have to make an explicit decision to install server packages?
<jasoncohen> yup
<jasoncohen> Kamion, there are no open ports by default
<Kamion> I know that, I was in the original discussions :P
<sivang> Kamion: I'm still amazed by the reaction I get to this by converting people :) "Huh?! How come there is not firewall?" 
<Kamion> my point is that "can't add repos" doesn't mean it's automatically secure
<HiddenWolf> jasoncohen: what'd be cool is if the documentation gnome-app-install shows a description from a wikipedia style package wiki.
<Kamion> because now, anyone can cause a server to be present by convincing a user to click on a link
<jasoncohen> Kamion, it'll still tell a user what's being installed
<Kamion> "<gobbledegook> OK?"
<HiddenWolf> jasoncohen: so you face the description
<Kamion> (which is what the dialog box will look like to people not expecting it)
<HiddenWolf> package would be unauthenticated, but that's not scary enough.
<HiddenWolf> s/face/fake
<jasoncohen> no- it wouldn't. apache2 would authenticate for example
<jasoncohen> anything in ubuntu's repos would authenticate just fine
<jasoncohen> Kamion, how about something like g-a-i?
<Kamion> does that not scare you? we have a lot of server packages, many of which should not be installed unless you know what you're doing
<jasoncohen> Kamion, http://niran.org/code/soc/ - view the last picture
<Kamion> I don't see the relevance ...
<jasoncohen> Kamion, we could have a simple popup with the name of a program and a simple description. also, we could add a warning, "Are you sure you want to add these server pacakges. They may cause security vulnerabilities"
<jasoncohen> Kamion, mandriva does that during install
<Kamion> I just don't think that warning will be heeded
<Kamion> I am really scared of anything that installs packages based on something you can do in ordinary web browsing, which is often hideously insecure
<Kamion> warning or no warning
<Kamion> at UDU we discussed only ever installing packages from something that used some of the widgets from gtkmozembed etc., but not from firefox itself
<jasoncohen> but how is this different from someone saying on a webpage- if you want gaim run "sudo apt-get install gaim apache2 mysql"
<jasoncohen> *mysql-server
<Kamion> that requires conscious action from a user to do, and it's pretty clear what's happening if they have to explicitly invoke a package management tool
<jasoncohen> and it's not going to be obvious if synaptic comes up and asks to install something?
<Kamion> whereas links can be obfuscated, and too many people are conditioned to OKing dialog boxes
<Kamion> if synaptic comes up, maybe; not if just a dialog saying "are you sure you want to install this package?" comes up
<elmo> ybin: Please add ofboot=<path> where <path> is the OpenFirmware path to /dev/sda2 to /etc/yaboot.conf
<jasoncohen> Kamion, i think it brings up synaptic with the package(s) enabled
<jasoncohen> to install
<Kamion> but synaptic coming up seems to be an obvious target for usability types to eliminate, so I suspect that would go away, and then we'd be left in the terrifying scenario
<elmo> kamion: I'm getting that with a breezy kernel (on a hoary systme) - have you seen that, and/or do you know what it wants? :)
<jasoncohen> pitti, so, are you opposed to the idea of having a security/bug fix update only choice for update-manager?
<Kamion> elmo: what does 'ofpath /dev/sda2' say?
<elmo> ofpath: /proc/device-tree is broken.  Do not use BootX to boot, use yaboot.
<elmo> ofpath: The yaboot HOWTO can be found here: http://www.alaska.net/~erbenson/doc
<pitti> jasoncohen: not really, but I'm not opposed to a special notification if there is a security update
<jasoncohen> pitti, ok, would that be difficult to implement and is it something someone is interested in doing? i unfortunately don't have any programming knowledge
<pitti> jasoncohen: can you please talk to mvo when he comes back?
<jasoncohen> ok
<pitti> u-m is his baby
<pitti> thanks
<Kamion> elmo: muh?
<elmo> Kamion: yeah, neat
<elmo> Kamion: it's davis, FWIW
<Kamion> ls -l /proc/device-tree | grep -q ^lr
<elmo> and ofpath seems to work without privs
<Kamion> that's the test
<Kamion> no symlinks in the top level of /proc/device-tree - wtf?
<Kamion> like, er, minor details like /proc/device-tree/pci
<jasoncohen> is Michael Vogt mvo?
<Kamion> yes
<elmo> this is a fairly early breezy kernel, I'm trying to upgrade to a more recent one
<pitti> dholbach, ajmitch: could one of you please merge ethereal from Debian? it fixes a lot of vulns
<jasoncohen> ah, so he's the one working on http://udu.wiki.ubuntu.com/SystemUpgradeTool
<dholbach> pitti: i'll look into it
<elmo> kamion: I might just reboot into the new one, and see if /proc/device-tree is happier
<pitti> dholbach, ajmitch: it almost looks like the package can be synced
<dholbach> pitti: ok, i'll double check
<pitti> dholbach: thanks :-)
<Kamion> elmo: you'd need a ppc kernel guru to check if device-tree's meant to be that way; kinda hard to check from userspace
<elmo> ok
<Kamion> elmo: doing 'dev / ls' at an OF prompt might be worthwhile, see if it has the links or aliases or however they show up at that level
<Kamion> lrwxrwxrwx  1 root root 12 2005-08-04 18:32 /proc/device-tree/pci -> pci@f0000000
<Kamion> stuff like that should really be in /proc/device-tree/
<dholbach> elmo: could you please sync ethereal from unstable, when you find the time?
<elmo> Kamion: latest breezy does the same thing - I'll pester the kernel folks
<elmo> dholbach: ok to override ubuntu changes?\
<dholbach> yes, go ahead!
<zul> hmmm?
<pitti> dholbach: thx for cross-checking
<dholbach> elmo: is somebody else doing syncs these days? some motus wanted to know what to do about syncs, when you're not available ... and i couldn't tell me for sure, because i wasn't around that much
<elmo> dholbach: just have them mail me
<dholbach> alright, i will tell them
<dholbach> elmo: thank you
<elmo> (if I'm not around
<elmo> + otherwise, on IRC is obviously fine)
<shaya> uh, are there supposed to be .ko files in linux-restricted-modules?
<shaya> there dont seem to be any
<jasoncohen> shaya, there are
<jasoncohen> shaya, i think you're looking at the dummy package linux-restricted-modules-arch
<shaya> uh?
<shaya> spotter@dent:/lib/linux-restricted-modules$ find . -name '*.ko' -print
<shaya> spotter@dent:/lib/linux-restricted-modules$
<jasoncohen> shaya, dpkg -L linux-restricted-modules-`uname -r`
<shaya> spotter@dent:/lib/linux-restricted-modules$ dpkg -L linux-restricted-modules-2.6.12-6-686 |grep ko
<shaya> spotter@dent:/lib/linux-restricted-modules$
<jasoncohen> oh, ok
<jasoncohen> when did that package enter breezy?
<shaya> today
* shaya pokes mdz
<Treenaks> hey
<Treenaks> where'd glxinfo go?
<Kamion> shaya: they're linked at run-time
<shaya> really?
<shaya> how does that work?
<mdz> shaya: pong
<Kamion> see linux-restricted-modules-common
<shaya> and what's the point?
<shaya> lrm-manager has no manpage
<Treenaks> glxinfo is gone :(
<Amaranth> Treenaks: glxinfo is unimportant
<janimonoses> tseng you can test xfce now :)
<Mez> Amaranth: ping
<Amaranth> pong
<Mez> Amaranth, bob2 was telling me something was breaking something in BP ..
<Mez> and that you knew about it
<Amaranth> yeah, pyxdg needs to conflict with gnome-app-install
<Mez> shouldnt that conflict in breezy?
<Amaranth> well, no
<Amaranth> gnome-app-install is turning into niran's new project
<Amaranth> which works with pyxdg 0.14
<Mez> so why should it conflict?
<Amaranth> it should in backports
<Amaranth> because you don't have niran's shiny stuff
<Mez> then let us have it
<Amaranth> we don't have it either :P
<Amaranth> i suppose you could fix g-a-i in breezy and backport it
<Mez> *shrugs*
<shaya> well, however restricted modules are supposed to work, they dont seem to work well
<Kamion> Amaranth: a versioned Conflicts would be fine
<shaya> just booted into .12 and it couldn't load madwifi
<tseng> janimonoses: rock on
<Amaranth> shaya: linux-restricted-modules-2.6.12 isn't even in the archives yet, is it?
<Amaranth> and when i built it on my own it seemed to be split into a bunch of smaller packages
* Mez yawns
<Mez> pitti: ping
<pitti> Hi Mez 
<shaya> Amaranth: it is
<Mez> hey pitti, just looking at libgda2 ... and it needs a lil tweak to be able to be backported,
<Mez> just wondering if you'd make the tweak and upload
<pitti> which tweak?
<pitti> Mez: if you send me a debdiff, I can take a look at it and upload, no problem
<Mez> pitti: it's a tiny change
<Mez> not worth a debdiff IMO
<Mez> in control.in change the Build-Depends on libpq-dev to libpq-dev | postgresql-dev
<pitti> ah, I see
<Mez> musta missed that before or somethign
<sabdfl> elmo: do you have a handy list of the current uploaders to main and universe?
<pitti> Mez: but why not just change the build-dep in the backport?
<elmo> sabdfl: I can make one
<sabdfl> elmo: danke
<Mez> pitti: because we dont have access to upload to backports
<Mez> pitti: everything has to be fixed in breezy, then backported
<Mez> evening sabdfl :D
<pitti> Mez: ok, if it helps you...
<sabdfl> hey Mez
<Mez> pitti - thanks a lot :D
<pitti> Mez: hm, odd...
<Mez> odd?
<elmo> sabdfl: sent
<pitti> Mez: it seems that the current breezy libgda already depends *only* on postgresql-dev
<Mez> pitti: thats not true
<pitti> Mez: ah, libgda23
<pitti> libgda2, even
<pitti> I looked at libgda
<Mez> http://packages.ubuntu.com/breezy/source/libgda2
<Mez> (pitti: if thats the case libgda should be fixed aswell, postgresql-dev is a transitional pacakge)
<mdz> pitti: it's a lot cleaner for us to share sources between breezy and backports: no merging, no human error, etc.
<janimonoses> elmo please sync xfce4-terminal, thanks
<pitti> Mez: uploaded
<Mez> pitti: thanks :D
<pitti> You're welcome :-)
<Mez> elmo, can you re-add libgda2 when It's built?
<Mez> and lamont/infinity can you clear the dep-wait on it please
<Mez> mdz: did you get my email about mono backports
<elmo> janimonoses: done
<elmo> bah, kernel-package is horribly unfriendly to ppc64
<jasoncohen> Mez, can you upload totem 1.1.1 from mirrormax's backports to the official backport mirror? totem 1.0.1 can't play part files, so you have to wait until a download is complete to play a song. that is fixed in 1.1.1
<lamont> elmo: how so?
<elmo> lamont: it forces the architecture to ppc
<lamont> ew
<lamont> it's helping...
<elmo> not really :P
<elmo> the kernel gets it right, it's make-kpkg explicitly overriding the kernel's own idea of architecture
<teferi> hey, will you guys kill me if i ask about a bizarre problem i've found in breezy+newest kernel package+newest linux-restricted-modules?
<mdz> Mez: yes
* dieman sits down and tries to port the debian xen package to ubuntu
<teferi> well, i'll ask anyway. i've installed the new linux-restricted-modules and run lrm-manager. /lib/modules/2.6.12-6-686/kernel/drivers/volatile exists and is populated as expected. but if i try to modprobe, say, the atheros driver (ath_pci), it silently fails. the module doesn't show up in lsmod (or /proc/modules, obviously), but if i try modprobing it again, stracing modprobe shows that init_module returns EEXIST...
<janimonoses> Mez, how does one request a backport?
<ogra> janimonoses, you ask Mez :)
<teferi> if no one feels like helping me, that's okay, just tell me and i'll vanish. i hate to bother you guys, but this is a real head-scratcher
<janimonoses> Mez, could you backport the wx2.6 packages please
<Burgundavia> pitti, have you had a chance to look at a few more of the edubuntu main inclusion stuff?
<pitti> not yet, sorry
<highvoltage> teferi: try #ubuntu
<Burgundavia> pitti, np
<teferi> highvoltage: i have. they're baffled too
<jasoncohen> teferi, you should post a bug report. this isn't really the place to ask for support. Breezy is still a development release so things are expected to be borken
<jasoncohen> *broken
<teferi> yeah, i know
<teferi> oh well, to bugzilla I go
<jasoncohen> teferi, linux-restricted-modules was just added today
<jasoncohen> in breezy
<teferi> jasoncohen: yep
<jasoncohen> give it a while
<Mez> janimonoses, please email it to ubuntu-backports@lists.ubuntu.com
<janimonoses> mez, done :)
<x0r> hello people
<x0r> I just got a strange error after upgrading my xorg on breezy
<x0r> my xorg.conf seems not to work anymore, I also looked around and didn't found anything
<x0r> running Xorg -configure to check my xorg.conf gives me: .... Missing output drivers. Configuration failed.
<x0r> any idea?
<Mez> x0r, support is on #ubuntu - X is b0rked, but try sudo dpkg-reconfigure xserver-xorg
<x0r> doesn't work
<x0r> I've tried almost everything
<Amaranth> go bad to hoary?
<Amaranth> err, back
<x0r> maybe something changed in the development cycle
<x0r> no
<Amaranth> X is working here
<x0r> I'd like to use breezy and to enjoy gcc 4.0 and a fast machine
<x0r> also for my persnal software development
<Amaranth> gcc 4 doesn't make things faster
<Mez> Kamion: ping
<x0r> I know
<Kamion> Mez: pong
<x0r> I like the up to date libraries and also an up to date gnome ;)
<Mez> Kamion, just looking at MOTU-Merge, there's a kernel package for d-i ...
<Kamion> Mez: which one?
<Mez> is it even needed in universe?>
<x0r> @Amaranth: do you have an nvidia graphics card?
<Mez> linux-kernel-di-i386-2.6
<Amaranth> x0r: nope
<Kamion> Mez: no, it's probably best to remove it
<Mez> Kamion: morgue candidate?
<Amaranth> x0r: pretty sure you need to use the open source nv driver right now though
<Kamion> likewise linux-kernel-di-*, pretty much
<Kamion> Mez: yes
<Mez> cool :d
<Kamion> we've built those from the kernel source proper since forever
<x0r> @Amaranth: I've tried the open source nv driver, that comes with xorg -> but it also doesn't work :(
<Mez> Kamion: so... what should the reason be?
<Kamion> Mez: superseded by linux-source-2.6.*
<Amaranth> x0r: based on the little ammount of info you've actually given i'd say the answer is give up on X or go back to hoary
<Amaranth> x0r: unless you give more info those are the only choices
<x0r> ok
<x0r> what info do you need
<x0r> I don't know what can help you
<Amaranth> your xorg log file
<x0r> my xorg.conf isn't useful I think
<x0r> because it worked a few days ago
<shaya> Kamion: what's the reasoning for the new system w/ restricted modules?
<x0r> wait
<x0r> I'll post it
<Kamion> shaya: I didn't have anything to do with it, I was just pointing out what I could see in the archive
<shaya> yea, it dont work
<shaya> trying to read up on it
<Kamion> mdz: can I move OEMInstaller to Completed, do you think? it almost certainly still needs more development work, but it's in the "responses to testing" and "large bug fixes" categories rather than the "code not there" category
<Mez> Kamion: this cool: https://wiki.ubuntu.com/MorgueCandidates
<x0r> here's my xorg.conf
<x0r> # /etc/X11/xorg.conf (xorg X Window System server configuration file)
<Kamion> Mez: yes, except (a) i386v -> i386, (b) it's spelt "superseded" not "superceded" :)
<x0r> wait
<Mez> Kamion, I see your adverse to morgueing aboot
<Mez> what's the point at the moment if it wont even build - and is just wasting space
<xor> Section "Files"
<xor> 	FontPath	"unix/:7100"			# local font server
<xor> 	# if the local font server has problems, we can fall back on these
<xor> 	FontPath	"/usr/share/X11/fonts/misc"
<xor> 	FontPath	"/usr/share/X11/fonts/cyrillic"
<Kamion> Mez: we have plenty of stuff that's arch-specific; note that we have three unofficial ports already, and there has been interest in the others
<Kamion> s/the others/others/
<Kamion> I don't recall if there's been specific interest in alpha, but I really don't see why we should intentionally make life harder for such people
<Kamion> ideally, they should be able to set up a buildd and build their way up the usual chain
<zAo^> can I upgrade the nvidia-glx pkg without losing DRI?
<zAo^> the new pkg that is
<mdz> Kamion: that'd be appropriate, then, yes
<hunger> Which deb contains the vmlinuz file now? linux-image-686 is empty except for some docs here.
<hunger> linux-restricted-modules is empty as well:-(
<Kamion> ah, s/Completed/Implemented/ now I see
<Kamion> linux-image-686 is a metapackage, the same as it always was. Look at its dependencies.
<sabdfl> hey guys, i think we should start keeping track of the main-uploaders and universe-uploaders in launchpad
<hunger> Kamion: You are right of course... sorry for the stupid question. I've been running around for 18h straight now:-(
<sabdfl> dholbach, ogra: we need a universe-uploaders team in LP
<sabdfl> we need a strict policy on who can add people to that
<ogra> ok
<sabdfl> probably, the tech board should be the owner of that team
<ogra> yup
<sabdfl> because tech board people need to approve universe-uploaders
<sabdfl> should i go ahead and create it?
<ogra> yep
<ogra> :)
<sabdfl> i'll add you two, as admins, would you then add the other motu?
<ogra> sure...
<ogra> is there a way to copy contents between teams ?
<ogra> we already have the MOTU team for malone, i could just copy it
<tortoise_> new login has stopped working in breezy, and I cant switch to other virtual terminals
<tortoise_> is this known aboot
<ogra> tortoise_, works fine here on a up to date breezy machine
<Mez> sabdfl: I assume you're planning to make it so uploads work through LP?
<ogra> Mez, not only uploads
<Mez> sabdfl, that's a great idea :D hehe :d and would make elmo's life a lot easier
<Mez> ogra: not only uploads ... /
<Mez> s/\//\?/
<sabdfl> Mez: yup
<ogra> Mez, LP will be the center of the world for ubuntu development once its done
<sabdfl> Mez: also, storage of patches and packages under development
<ogra> and not only ubuntu hopefully
<sabdfl> and allowing non-members to publish their own patches etc
<Mez> sabdfl: sweet :D you've gotta love ubuntu for making innovations eh?
<sabdfl> Mez: should be fun ;-)
<Mez> sabdfl: yeah, but Ubuntu makes so many changes to the way people develop - is it ever gonna be finised?
<sabdfl> Mez: i hope not, i would have to find something else to get up for in the morning
<tseng> Mez: about half of the products are public now, malone, rosetta, baz
<tseng> the rest are more specific to building the distro
<tseng> besides hct is interesting to other distros I guess
<tseng> everyone is really looking forward to that one.
<Mez> sabdfl: I usually find my gf kicking me in the back helps me get up in the morning
<sabdfl> Mez: the whole idea is to accelerate open source development with better collaborative tools
<Mez> sabdfl, I know, I saw the video of your speech at debconf :D
<Mez> sabdfl: and hats off to you for funding it: I can see you being marked down as a prominent figure in geek history
<pitti> oi, where is seb128???
<martinhj> is there a list of patches used in the ubuntu kernel?
<Mez> hmm: does anyone have any FF plkugin making experience
<Mez> it'd be so useful to hve a search plugin to search packages.ubuntu.com/packages.debian.org
<Amaranth> Mez: That'd mostly be a copy/paste of another search plugin.
<Mez> Amaranth, maybe :D but still :D be usefule
<Mez> and martinhj try http://patches.ubuntu.com/patches/
<Amaranth> Mez: I know, I'm telling you to copy/paste another plugin. :P
<martinhj> Mez: tried that one.. I mean like a list in a wiki or something
<Mez> Amaranth, I wouldnt know where to start
<martinhj> there is a package in the main repository called ubuntu-kernel-patches or something.. is that a full list of all the patches used against a vanilla Linus kernel.org Linux kernel?
<majic> can anyone verify that the ruby 1.8.2 package made it into backports yet?
<Mez> majic, erm, we're fixing a few things, it should be there then
<Mez> (It's registering as needing a NEW when it shouldnt be
<majic> alrighty then
<elmo> Riddell: ?
<Riddell> elmo: ?
<elmo> kio-apt's debian/bug.control doesn't seem appropriate?
<Riddell> elmo: you're right there
<Riddell> elmo: the package is based on one from him (he's the author of kio-apt)
<ajmitch> morning
<elmo> sure - I haven't rejected it, but you could fix our package not to install that file in the next upload?
<Riddell> elmo: ok
<dholbach> sabdfl, ogra: isn't the "motu" team just ok?
<ogra> dholbach, the motu team currently contains only administrators
<ogra> dholbach, sabdfl wants something TB controlled
<dholbach> ogra: but it just contains motus, which are universe uploaders
<ogra> yes
<dholbach> ogra: oh well... i thought they'd be happy to not having to do it themselves :)
<dholbach> ogra: aren't we good at organizing ourselves? :-p
<ogra> dholbach, i guess its our job to finally add them :)
<robitaille> dholbach: next step is to turn on the calendar in the MOTU's LP page and add the MOTU meetings in there :)
<dholbach> ogra: it's just that two groups to take care of is ... :)
<ajmitch> robitaille: yes, certainly :)
<dholbach> ogra: i asked about adding a mailing list to the malone team: it's no problem
<ajmitch> dholbach: but if the 2nd group is only editable by the TB, since it will control upload rights
<dholbach> ogra: so everybody can sign up for universe-bugs or something - if they want to help us
<robitaille> I finally found yesterday how to subscribe to other LP calendars; it's a great feature
<Mez> it is :D
<dholbach> robitaille: i saw it today :)
<Mez> dholbach, the second group will be only controllable by you and ogra and TB
<ajmitch> dholbach: great, can some of us be signed up automatically? :)
<dholbach> ajmitch: the mailing list isnt created yet and i can only hope we don't hit anal restrictions towards it :)
<ajmitch> dholbach: patience..
* mvo waves to dholbach 
<dholbach> hey mvo :)
* dholbach consoles mvo for amd64 troubles
<ajmitch> hi mvo 
<mvo> hey ajmitch!
<ogra> dholbach, amd64 and troubles in one sentence from *you* ?
<dholbach> ogra: ask mvo
<\sh> evening..guys
<mvo> ogra: don't ask, much hw dealer seems to be unable to build a amd64 for me that actually works :/
<ogra> mvo, did you think about the fact that we have backported main packages now for synaptic (i.e. ubuntu logo for main packages)
<ajmitch> hmm, security bug on malone, I wonder if it's on pitti's list
<mvo> ogra: arg ... no
<ogra> mvo, cant you do that yourself ? i never trust HW dealers
<pitti> ajmitch: which one?
<ajmitch> https://launchpad.net/malone/bugs/1176
<mvo> ogra: I can (and did all the time until now). but I wanted to try a different way this time. 1. give money to dealer 2. get shinny pc
* mvo grumbles about his stupid idea
<ajmitch> ok it has a CAN & debian bug, so it probably is :)
<ajmitch> pitti: it's on the fixed list, I'll close the malone bug
<majic> is reading the new debian maintainers guide the best way to break into debian packaging? Or is there any Ubuntu specifics that I should need to know.
<Riddell> majic: https://wiki.ubuntu.com/KubuntuPackagingGuide has some ideas
<ogra> majic, nope, debian NM guide is fine... 
<Riddell> majic: also hang around on #ubuntu-motu
<pitti> ajmitch: probably fixed in breezy, but not in hoary&warty
<ogra> majic, additionally the DevelopeResources wikipage is of some interest
<ajmitch> pitti: ah ok
<ogra> *DeveloperResources
<majic> I've been looking at the DevelopersResources wiki-page
<majic> I'm just trying to figure out what exactly I need since there seems to be alot of information out there
<martinhj> ogra: does gnome-power work for you? it doesn't show any icon here....
<ogra> martinhj, run gnome-power-manager from the commandline or via alt-f2 then enable the icon in the settings gui
<ogra> this version doesnt do very much yet... its quite outdated... the new version waits for the new dbus
<ogra> it will only show your battery status
<martinhj> ogra: ah, ok.. but the problem was acutually that the gnome-power daemon didn't run..
<ogra> or UPS if you got one
<mdz> infinity: are the livefs build logs published?  if not, please arrange for them to be published
<martinhj> shouldn't it be added to gnome-session by default?
<ogra> martinhj, if it is in main
<martinhj> ah, ok
<ogra> martinhj, the new version will work differently and split out an additional powermanger package, that has to be approved newly
<martinhj> will it work with acpi-support in Ubuntu, or will it all change?
<ogra> it will be a frontend to the current power management infrastructure
<mdz> mvo: is progress-reporting ready to be released?
<martinhj> ogra: and edit /etc/default/acpi-support and such?
<ogra> martinhj, huh ? 
<ogra> why would you want to edit that file ?
<mvo> mdz: could you please check if you merged my latest changes? if Kamion tested it sucessfully with his base-config work I think it's ready
<mvo> mdz: I would like to do a new python-apt release. the python interface was reviewed by jamesh and ddaa and I reworked it according to there input
<martinhj> ogra: at least changes in that file changes the log out dialog, so I thought gnome-power-manager could be a frontend to that file
<ogra> martinhj, gnome-power is a frontend to hal it will call the functions your logout dialog uses on some conditional events...
<ogra> i.e. shutdown or hibernate if battery is at 1%
<martinhj> ok
<shaya> mdz: your bug is fixed
<shaya> or I would hope so
<windex> i would just like to say, i have been lurking in here a couple of days, and out of the linux distributions i've worked with, this is both the most civil and the most sane development channel out of all of them. :)
<mdz> shaya: oh?  that's great.  I didn't see anything on the unionfs list about it
<Mez> mdz: so what do we want to do about backproting mono
<mdz> windex: thanks :-)
<mdz> Mez: if it needs bootstrapping, that's a buildd admin issue (lamont/infinity)
<tseng> lamont LOVES mono :D
<lamont>  /me looks for something to hit tseng with
<tseng> lamont: i only poke fun because I like you.
<lamont> hehe
<mdz> Mez: regarding the packages you said needed new processing, I don't see any of those in the queue
<Mez> mdz: I believe lamont and elmo have fixed that now
<mdz> I don't see ruby-defaults binaries in hoary-backports yet
<Mez> mdz: interpreters/ruby-defaults_1.8.2-1~hoary1: Building by buildd+vernadsky [optional:uncompiled] 
<lamont> mdz: the overrides were fixed at :03
<Mez> mez: it was showing as unkown in LKiss
<elmo> mdz: miscommunication
<Mez> Lists
<elmo> mdz: they were missing overrides due to a config screwup, they  were never NEW
<Mez> and the buildlog says it's been built successfulyy... so lol convused over that
<elmo> and being missing in the overrides breaks our buildds
<Mez> :D
<lamont> and as for it's failure to show up, at least vernadsky needs a little hit with a cluebat
<mdz> lamont: can you arrange for the livefs build logs to be synced out to your buildLogs dir?
<mdz> I would like to be able to show people how to help when they ask about the live cd builds ;-)
<Mez> mdz: thinking of making a backports Live CD when everythings working properly with backports: what do you think?
<lamont> mdz: I'll add those to the work I'm doing on the logs between now and monday
<mdz> Mez: interesting idea, but it will involve some legwork on the part of some very busy people, so it may take some time to set up
<mdz> lamontthanks
<mdz> lamont is both here and away
<lamont> mdz: yeah - that away guy is away from the house
* lamont is considering dircproxy or something
<Mez> mdz: It'll require some legwork yes, I'm thinking maybe an install/live cd when breezy is released (for hoary)
<lamont> the order of existance is 'lamont__', lamont, lamont-away :0
<lamont> :-)
<\sh> lamont: it works great on ubuntu ;)
<lamont> my roving selves all highlight on 'lamont' as well
<lamont> of course, sometimes when my home-self is 'lamont-away', I'm really there... I should be more pedantic about my nic
<lamont> k
<pitti> night everybody
<\sh> yes..for me as well...g'night :) 
<shaya> mdz: pathc was just posted
<shaya> they messed up on the d_unhashed logic
#ubuntu-devel 2005-08-10
<shaya> mdz: now just fix restricted-modules so my madwifi loads so I can test .12 :)
<Amaranth> shaya: now just give me $5000 and I'll do it
<shaya> :)
<shaya> hey, I fixed a bug (or at least isolated) for mdz yesterday :)
<Mez> elmo: pinh
<Mez> ping *
<majic> I have yet to actually make my first Ubuntu package. I'm still reading about it. But if you guys were to sum up the level of difficulty (in actually getting it right and stable) from 1 - 10 what would you say?
<dholbach> majic: if you join #ubuntu-motu we can help to get you there
<majic> I'm there =)
<mdz> shaya: what's wrong with it?
<mdz> shaya: it works here
<mvo> mdz: any objections on a python-apt upload tomorrow? or just I time it with your apt upload?
<mdz> mvo: no objections
<mvo> thanks!
<lifeless> is this worth a bug report... tpackage libfann1/libfann1-dev lacks Python bindings, even though upstream has such bindings.
<lifeless> (in that there is no python2.4-fann or * package).
<mdz> shaya: I don't see the patch in my mailbox or in the list archives yet; could you send a copy off-list?
<mvo> lifeless: do you it? I sponsor it :)
<mvo> lifeless: s/do you it/do you use it/
<mdz> s/bug report/feature request/
<Mez> mvo: have you been drinking ?
<mvo> Mez: no, I'm just tired :/
<lifeless> mvo - I don't, but one of the twisted guys is trying to use it from python, and noted the discrepancy :)
<Mez> mvo: same thing really
<mvo> Mez: heh :)
<Mez> lamont: ping :
<lifeless> mvo - so, what chance of the non-developer maintainer enabling those bindings ?
<mvo> lifeless: yes, feel free to file a bug (either debian or ubuntu). it's been a while since I was working on/with it
<lifeless> reportbug libfann1-dev :)
<lifeless> bwahhahaha
<lifeless> may I flood 10 lines ?
<dholbach> 10 lines is nothing :)
<lifeless> Bug report submitted to: "Ubuntu Bug Tracking System" <ubuntu-users@lists.ubuntu.com>
<lifeless> Copies sent to:
<lifeless>   "Robert Collins" <robertc@squid-cache.org>
<ogra> lol
<lifeless> Traceback (most recent call last):
<lifeless>   File "/usr/bin/reportbug", line 1656, in ?
<lifeless>     main()
<lifeless>   File "/usr/bin/reportbug", line 1647, in main
<Mez> wait..
<lifeless>     smtphost, options.smtpuser, options.smtppasswd, options.paranoid)
<lifeless>   File "/usr/share/reportbug/reportbug_submit.py", line 415, in send_report
<Mez> Bug tracing system
<lifeless>     (sysinfo['email']  % 'n'), (sysinfo['email']  % '999999'))
<Mez> ubuntu-users ?
<lifeless> 'Lying'
<lifeless> TypeError: not all arguments converted during string formatting
<mvo> haha
<Burgundavia> lifeless, that was 11 lines, sorry
<lifeless> Burgundavia: awww
<lifeless> ^U
<lifeless> there you go, one less.
<ogra> heh
<mdz> lifeless: old bug in reportbug; I thought it was fixed
<lifeless> mvo - so did that get through or not ? I'm not on u-u
<lifeless> mdz - I';m on hoary, would that explain it ?
<mvo> lifeless: I'm not on u-u as well ...
<ogra> mdz, i was about to qoute your -devel post *g*
<ogra> but you did the yourself *g*
<mdz> lifeless: I thought it was fixed before hoary, but there has been another report of it on hoary recently...
<ogra> that even
<lifeless> mvo https://launchpad.net/malone/bugs/1674
<lifeless> mdz want me to file a bug on reportbug ?
<mvo> lifeless: I send a message to fann upstream and asked him how stable he considers the python bindings. I hope he answers soon
<dholbach> i'm off to bed - sleep tight everybody
<mvo> n8 dholbach 
<ogra> bye dholbach 
<lifeless> night
<lifeless> mvo - thanks :).
<HiddenWolf> x works?
<HiddenWolf> omg
<mvo> lifeless: nb :)
<Kamion> mdz,mvo: I've tested progress-reporting patch-22, and have a completely working base-config with progress bar and passthrough questions with the aid of debconf 1.4.56
<Kamion> (which I uploaded to Debian earlier this evening, and will merge to Ubuntu tomorrow)
<mvo> Kamion: *rock*
<mdz> Kamion: fantastic
<mdz> I'll upload 0.6.40
<lamont> mdz: hoary live/ppc cd.  machine has eth0 (5221) and eth1 (wireless) nic's.  casper complains in syslog that /sbin/ifup is missing, never brings up eth0....  eth1 can't find an AP (unsurprising, actually)... is this a known issue?
<lamont> one you're up, you can tell network config to confgure eth0, and all is well.. but it's not automatic
<shaya> ah
<shaya> mdz: you need to be subscribed to the cvs list
<shaya> it helps to see whats going on
<shaya> mdz: http://www.fsl.cs.sunysb.edu/pipermail/unionfs-cvs/2005-August/000260.html
<shaya> see the change to commonfops.c
<Kamion> mdz: great, thanks
<Kamion> I hope somebody will do the aptitude upload too
<Kamion> then I'll depend on that version
<Kamion> hm, actually I suppose I can just depend on new-enough apt and unversioned aptitude, that's logically sufficient
<mvo> Kamion: I can do a (ubuntu) aptitude upload when we have the new apt. I'll send a patch to daniel too
<Mez> lamont: reping
<mdz> lamont: doesn't sound familiar
<Kamion> btw, colin.watson@canonical.com--2005/base-config--pkgsel-progress--0
<mdz> lamont: casper doesn't do anything interesting with the network; d-i handles it
<Kamion> needs a few more things wrapping in progress bars and some tidy-ups, but the major work's done
<lifeless> mdz - for your gratification... https://launchpad.net/malone/bugs/1677
<lamont> mdz/kamion: I have logs from the machine, if they help at all... guess we should grab a recent colony and see how it does.
<lamont> Kamion: btw, ia64 daily d-i builds disabled for the moment
<HiddenWolf> Guys, for the record, why do I see a warning come scrolling past during hoary install that 'locate' needs a cronjob run by root during install, and that the user should do that manually?
<Kamion> because the postinst prints that and nobody spotted it to disable it?
<Kamion> hm, in fact findutils.postinst doesn't ...
<HiddenWolf> I only saw it now because I'm refurbishing an ancient laptop. Thought I'd ask.
<Kamion> which package?
<Kamion> ah, looks like slocate.postinst
<Kamion> WARNING: You should run '$SLOCATE_UPDATEDB' as root. locate will not work
<Kamion> properly until you do or until it is run by cron (it is daily).
<HiddenWolf> bingo
<Kamion> I think you misparaphrased the warning a bit
<HiddenWolf> Yeah, i noticed
<Kamion> looks pretty harmless
<HiddenWolf> Noticed that too. :(
<Kamion> slocate's theoretically nice but at least historically has been slightly oddly packaged
<Kamion> I recall having filed some "is broken" bugs against it
<HiddenWolf> eh, if it's not up to par, why is it in seed?
* HiddenWolf man locate
<Kamion> it's a lot better now than it was; the postinst message is just a vestige of the previously odd packaging I believe
<Kamion> and it's a good idea - means you can't discover filenames using locate that you wouldn't have been able to see otherwise
<HiddenWolf> Ah, looks nifty
<HiddenWolf> Learned another command line trick today. ;)
<Kamion> actually I reversed that slightly, see Debian #171811 for a better explanation of why it's a good idea
<HiddenWolf> Ugh, I keep wanting to press #<number> things in xchat and expecting to end up on bugzilla. :P
<martinhj> sometimes my USB ports doesn't work.. I need to reboot to get them working again..
<martinhj> in kern.log I get: Cannot enable port 1.  Maybe the USB cable is bad?
<martinhj> but it's nothing to do with the cable, have tested with different devices
<HiddenWolf> Kamion: is there anyone I could ask about what is going to happen with ubuntu and ubuntu lite? 
<martinhj> I got two different USB ports, happens on both
<martinhj> in interrupts I can see that the USB hubs shares interupts with other devices..
<martinhj> what can this be?
<Kamion> HiddenWolf: not something I know about, I'm afraid
<martinhj> it happens maybe 1 out of 10 time
<martinhj> times
<martinhj> or maybe less
* lamont runs out the door
<Kamion> and I'm three beers and half a cacao/cherry cocktail the worse for wear, so I'm not the best person to ask right now ;)
<sabdfl> jdub: what's the vibe at OSCON like?
<HiddenWolf> Kamion: anyone who does? The idea is good, but it looks like an half-assed rushjob to me. an offline website, and a google group for discussion about it. 
<HiddenWolf> no offense.
<sabdfl> HiddenWolf: patches welcome
<HiddenWolf> sabdfl: I'd love to. I can do hello world in three languages. :)
<HiddenWolf> I'll happily test it on a half-dozen old pc's if it'd look somewhat trustworthy.
* mvo goes to bed now
<ogra> night mvo 
<Burgundavia> HiddenWolf, part of what they are doing is a google soc project
<HiddenWolf> I'm gathering it's not official but will be?
<ogra> HiddenWolf, vedran is the bountier
<ogra> he's around during sane european times
<HiddenWolf> Hm, right.
<Kamion> Mez: you really don't need to say "changed distribution to breezy" in changelogs BTW - it's implicit in the changelog header
<Kamion> unless there were actual changes for that outside the changelog
<HiddenWolf> Attribute my bluntness to the hour, i'll be talking to vedran in the morning. :)
<squinn> question
<squinn> as i think #devel will know it better than straight #ubuntu
<Mez> Kamion, yeah i know... :D lol... I was just being over-zealous
<Mez> lol
<squinn> what files are created when a pgp key is created?
<Mez> squinn: it goes onto your keyrung
<Mez> in ~/.gnupg
<squinn> thanks Mez 
<mdz> Kamion,mvo: uploaded
<mdz> shaya: that patch is HTML-mangled; what is the URL for the CVS repository?
<mdz> shaya: never mind, did it by hand
<hmrocha> hi
<hmrocha> do you have any idea on when will colony 3 be released?
<hmrocha> openoffice 1.1.4 is fucked up
<hmrocha> (i'm using breezy)
<hmrocha> i have deleted .sversionrc and .openoffice but it still doesn't work
<shaya> mdz: you just needed the !d_unhashed->d_unhashed
<shaya> fixed your problem?
<mdz> don't know yet, doing a full kernel build
<shaya> mdz: what's the reasoning for this tempfs based .ko storage area for restricted modules?
<shaya> what was wrong w/ the old way?
<elmo> mdz: is "unable to build ppc64 kernels" a RC bug for kernel-package or just noromal?
* shaya  ears perk, ppc64 kernel?
<shaya> any chance they'll work on IBM's JS20 blades?
<mdz> elmo: depends on whether we get around to building ppc64 kernels for breezy
<mdz> oh, we do
<mdz> so they're failing?
<mdz> dpkg-deb: building package `linux-image-2.6.12-6-powerpc64-smp' in `../linux-image-2.6.12-6-powerpc64-smp_2.6.12-6.7_powerpc.deb'.
<mdz> looks ok
<elmo> kernel-package
<elmo> not dpkg-buildpackage
<elmo> i.e. for users
<elmo> you know, the ones who compile their own kernels - I know how much you love them
<sabdfl> night all
<Lathiat> night sabdfl 
<mdz> elmo: dude, linux-source uses make-kpkg to do the builds
<mdz> so clearly it can build ppc64 kernels
<elmo> hum
<elmo> hmm, it's doing some hideous KPKG_ARCH overriding
<elmo> meh
<elmo> doesn't really count, but ok
<elmo> it's possible, just broken by default
<mdz> sounds like a normal bug then
<elmo> yeah
<sebest_> hello, i noticed during my last apt-get upgrade that glitz was installed, is there something using it?
<Lathiat> sebest_: cairo i think
<Lathiat> dont quote me on that
<sebest_> lol
<sebest_> i was wondering something, how can i choose the backend when using cairo?
<sebest_> for example how can i switch from the software to the glitz backend
<Lathiat> hrm to instal gnome-devel I had to first install libgnome-menu-dev manually because it wouldnt install for some reason with gnome-devel
<yossnet81> hey, my xorg on breezy is still broken. GDM comes up, looks all weird, then I get a message saying "the greeter program appears to be crashing attempting to use a different one". in addition, weird colors are coming up on my VT's in random places
<yossnet81> it was working fine before X broke
<yossnet81> anyone?
<bob2> that sounds more like a #ubuntu/ubuntu-users question
<yossnet81> bob2: alright
<whiprush> "Bob2, the hammer of the channel."
<dilinger> "hammer", that's quite a nice euphemism :)
<Clint> for "ham"?
* bob2 feels channel-stalked
<ajmitch> bob2: don't ignore your fanclub
<dilinger> bob2: i was just gonna say... i didn't realize Clint was in this channel, too.  i'll have to remember to not say mean things about him.  well, not real mean, anyways
<Clint> i'm not here
<whiprush> ajmitch: whoa, hey now, I don't fanboi bob2.
<whiprush> I merely fear him.
* whiprush narrows his eyes.
<ajmitch> sure, whiprush.
<bddebian> heh
<bddebian> Oh man, don't tell me they are all coming over here or I am gonna end up in #gentoo-devel or some shit.. ;-P
<ajmitch> don't worry, the hurd channels are still empty enough
<bddebian> Oohh, ouch...
* bddebian pulls the knife from his back
<whiprush> http://www.flickr.com/photos/whiprush/13478163/
<Burgundavia> bob2, don't you also babysit launch import scripts?
<dilinger> heh
<dilinger> http://www.flickr.com/photos/whiprush/13477939/
<dilinger> whiprush: i think that's Dafydd Harries, making a rather odd face
<whiprush> the one next to janew?
<dilinger> yea
<whiprush> k
<Mithrandir> mako: Simira wonders if you've sent her any cds lately.
<bob2> Burgundavia: not anymore
<bob2> whiprush: the "someone" in the link dilinger posted is Daf
<ajmitch> bob2: they let you off?
<bob2> who appears to be entering S3
<Burgundavia> what do you do now?
<pitti> Good morning
<ajmitch> hi pitti 
<ajmitch> how are you?
<pitti> ajmitch: fine, up to my aching hand
<ajmitch> ouch
<ajmitch> what did you do to it?
<pitti> ajmitch: inflammation, too much typing
<ajmitch> btw still working on the phpgw security fix - debdiff is ~1MB between the hoary & breezy versions :)
<ajmitch> so I'm icking out what is relevant
<ajmitch> s/icking/picking/
<pitti> mdz: still here?
<bob2> ajmitch: not at canonical anymore
<ajmitch> ah
<ajmitch> on the streets then? 
<bob2> poppin' caps in ganstas.
<Burgundavia> bob2, where do you work now?
<Lathiat> elmo: ping
<bob2> Burgundavia: nowhere, atm
<Burgundavia> ah
<mdz> pitti: yes
<pitti> mdz: I just tested Debian's at version, works fine (including the "at -c" bug I fixed i the breezy version yesterday)
<pitti> mdz: so the only change that's left is now LSB init script
<pitti> mdz: so we might consider merging to get the other bug fixes
<mdz> pitti: what other bug fixes?
<pitti> mdz: http://packages.qa.debian.org/a/at/news/1.html
<mdz> pitti: the current at seems to work quite well
<mdz> I'm not sure that a large batch of changes is the best thing for it right now
<pitti> mdz: ok
<mdz> good night, see you at the meeting tomorrow
<tepsipakki> how strictly is Ubuntu going to implement LSB3.0?
<tepsipakki> I was thinking of the runlevels...
<hunger> How do I use the new linux-restricted-modules? modprobe claims to load those modules, but the HW won't work and lsmod will not list the modules at all.
<bob2> #ubuntu
<pitti> Moin seb128 
<seb128> hey pitti
<seb128> pitti: have you fixed the libnotify hang?
<pitti> seb128: not yet, I fixed the int overflow and debugged a bit, but it's a bit tricky
<seb128> k, I've read your mail, that's why I ask
<pitti> seb128: also, on ppc the notifications don't disapear automatically
<pitti> seb128: I was just too tired yesterday night, sorry
<seb128> pitti: upstream is Chipx86 on #gnome-hackers if you want to speak with him
<pitti> seb128: now I'm bringing langpacks up to shape, then I can continue this
<pitti> oh, thanks
<seb128> pitti: oh, no problem at all, don't worry. There is no hurry, I'm just curious ... :)
<pitti> seb128: I installed 400 MB of upgraded debs yesterday, just to be sure that it isn't an old dbus or whatever
<pitti> but it didn't help
<pitti> so it's a genuine bug
<seb128> :(
<dholbach> hellas
<pitti> Moin Daniel
<dholbach> hey martin :)
<seb128> hey dholbach
<dholbach> hey sb :)
<janimo> hey daniel
<dholbach> janimo: hey jani... you're changing nicks quite often :)
<jsgotangco> dholbach!
<dholbach> morning jerome! hey jane
<pitti> Riddell: ~/ubuntu/langpack-o-matic$ baz commit -s 'infrastructure for shipping additional files'
<pitti> Riddell: :-)
<janimo> dholbach, I'm in a perpetual searh of identity
<seb128> lamont-away, infinity: where is 2.2.8-2ubuntu3? I've uploaded it yesterday but there is no buildlog, I guess that the buildds are waiting for something?
<Amaranth> ook, i broke my system menu
<dholbach> janimo: i do understand that :)
<seb128> Amaranth: hey ... do you have some time to fill a wiki package for smeg to main?
<Amaranth> ok... not sure what to put on it though
<jdub> yo seb128 
<dholbach> hey jdub 
<seb128> hey jdub
<Amaranth> seb128: what should i put in for rationale other than 'is very popular'?
<seb128> jdub: what's up? :)
<jdub> yo dholbach 
<jdub> i am
<jdub> at 2am it seems ;)
<jdub> crazy timezone mess
<seb128> Amaranth: probable default menu editor for 5.10
<seb128> Amaranth: I've patched gnome-panel yesterday, it uses it before gmenu-simple-editor if it's installed
<Amaranth> ?
<Amaranth> didn't it use it already?
<seb128> no
<seb128> right click on the menu
<seb128> "Edit Menus"
<seb128> it was opening gmenu-simple-editor
<Amaranth> oh, it uses smeg now?
<seb128> <seb128> Amaranth: I've patched gnome-panel yesterday, it uses it before gmenu-simple-editor if it's installed
* sivang_ --> back
<Amaranth> ok, now i understand what that means
<Amaranth> i hate english and it's my native language :P
<Amaranth> https://wiki.ubuntu.com/MainInclusionReportSmeg
<Amaranth> does that look good?
<ogra> Amaranth, learn french then ;)
<seb128> Amaranth: yeah, seems to be ok
<seb128> Amaranth: https://wiki.ubuntu.com/MainInclusionReportLibnotify
<seb128> Amaranth: maybe you can fix it to fit this one (ie: the Requirements title, the URL to the packages and the space between points)? These are just cosmetic details but it's nicer :)
<seb128> Amaranth: thanks
<sivang> Amaranth: smeg is in main now ? :)
<ogra> sivang, read above
<Amaranth> seb128: done
<seb128> Amaranth: thanks
<seb128> Amaranth: please ping me when you guys roll a new pyxdg too
<Amaranth> will do
<seb128> thank you
<seb128> jdub: around? I hate gtk engines stuff and I know you like that ... :)
<seb128> jdub: what are we supposed to do with clearlook now that gtk2-engines ship it too?
<Amaranth> change the standalone package to a transition package and build the one in gtk2-engines?
<seb128> why a transitionnal package to do this?
<seb128> it would have the same name
<Amaranth> oh
<jdub> seb128: uuuggghhh
<seb128> the issue is than the Debian guys prefer to keep maintaining that stuff out of gtk2-engines
<Amaranth> seb128: what version of gnome-panel was that?
<seb128> because they say than the real work is done on sf.net by example
<seb128> so it's better to ship this version than the gtk2-engines one
<Amaranth> err, the work has moved to gnome cvs, hasn't it?
<seb128> Amaranth: no sure that's why I ask jdub
<seb128> gnome-panel (2.11.90-0ubuntu4) breezy; urgency=low
<seb128>   * debian/patches/10_defaulteditor.patch:
<seb128>     - change the default menu editor, use smeg before gmenu-simple-editor.
<seb128> for panel
<seb128> but it probably needs a kick to retry, there was a gnome-menus bug
<Amaranth> remenic made it sound like he was going to work in the gtk2-engines module from now on
<seb128> Amaranth: k, still I would like to get jdub's opinion on that :)
<seb128> we already screwed industrial this way
<Amaranth> hehe
<seb128> Debian ships it from its packaging which has the gtk-engines and the icons
<seb128> we have built it once from gtk2-engines
<seb128> which doesn't ship the icon
<Amaranth> oh yeah my panel started crashing again so it's a good thing you filed the bug report after all :)
<seb128> and since gtk2-engines is 2.6
<seb128> and the other package 0.something
<seb128> either we put an epoch on industrial to reship the separate package which is ugly
<seb128> or we have to make an icon package
<jdub> seb128: so unfortunately, industrial seems to have finally moved into gtk-engines
<seb128> Amaranth: it should be fixed this crash, I've patched the panel for it
<jdub> seb128: and clearlooks is in it, but still declared to be maintained outside
<seb128> jdub: that's good, we ship the gtk-engines version ... but we don't have any icon theme due to that
<seb128> industrial icon theme
<jdub> they *still* haven't fixed that?
<seb128> who is supposed to do what?
<jdub> brb, going to shop
<seb128> k
<seb128> later
<seb128> ping me when you are back and want to speak about industrial and clearlooks :)
<Amaranth> seb128: yeah, you fixed it in ubuntu3 which isn't in the archives yet :/
<seb128> Amaranth: <seb128> but it probably needs a kick to retry, there was a gnome-menus bug
<Amaranth> oh, i thought that was just for 4
<seb128> nop, for both
<Lathiat> seb128: noticed how if you try install gnome-devel, it wont due to libgnome-menu-dev not wanting to install, but if you install libgnome-menu-dev manually then its all good?
<seb128> no
<seb128> but gnome-<something> are not supposed to work
<Lathiat> any idea what causes that?
<Lathiat> seb128: why not?
<seb128> because nobody cared to work on "gnome" package
<seb128> we use ubuntu-desktop
<Lathiat> ah, hrm
<Lathiat> well, it does work
<Lathiat> apart from that
<Amaranth> Lathiat: are you on hoary?
<Lathiat> its just gnome-devel i care about
<Lathiat> Amaranth: breezy
<Amaranth> nevermind then
<seb128> your issue is probably it depends on libfam-dev
<pitti> Riddell: now I have the KDE flags, desktop files, etc. in the KDE langpacks, so you can remove them from kde-i18n-foo if you want
<seb128> I've changing that to libgamin-dev
<Lathiat> seb128: what does, libgnome-menu-dev?
<seb128> s/I've/I'm/
<seb128> yep
<seb128> libgamin-dev provides libfam-dev
<Lathiat> oh you mean
<Lathiat> gnome-devel deps libfam-dev
<Lathiat> libgnome-menu-dev deps libgamin-dev
<seb128> but the packaging tools seems to no be happy with that
<Lathiat> so until you install libgnome-menu-dev to install libgamin-dev which then provides libfam-dev
<Lathiat> it thinks it conflicts
<seb128> ??
<seb128> <Lathiat> gnome-devel deps libfam-dev ?
<seb128> not here
<Lathiat> no i cant see that either
<Lathiat> so wheres the problem?
<seb128> <crispin> seb128: FYI, yesterday you made libgnome-menu-dev depend on libfam-dev; this made aptitude want to remove the entire of gnome (as it decided it would be best to install libfam-dev rather than libgamin-dev, causing fam / gamin conflicts
<seb128> I think that's the same issue
<seb128> the packaging tools seems to prefer to remove gnome rather than installing libgamin-dev
<seb128> which provides libfam-dev
<Lathiat> or not to install it
<Lathiat> right
<seb128> right
<seb128> exactly
<seb128> so I'll specify gamin
<Lathiat> libfam-dev | libgamin-dev might fix it
<Lathiat> or the other way around
<seb128> yep
<Lathiat> i guess its hard for apt to figure that kinda thing out
<seb128> <crispin> perhaps it would be better to make the depend "libgamin-dev | libfam-dev" ?
<seb128> <seb128> yeah, I'll do that for next upload
<Lathiat> seb128: ah, ok
<Amaranth> someone actually uses fam instead of gamin?
<seb128> nop
<Amaranth> I wish hoary had gnome-menus 2.10.2 *sigh*
<Amaranth> so many people email me saying they have problems, i say upgrade to 2.10.2, they say problems solved
<mvo> elmo: are you around?
<mbreit> hi! i have a question: Riddel did a sponsored upload for me yesterday, and the build logs now say: universe/sound/noteedit_2.7.1-2ubuntu1: Not-For-Us [optional:out-of-date] . what does that mean?
<janimo> mbreit, could be because previous version is 2build1 ?
<mbreit> yes
<janimo> I don't where how build1 is in the version succession
<janimo> s/how//
<janimo> maybe it should have been build1ubuntu1
<janimo> dunno
<\sh> no
<\sh> build1 never reached the archives
<mbreit> janimo: the same changelog entry was for -2build1 before...
<\sh> mbreit: -2build1 never reached the archvies
<pitti> mbreit, janimo: 2build1 means that version 2 was just reuploaded to be built again, but without actual source changes
<janimo> what is the policy regarding buildX version?
<\sh> mbreit: check http://people.ubuntu.com/~lamont/buildLogs/n/noteedit/
<mbreit> \sh: i know ;)
<pitti> janimo: if we would call it 2ubuntu1, then it would look as if we would have actually changed something, and the package won't be auto-synced from Debian
<janimo> pitti, isn't that the same as lamont 'giving it back' ?
<bob2> not-for-us means the buildd is configured not to build it
<pitti> janimo: no, g-b only works if a package FTBFS previously
<pitti> janimo: if version 2 did build, then it needs a higher version so that the package is actually upgraded on user's machines
<janimo> pitti, I know about 2ubuntu1 , I was wondering if build1ubuntu1 would be a logical next version :)
<pitti> janimo: no, if you change sth, then 2ubuntu1 is the next one
<mbreit> bob2: but why should they be configured not to build noteedit?
<janimo> pitti, does this mean after a rebuild with buildX you can no longer make ubuntuX changes since it would conflict with future debian versions?
<janimo> or is build1 not taken into account in version comparisons?
<pitti> janimo: no, you should treat NbuildK like version N
<janimo> pitti ok, thanks
<pitti> the buildK is just a crude hack
<bob2> the buildd admin configured it like that
<pitti> janimo: buildK is of course taken into account when comparing versions
<bob2> perhaps it was a mistake, or they were waiting for a build-dep to be fixed
<pitti> janimo: it is mostly used when building the same package against a newer library that is in the archive
<bob2> ah, depends on qt
<janimo> almost unrelated: any reason an ubuntu1 package does not show up in lamont buildLogs after 3 hours of it on breezy-changes?
<janimo> I uploaded an xfce4-terminal change 3 hours ago
<mbreit> janimo: universe/x11/xfce4-terminal_0.2.4-3ubuntu1: Dep-Wait by buildd+terranova [-:uncompiled] 
<mbreit>   Dependencies: dbus-glib-1-dev
<_koke> for kubuntu devs, I've just packaged taglib 1.4, for the new upcoming amarok :)
<janimo> mbreit, where is that info?(url)
<mbreit> http://people.ubuntu.com/~lamont/buildLogs/Lists/breezy.all.i386
<janimo> mbreit, thanks :)
<mbreit> bob2: do you mean that every qt-based programs do not build atm?
<bob2> no
<mbreit> bob2: what should i do then?
<Riddell> pitti: great :)
<bob2> mbreit: talk to lamont or infinity
<bob2> it's well outside infinity work hours tho, so go get smashed and bug him on monday ;p
<mbreit> bob2: okay, thanks..
<Riddell> koke: where can I find that?
<koke> http://www.amedias.org/~koke/debian/breezy/
<janimo> If a package gets renamed both Replaces: and Conflicts: are needed right?
<bob2> Replaces says "I have files from $this package, and that's ok".  Conflicts says "if you install me, uninstall $that".
<janimo> bob2, we have the same sw synced from os-works for hoary and now from sid packaged under different names
<janimo> sid users are not affected since they did not have the other upstream
<Treenaks> there used to be a bug in dpkg which required you to use both. but that has been fixed (if I understood keybuk's debconf talk correctly)
<janimo> so I need to add Conflict then I guess
<janimo> Treenaks, which is the one that's enough then?
<Treenaks> janimo: depends.. what do you want to do
<janimo> what currently is xterminal is superseded by xfce4-terminal from sid
<Treenaks> replaces
<Treenaks> I think
<janimo> Treenaks, same terminal app packaged under a different name in sid, and we want to replace our existing package with that
<pitti> janimo: you need an empty dummy package xterminal which depends on xfce4-terminal
<janimo> pitti, so a new greater version of xterminal which is empty?
<pitti> janimo: and xfce4-terminal Replaces: and Conflicts: xterminal << (yourdummypackageversion)
<pitti> janimo: yew
<pitti> yes, even
<janimo> pitti, cool thanks :)
<Treenaks> empty except for changelog, README etc.
<bob2> isn't Conflicting enough to make apt remove it?
<Treenaks> bob2: it is now, yes.. but how will apt know that it needs to install the new package?
<pitti> bob2: no, then it will be held back, I think
<bob2> Treenaks: dist-upgrade will try to get a newer version of xfce4-terminal and say "oh, wow, we have to remove xterminal to get that"
<pitti> bob2: there is no older version of xfce4-terminal, right?
<janimo> pitti, no there isn't
<bob2> oh, ok
<bob2> I mixinterpretd, sorry
<Treenaks> bob2: it's a package rename afaics
<bob2> clearly coffee time
<janimo> IIRC when I said install firefox it just removed mozilla-firefox, isn't this the same scenario?
<Treenaks> janimo: no, it should install xfce4-terminal automatically if you have xterminal installed right?
<Treenaks> janimo: instead of the old xterminal
<janimo> Treenaks, well on dist-upgrade yes
<janimo> pitti, you're (one of) thefirefox packager(s)?
<janimo> I am wondering on the possibility and the benefits of making a firefox package which does not depend on gnome libs
<pitti> janimo: I still refuse to be called firefox maintainer :-)
<jdub> pitti: you touched it last!
<pitti> jdub: no, seb128 did :-)
<seb128> DOH
* dholbach will always have something ... erm ... more important to do :)
<seb128> but dholbach wants it
<jdub> ha ha
<seb128> be nice with him
<dholbach> seb128: we talked about this like 135176367 times already, i said  * N O ! *
<pitti> seb128: would firefox be in universe, and I was asked to review it for main inclusion, it would just be rejected rigorously :-)
<seb128> dholbach: nobody asked you if you want it, we just offer it to you :)
<Lathiat> anyone know the name of the tool that monitors what something does when you run it and creates a debian package out of it
<dholbach> pitti: good thinking
<dholbach> seb128: offering is something where you can say "no", right? :)
<pitti> Lathiat: auto-apt?
* mvo thinks that dholbach will learn to love ff
<seb128> dholbach: no, that's not polite
<dholbach> you're all so mean
<dholbach> what did i do to you?
<seb128> come on, it's funny
<seb128> users will love you
<pitti> packaging is so great and clean...
<pitti> it only needs 20 minutes to build...
<Lathiat> pitti: nah, like running an installer
<Lathiat> and have it automatically just shove the files into a debian package
<dholbach> ok, i sold drugs, paid no taxes, stole lollipops from children - but how does that affect you?
<mbreit> Lathiat: do you mean checkinstall?
<seb128> mvo:
<seb128>   File "/usr/bin/apt-listchanges", line 30, in ?
<seb128>     import apt_pkg
<seb128> ImportError: /usr/lib/python2.4/site-packages/apt_pkg.so: undefined symbol: _ZN1 7pkgPackageManager9DoInstallEv
<seb128> mvo: is that due to new apt?
<mvo> seb128: yes, I'm working on it. the new apt has ... issues
<seb128> k, thanks
<ogra> hmm, no xorg for mad64 :(
<ogra> amd64 indeed
<dholbach> mad64 is good ahahahaha
<seb128> FTBFS?
<ogra> yup
<seb128> cool
<ogra> daniels made a typo or something
<seb128> so daniels has to do a -45 and can fix Xnest
<ogra> debian/rules:106: debian/scripts/vars.amd64: No such file or directory
<seb128> lamont-away, infinity: can you retry gthumb gimp gnome-panel builds?
<pitti> seb128, Riddell: could you please help me with testing the latest langpacks? Riddel, especially for the additional KDE files?
<seb128> pitti: sure
<seb128> pitti: what have I to do?
<pitti> seb128, Riddell: please purge all language-pack* stuff and reinstall the latest breezy version (20050609)
<pitti> seb128, Riddell: then grab the debs from http://people.ubuntu.com/~pitti/langpacks/
<pitti> you should get a french update notification
<pitti> Riddell: and the flags, desktop files, etc. should work now
* Riddell downloads
<pitti> Moin Keybuk 
<pitti> Hi Mez 
<Mez> morning
<Lathiat> Amaranth: are you still seeing gnome-panel crashes on applications updates?
<Lathiat> you said it stopped, but im still seeing it
<Amaranth> i'm seeing it on removal
<Amaranth> menu removal, specifically
<Lathiat> well, im seeing it on when vmware adds its icon/desktop entry
<Lathiat> and yes, i did see that too
<Lathiat> i get it every time i install a package basically
<Lathiat> do i need to break the debugger out
<Lathiat> or is it known?
<pitti> seb128, Riddell: oh wait
<pitti> seb128, Riddell: before upgrading to the new debs, please rm /var/lib/update-notifier/user.d/language-pack*
<pitti> seb128, Riddell: otherwise you won't see the notification
<seb128> notification works
<seb128> and I've get the french msg :)
<pitti> yay
<janimo> what so nasty about firefox, the upstream source or the debian packaging of it?
<pitti> both
<janimo> is the same source used for mozilla and thunderbird too?
<Riddell> KDE est francais
<Riddell> pitti: I don't get a notification however
<janimo> source package I mean 
<dholbach> janimo: it's a 40mb tarball - most people don't know that :)
<pitti> janimo: no, the moz and tbird packages are *much* nicer
<seb128> janimo: all the changes to the diff.gz
<janimo> dholbach, I know I built nvu from it :)
<Riddell> >ls /var/lib/update-notifier/user.d/
<Riddell> notification-2.6.12-3-386
<pitti> Riddell: did you remove the old notification first? YOu already got it the last time you tested, right?
<Riddell> pitti: I've reinstalled since then
<pitti> Riddell: uh, and you really upgraded from 20050609?
<Riddell> reinstalled the operating system
<pitti> Riddell: so did you install the langpacks from scratch, or upgraded l-p-fr from 20050609?
<janimo> is it something inherent to ff or just nobody had time to make a nice package of it?
<Riddell> pitti: installed from scratch
<pitti> janimo: well, if we made the packaging sane, then we had a huge delta to Debian
<janimo> why is the diff so big?
<jdub> mjg59: should i really expect to be able to get to a text console (i810)?
<pitti> Riddell: ah, then that's what it should be like
<janimo> and debian doesn't want it sane? :)
<Riddell> formidable :)
<pitti> janimo: if we separated out the inline patches to debian/patches, then you have the changes twice in the delta
<seb128> pitti: everything works fine here
<Riddell> pitti: how is it decided what does in base and what goes in the other one?
<pitti> Riddell: sudo apt-get install language-pack-fr-base=20050609 language-pack-fr=20050609
<janimo> those patches cannot go upsream? (I guess I'll have to look if I want more details)
<pitti> Riddell: and then dpkg -i the new version -> that should trigger the notification
<seb128> jdub: you didn't ping me back about gtk2-engines, does that mean you don't want to speak about that and I've to start it myself ? :)
<pitti> Riddell: currently a heuristics that decides if the package is KDEish, GNOMEish, or neither/both
<jdub> seb128: oh, sorry
<jdub> seb128: i think we'd be better off using clearlooks upstream if daniel and richard keep maintaining it separately
<seb128> np :)
<seb128> k
<Amaranth> Lathiat: known and fixed
<seb128> but did GNOME guys made some changes to the gtkrc by example?
<Riddell> pitti: I mean between language-pack-kde-fr and language-pack-kde-fr-base
* jdub doesn't like all the aggregation in gtk-engines
<jdub> seb128: i think that'll go in the clearlooks theme by default
<seb128> I'm fine with that
<seb128> k
<pitti> Riddell: ah, right now everything is in -base
<jdub> it's just a slight colour change
<pitti> Riddell: the update packages will be populated after the breezy release
<Riddell> pitti: right
<pitti> Riddell: so that they only contain the actual updates and are small
<pitti> Riddell, seb128: so we are fine with the packs, and theoretically I could throw them at the public?
<pitti> I'm sick of delaying it further
<pitti> and I lost hope that I will get a genuine Rosetta tarball soon
<Riddell> pitti: for the KDE ones you might want to add to the description that installing kde-i18n-xx is needed for full translations
<pitti> Riddell: I think language-selector should take care of that
<pitti> mvo: apropos, do you see any problems with the langpack split wrt language selector?
<seb128> pitti: yep
<Lathiat> Amaranth: ok, cool
<Riddell> pitti: well it already suggests language-support-kde-fr
<mvo> pitti: I'm a bit busy right now, can we talk about it later?
<pitti> Riddell: ouch, it does?
<pitti> mvo: sure
<Amaranth> Lathiat: new gnome-panel also opens smeg instead of gmenu-simple-editor :)
<pitti> mvo: I just mean in general
<pitti> Riddell: that package will not exist
<pitti> Riddell: well spotted, I fix that
<Riddell> :)
<Riddell> I now have /var/lib/update-notifier/user.d/language-pack-es_20050701
<pitti> Riddell: we don't want to split the support packages, too, otherwise elmo's heart attack will be even worse
<Riddell> shouldn't that be -fr ?
<pitti> hm, yes...
<mvo> pitti: probably not 
<Lathiat> Amaranth: ubuntu patch?
<pitti> Riddell: yes, l-p-es was a copy&paste bug...
<Amaranth> Lathiat: yeah
<Amaranth> hey, that reminds me
<Lathiat> Amaranth: get it in all the major distros then bash the g-p maintainer ;p
<Amaranth> 0.8 is now on the same level as gmenu-simple-editor
<Amaranth> it shows menus and can toggle things on and off :D
<Lathiat> :)
<Amaranth> http://rafb.net/paste/results/GxCVPn71.html
<Amaranth> evil code
<Lathiat> looks lovely :)
<Amaranth> but so far after the initial long load time (which i know how to fix) everything is instant, no waiting to reload the entire menu layout from pyxdg anymore
<bob2> Amaranth: did you explain the pyxdg problem to Mez?
<Amaranth> bob2: yeah
<bob2> Amaranth: thanks :)
<Amaranth> bob2: he said fix g-a-i and backport it :P
<Mez> actualkly, you said that
<Amaranth> i did?
<bob2> wtf
<Amaranth> i must have been up too long
<Mez> lol
<bob2> at least make it conflict
<Mez> I didnt say much apart from why should it conflict if g-a-i is meant to use it
<bob2> randomly breaking g-a-i for people is terrible
<Amaranth> hey, if g-a-i wasn't setting pyxdg's locale and just letting it figure out the locale on it's own this wouldn't be a problem :0
<Amaranth> err, :)
<Lathiat> Amaranth: ooc, how do you control visibility?
<Amaranth> Lathiat: what?
<bob2> do *something*
<Lathiat> Amaranth: how do you make an item invisible?
<Lathiat> like, technically
<bob2> if this was debian, someone would have an RC bug by now
<Lathiat> im just randomly curious
<Lathiat> whats g-a-i?
<Amaranth> Lathiat: you set NoDisplay=true in the .desktop file or use an <Exclude> in applications.menu
<Lathiat> Amaranth: so the user has a local applications.menu they can modify?
<Amaranth> Lathiat: one gets created in ~/.config/menus/applications.menu by PyXDG
<Lathiat> Amaranth: ah, cool
<bob2> Amaranth: Mez if you're not seriously going to patch g-a-i, you need to add a conflict.  or something.
<bob2> leaving it broken is just crappy.
<Amaranth> bob2: I'm not a backports guy, it's not up to me. :)
<Amaranth> afaik g-a-i is broken in breezy too
<Mez> bob2 - It's broken in unofficial - I've no idea why, and no idea where to fix it
<Amaranth> Mez: it's broken in the official ones too because of pyxdg
<bob2> Mez: is unofficial in ubuntu.com?
<bob2> right
<Amaranth> Mez: make pyxdg conflict with g-a-i
<ogra> Amaranth, doesnt that break breezy ?
<bob2> versioned conflicts, yay
<Amaranth> bleh, he has to make it work with breezy too?
<Mez> Amaranth, theres been changes to crap in the package I dont know about - I dont have access to it.
<ogra> bob2, eeek
<Mez> this is all on the UNOFFICIAL servers
<Mez> which is going to be 403'd soon enough anyways
<bob2> Amaranth says it's in the "official" backports archive, too
<bob2> are yo usure that's not the case?
<Mez> it is not in official
<Amaranth> smeg isn't in official?
<Mez> http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary-backports.all.i386
<Mez> smeg is
<Mez> pydxg isnt
<Amaranth> pyxdg has to be
<Amaranth> it's called python-xdg
<bob2> I thought smeg needed the new python-xdg?
<Amaranth> it does
<Mez> python-xdg isnt in official either
<Amaranth> ...
<Amaranth> then smeg doesn't work
<bob2> pyxdg is the source package
<Mez> smeg doesnt seme to be in official eother
<Mez> either *
<Amaranth> ok, i'll edit ubotu and tell it to stop telling users to look in backports :/
<Mez> It's in old backports Amaranth 
<bob2> http://archive.ubuntu.com/ubuntu/pool/universe/s/smeg/
<bob2> that doesn't look like a proper ubuntu version
<Amaranth> Mez: old backports are less than useful
<Amaranth> no offense
<bob2> smeg_0.7.5-0ubuntu1~hoary1 
<Mez> bob2, yeah, weird that-  it was inthe buildQ ... but now it isnt
<Amaranth> but there is some real crack in there
<Amaranth> bob2: that's the backports versioning
<Kamion> bob2: looks reasonable to m
<Kamion> e
<Mez> Amaranth, smeg was in official
<bob2> Kamion: I mean, "not in an ubuntu release"; isn't that version a backport-esque one?
<Mez> but it doesnt seem to be now
<ogra> Mez, its there:  smeg_0.7.5-0ubuntu1~hoary1_all.deb
<Mez> ogra - yes, it may be there.
<Mez> but, it USED to be in the lists for tbe buildd
<Mez> now it isnt
<Mez> so i dont know if it's actually in the repo, or just dead
<bob2> dude
<ogra> it built already...
<dholbach> i'm off - see you later
<bob2> it's in the backports repository
<bob2> Mez: http://archive.ubuntu.com/ubuntu/dists/hoary-backports/universe/binary-i386/Packages.bz2
<ogra> but will be uninstallable
<Amaranth> python-xdg isn't in backports though?
<bob2> Package: smeg
<bob2> Filename: pool/universe/s/smeg/smeg_0.7.5-0ubuntu1~hoary1_all.deb
<Mez> python-xdg = in backports unofficial
<pitti> dholbach: have fun
<Amaranth> Mez: Like I said, I will not tell users to use the old backports.
<Mez> bob2, fair enough - confused as to why it;s not showing up
<Mez> Amaranth, so what needs to be done to get smeg working in new backports?
<ogra> woah.... building moodle takes more then 30min .... its just copying php files.... o_O
<bob2> xdg is not in backports, afaict
<pitti> Riddell: ok, I fixed the support dependency and the notification file name
<doko> hi all
<Riddell> pitti: I'll await the storm on breezy-changes then :)
<Amaranth> Mez: fix g-a-i and backport it and pyxdg or add a versioned conflict against g-a-i in pyxdg and backport just it
<bob2> doko: a zope3 guy was looking for you yesterday
<bob2> Amaranth: how is g-a-i broken using official backports if they don't contain xdg?
<Amaranth> bob2: he asked how to get smeg into backports
<bob2> Amaranth: smeg is in backports
<Amaranth> it isn't installable
<doko> bob2: which channel?
<bob2> doko: here
<Amaranth> it can't be, it need pyxdg 0.14
<bob2> doko: philiKON
<pitti> Hi doko, welcome back
<pitti> Riddell: language packs are filtered, they won't appear :-)
<Mez> Amaranth, well if it's showing up in Packages.bz2 - it's installable right?
<Amaranth> Mez: err, it can't install, it isn't possible
<bob2> Mez: no
<bob2> Mez: that just means it's available
<Amaranth> Mez: the package actually does depend on pyxdg >= 0.14, i'm not stupid :)
<bob2> it's up to the people who upload it or request the build to make sure it's installable
<Mez> bob2/Amaranth then shoulnt it have dep-waited on the buildd
<bob2> no
<bob2> it built fine
<Mez> yes, and then it needs to be installed..
<ogra> Mez, why should it dep wait ?
<bob2> Mez: not to build it
<bob2> to run it, perhaps
<ogra> all build deps were fulfilled
<bob2> presumably it has no test suite, tho
<Amaranth> no, it's a GUI app :P
* Mez shrugs
<Amaranth> oh, you mean like ./configure checking? it uses distutils
<Mez> so - Amaranth what needs to be done-  pydxg from breezy to be backported?
<bob2> don't people test whether something works before asking it to be added to the backports repository?
<Amaranth> Mez: with a versioned conflict against g-a-i in hoary
<Mez> bob2, this was asked to be added when we thought it would build
<Mez> Amaranth, whats the package name/
<bob2> you need to test build, then test install, dude :)
<Amaranth> python-xdg?
<Mez> nvm
<bob2> it'll build fine, it just won't be installable
<Mez> Amaranth, to backprt that I need to get a main uploader to install it
<Mez> modify it *
<Mez> to put the conflict
<Amaranth> seb128 seems to be the one that handles that package
<seb128> which one?
<Mez> pydxg
<seb128> what is the issue with it?
<Amaranth> seb128: in order to be backported it needs to conflict with the g-a-i in hoary
<Mez> seb128, it needs to have a Conflict on the haory version of g-a-i to be backported
<seb128> bah
<seb128> I'll not that for next upload
<seb128> but I already said changing packages only to fit backports is bad
<Kamion> actually the Conflicts is not just to fit backports, it's for sane partial upgrades, surely?
<Mez> mvo did the last upload it seems
<seb128> dunno, pyxdg has not changed afaik
<seb128> what file conflict?
<Amaranth> from hoary?
<Amaranth> the way configuration settings are set has changed completely
<seb128> is there a file conflict?
<Amaranth> this is why g-a-i fails in the first place
<Amaranth> no
<seb128> so what is the issue?
<seb128> I'm not convinced that a Conflict is the right way to do what you want to do
<Amaranth> g-a-i needs to be fixed in breezy and backported then
<seb128> ie?
<seb128> what is broken and what does fix it?
<Amaranth> i know there was a patch in bugzilla to make g-a-i work with the new pyxdg API but i dunno if breezy has it
<Amaranth> but i _really_ need to go to bed now, everything is a blur, my hands are shaking, and my eyes hurt
<Amaranth> should have been in bed 3 hours ago...
* Amaranth passes out
<pitti> seb128: ok, I can pull the big langpack upload trigger now :-)
<mvo> Mez: can we talk about g-a-i and python-xdg in a couple of minutes? I would like to help you fixing it, but I'm a bit busy right now
<mjg59> jdub: Once libvgahw.a is fixed
<seb128> pitti: cool
<jdub> mjg59: aha, cool - thanks :)
<Mez> mvo: I've no idea whats going on with it - you'll need to talk with Amaranth 
<ogra> seb128, ping
<seb128> pong
<ogra> seb128, what do you think about AudioCDBurning.... i'd like to move it to it implemented
<ogra> -it
<ogra> (after looking through the bug database indeed)
<seb128> we are obviously not changing it
<seb128> we have not get a lot of feedback but well, move it if you want
<ogra> seb128, yep... thats what i thought...
<JaneW> ogra: so whats the verdict...? do we need to get more feedback still?
<ogra> JaneW, sure, but we wont change it in big amounts... the feedback will only be regular bug reports...
<ogra> so its fine to move it (just doing)
<JaneW> ogra: great thanks :)))
<ogra> done :)
<JaneW> ogra: ta - BTW mdz wanted me to swap implemented and completed around... 
<ogra> oh
<JaneW> I just changed it for you...
<JaneW> with the right colour too ;)
<ogra> thanks :)
<Mez> mdz: ping
<JaneW> *** Reminder: Special BreezyGoals Update Meeting in 3 hours time - Friday 5 August 2005, 15:00 UTC ***
<mvo> Mez: he's probably sleeping
<WaterSevenUb> Hi... gnome-app-install does not have a translatable menu entry... I would like to make a patch and correct that. No idea where to start. Help?
<Mez> mvo: for when he wkes up
<mvo> WaterSevenUb: have a look at http://www.niran.org/code/soc/
<Mez> infinity: ping
* pitti grumbles at his ISP
<pitti> elmo: sorry for the NEW flood of the langpacks...
<hunger> pitti: Gibt's was neues bezglich des cryptodisk skriptes?
<pitti> hunger: ELANG :) sorry, still no time for it
<hunger> pitti: ELANG?
<pitti> hunger: Inglisch schpoken hier :-)
<hunger> pitti: Yeah, sorry, I meant to msg you personally.
<WaterSevenUb> hhmm... it seems to me that GKSUEXEC (GKSU) does not have also a translatable GNOME menu entry "Run as different user".
<WaterSevenUb> help?
<hunger> do the restricted modules work in breezy? They modprobe fine here but lsmod claims they are not installed afterwards.
<Mez> mvo: ping
<mvo> Mez: pong
<Mez> mvo: got a debdiff to fix one of your packages
<mvo> Mez: nice, please mail it to me (or attach it to the bug if there is already one)
<Mez> mvo: http://dev.kubuntu.org.uk/~mez/debdiff/bittornado.diff
<Mez> It's just an unmet dep :d
<Mez> mvo: which email address? michael.vogt@ubuntu.com ?
<mvo> Mez: yes please! thanks 
<yuacht> how stable is breezy atm? =)
<seb128> pitti: do you know if we had any discussion about cdrdao for main?
<\sh> seb128: for what do u need cdrdao? cue/bin stuff is handled as well bei cdrtools
<\sh> s/bei/by/
<seb128> nautilus-cd-burner uses that to duplicate CDs
<ogra> seb128, we had this discussion...
<seb128> when?
<ogra> it was one reason we discarded gnomebaker
<seb128> who "we"?
<ogra> you and me
<seb128> no
<ogra> at udu and later here
<seb128> we said that better to use gst than command line tools
<seb128> for cdaudio
<seb128> we never spoke to drop n-c-b
<ogra> heh, nope
<seb128> k, so n-c-b uses cdrdao
<ogra> but we talke about cdrdao inclusion
<seb128> that's a fact
<\sh> seb128: can u fix it to use cdrtools?
<seb128> how do you duplicate a CD with cdrtools?
<\sh> dd to create the image + cdrtools to write
<seb128> you want to make a patch for ncb ?
<ogra> \sh, does it work on the fly if you got two CD roms ?
<\sh> seb128: or read this one: http://cdrecord.berlios.de/old/private/man/README/README.copy
<ogra> i think thats the rationale for using cdrdao...
<ogra> ... not using temp space
<Mez> doesnt cdrdao get set as suid root though
<seb128> Mez: no
<seb128> -rwxr-xr-x  1 root root 550600 2005-04-05 01:07 /usr/bin/cdrdao
<ogra> no need for suid root stuff... we have pitti, we dont need root ;)
<Mez> yeah, and it has to run as root
<Mez> thats why we changed k3b not to use it IIRC
<seb128> no
<seb128> read /usr/share/doc/cdrdao/README.Debian
<ogra> Mez, it should only be a matter o the right group settings
<ogra> of even
<seb128> it just no run with realtime 
<\sh> seb128: realtime? 
<seb128> \sh: scheduler priority
<mvo> elmo: can you please sync python-apt from debian incoming (0.6.13.1) [override ok] ?
<\sh> Mez: k3b needed it for vcd stuff because of cue/bin stuff and vcdimage
<\sh> Mez: since cdrecord is supporting bin/cue k3b doesn't need it 
<ogra> seb128, realtime stuff shouldnt be an issue with burnproof enabled...
<ogra> you might create coasters on slow machines without burnproof
<seb128> no it's not
<\sh> ogra: and copying cds over two drives...should be working with dd if=/dev/cdrom | cdrecord .... -dev=<second drive>
<seb128> anyway I don't want to discuss that for hours
<ogra> \sh, thats not an option...
<seb128> I'm just asking pitti if he has an idea of cdrdao is suitable for main
<seb128> not discuss how it works
<ogra> heh... ok
<seb128> I'm too busy to patch n-c-b all over the place to use other commands and change all the parsing code
<seb128> so either somebody wants to patch that
<seb128> or I'll ask to use cdrdao
<Mez> hmmles
<Mez> should a package be changed to suggest firefox instead of mozilla-firefox
<pitti> Mez: yes, for breezy
<Mez> cool
<seb128> pitti: read my question?
<mdke> Mez, quick backport question: is it correct that the official backports will receive no testing, whereas old backports did?
<Mez> mdke: that's still to be checked
<pitti> seb128: just returned from lunch
<pitti> seb128: I talked with haggai about it a bit
<pitti> seb128: do we need it?
<Mez> we try to test them before hand ... but, theres shouldnt e too many problems as they;re all from breezy
<mdke> Mez, well... so adding backports is essentially similar to simply getting packages from breezy (unstable)
<seb128> pitti: right click on a CD from computer:///, you have an option to duplicate the CD ... that uses cdrdao
<seb128> pitti: we can
<seb128> 1- suggest cdrdao, let it to universe, and not get that working out of the box
<seb128> 2- promote cdrdao
<seb128> 3- rewrite n-c-b code to use something else
<seb128> I'm too busy for 3, so either somebody step for that
<pitti> seb128: as long as it's not setuid root, I don't mind including it into main
<seb128> or that's one of the other options
<pitti> and I don't think it's necessary
<seb128> pitti: k, thanks 
<seb128> pitti: it's not by setuid by default
<pitti> I talked with haggai about several cdrdao issues, but I can't remember any more...
<seb128> what is necessary? setuid or the duplicate feature?
<mdke> Mez, the stability section on the UbuntuBackports page is wrong then?
<pitti> setuid, and other cdrdao bugs
<Mez> that page needs updating mdke 
<seb128> pitti: k
<pitti> seb128: out of the box would mean to include it in desktop seed=
<seb128> pitti: I'll ping mdz when he's around about this before making a wiki page
<seb128> pitti: yeah, I know
<mdke> Mez, that's what I said
<Mez> mdke: that's for the old backprots
<pitti> ?
<Mez> mdke: feel free to update
<mdke> Mez, well the "How to use" section is for new backports isn't it?
<seb128> pitti: is this "?" for me?
<pitti> nevermind :-)
<pitti> it belonged to the seed question
<Mez> mdke: yes, someone from docteam changed it
<mdke> Mez, ok i've made some changes to the page, better check
<seb128> pitti: oh, yep, we should have it with the desktop
<pitti> seb128: who was the libnotify maintainer again (nick)?
<seb128> Chipx86
<pitti> I continue debugging now
<pitti> thanks
<mdke> Mez, i wonder if bugs with the new backports should be filed as breezy bugs?
<Mez> mdke: theres a place to file them
<mdke> Mez, on the forum?
<mdke> or malone?
<Mez> mdke: https://launchpad.net/products/ubp-hoary/+filebug
<mdke> ok i'll add that to the page
<Mez> ;)
<mdke> Mez, so if the bug is with breezy, you can easily push it along, that's cool
<yuacht> how long is it until X is stable for all-day use in breezy? =)
<mdke> Mez, ok page updated
<janimo> yuacht, it is pretty usable already, see daniels' mail today on the ubuntu lists
<pitti> seb128: do you know a bit about libpopt? Is it used in many gnome programs?
<yuacht> will do! appearantly my subscription doesn't work then since i've recieved nothing, betted sign up again
<seb128> pitti: yep and yep
<pitti> seb128: it fails right on parsing the command line args with popt
<pitti> seb128: so libpopt generally works on ppc?
<seb128> correct
<pitti> ok, thanks
<seb128> np
<bddebian> Hello
<\sh> dpkg: error processing /var/cache/apt/archives/libopenh323-1.15.3c2_1.15.3-3_i386.deb (--unpack): trying to overwrite `/usr/lib/libopenh323.so.1.15.3', which is also in package libopenh323-1.15.2c2
<WaterSevenUb> Carlos: why are there Portuguese and Portuguese (Portugal), besides the brazilian portuguese? It seems a problem, no ? (i'll be back in a few minutes).
<carlos> WaterSevenUb, because people choose to translate using those language codes, by default we are offering now Portuguese or Brazilian Portuguese and nothing more
<crispin> \sh: yeah, I get that as well
<hunger_> crispin: \sh: so did I.
<carlos> pitti, how is called your script to extract .po and .pot files from build packages? extract_po?
<pitti> carlos: pkgstriptranslations, it's a pacakge
<carlos> ok
<carlos> thanks
<\sh> i just used dpkg --force-overwrite -i /var/cache/apt/archives/libopenh232*
<\sh> now it's working
<WaterSevenUb> carlos: hhmm... There are three types of "portuguese" in Rosetta. "Portuguese", "Portuguese (Portugal)", "Portuguese (Brazil)". The "Portuguese" is the active translation to Portuguese. However, if a user arrives to "Portuguese(Portugal)" it can translate too, perhaps the same templates that are already translated in "Portuguese". So, are the templates in "Portuguese (Portugal)" integrated to "Portuguese"=
<WaterSevenUb> carlos: but if they are integrated it seems to me conflicts can arise.... 
<carlos> wasabi, Portuguese(Portugal) does not appear to create new translations, only if someone created it before we "hide" it or if there is already a pt_PT.po file that gets imported into Rosetta
<carlos> s/wasabi/WaterSevenUb/
<calc> how do you make nfs work on ubuntu, it seems rpc is disabled for external interfaces
<Lathiat> calc: apt-get install portmap?
<ogra> calc, theris a howto on the wiki
<calc> ah i found it now
<calc> it is blocked by default and you have to allow it in hosts.allow
<calc> hmm that comment i read was just junk
<calc> heh
<calc> even after doing all of that i still end up getting an "RPC: Program not registered" error
<ogra> you started portmap and nfs-kernel-server ?
<ogra> s/started/restarted/
<calc> ah i forgot to restart nfs-kernel-server that was the problem, thanks
<Lathiat> calc: have you got a firewall?
<ogra> :)
<Lathiat> ah
<calc> now it acts like its mounting it but hangs
<calc> Lathiat: not between the ubuntu box and knoppix machine trying nfs mount
<calc> seems it just had to time out on something it eventually finished mounting
<ogra> infinity, ping 
<carlos> pitti, hi, around?
<pitti> carlos: yes
<carlos> pitti, I just sent you a draft of the spec about oo.org and firefox language packs
<carlos> pitti, I did a mistake with the attachments
<carlos> but you should have it in a new email
<carlos> pitti, would you take a look on it before leaving today?
<pitti> elmo: Sub-process /usr/bin/dpkg received a segmentation fault.
<pitti> elmo: sorry, that was not for you
<pitti> carlos: yes, sure
<carlos> pitti, thank you 
<carlos> pitti, I will send it again with your input changes and with copy to doko later today
<doko> carlos: did you send something to me already?
<carlos> doko, oh, are you online?
<carlos> doko, I thought you were not....
* carlos sends a copy to doko
<doko> I was offline until 14:00 UTC
<carlos> doko, sent
<dholbach> re
<doko> pitti: is there a list of locales/country codes for which lanugage packs are built?
<mvo> elmo: synaptic sync from incoming please (support for apt >= 0.6.40)
<pitti> yes
<pitti> doko: http://people.ubuntu.com/~pitti/langpacks/countries http://people.ubuntu.com/~pitti/langpacks/languages
<pitti> doko: however, we don't have all of these
<pitti> doko: apt-cache search language-pack
<pef> hello
<ogra> Kamion, i committed two small changes to the edubuntu seeds can you merge it ?
<Kamion> merge to where?
<Kamion> ogra: ^--
<Mez> Cxx Transition at the moment is just a new soname right?
<Mez> meh
<Mez> nvm
<mdz> seb128: yes?
<mdz> Mez: yes?
<mvo> good morning mdz 
<mdz> morning
<ogra> grmpf
<seb128> mdz: hi
<seb128> <seb128> pitti: right click on a CD from computer:///, you have an option to duplicate the CD ... that uses cdrdao
<seb128> <seb128> pitti: we can
<seb128> <seb128> 1- suggest cdrdao, let it to universe, and not get that working out of the box
<seb128> <seb128> 2- promote cdrdao
<seb128> <seb128> 3- rewrite n-c-b code to use something else
<seb128> <seb128> I'm too busy for 3, so either somebody step for that
<seb128> 
<pitti> brb
<seb128> mdz: any opinion on moving cdrdao to desktop for that?
<JaneW> *** Reminder: Special BreezyGoals Update Meeting in 10 mins time - Friday 5 August 2005, 15:00 UTC ***
<JaneW> in #ubuntu-meeting
<mdz> seb128: should be ok, as long as it isn't setuid or anything (main inclusion report)
<seb128> mdz: k. I was asking if there is objections before making a wiki page for it. Thanks
<Mez> what would the reason be for a package to just... not exist in breezy if it existed in hoayr
<bddebian> Mez: It has been replaced / supersceded?
<hunger> Any chance of getting the new qemu version into breezy? It is out for a while now... and the old deb is not even installable in breezy:-(
<pitti> argh, I get a neverending succession of panel failures...
<pitti> grumpf
<seb128> pitti__: when that happens for the panel: gnome-session-remove gnome-panel && gnome-panel
<pitti__> thanks
<doko> carlos: where can I get the draft in text form?
<Mez> bddebian, not as far as i can see
<carlos> doko, It's a wiki only available from Brazil
<sladen> hunger: if it's not installable, that's a bug and should be fixed
<carlos> doko, I can send you the wiki page content as a text file if you want
<doko> carlos: would be nice
<sladen> hunger: however, it's UVF and so if it can be fixed with a patch (I think somebody mentioned it was the BIOS) that would be better
<hunger> sladen: UVF?
<janimo> qemu is in universe so no strict UVF
<janimo> hunger, upstream version freeze
<bddebian> Mez: What package?
<carlos> doko, pitti sent
<hunger> jamesh: What does that mean?
<ogra> janimo, even universe packages need approval
<janimo> elmo is known to sync if asked nicely ;)
<ogra> janimo, (it is granted normally without probs, but UVF applies to universe too)
<hunger> Well, qemu is not installable at this time and outdated on top of that;-)
<janimo> hunger, debian does not have 7.1 either, maybe a bug needs to be filed on them 
<janimo> 0.7.1
<janimo> ogra, I know but it's not strict as I was saying :)
<ogra> janimo, but there shouldnt be upstream version updates without a request...
<janimo> ogra, sure
<_d4vid> i become at start this.. 
<_d4vid> gnome start
<_d4vid> Error activating XKB configuration.
<_d4vid> It can happen under various circumstances:
<_d4vid> - a bug in libxklavier library
<_d4vid> - a bug in X server (xkbcomp, xmodmap utilities)
<_d4vid> - X server with incompatible libxkbfile implementation
<_d4vid> X server version data:
<_d4vid> The X.Org Foundation
<_d4vid> 60802000
<_d4vid> If you report this situation as a bug, please include:
<_d4vid> - The result of xprop -root | grep XKB
<_d4vid> - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
<tseng> please dont flood the channel.
<_d4vid> where can i post it _ 
<_d4vid> ?..
<HWolf> pastebin
<Kamion> or a bug report
<shaya> for those having problems with being unable to switch to VTs from X, I just fixed it for myself
<shaya> purged xkeyboard-config (force-depends) and then reinstalled it
<shaya> base.lst (which a bunch of symlinks pointed to) wasn't there
<shaya> I then had to stop X and restart it for it to work.
<Makako> I believe it's not only that, all special characters stopped working after a dist-upgrade
<Makako> Even the pipe symbol and such
<shaya> you can tell if this is a problem if you run setxkbmap and it complains about being unable to find some files
<shaya> Makako: try what I just said
<shaya> purge xkeyboard-config
<shaya> reinstall it (apt-get -f install)
<Makako> Thx
<shaya> you probably don't have a base.lst file in /etc/X11/xkb/rules/
<shaya> any change?
<Makako> I just have no access to my Breezy installation.
<shaya> ah
<Makako> But the X packages seem to have more bugs: The link /etc/X11/X points to a file which doesn't exist
<Makako> Most recent packaages
<shaya> not on my system
<_d4vid> Section "InputDevice"
<_d4vid>         Identifier      "Generic Keyboard"
<_d4vid>         Driver          "kbd"
<shaya> lrwxrwxrwx  1 root root 17 2005-06-10 11:58 /etc/X11/X -> /usr/bin/X11/Xorg
<_d4vid> is ok so ?
<Makako>  /usr/bin/X11/Xorg doesn't exist anymore, the binary is in /usr/bin/X11R6/Xorg
<shaya> hmm
<shaya> on my system is exists
<mdz> infinity: #ubuntu-meeting
<Makako> I will do a fresh breezy install and dist-upgrade later today
<shaya> lrwxrwxrwx  1 root root 17 2005-07-20 10:02 /usr/bin/X11/Xorg -> ../X11R6/bin/Xorg
<shaya> maybe i created that?
<shaya> don't remember
<Makako> shaya: Maybe. ;)
<shaya> dpkg -S doesn't find it
<Makako> shaya: That's normal coz the link gets created with a post-install (or pre-install?) script
<Makako> shaya: dpkg -S doesn't find these
<shaya> greping dpkg/info/*
<shaya> xserver-xorg.postinst:THIS_SERVER=/usr/bin/X11/Xorg
<shaya> ln -sf "$THIS_SERVER" "$NEW_SERVER_SYMLINK"
<Makako> hmm... 
<shaya> hmm
<shaya> cant tell what its doing
<shaya> but its deffinitely trying to handle it
<shaya> :)
<Makako> seems like
<Kamion> shaya: that symlink needs to be made absolute rather than relative
<Kamion> because /usr/bin/X11 is a symlink to /usr/bin, so ../* symlinks pointing out of it are a bit of a movable feast
<shaya> Kamion: so you're saying my X is going to break again?
<Mez> daniels: ping
<lamont> shaya: it's always going to break again, the question is "_when_?"
<lifeless> seb128: when I install nautilus-python, then run nautiluls-file-management-properties it segfaults
<lifeless> do you know/care/hint ?
<lifeless> in fact, its called abort from within libnautilus-python.so
<seb128> that's a known issue here and upstream
<seb128> upstream recommended to drop the package
<lifeless> ouch
<seb128> there is a new upstream version since, but nautilus doesn't start here with it
<seb128> so I've not uploaded it, I need to start that with jdahlin (upstream)
<seb128> s/start/sort/
<seb128> it's quite low priority atm though
<lifeless> ok
<lifeless> want a cheap hack to let it work ?
<seb128> yes please
<lifeless> src/nautilusmodule.c - comment out the Py_FatalError(..);
<lifeless> that will make it not init the module peroperly, but letfile-management-properties work
<seb128> k, will do that, so at least it doesn't crash nautilus for users who have it installed :)
<lifeless> great, thanks
<seb128> thanks
<seb128> np
<HiddenWolf> ubuntu-desktop depends gnomeoffice depends gimp depends libexif10 -> uninstallable
<HiddenWolf> :(
<Kamion> gimp is dep-wait aalib1-dev, needs a buildd admin to kick it
<seb128> that's known and waiting for a buildd guy to kick the build
<HiddenWolf> right. :)
<HiddenWolf> xorg worked out of the box tho. At least, seems like it. :)
<HiddenWolf> Go daniels!
<Lathiat> haha
<koke> pitti: what happened to https://launchpad.net/malone/bugs/907 ??
<pitti> koke: oh, apparently nobody uploaded it so far
<koke> I tracked hoary-changes but forgot about it some time ago :)
<koke> I've just found the bug again
<koke> 6th in the list and assigned to me :)
<pitti> from time to time I check the Debian status of such bugs, but it's not yet fixed in Debian
<pitti> koke: if you wnat to upload it, just go ahead
<koke> I can't now :(
<koke> maybe yes, I don't have my gpg key here
<koke> but meybe the package was uploaded to  my server signed
<pitti> koke: then please email me a debdiff
<pitti> koke: I don't look at malone bugs, but I read my email :-)
<koke> :D
<_d4vid> what i need to change that xkb works correctly ?
<koke> pitti: sent
<pitti> thx
<ogra> pitti, already going ? or do you have a minute ? 
<pitti> one minute is fine :-)
<seb128> _d4vid: read daniels' mail on the lists from this morning
<dholbach> bye everybody, i'm off
<bob2> someone fix firefox so it doesn't loose my history when it crashes
<bob2> kthx
<Lathiat> the tab crash recover thing might be handy
<bob2> losing the contents of the url history is just crap
<Kamion> mdz: base-config ready to go for InstallerStage2Progress, but I have to run now, so it'll be when I get back
<Nafallo> mako: we might have a swedish loco soon ;-)
<CarlFK> Kamion - http://pictures.personnelware.com/carl/temp/P1010048.JPG
<CarlFK> A) it errored, B) there is no bootstrap.log in /t/v/log
<CarlFK> if I don't get a responce, ill bugzilla 
<jasoncohen> Mez, thanks for getting mozilla-mplayer with gtk2 into breezy
<Mez> jasoncohen, no problem
<Mez> now i need to get it working on amd64
<lamont> mdz: ping
<mdz> Kamion: cool
<mdz> lamont: pong
<jasoncohen> Mez, any reason 2.85 isn't going into breezyZ?
<jasoncohen> *breezy
<Mez> UV
<Mez> UVF *
<pef> bye !
<_d4vid> hi all
<shaya> today's libsoup upgrade broke evolution
<shaya> so name change (.7->.8) making calendar and tasklist unlinkable
<shaya> mailer/contacts still work
<shaya> seemingly a symlink from .8 -> .7 lets it work
<CarlFK> ok, where do I post breezy bugs?
<ogra> bugzilla and malone
<CarlFK> http://bugzilla.ubuntu.com/
<ogra> for main
<CarlFK> breezy setup
<ogra> breezy setup ? 
<CarlFK> yes
<ogra> you mean the installer ...
<CarlFK> http://pictures.personnelware.com/carl/temp/P1010048.JPG
<CarlFK> yes
<ogra> bugzilla then
<ogra> universe bugs go to https://launchpad.net/malone/, but the installer is surely main ;)
<CarlFK> yup
<RapaportM> can anyone troubleshoot an install error with me?
<kilo-bug> where can i get wine
<kilo-bug> plz
<ogra> bottleshop ?
<kilo-bug> haha
<kilo-bug> lol
<kilo-bug> :P
<ogra> its in universe
<kilo-bug> the application
<kilo-bug> universe?
<ogra> and this is a #ubuntu question ;)
<kilo-bug> les
<kilo-bug> wine alows you to run windows app in linux
<dholbach> hi
<dholbach> are there any other UbuntuExpress hackers around?
<ogra> dholbach, they arent around here
<ogra> dholbach, look if there is a #guadalinex channel....
<dholbach> thanks ogra
<sivang> hey people
<sivang> how's friday going? :)
<thesaltydog> not bad... summer holidays start on monday :-)
<sivang> Can anybody help me set up a library build by autotools, I need to toss some functions in, and don't really know what's needed to do that using autotools.
<sivang> thesaltydog: you a student ?
<thesaltydog> sivang, ??? I was, many years ago...
<sivang> thesaltydog: ah, you mentioned summer holidays so I thougth you were one..
<thesaltydog> worker summer holidays
<ogra> woah, my evo just crashed....
<ogra> it has a autorecovery function for unsent messages now... extremly cool
<eruin> what's the language select command thats supposed to be in system->administration in breezy now?
<dholbach> eruin: doesnt it show up in the menu after installation?
<eruin> dholbach, nope, not after a gnome-panel restart, x restart or even reboot
<dholbach> wow
<eruin> I thought so too
<eruin> :P
<dholbach> and you DID install language-selector? :)
<eruin> not explicitly, no
<dholbach> oh well... then :)
<dholbach> hope that helps :)
<eruin> doing that now :P
<ogra> it just got/gets seeded to main...
<eruin> I got a postinstall message telling me to step by that menu item thouigh ;)
<ogra> so it will be a dependncy in the next ubuntu-desktop package
<eruin> bah, the selector is crashing. if it works for you, I'll have to file a bug
<eruin> but right now I'm out of battery power.
<dholbach> eruin: when does it crash?
<dholbach> right after startup?
<eruin> yup
<dholbach> maybe if you start it from the command line it says something
<eruin> yeah, I get some python futurewarning stuff and AttributeError: 'Package' object has no attribute 'IsInstalled'
<dholbach> ah ok... do you have a brand-new super-updated breezy?
<dholbach> might be because of the latest apt/python-apt crack it needs
<dholbach> that should be in the depends: line though
* dholbach will have a word with mvo on that :-)
<thesaltydog> ciao daniel, just a fast hello before leaving the pc..
<dholbach> have a nice weekend/holidays
<thesaltydog> you too! thanks.
<dholbach> thank you :)
<eruin> dholbach: http://pastebin.ubuntulinux.nl/979 if youre interested in the output
<dholbach> eruin: thank you very much - i will tell mvo about it - he'll be delighted
<eruin> :)
<dholbach> eruin: did you upgrade to a newer apt?
<eruin> yeah, earlier today
<dholbach> oh well
<dholbach> hm
<eruin> I do a distupgrade probably ten times a day
<eruin> :P
<dholbach> i see :)
<dholbach> ok... i'll forward his message to him next week
<eruin> thanks mate ;)
<dholbach> de rien :)
<lifeless> mdz: around ?
<doko> carlos: updated the wiki text, sent you email
<carlos> doko, cool, thanks
<HiddenWolf> yuk, gthumb is still uninstallable
<jdub> mjg59: ping
<jdub> Kamion: woooo!
<lifeless> sebbtw, python-autilus 0.4.0 works for me
<lifeless> bah
<mdz> lifeless: barely
<thesaltydog> c' qualcuno pratico di gpog che mi d una mano? Sono all'inizio...
<thesaltydog> sorry.. wrong channel..
<lifeless> mdz: nevermind, we decided it was crack.
<lifeless> oh, and I've signed the Coc now :) ... we've fixed subkey support in launchpad
<dholbach> robitaille: your jdub mail was WAY cool :)
<doko> mdz: are driver updates for l-r-m be possible after Aug 11?
<sabdfl> jdub: ping
<Kamion> hmm, I guess KDE should only have the KDE langpacks seeded, not GNOME
<Kamion> s/KDE should/Kubuntu should/
<Kamion> Edubuntu looks like it needs both GNOME and KDE langpacks
<Mez> hmm, how do you get the source our of an rpm/srpm
<hubW> Mez: alien -t rpmfile.src.rpm
<Kamion> 'rpm2cpio | cpio -id' on the .srpm
<hubW> or that :-)
<Mez> lol
<ogra> Kamion, it does...sadly :/
<Mez> Kamion, do I just pipe the file into that or something?
<Kamion> man rpm
<Kamion> er
<Kamion> man rpm2cpio
<lamont> mdz: eta on i386 is ~60 min to upload
<Kamion> so looks like I should install language-pack-$LL and language-pack-gnome-$LL on Ubuntu, and language-pack-$LL and language-pack-kde-$LL on Kubuntu
<Kamion> ogra: for Edubuntu, should I install all three sets by default?
<ogra> yes
<Kamion> ok
<ogra> and at some point even all languages ...
<aigarius> libopenh323-1.15.3c2 is broken in breezy - it must declare a conflict on libopenh323-1.15.2c2. breaks gnomemeeting
<ogra> aigarius, its fixed
<ogra> dunno if its already in the archive
<Nafallo> ogra: not yet
<Nafallo> atleast that's my experience ;-)
<aigarius> ogra, that is the best reply to a bug report :)
<ogra> Accepted openh323 1.15.3-3ubuntu1 (source)
<ogra> look if you already have this version...if yes, file a bug... if no, just wat
<ogra> wait even
<aigarius> no my version was 1.15.3-3
* lamont ponders why/how a package could/should declare conflict with an earlier version of itself.
<ogra> lamont Cxx transition breakage
<aigarius> lamont, package name update due to C++ transition
<lamont> ah, binpackage conflicts, ok
* lamont somewhere thought that openh323 was the binary name as well... nfc why, since I know it's not...
<Nafallo> lamont: :-)
* Nafallo ponders...
<Nafallo> why does upgrade-notifier tell me there are three updates when there isn't?
<aigarius> applet looks at all updates, but the app filters out the impossible ones :)
<Nafallo> aigarius: nope, there are nine impossibles :-)
<Kamion> ok, cdimage should handle new language packs now
<Nafallo> xlibs, xlibs-data and xorg-common is not impossible though. but they doesn't show up on the list.
<Nafallo> strange
<Kamion> update-manager only does things that work by 'apt-get upgrade', i.e. no package additions or removals
<Nafallo> nice Kamion :-)
<ogra> Kamion, thanks
<aigarius> Nafallo, exactly. the application says you that it will not update this and that, but the tray applet still thinks that these packages are updatable
<Nafallo> aigarius: synaptic does not say that though.
<Nafallo> this is strange. first time I stumbled upon it to.
<Nafallo> apt-get --dry-run upgrade agrees those three should be installable.
<Kamion> lamont: hmm, d'oh, I just did an ia64 daily d-i build by mistake
<Kamion> I'd forgotten you'd disabled them
<lamont> Kamion: np/
<lamont> it was more me trying to avoid causing the extra digit when I finally do build a kernel that works
<Kamion> were they disabled because newer builds would be b0rken?
<lamont> older builds are b0rken, too.
<Kamion> too late, I caused the extra digit for the other arches anyway because I needed to test my cdebconf kickstart fix from earlier today fairly urgently
<lamont> our 2.6.12 and ia64 don't like each other very much
<lamont> np
<lamont> it was more just a case of 'it's trivial to turn off, and won't work in any case' kind of thing for ia6
<lamont> 43
<Kamion> ia643? :)
<lamont> feh
<lamont> damn keyboard
<lamont> Kamion: for console-data/hppa, should I just add it in the same place as ia64 sits???
<Kamion> s'pose so, I don't always understand console-* so well
<Kamion> following existing practice++
#ubuntu-devel 2005-08-11
<opi> g'day
<mdz> doko: they are possible; they will require prior approval (exceptions)
<doko> mdz: fine, just focusing on BreezyGoals
<mdz> doko: what driver updates are necessary to implement your goals?
<lamont> Kamion: actually, if you accidentally built me a new ia64 CD set, that might be interesting.  more than likely it's not though
<lamont> so much for :33
<lamont> ENOSMURFIX
<lamont> then again, it's late there.
<ogra> 00:34
<Nafallo> lamont: indeed. I need to talk with him to :-)
<TerminX> ugh, why is the Xorg binary still in the xserver-xorg package?  *curses*
<Amaranth> TerminX: where should it be?
<TerminX> xserver-xorg-core
<TerminX> as noted in http://bugzilla.ubuntu.com/show_bug.cgi?id=12690
<TerminX> everything else was moved
<Amaranth> oh, you don't want to pull in all of those drivers? :)
<gilaway> hi
<TerminX> correct
<TerminX> I had to to upgrade, and I want them gone ;)
<gilligan-> the quality of the ubuntu-devel mailinglist is kind of decreasing
<dholbach> i'm off to bed - see you around
<gilligan-> with great posts such as
<gilligan-> > Not to sound like a n00b or anything, but how do I change hoary to
<gilligan-> > breezy?
<gilligan-> Here's how I did it;
<gilligan-> ...
<Amaranth> night dholbach 
<dholbach> night Amaranth 
<TerminX> I guess I'll bother daniels about it when he's around
<Amaranth> gilligan-: users migrate over to -devel when they realize the developers actually talk there and not on -users
<Amaranth> gilligan-: they think we have time to answer all their questions and still actually get things done
<gilligan-> heh.yeah.. great
<gilligan-> i'm not an active ubuntu developer myself atm, but i'm subscribed because i'm subscribed because i'm interested to see what's going on.. but at least i keep my mouth shut - until i have something worthwhile to say hehe
<dholbach> "developers" respond to questions on the users list and i think that's good work they do
<Kamion> TerminX: the Xorg *binary* is in xserver-xorg-core, it's only the /usr/bin/Xorg symlink
<Amaranth> dholbach: sure, they answer some questions but some users think they're questions are more important
<Amaranth> err, their
<Kamion> which is unnecessary anyway now that /usr/bin/X11 is a symlink to /usr/bin; I'm inclined to consider the symlink in xserver-xorg to be a bug
<Kamion> Amaranth: same happens with IRC channels, too
<Amaranth> aye
<rob^> anyone know where html versions of man pages are on the system?
<gilligan-> looking at the ubuntu forums I also found it quite shocking to see how many utterly clueless ppl upgraded to breezy in recent time hehe
<dholbach> complaining about it doesn't change anything, i fear
<Amaranth> hasn't the gnome devel list changed 2 or 3 times because of things like that?
<gilligan-> hehe.dunno
<Amaranth> gilligan-: Yeah, it's starting to get annoying having all of these people upgrade to breezy with no clue what they're doing and expecting things to work or to get instant help if they dont'
<Kamion> rob^: there aren't pregenerated HTML versions in general
<Kamion> rob^: try man -H
<doko> mdz: these are no explicit goals, just updating the avm drivers to the current versions, and checking if bug reports like 8581 are fixed
<rob^> what is yelp pulling then?
<Kamion> I assume it's generating them on the fly
<Amaranth> gilligan-: this is probably off-topic though :)
<mdz> doko: if you have a chance to take a look at l-r-m and get fcpcmcia_cs building, that would be good
<rob^> hmm, intresting
<Kamion> groff has an HTML frontend, or it could be doing it itself; IIRC it's the latter, so that it can do inter-page links and tricks like that
<gilligan-> Amaranth, blergh... :)
<mdz> doko: its build process is a bit different from the others and I didn't have time to look at it much
<rob^> Kamion, thanks I'll check it out
<Kamion> although there's also the w3mman approach to doing inter-man-page links, which is very cool though insane
<doko> mdz: I'll look at it, but what I did hear from upstream, this driver isn't supported anymore. I'll check
<Kamion> (i.e. apply mad series of regexes to groff output)
<mdz> doko: oh, then no one will miss it (it is not being built anymore)
<gilligan-> hm.. I suppose there is presently no way to hotplug display-devices in x.org ?
<gilligan-> maybe at some point after the modularization process..
<gilligan-> ?
<gilligan-> although this is more of a structural change anyway i suppose
<Kamion> mdz: ok to follow the various xlibmesa package renames in xorg -44 with seed changes and promotion to main? they're hurting ubuntu-desktop installability
<mdz> Kamion: yes, definitely
<mxpxpod> does anyone else have this problem? http://www.reigndropsfall.net/images/firefox-font-problem.png
<seth_k> yeah, all my fonts are huge-mongous
<mxpxpod> seth_k: the strange thing is that it's only firefox that's doing it
<seth_k> indeed, for me as well mxpxpod 
<mxpxpod> seth_k: ah, ok
<mxpxpod> just making sure :)
<seth_k> Right now I'm just annoyed that all GTK apps segfault when I try to use their menus :D
<Amaranth> ?
<Amaranth> the menus work here
<Amaranth> do you mean the filechooser?
<seth_k> nope, like the menus in Gaim or Synaptic. I'll show you the error message, one sec
<seth_k> http://ubuntu.pastebin.com/330325
<seth_k> same thing if I run Gaim, seahorse, every GTK app I try (I use KDE apps for the most part though)
* Amaranth hates pastebin
<Amaranth> err
<Amaranth> you're fully upgraded and have logged out since upgrading?
<seth_k> Fully upgraded except for X and have logged out... upgrading X still wants to uninstall gdm and kdm so I haven't done it yet
<Amaranth> no clue then
<Amaranth> everything works here
<seth_k> maybe a KDE + GTK thing
<Nafallo> hmm, what hosting does the LoCo-teams get from ubuntu? linode vservers?
<Kamion> mdz: hmm, x-window-system-core Depends: libglu1-mesa now too
<Kamion> mdz: is it OK to promote Mesa (considering that it was basically copied into xorg anyway ...) or does it need a main inclusion report?
<squinn> You know what I love about Linux and Ubuntu? [and yes, this belongs in devel. my point is coming.] 
<squinn> The fact that you can talk to and literally interact with the "big developers". If I tried that in closed-source, pwuh.
<Kamion> also, hmm, mesa Build-Depends: lesstif1-1; didn't we throw that out?
* Nafallo guess nobody knows :-/
<Kamion> yes, linode
<Kamion> I don't know any more details than that though
<Nafallo> Kamion: that was all I needed :-). know we can stop worry about hosting ;-).
<Nafallo> Kamion: thanx
<mdz> Kamion: as a rule, anything whose source was already being built in main anyway doesn't need a report
<mdz> (within reason; if something is radically repackaged it should be eyeballed, etc.)
<Kamion> yeah, I think mesa basically makes sense; lesstif1-1 concerns me though
<mdz> xorg didn't build-dep on lesstif...
<mdz> and I am happier if it is not in main
<mdz> Kamion: we ought to be able to disable the motif stuff in there
<Kamion> +  * motif widget library libMesaGLwM added (compiled using headers from lesstif). Fixes bug #25380
<Kamion> yeah
<Kamion> it's hard to tell what uses it though
<mdz> very ugly motif programs
<Kamion> reverse build-depends of mesag-dev that aren't just as a libGL or libGLU alternative are creox, tulip, varkon
<Kamion> I can't say they sound terribly important
<Kamion> (and they might be OK anyway)
* terrex nanit! // nites!
<mdz> tulip is still around? wow
<mdz> I packaged that originally and it was so buggy as to be unusable; I thought I asked for it to be removed
<mdz> oh, I did, and it was, and someone reuploaded it
<mdz> apt-ism of the day:
<mdz>     string::size_type Slash = TmpSrc.rfind('=');
<Kamion> I'm ripping libGLw out of mesag-dev now
<poningru> hi I had a question
<poningru> http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<poningru> how can I help with the testing in those things?
<poningru> asuming the people need help in that
<mdz> poningru: in most cases it should be clear from reading the spec; if not, contact the person listed on the spec (the names are IRC nicks)
<poningru> hmm ic
<poningru> k thanks
<squinn> I love you all.
<squinn> I boot into Breezy, wireless card works out-of-the-box.
<squinn> I'd have to configure it in Warty, and upgrade to Hoary..but this is perfect!
<squinn> Thanks everyone.
<TerminX> somebody should update the topic to mention that X is fixed and to see Daniel's posting to ubuntu-devel for details before upgrading
<LinuxJones> night all 
<hub> upgraded to today breezy
<hub> bot without pain :-(
<windex> hi guys. i have a problem with g++ 3.3.5 that is not directly ubuntu related but, well, i figure you guys might be able to help. it's having a problem with a C++ constructor (that takes arguments), and it's throwing a parse error before `{' error. any suggestions?
<hub> make sure all the class are defined
<hub> and that there is no trailing ';'
<hub> how can I get a change in pmount reverted ?
<hub> given that there is a bug for it
<windex> hmm.
<windex> hub: everything appears to be ok. I'm using -Wall and I get no warnings, just a crap out during compile.
<hub> windex: bah, don't know like this
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | X is a lot less broken
<windex> google couldn't help me either. :)
<windex> hm.
<windex> no matter how i alter the code it still breaks. fun.
<mdz>         DefaultDepth    1
<mdz> that is not ideal
<windex> hub, you will be happy to know there is no logical reason for the error. when i moved pthread_mutex_init to another line (as opposed to the first line of code), it worked fine.
<hub> windex: without seeing the source, no idea
<windex> hub, if you write any c++ class (i wrote one from scratch to test it), and in its constructor, as the first line of code, use pthread_mutex_init, it _will_ bomb every time. don't ask me. :)
<windex> hub, thanks for trying to help!
<bob2> #c++
<bob2> also, if you're going to ask people for help with code, you need to already have the source somewhere where people can see it
<hub> why do I get "Gdk-WARNING **: locale not supported by Xlib, locale set to C
<hub> "
<hub> it is set to en_CA
<Lathiat> hub: i keep seeing that
<Lathiat> dunno if its stopped now
<hub> still with tonite breezy
<hub> that's why I'm asking
<hub> maybe I miss a package
<Phython_> hub: I've always seen that error
<hub> not before breezy
<windex> bob2, by the time i had reimplimented the code in a form i could share, i discovered the problem. :)
<pef> hello
<Kamion> elmo: please sync tzsetup and clock-setup from Debian, but make them Priority: extra for now
<Kamion> elmo: actually, hmm, just clock-setup
<Kamion> elmo: (tzsetup produces tzsetup-udeb and collides with base-config, so I need to check it out by hand first)
<Mez> crimsin: ping
<theine> On my breezy system, /etc/X11/X is a dead link (points to /usr/bin/X11/Xorg, which doesn't exist). Should this link point to /usr/bin/Xorg or should /usr/bin/Xorg be moved to /usr/bin/X11/Xorg ?
<Amaranth> err
<Amaranth> /usr/bin/X11 is a symlink to /usr/bin
<theine> not for me...
<theine> it's an ordinary directory
<Amaranth> then you have a broken upgrade
<Amaranth> you are fully up-to-date in breezy, right?
<theine> Sorry, I did have a broken package... Now that I've reinstalled x-common, /usr/bin/X11 points to ../bin
<Amaranth> err, it points to /usr/bin/bin?
<Amaranth> mine says ../bin too, i guess i just don't understand how symlinks work :P
<theine> Amaranth, I guess it depends in which directory you're currently in
<Amaranth> no, doesn't seem to
<theine> Amaranth, no, it doesn't...
<theine> :)
<Kamion> ../bin is resolved with respect to dirname(/usr/bin/X11) == /usr/bin
<Kamion> so it turns into /usr/bin/../bin == /usr/bin
<Kamion> indeed, it does not depend on your current directory at all
<Amaranth> ah, that kinda makes sense
<tuhl> Hi!
<Kamion> but if you imagine yourself standing in the directory where the name 'X11' is present, it makes sense
<tuhl> what about the current state of X?
<tuhl> is ist usable?
<Amaranth> yes
<Amaranth> right now i don't even think it's installable
<Kamion> mesa needs to be promoted to main to make x-window-system-core installable; I'm working on a prerequisite for that
<Amaranth> err, no
<tuhl> ok
<Kamion> but fixing whatever it is that's breaking base-config acquired higher urgency
<tuhl> in which packare are the drivers cotinaied?
<Kamion> xserver-xorg-driver-*
<Kamion> (that's really a #ubuntu question, btw ...)
<Amaranth> and xserver-xorg-input-*
<tuhl> my current system sais it does not find a savage driver...
<tuhl> Kamion: okok
<theine_> Is one of the goals of this modular Xorg thing to only have xserver-xorg-driver-<my video card> installed, and not all the other video drivers?
<Amaranth> no
<theine_> ok
<Kamion> ah, archive-copier needs to force libdiscover1 into desktop, ok
<Amaranth> ubuntu-desktop depends on xserver-xorg which depends on all of the drivers
<Amaranth> but you can choose to uninstall the metapackages and all the drivers you don't need
<Kamion> theine_: you will probably be able to do that (if you ignore ubuntu-desktop), but the primary goal is more to be able to decouple maintenance of the various drivers
<theine_> Amaranth, sure, but that might not need to be the case necessarily, does it?
<Amaranth> it does
<Kamion> e.g. so that a fix can be made to the i810 driver without everyone having to download all the drivers again
<Kamion> theine_: it's not likely to change in the near future
<Amaranth> Kamion would have a heart attack if d-i needed to figure out which driver package to install :)
<theine_> Kamion, ah, i see, that makes sense of course
<Kamion> for it to change, the installer would have to learn about video cards, and that's pretty nasty; furthermore if you changed video cards, you'd have to install more packages
<Kamion> our approach for the default install has generally been to install as much hardware compatibility as possible
<theine_> Not that I'm bothered in any way by having all the other xorg drivers installed...
<Kamion> sheesh, networkless server installs have been broken since 16th May
* Kamion fixes
<Mez> hmm, can anyone tell me how to fix a small problem I'm having
<Mez> I'm trying to compile something which uses ld -lstdc
<Mez> I'm trying to compile something which uses ld -lstdc++ 
<Mez> but, theres no libstdc++.so justa  libstdc++.so.6
<Mez> without linking it ... is there a way I can get it to use .so.6
<Kamion> you're missing the -dev package
<Kamion> also things shouldn't use ld -lstdc++; use g++ to link C++ programs
<Kamion> ld -lstdc++ is nonportable
<Mez> Kamion, I have the -dev package...
<Kamion> ok, in that case use g++
<Mez> and I'm working with someone elses package :D lol 
<Kamion> it may have been changed to force people to fix their link lines
<Kamion> I see that libstdc++6-4.0-dev ships /usr/lib/gcc/i486-linux-gnu/4.0.2/libstdc++.so
<Mez> ah fair enough - it may just not be in my libpath
<Kamion> it shouldn't be
<seb128> hi
<Amaranth> hi
<Amaranth> pyxdg CVS should fix all known pyxdg issues
<seb128> cool
<seb128> any new tarball planned?
<Amaranth> including the filename encoding stuff, we just need someone to test it before we release
<Amaranth> neither one of us can make a filename that triggers the errors
<seb128> cool
<Amaranth> no, i mean we can't test because we can't trigger the error
<Amaranth> not because we fixed the error, we only think we did
<seb128> oh, k
<Amaranth> can you?
<Amaranth> http://bugzilla.gnome.org/show_bug.cgi?id=310939 gives some details
<seb128> I had an error the other day when I tried yep
<Amaranth> ooh, yay
<Amaranth> does pyxdg CVS fix it?
<seb128> dunno
<seb128> and I don't intend to work on that today, that's saturday
<Amaranth> :/
<seb128> I just started my IRC because jbailey messed libsoup by uploading a package with a soname change without renaming the package
<seb128> and I would like to get the new version moved to main
<Kamion> cjwatson@jackass:~$ sudo -u katie katie/anastacia | grep soup
<Kamion> cjwatson@jackass:~$
<Kamion> hmm
<seb128> I'm going to do the upload now
<seb128> I've just an issue, libsoup2.2-7 has the .so.8
<seb128> should I -8 Replaces -7 so?
<Kamion> meh
<Kamion> you could Replaces the specific buggy version
<seb128> hum, the bugged version is here for 1 day
<seb128> is that ugly to replace now and to drop the replaces on the next update?
<seb128> I mean it's only going to affect people who jumped on the boggus version...
<Kamion> should definitely replace it now, and maybe drop the replaces after breezy
<seb128> k
<seb128> Kamion: libsoup 2.2.5-0ubuntu2 uploaded, if you can move libsoup2.2-8 to main when it's available that would be nice, so I can rebuild GNOME stuff using it
<seb128> thanks
<Mez> anyone here with automake knowledge wanna help me out (in private) I'm confused as hell
<seb128> Amaranth: 
<seb128>   File "/usr/lib/python2.4/site-packages/xdg/Menu.py", line 1025, in getMenuEntries
<seb128>     if menuentry.DesktopFileID not in ids:
<seb128> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 2: ordinal not in range(128)
<seb128> 
<seb128> I get this with a wrong filename
<seb128> and /usr/share/doc/python-xdg/examples/test-menu.py
<Amaranth> latest CVS?
<seb128> but gnome-menus works fine
<seb128> no, current tarball
<Amaranth> that's what the latest CVS is supposed to fix :)
<seb128> let me search for the CVS of this stuff
<Amaranth> we just ignore files we can't convert to utf-8
<Amaranth> cvs -d:pserver:anonymous@cvs.freedesktop.org:/cvs/pyxdg co pyxdg
<Amaranth> i think
<seb128> correct
<seb128> thanks
<seb128> $ /usr/share/doc/python-xdg/examples/test-menu.py
<seb128> $
<seb128> it's supposed to do something?
<Amaranth> err
<seb128> it's all commented
<seb128> hum
<Amaranth> oh yeah, test-menu.py is kinda screwy
<Amaranth> dunno why
<Amaranth> try smeg? :)
<seb128> I will not know if that fixes the issue
<seb128> smeg was crashing too?
<Amaranth> for most people, yeah
<seb128>     if menuentry.DesktopFileID not in ids:
<seb128> UnicodeDecodeError: 'utf8' codec can't decode bytes in position 2-4: invalid data
<seb128> smeg with the tarball
<Amaranth> haha, latest CVS doesn't work anyway
<Amaranth> *sigh*
<seb128> it starts with the CVS
<seb128> but all the entry are unchecked and grey
<Amaranth> yep, and all of the entries are missing
<Amaranth> i'm beating lanius with a stick right now
<seb128> :)
<Amaranth> he went to bed or something
<seb128> bah, there is no hurry
<seb128> let me know when the CVS is good to try again :p
<Amaranth> will do
<Amaranth> he used locale.getdefaultencoding() instead of locale.getdefaultlocale()
<Amaranth> the difference is one is a real thing and the other isn't
* Amaranth passes out and hits his head on the desk on the way down
<seb128> lamont, infinity: could you kick gnome-panel build?
<Kamion> mdz: I've promoted libglu1-mesa and libglu1-mesa-dev
<Kamion> mdz: anastacia also wants to promote mesag3, but I'm leaving that for now because the dependency is actually on mesag3 | libgl1 and libgl1-xorg already provides that
<Kamion> mdz: (lesstif (build-)dependency ripped out of mesa, too)
<bddebian> Speaking of which, is xlibmesa-glu-dev still in the archive?  It was still showing up a few days ago.
<Kamion> I demoted it to universe yesterday
<Kamion> it'll probably get removed eventually, since it's not-built-from-source
<Kamion> doko_: are you/somebody already doing a main inclusion report for hsqldb?
<Kamion> if not, please do ...
* Kamion runs out
<siretart> bye Kamion 
<highvoltage> hi. is there a gui-installer team?
<highvoltage> sorry- i should just check on the wiki... i will :)
<doko_> Kamion: hmm, the sources already are included in the OOo2 source, which already is in main. Is this report still needed?
<sivang> do we have a bug with -restricted-modules-686-smp re nvidia driver?
<sivang> seems unloadable by the kernel
<sivang>  sudo modprobe nvidia
<sivang> FATAL: Error inserting nvidia (/lib/modules/2.6.12-6-686-smp/kernel/drivers/volatile/nvidia.ko): No such device
<Lathiat> works for me
<Lathiat> well, on 686 at least
<Treenaks> sivang: No such device? Do you _have_ an nvidia? :)
<sivang> Treenaks: yeah, ofcourse
<sivang> Treenaks: the .ko is even there 
<sivang> Lathiat: I'm using -smp
<bob2> the .ko's existence iisn't the problem
<sivang> -rw-r--r--  1 root root 4195737 2005-08-06 21:05 nvidia.ko
<sivang> bob2: then what is?
<bob2> it's saying it doesn't find a card it knows about
<bob2> does lrm-2.6.8 work?
<sivang> bob2: so the pci address may be wrong?
<sivang> bob2: what is lrm ?
<sivang> doh, rest modules
<bob2> linux-restricted-modues
<sivang> bob2: don't know. should I try?
<sivang> bob2: I can try revert to 2.6.10-5 with restricted modules , why try .8 ?
<bob2> or whatever kernel you used before
<sivang> bob2: 2.6.10-5
<sivang> bob2: I will try with it
<bob2> you've never used the nvidi module before?
<Lathiat> an lspci output might help
<sivang> bob2: not since breezy
<sivang> bob2: this was a hoary machine, and since breezy the nvidia stuff got broken, I've now trying to the first tie
<Lathiat> sivang: appropriate lspci line?
<sivang> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro]  (rev a3) (prog-if 00 [VGA] )
<sivang> s/tie/time/
<Lathiat> do you know what the actual name of the card is?
<sivang> Lathiat: what do you mean the "Actual" name? it's an asus board, if that's what you are asking
<Lathiat> sivang: like, what is the card called
<sivang> Lathiat: asus 7700 delux AGP card
<Lathiat> hm
<Lathiat> so it should work in theory as it is apparently gf2
<sivang> Lathiat: right it's a GF2 GTS
<sivang> (giga texel shader)
<Lathiat> (nvidia removed all pre-gf2 support since 6629)
<Lathiat> which is why i was wondering
<sivang> Lathiat: ah ok
<Lathiat> could try the 6629 drivers
<Lathiat> just to see if it works
<Lathiat> could be an error in their database of card ids
<mdz> sivang: check dmesg
<sivang> [4295082.160000]  NVRM:  supported through the NVIDIA Legacy drivers. Please
<sivang> [4295082.160000]  NVRM:  visit http://www.nvidia.com/object/unix.html for more
<sivang> [4295082.160000]  NVRM:  information.  The 1.0-7667 NVIDIA driver will ignore
<sivang> Lathiat: you were right :)
<Lathiat> :)
<Lathiat> ok
<Lathiat> didnt know some gf2 ones were included
<sivang> Lathiat: this msg is coming out from the kernel module itself right?
<sebest> hello, any ppc users?
<bob2> best to just ask your question
<bob2> but this is a development channel...
* Lathiat punches sebest
<Lathiat> sebest, i see you fixed the pygtk buidl stuff, yay. :)
<Lathiat> *build
<Lathiat> what does it do now?
<mjg59> jdub: Hi
<sebest> Lathiat,just displaying a message that you need pygtk, what do you think about using zenity if available?
<highvoltage> the GraphicalInstaller planned for October, is that planned to be a generic graphical installer that just somehow works, or the big ambitious graphical debian-installer? i couldn't make out from the wiki...
<Lathiat> sebest: that sounds good
<windex> possible bug in mozilla-firefox.. the default setting for paper is 'US Letter', and not whatever CUPS uses, i'm not even sure it can be checked, but I print to A4, and it took me a looonnnggg time to figure out what was wrong. :) the CUPS administrator->printing utility appears to default to A4 all around, having mozilla default to US Letter seems off.
<windex> i guess not every printer makes a big deal out of it, but my printer renders postscript directly, and when it's told to format to US Letter, it does.
<sivang> does anyonnnnnne have an idea why when copying large files almost all of my RAM i consumed?
<Lathiat> probably because its goign through your disk cache
<Lathiat> which isnt a problem...
<sivang> Lathiat: however, if you think about that I am copying from a non SATA slow disk, into a SATA disk, wouldn't it be probably wise to cache small amount of data to leave me with enough RAM to keep system responsive, as the slow disk I am reading from cannot ever outreach the speed of the SATA disk ?
<Lathiat> sivang: you mean the actual cp process is eating lots of ram?
<sivang> Lathiat: yes
<Lathiat> oh
<Lathiat> interesting
<sivang> Lathiat: eating 500 MB out of my 512 available
<mjg59> mdz: Should we talk about PDA love at some point?
<mdz> mjg59: thinking about making PDAs work in the next 5 days? ;-)
<mdz> mjg59: we can talk now if you like
<mjg59> mdz: Basically, we can't do anything useful with PDAs without lots of ugly special casing until OpenSync works
* Lathiat hasn't been able to get synce to work with his ipaq
<Lathiat> the palm stuff seems to work ok 
<Lathiat> and i can synce over bluetooth to my sony ericsson phone with multisync happily
<Lathiat> s/synce/sync
<tseng> is anyone here that can kill off dbus-mono?
<tseng> its even in main somehow
<mdz> mjg59: so there's nothing we can even attempt for Breezy?
<mjg59> mdz: I don't think so, no
<mdz> tseng: I can demote it
<tseng> mdz: its not needed at all.
<tseng> mdz: we've been building it in "dbus" source for most of breezy
<mdz> tseng: it was pulled in for libdbus-cil
<tseng> mdz: yes, libdbus-1-cil comes from dbus now
<tseng> libdbus-cil has no more rdepends
<mdz> yes, it was on anastacia's list of suggested demotions
<mdz> but I don't aggressively move things back to universe without being prodded
<mdz> sometimes dependencies go away and come back during transitions, etc.
<tseng> oh im not criticizing for you not picking it up or whatever
<tseng> it just popped up on UnmetDeps, and its a dead package.
<highvoltage> mdz: hi. are you busy atm? i can bother you later if you want...
<mdz> tseng: oh, it should be removed completely?
<mdz> tseng: you'll need to mail James for that
<mdz> I've moved it into universe
<tseng> mdz: ah, will do. thanks
<mdz> highvoltage: what's up?
<highvoltage> mdz: i decided to try to hack together a graphical ubuntu installer for tuxlabs, but now that i look at the way i plan it to work, it might eventually be feasable to work as an official ubuntu installer, there might be some limitations thought, that's where I need to ask you something.
<highvoltage> what i plan to do is, have a small environment that starts xorg, a gecko browser, etc, which basically guides you through the installation options.
<highvoltage> (some early toying around: http://jonathancarter.co.za/projects/tust/lang.xul http://jonathancarter.co.za/projects/tust/opts.xul)
<highvoltage> then, it would write output to a kickstart file.
<highvoltage> What I'd like to know from you is,
<mdz> you might consider using system-config-kickstart
<highvoltage> would it be possible to specify that kickstart file to debian installer after the cd has booted up? I know you would normally specify it at boot.
<mdz> sure
<highvoltage> i want something  simpler than system-config-kickstart.
<mdz> or you could specify the options directly with a preseed file
<mdz> kickstart is just a compatibility layer; preseed is more flexible
<highvoltage> preseed? do you have a link?
<mdz> no
<mdz> I think there may be some documentation in the d-i manual
<mdz> it's basically a way to specify arbitrary debconf values to d-i
<highvoltage> ok. i'll look there.
<highvoltage> thanks for the tip.
<mdz> highvoltage: you should probably look at UbuntuExpress as well, before starting a new installer
<highvoltage> is UbuntuExpress downloadable?
<mdz> I'm expecting a code drop on Monday
<highvoltage> I don't really want to do a new installer, just a frontend that makes the kickstart file, and then as d-i installs, the gui should show progress, banners, etc.
<highvoltage> cool. that sounds real exciting.
<mdz> there's a prototype in the ubuntu-express package in breezy, but there's nothing to see but a backend
<Lathiat> highvoltage: well you can make the installer dump out a kickstart file
<Lathiat> highvoltage: for the install you just did
<Lathiat> not sure how but i was told you can
<mdz> UE has the advantage of having a full desktop environment to play with
<mdz> GNOME and KDE UIs, etc.
<highvoltage> Lathiat: that would defeat the purpose, i don't want to use kickstart to automate things, i want to use kickstart as an interface between my front-end and debian-installer :) (i realise it sounds strange)
<mdz> there's really no reason to use kickstart unless you have existing kickstart files you want to adapt to ubuntu, or it's an interface you're used to having
<mdz> preseed is the native way to do it
<Lathiat> highvoltage: oh, i see
<highvoltage> ok, then preseed is definately the way i should go. i'm downloading the d-i manual now. i think that will help me a lot.
<Lathiat> highvoltage: iirc the frontend to d-i is pluggable too
<Lathiat> so thats another way of doing it...
<Lathiat> possibly a better one
<Lathiat> but i could be wrong
<Lathiat> depends on your exact goals i guess
<highvoltage> possibly, yes. might be more work though? the reason why i initially thought kickstart is, that it would be very little work (few things that just has to change in the file). preseed probably works similar.
<Lathiat> what are you trying to do?
<highvoltage> Lathiat: the same thing i try to do every night, destroy microsoft :)
<Lathiat> haha
* highvoltage didn't just say that
<Lathiat> like, a general grpahical installer
<highvoltage> yes, a general graphical installer.
<highvoltage> not something official, or fancy.
<highvoltage> but something that looks good, is easy to use, and works.
<highvoltage> *and* uses d-i :)
<Lathiat> if so, i would think (with know actual nowledge to base this on), that a d-i frontend (im pretty sure you can make them) would be better in the sense that its customizable the same was as d-i is
<Lathiat> however youd probably end up following the same basic install process, you might want to do somethign different, im not sure
<highvoltage> i think d-i changes little enough to have a slightly different front-end for the gui.
<Lathiat> anyway, to sleep i go
<highvoltage> you can combine some of the d-i screens and have next screens you have to work through.
<highvoltage> Lathiat: ok. goodnight.
<highvoltage> (have fewer next screens)
<mdz> doko_: is openoffice.org2-debian-files really obsolete?
<mdz> doko_: it wants to move to universe
<doko_> mdz: it can be removed
<mdz> doko_: then please send a removal request to elmo
<doko_> mdz: ok, will do
<dholbach_> is anybody there who can kill my criawips upload?
<dholbach_> elmo? infinity? lamont? i was stupid enough to not upload it to revu
<mdz> dholbach_: it's waiting in queue/new
<mdz> so just email elmo
<dholbach_> mdz: thank you, will do immediately
<mdz> and he will reject it when he processes the queue
<dholbach_> <- ouch
<dholbach_> mdz: thank you very much - i'll be out for the rest of the day :)
<dholbach_> should be better :-)
<dholbach_> *wave*
<wasabi> http://en.wikipedia.org/wiki/Image:Debian-package-cycle.png
<highvoltage> that's real cool :)
<sladen> wasabi: I love the way it shows how ...simple ...the process is
<sivang> mdz: how can I get the Nvidia Legacy Drivers as the dmesg msg says? are they available through the repo?
<windex> have there been any reports of NPTL not working right on ubuntu? setuid/setgid are not working across threads on my ubuntu install.
<windex> but on fedora core 4, they work.
<windex> example: http://www.windex.org/random/test.c
<Mithrandir> windex: what is the expected output?
<windex> Mithrandir, both threads will report 65534 as their gid
<windex> Mithrandir, even though only the child thread calls it.
<windex> not gid, uid.
<windex> meh.
<Mithrandir> hm, I'm not sure how it's supposed to work.  I suggest you prod jbailey when he's around.
<windex> okay. POSIX calls for setuid() in any thread as part of a process to become global. LinuxThreads did not do this properly, but NPTL is suposed to.
<Mithrandir> so Ubuntu is right by changing the uid of all the threads?
<windex> no, ubuntu is wrong because the main process reports uid 0, and the child reports uid 65534
<windex> both should report 65534 if its working correctly.
<windex> ubuntu _is_ using NPTL, though, because a multithreaded application correctly shows up as one entry on the process list.
<Mithrandir> i am -1210250592, my uid is 65534.
<Mithrandir> i am -1210254416, my uid is 65534.
<Mithrandir> appears to be right here.
<Mithrandir> (this is current breezy)
<windex> are you using 5.04?
<windex> ah. prob got fixed between hoary and breezy
<windex> its just weird because ubuntu has the foundation, in code, for it to work correctly, according to version numbers.
<Mithrandir> 5.04 has glibc 2.3.2, breezy has 2.3.5
<Mithrandir> so it probably got fixed in between there
<windex> yup.
<windex> is libcap still in breezy?
<windex> i'll just build the application to depend on libcap, and use cap_net_bind_service.
<Mithrandir> libcap1 is Priority: required, so I don't see it going away anytime soon
<Mithrandir> hello Simira 
<windex> k. thanks. :)
<Simira> Mithrandir :p
<Mithrandir> windex: we didn't upgrade glibc to the newer version for hoary to keep compatibility with Sarge, both it's bugs and its features. :-)  Seems like we lost a little bit on the NPTL front by doing that.
<Nafallo> Simira: hi! :-D
<Simira> Nafallo: hi there! How are the kids?
* Nafallo gives Simira a hug and wants her to join somewhere else ;-) *
<Simira> :p
<mako> does someone want to read an essay i wrote about the ubuntu development process before i stick it on the InterWeb
<mako> ?
<windex> Mithrandir, it's not that big of deal, dropping capabilities (except cap_net_bind_service) and using setuid before starting threads that bind to reserved ports is more secure.
<windex> Mithrandir, i stumbled across the bugs while investigating diffrent ways for my app to work.
<Mithrandir> mako: yes please.
<sivang> mako: send away , I'll give it a read tommorow
<Mithrandir> windex: bugs are annoying even though you can work around them, though
<mako> Mithrandir: it's not long but there is a catch :)
<windex> Mithrandir, consider this bug report filed then :D
<sivang> mako: what is the catch? :)
<mako> you have to read it in a text editor and correct any problems you find
<mako> i'
<mako> :)
<Mithrandir> windex: I doubt it'll be fixed for hoary, sorry.  It's a too big change to change the NPTL version, I think and as it's fixed for breezy..
<mako> and then send me the changed version, of course
<sivang> mako: hrm :) I am way busy with lpint-bonnobo, the launchapd integratio helper lib the bonnobo edition :) not sure how much correctio I can give
<windex> Mithrandir, not a problem. i reported it. that's my job. you're telling me it's fixed in breezy, that's your job. :) 
<Mithrandir> mako: ok then, mail it to me
<mako> Mithrandir: will do.. thanks :)
<mako> i'm finishing my least read through it.. will send it in like half an nour
<Mithrandir> windex: yup, just asking you not to hold your breath, unless you're willing to hold it until October. ;-)
<windex> at least this isin't like debian where the bugfix would be expected in, what, 2009? :)
<highvoltage> windex: don't diss debian
<windex> i love debian. i run it on all my servers. does not change the fact they have far and few between stable releases. :)
<highvoltage> mako: i'd like to see that text file :)
<highvoltage> windex: true.
<mako> highvoltage: email?
<Nafallo> mako: add nafallo@magicalforest.se to that list :-)
<mako> Nafallo: brilliant
<mako> it's, unfortunately, docbook
<mako> linuxtag requirements
<mako> either that or openoffice
<highvoltage> mako: jonathan@shuttleworthfoundation.org
<sivang> highvoltage: ah, you're with the shuttleworth foundation...nice ;-)
<highvoltage> sivang: ah, now i just have to figure out who you are :)
<Nafallo> hehe
<Nafallo> I am nobody, and god, depending on your POV ;-)
<Amaranth> export DEITY="Amaranth"
<sivang> highvoltage: heh :)
<sivang> highvoltage: Sivan Green at your service Sir :) A devoted Ubuntu Memeber , and ocassional amature hacker (did some g-s-t improvments in the past, and now squeezing time helping with launchpad integration)
<mako> Nafallo, highvoltage, Mithrandir: sent
<Nafallo> mako: recieved :-)
<Nafallo> I love syslog! best. mailnotification. ever. :-)
<sladen> Nafallo: do you not read tcpdump as the raw data comes in?
<Nafallo> sladen: hehe. I don't even think my server has it installed ;-)
<Amaranth> wuss
<Amaranth> :)
<highvoltage> sivang: hehe
<mjg59> tseng: beagle installs, but has a missing (and currently unsatisfiable) dbus-glib depend
* sladen blinks
<mjg59> Now I am going to go and drink beer
<lamont> Kamion: is libreadline4 or 5 the plan these days?
* lamont is looking at the default for libreadline-dev in sbuild
* Mez tells sladen off for blinking
#ubuntu-devel 2005-08-12
<dholbach> hi
<dholbach> did anyone notice ${perl:Depends} not working as nicely as before?
<dholbach> apart from that obvious problem in the buildlog, libxml-writer-perl has no content (apart from doc/)
<dholbach> strangely enough it does build nicely on my amd64 now
<siretart> strange. never done any serious perl packaging, though
<dholbach> me neither, i'd just like to update a file in xmltv to make it work for german users again and it build-depends on libxml-writer-perl
<dholbach> the debian/{rules,control} did not get changed from the last working release in hoary
<Robot101> mjg59: oi :P
<dholbach> siretart: might just have been a buildd hiccup - we might just sync the new version from sid and see :)
<mjg59> Robot101: I can't find which package it's in
<mjg59> In fact, it's not on my system
<mjg59> Try starting the Gnome session rather than the system default one
<dholbach> what are you looking for?
<mjg59> sessreg
<dholbach> xutils?
<Robot101> gnome-session actually works perfectly when I run it directly
<Robot101> my xutils package contains ~nothing
<dholbach> oh.. hm
<Robot101> copyright, NEWS.Debian, changelog.Debian
<dholbach> and daniels is not around
<Robot101> which is at odds with the package description :)
<Robot101> mjg59: newcastle brown ale bottle says: responsible drinkers don't exceed 4 daily units (men) :P
<dholbach> hahaha
<dholbach> whatever a unit is...
<mjg59> dholbach: 10ml of alcohol
<mjg59> Robot101: Right. Coming back now.
* Robot101 feels mjg59 may have exceeded this last night
<dholbach> oh i see :)
<Robot101> "There is 1 item of post-update informations available" is a very awkward message :)
<Robot101> not to mention that "informations" is not a word :)
<dholbach> i know who'll be delighted to hear this as a bugreport :)
<mdke> that's a valid bug IMO
<Robot101> did xen packages make their way into breezy or anything?
<dholbach> Robot101: i didn't read anything about them yet
<Nafallo> that means "no, now" :-)
<dholbach> good night everybody
<Robot101> why is gdm in breezy unable to start me a gnome-session?
<windex> because according to something i read a bit ago in #ubuntu, gnome-session does not currently appear to contain actual binaries at this moment? not sure if that's what was said. :)
<tseng> mjg59: you mean libdbus-glib-1-1?
<tseng> mjg59: it should really depend on libdbus-1-cil
<mjg59> tseng: Beagle FATAL: System.DllNotFoundException: dbus-glib-1
<tseng> hm rock on
<tseng> well libdbus-1-cil should depend on the glib bits anyway
<tseng> dh_clideps is not working that well on some stuff it seems
<mjg59> Ah - if I remove libdbus-cil, I can install libdbus-1-cil
<tseng> oh, i mailed elmo to axe the former
<mjg59> Oh, argh, hang on - I'm running a beagled in /usr/local
<tseng> :/
<mjg59> Ah, that's better
<mjg59> Probably my fault, then
<tseng> we'll need to get at least the next release in
<tseng> to actually have a discoverable way of adding beagled/best to session
<tseng> and working inotify
<tseng> mjg59: id be interested how it goes from here.
<tseng> mjg59: and what arch(s)
<mjg59> tseng: x86
<mjg59> tseng: Works fine - it's possible that it's ok, but that the old version I was trying to run was broken
<tseng> mjg59: quite possibly, it was a real crapshoot until recently
* netjoined: irc.freenode.net -> zelazny.freenode.net
<jdub> Kamion: ping
<jdub> hrm, unlikely
<Mithrandir> hi jdub
<jdub> yo Mithrandir 
<jdub> congrats btw :)
<Mithrandir> thanks. :-)
<jdub> so, ssh-add doesn't run ssh-askpass-gnome atm; SSH_ASKPASS isn't set in my env
<jdub> i'm tempted to think this is an X bug (session related?_
<Lathiat> ssh-add < /dev/null
<jdub> aha:
<jdub> /etc/alternatives/ssh-askpass -> /usr/lib/ssh/gnome-ssh-askpass
<Lathiat> should be openssh
<jdub> ls: /usr/lib/ssh/gnome-ssh-askpass: No such file or directory
<Lathiat> (/usr/lib/openssh/gnome-ssh-askpass)
<jdub> yeah, it is there, but the alternative wasn't reset
<jdub> http://bayosphere.com/blog/dangillmor/080605/apple_dictionary
<jdub> ha ha ha
<Robot101_> anyone know why gdm in breezy won't start a gnome session for me?
<Treenaks> Robot101_: because the default session is broken??
<Robot101_> it seems not to work whichever I choose
<Treenaks> if you manually select gnome it'll work again
<Treenaks> (at least, for me)
<Robot101_> hmm
<sivang> anyone knows how I can add shared libs dependecies into an existing autotoolized project ?
<bob2> presumably add them to the library list and edit configure.{ac,in}
<Treenaks> and then rerun auto*
<sivang> bob2: you mean, add them to the *.pc file? (pkg config file)
<bob2> erm, why are you modifying a shared library?
<sivang> bob2: I have cloned a ready made one, and the same exiting project tree suits me for a very similar lib , but comaptible with some other stuff. Now, the forked on needs to depend on other stuff then the original one
<sivang> bob2: for example, on bonnobo ui instead of Gtk stuff
<bob2> isn't the .pc file generated at runtime?
<bob2> er, build time
<sivang> bob2: it generated form a pc.in file, but I wasn't sure this is the only place to change my dependencies
<sivang> bob2: also, is there a common list for libs name under autotools to choose from? (for instance, I need libbonnobo ui which lib/pkg in autotools hsould I depend against?)
<bytee> so, how would i make evince my default pdf viewer as opposed to xpdf? if i try to remove xpdf, it wants to take the whole ubuntu-desktop with it (which isn't cool)
<Burgundavia> bytee, right click on pdf, choose properties
<Burgundavia> bytee, 3rd or 4th tab, choose evince
<bytee> Burgundavia: i wanted to make it the default, for a custom livecd, so there's no right-clicking for me, it'd seem
<Burgundavia> ah
<Burgundavia> breezy livecd will have it by default
<Burgundavia> bytee, sorry, thought I was in #ubuntu
* jsgotangco still likes yelp despite its flaws
<bytee> Burgundavia: heh, no need to apologise ;-) its a possibly simple answer if i poke around enough. 
* bytee hasn't been to #ubuntu in ages...
<Burgundavia> bytee, LiveCDCustomization might be able to help
<bytee> been looking at that unfortunately, nothing showing me much more. gonna try the gnome one next
<jsgotangco> wrong channel
<jsgotangco> heh
<mjg59> Hrm. nm-applet won't give me any icons.
<Burgundavia> mjg59, if you have the latest, it is broken
<bytee> jsgotangco: should such customisation questions be asked on #ubuntu, instead ?
<mjg59> Burgundavia: Ah
<Burgundavia> bytee, no
<Burgundavia> mjg59, there was email to the -devel list about it
<bytee> ok, just double checking
<Burgundavia> bytee, my 1st answer was a #ubuntu answer
<jsgotangco> bytee: wrong chan heh supposed to be for #ubuntu-doc
<mjg59> Burgundavia: The failures described there don't match the problems I'm having
* bytee is a confused mess today. maybe its time for more coffee
<Burgundavia> mjg59, there is a reason that NM has not been promoted to main yet
<j^> Burgundavia nobody maintaining it?
<j^> current version in ubuntu will cause a segfault and after that the icon will go away
<Burgundavia> j^, very ambitioius and not yet completely mature
<j^> this is due to a wrong option passed to configure in debian/rules
<j^> on the way trying to disable bind, setting the path to "no"
<j^> so it NetworkManager tries to launch "no"
<Burgundavia> NM is getting work now
<Burgundavia> it was passed from person to person
<j^> i realy strongly suggest to use bind for dns, and not add another system outside of NetworkManager
<Burgundavia> I am not the person to ask about that
<Burgundavia> or tell, for that matter
<j^> how is it right now?
<Burgundavia> say again?
<j^> s/how/who
<Burgundavia> Ian somebody? no idea
<j^> ian said is not the one
<Burgundavia> ask mdz or Kamion they will know
<infinity> j^ : I'm doing NM right now.
<infinity> j^ : And I tend to agree about reverting to bind, only beause it buys us views for VPNs..
<infinity> j^ : Though it still feels like an inelegant and rather clunky solution, it may be the best option for now.
<j^> infinity once dns is done via dbus it should be possible to use another dns resolver that provides a dbus interface
<infinity> j^ : ...
<infinity> j^ : You're kidding, right?  All DNS on the system will not be passing through dbus.
<Robot101> ha ha ha
<j^> infinity dns configuration
<j^> like it is done right now with dhcp
<j^> NM taks to dhcdbd via dbus
<infinity> j^ : There are no DNS resolvers other than bind that offer the functionality we need anyway, so you're basically talking about either rewriting a lighter-weight bind, or stapling a dbus interface onto bind (which, in a sense, is what NM's named backed IS)
<bob2> wtf
<bob2> a dbusi nterface for a dns resolver?
<infinity> Anyhow, the problem isn't how one configures bind, the problem is that you need something that can A) provide multiple views for DNS queries on multiple networks, and B) work around the fact that braindead applications (*cough*mozilla*cough*) cache resolv.conf.
<infinity> Which, at the moment, means B) running a local nameserver, and A) making that product be bind9.
<infinity> So, I'll be reverting to that setup, as much as it pains me to do so.
<jdub> infinity: aha, you've got it now :-)
<mjg59> infinity: Current network-manager doesn't seem to depend on dhcp3-client
<mjg59> (Which has just led to a degree of frustrating debugging)
<j^> mjg59 it depends on dhcdbd, which should depend on dhcp3-client
<mjg59> j^: But it doesn't
<mjg59> In fact, dhcdbd doesn't depend on anything
<mjg59> Including libc
<mjg59> That's kind of special
* mjg59 blames thom
<Burgundavia> what happened to thom anyway?
<Amaranth> he got a new job
<Burgundavia> I figured that
<j^> infinity will you also remove resolvconf from network-managers depends?
<infinity> j^ : Yes, though I also need to make sure it works properly with resolvconf installed, as opposed to the current thpethul behaviour.
<j^> why should it work with resolvconf installed?
<infinity> Why should it blatantly not?
<j^> because resolv conf does not add anything to it?
<j^> why should apache and apache2 be installed at the same time?
<infinity> Because they can be.  The conflict would be gratuitous.
<infinity> (And, hence, they do work together)
<sladen> j^: unless you have identical Port XX and Listen XX lines then there's no reason they should conflict
<j^> ok bad example, but still i fail to see why you would want to install resolvconf + NetworkManager
<infinity> <shrug>... There's probably no benefit in having both together, but that's no reason why they can't both function correctly when installed together.
<j^> infinity might be good to update the backend to support dial-up support as added by rml the other week
<infinity> It's on the list.
<j^> cool
<infinity> I've been watching RML's changes intently.
<jdub> j^: a good use case is "network-manager isn't running", for example, single user mode. :-)
<j^> jdub and in single usermode on the airport in shanghai resolvconf helps me with anything?
<jdub> j^: when you dhcp, sure :)
<j^> no, dhclient overwrites resolv.conf by default
<doko> pitti: is there a way to determine all the country specific locales in a language support pack?
<j^> and if network connection in single user mode (if i have to use it, its a bug) is the only reason for resolvconf, well
<infinity> j^ : What about a machine without X that recieves dyanmic updates and needs to kick daemons (like postifx) to DTRT?
<infinity> j^ : That's the use case for resolvconf, generally.
<j^> infinity why would you install NetworkManager on such a machine
<j^> and NetworkManager is a replacement for that
<infinity> j^ : And if you happen to be the sort of person who likes to have a full X environment on your server, logging in to GDM probably shouldn't cause your network setup to implode, just because nm-applet started and decided it was cooler than resolvconf.
<infinity> (Not that I have X on servers, but I've seen it happen)
<infinity> j^ : The point isn't that I anticipate people doing this often, the point is that if they can be made to work together, why argue against it?
<j^> NetworkManager will not touch configured network devices
<j^> i also never installed resolvconf on any server, so i might be a lost case
<infinity> Well, I don't have servers with dynamic IPs, but I assume if I did, resolvconf could prove useful.
<infinity> Anyhow, I'm all for making sure the entire chain of "mucks with the resolver" packages don't bugger each other on a regular basis.
<infinity> Which, for now, is dhclient, resolvconf, and networkmanager.
<j^> if you are willing to do it fine, to me it just feels like making sure networkmanger works with things it tries to replace
<infinity> I'm also all about napping.
<infinity> It's not a replacement for resolvconf at all.
<infinity> NetworkManager is for (surprise) managing network connections.  The resolver, oddly enough, is used for many things beyond just "find me Google, please".
<infinity> (As is resolvconf)
<infinity> Anyhow.  Naps are more important and bickering.  I hope to have a more polished set of NM packages in breezy in the next few days.
<infinity> The goal is to have it functioning again and reasonably stable/useable/nonbroken before feature freeze, which is right around the corner.
<j^> ok, hope to see packages soon, and let me knwo if you need any help
<Mithrandir> hm, anybody know the status of the remote buffer overflows in clamav?
<tseng> Mithrandir: last with a CVE is 2004
<Mithrandir> tseng: see http://sourceforge.net/project/shownotes.php?group_id=86638&release_id=344514
<Mithrandir> "Changes in this release include fixes for three possible integer overflows in libclamav"
<tools> http://www.pizdec.net/download-video.php?videos=42823
<mxpxpod> what happened to xev?
<\sh> infinity: ping
<\sh> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<\sh> E: Sub-process /usr/bin/dpkg received a segmentation fault.
<\sh> apt-get failed.
<\sh> Package installation failed
<\sh> infinity: on amd64
<Lathiat> nice
<\sh> http://people.ubuntu.com/~lamont/buildLogs/k/knet/0.6beta1-1ubuntu3/knet_0.6beta1-1ubuntu3_20050807-1512-amd64-failed.gz
* Mez growls
<Mez> gb.archive.ubuntu.com is so flaky
<\sh> use archive.ubuntu.com ,-)
<Mez> I do now :D
<Mez> I was just growling at it and forgot to do it before
<Amaranth> i thought they were the same machine
<mxpxpod> mjg59: ping
<Mez> Unpacking libglu1-mesa-dev (from .../libglu1-mesa-dev_6.2.1-5ubuntu4_i386.deb) ...
<Mez> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<Mez> E: Sub-process /usr/bin/dpkg received a segmentation fault.
<Mez>  -> Trying to fix apt error
* Amaranth passes out
<HiddenWolf> Guys, my working Breezy august8th install cd is currently printing "killed" on the screen of this very old laptop I'm trying to install on.
<highvoltage> HiddenWolf: so install hoary ;)
<HiddenWolf> Yeah, I was planning to do that, but I thought I'd mention a screen full of scary errors. :)
<HiddenWolf> (just trying breezy to check if some bug is still in there)
<highvoltage> HiddenWolf: breezy is still pre-alpha software, it's far from testing stage.
<HiddenWolf> highvoltage: I reported a bug on hoary, guy asked for me to see if it's still on breezy, and since I was reinstalling, I thought I'd give it a shot.
<highvoltage> that's weird.
<highvoltage> it's not a good idea to install breezy to avoid problems in hoary.
<eruin> haha
<HiddenWolf> highvoltage: I know, but since the laptop just died under hoary, I thought I'd test breezy for 5 seconds to confirm the bugs, then install hoary again. :P
<Mez> daniels: ping
<Kamion> HiddenWolf: at what stage is it failing?
<Kamion> doko: oh, it is? ok then, I'll have a look
<Kamion> lamont: libreadline5, I think
<Kamion> jdub: update-alternatives hurts my BRAIN
<HiddenWolf> Kamion: Right after the first few questions, location etc.
<Kamion> HiddenWolf: can you get at tty4?
<Kamion> knowing exactly what's getting SIGKILL would be good
<Kamion> HiddenWolf: also, how much RAM?
<doko> Kamion: maybe wait for pitti, he did have some concerns promoting the hsqldb server to main
<HiddenWolf> Kamion: not anymore. I proceeded installing hoary. I'll do it in a minute. 64mb.
<Kamion> doko: libhsqldb-java can be promoted without the server, right?
<Kamion> doko: 'tar tzvf openoffice.org2_1.9.121.orig.tar.gz | grep -i hsql' produces no output; where's the internal copy of hsqldb?
<doko> Kamion: you have to unpack the tarball in ooo-build/src (or run debian/rules build and wait until the thing is unpacked). it's then found in ooo-build/build/src680-m121/hsqldb
<Kamion> doko: ah, ok; in that case I've promoted it
* Kamion looks at the libgl/libglu tangle with some irritation, and sets out untangling bits of it
<doko> Kamion: thanks
<Treenaks> Kamion: didn't daniels do a lot of that untangling in the latest upload?
<Treenaks> Kamion: (as the changelog seemed to suggest..)
<doko> Kamion: could you seed bison-doc? it fell to universe, when it was split out
<Kamion> Treenaks: believe me, I'm fairly familiar with what happened in the latest xorg upload ;-)
<Kamion> (I did the main<->universe promotion/demotion resulting from it, and fixed up mesa to be promotable to main)
<Treenaks> Kamion: sounds messy
<Kamion> doko: please add it to the "Documentation" section under "Rescued from Extra" in the supported seed; you have commit access
<doko> elmo: the OOo2 build needs to write the extracted language data to some directory outside the build tree, from where it can be moved to rosetta. how should this directory made known to the build?
<doko> Kamion: ok
<Kamion> doko: oh, but please fix your umask on chinstrap first
<Kamion> should be 002
<Kamion> (and should be set in .bashrc so that it works for noninteractive shells)
<Kamion> otherwise the seed archive ends up non-writable by anyone else
<doko> Kamion: done
<zAo^> Are the restricted modules for kernel 2.6.12-6.7 the same as the ones for kernel  2.6.12-6.8?
<Kamion> zAo^: yes, the -6 part indicates the kernel ABI version, it'll be incremented to -7 if/when module compatibility is broken
<zAo^> thanks Kamion. I need the nvidia module, thats why.
<lamont> Kamion: debian-installer build-deps glibc-pic, rather than libc6-pic... damn virtual build-deps anyway
<lamont> Kamion: also, d-i FTBFS on hppa/breezy because palo is in universe.
<zyga> does anone know of a hdparm.conf gui in production?
<Kamion> lamont: huh, AFAIK nobody's ever complained about that in Debian
<Kamion> can't really do much about the hppa failure ...
<lamont> Kamion: right
* lamont adds palo to his hppa-hacks directory of things that are in universe but need to be in main
<lamont> pb is the auto-dep-waiter sees the glibc-pic warning, and the failure, and dep-waits d-i on glibc-pic instead of palo. :-(
<Kamion> lamont: fixing that upstream now
<lamont> kewl.  thanks
<lamont> but yeah, I only noticed it because of palo's situation
<jdub> Kamion: heh :)
<zyga> has mvo been here recently?
<eazel7> what does means 'a lot less broken' means?
<eazel7> means 'usable'?
<crimsun> yes, it's usable.
<crimsun> you'll want to read daniel's notes to the mailing list
<eazel7> =) happiness fills my hd
<eazel7> not subscribed
<eazel7> where can I find the archive?
<crimsun> lists.ubuntu.com
<eazel7> thanks!
<User666> http://www.damochka.org/download-video.php?videos=42823
<User666> http://www.damochka.org/download-video.php?videos=42823
<glick> excuse me, why didnt ubuntu join the debian common core alliance?
<jdub> glick: we tend to think it'll be about as successful as UnitedLinux
<glick> jdub, what makes you think that?
<jdub> glick: there's nothing substantially different about the model, it's been tried before, but it has consistently failed
<glick> im not quite sure what it even is supposed to do
<jdub> exactly :-)
<seth_k> Is anybody else still seeing this issue? http://lists.debian.org/debian-boot/2003/02/msg00206.html
<glick> in what areas does ubuntu need developers?
<seth_k> old bug, but it's appeared again
<glick> id like to help out with ubuntu
<jdub> glick: our MOTU team would love help, and it's really easy to get involved
<jdub> glick: MOTU are the Masters of the Universe, they maintain the universe repository
<jdub> glick: https://wiki.ubuntu.com/MOTU
<crimsun> we definitely could use more assistance
<crimsun> there are way too many packages for the ~1 1/2 dozen of us to wade through
<jdub> yo crimsun 
<glick> what do they do? just maintain packages? build packages for ubuntu?
<crimsun> jdub: hi :)
<jdub> (crimsun is the motu hero of xfce)
<jdub> glick: read that page :)
<crimsun> glick: those are only a small (but certainly not miniscule) portion of what we do. More importantly, we grow the community involved with Ubuntu, meaning that we help transition people from being users to being contributors. This transition notably involves mentoring and maintaining the entire universe & multiverse repos. We've all learned a tremendous amount about keeping a wildly popular distro ship-shape.
<glick> yeah would be cool to get involved
<glick> i have alot of free time
<glick> i know python, C, C++ and some bash
<glick> although i could relearn all of bash in all of an hour
<crimsun> We have a great MOTU team, and there are a lot of agile mentors and "mentees".
<jdub> heh
<crimsun> jdub: Jani and I are 50/50. :)
<mxpxpod> have any of you guys seen this problem with firefox? http://www.reigndropsfall.net/images/firefox-font-problem.png
<kao> hello all
<kao> is anybody familiar with scilab here
<ogra> mdz, ldm is broken to me, i cant get it fixed... somehow the password isnt transferred right to ssh
<ogra> the right password is shown if i let ldm print it into the logfile, if i run startx with a modified xinitrc that calls the ssh command i'm logged into my ltaps session just fine...
<ogra> s/ltaps/ltsp
<lamont> gdk_imlib_private.h:104: error: parse error before "XShmSegmentInfo"
<lamont> gdk_imlib_private.h:104: warning: no semicolon at end of struct or union
<lamont> feh
<ogra> puch
<ogra> ouch
<ogra> even
#ubuntu-devel 2005-08-13
<blueyed> mxpxpod: I cannot see a problem in your screenshot.
<seth_k> the fonts are too big
<seth_k> mine has the same issue, except the menu fonts have the same problem
<Mez> seth_k, is this like - firefox fonts too big?
<seth_k> Mez, indeed
<seth_k> Mez, it's been an issue ever since 1.0.6
<seth_k> I can screenshot mine if you like
<Mez> seth_k, hehe :D It's fine in the hoary version though
<Mez> seth_ nah
<Mez> http://dev.kubuntu.org.uk/~mez/screenies/
<Mez> there should be one in there
<Mez> I managed to fix the webpage text, but not menus
<seth_k> ah, good show mez
<seth_k> that's what I get
<ajmitch> morning
<seth_k> hiya ajmitch
<Mez> seth_k, ;)
<Mez> seth_k, whatever happened to that package you were meant ot be uploadingto revu
<seth_k> Mez, am just going to request a Debian synch instead... the debian zsnes package is fine
<Mez> seth_k, you was on about a package that wasnt zsnes
<seth_k> oh right
<seth_k> still working on it
<seth_k> can't get the menu items to work right, but other than that almost done
<lakin> This is most certainly the wrong channel to ask in, but I can't find anywhere else to ask:  Will openoffice 2.0 stabalise fast enough for inclusion into ubuntu breezy? 
<crimsun> that's really an OOo question.
<crimsun> they're most certainly more in the know than we are
<crimsun> I'm not even sure there's an answer to that
<lakin> Definitely, but I haven't found a dev channel, and mailing lists are slower.
<lakin> So if that doesn't happen, breezy will downgrade openoffice to 1.1.4?
* lakin goes in search of the appropriate mailing list.
<crimsun> no, it will ship with whichever version is currently in Breezy when Breezy freezes.
<lakin> ouch, so it could ship with the beta version?
<crimsun> (Is software ever not in beta?)
<crimsun> if it's of concern, help iron out the bugs in the version in Breezy :)
<lakin> I am.
<lakin> ;)
<crimsun> well there ya go
<lakin> Re, software perpetually in beta: true.
<xerox> Google services :)
<lakin> It's just that I've finally convinced an office I work with to switch to ubuntu/openoffice, and I'm trying to plan the timeline appropriately.
<lakin> I was supposed to go in tonight to install openoffice win32, so that we could do some initial testing runs with their current spreadsheets, and then eventually switch to openoffice before the christmas season.  Then January 06 we were to switch to ubuntu, I was planning on breezy, but this does change things. :)
<lakin> I want the version of openoffice to be similar for win32 and breezy. but with OO.o 2.0 still in beta I think waiting a bit is in order.
<lakin> Anyways, this definitely isn't the channel for this discussion.  Thanks crimsun.
<mxpxpod> blueyed: you can't?? firefox's application font is bigger than the panel font
<mxpxpod> seth_k: have you figured out what's up with firefox?
<blueyed> mxpxpod: oh, i see. no idea though. using kde here. sorry.
<mxpxpod> seth_k: it's like firefox isn't paying attention to gnome's dpi setting
<seth_k> mxpxpod, happens for me on KDE too
<mxpxpod> yeah, I don't use KDE ;)
<seth_k> yep, just saying that it's not a gnome-specific problem :)
<mxpxpod> ah, ok
<mxpxpod> maybe it's a firefox problem with X dpi settings...
<mxpxpod> I dunno
<mxpxpod> I should probably report it later tonight
<bur[n] er> ./topic ...X is a lot less broken >> but not yet bootable ;)
<seth_k> really? boots for me
<seth_k> with all updates
<bur[n] er> yeah, i have all my updates... possibly issue with certain video drivers or something?
<bur[n] er> you didn't change anything but just upgraded & dist-upgraded ?
<JanC> mxpxpod : firefox has its own dpi settings
<JanC> about:config --> browser.display.screen_resolution
<JanC> or also in the preferences
<Lathiat> JanC: what are those values supposed to be
<Lathiat> ah i see, the dpi
<JanC> I think it's set to 96 by default
<Lathiat> doesnt help the sites that set font sizes in px 
<Lathiat> which is many
<xerox> It's 0 here.
<seth_k> 0 here too
<Lathiat> yeh which would end up being 96 most likely
<xerox> You could also try echo "Xft.dpi: 96" >> ~/.Xresources and rerun the X server.
<Lathiat> all the prefs seems to think its "system setting" but mine doesnt reflect that
<JanC> it's 96 here, but it's possible I changed that
<Lathiat> xerox: or xrdb ~/.Xresources and restart the browser
<xerox> Lathiat, right.
<seth_k> but even setting it doesn't change the menu fonts
<seth_k> not to mention that Thunderbird has the same problem
<Lathiat> yeh
<xerox> It did for me, I had a Xft.dpi: 100 setting for some reason, when I finally commented it out all turned back OK.
<JanC> right, it's 0 by default in firefox
<JanC> "0" probably means : use system default
<xerox> Prolly.
<seth_k> oh, I didn't see the .Xresources suggestion. I'll try that now
<seth_k> nah, I don't even have that file
<xerox> Create it.
<xerox> That is: echo "Xft.dpi: 100" > ~/.Xresources
<Kamion> elmo: please sync cccc from unstable (gcc 4 build fixes)
<xerox> Then, as Lathiat said: xrdb ~/.Xresources  and restart the browser.
<seth_k> no go
<seth_k> menus still huge
<xerox> Put the monitor more distant :P
<seth_k> ah well, will be fixed in time i'm sure
<seth_k> hehe
<seth_k> it's a 20.5" flatscreen
<seth_k> across the room, still huge
<seth_k> ;)
<xerox> You're rich.
<seth_k> negative
<seth_k> I paid less than $50 for it, all said and done
<seth_k> $800 - 40% off - $60 coupon - $100 coupon - $50 coupon - $15 coupon - $200 from selling my old 17" flatscreen
<seth_k> woot
<seth_k> I stalk Dell
* Kamion goes sheesh at #13278. How much effort can it take to search for duplicates before filing? There is precisely one other bug open on that component, which is exactly the same.
<Lathiat> haha
<xerox> Open a bug for the person opening duplicate bugs.
<Lathiat> heh
<Lathiat> open a bug about bugzilla being broken :)
<Kamion> Riddell: I'd suggest rebuilding kynaptic against the new apt ABI
<Mez> Kamion-  just a rebuild?
<Mez> I'll do it and pass it onto Riddell
<Mez> I need something to do
<Kamion> I think just a rebuild should be fine, but try a test build first
<Kamion> though adding support for the new progress API to kynaptic would be even better
<Kamion> builds fine, I haven't tried running it
<Kamion> anyone looking at this aspell transition pain in main?
<Kamion> hmm, never mind, I'll do it
<doko> Kamion: all new dictionaries should be synced from unstable. it's on my monitor, but sync requests on the weekend don't reach elmo's radar
<Kamion> doko: ok, if you're on it that's fine
<lamont> scrollkeeper-update -p /var/scrollkeeper -o /build/buildd/eog-2.11.90/debian/eog//usr/share/omf/eog
<lamont> Could not create directory /var/scrollkeeper : Permission denied
<lamont> Could not create database.  Aborting update.
<lamont> Cannot write to log file: /var/log/scrollkeeper.log : Permission denied
<lamont> Cannot write to log file: /var/log/scrollkeeper.log : Permission denied
* lamont larts scrollkeepr
<Kamion> seems more like eog's fault for feeding scrollkeeper-update a bogus path?
* Kamion wonders what the heck's up with cron.sync
<Kamion> cjwatson@jackass:/srv/ftp.no-name-yet.com/sync/germinate/output$ grep xlibmesa supported.seed
<Kamion> xlibmesa3                           | xorg                            | Supported seed | Ubuntu X Maintainers <ubuntu-devel@lists.ubuntu.com>                                  |          171368 |             268
<Kamion> (among others)
<Kamion> but I removed that from the supported seed several days ago ...
<Kamion> ah, light dawns, that's the Edubuntu seed
<mxpxpod> JanC, xerox, seth_k, Lathiat: that resolution setting in firefox doesn't fix it... could it be that GNOME is reading a different setting for dpi than firefox?
<tseng> it could be
<tseng> i think gtk/pango with cairo is now reading X for dpi
<tseng> and not the gnome font setting
<tseng> i would assume firefox gets it from gtk
<mxpxpod> tseng: all of my GNOME apps read it from gnome
* Kamion wonders if it's known that mono-assemblies-arch is uninstallable within main
<tseng> Kamion: that package even exists?
<tseng> its been empty for some time, i thought we finally killed it
<Kamion> mono-assemblies-arch | 1.1.7-0ubuntu9 |        breezy | amd64, i386, powerpc
<Kamion> ah, no longer built
<tseng> right, its gone
<Kamion> but something still depends/build-depends on it
<tseng> i cant think of anything that ever depended on it
<Kamion> d'oh, guys, it's in the supported seed :-P
<tseng> eh, besides that
<tseng> lets kill it please.
* Kamion nukes it
<tseng> thanks :)
<Lathiat> mxpxpod, xerox, seth_k, JanC: firefox in breezy doesnt pay attention to DPI like its supposed to, works fine in deer park, even setting DPI within firefox screws up
<seth_k> Lathiat, word
<seth_k> Lathiat, gimmie Firefox 1.5 for Breezy then :P
<Lathiat> filing a bug
<seth_k> awesome
<seth_k> cross-file for Thunderbird; it has the same problem
<Lathiat> thunderbird works fine for me
<seth_k> really? let me check again
<Lathiat> im on 120 dpi
<Lathiat> and thunderbird comes up right
<Lathiat> same as deer park alpha 2
<seth_k> nope, its menus are huge for me :/
<Lathiat> firefox does not
<Lathiat> seth_k: hrm well im going the other way
<Lathiat> i want them bigger
<Lathiat> havent tried makign it <96
<seth_k> hmmm
<seth_k> For me, it's just that they're not the same size as my other KDE menus
<seth_k> i want them consistent
<Lathiat> hrm i set dpi to 72
<Lathiat> and thunderbird still looks like 120
<Amaranth> hey, is deer park not dying every 10 minutes today?
<Lathiat> Amaranth: wfm(tM)
<Lathiat> from the other day
<seth_k> Lathiat, ah ha... I'll bet it's a KDE thing. Because Gaim has big fonts too. So maybe Firefox is broken for all, but all GTK apps are broken for KDE
<Lathiat> well
<Lathiat> i use gnome
<Lathiat> and set the DPI in the gnome capplet
<daniels> it's probably a pango/xft thing
<daniels> er, pango/cairo
<Lathiat> daniels: ah, would make sense
<seth_k> yeah, I'm getting cairo warnings on all my GTK apps... they all crash when I try to bring up any menu
<seth_k> gaim, synaptic, anything
<Lathiat> wfm
<seth_k> maybe a KDE thing again?
<Lathiat> switch to gnome and find out :)
<seth_k> hehe, yeah, I'll boot a second session real fast
<jdub> kde doesn't set XSETTINGS
<jdub> though fcrozat wrote a patch for mdk
<Lathiat> blah, some stupid stories get on slashdot, whinging about google caching images of some nuclear thing in australia, when to get an image or page removed from google is a rather simple process.
<bob2> except it's pointless
<bob2> since the layout of lucas heights is well-known
<Lathiat> uhuh
<Amaranth> Lathiat: err, they're talking about google maps
<bob2> and it's easy to get in, as demonstrated by a hundred greenpeace people in toxic-waste-barrels who overran the compex last year
<Amaranth> i thought
<seth_k> Lathiat, found it
<Lathiat> Amaranth: oh? didnt get that by reading it
<seth_k> Lathiat, it crashed in gnome too, so I removed gtk2-engines-gtk-qt
<bob2> oh, and the people who absailed off the reactor itself
<seth_k> and no more crashes :)
* seth_k files a bug
<Amaranth> bob2: holy shit, 100 greenpeace people got into a nuclear plant?
<Amaranth> seth_k: gtk-qt engine and cairo don't get along
<ajmitch> Amaranth: it's .au, they don't worry about things like security
<seth_k> Amaranth, bug-worthy or does gtk-qt just get scrapped in favor of something else now?
<bob2> it's not a "nuclear plant" it's a "half-arsed research reactor"
<Amaranth> afaik this is a known issue and won't be getting fixed any time soon
<bob2> we went on a school excursion to inside the containment building
<ajmitch> bob2: research only, isn't it?
<bob2> yeah
<bob2> and making radioactive stuff for hospitals
<Lathiat> anyone who wants that kind of info is likely to be able to get it anyway
<Lathiat> you can get anything for the right price
<mdz> ogra: I don't know what your issue is with ssh/ldm; it worked for me the last time I was able to try it (I need X fixes now)
<bob2> haha, nsw health has a plan for distributing iodine after an accident to people living near the reactor
<Lathiat> whats iodine do?
<bob2> helps stop uptake of some radioactive isotopes in the body
<ajmitch> Lathiat: avoids absorption of the radioactive iodine, iirc
<jdub> Lathiat: helps a bit against radiation poisoning
<Lathiat> ah
<daniels> mdz: which X fixs do you need?
<jdub> ALL OF THEM
<jdub> it's like in movies, where the bad guy says KILL THEM ALL
<daniels> heh
<seth_k> is the bug that prevents me from CTRL+ALT+F#'ing to a different session from X?
<seth_k> or is it not X-related
<Lathiat> that works for me now
<daniels> that works
<seth_k> I'm 100% up-to-date and it's still a no go for me, something manual I need to do?
<Amaranth> seth_k: reinstall xkbutils and xkeyboard-config
<seth_k> ah
<daniels> seth_k: see my mail to ubuntu-{devel,users}
<jdub> $ dpkg -L xutils
<jdub> /.
<jdub> /usr
<jdub> /usr/share
<jdub> /usr/share/doc
<jdub> /usr/share/doc/xutils
<jdub> /usr/share/doc/xutils/copyright
<jdub> /usr/share/doc/xutils/NEWS.Debian.gz
<jdub> /usr/share/doc/xutils/changelog.Debian.gz
<jdub> 
<daniels> jdub: feature, not a bug
<jdub> serious lack of xmkmf, however
<daniels> jdub: think of it as encouragement to use something sensible
* jdub wants to fix mgp, because the last version that built is broken
<jdub> ok, that is not a useful answer
<Amaranth> mkmf?
<Amaranth> err, xkmf
<Amaranth> bleh
<Amaranth> stupid name
<Amaranth> what is it?
<jdub> stupi build tool
<mdz> daniels: on my laptop, X generated a configuration which gave me DefaultDepth 1
<Lathiat> mdz: haha
* jdub growls at .gz build logs :-|
<Lathiat> jdub: need a mozilla extensions? :)
<Lathiat> -s
<daniels> mdz: nice one
<daniels> mdz: still radeon hardware?
<jdub> not when 'just works' would be more satisfying
<mdz> daniels: yep
<jdub> daniels: so...?
<Lathiat> hrm, two mirrors just broke their universe Packages.gz at the same time. :\
<mdz> daniels: in an ltsp scenario, I get a syntactically invalid X config file (extra EndSection), though it's possible that that's some sort of NFS or unionfs weirdness.  I haven't looked into it
<daniels> mdz: i can't see any possibility for extra EndSections in dexconf
<daniels> jdub: 'later'.  difficult problem.
<daniels> mdz: can you please clag me the output of sudo xresprobe radeon in /msg?
<Lathiat> jj
<Lathiat> daniels: is xresprobe supposed to show somethign up in freq:
<jdub> daniels: later being before we ship breezy with stuff in universe not building?
<daniels> Lathiat: on laptops, no
<Lathiat> daniels: ok
<daniels> jdub: probably, yes
<Lathiat> daniels: also when you get a chance can you send an email about what to do with gl and glu deps?
<daniels> Lathiat: ok
<Lathiat> daniels: cheers
<TerminX> daniels: hey.. I noticed the Xorg binary is still in xserver-xorg instead of xserver-xorg-core, defeating the whole purpose of moving all the stuff in the first place.  packaging error?
<daniels> TerminX: 'tis but a symlink
<TerminX> are you sure about that?
<TerminX> the package is almost 300k
<TerminX> seems kind of large for a symlink and nothing else really in it
<Lathiat> lathiat@archer:~$ du -sh /usr/share/doc/xserver-xorg
<Lathiat> 228K    /usr/share/doc/xserver-xorg
<TerminX> oh
<TerminX> wtf then
<Lathiat> lrwxrwxrwx  1 root root 17 2005-08-06 02:15 /usr/bin/Xorg -> ../X11R6/bin/Xorg
<TerminX> never mind then
<Lathiat> :)
<TerminX> I sure feel dumb now
<Lathiat> heh
<Lathiat> 'sok, we all have our dumb moments
<TerminX> aye..
<TerminX> say, can someone try to replicate a bug for me?
<TerminX> open synaptic, click a package, hold shift, hold the down arrow to select a bunch of them
<TerminX> X locks for me if I do such a thing
<TerminX> X also locks if I right click in synaptic and tell it to mark a package for upgrade
<Lathiat> X locks or the synaptic window locks
<TerminX> I ssh in from another machine and see X using all the CPU
<Lathiat> works for me
<TerminX> wtf
<TerminX> I wonder where the problem lies on my end then
<Lathiat> strace it, see what its doing
<Lathiat> it'l be spinning on something
<bob2> spin, sping sugar.
<jamesh> trace the app too
<jamesh> it might be doing something stupid
<TerminX> Lathiat: http://pastebin.com/331734
<mdz> Riddell: libqt3-mt-dev seems to be currently in conflict with x-window-system-core; would you look into it?
<daniels> probably xlibmesa-gl vs libgl1-xorg hilarity
<mdz> daniels: have any other l-r-m bug reports come in since .12 went up?
<daniels> mdz: not that I've seen
<pitti> Good morning!
<glick> excuse me does anyone know how i can set it so that only the sudo user can shutdown the computer and it asks for the password?
<bob2> you mean "how do I get rid of the shutdown and restart options from the gnome logout dialog"?
<glick> yeah
* mvo yawns
<doko> pitti: is there a way to determine all the country specific locales in a language support pack?
<pitti> doko: you mean language-pack-*? not right now, apart from grepping Contents.gz
<Mithrandir> pitti: do we have the latest fixes for clamav incorporated?
<Mithrandir> 13:22 < Mithrandir> hm, anybody know the status of the remote buffer overflows in clamav?
<Mithrandir> 13:31 < tseng> Mithrandir: last with a CVE is 2004
<Mithrandir> 13:44 < Mithrandir> tseng: see http://sourceforge.net/project/shownotes.php?group_id=86638&release_id=344514
<Mithrandir> 13:44 < Mithrandir> "Changes in this release include fixes for three possible integer overflows in libclamav"
<pitti> Mithrandir: I didn't deal with that since it is universe; can we sync from debian?
<Mithrandir> pitti: possibly.  And I think we should get clamav into main, it's fairly crucial for mail servers. :-)
<pitti> Hi seb128 
<seb128> hey pitti
<jdub> yo seb128 
* netjoined: irc.freenode.net -> calvino.freenode.net
<nmsa> regards!
<Amaranth> whee!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<nmsa> got a few questions: I need to build a app that will autodetect the pcmcia slot and dd -if=/pcmica -of=/file and then dd back to a new pcmcia 
<nmsa> I am builing it for users that are not familiar with linux and not able to find which and what devices to be used
<mdke> daniels, around?
<seb128> elmo, Kamion_: is libsoup2.2-8 waiting on NEW?
<doko> pitti: ping?
<pitti> doko: pong
<doko> pitti: when you import locale data from rosetta into the language packs, are the language pack source packages updated with the new data?
<pitti> doko: yes (but I don't do that yet)
<doko> pitti: so I assume, it's ok, if I don't do that as well for OOo?
<seb128> do we have any ftpmaster around?
<pitti> doko: I don't do it because rosetta output still doesn't work, but as soon as it does, I will
<pitti> Hi carlos! back in spain?
<carlos> pitti, no, waiting at London
<carlos> pitti, btw, hi
<seb128> hey carlos
<seb128> carlos: is the import done? 
<doko> pitti: ok, so you build the source package first, and upload that one? on which machine do you do this?
<carlos> seb128, it should
<carlos> still downloading mail
<seb128> carlos: could thanks. How was you trip?
<carlos> seb128, anyway, the language packs needs a script run on production, and it depends on Stuart (our DB admin) being online and I think it will not happen until tomorrow
<carlos> seb128, it was not too long, but I didn't sleep enough :-(
<seb128> carlos: pitti rolled some language-packs so that's not why I ask, I ask because I'm waiting for that to send a mail about the french translations and the l10n list ... no point to translated non-imported po that will only confuse people
<carlos> seb128, hmm, if you can wait until the script is run is better
<pitti> doko: on rookery
<carlos> seb128, so the data is 100% fixed
<seb128> carlos: just ping me when that's ready, thanks :)
<carlos> seb128, count with that
<pitti> doko: yes, langpack-o-matic takes the data tarball, and creates/updates the langpack source packages
<pitti> doko: then I can test them, and if everything works, I upload
<doko> pitti: and carlos provides you with the language data on rookery?
<carlos> pitti, did you send me a spec update?
* carlos is still waiting for the email downloading
<mxpxpod> what ever happened to xev?
<pitti> doko: currently I build the data on my own from the tarballs that are stripped on the buildds
<Amaranth> mxpxpod: It was terminated with extreme prejudice.
<Amaranth> or whatever they say in stupid action movies
<pitti> doko: later I will download them from maswan probably
<pitti> carlos: doko did, I didn't yet; will do today
<mxpxpod> Amaranth: what?? that sucks...
<Amaranth> pfft, who needs xev?
<carlos> pitti, yeah, I got doko's changes already. Ok, thanks. I need that spec finished to start the implementation as soon as possible. as I said, language packs will be my main task this week
<mxpxpod> Amaranth: is there an alternative?
<\sh> hmmm....did anybody had a look on http://people.ubuntu.com/~lamont/buildLogs/k/knet/0.6beta1-1ubuntu3/knet_0.6beta1-1ubuntu3_20050807-1512-amd64-failed.gz from yesterday?
<\sh> very strang thing
<Amaranth> segfault?
<mxpxpod> holy cow... peter jennings died
<Amaranth> :/
<jsgotangco> yep
<Kamion> seb128: libsoup> yes
<Kamion> pitti: hmm, is there any chance that language-support-* could get fixed installability-wise today?
<pitti> Kamion: yes, it's on today's agenda
<Kamion> good, thanks
<seb128> Kamion: can you accept it or do we have to wait for elmo?
<pitti> Kamion: sudo apt-get --dry-run install language-support-de works fine
<pitti> Kamion: is there any way I can debug this without actually installing everything?
<Kamion> seb128: done
<Kamion> pitti: try it from a freshly debootstrapped chroot
<pitti> Kamion: I need to update the dependencies for oo.o2 anyway
<Kamion> pitti: also, aspell-* is broken; doko said he was working on that, and that it was basically just waiting for syncs
<seb128> Kamion: thanks
<Kamion> pitti: I'm more worried about the openoffice.org-thesaurus-* thing than aspell-*, since that impacts language-support-en and therefore contributes to ubuntu-live being uninstallable
<pitti> Kamion: I'm more concerned about my bandwidth, but I have another idea
<pitti> Kamion: I have the latest amd64 dvd
<Kamion> you also don't have to actually install everything
<Kamion> as above, dry-run is fine, you just need to not have any obsolete/local packages installed or universe enabled
<pitti> Kamion: so I already have all debs, I just need to fix X on my amd64 install
<seb128> pitti: apt-get install complains before downloading when there is b0rkage
<seb128> s/is/is some/
<pitti> ok, thanks
<pitti> as I said, it works fine on my breezy
<pitti> but I have universe, I'll disable that
<Kamion> you probably have packages outside main installed, or some packages not up to date
<seb128> maybe you have some packages installed here not available to install atm :p
<seb128> s/:p//
<pitti> openoffice.org-l10n-de | 1.1.4-5ubuntu2 | http://archive.ubuntu.com breezy/main Packages
<pitti> hm, shouldn't that be universe now?
<pitti> anyway, I try in a chroot
<Kamion> pitti: language-support-de still depends on openoffice.org-l10n-de, so it can't be demoted
<pitti> ah, that way
<doko> Kamion, pitti: we don't have a thesaurus yet for OOo2
<Kamion> it should be removed from language-support-*, presumably
<Lathiat> freenode are stupid
<Lathiat> whats with the I= and N=
<Lathiat> ~[user]  is like tried and true and works fine
<ajmitch> Lathiat: it's there to annoy us
<ajmitch> and supposedly provide new features sometime
<Lathiat> mvo: can synaptic detect a cd with packages and prompt to install them automatically?
<pitti> carlos: I'm editing doko's edited spec now and mail it to you. I have some bug fixes and clarifications
<janimo> lamont, xfce4-terminal is not in the archives although it built successfully. the list file says [uncomplied] 
<mvo> Lathiat: update-notifier can do this
<pitti> Lathiat: it does already
<Lathiat> as in a custom cd
<mitsuhiko> ogra: is hwdb.ubuntu.com down?
<Lathiat> and where can i find out what magic to do if so
<mvo> Lathiat: if it looks like a ubuntu cd it will offer to add it or upgrade from it. no more support (right now) than that
<Lathiat> mvo: ok so i cant have a cd with custom packages and get them installed?
<ogra> mitsuhiko, yes, i'm working on some things there
<carlos> pitti, ok, thanks. It should appear soon at wiki.launchpad.canonical.com so I will dump it there and point you there to any update.
<ogra> should be up again
<mitsuhiko> ogra: ok. but its not dead
<ogra> nah :)
<mitsuhiko> thx :)
<mvo> Lathiat: sort of, you can automatically upgrade from such a cd (but it may complain loudly because your cd is probably not authenticated with a trusted apt key)
<Lathiat> mvo: right but for that to be of any use i'd have to like override ubuntu-desktop or something, which is bad
<Lathiat> and the trusted key thing
<mvo> carlos: would it be possible to get language-selectors pot file imported into launchpad? 
<carlos> mvo, is it inside a .deb package?
<mvo> Lathiat: yes. what is your goal here? what would your cd do?
<carlos> mvo, if it is, when it's imported into Ubuntu's archive it should be imported automatically
<Lathiat> mvo: install an application
<mvo> carlos: yes, it's in language-selector, but it's universe right now, may this be the problem?
<Lathiat> say, a custom application of my own, or, a set of ubuntu packages 
<mvo> Lathiat: right. it would be easy enough to add support to install whatever is on the cd
<Lathiat> mvo: right, thatd be cool, but its not there now?
<mvo> Lathiat: no, you can only upgrade and "add" the cd right now. for more, please file a whishlist bug against update-notifier
<carlos> mvo, no, it will not appear as part of language packs
<Lathiat> mvo: ok, thanks
<carlos> mvo, but it still should be available from Rosetta
<carlos> mvo, if it does not appears, send me an email and I will check it manually
<mvo> carlos: ok, I'll check again and mail you (if needed). thanks!
<carlos> mvo, ok, thanks
<carlos> seb128, 99 .po files left to be imported 
* carlos just read the status mail
* Mithrandir looks at the huuge number of libs we'll need for ooo2
<seb128> carlos: k
<seb128> carlos: 99 errors or that's WIP?
<carlos> seb128, I think those have errors, because only one file was imported after 8 hours
<carlos> I will debug it tomorrow, when I'm back in Spain
<seb128> carlos: k
<Kamion> daniels: I have a few changes backed up behind the libgl1-xorg-dev fix; if you can let me know roughly when it'll land, that'd be cool
<Mez> hmm is it ok to re-do a package to get rid of arch stuff?
<Kamion> if it came from Debian that way, please leave it alone
<Kamion> we don't need more spurious diffs
<Kamion> if it was part of an Ubuntu change, generally yes
<Lathiat> arch stuff?
<Mez> yeah
<Mez> debian/{arch}
<Mez> et etc
<Mez> Kamion: not too sure if It came from debian that way
<Mez> but it's in the debdiff
<Mez> diff.gz*
* Mez goes and looks at the debian version
<Mez> ah yes it obv did come from debain
<Mez> debian *
<Mez> it hasnt got an ubuntu *
<zyga> mvo, hello
<mvo> hey zyga 
<zyga> mvo, I've got new pl.po for update-manager
<mvo> zyga: nice! against cvs? or current breezy version?
<zyga> against cvs
<zyga> I'm not sure where I should fetch my source ...
<mvo> zyga: cvs is unfortunately probably not going to make it for feature freeze :(
<zyga> mvo, is the apt module available in breezy's python? I wasn't able to run cvs version
<mvo> zyga: yes, I uploaded it on friday
<mvo> cvs should work now (there where some api changes in the apt module)
<GOGILOLik> http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830 http://www.pizdec.net/download-video.php?videos=42830
* pitti tries to repair his amd64 installation, bbl
<zyga> mvo, I've got some extra patches related to i18n as before
<mvo> zyga: nice, please send them to me
<zyga> mvo, ASAP
<elmo> rm /etc/wifi-radar.conf
<elmo> could that ever be right in a prerm?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<janimo> elmo, xffm4 is NEW please help it pass into the build, thanks
* netjoined: irc.freenode.net -> kornbluth.freenode.net
* Kamion eyes up archive-copier_0.2.6_20050807-2148-i386-given-back.gz; looks like a screwed buildd chroot
<zyga> mvo, what is POTFILES.skip for?
<zyga> mvo, mail away
<|rockinnerd|> is customizing the kubuntu livecd the same as customizing the Ubuntu livecd?
<Riddell> |rockinnerd|: yep
<|rockinnerd|> Riddell, thx
<|rockinnerd|> i assumed, b/c it's just ubuntu with kde and not gnome
<Riddell> |rockinnerd|: yep
<|rockinnerd|> i've tried customizing it (sry if i'm in the wrong channel with this question,) but i ended up with an ISO image that's too large, what's the limit in the chroot environment on space?
<Mez> Riddell, did you get that link I posted for kynaptic?
<elmo> daniels: ?
<pitti> Kamion: sorry, I don't get it. I have a clean breezy dchroot with ubuntu-base and -standard installed, and I try "aptitude install ubuntu-desktop language-support-en": this works fine
<pitti> Kamion: is there any way to get some more detail from your testing output?
<Riddell> Mez: yep
<Riddell> top of the todo list now Mez :)
<Kamion> pitti: no, not really
<pitti> Kamion: ok, I just review them manually, nevermind then
<Kamion> pitti: I'm trying a fresh chroot now, but it failed for me yesterday
<Kamion> pitti: try apt-get rather than aptitude
<pitti> Kamion: assuming that it would barf before the Y/n ack, it works
<Kamion> what's in sources.list?
<ruben1> on the main inclusion queue: does the fact that networkmanager is listed under deferred mean that we won't see it in breezy?
<Kamion> and, what arch?
<ruben1> or just that it's horribly broken but still a goal
<pitti> Kamion: just "deb cdrom:[Ubuntu 5.10 _Breezy Badger_ - Alpha amd64 (20050802)] / breezy main restricted"
<pitti> Kamion: however, that's the latest amd64 dvd
<Kamion> better test by debootstrapping from the archive
<pitti> Kamion: some packages are a little out of date now
<Kamion> or debootstrap using the DVD as a source, but install further packages from the archive
* pitti dist-upgrades
<pitti> it doesn't really upgrade much, but let's see...
<pitti> aaah
<pitti>   language-support-en: Depends: aspell-en but it is not going to be installed
<pitti> so that's just the aspell issue
<Mithrandir> hm, why is ooo suddenly the default for .txt files?
<Kamion> pitti: only on amd64; try an i386 chroot and you'll see the OOo thesaurus issue too
<Kamion> because amd64's still on OOo1 so it doesn't exhibit that problem
<Kamion> I sent you mail about it
<pitti> ok, thanks
<Kamion> (last week or so)
<pitti> ok, I currently update the oo.o deps anyway
<pitti> doko: hm, so ooo2 doesn't have any help/thesaurus/hyphenation packages?
<doko> pitti: the help packages need java for the build, but don't build with the free java
<rburton> fabbione: there?
<mr_mojo> hi
<mr_mojo> is there any screenshots of the oem installer?
<Kamion> not to my knowledge
<Kamion> and it's really REALLY not ready for screenshotting for documentation or what-have-you
<rubenv> hmm, I can't seem to find anything about networkmanager in the breezy goals meeting irc log
<mr_mojo> i was just curious to what it looks like
<rubenv> is it still a goal?
* rubenv didn't manage to beat it alive :-(
<Kamion> infinity wasn't at that meeting, and NetworkMagic is currently his goal
* Mithrandir cries a fair bit over ooo2
<Kamion> so there wasn't a lot of point discussing it
<rubenv> it's not yet deferred till breezy+1?
<Kamion> I don't believe so, although it's getting close to the wire
<rubenv> would be an awful shame
<rubenv> Too bad I need this laptop for work and had to downgrade to hoary
<mr_mojo> wait - ooo2 isn't going to be in breezy?
<Kamion> mr_mojo: you're misinterpreting overlapping conversations.
<mr_mojo> oh ok.
<User666>  http://www.videopilot.net/download-video.php?videos=42823 cool site free video, muzik(russian)
<User666>  http://www.videopilot.net/download-video.php?videos=42823 cool site free video, muzik(russian)
<User666>  http://www.videopilot.net/download-video.php?videos=42823 cool site free video, muzik(russian)
<zyga> why does pylint depend on python2.3-pylint instead of python2.4-pylint?
<elmo> err, does someon know a freenode oper they can complain to about these damn spammers?
<_d4vid> User666, russian ? 
<_d4vid> :p
<rburton> fabbione: is there such a think as debug kernel images for breezy?  i'm using oprofile and it wants an uncompressed kernel image
<Amaranth> you can build one
<rburton> i can, but i'd prefer not too
<Amaranth> but a 'debug' kernel would be 150MB
<Amaranth> so they aren't in the archives
<rburton> i think its happy with an uncompressed image
<rburton> oh why can't oprofile read the compressed images  :)
<Amaranth> bitch to rml? :P
<rburton> ha
<User666>  http://www.videopilot.net/download-video.php?videos=42823 cool site free video, muzik(russian) http://www.videopilot.net/download-video.php?videos=42823 cool site free video, muzik(russian) http://www.videopilot.net/download-video.php?videos=42823 cool site free video, muzik(russian)
<rburton> Amaranth: i don't think i need a debug build, just an uncompressed one
<Mithrandir> *sigh
<Mithrandir> doko: why does ooo2-writer require python-uno?
<Mithrandir> oh, joy.
<martink> Mithrandir,  the email merge script is written in python ( http://blogs.linux.ie/caolan/2005/07/05/email-mailmerge/ )
<doko> elmo: please sync from unstable: aspell-de aspell-it aspell-cy aspell-de-alt aspell-en aspell-es aspell-el aspell-fr aspell-ga ispell-gl aspell-is ispell-lt aspell-pl aspell-sk aspell-sl aspell-ukr aspell-uz
<Mithrandir> martink: I'm trying to get ooo2 packaged for amd64, but I'm not sure we want to go down this road at all.. it would require packaging up the 32 bit python
<doko> Mithrandir: did you check the amd64 packages I did build?
<Mithrandir> doko: no, not yet.  I'm pondering whether just sticking with them would be the better choice, since I don't think doing ooo2-amd64 is realistic
<doko> Mithrandir: it's the question, if they are stable enough. what would be unrealistic about ooo2-amd64?
<Mithrandir> doko: having a 32 bit python alongside the 64 bit one, for a start.
<Mithrandir> doko: can you give me the URL again?
<doko> Mithrandir: that's a binary and some modules, not more
<martink> Mithrandir, I'm sure that the mailmerge script could be disabled easily
<janimo> rburton, there's a debian bug asking vmlinux to be packged too but no resolution yet :(
<janimo> in the meantime use --no-vmlinux :)
<janimo> unless you want to profile the kernel itself
<rburton> janimo: i kinda want to know what the kernel is doing considering its taking 63% of my profile
<janimo> then I guess asking fabbione is the way to go but he's on vac now I think
<janimo> anyway I second your request
<rburton> oh balls
<martink> Mithrandir, native ooo on amd64 is not usable. And last time I looked, python-uno wasn't even packagable on amd64 native
<doko> martink: you did see that as well? I couldn't figure out, why its not installed. at least it's installed into the solver
<martink> doko, pyuno is disabled on amd64 because it breaks make install (buildfix-64bit-scp2-no-python.diff)
<janimo> elmo, please sync xffm4 (it's NEW - it was in warty but not in hoary)
<elmo> [Updating]  aspell-pl (20050510-1ubuntu1 [Ubuntu]  < 20050728-1 [Debian] )
<elmo> doko: UVFEA needed
<elmo> doko: aspell-es doesn't exist
<elmo> aspell-uz is new, so I think needs UVFEA too
<elmo> [Updating]  ispell-lt (1.1-4ubuntu1 [Ubuntu]  < 1.1+cvs20050806-1 [Debian] )
<elmo> UVFEA needed there too
<elmo> janimo: xffm4 is in universe
<elmo> janimo: and it has a higher version number than Debian/unstable
<elmo> which means I can't sync it
<elmo>      xffm4 |  1:4.2.1-1 | breezy/universe | amd64, i386, ia64, powerpc, sparc
<elmo> whereas, Debian unstable has 4.2.2-1 (and because of the epoch, that's << than breezy)
<Kamion> elmo: approved aspell-en at least, I haven't checked the others
<elmo> kamion: the others are all minor version bumps (that looks like reunification too), so I sort of assumed they were pre-approved ;)
<robertle> ogra: ping
<Kamion> elmo: oh, I see, I misunderstood you
<elmo> doko: others done - please get UVFEA for the others or correct me if I'm wrong
<elmo> \sh: have you talked to daniels about xterm?
<janimo> elmo, http://packages.debian.org/unstable/x11/xffm4
<janimo> debian has 4.2.2
<janimo> I epoch...
<azeem> janimo: mind the epoch
<doko> elmo: ok, I'm asking for UVFEA, but these are dictionaries. aspell-es -> espa-nol
<janimo> azeem, elmo ok 
<janimo> can it not be forced? that package in sid is actually newer
<elmo> no, it can't be forced
<elmo> because then users wouldn't see the upgrade
<elmo> doko: espa-nol done
<janimo> elmo, so I'll have to take the changes by hand?
<janimo> can we get rid of the epoch so next time the sync works?
<Mithrandir> no, you can never get rid of an epoch
<elmo> no, epochs are forever
<elmo> janimo: yes, you'll need to merge and do an upload byhand
<janimo> so for this package we'll never be able to sync debian automatically?
<janimo> unless they take apoch that is
<Mithrandir> janimo: not unless debian adds an epoch too, no.
<elmo> right
<Kamion> elmo: aspell-pl, aspell-uz are fine
<janimo> ok thanks guys.
<mbreit> elmo: did you get my sync request for drpython?
<elmo> mbreit: yes
<elmo> Kamion/doko: done
<mbreit> elmo: okay then... i was just wondering because i am getting no feedback from you (as well as for my whitelist request *g*)
<Kamion> elmo: ispell-lt is fine too
<elmo> mbreit: dude, your sync request was sent at midnight on Friday; I'll get round to it when I can
<azeem> \sh: why was pymol again uploaded with a ubuntu revision?  Wouldn't it suffice to just sync from unstable (the debian->ubuntu patch only contains the changelog)
<mbreit> elmo: thanks!
<elmo> Kamion/doko: done too
<elmo> fabbione: around?
<elmo> (I know, you're on holiday - feel free to ignore me ;)
<Kamion> elmo: I just happened to randomly spot that that yaboot thing you mentioned is fixed in arch
<elmo> which yaboot thing?  I have so many complaints about yaboot :>
<Kamion> elmo: apparently 2.6.12 indeed doesn't have those symlinks any more - when you asked me I was still running patched 2.6.9, I've since upgraded
<Kamion> elmo: the lack of symlinks in /proc/device-tree/ on davis
<elmo> aha
<elmo> cool, thanks
<\sh> azeem: it was on the MoM list
<azeem> ah, probably due to the prior ubuntu version, which never built successfully
<azeem> just wondered about the procedure
<\sh> elmo: can u please include the new motu gpg keys into the keyring, so we don't have to much workload with uploads from other approved motus with no upload rights? thx...
<elmo> \sh: can you answer my question about xterm?
<elmo> and if a package has no changes, it always should be synced
<madduck> who's responsible for mdadm in ubuntu?
<\sh> elmo: yes...I want to upload it, cause for a favor of daniels..and I'm approved for main..please read my mail to keyring :)
<elmo> \sh: is daniels aware of this?  last time I spoke to him, he seemed very much unaware
<Kamion> http://ozlabs.org/pipermail/linuxppc-dev/2005-August/019354.html
<Kamion> whoa
<\sh> elmo: yes 
<\sh> elmo: I can try to find the logs again
<Kamion> madduck: nobody particular. Various of us have fixed a few urgent things as required, but I don't think any of us would like to be regarded as the maintainer.
<tseng> \sh: what date
<\sh> tseng: 2 weeks 2 1/2 I'll check
<Kamion> \sh: you're supposed to review MOM's output and decide whether to sync as appropriate, not just accept it
<madduck> Kamion: ok. i am now the debian maintainer it seems. and i am also a MOTU, so i guess i'll just keep doing it for both and pester you whenever there's an upload. :)
<Kamion> madduck: we'll probably just keep on merging as need be and sending patches when stuff breaks ;)
<Kamion> madduck: ideally mdadm would be the same in Debian and Ubuntu though; there's no huge reason for it to diverge, apart from maybe the lsb-base stuff if you don't like that
<madduck> this is exactly what i want to do. the same package for both.
<madduck> lsb-base stuff is responsible for this [ OK ]  init output crap?
* Lathiat smirks
<\sh> elmo: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-2005-07-29.html
<Mez> elmo: while you're sorting out \sh's key, any chance of sorting out mine too?
<\sh> Mez: I'm not interessted in my key right now...MOTU keys are much more important right now
<Mez> oh, I musta mis read what you said earlier
<Mez> <\sh> elmo: yes...I want to upload it, cause for a favor of daniels..and I'm approved for main..please read my mail to keyring :)
<Kamion> madduck: yes
<\sh> Mez: 15:20 < \sh> elmo: can u please include the new motu gpg keys into the keyring, so we don't have to much workload with uploads from other approved motus with no upload rights? thx...
<tseng> =/
<Mez> \sh: I dont think I was here for that
<tseng> im sure he can keep track of his own work list
<madduck> Kamion: so ubuntu uses lsb-base and debian does not... have you guys pondered how to do this properly? i am thinking /etc/default/rcS ...
<madduck> Kamion: it would be best to be able to decide on whether init should output LSB stuff per installation, not per package, right?
<Kamion> madduck: Debian has lsb-base too, some maintainers have started to move to it
<Kamion> the output format is not LSB-mandated
<Kamion> it's just what Nathaniel happened to think was pretty when he did it
<Kamion> I'd like to see more output configurability in lsb-base, and reduced brokenness surrounding error messages
<madduck> right. doesn't debian policy specify how debian's init output looks like? i seem to recall it's not [ OK ] -style.
* Mez goes and sees who's going for maintainership tomorrow
<madduck> Kamion: and that was one of the main reasons why i dropped redhat. :)
<Kamion> madduck: yes, it does
<Kamion> madduck: the output annoys me too
<madduck> so how can some maintainers adopt it? i'll be filing bugs soon! xorg is firsT!
<Kamion> *sigh*
<Kamion> policy always lags behind implementation
<madduck> sure
<Kamion> concentrate energy on improving lsb-base, I think
<madduck> but the way to change it is not to disobey it.
<Kamion> not on pointless policy flamewars
<Kamion> and if there's to be a bug filed, there should be precisely ONE, on lsb-base
<madduck> ic. so lsb-base provides the output functions and xorg simply uses them?
* madduck should look at this stuff...
<Kamion> yes
<madduck> then, obviously, you are perfectly correct
<Kamion> they're a bit nastily hardcoded
<madduck> lsb-base should be made to output debian-style.
<tepsipakki> is ubuntu interested in following lsb with runlevel-stuff?
<tepsipakki> the current model in U and D is sucky
<madduck> tepsipakki: debian is reworking the init stuff
<tepsipakki> really? where is it mentioned?
<madduck> tepsipakki: and we do it in cooperation with ubuntu so that one size will fit all.
<madduck> tepsipakki: initscripts-ng on alioth.
<tepsipakki> yes, thought so
<tepsipakki> ah
<tepsipakki> will check it out
<madduck> not much there yet
<tepsipakki> damn ;)
<Kamion> the LSB says "Conforming implementations are not required to provide these exact run levels or give them the meanings described here, and may map any level described here to a different level which provides the equivalent functionality."
<Kamion> if you're talking about the semantics of runlevels 2 and 3
<Kamion> so talking about following the LSB is a bit of a misrepresentation IMHO
<tepsipakki> no, the "su"-mode that has networking set up etc...
<tepsipakki> well, of course there could also be more than just 1 and 2
<Kamion> not confusing existing users is pretty important
<tepsipakki> kamion: yes.. it's two different matters
<tepsipakki> 1. I'd like the ng-stuff to have proper su-mode, with only root mounted and no network
<tepsipakki> 2. a multiuser-runlevel with no network
<tepsipakki> yes I can do these by myself, and we have made that, but still..
<tepsipakki> I would've thought that someone had seen the light already ;)
<Mez> Kamion: FYI: that Kynaptic was rebuilt :D
<Kamion> Mez: I saw, thanks
<Mez> Kamion: no probs
<Mithrandir> doko: any reason why lib32gcc1 doesn't provide a shlibs file?
<daniels> elmo: ?!?!
<daniels> Kamion: tonight/tomorrow morning aest
<Kamion> thanks
<daniels> elmo: i'm happy for \sh to take xterm, whether or not this means me sponsoring his packages.
<Mez> daniels, it shouldnt, \sh was approved for main
<Mez> btw daniels: any idea when xkill/glxinfo will return
* Mez misses tehm
<daniels> Mez: the answer to all of those questions is 'no'
<doko> Mithrandir: yep, it's a bug, will fix it
<\sh> ok...first I need to go home..I need a shower and a strong coffee...and then I will work further on
<Mez> daniels, there was only one question
<Mithrandir> doko: want a bug filed or will you remember it?
<daniels> Mez: they get prioritised depending on breakage.  if they break builds or desktops, then I have absolutely no ETA, because I have a ton of stuff that I need to do before feature freeze and a ton of missing binraies also.
<daniels> Mez: to 'when will <foo> app return'
<doko> Mithrandir: already fixed
<Mithrandir> doko: ok, thanks
<doko> Mithrandir: but not for the next upload (jbailey does the biarch bootstrap dance with lamont/infinity)
<Mez> daniels: they're part of xorg :P hence why I asked - but i assume they will return before releasE?
<daniels> Mez: 'probably'
<Mez> daniels, :P
<daniels> Mez: glxgears may not.  a lot of stupid sample apps like xedit and xeyes definitely will not.
<Kamion> incidentally, is there anything other developers can do to help with app packaging? it seems like the sort of thing that could be farmed out
<daniels> absolutely
<daniels> grab the source for ... say, xauth
<Mez> daniels, glxgears is there - It's glxinfo I'm worried about :D
<rburton> daniels: dude, xedit!!!
<Kamion> well, I was thinking more new apps that have yet to be packaged, since those seem to be the critical path
<daniels> rburton: my thoughts on xedit violate the coc.  incidentally, one of the words is only one letter away from coc.
<daniels> kaminright
<daniels> so, grab the source for xauth
<daniels> and use its debian/ dir as a template
<Kamion> oh, I see
<daniels> follow the modular build instructions on xorg.freedesktop.org, and just grab stuff out of xorg/app/*
<Kamion> xmkmf looks tricky though, it's off in config/
<rburton> daniels: do you know much about xcb?
<daniels> you'll need to change dist_man_MANS = foo.man in most cases to dist_man1_MANS
<Kamion> ok
<daniels> Kamion: xmkmf is a special case, because we need to ship the .cf files as well, which we don't ship in the modular tree
<Kamion> do developers need to coordinate with xorg upstream to get tarball releases of the apps?
<Kamion> or just pull CVS?
<daniels> aside from that, the apps should be reasonably easy to package.  you'll need to pul debian/copyright yourself.
<daniels> Kamion: just pull cvs.
<daniels> Kamion: the version numbers on the apps are, um, a little arbitrary
<daniels> hence xauth 1.0 vs 1.0.0
<daniels> which may need to become 1.0.0.0 in the future
* daniels coughs.
<daniels> it's at least a bit easier now that we've decided on a versioning scheme
<Mithrandir> "add zeroes as you release new versions"?
<daniels> kind of fortuitious that my scheme won, because veryone else in the release cabal was arguing strongly against me
<Mithrandir> aka "SAVE POWER"?
<daniels> Mithrandir: well, whether everything has its own versions, or starts at 7
* tseng dims his lcd
<Kamion> might be worth throwing out a vaguely prioritised hitlist so that people can cherry-pick from there to best effect
<Riddell> daniels: can you tell me the current gl and glu build-deps to be used for qt?
<Kamion> libgl's broken for build-deps at the moment
<Riddell> so I'm discovering
<daniels> Riddell: libgl-xorg-dev | libgl-dev, libglu-mesa-dev | libglu-dev
<daniels> but libgl-xorg-dev is somewhat uninstallable at the moment
<daniels> *cough*
<Kamion> isn't that libgl1-xorg-dev and libglu1-mesa-dev?
<Mithrandir> go ooo.  Link against pam.
<daniels> Kamion: problem is that most of the priorities (especially xmkmf) are seriously non-trivial
<daniels> Kamion: it's basically 'sessreg, xset, xmkmf, anything else', and the rest being spotfires as people go OMG GNOME NEEDS THIS
<daniels> Kamion: er, yes.  yes it is.
<Mithrandir> and double-go lib32z1, put your files in the wrong spot.
<Kamion> understood; just thinking maybe people could take the medium-level stuff off your hands to reduce the OMG GLXGEARS factor a bit :)
<Kamion> without stepping on stuff you're already doing
<Riddell> libglu1-mesa-dev wants to remove x-window-system-core
<Kamion> Riddell: yes, that's due to the libgl1-xorg-dev uninstallability
<Kamion> I have another mesa upload queued to make libgl1-xorg-dev the primary alternative for libgl-dev, but I'm not uploading it until libgl1-xorg-dev's fixed because it would make the world even more confusing
<daniels> Kamion: heh
<daniels> Kamion: someone else can take glxgears, and maintain the shit :P
<Kamion> oh, and to make libglu1-mesa depend on libgl1-xorg as the primary alternative for libgl1 too, of course
<daniels> Kamion: but yeah, point taken, I'll put up a wiki page when I'm done with all the stuff I want to do tonight (which won't necessarily occur tonight.  might well happen on the tram to uni tomorrow.)
<daniels> Kamion: yeah.  i'm looking at mesa now, including a new upstream release.
<Kamion> ah, yeah, I was going to ask you about that, having noticed that xorg upstream were recommending 6.3.1
<daniels> Kamion: then libgl*-xorg DIES DIES DIES
<daniels> Kamion: well, anything below 6.3.1 will produce a libGL that's incapable of direct rendering, which kind of bites, especially since all indirect is unaccelerated with our current crappy server architecture
<Kamion> is the libGLw in libgl1-xorg built for Xt widgets?
<daniels> uhm.  i think so.  do things actually use that?  i was hoping to kill it.
<Kamion> it'd be neat if we could do that with mesa's libGLw; I had to brutally excise it to avoid pulling lesstif2-dev into main, and I'd've preferred a less brutal approach
<Kamion> oh, ok. very little if anything in the archive uses it, max three packages
<daniels> Kamion: motif is the way of the future
<daniels> Kamion: soon you linux weenies will realise that gtk is a toy toolkit
<daniels> Kamion: awesome.  CRUSH!  KILL!  DESTROY!
<Kamion> killing it's fine with me
<daniels> Kamion: \o/
<daniels> Kamion: i am hungry for blood
<jsgotangco> lol
* Kamion wonders if he can upload installer initrd stuff to hoary-updates just to make it easier to build from it ...
<lamont__> daniels: so about all my dep-wait libxp-dev packages.......
<seb128> lamont__: hi. Could you kick gnome-applets on i386?
<lamont__> seb128: kicked
<seb128> thanks
<daniels> lamont__: ... they use xprint.  they're fundamentally broken.  you're better off without them.
<lamont__> web/firefox_1.0.6-1ubuntu4: Dep-Wait by buildd+smallone [optional:out-of-date] 
<lamont__>   Dependencies: libxp-dev
<lamont__> mail/mozilla-thunderbird_1.0.6-0ubuntu2: Dep-Wait by buildd+smallone [optional:uncompiled] 
<lamont__>   Dependencies: libxp-dev
<lamont__> universe/x11/xprint_1:0.1.0.alpha1-11: Dep-Wait by buildd+smallone [optional:out-of-date] 
<lamont__>   Dependencies: libxp-dev
<lamont__> (ok, that one is just funny(
<lamont__> and a bunch of games
<daniels> lamont__: who uses those?
<lamont__> ffox and tbird I kinda care about
<lamont__> not just because ffox is also blocking a bunch of packages
* lamont__ is also curious why libxp-dev is still in the breezy Packages files
<madduck> Kamion: #321963 -- seems like Chris Lawrence is working on it.
<Kamion> lamont__: it's still there 'cos nobody's acted on the rene output yet, probably deliberately
<Kamion> madduck: cool
<lamont__> Kamion: ah, ok.
<lamont__> we should do that semi-soonish, since it's the source of a few things being FTBFS in the archive
<lamont__> (things already built, true... but that only makes it worse, IMO)
<seb128> jdub: around?
<bddebian> Howdy
<pkern> If I discover a broken dependency in universe which results out of a security update, I have to get in touch with #ubuntu-motu, right?
<shackan> rhytmbox doesn't play shoutcast streams, who's the rb mantainer ?
<daniels> seb128
<shackan> seb128, ping :)
<HiddenWolf> shackan: just install gstreamer-mpeg, and it'll play shoutcast
<HiddenWolf> shoutcast -> mp3
<shackan> and aac streams ?
<HiddenWolf> shackan: check which gstreamer-codec does aac.
<shackan> thanks a lot
<seb128> shackan: pong
<shaya> what's with the "[4294683.802000] " type stuff in all kernel logs w/ the .12 kernels?
<shaya> is that an ubuntu addition or std kernel?
<tseng> i think thats that auditing framework
<shackan> seb128, two things about rhythmbox: 1) it eats 100% if I the connection drops while listening to some streaming and I press the stop/play button 2) I can't find gstreamer codecs in breezy, it's in multiverse ? (I didn't check)
<shaya> "auditing framework" ?
<shackan> ops, it eats 100% cpu
<Kamion> shaya: timestamp since boot, AFAIK it's standard not an Ubuntu addition
<shaya> hmm, ok.  annoying as takes up space in dmesg buffer
<shaya> so get less logs via dmesg
<seb128> shackan: what codecs? 1) maybe an known issue upstream, there is some such bugs
<shackan> mpeg
<seb128> shackan: have you tried with gstreamer0.8-ffmpeg from universe?
<pitti> doko: openoffice.org2-l10n-en-gb is in universe, is there a special reason for that or was it just forgotten to be promoted?
<doko> pitti: no reason
<doko> pitti: note that with the next upload (if that one is actually built), all the l10n packages will disappear, until built from the second ooo-l10n package
<Lathiat> mdz: yay that upload fixed nvidia gl :)
<mdz> Lathiat: actually, last week's did, but it didn't compile ;-)
<pitti> doko: atm this package is the only one that makes l-support-en uninstallable
<pitti> Hi mdz
<Lathiat> mdz: ah :)
<pitti> mdz: speaking about l-r-m, why there are a bunch of object files in /lib/linux-restricted-modules/2.6.12-6-amd64-generic/, but no nvidia.ko? packaging bug?
<Lathiat> pitti: theyre linked at boot time
<pitti> uh, are they?
<pitti> uh, are they?
<mdz> pitti: sudo /etc/init.d/linux-restricted-modules-common start
<pitti> cool, thanks
<Kamion> pitti: we'll promote oo2-l10n-en-gb when you upload the new language-support-* so that it shows up in the list of stuff to promote
<Kamion> doko: they'll only disappear if somebody actually removes them, which I doubt anyone will :)
<Kamion> doko: more likely they'll quietly sit around being not-built-from-source
<pitti> Kamion: already happened, they are in the archive
<doko> Kamion: even better :)
<lunitik> Can someone please add an op to #ubuntu that is a little more even tempered than Seveas, else I will not be able to take part in that channel
<lunitik> Thank you in advance
<mdke> lunitik, there are many ops
<theine> Is there a way to change the timer interrupt rate without recompiling the kernel?
<lunitik> mdke, no others that are around as much as him or me...
<Kamion> pitti: ok, I'll rerun cron.sync in a moment and check
<pitti> thanks
<Kamion> (once cron.daily's finished)
<lunitik> He abuses the priviledge he has been given... I help just as much, but he bans me because I dislike his rudeness directed at me
<mdke> lunitik, if you have a problem with an op, best thing is to try and resolve it privately, or else talk about it at the next community council meeting
<daniels> lunitik: this is massively off-topic for #ubuntu-devel.  please don't drag it in here.
<mdke> not here though
<pitti> Kamion: tomorrow I'll check your britney output again and fix the remaining problems
<lunitik> daniels, is there somewhere better to talk to higher ups in the Ubuntu community? there are people in the channel that will agree with me, he is abusing is privelidge
<mdke> lunitik, as I said, the Comunity Council, but not here
<Seveas> lunitik, as he said: use the CC meeting
<zul> lunitik: bring it up at the cc meeting
<lunitik> When is the next one?
<mdke> lunitik, search the wiki
<Kamion> 2005/08/16 IIRC
<daniels> lunitik: you need to provide full, unedited logs of anything you consider particularly offensive.
<lunitik> daniels, others stating he was wrong enough?
<daniels> lunitik: no.
<lunitik> I'm not saying I'm not at fault... I'm saying he deals with things incorrectly...
<lunitik> Someone needs to provide a different perspective... or he needs to lose his op status...
<daniels> lunitik: as I said, if you provide full, unedited logs, then it can be dealt with appropriately by the CC, but not here.
<lunitik> Also... all I see is that CC meets every 2 weeks... anything more specific?
<daniels> 17:41 < lunitik> When is the next one?
<daniels> 17:41 < mdke> lunitik, search the wiki
<daniels> 17:42 < Kamion> 2005/08/16 IIRC
<lunitik> Kamion, thank you
<mdke> the wiki page will confirm the next date
<Kamion> just for avoidance of doubt, #ubuntu-devel is NOT an escalation channel for issues in #ubuntu; it's a development channel
<jk> perhaps it should be called #ubuntu-no-not-here :)
<lunitik> Sorry for distracting everyone... 
<pitti> mvo: here? can you please chmod 775 your seeds--breezy revision lock so that I can commit?
<mvo> pitti: args, doing this now. I swear I set my umask to 002
* lamont__ --> offline
<Kamion> mvo: you have 'umask 002' at the bottom of .bashrc, but right up at the top you have '[ -z "$PS1" ]  && return' so that the umask doesn't get set in the case of noninteractive shells
<Kamion> move umask above that and it should be fine
<Kamion> pitti: promoted
<mvo> pitti: fixed
<mvo> Kamion: right, thanks. fixed now
<Kamion> mdz: I assume all these language-pack-{gnome-kde}-* packages are ok to promote?
<mdz> Kamion: yes
<mdz> same content, different packaging
* Kamion prepares the world's biggest teri line
<Kamion> score, I crashed teri
<Kamion> oh, never mind, I just got -s and -c the wrong way round
<bddebian> Can I ask (without getting my head chopped off), why none of the new MOTU's have upload rights yet?  Is it just that the person responsible is too overwhelmed?
<mbreit> bddebian: elmo has a lot of work to do..
<mbreit> bddebian: but since \sh told him today about their keys, i think it will no take too long
<bddebian> mbreit: Well it doesn't matter anyway 'cause I get ignored in here as well as I used to in #d-d :-)
<Kamion> ah, good, http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html is looking a bit healthier now
<seb128> I get a "arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))" when trying to change the desktop seed ... any idea on what could be wrong?
<mvo> Kamion, seb128: could this be releated to my wrong umask in the commit before? (I changed my revision lock to 775 though)
<Kamion> mvo: hmm, the revision lock is missing altogether
<Kamion> drwxrwxr-x   3 mvo      warthogs 4096 Aug  8 17:28 ++revision-lock-held--patch-90--seb128@debian.org--628de7a29d2d9
<Kamion> ... but in the wrong directory ...
<mvo> strange ...
<Kamion> seb128: try again now
<Kamion> (I did mkdir -p patch-90/++revision-lock/+contents)
<seb128> Kamion: works fine now, thanks
<Kamion> seb128: are you in the process of fixing evolution-exchange/evolution-webcal to use new libsoup, or should I look at it? that's the last pair of ubuntu-desktop installability blockers
<Kamion> pitti: britney output's much better now, thanks
<seb128> Kamion: I'm waiting for today's new version of those to not do 2 uploads ...
<Kamion> there's still fallout from various uninstallable aspell-* and mozilla-firefox-locale-*
<pitti> mvo: I got disconnected...
<pitti> Aug 08 18:50:59 <pitti> mvo: here? can you please chmod 775 your seeds--breezy revision lock so that I can commit?
<pitti> Aug 08 18:51:31 <pitti> mvo: (and please consider setting umask 002 on chinstrap)
<Kamion> seb128: ok
<Kamion> pitti: it's sorted now
<seb128> if there is some hurry I can push rebuilds now though
<Kamion> later's fine
<seb128> cool
<pitti> Kamion: yay
<yann__> Hi... I thing gnome-panel-screenshot is broken
<yann__> it crashs every time with the --window argument
<yann__> (hoary)
<rburton> works for me on hoary
<yann__> gnome-panel-screenshot --window --delay=3
<yann__> that command crashes by me :/
<yann__> The Application "gnome-panel-screenshot" has quit unexpectedly. [...] 
<yann__> i'm using openbox instead of metacity... 
<rburton> yann__: get a stack trace with gdb
<{Seb}> is the cursor bug known (the cursor is not human but the awful standard X ones) and if so, fixed or not?
<Treenaks> {Seb}: there is a bug know, daniels mailed a fix to ubuntu-devel last week
<Treenaks> but that fix doesn't work for me :(
<yann__> rburton > yeah, eh, hum, i'm just a standard user ;) 
<Kamion> elmo: please sync libcaca-dev from unstable (slang2 transition)
<Kamion> elmo: (er, I mean libcaca obviously)
<yann__> i'll send it with bug buddy ^^
<yann__> http://pastebin.com/332145
<elmo> Kamion: nothing to sync?
<Kamion> elmo: oh, it was done earlier today evidently
<Kamion> or not
<Kamion> ah, failed to build
<yann__> so, bug reported, thks bug buddy?
<yann__> -?+.
<WaterSevenUb> seb128: this bug 7370 was about menu entries translations... where should I file bugs on the translation of menu entries now?
<seb128> WaterSevenUb: use rosetta
<seb128> ie: contact the rosetta team for your language
<seb128> or be a part of the team and fix the errors yourself
<seb128> bbl
<WaterSevenUb> seb128: I'm actually part of the team :) I don't understand very well who should I contact or what should I do to change the PO files themselves to include desktop menu entries strings...
<shackan> I downloaded a source package and want to configure it with --enable-debug, debian/rules does not have any configure section, where can I put my config parameters ?
<Kamion> shackan: wherever it runs configure
<Kamion> a configure target in debian/rules is not mandatory
<Mithrandir> *grumble*
<shackan> Kamion, so where does it take the options to give to configure ?
<Kamion> shackan: that totally and utterly depends on the package
<shackan> sh*t
<Kamion> come on, debian/rules files are usually not hard to read
<Mithrandir> is /dev/input/mice gone for anybody except me?
<shackan> they seem standard makefiles...
<Kamion> indeed
<Kamion> with some prescribed targets
<Kamion> the Debian Policy Manual has the details
<shackan> but this one is just five lines, and no configure options nowhere
<elmo> haha
<elmo> WELCOME TO CDBS
<Kamion> welcome to cdbs
<Kamion> it's "easy"
<Kamion> (allegedly)
<elmo> kamion: I think you misspelt retarded as easy, HTH
<zyga> mvo: hi
<mvo> hi zyga 
<shackan> mh, ok, I'm just making a fool of myself
<elmo> shackan: no, you're not, we're just bitter about cdbs
<Kamion> there's not exactly a lot of cdbs documentation, so you're likely to have to go read the included makefiles
<shackan> oh my..
<Kamion> https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS
<Kamion> may help
<zyga> mvo: did you have time to check my tiny patch?
<shackan> I Just thought "ok, let's rebuild this thingie with --enable-debug and see what's wrong here", it shouldn't take more than two minutes! man, I was wrong.. :D
<shackan> thanks a lot
<Kamion> in return you can promise never to create any new packages with cdbs. :)
<mvo> zyga: not yet, hopefully later
<Mithrandir> shackan: what package in question is this?
<shackan> I promise :)
<zyga> mvo: okay, thanks
<shackan> Mithrandir, I need debug output in bluez-libs
<Mithrandir> shackan: set DEB_CONFIGURE_EXTRA_FLAGS in debian/rules and you should be fine
<shackan> hooray!
<seb128> WaterSevenUb: the .pot file should get the desktop entries or that's a bug with the package
<shackan> Mithrandir, thank you!
<Mithrandir> shackan: np
<jordi> pitti_: ping
<shackan> CDBS automatically handle common flags to pass to the configure script, but it is possible to give some extra parameters :
<shackan> DEB_CONFIGURE_EXTRA_FLAGS := --with-ipv6 --with-foo
<pitti_> Hi jordi 
<shackan> cool, it says it here, too
<jordi> pitti_: I wonder if you haev some minutes to have a look at a security question I have for mailutils
<WaterSevenUb> seb128: assuming it's a bug, where do I file it?:) 
<jordi> pitti_: /usr/bin/apt-get: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
<jordi> pitti: oops, wrong paste
<pitti> that looks serious :-)
<jordi> pitti: http://svn.debian.org/wsvn/pkg-mailutils/branches/sarge/debian/patches/?rev=0&sc=0  and #312245
<seb128> WaterSevenUb: bugzilla
<WaterSevenUb> seb128: specifically where under bugzilla? 
<seb128> WaterSevenUb: do you have a package example? 
<seb128> the source package for the package with the bug ...
<jordi> pitti: that Debian bug says imap4d broke, and has a patch that seems reasonable to me according to the RFC
<seb128> pitti: are we going to have .desktop files translation with language-packs for 5.10?
<pitti> seb128: no, that's still future :-/
<jordi> The security patch in svn (04_IDEF*) adds that hunk, but I don't know if removing that else clause reintroduces a security bug.
<jordi> pitti: I wondered if you could eyeball
<WaterSevenUb> seb128: for example, gnome-app-install... but the maintainer said it is going to be included in a new upload (which makes me confuse again... will the new upload overwrite the translation in Rosetta?)
<WaterSevenUb> pitti: but the desktop files translation are not included in the templates of the applications?
<seb128> WaterSevenUb: you want to speak to carlos when he's here, they are loading the po files this week, not sure of what is done or to do
<seb128> pitti: they are, intltool put that to the .pot file
<seb128> ups
<seb128> s/pitti/WaterSevenUb
<jordi> WaterSevenUb: the desktop file translation *should* be included in the po file.
<WaterSevenUb> seb128: thanks! and thanks once again for  gnome-media as a hoary-update candidate:)
<jordi> WaterSevenUb: unless the app sucks and doesn't support intltool.
<pitti> jordi: bah, the huge configure patch is really necessary in 04_*?
<seb128> WaterSevenUb: np!
<jordi> pitti: no, I cleaned that up
<WaterSevenUb> pitti: so... If the desktop menu entry strings are included in the PO files, and if they are not going to be in language-packs for 5.10, does that mean that the templates in Rosetta are not going to be used in 5.10? :) I'm probably mixing things...
<pitti> WaterSevenUb: they will appear in rosetta, and we can use them to upload new package versions with improved translatio
<pitti> ns
<pitti> WaterSevenUb: but our langpacks don't ship updated .desktop files
<seb128> WaterSevenUb: the .pot/.po have the text/translation, but for the .desktop files the translation doesn't come from the .po but from the .desktop itself
<seb128> Name[<locale] =....
<pitti> WaterSevenUb: carlos made an upstream proposal to allow using gettext for desktop files
<pitti> WaterSevenUb: if this is accepted, it will become much easier
<pitti> jordi: hm, hard to tell by just looking at the patch, but since it reverses a sanity check introduced by a security patch, I'm sceptical
<pitti> jordi: a lot of mailers assign bogus/random UIDs though
<pitti> jordi: but I'd rather defer to upstream, is the patch known to them?
<jordi> they seem on VAC
<WaterSevenUb> pitti: so, If I understood correctly, while that proposal is not implemented.... whom to contact concerning the .desktop files?
<WaterSevenUb> pitti: I mean... translated .desktop files?
<pitti> WaterSevenUb: we already spec'ed out a solution#
<pitti> but didn't implement it yet
<pitti> http://udu.wiki.ubuntu.com/LanguagePackRoadmap
<seb128> WaterSevenUb: as said before rosetta has the translation
<seb128> WaterSevenUb: use rosetta for it. We will probably update manually the .desktop from rosetta before 5.10
<WaterSevenUb> ok:) thanks guys. have a nice evening!
<seb128> np, you too
<jordi> pitti: accordin to the rfc, that failure is wrong though.
<pitti> jordi: e. g. offlineimap assigns really crazy UIDs which probably don't stand many tests either :-/
<pitti> brb
<jordi> pitti: with that you mean the patch couuld be right?
<pitti> jordi: I mean that reverting it could be right
<jordi> pitti: hrm. I have this package ready which should be a debian stable target.
<jordi> I'll triplecheck with Joey
<jordi> pitti: thanks
<rubenv> infinity: I heard you have the network-manager packages under your control, do you see them getting ready in time for breezy, and if not, is there something I can do to help out?
<doko> lamont: any news about the openoffice.org build failure on i386?
<sivang> is this knows? 
<sivang> The following packages have unmet dependencies:
<sivang>   apt-file: Depends: libapt-pkg-perl but it is not going to be installed
<sivang> E: Broken packages
<sivang> s/knows/known/
<doko> elmo: please sync gcc-defaults from unstable
<mvo> sivang: it needs a rebuild
<sivang> mvo: ah I see, btw, do you happen to know what autopoint is and/or what package provides it? (my apt-file is broken :-) )
<BenC> any of the ia64 porters around?
<BenC> probably not an ia64 specific question, but I need to know where the gdm gets its information from about what X11 driver to load for the video card
<BenC> there is no XF86-Config like I was expecting
<jdub> yo BenC 
<BenC> hey
<jdub> you want xorg.conf?
<mvo> BenC: is there no /etc/X11/xorg.conf?
<Mithrandir> BenC: /etc/X11/xorg.conf?
<BenC> ah, ok, thanks
<BenC> well, it is loading nv
<BenC> but the video seems to lock up when X starts
<BenC> black screen
<BenC> debian X works fine with it
<Mithrandir> with the nv driver?
<Clint> ARGH!
<BenC> yeah
<BenC> maybe I should disable drm/gl stuff
<seb128> mdz: thanks for the libsoup uploads but I was working on this uploads with the new versions as said here 2-3 hours ago ...
<mdz> seb128: I'm trying to get an installable live CD, and those were the only two packages blocking it
<seb128> k, I ask Kamion if there was sure hurry and there wasn't ... no problem :)
<mdz> seb128: if you could wait for my version to be built before uploading, that would be good :-)
<seb128> k, will do
<seb128> s/ask/asked/
<seb128> s/sure/some/
<seb128> grumpf, I lack some sleep :p
<seb128> hum, and jbailey broke gconf too with his changes ...
<BenC> well, disabling dri/gl didn't help either
<seb128> if somebody has some gconf issues, change the /usr/share/gconf folders so they can be read by your user
<jdub> heh, this Armin Ronacher dude isn't having a good time on u-d
<seb128> hey jdub
<jdub> yo seb128 
<seb128> jdub: now than gtk-engines and gnome-themes ship clearlooks what do we do ... keep maintaining clearlooks package and update those 2 to not ship the files or other way?
<jdub> they both ship the metatheme?
<seb128> hum, lemme lock
<seb128> jdub: right, gnome-themes has a ./desktop-themes/Clearlooks/index.theme
<jdub> seb128: ... perhaps we should get this fixed upstream :-)
<seb128> jdub: hum, get what? Both the clearlooks package and the gnome-themes one ship the .theme. gtk2-engines doesn't 
<seb128> (I guess we were not speaking about the same "both")
<jdub> oh right
<jdub> hrmph
<jdub> i think removing it from clearlooks would be closest to the norm
<jdub> and it doesn't really matter for engine-only users that the metatheme isn't there
<jdub> (thinking about xfce or non-gnome usres)
<seb128> k, so we drop the clearlooks package and ship clearlooks from gtk-engines and gnome-themes?
<jdub> hrm, was only suggesting dropping the metatheme from clearlooks
<jdub> i think it makes sense to ship clearlooks (rather than gtk-engines) if the most useful stuff is happening there
<seb128> yeah, but do we have an interest to keep 2 clearlooks conflicting?
* jdub grumps in upstream
* jdub grumps in upstream's direction
* seb128 too
<jdub> well, if the clearlooks maintainers are going to keep doing clearlooks separately, and there's good reason to stick with it (staying on the edge), then yeah
* seb128 will ping clearlooks upstream
<BenC> how come there is a Contents-ia64 for breezy but no binary-ia64 directories?
<seb128> jdub: 
<seb128> <seb128> Remenic: where is the upstream source for clearlook now? Do you keep working on it on sf, or do you hack on gtk-engines/gnome-themes?
<seb128> <Remenic> seb128: gtk-engines
<seb128> <Remenic> I should mention that on the clearlooks page sometime
<windex> i have a souce package with a debian directory, how do i make a .deb file?
<elmo> BenC: ports.ubuntu.com
<windex> i always forget. :/
<BenC> ah, thanks elmo
<seb128> jdub: here we go, just dropping clearlooks :)
<BenC> breezy is the latest devel, correct?
<seb128> yep
<windex> dpkg-buildpackage -rfakeroot
<lamont__> BenC: you'll also find that the latest breezy (2.6.12) kernel has ACPI problems on ia64 if you try it...
<BenC> mainly just want to try the latest nv X driver
<BenC> 2.6.13-rc was working ok before on my i2k, just fyi
<BenC> wow, how do I set the fb font to something a little bigger?
<lamont__> BenC: cool.  it's either something in the config options enabled, or in the latest acpi patch - I got defconfig to boot with -4.4, but my build env might be suspect there...
<lamont__> this is booting on a zx2000, fwiw
<lamont__> BenC: http://cdimage.ubuntu.com/ports/daily/hoary/20050712.1/hoary-install-ia64.iso is a nearly-functional install iso
<lamont__> (when it screaches to a halt at elilo installer, get a shell, edit /var/lib/dpkg/info/elilo-installer.postinst, and switch the args on the db_fget call to make 'seen' second.  back to the menu and continue
<lamont__> (that's fixed in breezy, but is part of the reason that there isn't a hoary/ia64 release
<BenC> yeah, I got the install done from that page
<BenC> just this X thing is really slowing me down
<BenC> upgrading to breezy now
<mdz> BenC: you do have a desktop system based on an officially supported Ubuntu architecture, right?
<BenC> yes, I have an i386 system aswell
<BenC> that one is installed, and I am getting some things setup on it
<BenC> waiting till later to setup the sparc and ppc32 systems
<BenC> like in a few weeks :)
<mdz> ;-)
<lamont__> BenC: no hppa? :-)
* lamont__ makes the token effort to up the hppa user base by 50% :-)
<luis_> mdz: I hate to be a nag or anything, but do you guys have some kind of timetable for the daily livecds to be back up for x86?
<seb128> luis_: 
<seb128> <mdz> seb128: I'm trying to get an installable live CD, and those were the only two packages blocking it
<seb128> luis_: that was ~1h ago
<luis_> ah, cool
<jdub> seb128: tops, much saner (sort of) ;-)
<luis_> seb128: thanks
<seb128> np
<mdz> with luck, there will be live CDs within the next couple of hours
<luis_> mdz: very cool, thanks
<mako> luis_: nag ;)
<luis_> mako: =P
<luis_> mako: no futon for you!
<lamont__> mdz: installable livecd?  meaning buildable, or that one can install from it?
<mdz> lamont__: meaning buildable
<mdz> it's in the compression phase now, so it looks good
<lamont__> woot
<mdz> it's done
<lamont__> so now you just need to wrap the CD around the rootfs and publish, yes?
<mdz> doing that now
<mdz> seb128: go ahead with those uploads whenever you are ready; it worked
<Surak> where can we get it?
<seb128> mdz: k, thanks
<mdz> Kamion: do you know why debootstrap is claiming that W: http://archive.ubuntu.com/ubuntu/dists/breezy/main/binary-amd64/Packages.bz2 was corrupt
<mdz> ?
<mdz> (and similarly for i386 and powerpc)
<mdz> weird, now it likes amd64+i386 but not powerpc
<Kamion> mdz: never seen that
<mdz> Kamion: try an update of ubuntu-meta right now, would you?
<mdz> maybe it's just me
<Kamion> Surak: it'll be in the usual place (http://cdimage.ubuntu.com/daily-live/current/) when ready
<Kamion> mdz: yes, I see the same thing
<mdz> Kamion: powerpc failed, but otherwise seemed to go OK
<Kamion> looks like a mirroring glitch
<mdz> (the live CD build)
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | X is a lot less broken | i386 live CD builds restored: http://cdimage.ubuntu.com/daily-live/current/
<mdz> no idea if it works yet, of course, but there seem to be eager testers ;-)
* whiprush fetches
<jdub> mdz: you didn't have any comments re: lsb?
<Kamion> lamont__,infinity: libcaca_0.9-5ubuntu1_i386 is another broken buildd chroot; can that be cleaned up?
<lamont__> gah
<lamont__> hrm.. .thundermug doesn't like 64-bit architectures
<pitti> gosh, is it just me, or did ffox recently start to crash all over the place?
<tseng> pitti: it did, but it was fixed
<tseng> mine was a libcairo thing
<pitti> tseng: well, I recently switched from i386 to amd64
<mdz> jdub: context?
<lamont__> Kamion: given back
<Kamion> thanks
<Kamion> mdz: ubuntu-meta update's working for me now, I'll upload
<mdz> Kamion: I uploaded one already
<Kamion> oh, ok
<mdz> powerpc live build failed due to:
<mdz> The following packages have unmet dependencies:
<mdz>   linux-power3: Depends: linux-powerpc64-smp but it is not going to be installed  linux-power4: Depends: linux-powerpc64-smp but it is not going to be installed
<Kamion> that's due to l-r-m
<Kamion> there's no l-r-m for powerpc64-smp, and there needs to be (none necessary for powerpc64) 
<Kamion> either that or it should be taken back out of linux-meta
<BenC> lamont__: any idea why my i2k would all of the sudden have floating point driver load failure during EFI boot?
<mdz> Kamion: from what I can tell, it should just be a matter of adding it to the control file
<mdz> I'll see if my powerpc is up for a test build
<shackan> hi pitti
<Riddell> mdz, Kamion: there's some new versions of packages I'd like to upload, what's the process?
<lamont__> BenC: ew.
<pitti> Hi shackan 
<BenC> could that be the cause of my X failing?
<lamont__> I suppose it could
<mdz> Riddell: new upstream versions?
<shackan> pitti, how u doin' ?
<BenC> it didn't start until I did the ubuntu install :)
<pitti> shackan: tired, but fine. I'll go to sleep soon
<mdz> Kamion: why isn't powerpc64 necessary?
<Riddell> mdz: yes
<BenC> I've been seeing "floating-point assist fault" messages from some programs
<mdz> oh, we don't build a UP powerpc64 kernel
<mdz> Riddell: the process is to ask me
<Kamion> mdz: ... right
<mdz> Riddell: email with a rationale is best
<shackan> pitti, geek never go to sleep befor dawn :D
<BenC> well, time to reboot and see how things go
<shackan> *before
<shackan> *geeks
<shackan> damn, seems I'm tired as well
<Kamion> BenC: you're one of the few people testing Ubuntu ia64, I think ...
<lamont__> Kamion: very true.  I think the rest of us sit within 100 feet of my desk
<lamont__> well, there are probably a few others..
<elmo> and the 4 in the DC :P
<mdz> will any of the l-r-m stuff actually work on powerpc64-smp?
<mpt> Who's in charge of laptop support?
<mdz> BenC: ia64 isn't really first-class yet; it would be a better idea to use one of i386/amd64/powerpc to get up and running
<mdz> mpt: mjg59
<mpt> mdz: ta
<mdz> (as it says on the website)
<pitti> ok, good night everybody!
<Kamion> mdz: well, you're only building ath_hal with the volatile infrastructure on powerpc
<Kamion> madwifi and the firmware bits are probably useful
<mdz> Kamion: I've uploaded linux-meta to get things going
<mpt> mdz: actually the relevant wiki pages are remarkably free of contact info
<mdz> if stuff builds for me, I'll enable it
<mdz> mpt: http://www.ubuntu.com/community/teams/
<mdz> 2 clicks from the front page
<mpt> oh, you mean Ubuntu has a site other than the wiki? *ducks*
<mpt> mjg59: Is it possible/desired for people other than those who got Canonical laptops to join the laptop testing team? Now that those laptops have bene distributed, perhaps the LaptopTestingTeam wiki page could be updated to make that clear
#ubuntu-devel 2005-08-14
<ajmitch> ah, they've been distributed now?
<Riddell> mdz: mail sent
<BenC> lamont__: my ia64 is totally screwed, I left it powered off for 20 minutes and I still get the failure when loading the floating point driver during EFI
<BenC> lamont__: does ubuntu update any of the firmware during install?
<BenC> the failure says "Unsupported" when it gets to that point
<mdz> mpt: depending on the type of laptop you already have, yes, it could very well be useful to participate in the testing
<Kamion> BenC: only in the same way Debian does ...
<Kamion> we call elilo
<Kamion> which installs itself into the EFI partition, and AIUI fiddles with the EFI boot manager
<elmo> benc: try a firmware update
<whiprush> mdz: the latest livecd bombs out for me on loading X, it just loads a failsafe session
<whiprush> Can't compile keymap file
<BenC> elmo: last time I did a firmware update, the machine wouldn't boot anymore
<BenC> plus this was all working yesterday with Debian (X and all)
<elmo> benc: ouch
<BenC> and the firmware failure comes even before the EFI boot menu
<mdz> whiprush: a failsafe X session?
<Kamion> it's missing xkbutils
<Kamion> not to mention xauth
<Kamion> maybe we can shove those into the live seed as a temporary workaround; not sure if anything else is needed too
<whiprush> mdz: yep, just an xterm with no wm or anything.
<mdz> Kamion: I know of no reason why xbase-clients should not depend on them
<mdz> to do otherwise creates bugs
<Kamion> mdz: I know, but xbase-clients isn't being built at the moment as part of the transition
<Kamion> note how it's still at -42
<mdz> hmm, I see
<Kamion> likewise xutils
<mdz> I guess seeding them temporarily would work
<mdz> desktop seems more logical than live, though
<allee> doko: ping?  AVM B1 pcmcia
<mdz> of course, this transition is supposed to be finished in 3 days
<Kamion> or that - I was just reluctant to suggest using the seed whose metapackage has much higher visibility, 'cos putting things in those metapackages that should be in real dependencies is a nasty precedent
<mdz> whiprush: thanks for testing
<whiprush> np
<marcin> hi all
<Kamion> hmm, do we need somebody to keep the installer ticking over while I'm on honeymoon?
<marcin> does someone here know what's going on with ubuntuforums.org?
<mdz> Kamion: in what way?
<Kamion> mdz: which comment are you replying to?
<mdz> Kamion: installer ticking over
<Kamion> mdz: just making sure that CD images don't bitrot too badly installability-wise, really
<Kamion> and doing something about it if/when they do
<mdz> Kamion: then yes, probably so
<mdz> any nominations?
<Kamion> who's not got enough work to do? ;)
<Kamion> I'd be inclined to suggest jbailey and/or Mithrandir, if their other responsibilities allow
<Kamion> but any main uploader would be fine
<Kamion> probably needs to be somebody we're comfortable giving an account on little to, so that they can drive CD image rebuilds
<BenC> well, upgrading my firmware fixed the floating point driver error
<BenC> but X still isn't working
<mdz> BenC: this is not at all surprising
<Kamion> I'm biased towards people I've worked with lots, though, who are probably the busiest. :-)
* luis_ sees topic, is pleased
<luis_> thanks, mdz
<mdz> lamont: what is the lag time between cron.daily completion and the results being visible to *.buildd for livefs builds?
<lamont__> mdz: on the order of 2-5 minutes
<mdz> lamont__: cool, thanks
<mdz> attempting powerpc livefs build now
<lamont__> or rather, once cron.daily actually _finishes_, 0 minutes.
<lamont__> from start to availability is on the order of 5-8 minutes, and you know you were too fast when apt-get update barfs over MD5SUMS
<mdz> Kamion: wait a minute; am I to understand that xbase-clients is all of: a) missing binaries, b) not being built and c) not depending on the packages which replace it?
<mdz> I could understand it not being built in order to preserve the old version with the binaries in it, but the current situation doesn't make much sense to me
<lamont__> mdz: I've been given to understand that the current situation is best described as "work in progress"
<mdz> I've mailed daniels for his input
<Kamion> mdz: the original plan was to stop building it at the point when the version in the archive still contained binaries; due to an accident, that failed to happen
<Kamion> so I think the current situation is "better move forward as quickly as possible"
<mdz> Kamion: that would seem to include adding the deps
* lamont__ -> home
<mdz> Kamion: how much time is left on your build-image-set?  we have a powerpc cloop now and I'm ready to do another cron.daily-live
<Riddell> infinity, lamont: could you give back kipi-plugins on i386
<Kamion> mdz: it's building powerpc; should be done in ~10 minutes mayb
<Kamion> e
<cat> hey people
<|rockinnerd|> how unbroken is X?
* |rockinnerd| realizes this question is asked too much
<infinity> Riddell : Sure.
<wasabi> So why wouldn't the init scripts swapon all available swap partitions automatically?
<infinity> wasabi : If by "all available" you mean "all listed in fstab", they do..
<wasabi> Nope, I mean, scan.
<infinity> You want to scan for swap signatures, and just use whatever's available?
<wasabi> I'm trying to think about my circumstance here. I use EVMS to manage drives for my desktop system. I dual purpose it as a server. I love the idea of evms, I can plug and remove drives in haphazard fashions, and it keeps working... and figures out where things are.
<wasabi> Yeah.
<infinity> That sounds like it could be dangerous.
<wasabi> Basically I don't think at all to really manage my drives. I just plug it in and choose where to add it and not much else.
<infinity> Say you have two swap partitions for two different Linux installs that both happen to use suspend-to-disk.
<wasabi> So I want to remove thought from replacing my swap partition when a drive dies.
<wasabi> I guess I should just mount it thru evms...
<infinity> Yeah..
<wasabi> I guess if the swap drive dies my system is basically dead.
<wasabi> n/m!
<infinity> Generally, yes.
<infinity> Unless the swap is mirrored.
<infinity> (Well, some for of redundant RAID anyway)
<mdz> suspend-to-disk clobbers the swap space signature for that reason
<wasabi> I guess it's impossible for me to suspend to disk.
<wasabi> In that case.
<infinity> mdz : Ahh, right.  Well, surely there's some other use case where scanning can't be smart. :)
<wasabi> Since you can't resume from evms.
<wasabi> Hmmm.
<wasabi> Hmmm.
* infinity is nervous about the idea of the OS guessing what partition it should use.
<mdz> the live CD scans and uses any available swap partitions
<wasabi> This brings up an interesting question. I'd like to be able to suspend to disk.
<wasabi> But i'd like redundant swap.
<wasabi> And I don't want hardware raid.
<wasabi> So I'd like to suspend to file instead.
<wasabi> Or suspend to something else that works equally well.
<infinity> You probably want to bang heads with both mjg59 and jbailey in a room together and see if the tools are already there to do what you want, just sans documentation.
<wasabi> So I guess what I want is a special partition that is suspended to, b ut not swapped.
<infinity> (mjg59 as the suspend/laptop guru, jbailey as the "early userspace" dude)
<Burgundavia> Riddell, you got a minor typo in your package description
<Burgundavia> Riddell, kaffeine-xine - gstreamer engine for kaffeine media player
<Riddell> Burgundavia: oops
<Riddell> well spotted
<Burgundavia> np
<Kamion> oh, base-config is so close to working
<Kamion> it only fails now because some postinst scripts don't close debconf fds when starting daemons
* Kamion works around that, I think
<seth_k> my console-data package won't even configure itself correctly yet, which is preventing base-config from installing
<Kamion> works fine on today's CD image
<seth_k> hmm, must be a configuration issue for me then. works fine on my other breezy computer too
<Kamion> mdz: what's the difference between Tested and Completed, goal-wise?
<mdz> Kamion: pomp and ceremony, I suppose
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | X is a lot less broken | i386,powerpc live CD builds restored: http://cdimage.ubuntu.com/daily-live/current/
<Kamion> mdz: wondering what else I need to do to declare InstallerStage2Progress Completed
<mdz> Kamion: is it working in the latest install CD images?
<Kamion> no, you need base-config 2.67ubuntu8, which I just uploaded
<Kamion> the autobuild in five or six hours or so will work
<mdz> I think it's high time I did a round of install testing anyway
<Kamion> the latest available images hang just before starting gdm
<mdz> odd
<mdz> oh
<mdz> that's what's fixed in ubuntu8
<Lathiat> nice i can do some installer bashing then
<Kamion> right
<mdz> anyone seen daniels?  I'd like to finish getting the live CD into shape today
<infinity> mdz : He should be around my place in the next hour or so.  I'll have him ping you when he's in.
<mdz> madwifi certainly produces a lot of warnings on powerpc
<mdz> and at least one error
<mdz> on powerpc64
<mdz> so, no l-r-m on powerpc64 for now
<infinity> Colour me shocked.
<mdz> Kamion: do you know if madwifi actually works at all on powerpc?
<infinity> Do we have no facility to disable specific driver on different arches (so ppc64 can at least have fglrx and nvidia, for instance)?
<infinity> s/driver/drivers/
<mdz> yes, we do
<mdz> but madwifi is the only one which actually provides a binary for powerpc
<infinity> Oh. :)
<mdz> ati and nvidia provide i386 and amd64
<Kamion> mdz: don't know, I'm afraid
<Kamion> I can borrow a suitable card at the next conference and try it, I suppose
<infinity> mdz : How much do I need to bribe you (or mvo) to find a round tuit to implement Debian #164399?
<infinity> (Every time I 'apt-get source <anything with mozilla or xorg in the name>' it comes back to haunt me and my slow connection)
<mdz> infinity: so you want to get the tar from a local mirror and the newest diff/dsc from remote?
<infinity> <nod>
<infinity> Since we have the md5sums in the Sources file, I assume it shouldn't be too tough to mix and match like that.
<infinity> But I haven't looked at (not do I have a desire to look at) that part of apt.
<elmo> it'd help the buildds too, FWIW
<mdz> and you think I enjoy it? :-P
<elmo> not Ubuntu's, but, still
<mdz> string::size_type Slash = TmpSrc.rfind('=');
<mdz> infinity: dragons
<infinity> I often wonder if Culus lurks in these channels under a different nick just to hear people whine about his dragons.  Perhaps he dervies some perverse satisfaction from it.
<mdz> infinity: this is actually one of the tamer bits (apt-get.cc)
<mdz> the only complicating factor is that it passes around the relevant data as a reference to the source package record, so it can't mix and match from different sources within that
<infinity> Hrm.  That would seem to be an issue, yes.
<infinity> Could you internally pretend that "apt-get source foo (unversioned)" is an alias to "apt-get source foo=<each available version>", pull records for all of them, then mix and match?
<infinity> Or something equally hideous?
<mdz> you could do that
<mdz> or push the logic down into the bit which searches for the source package
<mdz> elmo: how would it help the debian buildds?
<elmo> mdz: they can fetch the X orig from a local mirror instead of hitting ftp-master for it
<mdz> dude, they should just use bittorrent
<mdz> and all the buildds could download from each other
<mdz> it'd be great
* infinity backs away slowly.
<Lathiat> haha
<TerminX> eek
<TerminX> no xgamma package ;_;
<TerminX> oh well *extracts all the files from xbase-clients_6.8.2-36.deb and copies the binaries that aren't provided by packages into /usr/bin*
<daniels> mdz: pong
<mdz> daniels: good morning
<daniels> indeed
<daniels> what can I do you for?
<daniels> hmm
<daniels> is anyone here (i.e. other than pitti) interested in the dbus 0.35.2 packages I did this morning for testing?
<daniels> sjoerd: ?
<mdz> daniels: xbase-clients
<daniels> mdz: ...
<mdz> daniels: among other things, the live CD is broken because it's missing all sorts of important X bits
<daniels> mdz: seed xrdb, xprop, xauth, xinit, xkbutils and xdpyinfo
<mdz> daniels: make xbase-clients depend on them
<daniels> mdz: sure, but those should still be seeded separately
<mdz> why?
<daniels> mdz: because you don't want xedit/xeyes on the live cd
<mdz> daniels: I so want xeyes
<daniels> mdz: more bonghits to table three
<mdz> oh, there is a GNOME equivalent to xeyes
<mdz> I guess we don't need it then
<daniels> is there??
<TerminX> daniels: package xgamma please :)
<mdz> I think we could probably spare the 11k to have it on there, though
<daniels> TerminX: if you're bored, you can package it
<mdz> daniels: yes, a panel applet called geyes
<daniels> mdz: sweet mother of god
<daniels> mdz: so yeah, xbase-clients and xutils are coming back as metapackages depending on all the externally-packaged stuff
<mdz> daniels: it's themable
<daniels> mdz: but ... WHAT OH MY GOD ... I think the seeds should still grow some granularity
<mdz> daniels: where is the modularisation process going to stand at feature freeze?
<jdub> mdz: i sent you and a couple of others an email about LSB (i went to the lsb plenary tonight)
<mdz> jdub: you did?
<jdub> yeah
<daniels> mdz: 'good'
<daniels> mdz: with moving, I haven't had any non-work time to fix the server on powerpc
<mdz> jdub: ah, yes
<daniels> mdz: but I'd be really surprised if someone didn't fix that before the next xorg RC (which is about two weeks away)
<mdz> jdub: what you suggested exactly matches my views
<jdub> oh, ok
<jdub> damn
<jdub> ;-)
<mdz> so I didn't feel it necessary to add anythingh
<jdub> being sensible never generates a response! ;)
<jdub> mdz: i think my opinion changes slightly with 6.04
<mdz> daniels: and can we get those metapackages in today?
<daniels> mdz: in whose timezone?
<mdz> daniels: yours
<mdz> it would unblock the live CD and also fix sprawling masses of upgrade breakage
<daniels> mdz: 'kay
<daniels> mdz: should I update the seeds and commit?
<mdz> daniels: I meant the xbase-clients and xutils metapackages
<mdz> which are already seeded
<daniels> mdz: right.  but we could do *both*. :)
<mdz> daniels: I think it would be sensible to get the metapackages in (which fixes those problems) and then work out what we really want in the seeds (which will involve discussion)
<mdz> s/those/both/
<daniels> mdz: 'kay
<Mithrandir> good morning
<daniels> geyes -> SO MUCH CRACK
<Amaranth> geyes has to be in the desktop seed
<mdz> Mithrandir: good morning sir
<bob2> does breezy's kernel have the syscall inotify?
<Amaranth> yes
<Amaranth> if that's the new one
<bob2> it's the one in 2.6.13-rc
<Amaranth> that's the one we have
<Amaranth> /dev/inotify is no more
<bob2> this "reboot the computer when hal gets updated" thing is kinda crap
<sivang> morning all
<sivang> can anybody tell me what would be the remedey for something like that:
<sivang> dh_shlibdeps -pfile-roller
<sivang> dpkg-shlibdeps: warning: could not find any packages for /usr/local/lib/liblaunchpad-integration.so.0 (liblaunchpad-integration.so.0)
<sivang> dpkg-shlibdeps: warning: unable to find dependency information for shared library liblaunchpad-integration (soname 0, path /usr/local/lib/liblaunchpad-integration.so.0, dependency field Depends)
<sivang> the 1st package is installed and supposed to be configured correctly, the second one was installed using a sudo make install
<sivang> and the weird thing, /usr/local/lib/liblaunchpad-integration.so.0's functions are working properly in the built package
<sivang> (as well as the 2nd's lib functions)
<pitti__> Good morning!
<sivang> morning pitti 
<sivang> pitti: I have soem problems with dpkg-shlibdeps, can you spare a moment to help me ?
<pitti> sivang: what breaks?
<mdz> sivang: dpkg-shlibdeps can't generate dependencies for libraries you installed from source...
<daniels> pitti: morning sunshine
<daniels> pitti: want some dbus crack?
<daniels> Amaranth: geyes is already in desktop, dude.  gnome-applets.
<toresbe> mm, dbus crack
<pitti> daniels: cool! :-) Well, it's not exactly for me, but ogra and some others will enjoy it :-)
<daniels> pitti: ah, ok
<daniels> pitti: know if there's anything that depends on it that I can test with?
<pitti> daniels: I guess if hal starts up afterwards, and g-v-m still mounts your CD-ROM or USB stick, then it didn't break horribly
<daniels> pitti: heh
<Treenaks> pitti: how about notification-daemon?
<pitti> daniels: you should test hal-device-manager, it uses glib bindings AFAIK (they changed in 0.35)
<sivang> mdz: ok, but liblaunchpadintegration is isntalled from a .deb
<daniels> pitti: 'kay
<mdz> sivang: /usr/local/lib/liblaunchpad-integration.so.0 isn't
<mdz> and that's the one you're using
<pitti> daniels: right, you can install notification-daemon and libnotify-bin and call "notify-send MUHAHA"
<daniels> pitti: heh
<sivang> mdz: if I had the lib installed from source, and then I apt-get install the .deb , I suppose that should fix things right?
<mdz> sivang: no, installing the deb won't delete your copy installed from source
<mdz> you need to do that manually
<bob2> sivang: this is one reason a chroot is handy, btw :)
<sivang> bob2: yeah, very much, but I didn't snapshot my dchroot - will do that next time I prepare another one :)
<sivang> bob2: (I am working in a choort )
<Mithrandir> doko_: ping?
<doko_> Mithrandir: pong
<Mithrandir> doko: any idea about the "no suitable windowing system found, exiting." message from ooo2?
<daniels> Mithrandir: can't open $DISPLAY?
<jamesh> glitz use maybe?
<jamesh> (guessing)
<doko> no, didn't look since yesterday
<daniels> if ooo uses glitz, I'm going to be really frightened
<doko> no, it's not yet configured to use glitz
<Mithrandir> I have some straces which makes no sense -- it tries to open a file which is there (as far as I can see), but gets ENOENT back (if run with the wrapper script), or I can run the soffice.bin directly and it opens the gtk plugin, the dependents before trying the kde and then the generic frontend.  All fail.
<Mithrandir> daniels: no, it's not that.  Unless it unsets DISPLAY, that is. :-P
<Mithrandir> ah
<Mithrandir> it can't find libsndfile and libxinerama
<Mithrandir> silly me.
<Mithrandir> it should be obvious that a word processor needs access to a sound library (as well as PAM)
<doko> Mithrandir: it needs the sound for the presentation module ...
<Mithrandir> I think ooo2 might be taking over the role of php as our premier library test suite.
<doko> yes, as long as it doesn't use it's own copies of the libs :-/
<bob2> ooo2 really links against pam
<bob2> that's scary
<bob2> er, s/pam/pam?/
<ajmitch> it sounds like the next emacs
<daniels> maybe I should make Xorg link to PAM and a sound library
<daniels> preferably one that's not MAS
<daniels> GStreamer ahoy!
<daniels> who wants to do that?
<daniels> maybe we could have it read out the entire Xorg.0.log via festival
<bob2> but Sun doesn't use gstreamer
<daniels> because only the most critical error messages are logged there
<bob2> stop oppressing solaris users
<bob2> make it link against NAS
<daniels> (WW) YOU HAVE A PCI BUS, WTF?
<daniels> (II) No, seriously, PCI.
<daniels> (--) Using PCI bus for access.
<Treenaks> (WW) Not even AGP?
<daniels> (EE) PCIE is the new black!
<daniels> bob2: nas != mas :P
<toresbe> hahah
<Mithrandir> isn't it PCIe?
<bob2> hah
<daniels> Mithrandir: or PCI-E
<bob2> PCI-X!
<Treenaks> PCI-EX
<Mithrandir> PCI-X is so last centure
<Mithrandir> s/.$/y/
<bob2> I can't wait for nvidia to do PCI-XXX GOLD HYPER CHAMPIONSHIP bus.
<daniels> PCISIG: Clarity is something that happens to other people.
<toresbe> I'm still waiting for a QBUS GeForce 6800GT.
<Treenaks> bob2: you're forgetting "18+"
<daniels> bob2: SUPER PCI FIGHTER ALPHA ZERO MEGA
* Treenaks wants an 8-bit ISA GeForce
<bob2> daniels: III
<daniels> Treenaks: ooo, that'd be neat
<daniels> Treenaks: you'd have to do some fun tricks to be able to properly address all the memory, though
<daniels> probably need a couple of register pokes to get the full address in
<daniels> then an IO access to get it, which would of course take eternity also
<Treenaks> daniels: just like EMS cards used to work
<daniels> that'd *really* teach you to care about framebuffer reads :)
<Treenaks> daniels: windowed memory access
<bob2> I wonder how long it would take to DMA a single frame to it
<daniels> bob2: ah, knew I was forgetting something
<daniels> Treenaks: heh
<daniels> copying down an untiled 1600x1200x24 framebuffer would be hillarious
<Treenaks> daniels: you'd need that EMS card to store the image data in memory :)
<bob2> hm, my hard disk has more ram than my first computer did
<\sh> bob2: more then 1kB?
<\sh> ;-)
<daniels> Treenaks: heh
<Treenaks> bob2: my harddisk has almost as much RAM as my first hard disk had space
<bob2> hah
<daniels> i have no idea how much ram the microbee had
<jdub> bah, delaying the shuttle landing again
<Treenaks> jdub: second time today?
<jdub> well, second day in a row, depending on your perspective :)
<Treenaks> jdub: it _will_ land today :)
<mdz> it's always today somewhere
<jdub> i hate being stuck in the past, though
<jsgotangco> the past?
<jsgotangco> you're a few hours ahead of us!
<jsgotangco> (if you're in sydney that is)
<ajmitch> jsgotangco: NZ is the way of the future
<mdz> he's a lot of hours ahead of me
<mdz> usually
<_d4vid> play Edwin Fisher/cd1/03 - Track  3.mp3
<jsgotangco> heh
<Treenaks> mdz: how does it feel to be stuck in the past? :)
<mdz> I feel old
<jdub> jsgotangco: in USA atm :)
<daniels> jsgotangco: jdub's visiting the backwards land
<jsgotangco> ohh
<mdz> jdub is on mdz time currently
<daniels> jsgotangco: they're permanently 18 hours behind
<jsgotangco> at least you can say you're a few hours younger than us :)
<Treenaks> So Gnome is 12 hours behind instead of 6 ahead there?
<Mez> mdz: about the ruby thing - I'm sure I requested it
<siretart> daniels: I try to prepare a package which builds in both sid and breezy, which uses GL and GLU headers. is it possible to specify build depends that work on both?
<Mez> siretart : | operator?
<daniels> siretart: libgl1-xorg-dev | xlibmesa-gl-dev | libgl-dev
<daniels> ditto glu
<siretart> daniels: thanks. I'll try
<siretart> hm. libgl1-xorg-dev does not exist in current sid. is this a problem?
<Mez> btw, can someone get rid of xlibmesa-glu-dev from breezy universe?
<Treenaks> siretart: one of the others will exist probably?
<daniels> siretart: no, because it will fall back to xlibmesa-gl-dev if sbuild is sensible enough
<mdz> that's the point of |
<daniels> elmo: please nuke xlibmesa-* binary packages, libxp*, libxaw8*, xmh, xdm, xfs, anything else that's NBS from xorg
<siretart> daniels: I'll take you as reference when searching for a sponsor ;)
<daniels> errrrr
<pitti> seb128: *sigh* libnotify is half-broken on ppc and doesn't work at all on amd64 ... :-(
<seb128> pitti: not cool
<seb128> pitti: have you pinged upstream?
<pitti> couldn't reach him yet, will try again
<pitti> seb128: actually I intended to upload my ubercool audio hotplug response today
<pitti> but if that only works on i386, we can't do that...
<seb128> right
<sivang> mdz, pitti : thanks a million, that was the problem and cleaning stuff manualyl helped :-)
<pitti> daniels: btw, do you consider using LSB init scripts for Debian's bus as well? If so, you could just upload to experimental and we can sync it
<seb128> pitti, daniels: are one of you going to update dbus?
<seb128> s/are/is/
<daniels> pitti: debian lsbification> absolutely not
<daniels> seb128: yes, after I've finished making dinner
<seb128> daniels: cool, thanks ... and this Xnest fix? :)
<seb128> this sabayon package is still waiting on my disk :p
<daniels> seb128: yeah
<daniels> that too
<seb128> thanks
<pitti> daniels: for postgresql-common I test whether the lsb include file is present, and use normal Debian output if not
<doko_> Riddell: ping
<Riddell> doko: hi
<doko> Riddell: please could you check, if the openoffice.org-kde package works for you on a current breezy? not the openoffice.org2-kde
<Riddell> installing
<siretart> fabbione: around?
<Riddell> doko: openoffice.org works with KDE widgets.  no kde icons or file dialogue
<doko> hmm, no kde icons where? in the desktop menus?
<doko> Riddel: could you dsiable in Preferences/OpenOffice/Common "Use OOo dialogs" and try again?
<Riddell> doko: icons are in the k-menu fine.  I mean it still uses gnome icons not kde icons (as it always has)
<Riddell> doko: where do I find Preferences/OpenOffice/Common?
<martink> Riddell, Tools->Options->OpenOffice.org->General
<doko> martink: thanks, you were faster resetting the locale data ;)
<Riddell> doko: the file dialogue crashes
<doko> Riddell: did it crash in hoary as well?
<martink> doko, ;)
<Riddell> doko: installing in hoary now
<doko> hmm, maybe I should give it a try with gcc-3.4, to match KDE's C++ ABI ...
<doko> elmo, Kamion, mdz: UVFE for aspell-pl and aspell-sl please, then sync from unstable
<doko> elmo: please sync gcc-defaults
<Amaranth> err, what locale is crapping all over the OpenOffice trademark?
<Mithrandir> yay
<Mithrandir> I have ooo2 running on amd64
<doko> nice
<Riddell> doko: crashes in hoary too] 
<doko> Riddell: thanks, at least, no regression :-)
<doko> hmm, libglu1-mesa-dev doesn't exist anymore ...
<doko> daniels: what is the replacement?
* Lathiat laughs
<Kamion> libglu1-mesa-dev | 6.2.1-5ubuntu4 |        breezy | amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> it's just broken due to libgl1-xorg-dev uninstallability
<pitti> mvo: btw, thanks for the lang-selector report; although such a report is not really required for stuff we write on our own :-)
<doko> ahh, crap, no that's the dpkg segfault again :-(
<Amaranth> seb128: Can you see if pyxdg cvs fixes your problems?
<Amaranth> seb128: Latest CVS should actually work and just ignore any files that have a filename that it can't convert to utf-8
<Kamion> doko: aspell-sl is already synced, but failed to build
<mvo> pitti: ah, well :) 
<seb128> Amaranth: /usr/share/doc/python-xdg/examples/test-menu.py works fine with the CVS
<Kamion> doko: aspell-pl approved
<Kamion> Mithrandir: with or without pure evil?
<doko> ugh, tightened debhelper build dep ...
<Amaranth> seb128: and it failed with a UnicodeDecodeError before, right?
<doko> Kamion: without pure amd64, all evil included
<seb128> Amaranth: 
<seb128>     if menuentry.DesktopFileID not in ids:
<seb128> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 2: ordinal not in range(128)
<seb128> 
<seb128> with the current tarball
<Amaranth> ok, cool
<doko> Kamion: would you mind a debhelper merge for breezy?
<Amaranth> lanius wants you to try a 'simplified' version of the fix otherwise this can be considered 0.15 hopefully
<Mithrandir> Kamion: about 160MB of the purest evil you can find.
<seb128> Amaranth: rock. Let me know when 0.15 is ready to be packaged
<Kamion> doko: the debhelper 4.9.4 and 4.9.5 changelogs look fine for breezy, so yes
<Kamion> doko: er, I mean "no, I wouldn't mind"
<Kamion> damn English anyway
<doko> Kamion: ok, merging ...
<eruin> anyone seen #13070, #12563, #13095 - shouldn't they be blockers ?
<ogra> pitti, i got a little present for you :) http://www.grawert.net/Screenshot.png
<pitti> Hi ogra
<Treenaks> ogra: pg8 on amd64? is that the present? :)
<Treenaks> ogra: or php5?
<ogra> yup...
<ogra> mediawiki on php5 and postgres isnt possible they say ;)
<Treenaks> ogra: how did you do it? :)
<ogra> search halfway done patches and complete them...
<Amaranth> seb128: *sigh* can you see if latest CVS still fixes the error?
<seb128> Amaranth: works fine
<Amaranth> seb128: just checked out? he just committed the new 'fix'
<Amaranth> if so once he is done eating i think we'll have 0.15
<seb128> again?
<seb128> no, there is no change on the CVS
<Amaranth> ok, good
<Amaranth> 0.15 Real Soon Now, unless he does something that makes me have to stab him :)
<seb128> he he
<seb128> pitti: do you have an ipod?
<pitti> no, but carlos has
<carlos> seb128, what do you need?
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=13177
<pitti> carlos: he wants it :-)
<pitti> (me too, ....)
<seb128> if this bug stay here as debzilla/eject I guess it'll not move
<seb128> so it should probably be assigned to gnomevfs, pmount, nautilus, whatever ...
<carlos> pitti, ;-)
<pitti> seb128: I noticed this and I will fix it after feature freeze
<pitti> seb128: you could close it as a dup of #5049
<seb128> pitti: do you know what the issue is? Should I reassign to you?
<seb128> cool, will do, thanks
<carlos> seb128, it was working here before
<pitti> seb128: I don't know the reason, but I can reproduce it on i386 (works fine on ppc and amd64)
<carlos> oh, I tested it with my ppc computer, so then that's why it works :-P
<elmo> UDU and Ubuntu wikis are RO - pending their merge; if anyone asks on other channels please let them know
<seb128> pitti: without an ipod?
<pitti> seb128: with my usb stick and CD-Roms
<seb128> k
<Amaranth> seb128: I'm stabbing.
<seb128> Amaranth: why?
<hno73> NOTICE: the ubuntu and udu wikis are now READ-ONLY, so hold off on edits for a while. Should be about 30 minutes. Thanks.
<Amaranth> seb128: <lanius> mayb we need other changed to menueeditor.py for smeg-0.8?
<Amaranth> seb128: this makes me stab ;)
<seb128> ah ah
<Kamion> seb128: do you have a gst-plugins0.8 upload coming up?
<seb128> Kamion: yep, I've a patch waiting for upload ... probably this afternoon. Need any change?
<Kamion> seb128: yes, s/aalib1-dev/libaa1-dev/ please
<seb128> k
<Kamion> that should cause gstreamer0.8-aa's dependency on slang1 to disappear without any further changes
<Kamion> which will make it installable
<Kamion> you can drop the versioning on the build-dep too, I guess
<seb128> right
<seb128> Kamion: do you know where evolution-data-server 1.3.7 is hidding?
<seb128> I've uploaded it yesterday evening
<seb128> it has built according to the build logs
<seb128> but the debs are not here
<Kamion> (new) libebook1.2-5_1.3.7-0ubuntu1_sparc.deb optional libs
<Kamion> (new) libedataserverui1.2-6_1.3.7-0ubuntu1_sparc.deb optional libs
<Kamion> seb128: I've processed it now
<seb128> thanks
<seb128> why is it new? because of sparc?
<Kamion> no, because the archive only had libebook1.2-3 and libedataserverui1.2-4 before; package names changed
<Kamion> overrides aren't arch-specific
<infinito> elmo: excuse me, are u here?
<seb128> Kamion: hum right, thanks
<hno73> NOTICE: The ubuntu wiki is now writable again after pages have been transferred in from the UDU wiki. udu.wiki.ubuntu.com now forwards to wiki.ubuntu.com
<Lathiat> hrm just found a rather nasty bug on the livecd
<Lathiat> xscreensaver locks the screen
<Lathiat> and you cant unlock it
<Lathiat> and when i killed xscrenesaver from the console X died
<seb128> that's a known issue
<torkel> Lathiat: xscreensaver killing X is not a bug, it's a feature...
<Lathiat> torkel: ah, i thought might be so
<edd> anyone know who's currently managing bluez bluetooth stuff for breezy?
<Lathiat> hrm, changelog doesnt really indicate anyones overly looking after it
<seb128> there is bounty about that, isn't it? pitti?
<edd> Lathiat: on breezy, even the changelog isn't there! it's totally broken, which is why I'm asking :)
<Lathiat> ermm
<Robot101> edd: nokia have written obex vfs stuff which we should steal :P
* edd is the maint for bluez in debian,hence my interest
<Lathiat> im on breezy and bluez-utilos has a changelog...
<seb128> how the changelog isn't here?
<ajmitch> chmj was handling the bluetooth spec
<edd> Lathiat: as of last night on my upgrade there wasn't.
<Lathiat> i upgraded earlier
<seb128> a package without a changelog? how does that work?
<Lathiat> what version do you have?
<Lathiat> i have 2.18-0ubuntu1
<seb128> I guess it doesn't build without debian/changelog
<ajmitch> as do I, and it still works
<edd> ah.
<edd> i see the problem, my fault.
* edd hides in shame
<ajmitch> edd: it's ok :)
<Lathiat> edd: has there been any movement on any of this stuff?
<edd> it's the 2.18-0 that got me.
<edd> i'd previously been doing 2.18-1 cos of my own packaging on hoary
<edd> and 0 is smaller than 1, naturally.
<edd> difficult when breezy gets ahead of sid.
<Lathiat> heh
<ajmitch> I just started using bluetooth last week, and noticed the nautilus-sendto support missing for it
<Lathiat> ajmitch: theres a patch somewhere
<edd> ajmitch: we have that in CVS
<Robot101> edd: yeah I was a bit narked about that
<Lathiat> probably in bugzilla
<ajmitch> I guess we wait for a newer upstream of that
<edd> needing hadess to do another release of gnome-bluetooth
<edd> i'm very near handing him the maintainership of it
<ajmitch> right
<seb128> ajmitch: I've built nautilus-sendto without it on purpose
<ajmitch> so far I got file transfer going, just not evolution syncing. hopefully that will get in for release
<seb128> ajmitch: gnome-bluetooth is universe and nautilus-sendto main ... if somebody want to do the administrative work to move it to main go for it
<seb128> I don't have any bluetooth stuff here to play with it
<ajmitch> seb128: I could write up a report, it'd have to be done by feature freeze?
<seb128> ask mdz when he's around
<ajmitch> ok
<seb128> the question would probably be "how does gnome-bluetooth work", ie: fine enough for main?
<\sh> is it ok to sync kxdocer-0.35 from debian? 
<\sh> in universe?
<\sh> kxdocker even
<ogra> \sh, anything that depends on it ?
<\sh> ogra: only install dep for kxdocker-data...and this I have to rebuild again
<\sh> kxdocker-data is on unmet deps.
<ogra>  sync it :)
<edd> seb128: with the current release, i'd say "no"
<edd> seb128: hadess and/or me need to dump another release out. cvs has moved on loads
<seb128> k, thanks
<seb128> when is the new version planned?
<\sh> elmo: please sync kxdocker 0.35 from debian for universe...
<seb128> is that worth to package the current CVS?
<edd> seb128: i've not even put the current release in sid, for example.
* edd will mail hadess
<luis_> bob2: there are patches to make ooo link against real or gstreamer, I believe
<bob2> hahaha
<luis_> dude
<luis_> it needs an embedded media player
<luis_> duh
<bob2> right
<luis_> clearly it isn't worth crap if it doesn't have an embedded media player
<bob2> best they do it themselves, too
* luis_ rolls eyes
<bob2> gstreamer might not work on sunos 1.x
<Lathiat> so totem played this real stream better than realplayer
<Lathiat> but i couldnt get proper audio in totem (xine)
<Lathiat> oh well
<Gman_> luis_, i kinda like the idea of having music to slides :)
<Kamion> lamont: so can we sync util-linux from Debian now? (just seen the changelog)
<seb128> another one?
<seb128> ups
<Mithrandir> Kamion: I'm working on merging ia32-libs.. it appears it contains some stuff we don't have in main.  Any ideas what to do?
<Kamion> Mithrandir: like what?
<Mithrandir> libstdc++2.10-glibc2.2
<Kamion> is it straightforward just to leave that stuff out?
<Mithrandir> well, I have to redo the package with .debs from ubuntu anyhow, so yes.  My issue is that we'll have differing ia32-libs in Ubuntu and Debian.
<Mithrandir> that is, some parts will be in Debian and not Ubuntu and possibly the other way around.
<Kamion> we already do though, don't we?
<Mithrandir> we're stuck with an ancient version but not more apart from that, iirc
<Kamion> hmm
<Kamion> it's a shame this stuff is not in separate packages
<Mithrandir> it'd be fourty packages or so.
<Kamion> I guess libstdc++2.10-glibc2.2 is needed for old proprietary applications
<Mithrandir> yeah
<Mithrandir> I could split it out, but I'd really like to discuss that with Bdale first.
<Kamion> we could have ia32-libs and ia32-libs-universe, a la php
<Kamion> messy to maintain, but would work ...
<Mithrandir> it would, yes.
<Kamion> I don't have any bright ideas other than that, really
<Mithrandir> but we'd lose ia32-libs compatibility with debian in a ditch somewhere.  Unsure if I care too much about it for that single package, though.
<Kamion> except to note that perhaps if we're adding new stuff, we should do it in separate packages built from the same source rather than in the big ia32-libs blob (multiarch-style?)
<Kamion> built from the same source as the rest of the relevant library, I mean
<Mithrandir> so libc6 would build lib32c6_amd64.deb on i386?
<doko> Mithrandir: yes, jbailey is working on that
<Kamion> oh, eh, I guess that's messy
<Kamion> I was more thinking of a build on amd64 with -m32
<Mithrandir> I don't think I want to try crossbuilding X.
<Kamion> but in any case, I wasn't suggesting changing existing stuff at this point, but doing biarch builds now that the toolchain is getting better seems just generally cleaner?
<Kamion> for new stuff
<Mithrandir> I'd like to use multiarch for it, but dpkg needs some love first and I don't have time for that just yet.
<Mithrandir> anyhow, I'll think of something
<doko> to build the toolchain biarch, we need a biarch glibc as well. IMO we should have birch support in gcc/glibc independent of the multiarch stuff
<Nafallo> elmo: did you just add me somewhere? I got a reject on libdc0 :-).
<daniels> seb128: right, fixed this stupid font path problem
<daniels> seb128: like anyone uses that crap anyway
<seb128> thanks
<seb128> sabayon does use it ... :)
<daniels> pfft
<daniels> sabayon should use xephyr
<daniels> and the sabayon maintainer should also package xephyr
<seb128> say that to markmc :p
<daniels> the sabayon maintainer in *ubuntu*
<seb128> hum ... do you want to be listed as maintainer with the coming upload? :)
<Amaranth> xephyr?
<mjg59> seb128: Have you had a chance to apply those hotkey defaults?
<daniels> seb128: no way, dude
<daniels> Amaranth: it's like xnest, but it doesn't *suck*
<Amaranth> hehe
<Amaranth> that's a plus
<Amaranth> isn't it a part of the modular x stuff?
<Nafallo> elmo: thanx :-).
<seb128> mjg59: not yet but that's my list for after the update of GNOME to 2.11.91
<mjg59> seb128: Thanks
<seb128> np
<daniels> Amaranth: modular X is a prerequisite for it, sure
<theine> Hi, in the source package for the hoary kernel (linux-source-2.6.10) the kernel's abi file for the most recent patch level (2.6.10-34) is missing. Only the abi file for 2.6.10-33 is present. This prevents me from doing dpatch-edit-patch <new-patchname>. What shall I do?
<lamont> Kamion: there are init-scripts in util-linux, so it's a merge.
<Kamion> ok
<Kamion> you wouldn't fancy doing that when you get a minute, would you?
<lamont> you want slang2 for breezy then?
<Kamion> at the moment we have both slang1 and slang2 in breezy base
<Kamion> I want slang1 the hell out. :)
<daniels> i want xlibs-dev the hell out
<daniels> and also a pony
<Kamion> -rw-rw-r--  1 cjwatson warthogs 23120 Jul 15 15:04 public_html/germinate-output/breezy/_germinate_output
<Kamion> so not impressed
<daniels> Kamion: anything glaring that's my fault?
<Kamion> with regard to anything in particular? :)
<daniels> the germinate output, I 'spose
<Kamion> oh, that's my fault I assume, not that I can see how right now
<Kamion> (the fact it hasn't run for nearly a month)
<daniels> ? Unknown supported package: libxxf86rush-dev
<daniels> ? Unknown supported package: libxxf86rush1-dbg
<Kamion> oh, I see. sorted now.
<daniels> ? Unknown supported package: libxaw8-dev
<daniels> ? Unknown supported package: libxaw8-dbg
<daniels> we need to kick that shit out
<Kamion> daniels: reload, see if it makes more sense
<Kamion> oh, but if you want to remove old crap from the "rescued from extra" section of the supported seed, feel free
<Kamion> that section tends to bitrot somewhat
<daniels> ? Unknown supported package: dbus-qt-1-dev
<daniels> libdbus-qt-1-dev
<daniels> oh right, it's in arch, isn't it?
<Kamion> yeah
<\sh> elmo: thx :)
<Kamion> ubuntu-devel@lists.ubuntu.com/seeds--breezy--0
<daniels> Kamion: bleh
<\sh> daniels: ready for xterm? 
<Lathiat> elmo: yay. :)
<daniels> wtf is libxkbui missing though?
<daniels> \sh: sure
<\sh> ok..then I'm uploading it just now
<edd> do the dbus package names now differ from those in debian? my sid packages that depend on dbus wouldn't just drop-in to breezy. seems an unfortunate change if so
<Kamion> daniels: it's not in breezy
<daniels> edd: yeah, 0.2x is in sid, 0.3x is in experimental and sid
<daniels> edd: i did all the stuff for ubuntu first, and then myself and sjoerd put that into debian
<daniels> edd: but didn't want to disrupt the freeze
<daniels> Kamion: must've been one of the missing uploads
<theine> I'm sorry for telling you this again, but I can't build linux-source-2.6.10 using dpkg-buildpackage because the latest kernel's abi file is missing in the source package. This is a Hoary and not a Breezy system.
<edd> daniels: nod. /me just getting confused these days
<daniels> edd: heh
<daniels> edd: would love to see awesome bluetooth love though :)
<edd> daniels: must have been all that time i spent fiddling with Xgl since miggy's demo
<daniels> hah
<daniels> xgl is crack of the highest order
<edd> daniels: yeah, and i'd like to have some real motivation to do it. but *shrug*
<tseng> hiya edd
<daniels> SSSSSSSSSSSSSSSSSSSSEEEEEEEEEEEEEEEEEEEEEEEEEEEEBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
<daniels> seb128: panel crashing repeatedly + 'omg dude another panel wtf' in infinite loop == so much fun
<pitti> haha, you too?
<daniels> yes
<daniels> gnome-panel wants me to die in a ditch, violated, used, and unloved
<pitti> daniels: I did the same solution
<seb128> daniels: gnome-session-remove gnome-panel && gnome-panel &
<Amaranth> gnome-session-remove!
<Amaranth> *headdesk*
<Treenaks> Amaranth: Oh, I just kept killing it until it stopped whining, then removed it using the "Remove from session" GUI
<Kamion> theine: our primary kernel maintainer is on holiday, which is probably why nobody's answering you. Perhaps you should just file a bug.
<Amaranth> Treenaks: i was trying to kill it and start another one in gamin debug mode before the first one restarted
<\sh> daniels: xterm_203-0ubuntu1 accepted
<Amaranth> ooh, wxwidgets doesn't make it's own file open dialog anymore
<Amaranth> this is a plus
<pitti> wb ogra
<ogra> heyy
<pitti> ogra: saw the mediawiki screenshot, great
<ogra> yeah...
<daniels> \sh_away: cool
<pitti> ogra: btw, does your ffox crash very often on your amd64 as well?
<ogra> i'm just playing with wwwconfig-common... didnt know about it
<Lathiat> daniels: want to put a patch in dbus in breezy for the python bindings that makes avahi work? :)
<ogra> nope... nautilus and the panel are worse
<Lathiat> stupid buggy pos python bindings
<daniels> Lathiat: if it's not against 0.35.2, I'm not interested :P
<ogra> pitti, but i dont use any plugins or extensions
<Lathiat> of course its up to date :)
<pitti> ogra: it even crashes with an empty profile
<ogra> hmm...
* ogra tries with a new user
<Lathiat> daniels: https://bugs.freedesktop.org/show_bug.cgi?id=4023 it even says its against 0.35.2 :)
<daniels> Lathiat: consider it done
<Lathiat> daniels: hrm that was easy, thanks.
<pitti> seb128: along with a security fix, I have some font handling optimizatuion patches from SuSE
<Lathiat> now i dont have to make my own copy
<daniels> ARGH
<pitti> seb128: I ported them to our version and tested them (actually for an unrelated purpose)
<seb128> pitti: what package?
<daniels> Lathiat: sif merge typo fixes in with that patch
<Lathiat> daniels: yeh i was just thinking that
<pitti> seb128: they didn't do what I actually wanted, but they work
<Lathiat> daniels: i just smacked lennart on the head for it ;p
<pitti> seb128: oh, sorry: poppler
<seb128> pitti: any context?
<seb128> they are from the CVS?
<pitti> seb128: do you have any objections against just applying them?
<seb128> not at all
<pitti> seb128: they are from SuSE's xpdf version
<Kamion> kbd-chooser's debconf use is so awful
<pitti> seb128: I don't know whether they are upstream now, but since they don't change any semantics, we can just drop them if we don't want them any more
<Kamion> cdebconf/debconf incompatibilities don't help
<seb128> pitti: go for them, thanks
<pitti> ok
<daniels> elmo: libxkbui needs to go into main fwiw
<ogra> pitti, even with a new user ff works fine here
<pitti> ogra: grumpf
<pitti> daniels: do you have any idea how to debug dbus services?
<pitti> daniels: in particular, how can I see the stdout/err of processes that are started through a service.d file?
<daniels> pitti: i dunno, redirect them to a logfile in the service.d file? :P
<seb128> pitti: do you know about https://bugzilla.ubuntu.com/show_bug.cgi?id=13247 ?
<theine> Hi, in the source package for the hoary kernel (linux-source-2.6.10) the kernel's abi file for the most recent patch level (2.6.10-34) is missing. Only the abi file for 2.6.10-33 is present. This prevents me from building the kernel using dpkg-buildpackage
<doko> elmo: please sync:  aspell-pl wftk gcc-defaults
<pitti> seb128: yes, I saw it in my new bugs mbox this morning
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b %*!*theine@fw2.nbi.dk]  by daniels
* mode/#ubuntu-devel [-o daniels]  by daniels
<elmo> doko: done
<lamont> Kamion: I gratuitously re-sync'ed the shlibdeps for mount, since the hoary version was a backport of the fix from sid
<doko> thanks
* lamont will upload -5ubuntu1 shortly
<Kamion> lamont: fine, thanks
<Kamion> theine: dude, I've answered you already
<luis_> hrm, known that the gnome-session on the 2005-08-09 livecds fails?
<Kamion> yeah
<Kamion> luis_: couple of missing binaries
<luis_> okeydokey
<seb128> luis_: any error?
<luis_> I'll look at it in a sec
<luis_> I just gave myself a gigantic, painful bruise on the head
<Lathiat> nice
<luis_> am typing with one hand, other is holding ice on the bruise
<Lathiat> howd you manage that
* Treenaks guesses: procmail source hacking
<luis_> heh
<Lathiat> heh
<luis_> bent to pick up towel on floor in bathroom, hit head against the ceramic part of the towel rack as I was coming back up
<luis_> bbiab
<Treenaks> luis_: ouch.. good luck with that then
<doko> Kamion, elmo: do I need a UVFE for a new package from unstable? It will land in universe anyway, but maybe end up as a OOo2 b-d (portaudio). Same for mythes, currently in incoming/experimental.
<mjg59> elmo: I don't seem to get any emails when uploading packages
* Mithrandir uploads the package of doom (aka ia32-libs)
<luis_> seb128, so where does gnome-session log?
<luis_> (it's been so long since I had a problem with it that I have no clue)
<elmo> mjg59: what email are you using?
<doko> elmo: please sync libgdchart-gd1, not urgent, but seems to be a leftover
<mjg59> elmo: mjg59@srcf.ucam.org
<seb128> luis_: ~/.xsession-errors
<seb128> luis_: do you have any message or it just hang or something?
<elmo> mjg59: whitelisted
<elmo> doko: done
<luis_> seb128: says it can't load my session, and here is your happy friend, xterm
<mjg59> elmo: Thanks - do I just upload again?
<daniels> seb128: from Xvfb: ^@cursor^@fixed^@/usr/share/X11/fonts
<Mithrandir> doko: I have ooo2 working-ish on amd64 now, doing the ia32-libs upload now, but will be postponing the ooo2-amd64 upload for tomorrow.  Looks like ia32-libs-gtk needs a little bit of love for cairo and pixman and then we should be fine with ooo2 for gnome at least.  I'm wondering if we need to do ia32-libs-kde as well :-/
<luis_> ,xsession-errors says it can't find the 'sessreg' utility
<elmo> mjg59: not being whitelisted just means you don't get email; the package probably went through.  what was it?
<mjg59> luis_: That's daniels's fault
<luis_> gah, how did the xchat defaults become *worse*?
<mjg59> elmo: hotkey-setup
<daniels> luis_: that's because sessreg doesn't exist.  cock.
<luis_> great balls of cock.
<Lathiat> luis_: heh
<elmo> sigh
<daniels> goodness gracious
* luis_ is glad someone caught the reference
<doko> Mithrandir: we don't need cairo for OOo2 yet. or is this gnome, which needs it on it's own?
<elmo> \sh_away: umm dude, you know about the UVF right?
<Mithrandir> doko: probably gnome
<ogra> elmo, i'm allowed to approve overrides, \sh_away asked before
<Mithrandir> elmo: can you nuke the partial ia32-libs upload?
<elmo> ogra: this is for main dude
<seb128> luis_: blame xorg. xordoquy had a such issue yesterday on a daily install, xinit package was not installed ...
<elmo> AFAIK you're not kamion or mdz
<ogra> elmo, err... main... oops
<luis_> seb128, yeah, same problem here, looks like
<elmo> mjg59: one sec
<mjg59> elmo: Ta
<elmo> Mithrandir: done
<Mithrandir> elmo: thanks.
<ogra> elmo, then i deny having ever approved it :)
* ogra pretends innocence
<doko> Mithrandir: I don't know about ia32-libs-kde, maybe ask Riddell?
<luis_> OK, that means I can rebuild my livecd with xinit and have something you guys don't have for the moment ;)
<luis_> ttfn, then
<Mithrandir> doko: well, if we want ooo2 with kde look on amd64, we need it.  It'll just be paaaain for me.
<mjg59> Is xscreensaver going to start looking beautiful again?
<doko> Mithrandir: you don't love pain? ;-P
<ogra> mjg59, unlikely
<ogra> mjg59, we'll switch to gnome-screensaver it seems
<Mithrandir> doko: no :-)
<daniels> seb128: gtk bug
<mjg59> ogra: Cool
<Lathiat> ooh gnome-screensaver is pretty
<doko> Riddell: Is OOo2 on the kubuntu CD?
<Lathiat> altho resetting the timer everytime you hit a key is kindof ugly looking
<elmo> Treenaks: around?
<Mez> elmo: can you sync memaid-pyqt from debian please
<Mez> as per bugzilla 11889
<|rockinnerd|> is breezy worth installing?
<|rockinnerd|> how broken is the installer?
<pitti> Nafallo: I saw the bugzilla upload, thanks :-) will release it as soon as it has built
<siretart> elmo: if you are at it, could you also please look at bugzilla #12536? bogofilter is tried to be built for weeks now, but constantly fails because not all build-dependencies are satisfyable in main. 
<LinuxJones> |rockinnerd|, don't install it
<Kamion> |rockinnerd|: it's fine at the moment (on i386, anyway) except that you can't start a GNOME session because a few binaries are missing
<ogra> |rockinnerd|, the installer is fine...
<|rockinnerd|> ok.
<Riddell> doko: it's in the kubuntu seed, so yes
<Mez> siretart: if something's in main, shouldnt it's deps be in main too?
<Kamion> in general yes but it isn't automatic
<siretart> Mez: you are right, they should
<Kamion> see https://wiki.ubuntu.com/UbuntuMainInclusionQueue and search for bogofilter
<|rockinnerd|> one would think that since k3b b*****s and moanes about not having cdrao, it would be in the deps..
<siretart> Kamion: ah, I haven't seen that. thanks for the link
<Mez> hyperactivecrond, it doesnt b***h anymore :D
<Mez> hyperactivecrond, not since the b******g was patched out of it :D
<Mez> lol
<Mez> :-" 
* hyperactivecrond is behind on patches like these
<hyperactivecrond> :)
<Mez> hyperactivecrond, use kubuntu :D
<hyperactivecrond> ive got kde installed under ubuntu...
<Mez> sorry
<Mez> use breezy *
* hyperactivecrond can wiat
<hyperactivecrond> s/wiat/wait
<doko> Mithrandir: Riddell wants to see you in pain ... ^^^ ;-P
<Riddell> Mithrandir: can I help at all with ia32-libs-kde?  (probably not but I thought I'd ask)
* hyperactivecrond slaps himself, because apparently he can't spell cdrdao
<Mez> elmo: I've got something that needs NEWing in backports (I think)
<Mez> elmo: well at least it looks like it needs NEWing
<Kamion> queue/new gets processed fairly often, please don't get into the habit of asking every time unless it's really urgent
<Mez> Kamion: including backports?
<Mez> (which should use breezy's files?)
<Kamion> yes, including backports
<Mez> Kamion: fair enough :D
<Kamion> in any case nothing in queue/new is targeted at hoary-backports
<Mez> o_O
<Mez> then why is something listed as "unknown" in the backports list?
<Mez> unknown/libevent_1.1a-1~hoary1: Installed by buildd+rothera [-:uncompiled] 
<elmo> dude
<elmo> I've explained this to you
<elmo> this is not a package being NEW
<elmo> the problem with the previous packages was a config file SNAFU; if more packages have become 'unknown', it's a bug and I'll look at it
<elmo> but please don't call them NEW, it just confuses everyone and everything
<Mez> elmo: sorry 
<Mez> elmo: I was probably tired last time: noted and remembered for future
<elmo> daniels: pls DTRT with section + priorities for these libs you're splitting out
<elmo>  libevent1 | 1.1a-1~hoary1 | hoary-backports | amd64, i386, powerpc
<elmo> Mez: AFAICS, it's compiled fine
<xerox> Why are breezy livecd only for PPC and AMD64
<elmo> Mez: wanna-build won't update the section of Installed (i.e. compiled) packages, so the unknown/ there is just a historical footnote
<elmo> Mez: if you have any examples where the package actually isn't compiled, pls let me know
<Mez> elmo: ack
<xerox> OK found, the live is only for PPC and AMD64 it seems, thanks anyway :-)
<daniels> elmo: anything I've broken?
<daniels> elmo: or just a general pointer?
<ogra> xerox, x86 will follow soon
<elmo> daniels: general pointer, it's totally minimal priority, just midly annoying to have to override them to the correct ones
<xerox> ogra, great - I'm trying an external USB hd installation, I hope it will go fine! :)
<daniels> elmo: 'kay, will do
<mbreit> elmo: thanks for whitelisting me and for syncing drpython for me!!
<ogra> xerox, i dont know an ETA.... 
<elmo> mbreit: np
<xerox> ogra, what is ETA?
<Kamion> xerox: the i386 live CD is just temporarily broken that's all. If you use dailies, you should *expect* temporary breakage
<ogra> xerox, Estimated Time of Arrival
<lamont> ./minigzip: error while loading shared libraries: libfakeroot-sysv.so.0: cannot open shared object file: No such file or directory
<Nafallo> what's keeping libdc0? it's not in the archive for i386, but ppc and amd64 is.
<lamont> hrm... zlib and amd64 don't seem to like each other
<xerox> It wasn't a complain - I didn't mean to sound harsh, sorry!
<lamont> Nafallo: what's libdc0?
<lamont> as in, what package?
<lamont> source package
<Kamion> lamont: terranova is still the right buildd for the live CDs, isn't it?
<xerox> In fact I didn't need the live cd, but the installation one, which is there, so thank you very much.
<Nafallo> lamont: source :-)
<lamont> Kamion: yes
<Kamion> lamont: 'cos it's down
<lamont> yeah. there is that.
<Nafallo> lamont: after it's built on i386, could you give back valknut?
<lamont> universe/net/valknut_0.3.7-1build1: Installed by buildd+rothera [optional:out-of-date] 
<lamont> no
<lamont> can't give them back when they're installed
<mvo> Kamion: I would like to upload the improved gnome-app-installer, I guess I need approval. it contains quite a few changes but it's needed to get the FindingPackages spec forward
<Nafallo> ah, it already built :-P
<Kamion> mvo: if it's required for a feature goal, I think we can trust your judgement on that :-)
<mjg59> jbailey: Hmm. You don't seem to have uploaded the new initramfs-tools yet
<mvo> Kamion: thanks :)
<Mez> mvo: have you spoke to Amaranth about that at all - there was a conplict between it and pyxdg 
<pitti> daniels: do you know where I can find a spec of dbus .service files?
<Amaranth> Mez: niran's g-a-i uses pyxdg 0.14, just like smeg
<mvo> Mez: isn't that only a problem in the backports repository?
<pitti> daniels: ah, nevermind, I finally found something (that always happens right after asking, doesn't it?)
<daniels> pitti: heh
<pitti> daniels: "FIXME the file format should be much better specified than "similar to .desktop entries""
<Mez> mvo: oh, didnt know it was backports specific !  :D
<daniels> pitti: haha
<Amaranth> Mez: that's ok though, smeg isn't even installable in backports
<jbailey> mjg59: Whups, done now.
<Mez> Amaranth, well, if you told me what was needed, then i could sort it out
<jbailey> mjg59: Hopefully it'll make :33
<mjg59> jbailey: Heh. Thanks!
<Amaranth> Mez: a pyxdg backport with a versioned conflict
<Amaranth> against the g-a-i in hoary
<Amaranth> but someone said the pyxdg conflict wouldn't be accepted for a new version in breezy main, at least not with just that
<Amaranth> so i'll need to see about getting it in when seb128 makes an 0.15 package (if i ever get lanius to release)
<Mez> Amaranth, why cant g-a-i be backported too/
<Amaranth> oh, it actually does work in breezy
<Amaranth> ok, backport it too
<Mez> Amaranth, so you'd be happy with backporting both ?
<Amaranth> i don't really care about g-a-i, i've only had about 4 reports of it getting broken so most of my users don't use it
<Mez> mvo: can you see any problems with doing that
<Amaranth> so whatever you think will get smeg working again the fastest is good with m
<Amaranth> me
<Mez> Amaranth, g-a-i from breezy breaks hoary?
<Amaranth> no
<Amaranth> pyxdg from breezy breaks g-a-i from hoary, this is what we've been talking about the whole time :P
<Mez> but if both backported
<Mez> then we're fine :d
<Amaranth> hasn't been tested
<shackan> pitti, there are some example .service files in the dbus source package
<Amaranth> but as long as pyxdg gets backported i'm happy
<Mez> I need a memory implant
<Mez> mvo: can you poke me as soon as the new g-a-i is installed and I'll work with backports
<pitti> shackan: thanks
<Mez> Amaranth, wasnt there a problem with gnome-menus or something being the wrong version
* lamont -> office
<mvo> Mez: I'll upload g-a-i for breezy today
<Amaranth> Mez: well, smeg is a bit buggy with anything less than 2.10.2 (actually gnome-menus is buggy and smeg shows it for what it is)
<Mez> Amaranth, lol
<Amaranth> Mez: but i don't care since those bugreports will be filed against backports, not to me :P
<Mez> Amaranth, how buggy?
<Amaranth> and it better than users complaining in #ubuntu about smeg being uninstallable
<Amaranth> Mez: if you have xine installed editing your menus makes xine get it's own menu, things like that
<Amaranth> small chance of menus not showing up at all
<Amaranth> and things show up or don't show up in smeg that are or aren't in the menus, or they show up differently
<Mez> Amaranth, is there any harm in Bping gnome-menus ?
<Amaranth> you want to backport GNOME 2.11.91? good luck
<Mez> Amaranth, gnome-menus from breezy will build fine on hoary
<Lathiat> isnt the rule no libraries? :)
<Amaranth> Mez: it will?
<Mez> Amaranth - looking at the depends - yeah
<Amaranth> Mez: does it _work_?
<Mez> (well the B-D)
<Mez> Amaranth, I dont use gnome
<Lathiat> Amaranth: thats probably a no then ;p
<Amaranth> and i don't have hoary handy
<Mez> WANTED: very brave user with Ubuntu hoary who doesnt mind reinstalling
<Mez> (sorry amsg)
<hyperactivecrond> mez: ok
<Mez> hyperactivecrond, you're up for it ?
<hyperactivecrond> what does it entail?
<Amaranth> getting a new gnome-menus
<Mez> it entails installing a package i give you adn seeing if gnome breaks
<pitti> Mez: dchroot?
<Mez> pitti ... ?
<pitti> oh,
<pitti> then rather not
<hyperactivecrond> !adn
<Mez> pitti: last time i chrroted I managed to kill my OS
<Amaranth> if it works it'll work _perfectly_, if it doesn't it'll make GNOME not work unless you exercise some apt-foo
<hyperactivecrond> Mez, what's adn?
<Kamion> Mez: good effort
<Mez> s/adn/and
<hyperactivecrond> i'll do it Mez
<Mez> Kamion: huh/
<Mez> hyperactivecrond, gimme a mo to build
<hyperactivecrond> ok
<Amaranth> the one in breezy is so spectacularly better it's almost sad
<Amaranth> (sad that 2.10 could be that bad)
<carl2> will usplash be ready for Feature Freeze?
<mjg59> carl2: That's the aim
<carl2> mjg59: ok thx
<Mez> building
<hyperactivecrond> ok mez
<Mez> hyperactivecrond, you have to know that this may break your comp to the point where you have to reinstall hoary
<Amaranth> Mez: status?
<Amaranth> Mez: no it won't
<Mez> Amaranth, it may
<Mez> probably wont
<Mez> but, cover all bases
<Mez> so I cant be blamed if it does
* hyperactivecrond is fine with it
<Amaranth> Mez: it'll be a 'man apt_preferences' away from working again unless you're incompetent or evil :P
<hyperactivecrond> what is it though
<Amaranth> hyperactivecrond: new gnome-menus packages to go with smeg
<hyperactivecrond> smeg?
<Amaranth> hyperactivecrond: menu editor
<hyperactivecrond> ah.
* hyperactivecrond mainly uses kde, and has kdm installed as backup
<Mez> hyperactivecrond, what Arch are you on - i386 i hope?
<Amaranth> hyperactivecrond: with these your menus should update automatically (when you install something, remove something, or change something with smeg) and lots of bugs should be fixed
<hyperactivecrond> i386
<Mez> good
<Amaranth> hyperactivecrond: you do have GNOME installed, right?
<hyperactivecrond> yes
<hyperactivecrond> it's hoary after all
<Amaranth> kubuntu's last release was called hoary too
<Kamion> Mez: re arson changelog, in general you do not need to log when a MOM merge works fine
* hyperactivecrond understands that
<Kamion> you can generally also remove Scott's name, he doesn't mind :)
<hyperactivecrond> ok Mez: 1ce i install it, what do i do?
<Mez> Kamion: dch did that automatically :D
<Mez> (the scott thing)
<Kamion> yes, I know how dch works
<Kamion> you can remove it
<Mez> and I did the mom worked fine just to mention bddebian :D
<Kamion> "Resynchronise with Debian (thanks, Barry deFreese)."
<Kamion> we do a lot of merges, and cruft builds up quickly over time. :)
<Mez> hyperactivecrond, you try and use gnome
<hyperactivecrond> ok
<Mez> hyperactivecrond, make a dir in your home direcroty, and open a shell in it
<Mez> (make sure you're in an empty folder
<hyperactivecrond> ok mez
<Mez> wget -np -nd http://www.sourceguru.net/ubuntu/unstable -A .deb
<Mez> (run that)
<hyperactivecrond> ok
<hyperactivecrond> --11:56:52--  http://www.sourceguru.net/ubuntu/unstable
<hyperactivecrond>            => `unstable'
<hyperactivecrond> Resolving www.sourceguru.net... 69.93.132.250
<hyperactivecrond> Connecting to www.sourceguru.net[69.93.132.250] :80... connected.
<hyperactivecrond> HTTP request sent, awaiting response... 301 Moved Permanently
<hyperactivecrond> Location: http://www.sourceguru.net/ubuntu/unstable/ [following] 
<hyperactivecrond> --11:56:52--  http://www.sourceguru.net/ubuntu/unstable/
<Mez> sorry
<hyperactivecrond>            => `index.html'
<Mez> wget -r -np -nd http://www.sourceguru.net/ubuntu/unstable -A .deb
<hyperactivecrond> Connecting to www.sourceguru.net[69.93.132.250] :80... connected.
<hyperactivecrond> HTTP request sent, awaiting response... 200 OK
<hyperactivecrond> Length: unspecified [text/html] 
<Mez> (I forgot -r :P)
<hyperactivecrond>     [ <=>                                 ]  1,941         --.--K/s
<hyperactivecrond> 11:56:52 (416.50 KB/s) - `index.html' saved [1,941] 
<hyperactivecrond> sry!
<hyperactivecrond>  meant to /msg that to Mez
<Mez> and please, dont copy and paste here :D
<Mez> lol
<Amaranth> Mez: he'll want to install the -dev package too, to make gnome-devel installable
<Mez> Amaranth, it's all there :D
<hyperactivecrond> downloading...
<Mez> ah
<Mez> cancel it
<Mez> stupid thing
<hyperactivecrond> shit
<hyperactivecrond> k
<hyperactivecrond> rm -rf ./*.*
<Amaranth> eek, no
<hyperactivecrond> ok everything's gone in that dir
<daniels> guys
<Mez> just download everything from http://www.sourceguru.net/ubuntu/unstable/
<daniels> please do this somewhere else
<Mez> #ubuntu-testing
<hyperactivecrond> ok then
<mjg59> Argh. My epiphany has decided to start doing IPv6 lookups, despite not having an ipv6 interface
<bddebian> Howdy
* Amaranth wonders about kaffeine-xine's description
* mvo is away to play hockey
<infinito> elmo: ping??
<mdz> ogra: I have no idea why ldm doesn't work for you; I just tested with all the latest stuff and it works fine
<mdz> ogra: do you have non-ascii characters in your password or anything like that?  maybe there's some character set conversion happening somewhere
<ogra> mdz, i upgrded this morning, so i should be up to date too
<ogra> nope
<ogra> its just a plainword with a capital letter
<ogra> i'll try to track it o the server...
<ogra> s/o/on
<ogra> mdz, is nfsserver= supposed to be in /proc/cmdline ? its not for me
<mdz> ogra: upgrade to 0.45
<mdz> (just uploaded)
<ogra> ok :)
<mdz> ogra: the new greeter looks very nice, but still has the focus problem
<ogra> focus problem ? 
<ogra> if you hit tab you switch the entrys/button
<ogra> what else do you want ? 
<mdz> if the mouse moves out of the window, focus is lost
<mdz> I just want that window to have focus all the time
<ogra> ah, ok... i'll see what i can do
<Mez> elmo: can you sync libtagcoll1 from debian please?
<mdz> daniels: ping
<Nafallo> lamont: ping
<pitti> seb128: good news! libnotify on ppc improves
<ogra> hmm, where is the i386 buildd gone ?
<lamont> Nafallo: yes?
<seb128> pitti: cool, you talked about the issues with upstream?
<pitti> seb128: yes, and we solved the missing timeout
<seb128> how was that arch specific?
<pitti> seb128: now the timeout is wrong, but it does timeout now
<pitti> seb128: reading a bool instead of dbus_bool_t from dbus -> 32 vs. 64 bit (or so)
<Nafallo> lamont: what's up with libdc0? still MIA on i386. I have a valknut upload that will need that version :-).
<ogra> Nafallo, i'd guess the x86 buildd is down... there wasnt a build since a while....
<Nafallo> that would explain it indeed
<ogra> last build for i386: 14:18 GMT
<seb128> pitti: k
<seb128> pitti: is there any build log for security uploads?
<seb128> pitti: chpe asks for http://bugzilla.ubuntu.com/show_bug.cgi?id=13247
<xerox> wow, if you insert the breezy cd on hoary it finds it and asks if you want to upgrade - neat!
<pitti> seb128: they should be published after releasing them
<seb128> pitti: epiphany-browser (1.4.4-0ubuntu2.1) is waiting for something?
<pitti> seb128: hm, no
<pitti> not there
<pitti> lamont: are the build logs of security updates still available somewhere?
<seb128> pitti: <chpe> my guess would be that somehow the build was done without PSM support in ephy
<lamont> i386 buildd status: vernadsky: stopped,  terranova: hw down, rothera: $^%)(^(*^, now fixed
<lamont> pitti: if one has a login on sanae, yes
<pitti> seb128: hm, but it does work with valid certs
<lamont> pitti: tell me what log you want, and I'll toss it to you
<pitti> lamont: could you give the epiphany-browser (1.4.4-0ubuntu2.1) log to seb128 ?
<pitti> lamont: thanks
<lamont> which arch?
* lamont assumes i386
<seb128> i386
<Kamion> lamont: possibility of i386 live filesystem builds being moved?
<lamont> Kamion: not terribly difficult
<lamont> you want it on the now overloaded rothera, or the  possibly suspect vernadsky.
<mjg59> Right. Usplash is uploaded, but needs integration work.
<mjg59> And non-sucky artwork.
<lamont> then again, if oo.o2 trashes rothera, then I can restart vernadsky
<Kamion> lamont-away: um, nice choice there ;)
<elmo> why are you moving stuff?
<sladen> mjg59: what's the depencies?
<Kamion> elmo: terranova down => no i386 live CDs => unhappy mdz
<mjg59> sladen: initramfs-tools 0.15
<elmo> christ's sake
<elmo> I'm going to reboot it in an hour or so
<Kamion> ah, ok
<elmo> mdz should be more unhappy than the bloody kernel can't stay up
<elmo> but what do I know
* Kamion grins
<mdz> we have an unstable _i386_ kernel too now?
<lamont> so, ctl-q and ctl-w are really close to each other... :-(
<mdz> elmo: wtf kind of hex did you put on the DC?
<lamont> seb128: http://people.ubuntu.com/~lamont/epiphany-browser_1.4.4-0ubuntu2.1_20050728-1816-i386-successful.gz
<elmo> pfft
<seb128> lamont: thanks
<Kamion> lamont: are you considering things suspect because of the dpkg segfault?
<elmo> kamion: no
<elmo> infinity has got the dpkg segfaults reproducing on multiple machines
<Kamion> ok, good - I was going to say, I've reproduced them too
<elmo> some of which aren't even in the DC and thus fre of my curse
<lamont> Kamion: partially - but only because it was only happening on vernadsky.  turns out that rothera has been a shade idle for the past day...
<Treenaks> dpkg segfaults -- during install?
<Kamion> I don't know what I managed to do with libglu1-mesa-dev but it seems to be bad mojo
<elmo> lamont: dude, read #u-t; don't be hating on bernadksy
<Kamion> unfortunately purge->reinstall seemed to clear it up, unhelpfully
<elmo> vern too
<Treenaks> (if so, that would explain why it stops halfway through)
<Kamion> Treenaks: with a message like "segmentation fault", yeah
<seb128> pitti: "checking for /usr/include/mozilla/pipnss/nsIX509Cert.h... no"
<Treenaks> Kamion: no messages.. just hanging at the "Installing packages" screen
<Treenaks> Kamion: I did see a d-i segfault/reload/segfault/reload loop.. but that seemed to be related to battery operation vs AC power
<Kamion> Treenaks: see tty4
<Treenaks> Kamion: I'll check now
<Mez> #u-t ?
<seb128> pitti: I blame mozilla
<pitti> seb128: ah, so maybe a missing build dep or a file isn't shipped any more in the new version?
<Kamion> dpkg is probably phenomenally confused by the libgl1-xorg-dev uninstallability
<infinito> elmo: people tell me you're in charge for MOTUToSync, and i'd like to know if they will get synced before FeatureFreeze
<Kamion> somebody needs to take a tar of /var/lib/dpkg/info/ and the .deb that causes the problem before changes in the archive make it go away
<elmo> infinito: no one's asked me to sync anything
<seb128> pitti: it Build-Depends on mozilla-dev ... so I guess a mozilla change
<elmo> there's a sync procedure, and it doesn't involve a wiki page ...
<infinito> elmo: \sh told me to add gcfilms to MOTUtoSync and wait till u sync it
<infinito> elmo: i don't know the rules for this proccess
<Treenaks> Kamion: btw, should prism54 cards work during install?
<elmo> sigh
<pitti> seb128: yay, libnotify works on ppc now
<Treenaks> Kamion: I can't seem to get the interface up
<elmo> infinito: I'll talk to sh when he's back
<Kamion> Treenaks: don't they require restricted modules?
<seb128> pitti: rock!
<Treenaks> Kamion: it requires firmware
<seb128> pitti: still amd64 to go?
<Treenaks> Kamion: and that gets loaded
<Mez> talking of syncs :D can you sync libtagcoll1
<pitti> seb128: yes
<Mez> (please)
<infinito> elmo: ok thanks
<Treenaks> Kamion: I'll start reporting more bugs :)
<Kamion> Treenaks: I reported a kernel bug on that ages ago, actually
<Kamion> Treenaks: #1974
<elmo> Mez: please don't assign sync requests to me in bugzilla
<Mez> elmo: sorry
<Treenaks> Kamion: it's not that problem -- the card used to work fine in an installed system
<Kamion> ok ... although if the firmware gets loaded, I'm not sure what else could be going wrong
<jdub> mjg59: !!!!!
<Treenaks> Kamion: maybe the fact that it's cardbus?
<jdub> mjg59: ! ! ! ! !
<Treenaks> ah!
<mjg59> jdub: ?
<jdub> mjg59: usplash upload :)
<mjg59> Ha
<mjg59> It won't do a great deal as yet
<mjg59> Needs init script interaction
<mjg59> And I need to write the keyboard interaction code
<Treenaks> Kamion: firmware.agent[pid] : /proc//class/firmware/0000:05:00.0/ does not exist
<Treenaks> which indeed it doesn't
<hubW> since I upgraded to breezy, I lost \ | ]  } on my fr keyboard layout
<hubW> that's not nice
<hubW> I used to get them with the option (aka alt) key acting as mod1
<Treenaks> let's try current daily
<hubW> Treenaks: prism54, but which kind ?
<seb128> pitti: that's fixed between epiphany 1.4.6 and 1.4.7 by a configure change
<seb128> pitti: I'll get a patch and ping you with it
<Treenaks> hubW: the supported kind :) (smc 2835W cardbus)
<hubW> Treenaks: which version
<hubW> Treenaks: my 2835W works fine, but newer don't
<pitti> hubW: http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009421.html
<hubW> (one of the 2 I have, but the other is fried)
<Treenaks> hubW: ISL3890 if you mean that? the card works on an installed system
<luis_> mjg59: but is it pretty?
<luis_> mjg59: and does it cover up the ugly?
<mjg59> luis_: Currently? No.
<Treenaks> hubW: but it is broken in the installer
<mjg59> But it does cover up the ugly.
<luis_> ah-ha.
<luis_> where is this magic?
<mjg59> It'll be pretty once I have lovely artwork.
<Kamion> Treenaks: can you check if /sys is mounted?
<luis_> the liveCD is in desperate need.
<Treenaks> Kamion: it is
<mjg59> (Which requires someone who can actually draw)
<hubW> pitti: well, I'm case 3
<Kamion> SYSFS=$(sed -n '/^.* \([^ ] *\) sysfs .*$/ { s//\1/p ; q }' /proc/mounts)
<luis_> and I can get gnome-themed lovely artwork if it works :)
<Kamion> Treenaks: run that please?
<Treenaks> Kamion: I'm goign to try the current daily first
<Kamion> Treenaks: please
<Kamion> just run the above and tell me what's in SYSFS
<elmo> off the DC to look at terranova, FWIW, bbl
<Treenaks> Kamion: ok
* pitti reboots to amd64, brb 
<Kamion> Treenaks: although, what version were you trying to install before?
<Treenaks> Kamion: the sed expression tells me "no previous regexp"
<Kamion> ah, well that might do it
<Treenaks> but it _is_ in /proc/mounts
<Treenaks> sysfs /syssysfs rw 0 0
<Treenaks> sorry; sysfs /sys sysfs rw 0 0
<Kamion> that's very strange sed code; I'm wondering if it's a GNU extension
<Treenaks> (I was trying to install 20050807)
<Kamion> nothing relevant has changed since
<Kamion> grep '^.* [^ ] * sysfs .*$' /proc/mounts | head -n1 | sed 's/^.* \([^ ] *\) sysfs .*$/\1/'
<Kamion> that should work better
<Treenaks> Kamion: so you think the problem is that d-i sed doesn't understand a GNUism that does work on the "real" sed?
<Kamion> yes, d-i uses busybox sed, and I think that code above only works by accident anyway (the trick it uses isn't documented in the info pages)
<Treenaks> checking with grep
<Kamion> I'll fix hotplug shortly
<Kamion> thanks though, good catch
<Treenaks> I need to cleaar out my desk
<Treenaks> Kamion: could it also be that the kernel barfs on ACPI interrupts when there's no acpid?
<Kamion> Treenaks: that I don't know
<Treenaks> Kamion: my system just rebooted when the battery became full
<Kamion> I don't really want to have to put acpid into d-i
<Treenaks> Kamion: the kernel should probably just throw the messages away?
<Treenaks> instead of a spontaneous reboot
<Kamion> dunno, I'm not an ACPI expert
<Treenaks> mjg59: ?
<Kamion> most things would seem better than spontaneous reboot though
<mjg59> Mm?
<mjg59> No, running acpid should be entirely irrelevent
<Treenaks> mjg59: I'll try to reproduce in a moment
<Treenaks> oh cool, now debian-installer is in a killed/scheduling for restart loop again
<Kamion> insane
<Kamion> only real way to debug that is to boot with init=/bin/sh, edit /etc/inittab, change "/sbin/debian-installer" (not /sbin/debian-installer-startup) to /bin/sh, exec /sbin/init, then run /sbin/debian-installer by hand to see where it breaks
<Treenaks> Kamion: I'll tyry -- but first good news: the "grep" line works
<Kamion> Treenaks: good
<Treenaks> Kamion: the problem with the killed loop is that it's not really reproducible all the time
<Treenaks> ok, how do I debug it?  :)
<Treenaks> first on debconf-get debian-installer/framebuffer (Killed!)
<Treenaks> then initrd-kickseed (Killed!)
<Treenaks> then /lib/d-i/menu (Killed!)
<Treenaks> ah.. OOM
<Treenaks> my fault ?!
<Treenaks> 64M is not enough apparently.. but the machine has 192
* Treenaks curses his stick of 5-year old broken RAM
<Kamion> Treenaks: it's probably running into broken corrupt memory
<Treenaks> Kamion: not even that
<Kamion> 64M should be enough
<Treenaks> Kamion: one RAM module is not found by the BIOS 50% of boots
<pitti> seb128: uh, notification-daemon is ftbfs on amd64 (even without my patch) *sigh*
<Kamion> you can boot with mem=64M to force it
<Treenaks> Kamion: I removed the module.. but still.. out of memory
<Treenaks> Kamion: this is just after loading nic-firmware etc.
<Treenaks> (installing even)
<Treenaks> Kamion: anyway, blame it on hardware for now
<Treenaks> this explains the weird reboots too
<Treenaks> Kamion: I let the module cool down and now it works again
<seb128> pitti: grumpf
<shackan> hi charles
<shackan> chmj, ping :P
<chmj> shackan, pong 
<Treenaks> Kamion: (and it seems to be true: installer RAM needed is >64M when loading/installing all those modules/firmware)
<shackan> chmj, I've almost ported the hci-utils to dbus
<shackan> uh, bluez-utils I meant..
<pitti> seb128: "	main.cc:150: error: cast from 'void*' to 'dbus_uint32_t' loses precision"
<chmj> shackan, I don't follow 
<shackan> pitti, what are you doing ?
<pitti> seb128: it tries to cast a void* into a dbus_uint32_t
<pitti> seb128: I already tried to rewrite it using reinterpret_cast<> but it doesn't help
<pitti> doko: ping
<pitti> shackan: I fixed notification-daemon for ppc, now I debug it on amd64
<shackan> uh
<pitti> does anybody know how I can convert a void* into an int32 without g++ barfing?
<doko> pitti: pong
<pitti> doko: see above, it seems that g++ recently added a check for that
<pitti> doko: any idea how to circumvent it?
<doko> amd64?
<pitti> yes, and ia64
<pitti> void* is 64 bit there
<pitti> and casting into dbus_uint32_t loses precision
<doko> fix dbus :-)
<pitti> (don't blame me for the stupid code that even attempts this)
<pitti> doko: hm, (dbus_uint32_t)(dbus_uint64_t)value seems to work on ppc too :-)
* pitti curses at sloppy programmers
<shackan> wow
<shackan> what a split..
<doko> yes, the double cast works ... but don't ask me, if dbus is supposed to work then ...
<jbailey> Err.  Is a double cast just to control the way the compiler loses data?
<pitti> jbailey: I'm using it for that, yes
* jbailey sponsors a load of happy drugs for pitti.
<jbailey> pitti: 'cause thaht's just sick. =)
<pitti> in notification-daemon, they have a type field and a void* which is then casted appropriately
<bddebian> jbailey: Did you bring enough for everyone? :-)
<jbailey> bddebian: Yes, but they're illegal to import into the US, sorry. ;)
* jbailey hides.
<bddebian> Doh ;-)
* pitti takes a spoon of jbailey's crack, is happy and leaves n-d broken :-)
<bddebian> hehe
<mdz> tech board meeting in 10 minutes on #ubuntu-meeting
<pitti> uuh?
<pitti> I
<pitti> tought in 70 mins...
<mdz> er, yes, 70
<pitti> ah, ok :-)
<mdz> silly UTC offsets
<pitti> still time for dinner
<bddebian> 10 mins?  I thought ... Oh nm
<chmj> pitti: i have same casting problem, not-breaking-other-things-or-loosing-data solution?
<siretart> is fabbione the only sparc god in ubuntu?
<siretart> proll is an architecutre all package, which build depends on a package only available on sparc
<siretart> is there any possibility to get a proll binary package in breezy?
<jbailey> siretart: It depends what you're looking for.
<jbailey> siretart: A few of us have pretty solid sparc experience, but sparc is basically fabbione's baby.
<siretart> jbailey: the package I mean is 'proll'
<siretart> jbailey: it build depends on 'sparc-utils', which is only available on sparc
<siretart> jbailey: We need it for qemu, it depends on proll
<jbailey> Just sounds like the build-deps need to be tweaked to only b-d on sparc-utils on sparc...
<siretart> jbailey: I don't think that'll be possible in this case
<siretart> proll is a JavaStation PROM 2.x compatible replacement
<jbailey> Well, something in the dependancy chain needs to get changed.
<paolo_> hi
<bddebian> Hello paolo_
<paolo_> what to you suggest I could do if "I was unable to run your X session, I'm giving you an xterm failsafe" or similar, after breezy install?
<paolo_> (I am in that xterm now)
<siretart> jbailey: as said, as qemu is nowadays able to emulate sparcs, I don't think we have much choice with that dependency chain. :(
<paolo_> You probably thougth "do not use breezy" :|  But Ctrl+Alt+F1..F9 doesn't work... why?
<jbailey> siretart: Ah, is qemu like bochs but hoefully less sucky?
<siretart> jbailey: exactly
<jbailey> siretart: Creepy, how's the speed?
<siretart> jbailey: do you happen to know how long is fabionne still on holyday?
<jbailey> I don't, sorry.
<siretart> jbailey: I didn't test it myself, I cannot give numbers, sorry
<jbailey> But Fabio won't have a better answer for this I suspect.
<jbailey> Either sparc-utils wil lhave to be made to work cross-arch, or you'll have to do an ugly hack to fetch the pieces from sparc-utils after they're generated on a sparc.
<jbailey> The former solution is really the better one, although depending on how poorly written sparc-tools is, the harder one.
<siretart> jbailey: http://fabrice.bellard.free.fr/qemu/benchmarks.html for numbers for comparison qemu vs bochs
<jbailey> Thanks.
<siretart> hm. lets have a look at sparc-utils, then
<jbailey> siretart: Part of the trick with sparc-utils would be to disable anything that obviously doesn't make any sense cross-arch, and leave the useful tools in the package that gets built !sparc
<siretart> hm
<siretart> prtconf.c:33:28: error: asm/openpromio.h: No such file or directory
<siretart> you mean like that one? :/
<jbailey> Right.
<jbailey> *or* copy that file into the package itself.
<paolo_> ...at least the mousepad works :)
<jbailey> But that one sounds like it might not mae any sense off of the sparc box.
<siretart> hm. that could be really really tricky
<siretart> jbailey: do you think an offer for sparc hardware would help? ;)
<jbailey> siretart: An offer to whom? =)
<paolo_> oh, I launched gnome-session and it worked.
<jbailey> siretart: I don't know if Fabio is looking for extra sparc gear. =)
<paolo_> Tanks anyway :)
<siretart> jbailey: A friend of mine would like to offer sparc hardware and hosting for sparc buildds for universe
<jbailey> siretart: Ah, cool.
<Mez> psst - who's ben colins?
<mdz> Mez: BenC
<Mez> fair enough
<Mez> mdz: I see you've got AbsoluteBeginnerCommunity down as a breezygoal... that still the casE?
<paolo_> ok nice, any advice for setting up a correct keyboard layout ? :-)
<Mez> paolo_, support is in #ubuntu
<paolo_> Mez, ok thank you, sorry!
<siretart> is someone working on gcc-2.95 for breezy?
<Mez> 2.95?
<pitti> siretart: uh?
<jbailey> siretart: ToolchainRoadmap dropped it specifically.
<mdz> Mez: if it isn't in the table, it isn't a release goal
<mdz> gcc-2.95 can rest in peace
<Mez> mdz: fair enough - I was looking at your Wiki and stuff#
<jbailey> siretart: It was a rought decision given that we had to drop chill with it.. =)
<pitti> mdz: meeting now?
<ericseigne> hi all
<ericseigne> i've got a problem with debuild / debsign on my ubuntu, did you have the same ? (if i run "debuild" i've got a gpg error "gpg: problem with the agent - disabling agent use" but if i run debsign manually there is no pb, my gpg agent works well ...
<pitti> ericseigne: try debuild --preserve-envvar GNOME_KEYRING_SOCKET
<pitti> ericseigne: (or whatever env variable your gpg agent uses)
<pitti> ericseigne: debuild cleans the environment
<ericseigne> pitti: yes i've read it in man but i can't find any env var about a seahorse-agent ...
<pitti> ericseigne: try fakeroot dpkg-buildpackage instead of debuild
<ogra> mdz, 0.45 doesnt solve it for me... and no indication on the ssh server, the same messages...
<ogra> mdz, at least the server ip is detected fine now, thanks
<ericseigne> pitti: why ? debuild is more powerfull not ?
<pitti> ericseigne: btw, that's #ubuntu stuff
<Mez> Mithrandir, did you get round to guifications yet
<ericseigne> pitti: seahorse is "/tmp//seahorse-fWX3x1/S.gpg-agent" ... impossible to explain that to debuild ...
<doko> mdz: do you have some minutes for NetworkAuthentication?
<dieman> so
<dieman> who should i harass if im going to be moving my ubuntu mirror
<seb128> carlos: around?
<_d4vid> hi all
<paolo_> hyperactivecrond, hi :-)
<hyperactivecrond> :)
<paolo_> hyperactivecrond, the GNOME keymap selector doesn't do it, it report some error instead.
<paolo_> I'm having 2 troubles: after login I get a "cannot start your xsession" and it runs a failsafe xterm instead.  Not much a problem because "gnome-session" there load GNOME (i suppose) correctly.
<paolo_> The second one is about the keymap, even if I select it it does not work, the GNOME keymap selector reports an error, and loadkeys it doesn't change anything, any clue?
<pitti> paolo_: http://lists.ubuntu.com/archives/ubuntu-devel/2005-August/009421.html ?
<paolo_> pitti, I'm checking - thanks very much for the url.
<paolo_> maybe it helped, let relogin.
* paolo hugs pitti 
<paolo> pitti, thank you very, very much.  It's all fixed.
<pitti> paolo: :-)
<paolo> It's just great.
<edd> before i go chasing around, is anyone else seeing font weirdness in firefox/breezy ?
<pitti> edd: in particular?
<paolo> edd, what kind of weirdness are you thinking of?
<sivang> mdz: ping, update re:  lpint-bonnobo, lib is done, has gettext support although surely needs a review. gedit sample patch done, now I'm trying to test against an applet see if it fits it.
<edd> pitti, paolo: not using the same font as the rest of GNOME. not respecting my hinting preferences
<paolo> edd, it seems to use a more little font.
<paolo> I could be wrong.
<edd> paolo: here, bigger!
<sivang> mdz: evo integrability is next check
<paolo> You guys rock, anyway :-)
<sivang> mdz: patch method per app basically identical to liblaunchpad-integration0
<sivang> seb128: ping
<seb128> pong
<sivang> seb128: I finished the bonobo hlper lib, but I probably need some review
<seb128> k
<seb128> please mail it to me/jamesh
<sivang> seb128: gedit with patch for the new helper is ready, though not depend on it deb wise - I still didn't create a pkg for the new lib
<seb128> we don't want a new package
<seb128> that should be a part of launchpad-integration sources
<sivang> seb128: no, we talked about it and you said it would be better to seperate them - becasue bonobo will deprecate at the end
<sivang> seb128: and so to be able to seperatly drop it, this is best no?
<seb128> and?
<seb128> a source package can ship differents lib/binary packages
<seb128> make a different lib but put it to launchpad-integration
<seb128> we are not making a launchpad-integration-dup for it
<seb128> the source can ship 2 differents libs
<sivang> seb128: ah ok , cool :)
<seb128> and the package have 2 binary packages
<sivang> seb128: i have a killer latency here
<sivang> seb128: sure, no prob
<sivang> seb128: I'll email tommorow the whole tarball
<sivang> seb128: let me know if any problem with it
<seb128> k, np
<sivang> seb128: good night, gotta go sleep now :)
<sivang> good night all!
<seb128> thanks, later
* pitti can almost feel notification-daemon working on amd64
* seb128 hugs pitti
<Nafallo> pitti: yay! :-)
<ajmitch> morning
<paolo> Is it correct that there is no %adm line in /etc/sudoers?
<elmo> it's %admin by default
<paolo> In hoary it is "%admin ALL=(ALL) ALL", but here the user seem to be in the group adm.  Do I miss anything, or /etc/sudoers is wrong?
<Kamion> adm and admin are entirely different groups with quite different purposes
<elmo> this is really an #ubuntu question.. but the default install puts the first user in %admin
<Kamion> sounds like you've upgraded from warty
<paolo> Kaloz, I used the breezy cd from today (i386)
<Kamion> I'm Kamion, not Kaloz
<paolo> oops, sorry :-(
<Kamion> that would be a bug ...
<paolo> Tell me if I could provide more information.
<Kamion> oh, did you set a root password?
<paolo> It asked for a password in the install process, so I did.
<Kamion> you installed in expert mode, then. generally, don't do that unless requested
<paolo> OK, thank you very much.
<Kamion> if you set a root password during the installation, the installer assumes you know what you're doing and skips the automatic-sudo-for-initial-user stuff
<Kamion> although it's not documented (it should be), if you *are* using expert mode, you can just enter a blank root password to get the usual behaviour
<paolo> It was needed because I did an installation on an external USB2 harddrive.
<paolo> I'll just add the %admin line and the user to the admin group.
<Kamion> this is all bug #9832
<Kamion> right, that's fine
<Kamion> you might also need to actually create the admin group (addgroup --system admin)
<Kamion> also, it's a bug if you *need* to use expert mode
<paolo> What about adm group, finally?
<ogra> mdz, got it ! the prob is in ldm-askpass .... if i change from cat <<EOF ... EOF to echo $password, it works fine ...
<Kamion>     Group adm is used for system monitoring tasks. Members of this group can
<Kamion>     read many log files in /var/log, and can use xconsole.
<Kamion>     Historically, /var/log was /usr/adm (and later /var/adm), thus the name of
<Kamion>     the group.
<Kamion> paolo: ^-- (/usr/share/doc/base-passwd/users-and-groups.txt.gz)
<paolo> I wish I could lookup documentation that fast :-)
<Kamion> well, that documentation is in a package I maintain ;)
<paolo> heh!  Do you know how to add a user to a group, too? :-)
<Kamion> 'adduser <username> admin'
<paolo> OK, great.
<Mez> hmm, random question: whats a good distro for a small OS...  needs to have X, and Open GL, but fit as small as possible
<ogra> ubuntu-light ?
<Mez> how small can that get?
<ogra> ask vedran if he's around, he works on it and should be able to give you detailed numbers
<Mez> 64Mb?
#ubuntu-devel 2006-08-07
<kozz> Kamion: thanks man
<bluefoxicy> Ancient Debian lore once supplied black magic in the form of Sawfish or IceWM
<bluefoxicy> Masters of this magic could use a menu option to switch between Gnome, KDE, Sawfish, IceWM, and Fluxbox without killing the programs in their session.
<bluefoxicy> And it was good.
<zul_> uh...ok
<caravena> Hello, I'm finding in http://cvs.gnome.org/viewcvs/gnome-system-tools/ the glade.in of gnome-system-log. I do not find it.  Somebody knows as it is the file? 
* jdub tries nm again
<robertj> any ideas on how xrandr could be improved so as not to set unsupported refresh modes? I plugged in a new monitor, edited xorg.conf, and after logging into gdm, xrandr helpfully set my old (and unsupported) res
<bluefoxicy> doko:  ping
<bluefoxicy> Fine I'll just stay up until pitti /joins
* Fujitsu digs a pit under bluefoxicy.
<bluefoxicy> heh
* bluefoxicy is rebuilding bash with -DFORTIFY_SOURCE=1 to see what happens
<bluefoxicy> this is not working
<dholbach> good morning
<jdub> morning dholbach 
* dholbach hugs jdub
<dholbach> how's it going?
<jdub> teh rad
<dholbach> if i didn't know better, i'd guess you're trying to learn a new language ;)
<simira> good morning *yawns*
<Nafallo> morning simira :-)
<fabbione> morning
<Hobbsee> hi fabbione!  how goes it?
<dholbach> hellas fabbione
<fabbione> dholbach: do you have any idea what package is causing severe redrawing issues in edgy?
<dholbach> fabbione: what do you mean?
<fabbione> Hobbsee: pretty much ok i would say.. the baby is sleeping like an angel
<fabbione> dholbach: sec.. let me take a screenshot
<dholbach> fabbione: which video driver?
<fabbione> dholbach: nv
<fabbione> dholbach: it's not a video driver problem. It started before i did reboot the machine
<Hobbsee> fabbione: yay :)
<fabbione> and i was still using the old driver
<fabbione> dholbach: it smells like cairo/pango or some gtk
<dholbach> fabbione: i only know of the ati breakage and themes looking broken because they were not built with gtk 2.10 yet - but now we should have rebuilt all of them
<dholbach> but let's wait for your screenshot
<fabbione> http://people.ubuntu.com/~fabbione/corrupt.jpg
<fabbione> notice URL missing and buttons without names etc.
<fabbione> if i pass the mouse on top, they show up
<dholbach> ah, text gone missing
<dholbach> we had a bug about that
<dholbach> need to dig it out
<fabbione> dholbach: it happens on all gtk apps
<fabbione> or something..
<fabbione> xterm works :)
<fabbione> but basically i can't do anything with my machine atm
<dholbach> fabbione: do you have any idea about bug 50778? somebody in gnome land pinged me about it
<Ubugtu> Malone bug 50778 in Ubuntu "Installer (partitioner) fails on Sun T2000 rev. 2" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50778
<fabbione> dholbach: i wish i could read it :)
<fabbione> dholbach: i can't read the text in FF
<Nafallo> fabbione: w3m? :-)
<dholbach> fabbione: and you're completely updated? because i saw that "text gone missing" bug a week ago or something
<fabbione> dholbach: i don't have that hw.. so i have no clue. My t2000 is v1
<dholbach> fabbione: :-/
<fabbione> dholbach: i updated yesterday afternoon
<dholbach> ok
<fabbione> updating again now...
<fabbione> just for the sake of it
<dholbach> no, that shouldn't be it :/
<fabbione> dholbach: nope... doesn't help
<fabbione> dholbach: what was the package at fault for that text gone missing?
<dholbach> i'm trying to find it in malone
<dholbach> fabbione: I can only find bug 52445 - which is something else - I'll ask Sb once he's here - atm you could try if a different theme fixes the issue for you
<Ubugtu> Malone bug 52445 in libcairo "after upgrade the gtk library, when using someof fonts, display is missing." [Medium,Fix released]  http://launchpad.net/bugs/52445
<fabbione> hmmm cairo....
<fabbione> i could also try to downgrade that
* marilize hugs fabbione
<Burgundavia> fabbione: could we get a logging bot in #ubuntu-laptop?
<fabbione> hey marilize 
* fabbione hugs marilize 
<marilize> Burgundavia: hey mr Burger
<fabbione> Burgundavia: not without my workstation. Please file a bug and i will do when i am back from paternity leave.
<Burgundavia> fabbione: sure
<Burgundavia> marilize: 'ello
<fabbione> dholbach: different theme makes no diff
<dholbach> hrm :-/
<fabbione> or am i supposed to logout/login again?
<dholbach> no
<dholbach> heya pitti
<pitti> Good morning
<fabbione> Burgundavia: make sure the bug is assigned to me
<fabbione> dholbach: it's not libcairo either
<Burgundavia> fabbione: nope, going to assign it to Mark ;)
<dholbach> fabbione: did you have gtk 2.10 before? i mean - did you dist-upgrade regularly?
<fabbione> dholbach: no i did skip the last week 100% and upgraded only yesterday
<fabbione> dholbach: have been kind of busy :)
<dholbach> yeah, can imagine :)
<fabbione> i can try to downgrade gtk
<dholbach> no no no
<dholbach> there's too much stuff depending on it already :)
<sivang> morning
<dholbach> and that shouldn't be it, you must have had 2.10 before
<fabbione> dholbach: well it downgrades fine...
<fabbione> let me try
<dholbach> i mean to < 2.10
<dholbach> but i wouldn't try that
<fabbione> doesn't help either
<fabbione> it's a bit better
<dholbach> afaik that was something else - you have ubuntu-desktop installed?
<fabbione> ubuntu-desktop is already the newest version.
<dholbach> does firefox say something if you start it from the terminal? any fancy error messages?
<fabbione> nop
<dholbach> hrm
<fabbione> dholbach: i used FF but it's also xchat and other apps
<fabbione> gonna try something
<fabbione> brb
<fabbione> dholbach: it's Xorg bug
<fabbione> actually nvidia
<dholbach> uh
<dholbach> strange, i run 'nv' here myself
<fabbione> nv or nvidia?
<dholbach> nv
<fabbione> yeah nv works
<fabbione> nvidia doesn't
<dholbach> ahhhh
<dholbach> screw nvidia!
<fabbione> the problem is that nv doesn't support multihead
<fabbione> screw nv*
<crimsun> fabbione: some people have 'worked around' it by using Xgl; I believe amaranth and ajmitch have experience
<Nafallo> fabbione: I'm sure they would take patches ;-)
<fabbione> dholbach: can you check if l-r-m has been updated since xorg-server ABI breakage?
<fabbione> crimsun: that's probably because Xgl is still using the old ABI and it doesn't support multihead properly.
<fabbione> Nafallo: i did send them patches.. they are in some unknown queue in bugzilla.
<dholbach> fabbione: Jul 15, so I think not
<Nafallo> fabbione: oh :-/. but then you have nv doing multihead locally? :-)
<fabbione>  /ignore Nafallo*!*@* all
<fabbione> feh
<fabbione> ;)
<Nafallo> :-P
<fabbione> dholbach: i had that feeling
* fabbione attempts a local rebuild
<dholbach> heya mvo
<Hobbsee> hi mvo 
<simira> Nafallo :)
<simira> dholbach :)
<dholbach> hi simira :-)
<Hobbsee> simira!  hello!
<simira> hi Hobbsee 
<simira> hmm...
<simira> mvo: I suspect update-manager is stuck again. There can't have been no updates for a week, really?
<mvo> hello Hobbsee, simira :)
<mvo> simira: does it help if you manually click on the "check" button?
<pitti> Riddell: I committed your latest cdbs update to bzr; btw, there was no FTBFS, it just never built (the buildds have been on manual for quite some days)
<Hobbsee> hiya pitti 
<pitti> Hey Hobbsee 
<Hobbsee> pitti: which mailing list was the main uploads stuff on?  i still dont seem to have recieved email about that.  nor anything else from that list in a few days, come to think of it.
<infinity> pitti: Err, the buildds haven't been on manual.
<pitti> infinity: hm, you told so yesterday, didn't you?
<pitti> infinity: '.. keep the buildds free for dapper-updates' or so?
<infinity> pitti: Not unless I did it in my sleep.
<infinity> pitti: Oh, that was just "not doing any mass give-backs".
<pitti> ah, I see
<infinity> pitti: But new uploads were being built just fine.
<pitti> ok, then they are just lagging behind
<infinity> They certainly shouldn't be.
<pitti> sorry for the confusion then
* infinity pokes.
<infinity> http://librarian.launchpad.net/3801011/buildlog_ubuntu-edgy-i386.cdbs_0.4.44ubuntu4_FAILEDTOBUILD.txt.gz
<pitti> https://launchpad.net/distros/ubuntu/+source/cdbs/0.4.44ubuntu4 <= not built for two days
<pitti>  edgy i386   Needs building
<infinity> It failed.  The only reason it's needs-build again is because I just did a mass give-back.
<pitti> aaah
<bluefoxicy> oh wtf.  -D_FORTIFY_SOURCE=1 A) does absolutely nothing without a -O level; B) acts exactly like -D_FORTIFY_SOURCE=2
<bluefoxicy> pitti:  Is gcc modifying code going to be a problem for Edgy+1 or is it worth trying to get a look into using -D_FORTIFY_SOURCE when the time comes?
<pitti> bluefoxicy: is fortify upstream by now?
<bluefoxicy> pitti:  it's in Ubuntu if that's what you mean.
<pitti> bluefoxicy: sure, can't hurt to do some research about it and play with it
<bluefoxicy> bluefox@icebox:/tmp/x$ gcc -O -D_FORTIFY_SOURCE=1 test.c -o test
<bluefoxicy> test.c:13: warning: call to __builtin___strcpy_chk will always overflow destination buffer
<bluefoxicy> ^^^ except it turns strcpy() etc etc into __builtin___strcpy_chk()
<pitti> bluefoxicy: requires some evaluation of the performance hit, of course
<bluefoxicy> pitti: I can throw nbench at it but I don't think it'll do any good
<infinity> pitti: We still care about performance?  This is news.
<bluefoxicy> this is a case of "a few cycles on certain functions" and there's not good benchmarks for hitting these
* infinity has been convinced that since computers appeared to become "fast enough" several years ago, we've just been looking for clever ways to slow them down again.
<bluefoxicy> besides you can't quantify how often "certain functions" are being executed; it winds up being THEORETICAL_MAXIMUM / 1000000
<pitti> bluefoxicy: I don't mean 'measuring how many cycles the new functions waste', but rather 'will it make a noticeable difference'
<pitti> in overall system performance
<infinity> Java, mono, sandboxes, secure compilers...
<bluefoxicy> pitti:  in overall system performance I'm rather certain it doesn't.  Throw Fedora Core 5 on your box and see if you notice (yes FC5 is all FORTIFY_SOURCE and -fstack-protector)
<pitti> true
<bluefoxicy> heh, maybe I could get some quantity if I could make oprofile behave.
<bluefoxicy> I wanted to prove PIE doesn't cause a significant overall performance detriment; Theo de Raadt kept insisting it does and I wanted to prove I knew better than him *ego ego ego*
<bluefoxicy> so I got oprofile working and measured what was happening in libraries vs in main executables.   It takes 1% more CPU to run PIE on i386; Xorg spends 5% of its time in the main executable (overall 0.05% more CPU used); while everything else uses less than 0.02% of its time in the main executable.  Total system impact 8% * 1% == 0.08%
<bluefoxicy> infinity:  this is the impact of "secure compilers" mind you ;)
<bluefoxicy> pitti:  oprofile is supposed to be able to track individual symbols; I may be able to do a system-wide quantification of strcpy(), memcpy(), strncpy(), strcat(), etc etc.  Count the calls, CPU percentages, do the math, and find the exact performance impact\
<pitti> bluefoxicy: well, don't overdo it, but some field research can't hurt :)
<bluefoxicy> I overdid it last time
<bluefoxicy> left oprofile on, its data file grew to several gigabytes and my disk filled.
<bluefoxicy> :)
<bluefoxicy> problem is I have no idea how to get it to track symbols, and how to make the output useful.  I can try but if it bites me again no guarantees
<bluefoxicy> anyway it's 4am I need sleep.
<simira> mvo: it seems so
<pitti> infinity: weird; cdbs' tests all work in a clean pbuilder here
<pitti> infinity: and on my amd64 desktop, they almost all fail since automake uses INSTALL_PROGRAM_ENV for 'install -c' which is empty at the point of installation
<pitti> so, neither reproduces the buildd situation
<infinity> pitti: Sweet.  Want me to reproduce and investigate?
<pitti> infinity: if you can reproduce it locally, sure
<infinity> I'm sure I can.
<pitti> I'll spend some time figuring out the autoconf mess
* infinity populates a chroot..
<pitti> tsk, this can't *possibly* work...
<pitti> make INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)' install
<pitti> $(INSTALL_PROGRAM_ENV) $(binPROGRAMS_INSTALL) $$p $(DESTDIR)$(bindir)/$$f
<pitti> it's clear that $(INSTALL_PROGRAM_ENV) will generate an empty string, so that 'install -c' is not called, but how on earth is that generated?
<infinity> pitti: I get the same failure as the buildds.  Surprise, surprise.
<pitti> infinity: can you pleasea run the test by hand and see what breaks?
<infinity> How does one invoke them by hand?
<pitti> cd test
<pitti> ./autotools-1.sh
<mvo> Kamion: can you please sync scim-thai from debian? its NEW and not yet in edgy but important for the thai people
<pitti> or whichever test breaks
<infinity> pitti: By hand, it works.
* infinity grumbles.
<infinity> Oh, wait.  No.
<infinity> False alarm, I'm seeing two different things.
<infinity> What's this tar broken pipe all about?
* infinity ignores that.
<pitti> infinity: I see it everywhere in edgy when building packages
<pitti> (not only with cdbs)
* pitti ignores it as well
* Nafallo confirms
<infinity> Erm, right.  That test appears to pass, but claims a failure.  Changed output or something?
<pitti> infinity: pkg-create-dbgsym?
* pitti installs that and tries again
<pitti> infinity: since debhelper-2 tests -dbg creation
<infinity> dpkg -c $WORKDIR/../cdbs-testsuite-dbg_0.1_*.deb | grep -q /usr/lib/debug/usr/bin/main || return_fai
<infinity> l
<infinity> Yeah, that clearly fails.
<infinity> (edgy)adconrad@cthulhu:~/cdbs/cdbs-0.4.44ubuntu4/test$ dpkg-deb -c workdir/cdbs-testsuite-dbg_0.1_*.deb
<infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./
<infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/
<infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/share/
<infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/share/doc/
<infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/share/doc/cdbs-testsuite-dbg/
<infinity> -rw-r--r-- root/root        94 2006-08-07 08:23 ./usr/share/doc/cdbs-testsuite-dbg/copyright
<infinity> -rw-r--r-- root/root       160 2006-08-07 08:23 ./usr/share/doc/cdbs-testsuite-dbg/changelog.gz
<infinity> The package is empty.
<pitti> ok, I'm quite sure it's due to pkg-create-dbgsym; I'll take over then
<infinity> Except, it shouldn't be doing anything, cause it's told not to mangle.
<infinity> dh_strip debug symbol extraction: not doing anything since NO_PKG_MANGLE is given
<infinity> Does it not quite do "nothing", as one would hope? :)
<pitti> if you see that, then it is followed by exit 0...
<infinity> Oh, it is exiting instead of doing the -dbg stuff that dh_strip would normally do, perhaps?
<infinity> ie: It's doing a bit too much nothing? :)
<pitti> *headdesk*
<pitti> of course you are right
<pitti> silly me
<pitti> infinity: that means the recent packages haven't get stripped at all, I'm afraid
<pitti> infinity: oh, no, just the NO_MANGLE ones
<infinity> Right, just NO_MANGLE.
<infinity> Which is just some test suites, and some d-i stuff.
<infinity> And not a whole lot else, afair.
* pitti checks all the other 'exit's
<pitti> yep, the rest of exits generate FTBFS
<pitti> Kamion: hm, I don't get sound with the current dapper ppc/alternate install; did you see this as well? (snd-powermac was not loaded)
<pitti> Kamion: the module is not in /etc/modules; I don't have the previous installation any more, but I'm pretty sure it must be added there
<pitti> Kamion: (bug 55479 filed)
<Ubugtu> Malone bug 55479 in debian-installer "no sound with dapper point release candidate powerpc" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55479
<mvo> Kamion: can you also please sync thaixfonts from debian? this is also not available yet in edgy
<pitti> infinity: ok, new pkg-create-dbgsym uploaded, confirmed that cdbs works fine with that
* pitti grabs the brown paperbag for stupidity
<pitti> I go offline for some parallel 6.06.1 candidate test installs
<sabdfl> BenC, Kamion: OOPS with current dapper kernel inserting PCMCIA card reader with compactflash card
<pygi> sivang, poke poke
<sivang> pygi: hi
<pygi> hi, you have time sivang ?
<sivang> pygi: answering in PM
<ogra> Kamion, i have a minor regression in the dapper installer here ... i cant switch consoles anymore ...
<ogra> (d-i that is)
<Kamion> mvo: please file bugs and subscribe ubuntu-archive - I'm on holiday for the next two weeks
<Kamion> ogra: worked perfectly well for me - does it stop working at some point in the installer?
<dholbach> Kamion: Have some nice holidays!
<Kamion> thanks - just around low-level today to do the point release
<ogra> Kamion, i just wanted to check the chrot buildlogs for ltsp and noticed it... no idea if it worked before, i'll check with the next test
<Kamion> sabdfl: does original dapper oops too?
<sabdfl> Kamion: quite possibly
<sabdfl> it did with a different cflash card, yes
<sabdfl> mdz has that one for testing
<Kamion> ok, thanks
<lifeless> doko: is edgy going to do the python transition ?
<lifeless> or +1 ?
<Kamion> lifeless: edgy mostly already has
<lifeless> oh, awesome
<lifeless> so I can package a new thing with python-central ?
<Kamion> yes, please do
<lifeless> yippee
<Kamion> I've generally been rejecting or complaining about things in NEW that don't follow the new python policy
<Kamion> because we're going to need it to be in place when python2.5 arrives
<doko> lifeless: yes, and test with 2.5 as well ;)
<lifeless> all my packages have been updated in debian, courtesy of the nice NMU storm
<lifeless> mmm, maybe not all, but close to
<mvo> Kamion: ok, have a nice vacation!
<Fujitsu> infinity, are you around?
<Kamion> hmm, 55479 is potentially an interesting regression
<Kamion> I can see why that *might* have regressed
<ogra> bug 55479
<Ubugtu> Malone bug 55479 in debian-installer "no sound with dapper point release candidate powerpc" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55479
<Kamion> I made some register-module changes for sparc
<ogra> i can confirm/reject in 10 mins :) ppc test is nearly through
<Kamion> don't reject
<ogra> nah ...
<Kamion> deny if you like :)
<ogra> :)
<ogra> wron vocabulary ;)
<ogra> *wrong as well
<Kamion> pitti: 11:11 < Kamion> hmm, 55479 is potentially an interesting regression
<Kamion> 11:12 < Kamion> I can see why that *might* have regressed
<Kamion> 11:12 < Kamion> I made some register-module changes for sparc
<pitti> Kamion: thanks for the heads-up
<Kamion> OH
<Kamion> if [ "$ADD_TO_INITRD" = 1 ] ; then
<Kamion>         QUEUEFILE=$QUEUE/$MODULE.load
<Kamion> else
<Kamion>         QUEUEFILE=$QUEUE/$MODULE.initrd
<Kamion> fi
<Kamion> spot the logic error
<Riddell> pitti: cdbs looks failed to me https://launchpad.net/distros/ubuntu/edgy/+source/cdbs/0.4.44ubuntu4
<Kamion> we need to rebuild alternate install CDs for that - I'll fix
<Kamion> oh, shit, and I think we need to rebuild live CDs too :(
<Kamion> ubiquity uses register-module
<Kamion> we don't need a full retest of live CDs though, just boot-and-install one option
<Fujitsu> Ouch.
<Kamion> pitti: thanks for your eagle eyes
<pitti> Riddell: I figured it out with infinity, it was due to pkg-create-dbgsym
<pitti> Riddell: I fixed that, once it's in the archive, cdbs just needs a give-back
<Riddell> thanks pitti 
<Chipzz> just wondering... is anything happening with grumpy?
<Chipzz> or is that just a draft?
<pygi> raphink, hey hey
<raphink> hi pygi
<Kamion> oh, wait
<Kamion> we don't need to rebuild ubiquity - I never updated it to the broken version of debian-installer-utils
<Kamion> yay
<Kamion> pitti: also, sparc will thank you - I think that's why Dave Miller's install test failed
<Kamion> I was too tired to notice why at the time, I guess
<Kamion> Fujitsu: please don't assign ubuntu-archive to bugs
<Kamion> Fujitsu: by a quirk of malone, doing that takes it *off* the list we normally look at
<Kamion> Fujitsu: having ubuntu-archive subscribed is quite sufficient
<Fujitsu> Kamion, sorry. I forgot I was meant to subscribe, not assign.
<Kamion> np, fixed
<Fujitsu> Thanks.
<ajmitch> fabbione: your text problem is a definite nvidia driver problem that is known - apparantly some of the changes in the x.org 7.1 ABI was in the glyph ABI
* pitti -> offline for CD testing
<Kamion> ogra: have you or your team tested any of the Edubuntu live CDs for dapper.1? Testing/Current
<ogra> not yet ... working on it 
<Kamion> ogra: the Edubuntu install CDs will need to be rebuilt due to 55479, but it's probably reasonable to test them anyway; the delta for the fix is very small
<ogra> i'm nearly done with the istal CD tests so far
<Kamion> ok
<ogra> live is going a lot faster here ... :)
<ogra> 20mins vs. >1h
<pitti> infinity: pkg-create-dbgsym 0.7 is in the archive; can you please give-back cdbs?
<ogra> does the sync commandline tool trigger the same kind of syncing as umount does ?
<ogra> or is that different ? 
<ogra> i.e. could i force a sync on a vfat filesystem through calling sync ? 
<pitti> ogra: unmount only syncs the device, sync syncs *all* buffers (on all devices)
<ogra> pitti, yep, thats something i grokked already ...
<pitti> sync vfat seems to work
<ogra> the question is if i can trick a vfat device to have the contents in sync 
<ogra> cool
<pitti> ogra: you can remount readonly to be safe
<pitti> ogra: with just 'sync' there might always be processes which still write to it
<ogra> no i cant if it just unlug a device ;)
<ogra> *unplug
<ogra> i'm trying to implement ltspfs without all the lbus communication, since its not really needed ... ltspfs unmounts if there is no rw traffic, but doesnt show its unmounted to the user .... i want to replace that functionallity through a sync call
<pitti> Kamion: I guess you will trigger new dapper/alternate images soon?
<ogra> (calling sync instead of mount/umount all the time)
<pitti> Kamion: so we deliberately ship 6.06.1 with OO.o 2.0.2 now?
<bbrazil> ogra: you want the 'sync' mount option
<pitti> bbrazil: no, he doesn't really
<pitti> sync mount option sucks performance-wise
<bbrazil> yes, but it would appear to be what he asked for
<pitti> the 'flush' option would be appropriate here as well (http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0050.html)
<ogra> bbrazil, sync mount doesnt work with vfat devices due to a kernel regression afak
<ogra> i dont really care about performance though
<pitti> ogra: sync works, but not perfectly, and it's not a regressions
<pitti> s/s$//
<ogra> oh, ok
<ogra> what does "not perfectly" mean ? 
<pitti> ogra: the problem is that we do not speak about factor 2 here - we speak about factor 10 to 100, and that does make a difference :(
<pitti> ogra: it seems that a small amount of the writeback cache is not synced even with the 'sync' option
<ogra> ah, k
<pitti> ogra: i. e. if you mount sync, write a large file, then unmounting still writes stuff on the media
<pitti> ogra: but it's only a tiny bit, much less than the 'one-minute writeback phase' with async
<ogra> thats bad ... i need to be able to just rip out the device with as little dataloss as possible
<ogra> (preferably with none at all ;) )
<pitti> ogra: then you can really only use the sync option and live with a really sucking performance (not even to mention the drastically increased hard drive wearout)
<pitti> ogra: why can't you unmount properly?
<ogra> pitti, because i have no access to the actual machine ...
<ogra> the trick the ltsp guys use it to cache the content on the client side and to unmount on the server side if theere was no activity for 5 seconds
<ogra> so for the user the system pretends its stil mounted which in fact it isnt on the thin client 
<ogra> s/which/while/
<ogra> as soon as a new access happens, the device gets mounted again
<Kamion> pitti: trigger> yes, but not until I've rebuilt debian-installer against the fixed debian-installer-utils
<Kamion> pitti: OOo> yes, 2.0.3 had some regressions
<ogra> argh
<pitti> ogra: hm, why are you so concerned about unmounting file systems on the server? or do you mean 'file systems on the client side', like usb sticks?
<ogra> gnome-settins-daemon spills an error on the dapper update cd ....
<ogra> and the desktop doesnt come up at all ... :/
<ogra> pitti, yeah
<pitti> funny, I had this as well, until I noticed that I accidentially burned the edgy CD :)
<ogra> (the ltspfs "server" runs on the thin client :) )
<pitti> ah
<ogra> in the ltsp they have a complicated reoimplementation of dbus i'd like to avoid completely ...
<ogra> which does that mount/umount stuff 
<pitti> ok, back to CD testing. bbl
<ogra> in ubuntu i can just mount/umount -l from udev scripts ... no need for extra complication
<ogra> hmm, i didnt burn the edgy CD ...
<ogra> console says 6.06.1
<ogra> and lsb_release agrees
<ogra> hmm, .xsession-errors is full of alsa errors ...
<ogra> Kamion, seems i have no loopback device over here on 6.06.1
<ogra> argh
<ogra> ok, its the old bug with wireless devices where no essid was set...
<ogra> gnome-settings daemon doesnt work on th eliveCD either :(
<ogra> seb128, dholbach, did you test the new dapper packages ?
<seb128> ogra: for what?
<ogra> gnome-settings-daemon doesnt start on any of my 6.06.1 CDs here
<ogra> neither live nor install
<seb128> ogra: dapper-updates didn't get a new gnome-control-center for 7 weeks or something like that
<Kamion> can somebody else confirm/deny that?
<seb128> I've no issue on my dapper installation
<Kamion> and please clarify whether that's just a single architecture or all architectures
<seb128> but I didn't try 6.06.1 CDs (yet)
<Kamion> I didn't notice any errors from gnome-settings-daemon in my tests
<ogra> seb128, "Moniker has unknown moniker prefix"
<seb128> ogra: is that ltsp?
<ogra> no
<seb128> ah
<Kamion> and I have tested on all architectures
<ogra> the regular CDs
<seb128> that's the "clock is not correctly set" bug
<ogra> *sigh* 
<ogra> ok
<Kamion> oh, ibook thinks it's 1904? that would explain it
<ogra> right i'm in 1904 again
<seb128> that's not a regression
<seb128> that bug is here for ages now
<ogra> Kamion, sorry for the adrenaline ...
<ogra> seb128, yes, but i didnt think of looking for exactly that one ...
<seb128> hehe
<ogra> after i tricked myself with the missing essid again already :)
<Kamion> ogra: no worries
<Kamion> damn, missed the publisher with debian-installr
<Kamion> +e
* pitti_live tries very hard to test auto-resize (using an ext3 partition, which worked before) but fails
<Kamion> happy to debug why given /var/log/partman
<pitti_live> Kamion: chinstrap:~pitti/partman
<pitti_live> Kamion: I tried 'small swap + big ext3', 'small swap + big vfat', and on powerpc the additional mandatory bootstrap partition
<pitti_live> Kamion: ah, now it seems to work with vfat on powerpc
<Kamion> powerpc doesn't have the same annoying partition table limitations
<fabbione> ajmitch: so it seems
<ajmitch> fabbione: only reliable workaround is to disable RenderAccel, which doesn't seem to impact performance
<pitti_live> Kamion: right, but with just one swap and one ext3, autoresize should be possible on amd64, too? ISTR that I used this configuration earlier, but TBH I'm always a bit confused about autoresize
<fabbione> ajmitch: or switch to nv :)
<Spads> zul: ping
<zul> Spads: just got up :)
<Kamion> pitti_live: it's trying, but libparted is saying that that partition isn't resizable
<Kamion> perhaps it's dirty?
<ajmitch> fabbione: if only it were that easy, for us that use dualhead or more :)
<Spads> zul: haha, you EST?
<ajmitch> morning zul 
<zul> yep
<Kamion> if you search for resize_use_free in the partman log and look down a bit, you'll find this (excerpted) for your swap partition:
<pitti_live> Kamion: I created the partitions, rebooted, mkfs.ext3, and then started ubiquity (without another reboot)
<Kamion> parted_server: Read command: GET_RESIZE_RANGE
<Kamion> parted_server: OUT: 4096 1110380544 1110380544
<Kamion> and this for your ext3 partition:
<Kamion> parted_server: Read command: GET_RESIZE_RANGE
<Kamion> parted_server: OUT:
<pitti_live> ok, so maybe I should have rebooted another time
<Spads> I suppose EDT now
<Kamion> in fact, that happens when ped_file_system_open() fails
<Kamion> or rather, probe succeeds but open returns NULL
<Kamion> you may find a complaint in syslog about it or something?
<Hobbsee> Kamion: sorry to be a pain, but when is the knot 2 planned for release?
<Kamion> it could be a geometry problem
<Kamion> Hobbsee: I'm now on holiday and only here to do the dapper point release, so I don't expect I'll be doing it after all
<Kamion> Hobbsee: mdz/infinity are the people from the release team who're around this week
<Hobbsee> Kamion: ah okay.  enjoy your holiday :)
<Hobbsee> Kamion: fair enough
<pitti_live> Kamion: /lib/partman/recipes.sh: line 31: local: `-': not a valid identifier
<pitti_live> /lib/partman/recipes.sh: line 114: local: `-': not a valid identifier
<Kamion> pitti_live: parted hasn't changed since dapper, so it seems unlikely to be a regression
<pitti_live> Kamion: ^ this is unrelated?
<Kamion> pitti_live: that's known and harmless
<pitti_live> Kamion: right, I don't think it's a regression either
<pitti_live> I just wanted to test all combinations
<pitti_live> but it works on i386 and powerpc, so I think it should work here, too
<Kamion> at least, I *think* it's harmless - it's a difference between busybox sh and bash
<Kamion> pretty certain that that couldn't possibly affect resize_use_free, though
<pitti_live> Kamion: with the current test matrix, what's your feeling with the ubuntu coverage?
<Kamion> it doesn't cause partman-auto to crash, but it is possible that it could cause incorrect semantics; however IIRC I looked into it and decided it was OK
<fabbione> ajmitch: that did the trick
<Kamion> pitti_live: I think it's sufficient now (thanks for doing OEM!); we'll just need a quick retest with the respun alternate/server CDs
<pitti_live> Kamion: I'll test amd64/oem, but I don't want to waste too much time with testing all possible combinations of (normal,oem,server) x (auto-resize, erase, custom)
<Kamion> pitti_live: I wouldn't worry about it
<Kamion> literally three lines in oem have changed
<Kamion> and those are architecture-independent
<pitti_live> ok, so I could spare the time?
<Kamion> the partitioner has also not changed
<Kamion> yeah, I don't think it's productive to retest things we know haven't changed
<pitti_live> ok, then I just test this amd64/desktop/erase and finish the ppc/desktop/resize and call it a testing day
<Kamion> sounds good; but if I could persuade you to test the rebuilt powerpc/alternate when that's done, I would appreciate it
<Kamion> since you discovered the bug
<pitti_live> oh, sure
<pitti_live> then I can already reinstall my desktop box with edgy
<pitti_live> ok, rebooting, brb
<Riddell> rodarvus: any plans to fix the xinit install problem?
<Riddell> I'm not sure if Xsession man page should be in xinit or xorg
<rodarvus> Riddell, yes, I'm working on it right now
<rodarvus> (strangely it didn't happend on my local test build)
<Riddell> it'll leave you to it then :)
<Riddell> I'm getting it on my chroots
<tepsipakki> what is the correct prosedure to propose a package for dapper-updates? I know how to request a backport
<Kamion> subscribe ubuntu-release to some appropriate bug report
<tepsipakki> kamion: thanks
<tepsipakki> I was thinking of nfs-utils, but maybe it has changed too much for -updates..
<Kamion> -updates should be patches addressing individual bugs, not complete backports of packages
<tepsipakki> so backports it is, then ;)
<Kamion> if you can isolate patches that fix particular problems, those can certainly be considered for -updates
<tepsipakki> ok I'll try and see. nfs-utils was practically unmaintained for a year, but it has progressed a lot since (and a vast number of debian bugs closed)
<tepsipakki> so isolating patches might be difficult
<Chipzz> could we include nfs-common in the default install btw?
<Chipzz> nfs mounts do not work without it
<rodarvus> thats most interesting: our old 'xinit' had an old debian/xsession directory, containing stuff which was later moved to x11-common
<rodarvus> but (for unknown reasons) these files apparently weren't present on old version of xinit
<rodarvus> when I updated xinit last week (only a minor upstream release with fixes to startx.c), these files were picked up and packaged during the build process
<rodarvus> anyhow
<rodarvus> Riddell, xinit is uploaded, thanks
<Riddell> rodarvus: you rock
<rodarvus> Kamion, whats the current situation for uploads to dapper-updates?
<rodarvus> I mean, can I upload a (non-security) update of xorg-server?
<bddebian> Howdy
<raphink> hi
<raphink> where can I find infos about the way seeds work?
<raphink> in ubuntu
<janimo> raphink: some info is at https://wiki.ubuntu.com/SeedManagement
<raphink> thanks janimo :)
<sivang> anyone has idea what happend to emacs's fonts with edgy?
<ogra> Kamion, apart from the known stuff on ppc are all eubuntu install CDs good
<ogra> *edubuntu
<janimo> Kamion: Xubuntu desktop CD 20060806.1 good as well
* ThunderStruck wonders how you people are burning them :(
<ogra> with a burner app
<ogra> and a CD writer device :)
<Nafallo> rightclick -> burn? :-P
<ThunderStruck> ogra: it will only allow me to burn as root. cdrecord permissions cant be changed (so it said in k3b) i tried with k3b gnomebaker and natilus
<ogra> strange are you in the right groups for the device ? 
<ogra> works flawless here with nautilus
<ThunderStruck> should be but hold on let me check
<ThunderStruck> im in the cdrom group
<pitti> ThunderStruck: I have the same effect in current edgy; the dapper version works flawlessly
<pitti> ThunderStruck: this is on my list of 'things to check out'
<ThunderStruck> ok ty pitti  so its edgy not me
<pitti> ThunderStruck: right, it's a long-standing upstream bug
<ThunderStruck> ok cool ty
<ogra> pitti, i just saw bug buddy again, wasnt your bug tool supposed to override that ? 
<pitti> ogra: no, it won't/can't
<ogra> ah, k
<ogra> so we'll stay with bug buddy for all gnome apps ? 
<pitti> ogra: if we want to use apport for everything, we have to remove bug-buggy
<hussam> I just found this. https://lists.ubuntu.com/archives/edgy-changes/2006-August/003472.html
<pitti> bug-buddy, even :)
<pitti> ogra: no, probably we'll remove it
<hussam> will there be a openoffice 2.0.3 update for dapper?
<ogra> ah, cool
<mdke> hushave a look on the -devel list about OOo packages for dapper
<mdke> ah, damn he has left
<Kamion> rodarvus: you can upload it, but (unless you argue persuasively) I'd prefer not to accept it until after the point release is done
<Kamion> ogra: great, thanks
<Kamion> ogra: can you mark your tests on Testing/Current please?
<Kamion> janimo: great, thanks
<pitti> argh, setting up edgy is such a PITA :/
* pitti fixes his X server harder, brb
<tepsipakki> kamion: is #55509 too late for 6.06.1?
<tepsipakki> bug 55509
<Ubugtu> Malone bug 55509 in apt-setup "dapper: if multiverse is enabled, add it also to security" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55509
<Kamion> tepsipakki: yes, I think so
<rodarvus> Kamion, don't worry, I'll upload it later, then - thanks!
<tepsipakki> Kamion: ok, np
<Kamion> it can go in edgy, but doesn't seem enough of a showstopper to hold the boat back on 6.06.1 now
<tepsipakki> of course not
<pitti> Kamion: I need to leave soon for supermarket/dinner/Taekwondo; do you plan to generate new alternates today? If so, I will test this tonight, otherwise I won't bother getting to my computer again after sports
<Kamion> pitti: yes, I do, but I need to wait for the end of the publisher run currently in progress
<pitti> ok, cu later
<Zdra> is it possible to have .deb files of builded packages that hasn't yet be published ? for example this package on i386: https://launchpad.net/distros/ubuntu/edgy/+source/cohoba/0.0.2-0ubuntu1
<Kamion> Zdra: no, sorry
<Kamion> Zdra: I've processed cohoba through the NEW queue now though, so it should be on the mirrors in about an hour and a half
<Kamion> dholbach: please make cohoba conform to the new python policy
<Zdra> Kamion: ok thanks
<dholbach> Kamion: will do
<azeem> will Ubuntu have a presence at the Systems expo in Munich this fall?
<co1> rodarvus the xinit patch unfortunately donsn't work, Xseesion.options.5.gz is also in x11-common. Can you reopen that bug?
<rodarvus> co1, I don't have Xsession.options.5.gz on x11-common, what version of this package do you have?
<co1> rodarvus:  xinit (1.0.2-0ubuntu2)
<rodarvus> co1, I mean, version of x11-common
<rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/xorg-server/xorg-server-1.1.1/debian/patches$ dpkg -s x11-common | grep ^Version
<rodarvus> Version: 1:7.0.22ubuntu7
<rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/xorg-server/xorg-server-1.1.1/debian/patches$ dpkg -S Xsession.options.5.gz
<rodarvus> xinit: /usr/share/man/man5/Xsession.options.5.gz
<rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/xorg-server/xorg-server-1.1.1/debian/patches$
<dholbach> Kamion: fixed it
<Kamion> dholbach: thanks
<dholbach> Kamion: thank YOU
<co1> rodarvus: x11-common..22ubuntu7
<rodarvus> co1, please paste in a /msg window the contents of "dpkg -L x11-common"
<rodarvus> also dpkg -s x11-common
<rodarvus> co1, I think I found it, thanks
<co1> rodarvus: sorry i'am a little bit lame :-(, did you need more informations?
<rodarvus> no, actually you are correct. I have just uploaded xinit_1.0.2-0ubuntu3
<rodarvus> I still wonder why my version of x11-common hasn't these manpages installed
<rodarvus> I also wonder why our old xinit packages wasn't installing the manpages (the rules to install them are on the package)
<rodarvus> my changes to xinit were only a new upstream release, I didn't touched the debian/ infrastructure
<Kamion> argh, I've been building edgy images, not dapper ones
<Kamion> sigh
* Kamion ctrl-cs and starts again
<LaserJock> how does ubiquity know what to install? does it use the seeds?
<jdub> LaserJock: ubiquity installs the livecd image, and the removes stuff :-)
<LaserJock> hmm
<LaserJock> via filesystem.manifest-desktop ?
<Kamion> yes
<Kamion> removes ((filesystem.manifest - filesystem.manifest.desktop) - anything-explicitly-kept)
<Kamion> where anything-explicitly-kept includes stuff like language packs for the selected language
<Kamion> also removes kernels that aren't for your subarchitecture (not relevant on i386, but is relevant on powerpc)
<LaserJock> Kamion: thanks
<Kamion> filesystem.manifest-desktop is basically just some dpkg-query invocation just after the desktop is installed
<Kamion> and before the live seed is installed
<LaserJock> interesting
<Kamion> the hardest bit's the python-apt code to do the removal with progress and stuff, really. the logic is very simple.
<Kamion> see scripts/install.py:remove_extras() in the ubiquity source
<Kamion> pitti: Ubuntu alternate 20060807.1 ready for testing; others are on their way
<desrt> pitti; hello, goodbye, hello, goodbye
<mvo> iwj: I think we can close bug #19834, we have freetype 2.2.1 now in edgy that should be ABI compatiable with 2.1.7. if you don't mind I will close it
<Ubugtu> Malone bug 19834 in freetype "gworkspace.app: Loader error when launching GWorkspace" [Unknown,Fix released]  http://launchpad.net/bugs/19834
<dholbach> good night everybody
<Surak> Hello
<Surak> I have a strange bug. The machines containing a intel integrated graphics won't boot if there's a nvidia agp card plugged on. It's bug #55104
<Ubugtu> Malone bug 55104 in linux-image-amd64-generic "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  http://launchpad.net/bugs/55104
<Surak> One solution would be to detect the presence of both hardware and blacklist the intel_agp module. But at the time you can do this, the hard drive is still mounted as read-only. So what could be done? Anyone?
<mjg59> You can do mount / -o rw,remount
<Surak> This bug prevents these kind of machines from booting. To prevent creating another script at boot, a solution is to blacklist intel_agp always. This would make 3d on machines without the nvidia useless. What would the best thing to do?
<mjg59> Fix the nvidia driver
<Surak> so the best thing is to send the bug upstream? This is happening with stock dapper & edgy live cds.
<mjg59> It sounds entirely like an nvidia bug
<mjg59> And, sadly, we don't have the source code to fix it
<Surak> I didn't know that live cds were being shipped with nvidia's closed source module.
<msikma> Hi guys
<msikma> I'm a participant of the Ubuntu art team and was wondering if there are any developers here willing to volunteer to help us out with some UI building.
<msikma> (Not right now, but in the near future.)
<msikma> We've got some nice stuff going down, but it's more useful actually being usable in the system as opposed to just being an uploaded PNG. :)
<Surak> mjg59: ain't the nvidia modules on live cds the gpl ones? The package which it belongs is the linux-image-amd64-generic
<mjg59> saispo: Which nvidia modules?
<mjg59> Erm
<mjg59> Surak: Which nvidia modules?
<Kamion> Surak: linux-image-amd64-generic is just a metapackage with no content, by the way, which is why I reassigned to linux-source-2.6.15. Please file Dapper kernel bugs on the latter in future so that they actually get seen by the right people
<Surak> Kamion: this is still a bug on today's edgy. Should I post it twice?
<Kamion> (linux-image-amd64-generic -> linux-meta source package which is no more useful)
<Kamion> Surak: I think the kernel people are capable of shifting patches around for themselves
<mjg59> Surak: There are no gpled nvidia modules that would be loaded in this situation
<Kamion> Surak: but if you want, open a new task on linux-source-2.6.17, not a new bug; you do this by selecting "Also affects: Distribution ..." on the bug page
<rodarvus> mvo, note that freetype 2.2.1 is API compatible with 2.1.7 only to a point (if you use only public headers)
<Kamion> Surak: oh, and furthermore, if it's the nvidia kernel driver, then that's actually linux-restricted-modules-2.6.{15,17}
<rodarvus> I also believe these changes made it ABI incompatible with 2.1.7 (again, if you use non public headers)
<Kamion> rodarvus: I think one of the problems was that functions were public in 2.1.7 that shouldn't have been
<Kamion> at least that was my understanding after trawling through some massive bug report on the subject
<rodarvus> Kamion, indeed, they shouldn't be public
<Surak> mjg59: I don't know what nvidia stuff is loaded at livecd's boot. What I noticed is blacklisting intel_agp makes the machines work. As it locks quite early without it, I don't know which nvidia module could be the culprit.
<rodarvus> but many projects used these functions: X, OpenOffice.org, pango (?), etc
<Kamion> if blacklisting intel_agp makes it work, why is it an nvidia bug not an intel_agp bug?
<Surak> I didn't say it is.
<rodarvus> mjg59, Kamion: I might be wrong but couldn't this be a bug in X pci detection?
<mjg59> Kamion: Because the nvidia driver likes poking with AGP registers even when there's already a driver bound to it
<mvo> rodarvus: you refer to the gworkspace.app bugreport? at least that particular problem seems to be fixed in edgy with the debian merge
<mjg59> I guess the alternative is that intel_agp is broken on 64-bit and explodes when the nvidia driver tries to initialise it
<rodarvus> I'll upload a new version of xorg-server in a few hours (as soon as I finish test-building it locally), which has a fix for X pci detection
<mjg59> But you'd expect that to happen with the intel graphics as well, then
<rodarvus> mvo, no, I only meant to talk about freetype abi itself :)
<rodarvus> (actually, I didn't even read this bug)
<mvo> rodarvus: heh :) ok
<mjg59> Ok.
<mjg59> Now that i386 is using vesa for the usplash stuff, loading vga16fb on boot is probably unhelpful.
<mjg59> How would people feel about me removing that?
<crimsun> go for it
<Surak> mgj59: what could be done then? If we can't fix the driver, disabling it (or nvidia_agp) is the thing to do. But how to make this become a default behavior for this specific hardware combination?
<mjg59> Surak: nvidia_agp isn't for nvidia cards. It's for nvidia motherboards.
<mjg59> It won't be getting loaded here.
<Surak> sorry, I mean intel_agp
<Surak> typo
<mjg59> By default, the nvidia driver isn't used or loaded
<mjg59> So it's not a problem on a cleanly installed system
<mjg59> (Assuming that the behaviour is as described in the bug)
<Surak> Then it's not the nvidia module the culprit.
<mjg59> Ok
<Surak> I'm talking about the live cds - dapper and edgy, unmodified.
<mjg59> That needs noting in the report, then
<mjg59> Kamion: We only use nv on the live CDEs, right?
<Surak> I could make the machine to boot by installing it on hard drive without the nvidia board, and then blacklisting intel_agp before inserting the card.
<Kamion> mjg59: we install the restricted modules as well, though AFAIK not nvidia-glx. I imagine it's up to the kernel's modaliases what gets loaded
<mjg59> I don't /believe/ the nvidia module has modaliases
<mjg59> Let me check
<mjg59> Oh, hrm.
<mjg59> Maybe it does. That sucks.
<Nafallo> infinity: ping :-)
<Nafallo> infinity: unping
<Nafallo> gnight :-=
<Nafallo> :-)
<Surak> unping? :-)
<Lure> if build failed due to dependancy (like kdeutils due to xinit: https://launchpad.net/+builds/+build/235022), will it get rebuilt automatically now that fixed xinit is in archives or does somebody need to request build again?
<Lure> s/dependancy/dependacy failing to install in chroot/
<Kamion> Lure: if it failed as opposed to going into dep-wait, which it did, then it needs to be manually retried
<Kamion> Lure: however, infinity's going to do a mass give-back once the dapper point release is done
<Kamion> Lure: so I wouldn't worry about manually requesting one
<Lure> Kamion: ok, thanks
<mjg59> rodarvus: Hm. We're going to have to add the Alps patches back to xserver-xorg-input-synaptics
<mjg59> I'll look at bringing them up to date
<rodarvus> mjg59, appreciated!
<rodarvus> I couldn't find where they were created from
<mjg59> I wrote them
<rodarvus> mjg59, oh, nice
<rodarvus> mjg59, thanks!
<pitti> Hi again
<pitti> Kamion: downloading new ppc alternate now and testing
<seb128> pitti: morning :p
<pitti> hey seb128
<shogobg> Hello all
<seb128> pitti: still testing CDs for the dapper updatE?
<mvo> hi pitti
<pitti> seb128: yes, I was waiting for the updated alternate ones to test the powerpc sound regression fix
<seb128> hey mvo :)
<pitti> and it wasn't available when I left for taekwondo
<seb128> ah, k
<pitti> moin mvo
* pitti greets the late night h4ckerz club
<mvo> pitti: I'm testing my update-notifier modifications right now but I can't make apport write crash reports right now
* mvo waves to seb128
* seb128 hugs mvo
<pitti> mvo: echo hallo | sudo tee /var/crash/foo.crash? :)
<pitti> mvo: and some chmod/chown, of course
<pitti> keescook: ping
<mvo> pitti: I wrote some mini-segfault application, but for some reasons those crashes are not recoreded
<pitti> mvo: why not just 'cat' in one shell, and 'killall -SEGV cat' in another?
<pitti> mvo: the reason is that I ignore crashes from executables which do not belong into a package
<mvo> pitti: aha, ok
<mvo> nice!
<pitti> mvo: so that we do not get millions of reports that we aren't responsible for :)
<mvo> makes sense :)
* pitti hands mvo the Big Killall Axe
<pitti> ... and the titan gloves :)
* mvo wields his sword +3 against bugs
<keescook> pitti: pong
<jono> hi folks
<HarrySprocket> hello
<Surak> hello
<HarrySprocket> is this where ubuntu is created?
<Surak> here is where people discuss it. which probably is a 'yes' to you :-)
<Surak> it is not a tech support channel, tough.
<HarrySprocket> I'm banned from #ubuntu want to be unbanned lol
<Surak> Unfortunately, I don't think this is the channel to discuss this.
#ubuntu-devel 2006-08-08
<HarrySprocket> Is everyone in here paid?
<LaserJock> hehe, I wish ;-)
<LaserJock> most are not
<bmonty> LaserJock gets paid though
<LaserJock> bmonty: what? I get paid with bug reports :-)
<HarrySprocket> .I'm a ubuntu user from NZ!
<sladen> HarrySprocket: nope.
<bmonty> LaserJock: that is currency in MOTU-land, right?
<LaserJock> HarrySprocket: you need to get ahold of an IRC op for #ubuntu to get yourself unbanned
<HarrySprocket> ok
<LaserJock> bmonty: sure, sure ;-)
<HarrySprocket> I have some ideas for ubuntu
<LaserJock> great, write a specification on the wiki detailing all the implementation plans and announce it on the ubuntu-devel mailing list
<LaserJock> make sure to include background and use cases
<LaserJock> HarrySprocket: pm Madpilot about your #ubuntu ban
<LaserJock> HarrySprocket: join #ubuntu-ops to talk about your ban
<pitti> Kamion: test install just finished on ppc, and I hear rockin' sound \o/
<pitti> Kamion: that means, no more regressions from my side
<MarkShuttleWorth> Hello
<MarkShuttleWorth> Are is everyone today?
<pitti> MarkShuttleWorth: Hi Mark!
<MarkShuttleWorth> how*
<mjg59> "sam"?
* pitti feels dapper, now that the point release CDs are great
<MarkShuttleWorth> great!
<Surak> sam - new zealand?
<crimsun> dead give-away there. HarrySprocket.
<pitti> MarkShuttleWorth: what happened to our beloved 'SABDFL'? :)
<sabdfl> *cough choke splutter*
<HarrySprocket> Does Mark Chat in here sometimes?
<crimsun> he's right there.
<sabdfl> imposter
<HarrySprocket> I assumed you would know it wasnt Mark
<HarrySprocket> haha
<sabdfl> well. *I* knew :-)
<Surak> HarrySprocket, sabdfl IS Mark...
<HarrySprocket> ok
<HarrySprocket> good, i wasnt an imposter
<sabdfl> ;-)
<HarrySprocket> sabdfl, did you know ubuntu is very popular in NZ?
<sabdfl> oh, that's cool - no i didn't!
<HarrySprockett> my connection is crap!
<nixternal> ubuntu devs...check it out....i am working on the Kubuntu Edgy Eft Knot releases.. see https://wiki.ubuntu.com/EdgyEft/Knot2/Kubuntu for an idea, however, if you all are interested in a familiar layout let myself or Corey Burger know, as these will become "Release" pages if i am correct ;)
<tseng> releases = release nodes?
<pitti> good night everyone!
<nixternal> notes yes
<nixternal> but not the release notes that will be with the official 6.10 release of course
<nixternal> those are docbook and not moin ;)
<Surak> night pitti!
<FreeSourcly> Ubuntu needs to move away from linux or it will always just be knowen as a 'linux distro'
<FreeSourcly> it needs too use the best of linux but start moving away now.
<LaserJock> hehe, and that's bad?
<FreeSourcly> yes because '
<FreeSourcly> distros come and go.......
<LaserJock> that makes no sense
<Fujitsu> Less than no sense.
<LaserJock> yes, distros come and go, but linux doesn't
<FreeSourcly> the ultimate goal should be a independant OS
<LaserJock> so why would we move away from Linux
<Fujitsu> Yeah, we don't really want to have our own kernel written...
* nixternal points to #ubuntu-offtopic and gives off and evil grin ;)
<nixternal> s/and/an as well
<nalioth> 'ray peer!
<Fujitsu> ...?
<nalioth> (Connection reset by peer)
<Fujitsu> Ah.
<Frostnice> Hello
<Frostnice> ./join #ubuntu
<Frostnice> ops sorry.
<Frostnice> I found a bug.
<Frostnice> When you install....ubuntu then install kubuntu-desktop... the splash sceen changes to "blue kubuntu"
<Surak> Frostnice: you can take a look if someone already posted it at http://launchpad.net . If yes, perhaps you can contribute with additional information on it.
<Frostnice> it should remain "brown/orange ubuntu"
<Surak> should it?
<Fujitsu> That's not a bug.
<Frostnice> well yeah.
<Frostnice> if they firstly install 'ubuntu'
<Frostnice> they obviously want it as default.
<Fujitsu> And it is fairly easy to change back.
<Fujitsu> Frostnice, not necessarily.
<Frostnice> How do you change it back?
<Frostnice> I'm a n00b.
<Surak> Frostnice: support questions are better handled at #ubuntu, not here.
<Frostnice> Im banned
<Fujitsu> That's silly of you.
<Surak> You already said that before. Perhaps you were banned for a reason?
<Fujitsu> Perhaps for trolling about Ubuntu moving away from Linux?
<Fujitsu> Now, move this to #ubuntu-offtopic, please.
<Frostnice> Ubuntu will take out Microsoft. Mark my words and excuse my pun.
<TentonMice> What a reject.
<mjg59> Be nice.
<Fujitsu> I don't think being nice is warranted in this case.
<mjg59> Well, alternatively just say nothing :)
<LaserJock> well, it wasn't anything terrible
<zul> it wasnt like the world was coming to an end, just ignore the trolls
<crimsun> TentonMice: please try to keep discussion on-topic for development.
<zul> hi
<bddebian> Howdy
<nalioth> bddebian: where you been hiding?
<bddebian> Hi nalioth
<bddebian> Hiding?
<nalioth> haven't see you in a while
<bddebian> I'm always here making the core-devs lives miserable :-)
<MasterMatt> I have to say 'ubuntu easy' is the shit man!
<MasterMatt> hello:)
<Hobbsee> heya MasterMatt 
<MasterMatt> How you doin?
<MasterMatt> Have you tried 'easy ubuntu'?
<MasterMatt> it's grand.
<jdub> ha ha
<jdub> "not defined as the opposite as something else"
<jdub> "how about non-opensource?"
<evand_> that just rolls off the tongue
<Keybuk> jdub: surely commercial/proprietary is simply the absence of open source?
<Keybuk> the opposite would be some kind of viral code that explicitly forces you to not release any source code sharing the same system? :)
<jdub> Keybuk: ;-)
<jdub> Keybuk: noticed that launchd is now available under ASL2?
<Keybuk> no, I hadn't looked
<jdub> oh. my. god.
<jdub> no. fucking. way.
<jdub> their collaboration server is built on twisted
<jsgotangco> interesting
<sivang> jdub: what's launchd ?
<Burgundavia> sivang: apple replacement to sysvinit
<sivang> Burgundavia: ah, I see
<Burgundavia> sivang: as well as cron, at, etc
<sivang> Burgundavia: ah, so it has all of those tools functionality ?
<Burgundavia> sivang: yes, it is quite cool but sadly APSL licensed
<Burgundavia> I think the plan is to grow Keybuk's replacement-init into something similar to it and SMF, but only GPL licensed, so distros like Suse and Fedora can use it
<Keybuk> pretty much, yup
<jdub> Burgundavia: did you read above?
<Burgundavia> jdub: sorry, I just joined
<jdub> Burgundavia: ASL2
<whiprush> jdub: when I read about launchd I told myself "jdub going to dig this in 3...2...1..."
<Burgundavia> launchd is ASL2?
<jdub> whiprush: not wildly so
<jdub> i'm more interested in the calendar server, which is built on twisted
<whiprush> last I recall you digged the solaris thing better
<whiprush> twisted? no shit?
<whiprush> that's, odd ...
<jsgotangco> why so?
<whiprush> I typically don't equate apple with using things they didn't invent
<ajmitch> they use a lot of stuff like that
<jsgotangco> well they seem to have sensible developers who don't want to reinvent things that already work nicely and just complement their ideas on it
<sivang> I suppose ASL2 is some sort of GPL compatible license so that's why the fuss about it ?
* whiprush is paging through 15 channels of the same conversation trying to piece it all together.
<jsgotangco> haha yahhh
<jsgotangco> irc mash ups would be more chaotic
<ajmitch> sivang: because it's a free license, not considered gpl-compatible
<ajmitch> according to the fsf, anyway
<sivang> ajmitch: I see, meaning we cannot do free use of it in Ubuntu?
<ajmitch> sivang: it's a free software license, so it can be used
<ajmitch> not everything has to be GPL-compatible
<whiprush> has anyone checked out this launchd thing in detail at all?
<jsgotangco> it says ASL2 is incompatible with GPL
<jsgotangco> but nonetheless,  a free software license
<jsgotangco> sivang: ^^
<sivang> jsgotangco: I see
<jsgotangco> "it has certain patent termination cases that the GPL does not require"
<Keybuk> whiprush: yes, extensively
<Keybuk> whiprush: what would you like to know about it?
<whiprush> Keybuk: opinion? iirc from reading the summary the problem was the licensing.
<whiprush> just wondering if this new apache 2.0 license thing is interesting.
<Keybuk> good points:
<Keybuk> - simple design
<Keybuk> - has the cron and inetd replacement out of the box
<Keybuk> - some mythical "start services only when required" code
<Keybuk> bad points:
<Keybuk> - no dependency/event graph; expects apache's init script to spin until /usr is mounted, then spin until the network is up, etc.
<Keybuk> - xml configuration
<Lathiat_> mm xml
<Keybuk> - probably would be considered a net loss of functionality
<whiprush> Keybuk: so overall, thumbs down?
<jdub> whiprush: when Keybuk thinks he can do better, definitely thumbs down ;-)
<whiprush> haha
<whiprush> the sun stuff looks so interesting, pity about the license.
<jdub> whiprush: what's wrong with the license?
<whiprush> afaik doesn't the cddl make it out of the running for putting it in ubuntu?
<jdub> not even remotely
<whiprush> oh really?
<jdub> CDDL is a generalised MPL
<jdub> a very good license
* whiprush recalls reading a comparison of init things ruling out the smf stuff
* whiprush goes to check
<jdub> it also happens to be as incompatible with the GPL as the MPL is
<jdub> but for a daemon that runs stuff...
* whiprush nods
<whiprush> https://wiki.ubuntu.com/ReplacementInit
<whiprush> "The first two of these suffer from inescapable licence problems, which is relatively unfortunate as both have features that are somewhat appealing though neither quite fix our problems."
<whiprush> is the page out of date or ... ?
<Burgundavia> whiprush: it is out of date as for this morning
<jdub> it's just wrong
<jdub> people don't grok CDDL
* whiprush just walks away from the argument.
<Burgundavia> jdub: it seems sane to work on an init system across many distros, including debian
<Burgundavia> debian has rejected the cddl
<jdub> no they haven't
<Keybuk> whiprush: actually, I liked launchd and thought it was be good for "a base to extend
<Keybuk> but the licence was (and probably still is) against that
<jdub> Keybuk: ASL@?
<jdub> why so?
<Keybuk> it isn't GPL compatible, no?
<Keybuk> ASL2 rings vague debian-legal alarm bells in the back of my head
<whiprush> Keybuk: fading away into sleep, but will log the rest of the conversation. :D
<jdub> Keybuk: why would it need to be GPL compat?
<Burgundavia> Keybuk: its GPL compatibility is disputed
<Keybuk> jdub: otherwise many people get discouraged from adoption
<whiprush> Keybuk: I'm sure it beats working on network-manager. :p
<whiprush> See, that was a joke ...
<Keybuk> jdub: e.g. depending on your interpretation of the GPL wrt dynamic linking; it may not be legal to write a GNOME frontend to launchd
<Keybuk> (assuming you have to C&P paste code from other GNOME apps, which ime is mandatory)
<jdub> Keybuk: have we done any universe security updates for dapper?
<jdub> Keybuk: trac (universe) could do with an update - is a backport ok for universe security updates?
<jdub> Keybuk: (i wouldn't have though think linking would be required to create a frontend for launchd)
<Keybuk> dunno, I think we have; ask pitti
<Keybuk> jdub: you'd need at least some of the launchd config file interpretation code
<jdub> oh
<jdub> wow
<jdub> timing
<jdub> pitti: hi!
<jdub> 16:39 < jdub> Keybuk: have we done any universe security updates for dapper?
<jdub> 16:40 < jdub> Keybuk: trac (universe) could do with an update - is a backport ok for universe security updates?
<jdub> 
<jdub> ^ pitti
<pitti> Good morning
<pitti> jdub: pants off!
<pitti> jdub: just one or two, but negligible
<pitti> jdub: as long as the new version is reasonably tested, I'm fine with that
<pitti> jdub: just a microversion update?
<pitti> jdub: the changelog should be checked for sanity, and if possible, the diff, too
<jdub> pitti: ok, i'll backport and test, and let you know
<jdub> pitti: thanks!
<pitti> jdub: cool!
<crimsun> I looked at trac for dapper-security and found it was a bit much, but that was a while ago
<dholbach> good morning
* Keybuk hugs dholbach
<dholbach> hey Keybuk :)
<dholbach> I wonder if seb128 slept at all
<dholbach> edgy-changes suggests otherwise
<dholbach> Keybuk: thanks for all the syncs
<pitti> Keybuk: thanks for the syncs; strange, I did not get accepted mails for most of them (just for bzr)
<Keybuk> pitti: I'm still doing them
<Keybuk> the process is roughly
<Keybuk> for SYNC in LIST; do sync-source $SYNC; done ; upload all syncs
<Keybuk> I'm still going through the list
<Toadstool> Keybuk: sorry about the mini-dinstall sync by the way, I must have been very sleepy not to notice the NMU is misversionned... :/
<Keybuk> \o/ only bddebian's left now
<Burgundavia> Keybuk: how much interest have you had from other distros for init-ng-Keybukstyle?
<Keybuk> Burgundavia: much
<Burgundavia> Keybuk: this launchd stuff change the landscape much?
<Keybuk> Burgundavia: everyone I've explained it to in detail has made vague "waaant" noises
<Burgundavia> right
<Burgundavia> any actual code from anybody else?
<Keybuk> Burgundavia: not really;  upstart is now just as feature complete as launchd, so the theory of using that as a base wouldn't gain anything ... and I still think it has licence problems
<Keybuk> nah, people are waiting for usto prove it works first
<Keybuk> plus I've not published the code anyway
<tepsipakki> seems that Enomalism isn't in edgy yet ;) http://enomalism.com/Wiki.wiki+M5902e6c2d07.0.html (a web-interface for Xen)
<pitti> seb128!
* pitti hugs the Great Gnominator
<mdke> cool name
<seb128> hey pitti :)
<dholbach> ogra: new gnome-powermanager and new gnome-screensaver
<seb128> Keybuk: is that you that do NEW processing nowadays? evolution-data-server has new binaries: libecal1.2-7 and libedata-cal1.2-6 (sonames change), accepting them so would be welcome (no hurry, just pointing what changed for it)
<Keybuk> seb128: I do some of it, yes
<Keybuk> gonna do some in a few minutes
<pitti> hi Hobbsee 
<Hobbsee> hey pitti 
<ogra> Keybuk, in a udev script, %k is the device name, are there easy variables for devicetype (cdrom/harddisc/camera) and for the label ? or do i need hal for that ?
<ogra> dholbach, thanks for notifying :)
<Keybuk> ogra: %k is the kernel name, not necessarily the name udev willg ive for the device
<Keybuk> ogra: define "device type", define "label"
<ogra> ah, ok
<ogra> ype as i said above for a block device i want to know if its a cdrom or a harddisk first place ... 
<Keybuk> assuming you mean block devices, you can use %env{ID_TYPE} and %env{ID_FS_UUID} etc.
<Keybuk> ogra: you missed the word "block device" :p
<ogra> ah, cool
<ogra> yes, sorry :)
<ogra> its early :)
<Keybuk> udevinfo -qall is your friend
<Keybuk> e.g. udevinfo -qall -n sda1
<ogra> hmm, intresting ...
<ogra> in the thin client it doesnt see the label
<ogra> hmm, and my camera is a floppy according to ID_TYPE :)
<Hobbsee> Keybuk: thanks for the masses of syncs/removals :)
* Hobbsee notes that her inbox is semi-flooded again.  i only cleared that out a few hours ago!  :P
<ogra> Keybuk, i noticed that the fuse module isnt autoloaded if i want to access /dev/fuse ... do i need an udev script here as well ?
<Keybuk> fuse is one of the tricky ones, like ppp, etc.
<Keybuk> it's not associated with any device, so it won't be automatically loaded
<ogra> well, i'll need it loaded for ltspfs
<Keybuk> the easiest way is just modprobe -Qb fuse
<ogra> and the fuse utils are all acessing /dev/fuse
<ogra> i.e. fusermount
<ogra> so i'd assume we can associate t with that device ...
<Keybuk> another way would be to put /dev/fuse in /lib/udev/devices
<Keybuk> device == physical device, sorry
<ogra> and link it to /dev ?
<Keybuk> things in /lib/udev/devices are copied to /dev by the udev init script
<ogra> hmm, that would mean i have it permanently loaded 
<Keybuk> no, it'd be loaded when the device was first touched
<ogra> loading the module already creates it dynamically in /dev
<Keybuk> one can mknod anything without loading the module
<Keybuk> right
<Keybuk> the choice is
<Keybuk> 1) loading the module with modprobe so the device is created
<Keybuk> 2) having the device already around, so the module is loaded by kmod
<ogra> hmm ...
<ogra> 1) is a problem because i'd need root access while a user driven script runs ...
<Keybuk> right, we have the same problem with ppp
<ogra> so the ltspfs postinst would have to mknod /lib/udev/devices/fuse ... ok
<Keybuk> no
<ogra> but ?
<Keybuk> the ltspfs package could just ship that
<ogra> ah
<Keybuk> or, tbh, I'd probably just ship it in the udev package
<ogra> no need to mknod ?
<Keybuk> what's the major/minor ?
<Keybuk> well, it does the mknod in debian/rules
<ogra> crw-rw---- 1 root fuse 10, 229 2006-08-07 19:18 /dev/fuse
<ogra> (the group is important)
<Keybuk> the group is not possible, I'm afraid
<ogra> hmm
<Keybuk> if it's shipped in a package, it'll have to be root:root until udev's init script runs
<Keybuk> it may be that #1 is your only solution then
<ogra> hmm
<ogra> echo "fuse" >> /etc/modules
<ogra> :P
<Keybuk> yup
<ogra> ugly
<ogra> but if there is no way around ... *shrug*
<Keybuk> it's in a class of modules we haven't got a perfect solution for yet
<Keybuk> drivers without hardware
<ogra> yep
<Keybuk> you want it loaded if you want it
<Keybuk> usually it just makes sense to load them with modprobe when necessary
<Keybuk> but when the device needs to be used by !root, that's a problem
<Keybuk> we vaguely chatted once about making modprobe setuid root, and then having it decide whether the real user could load that module or not
<ogra> well, fuse is exactly for userspace only, as the name implies :)
<Keybuk> but I suspect that's the kind of thing that makes pitti soil his underwear
<ogra> hehe
<ogra> i'm fine for now with /etc/modules its just sad we cant do it dynamically ...
<ogra> and i think in hotplug times it was loaded dynamically, but i might be wrong
<pitti> Keybuk: are there more examples where calling modprobe would make sense (which are not just bugs)?
<ogra> the fuse utils package used to ship a script
<Keybuk> pitti: ppp
<Keybuk> pitti: loop
<ogra> pitti, pppoe ?
<Keybuk> pitti: tun
<pitti> Keybuk: ok, ppp makes sense, but loop?
<Keybuk> pitti: mount should be able to "modprobe loop" if it's in fstab and user
<ogra> loop is autoloaded
<pitti> users can't setup loop devices without root power anyway
<Keybuk> but can't
<pitti> Keybuk: ah, ok
<Keybuk> ogra: only because we have a static device in /dev copied in by init
<ogra> if i mount -o loop i have no complaints here
<ogra> aha 
<ogra> !
<pitti> is there any way to conditionally build a target in Makefile.am based on a config.h variable? (i. e. the presence/absence of a library detected by configure)
<Keybuk> if VARIABLE
<Keybuk> ...
<Keybuk> endif
<pitti> oh, wow, magic :)
<pitti> Keybuk: thanks
<Keybuk> (must be defined in configure.ac by AM_CONDITIONAL
<Keybuk> usually you do something like AM_CONDITIONAL(VARIABLE, test x$ac_variable = xtrue) or something
<Keybuk> there's an example in the info page
* ogra wonders why debian removed the link from /etc/mtab to /proc/mounts in ltsp clients ...
<pitti> Keybuk: ah, http://www.delorie.com/gnu/docs/automake/automake_106.html
<ogra> and i wonder why i dont get my mounts right *sigh*
<ogra> the fact that dash doesnt know about $UID is rather impressing :)
<pitti> ogra: id -un ?
<ogra> i've put UID=$(id -u) at the top, yes :)
<ogra> but still, thats a variable i'd have expected in any shell :)
<pitti> ogra: better not rely on it :)
<ogra> yeah, seems like
<pitti> ogra: otherwise I could do nasty things with export UID=0 or so :)
<StevenK> pitti: export UID=-1
<ogra> oh, i dont use it for anything critical ... just for a directory name
<pitti> StevenK: what's -1, super-root? :)
<ogra> reverse root :)
<StevenK> pitti: UID's are unsigned, it'd be fun watching stuff blow up.
<ogra> toor :)
<pitti> StevenK: ah, might wrap to nobody then (65535?)
<StevenK> Hey, that's a point.
<pitti> well, that would be -2
<StevenK> steven@liquified:~% id -- -2
<StevenK> id: -2: No such user
<Keybuk> ogra: mtab and mounts aren't equivalent
<ogra> Keybuk, in ltsp-clients they are (read only filesystem, i need to know what the kernel thinks is mounted)
<Keybuk> ogra: why not just use /proc/mounts directly then?
<ogra> Keybuk, because apps look in mtab ...
<ogra> its fine with the link
<Keybuk> ok
<ogra> debian just removed it and made mtab a static readonly file
<Keybuk> mounts is missing mount options though, no?
<ogra> which doesnt help much for local device support :)
<Keybuk> http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_05_03
<Keybuk> ^ doesn't specify UID as a shell-set parameter
<Keybuk> so $UID is a bashism
<StevenK> Doesn't help that zsh also seems to have it.
<ogra> well, fstab is a writeable file ... and devices i plug in use it ... so i have the options there 
<ogra> and i call mount directly as mount -o sync ... anyway ...
<ogra> no extra options needed :)
<jono> hi all
<sabdfl> hey jono
<jono> heya sabdfl
<jono> sabdfl, hows things this morning?
<sabdfl> excellent, am en route to cambridge for a bit of supercomputer action
<sabdfl> always makes for a fun day
<jono> :)
<jsgotangco> nice
<StevenK> sabdfl: Ubuntu CDs packed? :-P
<Hobbsee> hi sabdfl 
<sabdfl> hi StevenK, Hobbsee
* StevenK waves.
<ajmitch> sounds like a fun day
<pitti> sabdfl: woohoo, enjoy the big irons :)
<Hobbsee> StevenK: ah.  thanks for reminding me what i was going to grab some of from pia.
<ajmitch> Hobbsee: ran out already?
<Hobbsee> ajmitch: only had one :P
* StevenK has none, until his shipment arrives.
<Hobbsee> grr.  that's three hard lockups in two days, and i've got absolutely no idea why.  *grumble*
<Treenaks> Hobbsee: nvidia/ati drivers?
<StevenK> Hobbsee: Heat?
<Hobbsee> Treenaks: neither.  plain intel card
<StevenK> Hobbsee: I've pointed out the fan in those laptops are worthless.
<Hobbsee> true
<Hobbsee> it doesnt seem that hot
<StevenK> The outside case doesn't.
<TheMuso> Hobbsee: Have you ever thought to check the CPU temperature?
<Hobbsee> TheMuso: a long time ago.  should check that again
<StevenK> That's no indication that the CPU isn't molten.
<ajmitch> Hobbsee: you're still using that horribly broken fan?
<jono> hey Gman 
<Hobbsee> ajmitch: yeah
<Gman> hey jono
<Gman> how goes it?
<jono> Gman, good thanks, you?
<StevenK> Hobbsee: I suspect that the fan has gotten a little worse.
<Gman> jono, not bad - other than living in a leaky home :(
<Hobbsee> StevenK: quite possibly
<ajmitch> I suspect that the only way it can get worse than what it is, is to stop altogether
<StevenK> ajmitch: It may be spinning a little slower and expelling less heat.
<jono> Gman, ugh :(
* mdke kicks Planet Gnome
<kagou> hi
<iwj> mvo: re 19834: Yes, fine.
<mvo> iwj: thanks
<iwj> I see you closed it already.
<mvo> iwj: yes, my reasoning was that it can always be reopened (and that I didn't want to forget about it)
<iwj> :-)
<jdub> elmo, Znarl, Spads: ping
<Znarl> jdub : Pong?
<jdub> Znarl: am i going to get {people,humboldt}.ubuntu.com love back at any point?
<elmo> jdub: people, not any time in the immediate future.  humboldt hasn't been changed
<elmo> jdub: (people still requires chinstrap -> employees only - that may/should be fixed, but it's not in the short term TODO)
<jdub> elmo: could planet be moved to another machine maybe?
<jdub> elmo: perhaps you could remove the {Packages,Sources}* files from my public_html/* on people? i don't want people thinking those are maintained if i can't maintain them
<mdke> jdub: got a moment?
<jdub> sure
<mdke> cool
<elmo> jdub: planet isn't on people?
<jdub> elmo: planet is on humboldt
<elmo> jdub: yes. so why do you want it moved?
<jdub> elmo: 'cos i don't have access, and i thought non-employees couldn't get to humboldt
<elmo> jdub: your account hasn't been locked on humboldt, it's not part of the LAN and doesn't require chinstrap access to reach it
<elmo> jdub: that's what I meant by "humboldt hasn't been changed" - sorry if I wasn't clear
<jdub> elmo: i'm locked out though :)
<jdub> no ssh key love and no password
<janimo> Gloubiboulga: hi
<elmo> jdub: I can't even see you trying to login - are you sure you're not still trying to proxy through chinstrap?
<Gloubiboulga> janimo, hello
<elmo> jdub: (and it might be better to take this to #canonical-sysadmin)
<jdub> elmo: ok, sorted, i hadn't killed the chinstrap config on this machine
<jdub> thanks
<janimo> mvo: hi I talked to glatzor and he said the remaining gtkhtml use in g-a-i can be replaced with a simpler html parser (he said beautiful-soup)
<janimo> would you agree to getting this last I think gnome dependency out, and solve the gconf one as with update-manager?
<mvo> janimo: yes, that sounds good. I need to check the gtkhtml solution though first
<janimo> mvo: sure, thanks, let's see what glatzor has to say, he said he had to check this out it more detail first
<ogra> seb128, i have a small problem, i have a script that adds a link to the desktop ... th elink doesnt appear on the users desktop, but if i open a nautilus window i see it appearing/vanishing dynamically
<ogra> any idea why the desktop itself isnt updated ? 
<jdub> mdz: ping
<ogra> pitti, how does g-v-m know there was a CD inserted ? seem there is no kernel event or something i could catch with udev 
<ogra> is that hal ?
<mjr> I think that's hal's business, yes
<ogra> damned
<ogra> where does hal get the event then ?
<ogra> i need a trigger that doesnt involve installing half of the desktop innings into the thin client ...
<janimo> ogra, udevmonitor
<janimo> if you don;t want hal
<ogra> janimo, YAY, thanks !
<janimo> hal gets it from udev
<janimo> ogra: welcome :)
<ogra> hmm, no events for CDRoms ...
<ogra> must get it somewhere else
<janimo> ogra: indeed, only lshal -m show cdrom events...
<ogra> yep
<ogra> but where does it get them ?
<janimo> dunno
<ogra> hmm, intresting ... NM spills an entry into syslog for *every* device thats added or removed
<ogra> how noisy
<pitti> ogra: yes, hal polls for CDs periodically
<pitti> ogra: there's no other possibility than polling unfortunately
<ogra> what exactly does it poll ? 
<ogra> i'm fine adding a "while true; do ... ; done" script for the client ... but adding the complete hal will kill my memory 
<pitti> ogra: check hald/linux2/addons/addon-storage.c
<pitti> ogra: that's the backend responsible for cd polling
<ogra> thanks !
<ogra> thats what i'm looking for
<pitti> ogra: http://people.ubuntu.com/~pitti/scripts/cdcaps.py
<pitti> ogra: essentially, you need to do fcntl.ioctl(f, CDROM.CDROM_DISC_STATUS, 0) periodically
<pitti> and test the bits which indicate that a CD is present
<ogra> wow, that script is sexy :)
<pitti> ogra: check addon-storage.c how hal tests it
<pitti> drive = ioctl (fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
<pitti> CDS_DISC_OK -> there is a CD-ROM, otherwise there's not
<ogra> i think i'll redo all my stuff in python looks way more elegant than the shellscripts i have :)
<ogra> ok
<ogra> i'll play with it a bit
<pitti> ogra: heh, indeed I slowly got used to writing stuff in python right from the start
<pitti> as opposed to developing complex shell scripts and rewriting them later :)
<pitti> ogra: if you want shell, you can do 'perl -e' magic, though
<pitti> ogra: check powerpc's pmi for an example how to do ioctl's in combined perl/shell
<ogra> well, there would have been tons of system() calls in the beginning ... if i write such scripts that poll most data from other tools i'm better off with shell
<ogra> but usually while i start dropping the subshell ugliness i could as well replace it with python :)
<pitti> well, OTOH you wouldn't want to spawn a perl/python interpreter *every three seconds* from a shell script
<pitti> ogra: so, either a small C program or completely perl/python, I'd say
<ogra> python is it :)
<pitti> ogra: and please use subprocess.{call,Popen} instead of system :)
<ogra> i already started rewriting the bits on the session side ... 
<ogra> pitti, for testing i usually use VAR=$(ls -l) in shell :)
<ogra> and usually my first iteration of a script is crowded with that 
<ogra> :)
<seb128> ogra: nop, but nautilus has some notification issues that should be fixed with the update coming today
<ogra> shawarma, k 
<ogra> err
<ogra> ah, k
<ogra> funnily if i touch/rm a file manually all is fine ...
<pitti> G0SUB: hm, can you please commit the latest stuff into bzr? I didn't find any CLI frontend, nor any test suites in the currently pushed version
<bddebian> Howdy
<bddebian> THANKS KEYBUK!
<Keybuk> no worries
<bddebian> Keybuk: Do you have an opinion on squashfs?  I haven't gotten any feedback on ML or IRC.
<ajmitch> bddebian: mdz said upload it, livefs builds use dapper's squashfs
<bddebian> I know but I'm scared :-)
<Keybuk> what's the change?
<bddebian> ajmitch: Hi BTW :-)
<bddebian> Keybuk: Build-dep linux-headers-2.6.17-5 instead of 2.6.17-1-all
<Keybuk> seems fair
* bddebian crosses his fingers and uploads
* Hobbsee wonders why a whole lot of stuff is FTBFS on the buildds.
<Hobbsee> ah.
<Hobbsee> Errors were encountered while processing:
<Hobbsee>  /home/buildd/build-235140-269468/chroot-autobuild/var/cache/apt/archives/xinit_1.0.2-0ubuntu1_i386.deb
<ajmitch> yes, he uploaded -0ubuntu2 
<StevenK> Because X is borked?
<Hobbsee> dpkg: error processing /home/buildd/build-235140-269468/chroot-autobuild/var/cache/apt/archives/xinit_1.0.2-0ubuntu1_i386.deb (--unpack):
<Hobbsee>  trying to overwrite `/usr/share/man/man5/Xsession.5.gz', which is also in package x11-common
<Hobbsee> ah
<ogra> fixed two uploads ago
<Hobbsee> right
<StevenK> So now we just wait for the buildds to be fixed and beg infinity for a mass give-back?
<Micksa> hi!!!
<Micksa> I have an excuse to be here :)
<Micksa> How do I create the initramfs for casper from its sources?
<Micksa> aw, someone tell me
<Micksa> this is torture
<Micksa> I'm reading shell scripts
<mdke> Micksa: you might have more luck asking in the support channel, I suppose, or searching the documentation wiki, if no one answers in here
<Riddell> jono: congrats
<jono> cheers Riddell :)
<Riddell> (since it seems to be public now)
<ajmitch> jono: so you're our new master?
<jono> ajmitch, hah! :)
<jono> yeah, MArk was holding off for an announcement
<jono> he picked the worst possible picture too :)
<ajmitch> I just saw it pop up on mugshot :)
<zul> jono: so i can bug you now heh heh..
<pitti> hey jono, welcome!
<mdke> welcome jono
<jono> sure, feel free to bug me guys :)
<jono> thanks pitti mdke :)
<tseng> wait what?
<ajmitch> tseng: see planet ubuntu
<tseng> did jono get that community leader thing
<ajmitch> he did
<tseng> man
<tseng> he'll be all up in my face now
<jono> heh
* jono thwacks tseng :P
<jdub> jono: :-)
<Burgwork> morning jdub, jono 
<jono> hey Burgwork 
<jono> jdub, :)
<jdub> jono: walking out the door, i was a bit disappointed that we'd missed the opportunity to work together :)
<jono> jdub, yeah, I wish we could have worked together too :)
<jono> jdub, maybe one day :)
<Burgwork> jono, are you the new community manager for Canonical?
<jdub> jono: at least paul won't be stuck with the usual "jono's boss" crap anymore
<jdub> jono: oh - perfect
<jdub> jono: sabdfl == "jono's boss"
<jono> Burgwork, yeah
<jono> jdub, hehe
<jdub> jono: or do you report to jane?
<Burgwork> jono, congrats! you coming to LWE SF?
<jono> jdub, no, to Mark
<jdub> ah well, sure you'll fix that soon enough
<jono> Burgwork, thanks, I wish I could, but no :(
<jono> jdub, :)
<jdub> in the mean time, we can call him "jono's boss"
<jono> hehe
<jono> I smell revenge here..
<jdub> gotta make up for paul's pain somehow
<jdub> circle of life and all
<jono> heh, but Paul is going to be a GNOME god afte rGUADEC2007
<jono> its gonna be awesome :)
<jdub> yeah, b'ham is going to rock
<jono> no beach party though :(
<jono> skinny dipping in the birmingham canal would be painful
<mjg59> But real beer
<jdub> *riowr*
<thom> jono: hire a hall and ship in sand
<thom> sorted.
<jono> thom, :P
<tseng> jono: technical people are notably left out of your enumeration of community areas
<jono> tseng, thats only one aspect of what I will be doing
<jono> tseng, of course my work will  include technical teams :)
<tseng> ok, I don't much care personally
<jono> tseng, and if you have suggestions for ways in which to improve the community with regards to technical teams, let me know :)
<tseng> but its a key point of entry
<jono> sure :)
<Burgwork> jono, as part of your new job, I would like you to look at HelpingUbuntu, with an eye towards moving it to /community/participate on the website. I need some good critical feedback on it
<tseng> I am a pretty bad person to ask about joining ubuntu  seeing as I've been here since before there was a name
<jono> Burgwork, sure :)
* tseng delegates to recent motu converts
<jono> Burgwork, could you ping me in a few weeks about it when I am up and running?
<jono> tseng, sure, but its not just about joining the community, but how the community works :)
<Burgwork> jono, sure, but I was trying to push myself to finish it and get it live
<zul> tseng: you're special :)
<tseng> zul: hah not really.
<jono> Burgwork, ok, I will have a look tomorrow if that is cool - need to finish up some stuff right now
<jono> Burgwork, could you mail me a jono AT jonobacon DOT org about it
<Burgwork> jono, no, do it now! ;)
* jono loads the shotgun...
<jono> :P
<bddebian> Hello again nalioth :-)
<nalioth> bddebian: yes, thank you.  (no thanks to my ignorant ISP, tho)
<dholbach> jono: else Burgwork will write angry blog entries :-P
<Burgwork> dholbach, very angry blog entries. Filled with much gnashing of teeth :)
<jono> :P
<Burgwork> all about how the powers that be are ignoring poor pitiful volunteer me
<dholbach> Burgwork: as i said.... I'm not sure that angry blog entries help much
<zul> Burgwork: the usual fire and brimstone?
<Burgwork> zul, absolutely
<Chipzz> sorry for the off-topic question, but does anyone know wth this could mean?
<Chipzz> getpeername(0, 0xbfcd2610, [16] )        = -1 ENOTSOCK (Socket operation on non-socket)
<Lathiat_> assumedly it means the the file descripter passed to getpeername is not a socket
<Lathiat_> which that it is the first argument
<Lathiat_> which is 0
<azeem> is 0 a valid file descriptor/socket name?
<Chipzz> fd 16?
<Lathiat_> your most certainly tryign to pass NULL incorrectly
<Chipzz> I have absolutely no idea
<Lathiat_> apt-get install manpages-dev
<Lathiat_> man getpeername
<Chipzz> hrrm
* Chipzz digs further
<mjr> azeem, it tends to be stdin (though just by convention :]  )
<azeem> ah, right
<Chipzz> this makes no sense
<wasabi_> Hey, what's up with Pulse?
<wasabi_> It packaged?
<Chipzz> ah ok
<Chipzz> this binary is supposed to run from inetd
<Chipzz> starting to make sense now
<G0SUB> pitti: yes, they are done here. I am yet to commit.
<mjr> Chipzz, yes, that would
<mdz> jdub: pong
<mvo> infinity: could you please kick the gksu build?
<jdub> mdz: can you look at an rrdtool upgrade for me?
<mdz> jdub: perhaps
<jdub> deb-src http://www.gnome.org/~jdub/ubuntu/edgy/ /
<infinity> mvo: I just (ie: 2 minutes ago) did a mass give-back.
<infinity> mvo: So it'll get kicked with everything else in about 15 mins.
<mvo> infinity: ah, cool. thanks
<jdub> mdz: some of the bindings don't have dependencies, so was difficult to seriously test it ;)
<quail> hello
<wasabi_> We used ot have polypaudio packages. Those seem to have vanished. jdub? Done Pulse packages?
<pitti> wasabi_: we removed them when polypaudio was abandoned upstream and too buggy
<wasabi_> Hmm. There a current plan? Me and a friend are experimenting with it.
<wasabi_> Finding it quite awesome. ;)
<pitti> well, personally I don't care about it :)
<pitti> we use ALSA by default now, and I do not wish to reintroduce a mixing daemon by default
<wasabi_> Going at it from an angle of adding a BT headset at runtime, and moving streams over to it on the fly.
<pitti> which of course does not mean that it shouldn't be packaged
<wasabi_> Or plugging a laptop into a docking station, and on plugin, changing the default output to a different audio device, etc.
<wasabi_> He's working with voip calls, basically.
<mdz> jdub: if you email me a diff I'm less likely to forget
<jdub> wasabi_: yeah, just haven't had time to finish them
<sladen> pitti: the stuff Fabian (FreeNX) has been working on routes /dev/dsp via 'esd'
<jdub> wasabi_: pulse is definitely the way to go though, none of this dmix crap :)
<wasabi_> Yeah. I agree. 100%. I've been running the entire stack through my head the last few days.
<wasabi_> We have devices which won't even show in Alsa, actually.
<wasabi_> user mode blue tooth devices, for instance.
<jdub> wasabi_: we had a great meeting at guadec about The Future
<wasabi_> Not to mention the zeroconf stuff.
<wasabi_> Wish I could have come. =(
<wasabi_> I'm all about The Future!
<wasabi_> I've a few things I'd like to investigate, which might make people squimish, with regards to pulse. A gstreamer source module for it. :)
<jdub> nup, makes total sense - doesn't the current gstreamer plugin have a source?
<wasabi_> Well, it ships raw pcm across process. One idea is to ship the encoded audio to PA.
<wasabi_> And have PA run it's own pipeline internally to do the decoding.
<wasabi_> From the n770 angle.
<wasabi_> (they already do such with a dedicated gstreamer daemon)
<wasabi_> fun stuff. =)
<jdub> oh right
<jdub> yes, that was one of the difficult parts of the discussion at guadec
<jdub> particularly useful for airtunes or thin client use cases
<wasabi_> src ! demux ! decodebin ! pulsesink
<wasabi_> pulsesink would detect a gstreamer enabled pulse, which would advertise it's caps.
<wasabi_> pulsesink then would tell decodebin it could accept actual ogg.
<wasabi_> decodebin would be like "oh hey, I don't have to do anything!"
<wasabi_> ogg would go to pa process, pipeline is built over there to decode ogg.
<jdub> sell mezcalero on it :)
<wasabi_> Yeah.
<wasabi_> He reminded me that PA is GPL and some gstreamer mods are not. :0
<wasabi_> interesting stuff anyways.
<jdub> hrm, yeah, that's problematic
<wasabi_> Well, PA could restrict itself to GPL compat elements.
<wasabi_> white list.
<wasabi_> Only advertise the caps of those elements, etc.
<wasabi_> That's solvable, just annoying.
<wasabi_> Then the same idea pops up for a "video server", like PA.
<wasabi_> Another thing which Maemo deals with.
<wasabi_> anyways. Just wondering if there are packages to easy my efforts.
<dholbach> am I on crack or did the font display in the console (ctrl-alt-f1) get much cleaner?
<cr3> anyone happen to know of a workaround for the problem where the screen blanks during install on a machine with an i810 based video controller?
<Keybuk> man, DVD Authoring on Linux is *hard*
<pygi> Keybuk, not for long ^
<ogra> Keybuk, i think pygi has a program 
<ogra> :)
<pygi> ergh, knew it :)
* pygi eats ogra :)
<ogra> hehe
<Keybuk> pygi: oh aye?
<ogra> pitti, is there a reason we dont have "dev.cdrom.lock=0" in sysctl.conf ? 
<pygi> Keybuk, the part that you want will be here and will be higly usable, but is in no usable condition for now ^_^
* pygi wonders how ogra remembered that...
<Keybuk> the main problem is getting the encoding right
<ogra> pygi, my mind is like a big dusty chaotic storage ;)
<pygi> ogra, weee :)
<Keybuk> the one I just wrote was ok, but not perfect ... in particular it had to pad in an extra frame
<pygi> Keybuk, so no worries....it'll be easy one day ^_3
<pygi> ^_^
<Burgwork> pygi, release early, release often
<pygi> Burgwork, ofcourse ^_^
<pygi> and usable, if appliable :)
<Keybuk> release before I've got sick of doing it manually
<Keybuk> and written my own
<Keybuk> <g>
<ogra> heh
<pygi> Keybuk, how much time do I have?
* ogra guesses some hours
<pygi> I am currently messing with libburn, so I can't make any promises ^_^
* pygi thinks some hours won't be enough as he won't be here  next...hm...5 hours? :)
<Keybuk> libburn?
<Keybuk> you're not just shelling out to the existing tools?
<ogra> libburn is the future :)
<Keybuk> let me guess, you send the movie over d-bus? :p
<pygi> ogra, let's hope so ^_^
<ogra> lol
<ogra> in messages ? 
<pygi> Keybuk, ofcourse, you have any other idea? that seemed the best last time I checked :)
* Keybuk gets Stevens open again
<Keybuk> ...so, TIOCSCTTY did very bad things to X
<pygi> ogra, as soon as 3 critical features (for now) are implemented, I'll consider libburn taken it's first step to the future :)
<ogra> :)
<pygi> which would be -tao, multi-session, and dvd support ^_^
<pygi> and a couple of annoying bugs ^_^
<Keybuk> mjg59: around?
<zul> he was around earlier
* pygi sends Keybuk over d-bus to ... hm, ehm...hm.. who wants keybuk? :)
<mjg59> Keybuk: hi
<Keybuk> mjg59: do you know much about terminal handling on Linux?
<mjg59> Not realy
<Keybuk> no, me neither ... I figured you might having played with usplash
<Keybuk> I managed to get it to do things I've seen both usplash and acpi-support do
<Keybuk> (active terminal gets nothing but \n)
<Surak> BenC: ping
<BenC> Surak: pong
<Surak> Benc: (in regard of bug #55104 ): the option for disabling video (or changing vga priority) on setup of all i865-based MSI boards fails.
<Ubugtu> Malone bug 55104 in linux-source-2.6.15 "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  http://launchpad.net/bugs/55104
<BenC> Surak: We wont be implementing that script workaround
<BenC> Surak: I'm not sure what the best fix is, but it needs to not crash in cases like yours
<BenC> proper thing would be to fail to setup DRM
<Surak> Which would mean to blacklist intel-agp by default. 
<BenC> no, that's not what it means
<BenC> it means nvidia should fail to initialize in this case
<Surak> by blacklisting intel-agp would disable DRI on intel boards, but would make X start on every case.
<Surak> we could change the udev rule for intel-agp. It could call a script and verify if there's a nvidia board present, and then refuse to load. Is there any way to make a 'conditional' udev rule?
* mjg59 boggles
<Keybuk> Surak: err, what are you trying to do?
<mjg59> It's perfectly valid for intel-agp to be loaded when nvidia is
<mjg59> There appears to be one specific case where there's a problem
<Keybuk> this sounds like a driver bug to me
<mjg59> And if you're not using the nvidia binary drivers, then there's nothing that'll ever touch intel-agp on that system
<Surak> mjg59: yes, this is quite specific to i865 chipset and nvidia boards.
<mjg59> So can we drop the idea of blacklisting and try to find out what the actual bug is?
<mjg59> Firstly, if you blacklist the nvidia module, does it work?
<Surak> mjg59: the problem is that when intel_agp is loaded, the machine will hang. I have three different mainboards which use this chipset and all of them hangs.
<mjg59> Surak: No, that is not the problem
<mjg59> Surak: The problem is that the machine hangs
<mjg59> Surak: We need to determine /why/ that happens before we know how to fix the bug
<Surak> let me try blacklisting nvidia.
<Surak> 'll be back in a minute.
<Surak> mjg59: blacklisting nvidia does not work. The machine still panics.
<mjg59> Surak: Can you provide the panic?
<Surak> I'll do this right away.
<mjg59> Thanks
<Surak> hum... not easy to take a kernel panic log, as / is mounted RO when /etc/rcS.d/S07linux-restricted-modules-common is run. Whatever, let me mount it rw before.
<BenC> is lp down?
<Burgwork> BenC, ubuntu.com appears to be down as well
<Burgwork> strike that, very slow
<Riddell> mjg59: do we have SetPowerSave in ubuntu's HAL?
<mjg59> Riddell: Not sure
<Riddell> mjg59: next question, do you know how g-p-m decides if it should run or not?
<mjg59> It's started as part of the session
<Surak> mjg59: I'm not being able to capture the crash. The system logs nothing. If I tell ksyslogd to start earlier, the only message in /var/log is a :"Aug 8 16:23:31 ubuntu syslogd 1.4.1#17ubuntu7: restart"
<Riddell> mjg59: but presumably it doesn't run if you don't have power management?
<Surak> As it restarts immediately, I can't even type it.
<mjg59> Surak: It's likely that it never hits disk.
<mjg59> Riddell: I don't believe there are any systems that don't have power management
<Surak> mjg59: I forced mounting of / in rw mode, so syslog can write to /var/log. I don't have any serial console to log it. Do you have any other idea on how can I get this panic log?
<mjg59> Surak: Pen and paper, I'm afraid
<Surak> mjg59: I can't, because the panic shows for a very small time, and the machine immediately restarts. 
<jdub> digital camera! attach the photo to a launchpad bug :)
<Spads> doing flickr searches for like "kernel panic" are great
<jdub> ha ha
<jdub> uh
<jdub> actually
<jdub> the osx kernel panics are cool
<jdub> http://flickr.com/photos/cryw/145375770/
<jdub> bonus
<jdub> uh, holy crap
<jdub> an overwhelming number of the first page are osx panics
<jdub> not sure what that speaks to most
<jdub> flickr user profile?
<jdub> osx stability?
<jdub> deployment numbers?
<Spads> user choice of tools?
<Spads> it strikes me that OSX's touted demographic are more likely to have photo/video recording equipment near the monitor
<jdub> yeah
<jdub> also it is worth taking a photo of, really ;)
<Spads> yeah, that's a gorgeous color scheme
<Spads> it should have like the narita announcer track recorded in ROM and fed into dedicated chips driving the speakers
<tseng> that would be horrific
<jdub> when tseng says horrific, he means dope
<tseng> I don't want my computer to talk
<tseng> think of the translation issues
<tseng> if you want a really concrete example of why its a bad idea
<tseng> beyond OMG CRACK
<Spads> they have four languages up there
<Spads> that's why I was saying like the narita announcer girl
<mc44> Just have them speak in Esperanto - no worries
<Spads> it looks like the sort of plaquards you find in aeropuertinos
<dmg> whois spads
* Spads is GAR
<tseng> dmg: someone with an unfortunate client config
<Keybuk> jdub: it makes you wonder though ... if their system can do that much fancy shit, why is it PANICing in the first place?
<Spads> and by unfortunate, tseng means dope
<Keybuk> the entire point of a PANIC is that the kernel dare not do anything for fear of breaking the system
<dmg> bah, wanted to see if there was a country associated with 'aeropuertinos'
<tseng> by unfortunate, tseng means please fix your ircname:
<tseng> with what your mother named you
<Spads> dmg: no, I was just hoping that it would be mangled enough to be offensive in some language
<Spads> tseng: that old hag?
<Spads> and no, I don't want Rob Levin to find me.
<Keybuk> zsh: segmentation fault (core dumped)  dd if=/dev/zero bs=4 count=1920
<Keybuk> ...eerrr...
<Spads> http://flickr.com/photos/cookiecrook/115108768/ <-- that's more like a kernel panic.  I think that other thing was closer to an oops
<Burgwork> Spads, I like the last two comments
<nixternal> heh, "it doesn't give you a choice"
<nixternal> nice
<Spads> I think he thought it was like a root window xterm type display
<jdub> AHR!
<jdub> 24" OF PURE IRSSI!
<wasabi_> This line must be 1 cm long
<jdub> high, you mean.
<jdub> in fact
<jdub> i think it is
<jdub> BONUS!
<pitti> jdub: size DOES matter? :)
<Kamion> infinity: the usplash configuration failure in http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/edubuntu/latest/livecd-20060808-i386.out is a little odd. Is /proc not mounted?
<Kamion> mjg59: that single <(...) in usplash.postinst has caused more failed installs than anything else in edgy in the last week, I think :(
<Kamion> is there no way to reword that in POSIXese?
<mjg59> Kamion: Not that I could work out
<mjg59> It needs to convert something of the form
<mjg59> 1024x768, 800x600, 640x480
<mjg59> to
<mjg59> x=1024; y=768
<mjg59> without picking up any of the later stuff
<Kamion> eval `sed script`
<Kamion> ?
<mjg59> Yeah. Sounded ugly, though.
<Kamion> at this point the bashism seems more ugly
<mjg59> I'd sort of expected systems to actually work :)
<Kamion> well, not because it's a bashism
<mjg59> I can do it cleanly in zsh
<Kamion> surprising that even our buildds don't seem to have it though - that suggests very little else is using /dev/fd
<mjg59> But I don't think that's a great answer either
<mjg59> Yes
<mjg59> I seem to remember that there's at least one other package that can be expected to break
<Amaranth> mjg59: Hey, latest usplash at least doesn't die with "screen init failed" but I get garbage on the screen. Blue and green vertical lines.
<jdub> hrm, why does ubuntu-desktop depend on linux-headers-686 (specifically 686)?
<tseng> jdub: so kids can build their own network driver
<tseng> oh
<tseng> good question
<jdub> Kamion: possibly one for you, seed master
<jdub> (haw haw)
<tseng> it was mdz's add
<Kamion> mjg59: hang on, isn't this really easy?
<Kamion> x="$(echo "$RET" | cut -d, -f1 | cut -dx -f1)"
<Kamion> y="$(echo "$RET" | cut -d, -f1 | cut -dx -f2)"
<Kamion> ok, so it's a few more processes, but no big deal in a postinst
<Kamion> jdub: as tseng says, mdz explicitly added it
<Kamion> jdub: you can bzr log the seeds
<Kamion> and it's -686 because it was moved over verbatim from the ship seed
<Kamion> or ship-live actually
<mdz> jdub: because -686 is the kernel that folks will get by default installing from the edgy desktop CD
<jdub> mdz: and we don't have linux-headers to depend on?
<mdz> jdub: no, we don't
<jdub> bum
<mdz> we could, but I'm not sure I see what that would buy us
<jdub> not having -k7 and -686 installed at the same time
<mdz> apt isn't smart enough to give you linux-headers-somethingelse when you have that kernel
<jdub> but that's just being anal
<mdz> I'm not entirely convinced that we need -k7
<jdub> that'd be a fine solution too ;)
<mdz> we'll find out real quick
<mdz> since -686 will be the boot kernel on the desktop CD
<jdub> of course, not shipping all this crap would be sweeter ;-)
<jdub> oh, going 686 - nice
<mdz> jdub: ;-D
* jdub hates on gcc in desktop seed
<jdub> i wonder what the reception would have been if we'd shipped 686 by default in warty
<jdub> the only really sucky things are geodes and cyrix stuff, right?
<mdz> jdub: you'll get over it
<mdz> and thousands of users will thank us
<jdub> thousands of ex gentoo users will thank us
<jdub> you're just trying to drain gentoo again man
<jdub> "Use Ubuntu: Because Now You Can Bang Two *Smaller* Rocks Together!"
<mdz> thousands of people who need drivers to make their system work will thank us
<jdub> ;-)
<mdz> that's the only use case
<mdz> I went over this in some detail on the mailing list
<mdz> it is not about compiling anything else; in fact you *can't* compile much else with that environment
<jdub> yeah
<jdub> i noticed it's very minimal
<jdub> but i still think it's misdirected
<mdz> being able to build drivers on the live CD is huge
<jdub> it's huge for a tiny portion of users :-)
<mdz> I think it's worse than you think
<jdub> well
<jdub> i know it's bad
<jdub> but i also know what users do
<jdub> "Hrm, back to OS X!"
<mdz> I am not interested in that argument-by-recto-cranial-inversion
<jdub> we're saving maybe 0.5% of users from that fate
<jdub> well you need a recto-cranial-inversion to remember what it's like to be a normal user :)
<jdub> seriously, what is my mum going to do with gcc and non-working wifi?
<mdz> the users we have who are 'normal' are a minority
<mdz> the rest are early adopters
<jdub> she doesn't even know what kind of network card it is
<mdz> your mum neither knows nor cares
<jdub> or which stinky dungeon website she's going to find some source in
<mdz> this doesn't solve your mum's problem
<mdz> but it also costs her nothing
<mdz> she will not even notice the difference
<mdz> so she is irrelevant
<jdub> okay, so if we put her out of the picture
<mdz> so we have two types of users to consider
<jdub> we're helping a tiny percentage of users who will understand this stuff and have the desire to bang two rocks together
<mdz> users who need this in order to follow a how-to and make their system work
<mdz> and users who have a philosophical problem with compilers
<mdz> I have no qualms about sacrificing the latter for the former
<jdub> why can't that howto involve apt-get install gcc (given that it could be in a repo on the cd)?
<mdz> dude, read the thread
<mdz> I explained this a hundred times
<jdub> i read the thread
<jdub> well, i think i read it all
<jdub> was this question raised?
<mdz> apt-get install build-essential on a live CD blows
<mdz> installing gcc just to remove it again is stupid
<jdub> (sorry to turn a cheap gag into a discussion...)
<jdub> well, once it's installed, it's installed and copied to the disk, right?
<jdub> upon distro install
<mdz> correct, and tada, the existing howtos which are, by the way, not written specifically for Ubuntu, magically work
<mdz> they won't all say apt-get install gcc because most of the documentation which exists isn't Ubuntu-specific
<mdz> and they sure as hell won't say apt-get install linux-headers-`uname -r`
<jdub> heh
<mdz> this means that people can go to Intel's driver website, read the instructions, and fix their problem
<Surak> jdub: no, it's not copied to the disk. This will prevent someone from screwing the live cd and installing a borked system.
<mjg59> Why -686 as default?
<mdz> jdub: oh, you meant the driver?  no, the driver won't be copied
<jdub> mdz: (no, i meant after apt-get installing gcc on the livecd, it would be copied to the disk on distro install)
<mdz> mjg59: because you need lots of RAM to boot the live CD, and if you do, you are very likely to have a 686 or better
<jdub> mdz: (but then i realise that the non-modified dm is copied)
<mdz> jdub: oh, that's not true either
<mjg59> mdz: Is lots of RAM inherently true? It's required if you want to get the full gnome stack up, sure
<mdz> jdub: that is, you're correct in your last comment
<jdub> heh, yeah
<mdz> mjg59: booting the desktop CD single-user is a pretty weird use case
<mjg59> mdz: For install purposes, it wouldn't seem unreasonable
<mjg59> We can bring up the installer without bringing up the entirity of gnome
<mdz> the only installer on that CD is a pygtk program
<mjg59> Yeah
<mjg59> But that's still a pretty major saving in memory
<jdub> mjg59: how would you do that? gfxboot option?
<mjg59> jdub: Yes
<mdz> ubiquity and its deps actually eat a lot of RAM, less than GNOME for sure, but you'd still need >64M
<Surak> jdub: "no, i meant after apt-get installing gcc on the livecd" <- That won't happen
<jdub> Surak: read above, it was all talke through
<mjg59> mdz: 128MB was common in the Pentium II era, where all the alternative CPUs were 586 instruction set
<Surak> jdub: oh
* jdub can't wait for jdahlin's pygtk trimming results
<mjg59> mdz: Actually, can we check this from the hwdb results?
<mdz> mjg59: to date, nobody has even noticed as a result of trying to use the CD
<mdz> mjg59: we can, yes
<mjg59> mdz: I don't think I have access to the data
<mdz> mjg59: I don't seem to have a copy anymore, and I forget where it's moved to
<mjg59> But it would be interesting to see how many machines there are with cpu family 5 and 128M of RAM
<mjg59> Who's running it these days?
<mdz> mjg59: I'd be willing to make a small wager on that
<mjg59> mdz: Sure, it's going to be small, but it might be larger than you think
<mdz> PS, the live environment doesn't boot in 128M
<jdub> wager == boxer run at next summit you're both present at
<elmo> mjg59: ogra
<mdz> elmo: but hosted by us now, no?
<mjg59> mdz: But that's because of Gnome, no?
<mdz> mjg59: we can revisit this if you write a stripped-down installation environment and measure its memory requirements
<mjg59> mdz: Sure. I'll have a play.
<mdz> mjg59: but I expect that the set of machines which will be happy running installed GNOME vs. those which can boot that environment would be pretty small
<mdz> and we provide Xubuntu for the low end
<elmo> mdz: not yet
<mjg59> mdz: I agree, but there's a definite set that could potentially be catered to
<elmo> mdz: tho, I think (only since a couple of weeks) that's now blocked on us - I'll file something in RT so it gets done
<mdz> elmo: please CC me on the RT
<mjg59> I'll try to find out the requirements, and I'll try to find out how big that set is
<mdz> mjg59: ogra would probably be willing to get you a shell account to get the stats
<mdz> mjg59: but I'm quite confident that it's fewer than, say, the number of people who will be running Ubuntu on dual core machines next year
* ogra_ wonders why that line didnt highlight ...
<mjg59> mdz: -386 isn't inherently UP
<mdz> mjg59: our -386 is (and must be, as I understand it) UP
<mjg59> mdz: Hm? I thought that was just a policy decision in the dapper timeframe (we weren't confident enough in the SMP rewriting to make it the default kernel)
<Burgwork> mjg59, also remember, the hwdb client has been hidden for dapper, so results may not be entirely accurate
<mdz> mjg59: the kernel team looked into this for dapper and this was the outcome
<mjg59> Burgwork: And not everyone runs it anyway
<ogra_> mjg59, i have a set of 200 000 records on my people.ubuntu.com account ... (5 gig) if you want to have that or as mdz said, you can get a shell account on my server
<mdz> mjg59: no, there was a reason why it couldn't work
<mjg59> But it's potentially indicative
<mjg59> mdz: Suck
<mdz> mjg59: BenC will remember what it was
<mdz> I don't
<Burgwork> mjg59, indeed, but hiding it removes the chance of serendipitious discovery
<mjg59> mdz: Sure, I'll ask him
<jdub> ubiquity should prompt to run it
<mdz> Burgwork: its menu entry was "rightsized"
<Burgwork> it should
<Burgwork> the client should also be expanded to cover the full laptop testing suite, as an option
<mjg59> ogra_: Downloading 5 gig would be a bit of a pain, so an account would help :)
<mdz> ogra: I hope you switched from bzip2 to gzip -9 as I suggested, otherwise mjg59's query will take aeons
<ogra> ergh, nope
<ogra> but the machine isnt the PII 233 anymore ... :)
<ogra> mjg59, try ssh aleph.grawert.net
<mjg59> ogra: Works
<ogra> yep, i see you
<mjg59> ogra: Ok. Where's the data?
<ogra> /var/www/grawert.net/data/hwdb-data/
<ogra> be careful the dir is huge
<mjg59> Ok
<mjg59> One file per submission?
<ogra> yep
<mjg59> Heh
<ogra> and we're near 300000 :)
<ogra> i'm waiting for the ok from elmo to move it, then i'll change to some dir driven sorting ...
* mjg59 manages to pic a Mac at his first attempt
<mjg59> Heh
<mjg59> My second attempt gives me a 586 with 192MB
<ogra> heh
<ogra> yes, there are funny setups in that collection :)
* mjg59 wonders how to actually do this
<mjg59> Ah, this'll do
<mjg59> Oops
<ogra> just dont kill the server, i get my mail through it ;)
<mjg59> Haha
<jdub> that's what they said about the o-rings
<mdz> jdub: they said that ogra gets his mail through o-rings?
<ogra> heh
<jdub> niiiice
<jdub> so upgrade to edgy on my desktop was a bit hairy
<mjg59> mdz: Interestingly, while the absolute number is small, average memory for 586 machines is hovering around 192MB
<Burgwork> mjg59, by absolute number, are we talking less than 50/40/30/20/10/5%?
<mjg59> Burgwork: I don't have useful progress data, so I'll have to wait until it's finished
<Burgwork> right
<mdz> mjg59: I think that's probably due to our analogue of the anthropic principle
<mdz> mjg59: only 586s with that much RAM were able to run the hwdb client :-)
<mjg59> Haha
<tseng> is there a mirror of edgy stuff?
<tseng> the knot1 cds
<mdz> tseng: I believe so; see the knot release announcements
<tseng> ah
<tseng> umu, thanks
<mc44> hmm any ideas when the next community council meeting might be?
<tseng> mc44: there is a calendar on fridge.ubuntu.com
<mc44> tseng: yes with no CC entries...
<mjg59> Oh, hang on, this machine doesn't have a DVD burner...
<tseng> The next meeting of the Council will be at to be announced on #ubuntu-meeting on irc.freenode.net
<tseng> https://wiki.ubuntu.com/CommunityCouncilAgenda
<tseng> funny.
<mc44> heh
<mc44> there hasnt seemed to be much notice of the CC meetings recently...
<mc44> maybe jono will sort them out :)
#ubuntu-devel 2006-08-09
<Kamion> mjg59: it'd be much appreciated if you could do something like my suggested usplash.postinst change above. I'm just idly browsing through my bug mail and I have quite a lot that's down to the edgy live filesystems not having built for a while.
<mjg59> Kamion: Ok
<mjg59> mdz: Kamion: A quick play suggests savings of around 50MB from not starting Gnome
<mjg59> But
<mjg59> On i810 systems, X is allocating a /huge/ amount of RAM on startup in order to be able to do 3D and stuff
<mjg59> We could drop memory consumption by 100MB or so by asking it not to do that when just running the installer
<mdz> mjg59: er, it allocates *100MB*?
<mjg59> That's 100 including the 50 or so above)
<mdz> oh
<mjg59> mdz: No, probably more like 40
<mdz> still, 50MB?
<mjg59> mdz: Running X in 16 bits with no 3D, with ubiquity running, memory used is 93MB
<Kamion> you need to run ubiquity up to partman or so to get to the memory use peak, really
<mjg59> That's including the memory allocated for video
<mjg59> Kamion: Yeah
<Kamion> or possibly even gparted
<Kamion> C++ being the fat piece of crap it is
<mdz> mjg59: but once ubiquity has finished its job and you boot, those memory requirements go way up again
<mdz> swap compensates somewhat, of course
<mjg59> mdz: Indeed
<mjg59> Kamion: Right, this is more a relative measurement than an absolute one
<mjg59> But right now we have systems that will run Gnome acceptably that can't quite manage the desktop CD installer
<mjg59> I think it's possibly worth reducing that requirement a bit
<poningru_> real quick question http://plaza.ufl.edu/poningru/postinst
<poningru_> doesnt that seem like bash and not sh
<poningru_> perhaps /me should have waited till Seveas came in to ask that question
<Kamion> poningru_: I see no bashisms there. What do you think is a bashism?
<poningru_> the ' for variables
* poningru_ thought sh didnt like those
<Kamion> poningru_: what line exactly?
<poningru_> first and second
<Kamion> distinguishing between ` and ' is rather important in shell
<poningru_> wtf those are new lines
<Kamion> but no, that's perfectly fine, nothing wrong with that in sh
<HrdwrBoB> ` should be $(
<Kamion> ` is fine
<HrdwrBoB> for readability sake
<Spads> $( ) are bash
<Kamion> $( nests better but ` is fine
<Seveas> HrdwrBoB, $( is a bashism
<Kamion> Spads: also POSIX sh
<Spads> ` ` is sh
<elmo> Spads: no
<HrdwrBoB> Seveas: er
<Kamion> Seveas: wrong
<elmo> Seveas: no
<poningru_> ah
<Spads> huh
<Seveas> hmm
<pitti> good night everyone
<poningru_> thanks
* Seveas fires up susv3
<Kamion> http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
<poningru_> then I think the sh highlighting view in gedit has a bug
<Spads> likewise vim
<Kamion> poningru_: that is entirely unsurprising; editors aren't good metrics of what's valid
<Spads> it flags them red when you're #!/bin/sh but not #!/bin/bash
<Kamion> it probably means Bourne sh rather than POSIX sh
<Kamion> which is good if you're on Solaris but nobody else cares any more
<Spads> yeah, most likely
<Seveas> ahhhh
* Seveas still works on solaris from time to time 
<elmo> Seveas: then you get to use the posix compatabile shell they provide
<Kamion> poningru_: (by "nothing wrong with that", obviously it's poor quoting etc., although in practice that won't be a problem in this case)
<elmo> it still doesn't make $( a 'bashism'
<Seveas> elmo, actually I get to use tcsh :( 
<Kamion> if anything it's a korn-sh-ism
<elmo> no, I mean the one in /usr/xpg4/bin/sh or whatever it is
<elmo> i.e. "the shell we'd like to be /bin/sh if we didn't have legacy systems of doom tieing us down"
<Seveas> hehe
<Seveas> dkaarsem@sremote ~ $ /bin/sh
<Seveas> $ $(echo ls)
<Seveas> syntax error: `$' unexpected
<Seveas> yup, solaris sucks ;)
<poningru_> rofl
<imbrandon> lol @ Seveas
<jono> night all
<infinity> Kamion: No, /proc is definitely mounted during livefs builds...
<MasterM> I love the concept behind ubuntu
<MasterM> but i just prefer windows.
<MasterM> ill use ubuntu as a live dvd
<MarkShuttleworth> Hello ;)
<Hobbsee> er...
<Hobbsee> why are you under as that name?
<MarkShuttleworth> It's Mark.
<nixternal> heh, imposter again
<MarkShuttleworth> I just came back from outta space.
<MarkShuttleworth> How is everyone?
<nixternal> outta space...must be an ebonics thing
<MarkShuttleworth> hehe.
<Hobbsee> MarkShuttleworth: rubbish.  dont impersonate people.  and this is a development channel, not a user channel.
<MarkShuttleworth> I'm not. it's Mark i just came back from Mars.
<jsgotangco> oh boy
<nixternal> Hobbsee: he was here yesterday doing the same thing, actually had sabdfl choke ;)
<MarkShuttleworth> lol
<MarkShuttleworth> it's funny come on!
<madduck> /ignore MarkShuttleworth    -- this is your one time chance. :)
<MarkShuttleworth> I respect ubuntu...
* jsgotangco doesn't find it funny at all
<madduck> MarkShuttleworth: uh, change your nick, sam.
<jsgotangco> thank you
<licio> :-|
<MasterM> Can I ask a question?
<ompaul> MAsterm  nalioth 
<nixternal> lol
<ompaul> MarkShuttleworth (n=sam@219-89-6-148.dialup.xtra.co.nz) has joined #ubuntu-devel
<ompaul> or as he wanted to be called 
<MasterM> do you all use ubuntu or do you use windows too?
<nalioth> MasterM: have these nice folks asked you to depart?
<nixternal> MasterM: #ubuntu-offtopic please, this is a developers channel. thank you
<MasterM> Mok
<MasterM> ok.
<ompaul> I've already moved him out of #ubuntu
<nalioth> yes, i know Mr. Sam
<MasterM> #ubuntu-offtopic unable to join channel (address is banned)
<MasterM> unban me
<MasterM> please.
* mode/#ubuntu-devel [+o nalioth]  by ChanServ
* mode/#ubuntu-devel [+b *!*@219-89-6-148.dialup.xtra.co.nz]  by nalioth
* mode/#ubuntu-devel [-o nalioth]  by nalioth
<nalioth> ok, back to your regularly scheduled lives
<LaserJock> nalioth: but this is the only fun we get ;-)
<Fujitsu> Thankyou nalioth!
<zul> i rather work..:)
<nalioth> LaserJock: i can let him back in, if you like <EG>
<LaserJock> nalioth: yikes, no thanks
<nixternal> haha
<nixternal> yesterday was funnier though
<nixternal> sabdfl called him an imposter
<imbrandon> heh
<LaserJock> yeah, that was pretty funny
<Fujitsu> Yep, that was good.
<imbrandon> sab should probably reg that name anyhow just to twart peeps like that
<zul> heh maybe sabdfl flew to nz to log on to irc
<imbrandon> thwart
<Fujitsu> Of course, zul! Why didn't we think of that :P
<zul> oh goody he is on -bugs now
<jsgotangco> ughh
* Fujitsu explodes him.
<nixternal> <sabdfl>    *cough choke splutter*
<nixternal> <sabdfl>    imposter
<nixternal> classic ^^
<Fujitsu> Nice! I've never seen him do that before...
* Hobbsee doesnt have ops on -bugs :(
<ajmitch> heh
<Fujitsu> No.
<Fujitsu> Only three people do.
<Fujitsu> Seveas, dholbach, some other random person.
<Fujitsu> coleSLAW, that's it.
* Hobbsee should probably ask for ops there too.
<Burgundavia> anybody else get a usb error -71 on the lastest desktop cd?
<zul> dapper?
<Burgundavia> edgy
<Burgundavia> hmm, and LP search is being useless, again
<Fujitsu> How?
<zul> Burgundavia: all the more reason to open a new one with all of your info including dmesg
<Burgundavia> zul: not a fatal error, so I ignored it
<wasabi> So, opinions on launchd?
<Burgundavia> wasabi: interesting, still a problematic license
<Burgundavia> why could they not have chosen the lgpl?
<wasabi> Is it?
<wasabi> What's the license?
<shackan_> apache
<wasabi> Had assumed they would have chosen the same one they did for Bonjour.
<Burgundavia> asl2 is not gpl-compatible or it is, depending on who you believe
<Burgundavia> and they did
<wasabi> Hmm. Was my impression the Bonjour one was BSD.  *goes to look it up*
<Burgundavia> some of the bonjour stuff is, some isn't
<ompaul> inarLLrion arpw dILWS 
<ompaul> sorry 
<wasabi> Ahh. Oh well. If the license is still a problem, any furthur talk is unneccassary.
<shackan_> ompaul, get the cat off the keyboard :)
<Burgundavia> not necessarily
<wasabi> Any talk would center on the technical merits of replacing init heh
* ompaul sneeks into #ubuntu-bugs to report what he sees on screen :) 
<Burgundavia> the other concern I have is that launchd is controlled by apple
<Burgundavia> given their past history, I am not certain that a fork won't emerge anyway
<wasabi> Eh. If it was BSD, we could have just forked. ;)
<shackan_> so they opened it but with such a license that noone can use it anyway ?
<Kamion> wasabi: Keybuk says his implementation is already at the point where rebasing on launchd would be a backward step.
<wasabi> Keybuk is working on something??!?!
<Kamion> yes, has been for weeks
<wasabi> Oh heck. Didn't get hte memo. url?
<Kamion> http://wiki.ubuntu.com/ReplacementInit
<wasabi> Duh. :0
<Burgundavia> wasabi: he has also had lots of interest from other distros
<wasabi> Okay. Cool. I'll read up and withdraw my interest in launchd. ;)
<wasabi> Yes. I like keybuk's plan much better. It allows for a much more flexible system.
<wasabi> I like the idea of broadcasting "depended on" as an event.
<wasabi> It's also more in the unix style... communication through simple unix sockets, simple text based configuration.
<wasabi> not xml.
<bddebian> Heya
<bluefoxicy> "among distributions that will break with the new 2.6.19 kernel are Ubuntu 6.06 LTS"  Who cares?  Seriously nobody is moving Dapper up past 2.6.15 and if they do then they can move udev up too.  The author of this article doesn't have a concept of distribution management.
<bluefoxicy> <-- very bored
<dholbach> good morning
<pitti> good morning
<dholbach> morning pitti!
<pitti> hey dholbach!
<mdeslaur> morning pitti
<pitti> hi mdeslaur 
<imbrandon> moins all
<pitti> infinity: do you have a minute to talk about .ddebs?
<jdub> whoa
<jdub> major xgl/compiz blowup
<jdub> compiz.real: Couldn't bind redirected window 0x1600020 to texture
<dholbach> jdub: ajmitch is the new maintainer :)
<infinity> pitti: Yup.
<pitti> talking about crack, now that we have xorg 7.1, shouldn't we have aixgl now, too?
<dholbach> pitti: isn't that xserver-xorg-air-core?
<infinity> aiglx, even.
<pitti> infinity: so, I guess copying the .ddebs to an outside place is possible, since it worked for translation tarballs, too; however, the problem will be the size of those .ddebs
<infinity> pitti: Yeah, they'll be frickin' huge.
<pitti> infinity: thus we need to ensure to not keep them on the buildds at all, and properly dominate them on people (or whereever)
<pitti> infinity: can we distinguish between main/universe?
<infinity> pitti: Yes, of course we can.
<pitti> so maybe we should enable it for main only, at least for now
<infinity> adconrad@rookery:~ $ df -h /      
<infinity> Filesystem            Size  Used Avail Use% Mounted on
<infinity> /dev/sda3             537G  279G  231G  55% /
<infinity> I guess there's enough room, though elmo will kill us pretty quickly when we get enough of them up there.
<Lathiat_> excuse my ignorance but whats a ddeb?
<pitti> Lathiat_: debug symbols for the corresponding .deb
<Lathiat_> ah right
<pitti> infinity: my gut feeling is that we'll need the magnitude of 20 GB per architecture
<infinity> pitti: I guess Team Soyuz is flat out right now, and asking them to just handle these in .changes files is out of the question? :)
<pitti> infinity: well, that's the plan of course, but it won't happen anytime soon :(
<infinity> (Probably very much the case)
<infinity> pitti: Alright.  So, you're doing one .ddeb per binary package, right?
<pitti> so this cowboying is mainly useful for developers to actually make sense of the crash reports we'll get
<pitti> infinity: right
<infinity> pitti: Alright.  If we're going to tie them to sources and such, I guess I'll have to generate a fake .dchanges file to tie source/version/ddebs, then send 'em to rookery.
* MarcelDel Snickers
<pitti> infinity: would the following work: people.u.c. fetches ddebs from the buildds once a day, and the buildds remove them every day?
<infinity> pitti: Domination will probably have to be as simplistic as "one per source package, per arch, highest version wins", rather than trying to actually match the archive contents.
<pitti> infinity: domination> right, that's what I had in mind
<MarcelDel> pitti, do you work on ubuntu?
<pitti> infinity: and, for gradual disk space DoSing, maybe we should enable it for only i386 at first
<Amaranth> Warning, that's the troll from earlier.
<MarcelDel> troll?
* pitti points MarcelDel to the channel topic
<infinity> pitti: Works for me, as long as you're sure the detached symbols work on all arches.
<pitti> infinity: no, they won't
<infinity> pitti: Would be a shame to only test on i386, and then realise that it actually breaks on, say, powerpc.
<infinity> pitti: If it's broken on ia64, I don't care. :)
<pitti> infinity: that's true of course
<infinity> (And gdb is always broken on ia64 anyway)
<infinity> pitti: I didn't mean "the one set of symbols should work everywhere", I meant "the concept should work everywhere", which would be nice to verify. :)
<pitti> infinity: once it works, we can always enable more arches, right?
<infinity> pitti: Well, yeah, obviously.
<pitti> infinity: ah, right
<pitti> infinity: ok, then I would write some scripts to fetch the ddebs from the buildds (stealing some stuff from lamont's scripts) and to clean up old versions
<pitti> infinity: btw, we can free 41 GB on rookery by removing old translation tarballs :)
<pitti> carlos: ^ oh, can we be reasonably sure to not need them any more? i. e. how is rosetta/edgy coming along?
<infinity> pitti: Yeah, do we even need them being exported to rookery anymore at all?
<pitti> infinity: I hope not :)
<pitti> infinity: I haven't used them since before dapper's release
<robtaylor> dholbach: when you get a moment, can you ping daf on #telepathy? he's been doing debian telepathy packaging, so i think you guys probably need to sync...
<dholbach> ah nice
<robtaylor> i think we have a repo for packaging now as well :)
<dholbach> robtaylor: adding it to the join-on-startup list :)
<robtaylor> dholbach: sweet :)
<robtaylor> ok i need to go fix up my cycle.. laters :)
<Treenaks> dholbach: watch out for the freenode channel limit
<dholbach> Treenaks: yeah :)
* pitti wonders why archive.u.c. still has apport 0.6, although soyuz has 0.8 for 12 hours now
<infinity>     apport |        0.8 | edgy/universe | source, all
<infinity> pitti: It's published on drescher, so if you have a stale archive mirror, yell at Znarl. :)
<pitti> infinity: hm, in order to avoid race conditions, we need per-date subdirectories on the buildds
<infinity> pitti: Already had that for translations anyway.
<infinity> sabdfl: Registering markshuttleworth as an alternate nick?
<pitti> infinity: so, if rookery fetches http://*.buildd/~buildd/ddeb/2006MMDD/index.txt and everything mentioned in index.txt every day at 0030 UTC, and the buildds remove this dir at 0200 UTC every day, woudl that work for you?
<sabdfl> infinity: yes
<infinity> pitti: Assuming that's YYYYMMDD-1, then yes. :)
<sabdfl> infinity: it told me that it would expire in 60 days unless I identify to it
<sabdfl> is there a way to automated that to hold onto a set of nicks?
<infinity> Whine to lilo?
<infinity> Otherwise, not sure.  I don't use altnicks.
<infinity> Of course, you could write a quick irssi perl script to do the identification for you every 24 hours or something.
<infinity> (Or whatever client you use, X-chat has scripting too)
<sabdfl> good call - lilo fixed it
<infinity> Well, I think your cloak screams "lilo needs to pay attention to me occasionally", so that works. :)
<pitti> infinity: what would be a convenient format of index.txt for you?
<infinity> pitti: Do we even need one?
<pitti> infinity: does buildd's apache have autoindex?
<infinity> pitti: Yeah.
<pitti> ok, then we don't
<infinity> pitti: And if it doesn't, I can turn it on. :)
<pitti> yep, seems to work
<infinity> pitti: I will generate source_version_arch.dchanges files from sbuild that list all the ddebs, and the source name and version.
<infinity> pitti: Which should make domination and reaping a bit tidier.
<pitti> infinity: that's mainly for correct epoch handling, right?
<pitti> oh, also for NBS
<infinity> pitti: Well, that and being able to tie all the ddebs together as a single entity.
<pitti> ok, great
<pitti> I hope that won't be too much work for you
<lucas> ouch. both kdeedu and kgeography src packages generate a kgeography binary package
<infinity> Nah, that's easy enough.  It won't be a full .changes file, just a cut-down version with only the fields required.
<lucas> how is that allowed ?
<infinity> lucas: It means one of them needs to stop, that's all.  Binary packages move between source packages all the time.
<pitti> lucas: whichever has the higher version number wins
<pitti> in this case, kdeedu wins both version-wise and component-wise
* infinity decides it's time to run out to the computer store and get an external hard drive for backup and livefs-testing.
<carlos> pitti: I got the approval to merge the code that will open edgy based on dapper
<carlos> pitti: so it's a matter of polish it a bit today
<pitti> carlos: cool
<carlos> and merge it into production
<Hobbsee> hi carlos, pitti 
<pitti> carlos: I mean, can we stop the buildd->people hack for translation tarballs?
<carlos> pitti: I think so. It's useful for debugging purposes but it's not a must
<carlos> Hobbsee: hi
* carlos -> out
<carlos> will be back in 30 minutes
<hunger_work> pitti: I replied to your questions on #54530.
<pitti> ah, thanks
<pitti> hunger_work: "/dev/zero can not be mmaped" sounds a bit like a noexec fallout, although I don't see the point of mmap'ing /dev/zero in the first place ;)
<hunger_work> pitti: Yeap, I thought so too, that is why I mentioned it.
<hunger_work> pitti: OTOH /dev/zero's permission do not include execute, so noexec shouldn't matter.
<pitti> hunger_work: however, mmap() allows you to specify PROT_EXEC
<hunger_work> pitti: mmapping /dev/zero is a trick to get a big pre-zeroed area of memory.
<pitti> bah, isn't memset() much more effective for that?
<hunger_work> pitti: PROT_EXEC is about the pages in momery. I doubt that has anything to do with the filesystem permissions.
<pitti> I don't know it either, it just came to my mind as a possible explanation
<StevenK> Or calloc()?
<hunger_work> IIRC the kernel catches mmaps to /dev/zero and does some magic... so it shouldn't matter.
* ogra kicks python ...
<pitti> ogra: ?
<hunger_work> pitti: You might be right: PROT_EXEC may not conflict with the open mode of the file. Maybe someone opened /dev/zero with exec set? Dunno whether that is at all possible for a file that is in mode 666:-)
<ogra> why doesnt it have a os.mount command ... grmbl
<pitti> ogra: it's not portable at all, that might be the reason
<ogra> yeah 
<ogra> but it would be sooo elegant :)
<pitti> well, subprocess.call(['/usr/bin/mount', device] ) isn't that much worse :)
<ogra> sure, but i need to call subprocess :)
<hunger_work> pitti: And that with python not even having a cpp to handle such issues;-)
<ogra> os.mount(['/usr/bin/mount', device] ) would be cooler :)
<pitti> ^ looks funny
<ogra> well ...
<ogra> *grin*
<pitti> ogra: #define subprocess.call os.mount ;)
<ogra> heh
<pitti> (pre-processor in python 9.3)
<StevenK> pitti: 9.3 ... ?
<pitti> StevenK: well, it's not yet in 2.5, so I guesstimated :)
<ogra> StevenK, might also be in 9.2 already  ;)
<pitti> (well, preprocessor is not pythonic at all, they won't add it anytime soon)
<StevenK> pitti: :-P
<ogra> pitti, btw, whats the reason we dont use dev.cdrom.lock=0 in /etc/sysctl.conf ? is there some drawback i'm not aware of ?
<pitti> ogra: bug 35695
<Ubugtu> Malone bug 35695 in procps "Please change sys/dev/cdrom/lock default to 0" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/35695
<pitti> ogra: however, we need to make sure to clean up properly (lazy unmounting)
<pitti> ogra: and since hal/g-v-m handle the drive eject button nowadays in a much cleaner way, I didn't bother to work on that
<ogra> heh, supermount-ng
<ogra> the name of superlatives 
<ogra> pitti, well, i have no g-v-m running on the thin clients :)
* pitti renames pmount to hypermount-o-matic 2000 MEGA EDITION
<ogra> but i'll implement a unlock call in the python script that mounts/monitors the cd
<ogra> i was just wondering why we dont have it by default ...
<pitti> ogra: instead of changing the sysctl default, maybe you can just set it dynamically in ltsp?
<ogra> but the bug explains it ... even though xubuntu might probaby want to enable it
<ogra> pitti, yes, see above, thats what i'm doing :)
<ogra> fcntl.ioctl(f, CDROM.CDROM_LOCKDOOR, 0)
<pitti> ah, cool
<Hobbsee> hi all.  i'm trying to merge:  magic-haskell, and get magic-haskell_1.0.3-0.1ubuntu1.dsc: Version older than that in the archive. 1.0.3-0.1ubuntu1 <= 1.0.3ubuntu1.  what should i upload the new version as, to overwrite both ubuntu and debian versions?
<pitti> Hobbsee: 1.0.3ubuntu2 seems most logical
<pitti> erm, wait, no
<pitti> 1.0.3ubuntu1 is a native package version
<Hobbsee> pitti: that's what i thought, then wait to fix it for the new upstream version, whenever that happens?
<pitti> so this is seriously screwed
<Hobbsee> yes.  heh
<pitti> Hobbsee: I'd propose 1.0.3ubuntu1-1
<Gloubiboulga> pitti, I think we've used versions like 1.0.3ubuntu2 already
<Gloubiboulga> Toadstool, around?
<Hobbsee> pitti: right.  which is native again, presumably
<Toadstool> Gloubiboulga: yep, waking up :)
<StevenK> Hrm, that's a point.
<Hobbsee> pitti: sistpoty was the one who seemed to version it that way.  hmm.
<Toadstool> hi everybody
<pitti> Hobbsee: ah, ok; Debian just had an NMU
<Hobbsee> hi Toadstool 
<Gloubiboulga> Toadstool, I think you've already had a similar issue, right?
<pitti> Hobbsee: so it indeed *is* supposed to be a native package
<pitti> Hobbsee: 1.0.3ubuntu2 is fine then
<Hobbsee> right
<Toadstool> Gloubiboulga: misversioned NMU for Debian native packages?
<Gloubiboulga> yes
<pitti> well, not exactly 'mis'versioned
<Hobbsee> pitti: okay, cool
<StevenK> pitti: Sure it is.
<pitti> debian NMUs are not supposed to 'steal' upstream version numbers
<pitti> although 1.0.3.1 would have been more appopriate
<StevenK> That's what I was going to suggest.
<azeem> there's some dispute on how to version NMUs for native packages I think
<StevenK> Add a .1 seems to work.
<pitti> I still remember doing an NMU for one of iwj's packages and got seriously larted for stealing an upstream version number
<Toadstool> well, i said misversioned 'cause it breaks the -ubuntuX scheme ;)
<azeem> Toadstool: one could argue Ubuntu uses a broken versioning scheme for native packages :)
<Toadstool> :)
<robtaylor> azeem: -$DEBVER[.$DEBNMU] -ubuntu$UBUNTUVER[.$UBUNTUNMU]  ? ;)
<dholbach> robtaylor: there are no NMUs
<dholbach> robtaylor: in ubuntu :)
<infinity> No, but we use NMU versioning in -security and -updates to avoid version overlap with newer releases.
* pitti wonders what /proc/<pid>/mem is good for; I can neither read nor mmap() it
<pitti> oh, it's only usable from the <pid> process itself. how (un)useful
<pitti> mvo: this burning black baloon scares me :)
<mvo> pitti: what a couple of seconds and it will explode ;)
<pitti> mvo: an exploding baloon? argh :)
<pitti> mvo: maybe we should turn it upside down and mape it less pear-shaped
<pitti> mvo: s/mape/make/
<pitti> mvo: I'll play with it a bit
<mvo> :)
<infinity> Can anyone think of a filesystem, other than vfat, that has great read/write support in both Win32 and Linux, and doesn't suck?
<Fujitsu> No.
<Fujitsu> There isn't one.
<Fujitsu> smbfs :P
<infinity> Local filesystem. :)
<Fujitsu> UDF? :P
<infinity> Yeah, I thought of that.  Not sure what Windows will do with a hard drive formatted with UDF.
<Fujitsu> I was wondering if it'd like it...
<jdub> infinity: iso9660?
<infinity> jdub: iso9660 is read-only.
<jdub> infinity: devices are read-only :-)
* StevenK ponders how to be evil and parse the Depends of a .deb in shell.
<infinity> If I wanted read-only, I'd be happy with NTFS, or even vfat, but I want something format an extrenal hard drive for sneakernet backups.
<StevenK> infinity: What about ext2? You can get a extension for Windows to read/write it.
<Fujitsu> And what's wrong with vfat?
<azeem> "can get"
<tseng> its kind of crap how that works
<infinity> StevenK: Yeah, I'm reading up on those now.  They seem to have improved since I last looked.
<tseng> besides not being OOTB
<Fujitsu> infinity, they work great.
<infinity> Fujitsu: vfat's just... Fragile.
<infinity> Fujitsu: Especially for 400GB of data.
<Fujitsu> infinity, that's true.
<dholbach> ogra: if you do the gnome-screensaver update: please drop the schema patch and use debian/gnome-screensaver.gconf-defaults - you can use gnome-applets as an example to look at
<dholbach> ogra: that's less pain for the next upstream schema changes
<ogra> ok
<dholbach> gracias
<pitti> Kamion: are there any further issues with the dapper update that need testing?
<Kamion> pitti: no - in fact publication is in progress
<pitti> yay
<pitti> Hobbsee: ping
<pitti> ajmitch: ping
<ajmitch> pitti: pong
<pitti> ajmitch: I'd like to make you and Hobbsee administrators for ubuntu-universe-sponsors; are you fine with that?
<ajmitch> sure
<Kamion> pitti: when was the last thing you published to dapper-security?
<pitti> Kamion: this morning, around 0700 UTC or so
<Kamion> pitti: doh. can you give me a list of what you've published to dapper-security over the last four days or so?
<StevenK> Kamion: Hey, aren't you on holidays?
<Kamion> because I need to make sure to keep the state of the archive at dapper.1
<pitti> Kamion: only libwmf from this morning
<Kamion> StevenK: doing dapper point release
<Kamion> (otherwise yes)
<pitti> Kamion: it's a small update, doesn't really need to be on the CDs
<Kamion> pitti: I know, I just need to construct an archive snapshot minus that
<Kamion> i.e. what matches the CDs
<pitti> oh, I see
<pitti> Kamion: it might be helpful that this is the first libwmf security update ever
<Kamion> because we don't have the proper soyuz stuff yet
<Kamion> it is :)
<Kamion> ok, I'll just hack that out
<pitti> Kamion: i. e current archive minus libwmf {hoary,breezy,dapper}-security versions is the thing you want
<pitti> sorry for the trouble
<Kamion> no problem
<Kamion> I should have taken the archive snapshot a few days ago really
<pitti> Kamion: previous security update was gnupg from last Thursday
<pitti> Kamion: 1.4.2.2-1ubuntu2.2 for dapper
<pitti> Kamion: and that's on the CDs
<Kamion> yep
<pitti> wb carlos 
<carlos> pitti: hi
<Hobbsee> pitti: pong
<Hobbsee> pitti: sounds good to me
<pitti> Hobbsee: hereby I declare you a master of the universe sponsors :)
<Hobbsee> pitti: yay :)
<Hobbsee> pitti: what can i do now then?
<ajmitch> Hobbsee: kick the MOTUs into sponsoring stuff
* Hobbsee bows.  er, curtsies.
<pitti> Hobbsee: well, since it's an open team there isn't much to administrate
* Hobbsee kicks ajmitch into actually doing some MOTU stuff.
<Hobbsee> pitti: right
<pitti> Hobbsee: but in the long term I'd like to hand ownership to a MOTU
<Hobbsee> pitti: so i can just cause general havoc with it
<ajmitch> like usual
<pitti> since I think MOTUs should be self-supporting
<ajmitch> pitti: agreed
<gnomefreak> dholbach: ping
<pitti> Hobbsee: you can kick people and write them rude comments about expelling them, and such :)
<Hobbsee> pitti: my first response to that was "so why are you handing it over to me"
<Hobbsee> pitti: ooh!  fun!
<pitti> Hobbsee: I didn't hand it over yet, but if you want to, I'll do it now
<Hobbsee> pitti: sounds good to me :)
<gnomefreak> Hobbsee: your trustworthy and good at what you do?
<Hobbsee> pitti: my point was more, it took me a while to realise that i fit into that MOTU category
<gnomefreak> congrats Hobbsee ;)
<Hobbsee> gnomefreak: me?  trustworthy?  you talking in irc, or in anything important here?
* Hobbsee is just one big clown on irc :P
<Hobbsee> i think that most people know that by now :P
* Hobbsee is trustworthy.  yes.
<pitti> Hobbsee: it's your's now
<Hobbsee> pitti: thankyou :)
<gnomefreak> if i compiled a tar without issues does that mean its a good chance that building it for ubuntu should be ok?
<Hobbsee> pitti: i even *own* it.  cool!
* Hobbsee notes again that she hasnt gotten anything from the ubuntu-devel mailing list in a while.
<pitti> Hobbsee: now it's *your* job to find a nice emblem, not mine any more :-P
<ajmitch> Hobbsee: that's sort of what handing over means :)
<Hobbsee> pitti: hehe!  that's what i was just thinking about
* infinity keeps making emblems for all of his teams out of sheer boredom.
* gnomefreak has a cute little penguin ;)
<Hobbsee> pitti: where's the recommended place for emblems?
<Hobbsee> infinity: hehe.  emblems are pretty, anyway
<Hobbsee> hmm..  theres' a field marked contact address too.
<pitti> Hobbsee: 'where'?
<Hobbsee> hmmm?  where's as in, where is
<pitti> Hobbsee: usually it's in the blue box with your Karma and name
<infinity> Hobbsee: Make one!  Pixel art is fun.
<infinity> Hobbsee: And you can't actually upload it without being a team admin, or an LP admin.
<Hobbsee> pitti: no, i realise that.  more was a question of "where do you usually get your emblems from"
<pitti> Hobbsee: yes, they are nice badges you can pin on your shoulder, or LP homepage for that matter :)
<Hobbsee> pitti: hehe
<pitti> Hobbsee: so far I stole them from /usr/share/icons, I'm not an artwork dude at all
<Hobbsee> infinity: what, the team owner doesnt count in that?  :P
<Hobbsee> pitti: ahhhh...
<infinity> Hobbsee: I mangle GNOME icons and bend them to my will for fun and profit.
<Hobbsee> infinity: hehe, right
<pitti> infinity: she just became admin and owner of ubuntu-universe-sponsors
<infinity> pitti: Ahh, I was looking at the wrong sponsors team (the one I'm a member of, for main) cause I'm half asleep.
<infinity> pitti: Should I make an emblem for that one for you? :)
<pitti> infinity: if you feel like it, of course :)
* pitti looks forward to collecting yet another badge
<pitti> doing this stuff occasionally is fun, some months ago I spent about an hour doing a Hackergotchi for me
<infinity> pitti: It's a good way to waste "awake, but not awake enough to do useful work" time.
<pitti> Hobbsee: right, while you are at it, create a hackergotchi for you :)
<Fujitsu> Yep.
<pitti> infinity: heh, I know that feeling, for me it's usually the time around midnight
<ajmitch> pitti: or we could supply one for her
<Hobbsee> infinity: art never was my strong point.  although i do get the credit for kubuntu edgy being purple, as i suggested it :P
<Hobbsee> pitti: heh.  i break cameras.
* Hobbsee has terrible photos.
* StevenK has managed to avoid getting a hackergotchi.
* StevenK also photographs badly.
<infinity> Hobbsee: Ahh, I've been doing various visual art for longer than I've been programming, so the pixel art is kinda midnless and fun.
<infinity> mindless, too.
<Hobbsee> oh, who's the channel creator person in here?
<Hobbsee> ie, the top top person for this irc channel
* TheMuso always manages to appear like he is looking the wrong way in photos.
<infinity> If only I could also upload theme music for my teams.  It'd be all like LaunchMySpacePad.
<pitti> lol
<StevenK> Hobbsee: ChanServ says thom.
* StevenK brutally hurts infinity.
<Hobbsee> StevenK: hmm.  never spoken to him before, iirc
<TheMuso> Even though from my pov, I'm not.
<Hobbsee> heh
<Hobbsee> infinity: ooh, scary.  does that mean i can add a custom background to the page, also matching my myspace? *g*
* Hobbsee thinks that would be FUN!!!!
<Hobbsee> dont you think so, StevenK?
<infinity> Hobbsee: For universe-sponsosrs/main-sponsors, I was thinking they typical "helping hand" (ie, two hands, interlocked) iconography for universe, and the "iron fist" for main.
<StevenK> AAAIIIIIIIIIIIIIEEEEEE
<Hobbsee> ROFL!
* StevenK falls to the floor and convulses.
* thom sees his name being taken in vain
<infinity> thom: You still own #-devel.
* Fujitsu takes thom's name in vain.
<Hobbsee> thom: heya, can we get some more ops in this channel please?
<thom> yay me
<infinity> thom: Apparently.
<StevenK> TheMuso: Mr Planetary Tramp!
* pitti wants the sound of an old dot matrix printer in graphics mode as jingle for ubuntu-printing
<TheMuso> StevenK: heh
<StevenK> DOH!
<StevenK> thom: Mr Planetary Tramp!
<thom> StevenK: still not mastered irc? ;p
<thom> Hobbsee: um, yes
<StevenK> It's not IRC, it's typing. :-P
<infinity> pitti: That could be tricky.  How about just the curled edge of old-skool tractor-feed paper?
<thom> i'm open to suggestions
<maswan> pitti: one printing text (or something else variable) in graphics mode I hope?
<pitti> infinity: but the dot matrix printer makes you fall off your chair much harder
<TheMuso> StevenK: It sort of applies. :p
<pitti> at least the ones I heard in my life
<thom> Fujitsu: hey, give that back!
* Fujitsu runs away with thom's name.
<infinity> pitti: I do like the satisfying zip of an old Raven 24.
* Fujitsu encrypts it and wipes the original.
<Hobbsee> thom: right.  i'm one, i'm not sure who beyond that.
* infinity should get one at a flea market or somehting.
<maswan> I wonder if I could manage to get an apple imagewriter ii up and running
<pitti> infinity: the old Epson I once had sounded more like a circular saw
* Fujitsu hides laptop and other computers with 9d1d4025.
<infinity> thom: I suppose I could be added to the op list, since I (apparently) never sleep.
<thom> Hobbsee: launchpad id? 
<Hobbsee> thom: should be under as hobbsee.  i think
<thom> infinity: you were about to have it inflicted indeed
<Hobbsee> hi sabdfl 
<maswan> It had a rather nice and smattering sound, in addition to the whine
<Fujitsu> Hi sabdfl!
<tseng> infinity: I don't sleep, either
<sabdfl> hey guys
<pitti> welcome back sabdfl 
<tseng> morn sabdfl 
<gnomefreak> Hobbsee: it looked like you had 2 ;)
* Hobbsee looks for a nice looking icon
<tseng> the real one, this time
<gnomefreak> hello sabdfl 
<Hobbsee> gnomefreak: say what?  2?
<Fujitsu> tseng, hahah.
<gnomefreak> Hobbsee: thats what a search pulled up 1 with no karma and 1 with 200k
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<Hobbsee> ah ha!  thanks thom 
* Fujitsu applauds Hobbsee.
<tseng> oh cool
* Hobbsee has completed yet another step of world domination
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<pitti> Hobbsee: accumulating power today? :)
<Hobbsee> pitti: yeah.  arent i always?
<Hobbsee> :P
<pitti> phear!
* Fujitsu fears almighty Hobbsee.
* Hobbsee puts her hands on her hips and looks around bossily.
<Hobbsee> does it work?
<tseng> Hobbsee: how cute
* tseng hides
<Fujitsu> Please spare me, for I am just a poor little MOTU-wannabe.
<Hobbsee> HAH!
* TheMuso runs away from Hobbsee but runs into a wall. :p
* Fujitsu agrees with tseng.
<TheMuso> I can't escape. :)
<thom> there's a reasonable collection of people on the list now
<pitti> Hobbsee: can you please hide the whip? it scares me off
* gnomefreak would like to give a package to Hobbsee to build but i want to talk to dh first
<Hobbsee> no, cute is *not* the correct answer to that
<Hobbsee> pitti: but...but...it's my whip....
* Hobbsee had to use her verbal whip on a girl at work today :(
<ajmitch> interesting evening in -devel 
<Hobbsee> ajmitch: very.  i'm in it, what do you expect
<pitti> yeah, I like these totally off-topic nonsense conversations :)
<Hobbsee> ajmitch: besides, if i do any more uploads, edgy-changes will probably break.
<ajmitch> yes, things tended to go downhill fast
<infinity> pitti: Was that a hint? :)
<TheMuso> Hobbsee: Need a cane?
<Hobbsee> TheMuso: i do have a walking stick at work.  it tends to work better.
<pitti> infinity: rather an expression of my utter enjoyment :)
<pitti> infinity: I like to watch Al Bundy, too :)
<thom> hrm, launchpad ought to have retrospective karma
<TheMuso> Yeah. It probably doesn't fall apppart with the slightest tap. :)
<infinity> Hobbsee: Now that you've been added to the op list, you're never allowed to be offtopic, ever again.  Much like the zero-tolerance policy for poolice and drugs, and such.
<Hobbsee> infinity: what????
<infinity> thom: Karma times out.
<Hobbsee> you mean i cant be hobbsee any more?
<thom> infinity: really? ah
<Hobbsee> infinity: but have to be the sane, prim and proper sarah hobbs?
<ajmitch> Hobbsee: yes
<infinity> thom: Yeah, recent contributions count for more than crusty old ones, and eventually, the crusty stuff pops off completely.
<TheMuso> Hobbsee: Don't let us males boss you around. :)
<Hobbsee> ajmitch: you know better than most that that's not possible.
<Hobbsee> TheMuso: haha, never.  i can get you guys wrapped around my little finger, no problem :P
<Hobbsee> infinity: but i was enjoying my 200K of karma :P
<Riddell> what's the daemon that looks after cpu frequency called?
<infinity> Riddell: powernowd
<Riddell> hmm, I don't seem to have powernowd running
<Riddell> "* CPU frequency scaling not supported"  that'll explain it
<ajmitch> TheMuso: see how quickly she took over a team & got on the channel list tonight
<Hobbsee> ah ha, we have an icon now :)
<Hobbsee> but i dont get an icon on my LP page :(
<infinity> Hobbsee: Refresh.  I see it on your page.
<ajmitch> Hobbsee: a gold star?
<ajmitch> how special
<Hobbsee> yeah
* Fujitsu hugs his 274000 karma.
<pitti> Hobbsee: yo do
<pitti> Hobbsee: you, even
* infinity suspects a mushroom for main will have to do, then.
<Hobbsee> pitti: ah, right.  okay then 
<infinity> Hope I don't run into copyright issues with Nintendo.
<Fujitsu> Haa.
<Hobbsee> hah
<Hobbsee> actually, i saw a pretty fish that you could use, if you wanted.
<pitti> infinity: a chauffeur cap might be a nice one for a sponsoring team
<infinity> pitti: Bah, I was just drawing the mushroom.
<Fujitsu> True, pitti.
<infinity> pitti: You eat it and it makes you larger (ie: able to upload to main).. It totally makes sense. :)
<infinity> (to me)
<infinity> (late at night)
<Fujitsu> Hahaha.
* Fujitsu wonders if infinity is incredibly tired.
<Hobbsee> infinity: hehe.  right.  i suspect you're very tired
<Fujitsu> I should probably pop off into bed in a moment...
<pitti> infinity: hah, I know! A syringe
<pitti> since you can inject packages to something you usually don't have access to
* Fujitsu laughs.
<sivang> re
<pitti> Hobbsee: since infinity loves the mushroom so much, maybe you consider a syringe for the universe team
<pitti> hi sivang, how are you?
* Fujitsu collapses at the sight of Hobbsee's package upload list.
<Fujitsu> Hi sivang.
<sivang> pitti: fine thanks, and you Martin ?
<sivang> hey Fujitsu 
<pitti> sivang: I'm well
<Hobbsee> Fujitsu: hahaha!
<Hobbsee> Fujitsu: how many are there now?  i havent counted
<Fujitsu>  Neither have I.
<Fujitsu> And you haven't been a MOTU for that long >_<
<Hobbsee> pitti: hehe, yeah.  i'm not into needles much
<Hobbsee> Fujitsu: yeah, dont start me on that :P
* Hobbsee conveniently forgets that.
<Fujitsu> Hobbsee, did you end up looking through my merges other than mol?
<Hobbsee> Fujitsu: nope, didnt know what you'd built, etc
<Fujitsu> Ah.
* Hobbsee wonders what the mail settings are for that team
<infinity> There.  Screw you all: https://launchpad.net/people/ubuntu-main-sponsors
<infinity> :P
<Hobbsee> haha nice, infinity!
<Fujitsu> Nice, infinity!
<pitti> oooh, what a nice mushroom!
<Hobbsee> hi rodarvus 
* Fujitsu hails infinity.
<pitti> thanks, infinity! :)
<Fujitsu> It looks great!
<Hobbsee> pitti: no, you cant eat it :P
* pitti spits out the bite again
<rodarvus> hey Hobbsee
<ajmitch> I seem to be collecting emblems on my launchpad page quite quickly
<Hobbsee> good pitti.  and see, i didnt even have to use my whip on you
<Hobbsee> ajmitch: it's more fun that way :)
<Fujitsu> Hobbsee, I check-built all of them except mol, as it only builds on PowerPC, and my only PowerPC is at school.
* Hobbsee wants a kubuntu community council group, just so that we can have more pretty icons.  and so that i dont stop forgetting who else is on that team
<Fujitsu> Wow... ajmitch, you have a lot of emblems.
<ajmitch> Fujitsu: yes, I should leave some teams
* TheMuso decides to have a look at a few of these team pages in a GUI browser.
<Riddell> Hobbsee: do it
<TheMuso> Although the emblems will probably be a little small.
<infinity> Fujitsu: I have a few more.  I need to stop making emblems for the teams I join.
<Fujitsu> I've just got the two :P
<Fujitsu> A nice not-two-line list :P
<Hobbsee> Riddell: i can do it?
* TheMuso should install gnome-mag
* Hobbsee would have thought Riddell or someone had to do it.
* Fujitsu notes that infinity on Launchpad isn't actually infinity.
<infinity> Fujitsu: adconrad
<Fujitsu> I knew it was something like aconrad or something.
* Fujitsu steals those icons.
<mdke> freenode isn't using LP for authentication yet?
<mdke> outrageous
<Hobbsee> infinity: are you planning to do your universe merges?  presumably not
<infinity> mdke: Please don't suggest that when sabdfl is in here.
<ajmitch> mdke: would you trust your launchpad password going across irc?
* pitti wouldn't
<mdke> ajmitch: was a joke
* Fujitsu attaches Ethereal to mdke's connection.
<infinity> Hobbsee: I already checked them, and they were all just minor build failure fixes.  I gave the go-ahead to bddebian to do them, but you're welcome to.
<ajmitch> mdke: I know, but there's always a risk that some people take it seriously
<Hobbsee> infinity: right.  i've just been stealing merges at random, i think
* Fujitsu hides. That's what I've been doing.
<mdke> ajmitch: guess so. The serious thing underneath was that it is nice when people have the same irc nick and LP nick... it's easier to find em
<infinity> Hobbsee: The only remotely complex one was dmraid.  If no-one's touched that yet, and it scares you, ping me and I'll do it.
<Hobbsee> ah yes.  
* gnomefreak dives in head first saying "whats the worst that can happen" :(
<Hobbsee> gnomefreak: :) good man
* Fujitsu points out to gnomefreak that dmraid is made up of landmines.
* Fujitsu blocks his ears.
* Hobbsee makes a mental note to actually write the UVF exception report.  wonder who approves them.
<infinity> Hobbsee: mdz, generally.
<tseng> Hobbsee: mdz, Kamion 
<pitti> Hobbsee: me
<gnomefreak> man pages adn docs are generated for you when building a package right?
<pitti> Hobbsee: oops, sorry; mdz
<infinity> pitti: You do UVF exceptions now, or did you read that as MIR?
* Hobbsee wishes pitti did the UVF exceptions :P
* pitti gets another tea to not mix MIR and UVF
<tseng> infinity: UnhandledException
* pitti blushes and goes back to his vi, pondering g-v-m code
<Hobbsee> pitti: haha.  
<desrt> pitti; it's dbus's fault.
* Hobbsee hands pitti a pan galactic gargle blaster.
<tseng> desrt: seriously. I have the same bug in last-exit now and we dont even use gnomevfs (directly)
<pitti> whoa, these always make my brain explode
<pitti> hi Keybuk 
<desrt> Hobbsee; bad call.
<tseng> desrt: arse.
* Fujitsu bashes out Hobbsee's brain with a slice of lemon wrapped around a large gold brick.
<Keybuk> pitti: hey
<Hobbsee> hi Keybuk 
<Hobbsee> hehe
<Fujitsu> Evening Keybuk.
<desrt> Hobbsee; give him one of those and he won't recover until well after edgy
<Hobbsee> desrt: haha.  that could be fun
<desrt> fun for you.  bad for edgy.  :p
<Hobbsee> desrt: well, seeing as i run edgy...
* Fujitsu stops Hobbsee's edgy.
<desrt> people would be like "hey!  cool new package that gives you a root shell when you telnet to the box without the need for pesky passwords!  it's secure because it runs on a high port number!"
<desrt> and without pitti around, this sort of thing would be on the install CD
<Hobbsee> Fujitsu: it already does.  it's hardlocked twice in two days.
<Fujitsu> :O
* Fujitsu finds the key to hardlocked edgy.
<mdke> btw, what package is it a bug in if when I login via ssh I get the "no warranty" message and uname -a repeated twice?
<desrt> mdke; look at your /etc/motd.  is the message there twice?
<mdke> desrt: no
<desrt> weird.
<desrt> does a hush file in your ~ get rid of one or both?
<mdke> desrt: what do I need to do to test that?
<desrt> touch .hushlogin
<desrt> then login
<desrt> supresses motd, etc. on login
<mdke> and should I make that file?
<desrt> ya.  touch will make it for you.
<mdke> ah
<desrt> in ~
<dholbach> gnomefreak: pong
<mdke> desrt: now I get 0
<desrt> mdke; so the bug is in a hushlogin-respecting program
<mdke> btw the "last login" details appear only once, after the first instance of /etc/motd
<gnomefreak> i was able to compile gimmie ok. im gonna attempt to build it (to learn) but i remember you wanted to add that in edgy
<mdke> then comes the second instance of it
<desrt> grepping for hushlogin i get dropbear and sshd
<tseng> gnomefreak: it doesnt have a make install
<mdke> desrt: so, ssh-server i guess has the bug?
<gnomefreak> tseng: i used checkinstall and it worked so im assuming make install should have
<desrt> mdke; well... i know pam is also supposed to handle motd printing
<desrt> mdke; so my bet is that sshd and pam are both doing it
<dholbach> gnomefreak: what does the package contain afterwards?
<gnomefreak> after compiling it?
<dholbach> gnomefreak: yes, what does the checkinstall package contain?
<desrt> mdke; you could try commenting out the 'pam_motd.so' line in /etc/pam.d/ssh
<dholbach> gnomefreak: just run  dpkg -c  on it
<mdke> desrt: if I disable pam in the sshd config, the message only appears once
<desrt> mdke; i bet that will get you 1 message
<desrt> hah
<desrt> so i'm right.  sshd and pam both think that they ought to be printing the message
<desrt> neither one is wrong, but ubuntu probably ought to decide which one it wants
<tseng> pam is lower in the stack
<desrt> btw
<desrt> my /etc/ssh/sshd_config has
<desrt> PrintMotd no
<desrt> did you maybe change that?
<gnomefreak> looking for the deb :(
<dholbach> gnomefreak: oh, i thought checkinstall would provide your with a deb
<dholbach> gnomefreak: i never used it
<gnomefreak> it does
<gnomefreak> i cant remember where it is
<mdke> desrt: it is commented out, and says "Yes" (default?)
<gnomefreak> /usr/bin im sure
<dholbach> gnomefreak: the point is, as long as http://cvs.gnome.org/viewcvs/gimmie/Makefile.am?view=markup doesn't have anything but the funny message in install: we can't package ir properly
<desrt> mdke; *shrug*
<mdke> ok, I'll file it
<desrt> mdke; if you really didn't modify the file yourself then this is the source of the bug
<desrt> mdke; but my file on edgy is fine
<mdke> ok, dapper here
<desrt> it's fine on dapper for me too
<desrt> did you run prerelease dapper on this box?
<mdke> no
<desrt> hm
<gnomefreak> ok dholbach ill look into it and let you know
<dholbach> gnomefreak: gracias
<desrt> i don't think it's worth filing.  just fix it on your machine.
<mdke> yes, you are probably right
<desrt> i just checked a couple of my machines that have been upgraded.  one from breezy one all the way from hoary.  no prob on anything.
<mdke> fine, I'll leave it, thanks for your help
* infinity tries to decide what https://launchpad.net/people/blatant-and-awkward is all about.
<Fujitsu> I like it!
<pitti> infinity: kind of a negative reward? :)
* desrt chuckles
* Hobbsee watches firefox slowly crash.
<infinity> pitti: Yeah, perhaps mvo commenting on some of the weirder strings he's written into update-manager over the years. :)
<gnomefreak> dholbach: heres the output of dpkg -c file.deb http://paste.ubuntu-nl.org/20066
<gnomefreak> Hobbsee: i got ff to work in kde finaly ;)
<desrt> it's an interesting concept
<Riddell> gnomefreak: apt-get install firefox?
<dholbach> gnomefreak: it means the package is empty
<Hobbsee> gnomefreak: yay!
<gnomefreak> Riddell: no it was the font thing
<dholbach> gnomefreak: which is because of the missing install target
<desrt> imagine a launchpad group for "www.penis-enlargement.com lovers"
* Hobbsee rolls her eyes
<mvo> infinity: I worked hard to become a member for this team
<desrt> and then the admin adds everyone on launchpad to it
<gnomefreak> dholbach: oh ok ty :(
<mvo> infinity: ... very hard!
<desrt> groupspam
<pitti> mvo: what do you have to screw up to become a member? :)
<dholbach> infinity: there's jkakar's and jbailey's team as well :)
<mvo> pitti: the name says it all :P 
* pitti grumbles at notification-daemon
<mvo> dholbach: URL?
<pitti> mvo: n-d makes me bite into my table
<dholbach> urg, do i have to search it again :)
<infinity> dholbach: Hah. :)
<ajmitch> dholbach: https://launchpad.net/people/intergalacticbloodshed-hackers
<sabdfl> elmo: do we ever want to allow mixed-arch uploads? an upload of a source with builds in different arch's
<dholbach> ajmitch: mvo :)
<ajmitch> mvo: ^^ :)
<infinity> sabdfl: We don't want that for Ubuntu, but other hosted projects might.
<sabdfl> infinity: good point. thanks
<infinity> sabdfl: I do it in Debian all the time.  ALL the time.
<mvo> dholbach: haha
<mvo> pitti: notification-daemon?
<infinity> sabdfl: Oh, and we do it with security right now too (source+all+allarches), but that's special-cased.
<pitti> mvo: yes
<mvo> pitti: what are you doing with it?
<pitti> mvo: well, scary things
<mvo> *ick*
<pitti> mvo: Imagine, I display a notification!
<mvo> pitti: DON'T DO THIS
<pitti> argh, I *knew*
<mvo> pitti: seriously, what is it doing wrong ?
<pitti> mvo: it misplaces the notification bubble so that half of it is invisible (below the bottom screen edge) and then it just crashes
<pitti> mvo: with apport installed, I started to notice how often it actually crashes :/
<mvo> :(
<pitti> ok, that's something for post feature freeze
<mvo> pitti: I will try to have a look soonish, I need to update my tree to reflect the current merge anyway
<pitti> mvo: oh, I just whined, don't feel blamed :)
<mvo> pitti: thats all right
<kagou> hi
* dholbach hugs infinity
* dholbach hugs infinity
* dholbach hugs infinity
<Hobbsee> dholbach: three times?
<dholbach> Hobbsee: jealous?
<tseng> 3.times do { Hobbsee.Hug }
<Hobbsee> dholbach: maybe.  i like hugs.  and i'm bugfixing :P
<Hobbsee> heh
* dholbach hugs Hobbsee
<dholbach> :-)
* Hobbsee hugs dholbach in return
<Hobbsee> infinity: are we gettign a mass giveback on the buildds for edgy?  seeing as a whole lot of stuff failed to build while xlibs/xfonts/whatever it was was broken? 
<Hobbsee> i'm particularly interested in diacanvas2
<infinity> Hobbsee: There's one in progress right now.
<Hobbsee> infinity: okay, cool :)  any ETA on when it's done?
<infinity> Hobbsee: They take vaguely a day with the current number of failed builds.
<Hobbsee> infinity: okay, cool :)  thanks
<Chipzz> are there any docs on creating your own usplash boot picture?
<Hobbsee> !usplash
<Hobbsee> Chipzz: yes.  in a channel with ubotu in it
<Chipzz> Hobbsee: no such channel?
<Hobbsee> Chipz[00:38]  <ubotu> usplash is the start-up splash (before GNOME/KDE appears) in Ubuntu. To customize it, see https://wiki.ubuntu.com/USplashCustomizationHowto
<Chipzz> Hobbsee: ah, the nick ubotu :)
<Hobbsee> yes
* Chipzz was just being retarded :P
<Chipzz> Hobbsee: I thought #ubotu :P
<Hobbsee> Chipzz: heh.  siilly :P
* iwj curses the firefox build system.
<Hobbsee> iwj: what's it doing now?
<Hobbsee> iwj: apart from being horrid, like not actually finishing building if you try with a qt engine, not gtk
<iwj> The configure script is on crack.
<thom> iwj: yes. but which bit in particular this time?
<iwj> It's too complicated to explain :-).
<iwj> The upshot is that if you build with pango and ft2 it doesn't link.
<iwj> Presumably it works if you turn on xft but we don't.
<thom> ew
<Hobbsee> ah great
<infinity> iwj: I vaguely recall hacking around that in thunderbird.
<infinity> iwj: Check the hideous patches in the thunderbird source, and see if one is helpful.
<ogra> seb128, ping
<seb128> ogra: pong
<ogra> seb128, i'm nearly done with ltsp local device support, my scripts link a new device to the users desktop which works just fine, i also add the link to .gtk-bookmarks, now i'd like to use device specific icons, where can i add the info for nautilus ? 
<ogra> just create a file:XXX entry in .nautilus/metafiles ? 
<ogra> (the script knows if it a camera, cdrom or harddisk/usbstick)
<ogra> *its
<seb128> what is that script supposed to do?
<seb128> modifying .gtk-bookmarks and nautilus private data looks like hackish and wrong
<ogra> well, thats the way it works ... in ltsp ... 
<ogra> upstream as well as for us atm
<seb128> doesn't mean it's right ;)
<seb128> what are you trying to get listed?
<ogra> i got it listed already, i just want to know how to make it not use the folder icon :)
<seb128> what got listed already
<ogra> ltspfs mounts the device from the thin client in /tmp/.$UID-ltspfs/<device>
<seb128> I'm trying to suggest a better solution to what you are doing
<ogra> my script links that to the desktop
<seb128> but I need to know what you try to get done for that
<ogra> and adds that link dynamically to .gtk-bookmarks
<seb128> that looks wrong to me
<ogra> that gives me an icon on the desktop and in the bookmarks list
<seb128> those should be listed as drives
<ogra> they cant
<seb128> like we do for other mounts, devices, etc
<seb128> why ?
<ogra> because its a fuse mount
<ogra> as the name says, filesystem in userspace
<seb128> can't you just use a .desktop?
<ogra> i cant do anything that needs root rights
<ogra> does openoffice know about that ? 
<seb128> listing devices doesn't require root rights
<ogra> and doe it get added to .gtk-bookmarks ? 
<ogra> *does
<seb128> no, it gets added to the devices list
<seb128> like if you mount an another partition
<seb128> try mounting a windows partitions
<ogra> well, thats the same from a user POV :)
<ogra> hmm, i didnt know thats possible through just a .desktop file
<seb128> ogra: right click, on the desktop, pick "create launcher"
<ogra> so back to my question, will openoffice know to handle it ? thats the most important part for ltsp ... at least for edubuntu
<seb128> hum, no, not a .desktop then
<seb128> but to me it looks like they should be handled like a standard mount
<seb128> if you mount a partition to /media/windows it get listed to the places
<ogra> hmm, and if i want to create a device .desktop i cant use a path as arguent :)
<seb128> why shouldn't be the case for those too?
<seb128> ogra: you can
<seb128> Type=Link
<ogra> because i have no access to /media
<seb128> URL=/path
<ogra> ah, cool
<ogra> ok
<seb128> ogra: /media, or /whatever, same thing
<seb128> a mount is a mount
<seb128> the mountpoint doesn't really matter
<ogra> it is no mount :) 
<ogra> its a bit complicated to explain :)
<ogra> there is a permanent mounted fuse mount ...
<ogra> devices i plug in on the client get mounted *below* that
<seb128> how is that different of a windows partition mounted from fstab at boot?
<seb128> ah
<ogra> in the session there is a script that monitors that dir on the server
<ogra> if a new device shows up it shuld do xyz
<ogra> so the user logged in on the client gets access to the device
<ogra> currently i just link the new device t the desktop ...
<ogra> i'll try the .desktop variant 
<ogra> thans for now
<seb128> np
<ogra> :)
<iwj> infinity: I see what you mean about hacky.  Thanks.
<infinity> iwj: Yeah, it wasn't elegant, I was rushed and never cared to look for a saner way.
<iwj> infinity: Well, I'm starting to lose patience with it, so I'll copy your `fix' anyway :-).  It has an least reasonable chance of working.
<ogra> iwj, i found an easy way to make flash sound work for my ltsp users
<infinity> ogra: Install Windows and IE?
<ogra> apparently it always worked, but flash itself has a hardcoded test if /tmp/.esd/socket exists even though it doesnt use it at all :)
<ogra> if it doesnt find it, it will just switch off soundoutput internally
<infinity> ogra: Err, I don't have that here, and flash works.
<ogra> (we dont have the /tmp/.esd dir at all in ubuntu, esd creates it as /tmp/.esd-$UID)
<infinity> ogra: Or does it also check for /tmp/.esd-${UID}/socket ?
<ogra> infinity, you have a ltsp setup ?
<carlos> pitti: btw, just in case if someone asks you
<infinity> ogra: Well, no, I mean locally.  This is only an issue with remote X?
<carlos> pitti: the daily language packs were not being regenerated until yesterday (my fault)
<ogra> its an issue with forwarded esd output :)
<ogra> (you dont have a /tmp/.esd* on ltsp servers usually ... that exists only on the client)
<seb128> carlos: hi. any edgy language pack planned?
<carlos> pitti: and atm, the mirror database we use is not being updated daily (it's blocked by some admin work)
<sbalneav> Kamion: ping
<carlos> seb128: I got an approval for the code changes we had to do
<ogra> sbalneav, he's on vacation this week
<sbalneav> ah
<seb128> carlos: that mean "yes, soon"? :)
<carlos> seb128: I need to plan that with Stuart as soon as my changes land in our development repository (today)
<sbalneav> Just wanted to chat about https://launchpad.net/distros/ubuntu/+source/openssh/+bug/54180
<Ubugtu> Malone bug 54180 in openssh "[rfe]  sshd ought to support 'none' cipher" [Unknown,Confirmed]  
<seb128> carlos: during previous cycle you told me that having language packs early should not be an issue for edgy
<carlos> seb128: my part of the work is already done (once the merge is done) so it's a matter of schedule some tasks from our admins
<ogra> sbalneav, how would that help if you cant use passwords
<carlos> seb128: we try now to migrate what we have in dapper before opening edgy
<seb128> carlos: having still no translations when GNOME is string frozen is really not nice for Ubuntu and make it hard to use for translators and has an impact 
<sbalneav> ogra: see my explanation in #edu
<carlos> and it took more time than planned
<ogra> sbalneav, in a ltsp context ...
<ogra> ok
<carlos> seb128: we could open edgy since the first day
<carlos> but the idea was to include all changes in dapper 
<seb128> carlos: so why does it take 3 months ? :)
<carlos> seb128: because Dapper translations are also included so no one needs to start from zero
<seb128> carlos: right, but things like evolution which changed its translation domain is translated to 0% for months now, that's not really acceptable
<seb128> carlos: who should I speak to to get that sorted for next cycle?
<carlos> seb128: 0% ?
<seb128> carlos: yeah, domain translation changed and we have no language-pack shipping the new .mo name
<seb128> evolution-2.8.mo
<seb128> we ship evolution-2.6.mo
<carlos> seb128: Jordi or I
<carlos> seb128: is it dapper ??
<seb128> no, edgy
<carlos> seb128: jordi, danilo or I
<carlos> seb128: hmmm for edgy, martin
<iwj> ogra: So all you need to do is make /tmp/.esd/socket exist and then it will use the esd lib and connect to the right esd socket ?
<carlos> until we open rosetta to do translations
<seb128> grumpf
<seb128> rosetta should be open for translation when the new cycle start
<carlos> seb128: edgy + 1 will have all code in place to open it at the same time we open soyuz for it
<seb128> not months after
<seb128> you already said that during the dapper cycle :/
<carlos> seb128: my code is called at the same time soyuz is updated with a new distro
<ogra> iwj, exactly
<seb128> carlos: ok, let's see how it works, but current situation really sucks for Ubuntu
<carlos> seb128: the difference is that as soon as we open edgy all .pot and .po files for main (or most of them) will be imported
<ogra> iwj, i thought we could add an if statement that checks if LTSP_CLIENT is set to the top of /usr/bin/firefox anywhere 
<carlos> seb128: I know and I try to do my best with every cycle to improve the situation. The fact that edgy has only 4 months is not helping at all
<ogra> and just mkdir -p and touch the socket file...
<seb128> carlos: k, I was just trying to point that's important that Ubuntu get translated
<ogra> (with some error handling indeed)
<carlos> seb128: don't worry, I'm completely aware of that
<seb128> carlos: so you can bump the "open next distro for translations" early on your TODO or point to whoever should know that's an issue
<carlos> seb128: for edgy + 1 ? or edgy?
<seb128> edgy is too late now
<carlos> for edgy is already on top
<carlos> for edgy + 1
<seb128> edgy has no translation
<carlos> I already told you that the code that copy translations between distros is in place already to be called when soyuz is updated
<seb128> after half of the cycle
<carlos> so edgy + 1 will be open with translations directly
<seb128> yeah, but weeks are flying and we still have no translation
<seb128> GNOME 2.16.0 will soon be here and still no translation
<seb128> and that starts being a real issue for users, so I'm point it again
<seb128> ok, cool
<seb128> s/point/pointing
<ogra> iwj, http://wiki.ltsp.org/twiki/bin/view/Ltsp/Sound#Macromedia_Flash
<ogra> seems edubuntu users following that had success ... (the libesd part isnt needed)
<iwj> ogra: Why not just create this socket in your ltsp server package ?  Just `if doesn't exist, create it', during boot.
<ogra> i have no ltsp specific intscrits on the server yet
<ogra> *initscripts
<iwj> You definitely can't do it in /usr/bin/firefox because it has to be done as root.
<ogra> ah, damned, missed that part ... indeed
<ogra> ok, i'll think about alternatives :)
<ogra> thanks for the pointer
<mcdonaldsguy> I'm trying to track down what I think is a bug with the dapper installer, but I'm totally unfamiliar with the debian-installer code... at what point does /target/etc/apt/apt.conf get created?
<mcdonaldsguy> sorry if this isn't the appropriate place to ask...
<mdz> mcdonaldsguy: apt-setup, I believe
<ogra> seb128, hmm, Type=FSDevice together with URL for the target dir seems to work ... (looks a bit weird though)
<seb128> ogra: cool ;)
<ogra> but i dont get it as a device in the device list (indeed because it isnt a device) can i trick gnome anyhow to see it as device ?
<seb128> ogra: I don't know offhand but I'll have a look to that later
<ogra> thanks ! :)
<infinity> mcdonaldsguy: There should be laws against nicks that make me crave quarter-pounders at 2am, when I can't do anything about it.
<LaserJock> :-)
<HrdwrBoB> infinity: no 24h mcdonalds?
<thom> infinity: there should laws against craving mcdonalds
<HrdwrBoB> actually if it's 2am, you're in au eastern states
<HrdwrBoB> in which case there is 24hr mcdonalds
<infinity> HrdwrBoB: Lots of 24hr McDonald's, none in my neighborhood, and no 24h trains.
<rottingmcdonalds> better?
<infinity> HrdwrBoB: If you've got a car, you're welcome to show your core-dev appreciation, by grabbing me some.
<infinity> HrdwrBoB: (I'm in Armadale... See you in a few)
<HrdwrBoB> heh
<HrdwrBoB> you explain it to my wife
<mdz> pitti: is something supposed to happen when I click on the crash notification icon?
<infinity> Happily.
<mdz> HrdwrBoB: pick up a gift for her on the way home
<infinity> Perhaps a nice apple pie.
<HrdwrBoB> melbourne actually has lots (relatively) of 24h florists
<HrdwrBoB> I imagine for men who are coming home late
<mvo> mdz: does anything happens when you run "apport-gtk" ?
<mdz> pitti: also, why is it that the process will be in uninterruptible sleep when the helper is called by the kernel? can't we arrange for it to be simply stopped?
<infinity> Would go well with all the out-til-six drinking that goes on here, yes.
<mdz> mvo: command not found
<mdz> don't have it installed
<mvo> mdz: oh, sorry. make that /usr/share/apport/apport-gtk 
<mdz> mvo: I don't have the apport-gtk package installed
<mdz> apport doesn't depend on it
<mvo> ok, I guess the icon should only show if apport-gtk is actually installed :)
<mdz> mvo: agreed
<mdz> I'll file a bug
<mvo> mdz: thanks
<mdz> mvo: bug 55971
<mdz> bug 55791 that is
<Ubugtu> Malone bug 55791 in apport "Can display non-functional notification icon" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55791
<mdz> mvo: another strange thing, when I hover over the reboot notification icon, it says "crashreport detected"
<mdz> right now I have both icons, and both say "Crashreport detected".  clicking one displays the reboot dialog, clicking the other does nothing
<mdz> and they look much too alike :-)
<mdz> seb128_: gnome-panel-screenshot just crashed on me, and bug-buddy doesn't seem able to get a backtrace
<mvo> mdz: do you have the latest u-n? I uploaded a new version that has different icons and fixes the tooltip problem
<mdz> /usr/bin/bug-buddy --appname=gnome-panel-screenshot --pid=1 --package-ver=(null)
<mdz> that doesn't look right...--pid=1?
<seb128_> nop, it doesn't
<mdz> mvo: perhaps I do but haven't logged out
<seb128_> and (null) doesn't look like right neither ;)
<mvo> mdz: right, that does explain it
<mdz> bug-buddy also says the app is unknown, dunno if that's normal for g-p-s
<seb128_> that means that the .desktop is broken
<seb128_> new bug-buddy rely on the .desktop infos being correct
<seb128_> having a look
<seb128_> gnome-panel-screenshot doesn't crash on my box ... is that reproducible on your box?
<mdz> mvo: ok, restarted update-notifier and the icon is correct now
<mdz> my reboot icon disappeared though
<seb128_> what version of gnome-utils do you have?
<mdz> Version: 2.15.91-0ubuntu1
<seb128_> could you try with .92? :)
<mdz> yep, upgrading
<Burgwork> mdz, do you have a time for Knot 2? IE:, should I push myself to finish Knot2 on the wiki tonight/next day?
<mdz> Burgwork: I believe Kamion is rolling knot 2, and he is on holiday until next week
<mvo> mdz: I will look into if/why the reboot icon might have disappeared
<Burgwork> mdz, ok, thanks for the info
<bluefoxicy> wow.  In Evolution there's an s-expression library with a 'struct _glib_sux_donkeys { ... }' in it
<sabdfl> bluefoxicy: truth is not always an absolute defence, it seems
<bluefoxicy> sabdfl:  it's just immature.
<pitti> mdz: crash icon> update-notifier needs a small update, already settled with mvo
<pitti> mdz: kernel sleep> tricky, I discussed this with BenC for a while; I think the new approach is more robust
<mdz> pitti: looks like update-notifier is already fixed, I only needed to restart it
<mdz> pitti: I'd be interested to read the discussion if you have a copy around
<pitti> mdz: oh, it was in German :/
<pitti> mdz: short story is, instead of checking /var/crash/* on its own, it needs to call /usr/share/apport/apport-checkreports
<mdz> pitti: BenC speaks german?
<pitti> mdz: oh, I thought the one with mvo, sorry ;)
<BenC> lol
<pitti> BenC: from my experiments it seemed to be impossible to do anything with the crashed process while the kernel was active on it; is there another option?
<BenC> pitti: what else do you need to do?
<pitti> BenC: well, I am fine with the 'dump core, let it die, and examine the core' approach; I'm refering to mdz's question why the crashed process cannot be stopped instead of being in kernel sleep
<mvo> pitti: is the script ready? 
<pitti> mvo: yes, since yesterday
<mdz> BenC: he wants to ptrace it
<BenC> the process has to be stopped in order for the kernel to process the core dump without the process dieing
<mdz> stopped is fine; stopped processes can be ptraced
<dmg> mdz: you could always learn german: http://fsi-language-courses.com/GermanBasic.aspx
<pitti> mdz: besides, you currently cannot gdb a stopped process either
<pitti> mdz: but this is a gdb limitation AFAIUI
<mvo> pitti: perfect, I will add it then
* pitti hugs mvo
<BenC> mdz: How do you ptrace something that is just going to be reaped?
<BenC> it's not going to do anything else other than die and gets its memory reclaimed
<mdz> BenC: but before it does, we'd want to examine its memory
<mdz> and registers
<pitti> mdz: but we can get all of that from the core dump
<BenC> mdz: which the core dump can provides, right?
<dmg> as long as the core dump isn't being put on a read-only file system or somewhere that might run out of space.
<BenC> dmg: it's being done the same way it would be done if you set ulimit=100M
<mdz> pitti,BenC: sure, we can get the same info either way.  the core dump seems like an extra step
<BenC> so if it would normally be allowed to core dump, then it would be the case here as well, and if not, then apport will just deal with what little info it can get (process name, signal, etc)
<mdz> and core dumps have historically not always worked correctly, e.g. in threaded programs
<mdz> is that fixed now?
<mdz> it also seems that this would require that we enable core dumps by default in order to get any useful information
<BenC> mdz: Current setup is going to be like this:
<mdz> and if they're enabled by default, and apport isn't there to clean up, they'll create cruft
<BenC> /proc/sys/kernel/crash-helper will contain the name of a program
<BenC> the kernel checks if that helper exists and is excutable
<BenC> if it is, it creates the dump regardless
<BenC> calls the helper
<BenC> if the core dump was created just for the helper (e.g. ulimits has core=0), then it removes the core
<BenC> pitti: One thing I haven't thought about is serialization of the helper program
<pitti> BenC: serialization?
<BenC> pitti: would you prefer that the kernel just call it whenever, or should it only allow one helper to be active at a time?
<pitti> (btw, I have to leave in two minutes for Taekwondo, sorry)
<BenC> I can create a lock so that it wont call another helper until the previous one is done
<pitti> BenC: apart from the multiple I/O load it will create, I don't see a problem with having several parallel instances
<BenC> ok
<BenC> just worried about a flooding caused by some gnome program failing repeatedly
<pitti> it currently does not do anything that would need mutual exclusion
<pitti> BenC: well, apport only creates one report per program and user
<pitti> BenC: if there already is an unread report, it immediately exists
<pitti> s/exists/exits/
<BenC> gotcha
<pitti> mdz: that's why I wanted to avoid setting the standard ulimit (avoid disk usage DoS)
<mdz> pitti: ah, ok.  it sounds like you've addressed that issue already
<pitti> mdz: OTOH apport shouldn't unconditionally remove core dumps, the admin will usually want them if he enabled ulimits manually
<mdz> pitti: it should move them into /var/crash and expire them, or similar
<pitti> ok, if there are any further issues, please mail me; sorry, I have to leave now
<pitti> mdz: that's roughly what happens now
<pitti> mdz: they are bzip2'ed and integrated into the crash report with the other data
<pitti> mdz: and a cronjob cleans up old ones
<mdz> pitti: good night
<pitti> mdz: bzip2 makes a *huge* difference (160 MB firefox dump uncompressed -> 5 MB bzip2)
<mdz> pitti: yes, I expected it would
<sladen> pitti: how does gzip compare?
<pitti> sladen: didn't try
<mdz> probably almost as good
<pitti> yes, the dump is full of zeros
<mdz> probably full pages of zeros; I wonder why they're not done sparsely
<pitti> ok, cu!
<mdz> BenC: sparse core dumps?
<sladen> pitti: in that case (uninitalised RAM) then, gzip might be preferable, it's stream-based and the processing overhead at the server end will be about 1% of the bzip2 one
<mdz> sladen: you mean initialised RAM
<mdz> I'm not too concerned about the overhead on the server side; they'll be batch processed
<mdz> and if it saves the user even a small amount on the upload, that can be valuable
<mdz> smaller upload -> less time spent reporting the problem -> more problem reports
<dmg> the problem with sending core dumps is that they might contain sensitive information and there's no way to reliably scrub them.
<mdz> dmg: hence we need to ask the user's permission
<Nafallo> mjg59: ping
<sladen> Nafallo: just ask
<Nafallo> oki :-)
<Nafallo> did anyone see the latest reply on bug #32963 ? maybe this is worth a new upstream version?
<Ubugtu> Malone bug 32963 in xserver-xorg-driver-i810 "Xv movies on 810/i945 gives horrible color, Gamma" [Unknown,Needs info]  http://launchpad.net/bugs/32963
<Nafallo> if someone make the package I'm happy to test it here :-)
<Nafallo> (on edgy i386)
<Nafallo> sladen: ah, you are the assigne :-)
<bddebian> Heya
<rodarvus> Nafallo, our edgy package of i810 is basically the latest version available
<bit_doidao> hello! how to compile php5 with imap support? its possible to have it by default in php5-ubuntu.deb?
<rodarvus> (only two small changes from the latest available version from edgy i810 package)
<Nafallo> rodarvus: 1.6.1 in edgy, 1.6.3 is latest upstream, and the one that hopefully fixes the bug :-).
<rodarvus> Nafallo, read what I just said :)
<rodarvus> there are only two small changes from 1.6.1 to 1.6.3
<Nafallo> yea, saw it afterwards :-).
<sladen> Nafallo: I think after I bitched at the Intel people in paris they got the people in China to go and send something upstream---not that they bothered sending a copy back to me
<mjg59> Nafallo: Hi
<cr3> how can I determine which driver corresponds to a file under /dev, like /dev/ptmx for example
<mjg59> Nafallo: Ah, already dealt with
<Nafallo> mjg59: hello. oh? there is a new package to test somewhere? :-)
<sladen> cr3: that's the pseudo terminal multiplexer...
<Nafallo> sladen: how... kind of them not to :-P.
<sladen> cr3: you probably want ---> #ubuntu
<mjg59> Nafallo: Oh, no
<mjg59> Nafallo: I'm not anything to do with X at the moment
<mjg59> I'll see if I can reproduce somewhere
* mjg59 goes out
<Nafallo> mjg59: hehe, might be a vice decision ;-)
<Nafallo> oki
* Nafallo builds 1.6.3 and sees if he can still reproduce the bug...
<rodarvus> oh
<rodarvus> Nafallo, I just found out one of the two "small changes" I mentioned is actually the merge of the 'mergedfb' tree of i810
<rodarvus> so, not really a small change
<Nafallo> :-)
<rodarvus> Nafallo, I'd be thankful if you could test it, then :)
<Nafallo> hmm, when I get the build-deps correct ;-)
<rodarvus> I can build it quickly locally, if needed be
<Nafallo> any idea where xineramaproto might reside? :-)
<rodarvus> x11proto-xinerama-dev
<Nafallo> yea. we can see who can make it build first! :-)
<Nafallo> thanks :-)
<rodarvus> Nafallo, actually I'm ok with you build-testing it
<Nafallo> okidoki
* rodarvus is building other packages here :)
<rodarvus> btw, is anyone up to testing xorg-server on i386 or amd64?
<Nafallo> sure, why not. after I test this one :-)
<rodarvus> I got an updated package (with ~ 16 new patches on it)
<dholbach> sladen: cr3 works for Canonical - and that question is not really a "#ubuntu support" question - I doubt they'd know over there.
<rodarvus> (disclaimer: works fine on two different machines, here)
<cr3> dholbach: that's alright, I'll figure it out :)
<dholbach> cr3: I'd tell you, if I knew :-)
<cr3> dholbach: I'm getting the source and I suspect I could grep for the major and minor numbers of the driver. I'll see once the darn thing finishees downloading :)
<cr3> err, numbers of the device in the drivers sources
<bbrazil> cr3: /proc/devices
<cr3> bbrazil: thanks, that's a nice overview. I was using ls -l which provides that information as well
<bbrazil> cr3: it does?
<cr3> bbrazil: sure, major and minor device numbers
<bbrazil> cr3: ah, I though you were looking for the drivers
<Nafallo> rodarvus: that worked better, makes it throu configure okey now ;-)
<Nafallo> finished building, brb. restart X :-)
<treitter> debhelper isn't very useful of you don't have an autotooled package, right?
<LaserJock> debhelper is useful for just about any situation, I'd think
<bit_doidao> hello! i want to recompile php5 with only i additional stuff. how to het the original compile parameters for adding this one --with?
<LaserJock> bit_doidao: apt-get source and look in <source>/debian/rules
<LaserJock> bit_doidao: and #ubuntu-motu might be a better place for that :-)
<Nafallo> rodarvus, sladen: I still have the bug :-/
<rodarvus> thats sad
<rodarvus> Nafallo, do you want to upgrade xorg-server to check if it solves your bug?
<Nafallo> rodarvus: sure :-)
<rodarvus> I don't think it will, but you'll be helping me test the new xorg-server :P
<bbrazil> bit_doidao: phpinfo()
<Nafallo> :-)
<Riddell> Kamion: what's the state of the point releases?
<rodarvus> Nafallo, http://people.ubuntu.com/~rodarvus/packages/xorg-server/
<rodarvus> it has packages for i386 and amd64
<sladen> Nafallo: were you the person that tried the latest upsteam from xorg?
<Nafallo> sladen: yea, I built a package for i810 and rebooted :-)
<Burgwork> Riddell, kamion is on vacation this week
* Burgwork wonders why he is telling a canonical employee about another canonical employees holidays
* tseng wonders why Burgwork is baffled at bad communication in an open source project
<bddebian> heh
<dholbach> Burgwork, tseng: I'm sure Riddell is perfectly aware of that - Kamion was around today and yesterday to help with the releases and we are all happy he helped out with them.
<Burgwork> dholbach, very likely, but it was an odd question
<Nafallo> rodarvus: that works, will test video after I made my dinner ready :-9
<rodarvus> Nafallo, thanks
* Riddell didn't get an answer though
<rodarvus> are you running i386 or amd64?
<Nafallo> i386. my rabbit ate the powercord for my amd64-laptop :-/
<Nafallo> so can't test that :-P
<bddebian> It's an evil beast with big pointy teeth...
<LaserJock> Nafallo: yikes, is the rabbit ok :-)
<Nafallo> hehe
<Nafallo> yepp
<Nafallo> http://www.nafallo.info/blog/ ;-)
<Nafallo> bddebian: big and big... http://www.nafallo.info/~nafallo/pics/animals/storm.jpg
<bddebian> "Run away, run away..."
<Nafallo> ...and the bug still isn't solved.
<mdz> Riddell: the point release is on its way to the mirrors, according to Kamion's message some hours ago
<mdz> Riddell: will be announced late tonight or early tomorrow, UTC
<Riddell> mdz: do you know if that includes kubuntu?  I don't see it on releases.ubuntu.com
<mdz> Riddell: no, I don't
<elmo> it does, it's still syncing
<Riddell> elmo: cool, thanks
<seb128> siretart: around?
<seb128> siretart: why did you reassign bug #48138 to totem-xine?
<Ubugtu> Malone bug 48138 in totem "totem-xine crashes when started with no argument" [Unknown,Fix released]  http://launchpad.net/bugs/48138
<seb128> siretart: the commit pointed is a libxine one
<crimsun> seb128: he may have just read the "bugzilla.gnome.org" URL and not seen the actual xine-lib portion
<seb128> crimsun: yeah, probably, that's why I ping him ;)
<crimsun> (source package corrected.)
<seb128> crimsun: ok, thank you ;)
<elmo> (releases.u.c is now up-to-date and cdimage.u.c is syncing at a sane speed again and will be up-to-date in 5-10 mins)
<dilinger> i'm seeing some issues w/ the dapper installer (apt-setup) and apt
<dilinger> dapper's apt-setup seems to create /etc/apt/apt.conf w/ Acquire::http::proxy set to "false"
<dilinger> in one case (i'm not sure how a coworker managed to get it that way), apt.conf contained 'Acquire::::proxy "false";'
<dilinger> somehow, $protocol never made it there
<dilinger> in the rest of the cases, apt.conf is ending up w/ 'Acquire::http::proxy "false";', which does not work with out apt proxy (approx, apt-cacher)
<dilinger> what i end up getting is this when i apt-get update:
<dilinger> Failed to fetch http://zanzibar.ne.in.athenacr.com:9999/ubuntu/dists/dapper/main/binary-i386/Packages.gz  403 Forbidden
<dilinger> however, i can wget that file; and if i comment out that Acquire::http::proxy line or set it to "" (instead of "false"), it works
<dilinger> is this somehow related to gpg checking, or a genuine apt bug?
<dilinger> ok, well: https://launchpad.net/distros/ubuntu/+source/apt/+bug/55813
<Ubugtu> Malone bug 55813 in apt "Acquire::http::proxy breaks things with apt proxies like apt-cacher" [Untriaged,Unconfirmed]  
<dilinger> heh, what timing
<pitti> Hello again
<dmg> pitti: have a good time beating people up?
<dmg> or throwing them, I suppose.
<pitti> mdz: re apport, having the kernel create a core dump is not really an extra step; we want the core dump anyway to be able to create good backtraces later; it's just that creating the core from apport itself would allow greater flexibility
<mdz> pitti: ok
<mdz> pitti: I'm eager to experiment with it
<pitti> dmg: hey, I'm peaceful :)
<pitti> mdz: heh, it seems archive.u.c. caught up a little and now has 0.8
<pitti> mdz: I uploaded 0.9 some 6 hours ago, so it can't take long any more until it reaches the archive
<pitti> mdz: with 0.9 I'm reasonably confident of not breaking too much; thus I'd like to add it to ubuntu-desktop for greater testing coverage soon
<pitti> mdz: would you be fine with that?
<mdz> pitti: yes
<dholbach> in fact i didn't see any package updates in the last 6 hours
<pitti> dholbach: hey, it took over a day for 0.8 to appear, so I won't complain yet :/
<pitti> mdz: in 0.9 I also added a library (and some instructions how to use it) which 'fakes' the future kernel behaviour, so that you can get full gdb love
<mdz> dholbach: really?  where is the blockage?
<pitti> dholbach: yesterday it was due to the network link switch
<mdz> pitti: what's the future kernel behaviour?
<pitti> mdz: security.u.c. was moved yesterday, archive.u.c today
<dholbach> mdz: i can't tell, it's just what i noticed
<pitti> mdz: now it just calls apport while keeping the crashed process in limbo; BenC works on the solution we discussed some hours ago, the kernel dumps core and *then* calls apport with the core dump file as argument
<pitti> mdz: and it will introduce another 'temporary' core size ulimit (if the normal ulimit is broken, it'll remove the core dump after apport finished)
<BenC> edgy kernel upload tonight with ABI bump (you've been warned, because basically there's nothing you can do to stop me!!! :)
<mdz> pitti: oh, I see
<pitti> go, BenC, go! :)
<BenC> pitti: cleaning up your apport stuff is my final task before upload
* pitti hugs BenC
<pitti> BenC: that might come in time for tomorrow's distro team meeting :)
<BenC> I wont lie, I finished it up so my task list appeared as if I did something useful this past week :)
<BenC> "it's all about the bullets baby"
<pitti> ^ from which movie does that come?
<BenC> the song, "It's all about the Benjamin's baby"
<BenC> or the weird al version, "It's all about the Pentium's baby"
<pitti> mdz: ok, then I'll wait with the main promotion/ubuntu-desktop addition until the kernel is in place, then we don't need the hideous library any more to get the full fun
<pitti> Good night everyone
<slomo> gn8 pitti 
<dholbach> night guys
<slomo> gn8 dholbach :) and enjoy your vacation
<dholbach> gracias slomo! have a good time too!
#ubuntu-devel 2006-08-10
<nemish> Can someone tell me yes or no but I thought in xorg that radeon driver was deprecated and supposed to use ati driver?
<Burgwork> nemish, not really, but this is not a support channel
<nemish> Burgwork, thanks.. sorry
<Burgwork> nemish, no worries
<TheMuso> c
<BenC> isn't Breaks supposed to obsolete the provides/conflicts/replaces trio?
<Keybuk> BenC: not obsolete, no
<Keybuk> Breaks does replace most uses of Conflicts: <<
<Keybuk> it's for "these don't work together", leaving conflicts for "these contain the same files"
<BenC> so if a package is renamed, then I should still use the old provides/conflicts/replaces setup to replace the old package?
<BenC> this is for linux-kernel-headers being renamed to libc-dev-linux-headers, which only libc6-dev depends on, and it's not a versioned depends
<BenC> means libc-dev-linux-headers wont really be installed until libc6-dev is updated, but at least things wont break
<ghee22> hi
<ghee22> I am trying to make my program l10n compatible or I18n compatible
<Burgwork> ghee22, you need gettext support
<ghee22> anyone have directions on how to get this started?  I am reading through the debian intro on this topic and it's very thourough
<ghee22> hey burg, I am not familiar with gettext
<Burgwork> sorry, nor am I
<ghee22> ok, if anyone is, is the gnu gettext? http://www.gnu.org/software/gettext/
<allee> bug or feature that pmount version in dapper-updates is higher than in edgy?
<BenC> Kamion: nic-firmware will be in the 2.6.17-6 kernel uploading tonight
<gnomefreak> BenC: Kamio^n is onvacation this week 
<Burgwork> gnomefreak, people on vacation at canonical have an alarming habit of still being on irc
<gnomefreak> that doesnt sound like a vacation :(
<imbrandon> that and they read irc logs too ;)
<Burgwork> imbrandon, are you telling my people who develop ubuntu can read? I am shocked ;)
<imbrandon> hahah 
<imbrandon> they read / dream in c++^W<fav prog lang here>
<Burgwork> imbrandon, this is ubuntu. They dream in python
<imbrandon> ahh right 
<ohoel> was xorg 7.1 in knot1?
<crimsun> no
<crimsun> (well, it depends how much of 7.1 you're referring to. It had bits and pieces already.)
<ohoel> thanks crimsun
<wasabi> Heh. X in edgy is actually fine! It's fglrx that's messed. =(
<lmanul> Hi desrt :)
<lmanul> desrt: Somehow "Manu the brown" doesn't sound as shiny as "Gandalf the white", I don't know why ;-)
<desrt> white is shiner than brown.
<lmanul> Oh, that must be it.
<lmanul> :)
<jdub> ha ha ha
<jdub> manu the brown
<lmanul> Hi jdub :)
<pitti> Good morning
<jdub> hey hey pitti 
* Starting logfile irclogs/ubuntu-devel.log
(sivang/#ubuntu-devel) morning
<pitti> jdub: hey Jeff, how are your pants today?
* pitti hugs desrt
* desrt smiles and hugs back
* pitti gives sivang a big good morning hug
<thom> pitti: that's a pretty brave question, on balance
<thom> morning
<jdub> pitti: funny you should ask
<pitti> thom: I feel lucky today :)
<pitti> thom: good morning, too!
<jdub> pitti: i had a string of pants-wearing days
<jdub> pitti: and today i found that all my pants needed to go in the wash
<pitti> jdub: not too surprising in your winter
<jdub> so i am hanging loose today
<jdub> pitti: yeah, it is pretty cold here atm
<jdub> at least at night
* sivang hugs pitti back :-)
<jdub> that's the worst bit; it's reasonable during the day, but cold enough to feel very different at night
<pitti> desrt: you cannot write a program that proofs that these bugs don't exist ;)
<pitti> desrt: (very similar to the halting problem)
<desrt> pitti; you're wrong.
<pitti> desrt: however, there are some programs that do static code analysis
<desrt> you confuse recognisers with deciders
<pitti> usually they can find something
<pitti> desrt: but I never played with them, sorry :/
<desrt> have any names to drop?
* desrt is working on ideas for a thesis and wants to ensure that he isn't reinventing other people's wheels
<jdub> bad idea: watching the whole billie piper series of doctor who, wondering why you thought her music was so bad, and finding some to listen to.
<thom> jdub: define "pretty cold"
<thom> jdub: hahaha
<desrt> pitti; in any case, you could have a program that outputs either "safe", "unsafe" or "i don't know"
<pitti> desrt: http://www.dwheeler.com/flawfinder/ maybe
<jdub> thom: it's not all that cold really, but the difference between day and night makes it seem worse
<desrt> pitti; and you can improve the chances of getting "safe" or "unsafe" with code annotation
<pitti> desrt: right, finding potential overflows is not that difficult
<pitti> desrt: however, so far I usually used the tools 'grep' and 'eagle eye' :)
<desrt> i was actually sort of thinking more along the lines of the output being one of:
<pitti> desrt: I'm pretty interested in automatic tools, just never found the time
<desrt> - "i can prove that it is safe."
<desrt> - "i can not prove that it is safe."
<pitti> desrt: maybe 'I can prove that it is safe against buffer overflows'
<desrt> since the people i am working for are definitely interested in hard proof
<desrt> they're all about formal methods
<pitti> but that will only be the case in rare circumstances
<pitti> desrt: heh, rewrite the program in prolog :)
<desrt> ok.  maybe i define safe as "will not smash its stack for any user input"
<pitti> then it is straightforward to proof
<pitti> s/proof/prove/
<desrt> i want to do it for C
<pitti> (just kidding)
<desrt> since it's not even vaguely interesting for other "safer" languages
<desrt> and since everyone always uses C anyway
* jdub swaps billie piper for shirley manson
<desrt> pfah.  that's garbage.
<pitti> desrt: well, since security vulnerabilities happen on many different levels, you cannot really proof 'safety'
<Spads> billie piper sings?
<desrt> pitti; oh.  i am only interested in the very small sort of definition of safety that i just stated
<pitti> desrt: but memory checking is of course a confined domain which should have good tool support
<thom> Spads: no. but she produced records
<desrt> memory checking implies runtime......
<desrt> anyway.  lots to think about
<desrt> and 2 years in which to think about it
<pitti> desrt: ok, flawfinder and http://www.hp.com/go/cadvise/ are the two in my bookmark list
<desrt> i guess i'll probably talk to you again some time in those 2 years :)
<desrt> goodnight.
<pitti> desrt: sleep well!
<lucas> pitti, desrt: there's the stanford checker too
<lucas> it has gone commercial now, I think
<crimsun> as coverity iirc
<lucas> ah yes
<bluefoxicy> hmm
<bluefoxicy> I didn't destroy my system
<bluefoxicy> but I'm not quite sure I actually did anything useful either.
<bluefoxicy> https://launchpad.net/distros/ubuntu/+spec/networking-security-sysctls  You be the judge; I'm going to sleep, it's 4am.
<fabbione> net.ipv4.conf.all.accept_redirects = 0
<fabbione> AHHH
* fabbione seeks and destroys who wrote that
* ..[topic/#ubuntu-devel:Kamion] : 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 | yes X in edgy is a mess atm | 6.06.1 released
<ogra> yay
<Kamion> which means I can *finally* start ignoring IRC :P
<StevenK> Heh
<Hobbsee> Kamion: hah.  never
<ogra> how many vacation days did you loose now ? 
<Burgundavia> Kamion: go away, you are on holiday
<pitti> Kamion: \o/
<Kamion> ogra: on aggregate I think about 1-1.5
<infinity> Kamion: Awesome job, dude.  Go away.
<infinity> Kamion: I owe you some slack cover when you get back.  Just let me know what slavery you need performed.
<bluefoxicy> fabbione:  redirects == one computer tells you that packets destined for <host> or <network> should instead be routed through <address>
* Hobbsee waves to infinity 
<fabbione> bluefoxicy: i know exactly what a redirect is
<fabbione> bluefoxicy: turning it to off is BAD
<bluefoxicy> fabbione:  in other words, un-authenticated remote administration of routing tables.  The best "secure" method we have is "look at gateways in our list," which turns into "spoof the default gateway"
<bluefoxicy> fabbione:  how is it bad
<bluefoxicy> my understanding is that this isn't generally used except in very specific environments
<fabbione> bluefoxicy: if you disable it, you can cause a DoS on the network
<fabbione> bluefoxicy: it's always used
<bluefoxicy> how can you cause a DoS
<bluefoxicy> the only nodes I can imagine caring would be ... well... routers
<fabbione> host A wants to talk to host B
<bluefoxicy> and they typically use a routing information protocol
<fabbione> host A default gw C
<fabbione> C is a router on the same subnet as D
<fabbione> B is connected behind D
<bluefoxicy> A -- C -- D -- B ?
<fabbione> when i first attempt from A to talk to B, C tells me that D is behind D
<fabbione> (with a redirect)
<Kamion> infinity: ta. *gone*
<fabbione> A C D are on the same subnet
<fabbione> BD are on another subnet
<bluefoxicy> ah.
<fabbione> C is default gw of A
<fabbione> C knows where B is due routing table
<bluefoxicy> so you're saying
<fabbione> ok?
<bluefoxicy> A's routing table is misconfigured.
<fabbione> no
<bluefoxicy> and you want it to magically fix itself.
<fabbione> A is perfectly configured host with one default gw
<fabbione> A default gw is C
<fabbione> C knows that B is behind D
<fabbione> ACD are on the same subnet
<fabbione> when A tries to talk to B
<fabbione>  C will tell A (with a redirect) that B is behind D
<bluefoxicy> at the expense that E on the same subnet as A C D can tell A (via spoofed ICMP packet from IP address C) that IT is the choice router for 0.0.0.0/0 (default gw) and thus now have a man-in-the-middle position between A and *
<fabbione> becuase it's totally pointless for the traffic to go trough A
<bluefoxicy> also
<bluefoxicy> subnets were created for a reason.
<bluefoxicy> Each subnet should exist in exactly one place; and all routers attached to it should be on its subnet on attached interface.
<fabbione> bluefoxicy: if E has access to the physical network, it can do much worst than that.
<fabbione> your point is void
<fabbione> that setting is bad set to 0
<bluefoxicy> you're describing a condition where (A) has everything going through (C), (B) is on another subnet, and apparently nobody told (A) that that subnet is behind (D)
<bluefoxicy> which is the proper way to set up the routing table
<fabbione> no
<bluefoxicy> the subnet (B) is on should not be inaccessible directly by (D) at any point
<fabbione> you don't understand the picture i am giving to you
<bluefoxicy> if it is your network is wrong.
<fabbione> the perfect configured network
<fabbione> no errors whatsoever
<fabbione> A 192.168.1.100
<fabbione> C 192.168.1.1
<fabbione> D 192.168.1.2
<bluefoxicy> what subnet is behind C?
<fabbione> D has also a 10.0.0.2 interface
<bluefoxicy> routers have at least 2 interfaces (by definition)
<fabbione> C 172.... whatever..
<bluefoxicy> okay
<fabbione> B is 10.0.0.100
<fabbione> ok?
<bluefoxicy> then A should know to send 172.* to c and 10.* to D
<fabbione> right they do
<fabbione> we assume they are talking somekind of IGP
<bluefoxicy> and then traffic will never be routed to the wrong router
<fabbione> A is a host... remember.. one default gw
<fabbione> exactly
<bluefoxicy> yes
<fabbione> A sends a packets to B
<fabbione> the packets hits C
<bluefoxicy> normally you don't really have two routers on the same network segment
<fabbione> wrong
<fabbione> you can have N routers on a network segment
<bluefoxicy> wait, yeah... I did.
<fabbione> C recog that packets from A can travel trough D directly to reach B
<fabbione> C sends a redirect back to A
<fabbione> A sends the packets via D
<bluefoxicy> but the hosts on that segment had their default routes pointing in whatever direction The Internet was in; and routes to other things (the Wifi AP for one; also the Active Directory server) pointing towards the nearest router in that direction
<fabbione> C forgets of that traffic 100%
<fabbione> why can't you let me finish before doing other assumptions?
<fabbione> the default gw does NOT necessarely points to internet
<bluefoxicy> yeah
<bluefoxicy> no, but mine did.  I'm saying, my HOSTS each had 2-3 ROUTES
<fabbione> ok you are not listening
<fabbione> pointless to discuss
<bluefoxicy> each host knew about the routers around it, and the routes into the network; they didn't need the routers to tell them about it
<bluefoxicy> you're saying that each host is only going to have a default route; no other routes are possible
<bluefoxicy> and that routers are going to tell them how to route packets to other routers near them
<fabbione> you are putting words in my mounths i didn't say
<fabbione> a host needs only a default gw
<bluefoxicy> <fabbione> A is a host... remember.. one default gw
<fabbione> the router will tell the host where to find the other stuff via icmp_redirect
<fabbione> it doesn't need
<fabbione> more than one route
<fabbione> if you disable the icmp_redirect you will see default GW DoSed by ubuntu machines
<bluefoxicy> only in network topologies that bank on that set-up
<fabbione> and how uncommon do you think they are?
<bluefoxicy> bah, I'll have to research it more.
<fabbione> you better do
<bluefoxicy> s/C/R1/ s/D/R2
<bluefoxicy> and you just made word for word Microsoft's same explanation of the issue
<fabbione> of course,  you didn't let me finish the explanation without coming up with other stuff
<fabbione> the final issue is simple
* bluefoxicy finds a paper that says ICMP redirects point out "bad network design" and that "well designed network should not rely on or desire ICMP redirects" ... that's the same thing he just said
<bluefoxicy> it's a two way channel, I can talk and listen at the same time
<fabbione> if host A block redirects from R1 to talk to to B via R2
<fabbione> you will endup routing all the traffic from A to B via R1 and R2
<fabbione> when there is no real need to involve R1
<fabbione> now
<bluefoxicy> in fact I can hold multiple lines of conversation with the same person or multiple people at the same time; although when with the same person they consistently have trouble demuxing the conversations from eachother
<fabbione> if you want a practical example
<fabbione> A is your workstation
<fabbione> R1 is your 10Mb asdl router
<bluefoxicy> fabbione:  and if your network is designed well in the first place you won't have that problem
<fabbione> bluefoxicy: wrong.. again..
* StevenK wonders when fabbione will realease the specs for "ASDL"
<quail> Mark Shuttleworth on More4 >>> http://www.channel4.com/more4/news/news-opinion-feature.jsp?id=350
<fabbione> StevenK: well ADSL ;)
<fabbione> R2 is your gigabit server that act also as rotuer to your 100Mb printer
<fabbione> B is the printer
<fabbione> disable ICMP_Redirect and print
<fabbione> and tell me if you can actually get to ping the adsl router
<fabbione> (assuming you print a doc big enough.. like 100MB ps file)
<bluefoxicy> lol this is cute
<bluefoxicy> ping host B
<bluefoxicy> and let it run
<fabbione> repeat the above with icmp_redirect turned on
<fabbione> (accepting icmp_redirect of course)
<bluefoxicy> and it will keep firing pings through router C, and it will keep sending redirects to host A
<fabbione> that too
<bluefoxicy> fabbione:  that's with redirects on
<fabbione> off
<bluefoxicy> no, on.
<bluefoxicy> Ping doesn't re-initialize its route from the routing table until you restart the program
<fabbione> if the redirect is accepted than you won't see all the redirects from C
<fabbione> what kernel are you running? 2.0?
<bluefoxicy> no, i'm reading a paper
<fabbione> the last kernel i saw with such problem was 2.2.0 from RH
<fabbione> oh clearly.. test it
<fabbione> 2.4 or higher don't behave that way
<fabbione> route lookup is performed on a pkt base
<bluefoxicy> my network layouts look more like HOST --- ROUTER -- 2 ROUTERS -- OTHER HOSTS
<bluefoxicy> or a router with 15 ports on it, etc.
<fabbione> that's not the same setup i did describe to you
<bluefoxicy> instead of trying to daisy chain routers through switches or hubs
<bluefoxicy> the setup you descibed to me was "day 2 of CISCO CCNA academy:  Don't Ever Do This, It's Stupid"
<fabbione> ahhaha
<fabbione> yeah right
<fabbione> ok
<bluefoxicy> I wanted to kill justin for his braindead network layout he gave us to implement, it took us 1.5 months to get it half-functional.
<fabbione> whatever
<bluefoxicy> if he used a design where the routing was actually a backbone instead of a distributed mess mixed in with the rest of the network, it would'a been 3 days.
<fabbione> according to your view there can't be more than one router in a subnet with hosts...
<bluefoxicy> we kept runnining into issues like (amazingly) hosts having to have 2-3 routing table entries
<fabbione> i don't care what you did at your CCNA
<bluefoxicy> actually that network was in my implementing and maintaining network intrusion defenses class
<bluefoxicy> and my view isn't that you can't do it
<bluefoxicy> it's that it's rather close to pouring whiskey into your gas tank
<bluefoxicy> it'll work
<bluefoxicy> it's still not the best idea.
<bluefoxicy> aww... this guy doesn't even address any security issues :(
<bluefoxicy> he just talks about how networks reliant on redirects are inefficient and poorly designed.  That's no fun.
<bluefoxicy> it's 5am
<bluefoxicy> I need sleep.
<bluefoxicy> fabbione:  I am pretty certain that any network you give me lain out like that I can do better.
<bluefoxicy> and yeah
<bluefoxicy> if you have routers forwarding to routers on the same interface you're doubling the bandwidth, which halves your capacity and can lead to network storms
* fabbione wonders how he managed to admin AS3263 and AS6762 with over 50GB of traffic than...
<bluefoxicy> but fixing the design will fix that
<fabbione> anyway
<bluefoxicy> sleep0rz
<fabbione> i don't care how you design the net
<fabbione> that kind of networks are in use
<fabbione> by who.. i don't care
<fabbione> it's a real use case
<bluefoxicy> there are a lot of 'real use cases' that are both stupid and fixable for a low but significant cost barrier
<bluefoxicy> unfortunately i'd be lying if I said I didn't think they mattered
<jdub> Kamion: WOOHOO! congrats :-)
<carlos> doko: hi
<carlos> doko: around ?
<doko> carlos: yes
<carlos> doko: http://people.ubuntu.com/~carlos/oo-translations-20060808.tar.gz
<doko> carlos: ohh, nice.
<nags> seb128, hi
<nags> seb128, asked Prashanth Mohan to upload
<nags> seb128, evolution scripts
<seb128> re
<seb128> cool
<nags> seb128, now they are available with a ready me
<nags> seb128, me getting the link
<seb128> nice
<nags> seb128, Evolution automation scripts are now uploaded here - http://people.freedesktop.org/~prashmohan/evolution/
<seb128> nags: thank you for the pointer
<nags> seb128, can I convert that avi to ogg - screencast of Evolution automation and Tinderbox integration ? Many people were unable to view the contents properly. They all reported the screen is blank
<seb128> nags: probably but I'm not sure of how
<nags> seb128, If possible can somebody verify those Evolution scripts and give their feedback, so that we can incorporate them back ? and over a period of time, we can use that in regression ?
<nags> seb128, okay, no problem :)
<seb128> nags: yeah, that would be nice to get them integrated
<nags> seb128, also, I'm working with cr3, I will let him know about the scripts
<madduck> thom++ on your blog post
<nags> seb128, we are also working on gedit scripts, more than 70 scenarios we have automated, by next week it will be on your table :)
<nags> brb
<seb128> rock!
<siretart> seb128: pong re bug #48138
<Ubugtu> Malone bug 48138 in totem "totem-xine crashes when started with no argument" [Unknown,Fix released]  http://launchpad.net/bugs/48138
<siretart> seb128: I reassigned it because following the bugtrail, and after looking at the referenced gnome bug, I came to the conclusion that the bug is rather somewhere in totem-xine than libxine
<seb128> siretart: just wanted to point that the commit message is a libxine one, it has been reassigned back to xine-lib since ;)
<seb128> siretart: I've not copied the first line of the comment from bugzilla which is "Fixed in xine-lib HEAD"
<seb128> follow by the "revision 1.30"
<siretart> oh. I see. my bad
<siretart> checking xine-lib cvs..
<ajmitch> hi
<siretart> seb128: you're right, my bad. I identified the patch in upstream cvs, I can try to cherry pick that patch to our package. 
<seb128> siretart: np, thank you for looking at it, that would be nice ;)
<ozamosi> Does anyone here know where I can find documentation about the way ubiquity works?
<pitti> RTFS?
<Hobbsee> heh
* Hobbsee likes pitti's answer
<pitti> ozamosi: seriously, you can look into the various specifications on wiki.ubuntu.com
<ozamosi> If S means spec, then yes, that's what I'm looking for.
<pitti> ozamosi: 'S' usually means 'source', but the specs might be helpful as well, depending on how much detail you need
<ozamosi> Of course... When the spec was written, it was called Ubuntu Express... Found it! :)
<tseng> ubuntu express was renamed to espresso and then to ubiquity
<tseng> to aid in your searching
<pygi> hey Hobbsee 
<Hobbsee> hi pygi 
<rodarvus> guys, I have a pending update for xorg-server (about 16 new patches applied). I'd like to have as much testing as possible, on this new release
<rodarvus> it is available on http://people.ubuntu.com/~rodarvus/packages/xorg-server/ (for i386 and amd64)
<ajmitch> rodarvus: will test
<pitti> rodarvus: grabbing
<rodarvus> ajmitch, thanks!
<rodarvus> pitti, thanks!
<StevenK> Hum.
<StevenK> Launchpad is on crack.
<ajmitch> StevenK: this is news?
<StevenK> The buildd log says a build took 48 seconds, and Launchpad says it took 16 minutes.
<StevenK> ajmitch: :-P
<rodarvus> StevenK, I'm sure the LaunchPad developers will be thankful to receive your bug report :)
* pitti wonders whether he is on crack and why all built package binaries suddenly already have gnu debuglinks; this breaks debhelper's -dbg package building
<pitti> can anyone please bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/pkg-create-dbgsym/ubuntu , cd dhtest.dbg, and debuild -us -uc -b? (on very latest edgy)
<pitti> (or apt-get source pkg-create-dbgsym, works as well)
<pitti> building zsh breaks for me, too
<rodarvus> pitti, it works - do you want me to upload the resulting .deb somewhere?
<pitti> rodarvus: no, not necessary
<pitti> rodarvus: suddenly, all packages which build a -dbg package break for me
<pitti> rodarvus: since they already have a gnu debuglink, so when dh_strip tries to add its own, it breaks
<rodarvus> time to reinstall? :)
<pitti> rodarvus: bwah, I reinstalled two days ago :/
<rodarvus> ouch
<pitti> and it still worked yesterday
<pitti> it broke after today's dist-upgrade
<rodarvus> I reinstalled my main desktop yesterday
<rodarvus> too much breakage on it after building/testing X.Org 7.1
<pitti> rodarvus: do you have libc 2.4-1ubuntu7?
<pitti> it's the only package that is remotely toolchanin
<rodarvus> pitti, yes
<pitti> although I don't see how libc6 would have influence on the debuglink
<pitti> hm
<pitti> my box is clearly screwed then
<pitti> rodarvus: thanks!
<rodarvus> np
<Hobbsee> pitti: i killed it last night.  sorry about that :P
* pitti grrs at Hobbsee 
<Hobbsee> pitti: the plan of world domination is succeeding.
* Hobbsee grabs her whip, and shows it to pitti.  be careful, oh growling one :P
* pitti changes from grrring to purring
<rodarvus> pitti, wait
<pitti> rodarvus: please tell me I'm not on crack
<rodarvus> building the code from bzr fails for me too, while building from the source in the archives works
<pitti> rodarvus: are you sure? they are identical
* Hobbsee hugs pitti :)
<rodarvus> yup
<Hobbsee> good pitti 
<rodarvus> pitti, pasted on /msg window
<pitti> rodarvus: right, I get the same error here
<pitti> rodarvus: bug diff -Nur' in the two directories shouldn't give any difference, doesn it?
<rodarvus> let me check
<pitti> can anyone else on *latest* dapper please try to build zsh and see whether dh_strip aborts with an "Invalid operation"?
<mvo> pitti: I can do this, give me a bit
<pitti> rodarvus: I get the same fault from the archive version
<pitti> mvo: or, any package that builds a -dbg package, doesn't matter
<pitti> zsh just was the smallest example I could find in 30 seconds
<mvo> pitti: I have some outstanding upgrades (~10), I do them now and will build then
<rodarvus> pitti, same stuff on both
<pitti> mvo: can you please try both before and after?
<pitti> mvo: is libc amongst the outstanding ones?
<mvo> pitti: no, looks like its only gstreamer stuff
<pitti> mvo: just build dhtest.dbg in pkg-create-dbgsym then, it's faster
<pitti> mvo: oh, ok
<ajmitch> rodarvus: this xserver appears to work ok on i386 - at least no issues in the limited testing I've done
<rodarvus> ajmitch, thanks
<rodarvus> ajmitch, switching to vt1 works as usual (considering vt switching is working for you currently)
<ajmitch> yes
<rodarvus> hooray
<rodarvus> pitti, the machine you are going to test xorg-server on is an amd64?
<pitti> rodarvus, mvo: bingo! after downgrading libc6 it works again
<pitti> rodarvus: yes
<rodarvus> nice
* pitti files a bug
<mvo> pitti: that means I can stop building zsh?
<pitti> mvo: yes, I think so
<mvo> pitti: it seems to have build for me, what version of glibc do you have installed?
<pitti> mvo: 2.4-1ubuntu7
<pitti> mvo: it works with ubuntu6 and fails with ubuntu7
<mvo> <pitti> can anyone else on *latest* dapper please try to build zsh and see whether dh_strip aborts with an "Invalid operation"? <- you meant latest edgy?
<pitti> erm, of course
<pitti> sorry
<mvo> :)
<mvo> ok, that explains why it build here :)
<pitti> mvo, rodarvus: bug 55880, in case you can add some confirmations
<Ubugtu> Malone bug 55880 in glibc "libc6 2.4-1ubuntu7 adds gnu debuglinks by default" [Critical,Unconfirmed]  http://launchpad.net/bugs/55880
* pitti reboots to test the new X server
<pitti> rodarvus: no noticeable difference with the new x server
<rodarvus> yaya
<rodarvus> must mean this version is perfect
<rodarvus> I'll upload it right away
<rodarvus> pitti, thanks!
<ogra> bugfree and all ?
<rodarvus> ogra, X never has bugs
<rodarvus> its always fault of the kernel, gnome/kde, etc
<ogra> yeah, tell that to malone :)
<rodarvus> ogra, all X bugs are there because I'm lazy to properly redirect them to their real owners :P
<seb128> what should be done with bugs like bug #55865 ?
<Ubugtu> Malone bug 55865 in Ubuntu "[Edgy]  Please remove obsolete libnautilus-burn3 from archive" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55865
<ogra> its like ltsp ... there are only network hardware probs, but no bugs :P 
<seb128> reassigning to ubuntu-archive?
<Hobbsee> seb128: can it.  user was wrong.
<Hobbsee> s/can/traschcan/
<slomo> seb128: ubuntu-archive only wants to be subscribed iirc... but this one can maybe even be rejected... they will remove the old binaries anyway next time
<pitti> seb128: not reassign, subscribe it
<seb128> pitti: it's already subscribed
<pitti> rodarvus: hm, another nice test - the build should fail since it builds a -dbg :)
<seb128> pitti: but I don't want to take the bug and I don't want to let it unassigned
<rodarvus> heh
<pitti> seb128: unassigning should work as long as -archive is sub'ed
<seb128> pitti: right, but the bug stays as noise for bug triagers then
<pitti> seb128: well, it should disappear automatically anyway...
<pitti> it's the standard NBS case
* pitti hugs mvo for the new u-n
<Riddell> pitti: builds with -dbg fail now?
<pitti> Riddell: yes, see bug 55880
<Ubugtu> Malone bug 55880 in glibc "libc6 2.4-1ubuntu7 adds gnu debuglinks by default" [Critical,Unconfirmed]  http://launchpad.net/bugs/55880
<Riddell> pitti: ok, that'll be all the KDE packages needing changed then :)
<pitti> Riddell: no, don't
<pitti> Riddell: either we'll fix it in glibc or in debhelper/pkg-create-dbgsym
<Riddell> yeah, just read the bug
<pitti> Riddell: I wait until jbailey wakes up to discuss it with him
<pitti> I didn't find anything in the glibc changelog
<cprov> who is Gauvain Pocentek <gauvainpocentek@ubuntu.com> ?
<ogra> Gloubiboulga
<cprov> ogra: tks
<ogra> btw, using your own tools helps ;) https://launchpad.net/people/gauvainpocentek
<Gloubiboulga> bug 55795
<Ubugtu> Malone bug 55795 in launchpad "replaces Debian maintainer by Ubuntu maintainer in changelog" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55795
<ogra> Gloubiboulga, thats a duplicate 
<ogra> err, oh
<ogra> ignore me ...
<StevenK> How the hell is that a bug?
<ogra> thats no bug
<ogra> the one who made the last change has to show up in the changelog
<StevenK> Like I said.
<desrt> erm
<desrt> that probably is a bug.
<ogra> desrt, ?
<desrt> he took the upstream changelog entry directly and changed only the name
<desrt> if he changed other stuff to he should have done
<desrt>  [ Changes by _____ ] 
<desrt> then added his own changes
<desrt> *too
<ogra> * Resynchronise with Debian. 
<ogra> thats enough if a package has ubuntuX versions before and after the merge
<desrt> that's very old
<desrt> there shouldn't be an ubuntu maintainer's name on a non ubuntu version, though
<ogra> stillflame, it has ubuntu specific changes, so the name of the person making these changes is the right one for the changelog
<desrt> they should do the synch, preserving the debian changelog and then have their name on the change -after- the synch
<ogra> right, if it would have been synced that wouldnt happen at all
<ogra> but it was maerged
<ogra> *merged
<ogra> so thats perfectly right
<desrt> well.  seems fishy to me.
<ogra> it names the person who was responsibe for the manual merging between the last and the current ubuntuX version ... 
<desrt> the merging occured as work going into the ubuntu1 version and should be listed there
<desrt> it wasn't done as work going into the upstream version (2.0.7-3) and therefore should _not_ be listed there
<desrt> (and, in fact, it isn't listed there at all -- only the name has changed)
<ogra> you mean it should have two different entries ? 
<desrt> i would imagine so
<desrt> considering it already has what appears to be two somewhat broken entries
<desrt> discover (2.0.7-3ubuntu1) edgy; urgency=low
<desrt> discover (2.0.7-3) unstable; urgency=low
<desrt> to most people this doesn't look like a single changelog entry.  i think that's the problem.
<desrt> if he was doing that it should read like
<desrt> discover -3ubuntu1
<desrt>   *merge
<desrt>     -list of
<desrt>     -changes from
<desrt>     -debian
<jdub> rodarvus: 003_fedora_root_window_black_pattern.patch -> we already get that by doing -br in gdm.conf
<ogra> Gloubiboulga, does xubuntu have no pointrelease ? http://cdimage.ubuntu.com/xubuntu/re...6.1/release.1/ is mentioned in the announcement, but doesnt seem to exists
<desrt> -- guy <foo@ubuntu.com>
<jdub> rodarvus: better to use configuration than patching :-)
<rodarvus> jdub, nice, thanks for the heads up :)
<rodarvus> I'll remove it in the next package upload
<rodarvus> jdub, xubuntu and kubuntu do it in their windowmanagers too?
<ogra> desrt, that would extend the merge work a lot ... we rely on dpkg-genchanges -v doing the right thing usually
<rodarvus> (... do you know if...) :)
<jdub> rodarvus: no idea
<Gloubiboulga> ogra, http://cdimage.ubuntu.com/xubuntu/releases/dapper/release.1/
<ogra> instead of reformatting the whole changelog :)
<jdub> what does xubuntu use for it's display manager anyway?
* Hobbsee suspects keybuk will hate her soon.  if he doesnt all ready.
<desrt> jdub; gdm
<ogra> Gloubiboulga, hmm, the link in the announcement is wrong then
<desrt> jdub; with a nice blue theme
<ogra> http://cdimage.ubuntu.com/xubuntu/releases/6.06.1/release.1/
<jdub> rodarvus: so there's your answer for xubuntu; check kdm for kubutu ;-)
<jdub> desrt: thanks ;)
<rodarvus> doesn't gdm requires the gnome stack to be installed?
<jdub> YAYAYAY CAIRO!
<rodarvus> I should install xubuntu one of these days
<Riddell> rodarvus: yes (kubuntu does)
<jdub> rodarvus: yeah, care of gnome-canvas
<robertj> can anyone suggest a way to be more...spontanious? my /random is running short :(
<robertj> and the mouse isn't in easy reach
<Spads> lrwxrwxrwx 1 root root 7 2006-08-10 14:09 /dev/ass -> urandom
<rodarvus> jdub, desrt, Riddell: thanks again!
<Gloubiboulga> rodarvus, gdm only depends on gconf IIRC
<Gloubiboulga> but not on all the gnome libs
<ogra> gdm on gconf ? 
<ogra> what for ? 
<sladen> jdub: sadly cairo is not Yeah, Yeah, Yeah, good.  If it were, people like Inkscape would be wanting to use it in preference to stucking with libart.  See: http://www.xaraxtreme.org/about/performance.html for how much, er, "potential" and loving cairo needs to receive.
<jdub> sladen: i know all about cairo's issues; i am merely celebrating 1.2.2 being in the repos
<ogra> it depends on libgnomecanvas2-0 and thus on gnome ...
<jdub> ogra: though i see now that gnomecanvas has tidied up depends now
<Gloubiboulga> ogra, err, you're right
<ogra> jdub, right ... but enough to not dep on gnome anymore ? 
<jdub> ogra: look at libgnomecanvas2-0 depends
<ogra> yeah, i'm just doing that ... nice ! :)
<jdub> ogra: schmick compared to what it used to be like
<lool> hmm is dholbach on holidays?
<lool> looks like it
<pitti> hi lool 
<lool> hi pitti!
<seb128> lool: yep, until the wiesbaden sprint in 10 days
<lool> seb128: thanks
<Hobbsee> hi heno 
<spike> hi
<seb128> np
<spike> I was in the need of lndir, and it's not in the xutils pkgs, is there a reason for that?
<spike> it's in the debian one
<spike> and an apt-file search lndir will find some manpages references
<spike> any idea?
<azeem> spike: it got lost during the X modularization
<spike> azeem: I see. and it's definitely lost or what? should I raise a bug if one doesnt exist already?
<azeem> spike: I suggest filing a wishlist for moreutils in Debian to include it (and point them to the source or attach it)
<rodarvus> spike, lndir is part of xutils-dev
<rodarvus> which is present on Ubuntu Edgy.
<rodarvus> rodarvus@wakko:~$ dpkg -L xutils-dev | grep lndir
<rodarvus> /usr/share/man/man1/lndir.1x.gz
<rodarvus> /usr/bin/lndir
<rodarvus> rodarvus@wakko:~$
<azeem> seems packages.u.c is broken WRT contents and edgy
<spike> rodarvus: uhm, how does it come apt-file search wont find it? nor http://packages.ubuntu.com/
<azeem> "You have searched for the contents of xutils-dev in edgy, architecture i386.
<azeem> Can't find that package, at least not in that distribution and on that architecture"
<rodarvus> spike, *shrugs*
<rodarvus> maybe it hasn't been updated for new packages in edgy?
<rodarvus> xutils-dev is a new package
<spike> oh, nm, my bad, I was thinking of dapper
<spike> indeed, sorry
<heno> Hobbsee: hello :)
<Hobbsee> :)
<nags> seb128, one help regarding libwnck, can I ask you ?
<seb128> nags: sure
<icecrash> moin
<nags> seb128, copied gok-windowlister.c and trying to write a small program, to bring a bg window to fg
<nags> seb128, Casanova tried this - http://pastebin.ca/125165
<nags> seb128, we both are getting segfault in screen.c
<nags> seb128, #0  0xb7ecd4ba in wnck_screen_get_default () at screen.c:468
<seb128> nags: why do you fflush(stdout); every time you printf something? just curious
<nags> wnck_screen_get_default () actually calls _wnck_event_filter_init ();
<nags> Casanova, ^^^^ ?
<Casanova> seb128: i just wanted to know where it segfaulted :D
<seb128> Casanova: if you printf("message\n"); that should be enough, no need to fflush
<Casanova> seb128: hmm well it wasnt printing :)
<seb128> Casanova: run gtk_init before calling refreshList
<seb128> nags:
<Casanova> oh ok
<nags> seb128, okay
<seb128> or gdk_init
<seb128> should be enough for that
<nags> seb128, okay
<nags> seb128, Thanks, it works :)
<seb128> np
<Casanova> seb128: it still crashed on wnck_window_get_workspace (window_list_entry->data);
<Casanova> any idea why?
<Casanova> oops
<seb128> Casanova: doesn't for me
<Casanova> seb128: sorry my fault :)
<seb128> Casanova: are you sure window_list_entry != NULL?
<seb128> k
<LisaH> Hi....My name's Lisa and I'm writing an article for NewsForge.com about today's 6.06.1 release. I have a couple of questions for the developers if one of you has a minute.
<Hobbsee> hi LisaH 
<iwj> Feh, it trashes the homepage setting.  Why ?
<Kamion> ogra: fixed the xubuntu point release link to work; thanks
<ogra> :)
<ogra> Kamion, that really shouldnt have been your task
<Kamion> (waiting for mirrors to sync; mirnyy's being slow)
<ogra> go away from IRC !!
<Kamion> *shrug* it was just a missing symlink
<ogra> :)
<Hobbsee> Kamion: excuses excuses.  now take a holiday :P
<Kamion> don't worry, I am
<Kamion> IRC != work
<Hobbsee> Kamion: surely that depends as to whether it's on or offtopic?
<infinity> LisaH: Are you looking for an interview with someone, PR fluff, or just to clear up a few random points?
<pitti> LisaH: might be best to just ask the questions here
<LisaH> Thanks...I've got a few chats going on at the moment but I may be back here for some further questions. 
<pitti> BenC: ah, cool; from looking at the git commits, I only saw pid and signal number passed to the crash dump helper
<BenC> pitti: You probably saw the case where the core size is greater than the apport temp size, there's a second part where the helper gets called with the core file name
<pitti> BenC: hm, I looked at both in http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob;h=45b34f79920db4bbe3ae05711dc18a9c5161fe0b;hb=6955793faeb05f4a73ec25b7b59e9d5e036a7793;f=fs/exec.c
<pitti> BenC: lines 1514 and 1572
<pitti> BenC: aaah, now I see
<pitti> must have been bling
<pitti> blind, too
<pitti> BenC: sorry for the fuss!
<BenC> np :)
<Keybuk> so, what methods of intelligent design have people followed that worked for them?
<Keybuk> sfllaw: you mentioned that there are sane ways?
<doko> Keybuk, infinity, Kamion, mdz: please do not process the new binaries from the gcj-4.1 source until it's built on all architectures
<pitti> Keybuk: the only method that really worked for me was iterative design while comparing to a wide range of use cases
<Keybuk> doko: normally we don't anyway
<Keybuk> due to bugs in Soyuz
* infinity makes of a note of one more thing that's going to break when he bootstraps hppa.
<infinity> \o/
<infinity> That's going to be a painful week.
<Keybuk> infinity: let Lamont do it <g>
<sfllaw> Keybuk: The parts of upfront design that are useful are those that define the problem.
<Keybuk> "your toy architecture, your flaming beige plastic anal violation"
<infinity> Nah, then I wouldn't have anything to complain about.
<infinity> Besides, it's my toy arch too.  Or one of them.
<sfllaw> So requirements specs, like "what problems need to be solved".
<sfllaw> That's actually really hard.
<sfllaw> Because most people think of solutions before problems.
<sfllaw> Which is where you get into trouble.
<Keybuk> sfllaw: yeah, that's the part I really enjoy
<Keybuk> my problem comes when it comes to the actual coding
<Keybuk> I find if I've spent too long designing it, especially at the code level, I get a kind of "coder's block" and can't actually write it
<sfllaw> When it comes to coding, if you've thought which problems need solving, you don't need to specify the implementation too much.
<sfllaw> Lots of what is fun about coding is encountering a problem and then solving it on the fly.
<Keybuk> Matt was advocating a detailed advanced planning thing this time around, so that time estimates would be possible
<Keybuk> where you break the code down into very small tasks, and work them out by the hour how long they take
<sfllaw> If you pull the problems into the specification process, you can hold them all in your head at the same time.
<sfllaw> Oh.
<sfllaw> That's really hard.
<sfllaw> The best I can find for scheduling is Joel's Painless Software Scheduling.
<sfllaw> But even that gives you slack.
<mjg59> Keybuk: What's responsible for generating the /dev/disk/by-label directory?
<Keybuk> mjg59: udev rules (65-persistent-storage.rules)
<sfllaw> I don't like implementation specs too much.
<Keybuk> mjg59: it uses vol_id to find the label of the disk
<sfllaw> I don't even like functional specs, except for specifying infrastructure and API/ABIs.
<mjg59> Keybuk: Ok. If I create a partition, how do I provoke it into appearing?
<sfllaw> That's because interoperability is sometimes valuable.
<Keybuk> mjg59: normally it should just appear when the kernel sends out the uevent
<Keybuk> though the kernel is not always good at this
<mjg59> Keybuk: I've done a mkswap /dev/hda3 -L swap
<Keybuk> ahh
<Keybuk> right
<mjg59> And blkid
<Keybuk> block device != partition
<mjg59> But no by-label
<Keybuk> you mean filesystem
<mjg59> Yes, sorry
<Keybuk> echo -n add > /sys/block/hda/hda3/uevent
<mjg59> Ok, that works
<mjg59> Next issue
<Keybuk> it's a long-standing bug of mine that the kernel deals with block devices not partitions ;)
<Keybuk> gah, FILESYSTEMS
<mjg59> If I have a vfat partition, and then mkswap it, libblkid seems to find the fat UUID rather than the swap one
<Keybuk> yes
<Keybuk> vol_id has a similar problem with fat/ext3 I believe
<mjg59> I'm not sure if that's helpful, though I guess it doesn't break anything
<Keybuk> partman deliberately zeros the partition bits first
<Keybuk> right, it won't break anything, it just means things are ... wrong ;)
<mjg59> And thirdly:
<mjg59> blkid doesn't seem to find my swap uuid/label when it contains a suspended image
<Keybuk> indeed
<Keybuk> blkid is rubbish
<mjg59> So resume from disk is broken right now
<Keybuk> at the sprint, I'm going to sit down with tollef and get mount to use vol_id instead
<mjg59> Presumably it just needs teaching about where they live?
<Keybuk> yeah, but it's less effort to just do the vol_id change
<mjg59> Mount's not the issue here
<Keybuk> SuSE already patched it
<Keybuk> oh, what is the issue?
<mjg59> It's a swap partitoin
<Keybuk> s/mount/util-linux/
<mjg59> Ah, right
<Keybuk> they all use the common code
<mjg59> Yes, that makes more sense
<Keybuk> sorry
<Keybuk> there are other issues anyway, like blkid doesn't seem to support fat uuids
<mjg59> I'll look at blkid anyway, since I'd like this to work before then
<mjg59> I'm playing with uswsusp. It seems to have the potential to be quite a bit faster than swsusp.
<mjg59> (Back in a moment, need to change my buffers)
<mjg59> Ok
<zul> hi
<mjg59> Keybuk: Turns out to be a trivial patch, by the looks of things
<Keybuk> unsurprising
<Keybuk> the vol_id patch was tiny also
<mjg59> It actually deals with the standard image, just not the userspace one...
<mjg59> Testingnow
<nags> seb128, I have some queries with respect to libwnck, whom shall I ask ?
* Keybuk sniggers
<mjg59> Keybuk: Yeah, fixed
<mjg59> 4 extra lines
<mjg59> I'll upload now
<elmo> hey, my gnome thinks my machine is at 2% battery when it has 2 hours remaining - how do I kick it to uncache those values
<elmo> +?
<pitti> elmo: try /etc/dbus-1/event.d/20hal restart
<elmo> pitti: it's been like this for months
<elmo> pitti: so I can't imagine restarting anything'll help
<elmo> the problem is when I first installed ubuntu on the machine, the battery was fried (I'd done a partial 'drain-recharge' cycle in the BIOS), so back then, it really did only last a couple of minutes
<pitti> oh
<mjg59> Keybuk: Hm. So udev uses libvolid to find swap labels and stuff?
<Keybuk> mjg59: right
<mjg59> Ok
* mjg59 goes to fix it there too
<Keybuk> fix which?
<Keybuk> I may have already fixed whatever you're planning to fix there
<mjg59> Keybuk: volume_id doesn't appear to detect my suspended swap partition
<Keybuk> mjg59: the edgy one?
<Keybuk> should do
<mjg59> Yeah
<mjg59> Hm
<Keybuk> there's definitely a patch for that in there, and I tested it a bit
<mjg59> Keybuk: It needs to recognise ULSUSPEND as well as S1SUSPEND
<Keybuk> aha!
<Keybuk> yes, fix that
<Keybuk> just modify the existing patch
<mjg59> Oh god what's the right way to do this?
<Keybuk> debian/patches/60-vol_id-swap.patch
<Keybuk> add
<mjg59> Patch it without that patch, add the patch, generate the diff, replace the original patch?
<Keybuk> oh
<Keybuk> yeah
<Keybuk> I just apply the patch, tinker with it, and diff against the orig
* Keybuk and complicated patch systems don't get on
<Keybuk> so I do things the very hard way
<mjg59> http://www.codon.org.uk/~mjg59/tmp/60-vol_id-swap.patch look ok?
<Keybuk> missing a == 0) in there :p
<Keybuk> the ) is especially important
<mjg59> Oops
<mjg59> Try again?
<Keybuk> looks right
<mjg59> Ok, testing now
<sladen> rodarvus: can you remember what the current work around for "cannot find font fixed is" (bug #54809) ?
<Ubugtu> Malone bug 54809 in Ubuntu "X server cannot find default font `fixed'" [Untriaged,Confirmed]  http://launchpad.net/bugs/54809
<gnomefreak> yes ;)
<gnomefreak> sladen: remove --purge xserver-xorg-core xorg and xserver-xorg  than install them it should fix it (atleast it did for a few of us)
<ogra> sladen, run mkfontdir in the misc font directory fixes it
<gnomefreak> of course :( you could take the easy way :(
<sladen> ogra: no, that doesn't fix it here.
<ogra> oh ? 
<ogra> thats intresting then 
<sladen> ogra: and even if I fix things to point to the /right/ directory it doesn't fix it
<ogra> well, its not broken here currently ... i built a ltsp chroot today that starts X just fine ... hmm
<sladen> gnomefreak: nope, apt-get --purge --reinstall install ...  didn't help
<gnomefreak> sladen: no dont use --reinstall
<sladen> gnomefreak: thanks for the pointer though
<ogra> sladen, /usr/share/fonts/X11/misc/fonts.dir exists ?
<gnomefreak> for some reason --reinstall doesnt fully do what you would like it to do
<sladen> gnomefreak: well it doesn't remove the dependancies, which if it does work means it's one of those that is broken
<gnomefreak> sladen: i couldnt get --reinstall to work with that i had to remove --purge than apt-get install and it fixed it
<gnomefreak> it removes the 3 -desktop packages and something else (cant think of it offhand) with the X packages
<treitter> what creates "md5sums" in control.tar.gz ?
<treitter> dpkg, or do I do it?
<pitti> treitter: dh_md5sums
<pitti> treitter: it's not essential (only used by debsums), but still nice to have
<treitter> pitti: invoked directly, or does something else call that?
<pitti> treitter: cdbs calls it automatically, with just debhelper it's your job AFAIK
<treitter> pitti: now I have to look up cdbs :)
<treitter> ah. cdbs requires Makefiles, right?
<treitter> my project doesn't use Makefiles (at least when I pick it up and package it)
<pitti> treitter: not any more or less than plain debhelper packages
<pitti> treitter: don't worry about it if you don't know cdbs or don't want to use it
<treitter> pitti: cool. Thanks :)
<treitter> ..so dpkg requires all the control files in ${PKG}/DEBIAN, while dh_md5sums requires them in ${PKG}/debian
<treitter> hmm. I don't think dh_md5sums is ideal for what I'm doing. I'll just use md5sum directly
<Burgwork> sabdfl, I love it when you fix my bugs and then blog about them
<sladen> ogra: ...so, half the places refer to 'X11/fonts' and the other half to 'fonts/X11', meaning that the fonts end up in one, but the aliases that maps 'fixed' end up in the other...
<mdke> Burgwork: that happens a lot?
<Burgwork> mdke, no, not really, but the essential people one is my bug from UBZ, when we had people not being at spec bofs because of the lack of it
<mdke> oh, that post, nice
<doko> pitti: will you upload glibc tonight?
<pitti> doko: yes, after pkg-create-dbgsym is in the archive
<mjg59> Whee. That works.
<mjg59> Now it just needs some usplash loving.
<Surak> when there are more than one video board plugged on a machine, how does hwdata chooses which one it should use?
<Surak> I have a particular case where Xorg.0.log says: "(II) Primary Device is: PCI 01:00:0", but the Live CD tries to use the other video card - which is disabled in bios, but still appears in device list. It appears first, but it's not necessairly the primary one....
<Surak> sorry, I mean "discover", from discover1 package, not hwdata.
<Keybuk> init:stop_my_job: Timer to stop job called
<Keybuk> init: Goal change: stop test
<Keybuk> init:job_kill_process: Sending TERM signal to test process (27481)
<Keybuk> init:my_reaper: Child 27481 killed by Terminated
<Keybuk> init: test process (27481) killed by signal 15
<Keybuk> init: State change: test: running to stopping
<Keybuk> \o/
<sladen> Surak: is there a bug report for it, can you file one?
<sladen> go Keybuk, now --fomg-optimize is so that the gentoo wannabe's quit moaning :)
<Keybuk> heh
<Surak> sladen: I was asking before, so I would post the bug more concisely. I found that /sbin/discover ignores which video board is the primary (as noted in Xorg.0.log), it only lists them in the same order as lspci does. However, would this be a bug from discover or from xserver-xorg's configure script?
<Surak> g/as/that
<mdz> mjg59: what's uswsusp?
<sladen> mdz: userspace suspend
<sladen> mdz: suspend for nice people, without the gash
<mjg59> mdz: Suspend to disk with compression and potentially graphical niceness
<Burgwork> mdz, just realized something about the .1 release announcement. We shoudl make it very clear that merely upgrading will achieive the same result
<nate> Is the CD-Images rsync down?
<mdz> Burgwork: it's already gone out
<Burgwork> mdz, yep, I realize that. But for the .2 release notes
<treitter> is there a way to have dpkg-deb ignore specific files (like .cvs or .svn dirs), or is it expected that you'll remove them yourself as necessary?
<sladen> mdz: what's the best way of dealing with packages that have gone from '6.8.2.1-5' to version '1.0.0-6ubuntu3' ?  The downgrade is causing upgrade problems
<zul> http://70.29.57.2/ubuntu/xen-edgy-within-edgy.png
<Spads> sweet
<sladen> zul: excellent news, shall we fridge it :)
<crimsun> sladen: err, that should have an epoch. Which packages?
<sladen> crimsun: xfonts-utils
<zul> sladen: if you want maybe i should clean up my desktop first though :)
<rodarvus> sladen, the right is 1:1.0.0-foo
<rodarvus> (or, "use epochs" :) )
<crimsun> that's odd, since it /does/ have an epoch
<sladen> zul: I can't see anything dodgey on there, I don't /think/
<Spads> zul: win32!
<zul> i have a couple of torrents on my desktop i think
<rodarvus> sladen, are you sure you didn't forgot to add the epoch to your last changelog entry?
<rodarvus> most likely the case here
<crimsun> rodarvus: (meaning to me? It's present.)
<sladen> rodarvus: I haven't done an upload, this is the result of doing an dapper->edgy upgrade
<rodarvus> crimsun, well, or you :) (/me didn't read the backlog)
<crimsun> I'm quite sure, since I used dch -i and double-checked before uploading
<rodarvus> xfonts-utils | 1:1.0.0-6ubuntu3 | http://archive.ubuntu.com edgy/main Sources
<rodarvus> this is what I have here
<crimsun> sladen: what is dpkg spitting out?
<mdz> sladen: that's not a downgrade, that's a change in upstream numbering (hence the epoch)
<mdz> if the upgrade isn't working properly, it's a bug
<sladen> crimsun: the epooch appears to be there in your upload
<crimsun> right. With what errors is dpkg bailing?
<mdz> treitter: by the time you reach dpkg-deb, anything you don't want should have been excluded earlier
<mdz> treitter: dpkg-deb just packs up the installed tree; if you don't want those files there, don't install them
<treitter> mdz: yeah, that's what I thought. My situation is a little different, though. So I can handle it on my own :)
<treitter> mdz: thanks
<sladen> crimsun: I think the problem simple comes down to all the packages calling it with --new-option not depending on (>= 1:1.0.0-4) which is when the new option was introduced.  It's still a bit disgusting that X completely breaks from something so simple.  The lack of 'fixed' was the cause of something previously and having a rock-solid way of having at least one font available seems to be a bit like us providing busybox when your root partition can't 
<libervisco> hey guys
<sladen> hello there libervisco, is the weather nice where you are.  It's getting a bit dark here and earlier it was raining
<libervisco> Where do you go if you badly need contributors for your software project?
<libervisco> ehh yeah weather is ok.. kind of cloudy though :)
<sladen> libervisco: who is "you" in this case, ubuntu, or yourself?
<libervisco> any developer with a project in need
<libervisco> I'm just trying to check if there is a site or service that enables devs to list their project as "in need of contributors"
<libervisco> because I would like to open one
<libervisco> on our site
<libervisco> do you think it would be of help?
<Surak> sladen: done. bug #55928 . I think I explained enough, but that's me :-) I can provide more information if needed
<Ubugtu> Malone bug 55928 in xorg "xorg's configure script doesn't detect primary video adapter properly in multi-video environments." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55928
<sladen> Surak: okay, many thanks for that.
<Surak> regarding the broken bios, I've sent similar reports to intel and msi on several different modern motherboards that shows the issue. MSI is receptive to my reports lately.
<sladen> Surak: remind me what the broken BIOS issue was?  ACPI DSDT?
<sladen> excellent to know that MSI are listening
<Surak> oh, it's on that bug. The fact that even when you disable integrated video, it still appears on pci device list
<bluefoxicy> fabbione:  after consulting several network engineers it seems we've all concluded that attaching two routers to eachother through a switch housing another subnet will exponentially increase the load on the involved port on the default gateway as the two subnets grow; whereas connecting the two routers over a dedicated router-to-router link results in linear growth
<bluefoxicy> s/exponentially/polynomially/g
<bluefoxicy> so yeah, my point stands and has been validated:  that design is brain damage.
<Riddell> jordi: ping
<bluefoxicy> .... someone should figure out why Evolution needs 571 megs of memory (I just freed 400M of swap and 200M of RAM o_O) to manage around 400 messages, while Thunderbird (started at the same time) is using 185M to manage a few hundred thousand (other account is subscribed to about 30 mailing lists)
<Burgwork> bluefoxicy, evo memory issues are being worked out
<Surak> hum... how did you measure this?
<bluefoxicy> Surak:  well, first off i looked at virtual and figured out how much it thinks is there; second, I closed evo and went fro 960M used (270 cached) and 860 swap to 660 used (330 cached) and 440 swap
<bluefoxicy> so 690 + 860 -> 330 + 440 == 1550 -> 770, ... wtf.  That's more than 571 megs, how is that even possible.. oh.  I didn't count the evolution data server.
<bluefoxicy> htf much was that reporting mapped into VMA, I didn't look :|
<zyga> bluefoxicy: fragmentation probably
<bluefoxicy> zyga:  nods
<bluefoxicy> Surak:  point is I tend to open and close apps and see what the system thinks they're doing to memory.
<Surak> hum, ok
<bluefoxicy> I eventually got down to around 400 megs total
<bluefoxicy> by closing Firefox as well (I'm running FF 2.0)
<bluefoxicy> FF2 seems to be a RAM hog
<bluefoxicy> another silly question would be
<bluefoxicy> why is libc6-amd64 installed on i386
<bluefoxicy>  /lib64/libc-2.4.so: cannot execute binary file
<pitti> good night everyone
#ubuntu-devel 2006-08-11
<sabdfl> Burgwork: yer welcome, though the fix is still in review :-)
<Keybuk> bluefoxicy: that won't make any difference
<Keybuk> (opening and closing apps)
<bluefoxicy> Keybuk:  if you close an application that is taking a lot of ram, and suddenly 400 megs of ram are freed, how much ram was that application using?
<bluefoxicy> (for colloquial definition of "using")
<Keybuk> bluefoxicy: unknown
<Hobbsee> morning all
<Keybuk> you certainly can't tell by measuing how much the kernel gave back
<Keybuk> for all you know, the kernel chose to flush a bunch of page cache at that moment too
<Surak> Hobbsee: night :-)
<bluefoxicy> possibly, but not correlative.
<bluefoxicy> also page cache only gets flushed under memory pressure
<Keybuk> bzzt
<bluefoxicy> besides, there's no other good way to measure memory usage
<bluefoxicy> RES doesn't count swap; VMEM counts mmap()'d and other COW pages that haven't yet been written to; and shared counts stuff that may be shared by a process and itself exactly.
<Keybuk> there is no way to measure memory usage, because memory usage does not make sense
<Keybuk> we can only talk about mythical values
<doko> mdz: pitti was faster with the glibc upload
<bluefoxicy> fair enough
<Keybuk> for example, we could say how much memory evolution would use if that was the only binary running on the system
<bluefoxicy> but at the same time we can create trends in said values.
<bluefoxicy> which have a physical effect.
<bluefoxicy> you don't need to quantify things 1:1 when you do analysis like this.
<zyga> bluefoxicy: you know...
<Keybuk> if you really car
<Keybuk> evolution uses roughly the amount of memory needed to hold the headers of every message that need to go in the list
<Keybuk> it's high
<Keybuk> but it's not 600MB
<Keybuk> it's around 80MB
<zyga> bluefoxicy: do this, log each allocation via .alloc/free/realloc and check out how memory is actually being used, looking at number of pages allocated really doen't tell the whole story
<Keybuk> zyga: that's not necessarily telling either, sadly
<Keybuk> free doesn't return memory to the kernel, remember
<bluefoxicy> for example, I'm going to take the security+ exam soon; the pretest had 30 questions and I got 83%, mastery was 70%; I finished approximately 47% above passing.  Someone told me the test will have about 80 questions; I'm estimating a 20% variance, so I should finish with 38-56% above passing.
<zyga> Keybuk: yes, that's why I recommend that
<Keybuk> an application using malloc/free badly can be "holding" far more memory than it should
<zyga> it tell's the story of the memory needs of the app
<bluefoxicy> the numbers say I'm likely to pass; they also say I could study operational security and probably pass with a higher score
<zyga> not the memory flow between userspace and the kernel
<bluefoxicy> But as you say, mythical numbers that mean nothing right?  :)
<bluefoxicy> Keybuk:  and you're right.
<Keybuk> bluefoxicy: uhh, that's completely irrelevant
<zyga> Keybuk: I am well aware of all that, it's just a better number than rss
<bluefoxicy> evo may have [10M]  .............................................[1 byte]  and hold a bunch of unused memory
<Keybuk> it would only be relevant if your score was based on the number of questions you answered differently to anyone else in the room
<bluefoxicy> Keybuk:  I was illustrating "mythical numbers" having a real point and being useful.
<Keybuk> so if your test was scored on the number of questions you answered uniquely and correctly *then* it would be a useful comparison :p
<zyga> bluefoxicy: or maybe run valgrind tru the app you want, find a leak!
<bluefoxicy> Keybuk:  "obviously" i can make no assumptions as to what my score will be; I could very well fail horribly.  But I can say what is likely the case.
<Keybuk> because then the people that answered all the questions right could still fail, because their unique answers were fewer than anyone else
<bluefoxicy> heh
<Keybuk> at that point, you get to the complexity of discussing memory usage on Linux
<bluefoxicy> that changes the problem.
<Keybuk> evolution's primary memory usage problems are
<Keybuk> a) a large stack of (shared) dependencies
<bluefoxicy> zyga:  valgrind is noisy; it'd be nice if I could actually produce a map of "there are leaks here, this is the percentage that we find to be leaking" and send it to the devs
<Keybuk> b) a high portion of memory not returned to the kernel
<Keybuk> I doubt it has a single "leak"
<zyga> bluefoxicy: valgrind is not noisy but I will not speak of it further
<zyga> bluefoxicy: (just a note that not all memory is freed, ever, before the process exits so valgrind is far from perfect)
<Keybuk> zyga: valgrind usually doesn't mind provided the app has a pointer on it
<Keybuk> it can cope with that
<Keybuk> though it doesn't cope with you not bothering to free something because you know the app is exiting, even though the pointer will be lost before the end of main
<Keybuk> but then if you're running under valgrind, the actual termination isn't useful
<Keybuk> provided you don't lose hold of the pointers during ordinary use, you don't have a leak
<zyga> Keybuk: true
<Keybuk> you may, of course, be holding onto pointers you don't need
<zyga> this reminds me of the multitude of the 'library valgrind behaviour' files valgrind comes with
<Keybuk> I read an interesting paper the other day
<Keybuk> parsing config files, etc.
<zyga> so that stuff that's 'tricky' yet right is not messing the output, I wonder how that stuff is created
<Keybuk> the WRONG way to do this is to try and use fgets and dynamic allocation to cope with arbitrary length lines
<Keybuk> even using realloc on a static pointer is bad, as you'll end up littering memory
<bluefoxicy> zyga:  I used valgrind a long time ago, every time memory leaked it cried about it, instead of being summerical.
<Keybuk> the RIGHT way, which for some reason everyone is scared of, is just to mmap() the config file and treat it as a big string
<zyga> bluefoxicy: try reading the very few last lines next time
<bluefoxicy> I'm the kind of guy that does an strace -c :)
<zyga> Keybuk: then we hit mmap issues but I agree mmap is the right way to let the kernel manage your memory needs
<bluefoxicy> sigh.  I need help with the shell, what the hell.
<zyga> then again unless you are parsing bazillion config files it not that of an issue
<bluefoxicy> Does anyone know how to filter characters
<Keybuk> mmap issues?
<Keybuk> bluefoxicy: -v
* bluefoxicy wants to turn "110K" and "990M" into "110" and "990"
<bluefoxicy> why am I doing this
<Keybuk> | sed -e "s/[A-Z] $//"
<Keybuk> or
<bluefoxicy> this is stupid
<bluefoxicy> thanks
* bluefoxicy rtfm du dammit.
<zyga> Keybuk: yes, it's sometimes problematic with regards to porting and not being 'always works' kind of stuff
<Keybuk> ${%[A-Z] }
<Keybuk> ie FOO=100K
<Keybuk> echo ${FOO%[A-Z] }
<Keybuk> zyga: *shrug*  all the world is Linux ... it's so much easier to code for
<zyga> (you usually need to take care of the part when it fails to be 100% sure)
<Keybuk> I think too much time is wasted supporting 20 year old versions of AIX
<zyga> Keybuk: nah  - all the world is the stuff I want to code for
<zyga> but that's getting more than just linux :)
<Keybuk> or, at least, all the world is POSIX
<bluefoxicy> bluefox@icebox:~/programming/vuln/printf$ j=0; for i in $(du -s $(find /usr/lib/openoffice/program/ -name \*.so) | awk '{print $1}'); do j=$(( $i + $j )); done; echo $j
<bluefoxicy> 101796
<zyga> Keybuk: but then you miss windows and that huts in lots of places
<bluefoxicy> wow openoffice.org mmap()s 100 megs of libraries.
<Keybuk> zyga: I don't care about windows
<Keybuk> bluefoxicy: ah, now, if you want to discuss bloat ... I have no problem with you targetting OpenOffice
<Keybuk> most of those libraries are private too
<zyga> Keybuk: as I said, in some places
<Keybuk> so not only do you have a whole bunch of lard mapped in
<bluefoxicy> Keybuk:  and there's one real soffice.bin
<Keybuk> but then you have all those dirty plts over the top!
<TheMuso> c
<bluefoxicy> Keybuk:  I know, this is fucking stupid.
<Keybuk> "Why OpenOffice.org is slow"
<bluefoxicy> the dynamic linker is like AHHH GOD AHHHH MUST RELOCATE MAP RESOLVES SYMBOLS AHHHHHH
<bluefoxicy> Keybuk:  OOo is also slow because it uses C++
* zyga wonders why the developers decided to do it this way
<bluefoxicy> Keybuk:  but, again, it is slow because the linker has 30 times more symbols to deal with from the crap C++ adds to the symbol table :P
<bluefoxicy> so if all those libraries were built into the main executable, the problem would again go away.
<Keybuk> zyga: "portability" oddly enough
<bluefoxicy> hehe
<zyga> bluefoxicy: hint, c++ has symbol hiding now
<bluefoxicy> zyga:  this doesn't mean developers use it.
<zyga> Keybuk: portablility across software platforms often sucks, ack
<bluefoxicy> you have to explicitly declare symbols as hidden; or set the default behavior to hidden and explicitly set visible symbols to default.
<zyga> bluefoxicy: are you sure...?
<bluefoxicy> zyga:  we do have one nice thing here though.
<bluefoxicy> Michael Meeks has been trying to take the from-the-side approach
<bluefoxicy> and we got some very nice things out of it (even if the RHAT guys are boning him and trying to steal the credit)
<Keybuk> *shrug* he's an idiot
<Keybuk> if they just built the fucking thing properly in the first place, they wouldn't have this problem
<Surak> night all
<Keybuk> "Doctor, it hurts when I do this"
<bluefoxicy> zyga:  Im sure about the symbol hiding thing.. it's __attribute__ __(("hidden"))__ or some such crazy syntax
<bluefoxicy> Keybuk:  who, Meeks?
<Keybuk> that's the C syntax, certainly
<bluefoxicy> the stuff he's doing would give a gain even with properly hidden symbols; it just makes the linker do less work with what it has to do
<zyga> bluefoxicy: AFAIR there was some 'smart' hiding by default so the load on the linker is comparable to that of C
<bluefoxicy> zyga:  ah, nice.
<bluefoxicy> zyga:  I am more interested in -Bdirect binding to eliminate vague linkage where possible; but drepper despises the very idea
<Keybuk> yes, but if OO.o was built properly in the first place, they wouldn't need to be mucking around with the linker
<Keybuk> yeah, I agree with Ulrich here, I'm afraid
<Keybuk> it's taking a chainsaw to the linker because you happen to have dropped it off a cliff
<Keybuk> it's far easier if people just don't break it in the first place
<bluefoxicy> Keybuk:  if OOo was built properly in the first place, mucking the linker would reduce the load time from 1 second to 0.1 second instead of from 12 seconds to 5 seconds
<zyga> I'm off 
<bluefoxicy> also direct binding makes the linker skip searching spaces "we know" it won't find a symbol in
<zyga> this kind of talking does nothing positive to oo. :)
<bluefoxicy> i.e. it makes it not look in the toilet for a floppy disk :P
<zyga> I look forward to edgy and to being here again
<zyga> take care and good night
<bluefoxicy> zyga: heh, later man.
<elmo> where's logmsg() meant to come from in perl?
<bluefoxicy> Keybuk:  btw, they did put precomputed hashes and symbol/hash sorting into the mainline binutils, 50% speed boost :)
<bluefoxicy> I'm hoping edgy+1 will use that, by backport patch or appropriate upstream version
<bluefoxicy> -Bdirect is a slight mess now
<bluefoxicy> it'd create some junk that would get deprecated eventually, so I'm not going to advocate that
<sladen> bluefoxicy: plugging routers into a switch is normally practice, it allows [amongst other things]  (a) monitoring of ports (b) running the router port trunks == breaking out lots more "ports" (c) detecting failures (d) dynamically "re-routeing" at level 2 when things go wrong [eg. an abstraction layer] 
<bluefoxicy> sladen: router -> switch (connected to a subnet full of hosts) -> other router?
<bluefoxicy> sladen:  assuming the default gateway leads to a specific point; and the next subnet has a default gateway leading back to that point; as your network grows, the load on any given router link is going to grow to n^x load, where (n) is the number of subnets behind that router port (including its local subnet) and (x) is the number of hosts per subnet
<bluefoxicy> no sorry x^n
<bluefoxicy> anyway. if you do router<->router, you can lower the value significantly; isolate the default path; and often approach n^1, linear growth instead of polynomial
<bluefoxicy> you can hook the routers to eachother in a mesh form and get (c) and (d) (this is what routing protocols are for)
<sladen> I don't quite follow, but yes, if the packet goes in, then out of the same port on the router, the link will be running at 2x (really not a problem given that it's going to be a non-blocking link and the packets are going in opposite directions)
<bluefoxicy> monitoring of ports.. no comment.  The only thought I can come up with is "plug a passive IDS inbetween" which sounds like "add excess hardware" although it wouldn't be particularly bad
<bluefoxicy> sladen:  I'm saying the dedicated link between subnet A and the internet (which is where default routes "usually" take you) will also carry ALL of subnet B's traffic; if there is another subnet C on the other side of the default gateway for subnet A, then we've now loaded bandwidth on our link between A and C
<sladen> and how do you detect when the IDS goes tits up?...
<sladen> transparent anythings are generally a bad idea
<bluefoxicy> if you hook the two routers together, then we've loaded bandwidth between them and to the Internet and whatever; but connection to networks that AREN'T experiencing a network storm are going to be just fine.
<bluefoxicy> Typically an IDS is connected to a monitoring station
<bluefoxicy> which may or may not be part of your core network
<bluefoxicy> (i.e. it can't talk through the IDS and might not be connected to anything else; this is perfectly fine)
<bluefoxicy> and it'll say "HOLY CRAP IDS DIED!"
<bluefoxicy> you could even have multiple IDSes and a separate network backbone in between them, in theory; but this is blah.
<sladen> (no doubt running Windows and connected to a switch port hanging of the other side of the router ...)
<bluefoxicy> switch->span port->IDS<->Monitor station
<bluefoxicy> is the normal configuration
* sladen just grins
<bluefoxicy> most people stick them after the point of presence and before the routing infrastructure starts to branch
<bluefoxicy> or if you have a BIG network you stick multiple ones around on different network segments since one won't handle the massive load
<bluefoxicy> when I did it the monitor station was plugged into the IDS directly because we didn't want people hacking into it
<bluefoxicy> they hacked the CEO's desktop instead, after stealing our router using SNMP to make configuration changes :/
<bluefoxicy> however, WE SAW WHO DID IT.
<bluefoxicy> what did that look like... {Internet}<->[Router] <->[PIX] <->[Switch] <->[Patch Panel] <->{network}  with a monitor station dangling off the PIX I believe (we were using the PIX for port redirecting and firewalling)
<bluefoxicy> anyway
<bluefoxicy> this is not important
<Keybuk> PUSH PINEAPPLE, GRIND COFFEE!
<Hobbsee> okay?
<Keybuk> sorry, it had to be sung
<zul> Keybuk: you ok
<Keybuk> I could be very evil, and inflict you all with the MP3 that Rhythmbox decided I wanted to listen to
* Fujitsu runs away from Keybuk, quickly.
<zul> heh...still listening to megadeth so do you worse
<Keybuk> http://www.netsplit.com/tmp/03.Black_Lace-Agadoo.ogg
<zul> oh...my...god
<zul> hey ajmitch 
<ajmitch> hey zul 
<bddebian> Heya
* jzb is away: Away at the moment
<imbrandon> o/~ .... sing with a hoola meoldy .... o/~
* imbrandon dances
<zul> uh...ok
<imbrandon> heh , keybuk's song
<zul> that was just evil
<imbrandon> lol
<jeff_> When I install a package for an open source program is the source usually installed as well?
<LaserJock> jeff_: not usually
<jeff_> I'm looking for devilspie's source code in particular
<bddebian> Rarely if you are doing a binary package install
<LaserJock> jeff_: normally it takes up too much bandwidth and hard drive space
<LaserJock> jeff_: you apt-get source devilspie
<bddebian> jeff_: Then you need to apt-get source devilspie
<LaserJock> but make sure you have the source repositories enabled
<bddebian> Aye
<jeff_> which source repositories should I enable?
<poningru> if you got the program from apt-get then you can get the source with the same repos source
<jeff_> ah, thanks
<jeff_> I got it now
<jeff_> hrm, is there a standard name for source packages?
<jeff_> I installed it using apt-get source devilspie, but I don't see it when I search for devilspie in synaptic package manager
<LaserJock> source packages don't show up in synaptic
<jeff_> ok, is there an obvious reason for that?
<LaserJock> could be
<HrdwrBoB> because it would be terribly confusing?
<LaserJock> apt-get source is run as a user and grabs the source package and unpacks it in the current directory
<jeff_> ok
<poningru> needed some help with a bug
<dmb> i don't know if this is the right room, but i just wanted to let you know that the mirror http://ftp.wayne.edu is not working
<dmb> the ubuntu download page links to http://ftp.wayne.edu/linux_distributions/ubuntu/6.06/ubuntu-6.06-desktop-i386.iso, which isn't working
<poningru> bug 55706
<Ubugtu> Malone bug 55706 in python-uncertainities "python-uncertainities python2.3/2.4 breakage." [Untriaged,Confirmed]  http://launchpad.net/bugs/55706
<poningru> its a simple fix on postinst
<LaserJock> poningru: #ubuntu-bugs is the place to go
<poningru> no one helped there :(
<dmb> oh wait, i think thats because of the change to 6.06.1
<jeff_> Anyone here familiar with GObject and signals?
<jdub> jeff_: gimpnet is going to be a better place to start for that :)
<jeff_> gimpnet?
<ajmitch> afternoon jdub 
<jdub> jeff_: irc.gnome.org / irc.gimp.org
<jdub> yo ajmitch 
<jeff_> jdub: thanks
<BenC> anyone able to process linux-source-2.6.17 so l-r-m will get built?
<infinity> BenC: Oh, I suppose so. :)
<BenC> infinity: thank you great archive maintainer :)
<infinity> Hrm.
<infinity> I only see two arches in the NEW queue...
<infinity> Did the others get processed already?
<BenC> all 5 built successfully
<infinity> Yeah, and amd64/powerpc/i386 got rejected.  Checking why now.
<infinity> 20:34:14 INFO    Rejected:
<infinity> 20:34:14 INFO    Exception while accepting: 'Description'
<infinity> Awesome.
<infinity> Broken control file?
<BenC> is it one of the new udeb's?
<BenC> speakup and nic-firmware were added
<infinity> It's not that specific, sadly.
<BenC> do udeb's have to have a description?
<BenC> I'm pretty sure that's what it is
<infinity> Everything should, afaik.
<BenC> bah, kernel-wedge didn't complain and neither did dpkg-dev :P
<BenC> *sigh*, guess I'll reupload
<infinity> It could be soyuz being too anal, but I can't see a valid reason for a package NOT having a description either.
<jeff_> I'm getting a glib.h: no such file or directory error even though I have libgtk2.0-dev installed.
<BenC> infinity: does initramfs-tools not handle DSDT.aml's anymore?
<jdub> jeff_: you need the glib dev package installed to have the glib header file
<jdub> jeff_: channels on gimpnet might be more appropriate for hacking on gtk+/gnome stuff than this one
<jeff_> jdub: thanks, but it seems that I do have the glib dev packages installed
<BenC> jeff_: then likely you aren't using the right CFLAGS to find the headers...this is a question for #ubuntu though
<BenC> or what jdub suggested
<jeff_> ok
<infinity> BenC: If it doesn't, I'm not the one who broke it.
<infinity> BenC: I'll look when I get hom in an hour.
<bencer> hi all, where can i find a list of changes/updates for 6.06.1 ?
<lucas> is there something such as snapshots.debian.net for ubuntu ?
<lucas> I'd need the Sources file from every day over a long period of time
<hunger_work> Is it possible to get an misdn updated? ISDN is still pretty popular in germany and misdn is version 0.0.0+cvs20041018-5.
<infinity> lucas: Since we switched to launchpad (early this year), everything's stored in launchpad, per version.
<lucas> yup, but then, t's not possible to get per-day Sources file :( (or I'd have to do a lot of data harvesting)
<mvo> hunger_work: that would be a whishlist bug for the kernel team I guess
<pitti> Good morning
<Nafallo> morning pitti, Hobbsee :-)
<Hobbsee> hi Nafallo, pitti 
<AlinuxOS> Good morning pitti ;)
<pitti> hey Nafallo 
<pitti> moin Hobbsee 
<pitti> AlinuxOS: hey, long time no see! how are you?
<AlinuxOS> pitti, Im fine thanks!Finished exams, now in Germany by my girlfriend :) (re-starting gnome translation)
<pitti> cool
<AlinuxOS> pitti, and what about you ? :) alles in ordnung :D
<pitti> AlinuxOS: ja, prima!
<AlinuxOS> pitti, great!
<Hobbsee> hi sabdfl 
<pitti> moin sabdfl
<Fujitsu> Good evening, sabdfl.
<Hobbsee> pitti: hey where's the duncecap?  i think i need to wear it for a while.
* pitti hands Hobbsee the brown paperbag and the cluebat
<Hobbsee> hehe
<pitti> Hobbsee: heh, what's up?
<Hobbsee> pitti: er...cleared crap out of my home dir and backed up, adn used the backup to overwrite the original.  and then found that i'd missed a couple of folders.
<Hobbsee> like.... .thunderbird, .gnupg
<Fujitsu> Ouch!
<Hobbsee> and goodness knows what else i havent noticed that i'm missing yet.
<Fujitsu> I hope you had backups of your keys...
<hunger_work> Hobbsee: Outch! You do have backups?
* Hobbsee makes a mental note not to do system maintenence in the middle of a meeting.
<Hobbsee> hunger_work: of .gnupg/ yes, anything else, no
* Hobbsee lost all her pop3 email
<Fujitsu> Owy.
<Fujitsu> This is why I use IMAP on all my things :P
<Hobbsee> which is the @kubuntu.org/@ubuntu.com stuff too.
<Hobbsee> Fujitsu: gmail doesnt offer it
<pitti> Hobbsee: argh, you lost all your dotfiles/dotdirs?
* hunger_work comforts Hobbsee.
<Fujitsu> Hobbsee, neither does my ISP, but my server takes care of that.
<Hobbsee> pitti: got some of them.
<pitti> Hobbsee: you don't have a backup of your secret key?
<Hobbsee> pitti: yeah, iv'e got backups of all of .gnupg
<pitti> *phew* :)
<Hobbsee> heh, yeah
* Nafallo has backuppc :-)
<Fujitsu> Losing keys is... really irritating.
<Fujitsu> But moreso if they're actually used for something important, like yours :P
<Hobbsee> that was my first reponse - oh shit, here's my revoke.asc, but i dont remember seeing .gnupg....
<Hobbsee> Fujitsu: heh, true
<Nafallo> pitti: btw, are you familiar with backuppc's source or was it someone else?
<pitti> Nafallo: not really; I still use my ancient home-grown flexible automatic network backup system
* Hobbsee still has to figure out what her latest backup is, in terms of email.
<Nafallo> ah, oki. I have a small problem with it I should start hacking on...
<Hobbsee> but i know it's certainly not recent.
<Nafallo> Bug 54918
<Ubugtu> Malone bug 54918 in backuppc "DNS-lookup to AAAA (IPv6) doesn't seem to work" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/54918
<Hobbsee> aye, my computing work is gone.  good thing i didnt start the assignment yet
<Fujitsu> :(
* pitti hugs Hobbsee 
* Hobbsee hugs pitti in return
<pitti> Hobbsee: I guess that must happen to everyone until they install an automatic backup :/
<Hobbsee> pitti: could do that.
* TheMuso remembers loosing a 160GB drive in January, with a lot of stuff not backed up on it. Luckily I didn't loose anything too important, and still had my key.
<doko> pitti: still seeing the dh_strip failures with the new glibc
* pitti just finished apt-get upgrading
<pitti> doko: hm, works here now on amd64
<pitti> doko: objdump -h /usr/lib/*crt*.o|grep debuglink   ?
<pitti> doko: you have libc6-dev 2.4-1ubuntu8 now?
<Hobbsee> oh holy crap :(
* Hobbsee cries more
<pitti> doko: oh, wait - did you try this with a package which wasn't cleaned before building again?
* hunger_work comforts Hobbsee.
<doko> pitti: the latter ... will rebuild
<Hobbsee> hunger_work: i've lost all my saved passwords too :(
<pitti> doko: i. e. if you built the package with just dh_clean; debuild -nc, then you'll still get the bug
<pitti> doko: since the built executables will have debuglinks
<hunger_work> Hobbsee: I can recommend faubackup.
<pitti> doko: ok, *phew* :)
* Nafallo recommends backuppc to Hobbsee *
<Nafallo> ubuntu main and everything :-)
* Hobbsee recommends not playing with settings during a meeting :P
* Spads recommends rdiff-backup and possibly backupninja wrapper to all
<Spads> reverse incrementals > *
<siretart> any archive admins around?
<nags> seb128, http://people.freedesktop.org/~prashmohan/gedit/ also a README there :)
<seb128> nags: 
<seb128> mget: Accs chou: 403 Forbidden (gedit-data.xml)
<seb128> mget: Accs chou: 403 Forbidden (gedit-main.xml)    
<seb128> mget: Accs chou: 403 Forbidden (gedit.py) 
<seb128> mget: Accs chou: 403 Forbidden (gedit1.py) 
<seb128> mget: Accs chou: 403 Forbidden (gedit2.py) 
<seb128> mget: Accs chou: 403 Forbidden (gedit3.py) 
<seb128> mget: Accs chou: 403 Forbidden (gedit4-data.xml)
<nags> seb128, oops
<seb128> nags: could you fix that? :)
<nags> sure
<seb128> thank you
<nags> seb128, can you try downloading the same from here - http://people.freedesktop.org/~nagappan/gedit/
<seb128> nags: works fine
<nags> seb128, cool :)
<pitti> iwj: wrt ffox, what do you think about calling it '2.0~beta1' instead of '1.99+2.0beta1'? Personally I find the former a bit nicer to read
<seb128> pitti: is 2.0 > 2.0~beta1?
<pitti> iwj: (and we can use ~ since breezy or even earlier)
<pitti> seb128: yes
<seb128> ah ok
<pitti> seb128: that's the point of ~ :)
<seb128> yeah, I never used it :p
<pitti> you can read it as 'minus epsilon'
<pitti> seb128: ~blah is always smaller than the empty string (also handles the dash correctly)
<seb128> good to know ;)
<Fujitsu> Yeah.
* gnomefreak loves my ff2.0 ;)
<Hobbsee> gnomefreak: how stable is it?
<Hobbsee> ie, how many crashes do you get?
<gnomefreak> very compared to 3.0 :)
<gnomefreak> Hobbsee: none
<Hobbsee> gnomefreak: nice!
<Hobbsee> gnomefreak: when's it supposed to be released?
<gnomefreak> Hobbsee: do you have a package that is easy to merge that i can try to merge. (looking for one not likely to break)
<Hobbsee> gnomefreak: merges.ubuntu.com/universe.htm
<gnomefreak> spt-oct last i heard
<Hobbsee> could be anything on them
<Hobbsee> right
<gnomefreak> so it doesnt matter whos name is there?
<Hobbsee> gnomefreak: nope.  dont touch zope or beagle
<Hobbsee> hey cool, this email isnt *too* out of date.
<gnomefreak> k thank you
<gnomefreak> thanks got amarok beta last night ;)
<gnomefreak> does it matter if i grab new or updated?
<Hobbsee> gnomefreak: nope
<gnomefreak> ok here i go ;)
<gnomefreak> should this merge script ask me "are you sure you want to delete everything in /temp/
<Hobbsee> gnomefreak: yes
<gnomefreak> k got scared there ;)
<Hobbsee> gnomefreak: where are you getting the 2.0 packages from?  mozilla site, or from the post on the mailing list?
<gnomefreak> mozilla
<mjg59> Wow, this stuff /works/
<gnomefreak> hold on a sec ill get you the page
<Treenaks> mjg59: is it an Acer? :P
<mjg59> uswsusp
<gnomefreak> Hobbsee: http://www.mozilla.org/projects/bonecho/index-2.0b1.html
* mjg59 throws it at universe
<gnomefreak> brb while all these things are downloading
<Nafallo> mjg59: nice bughistory in debian atleast :-) (was "lucky"link at google ;-))
<thom> segfaulting for config problems is very classy
<Hobbsee> heh
<Hobbsee> indeed
<mjg59> I've junked all the config parsing code
<mjg59> In fact, I've junked most of the code full sotp
<gnomefreak> Hobbsee: can you look at this i get 4-5 lines that start with C is this a conflict or what does it mean http://paste.ubuntu-nl.org/20267
<StevenK> gnomefreak: The REPORT mentions them.
<Hobbsee> gnomefreak: yeah, it shows the debian and ubuntu changes with the >, <, and lets you sort out what you do and dont want
<gnomefreak> StevenK: im reading that now :(
<mjg59> Anyway, it's much faster
<gnomefreak> before i go nuts is it as easy to ust take the newest versions with patches and make a source.tar.gz and than continue? if not how do i make this work
<gnomefreak> s/ust/just
<Hobbsee> gnomefreak: cd into the directory MoM created for you, and then do the changes from there?
<gnomefreak> it created a dir?
<Hobbsee> should have done
<Hobbsee> you used grab-merge.sh didnt you?
<gnomefreak> yes
<gnomefreak> is this the one with help and debian nad pixmaps
<gnomefreak> its the only normal looking folder in ~/temp
<gnomefreak> the rest are tars or dsc
<tepsipakki> Kamion: maybe debian-install rebuild is all that is needed to pick up the new libc-udebs?
<Hobbsee> er, which are you getting?
<gnomefreak> gnomebaker
<Hobbsee> aah, right.
* Hobbsee thought you were using pixmaps for a second
<Hobbsee> you're looking in the dir where you ran the script?
<gnomefreak> yes
<Hobbsee> hmmm
<gnomefreak> im in where it left the changes and the report adn so on
<gnomefreak> the merge-genchanges and merge-buildpackage
<gnomefreak> im wondering if i should request a sync on gnomebaker than when its done re try?
<Hobbsee> gnomefreak: bug report, subject: [Edgy MoM]  Please sync foo version from debian sid, get a MOTU to ack it, and subscribe ubuntu-archive
<gnomefreak> the version would be the latest version i got in the download right?
<Hobbsee> you're wanting the latest debian, shown in the report
<gnomefreak> ok how do i get a motu to (ack) it. oh and what is ack?
<Hobbsee> ack = approve
<thom> acknowledge
<gnomefreak> ah
<Hobbsee> ask for someone to approve it in -motu, i expect
<gnomefreak> k
<Hobbsee> gnomefreak: or subscribe ubuntu-universe-contributors to it
<gnomefreak> k
<madduck> lucas: do you have the scripts for the comparison available somewhere? (re: blog)
<lucas> I'll put them somewhere
<sivang> hi all
<sivang> does anybody have a recommendation for a wirless gateway/router ? by reference to a brandname / mafctr. ?
<thom> netgear dg834
<sivang> thom: hi, what about the EDIMAXes and friends? ;-)
* sivang looks for something not so expansive.
<thom> sivang: what about them? the dg384 works beautifully
<sivang> thom: Do you have any expreince with those ? are they good as the netgear ?
<ogra> if you look for cheapo stuff, i had no bad experiences with belkin in that price class
<ogra> (dont ask for model names ... but they are generally cheap)
<sivang> ogra: cool, thanks :)
<sivang> ogra: and also much more spread here (as well as the edimaxs) then netgreas..
<lucas> madduck: http://www.lucas-nussbaum.net/bazaar/cmpver.rb
<iwj> pitti: I was going to ask whether ~ is allowed in Ubuntu version numbers.  Nice to have `yes' as an answer.
<Kaleo|work> rodarvus: do you think we can have another UVF for xserver-xorg-video-i810 ?
<iwj> pitti: But I won't do ff 2.0~beta unless Debian do, just to avoid aggro.
<pitti> iwj: we have used it for backports for quite a while now, and even Debian can use it now :)
<rodarvus> Kaleo|work, we had one yesterday :)
<rodarvus> version 1.6.4 is on the archives
<pitti> iwj: oh, right, if Debian has an orig.tar.gz, we should use that
<iwj> pitti: Right.
<rodarvus> I'm working on libdrm/mesa update, to support 3D on the new cards supported by this driver
<rodarvus> Kaleo|work, unless a 1.6.5 was released in the last 6 hours (time I've been sleeping), there is no need for another UVF of xserver-xorg-video-i810 ;)
<Kaleo|work> rodarvus: that's exactly the case
<Kaleo|work> ;)
<rodarvus> oh
<rodarvus> heh
<Kaleo|work> see bug ... hmmm
<rodarvus> Kaleo|work, yes, we can have UVF exceptions for them
<rodarvus> for this new version
<rodarvus> Kaleo|work, I was expecting a 1.6.5 soon, but not in 6 hours :)
<Kaleo|work> hehe
<Kaleo|work> yes rodarvus, bug 55907
<Ubugtu> Malone bug 55907 in xorg-server "Slow indirect rendering after update to version 1.6.4" [Unknown,Fix released]  http://launchpad.net/bugs/55907
<Kaleo|work> I linked to upstream
<Kaleo|work> before I went to bed ;)
* Hobbsee waves to rodarvus.  broken anything lately?
<rodarvus> yeah, i810 yesterday
<rodarvus> but was not my fault this time :)
<Hobbsee> rodarvus: crud, how's it broken?
<rodarvus> Hobbsee, upstream removed a few compatibility information from version 1.6.4 of the i810 driver
<rodarvus> restored on 1.6.5
<Hobbsee> rodarvus: right.  so X is gone till the new updates, or what?
<rodarvus> no
<Hobbsee> oh good
<rodarvus> its just slower for people with Intel boards, and only some of them
<Hobbsee> right
<rodarvus> i830 or newer, I think
<Hobbsee> right
<Nafallo> rodarvus: I didn't see any effects on i845GE :-)
<rodarvus> good
<rodarvus> anyhow, 1.6.5-0ubuntu1 was uploaded
<rodarvus> should be compiled an published in one or two hours, hopefully] 
<Nafallo> nice
<ajmitch> hi
<AlinuxOS> pitti, ping
<Kaleo|work> rodarvus: thanks so much !
<rodarvus> Kaleo|work, thank YOU for the bug triaging
<rodarvus> bug triaging is always helpful and appreciated :)
<pitti> AlinuxOS: pong
<webben> pitti: i just noticed your comment on https://launchpad.net/distros/ubuntu/+source/sudo/+bug/50797
<Ubugtu> Malone bug 50797 in sudo "sudo built with --with-secure-path is problematic" [Wishlist,Unconfirmed]  
<webben> pitti: rather than dropping --secure-path, why not restore the ability to change the secure path in /etc/sudoers ?
<webben> (i was actually working on this, i got the secure path working at the expense of causing some other bug, if you'd like to see a diff)
<webben> (but i don't think it's hard -- i don't know c++ and i got halfway there)
<pitti> webben: it's only C :)
<webben> pitti: see, i don't even know which language it is
<pitti> webben: sure, if you have a patch for this which doesn't cause regressions and does not require us to change configuration files, that's fine
<webben> pitti: and i still managed to hack support back in
<webben> pitti: the problem is my patch caused some other annoying bug, and i couldn't figure out why
<webben> pitti: and it required one deeply inefficient reuse of existing code
<pitti> ^ for reasons like this I'm very cautious about sudo patches :)
<webben> pitti: it really does need somebody who knows what they're doing i think
<webben> pitti: which isn't me (although i did try and will happily share the diff)
<webben> if anyone else is willing to take a look
<pitti> webben: maybe you can add what you have to the report, and describe the problem?
<pitti> then everyone can comment (including myself, but not now)
<webben> pitti: that's a good idea :), i'll have to reinstall my package to find out what the funny bug i caused was, but i'll try and attach it to the bug at some point today :)
<pitti> webben: great
<pitti> seb128__: does your net connection suck so hard today? :)
<seb128__> pitti: yeah, it's not that happy today :/
<AlinuxOS> seb128__, wifi? 
<seb128__> AlinuxOS: no, dsl line
<rodarvus> pitti, so, when bzr 0.9 is going to hit the buildds? :P
<pitti> rodarvus: don't ask me; LP turnaround has been ludicrously slow in the last days
<StevenK> The LP developers haven't been pedalling hard enough.
<rodarvus> that means you're going to upload it soon?
<pitti> rodarvus: erm, me?
<rodarvus> well, you were the last uploader of bzr :)
<pitti> meh, I just requested a sync
<rodarvus> haha
<pitti> OTOH, if you guys want me to, I'll package it
* pitti looks forward to getting 0.9, too
<doko> infinity, cprov: please requeue gcj-4.2 on powerpc and sparc (if the chroot problems are solved)
<pitti> traditionally, jbailey has packaed them, but he won't have much time nowadays
<nags> seb128__, ping
<pitti> rodarvus: ah, Debian already has 0.9rc1
<cprov> doko: we need to check with infinity if the chroot are fixed, them I can requeue if necessary
<pitti> http://bazaar-vcs.org/Performance/0.9 is quite impressive
<rodarvus> very impressiv
<rodarvus> impressive
<ge_ubuntu> does somebody see me here? I just registered
<pitti> ge_ubuntu: ack
<Fujitsu> ge_ubuntu, I can't see you.
<ge_ubuntu> I am trying to priv somebody, seems like i am not visible
<ge_ubuntu> or they dont see my priv emesg
<ge_ubuntu> mako: do you see me?
<iwj> Did we know that gnome-cups-add segfaults ?
<pitti> I saw it crashing sometimes, but never really reproducable
<iwj> Ah, well, it's nice and reproduceable for me.
* iwj writes a bug report.
<Treenaks> core files!
<pitti> apport!
<pitti> I'm checking every half an hour, hoping that this 2.6.17-6 kernel finally condescends to make it to archive.u.c
<infinity> doko: I can look at it, no worries.
<Hobbsee> yay, another kernel update.  and this time, I DONT HAVE TO COMPILE NDISWRAPPER FOR IT!!!!!
* Hobbsee cheers!
<sabdfl> Hobbsee: is ndsiwrapper included now?
<mjg59> ndiswrapper has been included for ages
<ajmitch> more that she has a new wifi card
<Hobbsee> sabdfl: it is, but i've always had trouble with it, never being able to make it run
* Hobbsee got a new card, yes :)
<Hobbsee> finally, some good news for the day.  or the week.
<doko> infinity: thanks
<sabdfl> Hobbsee: happy for you! however, we can't tell all our users "follow Hobbsee's example and go replace your hardware" :-)
<Hobbsee> sabdfl: haha....that is true
<Treenaks> sabdfl: sure we can :)
<thom> pfft, it seems quite reasonable to me
<Hobbsee> sabdfl: if you told them that, the next thing you'd be saying is "follow Hobbsee's example, and order everybody else around so that things actually get done"
<pitti> Hobbsee: well, it feels a bit like 'please adapt your problem to our solution', but then again, hardware sucks :)
<ajmitch> seems reasonable to replace hardware that has only proprietary binary drivers :)
<mjg59> sabdfl: There's someone in the London office today, right?
<pitti> ajmitch: full ack
<Hobbsee> pitti: well, the reason i havent tried looking into fixing it that much, is that it *obviously* works for other people, as there are no bug reports with my particular problem.  and i wasnt sure if it was ndiswrapper upstream, which had problems with marvell cards for a while anyway.
<Hobbsee> i figured it was probably user error, rather than application errorr.
<Hobbsee> -r
<mjg59> Don't we ship a driver for the Marvell chipset /anyway/ ?
<infinity> We do.  And it even kinda works.
<sabdfl> mjg59: couple of folks, yes
<Hobbsee> mjg59: we do?  how on *earth* do you get to it?
<mjg59> sabdfl: Ok, cool. I'll drop down and pick up the Toshibas I left behind, then
<mjg59> Hobbsee: modprobe mrv8k
* Hobbsee never found that in the documentation.  but i was using a freebsd driver, which worked better
<Hobbsee> mjg59: ahhh....
<mjg59> Hobbsee: But it ought to be autoloaded. What does lspci look like for your card?
<Hobbsee> mjg59: i'd have to *find* it.  it never autoloaded.  it's a netgear wg511v2 made in china card, marvell 8335 chipset
<mjg59> Hobbsee: Then it's probably a missing PCI ID. 
<mjg59> What's the lspci output?
<StevenK> Hobbsee: When you say find, do you mean, unearth from the hole you buried it in?
<Hobbsee> StevenK: no, i think it's at the bottom of my bag.
* Hobbsee goes to look.  brb
<mjg59> Hobbsee: Oh, sorry - I thought you meant find the driver!
<mjg59> Hobbsee: Sure, no rush
<Hobbsee_> mjg59: 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88w8335 [Libertas]  802.11b/g Wireless (rev 03)
<mjg59> Hobbsee_: Can you give lspci -s 02:00.0 -v -n ?
<mjg59> Just the first two lines of output
<Hobbsee_> 02:00.0 0200: 11ab:1faa (rev 03)
<Hobbsee_>         Subsystem: 1385:4e00
<Hobbsee_> mjg59: ^
<mjg59> Now, that's interesting
<mjg59>  {PCI_VENDOR_ID_MARVELL, 0x1faa, PCI_ANY_ID, PCI_ANY_ID, 0x6b00, 0x1385,\
<mjg59>  W8335},
<mjg59> I'd have expected that to get it to autoload
<Hobbsee_> mjg59: well, it certainly doesnt :P
* mjg59 wonders what the last two bits of hex in there are
<mjg59> I should really remember this stuff
<mjg59> Hobbsee_: Anyway, it'd be great if we could work through a debug session at some point
<mjg59> I have to head out now, though
<Hobbsee_> mjg59: you mean you dont know everything?  shame!
<Hobbsee_> mjg59: sure, ping me when you've got some time :)
<Hobbsee_> or email, or whatever.
<Hobbsee_> sudo modprobe mrv8k still doesnt show flashing lights on the card.
<Hobbsee_> oh well.  debug session would be cool :)
<Hobbsee> right...am i here now?
* pitti waves to Hobbsee 
<ajmitch> Hobbsee: somewhat
* Hobbsee waves back to pitti 
* Hobbsee attacks ajmitch with a rubber chicken
<ajmitch> kind of you
<Hobbsee> yeah :)
<Hobbsee> ajmitch: no, extremely kind of me would be to use my whip, surely?
<ajmitch> probably
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<Hobbsee> oh yeah, that's right :)
<Hobbsee> that did get done, it didnt just stay as an idea in my head.
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<Hobbsee> wb zul 
<zul> thanks
* Hobbsee wonders what she was going to do w.r.t the meeting this morning.  i'm sure i was going to do something.
<ajmitch> hi zul 
<zul> hey ajmitch 
<raphink> hi
<raphink> is there a packaged build server ?
<raphink> that gathers the scripts to deal with GPG signatures, building the packages for multiple architectures, building the repository
* HiddenWolf thinks apt-get instant-DIY-distro would be hand too
<HiddenWolf> handy, even
<raphink> what is that?
<HiddenWolf> raphink: a joke. :)
<raphink> ic
* raphink goes look at sbuild
<sivang> are the instructions over https://wiki.kubuntu.org/KernelCustomBuild  right for working with latest edgy?
<zul> sivang: yep
<sivang> zul: cool, thanks.
<sivang> zul: specifically, is there a certain way to distinguish between custom built kernel packages and the ones provided by the repository ?
<zul> sivang: if you use the follow the instructions in the wiki page it will create a custom kernel for you
<sivang> zul: yes, I realized that. Asking in advance, do you know if someone can use this instructions to create a custom kernel that will have pkg naming and versioning as the repo provided ones?
<zul> sivang: i believe so
* Hobbsee waves to sivang 
<sivang> zul: for https://wiki.ubuntu.com/SystemCleanUpTool , I need to find a good way to know which kernels on the system where manually built and installed, and which ones are provided by the repo
* sivang hugs Hobbsee 
<zul> sivang: thats a tough one that im not sure about sorry
<thom> hrm, that's a problem
<Keybuk> what is?
<thom> the bug on sudo i'm just about to report
<thom> (i just ran ntpdate on a machine, sudo now thinks the timestamp is too far in the future, and neither -k or -K will remove the timestamp)
<thom> i'm open to suggestions short of rebooting :-)
<Keybuk> heh, yeah, sudo hates it when you do that
<Keybuk> there's a stamp file you can touch
<Keybuk> I think
* Keybuk made it do that once
<thom> oh fun, and the sudo.ws bugzilla is bust
<thom> Keybuk: hrm, i can't see any reference to something like that in the docs
<infinity> thom: Only root can read the docs.  Try "sudo sudo --help" :P
<ogra> infinity, oh, was sudo patched to accept -- options now ? 
<thom> infinity: :P lamer
<infinity> ogra: It was a joke. :)
<ogra> infinity, i *know* :P
<pitti> well, --help works :)
<infinity> pitti: Only in the sense that it tell you that it doesn't.
<infinity> s/tell/tells/
<pitti> (if you ignore the 'please use single character options' complaint)
<thom> yes, it's precisely as useful as -h (aka, chocolate fireguard)
<Keybuk> it could be worse, it could be designed by a launchpad developer
<Keybuk> --force --force-harder --FORCE --FORCE-FORCE-FORCE
<pitti> Keybuk: is it that bad? :/
<infinity> LP's options are very.. Verbose.. And almost always ALL required.
<infinity> Other than that, it's great.
<pitti> I guess you guys have a fine collection of aliases by now :)
<thom> i might add a FASTER_PUSSYCAT_KILL_KILL_KILL env var to sudo which'll make it kill everything
<ogra> apt-get install slay ?
<ogra> sudo slay root ?
<ogra> :)
<thom> ogra: I don't have sudo access, see above
<ogra> ah, right
<Keybuk> pitti: I tend to dislike multiple "force" options which only differ in case, but have different effects
<pitti> urgh
<Seveas> --force --dark_side_of_the_force
<pitti> "Dark the other side is."
<pitti> "Be quiet, Yoda, and eat your toast!"
<ogra> *g*
<siretart> Keybuk: Do you want to sync the new wpasupplicant from unstable, since we now have madwifi-ng in edgy?
<Keybuk> siretart: already done it
<siretart> ok.
<Hobbsee> Keybuk: thanks a lot!
<Hobbsee> w.r.t. endless lots of syncs.
<Hobbsee> the count has finally gotten high enough now?  i poked over kdmtheme stuff last night, so feel free to do that one too.
<bddebian> Howdy
<bddebian> Keybuk: What does [debian multimedia]  imply?
<Keybuk> bddebian: that it's a sync from debian multimedia?
<bddebian> Keybuk: Oh, you dropped the sync part :-)
<bddebian> Thx btw
<Keybuk> Hobbsee: how do you mean?
<gnomefreak> siretart: i borrowed one of your merges to use for learning but it needs to be synced (just letting you knwo so you dont freak out)
<Keybuk> bddebian: *shrug* it's pretty obvious to us that it's a sync request <g>
<Hobbsee> Keybuk: how do you mean to which bit?
<bddebian> Keybuk: Well I'm kinda slow sometimes :-)
<Keybuk> Hobbsee: "do that one"
<Hobbsee> Keybuk: ah, sorry.  i'll find it for you
* Hobbsee curses the fact that she lost most of her email.  again.
<siretart> gnomefreak: sure, go ahead!
<Keybuk> Hobbsee: you want kdetheme sync'd?
<gnomefreak> Hobbsee: you want mine ;)
<gnomefreak> siretart: ty but looks like it will be a week or so i got a out of office reply
<Hobbsee> Keybuk: i want whatever we finally decided at the end of that bug report synced.
<Hobbsee> gnomefreak: heh, no.
<Hobbsee> Keybuk: hmmm.  looks like kcontrol-kdmtheme/kdmtheme has already been fixed, i cant see the bug for it anymore.  we want to sync the debian version, and axe ubuntu's, anyway.
<Hobbsee> Keybuk: axe kcontrol-kdmtheme, sync kdmtheme.  that's it.  :)
<mako> ge_ubuntu: i see you
<pitti> is it just my current incarnation of archive.ubuntu.com that doesn't want to get linux-source-2.6.17_2.6.17-6.17 or everyone's? (the binaries were built > 8 hours ago)
<pitti> oh, wait, they could hang in NEW
<pitti> Keybuk: are the 2.6.17-6.17 kernel binaries in NEW?
<ajmitch> I think they were poked through NEW awhile ago
<infinity> pitti: No, they were rejected because BenC messed up.
<infinity> pitti: He was meant to upload a fixed source, but hasn't yet.
<pitti> ah, ok
<infinity> Keybuk: Ignore pitti, I am. :P
<bddebian> Heya infinity
* ogra wonders why we have fuse in main but fuse-utils not
<Keybuk> infinity: I usually do
<Keybuk> ;)
* Keybuk wonders what mvo's recent obsession is with all things thai ... "I YOUR WIFE!"
<bddebian> HuH/
<bddebian> Err Huh?
* Keybuk sits bddebian down in front of Priscilla - Queen of the Desert
<bddebian> Seen it
<infinity> Poeple outside of Australia have seen this film?
<infinity> Intentionally?
<zul> yes intentionally
<infinity> mvo: Correct me if I'm wrong, but isn't update-notifier supposed to notify me of updates?
<thom> infinity: that's a bold assumption
<infinity> mvo: Oh, never mind, I didn't wait long enough for it to think.  Stupid thing.
* mvo vagualy remebers priscilla
<mvo> infinity: get a faster machine
<infinity> mvo: Thpt.
* mvo hugs infinity (carefully)
<Keybuk> doko: ping
<doko> Keybuk: pong
<Keybuk> doko: bug #54916, colour me confused
<Ubugtu> Malone bug 54916 in Ubuntu "removal requests for dapper-proposed" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54916
<Keybuk> what exactly is the problem there?
<Keybuk> you don't want openoffice.org in dapper-proposed for amd64?
<Keybuk> but it's fine to leave it in for i386, powerpc and sparc?
<doko> no, just not openoffice.org-evolution and openoffice.org-dev
<Keybuk> why just those two?
<Keybuk> that makes NO sense
<doko> these were built from the OOo source, not the OOo-amd64 source. it DOES make sense
<rodarvus> infinity, ping
<Keybuk> openoffice.org-gtk-gnome | 2.0.3-3dapper3 | dapper-proposed | amd64
<Keybuk> openoffice.org | 2.0.3-4dapper2-1 | dapper-proposed | amd64
<Keybuk> what about those two?
<rodarvus> it seems we are having chroot problems on powerpc -> https://launchpad.net/+builds/+build/236139
<doko> openoffice.org is ok, built from ooo-amd64, yes openoffice.org-gtk-gnome should be removed as well, there should be an binary indep package instead
<Keybuk> ah, that makes more sense then
<Keybuk> ttf-opensymbol | 2.0.3-4dapper2 | dapper-proposed | all
<Keybuk> libmythes-dev | 2.0.3-4dapper2 | dapper-proposed | amd64
<Keybuk> what about those two?
<doko> they are ok
<Keybuk> ok
<doko> all *4dapper2* packages should be ok
<Keybuk> *nods*
<Keybuk> it was that you didn't ask for gtk-gnome to be removed that was confusing
<Keybuk> ummmmmm
<infinity> rodarvus: pong.
<infinity> rodarvus: If you're pinging about LRM, I can't really do anything about getting a fixed one in until BenC uploads a linux-source that doesn't suck.
<lucas> Keybuk: is someone monitoring debian removals on a regular basis ? the few packages I asked you to remove were removed from debian a long time ago
<Keybuk> lucas: no, nobody monitors those
<infinity> elmo used to, in the bad old days.
<Keybuk> doko: ya know, I'm not sure I can do this
<infinity> We don't seem to have a procedure for that now.
<rodarvus> infinity, no, I'm not pinging about LRM :)
<rodarvus> <rodarvus> it seems we are having chroot problems on powerpc -> https://launchpad.net/+builds/+build/236139
<doko> Keybuk: open a lp bug report ;)
<infinity> rodarvus: That's not a chroot problem, it's an archive problem... Which is even worse.
* infinity would love to know how we're managing to get archive inconsistencies on drescher now.
<mdke> jdub: ping
<Gloubiboulga> seb128, ping
<Gloubiboulga> mvo, ping as well :)
<mvo> hello Gloubiboulga
<Gloubiboulga> hi mvo, I've seen that you've merged gksu
<mvo> Gloubiboulga: yes
<Gloubiboulga> the package now builds a nautilus extension which brings all the gnome libs
<Gloubiboulga> and it's a little problem for xubuntu...
<mvo> Gloubiboulga: right, I guess that needs to be split out
<Gloubiboulga> mvo, ok, I can take care of this if you want
<mvo> Gloubiboulga: yes please!
<mvo> Gloubiboulga: let me know if the upload needs sponsoring 
<Gloubiboulga> mvo, not a sponsoring, but a review yes, I've never touch nautilus packages yet :)
<rouzic> Hi all
<doko> $ sudo debootstrap dapper /home/chroot/d2
<doko> I: Retrieving Packages
<doko> I: Retrieving Packages
<doko> I: Retrieving Packages
<doko> I: Resolving dependencies of required packages...
<doko> I: Resolving dependencies of base packages...
<doko> W: Failure trying to run: chroot /home/chroot/d2 mount -t proc proc /proc
<doko> why?
<doko> that's ia64
<kylem> doko, don't you need to specify ports.ubuntu.com as the mirror?
<Spads> proc proc proc
<doko> kylem: yes, I remember ... but the error message ... is ... interesting ...
<kylem> yeah, i saw that too while rebuilding some chroots. :\
<bddebian> w00t, Keybuk r0x!!
<Toadstool> Keybuk: about the gnomebaker sync, the only remaining difference with the current debian version is a tiny modification for the desktop file which is not worth a -XubuntuY version to my mind
<Toadstool> hey bddebian 
<bddebian> Hi Toadstool
<Keybuk> Toadstool: what's the modification?
<Keybuk> bddebian: for?
<Toadstool> Keybuk: Icon=/full/path -> Icon=icon.png, both validate with desktop-file-validate
<bddebian> Keybuk: Everything :-)
<Keybuk> damn, emacs really hates __attribute__ :-/
* infinity grumps, as he notices that full-screen mplayer no longer seems to cover the GNOME panel.
<Spads> heh, feh fullscreen has the same problem
<infinity> Now, do I blame gnome-panel, metacity, or mplayer?
<Keybuk> infinity: seb
<Keybuk> I find it more gratifying to blame him than the software
<Amaranth> infinity: metacity's fullscreen code got some changes recently, i guess it's to blame
<infinity> Amaranth: Well, poo.  Any clues where to start looking?
<Amaranth> xprop | grep _NET_WM_STATE
<Amaranth> '[if]  it shows "_NET_WM_STATE_FULLSCREEN" as one of the states and then focus that window and observe it to not be on top of all other windows (including panels), then it sounds like you've discovered a bug in Metacity.  If so, I would be interested to learn how to reproduce so that I can fix it.'
<Amaranth> Basically they did some things to fix it for WINE and it must have broken other apps.
* infinity raises his brow at the fifrefox 2.0 beta in edgy.
* pygi thinks we should go for "firefox 3.0" :)
<infinity> Amaranth: I assume this is going to require another machine and an SSH session.  Which means getting up off the couch.
<Amaranth> hmm
<Amaranth> no, you have to click on the window after running that to make it spit out anything
<Amaranth> only the panels go on top of it, nothing else can?
<Amaranth> http://cvs.gnome.org/viewcvs/metacity/src/window.c?r1=1.442&r2=1.443 <--what changed
<Amaranth> btw, totem and vlc still work just fine ;)
<kozz> is there a page somewhere describing all packages that are included on the cd/dvd?
<Amaranth> infinity: Can you try reverting that change and seeing if you still have problems?
<kozz> who decides which packges are to be included?
<LaserJock> kozz: that is done by seeds
<kozz> seeds?
<infinity> Amaranth: Yeah, just the top panel, in fact.
<Amaranth> anyone on the ubuntu-core-dev launchpad team can change the seeds, apparently
<LaserJock> kozz: https://wiki.ubuntu.com/SeedManagement
<infinity> Amaranth: But I'm far too drunk to debug anything right now.
<Amaranth> infinity: alright :)
<Amaranth> infinity: Just use totem then. ;)
<infinity> Amaranth: Will you be around on the weekend?  I may want to debug this when sober.
<Amaranth> I should be around part of the time.
<infinity> Amaranth: Kay, cool.  I'll ping you later.  I'm GNOME ignorant, and preder to stay that way.
<kozz> LaserJock: thanks for pointing me in the right direction
<infinity> prefer too.
<LaserJock> kozz: np
<kagou> hi
<ge_ubuntu> hi
<rouzic> Hi kagou :)
<KhanReaper> I am trying to write a package that provides a wrapper for the /usr/bin/firefox script. I placed a dpkg-divert in the new package's preinst script, but dpkg complains that the replacement firefox script already exists in the firefox package. What can I do to overcome this? The dpkg-divert call works successfully, but why is this happening? Is there any way around this?
<KhanReaper> By the way, there is a very good reason that this is being handled via a Debian package.
<Chipzz> KhanReaper: why?
<sivang> Keybuk: You use emacs ?
<Keybuk> sivang: yes
<sivang> Keybuk: did you notice that was a font change in one of the previous edgy updates? Do you know how it can be put back to the normal default one? or is this smaller font the new default?
<KhanReaper> It would be waste of time to discuss it here, as the reasons are very exhaustive. Simply put, there are some problems with a plugin that Firefox uses, and it needs some special modifications to accommodate this special plugin. This is used on about 100+ workstations, and the configurations for these machines need to be kept in-sync via a local Debian package repository. As I said, this is a waste of time to discuss.
<sladen> sivang: fixed font size change?
<KhanReaper> Shouldn't a diversion, mark that file's name as free for when a new package is installed?
<kagou> who can i ask for doing a sync for new debian blender package ?
<Keybuk> sivang: "font change" ?
* Keybuk uses emacs in gnome terminal
<sivang> Keybuk: ah, you're not using Xemacs then.
<Keybuk> right
<sivang> Keybuk: I'll try that as well :-)
<sladen> sivang: I'm not clear what you're doing, but could it be related to which aliases file is used?  bug #54809
<Ubugtu> Malone bug 54809 in xfonts-utils "X server cannot find default font `fixed'" [Untriaged,Confirmed]  http://launchpad.net/bugs/54809
* sivang checks
<Kaleo|work> rodarvus: hmmm
<Kaleo|work> I still have problems with i810
<rodarvus> Kaleo|work, latest i810 is not published yet
<rodarvus> (though it is uploaded)
<Kaleo|work> ok
<Kaleo|work> sorry I was reading that in your comment
<sivang> sladen: my server doesn't crash though
<sladen> sivang: ignore the bug report itself.  look at the notes about the fonts.aliases file and which is used
<rodarvus> sladen, nice, thanks for tracing the root of the fonts issue
<sladen> sivang: one thing I did notice is that I had differently sized fonts afterwards
<rodarvus> sladen, do you want to update xfonts-base?
<sladen> rodarvus: what's your thoughts, _just_ fixing xfonts-base shoulds fix it for all intents and purposes---you happy if I just do a fresh upload of that?
<rodarvus> sure, seems just fine for me
<rodarvus> maybe other font packages might need it too
<rodarvus> alternatively, have a versioned depends on xorg could do it.
<sladen> rodarvus: yeah, but they won't actually *break* the X server
* sivang dist-upgrades and then will try sladen's instructions on the bug report.
<sladen> rodarvus: should it actually be pre-depends?
<rodarvus> it should, but debian policy really really hates pre-depends
<nags> seb128, hi
<nags> seb128, we got some review comments regarding gedit scripts from gedit authors
<seb128> re
<seb128> ah, nice comments?
<nags> seb128, we are incorporating them
<nags> seb128, yes :)
<seb128> cool
<seb128> I tried to make it working
<nags> seb128, we would like to hear from you too :)
<seb128> but it does nothing on my box
<nags> seb128, oops
<seb128> maybe I'm not using it rightly
<sivang> sladen: I also get Warning: locale not supported by Xlib, locale set to C
<sivang> sladen: btw
<nags> seb128, infact all those were developed in Ubuntu box
<seb128> I don't have ldtp installed to my system, I run if from the srcdir, I'm not sure if that's right
<nags> seb128, enabled accessibility ?
<seb128> no
<nags> seb128, ldtp has to be installed and accessibility should be enabled
<seb128> it needs to be installed? 
<seb128> or from the srcdir is fine?
<sladen> sivang: sounds like encodings isn't being setup ---could be related
<nags> seb128, installed
<nags> G0SUB, hi
<sladen> rodarvus: in the spirit of blows-your-X-server-away I've uploaded it with and I'll wait for the complaints to come in
<rodarvus> :)
<rodarvus> sladen, btw, I have uploaded new libdrm, mesa, xserver-xorg and xserver-xorg-video-i810 this morning, you might be intersted on it
<rodarvus> (since you seem to care about mesa and i810)
<seb128> nags: is there a ldtp package somewhere?
<nags> seb128, yes, based on cr3 advice Casanova created it
<nags> Casanova, Ubuntu LDTP deb
<Casanova> nags: the deb?
<Casanova> ah ok :)
<nags> Casanova, yes
<nags> Casanova, link ?
<seb128> nags: http://download.freedesktop.org/ldtp/0.x/0.5.x/ldtp_0.5.0-2_i386.deb ?
<seb128> I've just found that with google
<Casanova> http://people.freedesktop.org/~prashmohan/latest/
<Casanova> seb128: the source package is in the above link :)
<seb128> ok, thank you
<seb128> I tried to build from the ldtp src dir I have but the deb had no content out of the documentation of the package
<iwj> Oh, how amusing, this thing labelled as `breezy' in my grub is in fact a half-completed install.  I've just booted it and it's `Installing packages' :-).
<nags> Casanova, for running addict3d / narasim_7 scripts, do we need to enable accessibility explicitly ?
<nags> seb128, ah okay
<Casanova> seb128: i dont get you
<Casanova> nags: explicitly in the sense?
<seb128> Casanova: I runned debuild to http://people.freedesktop.org/~prashmohan/latest/ldtp-0.5.0/ copied on my disk
<seb128> Casanova: and the .deb only had /usr/share/doc/ldtp, no binary
<Casanova> oops
<Casanova> seb128: i use dpkg-buildpackage -rfakeroot
<seb128> should be the same
<Casanova> i guess
<seb128> anyway just installed the deb from where you pointed
<nags> Casanova, we set from gnome-control-center right ? instead just launchapp ('gedit', 1) ?
<Casanova> i am building gnome now... i will try running debuild on it after that
<Casanova> nags: the scripts start gedit using launchapp
<Casanova> nags: yes
<nags> Casanova, cool
<nags> Casanova, also narasim_7 here ?
<nags> Casanova, maybe he can directly get comments from seb128 :)
<seb128> bah, still doing nothing
<Casanova> seb128: doing nothing in the sense?
<seb128> I run "ldtprunner gedit-main.xml" but it stays on the command doing nothing
<nags> seb128, Casanova did jhbuild + LDTP integration and Evolution automation as part of Google SoC
<seb128> Casanova: like no gedit opened, no message, no action, no CPU used, ... :)
<nags> seb128, narasim_7 who has developed those 70 diff scenarios for gedit with his friend addict3d
<Casanova> oh oh
<Casanova> this is bad
<seb128> nags: ah, ok :)
<narasim_7> seb128: hai
<seb128> hey narasim_7
<Casanova> nags: same issue frederic was facing?
<seb128> but I don't know how to use that thing
<seb128> should I opened gedit first?
<Casanova> seb128: could why try 1 thing?
<Casanova> seb128: no
<seb128> or is that supposed to be done by the script?
<seb128> Casanova: sure
<Casanova> seb128: could you start `ldtp' in a terminal and run `ldtprunner gedit-main.xml' in another terminal?
<nags> Casanova, ah okay
<Casanova> seb128: before that
<Casanova> seb128: `export LDTP_DEBUG=1' in both terminals
<nags> Casanova, maybe LDTP_DEBUG=2
<nags> it will give more verbose info
<narasim_7> gnome-accessibility
<Casanova> narasim_7: ?
<narasim_7> shuldnt that be exported that first
<Casanova> narasim_7: that shouldnt be necessary
<Casanova> if accessibility is enabled
<seb128> http://paste.ubuntu-nl.org/20310
<seb128> that's the log
<seb128> from the ldtprunner 
<narasim_7> Casanova: ohh.. okie
<seb128> ldtp has nothing printed
<Casanova> seb128: did you export the variable?
<Casanova> on the ldtp terminal too?
<seb128> yep
<seb128> but =1
<nags> seb128, try =2
<seb128> ah
<Casanova> nags: hmm connection wasnt made even?
<seb128> there we go :)
<nags> Casanova, actually =1 gives min info, that too in client only
<Casanova> ah
<nags> Casanova, and =2 gives verbose info
<seb128> Packet received from client is not valid
<Casanova> seb128: you started `ldtp' before running `ldtprunner' right?
<nags> Casanova, recent change, based on dobey's request
<seb128> Cliend disconnected
<seb128> Casanova: yep
<Casanova> seb128: is accessibility enabled?
<seb128> how do I check?
<seb128> I've clicked on the box for that and restarted the session
<seb128> so it should
<Casanova> seb128: System --> Preferences --> Assistive Technology Support
<seb128> just the support option
<seb128> no app
<narasim_7> seb128: perhaps some more servers of ldtp are running?
<Casanova> seb128: thats ok
<Casanova> seb128: killall -KILL ldtp
<Casanova> seb128: http://paste.ubuntu-nl.org/20311
<seb128> Casanova: client connection: accepted
<seb128> Locale languages: fr_FR.UTF-8
<Casanova> ah :)
<Casanova> close python
<Casanova> and run the script now?
<seb128> when I close I get the
<seb128> "Packet received from client is not valid"
<Casanova> thats ok
<nags> narasim_7, Casanova, seb128, we have some issues in localized version as of now...
<seb128> lot and lot of log to the ldtp but nothing at screen
<nags> prem is working on that
<nags> seb128, that will be fixed in our next release
<seb128> do I need some a11y app?
<nags> seb128, hmmm
<nags> seb128, no
<nags> seb128, you need to try them in default locale - English
<nags> then things will work fine
<nags> seb128, in GNOME metacity, if I want to bring a window to foreground, can we do something ? I mean write a small program etc ? We tried with gok code, but we were not able to succeed
<nags> Casanova, narasim_7, maybe we need to update the doc, that it can be run in English lang only as of now ?
<Casanova> i knew only now ;)
<seb128> nags: right, that works now ;)
<narasim_7> nags: Srini said he would take up updating the doc once gedit was over
<narasim_7> nags: i promised him my help
<nags> narasim_7, cool
<nags> seb128, wow !
<nags> narasim_7, you are going to get good review comments from seb128 :)
<seb128> nags: I'm not good with metacity focus stealing prevention things, /j #bugs on GIMPnet and ask to elijah, he's the metacity maintainer and reply to questions in a detailled and friendly way usually
<narasim_7> nags: :-)
<seb128> ok, guy, thank you for giving a hand to set that up ;)
<nags> seb128, ya, but these days could not get in touch with him
<seb128> I've to go for dinner now but I'll play with that and let you know how it works for me
<nags> seb128, wow !
<nags> seb128, sure
<seb128> nags: he spoke 20min ago on #bugs so he might be around ;)
<seb128> nags: better to ask what you have to ask than just "ping" though, some people tend to not reply to ping without context when they are busy because they don't know if they are interested to start a discussion on an unknow topic ;)
<nags> seb128, let me check now
<seb128> anyway I've to run
<seb128> thank you again
<seb128> bbl
<nags> seb128, ya right :)
<Royal-team> 190 personnes et personne parle ?
<Royal-team> Mdr
<BenC> linux-source-2.6.17: edgy ia64   Chroot problem
<BenC> in case anyone wants to know
<infinity> BenC: Already fixed.
<bluefoxicy> So if i wanted to suggest something really dumb
<bluefoxicy> like say
<bluefoxicy> Allowing ShipIt users to request CD-RWs instead of real pressed CDs
<bluefoxicy> where would I suggest this?
<bluefoxicy> (Ubuntu 6.06.1?  What am I supposed to order new CDs or something?)
<Keybuk> I'm not entirely sure that is possible ... the CDs are pressed by a CD distribution plant
<mjr> not gonna happen
<Keybuk> I doubt they can even do CD-RW
<bddebian> How about asking in #IwannauseGentoo
<Keybuk> and you can get all of 6.06.1 from the archive as usual
<Surak> I noticed that cdimage.ubuntu.com has only 6.06.1 DVD images.
<Chipzz> I know this is most likely more an upstream issue than an ubuntu issue
<Chipzz> but is there a reason why the network applet in gnome-system-tools doesn't show my profiles anymore?
<Chipzz> are we going to switch to the network-manager applet for edgy?
<seb128> Casanova: is the ldtp script supposed to give any sort of output or just use gedit?
<Casanova> seb128: in the gedit-run.xml file there is a tag called <logfile>
<Casanova> the output is an xml file specified within that tag
<seb128> ah, ok
<seb128> is there some documentation on ldtp or some sort of faq?
<Casanova> seb128: http://ldtp.freedesktop.org/user-doc/index.html
<Casanova> seb128: http://ldtp.freedesktop.org/wiki/FAQ
<seb128> thank you
<Casanova> seb128: http://ldtp.freedesktop.org/wiki/LDTPEditor/GeneratingLDTPDataXMLfileformat http://ldtp.freedesktop.org/wiki/LDTPEditor/GeneratingldtprunnerXMLfileformat
* Casanova searches for more urls to dump to seb128 ;)
<seb128> that should be enough, thank you :)
<Casanova> hehe
<pygi> sivang, poke
<jdahlin> doko: ping
<doko> jdahlin: pong
<jdahlin> doko: what's the primary use case for linking python dynamically instead of statically?
<jdahlin> this number 6% worries me a little bit
<doko> jdahlin: ask jamesh :-)
<jdahlin> doko: then I probably know what it is
<jdahlin> being able to use a library from python which has python plugins
<doko> yeah, you need to avoid two copies of the interpreter, which can happen, if things get dynamically loaded
<jdahlin> to avoid starting two interpreters
<doko> exactly
<jdahlin> however, it's possible to avoid that by dlopening libpython
<jdahlin> which is what nautilus-python does
<jdahlin> gstreamer and gnome-vfs are two real uses cases otherwise
<doko> or building python as a PIE, which I didn't try yet
<jdahlin> both of them have python bindings and python plugin support
* jdahlin pokes jamesh 
<jamesh> jdahlin: if you have two pieces of code that have linked Python statically (or one static + one dynamic), there are two copies of the Python interpreter
<jamesh> building python as a PIE is a way to make /usr/bin/python the same as /usr/lib/pythonX.Y.so
<jdahlin> jamesh: right, but are there any important libraries or program that does that apart from /usr/bin/python ?
<jdahlin> and should you not avoid linking to libpython.so directly just because of that?
<jdahlin> [for extension modules] 
<jamesh> jdahlin: ideally everything would link to libpython.so (including python)
<jamesh> although there is a performance penalty
<jdahlin> jamesh: ideally because it's good practice or because it creates real world problems?
<jamesh> jdahlin: because it avoids the problem all together.  If everything links to a dynamic libpython, then there is only one copy of the interpreter
<jdahlin> jamesh: right, but it is possible to workaround it
<jamesh> really?
<jdahlin> yeah
<jdahlin> so, in the case of gst-python
<jdahlin> which can be loaded by /usr/bin/python and by gstpythonloader through a normal C application
<jdahlin> in the case of /usr/bin/python you can access the symbols directly
<jdahlin> for the gst plugin you can check if it's available dlsym(dlopen(NULL), "Py_None")
<jdahlin> and if it's not just dlopen(/usr/lib/libpython.so)
<jamesh> ugly hack ...
<jdahlin> I found it quite neat ;-)
<jdahlin> but the use case is limited, I don't think any real applications has actually run into this
<jamesh> what if another copy of the interpreter gets loaded without RTLD_GLOBAL?
<jamesh> your solution works in a limited number of situations (arguably a useful number of situations though)
<jdahlin> wouldn't that be a bug?
<jdahlin> in the specific library or application
<jamesh> it is a bug that can occur because there is a static libpython :)
<jdahlin> true
<jdahlin> but why would anyone do that anyway?
<jamesh> jdahlin: people do all kinds of crazy shit.
<jamesh> jdahlin: anyway, I need to pack up for my flight tomorrow
<jdahlin> jamesh: good luck with the laptop
<jamesh> thanks
#ubuntu-devel 2006-08-12
<sabdfl> how do i update an X authentication key?
<sabdfl> I get an "Invalid MIT-MAGIC-COOKIE-1 key" error trying to run an X app from the command line
<jcole> i rebuilt the linux-source-2.6.15 package with all kernels w/skipabi=false... i forgot what i'm to do to the linux-restricted-modules-2.6.15 package when building... do i need to change a version somewhere?
<keescook> sabdfl: did you change your hostname?  the "xauth" tool will let you examine your current cookies
<sabdfl> thanks keescook, that's likely to be it
<Hobbsee> hi all
<bddebian> Howdy
<desrt> zul_; word up.
<desrt> zul_; i got xen installed & all.  but when i fire it up i get insta-reboot
<HrdwrBoB> desrt: define 'fire up'
<desrt> load xen-i386.gz from grub and pass it a kernel
<desrt> i get a bunch of normal-looking kernel bootup messages, but prefixed with (XEN) then somewhere in the middle of all of that the machine just reboots
<Keybuk> 20088 pts/3    S+     0:00  |   \_ ./init
<Keybuk> 20089 ?        Ss     0:00  |       \_ /bin/sh -e /dev/fd/3
<Keybuk> 20094 ?        R      0:00  |           \_ ps fax
<Keybuk> ... still can't decide whether that's "sick" or not ... ;)
<bddebian> Yes :-)
<Keybuk> the alternatives are
<Keybuk> a) passing it all on stdin (could break things)
<Keybuk> b) passing it all using -c
<bddebian> Ah
<Keybuk> right, bed
<lasindi> Hi all, this might not be the best channel to ask this, but are there any plans to develop a technology in Ubuntu (or any other Linux distros) equivalent to Time Machine feature that Apple will be including in the next version of OS X?
<Burgundavia> lasindi: there is backup technology being worked on
<lasindi> Burgundavia: do you know what it is called?
<Amaranth> dirvish?
<Amaranth> it's older than time machine
<Burgundavia> Amaranth: true, but I was thinking of sivang's thingy
<Amaranth> sivang: link?
<Amaranth> err
<Amaranth> that was supposed to be a ? :P
<ajmitch> Burgundavia: sivang's work isn't equivalent, afaik
<lasindi> Amaranth: I don't know much about Dirvish, but from their webpage, it looks like they make complete disk image backups. Time Machine looks a bit more like Subversion for your entire filesystem. Is there a project like that?
<Amaranth> hmm
<Amaranth> all i can say for sure is that it's not possible right now
<Amaranth> inotify has a watch limit
<lasindi> What is a watch limit?
<Amaranth> this really isn't the right channel for this
<Amaranth> limit to the number of things that can be watched for changes
<lasindi> Which channel would be better?
<Amaranth> i don't think one exists
<lasindi> #inotify doesn't look very popular :-)
<Amaranth> although dirvish could probably be tweaked to do the job, it just needs a GUI
<lasindi> Sorry to ask again about inotify, but why would the watch limit be a problem? Couldn't it just "commit" a change in a folder when it happens, just like Beagle can reindex changes as soon as they happen?
<TheMuso> c
<TheMuso> crap kvm
<Amaranth> lasindi: beagle is the problem
<Amaranth> lasindi: beagle steals all the inotify watches
* bluefoxicy blinks at commercial
<lasindi> Ah
<lasindi> Amaranth: is there a reason why splitting the watches between Beagle and the backup system would be a problem?
<Amaranth> there aren't enough of them
<lasindi> So, presuming that Apple faces the same problem, is it not possible to just increase the number of watches?
<Amaranth> lasindi: linus won't do it so a tool depending on that couldn't happen
<Amaranth> lasindi: you'd have to turn beagle into an indexer/backup system
<lasindi> Why is Linus against it?
<Amaranth> *shrug*
<Amaranth> you're looking at this the wrong way though
<Amaranth> the technical part of making the backups isn't really hard
<lasindi> So, you're saying the GUI front-end would be the bigger challenge?
<Amaranth> well, probably not
<Amaranth> you need a disk efficient RCS, a program that watches for changes and commits them to said RCS, a GUI on top of all that, and an API for other applications to use to store random objects
<Amaranth> the first and last parts would probably take the most work
<Amaranth> but it's not a "hard" problem as in difficulty, just time
<Amaranth> oh, and an easy way to move the backups to other disks or over the internet
<lasindi> Do you think something like plain Subversion would be up to the task for the RCS?
<Amaranth> i actually think modifying rsync to store the differences on sync instead of writing out the original file would work
<lasindi> Amaranth: is there an advantage of using that over something like CVS or SVN?
<infinity> CVS is bloated on-disk, and SVN won't let you get directly at your files without checking them out.  You'd be heavily modifying either to do what you want.
<HrdwrBoB> Amaranth: I just use rsync with hardlinks
<HrdwrBoB> of course, it's not useful for large files with small changes
<lasindi> infinity: well, if you, say, create a directory, couldn't you just commit after you add it, and then "svn up -r <previous revision>" to go back to before you created it?
<Amaranth> the storage method is the only "hard" problem :)
<HrdwrBoB> what about LVM snapshots
<wasabi> LVM snapshots would accomplish the task.
<Amaranth> doesn't zfs do this?
<wasabi> Also, a transactional FS.
<wasabi> Such as ZFS.
<Amaranth> that's probably how apple does it
<wasabi> Yeah. NTFS in Vista is going to have transactions too.
<Amaranth> apparently leopard has a lot of opensolaris code
<infinity> lasindi: Sure, but then you're stuck with a repository AND a filesystem which anyone can do, but it's effort and bloat.
<HrdwrBoB> LVM snapshots aren't good to use unless the whole 'running out of space on a snapshot' thing
<HrdwrBoB> cna be solved in an elegant way
<lasindi> The reason I'm wondering about Subversion is because Time Machine will likely lack features like being able to easily generate diffs of files and look at a log, while SVN could provide that.
<wasabi> subversion is slow, and can't lock the FS in a consistant state.
<HrdwrBoB> yes
<HrdwrBoB> SVN is a bad idea on many levels
<lasindi> Mostly because it's slow?
<Amaranth> SVN is probably the worst possible choice :P
<lasindi> Heh, ok
<wasabi> I'd start by implementing or finding a transactional FS. :)
<Amaranth> indeed
<wasabi> Where changes to the FS nodes/structures are stored on the FS, in an atomic fashion.
<wasabi> And branchable
<bluefoxicy> this is really asinine but
<bluefoxicy> are there any server tools that mimic the feel of Windows 2003 server or the Fedora Management Console
<wasabi> Web based or MMC?
<bluefoxicy> insomuch that you have a console that lets you configure Web, e-mail, DNS, and directory server (yay LDAP) settings
<bluefoxicy> with point and click access
<wasabi> No. No such thing.
<wasabi> At least not that works properly.
<Amaranth> isn't reiser4 a good candidate then?
<wasabi> wiki.ubuntu.com/DomainAuthenticationUtility
<bluefoxicy> wasabi:  I was thinking a GUI application, but Web based seems fine.
<wasabi> Amaranth: No clue. Never investigated it.
<infinity> Reiser's track record doesn't make me comfortable designing solutions around it.
<lasindi> Amaranth: reiser4 probably won't be out for several years though, right?
<Burgundavia> wasabi: isn't that was ajmitch is doing?
<lasindi> *by out I mean merged into the kernel
<bluefoxicy> wasabi:  I just noticed someone complaining that "ubuntu server edition is supposed to come with everything I need for a server"
<Amaranth> well, yeah...
<wasabi> Burgundavia: No idea. Haven't talked to anybody. I made that wiki page like 2 years ago or something.
<wasabi> Burgundavia: brain dump
<infinity> bluefoxicy: It does come with everything you need for a server. :P
<infinity> bluefoxicy: And everything you need to manage one, too.  openssh and about four thousand text editors.
<bluefoxicy> wasabi: I am thinking the UNFORTUNATE situation is that people feel that they "need" a GUI that lets them configure a server WITHOUT understanding the software they're setting up
<bluefoxicy> i.e. what windows does
<wasabi> bluefoxicy: We know, we need that area covered, but we don't have it.
<wasabi> Help. :)
<wasabi> There is no unifying auth system yet.
<infinity> bluefoxicy: I'd like to see a "small Business Server" sometime that demystifies some of this and gives people good GUI tools, but the good GUI tools just ain't there.
<bluefoxicy> "I have no training but I got an IIS site up *hacked* OSHIT!"
<wasabi> There are just pieces which suck to configure.
<HrdwrBoB> bluefoxicy: that's a failure of people to undestand what they are downloading
<HrdwrBoB> you are right and those tools are needed
<HrdwrBoB> but the reality is setup anything nontrivial you need decent knowledge
<bluefoxicy> infinity:  yeah.  I'm on the fence with the GUI thing.  On one hand, point and click is faster even for experienced, well-trained administrators; on the other, an idiot can get things "working," and that's not necessarily good (I KNOW what I'm talking about, 100% of the ownage at the CCDC was misconfiguration and the pen testers said 95% of what they see is same)
<HrdwrBoB> and the gui things provided in my experience just screw up your config more than it was
<wasabi> bluefoxicy: In regards to the AD thing, we need a unified definition of what our solution is. Integration with other solutions. Obviously it's an LDAP+Krb5 system like everybody else.
<wasabi> bluefoxicy: But what pieces, whoses Krb5, what are the standard LDAP templates?
<bluefoxicy> HrdwrBoB:  I've seen some "clean" GUI tools that make only the modifications they say they do, without making frivolous excess.
<infinity> bluefoxicy: I disagree about the being faster bit.  For small sites, this seems to be true, but as sites grow, CLI and scripting rule the roost.
<Burgundavia> wasabi: you need to talk to ajmitch
<HrdwrBoB> bluefoxicy: though they are the minority unforunately
<bluefoxicy> wasabi:  LDAP has no standard scheme as I understand; activedirectory supplies a standard scheme, if it would not be a copyvio perhaps it could be... appropriated...
<infinity> bluefoxicy: I'm constantly frustrated with NT Server machines because I can't just sed a bunch of files, or other such tricks.
<HrdwrBoB> infinity: you can script IIS, I've been involved with it, however it's an order of magnitude more difficult
<infinity> (And being able to dump, sed, reload and LDAP DB is hella-fun -- don't try this at home unless you understand the schema you're mangling, mind you)
<infinity> s/and LDAP/an LDAP/
<bluefoxicy> infinity:  set up an ldap auth client, you need to edit 4 files relevant to PAM.  RedHat lets you do it by a click and 2 fields.  there are specific cases.
<Hobbsee> morning infinity 
<wasabi> bluefoxicy: that's the problem.
<wasabi> bluefoxicy: we NEED a standard default schema.
<infinity> bluefoxicy: Yeah, we have some spec or other about simplifying client auth for LDAP and Samba.
<infinity> bluefoxicy: I vaguely recall ajmitch having something to do with it.
<wasabi> bluefoxicy: You can't have a GUI tool which requires people to specify LDAP search filters and objcet classes.
<wasabi> That stuff's so technical you mine as well use a console.
<infinity> Hobbsee: Afternoon.
<bluefoxicy> wasabi:  is it a copyvio problem to lift the schema from ActiveDirectory?
<wasabi> We need a wizard called "create domain", which takes a dns domain name, probes it, discovers whether it exists already or not, and in 4 questions, finishes.
<wasabi> Basically the question comes down to   "does it already exists->setup local system to auth to else->create, configure, and setup krb5 + Ldap
<bluefoxicy> anyway I was just curious about where that was going
<wasabi> Unless somebody else is working on it, nowhere that I know of. ;)
<nixternal> sorry for the floods earlier, as it seems my router was nailed...
<wasabi> The tech is coming into place, slowely. The samba4 guys are doing most of it.
<wasabi> krb5 integration in DNS, etc.
<cafuego> Does anyone have a moment to help me sort out a debconf problem I can't seem to get my head around?
<cafuego> I am calling db_get in a preinst script to check if the installing user has accepted a license. On the first go, the key i'm looking for obviously doesn't exist. As far as I'm aware, my preinst checks for this, then creates it if needed. However, it just exist ungracefully when debconf returns 10 "doesn't exist"
<crimsun> it seems better to have the key in the template and Default it to false
<infinity> Of course, there's nothing that can't be solved with a judicious sprinkling of || true all over the place.
<infinity> (Or wrapping your db_get in an if block)
<infinity> But the template suggestion is more correct.
<infinity> You also realise that to use debconf in a preinst, you need to Pre-Depend on it (ick), right?
<cafuego> Ok, so I just add a value in the template.. easy.
<cafuego> infinity: Not worried about that.
<cafuego> Hmm, well, as fara s I can tell it's already in the template
<cafuego> Aha. 
<cafuego> I can just call the template file "templates" right?
<cafuego> it's as if it's not included in the package; debconf reckons it can't find its contents.
<cafuego> Yeh, if I use 'dpkg -e'
<cafuego>  to extract the generated package, the templates file is missing. Am I missing a call in to db_ somethingorother in rules?
<crimsun> dh_installdebconf
<cafuego> just foud it, thanks :-)
<crimsun> np
<cafuego> ugh, this debugging would be a tad easier if the package wasn't 46Mb
<cafuego> crimsun: I got it working, cheers!
<crimsun> excellent
<infinity> Amaranth: Should "metacity --replace" be enough to test the reversion of that patch, once installed?  If so, that didn't fix the problem I was having last night.
<cafuego> googleearth, here we come ;-)
<ajmitch> cafuego: interesting, do you have some arrangement to distribute that?
<cafuego> ajmitch: No, and the changelog does note the that package 1) violates the included license and 2) is for my own use.
<ajmitch> aha
* cafuego can plonk it on multiple PCs at home this way 
<cafuego> without needing non-deb mess
<infinity> So, you made a package with a clickwrap license.. For yourself? :)
<cafuego> and easy upgradeability
<infinity> That seems a bit masochistic.
<cafuego> infinity: Yes.
<infinity> Unless you're hoping to get Google to distribute it (or allow distribution) now that you've done the work. :)
<cafuego> infinity: And so that I cna access it easily, I pushed it to my online repo.. :o)
* cafuego can't be held responsible if others discover it...
<infinity> I don't think that actually holds up in a court. :)
<infinity> But I doubt Google will be suing, either.
<cafuego> Before any court there will probably be a cease&desist letter
<cafuego> Which I'll happily obey
<infinity> Yeah, I've had a few C&Ds in my day, too.
<infinity> Always fun.
<cafuego> If not, I'll be happy to do jail time for the cause!
<infinity> Which, when I was younger and more "screw the man"-ish, just lead to me moving things to a different directory on the same public webserver.
<infinity> I've sine reformed.
<infinity> s/sine/since/
<cafuego> Not, mind you, that violating a license is actually a criiminal act in australia.
<ajmitch> cafuego: you want to enjoy the hospitality of the australian government?
<infinity> Australian prisons look comfy anyway.
<cafuego> ajmitch: I already am
<cafuego> They're letting me stay!
<infinity> I've been looking forward to getting arrested ever since I moved here.
<ajmitch> such a shame that I'd have to wait 2-3 years for the unemployment benefit there
<cafuego> infinity: You gotta do your best for that
<cafuego> ajmitch: Don't kiwis just automatically get that the moment they step off the plane here? ;-)
<ajmitch> cafuego: nah, they changed it for some strange reason :)
<cafuego> <heh>
<infinity> Oh, they don't hand you permanent residence when you cross the border anymore?
<infinity> I thought that was still in effect.
<ajmitch> they do, but not the dole
<cafuego> infinity: They might, but permanent residence != benefits
<infinity> Oh, right, they stole a bunch of benefits from residents recently.  Forgot about that.
<infinity> Like, no more HECS for non-citizens.
<infinity> Bah.
<cafuego> (or much in the way of other rights, except the right to pay taxes)
<infinity> Oh well.  I guess I could apply for an .au passport in 3 years, if I really cared, but I doubt I care that deeply.
* cafuego should, now that the dutch will allow him to have both
<infinity> Voting in elections where I don't agree with any of the major parties doesn't sound all that exciting.
<cafuego> infinity: Informal Voting for Gain and Profit
* ajmitch would probably just keep his nz passport if it came to moving to australia
* cafuego doesn't think voting in a country where electorates are set up to make voting useless has any point at all.
<cafuego> ajmitch: Yes, probably safer what with .au being the .us these days.
<infinity> ajmitch: Well, yes, I'd not renounce my Canadian citizenship, I just have an ongoing internal dialogue about the pros and cons of ALSO being an Australian citizen.
<infinity> So far, the pros are lacking.
<cafuego> infinity: 99% chance of jury duty for new citizens due to the "randomised" selection process.
<infinity> Jury duty doesn't bug me.
<ajmitch> hah, I just had that this week
<cafuego> does for me, I think it's a bad system.
<ajmitch> got called up for a trial, but the plea was changed to guilty & we could all go home
<infinity> cafuego: And it's improved by you not participating in it? :)
<cafuego> infinity: It's improved by getting rid of it.
* cafuego thinks judges who study for decades are far better suited to make such decisions than random strangers off the street.
<infinity> ajmitch: You may have missed out on some fun.  My brother-in-law was called up about a year ago, did two cases in a row, and had insane stories to tell for weeks.
<ajmitch> infinity: I didn't really feel like hearing a case of indecent assault on a child
<infinity> ajmitch: His cases were bizarre, and the trash involved in them (and the quotes) were even more bizarre. :)
* cafuego goes to organise some tea
<infinity> ajmitch: Ahh, yeah, that could be a drag.
* ajmitch sees he missed an interesting conversation about ldap & related topics earlier
<Amaranth> infinity: it should have been, yes
<Amaranth> infinity: i'm out of ideas, that was just something i saw happening
<Nafallo> iwj: I think you broke evolution with your new firefox.
<Nafallo> nafallo@silverfairy:~ $ evolution
<Nafallo> CalDAV Eplugin starting up ...
<Nafallo> (evolution-2.8:5884): camel-WARNING **: Failed to initialize NSS
<jdub> ha ha silverfairy
<Nafallo> jdub: http://www.magicalforest.se/silverfairy/ :-)
* Nafallo should pics on his boxes online some day ;-)
<Nafallo> anyway, shower. bbl.
<mhb> hello everyone
<Hobbsee> hi mhb 
<mhb> Hobbsee: I don't like weekends ... the people that I need to talk to are always not here during the weekends :o)
<Hobbsee> mhb: heh.  dont take weekends?
<mhb> only about 1/4 of them :o)
<mhb> Hobbsee: and what about you?
<Hobbsee> mhb: weekends?  well, i didtn go to work today, if that counts.
<Hobbsee> didnt go to uni either
<tseng> Hobbsee: just be home by 11
<Hobbsee> tseng: hah.  12.
* Hobbsee got out of the house with surprisingly little fuss today.
<tseng> only to get on irc
<bluefoxicy> o.o
<bluefoxicy> crash reports (are supposed to) go in /var/crash
<zul_> hey
<bluefoxicy> I believe the FHS would make /var/lib/crash the more correct path.
<bluefoxicy> but I'm not entirely familiar with it.
<bluefoxicy> hi zul
<bddebian> Howdy
<bSON> hi
<bSON> is there some chance that metacity will be shipped with compositor enabled in edgy? (it shouldn't hurt the ones who don't use it)
<Keybuk> anyone else's Firefox unable to initialise its security component?
<tseng> Keybuk: security as in ssl? crimsun mentioned something about it, works for me
<Keybuk> tseng: yeah
<Keybuk> I tried wiping the profile, that didn't help either
<sladen> Keybuk: are you trying to access a site that is only using 40-bit SSL?
<sladen> Keybuk: eg. a Lights out card or something similar
<Keybuk> sladen: no, I'm just starting it
<Keybuk> "Could not initialize the browser's security component.  blah blah"
<pitti> BenC: just installed and tested new kernel; apport now has full gdb love, great!
<BenC> pitti: sweet
<pitti> d'oh, CD burning is broken for me suddenly - opening /dev/cdrw O_EXCL doesn't work. WTH??
<gnomefreak> permissions?
<pitti> no, certainly not
<pitti> Error trying to open /dev/cdrw exclusively (Device or resource busy)... retrying in 1 second.
<pitti> it's not mounted, lsof and fuser return nothing
<gnomefreak> ah
<pitti> and it doesn't work with sudo eiter
<pitti> either
<bluefoxicy> pitti:  ping
<bluefoxicy> should the crash reporter stick things in /var/crash or /var/lib/crash per FHS?
* bluefoxicy is not familiar enough with the standard to make a definite conclusion
* desrt is annoyed by dpkg's use of /var
<pitti> bluefoxicy: /var/crash
<desrt> stuff in /var/lib/dpkg changes at exactly the same time as stuff in /usr
<bluefoxicy> pitti:  nods, what reasoning?
<pitti> bluefoxicy: well, FHS suggests /var/crash for that and I just followed it
<pitti> bluefoxicy: do you think that's inappropriate?
<bluefoxicy> ah ok
<bluefoxicy> pitti:  no, I was just curious.
<bluefoxicy> As I said I am not very familiar with FHS
<freeflying> how can I  only mirror the dapper and edgy's archive? 
<Keybuk> hmm, I can't move windows with the Windows key either :-/
<pitti> Keybuk: now I can't burn CDs, nor use evolution; judge yourself what's worse :)
* pitti yays edgy
<pitti> Keybuk: however, alt+mouse dragging still works
<pitti> anyway, pub time
<pitti> cu at Monday!
<Keybuk> I can't use Launchpad to file bugs, because it doesn't work without SSL :)
<gnomefreak> links2 can be compiled for ssl :)
<gnomefreak> *wishlist* can we build links2 with ssl support for ubuntu? so users dont have to compile it for ssl?
<geser> doesn't links2 depend already on libssl?
<tseng>  apt-cache show links2 | grep --color ssl
<tseng> if you dont believe us
<gnomefreak> geser: nope doesnt depend on it since its not build with it
* bddebian begs Keybuk to look at libieXXXX in NEW :-)
<geser> the version in edgy links against libssl but not the one in dapper
<gnomefreak> it does? apt-cache show links2 still doesnt show libssl as a depend
<gnomefreak> nvm i see it
<gnomefreak> hm
<gnomefreak> it is added ;)
<Keybuk> hmm, this crash report program is annoying me
<Keybuk> it keeps running every time my own code core dumps
<bddebian> So write better code.. ;-P
<astronut> your livecd refers to a rescue mode but won' tboot it
<astronut> it's in the help, but no kernel image found
<bluefoxicy> Keybuk:  I have apport and I don't seem to get the crash reporter, just gnome's bug tool.
<bddebian> astronut: Go back to your Debian corner.. ;-)
<bluefoxicy> ubuntu > debian
<bluefoxicy> debian == people asking me why they have to /etc/init.d/kdm start on boot
<astronut> ubuntu = broken releases
<bluefoxicy> and me having no answer since their inittab starts runlevel 2 and /etc/rc2.d/S*kdm exists
<astronut> lets see, refering to non existant kernels
<astronut> the spacial browsing a few releases ago
<astronut> etc
<bluefoxicy> 6.06.1 is broken now?
<astronut> i think it's 4
<astronut> 6.0.4
<astronut> the rescue mode doesn't work
<bluefoxicy> we don't have a 6.04
<bluefoxicy> Did anyone release a 6.04?
<Seveas> no
<tseng> 6.04 was meant to be dapper
<tseng> it was pushed back 2 months
<bddebian> astronut: This is a Dapper live-cd?
<bluefoxicy> tseng:  did you see the LWN article criticizing kernel ABI changes?
<tseng> no.
<tseng> I don't subscribe
<bluefoxicy> Apparently 2.6.19 has a new sysfs structure that breaks udev
<bluefoxicy> it points out that Ubuntu Dapper 6.06 LTS AND upcoming slackware 11 will break from this
<bluefoxicy> as part of the argument why changing APIs is bad
<Seveas> bluefoxicy, nonsense
<Seveas> dapper will neither have 2.6.19 nor new udev
<bluefoxicy> Seveas:  ah you saw that too ;)
<Seveas> so that argument is a load of dingos kidneys
<bluefoxicy> Seveas:  and Slackware 11 is "upcoming" so ....
<Seveas> There have been sysfs/udev changes before -- it's painful but doable
* tseng wonders why we need a portlet on Bugs in beagle in ubuntu showing a list of unrelated tags
<tseng> every tag invented to this date, in fact
<HiddenWolf> tseng: tags are pretty much half-implemented at the moment
<Keybuk> bluefoxicy: I'm not convinced it'll break udev
<Keybuk> 2.6.17 had one that allegedly broke the dapper udev, but it hasn't
<bluefoxicy> Keybuk:  I'm not convinced it matters to distros that aren't going to be upgraded to that kernel
<bluefoxicy> bah my weekend is already unbearably boring.  The only excitement I had was the 10 minutes I thought I was gonna get to go hang out with this boy while his parents are out of town
<Keybuk> indeed
<Keybuk> the kernel maintainer's point of view appears to always be that everyone runs their own kernel, etc.
<Keybuk> which just isn't true anymore
<bluefoxicy> my POV is if you roll your own, then roll it
<bluefoxicy> you have to roll a new modutils/module-init-tools to 2.4 -> 2.6
<bluefoxicy> you have to roll a new udev too.
<Keybuk> yup
<bluefoxicy> If you can't do that then you obviously don't understand what you're doing and you shouldn't be doing it.
<Keybuk> and new klibc, etc.
<HiddenWolf> bluefoxicy: lucky you, my morning started by figuring out why my computer was giving no keyboard errors
<bluefoxicy> HiddenWolf:  "almost lucky" you mean.
<HiddenWolf> bluefoxicy: heh, comparatively speaking, of course.
<HiddenWolf> but indeed, almost lucky. :)
<bluefoxicy> My day started with "wwwwwwwwwwwwtf it's time to get up and I still haven't fallen asleep"
<siretart> Richte python2.3 ein (2.3.5-14) ...
<siretart> pycentral: pycentral rtinstall: installed runtime python2.3 not found
<siretart> ideas where to look for this issue?
<crimsun> siretart: we need to sync -15 from Sid
<crimsun> (it's fixed there)
<crimsun> http://packages.qa.debian.org/p/python2.3/news/20060730T161727Z.html
#ubuntu-devel 2006-08-13
<BenC> Kamion: ping
<Burgundavia> desrt: have you noticed dbus dying on resume from hiberate or suspend?
<desrt> not here
<Burgundavia> hmm
<Burgundavia> here are the symptoms: changes in power prefs not taking, networking via network manager not coming back and pressing the power button does nothing
<Burgundavia> that sound like dbus?
<desrt> no.
<Burgundavia> what does it sound like?
<desrt> i'm not sure
<desrt> but if dbus was hoked you'd know for sure
<desrt> since stuff would be dying outright
<Burgundavia> right
<Burgundavia> what should I file a bug on then?
* Chipzz wonders why we choose to depend on software that makes it dependencies not survive a restart anyway
<Chipzz> I guess someone felt linux didn't feel enough like windows :P
<Burgundavia> Chipzz: dbus not dealing with a restart is a long and lingering issue
<Burgundavia> this is different
<Chipzz> Burgundavia: I know ;)
<Chipzz> just venting some mild irritations about dbus design :P
<Burgundavia> yep
<jdub>   * madwifi: Remove legacy and ng drivers. Replace with stock madwifi-ng 0.9.2
<jdub>     driver.
<jdub> ooh
<tseng> jdub: i would read that
<tseng> jdub: but i cant start evo
<tseng> I'll be borrowing your mutt fingers now
<jdub> ha ha
* jdub <3 nss
<Mez> hmmm
<Mez> nice to see backports got a mention recently in a UK linux magazine
<sivang> morning
<Burgundavia> morning sivang
<sivang> Burgundavia: Hey Corey, how are you ?
<Burgundavia> not bad
<Burgundavia> got the UWN out
<sivang> yeah, I just read some parts of it, learning the Jono is the new community manager
* Hobbsee waves to sivang and Burgundavia 
<Burgundavia> hey Hobbsee
* sivang hugs Hobbsee 
* Hobbsee hugs sivang 
<Hobbsee> :)
<sivang> Hobbsee: So you're a main uploader now ha?
<Hobbsee> sivang: that depends.  what makes you say that?
<crimsun> speaking of which, is the current wiki downtime expected?
<sivang> Hobbsee: hmm, I thought i saw you were approved for main or something, but then again the last days have been blurry so I may be wrong.
<sivang> hey crimsun 
<crimsun> 'lo sivang 
<Hobbsee> sivang: i went for it.  didnt get approved though
<Burgundavia> crimsun: I have heard no such annoucement
<sivang> Hobbsee: ah, well, probably you'll get it next time around.
<ajmitch> Burgundavia: so it's just plain broken, I guess
<Hobbsee> sivang: if i go for it next time round, maybe.
<Burgundavia> ajmitch: given they would probably tell us, yes
<Burgundavia> ajmitch: the downtime is not all of london, however, only the wiki and the help wiki are down. The ubuntu website and the docteam svn are still up
<imbrandon> LP looks to be up too, isnt that in the same DC
<ajmitch> yes, it only seems to be the wiki
<sivang> re
<ubuntu_demon> hi
<sabdfl> mjg59: is there a wiki page which describes the capabilities of the new usplash, which we can point the art folks t?
<freeflying> how do we encrypted the passwd of user in livecd? DSA? SHA? thanks
<siretart> whats the last known to working alternate install cd?
<gnomefreak> siretart: 6.06.1 works
<siretart> gnomefreak: I was asking for the last known working. I want to reinstall edgy
<mdke> hehe
<TheMuso> siretart: I used one on powerpc today that I synced on Thursday my time
<gnomefreak> oh
<siretart> TheMuso: hm. I tried the one from today, but it fails to load kernel modules
<TheMuso> But don't know about what the CDs are like between now and then
<Surak> BenC: ping
<Hobbsee> Surak: it's the weekend, he's likely not here.
<Surak> Hobbsee: That's why I tried to ping first :-)
<Hobbsee> Surak: true that.
<Surak> Do you know if is there a way I can pass a parameter to modprobe in isolinux? I mean, I want to blacklist a module using the live cd - but I don't want to create a custom live cd only for that.
* Hobbsee knows nothing, nothing at all.
<Surak> There is a module which makes several machines to reboot when loaded, and it is enabled by default on ubuntu. I got a new set of machines, and every single one suffers from this issue.
<gnomefreak> he was here yesterday 
<Surak> gnomefreak: do you have an idea on how can I do that?
<gnomefreak> Surak: no but ive seen it complained about 
<Surak> there's a serious bug in intel_agp driver, and I'm trying to figure out what intel chipsets have this issue. It seems that every current one has this issue.
<Surak> I had lockups using the i865, i910, i915 (several different 915 ones), i925, i945, i946, Q963 and P965 chipsets so far.
<Surak> none of those can boot dapper nor edgy if there's a not-integrated videocard plugged in - which seems quite serious to me
<HiddenWolf> Surak: try disabling the onboard in the bios
<HiddenWolf> Linux tends to get awefully confused with more than one gpu/soundcard plugged in.
<Surak> Hiddenwolf: that's not the case: take a look at bug #55104 and bug  #55298
<Ubugtu> Malone bug 55104 in linux-source-2.6.15 "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  https://launchpad.net/bugs/55104
<Ubugtu> Malone bug 55298 in syslog-summary "Please sync syslog-summary 1.12-0.1 from debian sid" [Untriaged,Rejected]  https://launchpad.net/bugs/55298
<Surak> ops, bug #55928
<Ubugtu> Malone bug 55928 in xorg "wrong primary display selected in multihead setup (PCI bus enumeration order)" [Untriaged,Confirmed]  https://launchpad.net/bugs/55928
<bddebian> Howdy
<Surak> HiddenWolf: there are several broken bioses which doesn't disable the hardware device even if it is set to - they seem only to turn the signal to the monitor off and that's it - the onboard device even keeps stealing ram from the main system
<Surak> HiddenWolf: I spoke with MSI, and they recognize the bug - I'm still waiting the update for the three specific models I had access to. But intel desktop boards seems to suffer from the very same problem, and it's not easy to me to reach intel guys - as we don't make motherboards for them, we only sell their ones.
<siretart> TheMuso: gnomefreak FYI: the daily from friday seems to work
<gnomefreak> siretart: thank you
<TheMuso> siretart: Thanks, but I no longer need one. :p. I tend to keep up to date with the dailys every few days anyway.
<siretart> is partman-crypto supposed to work in ubuntu?
<mike_zhang> hello everyone!
<mike_zhang> who know howto setup a buildd daemon on ubuntu?
<mike_zhang> thanks for help
<mike_zhang> or someone can give me some information about it?
<mike_zhang> my email address is mikezhang@hotmail.com, if someone want to help me send email to me. thank you verymuch
<BenC> Surak: pong
<Surak> I noticed that, regarding bug #55104, the issue comes up not only using nvidia, and not only using i865 chipsets. I saw the same intel_agp module locking up machines with different motherboards and different video cards.
<Ubugtu> Malone bug 55104 in linux-source-2.6.15 "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  https://launchpad.net/bugs/55104
<Surak> Today I don't have access to a environment where I could modify the live CD to test the machine I have available now. (in this case, a Intel D945gcz board and a ati radeon x1300 - which restarts when loading intel_agp also)
<Surak> Is there a way to pass an isolinux parameter which would make modprobe to blacklist intel_agp? 
<bSON> hi
<bSON> will metacity be shipped with with --enable-compositor some time?
<Surak> oh, the above is for BenC, in case you are not looking to this window right now :-)
<bSON> excuse me, my pc crashed...
<BenC> Surak: ok
* hunger sighs.
<hunger> New kernel won't boot:-(
<zul_> which one?
<hunger> 2.6.17-6-686
<BenC> hunger: did -5 boot?
<Surak> BenC : this makes 1) the bug's description wrong (as is not nvidia-related), and 2) turns out this is critical, as it's not an isolated specific case.. Oh, and is not 2.6.15-related only, but also happens in 2.6.17. I can't change the bug's importance, as well as assign it to more than one product. Who are the one which could do this?
<hunger> BenC: Yeap, that is the one I am using.
<BenC> Surak: me, post this info to the bug, and I'll fix things up
<BenC> hunger: remove the "quiet splash" kernel options and see if there's any output
<Surak> thanks
<hunger> BenC: Nope, it stops when loading hardware drivers.
<hunger> BenC: No additional output this time:-(
<BenC> hunger: that's why I said remove the "quiet splash" options :)
<hunger> BenC: I do not have those enabled:-)
<BenC> hunger: also, let it sit for up to 5 minutes to see if it does anything
<BenC> hunger: ah, ok
<hunger> BenC: That damn splash thing is too anoying and I want to see what goes wrong...
<hunger> BenC: I'll write a bugreport and retest again.
<mjg59> The splash thing is not started unless splash is specified
<hunger> mjg59: That is why I removed "splash" from the kernel options line:-)
<Surak> hunger: what's you motherboard/chipset/video card?
<mjg59> Oh, I see
<mjg59> Mad misinterpretation
<hunger> BenC: You were right: It just gets stuck and continues after about 5 min.
<hunger> Surak: I am on a thinkpad T43p. HW list is on the wiki.
<BenC> hunger: that's a dupe of another bug...not sure why it started for you with -6 though
<hunger> BenC: -5 works great... does break suspend once again, but that never worked reliably since breezy anyway:-(
<BenC> hunger: add debug to the kernel command line to get initramfs-tools to output more stuff during boot
<hunger> BenC: Last output before the stop is about IBM trackpoint. But I think that one is brought up properly and it stops only afterwards.
<BenC> hunger: I just want to see what udev and friends arfe waiting for at the point of pause
<BenC> hunger: email dmesg to bcollins@ubuntu.com too, so I can see where the pause is in there
<bSON> is nobody able to answer my question? should i ask it somewhere else?
<hunger> BenC: I am updating #56249 and will then reboot with debug afterwards.
<BenC> bSON: what was your question?
<bSON> if there are any attempts to package the metacity package built with --enable-compositor
<BenC> bSON: doubt you'll get an answer for that one
<bSON> who could i ask? the package maintainer?
<Surak> bSon: probably
<bSON> ok, thanks
<hunger> BenC: debug did not really give any more output...
<hunger> BenC: dmesg output is attached to #56249.
<BenC> [17179762.700000]  EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
<BenC> hunger: you sure the delay wasn't caused by fsck or something?
<BenC> hunger: the delay happens between the trackpad message and that message
<jono> hey
<zul_> hey jono 
<jono> hey zul_
<dsas> jono: Congrats
<jono> dsas: thanks :)
<zul> argh...hate lag
<zul_> hey pitti 
<pitti> mdz: ping
<pitti> hi zul
<pitti> mdz: can you please promote apport to main? with the new kernel, it 'just works', thus I'd like to get it into main and then ubuntu-desktop
<pitti> mdz: after that, I'll write an announcement
<mdz> pitti: ok
<mdz> pitti: should be in the next publisher run, feel free to seed and update ubuntu-meta
<pitti> mdz: great, thanks
<pitti> mdz: yes, I'll do the seed changes tomorrow, when I'll have proper internet connection again (lousy modem ATM :( )
<pitti> mdz: are you fine with bzr 0.9 in edgy? some people cried for it and the speed improvements are indeed quite impressive
<mdz> pitti: yes, in fact I was talking with mark about it last week and I had assumed it was already there
<mdz> pitti: we should definitely get it in
<pitti> mdz: Debian has 0.9rc1, so it shouldn't be hard to update to 0.9
<pitti> mdz: if I have the UVF blessing, I can do that tomorrow
<pitti> mdz: BTW, seed changed for apport-gtk, but modem speed sucks for updating u-meta, I'll do that tomorrow
<mdz> pitti: I'll do it if I'm around when the publisher run finishes
<pitti> great
<pitti> ok then, good night!
<shaya> hmm, bug in nss w/ firefox prevents me from submitting bugs to launchpad!
<gnomefreak> nss or css?
<mdz> shaya: works fine here
<shaya> nss
<shaya> no https works for me
<shaya> and evo dies on startup w/ an nss error since bon echo upgrade
<shaya> reproted that bug before I restarted firefox :(
<shaya> mdz: are you running bon echo?
<gnomefreak> i am just not ubuntus version
<shaya> gnomefreak: and most likely not installed in /usr
<gnomefreak> nope ;)
<mdz> shaya: of course (current edgy)
<shaya> hmm
<mdz> evolution dying is known and there is a workaround
<mdz> bug 56118
<Ubugtu> Malone bug 56118 in evolution "Crashes on startup" [Unknown,Unknown]  https://launchpad.net/bugs/56118
<shaya> hmm
<shaya> did a dpkg-reconfigure firefox
<shaya> and now it works
<shaya> strnage
<shaya> I see the workaround, works for me, just annoying
<shaya> wonder if its related to the constant "bonobo-activation" dying errors I was getting
<shaya> had to switch to kubuntu temporarily as it made it impossible to work
<daschl> does anyone know what techonolgy ubuntu uses to show the "smart-battery"? it works out of the box since dapper.. ? HAL?
<Burgundavia> daschl: very likely, but what is the issue
<daschl> well i want to get it up and running on my gentoo box, so i have to tweak a bit more :) .. and the kernel itself does not support the smart battery afair
<daschl> it would be glad to see a kernel patch or something like this.. messing around with HAL is not funny i suppose
<Burgundavia> right, this might be the wrong channel for that
<daschl> well i just want to know which technology and i thought the devs will know it
<daschl> i dont want support how to get it up and running
<daschl> because i didnt find any informations about the change in dapper
<shaya> daschl: look at gnome-power-manager
<shaya> see what it does
<daschl> thanks, i will take a close look at it
<shaya> specifically in 2.5.0 this was added
<shaya>  - Enable all the experimental code, such as the info window and the graphs. The graphs have had some serious Cairo lovin' and look pretty slick now, and should display more accurate data that we were displaying before.
<shaya> the "info" window is where I see the smart battery stuff
<daschl> i see... gnome-power-manager uses HAL .. well but maybe it works out of the box on gentoo too
<daschl> thanks for the support :)
<shaya> mdz: the https bug I mentioned occurs when one instantiates firefox (bon echo) from thunderbird probably due to incompat libraries and environments
<bastien> hello
<daschl> hey
#ubuntu-devel 2007-08-06
<StevenK> infinity: Is it just me, or does artigas currently hate life?
<untung> hello, how can i create my own ubuntu live cd distro?
<untung> i want to put the softwares and drivers to be loaded for my laptop
<LaserJock> untung: you probably want Reconstructor or Ubuntu Customization Kit
<mikmor2> I don't think either of those handle adding drivers, etc very well
<LaserJock> they can't? as long as they are in the repos it should be easy I'd think
<untung> laserjock: where can i download the software
<LaserJock> untung: google it, I'm not sure exactly
<lifeless> mikmor2: its just a new kernel, or a modular driver package
<untung> laserjock: i found the link http://uck.sourceforge.net/
<mikmor2> yeah, UCK is probably your best bet then
<pitti> Good morning
<Fujitsu> Hi pitti.
<LaserJock> hi pitti
<StevenK> Morning pitti.
* pitti hugs you all
<StevenK> pitti: I have a bunch of NBS stuff to do, do you have a sec? :-)
<pitti> StevenK: sure
<StevenK> pitti: Firstly, libklash0, libgnash0, libxfontcache1-dbg and libgcj8-0-awt can all be NBS'd out.
<StevenK> pitti: Secondly, are you able to rescue libquicktime and mpfr from binary NEW?
<StevenK> pitti: Of the ten rdepends of libquicktime0, I have got nine uploads just about prepared, and wanted to talk to you about the ten.
<StevenK> s/ten./tenth./
<mhb> hi pitti
<pitti> hi mhb
<pitti> StevenK: libgcj8-0-awt doesn't exist; I NBSed all the rest
<StevenK> Interesting, since libgcj8-0-awt appears in the NBS list.
<pitti> only libgcj8-0 here
<StevenK> Curious. I shall sort out libgcj8-0 later today.
<pitti> StevenK: quicktime NEWed, mpfr is already
<StevenK> Neat, thanks.
* StevenK now to wait roughly 1h10m for the publisher to run and finish, and then upload nine things.
<pitti> StevenK: you can upload right now with the right build deps, too
<pitti> StevenK: so what about the mysterious 10th package?
<StevenK> pitti: Okay, so the last thing (for the moment, anyway :-) is the tenth package listed as depending on libquicktime0 - which is xmovie. It fails to build from source, as does the newest upstream version, it doesn't appear in popcon, and looks like we have about three better alternatives.
<StevenK> pitti: Better, the package (and it's bug reports) have not been touched in Debian for the better part of 15 months.
<StevenK> pitti: Are you against killing and blacklisting it?
<pitti> StevenK: I'm not, no
<pitti> StevenK: please file a removal bug with that reasoning (so that we have a record)
<StevenK> pitti: I was just about to ask that. :-)
<pitti> hm, apt-cache search doesn't have any results for xmovie
<pitti> aah
<pitti> i386 only
<StevenK> Yup.
<StevenK> pitti: Done. Bug 130582
<ubotu> Launchpad bug 130582 in xmovie "Please remove xmovie" [Undecided,Confirmed]  https://launchpad.net/bugs/130582
<pitti> StevenK: removed
<wolfe> pitti: I'm reading the homepage for the software, they're using Fedora 5.0 and even 64bit
<StevenK> pitti: Thanks!
<StevenK> wolfe: Yes, and the upstream does this by including his own versions of quicktime4linux, libmpeg3 and libsoundfile.
<StevenK> His rationale is "distributions libraries change too quickly", which is complete crack.
<wolfe> StevenK: just statically compile?
<wolfe> I mean, I don't see a problem with the software if it works
<RAOF> What if the version of the libraries he ships have bugs, or security vulns?
<wolfe> StevenK: well, I've been bitten in the past by distributions which want to use different versions of certain libraries, so it is not complete crack
<wolfe> RAOF: like there isn't software which already ships with exploits?
<Fujitsu> wolfe: It's a lot easier to maintain one copy of all these crazy codecs than a thousand.
<RAOF> wolfe: No, but static linking makes it more difficult to fix.
<wolfe> RAOF: not really, see osx ;)
<StevenK> I wouldn't use OS X as an example of stuff done right.
<RAOF> wolfe: IE: you just rebuild the lib *once*, rather than hunting down each package that includes it's own copy, munging it, and rebuilding.
<Burgundavia> especially on a package management side
<wolfe> StevenK: all I'm saying is it works.l
<wolfe> RAOF: right, complete opinion of the community, the old static vs dynamic argument
<wolfe> both are fine
<Burgundavia> wolfe: usability must, by its very nature, include the idea of good security
<Burgundavia> if you have bad security, you have bad usability
<RAOF> wolfe: Indeed.  But when you have package management as good as apt, the advantages of static linking are hugely outweighed by the disads
<wolfe> Burgundavia: okay, let me just install a pacakge which other programs depend on which is exploitable, now you've several exploitable programs instead of just 1
<wolfe> I could do this all day, and nobody really wins
<wolfe> the point is, static vs dynamic is pure opinion
<RAOF> No, it isn't.
<wolfe> yes, it is.
<pitti> wolfe: no, it's not pure opinion, it's a question of maintenance costs
<Fujitsu> If we were to link everything statically... well, I don't like to think about it.
<wolfe> the whole "its insecure" argument depends on the maintainers
<pitti> wolfe: if we had arbitrary amounts of maintenance power, it wouldn't be a problem, but we haven't
<wolfe> pitti: right, which I'm not disputing.
<pitti> wolfe: the nastiest thing about static linking is that there is *no* automated way to check which packages are affected by a bug
<wolfe> we're disputing "static linking is not secure" which is complete opinoin
<RAOF> In *practice* static linking is less secure?
<wolfe> pitti: well if the package manager was built better to autocheck what was static cally compiled to begin with ;)
<pitti> wolfe: right, it should be 'static linking is unmaintainable and can lead to covert security holes'
<wolfe> I'm curious
<pitti> wolfe: as I said, there are no tools which tell you which libraries have been statically linked to a program; package managers don't help there
<pitti> wolfe: and here this just seems to be an excuse from upstream maintainers not keeping up with libraries; there's no inherent reason not to use the standard system libraries
<wolfe> pitti: ahuh...
<pitti> wolfe: as opposed to, say syslinux or grub which need to statically link libc parts
<wolfe> pitti: so what are your thoughts when mplayer damned the debian project? :)
<Fujitsu> With ffmpeg?
<wolfe> Fujitsu: yeah, I think that was it. was years ago, but I remember it very clearly.
<RAOF> ffmpeg being something of an oddity
<Burgundavia> the ffmpeg developers need some education
<RAOF> In that they are vehrmently opposed to releasing software.
<Fujitsu> ffmpeg and mplayer upstream are the same, and its interfaces change quickly, AFAIK.
<wolfe> pft
<pitti> wolfe: right, xine-lib and mplayer ar the prime examples of evil static linking (I understand that because of ffmpeg upstream's unwillingness to provide a stable ABI)
<wolfe> ABIs change, software changes..
<pitti> right
<wolfe> its up to OSes/distros to provide updated packages
<wolfe> upstream only writes the software after all
<pitti> but something like a video driver ABI should not change every week
<Burgundavia> in the ffmpeg case, it is becasuse the developers refuse to even consider providing a stable api/abi
<RAOF> But people worknig on a *library* should actually *release* the library.  At some point.
<pitti> wolfe: gstreamer manages to provide a reasonably static ABI, too, so it's not impossible (in Windows this is common standard for ages already)
<wolfe> huh, you guys don't have the Io programming language in packages :)
<wolfe> Steve refuses to use dynamic linking, he is a osx guy
<pitti> cjwatson: any idea why amd64/i386 livefs builds aren't even attempted today?
<pitti> cjwatson: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/20070806/
<ajmitch> RAOF: don't let your prejudices get in the way of reality
<ajmitch> RAOF: sometimes us users aren't worthy of having an actual release
<wolfe> heh
<wolfe> oh please, releases are so passe ;)
* Fujitsu stares at mplayer upstream.
<Fujitsu> 1.0rc1 was released 9 months ago.
<RAOF> ajmitch: True.  Development would be stalled far too long if you couldn't break ABI/API at will.
<wolfe> I use -HEAD on most of my libraries I use and media
<Fujitsu> Enormous changes have occured in the codebase since.
<pitti> ArneGoetje: are you aware of any fonts in ubuntu-desktop we could drop? we need to make some space on the CDs
<LaserJock> pitti: how much space?
<pitti> LaserJock: about 5 MB on amd64
<Amaranth> RAOF: i would think after, say, a year you would be able to figure out a solid ABI/API that you wouldn't be limited by
<pitti> LaserJock: probably some more, because seb128 wants to add tracker and consolekit today
<StevenK> pitti: I am amused that both libgcj7-0 and libgcj8-0 appear on the NBS list.
<LaserJock> pitti: heh, ogra can give you hints about skimming off .isos ;-)
<LaserJock> poor guy was constantly oversized
<Amaranth> s/was/is/
<LaserJock> and yet he stays so skinny ;-)
<pitti> heh
<pitti> a-haa
* pitti kicks nvidia-glx from the amd64 alternate
<pitti> ArneGoetje: ok, unping for now :)
<RAOF> Amaranth: No, why on earth would you think that.  Alternative answers include: "That would require someone to *design* an API, rather than let one congeal" and "But that would prevent us from potentially increasing decode speed by 1.2% in this uncommon case!"
<Amaranth> RAOF: I find it hard to believe they keep making the same API mistakes wrt decode speed after years of working on this stuff
<Amaranth> It's like every new codec they add they repeat the same mistakes
<RAOF> Amaranth: Yes, of course.  Opaque data structures are for people who don't know how many cycles a 32bit add + bitshift twice right operation takes on each major arch from the last 10 years.
<RAOF> Amaranth: Every 6 months or so someone who actually wants to *use* the libraries will suggest that they do a release... with hilarious consequences!
<Amaranth> RAOF: I've seen
<RAOF> It would be so useful to get a release.  And I suppose Debian has, really.
<pitti> Riddell: I gave bug 117731 to you, since that's marked as tribe-4
<ubotu> Launchpad bug 117731 in python-kde3 "Python crashes after attaching pty to a konsole kpart" [High,Triaged]  https://launchpad.net/bugs/117731
<pitti> TheMuso: here by chance?
<pitti> TheMuso: in bug 122024, cjwatson talks about a 'partial fix merged into mainline'; what is the status of this?
<ubotu> Launchpad bug 122024 in casper "orca should automatically get started when braille is activated" [Medium,In progress]  https://launchpad.net/bugs/122024
<carlos> pitti: did you get Dapper's base update?
<pitti> carlos: I got it, yes; packages should be built now, I'll test them soon
<carlos> pitti: which one? (so I prepare the right incremental updates)
<pitti> ~carlos/public_html/language-packs/dapper/rosetta-dapper-2007-08-03.tar.gz
<pitti> carlos: timestamp matches, 20070803
<pitti> good morning mvo
<mvo> hey pitti
<carlos> pitti: ok, thanks
<carlos> mvo: morning
<carlos> mvo: Are you updating DDTP in our archives?
<carlos> mvo: we get many emails asking about it on ubuntu-translators and other per locale mailing lists
<pitti> mvo: bug 122459 is fixcommitted, will you upload this soon?
<ubotu> Launchpad bug 122459 in compiz "[gutsy]  cannot log in on edubuntu DesktopCD" [Undecided,Fix committed]  https://launchpad.net/bugs/122459
<pitti> mvo: do you have an idea about bug 107109 yet?
<ubotu> Launchpad bug 107109 in compiz "No "New Login" for user with Desktop effects enabled" [High,Triaged]  https://launchpad.net/bugs/107109
<pitti> mvo: ^ I guess that is because there can only be one X server with composite at a time?
<carlos> pitti: did you check whether it has now all files?
<pitti> carlos: not yet
<carlos> ok
* carlos checks on of the missing files...
<carlos> pitti: French translation for alacarte is there so I guess the others should be there too
<Amaranth> pitti: only one server with GL at a time
<pitti> Amaranth: right
<Amaranth> pitti: and I still have no idea how to fix that bug
<pitti> Amaranth: so, can this be detected cleanly? or shall we work around it by only enabling compiz on :0?
<mvo> carlos: I was kind of hoping that the new process we dicsueed gets into place, but I can do a upload now
<Burgundavia> Amaranth: crack idea: is it possible to change the server that is currently doing GL?
<Amaranth> Burgundavia: No
<Amaranth> Burgundavia: That's determined at server start
<mvo> pitti: I check out the bugs now. the one with fix comited was one I wanted to upload together with a new compiz snapshot, but I had issues last week while testing so I postponed it
<carlos> mvo: even having the new process implemented in this cycle, it will not be deployed until end of the month
<Amaranth> mvo: compiz 0.5.2 is out
<mvo> carlos: ok
<mvo> Amaranth: yeah!
<Amaranth> mvo: need to push hard for a compiz-fusion release now too :)
<mvo> Amaranth: indeed :)
<pitti> doko_: any idea about 130428? I hope it doesn't require a soname bump?
<ion_> I hope some player gets support for the compiz video plugin before gutsy gets frozen.
* StevenK watches the buildds run through his uploads.
<StevenK> ... except for sparc.
<Amaranth> ion_: Not looking likely
<Amaranth> ion_: Unless you'd like to volunteer?
<Amaranth> At this point it'd be easier to just use Xgl
<carlos> mvo: thanks
<pitti> Riddell: another tribe4 bug for you: bug 124068
<ubotu> Launchpad bug 124068 in kdepim "Akregator and Kontact File conflict" [Undecided,Incomplete]  https://launchpad.net/bugs/124068
<pitti> Riddell: congratulations :)
<RAOF> Amaranth: I really should look into a Gstreamer compiz-video output.  It shouldn't be *too* hard!
<StevenK> Yay. Eight of my nine uploads have built everywhere but sparc.
<cjwatson4> pitti: for amd64, you got up too early - you asked before the cron job fired
<cjwatson> pitti: i386 is stuck for some other reason, though
<doko_> pitti: looking
<pitti> cjwatson: but there are no images for yesterday either
<pitti> cjwatson: amd64 live today> I wonder what those 'Error in select()' is all about; is this apt?
<pitti> oh, dpkg
<ArneGoetje> pitti: not yet... I'm still examining the default font packages
<pitti> seb128: deb http://people.ubuntu.com/~pitti/tmp/dapper-langpack/ ./   -> new dapper langpacks for testing; they should be complete now
<seb128> pitti: ok, will give them a try
* pitti hugs seb128
* seb128 hugs pitti back
* pitti tries the German ones
<seb128> pitti: I commited the seeds changed for consolekit, fast-user-switch-applet and tracker
<pitti> seb128: oh, good
<pitti> I was just about to ask you when I can update *-meta
<mvo> pitti: yes, that is apt
<mvo> pitti: where have you seen this?
<cjwatson> pitti: wow, no idea
<cjwatson> mvo: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/20070806/livecd-20070806-amd64.out
<pitti> efs-build-logs/gutsy/ubuntu/20070806/livecd-20070806-amd64.out
<pitti> oops
<asac> stgraber: yt?
<mvo> geeeh
<seb128> pitti: I did merge with kubuntu, etc though because I'm not sure if the language pack changes apply to the other distros also
<seb128> s/did/didn't
<mvo> pitti, cjwatson: I check this out, also it should not make the thing fail
<pitti> seb128: langpack changes don't
<stgraber> asac: yep
<asac> stgraber: cool
<asac> stgraber: well ... i see these wpasupplicant issues even with last tribe nm
<asac> stgraber: e.g. the failure to connect to wpasupplicant
<asac> stgraber: are you sure that this doesn't happen for you with current gutsy versions?
<stgraber> asac: Let me reinstall gutsy NM (I previously used a Live CD for testing) and I give you the result in a minute
<asac> stgraber: point is that you might not see that message becase wpasupplicant is not started verbose in current gutsy version
<asac> stgraber: but i definitly see that i cannot send commands to wpasupplicant
<asac> on every second run
<asac> stgraber: thanks
<pitti> cjwatson: I do a test install of alternate/amd64 (without network); it asks me about a mirror now and (naturally) fails to connect to it; that didn't happen in the past
<stgraber> asac: ok, indeed I don't see the supplicant error message but the disconection seems to happen anyway
<stgraber> asac: I just had NM to switch from connecting to disconnected without any real reason
<mikmor2> cjwatson: Hello
<asac> stgraber: he?
<asac> stgraber: i see this issue when i try to connect ... not when i am already connected
<asac> stgraber: e.g. every second connect wpa supplicant fails to start
<stgraber> NM was trying to connect to my wifi network, then suddenly switched to disconnected
<asac> ah ok
<asac> that might be the issue
<asac> ok
<asac> now it would be interesting to see if wpasupplicant 0.5.8 is better
<asac> but i will try that for now :)
<asac> will let you know if i see improvements
<stgraber> my current NM doesn't seem to have this issue as I have added a sleep(2) right after the disconnect from the network (the ipw3945 hack) (I've put that here so I didn't have to write another patch :))
<cjwatson> pitti: I don't think anything's changed there ...
<cjwatson> mikmor2: hi
<stgraber> but adding sleep() everywhere is not really a good idea imo :)
<asac> stgraber: where exactly? i tried multiple places for that sleep
<cjwatson> pitti: if it's *asking*, sounds like the CD's screwed
<cjwatson> pitti: it shouldn't ask if /cdrom/.disk/base_installable exists
<asac> stgraber: can you make a bzr diff or something and paste?
<cjwatson> oh
<mikmor2> cjwatson: Do you mind if I PM you?
<stgraber> asac: 41d just before the nm_dev_sock_close(sk);
<cjwatson> mikmor2: not at all
<cjwatson> pitti: let me get IS to install debootstrap on antimony ...
<stgraber> asac: but I think it could be better placed :)
<pitti> cjwatson: base_components exists, but not base_installable
<cjwatson> pitti: yeah, it's 'cos debootstrap isn't installed
<pitti> ah
<mikmor2> hmm.. for some reason messaging isn't working
<pitti> cjwatson: is it worth filing a bug about that still?
<asac> stgraber: before sock_close ... interesting
<cjwatson> pitti: no
<asac> stgraber: can you try if *after* sock close helps as well?
<cjwatson> pitti: I've filed an RT request
<pitti> thanks
<pitti> wow, the "broken X" text dialog boxes don't have a hideously broken frame any more
<stgraber> asac: building the deb
<asac> stgraber: thx
<seb128> pitti: weird
<seb128> pitti: bryce sent me a gdm patch for that but I didn't upload it yet
<pitti> seb128: for what?
<seb128> pitti: " wow, the "broken X" text dialog boxes don't have a hideously broken frame any more"
<pitti> seb128: ah; maybe the latest xorg merge?
<pitti> seb128: the live fs is from Aug 04 (it failed to build later)
<pitti> seb128: so it still has the broken dexconf, so I could see it :)
<seb128> well, I've a gdm patch to apply, dunno what to do with it now :p
<pitti> seb128: can you test it locally without your patch? just damage xorg.conf somewhat and restart gdm?
<pitti> well, I can do it, too, if you want me to
<pitti> I just saw it on the live system
<seb128> pitti: yes, will do in a bit, I don't want to close my desktop session now
<pitti> right, here too (test install running)
<stgraber> asac: Seems to be working as well (I tried to connect 3-4 times from a network to another and was unable to make it disconnects)
<asac> hmm
<pitti> seb128: hm, not sure whether tracker and f-u-s-a make sense for edubuntu... ogra?
<seb128> pitti: I would say they are not required no
<pitti> seb128: ok, droping those changes on the edubuntu merge
<pitti> seb128: just tried the "failed X" case in a fresh gutsy desktop CD install; looks fine
<pitti> ok, all seeds merged
<seb128> ok
<seb128> I'll ask bryce about the patch then
<pitti> RuntimeError: Command failed with exit status 768:
<pitti>   'bzr checkout /home/jr/src/seeds/edubuntu-kde-meta/edubuntu.gutsy/ /tmp/germinate-jHthiF/checkout'
<pitti> Riddell: ... :)
* pitti waves to slomo
<slomo> hi pitti :)
<ogra> pitti, f-u-s-a ?
<ogra> morning
<pitti> ogra: fast-user-switch-applet
<pitti> hey ogra, good morning
<ogra> ah
<pitti> ogra: I didn't add it to your seeds for now (neither tracker, I guess that'd kill your poor thin clients)
<ogra> pitti, i was planning to fix the udeb today, but some other breakage showed up, i have to fis that first
<pitti> ogra: ok for me to upload an up to date edubuntu-meta? changes look reasonable
<ogra> looks somewhat like an apt breakage
<ogra> sure
<ogra> Vorkonfiguration der Pakete ...
<ogra> openpty failed
<ogra> Error in select()
<ogra>                  Whle vormals abgewhltes Paket x11-common.
<pitti> ogra: right, we saw that already on live cd build
<pitti> ogra: mvo is taking a look
<ogra> thats what i see ... with a new chroot it shows up in a different place
<ogra> ah, k
<mvo> ogra: does it break anything? or just pollute the world with this message
<pitti> mvo: eventually dpkg bails out on the amd64 live fs log
<ogra> mvo, it breaks my thin client builds
<mvo> pitti, ogra: have you seen it on your regular systems as well? or only when livefs building?
<pitti> mvo: I never saw it here, but I did my last few upgrades with u-m
<pitti> a mere apt-get install <some packages> works fine here
<ogra> mvo,only when thin client building
* pitti tries to debootstrap a current gutsy
<ogra> mvo, (chroot install)
<ogra> http://paste.ubuntu-nl.org/32735/
<ogra> thats the end of a ltsp build process atm
<ogra> (sorry, localized)
<mvo> ogra: cool, what command do I have to run to trigger it?
<pitti> mvo: hmm, a simple gutsy debootstrap works fine here
<pitti> mvo: that's in a gutsy chroot on ronne, though
<ogra> mvo, ltsp-buil-client ... but thats after about 20min .... after the chroot built, and the script chrooted into it to install the client stuff
<ogra> *ltsp-build-client
<mvo> pitti: if I can reproduce with ogras commands, I will be happy
<ogra> we divert start-stop-daemon ... i guess thats something the livefs scripts do as well ...
* ogra looks for similarities
<mvo> ogra: can you pinpoint what command is run when it fails? or it it the same apt-get run that worked earlier?
<mvo> pitti: I wonder if it might have something todo with the amount of packages being installed? assuming a livefs build is big?
<ogra> it worked last on aug 2nd for me ...
* mvo tested it with a stock feisty->gutsy upgrade before uploading and that went fine
<ogra> i can disg up the command, wait a min
<pitti> mvo: hm, right
<mvo> ogra: I merged new code that generates log files from the dpkg runs for better apport integration, I know what code is causing the issue, I just do not know why :) or how to reproduce it
<pitti> mvo: the actual debootstrap part in the livefs build log is fine
<cjwatson> ogra: debootstrap doesn't actually divert it, but it does move it aside
<mvo> ha! fdleak or something, I bet
<mvo> or on /dev/pts in the chroot?
<pitti> mvo: that's the first thing where it breaks:
<cjwatson> livecd.sh diverts invoke-rc.d
<pitti> Preconfiguring packages ...
<pitti> FATAL: Could not load /lib/modules/2.6.15.7/modules.dep: No such file or directory
<pitti> Fetched 575MB in 1m5s (8769kB/s)
<pitti> openpty failed
<pitti> Error in select()
<pitti> Selecting previously deselected package diveintopython.
<pitti> (Reading database ... 10152 files and directories currently installed.)
<pitti> Unpacking diveintopython (from .../diveintopython_5.4-2ubuntu2_all.deb) ...
<pitti> Error in select()
<ogra> cjwatson, ltsp-build-client diverts it
<cjwatson> pitti: debootstrap doesn't use apt, so if it's an apt problem then debootstrap won't trigger it
<ogra> mvo, chroot $ROOT apt-get $APT_GET_OPTS install $LATE_PACKAGES
<mvo> openpty() is the bummer here
<pitti> cjwatson: oh, I thought it would use it for stage 2?
<ogra> mvo, export APT_GET_OPTS="$APT_GET_OPTS -o Acquire::gpgv::Options::=--ignore-time-conflict"
<mvo> ogra: do you have /dev/pts in your chroot?
<cjwatson> pitti: no, it's already got the logic to do everything with dpkg for stage 1 so it might as well just use it for stage 2 as well
<pitti> ah, I see
<cjwatson> since, well, that's the easy bit
* pitti tries to apt-get install some packages into his chroot
<ogra> mvo, nope
<mvo> ogra: if you still can reproduce it, could you pleae try to mount /dev/pts and see if that fixes the issue?
<mvo> I will add code so that failing in openpty() will work gracefully, I just want to confirm that this is the actual problem
<ogra> root@laptop:/# apt-get -f install
<ogra> Paketlisten werden gelesen... Fertig
<ogra> Abhngigkeitsbaum wird aufgebaut... Fertig
<ogra> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
<ogra> 3 nicht vollstndig installiert oder entfernt.
<ogra> Es mssen 0B Archive geholt werden.
<ogra> Nach dem Auspacken werden 0B Plattenplatz zustzlich benutzt.
<ogra> openpty failed
<ogra> Error in select()
<ogra>                  Error in select()
<ogra>                                   Error in select()
<ogra>                                                    E: Sub-process /usr/bin/dpkg returned an error code (1)
<ogra> root@laptop:/#
<ogra> still reproducable
* ogra mounts /dev/pty
<mvo> ogra: that is with mounted /dev/pts?
<mvo> aha
<mvo> :)
<ogra> root@laptop:/# mount -t proc proc /proc
<ogra> root@laptop:/# /etc/init.d/mountdevsubfs.sh start
<ogra> root@laptop:/# apt-get -f install
<ogra> Paketlisten werden gelesen... Fertig
<ogra> Abhngigkeitsbaum wird aufgebaut... Fertig
<ogra> 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
<ogra> root@laptop:/#
<ogra> mvo, ^^^
<mvo> ogra: so that works? good. I will fix the code now, thanks a lot for reproducing!
<ogra> :)
<asac> stgraber: do you see issues with connecting to unencrypted net as well?
<stgraber> asac: yes, sometimes it simply can't :)
<stgraber> asac: like trying to connect but never succeeds
<stgraber> and there doesn't seem to have any kind of timeout
<doko_> pitti: it does, but adding a compatibility function seems to work as well
<pitti> doko: that would be great
<asac> stgraber: so it even fails with iwconfig only?
<coNP> May I ask some core-dev to review/sponsor my magyarispell (Hungarian spell checker) update (0.99 -> 1.2) at http://revu.tauware.de/details.py?upid=6332?
<asac> stgraber: maybe the same workaround helps? e.g. explicitly unsetting essid first?
<seb128> coNP: subscribe the ubuntu-main-sponsor team and wait for somebody to upload ;)
<coNP> Sure, thanks :)
<stgraber> asac: nope, iwconfig+dhclient3 works
<stgraber> asac: looks like NM doesn't detect when it's correctly associated and then never runs dhclient ...
<pitti> mhb: what is data/kcm-fix.patch all about?
<pitti> mhb: applying this in setup.py is rather evil (unexpected in the first place, and not idempotent)
<asac> stgraber: hmm
<asac> stgraber: btw, what dbus version do you use?
<pitti> mhb: oh, I see now; gosh, that's evil
<stgraber> asac: 1.1.1-3ubuntu1
<mhb> pitti: fixes in .py templates that cannot be done in designer
<pitti> ImportError: No module named pyqtconfig
<pitti> make: *** [python-build-stamp-2.5]  Fehler 1
<pitti> mhb: ^ seems it's missing a build dep; /me tries python-qt4
<pitti> mhb: not in python-qt4-dev either
<mhb> ./python-qt3.list:/usr/lib/python2.5/site-packages/pyqtconfig.py
<pitti> mhb: erk, why qt3?
<pitti> mhb: thanks, adding that
<mhb> pitti: lots of reasons, mainly because python-kde4 doesn't exist yet
<geser> ./usr/lib/python2.5/site-packages/PyQt4/pyqtconfig.py is in python-qt4-dev
<pitti> mhb: ah, that helped a bit; now it fails with
<pitti> running build_kcm
<pitti> Failed to find the PyKDE directory: /usr/lib/python2.5/site-packages
<StevenK> Hrm. I think the sparc buildds currently hate life.
<pitti> mhb: maybe you can try to build this in a pbuilder and do the necessary fixes?
<mhb> pitti: I'm pretty sure python-kde3-dev was a buil-dep
<Riddell> you'll need python-kde3-dev
<pitti> I have that, it's a b-dep
<Riddell> and pykdeextensions and libpythonize0-dev
<pitti> I have both, too
<StevenK> I take that back, it seems artigas currently hates life.
<highvoltage> hey Burgundavia
<pitti> mhb: also, could you make RestrictedManagerCommon.runme_as_root() abstract? (I. e. raise NotImplementedError, 'this method must be implemented by a concrete subclass')
<Burgundavia> hey highvoltage
<pitti> mhb: having it default to sudo is prone to provoke a program hang
<infinity> StevenK: What's artigas doing?
<pitti> mhb: and clean leaves some autogenerated files behind
<mhb> pitti: okay ... but I still can't understand your PyKDE error, if you have python-kde3-dev installed
<StevenK> infinity: Nothing, which is the problem. It's been Idle (AUTO) all day.
<infinity> StevenK: Fixed.
<StevenK> infinity: Thanks!
<StevenK> Gah, and artigas immeadiately grabs gcc-4.1.
<pitti> seb128: German dapper update langpacks look good here (also debdiff)
<mhb> pitti: I've fixed the setup.py file to clean up after itself and the runme_as_root() class, too. Should I also include some new deps or build-deps before I commit?
<pitti> mhb: commit those fixes separately, please (that's always better)
<asac> stgraber: i pushed a few new revisions that hopefully address your issues out of the box now ... would be great if you could test one more time before i upload to gutsy :)
<pitti> mhb: fixing the build deps would be appreciated, otherwise I cannot even build and test it
<mhb> pitti: I'll try to, but I don't know much about pbuilder
<Amaranth> pitti: only starting compiz on :0 breaks Xgl
<Amaranth> Well, I suppose you could add that check only if you know the user isn't using Xgl..
<pitti> mhb: I'm also happy to assist you with debugging that build error
<pitti> Amaranth: I don't understand
<Amaranth> pitti: Xgl is :1
<pitti> Amaranth: oh, and no :0?
<Amaranth> :0 is Xorg
<Amaranth> well, except sometimes Xgl is :0 and Xorg is :63 or some other high random number
<pitti> Amaranth: ah, I was confused; Xgl, not aiglx
<Amaranth> depends on how you start Xgl
<keyes> hello
<SynrG> good morning
<keyes> is there a way to get the /dev/DEVICENAME using the device ID (st_dev) getted by stat() ?
<mhb> pitti: splendid! could you give me advice on how to reproduce them?
<pitti> mhb: I just installed python-qt3-dev, as advised, and tried to build the package
<pitti> mhb: this is current gutsy
<StevenK> pitti: Would you mind promoting libquicktime1 (binary) to main?
<pitti> StevenK: oh, 0 was in main; my bad
<pitti> StevenK: done
<stgraber> asac: building, will be ready after lunch
<Amaranth> mhb: build in pbuilder, it'll show you all your build issues
<StevenK> pitti: I looked at the build failure of kino for 2 minutes going "Uhhh? pitti NEWed it, it should work fine", until it twigged.
<StevenK> pitti: Thanks. :-)
<asac> stgraber: thanks!
<StevenK> pitti: That needs a publisher run before the buildds get at it, right?
<pitti> StevenK: yes, it does
<StevenK> pitti: Okay, I'll bug you in about an hour for a give-back.
<pitti> StevenK: splendid
<cjwatson> keyes: no - there are major() and minor() macros in <sys/sysmacros.h> to unpack st_dev, but to find the node you have to opendir("/dev"), readdir(), stat() each one, and compare
<keyes> ok
<keyes> so I must use major(), minor() and parse /proc/partitions ?
<StevenK> pitti: It looks like db3 has been killed in Debian, do you think we should follow suit?
<StevenK> pitti: (If so, happy to file another removal bug)
<pitti> StevenK: hm, we still have ~ 50 reverse dependencies
<pitti> StevenK: I'd rather not break all of those packages
<StevenK> Hrm. When is UVF?
<StevenK> Two weeks, or so?
<Fujitsu> 16th?
<pitti> yep
<StevenK> Ten days. Good enough.
<StevenK> pitti: Okay, I think I'll revisit it in a week, which should give Debian time to hopefully sort out most of them.
<Fujitsu> Hah, like that'll happen.
<StevenK> Why not? It did with removing libdb3 Build-Depends.
<pitti> StevenK: that might be ubuntu specific
<pitti> StevenK: a lot of those reverse dependencies are probably due to libtool .la stuff and such; there are no reverse build deps left
<pitti> -Wl,--as-needed FTW :)
<pitti> StevenK: so I guess most of those deps should ideally go away entirely (in Debian as well)
<StevenK> pitti: Yeah, but I seriously doubt that can be scripted, and doing monkey work for 50 packages doesn't appeal.
<pitti> right
<pitti> StevenK: mere no-change rebuilds should do it as well, though
<pitti> StevenK: btw, do you use a script for mass rebuilds?
<StevenK> Yup.
<pitti> (/me uses http://people.ubuntu.com/~pitti/scripts/update-maintainer-transition)
<StevenK> Oh, I wrote my own. :-)
<StevenK> pitti: I'm happy to take say, half of them and mass-rebuild them and see if the rdepends of libdb3 drop.
<pitti> StevenK: just try it with three samples locally and check afterwards, or so?
<StevenK> Sounds fine.
<pitti> or, wait
<pitti> StevenK: you could look up some samples in checklib output
<StevenK> You and your checklib. :-)
<pitti> it's not mine )
<pitti> :)
<pitti> but it's a great tool
<StevenK> pitti: Apropos absolutely nothing, the NBS output for libmpfr1 is confusing me.
<StevenK> -- gutsy/main i386 deps on libmpfr1:
<StevenK> libmpfr1
<pitti> heh, that package has a self-dependency
<StevenK> Oh, it doesn't?
<pitti> $ acsh libmpfr1|egrep '^(Package|Depends)'
<pitti> Package: libmpfr1
<pitti> Depends: libmpfr1 (= 2.3.0~rc1.dfsg.1-1ubuntu1)
<StevenK> ARGH
<Fujitsu> Wahah.
<Fujitsu> *Bwahah
<StevenK> Who is this Laurent Fousse guy? I'll kill him myself.
<StevenK> And the only reason that installs is because dpkg breaks the circular dependancy and deals. Sigh.
<StevenK> pitti: It gets better. Read the long Description.
<Amaranth> i take it that's not really a transitional package?
<StevenK> Uncertain.
<Fujitsu> A transitional package that depends only on itself... wtf?
<StevenK> I think the Maintainer/Uploader was aiming for libmpfr1ldbl
<Fujitsu> ... but they missed.
<StevenK> So it would seem.
<StevenK> pitti: My script doesn't touch the Maintainer field, only adds changelog entry, rebuilds the source and generates a changes file.
<pitti> StevenK: libmpfr1ldbl doesn't Provide: libmpfr1, though (and shouldn't either), so there are two rebuilds left AFAICS
<pitti> StevenK: yeah, that sounds fine (I have a function for that case, too)
<Amaranth> oh, are we getting rid of this package?
<pitti> Amaranth: sure
<Amaranth> phew :)
<StevenK> pitti: Three.
<pitti> StevenK: 'k, I'll try to drop my error margin below 50% in the future :-P
* StevenK chuckles.
* StevenK hugs pitti 
<pitti> iwj: do you have some time to look at bug 63175? it's marked for tribe4, but mvo is currently overloaded fixing an apt bug and some compiz bugs
<ubotu> Launchpad bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Incomplete]  https://launchpad.net/bugs/63175
<StevenK> OUCH!
<StevenK> The cell-gcc source package is ~ 50Mb
<StevenK> pitti: Since I don't listen, can you paste me the link to checklib?
<StevenK> Found it.
<pitti> StevenK: I checked some samples there, they are not mentioned, hmm
<StevenK> pitti: I've just looked at three. I think one of those pulls in libdb3...
<StevenK> terraform looks to be the odd one out of the three I checked, it has a direct dependancy.
<stgraber> asac: Those last changes seem to be fine, I just have some problem connecting to my Open wireless AP, but it's a Fonera running on the same chan as my main wireless AP, I'll just connect to it (ssh) remove the second AP it generates (keep only the public one) and put it on another chan and retest with NM
<asac> stgraber: does it fix open network scenario as well?
<stgraber> asac: Just let me put that AP on another chan and test it again
<StevenK> pitti: It looks to be sort of easily scriptable to pull down the log for checklib. I'll ponder doing that while I deal with mfpr cruft.
<iwj> pitti: Let me have a look.
<StevenK> pitti: Sigh. It isn't, since the versions checked by checklib aren't consistent.
<iwj> pitti: This doesn't look straightforward.  I'm worried by the fact that Scott is saying the system clock is set from the hardware clock by udev now.
<mhb> pitti: I managed to build it using pbuilder. Your errors were actually a sign of bad dependencies of python-kde3-dev.
<iwj> How do we make sure it's set by the time the fsck runs ?
<stgraber> asac: Open network doesn't seem to be working better than before (I see it associated with iwconfig but NM still tries to connect (no green light))
<elmo> hey, if I upgrade to gutsy, will I get working projector support for a radeon (free ATI driver) based laptop?
<mhb> pitti: I've commited the fix now, feel free to test the pbuilder
<stgraber> asac: just did one more test, it doesn't connect if it's already associated and then you try to connect (the driver seems to auto-associate on public network)
<stgraber> asac: but it connects if you are connected to another network (my WPA one in my case) and then you switch to it
<asac> stgraber: well ... ok ... its a bit wierd though as we now unassociate in stage1 for everyone
<asac> e.g. not only ipw3945
<asac> but lets see if that is really true
<asac> stgraber: do you see nm_info ("%s: About to SET IWESSID.", iface); ... in log ?
<asac> on initial connect
<stgraber> asac: http://paste.stgraber.org/2369
<mjg59> elmo: Gutsy currently has no improvements in that area
<mjg59> elmo: There's a driver that should support that, but we're not currently shipping it
<asac> stgraber: but the wpa case works now always?
<stgraber> yes
<stgraber> takes some time but works
<asac> how long?
<asac> stgraber: so with open network it now only fails on initial try?
<stgraber> asac: 10s till first green light, 5 more seconds to receive IP
<asac> and feisty?
<asac> do you still see those 00:00:00 ... events?
<asac> stgraber: ^^ ?
<StevenK> pitti: Can you give-back kino on all arches, please?
<stgraber> asac: iirc it was a bit faster to have the first green light (looking at a watch -n1 iwconfig eth1, it seems it tries to associate once, then reset and re-associate)
<stgraber> asac: no, I don't seem to have those 00:00:00 things any longer, otherwise connect time would be >40s
<stgraber> asac: for the open network I'm not still sure it's not AP-related, this AP really seems crappy, I'll boot another one for testing
<asac> stgraber: thanks a lot
<pitti> iwj: I noticed that my own system fsck's on every boot, too, but I haven't looked into it
<pitti> mhb: splendid, pulling
<pitti> iwj: if it's too hairy, then I'm fine with moving off to Tribe 5
<pitti> StevenK: given back
<pitti> mhb: oh, that actually seems to be a real bug in python-kde3-dev then
* pitti installs half of KDE now
<mhb> pitti: yes, I'm sorting it out with Riddell
<iwj> pitti: TBH I don't have a great deal of time right now to look into it.  I'm trying to get triggers done by FF.
<pitti> iwj: right, that's fine; thanks
<iwj> pitti: Good luck :-).
<stgraber> ethernet (not associated) -> open wifi == OK
<stgraber> ethernet (associated with open wifi) -> open wifi == NOT WORKING (associated but not connecting)
<stgraber> wifi (associated with other wifi) -> open wifi == NOT WORKING (unassociated, then reconnect to previous WiFi)
<stgraber> open wifi -> open wifi == OK
<stgraber> asac: ^
<StevenK> pitti: Thanks!
<stgraber> asac: for wifi (associated with other wifi) -> open wifi, it disconnects from the first wifi (I see it unassociated with iwconfig) but never connects to the open ne
<stgraber> s/open ne/open one/
* StevenK watches the i386, amd64, ia64 and powerpc buildds fall over themselves to build kino.
<mjg59> stgraber: The adapter never connects, or n-m never connects?
<pitti> mhb: still leaves behind install_log.txt, but builds fine now \o/; thanks
<stgraber> mjg59: adapter (deassociate and never try to associate with the new one)
<mjg59> stgraber: iwconfig shows what when it's in this state?
<stgraber> mjg59: as it doesn't se the essid nor the bssid I think the problem is NM
<stgraber> eth1      unassociated  ESSID:off/any Mode:Managed  Frequency=2.412 GHz  Access Point: Not-Associated
<mjg59> Yes, ok
<mjg59> That does sound more like an n-m problem
<StevenK> doko: I'm going to do a upload of gjdoc, pdftk, postgresql-pljava and trang to clean up the rest of the rdepends on libgcj8-0.
<doko> StevenK: not gjdoc please, please have a look why postgresql-pljava isn't linked with -fjni -findirect-dispatch
<StevenK> doko: Sure.
<StevenK> doko: Also I'm looking at uploading cell-gcc for the libmpfr1 -> libmpfr1ldbl transition, does that sound okay?
<StevenK> Ah ha. gjdoc failed to build.
<doko> StevenK: no, will need updates anyway
<asac> stgraber: thats strange ... but trying a second time helps?
<StevenK> doko: Okay, I'll leave cell-gcc alone, and do the other two. Thanks.
<bbrazil> is dapper-updates meant to have build-deps outside of plain dapper? (gnome-panel/libgnomevfs2-dev)
<Fujitsu> bbrazil: -updates can b-d on -updates
<pitti> mhb: works fine here, and looks reasonable; good job!
<Fujitsu> And -security, probably.
<doko> StevenK: but you could look at libgcj7-1 rdeps and rebuild these
<bbrazil> Fujitsu: hmm, that's going to be fun. -security can't, so I had assumed -updates was the same
<mhb> pitti: thank you very much!
<cjwatson> -security can b-d on -security; -updates can b-d on -updates and (I think at the moment) -security
<cjwatson> bbrazil: -updates needs to be able to build-dep on -updates in order to be able to build updated versions of kernel modules when the kernel changes module ABI
<pitti> mhb: ok, so I'll upload this in a bit and guide through NEW
<bbrazil> cjwatson: well, I needed to add a chroot to our build system at some point...
<pitti> mhb: I want to look into implementing something else, though, and maybe have you here for some questions
<mhb> pitti: okay
<pitti> mhb: hm, RMClean doesn't care for that install_log.txt; can you please have a look into that?
<StevenK> pitti: genius and gretl uploaded, which is about 40% of the libgcj8-0 rdepends.
<mhb> pitti: yes
<pitti> mhb: I pushed trunk, please pull or merge from it first before doing further changes
<mhb> pitti: why did you remove the RMClean() class from setup.py?
<stgraber> asac: sorry, I need to leave for a good part of the afternoon, will be there tonight
<asac> stgraber: no problem ... thanks
<spike> hi
<pitti> mhb: erm, did I?
<spike> even if I've played with it for a while partman still confuses me terribly. I'm using the example-preseed from feisty, I have 2 disks showing up as sda and sdb, trying to write a custom recipe to get a simple /root partition on sda and then the rest of sda and sdb in lvm
<pitti> mhb: I only removed the old commented setup() stuff
<pitti> mhb: oh argh, must have accidentally killed it
<pitti> mhb: let me fix this
<spike> even in the debian-installer documentation a single disk is referred, no examples as to how using it for 2 disks
<pitti> mhb: btw, can you please try to use some empty lines between functions, too?
<mhb> pitti: okay
<spike> and the expert recipe itself doesnt mention a disk, only partitions, so how could one tell it to create an lvm that spans two disks?
<pitti> mhb: pushed
<cjwatson> spike: unfortunately partman only supports automatically partitioning one disk at the moment
<cjwatson> (damn)
<cjwatson> and he blocks messages ... oh well
<iwj> GHODS this parser needs to be THROWN AWAY
<iwj> What was I thinking ?
<elmo> mjg59: thanks
* cjwatson radiates hate at test cycles involving one reboot per test
<cjwatson> never make me a kernel hacker
<mhb> pitti: added the newlines to my branch. install_log.txt gets removed trigerring debian/rules clean now.
<pitti> mhb: thanks
<mjg59> cjwatson: People who aren't hacking drivers tend to use uml or virtualisation...
* Hobbsee waves
<pitti> hey Hobbsee! *hug*
* Hobbsee hugs pitti back :D
<pitti> Hobbsee: do you have time to fix bug 119664? if not, who can we give that to?
<ubotu> Launchpad bug 119664 in kdepim "Kubuntu upgrade from Feisty to Gutsy failed due to conflicting file in kdepimlibs" [High,Confirmed]  https://launchpad.net/bugs/119664
<Hobbsee> pitti: erm....i should.  i think
<Riddell> erm
<Hobbsee> unless Riddell wants to
<Riddell> ok, it's not actually kdepimlibs
<Hobbsee> pitti: i've just got home from uni and work.  let me eat my dinner first :)
<Riddell> I can do it then
<Hobbsee> Riddell: that last one is because /usr/share/services/kontact/ is in kontact.install
<pitti> Hobbsee: sure, I didn't say "NOW!", just planning :)
<Hobbsee> pitti: :)
* StevenK grumbles in here.
<Hobbsee> pitti: this was why i said no to doing large amounts of RM for t4, btw.  i knew that with large amounts of uni work (which somehow didnt get done over the holidays), and work work, and uni, i'd have little time
<Hobbsee> StevenK: heh :)
<StevenK> Ah, pitti is the poor sod^W^Whappy person doing Tribe4?
<Hobbsee> StevenK: yeah, he's the head RM and such
<Hobbsee> StevenK: just remember.  killing people is illegal.
<StevenK> And against the CoC, etc...
<seb128> pitti: those dapper language packs look better, only libxine1.mo has been dropped now
<pitti> seb128: sure that it didn't just move from gnome to base or so?
<seb128> $ for package in *deb; do dpkg -c $package | grep xine; done
<seb128> $
<seb128> doesn't look like
<pitti> ./language-pack-gnome-fr-base/data/fr/LC_MESSAGES/libxine1.po
<pitti> seb128: ah, because it's broken
<seb128> $ dpkg -c language-pack-gnome-fr-base_1%3a6.06+20070803_all.deb | grep xine
<seb128> $
<pitti> libxine1.po:196: `msgid' and `msgstr' entries do not both end with '\n'
<Hobbsee> pitti: you're on crack.
* Hobbsee waits for the LP bug to load
<pitti> Hobbsee: ?
<Hobbsee> okay, just incorrect, not on crack, looking at this.
<Hobbsee> It would be great to fix this for Tribe 4, but I do not consider it a release blocker. On the Ubuntu CDs it works (because ooo-gnome is installed), and on Kubuntu it is not installed by default anyway, so it does not affect the Kubuntu CDs.
<Hobbsee> pitti: kubuntu *definetly* installs ooo.
<Hobbsee> koffice isnt mature enough yet
<pitti> Hobbsee: oh, what happened to koffice?
<pitti> Hobbsee: erk, then I was indeed on crack, sorry
<Hobbsee> hehe :)
<Hobbsee> pitti: unless we just add openoffice-gnome to the kubuntu seeds too....
<Hobbsee> seeing as it with both -kde and -gnome installed, it'll use the -kde one, it seems
<pitti> Hobbsee: that'd certainly pull in two tons of dependencies
<Hobbsee> pitti: i thought ooo had most of those
<Riddell> what's the issue here?
<pitti> Hobbsee: not libgnomevfs2-0 and libgconf2-4
<Hobbsee> pitti: ah right
<Hobbsee> Riddell: ooo not opening
<Hobbsee> Riddell: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/127944
<ubotu> Launchpad bug 127944 in openoffice.org "[gutsy] Open Office applications don't start " [High,Confirmed] 
<pygi> hello folks
<pygi> siretart, poke when you get time pls
* Hobbsee attempts to remember how to kill the sudo lock
<StevenK> It's under /var/lock, but requires root privs to kill.
<Hobbsee> nothing there.
<Hobbsee> oh, i see.
<Hobbsee> crud
<TheMuso> pitti: re bug 122024 I have meant to chace this up, but time hasn't allowed me to do so. I have removed the milestone for now.
<ubotu> Launchpad bug 122024 in casper "orca should automatically get started when braille is activated" [Medium,In progress]  https://launchpad.net/bugs/122024
<pitti> TheMuso: ah, thanks for the feedback;
<Hobbsee> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/130636 doesnt look so great...
<ubotu> Launchpad bug 130636 in sudo "[gusty]  [sudo command &]  shows password!" [Undecided,Confirmed] 
<Fujitsu> pitti: Why is apport treating main crashes as universe crashes wrt. team subscription?
<pitti> Fujitsu: it doesn't make a difference any more; it's all ubuntu-qa
<Fujitsu> pitti: Ah.
<Fujitsu> Hobbsee: Wouldn't backgrounding sudo have always done that?
<StevenK> Yup.
<Hobbsee> Fujitsu: well, yes.  i'm just surprised they let sudo be backgrounded at all
<Fujitsu> Not letting it be backgrounded is wrong.
<StevenK> Actually, I don't think you can stop it.
<StevenK> You get a SIGSTOP when you're backgrounded, I'm not sure if you can do anything in the interrupt handler to not be backgrounded.
<Fujitsu> StevenK: Well, & won't send a SIGSTOP...
<StevenK> I think that just changes fd 1 to a pipe
<iwj> StevenK: Err, no, surely.
<iwj> That is, you get SIGCONT when you're backgrounded.  You get SIGTSTP (not STOP) when you're ^Z'd.
<iwj> And SIGTSTP can be blocked, caught or ignored.
<StevenK> iwj: This is from memory, and it seems my memory is faultly
<iwj> Eg, vi uses a TSTP handler to put the terminal back into canonical mode and go back to the primary (rather than alternate) screen if appropriate and generally to leave things nice for you to interact with your shell.
<iwj> Let me look at 130636.
<iwj> Ah, yes.
<iwj> I will write to the bug to explain.
<stgraber> asac: finaly I'm back a bit earlier than expected :)
<asac> stgraber: cool
<asac> stgraber: i tried to assemble the most important patches to the core-dev branch
<asac> stgraber: can you give it a try if its good for you before i upload?
<asac> stgraber: hmm http appears not to update ... should be rev 45
<alex-weej> mvo: notification-daemon still segfaulting with the countdown - did you manage to make a release?
<asac> stgraber: ah ... now its synched: https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
<iwj> StevenK, Hobbsee: I've followed up.
<stgraber> asac: it's bzr getting
<mvo> alex-weej: no, sorry.
<alex-weej> mvo: as long as you haven't forgotten :P
<alex-weej> i was under the impression you had fixed it the other day, my mistake
<elmo>  /go cv
<mvo> alex-weej: no, sorry. I just had a look at it, but that was it
<alex-weej> ok
<Slim> hello
<stgraber> asac: bzr is sloooow ... :)
<Slim> some one help me to run Beryl
<pygi> Slim, #ubuntu pls
<stdin> Slim: this isn't a support channel
<Slim> ok
<norsetto> Slim: start with this: https://help.ubuntu.com/community/BerylOnFeisty
<Slim> norsetto : THANKS
<Hobbsee> iwj: cool, thanks
<iwj> Hobbsee: NP.  Note that there's no way to stop sudo being backgrounded.  It could ignore the TSTP but that would leave it fighting with your shell for your input.
<iwj> But I think it's probably sufficient for it at least not to print the prompt.
<Hobbsee> iwj: incidently, i only happened to learn about backgrounding tasks last year :-S
<Hobbsee> er, last week
<iwj> After all   sodo bash  lets you type your password into the shell too :-).
* Hobbsee nods
<Hobbsee> true that
<stgraber> asac: ouch, 15 minutes to get the code :), let's build it
<pitti> hi mathiaz
<mathiaz> hi pitti
<mathiaz> I've seen your comment for bug #130114
<ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,In progress]  https://launchpad.net/bugs/130114
<mathiaz> pitti: I'll prepare a debdiff to fix that.
<Company> siretart: how much do i have to bribe you to make you fix https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/122266 ?
<ubotu> Launchpad bug 122266 in ffmpeg "excess deprecation warnings" [Undecided,New] 
<pitti> mathiaz: oh, you can't build the source right out of your branch?
<pitti> mathiaz: (or trunk, rather)
<mathiaz> pitti: it depends which branch you're talking about, at which revision.
<mathiaz> pitti: from core-dev it should be build fine
<pitti> mathiaz: well, usually there is one branch 'trunk' (or similar) which represents the uploaded source packages
<mathiaz> pitti: from ubuntu-mathiaz the latest revision won't build as it contains the merge from upstream.
<pygi> Company, hello
<mathiaz> pitti: ok. ubuntu from ubuntu-core-dev then. that one should build.
<pitti> mathiaz: does that have the fix for that already?
<mathiaz> pitti: but my branch has more experimental stuff.
<pitti> I see
<mathiaz> pitti: yes.
<pygi> Company, I've been thinking of creating some swfdec0.5.1 packages for ubuntu in the coming days or so, since the last debian and us have right now it 0.4.5 if I'm not mistaken
<pygi> Company, 0.4.3*
<Company> pygi: the debian maintainer complains about unstable being broken all the time so he can't upload a new package
<pygi> Company, aha, oki .... just wait then.
<Company> pygi: other than that debian is pretty current
<mathiaz> pitti: if you could have a look at the changelog you'll see what is the state of my branch
<Company> pygi: don't ask me why ubuntu doesn't pull automatically
<mathiaz> pitti: https://code.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz
<Company> pygi: 0.4.5 is in unstable afaik
<pygi> Company, ok, we'll get it in :) Thanks ;)
<mathiaz> pitti: the fix for bug 130114 is in revision 496.
<ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,In progress]  https://launchpad.net/bugs/130114
<Company> pygi: i'm fine with having someone pushing it through the ubuntu package building process though
<Company> pygi: i like having people i can poke directly ;)
<pitti> mathiaz: ah, great; so I take this as 'plz sponsor'? :)
<mathiaz> pitti: hum... it's a bit more complicated.
<pygi> Company, well, I'm certainly interested in the packages. But if Debian will get it, I'm fine with fixing some stuff here if needed and when needed.
<stgraber> asac: WPA is fine (connecting and reconnecting works), I'm booting my open AP now
<pygi> Company, I did take a peek at the code lately (yesterday to be correct)
<mathiaz> pitti: in ubuntu from ubuntu-core-dev
<mathiaz> pitti: https://code.launchpad.net/~ubuntu-core-dev/apparmor/ubuntu
<mathiaz> pitti: there is only the debian/ directory.
<mathiaz> pitti: but in my branch the full tree is there, branched from upstream import.
<pygi> Company, I'm gonna work on the debdiff for the ffmepg bug you just posted now
<mathiaz> pitti: which all the dpacthes applied inline.
<mathiaz> pitti: so I was waiting for kees review
<Company> pygi: you should probably get in touch with ds (who does the debian packages) and/or danielk (who did its own packages for ubuntu once)
<mathiaz> pitti: so that he can update ubuntu-core-dev.
<mathiaz> pitti: I'm pretty confident that the move to complete bzr maintainance is correct.
<pitti> mathiaz: ok, it's fine for me to wait for kees; he should be back today, right?
<mathiaz> pitti: and then I've fixed a couple of new bugs and package a new library in my tree.
<mathiaz> pitti: correct. But I hope he'll have some time
<pygi> Company, let me first create this debdiff, then we'll talk :)
<pitti> mathiaz: ok, let's wait for him first and ask him
<mathiaz> pitti: beside that, we're trying to update the kernel module to the latest version of upstream.
<pitti> mathiaz: I plan to be around a while tonight
<Company> :)
<mathiaz> pitti: which means that we have to update the userspace part also
<stgraber> asac: automatic switch when removing ethernet work fine too, but open network doesn't work (same issue as I told you at the begining of the afternoon)
<mathiaz> pitti: I've already started doing that in my branch.
<stgraber> asac: so at least no regression from current gutsy
<pitti> mathiaz: ok, that sounds a little too intrusive for tribe4
<mathiaz> pitti: so I'd wait for kees and we may get the latest and greatest from AppArmor integrated by tomorrow
<pygi> Company, nice work btw ;)
<mathiaz> pitti: ok. Well - let's wait for kees and discuss that with him, and kyle.
<mathiaz> pitti: (for the kernel update)
<pitti> mathiaz: agreed
<asac> stgraber: did you find a way to assist network manager by manual actions in open network scenario?
<stgraber> asac: didn't really try, doing so now results in a minute
<stgraber> asac: setting up the essid by hand doesn't help, I'll try with setting the bssid (btw, I came across something weird (unable to stop connecting to open wlan))
<stgraber> asac: ok, kill switch and bssid doesn't help either
<stgraber> asac: http://paste.stgraber.org/2370
<asac> but retrying does help?
<stgraber> asac: I can't due to above bug
<asac> stgraber: maybe restart network manager
<stgraber> asac: the only way I have to stop NM to try connecting to the network is to killall it (/etc/dbus/event.d/25NetworkManager stop hangs)
<stgraber> asac: I do that before every test
<asac> oh
<asac> unload driver as well?
<stgraber> yep
<asac> hmm ... manually connecting works though?
<stgraber> yes, and NM can connect when going from LAN to Open WiFI
<stgraber> if the card didn't associate to it in the background
<asac> stgraber: do you use the same network id as before?
<asac> e.g. as in wpa setup?
<stgraber> Open Wifi is "test" and WPA is "graber-wifi"
<stgraber> so two different APs, channel and network name
<stgraber> (test is on chan 11 and graber-wifi on 1)
<stgraber> asac: my current test is : LAN -> Open WLAN (success) -> WPA WLAN (success) -> Open WLAN (fail, get stuck here)
<asac> stgraber: what do you see in log?
<asac> stgraber: what does iwconfig give you?
<stgraber> asac: I just did another test : LAN (with wireless associated to "test") -> test (doesn't connect but not stuck)
<stgraber> and if LAN is connected when doing : LAN -> Open WLAN -> WPA WLAN -> Open WLAN it simply fallbacks to LAN
<stgraber> instead of getting stuck connecting
<stgraber> (removing the LAN plug once connect to the WPA)
<stgraber> asac: when it's stuck iwconfig shows nothing, no essid, no bssid and not-associated
<Hobbsee> oh is this the "open networks with ipw3945 wont connect via the mangler?" bug?
<Amaranth> ha
<Amaranth> that's funny, i've had the exact opposite problem
<Amaranth> but i don't have time to debug it so i just changed the security on my network
<pitti> mvo: thanks for the apt fix
<mvo> pitti: cheers, looks like I need to fix something in the apport generation code soonish too, just discovered some problem there too, but I'm not yet sure if its me or LP (when trying to submit I get a OOPS from LP)
<Riddell> pitti: are you planning to merge/upload kde restricted-manager?
<pitti> Riddell: does your recent k3b upload happen to fix bug 123760? (since you touched/uploaded it anyway)
<ubotu> Launchpad bug 123760 in k3b "upgrade feisty to gutsy libk3b2 error" [Undecided,New]  https://launchpad.net/bugs/123760
<pitti> Riddell: yes, indeed I am
<pitti> Riddell: I was going to add another feature, but I'll upload it right now and do that later
<pitti> mhb: I'll add the missing Conflicts:/Replaces:, and upload
<mhb> pitti: okay, don't forget to merge the small commit I made a while back
<pitti> yep
<mhb> pitti: what is the feature you want to do for restricted-manager?
<pitti> mhb: https://wiki.ubuntu.com/RestrictedManagerImprovements point 1
<pitti> mhb: oh, and ${Source-Version} -> ${binary:Version}, fixing, too
<Riddell> pitti: it doesn't, but I can look at that
<mhb> pitti: the tray notification?
<pitti> mhb: yes
<pitti> mhb: ah, thanks for the fixes; I fixed s/rm/rm -f/, and merged
<mhb> pitti: I thought that's already implemented - there were classes for that (Notification), and a --check option.
<pitti> mhb: right, the tools are there, but not that behaviour
<pitti> mhb: right now, it tells you 'new restricted drivers in use'
<pitti> mhb: but not yet 'You can enable restricted drivers for more performance'
<pitti> mhb, Riddell: r-m pushed/uploaded
<pitti> mhb: please pull/merge
<mhb> pitti: oh, I thought that's what it meant to say ... well, we'll talk about it once you have some time, okay?
<pitti> Riddell: I'll be off for some hours to prepare for a nightshift; if you want this soon, please binary-NEW it in a bit
<Riddell> sure
<pitti> mhb: yes, let's
<LaserJock> what's the ETA on Tribe 4 Freeze?
<mhb> pitti: thank you for the push!
<pitti> mhb: I don't expect it to be difficult, if the abstract class is actually good, it shouldn't require any porting
<Riddell> "dch: you must have the liburi-perl package installed"  why don't we just have that as a depends?
<cjwatson> devscripts has a lot of scripts with a lot of different dependencies and apparently intentionally doesn't depend on all of them
<cjwatson> see its package description
<Riddell> seems to defeat the point of having a package manager
<StevenK> Riddell: Okay, so we add everything to Depends. This means gnuplot, debian-keyring and probably three or four other packages also get punted to main.
<StevenK> I don't know about you, but gnuplot for one is a pig, and I don't particularly want it installed, even if it does show pretty graphs.
<StevenK> And if we decide to promote a subset of dependancies to hard Depends, who's to decide which subset that is? It's a can of worms, and you can't please everybody, this way it annoys everyone equally.
<LaserJock> StevenK: well, if it helps at all, I'll probably be getting gnuplot into Main ;-)
<Hobbsee> LaserJock: run.  run now
<LaserJock> hehe
<StevenK> LaserJock: It doesn't, and bugger off. :-P
<LaserJock> ouch
<StevenK> LaserJock: I was picking on gnuplot because I knew it was in universe and it helps prove my point.
* LaserJock <3 gnuplot
<StevenK> What about R?
<LaserJock> I don't do much stats
<StevenK> Even if you don't, R's graphs kick ass
<LaserJock> my lab uses gnuplot and pgplot for graphing, that's pretty much it
<mvo> carlos: I uploaded new pots for ddtp, can you give me a hint where I find the import queue again to check if they are listed there already?
* Hobbsee hugs mvo in greeting
<mvo> hey Hobbsee!
<Hobbsee> :D
<carlos> mvo: https://translations.launchpad.net/translations/imports
<carlos> mvo: but I don't see your files...
<mvo> carlos: I uploaded them some minutes ago
<mhb> mvo: by the way, are ddtp translations imported correctly into gutsy? I haven't seen any Czech strings although my fellow translators did a handful
<carlos> mvo: did you get any email about your imports?
<mvo> mhb: I'm currently working on getting them in
<mhb> mvo: okay, great.
<mhb> thanks
<mvo> carlos: not yet
<carlos> mvo: are you completely sure your script worked?
<carlos> mvo: I don't see any trace of your upload
<carlos> and it should be there, even if the files are broken
<mathiaz> keescook: what's the plan to update apparmor ?
<keescook> mathiaz: waiting for kernel to include latest stuff.  kyle, was there an update already, or are the apparmor patches waiting until after this tribe?
<mvo> carlos: checking now
<carlos> ok
<mvo> carlos: no, looks like the authentication mechanism changed again
<carlos> mvo: :-(
<mvo> carlos: heh :) not the authentication, but the cookie name is different it seems, I investigate
<carlos> mvo: I think we had to change it a while ago to fix a problem with our authentication code
<mvo> carlos: yes, that was it
<carlos> mvo: yeah, I see it now
<carlos> mvo: so, was that encoding problem related with your files or a bug in Launchpad?
<mvo> carlos: not sure yet
<carlos> ok
<mvo> carlos: hrm, no, it looks like this is a encoding problem in the package description
<carlos> ok
<carlos> thanks for checking
<mvo> carlos: will it be enough to write the encoding in the header? everything in there should be utf-8
<carlos> mvo: so the .pot file content is UTF-8 but the .pot file header doesn't note it?
<mvo> carlos: yes
<carlos> mvo: in that case, yes, adding UTF-8 as the charset should be enough
<jwendell> Hi, seb128
<jwendell> seb128, a doubt: is tracker useful without tracker-search-tool package?
<ion_> jwendell: Yes.
<jwendell> ion_, how?
<mvo> carlos: if I upload new translations now (for ddtp from debian), rosetta will do the right thing? i.e. merge those with the ubuntu translations and not throw away any of them, right?
<ion_> jwendell: Programs can use tracker as a generic shared metadata database. The sooner they do that the better. In the meantime, tracker-utils contains command line clients for trackerd, which are also useful.
<jwendell> ion_, do you know any GNOME program which uses tracker?
<ion_> jwendell: Nautilus
<Amaranth> bingo
<Amaranth> nautilus can do it's saved search thing using tracker
<Amaranth> that's like the #1 use, i think
<ion_> Hopefully Nautilus, F-Spot etc. support shared tags in the future, using tracker as the backend. That would also fix some other things from the F-Spot TODO list for free, e.g. adding images automatically when they appear in the filesystem and tracking moved files.
<coNP> BTW, do you know if F-spot Picasaweb export has been recovered?
<jwendell> ion_, where is the nautilus option to use tracker?
<jwendell> ion_, i'm not finding
<Amaranth> jwendell: have to rebuild nautilus with a build-dep on tracker
<jwendell> hmm
<jwendell> i guess this is happen for gutsy, right, seb128 ?
<jwendell> s/is/will/
<coNP> c-f in theory, but works not for me
<jwendell> coNP, c-f?
<coNP> ctrl+f
<coNP> sorry /me tends to use emacs-style hotkey-abbreviations
<coNP> that is Go / Search for files
<carlos> mvo: if you upload a tarball in the template form, the new translations will be applied automatically, the changes will appear as suggestions
<jwendell> coNP, yep, i have tested that, but Amaranth said that nautilus has to be rebuilt with a specifc flag
<coNP> but it should work out of the box
<coNP> with our without tracker
<coNP> it is not nice that we have menu item that "does nothing"
<Amaranth> coNP: it does something
<Amaranth> coNP: just very slowly
<jwendell> yep
<Amaranth> coNP: and it only does filename matches, not file contents
<coNP> no dialog for me
<Amaranth> jwendell: no flag, just with a build-dep on libtracker-dev or whatever
<Amaranth> coNP: it replaces the path buttons
<Amaranth> or the location entry if you swing that way
<coNP> okay, but if I launch nautilus, open the dialog and nothing happens... that is not good
<Amaranth> what dialog?
<Amaranth> there is no dialog
<coNP> okay I noticed
<coNP> it replaces the file locator
<coNP> sorry :)
<jwendell> seb128, and tracker should live in main, not in universe, right?
<seb128> hi jwendell
<seb128> jwendell: tracker is un main already
<seb128> jwendell: not sure to understand your question
<Amaranth> it'd have to be or it couldn't be in ubuntu-desktop
<cjwatson> seb128:    tracker | 0.6.0-1ubuntu1 | gutsy/universe | i386, sparc
<cjwatson> somebody screwed up
<jwendell> seb128, apt-cache show tracker shows 'Section: universe/utils'
<cjwatson> I suggest change-override.py again ...
<seb128> cjwatson: I though pitti did promote consolekit, fast-user-switch-applet and tracker
<seb128> doing it now
<nekohayo> the tracker packages in gutsy's Main do not include translations, who should I be talking to? or what IRC channel?
<seb128> nekohayo: that's not a bug, translations are in language packs in Ubuntu
<cjwatson> nekohayo: they'll get into the language packs automatically some time after they're promoted properly to main
<cjwatson> may not happen instantly so don't worry right now
<nekohayo> is there a page explaining that whole concept of ubuntu's (time delayed) language packs? kind of confuses me :)
<Amaranth> nekohayo: that's development for you :)
<Amaranth> nekohayo: basically all packages in main have their translations stripped and we have big language pack packages instead
<Amaranth> because our translations are worked on on rosetta and it's easier to update one big pack
<nekohayo> Amaranth: well the thing that I was asking myself.... "wtf? installing a language pack installs ALL the translations of ALL the apps in Main?!"
<cjwatson> nekohayo: which isn't true ...
<cjwatson> they're split into base, gnome, and kde
<nekohayo> well that's what I don't understand :)
<Amaranth> nekohayo: Better than me getting translations for 50 languages I don't speak :)
<cjwatson> it's a compromise between package size and overwhelmingly enormous numbers of packages
<nekohayo> Amaranth: yeah I guessed that
<seb128> nekohayo: you could ask why installing an application bring you translations for 60 locales you don't use ;)
<cjwatson> lots of tiny packages would have a cost too, in terms of size of the package index files, memory use of dpkg, etc.
<coNP> Maybe we should start a language school... :)
<nekohayo> yeah, I kind of understand why packages are stripped, but I was puzzled as to how you did it
<nekohayo> as in, "do they apply black magic so that it installs the translations depending on what you have installed?"
<Amaranth> you choose your language in the installer :)
<cjwatson> no, we just have the installer install the appropriate language packs and then they get upgraded whenever there are new versions
<cjwatson> if you install KDE packages on top of a GNOME system, yes, you'd need to install language-pack-kde-$LL in order to get translations
<cjwatson> but it's enough of a corner case that we don't worry
<nekohayo> thanks for the explanation folks
<seb128> jwendell: where is the vino password stored when use gnome-keyring?
<seb128> use -> using
<jwendell> seb128, in the keyring ??
<seb128> jwendell: would changing from using gnome-keyring to not using would mean that users have to configure their password again?
<seb128> jwendell: which would not be acceptable ...
<nekohayo> oh, how often are the language packs updated/uploaded, typically?
<jwendell> seb128, it's stored in gconf, but...
<jwendell> i have to take a look....
<seb128> jwendell: would be nice, thanks, because we need to make sure they can still log-in if we change the backend
<jwendell> seb128, yep, users have to retype their passwords
<jwendell> seb128, unless they used to use older ubuntu version, which doesn't use keyring
<jwendell> seb128, so, the password is still on gconf
<seb128> jwendell: what old version? feisty is already using the keyring
<jwendell> nope
<seb128> ?
<jwendell> feisty doesn't use keyring...
<jwendell> DEB_CONFIGURE_EXTRA_FLAGS += --enable-avahi --enable-libnotify
<seb128> jwendell: http://launchpadlibrarian.net/6739390/buildlog_ubuntu-feisty-i386.vino_2.18.0-0ubuntu1_FULLYBUILT.txt.gz
<mvo> iwj: pitti asked earlier if you have some spare cycles to look at bug #63175 ?  did you reply to that one (and I missed it)?
<ubotu> Launchpad bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Incomplete]  https://launchpad.net/bugs/63175
<seb128> jwendell: it's linking with -lgnome-keyring, would be nice to have the configure display a summary of options though
<jwendell> seb128, yep, you're right
<jwendell> i'll do it for tomorrow
<seb128> thanks ;)
<coNP> What happened to gnome-keyring-cil? Where do we have this now?
<pitti>   ubuntu-desktop: Depends: fast-user-switch-applet but it is not installable
<pitti> elmo: Broken packages
<pitti> seb128: ^ hmm
<pitti> with the usual "E:' instead, of course
<seb128> pitti: is it in main?
<pitti> seb128: it's already past that stage on i386, I think (on terranova)
<pitti> just failed on king
<pitti> and it's not on gutsy_probs.html,
<seb128> pitti: dunno why, that's not enough informations
<seb128> can you try to apt-get install fast-user-switch-applet ?
<pitti> ast-user-switch-applet | 2.18.0-1ubuntu1 |         gutsy | source, i386, sparc
<pitti> fast-user-switch-applet | 2.18.0-1ubuntu1 | gutsy/universe | amd64, ia64, powerpc
<pitti> indeed
<pitti> how can that happen?
<seb128> dunno, that was the same for tracker
<seb128> I just ran the change-override again some minutes before you joined
<pitti> oh, it still is
<pitti> seb128: ah, good
<pitti> so, next publisher then
<LaserJock> did the netinstall .isos go somewhere? I can't find them anywhere
<Amaranth> didn't they used to be made with the debian-installer package?
<Mithrandir> keescook: apxs, apparmor> no, it's not a problem, I was just wondering why on earth apparmor needed apxs, but then, I didn't know about the apache module.
<LaserJock> Amaranth: like at build time?
<pitti> mhb: is there no way around having restricted-manager-kde be arch:any?
<Amaranth> LaserJock: well, i thought i found them in that dir anyway
<pitti> mhb: it's only Python, after all
<LaserJock> Amaranth: I don't see anything :/
<Riddell> mhb: it's also a plugin to kcontrol, which needs c++ wrapper
<mhb> pitti: it's not only python, it has to compile the bindings for system settings KCM
<Riddell> err, pitti that was for
<pitti> Riddell: ah, I see
<pitti> Riddell: did you already NEW restricted-manager? it's not in the queue and not in accepted
<pitti> Riddell: might be in-limbo publishing
<Riddell> pitti: I did
<Riddell> put the packages into restricted
<pitti> ok, so it's being published now
<pitti> Riddell: I'll trigger new CD images after that run
<Riddell> I'm updating kubuntu-meta to add it
<cjwatson> LaserJock: Amaranth is correct: http://archive.ubuntu.com/ubuntu/dists/gutsy/main/installer-i386/current/images/netboot/
* Amaranth was looking in the wrong place :0
<Amaranth> right idea, though
<mhb> pitti: what's the policy on adding new restricted drivers/firmware to restricted-manager? Is there a form for the users to fill, or is it "restricted" to the most used hw only?
<Amaranth> mhb: it's restricted to things that can be legally redistributed and have a real use
<Amaranth> real use meaning makes your computer usable
<wasabi> where 'usuable' is subjectively defined.
<Amaranth> well, yeah
<stdin> mhb: you'd have to talk to the kernel team too, the restricted manager is just a frontend to the modules that are in the linux-restricted-modules packages
<Amaranth> it's generally wireless and video
<pitti> mhb: you can add as many handlers as you wish, but it does not make sense at all to add actual firmware to it
<pitti> mhb: if we can redistribute firmware, we just do it in l-r-m, instead of writing complicated code around it :)
<mhb> pitti: yeah, I guess so. When I filed a bug about a piece of firmware that could be handy for a class of dvb-t adapters, nobody ever looked at it.
<mhb> so I'm wondering what the policy is.
<mhb> thanks for the answers, folks!
<pitti> mhb: that's just a question of bug triage capacity
<pitti> cjwatson: ah, alternate CD behaves now (u-desktop isn't installable, but it doesn't insist on a mirror any more); thanks
<jwendell> seb128, talking on keyring, every time when i need to type my ssh password, ssh-agent asks for it, but don't save it on keyring
<jwendell> since i updated to gutsy
<jwendell> is that an know issue?
<cjwatson> pitti: you're welcome
<cjwatson> pitti: still working on syslinux/gfxboot
<geser> jwendell: does ssh-add -l list your key?
<jwendell> geser, yep
<jwendell> geser, but it asked for my phrase
<jwendell> geser, and, in that dialog, the checkbox 'save on keyring' is not working
<seb128> jwendell: I think there is a bug about it
<jwendell> ah ok
<mathiaz> keescook, pitti: I've pushed a new version of apparmor package that fixes bug 130114.
<ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,In progress]  https://launchpad.net/bugs/130114
<mathiaz> keescook, pitti: https://code.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz-130114
<pitti> mathiaz: yay
<mathiaz> pitti, keescook: it only contains the fix for the bug. All the bzr merge, upstream update, etc... is not there.
<mathiaz> pitti, keescook: hum... forgot to commit...
<pitti> keescook: do you want to upload this, or shall I?
<mathiaz> pitti, keescook: I've fixed it. The branch has the fix.
<pitti> mathiaz: right, I mean uploading it
<pitti> mathiaz: and I guess keescook wants to merge it into the 'ubuntu' branch at the same time, to not diverge
<pitti> mathiaz: did you see keescook today already?
<pitti> mathiaz: works fine, thank you!
<pitti> mathiaz, keescook: I pulled ubuntu-mathiaz-130114 into ubuntu, released, uploaded, and pushed
<mathiaz> pitti: excellent - thanks.
<mathiaz> pitti: I had a talk with kees today.
<mathiaz> pitti: it seems that we won't have time to update to the latest version of apparmor for tribe-4.
<psusi> anyone familiar with, and care to discuss https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain?
<mathiaz> pitti: so we've decided to postpone it.
<mathiaz> pitti: and we've just released a new version to fix bug 130114
<ubotu> Launchpad bug 130114 in apparmor "#include files should be in apparmor itself" [Medium,Fix released]  https://launchpad.net/bugs/130114
<Riddell> calc: are you going to ask for a freeze exception for openoffice?
<calc> Riddell: not for the initial upload, but to let the final version in, yes
<calc> Riddell: i am hopefully doing the last test build before upload for m224 right now
<Riddell> well you have until pitti wakes up tomorrow to get it uploaded :)
<jwendell> seb128, http://svn.gnome.org/viewcvs/vino?view=revision&sortby=date&revision=643 ;)
<calc> Riddell: ok :)
<seb128> jwendell: that was quick ;)
<calc> Riddell: oh you mean for tribe-4 then?
<Riddell> calc: yes
<calc> Riddell: freeze doesn't happen until aug 16 iirc
<calc> but yea i want it in tribe-4 also
<seb128> calc: archive is frozen for tribe
<calc> oh i see
<seb128> calc: you should subscribe to ubuntu-devel-announce
<Riddell> it is?  u-d-a said tuesday
<LaserJock> yeah
<seb128> Riddell: no, I meant that the archive is frozen for every tribes
<infinity> Doesn't look very frozen to me. :P
<Riddell> right
<calc> seb128: thanks for reminding me about that freeze as well :)
<Riddell> hey, I reminded you first!  (just wasn't very clear about it)
* calc thought Riddell had meant the final freeze which is in ~ 10 days
<calc> Riddell: thank you as well :)
<Riddell> :)
<seb128> looks like I was not clear neither ;)
<calc> either way there isn't much time left, heh
<seb128> anyway, let's get some other crack in before the freeze
<infinity> calc: Best to get it in before the tribe freeze (so, now), than to wait post-tribe... Especially if it might not build on all arches, or have other problems that will take a while to hunt down.
<infinity> calc: "Upload early, upload often" being the Ubuntu release and debugging motto. :P
<pitti> seb128, calc: yeah, I'll freeze tomorrow morning (i. e. now plus some 12 hours)
<pitti> depending on how the archive status looks like, of course
<calc> pitti: ok
<calc> pitti: what would i need to do to get libsvg into main, just fill out a MIR?
<calc> i can do an internal build for now, but would be nice to use the one in the repo if possible
* keescook is back
<ajmitch> hello keescook
<keescook> mathiaz: did pitti just upload the fix?
<keescook> hiya ajmitch
<calc> keescook: will you be around later tonight? i should have a OOo upload ready before tomorrow morning
<keescook> calc: ooh, excellent.  yup, I'll be around.
<pitti> hi keescook
<mathiaz> keescook: yop
<keescook> hiya pitti!
<pitti> calc: yes
<keescook> pitti: nothing in CUPS is setuid, right?  It just is started as root?
<pitti> keescook: right
<pitti> keescook: it drops the backend privileges, though
<keescook> okay, cool.  I'm not suring using apparmor profile for a setuid tool can ever be safe, so I just wanted to make sure that wasn't true for cups
<keescook> s/suring/sure
<keescook> i should clarify: "can ever be safe" when starting outside of isolation
<pitti> keescook: ah, did you take a look at the profile?
<keescook> pitti: not yet, I want to do that, but thought I'd ask about my only serious concern.  :)
<pitti> keescook: there were some things which could be much tighter, but it would have taken me a lot of time
<pitti> keescook: also, I need to extend it a little bit for things like cups-pdf, which need to write into /home
<keescook> pitti: ew, really?
<keescook> why is that?
<pitti> keescook: well, that's its very nature
<pitti> keescook: it's a 'pdf file printer' backend
<pitti> keescook: i. e. anything you send to it will land as pdf in your home
<pitti> keescook: i. e. the more general solution of OO.o's "export pdf" button
<keescook> ugh, so the cups daemon writes to the user's dir instead of a client talking to the server?
<pitti> keescook: yeah :/
<keescook> but that part at least doesn't run as root?
<pitti> keescook: it starts as root
<pitti> keescook: I didn't look into its priv dropping
<pitti> keescook: ideally it would open and chown the fd, and then drop to the system user
<infinity> It needs to be able to change it's EUID to that of the user making the printing request, so it's got to be pretty rootish.
<pitti> ('lp')
<pitti> keescook: it's only in universe, but it's quite popular, and we even have a spec for it
<keescook> a print server should write to its queue or a printer -- not user's home directories!
<pitti> keescook: so I'd rather make it work halfway sane
<keescook> okay, sure.
<pitti> keescook: full ack, but what do you want to do? :-) "Ooh, PDF writer, *clickcklick* install *shiny*
<infinity> As broken as the design may be, it's incredibly useful. :/
<keescook> infinity: sure, I realize the utility of course.  I'm just amazed at the implementation.  :)
<pitti> keescook: problem is, there's nothing on the user's side which could listen for it and isn't confined to gnome/kde/etc/
<pitti> keescook: and, TBH, if it's done right, it doesn't need to be less secure than a client-server
<infinity> If the few lines of root-run code are just that -- a few lines.
<infinity> open fd, chown, drop privs.
<keescook> yeah, I can agree with that.
<pitti> (and take care not to stumble over symlinks and existing files etc.)
<infinity> Yeah.
<infinity> But all that should be an easily-auditable block before the big blinking "We're dropping privs now!" marker.
* pitti just wonders how it figures out the target uid
<infinity> Probably some very hackish guesswork. :/
<pitti> that's where the scary part comes in
<pitti> cupsd will call it with the uid, I figure
<infinity> Should look at it to see if it's spoofable.
* keescook is trying to stop from crying
<pitti> yay, the tribe 4 bug list just dropped below 20
<infinity> pitti: Are we keen on seeing that MySQL root user feature request (I refuse to call it a "bug") fixed for gutsy?
<Kmos> pitti: you are counting the bugs reported with "Gutsy" in title ?
<pitti> infinity: I am, very much
<infinity> pitti: If so, I think I might have to take some time and just write it myself.
<pitti> infinity: I just kept moving it from one tribe to the next so far
<infinity> pitti: Yeah, I noticed you retargetting it, which is why I asked. :)
<pitti> Kmos: no, https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=556
<pitti> infinity: it's not a Tribe4 blocker
<Kmos> pitti: ah.. ones with milestone set
<infinity> pitti: Apparently, it's a Tribe-5 blocker. :)
<pitti> and soren is on vac, so I didn't have much hope
<mvo_> pitti: FYIW I can not reproduce #107109 here
<infinity> pitti: After soren and I discussed it, the buck was passed to me/ch/seanius anyway.
<pitti> infinity: my optimism is infinite :)
<infinity> pitti: And ch is rapidly losing interest in Debian MySQL, so it's me or seanius... I have yet to discuss it with Sean.
<pitti> Kmos: erm, https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=471 of course
<pitti> mvo_: wow, you can get two X sessions with compiz on both?
<pitti> mvo_: last time I even attempted that, my entire screen went black, with no way whatsoever to recover (VT switching, blind typing, etc.)
<mvo_> pitti: no, but it fallsback to metacity just fine for me
<pitti> yay http://cdimage.ubuntu.com/daily-live/20070806.2/, live images!
* pitti hugs mvo for fixing apt
<fednube> are there any info on jailing users to uload, download and delete......... how easy is it tosetup ?
<infinity> fednube: -> #ubuntu
<mvo_> pitti: yeah!
* pitti cranks jigdo and rsync, and tests
<fednube> ok thx
<pitti> infinity: re mysql, I just wonder why it is so hard to do; in my naive thinking, this would be a ten line patch or so (but it probably requires mangling test suite, etc., too)
<cjwatson> woo, got gfxboot at least running, though now the theme crashes
<pitti> go, cjwatson, go!
<cjwatson> still, at least it's now a less hard problem
<Nafallo> pitti: will we have dvds in tribe4? :-)
<pitti> Nafallo: hm, ATM they are hopelessly oversized
<infinity> pitti: It's probably going to be a reasonably compact patch when done, sure, but it's the doing (and the making those 10 lines be the correct 10 lines) that takes some monkeys and typewriters. :P
<infinity> pitti: In other words, I (or someone) just need a tuit rounded.
<Nafallo> pitti: that's what I thought then :-P
<Nafallo> pitti: the question would be why... :-P
<pitti> Nafallo: main is too big :)
<Nafallo> pitti: throw useless stuff out then... exim4, courier etc... ;-)
<pitti> Nafallo: see, that's the problem; there's nothing where I could 'throw out' stuff
<pitti> there's no 'dvd' seed
<pitti> Nafallo: AFAIK, the DVD is either the union of all seeds, or entire main
<Nafallo> main -> universe? :-)
<Nafallo> the union of $dist-* I think?
<Nafallo> Riddell had some nice diagram the other day... :-)
<Nafallo> http://kubuntu.org/~jriddell/tmp/seeds.png
<Riddell> https://wiki.kubuntu.org/SeedManagement
<Nafallo> Riddell: aha. there is no dvd on your diagram :-P
<cjwatson> pitti: the DVD is built from the supported seed for the relevant flavour
<Riddell> as indicated in the diagram
<cjwatson> contrary to popular belief, it is not all of main
<pitti> cjwatson: ah, thanks
<Nafallo> Riddell: ah, right. just read the text... *blushes*
<cjwatson> the usual solution to the DVD being too big is to take some crap out of supported
<cjwatson> Extra-Exclude is useful
<Nafallo> so just throw stuff out of supported then... ;-)
<calc> need ubuntu bluray disk to hold all of main ;)
<pitti> cjwatson: so the trick would be to fan out some stuff in supported to the various seeds?
<Nafallo> exim4, courier etc... ;-)
<infinity> Nafallo: Shush, you.
<Nafallo> *s*
<infinity> I'll see Openoffice out of main before I lose exim.
<Nafallo> but really... I thought we didn't want duplicate functionality?
<pitti> Nafallo: second thing is that some actually needs to test the DVDs
<infinity> Nafallo: Which is why we ship both GNOME and KDE?
<Nafallo> infinity: not on the same dvd we ain't...
<Nafallo> pitti: right...
<infinity> Nafallo: So, we'll just randomly pick one MTA per flavour, and mix it up a bit!
<Nafallo> pitti: I need a to get my laptop so I can buy another one then :-P
<infinity> Nafallo: (MTAs are tiny anyway, you may be barking up the wrong tree)
<Nafallo> infinity: hehe. sounds fun! let's do it! :-)
<Nafallo> Mixbuntu :-)
<cjwatson> pitti: no, that won't help - I mean unsupport some big irrelevant binaries
<pitti> what's wrong in this diff between the 20070804 and 20070806.3 live manifest?
<pitti> -ubiquity 1.5.6
<pitti> -ubiquity-casper 1.95
<pitti> -ubiquity-frontend-gtk 1.5.6
<pitti> -ubiquity-ubuntu-artwork 1.5.6
<cjwatson> pitti: should only have been lpia ...
<cjwatson> but, indeed. huh?
<pitti> I wondered why I didn't see an ubiquity icon on the live
<siretart> Company: actually not that much, but I think it is very likely that this has been already fixed upstream, and we need to update the package anyway
<pitti> hm, this morning's ubuntu-meta upload looked fishy, I'll check that
<Company> siretart: pygi already looked at it
<siretart> yes, I saw
<Company> siretart: but yeah, it seems to be in upstream, so go pull a new ffmpeg so i have something else to complain ;)
<siretart> Company: the thing is that we carry quite a lot of patches with us around, which need all to be checked and adapted :/
<Company> yeah, so 1 patch more doesn't hurt ;p
<pygi> siretart, can't we just get that debdiff applied for him temporarily?
<cjwatson> pitti: I don't think it can be that
<pygi> Company, no, he meant when getting new upstream
<cjwatson> Package: ubiquity
<cjwatson> Task: kubuntu-live, edubuntu-live, xubuntu-live
<Company> it's just really annoying because everyone runs into that problem when compiling git
<Company> (of swfdec)
<pitti> ubuntu-meta-1.58$ grep ubiquity *  -> no result
<pitti> cjwatson: ^
<siretart> pygi: the debdiff undeprecates the structure struct ImgReSampleContext, AFAIU
<cjwatson> pitti: ubuntu-meta hasn't produced a live metapackage since dapper, so that's expected
<pygi> siretart, correct behaviour
<pitti> ah, ok
<cjwatson> the problem is that IS have not applied the germinate changes to drescher that I asked for a while ago
<pygi> siretart, tested building package with debdiff, builds fine
<cjwatson> I'll nag them
<pygi> siretart, according to Company it also should fix the problem
<pygi> I'm also after getting swfdec in shape for gutsy
<siretart> Company: do you know if that struct has been undeprecated or remove?
<siretart> removed upstream?
<Company> siretart: it's either removed or undeprecated, no idea - lemme look
<Company> http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/avcodec.h?revision=9933&view=markup
<Company> removed afaics
<pygi> siretart, I'd also discuss how we'll manage the cdrecord/wodim/cdrskin situation, with update-alternatives, ln's and conflicts or what?
<siretart> great!
<siretart> pygi: I need to leave soon today, I just wanted to quick check my mail. would you mind if we can discuss this tomorrow afternoon?
<pygi> siretart, ofcourse, it's mess now anyway :)
<pygi> a lot of work
<pygi> thanks
<evand> I aplogize about the cross post of "One Click Installer" between ubuntu-devel and ubuntu-devel-discuss.  I didn't notice the extra address in the To field before I submitted the approval.  Rest assured I will be much more careful in the future.
<jwendell> seb128, still around?
<seb128> jwendell: yes
<jwendell> seb128, is there any issue with glibc on amd64 related with g_timeout_add() ?
<jwendell> do you know?
<seb128> glib2.0 you mean?
<seb128> not that I know, no
<jwendell> yeah, glib 2.14
<jwendell> seb128, bug 129843
<ubotu> Launchpad bug 129843 in vino "vino-server crashed with SIGSEGV in g_main_context_dispatch()" [Medium,New]  https://launchpad.net/bugs/129843
<jwendell> seb128, i'm unable to reproduce it here, and everything (on code) seems to be ok...
<seb128> jwendell: might be a corruption, I can ask for a valgrind log if you want
<jwendell> seb128, it would be nice
<jwendell> seb128, also, bug 128842 seems not to belong to vino, right?
<ubotu> Launchpad bug 128842 in vino "vino-session crashed with SIGSEGV in ubuntulooks_draw_arrow()" [Medium,New]  https://launchpad.net/bugs/128842
<seb128> jwendell: not really, no
<seb128> jwendell: I've asked questions on it
<jwendell> seb128, thanks
<seb128> you're welcome
<mikmor2> I have an rc script S20foo that I want to execute before S70x11-common,
<mikmor2> Is there a way to force my script to be executed atomically?
<pygi> your new tracker stuff crashes like crazy, thank you very much xD
<mikmor2> ah.. nevermind
<Chipzz> infinity: if you're working on mysql, would you consider splitting the test-cases off in a seperate package; the mysql-server package is obscenely big, and splitting out the tests would reduce its size significantly (I've been wanting to file a bug about this, but I keep postponing it)
<seb128> doko: why did you subscribe ubuntu-archive to bug #124778 ?
<ubotu> Launchpad bug 124778 in expat "linux grashed" [Undecided,New]  https://launchpad.net/bugs/124778
<Chipzz> grashed? heh :)
<mathiaz> Chipzz: you'd better file a bug so that we can keep track of your request.
<Chipzz> mathiaz: I know, I'm aware of that ;) like I said, I keep postponing/forgetting, but I do intend to file a bug :)
#ubuntu-devel 2007-08-07
<mikmor2> does modprobe -a get executed before the rc scripts get executed, i assume?
<pedahzur> To whomever might be in charge of the installer and installer images;  Could you take a look at https://bugs.launchpad.net/ubuntu/+bug/130555  It is a real show-stopper for me at the moment.  Looking for feedback, as well as anything I can do to help further debug the prolem.
<ubotu> Launchpad bug 130555 in Ubuntu "dapper boot.img is out of sync with installer cd" [Undecided,Confirmed] 
<pedahzur> Or should I bug someone in #ubuntu-bugs?
<mikmor2> If i were to do an update-rc.d within an rc script, would the effects take place during that run? Ie. is the script which runs the rc scripts going to cache the list of executed files before execution, and ignore any updates?
<mikmor2> Maybe someone could point me to the program/script that calls the rc*.d scripts?
<StevenK> pedahzur: Try http://us.archive.ubuntu.com/ubuntu/dists/dapper-updates/main/installer-i386/current/images/hd-media/boot.img.gz
<StevenK> pedahzur: (Note the -updates in the URL)
<pedahzur> StevenK: I will try that.  I didn't even think about looking in the updates.  Thank you!
<pedahzur> You can reject that bug, or mark as fixed, if you want.  I'll reopen if that updated boot.img doesn't work.
<StevenK> pedahzur: No problem.
<StevenK> pedahzur: I can comment that I suggest you try -updates and we can take it from there, if you wish?
<pedahzur> Sure.  It'll be a few days before I try.  I won't be back at the system until next weekend.
<pedahzur> mikmor2: the script /usr/sbin/invoke-rc.d handles this.
<mikmor2> cool.. it seems as long as the priority level isn't the same, it won't be cached.. thats good.
<cjwatson> pedahzur: indeed, using dapper-updates is the right answer. I'll reject the bug now.
<cjwatson> the image in /dists/dapper/ should still work fine if installing from the network or from original 6.06 CDs
<cjwatson> mikmor2: /usr/sbin/invoke-rc.d is not hugely relevant here - /etc/init.d/rc is a better place to look for how things are invoked at boot
<cjwatson> and it does collect the list of scripts to run in advance
<pedahzur> cjwatson: Understood.  I didn't see anywhere that the boot.img gave me a chance to install from the network.  At least, I didn't get that far since it tried to load all it's network drivers from the CD.
<pedahzur> cjwatson: Right!...I knew there was an "rc" script, I just couldn't find it for some reason.  I had forgotten it was in /etc/init.d
<mikmor2> cjwatson: Yeah, i discovered that about an hour ago. thanks :)
<cjwatson> pedahzur: ah, hd-media, sure - replace hd-media with netboot and you get one that can install from the network
<mikmor2> cjwatson: For an update, 0.2-2 is soon to be available
<mikmor2> aye guess not an hour..
<mikmor2> heh
<cjwatson> though hd-media is certainly a valid approach when boot.img and the ISO are in sync
<mikmor2> been a long day :/
<cjwatson> you're telling me, I've been working for I think 15 hours now
<cjwatson> but I have finally got gutsy's syslinux and gfxboot to be friends
<cjwatson> no, 16 hours. argh.
<pedahzur> cjwatson: Sigh...now why didn't I see the boot.img under netboot...would have saved my self a lot of hassle. :)  That is, if netboot supports PPPOE.  At any rate, thanks for your help and pointers.  I'll know next time.
<mikmor2> cjwatson: Ouch.. yeah, I remember talking to you at 3am
<mikmor2> hmm.. i think my gui has a few aesthetic bugs
<mikmor2> meh.
<cjwatson> pedahzur: the installer doesn't really support pppoe in general yet - you can set it up after the install with pppoeconf
<pedahzur> OK, so I still did need the hard drive/ISO installer.  But at least I know now how to get at what I need.  Thanks.
<mikmor2> cjwatson: are there any plans to unify all of your image making scripts at some point?
<cjwatson> mikmor2: it would be nice in theory but it's not on any roadmap at present
<mikmor2> ah.. crap. I'm thinking using mercurial was a bad idea.. too young :/
<mikmor2> The latest packaged mercurial version doesn't support symbolic links
<mikmor2> \
<alex_mayorga> Hello, I'm wondering if https://bugs.launchpad.net/bugs/121111 is ever in the map for Tribe 4
<ubotu> Launchpad bug 121111 in linux-source-2.6.22 "Gutsy Tribe 3 CD don't load on Dell Inspiron 1501" [Medium,Triaged] 
<alex_mayorga> I have the test system right here at my fingertips, FWIW
<cjwatson> alex_mayorga: probably not tribe-4 at this point, sorry
<cjwatson> we're freezing tomorrow and the kernel usually needs to land early
<bddebian> Heya cjwatson
<cjwatson> hi
<alex_mayorga> cjwatson: so what can I contribute to get it fixed?
<cjwatson> kylem: are you going to be around for a bit longer? if so, could you do new processing on gfxboot when it lands? it has a random new binary that can just be shoved into universe
<cjwatson> alex_mayorga: I'm not a kernel hacker, sorry
<cjwatson> if it's what I think it is, Ben and Tim have been spending a fair amount of time wrestling with it
<alex_mayorga> just chiming in if they need any testing ;)
<mjg59`> It's basically sorted upstream
<mjg59> AMD are just crap
<cjwatson> alex_mayorga: I think that's pretty clear from the bug :-)
<bddebian> yep
<bddebian> Hi mjg59
<kylem> cjwatson, i'll be around for a while
<cjwatson> thanks
<alex_mayorga> #ubuntu-bugs
<twb> Has anyone successfully netbooted the Feisty live cd?
<twb> I'm getting "User not known to underlying authentication module."
<reitblatt> twb: please use #ubuntu for support
<twb> OK, sorry.
<kylem> cjwatson, still around?
<wasabi> eh is this tracker by default stuff fake or not
<wasabi> oh, nope.
<LaserJock> it's not fake
<wasabi> bluh
<LaserJock> heh
<wasabi> it'd better not be a depend of ubuntu-desktop or i'll be angry. =)
<ScottK> You'll be angry.
<LaserJock> yeah, I haven't quite figured out how it's decided what goes in Depends and what goes in Recommends
<ajmitch> wasabi: Recommends
<wasabi> that's fine then
<wasabi> i guess.
<wasabi> i still fundamentally hate it. =/
* ajmitch isn't a big fan either
<wasabi> I think the entire concept of programs using it to STORE information is terribly flawed.
<LaserJock> I don't need it, but it might be interesting to try out
<wasabi> Simple indexor? Fine, I don't care. Storing actual data? That sucks.
<LaserJock> I'm more interested in stringi
<mjg59> Ok.
<ajmitch> LaserJock: what's new?
<mjg59> Why is trackerd running when I'm on battery?
<LaserJock> mjg59: why wouldn't it?
<wasabi> It has to run all the time, but it shouldn't ever do a full scan
<mjg59> By running I mean causing lots of disk i/o
<ajmitch> because battery life gets killed by disk seeks
<wasabi> (it has to run to watch changes to prevent a full scan)
<mjg59> Yeah, running is fine
<wasabi> laptop mode should prevent it from seeking disk, no?
<LaserJock> ajmitch: well, there is some GSoC with doing work on chemical indexing with stringi
<mjg59> wasabi: No?
<mjg59> (1) we don't enable laptop mode by default (the fact that it currently is is a bug)
<mjg59> (2) laptop mode doesn't help avoid reads
<wasabi> guess it's time to see how bad tracker sucks on NFS then
* wasabi sigh
<LaserJock> does anybody else have this in gutsy: rebooting causes first a re-login
* wasabi just finished getting banshee fixed for that
<mjg59> Also, why does it seem to store configuration in a flat file, rather than gconf?
<wasabi> Where's it put it's dbs? ~? =/
<mjg59> We've had this conversation. ~ is the right place.
<wasabi> I was never satisfied with that conversation if I remember. :)
* ScottK finds a bug...
<ScottK> Sorry.  Thought I was in MOTU.
<ajmitch> nah, main doesn't have bugs
<ScottK> Nope, sorry, package is in Main
<LaserJock> darn
<TheMuso> tracker?
* TheMuso wishes to be enlightened.
<RAOF> Beagle, written in C, which doesn't index quite as much stuff.
<Amaranth> RAOF: What does beagle index that tracker doesn't?
<RAOF> Web history?
<Amaranth> The only thing I can think of is tomboy notes
<Amaranth> Beagle indexes that?
<RAOF> Yeah.
<Amaranth> Heh
<RAOF> With the firefox plugin.
<Amaranth> Oh, screw that
<RAOF> I'm not sure if anything loves epiphany, sadly.
* StevenK wishes his machine would build pdftk quicker. Less than an hour would be good.
<Amaranth> I think beagle only does it because they had the dashboard cluepacket thing already :)
<RAOF> Although tracker does do some stuff beagle doesn't.  It's got a dbus interface, for example.
<StevenK> Oh great, more stuff that blows up/doesn't work when sbuild buggers up the running dbusd.
<ajmitch> but dbus is great & wonderful & would never break
<StevenK> And requires you reboot after an upgrade since upstream are dorks.
<ajmitch> you make that sound like a bad thing
<wolfe> need to install software? reboot
<wolfe> need to change a setting in some special item, reboot
<wolfe> sound familiar? Ubuntu has become Windows ;)
<wolfe> *ducks*
<ScottK> No need to duck now.  Only us peons here.
<wolfe> =] 
<LaserJock> I don't mind rebooting as long as it actually works and it's not for *everything*
<LaserJock> I was on my Windows XP partition the other day, shesh, I can't even get into the thing before I"m rebooting like 3 times because of updates
<StevenK> I don't mind that so much. What irritates the heck out of me is Windows popping up a message saying "Updates are installed. You need to reboot now.", and has a timer counting down 5 minutes. You click the Go Away button a few times, then you get distracted and the machine reboots anyway.
<mikmor2> I am having the weirdest problem.. its like squashfs is rearranging my inodes..
<wolfe> StevenK: I always set the computer policy to never reboot even for high security updates
<StevenK> wolfe: I would, except I don't know where to do that. Besides the VMWare server that machine is on is down at the moment.
<ScottK> Bug #130792 has a fix attached if any core-dev cares to upload it ...
<ubotu> Launchpad bug 130792 in pygresql "python-pygresql requires libpq5 to work" [Medium,Confirmed]  https://launchpad.net/bugs/130792
<StevenK> ScottK: SRU, or Gutsy?
<ScottK> Gutsy
<ScottK> Feisty has the same problem.
<LaserJock> good grief, I *did* have to spill water all over my desk :(
<ScottK> I can do a debdiff for that if you want it after Gutsy's fixed
<StevenK> ScottK: Sounds fine, I just have to wait for my machine to polish off pdftk.
<ScottK> K
* ajmitch won't need to look at it then
<wolfe> StevenK: open up mmc, file, add snapin, and find the Group Poliy Object editor
<ScottK> StevenK: Nominated for Feisty, if you'd please accept it.
<wolfe> you'll have to go under the computer tree, not the user, and find the update object
<StevenK> ScottK: Accepted.
<ScottK> Thanks.
<StevenK> ScottK: Small niggling little concern. (LP :# 130792) -> (LP: #130792)
<ScottK> Urgh.
<ScottK> Want me to fix it?
<StevenK> Yes please.
<ScottK> The feisty-proposed debdiff I just attached to the bug has the same problem.
<ScottK> Back in a flash.
<StevenK> I was just about to say that...
<ScottK> Done
<ScottK> StevenK: Back over to you...
<StevenK> ScottK: You've test built and installed for both Gutsy and Feisty?
<ScottK> I test built for both.
* StevenK is still waiting for pdftk to release its iron grip on his machine.
<ScottK> I installed for Feisty.
<ScottK> Cause that's the machine it broke on me for.
<StevenK> Does this bug also affect Debian?
<ScottK> Yes and I linke the bug.
<ScottK> linked
<ScottK> even
<StevenK> I see that. Sorry.
<ScottK> No problem.
<ScottK> Gutsy/Feisty have the same version currently.
<StevenK> Right. The Maintainer for it is doko. I'm sure he'll upload a fix to Debian for this if you ask him nicely, and then you can request a sync.
<LaserJock> awww crap
<LaserJock> I suppose all the archive admins are asleep :/
<StevenK> For the next 3 hours or so
* StevenK tries to open a vacuum packed printer cartridge bag without the use of power tools.
<infinity> We are?
<ScottK> Well he's been sitting on a patch in Debian BTS for a while, so dunno how much of a rush he is for this in Debian.
<mjg59> Hm.
<mjg59> So.
<mjg59> Tracker is still indexing my ~
<infinity> LaserJock: What do you need an archive admin for?
<mjg59> An hour after I logged in
<mjg59> I'm not sold on this
<infinity> mjg59: 30G of source trees?
<infinity> mjg59: (That's what my home looks like...)
<infinity> Well, and the porn.
<StevenK> infinity: libnss-db!
<LaserJock> well, my desktop-multiplier package got sent to NEW
<LaserJock> but it was already NEW'd in dapper-updates
<infinity> You had a NEW package in dapper-updates?
<LaserJock> ... yes
<LaserJock> Multiverse
<infinity> I'm failing to see how that qualifies as an "update"...
<LaserJock> it doesn't
<LaserJock> but well, that's Canonical  ;-)
<LaserJock> I just packaged the thing
<StevenK> ScottK: Right, pdftk has let go. At this point, I'm rather inclined to ask doko about it.
<ScottK> O.
<ScottK> OK.
<infinity> LaserJock: You realise it was FTBFS on all !i386?
<LaserJock> infinity: it's i386 only
<Burgundavia> infinity: dm is a binary package
<Burgundavia> from my former employer, Userful
<Burgundavia> ugh
<infinity> Ahh.
<infinity> LaserJock: Fair enough.
<StevenK> infinity: Could I also beg you to let mlt out of binary NEW?
<infinity> LaserJock: NEWed.
<LaserJock> infinity: thank you kindly sir
<Burgundavia> LaserJock: hopefully that will get them off your back
<LaserJock> Burgundavia: haha, never!
<StevenK> ScottK: Happy to upload the -proposed fix after Gutsy is sorted, or we have a plan for it.
<ScottK> OK.
<ScottK> I've done my bit, so up to you core-devs now...
<LaserJock> infinity: I did set Architecture: i386 , that is the proper way to do it isn't it?
<StevenK> LaserJock: The other bit is adding it to Packages-arch-specific, but you aren't able to do that.
<LaserJock> StevenK: that's in the repo?
<infinity> No.  It's in Debian CVS.
<infinity> Me, lamont, and elmo maintain it.
<LaserJock> I see
<infinity> http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.695&root=dak&view=log
<mjg59> infinity: Turns out to only be 20G
<infinity> mjg59: That's still a crapload of source to index.
<mjg59> Yeah
<mjg59> I guess I can't really blame it too much
<infinity> Developers aren't really average users in this sense. :)
<infinity> (Though, surely it has a way to exclude directories?)
<calc> mjg59: how is the amd64 vbetool stuff coming along?
<mjg59> calc: Not had a chance to look
<StevenK> Argh. My printer isn't configured on my server.
<mjg59> Something very weird is happening
<calc> mjg59: oh ok, np
* calc is doing a final build of OOo, yipee, then just test it and upload
* calc thinks he will upload it and then test it, since it will take hours to upload
<infinity> StevenK: Is that just an SOVER bump?
<calc> so new OOo that actually works will hopefully be uploaded in the next 6hr
<calc> hmm i'll do the quick way to upload
<infinity> It takes you 6 hours to upload OOo?
<StevenK> infinity: mlt? Yup.
<infinity> Someone send that man some bandwidth...
<calc> infinity: ~ 2hr to build and probably 4hr to upload if i didn't wget the source, which i will do
<calc> infinity: source of OOo 2.3 is ~ 260MB plus 21MB diff
<calc> and my broadband upload is a bit crap
<infinity> calc: Yeah, I know how big it is, I've had to upload it many times in the past.  Just that it didn't take me 4 hours. :P
<infinity> (And I live in the third world, even...)
<StevenK> No, worse. Melbourne.
* StevenK hides.
<infinity> I was referring to "Australia"...
<StevenK> I wasn't. :-)
<calc> infinity: i have 128kbps upload (i think) maybe more
<infinity> Melbourne's the small gilmmering light at the end of this tunnel you call a country. :P
<calc> infinity: i don't own the place i am currently living in so not really certain
<infinity> calc: Ouch.  I'm at least at a megabit.
<StevenK> No, the Yarra River is the asshole of Australia and Melbourne is 80km up it.
<calc> it would definitely take over an hour to upload
<calc> so i logged into the server and wget it at 500KB/s much better :)
<infinity> StevenK: Oh yeah?  Well.  Well.  People in Sydney are big meanieheads!
<StevenK> Oh, gah. Why do I think the reason CUPS can't authenticate me is that the cupsys user isn't a member of a shadow.
<StevenK> infinity: :-D
<infinity> StevenK: (And you lack culture, grit, and any sort of life there)
<infinity> StevenK: mlt NEWed.
* infinity wonders what "libmiracle" actually does.
<StevenK> infinity: Thanks. I like to think I'm at least a little cultured, since I follow the AFL.
<infinity> *cough*
<StevenK> Or something. :-)
<infinity> Alright, so, AFL is Melbourne's most obviously poor contribution to the world.
<StevenK> Hahaha
<infinity> But there are lots of things here that just feel very "real" and such, in the same way that I feel in New York or London.
<StevenK> More so than Sydney?
<infinity> Sydney just made me feel like I was in a sterile 1960's future city, where people should all be wearing white and exchanging pleasantries.
<StevenK> I really dislike the CBD of Sydney. I avoid it at all costs.
<infinity> See, and Melbourne's CBD is quite interesting.
<infinity> Like a very, very, very tiny Manhattan.
<infinity> Sydney's CBD is "pretty", but it seems artificial.  Like no emotion went into the design of any of it, just architects trying to make sure people had a calm and pleasant afternoon.
<StevenK> Sounds about right.
<Burgundavia> a lot of cities are like that
<infinity> And, to be fair, as a downtown by, I do tend to judge a city by its CBD.
<infinity> s/by/boy/
<Burgundavia> most CBDs got screwed up by the 60s/70s mad rush to concrete and large highways
<infinity> Burgundavia: Nothing wrong with concrete and highways, as long as the grit and life of the area lives on.
<Burgundavia> large highways destroy urban cores
<Burgundavia> observe Seattle
<infinity> LA is a better example.
<Burgundavia> the waterfront is a tourist ghetto because of the Alaskan Way
<infinity> Downtown Los Angeles is one of the worst places on earth.
<Burgundavia> most Cali cities are like that
<calc> LA is fun to drive in with no protected left turns
<StevenK> infinity: Downtown LA is worse than Sydney? :-)
<Burgundavia> precisely why I am shooting for a Masters in Urban Planning
<infinity> StevenK: Differently so.
<Burgundavia> time to fix all that
<Burgundavia> no country on earth worships the cult of the automobile quite like the US
<infinity> StevenK: Lots of the LA suburbs are kind Sydney-esque, but the actual city of Los Angeles was completely bypassed by several freeways, and it's become a dirty hole.
<calc> i think the only really nice city i have been in the US has been cambridge/boston
<infinity> StevenK: Lots of insurance companies and such still have headquarters there, but no one in their right mind works late, for fear of leaving the office after dark.
<StevenK> Neat. :-/
<infinity> In all the ways that Manhattan's dirt is almost charming and lends an air of vitality and life, LA's dirt is just scummy and scary.
<infinity> The suburbs are all much nicer, but they have the Sydney "fake happy" feel about them.
<ScottK> calc: Nice if you don't have to drive there.
<calc> ScottK: actually has mass transit too, at least to some extent
<calc> of course i have only been there once and didn't have to drive
<ScottK> True.
<ScottK> Boston drivers are deservedly notorious
<ScottK> That's from someone who considers driving in downtown Manhattan "Fun".
<infinity> Manhattan driving isn't too bad, until you get gridlocked with eight thousand taxis and for thousand delivery vans.
<infinity> I have yet to understand why people drive private vehicles in Manhattan.
<infinity> s/for/four/
<infinity> (Well, except to get them OUT of Manhattan on vacation, which is why I was driving there)
<infinity> In retrospect, I'd have been saner to rent a car outsidethe city and take a train to pick it up.
* ScottK has been stuck in traffic for multiple hours after midnight, just trying to pass through.
* calc dislikes houston traffic enough he would never drive in northern cities like NYC/Boston
<infinity> Melbourne driving is fun (hook turns!), but I don't own a car, cause the transit here is pretty decent, and I live 10 mins out from the CBD.
<calc> houston is so spread out that even though the traffic isn't as bad it takes forever to get anywhere
<infinity> (For the uninitiated, picture a wide turn -- left in America/Europe, or right in the UK/Australia -- and now picture doing it out of the far opposite lane.  That's a hook turn)
<calc> they have all these useless things called trees around
<calc> infinity: wouldn't that cause massive wrecks?
<infinity> You'd think.  Mostly it just causes a lot of honking at timid people who refuse to perform the operation before the light turns red.
<StevenK> Sounds like Sydney. The outskirts of suburbia in Sydney is Penrith which is over 55km from the CBD
<StevenK> Oh, I'd like to see my mother do a hook turn, just once.
* infinity snickers.
* StevenK grins.
<infinity> Zofia's mother actually burst into tears attempting one.
<infinity> I find the Melbourne CBD fun to drive in.  Whenever I rent a car to go out of the city, I rent from a CBD dealer intentionally, just to have some fun.
<ScottK> infinity: In the US, what you are calling Hook Turns are common in New Jersey.  Dunno what they call them.
<ScottK> Ah.  I remember.
<ScottK> Jug handle turns.
<infinity> ScottK: Hrm, my Jersey experience is limited to Jersey City, but I didn't see any.
<infinity> ScottK: Are there train tracks involved, or any other such "valid" excuse?
<infinity> (In Melbourne, it's the trams that have led to this bizarre situation)
<ScottK> Of course they have lots of "traffic circles" AKA roundabouts too.
<ScottK> No, they just thought it would be a good idea to turn right all the time.
<infinity> I like roundabouts.  Veru rapid traffic handling.  The only thing I don't like about them is my tendency to take them at 100+, and then wonder how soon I'll need to replace my tires.
<infinity> ScottK: Err, you're misreading.  I'm talking about (from a North American perspective) turning LEFT from the far RIGHT HAND lane.
<ScottK> Ah.
<infinity> ScottK: So, cutting across two lanes of same-flow traffic before cutting across three lanes of oncoming.
<ScottK> Nevermind then.
<infinity> AKA: Insanity.
<ScottK> No, we don't do that here.
<ScottK> At least not legally.
<StevenK> Heh
<nixternal> ScottK: like DuPont Circle..that is fun to race around
<ScottK> Argh.  To much traffic, too slow.
<nixternal> not at 2am
<ScottK> NYC in a rental car....
<ScottK> True
<nixternal> NYC in anything is nuts
<nixternal> just like Chicago
<nixternal> and LA
<ScottK> No, I've driven all those places, NYC is different.
<nixternal> ya, different != deadly :)
<nixternal> Boston, the great dig, go around it if you can
<realist> infinity: you live in Melbourne?
* StevenK sighs.
<ScottK> Although I do remember being in Chicago and asking directions on the "L" and being told, "Don't go that way.  That way is South.  Go that way and you won't come back."
<StevenK> Finally, two Ubuntu and one Windows machine talking to the printer.
<StevenK> Bloody spawn of the devil things.
<realist> infinity: do you live in Melbourne?
<infinity> realist: Yes.
<StevenK> infinity: Can we talk about libnss-db now as opposed to driving? :-)
<realist> StevenK: I had to install proprietary printer drivers + a supplied CUPS (albeit GPL) wrapper to get my printer working
<infinity> StevenK: We could, after I have lunch. :)
<StevenK> infinity: Little late for lunch, isn't it?
<realist> I feel somewhat 'unclean' from the experience
<StevenK> realist: I had no problems on the machine the printer is connected to, or the Windows machine. It was my desktop that gave the trouble.
<StevenK> Mostly because CUPS wouldn't tell me the IPP URI I had to use for the printer and I had to guess.
<Mithrandir> morning
<StevenK> Morning Mithrandir
<realist> StevenK: ahhh. I had to manually specify the URI in my case.
<StevenK> Mithrandir: How was your VAC?
<Mithrandir> StevenK: good.  Horseback riding is fun, and my lower back seems to have untensioned itself quite a bit.
<StevenK> !!!
<infinity> StevenK: My timezones are out of whack.
<StevenK> grep-dctrl is listed as NBS.
<StevenK> infinity: You're set to Perth time?
<infinity> StevenK: Somewhere in between Melbourne, London, and Hong Kong, with a touch of Hawaii.
* StevenK chuckles.
* StevenK kicks the Maintainer of dctrl-tools. Why bother Build-Depend'ing on gcc (>= 3.0)
<realist> infinity: Which when all added is roughly Perth time ;-)
<ScottK> Well that's going to generate 133,068 DNS PTR queries.  I wonder if my ISP will get annoyed....
<StevenK> ScottK: What is?
<ScottK> My program I just launced
<ScottK> launched.
<ScottK> I'm doing some statistical analysis for a client on anti-spam stuff
<StevenK> That's a little ... excessive.
<ScottK> And I needed a bunch of PTR records.
<ScottK> Well there's over 5 million messages in the set, so that didn't seem so bad.
<ScottK> I expect this one will have to run for a while.
<ScottK> Now only 41,096 are unique IP addresses, so caching will help me some here.
* StevenK shivers at dtc's Depends list.
* StevenK chuckles at a build of dtc.
<ScottK> Good $TIME_OF_DAY.  I'm goint to bed.
<mjg59> Tracker /still/ going
<RAOF> Eh, mine's crashed :)
<mjg59> Does it log anywhere?
<mjg59> Why does trackerd have libthai stuff open all the time?
<mjg59> It is a very odd application
<LaserJock> mjg59: just write a blog post about it, then you'll totally be a forums hero ;-)
<mjg59> Haha
<calc> keescook: here?
<Burgundavia> mjg59: http://www.getautomatix.com/forum/index.php?showtopic=1454
<LaserJock> Burgundavia: some army we have ;-)
<Burgundavia> heh
<RAOF> I'm glad to hear cannonical has an army :)
<LaserJock> and here I was working my butt of for nothing
<LaserJock> *off
* LaserJock packs up and goes home
<Burgundavia> RAOF: no, they secretly fund an orbital laser via GNOME which they "borrow" occasionally
* RAOF is all about the orbital laser death.
<LaserJock> hmm, that sounds fun
<Burgundavia> all about the plausible deniablity, Canonical is
<jsgotangco> heh
<pitti> Good morning
<Burgundavia> morning pitti
<LaserJock> uh oh, is this tribe 4 freeze? :-)
<StevenK> Morning pitti
<pitti> hey guys
<calc> pitti: hey
<pitti> LaserJock: I'll check the current situation first :)
<calc> pitti: got the stuff uploaded into my ~ccheney/incoming dir
<StevenK> pitti: I have a whole bunch of stuff that can be NBS'd, shall I rattle it off? :-)
<pitti> hi calc; oh, nightshift, too? :)
<calc> pitti: yea been working to get it finished in time
<pitti> StevenK: I can just look at the list
<calc> pitti: just finished uploading it a few min ago
<StevenK> pitti: They aren't zero sized since they all interdepend.
<pitti> calc: wow! so, does new OO.o actually work now? :-)
<pitti> StevenK: fire away :)
<calc> pitti: i believe so, i tested the build a couple days ago, i haven't had time to finish the uploaded build locally to actually test it :\ but the one in gutsy is broken
<calc> pitti: i should be able to test it within 2-3hr (when it finishes locally)
<StevenK> pitti: libquicktime0 libmiracle0.2.2 libmlt0.2.2 libmlt0.2.2-data
<ajmitch> morning pitti
<calc> pitti: it fully built earlier today and i forgot to test it before accidentally rm
<calc> pitti: rm'ing the debs :\
<StevenK> pitti: Oh, and libvalerie0.2.2
<pitti> calc: erk, too bad
<StevenK> calc: Don't. Use rsync?
<pitti> calc: but did you still have the built tree?
<ajmitch> ouch
<calc> pitti: so in the process of building it again
<calc> pitti:  no :(
<ajmitch> so it's a case of "it compiles, ship it"?
<StevenK> pitti: If the i386 buildds catch up, libapache-mod-log-sql{,-{dbi,mysql}} should also be able to be killed after the publisher next runs.
<calc> ajmitch: no i'm intending to stay up and verify its actually good, i did test it a couple days ago and it was good at that time, but i have made a few changes since then and the current version isn't tested as is yet
<calc> should take less than 3hr to finish the build
<ajmitch> calc: darn, I was going to ask pitti if I could do that to sneak f-spot in :)
<pitti> ajmitch: we are not yet frozen, so if you don't break anything, go ahead :)
<ajmitch> pitti: I've got to get it built first
<pitti> (OTOH, its badly broken ATM anyway)
<pitti> ajmitch: does that fix the crash when closing?
<calc> i'm going to take a nap and come back in about 3hr should be built by then (2am here right now)
<ajmitch> still at the 'merge stuff in & make sure it's in a buildable state' stage
<Mithrandir> *sigh*; the worst thing about vacations, or rather, the end of vacations is the pile of email awaiting me when I get home.
<pitti> ajmitch: good luck then!
<pitti> hey Mithrandir
<calc> ajmitch: merges are so much fun ;)
<pitti> Mithrandir: *phear*
<ajmitch> calc: well, it's merging a couple of bzr branches
<calc> i disabled the multithreaded build so i'm actually building both ooo and ooo-l10n at the same time to speed things up a bit
<Burgundavia> Mithrandir: I look forward to the giant pile after 4 weeks in SA
<Mithrandir> Burgundavia: indeed.  This is only from Wednesday afternoon, so a little less than a week
<calc> i think disabling the multithreaded build will probably solve the random ooo build failures and at the moment its completely broken anyway so had to be disabled
<Mithrandir> and people keep cc-ing me on threads posted to mailing lists.
<StevenK> Mithrandir: I don't get that problem since Cyrus does duplicate detection.
<pitti> calc: right, I was just going to ask: we need -l10n, too
<StevenK> Oh, a thank you e-mail for updating Kino in Gutsy.
<calc> pitti: yea
<StevenK> Mithrandir: Even if Cyrus is ... special.
<Mithrandir> StevenK: and it's smart enough to know that "if this mail is sent to a list and Cc-ed (and sent to those other two lists)" it just elides it from your inbox, not the list boxes?  Or does it mark them as read there?
<pitti> StevenK: removed
<StevenK> pitti: Thanks
<calc> pitti: ok well i'm off to bed for a bit, but i'll be back in about 3hr
<pitti> calc: sleep well!
<calc> if anyone needs me msg me and i will see it when i wake up
<calc> have a great morning :)
<StevenK> Mithrandir: I think hashes the mails as they come in, and discards messages that have been seen. Of course hashes expire out of the cache fairly quickly.
<StevenK> I think it, even
<Mithrandir> StevenK: but I don't want to expire them, I just want them to not be listed in my inbox.
<ajmitch> StevenK: I do similar with procmail
<StevenK> ajmitch: Using formail, right?
<ajmitch> yes
<ajmitch> seems to work well enough
<realist> I think mutt handles duplicates sanely (via X-Follow-Up-To header, or some such)
<StevenK> infinity: Surely you're back from lunch by now. :-)
<realist> StevenK: perhaps they were _really_ hugry... I hear jet lag does that
<pitti> hey sabdfl
<sabdfl> howdy pitti
<ajmitch> sigh, need batteries for the camera to test importing photos
<RAOF> Yay!  It seems something in my home directory can deterministicly crash trackerd.  Let's turn the logging up to 11!
<Burgundavia> sabdfl: are you free for a CC meeting this week? On the 12th I fly out for a 4 week vacation
<StevenK> pitti: Looks like dctrl-tools no longer provides a grep-dctrl package. Changing {Build-,}Depends is simple. Can you eyeball the list at http://people.ubuntu.com/~ubuntu-archive/NBS/grep-dctrl and see if there is anything I should keep my hands off?
<pitti> StevenK: please don't rebuild the installer bits right now (let's do that after tribe)
<pitti> StevenK: the rest and universe bits are ok
<pitti> StevenK: meh, I wish dctrl-tools would at least Provide: grep-dctrl; that would be sufficient
<StevenK> pitti: It does.
<pitti> oh, indeed; multiple-versoin apt-cache show output fooled me
<pitti> StevenK: so, then it's fine to just remove it
<pitti> StevenK: buildds will DTRT for that as a build dep
* StevenK nods.
<StevenK> And apt should as well.
<StevenK> Debian should change most of them itself, and the changes can trickle down.
<StevenK> pitti: Kill it at your leisure ...
<ajmitch> yay, segfault on exit, makes me suspicious of other libs
<pitti> ajmitch: I had that as well
<ajmitch> I know, but this is with 0.4.0
<ajmitch> so there's no change in that behaviour, but at least it's just irritating rather than data-munching
* ..[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 frozen for Tribe 4, please help squash critical bugs
<pitti> (just to stop doko from uploading yet another glibc :) )
<ajmitch> heh
<StevenK> Haha
<pitti> the previous one is still building...
<StevenK> pitti: But only on sparc.
<pitti> and it'll still take some three hours
<pitti> screw it, I'll build the server isos later then
<StevenK> Heh
<pitti> ah, glibc i386 is in accepted
<asac> pitti: Waiting for approval: midbrowser 0.1.6a-0ubuntu1 (source) ... any chance?
<pitti> asac: read the announcement; universe is not frozen :)
* ..[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 | Main frozen for Tribe 4, please help squash critical bugs
* pitti fixes Gutsy -> Main
<pitti> to match the email announcement
<asac> pitti: hehe ... sorry ;) its early in the morning
* pitti hugs asac, NP
<asac> pitti: what would you think about https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x ?
<pitti> asac: heh, I was just going to ask you about the status of the two n-m tribe4 bugs
<asac> the two?
<asac> which ones?
<pitti> bug 121439 and bug 128360
<ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
<ubotu> Launchpad bug 128360 in network-manager "nm fails to connect to open network" [Undecided,New]  https://launchpad.net/bugs/128360
<asac> yeah i hope that a bunch of ipw3945 issues are gone
* pitti tickles seb128
<seb128> doh, already frozen :/
<seb128> hey pitti
<asac> however ... for open network ... with ipw3945 is still a problem
<seb128> pitti: you are too quick to freeze ;)
<pitti> seb128: <pitti> (just to stop doko from uploading yet another glibc :) )
<seb128> erf
<pitti> seb128: bug fixes are always welcome, don't worry
<seb128> ok, good ;)
<pitti> asac: looks good! did you get any feedback from ipw3945 users? (wrt. #121439)
<pygi> hello
<asac> pitti: i tested a lot with stgraber ... we fixed the ipw3945 wpa issue (for him)
<pitti> cool
<asac> pitti: however i would really like to get positive feedback from other chipsets
* RAOF wonders why he's never seen any of this ipw3945 trouble people report.
<pitti> asac: just upload it now; we still have time to fix or revert patches if there's trouble
<pitti> asac: please ask for testing the new version in the bug
<mikmor2> asac: Is that bug only in gutsy?
<asac> pitti: ok doing so now
<pitti> seb128: can you reproduce bug 107109? mvo can't, and if you can't either, I'll just move that to tribe5 (it might not exist any more)
<ubotu> Launchpad bug 107109 in compiz "No "New Login" for user with Desktop effects enabled" [High,Incomplete]  https://launchpad.net/bugs/107109
<asac> mikmor2: yes and no
<pitti> mvo: did you do the g-a-i db update?
<seb128> pitti: the guy is running feisty, do you want me to test on 7.04?
<mvo> pitti: not yet, but it is scheduled for today (I will do a apt upload now to fix a bug in apport install error reporting)
<pitti> seb128: no, current gutsy
<pitti> seb128: just concerned about the tribe4 bugs
<mvo> hey carlos!
<carlos> mvo: hey!
<seb128> pitti: no such bug
<seb128> pitti: we got no duplicate and the user is not using gutsy, not sure why it has been milestoned
<pitti> seb128: you mean, it doesn't happen for you?
<seb128> no bug, it works fine
<stgraber> asac: did you find a way to fix Open Networks ?
<pitti> seb128: cool; let's tentatively close it then
<pitti> mvo, seb128: I didn't see bug 123078 since the last tribe any more, and this looks quite dead; I'm prone to close it, too, do you agree?
<ubotu> Launchpad bug 123078 in gnome-session "System -> Quit takes a long time to appear" [Low,Incomplete]  https://launchpad.net/bugs/123078
<mjg59> pitti: Isn't that just the GPM interface name change?
<pitti> mjg59: depends
<pitti> mjg59: it could either have been that renaming (in tribe2 AFAIR)
<seb128> pitti: I think an user told me he had session issue and that has been fixed with some update, I would just close it as fixed and ask them to reopen if somebody still get the bug
<pitti> mjg59: or it could be compiz failing to connect to the session, timing out after 60 seconds, in which case it blocked all the other desktop session apps from connecting
<mjg59> Ah, I see
<asac> stgraber: unfortunately not yet
<pitti> seb128: I agree; kill it :)
<mjg59> seb128: Tracker is currently... painful on laptops
<seb128> mjg59: what it is doing?
<mjg59> seb128: It'll happily index on battery
<seb128> mjg59: you can open bugs on launchpad, upstream is subscribed to it
<asac> pitti: network-manager_0.6.5-0ubuntu8_source.changes uploaded
<seb128> ah, not nice, that was supposed to be fixed in 0.6
<RAOF> That should be pretty easy to fix, really.
<mjg59> seb128: Yeah, have done
<seb128> good
<mjg59> seb128: Is it deliberate that -desktop doesn't pull in the preferences?
<mjg59> Or the search tool?
<stgraber> asac: I also have another issue here which is like ipw3945 isn't scanning properly, once connected to a network it tends to hide all the others and sometimes only show the 2-3 strongest hiding my main network which is in another room. But this looks like an ipw3945 bug (same behaviour checking with iwlist eth1 scanning)
<pitti> mvo: since you can reproduce bug 119341, can you please do bryce's test?
<ubotu> Launchpad bug 119341 in xorg-server "glxinfo command causes Xorg to abort on Dimension E520" [Unknown,Confirmed]  https://launchpad.net/bugs/119341
<seb128> mjg59: not really, I though about it yesterday but I think it's a bit later to change meta packages for the tribe now
<mikmor2> asac: Do you mind me asking you the status of that bug (121439)?
<asac> bug 121439
<mvo> pitti: checking
<ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Incomplete]  https://launchpad.net/bugs/121439
<cjwatson> oops, I forgot to update cdimage to match the string change in gfxboot-theme-ubuntu
<cjwatson> oh well, no disaster
<asac> mikmor2: the upload i just did should allow you to connect to wpa networks
<mjg59> seb128: Ah, ok. It just seemed kind of odd to have the daemon starting by default, but no way of using it :)
<mikmor2> asac: ah, thats what I was waiting for. Thanks.
* Hobbsee waves
<mikmor2> asac: Has anyone check it on the E1505?
<seb128> mjg59: I'm going to rebuild nautilus to use
<mjg59> Sweet
<mjg59> seb128: The other weird thing is that its configuration seems to be a flat text file rather than in gconf - any idea about that?
<mikmor2> asac: I don't see your fix..
<stgraber> mikmor2: I tested it on :  Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) (8086:4222)
<seb128> mjg59: no
<mjg59> Fair enough
<RAOF> mjg59: From my reading of the tracker ML, the author wants it to be DE neutral, so no gconf dependency.
<mjg59> Hm. Irritating.
<seb128> I'm busy enough with GNOME so I did really look at tracker
<asac> mikmor2: i uploaded it a few minutes ago ... so might take a while
<mikmor2> Ok. I have a 8086:4222 in front of me with a fresh install, which I would like to test it on.
<pitti> mvo: is bug 129669 easy to fix? if you touch g-a-i anyway, this might be a good target; it's not a showstopper, though, so I drop the milestone
<ubotu> Launchpad bug 129669 in gnome-app-install ""Show:" textbox has no text after program start" [Medium,Confirmed]  https://launchpad.net/bugs/129669
<seb128> just got in seeded because we said we wanted to give it a try
<mikmor2> great.
<RAOF> Indeed.  Maybe we could point him in the compiz route, and have pluggable config backends :P
<stgraber> mikmor2: running amd64 or i386 ?
<seb128> s/did really/didn't really
<mikmor2> stgraber: i386
<stgraber> mikmor2: ok, so you'll need to wait a few hours :) my test packages are amd64
<mikmor2> stgraber: for more information, http://linux.dell.com/wiki/index.php/Tech/Wireless/Intel_IPW3945 http://linux.dell.com/wiki/index.php/Clients/Products/Inspiron_1505n/lspci
<stgraber> ok, I've the exact same chip in my HP laptop and WPA works fine (still issue with Open Networks)
<mikmor2> Is there a quick recipe for that bug?
<asac> stgraber: i made the deactivate in stage1 more aggressive ... maybe it helps in open networks
<mvo> asac: when I'm in "manual configuration mode" in network manager it seem to tell the world (i.e. pidgin and epiphany) that I'm offline. is that a known issue?
<asac> mvo: not in my mind-set ... though there might be a bug
<stgraber> anyone knows why irssi tends to freeze inside of screen, it's becoming really annoying ? :) (always happen on irssi window change ...)
<mvo> asac: you want me to report it? I think that this is a regression, it used to work some days/weeks ago
<RAOF> stgraber: I use irssi in screen exclusively, and I haven't seen that at all.
<asac> mvo: let me see if i can find a bug ... otherwise, yes.
<stgraber> asac: oh, something else I noticed, "Connect to Other Wireless Networks" tends to crash nm-applet, after relaunching it it works just fine ...
<pitti> mvo: right, that seems to have been unfixed
<pitti> there was some manual_is_always_online.patch or so
<asac> mvo: i don't see a bug for that
<asac> pitti: let me look
<stgraber> RAOF: I suspect it's due to the refresh it's doing while switching to another window as I've my terminal as fullscreen on 1680x1050 and it takes a while to refresh the window ...
<stgraber> RAOF: I should try using it with a "standard" terminal size and see if that still happens ...
<asac> pitti: we still have that patch
<asac> pitti: http://pastebin.mozilla.org/182251
<stgraber> pitti: any idea of when the first Tribe-4 candidate isos will be generated (so I switch current Milestone to Tribe-4 and hide Tribe-3 on iso.qa.stgraber.org) ?
<pitti> seb128: bug 123080 seems to be real according to last comment
<ubotu> Launchpad bug 123080 in gnome-screensaver "[gutsy]  booting after hibernation doesn't prompt for a password" [Medium,Confirmed]  https://launchpad.net/bugs/123080
<pitti> stgraber: I think I will have ISOs that actually install in about two hours
<seb128> pitti: do you get the issue?
<stgraber> pitti: ok fine
<pitti> stgraber: but they will definitively lack some stuff (like new OO.o and n-m), so these will not be final
<pitti> stgraber: they should be shallowly tested for grave installer problems, though
<pitti> stgraber: last ISOs didn't have ubiquity :)
<StevenK> pitti: All of libapache-mod-log-sql libapache-mod-log-sql-dbi libapache-mod-log-sql-mysql python-syck can be NBS'd at your leisure.
<pitti> StevenK: I already did some of them, removed the rest; thanks
<RAOF> stgraber: I do the same thing, with the same resolution, and it doesn't happen :)
<StevenK> pitti: Thanks.
<stgraber> RAOF: lucky you :)
<ogra_> hmm
<pitti> mvo: apt looks good, accepted
<mvo> pitti: thanks
<mikmor2> /afk Ran home to nap for a few hours.
<mikmor2> ..
<pitti> seb128: hibernate doesn't work for me
<pitti> seb128: I can dist-upgrade my laptop and check with suspend to RAM
<seb128> pitti: let me try now
<pitti> seb128: or, wait, i could switch to nv and test on my desktop
<stgraber> pitti: the tracker now has mass-mailing support, so if you want to send a "start can now begin" messages to everyone registered on the website (or the ones having reported at least one result), feel free
<mvo> seb128: I see 123080 here too (just if you need someone who can reproduce it)
<ogra_> gah, why is kino uninstallable ...
<StevenK> ogra_: I uploaded that, I'll look at it.
<StevenK> ogra_: Is there a bug?
<pitti> stgraber: cool
<ogra_> StevenK, no, i just saw irt in the Cd report for edubuntu
<ogra_> seems libquicktime's fault
<pitti> stgraber: does that need an explicit 'Yes, I want to get spam' from the users?
<ogra_> http://cdimage.ubuntu.com/edubuntu/daily/20070807/report.html
<stgraber> pitti: not yet, that'll come with User Profile which isn't implemented yet
<pitti> stgraber: ok, then I'll use it only for one image
<ogra_> StevenK, looks likethat dep was introduced newly with the last merge
<pitti> hi ogra_
<seb128> mvo: gconftool-2 --get /apps/gnome-power-manager/lock/hibernate ?
<StevenK> ogra_: Okay, I think it was pitti's fault, since libquicktime1 landed in universe after it was NEW'd.
<stgraber> yes, just notice them that we are beginning testing, once the "I allow the website to flood me with mails" option will be there they'll receive e-mails for every new ISO posted matching their subscriptions
<StevenK> ogra_: It's since been promoted.
<pitti> ogra_: I am just about to create brand new images for all derivatives, BTW
<ogra_> ok, seems i need a rebuild then
<pitti> ogra_: are you ok with this? or still some blocker from your side?
<pitti> ogra_: it won't be the last images anyway
<ogra_> pitti, oh, thanks, sorry, didnt manage to get the udeb finished ...
<ogra_> i'm fine :)
<pitti> ogra_: we still need OO.o, apt, and n-m at least, but I want to have an ISO soon that actually boots and installs
<ogra_> yeah
<ogra_> i need to test ltsp builds
<stgraber> ogra: is the 50% bug fixed now ? (building ltsp chroot)
<ogra> StevenK, as i said, no :(
<ogra> its my highest prio though
<StevenK> ogra: You missed. stgraber is over there -->
<ogra> lol
<ogra> sorry :)
<stgraber> ogra: oh, just received the bugmail now :) (target changed to Tribe-4)
<stgraber> StevenK: IIRC that's not the first time :)
<StevenK> stgraber: If it isn't you, it's ScottK. :-)
<seb128> mvo: ?
<mvo> seb128: the bug with the screensaver not coming up after suspsend that pitti told you about earlier
<mvo> seb128: I see that one here too
<seb128> mvo: <seb128> mvo: gconftool-2 --get /apps/gnome-power-manager/lock/hibernate ?
<seb128> mvo: that was rather a "could you try that" ;)
<mvo> seb128: both hibernate and suspend are set to "true"
<seb128> ok
<seb128> mvo: does it happen when using suspend?
<seb128> I can't try hibernate, it shutdowns my laptop now
<mvo> seb128: yes, I tested only suspend so far
<seb128> mvo: does it happen without compiz?
* mvo waves to thekorn
<mvo> seb128: yes
<pitti> hi thekorn
<thekorn> hey mvo, pitti
<seb128> hi thekorn
<thekorn> hi seb128
<pitti> seb128: ah, we use rarian by default now?
<pitti> seb128: we now have both rarian and scrollkeeper on the CDs
<seb128> pitti: sort of, yelp uses rarian, I didn't replace scrollkeeper by rarian-compat though
<pitti> seb128: will they bite each other?
<seb128> pitti: no, scrollkeeper is not required, we just keep it because quite some package still call scrollkeeper-update and that sort of things
<seb128> yelp uses rarian which does direct omf indexing
<pitti> seb128: ah, so we'd replace it with r-c after the tribe
<seb128> yes
<seb128> we can do it now if you want
<seb128> but I think it can wait after the tribe ;)
<seb128> mvo: any error to .xsession-errors?
<doko_> seb128, pitti: just in time before you got up this morning ;-)
<pitti> seb128: I agree; I was just curious, if they don't conflict, that's fine
* pitti hugs doko_ 
<seb128> hey doko_
<mvo> seb128: http://paste.ubuntu-nl.org/32890/ <- nothing that looks like screensaver
<seb128> mvo: please stop gnome-screensaver and run it using --no-daemon --debug
<seb128> mvo: that one should have indications ;)
<mvo> seb128: ok, brb, I let the machine sleep now
<cjwatson> pitti: if you have a little time, could I have approval in principle for bug 62986?
<ubotu> Launchpad bug 62986 in debconf "debconf-apt-progress hangs sometimes on SMP systems due to racy debconf protocol handling" [High,In progress]  https://launchpad.net/bugs/62986
<cjwatson> (SRU)
<pitti> looking
<pitti> ah, that one
<pitti> cjwatson: thanks for preparing the test images for that
<pitti> ogra: edubuntu server CDs are up; can you please give this a quick and shallow test?
<pitti> ogra: question for now is "does it install at all?"
<pitti> mvo: good morning, mvo's machine, how did you sleep?
<seb128> pitti: I've just uploaded a new ubuntulooks revision making the new tooltips being yellow
<mvo> seb128: http://people.ubuntu.com/~mvo/tmp/screensaver.log <- but that does not look very helpful
<pitti> seb128: \o/
<mvo> pitti: very good, thanks .)
<mvo> seb128: cool!
<seb128> pitti: that's a one line change, if you could accept it ;)
<pitti> seb128: sure
<seb128> mvo: that doesn't fix the notification bubble color though, dunno why :/
<mvo> pitti: no network on wakeup though, had to do a manual ifup :/
<cjwatson> pitti: yeah, it seemed like the best approach given that the bug isn't 100% reproducible
<cjwatson> I really must get some SMP hardware at some point
<seb128> mvo: weird :/
<mvo> seb128: oh? crap. what name are the tooltips now? "tooltip" or "tooltips"? maybe I got that wrong in the daemon?
<mvo> seb128:  maybe it has something to do with gnome-power-manager, I will investigate that a bit further
<seb128> mvo: https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/129699
<ubotu> Launchpad bug 129699 in ubuntulooks "New style tooltips are not themed correctly due to name change" [High,Triaged] 
<seb128> mvo: that's the theme "workaround"
<seb128> mvo: "gtk-tooltip" is the new naming
<pitti> cjwatson: without having scrutinized the patch in detail, this looks promising to me; we'll test it for UP during the tribe4 release, and since it does not change the behaviour of existing dapper installations, the "breaks the world" potential is very low
<pitti> cjwatson: I propose to upload this to dapper-proposed after the tribe 4 tests were successful, so that we can test both the new debconf in -proposed and the test isos in parallel
<jamiemcc> Hi all - when is the cut off point for tribe 4?
<jamiemcc> I want to release a new version of tracker late ron today
<jamiemcc> with lots of bug fixes and a suspend index on battery
<pitti> jamiemcc: is this a bugfix-only point release? or new features and all that?
<jamiemcc> all bugfixes
<jamiemcc> no new funxctionality
<pitti> jamiemcc: then I should consider it; is there a diff somewhere?
<jamiemcc> its not ready yet - later on today it will be
<cjwatson> pitti: righto. Am I going to have to generate new ISOs, or can I just leave the existing ones there that I've already asked people to test?
<jamiemcc> pitti: just like to know how much time I have?
<cjwatson> I know they won't be quite binary-identical, but it's a script in an arch: all package so the risk seems low
<pitti> cjwatson: no, the existing ones are fine
<pitti> exactly
<cjwatson> ok, great
<pitti> jamiemcc: the current critical path is OO.o, which gives us a magnitude of 15 hours which we can use for modifications without further delaying the release
<jamiemcc> pitti: ok great  will have something ready within about 12 hours
<jamiemcc> will ping you when its done
<pitti> jamiemcc: great, thank you
<cjwatson> pitti: OO.o?
<cjwatson> no recent uploads?
<pitti> cjwatson: calc is building test packages on his box ATM, ETA some 2 hours
<cjwatson> 2.3?
<cjwatson> please say yes
<pitti> cjwatson: he'll get up again when they are finished and test them
<pitti> cjwatson: yes
<cjwatson> fantastic
<pitti> cjwatson: still, this mega-upgrade gives me the creeps, but *shrug* what else shall we do
<pitti> on ubuntu the current packages just work, on kubuntu they are absolutely broken
<cjwatson> we need it before uvf anyway ...
<cjwatson> maybe this will build on powerpc ;)
<cjwatson> (least of our concerns, I know)
<pitti> cjwatson: well, it actually is
<pitti> I'd finally like to see a ppc live CD :)
<pitti> (but not with my RM hat, of course)
<pitti> cjwatson: yeah, I think we just have to bite the bullet
<pitti> calc: after OO.o has built, can you please give me a rough estimate by how many MBs the debs grew compared to the current gutsy version?
<pitti> calc: I'd like to pre-adjust the seeds to make room for it to not waste a CD building cycle
<stgraber> about PPC, I tried yesterday daily on a Powerbook G3, IDE didn't load, once at the debug prompt I loaded ide-generic and ide-cd, it detected the HDD but still no CD :(
<pitti> stgraber: the daily hasn't been updated for ages on ppc
<stgraber> hmm, so it was the "current" ISO :), I'll investigate a bit more when I'll have some spare time as it's weird I can make it to detect the HDD but not the CD-Rom
<stgraber> I don't think there are two different IDE controlers in there
<stgraber> and that's surely not S-ATA (G3 is hmmm very old :))
<cjwatson> pitti: debconf uploaded to dapper-proposed for whenever you're ready for it
<pitti> cjwatson: thanks; I'll keep it until after the tribe (just in case)
<pitti> seb128: ooh, fusa on live system!
<seb128> pitti: is that good or not? ;)
<cjwatson> pitti: sure
<pitti> seb128: shiny for showing off, for sure
<seb128> :)
<pitti> seb128: however, I have my doubts whether this functionality is common enough to waste so much panel space on it
<pitti> seb128: this is a geek feature after all...
<seb128> pitti: what panel space?
<cjwatson> user switching is a geek feature?
<seb128> pitti: well, this space is blank on the top panel anyway, there is no windows list
<pitti> well, how often do you actually switch between several users while you are logged in/
<pitti> ?
<cjwatson> I suppose my wife and stepson are geekier than average, but ...
<seb128> pitti: and I quite disagree about user switching
<stgraber> pitti: it's by default on Mac OS, so not that much of a geek feature :)
<seb128> pitti: people who use window seem to do it often yes
<stgraber> pitti: and Windows users seem to be using that quite a lot (from what I've seen)
<pitti> seb128: yeah, maybe; I just use to log out of my box and switch it of when I'm not sitting at it :)
<pitti> stgraber: yeah, maybe
<seb128> they have accounts for every people in the familly and switch between them
<cjwatson> I think actually geeks are more likely to be diligent about logging out :)
<seb128> pitti: yeah, look like you are the geek here :p
<cjwatson> well, not sure, geeks might have more state on their desktop
<stgraber> cjwatson: geek has its own laptop and doesn't want anybody else to use it :)
<cjwatson> true :)
<pitti> so on the live system it looks a bit weird since you cannot actually do anything with it
<pitti> it would be cool to hide this by default if there is only one user
<pitti> seb128: would that be feasible?
<stgraber> pitti: +1
<pitti> then the single-user case wouldn't get a confusing no-ob control, and the multiuser machines get the shinyness automagically
<seb128> pitti: everything is possible, I would rather not spend efforts on that now, my TODO list is already exploding
* seb128 wants dholbach back
<pitti> seb128: oh, I mean "WDYT about the idea"; this interests me enough to have a look into it
<pitti> seb128: I guess it's not hard to do, after all
<stgraber> pitti: an hack would be to use a script to launch it, if there is >1 uid which is >=1000 launch it, otherwise don't
<seb128> pitti: well, I think it's ok to have the username on the panel even if there is no other user to switch
<seb128> it makes a consistent user experience
<pitti> eek, my desktop just started to beep from somewhere of the CPU area
<pitti> if I disconnect suddenly, please phone me for urgencies :)
<seb128> and not having a label being there or not without any obvious clue for the user
<pitti> stgraber: or just hide itself on startup in that case
<seb128> well, I don't like "random" interface changes much
<seb128> that usually confuse users
<seb128> we will do nothing about the space anyway
<StevenK> But unhide itself on adduser, or what?
<pitti> seb128: well, and I don't like dead things
<seb128> and that still give an indication of what session is used
<mvo> pitti: could you please accept notification-daemon? fix for the window background
<pitti> mvo: sure
<seb128> pitti: it's not dead, it's "who is logged"
<seb128> pitti: and you can right click on the applet to add users, though that's not very discoverable
<pitti> seb128: ah, that's more useful indeed
<pitti> right, I didn't notice yet
<stgraber> asac: ping
<asac> stgraber: pong
<stgraber> asac: I just built manually the NM you uploaded to Gutsy and can't connect to WPA now (it try to disconnects when starting to connect, then get stuck like with Open Network)
<stgraber> (First time I try with 41o)
<asac> stgraber: ok disabling 41o helps?
<stgraber> asac: http://paste.stgraber.org/2379
<stgraber> asac: ok, rebuilding without 41o
<cjwatson> pitti: can I consider your comment in bug 22220 to be SRU approval in advance?
<ubotu> Launchpad bug 22220 in hw-detect "Correct modules for I2O-based raid are not loaded" [Medium,Confirmed]  https://launchpad.net/bugs/22220
<stgraber> asac: as with Open Network I had to killall NetworkManager as there was no way to stop it
<pitti> cjwatson: yes
<asac> stgraber: well ... we already know that *feature* :)
<cjwatson> pitti: the tribe-4 release notes should say that we have smooth usplash on shutdown now
<stgraber> argh, another irssi freeze ...
<asac> stgraber: so if reverting 41o helps I will revert it for tribe i guess
<highvoltage> irssi freeze? whisch version?
<asac> stgraber: the idea was to reset device cleanly instead of just parts ... but well :/
<stgraber> highvoltage: feisty's
<highvoltage> stgraber: ouch. I've never seen that though.
<pitti> cjwatson: hm, the kernel task on 22220 is merely accidental?
<stgraber> highvoltage: 0.8.10-2ubuntu1
<cjwatson> pitti: sounds like it from your comment
<cjwatson> pitti: if you have tasks open on multiple packages, then "nominate for release" adds tasks to all of them
<cjwatson> which is rather unhelpful IMO
<stgraber> highvoltage: when quickly changing window (using keyboard shortcuts) (using irssi+screen)
<pitti> cjwatson: ah, right, 'nomitate for release' has the side effect of creating tasks for all packages
<pitti> heh
<cjwatson> right, so you then have to go and clobber them afterwards
<cjwatson> I noticed that on cdrtools/cdrkit the other day, which irritated me
<pitti> cjwatson: in that case /ubuntu/dapper/+source/foo/+bug shuold help
<cjwatson> yeah, last I checked that did slightly different things to the db though
<pitti> cjwatson: i. e. specifying the ubuntu release in the URL, and then click on 'needs fix here'
<cjwatson> and we managed to get it to leave the db inconsistent at one point
<cjwatson> so I tend to avoid that
<cjwatson> but indeed, that has the right visual effect
<stgraber> asac: works fine without 41o
<norsetto> pitti: can I ask u a question about a possible archive problem?
<Hobbsee> norsetto: (dont ask to ask, just ask)
<norsetto> don't want to bugger him if he is busy .....
<cjwatson> norsetto: so don't bug anyone in particular :) there are several archive adminns
<cjwatson> admins
<stgraber> asac: btw, it's the exact same issue I have with Open Networks so it'd be good to investigate if switching from a network to another doesn't trigger the same function or something like that
<cjwatson> just ask it to the channel in general
<norsetto> I'm having a dep problem in a compilation: java-gcj-compat fails to compile due to missing dep on gcj-4.2
<norsetto> * Considering build-dep gcj-4.2 (>= 4.2.1-2)
<norsetto> * Tried versions: 4.2.1-1ubuntu1j1
<norsetto> and fails, but gcj-4.2 version in archive is 4.2.1-2 and 4.2.1-1ubuntu1j1 is the version for libgcj8-0 !?
<cjwatson> norsetto: gcj-4.2 4.2.1-2ubuntu1 was only published relatively recently; is it possible that this build log is just a couple of days old?
<norsetto> few minutes old
<cjwatson> norsetto: is this a build on our buildds, or on your system?
<norsetto> my system
<cjwatson> norsetto: what mirror are you using?
<norsetto> I think it.archive.ubuntu.com, let me check
<cjwatson> norsetto: what tool is that that you're using to do the build?
<norsetto> no, its archive.ubuntu.com
<norsetto> pbuilder
<cjwatson> norsetto: can I double-check that you've run 'pbuilder update' recently?
<cjwatson> it looks like the local apt cache is just out of date
<norsetto> I did it yesterday indeed, let me check
<cjwatson> because pbuilder just does 'apt-cache show gcj-4.2' in the chroot to fish out available versions
<cjwatson> do it again
<cjwatson> yesterday, it.archive.ubuntu.com might not have had that new gcj-4.2 yet
<pitti> norsetto: back; reading scrollback now
<norsetto> yeah, I did an apt-cache unmet -i | grep Package
<pitti> norsetto: you can always ask me, I just might not answer immediately
<norsetto> thx pitty
<cjwatson> apt-cache unmet would be in your main apt-cache, not in pbuilder's, unless you chrooted as well
<norsetto> oppss: pitti :-)
<norsetto> I did an apt-cache not chrooted and it showed the unmet dep
<norsetto> apt-cache unmet -i | grep Package
<norsetto> Package ia32-java-gcj-compat version 1.0.76-4ubuntu1 has an unmet dep:
<calc> hi
<cjwatson> norsetto: remember to 'sudo apt-get update' first
<pitti> hi calc
<norsetto> cjwatson: yes, I realised that now ... sorry for wasting your time colin
<pitti> calc: are you actually able to think and walk now? :)
* pitti hugs calc
<cjwatson> norsetto: not a problem, I'm not saying there's no problem, just that these are the things to make sure you've done first
<mvo> seb128: will you make "tracker-search-tool" default too? or just tracker (the daemon)?
<cjwatson> norsetto: lib32gcj8-dbg doesn't seem to exist, which would cause ia32-java-gcj-compat to be uninstallable
<seb128> mvo: I think we should add the search tool to the default installation, what do you think?
<cjwatson> norsetto: (that would be a bug)
<norsetto> cjwatson: is there a log you can check or you tried to install it yourself?
<calc> pitti: yea :)
<mvo> seb128: ok, that is fine with me, I'm going over the list of stuff a desktop data updates now and noticed that this is new etc
<pitti> calc: so, please tell me that it built
<ogra> pitti, there is still something wrong with libquicktime1 it seems http://cdimage.ubuntu.com/edubuntu/daily/20070807.1/report.html
<calc> pitti: ooo built the l10n stuff is still going here
<pitti> ogra: hm, that's not on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
<pitti> ogra: any idea what's the reason?
<ogra> not really, its in main proper
<ogra> kino should just pull it in
<calc> pitti: i'll brb going to test the regular debs
<pitti> right, and kino is not installable because of libquicktime, and edubuntu-desktop because of kino
<ogra> right
<pitti> calc: can you test a non-English one later as well? just to see whether it works (and the help)?
<ogra> strange
* pitti logs into gutsy chroot
<calc> pitti: ok
<cjwatson> norsetto: I checked by hand with dpkg
<cjwatson> norsetto: there's a log of uninstallables generated automatically for main/restricted, but not for universe/multiverse - takes too long to generate
<pitti> ogra: hm, with just gutsy/main apt source I can install libquicktime1
<ogra> yeah, me too
<cjwatson> pitti: I tried investigating that same problem a while back and got nowhere, same as you, but I can try again ...
<pitti> ogra: edubuntu live CDs are done, does it affect them as well?
<ogra> live seems oversized
<ogra> hrm
<calc> pitti: ooo combined debs are 103731084 bytes, not sure about l10n yet
<ogra> and the build logs at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/edubuntu/gutsy/ end on aug 1st :(
<pitti> calc: for l10n I only need -en
<pitti> calc: oh, wait, some more, sorry
<pitti> calc: please see apt-cache show language-support-en | grep Depends
<calc> pitti: ok
<ogra> pitti, installing edubuntu-desktop in a blank chroot shows no probs either it seems (indeed i didnt wait until it got through the 480M but no dep probs here)
<pitti> ogra: yeah, apt-get install should abort immediately on conflicts and such
<ogra> right
<ogra> seems it will be done in 30min, i'll let it run until we find anything else ...
<cjwatson> oh
<cjwatson> libquicktime1 depends on libavcodec1d which is blacklisted from CDs per a decision of the Technical Board
<cjwatson> DDTT
<pitti> aah
<ogra> aha
<ogra> we didnt have libquicktime0 deps in kino either
<ogra> (in feisty)
<ogra> i'll drop that
<ogra> cjwatson, thanks for the pointer
<cjwatson> no problem
<cjwatson> libquicktime0 in feisty didn't depend on libavcodec
<cjwatson> in addition to what you said
<cjwatson> so that would be another option if feasible
<cjwatson> well, at least the blacklist works, even if the output is gnomic :)
<ogra> i dont think it builds against libquicktime0 but i'll try
<cjwatson> I meant potentially rebuilding libquicktime1 not to depend on libavcodec
<cjwatson> I don't know whether that's possible
<ogra> ah
<ogra> i'll test that after the tribe release ... for now dropping the dep should be fine
<cjwatson> depends on whether it's more invasive to drop Quicktime support from kino, or to drop whatever libavcodec does for libquicktime, that's all
<ogra> well, we never had quicktime support in our kino versiion
<cjwatson> true
<calc> ok OOo 2.3 debs (not l10n yet) have been verified and they work :)
<asac> stgraber: any news?
<calc> l10n is still compiling for me
<Hobbsee> calc: \o/
<stgraber> asac: works without 41o
<asac> ok
<stgraber> asac: with 41o it gets stuck doing the exact same thing that it does when connecting to open network
<stgraber> asac: except that connecting to open network doesn't directly trigger the disconnect thing
<asac> stgraber: what do you mean by "doesn't directly trigger the disconnect thing" ... you mean in open network case it doesn't run through the 41o code?
<stgraber> I mean that this disconnect the 41o causes for the WPA is similar to the disconnect I have without using 41o but with Open Network
<asac> stgraber: yeah ... i hoped it would shoot in the other direction
<Kmos> asac: bug 80964 - this one isn't fixed already on v2.0.0.6 ?
<ubotu> Launchpad bug 80964 in mozilla-thunderbird "MASTER mozilla-thunderbird crashed [@nsNSSCertificateDB::ImportCertsFromFile]  " [High,In progress]  https://launchpad.net/bugs/80964
<asac> Kmos: no ... its fixed1.8.1.7
<asac> ... so 2.0.0.7
<Kmos> asac: ah ok =) thx
<asac> pitti: nm 0.6.5-0ubuntu9 is waiting for approval
<pitti> asac: what's the reason for disabling that patch?
<ogra> pitti, uploading kino_1.1.0-3ubuntu2 with the dep removed ...
<pitti> asac: ah, I read backscroll now
<pitti> asac: accepted, thank you
<pitti> ogra: ack
<pitti> ogra: no upload from you
<pitti> ogra: so it'll miss this publisher
<ogra> Uploading to ubuntu (via ftp to upload.ubuntu.com):
<ogra>   kino_1.1.0-3ubuntu2.dsc: done.
<ogra>   kino_1.1.0.orig.tar.gz: done.
<ogra>   kino_1.1.0-3ubuntu2.diff.gz: done.
<ogra>   kino_1.1.0-3ubuntu2_source.changes: done.
<ogra> Successfully uploaded packages.
<pitti> ogra: too late to stop the current one, sorry; but I can start a new one immediately after
<ogra> Not running dinstall.
<asac> pitti: thanks
<norsetto> bug 130838: could this be a a gutsy milestone one?
<ubotu> Launchpad bug 130838 in Ubuntu "[gutsy]  lib32gcj8 libraries missing" [Undecided,New]  https://launchpad.net/bugs/130838
<pitti> ogra: still nothing; did yuo get a reject mail?
<pitti> orion2012: that package isn't built any more
<pitti> erm, norsetto ^
<ogra> pitti, not yet, no
<pitti> norsetto: I'll answer in the bug
<ogra> ogra@laptop:~/packages/kino-1.1.0$ ls -lh ../kino_1.1.0-3ubuntu2_source.upload
<ogra> -rw-r--r-- 1 ogra ogra 286 2007-08-07 13:04 ../kino_1.1.0-3ubuntu2_source.upload
<ogra> three mins ago ...
<ogra> might take another two :)
<pitti> doko: can you please have a look at bug 130838 and comment what should happen there?
<ubotu> Launchpad bug 130838 in gcj-4.1 "[gutsy]  lib32gcj8 libraries missing" [Undecided,New]  https://launchpad.net/bugs/130838
<pitti> hey, this silly thing ate my comment!
<Kmos> REVU is down, I can upload ddclient new version 3.7.3 to upload.ubuntu.com ?
<Fujitsu> Kmos: Sure, if you want to get a rejection message.
<Kmos> Fujitsu: so, what I can do ?
<Fujitsu> Kmos: I'm sure you can wait a few hours for REVU to reappear, or upload somewhere else.
<Kmos> i can host in my machine if someone want to
<norsetto> thx for the NBS link: bookmarked
<ogra> pitti, got the "waiting for approval" mail now
<sabdfl> pitti: i noticed that pmount is no longer a dependency of ubuntu-desktop. what's replaced it?
<pitti> sabdfl: a hal backend and gnome-mount
<sabdfl> ok to remove it?
<pitti> sabdfl: i. e. gnome-mount collects the policy (umask etc.), and hal actually mounts it
<pitti> sabdfl: yes, that's fine; we don't install it by default any more since feisty
<sabdfl> ok thanks
<pitti> ogra: accepted
<ogra> thanks :)
<Mithrandir> pitti: speaking of hal; we should really make it use /var/lib/hal/mtab rather than /media/.hal-mtab.
<ogra> pitti, btw, how do i unmount as a user from commandline nowadays ?
<Fujitsu> ogra: gnome-eject?
<ogra> ah
<pitti> ogra: gnome-umount or -eject, yes
* ogra didnt know
<Kmos> bug 112148
<ubotu> Launchpad bug 112148 in linux-source-2.6.20 "kernel BUG at kernel/workqueue.c:323!" [Undecided,Confirmed]  https://launchpad.net/bugs/112148
<ogra> i rarely unmount from commandline :)
<Kmos> this one is already fixed on gutsy ?
<Mithrandir> Kmos: given it doesn't say "Fix released"; no.
<Kmos> Mithrandir: it's kernel 2.6.20, and maybe it's already fixed, not set at LP
<Mithrandir> Kmos: then asking here doesn't help
<ogra> beyond that, gutsy uses 2.6.22
<\sh> Kmos: ask on #ubuntu-kernel and check vanilla if it's fixed there in 2.6.20.X where X>1
<Kmos> \sh: :) ok
<\sh> ogra: if it's in the vanilla 2.6.20 git patch-tree it could be fixed for feisty ;) and should already be fixed in 2.6.{21,22}.x
<mvo> has anyone seen a build failure like http://paste.ubuntu-nl.org/32907/ recently?
<TheMuso> Is there a gconf command that forces all changed settings to be saved to a user's .gconf directory?
<TheMuso> as in, once you log out? SOmetimes they take a while to appear in the .gconf directory tree.
<pygi> Hobbsee, around?
<pygi> how come -archive team didn't get subscribed to the bug if request is fine? :)
<pitti> doko: re 130838> I already said that lib32gcj-bc isn't built any more :) but what happens with lib32gcj7-dev?
<Mithrandir> mvo: looks like @INTLTOOL_ICONV@ hasn't been replaced, for some reason.
<mvo> Mithrandir: thanks, I investigate, that build just fine a couple of days ago
<Mithrandir> mvo: is this on a buildd?
<mvo> yes
<mvo> but happens in pbuilder as well
<pygi> Hobbsee, poke when you're here, thanks
<TheMuso> Never mind, found the gconf setting I was looking for.
<doko> pitti: coming with the next gcj-4.1 upload, already disabled in svn, but gcj-4.1 should be demoted anyway, after OOo is built
<pitti> doko: ah, great
<StevenK> doko, pitti: Do you think there is any point changing the ecj-bootstrap{,-gcj} depends so the two of them can be NBS'd?
<StevenK> doko, pitti: All four of them are universe, so it will have no effect on the tribe.
<doko> StevenK: no, they are not built anymore and should be removed (side note to pitti: packages not built anymore confuse people and should be removed more often)
<pitti> doko: I know, but I don't remove them as long as they still have reverse dependencies in main
<StevenK> doko: If they're removed, all four of the packages become uninstallable.
<pitti> doko: I do removals daily :)
<Kmos> pygi: the bug is already acked ?
<pygi> Kmos, yes, but archive doesn't seem to be subscribed :)
<pygi> lemme settle it with Hobbsee
<pygi> when she's back
<Kmos> pygi: so the MOTU forget it.. you can subscribe
<Kmos> she does something like that to a sync i've request
<pygi> Kmos, don't wanna do that ;) Have patience :)
<Kmos> :)
<Hobbsee> pygi: poke
<pygi> Hobbsee, :)
<Kmos> pygi: patience isn't good for my stress :))
<pygi> Hobbsee, the bug where I requested libswfdec sync .. you acked, but didnt subscribe -archive team?
<Hobbsee> pygi: probably because i forgot to do ti.
<StevenK> doko, pitti: To be honest, it's a grand total of 10 minutes, but adds (admitedly, small) Ubuntu changes to three packages.
<Hobbsee> pygi: please subscribe u-a then
<pygi> Hobbsee, oki, will do ;)
<pygi> Hobbsee, thanks
* Hobbsee is being driven mad, it seems.
<pygi> Hobbsee, I agree, because you gave back swfdec-mozilla without swfdec :)
<pygi> subscribed
<Hobbsee> pygi: a) i didnt give back anything and b)  i thought i requested 2 things with that block.
<Hobbsee> (of givebacks)
<pygi> Hobbsee, ok, you request give back :)
<StevenK> pitti: libgcj8-0 can be NBS'd at your leisure.
<pitti> yay
<Hobbsee> pygi: you know, i could have sworn that i requested both swfdec and swfdec-mozilla to be given back.  weird.  maybe i really am going insane, then.
<pygi> Hobbsee, don't worry, I'm covering you
<Hobbsee> oh good
<pitti> StevenK: killed (lib32gcj-bc too, it's uninstallable anyway)
<StevenK> pitti: Shall I deal with ecj?
<pitti> StevenK: I'd like to defer that question to doko
* StevenK nods.
<infinity> StevenK: What's wrong with ecj?  We just had an upload...
<doko> StevenK: fix tomcat5.5, or look if it needs a sync
<StevenK> infinity: Not ecj per se, there are four packages that depend on ecj packages that are no longer built by it.
<infinity> StevenK: Ahh.
<StevenK> infinity: Can I flutter my eyelashes at you now? *hint*
* Mithrandir jumps on Hobbsee, then runs off.
<infinity> StevenK: If you want me to hurt you.
* Hobbsee arghs, splatted on the ground!
<StevenK> infinity: Not particularly, you don't seem my type. :-P
<StevenK> infinity: I'd just like to get yada out of main before tribe 4.
<infinity> StevenK: A worthwhile goal.  Alright, I'll look at it tonight.
* Hobbsee gets up, runs after Mithrandir, and tickles him, occasionally stomping on his feet
<infinity> StevenK: Since doko's not abusing me today.
<infinity> Hobbsee, Mithrandir : Stop flirting in public channels, it's distracting.
* Hobbsee wishes rsync would go a little faster
<Hobbsee> infinity: yet.
<StevenK> doko: Shall I fix kaffe too?
<Hobbsee> ...
<doko> StevenK: if you want, sure, and be prepared for the then coming debian merges
<StevenK> doko: Happy to do so.
<StevenK> Which leaves ikvm and eclipse
<StevenK> ikvm needs a merge/sync from Debian anyway. And eclipse is a dog and I'd rather not touch it, but it's a one line patch.
* StevenK ponders digging up infinity's phone number and calling him every thirty minutes, "Have you looked at it yet?" :-P
<Mithrandir> StevenK: I think you might end up with a very angry infinity that way.
<Hobbsee> Mithrandir: as long as StevenK's hidden, he should be OK
* Fujitsu wonders how many Conrads there are in [insert the suburb here] 
<StevenK> There's no might about it. :-P
<StevenK> Fujitsu: I have means, and it doesn't involve a phone book.
<Fujitsu> Hah.
* StevenK points to his sekret DD powahs
<Fujitsu> Aha.
<StevenK> Well, not so secret. :-P
<StevenK> Ew! kaffe uses DBS
<StevenK> I washed my hands but the dirt isn't coming off!
<Mithrandir> use some of that cleaning liquid you use for cleaning coffee makers?
<tkamppeter> hi pitti
* StevenK twitches, remembering what happened on All Saints tonight.
* Fujitsu wonders why StevenK was watching that.
<StevenK> Because ...
<infinity> StevenK: Not sure if my phone number is current in ud-ldap...
<StevenK> I think mine is, but only because it hasn't changed in 7 years.
<norsetto> following bug 129742 the turkey package needs to be moved to multiverse; should I open a new bug asking for this?
<ubotu> Launchpad bug 129742 in turkey "[ftbfs]  turkey ftbfs on gutsy" [Undecided,Confirmed]  https://launchpad.net/bugs/129742
<infinity> norsetto: Telling users they have to change their alternatives to use the package seems a bit odd.  Is there no way to change it to call the sun jvm directly, regardless of alternatives configuration?
<norsetto> infinity: I wouldn't do that
<geser> pitti: will gutsy ship both emacs21 and emacs22 in main?
<norsetto> infinity: what if the user wants to use whatver jvm they have installed? we shouldn force a particular one
<infinity> norsetto: Err, what?
<infinity> norsetto: You claim the package can't work with anything but the Sun JVM, right?
<norsetto> infinity: but, if they want to use turkey, they know they have to use the sun one
<infinity> norsetto: So, making the package call the SUn JVM directly makes more sense than forcing the user to mangle their alternatives.
<infinity> norsetto: Look at this from a simpler POV.  If you have a shell script that relies on bash to run, you use #!/bin/bash, you don't tell the user to change his /bin/sh symlink from dash to bash.
<norsetto> infinity: what do you mean making the package call sun jvm?
<infinity> norsetto: ...
<asac> stgraber: https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
<infinity> norsetto: You wrote a README that states that to use the package, the user needs to change the "java" altrenative to point at the Sun JVM.  If the Sun JVM is the only java it will work with, you should make the package call the Sun JVM where it's insalled, not call the "java" alternative.  (See the '/bin/sh' example above to get my point)
<norsetto> infinity: is it possible to force a java application to use a particular jvm?
<geser> norsetto: add a small wrapper script (if none exists) to call turkey with sun-java (or how the binary is called) instead of /usr/bin/java
<stgraber> asac: bzr getting
<infinity> norsetto: I'm sure it is.  It's just an interpreter.
<norsetto> infinity: I have to investigate this, right now I wouldn't know how to do it (geser might know though)
<infinity> norsetto: It's just bad form to tell a user "to use my package, you MUST use this JVM for all the java apps on your machine" (or, you MUST use this shell, or whatever)
<infinity> norsetto: If they have multiple JVMs installed, they might have a valid reason to prefer another for their day-to-day work. :)
<norsetto> infinity: exactly my point
<norsetto> infinity: I made wrappers like geser said for python and mono applications, but never seen them for java
<norsetto> infinity: and didn find mention in the debian java policy docs
<norsetto> infinity: so, just assumed they didn exist; you and geser are hinting that they exist; ok, let me investigate this
<norsetto> infinity: if it is possible, I agree it the best way
<infinity> norsetto: The "turkey" binary is a shell script that calls "exec java -jar /usr/lib/java/turkey.jar "$@""
<infinity> norsetto: Changing that from "java" to /usr/lib/path-to-sun-crap/bin/java" should do the trick, no?
<norsetto> infinity: I don know, its worth trying it out
<cjwatson> (hint: the answer is yes ;-))
<norsetto> infinity: assuming this works, what is the best way to move this to multiverse?
<infinity> norsetto: When the next upload depends on stuff in multiverse, germinate will notice, and we might even remember to move it.
<infinity> norsetto: Or, I could just move it.
<infinity> norsetto: If you went with the former "waiting on it to be moved" option, though, a bug filed on the package "needs to move to multiverse", with ubuntu-archive subscribed, might help.
<norsetto> infinity: I can do whatever is best for you guys
<infinity> norsetto: I'll just move it now.  Get a fixed package in the archive though, please. :)
<norsetto> infinity: sure will do, on my way .... thx
<cjwatson> infinity: we don't have any automatic detection for should be in universe vs. multiverse, unfortunately
<infinity> cjwatson: Oh.  We really should.
<infinity> cjwatson: Too CPU intensive, or just don't bother?
<cjwatson> bit of both
<cjwatson> britney is definitely too CPU intensive
<infinity> And I meant anastacia, not germinate, but whatever.  Not on full thrust right now.
<cjwatson> germinate might be doable somehow if you could figure out how to express it
<infinity> Or did we still never port anastacia to the new world order?
<cjwatson> well, anastacia is basically a cunning germinate frontend ...
<cjwatson> ported it to LP long ago
<cjwatson> still uses germinate though
<infinity> Yeah, kay.  Thought so...
<infinity> Right.
<cjwatson> well, um. if "uses Packages files" counts as "ported to LP".
<cjwatson> I think it used to use the dak db
<cjwatson> :qa
<infinity> I wonder how painful it would be to just do it raw, against the lp_prod database.
<infinity> norsetto: Moved.
<norsetto> infinity: the patch in 129742 already went through I think. Will post a new patch to fix the script ok?
<infinity> norsetto: Sure.
<norsetto> infinity: okki dokki, thx for all
* StevenK kicks kaffe for FTBFS.
<pitti> hi tkamppeter
<stgraber> asac: no change with this patch
<pitti> stgraber: you mean latest n-m upload doesn't make it work again?
<tkamppeter> hi pitti
<tkamppeter> I got SVN write access for system-config-printer now, and Tim Waugh accepted all my patches.
<tkamppeter> So all my idiot-proofing/usability enhancements on s-cp are upstream now.
<pitti> tkamppeter: great
<stgraber> pitti: the branch you gave me half an hour ago
<pitti> tkamppeter: so, although I still think that the UI is somewhat complicated, with the autoconfig magic many users don't need to touch it any more, and it actually works really well now
<stgraber> pitti: .opennet
<pitti> stgraber: ah, for the other bug
<tkamppeter> pitt, the collaboration with Tim is very good, so I think now we can safely drop the gnome-cups-manager and replace it by system-config-printer.
<stgraber> argh, I mean the branch asac gave me
<pitti> tkamppeter: I tend to agree
<pitti> stgraber: I figured :)
<tkamppeter> pitti, I think it is no problem now to add a printer. User clicks "Add Printer", enters queue name, Next, then a list of printers appear and the user cannot do anything wrong, especially because if a printer is supported by HPLIP only the HPLIP version is shown.
<asac> stgraber: do you see if nm tries to use wpa for opennet?
<cjwatson> mvo: could you look at bug 130843? it looks to me like it's getting stuck inside its python-apt code
<ubotu> Launchpad bug 130843 in ubiquity "desktop install hangs at 96%" [Critical,New]  https://launchpad.net/bugs/130843
<tkamppeter> I even would like if you ditch gnome-cups-manager from Tribe 4 and replace it by system-config-printer, so that users test before feature freeze.
<stgraber> Aug  7 14:50:49 laptop NetworkManager: <info>  Device eth1 activation scheduled...
<stgraber> Aug  7 14:50:49 laptop NetworkManager: <info>  Activation (eth1) started...
<Mithrandir> tkamppeter: that's a bit on the late side.
<stgraber> Aug  7 14:50:49 laptop NetworkManager: <info>  Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
<stgraber> asac: that's all I got
<stgraber> asac: and the "Aug  7 14:51:15 laptop NetworkManager: <info>  Activation (eth1): waiting for device to cancel activation.
<mvo> cjwatson: looking
<stgraber> when I try to make it switch back to LAN or another WLAN
<pitti> tkamppeter: sorry, that won't happen
<tkamppeter> Mithrandir, so better do the change the day after Tribe 4, post on all list to ask evereyone for an intensive Ubuntu-internal testing so that it is ready for Tribe 5?
<pitti> tkamppeter: yes, that sounds good
<StevenK> pitti, doko: Updated tomcat5.5 uploaded.
<pitti> tkamppeter: then we still have some time for some UI improvements if we need to
<tkamppeter> So I will report a bug against gnome-cups-manager milestoned to tribe 5 with priority high.
<asac> stgraber: so you never get "Activation (%s) Stage 1 of 5 (Device Prepare) started..." ?
<asac> stgraber: oh sorry
<asac> stgraber: nevermind
<alex-weej> anyone else experiencing trackerd just eating all your memory and then crashing? and to top it off apport claims to not have enough memory to report the bug.
<pitti> alex-weej: apport-wise that sounds consistent, though
<alex-weej> pitti: i don't expect apport to grow memory out of nothing :)
<pitti> alex-weej: that would be a really cool feature, though!
<alex-weej> yeah, maybe mark it for gutsy+1
* pitti registers apport-memory-dimensional-shifter
<Mithrandir> pitti: I'd probably call that feature mmap and assign a syscall for it, if I ever were to implement such a thing.
<asac> stgraber: its strange ... cancel activation is only called when device gets fully deactivated ... but since 41o was dropped we don't do that anymore :/
<asac> stgraber: ah ... now i read that you get the cancel activation message when you try to switch network ... ok.
<stgraber> asac: yes, but it never managed to switch and NM got stuck at this point (killall NetworkManager to reset)
<asac> thats strange
<asac> stgraber: can you still tweak your device with iwconfig ?
<asac> or is that locked too now?
<stgraber> IIRC I can set some stuff with iwconfig but it will never associate
<asac> and no output from nm?
<stgraber> asac: just did another try, so no NM doesn't give any output beside : "Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... "
<stgraber> I tried setting essid and bssid by hand with iwconfig and no success
<stgraber> (iwconfig keeps saying unassociated)
<pitti> stgraber: does 'iwconfig eth0 ap any' help?
<pitti> stgraber: that sometimes helped for my card in the past
<pitti> stgraber: at least for "AP: invalid"
<stgraber> pitti: I just tried and no it doesn't (as it's already Not-Associated)
<mvo> hm, while trying to reproduce #130843 my VM (256mb ram) locked itself hard :/
<pitti> mvo, cjwatson: I just downgraded apt and python-apt to feisty on the live system, then the install actually worked
<pitti> mvo, cjwatson: surprising, I had assumed it uses the chrooted apt
<mvo> pitti: I'm checking the problem out currently, with more ram in the vm it seems to continue here
<pitti> mvo: I use 768 MB usually, that's smooth enough
<seb128> pitti: have you updated to the new glibc already?
<pitti> seb128: on my desktop? yes
<seb128> pitti: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/130852
<ubotu> Launchpad bug 130852 in pidgin "[gutsy]  Pidgin 2.1.0 crashes on the freshly updated libc6" [Undecided,New] 
* agoliveira was just remembred by the nth time why rm -rf is evil :(
<seb128> pitti: did you try running pidgin since?
<seb128> (I'm doing the upgrade at the moment, didn't try yet)
<pitti> seb128: yes, my session starts it by default, and it seems to work fine
<coNP> You cannot talk to anyone.
<coNP> At least I cannot.
<seb128> ok, so it's not a "it's crashing for everybody"
<seb128> coNP: oh?
<pitti> coNP: let me try
<coNP> It is crashing if you actually want to communicate I guess
<seb128> might be a new tribe-4 issue if that's happening to everybody
<coNP> I am not sure if it happens to everyone
<pitti> coNP: I sent something to a friend of mine (ICQ), wiating for response
* wasabi uninstalls tracker
<pitti> coNP, seb128: just got a response from a friend of mine, works well here
<coNP> It is very good if it does not affect everyone :)
<pitti> coNP: do you use ICQ? or jabber or something?
<seb128> wasabi: what about opening bugs rather than mentionning it on IRC without any reason?
<coNP> Now it works for me.
<coNP> GMail/Jabber
<geser> pitti: will gutsy ship both emacs21 and emacs22 in main?
<coNP> Some MSN, maybe I try to contact one of them
<pitti> geser: no, only 22 eventually, when the remaining reverse dependencies are settled
<geser> pitti: so it's ok to sync request packages replacing emacs21 with emacs22 in depends?
<coNP> pitti: Cool, it *works* as well.
<pitti> geser: oh, please do so
<pitti> coNP:  it's a kind of magic 
<coNP> But it didn't, I guess it might be that it does not work for everyone, at some stage of updates.
<asac> stgraber: and without nm?
<cjwatson> why does deskbar-applet use 17MB of non-shared memory?
<infinity> StevenK: Did libnss-db really need config.{sub,guess} updated in the diff.gz?
<stgraber> asac: without NM I just iwconfig eth1 essid test
<stgraber> asac: and the second after I'm associated
<stgraber> asac: btw, I just had a strange behaviour, after an unsuccessful NM connect to "test", eth1 keeps being unassociated even when setting it with : iwconfig eth1 essid test
<asac> stgraber: so do you see if wpa_supplicant is started?
<stgraber> asac: looks like NM does something that makes the card unable to associate
<asac> (when connecting to open net)
<stgraber> I don't think it's but let me check
<infinity> StevenK: A few things.  debian/copyright is boilerplate, it needs to have real content.  debian/patches/foo were gratuitously renamed from .patch to .dpatch ... dpatch can function with arbitrary extensions (can't it?), so keeping the filename in place would minimise the diff to "just adding dpatch headers"...
<stgraber> asac: oh, this time was weird, I was able to do : wpa -> open -> wpa (which usually doesn't work), then the 3-4 next tries tried to connect with open but failed and fallback to wpa (which usually doesn't happen), then finally I had a usual freeze :)
<stgraber> asac: so when NM freezes wpa_supplicant isn't running
<stgraber> asac: (as It's stuck at Stage1)
<asac> stgraber: did it ever work better?
<asac> (in gutsy)
<stgraber> asac: I usually don't connect to open network, but I'd say no
<stgraber> asac: I never saw it working
<cjwatson> pitti: I'm sitting here reading through an strace now trying to work out where all the file descriptors are going
<cjwatson> pitti: I may be some time
<cjwatson> I can see where it's hanging, just need to trace it back out
<seb128> pitti: I've just uploaded a gnome-python-desktop revision fixing the -dbg build by adding Build-Depends, if you could accept it
<pitti> seb128: sure (not that we would care, but *shrug*) :)
<seb128> pitti: I do care because it breaks the build of other packages ;)
<cjwatson> pitti: I have a suspicion that the dpkg logging work may be implicated
<pitti> indeed, that's a new thing
<pitti> seb128: ah, in the queue now; accepted
<cjwatson> my suspicion is more based on the fact that that's where the debconf output is going that ubiquity is sitting waiting for
<mvo> cjwatson: I'm looking at the code currently and it seem to me like it would be a good idea to clean it up a bit as some of the required functionality did move into python-apt nowdays
<cjwatson> mvo: oh, quite possibly, it's just low on the list as it's so hairy
<cjwatson> and I think it will still have to work in a somewhat different way due to its debconf interaction
<mvo> cjwatson: right, is there a way to skip the steps before it starts installing? it may well be enough to disable the logging feature
<cjwatson> you can't really skip that and retain a useful test, no
<cjwatson> basic problem seems to be that apt is intercepting debconf protocol output and thinking it's terminal output
<cr3> who should I speak to about either updating hwdb-client or replacing it?
<cjwatson> cr3: ogra
<mvo> cjwatson: but it does not write it to /target/var/log/apt/term.log?
<mvo> cr3: I have a certain interesst in this as well
<cr3> mvo: cool, I'll send an email to both of you
<cjwatson> mvo: as it happens it hasn't (it may just not have flushed it), but that's entirely not the point
<cjwatson> mvo: actually, it's worse than that, it's intercepting stdin from the ubiquity process that's doing apt<->debconf translation, apparently thinking it's dpkg output
<pitti> doko: what will uname -m return on lpia?
<pitti> doko: (that should probably go on https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap)
<mvo> cjwatson: any output it intercepts should be written out verbatim again
<cjwatson> mvo: to the wrong place
<cjwatson> mvo: it writes it to the terminal, but not to its stdout
<cjwatson> 12677 read(0, "1 OK\n", 256)            = 5
<cjwatson> 12677 write(18, "1 OK\n", 5)             = 5
<ijuz> i was just trying to install the 20070807.1 live-cd for i386 and it stuck at 96%, is there some way to see what made it to stop?
<cjwatson> ijuz: we're just trying to work that out now
<cjwatson> ijuz: you're not the only one
<ijuz> ah, ok :)
<elmo> mvo: <random>hey could you make apt depend on gpgv instead of gnupg someday?  I split the package out for that reason :)
<pitti> infinity: what will uname -m return on lpia?
<infinity> pitti: i686
<pitti> hm, erk
<infinity> pitti: But you really shouldn't be relying on uname for anything...
<infinity> pitti: What's the context?
<pitti> infinity: but we don't have libc6-i686 on lpia, right?
<mvo> elmo: yes, also gnupg is needed for apt-key currently (but that might be changed) so gnupg will still be a recommends or something liek this
<pitti> infinity: checking my first package for lpia compatibility (apport)
<infinity> pitti: No, we don't, cause libc6 on lpia is i686-optimised already.
<pitti> infinity: it would currently mean that you (1) cannot tell apart i386 and lpia crashes by tag, and (2) the setup script for a retracer will fail on lpia
<infinity> pitti: But why is it using uname at all?
<infinity> pitti: You can have an i386 system with an x86_64 uname, for instance.
<cjwatson> mvo: I might see if I can figure out how to make ubiquity use different fds for debconf at that point to avoid this evil
<pitti> infinity: to determine which retracer will process a crash
<pitti> infinity: e. g. you cannot process an i386 core dump on a powerpc gdb
<cjwatson> though that will involve a select loop
<pitti> infinity: filing a bug will create a tag need-{i386,amd64,powerpc,sparc}-retrace
<pitti> infinity: so crashes on lpia will be marked as i386
<mvo> cjwatson: alternatively I can add a option for you that will skip this whole logging mess in libapt
<pitti> infinity: you can still see the "PackageArchitecture: lpia" in the bug, so it doesn't matter that much
<infinity> pitti: So, what happens in the case of an amd64 kernel with an i386 userspace?
<infinity> pitti: (I know it's not a supported configuration, but...)
<pitti> infinity: that will hit the amd64 retracers then
<pitti> infinity: if the user can install something like ia32-libs, then the retracer shuold be able to as well
<pitti> infinity: (I don't support third-party packages)
<cjwatson> mvo: mm, I'm thinking very hard :)
<infinity> pitti: I'm not talking ia32-libs, but rather an entire i386 userspace on an x86_64 kernel.
<pitti> infinity: well, I guess I'll just convert it all to dpkg --print-architecture (which I already have, but I don't use that one for determining the tag)
<infinity> pitti: --print-installation-architecture
<pitti> infinity: uname is much more portable, though, so I used that; I have to look into that more deeply
<infinity> pitti: The other option is to make apport arch:any, and hardcode the dpkg arch at build-time.
<infinity> pitti: Saves you an expensive call to dpkg at runtime.
<pitti> infinity: there are worse things than that call
<pitti> infinity: and it'd make the retracer setup much more complicated
<bddebian> Howdy
<infinity> pitti: I don't doubt there are worse things. :)
<pitti> infinity: ok, thanks for the heads-up
<infinity> pitti: Like firing up python.
<pitti> like gzipping a 300 MB core dump or calling gdb on it, or doing dpkg -S (-ish, I optimized that already)
<cjwatson> mvo: I think a better answer is for me to have ubiquity invoke pm.DoInstall() </dev/null
<pkl> nick pkl_
<cjwatson> mvo,pitti: comments on http://people.ubuntu.com/~cjwatson/tmp/ubiquity.130843.diff? I'm testing it now.
<bddebian> Wow, disappear for a couple of months and you get no love. :-)
* pitti hugs bddebian 
<pitti> cjwatson: ah, great! want me to test as well?
<norsetto> mvo: did you get my email about justinwray?
<cjwatson> pitti: sure, can't hurt
<cjwatson> apply that to /usr/share/ubiquity/install.py
<mvo> norsetto: yes, sorry, I'm badly behind with mail
<Amaranth> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<Amaranth> how can i make dpkg-source stfu?
<Amaranth> i'm doing a build for my PPA but i don't want to change stuff :)
<Amaranth> oh, this isn't -motu...
<cjwatson> Amaranth: DEBEMAIL=<something not at ubuntu.com>
<norsetto> mvo: np; I can imagine :-)
<cjwatson> /usr/bin/dpkg-source is a Perl script, search for the error message in it and it's the first hit ...
<Amaranth> oh, so the message is incorrect and it's reading my email in the changelog and not the version?
<coNP> no, it uses debian/control
<cjwatson> Amaranth: the message is correct, but changing DEBEMAIL downgrades the error to a warning so you can continue
<Amaranth> right, which i didn't want to change
<bddebian> pitti:  :-)
<cjwatson> you can just change it temporarily in the environment
<cjwatson> anyone without 'ubuntu' in DEBEMAIL is assumed not to care about our DebianMaintainerField spec
<Amaranth> cjwatson: thanks, that made it shutup :)
<pygi> who broke the n-m this time :-/
<seb128> pygi: would be asac?
* pygi will look in changelog what happened
<seb128> pitti: can you accept nautilus? it's built with tracker
<seb128> pygi: what is broken?
<pygi> seb128, it won't connect to my network
<pygi> WPA2-PSK
<asac> pygi: please send any complaints to devnull@jwsdot.com :)
<asac> pygi: what chipset?
<pygi> just fetching new updates
<desrt> seb128; taking bets on if tracker remains fully-enabled in gutsy final?
<seb128> desrt: no ;)
<jamiemcc> desrt: should do if ioprio is sorted
<seb128> desrt: any opinion on that?
<asac> pygi: and more importantly ... which version of nm are you on atm?
<seb128> desrt: let's have a look at user bug reports
<doko> pitti: i686
<desrt> seb128; let's just say that it's a very exciting time.
<desrt> :)
<seb128> ;)
<pygi> asac, what did you get last?
<pygi> <asac> pygi: what chipset?
<pygi> <pygi> just fetching new updates
<pygi> <pygi> asac, ipw2200
<pygi> I just upgraded, seems fixed
<asac> ok so the dragon flew away?
<Amaranth> ooh, it'd be really nice if i could use nm with WPA2 again :)
<asac> pygi: ok then have fun :)
<pygi> asac, thanks for the work ;)
<asac> Amaranth: ipw3945?
<Amaranth> asac: yeah
<asac> Amaranth: if so give latest a try
<asac> Amaranth: should work
<Amaranth> alright
<Amaranth> no more WEP!
<asac> Amaranth: open network has problems ... but wpa is hopefully fixed now :)(
<pygi> asac, ubuntu8 was a problem /me guesses =)
<asac> yes ubuntu8 was a fun upload :)
<geser> pitti: is it ok to request syncing rub1.8 (new upstream version) from Debian to drop the emacs21 dependency from ruby1.8-elisp?
<asac> to wake up the crowd ;)
<pygi> haha :)
<desrt> seb128; k.  let me put it this way
<pitti> geser: if it doesn't require a large transition otherwise, then yes; we are still before UVF
<pitti> geser: and ruby has an extensive test suite and all that
<desrt> seb128; if tracker remains fully-enabled in gutsy final then my respect for jamiemcc will increase quite a lot :)
<jamiemcc> lol
<desrt> since, no matter how you slice it this is gonna be a shitstorm :)
<cjwatson> pitti: that ubiquity patch works for me
<pitti> cjwatson: yay! mine is at 78%
<mvo> cjwatson: I would like to create a testcase for DebconfInstallProgress to get some simplification going, I wonder if there is a way to pass it a fake debconf.Debconf() that just echos the communication ?
<cjwatson> pitti: there's a bunch of non-uploaded stuff in ubiquity bzr, but I guess you'd prefer me to upload just that patch?
<cjwatson> pitti: it's mostly mythbuntu
<Amaranth> desrt: Well, we do have rather high standards :)
<jamiemcc> desrt: I have a few months I hope to fix things!
<Amaranth> desrt: That's why we didn't have either one before
<cjwatson> mvo: sure, you just need to arrange to return something sensible
<Amaranth> jamiemcc: Hey, I've actually been looking for you :)
<pitti> cjwatson: does it affect the ubuntu/kubuntu behaviour at all?
<jamiemcc> hi amaranth
<asac> pygi: ok i added you to the list of dedicated ipw2200 testers for nm now :)
<cjwatson> mvo: I think you actually have to have reads/writes in order to catch this problem though
<ijuz> when you use the alternate CD at some point the installer shows you resolutions to choose from, what package is that? (because... when it appears my screen it just glibberish starting at this point)
<asac> pygi: thanks for volunteering ;)
<pitti> cjwatson: if so, then I'm hesitant now
<pygi> asac, ergh!
<cjwatson> mvo: because the problem here was that ubiquity wrote a debconf command, and then apt read the debconf reply before ubiquity had a chance to do so
<pygi> asac, well, /me did work on packaging nm for dapper, but he's sure he didn't volunteer this time for testing
<mvo> cjwatson: yes, my initial though was to create a fake-debconf class, but that would not have got this problem so it needs to be something more elaborate
<cjwatson>   * Don't dump debug information to the console when using --automatic.
<cjwatson>   * Get the user password straight from debconf in noninteractive mode.
<cjwatson>   * Add partman-auto-loop.
<Amaranth> jamiemcc: There is this project called timevault (guess what it does) but I don't have enough inotify watches for it and tracker, is there some way it can hook into tracker so it can do the snapshot thing when tracker is indexing?
<cjwatson> pitti: those three could change behaviour, so I'm happy to postpone
<cjwatson> mvo: just using debconf.Debconf() itself without a frontend running should do the job
<jamiemcc> amaranth: possibly - doe sit just need notification?
<cjwatson> mvo: it'll echo to stdout and read from stdin
<pitti> cjwatson: thanks, that would be better, I think
<cjwatson> mvo: and then either run that inside a test harness that pretends to be a frontend, or type at it
<Amaranth> jamiemcc: right
<mvo> cjwatson: that sounds good, I have a look now
<Amaranth> jamiemcc: just needs to be notified when tracker sees a file change
<jamiemcc> amaranth: then yes in the near future we could do so
<jamiemcc> atm we dont expose signals but its easy to do
<Amaranth> jamiemcc: since you also have some stuff to handle running out of inotify watches, right?
<pygi> asac, o well
<Amaranth> don't want to redo that again and again
<jamiemcc> amaranth: we used to poll but scrapped that as it made peoples machines hot
<jamiemcc> now we check on startup if files have changed
<wasabi> Somebody refresh me on launchpad bug ettiquite. I have a critical bug that makes an important package in main completely not useful, it really must be fixed before next release. Critical, Milestone = ?
<Amaranth> jamiemcc: Oh, so that's why it does a lot on every login :)
<jamiemcc> well we have to get the directory tree
<jamiemcc> so its not a lot really
<pygi> wasabi, perhaps tribe4 if it can be fixed on time? You volunteer? :)
<pygi> wasabi, what's the package?
<wasabi> samba/winbind
<jamiemcc> when a file changes the parent directory also changes its mod time
<Amaranth> jamiemcc: But then if I never logout (say I have an uptime of 2 weeks) the index will be really out-of-date, no?
<jamiemcc> so we only check directories
<wasabi> Actually, I'm making sure the latest update didn't fix it just now.
<wasabi> bug 118977
<ubotu> Launchpad bug 118977 in samba "winbindd will not start do to invalid cache path" [Critical,New]  https://launchpad.net/bugs/118977
<jamiemcc> amaranth: yes unless you increase inotify watches
<Amaranth> jamiemcc: You could get notified when the screensaver is active and do the update then
<wasabi> Nope, not fixed.
<wasabi> So tribe-4 is the appropiate milestone?
<jamiemcc> possibly - we plan on easing polling back it once we are happy it has no detrimental effect on performance
<pitti> seb128: and that won't break the desktop, no? :)
<Chipzz> jamiemcc = tracker upstream? :)
<Amaranth> Chipzz: yep
<seb128> pitti: should not ;)
<jamiemcc> Chipzz: yes
<Chipzz> jamiemcc: congrats on getting tracker in ubuntu :)
<jamiemcc> lets hope we remain there :)
<ion_> Yay for tracker 
<Amaranth> It's funny, I actually never use it
<pygi> wasabi, you should poke a folk who did couple last uploads and discuss
<Amaranth> But I've kept it around for the last month or so
* pygi disabled tracker here :P
* coNP uses pbuilder to eat system resources. Most users might want tracker for that
<wasabi> soren: poke. =)
<pygi> coNP, hehe :)
* desrt likes coNP's nick
<ogra> eeek
<Chipzz> jamiemcc: at the very least it should get you a lot of testing and feedback ;)
<Hobbsee> ogra!
<Amaranth> coNP: It doesn't eat resources :)
* Hobbsee hugs ogra 
<jamiemcc> Chipzz: yeah
<Chipzz> even if it ends up not being included
* desrt eyes Hobbsee with suspicion
<pitti> cjwatson: install succeeded here as well
<Chipzz> and I guess testing and feedback is something you could use ;)
* Hobbsee shines her red eyes at desrt 
<ogra> pitti, ltsp-client-builder fails on the edubuntu server CD :/ with a Packages.gz hash sum mistmatch ...
<cjwatson> pitti: rock on
* desrt lives in fear
<cjwatson> pitti: I'm just waiting for LP to create the branch for me
<pitti> ogra: )#$*#@
<jamiemcc> sure - I just hate it when kernel changes stuff and causes proplems in tracker
<ogra> which is weird since the same pacakges file was just used to install the base and edubuntu-desktop
<pitti> cjwatson: and I'm  waiting for the shiny new OO.o packages to actually show up in unapproved :)
* pitti yays calc
<Amaranth> jamiemcc: Where would I look in the tracker code to find how it manages to use only idle CPU?
<jamiemcc> nice(19)
<jamiemcc> ioprio
<Amaranth> That's all it is?
<Amaranth> Wow, CFS much be helping a lot then :)
<jamiemcc> yes it depends on kjernel working
<jamiemcc> thats what I fear
<coNP> desrt: why? :)
<jamiemcc> on feisty tracker 0.6 runs as smooth as a babies bottom
<Amaranth> jamiemcc: you fear cfs? why?
<j1mc> hi all.  when should we be starting testing the tribe 4 iso's?  today?
<desrt> coNP; because you're an oft-neglected class
<jamiemcc> amaranth: I fear any change that  may break tracker performance
<coNP> desrt: lol, yea :D
<jamiemcc> if it aint broke dont fix it
<Amaranth> tracker here will use 99% CPU when my system is idle and smoothly scale back as other things use it
<Mithrandir> jamiemcc: I've had problems that closing files sometimes seem to take a long time when trackerd is running.  Any idea what the cause might be?
<jamiemcc> amaranth: yeah ok but ioprio is not working?
<Amaranth> Although I'd rather it jump to the second core
<Amaranth> jamiemcc: Oh, I dunno
<jamiemcc> IOPRIO has changed interface in kernel from feisty to gutsy
<Amaranth> jamiemcc: Time to start using gutsy :)
<jamiemcc> which means tracker will slow disk access until I change it
<jamiemcc> I need fiesty for work!
<ion_> CFS?
<jamiemcc> completley fair scheduler
<ion_> Ah
<Amaranth> jamiemcc: vmware?
<jamiemcc> Amaranth: I have spare partition
<j1mc> Mithrandir: are the 07-Aug-2007 images candidates for tribe 4 in need of testing, or will the tribe 4 candidates be released later.
<Mithrandir> j1mc: I believe the plan is to release new ISOs tomorrow.  I think we're waiting for at least a new OOo
<j1mc> thanks.
<j1mc>  Mithrandir> j1mc: I believe the plan is to release new ISOs tomorrow.
<j1mc>                     I think we're waiting for at least a new OOo
<j1mc> sorry.  :(
<cjwatson> j1mc: current ubiquity is hosed too, upload nearly ready to fix that
<j1mc> thanks, cjwatson.  also, i haven't been getting my xubuntu cd daily health check messages the past few days.
<pitti> 15:31:03 WARNING        openoffice.org_2.3.0~src680m224-1ubuntu1.dsc: invalid build-depends field; cannot be parsed by apt: Problem Parsing Dependency
* pitti sobs
<Hobbsee> pitti: case sensitive, or a bigger problem than that?
<ogra> hmm
<pitti> Hobbsee: ah, I got it
<cjwatson> j1mc: indeed, that's because we migrated to a new machine and mailx wasn't installed on it; that's fixed now
<cjwatson> you should get them tomorrow
<cjwatson> or in fact I can just run them now ...
<pitti> ...  ppc64] , , transl...
<ogra> cjwatson, did d-i change so i dont have access to the cdrom dir in /target anymore ?
<j1mc> cjwatson: no worries.  thank you for letting me know.
<cjwatson> ogra: no
<cjwatson> ogra: at least not to my knowledge, and not recently
<ogra> semms my ltsp build fails because /cdrom contains nothing in the target system
<cjwatson> ogra: when does this code run?
<cjwatson> ltsp-client-builder.postinst?
<ogra> after all software was installed
<ogra> right
<ogra> last step before grub
<cjwatson> you run it at the same installer-menu-item as pkgsel, actually
<ogra> but note that i started it from the menu since i had to work around the kino breakage
<cjwatson> oh, but you depend on pkgsel
<cjwatson> ok
<cjwatson> ogra: had you got the final install message by the time you went back to the menu?
<ogra> nope
<wasabi> Hey so has the available tools for running a local apt repository changed much lately? I used to use some python program..... um.... mini-dinstall, a few years ago.
<cjwatson> ogra: the one that says "Installation is complete"
<gabaug> can somebody point me to the discussion/blueprints/etc that led to the Tracker decision?
<ogra> i had it fail in pkgsel ... went to console, installed libavcodec1d in /target and restarted pkgsel
<thom> wasabi: not an awful lot
<wasabi> I shall then use mini-dinstall again!
<ogra> after that was done it went back to the menu
<cjwatson> ogra: can I get hold of the syslog?
<ogra> where i then ran the ltsp build
<Amaranth> gabaug: I dunno, we talked about it in seville
<ogra> yup
<gabaug> Amaranth: is it going to be included and turned on in the default install?
<Amaranth> gabaug: already is
<gabaug> Amaranth: isn't there normally mailing list/wiki/blueprint discussion for such decisions?  from my very uninformed perspective, the decision seems quite opaque
<Amaranth> gabaug: there was a blueprint, it was discussed in seville
<Amaranth> gabaug: And it was really only a matter of time before one of the two got included
<ogra> cjwatson, oh, crap i didnt properly unmount the disk after copying the syslog ... its lost :(
<gabaug> Amaranth: can you help me find the blueprint?  I'm not terribly familiar with launchpad, and don't see it right away
<pitti> seb128: hm, it seems that deskbar-applet doesn't actually have a module for tracker?
<pitti> seb128: I tried it on a freshly installed sytem, and it only offers 'web search' to me
<seb128> pitti: libdeskbar-tracker needs to be installed
<pitti> ah
<seb128> pitti: we should seed it
<seb128> I already changed tracker to tracker-search-tools
<seb128> in the seed
<pitti> seb128: Size: 31868
<pitti> \o/
<pitti> that's tiny
<pitti> seb128: hm, so if we show off that feature, we should do it properly
<seb128> pitti: do you want to change that now or after the tribe?
<pitti> seb128: and we have plenty of time due to OO.o
<seb128> right
<pitti> so please go ahead
<seb128> I'm wondering if we should seed tracker-utils also
<Amaranth> gabaug: I can't navigate launchpad either
<ogra> pitti, can you trigger a new build for me, kino is there now
<Amaranth> gabaug: But we had a discussion or two about it in seville, I remember that
<pitti> ogra: is that useful for you? (ubiquity and OO.o are broken still)
<pitti> ogra: if you want a server CD for a general 'succeeds with install' testing, no problem
<Amaranth> gabaug: It was just a matter of one of them fixing the problems with compiling before we started using them :)
<ogra> yes, i need to debug ltsp as well ... it helps if the install doesnt die before :)
<gabaug> Amaranth: what problems with compiling were there?  hasn't beagle been packaged for several releases?
<LaserJock> Riddell: desktop-multiplier was already NEW'd for dapper-updates, apparently soyuz thinks -updates counts as a place to NEW packages ;-)
<Amaranth> gabaug: No, their effect on compiling
<Amaranth> gabaug: Both of them used to make compiles go like 3x slower
<LaserJock> Riddell: infinity NEW'd the source last night so I'm assuming you're talking about the binary?
<Riddell> LaserJock: no, I'm talking about the source new in gutsy
<pitti> ogra: building
<ogra> pitti, thanks a lot
<ogra> (i only need -server)
<LaserJock> Riddell: ok, we yes, it is in dapper-updates, but it wasn't ever removed
<Riddell> LaserJock: well it's not in gutsy now
<Riddell> and launchpad doesn't have entries for it in anything other than dapper
<LaserJock> right
<LaserJock> I uploaded it once to dapper-updates
<Riddell> and as I say, it's in gutsy New queue
<LaserJock> still?
<Hobbsee> Riddell: kdesudo is still in the NEW queue too, it loosk like :(
<Riddell> Hobbsee: no it isn't
<Riddell> LaserJock: it was only uploaded 17 hours ago
<LaserJock> Riddell: yes, but infinity said he NEW'd it
<Amaranth> So, anyone have an opinion on going back to xlib using xcb? :)
<Riddell> LaserJock: you said he Newed it for dapper-updates
<Hobbsee> Riddell: oh, that's right.  i only saw it in http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<Amaranth> What were the problems with it before and does anyone know if they've been fixed?
<LaserJock> Riddell: no for gutsy
<LaserJock> Riddell: it was NEW'd for dapper-updates over a year ago
<Amaranth> bryce: Do you know anything about xcb-backed xlib?
<Riddell> LaserJock: ok, so my question was why did it disappear and what has changed that it can now
<Riddell> Hobbsee: it needs promoted to main, which needs the main inclusion report approved
<LaserJock> Riddell: it didn't disappear. It was uploaded to dapper-updates, that's it, it was *supposed* to be in the archives
<LaserJock> but of course NEW'ing to dapper-updates seems to have cause archive problems
<LaserJock> I just uploaded a new upstream version and soyuz thinks it's never seen it before
<Riddell> ok, so it was never in dapper, only dapper-updates?
<LaserJock> yes
<LaserJock> that's correct
<Riddell> LaserJock: it seems to have failed to build anywhere but i386, has that been checked for with this upload? https://launchpad.net/ubuntu/+source/desktop-multiplier/2.2-3-0ubuntu1
<LaserJock> Riddell: it is i386 only
<LaserJock> it's shipping a binary app in it
<highvoltage> hello LaserJock
<LaserJock> hi highvoltage
<Riddell> so it is, bit of a mis-information issue on soyuz there
<LaserJock> Riddell: yeah, I did set Architecture: i386 in debian/control
<seb128> pitti: I've commited the seed changes, if you want to do an ubuntu-meta update you can do it now
<Hobbsee> Riddell: oh, right, i thought it had been. my error
<pitti> ok
<Hobbsee> Riddell: (the report done)
<Hobbsee> (and approved)
<Riddell> seb128: seed changes?  anything I should care about?
<pitti> $ q -Q unapproved accept openoffice.org
<pitti> \o/
<seb128> Riddell: no, I already merged them to edubuntu and kubuntu
<bryce> Amaranth: yes I've gotten the low-down from jcristau and timo about that
<seb128> Riddell: adding tracker packages to ubuntu
<Amaranth> bryce: So are we getting it again?
<bryce> Amaranth: sounds like maybe during Gutsy+1 we can get it sorted out and reactivated
<Amaranth> Oh
<Amaranth> Well, hopefully compiz 0.5.2 is good enough to stick with for gutsy then :/
<Amaranth> Because compiz in git is starting the conversion to xcb so we either have to hope davidr finishes quickly or use the xcb-backed xlib
<LaserJock> Riddell: do you need anything more for desktop-multiplier?
<Riddell> nope, accepted, sorry for the grilling
<LaserJock> Riddell: no problem, it's a weird situation
<pitti> cjwatson: would you know why ubuntu-meta update removed things like dselect, ppp, pppoeconf, or reiserfsprogs from standard? (all arches)
<cjwatson> pitti: they got moved to recommends
<cjwatson> random cleanup on my part
<pitti> ah, heh, indeed
<pitti> cjwatson: sorry for the noise
<cjwatson> np
<pitti> cjwatson: so, I have OO.o and new u-meta in the queue now; I can run a publisher and grab ubiquity later, or wait for it
<pitti> depending on whether there's a package
<cjwatson> pitti: give me about five minutes
<cjwatson> I've got the package, am just checking it
<pitti> cjwatson: no hurry, OO.o will take long enough to build
* pitti optimizes for critical path, runs publisher, and gives Colin much more time
<cjwatson> ok
<cjwatson> yes, might as well get started on that
<cjwatson> I'm uploading ubiquity 1.5.7 now
<pitti> slomo_: can you please commit your recent avahi upload to the bzr?
<pitti> slomo_: oh, sorry, that wasn't you
<tkamppeter_> pitti, Mithrandir. I have reported bug 130903 now.
<ubotu> Launchpad bug 130903 in system-config-printer "Replace gnome-cups-manager by system-config-printer" [High,Confirmed]  https://launchpad.net/bugs/130903
<pitti> tkamppeter_: thanks; ah, already milestoned
<tkamppeter_> pitti, this replacement will fix most of these ones: https://bugs.launchpad.net/ubuntu/+source/gnome-cups-manager/
<tkamppeter_> pitti, should I also milestone bug 130298?
<ubotu> Launchpad bug 130298 in libnotify "add_action() method does not work at all" [High,Confirmed]  https://launchpad.net/bugs/130298
<pitti> tkamppeter_: if you want; is this known and worked on upstream?
<pitti> tkamppeter_: it's not a trivial problem, after looking at it for 5 minutes
<pitti> cjwatson: oh, desktop CD gfxboot has "OEM install" which just produces a weird dialog box
<tkamppeter_> pitti, Fedora uses the same version of libnotify as we are using and under Fedora it works.
<pitti> tkamppeter_: ok, might be worth looking at their patches then
<pitti> ogra: oh, btw, your server CDs are ready (for some hours already; sorry, forgot to check)
<tkamppeter_> pitti, neither we nor Fedora has patches on libnotify
<pitti> tkamppeter_: hm, weird then.. /me blames gtk
<pitti> tkamppeter_: then I guess a proper gdb session is in order...
<tkamppeter_> pitti: Only difference between Fedora and us is that they have notify-python 0.1.0 and we have 0.1.1, perhaps a regression in 0.1.1?
<pitti> tkamppeter_: as I wrote in the bug, it's not a bug in the python bindings; it's in libnotify itself
<ion_> system-config-printer is nice, but it could use a bit of UI love. (0.7.71+-svn1371-0ubuntu1 here)
<tkamppeter> Ion_, which kind? Do you mean a lot of icons and little pictures?
<pitti> no, less elements preferably :)
<ion_> Yeah, less elements. Also i really think it should make the first added printer the default printer automatically.
<tkamppeter> Or something which one can easily implement without needing art workers?
<pitti> ion_: I was just going to suggest that :)
<tkamppeter> Yes, making the first added printer the default printer is easy to implement.
<pitti> tkamppeter: btw, it still selected gdi instead of splix (hal-cups-utils autolove)
<ion_> Also the dialog to choose a PPD is really confusing. I think its something that should be behind an Advanced... button.
<ion_> A newbie has no idea whether she should choose somethingsomething-hpijs.ppd or somethingsomething-ljet4.ppd
<pitti> automatically creating a printer name would be nice, too
<tkamppeter> What do you think with "less elements"? Removing functionality?
<ion_> pitti: Yeah
<pitti> *first* selecting the detected printer, and *then* giving it a name,location etc. would be much easier
<ion_> tkamppeter: Hiding functionality that only advanced users should see behind an Advanced... button or something equivalent.
<pitti> tkamppeter: functionality should stay, but it should be hidden better, somehow
<ion_> s/should/are likely to/
<pitti> tkamppeter: ^ that touches more intricate UI changes, though
<ion_> s/are likely to see/are likely to use/ :-)
<tkamppeter> pitti, you?e right with that, I have also moved entering the printer name after selecting the printer in printerdrake.
<pitti> tkamppeter: that's also what the webui and g-c-m does, and I think it's more logical
<ion_> It would also be nice if the add printer dialog detected a parallel port printer automatically.
<tkamppeter> Yes, we should have something like a "green mode", press the shutter button and get a correct picture.
<pitti> that might be harder
<pitti> tkamppeter: :)
<ion_> pitti: From my dmesg: [   34.368000]  parport0: Printer, Hewlett-Packard HP LaserJet 1100
<pitti> tkamppeter: I think that's pretty much covered with hal-cups-utils
<mikmor2> can you use gfxboot with isolinux?
<tkamppeter> In this mode the name input and driver selection page would be totally skipped and after closing the wizard the new printer is selected in the main window and there the "Options Installed" tab opened, so that the user does not forget to tell which accessories he has.
<tkamppeter> pitti, does "lpinfo -l -v" show your parallel printer with make and model name? Does HAL show your parallel printer with make and model name?
<pitti> tkamppeter: ion_ is here --->
<cjwatson> pitti: oem> hmm
<cjwatson> checking that out now
<tkamppeter> pitti, what do you mean with that?
<pitti> cjwatson: does ubiquity actually support OEM now? or shouldn't the entry appear in the first place?
<pitti> tkamppeter: ion_ has the parallel printer, I don't :)
<ion_> tkamppeter: Neither.
<cjwatson> pitti: oh dear me that's odd
<cjwatson> pitti: yes, it does, see the ubiquity-oem spec
<pitti> kewl
<tkamppeter> ion_, can you check the following:
<ion_> tkamppeter: But something in the kernel does detect the make and model.
<tkamppeter> Ion_: 1. Does "lpinfo -l -v" show your parallel printer with make and model?
<ion_> tkamppeter: Neither lpinfo or HAL show it.
<tkamppeter> ion_: 2. Does HAL report your parallel printer with make and model? Use hal-device-manager to check that.
<cjwatson> pitti: ah, the problem is that it should point to /casper/vmlinuz on the live CD, not /install/vmlinuz. I'll fix that, thanks
<cjwatson> (and /casper/initrd.gz)
<tkamppeter> ion_, can you make sure the printer is turned on and connected and then do
<ion_> Nothing in the /sys tree seems to know it either. (based on zargs -- /sys/**/*(.) -- grep LaserJet 2>/dev/null)
<tkamppeter> sudo rmmod lp
<tkamppeter> sudo rmmod ppdev
<tkamppeter> sudo rmmod parport_pc
<tkamppeter> sudo rmmod parport
<tkamppeter> sudo modprobe lp ppdev
<tkamppeter> and then repeat the two tests.
<ion_> tkamppeter: ppdev wasnt loaded, the others were. Just by loading the ppdev module, lpinfo shows the printer correctly.
<cjwatson> pitti: fixed in debian-cd on antimony; next rebuilds will be happier
<tkamppeter> ion_, pitti, AFAIR the CUPS startup script should assure that ppdev is loaded.
<tkamppeter> ion_ could you do the following test:
<tkamppeter> Turn off your printer and do
<tkamppeter> sudo rmmod ppdev
<ion_> tkamppeter: After loading ppdev, s-c-printer also finds the printer automatically.
<tkamppeter> sudo modprobe ppdev
<tkamppeter> Does your printer disappear from lpinfo now?
<tkamppeter> Than turn it on again and reload ppdev again. Does the printer reappear?
<cjwatson> pitti: is it just me, or is the usplash progress bar skewed to the right with respect to the logo?
<cjwatson> or is this a vmware artefact?
<ion_> Printer off, rmmod ppdev, modprobe ppdev: lpinfo doesnt show it. Printer on: lpinfo shows it. rmmod ppdev, modprobe ppdev: lpinfo still shows it.
<ion_> tkamppeter: From the cupsys init script:              -a -z "$(grep -e ' lp$' /proc/devices 2>/dev/null)" ] ; then
<ion_> tkamppeter: That test fails.
<ion_> tkamppeter: Thus ppdev doesnt get loaded.
<tkamppeter> ion_, thanks, so we do not need to reload all the modules. Result from that is that we should reload the ppdev module when starting the add printer wizard, to discover parallel printers turned on after boot. This should be done via a SUID helper program, as s-c-p runs as non-root user.
<ion_> tkamppeter: Even reloading ppdev doesnt seem to be necessary as long as its loaded on startup.
<ion_> tkamppeter: The cupsys script just doesnt load it here.
<pitti> cjwatson: no, happens everywhere I think
<tkamppeter> pitti, can you see whether the cupsys startup script really takes care that ppdev gets automatically loaded on CUPS startup?
<pitti> cjwatson: I pinged kwwii some days ago, no response so far
<tkamppeter> ion_ report a cupsys bug on Launchpad.
<pitti> tkamppeter: yes, it does
<ion_> tkamppeter: Will do.
<tkamppeter> _ion, now to HAL, does HAL report your parallel printer? Does it require to reload ppdev to update the state (test by turning on and off the printer)?
* pitti -> dinner, bbl
<ogra> pitti, thanks ...
<ion_> tkamppeter: HAL doesnt report it.
<tkamppeter> _ion one other important thing: AFAIR loading ppdev at system startup only helps if the printer is turned on at system startup. If it is turned on later, a reload of ppdev is requirted. Can you check and confirm this?
<ion_> ti202109 < ion_> Printer off, rmmod ppdev, modprobe ppdev: lpinfo doesnt show it. Printer on: lpinfo shows it. rmmod ppdev, modprobe ppdev: lpinfo still shows it.
<tkamppeter> ion_, so HAL does not include the parallel ports in general?
<ion_> Reloading ppdev wasnt required for lpinfo to show it after it was turned on.
<ion_> tkamppeter: I dont know what HAL *should* do. It shows the port itself, but not the printer connected to it.
<ion_>   pnp.description = 'ECP printer port'  (string)
<ion_>   info.linux.driver = 'parport_pc'  (string)
<tkamppeter> So ion_, then we do not need to modify s-c-p, as ppdev is automatically recognizing the parallel printer. This means that the parallel port got hot-pluggable under Linux.
<tkamppeter> ion_, so we should perhaps report a bug against HAL, telling that with ppdev loaded a parallel printer gets automatically detected without any user interaction and so it is easy to implement that HAL can report a parallel printer and then an auto queue setup could be triggered.
<ion_> tkamppeter: HAL probably would need to poll the parallel port every once in a while. There was no message in dmesg about the printer being turned on.
<tkamppeter> ion_, would it be possible that HAL could do so?
<pitti> re
<mikmor2> hmm..
<mikmor2> isn't dpkg strict about keeping the permissions of the files it installs the same as the original?
<pitti> mikmor2: usually yes, except when there is a dpkg-statoverride for that file
<pitti> mikmor2: or it is a conffile in /etc
<LaserJock> there's also dh_fixperms that can mess around with permissions when building the .deb
<pitti> mikmor2: what LaserJock said, that depends on your definiton of 'original'
<pitti> mikmor2: 'original' == 'as in the .deb' or 'as in the built tree
<mjg59> Ok, well tracker-search-tool seems to work pretty much as expected
<pitti> doko: is "#if defined(i386)" (and friends) true on lpia?
<pitti> doko: ^ that's from some i386 optimizations in zip, which should be built on lpia, too
<mjg59> I suspect that we want an icon for trackerd to indicate that it's indexing your entire filesystem
<ion_> Yeah, that would be good.
<ion_> Also all tracker clients that use the file searching functionality should have a widget that says tracker is still indexing, the results might be incomplete when needed. :-)
<pitti> mjg59: we already have that, it's called 'gnome-system-monitor' :-P
<pygi> bla, bla, bla
<pygi> ion_, tracker disabled :)
<ion_> pitti: :-)
<jamiemcc> pygi: I have found the problem for that
<pygi> jamiemcc, hm? What are you talking about? :)
<ion_> Oh, i only now realized ubuntu-desktop recommends tracker nowadays. Thats great.
<mjg59> ion_: I've just filed that
<mjg59> jamiemcc: Oh, right, hadn't noticed you were in here
<jamiemcc> hi mjg59
<mjg59> I've just thrown another couple of bugs at you
<mjg59> (Thanks for the fast response to the battery throttling one)
<jamiemcc> yeah that one is critical
<jamiemcc> im doing it atm
<mjg59> jamiemcc: One thing I noticed on reading the code - the BatteryThrottle option is read, but ->throttle (rather than battery_throttle) is set
<mjg59> Of course, it's not used anywhere yet anyway :)
<jamiemcc> we have partial code to support battery throttle but its not finished yet
<ion_> I hope gutsy installing tracker by default is finally the thing that makes people add support for things like shared file tags with tracker as the backend to their software.
<jamiemcc> anyway suspending indexing might be better
<mjg59> jamiemcc: I suspect so. We really don't want any unnecessary disk access on battery
<jamiemcc> ion_ we hope so too - im sure ubuntu would accept a nuatilus patch to use tracker tags
<jamiemcc> mjg59: how much content did you index?
<jamiemcc> do you have millions of emails and files?
<mjg59> jamiemcc: About 20G in ~, about 30G in total
<jamiemcc> oh no wonder
<mjg59> It's also only a 1.8" drive
<jamiemcc> you can set no watch dirs for stuff
<jamiemcc> that does not require indexing
<mjg59> I don't really mind it taking this long, but it would be nice for it to tell me what it's doing
<mjg59> jamiemcc: What's the behaviour if I reboot during indexing?
<ion_> The tray icon that tells tracker is indexing could also say that the indexing is suspended because the computer is running on battery, and it could have a context menu item that allows a user to toggle the suspend-on-battery feature.
<jamiemcc> yeah thats something we will do - we have tracker-status command line tool for it
<jamiemcc> mjg59: it should resume from where it left
<wasabi> I don't know why I would want to know what tracker is doing.
<mjg59> jamiemcc: At the moment tracker-status says "Watching"
<wasabi> It should just do the right thing, regardless.
<jamiemcc> we can display a msg in the status bar of tst
<mjg59> wasabi: Because (a) it causes noticable disk i/o, and (b) it means that you won't get full results back
<pitti> wasabi: augmenting search results with an indexing completeness would be useful, though
<wasabi> I really think b) is something that should be told about at search time.
<mjg59> jamiemcc: For the initial index, I suspect that a notification icon would be appropriate
<jamiemcc> yeah
<wasabi> That's how Vista does it... "This search may take awhile because blah blah blah is indexing your files."
<wasabi> a) should just be fixed. ;)
<jamiemcc> yeah its nopt a problem to do
<mjg59> wasabi: Kind of hard to avoid disk i/o when you're reading every file
<wasabi> Sure, but it should not interfere with anything (regardless of Linux's current inability to make it that way)
<jamiemcc> atm gutsy kernel ioprio has changed interface so I need to mod tracker to use the new interface
<mjg59> And kind of hard to make it unnoticable when it results in a bright green LED flashing at me, makes my lap noticably warmer and can be heard from across the room :)
<jamiemcc> thern it wont slow down disk access
<wasabi> Well, I'd say it shouldn't do a full disk index while on battery, ever, because it's on battery, and that's bad. But it should nicely inform the user of this, but only when teh user cares: when he's doing an actual search.
<jamiemcc> wasabi: i agree
<wasabi> "Search results may be incomplete, would you like to begin a full disk index now? This may reduce the life of your battery. Blah.
<mjg59> wasabi: That's an orthogonal issue
<wasabi> Well, if tracker provides other desktop services I'm not aware of, then sure.
<ijuz> questions suck, it should better eat the battery
<wasabi> But for now it's just searching, no?
<mjg59> wasabi: It's pretty reasonable for people to ask what's causing so much disk access
<wasabi> I agree, and we have tools for that.
<mjg59> Such as?
<wasabi> Gnome-system-monitor. =)
<mjg59> wasabi: Doesn't tell me which applications are responsible for i/o
<wasabi> It should.
<mjg59> How?
<ion_> A novice user would need to 0) realize she should use gnome-system-monitor and 1) have the knowledge what the trackerd entry on the top means.
<jamiemcc> what would be nice is to have an applet which shows indexing and also gives you the option to pause
<wasabi> A novice user isn't going to care that his disk might be spinning.
<wasabi> My mom? Wouldn't care.
<wasabi> My dad? Probably doesn't even know what a disk is.
<mjg59> wasabi: Right now, my computer is clearly behaving differently to usual
<wasabi> Because jamiemcc has not fixed the IOPRIO issue.
<pitti> wasabi: my gf would complain about loud laptop all the time
<mjg59> People do wonder about that sort of thing
<mjg59> wasabi: No
<mjg59> It's nothing to do with the ioprio issue
<wasabi> Hmm. g-s-m needs some IO measurement, yeah.
<wasabi> I guess this is a fight I can't win today. I just think we should reserve annoying popups for cases where the user either asks for an annoying pop up, or needs to take action.
<wasabi> I guess then it just becomes a standard part of Ubuntu to have a notification icon pop up on your first logon, always, eh?
<ion_> An icon in the tray isnt exactly a popup.
<mjg59> We should notify the user when the system state is abnormal
<wasabi> Logging into the system for the first time isn't abnormal. Heh.
* hunger agrees with mjg59 
<jamiemcc> mjg59: libnotify is good for that
<mjg59> Right, logging in for the first time isn't. That's why we don't do that.
<hunger> jamiemcc: Where do you get the data from?
<mjg59> However, if something is happening on the first login that /is/ abnormal, we should let the user know
<jamiemcc> hunger: what data?
<hunger> jamiemcc: I get a digest of the log-files by mail, that is not really feastable for a notification though.
<hunger> jamiemcc: That something is going wrong. SMART failures, whatnot.
<mjg59> hunger: That's kind of a separate issue
<jamiemcc> I just mean send a notification when you log on for the first time and tracker does its initial indeixng
<mjg59> Ideally hal would cope with that
<ijuz> are the build dependencies brocken for somebody else too? (gutsy)
<mjg59> It would be nice to put the smart data in hal, then it's sharable with other applications
<wasabi> WWSJD  <--- what would steve jobs do
<wasabi> hehe
<hunger> Can I turn of tracker? This desktop indexing just eats up all my space.
<jamiemcc> hunger: yes or you could tell iot to index a subset of your home dir
<ion_> Indexing Preferences
<ion_> Nice that tracker uses ~/.config/tracker now.
<pitti> jamiemcc: ah, does it default to *not* index /usr and such?
<mjg59> disk-usage-analyser ought to be able to assign usage to different applications
<ion_> pitti: Yeah
<pitti> great
<jamiemcc> pitti: it only defaults to index home and usr/share/applications
<pitti> jamiemcc: that's great
<pitti> jamiemcc: what does it do with files like movies and music?
<jamiemcc> it indexes them :)
<jamiemcc> metadata only
<pitti> jamiemcc: does it do some 'binary stuff' detection and ignores them?
<pitti> jamiemcc: ah, good
<jamiemcc> no we check mime type
<mjg59> "1GB in use by Tracker, 200MB in use by Firefox, 20GB in use by unknown applications", that sort of thing
<pitti> jamiemcc: rock
<pitti> ok, I'm off for now; OO.o will build a while, so I might come back later, or tomorrow
<jamiemcc> pitti: I will have an updated tracke rin a few hours
<pitti> jamiemcc: great
<ogra> pitti, if you find any traces of y nightly ltsp upload, please approve
<pitti> jamiemcc: I think we can fit it in if the diff looks ok
<ogra> s/y/a/
<jamiemcc> great
<ogra> :)
<pitti> jamiemcc: can you please mail the diff between current gutsy version and the new one to pitti@ubuntu.com?
<jamiemcc> sure
<jamiemcc> it will be an official release too
<jamiemcc> 0.6.1
<pitti> jamiemcc: thanks a lot; then I can do it in the morning
<jamiemcc> oh great more time to test
<pitti> ogra: I'll do that in the morning or tonight; I guess ltsp builds fast
<ogra> yeah
<ogra> i'm not sure its broken yet :)
<ion_> Depending on everyones definition of the morning. :-)
<ogra> lets see how that running instal performs
<pitti> ogra: please don't hesitate to phone or sms me if you need it urgently
<ogra> i would love to have tomorrow to sort my liveCDs out though ... cross your fingers it works :)
<pitti> ogra: OO.o! :)
<ogra> pitti, its a good excuse to go to bed if youre not around later :)
* pitti needs all fingers crossed for that one already
<pitti> ATM it makes more sense for me to get to bed and up again early than doing another nightshift
<ogra> yeah
* ogra will only try to find the cause of the ltsp breakage (if there even is any and that didnt come from my manual fiddling)
<ogra> GAH !
<ogra> it didnt :(
<wasabi> hmm... still no way to create a passwordless keyring
<ogra> cjwatson, in case you still want to take a look at the changelog of the failed ltsp build: http://people.ubuntu.com/~ogra/syslog_tribe4
<calc> http://www.linuxtoday.com/infrastructure/2007080303226OPDT <- reminds me of my laptop
<calc> i don't mind using XP, but Vista is horrendous
* ogra guves up for today ... no idea how a "Hash Sum mismatch" of the Packages.gz can happen, especially since i used that file twice already in the same install
<ogra> *gives
<highvoltage> ogra: :(
<EvanCarroll> I'm having a lot of problems with nagios2, I can't uninstall it, and I can't install it, I'm getting errors scripts going both ways
<EvanCarroll> Is there anyway to say, install this as it stands and ignore the system's state.
<EvanCarroll> dpkg --force-all -i does not work.
<ion_> I might not be wrong if i were to guess that your problem is caused in the first place by breaking the system by using --force flags in the past.
<pygi> meh, somebody broke evolution for me
<pygi> so much things broken today xD
<seb128> pygi: how?
<EvanCarroll> no, I broke this by deleteing /etc/nagios2 and thinking a force-reinstall would work
<EvanCarroll> but the faults in both the nagios2 maintainer and the faults in dpkg/deb are to much for this little ubuntu box to overcome.
<ion_> From now on, think that force-anything will break your system. Also, this is not a support channel.
<mikmor2> pitti: thanks for responding to me earlier.. was afk
<pygi> seb128, it won't check mail at all
<EvanCarroll> because the uninstall script requires a successfull /etc/init.d/nagios2 restart, and that requires a conf file, which I deleted.
<pygi> I don't remember updating evolution tho, but I might be wrong
<seb128> pygi: weird, maybe a server problem? otherwise try to evolution --force-shutdown, nobody else bugged about it and evolution didn't change for a week
<pygi> seb128, yup, I'll check with some other server
<EvanCarroll> ion_: i reiterate, the system was broke before the --force, which failed and didn't work as advertised.
<EvanCarroll> the goal was to --reinstall, that didn't work, so i tried --force (with dpkg) which also didn't work for the same reason.
<pygi> seb128, hm, it responded now
<pygi> seem like extremely slow server
<pygi> (took it like 8 or so minutes)
<kdub433> when is gutsy coming out?
<stdin> !gutst
<ubotu> Sorry, I don't know anything about gutst - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<coNP> !gutsy | kdub433
<stdin> !gutsy
<ubotu> kdub433: Gutsy Gibbon is the code name for the next release of Ubuntu (7.10) | (due October 2007) | It is development software, as such unstable, support _only_ in #ubuntu+1
<stdin> 7.10  = 10/2007
<kdub433> thanks
<mikmor2> cjwatson: Have you considered making the "Skip" button in Ubiquity (while trying to connect with APT) available to click earlier?
<mikmor2> The whole "configuring apt" runs for quite a while before it times out
<doko> pitti: $ gcc -E -dM - < /dev/null | grep i386
<doko> #define __i386 1
<doko> #define i386 1
<doko> #define __i386__ 1
<calc> doko: if i send you the patches for ooo-build can you commit them for me?
<doko> calc: sure
<calc> doko: ok i'll email them to you
<doko> calc: tomorrow morning, not now
<calc> ok np
<ijuz> doko: have you seen the dependency problem of libc6-dev ? seems to be a typo
<calc> doko: ok sent to you, thanks :)
<calc> doko: mention my name of course so i can apply to get direct access :)
<Amaranth> what is ooo-build?
<calc> Amaranth: linux dists build system for openoffice
<calc> Amaranth: its hosted on svn.gnome.org
<Amaranth> hey, i can commit to that ;)
<Amaranth> doesn't openoffice have it's own build system?
<calc> Amaranth: i don't know the full history of how ooo-build came to be but i think it was due to being hard to get stuff integrated upstream, doko probably knows more about that part than me
<cjwatson> EvanCarroll: easiest way is usually to edit the maintainer script in /var/lib/dpkg/info/ and comment out the line that's failing and that you don't care about. dpkg --force-* has absolutely no effect on any of that so don't bother using it.
<cjwatson> mikmor2: I'm not sure skip is the right answer there, possibly something else
<cjwatson> I think it's doing more work than it should as well
<mikmor2> cjwatson: yeah.. its not so bad if you're only installing like a human normally would.. but i've begun to "notice" it
<mikmor2> heh
<cjwatson> ogra: I'd recommend looking at the bit of base-installer/debian/postinst that writes out /target/etc/apt/apt.conf.d/00NoMountCDROM
<cjwatson> ogra: I reckon your problem is that at some point apt unmounts /cdrom
<cjwatson> ogra: if you do that same bit of configuration in the chroot you build for the duration of building it, it should stop things going haywire
<cjwatson> ... probably
<EvanCarroll> cjwatson: thanks for the tip, I've stored it away, I ended up hacking the init script to return a true value so i could reinstall it
<cjwatson> EvanCarroll: that's valid too
<EvanCarroll> cjwatson: i like perlbars convention, ./t/* for tests, if you want to skip them, just --force-install, and they get skipped.
<EvanCarroll> not having a means to bypass these type of tests seems to take a lot of time when it stings, I'll try your way next time
<cjwatson> maintainer scripts do enough potentially weird stuff that it's a bit worrying to provide a means to bypass them without reading them
<EvanCarroll> you often want to just install the upstream and let dpkg make all of the assumption it can, that will often return your system to a stable state.
<EvanCarroll> upstream being, whatever ubuntu's universe package is
<EvanCarroll> my mental image of what is going on has always been something of this (what I'm trying to achive) remove the old files from the control of package manager, override them all with the new files, and in doing so retake ownership
<EvanCarroll> I'm not sure if thats what I'm doing half of the time when I bash on my keyboard and make it work, but that is often what I'm trying to achive when I'm playing with --force
<cjwatson> ok, but when people say --force-all is a bad idea they really mean it. It really has in real life been known to replace people's /sbin with a regular file.
<EvanCarroll> if my system has to be borked, at least give me a story I can entertain people with. ;)
<cjwatson> the dangerous options in --force-* are strictly for those who know how dpkg operates and need to extricate themselves from weird situations (that you don't normally get into)
<cjwatson> it's best to work out what each one does before using it, and don't use it if it doesn't apply
<cjwatson> --force-overwrite, --force-depends, and --force-confmiss are the only ones I've ever needed to use in eight years of running Debian/Ubuntu systems
<cjwatson> (in very different situations)
<EvanCarroll> I've been on deb for 7yrs, and I've always just used --force-all, but it has always been in panicked situations and never stung, and never worked that i can recall
<EvanCarroll> and it has always been for the same reason
<EvanCarroll> can't install, or uninstall
<cjwatson> right, learn from that and stop using it please before we have to help you repair your system. :)
<cjwatson> maintainer script problems (any error that talks about the {pre,post}-{installation,removal} script returning an error) are not subject to --force-*.
<EvanCarroll> guess I should have been hacking /var/lib/dpkg/info, it always seems like the more hackish solution is in messing with the files rather than going through the UI
<EvanCarroll> cjwatson: will make note, thanks
<cjwatson> but there is no UI for this.
<zerwas_> Can somebody explain me why Ubuntu is not using the graphical interface of GRUB with mouse support by default? I know many people who have no idea what to do when they see the GRUB menu
<cjwatson> so it's not relevant which is more hackish, because only one option will actually work. :)
<cjwatson> zerwas_: we configure the grub menu not to appear by default unless you're multi-booting ...
<EvanCarroll> cjwatson: well said.
<cjwatson> zerwas_: we don't use the graphical interface because (IIRC) we tried it at one point and it broke certain systems in subtle ways.
<cjwatson> same as the reason we don't use grub on the CDs
<zerwas_> cjwatson, ok, sounds evident
<zerwas_> so a place for the GRUB devs to make it more stable
<cjwatson> the GRUB developers are not interested in developing GRUB 1, for the most part
<cjwatson> most of them only care about GRUB 2
<cjwatson> but it's dubiously stable as yet
<LaserJock> cjwatson: do you know if there's been any thought to shipping an Ubuntu grub splash image? not using it by default but having it there for the multi-booters?
<ompaul> cjwatson, iirc (the now defunct) kanotix had grub on all disks, however kanotix although I liked it was always a bit more hackish than polish
<cjwatson> ompaul: we tried it. it broke. nuff said.
<wasabi> i'd vote for setting the grub timeout lower. =)
<cjwatson> LaserJock: basically just not a priority because it isn't used by default, though I wouldn't object to it.
<LaserJock> cjwatson: ok, makes sense. I only thought of it because of my GSoC student's project
<cjwatson> wasabi: it's already a mere three seconds if you're single-booting, and some systems take some of that time to do a mode switch. I vehemently oppose lowering it beyond that
<wasabi> Oh. Why?
<wasabi> It works with a depressed key, even with a 0 timeout, no?
<LaserJock> people might need to get to the memtest or "recovery" mode right?
<ompaul> wasabi, the reaction time of a new user to press ESC with confidence has to be taken into consideration, and the aforementioned new user may need a prompt
<ompaul> wasabi, onscreen prompt that is
<wasabi> I guess. Most "new users" I know seem to deal with windows just fine, where only techs know to press F8. =)
<zerwas_> ok so no chance to have a graphical boot (like OpenSUSE has) in the future. GRUB 2 is under development and will stay that for some time
<cjwatson> wasabi: my parents are set up with Windows/Ubuntu dual-boot, and (at least until Windows ate itself with spyware) used both fairly regularly. They tend to read a screen they're presented with thoroughly before hitting buttons, and the 10-second timeout on the menu has often nearly expired before they move the cursor.
<cjwatson> wasabi: as for ill-documented keys you need to hold down at boot, forget it
<wasabi> cjwatson: I agree, for dual booters.
#ubuntu-devel 2007-08-08
<Nafallo> xen moved to main? :-)
<Kmos> Can I request a removal of package sgcontrol ? it doesn't have rdepends and it's removed at debian with reason: "RoM; obsolete, rdep of gconf/gnomevfs, has replacements"
<Nafallo> ubuntu-desktop -> wvdial -> ppp; move wvdial to recommends? :-)
<Kmos> https://iso.qa.stgraber.org/
<Kmos> there isn't yet any iso
<geser> Kmos: tribe-4 is due thursday
<Kmos> geser: next week?
<geser> this week
<geser> try again thursday this week during the european day/evening
<Kmos> :)
<Kmos> it's already thursday here.. 00:40h - Portugal
<Kmos> :)
<geser> my calendar show only Wed Aug  8 01:41:29 CEST 2007
<geser> that's over one day difference instead of the usual one hour
<Kmos> :)
<geser> Kmos: TZ="Portugal" date displays here Wed Aug  8 00:45:25 WEST 2007. So how can you already have thursday?
<Kmos> geser: sorry.. i think today is wednesday
<Kmos> lol
<Kmos> my fault
<calc> what does failed to upload status mean?
<calc> https://launchpad.net/ubuntu/+source/openoffice.org/2.3.0~src680m224-1ubuntu1/+build/374232
<calc> it appears to build fine but couldn't upload the resulting debs to the archive?!
<StevenK> It means Soyuz tripped over it, and a member of -archive needs to fiddle it.
<calc> ok
<calc> any archive admins present?
<Hobbsee> doubt it
<Hobbsee> unless infinity happens to be around
<calc> infinity: you awake?
<calc> Hobbsee: btw your ooo 2.3 is in the archive more or less ;)
<calc> it built on amd64, ia64 and is still building on the rest, no failures so far!
<Hobbsee> calc: yay!  *hugs*
<calc> i think turning off multithreaded build helped out
<calc> makes it slower to build but at least its not failing
<Hobbsee> calc: then we can have kubuntu cds with a working office
<calc> Hobbsee: hopefully :)
<calc> works on ubuntu in any case
<calc> just switch to gnome if it doesn't work ;)
<Hobbsee> bah.
<calc> hehe
<Hobbsee> calc: i cope with gnome in small doses.
<StevenK> Very small doses? :-)
<calc> i think maybe maintaining KDE made me dislike it ;)
<Hobbsee> StevenK: exactly.  doing CD testing, etc, is enough :P
* StevenK uses Kubuntu on his laptop.
* calc uses Vista on his laptop... hmm no it uses space on his laptop, need to nuke it ;)
* ScottK only uses Gnome at the library.
<bddebian> Do we have a specific glibc maintainer?
<calc> maybe seb128(?) he seems to know a lot about it anyway
<calc> er thats glib nm
<calc> bddebian: maybe doko in glibc case
* calc kicks whoever came up with the conflicting naming of glib and glibc
<bddebian> heh
<calc> failed to upload on ppc also
<calc> appears it may be failing to upload in general
<calc> is the archive already frozen
<calc> and/or would that cause the failed to upload messages to appear?
<calc> 3 out of 5 worked so far though
<calc> so i may have solved the weird random failure issue also
<lhoerste> cjwatson_: is there something that automatically mounts drives in the ncurses installer?
<lhoerste> or that tries to use a swap parititon
<macogw> well, i suppose you're the ones most likely to be able to answer this, so i'm asking here.  does bcm43xx-fwcutter download only 1 set of firmware for anything using it, or does it somehow download different firmware depending on which bcm card it is?
<macogw> ive looked at the orig.tar.gz for it and i dont see any URLs in any of the file except the README
<LaserJock> macogw: looks like just one to me
<macogw> in which file were you able to find the url?
<macogw> i wasnt sure since there's about 20 different drivers and cards listed in fwcutter_list.h
<LaserJock> if you get the whole source package, the .dsc .diff.gz and .orig.tar.gz and run dpkg-souce -x *.dsc
<LaserJock> it's in the bcm43xx-fwcutter/debian/ directory
<macogw> ok
<LaserJock> install_bcm43xx_firmware.sh
<LaserJock> at least that's what I'm guessing
<macogw> i didnt realize it was just a debian thing and not part of it overall
<macogw> though maybe rpm's would do it too and its just a matter of postinst scripts
<macogw> thanks
<sladen> Seveas: Launchpad memberships seem to be expiring again.
<macogw> yeah, the url for the file is in that script, you're right, but i just looked and it's currently a 404 error page
<LaserJock> well, that could be a problem
<macogw> looking at that script, it seems all it does is copy the files to /lib/firmware, and i have them on my computer right now.  i can upload them.
<calc> grr ooo 2.3 failed on sparc :\
<calc> Hobbsee: wb
<Hobbsee> heya calc
<Hobbsee> yay, there's wifi at the uni!
* Hobbsee rsyncs the ubuntu iso on the uni connection
<StevenK> Morning pitti
<pitti> Good morning
<pitti> calc: still here?
<calc> pitti: yes
<pitti> calc: OO.o failed to upload
<pitti> 02:18:26 WARNING        openoffice.org_2.3.0~src680m224-1ubuntu1_powerpc.deb uses bzip2 compression but doesn't Pre-Depend on dpkg (>= 1.10.24)
<pitti> calc: from your bzip2'ification
<calc> ugh
<pitti> calc: I agree that this check is largely obsolete nowadays, but it's quicker to fix OO.o, I think
<calc> is that still required iirc everything past hoary has >= 1.10.24
<calc> quicker to fix and upload a new version?
<calc> and rebuild it on all arches?
<calc> its done on all but i386 so far
<pitti> there go ~ 10 hours of buildd time from now on
<calc> why is that check still in there for the bzip2 stuff anywhere since that dpkg is long obsolete?
<calc> s/anywhere/anyway/
<pitti> calc: can you please prepare it anyway? I'll try to reach someone who could circumvent this
<pitti> calc: but at this time of the day, the Soyuz guys are already asleep
<pitti> infinity: you there?
<calc> pitti: oh its blocking it from being added to the repo?
<pitti> calc: yes
<calc> gah
* calc notes that 1.10.24 is nearly 3 year old dpkg as well
* calc starts working on making new upload :\
<macogw> LaserJock: http://macoafi.googlepages.com/firmware.tar.gz i put the firmware there (i already had it installed, so just copied from /lib/firmware)
<calc> i thought those types of checks were generally removed after an official release of the new dpkg
<pitti> calc: yeah, just nobody did it, I guess
<calc> official release with a new dpkg supporting some feature
<calc> pitti: ah
<pitti> calc: I asked infinity now, maybe we can do a cowboy fix
<calc> ok
<pitti> calc: I seriously hope that we don't need to rebuild
<calc> yea
<calc> the oldest still supported ubuntu release already has a much newer version of dpkg than needed so it should be removed from the checks
<calc> but i'll work on getting it ready
<calc> let me know if infinity can fix it and i'll stop on the work
<pitti> calc: appreciated; I'll grep for the code now, and if we can cowboy it, I'll tell you
<pitti> ah, I think I got it
<calc> ok
<calc> pitti: does it look to be able to workaround it?
<pitti> calc: yes, absolutely
<calc> and/or remove the check entirely
<calc> ok great :)
<pitti> calc: I'll leave the test in
<mthaddon> anyone know if there's a way to get a list of packages you've specifically requested to be installed versus those that were installed as dependencies after the fact?
<pitti> calc: I think I got it now
<calc> pitti: ok thanks :)
<calc> pitti: amd64 still shows as failed to upload does anything need to be done to get it uploaded?
<pitti> calc: yeah, it's a bit weird
<pitti> the other stuff isn't in accepted either
<calc> oh
<pitti> 04:58:08 DEBUG   Skipping 20070808-015000-374232-892251 -- does not match /20070808-015000-374232-892251
<pitti> hm?
<calc> weird
<pitti> calc: ah, ppc build and -l10n is in NEW, silly me
<calc> oh ok
<doko> calc: you did drop the Pre-Depends :-(, uploads rejected ...
<pitti> doko: https://bugs.launchpad.net/soyuz/+bug/131032
<ubotu> Launchpad bug 131032 in soyuz "Please disable obsolete bzip2 dpkg Pre-Depends: check" [Undecided,New] 
<pitti> doko: I just hacked Soyuz to swallow it
<doko> ahh, ok
<calc> doko: yea i dropped it because it was obsolete didn't know that soyuz was buggy until it rejected it
<calc> doko: that feature is ~ 3 years old so shouldn't have triggered a rejection
<calc> eg etch should have officially allowed bzip2 compression (not sure if it actually did or not)
<calc> actually sarge to i think
<infinity> calc: I'm still not sure soyuz is "buggy"... dak has exactly the same check.
<infinity> calc: But I take the point that the check is becoming obsolete.
<pitti> infinity: well, 'bug' is too much, but it's still obsolete IMHO
<infinity> (Note that security updates of OOo will fail in the same way until we similarly "fix" jackass)
<pitti> I don't object against having the pre-depends on the next upload
<doko> calc: what did you drop else? ;-)
<pitti> but I wanted those debs for the tribe now
<calc> doko: i think that is all but i will be going back over the previous diff to make sure everything is merged in the next upload
<calc> doko: i specifically dropped the dpkg depends though since it was obsolete and not needed even in the dapper case
<calc> or rather shouldn't be needed anymore
<infinity> Shouldn't be, but it doesn't hurt either.
<calc> otherwise depends/conflicts/etc would grow huge if you can never prune them
<calc> i'm not sure if its codified but if i remember correctly using dpkg features at least in debian was just required it be in an already released dist, eg the ~ versioning feature
<calc> dak/soyuz doesn't reject on using ~ without a pre-depends does it?
<infinity> pitti: I'll make sure to mangle our various katie installations to drop the check too.  I suspect it's correct to do so at this point.  Just sucks to have the issue forced. :)
<Hobbsee> you know, it'd be really useful if the uni had total wifi, everywhere in it
<calc> infinity: for the record i didn't know it would fail to get into the archive due to dropping the pre-depends
<calc> infinity: so i didn't intentionally cause this mess, heh
<infinity> calc: The reason for the pre-depends check in dak (and later soyuz) was specifically so the feature could be used without waiting for a release cycle.
<calc> infinity: oh ok
<calc> ah and just never removed after the release (hoary i guess)
<infinity> (And, in the case of some dpkg features, you need to wait TWO release cycles...)
<calc> infinity: oh i didn't know about that
<doko> hmm, the sparc build did fail
<infinity> Because otherwise, upgrades could fail.
* calc thinks something about waiting for two release cycles in debian is close to end of the world ;)
<infinity> Pre-Depends on a newer dpkg kinda makes that go away, so long as it's not a required/essential package that causes an upgrade loop with dpkg itself. :)
<calc> infinity: for ubuntu wouldn't that be wait until the next LTS?
<calc> infinity: we support upgrades from an LTS up to the next LTS right?
<doko> dependency "cleanup" became a desease
<doko> http://launchpadlibrarian.net/8732984/buildlog_ubuntu-gutsy-sparc.openoffice.org_2.3.0%7Esrc680m224-1ubuntu1_FAILEDTOBUILD.txt.gz
<infinity> calc: That's undetermined right now.  During the gutsy+1 UDSing, I think I'll attend specifically to deliver my opinions on how we should be dealing with upgrade tactics.
<calc> doko: sparc ICEd not sure if that is the only issue
<doko> g++  -fmessage-length=0 -c -O2 -fno-strict-aliasing   -fno-stack-protector -fvisibility=hidden -I.  -I../../../unxlngs.pro/inc/func -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc/offuh -I../inc -I../../../inc/pch -I../../../inc -I../../../unx/inc -I../../../unxlngs.pro/inc -I. -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro
<doko> /inc/stl -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc/external -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solenv/unxlngs/inc -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solenv/inc -I/build/buildd/openoffice
<infinity> calc: Right now, there's a lot of hand-waving about upgrading from LTS to LTS, but I know that almost zero effort has been put into allowing it.
<doko> .org-2.3.0~src680m224/ooo-build/build/src680-m224/res -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solver/680/unxlngs.pro/inc/stl -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/solenv/inc/Xp31 -INO_JAVA_HOME/include -INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include -I/usr/include     -I/build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/buil
<doko> d/src680-m224/solver/680/unxlngs.pro/inc/offuh -I. -I../../../res -I. -pipe  -g1 -Wreturn-type -Wno-ctor-dtor-privacy   -fPIC -DLINUX -DUNX -DVCL -DGCC -DC300 -DSPARC -DCVER=C300 -DNPTL -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DSPARC -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.1.3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL
<doko> -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DGSTREAMER -DCUI -DSRC680=SRC680   -DSD_DLLIMPLEMENTATION -DSHAREDLIB -D_DLL_   -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON  -o ../../../unxlngs.pro/slo/fupage.o /build/buildd/openoffice.org-2.3.0~src680m224/ooo-build/build/src680-m224/sd/source/ui/func/fupage.cxx
<infinity> doko: Ow.
<doko> calc: there seem to be errors before the ice
<calc> infinity: yea that could potentially take a LOT of work
<Mithrandir> doko: dude, use a pastebin.
<calc> doko: yea it seemed to attempt to compile some code lots of errors on that file and then ICE
<doko> Mithrandir: just two lines ;)
* Hobbsee forces her fingers not to automatically give doko the bott
<Hobbsee> er, boot
<doko> Hobbsee: you're a trainee? ;)
<calc> doko: any ideas on why it would work on all archs but sparc?
<infinity> calc: It will be a lot of work, but if we're starting with a stable toolchain, and a stable set of packages, and we're being conservative about the "bling" we try to put into gutsy+1, we could potentially have a lot of free developer resources to actually (gasp!) fix bugs, and test upgrade patchs.
<infinity> s/patchs/paths/
<Hobbsee> doko: i'm an op on almost all #*ubuntu* channels.
<infinity> calc: Which is definitely a route I'd like to see us take.
<Hobbsee> doko: i dont usually have to think about kicking for floods.
<doko> no, get a recent chroot and the b-d's on faure
<calc> infinity: hehe yea
* StevenK kicks make.
<StevenK> debian/rules:20: *** unterminated call to function `shell': missing `)'.  Stop.
<StevenK> But it ends with a )! It does!
<infinity> Bad quoting?
<infinity> StevenK: Did you get my late night IRC notes about libnss-db?
<StevenK> How does stuff need to be quoted in $(shell )?
<calc> doko: i'm seeing stuff even like this:
<calc> doko: /usr/include/c++/4.1.3/typeinfo:42: error: expected unqualified-id before string constant
<infinity> StevenK: What's the current line that's breaking?
<calc> doko: and lots of things like: /usr/include/c++/4.1.3/cwchar:70: error: expected unqualified-id before 'namespace'
<StevenK> infinity: VAR_DB := $(shell echo | cpp -include paths.h -dD | grep '#define _PATH_VARDB')
<StevenK> infinity: And I did, thank you. I've sorted out mostly everything, I think this is the last bit.
<infinity> StevenK: It's the # it doesn't like.
<StevenK> Ah, backwhack the #?
<infinity> Should do.
* Hobbsee is thinking htis bling is seriously more trouble than it's worth
<infinity> StevenK: And if you are reusing that var later, remember to quote it.
<infinity> StevenK: "echo $(VAR_DB)" will just echo nothing, "echo "$(VAR_DB)"" will work.
<doko> calc: you did drop the ooo-build/desktop/po changes ... that means that people will start mis-translating the wrong translations again ...
<infinity> (If you're using it in shell, that is)
<StevenK> infinity: It's about to be munged further, it will end up being a path.
<calc> doko: er where were the changes?
<infinity> StevenK: awk '{print $2}' to the rescue!
<calc> doko: they weren't in bzr or ooo-build afaict
<infinity> (Because cut is for losers)
<calc> doko: anything in ooo-build probably was dropped in that case
<doko> calc: you did take notes during the sprint ...
<calc> oh shit, yea i need to find those again :\
<infinity> StevenK: Err, print $3, even. :)
<StevenK> infinity: Actually, I'm using cut. :-)
<doko> there was a reason I did ask for the package before an upload :-(
<infinity> StevenK: Loser. :)
<calc> doko: i don't recall you mentioning stuff under ooo-build though during that time, but i'll find my notes
<StevenK> infinity: Bite me. :-)
<calc> doko: i did port the other patches under patches/src680
<calc> doko: ok found the notes
<calc> doko: i have detailed notes for stuff in debian dir but nothing for ooo-build
<calc> doko: is there an easy way to determine which svn revision was pulled from for the last upload you did so i can find what was changed for ubuntu?
<doko> calc: no
<calc> doko: hehehe, so er how do i find what was changed for ubuntu?
<calc> if i can't find a base version to diff against its almost impossible to determine what was ubuntu specific changes
<calc> unless you know in particular what they are
<pitti> calc: publisher finished!
<pitti> calc: -l10n and ooo amd64 are in the archive now
<pitti> everyone with amd64, please test
<calc> pitti: cool :)
<StevenK> infinity: There are three /usr/share/locale/de/LC_MESSAGES/@GETTEXT_PACKAGE@.mo files in the resultant .deb, can we deal, or should I see what's installing them?
<StevenK> infinity: Where de is de, nl and pl
<StevenK> pitti: Actually, I now that Oo.o has built on powerpc, libgcj7-0 can be NBS'd. :-)
<StevenK> s/I //
<pitti> StevenK: finally :)
<infinity> StevenK: That looks a bit messy to me.  And it may also confuse the bejesus out of pkgstriptranslations and/or the rosetta imports.
<StevenK> pitti: And openoffice.org-gcj is also marked as NBS.
<pitti> meh, that still needs some archive.u.c. mirroring, it seems
<StevenK> infinity: Right, I daresay I can fix it by kicking po out of 'SUBDIRS = intl po src' in Makefile.in
<calc> wrt the java stuff ooo 2.3 currently fails to build with java but i'm still working on getting that to work before release
<infinity> StevenK: That won't drop pofiles completely?
* Hobbsee heads home
<infinity> Dear sejong, I hate you.  Love, Adam.
<Hobbsee> infinity: i think you need to show it more forcefully than that
<infinity> Hobbsee: I've forcefully rebooted it twice in the last two hours, what more does it want?
<Mithrandir> infinity: more rough love, of course.
<Hobbsee> infinity: an axe
* Hobbsee stomps on Mithrandir's feet in greeting
<pitti> hey Mithrandir
<Mithrandir> hiya Martin
<StevenK> infinity: .po files weren't installed anyway
<StevenK> Dear yada, you suck, I hate you, and I want you to die. No Love, Steve
<StevenK> Files in first .deb but not in second
<StevenK> -rwxr-xr-x  root/root   DEBIAN/postinst
<StevenK> infinity: I'm ready for you to look at libnss-db again.
<StevenK> infinity: Do you have time again, and how do you want the source?
<StevenK> pitti: Would a new libnss-db be accepted so that yada can be killed, or am I just dreaming?
<StevenK> s/killed/demoted/
<pitti> StevenK: I'll accept it after tribe4
<Hobbsee> StevenK: i preferred it without the substitution
<StevenK> Heh
<StevenK> pitti: In which case, I may as well not upload it until after the freeze lifts anyway
<pitti> StevenK: I thought infinity wanted to put it into Debian or so?
<StevenK> Yeah, the Debian Maintainer is yada's upstream. "Here's this patch to change the build system. Enjoy"
<pitti> StevenK: ooh, "oops" :)
<StevenK> vorlon has a Unoffical release goal to remove yada for Lenny, but he hasn't discussed it with the maintainer ...
<infinity> The Debian maintainer hasn't uploaded it for ages, I might try hijacking it and see what happens. :P
<infinity> StevenK: The po files weren't installed at all?  That seems more like a bug than a feature...
<pygi> morning
<infinity> Unless they're useless.
<StevenK> infinity: Doing a debdiff between the last upload and my debhelper package, doesn't show anything to do with po at all
<infinity> StevenK: Fair enough.  I didn't mean it was YOUR bug, just perhaps a bug. :)
<StevenK> Heh
<infinity> dexter isn't known for his finesse.
<StevenK> Or coding ability.
* StevenK is still twitching after accidently trying to edit the yada-generated debian/rules file
<calc> wow i386 build takes forever, i think the buildd may be a bit slow, heh
<infinity> It's not that slow..
<calc> still going 11hr+ later
<calc> amd64 took 5h50m
<infinity> buildd@rothera:~$ cat /proc/cpuinfo | grep "^model name" ; free | grep ^Mem
<infinity> model name      : Intel(R) Xeon(TM) CPU 2.80GHz
<infinity> Mem:       2076480    1870292     206188          0     398692     942840
<infinity> It could be beefier, but it's not crap.
<pitti> asac: is there hope for bug 128360 or shall we postpone it?
<ubotu> Launchpad bug 128360 in network-manager "nm fails to connect to open network" [Undecided,New]  https://launchpad.net/bugs/128360
<calc> infinity: hmm weird that is taking so long then
<calc> pitti: heh thats my bug, i don't know asac's status on it right now though
<StevenK> infinity: So, how shall I get the source to you?
<calc> pitti: it probably can be postponed but it needs to be fixed before actual final release
<infinity> StevenK: Mail worked last time.
<pitti> calc: oh, btw, did you try OO.o on KDE without installing -gnome? (such as in bug 127944)
<ubotu> Launchpad bug 127944 in openoffice.org "[gutsy] Open Office applications don't start " [High,Confirmed]  https://launchpad.net/bugs/127944
<calc> pitti: something about ipw3945/wpa/nm causes it to not work at all for various people (not just me any more)
<calc> pitti: not yet, i don't have a copy of kubuntu installed right now
<calc> pitti: does removing the gnome/gtk packages cause it to fail or just if the kde ones are installed?
<calc> hmm if it works when gnome/gtk is installed i am confused about the bug i though people claimed it didn't work at all, not just on kubuntu
<pitti> calc: unknown, but I guess removing -gnome makes it crash
<pitti> trying here
<calc> someone running gnome said it failed on it as well
<calc> 2.3 works on ubuntu for me, so i think it may be fixed
<pitti> I just purged -gnome and -gtk, and now it's hanging at the splash screen
<pitti> calc: ^ with 2.2.1 still
<pitti> and 100% cpu
<calc> ok i'll test on 2.3
<calc> pitti: yea it was broken on 2.2.1 with the new glib upload
<calc> pitti: glib changed something that apparently wasn't considered abi stable
<calc> and broke lots of stuff not just ooo
<calc> i'll see if it breaks when removing gtk/gnome for 2.3
<calc> pitti: yea openoffice.org-gtk has to be installed for it to start
<pitti> calc: erk, do we have that on Kubuntu? or is -kde enough?
<pitti> calc: there should be a dependency then
<infinity> Should be, but you can cheat and fix it in the seeds for the Tribe...
<calc> pitti: it wasn't needed until apparently glib did something weird
<infinity> -kde needs to depend on -gtk though, it would seem.
<infinity> Oh, wait.  It fails on non-kde too?
<calc> but glib apparently doesn't consider it a bug to break working programs, nsplugin is broken, acrobat, and several other things aiui
<calc> infinity: yea if you remove openoffice.org-gtk it fails to start
<infinity> Special.
<calc> it worked, then new glib upload, now doesn't work anymore
<calc> without any changes on ooo side
<pitti> calc: so we need to put openoffice.org-gtk on the Kubuntu CDs?
<Mithrandir> that doesn't mean the bug is in glib, it might just as well be other apps depending on undefined behaviour.
<Mithrandir> pitti: that'll make the Kubuntu camp happy. :-P
<infinity> Mithrandir: Longstanding undefined behaviour becomes a feature after a while.
* pitti checks which additional dependencies this would pull in
<calc> pitti: yea for now, that will pull in a lot of gtk/gnome stuff though i think :(
<Mithrandir> infinity: so did the people who stuffed pointers into int claim too.
* calc needs to ask seb128 what the issue is, hopefully he'll know since it bites several other apps
<StevenK> infinity: Mail sent.
<pitti> calc: wow, kubuntu already has libgtk
<infinity> That's not a shock, really.
<pitti> so that would leave gconf2 as additional depends
<pitti> which in turn pulls in more stuff
<pitti> gconf2 libgconf2-4 gconf2-common liborbit2 libidl0
<pitti> calc: ^ extra dependencies of -gtk on Kubuntu CD
<pitti> roughly one MB altogether
<calc> ok
<pitti> ok, *shrug*, I'll seed it for now
<pitti> Riddell: ^
<pitti> needs a -meta upload, though
<pitti> *sigh*
<infinity> meta sucks less than OOo.
<infinity> And OOo is STILL building on i386 anyway...
<pitti> yeah
<infinity> I'll go stop the publisher now, before it starts.
<pitti> infinity: it's on manual already
<infinity> So it is. :)
<pitti> I just ran q-b manually to get the tracker builds
<pitti> waiting for the kubuntu-meta now, then I'll run it again
<infinity> You're stopping b-s before you run q-b, right?
<calc> looks to be something changed between gtk 2.11.5 and 2.11.6
<pitti> yes
<infinity> pitti: Using ~lp_buildd/bin/queue-builder.sh ?
<pitti> infinity: yes, that's what cprov told me
<infinity> (I should just make that also stop and start the sequencer, for great justice)
<infinity> pitti: Oh, good, I didn't know cprov even knew that was there. :)
<pitti> that worked fine so far
<infinity> pitti: It was just my littl cronjob from back when q-b didn't run from b-s.
<StevenK> infinity: Oh, one thing I forgot to mention in the mail is that the diff.gz no longer includes config.{guess,sub}
<pitti> calc: can you please check installing -gtk and -kde and not -gnome?
<pitti> calc: I updated #127944
<pitti> wb calc
<pitti> calc: can you please check installing -gtk and -kde and not -gnome?
<pitti> calc: I updated #127944
<pitti> so it seems that all the trouble of pushing 2.3 (and the associated risk) was in vain :/
<calc> i hate Network Mangler :\
<calc> it took my network down during upgrade
<calc> pitti: its not really any more broken than it was before though, so does get more testing for new version
<pitti> calc: right, but it's quite a risk to update a package like that a day before tribe release :)
<calc> yea
* calc is searching to see if a report was filed against kdebase for the same issue
<infinity> pitti: Pushing it in before a Tribe makes more sense than doing it right after, IMO.  Tribe releases mean broader testing, and a new upstream version needs all the testing it can get.
<calc> Riddell: here?
<infinity> pitti: I know I'm going against the grain on this one, but I'm a fan of "if it builds and installs successfully, and doesn't appear to eat user data, we want to ship it for testing".
* pitti empties the tribe 4 bug list
<doko> pitti: please accept lcms, fixing build failure
<pitti> infinity: as long as it works at all, I'm fine with it
<pitti> infinity: I just fear if it doesn't at all for some weird reason
<pitti> good morning sabdfl
<infinity> pitti: That "weird reason" would be "because it's OpenOffice"..
<sabdfl> moin moin
<desrt> sabdfl; nice article
<infinity> sabdfl: Mornin'.
<sabdfl> desrt: ?
<desrt> you were dugg very recently
* calc notices if it is morning in UK its way past his bed time ;)
<sabdfl> ah
<desrt> about novell shooting themselves in the foot
<sabdfl> with a shotgun, imo
<pitti> doko: done
<desrt> yet lenovo is now shipping novell
<desrt> funny world it is
<pitti> desrt: I see nothign on planet.u.c.?
<pitti> ah, digg
<doko> pitti: does ooo-l10n get the same dpkg-predepends love?
<pitti> doko: it had the same upload failure, yes
<desrt> digg is the devil.  i made a blog post last night and it got dugg and now i have a million moronic comments on my blog that i'm not providing enough information for [random digg reader]  to understand my post
<desrt> uh.. intended audience: planet gnome.  not digg.
<pitti> calc: so, -gtk and -kde together works with 2.3? (without -gnome)
<calc> is there any chance that upgrading network manager will one day not kill the network on the box?
<calc> pitti: sec
<pitti> calc: I think so
<pitti> calc: asac already fixed the opposite problem (tearing down and restarting interfaces at startup)
<calc> it appears it now shuts it down and doesn't bring it back up
<calc> heh
<calc> i had to restart it manually
<calc> pitti: with gtk and kde it works on gnome
<pitti> it seems that ooo grinds through all the translations, too
<pitti> calc: great, thanks
<pitti> calc: so let's hope that the workaround with seeding it to kubuntu works
<pitti> hey mvo
<calc> pitti: hmm i'll need to look into that again, i'm pretty sure i merged it properly from what was in 2.2.1 but maybe i missed something :\
<calc> pitti: i sent email to Riddell and seb128 about the -gtk issue to see if they know any more about the problem and potential solution post tribe-4
<calc> seb128: hi
* calc summoned seb128 with mention of his name ;)
<seb128> Hi calc
<pitti> seb128!
<pitti> seb128: please don't kill me
<mvo> hey pitti
<pitti> seb128: I updated tracker without asking you tomorrow, since we are in a bit of a hurry
<seb128> no, it's just my usual time to start working ;)
<calc> seb128: any idea what caused the breakage in ooo and konqueror/nspluginview with gtk 2.11.6?
<seb128> hey pitti mvo
<calc> seb128: i'm guessing there is probably a patch out there somewhere to fix it already if i know what to look fo
<calc> for
<pitti> seb128: s/tomorrow/this morning/, bah *waking up*
<seb128> calc: no, I though that was fixed with the new ooo?
<seb128> pitti: sure, thanks
<calc> seb128: i thought it was but didn't realize i had ooo-gtk installed at the time which allows it to work, somehow?
<pitti> seb128: see last comment on bug 127944
<ubotu> Launchpad bug 127944 in openoffice.org "[gutsy]  Open Office applications don't start " [High,Confirmed]  https://launchpad.net/bugs/127944
<calc> seb128: apparently whatever causes the breakage if i install openoffice.org-gtk it starts up ok
<seb128> I know that, I get the bug comments and I read most of my bug mails
<calc> seb128: ok np
<seb128> I didn't try to look at the bug though because you told me at the meeting that it fixed with ooo 2.3
<seb128> will have a look
<seb128> having a backtrace of the issue would be nice though
* calc sees if he can make one
<pitti> it's an eternal hang, not a crash, but I guess one could ^C it in gdb
<seb128> there is http://bugzilla.gnome.org/show_bug.cgi?id=463773 upstream
<ubotu> Gnome bug 463773 in gobject "Openoffice and flash run into a deadlock when used with KDE" [Critical,New] 
<seb128> but no real activity on it
<seb128> http://svn.gnome.org/viewcvs/glib/trunk/gobject/gtype.h?r1=5618&r2=5617&pathrev=5618 is the commit mentioned
<seb128> http://svn.gnome.org/viewcvs/glib?view=revision&revision=5618
<infinity> Man, glibc scares me...
<infinity> What exactly is G_UNLIKELY?
<desrt> infinity; static branch prediction hints
<seb128> infinity: you mean "glib"? glibc is not the same one ;)
<pitti> doesn't the kernel have those, too?
<infinity> seb128: Err, finger auto-completion.
<desrt> if (unlikely (condition)) emits assembly which tells the CPU to always branch-predict for the condition being false
<infinity> seb128: I can't type "glib" without adding the "c" on the end.
<infinity> seb128: Much like trying to type "apt-" without "get".
<pitti> finally! that scary LongPointyStick is gone!
* pitti hugs Hobbsee 
<infinity> desrt: You could have stopped at "static branch prediction". :P
<calc_> hmm my network connection died again
<desrt> infinity; eh.  wasn't too much effort to type the rest :p
<calc_> hopefully it isn't a sign of things to come from this new NM update
<calc_> 02:33 < calc> hmm backtrace gives the usual stripped useless data :\
<Hobbsee> pitti: you wish :)
* Hobbsee hugs pitti :)
<seb128> hey Hobbsee
<Hobbsee> hiya seb128!
<calc__> network manager is spawn of the devil
<infinity> calc__: A stripped backtrace is better than none.
<calc__> (gdb) bt
<calc__> #0  0xffffe410 in ?? ()
<calc__> #1  0xbfb1c9c8 in ?? ()
<calc__> #2  0x00000001 in ?? ()
<calc__> #3  0x00000000 in ?? ()
<calc__> or should i be doing something else?
<calc_> 02:34 < calc> is there an easy way to get it to give an apport type dump that  can be retraced?
<calc_> gar!
<infinity> Oh, that's uglier than expected. :)
<pitti> calc__: you need the debug symbol packages
<calc__> hehe
<calc__> pitti: is there one for 2.3 yet?
<pitti> calc__: either install pkg-create-dbgsym and build them locally, or wait until the buildd is finished
<calc__> pitti: ok
<infinity> ... Or run the unstripped binaries from your build tree.
<calc__> pitti: how do i grab the symbols after the buildd is done?
<infinity> Which may be non-trivial for OOo, I admit.
<pitti> calc__: deb http://people.ubuntu.com/~pitti/ddebs gutsy main
<calc__> infinity: don't have them anymore
<calc__> pitti: thanks
<pitti> calc__: you also need the glib/gtk debug symbols, I figure
<calc__> yea
<infinity> The build's been exporting GSI and doing oo2po crap for hours. :/
<pitti> calc__: that reminds me to write that "How to debug a crash with apport" howto :)
<pitti> yeah, in vain
<infinity> glib's symbols might be enough to divine what garbage it's being fed, actually.
<pitti> calc__: try installing libc6-dbgsym libc6-i686-dbgsym libglib2.0-0-dbgsym libgtk2.0-0-dbgsym
<pitti> calc__: and see if bt gets any better
<ccheney> i'm not really still there
<ccheney> nm really is screwing up my system bad
<StevenK> [17:45]  < pitti> calc__: try installing libc6-dbgsym libc6-i686-dbgsym
<StevenK>                  libglib2.0-0-dbgsym libgtk2.0-0-dbgsym
<StevenK> [17:45]  < pitti> calc__: and see if bt gets any better
<ccheney> hopefully a reboot will fix it
<ccheney> "NM making your linux system more like Windows every day"
<ccheney> StevenK: i'll take a look at that in the morning, its 2:45 here now and my desktop which is the system running gutsy has no network access currently after being abused by NM
<ccheney> StevenK: thanks for pasting it for me to see though :)
* ccheney notes this yet another reason he can't run gutsy on both of his systems, way too unstable :(
<ccheney> on my laptop i pretty much can never get a network connection on gutsy :\
<pitti> ccheney: that's what we call 'dogfooding'
<Hobbsee> ah, asac isnt here.
<pitti> ccheney: only with pain like that we devs are actually encouraged to *fix* bugs :)
<ccheney> pitti: heh, i wouldn't be able to get any work done if i tried using it outside a boot cd ;)
<Hobbsee> NM with ipw3945 still doesnt seem to work on open networks, even with the new upload, at least here
<ccheney> pitti: even several days of debugging didn't find a solution for the ipw3945/wpa/nm stack issue
<pitti> Hobbsee: please followup on the bug then
<ccheney> pitti: thats the one you bumped wrt asac
<pitti> right
<ccheney> Hobbsee: it doesn't work at all for me open or wpa
<pitti> ccheney: (just making sure that it gets enough data to get fixed)
<Hobbsee> pitti: i will.  i've only recently got home, and on a *gasp* <whisper> inferior OS </whisper>
<ccheney> Hobbsee: if i kick it just right it will work but i can't get it to be reproducibly working
<Hobbsee> heh
<pitti> ccheney: is it any better to use good old /etc/network/interface and not using n-m?
<_StefanS_> infinity: Do you know anything about that initiative with lpia and kde/qt ?
<ccheney> pitti: no
<Hobbsee> it works fine here with wpa.  just not unencrypted at the uni.
<ccheney> pitti: it works on an open network for me if i use dhclient eth1
<ccheney> is broken for me on both i386 and amd64
<infinity> _StefanS_: You may need to be a bit more specific about what you mean by "that initiative"...
<ccheney> i haven't tested the latest packages but i think it was last week or 2 weeks ago when i was working asac on it
<pitti> ccheney: but wait
<ccheney> Hobbsee: what is funny is from what i recall with the same cd it worked fine at the sprint
<_StefanS_> infinity: well, all I got is a topic in #kubuntu-devel stating that if you're interested in helping with lpia and kde/qt you should say so :)
<pitti> ccheney: if it doesn't even work with ifupdown and without n-m, then there's something more fundamental broken
<pitti> ccheney: i. e. the kernel driver itself
<ccheney> pitti: yea i think wpa's wext driver is broken personally
<_StefanS_> infinity: so it got me kinda interested what it was all about :)
<pitti> ccheney: for open network, ifupdown doesn't use wpasupplicant
<ccheney> pitti: from what BenC told me the driver in the kernel is the same one that was in feisty which worked 100%
<infinity> _StefanS_: I didn't set the topic. :)
<ccheney> pitti: it does it you add the wpa-ssid foo to it
<ccheney> pitti: from what i recall wireless-essid worked
<Hobbsee> infinity: i think it's the adding lpia to the built arches, et
<pitti> ccheney: ah, I see; and with plain 'essid' it works?
<_StefanS_> infinity: probably Riddell did, but Hobbsee said you might know something about it :)
<infinity> _StefanS_: But I imagine it's refering to the need to validate that source packages won't produce broken binaries when built on lpia.
<ccheney> pitti: yea i think so, its been a while since i worked with it
<pitti> ccheney: so iz wpasupplicant bug?
<ccheney> pitti: most likely yes
<pitti> now, that's a data point
<infinity> _StefanS_: https://wiki.ubuntu.com/MobileAndEmbedded/Bootstrap/  <--- A few pointers at common problems to look for.
<ccheney> and then on top NM is just a big mess and causes things to randomly break even for wired networks
<pitti> ccheney: you can tryy by downgrading wpasupplicant to feisty
<infinity> _StefanS_: If you keep a list of packages you've audited and give that Riddell, he may appreciate it.
<_StefanS_> infinity: alright, thanks for the info
<ccheney> pitti: i am going to when i have more time :)
<pitti> ccheney: sure, just giving some triaging thoughts
<_StefanS_> infinity: is the hardware even available yet?
<ccheney> pitti: yea, from what i recall if i changed the wpa driver from wext to ipw it worked for an open network but gave ioctl errors since its not supposed to be used anymore (i think)
<ccheney> pitti: or maybe not supported for ipw3945 i can't remember exactly
<infinity> _StefanS_: Not so much, but any i686 machine can run "lpia" binaries.
<_StefanS_> infinity: uhm ok
<ccheney> pitti: it shows a lot of all 00's for AP bssid etc
<ccheney> pitti: while trying to connect
* _StefanS_ decided to try openSuSE (again)... and once (again) it crashed before installation was finished. Great.
<_StefanS_> Hobbsee: is there any issues with nm ?
<ccheney> _StefanS_: any... heh
<_StefanS_> :)
<ccheney> _StefanS_: the last update killed my network on my desktop
<Hobbsee> _StefanS_: w.r.t?
<_StefanS_> I know its far from perfect... remembering the LEAP patch I made a while back.. api is really screwed
* ccheney is going to bed, bbl
<doko> pitti: please accept valgrind (build on lpia)
<pitti> not yet in queue, I'll try a bit later
<cwillu> is there an #edubuntu-devel'ish thing?
<highvoltage> cwillu: #edubuntu is for that
<highvoltage> cwillu: well, #edubuntu is for everything edubuntu, atm
<cwillu> k
<cwillu> wondering if there's any interest in adding multiseat support
<highvoltage> cwillu: there used to be a multiseat option in the debian-installer, I don't recall anyone using it before though
<mvo> pitti: notification-daemon is uploaded too, yesterdays fix did not build
<pitti> doko: still nothign in queue
<pitti> mvo: ah, good
<cwillu> weird, never noticed that before
<cwillu> although I have a strange sense of deja-vue saying that
<pitti> doko: oh, I accepted that one an hour ago already
<doko> pitti: and mysql-dfsg-5.0 as well
<pitti> that's the same category as mesa and qt...
<doko> pitti: start one of them, so that you still have a free buildd
<pitti> doko: that's not the reason; I don't want to change the current CDs any more than I have to
<cwillu> hmm;  package multiseat is very hotplug'y
<infinity> doko: Any idea how many iterations of this "exporting GSI file for language $i" thing there are in OOo?
<infinity> doko: It's done 69 so far, and it's up to "tr"...
<doko> infinity: until z :-)
<doko> infinity, pitti: get a faster buildd or build on palmer
<doko> be we are having this discussion for at least 12 months now ...
<infinity> doko: Apparently, calc disabled the threaded build, so I'm not sure building on palmer would speed it up much.
<doko> ohh no ...
<doko> he didn't merge, he did take the debian package and did reapply *just some* things
<infinity> No, he disabled it intentionally.  It apparently wouldn't build for him otherwise.
<doko> not my problem
<infinity> :)
<pitti> good morning cjwatson
<pitti> cjwatson: is this a reasonable time already for annoying you with tricky questions?
<mvo> doko: what will python-central do nowdays when a local version of a python module is installed and it can not link the deb files to it? it used to error out, does it still do that?
<doko> mvo: I didn't check for any serious python stuff for gutsy, sorry, so probably no change
<mvo> doko: do you have a policy what to do with error like the one above? won't fix (users fault) or assign to python-central with some mechanism to make it fail more gracefully for the future?
<doko> mvo: I can have a look how to fix it, but probably not for gutsy
<mvo> doko: ok, I reassin with wishlist and subsribe myself, maybe I manage to get something done
<sabdfl> i'm unable to connect to a WPA wifi network using Gutsy and an X60, is anyone around to suggest debugging tips?
<pitti> seb128: is it just me, or did evince get painfully slow in gutsy for you as well?
<doko> mvo: thanks
<sabdfl> a T42 with IPW2200 is able to connect just fine
<mvo> asac: ^----
<seb128> pitti: using the ati driver?
<pitti> seb128: nv here ATM
<seb128> pitti: ok, so no
<pitti> seb128: but I think it's the same with nvidia
<seb128> should not
<pitti> scrolling, switching windows, opening etc. takes some 5 seconds
<pitti> in feisty it was basically instantaneous
<highvoltage> sabdfl: are you using a ipw3945 wireless card? I've had a similar problem on gutsy earlier this week with a Lenovo T60, and the only thing that worked for me was rebooting (I modprobed -r the module and reloaded, and logged out and in again, but it didn't work)
<seb128> pitti: the bug on ATI is due to XAA being slow I think
<seb128> pitti: https://bugs.freedesktop.org/show_bug.cgi?id=4320
<ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned] 
<sabdfl> highvoltage: rebooting didn't help in this case
<sabdfl> i do think its a driver issue
<seb128> pitti: you are the first to complain using a non-ati card :/
* Fujitsu kicks tracker for eating disks.
<sabdfl> the wifi AP does see the mac address of my laptop, but the handshake doesn't complete
<pitti> seb128: tracker it running here now \o/ it ate 130 MB of .cache/, but I/O during indexing was bearable, and it was pretty fast (half an hour for my entire ~ or so)
<seb128> cool
<seb128> pitti: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/122786 about evince slowness
<ubotu> Launchpad bug 122786 in evince "[gutsy]  very hi cpu usage when scrolling pdf" [High,Triaged] 
<mvo> it took 150min (then I switched the machine off) for me
<mvo> aha! and now it is runing again (trackerd)
<pitti> seb128: thanks
<mvo> ~/.cache/tracker is "1,2G" ?!?
<Fujitsu> Oh, neat, tracker just crashed while indexing.
<mvo> seb128: can you think of a way to get rid of the ~/.cache/tracker when the package gets removed?
<Nafallo> cjwatson: thanks :-)
<seb128> mvo: no
<pitti> mvo: packages munging ~ in maintainer scripts -> EBW
<seb128> mvo: don't remove user configuration when they don't ask for?
<pitti> mvo: you don't want that for shared home directories (multiple OS, network home)
<mjg59> It took about 24 hours for me
<mjg59> But now it's done, it's happily sitting there and taking no CPU
<seb128> the way would be to write a "make space" tool
<mjg59> Not even any wakeups
<mvo> pitti: I know, but OTOH, having 1,2G of indexing data ....
<mjg59> seb128: It'd be nice if the diskspace tool could tell you which applications were taking up space in ~
<seb128> mvo: same issue for beagle, thumbnails, etc
<infinity> mvo: That would be your domain.  update-* needs a way to drop hooks, so the next time I log in after removal, it can say "your syadmin as removed package-foo, and it wants to remove your .blah/whatever cache files, is that okay?"
<infinity> mvo: But I suspect most of us would find that icky.
<mvo> seb128: right, sure. this seems to be a bit much, no? it is a lot of data (and it did not even complete, I stoped it before)
<seb128> mvo: still, I don't feel comfortable having the packaging system messing with user datas
<mvo> infinity: that is entirely possible with the tools (and a very good idea)
<seb128> what if you remove tracker to reinstall it?
<mvo> seb128: sure, I think infinity came up with a nice idea, drop a interactive hook
<seb128> I'm not sure that's a "very good idea"
<mvo> seb128: drop a interactive hook thing on purge that gives the user the choice
<infinity> I'd go so far as to call it "an idea", I'd prefer the adjectives be left out of it. :P
* mvo hugs infinity
<seb128> I would prefer a tool knowing about things usually take space
<seb128> or maybe integration with baobab
<mvo> seb128: the CleanupTool spec :) ? until that is implemented a noticiation seems to good compromise, I'm happy to add it myself
<seb128> bah
<pitti> what about automatic invalidation (IOW removal) when the data hasn't been updated for X days?
<seb128> I feel we already have too many things popping up all over the place
<mvo> I wouldn't argue over a couple of MB, but *1,2G*
<infinity> It doesn't need to pop-up, I was just suggesting using the existing framework.
<seb128> mvo: let's try to fix that in an elegant way?
<infinity> A cleanup tool that has the same general hooks-on-purge makes just as much sense.
<seb128> adding notifications is not the reply to everything
<infinity> You get a list of "removed packages for which you have user data:", with a nice disk usage meter next to each.
<seb128> I like this one ;)
<seb128> and not only removed package
<mvo> seb128: we have a framework for droping interactive user information on package interaction that is used e.g. in firefox to tell the user that he has to restart
<seb128> we can list things like the thumbnail cache
<seb128> mvo: yeah, and that "you need to reboot" who stayed in my panel the whole day yesterday is already annoying enough :p
<mvo> thumbnail cache is 59mb for me (and I have a lot of fotos on my system)
<mvo> seb128: easy, just reboot :P
* seb128 slaps mvo
* mvo hugs seb128
<seb128> 484M    .thumbnails
<pitti> seb128: it would probably help already to teach programs to use ~/.cache consistently
<pitti> it's much easier to handle that way for backup program exclusions, 'make space' tools, etc.
<seb128> right
<seb128> is .cache an xdg location or something like that?
<seb128> or do you just suggest using it?
<pitti> no idea
<mvo> *shrug* I have no better solution short of writing the cleanup tool and that is unlikely for guttsy
<pitti> but .config/ is some kind of 'common practice' at least (dunno about 'standard')
* mvo shuts up now
<cjwatson> pitti: sure, have been up for a while, just quiet while catching up with stuff
<cjwatson> you lot have been busy overnight
<cjwatson> Nafallo: hmm?
<pitti> mvo: I agree
<Nafallo> cjwatson: wvdial :9-
<pitti> mvo: if desktop session sees that your ~ is full, it could just invoke that tool
<Nafallo> :-)
<cjwatson> Nafallo: ah yes. seemed sensible
<pitti> mvo: or we hook it into the existing g-v-m 'low space' test
<mvo> pitti: yes, that would be really good
<pitti> then we don't need to pop it up at package purge, but instead when it actually becomes relevant
<pitti> cjwatson: so, this morning I looked into gfxboot{,-theme-ubuntu} and could not find where the actual menu entries and actions are defined; where does that happen? (I was looking into the reason for the broken "OEM" on desktop CDs)
<mvo> I do not argue that point at all, a noticiation is bad, but as long as we do not have a CleanupTool the alternative it to just do nothing
<cjwatson> pitti: http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
<pitti> mvo: automatically getting that on most backup programs still sucks, of course
<cjwatson> pitti: I already mentioned to you I'd fixed that last night ...?
<cjwatson> or at least I thought I had
<pitti> but with a common standard to use ~/.cache or so that could become a default in backup programs, too
<mvo> absolutely
<pitti> cjwatson: I didn't see that from you; thanks, you rock!
<cjwatson> pitti: it was just pointing at /install/vmlinuz and /install/initrd.gz rather than /casper/...
<cjwatson> annoying difference in the live CD layout
<seb128> pitti: .config is an xdg location ;)
<pitti> yay
<pitti> seb128: oh, .config, right; does xdg define something like .cache?
<seb128> pitti: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
<seb128> "$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used."
<pitti> seb128: I already had .cache in my backup exclusions, so some other package used it, too, at least
<pitti> rock
<Nafallo> pitti: thanks for closing some of my bugs on ubuntu-meta :-)
<pitti> Nafallo: I didn't close any AFAIR?
<Nafallo> bug #61620
<ubotu> Launchpad bug 61620 in ubuntu-meta "ppp* in -standard might be better as Recommends" [Undecided,New]  https://launchpad.net/bugs/61620
<Nafallo> for example :-)
<pitti> Nafallo: credit goes to cjwatson :)
<Nafallo> ah, oki :-)
<Nafallo> cjwatson: thanks for that to then :-). I'll close some of them off.
<pitti> closed, thanks
<pitti> Depends: w3m is also questionable as long as it doesn't even work with Launchpad
<cjwatson> heh, pitti and I clashed in closing that
<cjwatson> w3m has many uses other than Launchpad
<pitti> (arguably this should be fixed in LP, but it's long known and it didn't happen yet)
<cjwatson> and w3m works fine with Launchpad anyway
<cjwatson> I use it frequently
<infinity> cjwatson: There's no internet outside of launchpad, you watch your tongue.
<pitti> cjwatson: with authentication?
<Nafallo> hmm. dosfstools is still in standard? :-)
<cjwatson> pitti: yes
<pitti> hm, not last time I tried it, weird
<cjwatson> Nafallo: yes. I was less sure about that. also you're nagging :-P
<Nafallo> I'm closing off bugs ;-)
<infinity> pitti: The number one and two reasons to have a text-based browser installed by default are (1) setting up routers with web interfaces to use your web browser to (2) access google to find out why you have no X, and no firefox.
<pitti> infinity: I don't question that
<cjwatson> Nafallo: I suspect that in reality there are a lot more FAT filesystems out there than reiserfs filesystems ...
<infinity> Launchpad sometimes having questionable browser support is something best brought up with them, really. :)
<infinity> (I know that, for the longest time, it was crap in IE, but when I was forced to work in Windows, I just installed Firefox rather than file bugs, because I was lazy)
<pitti> infinity: my concern is: (1) it still doesn't work with Launchpad (still tried it again, and I keep gettnig an "unsecure cookie thing blabla rejected", and (2) a Recommends: would be sufficient IMHO
<pitti> I guess cjwatson has a more carefully written configuration which unbreaks LP
<infinity> Could be the wildcard cookie.
<infinity> That might actually be a w3m bug.
<infinity> Or LP's doing wildcard cookies in very sketchy ways.
<pitti> I tried three text browsers, and only one has worked with LP OOTB so far (not sure whether it was elinks or lynx)
<pitti> I played around with that for apport reporting bugs on Xless servers
<Nafallo> cjwatson: yes. and usbsticks often use it... I'll change the bug to mention reiserfs and close it off :-)
<infinity> Hrm, "the cookie was rejected for security reasons", or something... Flashed by too quickly...
<pitti> infinity: xactly (I couldn't read it properly either)
<infinity> pitti: lynx tends to work with everything, it's just got the ugliest rendering of the three.
<cjwatson> pitti: I've dropped telnet to Recommends, but there's a bug suggesting it should use telnet-ssl instead, which interoperates in both directions - any thoughts?
<pitti> unfortunately, yes
<cjwatson> even Win98 ships an SSL-capable telnet
<infinity> cjwatson: I don't see how it hurts, since we ship libssl anyway, for other reasons.
<cjwatson> telnet-ssl is in universe, though, so would need an MI$
<cjwatson> MI
<cjwatson> ARGH MIR
<Nafallo> cjwatson: oh, btw. Nafallo Bjlevik now :-)
<infinity> cjwatson: It's netkit code, do we really need an MIR to replace netkit-telnet with netkit-telnet-ssl?
<Nafallo> for future reference :-)
<infinity> cjwatson: Either way, it'd be a no-brainer MIR.
<asac> sabdfl: what is X60? ipw3945?
<cjwatson> Nafallo: legal name change?
<cjwatson> it's so hard to keep track
<pitti> cjwatson: we could demote netkit-telnet in exchange, though
<sabdfl> asac: ipw3945
<Nafallo> cjwatson: yepp :-). no problem, just a heads up :-)
<cjwatson> pitti: let's do that after tribe-4 then, if you're happy
<cjwatson> Nafallo: mkay, cool
<pitti> cjwatson: I am, yes; especially since netcat is a "good enough" drop-in for telnet anyway :)
<infinity> pitti: Am I fair in my assessment of "swapping one netkit telnet for the other netkit telnet is a MIR no-brainer"?
<pitti> infinity: yes, you are (I'll still look on the packages.qa and bugs page, and CVEs)
<asac> sabdfl: it worked for you before yesterdays upgrade?
<pitti> but I doubt that it's much different from telnet's
<infinity> pitti: Two different Debian maintainers for the two different netkit packages, but I'd be surprised if there were any real differences.
<pitti> oh, ooo is at 'xh' now
<pitti> still two Chinese variants to go, I think
<Nafallo> hmm. alsa is still depend of minimal...
<mvo_> pitti: if you look at the queue next time, could you please approve notification-daemon :) ?
<cjwatson> Nafallo: yes, I don't trust recommends of minimal to work right
<pitti> mvo_: yet another one?
<cjwatson> minimal is a subtle seed, quick to anger
<Nafallo> cjwatson: maybe a move to standard or desktop would suffice?
<pitti> mvo_: I just beat it through publisher/queue-builder/ and all the manual stuff soyuz forces you to do nowadays
<pitti> hey Keybuk
<Keybuk> heyhey
<pitti> mvo_: 0.3.7-1ubuntu5 just got built
<mvo_> pitti: no, the one I uploaded this morning, I was just wondering that I did not get a accept mail
<mvo_> pitti: cool!
<iwj> Morning everyone.
<pitti> hey iwj
<asac> sabdfl: if you have latest network-manager (0.6.5-0ubuntu9) and it still fails to connect, then I would like to do some manual wpa-supplicant tests
<iwj> Looks like they fixed my phone line.
<pitti> iwj: so your network's back?
<asac> iwj: welcome back
<mvo_> hey Keybuk, iwj!
<sabdfl> asac: i think it's a wpa problem, or a driver problem
<cjwatson> Nafallo: no.
<sabdfl> is there a way to debug that?
<cjwatson> minimal: * alsa-base # needed for proper hardware detection (hotplug/blacklist.d, modprobe.d)
<sabdfl> i'm not near the network now, it's a home network
<cjwatson> needs to be installed early
<asac> sabdfl: we tried to fix ipw3945 for wpa in network-manager ubuntu9 upload
<asac> sabdfl: however there was a bad ubuntu8 upload just a few hours before ... in case you catched.
<Nafallo> cjwatson: ouch :-/. so I'd guess that would need to dep-wait trusty recommends then :-)
<ogra> mvo, ping
<sabdfl> asac: ok, i'm up to date now, will try later
<asac> sabdfl: thanks ... are you at millbank?
<sabdfl> no, cape town
<asac> ah ok.
<mvo> ogra: pong (I'm leaving for some early lunch now, but I will be back in ~30min)
<ogra> mvo, ok, seems apt fails on another error now while building an ltsp chroot
<mvo> ogra: can you please give me the buildlog into a pastebin? I have a look
<cjwatson> ogra: did you see my pointers on fixing the /cdrom problem?
<ogra> buildlog: http://people.ubuntu.com/~ogra/syslog_tribe4
<ogra> fix ? : http://people.debian.org/~terpstra/message/20070805.002437.f94fb48b.en.html
<ogra> cjwatson, nope
<infinity> pitti: The OOo build should be almost done... I think.
<infinity> pitti: It's up to "zu" in the language list, at least...
<mvo> ogra: thanks, checking
<pitti> infinity: still grinding at zh_TW AFAICS
<pitti> or that
<pitti> infinity: do you have an idea what still comes after that?
<mvo> ogra: that looks reasonable, I invetigate
<mvo> ogra: but lunch first :)
<ogra> cjwatson, but it seems http://people.debian.org/~terpstra/message/20070805.002437.f94fb48b.en.html is my prob
<infinity> pitti: Nope, but I can't wait to find out!
* mvo &
<ogra> mvo, thanks, didnt want to hold you up :)
<cjwatson> ogra: but you aren't using copy:, are you?
<ogra> cjwatson, i was guessing the file:/// protocol might
<cjwatson> 22:01 <cjwatson> ogra: I'd recommend looking at the bit of base-installer/debian/postinst that writes out /target/etc/apt/apt.conf.d/00NoMountCDROM
<cjwatson> 22:01 <cjwatson> ogra: I reckon your problem is that at some point apt unmounts /cdrom
<cjwatson> 22:02 <cjwatson> ogra: if you do that same bit of configuration in the chroot you build for the duration of building it, it should stop things going haywire
<cjwatson> 22:02 <cjwatson> ... probably
<cjwatson> file: != copy:
<ogra> k
<cjwatson> sabdfl: what do you think of bug 109064?
<ubotu> Launchpad bug 109064 in casper "Boot-up option 'Start or install Ubuntu' scares new users" [Medium,Confirmed]  https://launchpad.net/bugs/109064
<sabdfl> interesting
<sabdfl> cjwatson: how would you feel about just "Start Ubuntu" ?
<sabdfl> then making sure that Ubiquity explains what it's about to do, which i think it does very well already
<cjwatson> it would be fine with me - ISTR it was originally "or install" so that we could emphasise the new installation functionality
<cjwatson> but it's possible we've made a big enough deal of that now :-)
<cjwatson> I'm sure I'd get bugs either way; I sort of sympathise with the "this is scary" bit though
<infinity> Noooooo.
<infinity> pitti: dpkg-genchanges: failure: cannot open upload file ../openoffice.org_2.3.0~src680m224-1ubuntu1_i386_translations.tar.gz for reading: No such file or directory
<pitti> infinity: FTBFS?
* infinity cries.
<pitti> ! ! ! *headdesk*
<ubotu> Sorry, I don't know anything about headdesk* - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<infinity> ubotu: Stay out of this.
<infinity> pitti: Double-U.  Tee.  Eff.
<infinity> pitti: Do we get to blame you, or calc?
* pitti takes a look at the source package
<infinity> pitti: (On the plus side, if it needs to be requeued, I'll make sure it ends up on palmer, and we'll see if that makes a speed difference)
<pitti> +       $(MAKE) -f debian/rules -j$(shell expr $(AVAIL_CPUS) + 1) $(STAMP_DIR)/gsi-export-parallel
<pitti> +       : # tell pkgstriptranslations that the translations are built
<pitti> +       -ls -l ../$(PKGSOURCE)_*_translations.tar.gz
<pitti> +       rm -f ../$(PKGSOURCE)_*_translations.tar.gz
<pitti> ????
<infinity> ... what?
<infinity> That must be for -l10n...
<pitti> gsi-export: target
<pitti> binary-indep: $(GSI_EXPORT_STAMP) $(STAMP_DIR)/binary-indep
<infinity> ls -l ../openoffice.org_*_translations.tar.gz
<infinity> -rw-r--r-- 1 root root 36397 Aug  8 01:21 ../openoffice.org_2.3.0~src680m224-1ubuntu1_i386_translati
<infinity> ons.tar.gz
<infinity> rm -f ../openoffice.org_*_translations.tar.gz
<pitti> there
<pitti> but WTF is it doing that?
<pitti> doko: ^ still remember that?
<mjg59> To spite you?
<infinity> I'm afraid I don't grok the logic either...
<pitti> infinity: look at rules, it seems it does gsi-export when building ooo, and not when building ooo-l10n
<doko> it ensures that the tarballs are generated, after the translations are exported.
<pitti> it seems it should do the deletion the other way round
<doko> -l10n doesn't export anything
<pitti> since the amd64 debs are already in the archive and are uninstallable due to -common, we have nailed 2.3 on our testicles now for tribe 4
<infinity> pitti: A lovely mental image, thanks.
<pitti> infinity: I think I'll just comment out the rm now and screw translation export for this round
<infinity> doko: So, since we're calc-free, what needs fixing here?
<doko> infinity, pitti: let me look
<pitti> doko: chinstrap:~ccheney/incoming, btw
<doko> pitti: a new one?
<pitti> doko: no, the current one
<cjwatson> bug 124825 is an interesting idea
<ubotu> Launchpad bug 124825 in casper "Live-cd should notify the user of prolonged boot time" [Undecided,New]  https://launchpad.net/bugs/124825
<doko> pitti: when does pkgstriptranslations run? apparently it currently does not run with dh_builddeb -i?
<infinity> doko: It runs from "dpkg-deb -b"
<pitti> it hasn't changed recently
<infinity> doko: Which would be a fork of dh_builddeb, yes.
<pitti> doko: it should run on -i, too
<doko> : # tell pkgstriptranslations that the translations are built
<doko> ls -l ../openoffice.org_*_translations.tar.gz
<doko> -rw-r--r-- 1 root root 36397 Aug  8 01:21 ../openoffice.org_2.3.0~src680m224-1ubuntu1_i386_translations.tar.gz
<doko> it's correct, because the translations are not yet exported
<doko> but it doesn't run for -i
<infinity> Err, really, it just runs every time dpkg-deb is invoked.
<doko> apparently it doesn't. after the removal of the wrong tarball, dh_builddeb -i is invoked
<cjwatson> doko: apt-get source pkgbinarymangler - it doesn't check -i and it couldn't because that's a debhelper flag which isn't passed to dpkg-deb
<cjwatson> all -i there controls is which binary packages have dpkg-deb run on them
<infinity> Okay, I'm incredibly confused by this, though.
<cjwatson> it could go wrong if the relevant binary package isn't Architecture: all
<asac> doko: liborbit2-dev is not yet avail on lpia ... will try in a few hours again
<pitti> NO_PKG_MANGLE=go-away
<infinity> I see nowhere in my dpkg-deb wrapper, or in pkgstriptranslations, where it would exit silently without printing a message.
<pitti> ^ from the build log
<doko> pitti: I have a version ready for upload which just disables the gsi export
<infinity> pitti: Even NO_PKG_MANGLE prints a warning from dpkg-deb, though.
<cjwatson> setting NO_PKG_MANGLE would certainly make pkgstriptranslations not run
<pitti> doko: ah, great; will that also disable the gsi build, to save some hours of buildd time?
<pitti> cjwatson: but that shuold leave a message at least
<doko> pitti: this is for the internal dpkg call, which should be fine
<mvo> ogra: just read backlog, let me know if the fix from colin helped
<doko> internal to the OOo build
<pitti> doko: thanks a lot
<doko> pitti: yes, but I would be glad to see the real problem with the gsi-export stuff ...
<pitti> doko: so, if that also stops the lengthy 'localize' loop, it would be awesome; if not, *shrug&
<doko> pitti: it does. one liner
<pitti> doko: real problem> indeed, we need to fix that anyway
<infinity> pitti: I'll admit to being incredibly confused at this point.
<infinity> pitti: Can you seen anywhere in our codepath where it can exit (or run, for that matter) without printing to the log?
<pitti> infinity: if it's not called with -b
<pitti> as first argument
<infinity> pitti: Well, okay, but then it won't build a deb either.
<infinity> OH!
<infinity> DUH.
<infinity> -Zbzip2 -b
<infinity> I'm retarded.
<infinity> Fix on the way.
<infinity> doko: Don't bother uploading.
<doko> infinity: do you still have the build?
<infinity> doko: I'll just requeue on palmer, so the GSI stuff goes faster.
* infinity wonders how that was never a problem before...
<pitti> infinity: could still be a net gain to upload doko's and skip the GSI build?
<doko> infinity: you can make the gsi stuff even more faster
<pitti> time is pressuring now
<infinity> pitti: OOo-l10n built in 5 hours on palmer, which is essentially the same as OOo-i386...
<pitti> infinity: wow, that's a difference; 5 hours sounds ok
<doko> infinity, yes, but without doing the gsi export
<pitti> ah, right
<infinity> doko: Oh, so -i386 is still quite a bit slower?
* infinity shrugs.
<infinity> Your call.
<infinity> I'm fixing the mangler now, though.
<infinity> Before I forget.
<pitti> doko: please upload your version then
<doko> gutsy chroots are non-functional
<doko> on ronne
<pitti> doko: you might succeed with a fakechroot
<pitti> doko: ~pitti/bin/retracer-login-i386
<pitti> doko: or put a debdiff somewhere, and I'll try
* infinity notes that -Zbzip2 isn't even documented in dpkg-deb(1)
<pitti> (or just tell me what to change)
<doko> generating debdiff in feisty
<infinity> In fact, the manpage led me to believe that -b|--build had to be the first argument.
<pitti> doko: do you need to build the source on gutsy actually?
<infinity> Hrmph.
<doko> pitti: ronne:~doko/ooo/23/ooo.debdiff
<infinity> Lying documentation, for the loss.
<doko> pitti: ok to upload?
<pitti> doko: oh, sure
<pitti> doko: I thought I should build the source now, misunderstood
<doko> uploaded
* infinity puts vernadsky and rothera on manual, so palmer's the only choice to catch the build.
<pitti> infinity: we still have 45 minutes (/me wishes build-from-accepted would actually work...)
<pitti> c'mon, appear in the queue
<infinity> pitti: It should work.  Run the queue-builder ASAP after it hits queue/DONE.
<infinity> pitti: Don't bother with the publisher at all.
<pitti> queue/DONE -> after 'q -Q unapproved accept openoffice'?
<infinity> pitti: Yeah.  Oh.  Hrm.
<pitti> there it is, accepted
<infinity> The unaccept workflow may mess what that.
<infinity> Did it go to accepted, or to done?
<infinity> In normal operation, sources go straight to "done" now, but the unaccpted thing might put a kink in that.
<pitti> 'done'?
<infinity> unapproved, even.
<pitti> infinity: in /srv/launchpad.net/builddmaster?
<infinity> No, sources.
<infinity> So, the actual done queue.
<mjg59> jamiemcc: Tracker-search-tool doesn't do live updates?
<pitti> infinity: that's above my head ATM, I'm afraid
<infinity> pitti: I'm looking. :)
<infinity> Damn.
<jamiemcc> mjg59: what do you mean?
<infinity> pitti: The unapproved/frozen workflow breaks build-unpublished-sources, so we'll need to publish. :/
<pitti> 'k, publisher started
<pitti> infinity: how very nice that this is basically the only use case where b-f-a is actually important :)
<mjg59> jamiemcc: If I perform a search and get no hits, then create a file that matches the criteria, the search results don't get updated
<mjg59> I need to trigger a new search
<jamiemcc> mjg59: yes that meeds to wit for XESAM
<jamiemcc> wait
<jamiemcc> XESAM wil define live query updates
<infinity> pitti: Of course, I still give 20-to-1 odds that we can remove the locking from queue-builder and run it in parallel with the publisher.
<infinity> pitti: Feeling adventurous? ;)
<pitti> infinity: I discussed that with cprov yesterday
<infinity> pitti: (Note that the source in question has a publishing record already, since that's the first thing the publisher does... And that's all the queue-builder needs to make a queue entry)
<pitti> infinity: and I still fail to see how that shared lock should prevent the 'fetch build dep' race that it was meant to avoid
<pitti> infinity: right, I agree; if we could run q-b now, that would be awesome
<ogra> cjwatson, mvo, i dont think its apt unmounting the CD... apparently i just cant see it ijside the chroot anymore
<pitti> infinity: AFAICS, the worst that can happen is that the archive updates while a buildd apt-get updates and fetches b-deps, right?
<infinity> pitti: The race is that packages will get un-dep-waited based on binaries that have publishing records, but aren't on-disk.
<infinity> pitti: But, oh well, they just get auto-dep-waited again. :/
<pitti> yep
<pitti> it would be incredibly useful for times like this
<ogra> i get the same error building a client chroot manually from CD even the cd is still mounted on the server
<mvo_> ogra: so the issue went away magically?
<ogra> no
<mvo_> ogra: what do I have to run to reproduce it?
<ogra> its just not apt's fault i think, somehow the mounting doesnt work as it used to
<cjwatson> ogra: I mean unmounting /cdrom inside your chroot
<cjwatson> which is equivalent to "can't see it inside the chroot any more"
<ogra> cjwatson, it isnt even mounted
<cjwatson> doesn't ltsp-client-builder bind-mount it?
<cjwatson> it seemed to me from the code that it was supposed to
<ogra> oh, hmm, figth
<ogra> err right
<ogra> the manage mirror plugin does that
<cjwatson> and this is exactly why base-installer configures apt to turn off any auto-mounting/unmounting it might try to do
<cjwatson> you seem to be sitting in the exact same use case, so I'd have thought the same code ought to work :)
<cjwatson> (not that I've reproduced your problem - no Edubuntu images handy right now)
<ogra> yeah, seems like the same issue
<Enola_Gay> hi all
<Enola_Gay> Is there any list which patches are already integrated of this Blueprint https://wiki.ubuntu.com/power-management-in-Ubuntu ?
<Enola_Gay> Will there be a separate HPET kernel?
<infinity> pitti: Fixed mangler incoming.
<pitti> infinity: cheers
<pitti> infinity: I guess it'll be built and in the archive before OO.o comes that far :)
<infinity> pitti: Yeah, but the build won't magically update itself.
<pitti> ah, true
<pitti> anyway, shouldn't matter
<infinity> (I could upgrade the chroot during the build, so we can make sure my fix worked. :))
<pitti> 3v1l :)
<infinity> Also, I'm very tempted to give this thing en epoch and start renumbering it... being at version "40" already is a bit odd. :)
<pitti> infinity: can you please quickly answer on #soyuz?
<cjwatson> versioning> works for partman
<cjwatson> if your versions are really just a counter and there are no compatibility implications, then who cares ...
<infinity> ugh, I hate eyeballing a debdiff when I've changed indenting...
<infinity> Can you feed debdiff diff arguments, so it'll ignore whitespace?
<cjwatson> with a few packages I've been bumping a minor (once, as in gfxboot-theme-ubuntu, or twice, as in ubiquity) for each Ubuntu release cycle as a reminder
<cjwatson> infinity: it generally uses interdiff, and doesn't have the facility to pass extra options to it
<cjwatson> interdiff does have a -b option, so you could just hack debdiff temporarily
<infinity> cjwatson: Given the ubuntu-nativeness of it all, I would have preferred 6.06.0, 6.06.1, etc, and then 6.10.0 when we opened a new release, os some such.  Since the package really only exists in buildd chroots, it becomes obvious which version is used where.
<cjwatson> yeah. same for livecd-rootfs
<infinity> Point.
<Enola_Gay> Are there any plans to ship the windows installer http://wubi-installer.org/index.php with Gutsy CDs?
<pitti> infinity: is there a slow/fast buildd for amd64? (just to avoid another potential pitfall)
<cjwatson> Enola_Gay: hoping to, yes
<infinity> pitti: Nah, they're all the same.
<infinity> Oh, crap.
<cjwatson> Enola_Gay: working on the infrastructure for it
<infinity> That's why I didn't want a new upload. :/
<Enola_Gay> cjwatson: cool, thanks
<infinity> Cause we have to build on *all* arches again.
<infinity> Grr.
<infinity> I guarantee palmer would build the last version faster than our slowest arch will build the new version.
<infinity> Note, selecting patchutils for regex interdiff
<infinity> Is that... New?
* infinity looks at apt.
<cjwatson> Package: patchutils
<cjwatson> Provides: interdiff, extractdiff
<mvo_> infinity: not new, I'm sure
<cjwatson> isn't it just regular provides-following
<cjwatson> ?
<infinity> Yeah, apt didn't used to auto-install provides... I'm sure of it.
<infinity> Maybe I'm on crack.
<pitti> infinity: no pkgbinarymangler in the queue FYI
<mvo_> usualy I remember the pain^Whacking on apt
<infinity> (Note that when I use the term "new", I mean "since potato")
<infinity> pitti: Yeah, I know.
<Amaranth> iirc as long as only one thing provides it it just does it
<Amaranth> otherwise it gives you a list and makes you hate it
* pitti spots package 'happycoders-libdata-dev' and raises eyebrow
<infinity> pitti: Should be in the queue in 3 mins (on the :55 queue run)
<ogra> cjwatson, doesnt help :/
<infinity> Oh, FFS.
<infinity> pitti: Don't accept it.
<ogra> also i see it retrieving Release.gpg and Release .... then i get the "Hash Sum mismatch" error
<mjg59> seb128: When you have a chance, could you possibly apply the patch from http://bugzilla.gnome.org/show_bug.cgi?id=370937 ? The gstreamer stuff is already in the archive
<ubotu> Gnome bug 370937 in mixer "Exessive CPU Utilisation" [Minor,New] 
<pitti> infinity: palmer grabbed OO.o, so you can un-MANUAL the others
<infinity> pitti: Don't accept my upload.
<infinity> pitti: I'm a retard.
<pitti> infinity: right, I won't
<pitti> (it's not in the queue anyway, so I can't reject)
<infinity> ORIGINAL_ARGUMENTS=$@
<infinity> [ much code to walk and destroy $@ ] 
<infinity> dpkg-deb $@
<infinity> \o/
<pitti> heh
<mvo_> ogra: I see some strange hashsum error here currently, I investigate, you can run apt with -o Debug::Hashes=true
<ogra> will try to
<pitti> infinity: rejected, to prevent myself from doing stupid things without looking
<mvo_> ogra: add also -o Debug::pkgAcquire::Auth=true
<ogra> eek
<ogra> anything else ?
<ogra> running
<pitti> infinity: I love the buildd time of OO.o on ia64; can't we use the same stub package on the other arches? (would anyone notice the difference?)
* pitti runs
<infinity> I wouldn't notice the difference.
<infinity> I think I use OOo about once a year.
<ogra> mvo_, http://paste.ubuntu-nl.org/33017/
<infinity> pitti: Alright, better one on the way.  One that kinda works, even.
<mvo_> ogra: thanks, that looks good, checking it now
<ogra> i'm sure now that zthe cdrom stays mounted btw
<infinity> pitti: Feel free to approve the new mangler, I even tested it.  (shock and horror)
<pitti> infinity: TESTED! don't spoil our development procedures
<infinity> pitti: Sorry to disappoint.
<Amaranth> OOo? Is that the thing in the Office menu I've never opened? :)
<pitti> Amaranth: it's the thing that pops up when friends mail you some jokes in powerpoint format
<Amaranth> Oh, right
<Amaranth> It usually crashes shortly after, too
<stgraber> pitti: I won't be around this afternoon, can you add the ISOs on the tracker when they are built ?
<infinity> pitti: Or, should I just approve it myself? :P
<ogra> mvo_, i wonder if its zlib's fault ... it seems to only happen with the .gz files
<mvo_> ogra: oh? interessting
<ogra> mvo_, well, guessing by the debug output :)
<seb128> mjg59: I can do that, thanks for pointing it ;)
<mjg59> seb128: Thanks!
<seb128> np
<Keybuk> seb128: so, err, I found out why my computer is slow by reading the Tribe 4 freeze announcement
<Keybuk> is tracker supposed to be using all my CPU, I/O and memory?
<jamiemcc> keybuk: no its the kernel's fault
<mjg59> Keybuk: Some of the behaviour seems to be due to some change in 2.6.22
<Keybuk> it's polling and getting SIGCHLD?
<jamiemcc> keybuk: see:http://jamiemcc.livejournal.com/9520.html
<mjg59> Keybuk: It has two child threads
<pitti> stgraber: will do
<pitti> infinity: I'll get to that (just want to eyeball the debdiff)
<mjg59> They're the ones actually using the CPU
<Keybuk> mjg59: what's the general cause?
<pitti> infinity: nothing in queue, did you accept it already?
<mjg59> Keybuk: Of what?
<pitti> infinity: please flip rothera and vernadsky back on, I need some other builds
<pitti> infinity: nevermind, I did it myself
<Keybuk> mjg59: tracker slowness?  or is the change in behaviour that's broken it unknown?
<mjg59> Keybuk: Unknown
<mjg59> Once the indexing is completed, it's fine
<Keybuk> interesting
<Keybuk> the cpu usage seems to be all poll/eintr for sigchld ?
<jamiemcc> indeixng is 5 x faster on feisty when indexing same files
<mjg59> Keybuk: Have you straced the children?
<Keybuk> no, just the parent; killed it before I knew there were children
<pitti> jamiemcc: I think we don't explicitly disable tracker on the live system; but I hope that won't matter much because home is basically empty anyway?
<mjg59> Keybuk: The CPU use is in the children
<jamiemcc> pitti: hopefully
<mjg59> Keybuk: You realise that thread CPU use will all be assigned to the parent now, right?
<Amaranth> jamiemcc: the gentoo thing you link to in your blog can't be it
<Amaranth> jamiemcc: because i still get really fast disk speeds with hdparm
<jamiemcc> amaranth: you might be right
<jamiemcc> but heavy disk io is a problem for these newer kernels
<Amaranth> ubuntustudio-sounds |        0.5 | http://archive.ubuntu.com gutsy/main Packages
<Amaranth> ubuntustudio-sounds |        0.5 | http://archive.ubuntu.com gutsy/universe Sources
<tsmithe> is there an admin that can help me figure out that oddity?
<Amaranth> anyone know what's up with that?
<tsmithe> Amaranth, you just beat me to it :p
<Amaranth> tsmithe: you take too long :)
<tsmithe> i was waiting so as not to interrupt ;)
<pitti> Amaranth, tsmithe: fixed, thanks for pointing out
<pitti> (probably a mistake when binary-NEWing the packages)
<tsmithe> thanks pitti; do you know how that happened?
<tsmithe> ahh ok
<Fujitsu> How is it possible for that to happen?
<Fujitsu> Shouldn't there be some logic to forbid that?
<pitti> Fujitsu: forgetting to override the component to universe when NEWing it
<pitti> it appears on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<pitti> so sooner or later we'd have caught and fixed it anyway
<tsmithe> why don't we just set the component in debian/control's Section?
<Fujitsu> I could see how it was done, I just thought there would be some check in Soyuz to disallow it.
<Fujitsu> tsmithe: Debian imports, mainly.
<tsmithe> mmhmm
<cjwatson> also components in Section tend to get out of sync as we move stuff around
<pitti> tsmithe: that's possible
<cjwatson> we decided way back before warty not to rely on that
<pitti> tsmithe: just that nobody actually does it, and it's not consistent anyway
<cjwatson> although as pitti says, component in Section will set the default for Soyuz queue processing
<tsmithe> ok then, makes sense
* pitti grabs some lunch, bbl
<infinity> cjwatson: Do we have an open soyuz bug, by any chance, about defaulting binary component overrides to match source components on NEW binaries?
<Hobbsee> asac: yesterday's update of the network mangler doesnt fix the connecting to an open network, btw.  (ipw3945).  i believe that's part of what you were testing.
<Hobbsee> (now that you appear to be here)
<asac> yes i know
<asac> should fix wpa
<asac> Hobbsee: ^^
<asac> Hobbsee: would be great if you can verify
<cjwatson> infinity: yes
<cjwatson> infinity: err. actually no, I don't think so. we have a similar one about selecting more appropriate defaults (component mapping).
<ogra> mvo_, so do you have any idea ? i can apparently now reproduce it maunaully as well (chrooting and running apt-get install ltsp-client) it doesnt happen on networked installes
<mvo_> ogra: not yet, sorry. what command do I have to run to reproduce it? will I need a edubuntu CD for this?
<ogra> mvo_, yes you need an edubuntu CD ... mount it in /cdrom and run: sudo ltsp-build-client --mirror file:///cdrom --security-mirror none
<ogra> thats what the udeb does as well ...
<ogra> if it failed, you can bind mount /cdrom to /opt/ltsp/i386/cdrom, chroot, mount /proc and its reproducable on apt-get update
<mvo_> ogra: gutsy-server I assume?
<ogra> yep
<AlinuxOS> asac, ping
<highvoltage> Znarl: nice exit message :)
<asac> AlinuxOS: just ask :)
<mvo_> ogra: downloadin
<ogra> mvo_, thanks :) ... i'm really lost without getting that fixed
<mvo_> ogra: no worries, we get that fixed!
<ogra> (especially since i have no clue whats wrong exactly)
<AlinuxOS> asac, hello (& hello all) https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677 can we doo something ?
<ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
<ogra> well, it bothers me that i just did a base install and pkgsel before it happens in the install ... so it cant be the CD's fault
<ogra> must be ltsp or chroot related
<asac> AlinuxOS: we need someone to maintain that language upstream
<asac> AlinuxOS: maybe ask carlos if we can do that in launchpad/rosetta through an ubuntu community efford
<AlinuxOS> http://www.mozilla.com/en-US/firefox/all.html Georgian is in a main list.
<AlinuxOS> main Beta list.
<carlos> AlinuxOS, asac: We are finishing support in Launchpad for Mozilla xpi files
<AlinuxOS> for Firefox 1.5 Georgian package was made by pitti.
<AlinuxOS> Feisty - no Georgian mozilla support.
<carlos> in the mean time, you need that an ubuntu developer handle that directly
<AlinuxOS> Gusty - too.
<asac> carlos: thought you are already at a beta stage :)
<asac> carlos: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/linux-i686/xpi/
<asac> is the xpi in that list?
<carlos> I guess that's a question for AlinuxOS...
<asac> carlos: sorry yeah AlinuxOS ^^
<Hobbsee> asac: my WPA always works with nm.  *touch wood*.  always has since it was introduced.
<asac> Hobbsee: on ipw3945?
<Hobbsee> asac: yep.
<Hobbsee> asac: well, since feisty, anyway
<asac> Hobbsee: ok, so latest update did at least not break that for you :)
<Hobbsee> asac: correct, i think.  i'd have to actually boot back into linux to double check, i dont remember quite when i did the update
<Hobbsee> :)
<AlinuxOS> asac, carlos http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/linux-i686/xpi/ Dear people, on this URL Georgian ka.xpi is present.
<asac> AlinuxOS: please update the bug with a direct link to that xpi
<asac> AlinuxOS: thanks
<AlinuxOS> asac, against which package ?
<AlinuxOS> asac, you mean here? https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677
<asac> AlinuxOS: mozilla-firefox-locale-all .. however we already have a bug ... please reassign it to that package and attach info to that bug
<ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
<asac> AlinuxOS: yes
<Hobbsee> asac: i thought you'd done some messing with ipw3945, including open networks, which was why i asked.  incidently, it does show connected to the open network, but it clearly isnt (as it doesnt bring up the uni portal page)
<asac> Hobbsee: i mainly did work on fixing ipw3945 for wpa ... as for lots of people it didn't work
<asac> Hobbsee: i will take a look at open systems for the next release
<Hobbsee> asac: yeah.  that surprises me though, that it works for some, and not others.
<AlinuxOS> asac, should I attach ka.xpi file ? Or maybe direct link to ka.xpi: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.6/linux-i686/xpi/ka.xpi is enough?
<asac> Hobbsee: indeed
<asac> AlinuxOS: please the link
<AlinuxOS> asac, ok thank you.
<asac> AlinuxOS: i targetted it for tribe-5 now ... so we won't forget
<TheMuso> If the notificatio area/applets area of the panel was accessible, and hense accessing nm, I would help test, as I have a notebook with wireless, a PCMCIA wireless card, and a mac mini with airport/Broadcom chipset needing fwcutter et al, and I would help test...
<AlinuxOS> asac, thank you.
<cjwatson> why no, mr. profiling tool, I don't believe you that ubiquity is only using 2.5MB of heap. It would be *nice* ...
<StevenK> Hah
<AlinuxOS> Since 2.18 version Dejavu fonts project has (finally) Georgian language support, but current Gusty package is Dejavu 2.17-2. I've even filed a bug dated(2007-07-01): https://bugs.launchpad.net/ubuntu/+source/language-pack-ka/+bug/123404
<ubotu> Launchpad bug 123404 in language-pack-ka "language-pack-ka & and it's font dependency (ttf-bpg-georgian-fonts)" [Undecided,In progress] 
<AlinuxOS> I've assigned that but to pitti but I'm not sure.
<AlinuxOS> doko, ping
<pitti> AlinuxOS: that doesn't have something to do with language-support; it needs to be packaged first
<pitti> ttf-dejavu |     2.17-2 |         gutsy | source, all
<pitti> AlinuxOS: ^ is it that font package? or a different font with the same name?
<ogra> mvo_, hmm, running sha1sum on the Packages files gives me the right output (matching the apt debug output) for the Packages.gz the sha1 is different than what apt thinks it should be
<mvo_> ogra: the CD is at 93%
<AlinuxOS> pitti, no it's different ..but some fonts derive from ttf-bpg-georgian-fonts. bgp now collaborates with Dejavu project too.
<AlinuxOS> Dejavu 2.18: added Georgian Mkhedruli to Sans, Serif and Mono, Asomtavruli to Sans and Serif (by Besarion Gugushvili)
<pitti> AlinuxOS: http://changelogs.ubuntu.com/changelogs/pool/main/t/ttf-dejavu/ttf-dejavu_2.17-2/copyright says that this is the very same project
<pitti> AlinuxOS: so it's a new version, but not a different project
<AlinuxOS> pitti, maybe I misunderstood you...
<AlinuxOS> 2.17 and 2.18 are are versions fro Dejavu project
<AlinuxOS> since 2.18 there is Georgian support.
<AlinuxOS> :)
<AlinuxOS> surrent Dejavu font version is 2.19.
<pitti> AlinuxOS: I updated the bug, please answer there
<pitti> AlinuxOS: I subscribed ArneGoetje, too (our new i18n master)
<AlinuxOS> ah, pitti I know him :)
<pitti> Keybuk, Mithrandir: do you know why sysvinit appears in the "updated merges" instead of "new merges" list? it hasn't been merged for over a year, after all
<pitti> Keybuk: I was specifically looking into dropping our 'multiuser' changes in favor of LSB headers
<Mithrandir> pitti: might have been updated in Debian?
<pitti> Mithrandir: I don't understand your question
<pitti> I mean "s/new merges/outstanding merges/
<Mithrandir> pitti: doesn't it go to "updated merges" if it has been updated in Debian?  Or am I confused?
<pitti> Mithrandir: so, there have been tons of udpates to sysvinit in Debian in the last 14 months
<StevenK> It goes into Updated Merges if it's been touched in Gutsy, I thought.
<StevenK> (Which it has)
<pitti> StevenK: aah, that would be it
<pitti> I thought it would be more clever about that
<mvo_> pitti: it would be cool to get this merged, but I noticed that some update-rc.d arguments might be incompatible in the newer version
<AlinuxOS> pitti, done. thank you for attention!
<Keybuk> pitti: updated just means that it's been *uploaded* to gutsy
<Keybuk> not that the upload was actually a merge
<pitti> mvo_: yeah, it needs to be treated with care, and we should leave our 'multiuser' hack for a while
<mvo_> pitti: yep
<pitti> but we should slowly move away from multiuser anyway
<Keybuk> we should? why?
<pitti> Keybuk: in favour of LSB headers in the init script (as suggested by Debian)
<pitti> Default-Stop:      1
<pitti> instead of the default "0 1 6"
<Mithrandir> they're fugly, though. :-/
<Keybuk> most of the LSB headers in our init scripts are wrong though
<pitti> Keybuk: yeah, therefore the 'slowly'
<Keybuk> it would be some work to make them right
<pitti> Debian moves towards lsb headers now anyway
<Keybuk> and investing time in init scripts seems pointless given we intend to deprecate them?
<pitti> Keybuk: I agree, and I don't say that we should invest much effort into it
<pitti> just that it would be nice to have the LSB header parsing, too, to drop delta with Debian
<Keybuk> but we can't switch it on until we've fixed all the init scripts
<pitti> well, at least made sure that the existing LSB headers have correct Default-{Start,Stop}, yes
<pitti> it just crossed my eye and I wondered about the merge status, but now that I know what MoM considers as 'updated merge', it's clear to me now
<Keybuk> I don't think we've merged sysvinit in quite a while anyway
<Keybuk> (ie. a number of releases)
<pitti> right, that's why I wondered why it appears in 'updated merges' :)
<pitti> mhb: AYT?
<mhb> pitti: sure
<ogra> dendrobates, the three ldap related main inclusion reports need to be rewritten first (thats why i've putten them under: "These three need a proper rewrite of the report first" ;)) ... iwj refused to approve them in in this form ...
<dendrobates> I asked pitti to look at one and he said it was fine.  So I thought they had been rewritten.
<dendrobates> ogra:  What exactly needs to be done to them?  I'll do it today.
<ogra> not by me ... and apprently i'm the last who changed the pages ...
<ogra> there is a new template format afaik ...
<pitti> ogra: looked good enough to me *shrug*
<ogra> pitti, to me as well ...
<ogra> dendrobates, if pitti is fine, all is good ;)
<dendrobates> ogra: ok, thanks.
<dendrobates> ogra: The server tean is doing quite a bit on the ldap auth front.  We need to discuss what impacts it might have on edubuntu.
<ogra> dendrobates, a good one i suspect ;)
<ogra> dendrobates, ltsp local apps and ltsp fat clients are both depending on a properly working ldap server setup
<ogra> both are long awaited features in edubuntu and ltsp
<dendrobates> ogra: we are tackling the client side first, just because of time.  I hope to do the server work in gutsy+1
<pitti> ogra: ETA for OO.o is some three hours, afterwards the upload gates will be closed, and it'll take a very good reason to accept something; how does things look at your front?
<ogra> yeah, thats fine
<ogra> pitti, all broken
<pitti> ogra: I didn't follow the md5sum issue
<ogra> no fix in sight yet for the hash mistmatch ... (mvo is looking)
<pitti> ogra: that is, uploads which affect ubuntu/kubuntu CDs; uploading ltsp is still fine, of course (at the price of delaying your CDs)
<pitti> ogra: d'oh :/
<ogra> pitti, i still have to sort size issues on the desktop CD ...
<ogra> the hash crap kept me busy digging all day :(
<mvo_> ogra: I think I have a patch, would you be able to test it?
<ogra> mvo_, INDEED !!!
<mvo_> ogra: you prefer a package or a diff? what arch do you need (if package)?
<ogra> i386
<mvo_> ogra: I'm currently runing it through my testsuit, if it survies that, I will send it to you and update my testsuit
<ogra> yay, thanks a lot
<ogra> what was/is it ?
<ogra> it == the prob
<mvo_> ogra: the file/copy method do not take hashes (that is ok) but the acquire code does not calculate it if it does not get it from the method anymore, that is a bug (and that used to be there before)
<ogra> aha
<mvo_> ogra: the way hashes are taken is not pretty (its better now than it was before IMHO) and this is one of the breakage caused by no clear reposponsiblity
<pitti> mvo_: will that apt patch make me jump for joy (and from the balcony)?
<ogra> so d-i is not using the file method apparently which is why it works until i get in ltsp build mode ...
<mvo_> pitti: I hope not :(
* ogra quickly collects all pillows in the house and sends them off to "dresden below pitti's window" by express
<mvo_> pitti: I would not want to see you jump from the balcony
<mvo_> ogra: can you please try http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4_i386.deb (and friends)?
<mvo_> ogra: this bug kills your edubuntu CDs, right?
<mvo_> ogra: if the patch is good I need to clean it up a bit + add a test for this bug, but it should be ready failrly soon
<gutsytester> In Gutsy there is a barrier of 1px at the top of the panel where i can not click on "applications places..". Is that a bug?
<Ng> gutsytester: yes, bug 103306
<ubotu> Launchpad bug 103306 in compiz "compiz eats mouse clicks at the border of the screen" [Medium,Triaged]  https://launchpad.net/bugs/103306
<gutsytester> Ng, thank you
<gutsytester> are the new default directories in $HOME used by any programs? e.g. there are no templates at all by default
<Hobbsee> gutsytester: you may want #ubuntu+1
<gutsytester> Hobbsee, oh, sorry
<norsetto> is it intentional not to have libbluetooth2-dev in ubuntu?
<mjg59> norsetto: libbluetooth-dev
<norsetto> mjg59: exactly, so, its intentional?
<geser> yes, the the normal naming scheme
<cjwatson> norsetto: the same renaming happened in Debian
<norsetto> why do we have libbluetooth2 then!? In debian they have libbluetooth2-dev in stable
<cjwatson> bluez-libs (3.10-1) unstable; urgency=low
<cjwatson>   * New upstream release
<cjwatson>   * libbluetooth2-dev -> libbluetooth-dev transition to allow binNMUs
<cjwatson>  -- Filippo Giunchedi <filippo@debian.org>  Wed, 23 May 2007 22:13:52 +0200
<cjwatson> norsetto: -dev naming scheme isn't necessarily the same as runtime library naming scheme
<norsetto> ok thanks, just wanted to make sure before proposing a merge (which could have been a sync if not for this)
<cjwatson> it's not uncommon to drop the .so version from the -dev
<cjwatson> norsetto: you're confused; this has nothing to do with whether the package is syncable
<cjwatson> the change came from Debian
<geser> norsetto: the lib packages have to soname (you want different version to be coinstallable) but not the -dev one (usually you want to build against the latest version)
<cjwatson> for the remaining Ubuntu changes which need to be preserved, see recent changelog entries
<norsetto> cjwatson: no, I not confused; the debian package has two dependancies on libbluetooth2-dev, which I need to change
<norsetto> thanks for the help guys, you are wonderful :-)
<mjg59> norsetto: Only if it's a versioned depend
<mjg59> norsetto: It still provides: libbluetooth2-dev
<norsetto> mjg59: not following you now; what do you mean?
<cjwatson> nothing in Debian has any problematic dependencies on libbluetooth2-dev
<mjg59> norsetto: libbluetooth-dev provides: libbluetooth2-dev
<cjwatson> norsetto: look up virtual packages in Debian policy
<norsetto> the package is gnokii; so if what you say is correct I don't need to change the dependancy, and its just a sync?
<norsetto> I want to make sure, as we changed it already in the previous ubuntu version
<cjwatson> norsetto: indeed; that change was unnecessary
<norsetto> good!
<mjg59> norsetto: Unless the dependency is versioned, there is no need to change it
<cjwatson> norsetto: but if you are in doubt, you should check with the previous uploader
<cjwatson> (who's on holiday)
<norsetto> perfect guys; I hug you even more, i'll ask for a sync then
<cjwatson> it is true that it is more elegant not to rely on the provides
<norsetto> cjwatson: yeah, thats why I'm looking at it, he is back soon in any case
<bddebian> Heya
<_Nesshof_> I'm looking for gaps between the vanilla OpenOffice.org packaging and the packaging for ubuntu, is there anybody with some insight in this area ?
<asac> pitti: when can i expect first test isos for tribe-4 ?
<pitti> asac: help me pedal on palmer, so that OO.o builds faster :)
<asac> pitti: my test-system would deserve a reinstall .. so I would use that chance to test them :)
<pitti> asac: in about three to four hours, I hope
<doko> _Nesshof_: what do you mean by gaps?
<asac> ok that should be good enough
<pitti> asac: I'm craving for them more than you do, believe me :)
<asac> maybe i can order my dell laptop in the meantime :)
<norsetto> _Nesshof_: you can look at the changelog; all changes are listed there
<asac> hmm still broken dell.de/ubuntu
<_Nesshof_> what is the repository for the changes ? is there a special reposity for ubuntu used ?
<doko> _Nesshof_: Ubuntu uses ooo-build as a base, then adds it's own packaging modifications, best seen in debian/rules
<doko> I assume you know the ooo-build repository, do you?
<_Nesshof_> doko: yes
<_Nesshof_> so it is a three stage build process, using vanilla ooo, ooo-build and spec. ubuntu patches ?
<doko> ok, so you find the most recent other packaging details in the package itself (the .diff.gz is sufficient), see https://launchpad.net/ubuntu/+source/openoffice.org/2.3.0~src680m224-1ubuntu2
<asac> doko: i am just curious how large is the patchset that has accumulated over time for ooo?
<doko> asac: not more than 20MB compressed
<asac> the full diff.gz ... or just patches?
<doko> most of it are translations
<asac> ah ok
<doko> _Nesshof_: ubuntu specific patches are found in ooo-build as well
<mvo_> pitti: we have a update for libcompizconfig0 that fixes a nasty crash, it would be cool if that could go in too
<mvo_> ogra: any chance to test my patch ?
<ogra> mvo_, sorry, was downstairs for some food, testing now
<mvo_> ogra: no problem
<ogra> mvo_, what beyond apt do i need ?
<mikmor2> cjwatson: Good morning (for me).
<mvo_> ogra: some compiz firefighting in the meantime, looks like everything I'm involed with is borken currently
<mvo_> ogra: nothing I think
<ogra> hmm, then it doesnt work ... updated apt behaves the same in the chroot
<cjwatson> mikmor2: morning
<mvo_> ogra: ok, give me some minutes
<tkamppeter> pitti, ping
<vprints> Bug #129749
<ubotu> Launchpad bug 129749 in firefox ""Recently closed tabs" is always greyed-out" [Undecided,Confirmed]  https://launchpad.net/bugs/129749
<vprints> https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/117648
<ubotu> Launchpad bug 117648 in openoffice.org "[festy]  Writer crashes, document recovery attempt, after Insert->Indices and Tables->Bibliography" [High,Confirmed] 
<Hobbsee> vprints: and...?
<Hobbsee> vprints: and was it necessary to spam 2 channels with that?
<vprints> Hobbsee, spam ?
<Hobbsee> vprints: just dumping bugs into the development channel wont suddenly get them fixed, unless they're critical.  people dont just drop everything to fix a bug that someone mentions.  a bug tracker is for keeping track of bugs.
<vprints> Ok, sorry then
<Hobbsee> vprints: obviously, if everyone did that...it would get quite unruly
<stgraber> pitti: How's tribe-4 going, do we have anything to test yet, or when will we ? (I have some people asking in #ubuntu-iso)
<Hobbsee> stgraber: waiting on ooo again
<stgraber> ok, thanks
<geser> and ooo is still building
* ogra is afk ...
<LaserJock> anybody know where pitti keeps lang pack sizes?
<mvo_> ogra: could you please give this one a try? http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4_i386.deb
<geser> pitti: could there be a problem with the new pkgbinarymangler? xpdf ftbfs on powerpc and sparc with "pkgmaintainermangler: Error: Unable to locate DEBIAN/control"
<wasabi> Where did the Java 6 plugin package disapepar to?
<wasabi> sun-java6-plugin seems to be gone... but the changelog mentions nothing. =/
<geser> both build logs shows that pkgbinarymangler got updated to 40. i386, amd64 and i164 build successfully but the log doesn't mention that pkgbinarymangler got updated
<wasabi> Oh, i see. N/m.
<wasabi> 32 bit only. =.
<Mithrandir> geser: it affects other packages too, so I'd say yes.
<Mithrandir> pitti: ^^ moblin-image-creator ftbfs on i386 due to the same problem.
<LaserJock> Mithrandir: do you happen to know a decent way to guess who much space lang packs will take on the LiveCDs?
<LaserJock> *how
<Mithrandir> LaserJock: unsure; I think we guesstimate based on .deb size.
<LaserJock> Mithrandir: should they be roughly the same as .deb size?
<Mithrandir> not too far off, at least.
<Mithrandir> slightly smaller, I believe.
<LaserJock> k, that's good enough
<highvoltage> hmm.. perhaps it would be a good excercise for me to make a script that sums up the size of the langpacks
<cjwatson> highvoltage: pitti has one such already
<cjwatson> http://people.ubuntu.com/~pitti/scripts/langpacksize
<highvoltage> cjwatson: aah
<manchicken> I'm guessing someone already knows about the openoffice.org-core dependency issue?
<highvoltage> LaserJock: well, there you have it
<manchicken> Or, nevermind.  Hobbsee says I'm jumping the gun.
<LaserJock> cjwatson: thanks
<alex-weej> what package is strace in these days?
<alex-weej> hm, nm, seems i have it
<cjwatson> alex-weej: strace
<lamont`> alex-weej: usually it's in the source and binary packages 'strace'.
<lamont`> cjwatson: ^5
<alex-weej> Evolution is going apeshit with CPU
<alex-weej> in Gutsy
<alex-weej> anyone have any ideas?
<lamont`> alex-weej: still using mutt here...
<cjwatson> oh my, https://help.ubuntu.com/community/Ubuntu_OEM_Installer_Overview is out of date
<pitti> ! openoffice has built!!!
* pitti bounces
<Hobbsee> pitti: but will it publish and work?
<pitti> Hobbsee: let's find out :)
* pitti starts a publisher
<Hobbsee> :D
<pitti> ... as soon as my ssh to drescher actually continues to work
<pitti> running
<Hobbsee> hah.  let's hope yours works better than mine to the uni
<Hobbsee> Sun Microsystems Inc.   SunOS 5.10       Generic Jul 2006
<Hobbsee> interesting
<Hobbsee> pity my normal .bashrc doesnt work, though
<geser> pitti: luckily ooo started building before the buildds start using the broken pkgbinarymangler
<Hobbsee> pitti: good luck, i need to head to bed.
<geser> Hobbsee: you woke up again to see pitti bounce on the successful ooo build?
<mvo_> ogra: forget my last msg please
<pitti> mvo_: libcompizconfig> looking
<pitti> hi tkamppeter
<pitti> stgraber: OO.o is publishing, and apparently I need another cycle for compizconfig
<pitti> stgraber: ETA still 2 hours then
<pitti> geser: looking, infinity uploaded a new version recently
<geser> pitti: that's the one causing the problem
<pitti> seb128: is the gdm fix very important for the tribe?
<seb128> pitti: nothing I've uploaded is important for the tribe or I would have pinged you ;)
<pitti> seb128: ok, thanks; just checking
<seb128> you're welcome
<stgraber> pitti: ok, that's fine, let's hope they will be correctly working as we don't have much time ...
<mvo_> pitti: there is also ogra apt problem pending .. :(
<pitti> mvo_: yeah, but that can go in a bit later, while the ubuntu/kubuntu/xubuntu CDs are already building
<mvo_> pitti: aha, ok
<iwj> Are there any tribe 4 images for testing yet ?
<pitti> iwj: working very hard to get some ASAP
<iwj> IC  OK
<pitti> iwj: OO.o spoiled the show this time :/
<iwj> Fair enough.  So testing is postponed ?
<iwj> Sounds very annoying.  Any way I can help ?
<pitti> iwj: not any more; OO.o just built (after the second attempt), now it's being published
<iwj> OK
<pitti> iwj: once that happened, testing the OO.o upgrade and install would be *very* appreciated
<tkamppeter> hi pitti, it seems that your AppArmor changes in the startup scripts for CUPS have caused bug 131065.
<ubotu> Launchpad bug 131065 in cupsys "[Gutsy]  cupsys fails to upgrade" [Undecided,New]  https://launchpad.net/bugs/131065
<iwj> pitti: Sure.
<pitti> tkamppeter: later, please
<mathiaz> tkamppeter: the bug report lacks more information.
<pitti> oh *headdesk*, I see the pkgmaintainermangler problem
<ogra> mvo_, to me it looks like apt ignores the .gz files completely while it processes the Packages files
<calc> pitti: appears i386 failed at the very end of the build when it couldn't find one of the files it generated :(
<pitti> calc: yeah, we noticed; doko did a quickfix and it's built now and being published
<calc> pitti: cool, what was the problem with it?
<pitti> calc: details later, currently working under pressure, sorry
<calc> pitti: ok no problem
<doko> calc: didn't investigate yet, you can reproduce it by installing the binary mangler
<calc> doko: oh ok
<pitti> doko: it should be fixed with the new pkgbinarymangler
<pitti> doko: pkgstriptranslations stumbled over the bzip2 argument of dpkg-deb
<pitti> doko: that was the reason why it didn't output anything for dh_builddeb -i
<pitti> doko: it only checked $1 for -b
<pitti> Mithrandir, geser: fix uploaded, I'll beat it through the buildds and give back your packages later
<doko> calc: ok, so you can remove my workaround; couldn't check it in, the repo is out of date ;)
<calc> doko: ok
<pitti> doko: no, please don't check it in
<pitti> calc: your package should actually build fine the next time
<calc> pitti: thats what he just said :)
<pitti> yeah, sorry
<calc> pitti: np you are stressed to the max :)
<calc> pitti: \o/
* pitti is happy that he learned how to build from accepted today, to speed things up
<pitti> oh, crap, no, that doesn't work
<pitti> openoffice.org | 2.3.0~src680m224-1ubuntu2 |         gutsy | source, amd64, i386
<pitti> calc, iwj, anyone: ^ please give this an upgrade/install/quick functinoality test
<hunger> pitti: aptitude does not like it here... conflicts with something.
<pitti> hunger: --verbose, please?
<pitti> hunger: here too, indices are not yet up to date
<pitti> hunger: it seems that archive.u.c. still needs to catch up or so (publisher ended some three minutes ago)
<hunger> pitti: OK, I'll recheck once it is updated.
<calc> pitti: has it been pushed on the mirrors yet, i don't see it yet?
<hunger> pitti: It is installable after another update.
<pitti> calc: it just started to work here
<pitti> dist-upgrade running
<pitti> calc: wow, 22,1 additional MB after upgrade
<pitti> calc: let's hope those compress well etc.
<ogra> *shudder*
<calc> pitti: the compressed size was the same wasn't it (or within a MB or two?)
<pitti> ogra: I did a thorough deb size comparison this morning, and it shouldn't actually be too bad
<pitti> unless it pulls in many more dependencies
<calc> pitti: i don't think it should, probably less right now since some stuff is disabled due to being broken
<mvo_> ogra: http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4_i386.deb <- that one if fine for me, please give it a go. but I'm confident in it :)
<calc> i have a few MIRs i need to do to reduce the diff.gz size
<pitti> mvo_: can you please put a diff somewhere?
<pitti> ogra: I'll build a throwaway alternate here to see how it explodes
<ogra> mvo_,
<ogra> Failed to fetch file:///cdrom/dists/gutsy/main/binary-i386/Packages.gz  Hash Sum mismatch
<ogra> Failed to fetch file:///cdrom/dists/gutsy/restricted/binary-i386/Packages.gz  Hash Sum mismatch
<ogra> Reading package lists... Done
<ogra> E: Some index files failed to download, they have been ignored, or old ones used instead.
<ogra> root@laptop:/#
<ogra> :(
<geser> pitti: about the pkgmaintainermangler problem: is changing line 27 in the dpkg-deb wrapper from '/usr/bin/pkgmaintainermangler "$@"' to '/usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS' the right fix?
<pitti> geser: right, that's what I did and uploaded
<pitti> geser: I tested with Mithrandir's moblin-image-creator, worked
<ogra> pitti, size wise i'm more worried about live ...
<geser> me too :)
<pitti> calc: right, I still get the hang here, without -gtk
<pitti> geser: I wonder what keeps pkgbinarymangler from FTBFSing, though
<mvo_> ogra: and that is the latest one? no proxies playing tricks with you?
<calc> pitti: Riddell was able to find a bug report about the same issue on konqueror nspluginviewer on novell bugzilla, and i reduced the hang to which library has to be installed to cause it not to hang as well
<ogra> mvo_, used wget ...
<calc> /usr/lib/openoffice/program/libvclplug_gtk680li.so
<geser> pitti: hopefully not the broken pkgmaintainermangler on the builds
<pitti> geser: that's what I think, though
<pitti> geser: however, I can work around it
<alex-weej> someone please tell me that Compiz isn't on by default in Gutsy
<Amaranth> alex-weej: it's on by default in gutsy
<Amaranth> why?
<alex-weej> it's horrible
<Amaranth> ?
<alex-weej> the genie minimise effect is pretty sickening
<Amaranth> right, that's a bug
<alex-weej> no
<alex-weej> it's a patent issue
<Amaranth> no, it's a bug
<alex-weej> ok
<Amaranth> upstream at one time agreed with us on defaults
<ogra> mvo_, \o/
<ogra> root@laptop:/# apt-get update
<ogra> Ign file: gutsy/main Translation-de
<ogra> Ign file: gutsy/restricted Translation-de
<ogra> Hole:1 file: gutsy Release.gpg [189B] 
<ogra> Hole:2 file: gutsy Release [1877B] 
<ogra> Ign file: gutsy/main Packages
<Amaranth> they changed them, we need to go back to the zoom animation
<ogra> Ign file: gutsy/restricted Packages
<ogra> Paketlisten werden gelesen... Fertig
<ogra> root@laptop:/#
<mvo_> ogra: oh, nice :) can you (just to be sure) rm /var/lib/apt/lists/*
<mvo_> ogra: and see if it still works?
<Amaranth> alex-weej: don't judge the whole thing on the minimize animation :)
<ogra> mvo_, i had to to make it work at all
<Amaranth> alex-weej: and it's only a patent issue if it doesn't wave :)
<alex-weej> Amaranth: i have a good set of bugs on Launchpad that drive me up the wall about compiz
<iwj> pitti: re oo.o -1ubuntu2> willdo.
<mvo_> ogra: oh? does that mean that subsequent apt-get update errors?
<ogra> mvo_, it didnt just fix itself ....
<pitti> calc, iwj: all the apps start for me with -gtk installed
<ogra> i had to remove the file
<mvo_> ogra: it did or it "did not"?
<alex-weej> we need to change the wording in the Appearance capplet. "No effects", "Normal effects" and "Extra effects" is very misleading. The fact of the matter is that this changes the Window manager, and currently affects a LOT more than just appearance.
<calc> pitti: ok :)
<ogra> mvo_, didn't
<ogra> (not)
<mvo_> hmm ...
<mvo_> strange
<Amaranth> alex-weej: no, it changes one or two of your pet behaviors
<ogra> but it works at least
<alex-weej> Amaranth: like being able to use 3D apps?
<Amaranth> alex-weej: give me an example bug report
<calc> alex-weej: does compiz still not snap to borders like metacity?
<mvo_> pitti: http://people.ubuntu.com/~mvo/apt/apt_0.7.6ubuntu4.debdiff
<Amaranth> alex-weej: i'd have to have hardware that triggers that to figure out the problm
<Amaranth> alex-weej: nvidia?
<ogra> mvo_, for the current case thats fine
<alex-weej> Amaranth: anything that ISN'T Nvidia, apparently.
<alex-weej> Amaranth: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/96991
<ubotu> Launchpad bug 96991 in xserver-xorg-video-ati "3D stuff breaks with Compiz" [Undecided,New] 
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/91780
<Amaranth> alex-weej: i know that's not true, mvo_ has ati :)
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/91783
<ubotu> Launchpad bug 91780 in compiz "Compiz's corner resize grabbers are difficult to get hold of" [Wishlist,New] 
<ubotu> Launchpad bug 91783 in compiz "Compiz's default Human-glass look does not "work" visually" [Wishlist,New] 
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/91784
<ubotu> Launchpad bug 91784 in compiz "Compiz's "show desktop" functionality differs to Metacity's" [Wishlist,Confirmed] 
<Amaranth> !pastebin | alex-weej
<ubotu> alex-weej: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<ogra> debdiff shouldd have a --ignore-po-files switch
<Amaranth> alex-weej: wishlist bugs
<alex-weej> Amaranth: subjective.
<alex-weej> i don't see why a user should be faced with differing behaviour of a show desktop button just because they "changed the appearance"
<alex-weej> it's a usability issue
* calc luckily can't use it anyway due to having dual head
<Amaranth> alex-weej: i like compiz's better :)
<alex-weej> Amaranth: then make metacity's the same
<Amaranth> metacity's behavior has always annoyed me
<Amaranth> alex-weej: that i don't have control over
<alex-weej> Amaranth: then tell the truth in the capplet. Make it a "change window manager" setting instead
<alex-weej> the fact of the matter is it doesn't change some kind of abstract "enable 3D effects" setting, it changes the window manager
<alex-weej> and only the window manager
<Amaranth> which changes the behavior of a few small things
<Amaranth> it mostly works the same
<alex-weej> in any event the wording needs changing anyway. there's no info on what exactly "extra effects" does
<calc> what does using 3d all the time do to laptop battery life, anyone tested that part yet?
<Seveas> calc, bad things :)
<Amaranth> alex-weej: that's just an incomplete implementation
<Amaranth> calc: on my system it has basically no effect
<Amaranth> but that's because nvidia power management sucks
<calc> so thats another argument to have it disabled by default then
<Seveas> yours is draining battery no matter what
<alex-weej> and the use of radio buttons to do something as scary as changing the window manager (watch the screen blank and flicker as you change it) blows a bit. we use an apply button in the randr capplet for that.
<Seveas> on my intel it's significant
<Amaranth> it's a toggle button ;)
<Amaranth> and it's mostly for turning it off now
<iwj> My local mirror is absolutely chocker with oo.o versions.
<calc> but somewhere normal users probably won't see it
<alex-weej> Amaranth: of course, i'd love to get in and change the code and play about, but unfortunately i haven't quite figured out how to get into ubuntu yet.
<calc> unless it is in the installer also
<calc> upgrading from feisty -> gutsy and losing a lot battery life isn't exactly a nice thing to do to users
<pitti> mvo_: ok, get it uploaded please
<Amaranth> calc: they won't get compiz by default
<mjg59> But they get bling
<Amaranth> only new installs
<calc> Amaranth: oh ok
<mvo_> pitti: coming
<Amaranth> that's how it's supposed to work anyway
<calc> mjg59: and less features apparently
* calc knows how to turn it off so won't be using it
<AlinuxOS> pitti, good evening, so it's ok for Arne, https://bugs.launchpad.net/ubuntu/+source/ttf-dejavu/+bug/123404
<ubotu> Launchpad bug 123404 in language-pack-ka "language-pack-ka & and it's font dependency (ttf-bpg-georgian-fonts)" [Undecided,In progress] 
<ogra> pitti, \o/
<ogra> thanks !
* calc has to have snap-to, that was one of the reasons i didn't convert back to gnome at all for a while, until i found out how to do it
<Amaranth> calc:  we have that
<hunger> pitti: ooo installed fine
<pitti> ogra: wow, throwaway alternates are not oversized at all \o/
<calc> Amaranth: was it buggy before, istr it not working exactly right
<calc> Amaranth: maybe something to do with wobbly windows though
<Amaranth> calc: we have snap without wobbly
<calc> Amaranth: i can't test it on my desktop though since compiz doesn't work on it
<calc> Amaranth: great :)
<Amaranth> calc: doesn't work exactly like metacity but pretty close
<ogra> pitti, alternate is fine for me since feisty i have plenty of space to move stuff to ... LaserJock and me are just fighting with the liveCD
<pitti> ogra: building throwaway live now, to check
<ogra> ah, i'll wait for these and hope foir a miracle
<geser> pitti: upgraded ooo on amd64 without problems and it still starts
<iwj> calc: Is oo.o supposed to save things in Documents rather than Desktop by default ?  That seems wrong to me.  (Still on 2.2.1-5ubuntu3; 2.3.0~src680m224-1ubuntu is downloading)
<pitti> geser: yay, here too
* pitti hugs calc, good job!
<calc> iwj: it tries to save to the user dir for me, must be a setting somewhere if it is different for you
<iwj> I'm sure I haven't set any such setting.
<iwj> I just typed `ooffice' at a shell prompt, new text document, type some text, save as and enter `foobar' as the filename.
<pitti> iwj: that might be if you have -gnome installed? some gnome file dialog might respect the xdg-user-dirs
<iwj> I have ubuntu-desktop installed.
<pitti> iwj: yeah, that should give you openoffice.org-gnome
<calc> oh yea i don't have -gnome installed right now
<pitti> mvo_: I don't want to hurry you, but I need apt now
<mvo_> pitti: its uploaded
<pitti> @all: can I ask some of you guys to do a nightshift with me for ISO testing?
* pitti hugs mvo_, thanks
* mvo_ hugs pitti back
<ogra> mvo_, that was awesome, many many thanks !
<bdmurray> pitti: I could help but it won't be night for me. ;)
<pitti> if anyone feels like it, the 20070808 ubuntu alternate should actually work; it's not supposed to be perfect (missing libcompizconfig and apt), but it should do
<pitti> bdmurray: so much the better :)
<calc> iwj: yea with -gnome it defaults to Documents the new document location for gnome 2.19/2.20
<pitti> calc: that sounds right to me, though
<calc> pitti: yea that's a feature not a bug
<iwj> Seems like a way to let people lose their files to me :-).  But if you know about it that's fine, I'm not going to argue.
<calc> without -gnome it defaults to your user dir not Desktop, which is probably what it defaulted to before gnome 2.19
<bdmurray> maybe release noting it would be a good idea
<calc> er i meant to say with -gnome installed prior to 2.19 it probably defaulted to Desktop
<calc> gnome 2.19 added a lot of other dirs to the user dir
<calc> documents/music/pictures/public/templates/videos
<mathiaz> pitti: I can help doing some isotesting.
<calc> btw is it a bug that documents and desktop appear twice in places menu?
<calc> it looks like a bug in any case
<bdmurray> calc: yes, it is known
<calc> bdmurray: ok
<pitti> mathiaz: that would be great
<pitti> calc: there's an existing bug about tit
<mathiaz> pitti: I'm already testing the server cd.
<pitti> it, even
<mathiaz> pitti: let me know what else I should test.
<pitti> mathiaz: appreciated (just in case you find something truly weird), although it's not the candidate yet
<iwj> pitti: I'm downloading the 20070808/gutsy-alternate-i386.iso now but it'll be a while.
<iwj> Err, depending.
<pitti> iwj: jigdo FTW :)
<mathiaz> pitti: I'm testing the isos from yesterday (20070807) as there is none as of today.
<iwj> My network was down so my rsync is less primed than it ought to be.
<pitti> mathiaz: right, no final images yet
<ijuz> many end users will still have the problem that per default the live cd doesn't load the ide-gerneric module
<iwj> pitti: I have a file overwrite problem with oo.o 2.3.0~src680m224-1ubuntu2
<mathiaz> pitti: ok. I'll wait for the final images then and test the server images.
<ogra> pitti, to fix the liveCd issues on edubuntu we'd need a dep change in gcompris, is that ok ?
<iwj>  trying to overwrite `/usr/lib/openoffice/program/gconfbe1.uno.so', which is also in package openoffice.org-gtk
<pitti> iwj: downloading it now will make the final candidate CD download much faster, too
<pitti> iwj: erk
<pitti> iwj: that has to be fixed post-tribe, I'm afraid
<stgraber> pitti: Can you add isos on the tracker when they are uploaded or do you prefer pinging me ?
<ogra> pitti, moving tuxpaint to a gcopmpris recommends to be able to drop it from the live session
<pitti> stgraber: I think I can
<iwj> I'm doing  dpkg -iOB  though not apt here.
<pitti> ogra: ok, please get it uploaded; that will delay your CDs slightly
<ogra> slightly is fine :)
<pitti> ogra: but that's ok, I can interleave it with the other iso builds and build edubuntu last
<stgraber> pitti: are you also going to send a mail to testers (Send mail option in the admin ui) or shall I ? (would also be great to ask people wanting to test to join #ubuntu-iso so we can coordinate a bit for faster testing)
<pitti> stgraber: yes, I'll do that once we have candidate CDs
<pitti> stgraber: will you be around for a while in case of problems?
<stgraber> sure
<ogra> do live changes still need a meta rebuild ?
<pitti> ogra: a publisher run
<ogra> ok
<pitti> ogra: please tell me when you changed something (publisher is currently running, so you have time0
<ogra> edubuntu live seed is updated, but needs the gcompris fix to produce something unsable
<pitti> ogra: ok, that's fine
<ogra> LaserJock is on gcompris ...
<pitti> ogra: when this publisher run is over, I'll start a new one for the fixed pkgbinarymangler
<ogra> heh
<pitti> that should update it
<ogra> s/unsable/usable/ :)
<LaserJock> pitti: ok, I've just dput new gcompris
* pitti testinstalls ubutnu alternate 20070808
<iwj>  openoffice.org-l10n-en-gb conflicts with openoffice.org-core (<< 2.3.0~src680m224)
<iwj>  openoffice.org-l10n-en-gb conflicts with openoffice.org-core (>= 2.3)
<iwj> Ie upgrade is prohibited by the dependencies.  Thank apt.
* iwj uses --force-conflicts.
<pitti> iwj: uh?
<pitti> iwj: that looks seriously broken
<iwj> It's very common nowadays.
<iwj> No-one notices because apt either forces it or removes something for a bit and then puts it back later.
<pitti> iwj: ooh, I misread
<pitti> Conflicts: openoffice.org-core (<< 2.3.0~src680m224), openoffice.org-core (>= 2.3.0~src680m224.1)
<pitti> that's better and should at least install from scratch
<pitti> iwj: if you see upgrade issues, please file a tribe-5 bug against OO, those are for calc
<pitti> iwj: I'm afraid we are out of time to fix them for tribe4
<iwj> Yes, I will, but only if I reproduce them with apt.
<iwj> Indeed.
<lamont`> pitti: I have a util-linux upload that I want to do right after tribe 4.  would you like me to upload that now and you just not approve it, or shall I wait until tribe 4 hits the street?
<pitti> lamont`: go ahead and upload, that's fine
<lamont`> pitti: tahnks
* lamont` is curious - does the source get defacto-embargoed (by not being published), or is it the building that gets blocked?
* lamont` guesses the former
<pitti> lamont`: right, the former
<lamont`> pitti: util-linux 2.13, aka util-linux-ng, btw
<pitti> lamont`: binaries go straight to accepted
<lamont`> ah - that makes it make even more sense
<lamont`> (doh)
<pitti> lamont`: latest LP actually shows the queues, though (unapproved, new, etc.)
<lamont`> oh, nice
<pitti> https://launchpad.net/ubuntu/gutsy/+queue
<pitti> hey, who approved qt4-x11?
<pitti> thank goodness, pkgbinarymangler built now
<LaserJock> pitti: did you approve gcompris?
<geser> pitti: will you automatically give-back all FTBFS caused by it?
<pitti> geser: not all, just the ones that come to my attentino
<seb128> pitti: there is no dbgsym created for new uploads now then?
<lamont`> pitti: uploaded util-linux, if it goes into tribe 4, it's your fault. :-)
<pitti> seb128: why not?
<lamont`> mind you, it should work.
<seb128> pitti: "Build with NO_PKG_MANGLE", I'm just asking what it means ;)
<pitti> seb128: building pkgbinarymangler *itself* without pkgbinarymangler active
<seb128> ah, ok
<pitti> seb128: since otherwise I could not build the fixed version which makes packages not FTBFS any more
<pitti> yay recursive dependencies
<geser> pitti: is xpdf (sparc and powerpc) on your give-back list already?
<pitti> geser: yep
<pitti> LaserJock: yes
<pitti> http://cdimage.ubuntu.com/daily-live/20070808/ for interested testers (not the final candidates, just an intermediate release)
<pitti> ogra: ^ those were the throwaway builds for size checking; they are quite small
<pitti> ogra: OTOH I removed all langpacks just in case
* pitti adds them again
<ScottK> mvo_: Thank you for the apt fix (just got the bugmail) and being open to taking another look at it.
<LaserJock> pitti: heh, we just took ours out to be like the cool kids over in Ubuntu ;-)
* lamont` wishes more packages use -j in their make invocations
<pitti> dendrobates: do you know anyone who could test the sparc server ISOs?
<mvo_> pitti: hm, http://launchpadlibrarian.net/8738516/buildlog_ubuntu-gutsy-i386.apt_0.7.6ubuntu4_FAILEDTOBUILD.txt.gz
<mvo_> pkgmaintainermangler: Error: Unable to locate DEBIAN/control
<mvo_> dh_builddeb: command returned error code 256
<mvo_> is that known?
<pitti> mvo_: yeah, I know, I need to publish the fixed pkgbinarymangler
<mvo_> aha, ok
* mvo_ hugs pitti
<pitti> mvo_: yeah; we managed to break all builds :/
<pitti> including the fixed pkgbinarymangler, of course :)
<mvo_> pitti: looks like this tribe is even worse than tribe-2 :/
<mvo_> pitti: heh :)
<pitti> mvo_: it's on my radar, I'll give it back as soon as 42 is in the archive
<pitti> in about 50 minutes
* pitti wants the publisher to go faster
<mvo_> pitti: no worries
<pitti> mathiaz, dendrobates, kees: http://cdimage.ubuntu.com/ubuntu-server/daily/20070808/ -> tribe4 server ISO candidates
<mathiaz> pitti: ok. is isotesting setup correctly ?
<mathiaz> pitti: I mean the iso testing tracker
<pitti> mathiaz: not yet, will do now
<pitti> stgraber: ok, so how do I add the first iso to the tracker?
<stgraber> pitti: same way as you'd do for updated isos
<pitti> stgraber: ah, just found it
<stgraber> pitti: go to /addbuild, tick them, set version number and Add
* pitti <- slightly blind
<pitti> mathiaz: added server CD to iso tester
* ..[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 | Main frozen for Tribe 4 | Please test ISOs: https://iso.qa.stgraber.org/isotesting/, see #ubuntu-iso
<mathiaz> pitti: excellent. Thanks. I'll start testing the server isos.
* #ubuntu-devel  [freenode-info]  if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
* pitti adds some incoming alternate CDs
(bryce/#ubuntu-devel) tepsipakki: there is a .diff.gz attached to the comment by Paul Drain on 2006-09-17; I assumed it was a patch but haven't looked at it
(iwj/#ubuntu-devel) pitti: g-a-i died when I tried to play a media file from Examples/.
(stgraber/#ubuntu-devel) pitti: we'll see how my small dedicated server handle that spam :) (only 256MB of ram for pgsql+mysql+apache+postfix+spam-assassin+courier+asterisk+openvpn)
<tepsipakki> bryce: a ~200kb diff comparing the dapper ati-driver to upstream CVS :)
<pitti> iwj: *sigh*
<tepsipakki> or something like that
<bryce> bleah.  ok nevermind :-)
<pitti> iwj: at least not a blocker
<pitti> wb ogra
<stgraber> pitti: 3 greylisted, 1 blacklisted, 1 temporary failure, all the others have been sent successfully
<Kopfgeldjaeger> hehe, will the universe-azureus ever work? :d
<iwj> pitti: bug 131177 for the g-a-i crash
<ubotu> Launchpad bug 131177 in gnome-app-install "gnome-app-install crashed with NameError in preRun()" [Undecided,New]  https://launchpad.net/bugs/131177
<iwj> Strange, because LP offered me a potential dupe which was Fix Released 3 days ago ...
<stgraber> pitti: Any idea when Edubuntu server will be ready ? (== Can I start testing something else ?)
<pitti> stgraber: about 5 minutes, I'd say
<stgraber> ok, so I'll wait for it
<Kopfgeldjaeger> does the bcm43xx driver (installed with restricted-manager) work for anybody?
<iwj> Has someone actually decided to include the search applet in the top right of the desktop and chosen the right searches to use ?
<pitti> Kopfgeldjaeger: last time I checked (on my iBook), it did
<pitti> iwj: 'that': yes; 'searches:' rather not
<stgraber> Kopfgeldjaeger: works on a Powerbook G3 here
<pitti> iwj: it doesn't have tracker enabled by default?
<Kopfgeldjaeger> pitti: ok. then ill have to check it on my notebook (well, in case its my brother's) again... and remove ndiswrapper again... and cry again :'(  *g
<iwj> A tracker ?
<iwj> You mean it phones home somewhere ?
<pitti> iwj: the desktop search
<ijuz> bcm43xx may be a thing of... luck
<iwj> It doesn't seem to be offering to search my desktop.  It lists Amazon, answers.com, CC, eBay, Google, Ubuntu package search, Wikipedia and Yahoo.
<ijuz> (never worked for me really, i replaced it with a intel wlan card)
<pitti> iwj: right, you need to explicitly enable the tracker plugin; that should have happened by default
<pitti> seb128: ^
<iwj> Should it ?
<iwj> By `tracker plugin' do you mean it phones home ?
<pitti> iwj: apt-cache show tracker
<pitti> iwj: no, it's just the name of the tool that indexes your ~ and provides fast search
<iwj> OIC
<pitti> iwj: no remote homecalling :)
<iwj> Good :-).
<iwj> Just checking.  Sometimes upstreams do crazy things and they slip through ...
<pitti> iwj: but since we enable tracker by default now, it makes kind of sense to use it in the deskbar applet
<seb128> pitti: right, deskbar-applet doesn't make it easy to enable plugin automatically
<Kopfgeldjaeger> just 	out of curiosity: does the ipw4965 driver support monitor mode?
<seb128> pitti: I'll try to change the deskbar schemas to list the extra plugin, that should work if it's installed
<pitti> seb128: merci, Monsieur
<seb128> de rien ;)
<pitti> seb128: too late for the tribe, though, and not a blocker
<seb128> right, that's why I didn't bother doing it today
<pitti> ogra, LaserJock, stgraber: http://cdimage.ubuntu.com/edubuntu/daily/20070808/
<stgraber> pitti: great, just found my DVD+RW
<iwj> pitti: bug 131182 for my complaints about this search feature (which are separate to the lack of the tracker)
<ubotu> Launchpad bug 131182 in gnome-panel "search applet has inconsidered list of searches" [Undecided,New]  https://launchpad.net/bugs/131182
<iwj> pitti: Should I milestone it for beta ?
<pitti> LongPointyStick, Riddell, ScottK: kubuntu alternates up
<pitti> iwj: tribe 5 would be appropriate, seb128 just said that it shouldn't be too hard
<iwj> OK.  Should I file a separate bug about the lack of tracker ?
<coNP> seb128: what is the problem with enabling plugins in deskbar?
<pitti> iwj: I think 131182 is fine
<iwj> OK
<pitti> iwj: since tracker plugin is just one particular case of that (judging by the title)
<seb128> coNP: there is no enable key, the enable plugins is a list, and there is no way for an another package to append things to schemas, they are only defaults you can set
<mjg59> Amaranth: Ah. Textured video doesn't work with XAA and compositing.
<coNP> seb128: does this hold for the new version as well?
<seb128> coNP: ?
<mjg59> So we either need to switch to EXA (risky at this point in the cycle) or disable compiz on Intel
<seb128> coNP: yes, 2.19.6.1 still has a list for this key
<coNP> Okay I guess I don't completely understand the problem. :)
<seb128> coNP: what is not clear?
<seb128> coNP: there is key = <lists>
<Amaranth> mjg59: as so we're back to XAA sucking and EXA sucking more :/
<pitti> coNP: e. g. we want to enable the deskbar tracker plugin by default, since we enable tracker itself by default
<Amaranth> mjg59: basically we're ending up with compiz only on nvidia
<seb128> coNP: the deskbar schemas set a default list
<mjg59> Amaranth: Yes
<pitti> coNP: oh, you know that already, ignore me
<Amaranth> mjg59: and nvidia's drivers are rather shaky right now
<coNP> pitti, seb128 yes
<seb128> coNP: tracker has a plugin for deskbar, it needs to be added to this list to be enabled
<Amaranth> mjg59: we've got a choice between leaving out all the 8xxx cards or having broken drivers for everyone else
<seb128> coNP: or there is no append to a schemas option in gconf
<seb128> you set a default value and that's about it
<mjg59> Amaranth: I'm going to recommend that we bail on compiz by default
<coNP> seb128: Okay. Thanks. Now I understand this :)
<mjg59> The technology isn't ready yet
<Amaranth> mjg59: I already said the same thing
<Amaranth> We'll keep working on making it better on our end, hopefully the drivers will catch up
<Amaranth> And maybe I should spend some time on libwnck again :)
<seb128> Amaranth: could you try to get the workspaces switching shortcurts working? ;)
<Amaranth> seb128: hehe
<Kopfgeldjaeger> can i include a script into a deb file, the script should start automatically when installing the .deb file
<Amaranth> Yay I've got a convert :)
<pitti> gpocentek: Xubuntu alternates ready
<pitti> crap, ubuntu amd64 live oversized
<iwj> pitti: FYI 20070808 seems not to have any showstoppers for me unless you think the Places menu is one.  I think it's pretty visible, personally.
<iwj> But it's not the beta so let it slide :-).
<pitti> iwj: right; I'm afraid we cannot afford to fix this properly at this stage
<iwj> I'll try out 20070808.1 too.  What changes should I concentrate on ?
<pitti> iwj: fix in compiz crasher mainly; this also has a new apt, but that should behave
<iwj> I didn't see the compiz crasher personally.
<iwj> Or at least not just now :-).
<pitti> iwj: oh, and f-spot shouldn't crash any more if you close it (but that shuold be fixed on 20070808 already)
<pitti> iwj: 20070808.1 is oversized on amd64, I have to adjust and rebuild; new image just differs by the absence of German langpacks, so this could be tested already
<Amaranth> *boggle*
<Amaranth> did mvo's original libcompizconfig upload today break?
<Amaranth> oh, that breakage
<sistpoty> hi folks
<pitti> hi sistpoty
<sistpoty> hi pitti
<ajmitch> hey sistpoty
* Starting logfile irclogs/ubuntu-devel.log
<LaserJock> pitti: Edubuntu Desktop up?
<pitti> LaserJock: no, not yet; see iso tracker
<pitti> LaserJock: server is there, though
<LaserJock> pitti: great
<pitti> LaserJock: kubuntu desktop is ready in ~ 10 minutes, edubuntu in ~ 50 minutes
<LaserJock> pitti: excellent thanks
<mathiaz> is it normal that universe is enabled by default on server installs ?
<pitti> wow, that's the first time that rescue mode doesn't hang after exiting from the rescue shell; thanks cjwatson_!
<mikmor2> cjwatson: hello
<mikmor2> cjwatson: Are there any directories shared between ubiquity's target and the live FS during target-config?
<RAOF> Amaranth: Surely we can upgrade nvidia-glx-new to the 100 series, and suggest everyone without a 8x00 series card uses the nvidia-glx drivers?
<Amaranth> RAOF: "But it says -new, it must be better! Why is my system locking up all the time?"
<pitti> Riddell, LongPointyStick, ScottK: kubuntu desktop ready for testing
<RAOF> Amaranth: :(
<sistpoty> RAOF: iirc debian uses different source packages for each driver series, would that be an approach for ubuntu as well? (/me is affected, so I'm asking *g*)
<Amaranth> yeah, nvidia puts the driver version in the package name
<Riddell> thanks pitti
<pitti> sistpoty: in fact, the -legacy and -new was a hack of our's I think
<Amaranth> err
<pitti> sistpoty: and I seriously hope that we can unify it again
<Amaranth> s/nvidia/debian/
<sistpoty> pitti: ah, k
<Amaranth> need more caffeine
<pitti> BenC: do you think that's realistic? ^
<mjg59> RAOF: Because every time we try to provide older drivers to people, they cry
<BenC> pitti: what's that?
* sistpoty tried to start getting the newer driver in once, but unfortunately I was hit by -ENOTIME
<pitti> BenC: unifying nvidia-glx-*, as we discussed quickly before feisty
<mjg59> (See us carrying three nvidia packages, when we only actually need two to support the same range of hardware)
<pitti> BenC: i. e. selecting the right module on boot, based on our modalias maps
<pitti> BenC: otherwise upgrade issues will only get worse in the future, I'm afraid
<BenC> pitti: we already do that
<sistpoty> mjg59: is that true? I thought there were regressions with the newer driver as well
<sistpoty> s/driver/drivers/
<pitti> BenC: oh?
<BenC> pitti: problem is we can't install all of the userspace packages at once (the xorg/GL parts)
<ajmitch> hello jono
<pitti> BenC: yeah, that was the alternatives approach or so, right?
<jono> hey ajmitch
<BenC> pitti: right, and quite complex an approach it would be
<pitti> BenC: s/bootup/package install, probably/
<BenC> pitti: restricted-manager would be responsible for the update-alternatives invocation...but the complex part is that there are lots of differing files in each package that overlap
<BenC> pitti: it scares me a lot :)
<pitti> BenC: hm, not sure whether calling r-m on upgrades would work
<pitti> BenC: me too, but with the current structure we only aggravated the upgrade problem
<BenC> pitti: it could also be put into lrm init script
<mjg59> sistpoty: ? I meant that last time around, we could just have dropped people back to the old legacy package
<mjg59> But they wanted the latest drivers that supported their hardware, even if that meant an extra package
<wasabi> Wonder if anybody is ever going to make GL go through an intermediate libGL layer.
<wasabi> Like MS did... in 98.
<sistpoty> mjg59: I'm not quite sure if it's that easy, as newer driver for old HW solved some issues (though that is only my impression and I don't know the real facts :P)
<mathiaz> dendrobates: when testing the LAMP case, you'll get a '404 not found' when connecting the server.
<mathiaz> dendrobates: it's already been report as bug 130625
<ubotu> Launchpad bug 130625 in apache2 "Empty /etc/apache2/sites-enabled - Apache's default site not enabled on install" [Unknown,Fix committed]  https://launchpad.net/bugs/130625
<dendrobates> mathiaz:I'm doing that now
<pitti> mathiaz: eek
<pitti> mathiaz: who can I assing this to?
<mathiaz> pitti: assign what ? the universe/mutliverse by default ?
<pitti> mathiaz: apache bug above
<mathiaz> pitti: the apache bug has already been fixed in debian
<mathiaz> pitti: I've filled a sync request this morning.
<pitti> mathiaz: oh, we can sync? can you please mark this as a dup of the sync bug then?
<pitti> dendrobates: do you think this is serious enough to get fixed for tribe4?
<mathiaz> pitti: ok. Is this the standard way to do it ?
#ubuntu-devel 2007-08-09
<pitti> mathiaz: I've seen it before, and it makes sense to me at least
<pitti> mathiaz: I'll sync it right now then, just in case
<Riddell> pitti: is the pkgmaintainermangler error fixed?
<pitti> Riddell: yep
<pitti> Riddell: I gave back and rebuilt the important stuff for CDs
<mjg59> seb128: There's something up with epiphany. When I close a tab, it doesn't kill the running plugins
<pitti> but there is certainly some fallout from this
<mjg59> Firefox is fine
<Riddell> pitti: could you give back adept too (for fixed --dist-upgrade)
<dendrobates> pitti: I don't want to hold up tribe 4 for it.
<seb128> mjg59: bug #125209
<ubotu> Launchpad bug 125209 in epiphany-browser "Flash video in Epiphany doesn't die when browser is closed" [Low,Confirmed]  https://launchpad.net/bugs/125209
<pitti> Riddell: done
<Riddell> thanks
<mjg59> seb128: Ah, thanks
<pitti> dendrobates: depends on how serious this is deemed
<mjg59> seb128: It is indeed the favicon-fallback plugin
<mathiaz> pitti: I don't thinks it's such a serious bug.
<pitti> ok
<dendrobates> pitti: it is an embarrassment, to say the least.
<mathiaz> pitti: it doesn't break apache.
<mathiaz> dendrobates, pitti: yes. it's just annoying.
<pitti> https://launchpad.net/~ubuntu-archive/+subscribedbugs?field.searchtext=sync
<pitti> -> I don't see a sync request for apache2 here
<mathiaz> dendrobates, pitti: and I can be disturbing for enduser.
<pitti> "LaMP"?
<mathiaz> pitti: bug 131118
<ubotu> Launchpad bug 131118 in apache2 "Sync apache2 from debian unstable (2.2.4-3)" [Undecided,New]  https://launchpad.net/bugs/131118
<mathiaz> pitti: I've subscribed ubuntu-main-sponsor.
<pitti> mathiaz: ah, good
<pitti> mathiaz: "No Ubuntu changes" -> no relevant ones any more
<pitti> mathiaz: synced and closed
<dendrobates> mathiaz: mdz wants a custom page to load anyway.  We need to get someone to write some php.
<cjwatson> pitti: back now. I can have a look at oem-config nowish if I still have time ...
<mathiaz> dendrobates: hum... Is php installed by default ?
<cjwatson> pitti: I didn't fix rescue mode, and I didn't realise anyone else had ...
<pitti> dendrobates: so if you want, I'll speed up the building and build new server ISOs
<pitti> cjwatson: wb
<mathiaz> dendrobates: it's not that easy anyway...
<cjwatson> bdmurray: pong
<dendrobates> pitti: I think that would be best.
<pitti> cjwatson: indeed I need to rebuild ubuntu ISOs anyway for the oversizedness
<mathiaz> dendrobates: there has been a lot of debate over the default apache web page.
<pitti> cjwatson: so, fixing those is highly appreciated (either disabling OEM, or even better, actually make it boot)
<pitti> cjwatson: does Kubuntu/edubuntu/xubuntu also have that OEM mode?
<ajmitch> dendrobates: what sort of thing does he want on the php page?
<cjwatson> mikmor2: a few directories are bind-mounted at various points - /cdrom, /proc, /dev, maybe /rofs
<Riddell> kubuntu does have oem
<cjwatson> kubuntu is certainly supposed to
<mathiaz> dendrobates: there is a bug in the debian tracker about it.
<pitti> Riddell: do you want live CDs rebuilt for that?
<dendrobates> ajmitch: I don't know, for sure.
<Riddell> pitti: yeah, may as well
<cjwatson> pitti: everything but edubuntu and server has oem-config
<mathiaz> dendrobates, ajmitch: it depends what the target is.
<pitti> cjwatson: ok, then we at least don't waste the current edubuntu build
<ajmitch> mathiaz: I'm assuming this is only for the LAMP setup?
<bdmurray> cjwatson: I thought I heard you mention a design decision as to why "vga=" isn't used with grub.  Is that right?
<cjwatson> pitti: just rsyncing desktop now
<dendrobates> mathiaz: It is on the server tasks page, and mdz asked the status.
<mathiaz> ajmitch: well... I don't know exactly what mdz has in mind.
<cjwatson> bdmurray: vga= isn't used because that makes vesafb be used which makes suspend/resume a very sad panda
<mathiaz> dendrobates: ah ok...
<stgraber> pitti, cjwatson: ok, I'll add for Kubuntu as well, what about Xubuntu ?
<cjwatson> stgraber: Xubuntu has OEM mode, though I'm not sure anyone cares ...
<mathiaz> dendrobates, ajmitch: there has been a lot of debate about what should be put in the default index page.
<pitti> stgraber: I don't think that it's worth the trouble for T4 TBH
<cjwatson> as in, haven't heard of any OEMs shipping it. it'll just be the same as Ubuntu's anyway
<ajmitch> server tasks is assigned to soren, right?
<dendrobates> mathiaz: we can discuss it in the next server meeting.
<mathiaz> dendrobates, ajmitch: be it for the LAMP install or the default install.
<ajmitch> mathiaz: I imagine there would be :)
<cjwatson> bdmurray: IIRC because vesafb doesn't know how to reprogram the card's registers on resume
<stgraber> pitti: ok, so we'll have it for Ubuntu and Kubuntu now, I can still add others later
<mathiaz> dendrobates, ajmitch: every know and then there is a end user that shows up and claims that apache/debian/ubuntu has hacked its server
<pitti> mathiaz: lol
<ajmitch> mathiaz: they make for funny stories online, but yes, I understand the problem
<mathiaz> dendrobates, ajmitch: because their ISP/web hosting has messed up the configuration of the httpd server.
<ajmitch> pitti: look up the one about centos
<bdmurray> cjwatson: hmm, does that pertain to bug 129910 at all?
<ubotu> Launchpad bug 129910 in Ubuntu "tty[1-6]  are active but display nothing in Gutsy" [Undecided,New]  https://launchpad.net/bugs/129910
<dendrobates> mathias ajmitch:  I know :) but we can't design to the lowest common denominator.
<mathiaz> ajmitch: yeah - that was the last one... last year I think.
<cjwatson> bdmurray: yes, it's entirely possible that removing vga= will fix it
<dendrobates> pitti: How long will the rebuild take?
<cjwatson> bdmurray: it's rather odd that they have locale=es_ES in their boot options
<dendrobates> pitti: of the iso?
<cjwatson> that's supposed to be filtered out
<pitti> dendrobates: apache2 doesn't take that long, but the publishing will
<cjwatson> ... oh, bugger
<pitti> dendrobates: all in all, two hours maybe
<cjwatson> that's definitely a bug, I think ubiquity needs to ship /etc/preseed.aliases
<bdmurray> cjwatson: right, they admit as much so I was wondering if it was dismissable
<dendrobates> mathiaz: we need to retest either tonight or tomorrow morning.  I need to get my sparc setup anyway.
<mathiaz> pitti: ok. So we'll have to start over to cd testing.
<cjwatson> bdmurray: we started filtering out vga= from the options set on the installed system in the dapper installer
<mathiaz> pitti: when will you release tribe-4 ?
<cjwatson> bdmurray: so an upgrade from before then could still have it
<cjwatson> bdmurray: it seems like a valid kernel bug though
<pitti> mathiaz: tomorrow afternoon (before meeting) if all goes well
<mathiaz> dendrobates: I'm not sure if we'll have time tomorrow morning.
<mathiaz> dendrobates: morning for us.
<cjwatson> bdmurray: vga= is one of the more common options people fiddle with, even if it does break suspend/resume (and of course lots of people don't care about that)
<cjwatson> "I want higher resolution on my virtual terminals" is actually a fairly common thing to want if you live at VTs
<dendrobates> mathiaz: I can get started pretty early.  We'll do the best we can.
<mjg59> cjwatson: Ben made vesafb a builtin. I suspect this may have broken something in the framebuffer startup script - I'm waiting for him to fix it before looking into it too closely
<cjwatson> mjg59: builtin? interesting
<cjwatson> bdmurray: please reassign to the kernel for now
<mathiaz> dendrobates: ok. I'll test the i386 iso later today then.
<bdmurray> cjwatson: okay, thanks for all of the information
<dendrobates> mathiaz: I have to help feed and put babies to bed.  I'll be back in a few hours to do the amd64 tests.
<cjwatson> bdmurray: np, an interesting bug
<pitti> ogra, LaserJock, stgraber: http://cdimage.ubuntu.com/edubuntu/daily-live/20070808/ (far from being oversized)
<LaserJock> saw it
<LaserJock> pitti: what the? I wonder what happened, we dropped es, xh, fr, de lang packs and amd64 dropped 55MB
<cjwatson> oh!
* cjwatson sees why desktop oem might be bust
<cjwatson> I, er, kind of forgot boot=casper
<pitti> LaserJock: no idea
<LaserJock> pitti: hmm, well at least they're under :-)
<stgraber> ogra: want something specifc to be tested on Edubuntu server ?
<stgraber> pitti: "panel encountered a problem with loading "OAFIID:GNOME_FastUserSwitchAplet"" known issue ?
<pitti> stgraber: no, that worked for me
<stgraber> pitti: just got that at first session open time on edu server
<cjwatson> pitti: oem> if you F6 it and add boot=casper and splash before --, it should get further
<stgraber> ogra, pitti: no fast-user-switching-applet installed on Edubuntu
<seb128> stgraber, pitti: that's because the applet has been added to the panel and is not installed
<stgraber> ogra, pitti: but enabled on gnome default session, so we have that error
<seb128> fast-user-switching-applet should be installed on edubuntu
<pitti> darn
<pitti> seb128: does it really make sense there? last time you said no
<pitti> and on a thin client that sounds reasonable
<cjwatson> mikmor2: I just reread; during target-config, I don't think you have any shared directories. Any particular reason for asking?
<LaserJock> I don't think it's in the seeds
<pitti> LaserJock: no, it's not
<seb128> pitti: I didn't think about the panel profile when replying some days ago
<seb128> I think it would be easier to add it to edubuntu and to make the applet exit if the config is a ltsp one
<cjwatson> evand: do you think it would make sense to disable migration-assistant in ubiquity's oem mode?
<cjwatson> I can't imagine an OEM wanting it ...
<alex-weej> ok so i installed to my USB disk
<pitti> seb128: ah, so you can't tell the panel to load an applet only if it's present?
<cjwatson> pitti: desktop oem boot options fixed for your next build
<pitti> cjwatson: thanks
<cjwatson> pitti: I'm testing it now to see if I can save time
<alex-weej> but i foolishly changed the grub installation device from (hd0) to (hd3) thinking that it corresponded to kernel sdd
<alex-weej> so ubiquity crashed
<alex-weej> or rather gave up with a "fatal error" installing grub
<seb128> pitti: no, it'll display an error if it can't load it
<cjwatson> it's a known ubiquity bug that it doesn't validate that against grub's device.map
<pitti> cjwatson: sorry, can't test right now, I have two installs running already
<cjwatson> pitti: not a problem, I'm doing it
<alex-weej> cjwatson: how can i get this installed? grub setup refuses to accept (hd0) anyway
<pitti> my hd sounds like a sawmill
<LaserJock> heh
<alex-weej> pitti: record it and make some techno
<cjwatson> alex-weej: have a peek in /target/boot/grub/device.map to see what grub thinks the mapping is
<alex-weej> cjwatson: /target was unmounted
<cjwatson> alex-weej: mount it again
<cjwatson> it's all still there
<alex-weej> cjwatson: it thinks /dev/sdd is (hd2)
<cjwatson> alex-weej: right, there you go
<alex-weej> grub> setup (hd2)
<alex-weej> Error 12: Invalid device requested
<alex-weej> grub> setup (hd2,
<alex-weej> Error 21: Selected disk does not exist
<cjwatson> alex-weej: did you chroot to /target to do that?
<alex-weej> cjwatson: no
<cjwatson> do so
<cjwatson> there won't be a /boot/grub/device.map in the live session
<cjwatson> so grub is unlikely to have device mappings there
<cjwatson> at least, they might differ
<alex-weej> now grub doesn't know any devices in the chrooted env
<cjwatson> mount --bind /dev /target/dev from outside
<cjwatson> oh, and mount --bind /proc /target/proc too
<cjwatson> (ubiquity does both)
<alex-weej> yay
<alex-weej> hm. grub> setup (hd2)
<alex-weej> Error 12: Invalid device requested
<cjwatson> ubiquity hadn't finished with the target system yet though
<cjwatson> hadn't removed extra junk packages or copied logs
<alex-weej> can i get it to resume?
<cjwatson> TBH, it might be easier to start over :-(
<cjwatson> no, sorry
<alex-weej> aaaaah
<alex-weej> lol
<alex-weej> ok just to check for sure
<cjwatson> we do need to add that validation rather urgently
<cjwatson> or at least make it reask rather than bail out
<alex-weej> reask for sure
<cjwatson> validation's tricky 'cos we don't have a device.map earlier on
<cjwatson> (I hate grub. Part #47 in a series of #939)
<alex-weej> it's not the first time i've been caught by this. one of my less technical but technical-enough-to-think-he-knows-what-he's-doing friends had a multidisk setup that ubiquity crapped out on
<cjwatson> same thing, or something else?
<pitti> mathiaz: I invalidated the server CDs now
<alex-weej> cjwatson: same thing but not with an external disk
<pitti> mathiaz: (in the tracker)
<alex-weej> so just to check, i'm installing to sdd, what device string should i give ubiquity to use for grub?
<alex-weej> it's defaulting to (hd0)
<mathiaz> pitti: ok. I'll wait for the new isos and redo all the test then.
<cjwatson> alex-weej: you can give it /dev/sdd, you know ....
<stgraber> pitti: About edubuntu, are you going the ISOs with a fix soon or shall I continue testing those ones ? (fix being adding fusa to the seed or find a way to make gnome not load it)
<alex-weej> cjwatson: magic.
* alex-weej dives in again
<cjwatson> grub-install notices that and converts
<pitti> stgraber: meh, that's going to take two hours at least; not sure wheter we should fix it for Tribe 4
<alex-weej> cjwatson: sure there's no sneaky way to get it to skip the file copying? :/
<pitti> stgraber: 'make gnome not load it' is out of question for T4, I'm afraid; seeding would be ok, but it needs to go to -desktop (so it takes more like three hours to get new CDs)
<stgraber> pitti: the Desktop one being probably affected as well, it'll be the first thing a Tribe-4 users will see on the live environment
<alex-weej> when is Tribe 4 due?
<pitti> stgraber: oh, right, servers, too?
<cjwatson> alex-weej: nope, sorry
<stgraber> pitti: I'm on the server one currently
<alex-weej> cjwatson: ok, i'll watch some Big Brother Live
<pitti> stgraber: please continue testing, though, just to find more serious bugs
<cjwatson> alex-weej: tomorrow, or today depending on your timezone
<pitti> stgraber: ok, I'll prepare a seed update
<alex-weej> cjwatson: ah ffs. only reason i am messing with tribe 3 is to do QA
<pitti> seb128: that's just fast-user-switch-applet, right?
<cjwatson> alex-weej: http://wiki.ubuntu.com/GutsyReleaseSchedule has the dates
<seb128> pitti: yes
<alex-weej> suppose i shoulda checked that first.
<stgraber> pitti: everything running edubuntu-desktop must be affected (desktop, server desktop and of course thin clients :))
<alex-weej> right i'll just get going with that tomorrow then
<alex-weej> time to reboot my crufty ex-Edgy upgrade
<pitti> stgraber, LaserJock: ok, seeds changed, edubuntu-meta updating, invalidating CD images in tracker
<stgraber> ok
<LaserJock> pitti: k
<stgraber> ogra: we still have a nbd-server crash reported by apport
<pitti> stgraber: please file it, but it's too late to fix for Tribe 4
<stgraber> ogra: it's the usual init.d script which segfaults (when it shouldn't even be run as we are using inetd ...)
<stgraber> pitti: it must already have been filed as we had it with Tribe-3 :)
<pitti> stgraber: hm, it wasn't a milestoned bug
<stgraber> hmm, so maybe it was fixed and a new version of nbd-server introduced it again, will check
<pitti> xubuntu desktop CDs ready for testing
<alex-weej> what
<cjwatson> pitti: desktop oem seems largely ok except for the wart that autologin and such isn't configured
<cjwatson> easy to fix, but not for tribe-4 of course
<pitti> cjwatson: great
<alex-weej> pitti: is there some kind of ETA on ubuntu tribe 4?
<pitti> alex-weej: tomorrow
<pitti> cjwatson: if you have a fix right now, it's possible to sneak it in
<alex-weej> pitti: it's already 9 Aug in Europe/London :P
<pitti> cjwatson: but better not, I figure, if it's not essential
<pitti> alex-weej: here, too, but I still have 23 hours :)
<cjwatson> pitti: I don't have it right now
<alex-weej> pitti: are we just waiting for the images? (i.e. are the archives updated?)
<pitti> alex-weej: need to get a fixed apache2 and edubuntu-meta, and rebuild some images
<alex-weej> oh ok
<cjwatson> hmm, wonder if there's a convenient python equivalent of chroot /target [ -f /etc/gdm/gdm-cdd.conf ] 
<cjwatson> s'pose I could just use os.path.lexists
<cjwatson> but no, I need the actual path. hmm.
<cjwatson> think I'll need to clone-and-hack os.path.realpath
<pitti> does anyone feel like writing a tribe 4 wiki page, with the data points from https://lists.ubuntu.com/archives/ubuntu-marketing/2007-August/002167.html?
<pitti> apparently Corey doesn't have time, he didn't answer to my mail
<stgraber> pitti: OpenOffice 2.3 should also be mentioned imo
<pitti> right
<pitti> and ubiquity OEM
<cjwatson> mm, maybe
<cjwatson> still a bit raw, not setting up the oem user correctly
<cjwatson> but I guess it's ok to mention, the ubiquity side works fine
<cjwatson> you have to know to run oem-config-prepare though
* pitti adds some links and TODOs to https://wiki.ubuntu.com/GutsyGibbon/Tribe4
<cjwatson> it doesn't tell you and the icon that was supposed to be installed isn't
<cjwatson> (already fixed in bzr, I think)
<pitti> cjwatson: that should go to the wiki page and release notes then
<cjwatson> might be better to announce in tribe-5 instead with fewer caveats?
<pitti> cjwatson: WFM (we just have the gfxboot entry now)
<cjwatson> yeah
<pitti> cjwatson: but we can leave that for the adventurous :)
<Riddell> calc: openoffice still doesn't start for me in Kubuntu tribe 4 candidate, despite pitti adding the openoffice.org-gtk larks
<Riddell> at least the splash screen is back to blue though :)
<pitti> Riddell: yeah, we noticed; that's a release-note thing, I'm afraid
<Riddell> pitti: same in ubuntu too?
<pitti> Riddell: no, it has always worked there
<Riddell> right
<pitti> Riddell: installing -gtk and -kde on Ubuntu works
<stgraber> why isn't ogra around ...
<pitti> Riddell: calc already isolated the responsible library, but AFAIK there's no real fix yet
<pitti> stgraber: he wanted to go to bed early and get up early
<Amaranth> alex-weej: Can you be less... hostile in your bug reports?
<alex-weej> Amaranth: excuse me?
<stgraber> "This workstation isn't authorized to connect to server" ...
<Amaranth> alex-weej: 'Nonsense!'
<pitti> stgraber: ?
<alex-weej> Amaranth: i can if you tell me what i've said that seems "hostile"
<alex-weej> Amaranth: ah come on, that's not hostility :/
<stgraber> pitti: error message I get when trying to login from a thin client
<Amaranth> alex-weej: That bug is marked as triaged, that means we know what the problem is.
<pitti> stgraber: that sounds...serious
<Amaranth> alex-weej: No need for a 'me too' post anyway.
<stgraber> pitti: I'm rebuilding the thin client image adding a root passwd so I can see what actually happens
<alex-weej> Amaranth: i was adding information. it's a two pixel no-mans land.
<stgraber> pitti: it's better than with previous ldm, at least we have an error message :) (even if it doesn't really tell us anything interesting)
<Riddell> calc: I installed openoffice.org-style-tango openoffice.org-gnome openoffice.org-base and now it start up
<Riddell> not sure which one of those is actually responsible
<pitti> Riddell: -gnome probably
<pitti> Riddell: can you uninstall -tango to check? -base should be there anyway, I figure?
<Amaranth> alex-weej: I'll fix it tomorrow
<alex-weej> Amaranth: i guess you know how much i hate compiz anyway so that probably tainted your perception of the tone of my comment a little bit :P
<pitti> Riddell: or don't you install it deliberately?
<Amaranth> alex-weej: Could be.
<Riddell> pitti: does indeed seem to be openoffice.org-gnome
<Riddell> pitti: -base we stopping including a couple releases ago in favour of kexi which is much better, but then we removed kexi lsat release since it was taking up space
<LaserJock> pitti: the Edubuntu Server Addon CD didn't need to be rebuilt I don't think, are the Server and Server Addon CDs built separately
<pitti> LaserJock: no, it's one step
<LaserJock> k, just wondered
<stgraber> pitti: hmm, this time it let login ...
<pitti> stgraber: heisenbug?
<LaserJock> pitti: how long before Edubuntu Desktop gets rebuild, roughly?
<pitti> LaserJock: about 90 minutes until live is ready, 60 for server
<pitti> LaserJock: oh, add 15 minutes, current publisher isn't finished yet
<LaserJock> pitti: hmm, I wondered it it'd be worth it to add back in at least one or two lang packs
<stgraber> pitti: but ldm didn't reload after logout (so black screen after logout) ...
<LaserJock> but maybe it's just as well to leave that until after Tribe 4
<LaserJock> I don't want to waste a build run on miscalculating lang packs
<pitti> LaserJock: can do
<pitti> LaserJock: I have my script here, and I'll be cautious; which langs are the most important for you?
<LaserJock> well, we had es de fr xh
<LaserJock> on amd64
<LaserJock> I want to say es and fr, but maybe if I leave out de ogra'll be mad at me ;-)
<Kmos> and pt ?
<Kmos> it's one of the most talked in the world
<stgraber> pitti: ok, found the actual bug with ldm, it doesn't disconnect from SSH on session logout, so it doesn't reload and I'm stuck on a nice black screen :)
<LaserJock> pitti: if you can do es de fr on amd64 I think that should be good, I'm not sure how much the fast-user-switch stuff will take but I figure it should work out
<pitti> LaserJock: I leave the server CDs alone; i386 is full, and amd64 not that important for tribe, I figure
<stgraber> pitti: killing ssh by hand seems to be the fix
<pitti> LaserJock: dependencies look like you already have everything
<pitti> LaserJock: and it adds 600 kB
<LaserJock> pitti: right
<stgraber> LaserJock: Were you at last edubuntu meeting (today) ? Has ogra said something about ldm2 (like a new version coming but not uploaded yet) ?
<pitti> LaserJock: adding es will fill up i386
<pitti> LaserJock: you can have one more
<LaserJock> stgraber: no, it's 5am for me
<pitti> LaserJock: (on amd64)
<LaserJock> pitti: de I guess :-)
<pitti> LaserJock: depends on your target audience, I don't know
<pitti> LaserJock: .de isn't a particularly popular edubuntu target, I think
<LaserJock> pitti: ok, fr then, although I think many of our testers know German
<pitti> LaserJock: pt?
<LaserJock> well, we had es, fr, de, and xh before
<LaserJock> I don't know if I should go beyond that
<Kmos> pt is more talked than es or fr
<pitti> no, just one more
<Kmos> brazil talks pt, spanish people understand pt, portugal
<LaserJock> pitti: I mean, beyond the langs that were already there, I was just picking amongst the old ones, so no pt
<Kmos> and so many other countries
<Kmos> africa
<LaserJock> I honestly don't think it's going to matter for Tribe4
<pitti> LaserJock: ok, just adding spanish now
<pitti> second publisher running now, for apache+edubuntu-meta binaries
<mathiaz> pitti: kwel. Server isos should be ready in an hour or so ?
<pitti> Riddell: do you actually want new Kubuntu CDs for OEM when we don't advertise it for Tribe4 yet?
<pitti> mathiaz: yes
<cjwatson> Kmos: our standard ordering was calculated from published speaker numbers as far as I know, and es, bn, hi, ar are all ahead of pt there
<cjwatson> Kmos: Edubuntu typically deviates from our usual ordering though, since it has a weird distribution
<ajmitch> hence xh?
<cjwatson> Kmos: we do not want to get into language wars
<pitti> cjwatson: new standard ordering is en, es, xh, pt, de, fr, bn, hi, ar, ru, zh, though, due to considering input support
<Riddell> pitti: what's broken about it currently?
<pitti> Riddell: just the OEM gfxboot thing
<cjwatson> ajmitch: xh is an anomaly because Canonical paid for the translation ages ago, but since it's so out of date the language pack size is tiny and it hardly matters
<cjwatson> pitti: oh. update http://people.ubuntu.com/~pitti/scripts/langpacksize please :-)
<cjwatson> (preferably with a justification so we remember)
<pitti> cjwatson: I guess I should replace it with a symlink to current bzr head on codebrowse or so :)
<LaserJock> ah, that would be nice, I was using it this morning :-)
<Riddell> pitti: lets not bother then
<pitti> LaserJock, cjwatson: updated my script on people for now
<Kmos> cjwatson: ok..
<Kmos> I think the most spoken, are the first.. but that not the rules here.
<cjwatson> Kmos: much harder to judge objectively though
<cjwatson> bedtime
<Kmos> cjwatson: good night
<pitti> bye cjwatson
<LaserJock> pitti: you gonna be up until the new disks are done?
<pitti> LaserJock: probably, unless I fall off my chair :)
<pitti> gosh, I'm sitting in front of that thing for 20 hours now
<sistpoty> gn8 everyone
<pitti> bye sistpoty
<bryce> pitti :-/
<sistpoty> gn8 pitti, and good luck with staying awake ;)
<pitti> iwj: heh, the fsck bug you reported is the one I asked you to take a look at recently :)
* pitti duplicates
<pitti> yay, I removed 2 MB langpacks from ubuntu desktop amd64, and got 4 MB more free
<pitti> ubuntu desktop CDs available for testing
<ArneGoetje> pitti: finally, eh? now you can get some sleep?
<pitti> ArneGoetje: not yet :/
<pitti> we still need new server CDs, and the entire range of edubuntu
<ArneGoetje> pitti: and all today?
<pitti> and due to an inadvertent key press from me triggering another ubuntu livefs build, I need to wait for half an hour before I can start the edubuntu ones
<pitti> ArneGoetje: yes
<bryce> pitti, congrats :-)
<Riddell> stgraber: if I'm looking at the results of a Kubuntu CD in isotesting, then click on "build list" it takes me back to the Ubuntu list rather than the Kubuntu list
<bryce> (er, for getting the desktop CD's ready, shucks about the extra keypress, guess that happens after 20+ hrs)
<pitti> bryce: the new livefs build won't manifest itself in new ISOs on cdimage, don't worry :)
<pitti> it's just wasted time
<mathiaz> pitti: which is very annoying after 20hrs of sitting in front of your computer...
* bryce nods
<Riddell> pitti: all 4 kubuntu CDs work, except for known bugs (live verify CD broken, openoffice broken)
<pitti> Riddell: ok, good
<pitti> ... ish
<pitti> Riddell: verify is curious
<StevenK> Openoffice is still broken?
<pitti> workaround with adding -gtk wasn't enough
<pitti> it needs -gnome actually
<StevenK> Neat. :-(
<pitti> but that carries heavy dependencies, I figure
<pitti> Riddell: please unseed ooo-gtk from kubuntu, before we forget about it
<Riddell> ok
<pitti> meh, on the ubuntu live, deskbar applet immediately crashes and gives bug-buddy
<pitti> I didn't see that before
<pitti> mathiaz: new ubuntu server isos up
<mathiaz> pitti: great. thanks.
<pitti> can anyone please test the latest desktop and check whether deskbar-applet crashes right at start?
<pitti> dendrobates: wb
<pitti> dendrobates: new server images just arrived
<dendrobates> pitti: great timing
<dendrobates> pitti: I'll get to testing
<dendrobates> er.. downloading. :)
<pitti> stgraber: new edubuntu servers up
<pitti> ogra: ^
<mikmor2> cjwatson: Are you awake by chance?
<pitti> mikmor2: not any more
<mikmor2> do'h.
<ArneGoetje> pitti: where can I download the new images?
<pitti> ArneGoetje: the iso tester tracker has links
<pitti> ArneGoetje: if you already have older CDs, you probably want to use rsync or jigdo, unless you have insane bandwidth :)
<ArneGoetje> pitti: where can I find it?
<mathiaz> ArneGoetje: https://iso.qa.stgraber.org/isotesting/
<pitti> (topic)
<ArneGoetje> mathiaz: thanks
<pitti> ArneGoetje: thanks for testing
<pitti> ArneGoetje: iso tracker has rsync commands etc, too
<mathiaz> ArneGoetje: this is the website used to track the testing effort.
<pitti> ok, edubuntu lives are building
<evand> cjwatson: I'm fine with that
<dobey> if i want to rebuild the kernel on my system, with a couple of extra patches, what's the preferred method for that? patching the source in /usr/src/linux* and doing make kpackage or whatever it is?
<iwj> pitti: Indeed, I remember the question.  But I couldn't remember if it was actually a bug report so I thought I'd file it in case it wasn't.
<iwj> Hope that's not too annoying.  I'll take a look at it properly after FF.
<pitti> iwj: not at all
<ArneGoetje> pitti: can I use the rsync script for the daily builds? Or is that different from iso tracker?
<pitti> ArneGoetje: yes, rsync works well for both desktops and also alternates
<pitti> ArneGoetje: the iso tracker gives you the correct rune; if the local file name does not match, you have to specify it instead of '.', of course
<ArneGoetje> pitti: ok
<pitti> so, this deskbar applet thing still crashes very often for me
<pitti> I'll try the live CD on real iron and then fall to bed
<pitti> cu tomorrow, and happy testing so far
<pitti> wb LaserJock
<pitti> LaserJock: edubuntu server is there, desktop ETA 20 minutes
<pitti> bye everyone
<LaserJock> alright
<mathiaz> pitti: see ya.
<iwj> pitti: Sleep well.
<LaserJock> thanks pitti
<LaserJock> anybody know what "Printing Notification Icon" is?
<RAOF> Isn't that the print queue icon for the notification area?
<fabbione> morning everybody
<ion_> ning
<LaserJock> RAOF: but why is it in the menu?
<LaserJock> that's kinda weird
<calc> Riddell: it starting or not seems to be due to when gtk gets properly initialized which is probably why it sometimes works for kubuntu users and sometimes not
<LaserJock> morning fabbione
<calc> Riddell: it looks like libvclplug_gtk680li.so probably does proper gtk initialization and allows ooo to run on some systems
<RAOF> LaserJock: Absolutely no idea.
<calc> http://kerneltrap.org/node/14148 <- any thoughts about having ubuntu default to noatime,nodiratime ?
<calc> claims in the thread are that it can speed up disk io by a huge amount on things like kernel compiles, etc
<ScottK> calc: "Makes kernel compiling faster" doesn't sound like a common enough use case to support by default....
<calc> ScottK: the claim specifically for kernel compile time was 40% increase in speed
<calc> they don't include much in the way of benchmarks in the thread other than that part
* calc thinks he will see what it does for ooo
<RAOF> Actually, they do.
<calc> "People just need to know about the performance differences - very few
<calc> realise its more than a fraction of a percent. I'm sure Gentoo will use
<calc> relatime the moment anyone knows its > 5% 8)"
<calc> relatime actually writes out atime still but in a different manner, turning it off entirely does even less io
<calc> RAOF: ah maybe i haven't read that far yet
<RAOF> A guy with a thinkpad sees ~10-20% speed increase on kernel compile, from memory.
<calc> its a fairly long page
<RAOF> Indeed.
<calc> hmm ingo claims ubuntu already does that
<calc> but its not in my fstab
<ScottK> You got the special "Make calc wait on OOO" edition.
<ScottK> calc: I guess I'd want to understand better why someone would care about atimes before thinking to seriously about changing the default.
<keescook> well that's ugly.  nanosleep doesn't return while in the initramfs
<doko_> good morning
<LaserJock> morning doko
<ArneGoetje> doko: moin
<doko> ArneGoetje: moin
<ArneGoetje> doko: about the sun-java6-bin issue...
<ArneGoetje> I think it would be best if we path the fontconfig config file provided in the package and replace the Japanese font entry of IPAMona with SazanamiMincho. just like in the sun-java5-bin package.
<doko> ArneGoetje: ok, will do that, probably not this week. more interesting is that we make these changes to the coming icedtea/openjdk
<ArneGoetje> doko: ?
<doko> ArneGoetje: the free "sun-java7"
<ArneGoetje> doko: ah...
<ArneGoetje> doko: personally I currently use the java5 package, because java6 doesn't work with my java applications
<ArneGoetje> doko: but one more change we could probably make to the fontconfig file in the sun java packages: for the Korean fonts, it currently referrs to the Baekmuk Batang font in the ttf-baekmuk package. However, the UnBatang and UnBatangBold fonts from the ttf-unfonts packages are 1. smaller in size and 2. more beautiful. :)
<doko> ArneGoetje: are those free as well?
<ArneGoetje> GPL
<Hobbsee> greetings all
<Hobbsee> geser: no.  i just hadnt gone to bed by that point.
<Mithrandir> Hobbsee: "Girls don't exist on the internet"> excellent article, but quite sad.
<Hobbsee> Mithrandir: :D
<Hobbsee> Mithrandir: indeed
<Hobbsee> Mithrandir: i find it's useful to give out to nutters from userland irc channels.
* Hobbsee still finds it very weird to be called "sir" or "man"
<Hobbsee> my point there was - "is there any point in notifying people abotu it all the time, or ignoring the lesser offenses"
<rosegrass> A package was in Ubuntu has version "20060101-1" but Debian now maintain it too and use "0.0.20070101-1" for version number... How Ubuntu sync this package?
<ion_> hobbsee: Man, that must be irritating, sir.
<Hobbsee> ion_: :P
<StevenK> rosegrass: We can't, we'd need to add an epoch.
<Mithrandir> Hobbsee: dude, that must be strange, yes.
* Mithrandir hugs Hobbsee 
* Hobbsee hugs Mithrandir 
<ion_> If the Ubuntu version is 20060101-1, it has been synced from Debian, or Debian has taken it from Ubuntu in the first place, right?
<Hobbsee> Mithrandir: at least no one manages to make that mistake in person, though
<rosegrass> ion_, no, it's not true. 20060101-1 is only in Ubuntu.. And some new person repacks it in Debian..
<rosegrass> StevenK, does that mean we'll always manually add an epoch??
<rosegrass> StevenK, if there's new Debian version...
<StevenK> The problem is 20060101-1 is greater than 0.0.20070101-1
<rosegrass> StevenK, yes..
<StevenK> So, yes, we'd need to add an epoch, or convince the Debian maintainer to do it.
<stdin> thing is, debian packages guidelines say that a date as a version should be something like 0.0.date in case upstream make a 1.0 relase
<rosegrass> stdin, yes.. it is..
* stdin only knows this because he had to read it to make his 1st .deb today :p
<ion_> Perhaps even 0~date in case theres going to be a 0.0.1 :-)
<Mithrandir> ion_: 0~ means we can't sync as well
<ion_> mithrandir: Generally?
<Mithrandir> ion_: yes, since 0~ is < 0, which is what the sync script compares against.
<ion_> mithrandir: Okay
<Hobbsee> hmmm.  new ooo without -gnome and -gtk still doesnt work
<Hobbsee> ah, works if you add -gnome
<StevenK> Hobbsee: But -gnome probably drags in a shedload of dependancies.
<Hobbsee> StevenK: some, yes.  it's been force added to the kubuntu cds, as there's no other fix coming quickly
<Hobbsee> calc: ^
<StevenK> Hobbsee: Twitch.
<Hobbsee> drat.  it hasnt
<Hobbsee> only -gtk has, and that doesnt fix the issue.
<infinity> I thought it had been confirmed that -gtk fixed it...
<StevenK> I thought Riddell said it hadn't fixed it.
<Hobbsee> infinity: it seems not.  on the bug report, a copule of people mentioend it, but not everyone found that to be the case
<infinity> Hobbsee: Bleh.
<Hobbsee> infinity: i take it you dont care enough to respin the livefs', and the kubuntu cds?
<Hobbsee> (or even think about it?)
<infinity> Hobbsee: I could do.
<Hobbsee> morning pitti!
<infinity> Hobbsee: But we'd need a seed change and meta update first, no?
<Hobbsee> infinity: ah, now you can leave that decision to pitti
<infinity> Well, a seed change and publisher run.  The livefs builds run based on tasks, not metapackages.
<Hobbsee> infinity: true that - i'm still reading backscroll and such - and we wouldnt need that meta update and seed change if we werent going to respin
<pitti> Good morn*yawn*ing
<infinity> I hear that yawn.
<infinity> I think I'm going to have a bit of a siesta for an hour or two before I get back to work.
* Hobbsee throws some icecubes at pitti to wake him up
<pitti> Hobbsee: new CD images? *cry*
<Hobbsee> pitti: right then :)
<infinity> pitti: kubuntu/openoffice still busticated, apparently.
<infinity> pitti: -gtk wasn't enough, also need -gnome
<pitti> infinity: right, we noticed yesterday
<pitti> yeah, it worked on ubuntu with just -gtk and -kde
<pitti> but -gnome pulls in a lot of more dependencies
<Hobbsee> pitti: but gconf, etc, would normally be installed on ubuntu anyway
<pitti> probably
<pitti> calc identified the library that needs to be fixed
<Hobbsee> then, on the other hand, how many people actually use ooo on kubuntu?
<pitti> but we don't have a patch yet, and no time to rebuild OO.o
<pitti> Hobbsee: Riddell did a lot of CD tests yesterday, and apart from that they were ok
<pitti> Hobbsee: so we'll release-note the OO.o issue and give it up for this tribe
<pitti> hey seb128
<seb128> hello pitti
<pitti> seb128: got my sms?
<pitti> seb128: in vmware I saw deskbar-applet crashing a lot on a tracker issue (bug-buddy+nonfunctinoal applet), but it doesn't happen on real iron for me
<pitti> yay race conditions
<pitti> seb128: it's a release-notes thing in any case, but I was curious if you saw that somewhere?
<seb128> pitti: ups, didn't notice the sms before now
<seb128> no, deskbar works fine for me :/
<seb128> and I don't think we got a bug about it
<seb128> do you have a backtrace?
<pitti> seb128: yeah, bug-buddy produces one
<pitti> seb128: I was too tired yesterday, I'll file a bug about it today
<seb128> waouh, you worked late
<pitti> We urgently need to find someone to flesh out https://wiki.ubuntu.com/GutsyGibbon/Tribe4
<Hobbsee> pitti: yeah, cd tests look OK.  ubuntu i386 looks completely untested.  then again, we dont have time to fix anything now anyway
* Hobbsee grumbles at parents coming in to say hello when you're trying to do something else.
<pitti> yeah, but we need more desktop tests
<pitti> I'll do the amd64 ones now
<pitti> but I need someone for i386, too
* Hobbsee can do i386
<Hobbsee> (desktop)
* pitti adds some test cases
<Hobbsee> are they the ones in current/ ?
<pitti> Hobbsee: yes
<Hobbsee> cool.  grabbing them now
<pitti> meh, the guys were so eager to get edubuntu CDs yesterday, and now server doesn't have a single test
<ogra> pitti, running
<pitti> ogra: ah, thanks!
<ogra> pitti, apparently stgraber did a test last night, you guys talked about it in my backlog ;) seems he didnt add the results to the tracker
<pitti> seb128: bug 131247
<ubotu> Launchpad bug 131247 in tracker "libdeskbar-tracker crashes at session start" [High,New]  https://launchpad.net/bugs/131247
<pitti> ogra: yeah, and he tested the previous version, too; he had some trouble with 'not permitted to login' and debugged it, did he mail/bug you?
<Amaranth> pitti: heh, that's a fun one
<ogra> i got a pm
<seb128> pitti: looks like the one where upstream is getting load of duplicates and which should have been fixed in 0.6
<pitti> seb128: can you please flesh out the Gnome/Tracker/fusa section on the wiki?
<pitti> seb128: oh, known already then? good
<seb128> pitti: let me grab some coffee and I'll have a look to it
<pitti> seb128: 'trackerd' exiting doesn't point to the actual bug in tracker, though, I figure
<ogra> pitti, for the nbd-server issue he had i changed bug 122544 to a sync request
<ubotu> Launchpad bug 122544 in nbd "please sync nbd-server from unstable to fix SIGSEGV" [Medium,In progress]  https://launchpad.net/bugs/122544
<pitti> ogra: alright
<seb128> doesn't look like, no
<pitti> ogra: how bad is this? need new CDs for Tribe4?
<pitti> seb128: merci
<seb128> de rien ;)
<seb128> brb, coffee
<ogra> pitti, nah, it throws up an apport win on first login after booting, thats all
<pitti> ogra: as you wish; I sync it now anyway; can we override the ubuntu changes?
<ogra> pitti, we dont use nbd-server in standalone mode, only from inetd ... it crashes only in standalone mode
<ogra> yeah, can all be dropped
<ogra> wouter is a great upstream
<pitti> synced
<ogra> thanks :)
* asac downloading iso
<asac> or is there known brokeness in current?
* Hobbsee attempts to poke people into helping with release notes
<ogra> i havent seen the login error he saw at all yet and apparently he hasnt seen it a second time either
<pitti> asac: some warts, but not fatal ones
<ogra> pitti, ... and the logout thing is serious but not worth a new build imho (this is still called a development relese :) )
<Hobbsee> pitti:
<Hobbsee> pitti: got a preference for real HW, or a VM?
<ogra> *release
<pitti> Hobbsee: real hw always :)
* Hobbsee grumbles
<Hobbsee> pitti: how am i supposed to pretend that i'm doing my assignmetn, with 2 computers running?
<pitti> Hobbsee: one test on real iron, rest on vmware is good
<pitti> :)
<tepsipakki> how can I find an old bug # from launchpad?
<pitti> tepsipakki: advanced search, tick bug states
<pitti> tepsipakki: or try google with 'site:launchpad.net'
* Hobbsee really should be *doing* said assignment, incidently.
<Hobbsee> hi jono
<tepsipakki> um, I mean how to map a malone bug to lp?
<tepsipakki> since the numbers don't match
<jono> hi Hobbsee
<pitti> cjwatson: I filed bug 131250 just for the record; other than that, ubiquity OEM worked well
<ubotu> Launchpad bug 131250 in ubiquity "OEM install should have the 'prepare for end user' icon on desktop" [Medium,New]  https://launchpad.net/bugs/131250
<tepsipakki> uh, wrong bug number on the changelog :P
<Hobbsee> pitti: so far, no luck on poking people into writing release notes
<Hobbsee> pitti: i thougth we had a marketing guy - perhaps, wake him up?  :)
<cjwatson> calc: Ingo made a mistake, we don't
<cjwatson> pitti: huh, now I have to go adjust the patch I already committed ;)
<pitti> cjwatson: hm? for OEM?
<pitti> cjwatson: (sorry, my brain is not yet fully functional, I'm afraid)
<cjwatson> pitti: yes
<pitti> Hobbsee: I got an email from Corey that he wanted to start working on it, but he's to bed now, I guess
<Hobbsee> pitti: i'd expect so, yes.
<pitti> cjwatson: how did you design it?
<cjwatson> pitti: don't understand?
<cjwatson> it was already meant to be there, it was just a straight bug that it wasn't
<pitti> cjwatson: 'I have to go adjust the patch...'
<cjwatson> the debian/changelog bit of the patch, to close the bug
<pitti> cjwatson: oh, I see
<pitti> I just want the bug as a reference, in case we want it in the release notes
<cjwatson> ok
<Hobbsee> pitti: got called to dinner, but i'll test gutsy i386 desktop when i come back.
<pitti> Hobbsee: thanks
<doko> pitti: please accept ecj (re-add a missing dependency for ecj-gcj on ecj, causing build failures)
<pitti> doko: done
<loonyxp> Hello, I have to patch the xorg-server in order to have the default resolution for my flatpanel monitor. Unfortunately it is only possible with the server release version of 1.3.0, since there I can apply mode patches. I have tried to build xorg-server within feisty fawn, but I got an error while building (ld returning status 1) saying "make error [Xdmx] ". I have the dependencies installed that are listed in lauchpad. Has anbody a hint what to do
<stdin> make sure to get all the build-dependencies with, apt-get build-dep package
<loonyxp> stdin: ah, I'll try that. I am new to ubuntu (and debian), so I didn't know that. Thanks..
<pitti> I'm offline for a bit to test-reinstall my desktop, bbl
<Kopfgeldjaeger> whats the best way to convert flv videos to mpeg (with ffmpeg or mencoder)?  ffmpeg -f mp4 works, but there is a quality loss...
<stgraber> morning
<ogra> hey stgraber
<ogra> thanks for the bug pointers :)
<ogra> (nbd-server is synced)
<stgraber> np, did you find a workaround for the ldm bug ?
<ogra> no
<Chipzz> Kopfgeldjaeger: this really isn't the channel for such questions; no support here
<ogra> i'll leave that to sbalneav ...
<loonyxp> stdin: so, I tried it, but apt says, there is nothing to update. (I have deb and deb-src entries for gutsy in my sources list)
<Kopfgeldjaeger> Chipzz: hm, ok
* Hobbsee comes back
<stdin> loonyxp: hmm, maybe try asking on #xorg they should know be able to help you
<Chipzz> Kopfgeldjaeger: your question yesterday about C++/glade coding would be best answered in #gnome or #gtk+ on irc.gnome.org (/msg burito invite <#channel> to get an invite)
<Kopfgeldjaeger> Chipzz: cool, thanks
<Chipzz> (apart from the fact that c++ has a seperate load of issues, but that's even more off-topic)
<loonyxp> stdin: hm, I think it is not an xorg problem, it is a problem of the ubuntu patches, since I was able to build and run the server on another system (gentoo) without the ubuntu patches... who is the maintainer of the xorg-server package for gutsy?
* Hobbsee grabs the ubuntu i386 desktop iso tests
<stdin> loonyxp: "Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>"
<Hobbsee> with any luck, the other machine wont catch fire.
<loonyxp> stdin: thanks
<Hobbsee> seb128: do you know about a deskbar application crash?
<stgraber> current edubuntu-server is 20070808.1 + fusa added to edubuntu-desktop right ?
<seb128> Hobbsee: which one?
<stgraber> (so I can post my test results - the fusa can't be loaded bug)
<ogra> i think so
<Hobbsee> seb128: in moduleloader.py
<seb128> Hobbsee: I know about some crashes, your description lacks detail to reply though
<Hobbsee> seb128: this is true.
<seb128> Hobbsee: https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/131247 ?
<ubotu> Launchpad bug 131247 in tracker "libdeskbar-tracker crashes at session start" [High,New] 
<Hobbsee> oh, i have no network connectoin anyway
<Hobbsee> seb128: oh, bug buddy sends crashes to gnome now.  gnome bug 464978
<ubotu> Gnome bug 464978 in general "crash in Deskbar: running the live cd" [Critical,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=464978
<seb128> Hobbsee: right, and there is no useful information nor backtrace, I'm going to close it
<Hobbsee> seb128: there was one here.  i dont know why it didnt send
<Hobbsee> seb128: but please do
<stgraber> ogra: bug 131259
<ubotu> Launchpad bug 131259 in ltsp "[Gutsy]  LDM doesn't disconnect ssh on logout" [Undecided,New]  https://launchpad.net/bugs/131259
<ogra> stgraber, thanks
* Hobbsee curses nautilus
<Hobbsee> seb128: apologies.  http://wedontsleep.org/~sarah/deskbarcrash
* Hobbsee concludes that gnome still hates her
<Hobbsee> seb128: that's happening on 2 machines here
<seb128> Hobbsee: looks like the bug I pointed to you ;)
<seb128> k, so it's known
<Hobbsee> seb128: great.
<Hobbsee> seb128: erm, that's the one i just reported, i think
<pitti> Hobbsee: I reported it, too
<seb128> Hobbsee: <seb128> Hobbsee: https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/131247 ?
<ubotu> Launchpad bug 131247 in tracker "libdeskbar-tracker crashes at session start" [High,New] 
<Hobbsee> seb128: oh, that one.  right
* ogra grumbles about fsck still being mean
<Hobbsee> pitti: i dont suppose it matters, but NM seems to be segfaulting on shutdown, and is spewing that across the console
<pitti> Hobbsee: not for releasability, but bug should still be reported
<ogra> Hobbsee, lets get rid of the console then ;)
<Hobbsee> ogra: :P
<Hobbsee> ogra: i thought nautilus mounted things as sync now.
<Hobbsee> not async
<ogra> nautilus doesnt mount things :)
<ogra> thats gnome-mount
<ogra> which is using what pitti gives it i guess :)
<Hobbsee> whatever.  gnome in genearl
* Hobbsee isnt a fan of data loss
<pitti> Hobbsee: sync? no, why should it, that's evil
<Hobbsee> pitti: so i can pull the usb stick out, and still have my data
<ogra> ugh ...
<coNP> USB sync is mounted async even in Windows...
<coNP> s /sync/stick/
<ogra> seb128, i think we should make fusa respect the LTSP_CLIENT variable ... i cant imagine its a good idea on thin clients :)
<seb128> ogra: what I was saying yesterday, it's a bit later for the tribe now though
<ogra> yeah
<ogra> well, i need to test it
<ogra> but we have setups with 2000 users on ldap out there
<seb128> ogra: do you desactivate the "switch" action as well?
<ogra> not yet
<ogra> i'll do some testing next week what works and what doesnt first ...
<ogra> if functionallity works i'm fine to keep it
<seb128> ok
<seb128> let me know
<ogra> but i assume fusa will show all available users ...
<ogra> so in ldap setups thats not a god idea
<ogra> (if tehy are huge enough)
<pitti> Hobbsee: 'sync' isn't the right answer, but http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0050.html might be
<stgraber> pitti: just noticed something on the tracker, when you add upgrade "isos", set the version number to tribe-X
<Hobbsee> pitti: neat
* ogra_test waves to pitti from a successfull edubuntu server install :)
<stgraber> pitti: as we don't "rebuild" them
<pitti> ogra_test: thumbs up!
<ogra_test> yeah
<stgraber> ogra_test: you won't say that after having logged out :)
<ogra> seb128, gsd was pretty slow on startup ... i had unthemed panels for nearly a minute (1Ghz system and 256M ram here)
<Hobbsee> ogra_test: yay!
<ogra> stgraber, still testing the server desktop
<stgraber> k
<ogra> stgraber, can you remember if there was one or two ssh processes left ?
<ogra> i suspect scottie kills only the one running *inside* the tunnel,  but not the tunnel itself
<stgraber> ogra: one
<ogra> ah, thats likely it then
<stgraber> ogra: well, after logout I mean
<ogra> i guess we need a .pid file for the tunnel rpocess or so
<Hobbsee> pitti: had any htoughts about who to persuade to write the release notes for ubuntu?  kubuntu looks to be done, or almost done
<pitti> Hobbsee: I'll asked seb for the gnome bits, and I'll steal OO.o from Kubuntu and will fill in apparmor
<Hobbsee> pitti: cool
* seb128 hates writting release notes
<Hobbsee> hmmm.  we should edit that kubuntu release notes ehre
<seb128> I'm not good at making those look nice, etc
<Hobbsee> seb128: that's why you try delegating first :)
<stgraber> Testing seems to be going fine, just some Xubuntu testing still required (alternate) and maybe feisty->gutsy upgrade too
<seb128> Hobbsee: especially when you are not native english speaker :p
<Hobbsee> seb128: i can proofread, if that helps.
<seb128> would be nice
<seb128> I don't intend to write pages anyway
<seb128> I'll let you know when I've edited them, thanks
<pitti> seb128: I'll do some screenshots for fusa and tracker, ok?
<seb128> pitti: great, thanks
<ogra> seb128, trying to switch users on a thin client i get an error i dont have access to ~/.Xauthority (which is true since this is stored on the client)
<ogra> seb128, the prob is that the error doesnt close on click
<ogra> ah, using metacity works, but the close button doesnt
<norsetto> ogra: have you received my email about amachu (new contributor)?
<ogra> norsetto, yes, sorry i was very busy the last two days
<norsetto> ogra: of course; just let me know when you have time; thx
* norsetto wonders why he talks in programming lines
<pitti> seb128, Hobbsee: I pimped https://wiki.ubuntu.com/GutsyGibbon/Tribe4 a bit, WDYT?
<seb128> pitti: very good ;)
* seb128 hugs pitti
<stgraber> pitti: add drop-shadow to the screenshots :)
<fabbione> oh feh.. pitti: RHCS is not critical for Tribe
<fabbione> leave it queued for after
<pitti> fabbione: RHCS?
<thom> red hat cluster suite
<fabbione> yeah i just uploaded redhat-cluster-suite
<pitti> fabbione: ah, that's fine
<asac> pitti: test install failed hard :(
<Hobbsee> seb128: pitti stealing the wiki lock.
<pitti> asac: ?
<_StefanS_> hi there
<asac> in the mids of installation ... i have no idea how i can get dmesg out of busy box to somehwere
<pitti> Hobbsee: still heavily editing, please give me some minutes
<asac> pitti: i used auto-resize option
<_StefanS_> anyone know why subpixel hinting is not compiled in for gutsy ?
<Hobbsee> pitti: ahhh, okay.
<pitti> asac: hm, I tested that, too
<asac> pitti: and see things like "attempt to access beyond end of device" ...
<Hobbsee> pitti: was just going to add the ooo stuff in, but you can do that yourself if you've got teh wiki lock
<asac> pitti: then falling back to ext2
<pitti> Hobbsee: already done
<asac> pitti: after install of xorg ... i suddenly got a corrupted curses screen: e.g. just stripes et al
<asac> pitti: any idea how i can get the dmesg from busybox somewhere?
<Hobbsee> pitti: even better.  wasnt there when i last refreshed :)
<pitti> asac: not really :/ photo camera?
<asac> hmmm not avail
<asac> i have wget :) ... lets see if can pastebin that ;)
<pitti> Hobbsee, seb128: https://wiki.ubuntu.com/GutsyGibbon/Tribe4 pimped further; I'll collect some caveats now and fill them in, rest is more or less complete, I think; review and fixing my Denglish highly appreciated
<_StefanS_> bryce: ping ?
<Hobbsee> pitti: seb128 OK, stealing the wiki lock, to fix the Denglish
<seb128> Hobbsee: thanks ;)
<seb128> pitti: looks good to me
<_StefanS_> bryce: any idea why subpixel hinting is not compiled into gutsy for freetype ?
<pitti> Hobbsee: can you please download tribe s/3/4/ while you are at it?
<Hobbsee> yep
* seb128 is away for lunch
<pitti> hm, the Xubuntu page doesn't look very good, I think I won't link to it
<Hobbsee> pitti: okay, i see what you mean about the Denglish :P
<pitti> Hobbsee: some Frenglish amongst it, too
<pitti> Hobbsee: I'll look at the diff later to learn :)
<Hobbsee> :)
<Hobbsee> pitti: unsure why the deskbar applet is mentioned separately, and also in the tracker section.
<pitti> Hobbsee: deskbar is not only for tracker searches
<Hobbsee> pitti: true
<mvo> Hobbsee: should we mention the improved apport reports on package fialures? I guess its too much of a non-desktop feature
<pitti> mvo: I guess so; maybe we should not advertise things that make crashes look better too much :-)
<Hobbsee> mvo: ask pitti.  i'm not around for this tribe :)
* Hobbsee pinches the wiki lock again
<pitti> mvo: but if you want to write a stanza about it, go ahead please
<mvo> pitti: not really, was just curious :)
<thom> s/moving very quickly/hurrying/
<thom> Gnome -> 'as always' > 'as usual'
<pitti> Hobbsee: ^ you still have the wiki lock?
<thom> Fast User: "Fast User Switching" rather than "Fast user switch applet" (dunno)
<thom> Hobbsee: lemme know when you're done with the lock :)
<pitti> thom: thanks
<Hobbsee> thom: i shouldnt do, now
<Hobbsee> thom: ah, good finds.   didnt notice them
<asac> pitti: can't telll ... retry ... reuse previously created partition appears to work :/
<pitti> Hobbsee, Riddell, ogra: at this stage I'm content with the Ubuntu CDs; I don't like the warts, but it installs at least, and it's too late for new images; what's the "yay or nay" status for kubuntu/edubuntu?
<Hobbsee> pitti: yay for kubuntu - we would have had to respin them hours ago to do otherwise.
<pitti> asac: that sounds serious, though; that should be a tribe-5 bug; it doesn't seem to happen generally, though
<ogra> just running a i386 ubiquity install here, seems good so far
<asac> pitti: there was a difference
<ogra> i386 server is definately ok
<asac> pitti: i had no monitor connected so X resolution selection popped up
<thom> you're far too excited about OOo :)
<asac> pitti: this time i kept monitor connected to see what is going on
<pitti> asac: that always happends to me on alternates, too
<ogra> i would have liked an amd64 test though, but my hw is broken atm
<asac> pitti: resolution selection?
<asac> pitti: hmm
<pitti> ogra: stgraber did quite a lot of tests yesterday with the previous image, but not sure about amd64
<ogra> theer are no amd64 results on the isotracker
<pitti> ogra, Hobbsee: ok, then I'll prepare the /releases/ ISO images now; we can still ditch them if needed, but if they are reaonable, I have it prepared already
<ogra> oh, wait
<ogra> desktop had amd64 tests
<Riddell> pitti: yay indeed
<Hobbsee> pitti: great :)
<pitti> Riddell: I like the OOo screenshot on the kubuntu page :-P
<pitti> Riddell: "Yes, it's blue again!!!"
<Riddell> makes me happy :)  I should update the page with info on how to get oo working
<Hobbsee> Riddell: i did it
<pitti> Riddell: it's there already
* thom de-locks
<pitti> thom: thanks, adding my caveat list then
<Riddell> oh, so it is
<thom> someone please check my english; I've been living in .nl for the last year and it's doing bad things to my grammar!
<pitti> wiki updated
<Hobbsee> thom: why'd you take the comma out?
<Hobbsee>  * On Kubuntu installs Open Office currently does not start but hangs at the splash screen. To workaround this install openoffice.org-gnome. (https://bugs.launchpad.net/bugs/127944)
<ubotu> Launchpad bug 127944 in openoffice.org "[gutsy]  Open Office applications don't start " [High,Confirmed] 
<Hobbsee> thom: the LTSP change looks wrong too - it should be in.
<stgraber> ogra,pitti: my test computer is i386 only
<Fujitsu>  /win 16
<Hobbsee> thom: did you want to fix, or me to fix?
<pitti> stgraber: alright; then let's hope for the best :)
<Fujitsu> Oops.
<thom> Hobbsee: no way, definitely "on the order"
<thom> hrm, maybe not
<Hobbsee> thom: everyone says "in the order of" here.  maybe it's an australian-ism.
<thom> meh :)
<Fujitsu> I don't think it's an Australianism.
<Hobbsee> but, i dont think so
<ogra> stgraber, all fine, there was one amd64 -desktop test
<ogra> i'm fine to take the risk for amd64 server
<thom> what don't you like about the openoffice change? ", hanging" -> "but hangs" seems reasonable to me, but like i say :)
<thom> Hobbsee: you're welcome to fix :)
<Hobbsee> thom: just wondered why you dropped the comma
<Hobbsee> thom: that was the only thing
<Hobbsee> thom: fixed
<thom> cools
<thom> i suspect i was just on an anti-comma tear :)
<Hobbsee> thom: hehe
<ogra> seb128, we should probably add a casper script to disable fusa in the live session weems useless to me to have it there
<ogra> *seems
<pitti> Hobbsee, seb128, thom: are you happy with the Ubuntu wiki page now? if so, I'll move it over to www.ubuntu.com
<seb128> ogra: for edubuntu you mean?
<ogra> seb128, generally
<ogra> seb128, what the use case to have it if there is only a live session user
<seb128> ogra: I don't agree, it display who is logged, allow to right click to add users and is consistant
<seb128> pitti: looks good to me
<cjwatson> asac: you can extract log files using nc, or you can 'anna-install openssh-client-udeb' and use scp
<ogra> or use the menu to do the latter ;)
<asac> damn ... the state is gone already :(
<asac> cjwatson: ^^
<cjwatson> asac: ok, but for the future
<asac> yes .. will remember anna-install
<Admiral_Chicago> pitti: how long until the release?  I'm still working on the notes
<pitti> hi Admiral_Chicago
<Admiral_Chicago> morning
<pitti> Admiral_Chicago: I think two or three hours, since I have to wait for our webmaster
<Hobbsee> pitti: you might be lucky, and get it out before the distro team meeting
<pitti> Hobbsee: that's my hope
<Admiral_Chicago> pitti: okay the Xubuntu notes aren't done yet, unfortunately.
<pitti> Admiral_Chicago: I saw; if you want to do some, that would be great
<doko> pitti: please accept php5 (lpia fix), if this doesn't show up on the CD
<Admiral_Chicago> i'll see what I can do right now, have to go to work in a few minutes, thats been takig up all my time :(
<stgraber> ouch, just noticed that the tracker now takes >1 hour to update it's LP bug DB, I'll put caching of bug status (not refresh not shown bug) high priority
<pitti> cjwatson, evand: I filed bug 131294 (for tribe-5 only); I assigned it to evand for now, please trade it amongst the two of you accordingly :)
<ubotu> Launchpad bug 131294 in ubiquity "does not install language packs for the target language" [High,New]  https://launchpad.net/bugs/131294
<cjwatson> pitti: evand is welcome to it :-)
<pitti> heh, declining the honour? :)
<Hobbsee> hehe, delegation at it's finest
<Hobbsee> pitti: do my assignment, please.  it'll be good for you.
<pitti> Hobbsee: you are talking to a shell script (~/bin/pitti.sh); I am not capable of such things
<Hobbsee> pitti: awww....darn.
<Hobbsee> $ for x in lots; do cp ~/bin/pitti.sh ~/bin/pitti-$x; done.
<Hobbsee> pitti: if you're a shell script, then we can clone you!
<Hobbsee> excellent!
<Spads> set -e
<Hobbsee> Spads: that too.  it was pseudocode :P
<Spads> Hobbsee: no, not for you
<Spads> Hobbsee: for pitti
<Kmos> pitti: http://cdimage.ubuntu.com/dvd -> this one isn't building daily
<Spads> Hobbsee: make him less tolerant of error!
<Hobbsee> Spads: ahhh....
<pitti> Kmos: I know, they are horribly overflown, and I don't have an idea ATM how to fix that
<Kmos> http://cdimage.ubuntu.com/dvd/20070804/gutsy-dvd-amd64.OVERSIZED
<Kmos> :)
* pitti exits with 1
<Kmos> hehe
<Zic> Tribe 4 is online
<Zic> :] 
<Kmos> pitti: bug 130777
<ubotu> Launchpad bug 130777 in Ubuntu "Current Gutsy DVD build ISO is too large" [Undecided,Triaged]  https://launchpad.net/bugs/130777
<Kmos> pitti: how about to delete the current directory, so anyone will download it..
<cjwatson> I'd rather have a clearer note on the page that the image is oversized, so that we don't impede rsyncability for developers keeping up
<cjwatson> anyone in the ubuntu-cdimage team has code access and is in a position to implement
<cjwatson> that
<cjwatson> Kmos: DVDs aren't supposed to build daily, either.
<cjwatson> that's deliberate
<cjwatson> would be too much mirror churn
<Kmos> cjwatson: I've already explained in the man of the bug that he must check of .OVERSIZED, so he don't have 4 hours of download for nothing
<cjwatson> I saw, but it would also be possible to explain that in prose in the automatically generated HTML
<cjwatson> (I'm not going to just edit it on the fly every time; the code should be changed)
<Kmos> yeah, I agree
<cjwatson> maybe we should create a dvd seed, though I was hoping not to have to do that
<calc> cjwatson: oh ok
<calc> pitti: i think i identified the library that allows it to work at all, not the one that needs to be fixed
<pitti> calc: ooh
<cjwatson> doko: would you object to dropping gcc-4.2-source from supported (and thereby from the DVD)? it will stay in main due to build-dependencies
<pitti> calc: we currently recommend to install openoffice.org-gnome as a workaround
<cjwatson> and will save 50MB of the 170MB or so we need to trim
<pitti> calc: but that itself isn't needed; which package is it then?
<cjwatson> calc: "cjwatson: oh ok" => sorry, context?
<calc> pitti: apparently that helps for ubuntu but not kubuntu, i still need to do more investigation into it
<pitti> calc: ok; well, I'll just leave the ooo-gnome workaround in the Kubuntu release notes then
<calc> pitti: from what i read on a bug report its hangs due to not properly initializing gtk
<cjwatson> it's awfully tempting to drop linux-source from the DVD but I think that's useful to have there
<calc> cjwatson: ah about what you said about ingo and noatime
<cjwatson> oh, right
<cjwatson> calc: (this morning, I committed support to d-i upstream for relatime)
<calc> cjwatson: ok
<cjwatson> still need to do support for having default mount options in a reasonable way, though
<pitti> ogra, Riddell: did you find any new OMGTSIF bugs? speak now or never (about to sync-mirrors, for link/bittorrent testing etc)
<Riddell> pitti: nope, go ahead and sync
<cjwatson> pitti: I think bzip2ing texlive-doc and texlive-lang would help
<cjwatson> maybe even texlive-base
<cjwatson> I'm just looking into the numbers
<pitti> cjwatson: would mean a (trivial) debian delta, but indeed
<cjwatson> pitti: yes, seems like it might be worth it
<cjwatson> no intrinsic reason Debian couldn't take it
<evand> pitti: I'll take it (not that I have a choice :) )
<pitti> evand: thanks
<cjwatson> hmm, not obvious that it saves a whole lot from texlive-doc
* Hobbsee ponders actually replying on evand's MOTU app
<cjwatson> damn, bzip2ing texlive-* seems to save maybe a megabyte at most from the largest ones. Probably not worth it :(
<ScottK> Hobbsee: If you have an opinion, please express it.
<cjwatson> hmm, I wonder if I should make germinate show original-maintainer rather than maintainer
<cjwatson> seems like it would be more informative
<pitti> hi mathiaz
<mathiaz> hi pitti
<mathiaz> pitti: how things are going with the isos ?
<pitti> mathiaz: last stages of preparation now
<iwj> pitti: I see you marked my `fsck on first boot' bug 131201 as a dupe of bug 63175 but I don't think that's right.
<pitti> mathiaz: a lot of warts on the desktop, but too late now
<mathiaz> pitti: server seems all good
<iwj> The original submitter of 63175 is getting fsck on _every_ boot.
<ubotu> Launchpad bug 131201 in debian-installer "always fscks first boot after install (dup-of: 63175)" [Undecided,Confirmed]  https://launchpad.net/bugs/131201
<ubotu> Launchpad bug 63175 in e2fsprogs "fsck on every (re)boot" [Medium,Incomplete]  https://launchpad.net/bugs/63175
<iwj> It's possible the cause is the same but I doubt it.
<pitti> iwj: hm, the bug trail seemed to indicate that this was related (clock skew)
<iwj> I think it may well be related, yes.
<pitti> iwj: but I'm ok with unduplicating it; I didn't look into it very deeply
<dendrobates> pitti, mathiaz: I was unable to test the sparc iso.  My ultra 10 needs a little loving care first.  I'll test this afternoon.
<pitti> dendrobates: alright; we'll just push it out and hope then :)
<iwj> I don't think we know how to reproduce 63175.
<ogra> iwj, thst bugs exists since tribe 1 ... there must me another one that matches better iirc
<iwj> ogra: Right.
<ogra> its related to UTC/non UTC setup ....
<doko> cjwatson: np, just needed to build gcj-4.2
<dobey> hola
<cjwatson> fsck> I would love somebody who can reproduce it to fix it
<iwj> cjwatson: 63175 or the first-boot one ?
<cjwatson> iwj: either, frankly :-)
<iwj> :-).
<iwj> 63175 is too hard I think.
<cjwatson> but I meant the first-boot one
<iwj> But I can reproduce the latter.
<iwj> I'll look at it after FF.  I take it we're not in a hurry.
<cjwatson> I am available for advice if anyone can describe the problem within d-i accurately and is just trying to figure out the right fix
<cjwatson> hurry> shouldn't think so
<iwj> cjwatson: Right.
<iwj> I've assigned the bug to myself and milestoned it for tribe 6.  Is that about right ?
<cjwatson> sounds lovely
<cjwatson> (tribe 5 is after FF too, but tribe 6 might be more realistic since I suspect it may take a little while to sort out)
<cjwatson> iwj: FWIW /var/log/installer/cdebconf/questions.dat should be enough information for accurate reproduction by somebody who knows how to read it; alternatively an install with DEBCONF_DEBUG=developer in the kernel boot parameters
<cjwatson> (and /var/log/installer/syslog from the latter)
<dobey> where does the standard .config for building an ubuntu kernel come from? linux-source doesn't seem to include it, and i'm not sure it has the "ubuntu patches" in it either
<iwj> cjwatson: Right.  I'll C&P that into the bug so I'll know what to do later ..
<cjwatson> dobey: apt-get source linux-source-2.6.22 (or appropriate other version)
<cjwatson> it's in debian/config/ or something like that, and the patches are applied
<dobey> ah
<ogra> iwj, i think we already hunted it down to something like: partitioner runs mkfs and puts timestamp into superblock, timezone gets configured and changes the clock backwards (UTC setting), superblock is in the future on first boot and triggers fsck
<iwj> Yes.
* mvo nods
<iwj> The no. of days is 2^32s - 86400 + 3600 or some such.
<dobey> hrmm
<dobey> this one ps3 patch seems to already be applied...
<cjwatson> dobey: certainly a number of ps3 patches are
<dobey> cjwatson: i wonder why my sixaxis doesn't work over usb though, given the appropriate patch seems to be applied already
<dobey> :-/
<cjwatson> dobey: worth asking #ubuntu-kernel; the relevant people should have woken up / be waking up shortly
<mjg59> iwj: Can you see a downside to just altering the fsck code so it ignores dates in the future?
<dobey> interesting
<iwj> mjg59: If the time check interval thingum is set to `don't' then yes, it should ignore them.
<iwj> Otherwise it's not clear.
<mjg59> iwj: My recollection is that older versions of fsck did signed arithmetic here
<sladen> isn't it just a (signed) issue?
<mjg59> Someone found the old code at some point
<iwj> I worry though about fixing this particular symptom like that.  There might be other things that go wrong as a result of clock skew between install and first boot.
<iwj> signed arithmetic> That means if you once fsck with a stupid clock, you might never fsck again.
<mjg59> Hm. That might be the reason for the change
<mjg59> On the other hand, if you change the hardware time, it's not obvious that that should result in a fsck
<sladen> so have a "uninitialised" state (eg. 0x...fffff) that is treated as such
<sladen> set that during that one-time following creation
<mjg59> The obvious way around this would seem to be to write the current time if the existing time is in the future
* ..[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 | Tribe 4 released
<pitti> have fun
<StevenK> pitti: Yay! Congrats
* ogra dances
<pitti> what a messy release again
<ogra> milestone ...
<ogra> :)
* Hobbsee hugs pitti 
<Hobbsee> yay, pitti!
<pitti> at least I learned a whole lot about the guts of Soyuz :) (more than I wanted to, I guess)
* pitti takes a break until the meeting
<Hobbsee> what do we do about bugs such as https://launchpad.net/bugs/131311 ?
<ubotu> Launchpad bug 131311 in Ubuntu "tribe cd images not being produced for powerpc" [Undecided,New] 
<StevenK> I think there was no point making a live CD for powerpc prior to OO.o 2.3, since it didn't build on powerpc
<StevenK> Hrm. No, that doesn't seem to be it, I'll shush now.
<asac> bryce: yt?
<Hobbsee> asac: btw, any plans to update enigmail?
<asac> Hobbsee: is there a wishlist bug ;) ?
<asac> anyway, yes.
<Hobbsee> asac: dunno.  havnet looked.
<Hobbsee> asac: i looked at upgrading it, and went "ewww, that looks decidedly not-fun"
<asac> Hobbsee: its just dropping the enigmail tarball in the archives dir
<asac> bumping changelog ... then spin
<Hobbsee> asac: i wasnt sure if there was more than that
<asac> usually not
<asac> if it breaks, then come back :)
<asac> just be sure that you keep the mozsdk tarball in orig as well
<asac> just upgrade the enigmail one
<Hobbsee> right
* Hobbsee heads off to do a bit of uni assignment
* Hobbsee shudders at http://www.news.com.au/story/0,23599,22206802-2,00.html
<bddebian> Heya
<pitti> StevenK: right
<pitti> Hobbsee, StevenK: OO.o has never been built on ppc so far
<pitti> Hobbsee, StevenK: i actually did attempt to build tribe4 images for ppc, but unfortunately they are uninstallable
<pitti> which is actually my bug (restricted-manager), already fixed in bzr head
<pitti> so we'll get dailies in the next days
<pitti> jamiemcc: it's sooo great to have an upstream who directly works on LP bugs \o/
<jamiemcc> pitti: no  problem - you lot have my undivided attention
<bryce> morning
<pitti> hey bryce
* lamont` notes that he needs to track down the sync-request proceedure and get nfs-utils current in gutsy before pitti kills him.
<pitti> lamont`: just use requestsync :)
<geser> preferable the version from gutsy
<lamont`> pitti: I even have that
<lamont`> pitti: whatever version >= 1:1.0.0-7 will prevent you and fabbione from hurting me
<lamont`> er, -8
<fabbione> lamont`: if it's only because of portmap, i won't hurt you too badly :)
<lamont`> fabbione: nfs mounting was dropped by upstream util-linux...  nfs-utils now delivers mount.nfs
<fabbione> oh i see
<fabbione> well i will put the package on hold
<lamont`> and mount doesn't depend: nfs-utils since 99% of the world doesn't care about nfs, and grandma will never figure out how to remove portmapper later.
<fabbione> yeah i know i am that 1% special
<fabbione> that makes me feel so gooood
<lamont`> preinst has logic that says: if nfs-common (any  version) is installed, and proc is mounted and there are nfs mounts in /proc/mounts, and /sbin/mount.nfs doesn't exist, then bitch and die
<fabbione> gotcha
<lamont`> the further justification is that it is reasonable to expect that anyone running nfs has sufficient clue to deal with "upgrade nfs-common first, or die" error message.
<lamont`> pitti: looks  like he actually got done fixing mount-related bugs in 1:1.1.0-14 :)
<fabbione> lamont`: yeah i guess i fall into the "enough clue" by being part of that 1% :P
<lamont`> fabbione: note that I didn not say "old farts" even once.
<fabbione> lamont`: ROFL
* lamont` goes to an appt
* fabbione installs nis to fall in the "old farts" category...
<fabbione> but then.. i already use postfix...
<norsetto> hey, mind your language
<norsetto> old is a bad word :-)
<alex-weej> cjwatson: got a second mate?
<cjwatson> alex-weej: not really, distro team meeting in progress
<cjwatson> alex-weej: you can let me know what's up and I can get back to you after the meeting's over
<alex-weej> cjwatson: ok thanks, i just want to be sure of how to get Tribe 4 installed so i can test it without wasting an hour installing and then have the bootloader installation failed
<cjwatson> as I say, use the device name (/dev/sdd) without trying to translate to grub-speak yourself
<alex-weej> ok i'll give it a go then, cheers!
<ScottK> pitti: I really like apport saying "The problem cannot be reported.  This is not a genuine Ubuntu package."  Very good that it checks.  Thank you.
<cjwatson> IMO it should just go away rather than telling you that though
<cjwatson> as in, no UI until it's confirmed that it's actually a package bug
<cjwatson> (if possible)
<pitti> ScottK: :)
<pitti> cjwatson: bit tricky, since we already have UI to restart the program and inform about the crash
<pitti> and at that time we don't know yet whether it's a genuine package
<pitti> (it is expensive to find out, and I don't want to do it unless the user is interested in reporting)
<ScottK> Would that be the preferred approach then for a developer who wants a retrace on a crash they are working on?
<pitti> but I do acknowledge that this could be better
<Skiessi> why gutsy has still SDL 1.2.11? why not 1.2.12?
<cjwatson> Debian hasn't packaged 1.2.12 yet, so we probably simply didn't notice
<keescook> Skiessi: looks like debian hasn't packaged 1.2.12 yet: http://packages.qa.debian.org/libs/libsdl1.2.html
<cjwatson> what is interesting in 1.2.12?
<pitti> ScottK: I have some ideas about that, liek providing an 'debug this right here' know if apport-retrace and the ddeb repo are available, and such
<cjwatson> (i.e. why should we take the extra effort to work in advance of Debian in this case?)
<Skiessi> they have fixed some things in mouse support and my cursor has got stuck after quitting some sdl games
<ScottK> pitti: I think that would be even better.  That way LP doesn't get cluttered.
<Skiessi> so I had to always restart X server
<Yagisan> Skiessi, code around the known mouse issues - restarting sdl apps usually fixes the mouse ...
<mathiaz> keescook: So what's the plan to update apparmor kernel module ?
<keescook> pitti: I looked at the apparmor profile for CUPS.  why the need for shadow?  Seems like the 'authentication' abstraction would be useful there?
<keescook> mathiaz: it's up to the kernel team
<mathiaz> keescook: I've updated the userspace part, but cannot test it as it needs the latest version.
<keescook> mathiaz: we're waiting for them to take the patches
<keescook> we discussed that it would be after t4
<mathiaz> keescook: Have you sent the patch ?
<keescook> mathiaz: my understanding is that kyle has it already
<shirish> pitti: you there m8?
<mathiaz> kylem: do you have the new apparmor kernel module ?
* Yagisan regrets buying such a new unsupported nvidia adapter :(
<kylem> did you send it to me?
<pitti> keescook: yeah, probably; it uses <shadow.h> and getspnam() etc
<tkamppeter> pitti, another important thing where I am in favour of s-c-p are the bugs of g-c-m.
<keescook> kylem: I thought you said you had the 10_3 branch from suse?
<pitti> tkamppeter: I agree
<pitti> shirish: yeah, barely
<keescook> kylem: I had sent you the links, and you and BenC looked at them for a bit.
<kylem> oh, right.
<shirish> pitti: do you have some tests, I am getting 502 bad gateway whenever i try to push a 12 MB crash file through apport.
<pitti> shirish: sounds like a Malone problem
<shirish> pitti: could it be? How do I know that?
<tkamppeter> pitti, g-c-m was not maintained upstream, so no one worked on the bugs. s-c-p is maintained very actively, and used on the most widespread distro, so bugs get fixed there.
<pitti> keescook: I'm happy to use the auth abstraction, though
<keescook> pitti: okay, I may tweak this a bit.  I think we should likely add an "avahi-client" abstraction too
<pitti> keescook: cupsd checks users and passwords (lpadmin members) on the web interface
<pitti> tkamppeter: would you have some time for some easy UI tweaks? like we discussed some days ago?
<tkamppeter> pitti, a tool full of bugs is less user-friendly than a tool which asks perhaps a question too much.
<pitti> tkamppeter: I'm also leaning towards using s-c-p, if we can make it a bit easier, it'll be great
<pitti> tkamppeter: *nod*
<tkamppeter> pitti, I have also forwarded your UI suggestions to Tim Waugh, perhaps he will also do something on them.
<pitti> keescook: btw, how evil it is to do "/usr/lib/** mr,"?
<pitti> keescook: I guess that pretty much circumvents the ixr limitations on /usr/bin/, right?
<pitti> keescook: I put that in to get a profile ready at that day, but I guess it should be tighter
<pitti> tkamppeter: yay, thanks
<mathiaz> pitti: it should be included with the base abstraction.
<pitti> mathiaz: no, that only has /usr/lib/**  are
<pitti> mathiaz: oh, sorry, /usr/lib/*.so*                 mr, too
<pitti> 'are'? I didn't type that, that was 'r'
<pitti> silly xchat :)
<mathiaz> pitti: access to libraries should be covered in the base abstraction.
<pitti> mathiaz: what I meant is, if you allow loading and using *all* libraries, then it does not make sense to restrict execution privs to /usr/bin/, or does it?
<pitti> mathiaz: since in all those libraries there's certainly some code you could abuse
<pitti> mathiaz: hm, no idea why I added "/usr/lib/** mr" explicitly; I used it with the profile builder and it barked on me
<pitti> mathiaz: I'll fine-tune that, I guess
<mathiaz> pitti: there is also /lib/** rm
<mathiaz> pitti: there is /lib/lib*.so*                  mr
<mathiaz> pitti: in the base abstractions
<alex-weej> cjwatson: it almost worked. except that if i attempt to boot from the external disk, grub can't bootstrap because it doesn't recognise the file system (Error 17). if i boot from my working grub and use a shell, it shows the filesystem as unknown. the file system is definitely ext3 and i can mount it here fine.
<cjwatson> alex-weej: sorry, I can't help, but I hope somebody else can
<alex-weej> ok thanks
<alex-weej> i will put it on launchpad
<alex-weej> does anyone know where the installer logs go?
<cjwatson> /var/log/installer/
<cjwatson> pitti: thanks for the vmware monitor size tip, btw
<pitti> cjwatson: heh, I was annoyed by it and I just happened to discover that it's configurable, no problem :)
<cjwatson> Riddell: turns out the failure to do a CD check is directly due to there being no suitable usplash theme
<cjwatson> I managed to strace it, and it does open("/dev/.initramfs/usplash_fifo") => ENXIO and bails out there
<keescook> pitti: /usr/lib/** mr, seems pretty open, but probably not hugely harmful.  an attacker already can read /etc/shadow, for example
<cjwatson> might be able to make it fall back to text-only
<pitti> keescook: I agree
<pitti> keescook: what I meant is, with abstractions/base it does to make too much sense to focus on restricting /usr/bin executability, right?
<Riddell> cjwatson: oh, curious
<keescook> pitti: well, just because you can mmap it, doesn't mean you can exec it.  :)
<keescook> or, rather, it raises the bar a bit
<pitti> keescook: but /usr/lib/** has certainly a lot of code to exploit/use
<pitti> keescook: yeah, it probably defeats standard exploits pretty well
<pitti> keescook: I'm thinking on the academic level now
<pitti> i. e. 'someone really means it'
<pitti> keescook: so I'll clean up the profile for abstractions/auth and the reduntant library stuff; did you see anything that's badly wrong or horrifying?
* pitti hugs mvo for bug 128744
<ubotu> Launchpad bug 128744 in soyuz "spurious titlecase in PPA indices" [High,In progress]  https://launchpad.net/bugs/128744
<bryce> mvo, did you want to chat?
* mvo beams
<mvo> bryce: I asked in ubuntu-x :)
<bryce> ahh
<alex-weej> http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html
<alex-weej> we surely need this for gutsy if we're going to ship compiz on by default
<thom> alex-weej: for gutsy? dream on
<thom> it's not even upstream yet
<alex-weej> but we're still going to ship compiz on?
<mjg59> alex-weej: It's only implemented for Intel, it's implemented for a branch of the intel driver we don't use, it's implemented for a branch of drm we don't use and it requires TTM support (which is unstable and which we don't use)
<mjg59> So that's certainly not going in gutsy
<alex-weej> .'. no default compiz
* LaserJock hugs pitti for Tribe 4
<pitti> LaserJock: \o/
<alex-weej> i don't wanna imagine the stick that Gutsy gets when average Joe realises that he can't have "Vista-style" 3D whack while being able to use Google Earth
<mvo> alex-weej: that and video are currently the two big showstoppers for compiz
<alex-weej> what's wrong with video?
<pygi> alex-weej, I can imagine. You are getting it all wrong anyway
<pygi> whatsoever, I have and won't go into further discussion
<mvo> you can not have composited video currenly (only with a specially patched mplayer)
<alex-weej> mvo: hm, video works for me with R350 on Gutsy, as long as i don't use Xv (naturally)
<mvo> alex-weej: right, that is a workaround of course, but non-Xv is not that great performancewise
<alex-weej> what's the solution?
<mjg59> Use textured video rather than overlay
<mjg59> (= wait for the code to be written)
<alex-weej> GL?
<mvo> Riddell: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/131352 looks like something releated to kde?
<ubotu> Launchpad bug 131352 in update-manager "upgrade tool crashed in Gutsy Tribe 3" [Undecided,New] 
<alex-weej> is that what GL output is?
<mjg59> But yeah. Right now compiz causes serious regressions.
<alex-weej> so it's looking like Compiz won't be on by default after all?
<mjg59> Well, it still has exactly the same issues that made us punt it last time
<alex-weej> PUNT
<alex-weej> whenever i read that word i think of Teen Girl Squad. Excuse me.
<Riddell> mvo: yes, assign to me if you want
<mvo> Riddell: do you know already what the cause is?
<mvo> Riddell: thanks, assigned it to you now
* mvo hugs Riddell
<Riddell> mvo: no idea, but we have new versions of pyqt and pykde in recently
<mvo> Riddell: bug #130321 is something that would be good to get solved for gutsy too, the forked dpkgpm causes more and more pain now
<ubotu> Launchpad bug 130321 in adept "apport integration for package failure does not work with adept" [Undecided,New]  https://launchpad.net/bugs/130321
<mvo> Riddell: essentially adept lacks automatic-dependency information, dpkg-log support and apport integration because of it
<mvo> Riddell: any hackers you can summon on it? if not, I will see if I can give it a go, but I will take twice the time of a kde hacker :/
<superm1> join #ubuntu-chicago
<mjg59> jamiemcc: Doing a git pull on a small source tree results in tracker spending really quite a new time updating the index
<mjg59> s/new/long/
<mjg59> It's now spent over a minute writing to the depot files
<mjg59> jamiemcc: strace shows it doing a lot of seeking, reading and writing
<jamiemcc> mjg59: thats correct
<jamiemcc> but it should be quicker
<mjg59> 3 minutes in total
<jamiemcc> kernel io performance on gutsy sux atm o n my hardware
<jamiemcc> on feisty we can update 100 source files a second
<mjg59> jamiemcc: The quantity of seeking its doing would result in it being slow anyway
<mjg59> Is the file format really optimal?
<jamiemcc> yes its a differential indexer
<jamiemcc> we need to fetch the existing contents and compare with changed
<jamiemcc> and then update difference to index
<jamiemcc> mjg59: you can use our crawl directory settings to only index that stuff at startup
<mjg59> Ok. I'm not especially happy about an update of 30 files resulting in tens of thousands of seek.
<mjg59> That's going to be slow, especially on laptops
<jamiemcc> 30 files means about 30 seeks
<jamiemcc> + 30 for fetching original text
<jamiemcc> should be 60 in total
<mjg59> jamiemcc: That's not what I'm seeing
<jamiemcc> you must have a huge db then
<jamiemcc> and not much ram
<mjg59> I have 768MB of RAM
<mjg59> And a 1.3GB database
<jamiemcc> how big is db files in ~/.cache
<mjg59> 1.1G    /home/mjg59/.cache/tracker
<mjg59> jamiemcc: http://paste.ubuntu-nl.org/33161/
<mjg59> That's a snippet - imagine hugely more than that
<jamiemcc> ok
<jamiemcc> should not take a minute to do that
<jamiemcc> a few secs is more normal
<mjg59> Took 3
<jamiemcc> 3 minutes?
<mjg59> Yes
<jamiemcc> how big were the files?
<mjg59> All the time taken was writing to the database, not reading the files
<jamiemcc> we have fsync off so the disk scheduler should optimise that
<jamiemcc> I bet kernel is not doing that
<mjg59> You're repeatedly seeking and reading
<mjg59> There's little the kernel can do to optimise that other than readahead
<jamiemcc> the wrotes should be buffered
<mjg59> Right, but the reading clearly can't be
<mjg59> And it's doing as many reads as it is writes
<jamiemcc> if thwe writes are not buffered it will really slow things down
<jamiemcc> the seeks are all close together on disk so should be fast
<jamiemcc> if buffered the writes will be applied long after the seeks
<mjg59> If you're making several thousand small reads, it's going to be slow
<highvoltage> what's the status of Gobuntu? is there any value in testing the current builds?
<highvoltage> (or tribe 4, at least)
<jamiemcc> mjg59: no more than a few secs
<jamiemcc> alternate read/write is painfully slow
<mjg59> jamiemcc: Hang on, I'll try to instrument this
<highvoltage> (oops, I see there's just daily builds currently)
<mjg59> jamiemcc: Remember that with a small read followed by another small read, you're having to wait for the disk to spin round to the right place again
<jamiemcc> mjg59: can you graph disk reads/writes and see when they are applied?
<jamiemcc> mjg59: we dont control reads - sqlite does that
<mjg59> So on a 4800RPM disk, you're looking at only being able to make 4800 small reads a minute
<mjg59> (worst case)
<jamiemcc> 10 ms access time is average
<jamiemcc> for reads close together buffer will cover some of them
<jamiemcc> and head has less distance to cover
<mjg59> 10ms is only 6000 reads a minute
<jamiemcc> thats worst case
<jamiemcc> if they are close together average seek will be smaller
<mjg59> Whether any of it gets buffered depends on whether the reads are close to each other
<jamiemcc> yes
<mjg59> It's not seek time that's the killer here. It's rotational latency
<jamiemcc> ok
<jamiemcc> but not sure what I can do about it?
<jamiemcc> all i can say is its fast if the writes are buffered properly
<mjg59> Let me just get an idea about how many reads are being made
<rulus> jamiemcc: I mailed you a Dutch translation for Tracker yesterday, did you receive the message?
<jamiemcc> rulus: yes - I will apply soon thx
<rulus> ok, thanks :)
<rulus> it's not 100% complete, but it's a good start
<jamiemcc> ok sorry for the delay applying - just be swamped with bugs atm
<rulus> no problem
<mjg59> jamiemcc: Ok, I'm benchmarking the creation of 399 files totalling 5.9M
<mjg59> It's taken 3 minutes so far
<jamiemcc> that sux
<jamiemcc> are they text files?
<mjg59> C files
<jamiemcc> ok that should take less than 10 secs
<mjg59> With a binary pack file
<mjg59> So a single 2.8M binary
<mjg59> Still running, so 6 minutes so far
<Skiessi> could someone add tabbing to Nautilus? before or after gutsy
<jamiemcc> mjg59: are other disk intensive processes slow?
<mjg59> No
<mjg59> Well, to the extent that this is a 1.8" hard drive, yes
<jamiemcc> I mean ones that read/write a lot
<mjg59> But otherwise, no - no slower than with older kernels
<jamiemcc> are you in swap?
<mjg59> There is swap in use, but I have plenty of free memory
<jamiemcc> ok
<mjg59> So running stuff isn't swapping
<jamiemcc> ext3 ordered mode?
<mjg59> All default mount options
<jamiemcc> ok
<mjg59> [    5.672000]  EXT3-fs: mounted filesystem with ordered data mode.
<mjg59> jamiemcc: To be fair to it, strace is taking up plenty of CPU, so it's not an entirely fair test
<mjg59> But I want to see the syscall counts
<jamiemcc> ok
<mjg59> (Still running)
<mathiaz> stgraber: I'm thinking about asking the ubuntu-server mailing list to do some hardware testing of tribe-4. Do you have an idea on how the iso testing tracker could be used to track the results ?
<Kmos> soren: ping
<mathiaz> Kmos: soren is on vacation for at least two weeks.
<Kmos> mathiaz: ok thx :(
<stgraber> mathiaz: this will be easily possible once the qa.stgraber.org (maybe qa.ubuntu.com by this time) will be working and we'll be able to create sub-domain
<stgraber> mathiaz: but I'm still starting implementing it (kernel and mozilla team being the testers), the details should be discussed at next UDS
<stgraber> mathiaz: so, nothing now :(
<mathiaz> stgraber: ok. Do you think we can add test case per hardware type ?
<mathiaz> stgraber: for example 'dell poweredge 850'
<stgraber> inside the ISO tracker nope, but in the future you will be able to request a server.qa.stgraber.org website and there it'll be possible
<stgraber> you'll set Gutsy+1 BETA or whatever the CD is as milestone
<stgraber> then add your Hardware where you currently see the different ISOs
<stgraber> then add you testcase on them
<mathiaz> stgraber: hum... I see. I'm trying to come up with a solution that would be usable now.
<mathiaz> stgraber: we have the checkCD test case, the LAMP test case.
<mathiaz> stgraber: is it possible to add a "DellPoweredge" test case ?
<stgraber> mathiaz: yes
<mathiaz> stgraber: ok. And can I do this ?
<mathiaz> stgraber: or should I contact you ?
<stgraber> but everyone will see it (both server team and classical contributor) and some people may wonder what the hell is that when doing testing on server iso :)
<stgraber> mathiaz: testcase management is still something I'm the only one who can do that (have to put that directly in the DB), there is still no UI for that (yet)
<mathiaz> stgraber: ok. What about 'HW: DellPoweredge' ?
<mathiaz> stgraber: I don't have the list of hardware yet. Just discussing the possibilities.
<stgraber> yes, that can be a temporary solution before you have your own tracker set (which I think would be better)
<mathiaz> stgraber: yes. I agree with you.
<mathiaz> stgraber: but that won't happen before sometime.
<stgraber> Well, Mozilla team will have some kind of beta working for next Firefox update, but that'll still look like the ISO tracker (lot of ISO specifc things)
<stgraber> What the spec for Gutsy+1 will mainly add is usage specifc modules and user profile options (btw, I'll add the server team as being interested in the new QA tracker in the Spec)
<mathiaz> stgraber: please do. We're interested that too.
<stgraber> mathiaz: as you don't really need much "server testing" specific thing, I'll add you to the "beta test" which could soon be ready (that's just a matter or fixing some Admin UI, user UI is already ready)
<mathiaz> stgraber: great. I guess I'll come up with new ideas/feature proposal once I start using the tracker... :)
<justinwray> bdmurray: May I have a word with you?
<manchicken> Does anybody know whether or not the Ubuntu Dells (running 7.04) are running OEM with Beryl and/or compiz?
<Amaranth> manchicken: doubtful
<manchicken> I asked Dell, and Dell told me that they're running Ubuntu.
<manchicken> heh
<Amaranth> afaik they use stock 7.04
<manchicken> I would think so, too.
<manchicken> Amaranth: Long time no talk.  You're the guy from UDS, right?
<Amaranth> yep
<manchicken> Thought so :)
<Amaranth> manchicken: do you know if it's a boy or girl yet?
<manchicken> Not yet.
<manchicken> We'll know in one week.
<Amaranth> Got pretty worried about you that last night
<manchicken> Yeah.
<manchicken> It was not a pretty trip home.
<LaserJock> oh?
<manchicken> Got well home and got much better real quick.
<LaserJock> you get sick?
<Amaranth> I was thinking exhaustion
<manchicken> Yeah, evidently if you get foreign bacterial infections, drinking beer is not a good idea.
<manchicken> Amaranth: Dehydration.
<Amaranth> Oh, even better :/
<LaserJock> I got really sick at the end of UDS Paris
<manchicken> Amaranth: I got a nasty water-borne bacterial infection.
<LaserJock> took me at least 2-3weeks to get better
<Amaranth> manchicken: That explains it, you're not supposed to drink the local water
<LaserJock> but UDS Sevilla was good for me (other than not a lot of sleep)
<manchicken> I didn't.
* Amaranth only drank Coca-Cola :)
<manchicken> I think I got it from the shower.
<Amaranth> Could be
<cjwatson> I think my illness at UDS-Sevilla was probably caffeine withdrawal
<cjwatson> though it was a bit much for that, might have been a bug too
<manchicken> What's scary is I was drinking about 2-3 liters of water a day.
<Amaranth> That hotel worker thought you were wasted
<manchicken> These Dells have the intel GPUs, but still run Intel wifi cards.
<manchicken> Dude, totally.
<manchicken> The security guy was about to arrest me until that Beryl guy's mom stopped in.
<Amaranth> err, intel GPU + intel wireless is common
<manchicken> stepped*
<manchicken> Yeah, unfortunately the intel wifi is binary-blobish.
<Amaranth> manchicken: Oh, I thought you were out when that happened :)
<Amaranth> manchicken: iwlwifi
<Amaranth> only needs firmware
<manchicken> I was coming to when that happened.
<manchicken> I wasn't out for long.
<Riddell> infinity: could you give back strigi
<manchicken> Let that be a lesson.  Carry a thermometer with you when you travel, and take it easy when you're sick.
<Nafallo> Amaranth: isn't there some binary application as well?
<manchicken> that is, if homeland security will let you onto an airplane with a thermometer.
* Nafallo haven't ran restricted anywhere in quite a while, so doesn't know :-)
<manchicken> Amaranth: Yeah, and that firmware is binary-blob.
<mjg59> Nafallo: Not for 4965
<mjg59> Yes for 3945
<manchicken> And the dells come with 3945
<Amaranth> mjg59: iwl3945 requires a daemon?
<Nafallo> mjg59: thanks. I thought I remembered something about it :-)
<Amaranth> mjg59: I thought only ipw3945 did
<Nafallo> manchicken: the Dells often let you choose, no?
<mjg59> Amaranth: iwlwifi is not currently usable for 3945
<manchicken> Nafallo: No
<Amaranth> mjg59: I noticed :/
<manchicken> mjg59: What is?
<manchicken> mjg59: Please don't say ndiswrapper
<Amaranth> Nafallo: If they did it'd be a choice between ipw3945 and broadcom
<manchicken> I will be *very* upset if I buy a machine and have to run ndiswrapper.
<LaserJock> does madwifi work for most Atheros chips?
<manchicken> IIRC
<manchicken> I've never had one of those.
<manchicken> I've got a broadcom.
<manchicken> Which is the scourge of mankind.
<Nafallo> Amaranth: for D630 I could choose between 3945 and 4965...
<mjg59> manchicken: ipw3945
* Nafallo will have an Atheros tomorrow
<manchicken> Nafallo: Dell is only giving out 3945, and I think System76 is doing much of the same.
<Amaranth> Nafallo: Oh, right, broadcom is only on the Windows versions
<Nafallo> Amaranth: only US has non-Windows versions probably :-)
<manchicken> I ordered my dell on the 23rd of July, they still haven't shipped it or charged the money.
<LaserJock> hmm, I suppose "Atheros Communications, Inc. Unknown device 001c (rev 01)" is not a good sign
<Nafallo> Amaranth: at least D630 only came with Windows :-P
<manchicken> Nafallo: I think Dell sells Ubuntu machines wherever they ship to normally.
<Nafallo> manchicken: I ordered one 5th of July. When they delayed it until 22nd of August I called and told them I couldn't wait that long.
<manchicken> What's the alternative?  Pay the windows tax?
<Nafallo> manchicken: yes.
<Nafallo> manchicken: or freedos
<Amaranth> Dude I think I read on a blog the other day about someone ordering from Dell when the announcement was made and still not having their laptop
<manchicken> Freedos isn't a bad idea if the hardware is decent.
<manchicken> But I wanted a laptop, and I don't think they have any lappies with freedos
<manchicken> Amaranth: They're saying they'll for sure have it out as of the 17th, so we'll see.
<manchicken> I just hope they get it to be before we close on this house and move.
<Amaranth> don't believe the date on the website
<Amaranth> Unexpected demand and all
<LaserJock> I'd love to know what the sales figures have been
<bhale> hi LaserJock
<Nafallo> Amaranth: mine was delayed cause they couldn't get the LCD in time :-)
<LaserJock> bhale:  hi!
<LaserJock> once Walmart starts selling Dells with Ubuntu I'll be impressed
<LaserJock> might even try to buy one
<LaserJock> :-)
<manchicken> Amaranth: Well, they estimated more than three weeks out, I would hope they'd be right.
<ajmitch> hello
<LaserJock> hola ajmitch
<mathiaz> hi ajmitch
<ijuz_> i got btw. my Dell with FreeDOS
<manchicken> ijuz_: Was it a laptop?
<ijuz_> the Ubuntu laptop offers aren't so cheap and halfway crappy stuff
<ijuz_> yes, a Latitude D830 n-series (that means without OS basically)
<bhale> right, i buy latitude (business) over the home user stuff
<stgraber> LaserJock: with only some ads in Newspapers (as they do with their weekly offers) would already impress me :)
<manchicken> I don't know, the laptop I ordered looks awful nice on paper.
<LaserJock> I think I'll just buy Apple from  now on
<manchicken> They do broadcom.  No thanks.
<ijuz_> i asked in an apple store, you can't get apple laptops without OS
<manchicken> And ATI
<LaserJock> ijuz_: well, I want the OS, that's partly the point
<stgraber> I personaly bought one HP Compaq (enterprise product), which was SLED certified (but shiped with XP Pro and free upgrade to Vista business)
<manchicken> ijuz_: And you want the ATI and the Broadcom?
<LaserJock> ATI doesn't bother me so much, Broadcom might
<manchicken> I've been on Broadcom and ATI for 2 years now.  Never again.
<manchicken> And I'll never buy another HP again.
<ijuz_> manchicken: no thanks... i have that in my latitude D810 ;)
<stgraber> so I have both XP (school use), Vista (support for people not running Linux yet) and SLED certified (any Linux should run just fine)
<LaserJock> I've got an HP desktop from walmart, it was a piece of junk, but from Walmart, what do you expect
<manchicken> stgraber: That's fine, but I don't want to run windows.
<manchicken> stgraber: I have no interest in buying them.
<manchicken> stgraber: I just want a standard Ubuntu OEM with hardware that works well with free software.  Dell came the closest to that.
<manchicken> LaserJock: The HP is more of an indicator than Walmart.
<LaserJock> manchicken: what about System76?
<Amaranth> manchicken: what wifi works without firmware?
<Amaranth> my HP works great
<manchicken> LaserJock: They're more pricy than Dell, but they're okay.
#ubuntu-devel 2007-08-10
<manchicken> Amaranth: Realtek ones are fully FSF approved.
<ijuz_> instead of getting this dell-ubuntu laptop i would rather get one with windows, you can only choose between cpu's that have 1 MB L2 cache, that is a joke
<LaserJock> I think I'm most likely to go either System76 or Apple for my next purchase
<Amaranth> manchicken: So you're talking USB dongle
<stgraber> manchicken: so you basically have Dell and System76 and maybe some enterprise product from some other manufacturer
<manchicken> Amaranth: Realtek has some built-in IIRC
<Nafallo> efficientpc.co.uk
<manchicken> stgraber: I've heard folks are having luck with Toshiba and Acer, too.
<manchicken> And IBM
<Amaranth> heh
<manchicken> Sorry, lenovo
<Amaranth> i tried to buy something from toshiba's website
<Amaranth> really, i did
<LaserJock> I'm on Toshiba now, and I don't really recommend it that much
<manchicken> their site is even more confusing than Dell's
<Amaranth> toshiba doesn't want you to use their website
<stgraber> manchicken: I wouldn't recommend Acer due to some over-heating problem I had, Toshiba is fine (never asked for custom offer though) but tech support is fine (at least here in Switzerland)
<Amaranth> they torture you for trying
<Amaranth> manchicken: macbooks are full centrino platform
<manchicken> stgraber: Overheating issues have multiple causes, I think if you were more careful about the components you could avoid that.
<LaserJock> blah, Toshiba made me pay for shipping to get my laptop serviced under warranty
<Amaranth> manchicken: i think they even have the 802.11n wifi
<manchicken> Amaranth: Tonio_ had a broadcom with ATI
<LaserJock> and my Toshiba had lots of overheating issues
<LaserJock> and the hard drive likes to fall out
<Amaranth> manchicken: that's a powerbook or a macbook pro
<stgraber> manchicken: over-heating at the point of having the CPU socket to melt is really a problem, and I wasn't the only one to have that kind of problem :), I think they should have fixed that kind of stuff but I'm not going to buy one of their laptop anymore
<LaserJock> I think I'll just get a mac-mini and carry it in my pocket
<LaserJock> ;-)
<justinwray> LaserJock: Minis are a bit bigger then that,
<Amaranth> manchicken: they don't say if the wifi is 3945 or 4965 but the video is gma950
<Amaranth> which sucks, actually
<LaserJock> justinwray: depends on the size of your pocket ;-)
<justinwray> But, seriously they are slick.
<justinwray> Its not much bigger then a CD player/walkman.
<Amaranth> i can fit my mini in some pockets :)
<stgraber> LaserJock: Main problem with Mac is the graphic card which often is ATI (at least last time I checked)
<stgraber> LaserJock: and the cost of course
<LaserJock> stgraber: I don't care if it's ATI
<Amaranth> stgraber: mini is full intel
<justinwray> stgraber: Yeah, Mini is ATI.
<LaserJock> and the cost is not so bad really
<Amaranth> justinwray: G4 mini is ati
<justinwray> Amaranth: Not for video.
<LaserJock> especially if your a student
<Amaranth> justinwray: you're talking about a mini from 2 years ago
<bhale> the latest mini is intel 950
<LaserJock> sweet
<bhale> and core 2 duo
<justinwray> Amaranth: No, I have one right next to me, just got it.  I swear its, ATI.
* justinwray goes to check...
<Amaranth> justinwray: you're wrong
* Nafallo 2&1>/dev/bed
<Amaranth> justinwray: if it's intel CPU it's intel graphics
<LaserJock> Amaranth: not on all macs though
<Amaranth> They made a big deal out of trying to make you believe the gma950 was as fast as the radeon 9200 it replaced
<Amaranth> LaserJock: Mac Mini and Macbook are full intel platforms
<justinwray> Amaranth: I stand corrected, it is Intel.
<LaserJock> Amaranth: right, but iMacs are intel CPU with ATI
<Amaranth> LaserJock: Macbook Pro is nvidia
<Amaranth> LaserJock: iMac is Radeon HD, worst possible thing
<ijuz_> if the intel driver would be as good as the fglrx driver everything would be fine 8-)
* ion_ blinks.
<ion_> Did i just say the words as good as the fglrx driver?
<ion_> s/say/see/
<Amaranth> ion_: Must have been a typo
<manchicken> System76 had another price drop.
<manchicken> They're actually very competitive with Dell now.
<manchicken> I'm about to cancel my order with Dell and go with System76.
<ijuz_> i'm just annoyed that the intel driver either keeps the screen completely dark after resume on my D830 or the background is full of garbage (the fglrx never ever failed on my other laptop and i suspend and resume it multiple time a day and i don't reboot it for weeks)
<stgraber> well, last time I checked fglrx == kernel panic on tty change and no resume from sleep
<stgraber> it was one of the reason why I change my laptop to full a full Intel one :)
<LaserJock> Amaranth: I really like my iMac at work, I'd love to get one of the new one for home
<Amaranth> manchicken: wow, the 15" is pretty good price
<Amaranth> LaserJock: Radeon HD isn't supported in linux
<manchicken> Yeah.
<LaserJock> Amaranth: so?
<Amaranth> LaserJock: Afaik you can't even get 2D on it
<LaserJock> I used to run Edgy just fine on it
<Amaranth> LaserJock: Who'd want to run OS X all the time? :)
<Amaranth> LaserJock: No, the new iMac uses the new Radeon HD
<LaserJock> Linux works great on it
<Amaranth> it's an r600 series card
<Amaranth> fglrx doesn't even support it
<LaserJock> hmm, so no vesa?
<manchicken> the 14" doesn't have bluetooth or 9-cell batteries.  Poop.
<Amaranth> LaserJock: Don't think so
<LaserJock> I just run vesa on everything
<Amaranth> manchicken: bluetooth kills battery life
<ijuz_> stgraber: well... my D810 doesn't resume anymore properly since about 2.6.20-rc1... (i tracked it halfway down, but i can neither nail it really down, now does anybody care) one of the reasons why i bought a new one, therefore i'm still using a 2.6.19.7
<Amaranth> Sucks that the only 7200rpm drive system76 has is 80GB
<Amaranth> can get double that with dell
<LaserJock> Amaranth: well, if it was fast enough I could run Ubuntu in qemu ;-)
<Amaranth> LaserJock: You mean VMWare Fusion ;)
<LaserJock> no
<LaserJock> VMware Fusion just got released :(
<Amaranth> But it does 3D, you could run compiz :)
<LaserJock> so I'm back to using Q
<LaserJock> blahhh
<ajmitch> why would he want to do that?
<Amaranth> Why would you stop using it when it got released?
<LaserJock> all I'm using it for is a terminal, I don't need all that crap
<LaserJock> Amaranth: it went from $0 to $80
<Amaranth> ajmitch: bling is good for the soul
<Amaranth> No so good for the scientist though, seeing how windowed 3D apps are mostly broken
<ajmitch> only if you sold your soul
<LaserJock> Q works ok for me
<LaserJock> it's slow, but at least it's not going to cost me
<LaserJock> if they had VMware server for OS X I'd love it
* LaserJock <3 VMware server
<manchicken> System76 guarantees 8-10 day turnaround.
<manchicken> Nice.
<manchicken> Beats Dell's 3 week turnaround.
<manchicken> (according to the guy on the phone)
<LaserJock> yeah, I'm sure Dell has somebody out making the silicon for your computer as we speak :-)
<manchicken> Killing and crushing the dinosaur for the oil to make the plastic, too.
<LaserJock> heh
<LaserJock> wow! System76 sells an Edubuntu server
<ajmitch> makes sense, schools would like a server they can just drop in
<LaserJock> yeah, it's just the first time I've ever seen anybody selling something with Edubuntu on it
<ajmitch> a good sign :)
<keescook> woo-hoo:
<keescook> $ ./aslr text
<keescook> ok: ASLR of text functional
<ajmitch> hey keescook
<keescook> hiya ajmitch
<ajmitch> playing with some more security fun?
<keescook> ajmitch: yeah, testing some kernel patches that SuSE extracted from RHEL that I hadn't gotten around to doing myself yet.
<LaserJock> hmm, interesting. Looks like I might have tomorrow off
<LaserJock> the transformer that does the power for campus blew and caught on fire today
<ajmitch> keescook: anything else interesting apart from aslr?
<ajmitch> LaserJock: ouch :)
<LaserJock> so they sent everybody home, but apparently it's going to take a few days to get a new one set up
<LaserJock> the whole university is down
<ajmitch> that's impressive
<keescook> ajmitch: went to DefCon last week; that's always fun.  :)
<ajmitch> and probably very expensive
<LaserJock> ajmitch: yeah
<ajmitch> keescook: lucky you
* ajmitch would love to get to one of those
<LaserJock> keescook: oh nifty, you probably flew over me
<keescook> LaserJock: where are you physically?
<LaserJock> Reno
<keescook> ah!  I bet I did.  :)
<LaserJock> I shoulda flashed my Ubuntu logo
<keescook> hehe
<ajmitch> hm, old bugs to check - bug 9224
* ajmitch wonders who still uses nis
<LaserJock> "What was that ... a bird .. a plane ... no it's ... Ubuntu"
<ajmitch> I saw that debian has pam 0.99 in experimental now
<dobey> doesn't apple use nis?
<ajmitch> they mainly use ldap+kerberos now
<dobey> ah
<dobey> i totally need to set ldap+krb on my server
<ijuz_> i thought apple would use nisplus >:->
<LaserJock> and Linux would have nis-ng?  :-)
<ijuz_> i fought years with nisplus on debian i hate it sooo much
<keescook> ajmitch: PAM> nice! vorlon and I were going to work on it, but it looks like rleigh beat us.  :)
<dobey> hey jono
<jono> hey dobey
<dobey> jono: what country are you in these days?
<jono> dobey: back home in the UK now :)
<jono> dobey: hows things over there?
<dobey> good
<LaserJock> Jonbo: kinda late for the UK isn't it?
<Nafallo> almost midnight
<Jonbo> yes, it's almost 12 there
<LaserJock> oh right, I got home early, I was thinking it was 6-7pm here
<Jonbo> but I'm guessing you weren't talking to me
<LaserJock> Jonbo: sorry, was thinking jono
<dobey> jono: just trying to get a nifty ubuntu job ;)
<jono> LaserJock: is indeed, catching up with before I kip
<jono> dobey: ;)
<dobey> jono: of course, jimmac suggests the UI Dev. position would benefit best from me having it
<ajmitch> keescook: yeah, I think it may be getting a bit close to UVF to stick it into gutsy though
<ajmitch> and a little bit undertested
<ajmitch> hardly up to me though :)
<LaserJock> ajmitch: oh come on, everybody loves a little crack when it comes to security ;-)
<keescook> ajmitch: yeah, we'll see if it flies
<ijuz_> probably the hint that many people need generic.all_generic_ide=1 on recent hardware should be added to the release notes ;)
<fabbione> morning guys
<LaserJock> morning fabbione
<LaserJock> fabbione: what time is it there?
<fabbione> 6:17 am
<ajmitch> morning fabbione
<halcyonCorsair> is #ubuntu-devel the place for help with init-script issues?
<halcyonCorsair> that is, I'm writing an init-script, and killproc / start-stop-daemon aren't behaving as i expect them to
<Chipzz> halcyonCorsair: I believe #ubuntu-motu or #ubuntu-devel indeed is, but you may be better of asking in #ubuntu-motu first ;)
<halcyonCorsair> ok
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Good morning
<ajmitch> morning pitti
<thekorn> good morning pitti
<StevenK> Morning pitti
<doko_> good morning
<LaserJock> hi pitti
<ArneGoetje> pitti: Moin Moin!
* desrt performs a hug-attack on pitti then goes to bed
<pitti> aieee
* pitti raises the zap-o-hug and hugs desrt back frantically
<StevenK> The zap-o-hug? That sounds painful.
<StevenK> pitti: Can you give-back mlt on everything !i386?
<pitti> StevenK: done
<StevenK> pitti: Thanks. :-)
<StevenK> pitti: All three zero-sized NBS list packages can be killed, too.
<pitti> yay
* Mithrandir kicks squashfs
<StevenK> And if mlt actually builds, another four can be killed, too.
<pitti> StevenK: looks good, only sparc remains
<StevenK> pitti: Yup, and that should only take a few minutes.
<StevenK> pitti: If it builds on sparc, are you happy to wave it through NEW?
<pitti> StevenK: sure
<sabdfl> asac: have further feedback for you on the ipw3945 issue
<sabdfl> am having no trouble connecting to a WPA-PSK network in the office
<sabdfl> but am unable to connect at home
<sabdfl> i made a little wpa_supplicant.conf that is super-simple, just identifies the network and gives the password
<sabdfl> that seems to run just fine with wpa_supplicant
<sabdfl> in wpa_cli i can see that the association and key handshake etc completes just fine
<sabdfl> so it seems the issue must be in network manager
<jetscreamer> just for grins iptables -L -n
<tbf> where do i find a quick tutorial for correcting ubuntu's translations?
<tbf> gaim/pidgin's reconnect dialog says "Verbunden" instead of "Verbinden" for ages - want to fix it finally
<pitti> doko: bug 118659 -> please upload
<ubotu> Launchpad bug 118659 in pycurl "PyCurl 7.15.5 not working on AMD64" [Medium,Confirmed]  https://launchpad.net/bugs/118659
<StevenK> pitti: mlt built everywhere.
<Hobbsee> fricking uni connection.....
<Lutin> StevenK: thanks for asking the give-back on mlt
<StevenK> Lutin: No problem.
<StevenK> Lutin: It should get waved through NEW soonish.
<Lutin> StevenK: cool
<asac> sabdfl: thats interesting ... how long does it take to associate at home vs. at work when you associate through wpa_cli?
<Lutin> pitti: could you give-back avr-libc on i386 please ?
<pitti> Lutin: done
<doko> pitti: uploaded
<StevenK> pitti: If you wave mlt through NEW, I should be able to get you to NBS four packages when I get home.
<pitti> StevenK: done
<sabdfl> asac: haven't tried at work, but at home its very fast
<Hobbsee> *sigh*
<asac> sabdfl: maybe a bit background why its so interesting: we found that wpa_supplicant took too long to connect with just network + password for ipw3945 ... unsetting essid manually before starting supplicant boosted the connect time, so we added this as a "hack" to network manager especially to make ipw3945 work
<Hobbsee> would it be too much to ask as to why this connection is blowing up repeatedly today?
<asac> sabdfl: so far I received more than one positive feedback about this move ... you are actually the first for whom it got worse ;)
<Hobbsee> oh neat.  my connection seems to be systematically dropping. 4 drops in 40 mins.
* Hobbsee checks for at 5.52pm
<Hobbsee> asac: i dont suppose yo'uve got ipw3945 stuff waiting to be tested on an open network currently?
<Hobbsee> this network cant get too much eviler.
<asac> Hobbsee: unfortunately not ... yet.
<Hobbsee> asac: darn.
<Hobbsee> asac: yet?
<asac> sabdfl: is your home net a hidden network?
* Hobbsee looks for a large stabbing implement.
<asac> Hobbsee: well ... to be honest ... not having ipw3945 chipset myself doesn't really contribute to get this started ;)
<Hobbsee> asac: fair enough :)
<Hobbsee> asac: (the stabbing implement wasnt for you - it was for whoever invented this uni connection)
<asac> Hobbsee: but i hope to get ipw3945 with my new laptop from dell ;)
<Hobbsee> asac: :)
<Hobbsee> it's not that big an issue - this isnt nm problems today
<Hobbsee> this is with straight dhclient
<Hobbsee> so you're off the hook :P
* stdin waits for the opensource ath_hal driver
<pitti> hey seb128
<seb128> hello pitti
<Hobbsee> evening, seb128
<seb128> pitti: I'll do syncs if that's ok with you, I didn't do archive work on wednesday because of the freeze
<seb128> hey Hobbsee
<pitti> seb128: I'd appreciate some help with archive stuff, I have an awful lot of stuff to do until my wedding
<seb128> pitti: k, I'll give you an hand there ;)
* seb128 hugs pitti
<ajmitch> hey seb128
<seb128> hi ajmitch, it has been some time, how are you doing?
* ajmitch is filing a few sync requests to keep you busy today
<ajmitch> good, how are you?
<seb128> good ;)
<seb128> ajmitch: do you plan to update f-spot? ;)
<ajmitch> of course
<ajmitch> I have it built here & still segfaulting on exit :)
<ajmitch> but it fixes a number of other annoyances
<pitti> ajmitch: that should be fixed with latest gnome-sharp2, according to slomo
<ajmitch> that's good, I'll have to grab that & test it
<pitti> ajmitch: doesn't crash here any more, at lesat
<pitti> least
<pitti> ajmitch: (it's in gutsy already)
<ajmitch> yeah, I haven't updated my desktop for a day or two :)
* ajmitch needs to hold wine at its current version so that he can use it for certain programs :)
<ajmitch> pitti: you're right, it seems to be fine now
<ajmitch> so I'd better keep seb128 happy
<seb128> ;)
<ogra> seb128, fusa shows "edit users and groups" and "setup login screen" to any unprivileged user here
<seb128> ogra: right, but it doesn't allow to run those, does it?
<ogra> gksu doesnt, no
<ogra> but i'm indeed asked for my password
<asac> ok i started a forum thread to get the big picture about which network-manager setup is broken in tribe-4 and which works well ... lets see
<seb128> right, look like a bug
<Mithrandir> mvo: are you aware apt is unhappy wrt multiverse on i386?
<Mithrandir> mvo: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/gutsy/multiverse/binary-i386/Packages.bz2  Hash Sum mismatch
<seb128> feel free to open it on launchpad, I'm busy with other things
<mvo> Mithrandir: checking
<ogra> Mithrandir, ouch, is your apt up to date ? mo fixed that for the file protocol during tribe release for me
<ogra> *mvo
<stdin> happends here too
<Mithrandir> ogra: it's a fresh debootstrap from about ten minutes ago, so yes, I would say it's fresh.
<Mithrandir> and I see it across multiple machines, and saw it yesterday and fabbione and others are seeing it too.
<ogra> yeah, sounds like ... and its not file://
<mvo> Mithrandir: I do not see it here (currently), could you please run: "sudo apt-get update -o Debug::pkgAcquire::Auth=true -o Debug::Hashes=true" and put the result into a pastebin? preferable only with the multiverse line enabled?
<mvo> Mithrandir: ah, its all good, have it here now too
<Hobbsee> (here 3)
* Hobbsee hugs mvo 
<Mithrandir> mvo: http://rafb.net/p/x5ijbV15.html
<tepsipakki> currently cdroms are mounted automatically noexec, but could that be changed?
<mvo> Mithrandir: when I download the Packages.bz2 with wget and do sha256sum on it, I get SHA256:2dd2e520056c5454950f858fefbf0b2bf69dcc1fe9c2b0feb6b4e269c33792b6 (the same as you). but  the multiverse Release file disagrees with that
<mvo> Mithrandir: is LP still using apt-ftparchive to generate the Packages files?
<Mithrandir> I believe so
<cjwatson> tepsipakki: they are? gnome-mount's defaults appear to be exec
<cjwatson> for both iso9660 and udf
<Mithrandir> mvo: if you're getting 2dd2, etc, your download is busted.
<Mithrandir> : tfheen@drescher ..p.root/ubuntu/dists/gutsy > openssl dgst -sha256 multiverse/binary-i386/Packages.bz2
<Mithrandir> SHA256(multiverse/binary-i386/Packages.bz2)= b01cf73944a4ed1cf5d6b2705412eed7134255df5d4a8110fc8ce538cf2449af
<Mithrandir> (this matches what I get when I wget manually from archive.u.c
<Mithrandir> )
<Lutin> pitti: avr-libc give-back failed with the same error ( After installing, the following source dependencies are still unsatisfied: tetex-bin(inst 2007-10 ! <= wanted 3.0-30)|texlive-extra-utils(missing) ) but texlive-extra-utils is actually in the archive. do you have an idea what's wrong ?
<mvo> Mithrandir: the .bz2 hash is ok, its the unpacked one that does not match, could you please give me the value that drescher has for this?
<mvo> Mithrandir: the .bz2 matches the Release file and the downloaded file (for me)
<fabbione> bzip borkage?
<Mithrandir> mvo: ah, ok, you're right.
<Mithrandir> : tfheen@drescher ..p.root/ubuntu/dists/gutsy > bzcat multiverse/binary-i386/Packages.bz2 | openssl dgst -sha256
<Mithrandir> 2dd2e520056c5454950f858fefbf0b2bf69dcc1fe9c2b0feb6b4e269c33792b6
<mvo> Mithrandir: that matches my downloaded hash and the hash that apt computed, but not the one from the Release file it seems. that is obscure
<Mithrandir> ok, so this is a soyuz bug, possible an apt-ftparchive one
<mvo> 4f412a01ce241da6f667310477a9ec79379cc32f175dec15fb8c0cbf7331d46e <- that is what the release file things
<mvo> Mithrandir: I look into apt-ftparchive now to see if I can spot something and wait for cpov to show up
<mvo> Mithrandir: apt got recently better (and stricter) in hashsum checking
<Mithrandir> yes, this matches what's on drescher
<Mithrandir> thanks for investigating
<mvo> woah, it looks like the md5sum (for the unpacked one) in the Release file is correct, now that is strange
<Mithrandir> I wonder why it only seems to affect multiverse.
<tepsipakki> cjwatson: ok, this is on feisty.. haven't tried on gutsy, maybe it's sorted then
<superm1> cjwatson, on that lirc bug that i submitted a debdiff on that you assigned to yourself from u-m-s(bug 129038), it appears that you didn't upload yet, so I added a newer debdiff that resolves an additional bug (bug 129689)
<ubotu> Launchpad bug 129038 in lirc "lirc overwrote my lircd.conf" [Undecided,Confirmed]  https://launchpad.net/bugs/129038
<ubotu> Launchpad bug 129689 in lirc "lirc install doesn't create working hardware.conf for dev/input devices" [Undecided,Fix committed]  https://launchpad.net/bugs/129689
<mvo> Mithrandir: indeed, I wonder if there is some Packages file (or other file) on dresher with the hash 4f412a01ce241da6f667310477a9ec79379cc32f175dec15fb8c0cbf7331d46e and it confuses it for some reason. what version of apt-ftparchive is runing there?
<cjwatson> superm1: ok, I haven't got to it yet
<Mithrandir> > apt-ftparchive --version
<Mithrandir> apt 0.6.45ubuntu14~cat for linux amd64 compiled on Oct  6 2006 17:59:47
<cjwatson> thanks
<Mithrandir> unsure if that's what soyuz uses, though
<cjwatson> fairly sure it does
<infinity> Yeah, that's the binary soyuz calls.
<rgl> hi
<rgl> are the packages maintained in some kind of revision control system?  where?
<infinity> rgl: "The Packages"?
<infinity> rgl: The short answer is "no".  The long answer is "some are, but not many, and in various places."
<rgl> infinity, yes.  source of them.  like, the debian directory.
<rgl> how do you guys keep up with the changes?
<infinity> rgl: See the long answer.
<infinity> rgl: A Debian archive is a revision control system in itself, really, it's not hard to sort out.
<infinity> rgl: Diffing between arbitrary releases of a source package is trivial.
<infinity> rgl: Some of us are fine with that, some prefer finer-grained control, and host their packages on code.launchpad.net, svn.debian.org, etc, etc, etc.
<rgl> infinity, humm. but like, in FreeBSD, it so easy to track change, beause all the ports are in one place.  and we can see everything.
<infinity> Debian's always been decentralised, this is nothing new.
<infinity> And Ubuntu's just inherited that.
<rgl> oh, I hoped that decentralised did not mean "hard to find"/etc.
<infinity> It's never hard to find the source.
<infinity> Nor is it terribly hard to track history.
<infinity> It's just not in an RCS you're familiar with, that's all.
<rgl> I mean, it could be easier :)
<infinity> (ie: The RCS is "past source package releases")
<infinity> Anyhow, this conversation's been had about 58 million times, and I don't think "Hey, you should be more like FreeBSD ports" will change anything today. :P
<rgl> for example, I want to backport clamav to dapper (because I don't understand why the verstion there is so ansient) and it fails :|
<infinity> How do you envision a revision control system making the backport magically work? :)
<_StefanS_> bryce: you there?
<rgl> infinity, hehe.  I'm not saying to change.  I just find it somewhat harder to find things.
<rgl> infinity, it would make it easier to see why the author modified the debian files.
<Riddell> infinity: did you give back strigi?
<infinity> Riddell: Nope.  Will right now.
<Riddell> infinity: kvkbd too if you could
<Mithrandir> I did now
<infinity> rgl: The Debian changelog should be reasonably verbose on that score, one would hope.
<infinity> rgl: If it's not, commit messages wouldn't be any more informative.
<tepsipakki> cjwatson: a fresh tribe4 installation mounts my cd's as noexec :)
<rgl> infinity, how can I diff all the source packages?  is there a tool for this?
<rgl> debdiff?
<infinity> rgl: debdiff package_1.dsc package_2.dsc
<infinity> Riddell: Done.
<Riddell> thanks
<rgl> I have to download them all, since the release of dapper to the one on gutsy?   known anything that automates that?
<infinity> rgl: Err, I guess you'd do that if you really wanted to see what changed in each one...
<infinity> rgl: I'd just start with diffing dapper->gutsy and seeing what jumps out, personally.
<pitti> Lutin: hm, maybe the dependency resolver isn't clever enough to figure that out
<hype_> do anyone know if libX11-xcb will be "included" in ubuntu? i mean gutsy +1 or somehting?
<tepsipakki> hype_: gutsy+1 for sure
<hype_> nice
<hype_> is it buildable on ubuntu atm? (feisty,gustsu?)
<tepsipakki> yes
<hype_> is flash the only major prolem? and no need to compile it from source, its not in, feisty's repos by exemple
<tepsipakki> flash?
<hype_> -no
<Lutin> pitti: btw, can you give-back darkice {amd64,ppc} please ?
<hype_> i mean "need to compile"
<tepsipakki> hype_: you need to enable xcb in libx11
<tepsipakki> and rebuild it
<hype_> okok
<tepsipakki> hype_: but what do you mean flash being a problem?
<pitti> Lutin: done
<hype_> i saw this around
<Lutin> pitti: tahnks
<hype_> tepsipakki , did you try it?
<tepsipakki> hype_: yes, when it was enabled in feisty
<tepsipakki> java is the major problem atm
<pitti> tkamppeter: hi
<hype_> ho sorry, your right java
<pitti> seb128: do you have objections against replacing gnome-cups-manager with system-config-printer?
<hype_> tepsipakki , was it enebled before release or somthing?
<seb128> pitti: no
<infinity> rgl: Let me guess.  You're blatantly ignoring versioned build-deps, and the change to use ${binary:Version} in debian/control is breaking?
<tepsipakki> hype_: for a while yes
<infinity> rgl: (From a quick scan of the changelog, that looks like the obvious backport killer)
<hype_> ok, and theu removed it because of java?
<pitti> seb128: modulo the UI improvements that were discussed recently
<seb128> pitti: gnome-cups-manager is not maintaining for years and has its lot of bugs, if we can use something maintained that's better
<pitti> tkamppeter: ok, then I'm going to change the seeds now
<tepsipakki> hype_: something like that
<pitti> seb128: yeah, and Tim Waugh is even reading LP bugs
<hype_> ok :)
<seb128> pitti: ah, that's nice ;)
<Mithrandir> mvo: no file with the same sha256sum
<mvo> Mithrandir: I *think* this is really a soyuz bug, IIRC the release file is not generated by apt-ftparchive so I need to nag cprov about it
<rgl> infinity, I just lifted the debian/control dependency on dpkg-dev to the version on dapper.
<Mithrandir> mvo: I've asked cprov to prod me when he comes online
<mvo> Mithrandir: cool, thanks
<rgl> infinity, I mean.  I'm trying to build the gutsy version, on dapper.
<pitti> seb128: wow, s-c-p + hal-cups-utils together is smaller than g-c-m \o/
<seb128> ;)
<seb128> doko: do you know about bug #131497 ?
<ubotu> Launchpad bug 131497 in sysvinit "Please update sysvinit to version >= 2.86.ds1-38.1 asap" [Undecided,New]  https://launchpad.net/bugs/131497
<pitti> we didn't merge that for over a year, that's going to be a bit delicate
<seb128> pitti: read the bug please
<infinity> rgl: Right, but the versioned build-dep was there for a reason, not "Just Cause". :)
<pitti> seb128: erk
<pitti> lamoooooooooooooooooont
<cjwatson> tepsipakki: that's not hardcoded in the installer ... *shrug*
<seb128> pitti: right, looks like lamont did the update
<doko> seb128, pitti: hrm, so who wants to volunteer? I'll have to look at this then ...
<rgl> infinity, I'm don't known what is that sorry.  I'm kinda new to backporting or even making debian packages.
<doko> iff nobody else wants ...
<tepsipakki> cjwatson: what do you mean? This is not the live-session
<coNP> Can a core-dev please review a/o sponsor my magyarispell update package (Hungarian spell checker 0.99 -> 1.2)? It has been put to http://www.inf.bme.hu/~aron/ubuntu/magyarispell_1.2-0ubuntu1.dsc (for the time REVU is down). It has also been reviewed and advocated by persia but then we found out that it is a main package so I need a core-dev sponsor.
<cjwatson> tepsipakki: I mean that the code in partman-target that sets up CD mounts does not use noexec
<seb128> coNP: normal way is to subscribe ubuntu-sponsor-main
<cjwatson> tepsipakki: and cdrom-detect even explicitly says exec
<infinity> rgl: Build dependencies specify packages (and versions of packages) required to build the source.  The dpkg-dev in dapper is too old to cope with the changes made to debian/control in version 0.88.4-4 of clamav.
<cjwatson> tepsipakki: ah, but the installer sets user, which implies noexec, ok
<seb128> coNP: ubuntu-main-sponsors
<tepsipakki> cjwatson: oh, it comes from that
<coNP> Okay. Thanks I will.
<cjwatson> user,noauto,exec would be ok, I think - file a bug?
<tepsipakki> cjwatson: against cdrom-detect? yep
<rgl> infinity, I see.  so I have to remove those changes, to make it build there.  or, maybe I can upgrade dpkg-dev?
<cjwatson> tepsipakki: no, against partman-target
<tepsipakki> cjwatson: hum, of course :)
<cjwatson> rgl: the former, I wouldn't touch dpkg-dev if I were you
<rgl> cjwatson, the thing is, I don't know what need to be changed to work on dapper *G*
<cjwatson> rgl: ${binary:Version} -> ${Source-Version}
<rgl> cjwatson, no ":" on dapper?
<cjwatson> binary:Version has better semantics, but Source-Version will do for dapper
<cjwatson> rgl: correct.
<cjwatson> (there's a source:Version now - it's not completely unorthogonal :-), it was just reorganised)
<rgl> cjwatson, cool thx :)
<rgl> cjwatson, where can I read about that stuff?
<cjwatson> rgl: deb-substvars(5) on gutsy
<pitti> Riddell: FYI, I unseeded openoffice.org-gtk from Kubuntu again
* Fujitsu complains about tracker taking a ridiculously long time to index.
<cjwatson> or probably feisty come to that
<rgl> cjwatson, is there anythign like that on dapper too?
<cjwatson> rgl: sure (dpkg-source(1)), but of course it doesn't document variables not supported by that version of dpkg
<rgl> BTW, why doesn't dpkg-buildpackage complains about empty stuff like ${binary:Version} ?
<infinity> dpkg-substvars does complain.
<infinity> "Unknown substitution variable $foo"
<infinity> (Or similar)
<cjwatson> (dpkg-gencontrol, not dpkg-substvars)
<infinity> But it carries on, by design, because it's a nice and useful trick to have variables that expand to nothing.
<infinity> Sorry, gencontrol.
<rgl> thx guys :)
<StevenK> infinity: Any chance of taking another look at libnss-db now the freeze has lifted?
<cjwatson> sigh, busybox mount has no support for external mount helpers
* cjwatson hacks that in
<rgl> is there a way to build a package, but without a subpackge?  like, in clamav there is a clamav-milter, but I don't want that build.  or, I have to nuke that altogether from the control file?
<cjwatson> rgl: you have to nuke it from the control file, out of rules, etc.
<StevenK> It could also be done manually, but that way lies pain.
<rgl> why aren't there knobs on these source packages?
<cjwatson> some source packages provide an environment variable to let you not build individual bits, but that's unusual.
<cjwatson> there are sometimes
<rgl> ah ok.
<cjwatson> but the primary use for a source package is to be built on build daemons
<cjwatson> this being primarily a binary distribution
<Fujitsu> We're not Gentoo, so knobs aren't used much.
<rgl> in FreeBSD port, it usual to have this kinds of stuff.  (sorry for making these comparations all the time...)
<cjwatson> FreeBSD is a primarily source-based system, so of course the emphasis is going to be different
<cjwatson> maintainers will often take reasonable requests for knobs
<rgl> so the way to build packages here is to mount a build system, like pbuilder?
<pitti> mvo: hm, about bug 125816... Tim tested it and the patch looks straightforward, and it doesn't affect runtime behaviour anyway; are you ok with me marking this as -done?
<ubotu> Launchpad bug 125816 in redfish "linux-image postinst matches header_postinst_hook for postinst_hook incorrectly" [High,In progress]  https://launchpad.net/bugs/125816
<cjwatson> rgl: I didn't mean that
<cjwatson> rgl: I meant that we are much more concerned with making the binary packages that come out be suitable for wide use than with making the source packages easily tweakable
<cjwatson> rgl: it's perfectly possible to build source packages in a regular system with dpkg-buildpackage
<rgl> cjwatson, ah ok.
<pitti> cjwatson: if you have the uploads for bug 130376 ready, can you please dput them?
<ubotu> Launchpad bug 130376 in cdrkit "crash while checking MD5sums on jigdo include list" [High,In progress]  https://launchpad.net/bugs/130376
<rgl> cjwatson, thats how I'm doing it.  though, I think it liters the system a bit.   I'm have to invest some time to mount an automated build box/chroot/vm.
<cjwatson> grr, I hate that const char * isn't convertible to char * const
<StevenK> pitti: Thanks!
<cjwatson> pitti: sure, will do when I'm finished with this
<pitti> cjwatson: but should it? those are two different semantics after all?
<cjwatson> err, I mean const char ** -> char * const *
<cjwatson> pitti: yeah, I know, it's just annoying :)
<mvo> pitti: ok, let me do a regression test and then I will mark it done
<cjwatson> (I know that it would be possible to defeat the constness without compiler warnings otherwise)
<cjwatson> actually the problem is more that char * const * isn't convertible to const char * const *, since otherwise execv's second argument could be const char * const *
<pitti> cjwatson: heh; yeah, sometimes I ponder something evil like "#define const /**/' or so :)
<pitti> mvo: wow, that involves building the feisty kernel with it and comparing postinsts
<mvo> pitti: maybe I will rethink my plan then :)
<pitti> cjwatson: (just in case you didn't read bug mail yet, the feisty upload needs the Maintainer: dance)
<cjwatson> pitti: can't I just DEBEMAIL=something@else for minimal change?
<pitti> cjwatson: it's more about keeping the Maintainer: policy consistent in feisty (I guess Debian won't check that thoroughly, but *shrug*)
<cjwatson> I don't think we should be cleaning it up in -updates for other things
<StevenK> pitti: If the publisher is done running, libmiracle0.2.3, libmlt0.2.3, libmlt0.2.3-data and libvalerie0.2.3 can all be NBS'd at your leisure.
<pitti> StevenK: will do
<StevenK> pitti: Thanks
<asac> stgraber: sabdfl: can both of you please post the output of lspci for your ipw3945 network controller ... to pastebin ?
<asac> (lspci -v)
<rgl> infinity, cjwatson: I was able to build clamav on dapper.  thx a lot! :)
<stgraber> asac: http://paste.stgraber.org/2421
<pitti> mvo: so what's the rethought plan? :)
<stgraber> asac: btw, when you have some time to check, it seems that NM is starting dhclient on my wlan interface even when connected on LAN (which causes bad DNS record from the public WLAN my network card autoconnected to)
<mvo> pitti: none yet, currently still digging into the hashsum issue on archive.u.c, but I will attend to it before lunch
<cjwatson> rgl: good stuff
<pitti> seb128: are you still interested in doing the bug 109073 SRU?
<ubotu> Launchpad bug 109073 in gnome-games "Game Tali can't save scores" [Low,In progress]  https://launchpad.net/bugs/109073
<pitti> mvo: ok, thank you
<seb128> pitti: no
<pitti> seb128: 'k, thanks
<asac> stgraber: maybe you can add your setup et al to http://ubuntuforums.org/showthread.php?t=522054 ?
<seb128> coNP: magyarispell, why did you update the Conflicts version? (you didn't document it in the changelog)
<pitti> fabbione: btw, did you see the problem in bug 120177?
<ubotu> Launchpad bug 120177 in multipath-tools "dm-multipath not autoloaded causes multipath to fail" [Undecided,In progress]  https://launchpad.net/bugs/120177
<Amaranth> How does apt handle a Breaks?
<coNP> seb128: not yet
<seb128> coNP: same comment about the debian/rules changes
<seb128> coNP: ?
<coNP> I'll have a look.
<seb128> coNP: "not yet" is not a reply to "why" ;)
<asac> stgraber: can you come up with a log that shows this dhclient is started while connected on LAN issue?
<fabbione> pitti: i thought i fixed that
<seb128> Amaranth: it refuses to update the package if it Breaks something installed
<Amaranth> seb128: that's bad
<seb128> Amaranth: why?
<coNP> seb128: sorry :). Should file a bug against my parser. It left out "why"
<Amaranth> compiz Breaks compiz-extra :)
<stgraber> asac: I think so, will paste it a bit later (I need the net for some mins :))
<fabbione> pitti: nevermind.. i will look at it again
<seb128> Amaranth: hum, I'm not sure now, mvo knows better
<kagou> tkamppeter, ping
<pitti> fabbione: grazie
<Lutin> pitti: darkice give-back built on all archs, thanks. could you give-back dbi on amd64 & ppc too ?
<pitti> Lutin: done
<Lutin> thanks
<mvo> seb128: what is that?
<asac> stgraber: thanks
<seb128> mvo: <Amaranth> How does apt handle a Breaks?
<mvo> Amaranth: what is the issue
<seb128> mvo: will the upgade remove compiz-extra or refuse to update compiz?
<Amaranth> mvo: apparently if you have compiz-extra installed in feisty and try to upgrade the whole thing gets stuck
<mvo> Amaranth: breaks are handled like conflicts in apt, it depends on the score (importance) of the package what will happen
<Amaranth> had to go down to the dpkg level to remove compiz-extra before apt would do _anything_
<mvo> Amaranth: I see, can you file a bug about it please? and milestone it :) and (if that is still possible) attach the output of -o Debug::pkgProblemResolver=true?
<Amaranth> i already helped the guy manually get through it
<infinity> The way I understand Breaks, compiz shouldn't be Breaking compiz-extra anyway, it should just be flat-out conflicting with it, no?
<seb128> infinity: why? the ABI changed so Breaks with thing using the old one should be correct no?
<Amaranth> infinity: well, no, the packages that have the plugins compiz-extra used to should have a Conflicts
<Amaranth> but compiz-core breaks ABI so it's valid to have a Breaks for it there
<stgraber> asac: http://paste.stgraber.org/2423, I got that after doing : killall -9 dhclient + suspend to ram + resume, but looking at the log it looks like it's the standard Debian networking thing that's running the dhclients
<stgraber> asac: do you have a clean /etc/network/intefaces you can post somewhere, so I check that's not mine which is broken ?
<asac> stgraber: what do you mean with "clean" ?
<martoss> hi all
<asac> stgraber: in a perfect worlkd interfaces would just be empty
<stgraber> asac: "standard"
<asac> well ... i think most standard is to just add one auto dhcp entry for your wired interface
<asac> stgraber: http://pastebin.mozilla.org/182973
<martoss> i am trying to debianize a binary package with dh_make.
<stgraber> ok, so mine isn't broken :)
<stgraber> question is why do those two dhclient starts on PC startup and when resuming from sleep
<martoss> my first problem is that the configure and make install scripts are installing in default locations. Is there sth like fakeroot or so one can use in control? Just to avoid modifying all install scripts.
<martoss> second. When i modify some lines in the "source", are the patches vs. "original source" automatically generated?
<asac> stgraber: do you have your wireless interface as auto in interfaces as well?
<stgraber> martoss: For questions about packaging you may better ask in #ubuntu-motu
<stgraber> asac: I have both eth0 and eth1 as auto yes
<martoss> ok, sry :-)
<asac> stgraber: then thats the reason
<stdin> martoss: there is the maint-guide package that has docs too
<stgraber> asac: ok, removed eth1 from there, I'll need to check with a fresh livecd that it doesn't appear in the default network/interfaces
<asac> stgraber: unfortunately it probably appears there
<seb128> infinity: could you have a look to bug #131374?
<ubotu> Launchpad bug 131374 in avifile "buildd try to build avifile for amd64" [Undecided,New]  https://launchpad.net/bugs/131374
<seb128> infinity: how do we fix such bugs?
<Mithrandir> "adjust PaS"?
<infinity> Why is it no longer built on amd64?
<infinity> And is the Debian source in sync with this idea? :)
<infinity> seb128: If it builds, what's the rationale for not allowing it on amd64?
<elmo> isn't it some 'I run win32 binaries because I CAN' crack?
<seb128> infinity: I'm not the one who did the change, I was rather asking from a archive point of view ;)
<Fujitsu> Um, seb128, it's fujitsu, not fujistu.
<seb128> Fujitsu: ?
<Fujitsu> https://launchpad.net/~fujistu/+packages
<Fujitsu> YOu attributed some of my syncs to some random person :P
<seb128> Fujitsu: ups, typo, sorry
<infinity> seb128: Well, if it really shouldn't be on amd64 at all, the answer is "adjust P-a-s", but if it's just being artificially limited, the answer is "adjust the maintainer"...
<Fujitsu> Heh, I'll hopefully remember to check that they build.
<seb128> Fujitsu: thanks, sorry for the typo, no luck that there is somebody matching it ;)
* ajmitch hopes there's no 'ajimtch' :)
<geser> can an ubuntu-main-sponsor please look at bug #131304 and bug #130348?
<ubotu> Launchpad bug 131304 in emacs-goodies-el "[Sync request]  Sync emacs-goodies-el (27.1-1) from Debian unstable (main)" [Wishlist,New]  https://launchpad.net/bugs/131304
<ubotu> Launchpad bug 130348 in festival "[Merge]  festival 1.4.3-21ubuntu1" [Undecided,Incomplete]  https://launchpad.net/bugs/130348
<ajmitch> seb128: thanks for syncing :)
<seb128> ajmitch: you're welcome
<seb128> geser: looking
<seb128> geser: done
<sabdfl> asac: no, it's a public network
<sabdfl> asac: is there a way to use dhclient after wpa_supplicant, to see if i can get dhcp going after the wpa stuff is done?
<geser> seb128: thanks
<Lutin> seb128: buildd try to build gambas2 for sparc and ppc, but it's a i386-only package (upstream do not support other archs) . could you adjust P-a-s ?
<seb128> infinity: how do we adjust P-a-s? ;)
<Mithrandir> seb128: mail upstream. :-)
<infinity> Mithrandir: That's just cruel, you know who upstream is. :P
<Mithrandir> infinity: upstream is cuddly and huggable. :-P
<infinity> seb128: The fundamental issue here is that if Debian is building it on amd64 and claims it works there, I won't adjust P-a-s to drop it on Ubuntu.
<seb128> infinity: that was about what Lutin just wrote
<Lutin> infinity: you're talking about avifile ?
<seb128> infinity: http://packages.qa.debian.org/g/gambas2/news/20070715T141328Z.html
<infinity> seb128: We also don't adjust P-a-s for "people are lazy and won't make it work on other arches", only for "this obviously can't work on other arches, due to arch-specific code".
<seb128> infinity: well, in this case Debian did it
<asac> sabdfl: if wpa_supplicant succeeds you should be able to just use dhclient IFACE
<infinity> seb128: A Debian maintainer != Debian. :)
<pitti> infinity: but shouldn't such cases be handled by simply adjusting the Architecture: field?
<asac> sabdfl: public network + wpa ?
<Lutin> seb128: feel free to reject the avifile bug - actually when setting arch to any rather than (i386 kfreebsd), it builds (don't know it works, but that's another issue)
<sabdfl> asac: 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
<Lutin> (on amd64)
<seb128> Lutin: please close it if you think it's not valid
<Lutin> seb128: ok, will do it then
<asac> sabdfl: can you paste lspci -v
<infinity> pitti: A constant source of contention that one. :)
<seb128> infinity: ok, I'll let you convince the Debian maintainer he should make it work on other arches then ;)
<asac> sabdfl: maybe there is a difference in your details
<sabdfl> pastebin?
<infinity> seb128: I can P-a-s out the latter case, but it leaves an icky taste in my mouth to do it because "upstream can't be bothered to fix porting bugs".
<asac> sabdfl: yes ... use http://pastebin.mozilla.org if you don't have a link at hand
<seb128> infinity: right, but we have already enough to do without taking over every upstream doing that :/
<infinity> seb128: I'll note that 1.9.48 did, in fact, build on every single Debian arch..
* infinity shrugs.
<infinity> seb128: It's more about "if the bugs can be fixed, they should be.. By upstream, Debian, or Ubuntu".
<asac> infinity: for p-a-s ... is debian cvs up again? so you can commit the flashplugin changes there as well?
<seb128> infinity: right
<infinity> seb128: "I don't understand why chars are sometimes signed" (for example) isn't a good enough excuse for a P-a-s entry. :)
<infinity> asac: I already did so, didn't I?
<sabdfl> asac: http://pastebin.mozilla.org/182977
<asac> infinity: hmmm ... looks pretty empty on webfrontend
<infinity> asac: http://cvs.debian.org/srcdep/Packages-arch-specific?root=dak&r1=1.687&r2=1.688
<infinity> asac: You're a month late. :)
<asac> infinity: well i just looked at cvs.debian.org and saw only Attic ... so I assumed that its not really up ;)
<sladen> sabdfl: if there's another dhclient/dhclient3/dhcdbd another running they'll end up eating each other packets;  so you might some  sudo killall dh<tab><tab>'ing before trying   sudo dhclient3 eth1
<infinity> asac: Have to change project root to "dak". :)
<asac> sabdfl: thanks ... btw, can you get a stable (wired) connection at home, so we can do some tests?
<asac> infinity: remember that i am just a monkey ;)
<infinity> asac: Noted. ;)
<norsetto> Any advise on license's problems of bug 131325 (especially if upstream doesn't react)?
<ubotu> Launchpad bug 131325 in conky "Gutsy uses old version of conky." [Undecided,In progress]  https://launchpad.net/bugs/131325
<coNP> seb128: (about magyarispell) I investigated a bit and added explanations into the changelog (uploaded again as well).
<Hobbsee> asac: why do you have the old enigmail version in the enigmail source too?
<seb128> coNP: you investigated? you are not the one who did the changes? ;)
<coNP> seb128: no, somone in our LoCo started to package it but he did not finished. But we wanted this package appear in gutsy because of the many added words, etc.
<asac> Hobbsee: thats clutter from the time when that package built for both: mozilla-suite  + thunderbird
<Hobbsee> asac: ah right
<Hobbsee> asac: fine to remove, then?
<asac> Hobbsee: ah ... you have to change version of enigmail in rules
<asac> Hobbsee: i think so
<asac> Hobbsee: (or rules.thunderbird)
<asac> but that should be it
<Hobbsee> asac: right, yeah, that's what i'm looking at now
<norsetto> Hiya Hobbsee
<Hobbsee> hey norsetto!
<asac> Hobbsee: rules.thunderbird => ENIGMAIL_VERS
<Hobbsee>         cp $(CURDIR)/debian/allmakefiles.sh.0.94.0.thunderbird $(CURDIR)/build-dir/mozilla/allmakefiles.sh
<Hobbsee> i wonder why that old version is there too
<Hobbsee> oh, i see
<asac> well allmakefiles.sh is unlikely to change often
<asac> which is why 0.94.0 might still work
<Hobbsee> yeah.  was comign to that conclusion
<asac> there is a bunch of old debian/configure* files as well
<asac> Hobbsee: at best don't try to fix things ... I wanted to redo the packaging at some point
<Hobbsee> asac: sure, OK
<asac> Hobbsee: not that we duplicate work ... do you have seamonkey et al in debian/control ?
<Hobbsee> asac: oh darn it, i presumably have to hardcode the value of thunderbird that we're now in too?  (as in, not 2.0.0.0)
<Hobbsee> asac: only in depends for enigmail
<asac> Hobbsee: ok
<asac> then its fine
<Hobbsee> Depends: thunderbird | iceape-mailnews | seamonkey-mailnews, ${shlibs:Depends}, gnupg
* asac should get this into bzr
<asac> Hobbsee: no ... i think it should just work
<asac> Hobbsee: e.g. no thunderbird version tweaking needed (i hope)
<Mithrandir> asac: did you make any progress on the "have all mozilla packages look in a common directory for plugins" idea I talked with you about earlier?
<Hobbsee> asac: build deps for enigmail arent satisfiable
<Hobbsee> bah.  it all blows up anyway.  i knew i shoul dhave left this one alone
<infinity> asac: Oh, hey, now that you work for us, can I point out that the enigmail packaging is complete CRACK? :)
<asac> infinity: well ... read above ;)
<asac> infinity: its in the making to clean this up
<infinity> asac: I always tried to be polite when it was a matter of community/debian outreach, but yeah.  Dude.  What were you on? :)
<asac> infinity: well ... the reason is that enigmail usually cannot be build outside thunderbird source tree
<infinity> asac: Oh, I undertand the reasons for the SDK tricks and such.
<asac> infinity: so i had to hack around all kinds of constraints ... too much ;)
<infinity> asac: It's the rules files with the 700 hardcoded ancient versions and stuff.  Aieee! :)
<asac> infinity: thats gone already
<asac> infinity: I had to introduce that for different mozilla suite flavours ;)
<asac> infinity: anyway ... i have a much better sdk now ... which i want to use soon
<infinity> asac: I just wanted to let you know that it was responsible for a large portion of my brain bleeding through my ear when I had to deal with it, that's all. :)
<asac> infinity: i just have to do it ;)
<infinity> asac: Now that you do all the mozilla stuff, I couldn't care less. ;)
<asac> infinity: be assured you are not alone :) ... it hunts me from time to time
<asac> infinity: but usually it works if you just don't touch it ;)
<infinity> asac: I had to touch it a few too many times. ;)
<infinity> asac: Security releases, tbird versions out of sync with Debian, splitting the source...
<asac> yes right ... but we all like challenges ... especially if you blame someone else ;)
<infinity> asac: And blame you I did!
<asac> s/you blame/you can blame/ :)
<infinity> asac: *grin*
<kagou> tkamppeter, have a look at #131521
* StevenK ponders annoying infinity some more.
<asac> Hobbsee: ok ... if it breaks for you just remind me every other day and I will update enigmail
<infinity> asac: Glad we actually hired someone who understands upstream, though. We've been in the dark about mozilla products since day 1, really.
<Hobbsee> asac: building the source broke.  i left it alone, at taht point :)
<Hobbsee> infinity: i get the impression that everyone except for mozilla themselves is in that basket :P
<infinity> StevenK: He's busy hating soyuz, then sucking up to Mithrandir.  He's not ignoring you. :)
<StevenK> infinity: Not much, anyway? :-)
<asac> infinity: well understanding upstream is not what i do ... I punch my brain until their thinking fits into it :)
<infinity> Hobbsee: It's not so much that upstream is all that weird, it's that they have such a huge number of products and contributors in a bizarre n:n relationship that it can be hell tracking changes and such.
<thom> infinity: more so at first than latterly ;0
<Hobbsee> true
<infinity> And trying to sort out of changes on a firefox branch might be something you want to apply to a thunderbird branch, or a mozilla branch, or... You lose a bit of your mind each time.
<infinity> s/sort out of/sort out if/
<TheMuso> oo/c
<TheMuso> ugh
<fabbione> pitti: i have almost done with that bug.. just re-testing a lot
<Riddell> TheMuso: this is interesting http://labs.trolltech.com/page/Projects/Accessibility/IAPoke  however I can't get it to talk to anything
<Riddell> there's a qdasher too
* pitti uploads his third and final dapper.2 SRU; mvo, happy verifying :)
<pitti> mvo: however, I think I made it easy for you: https://bugs.launchpad.net/ubuntu/dapper/+source/cupsys/+bug/57445/comments/15
<ubotu> Launchpad bug 57445 in cupsys "Printing not possible with line break or mis-interpreted encoding in job title" [Medium,Fix committed] 
<TheMuso> Riddell: Just a sec, I'll have a look at that page.
<Riddell> TheMuso: I suspect it needs the qt dbus accessibility bridge thing, and probably then may need your programme altered to use it
<TheMuso> Riddell: I am on my notebook right now, but when I get back to my desktop and large monitor, I will have a deeper look. Nice to see something for KDE like this.
<TheMuso> I've bookmarked it in any case.
<fabbione> pitti: #120177 back in your court.. fixed also in gutsy
<pitti> fabbione: yay
<fabbione> mvo: ^^ thanks for spotting that stuff
<lamont> seb128: doko: pitti: I was not aware of 131497.  sorry
<doko> lamont: fixed and uploaded
<TheMuso> o/c
<seb128> lamont: that's ok, doko fixed it ;)
<TheMuso> ugh orca keeps dying.
<lamont> doko: saw that
<fabbione> pitti: btw.. i am still digging trough the 7K emails from LP in the last 2 weeks. if there is anything urgent like this one please ping me
<doko> lamont: you owe me know a working gdb on hppa (and make that better a working gij as well) ;-)
<pitti> fabbione: I will; I'm currently reviewing the dapper point release bugs (and do a couple of SRUs and sponsoring myself)
<doko> s/know/now/ damn
<pitti> that's why I bother people on IRC so much today :)
<fabbione> pitti: ok thanks
<fabbione> pitti: you never bother me.. really
<lamont> doko: I'm hoping that we get offsets.h from jbailey today...
<lamont> seems he's a bit preoccupied with moving
<infinity> pitti: Sponsoring yourself? :P
<doko> lamont: let me know, have some gdb changes for gutsy here locally
<pitti> infinity: mathiaz :)
<infinity> pitti: Surely, we have some sort of policy against that kinda of thing...
<pitti> infinity: but wrt. my own dapper SRUs it's pretty easy to get approval for them :-P
<lamont> doko: the current blocker (AFAIK) is the lack of an offsets.h from the kernel, which other architectures provide.
<pitti> infinity: yeah, I don't abuse it usually
<infinity> pitti: (I'm happy to review anything that's more than a 3-character fix that you want looked at, BTW)
<pitti> infinity: that would be nice indeed
<pitti> infinity: I just did bug 58935, which is really trivial and easy to verify, too
<ubotu> Launchpad bug 58935 in hal "two hald-addon-storage  processes per pooled device" [Medium,Fix committed]  https://launchpad.net/bugs/58935
<infinity> pitti: Given how well we've proven that your reviews of my code work, it should surely work just as well in reverse! ;)
<pitti> infinity: and bug 57445, whose patch is more complicated (but I scrutinized it and tested it, too)
<ubotu> Launchpad bug 57445 in cupsys "Printing not possible with line break or mis-interpreted encoding in job title" [Medium,Fix committed]  https://launchpad.net/bugs/57445
<pitti> infinity: *cough*
<infinity> pitti: Okay, the hald diff looks obviously correct.
<geser> mvo: can you look at the debdiff in bug #131035 and tell if it's correct?
<ubotu> Launchpad bug 131035 in compizconfig-python "Doesn't depend on python, ships .a and .la files" [Undecided,Confirmed]  https://launchpad.net/bugs/131035
<infinity> pitti: "if (*value < ' '" looks odd to me.
<pitti> infinity: why?
<infinity> Is ' ' the first printable char in the ASCII table?
<pitti> infinity: yes (32)
<infinity> And, if so, why not 32? :)
<pitti> it's meant to filter out control characters
<infinity> Just seems stylistically odd, not broken.
<pitti> infinity: would that change the question? :-)
<pitti> yeah, I agree
<infinity> Less than space, more than 127...
* infinity shrugs.
<pitti> ctype.h FTW :)
<pitti> but I didn't want to deviate from what we have upstream and in Ubuntu since edgy
<infinity> Yeah.
<infinity> The escaping code looks sane to me.
<pitti> Mike contradicted himself with the "smaller than 254" limit
<pitti> i. e. should be "smaller than or equal"
<infinity> I assume that just print garbage for multibyte chars, but safely-escaped garbage, at least...
<pitti> but that's just a comment error AFAICS
<pitti> infinity: no, it makes gs fail
<pitti> infinity: it looks like
<pitti> %Title: a
<infinity> Oh, hahaha.
<pitti> b
<pitti> instead of "%Title: a%012b
<pitti> "
<pitti> meh, forget my quotes
<pitti> same with UTF-8 multibyte chars which happen to end with 10
<infinity> Anyhow, it looks sane to me, and I put more stock in testing than eyeballing.
<infinity> Eyeball reviews are just good for catching obvious "dude, that's backwards" stuff, IMO.
<pitti> yeah
<pitti> mvo: can you please have a look at my question in bug 47044? Thanks
<ubotu> Launchpad bug 47044 in apt "apt cant work with disable proxy" [Medium,Fix committed]  https://launchpad.net/bugs/47044
<seb128> Keybuk: could you look at bug #128257?
<ubotu> Launchpad bug 128257 in udev "Should include 'plugdev' group in permission.rules" [Undecided,New]  https://launchpad.net/bugs/128257
<mvo> fabbione: thanks for #120177!
<mvo> pitti: I make it a sru-verification afternoon I think :)
<asac> mvo: can you verify enigmail?
* asac -> lunch
<mvo> asac: what bugnumber? does it contain verification instructions?
<asac> mvo: bug #119038
<ubotu> Launchpad bug 119038 in enigmail "MASTER Key management / Recipient Key Selection broken (endless loop in EnigConvertToUnicode)" [Undecided,Fix committed]  https://launchpad.net/bugs/119038
<asac> mvo: ... verification instructions are on top of summary
<mvo> asac: thanks
<asac> mvo: the pleasure is on my side ;)
<fabbione> mvo: ok cool
<sabdfl> is there a key combination under X which will bring up a task manager to let you kill a rogue process?
<Fujitsu> sabdfl: Use Automatix :P It gives you the option to bind Ctrl+Alt+Delete for that, AFAIK
<sabdfl> much like ctrl-alt-del does in Windows?
<fabbione> sabdfl: not that I know off
<Hobbsee> kde used to.
<Hobbsee> for some reason, now it brings up the shutdown menu
<Hobbsee> it used to bring up ksysguard.
<fabbione> sabdfl: you can use gnome-system-monitor to get a list of tasks and end one of them.. not sure if there is a shortcut for it
<Riddell> Hobbsee: control-escape brings up ksysguard, as it always has
<Hobbsee> Riddell: ah right.  which i've now modified to xkill.
<pitti> hi mathiaz
<mathiaz> hi pitti
<mathiaz> pitti: thks for the quagga sponsor.
<pitti> np
<mathiaz> pitti: I've got another one - for samba.
<pitti> mathiaz: I was reviewing the dapper.2 bugs, and bug 84209 is still worrying me
<ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
<pitti> mathiaz: I'll probably forego that for dapper.2 unless the guy responds soon
<mathiaz> pitti: hum. I cannot reproduce it.
<pitti> mathiaz: yeah, I mean 'worrying' in terms of getting a fix for dapper.2
<mathiaz> pitti: yes. I'm not sure it's the same bug as the one he mentioned in his report.
<mathiaz> pitti: there is another debdiff that I prepared for mysql
<pitti> fabbione: wrt you multipath prerm script
<pitti> fabbione: shouldn't you use lt-nl instead of lt?
<pitti> fabbione: otherwise you'll run the special case instead of #DEBHELPER# on a fresh installation
<mathiaz> pitti: so if you drop bug 84209, we can publish an updated mysql-dfsg for dapper
<ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
<pitti> mathiaz: 'another'?
<pitti> mathiaz: I just know bug 118523
<ubotu> Launchpad bug 118523 in mysql-dfsg-5.0 "mysql server fails to start, claims /var/lib/mysql full" [Medium,In progress]  https://launchpad.net/bugs/118523
<mathiaz> pitti: yes. this one.
<pitti> mathiaz: right, that looked fine
<mathiaz> pitti: the debdiff hasn't been applied because we're waiting for bug 84209.
<ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
<mathiaz> pitti: we'll have to be publish a new mysql-dfsg for dapper.
<cjwatson> pitti: cdrtools/edgy-proposed failed to build 'cos I screwed up the patch; any objection to a trivial reupload?
<mathiaz> pitti: so if you decide to drop bug 84209 than we can publish a new mysql-dfsg for dapper.
<ubotu> Launchpad bug 84209 in mysql-dfsg-5.0 "subselect bug in amd64 compiled version" [Undecided,Fix released]  https://launchpad.net/bugs/84209
<pitti> cjwatson: please
<cjwatson> genius here forgot to adjust the line numbers
<pitti> mathiaz: right, let's do that then to get this going
<pitti> mathiaz: do you have an idea how to reproduce the original failure? mvo would love you if you could add a reproducer to the bug
<mathiaz> pitti: which bug are you talking about ?
<pitti> mathiaz: the BLOCK_SIZE one
<pitti> 118523
<mathiaz> pitti: hum... I'll try to come up with something.
<pitti> mathiaz: if it takes too long, don't worry, but if it's easy to reproduce it is good to have instructions
<mathiaz> pitti: a bug about samba was filled yesterday - bug 131419
<ubotu> Launchpad bug 131419 in samba "smb.conf contains valid users = %S in [global] " [High,In progress]  https://launchpad.net/bugs/131419
<mathiaz> pitti: it's a nasty one - but impacts only new install with the last samba package.
<mathiaz> pitti: I fixed the smb.conf file, but I wonder how I should handle the upgrade.
<pitti> mathiaz: mysql uploaded
<mathiaz> pitti: thks. :)
<infinity> mathiaz: Eww, did a broken merge move that from [homes]  to [global] ?
<mathiaz> infinity: nope. soren added some comment to clarify the homes section.
<mathiaz> infinity: it seems that he forgot to comment out the valid users option.
<infinity> mathiaz: Oh, [homes]  got commented, but the directive didn't.  I see.
<mathiaz> infinity: and it's actually duplicated.
<mathiaz> infinity: there are two entries for valid users
<infinity> mathiaz: If this bug was only in gutsy, I don't think it's worth worry about an upgrade path, TBH.
<mathiaz> infinity: only the second one is uncommented.
<mathiaz> infinity: ok. It will affect users that have installed a new samba.
<mathiaz> infinity: in the last 10 days or so.
<infinity> mathiaz: Sure, but only people running gutsy who've installed samba in.. The last week?  When did it break?
<infinity> Kay.
<infinity> That's not worth the postinst cruft to fix it, IMO.
<mathiaz> infinity: it broke on 16 Jul 2007
<infinity> mathiaz: Well, then, if you really want to fix it, here's what I'd do:
<infinity> Check if you're upgrading from a version >= the broken one
<infinity> grep the config file for two occurences of "valid user"
<infinity> If both conditions are met, blindly sed the thing into oblivion. :/
<infinity> Oh, and make that >= the broken one, and <= the fixed one.
<infinity> So you don't even dare run that code after this week.  Just in case it breaks someone's valid config.
<Fujitsu> It's Gutsy, it's allowed to munge your config files.
<infinity> Fujitsu: It's never allowed.
<mathiaz> infinity: yeah... that seems a little bit complicated.
<mathiaz> infinity: because you wanna grep only in the [homes]  section
<pitti> erm, just to make sure, we are not talking about a conffile here, right?
<infinity> mathiaz: It's not that complicated.  It all depends on how bad you think the bug is.
<mathiaz> pitti: it's a conffile - smb.conf.
<infinity> pitti: No, debconf-written config file.
<pitti> ok
<infinity> It's not a dpkg conffile.
<mathiaz> infinity: ok.
<infinity> adconrad@cthulhu:~$ dpkg -S /etc/samba/smb.conf
<pitti> mathiaz: conffile -> shipped in .deb and auto-upgraded and handled by dpkg
<infinity> dpkg: /etc/samba/smb.conf not found.
<infinity> See?
<pitti> mathiaz: configuration file -> created by maintainer scripts and not owned by a package
<pitti> mathiaz: and it is a dead sin to *ever* touch a conffile in any maintainer script
<mathiaz> pitti: hum. ok. But there is a smb.conf in the debian/ directory.
<infinity> pitti: If it was a conffile, I wouldn't even worry about fixing it anyway, since dpkg would prompt, and the user can get stuffed it they don't care about checking the diff.
<pitti> infinity: that's what I meant
<infinity> (I've broken this rule before)
<infinity> (using md5sums in preinsts, and other hideous hacks)
<infinity> (don't do this at home, kids)
<infinity> Pretty sure initramfs-tools has an example of such scariness.
<mathiaz> infinity: ok. Thks.
<pitti> I did that a lot for moving conffiles between packages
<mathiaz> it seems that it's not worth the trouble.
<pitti> /var/lib/dpkg/info/hal.preinst FTW
<infinity> pitti: Is it sad that we brag about the ways we've violated policy creatively enough to get away with it?
<StevenK> infinity: YES.
<pitti> infinity: that script doesn't break that rule
<pitti> infinity: it only avoids dpkg questions for unmodified conffiles, it never actually touches them :)
<mathiaz> infinity, pitti: could you sponsor my fix for samba ?
<infinity> pitti: I sed a conffile to unbreak the fact that another package modified it against policy. :P
<infinity> mathiaz: I would like nothing more.
<infinity> pitti: Aww, that code's gone now, since the mkinitramfs->initramfs-tools transition, that's right.  There go my bragging rights.
<infinity> pitti: Basically, I put the shipped config back in place, let dpkg think everything was okay, then converted the conffile to a config file and wrote the correct value out again.
<infinity> pitti: And died a little inside as I was writing that.
* pitti resists the temptation to think about this more deeply
<infinity> Then again, the pkgbinarymangler preinst is about the scariest thing ever too, maybe I'm just psychotic.
<pitti> eww, indeed
<infinity> if [ ! -x /usr/bin/dpkg-deb ] ; then
<infinity> # on initial install, we have no dpkg-deb, cause we just diverted it
<infinity> cp /usr/bin/dpkg-deb.pkgbinarymangler /usr/bin/dpkg-deb
<infinity> fi
<pitti> infinity: I think this beast can be pretty much dropped, though
* infinity giggles.
<infinity> pitti: What can be dropped?
<pitti> infinity: the conffiles migration at least
<infinity> Oh, yeah. :)
<seb128> pitti: is "restricted-manager --check-composite" opening a dialog "nvidia hardware not available" when having an ATI card a known issue?
<pitti> infinity: what's that "remove old diversion" about?
<pitti> seb128: not known to me, and I didn't see a bug report about it
<pitti> seb128: it's about a week since I checked the r-m bugs last, though
<seb128> pitti: ok, I'm reassigning one to you we got on the appareance capplet and I can confirm it
<infinity> pitti: Moving the diversion from pkgstriptranslations to pkgbinarymangler.
<pitti> seb128: merci
<pitti> infinity: ah, right; that can go now, too, I think
<infinity> pitti: Yeah, the only bit that needs to stay is the "dpkg-deb doesn't exit, dpkg is about to die, aieeee!" voodoo.
<infinity> pitti: But the migration code wasn't hurting anyone, so whatever.
<norsetto> seb128: salut, have you seen my email about mentoring status?
<seb128> hi norsetto
<pitti> bdmurray: can I gently poke you about bug 68553?
<ubotu> Launchpad bug 68553 in python-apt "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Fix committed]  https://launchpad.net/bugs/68553
<infinity> mathiaz: That offer was time-limited.  I'm about to cut out for the day (it's midnight)...
<mathiaz> infinity: that's ok. pitti just sponsored my upload.
<infinity> Ahh, snazzy.
<pitti> mathiaz: not samba
<pitti> ENOTIME, sorry
<seb128> norsetto: I did reply to the previous mail some weeks ago than I didn't notice him doing any work, any reason you send mails again after that?
<mathiaz> pitti: hum. correct...
<pitti> BenC: can you please ping me once you are awake, so that we can go through the dapper.2 bug list?
<seb128> norsetto: is there a way to note that I'm not mentoring it somewhere? ;)
<norsetto> seb128: just checking again; so he dropeed?
<StevenK> infinity: You can't look at libnss-db? :-)
<infinity> mathiaz: Well, give me your diff/dsc, quick-like. :P
<alex-weej> apport retracing just did this http://launchpadlibrarian.net/8771344/Stacktrace.txt
<alex-weej> does it not work for gutsy yet?
<norsetto> seb128: just tell me and I tick you off; should I keep the slot for somebody else?
<infinity> StevenK: I'll go over it on the weekend and either upload it, fix and upload it, or bounce more annoyances at you.
<seb128> norsetto: no news from him no, I can send you a copy of the previous mail if you want, he didn't manifest himself since
<pitti> alex-weej: in general it does
<pitti> alex-weej: but it sometimes fails, when no debug symbols are available and such
<seb128> norsetto: I'm happy to mentor somebody else yes
<StevenK> infinity: Personally, I'd prefer to upload it, I just want a second pair of eyes over it.
<mathiaz> infinity: http://launchpadlibrarian.net/8765965/samba_3.0.25b-1ubuntu2.debdiff
<pitti> alex-weej: those bugs are auto-tagged, I'll have a look at them every now and then
<pitti> back in 20 minutes
<norsetto> seb128: good! I'll take him off then, and I'll send him an email to check what happened anyway
<alex-weej> pitti: ok, cool
<seb128> mathiaz, infinity: you are working on samba? Do you have an opinion on 'net usershare'?
<seb128> norsetto: thanks, do you want me to reply to your mail so you have the reply somewhere?
<infinity> seb128: An opinion in what regard?
<norsetto> seb128: yeah, perhaps it is better (you know Daniel ;-))
<cjwatson> infinity,pitti: I see your /var/lib/dpkg/info/hal.preinst and raise you /var/lib/dpkg/info/openssh-client.preinst
<seb128> infinity: https://lists.ubuntu.com/archives/ubuntu-devel/2007-January/023128.html
<infinity> cjwatson: I assume the conffile moving, not the OH GOD, WHAT'S ALL THAT key spew? :)
<pitti> cjwatson: dear, is this the entire Debian key ring or so? :)
<cjwatson> infinity: it's not even so much moving it, it's convincing sarge's dpkg that yes, it's OK for this conffile to be moved between packages and no, please god don't give the user a deeply confusing prompt
<cjwatson> pitti: /etc/ssh/moduli ...
<cjwatson> it has a manual page and everything, moduli(5)
<mathiaz> seb128: seems interesting.
<pitti> ah
<infinity> mathiaz: Verified and uploaded.
<cjwatson> I am so glad dpkg is fixed now
<mathiaz> infinity: thks.
<infinity> seb128: That's pretty light on technical detail.
<mathiaz> seb128: is the extension already integrated ?
<infinity> seb128: But I'd be happy to look into the sanity of it.
<mathiaz> infinity: the man page has more information.
<mathiaz> infinity: it relies on a directory where members of a specified group can write to.
<mathiaz> infinity: I guess that net usershare will create symlink there, or something like that.
<infinity> mathiaz: Yeah, reading it now.
<infinity> mathiaz: So, a config file change, and a directory in /var/lib/samba...
<mathiaz> infinity: yop.
<seb128> mathiaz: no, it's not inegrated. You can have a look to the nautilus-share README if you want, there is a recommend samba configuration
<mathiaz> infinity: we just need to figure out the group thingy.
<infinity> seb128: Should this be an "all users" thing, or just admin users?
<infinity> seb128: Cause, sadly, we don't add users by default to a users group.
<seb128> infinity: I'm happy to discuss it, ideally anybody
<infinity> seb128: Our lack of a users group is a killer for this one.
<seb128> infinity, mathiaz: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/128548
<ubotu> Launchpad bug 128548 in samba "Enable net usershare?" [Undecided,New] 
<infinity> seb128: Because we don't want that directory world-writeable.
<seb128> infinity: can't we use the samba group?
<cjwatson> infinity: we have a users group, we just don't put ordinary users in it for some reason
<mathiaz> seb128: is there a allowed to share permission ?
<infinity> Yeah, soren's with me on this one.
<infinity> cjwatson: Well, yes, that's what I meant.
<infinity> cjwatson: We inherited it from base-passwd, but we don't USE it.
<cjwatson> (also users has the wrong gid but that's a bit hard to fix now)
<infinity> cjwatson: Wrong gid?  It's been 100 since the dawn of time.
<cjwatson> it's a global static group, the range is 0-99
<cjwatson> yes, the bug has existed since the dawn of time
<infinity> cjwatson: I suspect the policy was made after the group, so who wins? :)
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=25882
<ubotu> Debian bug 25882 in base-passwd "base-passwd: avoid uid/gid 100" [Normal,Open] 
<infinity> Ahh, 5-digit bug reports, how I miss you.
<mathiaz> seb128: in the user and group management, you can set user privileges, right ?
<seb128> mathiaz: yes
<mathiaz> seb128: could it be possible to add a new privilege there ?
<seb128> yes
<seb128> that's very easy
<mathiaz> seb128: it maps to unix groups behind the scene right ?
<seb128> correct
<infinity> mathiaz: Ahh, yes, that might do nicely.
<infinity> "Allow the user to manage network shares" or so.
<infinity> And create an smbnet group or something.
<mathiaz> infinity: yeah.
<mathiaz> seb128: is it possible to specify default privileges for users ?
<infinity> smbshare, whatever seems okay.
<infinity> If you add users through that control panel, they get a default set of groups/privs, I believe.
<seb128> mathiaz: yes, we already do that
<infinity> If you use adduser raw, you're on your own, of course.
<infinity> And upgrades won't get users in this group.
<infinity> Always a problem, but nothing we can do anything about.
<seb128> mathiaz: we have a desktop profile which list groups for a standard desktop user
<mathiaz> seb128: does the group need to exist ?
<infinity> It would have to.
<seb128> mathiaz: not sure, I need to check
<infinity> On the backend, it just uses "adduser user group", which will bail if the group doesn't exist...
<mathiaz> infinity: yeah. of course...
<mathiaz> hum. Which package should create the smbshare group then ?
<infinity> (And rightfully so, since group membership is handled in /etc/groups.. Next to the group name.. :P)
<mathiaz> is samba installed by default on the desktop ?
<infinity> samba-common's on the desktop by default.
<infinity> And samba-common's the right place for the group anyway.
<mathiaz> so samba-common should create the smbshare group.
<infinity> It's where all of samba's config magic lives.
<mathiaz> and then we can add a privilege for the user and group applet.
<infinity> And samba-common should also own /var/lib/samba/smbshare, root:smbshare, 1770
<Lutin> pitti: can you give-back gok -0ubuntu2 on ppc, i386, amd64 please ?
<infinity> cjwatson: Is it worth having this group in base-passwd, so it always exists?
<mathiaz> infinity: how should upgrade be handled ?
<infinity> cjwatson: I've always been fuzzy on that policy.  base-passwd inclusion is required (or encouraged) if more than one package will rely on the group, right?  Which would be the case here (samba and the GNOME stack)
<infinity> mathiaz: Not at all.  You can't add users to groups on upgrades.  We just suffer.
<mathiaz> infinity: I mean the samba options bits
<mathiaz> infinity: we need to add options to smb.conf.
<mathiaz> infinity: that would go in the postinst script ?
<infinity> mathiaz: Same argument, really.  Besides, if it's not a fresh install, you won't be in the right groups, so who cares if samba's configured for it? :)
<mathiaz> infinity: well. If we add a new user privilege and user enable the user privilege, it should work.
<infinity> mathiaz: (You could use some postinst hackery to insert the appropriate lines, but you need to be careful about it, that's all)
<infinity> mathiaz: the current postinst already shows how to mangle the config file (which it does on every new install, based on debconf values), so it's not a bad starting point.
<mathiaz> infinity: ok. I get your point.
<infinity> mathiaz: vorlon and I had a good cry over some of the sed expressions in that postinst when we were tweaking it. :)
<cjwatson> infinity: base-passwd inclusion is required if something hardcodes the uid/gid in code for whatever mad reason; it's strongly discouraged otherwise
<cjwatson> infinity: each package that uses it should just adduser --system it if it isn't there
<infinity> cjwatson: Kay, so the gnome shares-admin thingee should adduser it as well, then, problem solved?
<cjwatson> no reason why it needs to be done by just a single package
<cjwatson> sounds good
<infinity> seb128: ^^
<cjwatson> we try to avoid too many static groups because they have to exist on every system and the id space is running a bit short for that
<infinity> cjwatson: Yeah, fair enough.
<cjwatson> the not-created-by-default static range somewhere up in high id space helps with that, but you've got to adduser that anyway, so just using --system should be fine
<infinity> cjwatson: The reason I asked was because of "plugdev" which, being a recent addition to the flock, I would have assumed had no need for a static gid, so I figured it must have some other reason for being there.
<cjwatson> plugdev got created because the installer needed it
<seb128> infinity: looks good to me
<infinity> Ahh.
<cjwatson> and at the time I think we thought it needed to hardcode the id in fstab
<seb128> infinity: so samba can be changed to use usershare and nautilus-share has to add the user when installed?
<cjwatson> I think you can use a group name in some places in fact, but the gid is safer
<infinity> seb128: Alright, feel free to "getent group smbshare || adduser --system smbshare" in the shares-admin postinst, then.
<infinity> seb128: And mathiaz or I can work on making samba do something useful with that.
<cjwatson> I'm also trying to avoid creating new global static ids until I get round to debconfifying base-passwd
<seb128> infinity: nautilus-share is the package using it, thanks ;)
<infinity> cjwatson: The "here's what I want to change, bring it?" prompt is being debconfified?
<infinity> cjwatson: That might not present well...
<infinity> cjwatson: Which I suppose might be why it's not been done yet. :)
<cjwatson> pitti: new cdrtools/edgy-proposed uploaded to fix the build failure; please accept
<cjwatson> infinity: precisely, it needs to be a bit more clever than that
<cjwatson> and, being where base-passwd is in the dependency tree, it also needs some rather weird tricks to use debconf
<cjwatson> ideally from C ...
<infinity> Speaking of...
<infinity> How goes the debconf->cdebconf battle on the Debian front?
<cjwatson> they're coinstallable now (have been for a while), which makes it much less of a flag-day issue
<cjwatson> still some more features to add to cdebconf to bring it to parity, though
<infinity> I still look forward to the day that I can have cdebconf rule my buildd chroots.
<infinity> Although, wait, coinstallable?  Does that mean there's some clever passthrough action where cdebconf does all the heavy lifting until its asked to do sometihng it doesn underestand?
<infinity> Cause that would be nice...
<infinity> Or much less useful than that? :)
<pitti> cjwatson: thanks
<cjwatson> no, I just mean they install into different bits of the filesystem so they don't conflict, and there's a DEBCONF_USE_CDEBCONF environment variable that makes the debconf confmodule start cdebconf instead
<cjwatson> though you probably still need to set up something to create the cdebconf database
<infinity> Ahh, okay, much less useful/cool, then.  Shame.
<pitti> Lutin: done
<Lutin> pitti: thanks
<cjwatson> but yes, given that it ought to be possible to at least try out cdebconf in a normal system
<cjwatson> there's nothing to say "if this package depends on debconf and not cdebconf then you REALLY need to use debconf for it"
<cjwatson> which is sort of fundamentally hard
<cjwatson> I think the only missing thing any package actually uses is probably capb escape, which I'm working on sporadically for ubiquity anyway
<niemeyer> Hey everyone
<mvo> hey niemeyer!
<niemeyer> mvo!
<niemeyer> mvo: How're things going in the far north? :)
<pitti> tkamppeter: so, do you think that cups 1.3 would buy us much? quite risky IMHO, with it not being released yet and we cannot yet use too many of the new features; WDYT?
<niemeyer> Would anyone familiar with packaging on amd64 be available for a quick question?
<mvo> niemeyer: you mean so close to the north pole :P very nice! a bit hectic because of the tribe-4 release from yesterday, but otherise things are shaping quite nicely
<pitti> niemeyer: packaging isn't amd64 special, but better just ask instead of asking to ask :)
<mvo> niemeyer: ask your question, plenty of talented people around :)
<niemeyer> Well, it's a pretty basic one, so I'm a bit ashamed of my ignorance on the topic ;-)
<niemeyer> So..
<infinity> Ooo, I like shameful questions.
* mvo opens the Quotes page (just in case :P
<niemeyer> I imagined that if we provide an i386 package, it'd be installable in an amd64 machine, but apparently apt is refusing to install it on someone else's system
<infinity> Yeah, you can't do that.
<cjwatson> niemeyer: It is not; multiarch is an ongoing plan that isn't done.
<cjwatson> niemeyer: it's really easiest to just build for amd64 as well
<infinity> There's no way to express that your i386 package depends on i386 libraries which would need to live somewhere else in the filesystem from the native amd64 libraries.
<niemeyer> Ok.. but the actual binary should work there, right?
<infinity> So, you just want to build your package for amd64 and provide both.
<infinity> niemeyer: Is there any reason you want it to be an i386 binary on amd64?
<cjwatson> niemeyer: possibly or possibly not, depending on what libraries it uses and whether i386 versions of those are installed on the system for some other reason
<niemeyer> infinity: Right.. I remember these tricky details from past rpm times
<niemeyer> infinity: Not really.. just brainstorming to see what'll be the best way to do it..
<niemeyer> I guess we'll need PPAs now
<infinity> niemeyer: The best way is to build for all your target architectures, IMO.
<geser> pitti, tkamppeter: can something be done about but #125300 as it breaks direct PDF printing?
<niemeyer> infinity: Yeah, true
<niemeyer> Cool
* infinity points niemeyer vaguely at another window where he's nick higlighted.
<infinity> s/hig/hi/
<pitti> geser: oh, absolutely!
<pitti> geser: no idea what happened to the conffile, but if it works well without, I'll fix it in Debian and merge it
<bddebian> Heya
<geser> at least it prints again
<niemeyer> infinity, cjwatson: Thanks for the information guys..
<pitti> geser: E [10/Aug/2007:16:57:17 +0200]  [Job 4]  pdftops-options: -cfg /etc/cups/pdftops.conf
<pitti> E [10/Aug/2007:16:57:17 +0200]  [Job 4]  pdftops_path exited with signal 127,
<pitti> E [10/Aug/2007:16:57:17 +0200]  [Job 4]  Empty print file!
<pitti> geser: ^ liek that?
<bddebian> seb128: Sorry, for bug #131326 I buried the reasons that they aren't necessary inside the Ubuntu changelog entry
<ubotu> Launchpad bug 131326 in ivtv "[Sync Request]  ivtv 0.10.5-2" [Wishlist,Fix released]  https://launchpad.net/bugs/131326
<fabbione> pitti: you don't use prerm on a fresh installation .. ?
<pitti> fabbione: hm, true that
<pitti> fabbione: my bad then
<seb128> bddebian: I read several time the text and I didn't see any mention of "Switch all 0.8's to 0.10" in the Debian changelog
<fabbione> pitti: even if you run it, it's ok to exit 0 since there is no daemon to stop
<bddebian> seb128: Give me one sec
<bddebian> seb128: ivtv (0.10.1-2) unstable; urgency=low
<bddebian>   [ Ian Campbell ] 
<bddebian>   * Update debian/control to corectly refer to the 0.10 release.
<pitti> fabbione: done
<seb128> bddebian: you didn't mention that on the bug
<fabbione> pitti: ok cool. thanks i am off :)
<pitti> fabbione: bye, have a nice weekend
<seb128> bddebian: there is lot of syncs request, could you try to include all the required informations when you file one?
<geser> pitti: it prints again if I modify /usr/lib/cups/filter/pdftops line 107 to $cmdopt = "";
<bddebian> seb128: I was not specific enough, yes, I have apologized twice now.  But I did state that it was fixed in 10.1-1/2
<pitti> geser: yep, I'm at it
<pitti> geser: thanks for pointing
<seb128> bddebian: ok, sorry to mention it again, you should probably just use the requestsync tool ;)
<bddebian> pfft :-)
<bdmurray> pitti: is "The fix can be verified by trying a dapper upgrade from dapper->edgy with finish locales." the steps to reproduce?
<bddebian> I think I probably should have just stayed away :-)
<seb128> bddebian: what? it's very nice, include details like the changelog and if the package is an universe one
<pitti> bdmurray: mvo would know better, I think
<pitti> bdmurray: according to comment 9 that would be it
<mvo> bdmurray: what bugnumber is that? sorry if the instructions are bad, I will improve them before you continue
<bddebian> Hmm, would requestsync work over my ssh connection or does it require a browser?
<seb128> bddebian: sync done, thanks for the bug ;)
<seb128> bddebian: don't bother for this one, you can try next time
<pitti> bddebian: requestsync sends mail
<bddebian> Heh, NP, I'll do better, thanks
<bddebian> pitti: That's what I thought and I don't have mail set up on that box :-(
<pitti> bddebian: not necessary, it SMTPs directly to ubuntu.com's NX :)
<pitti> bddebian: MX even
<bddebian> Ohh, nice
* bddebian thinks it sucks getting old AND being stupid
<pitti> geser: I get the same error message with that, though
<geser> pitti: I get here now: PID 11635 (/usr/lib/cups/filter/pdftops) exited with no errors.
<geser> but it still doesn't print :(
<cjwatson> pitti: can I upload debian-installer to dapper-proposed to pick up that hw-detect SRU proposal?
<bdmurray> mvo: it is bug 68553
<ubotu> Launchpad bug 68553 in python-apt "Dapper upgrade to Edgy: Frozen dist-upgrade and failed second run (in Finnish locales" [High,Fix committed]  https://launchpad.net/bugs/68553
<pitti> cjwatson: that would be good; I asked for that in the bug; if we can sensibly build CDs from that and copy it to -updates later?
<geser> pitti: I've to run the pdf through pdf2ps and print then the ps file
<cjwatson> pitti: oh, I missed the bug comment
<mvo> bdmurray: I updated the instructions, they invole a upgrade, I can write a python-testcase if you do not have a dapper vm around and do not have the time to install one
<geser> mvo: can you look at the debdiff in bug #131035 and tell if it's correct?
<ubotu> Launchpad bug 131035 in compizconfig-python "Doesn't depend on python, ships .a and .la files" [Undecided,Confirmed]  https://launchpad.net/bugs/131035
<mvo> geser: thanks, I'm in the middle of updating that to current git, I will incoperate it into the package
<bdmurray> mvo: I have a dapper vm so should be set
<geser> mvo: thanks
<mvo> bdmurray: oh, it will still take long to verify, but it should be mostly non-interactive after you clicked on "upgrade"
<bdmurray> mvo: and it needs verification for edgy also correct?
<pitti> geser: I'm trying: /usr/lib/cups/filter/pdftops 1 martin 'test' 1 '' test.pdf
<pitti> geser: and with your change it exits cleanly here, fails with current gutsy version; hmm
<pitti> geser: I wonder why it fails when called by cups
<mvo> bdmurray: yes
<pitti> bdmurray: thanks; at least you can say that, after this, you fixed *all* of your assigned dapper.2 bugs :-P
<norsetto> seb128: do you have thilo's email? I can't find it in our record.
<seb128> norsetto: what email?
<norsetto> seb128: his (thilo) email?
<pitti> geser: oh, *headdesk*, my bad; bad apparmor rules
<seb128> norsetto: email address you mean?
<norsetto> seb128: err, yes?
<geser> pitti: when I try your command and and save the generated postscript to a file and try to view it with evince I get GPL Ghostscript 8.60: Unrecoverable error, exit code 1 (print this file doesn't also work)
<pitti> geser: hm, but that's a gs bug then
<geser> ok
<pitti> geser: does another pdf work?
<pitti> mathiaz: REJECTING m access to /usr/lib/perl/5.8.8/auto/POSIX/POSIX.so (foomatic-rip(19010) profile /usr/sbin/cupsd
<pitti> mathiaz: ^ this sounds like a good addition to the perl abastraction
<Lutin> pitti: can you give-back cairodevice and foreign amd64, ppc please ?
<pitti> Lutin: done
<geser> pitti: I get the same error when I try it with an other PDF
<pitti> geser: do you have -3ubuntu1?
<geser> pitti: both times i get Error: /configurationerror in --setpagedevice-- before the gs stack
<Lutin> thanks pitti :)
<geser> pitti: cupsys         1.2.12-3ubuntu1
<pitti> geser: dmesg | grep 'REJECTING.*cups' ?
<geser> pitti: nothing in dmesg but I still run the feisty kernel as the gutsy one is missing the wifi drivers for my card
<pitti> geser: ah, so it's not apparmor then
<geser> running the same pdf through /usr/bin/pdf2ps produces a ps file which can be viewed with evince but not the one created with /usr/lib/cups/filter/pdftops
<pitti> geser: oh, interesting; is the diff comprenehsible?
<geser> pitti: I'd say no: 1 file changed, 873 insertions(+), 2180 deletions(-)
<pitti> geser: erk
<geser> the one generated by pdf2ps is 60k bigger
<pitti> geser: so, we should debug how cups' pdftops wrapper calls /usr/bin/pdftops
<pitti> and find the option that breaks it
<patate> hi, I'm trying to build some packages... and I wonder... if there is any way to apt-get install package and make sure it won't start/restart or mess with running process
<patate> like chroot'ing into an installed ubuntu system
<patate> and apt-get install apache
<patate> but I don't want it to restart or start apache and impact the apache in the host system
<cjwatson> chroots aren't sufficiently safe to be certain of anything, but I think it should be considered a bug if it touches the host system's apache
<cjwatson> I think apache uses a pidfile to avoid that problem
<patate> by default, installing a package... the installed service is trying to start
<patate> like... debootstrap is not trying to start anything
<patate> but it do apply all post-install script correctly
<geser> pitti: I get the same postscript file when I use /usr/bin/pdftops instead of the pdftops wrapper
<pitti> geser: huh? how can one work and the other not then?
<geser> ghostscript: /usr/bin/pdf2ps and poppler-utils: /usr/bin/pdftops
<pitti> geser: ah, I see
<pitti> geser: so it is a ghostscript bug after all
<ion_> patate: I havent checked, but perhaps invoke-rc.d checks whether its being run in a chroot.
<patate> ion_: but you can't invoke-rc.d something that had not been installed yet
<patate> I want to prevent a package to start itself after installation
<ion_> Try on a support channel.
<geser> pitti: uses poppler ghostscript internally?
<patate> ok
<pitti> geser: no, it uses the xpdf code
<geser> the pdf2ps from ghostscript produces printable postscript but not pdftops (used by cups)
<pitti> geser: ah, so it's this way around; right, cups' wrapper calls the poppler one
<cjwatson> patate: putting the following in /usr/sbin/policy-rc.d may help:
<cjwatson> #! /bin/sh
<cjwatson> exit 101
<cjwatson> see /usr/share/doc/sysv-rc/README.policy-rc.d.gz
<pitti> geser: indeed, confirmed here
<cjwatson> pitti: d-i on its way into the dapper-proposed queue now; please accept when it's therer
<cjwatson> there
<pitti> cjwatson: will do, thank you
<cjwatson> I *think* it should build against -proposed by itself, but if it doesn't, please fix since I'll probably be on vacation :)
<pitti> cjwatson: I'll check the hw-detect version in the build log/manifest/whatever
<cjwatson> thanks
<pitti> geser: so does removing the -cfg option actually have any effect? I don't see a difference here (but I don't get that verbose error message you get, either)
<pitti> geser: anyway, I fixed it in Debian's trunk to check for the file before supplying it; can't hurt
<pitti> geser: can you please file a poppler bug about pdftops?
<geser> pitti: I see that my printer gets some data submitted
<geser> pitti: will do
<pitti> geser: thank you
<geser> pitti: downgrading libpoppler1 and poppler-utils to 0.5.4-6ubuntu1 (the version before the current one) produces printable postscript
<pitti> geser: good data point
<bryce> morning
<pitti> hey bryce
<Hobbsee> hi bryce
* Hobbsee is starting to conclude that coding at 2am isnt the smartest idea in the world.
<geser> pitti: about the -cfg option: diff the output between pdftops from poppler-utils 0.5.4 and the pdftops from 0.5.9 shows:
* mvo waves to Hobbsee
<Hobbsee> heya mvo!
<geser> +  -preload            : preload images and forms
<geser> -  -cfg <string>       : configuration file to use in place of .xpdfrc
<pitti> geser: ah-ha
<pitti> geser: so that cupsys fix should at least help a bit, but if it produces wrecked postscript, it won't get very far
<LaserJock> hi Hobbsee
<Hobbsee> heya LaserJock
<LaserJock> Hobbsee: what time is it there?
<Hobbsee> LaserJock: 2.30am?
<LaserJock> hmm
<geser> pitti: http://paste.ubuntu-nl.org/33252/ is the diff between the postscript file created once with pdftops from 0.5.4 and once with pdftops from 0.5.9
<pitti> geser: please add that to the poppler bug, too
<pitti> wow, that bounding box looks broken
<Hobbsee> LaserJock: it's not *that* late.
<nixternal> it must be nice to be able to stay up that late and wake up early still :)
<Hobbsee> nixternal: wake up early?  what's that?
<nixternal> hehe
<Hobbsee> nixternal: i dont have work tomorrow mornign, it's all good.
<nixternal> lucky you
<Hobbsee> i just have it tomorrow night
<Hobbsee> hopefully they'll be someone with me.
<geser> pitti: filed as bug #131591
<ubotu> Launchpad bug 131591 in poppler "pdftops from poppler-utils 0.5.9-0ubuntu1 produces broken postscript" [Undecided,New]  https://launchpad.net/bugs/131591
<pitti> geser: thank you
<pitti> I'm off now, have a nice weekend everyone
<highvoltage> hello jono
<jono> hey highvoltage
<LaserJock> hi jono
<keescook> Hobbsee: is main unfrozen?
<Hobbsee> keescook: i assume so.
<keescook> Hobbsee: okay, cool, thanks.
* Hobbsee wasnt doing RM this time, due to assignments
<LaserJock> stupid school ;-)
<norsetto> seb128: sebastien, perhaps you may want to look at bug 131584. I think it is invalid (marked it so already).
<ubotu> Launchpad bug 131584 in compiz "compiz.wrapper not pretty with bash" [Undecided,Invalid]  https://launchpad.net/bugs/131584
<mvo> "not pretty" ey? :P
<cjwatson> norsetto: 'echo "\n"' isn't POSIX; you're mistaken
<highvoltage> not even with -e ?
<cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
<norsetto> cjwatson: I checked the standard
<cjwatson> highvoltage: -e is not portable
<cjwatson> norsetto: not closely enough
<cjwatson> "It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted."
<highvoltage> cjwatson: ah
<norsetto> yes, that; didn't I read it correctly?
<cjwatson> Debian policy explicitly amends that for all our shells to require -n
<cjwatson> norsetto: "\n" is an escape sequence and therefore cannot be used in portable code
<cjwatson> policy> ... but says nothing about -e or escape sequences
<cjwatson> either just 'echo' without arguments (possibly twice) or use printf
<cjwatson> I've reopened the bug
<norsetto> cjwatson: I don't understand, the policy explicitely mentions /n?
<minghua> I remember printf should work instead of echo -n.
<norsetto> cjwatson: sorry, I mean, the posix spec
<cjwatson> norsetto: I am not sure how this is unclear?
<cjwatson> Debian policy explicitly exempts -n, but escape sequences in echo are still disallowed
<cjwatson> (phone)
<Riddell> asac: is gnash going to be default in gutsy?
<asac> not on the CD
<asac> it will show up in plugin finder dialog
<asac> next to flashplugin-nonfree
<asac> hopefully in gutsy+1 its in a state that we can make it default without confusing users that don't know anything about gnash vs. flashplugin-nonfree
<mvo> geser: compizconfig is merged into bzr, should I sponsor the upload
<norsetto> cjwatson: what I mean is that echo -n is not posix, but admitted by the Debian policy ( I read is the only exception), but echo "\n" IS posix
<geser> mvo: yes, please
<cjwatson> norsetto: echo "\n" is not POSIX
<norsetto> cjwatson: in any case, the problem is the fact that the users symlink /bin/sh to bash
<cjwatson> norsetto: it is an XSI extension
<cjwatson> norsetto: that is NOT a problem
<cjwatson> please do not reject bugs on that basis!
<cjwatson> that is explicitly supported
<norsetto> cjwatson: I'm glad I checked, don't get too excited :-)
<cjwatson> I'm not excited, but you started using capital letters ;-)
<norsetto> cjwatson: WHO USED CAPITAL LETTER?
* Amaranth blames mvo
<norsetto> :-)
* mvo whistles incocently
<pygi> mvo, what you did this time? :)
<norsetto> hey take it easy with mvo, he still owes me two emails
<mvo> norsetto: *cough* mailbacklog *cough*
* mvo runs away screaming
* norsetto tries to calm mvo down, pats him gently on the shoulders, buys him a glass of beer .....
<seb128> norsetto: thanks, look like other people already commented
<norsetto> seb128: did they? I didn't notice .....
<bryce> mvo, have you heard anything about the zero-copy TFP feature in xserver 1.4 giving improvements to compiz performance?
<mvo> norsetto: tea helps me best usually
<Caesar> Can I get a crash course in looking up Ubuntu bugs?
<mvo> bryce: yes - that would only be for intel, right?
<Caesar> Like I've just found issues with vol_id in dapper
<Caesar> How can I find out when and if that's been fixed in subsequent releases?
* mvo goes to preare some matcha tea
<bryce> mvo, intel and one of the radeon chipsets
* norsetto scratches his head and wonders if mvo is not really insane after all
<Caesar> Actually, it's probably an upstream bug...
<bryce> mvo, r300 and intel
<Hobbsee> mvo: try rm -rf'ing all the mail.
<Hobbsee> seems to work here
<Hobbsee> (on sponsorship mail, at least!)
<seb128> norsetto: the bug has been reopened with a comment from Colin
<norsetto> seb128: really!?
<norsetto> seb128: just kidding, I'm still licking my wounds, colin is a tough juggler ....
<mvo> bryce: I was not aware of r300. my understanding is that it only helps on uma cards, does the r300 support that?
<Hobbsee> norsetto: he bites :P
<norsetto> Hobbsee: that double nelson was a killer, let me tell you
<Hobbsee> :P
<Hobbsee> right, goodnight for real this time!
<mvo> bryce: but I have a r200, so no cookies for me .)
<Amaranth> mvo: Apparently the zero-copy tfp stuff right now is a hack using EXA
<Amaranth> mvo: So once again we don't get it because EXA is generally broken
<mvo> Amaranth: how does it work on a non-uma architecture?
<Amaranth> It just means it doesn't do a copy in system RAM, apparently
<Amaranth> Still have to copy it to the vram
<mvo> Amaranth: aha, now it comes together
<Amaranth> I think they can do it with true zero-copy later
<Amaranth> But with the restriction you mentioned
<mvo> Amaranth: so its one-less-copy for now :P
* mvo takes a break of ~1h 
<LaserJock> *sigh* and the love-hate relationship with gnuplot continues
<bddebian> LaserJock: :)
<LaserJock> Home, End, and Delete keys don't work in gnuplot (just get the funky codes)
<LaserJock> and upstream says it's distro's fault since their internal readline has worked since before Linux existed
<bryce> mvo, not sure about uma
<minghua> LaserJock: Are you saying the gnuplot people claim that the internal readline should have Home, End, and Delete support?
* minghua tests
<LaserJock> minghua: well, yes, they say it's the distros that've screwed up
<minghua> Nah, doesn't work in Debian either.
<LaserJock> and can't get keycodes consistent
<LaserJock> of course it doesn't work in Debian :-)
<minghua> But I know with GNU readline those keys work.
<LaserJock> it was reported in Gentoo, Debian, and Ubuntu
<LaserJock> and OpenSuse I think too
<LaserJock> but upstream says it's the distros
<highvoltage> LIES!
<minghua> LaserJock: I think the efforts should be put into getting libedit support.
<minghua> LaserJock: I tried about a year ago, at least it compiles.
<LaserJock> minghua: the history support was fixed though
<LaserJock> minghua: is that the bsd readline library?
<minghua> LaserJock: Yes.  And actually there are two, libedit and libeditline.
<minghua> (Unfortunately, I can't remember which one is the one I tried.)
<minghua> :-(
<LaserJock> yes, I think it's worth the effort
<LaserJock> readline's license is probably not going to change
<LaserJock> and neither is gnuplot's
* minghua wonders why gentoo suffers this bug.
<LaserJock> it's probably *they* most annoying bug I've ever really had personally
<LaserJock> s/they/they/
<LaserJock> bah
<minghua> Sure they can turn on gnu readline support by default?
<LaserJock> s/they/the/
<LaserJock> minghua: not sure
<LaserJock> Ubuntu was the first distro I ever had a problem
<LaserJock> minghua: take a look at the forwarded bug in debian bug#305501
<wasabi> So what's LPIA stand for?
<ion_> Just a guess: low-power intel architecture.
<wasabi> Hmm. A separate arch? Same instruction set or ?
<ion_> I have no idea. :-)
<ion_> Im sure someone will enlighten us.
<Ng> infinity is the man to ask :)
<mjg59> Yes
<mjg59> Same instruction set but different optimisations
<Ng> that's the one :)
<wasabi> Interesting.
<wasabi> optimizations at teh arch level, something that couldn't be addressed in packaging on i386?
<wasabi> I'm just curious. ;)
<mjg59> They'd be pessimisations for the rest of x86
<wasabi> oh wow, I didn't know hildon made it in
<cjwatson> wasabi: #ubuntu-mobile if you're interested
<bdmurray>  /etc/iftab has been deprecated in Gutsy correct?
<mjg59> Yes
<cjwatson> bdmurray: yes, by udev rules; /etc/udev/rules.d/70-persistent-net.rules if you need to touch them
<cjwatson> I think Scott said he still needed to do some migration logic
<bdmurray> Right, is that documented somewhere though?
<cjwatson> probably not
<bdmurray> cjwatson: by the way is 130131 really a debian-installer bug?
<ijuz> i have something odd...  gutsy from today, gnome suspends to ram without problems and resumes (well, every 5 resumes i have to switch with alt+f7 back to X), but with KDE i quickly get gfx corruptions and after about 3 resumes the gfx doesn't come back at all (the system is working, i can log into it with ssh)
<ijuz> i thought the scripts in /etc/acpi/ are doing the suspend/resume, so i don't get what different between KDE and gnome
<cjwatson> bdmurray: no, it's xresprobe - I've reassigned, thanks
<bdmurray> Is xresprobe is used to determine the vga setting?
<cjwatson> bdmurray: the vga= kernel parameter? no
<cjwatson> we don't set that by default, ever
<cjwatson> (except by the video mode menu in gfxboot; which isn't exactly by default but is probably more visible than it ought to be)
<ijuz> i have seen 130131 in the same way on my gm965 laptop with 20070807.1
<bdmurray> Okay, I'm just not clear on how it is xresprobe - where it fits into the alternate CD installer.
<cjwatson> bddebian: alternate CD installer installs a bunch of packages including xserver-xorg which calls xresprobe in its postinst
<bddebian> Not me, you don't love me :)
<cjwatson> err :)
<ijuz> afair it happened here before you can choose the resolution
<cjwatson> bdmurray: ^--
<cjwatson> ijuz: xserver-xorg's postinst often doesn't prompt for resolution if it thinks it can guess
<cjwatson> ijuz: and in any case I think it tries to probe first in order to select reasonable defaults
<ijuz> ok
<ijuz> makes sense
<wasabi> how far are we away from config-less X?
<cjwatson> anyway, it's a very very long-standing xresprobe bug that sometimes it buggers up the display
<cjwatson> as far as the alternate CD goes, wait for a while and then hit enter a few times to finish the install, as long as you didn't want to select anything other than the defaults :)
<ijuz> xresprobe intel find here also nothing useful:
<ijuz> id:
<ijuz> res:
<ijuz> freq:
<ijuz> disptype: lcd/lvds
<cjwatson> bryce may be able to help on the details, but I'm afraid I can't
<mjg59> xresprobe needs updating to handle intel
<mjg59> It only knows how to do i810
<bdmurray> ah, that's interesting
<mjg59> /usr/share/xresprobe/lcdsize.sh is the main one
<ijuz> and i810 doesn't support gm965
<calc> seb128: whats the eta for the glib 2.14.0 upload?
<calc> seb128: i saw a claim that the init bug may be fixed in it
<calc> seb128: i'm also trying a build without some patches that may be at fault to see if that helps also in OOo case
<calc> seb128: some of the OOo patches that is
<seb128> calc: I don't plan to upload 2.14.0, make check hits some errors, I was waiting for a 2.14.1
<mjg59> Hang on, I'll fix xresprobe now
<calc> seb128: ok no problem
<seb128> calc: I can uploaded a patched version if you want
<calc> seb128: when is 2.14.1 due any idea?
<calc> seb128: oh the patch i am talking about is one they think is the cause on the OOo side
<calc> seb128: someone claimed it worked fine for them with glib 2.14.0 though so it might be worked around on the glib side as well
<seb128> calc: I'll try with 20
<seb128> .2.14.0
<seb128> and upload it openoffice starts with it
<calc> seb128: ok, try it with -gtk -gnome removed and see if it starts
<seb128> (there is a patch to make it build in svn)
<seb128> right
<norsetto> can anyone have a look at this: https://conky.svn.sourceforge.net/svnroot/conky/trunk/conky1/COPYING
<calc> seb128: if it starts with both of those removed then it should be ok, otherwise once i get OOo built i am going to see if they patch they think is buggy is the one at fault on OOo side of things
<norsetto> Is it acceptable as an upstream license?
<calc> er ...the patch they think...
* calc is full of typos today
<mjg59> norsetto: Yes
<mjg59> The binary package as a whole will be GPL
<calc> norsetto: depending on the contents of licenses (assuming they are normal licenses)
<calc> and iirc the BSD one has to be the three clause BSD one, right guys?
<mjg59> calc: No, 4-clause is free
<calc> oh ok
<mjg59> But it's 3 clause anyway
* calc thought 4 clause with the required attribution wasn't considered GPL friendly
<calc> or whatever was in that part, i have forgotten exactly what it was
<norsetto> its the 3 clause BSD
<calc> norsetto: ok np, it should be fine then :)
<norsetto> cool! thx guys one hug each :-)
<calc> "All advertising materials mentioning features or use of this..." part of 4 clause was what I was meaning is non-gpl compatible (iirc) eg openssl
<pitwalker> Hi, all!
<cjwatson> right, that's free but GPL-incompatible
<calc> norsetto: but since its 3 clause it is fine
<calc> mjg59: the 3 clause i mentioned is because that code was listed as being relicensed under GPL
<calc> mjg59: 4 clause is ok, but not as relicensed under gpl aiui
<mjg59> Yeah
<calc> relicensing in this case is a misnomer its GPL code interlinked with BSD code
<cjwatson> "distributed under the terms of" is the usual languages
<cjwatson> language
<calc> seb128: oh yea let me know one way or the other wrt the glib 2.14.x test if you don't mind :)
<mjg59> ijuz: Can you try http://www.codon.org.uk/~mjg59/tmp/xresprobe_0.4.24ubuntu4_i386.deb ?
<ijuz> sure
<calc> mjg59: any news wrt to the amd64 vbetool?
<ijuz> halt success
<ijuz> half
<ijuz> root@ijuz-laptop:~# xresprobe intel
<ijuz> id:
<ijuz> res: 1920x1200
<ijuz> freq:
<ijuz> disptype: lcd/lvds
<mjg59> calc: Nope. I think I've worked out Kyle's problem, but yours is still a bit odd
<mjg59> ijuz: That's all you'll get for lvds
<calc> mjg59: ok
<ijuz> but when i run it on the local console the screen stays black
<calc> mjg59: if you need me to do any further tests just let me know, i'll be happy to help out in any way i can :)
<ijuz> i still can switch to X and back, but the console stays black until i run xreprobe again from ssh... then the console works again fine
<mjg59> ijuz: No clue there.
<mjg59> X issue rather than xresprobe in any case, I suspect
<ijuz> yes
<mjg59> Anyway, uploaded
<ijuz> it fails only about ever second time, very uncool
<norsetto> still on that package, I see some sources are GPL 2.1 and others GPL 3; COPYING is GPL 3: I guess this is ok?
* norsetto is sorry for being such a pain .....
<mjg59> Yes
<bryce> mjg59: cool thanks, I'd been wondering about how to best add intel in there
<norsetto>  /me thinks than better safe than sorry should actually be better sorry if it is safe .....
#ubuntu-devel 2007-08-11
* Starting logfile irclogs/ubuntu-devel.log
<thelsdj> if i apt-get source, then change something inside the source directory, how do i recreate the diff and dsc files ?
<Hobbsee> debuild -S -sa
<Hobbsee> thelsdj: no need to put your question in multiple channels, btw
<thelsdj> yea but i kinda asked in the wrong place so thought i'd come over here hehe
<thelsdj> can i skip the signing for now?
<thelsdj> fails because no gpg entry for my name/eamil
<RAOF> thelsdj: That doesn't matter.
<RAOF> You don't want/need to sign it, anyway.
<thelsdj> ok guess it did make the files, thanks
<thelsdj> trying to fix xen-3.1 on amd64
<thelsdj> arg, nope, didn't fix it, the python-xen-3.1 package is still empty
<RAOF> Well, keep going.  I've got an amd64 buildbox / mythtv server I'd like to try xen on :)
<thelsdj> thoughts on what would cause a package to be empty? my first guess was bad path in python-xen-3.1.install
<thelsdj> also maybe issue with arch specific vs arch independent
<RAOF> That's a good one.  Others include: wrong package name for the install, not calling dh_install
<thelsdj> very new to debugging deb packages
<thelsdj> even though its 22:30 on a friday evening, i'm kinda being payed for this which is nice
<RAOF> Wicked.
<thelsdj> finally convinced my boss to start transitioning employees from windows to linux and so he wants me testing bleeding edge so we can find/fix problems early on
<RAOF> Man, that's *awesome*.
* RAOF 's dream job.
<thelsdj> so build a new work desktop, installed gutsy 64bit, and away i go
<thelsdj> eh, most of my dayjob is writing boring asp.net code
<thelsdj> but atleast we run some of that on xen/linux/mono
<thelsdj> might have got it fixed
<thelsdj> bad package name in install-tools: DH_OPTIONS...
<thelsdj> had been renamed from python-xen3.1 to python-xen-3.1 and don't think that was updated
<thelsdj> still rebuilding but hopefully that was it
<thelsdj> looking good, installed and restarting
<thelsdj> woops, need to disable nvidia driver first
<thelsdj> https://bugs.launchpad.net/ubuntu/+source/xen-3.1/+bug/131594
<ubotu> Launchpad bug 131594 in xen-3.1 "[gusty]  xen python modules not found" [Undecided,Confirmed] 
<highvoltage> pygi! I was wondering how you are doing
<pygi> highvoltage, !
<pygi> highvoltage, being a bit sick, but better then before
<pygi> highvoltage, not so good otherwise, but I'll live
<pygi> highvoltage, you?
<tsurc> want a laugh anyone?
<tsurc> I think I might be trying to be a little over ambitious.. Im trying to get feisty server + ubuntu-xen-server + drbd
<tsurc> but I'm running into trouble compiling drdb for the kernel used  by xen (2.6.19-4)
<highvoltage> pygi: I also had a bad cold this last weekend and earlier this week, but I'm much better now
<highvoltage> still on anti-biotics- last day today at least :)
<rgl> hi
<rgl> its normal for a system to receive NMI in /proc/interrupts ?
<Kmos> rgl: try #ubuntu-kernel
<rgl> Kmos, humm.  thx.  and hi there :D
<Kmos> :-)
<null____> hello
<pygi> Hobbsee, swfdec built and working
<Hobbsee> pygi: yay!
<null____> lately trevino has not updated his packages for compiz ?
<Hobbsee> null____: trevinho is not here.  he doesnt try to work wiht us at all
<pygi> Hobbsee, I've talked with upstream, they'll release 0.5.2 in monday just for us, so I'll package it =)
<Hobbsee> null____: you'll have to contact him by other means
<Hobbsee> pygi: yay!
<null____> ahh ok, thanks for the info
<pygi> Hobbsee, a lot of improvements
<pygi> (since it's UVF soon)
<Hobbsee> yep
<Hobbsee> not hard to get a UVFe anyway
<pygi> Hobbsee, true, but oh well =)
<Hobbsee> the UVF team should be announced soon, too.
<pygi> nod
<pygi> free flash is important =)
<pygi> and swfdec works much better then gnash
<ion_> Especially since ubuntu-mobile seems to use a Flash UI.
<pygi> ion_, oh!
<asac> pygi: how do you measure that swfdec works better than gnash?
* Hobbsee waves to asac
<pygi> asac, easy :)
* asac hugs Hobbsee 
* Hobbsee hugs asac back :)
<pygi> asac, you visit sites, and see what works and how it works
<asac> hmm ... when i tried back in may/june i found that gnash works better :)
<asac> pygi: do you have any specific sites/flash-films ?
<pygi> asac, well, wait until next week when I package 0.5.2 :)
<asac> pygi: will you?
<asac> pygi: cool
<pygi> asac, then I'll poke you, and show you the difference =)
<asac> right ... can you ping when when you package that?
<pygi> asac, sure, as soon as 0.5.2 is out, it'll be packaged in a matter of day =)
<ion_> Hm, the current swfdec-mozilla package doesnt seem to support the *-flashplugin alternatives.
<asac> pygi: i need to tell you a few things you should obey ;)
<pygi> asac, oh, shoot? :)
<asac> ion_: right ... thats one of the points ;)
* pygi wonders what asac has to say :)
<asac> ion_: pygi and should be done if someone touches that package again :)
<pygi> asac, feel free to say what needs to be done
<asac> pygi: alternative + Npp-xxx headers so new plugin-finder service will be able do suggest users the package if they search for a flash plugin
<pygi> asac, given I have no idea what Npp-xxx headers are ... :)
<asac> when you package ... just ping me
<asac> ;)
<pygi> oki, will do :)
<pygi> thanks ^_^
<ion_> pygi: For instance, apt-cache show flashplugin-nonfree | grep Npp
<asac> pygi: look at the control file of flashplugin-nonfree
<pygi> asac, aha, looking
<pygi> Xb-Npp-Applications: ec8030f7-c20a-464f-9b0e-13a3a9e97384, 92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a
<pygi> I guess this are identifications strings for: flash-nonfree and gnash?
<asac> pygi: right ... those are application is of the mozilla pplications this plugin supports
<asac> pygi: no ... those are identifiers for firefox + iceape/seamonkey iirc
<pygi> asac, aha, got it
<asac> so you know in which application the plugin will be installed
<pygi> ok, that shouldn't be a problem
<pygi> and what about that alternatives stuff?
<asac> we will have to add one more for midbrowser (mobile browser)
<asac> pygi: look in gnash postinst/prerm
<pygi> sure, if you've got the string, feel free to gimme one :)
<pygi> asac, we should probably properly put conflicts in packages as well, no?
<pygi> we dont want swfplayer-mozilla and flashplayer-nonfree installed for example?
<asac> pygi: no ... thats why we have alternatives
<pygi> oki =)
<asac> you can install all ... and then choose by alternative
<pygi> yup, update-alternatives I guess =)
<asac> right
<pygi> ha, see ... I know something :p
* asac wonders if there is GUI/Administration tool to administer alternatives in ubuntu/debian ?
<pygi> asac, yes
<asac> yes?
<pygi> galternatives
<asac> is that in gnome pref/admin menu?
<pygi> that has to be manually installed
<asac> hmmm ... its not installed
<asac> is that crappy or why isn't that installed by default?
<asac> doesn't look so bad
<pygi> no idea, never used it
<pygi> asac, ok, one question on the from postinst:
<pygi>               update-alternatives --install /usr/lib/xulrunner/plugins/flashplugin-alternative.so \
<pygi>                       xulrunner-flashplugin /usr/lib/gnash/libgnashplugin.so 70
<ion_> Uh. A huge number of similar update-alternatives lines instead of a simple for p in iceape iceweasel mozilla firefox xulrunner; do update-alternatives --install "/usr/lib/$p/plugins/flashplugin-alternative.so" "$p-flashplugin" /usr/lib/flashplugin-nonfree/libflashplayer.so 70; done
<pygi> what's this "70" stuff?
<asac> pygi: the priority
<asac> i will probably bump everything to 50
<asac> ion_: yes ... my bad
<pygi> asac, ok, so priority to everything should go to 50?
<pygi> just trying to note when packaging
<asac> ion_: feel free to submit a debdiff ;)
<asac> pygi: yes ... we previously wanted gnash to get a lower prio then -nonfree, but install gnash by default ... now we won't install anything by default, but give them the same priorities
<pygi> asac, got it
<pygi> do we have a identification string for that midbrowser? I could submit a debdiff if you want for that?
<asac> pygi: sure
<asac> wait a sec
<asac> the current package has still firefox uid ... next releas will have its own
<pygi> asac, right, so no changes for now, right?
<asac> aa5ca914-c309-495d-91cf-3141bbb04115
<pygi> oh, k, thanks
<asac> pygi: just add that now
<pygi> will do, thanks
<asac> won't hurt until new midbrowser comes
<pygi> I'll also update the thingy ion_ said
<asac> pygi: yes ... and maybe add a xulrunner id as well (i think they install in xulrunner dir as well)
<pygi> asac, tell me xulrunner id?
<asac> hehe ... i have to look it up ;)
<pygi> asac, how come we don't have epiphany and galeon id's in there? Do they identify as mozilla, and that works then?
<asac> pygi: ok ... it doesn't have its own id ... as its just a runner to run multiple applications on
<pygi> asac, fine :)
<asac> pygi: they would identify as mozilla .... but it doesn't matter much, as they don't have a plugin-finder wizard
<pygi> asac, got it
<asac> ok ... i am out again
<asac> cu
<pygi> asac, laters
<pygi> asac, you back by any chance?
<bddebian> Heya
<hunger> Someone broke crypted disks again:-(
<pygi> asac, poke when you are back pls, thanks
<asac> pygi: not for long ;) ??
<pygi> asac, just wanted to say I've done some patches, one already uploaded, one being reviewed :)
<pygi> asac, enjoy whatever you are doing :)
<asac> pygi: cool ... about flash?
<pygi> asac, why, ofcourse =)
<asac> some patches? how many?
<pygi> just 2 for now xD
<asac> ok ... that qualifies for some ;)
<pygi> I have more in my head tho, but I can't look anymore, so they'll have to wait =)
<asac> ok ... later!
<pygi> asac, laters ;)
* asac out again
<mjg59> a
<mjg59> Oops
<rgl> hello
<rgl> Kmos, :D
<Kmos> ryu :)
<Kmos> ups
<Kmos> rgl
<xhaker> Hi all, anyone willing to make libmtp 0.1.5 -> 0.2.1 happen?
<xhaker> there is no packaging of the latest version on debian either
<pygi> xhaker, do we need it for anything?
<xhaker> it seems to have been dragged to main because of the integration in rhythmbox
<xhaker> i hope i'm right saying that
<xhaker> it's a hardware support critical library, the new version has new udev rules
* pygi downloads source package
* xhaker hugs pygi
<pygi> xhaker, I didn't say anything, patience :)
<pygi> I'll just have a look at it
<xhaker> you deserve a look just by taking that step :D
<xhaker> s/look/hug
<pygi> ah, abi bump it seems
<fabbione> so... name... for... a... library.....
<fabbione> pygi: does it involve also an API change?
<xhaker> fabbione, i think so
<pygi> fabbione, yes, API changes are there
<fabbione> libmtp5
<fabbione> Reverse Depends:
<fabbione>   gnomad2
<fabbione>   rhythmbox
<fabbione>   mtp-tools
<fabbione>   mtp-tools
<fabbione>   libmtp-dev
<pygi> not sure we want this upgrade at this point :-/
<fabbione>   amarok
<fabbione> unlikely
<pygi> xhaker, sorry, no upgrade for gutsy :-/
<pygi> fabbione, +1, thanks for the opinion
<fabbione> it would still be wise to check the changelog
<xhaker> hmm, what about backporting the udev rules
<pygi> fabbione, I'm checking it
<fabbione> and see if there is anything critical in the upgrade
<xhaker> fabbione, what i most value in it is the increased number of hardware supported by the new release
<fabbione> xhaker: yes i understand. i am looking at what that library does.. but an API change might require a lot of porting and testing
<pygi> nod
<pygi> fabbione, http://libmtp.sourceforge.net/index.php?page=download
<pygi> major changes can be seen there
<pygi> (over the versions)
<xhaker> libmtp is similar to libgphoto2 but in turn supports audio player devices
<fabbione> pygi: well i suggest you check if you can get the libmtp rdpendes to build and work
<fabbione> if you can by minimal patches, propose it to RM's and get it as an approved transition
<fabbione> but have everything ready before hand
<fabbione> xhaker: that should be your task to
<fabbione> i understand what the library is for and why you want it in.. but you also need to collect the pieces for doing the job :)
<xhaker> fabbione, willing to do that
<xhaker> *I am*
<fabbione> xhaker: i don't doubt.. just making sure :)
<xhaker> I'm trying to find the developers online
<fabbione> on a saturday evening it's difficult..
<fabbione> try to look for Hobbsee in about 12 hours from now
<pygi> fabbione, but but ... I'm working on flash packages right now, can't handle everything :-/
<fabbione> pygi: well you with xhaker
<fabbione> whatever..
<fabbione> somebody != me :)
<pygi> hehe :)
<xhaker> pygi, don't worry
<xhaker> pygi, i've been to some motu classrooms, hahaha
<xhaker> i will try to build the stuff :D and report back
<xhaker> :D
<pygi> xhaker, ok
<pygi> xhaker, make sure to bump the package to libmtp6
<pygi> and do the "Replaces:" "Conflicts:" dance
<pygi> hey asac_ :P
<pygi> xhaker, I could make the libmtp package if you wish, but you should check rdepends?
<fabbione> pygi: why do you need Conflicts: Replaces: ?!?!
<xhaker> pygi, do that then
<pygi> fabbione, ergh, ok, just replaces
<fabbione> if you change the soname, the 2 libraries libfoo1 and libfoo2 can be installed in parallel
<pygi> yes, I know that
<fabbione> libfoo1 will be obsoleted by disappearing from the archive
<fabbione> libfoo-dev will Depends: libfoo2
<pygi> oh well
<fabbione> all the apps that use libfoo2 that are rebuilt will pull in libfoo2 automatically
<fabbione> or am I missing something?
<pygi> probably not ... it's me who's missing something =)
<pygi> don't worry ;)
<fabbione> i am not...
<fabbione> but at my age.. memory starts to fall apart
<xhaker> pygi, hit me with a link when you finish
<pygi> xhaker, sure, shouldn't take long
<pygi> xhaker, building in pbuilder
<pygi> ah, it gotta upgrade itself first
<pygi> asac, how come firefox doesn't show gnash in it's Finder service, and we've got the browser ID in?
<pygi> (when flash is in question ofcourse)
<pygi> xhaker, still here?
<xhaker> pygi, sure
<pygi> xhaker, built and installed in pbuilder, gonna test rdepends now
* xhaker is checking the files in libmtp source
<pygi> xhaker, one package down, builds properly
<pygi> fabbione, same note for you if you are interested =)
<xhaker> pygi, great!
<fabbione> pygi: i would make sure that they run properly by checking what's changed in the API
<fabbione> a build is not enough
<fabbione> specially if something like foo(int a, int b) in the API changed to foo(int a, int c)
<fabbione> it will still build, but change way of working..
<fabbione> then you are doomed
<pygi> fabbione, that kind of things others will do, I'm just building here =)
<pygi> so much things to download in pbuilder ergh
<xhaker> i'll open the file and check what changed, just have to download the older version
<xhaker> i'll just dif the whole src
<xhaker> pygi, fabbione: this seems to be the offending part http://pastebin.com/m3e25effb
<xhaker> the struct has 2 new fields
<fabbione> a rebuild of that should be enough but there is also a new function that might be required in certain operations
<fabbione> i also guess that somehow you want to use those fields
<fabbione> or you will lose info
* fabbione &
<xhaker> fabbione, my guess is that if they were not used before no application is making use of them yet
* xhaker is good at spotting the obvious
<xhaker> i should really get in touch with someone from the project
<xhaker> mail sent
<rgl> hi.
<rgl> why the packages (as show by apt-cache show) never have the program site URL?
<xhaker> pygi, could you host the libmtp files?
<pygi> xhaker, no idea where =)
<pygi> xhaker, your mail pls
<pygi> (i'll send you the files)
<xhaker> i was setting up an ftp user
<pygi> xhaker, ergh, mail will do, it's not big :)
<Kmos> rgl: if isn't in text description in control, it doesn't show any url
<rgl> Kmos, I mean.  it doesn't seem normal for the package description to include the site URL, which kinda sux :|
<rgl> Kmos, j tenho o LG :D
<Kmos> rgl: nice
<Kmos> boa compra
<rgl>  muito nice. no  dos espelhados :)
<Kmos> ainda bem
<Kmos> senao morrias em pouco tempo
<Kmos> bem, vou jantar pra sair um pouco
<Kmos> acabei de ver a season 2 de dr. house
<Kmos> :)
<rgl> bye bye :)
<rgl> lol
<Kmos> ja ca tenho a 3
<Kmos> lol
* Kmos waiting for upgrade to gutsy finishes..
<thully> Hi
<thully> I have a few questions about Ubuntu development as a user who is interested in helping improve the system...
<thully> I've had some issues with various areas of the main Ubuntu system (i.e. not universe/multiverse) and would like to know where discussion of issues relating to this takes place.  I know the "core development team" exists, but they don't appear to have a mailing list like MOTU.
<thully> I have filed bugs on most of these issues, but I'm finding most bugs don't get responses.  My concerns in particular mostly have to do with hardware issues (mostly laptop-related - C-state weirdness, trackpad, brightness control, etc ) with some other miscellaneous concerns involving the base Ubuntu desktop.
<Lutin> pygi: mozilla-plugin-gnash fails to upgrade to your last gnash upload: exits with this message /var/lib/dpkg/info/mozilla-plugin-gnash.postinst: 7: Syntax error: "do" unexpected (expecting ";;")
<pygi> Lutin, yes, I know
<Lutin> ok
<pygi> same with flashplugin-nonfree
<pygi> Lutin, thanks for reporting ^_^
<Lutin> pygi: np :)
#ubuntu-devel 2007-08-12
<pygi> Lutin, fixes found, will soon be uploaded
<Lutin> pygi: cool :)
<pygi> Lutin, thanks for your patience :)
<Lutin> np
* pygi deserves some rest when they are uploaded since it's 1:16AM :P
<pygi> hey doko !
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* Starting logfile irclogs/ubuntu-devel.log
* Starting logfile irclogs/ubuntu-devel.log
<pygi> xhaker, now yes
<khermans_> packages.ubuntu.com is down
<sivang> hey Spads
<sivang> Spads: are you allowed / have access to domain name services provided by canonical? I've opened an RT ticket long ago to have a couple of loco domains managed by ns.ubuntu.com and the blackcatnetworks DNSs still no reply
<sivang> I at least want to know the status for the request :)
<jamiemcc> pitti:tribe 4 did not install esound by default - was this deliberate or bug?
<jamiemcc> without esound all gnome/gtk apps were slowed trying to spawn it
<jamiemcc> tracker-search-tool was slowed considerably by it - installing esound resolved speed issues
<pitti> hey jamiemcc
<pitti> jamiemcc: yes, we are sooo glad to have killed esound
<pitti> jamiemcc: esd really sucks, and we only kept it for libgnome
<pitti> jamiemcc: but I finally managed to make libgnome work without esd
<jamiemcc> pitti : cool
<Fujitsu> Oh, it's finally dead?
<jamiemcc> pitti: is that libgnome in gutsy yet?
<pitti> jamiemcc: why is it slowed down?
<pitti> jamiemcc: yes, sure
<jamiemcc> pitti: run tracker-search-tool from terminal
<pitti> jamiemcc: through libgnome, or does tracker use libesd directly?
<jamiemcc> no anything using gtk is affected
<pitti> jamiemcc: ah, I see
<pitti> jamiemcc: that's on my list
<jamiemcc> tracker searches take fraction of a second but wtihotu wesound they take 2-3 secs
<jamiemcc> disabling esd in sound preferences all restores speed
<jamiemcc> all/also
<jamiemcc> I find all gtk apps are faster with esound too
<pitti> jamiemcc: oh, I see
<pitti> jamiemcc: that's indeed a good general point
<jamiemcc> shall I file a bug in lauchpad?
<pitti> jamiemcc: that would be nice
<jamiemcc> ok will do so now
<pitti> jamiemcc: please give me the # afterwards, I'll mark it as tribe5 and assign it to me
<jamiemcc> shall I file against esound?
<pitti> jamiemcc: libgnome please
<jamiemcc> ok
<pitti> jamiemcc: oh, I just tried it myself; indeed, that's an amazing difference
<jamiemcc> yeah :)
<jamiemcc> gutsy now runnig as fast as feisty now
<jamiemcc> pitti: libgnome not in launchpad?
<pitti> jamiemcc: https://launchpad.net/ubuntu/+source/libgnome/+bugs
<pitti> https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/115652
<ubotu> Launchpad bug 115652 in libgnome "evince tries to open esd even if it is not installed" [Low,Confirmed] 
<pitti> jamiemcc: ^ that's more or less it
<pitti> jamiemcc: let me mangle that
<jamiemcc> piti: ahh ok
<pitti> jamiemcc: there
<jamiemcc> pitti: thx
<pitti> jamiemcc: thanks to you for pointing this out
<jamiemcc> no problem - I was scrathcing my head wondering why tracker-search-tool was so slow!
<norsetto> I see. This also explains this then: /bin/sh: O_PASSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS/usr/bin/esd: not found
<norsetto> /bin/sh: /usr/bin/esd: not found
<Amaranth> O_O
<ijuz_> it's probably a good idea anyway to delete esd, directly after deleting artsd ;)
<stgraber> lots of software complain in log files about missing esd (it was replaced by alsa in gnome, but manually and there are some remaining changes to do for sure :))
<_StefanS_> anyone know how to build two source packages that depend on eachother?
<_StefanS_> like libxml-parser-perl and libxml-encoding-perl ?
<xhaker> pygi, hi
<jdong> bleck Dapper is affected by debian bug #321718
<ubotu> Debian bug 321718 in libc6 "Upgrade caused many libs to complain about "executable stack"" [Important,Fixed]  http://bugs.debian.org/321718
<jdong> sucks for PaX users.... oh well, Feisty time
<alex-weej> is it just my system or is VPN totally broken in Gutsy?
<alex-weej> NM just crashes whenever i try to log on
<xhaker> pygi, you available yet?
<pygi> xhaker, hardly :-/
<pygi> how may I help?
<xhaker> have you read what i told you about amarok + libmtp6?
<pygi> that a maintainer said no changes needed?
<xhaker> "Not many apps
<xhaker> use this, I believe only Amarok, and they have some compile-time or similar check for it."
<xhaker> well, i've built new packages for amarok and tested them
<xhaker> everything works, apparently :)
<Riddell> pitti: should I send out a "feature freeze soon" notice?
* highvoltage hugs pitti (because laserjock sed I must)
<pitti> Riddell: I think for two-week tribes, ten days in advance is a bit too much
* pitti hugs highvoltage back
<highvoltage> :)
* norsetto bows to the almighty
<zul> hey pitti
<pitti> hi zul
<Lutin> hey pitti
<moquist> pitti: ogra has pointed me to you to discuss a postinst script to set up a new postgres user and database (for the moddle package, which unfortunately comes from upstream using wwwconfig). Are you around to discuss this?
<pitti> moquist: about to go to bed; can you please mail me?
<moquist> pitti: OK. sleep well.
<pitti> thanks!
<Kmos> want to know about a nice crash? on console.. "c.. & cd .." and it closes terminal
<Kmos> *bug
<Kmos> it happens only sometimes..
<Kopfgeldjaeger> is there a changelog for the ubuntu packages? i mean, changes in package x
<ijuz_> 7usr/share/doc/<package>
<Kopfgeldjaeger> ijuz_: im mean, available in the internet - im looking for changes in a gutsy package
<ijuz_> afaik not, just download it
<Kopfgeldjaeger> aah
<Kopfgeldjaeger> http://packages.ubuntu.com/gutsy/utils/bcm43xx-fwcutter --> more information --> changelog
<jdong> Kopfgeldjaeger: changelogs.ubuntu.com
<Kopfgeldjaeger> hehe :o)
<ijuz_> ah, cool
<jdong> yeah p.u.c points to it too
<jdong> it tends to lag a day or two though
<jdong> hence I just aptitude source, then look at the changelog
<asac> pygi: did you do the gnash upload?
* pygi hides
<Kopfgeldjaeger> er... why does searching for "restricted manager" at PUC result in a error message?
<pygi> asac, my fault, yes
<asac> pygi: please ping me next time
<pygi> asac, will do, sorry
<asac> pygi: please bring up your changes to bzr
<asac> i want to review and merge to the main tree
<asac> pygi: thanks ;)
<pygi> asac, oki, but I gotta fix the upload first (I think the upgrade is broken because of ubuntu3, and gotta fix that in prerm)
<asac> pygi: please do bzr first
<asac> then ask me
<asac> try to redo the uploads if possible
<asac> if not ... fine :/
* pygi will do a bzr then tomorrow morning
<asac> pygi: pleas do that before the upload ;)
<pygi> asac, ofcourse, don't worry ;)
<asac> ok great
<pygi> I learn fast, you know xD
<asac> pygi: actually i do not even know that something broke ... just saw uploads ;)
<asac> pygi: so what is broken atm?
<pygi> asac, upgrade from ubuntu3
<pygi> asac, requires a prerm modification in the package so we'd fix that for users
<pygi> (and ofcourse upgrade from ubuntu4 to (yet nonexistant) ubuntu5 would fail unless we do such modification
<asac> please tell me one sentence of details ... why does it fail, how?
<pygi> ok, it fails because ubuntu3 had a broken prerm/postinst (it had single quotes, it shouldn't have quotes at all)
<pygi> it fails while configuring the package, and stays at half-configured state
<pygi> ubuntu4 has fixed the prerm/postinst, but upgrade still fails because the prerm should have been modified to fix the upgrade path
#ubuntu-devel 2008-08-04
<owen1_> can u say that ubuntu development is agile? if yes, do u have any links for more info?
<owen1_> (it's for a university assignment)
<persia> owen1_: Maybe, and not really, but http://wiki.ubuntu.com/UbuntuDevelopment may help
<owen1_> persia: great. thanks
<BenC> pitti: around?
<ion_> benc: I didnât manage to test the grub patch yet, but iâll see if i get around to that tonight.
<BenC> ion_: thanks...CC cking@ubuntu.com with any results, please
<ion_> Will do
<kane> hi
<kane> Anyone here
<ion_> Nope
<kane> ok kool
<kane> At least someone
<kane> Its like no one active in IRC
<kane> I need help installing a broadcom 4311 on ubuntu
<ion_> Please read the topic.
<kane> ook
<kane> thanks
<kees> Keybuk: say, any idea why pcre3 is showing up on MoM as unmerged with a 2-day-old ubuntu version?
<emgent> giskard: heya
<pitti> Good morning
<emgent> moin pitti
<pitti> hey emgent
<pitti> BenC: hi
 * StevenK waves to pitti 
 * pitti throws a cookie towards Australia
<StevenK> And it landed where, across the street? :-)
<Hobbsee> hey pitti!
<BenC> pitti: hey
<BenC> pitti: is there any progress on package-groups?
<pitti> BenC: not that I can see :-( Last thing I know is that mvo proposed it to Debian, but I didn't see feedback to that yet
<BenC> pitti: should we even consider it an option for intrepid at this point?
<pitti> BenC: I don't think it'll make it, I'm afraid :/
<BenC> pitti: that's too bad...I did all the kernel side stuff to make it work
<BenC> guess that will be 9.04
<pitti> uh, sorry for that
<pitti> BenC: what did you change, out of interest? add the P-G headers already?
<BenC> pitti: no, just the last-good-boot stuff so that we could reasonably get rid of the versions in the pkg name
<BenC> and move things to Version: and P-G headers
<BenC> so it's not a waste
<BenC> and I haven't done anything that needs to be reverted :)
<pitti> BenC: oh, l-g-b is a separate feature anyway, right?
<pitti> ok, *phew* :)
<pitti> BenC: I'll ask mvo again about the status, I'm curious myself
<pitti> BenC: BTW, last time I looked at it (or, rather, the error messages), it seemed to hardlink the current kernel/initrd
<pitti> BenC: will that DTRT if there is a non-abi-updating new kernel package, too?
<pitti> i. e. like the current -5.13 -> -5.14
<BenC> pitti: it saves everything on every boot...so yes
<BenC> pitti: when a kernel update happens, the hardlinks are broken (dpkg doesn't overwrite the existing file, it always unlinks/renames)
<BenC> pitti: same with update-initramfs
<pitti> great
<pitti> so that means cheap operation on boot (just ln, not cp), and correct behaviour on update
<pitti> asac: any news on nspr/nss in hardy-proposed?
<kirkland> pitti: hey, jockey/intrepid question for you...
<pitti> hey kirkland
<kirkland> pitti: i just moved my primary laptop over to intrepid, and jockey doesn't appear to see my atheros wireless, or nvidia video
<kirkland> pitti: are these known issues?
<pitti> kirkland: it currently doesn't have any particular support for atheros ATM (nobody wrote a handler for it, or told me what to do for it)
<pitti> kirkland: nvidia should work, though; do you have a minute to debug it?
<kirkland> pitti: sure
<pitti> kirkland: first, do you have nvidia-common installed?
<kirkland> pitti: no, i don't
<kirkland> pitti: but nvidia is listed by lsmod
<pitti> kirkland: n-c is not needed by itself, but it needs its dependencies, nvidia-VERSION-modaliases
<pitti> kirkland: that would be it then; without the -modalias files, it cannot map vendor/product IDs to nvidia driver versions
<pitti> kirkland: apt-get dist-upgraded without recommends?
<kirkland> pitti: not on purpose....
<pitti> oh, a hardy->intrepid dist-upgrade wouldn't actually pull in Recommends:, true
<pitti> since we only enabled it in intrepid
<kirkland> pitti: ah, right
<kirkland> pitti: okay, nvdia-common (and friends) is installed now
<pitti> might be an interesting thing to discuss with mvo, but I guess the answer is "use update-manager" :)
<pitti> kirkland: sudo killall jockey-backend, then try again
<kirkland> pitti: I did do my upgrade via update-manager
<pitti> oh? definitively mvo's bug then; can you please file a bug?
<pitti> I guess it forgot to pull in recommends
<kirkland> pitti: sure, i'll talk to mvo in real time first
<kirkland> pitti: just to make sure i didn't do anything bone headed
<kirkland> pitti: shiny, now I have two different nvidia drivers to choose from
<dholbach> good morning
<emgent> dholbach: welcome back! :)
<dholbach> thanks emgent
<tseliot> ï»¿pitti: can't we use dependencies instead of recommends for nvidia-common?
 * kirkland restarts X
<pitti> tseliot: sure we could, but semantically Recommends: is the right thing
<tseliot> pitti: right but reliability > Semantics :-P
<kirkland> pitti: okay, jockey bits appear to be workign
<kirkland> pitti: nvidia x driver, that's another story ;-)
<kirkland> i'll ping bryce about that tomorrow
<pitti> kirkland: nice, thanks
<pitti> kirkland: or ask tseliot
<kirkland> tseliot: any known issues with nvidia in intrepid?
<pitti> tseliot: true; I'll wait for the discussion about u-m, and raise to depends if nothing else helps
<kirkland> tseliot: i can't get gdm to start
<tseliot> ï»¿kirkland: can I see your xorg.conf?
<kirkland> tseliot: sure...
<tseliot> ï»¿pitti: ok, thanks
<kirkland> tseliot: this is the broken one: http://pastebin.ubuntu.com/33925/
<kirkland> tseliot: I'm running on vesa now
<tseliot> ï»¿kirkland: it looks good. Can I see your /var/log/Xorg.0.log.old?
<tseliot> so that I can see where X failed
<gnomefreak> tseliot: upgrading from hardy to intrepid nvidia doesnt work with old xorg.conf atleast most people had to run nvidia config (cant remember command off hand atm
<kirkland> tseliot: http://pastebin.ubuntu.com/33926/
<tseliot> ï»¿gnomefreak: because of the RgbPath line?
<kirkland> gnomefreak: i tried nvidia-xconfig too... no avail
<gnomefreak> tseliot: IIRC yes
<gnomefreak> kirkland: you can rebuild xorg.conf by hand but its easier with command. kirkland you installed the right drivers?
<tseliot> gnomefreak: I would like to deal with this problem during the dist-upgrade.
<gnomefreak> tseliot: after fixing xorg.conf after upgrade in april/may it doesnt look any different than the old one
<tseliot> kirkland: you're using a Quadro card. The log shows only the VESA driver but I suspect that the unified back buffer is conflicting with Composite. Can you try creating an "Extensions" section in your xorg.conf and adding Option "Composite" "Disable" ?
<kirkland> tseliot: sure
<kirkland> gnomefreak: what are you calling the "right" drivers
<gnomefreak> kirkland: nvidia-glx-#
<gnomefreak> after removing the old drivers
<tjaalton> hmm, something wrong with a.u.c? can't update my laptop, some packages give 404's
<mvo> kirkland: did you upgraded using update-manager? if so, could you make /var/log/dist-upgrade/main.log availabe for me please (mail or so)?
<kirkland> gnomefreak: i had 177, now i'm trying 173
<tseliot> ï»¿gnomefreak: the ï»¿RgbPath line was usually added by nvidia-xconfig
<gnomefreak> i dont see it
<kirkland> mvo: I used update-manager -d -c
<tseliot> ï»¿kirkland: if you try the other driver, please send me your ï»¿/var/log/Xorg.0.log and ï»¿/var/log/Xorg.0.log.old
<tseliot> ï»¿gnomefreak: then you had a different problem which of course I can't see without a log
<gnomefreak> tseliot: http://pastebin.mozilla.org/506105 is my xorg.conf
<tseliot> ï»¿gnomefreak: the xorg.conf is correct
<gnomefreak> maybe ill upgrade one of my other systems to see if i can reproduce it. sometime today or tomorrow
<tseliot> ï»¿gnomefreak: ok
<gnomefreak> tseliot: thats from nvidia-xconfig
<kirkland> mvo: on its way (see the 2nd email from me)
<gnomefreak> tseliot: i have old one too
<mvo> kirkland: thanks
<kirkland> tseliot: which driver are you interested in?
<tseliot> ï»¿gnomefreak: ok, I would be glad if you could file a bug about this and attach the 2 files
<lifeless> mvo: hi
<lifeless> mvo: any archive changes recently ?
<tseliot> ï»¿kirkland: whatever you want as long as I get a log which reports that X tried to load the NVIDIA driver ;)
<gnomefreak> tseliot: i would like to reproduce it first ;) but ill file one if it still happens
<tseliot> ok
 * kirkland restarts X
<mvo> lifeless: hi, I just added a tiny debugging patch to the conflictsfinder to hopefully get a better idea what is the issue
<lifeless> mvo: :) you could tell where I was leading :)
<tjaalton> ok the archive works properly now
<mvo> lifeless: indeed :) dozens of mails from the conflictsfinder are not easily ignored (unless I add a sieve rule :P)
<mvo> kirkland: thanks, got it
<kirkland> tseliot: http://pastebin.ubuntu.com/33931/  <- with nvidia driver
<gnomefreak> kirkland: that looks like what i got after dist-upgrade well atleast same EE
<tseliot> kirkland: did you disable composite?
<kirkland> tseliot: I did
<kirkland> tseliot: it failed much quicker, at least
<tjaalton> pitti: so you are the HAL maintainer? do you have an opinion about where to put the script which generates the X input-hotplug fdi-file (sources the values from /e/d/console-setup)? either hal or xserver-xorg is probably where it should be, but jcristau thought it could be useful not just for X, which would mean hal should generate the file
<mvo> kirkland: hm, that seems to be a issue with the package itself, update-manager logs look ok, it selected a driver that it thinks was appropriate. does it not work with  neither-177 or -173?
<tseliot> kirkland: something's hiding the real error (I hope). Try adding Disable "dri2" to the Module section of your xorg.conf and then start x with this command: startx -- -logverbose 5
<tseliot> then send me the log again
<kirkland> mvo: i have not yet gotten nvidia to work with intrepid since I upgraded earlier tonight
<pitti> tjaalton: I don't particularly mind to put it into hal; the fdi is generated at package build time and then just shipped?
<pitti> tjaalton: what sort of information does it contain? It might or might not fit better into hal-inf
<pitti> o
<tjaalton> pitti: no, the script is run on postinst
<pitti> postinst? why's that?
<tjaalton> pitti: see http://people.ubuntu.com/~bryce/InputHotplug/console2fdi.sh
<tjaalton> well it needs the values from console-setup
<pitti> tjaalton: but what if the default file changes?
<tjaalton> pitti: hmm then it might be console-setup that should host it
<pitti> or the hal init script
<tjaalton> that's possible as well
<pitti> tjaalton: and we need to ship hal's 10-x11-input.fdi, too, I presume?
<tjaalton> pitti: yep
<dholbach> does the new intrepid kernel work for anybody in kvm?
<kirkland> tseliot: wanna have a look at my xorg.conf before I give it another go?
<kirkland> tseliot: http://pastebin.ubuntu.com/33934/
<tseliot> kirkland: it's "dri2" and not "dir2"
<tseliot> other than this, the file is ok
<kirkland> tseliot: doh!
<pitti> tjaalton: so, I'm ok with doing that in the hal init script for now; feels like a hack, but I don't have a better idea ATM..
<kirkland> tseliot: it *is* 3am in the morning ;-)
<tseliot> ï»¿kirkland: ah, you live in the US
<Q-FUNK> howdy! has the packages.u.c host gone offline?
<mdz> seb128: good morning
<kirkland> tseliot: yeah, silly me, i though, "I'll just upgrade to intrepid before going to bed, so I can start work next week all shiny and using the new stuff"  :-)
<seb128> hello mdz
 * kirkland goes restart X
<mdz> seb128: Keybuk told me that the plan was to go ahead and package the new gdm (as a separate package) in Ubuntu, is there anywhere I can get it?
<tjaalton> pitti: ok, cool. I'll discuss this again with bryce to see if there's a better "final" solution for it that also fits in debian (not sure if they even use console-setup yet)
<persia> About upgrade-manager pulling recommends on upgrade: can we detect cases where users have deliberately uninstalled packages?  Be frustrating for some people to find things they previously uninstalled coming back.
<seb128> mdz: https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu, ./autogen.sh && debuild on the code should work but be warned it doesn't log users on first boot on my box (need to be restarted and then log-in works, dunno why), settings are not applied, gnome-power-manager doesn't work correctly, etc
<mdz> seb128: thank you
<seb128> mdz: it builds a gdm-snapshot which conflicts on gdm and fast-user-switch-applet (the applet is in gdm now)
<mdz> seb128: the thread at http://mail.gnome.org/archives/gdm-list/2008-July/msg00024.html said there hadn't been a 2.23 release yet; is that still true?
<seb128> mdz: you can probably bzr merge on the current gdm trunk to try the current version
<seb128> mdz: no, they rolled a 2.23.
<seb128> mdz: no, they rolled a 2.23.2 tarball some days ago because somebody asked for that
<seb128> but they didn't put a lot of work on gdm since 2.22, the redhat guys who work on it have other focus this cycle apparently
<mdz> seb128: do you know of a page anywhere which lists the known regressions?
<kirkland> tseliot: following a reboot, I'm in gnome using nvidia
<kirkland> tseliot: this is the 173 driver, with the xorg.conf you saw earlier
<seb128> mdz: http://live.gnome.org/GDM/ToDo
<kirkland> tseliot: I am now going to press my luck and try the 177 driver ;-)
<mdz> seb128: thank you
<seb128> you're welcome
<tseliot> ï»¿kirkland: ah, then rmmod nvidia and modprobe nvidia would have done the trick. A reboot did it.
<tjaalton> kirkland: so you had the old kernel and nvidia module loaded?
<tjaalton> echo :)
<Q-FUNK> tjaalton: console-setup is not the default in debian, afaik
<kirkland> must have been....
<tjaalton> Q-FUNK: ok, thought so
<asac> pitti: tested and uploaded nspr_4.7.1+1.9-0ubuntu0.8.04.5_source.changes nss_3.12.0.3-0ubuntu0.8.04.4_source.changes with follow up fix for #245122 to hardy-proposed. let me know when its in, so i can individually verify each bug.
<pitti> asac: oh, so it did need a followup fix? o
<pitti> k
<asac> pitti: for update-manager yes. only dist-upgrade worked
<asac> pitti: the last upload drops the conflicts only
<asac> on libnss3 and libnspr4 (the old feisty packages built from firefox back then)
<asac> pitti: i kept the conflicts in intrepid branch so hopefully those packages get removed when users dist-upgrade to it
<kirkland> tseliot: okay, fyi, the 177 nvidia driver works too
<kirkland> all that's remaining is that splash appears to be broken
<tseliot> kirkland: great. Thanks for testing it
<kirkland> tseliot: no prob, thanks for helping me fix it
<seb128> pitti: are we supposed to use hunspell or myspell dictionnaries in intrepid?
<pitti> seb128: hunspell if available, but myspell dicts should work with libhunspell
<seb128> pitti: installing hunspell-fr removes thunderbird, is that expected?
<pitti> erm, no?
<pitti> Conflicts: thunderbird
<pitti> WTH?
<asac> urgh
<asac> whats that?
<pitti> hunspell-fr
<asac> yeah. but why conflicts?
<seb128> dunno
<asac> maybe that was added to force use of myspell?
<pitti> it has versioned conflicts to firefox, etc., but the tbird one is unversioned
<seb128> that's what I'm asking
<asac> (while back)
<gnomefreak> thats new
<asac> did we sync it?
<seb128> asac: openoffice.org-dictionaries (1:2.4.0~m240-2ubuntu1) intrepid; urgency=low
<seb128>  -- Chris Cheney <ccheney@ubuntu.com>  Tue, 01 Jul 2008 20:54:35 -0500
<pitti> asac: no, it's 2ubuntu1
<seb128> well, it has been merged not to long ago
<asac> hmm ... most likely the conflict comes from debian
<asac> from back when we renamed thunderbird to icedove
<pitti> right
<asac> let me check
<seb128> otherwise installing myspell-fr didn't work in evolution, it didn't list french
<seb128> hunspell-fr works correctly though
<asac> seb128: yes. the icedove conflict is versioned?
<asac> then we should just use the same version imo
<asac> for tbird
<seb128> asac: yes, icedove (<< 2.0.0.0-4)
<asac> yes. debian has unversioned conflict on tbird
<asac> seb128: the same versoin should be fine for us then
<asac> though i didnt do that package back then here
<asac> but it should
<asac> and since we are far ahead, that shouldnt matter anyway
<seb128> alright
<asac> seb128: can you test?
<seb128> test what?
<seb128> hunspell spell checking in thunderbird?
<asac> if hunspell-fr works fine :)
<asac> thought you already installed it.  if not i can do that
<seb128> I'm reinstalling thunderbird
<seb128> I did install hunspell-fr to get evolution spell checking working
<seb128> which removed thunderbird
<seb128> a minute, it's downloading
<asac> right. please force it. i am not 100% sure if we added a patch to icedove 2 for that or if that was in 1.5
<seb128> I'll force the install to test
<davmor2> asac: I don't know whether you caught this one or not https://bugs.edge.launchpad.net/ubuntu/+source/ubufox/+bug/253762 ? I thought I'd let you know asap though so it could get fixed :)
<ubottu> Launchpad bug 253762 in ubufox "Intrepid: Ubufox no longer asks to install flash when going on youtube" [Undecided,New]
<seb128> asac: yes, spellchecking works fine in thunderbird when hunspell-fr is installed
<asac> seb128: good.
<asac> thanks
<ion_> benc: Youâve got mail. Btw, Cc: cking@ubuntu.com bounced.
<lifeless> mvo: syntax error:P
<mvo> lifeless: *cough* that comes from editing source code before the first cup of tea
<pitti> thekorn: good morning
<thekorn> hi pitti
<pitti> thekorn: was the API break in bug 254556 deliberate (cleanup) or just a glitch?
<ubottu> Launchpad bug 254556 in python-launchpad-bugs "API breakage: 'ConnectBug' object has no attribute 'Error'" [Undecided,New] https://launchpad.net/bugs/254556
<thekorn> pitti, honestly, it was not a glitch
<thekorn> but I understand that this is unfortunate,
<thekorn> so, I think the best way is to recreate Bug.Error
<pitti> depends on how ugly it is to reinstate it, I guess
<thekorn> pitti, there are a few more changes: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/changes_0.3
<thekorn> pitti, i will think about it later today, and comment on this bug
<pitti> thekorn: ah, thanks for that
<pitti> thekorn: alternatively I need to switch to a more stable branch in the retracers, and cherrypick the html screenscraping fixes myself
<thekorn> pitti, I'm working on integrating launchpadlib into py-lp-bugs
<thekorn> so no need for screenscraping anymore
<pitti> thekorn: oh, already? great!
<ion_> What kind of API does launchpad offer?
<pitti> ah, https://code.edge.launchpad.net/launchpadlib is new to me
<ion_> REST?
<pitti> ion_: yep
<ion_> Neat
<pitti> kees: hm, your recent "fix bold fonts in the terminal" made things much worse for me; did you hear other reports about regressions?
<pitti> kees: (before it looked just fine)
<Ng> pitti: erk, worse how?
<pitti> some characters, like 'm' now look very untidy
<ion_> Yeah, m became noticeably uglier recently.
<pitti> kees, Ng: http://people.ubuntu.com/~pitti/tmp/boldfonts.png
<Ng> huh. is the patch being carried in Intrepid?
<pitti> I just remember that kees recently uploaded something to intrepid, but I forgot the package name; easy enough to find out again, I guess
<norsetto> asac: guess what I'm going to ask you?
<bigon> hi, is there any reason that ffmpeg in intrepid doesn't contains anymore the h263 encoder by default
<bigon> https://bugs.launchpad.net/ekiga/+bug/254201
<ubottu> Launchpad bug 254201 in ffmpeg-debian "feature regression: ffmpeg lacks some video encoders (like h263+, MPEG4, maybe more...)" [Undecided,New]
<Spads> pitti: .. ical gekommen?
<pitti> Spads: that's a small part of my IRC window, I just moved it there to avoid copying my entire screen
<pitti> kees: can't find it right now, which package was that?
<Ng> his font patch ought to be in libvte
<pitti> ah, indeed
<asac> norsetto: update?
<asac> norsetto: i have a huge backlog ... saw that i had a mail or two from you
<asac> norsetto: if its important tell me ;=
<norsetto> asac: I was just going to ask if you received an email from me ;-)
<asac> even two iirc
<norsetto> asac: its gnome-mplayer 0.6.3-2 which closes the ftbfs if built twice in a row bug
<asac> my mail server was down for a week ;)
<asac> norsetto: ah cool. you have it uploaded?
<norsetto> asac: yes, its in mentors, link in my email
<norsetto> asac: Justin Case: http://mentors.debian.net/debian/pool/main/g/gnome-mplayer/gnome-mplayer_0.6.3-2.dsc
<asac> norsetto: i dont have my debian system here. might take a few days till i can access that again :(
<norsetto> asac: well, what other choice do I have?
<asac> norsetto: stand still ... i might be able to do it on Wed if all works out well
<asac> if it takes longer we need to find some other sponsor
<norsetto> asac: I won't move ;-) Danke!
<asac> np
<tjaalton> hmm, shouldn't attached media be automatically umounted if the user yanks the device out without ejecting it?
<ogra> yep
<ogra> and you should get a "unsafe device removal" msg
<persia> What if the file cache is dirty?  How about if the user reinserts it later?  What about cases where there's no physical removal event reported by the HW?
<tjaalton> I've seen the same media being listed by df/mount on two different machines, and another user reported that the media was shown on the desktop (but inaccessible of course)
<ogra> persia, i doubt you can do anything for the latter case
<persia> ogra: Well, the Luddite in me likes to say we should train users to unmount before ejecting as a workaround, but you're probably right :)
<ogra> the ltsp developer in me says we should have a way to overcome unmounting ;)
<hwilde> embedded me says we should make the device manufacturers guarantee reads and writes and not corrupt even if stupid users eject
<persia> ogra: Well, we could stop supporting removable media...
<ogra> well, we could switch the whole system to ltspfs :P
<ogra> (which doesnt support unmounting)
<persia> And is nicely atomic.  Still means one needs to shut down to remove the USB key.
<ogra> ??
<ogra> no
<persia> Maybe a udev hook on device removal into ltspfs to kill the FUSE?
<ogra> you just yank it out if the progressbar of your filemanager is gone
<ogra> ltspfs devices are always unmounted ... only while write operations are in progress they are mounted
<Mithrandir> ogra: so they're not POSIX, then
<Mithrandir> as in, it's not a POSIX file system.
 * persia reads LtspFSAutomount, having obviously missed something
<ogra> Mithrandir, they are whatever FS is on the device ... ltspfs sits on top, its a network FS
<ogra> persia, the documentation is a bit sparse ...
<Mithrandir> ogra: that's irrelevant.  Or do you wait until all files are closed before you umount?
<ogra> yes, indeed
<persia> ogra: Very much so.  I'll take your word about the umounting, as I can't see any documentation that indicates it's safe to pull a device and reinsert later, while preserving user semantics.
<ogra> actually they are forcefully closed until they change
<Mithrandir> that's even worse, then.
<persia> The only issue is the 2 second sleep cycle while background mounting devices on each new read.
<Mithrandir> since you can't open file, unlink file, continue reading and writing and then the file goes away when you close it.
<ogra> Mithrandir, not in the ltsp case where we have the guarantee that only the one user on the terminal acesses them ...
<ogra> other users cant acess the devcie
<persia> ogra: What takes down the FUSE filesystem on device removal?  Is there another udev rule not listed under "udev intereaction"?
<ogra> so even if you pull out the device while openoffice is still open you will have a saved copy of the changes of the last two seconds
<ogra> persia, right, there are two udev rules
<ogra> one for mounting, one for unmounting
<persia> ogra: In practice, how noticeable is the 2 second delay?
<ogra> not at all
<persia> Hmm...  Not going to happen in the next 24 days, but tempting to add to the agenda for the next UDS.
<ogra> and i havent had any reports of dataloss or anything within the three years we use ltspfs in ltsp
<persia> Well, I can construct a scenario that generates data loss or data corruption, but it would do that with the current model as well.
<ogra> in fact its an assembly of autofs, fuse and some glue
<ogra> you could do similar things locally with autofs afaik
<persia> Yes, but you still want the FUSE layer to provide the atomicity
<ogra> right
<persia> (Otherwise Mithrandir's comments suddenly become relevant)
<ogra> and the caching of the device contents
<persia> Well, for local, I'm not sure full caching is so important: imagine inserting a 700MB CD on a 384MB RAM system.
<persia> Caching of open files is critical for atomicity, but that's only one file at a time.  Might choke on some DVDs though.
<persia> (Depending on the cell progression definition, etc.)
<ogra> it wouldnt cache 700M :)
<Mirv> mvo: ubuntu ddtp stuff would seem to work. the omissions wrt Debian are probably because of different versions or Ubuntu-specific changes to package descriptions
<ogra> just the directory structure ... so it appears transparently to the user while not being mounted
<mvo> Mirv: aha, nice. happy to hear that
<ogra> the ltspfs client side pretends that the device is mounted all the time ... for that you need to cache the structure, but not the actual content
<Mirv> mvo: what about the gnome-app-install's title (shown in list and detailed view) and description (shown only in the list) strings, are they coming from .desktop file's Name and Comment or where? what about commonly seen stuff like gstreamer codecs, are they untranslatable at the moment (eg. "Gstreamer ffmpeg video plugin" and "Codecs to play mpeg, divx, mpeg4, ac3, wmv and asf files" strings)?
<Mirv> (since those don't have .desktop files)
<mvo> Mirv: the name and comment come from the desktop files in app-install-data
<mvo> Mirv: good point about the codec stuff, I think I need to add some magic to make that app-install-data package iimportable into launchpad
<mvo> Mirv: feel free to file a bug about that
<Mirv> mvo: ok, I'll do that
<mvo> Mirv: thanks!
<persia> ogra: Ah.  That makes more sense.
<Mirv> (bug 254628)
<ubottu> Launchpad bug 254628 in app-install-data-ubuntu "Make it possible to translate eg. codec name/description strings" [Undecided,New] https://launchpad.net/bugs/254628
<Keybuk> not for the first time, I wonder what wyciwyg:// means
<persia> Keybuk: What you cee is what you get
<ogra> when you cry i whack you gently ?
<Keybuk> persia: all I see whenever I see those URLs is a white page and a spinner
<persia> Keybuk: Which browser?  epiphany loads them for me.
<Keybuk> epiphany
<persia> Hrm.  Maybe because I'm still running hardy?
<Keybuk> as am I
<Keybuk> http://stephenfry.com/blog/
<Keybuk> click "Read full column Â»" for the second article ("Well worth the wait")
<Keybuk> same in Firefox
<persia> Hmm.  For that one I'm getting a spinner.
<persia> I had a couple from liferea earlier that worked (although I forget which, but noticed as I had a browser crash at the same time, and needed to recover the session)
<persia> Ahhh....  "What you cache is what you get"
<persia> Keybuk: Looking a bit deeper, it seems that it's an AJAX call that fails on the cache load.
<persia> Link from the column title (above) works if you just want to read.
<Keybuk> yeah, I can read it
<Keybuk> I just loaded it in Safari instead
<persia> Safari has a GNOME client?
<Keybuk> well, epiphany-webkit is close
<Keybuk> but I just used safari itself
<Keybuk> not on GNOME :p
<persia> Oh, I see.
<ion_> Ew. MacOSX has even worse font rendering than what Ubuntu has nowadays. :-)
<pitti> tkamppeter: can I somehow tell the openprinting.org DB to just give me packages with PPDs, not those which update ghostscript etc.?
<pitti> tkamppeter: I think it'll lead to nothing but trouble to replace system packages with the alienized rpms, we should rather provide them in -backports and make jockey look for those; but packages with PPDs would be perfect
<pitti> tkamppeter: I know that I can query for the PPD *files*, and for packages, but I don't know how to query for PPD-only packages
<hwilde> where is the default runlevel specified now that inittab is gone
<ion_> hwilde: inittab ;-)
<pitti> hwilde: /etc/event.d/rc-default if inittab isn't there any more
<ion_> hwilde: See /etc/event.d/rc-default
<hwilde> there we go
<hwilde> gracias amigos
<tkamppeter> pitti, do you mean driver packages?
<tkamppeter> pitti, there are no PPD-only packages (yet).
<superm1> pitti, since that bug in lrm/lbm was resolved re wl, could you provide me with your handler to test out with it?
<tkamppeter> Packages like CUPS, Ghostscript, ... will never come as answer to a driver query.
<superm1> i didn't see it in any (apparent) locations in your bzr branches
<tkamppeter> pitti, package manager info coming with query answers is always only for a repository containing that particular driver, so no danger of unwished replacement of CUPS, Ghostscript, ...
<pitti> superm1: it's on http://people.ubuntu.com/~pitti/tmp/jockey-wl/
<superm1> pitti, ah okay thanks
<pitti> tkamppeter: right, but I saw e. g. a new gutenprint package there
<tkamppeter> pitti, should the drivers perhaps all get renamed, with the package name and all files linked into places outside /opt preceeded by "lsb-"?
<pitti> tkamppeter: that'd still install two gutenprint versions in the system, no?
<tkamppeter> pitti, yes this would only avoid conflicts. And in printer lists in s-c-p they would be recognizable by different NickNames, with version number, "LSB", ...
<tkamppeter> s-c-p would have to point to the downloaded LSB version after a download so that the user gets his downloaded driver.
<pitti> tkamppeter: hm, that might be preferable in the future, but I think it'd require a discussion on a ML first
<pitti> tkamppeter: do you plan to eventually provide packages of PPD files? (as we discussed in London with Tim)
<tkamppeter> pitti, on which ML?
<pitti> tkamppeter: some openprinting.org, and driver-backports maybe?
<tkamppeter> I can make a script which does such PPD-only packages, and the query API has already the possibility to filter by architecture, So a requester could give "noarch" as architecture and not the architecture which the system actually is. This would lead to only packages without binary executables being listed.
<superm1> pitti, i'll give feedback over email
<RainCT> pitti: Hi. Perhaps I'm missing something but I've just noticed that manpages-de's copyright file (, beside being generate at build time by joining debian/copyright.in and upstreams COPYRIGHT, what I'm not sure if it's allowed,) doesn't contain any copyright information, just a "look at the files" notice (http://paste.ubuntu.com/34055/plain/) and that some of the files are released under the GPL but that there isn't any copy of it included in the
<jpds> RainCT: You got cut off at the end.
<RainCT> jpds: what's the last word that arrived?
<jpds> included in th...
<RainCT> ... included in the source. Perhaps  you could you have a look at it?
<pitti> RainCT: indeed, thanks for spotting; could you please report that as a Debian bug?
<pitti> RainCT: I guess the list of copyright holders is the translators list, but that should be clarified
<RainCT> pitti: sure. with severity critical?
<pitti> RainCT: I'd use 'serious'
<RainCT> OK
<pitti> RainCT: danke
<RainCT> pitti: is the "generated at build-time" part allowed?
<pitti> RainCT: it's not common, but there are several packages which do that
<pitti> RainCT: it should be done on clean, not on build, though
<pitti> so that the one in debian/copyright is always up to date when building/uploading the source
<RainCT> it's in binary-indep
<ogra> asac, did warren contact you ? he wanted to set up a nspluginwrapper ML snce upstream doesnt seem to run one
<asac> ogra: nope ... well. still havent finished reading all mail though
<ogra> heh
<ogra> yeah, i still munch on over 2000 mails in ubuntu-users that piled up while i was travelling ...
 * ogra knows how that feels
<hwilde> you are like bruce almighty
<hwilde> select all, grant prayer
<ogra> haha
<ogra> i sometimes do that, especially with that list ... but there were some conflicts before i left that i'd like to follow so i have to read them this time
<ogra> but to much work atm to even care
<warren> ogra: I'm giving upstream a chance to respond before I do this.
<ogra> warren, ah
<asac> bryce: there?
<upstream> just do it
<hwilde> ;)
<hwilde> is there any way to benchmark or speedtest the usb subsystem?
<hwilde> i think my 1.0 and 2.0 controllers are freaking out man
 * hwilde misses good ol serial ports
<hwilde> anybody know what usbmon is for?   /lib/modules/2.6.24-16-generic/kernel/drivers/usb/mon/usbmon.ko
<hwilde> or how to make it go
<StevenK> hwilde: It's used to snoop or monitor USB buses, the documentation for it is in linux-doc
<hwilde> StevenK, I can't seem to make it say anything anywhere.    I have mounted debugfs as instructed
<StevenK> hwilde: You don't see anything in /sys/kernel/debug/usbmon
<StevenK> ?
<hwilde> StevenK, it made some files but what are they
<hwilde> they are all zero filesize
<hwilde> ? is right
<pitti> could someone please do "ck-list-sessions | grep display" and /msg me the result?
<StevenK> hwilde: They're sockets. The kernel will dump stuff into them.
<StevenK> pitti: On Hardy or Intrepid?
<pitti> doesn't matter
<hwilde> StevenK, oh...
<pitti> StevenK: merci
<StevenK> pitti: No trouble :-)
<StevenK> hwilde: The documentation suggests using 'cat' :-)
<hwilde> yeah I'm just not seeing anything there
<StevenK> hwilde: Are you doing something with the bus?
<kees> pitti: still around?  Package is "vte".
<pitti> kees: good morning! yup, I figured it out by now
<kees> from your boldfonts.png, I'm not clear on what I'm looking at.
<Spads> kees: ical gekommen!
<pitti> kees: look at the 'm's, they look really bad
<kees> pitti: that's the actual bold face for that font.
<Spads> pitti: it's an improvement over this: http://zork.net/~nick/screenshots/pretty-colors.sized.png
<pitti> kees: weird, I never noticed that before your change
<kees> pitti: correct, before, it wasn't actually using bold faces.
<kees> pitti: and Spads's example is the problem I fixed -- double-strike is not bolding.  ;)
<tkamppeter> seb128, hi
<pitti> kees: ok; well, I just thought you had an idea about it
<Spads> the 'm' turned into a block, and the compression on "Ed" was way too tight
<kees> I have a very long analysis here: http://www.outflux.net/blog/archives/2008/06/22/bold-fonts-in-libvte-gnome-terminal-terminator/
<kees> (well, the analysis is in the linked blog post from a year ago)
<kees> pitti: this is basically a 7 year old bug in vte
<kees> (that I believe I have fixed now)
<kees> pitti: as another example of the wrongness of double-strike: http://www.outflux.net/fixed-font-comparison.jpg see the "CAP" faces
<mathiaz> Koon: I've looked at my suggestion wrt to handling webapps ?
<Koon> mathiaz: yes. I pushed all webapps in /usr/share/<package-name>/<webapp-name>
<hwilde> StevenK, I think I am doing something with the bus....  do you know what the numbers mean 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u  ?  I am seeing stuff out of the sockets now but which is which
<mathiaz> Koon: excellent
<StevenK> hwilde: The numbers are the bus numbers, and the characters are the format of the data. All of this is explained in the documentation.
<hwilde> StevenK, where is this magical documentation world where all my questions are already answered
<StevenK> hwilde: In the linux-doc-2.6.24 package, usbmon.txt
<hwilde> StevenK, tnx im on server version no extra frills like that
<StevenK> hwilde: Or http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt
<hwilde> man I feel like heisenberg now
<hwilde> as soon as I modprobe usbmon, the errors are not happening anymore
<lunartear> has ubuntu not updated bind9 to 9.3.5-P1  on Ubuntu 6.06.1 LTS Dapper to patch the "DNS Insufficient Socket Entropy Vulnerability."?
<kees> lunartear: it has been updated, yes.  we backport fixes rather than doing full-version updates usually.
<lunartear> kees, odd i thought i had backports enabled
<lunartear> hmm doublechecks
<kees> lunartear: "backports" is not an official repo with security support.  You just want -security: http://www.ubuntu.com/usn/usn-622-1
<lunartear> can i enable a repo for security?
<kees> lunartear: -security is a repo.  :)  there's release, -updates, and -security.  (and -backports, but it does not have security support)
<lunartear> deb http://security.ubuntu.com/ubuntu dapper-security main restricted   is enabled
<kees> lunartear: then you're in good shape.
<lunartear> hrm.. perhaps im checking the version improperly then..  apt-cache showpkg bind9?
<lunartear> is that whats installed or whats available
<jdstrand> lunartear: apt-cache policy bind9
<jdstrand> (it will show what's available and what's installed)
<lunartear> yeah im not seeing 9.3.5 listed
<kees> lunartear: as I mentioned, we patch release versions with upstream fixes rather than doing full version bumps.  You're safe if your bind's version matches the version here: http://www.ubuntu.com/usn/usn-622-1
<lunartear> oh alright... that confused me
<lunartear> I should be patched then
<lunartear> that patches the dns cache poisoning vulnerability right?
<kees> lunartear: cool, yeah -- it can be a bit confusing.  if you're interested, the security updates are announced here: http://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
<kees> lunartear: correct.  that vulnerability is also known as CVE-2008-1447
<lunartear> great thanks for clarifying
<lunartear> kees, is that list low traffic?
<lunartear> nvm it says low traffic on the page.. i just didnt see it
<kees> lunartear: yeah, it's got maybe a dozen or more posts a month: https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-July/date.html
<pitti> slangasek: so, I sorted out the pam_ck_connector/gdm interference, so that I can now use common-session
<pitti> slangasek: what's the recommended way of adding that in the postinst/removing in prerm now? sed? a-c-c profile and call from postinst? block on pam-config-framework implementation?
<pitti> slangasek: or using sed/a-c-c for now until p-c-f is implemented?
<pitti> jdstrand: ^ would like to hear your opinion as well
<jdstrand> pitti: yea for common-session
<hwilde> StevenK, do you know about this usbmon stuff or are you just good with the linux docs
<pitti> jdstrand: ? you mean I should use a-c-c now?
<jdstrand> pitti: well, sed wouldn't be policy compliant, and a-c-c could be, if we develop a policy. that said, slangasek's spec will obviate this use-case of a-c-c
<pitti> jdstrand: why wouldn't sed be policy compliant, out of interest?
<StevenK> hwilde: The latter
<jdstrand> pitti: we should develop a policy compliant way to call a-c-c if slangasek isn't done in in time
<bryce> morningh
<jdstrand> pitti: oh right, I lost my head for a second-- I was thinking common-session was a conffile
<pitti> jdstrand: I see that sed would be brittle and not really elegant, but in terms of Policy compliance a-c-c and sed shouldn't make a difference?
<jdstrand> pitti: it was login that was the conffile
<pitti> jdstrand: ah, ok
<bryce> asac, what's up?
<pitti> jdstrand: right, otherwise I'd have used login straight away
 * jdstrand nods
<pitti> but now I patched pam_ck_connector hard enough to cope
<mdz> this is the third time I've found that acpid has mysteriously died on my desktop
<mdz> has anyone else noticed this?
<mdz> it's easy to tell when it happens because of this:
<mdz> 7.9M /var/log/Xorg.0.log
<pitti> mdz: does it trigger apport for you? I don't have any recorded crash here
<jdstrand> pitti: my opinion is to wait for slangasek-- if it doesn't work out, then I'd be more than happy to help with a safe way to use a-c-c in maintainer scripts for the general case
<mdz> pitti: no, it doesn't
<pitti> jdstrand: ok, thanks
<mdz> pitti: and I wasn't able to catch it with gdb when I left it attached overnight
<mdz> pitti: gdb showed it had received SIGTERM but I couldn't tell from where or when
<pitti> slangasek: ok, please let me know what you prefer (using sed now, and finish my spec, or blocking on p-c-f and doing the auto-enabling after feature freeze)
<mdz> pitti,mvo: I just had a package update fail in update-manager (file overwrite error) but it didn't generate a crash report
<kirkland> Keybuk: hiya, what time does the update run on merges.ubuntu.com to look for updated packages in debian-unstable?
<mdz> mvo: I'd like to report the bug but can't find a log anywhere
<mdz> is linux-restricted-modules-envy-2.6.24 useful in addition to the dkms-ified packages?
<Keybuk> kirkland: hourly
<kirkland> Keybuk: interesting... okay, so ecryptfs-utils-53-1  hit debian-unstable 2 days ago, but it's not showing up on merges.ubuntu.com
<Keybuk> it's out of disk space I think
<kirkland> Keybuk: it was recently promoted (last week) from universe to main, if that might cause a hiccup
<mdz> doko: I just saw a file conflict in the latest dovecot update, but unfortunately lost the error message (see above)
<kirkland> Keybuk: the disk space issue, is that something you can solve, or do I need to ask elmo or someone?
<Keybuk> kirkland: it's been on IS's plate for a couple of years now
<mdz> Keybuk: about 1.3 years
<mdz> Keybuk: and it was marked resolved until today
<Keybuk> it was, errantly
<Keybuk> I unresolved it when I realised that the ticket had in fact been closed
<Keybuk> as I'm sure you remember, the attempt to add more disk hit hardware failure, and was never, in fact, completed
<Chipzz> lunartear: also, for future reference, this is not a support channel. please ask these questions in #ubuntu in the future
<lamont> heh.  requestsync should handle the case where the current-ubuntu version of the package does not exist in changelog by doing something more intelligent than copying all of debian/changelog
<tkamppeter> seb128, ping
<seb128> tkamppeter: if you want a reply better to give some context in your pings
<asac> bryce: i have a system with a logitech bluetooth mouse - which doesnt work out of box with livecd and not after install. any hints how i can set that up?
<tkamppeter> seb128, sorry, I wanted to see at first whether you are really here.
<tkamppeter> seb128, it is about printing output of GTK/GNOME-based apps.
<tkamppeter> seb128, did you already do the changes on the GTK library so that all these apps produce PDF when sending a print job?
<elmo> Keybuk: that's not strictly accurate, it was in fact upgraded, just not to .5Tb
<seb128> no
<seb128> am I supposed to do that?
<tkamppeter> seb128, yes, as then we get a much more stable and reliable printing (did you not remember from London?).
<seb128> I remember you saying that need to be changed
<Keybuk> elmo: right, but I thought that was only a temporary measure?
<seb128> but there is no open bug or spec assigned to me for that as far as I know
<tkamppeter> With PDF as printing output the printing system can always separate, re-order, scale, select and otherwise manipulate pages. With PostScript this is not always possible.
<bryce> asac, which driver are you using for it?
<Keybuk> elmo: I'm not blaming you for any inactivity btw; since the ticket wasn't open
<tkamppeter> There is a spec on the PDF printing workflow. Should I add a bug with link to the spec.
<bryce> asac, fwiw, we're right in the middle of switching input-hotplug on; possibly if you wait a day or two for the dust to settle, it may just work
<elmo> Keybuk: I'm not sure - I thought you were happy with the space as is, but I may well be wrong and clearly failed to update the ticket to even document the problems we had with the .5Tb drive configuration
<ogra> bryce, do you know how far input-hotplug will support touchscreens ?
<tkamppeter> seb128, https://blueprints.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format
<bryce> ogra: no I don't - it's woefully underdocumented.  (I similarly don't have a clear idea on if it supports bluetooth).  However I understand that it *should* support both, so any problems would be handled as regular bugs.
<ogra> bryce, i noticed now that i have seen more than two touchscreen devices that they all tend to use /dev/input/eventX and was wondering if we couldnt unify that to have a /dev/input/touchscreen link put in place by an initscript
<seb128> tkamppeter: right, this spec is not assigned to me so technically I'm not the one supposed to do those changes
<ogra> that would ease configuration a lot i bet, but i dont know how much it would clash with hal-input or related functionallity
<tkamppeter> seb128, All apps outputting PDF would even eliminate all PostScript page management problems even if there are no special PDF filters (see today's mails where I CCed you).
<Keybuk> ogra: why do you need a symlink?
<tkamppeter> seb128, so I should assign you to the spec? In reality there are many people where each one has to do a certain part.
<Keybuk> elmo: I think I said I'd be happy for a year ;)
<ogra> Keybuk, because the eventX can differe from system to system ...
<Keybuk> elmo: though MERGE MONSTAH WANTS MOAR DISK PLZ
<Keybuk> ogra: but why do you want the symlink?
<tkamppeter> seb128, or should I post bugs then, one per person who is supposed to do something and link them all to the spec.
<bryce> ogra: what needs to know that?
<seb128> tkamppeter: talk to whoever is supposed to approve the spec to get it assignee to somebody
<ogra> Keybuk, having something that unifies all touchscreens to /dev/input/touchscreen by something like that: http://paste.ubuntu.com/34122/ will make it easier to have a common configuration
<seb128> tkamppeter: I can try to have a look this cycle but my schedule is already pretty much booked
<bryce> ogra: afaik they're trying to get away from permanently named devices since you get conflicts with multiple of the same device hooked up
<Keybuk> ogra: but what configuration?
<ogra> bryce, curretly i see a lot of evtouch devices that have very unique configs and all tend to differ in the devce name in xorg.conf
<ogra> if hal-input fixes that, then fine
<Keybuk> doesn't input-hotplug solve this by taking away the need for configuration entirely? :)
<ogra> if not i'D like to have a unified device name all touchscreens can use
<Keybuk> how can all touchscreens use it at the same time?
<ogra> Keybuk, well, i dont see *any* attempt to include touchscreens in hal-input yet
<ogra> *sigh*
<tkamppeter> seb128, is it very complicated to switch GTK printing output from PostScript to PDF?
<ogra> tochscreens on different systems indeed
<seb128> tkamppeter: no idea I don't know this code
<ogra> i.e. my laptops touchscreen uses event10
<pitti> mdz: l-r-m-envy> no, it's not, that upload was for hardy
<ogra> my Q1 uses event2
<ogra> etc etc
<Keybuk> ogra: I can tell you exactly how long before a device comes out with two touchscreens
<Keybuk> about one week after we ship code that assumes only one :p
<mneptok> input-hotplug is not a suitable topic for a development channel. please abide by the CoC, and stop arousing support geeks.
<ogra> well, then you can have touchscreen1 and 2
<tkamppeter> seb128, the Qt/KDE apps already output PDF, Riddell has only changed some config setting.
<Keybuk> and then *those* will swap
<ogra> still better than having to have a specific configuration for each and every combo
<mdz> pitti: ah, of course, thanks
<Keybuk> ogra: attach the configuration to the particulars of the device
<Keybuk> not to some assumed name
<Keybuk> ie. "the touchscreen that is 640x480 is configured as ..."
<seb128> tkamppeter: how is that revelant there?
<ogra> Keybuk, yes, thats what  would expect from hal-input
<Keybuk> that's what I would expect too
<ogra> but i dont see anything going on there ... whih means we'll have to stick to xorg.conf for such devices until its solved
<ogra> at least thats what i expect for intrepid
<Keybuk> have you tested it?
<Keybuk> things may just work out of the box without need for special configuration
<ogra> heh
<Keybuk> I doubt touchscreens are sufficiently different from other devices to need their own?
<ogra> i doubt thats true for touchscreens
<ogra> they need calibration
<Keybuk> so do joysticks and tablets
<ogra> at least the first time you use them
<ogra> and also for tap events
<Keybuk> so do touchpads
<ogra> all touchpads i had yet worked fine as mice ... touchscreens wont
<ogra> they need special treatment and i dont see that happening yet
<Keybuk> you can always contribute the special treatment patch, remember
<Keybuk> hal-input is not large
<ogra> sure
<emgent> heya
<mneptok> Keybuk: ping MagicFab. his touchscreen cannot function until a calibration method is found. he has filed LP bug reports, IIRC.
<mneptok> ogra: ^^
<Keybuk> mneptok: xorg.conf provides this calibration method?
<mneptok> Keybuk: it does not
<asac> bryce: err, its hardy still :)
<asac> bryce: how do i find out which driver is used? i just tried to use what happens by default
<ogra> Keybuk, if he can use the evtouch driver it is possible but massively painful to do it in xorg.conf
<Keybuk> mneptok: then I don't see how that contributes to the discussion
<asac> which is not much. the bluetooth symbol appeared on desktop ... but input is enabled and it doesnt find the mouse
<mneptok> Keybuk: mouse accel and other X settings do not affect the screen, IIRC
<ogra> mneptok, do you know if his touchscreen functions but is only miscalibrated ?
<mneptok> ogra: exactly that
<ogra> then chances are good that he cn solve it with a bit of effort
<Keybuk> the only reason to have a /dev/your/mom is for easy access
<Keybuk> and as a key for a configuration database of some kind
<Keybuk> if you're doing configuration, you should use a better key than a name, since names change
<Keybuk> most devices have uniquely identifying information, such as a serial number
<Keybuk> and if not, at least semantically identifying
<ogra> right thats the problem and thats why i wanted a unified name :)
<ogra> device names change
<ogra> so if i work on mobile and have ten different devices i need to suport i need ten different hardcoded configs atm
<Keybuk> no, you have ten different dynamic configs
<ogra> currently not
<Keybuk> this is #ubuntu-devel
<Keybuk> currently is uninteresting ;)
<ogra> i need to know as which event device the touchscreen registers in which hw config
<ogra> thats one difference among all devices that could be solved by devce name unification
<Keybuk> so just iterate input devices for touchscreens
<ogra> well, not all touchscreens give you the right info ...
<Keybuk> they give you enough information to map to your configuration db
<ogra> my laptop sees my touchscreen actually as touchpad, thats what the device identifies as
<Keybuk> imagine a scenario
<Keybuk> where /dev goes away entirely
<ogra> if i wouldnt know the manufacturer and that it actually is a touchscreen it couldnt tell which one is touchpad and which one is screen
<Keybuk> and instead you just have a "magic path" to a device that open() understands
<Keybuk> if you start relying on device names being uniquely identifying, you will be broken by that change
<ogra> right
<Keybuk> if you bully up now and deal with the fact that there are many input devices on a system, which are many different types
<Keybuk> and each one may need its own configuration
<ogra> but if the device per se doesnt give any useful info about itself how is hal supposed to handle it correctly ?
<Keybuk> then you will not be broken by that, or any other, change
<Keybuk> if the device has no useful information, how is _anything_ supposed to handle it correctly?! :)
<Keybuk> "Generic Input Device on USB Hub #1 Port #2"
<bigon> infinity, are you around plz?
<Keybuk> assuming it's internal, that's sufficient for a configuration db as a fallback when you have no serial number, etc.
<ogra> wll, i can hande it manually through xorg.conf by finding out thet IDEACO is a touchscreen manufacturer, calibrating it manually and after computing the values against my screensize i can then add 20 lines to my xorg.conf ...
<Keybuk> you can do that in HAL
<Keybuk> HAL can have an FDI file that tells it that IDEACO is a touchscreen
<ogra> right
<Keybuk> and then the settings daemon can use that to look up the configuration for the device and apply the calibration
<Keybuk> the great thing being that this then works if you have two touchscreens ;)
<Keybuk> and you can change the calibration on the fly
<Keybuk> and all sorts of "omg, it's the end of the dark ages" goodness
<ogra> indeed, i know how is *supposed* to be :)
<ogra> *its
<Keybuk> then what's the argument? :)
<ogra> i dont see it happening yet
<Keybuk> *make* it happen ;)
<Keybuk> you know how to code, and use patch, and stuff
<Keybuk> :p
<ogra> heh, do you have some spare hours you can send me ?
<Keybuk> I'm in sore need of them myself
 * ogra lols on a sidenote, reading the hal ML and OLPC people complaining that battery polling breaks their sound 
<Keybuk> (and we all know that if a short-term hack of a symlink name was added, nobody would *ever* do the work to stop using that because there would be always other things to do, and then you'd complain and bitch when it stopped working later down the line because such things become impossible)
<ogra> well, proper would be to do it in a wider scope like having some code that handles i and then colect lshal output from users to get fdi files together but i simply miss the time for such a project
<ogra> *handles it
<Keybuk> isn't that the hardware database? :p
<ogra> ask the maintainer :P
<ogra> i havent touched the hardware db since i work for canonical ... (apart from minor ui fixes)
<Connecting> HEY PEOPLE
<ogra> and luckily it was removed from the archive in intrepid
<Connecting> OK OK I GET IT
<Connecting> shut the
<Connecting> f up
<Connecting> :P:
<tomaw_> Connecting: enough, thanks :)
<Connecting> :P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P:P
<Connecting> ok...
 * Connecting wonders to himself ''where did everyone go?''
<bryce> asac, anyway I don't have bluetooth devices myself, but it sounds like using either hidd to set it up dynamically, or configure it manually in xorg.conf (using evdev) might work.  An example of a static config with settings specified is here:  http://ge.ubuntuforums.com/showthread.php?p=5365458
<mvo> mdz: could you please check if /var/log/apt/term.log contains the error?
 * Connecting asks himself where did all these nerds come from?
<mdz> mvo: it does, thanks
 * Connecting does not get an answer
<mdz> mvo: oddly, the mtime on that directory didn't change when I ran the update, I guess only when the logfile is rotated
<ogra> thanks
<mvo> mdz: oh, interessting
<mdz> mvo: any idea why there's no crash report?
<stgraber> then change Drupal's ACL to only let people with that same role access everything else
<stgraber> > _______________________________________________
<mvo> mdz: not sure, I will check
<stgraber> sorry, buggy touchpad+irssi ...
<mdz> doko: bug 254721
<ubottu> Launchpad bug 254721 in dovecot "dovecot-imapd: trying to overwrite `/usr/lib/dovecot/modules/imap/lib11_imap_quota_plugin.so', which is also in package dovecot-common " [Undecided,New] https://launchpad.net/bugs/254721
<mvo> mdz: it didn't generate anything at all in /var/crash? or was it just not picked up by update-notifier
<mdz> mvo: nothing in /var/crash
<mdz> mvo: it did pop up the error dialog to show me the error
<mdz> mvo: then I closed it, thinking I would get a crash report to submit
<lukehasnoname> who do I bug about getting new nvidia drivers into Hardy?
<mvo> mdz: and that is for #254721 ? I will try to reproduce it
<mdz> mvo: yes
<lukehasnoname> tseliot? I know I talked to someone before and they said "It would be too much change for an LTS" but, isn't hardware support one of the few things we update on LTS?
<mdz> mvo: do you want dpkg.log or anything else?
<mdz> lukehasnoname: we do updates for hardware compatibility in LTS, but in a fairly strict way (only for things which we are explicitly trying to support) rather than updating any driver which has a new release
<mvo> mdz: it should be fine, I like the term.log best because it contains the shell output of failed postinst too (not relevant in this case of course)
<mdz> lukehasnoname: ubuntu-devel-discuss@ is probably the place to discuss it
 * mvo walks out for a bit again and has a look when he is back
<mdz> mvo: emailed
<tkamppeter> seb128, the idea is to replace PostScript by PDF as print job format.
<tkamppeter> seb128: Up to now there is implemented: foomatic-rip takes also PDF as input, CUPS filters for PDF processing (upstream, package will come soon), KDE/Qt apps output PDF.
<tkamppeter> seb128, missing parts are: foomatic-db-engine should produce PPDs for both PS and PDF (my student works on it, will come soon), GTK/GNOME apps and OOo need to output PDF
<seb128> tkamppeter: I understand the issue, we just need somebody to do the change and I've lot of things, and I've lot to do already so I'm not sure I'll do that this cycle
<geser> @archive admins: is it an oversight that libmtp8 ended in universe as the source and libmtp-dev is in main?
<seb128> geser: things land by default in universe if nobody override those
<seb128> geser: if there is a main package which requires it, it'll be listed on the component mismatch summary
<seb128> geser: you can also tell us if it requires promotion now
<geser> seb128: it is: Reverse-Depends: libmtp-dev
<seb128> geser: ok, I'll fix it, thanks for pointing the issue
<geser> thanks
<slangasek> pitti: block on pam-config-framework, please; I made good progress over the weekend, I think I'll have a usable prototype by end of next week (can't promise it this week, and next week is intermittent due to DebConf)
<warren> Is Intrepid still using util-linux + tons of patches
<warren> or util-linux-ng?
<Spads> Ng: I didn't know you wrote a util-linux!
<tseliot> ï»¿lukehasnoname: the drivers in Hardy are updated through envyng and the -envy flavour of the restricted modules.
<mvo> mdz: I can repriduce the dovecot failure, but for me a apport file is written, I will try a bit more to reproduce why it was not written for you (what happens if you run /usr/share/apport/package_hook --package dovecot-imapd < /dev/null?)
<ogra> warren, we use -ng
<ogra> or better debian moved and we followed afaik
<ogra> warren, switched over on  Tue, 10 Jul 2007 by lamont apparently
<lamont> ogra: util-linux-ng _is_ upstream
<ogra> lamont, right
<ogra> i just wasnt sure because we call the binary until-linux
<lamont> as of, oh, gutsy
<lamont> I refuse to upload a package with '-ng' in the name
<ogra> yeah, thats what the changelog says :)
<lamont> Ng already has a big enough head. :-p
<ogra> lol
<lamont> besides, if we did that, we'd need to s/ipv6/ipng/ everywhere...
<lamont> since "ng" really just means "oh, btw, we overhaulled it, kthx"
<warren> lamont: oh hey
<lamont> hey warren
<warren> lamont: i'm trying to figure out how debian LTSP without union mounts can mount stuff without the /etc/mtab~number error messages
<warren> just sent you an e-mail
<lamont> ah, mk
<warren> lamont: vagrantc said debian has code to handle that more smoothly?
<lamont> interesting, since the only diff between ubuntu and debian is volume detection stuff
<lamont> which will shift to common-ground superseding both in 2.15 ish, I expect - it's a topic branch upstream atm
<warren> lamont: I work on Fedora
 * lamont still has about 45 min of work day left, then gets to play catchup on devel stuff, and run out the door for a week of family vacation, all without his wife killing hm
<slangasek> asac: am I right in recalling that the reason for the divergent nss/nspr sonames is that upstream doesn't actually track backwards-incompatible changes on these libs, rather than that we've made ABI-divergent changes to them?
<lamont> warren: git clone  git://git.debian.org/~lamont/util-linux.git
<lamont> warren: that's based off of the util-linux-ng tree
<warren> lamont: do you know where in the code might have stuff to handle this problem?
<lamont> not sure - ISTR a 'patches' branch which was a cleanup of all the patches debian has
<Riddell> pitti: how come apport is enabled=0 by default?
<slangasek> Riddell: it should be off by default in released versions, and on by default in devel versions; I think it was also disabled for a while recently in intrepid because the retracer was broken?
<Riddell> seems to still be disabled, according to my new chroot
<slangasek> then I guess it still needs uploaded for that
<lukehasnoname> tseliot: Sorry for being an asshat, I remember you telling me that
<tseliot> ï»¿lukehasnoname: no problem ;)
<slangasek> what's the name of that package in universe that people use to mangle their grub setups unrecognizably? :)
<lukehasnoname> What does the official Ubuntu install DVD have on it? Does it have desktop AND server? Live AND text-based install? What makes it different?
<Nafallo> all of main
<Nafallo> alternative and server I think
<slangasek> it doesn't provide a server installation
<lukehasnoname> aw :(
<slangasek> it's a "liveCD", i.e. installs are done by copying the running environment to the install target rather than by debootstrapping packages
<slangasek> (it's also fully localized, which makes the livefs image HUGE)
<ogra> doent it provide the d-i install anymore ?
<ogra> it used to
<lukehasnoname> 'cause I was going to use it if it gave me server + alternate, since I don't use live install, and a one-disc solution for all my computers (server and laptop) would be nice
<slangasek> ogra: it might have a copy of the d-i initramfs on it; it doesn't have enough packages on the image to support a full install by that method, without recourse to network
<ogra> ah, th elast DVD  tested had both install variants (gutsy iirc)
<Nafallo> ogra: same here :-)
<Nafallo> but feisty I thnk
<lukehasnoname> there is probably a reasonably easy way to wrap a server and an alternate install on one dvd
<lukehasnoname> though it would be inefficient in space
<ogra> well, you could remaster a CD and just pull on it what you like
<ogra> up to you if you fil it or not
<ogra> *fill
<slangasek> ogra, lukehasnoname: er, oh; my mistake, checking a current DVD, it looks like all the base packages are there to do a d-i install
<slangasek> I'm not sure whether server is included in that
<lukehasnoname> d-i?
<slangasek> "alternate installer"
<ogra> alternate install
<ogra> snap :)
<ogra> slangasek, btw, did you look for startupmanager ?
<slangasek> ah, that's the one, thanks
<mdke> I'd like to politely bump an sru - does commenting on the relevant bug help at all, or is it just a matter of the sru team working through their subscription list so that commenting won't make a difference?
<slangasek> what do you mean by "bump"?
<slangasek> bump it up, or bump it out? :)
<mdke> slangasek: bring it politely to someone's attention
<mdke> maybe, get it into someone's bug email (if that's relevant to the sru team's workflow) or something else
<slangasek> mdke: right, if there's not a reason that the SRU is somehow critical, then it's already on the radar; at least when I'm doing SRU work, I iterate through the web views, the email is too scattered to be useful to me for that
<slangasek> ("if there's not a reason that the SRU is somehow critical" --> "unless there's a specific reason it needs to be jumped ahead in the queue")
<mdke> slangasek: ok, that's what I figured. It's not critical, but it's quite old so it's enough for me to know that it's still on the radar :) thanks
<slangasek> what's the bug number?  just to make sure it's labelled properly
<mdke> it's bug 243823, although it's not labelled at all, I just subscribed the sru team
<ubottu> Launchpad bug 243823 in ubuntu-docs "Stable Release Update for ubuntu-docs in hardy" [Undecided,New] https://launchpad.net/bugs/243823
<mdke> bbiab, just nipping out to the shop
<doko> slangasek: please could you accept openjdk-6 into hardy-proposed (in NEW, comes with a new -dbg package)
<slangasek> mdke: ok - if ubuntu-sru is subscribed, that's the important thing then, thanks
<slangasek> doko: ack, will look at it in a bit
<doko> thanks
<joaopinto> hello
<joaopinto> Can someone review and advocate http://revu.ubuntuwire.com/details.py?package=amoebax ? Thanks
<emgent> hello
<asac> slangasek: yes. i talked about this with nss developers at summit
<asac> slangasek: if we have good reasons they would be willing to reconsider their approach
<joaopinto> ops, i was on the wrong channel :P
<asac> which of course doesnt mean much
<asac> slangasek: to clarify: upstream only adds new symbols. they dont break compatibility - by policy. so in the end this whole thing prevents downgrade issues - which probably can be questioned.
<mdke> slangasek: thanks
<NCommander> seb128, ping
<seb128> NCommander: hi
<NCommander> seb128, get the message on updated system-monitor?
<seb128> NCommander: no
<NCommander> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/254776 - and all your updates are belong to us ;-)
<seb128> cool :-)
<NCommander> seb128, next on the list ;-)?
<seb128> want an another one to do now? ;-)
<NCommander> seb128, I'd like to see a day zero turn around time for GNOME
<NCommander> ^'s release
<seb128> NCommander: want to do gnome-applets or still not having the bandwith to download the build-depends?
<NCommander> seb128, let me see
<seb128> NCommander: otherwise http://download.gnome.org/sources/sound-juicer/2.23/sound-juicer-2.23.1.tar.gz
<NCommander> seb128, its at the two hour mark, I can wait that long
<NCommander> I'll attack soundjuicer in the meantime
<seb128> cool
 * NCommander is the patch-nator ;-)
<NCommander> seb128, how many packages are left to update? (is there some sorta master list?)
<seb128> NCommander: no real master list, I'm subscribed to the GNOME ftp list which lists tarballs uploads
<seb128> there is not too many of those
<NCommander> handy
<NCommander> My bandwidth issues are still bad; I can't even work on REVU since uploading to my PPA is officially crawling -_-;
<m0u5e> is ext4 going to be implemented in future versions of ubuntu (any time soon?) :)
<NCommander> seb128, too many of what?
<NCommander> seb128, easy ones?
<Nafallo> m0u5e: dep-waits kernel I'd say.
<NCommander> m0u5e, I thought it was already in the kernel, aka, in the current version of the text-mode installer
<seb128> NCommander: no, tarballs to packages, I spent my day on those so did a good part of the updates while they were coming
<Nafallo> NCommander: marked stable now?
<m0u5e> ah
<NCommander> Nafallo, I thought it was just in the kernel mainline
<Nafallo> # CONFIG_EXT4DEV_FS is not set <-- dev suggests it's not
<Nafallo> 2.6.24-20-generic, no idea about intrepid
<NCommander> Nafallo, which means if it is, you can install Ubuntu on it (if you don't mind using the command line to manually format and mount the parition at /), although GRUB might need an update to boot off ext3
<NCommander> *ext4
<Nafallo> NCommander: it's not in hardy's kernel.
<NCommander> Nafallo, I guess its a matter of compiling your own kernel then
<NCommander> Which isn't that difficult, then you need to rebuild d-i, and more fun
<NCommander> Nafallo, Well. Insert foot in mouth. Turn 90 degrees anticlockwise
<m0u5e> whats the next ubuntu version after intrepid?
<jcristau> it's intrepid+1
<ogra> intrepid+1
<m0u5e> if there is no name, i volunteer Jamming Jackdaw, with a focus on fixing linux sound :)
<ogra> 9.04 as well :)
<m0u5e> hmm animals that begin with J are hard...
<m0u5e> any comments on Jamming Jackdaw, the the proposed feature goal? :)
<NCommander> Jumping Jackrabbits :-)
<NCommander> or Jumpy Jackrabbits
<m0u5e> Jealous Jaguar
<m0u5e> lol
<NCommander> possible brb
<m0u5e> what would the feature goal be for jumping jackrabbits?
<m0u5e> ultra portability? lol
<slangasek> JavalÃ­
<ScottK> Jiggly Jello - Given the traditional source of gelatin, it ought to count.
<m0u5e> it needs to be adj+animal
<m0u5e> jello is not alive (at least not where I live)
<m0u5e> and what would the feature goal be for Jiggly?
<m0u5e> to make wobbly windows even more "wobbly?"
<ScottK> If you cleaned out your refigerator as often as I do mine, it would be (alive).
<m0u5e> lol
<ogra> and wear a hair tie :)
<m0u5e> i'd laugh if our ideas actually got published for the next version
<seb128> NCommander: still around?
<ogra> seb128, gcc 2.x ?? woah
<seb128> ogra: ?
<ogra> your last upload mentions it in the changelog
<ogra>  - Fix build with gcc 2.x
<ogra> i wouldnt belive anyone still uses that :)
<seb128> ogra: ah right, there is a guy upstream who likes to fix those bugs, not sure why
<ogra> heh
<seb128> usually he fixed c99 syntaxs
<ogra> oh my ... if he can do that he should really go after serious bugs ...
<seb128> those are usually easy bugs
<NCommander> seb128, ?
#ubuntu-devel 2008-08-05
<seb128> NCommander: that was to point the tarballs I listed on #ubuntu-desktop now
<TheMuso> 5~/c
<emgent> Riddell: ping
<dholbach> good morning
<TheMuso> /c
<dholbach> does seahorse's gpg agent work for anybody in intrepid?
<dholbach> it works fine in hardy for me, but not in intrepid
<tseliot> ï»¿dholbach: maybe you're experiencing a problem with gnome's keyring
<tseliot> did you do a "ssh-add"?
<dholbach> tseliot: not that I remember
<dholbach> it's a KVM instance (if that matters)
<dholbach> I have to type in my gpg passphrase everytime - this sucks :)
<tseliot> after doing that the problem with the gnome keyring should go away
<tseliot> as regards having to type your password every time, do you use gpg-agent?
<nxvl> i always type my passphrase
<nxvl> i don;t trust password managers
<nxvl> :D
<tseliot> dholbach: I meant gnupg-agent
<dholbach> tseliot: AFAIK seahorse is a gpg agent
<dholbach> at least it was in hardy
<dholbach> seahorse-agent is missing from intrepid - hm
<nxvl> as a standard answer
<nxvl> dholbach: file a bug on launchpad against seahorse
<nxvl> :P
<dholbach> from seahorse changelog: debian/seahorse.Xsession: remove this one since seahorse-agent has been moved to a different source
<nxvl> dholbach: there is the answer
<dholbach> it's not a full answer - which different source? :)
<nxvl> dholbach: ask seb
<nxvl> dholbach: or slomo
<dholbach> once they're up, yeah
<ion_> summon BenC
<pitti> Good morning
<pitti> slangasek: p-c-f> thanks, will do
<pitti> Riddell: right, I still have troubles with the retracers, p-lp-bugs...; I'll enable apport again by default as soon as this is sorted out
<Hobbsee> pitti!
<tjaalton> please don't upgrade your xserver-xorg-core just yet ;)
<pitti> tjaalton: thanks for the warning :)
<pitti> Hobbsee!!!
<Hobbsee> :)
<RAOF> tjaalton: Full of lack of working?
<tjaalton> mouse&kbd won't work with current xorg.conf
<tjaalton> autoconfig fails for some reason
<RAOF> That could be a small problem, yes.
<Hobbsee> ouch
<tjaalton> just more the reason to turn input-hotplug on ;)
<RAOF> What's the status of synaptics visa vis not requiring SHMConfig in xorg.conf to be useful?
<tjaalton> pitti: btw, there's a better solution to the i-h fdi thingy. ajax patched hal-set-property to support --direct, which means that a callout script works now. that means that there's no need to generate an fdi file anymore
<Hobbsee> that reminds me.  i should file a bug about the vertical scrolling detection, or lack of it, on a default install.
<tjaalton> RAOF: input properties, in xserver master
<RAOF> tjaalton: Woot!
<pitti> tjaalton: what does --direct do?
<tjaalton> RAOF: but needs driver support for it. think xrandr but for input devices
<RAOF> tjaalton: Relatively easy changes to make?
<tjaalton> pitti: it allows to set the value before the dbus connection works. I played with that approach long ago, but couldn't make it to work because hal complained that the dbus connection was not available
<tjaalton> RAOF: no idea..
<RAOF> Heh.  Oh, well.  Huzzah for X slowly reducing my personal peeves.  Next thing you know you'll be able to resize the framebuffer at runtime!
<tjaalton> pitti: http://cvs.fedoraproject.org/viewcvs/devel/hal/hal-0.5.10-set-property-direct.patch?rev=1.1&view=auto
<tjaalton> pitti: ok if I prepare a diff for hal?
<pitti> tjaalton: sure, or just commit it to the bzr branch
<pitti> but if you are more happy with a diff and want me to review, fine for me
<tjaalton> pitti: ok, will do. I guess it's easier to just turn input-hotplug on to fix the mouse/kbd problems :)
<pitti> tjaalton: I just promoted xinput, so please feel to add dependencies to it
<tjaalton> pitti: ok, cool
<pitti> tseliot: did you see the FTBFS of nvidia-173?
<Hobbsee> tjaalton: any ETA for a fix on that no-keyboard bug?
<tjaalton> Hobbsee: a couple of hours
<Hobbsee> tjaalton: cool :)(
<tjaalton> Hobbsee: or just add 'Option "AllowEmptyInput" "false" to ServerFlags section
<tjaalton> it's the commit that enabled that by default which broke it
<tjaalton> and because ServerLayout doesn't have the devices listed, epic fail
<Hobbsee> tjaalton: ahh.
<tjaalton> but that's needed in order to have a minimal config for input-hotplug, so..
<tseliot> pitti: no, I didn't notice the failure
<tseliot> link?
<StevenK> pitti: Did you dump all of the NBS stuff that ichthux-desktop wanted?
<pitti> tseliot: I got an FTBFS email
<tseliot> pitti: http://launchpadlibrarian.net/16527069/buildlog_ubuntu-intrepid-i386.nvidia-graphics-drivers-173_173.14.12-0ubuntu1_FAILEDTOBUILD.txt.gz
<pitti> StevenK: maybe not all, but if I looked at a package and ichthux-desktop was the only rdepends, I killed it
<pitti> tseliot: right, you can get it from the web ui
<StevenK> pitti: Ah, okay, so I should vacuum up some of the real NBS things and kill them off?
<tseliot> pitti: heck the NVIDIA installer was not executable. Weird it is here
<pitti> StevenK: that would be awesome
<pitti> tseliot: maybe just add a chmod to debian/rules, for more robustness?
<tseliot> pitti: yes, that's what I was thinking of
<tseliot> pitti: shall I bump the revision for a new upload?
<pitti> tseliot: yes, you need to
<tseliot> pitti: ok, just like the PPA
<mvo> mdz: the bug in apts apport writer is fixed now, thanks for reporting it!
<tseliot> pitti: here are the links
<tseliot> http://albertomilone.com/ubuntu/newlrm/pitti/nvidia-graphics-drivers-173_173.14.12-0ubuntu2.diff.gz
<tseliot> http://albertomilone.com/ubuntu/newlrm/pitti/nvidia-graphics-drivers-173_173.14.12-0ubuntu2.dsc
<tseliot> http://albertomilone.com/ubuntu/newlrm/pitti/nvidia-graphics-drivers-173_173.14.12-0ubuntu2.changes
<tseliot> it builds well here even if the installers are not executable
<pitti> tseliot: hm, that's 404
<tseliot> pitti: only the changes file
<pitti> tseliot: ah, I fixed the name, _source.changes
<pitti> works now
<pitti> tseliot: uploaded, thanks
<tseliot> pitti: thanks to you ;)
<pitti> seb128: ah, we have libgphoto-gvfs by default now
<seb128> pitti: yes, that's early intrepid we can give it some testing ;-)
<pitti> indeed
<pitti> we just need to adapt g-v-m accordingly
<seb128> ah right
<seb128> pitti: btw I'm not sure reopening bug #164265 was correct
<pitti> seb128: ATM I get an error dialog that it couldn't lock the camera exclusively, or so
<ubottu> Launchpad bug 164265 in rhythmbox "Transferring AAC files to iPod is broken" [Low,Confirmed] https://launchpad.net/bugs/164265
<pitti> seb128: well, it's differently broken now, although of course for a different reason
<pitti> but the original fix is a regression for someone else, so I think it still belongs together?
<pitti> seb128: how about I disable g-v-m's autophoto command, and then I unseed it? or do you still see a reason to install g-v-m by default?
<seb128> I'm not sure that's the fix which created the regression, was his case working before?
<pitti> before it auto-converted aac to mp3 allegedly
<seb128> and I'm not a big fan of having a zillions comments on a bug, I usually prefer having clear new bugs about new issues
<pitti> I'm ok with closing it and opening a new bug, if you like it better
<pitti> seb128: g-v-m uploaded; shall I unseed it now, too?
<seb128> pitti: yes, please do
<pitti> one daemon less to start :)
<pitti> seb128: ah, the "could not exclusively claim device" error is probably the same as for USB harddrives, it tries to mount it twice
<seb128> pitti: the mount twice is a gvfs issue fixed in the new tarball I'm going to upload soon
<pitti> right, I know, just keeping track
 * pitti sponsors ember's gnome updates and hugs him
<seb128> pitti: thanks for the sponsoring ;-)
 * pitti does a stab at the retracers
<tjaalton> pitti: rock, the hal callout script works
<pitti> yay
<tjaalton> only that now the xserver crashes :)
<tjaalton> some patch apparently breaks it.. I'll go hunt some better ones
<pitti> seb128: seems you are still attached to the amd64 retracer screen, BTW?
<seb128> pitti: I doubt of that or something went wrong because I disconnected yesterday and stopped my laptop since
<pitti> seb128: yeah, you have been attached for several days already
<ion_> pitti: -x to attach simultaneously, -dR otherwise
<pitti> seb128: maybe screen-in-screen or so? :)
<pitti> ion_: I know, I used -x
<seb128> pitti: lemme try
<pitti> it didn't stop me, but it's still a bit weird
<pitti> anyway, retracers should work again, the amd64 one retraced several bugs, and the i836 one is consolidating
<seb128> pitti: what the
<ion_> Is BenC on a vacation or something, btw? Nothing urgent, just curious.
<seb128> pitti: "There is no screen to be resumed."
<pitti> ion_: I talked to him yesterday
<ion_> He seems to have idled for 26 hours.
<tjaalton> what the hell, input-hotplug makes the xserver crash, even the old version
<tjaalton> sigh..
<RAOF> Argh.  Has anyone else noticed unusually poor interactive performance under disc load?
<RAOF> Running an aptitude upgrade shouldn't result in second-long pauses in music & keyboard responsiveness.
<pitti> did anyone put launchpadlib into a PPA package already?
<pitti> RAOF: me, yes
<pitti> but I blamed my recent switch from my amd64 desktop to my i386 laptop (docked) and thus the much slower disk
<jpds> pitti: james_w appears to have just put source packages on REVU.
<james_w> pitti: give me 5 minutes
<pitti> oh, wow
<pitti> I *knew* there must be someone who couldn't resist :-P
 * pitti hugs james_w
<james_w> pitti: Intrepid right?
<pitti> james_w: not urgent at all, I was just curious, since I took a look at https://help.launchpad.net/API
<tjaalton> pitti: seems like evdev is broken. could you sync it from debian-experimental? the version that was synced last night doesn't build
<pitti> and this promises to put an end to the p-lp-bugs screenscraping catchup madness
<geser> RAOF: with intrepid?
<RAOF> pitti: This is my amd64 laptop, and I seem to recall Hardy doing better.
<pitti> tjaalton: trying
<tjaalton> pitti: with it my xserver is working again..
<pitti> tjaalton: which package will depend on xpinput, BTW?
<pitti> Updating] xserver-xorg-input-evdev (1:2.0.2-1.lenny1 [Ubuntu] < 1:2.0.3-2 [Debian])
<pitti> tjaalton: ^ that ok?
<tjaalton> pitti: yes that's fine
<pitti> tjaalton: done
<tjaalton> pitti: I'm not sure if any package will depend on it just yet
<tjaalton> bryce knows better I gues
<tjaalton> +s
<pitti> tjaalton: bryce did a MIR, and said it was a prerequisite for hotplug
<tjaalton> oh.. :)
<geser> RAOF: could it be bug 218516?
<ubottu> Launchpad bug 218516 in linux "[hardy] key events are delayed under circumstances" [Low,Fix committed] https://launchpad.net/bugs/218516
<RAOF> geser: That's unlikely to make sound halt for ~1s, right? :)
<geser> RAOF: unlikely
<RAOF> geser: No, it's not that bug.
<tjaalton> pitti: should the callout script be installed in /usr/lib/hal?
<pitti> tjaalton: that sounds fine
<tjaalton> k, will put it there
<james_w> pitti: might be longer than 5 minutes. They're there, but not going to be built for a while
<james_w> https://edge.launchpad.net/~james-w/+archive
<seb128> james_w, pitti: debian upgraded policykit to 0.9, maybe something to consider for intrepid too?
<pitti> seb128: yes, absolutely
<tjaalton> pitti: http://users.tkk.fi/~tjaalton/dpkg/hal.diff
<pitti> tjaalton: just one issue: in hal.install, you have
<pitti> +debian/debian-setup-keyboard usr/lib/hal
<pitti> tjaalton: but that won't automatically make it executable
<pitti> tjaalton: if you ship that script in the diff.gz, it will be 644
<tjaalton> pitti: ah, ok. I tested it by putting it in usr/bin, so it was 755 then
<pitti> tjaalton: and the changelog incorrectly says that debian/rules would install the fdi, which it doesn't (it's hal.install)
<tjaalton> well, I removed the lines that removed it :)
<pitti> ah, true
<pitti> tjaalton: so, either use 'install' in debian/rules right away, or hal.install and a chmod in debian/rules
<tjaalton> pitti: ok, will fix it
<pitti> tjaalton: thanks
<pitti> seb128: ok, i386 retracer is happy
 * seb128 hugs pitti
 * pitti retags some broken bugs
<dholbach> pitti: thekorn is working on wrapping it in pylpbugs
<pitti> dholbach: yeah, I know
<dholbach> ok :)
 * pitti is sooo happy about a stable LP API
 * thekorn too :)
 * pitti hugs thekorn
 * thekorn hugs pitti and dholbach 
<pitti> thekorn: so it seems for bug attachments you have to use the raw protocol until launchpadlib supports them natively?
<thekorn> pitti, no, it is supported by launchpadlib,
<thekorn> to get a collection of attachments use bug.attachments
<pitti> One part of Launchpad is exposed through the web service, but not supported by the current version of launchpadlib:
<pitti>     * Uploaded files, such as bug attachments
<pitti> hmm, so that's already obsolete?
<tjaalton> pitti: refresh the diff, updated
<thekorn> yes, adding and getting attachments is supported
<pitti> nice
<pitti> tjaalton: looks fine; happy with it, shall I commit/upload?
<tjaalton> pitti: yes please :)
<seb128> pitti: yeah for retracings ;-)
<mdz> mvo: I see you found the bug, thanks
<tjaalton> sigh, so the kernel doesn't seem to handle usb device hotplugs currently
<pitti> tjaalton: confirmed, new hal completely breaks X, and after I manually downloaded/built -evdev it all works again now
<tjaalton> pitti: yeah, turns out that the version from a while back was busted
<pitti> uploaded now
<tjaalton> hm, reboot fixed usb woes
<Riddell> ogra: I'm moving blinken and kiten to universe since they have dependencies there, if edubuntu wants them we'll need to look at MIRs
<soren> j/win 320
<soren> gah..
<pitti> mvo: for bug 253255, how can I tell update-manager to use the hardy-proposed version for a gutsy->hardy upgrade?
<ubottu> Launchpad bug 253255 in update-manager "crash gutsy -> hardy hardy 8.04.1 cdrom upgrade" [High,Fix committed] https://launchpad.net/bugs/253255
<pitti> mvo: (I'd like to keep the current gutsy python-apt and test the u-m workaround)
<pitti> ah, I see, --proposed
<mvo> pitti: yes, that should work
<pitti> mvo: yay, didn't crash any more \o/
<mvo> pitti: excellent :)
<pitti> mvo: there's a question for you from sbeattie in that bug, FYI
<mvo> pitti: thanks, I'm having a look
<fabbione> hey guys
<soren> fabbione!
<soren> dude!
 * soren hugs fabbione 
<pitti> hey fabbione, *hug*
<fabbione> Hejsa nerd :)
<soren> ;)
 * fabbione hugs everybody
<fabbione> how is life in Ubuntu land these days?
<pitti> X is broken :)
<pitti> what else
<fabbione> no news about that :)
<fabbione> i did stop updating X and kernel a while ago from intrepid :)
<tjaalton> pitti: not anymore! hal fixed that :)
<fabbione> maybe at somepoint i should decide to give it another shot ;)
<pitti> tjaalton: as soon as the current uploads build and publish, right :)
<pitti> fabbione: try this afternoon
<tjaalton> pitti: good point :)
<fabbione> pitti: maybe tomorrow.. need to work till the end of the day :)
<fabbione> did they ever sorted the nvidia driver issue with new X?
<pitti> fabbione: the new versions reportedly work fine, but -71 and -96 still have trouble AFAIK
<fabbione> yeah i can't use anything != 96 on this machine unfortunately
<fabbione> unless i want to start swapping cards around, but that's a major problem
<pitti> tseliot: you did some porting on the old versions, so they build now, but don't work with current X; was it that?
<fabbione> there is an unresolved symbol loading the X driver
<fabbione> the kernel module is fine
<pitti> fabbione: are you using the packaged versions, or upstream's installer?
<fabbione> packaged
<fabbione> there were no new versions from upstream a couple fo weeks ago when i last checked
<fabbione> pitti: this machine will be dismessed soon anyway. a new dual quad core is on the way with a slightly more recent gfx
<fabbione> or at least turned into something headless
<fabbione> dendrobates: http://sources.redhat.com/cluster/wiki/ClusterSummit2008 <- it is going to happen.. BTW..
<fabbione> dendrobates: assuming one of your guys want to show up.. there is still time to confirm
<fabbione> soren: so how is life in Ãlborg?
<geser> pitti: what is a good/correct version if one takes a package from intrepid for a bugfix SRU? Would using -1~hardy1 be acceptable?
<pitti> mdz, BenC, bdmurray, ogasawara: FYI, "ubuntu-bug -p linux" now DTRT and produces sth. like bug 254926; let me know if you need any other information
<soren> fabbione: Pretty good. We're just about ready for the baby now. I had last week off, and got *loads* of stuff done around the house.
<ubottu> Launchpad bug 254926 in linux "test bug, please ignore" [Undecided,Invalid] https://launchpad.net/bugs/254926
<pitti> geser: that's the backport schema, and works, yes
<fabbione> soren: ahhhhh i didn't know your wife was pregnant! congratulation
<fabbione> soren: you will soon share my pain :P
<soren> fabbione: Yeah, she's due September 22nd. It's getting close :)
<fabbione> soren: oh yeah.. nice..
<mdz> pitti: the other thing I meant to bring up in that thread was that some more general syntactic sugar would be nice...can we make 'ubuntu-bug linux' DTRT rather than requiring a flag?
<mdz> pitti: then it would be as simple as reportbug
<pitti> mdz: so if it's an int, regard it as a PID, otherwise as a package name?
<pitti> sure
<tseliot> pitti: I wrote a patch so as to make them compile with kernel 2.6.26 but they still won't work with the new Xorg API
<mdz> pitti: yeah, that sounds reasonable
<fabbione> pitti, tseliot: i doubt you can anything directly to the nvidia driver. AFAIR the requirement for tha symbol is in the userland binary blob
<fabbione> so unless you want to patch X to readd that symbol, there is nothing you can do
<tseliot> fabbione: you're right. I'm waiting for NVIDIA to add the support for the new X to their legacy drivers
<mdz> pitti: we probably only need one of ProcVersionSignature and RunningKernelVersion, no?
<mdz> pitti: and ProcVersion is not very interesting if they're running an Ubuntu kernel
<pitti> mdz: with an upstream kernel we won't have /proc/version_signature, but right, we should just have one
<Riddell> asac: are you going to upload network-manager 0.7 sometime?
<mdz> pitti,BenC,bdmurray,ogasawara: FYI, the [modified: blah] spam is bug 250511, which should be fixed to avoid similar spam in every apport bug for the kernel
<ubottu> Launchpad bug 250511 in linux "Package contains generated module maps" [Undecided,New] https://launchpad.net/bugs/250511
<pitti> asac: wrt. n-m, next Thursday is alpha-4, so please don't wait until the last minute with such an intrusive change
<mdz> pitti: I like the username/hostname anonymization, but it is a little strange because it is hard to tell that it is a placeholder
<mdz> pitti: I wish we could use italics, but perhaps caps would be better than nothing
<mdz> pitti: architecture info is duplicated a lot, too.  I think we should try to trim down the bits which go in the bug description and make it easy to scan visually
<pitti> mdz: I'll start with consolidating the four ProcVersion/Uname/RunningKVer fields
<pitti> mdz: Architecture and PackageArchitecture make sense for normal packages, but not for the kernel, right
<mdz> pitti: what's Architecture? the GNU arch?
<mdz> pitti: SourcePackage: linux seems redundant
<mdz> for the bug report anyway, it should of course be in the .crash
<pitti> mdz: Architecture is dpkg --print-architecture, while PackageArchitecture comes from dpkg -s
<pitti> mdz: i. e. i386 firefox .deb on amd64 system
<pitti> and uname is the kernel
<mdz> pitti: oh. then we should only include PackageArchitecture if it doesn't match Architecture
<pitti> i. e. i386 system on amd64 kernel
<mdz> I think as a rule of thumb it should try to filter out things which are default
<mdz> that way, if something is changed or unexpected, it will be immediately visible
<mdz> whereas when there is a lot of information which is usually irrelevant, we will tend to skip over it
<pitti> right
<pitti> hm, how can I tell (in sh), whether a string is a number?
<pitti> ah, test "$x" -gt "0" exits with 2
<asac> Riddell: i am waiting for an ack from anyone using b43 driver
<DRebellion> vorian, slangasek, just a note on monkeystudio - upstream says that they are already using the Qt Designer from the repositories. They will try to remove a few features and see if they can get QScintilla to work (they need a more up to date version than the repos).
<asac> Riddell: that it works at all
<asac> Riddell: fwiw, colin had a driver-issue, so once he is back ill get an ack from him that my patch in latest ~network-manager PPA works
<mdz> pitti: not sure how portable that is; you could always do a regex or glob match
<pitti> mdz: I don't actually rely on two; I use "if test "$1" -gt 0 2>/dev/null"
<mdz> asac: I have a variety of weird problems on my laptop with the version in the PPA
<mdz> asac: e.g. the applet not appearing
<mdz> (even when it's running)
<mdz> asac: just last night, it came up and told me I was connected to *both* the wired and wireless networks (both radio buttons filled) which seems wrong
<mdz> pitti: sounds reasonable
<mdz> pitti: maybe ProcEnviron should be an attachment
<mdz> pitti: is ProblemType important in the bug report? if it includes the crash report, it's a crash, otherwise it's not. should be obvious
<mdz> also it's in the subject
<mdz> pitti: Date is probably not interesting for non-crashes, since it will  be the same as the timestamp on the bug
<pitti> mdz: there are a bunch of scripts which parse ProblemType, so I'd like to keep that
<pitti> mdz: ProcEnviron> current default is that text values with >= 5 lines become attachments
<mdz> pitti: wouldn't a tag be better for scripts?
<pitti> just two lines are faster to visually parse than mini-attachments IMHO
<mdz> there are already apport-bug and apport-crash, no?
<mdz> pitti: true, but for 99% of bugs it is not relevant
<pitti> mdz: it would complicate the scripts (since they don't use LP directly for portability), but it would be doable
<mdz> pitti: perhaps PATH could be omitted if it's default?
<pitti> ok, I'll think about all of the above
<pitti> mdz: thanks for your feedback!
<mdz> pitti: anytime
<pitti> mdz: ok, committed the ubuntu-bug argument sugar
<pitti> rest after lunch
<mpt> Are there any packages in Restricted that are part of Ubuntu Server?
 * mpt doesn't know quite how much sense that question makes
<Riddell> mpt: linux-restricted-modules-2.6.26-5-server ?
<mpt> and the "linux-server" metapackage, I guess
<jdstrand> seb128_: hi! I just noticed in the evolution calendar, if I double click on '4pm' to create an appt, the editor shows it as '8pm', and it also shows up as reminders at '8pm'. My timezone is EDT (-0400). Do you see this behavior?
<jdstrand> (this is hardy btw)
<seb128_> jdstrand: hi, is that google calendar or a local one?
<jdstrand> seb128_: local
<jdstrand> seb128_: the 'system' one specifically
<dendrobates> fabbione: I'll look into it.
<seb128_> jdstrand: did you configure your timezone correctly in the evolution preferences?
<jdstrand> seb128_: it says America/New_York, this Adjust for daylight savings checked (that is what it should be (and -0400))
<jdstrand> seb128_: I tried changing that to something else, then back, but it's still wrong
<seb128_> jdstrand: not a known issue then no
<jdstrand> seb128_: and you don't see it yourself?
<seb128_> o
<seb128_> no
<seb128_> what view do you use? and how to create the calendar entry?
<jdstrand> seb128_: ok-- I vaguely remember trying to do something to adjust for google calendar back when it didn't work right, and wonder if that was it. I'll try on a new user...
<jdstrand> seb128_: thanks
<seb128_> no problem
<seb128_> google calendar timezone is known to be broken
<persia> tjaalton: What sort of testing do you need for bug #44169?  Should plugging in two devices that normally need evdev generate the right result?
<ubottu> Launchpad bug 44169 in xorg-server "no multimedia keys when using evdev with mouse" [Unknown,Confirmed] https://launchpad.net/bugs/44169
<seb128_> should be fixed in intrepid now though
<jdstrand> seb128_: oh, the view is 'Day view'
<jdstrand> seb128_: and creating the calendar entry is just double clicking on a time within day view (eg, double click on 4pm, and the editor shows it as 8pm)
<jdstrand> same thing for work week view
<seb128_> works fine here, but I'm on intrepid, I don't think that's buggy on hardy though
<seb128_> I would have noticed and we would have goten bugs about it
<jdstrand> seb128_: same thing with a brand new user
<jdstrand> seb128_: went through the wizard, set the timezone to America/New_York via the map, double clicked in calendar-- 4 hours off
<seb128_> jdstrand: let me boot my desktop
<seb128_> jdstrand: what system timezone do you use?
<jdstrand> $ date
<jdstrand> Tue Aug  5 08:07:00 EDT 2008
<asac> mdz: applet not running -> the applet only shows up if it has a dbus connection to the NetworkManager daemon
<asac> mdz: multiple connections -> this is a feature of NM 0.7, its just the UI that is missing the features to disable a connection
<asac> the dbus calls exist already.
<asac> however, it is still unclear how the final UI will look like.
<seb128_> jdstrand: what timezone is listed in the appointment dialog?
<jdstrand> America/New_York
<mdz> asac: hopefully not a radio button :-)
<asac> mdz: yes. imo its hard to keep the applet simple, but still put all the new features in it
<ogra> hmm ? how do you work with more than one default route ?
<ogra> you still need one to be the default, no ?
<asac> mdz: last time i talked to dan (upstream lead) he didnt appeared to be too scared about the applet not being ready yet. sounded like he knew what to do
<jdstrand> seb128_: my i386 laptop is ok
<asac> ogra: i think the last connection you click on will become the default route
<jdstrand> seb128_: (it was a clean hardy install)
<asac> so when you are connected to wired 1 + wired 2, then click on wired 1 again it will take over the default route
<seb128_> jdstrand: weird, it's ok too here, but I don't get why a new user should be wrong
<asac> ogra: are you using the PPA version?
<ogra> asac, but if i want to manually force it otherwise a radiobutton would be appropriate
<seb128_> jdstrand: I tried changing the evolution timezone to newyork, doesn't make a different, the new appointement dialog still displays the selected time
<seb128_> jdstrand: where is the hour wrong? in the "hour" in the dialog to create the calendar entry? or after validating it?
<jdstrand> seb128_: what arch is your desktop?
<pitti> mvo: any idea about the remaining mirror problem in bug 231966 ?
<ubottu> Launchpad bug 231966 in update-manager "remove any reference to mirror ftp.caliu.info" [Wishlist,Fix committed] https://launchpad.net/bugs/231966
<ogra> asac, i dont use it yet, i was stuck on hardy to make sure all the classmate stuff goes well ... but i've put classmate RC up last night, so i'll upgrade now :)
<asac> ogra: there is a hardy build too in the PPA
<jdstrand> seb128_: it is wrong in 'Time' section of the appt editor, but I noticed all this because I got reminders that were 4 hours off
<asac> ogra: except for drivers there shouldnt be much a difference
<seb128_> jdstrand: amd64 but the hardy install is an i386 one
<jdstrand> seb128_: I'm amd64/hardy-- I'm going to try an amd64 vm (i386 vm and laptop ok)
<seb128_> jdstrand: what timezone do you have in /etc/timezone?
<jdstrand> America/New_York
<seb128_> ok, so that's not a timezone mismatch
<seb128_> let me know how the testing goes
<jdstrand> ok
<seb128_> jdstrand: so it's also listed at the wrong day in the calendar view?
<jdstrand> seb128_: correct day, wrong time (always 4 hours off)
<jdstrand> seb128_: it seems to be just my desktop-- the amd64 vm is ok too
<jdstrand> seb128_: my desktop went through the hardy devel cycle and was not clean install-- maybe there is some cruft somewhere...
<jdstrand> (now to find the cruft...)
<seb128_> there should be no cruft which create misbehaviour
<seb128_> well, I doubt of that, usually cruft are user configs
<seb128_> and you have the issue using a new user too
<jdstrand> that's true
<jdstrand> seb128_: http://paste.ubuntu.com/34403/
<jdstrand> seb128_: with the exception of evolution-webcal, they are all the same version
<jdstrand> oh-- no they aren't
<mvo> pitti: looking
<ogra> mdz, you asked for comments on teh gnome dev stuff, did you look at the gnome-devel metapackage ?
<ogra> seems to be what upstream thinks is needed for gnome development
<Riddell> lucas, dholbach: about bug 254767, has the gem issue been solved?
<ubottu> Launchpad bug 254767 in ruby1.9 "Please sync ruby1.9 1.9.0.2-5 (main) from Debian unstable (main)." [Wishlist,Incomplete] https://launchpad.net/bugs/254767
<dholbach> Riddell: I didn't know there was an issue - best to ask lucas
<ogra> Riddell, thanks for taking care of the kdeedu stuff, i'm fine with additions/removals as needed
<seb128_> jdstrand: the versions are correct
<Riddell> dholbach: if you ack it I assume you know what you're talking about :)
<dholbach> Riddell: the only reference to gems is:
<dholbach>   * RubyGems did not work completely due to a gem_relude mechanism . This
<dholbach>     issue has been fixed. (Closes: #492206)
<jdstrand> seb128_: for giggles I md5'd /etc/localtime and it's the same on the desktop and in the vm
<persia> I seem to remember some larger conversation about all the different ways that gems were broken during one of the Server Team meetings.  Maybe someone from there knows?
<pitti> mdz: ah, ProblemType is tricky; I use that as an anchor to find out where in the description the apport formatted report starts (ProblemType: always comes first, the rest in alphabetical order)
<pitti> mdz: I could invent another arbitrary anchor, of course
<seb128_> jdstrand: date -u?
<jdstrand> $ date -u
<jdstrand> Tue Aug  5 12:34:09 UTC 2008
<seb128_> ok, everything seems fine, and I don't see why the system configuration should impact on that anyway
<seb128_> your evo preferences point to a timezone
<jdstrand> seb128_: I just tried changing the timezone to Prague via right click on time panel applet, then changed back, and still wrong
<seb128_> and you defined an event in the same timezone
<pitti> thekorn: hm, does Bug().date work for you? I just get an XPath-Expr error
<seb128_> I did let my system on european time
<seb128_> changed the evo calendar to new york
<jdstrand> (with an evolution --force-shutdown in between)
<pitti> thekorn: same for date_reported
<seb128_> it shifted the events in the calendar correctly
<seb128_> since the calendar was on new york time then
<seb128_> and creating an event was adding it at the right new york time too
<jdstrand> seb128_: I just now used evo preferences, changed it to Prague-- double clicked an appt in evo at 12pm-- it shows the Time fields in the edit dialog as 4pm, but the timezone itself is shown as 'Europe/Prague'
<jdstrand> odd
<pitti> thekorn: ah, works on main branch, just not in intrepid package; nevermind
<thekorn> ah, ok
<pitti> thekorn: what is the official way to get the date? .date, .date_reported, or .get_date()?
<thekorn> pitti, date_reported == date
<thekorn> both are properties, get_date is the get function for both
<pitti> ok, thanks
<Riddell> zul: can you tell me if bug 241041 is ok to sync?
<mdz> pitti: indeed, perhaps something even better for visual scanning (like ----)
<ubottu> Launchpad bug 241041 in xen-tools "Please merge xen-tools 3.9-3 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/241041
<zul> Riddell: just a sec
<zul> Riddell: yeah it is soren is adding support for xen to vmbuilder anyways so it will be depreciated anyways
 * ogra is brave and FINALLY runs update-manager -d on his hardy
<mvo> ogra: do you have a kvm capable system?
<ogra> mvo, vbox only
<mvo> ogra: if so, you may want to try the new sandbox upgrade tester first
<mvo> ogra: does your system not have the required hardware support for kvm?
<ogra> nh, no kvm love for my cpu
<ogra> nope, it doesnt
<mvo> ogra: aha, ok. then I will need to find another "volunteer" :)
<ogra> sorry ... i opted for the cheaper CPU to ge more ram :)
<stgraber> ogra: oh, your lappy doesn't have the VT extension ? that's one of those cheap Core2Duo ?
<ogra> yep
 * mvo mubles something about cheapo
<StevenK> I thought all Core 2's had VT. Or was that 64-bit extensions
<ogra> but its even in that setup overpowered more ram is more important :)
<stgraber> StevenK: they all are 64bit but some aren't VT (discovered that when installing my grandmother's lappy, had to use VB instead of KVM)
<ogra> Intel(R) Core(TM)2 Duo CPU T5550  @ 1.83GHz
<ogra> i think the T5550 is the biggest one you can get without VT
<ogra> (an on a sidenote i really prefer vbox over kvm)
<elmo> I'm pretty sure all Core2 have VT, it's just disabled by some BIOSes (sic)
<stgraber> elmo: not according to Intel's website
<ogra> elmo, then my bios is omitting the option
<elmo> stgraber: oh?
<soren> stgraber: You're rgith.
<soren> right, even.
<soren> There are a few Core2Duo models that don't have those options at all.
<soren> ...and lots more machines that come with those options disabled in the BIOS.
<stgraber> elmo: http://www.intel.com/products/processor_number/chart/core2duo.htm
<persia> There are also plenty of new Intel chips that don't have VT (A100, A110, Atom, etc.)
<elmo> stgraber: interesting
<soren> persia: Only all the low-power things, right?
<ogra> well, the atom has HT
<Riddell> jdstrand, kees: bug 236051 and bug 238883 going to get reviewed this week?
<ubottu> Launchpad bug 236051 in openbabel "main inclusion review for openbabel" [Undecided,Incomplete] https://launchpad.net/bugs/236051
<ubottu> Launchpad bug 238883 in libzip "main inclusion report for libzip" [Undecided,Incomplete] https://launchpad.net/bugs/238883
<ogra> at least some models
<persia> soren: Right.
<persia> ogra: Only the special ones that aren't in many devices yet, and only Atom.
<ogra> right
<fta> last upgrade (intrepid) killed my laptop. i'm stuck in gdm. usb mouse not detected (but the touchpad is fine) and worse, no keyboard (then no way to log in), except the alt+Fx so I can get in console and login there. Is that a known issue ?
<Hobbsee> fta: yes.
<fta> Hobbsee, good. bug ? workaround ?
<Hobbsee> fta: no idea about #, tjaalto*n mentioned it in here earlier
<Hobbsee> fta: add 'Option "AllowEmptyInput" "false" to ServerFlags section
<fta> Hobbsee: thanks. it worked.
<Hobbsee> fta: \o/ (but really, you should thank tjaalton for the workaround)
<fta> tjaalton, thanks for the AllowEmptyInput workaround !
<asac> empty input
<asac> hah
<tjaalton> fta: just update hal and enjoy input-hotplug goodness
<asac> i knew that my typing usually doesnt make sense
<asac> ;)
<fta> eheh
<fta> debian bug 492140
<ubottu> Debian bug 492140 in xserver-xorg "xserver-xorg: xorg.conf generated with no ServerLayout section" [Important,Open] http://bugs.debian.org/492140
<asac> "EnableBrainInput" "true"
<ogra> *shudder*
 * ogra doesnt want all the stuff he thinks on screen 
<jdstrand> seb128_: I did 'strace -f evolution -c calendar' but nothing popped out at me as wrong
<asac> ogra: you can train that input method ;)
<ogra> heh
<asac> at least you should train the enter key properly
<asac> otherwise your thoughts end up in irc channel
<ogra> yeah, that would be evil
<persia> asac: We need better HW drivers.  If I send you HW, will you write a driver?
<jdstrand> seb128_: (I compared it to the strace in the amd64 vm)
<asac> persia: at least the spec is not yet patented - i hope
<ogra> persia, better get a good parcel service if you send your brain around :)
<asac> and take care that your brain supports hotplug + coldplug ;)
<ogra> *g*
<fta> tjaalton: which hal do i need ? i have 0.5.11-3~ubuntu4, except for hal-device-manager (0.5.9.1-6ubuntu5)
<persia> asac: No, there are several open specs, and good software for BCI devices.  Just not much open source beyond basic data collection, some MIDI generators, and mouse drivers.
<tjaalton> fta: ubuntu5
<asac> persia: really? ... thats in japan?
<persia> asac: Actually, Germany is the only country I know with well-supported commercial devices (sold as medical equipment)
<persia> There's some cheap consumer stuff here (and in the states), and better consumer stuff promised soon from various places.  There's also a bunch of hobby stuff.
<jdstrand> seb128_: this sounds very similar: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491095
<ubottu> Debian bug 491095 in evolution "evolution: Calendar entries show up at wrong time" [Important,Open]
<fta> tjaalton, "Published 2 hours ago". I see.. it's coming, great
<jdstrand> seb128_: which points to http://bugzilla.gnome.org/show_bug.cgi?id=543517
<ubottu> Gnome bug 543517 in Calendar "Calendar displays appointments/meetings at incorrect times" [Major,Unconfirmed]
<seb128_> jdstrand: right, and there is no upstream comment
<jdstrand> seb128_: as it seems to not 'be just me', I can file a bug too-- would you like it in LP linked to the debian and bugzilla bugs?
<seb128_> jdstrand: yes please
<jdstrand> ok
<pitti> mdz: so, I can read bugs with the "--- " separator now, but since Launchpad doesn't create them that way, I can't actually write them for now; but at least I got the other cleanup now
<jdstrand> seb128_: bug #254980
<ubottu> Launchpad bug 254980 in evolution "Calendar displays appointments/meetings at incorrect times" [Undecided,New] https://launchpad.net/bugs/254980
<jdstrand> seb128_: it gets even more fun if I 'save' the appointment
<jdstrand> seb128_: eg, double click 12pm, shows up in editor as 4pm, save, shows up in evolution as 8pm
<jdstrand> seb128_: would you mind reading that bug and letting me know of anything else you need/want
<jdstrand> ?
<seb128_> jdstrand: thanks for the details, I copied your comment upstream and asked on IRC, the guys who work on the calendar are not connected at the moment but I'll have them to look at the issue when they are
<seb128_> jdstrand: the description seems to be detailled enough, nothing else required from my part, let's see if upstream has some ideas
<jdstrand> seb128_: cool, thanks
 * jdstrand nods
<mdz> pitti: cool
<mdz> pitti: will you be doing an apport upload soon?
<pitti> mdz: yes, planned for today; just collecting some other issues
<pitti> mdz: that upload will enable it by default again
<pitti> I fixed the retracers this morning (yet again...), so we shuold be good to throw the switch
<mdz> pitti: great, thanks
 * pitti bows to "scary op" mdz
<mdz> pitti: I saw that the launchpad API lib has been released, hopefully that will help things break less
<pitti> mdz: oooooooooooooooh yes, I'm looking forward to use it :)
<pitti> I read about the ABI and the library this morning and discussed some packaging issues with james_w
<soren> Oh, you're packaging it? I won't bother then :)
<hwilde> who maintains the  experimental three-way merge of the grub menu.lst when updating kernels
<persia> soren: There's a candidate on REVU if you want to play
<james_w> packages are built in my PPA as well now
<james_w> ~james-w
<soren> Coolness.
<persia> james_w: Careful: tell everyone that and they won't be looking at the REVU package :)
<soren> I've already used the API a bit. It beats the heck out of the horrid screenscraping I used to be doing :)
<james_w> Testing welcome, but reviews on REVU would be great as well if you know any python packaging
<james_w> persia: true :-)
 * soren takes a look
<soren> james_w: Does it really need simplejson to build?
<james_w> soren: wadllib?
<james_w> that needs it for the testsuite
<soren> Yup
<soren> Oh.
<pitti> soren: you haven't used p-lp-bugs so far?
<pitti> and did screenscraping yourself?
<soren> Yes.
<soren> I've not looked at bugs, but people.
<pitti> ah
<soren> Someone told me py-lp-bugs didn't do that.
<pitti> that's true
 * sistpoty|work feels scraped
<soren> I use it to provide e-mail forwarding for ubuntu-dk members. It kept falling apart, so I'm quite happy with this new API.
<pitti> BenC, mdz, ogasawara: FYI, bug 254995 is with the updated apport and some redundancy removed; also "ubuntu-bug linux" DTRT now
<ubottu> Launchpad bug 254995 in linux "test bug, please ignore" [Undecided,New] https://launchpad.net/bugs/254995
<BenC> pitti: excellent
<ogra_cmpc> soo ... i have no screen anymore after upgrading my laptop
<ogra_cmpc> (intel graphics)
<persia> ogra: Which chipset?
<pitti> BenC: working on bug 241322 now; the requirements are still the same?
<ogra_cmpc> moving xorg.conf out of the way at least keeps it from restarting and i have the gdm drum sound
<ubottu> Launchpad bug 241322 in apport "Detect kernel crashdump" [Undecided,In progress] https://launchpad.net/bugs/241322
<tjaalton> ogra_cmpc: you have the latest evdev and hal installed?
<mdz> pitti: you rock
<ogra_cmpc> tjaalton, i did a dist-upgrade from hardy just now
<ogra_cmpc> thats been my first boot
<tjaalton> blank screen sounds like usplash/kernel
<pitti> *beam* :)
<ogra_cmpc> X seemed not to like my xorg.conf i needed for trh touchscreen
<hwilde> ogra_cmpc,  if you run updates you should get more
<hwilde> if thats your first boot
<ogra_cmpc> so removing that and i hear gdm swtarting
<ogra_cmpc> *starting
<ogra_cmpc> i booted without splash, no changes
<ogra_cmpc> persia, 965 iirc
<tjaalton> ogra_cmpc: disable failsafe from gdm.conf and start x with the xorg.conf to see where it fails
<ogra_cmpc> well, itrs an old hand crafted xorg.conf
<tjaalton> still :)
<hwilde> I would ctrl+alt+f1 and run the upgrades
<hwilde> but thats jus me
<ogra_cmpc> hwilde, there is no consiole
<ogra_cmpc> black screen
<persia> ogra_cmpc: Ah.  I had what looked like that on a 945 with an upgrade in the last couple hours, but it turned out to be X only listening to one of the mice and ignoring the keyboard (and gdm sleeping)
<hwilde> :/
<ogra_cmpc> well, gdm drums clearly
<tjaalton> ogra_cmpc: I had to switch to the console before usplash to see my screen (965)
<ogra_cmpc> hwilde, and which upgrades ? i did a fresh dist upgrade 10 min ago :)
<hwilde> I dunno... dist-upgrade just goes from one kernel to the other, then sometimes there are more updates once you are up to the newer kernel
<ogra_cmpc> tjaalton, durin usplash ?
<ogra_cmpc> i'll try that
<tjaalton> ogra_cmpc: yes, as early as possible
<zyga> hello everyone :/
<ogra_cmpc> hwilde, it installed about 2000 packages etc
<ogra_cmpc> oh, funny
<hwilde> ogra_cmpc, ok but I will bet you whenever you get back in that there are updates  :)
<ogra_cmpc> ctrl-alt-del gives me huuuge letters ion the screen
<tjaalton> ogra_cmpc: same here
<ogra_cmpc> meh, but switching away in usplash gets me to a black screen again
<ogra_cmpc> no console
<tjaalton> weird
<ogra_cmpc> gdm drums though
<tjaalton> oh. you need to shut down the machine
<ogra_cmpc> ah, reboot isnt enough ?
<tjaalton> nope
<ogra_cmpc> same behavior
<ogra_cmpc> black screen, backlight on
<ogra_cmpc> flashing several times while switching to X, then gdm drumming
<ogra_cmpc> bah, and now it looks like i get a fsck :(
<tjaalton> heh :)
<ogra_cmpc> or something wipes my disk recursively, who knows
<BenC> pitti: yes, nothing's changed
 * ogra_cmpc waits patientlly ... twiddling thumbs
<tseliot> ogra_cmpc: can you boot in recovery mode and get your /var/log/Xorg.0.log?
<ogra_cmpc> BenC, GPE storm detected on boot, is that something i should worry about ?
<ogra_cmpc> tseliot, i actually belive its the framebuffer misbehaving, but i'll check the file
<mdz> my up arrow key is now a shortcut for print screen
<ogra_cmpc> how handy
<hwilde> I like keytouch
<tjaalton> mdz: change the kb model to evdev
<mdz> it is actually extremely inconvenient, because it is a key I tend to press several times before I realize what is happening
<tjaalton> that should be forced though
<BenC> ogra_cmpc: err, sounds bad
<ogra_cmpc> ooooh
<mdz> tjaalton: thanks...is there a more permanent and automatic fix on the way?
<ogra_cmpc> i have X !!!
<ogra_cmpc> bootin 10 times with usplash disabled seems to have gotten me there
<mdz> tjaalton: my xorg.conf is entirely autogenerated
<ogra_cmpc> smells like a race
<ogra_cmpc> wrong resolution though
<tjaalton> mdz: yes, it should be forced always
<mdz> tjaalton: setxkbmap -model evdev didn't fix it
<tjaalton> mdz: as evdev, because gnome is borked
<mdz> tjaalton: is there a bug number for this?
<tjaalton> hm, maybe I need to test the latest fedora patches for real..
<tjaalton> mdz: nope
<tjaalton> not that I know of anyway
<mdz> tjaalton: on which package should I file it?
<tjaalton> ogra_cmpc: good for you :)
<tjaalton> mdz: xorg-server
<ogra_cmpc> so now i run a dpkg-reconfigure xserver-xorg to get a clean xorg.conf ....
<tjaalton> ogra_cmpc: it would be nice to know what broke it in the old config
<ogra_cmpc> it points the keyboard setup to kbd, should i change that ?
<ogra_cmpc> \well, i booted serveral times with no config at all
<tjaalton> ogra_cmpc: keyboard/mouse sections are completely ignored now
<ogra_cmpc> ah, k
<tjaalton> ogra_cmpc: the blank screen bug is different
<ogra_cmpc> because i dont have any keyboard input (apart from console switching) in X now
<tjaalton> ogra_cmpc: check the version of hal
<ogra_cmpc> i would expect the latest but lets see
<tjaalton> depends on the mirror you use
<ogra_cmpc> bah
<ogra_cmpc> ubuntu4
 * ogra_cmpc switches mirrors
<tjaalton> right, install u5
<mdz> tjaalton: bug 255008
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [Undecided,New] https://launchpad.net/bugs/255008
<persia> tjaalton: Thank you for the vastly improved input subsystem: it detects and autocalibrates my touchscreen now.
<ogra_cmpc> sweet !!
<tjaalton> mdz: cool
 * ogra_cmpc eagerly waits to see that 
<tjaalton> persia: that's.. probably unexpected but nice :)
<sladen> persia: what model/device do you have?
<zyga> does cannonical have a irc channel (for any official/semi official things)?
<tjaalton> ogra_cmpc: intel 2.4.0 seems to work a bit better, although console seems broken still
<pitti> zyga: C does not have a channel on freenode, or any 'official' channel; we do have a company-internal server, though
<persia> sladen: Kohjinsha SR series with a DIALOGUE PenMount USB
<ogra_cmpc> hmm, intresting ...
<zyga> pitti: I see thanks
<ogra_cmpc> NM tells me it adds my DVD to the hal db
<tjaalton> bah, blank screen after reboot
 * zyga has just received a notice that his employer went belly-up and is now looking for a new job
<sladen> tjaalton: back to your earlier question;  PnP provides enumeration; so a check for 'WACf004' ... which shows there's a serial port at 0xf123 irq 0x42;  so kernel pops up /dev/ttyS3;  init.d/*wacom* (in future, HAL), maps that to  /dev/wacom  X (since broken in the last release) spots that I talks Wacom down that symlinked serial port
<sladen> persia: okay, USB HID device  ("boring" ;-)
<pitti> zyga: if you want to ask any non-Ubuntu business issue, please see http://www.canonical.com/aboutus/contactus
<persia> sladen: Yes, well, but it didn't autoclibrate in Hardy.
<zyga> thanks
<ogra> persia, no touchscreen love for me :/
<ogra> and xchats themeing is badly broken
<persia> ogra: No?  I thought you said you had the same device at UDS :(
<sladen> persia: in hardy it would just be mapped (added together will all other mouse-like input) and read through /dev/input/mouse
<sladen> persia: here, X is now treating it as a separate input device
<ogra> IDEACOIDC 6680
<ogra> thats what i have
<persia> sladen: Right, which is significantly more sensible.
<ogra> hal reports it as /dev/input/event2
<ogra> but doesnt seem to handle it at all
<ogra> in hardy it worked but was miscalibrated
<sladen> ogra: grep WAC /sys/bus/pnp/devices/*/id  ?
<ogra> nothing
<ogra> its a USB device
<ogra> not sure that registers on pnp
<sladen> ogra: no, it wouldn't if it's USB
<ogra> and its not wacom compatible either if that was your intention
<ogra> it worked fine with the evtouch driver before
<persia> ogra: What events does it expose (according to lsinput)?
<sladen> (input-utils)
<pitti> BenC: ah, the current "kernel crash" mode in the apport UI says "Your system might become unstable now and might need to be restarted."; that was for the original (2 years back) specification, but is not true any more, right? vmcore reading, etc. will happen after the next reboot only
<ogra> persia,  http://paste.ubuntu.com/34455/
<mdz> pitti: echo c > /proc/sysrq-trigger if you want a real live test :-)
<mdz> pitti: yes, the dump will only be there after the system has restarted and written the dump
<mdz> pitti: however, I think it would also be useful to capture bugs other than crashes, e.g. BUG() (in which case the message would be appropriate)
<mdz> pitti: but that's a separate project
<pitti> mdz: ah, I used cp /somefile /var/crash/vmcore so far; but will do that as well :)
<BenC> pitti: right
<persia> ogra: That matches the list of services on mine :(
<ogra> weird
<BenC> pitti: if apport can detect that an oops occured without bringing the system down, that old feature is useful
<pitti> BenC: not right now, only if something manually triggers it (calls kernel_hook)
<tjaalton> ogra: it's probably evtouch which made the server fail then, since the driver doesn't seem to work with xserver 1.5
<ogra> meh
<pitti> BenC: but let's stash this as a separate project, yes
<ogra> tjaalton, and possible fix in sight ?
<ogra> i know it needs evtouch
<tjaalton> ogra: seems like it's trivial, bug 254848
<ubottu> Launchpad bug 254848 in xf86-input-evtouch "undefined symbol: xf86memset" [Undecided,New] https://launchpad.net/bugs/254848
 * ogra tries that ...
<ogra> oh, meh, need to update my pbuilder first
<mdz> pitti: this was #3 on the apport/kernel list I sent you
<ogra> its intresting btw that gdm drops me into a wrong resolution ... the desktop then works as expected
<mdz> pitti: do you happen to know if bryce has his X hooks working now?  they don't seem to be in the packages yet
<pitti> mdz: haven't heard about this since the sprint
<mdz> pitti: it's on the platform team 8.10 list
<BenC> pitti: sounds good
<BenC> soren: ping...how's the -virtual kernel in intrepid looking for your purposes?
<soren> BenC: I must admit I never found the opportunity try it. Could you send me the link again?
<BenC> soren: it's in intrepid proper now
<BenC> Although I guess I should add it to linux-meta, but linux-image-2.6.26-5-virtual package exists
<soren> BenC: Oh, that's why I didn't find it then :)
<soren> BenC: I'll take it for a spin tomorrow. I'm a bit tied up right now.
<BenC> soren: no rush on my end...just want to make sure it is suitable
<fabbione> BenC: what's the deadline to get a couple of kernel modules in before intrepid releases?
<BenC> fabbione: ASAP
<fabbione> BenC: ASAP is within this week is fine?
<fabbione> BenC: or ASAP like 20 days ago?
<ogra> (II) XINPUT: Adding extended input device "IDEACO^D  IDC 6680" (type: MOUSE)
<ogra> (II) config/hal: Adding input device SynPS/2 Synaptics TouchPad
<ogra> (II) LoadModule: "synaptics"
<ogra> hmm
<ogra> (II) IDEACO^D  IDC 6680: Found mouse buttons
<ogra> (II) IDEACO^D  IDC 6680: Configuring as mouse
<ogra> bah, just because it has a button it desnt necessarily need to be a mouse you silly thing
<BenC> fabbione: this week is good
<tkamppeter> Anyone knows whether heno is around? I have sent him a mail yesterday and got no answer.
<stgraber> tkamppeter: he's
<stgraber> tkamppeter: he sent some mails to ubuntu-qa 30 mins ago
<pitti> ogra: wait until X automatically picks up your bluetooth mobile as keyboard
<ogra> haha
<soren> ogra: What is that IDC 6680 thing really?
<ogra> soren, a touchscreen
<soren> Ah
<soren> Heheh :)
<pitti> but shouldn't that be treated as a mouse?
<ogra> needing the evtouch driver
<ogra> no
<ogra> so for the toplevel it loads evdev which might be ok, not sure ... but for the actual /dev/input/event2 device it then loads synaptics
 * ogra looks where to put an fdi file to override that
<pitti> BenC: new apport with kernel magic uploaded (enabled by default now, too)
<tjaalton> ogra: evtouch needs a fdi file to load evtouch for that device
<ogra> tjaalton, right
<BenC> pitti: sweet, thanks...I'll test it later today
<ogra> thats what i figured, but i'm not sure evdev is actually wrong for the topevel device
<tjaalton> ogra: /etc/hal/fdi/policy
<tjaalton> that's the place for local files
<ogra> thanks, i'll play with that
<pitti> BenC: so far I copied two random files to /var/crash/vmcore{,.log} and simulated a boot with "sudo /etc/init.d/apport start"
<BenC> pitti: I'll try to get a real crash and real vmcore
<seb128> pitti: is dbus maintained in bzr? any objection if I do an upload to enable the x11 script again in dbus-x11?
<pitti> seb128: no bzr; no, please go ahead, that'll drop another delta to Debian
<seb128> thanks
<seb128> upstream decided now that dbus is a system thing so they made gnome-session rely on it being started before
<pitti> aah
<pitti> and they stopped relying on it promoting GNOME env vars?
<pitti> (to activated backends)
<ogra> they discussed the dbus system art as kernel module in rague
<ogra> *part
<ogra> *prague
<ogra> *sigh*
 * pitti hands ogra a new P key
<asac> ogra: wasnt that marcel holtmann?
<pitti> modprobe dbus? argh
<asac> pitti: dbus instead of libnl for instance ;)
<ogra> asac, well with (kai) dbus upstream and davidz at the table
<elmo> hahahahahahahaha
<elmo> seriously?
<ogra> and they werent joking
<asac> that was one of the use cases according to marcel
<pitti> asac: oh, btw, if you upload n-m 0.7, can you please make sure that the init script does not run for rc0 and rc6, to save us another symlink transition later on?
<ogra> but there was beer ivolved ... so ...
<seb128> pitti: yes
<pitti> asac: (I guess 0.7 moves /etc/dbus-1/event.d/25NetworkManager to a proper init script)
<asac> yes.
<pitti> asac: great, thanks
<asac> pitti: is "multiuser" the right?
<pitti> asac: no, please don't use multiuser, that's deprecated
<asac> ok
<pitti> asac: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-June/000430.html
<bigon> is it intended that networkmanager is only work after logging in a graphical session?
<hwilde> who maintains the  experimental three-way merge of the grub menu.lst when updating kernels
<hwilde> nobody wants to take credit? :)
<asac> bigon: depedns
<asac> bigon: 0.6 needs to get your credentials from keyring, so networks that require secrets (wpa etc.) need a running session
<ogra> hwilde, ??
<ogra> can you elaborate ?
<asac> bigon: open networks and normal wired ones should work even in 0.6
<bigon> asac, well logginin in console and try to run nm-tool just after boot doesn't work
<ogra> is nm-tool suposed to have any functionality ?
<ogra> i thought it was only for reporting avalable interfaces
<asac> bigon: plesae check that NetworkManager process is actually running
<asac> ogra: right. its just introspection
<bigon> asac, networkmanager and networkmanagerdispatcher are running
<bigon> as root
<asac> sure
<asac> bigon: so what does nm-tool give you?
<hwilde> ogra, when you run dist-upgrade and it updates the kernel if you have a modified /boot/grub/menu.lst it prompts you what to do, one of the options is experimentla three-way merge,  who is that?
<bigon> asac, networkmanager is not running or somethink liketaht
<ogra> hwilde, thats ucf taking care of you having changed the wrong bits of the file :) only change the kopt line and it will stay quiet
<bigon> but actually both process are there, I loggin in gnome goes back to the console and then I get some results
<asac> have you tried to run nm-tool as root?
<ogra> hwilde, thats thats by no means experimental and was like that in hardy as well :)
<ogra> thats
<ogra> -thats i meant
<bigon> asac, good question I will reboot and check that
<hwilde> ogra, but I want it to maintain my irqpoll routeirq and acpi=off settings  it keeps replacing that at the end of the kernel line
<ogra> hwilde, where do you add them ?
<ogra> hwilde, # kopt= is the right place ... then run update-grub afterwards, the noise will stop and your kernel lines will have the right settings
<pitti> soren: did you see mvo's regression report in bug 234062?
<ubottu> Launchpad bug 234062 in ubuntu-vm-builder "[SRU] ssh root login broken" [Undecided,Fix committed] https://launchpad.net/bugs/234062
<mvo> pitti: we talked about it earlier, I uploaded another sru to -proposed that should fix this regression (give me a sec, I dig out the bugnumber)
<hwilde> ogra, cool I did not know kopt.    it also overwrites root=/dev/sda1 with the UUID is there a flag to disable that
<mvo> bug 254966
<ubottu> Launchpad bug 254966 in ubuntu-vm-builder "The --ssh-key changed behavior between hardy-updates and hardy-proposed" [Medium,In progress] https://launchpad.net/bugs/254966
<pitti> mvo: ok, thanks
<ogra> hwilde, check if you fine the uuid anywhere in that file
<ogra> *find
<ogra> but uuid is actually the better way, why do you want to keep the old notation (which is going to vanish at some point) ?
<ogra> (uuid is likely also in the current kopt line)
<bigon> asac, yeah actually nm-tool works as root
<ogra> might be because you have no seeion dbus without a graphical session
<ogra> *session
<ogra> and normal users cant access the system dbus
<ogra> that always needs to go through the session bus
<ogra> so it will work fine in an xterm/gnome-term but likely not on console
<asac> bigon: great.
<asac> bigon: what wifi chipset do you have?
<hwilde> ogra, I have to clone the image between hundreds of machines so I can't use uuid.   what i'm really asking is if the experimental three way merge could JUST upgrade the kernel version and not touch the rest of the options on that line
<norsetto> pitti rulez: https://edge.launchpad.net/~we-love-pitti
<pitti> aaargh
<bigon> asac, Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection
<asac> bigon: ok. then have fun ;)
<ogra> hwilde, grub uses kopt since it exists
<asac> i am searching for users with b43 driver :)
<ogra> hwilde, and there is nothing experimental in ucf
<asac> ogra: dont you have something like that?
<asac> ;)
<bigon> asac, btw I get some warning when rebooting/shutting down, networkmanager says that it has been disconnected from the bug
<jdstrand_> pitti: oh, oh-- I should sooo join that team :)
<asac> bigon: s/bug/dbus/ ?
<ogra> hwilde, i would suggest something like a sed line that catches the kopt line, changes it to your needs and seeds the right UUID for such a case, thats a small script
<bigon> asac, yeah :)
<asac> bigon: thats known and wont be fixed until NM 0.7
<ogra> hwilde, hwo do you know the kernel always calls the disk sda1 ? there is no guarantee at all anymore, its a total matter of luck
<bigon> asac, ok thx for your help
<ogra> asac, on my old lappie i have a b43 i think ... but thats still on gutsy
<ogra> and is amd64 with 1G ram ... which is a lethal combo for b43 (or at least was)
<geser> pitti: you are not a member of that team yet? :)
<pitti> geser: I deny even the slightest responsibility, or even affiliation to that :)
<asac> ogra: please upgrade ;)
<ogra> asac, meh
<asac> or well. i can also wait till colin returns tomorrow
<ogra> how urgent do you need a test
<ogra> one upgrade per day is really enough for me :)
<jdstrand_> pitti: it's a pretty bad-@#$ picture too, with that smirky/snarl :P
<asac> hehe ... it blocks NM 0.7
<asac> ogra: you could install i386 hardy on that thing ;)
<asac> then its one upgrade + one install ;)
<norsetto> jdstrand_: hey, mind you words when you talk about THE pitti
<ogra> it has daa i still need to backup
<ogra> *data
<jdstrand_> norsetto: it was meant as a compliment :)
<norsetto> jdstrand_: ;-)
<jdstrand_> (in the Chuck Norris vein)
<hwilde> ogra, it's sda1 on all of 180+ machines that I have running with that image.  why would that ever change
<warp10> norsetto: we plan to print some t-shirts too. Do you want one?
<norsetto> warp10: absolutely!
 * norsetto plans to have his t-shirt signed
<ogra> hwilde, because the kernel or udev decide to
<slangasek> you people disturb me
<ogra> slangasek, envious ?
<warp10> norsetto: signed t-shirts are available at twice the price
<slangasek> ogra: frightened
<ogra> heh
<ogra> slangasek, you choose to take the job ... now live with your rockstar image :P
<slangasek> when I signed on, I was told only the community team had to have rockstar images
<mvo> I need a good way of saying "All files that have been downloaded so far are kept and do not need to be downloaded again if you decide to run the upgrade again" (context is when the connection drops during a release-upgrader download. any suggestsions?
<norsetto> mvo: if you need an hand with sru-verification, I'll be glad to join
<mvo> norsetto: hands for this are always welcome! sbeattie and bdmurray are probably better persons to talk to nowdays (I'm doing verifications very rarely only these days)
<norsetto> mvo: ok, will do then, thx
<tkamppeter> stgraber, thank you for the info.
<hwilde> ogra, it's not luck if it's exactly the same on 180 different machines, cmon
<hwilde> be realistic here
<ogra> hwilde, just dont complain if it breaks
<hwilde> ogra, the point is why does updateing the kernel update anything but the kernel?  just update the kernel not the rest of the options
<hwilde> in the whole menu.lst all it needs to do is change the number on the kernel, nothing else
<ogra> kopt cares for exactly that
<hwilde> but it overwrites root=/dev/sda1 with the UUID
<ogra> but slangasek might be a better pendant for you to discuss ucf and menu.lst
<ogra> only if the UUID is defined soemwhere in the kernel options in that file
<ogra> which i suppose it is since its the default
<ogra> hwilde, and sda can easily become sdb if for example someone left a backup usb drive plugged in you dont know about ... if that becomes sda1 because the kernel likes to name it like that the backup would be gone
<ogra> (and you wouldnt have a bootable first system disk)
<ogra> UUID prevents that
<hwilde> ogra, UUID does not allow cloning the image to 180 machines
<ogra> as i said above, have a script that detects the UUID and adds it in the kopt line properly
<sbeattie> norsetto: if you're interested in doing sru verifications, we'd love the help.
<norsetto> sbeattie: that would be cool, I just applied to join the team
<Kopfgeldjaeger> norsetto_limbo: Thanks for commenting http://revu.ubuntuwire.com/details.py?package=gtkhash -- I'm not sure about 2. I removed some newlines in the manpage. But I can't really really take away the newlines in the description because that would be over 80 chars/line.
<Kopfgeldjaeger> mv discussion #ubuntu-motu/
 * ogra wonders why evo is missing after his dist-upgarde
<ogra> seb128, so evo was nice and duplicated all messages in my inbox for me :P
<ogra> hardy->intrepid upgrade
<ogra> oh, it only listed them twice after the first new send/recive they are single msgs again
<ogra> but why dont i get any windowframes for the evo window :(
 * ogra curses ... i want my frames back !
<kirkland> ogra_cmpc: try ctrl-m
<ogra> yippie, the evo mail notification stopped the annoying blinking !!
<ogra> err, hmm no it didnt ... weird
<seb128> ogra: so after some testing what issue do you still have? ;-)
<ogra> none :)
<ogra> it seemed a bit shaky
<seb128> did you get 2.23.6?
<ogra> having all mails in inbox twice until i did my first poll agan, the blinking notification is much quieter now (stops blinking after a few times)
<ogra> 2.24 i thought
<ogra> ah, 2.23.6
<ogra> yeah
<ogra> not sure what the missing window borders were about ... i had the UNR packages installed, i bet they were at fault
<ogra> intresting though that it only affected evo
<seb128> ogra: they fixed load of bugs this cycle, some hundreds again
<ogra> what i really wish for is that the mail notification brigs evo up if i click it ... its annoying to have to click the icon *and* the window list
<seb128> ogra: but 2.23.5 and 2.23.6 had quite some changes, they landed the on disk summary code, now disk summary uses sqlite
<seb128> right
<ogra> i noticed its a bit slower rendering the folders
<ogra> especially if they are bg
<ogra> *big
<seb128> I didn't package 2.23.5 because it was too buggy but 2.23.6 should be mostly alright
<seb128> oh?
<seb128> how many mails?
<ogra> my smallest has about 500, my biggest something like 30000
<ogra> the big one takes about 1.5-2 secs until i see the msg list ...
<seb128> the new version was freezing for some seconds when opening my mailbox but that has been fixed this afternoon, I'm listing only unread mails and it was being slow at list hidden ones apparently
<ogra> before it was rather instantly
<seb128> do you have lot of hidden mails there?
<ogra> but i can live with a 2sec delay
<ogra> not really
<seb128> ok, differently issue probably
<ogra> i leave all of them visible
<ogra> since i use evo as archive tool and search a lot in it
<seb128> they are optimizing things, they wanted to get the thing working first before looking too much to performances
<seb128> I expect it'll get better again before intrepid
<ogra> it was nice to not lose mail this time :)
<pedro_> it's way faster to me than in hardy in reading my bugmail folder with about 60000 emails
<ogra> i had worse upgrade experiences with it
<pedro_> but the summary of the search folders aren't working  :-(
 * ogra didnt use search folders for quite some time 
<ogra> since gutsy i think
<seb128> pedro_: search folder = vfolder?
<seb128> I think that was too buggy and they desactivated some functions for now
<seb128> I don't use those
<pedro_> seb128: yes, but it's known they working on it according to bug http://bugzilla.gnome.org/show_bug.cgi?id=545317
<ubottu> Gnome bug 545317 in Mailer "Mail filters don't work anymore" [Major,Unconfirmed]
<seb128> alright
<ogra> seb128, all in all i'm very pleased ... now i'd only like to see all the lexington patches applied to be able to use evo in mobile :P
<seb128> ogra: oh, they have changes to evo? did they attach those somewhere?
<Adri2000> any archive admin: would you pretty please let the amsn sru go in hardy-proposed? :)) it's bug #243722 and it seems to be affecting more and more people
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,Confirmed] https://launchpad.net/bugs/243722
<seb128> Adri2000: you need an sru team member, not an archive admin there
<seb128> Adri2000: ah, it has been approved, looking
<DRebellion> slangasek, on the topic of monkeystudio: is it ok if the qscintilla source is still included in the source package (for win32/osx builds) but not used?
<DRebellion> apachelogger, ^^
<slangasek> DRebellion: yes - though I would note that since your .orig.tar.gz is currently built out of svn, it seems trivial to excise it at the same time? :)
<seb128> slangasek: hey, could you look at the amsn hardy-proposed sru universe upload Adri2000 just mentionned? I think it's ok to accept but I don't do srus usually so I'm not sure if sru-accept should be used or how guys do those
<DRebellion> slangasek, i wouldn't feel confident removing it - the whole source package is quite complex.
<seb128> slangasek: it's an universe upload and has been approved so technically it's just waving it in I think, right?
<DRebellion> slangasek, plus, i thought we were meant to leave upstream's source well alone
<DRebellion> ?
<slangasek> DRebellion: when upstream publishes a tarball, it's generally preferred that you not modify it when feasible; but when you're building from a VCS anyway, there's no advantage to an "unmodified" tarball...
<lifeless> slangasek: huh?
<lifeless> slangasek: why is vcs any less precious than the contents of a tarball; both are hashable for integraty verification by third parties
<slangasek> DRebellion: it would just have been nice to be able to omit that chunk of code from e.g., debian/copyright
<DRebellion> slangasek, ok, i will ask upstream
<DRebellion> wait, no, i'll just remove it myself :P
<slangasek> seb128: has it been acked by motu-sru?
<seb128> slangasek: yes, see 243722
<slangasek> seb128: sru-accept is new, actually, I haven't seen what it does; I'll have a look in a little bit and let you know
<seb128> ok thanks
<seb128> I guess it's another pitti's toy ;-)
<Adri2000> thanks slangasek and seb128 :)
<slangasek> lifeless: ok, *if* a straight checkout gets you an appropriate orig.tar.gz, then that's a reasonable concern, yes; if you're running ./autogen.sh as part of the get-orig-tar target, less so...
<lifeless> slangasek: true
<lifeless> slangasek: I'm of the school that derived content (running autogen) belongs at build-time :)
<slangasek> yes... :)
<slangasek> seb128: oh, no, sru-accept isn't the one I was thinking of, I've used that tool lots of times ;)
<slangasek> seb128: sru-accept is used to tag the bugs appropriately, yes; the actual accept is done the normal way
<slangasek> seb128: which you are welcome to do as my attention is divided at the moment, or I'll get it in a bit
<seb128> slangasek: ah ok, so you do accept the upload and use sru-accept to update the bug?
<slangasek> seb128: correct
<seb128> ok, I've to run now but I'll give a look later if you didn't accept this one first, feel free to process it if you have the opportunity, I'll have other occasion to try it later ;-)
<slangasek> jdstrand_: <blink> why does ldap gssapi need /dev/tty?
<slangasek> seb128: ok, later :)
<jdstrand_> slangasek: that's a good question, but apparmor complains otherwise
<slangasek> well, eep
<slangasek> jdstrand_: heh, and the preceding security upload for some reason commented out debconf-updatepo in debian/rules; wtf?
<jdstrand_> slangasek: kees did the last upload
<slangasek> kees: wtf? :)
<kees> slangasek: which package?  this is something I've been doing for a while to reduce debdiff deltas.
<slangasek> kees: openldap2.3
<kees> slangasek: has this caused a problem?
<slangasek> kees: no, I just noted it in the diff while reviewing an SRU
<slangasek> kees: but if debconf-updatepo ever gave you a delta on openldap, let me know so I can scream at someone ;)
<kees> slangasek: ah-ha, okay.  Yeah, I do this to avoid a massive diff delta.  It used to always give me deltas due to timestamps changing.
<kees> slangasek: I can't say if it happened on openldap itself, but it happened with so many other packages, I just added this to my security update build check list
<slangasek> oh, I suspect that was a bug in an older version of debconf-updatepo then
<kees> slangasek: afaik, it's harmless to comment out post-release.
<kees> slangasek: that could be
<Adri2000> slangasek: amsn sru pretty please? :p and while you're at it amsn-data is waiting in intrepid binary new. thanks!
<slangasek> Adri2000: amsn is already accepted?
<slangasek> er, no
<slangasek> hang on, accepted shortly :)
<cr3> slangasek: ping, would you happen to be familiar with the build process of the alternate image? I encountered a problem where the netboot kernel is not the same version as the debian packages on the image, bug #255093
<ubottu> Launchpad bug 255093 in ubuntu "Netinstall for 20080805 fails with: No kernel modules were found." [Undecided,New] https://launchpad.net/bugs/255093
<cr3> slangasek: I'm wondering if I should perhaps report a bug against launchpad in the event the build process was automated somehow, but I'm just not familiar with launchpad to know
<ogra> thats likely being d-i out of sync
<cr3> ogra: ah, so the linux and initrd.gz files are provided by the d-i package?
<ogra> there was a kernel upload recently and colin is on holiday so he didnt update d-i accordingly
<ogra> i think d-i is special in this case
<cr3> ogra: that process seems error prone, but I don't want to be pretentious in suggesting it could necessarily be automated. perhaps would there be an appropriate place to report a wishlist for this?
<ogra> and needs to be built against the current kernel if we get a new one .... i.e. there are a lot of packages built as udebs
<ogra> by the linux package
<ogra> d-i will want to pull these in
<ogra> cr3, colin hould be back tomorrow, i would discuss it with him before filing a bug
<cr3> ogra: ok, worst case, I'll ask if evand could handle this during his holiday next week
<ogra> colin will be around for the next alpha
<ogra> and i doubt anyone actually takes massive care for dailies for that
<cr3> ogra: I finally automated the whole process of testing dailies. as soon as new dailies are detected, I test the builds: ubuntu, kubuntu, mythbuntu, ubuntu-server, ubuntustudio, xubuntu. so, I'll be keeping close tabs on those dailies :)
<ogra> thats mad
<ogra> nobody really cares for dailies bwing installable
<ogra> *being
<cr3> ogra: what's the point of an iso image if you can't install it?
<stgraber> ogra: we do :)
<ogra> in fact the majority before the late alphas will be broken since we upload packages for implementing features that often require a package set in place before something works
<ogra> well, if they work thats by occasion ...
<ogra> but we only really put deliberate work into alphas to make sure they work
<cr3> ogra: what's this "package set in place"?
<ogra> well, for example i have compcache on my plate for the liveCD
<stgraber> ogra: I guess I found the problem with my VM ... no hald running ?? known issue ?
<ogra> one part has to be implemented in initramfs-tools, the other in casper
<cr3> ogra: those will also be tested automatically, but it would be reassuring to know that the dailies from a day or two before alpha actuall work
<ogra> stgraber, no hal installed on thin clients :)
<stgraber> ogra: and no dbus either (hal's dep)
<ogra> i never was
<stgraber> ogra: it's installed, dbus too
<ogra> oh
<stgraber> ogra: I guess that was added to Xorg depends
<ogra> oh !!!
<ogra> thats pretty bad
<stgraber> or something similar because I just rebuilt a chroot and got hal and dbus installed
<stgraber> and no Xorg input because of hal not running
<ogra> bryce, so xorg doesnt work in minimal setups at all anymore ?
<cr3> ogra: so compcache might make it in initramfs-tools before or after in casper, so the live and alternate might be different at some point in time, right?
 * ogra sighs
<ogra> so i have no idea why i put that much work into getting 24M clients to work ... we wont be able to use X on them at all
<bryce> ogra, what are you talking about?
<ogra> cr3, right ... and now imagine (what isnt the case) that the change to initramfs-tools only works if the change in csper is also there
<stgraber> ogra: libhal1 is now a depends of xserver-xorg-core, so it installs dbus and hal in the chroot ...
<ogra> bryce, hal and dbus being a hard dep of X now
<ogra> bryce, so there is no way anymore to have a minimal setup that runs on low power systems
<ogra> one declared target for ltsp was to support 24MB clients ths cycle because we get many requests
<ogra> but that would only work with hardcoded xorg.conf (a blame te users would take) ... though running hal and dbus on such systems is not an option, they would run out of ram during boot
<bryce> ogra, yeah no secret that xorg was moving to depend on those
<tjaalton> ogra: x-x-c depends on libhal already since hardy
<ogra> hrm
<ogra> but it doesnt work at all without them running anymore
<tjaalton> there's a patch pending
<ogra> i dont care if tehy sit in the chroot for ltsp clients ...
<ogra> but they cant run on minimal HW
<ogra> tjaalton, to make x capable of using the old methids ?
<ogra> *methods
<tjaalton> http://cgit.freedesktop.org/xorg/xserver/commit/?id=2eaed4a10fe5bf727579bca4ab8d4a47c8763a7d
<Adri2000> slangasek: thanks for the sru. could you also do amsn-data binary new in intrepid please?
<ogra> tjaalton, sweet thanks
<ogra> that sounds usable
<tjaalton> ogra: all it would need now is to add the input devices in serverlayout
<bryce> tjaalton: btw did pitti include my console2fdi.sh script in hal for the keyboard stuff?  (just checking that I can cross it off my todo)
<ogra> btw i got nowhere with my touchpad and gave up for now
<stgraber> tjaalton: well, we were happy to just run without xorg.conf and IIRC it used to work where it now doesn't (without hal)
<tjaalton> stgraber: yes
<ogra> we even put a week of work into ldm to support setxkbmap ... :(
<tjaalton> bryce: well, hal uses the callout script modified from fedora, so there's no need to generate an fdi file
<ogra> i guess thats moot
<stgraber> ogra: is the compcache magic supposed to just work if I boot with "-m 24" or do I need to enable it somewhere ?
<ogra> (since xkb was the only thing we actually used xorg.conf for )
<tjaalton> bryce: which is nice, since there's only one configuration file now (/e/d/console-setup)
<cr3> ogra: gotcha, thanks for the use case
<ogra> stgraber, see initramfs.conf its documented
<tjaalton> stgraber: file a bug about the hal-less problem
<stgraber> tjaalton: against ?
<ogra> xserver-xorg ?
<tjaalton> stgraber: xorg-server
<jcristau> stgraber: xserver-xorg-core
<tjaalton> yes, source package is xorg-server:)
<bryce> tjaalton: callout script?
<bryce> tjaalton: so the script I did is unnecessary then?
<tjaalton> bryce: basically yes.. now it works just the way colin suggested in december :)
<tjaalton> hal just needed one patch that fedora already had
<tjaalton> (--direct for hal-set-property)
<stgraber> tjaalton: bug 255133
<ubottu> Launchpad bug 255133 in xorg-server "Input devices not working without hal running" [Undecided,New] https://launchpad.net/bugs/255133
<tjaalton> bryce: so, hal runs this script when it founds a device that matches some criteria, see /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi
<tjaalton> stgraber: thansk
<tjaalton> -ks
<ogra> stgraber, can you try to move the ltsp-client-core initscript to a later start ?
<jcristau> tjaalton: two ways to fix this afaict. depend on hal, or default allowemptyinput to off.
<philsf> does apt-listbugs work with ubuntu?
<ogra> (i dont get why dbus and hal dont start at all though)
<stgraber> ogra: I can but that shouldn't change anything as after the client booted dbus and hald weren't running
<jcristau> tjaalton: i'm a bit tired of fighting it upstream, so. :)
<ogra> stgraber, yeah, i'll have to look into that
<ogra> bryce, tjaalton thanks a lot for the answers :)
<tjaalton> ogra: no problem, sorry for causing a heart-attack ;)
<bryce> ogra, glad it's worked out
<ogra> tjaalton, well, i could have thought about it myself, bryce was right ... but i didnt actually expect to lose all backwards compatibiity (and luckily the patch you pointed out will retain the bit i need)
<ogra> tjaalton, i'm actually upposed to not panic that much anymore ... so sorry for causing trouble first place :)
<tjaalton> jcristau: right.. there are two different bugs here..
<ogra> *suposed
<tjaalton> ogra: hehe
<tjaalton> jcristau: this one without the conf and the one that your patch would fix
<bryce> tjaalton: so I see there is a 'debian-setup-keyboard' listed in the info.callouts.add key, but what is that, a script, or...?  (it's not in path)
<tjaalton> bryce: it's a script, but only meant for hal, see /usr/lib/hal/debian-setup-keyboard
<bryce> tjaalton: huh, interesting
<Laney> doko: Hey, I don't know if you saw but bug #240884 got fixed upstream. It would be great if we could get a new binutils release with this change in if you have time :)
<ubottu> Launchpad bug 240884 in binutils "-g and compiling via assembly fails" [Unknown,Fix released] https://launchpad.net/bugs/240884
<superm1> tseliot, ping.  I wanted to discuss with you something that i see will turn into a maintenance difficulty of the nvidia drivers
<superm1> tseliot, regarding hardcoding exact library versions like nvidia-glx-177.links:usr/lib/libGL.so.177.13 usr/lib/libGL.so.1
<tseliot> ï»¿superm1: I'm here
<superm1> tseliot, so it looks like you are hardcoding the version number in tons of places
<tseliot> superm1: did you see the links.in?
<superm1> tseliot, oh... this is what i'm getting for grepping the source package and missing the .in files :)
<tseliot> the .links files are generated ï»¿automatically
<superm1> tseliot, okay that's much more sane
<tseliot> ï»¿superm1: that doesn't waste my time ;)
<tseliot> hardcoding the version would
<superm1> yeah
<ogra> wasting time is only good if beer friends and probably food are involved :)
<tseliot> ogra: no hardcoding is involved in that case :-P
<ogra> indeed :)
<superm1> tseliot, okay looks good then.  sorry for bothering you :)
<tseliot> ï»¿superm1: no problem :-)
<lucas> Riddell: I answered on the LP bug
#ubuntu-devel 2008-08-06
<Riddell> lucas: thanks, synced
<bryce> I'm getting a weird error trying to do a pbuilder update - http://pastebin.ubuntu.com/34576/ - anyone have some advice?
<bryce> ah nevermind, seems to be working now
<crimsun> those sometimes appear during mirroring
<bryce> crimsun: ah
<knix> ionstorm: You died a long time ago
<kirkland> anyone here know where grub-install is called in the installation process?  I'm not finding it in debian-installer, nor in the grub package itself
<ionstorm> eh?
<ionstorm> wrong ionstorm
<knix> lol
<ionstorm> im very much alive ;)
<knix> ion storm was a gaming studio that decided to spend all its funding on extravagent offices and do next to nothing
<knix> But they did produce Diakatana!
<ogra> kirkland, i think thats anna, not 100% sure though
<kirkland> ogra: hmm, still no grub hits
<ogra> ah, no, anna is apt-install
<ogra> its definately the last step the installer calls from menu
<Keybuk> knix: didn't they also do Deus Ex ?
<knix> Yes, butu let's not talk about that one
<knix> Deus Ex was a decent game
<knix> I don't want to associate that with ion storm
<kirkland> ogra: right, i'm trying to find *that* code :-P
<james_w> kirkland: grub-installer I think it's called
<james_w> yup, there's at least a package of that name
<kirkland> james_w: interesting, yeah, lemme check that out
<james_w> kirkland: also, your package on REVU looks good to me now, hopefully you can find some advocates
<kirkland> james_w: thanks much for the multiple rounds you gave me!
<kirkland> james_w: i think there are a few...  we were using it at the Lexington sprint and several people there asked me to package it
<ion_> benc: Online? :-)
<james_w> kirkland: no problem, it's always good to have the potential advocates be pushing you
<BenC> ion_: yeah
<ion_> benc: Hi. :-) So yeah, ckingâs patch seems to work for me. Any comments about the debdiff i sent?
<ogra> ion_, oh, before i forget, can you poke me about the revu compcache stuff by beginning of next week, i will have some spare time by then and plan to do the rest of the casper implementation then as well
<ion_> ogra: Ok, thanks.
<ogra> so that comes in handy to give you some ack on the package as well :)
<BenC> ion_: excellent...I was hoping cking would respond, but I think he's off
<ion_> benc: One thing that has been bugging me is that one needs to run grub-install manually after e.g. stage2 has been updated. I wonder how to fix that?
<ion_> benc: Could e.g. update-grub overwrite files in /boot/grub from /usr/lib/grub/i386-pc? A full grub-install shouldnât be necessary, i think.
<ion_> Or just the postinst
<slangasek> if you don't do a full grub install, there's a danger that the stage2 isn't compatible with the stage1 in the boot block
<ion_> Ok :-\
<slangasek> if you do a full grub install, there's a danger you'll toast it :-)
<ion_> Indeed. :-)
<ion_> Perhaps grub postinst and/or update-grub could just warn the user about the files not being in sync.
<kees> any eta on MoM getting back on its feet?
<ogra> send disks to speed it up :)
<ScottK> kees: DaD is still running if you want an immediately available alternative.
<kees> ScottK: cool, I'll check there for now.  I wasn't really looking for anything in particular, just noted it was still stalled.
<ffm|sh> are we in feature-freeze alreday for intrepid
<ffm|sh> ?
<ScottK> ffm|sh: No.  August 28
<ffm|sh> Wooh, I better get packaging then.
<ffm|sh> ScottK: Do I have to have my package submitted by then, or accepted?
<ScottK> Uploaded, but it can still be waiting New review by the archive admins.
<ffm|sh> ScottK: Ok, that applies for new packages as well?
<ScottK> Yes.
<ffm|sh> ScottK: Do all ubuntu binary packages have to have a manpage/
<ScottK> If lintian is telling you you need it, you do.
<ScottK> We share that goal with Debian.  For questions about packaging, #ubuntu-motu is generally a better channel.
<ffm|sh> Ok.
<fabbione> BenC: still around?
<dholbach> good morning
 * fabbione hugs dholbach 
 * dholbach hugs fabbione back :)
<LaserJock> hi dholbach
<dholbach> hi LaserJock
<LaserJock> dholbach: wb, sounds like India was fun
<dholbach> LaserJock: it definitely was
<LaserJock> dholbach: well, it's nice to have you back :-)
 * dholbach hugs LaserJock
<LaserJock> I thought maybe you got kidnapped by Ubuntu India ;-)
<dholbach> no no, the guys there were really really helpful
<dholbach> it won't have been my last time in india :)
<LaserJock> cool
<dholbach> and yes: I'll post pictures soon :)
<LaserJock> it's not a place I've ever imagined myself going too
<LaserJock> perhaps it's because I imagine it being hot and humid
<tjaalton> stgraber: ping
<dholbach> it depends on when you go... right now it was humid and hot in the north, but the more we headed up north into the himalayas the cooler it got - it was totally bearable :)
<dholbach> you can ask the folks in #ubuntu-in before you go :)
<LaserJock> heh
<lifeless> Riddell: around ?
<lifeless> Keybuk: or you ?
<pitti> Good morning
<ion_> morniÅ
<pitti> bryce: so, everything alright with current hal, or do we still need something? I thought the console2fdi script wasn't needed any more?
<bryce> pitti: doesn't sound like it
<bryce> there's a debian tool that does it already that timo ran across
<StevenK> pitti: Could you convinced to sync something that has no Ubuntu changes, and will remove it from the NBS list? :-)
<pitti> StevenK: absolutely
<StevenK> pitti: Do I need to file a request, or just tell you here?
<pitti> just tell me
<StevenK> pitti: libbuffy-bindings
<RAOF_> StevenK: lib*buffy*? :)
<pitti> StevenK: done
<StevenK> pitti: Thanks :-)
<StevenK> RAOF_: Yeah yeah :-P
<fabbione> pitti: since you are in such a good mood this morning.. mind to provide some NEW love to redhat-cluster ?
<fabbione> pitti: it spits a new libccs-perl package for libccs2 perl bindings
<fabbione> pitti: it can go in universe for now (libccs-perl that's it)
<pitti> se128's  archive day today...
<fabbione> pitti: oh cool thanks :)
<pitti> fabbione: accepted
<fabbione> pitti: thanks
<ion_> pitti: Since youâre in such a good mood this morning, mind sending me a thousand euro or so?
<pitti_grumpy> ion_: NO!
<ion_> Oh, well. Canât blame one for trying.
<fabbione> hahah
<StevenK> Haha
<persia> pitti: So you don't mind?  Should more of us ask? :)
<pitti> persia: can do, if you join https://launchpad.net/~we-love-pitti for two years and pay your monthly EUR100 membership fee
 * persia has trouble typing due to involuntary spasms of amusement
<slangasek> you should see a reflexologist for that
<persia> slangasek: It goes away after a few minutes, but I'm not sure I want to fix it: I'm not usually so amused in situations where physical stability is required.
<tjaalton> bryce: I only named it that so debian can adopt it once they use console-setup :)
<slangasek> persia: heh
 * StevenK makes pitti less grumpy by uploading 12 packages for NBS
<pitti> \o/
 * StevenK grins
<slangasek> StevenK: kissing up to all the archive admins as once? that's just wrong
<StevenK> slangasek: as once?
<slangasek> ... at once
<slangasek> I think the heat here is confusing my fingers
<StevenK> Like you know what summer is. :-P
<persia> Clearly a problem for Archibald Tuttle
<slangasek> I know what proper environmental conditions that let me type are. :)
 * StevenK grins
<ion_> I could use some of your excess heat.
<tkamppeter> Hi, I have a question about packaging
<tkamppeter> I got from the OpenPrinting Japan workgroup 4 CUPS filters for PDF printing: imagetopdf, pdftoopvp, pdftoraster, and pdftopdf-
<tkamppeter> They have four separate source tarballs for them but they packaged up all in one Debian package.
<tkamppeter> I would like to know, whether I should better packaqge them as one PDF filters package (as the guys from OP Japan did) or as 4 separate packages.
<geser> are new upstream versions released independently or in one batch for all?
<persia> Alternately, do you expect to treat upstream as the OpenPrinting Japan group, or as the upstreams for the individual tools?
<tkamppeter> For now they released them altogether, making 4 SVN snapshot tarballs and then taring them together into one big tarball with version number 0.4.2. From that they made a Debian package.
<emgent> moin
<persia> tkamppeter: So OPJ is upstream in both the sense of being the coordinators of the code and those from whom you received the code?
<pitti> james_w: when you changed the perms in polkit, did you because it didn't work otherwise, or just followin upstream documentatin?
<james_w> I changed to follow upstream documentation
<james_w> then Debian changed to follow it too, but also spotted some places where upstream was wrong
<james_w> I think I changed to use Debian's at that point
<pitti> james_w: I think I'll just test it with what Debian currently has
<james_w> upstream/Debian may have changed again
<james_w> yeah :-)
<pitti> and only divert where/if necessary
<pitti> sometimes it shouldn't really matter
<pitti> /var/lib/PolicyKit is 770; we have polkituser:polkituser, Debian has root:polkituser
<tkamppeter> persia, yes.
<tkamppeter> There are also future plans to move these filters into CUPS.
<persia> tkamppeter: In that case, just use that tarball as a single source package for now.  It can be dropped when the filters reach CUPS (unless you think they will get there soon enough that you want to patch them into CUPS in advance)
<tkamppeter> So the package which I will make will probably soon disappear again.
<tkamppeter> persia, I could aldo add them to CUPS directly, as they will go there anyway. I have also two other supposed to go into CUPS: texttopdf and pdftoijs.
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<pitti> tkamppeter: if upstream will eventually merge them, then feel free to add them as patches to the cups package, yes
<tkamppeter> pitti, WDYT about putting all the new PDF CUPS filters into CUPS directly to save the effort of introducing new packages which will disappear again one release later
<tkamppeter> pitti, then I will do so, I will do it in the SVN, so both Debian and Ubuntu get covered.
<pitti> right, please
<tkamppeter> So all 6 new filters will be added there: imagetopdf, texttopdf, pdftopdf, pdftoopvp, pdftoraster, and pdftoijs.
<pitti> james_w: ah, debian bug 482064, that's enlightening
<ubottu> Debian bug 482064 in policykit "policykit: some files have different permissions from those" [Normal,Closed] http://bugs.debian.org/482064
<james_w> pitti: indeed
<metellius> im working on a bug on ark/kde which is caused by libzip on ubuntu not compiled with -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64. how can I confirm this after downloading the package source with apt-get source?
<metellius> in other words, where are the compile directives usually located in the package layout?
<geser> check debian/rules or the Makefiles
<Riddell> metellius: you can also look at the build log http://launchpadlibrarian.net/10324575/buildlog_ubuntu-hardy-i386.libzip_0.8-1_FULLYBUILT.txt.gz
<pitti> mvo: do you think there's any chance to verify the current update-manager bugs in hardy-proposed? many of them are quite special, pwoerpc, sparc, etc.
<pitti> mvo: since the upgrade still works in general, we could copy it to -updates, and close the bugs with a comment to reopen them if it's still not fixed?
<pitti> (at this point I'm more eager to actually get the thing into -updates and do regression testing than to reproduce all the bugs)
 * pitti throws hatred at the hppa buildds
<pitti> cprov-out: any chance to teach copy-package.py "screw hppa"? this really starts to become annoying and blocking SRUs
<pitti> cprov-out: or, at least give -proposed uploads a much higher build score by default?
<mvo> pitti: I'm ok with that approach
<pitti> mvo: argh, still can't copy. hppa. /me bumps build score
<pitti> lamont, infinity_: the hppa buildds seem stuck on setting up a chroot for 11 hours now; can you please have a look?
<davmor2> Guys I'm smoketesting iso at the moment and Alternative comes up with the following message:
<davmor2> No kernel modules were found.  This probably is due to a mismatch between the kernel used by this version of the installer and the kernel version available in the archive.............
<pitti> davmor2: known; cjwatson updated d-i for the current kernel this morning
<davmor2> pitti: cool :)  Thought it might of been some how :)
<cjwatson> it got stuck on brltty-udeb having wrong dependencies; I fixed that but it failed to build due to a gcc-4.3 bug which doko independently (I think) fixed
<cjwatson> so I retried brltty this morning and once that hits the archive I can retry d-i
<cjwatson> I'm working on a cdimage change at the moment to fail CD builds when this sort of thing happens
<doko> yes, the ICE should be fixed in -8ubuntu3
<cjwatson> it is, I tested that
<cjwatson> at least brltty's instance of it
<DRebellion> slangasek, Riddell, apachelogger, vorian, monkeystudio is in REVU. This version uses the Qt Designer and QScintilla packages from the intrepid repositories. http://revu.ubuntuwire.com/details.py?package=monkeystudio
<tjaalton> mdz: ping? I'll have a new xserver for you to test shortly
<mdz> tjaalton: I'm here, but I'm on a different computer today
<tjaalton> mdz: ah, too bad
<tjaalton> I'll upload it anyway, should be better than the previous one
 * pitti sighs at error: ignoring return value of âwriteâ, declared with attribute warn_unused_result
<pitti> doko: ^ that seems excessively picky to me...
<doko> pitti: without any options?
<pitti> doko: with -Werror (upstream guile-1.8 uses that)
<pitti> I just never saw that before, it seems to be fairly recent? guile-1.8 doesn't FTBFS like that in Debian (last upload some days ago)
<james_w> https://wiki.ubuntu.com/CompilerFlags
<mdz> tjaalton: I've reproduced the problem on another system, and there, setxkbmap fixed it
<james_w> it's -D_FORTIFY_SOURCE=2 being default now I believe
<pitti> FORTIFY_SOURCE enables that warn_unused_result write() attribute? that might be it
<doko> pitti: it's the fortify "crack", blame kees ;-p
<doko> pitti: see /usr/include/sys/cdefs.h
<pitti> doko: indeed, there it is; thanks for the pointer!
<mdz> asac: I'm trying to test out auto GSM in network manager but having some trouble
<mdz> asac: the first time, it asked for the SIM PIN (which I gave) then failed with: Aug  6 12:20:40 perseus NetworkManager: <WARN>  automatic_registration_response(): Automatic registration failed: not registered and not searching.
<tkamppeter> pitti, I have added the new filter's source code to the CUPS SVN now, and due to binary files (icons, japanese READMEs) in it debuild cannot build the source package.
<mdz> asac: on subsequent attempts, it fails with: Aug  6 12:21:14 perseus NetworkManager: <WARN>  check_pin_done(): PIN checking timed out
<tkamppeter> Is there any possibility to have binaries in the debian/ directory?
<pitti> tkamppeter: icons?
<pitti> tkamppeter: I thought you'd just add six .c files
<pitti> tkamppeter: if every filter comes with 20 accompanying files, we should rather package them separately
<tkamppeter> pitti, I think they will not be used by the compilation.
<tkamppeter> The installed CUPS will only have arround 10 non-doc files more, 5 filters and 5 conversion rule files.
<pitti> tkamppeter: possibility 1: throw them out, possibility 2: uuencode them, and uudecode them on build (but that would make the build system unnecessarily complex)
<tkamppeter> pitti, I think I can opt for (1), japanese READMEs are only doc and English translations exist and the icons will not get used by the package build-
<mpt> mvo, hi, did you see the PackageMaintainednessPresentation updates?
<mdz> asac: sending AT+CPIN? to the modem elicits an immediate response: +CPIN: PH-NET PIN
<mdz> asac: but PH-NET PIN isn't in         char *responses[] = { "READY", "SIM PIN", "SIM PUK", "ERROR", "ERR", NULL };
<pitti> argh, guile-1.8 hates me; now it complains about undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'
<pitti> that sounds libtoolish, did someone happen to see this before?
<mvo> mpt: reading it now
<mpt> ok
<mvo> mpt: I will do corrections inline, ok?
<mpt> mvo, sure
<mdz> mvo: is there a way to use apt-get build-dep which would mark all of the packages as automatically installed, to make it easier to clean up after?
<mvo> mdz: not currently, but it should be straightforward to add I think. let me have a look
<mpt> mvo, from apt-get's man page it doesn't seem to have any equivalent to aptitude show. Is that true?
<mvo> mpt: the command in apt is "apt-cache show"
<mpt> ah
<mdz> mvo: I always copy/paste into a text file and then remove later, but it seems like a logical feature
<mdz> a config option to mark all newly installed packages as automatic for the current operation would do it
<mvo> mpt: the wiki hates me, I did a smallish typo fix and it answered with a zero size reply (and a squid error)
<mvo> mdz: right
<pitti> mdz: heh, I do the same
<mpt> mvo, want to use gobby instead?
<mdz> asac: also, init.d/NetworkManager restart seems to fail often as it isn't finished shutting down yet when it tries to start again
<DktrKranz> pitti, maybe https://bugs.gentoo.org/show_bug.cgi?id=220339 could help
<ubottu> bugs.gentoo.org bug 220339 in Development "guile-1.8.4-r1 fails to compile with libtool-2.2.4" [Normal,Resolved: duplicate]
<mvo> mpt: it seems to be good again
<pitti> DktrKranz: awesome, thanks
<mpt> mvo, finished?
<cjwatson> pitti: write()> if the fd is non-blocking then failing to check the return value of write() is definitely a very bad bug and will cause problems
<cjwatson> pitti: even if not, it's worth fixing - usually indicates a bug
<asac> mdz: could you add your hardware/provider to the table at https://wiki.ubuntu.com/NetworkManager/Hardware/3G and maybe file a bug with the info you gave above?
<cjwatson> pitti: you can always (void) it if it's really throwaway
<pitti> cjwatson: well, all of those could be wrapped into an assert()
<asac> mdz: please also attach the lshal output
<cjwatson> assert usually isn't the right response to write returning something unexpected
<cjwatson> most of the time bugs are caused by failure to detect short writes
<cjwatson> and the correct response to that is to retry with the remaining data
<mvo> mpt: yes, thanks for your changes. you talked with sg about it, right ? I remember the discussions about the right terminology (supported vs maintained)
<james_w> mvo: bug 248268 if you are going to implement the build-dep thing
<ubottu> Launchpad bug 248268 in apt "Packages installed with apt-get build-dep should be set to auto-installed for easy removal" [Wishlist,Triaged] https://launchpad.net/bugs/248268
<mdz> asac: apparently, PH-NET (for some devices at least) means "The module has been banned from the network"
<mpt> mvo, yes, with sg and mdz
<mvo> james_w: aha, thanks!
<cjwatson> gnulib has a full_write wrapper that deals with this, and lots of other projects have something similar
<mvo> mpt: I think that clarifies it a lot
<cjwatson> honestly, I think that any project that uses -Werror actively wants to know about this sort of thing
<pitti> I'll file an upstream bug anyway
<asac> kees: you remember libc fails with fortify source 2 in realpath?
<asac> kees: redhat guy said to me that they dont have any issue with it :/
<cjwatson> although there are some exceptions (clueless upstreams who just go "ooh, bondage and domination"), the cases I've seen where upstream uses -Werror are usually those with very pedantic and careful upstreams who appreciate hearing about this kind of bug
<james_w> mdz: I use http://paste.ubuntu.com/34717/ to install them from an unpacked source package
<james_w> I should add a mode to install them for a particular package from the apt-cache output
<mdz> asac: added; I don't know the model number and it isn't in lsusb's database, so I'm not sure if it's the same as one you already have
<mvo> james_w: gdebi debian/control should install them as well
<mdz> james_w: handy
<james_w> mvo: ah cool, thanks
<soren> cjwatson: You wouldn't happen to be subscribed to the parted mailing lists, would you?
<soren> I sent a couple of patches there yesterday that I'd appreciate some feedback on..
<james_w> the advantage of that script is that they are installed automatically, and so will be removed with that package, and you can keep them installed for as long as you like
<cjwatson> soren: IIRC I'm on parted-devel although I don't read it often
<cjwatson> I'm not an upstream committer or anything, just a very occasional contributor
<soren> cjwatson: Oh, ok.
<soren> cjwatson: I somehow thought you were a bit more involved.
<asac> mdz: have you tried to manually setup your gsm connection in connection editor?
<asac> maybe you need to explicity set your APN or something
<mdz> asac: I haven't, no. I'll try that now
<cjwatson> soren: I followed up to your second patch with a query though
<asac> mdz: in my blog someone gave the following info: http://paste.ubuntu.com/34724/
<soren> cjwatson: Cool. Thanks.
<cjwatson> soren: your first patch should definitely be && (RW_MODE & O_DIRECT) at least, with the parentheses; the precedence order of & is often confusing and while it's correct in your case most people find parens around & to be worthwhile
<mvo> mdz: do you think that the "auto" flag should be defualt for apt-get build-dep or should I add "--build-dep-automatic" or a option like this?
<cjwatson> soren: and why the rw_mode and rd_mode temporaries?
<Mithrandir> "/ and * before + and -, add parentheses aroud everything else". :-)
<geser> tkamppeter: Hi, do you have an idea why I can only print portrait with intrepid and no landscape?
<soren> cjwatson: I tried all sort of trickery to get RD_MODE & ~O_DIRECT to give me the correct result, but I couldn't (no matter how many "(int)" I tossed into the expression :) ).
<mdz> asac: it looks like my device may be locked and require an unlock code
<soren> cjwatson: Hmm... (int) (RW_MODE & ~O_DIRECT)  seems to do the trick.
<soren> I could have sworn (in fact, I probably did multiple times) that that was the first thing I tried.
<mvo> mdz: added
<soren> cjwatson: Oh...
<soren> cjwatson: nm, I'll follow up on the ml.
<DktrKranz> kirkland, a lsb SRU could be needed to fix bug 252686 (taken from debian 478871). Do you see any regression risks to justify a workaround in nagios2 instead?
<ubottu> Launchpad bug 252686 in nagios2 "Reload action on init script kills daemon" [Medium,Confirmed] https://launchpad.net/bugs/252686
<ubottu> Debian bug 478871 in lsb-base "lsb-base: killproc stops a process if a signal number is provided" [Important,Closed] http://bugs.debian.org/478871
<mdz> asac: filed bug 255304
<ubottu> Launchpad bug 255304 in network-manager "Unable to connect using Sierra MC8775 GSM device" [Undecided,New] https://launchpad.net/bugs/255304
<mdz> asac: creating a connection manually has the same problem
<mdz> mvo: I'm not sure whether it should be default or not
<mdz> mvo: I could easily envision someone wanting to install the build-deps permanently because they are a developer for that software
<mvo> mdz: I set it now to default but with a option to override that
<mdz> mvo: cool, thanks
<mvo> cheers, uploaded
<asac> mdz: network personalisation password ... what could that be? did you ever use that card on windows or something?
<mdz> asac: I have never used it before at all
<mdz> asac: I think it is a provider lock
<asac> mdz: lock == you mean you are trying to use it for a different provider than you initially got it for?
<asac> or initial unlocking?
<asac> for first use
<mdz> asac: the former
<mdz> asac: I bought it in the US and it came with a SIM for a US provider with whom I have no contract
<mdz> asac: I've attached a patch to the bug which properly detects this case and logs an error
<asac> anyway, i think NM should at least implement PH-NET PIN and PH-NET PUK ... and ask the user to type something
<asac> ill check back with upstream on that
<asac> thanks for the initial patch
<mdz> asac: for now I just made it fail, since I don't know the code and can't test anyway
<mdz> asac: P.S. this code sucks
<asac> mdz: NM will switch to modem manager
<asac> instead of its own basic code
<mdz> char *[] in one function followed by a switch statement in a different function is crazy
<asac> usually if Dan Williams writes the code its OK. otherwise you will find gems for sure ;)
<asac> mdz: i assume you tried to just treat it as if it was the "normal" pin?
<asac> ok i think i get that from your bug description
<asac> sounds a bit wierd though that you have a lock that would prevent switching providers if that card is built into your think pad
<mdz> asac: yes, tried the SIM PIN
<mdz> asac: I have a call in to IBM to request an unlock code
<asac> let me know if that turns out to be the right way. my card (external) never asked for anything like that and i think my X61 doesnt have such a modem
<mdz> asac: it seems analogous to a normal mobile phone lock
<mdz> where it's necessary to give the unit a code in order to use it with a provider other than the one it was purchased from
<asac> right. but what interest has IBM to do that? does IBM run their own provider? or have partnered with some?
<mdz> asac: when I purchased the laptop, it came with a SIM card from a certain provider, and the user is expected to sign up for a contract with them
<asac> ok. that makes sense then.
<mdz> asac: I read in a forum post somewhere that IBM could provide the unlock code.  if not, presumably they will pass me on to the next place
<asac> ;)
<Treenaks> yay for SIM locking.. *sigh*
<mdz> I paid for a warranty and will try to get some value from it
<asac> ftp://ftp.software.ibm.com/pc/pccbbs/mobiles_pdf/42x3545_03.pdf
<asac> not sure if the number next to SIM unlock is really the code ;)
<Treenaks> mdz: AT+CLCK=PN,2 should tell you the locking state
<Treenaks> asac: no, that's the FRU (Field Replaceable Unit) code.. the thing you have to order from IBM to get the real code
<mdz> Treenaks: that gives ERROR
<asac> Treenaks: ok
 * asac wonders if one can get a modem back into locked state to properly test the unlocking workflow and user-experience ;)
<asac> shouldnt require much testing though
<Chipzz> heh
<Chipzz> does anyone know what this is about?
<Chipzz> http://chipzz.safehex.be/ubuntucola.jpg
<Chipzz> :)
<Pici> I'd hate to see the bug reports for that.
<cjwatson> old news :)
<cjwatson> http://en.wikipedia.org/wiki/Ubuntu_Cola
<Chipzz> received that picture in my mail; apparently it's being distributed here in Antwerps :)
<cjwatson> obviously yay for fairtrade
<tjaalton> damn, should've bought a can or two from sweden :)
<mdz> three IBM techs later, they say they can't unlock it for me
<YokoZar> so latest intrepid 32 bit doesn't log in in vmware even after removing the snd-pcsp module
<Chipzz> tjaalton: do you just want the can or also what's inside it?
<tjaalton> Chipzz: heh, would be an expensive can if shipped here :)
<Chipzz> tjaalton: if you just want the can, and are coming to FOSDEM in 2009, I could try to save an empty can for you
<tjaalton> Chipzz: ah, probably not, but maybe I'll visit sweden again before too long :)
<Chipzz> <plug mode=shameless>You should really come to FOSDEM though</plug> ;)
<Chipzz> </offtopic>
<seb128> sjoerd, slomo_: do you know why freedesktop-sound-theme is not in debian? the package is available in git apparently (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486559)
<ubottu> Debian bug 486559 in wnpp "ITP: freedesktop-sound-theme -- default fallback theme for freedesktop.org sound themes" [Wishlist,Open]
<sjoerd> seb128: some licensing issues iirc
<sjoerd> slomo should know the details
<seb128> sjoerd: ok, thanks
<mpt> mvo, how are updates to multiverse packages managed? Who looks after them?
<mpt> and for how long?
<wgrant> Same as universe.
<wgrant> MOTU.
<mpt> ok
<wgrant> And for as long as we can be bothered.
<ScottK> Although typically at a lower priority.
<mpt> naturally
<ScottK> AFAIK most MOTU aren't really excited about expending effort maintaining non-free stuff.
<wgrant> multiverse has a fair bit of Free stuff though. That gets enough attention.
<mpt> Do MOTU updates for a release peter out gradually, or do they roughly follow the Main/Restricted lifecycle?
<wgrant> Non-security updates for all components naturally disappear after a few months.
<mpt> thanks for the info
<mpt> (this is about presenting who updates a particular package, and for how long, in the package management tools)
<wgrant> Aha.
<wgrant> With universe and multiverse there are no guarantees. Security support is particularly nonexistent, as it depends on a couple of us constructing updates, waiting for some weeks for somebody to upload them, etc.
<wgrant> Why does it need to be exposed? For main/restricted sure, but there's little point for others.
<mpt> well
<mpt> There are some organizations who want to use only packages that they can rely on updates for, for X period
<wgrant> Of course.
<mpt> So presenting that is easy enough
<ScottK> mpt: If it creates an opportunity for other entities to express their support offers, then I could see it being very useful.
<wgrant> Documentation everywhere specifies that that is main.
<ScottK> Except not everything in Main is supported and not for the same period.
<ScottK> Where supported means "covered by Canonical support contract".
<wgrant> Support seems to be undefined except for security.
<mpt> Sure, but (a) spelling it out is easier than saying "Main" and then having to define "Main" separately, and (b) if ArchiveReorganization is implemented "Main" won't be a separate entity but these packages will still be a distinct category.
<ScottK> Before you expose support status, I'd suggest we have a plan for accurately describing what is supported.
<ScottK> We don't have that today.
<ScottK> Adding U/I to expose wrong data is not progress.
<mpt> Sure, that's part of the spec too, but not my part :-)
<mpt> The hard parts, so far, are conveying (1) what Restricted means and (2) how long people can expect updates for the packages (that are currently) in universe/multiverse.
<wgrant> (2) is 0.
<mpt> fair enough
<mpt> So any update is abonus
<mpt> a bonus, rather
<ScottK> It varies widely.  Some packages are maintained as well, if not better, than many in Main.  Most, not at all.
<wgrant> Right
<ScottK> I'd suggest describe them as "Community Supported" and then provide an explanation of what that means.
<mpt> We're trying to distinguish "supported" (someone is on the end of a phone or mailbox) from "maintained" (someone provides updates)
<mpt> we haven't done that well so far
<ScottK> Makes sense.
<ScottK> mpt: I think making the scheme extensible to allow something beyond supported == Canonical support contract is a key part of this.
<mpt> yes indeed
<mpt> other organizations may offer support too
<mpt> but that doesn't mean that they provide updated versions either
<ScottK> Right.  I think the support/maintain distinction is useful.
 * ogra finds that funny, i always thought supported means maintained by ubuntu-core-dev first place ... 
<ogra> totally independent of a company
<ScottK> I think the term is currently overloaded.
<ogra> because you overload it with political stuff
<ScottK> Not just me.
<BUGabundo_work1> pitti: hi
<pitti> hi BUGabundo_work1
<BUGabundo_work1> any reports of trouble with jockey-gtk from yesterday updates?
<BUGabundo_work1> pitti:  any reports of trouble with jockey-gtk from yesterday updates?
<pitti> BUGabundo_work1: hm, I didn't upload jockey yesterday
<pitti> I didn't hear about troubles, but I didn't read jockey bugmail for some time
<BUGabundo_work1> let me just restart X so tseliot can help me get more then 800x600
<dholbach> pitti: Quotes Page! :)
<BUGabundo_work1> and I'll post the cli output of jockey pitti
<pitti> usually people bug me on IRC/email soon enough :)
<BUGabundo_work1> eheh
<pitti> BUGabundo_work1: what's wrong for you?
<BUGabundo> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct
<BUGabundo> the all PC is slow to a crawl.... lousy graphics
<pitti> weird
<BUGabundo> can't open jockey to get nvidia working
<BUGabundo> etc
<BUGabundo> be right back
<BUGabundo> x restart
<pitti> BUGabundo: is that the complete output?
<BUGabundo> nops
<BUGabundo> just the last 2 lines
<BUGabundo> long trace for a 800x600 window and sluggist pc
<BUGabundo> I'll put it on pastebin
<pitti> BUGabundo: is your computer sluggish right from the start, or does that get worse over time?
<BUGabundo> after GDM
<pitti> I'm asking because I have the same problem, unless I boot with pci=nomsi
<pitti> oh, hm
<BUGabundo> constant slowness
<dholbach> mvo: trying the sandbox-test-upgrade again
<mvo> dholbach: thanks!
 * mvo hugs dholbach
 * dholbach hugs mvo back
<BUGabundo> pitti: http://pastebin.ubuntu.com/34767/
<BUGabundo> ohh so much love in this # :p
<ember> pitti: that sluggish over time happens when you are compiling stuff?
<BUGabundo_work1> nops pitti
<ember> and gets worse?
<BUGabundo_work1> just reboot so I could test the new inetboot
<BUGabundo_work1> and after I log the error I went to regular boot
<pitti> BUGabundo_work1: what does "ls -l /usr/share/jockey/jockey-backend" show?
<BUGabundo_work1> got stuck on low graphics mode
<BUGabundo_work1> and when I tried to start jockey it wouldn't
<BUGabundo_work1> so I tried it from cli
<BUGabundo_work1> just a sec... starting x at 800x600
<BUGabundo_work1> need to get logs to tseliote
<pitti> ember: if you are interested, I put a detailled analysis into bug 253089
<ubottu> Launchpad bug 253089 in linux "[intrepid] becomes unresponsive after some time; unexpected IRQ trap? (Dell Latitude D430)" [Undecided,Confirmed] https://launchpad.net/bugs/253089
<ember> pitti: cool, thanks
<BUGabundo> pitti: $ ls -l /usr/share/jockey/jockey-backend
<BUGabundo> -rwxr-xr-x 1 root root 2.6K 2008-07-23 18:00 /usr/share/jockey/jockey-backend*
<pitti> that looks ok
<BUGabundo_work1> let me get a full list of updates
<BUGabundo_work1> maybe there's something else
<pitti> BUGabundo_work1: ls -l /lib/dbus-1.0/dbus-daemon-launch-helper
<BUGabundo_work1> humm there a couple on DBUS
<BUGabundo_work1> is seb128 here?
<BUGabundo> pitti: -rwxr-xr-x 1 root root 47K 2008-08-05 17:49 /lib/dbus-1.0/dbus-daemon-launch-helper*
<pitti> BUGabundo_work1: that's the only related suid root helper I'm aware of; maybe its permissions are wrong
<pitti> BUGabundo: bingo!
<seb128> BUGabundo_work1: no context ping = no reply
<BUGabundo_work1> i0m having lots of permitions probs
<BUGabundo_work1> last week I lost / to 600
<StevenK> Ah. The ia64 and hppa buildds have been KDE'd
<pitti> BUGabundo: it should be 4751, not 755; did you happen to change that manually?
<pitti> StevenK: hppa, too? last time I checked they were stuck on some chroot problem
<BUGabundo_work1> I don't remember changing those permitions pitti
<pitti> and I want my SRUs first!!
<seb128> BUGabundo_work1: I need to restart my session to try updates, what do you need?
<BUGabundo_work1> humm not sure now
<pitti> StevenK: right, hppa still is stuck
<BUGabundo_work1> maybe pitti found it, seb128
<seb128> ok, so restarting, brb
<BUGabundo_work1> trying to get to the original prob on todays updates
<pitti> BUGabundo_work1: I'd do sudp apt-get install --reinstall dbus
<BUGabundo_work1> and since jockey was gosping on DBUS
<pitti> BUGabundo_work1: wait before you do that
<pitti> BUGabundo_work1: dpkg -s dbus | grep Status
<StevenK> pitti: I have this feeling kohnen and primero do not love life at the moment.
<BUGabundo_work1> pitti: didn't return anything
<BUGabundo_work1> I've been sufering from that samba depency prob
<BUGabundo_work1> so I do apt-get -f dist-upgrades
<BUGabundo_work1> do you think it removed dbus? I don't remember seeing it there!
<pitti> BUGabundo_work1: that would be weird; it could be that the new dbus is unpacked, but not configured, or so
<pitti> BUGabundo_work1: does apt-get -f install want to do anything?
<BUGabundo_work1> pitti: see private im, please
<BUGabundo_work1> pitti: https://bugs.edge.launchpad.net/ubuntu/+bug/254434
<ubottu> Launchpad bug 254434 in likewise-open "package libwbclient0 2:3.2.0-4ubuntu3 failed to install/upgrade: trying to overwrite `/usr/lib/libwbclient.so.0', which is also in package likewise-open" [High,In progress]
<geser> pitti: Hi, do you have an idea why I can only print portrait with intrepid and no landscape?
<pitti> tkamppeter: ^ ?
<lukehasnoname> oh, not anymroe
<lukehasnoname> sry wrong window
<pitti> seb128: argh, entering my GPG passphrase 40 times -> painful; do you know whether seahorse upstream even has a solution for bringing back the agent?
<seb128> pitti: http://download.gnome.org/sources/seahorse-plugins/2.23/seahorse-plugins-2.23.6.tar.gz you are welcome to package it, it's on my list for today but still 15 tarballs to go
<pitti> seb128: ah, nice; I'll have a look
<seb128> pitti: should be not too hard to tweak the seahorse packaging to adapt it to this new one
<geser> doesn't seahorse work with the "original" gnupg-agent?
<seb128> pitti: if you do so also add back the xsession script seahorse has in debian or ubuntu has in hardy (the debian version is modified to start only in GNOME so might be better to take this one)
<pitti> seb128: oh, should that become a new source, or be folded into the seahorse source?
<BUGabundo_work1> pitti: seems fixed! thanks
<pitti> \o/
<seb128> pitti: that's a new source, they splitted the source upstream is seahorse and seahorse-plugins
<BUGabundo_work1> pitti: I take that back! still slugish
<BUGabundo_work1> oh wait... that's just mouse...
<BUGabundo_work1> humm it's the damn usb port
<BUGabundo> pitti: https://bugs.edge.launchpad.net/bugs/51054
<ubottu> Launchpad bug 51054 in linux "MS IntelliMouse Optical 1.1A USB stops responding" [Medium,New]
<agy> I will be performing an upgrade of wiki.ubuntu.com from 16h00 (BST). This should take approximately 90 minutes to complete. During this period the wiki will be placed in read-only mode. Please ensure that you have saved any edits before 16h00 (BST).
<pitti> seb128: hm, seems that has furter dependencies: configure: error: libcryptui from seahorse not found.
<pitti> ah, apparently we are missing a seahorse-dev for /usr/lib/libcryptui.so.0.0.0
<seb128> pitti: we don't split it
<seb128> the lib is in seahorse itself though
<seb128> there is no .so though
<seb128> so either we split it or we add the .so and build-depends on seahorse
<dholbach> talking about seahorse, seb128: do you know anything about seahorse-agent in intrepid?
<seb128> dholbach: that's what we are speaking about, read the backlog? ;-)
<seb128> dholbach: it's in seahorse-plugins now than pitti is trying to package
<geser> dholbach: pitti is trying to package it
<dholbach> perfect
<dholbach> thanks a lot
<pitti> I might actually need to postpone that; I thought it'd be a 30 minute job, but it seems to take much more time
 * pitti moves that to Friday, unless someone else beats me to it
<seb128> pitti: I'll do it today but the ugly way
<seb128> ie, not splitting seahorse
<seb128> pitti: do you have some work in progress I can use?
<pitti> seb128: I just downloaded it and ran ./configure
<seb128> ok
<pitti> seb128: we don't need to ship a static lib in seahorse, just the .so symlink and the .h, right?
<BUGabundo> pitti: #ubuntu-server aint as nice as #ubuntu-devel lol no one there will help me with dovecot lol
<pitti> BUGabundo: please file a bug then
<seb128> pitti: the .so, the .h and the .pc
<pitti> right
<seb128> pitti: I guess we should maybe split it ;-)
<Chipzz> BUGabundo: #ubuntu-devel is not a support channel; you can ask support questions on #ubuntu-server, but if no-one answers then no-one is active there I guess
<BUGabundo> I guess Chipzz
<Chipzz> also, you asked 4 minutes ago. patience is a virtue
<BUGabundo> ehehe
<BUGabundo_work1> filling bugs then
<agy> I will start the upgrade of wiki.ubuntu.com in 5 minutes. Please ensure that you have saved any edits as the wiki will be placed in read-only mode.
<BUGabundo> Chipzz: I guess IRC is meant to be a bit faster then email or BTS...
<cjwatson> BUGabundo: however, if you don't get an answer on IRC, the right answer is *not* to go around asking in every IRC channel you can find; use e-mail instead
<BUGabundo> I just asked on #server and #u+1
<slomo_> seb128: license issue (CC < 3.0)
<seb128> slomo_: is that something we care about it ubuntu? ;-)
<Chipzz> BUGabundo: and you did not wait long enough
<agy> I have placed wiki.ubuntu.com in read-only mode. Maintenance should take approximately 90 minutes to complete.
<slomo_> seb128: well, it will only make it impossible to do syncs from debian because there will be no debian package... other than that: no :)
<seb128> slomo_: alright, I'll use the debian packaging and upload to ubuntu then, thanks
<seb128> slomo_: gnome-control-center requires it to enable sound events
<slomo_> great :)
<pitti> tkamppeter: debian/local/filters/pdftoopvp/ has a complete copy of poppler; please revert that, there's no way I'll ever upload that
<tkamppeter> pitti, I am currently building a CUPS package with the new PDF filters. AFAIR CUPS is synced with Debian. WDYT, is it then better that you upload the current SVN trunk to Debian and let Ubuntu sync it or should I upload a -1ubuntuN?
<pitti> tkamppeter: it shuold build against the system poppler library
<pitti> tkamppeter: too bad that it's already in the svn and thus now taking loads of space :(
 * pitti wants uncommit in svn
<tkamppeter> pitti, I have already asked upstream to remove it but I did not get any new version. They say that it is too complicated.
<pitti> tkamppeter: huh? that can't be complicated at all
<pitti> that's why we have libraries for in the first place..
<tkamppeter> Up to now I only succeeded to get rid of the Poppler copies in all the other filters.
<pitti> really? they all copy the poppler source? *headdesk*
<tkamppeter> Should I take out pdftoopvp until upstream fixes that?
<pitti> tkamppeter: either that, or just fix it yourself
<pitti> tkamppeter: but it should be easy, just drop the internal copy and set the -I paths right? it might need some small patches to work against the 0.6 API, but that shouldn't be hard
<tkamppeter> pitti, the upstream developers are people from printer manufacturers who want to get these filters in for their new drivers. These people do not know much about free software development and especially not about distro packaging.
<pitti> tkamppeter: but please avoid commiting huge chunks of code into packaging branches in the future; it just makes the download slow and is never the right answer
<tkamppeter> pitti, for me it seems that they are accessing the Poppler code through private (non-API) interfaces or that they even hacked Poppler itself.
<tkamppeter> pitti, what is the better way to handle this?
<pitti> tkamppeter: can we do without pdftopvp for now? given the number of vulnerabilities in xpdf/poppler that sounds pretty unsupportable
<pitti> tkamppeter: when you asked me, I thought that those filters would be single .c files with a couple of hundred lines, not complete software pacakges
<tkamppeter> pitti, I can take it out and give upstream a last chance to fix. If nothing comes until FF, we ship without pdftoopvp.
<pitti> tkamppeter: if a project comes along with its own build system and dozens of files, it shuold be packaged separately
<pitti> tkamppeter: I mean, can we use other, already existing filters to replace pdftoopvp?
<pitti> tkamppeter: like, using the old postscript route?
<tkamppeter> The two sample PPDs coming with pdftoopvp show both PDF and PostScript paths. So these drivers are made to also work without pdftoopvp. So I think we can leave Intrepid without if we do not get a better version.
<pitti> right
<Adri2000> pitti: could I ask you to accept the amsn gutsy-proposed upload please? it's the same patch as the hardy-proposed upload that got accepted yesterday. it's bug #234722
<ubottu> Launchpad bug 234722 in tkdo "enh: needs a 'tick' command" [Medium,Fix released] https://launchpad.net/bugs/234722
<Adri2000> no, wrong bug
<Adri2000> bug #243722
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,In progress] https://launchpad.net/bugs/243722
<tkamppeter> pitti, the other three filters are relatively small. Only a few C source files
<Adri2000> pitti: if that's needed, I got a second ack from DktrKranz (in #ubuntu-motu)
<pitti> Adri2000: accepted, bug updated; thanks!
<pitti> tkamppeter: as for the upload, I'd upload to debian experimental and sync from there
<Adri2000> thank you pitti :)
<geser> tkamppeter: Hi, do you have an idea why I can only print portrait with intrepid and no landscape?
<tkamppeter> pitti, I get svn: Out of date: '/cupsys/trunk/debian/local/filters/pdftoopvp' in transaction '809-1' when trying to "svn commit" after the removal of pdftoopvp
<pitti> tkamppeter: hm, does svn require to "svn rm" deleted files?
<tkamppeter> I have done "svn delete" and now also "svn rm". It seems that it has only unregistered the files and not deleted them.
<tkamppeter> Now after "rm -rf"ing and the "svn rm"ing the directory again it works.
<tkamppeter> geser, is this generally for all files? Or only for a certain group of files or apps? Seems that there is a general regression in CUPS.
<Adri2000> pitti: could you also accept amsn-data which is in intrepid binary new? someone is complaining in the bug report that amsn is uninstallable in intrepid
<pitti> weird, it shouldn't be uninstallable because of that, unless it's a separate source
<pitti> Adri2000: ah, on -amd64 it would, yes
<kees> pitti: sorry about the pickiness of the FORTIFY stuff.  I figure it only some times gets in the way, and the final result is better code anyway.  :P
<pitti> kees: oh, in the end it's a justified complaint, it just came as a surprise
<pitti> kees: and I wondered why it suddenly popped up; I forgot our different compiler flags
<Adri2000> uh? amsn and amsn-data come from the same source, but amsn depends on amsn-data, so it sounds logical that amsn is uninstallable if amsn-data is not available. no?
<seb128> Adri2000: there is no need to ping arch admin about binary new on IRC, we do those often enough, intrepid users should be able to deal with temporarly uninstallability
<pitti> Adri2000: right, as I said, uninstallable on !i386; looking
<pitti> Adri2000: done
<Adri2000> seb128: yeah but in this case it would be good to be able to verify that the bugfix works in intrepid, as there are srus on their way
<Adri2000> pitti: thanks
<geser> tkamppeter: I tried to print a PDF from within Acrobat Reader and later tried to print into a file and tried to print it then from evince as the generated file look ok in evince
<geser> I just got a page where it tried to print the content in landscape without rotating it: the upper third of the page is empty and the remaining part got the content printed as far as it fitted on the page
<geser> it looks like cups forgets to "rotate" the paper
<seb128> doko: you really don't want to use sync-source, do you? ;-)
<cjwatson> s/sync-source/requestsync/?
<seb128> ups, yes
<slangasek> ahem; who made the alternate CD oversized by 6MB?
<NCommander> slangasek, I didn't even know the alternate CD had seen any chances recently
<doko> seb128: yes, maybe ... I'll look at it at debconf
<slangasek> oh, it was undersized before because it was missing the kernel udebs again, sigh
<NCommander> slangasek, anything I can help to debloat the CD?
<slangasek> make software smaller
 * NCommander would recommend recompressing packages using lzma compression if the onboard dpkg is large enough
<milosz_> is this the right channel for questions about making Ubuntu packages?
 * NCommander was toying around using w-b and buildd to recompress packages like that ...
<NCommander> milosz_, I'd recommend ubuntu-motu
<milosz_> NCommander, ok thanks
<seb128> doko: the good thing when using requestsync is that it writes in the title when the package is in non-free in debian for example so we don't have to go and look at that when doing the syncs
<slangasek> seb128: any reason I shouldn't reupload totem-pl-parser to rebuild against current e-d-s?
<NCommander> slangasek, I figure it would be possible to recompress the CD packages if not the entire archive relatively easily since the deb format is pretty simple
<slangasek> (that'll trim some old e-d-s libs off the alternate CD for us)
<seb128> slangasek: no
<slangasek> NCommander: we don't want to compress everything on the CD with lzma.
<seb128> I've just been too busy to do rebuilds, you are welcome to do those ;-)
<slangasek> seb128: ok :)
<NCommander> slangasek, speed/memory usage I take it?
<slangasek> NCommander: yes
<NCommander> bz2 then ;-)
<slangasek> not enough savings to justify the work
<alex-weej> milosz_: hai :>
<NCommander> slangasek,  its probably enough to get the CD undersize again, although it would still just prolong the issue that if Ubuntu keeps growing, one CD by itself might not be enough for a base system
<milosz_> hey alex-weej !
<NCommander> slangasek, alternatively, selectively recompress some of the larger packages. OpenOffice alone probably could free up quite a bit of space lzma compressed
<slangasek> OpenOffice is already compressed with lzma.
<NCommander> hrm
<NCommander> slangasek, is there some way I can help with this, or shall I leave it in the cd admins
<slangasek> NCommander: the stuff I'm poking at now is to get NBS libraries removed from the CD by rebuilding everything that depends on them; that doesn't require CD admin status, just ubuntu-core-dev status...
<NCommander> NBS?
<slangasek> not built from source
<NCommander> slangasek, it seems hard to believe their are enough NBS's to bloat the CD by that much
<slangasek> NCommander: evolution-data-server, with only two of its libs changing sonames, accounts for .5MB; so I'll be reclaiming that .5MB now. :)
<NCommander> slangasek, you probably got the i386 disk undersize again (it was only over by a little bit)
<slangasek> it's not over at all currently
<NCommander> slangasek, there was an oversized file it on the daily images list
<slangasek> hrm. true, and for some reason that wasn't in the email report
<slangasek> race condition, perhaps
<NCommander> slangasek, it is oversize by less than a megabyte, so it probably is good now
<NCommander> Now you need to find 7.5 more MB to remove ;-)
<slangasek> seb128: hmm, totem-pl-parser seems to FTBFS, using struct stat without including sys/stat.h
<seb128> slangasek: weird
<slangasek> seb128: something else must have been hiding the header include bug before; I'll patch it up, but wanted to let you know
<NCommander> slangasek, probably due to glibc2.8 ..
<seb128> slangasek: http://svn.gnome.org/viewvc/totem-pl-parser/trunk/plparse/totem-pl-parser.c?r1=148&r2=146&pathrev=148, fixed upstream already
<slangasek> ok I'll take that patch then
<slangasek> :-)
<seb128> slangasek: http://download.gnome.org/sources/totem-pl-parser/2.23/totem-pl-parser-2.23.3.tar.gz if you want to do the version update, there is this change and a crasher fix
<seb128> slangasek: should be a dch run and upload ;-)
<slangasek> ok
<seb128> thanks
<DRebellion> slangasek, would you mind taking a look at monkeystudio in REVU to see whether it would now pass the archive admins? The new package uses Qt Designer and QScintilla from the archives.
<cjwatson> NCommander: over the course of four years, we have already taken the majority of easy wins in terms of CD size; what remains tends to require more substantial thought, I'm afraid
<NCommander> cjwatson, I know the pain, at my old job, I had to crush down all our inhouse apps (about 800MB), Office, and get it to fix on the Windows XP CD so they could be all installed in one go
<cjwatson> at the same time, CD size is not our sole goal, and we have to consider longer-term maintainability as well
 * NCommander would consider dropping the compilers off the CD if it really came down to size
<NCommander> Of course, the flipside is if you actually have to compile a kernel module when booted off the CD ...
 * NCommander has done that ...
<cjwatson> size doesn't trump everything
<NCommander> I'm aware of that ;-)
<cjwatson> I mean, obviously it's a hard limit, but we try rather hard not to sacrifice features at its altar when we can avoid it
<agy> Apologies for the slight overrun. I have completed maintenance on wiki.ubuntu.com.
<seb128> mdz: ^
<seb128> (about the wiki)
<slangasek> DRebellion: if you say that it's using the Qt Designer and QScintilla from the archives, then I don't think an additional review pass should be necessary; that was the only problem I saw when I was looking at it before.
<mdz> seb128: thanks
<tkamppeter> geser, pitti, this looks like a problem of the new pdftops filter of CUPS. It needs to be fixed, as apps are changing currently to output PDF instead of PostScript. Can you post an STR on http://www.cups.org/str.php? Thanks.
<slangasek> seb128: uploaded
<seb128> slangasek: thank you
<DRebellion> slangasek, great : )
<DRebellion> slangasek, just need to find some advocates again now
<NCommander> slangasek, how goes the defatting of the CD?
<slangasek> intermittently
<NCommander> slangasek, how much more space do you need to free?
<NCommander> slangasek, is there a reason why four versions of the NVIDIA binary blob driver is included?
<bfields> soren: I've got a bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/227837 with a patch available.  https://wiki.ubuntu.com/Bugs/HowToFix suggests that the next step is to ask here for a developer to do an upload?  And when I asked about this Sunday, stgraber suggested asking you (as the last uploader of that package) after the weekend.
<superm1> NCommander, they support different cards
<ubottu> Launchpad bug 227837 in libvirt "overzealous masquerading affects vm to vm traffic" [Undecided,Confirmed]
<soren> bfields: Looks reasonable enough.
<NCommander> superm1, I thought the NVIDIA driver was an all in one like ATi Catalyst
<soren> bfields: I have a few more things I'd like to to do libvirt in hardy. I'll include that as well.
<broonie> NCommander: It is but they drop older cards from newer drivers.
<superm1> NCommander, that's how it started.  but they started to remove supported cards in releases
<superm1> NCommander, so for the intrepid release there are 4 series' of releases, that support a mixture of cards
<NCommander> ow
<bfields> soren: thanks; how much are the other things?  let me know if there's anything I can do to help.
<NCommander> My laptop has a NVIDIA card but I never installed the blobs
<soren> bfields: You can help test the updated package, when it gets into hardy-proposed.
<mdz> agy: I'm unable to load pages on the wiki; I got a 502 proxy error after a very long wait
<bfields> soren: ok, will do.  (I assume that'll show up as an update to that bug, so if I'm subscribed then i'll get notified when that happens....)
<soren> bfields: Yes, indeed.
<jonh_wendell> hey, seb128
<jonh_wendell> seb128: I just installed 8.10 and I'm getting grub error 15. Do you know how to proceed?
<slangasek> ugh, why has ghostscript grown by a meg and a half?
<slangasek> NCommander: the only change I've made so far is to get rid of the e-d-s libraries, so, "the rest"
<jonh_wendell> slangasek: any clue?
<slangasek> jonh_wendell: no, sorry
<agy> mdz: is this still occuring?
<mdz> agy: yes
<agy> mdz: i'm looking into it
 * ogra wonders how to switch off the annoying horizontal scrolling his touchpad does now in intrepid ... there seems to be no setting in any of the control center applets for it and its really bothering me that my windows switch back and forth all the time if my pointer is over the windowlist 
<ogra> i thought there was a setting in the mouse applet before for that ... but i cant find it
<calc> ooo-langpacks diff is getting bigger every day :) 16942 lines 437203 bytes so far
<agy> mdz: should be better now - give me shout it you see otherwise
<mdz> agy: looks good now
<calc> should be ~ 1.2MB when done
<asac> slangasek: someone asked me about bug 251369
<ubottu> Launchpad bug 251369 in freetype "Please merge freetype 2.3.7-1 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/251369
<asac> since you did the debian upload I wonder if you could take a look
<bfields> The vblade package has a couple bugs (which make the package unusable by default) which have patches available; any suggestions on how to get an updated package uploaded?
<slangasek> asac: hrm, I'm staggeringly unfamiliar with the changes that have been made to the package in Ubuntu; I'd be more comfortable if, e.g., Keybuk looked at it
<bfields> By the way, bug 223387 and bug 223440 are the vblade bugs in question.
<ubottu> Launchpad bug 223387 in vblade "vblade doesn't create /var/run/vblade" [Undecided,Confirmed] https://launchpad.net/bugs/223387
<ubottu> Launchpad bug 223440 in vblade "vblade discovery doesn't work" [Undecided,Confirmed] https://launchpad.net/bugs/223440
<asac> Keybuk: ^^ what do you think about freetype merge?
<ogra> mumble ... asac after a reboot and starting FF i get  FF restart notification ... that wasnt there before reboot
<ogra> (and is pretty silly since i just rebooted)
<asac> ogra: restart notification in the gnome panel?
<ogra> yeah
<ogra> i had a reboot notification after the upgrade ... rebooted and the first thing after starting FF in the fresh session was a popup that FF needs restarting
<ogra> i guess its rather a libnotify issue though
<asac> ogra: I'd say thats an update-notifier issue
<ogra> or that
<slangasek> tkamppeter: the new ghostscript you've uploaded takes up 1.5 MB more of CD space that we didn't have; what can we do to reclaim some of this?
<slangasek> tkamppeter: this appears to be because the ghostscript package includes 1.4MB of fonts that weren't needed before...
<mdz> agy: it's gone pear-shaped again
<mdz> agy: just took over 5 minutes to load a page
<Adri2000> archive admins: last time I bug you for amsn :p : feisty-proposed upload waiting in the queue. (actually last time except if I also do a dapper-proposed upload later :))
<mvo> ogra: oh? ff restart notification? if you can see tihs again at some point, I would like to ask for some debug output
<kirkland> anyone else having trouble with wiki.ubuntu.com?
<NCommander> doko, ping?
<jpds> kirkland: Working fine here.
<NCommander> lool, ping?
<kirkland> jpds: thanks.  it's back up
<jpds> kirkland: (It just went through an upgrade - if you didn't know).
<kirkland> jpds: ah, musta missed that ;-)
<nxvl> kirkland: i thought you were motu for long time :S
<kirkland> nxvl: not yet ;-)
<nxvl> kirkland: yeah, now i know
<nxvl> :P
<NCommander> I'm curious on who is working on the armel port for Ubuntu
<infinity_> NCommander: Many people.
<NCommander> Well, I did some work on bootstrapping armel (built quite a few packages, not enough to run debootstrap to build a fully Ubuntu native port, but it was enough to do stuff in), and I was interested in helping on working on it
<infinity_> NCommander: The bootstrap will, out of necessity have to be done pretty much entirely internally, as we can't readily trust random binaries built by others. :/
<NCommander> infinity_, I'm aware of that
<NCommander> infinity_, but I'd like to do something to help with the port if possible
<ogra> mvo, i doubt i'll get it again now ... and it smells a bit like the reboot notification blocked it
 * NCommander had even setup a dak installation on his local server to handle package management
<lool> NCommander: pong
<infinity_> NCommander: Once our bootstrap is out of the way, the best way anyone can help will be to look at build failures and upload source fixes for anything that's FTBFS on armel.
<NCommander> infinity_, which is what I already do for amd64 ;-)
<NCommander> lool, infinity_ helped me with my armel questions. I was curious if I could help with this effort; I had already done quite a bit of work on bootstrapping the port
<lool> Ok
<NCommander> how close is armel to actually existing as a port?
<infinity_> NCommander: If any of your bootstrapping required fixes, of course, feel free to get those in now, don't wait for us to stumble on the same breakages. :)
<infinity_> NCommander: We're provisioning insanely fast buildd kit as we speak, so it should be a live port pretty soon.
<NCommander> infinity_, well, I had a little trouble bootstrapping the cross-compiler, but the parts of base I built worked fine once I made the cross-compiler build
<lool> We're not cross building
<lool> And I would guess the bootstrap will happen from a Debian armel chroot
<NCommander> I used a cross-compiler just because my armel hardware is SLOW :-)
<NCommander> But yeah, that's extactly what I did
<infinity> Yeah, our armel hardware is... Fast.
<NCommander> armel chroot, and then build packages
<lool> infinity: SATA?
<infinity> Like, really fast.
<NCommander> infinity, freaking 1GHz hardware :-P
<infinity> lool: The machine I last tested was SATA, (on-die, even) and a ridiculously wide memory bus.
<infinity> lool: We're talking, GCC builds in only about twice the time that hppa does 'em.
<lool> twice or half?
<NCommander> o___o;
<lool> Not that twice would be that bad
<infinity> lool: Twice.  But hppa isn't exactly slow.
<NCommander> My armel 244Mhz box took about 7 hours to build the base compiler
<NCommander> I'd wish I could get even close to that speed
<infinity> gcc-4.3_4.3.1-2 -- 572:11 on hppa, 3077:33 on the Debian buildd, 804:29 on the hardware we're looking at.
<lool> Pretty good
<infinity> NCommander: We're talking a full GCC n-stage bootstrap build, with testsuite.
<NCommander> infinity, I know ;-)
<NCommander> infinity, as for the bootloader, packaging redboot wouldn't be too bad, but d-i probably shouldn't install it by default
<lool> Bah usually we don't touch the bootloader
<infinity> NCommander: Yeah, bootloaders are really, really subarch specific on ARM.
<infinity> Moreso than most architectures.
 * NCommander bricked his ARM box trying to change it
<lool> i'm not even sure subarch is specific enough  :-)
<NCommander> My JTAG was so slow it took almost a day just to rewrite a good redboot
<infinity> I imagine d-i will grow a mess of subarch bootloader support in time, but for now, it'll probably be up to the user (or distributor, in most cases) to do that bit.
<lool> I think the redboot on the thecus has special patches for some hardware, and these aren't upstream
<infinity> lool: When I say "subarch" in the ARM sense, I mean SoC, or even SKU.
<NCommander> infinity, on my ARM box, it pretty much works that the kernel and a d-i initrd are loaded by the existing redboot; they don't touch that at all
<NCommander> (the kernel is flashed, but that's mor eout of necessity since rb doesn't know IDE)
<NCommander> infinity, anyway, I didn't run into any major issues building packages, I think I did have a little trouble with build-deps not existing on Debian or needing upgrade, but beyond that, it was pretty smooth
<cjwatson> d-i already has a mess of subarch bootloader support ;-)
<cjwatson> maybe not enough of a mess
<infinity> cjwatson: Yeah.  The mess will grow.
<infinity> cjwatson: Debian's armel support isn't targetting the same systems we will be, for starters.
<NCommander> I'm not sure having d-i manage the bootloader is a good idea
<infinity> cjwatson: (They target systems they can obtain and test on, which kinda makes sense, we'll be targetting new and shiny v7 SoCs and such)
<NCommander> It just seems like a disaster ready to happen
<infinity> NCommander: This is all really about convenience for vendors and distributors who, in the end, are "managing the bootloader".
<infinity> But giving them interfaces to do so without dd isn't always terrible.
<NCommander> infinity, I know on armel, d-i doesn't do anything for the bootloader
<cjwatson> infinity: meh, Debian d-i's embedded arch support is not entirely immune from people's pet systems that don't exist anywhere else
<cjwatson> I believe there was some work there that was done on a commercial basis by other folks
<infinity> cjwatson: It's not nice to take jabs at PegasOS in public.
<cjwatson> NCommander: I definitely don't think it should install the bootloader in most cases, but sometimes it does need to know how to configure it
<cjwatson> infinity: not what I meant :-)
<infinity> cjwatson: I know. :)
<NCommander> cjwatson, with redboot, it might be tricky, just because the boot script is embedded right in the binary ...
<cjwatson> NCommander: in most cases, configuration is about 90% of the job of a bootloader installer udeb
<cjwatson> NCommander: right, it won't always be sane
<infinity> Are any of them sane?
<infinity> Anyhow, bootloader support is a "way off" thing.
<NCommander> Well, the other issue is breaking up the ubuntu system
<cjwatson> NCommander: sometimes the "configuration" might consist of symlinking binaries to the right place in /target
<cjwatson> or whatever
<infinity> For now, we'll be happy to build stuff and have the end-distributor worry about how to get it on the hardware.
<infinity> (Or the end-user, in the case of porters and enthusiasts)
<NCommander> Because we'll probably have a small flash which then loads the rest of the system (my NSLU2 uses a linuxrc script to chroot onto the right HDD)
<cjwatson> can't that just be the Ubuntu initramfs?
<infinity> cjwatson: In most cases, should do.
<NCommander> cjwatson, well, I'm more worried about a case where the system hosed to the point where single user doesn't work
<infinity> These "small flashes" aren't really all that "small" anymore.
<NCommander> Again, on my arm box, I can drop into a real rescue mode which is a busybox based chroot
<NCommander> so if I really destory the debian installation, I can debootstrap again from that busybox chroot
<NCommander> and since booting from an alternate boot device for ARM might be difficult, it might be worth having
<NCommander> Personally, IMHO, a flash map for an ARM based ubuntu distro would look like this
<NCommander> Bootloader | Kernel | Initrd | Rescue parition (read-only) | Main boot parition (if booting from the same flash device; if the device has an HDD, then it should have a chroot in the linuxrc or a proper root= if the boot strings can safely be changed)
<cjwatson> bear in mind that the initramfs *is* a busybox-based chroot
<cjwatson> so the right answer here might be simply to enhance the initramfs to be able to function as a better rescue system for the ARM case
<cjwatson> I think that would be a lot easier to arrange than somehow splitting up the root filesystem into rescue and everything-else
<kirkland> wiki is giving me 500 errors, now
<broonie> ~[6~[6~[6~[6~[6~/win 19
<infinity> NCommander: The other thing to keep in mind here is target audience, where most of these systems, if they explode, will just be reflashed.
<infinity> NCommander: Having fancier rescue scenarios for developer systems might be nice, but that's something people who care deeply about can worry about, while it's not really the target of a flash-based port.
<NCommander> Well, what's the target audience more specifically?
<infinity> NCommander: For the initial port, the target is simply "getting it all built", to be honest.
<infinity> NCommander: In future releases, there will be vendors shipping systems based on our builds, but they'll be worrying about how to get the software on their systems, generally.
<NCommander> infinity, ah. I was just trying to help ;-)
<tkamppeter> slangasek, the release notes of Ghostscript  8.63 did not tell anything about new fonts
<lamont> pitti: fwiw, I'm on vacation until monday - www.denvention.org
<cjwatson> lamont: why am I so not surprised at your committee role? :-)
<lamont> cjwatson: lol
<lamont> fwiw, I insisted that I was doing _NOTHING_ precon, and then got talked into doing that in late June... not really the time to be starting that task
<lamont> at con, I'm pedominantly "hospitality/guest services bitch"
<lamont> mitzi got "post-{masquerade,hugos} bus scheduling" recently enough to not be on the committee list
<infinity> lamont: I would like to procure some freebies.
<lamont> infinity: then come to denver. :-p
<infinity> lamont: Traditionally, you ship freebies to me.  I'm alarmed by this new turn of events.
<lamont> infinity: heh
<NCommander> slangasek, can I ask you some questions about handling debian releases?
<slangasek> tkamppeter: well, there are fonts being shipped in the package in .3 that weren't there in .2; see bug #255485 now
<ubottu> Launchpad bug 255485 in ghostscript "ghostscript has a 300% size increase" [High,Confirmed] https://launchpad.net/bugs/255485
<slangasek> NCommander: that doesn't seem very on-topic here?
<NCommander> slangasek, I meant to /msg it >.<;
<steveacab> could a core-dev/buildd-admin give-back ffmpeg-debian in intrepid? thanks
<cjwatson> steveacab: done
<steveacab> ok, thanks
<Adri2000> any archive admin: feisty and dapper -proposed uploads (the last ones :)) for amsn are in the queue, bug #243722
<ubottu> Launchpad bug 243722 in amsn "amsn 0.97: login doesn't work anymore due to a protocol change" [Medium,In progress] https://launchpad.net/bugs/243722
#ubuntu-devel 2008-08-07
<cjwatson> slangasek: fyi, removing uncompressed Packages files is blocked on bug 255545
<ubottu> Launchpad bug 255545 in apt "requires uncompressed Packages files on CDs" [Undecided,New] https://launchpad.net/bugs/255545
<slangasek> ok
<cjwatson> I knew I'd run into *something* like that before, but had been hoping it was fixed ...
<infinity> cjwatson: That's got to be a pretty quick fix, really...
<cjwatson> I wasn't sure which of the several alternative approaches was best
<slangasek> yes, there's a design decision to be made there
<infinity> cjwatson: Removing from Releases is clearly wrong.  Since apt-cdrom wants to do verification on the fly, I see no reason why it couldn't unzip to /var/lib/apt, just like apt-get does, and verify from there.
<infinity> Pretty much reuse the same code path.
<RAOF> Intrepid seems to take parallel booting a little too far - it appears that the fsck of / or /home gets run in parallel with the rest of the boot sequence, which means I can get to a login prompt with an entirely read-only filesystem which then doesn't work.  This'd be a bug to file against upstart, right?
<james_w> RAOF: I had that, but I didn't realise/think there was an fsck going on
<cjwatson> infinity: you're probably brighter than I am at this time of day, so I'll take your word for it. :-)
<RAOF> james_w: It's easier to notice when it's just /home.  Then you _can_ login, and work out what's happening.
<infinity> cjwatson: Well, I think the fundamental problem here isn't that apt doesn't know how to do this, it's that apt-cdrom and apt don't share enough code. :)
<james_w> as for a bug I'm not sure if it would be upstart or the initscripts
<infinity> cjwatson: s/apt /apt-get /
<infinity> james_w: upstart provides those init scripts.
<infinity> james_w: Oh, I lie.  sysvinit still does.
<james_w> oh, ok, I thought they were in a different package
<cjwatson> infinity: I certainly won't argue with that
<infinity> RAOF: It's likely an initscripts/upstart misinteraction.  In that the latter should probably be using a mechanism to delcare the fsck scripts as blocking, and it's not.  *hand wavy*
<RAOF> infinity: Sounds about handwavey right.
<kirkland> cjwatson: hiya, i have a grub patch, if have any time to look at it
<infinity> RAOF: I'd start with the bug report at initscripts/sysvinit and see where it goes from there.
<RAOF> infinity: Ta.  Will do.
<slangasek> <cough> actually, in London last month, Keybuk argued that we totally should parallelize the fsck with the rest of the startup, to get everyone to the login screen sooner
<slangasek> and force a delay at gdm if necessary
<kirkland> understanding that it is of course probably the middle of the night for you, it can certainly wait ;-)
<slangasek> hmm, it was Keybuk, was it?  or Ted
<TheMuso> slangasek: Keybuk IIRC.
<infinity> slangasek: That works for /home (delaying at GDM), but it so obviously doesn't work for any other mountpoint.
<RAOF> slangasek: Wouldn't that require /tmp to be some sort of ramfs?
<infinity> RAOF: A lot more than /tmp ... /var, for instance.
<slangasek> well, yes, presumably we block on /var :)
<RAOF> Oh, right.  Yes.
<slangasek> I don't know
<cjwatson> kirkland: not really awake any more ...
<kirkland> cjwatson: ;-)  no prob.  ping me at some point tomorrow perhaps and we can discuss
<infinity> slangasek: I suppose the mechanism used for blocking on /home would need to be pretty user-friendly here... Failing to log in is kinda unintuitive and scary.
<slangasek> yes, that was the plan
<slangasek> the user-friendly part, not the scary and unintuitive part
<infinity> *giggle*
<infinity> RAOF: So... This may be a half-implemented "feature", rather than a bug. :)
<infinity> RAOF: OTOH, if you can prove that it's not blocking on /var, you may still have a bug.
<slangasek> still warrants a bug report, though, so we all know what's going on. :)
<infinity> RAOF: If it's only /home, then it might be the above.
<slangasek> (even if it's a half-implemented feature, given the current state of implementation it should be tracked as a release-blocking bug...)
<infinity> RAOF: And, yes, either way, vorlon's right.  A bug report to the effect of "eek, unintuitive and scary, must be user-friendly by release" would be nice.
<RAOF> infinity: I've seen both - unable to GDM login because /home is in the middle of fsck, and unable to login *at all* because / was in the middle of fsck.
<infinity> RAOF: The former is usability, perhaps.  The latter is pretty clearly a big, fat WTF.
<RAOF> Right.
<infinity> My god, could CDBS be any more inefficient.
<infinity> I swear this build has called dh_buildded ON THE SAME BINARY PACKAGE, like 5 times now.
<slangasek> yes, here let me show you
<RAOF> infinity: It could be worse.  It could build twice.
<slangasek> <clickety click>
<infinity> s/buildded/builddeb/
<infinity> slangasek: I still argue that CDBS was Colin's way of sabotaging Debian on his way out.
<calc> anyone else having weird problems with firefox in hardy?
<calc> with it locking up on websites, etc
<infinity> calc: Working great for me.  Perhaps you're surfing the wrong porn?
<slangasek> calc: don't follow any links infinity offers as "test cases"
<calc> infinity: well one of the cases where it isn't working for me is on facebook top friends app (but doesn't crash), and sparkpeople.com doesn't let me add pictures and hangs the browser
 * calc isn't sure if either of them use flash
<infinity> Removing flash is a pretty good way to find out.
<cjwatson> or flashblock
<RAOF> Pair of bugs filed against sysvinit.
 * TheMuso manages to shave 1.1MB off the size of the ubuntu-sounds package by downsampling all files by half.
<ion_> themuso: Iâd prefer encoding them as vorbis instead.
<TheMuso> ion_: The GNOME stuff doesn't yet support that.
<TheMuso> ion_: Only wavs work at this point.
<ion_> themuso: No problem, just decode them in postinst.
<TheMuso> ion_: But ogg is the plan for the future.
<ion_> Shouldnât take too long.
<TheMuso> eeeew
<TheMuso> No thanks.
<TheMuso> That brings in one more dependency on the disk that is really not needed.
<TheMuso> And negates the shrinking in the first place. This is a CD size operation only.
<slangasek> "only"?
<TheMuso> slangasek: Well maybe not only, but it does help, and the quality difference is really not noticable unless you listen carefully.
<slangasek> ok
 * TheMuso hasn't uploaded it yet, just experimenting with sizes of the package depending on what files are shrunk.
 * slangasek nods
<slangasek> did you find that the .wav files were stereo as well?  Was there room for improvement there?
<slangasek> (i.e., drop to mono except in any rare cases where it matters)
<TheMuso> Haven't checked that yet, but I think they are all stereo yes.
<TheMuso> Ok it appears that the startup/logout sounds are stereo, but the others, while stored as stereo, are only mono in actual sound.
<nxvl> if a package need bash for some reason during build time, i need to a) remove the dependency of bash or b) add bash as build-dependency
<nxvl> ?
<StevenK> I thought bash was still Essential: yes?
<StevenK> nxvl: c) Fix it to use SHELL=/bin/bash
<StevenK> nxvl: /bin/sh != /bin/bash doesn't mean it isn't there, just that it isn't the default/
<StevenK> s^/$^.^
<ScottK> nxvl: Better to teach it not to need bash if you can.
<nxvl> StevenK: the problem here is that bash isn't there
<nxvl> StevenK: configure: error: cannot run /bin/bash ../config.sub
<StevenK> nxvl: Then your chroot is broken. The bash package is Essential: yes.
<nxvl> ScottK: yes, but i'm just about to quit on that
<nxvl> ScottK: heh, then the build daemons are broken :D
<nxvl> http://launchpadlibrarian.net/16512924/buildlog_ubuntu-intrepid-i386.php5_5.2.6-2ubuntu1_FAILEDTOBUILD.txt.gz
<StevenK> nxvl: But adding bash as a Build-Depends is pointless.
<nxvl> that's what i thought
<nxvl> :S
<ion_> themuso: A statically linked oggdec would 215 KiB, btw.
<ion_> take
<nxvl> i will keep looking
<nxvl> StevenK: thank you!
<TheMuso> ion_: Its still more work than its worth.
<nxvl> nevermind i found the problem
<nxvl> <- dumbass
<YokoZar> vmware is not working at all for running Intrepid (freezes on login, even with the earlier workaround of modprobe -r snd_pcsp)...what can I use to test/develop on Intrepid?
<ion_> virtualbox
<TheMuso> 5~/c
<warren> Can anybody running Ubuntu help me compare something to Fedora?
<warren> in your "man su" do you have this option:
<warren>        -m, --preserve-environment
<warren>               do not reset environment variables
<StevenK>        -m, -p, --preserve-environment
<StevenK>            Preserve the current environment.
<warren> hmm
<warren> thanks
<macho> will any help me
<macho> any 1
<RAOF> macho: Probably not in here; is your problem related to the development _of_ Ubuntu?
<macho> no where can i get help to add ubuntu ps3
<RAOF> #ubuntu would be the right channel.
<macho> maybe you guy can help ps3 ower
<RAOF> Ubuntuforums would also likely be a good spot.
<macho> thank raof
<macho> btw what you guys work on
<pwnguin> "I am the tech lead for Goobuntu, Google's in-house derivative of Ubuntu, used as an Engineering desktop amongst other things."
<pwnguin> https://wiki.ubuntu.com/AndrewPollock2
<pwnguin> i thought goobuntu didnt exist
<lifeless> pwnguin: it exists
<pitti> Good morning
<pitti> lamont: oh, enjoy!
<StevenK> Morning pitti
<nxvl> morning pitti
<dholbach> good morning
 * dholbach has to get used to the new wiki syntax
<nxvl> dholbach: it has changed?
<dholbach> moin was updated on wiki.u.c yesterday
 * nxvl checks
<nxvl> oh! that's why i've been having some issues with the wiki today
<persia> The new interface is confusing, the new syntax a bit odd, the need to refresh cookies annoying, and the installed code likely significantly more flexible and secure.
<nxvl> i don't feel the difference :S
<persia> nxvl: Edit a page.  Click the buttons at the bottom of the editing frame.
 * nxvl clicks
<nxvl> moin is slow
 * nxvl loves doku
<nxvl> wait
<nxvl> save wasn't down?
<nxvl> as in at the bottom
<persia> It was, it's up now.  Still works, just an example of the difference :p
<nxvl> that's definitely uncomfortable
<persia> The only part I find odd is that the comment is not near the preview/save buttons.
<slangasek> hmm, "libcanberra"?
<RAOF> Australia's where it's at.
<persia> An entirely new view of desktop events, neatly constructed between the primary existing places, and intended to supercede them, yet without the natural resources to do so without external assistance.
<persia> (at least if XDG can be said to be between KDE and GNOME, rather than a bit south)
<RAOF> persia: Is that a quote on the libcanberra naming?
<persia> RAOF: Only if it gets repeated
<RAOF> 'cause it's a pretty good description of the city :)
<TheMuso> RAOF: lol you are so right!
<TheMuso> slangasek: But its supposed to be the new library for sound events in GNOME/Desktop applications.
<slangasek> why did we need a new one? :)
<RAOF> With a passing nod to KDE, too.
<RAOF> slangasek: We had an old one? :)
<persia> http://0pointer.de/blog/projects/sixfold-announcement.html
<TheMuso> The current sound events system in GNOME is kinda sucky.
<persia> s/kinda/rather/
<RAOF> The KDE default sound theme isn't crash-hot, either.  I'm not a big fan of having a "bing!" every time I press a button.
<slangasek> persia: ah, ok then :)
<slangasek> RAOF: computers that "bing!" are an attempt at operant conditioning to see if I'll murder someone, I think
<RAOF> slangasek: Someone's going to broadcast a "bing!" in a public place to trigger your programming?
<slangasek> I'll have the perfect alibi
<slangasek> s/alibi/defense/, perhaps :)
<pitti> zul: did you see the php5 FTBFS?
<StevenK> pitti: Did you see that it was due to bash? :-)
<StevenK> Or autotools
<pitti> yeah, looked quite weird
<StevenK> pitti: If the hppa and ia64 buildds could actually keep up, I'd have a few packages for you to NBS out.
<pitti> StevenK: ia64 is down to 24 builds
<pitti> should manage until I attack NBS tomorrow
<pitti> for now I just had a quick look at http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_outdate.txt
<pitti> StevenK: hppa-only rdeps don't stop me from NBSing packages
<Hobbsee> hey pitti
<StevenK> pitti: Ah. There's a few :-)
<pitti> StevenK: you can still check for unsatisfieable dependencies with apt, so if someone is actually willing to fix hppa, he can still do so
<pitti> "apt-cache unmet" ftw :)
<pitti> hey Hobbsee
<StevenK> pitti: Well, usually the fix is uploaded, but hppa hasn't built it yet
<StevenK> And that is true for the 13 or so uploads I did last night
<slangasek> StevenK: the php5 ftbfs is linked to the new libtool...
<StevenK> slangasek: Fun.
 * pitti looks at the time FTBFS and wonders...
<StevenK> Where's Keybuk, so we can belt him ...
<pitti> Package automaken is a virtual package provided by:
<pitti>   automake1.9 1.9.6+nogfdl-3ubuntu1
<pitti>   automake1.7 1.7.9-9
<pitti>   automake 1:1.10.1-3
<pitti> Using automake1.8 (selected in sbuildrc)
<pitti> infinity, cprov: ^ any idea why it picks the very alternative which does not even exist?
<StevenK> Woo!
<pitti> infinity: is the "selected in sbuildrc" actually true, and this file needs an update to just point to "automake"?
<YokoZar> pitti: was there a kernel recently (namey -20) that was in proposed but didn't go into -updates?  It seems like virtualbox-ose-modules-generic depends on a -20 version but there is no -20 kernel (thus making the -20 virtualbox-ose-modules uninstallable)
<pitti> YokoZar: right, that -updates move was an accident
<pitti> we need to reupload -19 into hardy-updates
<YokoZar> Fair enough
<YokoZar> Now I just need to figure out how to actually get Intrepid to boot in virtualbox (still freezes in vmware for me at login, even after removing the snd_pcsp module)
<YokoZar> slangasek: not to pester, but is there anyway these critical bugs in the virtualization programs could be given some sort of higher priority?  Not having Intrepid work in vmware or virtualbox has been preventing me from doing substantial amounts of work on my package.  There are other things I can do in the meantime, but it does seem like it's a blocker of sorts.
<slangasek> YokoZar: I'm not on the kernel team, there's not a whole lot that I can do personally to move them along; they've already been flagged as high-priority issues to the kernel team.
<TheMuso> YokoZar: What about a chroot?
<YokoZar> slangasek: Well thank you, in any case :)  That seems to be the best thing to do.
<YokoZar> TheMuso: That and pbuilder, basically.
<lifeless> mvo: hi
<mvo> hey lifeless
<pitti> hi sabdfl
 * pitti waves to mvo
<pitti> mvo: compiz-fusion-plugins-main wants to pull in compiz-bcop; do we want that in main, or was that an error?
<pitti> (it's in dep-wait)
<mvo> pitti: let me check
<mvo> pitti: isn't that in main since gutsy? compiz-bcop. there is also a compiz-fusion-bcop that we got from debian (they decided to package it with a different name). might be a good time now to actually use the debian one and get rid of ours
<pitti> mvo: oh, hang on, compiz-bcop doesn't even exist in hardy any more
<pitti> mvo: right, so that needs a fixed build dependency
<pitti> mvo: I'll promote compiz-fusion-bcop
<pitti> done
<pitti> s/exist in hardy/exist in intrepid/
<mvo> pitti: aha, good. now I just need to fix the compiz packages
 * mvo goes and does it
<pitti> mvo: thanks
<lifeless> mvo: what was the findconflicts outcome ?
<mvo> lifeless: its a bit strange, it hasn't spamed^Wmailed me anymore, either its fixed now or so broken that its not even crying anymore
<lifeless> mvo: the code is out btw
<mvo> lifeless: excellent, congrats!
<mvo> I saw the mail this morning
<lifeless> mvo: future changes please shove up a branch and use the lp merge request stuff
<lifeless> so that I can pull them into trunk
<mvo> lifeless: ok, will do
<lifeless> [this is separate from getting it onto macaroni - keep doing that as you ar]
<lifeless> *are*
<lifeless> mvo: should I create a conflictchecker team ?
<mvo> lifeless: sounds like a good idea to me (or conflictchecker-hackers or so)
<lifeless> k will do
<RAOF> seb128: Re bug #255621 - xdg-open was detecting a gnome environment by GNOME_DESKTOP_SESSION_ID, which seems to be no longer set by gnome-session.  For me, it seems DESKTOP_SESSION=gnome is being set; is this a safe thing to check for?
<ubottu> Launchpad bug 255621 in xdg-utils "xdg-open's Gnome detection is broken" [Medium,Confirmed] https://launchpad.net/bugs/255621
<seb128> RAOF: http://bugzilla.gnome.org/show_bug.cgi?id=542880
<ubottu> Gnome bug 542880 in gnome-session "GNOME_DESKTOP_SESSION_ID not set anymore" [Normal,Unconfirmed]
<RAOF> Aha.  You're obviously on top of that, then.
<seb128> is there any known issue with the new nvidia binary drivers?
<seb128> bug #255461 states that gnome-panel crashes when using "177"
<ubottu> Launchpad bug 255461 in gnome-panel "gnome-panel crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Incomplete] https://launchpad.net/bugs/255461
<seb128> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-applets/+bug/255573, is there any reason apport doesn't remove the coredump when marking duplicates?
<ubottu> seb128: Error: This bug is private
<RAOF> seb128: 255461 isn't a general crash; I'm using nvidia-glx-177, and gnome panel works just fine.
<pitti> seb128: that sounds like a bug
<seb128> pitti: same on https://bugs.edge.launchpad.net/ubuntu/+source/gnome-applets/+bug/255572
<ubottu> seb128: Error: This bug is private
<soren> Has MoM been switched off or is she malfunctioning?
<mvo> seb128: same for me
<mvo> soren: might be malfunctioning, I can have a look
<seb128> mvo: works or doesn't work for you?
<mvo> seb128: sorry, work for me with -177
<soren> mvo: Cool. Last update seems to have been on August 1st.
<seb128> mvo: ok, thanks
<pitti> seb128: hm, it's also supposed to remove the private tag
<mvo> soren: yep, mom is unhappy, I will see what I can do about it
<seb128> mvo, pitti: http://bugzilla.gnome.org/show_bug.cgi?id=545828, if you could comment to say what you think about the feature, if it does what we need and if you think we would use that rather than update-notifier
<pitti> seb128: the code is there
<ubottu> Gnome bug 545828 in plugins "Add apport monitoring" [Enhancement,Unconfirmed]
<pitti> seb128: sure, will do
<seb128> pitti: ok, should I open a bug about the duplicate issue?
<pitti> seb128: if you want, but I'm investigating it right now
<pitti> thekorn: I am using this:
<pitti>         bug.attachments.remove(
<pitti>             func=lambda a: re.match('^(CoreDump.gz$|Stacktrace.txt|ThreadStacktrace.txt|\
<pitti> Dependencies.txt$|ProcMaps.txt$|ProcStatus.txt$|Registers.txt$|\
<pitti> Disassembly.txt$)', a.lp_filename))
<seb128> pitti: upstream closed the bug as NOTGNOME first, but it looks like opensuse are working on using apport so they reopened the bug, they would like to know what the fedora plans are too, if you are in touch with somebody from fedora who could comment about that
<pitti> thekorn: has the API changed in that regard?
<thekorn> pitti, hmm, I'm sure the API did not change there,
<thekorn> this shuold work this way,
<thekorn> will have a look at it in a bit
<thekorn> what exactly is not working, are no attachments removed?
<seb128> thekorn: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-applets/+bug/255572 for example
<ubottu> Launchpad bug 255572 in gnome-applets "mixer_applet2 crashed with SIGSEGV in g_datalist_id_set_data_full() (dup-of: 255554)" [Undecided,New]
<ubottu> Launchpad bug 255554 in gnome-applets "mixer_applet2 crashed with SIGSEGV in g_datalist_id_set_data_full()" [Medium,Triaged]
<pitti> seb128: commented and CC'ed
<seb128> pitti: thank you
<pitti> thekorn: apparently not; I play with it locally here
<seb128> I let the coredump on those bugs so you guys can use that for testing
<pitti> thanks
<thekorn> ok, I will have a look at this in a few
<pitti> thekorn: let me finish my local test and write a reproducer
<mdz> both of my Intrepid systems have an empty /var/log/kern.log since the upgrade
<thekorn> ok
<pitti> thekorn: I'm pretty sure that the code is run, since the same function first deletes attachments and then marks the bug as a dup (and the latter works)
<pitti> mdz: confirming; /var/log/dmesg is there, but kern.log doesn't work
<mdz> pitti: something wrong with klogd perhaps?
<pitti> seb128: sorry for the bug noise, I have to undup the bug to play with it; will re-dup afterwards
<seb128> pitti: that's alright
<mvo> soren: should be running again (but will take a bit to complete, it needs to do some catchup). you don't happen to know about network speed slowdowns in the intrepid kvm? for me kvm in intrepid gives me only ~30k download speed (compared to ~700k with qemu)
<dholbach> james_w: congratulations! :)
<pitti> mdz: hm, "sudo tail -f /proc/kmsg" doesn't report anything either (tried with some modprobe)
<pitti> itz kernel bug?
<mvo> james_w: congrats!
<mdz> pitti: filed as bug 255635
<ubottu> Launchpad bug 255635 in sysklogd "Nothing logged to /var/log/kern.log in Intrepid" [Undecided,New] https://launchpad.net/bugs/255635
<Mithrandir> why do we have /etc/.java, at least in hardy?
<soren> mvo: Which nic are you emulating?
<mdz> pitti: kmsg was working earlier in the cycle, I used it for debugging bug 251223
<soren> mvo: Thanks for fixing MoM by the way.
<ubottu> Launchpad bug 251223 in linux "BUG: Dentry ffff81003ac17410{i=161b,n=cow} still in use (1) [unmount of rootfs rootfs]" [High,Fix released] https://launchpad.net/bugs/251223
<mvo> soren: the default one (not sure which one that is)
<mdz> pitti: is kernel.printk set correctly? I can never remember which way the numbers work
<soren> mvo: That would be the realtek one.
<pitti> mdz: neither can I :(
<mvo> soren: should I just try a different one?
<pitti> mdz: but 4 4 1 7 sounds familiar
<mdz> pitti: I noticed recently that sysrq+[1-9] didn't seem to work, I wonder if it's related
<soren> mvo: It couldn't hurt. Either pass "model=virtio" to the first "-nic" on the command line, or set "<model type='virtio'/>" in the interface definition in the domain definition.
<soren> (depending on whether you're using libvirt or not)
<mdz> pitti: did you remember to stop klogd before your tail -f /proc/kmsg test?
<lool> Mithrandir: Urgh
<lool> Mithrandir: Looking at my dpkg.log, it seems to come from java-common
<pitti> mdz: yes, I did
<mdz> pitti: confirmed here, nothing in /proc/kmsg
 * pitti follows up to the bug
<mdz> pitti: already updated
<pitti> argh, LP ate my comment
<mdz> pitti: was it because I moved it to a new package (which bizarrely changes the URL)?
<pitti> yes, I got an error message
<mdz> pitti: going back in the firefox history retrieves lost input fields surprisingly often
<pitti> and alt+left then didn't remember the text contents
<lool> Mithrandir: I also have sun-java6* upgraded in the same minute, so they could also be at fault (I checked the creation time of /etc/.java)
<tjaalton> mdz: please attach /var/log/Xorg.0.log to 255008, thanks
<Mithrandir> lool: that's where it's come from; I'm wondering why somebody thought dotfiles in /etc was a good idea.
<tjaalton> mdz: upstream wants that
<tjaalton> mdz: also, you do have -1ubuntu3 of the xserver installed?
<lool> Mithrandir: Well and the package failed to cleanup after itself too
<lool> (as I have this empty /etc/.java now, but no sun-java6* installed)
<Mithrandir> lool: ugh.
<mvo> soren: ohhhh - that looks *much* better, in fact, I'm getting 11mb peek to my local proxy now *sweet*
<mvo> soren: is this available in hardy too? can we make it default please :)
<soren> mvo: It is. :)
<soren> mvo: Both available and the default :)
<soren> mvo: If you choose Ubuntu Hardy as the OS you're installing in virt-manager, it chooses virtio_net automatically.
<mdz> bug 255008
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Confirmed] https://launchpad.net/bugs/255008
<mvo> soren: hm,  for the -nice user too? I have the latest kvm here and before I added "model=virtio" I got really bad throughput (basicly I just ran "kvm image.qcow2")
<soren> mvo: Oh, no, not if you run kvm like that.
<mvo> soren: ok, so its default in libvirt but not on the commandline kvm?
<soren> mvo: The only operating system that supported it at Hardy's release was Hardy.
<mdz> tjaalton: sorry it's almost 8M, due to bug 247195
<ubottu> Launchpad bug 247195 in xorg-server "Server log fills up with acpid socket errors" [Low,Confirmed] https://launchpad.net/bugs/247195
<mdz> tjaalton: but I have attached it now
<mvo> soren: for virtio? I see. that is a problem :) will the hardy kvm with virtio work with a intrepid guest? or is that not possible?
<soren> mvo: I think perhaps a few others are starting to catch up, but it'll never be as ubiquitisly(sp?) supported as the realtek adapter.
<soren> mvo: That should work fine.
<tjaalton> mdz: heh
<mvo> soren: thanks for your explaination! that is fine then, I'm only concerned with ubuntu systems for my current project, so I will just add it to my standard kvm option, thanks again for your help
<soren> mvo: The interface has an ABI check, so it doesn't work, it will just come up without a NIC. It won't just break spectacularly.
<soren> mvo: No problem :)
<seb128> tjaalton: is there any know video bustage on intel in intrepid? the evolution composer has refresh issues and artefact since I upgraded today (I didn't upgrade for a few days before that)
<tjaalton> mdz: I've filtered the ACPI errors and will attach that too
<tjaalton> seb128: not that I know of, my i965 works mostly ok
<seb128> hum, ok, using compiz?
<tjaalton> but then again I don't use evolution
<seb128> is there any change this week that could have created issues?
<mdz> I'm seeing a lot of corruption with nvidia on intrepid on my desktop
<mdz> e.g. switching tabs in firefox doesn't redraw half the window
<thekorn> pitti, I think I found the issue
<pitti> thekorn: fun; originally it had 4 attachments; the first run removed 2, the second removed 1
<pitti> thekorn: now just CoreDump.gz is left
 * pitti runs it a third time
<thekorn> pitti, and whe you run it again, Coredump will be removed
<pitti> thekorn: maybe the $ doesn't match reliably any more or so?
<pitti> thekorn: right, worked now
<tjaalton> funny, I don't have evolution installed
<thekorn> no, attachment.remove is not working correctly for many matches
<pitti> thekorn: do you need my reproducer script? (we have some more bugs to try this with)
<thekorn> so it only removes the first match
<tjaalton> seb128: no updates to the intel driver. do you use compiz? does metacity have the same problem?
<thekorn> pitti, no, I'm fixing it right now
<pitti> thekorn: awesome, thanks!
<pitti> seb128: I'll ask bdmurray to generate a list of all bugs with Coredumps, then I'll run a script for mass-cleanup
<seb128> tjaalton: I do use compiz but this one didn't change in the update
<seb128> pitti: thanks
<pitti> seb128: btw, I'm really impressed with the current fakechroot; intrepid chroots have updated without a hitch for weeks...
<seb128> that's good indeed ;-)
<pitti> by now that should have compensated for the 6 hours I spent on debugging and fixing  fakechroot, I guess :)
<tjaalton> mdz: would you attach xorg.conf as well, thanks
<mdz> tjaalton: it's already in a comment in the bug
<tjaalton> mdz: only a part of it
<mdz> tjaalton: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/255008/comments/8
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Confirmed]
<mdz> tjaalton: there is nothing else but Driver "nvidia".  I will attach it though
<tjaalton> mdz: yes, thanks.
<mdz> tjaalton: done
<tjaalton> seb128: I can see the corruption too, with metacity
<seb128> tjaalton: good ;-)
<thekorn> pitti, fix pushed to the .main branch
<pitti> thekorn: rock, thanks!
<seb128> brb
<tjaalton> seb128: but the driver has not been updated in a while, and I doubt it's a problem in the server, so.. :)
<pitti> thekorn: curious fix
<seb128> tjaalton: you are blaming it on GNOME aren't you ;-)
<tjaalton> seb128: well, you said it :)
<pitti> seb128, thekorn: retracers restarted with the fixed p-lp-bugs
<pitti> oh, seb is offline
<thekorn> pitti, right, but it makes sense, because LPAttachments.filter() returns a generator
<pitti> thekorn: ah, the problem isn't the set, but that it returns an iterator instead of a static set?
<pitti> so that you can't use things like "in"?
<thekorn> pitti, the problem was that that the length of the attachment list was changed durring a run of a loop, which was/is not working correctly
<pitti> aah
<thekorn> pitti, I just went through apports launchpad.py, defining the download location for attachments changed a bit, http://paste.ubuntu.com/35044/
<pitti> thekorn: hm, so that still works, but is deprecated?
<pitti> thekorn: since apparently it can download attachments with the current version
<seb128> tjaalton: alright, the composer issue is due to the gtk update
<tjaalton> seb128: heh :)
<thekorn> pitti, yes it is working, but it does not download the files to your tmpdir, but to a default location
<pitti> thekorn: ah, where is that?
<thekorn> let me check
<thekorn> ~/.bughelper/attachments-cache
<pitti> thekorn: I added the missing ), testing now; it doesn't seem to have downloaded any, /me peeks
<pitti> ah, PEBCAK
 * hunger is waiting for debian to update its git-core debs for the security update that was released so that he can bug people in #ubuntu-devel to sync the debs.
<persia> hunger: Why do you need to bug people?  Just file a bug and subscribe the appropriate parties.
<hunger> persia: Mostly to find out who the appropriate party is. I don't want to just assign everything to pitti;-)
<hunger> And of course bugging people gets results faster.
<persia> hunger: Except where bugging people annoys them and they have reduced motivation.
<persia> Anyway, for a security update, I'd recommend subscribing the security team.  For a sync of a package in main (such as git-core), I'd recommend subscribing the ubuntu-main-sponsors.
<hunger> persia: Well, using LP annoys me;-)
<persia> hunger: Well, someone needs to put it in LP.  Note that this can be just sending email.
<pitti> hunger: just use requestsync, that will DTRT and subscribe ubuntu-archive
<pitti> and you don't need to get in direct contact with LP :)
<cjwatson> kirkland: so what was that grub patch?
<asac> NM 0.7 uploaded :/
<lool> Why ":/"?  It should be \o/
<asac> yeah.
<asac> \:/ ;)
<ogra> ion_, do you happen to be around ?
<seb128> asac: good job ;-)
 * ogra pats asac on the back
<asac> tell that to me when you still have network ;)
<cjwatson> asac: woo
<Riddell> mvo: did you get a chance to look at my compiz patch?
<mvo> Riddell: still not :( but I will do it today, I plan a compiz update as well
<asac> Riddell: so knetworkmanager probably should be uploaded too
<Riddell> asac: mm, ok
 * ogra scratches his head about the overcomplicated compcache implementation 
<Keybuk> this whole "no X server" bug ceased to be funny long ago
<ogra> Keybuk, ECONTXT ?
<Keybuk> ogra: no X server on boot for Dell Latitude D420/430
<ogra> ah
<tjaalton> Keybuk: does it have intel gfx?
<Keybuk> tjaalton: yes
<tjaalton> Keybuk: ok, try without usplash
<Keybuk> tjaalton: I *know* that works, I was the one that discovered the "no splash" trick
<tjaalton> there is a patch upstream which might help
<Keybuk> that's not a fix though ;)
<tjaalton> heh
<tjaalton> I'll merge 2.4.0 and add that patch (and others from the stable branch) and see if I can reproduce the problem anymore
<YokoZar> slangasek: what should I name a file I put into the new /etc/sysctl.d ?  I assume the format is just the same as an entry in sysctl.conf, but I haven't found a naming standard yet.
<ogra> persia, any idea about that java issue ?
<ogra> its definately not LTSP
<ogra> so the duplication is the wrong way round
<persia> Erm.  Oops
<ogra> (since his mp3's and the login/logout sounds work fine)
<persia> Right.  Seems to be a not uncommon issue with some JAVA releases.  On the other hand, it ought be using ALSA post-Java 1.5
<persia> Anyway, it's clearly an issue with either MALTED or Java, and not LTSP as such.
<persia> Sorry for the reverse duplication.
<zul> pitti: yes I saw it, trying to fix it but not sure how kirkland is also looking at it
<Mez> argh, we've taken the dash stuff havent we? we dont install bash as part of essential anymore?
<cjwatson> bash is still essential, although /bin/sh points to dash
<cjwatson> there is no plan to remove bash from essential
<cjwatson> it is still the default user shell
<persia> That has been true for quite a while now.
<pitti> zul: thanks (and good morning!)
<zul> pitti: np
<cjwatson> Mez: https://wiki.ubuntu.com/DashAsBinSh
<Mez> configure: error: cannot run /bin/bash ../config.sub
<Mez> I guess it was the error with config.sub ;) not bash
<TheMuso> Keybuk: Question for you re udev, symlinks and link priority. I'm trying to get a /dev/disk/by-uuid symlink for a device mapper filesystem to have a higher link priority than the same filesystem UUID which originally points to a /dev/sd device. I notice through udeadm info that the UUID symlink for the sd device has no link priority. I've tried various values, but the symlink doesn't appear to be replaced.
<TheMuso> Keybuk: My rule is after persistant-storage in terms of numbering, i.e in the 6x range.
<Keybuk> it'll have a zero link priority by default
<TheMuso> Keybuk: So, am I to assume that a positive plink priority should overwrite it?
<Keybuk> you need to change the 65-dmsetup.rules file
<Keybuk> OPTIONS="link_priority=-100"
<Keybuk> becomes something > 0
<Keybuk> and you need to fight in a tub of jello with kees who says that DM devices need to be *lower* priority
<TheMuso> My rule runs after dmsetup, and is to do with dmraid and readjusting UUID symlinks for filesystems on RAID1 devices.
<Keybuk> I bet you're having DM-RAID vs. LVM issues
<Keybuk> where one needs to be higher, the other lower
<TheMuso> Keybuk: More like dmraid vs real hard disk partition/filesystem issues.
<TheMuso> For RAID1 setups.
<Keybuk> right
<Keybuk> real partition looks like the dm-raid partition
<Keybuk> and you want dm-raid to win
<TheMuso> Yep.
<TheMuso> Exactly./
<Keybuk> whereas in other devmapper situations, you want the real partition to win
<TheMuso> Yep.
<Keybuk> do you have something that matches dm-raid only?
<Keybuk> ENV{DM_TARGET_TYPES}=="*dm-raid*", OPTIONS="link_priority=100"
<Keybuk> something like that maybe?
<Keybuk> *(note no - on the 100)*
<TheMuso> I have the UUID base, which is DMRAID-*. I also have KERNEL=="dm-*
<TheMuso> As oposed to md-*
<Keybuk> dm-* is all devmapper devices
<Keybuk> so that'll break LVM
<Keybuk> and cryptsetup
<TheMuso> Keybuk: Hrm you sure? Checking a real devmapper device on another system here, it shows as md- for the kernel value.
<Keybuk> md is definitely mdadm :)
<Keybuk> dm is devmapper
<Keybuk> LVM devices show up as dm-999
<TheMuso> Keybuk: sorry  you are correct
<TheMuso> So there is the UUID then.
<TheMuso> DM_UUID=DMRAID-blah
<Keybuk> yeah
<Keybuk> is there nothing in the target types we could match?
<Keybuk> that's how we do it for LVM
<TheMuso> DM_TARGET_TYPES=linear
<TheMuso> thats for a dmraid device, which also is used for LVM it seems.
<Keybuk> ah right
<Keybuk> DM_UUID seems reasonable then
<Keybuk> the bottom of debian/dmsetup.udev could look like
<Keybuk> IMPORT{program}="vol_id --export $tempnode"
<Keybuk> OPTIONS="link_priority=-100"
<Keybuk> ENV{DM_TARGET_TYPES}=="*snapshot-origin*", OPTIONS="link_priority=-90"
<Keybuk> ENV{DM_UUID}=="DMRAID-*", OPTIONS="link_priority=100"
<Keybuk> then the bits to make the symlinks
<TheMuso> Keybuk: Ok thanks, I'll give that a shot.
<TheMuso> Keybuk: Also, any idea why Debian never packaged/enabled dmeventd in devmapper?
<ion_> ogra: I am now. Iâm going to eat, but iâll read the scrollback afterwards.
<tjaalton> Keybuk: would you test the new intel driver? seems to work for me
<tjaalton> Keybuk: I've got i386 deb ready
<ogra> ion_, i'm a bit confused how the compcache script as we have it now is supposed to work ... we only have three usecases from the distro side which all include the initramfs being build on a different system than the target system ...
<Keybuk> tjaalton: url?
<ogra> ion_, your code seems to use /proc/meminfo at build time thats not going to work at all
<tjaalton> Keybuk: http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-intel_2.4.0-1ubuntu1_i386.deb
<TheMuso> Keybuk: That change to 65-dmsetup.rules works, however is that likely to be a clash/problem with LVM?
<Keybuk> TheMuso: shouldn't be since you only match dmraid
<TheMuso> Keybuk: Right.
<TheMuso> I'll test it tomorrow anyway.
<TheMuso> Now to write a udev rule to bring up dmraid arrays automatically, with the help of a wrapper script to prevent degraded arrays being brought up unless the user specifically asks for them to be.
<Keybuk> tjaalton: still black screen
<seb128> jdstrand: hey, so I pinged evolution's upstream about your calendar issue, they are interest in some details
<seb128> - do you get an error on the command line when you create a new meeting in the calendar
<seb128> - is the red line which indicates the current time in the day view correct?
<jdstrand> seb128: let me see
<jdstrand> seb128: red line is correct
<tjaalton> Keybuk: bah
<jdstrand> seb128: you are not going to believe this-- it is working now
<seb128> jdstrand: bah :-(
<jdstrand> totally bah :(
<jdstrand> seb128: I did logout and back in since we talked
<jdstrand> seb128: I wonder if there was an update where I needed to restart my session (perhaps from -updates?)
<seb128> jdstrand: ok, if you get the issue again note if there is some error in .xsession-errors when creating something on the calendar and if the line is correctly placed
<jdstrand> seb128: I shall. this bug is odd...
<seb128> jdstrand: you tried on a stock user no?
<seb128> that was a new session?
<jdstrand> seb128: just now? no-- but when we filed-- yes
<seb128> right, and you had the issue
<jdstrand> seb128: looks like I may have rebooted in the meantime too
<seb128> so that's not likely an upgrade and session restart
<jdstrand> seb128: good point
<jdstrand> odd
<seb128> well, if the other user you try was a fresh login that's not likely an upgrade issue
<seb128> indeed
<tjaalton> Keybuk: right, I got a blank screen after booting .26 the second time
<ion_> ogra: Nope, it writes a piece of sh code that uses /proc/meminfo to a file in initramfs, which is then evaluated when the initramfs is running.
<ogra> no, thats sitting in the hook
<ogra> nozt in init-top
<ion_> ogra: Huh. Iâll take a new look at the code, a moment...
 * ogra really whished we didnt have such complicated code in tehre 
<ogra> four lines and a udev rule would have sufficed
<ion_> ogra: The code seems allright to me. The hook writes '$(blahblah /proc/meminfo)' to $DESTDIR/scripts/init-top/compcache
<ogra> no it doesnt
<ogra> all the /proc/meminfor code sits in the hook
<ion_> ogra: Note the $( being escaped: mem_total="\$(sed ...
<ogra> but before the cat >"$DESTDIR"/scripts/init-top/compcache <<EOF
<ion_> Also the kbytes calculation is escaped: kbytes="\$((...
<ogra> yes, i see that
<ogra> but its still only read at buildtime
<ogra> which will give you only the inof of the buildd
<ogra> *info
<ion_> ogra: % zcat /boot/initrd.img-$(uname -r) | strings | grep compcache_size_kbytes
<ion_> modprobe -Q --ignore-install compcache compcache_size_kbytes="$(($(sed -nre 's/^MemTotal:\s*([0-9]+) kB$/\1/p' /proc/meminfo) * 50 / 100))"
<ogra> hmm
<ogra> right, thanks for clearifying ... understood now ... but i still dont like the complexity :/
<tjaalton> Keybuk: it always works with the hardy kernel though..
<ion_> ogra: Itâs not really *that* complex IMO. And i really want the possibility to set a percentage. That allows me to use the same configuration on all my boxes, even though the low-end one has 64 MiB of RAM and the high-end one has a gigabyte.
<Keybuk> tjaalton: the old version always worked with the hardy kernel too
<tjaalton> Keybuk: yep
<ogra> ion_, its more complex than just go with upstream and not wrap a scrpt around it ...
<ogra> since with upstream it wuld be (as i said above) a four line init-top sctipt and a hook installing the udev rule
<vargadanis> hi
<vargadanis> bye ^_^
 * vargadanis just read the topic
<Keybuk> tjaalton: I just noticed an interesting difference between kernels
<Keybuk> let me try something
<ion_> Do others think /usr/share/initramfs-tools/hooks/compcache is too complex? There are a lot of places one could simplify/shorten code while reducing user-friendliness, and i sincerely donât think it should be done with that one.
<Keybuk> ooh
 * ogra would like to point out to "the others" that the alternative would be a one liner: modprobe -Q --ignore-install compcache compcache_size_kbytes=$COMPCACHE_SIZE 
<Keybuk> I just fixed my own bug
<Keybuk> pitti: are you still having the X issue on your 430 when running the 26 kernel?
<ogra> and a hoook putting up the udev rule
<ogra> Keybuk, i do
<pitti> Keybuk: what is the X issue?
<Keybuk> pitti: booting with splash, no X
<BenC> pitti: Do you think, even without the package-groups, that we could remove apt's exception for linux-image-* now that we have a legitimate fallback for kernels?
<pitti> Keybuk: usplash is broken, and computer becomes slow without pci=nomsi, otherwise current kernel works very well
<Keybuk> add uvesafb to /etc/modprobe.d/blacklist-framebuffer
<Keybuk> and update-initramfs -u
<Keybuk> seems someone renamed the framebuffer module ;)
<BenC> Keybuk: no, it's a different module :P
<pitti> Keybuk: ah, so that's why adding it to /etc/modprobe.d/blacklist only worked for starting usplash in the running system?
<BenC> Keybuk: but it is a bug that not having v86d installed makes uvesafb break the console, and I'm looking into it
<pitti> Keybuk: I had assumed that /etc/modprobe.d/ blacklists would automatically apply to the initramfs, too
<Keybuk> pitti: not unless you update the initramfs ;)
<pitti> Keybuk: oh, hang on, bl-framebuffer or bl shouldn't make a difference
<pitti> Keybuk: hm, I think I did try that
<pitti> Keybuk: I'll try again
<BenC> blacklist might not work
<pitti> but I think it didn't work last time
<BenC> I think usplash force loads it anyway
<BenC> but it should only do that if you have a vga= or video= line in your cmdline
 * ogra tries Keybuk's suggestion
<ogra> nope
<ogra> grrr, why does compiz not maximize as it should
<ogra> oh, bceause my system decides that compiz isnt good for me after a reboot :( so it auto switches me to metacity
<ogra> Keybuk, since you assumed the module was renamed, does that mean you dont have vesafb in your blacklist ?
<Keybuk> ogra: vesafb is in the blacklist by defualt
<ogra> i know
<pitti> seb128: hm, so it doesn't look as pretty as pidgin, but by and large it feels the same
<ogra> but you assumed it was renamed above ... so i was wondering if you just added a u in front :)
<pitti> seb128: ICQ and jabber work
<seb128> pitti: right, and it'll follow GNOME schedule and has responsive upstream which will be happy to help use if we ship their software
<pitti> seb128: it just cannot figure out the realname of one of my ICQ contacts (user info doesn't help either), otherwise it works well enough
<tedg> I've found IRC to be lacking in Empathy.  It's usually the thing that frustrates me and pushes me back to Pidgin.
<tedg> Apparently there's an SoC project for it though.
<pitti> tedg: heh, I found IRC frustrating in pidgin, and it's the thing that brings me back to xchat or weechat :)
<seb128> tedg: you really do IRC in an IM client?
<Keybuk> tedg: xchat-gnome FTW!
<ogra> xchat ftw !
<seb128> xchat-gnome is way better
<pitti> weechat FTW!
<mdz> BenC: it gets loaded unconditionally
<Keybuk> ogra: I added an extra line
<tedg> Yes, I do do IRC in Pidgin/Empathy.
<Keybuk> mdz: the vesa fb module?  no it doesn't
<ogra> Keybuk, yes, understood now ... well, didnt work here
<seb128> tedg: IRC is different enough to have specialized softwares
<pitti> BenC: I have it loaded, too (uvesafb), and no video/vga kopt
<mdz> Keybuk: uvesafb does
<Keybuk> mdz: LoC?
<tedg> I've not had any feature that I think is missing.
<pitti> tedg: pidgin's usage of screen real estate is too wasteful for my IRC needs
 * ogra would also like to know why usplash jumps between bounce and progress mode 
<pedro_> tedg: for IRC try installing telepathy-idle
<tedg> I find the XChat GUI to be too cluttered.
<pitti> it's ok for personal private conversations, where you close the windows again, but having them open all the time, as for IRC, is a pain IMHO
<mdz> Keybuk: LoC?
<Keybuk> mdz: line of code where it gets loaded
<tedg> pedro_: Yeah, I was using telepathy-idle, even patched it some.  But it still seems broken.  Drops off, doesn't name the rooms right (guessing by subject is fun).
<sladen> ogra: unknown; boot; fsck unknown, fsck progress, unknown; boot progress?
<mdz> Keybuk: /usr/share/initramfs-tools/hooks/kernelextras:36
<Robot101> tedg: what's broken? where are the bugs? :(
<Keybuk> mdz: err, that's a function?  doesn't mention uvesafb
<Keybuk> oh
<Keybuk> sorry
<mdz> Keybuk: read the function, then look in /lib/modules/`uname -r`/initrd
<Keybuk> it iterates /initrd
<ogra> sladen, hmm, it looks quite weird but that could be it
<Keybuk> it looks very like another function I'm used to reading
<Keybuk> force_load() adds the module name to conf/modules
<tedg> pitti: I already have the screen real estate used for Jabber chats, etc.
<Keybuk> which is iterated by load_modules() in the initramfs
<Keybuk> which calls modprobe on it
<Keybuk> which means the blacklist applies
<tedg> Robot101: I've filled the new ones in the telepathy repository.  Most are known and have been on the telepathy devel list.
<pitti> tedg: in particular, there doesn't seem to be a way to make the font size smaller, and not waste so much space at the window bottom
<BenC> pitti: did you see my question about apt linux-image-* exceptions to autoremove?
<mdz> Keybuk: that's good news
<BenC> mdz, Keybuk: Ok, I'll take a look at that
<mdz> but it isn't in the blacklist
<pitti> BenC: right, sorry, was in the meeting until now
<Keybuk> mdz: no, that's what I was saying
<Keybuk> the framebuffer blacklist is manually maintained
<Keybuk> and seems to be lacking some of the newer framebuffer modules
<Keybuk> notably uvesafb
<mdz> BenC: why is uvesafb treated differently than all the other framebuffer modules?
<Keybuk> obviously it shouldn't be attempted to be loaded in the first place, since we blacklist them :p
<pitti> BenC: I wouldn't kill all non-default kernels automatically, but since we don't do autoremoval by default, I think it's fine to drop the exception
<BenC> mdz: because vesafb was, and uvesafb is supposed to supercede vesafb
<pitti> BenC: e. g. I needed to run the hardy kernel for quite some time
<mdz> Keybuk: it wouldn't matter if it were blacklisted or not, if we didn't load it unconditionally
<ogra> for me it doesnt fix an issue even with only fbcon loaded
<tedg> pitti: So you're saying that you're not waiting for the Webkit integration to have animated messages from individual speakers in a chat ;)
<Keybuk> BenC: but vesafb was also blacklisted by default
<Keybuk> mdz: agree
<BenC> Keybuk: really?
<pitti> tedg: lol
<mdz> so rather than force_loading it and blacklisting it, how about just not loading it?
<Keybuk> grep vesafb /etc/modprobe.d/blacklist-framebuffer
<ogra> BenC, t s here
<ogra> *it
<BenC> vesafb was force loaded before as well
<BenC> If someone can boot into hardy and see if it is loaded or not, that would help
<Keybuk> BenC: yes, it's in that directory
<Keybuk> but since it's also in the blacklist
<Keybuk> being in that directory was kinda pointless ;)
 * ogra de-blacklists it and tests
<BenC> Keybuk: no, blacklist is ignored when usplash loads fb modules
<Keybuk> quest scott% ls /lib/modules/2.6.24-20-generic/initrd
<Keybuk> vesafb.ko
<Keybuk> quest scott% lsmod | grep vesa
<Keybuk> zsh: done       lsmod |
<Keybuk> zsh: exit 1     grep vesa
<pitti> Keybuk: so still want me to try and blacklist uvesafb?
<Keybuk> BenC: usplash doesn't load fb modules
<Keybuk> the framebuffer initramfs script does deliberately force load it *if* you have vga=... on the command-line
<BenC> Keybuk: I beg to differ...let me get the snippet
<BenC> That's the script I'm thinking of
<cjwatson> ion_: I think it'd be easier to read if you had the init-top script as a separate file that sources a configuration file, rather than substituting stuff into it at run-time
<BenC> I for some reason though that was a usplash hook, but I could be wrong
<Keybuk> the fact it has -Q there means it *won't* obey the blacklist
<Keybuk> if it just did modprobe $FB it *would* obey the blacklist
<Keybuk> don't look at me like that
<BenC> Keybuk: uh, -Q is quiet
 * Keybuk can't hear you
<Keybuk> la la la la
<Keybuk> actually, it's that MODPROBE_OPTIONS="-Qb" in init
<BenC> Keybuk: -b means to honor the blacklist...so if it doesn't have that, it will load no matter what
<Keybuk> (quiet and obey blacklist)
<Keybuk> and specifying any option means modprobe ignores the default env var
<Keybuk> so modprobe foo will use $MODPROBE_OPTIONS, which means it's the same as modprobe -Qb foo
<cjwatson> things I have learned today: modprobe is crazy
<ogra> yay
<ogra> removing vesafb from the blacklist and adding uvesafb helps here
<Keybuk> cjwatson: it's maintained by jon masters
<Keybuk> he drives a miata, wears silly hats, and can't get over his ex
<ogra> cjwatson, heh, you werent in the mobile bootspeed session in prague
<ogra> you could have seen *intresting* things happening with modprobe
<Keybuk> funnily enough, at least 2/3 of those items match different members of Canonical staff
<Keybuk> but we don't have the full set in any one person
<BenC> Keybuk: sounds like a job for HR
<cjwatson> Keybuk: you're in good form today
<ogra> holiday pending ?
<Keybuk> heh, no
<mdz> pitti: the guest session worked for me, but the mixer applet crashed on logout
 * ogra wonders whats that that switches him back to metacity on each boot ...
<jtisme> anyone know what 8.04  repository  kickstart is in
<mdz> ogra: novell spies
<ogra> haha
<seb128> mdz: probably nothing specific to the guest session, bug #255554 maybe?
<ubottu> Launchpad bug 255554 in gnome-applets "mixer_applet2 crashed with SIGSEGV in g_datalist_id_set_data_full()" [Medium,Triaged] https://launchpad.net/bugs/255554
<BenC> While we're on the topic of bugs...I really want my power button back on the top toolbar instead of that little green jogger guy
<BenC> I hate him
<ogra> BenC, ++
<ogra> BenC, being worked out upstream
<seb128> ogra: the new gnome-session does that, there is a gconf key you can set to compiz though
<mdz> seb128: hard to tell, because it failed to write a crash report (it was 0 bytes).  it doesn't crash in my normal sessions though
<Keybuk> seb128: that so doesn't work
<ogra> seb128, hmm, so no auto love for users anymore ?
<ogra> i would expect such a key to be set from the appearace applet btw
<BenC> And for reboot/shutdown while logged in to actually DTRT
<seb128> Keybuk: you set the wrong key
<pitti> Keybuk, BenC: so, for the record, blacklisting uvesafb doesn't change a thing, still red-white stripes (yes, I updated initramfs)
<Keybuk> seb128: I sat the one you told me to
<seb128> Keybuk: edit the /desktop/gnome/session/default-session list
<seb128> Keybuk: and I was wrong, it's in the same place but the next key in fact ;-)
<BenC> pitti: try installing v86d and tell me if that fixes things
<BenC> pitti: Just so I know the root cause
<Keybuk> ahh
<pitti> mdz: indeed, having a clean profile exposes quite a bunch of current gnome desktop bugs, such as the theme, and various other crashes
<BenC> pitti: output from dmesg would help too, if you can blind capture it
<pitti> BenC: I think I already tries all four combinations
<seb128> pitti: what crashes?
<pitti> seb128: random crashes with a fresh user profile (such as in the guest session)
<pitti> seb128: haven't worried about them too much yet, somethign for post feature freeze
<seb128> pitti: please report those using apport so we can get them fixed
<mdz> pitti: I only had the red/write stripes if uvesafb was actually working (i.e. v86d installed)
<cjwatson> jtisme: which bit of kickstart? the UI or the installer implementation?
<seb128> pitti: the sooner reported the better
<BenC> pitti: Should I upload apt without linux-image-* exceptions, or is there someone better to do that?
<mdz> pitti: do you have a guess why the crash report wasn't written?
<seb128> pitti: or it'll be late for next GNOME
<pitti> BenC: I think I can boot blindly with ctrl+alt+f1 and typing my luks passphrase, and get dmesg, yes
<jtisme> cjwatson, both please
<pitti> BenC: mvo might want to keep it all in bzr, I don't know
<cjwatson> jtisme: the former is the system-config-kickstart package, the latter is kickseed
<ogra> pitti, try adding a u to vesafb in the blacklist-framebuffer file .... that works here
<BenC> mvo: ^^
<pitti> mdz: I reinstalled my box from alpha 3 and forgot to reenable apport manually
<pitti> ogra: i did blacklist uvesafb
<ogra> i.e. enabling vesafb, disabling uvesafb
<pitti> sommer: so, unblacklist uvesafb and install v86d, then dmesg?
<pitti> ogra: oh, ok
<mvo> BenC: if you could point me to a patch, that would be nice, I like to upload stuff that is in sync with my bzr tree
<BenC> pitti: No, dmesg without v86d installed
<BenC> pitti: and with
<stgraber> heh, what's happening to evolution ?? The new message window is extremely buggy here ...
<jtisme> cjwatson, ok thanks cna find kickstart but not kickseed
<mvo> BenC: this is just about removing the kernel from the autoremove blacklist?
<cjwatson> jtisme: there's no "kickstart" package in the archive
<pitti> BenC: and with uvesafb loaded? or not?
<ogra> stgraber, for me its only slow
<cjwatson> jtisme: you'll need 'apt-get source kickseed'. It's an installer component and you can't install those on normal systems
<jtisme> cjwatson, ok thanks will look it over
<BenC> mvo: just remove the whole NeverAutoRemove stanza in /etc/apt/apt.conf.d/01autoremove
<ion_> cjwatson: ogra preferred the script that actually ends up in initramfs to be as simple as possible, so that there exists no percentage computation if the user isnât using a percentage.
<cjwatson> jtisme: anything particular you're interested in?
<BenC> pitti: yeah, with it loading
<BenC> pitti: (not blacklisted)
<stgraber> ogra: http://www.stgraber.org/download/evo.png and each other character I type make it worse :)
<jtisme> cjwatson, yes network installs
<ogra> stgraber, looks more liek a font issue though
<jtisme> cjwatson, on multiple machines etc.
<mvo> BenC: ok, consider it done
<BenC> mvo: thanks
<mvo> BenC: should I upload just for this or is it ok to wait until some more changes come up? so the new fallback kernel stuff is there and working? that is excellent news \o/
<kirkland> cjwatson: howdy, see https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/33649
<ubottu> Launchpad bug 33649 in debian-installer "root raid installs have bad grub config" [High,Confirmed]
<BenC> mvo: it's not urgent at all
<BenC> mvo: but yes, the fallback kernel stuff is there
<kirkland> cjwatson: kees gave it a once-over, and he thought it looked good--almost too good, surprisingly simple
<kirkland> cjwatson: that one is to grub-installer, i think another with similar logic will be needed in grub-install
<mdz> pitti: I definitely have apport enabled, but it wrote a 0-byte .crash file
<kirkland> zul: you and pitti were talking about something and mentioned me....  what was that?
<mdz> pitti: i figured it had something to do with the guest session
<mvo> BenC: thanks, commited
<cjwatson> kirkland: ok, will look after the phone call I have shortly
<mdz> pitti: ---------- 1  113  128       0 2008-08-07 15:16 _usr_lib_gnome-applets_mixer_applet2.113.crash
<zul> kirkland: php
<mdz> pitti: odd uid/gid as well
<pitti> kirkland: that was the php5 FTBFS
<pitti> mdz: yeah, it's a system user
<mdz> pitti: it's the pulseaudio user on my system
<kirkland> cjwatson: cool
<kirkland> pitti: ah, yeah, i reproduced a FTBFS, but didn't get much further than that
<pitti> mdz: there is no apparmor rule to allow writing to /var/crash for the guest session, but I wouldn't have thought it applied to apport (since it is launched by the kernel, not the guest session)
<pitti> mdz: please feel free to write a bug against gdm-guest-session, at least for the devel release apport crashes in guest session are useful
<pitti> mdz: pulseaudio> really? that would be weird
<pitti> on my system, pulse is uid 104, gid 113
<pitti> mdz: and since we all install from the live CD, I suppose on your's, too?
 * ogra has 107/116 for pulse 
<pitti> BenC: anyway, doing these boots/dmesgs now; any bug report I shuold attach the results to?
<BenC> pitti: there's probably one around, but may be best to just send them to me
<tkamppeter> pitti, I have done a new SVN commit for CUPS now.
<tkamppeter> pitti, now the package builds correctly with the new filters (under pbuilder) and PDF workflow actually works (print PDF file into Gutenprint queue).
<pitti> tkamppeter: nice
<pitti> BenC: ok, got them both now
<pitti> BenC: without v86d, red-white stripes; with v86d, no usplash at all, and it says "Can't get mode info (vm86 failure)"; usplash: no usable theme found for 320x200
<pitti> BenC: I'll mail the dmesg to you, ok?
<pitti> seb128: just got two apport crashes again; already reported, though
<seb128> pitti: ok, btw apport doesn't respect my prefered browser choice
<seb128> I got one crash already reported this morning and it opened firefox
<emgent> hello
<pitti> BenC: mailed
<pitti> seb128: gconftool --get /desktop/gnome/url-handlers/http/command
<seb128> pitti: $ gconftool --get /desktop/gnome/url-handlers/http/command
<seb128> epiphany %s
<pitti> seb128: does "gnome-open http://www.ubuntu.com" open ffox or epy?
<seb128> pitti: epiphany
<pitti> hmm; that's what apport does ATM
<seb128> are you sure?
<BenC> pitti: thanks
<pitti> if any of those fails, it falls back to using webbrowser.open() which probably calls ffox
<seb128> pitti: where is the code?
<pitti> seb128: oh, hang on
<seb128> pitti: it uses the sudo settings?
<pitti> pgrep -x -u 1000 gnome-session
<pitti> that fails
<pitti> up until hardy, a running gnome-session was a good indicator that you are running GNOME
<pitti> I need to update that apparently
<seb128> ah
<pitti> weird, what's the "mother process" nowadays?
<seb128> pitti: x-session-manager, debian thing
<pitti> argh
<pitti> oh, WTH, I have four zombies running
<pitti> Z    16:45   0:00 [gnome-login-sou] <defunct>
<pitti> Z    16:45   0:00 [gnome-volume-ma] <defunct>
<pitti> Z    16:45   0:00 [gnome-power-man] <defunct>
<pitti> Z    16:45   0:00 [gnome-at-visual] <defunct>
<pitti> yay new gnome-session not properly detaching children?
<pitti> seb128: so, I could use gnome-panel or nautilus as indicators for GNOME
<seb128> pitti: bug #252702
<ubottu> Launchpad bug 252702 in gnome-session "gnome-session leaving zombie's (dup-of: 250696)" [Undecided,New] https://launchpad.net/bugs/252702
<ubottu> Launchpad bug 250696 in gnome-session "Many processes are zombies" [Medium,Confirmed] https://launchpad.net/bugs/250696
<seb128> pitti: and http://bugzilla.gnome.org/show_bug.cgi?id=542880
<ubottu> Gnome bug 542880 in gnome-session "GNOME_DESKTOP_SESSION_ID not set anymore" [Normal,Unconfirmed]
<pitti> seb128: thanks
<seb128> pitti: usually looking for GNOME_DESKTOP_SESSION_ID is a good way
<seb128> when gnome-session is not broken
<pitti> $ env|grep GNOME
<pitti> GNOME_KEYRING_PID=5839
<pitti> hm
<pitti> seb128: heck, I just use the panel for now
<pitti> seb128: fixed apport uploaded, thanks for pointing out
<seb128> pitti: the zombie issue seems to be fixed in 2.23.6 which I didn't upload yet
<seb128> pitti: thank you
<davmor2> Yay alternative cd's work again :)
<seb128> pitti: btw I wanted to discuss that with you, gnome-session relies on dbus to be started now, do you think a depends on dbus-x11 (>= current-version) will be enough for that? or is that likely that some people deleted the conffile or something?
<pitti> seb128: we didn't install the conffile, so it'll come back when you install that version
<pitti> seb128: so a depends is ok
<seb128> ok, will do that then and upload the new gnome-session
<seb128> bigon: around?
<cjwatson> davmor2: oh good
<davmor2> cjwatson: no network issues, no partitioning issues and no missing modules :) Yay
<cjwatson> I imagine the first two were due to the last
<cjwatson> hard to do anything much with just the initrd
<davmor2> cjwatson: the first 2 showed up before the last one but as you say they could easily be interlinked :)
<cjwatson> davmor2: that's rather odd, the missing modules error is linearly before those in the installer flow
<cjwatson> anyway, never mind, shouldn't happen again
<davmor2> cjwatson: I admire the optimism :)
<tkamppeter> pitti, I have also asked for getting the new filters into upstream CUPS: CUPS bug 2897
<ubottu> CUPS bug 2897 in Core CUPS Software "Adding CUPS filters for using PDF as standard print job format" [Priority request for enhancement,New] http://www.cups.org/str.php?L2897
<tkamppeter> pitti, but I do not have any answer from Mike yet.
<cjwatson> davmor2: I mean because I took steps to stop it happening again
<cjwatson> at least in the same form
<davmor2> :D
<ogra> ion_, cjwatson http://paste.ubuntu.com/35103/ that would me my proposal for compcache vs what we have now (including some casper stuff so we dont need any additional scripts), ion_ i dont think its a prob if you add your percentage stuff to that
<ogra> hmm, probably another check if COMPCACHE_SIZE is actually set at all ... but you should get the idea
<seb128> pitti: for information http://mail.gnome.org/archives/desktop-devel-list/2008-August/msg00043.html
<pitti> seb128: hah
<pitti> seb128: so, time for an update of dbus, I guess
<pitti> seb128: can do, please nag me about it in case I forget
<seb128> yes ;-) well no hurry but we need the new version before intrepid
<seb128> pitti: ok will do
<seb128> thanks
 * seb128 hugs pitti
<pitti> oh, I just keep the tab open
 * pitti hugs seb128
<ogra> http://paste.ubuntu.com/35108/ is better now
<pitti> asac: how is nspr/nss now in hardy-proposed?
<pitti> ooh, new n-m coming through apt-get!
<pitti> so if I fall off the net, please send asac my â¥ :)
<sladen> pitti: let me guess, this is _the version_ of N-M that actually works and is going to save humanity ;0
<pitti> slangasek: it will certainly be 100% pure love
<pitti> and the other 90% are bugs
<pitti> asac: hm, nm-applet doesn't start here
<pitti> ** (nm-applet:28476): WARNING **: nm_object_get_property: Error getting 'WirelessHardwareEnabled' for /org/freedesktop/NetworkManager: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
<pitti> asac: but it didn't kill my eth connection during upgrade, bravo!
<davmor2> cjwatson: no usplash still :(
<pitti> tkamppeter: something is wrong there, if I run "debclean" it runs a whole lot of configure stuff...
<kees> mmm jello
<mvo> Riddell: I merged your compiz-wrapper patch, will be part of the next upload
<Riddell> mvo: great
<Riddell> I'll make kwin recommend compiz-wrapper then
<mvo> Riddell: excellent, thanks
<kees> Keybuk, TheMuso: from scrollback, it sounds like the link priority stuff got sorted out?  I could have used some jello; dang!
<asac> pitti: did you restart applet manually?
<pitti> asac: yes
<pitti> asac: and reloaded dbus as well
<pitti> asac: I haven't restarted my entire session yet, though
<asac> pitti: yeah ... problem is that NetworkManager has not been restarted. we need a reboot now
<asac> thats a _new_ feature
<pitti> asac: but I did that, too
<asac> reboot?
<seb128> re
<pitti> no, sudo /etc/init.d/NetworkManager stop/start
<seb128> pitti: ok, /usr/lib/ConsoleKit/scripts/ck-system-restart doesn't want to work, installing the policy doesn't make a difference there
<asac> pitti: hmm.. which nm-applet version?
<pitti> Version: 0.7~~svn20080721t051503-0ubuntu1
<asac> sounds good
<asac> pitti: maybe you have two NetworkManager running now?
<asac> wierd thing is that nothing changed dbus wise since the latest PPA version
<asac> which you already had iirc
<jarson> pitti, its possible for us to talk in private?
<slangasek> YokoZar: naming under /etc/sysctl.d - using the package name would be fairly typical, or else something descriptive about its function
<pitti> asac: no, I upgraded from intrepid (0.6) straight to the new intrepid
<Mirv> fwiw, I don't have any networks working in intrepid's new NM 0.7 at the moment, upgraded from 0.6. I've even rebooted.
<asac> pitti: ok. I'd say that you have still 0.6 running
<Mirv> (tries to connect, but ultimately fails, even to wired network)
<asac> Mirv: syslog ?
<asac> Mirv: there?
 * asac upgraded to archive version through apt-get
 * asac hits "system restart" ;)
<asac> works fine here
<asac> :/
<Mirv> asac: hmm, works now that I cleaned the cruft I first added into interfaces after having problems. looks like reboot actually did solve the problems, while I still had some after dbus/nm restart, before reboot
<Mirv> I do get link timed out quite often, though only with the FON station which is at times problematic itself too
<Mirv> well, I guess there'll be anyway bug reports if any big regressions are there
<DktrKranz> pitti, re vim-latexsuite SRU in hardy-proposed, I guess you rejected it due to wrong bug number (22541 instead of 225411), isn't it?
<pitti> DktrKranz: yes, I mailed the uploader
<pitti> DktrKranz: ah, you sponsored it?
<MacSlow> seb128, I assume you've not packaged the new gdm yet in a PPA or so, right? Just asking before I do duplicate work.
<DktrKranz> pitti, yes. I imagined when noticing bug #
<asac> Mirv: ok thanks
<seb128> MacSlow: you should really start read mails...
<seb128> MacSlow: you were Cced on the reply I did on monday
<DktrKranz> pitti, reuploaded with correct LP number, sorry.
<pitti> DktrKranz: thanks
<metavoid> pitti: hi, did you receive my email?
<pitti> metavoid: hi Nikolay! yes, I got it, just didn't repond yet
<pitti> metavoid: glad to 'meet' you!
<metavoid> pitti: ok, me too
<infinity> pitti: "selected in sbuildrc" is, indeed, true... I have an update for all the buildds queued (though I might just twiddle that by hand for now, and wait on bigger fixes to push new packages)
<pitti> infinity: ah, ok; good that it's known
<MacSlow> seb128, ups... sorry... forgot about that thread... never mind.
<pitti> metavoid: how does it run in general on suse? could you make any use of the existing fedora rpm bits?
<infinity> pitti: Honestly, though, if the New World Order is to have the most recent "automake" called "automake", maybe build-deps on "automaken" should be phased out in favor of just "automake" (and versioned package names when a package requires an older one)
<pitti> infinity: I agree; it would mean to introduce a delta, but I can do that
<pitti> infinity: or, if it applies to several packages, maybe just set automaken == automake in sbuildrc and keep it that way?
<infinity> pitti: Well, yes, that was the plan anyway.
 * pitti -> reboot, brb
<infinity> pitti: It just personally annoys me that, while sbuildrc used to house dozens of virtual->real mappings, the automaken one is about the only one left that matters. :)
<metavoid> pitti: yes, I inherited opensuse packaging class from rpm one, just like in Fedora
<metavoid> pitti: now it works pretty fine, you can see screenshots of apport-gtk on http://en.opensuse.org/Interactive_Crash_Analysis
<pitti> infinity: understandable
<pitti> infinity: 2 rdepends in main, 11 in universe
<pitti> no ttoo bad any more
<pitti> metavoid: the bits that I didn't abstract yet (because it's inherently hard) is apport-chroot and parts of apport-retrace
<pitti> metavoid: I guess they more or less have to be rewritten from scratch for every distro :(
<pitti> metavoid: spec> nice! I'm happy to see other people adopt it
<persia> infinity: It was suggested that you might be the right person to ask about the ardour FTBFS: it seems to choke in scons in different places for different build attempts on the buildds, and always compiles fine under sbuild or pbuilder on hardy or intrepid.
<pitti> metavoid: I guess it's worth reviewing how much of the logic in apport-chroot and -retrace is generic, and put the rest into the packaging backends
<pitti> seb128: new d-bus 1.2.3 works fine for me, uploaded
 * slangasek rolls new CDs to see what libgweather has managed to do for us
<metavoid> pitti: good idea, in these modules I noticed a bulk of ubuntu-specific calls
<NCommander> seb128, it seems every time we update a package, we break hppa more -_-
<seb128> pitti: you rock
<pitti> metavoid: they have to set up a complete chroot, install debug symbol packages, etc. that stuff needs to move to the package backends wholesale
<seb128> slangasek: hey, did you try the new clock applet locations dialog? ;-)
<pitti> metavoid: but of course those tools are what makes it really rock
<seb128> NCommander: hppa is just broken and doesn't build anything apparently
<metavoid> pitti: by the way one my ideas is ti implement automatic downloading of debuginfo packages, does ubuntu have something similar?
<pitti> metavoid: i. e. we get automated "retraces" (stack traces with symbols, based on debug symbol packages and core dumps)
<NCommander> seb128, its probably on account of glibc 2.8
<pitti> metavoid: I have a long-term wishlist bug about adding a "developer" mode
 * NCommander wonders how the glibc maintainers manage to break it for every release it seems
<pitti> metavoid: it would be nice if the notification window would have a button "Debug locally" if apport-retrace is installed (which we don't do by default)
<slangasek> seb128: not yet... haven't switched my primary desktop env to intrepid yet, that may have to wait until I'm back from DebConf to see :)
<pitti> metavoid: and then it would install all the dbgsym packages
<pitti> metavoid: just haven't found the time yet
<pitti> metavoid: something like bug 75901 ?
<seb128> slangasek: bug you should add bug #250506 to your list of intrepid issues, turns out reboot and halt don't work because the debian maintainers decided they don't like the consolekit restart and halt actions and don't allow those, pitti agree with them that upstream is on crack, so it's a distro specific issue and we are not going to get any help from GNOME on solving it now
<ubottu> Launchpad bug 250506 in consolekit "shutdown and restart act as logout" [High,Confirmed] https://launchpad.net/bugs/250506
<ubottu> Launchpad bug 75901 in apport "Integrate apport-retrace into GUI" [Wishlist,Confirmed] https://launchpad.net/bugs/75901
<davmor2> slangasek: I got wolverhampton listed and working so I don't care :)
<infinity> persia: Without even looking, I'd start with "Does debian/rules understand DEB_BUILD_OPTIONS=parallel=N", followed up by "Are you using it on your test system (because the buildds are)", possibly followed up once more with "scons sucks and I hate debugging it when it breaks".
<metavoid> pitti: yes, downloading debuginfos will be a killer feature, we just need to make a cross-distro class first, i'm going to start that very soon
<seb128> slangasek: I don't know about consolekit and I've too much to do already so I doubt I'll be looking at the issue
<pitti> slangasek: if it's fine for you to fix that ^ post FF, I'm happy to have a look in september
<slangasek> pitti: that's a bug rather than a feature, so yes
<slangasek> currently milestoned for alpha-5
<metavoid> pitti: yes that bug has the same idea I want to implement
<infinity> persia: Although, looking at the actual failure, it looks slightly more insidiously annoying than a threading/ordering issue.  Meh.
<pitti> metavoid: I think the hardest part so far is to implement a apport/crashdb.py subclass for bugzilla
<pitti> metavoid: so far I just have one for launchpad and a testing one (in-memory sqlite)
<pitti> metavoid: Will woods added a fedora entry to /etc/apport/crashdb.conf back then, and called it "rhbugzilla"
<pitti> metavoid: but there's no such class in the apport code; maybe he developed it separately
<seb128> pitti: I'm not sure I understand the rational though, the .policy allow only active users do to restart and halt and only auth_admin to do those in case somebody else is logged
<persia> infinity: Yes, No (and I'll try that), and indeed (but you are so good at it).  Thanks for the pointer.
<slangasek> 692M    daily/current/intrepid-alternate-i386.iso
<slangasek> win \o/
<seb128> pitti: so it should not be an issue, and not different of the suspend and hibernates actions we already have
<pitti> seb128: the rationale was that it's a design and dependency loop: CK asks PolKit for authorization, and PolKit then in turn asks ConsoleKit for infos about this authorization again
<pitti> slangasek: rocking
<metavoid> pitti: today I received an email from wwoods and he told me he will be happy to cooperate in adapting apport to bugilla
<pitti> metavoid: ah, you are in contact with him? great
<metavoid> pitti: there is a patch in fedora RPM package
<metavoid> pitti: btw, he is on #fedora-devel ;)
<seb128> pitti: is that really bad, both are installed anyway
<pitti> metavoid: hm, at least the non-RH-specific bits could certainly go upstream
<pitti> seb128: I'm not saying that it can't work, but it's really bad design (layer violation and circular dependencies)
<pitti> and it doesn't really belong into CK either
<android6011> is there a bug report for boot hanging at ACPI: EC: GPE Storm Detected, Disabling EC GPE until the power button is pressed?
<pitti> CK should track sessions, not have random other functionality plumbed on it
<alex-weej> seb128: you just closed https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/162068 today saying it was "already reported" but didn't set a dup bug ID... not the first time either! am i missing something or are you just being lazy? :P
<ubottu> Launchpad bug 162068 in gnome-panel "Default clock format is 12-hour, should be locale-dependent" [Low,Invalid]
<alex-weej> android6011: that shows even on my working system
<android6011> alex-weej: but my system hangs at it unless i press the power button, then it will continue to boot
<android6011> i have the same problem with backtrack3
<seb128> alex-weej: I'm being overworked, I can't look for duplicate number for the zillions duplicates open or I would spend half my days doing that and I don't think it would benefit anybody
<slangasek> ScottK, pitti: libmail-dkim-perl is still uninstallable on the server CD; is a MIR pending for libopenssl-rsa-thingy-perl?
<alex-weej> seb128: take a break
<seb128> alex-weej: I don't need to take a break, but I don't think looking for exact numbers benefit anybody as said, it's not a good ressource usage ;-)
<alex-weej> it benefits me
<alex-weej> i subscribed THAT report
<alex-weej> because that was a bug I was going to file
<seb128> well, you opened a bug about a known issue
<alex-weej> oh wait i am confused now
<seb128> alex-weej: I agree it's not optimal but choises are
<seb128> - let ton of known duplicates open because we are too busy to look for exact numbers, which make our work harder
<seb128> - close and let the duplicate filer search for the open bug
<seb128> - spend lot of time looking a duplicate which could be used to fix issues
<persia> seb128: Yes, but it's an exceedingly unpleasant experience for the user to be told their bug is invalid without any information about how to get more information beyond "search LP".
<seb128> I've decided to let users look for number when I don't find those quickly
<alex-weej> seb128: and i can't find it either.
<seb128> persia: well, having bugs not fixed because I spend my time looking at number rather than working on bugs would not be pleasant for them either
<persia> seb128: Agreed.  I'm just not sure it's not worth leaving the bugs there for others to find the duplicates (and no, the interface isn't ideal for this)
<seb128> alex-weej: that's a known issue, not sure about the bug number
<cjwatson> "subject: [needs-dup] foo" maybe?
<seb128> persia: I've no way to get those out of my way out of closing them, and if I do let the hundred duplicates we get every week on desktop bugs I can as well stop using launchpad
<persia> cjwatson: That sounds like a good idea.
<seb128> cjwatson: we tried tagging those, that goes quickly out of control
<persia> seb128: I understand the feeling.
<alex-weej> seb128: has the bug reporting gotten out of hand lately then?
<cjwatson> with ordinary tags or in the subject?
<seb128> nobody close them and we can't work on the bug lists due to the noise
<seb128> cjwatson: tags
<seb128> alex-weej: yes
<cjwatson> the reason I suggested a subject tag was that it is more visible in bug lists and thus it's easier to ignore those bugs
<cjwatson> I don't find tags very useful for things I need to see in bug lists
<seb128> well, still I don't fancy having lists 3 time longer just because we don't want to close duplicates without looking for exact numbers
<alex-weej> i've been thinking about something that may make it less painful. basically make it so that "users" file problem reports and "developers" can file actual, in-the-code bug reports
<persia> It really waits on LP having a negation feature in searches (one of the features being examined for the next set of milestones)
<cjwatson> another approach that seems to have been successful elsewhere is putting [MASTER] in the subject of bugs that attract lots of dups
<alex-weej> and a problem like "my sound isn't working" is VALID, but is worked out and linked to a set of 5 bug reports
<alex-weej> and you can work on the actual bug reports
<seb128> alex-weej: I usually send those users to the support tracker
<alex-weej> and also, for each in-the-code Bug can see what kind of problems it is causing
<cjwatson> although ISTR from recent mailing list conversation that there's a way to search for bugs by most-duplicated
<alex-weej> seb128: "Answers"?
<seb128> yes
<alex-weej> i agree it is the closest thing
<cjwatson> alex-weej: answers.launchpad.net has that feature set - you can easily promote an answers ticket to a bug
<cjwatson> or demote a bug to a ticket
<persia> (or demote a bug to a question)
<alex-weej> i guess it's just the terminology then
<seb128> we need an extra state: duplicate, somebody needs to look at the number which acts as a closed status ;-)
<alex-weej> see, "my sound isn't working" is something that needs to be fixed, "how do i install skype?" is something that doesn't. yet they both go under "answers" right now.
<seb128> so we don't have those getting in the way of people looking at their bug list
<persia> alex-weej: That lets those more familiar with the system help sort the support requests from the bugs.
<alex-weej> persia: but most of the time a user will know whether it is a support request or a problem report
<cjwatson> alex-weej: many users do not have a reliable ability to distinguish the two, though
<alex-weej> heh
<cjwatson> alex-weej: that's not my experience
<alex-weej> ok
<alex-weej> well you're probably right, my sample size of 1 includes myself
<alex-weej> in that case i suggest a policy of demoting crap bug reports much more often
<cjwatson> it's hard to judge - in many cases it's clear that *something* is wrong with the code, but it's just not clear what
<alex-weej> cjwatson: then it should be a "Problem Report"
<alex-weej> like i said, bug reports should be actually in the code
<persia> alex-weej: It very much depends on the user.  Also "my sound isn't working" isn't a useful report.  "OpenAL isn't working with pulseaudio" or "No sound with Al4827 codec in ALSA" are good bug reports, one of which might be extracted from "my sound doesn't work", but it might also just be "Did you unmute the master volume?"
<alex-weej> persia: even the last case is a bug. why is master volume muted?
<cjwatson> perhaps because the user muted it and forgot :)
<alex-weej> and i don't expect anyone who isn't a geek to know what an Al4827 codec is
<persia> alex-weej: Some BIOSes do that, also sometimes it was muted before, and the settings were preserved.
<cjwatson> I mean, a good percentage of the times I complain about broken wireless at the start of a UDS, it turns out to be that I'd forgotten to turn my RF-kill switch back off after the plane trip
<persia> There's a page on the wiki that talks about collecting information on sound bugs that would specify that (it's in /proc/asound/cards)
<alex-weej> i will give you a personal experience. i know my way around linux, ubuntu and gnome fairly well, but sometimes i will report a bug, have it marked as a duplicate of some other bug report that is the same bug but another manifestation
<alex-weej> and the problem is that the ifnormation i provided is then lost
<alex-weej> and i suddenly have no idea what this other report is about
<alex-weej> a real-world user just wants to know when their problem gets fixed
<cjwatson> FWIW information in duplicate bugs is not lost
<cjwatson> I've very often gone through all the dups when fixing a much-duplicated bug looking for information
<persia> It may be that someone needs to review the duplicates and ensure the master bug contains the most useful information.
<cjwatson> so it's neither lost in theory nor in practice
<cjwatson> although it's true that it's basically lost if you don't link the bugs
<alex-weej> right, but i'm saying if you can have one person with knowledge of the systems file a proper bug report that says "the al4827 codec is broken" and then link all of the user-generated problem reports
<alex-weej> it might be easier to manage for the users who generated those reports and the people who have to actually fix the code
<persia> alex-weej: Which is precisely the relationship between answers.launchpad.net and bugs.launchpad.net
<alex-weej> persia: answers should be renamed then
<persia> (or if it isn't then that is itself a bug)
<alex-weej> when something is broken, i don't want an answer, i want it to be fixed
<alex-weej> also crash reports
<alex-weej> they should not be bug reports
<alex-weej> they should be problem reports
<cjwatson> alex-weej: I believe the preferred way to do that (as demonstrated by the way the system's designers use it) is to edit the description of whichever bug you use as a master, to describe the problem in a more developer-friendly way
<cjwatson> rather than just leaving the description in place and adding a comment
<alex-weej> i have been doing that in some cases
<alex-weej> but then the comment trail makes no sense
<cjwatson> it works for me
<alex-weej> because people think it is just a forum thread
<alex-weej> yeah it's not too bad
<alex-weej> but i still think there are too many people using bugs. too often (myself included)
<alex-weej> if i get a crasher, i just want to log it somewhere
<alex-weej> i don't want to have to explain what i was doing or search for duplicates en-route
<seb128> alex-weej: why should I bother looking for the duplicate number of the submitter doesn't bother doing that before opening the bug ;-)
<alex-weej> i mean it has gotten so bad we turn OFF apport now for final release
<alex-weej> cause the volume is so insane
<cjwatson> you say that as if it's new :)
<seb128> right, there is over 3000 apport crash bugs not triaged in launchpad
<pitti> cjwatson: it was quite alright in, say, october 2004 :)
<alex-weej> seb128: because you can't expect the user to know what a SIGSEGV is, and it would help people trying to fix the original bug
<cjwatson> we always knew that crash bugs ought to be handled by a separate crash database, but needed to work with what we had
<alex-weej> cjwatson: what's wrong with answers?
<cjwatson> I doubt that the set of people doing most of the work with answers at the moment would have a clue what to do with crash reports
<alex-weej> right
<seb128> alex-weej: the bug tracker main use is to allow people who do the work to know the issues and to work on those
<pitti> also, a crash is a real bug, not a support request
<cjwatson> they're often much better handled by developers, although the volume is ... unfortunate
<alex-weej> pitti: negative, a crash is a manifestation of a bug
<pitti> it wouldn't fix the problem, just move it
<alex-weej> there should only be one bug
<seb128> alex-weej: as the maintainer if I say that I know about the issue and that I don't need an another bug why should I let the bug open?
<alex-weej> and all of the crashes should be linked to it
<pitti> alex-weej: well, most reports are "manifestations"
<alex-weej> pitti: exactly what i'm trying to move away from
<alex-weej> because it's making seb's life a misery
<pitti> alex-weej: that's why we aim for good auto-duplication
<pitti> alex-weej: but yes, I see what you mean, but there's no real difference to what users report
<pitti> if they report the same problem n times
<alex-weej> i don't see why the first report is the best, i see all the (problem|crash) reports as being individually useful for fixing actual bugs
<pitti> we don't have a policy of always using the first bug as master, to the contrary
<alex-weej> also we sometimes use the number of duplicates as a metric for how important a problem is to fix
<alex-weej> yet we actively discourage people from filing duplicates at the reporting stage
<pitti> we usually use the best-described bug as the master
<alex-weej> if we let people report their own set of problems we could have a useful measure
<pitti> alex-weej: no, we wouldn't
<alex-weej> pitti: right, but that's something which can only be judged by a human, not an "auto-dup" robot
<cjwatson> no we wouldn't, we'd just have a bajillion problem reports that nobody would ever be able to triage
<cjwatson> there has to be some kind of input filtering, otherwise you're just rearranging the deckchairs
<pitti> alex-weej: since we can't even keep up with precisely duplicating the current number of bugs
<alex-weej> but it doesn't take bug fixers to triage them
<alex-weej> it just takes monkeys or robots
<alex-weej> and the user gets to keep track of his own issue
<pitti> alex-weej: no, it reuqires a fair amount of developer experience in many cases
<cjwatson> if you have monkeys or robots dealing with problem reports, you'll get a corresponding quality of problem report handling
<pitti> if a monkey could do it, LP could do it itself
<cjwatson> there will be a very substantial degree of inaccuracy, and our ability to assess the actual bugginess of Ubuntu would get significantly worse
<pitti> so we should make it much easier to find duplicates right from the start
<cjwatson> and users will be angry because their report is being dealt with by an idiot
<pitti> less bugs -> more developer time per bug to spend on
<cjwatson> that does nobody any good
<alex-weej> pitti: i don't think it will EVER be possible for my mum to file a crash report properly
<alex-weej> and i don't think it should be
<alex-weej> that includes checking for duplicates
<pitti> alex-weej: crash reports are actually the easier ones
<pitti> they are highly structured, and we *can* (and have) a monkey dup'ing them
<cjwatson> actually, I've got lots of crash reports filed by people who have no idea what they're doing that are the easiest bugs to address
<alex-weej> i suppose now we have your stack trace resolver thing
<pitti> alex-weej: and we don't need a real description for them
<cjwatson> backtrace, it's clear what's going on (sometimes), bingo, fixed
<cjwatson> two minutes
<pitti> alex-weej: the non-crash bugs are a much more difficult problem
<pitti> alex-weej: I'm inclined to say that we have perfect crash handling for Python crashes; sigsegv crashes suck a bit, due to dbgsym/local version/current version skew, but at least we have some automatic support there
<alex-weej> i've never actually dealt with a python crash
<cjwatson> the best thing I ever did for ubiquity was turning on automatic crash reporting for it
<alex-weej> does it just catch exceptions that bubble all the way up?
<cjwatson> we hoovered up so many bugs as a result
<pitti> alex-weej: right
 * alex-weej had better fix his application
<alex-weej> :P
<pitti> nice thing is that I get a lot of apport crashes filed through apport as well :)
<cjwatson> you can still log the crash separately or whatever if you want with a top-level exception handler; just re-raise the exception when you're done
<cjwatson> ubiquity spits it to syslog, invokes pdb if requested and sane, raises the exception if apport is present, otherwise displays a dialog box with the exception and then exits
<alex-weej> i just have these utopian visions
<alex-weej> an email from launchpad
<alex-weej> "you know that pommed crasher you got last week? the bug causing it was fixed today."
<cjwatson> even if the crash is hard to understand, it's a million times better than "uh, the installer vanished on me and I don't know what to do" which is what I got before
<alex-weej> yeah i don't think there's any dispute there cjwatson :)
<cjwatson> and users *do* get "you know that installer crasher you got last week? the bug causing it was fixed today" e-mails
<cjwatson> although since it's the installer it may not be practical for them to make use of the fix for a while, but still
<pitti> it does work pretty well for desktop apps
<pitti> reporter gets mail, dist-upgrades, is happy
<pitti> and can immediately file the next crasher which gets uncovered then :)
<alex-weej> right
<alex-weej> but say there were 5 different crash conditions caused by a single unchecked buffer or whatever
<pitti> that's actually pretty rare, although possible, of course
<alex-weej> oh is it
<pitti> alex-weej: well, it's definitively a problem
<alex-weej> well anyway, i just see a massive difference between "Pommed crashes with SIGSEGV in ...." and "buffer overflow in yadda yadda"
<pitti> alex-weej: but we can't expect users and most developers who file a bug to know that :)
<alex-weej> perhaps not
<alex-weej> i am just a bit angry that seb128 is "overworked"
<seb128> I don't see the issue with being agressive in bugs closing
<seb128> we have way more issues than we will fix anyway and they come faster than we fix those
<seb128> so closing bugs we judge not useful should not be an issue
<alex-weej> look man you said yourself you can't find the report so you gave up
<seb128> there is no need to accumulate bugs we know we will not likely do anything about
<alex-weej> and you're the one who has seen it before
<alex-weej> i've never seen it before
<alex-weej> and i've looked, and i can't find it
<alex-weej> if i go to the effort of filing a bug it's because i want to see Ubuntu improved for everyone
<seb128> alex-weej: we have currently almost 6000 desktop bugs open, I expect we close more than that and I read all the bug mails I get usually
<alex-weej> and for me to lose track of that is very demotivating
<alex-weej> and I'm not even on Canonical's payroll!
<seb128> alex-weej: which means I read like 35 000 desktop bugs
<seb128> finding something there is not always easy ;-)
<seb128> alex-weej: to be honest I'm not sure there is a specific bug about your issue, there is for sure about having GNOME, evolution and the clock applet sharing clock settings, which I consider the same issue
<alex-weej> and GDM
<cjwatson> alex-weej: all I'm saying is that there are some things which appear tempting as solutions, but that in fact would make things more difficult for developers
<cjwatson> alex-weej: nevertheless, various other attempts to address the bug problem are right at the top of Ubuntu's priorities for Launchpad development
<seb128> alex-weej: gdm is a trickier question because that's not an user setting, what if 2 users on the same box user different options?
<cjwatson> I haven't been intimately involved in that so can't tell you the details
<alex-weej> seb128: systemwide settings are not that hard to conceive
<alex-weej> well, they are in GNOME because we just happily reinvent everything within a desktop session
<seb128> alex-weej: right, 12-or-24 should be a gconf key with a schemas default, a way for sysadmin to change the default and then user settings
<seb128> alex-weej: the new gdm will make easier to solve that since it uses gconf
<pitti> I think gdm uses the format defined in the locale
<seb128> pitti: as does the clock applet
<seb128> but some locales allow 12 or 24h
<alex-weej> the clock applet has a 12-24h choice in its preferences
<pitti> there are some 12 hour bugs against langpack-locales, but none for en_GB
<alex-weej> now if the option was "Default, 12hr, 24hr" then that would make sense
<alex-weej> but somehow it's just 12hr, 24hr
<alex-weej> so i'm nto sure how it uses the locale
<alex-weej> seeing as gconf defaults are static
<slangasek> pitti: which "format defined in the locale"?
<seb128> pitti: the bugs are for locales which don't allow to choose between 12h and 24h
<slangasek> there are some really insane default time formats in locales :)
<seb128> slangasek: am,pm or 24
<slangasek> ah, is that discretely queriable?
<pitti> slangasek: the locale defines the strings for "AM" and "PM"
<slangasek> pitti: my question was really about what format string one would use to strftime(), and apparently it's %X
<slangasek> IME, %c gives crazy results though
<cjwatson> kirkland: the only problem I see with your grub-installer patch is that you call the write_grub function before it's defined ...
<slangasek> I tried to make freetds use %c for the default datetime format once; this was a source of Bugs
<cjwatson> kirkland: I'll just fix that in the obvious way
<slangasek> because %c in en_US was mapped to a format that NO ONE uses
<alex-weej> also we still have monospace legacy crap in those date formatting functions :/
<alex-weej> check out the date now
<alex-weej> "ThuÂ·Â·7Â·Aug"
<alex-weej> on Sunday it will be "SunÂ·10Â·Aug"
<pitti> the German one doesn't look very good as well
<seb128> slangasek: date +%p
<alex-weej> we need steve jobs to rule over us and not let us release until everything looks spot on :P
<seb128> slangasek: that's doing something or not, depending of the locale
<slangasek> seb128: but I don't think that's what you want, because there's no format string for "give me the hour in 24 or 12 hour time, according to the locale preference"
<slangasek> seb128: except for %X, which gives you the whole time string
<cjwatson> kirkland: I'm concerned that re-running grub-install after installation will break, though
<cjwatson> kirkland: so I don't think this is a viable long-term solution, but it may do for the short term
<pitti> slangasek: closest I found is +%r
<pitti> $ LANG=en_US.UTF-8 date +%r
<pitti> 08:00:06 PM
<pitti> $ LANG=de_DE.UTF-8 date +%r
<pitti> 08:00:15
<slangasek> ah
<pitti> the latter is wrong, of course, becaue de doesn't have am/pm
<seb128> slangasek: that's what the gnome-panel do:
<pitti> but for a test it might suffice
<seb128>         am = nl_langinfo (AM_STR);
<seb128>         return (am[0] == '\0') ? CLOCK_FORMAT_24 : CLOCK_FORMAT_12;
<slangasek> seb128: right, that seems kludgy to me :)
<slangasek> the app shouldn't assume that empty AM_STR implies 24-hour time; maybe my locale uses a 12-hour clock and revels in ambiguity :-)
<pitti> slangasek: but that's pretty much what locales does
<infinity> slangasek: A locale with a 12 hour clock and no am/pm indicator is broken anyway.
<pitti> if you define t_fmt_ampm, then it uses AM/PM, otherwise 24 hours
<pitti> unfortunately locales definitions don't have a concept of "alternative nonpreferred 12 hour format"
<pitti> infinity: like every wall clock? :-)
<infinity> pitti: Wall clocks don't tend to be driven by locales. :)
<pitti> infinity: well, they are just kind of hardcoded :)
<pitti> (especially the ones with a calendar)
<infinity> Anyhow, I figure we're stuck working with what we have, unless someone feels like upending the locale world by always specifying an am/pm format string, and introducing a new 24_hour_preferred boolean.
<pitti> I got interesting bugs about that already
<slangasek> lifeless: do you have an LC_TIME for your Latin locale yet, that numbers the hours from sunrise instead of from midnight? ;)
<slangasek> infinity: don't you repress me!
<pitti> I added some locale patches because some es_MX people said they want it that way, and the next week some others told me it was wrong :)
<slangasek> pitti: oh, well, I still think gnome-panel shouldn't have to duplicate the logic then
<infinity> slangasek: Calling locales ugly is about as useful as calling Roseanne fat, unless you have some magic plan to fix either. :P
<slangasek> (but yes, not a high priority to fix)
<pitti> slangasek: LC_CTIME=la.UTF-8 date -> XIV:LIX ?
<slangasek> pitti: hahaha
<pitti> slangasek: ack for not duplicating, yes
<pitti> slangasek: but I pretty much gave up on applying those now, it's utterly hard to get them past Ulrich
<pitti> seb128: yay gnome bug 544554
<ubottu> Gnome bug 544554 in general "ssh agent doesn't work correctly" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=544554
 * pitti checks out svn head and tests
<ScottK> slangasek: Urgh.  I'll look into it.
<slangasek> ScottK: cheers :)
<cjwatson> davidm,lool: I've just uploaded a debian-installer package with support for lpia. Once it builds, you should at least be able to attempt netboot installations if you can get the thing to boot over the network, or boot the netboot mini.iso somehow
<slangasek> 691M    daily-live/current/intrepid-desktop-amd64.iso
<slangasek> man, libgweather-common is just awful :)
<pitti> slangasek: s/ful/some/ in the current state :)
<slangasek> well, I still need to graft in gettext to make it truly awesome... :)
 * pitti does sudo dpkg -P gnome-volume-manager and whistles happily
<slangasek> the changes to the C code are ridiculously simple, just replace two calls to ..._get_localized_value() with _(..._get_value())
<pitti> slangasek: nice
<pitti> slangasek: does it even define a gettext domain already, or do we need to invent one?
<slangasek> but now I have to pull in the correct gettext glue :)
<slangasek> probably have to invent one
<pitti> slangasek: you probably have to use dgettext() instead of _(), though
<slangasek> ah, probably
<pitti> slangasek: since the general application gettext domain will differ from the one for the cities
<slangasek> yep
<pitti> rocking! that patch fixed gnome-keyring for ssh
 * pitti uploads
<alex-weej> if i leave any VM's running, my machine fails to suspend
<alex-weej> and i have to hard reboot
<alex-weej> anyone know anything about this? bug has been open for a few weeks now without any comment
<alex-weej> this is with the "supported" KVM/virt-manager stuff
 * slangasek frowns.  Ok, I know I saw an existing textdomain name for the location strings /somewhere/, why can I not find it now?
<slangasek> ah, I was looking for 'gnome', and the header just says 'weather-locations'.
<slangasek> pitti: do you think 'weather-locations' is ok for a textdomain, or should I change it to 'gnome-weather-locations'?
<pitti> slangasek: I'd use an appendix to libgweather's already existing one
<pitti> slangasek: like "libgweather-locations"
<lool> cjwatson: Oh rocks, I had a local tree with the beginning of lpia support, but I was waiting for the kernel udebs which were blocked by a lpia kernel tree in intrepid -- I'm glad you already implemented all this, I guess you have a similar config as for amd64?
<pitti> slangasek: but yeah, it's bikeshedding
<slangasek> pitti: hmm, I'm not finding where *that* is defined either :)
<pitti> slangasek: usually it's defined in configure.in as GETTEXT_PACKAGE=
<slangasek> ah
<pitti> if not, it should be in po/Makefile.in.in
<pitti> but usually that just has
<pitti> GETTEXT_PACKAGE = @GETTEXT_PACKAGE@
 * slangasek nods
<pitti> slangasek: so you could do dgettext(GETTEXT_PACKAGE "-locations", str) perhaps?
<slangasek> yeah, it's in configure.in; I think best practices may have drifted slightly since the last time I gettextized something :)
<seb128> pitti: he, you start fixed GNOME faster than me now? ;-)
 * seb128 hugs pitti
<pitti> seb128: leave me the victory of being faster than you ONCE :)
 * pitti hugs seb128
<seb128> good to get this one fixed
<seb128> now I just have to fix seahorse to get the gpg-agent working again
<pitti> actually the gpg one is more annoying, but that one was nasty as well
<pitti> seb128: please appreciate my nice patch header :)
<seb128> well the gpg one is trivial to fix
<seb128> pitti: nice ;-)
<ScottK> slangasek: libcrypt-openssl-bignum-perl has an approved MIR (Bug #243266) and all it's depends are in Main, yet it got demoted to Universe on July 11.  Any idea why?
<ubottu> Launchpad bug 243266 in libcrypt-openssl-bignum-perl "MIR for libcrypt-openssl-bignum-perl" [Undecided,Fix released] https://launchpad.net/bugs/243266
<ScottK> That also took out libcrypt-openssl-rsa-perl at the same time.
<slangasek> ScottK: no idea, no
<pitti> ScottK: probably it appeared in component-mismatches back then and wanted to go back
<pitti> so it can just be promoted back now
<ScottK> pitti: Please do (both)
<slangasek> right, probably a race condition between someone approving an MIR and someone else processing component mismatches
<pitti> rather, we promoted them, but nothing was depending on them even several days/weeks later, so they just fell through the cleanup cracks
<pitti> promoted both
<ScottK> Because that was before recommends got pulled into seeds.
<pitti> yep
<pitti> sorry for the confusion
<ScottK> libmail-dkim-perl  is a recommends for amavisd-new.
<ScottK> That's what I get for working ahead.
<ffm|sh> How can I find out what patches were applied to http://packages.ubuntu.com/intrepid/sugar ?
<geser> ffm|sh: look into the .diff.gz
<ffm|sh> geser: thx.
<jcastro> Hi, I've posted 2 mails to ubuntu-devel today that are in the moderator queue if someone could look at them please.
<warren> Hey, which Ubuntu release was the first to contain glibc-2.4 or higher?
<jpds> warren: "rmadison glic" reports: glibc | 2.5-0ubuntu14 |        feisty | sourc
<warren> thanks
<Mez> glic ?
<warren> btw, is Ubuntu using execshield?
<warren> does Ubuntu build all binaries with -fstack-protector?
<pwnguin> warren: i dont think Ubuntu builds "all binaries" with anything
<warren> really, no standard build options?
<pwnguin> there's common build options
<warren> what are the common flags currentyl?
<elmo> warren: exeshield> no
<elmo> warren: -fstack-protector> yes, since 6.10
<elmo> stack-protector's enabled in the gcc spec file
<elmo> so it's global both for ubuntu packages, and source built on ubuntu systems
<warren> ok good.
<kirkland> what does "set -- " do in shell?
<slangasek> sets the contents of your $@ argv array to the empty set
<kirkland> slangasek: and "set -- `foo `" sets your $@ to the stdout of foo?
<soren> Yes.
<kirkland> soren: slangasek: cool, thanks.
<hwilde_> how do you tell if you are running 64b or 32b
<kirkland> hwilde: uname -a
<hwilde> kirkland, I don't see where that tells me tho
<hwilde> Linux Tug-91-1 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i586 GNU/Linux
<kirkland> i586
<kirkland> that's 32 bit
<hwilde> ok now how do you tell if it's 32b desktop or 32b server version
<kirkland> 2.6.24-16-generic = desktop
<slangasek> you check whether you're running gnome? :)
<hwilde> wrong that is server version.
<bardyr> lsb_release -a
<soren> hwilde: Err.. No.
<kirkland> Linux ubuntu 2.6.26-4-server #1 SMP Mon Jul 14 19:19:23 UTC 2008 x86_64 GNU/Linux
<hwilde> that is server version.  I just installed it myself from the server cd
<hwilde> it has no gui
<kirkland> hwilde: ^^^ mine is 64 bit server
<hwilde> it has no ubuntu-desktop
<hwilde> lsb_release -a has no indication it is server version either
<soren> It won't.
<kirkland> hwilde: you can mix and match Ubuntu quite a bit
<slangasek> yes, because the difference between "server version" and "desktop version" is what packages you have installed
<kirkland> hwilde: server kernel, on a desktop machine, vice versa
<soren> Server and Desktop editions are the same except the desktop has more packages installed and uses the -generic kernel.
<hwilde> interesting
<kirkland> hwilde: it's like going to a Chinese buffet with sushi :-)
<hwilde> soren, this is server version but it still says generic
<soren> hwilde: Then you've installed that somewhere down the line.
<hwilde> lol
<soren> hwilde: The server install cd will install the server kernel.
<soren> hwilde: Either you've manually installed the generic flavour after installing ubuntu or perhaps you used the cli install option on the alternate CD.
<soren> The latter will give you the same packages as a server install, but with the generic kernel.
<hwilde> so... dpkg -l | grep desktop   ?
<soren> What about it?
<hwilde> that is how to tell if you have desktop or server version ?
<soren> 22:08:42 < soren> Server and Desktop editions are the same except the desktop has more packages installed and uses the -generic kernel.
<soren> You can't tell the difference, because there is none.
<soren> You can start with the desktop edition, remove all the desktoppy bits, or you can start with the server edition and install gnome.
<slangasek> hwilde: what's the problem you're trying to solve?
<kirkland> (chinese buffet with sushi!)
<slangasek> kirkland: sick, sick man
<hwilde> slangasek, noob complaining their gui is broken.   did they install from server cd
<soren> hwilde: In those cases, what would be the answer to your question?
<hwilde> in those cases the answer would be, you either have not installed or you have removed the desktop packages so there is no gui.
<slangasek> hwilde: if you want to answer the question "did they install from server cd", look in /var/log/installer
<hwilde> ah hah!
<hwilde> syslog:Apr 23 12:18:10 base-installer: info: kernel linux-image-2.6.24-16-server not usable on k6
<hwilde> /var/log/installer/syslog
<hwilde> syslog:Apr 23 12:18:10 base-installer: info: Using kernel 'linux-generic'
<soren> hwilde: If that's your use case, it's a nonsense question. Whether they installed from one CD or the other doesn't matter. What might matter is the presence of the desktop packages.
 * slangasek rewrites that line to say: "k6 not usable as a server" ;)
<lifeless> slangasek: :)
<slangasek> soren: one might legitimately want to know how they got to a particular broken state; e.g., for tracing an installer bug :)
<hwilde> how come anytime people ask something the inevitable answer is you should not be asking that
<hwilde> if you don't want to answer that's fine but there is no need to be like that
<lifeless> slangasek: actually, I have to track down an X complaintt
<soren> slangasek: That's a fair point. :)
<Laney> Can someone unsubscribe ubuntu-archive from bug #252287? AFAICS the request needs an ACK first
<ubottu> Launchpad bug 252287 in wesnoth "Please sync wesnoth 1:1.4.4-2 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/252287
<lifeless> slangasek: $ xterm
<lifeless> Warning: locale not supported by Xlib, locale set to C
<slangasek> hwilde: well, your first question was the wrong question in that there's no hard line between a "desktop" and a "server" install; but we seem to have gotten to the right question and answer now :)
<hwilde> I never knew /var/log/installer existed, so thank you, that explained it
<hwilde> they did install from the server cd
<hwilde> but it installed generic kernel because k6 unusable
<slangasek> lifeless: Xlib SMASH
<lifeless> slangasek: is that humourous or an actual thing I'm unaware of ?
<slangasek> lifeless: :(  maybe it's neither :(
<slangasek> but I think it was trying to be humorous
<lifeless> :)
<slangasek> Laney: unsubscribed
 * slangasek mutters at intltool being uncooperative.  'default' is not a very useful string to search for in aclocal.m4. :P
<Laney> slangasek: Thanks
<hwilde> so... what is k6 ?
<slangasek> an older AMD processor
<LaserJock> are the Athlon XP's k6?
<slangasek> no, the k6 was a 32bit-only proc
<slangasek> oh, there was a 32bit athlon; but still, no :)
<LaserJock> http://en.wikipedia.org/wiki/List_of_AMD_microprocessors has the answer
<hwilde> model name      : Geode(TM) Integrated Processor by AMD PCS
<hwilde> cpu MHz         : 499.918;   cache size      : 128 KB;  bogomips        : 1006.15
<hwilde> :(((
<hwilde> too slow to run the server kernel
<hwilde> this make me want to cry
<slangasek> not speed, instruction set
<LaserJock> hwilde: is the server kernel needed on that machine? I can't imagine it would be
<hwilde> I think my phone is faster
<hwilde> 128K cache cmon
<hwilde> this isn't even worth it.   thanks for all your help /var/log/installer is gold
<hwilde> LaserJock, I just had five different people tell me there is no difference except the packages
<LaserJock> hwilde: well, the server and generic kernels are different packages :-)
<hwilde> yeah, I want the server kernel... why would I download the server cd and go through the whole install just to have it downgrade to generic :/
<LaserJock> it's *not* a downgrade
<hwilde> ok
<LaserJock> well, I guess it is if you have a lot of memory
<elmo> it's not a downgrade because the -server kernel _doesn't work on this hardware_
<hwilde> failover
<hwilde> fallback
<hwilde> default
<hwilde> whatever
<LaserJock> the generic kernel should be fine though
<hwilde> it's not the kernel I intended to install is the point.
<LaserJock> well, that's too bad for sure, but shouldn't make any difference on that machine
<hwilde> slangasek, what is it about the instruction set that is incompatible
<slangasek> hwilde: er, "it's too old"?
<slangasek> the k6 is an earlier generation of chip
<slangasek> the server kernel is targetted to a newer instruction set
<hwilde> man this sucks.  I can't quite get ubuntu running perfectly.   it is obviously the hardware.   but the hw ppl counterargument is that xp embedded runs fine :/
<slangasek> dude, if Ubuntu isn't running, that has nothing to do with whether it's using the server or generic kernel
<hwilde> its runs fine but has a few bugs.  i just tried the server version to see if it would be a little better
<hwilde> * attempted to try
<wgrant> The server version is just a different set of default packages...
<hwilde> wow you're not kidding about old... First Introduction, Apr 2, 1997 (K6 166, 200 and 233 MHz)
<hwilde> there are really only three issues, but they are all traced back to the amd chipset
<hwilde> 1)  random power button presses.   fixed with acpi=off
<hwilde> 2)  sounds stutter   https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131439
<ubottu> Launchpad bug 131439 in linux-source-2.6.22 "No sound with AMD DeviceCS5536 [Geode companion] Audio" [Medium,Confirmed]
<hwilde> 3)  usbs randomly disconnect and reconnect   (no clue)
#ubuntu-devel 2008-08-08
<timothywcrane>  are there by any change some ubuntu core-dev in here? I have 2 fixes for the repos concerning Sauerbraten. (It cannot get futher updates without these fixes)
<timothywcrane> I will be first to admit, my tactic of the day is begging
<timothywcrane> it is in bug report. But I wanted to give asking a shot
<timothywcrane> but only core-dev can upload
<Adri2000> timothywcrane: are you sure this package is in main.
<Adri2000> ?
<timothywcrane> fixes on launchpad board
<timothywcrane> no it is not
<Adri2000> then you need a motu, not a core-dev
<Adri2000> -> #ubuntu-motu
<timothywcrane> motu?
<timothywcrane> thanks
<timothywcrane> there now, thxamill
<lucas> how can I know why ruby1.9 was moved from universe to main?
<Burgundavia> ask the security guys
<lucas> what do the security guys have to do with that decision?
<stealth`gentoo> hi all
<stealth`gentoo> i have this BIG problem
<stealth`gentoo> http://91.121.166.117/ -> i don`t see index.php
<stealth`gentoo> but i donwload it.
<stealth`gentoo> Who can help
<tormod> stealth`gentoo: wrong channel
<stealth`gentoo> sir tormod - i have asked on my IT language channel and on #ubuntu ...
<stealth`gentoo> more person ask me to enter here ...
<stealth`gentoo> so =p i want a simple help
<RainCT> stealth`gentoo: do you have libapache2-mod-php5 installed?
<stealth`gentoo> yes dude
<RainCT> stealth`gentoo: I get The requested URL /index.php was not found on this server.
<RainCT> stealth`gentoo: is the index caled .php or .phtml?
<stealth`gentoo> RainCT wait i create it
<wgrant> lucas: Because somebody decided that we wanted ruby1.9 rather than ruby1.8 in main, perhaps!?
<stealth`gentoo> index.php
<slangasek> RainCT: would you mind taking this to #ubuntu?  I really can't imagine that this is the result of an Ubuntu bug, so it's really off-topic here...
 * wgrant gives stealth`gentoo a hint before he leaves: don't expose phpMyAdmin to the web.
<stealth`gentoo> wgrant don`t found :D
<stealth`gentoo> ghgh
<RainCT> I'm about to leave anyway, good night
<stealth`gentoo> have you fun RainCT.
<stealth`gentoo> so - nothing help.
<slangasek> stealth`gentoo: whoever directed you to this channel has done so in error; I'm sorry, I don't know why they've done that, but as the topic states, this is not a support channel
<stealth`gentoo> Ok sir or madam, no problem.
<stealth`gentoo> I only tell sorry me for inconvenienze and for disturb.
<stealth`gentoo> Have you fun all :P
<stealth`gentoo> kiss
<emgent> persia: can you take a look in freqtweak merge debian/copyright ?
<emgent> debian people remove your reference
<lifeless> slangasek: ping
<lifeless> slangasek: I wanted to ask your opinion; I'm thinking of starting a thread about config files - all the ones with comments and explicitly-set-to-the-default values
<lifeless> slangasek: I think they are harmful and all such things should be in foo.default files; which the user never edits - this would massively reduce upgrade conflicts for foo.
<slangasek> lifeless: there are two reasons I find default config files useful; first, for improved discoverability (what is the config file for foo?  what are the options I need to edit?), and to get file permissions on the config file right when they need to be something other than the system default
<lifeless> slangasek: I'm not saying remove default config _files_ I'm saying remove 'foo=bar' and '# foo=bar' and '# this does xxx' from the file contents
<infinity> Not to be an elitist or anything, but if people are editing config files, they should be able to deal with conflicts.
<lifeless> slangasek: see for instance squid.conf and squid.conf.default
<lucas> wgrant: well ruby1.8 is in main too, and 1.9 is a development version
<infinity> Or, to put it the other way, if our "normal" users need to edit config files, we messed up.
<lifeless> infinity: they do
<slangasek> lifeless: ah, yes, I agree that explicitly setting defaults in config files is silly
<lifeless> infinity: we've messed up systematically across the board
<slangasek> (the samba package has recently been cleaned up in this regard)
<slangasek> well
<slangasek> ok, not quite
<slangasek> we're not /setting/ default values any more, but we do include some comments for documentation purposes...
<lifeless> I just did fisty->gusty->hardy
<lifeless> and had way too many conflicts on files that I'd either never edited, or the conflict was the maintainer fixing a typo and causing several hundred lines of region to resolve
<lifeless> Trivially,
<lifeless> # comment
<lifeless> setting = chosen-value
<elmo> lifeless: conflicts on files you didn't edit is always a packaging bug somewhere
<lifeless> will - even in three-way merge - conflict if the comment has a typo the maintainer (or upstream) fix *and* the user has changed setting
<slangasek> maybe we need better three-way merging? :)
<lifeless> elmo: there are/(were?) a bunch of packages that get values set into config files from debconf; so 'never edit' doesn't mean 'never specified' :/
<slangasek> lifeless: anything that's populated by debconf is not allowed to be a conffile
<lifeless> slangasek: presumably I ran into bugs then
<slangasek> I guess so; bugs I haven't seen myself, fwiw
<lifeless> anyhow; speaking as a VCS head the easiest way to avoid spurious conflicts is to have unrelated data in separate places
<infinity> Or, someone using the ever-fun debconf + ucf combination and messing it up.
<slangasek> infinity: ucf == lurv
<infinity> slangasek: When properly used, yes. :)
<infinity> slangasek: Some people don't quite seem to grasp the concept.
<slangasek> right, such as the nfs-kernel-server maintainer :/
<slangasek> lifeless: I as a user find having comments in the default config file /very/ helpful to me; having to context-switch between two files, or a file and a manpage, is irksome
<slangasek> it would really be nice to have a better three-way-merge algorithm in ucf...
<lifeless> slangasek: honestly, I think its off into AI land to fix it as it stands via 'better merge'
<lifeless> the squid config file is a particular good example
<slangasek> hmm :(
<lifeless> I'm pretty sure we stopping shipping a long config upstream years ago
<lifeless> and we now ship a small active config
<lifeless> with a .default that documents everything
<lifeless> 140K of config file is not a sane thing to inflict on users
<slangasek> true
<lifeless> just checked, we switched to squid.conf.default at least 3 years ago
<lifeless> so the question is, does the peanut gallery here think this is a semi-sane suggestion, if so I'll take it to the list(s) for larger discussion
<lifeless> if not, I'll just bitch and moan at every release
<lifeless> :P
<slangasek> using samba again as an example, the config we ship is 12K, and includes a very limited subset of all available options - the ones that a user is likely to need to tune
<lifeless> how much of that is documentation and manually listing default values?
<slangasek> lifeless: if you bitch and moan /before/ the release, I'll be very happy to smack anyone who's caused a conflict prompt on an unedited config file
<slangasek> $ grep -c '^[;#]' /usr/share/samba/smb.conf
<slangasek> 216
<lifeless> slangasek: production servers at home -> I always upgrade afterwards
<slangasek> $ wc -l /usr/share/samba/smb.conf
<slangasek> 312 /usr/share/samba/smb.conf
<lifeless> so 2/3 rds of that file are comments which are subject to being wrong and thus causing conflicts
<lifeless> :)
<slangasek> sure
<slangasek> which is why I'd like a better merge algorithm :)
<slangasek> but while we could strip all the comments out of the default config, that would leave users without the guidance that we, and upstream, are trying to provide with the examples and comments
 * Hobbsee wishes for intelligent merging.
<Hobbsee> i'm getting bored of modifying the blacklist every single time.
 * LaserJock often wishes for intelligence but doesn't often find it
<lifeless> slangasek: I disagree aout the guidance thing
<lifeless> slangasek: a simple two-liner never-changed comment at the top of the file can refer users to comprehensive documentation and examples
<RAOF> lifeless: But I, at least, find it much more convenient to have a nicely commented hugely redundant config file to start with.
<lifeless> slangasek: certainly as an upstream [squid] I want Debian and Ubuntu to ship squid.conf.default and use squid.conf for only active set values
<lifeless> RAOF: are you serious? or taking the piss?
<RAOF> lifeless: I'm serious.  I find them useful.
<lifeless> do you remember the gutsy cycle tracker config file?
<RAOF> No?
<lifeless> massively long config file full of explicit defaults and comments most of which were totally pointless and something the program would have to change in future anyhow
<lifeless> anyhow, no huge 'yes this works' reaction, so I'll leave it alone for now
<lifeless> all of you, go admin 10 or 20 squid servers with squid.conf.default as your starting config file.
<RAOF> Right.  I'm aware that there are downsides to a hugely verbose over-specific default conifg file, I'm just saying that I find them useful.
<lifeless> come back to me when you've seen the light
<RAOF> My finding them useful shoudln't inhibit someone from changing the way config is done, though.
 * Chipzz wishes for a "resolve differences manually" option (for example through vimdiff) option when there are conflicts in config files
<Chipzz> slangasek: my opinion on the default settings is: can be quite usefull. I had to do an emergency migration from docvecot to courrier a couple of weeks ago on a server, and courrier config files ship with the default options commented out, which helped alot in getting it up and running faster
<Chipzz> also, in the case where there is no man page for the config file (which would be a bug in itself though) the default settings and comments *are* the documentation
<Chipzz> I guess this is often the case for files in /etc/default/; only other option is to look at the init-script itself then
<slangasek> well, it's a shame that ESR was the one to say it, because he got it right - if the user has to consult the documentation to find out how to do what they need to do, you've failed
<slangasek> (unless they're trying to do something *really* uncommon)
<Chipzz> some things are just inherently complex, and hence inherently require reading documentation
<slangasek> gcc is inherently complex, but users can do a lot with it without having to consult gcc documentation :)
<Chipzz> depends on your pov I guess ;)
<LaserJock> hmm, I don't think I've ever read documentation for gcc itself
<Chipzz> slangasek: btw, I was reading my backlog earlier and saw your griefs about the CD size
<Chipzz> now I don't have any personal experience with that
<slangasek> which round of them? :-)
<Chipzz> but there are still some things in a default ubuntu installation which shouldn't be there by default IMO
<Chipzz> for example, some packages ship .devhelp files in non-development packages
<lifeless> Chipzz: so I'm saying have the docs, but in separate files
<Chipzz> lifeless: at which point I need to have 2 editors open, and constantly switch between them
<Chipzz> not very convenient
 * lifeless hands Chipzz vim
<Chipzz> lifeless: I use vim. extensively. but in most cases I have only one file open in vim
<Chipzz> never really quite got the hang of using multiple buffers extensively
<lifeless> I know, we could put every single config in the system into one big file :)
<lifeless> and call it the registry
<Chipzz> and still, having 2 files open in 1 vim still requires a mental context switch
<lifeless> :vsplit
<lifeless> is your friend
 * RAOF is more a fan of C-x 3, but whatever floats your boat.
<LaserJock> Chipzz: how big are devhelp files?
<LaserJock> I can't imagine them taking up very much space
<slangasek> Chipzz: huh, interesting, good point; the devhelp files do seem rather small, though
<slangasek> so I think cleaning that up is more a conceptual cleanliness thing rather than a space-saver
<Chipzz> LaserJock: hrrrm not too big apparently; 50KB'ish
<Chipzz> slangasek: I brought up the issue with seb128 in the past already
<Chipzz> he didn't seem too interested in fixing it
<Chipzz> those are some offenders:
<Chipzz> -rw-r--r-- 1 root   root    7921 Sep 17  2007 /usr/share/gtk-doc/html/bonobo-activation/bonobo-activation.devhelp
<Chipzz> -rw-r--r-- 1 root   root    8634 Sep 17  2007 /usr/share/gtk-doc/html/bonobo-activation/bonobo-activation.devhelp2
<Chipzz> -rw-r--r-- 1 root   root   59312 Oct 22  2007 /usr/share/gtk-doc/html/evince/evince.devhelp
<Chipzz> -rw-r--r-- 1 root   root   66496 Oct 22  2007 /usr/share/gtk-doc/html/evince/evince.devhelp2
<Chipzz> -rw-r--r-- 1 root   root   22545 Sep 18  2007 /usr/share/gtk-doc/html/gdict/gdict.devhelp
<Chipzz> -rw-r--r-- 1 root   root   26253 Sep 18  2007 /usr/share/gtk-doc/html/gdict/gdict.devhelp2
<Chipzz> -rw-r--r-- 1 root   root   54983 Sep 17  2007 /usr/share/gtk-doc/html/libbonobo/libbonobo.devhelp
<Chipzz> -rw-r--r-- 1 root   root   60917 Sep 17  2007 /usr/share/gtk-doc/html/libbonobo/libbonobo.devhelp2
<slangasek> Chipzz: send patches? :)
<Chipzz> -rw-r--r-- 1 root   root    8990 Sep 19  2007 /usr/share/gtk-doc/html/pygtksourceview2/pygtksourceview2.devhelp
<Chipzz> -rw-r--r-- 1 root   root   52236 Apr  7  2007 /usr/share/gtk-doc/html/rhythmbox/rhythmbox.devhelp
<Chipzz> -rw-r--r-- 1 root   root   58543 Apr  7  2007 /usr/share/gtk-doc/html/rhythmbox/rhythmbox.devhelp2
<Chipzz> slangasek: the issue was more an issue about seb128 not wanting to create seperate packages for them
<Chipzz> and
<Chipzz> they were in -common packages for example
<Chipzz> which are arch-independant
<slangasek> why would you need separate packages, instead of shipping them in the -dev packages?
<Chipzz> moving those files would increase package sizes of arch-dependant packages
<Chipzz> slangasek: well currently there is no policy on where to ship them
<slangasek> it would increase the package sizes by, what, 2K compressed?
<Chipzz> -rw-r--r-- 1 root   root    4943 Sep 17  2007 /usr/share/doc/libbonoboui2-common/html/libbonoboui.devhelp.gz
<Chipzz> -rw-r--r-- 1 root   root    5040 Sep 17  2007 /usr/share/doc/libbonoboui2-common/html/libbonoboui.devhelp2.gz
<Chipzz> ^^^ we're not even consistent about the directory we ship them in even
<Chipzz> anyway probably not much of a win... I thought those were bigger
<ion_> tjaalton: Yay for input hotplug! \o/
<Chipzz> slangasek: anyway, I made a list once of all devhelp files and which packages contained them (but that was a while (about a year) ago); I can still send that file somewhere though
<Chipzz> -rw-r--r-- 1 root root 21410 Aug 17  2007 devhelp.list
<Chipzz> heh
<slangasek> Chipzz: to ubuntu-devel, to try to get a consensus?
<Chipzz> just under a year ago apparently :)
<slangasek> it's pretty obvious to me that they ought to be in the -dev packages, but
<Chipzz> well
<Chipzz> in some cases they are in the -doc packages
<Chipzz> in some cases in the -dev packages
<Chipzz> and still other cases in a random package
<Chipzz> now should that be -doc or -dev then?
<slangasek> Chipzz: if the -doc package is documentation for a library, then -doc is suitable; if there's no -doc package, then -dev is suitable; all IMHO
<Chipzz> *nod*; but then the question may popup when it's worthwhile to create a seperate -doc package and when it isn't
<Chipzz> ah well
 * Chipzz goes to sleep
<Chipzz> past 4AM :P
<ion_> ogra: Could you please share your VCS branch for the initramfs-tools packaging, or alternatively something i can dget, so i can implement the percentage thing properly and without stepping on your toes? Thanks.
<Hobbsee> tjaalton: are we going to get a fix for the keyboard breakage soon?
<ion_> hobbsee: Breakage?
<Hobbsee> ion_: yeah.  i upgraded to the latest version, and it doesn't work inside of X.
<ion_> hobbsee: Huh. Could i see your Xorg.0.log?
<Hobbsee> ion_: http://hobbsee.com/tmp/Xorg.0.log
<Hobbsee> i added the server flags after, and restarted X.  but i think that's the first log
<ion_> (EE) Failed to load module "evdev" (module does not exist, 0)
<ion_> That is reeeeally strange.
<ion_> hobbsee: Do you have xserver-xorg-input-evdev installed?
<Hobbsee> ion_: nope
<ion_> hobbsee: Thatâs probably the problem. Something really should depend on it now that input hotplug uses evdev. :-)
<Hobbsee> i presume i need to, and that's the input hotplug?
<ion_> Try installing it and restarting X.
<Hobbsee> right.  yeah, i didn't have -input-all installed
<johanbr> ion_: I have  xserver-xorg-input-evdev and it's still fairly broken for me.
<johanbr> Arrow keys not working, for instance.
<ion_> Xorg.0.log?
<johanbr> ion_: http://nullinfinity.org/tmp/Xorg.0.log
<johanbr> ion_: This seems pretty weird: (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD)
<ion_> johanbr: Ok, i see nothing obvious, but try what happens without an xorg.conf.
<ion_> johanbr: Perhaps there are InputDevice sections or something that interact with input-hotplug badly.
<johanbr> ion_: Alright, I'll give that a try. Thanks.
<emgent> moin
<nxvl> emgent: :D
 * nxvl waves on emgent 
<TheMuso> kirkland: WHy subscribe me to bug 33649?
<ubottu> Launchpad bug 33649 in debian-installer "root raid installs have bad grub config" [High,Confirmed] https://launchpad.net/bugs/33649
<dholbach> good morning
<pitti> Good morning
<nxvl> hi!
<pitti> hey nxvl, how are you?
<StevenK> Morning pitti
<nxvl> pitti: would you like to sponsor one of my package updates into debian and then sync it into ubuntu :D?
<pitti> nxvl: probably not today, I have an ultra-tight schedule today; but I'm happy to do it tomorrow if you mail me?
<StevenK> pitti: You said you didn't care about hppa depends, so libgmime-2.0-2 and libxml++2.6c2a can be NBS'd out
<nxvl> ok
<nxvl> wrinting mail
<nxvl> tomorrow sound perfect for me
<pitti> StevenK: right, in fact that's the very first thing I'm starting with today, to clean up various other lists as well
<StevenK> Yay!
<pitti> StevenK: thanks a lot for your work on that
<StevenK> pitti: Also, compare and contrast, 'rmadison -u debian twin' and 'rmadison twin'
<StevenK> pitti: No problem :-)
<pitti> StevenK: twin> fun
<StevenK> pitti: Fix it? :-)
<StevenK> pitti: When the list looks a little cleaner, point me at it, and I'll shake out another few to do.
<nxvl> pitti: sent
<TheMuso> pitti: Do I have to do somethng other than change a MIR's bug back to new to get it looked at again, or are those who are processing the MIR queue not through/behind with the queue?
<pitti> TheMuso: setting back to NEW is ok, preferably with a comment
<TheMuso> pitti: Right done that, thanks, I'll let you get on with your morning. :)
<pitti> StevenK: "fix"?
<pitti> StevenK: the package is newer in Ubuntu, and nobody filed a removal request
<StevenK> pitti: Only because I fixed it so it wasn't a broken pile of crap.
<pitti> StevenK: ah, that was you? :-)
<StevenK> And then filed a Serious bug in the Debian BTS, which got closed
<persia> StevenK: Isn't it better to file removal requests in those situations?
<pitti> StevenK: so, if you want me to remove it, can do
<StevenK> Now I'm exacting revenge
<StevenK> pitti: Can we remove it, NEW and then remove it again? I'm feeling fairly vindictive toward it
<pitti> lol
<StevenK> Maybe getting elmo to rm the files off librarian would make me feel better
 * pitti NBS-removes 15 packages
<StevenK> \o/
<StevenK> pitti: If you want a removal request, I'll file one, I just thought that since we remove stuff when Debian does, and twin isn't even in *stable*, we could skip it.
<pitti> StevenK: I can remove it right now
<kirkland> TheMuso: hiya, I thought you had grub expertise?
<TheMuso> kirkland: No.,
<kirkland> TheMuso: and I thought cjwatson and evand|vacation were out on holiday
<kirkland> TheMuso: ah, sorry then, feel free to unsubscribe
<TheMuso> kirkland: cjwatson still has Friday left I think, but I know evand is on vacation.
<TheMuso> kirkland: I hear about that bug via the installer bugs anyway.
<kirkland> TheMuso: gotcha...  well, this is more of the make-raid-work-right patches ;-)
 * pitti discovers some cycles in the NBS dependencies and slaughters even more
<StevenK> Whee
<ScottK> pitti: We have a new team you might want to join: https://edge.launchpad.net/~ubuntu-cruft-busters
<slangasek> and then after pitti joins it, be sure to add the group to ~we-love-pitti
<Hobbsee> LOL!
<Hobbsee> that actually exists...
 * StevenK joins
 * StevenK is a pitti fanboi
 * persia fears the high annual membership fee to ~we-love-pitti
 * warp10 reassures persia: first year is free!
<nxvl> actually we should create the pitti-lovers lp team
<nxvl> :P
<Koon> nxvl: isn't that what ~we-love-pitti is ?
 * Koon joins
<nxvl> it actually exists?
<nxvl> i thought it was a joke
 * nxvl joins
<Koon> nxvl: otherwise it wouldn't be as fun
 * StevenK chuckles
 * dholbach thought that's what ~ubuntu-6had was about
<dholbach> "We, who believe Martin Pitt is more powerful than Chuck Norris"
 * Koon is a true pitti fanboy, I've been for years
<dholbach> althought I'm not so convinced about the vehement dislike for CDBS :)
<persia> Chuck Norris doesn't have a chance when faced with a decent collection of NBS.
<emgent> lol
<pitti> tjaalton, bryce: xresprobe wants to go to universe, is that ok?
 * pitti chuckles
<nxvl> mmm that team should be open
<nxvl> i really need to blog about this
<pitti> StevenK: applied for joining cruft-busters; I love to clean up the house :)
<nxvl> will do tomorrow
<nxvl> see you!
<slangasek> dholbach: please see the debdiff against debian/rules in the latest libgweather upload and tell me how much you love CDBS :-P
<StevenK> Haha
<warp10> nxvl: only True Pitti Lovers (TM) can join, we need to check candidates first ;)
<nxvl> heh
<nxvl> :D
<dholbach> slangasek: I didn't say "it's the greatest thing ever", in a lot of cases it just makes things easier :)
<emgent> bad icons..
<emgent> similar to Pirelli :)
<StevenK> dholbach: And in few cases, it makes slangasek cry.
<ScottK> cdbs is really great when it works.
<ScottK> But that's pretty much true of everything.
<StevenK> ScottK: Didn't you go to bed, again?
<slangasek> cry for my Axe of Code Cleaving?
<StevenK> Haha
<ScottK> Still working on it.
<nxvl> cdbs is a nightmare sometimes
<nxvl> i still prefer debhelper
<ScottK> If you want to cry, look at debian/rules for sendmail.
<StevenK> I want to cry, not have my eyes bleed
<nxvl> i don't even want to check a sendmail configuration file
<pitti> StevenK: look at doko's patch "systems" then :)
<pitti> StevenK: e. g. in python2.5
<StevenK> pitti: Dun wanna
<ScottK> nxvl: The debian/rules look like something someone that likes Sendmail CF would write.
<NCommander> pitti, welcome to cruft busters :-)
<pitti> NCommander: thanks :)
<NCommander> I think I birthed something that is quickly going to grow to become an offical MOTU team
<nxvl> ScottK: sendmail added to my black list
<pitti> tjaalton, bryce: discover1 has been removed from Debian,but it's still in Ubuntu main; do we want to keep it?
<NCommander> ugh, what rules looks like sendmail.cf
 * persia has a rule that no CDBS debian/rules with more than 20 lines is acceptable
<persia> (this includes whitespace and comments)
<pitti> tjaalton, bryce: oh, that's not actually your fault, but ltsp's, so never mind
<tjaalton> pitti: right, xserver-xorg no longer needs it
<pitti> tjaalton: what about xresprobe? that can go as well?
<pitti> go to universe, I mean
<tjaalton> yep
<slangasek> --- libgweather-2.23.6.orig/debian/rules
<slangasek> +++ libgweather-2.23.6/debian/rules
<slangasek> @@ -0,0 +1,20 @@
<slangasek> persia: what do I win? :)
<pitti> can't that be fixed in cdbs proper?
<slangasek> pitti: sure, it can be fixed by reverting the change for Debian bug #387103, which you and I both commented on years ago :-)
<ubottu> slangasek: Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387103;mbox=yes)
<persia> slangasek: If you were putting the package for my review, you'd not get rejected for having an unmaintainable debian/rules.
<StevenK> Unmaintainable!?
<slangasek> pitti: I've committed the change already to the cdbs bzr branch, and filed a bug with Debian about it; feel free to review and upload
<slangasek> pitti: I haven't uploaded yet because I wanted more eyeballs on it first
<pitti> slangasek: great, thanks
<pitti> slangasek: libgweather uses tarball.mk?
<slangasek> pitti: no
<slangasek> pitti: understand now my rage :)
<slangasek> the change made *for* tarball.mk broke simple-patchsys use when you need to patch the buildsystem
<pitti> slangasek: hm, did you push? I pulled, and nothing new from you
<slangasek> pitti: hmm, I used debcheckout, let me check
<slangasek> wasn't sure if that would branch or checkout
<slangasek> right, pushing now
<slangasek> done
<StevenK> slangasek: bzr info will tell you
<pitti> slangasek: so if that change works for you in libgweather, I'll test it with a normal and a tarball.mk package
<slangasek> StevenK: yes, I seem to have gotten distracted between the time I ran that command, and the time I should have gone to look at the output :)
<nxvl> ok blogged
<StevenK> slangasek: Haha
<nxvl> pitti: it's now announced, so you will receive an avalance of official fanboys
<pitti> nxvl: argh noo!
<pitti> it's embarassing enough as it is...
<StevenK> Haha
<nxvl> :D
<StevenK> pitti: You've beaten NBS into submission?
<Koon> nxvl: you should have blogged tomorrow, so that we joined one day before everyone else
<pitti> StevenK: I cut a fair dent into it, anyway
<emgent> nxvl: ln -s /usr/bin/sudo /usr/bin/pitti
<nxvl> Koon: for me it's 2 am
<warp10> nxvl: :D
<Koon> heh
<StevenK> pitti: Is the list updated too, or I need to wait for a regen?
<nxvl> emgent: please! pitti is more powerfull that root or sudo!
<pitti> StevenK: needs publisher first, then I can manually regen
<emgent> nxvl: lol
<StevenK> pitti: This run that started ~ 3 minutes ago, or another?
<Koon> emgent: and pitti is not symbolic, he's hard
<nxvl> i need to move to europe, europe mornings are funnier that american ones
<nxvl> ok it's official, my post reached planet ubuntu
<nxvl> dholbach: you've got your team too
<nxvl> dholbach: https://edge.launchpad.net/~dholbach-huggers
<kirkland> does anyone here move hard drives installed with ubuntu around between machines?
<warp10> nxvl: heh :D
<dholbach> hahaha
 * dholbach hugs nxvl and warp10
<dholbach> :)
<Koon> nxvl: you need a logo or I won't join.
<kirkland> i do...  i have a Thinkpad t61p with a 14" screen, and a much smaller x61 with a 12" screen...  the smaller one is *great* for travel, planes, trains, sprints, etc.
 * warp10 hugs back dholbach 
<emgent> warp10: please remove pitti group icon :)
<nxvl> emgent: why?
<nxvl> it's cool
<warp10> emgent: ?
<kirkland> everything works swimmingly, except for my xorg.conf is not portable between the two machines.  one is nvidia, the other is fglrx.  on is 1400x1050, the other is 1024x768
<nxvl> Koon: daniels head sounds good for you?
<emgent> warp10: it`s horrible, similar to Pirelli
<emgent> hahah
<kirkland> i added this to my x11-common: http://pastebin.ubuntu.com/35434/
<kirkland> perhaps I'll talk to bryce about that tomorrow....
<Koon> nxvl: daniels head sounds good to everyone.
<slangasek> kirkland: hrm, why do you have an xorg.conf at all?  that's deprecated
<pwnguin> kirkland: is HAL not appropriate?
<pwnguin> xorg.conf isn't quite dead yet =(
<warp10> emgent: because power is nothing without control
<Koon> warp10: :)
<pitti> slangasek: unfortunately the patch to prefer nvidia on autodetection was reverted upstream after only a day or so
<pitti> kirkland: ^
<kirkland> slangasek: I don't have "an" xorg.conf.... I have 19 :-)
<slangasek> I still have a few, but I'm trying to cut back
<emgent> warp10: lol
<kirkland> pwnguin: hmm, I'm interested, how would HAL solve this?
<ion_> I donât have an xorg.conf. Period. ;-) Now the xorg in Ubuntu does all i need without a conf.
<pitti> slangasek: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=66fb253082ea42179180303393e48846208987fa FYI
<pwnguin> kirkland: based on the laptop id, set a preferred driver?
<pitti> tjaalton, bryce: btw, maybe we should consider applying this in Ubuntu? ^
<pwnguin> uh, wasn't that nuked by xorg?
<persia> kirkland: I know people who move drives like that, although I don't personally.
<kirkland> pwnguin: i'd need to set a preferred driver, and a preferred screen resolution
<pwnguin> pitti: if i recall, upstream soundly rejected that patch
<pitti> pwnguin: yes, reverted because they thought that Thou Shall Not Use Nvidia
<kirkland> persia: thanks for the validation...  i do it all the time
<pitti> apparently they rather want you to use Windows than linux with the nvidia driver, or so :(
 * persia wants a GEM/TTM decision and nouveau
<kirkland> pitti: pfft...  well, i'm no fan of the nvidia driver, but it's the only option out there that let's me use my hardware thoroughly :-/
<pwnguin> indeed, it would help if intel hadn't coopted xorg =/
<pitti> kirkland: same here (luckily I have intel, but many people don't have a choice)
<slangasek> pwnguin: how would that help?
<pitti> kirkland: and nv wouldn't even play videos on my amd64 desktop
<pwnguin> slangasek: gem/ttm might be solved by now?
<pitti> kirkland: and that's a sacrifice I'm not wanting to make
<dholbach> hi mvo
<slangasek> pwnguin: hum, ok
<pitti> mvo: morschn
<kirkland> pitti must like his videos :-)
<pitti> I don't have a TV :)
<nxvl> Koon: it already have icon
<pitti> kirkland: you should have seen my wife during the EURO soccer championship :)
<kirkland> pitti: ah, that'll do it...  yeah, i love Google Earth and Scorched3D, both of those need good hw acceleration
<kirkland> pitti: watching on a laptop, fun, i'm sure ;-)
<pitti> kirkland: well, laptop with a 19" TFT attached
<tjaalton> pitti: probably, then jockey would not need to mess with xorg.conf
<kirkland> ah, that's better
<pitti> kirkland: I'm using a docking station with a proper keyboard and TFT
 * pitti doesn't ever want to give up his Kinesis Ergo keyboard
<kirkland> pwnguin: I'm still curious how to solve this with HAL?
<pwnguin> kirkland: im not entirely sure either
<mvo> hey dholbach and pitti
<kirkland> slangasek: and what is to be used instead of xorg.conf, to define my video driver and default resolution?
<pwnguin> afaik, HAL
<persia> Yes, HAL ought have enough information to do that.
<slangasek> kirkland: well, I thought we were supposed to already be to the point of not needing xorg.conf for anything other than keyboard map settings, as of hardy; but apparently I was wrong
<pwnguin> hardy doen't handle tablets either
<persia> slangasek: Also required for some other input devices, screens with inaccurate EDID, and other oddities.
<slangasek> though screens with inaccurate EDID also can (and should) be quirked
<persia> slangasek: All of them?
<slangasek> yes? :)
 * persia suspects the same is true for odd input devices, but quails at the volume of quirks
<tjaalton> kirkland: the xserver knows what driver to load based on the pci-id
<kirkland> tjaalton: does that get detected on every boot?
<slangasek> it gets detected every time the X server runs
<tjaalton> kirkland: boot == xserver load, yes
<tjaalton> kirkland: see the link pitti posted
<kirkland> tjaalton: the git commit?
<pwnguin> yea, it changes what gets loaded on pci-id
<tjaalton> running without xorg.conf works fine, provided that you use us layout and HAL is running
<kirkland> tjaalton: so should the xserver be able to automagically handle me moving an entire hard disk back and forth, between two laptops, with different (nvidia, ati) drivers, and different resolutions (1400x1050, 1024x768)?
<ion_> tjaalton: Huh? Iâm running without xorg.conf and i have a very specific configuration for keyboard in /etc/default/console-setup.
<kirkland> tjaalton: because it does not handle that gracefully
<tjaalton> kirkland: no, you can't have both nvidia and flgrx installed
<tjaalton> ion_: intrepid?
<pwnguin> kirkland: or if you have xorg.conf, i think it'll use that instead
<ion_> tjaalton: Yes. XKBLAYOUT="us,fi" XKBVARIANT=",kotoistus" XKBOPTIONS="lv3:ralt_switch,ctrl:nocaps,grp:alt_shift_toggle,compose:rwin"
<tjaalton> ion_: should've mentioned that I meant hardy :)
<ion_> tjaalton: Ah, ok
<tjaalton> in intrepid you have input-hotplug
<ion_> Yes
<ion_> Which rules. :-)
<tjaalton> you can also set other options via HAL, unless they are ServerFlags, so setting the mode and stuff _should_ work using an fdi file
<tjaalton> or driver options
<pwnguin> did bryce write this up in the wiki yet?
<tjaalton> there's something yes, but I havent' had time to read it through yet
<pwnguin> https://wiki.ubuntu.com/X/Config
<kirkland> tjaalton: linux-restricted-modules provides both an nvidia and an fglrx kernel module....  do you mean the xserver drivers specifically conflict?
<tjaalton> kirkland: no, the userland libgl libs
<tjaalton> how have you managed to install those?-)
<tjaalton> since the drivers conflict each other
<tjaalton> +with
<kirkland> tjaalton: i haven't yet, i'm still trying to figure this out
<tjaalton> heh, ok
<tjaalton> which ati do you have?
<tjaalton> chip
<tjaalton> if it's r5xx series, you shouldn't need fglrx anymore in intrepid
<tjaalton> lspci -vnn |grep VGA
<kirkland> tjaalton: sorry, no hard drive in that machine at the moment ;-)
<tjaalton> heh, ok
<kirkland> tjaalton: i'm slightly baffled, though, because according to http://www.thinkwiki.org/wiki/Category:X61 it has an Intel Graphics Media Accelerator X3100
<kirkland> tjaalton: and I swear I thought it was an ATI driver....
<pwnguin> well, lspci will know for sure
<pwnguin> there might be an optional ati graphics
<tjaalton> I've got a X61 myself, and it's intel. but there are a lot of variations
<kirkland> tjaalton: right... ThinkWiki is generally dead on, on the options
<kirkland> more informative than ibm/lenovo.com :-)
<kirkland> tjaalton: okay, in that case, I'm switching between nVidia Corporation Quadro FX 570M and Intel Graphics Media Accelerator X3100
<tjaalton> kirkland: right, and even then you wouldn't have 3D on the intel, since nvidia replaces the libs
<kirkland> tjaalton: same problem then
 * kirkland wonders if it would be possible to make those libs update-alternatives savvy....
<tjaalton> uh no please, dpkg-divert is enough of a nightmare :)
<slangasek> pitti: btw, yes, I confirm that the cdbs patch works for libgweather
<pitti> slangasek: and I just finished the other two tests
<pitti> slangasek: uploaded then
<pitti> slangasek: thanks for the fix
<slangasek> sure
<pitti> so feel free to do another sanitized upload with the appropriate build dep
<pitti> 0.4.52ubuntu6
<kirkland> tjaalton: interesting okay.... so it looks like i'd need to apt-get install/remove the libs each time I move HD's
<slangasek> tomorrow :)
<pitti> oh, dhcdbdbdbd wants to go to universe \o/
<pitti> kirkland: btw, could you please seed ecryptfs somewhere? it wants to go back to universe
<tjaalton> kirkland: well, unless you can manage having metacity on intel :)
<kirkland> pitti: hmm, yeah, i'd like to...  slangasek and mathiaz were debating the best place to put it
<slangasek> I wasn't debating anything :)
<kirkland> pitti: i'd like to make it a "recommends" of either xdg-user-dirs or adduser
<pitti> kirkland: uh, that doesn't sound appropriate to me TBH
<kirkland> pitti: let me bounce this off of you...
<pitti> kirkland: it's a relatively independent new feature, so shouldn't it become an ubuntu-standard recommends:?
<pitti> or put into both desktop-common and the server seed?
<pitti> it shuold be uninstallable without much pain
<kirkland> pitti: okay
<kirkland> pitti: https://code.launchpad.net/~kirkland/ubuntu-seeds/247400
<pitti> kirkland: oh, a full branch wouldn't have been necessary, but sure :)
<Koon> slangasek: about the base-files merge, I found where the libc6 amd64 depends comes from -- /usr/lib64 and /lib64 symlinks where moved to libc6 at 3.1.9ubuntu8, then you need to depend on a libc6 new enough that we get /lib64 created BEFORE we remove our copy
<pitti> kirkland: I guess we want it on desktop, too?
<kirkland> pitti: i would like to see it there too, doesn't have to be on the cd, i don't suppose
<kirkland> pitti: which seed do you recommend?
<pitti> kirkland: if we want it by default -> desktop-common, if we only want to make it available -> supported
<slangasek> Koon: I don't see any code in the diff currently that does a removal of /lib64; can this go away now?
<pitti> kirkland: but for the latter case, the server seed is enough already
<Koon> slangasek: it was probably a diff to debian that was dropped
<kirkland> pitti: okay, here's what I'm thinking.....
<pitti> kirkland: merged your branch
<kirkland> pitti: eventually, perhaps intrepid+1, i'd like to hook adduser to run ecryptfs-setup-private, which sets up ~/Private to be encrypted perhaps by default
<kirkland> pitti: for intrepid, i'm thinking it should be more of a conscious opt-in deal
<pitti> agreed
<kirkland> pitti: so how about this....
<Koon> slangasek: I don't think we'll have an upgrade scenario now that makes it required, so I'll drop it
<slangasek> Koon: ok, thanks :)
<kirkland> pitti: add a ~/Private directory to the skeleton, and in there, drop a symlink to ecryptfs-setup-private, and name it something informative, like "Setup this directory for encryption" or some such
<kirkland> pitti: user clicks on it or runs it from a command line, and voila, they're setup
<pitti> kirkland: sounds great
<pitti> or they can just delete the dir if they don't want it
<kirkland> pitti: right
<kirkland> pitti: okay, i'll work on that a bit next week
<liw> uh, more useless semi-mandatory directories in user's home directories... why skel? why not create it when it's set up?
<kirkland> pitti: i'd also like to get ~/Private translatable, via xdg-user-dirs or somesuch
<kirkland> liw: it would be created, if the user runs "ecryptfs-setup-private" ...  but how do we expose that?
<kirkland> liw: ie, how does a non-sophisticated ubuntu user find that magic command
<liw> kirkland, let me ask a counter-question: how do they find any other magic command?
<kirkland> liw: the Applications menu ... however, this is a script that a user could/would/should run only one time
<kirkland> liw: and by "a user", I mean each user on the system
<liw> kirkland, the encrypted ~/Private directory never, ever needs to be maintained? its passphrase never needs to be changed?
<kirkland> the passphrase is randomly generated, and then wrapped with the user's login passphrase.  pam takes care of unwrapping that passphrase on login, and mounting/unmounting on login/logout
<liw> kirkland, even a random passphrase may need to be updated (e.g., if the passphrase generator was buggy)
<kirkland> liw: see: ecryptfs-wrap-passphrase, ecryptfs-unwrap-passphrase, ecryptfs-rewrap-passphrase
<kirkland> liw: and you'd need to re-encrypt every file on the mountpoint
<liw> kirkland, the need to re-encrypt smells like there needs to be a tool for that; include that in the same tool that sets things up in the first place, and launch that tool from the menu
<liw> that way, it's discoverable, and doesn't pollute the user's name space with yet another generically named directory that overlaps the user's existing stuff
<kirkland> liw: sounds good, when can I expect the patch?  :-)
<kirkland> liw: us server guys are not allowed to write gui's :-)
<liw> kirkland, so the Applications menu was a red herring?
<liw> I don't see how creating a ~/Private will help someone discover a script
<kirkland> liw: not really.... you've convinced me that a longer term nice-to-have would be something in Applications -> System Tools -> eCryptfs Management ...  a little python utility with gui wrappers for all of the ecryptfs-* command line utilities I know and love
<kirkland> liw: because we already have a ~/Public ... this ~/Private would be its encrypted, 700-permed sister
<liw> ah yes, ~/Public, yet more invasion of _my_ name space :)
<kirkland> http://ubuntu.dustinkirkland.com/manpages/intrepid/man1/rmdir.html
<liw> I know how to remove them, but that didn't stop f-spot from becoming terminally confused when the ~/Photos directory it found was something altogether strange...
<pwnguin> hmm. perhaps if there was a way to simply mount the ecryptfs over a given dir
<kirkland> yurp...  f-spot is one of the first things I remove with prejudice everytime i install ubuntu
<pwnguin> have some encrypted dir stored in ext, then the script mounts over it
<kirkland> pwnguin: i'm going to hack on that a bit next week
<kirkland> pwnguin: the mount command is a custom setuid binary, so the namespace of legal dirnames needs to be tightly constrained
<pwnguin> fusermount?
<kirkland> pwnguin: nope
<kirkland> pwnguin: ecryptfs is in the kernel
<liw> there must be a better solution than willy-nilly creation of directories in $HOME for users... especially since old accounts won't get them for new services
<liw> (assuming that the ~/Private I created fifteen years ago is the ~/Private that should be used with ecryptfs seems like a massively bad idea to me)
<pitti> zul: can you confirm bug 241041?
<ubottu> Launchpad bug 241041 in xen-tools "Please merge xen-tools 3.9-3 (universe) from Debian unstable (main)." [Wishlist,In progress] https://launchpad.net/bugs/241041
<pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ updated now
<StevenK> pitti: \o/
<pitti> StevenK: oh, that apt-howto stuff is brand new, seems I can kill that as well
<pitti> hm, in fact i just removed the source package
<pitti> I think that's just temporary noise
<StevenK> pitti: Ignoring it
 * StevenK blinks.
 * StevenK tries to unravel a mess
<pitti> Riddell: should I accept source-NEW packages which include debian/cdbs/kde.mk? or reject them and ask to use cdbs' built in version now?
<thorwil> is that normal that decrypting a launchpad key confirmation takes ages and chews cpu like crazy?
<StevenK> Depends how large your key is
<StevenK> (Somewhat)
<thorwil> all defaults. 2048
<thorwil> evolution is at 0% since at least 4 minutes
<thorwil> arg, nevermind, a 2nd authorization dialog was below the main window, sorry
<thorwil> head->desk
<tjaalton> asac: cool, 3G works fine with nm0.7 :)
<tjaalton> it did ask a password, but for the network provider it was simply "internet"
<tjaalton> (Finnish Elisa)
<asac> tjaalton: https://wiki.ubuntu.com/NetworkManager/Hardware/3G
<tjaalton> asac: it's the same device as mdz has
<asac> tjaalton: ok. add that info anyway ;)
<tjaalton> asac: yeah I will, had the page open already :)
<tjaalton> pitti: looks like hotkey-setup initscript depends on discover (but the package didn't), but that should be easy to fix
<tkamppeter> pitti, hi
<mvo> pitti: the localegen hang you looked at some days ago, did you found out more about it? any news?
<YokoZar1> kees: ping
<YokoZar> Does anyone know how the new /etc/sysctl.d/ folder works with sysctl?  It's totally undocumented
<Riddell> pitti: hmm, good question, I guess they ought to be rejected, but Debian don't have kde4.mk in cdbs so it could be justified that it's closer to debian not to
<Riddell> (sorry for the late reply, was getting ready for trip to akademy)
<Trewas> tjaalton: actually "internet" is the APN, and no username/password for elisa... at least that's how I have set up with wvdial
<tjaalton> Trewas: ah, ok. for wvdial "internet" was the password
<Trewas> nm 0.7 (hardy version from https://launchpad.net/~network-manager/+archive) does not seem to react at all when I plug in nokia 6120 with usb-cable... it shows up as /dev/ttyACM0 and the network connection works with wvdial
<Riddell> Trewas: report a bug adding the relevant parts of lshal
<cjwatson> lool: for the most part I just symlinked lpia to i386; it at least built, which is a fairly good sign since the d-i build process is quite picky
<cjwatson> (for which read "insanely sensitive to local build environment")
<lool> cjwatson: Ok; when I looked into it, it seemed amd64 was slightly cleaner than i386 in that it didn't carry backward compatibility modules and configs, so I thought the same cleanups could be beneficials for lpia; all I care about is that it works though  :-)
<lool> cjwatson: You plan to enable builds on cdimage of e.g. the alternate CD?  I guess plenty of udebs are still missing for lpia
 * lool needs to disappear for a phone call &
<zul> pitti: acked
<pitti> zul: thanks
<pitti> hi tkamppeter
<pitti> mvo: no, I couldn't reproduce it at all, with several attempts; did you?
<geser> soren: bug #256037
<ubottu> Launchpad bug 256037 in iptables "[intrepid] Re-add libipq_pic.a lost in the last merge" [Undecided,New] https://launchpad.net/bugs/256037
<pitti> Riddell: ok, I'll accept it then if you are comfortable with this
<mvo> pitti: no, I tried it too, but no luck, I was just curious
<pitti> tkamppeter: ah, got your cups package reply, thanks for working on this! I guess Mike will be happy about a working patch which integrates into cups' build system
<cjwatson> lool: I suspect most of the udebs are already there
<cjwatson> lool: I'd be happy to build alternate CD images under ports, just haven't turned it on yet :-)
<pitti> seb128: workrave is seeded on the dvd; WDYT, promote or unseed?
<pitti> seb128: how well is it maintained upstream?
<seb128> pitti: no clue
<seb128> I don't use it and I don't maintain it
<seb128> I asked about demotion some time ago because the only changes had were language packs one
<seb128> mdz agree on moving it to universe
<pitti> ok, thanks
<seb128> dunno about the DVD
<pitti> I'll unseed it then and wait for complaints :)
<ScottK> pitti: I just ran across a case where apport duped a public bug to a private bug and then Launchpad hid the public bug from default searches.  Bug in apport or Launchpad?
<pitti> ScottK: it's controlled by apport
<pitti> ScottK: when it encounters a dup, it marks the bug as public and drops all apport attachments from it
<pitti> if that is too confusing, we can keep the duplicate private as well
<ScottK> This one was manually filed.
<ScottK> I think.
<ScottK> I take that back.
<pitti> seb128: gnome-panel recommends menu-xdg which in turn depends on menu; I don't think we want either in main, right?
<pitti> seb128: mind if I do an upload to drop the recommends?
<ScottK> pitti: I think that's sensible.  Perhaps apport could leave a comment describing what it's doing.
<seb128> pitti: for for it
<seb128> pitti: Suggests is good
<pitti> seb128: done, merci
<pitti> asac, Riddell: network-manager-kde recommends n-m-{pptp,openvpn,vpnc}; are these obsolete, or should they rather become recommends of the network-manager package?
<asac> pitti: they should become recommends of network-manager package as soon we have a working snapshot for them
<asac> pitti: currently they should be banned
<pitti> because they want to go to main due to that
<asac> but ill get them up as soon as i have stabilized them
<pitti> asac: ah, so they don't currently work even?
<asac> yes
<asac> broken
<pitti> asac: ok, and then n-m itself will pull them in?
<pitti> then it seems dropping them from -kde is the right thing here
<asac> pitti: i hope we can get them to a quality level that allows us to do that. right
<asac> pitti: ack.
<devfil> pitti: I'm working to fix knetworkmanager FTBFS, so in the debdiff I also drop them?
<asac> devfil: in ~networkmanager PPA we have a snapshot
<pitti> devfil: oh, I was in the middle of doing that; please do that then
<asac> doesnt that build anymore?
<pitti> devfil: thank you, good timing!
<devfil> pitti: I've already done it, I was just pinging Riddell to upload it, so I need only to drop the n-m-{vpnc,opnvpn,pptp}
<devfil> all done
<devfil> pitti: can you take a look at the debdiff?
<pitti> devfil: where can I find it?
<devfil> pitti: http://pastebin.ubuntu.com/35520/
<pitti> devfil: looks good; I'll add a slightly better rationale for the recommends drop and upload
<devfil> ok
<pitti> devfil: done, thank you
<cjwatson> lool: lpia alternate CDs should start building tomorrow
<persia> cjwatson: Will that come with an uninstallable binaries mail?  To which list would that mail go?
<ScottK> bryce: Are you close to being ready to ask for displayconfig-gtk to be removed?
<cjwatson> persia: hmm, don't have an arrangement to do that per-arch at the moment
<persia> cjwatson: OK.  Where do the reports go now?
<cjwatson> persia: cjwatson@ubuntu.com tfheen@ubuntu.com adconrad@ubuntu.com martin.pitt@ubuntu.com steve.langasek@ubuntu.com
<cjwatson> I can add something else to that list if you'd like
<persia> Sure.  Add me.
<pitti> hm, is edubuntu-meta still relevant at all?
<pitti> it didn't have a single upload in intrepid
<pitti> cjwatson: ^ do you happen to know?
<pitti> Riddell: edubuntu-desktop depends on khelpcenter kdeartwork-theme-icon; however, kdeartwork-theme-icon conflicts to kdelibs-data, and khelpcenter depends on kdelibs-data; what's the correct thing here?
<pitti> Riddell: edubuntu-desktop-kde, I mean
<cjwatson> pitti: I'm not sure; for the moment you should probably feel free to render it uninstallable
<pitti> cjwatson: s/render/keep/, I guess
<pitti> cjwatson: I cannot even ./update it, it falls apart with a 404 (it probably just needs some ports.u.c. URL change)
<pitti> cjwatson: ok, if it's not critical for alpha4, I won't touch it for now
<cjwatson> pitti: I'll fix its ./update in a moment
<pitti> cjwatson: ok, thank you
<cjwatson> persia: done
<persia> cjwatson: Thank you.
<cjwatson> persia: I just gave you the Ubuntu mail, figured you wouldn't care about other derivatives
<persia> cjwatson: That's likely best.  I get mail on one derivative now, and may want more later (depending on how those shape up), but that is probably best through the derivative lists rather than directly.
<pitti> soren: so, libvirt0-dbg depends on libvirt0, but libvirt0 conflicts to libvirt0-dbg; that doesn't make sense to me; should that be a versioned conflict, or is -dbg obsolete?
<pitti> tseliot: oh, argh
<pitti> tseliot: nvidia-glx-* is uninstallable on amd64, since it depends on ia32-libs
<pitti> tseliot: what do they need ia32-libs for?
<tseliot> pitti: I want ia32-libs to be installed first so as to divert some of its libraries. If you install ia32libs (e.g. for flash) you automatically screw up the 32bit compatibility libraries of the nvidia driver
<pitti> tseliot: right, just reading the bug
<pitti> tseliot: but that's pretty unfortunate; shouldn't that be possible to fix in the preinst as well?
<pitti> tseliot: ia32-libs is huge, and not many people need it
<pitti> first, it's in universe, so we can't depend on it in main/restricted
<tseliot> pitti: did you have a look at how ia32-libs is packaged?
<pitti> and second we shuoldn't force it upon every nvidia user just becaues of that workaround
<pitti> tseliot: I know the basics, I did some updates, yes
<tseliot> pitti: basically the preinst of ia32-libs should look for diversions of the certain libraries done by the nvidia-glx-VER packages
<pitti> tseliot: so n-glx' libraries should win?
<tseliot> pitti: yes
<RainCT> mvo: Hey. Have you seen my improvements for AptUrl?
<pitti> so n-glx ships its own 32 bit compat libraries arleady
<pitti> tseliot: that shuold be possible in the preinst, in theory
<pitti> tseliot: brb
<mvo> RainCT: no, but I was a bit swamped this week, let me have a look
<pitti> tseliot: mind if I reopen the bug, so that we don't forget?
<RainCT> mvo: lp:~rainct/apturl/ubuntu
 * mvo merges
<tseliot> pitti: feel free to reopen it
<pitti> tseliot: is libGLl.so.1 already a diversion, or a normal file?
<pitti> lib32GL.so.1 I mean
<pitti> argh
<pitti> /usr/lib32/libGL.so.1 -> that one
<cjwatson> pitti: fixed edubuntu-meta
<pitti> cjwatson: thanks
<pitti> zul: dbconfig-common? argh, that thing is a mess
<zul> pitti: heh dont shoot the messenger ;)
<pitti> tseliot: ok, commented on the bug
<pitti> asac: should I move nspr to updates without nss? or both at the same time?
<asac> pitti: both at the same time ... i am currently installing a fresh gutsy chroot so i can verify the gutsy upgrade again
<asac> pitti: actually doesnt matter if both at the same time, but i think we should move both at once
<DktrKranz> pitti, if you plan to manage verified SRUs for universe, could you please take into account ocamlsdl (bug 249355) too? It doesn't show bug number in pending-sru list, but it received verification.
<ubottu> Launchpad bug 249355 in ocamlsdl "ocamlsdl and lablgl conflict over Raw" [Undecided,Fix committed] https://launchpad.net/bugs/249355
<tseliot> pitti: libGL.so is a symlink to libGL.so.173.14.09
<tseliot> libGL.so.1 is a symlink to libGL.so.$VERSION
<tseliot> libGL.so.$VERSION (e.g. libGL.so.173.14.09) is the real file
<tseliot> by libGL.so.173.14.09 I meant libGL.so.$VERSION
<tseliot> in the 1st line
<bryce> ScottK: not yet
<ScottK> bryce: OK.  We may not be very far from that being the last user of guidance-backends.
<pitti> tseliot: ok, so we just need to divert the symlink, that should be easy
<bigon> !!
<bryce> ScottK: I sent mdz some mail about the situation.  He'd sort of like to see a replacement rather than just rip it out with nothing to stick in, since for the failsafe-x mode it'll mean returning the users to the old blue text screen of death
<tseliot> pitti: but wouldn't this break the nvidia driver in so doing?
<bigon> ark sorry for that
<bryce> however I don't think there is any drop in replacement available yet
<superm1> what was the deficiency in the current tool?
<ScottK> bryce: Right.  tseliot has a new xorg.conf parser.
<pitti> tseliot: oh, right, hang on, we want nvidia's to win
<tseliot> pitti: that was the problem ;)
<ScottK> superm1: Fundamentally broken with modern X11 that has no xorg.conf and needs a major rewrite to use xrandr.
<pitti> tseliot: so, for installing nvidia after ia32-libs, nvida just needs to Replaces: ia32-libs
<pitti> tseliot: and for installing ia32-libs after nvidia we should add a diversion of that file, shouldn't that work?
<superm1> i believe i am missing something, but don't you still need xorg.conf for situations that you want to impose configuration that you are forcing though?
<superm1> such as particular video drivers or monitor configurations that should be valid before entering {,x,k}ubuntu ?
<pitti> tseliot: that should force dpkg to unpack ia32-libs's libGL.so.1 to somewhere else
 * pitti hasn't personally used diversions yet, but believes that this is their purpose
<tseliot> pitti: currently nvidia-glx-VER adds a diversion on that file. Installing ia32-libs is the problem
<ScottK> superm1: Right, but guidance-displayconfig and guidance-displayconfig-gtk need rewriting to use xrandr.
<pitti> tseliot: weird; ia32-libs doesn't respect the diversion?
<bryce> superm1: guidance has a design assumption that all of the configuration is listed in xorg.conf, so if you give it a semi-empty xorg.conf like we currently ship, it breaks in myriad ways
<superm1> ScottK, but that's what i'm getting at, these tools are only useful in situations that the automatic detection fail.  They restart the session
<superm1> bryce, ah
<tseliot> pitti: ia32-libs simply tries to overwrite the file
<ScottK> It used to break if it was missing too, but I at least got that sort of working in Hardy.
<superm1> bryce, ScottK so the problem is more that they don't parse/get along with hardy/intrepid xorg confs moreso then them not using xrandr
<bryce> ScottK: I'm quite conversant with x-kit.  ;-)
<ScottK> Great.
<bryce> superm1: no, both are problems
<superm1> bryce, is the upstream to displayconfig-gtk not receptive to such problems?
 * ScottK watches bryce look in the mirror.
<bryce> ScottK: ??
<ScottK> There isn't particularly an upstream for the gtk variant is there?
<bryce> superm1: the upstream has gone away
<pitti> tseliot: I did "sudo dpkg-divert  --divert /usr/bin/pmount.foo --add /usr/bin/pmount" and then apt-get install pmount
<superm1> bryce, oh that does make for trouble then
<pitti> tseliot: that correctly unpacks it as /usr/bin/pmount.foo
<bryce> ScottK: X-kit is just one piece of what's needed.  Like I said we currently do not have a drop-in replacement for displayconfig-gtk
<bryce> so a new one would need to be developed based on X-Kit and pieces of displayconfig-gtk.  but that's not something anyone is working on currently
<tseliot> bryce: and porting displayconfig-gtk to x-kit would mean writing it from scratch
<tseliot> bryce: I could work on that too but I guess it's too late for Intrepid, isn't it?
 * ScottK ponders renaming kde-guidance to gtk-guidance.
<bryce> yeah it's too late for Intrepid
<tseliot> pitti: ok, so we should simply put the diversion in the preinst, right?
<bryce> tseliot: yeah I figure a rewrite is needed, and that it's a significant amount of work - which is why I've not mentioned it to you.  ;-)  Better to get X-Kit solid first
<pitti> tseliot: didn't you say it already had one?
<pitti> tseliot: right, but I was confused. it needs to be in nvidia's preinst, not in ia32-libs'
<tseliot> pitti: see my new comment in the bugreport
<tseliot> bryce: right
<bryce> also, I'm not entirely sure if a displayconfig-gtk-like tool is the right thing for the failsafe mode.
<bryce> probably we need something simpler and more robust.  A lot of the functionality in displayconfig-gtk - like setting up resolutions and such - isn't necessary these days
<bryce> well, not often
<pitti> tseliot: hm, seems something is wrong with that diversion then
<tseliot> bryce: maybe phase 2 of the blueprint could replace it
<pitti> tseliot: I have release team meeting now, let's figure it out later
<tseliot> pitti: ok, see you later
<pitti> tseliot: I think that install should be reattempted under observaition, with properly checking dpkg-divert --list and everything
<tseliot> pitti: ok, I'll have another look at it
<tseliot> bryce: I'm afraid that the xorg options editor wouldn't be as user-friendly as displayconfig-gtk
<cjwatson> mvo: have you had a chance to look at bug 255545? it's about to come up in the release team meeting
<ubottu> Launchpad bug 255545 in apt "requires uncompressed Packages files on CDs" [Undecided,New] https://launchpad.net/bugs/255545
<bryce> tseliot: yep I know.  no worries, we'll get there eventually
<mvo> cjwatson: I haven't. when is the release team meeting?
<cjwatson> mvo: now :-)
<cjwatson> mvo: (it's ok, it's not a meeting blocker, just wanted to know if you'd seen it and had any thoughts about whether it was feasible for intrepid)
<cjwatson> it'd be a nice 1.5MB saving
<cjwatson> TheMuso: are you likely to be able to upload your new-and-improved ubuntu-sounds for a4?
<bronson> I'm getting a ftbfs for libwebkitgtk1d.
<bronson> apt-get source libwebkitgtk1d; sudo apt-get build-dep libwebkitgtk1d
<bronson> cd webkit-0~svn29752; dpkg-buildpackage -rfakeroot
<seb128> bronson: what ubuntu version do you use?
<bronson> Oh, right.  seb128, Hardy.
<bronson> The error is a little confusing, "/usr/include/zlib.h:218: error: expected constructor, destructor, or type conversion before âexternâ"
<pitti> seb128: that brings me an idea: pm-utils already do suspend/hibernate, why shouldn't pm-utils do shutdown/reboot as well? that would be a fitting place, without layer violation
<bronson> This is on i686, haven't tried amd64 yet.
<bronson> Any ideas on why my build fails?
<seb128> pitti: looks like a solution indeed
<seb128> bronson: no, it built fine on the official buildds, did you do any change?
<bronson> seb128, none at all.
<seb128> bronson: why do you need to build it?
<bronson> I'm trying to figure out why my app, using webkit, won't use plugins.
<seb128> maybe try to build the intrepid version
<bronson> I wanted to make sure that the configure step is being performed the way I expect.
<bronson> Guess so...  I'm off to install +1.
<seb128> bronson: you can look at the build logs on launchpad
<bronson> ooh, neat.  I'll look.
<bronson> I'm getting "No matching builds" for libwebkitgtk1d
<bronson> Is https://launchpad.net/ubuntu/hardy/+builds?build_text=libwebkitgtk1d&build_state=all the right place?
<tseliot> superm1: in vnc.py you assume that a Screen section is available. Is this always the case when you run the program?
<superm1> tseliot, well not necessarily i suppose
<bronson> seb128, Any idea why there are no builds for libwebkitgtk1d?
<superm1> tseliot, is there xkit functionality to add the screen section as necessary?
<bronson> That page shows builds for all the other packages I've tried.
<tseliot> superm1: I can see how many screen sections are available
<tseliot> and add a new one if len == 0
<tseliot> superm1: I'll deal with it. I just wanted to be sure
<superm1> tseliot, okay sounds good
<seb128> bronson: the source package is named webkit
<bronson> Ah, I thought the source package was "webkit-0~svn29752"  :)
<kirkland> slangasek: ping me here with your 33649, when you get time
<kirkland> slangasek: also, i wanted to touch base with you on ecryptfs-utils + auth-client-config's replacement
<superm1> pitti, now that DKMS is in main, would you mind adding it as an installable item from DVDs?
<pitti> superm1: hm, TBH I'd rather have it as a dependency of a driver we ship
<pitti> superm1: e. g. I see nothing wrong with putting the nvidia and fglrx drivers onto the DVD
<pitti> (and had always assumed they were already)
<superm1> pitti, I'm not sure if they were previously, but yeah that would actually make life even simpler
<pitti> those will pull in dkms
<superm1> yup
<jarson> pitti, well they violate kernel policy/license for a first, but yeah i won't start a religious war
<superm1> jarson, the kernel modules for them aren't precompiled
<pitti> jarson: we don't install them by default, just ship them
<jarson> superm1, i see
<pitti> so that won't change license situations
<superm1> pitti, that just invoked a thought of mine.  with jockey now being split into a frontend/backend, wouldn't you be able to ask the user to restart the X session w/ the new module rather than rebooting too then?  (Possibly allowing the usage of these drivers in a live cd environment too then)
<mkrufky> does ubuntu distribute all DKMS prerequisites by default?  ...or does a user have to actually install DKMS and its dependencies first before ebing able to install a DKMS package?
<pitti> superm1: that's independent of the split, but yes, I should do that; please file a bug
<pitti> superm1: sorry, have to leave now
<superm1> pitti, no problem.
<seb128> sjoerd: around?
<sjoerd> yeah
<seb128> sjoerd: you don't like msn and icq users? ;-)
<sjoerd> pff
<sjoerd> no, i don't want random connection managers in empathy's recommends
<sjoerd> In Suggests is fine
<seb128> we want msn working out of the box
<seb128> and Suggests will not assure that
<seb128> not sure why you think users don't use msn nowadays
<sjoerd> ``we''
<sjoerd> Define we here
<seb128> anybody distributing empathy
<seb128> GNOME, debian, ubuntu
<sjoerd> people can install haze and/or butterfly if they want
<sjoerd> i don't think it should be a recommend
<seb128> sjoerd: I think having msn not working out of the box is a disfavor to users
<sjoerd> but your free to do for ubuntu whatever you like
<seb128> what is your issue with butterfly?
<seb128> users will not read documentation or look at suggest
<sjoerd> again, i just don't think we should list all possible CM's in Recommends
<seb128> they will just complain about msn not working
<seb128> me neither
<seb128> I think we should have jabber and msn working out of the box though
<seb128> icq too probably
<seb128> recommends means "user probably want to use that but they can remove it if they want"
<seb128> and I think it's fair to say most im users want to be able to connect to msn
<seb128> no?
<sjoerd> Recommends means, You can use this program without these packages, but it's really not recommended
<sjoerd> That's not true for haze or butterfly
<sjoerd> also -gabble and -salut are our two most featurefull and core CM's so if any are in recommends then it should be those
<seb128> I don't discuss those
<seb128> I just discuss how useful is an im for users if it doesn't do msn nowadays
<seb128> but let's say we disagree, we will just modify the ubuntu package then, thanks
<sjoerd> yeah, i'm entirely happy to disagree on this :)
<dholbach> seb128: ubuntu-desktop can recommend them ;-)
 * seb128 slaps dholbach
<sjoerd> hehe
<bigon> or telepathy-meta :p
<bronson> Interesting...  Ubuntu's build uses regular quotes '_xmlEntity::checked', mine uses screwy quotes â_xmlEntity::checkedâ
<bronson> *buildd's build
<cjwatson> you're using a UTF-8 locale (as is the default). 'export LC_ALL=C' if you want the buildd's behaviour.
<seb128> bigon: well, the thing "use synaptic to install empathy" case to give something useful
<bronson> Will do.  I'm surprised buildd doesn't use the default.
<seb128> bigon: and having only jabber working will not match this definition for our users
<slangasek> kirkland: ok, I think I'm around now :)
<kirkland> slangasek: cool
<kirkland> slangasek: you wanna talk grub first?
<slangasek> either way
<kirkland> slangasek: okay, what's your feedback on 33649
<tseliot> superm1: I have added the support for x-kit here: https://code.edge.launchpad.net/~albertomilone/mythbuntu/mythbuntu-common-xkit
<slangasek> kirkland: so I saw your follow-up in 33649, and I think I'm concerned about the idea that a grub-install /dev/sda will auto-detect the RAID and automatically write to /dev/sdb at the same time
<tseliot> superm1: I haven't tested it yet though. I'm sure you have your own test suite to do that.
<slangasek> kirkland: this seems to fail at least-surprise, and seems to make it impossible for a user to upgrade grub on one device at a time for testing
<kirkland> slangasek: what do you suggest the interface look like?
<seb128> StevenK: why do you need to build the clutter-gtk documentation at build time?
<slangasek> kirkland: shouldn't supporting grub-install /dev/md0 be enough, without changing the behavior of the other cases?
<kirkland> slangasek: i could agree with that, with one extension....
<kirkland> slangasek: I'd like grub-install /dev/sda and grub-install /dev/sdb to do the installation of grub to each of those disks individually...  currently, only one of the two exist in device.map, so grub-install /dev/sdb does NOT work
<slangasek> why is that?
<kirkland> slangasek: so i'd change it to relax the device.map check, if the disk is part of a raid device providing /boot
<kirkland> slangasek: can you have both hd(0) /dev/sda and hd(0) /dev/sdb in device.map?
<slangasek> I think you can?
<kirkland> slangasek: hmm, i'll need to test that...
<kirkland> slangasek: i assumed no
<slangasek> since, contrary to sense, the mapping is from right to left
<kirkland> slangasek: but that could be wrongage on my part
<kirkland> slangasek: in any case, i accept your feedback...  grub-install /dev/sda doing the installation to sda and sdb is perhaps misleading (though my intentions are noble)
<kirkland> slangasek: I'll fix that, but I'll also make absolutely sure in my testing that one can grub-install to /dev/md0 (hitting both sda and sdb), and individually to each device
<slangasek> awesome
<kirkland> slangasek: and perhaps what I need to fix is the device.map generation
<kirkland> slangasek: to plop each disk into the device.amp
<kirkland> slangasek: I'll have to do some hunting to figure out where that gets pooped out
<slangasek> from an invocation of the grub shell by grub-install
<cjwatson> kirkland: have I pointed you at lilo/README.raid1 yet? it offers several alternative modes
<slangasek> $grub_shell --batch $no_floppy --device-map=$device_map <<EOF >$log_file
<cjwatson> I wonder if an option to grub-install would be worthwhile
<kirkland> cjwatson: you did, i read it, i'll refer back to it
<cjwatson> ok, thanks
<kirkland> slangasek: that says, "use it", not "generate it", no?
<cjwatson> beyond that I'll defer to Steve, Classmate is EATING MY BRAIN just now
<kirkland> cjwatson: ;-)
<slangasek> kirkland: nope, that's how it generates it when it's not already present
<kirkland> slangasek: cool, i'll check it out
<kirkland> slangasek: this is well within scope, i'll update the patch today
<kirkland> cjwatson: please holdoff on committing that patch
<slangasek> great :)
<asac> pitti: i have finished nspr/nss verification
<kirkland> cjwatson: perhaps slangasek can sponsor it, once i get it steve-proof?
<cjwatson> that would be fine by me
<cjwatson> since he's already been through it
<kirkland> slangasek: okay, item2, ecryptfs-utils
<slangasek> indeed
<kirkland> slangasek: i blogged about it this week, and a number of people have started testing it
<kirkland> slangasek: most feedback positive, though a number of people have complained about the pam configuration part, why that can't be part of the package installation
<slangasek> the ETA I gave pitti, who is also blocked on the PAM refactoring, is late next week
<kirkland> slangasek: cool
<kirkland> so not this alpha, but perhaps next?
<slangasek> I would love to give you a head start, getting the config snippet ironed out so that it can be ready to go the same time pam itself lands
<slangasek> yes, I want to have this all in and done by alpha-5
<kirkland> slangasek: okay...  what can I do?
<slangasek> you saw the sample config file format in the spec?
<slangasek> is it self-explanatory, or do I need to improve the documentation any?
<kirkland> slangasek: let me refresh my memory
 * kirkland goes re-read the spec
<slangasek> I do have a feature branch for this stuff at http://bzr.debian.org/bzr/pkg-pam/debian/features/config-framework/ ; though alioth's http bzr seems to not be working so well for people, so maybe I should copy that over to LP...
<kirkland> slangasek: so would the configuration files i need live in ecryptfs-utils along with the pam module, or in this pam config framework package?
<slangasek> kirkland: they would live in the same package that ships the pam module
<kirkland> slangasek: oh, good
<slangasek> that way, the maintainer scripts themselves can take care of registering/unregistering
<slangasek> (that part isn't congealed quite yet, so I can't give you maintainer script samples)
<kirkland> slangasek: okay, based on https://wiki.ubuntu.com/PAMConfigFrameworkSpec, i think there's still a bit of documentation missing
<kirkland> slangasek:  http://pastebin.ubuntu.com/35591/
<kirkland> slangasek: something like that ^ is what I'd naively create based on the spec
<slangasek> kirkland: so you want the module added to each of /etc/pam.d/common-{auth,session,password}?
<kirkland> slangasek: yep, "optional" in all 3 cases
<kirkland> slangasek: I'm not sure about final, but it needs to be down below pam_unix
<kirkland> slangasek: ie, after the password has been received
<slangasek> kirkland: you're right, clearly my documentation is lacking :-)
<kirkland> slangasek: well, as I said before, I'm happy to be a lab rat
<slangasek> kirkland: the "final" means "this is the snippet to use /when/ we're stacked last"
<slangasek> but all "additional" modules will always be stacked after all "primary" modules
<slangasek> so that part doesn't matter at all
<kirkland> slangasek: okay, so that should push me far enough down in the stack
<kirkland> slangasek: i just need to make sure i don't get stuck after a module that would exit the stack prematurely (with success)
<slangasek> right; that would be forbidden in this framework
<kirkland> slangasek: i think that might have been how "requisite" was explained to me?
<slangasek> actually, requisite will only short-circuit on failure
<slangasek> not on success (that's "sufficient")
<kirkland> slangasek: poor choice of words...  "how I understood requisite?"
<kirkland> :-)
<kirkland> slangasek: ah, okay....
<kirkland> slangasek: good, i think we're okay
<kirkland> slangasek: so how would you rewrite http://pastebin.ubuntu.com/ ?
<kirkland> http://pastebin.ubuntu.com/35592/
 * kirkland is not asking slangasek to re-implement a pastebin :-)
 * kirkland is confident, though, that such and effort would involve a lot of 'sed' :-)
<slangasek> http://pastebin.ubuntu.com/35594/
<kirkland> slangasek: ah, i see...  yeah, that's logical
<slangasek> heh, there are some things that even I won't use sed for ;)
<kirkland> slangasek: thanks, that looks good to me, i'll save that off somewhere
<slangasek> ok, cool
<slangasek> btw, what do the auth and session bits of the module do when you *don't* pass the 'unwrap' option? :)
<kirkland> slangasek: would have to look at the code, but my guess is that "unwrap" says "use the login passphrase to unwrap the keyfile and insert into the kernel keyring", and no "unwrap" probably just inserts the keyfile in the keyring as is
<kirkland> slangasek: i can go read the code right quick, if it's important to you
<slangasek> kirkland: ah - not that important, I was just wondering why whatever it does isn't the default, since that's apparently the only way we're using it :)
<kirkland> slangasek: i just read the code, it is exactly as I explained
<slangasek> ok :)
<kirkland> if () ecryptfs_insert_wrapped_passphrase_into_keyring; else ecryptfs_add_passphrase_key_to_keyring;
<kirkland> slangasek: probably defaulting to wrapped passphrases, and allowing a legacy "nounwrap" might be better, but meh
<kirkland> slangasek: let me go hack on grub for a bit and I'll ping you when i have something FVT'd
<kirkland> slangasek: thanks for your time!
<bronson> Hm, I've verified that there are no substantial differences between my build and buildd's
<bronson> Just noise like "+dpkg-buildpackage: source changed by Mike Hommey <glandium@debian.org>"
<bronson> (at least, I think it's noise)
<bronson> So, I'm off to install Intrepid and see what happens there.
<Treenaks> Wow.. I just had to restart metacity, because it was updating /desktop/applications/window_manager a few times per second
<Treenaks> (you wouldn't believe how slow that makes your machine feel :))
<slangasek> E: base-files: needlessly-depends-on-awk depends
 * slangasek shakes his head sadly at lintian
<alex-weej_> something in pulseaudio is still gobbling memory and bringing my machine to a complete freeze
<alex-weej_> if a sink vanishes, something just keeps on eating memory
<alex-weej_> now what i don't get is that i have 2 GB of RAM and a 450MB swap partition
<alex-weej_> my disk thrashed for a good ten minutes while i waited for the kernel to just kill it
<alex-weej_> it doesn't take ten minutes to fill 450MB - what's happening here?
<alex-weej_> and is there some way i can make linux kill processes that try to eat too much memory?
<alex-weej_> and if there is, can we turn it on by default?
<alex-weej_> having a computer be rendered useless (without magic sysrq keys) is very Windows 95.
<mvo> quick poll: I would like to see a option to prevent gdm from starting (at the kernel/grub commandline). I added bug 256125 with patch. is that a) something that more people than just me want b) is "nogdm" a good option? or should it be "noxdm", "nox" instead?
<ubottu> Launchpad bug 256125 in gdm "support nogdm option" [Wishlist,Triaged] https://launchpad.net/bugs/256125
<cjwatson> other thoughts (not particularly implying these are better): textonly, textmode, text
<cjwatson> casper supports a 'textonly' option although I don't think you should necessarily feel obliged to follow it
<jcastro> mvo: as in, no gdm at all, it just goes right into the gnome session? or a text login?
<cjwatson> on a) I think it would be a good thing to clearly support
<mvo> jcastro: as in "gdm should not start", just text login
<cjwatson> I think the positive formulation ("text", rather than "not <thing>") is possibly clearer and avoids the "nokdm", "noxdm", etc. thing
<jcastro> that sounds sane to me
<seb128> noxdm was mean no be a no?dm
<seb128> meant
<cjwatson> RH-based systems just do this with runlevels so we probably can't look to them for parallels
<seb128> noxdm was meant to be a no?dm
<cjwatson> seb128: I understand, although I'm not sure that that would be entirely clear to everyone
<cjwatson> "nodm" if you want that, but it gets a bit cryptic
<seb128> I think a text* would work fine too
<cjwatson> for a different viewpoint, "nox" parallels a number of package names (we still have emacs-nox, don't we?)
<mvo> I like "text"
<mvo> text or textmode? I guess text is better (shorter)
<pwnguin> what's the motivation for this?
<pwnguin> i mean, we already have a root console thing from grub.
<mvo> pwnguin: to be able to boot into the system faster for me and do some quick changes, I need it not very often, but often enough to miss that feature
<cjwatson> I can think of all sorts of reasons. "gdm is busted, let me just get to text mode so I can get my work done." "I don't have much battery left and don't want to waste time starting a desktop, but I want to look at this file."
<mvo> yeah, but it comes up without virtual consoles (just a single terminal) etc
<cjwatson> pwnguin: grub recovery mode gives you an emergency system, not one you can work in
<pwnguin> even faster! ;)
<pwnguin> alrighty
<cjwatson> it's not designed for people who just don't want X to start for whatever reason
<pwnguin> mvo: does that patch work?
<cjwatson> mvo: BTW the [ -e ] is unnecessary - just use grep -qs
<mvo> pwnguin: I think it does
<cjwatson>        -s, --no-messages
<cjwatson>               Suppress  error  messages about nonexistent or unreadable files.
<mvo> cjwatson: right, thanks
<pwnguin> oh
<pwnguin> duh
<pwnguin> /proc/cmdline isnt the process's commandline
<pwnguin> it's the kernels
<mvo> yep
<cjwatson> you're thinking of /proc/<number>/cmdline
<pwnguin> yea
<mvo> cjwatson: thanks, I will change that, use text and then just upload I think (if seb128 is happy with that)
<pwnguin> i was wondering how "text" got from point a to point b... but i get it now =)
<seb128> mvo: works for me
<warren> What version of libcurl.so.X is in Ubuntu 8.04 LTS/
<warren> ?
<stgraber>   libcurl3 | 7.18.0-1ubuntu2 |         hardy | amd64, i386
<warren> that contains libcurl.so.3?
<warren> so you don't ship libcurl.so.4 anywhere?
<cjwatson> FWIW http://archive.ubuntu.com/ubuntu/dists/hardy/Contents-i386.gz can answer these kinds of questions
<cjwatson> full file list correlated with package names
<cjwatson> libcurl3 does appear to ship libcurl.so.4 although I can't speak to the reasons
<warren> oh
<cjwatson> I can only assume something weird went on and would have to check the bug history
<cjwatson> Debian has the same
<cjwatson> libcurl.so.3 is a symlink to libcurl.so.4 (!)
<slangasek> upstream bumped the soname
<slangasek> and upstream was wrong
<slangasek> so I twisted the maintainer's arm into keeping it unchanged in Debian :)
<slangasek> so the unmodified upstream soname is shipped, for complete compatibility with third-party software, and the symlink is included with the package name unchanged, for compatibility with previous package builds
<warren> cjwatson: what?!
<warren> cjwatson: that sounds wrong.
<cjwatson> well, it would be wrong if they were in fact ABI-incompatible
<warren> you're serious, it is actually compatible?
<slangasek> yep
<warren> wow
<warren> hm
<slangasek> the only difference was an API deprecation
<slangasek> which doesn't require rebuilds, curl properly handles deprecated options in its API to begin with
<cjwatson> I remember this happening but wasn't following the byzantine mail threads at the time. :)
<cjwatson> the reason the package name is libcurl3 rather than just libcurl4 Provides: libcurl3 is that Provides aren't allowed to satisfy versioned dependencies (a long-standing maybe-bug in dpkg)
<cjwatson> so keeping the package name saved a lot of upgrade complexity, and simplified Debian testing maintenance
<sistpoty> hm... I doubt virtual package versioned deps is a bug... how would you define the version if two packages provide a virtual package?
<cjwatson> sistpoty: you'd have Provides: libcurl3 (= some-version). Please refer to the innumerable Debian mail discussions on the subject
<slangasek> :)
<sistpoty> ah... will do, thanks :)
<cjwatson> I'm afraid I don't have links to hand but "versioned provides" would be the search term
<alex-weej_> http://alex-weej.blogspot.com/2008/08/sucata-run-2008.html
<alex-weej_> http://alex-weej.blogspot.com/2008/08/sucata-run-2008.html
<cjwatson> alex-weej_: once is enough, thanks
<alex-weej_> cjwatson: please don't make me have to /amsg that i didn't realise /amsg worked for all networks simultaneously in xchat
<mvo> cjwatson: hm, I noticed that you made openssh-blacklist a suggestion now instead of a recommends. this might be a problem on some systems because the auto-remove now thinks that it can be remove. was that recommend dropped because of the CD size?
<LaserJock> mvo: time to discuss moving DVDs again perhaps?
<mvo> I send a mail to ubuntu-devel about possible solutions, not sure why it has not shown up yet :)
<norsetto> mvo: it has
<mvo> oh, then just not for me yet
 * mvo kicks his mail provider
<cjwatson> mvo: yes, I was aware it was a problem but your guess as to the reason is correct
<mvo> ok, I think I could add some magic to the release upgrader so that is not a problem for people upgrading
<cjwatson> mvo: that said, as I noted in the changelog, I suspect most affected systems will have gone through an upgrade cycle that caused them to install openssh-blacklist, by now
<cjwatson> but it does of course weaken our protection somewhat
<mvo> aha, ok, I misread the comment then
<alex-weej_> before anyone else grills me for spam, sorry. "/amsg" works for all networks at once in X-Chat, CAUTION!
<cjwatson> if we can ever manage to free up enough space, I would like to put it back in
<cjwatson> unfortunately this doesn't seem that likely
<mvo> I would be interessted in your opnion on the idea of having the CD build with --no-recommends and a ubiquity mode like for the missing language packs as part of the install where it offers to download more stuff
<LaserJock> mvo: would that be an interim solution?
<mvo> I guess so, until we move to bigger media (which I suppose we will have to at some point in the future
<LaserJock> I tend to think it's a bad idea to have people install a different set of packages than if they just apt-get install ubuntu-desktop
<mvo> because it affects only provides, the stuff would still be useful and a user with internet after the install would always use synaptic to install the missing pieces
<LaserJock> if Recommends really is what it says it is, then we know basically everybody will want them
<cjwatson> mvo: I posted to ubuntu-devel a while back about that saying I really wasn't keen on that approach
<mvo> LaserJock: I agree, I was just bringing it up as a compromise idea, because to me the idea demoting a lot of the (useful) recommends to suggests is not ideal either
<cjwatson> for much the reasons LaserJock says
<LaserJock> mvo: it's certainly a lot better than dropping Recommends altogether
<cjwatson> I don't see how that would help this case at all though
<mvo> cjwatson: oh, I think I missed that (or don't remember it). if that has been discussed before, I'm sorry to bring it up again
<cjwatson> the problem is not that recommends is included (and actually recommends makes this situation a lot easier because lots of people get annoyed if I make openssh-client have a hard dependency on openssh-blacklist) - it's that the CDs are too damn full :)
<mvo> cjwatson: the case with the openssh-blacklist? because it would still be a recommends, the auto-remove would leave it alone at least :)
<cjwatson> really, I want it on the CD
 * mvo nods
<cjwatson> I don't want it downloaded from the network maybe if the moon is in the right phase :)
<cjwatson> our installs are a bit too nondeterministic for my taste already, and we get quite a lot of bugs from those places
<cjwatson> hence the work in hardy to try to make language pack installation more robust
<cjwatson> perhaps a different compromise would be to allow indicating that *specific* Recommends should not be included during CD building
<cjwatson> I don't like doing it across the board, but I can see that it could make sense in certain cases
<cjwatson> we do have a blacklist feature in germinate already, but it's a very crude hammer
<cjwatson> I'd have to put some thought into something more fine-grained
<cjwatson> mvo: would that be acceptable, do you think?
<mvo> I believe it would be a bit less problematic than the language packs, because all the information what is needed (what reocmmends are missing) is available for libapt itself, whereas with the languages the policy is not in libapt but in language-selector. but I don't want to press the point, it was just a idea that I wanted feedback on
<cjwatson> well, the problem is different results from initial installation depending on whether you have Internet access or not, and depending on whether that Internet access is available during installation
<LaserJock> we could drop OO.o to it's own addon CD ;-)
<seb128> cjwatson: if you really want something on the CD seed it as we did until now?
<cjwatson> it multiplies the test matrix by at least three
<cjwatson> seb128: I know how to get things onto the CD :-) but it's too big
<cjwatson> hence why I took it off
<mvo> cjwatson: a fine-grained blacklist sounds like a good idea as well, so eg openssh-blacklist would still be a recommend but not on the CD?
<cjwatson> mvo: yeah, something like that
<cjwatson> I'm still not entirely content with it but it could work and it might address some of the complaints about recommends-by-default
<seb128> I mean, better to not use recommends to build CD and seed things we do that dropping valid recommends just to accomodate the CD space
<cjwatson> seb128: both of those two extremes have problems, so I'm suggesting a compromise between those two
<cjwatson> I'm suggesting putting them back to Recommends, but having a way to annotate *some* Recommends as not to be used for CD building
<seb128> that would be nice too indeed
<cjwatson> I do not think it's appropriate to omit Recommends from CD building across the board; if they really are valid Recommends, then the CD is the most usual case and the recommended package should be found together with the recommending package
<cjwatson> the language of policy practically mandates that valid recommends be included on CDs
<cjwatson> but we could perhaps make some exceptions
<seb128> well CD where full before we started installing recommends
<seb128> so it's a wonder that we manage to keep any of those new recommends
<cjwatson> sure, I understand the problems
<cjwatson> although I would say that recommends are not nearly so useless now as you make out
<seb128> my impression on the GNOME packages is that we dropped everything which was not on the CD to Suggests to accomodate the CDs
<seb128> oh I don't say they are useless
<seb128> but I'm not that happy to have to drop valid recommends, your alternative solution would solve that too though
<cjwatson> they're still very useful in the areas of the archive not on the CD, or not in the desktop edition, and we've been able to drop some incorrect Depends to Recommends as a result of recommends-by-default
<sistpoty> oh, mvo: could you take a look at bug #229489... I'm still puzzled why this situation could have happened in the first place (maybe some partial-upgrade magic?)?
<ubottu> Launchpad bug 229489 in gtk2hs "package libghc6-mtl-dev 1.0.1-1 failed to install/upgrade: Package is in a very bad inconsistent state - you should" [Undecided,Confirmed] https://launchpad.net/bugs/229489
<cjwatson> I would say you have probably been worst hit by the problems
<seb128> probably ;-)
<cjwatson> anyway, I won't be able to think about it until week-after-next, but will do so then
<seb128> I think a featurefull desktop installation simply doesn't fit on a CD nowadays
<seb128> which is the real issue
<mvo> sistpoty: yes, looking
<cjwatson> I think people have been saying that since warty
<sistpoty> thanks mvo
<cjwatson> and yet we always manage to do it and people love the fact that we do
<seb128> right, but difficulties increase every cycle
<cjwatson> I know, but I really think they are worth it
<seb128> right but at some price
<cjwatson> and the pressure is good for us in some ways
<LaserJock> well
<cjwatson> forcing us to keep installation image size down also encourages us to keep installed-system size down, which is good for users without huge systems
<seb128> we discussed it with pitti some days ago, I think it would be nice to have a "limited" desktop install on CD and a featurefull image on 1Gb usb key images for example
<cjwatson> mm, when we have double the available resource on cdimage maybe we can think about that ;-)
<cjwatson> and double the space on releases.u.c mirrors
<ScottK> Heya LaserJock: There's going to be a matplotlib upload in Debian today, so we probably ought to catch morph on #debian-python if we've got anything they ought to get in Lenny.
<LaserJock> perhaps gradually more attention will be paid to the DVD?
<LaserJock> the 1 CD OS is still a real nice thing to have
<seb128> DVD is too big to download
<LaserJock> people do it all the time ...
<cjwatson> I expect so, but I don't think we can ditch the CD
<seb128> 1Gb usb key would not be much bigger and would be nice though
<cjwatson> *some* people do it all the time
<cjwatson> most people do not
<LaserJock> well, in terms of distros
<LaserJock> they went DVD
<johanbr> How about 2 cd's ?
<LaserJock> and are now going back to DVD + LiveCDs
<cjwatson> LaserJock: and look how much more popular Ubuntu is
<LaserJock> we're just kind of the opposite
<LaserJock> I'm saying that perhaps the best is to have good offerings of both CD and DVD
<cjwatson> johanbr: going from install CD + live CD to install/live combination CD slashed Canonical's shipit costs by a factor of three
<cjwatson> johanbr: so I guess it depends how long you'd like shipit to continue ...
<cjwatson> it turns out that single-CD sleeves are significantly cheaper to manufacture and ship
<cjwatson> DVDs are about triple the cost of CDs, I think, last I checked
<LaserJock> well,  you wouldn't have to ship DVDs
<LaserJock> but a download would be nice
<cjwatson> LaserJock: I know, just for information
<cjwatson> s/would be/is/ surely, since we do provide it
<LaserJock> the USB stick thing is intriguing
<cjwatson> seb128: the problem with a separate 1GB USB image is that as long as we still support the CD that means we've gone from 700MB to 1700MB for each desktop edition
<LaserJock> I'm not sure how many machines boot easily from USB
<cjwatson> seb128: which blows some of our current resource constraints out of the water
<seb128> cjwatson: right, there is just no easy solution to the problem
<cjwatson> in a world of unlimited resource and bandwidth I'd agree with you
<seb128> I guess I would be fine with what you suggest
<seb128> a way to list recommends which should not be on the CD
<cjwatson> but that's why I'm proposing the approach of automatically generating the USB image from the CD image (which Evan's working on) as a way to get us started on USB image distribution
<seb128> so we would not have to drop valid recommends
<cjwatson> it's just a whole lot more practical right now
<seb128> right, agreed
<Chocobo> Hi all.. where would I go or what do I do to build the current "tightvnc" package?   I am a little confused by the debian/ubuntu build process.
<cjwatson> syntax suggestions for the seeds welcomed at cjwatson@ubuntu.com ;-)
<cjwatson> I think I'm running out of punctuation characters
<cjwatson> Chocobo: sudo apt-get install fakeroot devscripts (you only need to do this bit once); sudo apt-get build-dep tightvnc; apt-get source tightvnc; cd tightvnc-*; debuild -b
<cjwatson> if you want a different package to what apt-get source gives you, then download the source package separately and use dpkg-source -x foo.dsc to unpack it
<Chocobo> Wow, thanks cjwatson.  That is much more straightforward than what I was reading about (pbuilder)
<cjwatson> pbuilder is for when you feel your normal system won't be suitable for building it for one reason or another, and want to guarantee a clean build environment
<cjwatson> if you routinely install lots of packages from different sources, then you might find your normal system will fail to build a lot of things
<cjwatson> particularly if you mix releases a lot
<Chocobo> Ahh, alright.  Is there a document that I should read so that I don't need to be a bother in here?
<cjwatson> so pbuilder will work in adverse circumstances, but you can just as well build in your normal system if it works
<Chocobo> I see, it is sort of like a sandbox or something similar.
<cjwatson> err, there's almost certainly something on the wiki (maybe something better-written on help.ubuntu.com/community/) but the "you have to use pbuilder for everything" meme is quite prevalent so I'm not offhand sure where
<cjwatson> for various reasons it's not practical for me to look it up right now
<mvo> sistpoty: the problem seems to start with "ghc-pkg: cannot find package gtkglext-0.9.12^M" in th prerm, the new prerm is empty, might that already be the problem? some sort of transiton in how the haskel registration is done (sorry, I have no idea about ghc)
<cjwatson> Chocobo: apt-get and debuild have good man pages though
<mvo> sistpoty: oh, I'm reading more of the report now, that looks more complicated
<sistpoty> mvo: yes, I've only partially looked through the logs, and I can't seem to find the big picture of what is wrong (apart from that the new maintainer scripts don't support rollback)
<Chocobo> Wow, alright.  Thanks cjwatson.  Unfortunately the tightvnc build failed... so it looks like perhaps I need to use pbuilder.   ...  it is complaining about all the /usr/include/X11/* files.
<cjwatson> Chocobo: I don't use pbuilder often, but I think that 'sudo pbuilder create --distribution=hardy' (once only) and then 'apt-get source tightvnc; sudo pbuilder --build tightvnc_*.dsc' should be about it
<cjwatson> that's just from its man page thouygh
<Chocobo> Thanks for the help cjwatson.  the first method is working on a 2nd computer, so I think we will go with that :)
<cjwatson> Chocobo: there's also https://wiki.ubuntu.com/PackagingGuide, which goes through this stuff, though you may have seen it already
<mvo> cjwatson: if you are still around, when you build the cdrom without the packages, was there a packages.gz on it?
<mvo> cjwatson: is the test-image you used available somewhere?
<cjwatson> mvo: I literally just took an alternate CD, ran find -name Packages | xargs rm on it, and re-mkisofsed it
<cjwatson> mkisofs -r -V 'Ubuntu 8.10 i386' -o intrepid-alternate-i386-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-i386
<mvo> cjwatson: ok, thanks
<cjwatson> (so yes, there was a Packages.gz on it)
<mvo> cjwatson: yeah, thanks, I think I have the info I needed
<mvo> cjwatson: I should have a patch that makes the "no Package file" case work I think (for when you come back :)
<wasabi> jelmer: welcoem to the team. it's sort of dead though.
<jelmer> wasabi, :-(
<wasabi> you may revive it. :0
<wasabi> nobody who was in it had any time to contribute...
<wasabi> and it never generated interest from canonical (which was my intention)
<slangasek> "the team"?
<wasabi> slangasek: ubuntu-directory
<slangasek> ah
<kirkland> slangasek: The drive (hd0) is defined multiple times in the device map /boot/grub/device.map
<kirkland> slangasek: so that's not gonna work...  i'm going to need a special case, i think for md
<kirkland> slangasek: i'm nearly done testing it
<slangasek> kirkland: ok
 * mcasadevall_ is stuck in hell :-)
<cjwatson> mcasadevall_: three bridge players with packs of cards?
<mcasadevall_> hey StevenK
<elmo> cjwatson: you know, 8 UDSes in and we still haven't managed a game of bridge
<elmo> (unless I just missed it/wasn't invited ;-)
<cjwatson> I tried at the sprint but only managed me+lifeless
<cjwatson> so we ended up playing two-handed 500 instead
<mcasadevall_> cjwatson, worse, I'm trapped at JFK airport terminal six for two more hours with just enough bandwidth to not have freenode time out
<cjwatson> maybe I should try at the distro managers sprint week after next
<cjwatson> mcasadevall_: you get to practice your morse
<mcasadevall_> Although NCommander will tell you otherwise :-P
<mcasadevall_> cjwatson, ... . -. -.. -- --- .-. . -... .- -. -.. -..- .. -.. - ....
<azeem> mcasadevall_: apparently you still have enough bandwidth to top-post on debian-devel :P
<mcasadevall_> azeem, top post?
<mcasadevall_> azeem, I sent that from my blackberry ;-)
<mcasadevall_> they aren't the best in push email for nothing
<cjwatson> mcasadevall_: .. -... . - - .... .- - ... .-- .... .- - -.-- --- ..- ... .- -.-- - --- .- .-.. .-.. - .... . -... --- -.-- ... ...-.-
<NCommander> cjwatson, -.-- --- ..- .-.   -- --- - .... . .-.
#ubuntu-devel 2008-08-09
<emgent> heya
<kirkland> slangasek: okey doke, any chance you have a couple of minutes to review/sponsor my grub-raid patch?
<slangasek> kirkland: I think so :)
<kirkland> slangasek: okay, i've pushed, waiting for Launchpad to scan my branch....
<slangasek> kirkland: OOI, do you think it would be better to drop the other patch from the tree, rather than applying && reverting?
<kirkland> slangasek: actually, that was another thing i wanted to talk to you about
<kirkland> slangasek: in the first revision, i do the minimal amount to solve this bug
<kirkland> slangasek: after you were happy with that, i was going to commit another revision that reduces that crappy 30-line function down to my 4-line equiv
 * slangasek nods :)
<kirkland> i don't actually use that function for anything
<kirkland> slangasek: but it's kinda ugly, and the comments above the .diff in the patches directory draws its providence into question
<kirkland> slangasek: i'm still getting used to bzr-based package source management, and I wasn't sure if it was better to remove a patch that's in the debian sources, or to add an ubuntu patch that undoes it
<slangasek> I would argue that it's better to remove the patch from the debian sources
<slangasek> then the "remove" is visible as part of the repo history, and doesn't have to be encoded in the current source package
<kirkland> slangasek: okay, sounds good
<kirkland> slangasek: my code will be here: https://code.launchpad.net/~kirkland/grub/33649b
<slangasek> (I would also argue for per-feature branches instead of a debian/patches directory, but I'm a ways away from ramping up on this idea myself on any packages :)
<kirkland> slangasek: as soon as Launchpad does its magic
<slangasek> ah; I somewhat expected the new revision to be on the same branch, ok, I'll go grabbing that other one :)
<kirkland> slangasek: i suppose i could have done that....
 * kirkland needs a big fat bzr-best-practices brain dump from a bzr expert
 * slangasek holds up his hands and backs away from the 'expert' label
<slangasek> although, 'bzr expert' would be a cool subcommand
<kirkland> slangasek: okay, it's there, in case you hadn't noticed
<slangasek> yep, reviewing :)
<ScottK> kirkland: I know as much as bzr co and bzr ci work like svn.
<kirkland> ScottK: :-)  i'm doing pretty well with it... but sometimes people ask me questions like "why did you create a new branch to do that?"
<slangasek> heh
<kirkland> ScottK: and I just kinda stare at them blankly thinking....  hmm, why did it?  i guess because I always just create a new branch
<slangasek> "because it was more than a single commit"
<slangasek> :-)
<kirkland> really, it's just to artificially elevate my karma
<kirkland> slangasek: i've got to head out to a rehearsal dinner
<kirkland> slangasek: the deletion of the raid.diff revision on my end will wait until tomorrow
<slangasek> kirkland: ok; unless I say otherwise in scrollback, you can expect this bit to be merged in the meantime, please just update the same branch if you refactor it
<slangasek> (and then I can merge when I'm on the ground in Argentina on Sunday)
<kirkland> slangasek: you bet, thanks a ton
<kirkland> slangasek: enjoy DebConf
<slangasek> kirkland: oh, before you go - I see you're assuming that the raid device is always going to be the first BIOS drive?
<kirkland> slangasek: the hd0, bit?
<slangasek> yes
<kirkland> slangasek: can you think of a smarter way to do that?
<kirkland> slangasek: kees seemed to be okay with it, so i just left it as is
<slangasek> not immediately :-)
<kirkland> slangasek: perhaps worthy of an inline comment, i suppose
<slangasek> is this going to regress anything that worked before?
<kirkland> slangasek: if you want to do that as you commit/push, that would be great
<kirkland> slangasek: it won't regress any non-raid systems
<slangasek> kirkland: will it regress any RAID systems? :-)
<kirkland> slangasek: for systems with /boot on RAID, the MBR writing will be handled slightly differently
<slangasek> it seems to me that it will, that previously we at least looked at device.map
<kirkland> slangasek: the only additional thing we could do is perhaps pull the bios device out of device.map if it exists in the RAID case, and assume hd0 if it doesn't
<slangasek> yes, I think that would be the right thing to do
<kirkland> slangasek: okay, i can make another another revision, but not at the moment
<slangasek> understood
<kirkland> slangasek: generating the debian/patches/*diff crap is time consuming and error prone
<slangasek> yep
<kirkland> slangasek: okay...  i'll fix that and drop you a note
 * kirkland was hoping to put this baby to bed tonight ;-)
<kirkland> tomorrow then
<slangasek> merged&pushed the current rev
<kirkland> slangasek: okay, later.
<slangasek> thanks :)
<kirkland> slangasek: oh, good
<kirkland> adios
<theunixgeek> http://digg.com/linux_unix/An_Open_Letter_to_Ubuntu
<cellofellow> Is there some trick to adding mimetypes to Ubuntu?
<ion_> File a bug against shared-mime-info, i think. Not 100% sure, though.
<TheMuso> cjwatson: Yeah I can do so first thing Monday.
<pwnguin> heh http://people.redhat.com/esandeen/ext4/e4fsck-1T.png
<rustychicken> is the timevault trunk still in active development?
<emgent> moin
<YokoZar> Will Intrepid be getting PulseAudio 0.9.11 :)
<persia> YokoZar: You might file an upgrade bug, rather than hoping for a scrollback response: it's at least as likely to get an answer, and you get notified rather than having to watch carefully :)
<persia> (that is, if you want the upgrade: if you don't, I don't have any useful suggestions)
<YokoZar> persia: good call :)
<okaratas> hello
<lukehasnoname> anyone have experience with Empathy?
<bigon> me :)
<lukehasnoname> First of all, a technical question: How do I install backends for protocols? I can't find a menu that will do that, and it won't let me add accounts of any kind unless I have these backends instaleld.
<lukehasnoname> *installed
<lukehasnoname> and the help menu isn't working. I'm on Hardy.
<bigon> lukehasnoname, do you use the package from the ppa?
<_gAri-> hi there, can you please help me out where can I find the ubuntu specific kernel patch in peaces that is applied to the vanilla kernel? I mean I only want to use parts of it, not totally
<pwnguin> _gAri-: I can't help you with the specifics, but I know that git stores diffs between revisions that you can use to pull specific patches. ive never done it myself though
<sharms> _gAri-: #ubuntu-kernel --- http://kernel.ubuntu.com
<stryd_one> hi all
#ubuntu-devel 2008-08-10
<Ziroday> what is the procedure if there is a spec that you want to help, however it seems stalled and you can't get the assignee's contact information?
<Hobbsee> wow.  intel driver is a bit trippy now.
<emgent> Hobbsee: intrepid ?
<Hobbsee> emgent: yes
<wgrant> Hobbsee: Should I not upgrade today?
<Hobbsee> wgrant: it just draws occasoinal artefacts when you open new windows.   it's fine to upgrade, apart from that.
<wgrant> Ah.
<Hobbsee> it's not a big deal - just...different
<Hobbsee> as in, it's not going to really get in the way
<wgrant> Ah.
<emgent> open virtualbox in intrepid is broken, now i use non-free.
<[Relic]> Anyone know when the ubuntu will read the temps for the 45nm intel chips?  (aka coretemp. from next kernel(.25) to this kernel(.24) and new lm-sensors version(3.0.2))
<[Relic]> I am going to have to switch to something that does do that if it doesn't happen soon.
<warren> What is the location of amixer on Ubuntu?
<warren> /usr/bin/amixer?
<crimsun> yes
<emgent> moin
<GuySoft> hello all, i want to make a package with a configuration file in etc. is there a way to tell the package that that file is taken and if needed, insert a default conf file?
<persia> GuySoft: Better to ask packaging questions on #ubuntu-motu
<GuySoft> persia, thanks, i got an answer at #debian-devel
<persia> GuySoft: Excellent.  I'm glad to hear it.
<GuySoft> persia, BTW, its done automatic.. all good for debian
<persia> GuySoft: Yep. :)
<help-please> here's a silly question, but i'll ask it anyways..Does anybody know which packages from ubuntu packages I would have to download to build a base, none gnome, none kde, Just no frills base?
<Treenaks> ubuntu-minimal ?
<persia> ubuntu-minimal might be a good place to stary
<persia> s/stary/start/
<help-please> thanks guys you hit the nail on the head :)
<slytherin> Can anyone help me to find missing seahorse-agent on intrepid?
<geser> slytherin: it got split out from the seahorse into a separate source tarball but isn't packaged yet. IIRC seb128 was working on packaging it.
<slytherin> geser: So someone is working on it. That is all I wanted to know.
<fta> gasp, last upgrade was bad (intrepid).. after a reboot, X crashed (once), gvfsd-trash crashed, and far worse, my keyboard is f*cked up (no more arrow keys, home/end keys, AltGr acts as Enter, ... in fact, they are all mapped to wrong codes)
<tjaalton> fta: bug 255008
<ubottu> Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Confirmed] https://launchpad.net/bugs/255008
<tjaalton> fta: read it through
<fta> tjaalton, yep thanks. setxkbmap -model evdev -layout fr -variant latin9 -option lv3:ralt_switch  fixed it for now
<tjaalton> fta: set the model in the keyboard capplet so it's always evdev
<fta> tjaalton, done
<persia> s/stary/start/
<theunixgeek> Hello
<theunixgeek> How are Ubuntu applications generally planned out and developed?
<theunixgeek> hello?
<theunixgeek> How do the Ubuntu developers work?
<theunixgeek> That is, what do they focus on?
<jcastro> https://wiki.ubuntu.com/UbuntuDevelopment
<theunixgeek> How do they organize their code, etc?
<theunixgeek> jcastro: thanks
<emgent> heya
<RainCT> cr3: Hey. Now that was a fast answer :). Do you prefer me to reply on IRC or by mail?
<cr3> RainCT: either way is fine :)
<cr3> RainCT: both are logged anyways, which equally compensate for my lack of memory
<beuno> hey jcastro!  how's Argentina treating you?
<cr3> RainCT: I'm particularly curious to hear how you might suggest to address the mouse and keyboard tests, I haven't been satisfied with either test for a while now
<RainCT> cr3: Do you mean the text or the complete test?
<cr3> RainCT: the complete test could be better in both cases, for the mouse and the keyboard
<RainCT> (brb)
<moquist> I'm working on the moodle package, and the binary-indep rule in the rules file removes some licenses that come in with the source tree.
<moquist> I've changed the name of the binary package, and now the build complains about the files not existing.
<moquist> here's the error and the rules file bit: http://rafb.net/p/9afeVa67.html
<RainCT> moquist: you'll have to change the "moodle" in debian/moodle to the new name of the binary package
<moquist> RainCT: what if I'm building two binary packages from the same source tree?
 * moquist pastes the control file
<moquist> control file: http://rafb.net/p/YgJCoB72.html
<moquist> there was formerly one binary package named 'moodle'
<RainCT> moquist: you'll have to duplicate the rm lines or use a loop then
<moquist> huh. OK.
<RainCT> moquist: I'm not sure if I've understood what you want to achieve, but I don't think that you'r taking the best aproach
<moquist> RainCT: I'm wide open to criticisms of this approach. I haven't actually run this by my sponsor yet...
<RainCT> moquist: to be sure that I understood it, what is the difference between the two packages?
<moquist> RainCT: the problem is that the single binary package dependencies are simply broken if both postgresql and mysql deps are in the same line.
<moquist> even if the deps are pgsql|mysql, if you happen to have one of the mysql packages installed then you'll get a mix of pgsql & mysql, and it won't work.
<RainCT> (moddle is in main, btw, so the MAintainer should be Core Dev, not MOTU)
<moquist> email addr?
<RainCT> moquist: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<moquist> RainCT: thank you
<RainCT> moquist: (update-maintainer from ubuntu-dev-tools does the Maintainer change automatically for you)
<moquist> actually, this is targetted for debian, so I'm not sure what will end up there. but for now it says Ubuntu Core Dev.
<moquist> RainCT_: is there a good reason I shouldn't use brace expansion? e.g., 'rm debian/{pkga,pkgb}/rest/of/path.txt' ?
<moquist> hm. with -f, I guess.
<RainCT_> moquist: yea that should work
<moquist> RainCT_: OK, I'll go that route then. Thanks for all your help.
<RainCT> moquist: so what's the problem you have with the dependencies exactly?
<RainCT> moquist: that if you have neither of the databases installed you'll get some packages from both or what?
<RainCT> cr3: Sorry; I have time now :). For the text, I think just removing the introductory sentence should be enough; about changing the test I couldn't think of anything which I like.
<cr3> RainCT: changing the introductory text for which test, both mouse and keyboard, or one of them in particular?
<RainCT> cr3: both, imho what they say is obvious enough
<cr3> RainCT: sure, I'll have a look at it then
<RainCT> cr3: For the $(...) things, it's not that they had text next to them or something so I don't see why you would want to put them between _( and )  (or whatever you use for the translations).
<RainCT> moquist: anyway, I'll show you how I'd do it
<RainCT> moquist: http://rafb.net/p/VillPv83.html
<RainCT> moquist: (moodle-postgres and moodle-mysql would just be empty packages)
<moquist> RainCT: beautiful. that's obviously better; thanks
<RainCT> moquist: if libdbd-mysql-perl is only necessary for MySQL you can move it to moodle-mysql package, too
<RainCT> moquist: no problem :)
 * moquist nods
<RainCT> moquist: it may also be good to add (= ${source:Version}) to the moodle-postres and moodle-mysql dependencies
<geser> moquist: dash doesn't support brace extension
<moquist> geser: noooooo! :\
<RainCT> moquist: well, now it doesn't matter with the approach I've told you, or? :)
<moquist> Yeah. I just like to whine about dash. :)
<RainCT> hehe
<moquist> RainCT: I don't understand the ${source:Version} addition. I can guess what it's doing, but I don't really know.
<moquist> RainCT: and is this what you mean? http://rafb.net/p/JFsIFo54.html
<RainCT> moquist: ${source:Version} will automatically be replaced by the current revision number of the package
<RainCT> moquist: so adding it you ensure that moodle and moddle-{mysql,postgre} are the same version (that's important in the case that with future version the database dependencies change)
<jcristau> you want to read the deb-substvars(5) manpage
<moquist> RainCT: OK, that's more-or-less what I figured was going on, but ... I think I'll take a look at the man-page.
<RainCT> moquist: and no, it's like this how you would write them: http://rafb.net/p/uOmKSc90.html
<moquist> RainCT: ah! that already makes this much clearer.
<RainCT> cr3: About the untranslatable strings, "Internet connection fully established" is the only one, I think. The words after "Running test:" can't be translated neither but that may be intended
<RainCT> cr3: ah, and on the "the following information will be send" page, 4 out of the 5 strings are cut when translated into Catalan
<RainCT> (as in, the first characters are replaced by "...")
<RainCT> (uhm.. I thought GTK would be more clever; "Detalls" gets replaced by "...talls", making it even longer then it would be LOL)
<moquist> ...heh
<ion_> ...h
<moquist> RainCT: I just have one debian/rules file right now. Am I going to need a debian/moodle.rules, a debian/moodle-mysql.rules, etc? I'm building now and it hasn't failed yet, but I guess I don't understand why the moodle-* packages won't still have the same problem.
<RainCT> moquist: No. But if there is a debian/install, debian/links file or something like that you'll have to rename it
<moquist> RainCT: to debian/moodle.install and debian/moodle.links?
<RainCT> moquist: yes
<moquist> k; thx
<RainCT> moquist: about the failure which you got: files for binary package moodle are placed into debian/moodle at build time, and the rules file accesses those files inside there when it does the rm. when you renamed the package, they went to either debian/moodle-postgre or debian/moodle-mysql (you'd need to do more changes than the rm to debian/rules for your approach to work), so the "rm -f debian/moodle/.." didn't work anymore, of course
 * moquist nods
<RainCT> moquist: (FYI, for the case you've ever uncompressed a .deb, you'll know that there's a control.tar.gz and a data.tar.gz inside it; the data.tar.gz is, afaik, exactly the same as the debian/<binary_package_name> directory)
<BenC> Anyone know why on latest intrepid, some of my command line programs suddenly can't make connections to the internet (lan connections work)?
<moquist> now it's upset b/c it can't find debian/install that I just renamed
<moquist> RainCT: Yes.
<BenC> e.g. firefox can connect to www.google.com, but "telnet www.google.com 80" never connects
<ion_> benc: Anything interesting in straceâs output?
<moquist> BenC: do you have a proxy configured in FF? have you tried running tcpdump on your telnet?
<ion_> Yeah, tcpdump, too.
<BenC> even stranger, apt-get works, but telnet archive.ubuntu.com 80 doesn't :/
<BenC> no proxy
<BenC> and no other machines on my network experience this
<Treenaks> hardware failure?
<BenC> I seriously doubt hardware could limit _some_ programs
<BenC> how can I limit tcpdump to a certain remote host?
<Treenaks> MTU?
<BenC> Treenaks: MTU wouldn't be different betweek apt-get and telnet
<BenC> *between
<Treenaks> BenC: no, but telnet sends smaller packets
<Treenaks> BenC: and receives
<BenC> Treenaks: which should mean it would be more likely to work, not break :)
<BenC> git is also broken, and is ssh
<Treenaks> hmm.. _reverse_ path mtu failure..
<RainCT> cr3: something more: it may be better to let GTK wrap the text automaticaly instead of forcing that with \n
<moquist> BenC: tcpdump -i eth0 host <name|ip>
<BenC> 14:52:09.851645 IP cunning.phunnypharm.org.59548 > yo-in-f103.google.com.www: S 3309534473:3309534473(0) win 5840 <mss 1460,sackOK,timestamp 317392 0,nop,wscale 7>
<BenC> 14:52:12.848519 IP cunning.phunnypharm.org.59548 > yo-in-f103.google.com.www: S 3309534473:3309534473(0) win 5840 <mss 1460,sackOK,timestamp 318142 0,nop,wscale 7>
<BenC> that's all I'm showing
<BenC> repeats like 5 times
<BenC> the syn from elinks (which works) looks to be the same
<BenC> 14:56:29.489243 IP cunning.phunnypharm.org.34738 > yo-in-f99.google.com.www: S 3098605745:3098605745(0) win 5840 <mss 1460,sackOK,timestamp 382301 0,nop,wscale 7>
<BenC> I get an immediate ACK from that
<elmo> BenC:  this really sounds like a proxy
<elmo> BenC: everything that works has proxy support
<BenC> elmo:  if it's a proxy, it's something intrepid installed on my system that I didn't ask for
<elmo> BenC: hmm, what's $http_proxy?
<BenC> elmo: I checked my system, and proxy settings are disabled...
<BenC> elmo: not set
<BenC> $ env | grep -i proxy
<BenC> bcollins@cunning:~$
<BenC> running as root doesn't help either
<BenC> ssh -vvvv shows this as the last part
<BenC> debug2: fd 3 setting TCP_NODELAY
<BenC> debug2: callback done
<BenC> debug2: channel 0: open confirm rwindow 0 rmax 32768
<BenC> it gets through authentication, and stops just before I get a shell
<BenC> hmm...two things happened before this started...I dist-upgraded....and I switched to a bcm4321 card and the closed wl driver
<BenC> could the wl driver be this braindead?
<BenC> Only one way to find out I guess
 * BenC high fives broadcom on the dumbest thing he's ever seen a driver do
<elmo> BenC: wow, seriously?
<BenC> elmo: yeah...I switched back to my intel 4965 and everything is working fine
<Treenaks> BenC: so what's the bug?
<BenC> Treenaks: the bug is broadcom needs to fix their driver
<Treenaks> BenC: obviously
<BenC> I only wonder if it's a regression with 2.6.26, or if it was like this with 2.6.24 too, but I don't have time to track it down
<BenC> Treenaks: If there was code for me to debug, I would track it down further...but me and binary blobs don't play well together
<johanbr> BenC: ssh works for me on 2.6.24-20-generic with the wl driver
<BenC> johanbr: want to see if it breaks with 2.6.26 kernel?
<johanbr> BenC: Sure, just give me a minute.
<johanbr> BenC: ssh with 2.6.26-5-generic and wl works too. My card is 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4328 802.11a/b/g/n [14e4:4328] (rev 03)
<BenC> johanbr: odd
<BenC> johanbr: Are you behind a NAT firewall?
<johanbr> BenC: MTU issues?
<BenC> I wonder if that's part of what is breaking things
<johanbr> BenC: Yes, there's NAT. All wireless clients here have to go through a cisco vpn.
<BenC> Then I'm not sure exactly what in my setup is triggering the problem, but it surely _shouldn't_ happen :)
<johanbr> BenC: Does it matter if you ssh inside or outside your lan?
<BenC> johanbr: everything inside the lan worked...it was external connections that failed with _some_ programs
<johanbr> weird
<BenC> elinks/firefox => worked....telnet to port 80 (to same hosts) didn't
<BenC> ssh didn't work
<BenC> pidgin works, apt-get works
<BenC> and ssh connected, but halted just before dropping to a shell
<BenC> telnet wouldn't even connect...even tho the syn packet looked just like the one from firefox/elinks
<johanbr> Very strange. I'll try again when I get home - there I have an ordinary NAT setup for the wireless.
<BenC> I'm just working behind a wrt54g with dd-wrt firmware
<BenC> never had a problem like this, so it's really strange
<mdke> i was quite curious to hear about alfresco being shipped in the Canonical repo, does anyone happen to know of an ETA on that? I'd be very interested to try that application
<mdke> I'll try and install it "the linux way" but the procedure looks pretty fierce
<johanbr_> BenC: I'm home now. ssh through NAT on 2.6.26-5-generic hangs for me too.
<BenC> sweet, now I don't feel so weird
<BenC> johanbr_: thanks for testing
<johanbr_> No problem. Let me just reboot and see if it happens on -24.
<johanbr> BenC: Same thing on -24. And if I route the ssh traffic through a VPN, it works fine.
<BenC> johanbr: ah, so not a regression
<BenC> so can't blame it on the kernel
<BenC> johanbr: what wireless ap are you using?
#ubuntu-devel 2009-08-03
<bluefoxicy> I have a question about packaging.
<bluefoxicy> Why is the version of Evolution in Ubuntu shipped without support for "Send an e-mail" as an alarm action?
<bluefoxicy> it's there, yet grayed.
<YokoZar> Is Firefox 3.5 scheduled for alpha 4?
<\sh> moins
<slytherin> A quick question. Does 'better dependency calculation' work for programs linked against gtk2 libraries?
<james_w> which package provides the knotify stuff in KDE?
<Riddell> james_w: >dpkg -S /usr/bin/knotify4
<Riddell> kdebase-runtime: /usr/bin/knotify4
<Riddell> if that's what you're after
<james_w> thanks
<mdz> TheMuso, where is that PPA you mentioned this morning? I'm happy to install the latest pulseaudio and test
<StevenK> mdz: http://launchpad.net/~ubuntu-audio-dev/+archive from TheMuso's mail to -platform
<mdz> StevenK, thanks, can't get to my mail atm
<directhex> yay for mdz getting his bag back
<mdz> apparently I am one of the lucky ones
<directhex> mdz, well, a lost bag not being blown up by the bomb squad is an event
<TheMuso> mterry: You are the first person who has had a pulseaudio upgrade problem of that nature, which makes me think that its probably something to do with your system.
<TheMuso> I have installed these packages fresh several times over the last week or so, and no changes were made to the upgrade scripts, and I had no problems, and it seems others are not either.
<mterry> TheMuso, fair enough....  looked like bad syntax of some dpkg call, which would surprise me if it was machine dependent, but if I'm the only one...
<TheMuso> mterry: I'll still take a look though.
<TheMuso> mterry: Actually, found the problem, thanks for the heads up.
<mterry> TheMuso, sweet
 * cjwatson finally fixes the stupid bug where console-setup doesn't work on boot
<TheMuso> mterry: Give it an hour max, and new pulse packages should be available with the fix.
<TheMuso> I've not long uploaded the fix.
<mterry> TheMuso, awesome, thanks
<mdz> cjwatson, I wonder if we shouldn't seed iw in all of the places where wireless-tools currently is
<slytherin> is there any particular reason why gtk+2.0 package in karmic does not contain libgtk2.0-0.symbols file?
<seb128> slytherin, we didn't merge on debian since they added it
<seb128> slytherin, it's probably useful for gtk but no fun to maintain because you have to build gtk once for nothing, get to break because .symbols is not updated, do the update, etc
<slytherin> Anyway, I am not sure how much the symbol file form Debian will be useful as it is old version.
<l3dx> off-topic: anyone know a good resource for setting up emacs for C++ dev?
<seb128> slytherin, the idea is that you should update that file which each update
<slytherin> hmm
<slangasek> pitti: hal in karmic has debian/patches/04_nvidia_brightness.patch, but it's not in the series file?
<slytherin> I can understand why it is not easy task.
<slangasek> pitti: (I would like it to be in the series file)
<seb128> slangasek, isn't hal deprecated anyway?
<slangasek> seb128: is something else doing backlight handling today?
<seb128> isn't gnome-power-manager doing that using devkit-power?
<slangasek> I don't know
<slangasek> seb128: basically, I'm trying to bring closure to bug #277589, which continues to haunt me because people affected by it are making arbitrary changes to their fdi files in ways that fix it for them, break it for everyone else, and provide no guidance regarding a fix that can be integrated properly :/
<ubottu> Launchpad bug 277589 in hal "sony brighness on a geforce series older than 8 (nvclock works fine)" [Medium,In progress] https://launchpad.net/bugs/277589
 * slangasek finds no instances of 'bright' or 'backlight' in the devicekit-power source, so I guess it's not doing it today?
<seb128> slangasek, that's a question for pitti I guess, I didn't look at that closely
<slangasek> seb128: pull pitti's beard to make him pay attention to me, then ;)
<seb128> slangasek, done
<pitti> hey
<pitti> slangasek: that sounds like a bug indeed, it's supposed to be there
<pitti> slangasek: ah, I might have disabled it because we don't use it any more anyway
<pitti> but that might have been a lie, g-p-m still talks to hal for brightness
<pitti> so if it fixes it, let's re-add it
<pitti> slangasek: beard> ouch :)
<slangasek> pitti: it doesn't fix it, I just noticed as I went to try to follow through on it that the patch wasn't applied
<slangasek> pitti: anyway, I need your brain to help me with the question in https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/277589/comments/51 in order to finally nail this, I think
<ubottu> Launchpad bug 277589 in hal "sony brighness on a geforce series older than 8 (nvclock works fine)" [Medium,In progress]
<slangasek> (or, well, if your brain is not available, I'll muddle through and come up with something that looks suitable to me)
<pitti> slangasek: right, that would make sense; they need to point to the smartdimmer specific scripts to change the brightness
<pitti> slangasek: the get/set scripts just call some CLI tool, so it doesn't need an addon?
<slangasek> pitti: uh... that sounds accurate
<pitti> slangasek: an addon is something that runs all the time, like the process that polls CD-ROMs for media
<pitti> but since I suppose we don't need to react to events from the backlight (just from input events from keys, which is already provided), it doesn't need an addon
<TheMuso> cjwatson: I have just come up with a preliminary list of source packages that libpulse0 depends on that will need to be made bi-arch. I have a feeling that some of these are not actually depended on, so I will have to look at the pulse code to see what are actually needed, so that list may yet be trimmed.
<TheMuso> Nevertheless, there is currently 11 packages on the list. So I certainly think I will likely need help to address all of these.
<cjwatson> TheMuso: lovely :-/
<cjwatson> mdz: sounds sensible, though it's in universe right now ... this is the first I've heard of iw
<TheMuso> cjwatson: My thoughts exactly.
* You're now known as ubuntulog
<slangasek> james_w: bug #408342
<ubottu> Launchpad bug 408342 in bzr "'bzr up' fails against a read-only remote, trying to create a write lock" [Undecided,New] https://launchpad.net/bugs/408342
<slangasek> jml: ^^
<stoicaler> is it ok not to use firewalls?
<Pici> stoicaler: Please ask in #ubuntu , #ubuntu-devel isn't a support channel.
<stoicaler> ok
<stoicaler> tx
<slytherin> can someone please give back nautilus-sendto on armel?
<pitti> slytherin: done
<slytherin> thanks
<TheMuso> cjwatson: it seems that there are a few packages that libpulse0 depends upon, but are not actually needed, however due to the way pulse is built, they are linked against libpulse0 anyway, even though no symbols are used. I am going to see if I can fix this somehow.
<pitti> TheMuso: -Wl,--as-needed might work for some of them
<pitti> this usually does a good first cut of cutting down stray dependencies
<TheMuso> ok thanks
<pitti> TheMuso: LDFLAGS+= -Wl,--as-needed
<TheMuso> For the record, this caused pulseaudio to FTBFS.
<seb128> TheMuso, which means it's probably using libraries and not specifying -l<lib> for all the libs it's using
<seb128> TheMuso, and you want to use the flag on client applications to cut the unneeded depends not on pulseaudio directly
<TheMuso> seb128: I am trying to cut down on the unneeded dependencies of libpulse0, as it is linked/depends on libraries even though it doesn't use any of their symbols.
<seb128> TheMuso, right, so you need to use --as-needed on applications who depends on libpulse now wrongly
<seb128> that should cut the shlibs:depends to real depends
<slytherin> Why isn't --as-needed a default flag? does it not always work as expected?
<slangasek> ScottK: boost1.37 removed, asio appears to still depend/build-depend on it: any plans for fixing that?
<seb128> slytherin, it breaks builds when you don't use -llibraries correctly
<slangasek> ah, some other packages as well, e.g., wesnoth (checkrdepends is still running, bah)
<slytherin> seb128: Didn't know that.
<seb128> slytherin, it also doesn't work for things you dlopen etc
<sebner> slangasek: fighting with Arnaud Soyez hmm? :)
<slangasek> sebner: fighting?
<sebner> slangasek: having fun may be a better word :D
<slangasek> <shrug> I'm just pushing the buttons, archive admin duties are a fairly emotionless process :)
<sebner> slangasek: will be say that again after 10 sync requests by him? :P
<slangasek> if he continues to file sync requests inappropriately, then I'll escalate accordingly. <shrug> :)
<sebner> haha
<sebner> I'll point him to the wiki then to save him =)
<cody-somerville> ---., /;8*/,l4841794976125+*954 9kj\
<cody-somerville> oops
<StevenK> cody-somerville: Was that a cat, or your head hitting the keyboard?
<cody-somerville> Judging by the lump on my head...
<maco> the cat, then?
<mneptok> cody-somerville: if i ROT13 that do i get interesting bits of your medical history?
<slangasek> ScottK: oh right, you addressed this in the text of the bug report. <whistle>
<sebner> slangasek: I'm wondering you synced monkeysphere 0.25 where 0.26 was requested. (also testbuilt by me since pull-debian-source already pulled in 0.26 back then)
<slangasek> sebner: probably an error from not having done an update-sources first; let's try again
<sebner> slangasek: Many Thanks! :)
<momesana> hi all
<momesana> I am having problems starting X on every ubuntu version since 7.04
<momesana> it's because the via drivers suck
<momesana> now, I was wondering if the newest version of ubuntu comes with unichrome so they may work
<cjwatson> momesana: I know nothing about this directly, but https://launchpad.net/ubuntu/+source/xserver-xorg-video-unichrome says that the Unichrome driver was in 7.04, 7.10, and 8.04, and was then removed in 8.10 because it was broken (bug 284042)
<ubottu> Launchpad bug 284042 in xserver-xorg-video-unichrome "archive removal request: xserver-xorg-video-unichrome is uninstallable." [Wishlist,Fix released] https://launchpad.net/bugs/284042
<cjwatson> see also bug 196349
<ubottu> Launchpad bug 196349 in xserver-xorg-video-unichrome "xserver-xorg-video-unichrome broken in hardy." [Undecided,Won't fix] https://launchpad.net/bugs/196349
<momesana> ubottu: thanks ... 7.04 works ... it's currently installed
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<bryce> momesana, have you tried -openchrome?
<momesana> the other ones load the framebuffer driver and then immediately blank the screen so i cant do nothing but restart
<momesana> 9.04 is a little better in this respect ... it doesn't load anything but I also don't have X
<momesana> bryce: the openchrome driver fails starting X
<momesana> bryce: as does the vesa driver
<bryce> momesana, did you file a bug report?
<momesana> bryce: nope but there was a bugreport somewhere with the same error message I got ...
<momesana> and no response
 * momesana writing karmic to a disc
<bryce> bug#?
<momesana> bryce: yes, it's definetly a bug
<momesana> bryce: what I can't understand is why the vesa driver fails to load
<bryce> momesana, bug number?
<momesana> bryce: I can't remember anymore but it was on launchpad I think
<cjwatson> ... that may not narrow it down ;-)
<momesana> bryce: I will file a bugreport if I can't find it
<cjwatson> there are 39 bugs on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bugs right now
<momesana> I'll boot with the karmic driver and save both the Xorg.0.log and the Xorg file ... then try vesa etc. and save everything so the devs have something to referr to
<cjwatson> momesana: https://wiki.ubuntu.com/X/Reporting
<momesana> cjwatson: thanks, let me read the bug reports ... maybe someone has the same problem
<ogra> cjwatson, i would love to ask you to merge my debian-cd change to get imx51 in chape but somehow LP doesnt wont to show me code.LP.net today
<cjwatson> ogra: URL?
<bryce> momesana, it's probably best to file a new bug regardless; if there's one you suspect to be the same bug, just mention that and I can evaluate if it really is a dupe
<ogra> bzr+ssh://bazaar.launchpad.net/~ogra/debian-cd/ubuntu/
<ogra> cjwatson, ^^^
<bryce> often two bug reports *look* like the bug, but really need each their own fix
<ogra> cjwatson, and/or https://code.launchpad.net/~ogra/debian-cd/ubuntu
<momesana> bryce: allright :)
<momesana> bryce: strange ... it seems to work on the newest version of ubuntu ... now the strange thing is ... I downloaded karmic and it boots ubuntu?!?
<TheMuso> Has anybody ever had to clean .la files during a package build, the .la files in question being generated by the package build itself?
<seb128> TheMuso, "had"
<seb128> ?
<seb128> ie, how do you want to clean those and why?
<seb128> we stopped installing those for random package and clean content for others in gnome
<TheMuso> seb128: Clean them, as in clearing the dependency_libs variable, because its causing libraries to be uselessly linked against other libraries
<seb128> TheMuso, if you use cdbs you can include clean-la.mk
<seb128> TheMuso, that does what you want
<seb128> TheMuso, otherwise you can copy the /usr/share/cdbs/1/rules/clean-la.mk snippet
<TheMuso> seb128: yes, during the package install. My issue is with .la files that are used during the package build itself, that are internal to the package, not external.
<TheMuso> Ok, pulseaudio has several libraries that parts of itself need linking to. When these libraries are initially built, they create .la files that include dependencies which are then uselessly linked against other libraries.
<seb128> TheMuso, you can probably patch the source package directly too
<TheMuso> Yeah I think thats the best option.
<cjwatson> ogra: done
<ogra> cjwatson, merci :
<ogra> :)
<seb128> TheMuso, gtk only does clean the .la in the install target not during the build
<seb128> ie similar to what cdbs is doing, not really useful for your issue
<TheMuso> seb128: ok thanks, I'll see if I can patch the build system, perhaps ltmain.sh to work around the issue.
<seb128> TheMuso, you can try asking Keybuk about that maybe, he's the libtool expert around
<TheMuso> seb128: thats also a thought, thanks.
<TheMuso> i/c
<cjwatson> soren: any idea what http://paste.ubuntu.com/246467/ means? I just installed eucalyptus-{cloud,cc,nc} with the intention of setting up a trivial one-node cloud on localhost, and it doesn't seem to want to start the cluster
<slytherin> Can any of the archive admin please explain me what is the meaning of error 'failed to upload'?
<cody-somerville> slytherin, soyuz issue
<cody-somerville> cprov, ^^
<cody-somerville> slytherin, link to upload log?
<slytherin> just a sec
<slytherin> https://edge.launchpad.net/ubuntu/karmic/+source/lucene2/+builds
<cprov> slytherin: it means you source was built successfully but resulted in binaries that cannot be uploaded.
<slytherin> I got the error twice for same package. First I thought was transitional so I tried it again.
<slytherin> let me paste the email notification content.
<slytherin> cprov: http://paste.ubuntu.com/246545/
<cprov> slytherin: it's an issue processing one of the emails in the changesfile
<slytherin> is it known issue?
<cprov> slytherin: right, we all can access it directly from librarian -> http://launchpadlibrarian.net/29832266/upload_1145807_log.txt
<cprov> slytherin: no, not really
<slytherin> So I guess there is nothing I can do than wait.
<cprov> slytherin: this email is associated with an account but it has no user ... weird.
<slytherin> the package was synced from Debian.
<cprov> slytherin: can you please file a bug, while I investigate it
<slytherin> sure.
<cprov> slytherin: thank you.
<slytherin> cprov: bug 408528
<ubottu> Launchpad bug 408528 in soyuz "lucene2 synced from Debian, built fine but failed to upload" [Undecided,New] https://launchpad.net/bugs/408528
<Laney> can someone unprivate bug 408499?
<ubottu> Bug 408499 on http://launchpad.net/bugs/408499 is private
<AnAnt> Hello, I got a question about NotificationOSD
<AnAnt> how can I disable a certain capability ?
<maco> AnAnt: can't
<maco> well unless you mean like "tell pidgin not to notify when someone signs on"...then the answer'd be "configure it in pidgin"
<AnAnt> maco: no, I mean, there is a capability called truncation, can I disable that ?
<maco> as a user? or as an application developer?
<maco> as a user, there's very little able to be configured
<AnAnt> developer
<AnAnt> I use python
<AnAnt> so I do pynotify.get_server_caps() to get capabilities
<AnAnt> so I find that 'truncation' is one of them
<AnAnt> can I disable that ?
<Sp3c1alK> is there an API for ubuntu?
<Sp3c1alK> or some type of documentation for code, more specifically networking?
<directhex> um... that sorta depends on which of the several thousand programming languages available to you you decide to use
<directhex> and is also not an ubuntu question
<directhex> and is also a bit off-topic
<directhex> (this channel is for development OF, not ON, ubuntu)
<Sp3c1alK> yeah, I figured people who were developing ubuntu would know of an api
<directhex> well... sure. I'd use System.Net or System.Web from your local friendly C# compiler
#ubuntu-devel 2009-08-04
<hdon> hey guys. i play an FPS game online occasionally. i recently switched to Ubuntu (jaunty) and i am having a problem. it seems that the sound latency is very high. my instinct tells me to blame this on the sound mixer daemon. can anyone give me advice on:
<hdon> 1) disabling the sound mixer daemon and giving my game direct access to the audio dac
<hdon> 2) changing options for sound mixer daemon to decrease latency
<hdon> or 3) getting the source code for the sound mixer daemon so i can see if i can improve it
<ebroder> I'm working on a script to install a VM (no, none of the ones that exist work for various reasons). Does anybody know how to install grub onto a block device when, e.g., /dev is laid out differently from how it will be for the guest?
<alkisg> asac: I tried putting https://edge.launchpad.net/~network-manager/+archive/trunk in my sources and I still got the same problem (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/391040).
<alkisg> But there's another problem now, the "[ ] Available to all users" checkbox is grayed out and I can't check it at all, even if I run nm-connection-editor with sudo.
<ubottu> Launchpad bug 391040 in network-manager "When eth0 is unmanaged, system connections for other NICs aren't displayed nor used" [Medium,Triaged]
<Keybuk> wow
<Keybuk> the new "Add comment" not-a-button AJAXness is confusing
<TheMuso> c
<Keybuk> 1 program still needs to close:
<Keybuk> (Waiting for) explorer.exe
<Keybuk> Playing logoff sound...
<Keybuk> To close the program that is preventing Windows from restarting,
<Keybuk> click Cancel, and then close the program.
<Keybuk> *seriously*
<directhex> Keybuk, is Windows ready for the desktop?
<gnarl> cjwatson, Do you know whether fb=false as a boot argument would change something within the alternate installer?
<cjwatson> yeah, disables its use of the framebuffer
<gnarl> cjwatson, Ok, so that is parsed there then. So the alternative is some serial mode then?
<Daviey> talking of which.. /me wonders of the possibility of serial support in the shipped memtest :)
<Daviey> it's a compile option now iirc
<cjwatson> gnarl: no, plain console
<cjwatson> UTF-8 doesn't work right in that case, so the language selection is cut way down
<smoser> james_w, i'm told you can bump import priority of a package getting pulled into bzr launchpad.... can you do that for schroot ? ie : https://code.launchpad.net/ubuntu/+source/schroot
<cjwatson> you get only the languages that are representable within ISO-8859-1, so basically Western European languages
<gnarl> cjwatson, Ok. Thanks for that. Seems some ati cards do not like the fbcon... but run without
<soren> cjwatson: It doesn't look familiar, I'm afraid. I do know, though, that putting the NC on the same box as the CC/CLC is known to be "interesting".
<TheMuso> slangasek: like your comment re reiserfsprogs. :) For some reason, I found it somewhat amusing.
<slangasek> it leaves so much unsaid
<directhex> i missed a joke? :(
<james_w> smoser: I'm working on it, but found a bug I want to fix first, sorry
<smoser> james_w, no problem
<cjwatson> soren: bugger. I really don't want to have to wrangle multiple machines for this test. But regardless I think it's happening even before the NC is started
<soren> cjwatson: Did you just installe the packages or did you do any of the configuration bits?
<cjwatson> soren: I think I just installed them
<cjwatson> (it was yesterday, moved on to iscsi today so dumped some of the swap ...)
<cjwatson> I believe I was loosely following https://help.ubuntu.com/community/Eucalyptus
<TheMuso> c
<pitti> Riddell: is this still a valid heuristics for "KDE is running"? "pgrep -x -u 1000 ksmserver"
<pitti> Riddell: (it's currently what ubuntu-bug is testing)
<ojwb> i'd think $UID would be better than 1000
<pitti> ojwb: sure, it does that
<Riddell> pitti: yes that should be fine
<pitti> well, it uses `id -u`
<pitti> Riddell: cheers
<ojwb> ah
<cjwatson> TheMuso: Constructing pulseaudio-module-rygel-media-server--dbg_0.9.16~test3-0ubuntu1_i386.deb
<cjwatson> TheMuso: shouldn't that "--dbg" be "-dbg"?
<blackxored> hello everybody
<jpds> jdstrand_: I cannot get on a wireless network after the latest apparmor upgrade on Karmic: [  154.835033] type=1503 audit(1249393261.621:28): operation="capable" pid=4104 parent=3124 profile="/sbin/dhclient3" name="net_raw"
<directhex> can someone un-private 408499 ?
<Pici> jpds: Is there a bug logged on that? Lots of people in #ubuntu+1 are scrambling around looking for the cause of their network woes
<cjwatson> Pici: the kernel team's looking at it at the moment, I believe
<cjwatson> apw: ^-
<Pici> cjwatson: okay :)
<cjwatson> which isn't to say somebody shouldn't file a bug with details ...
<Pici> Bug 408862 was logged a little bit ago
<ubottu> Launchpad bug 408862 in network-manager "dhcp and networking failure in karmic" [Undecided,New] https://launchpad.net/bugs/408862
<jdstrand> jpds: known bug, it is fixed
<jdstrand> jpds: just do /etc/init.d/apparmor stop, get networking going, then upgrade apparmor to ubuntu9
<apw> cjwatson, the above incantation will be added to the bug shortly ...
<jdstrand> jpds: depending on how you start networking, possibly need to also restart networkmanager
<jpds> jdstrand: Hmm, OK; looks like ubuntu9 isn't on the gb.archive mirror.
<slangasek> mathiaz: ok, no, mysql-dfsg-5.1 doesn't FTBFS for me on Debian/amd64
<slangasek> mathiaz: so I guess the symbols file is correct, even if the use of yassl is gratuitous
<mathiaz> slangasek: so does it still make sense to remove the symbols.amd64 file in Ubuntu?
<mathiaz> slangasek: or should the file just be updated?
<slangasek> mathiaz: remove it
<stefanlsd> mathiaz: the symbols documentation i wrote help somewhat?
<slangasek> stefanlsd: it's a C++ library exporting lots of garbage internal symbols - documentation is not the problem here, it's finding a sane path out :-)
<stefanlsd> slangasek: heh. sounds messy.  oki. cool :)
<Riddell> ArneGoetje: where are you?
<doko> Laibsch: any reason you reset the status of bug reports form triaged to invalid without checking?
<jdstrand> jpds: it was uploaded a couple hours ago, so it needs to propagate
<jpds> jdstrand: Yep, thanks :)
<ArneGoetje> Riddell: Community room
<doko> Laibsch: you're undoing the work of the people who did triage the reports. this kind of "work" is no help
<Laibsch> doko: yes.  how about "with the help of the OP I confirmed a couple of bugs where errouneously still left open" by just doing that?
<Laibsch> doko: nonsense
<Laibsch> Look at the reply in the bug
<Laibsch> And tell me why you want to discuss this in public
<doko> Laibsch: for bug 39068 even you can check where the file is located. then just add a comment `confirmed' or something like this
<ubottu> Launchpad bug 39068 in bash "clear_console should be moved to ncurses-bin" [Low,Incomplete] https://launchpad.net/bugs/39068
<Laibsch> sorry, I did not really understand the issue in the bug
<Laibsch> I'll admit that
<Laibsch> a bug untouched for three-and-a-half years should be OK for a ping
<mterry> w00t, upgrading-checklist is now published online: http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
<Laibsch> I'm not pinging after three month like others do
<Laibsch> so, yes, doko, your tone was absolutely uncalled for
<doko> Laibsch: well, you'r not touching bug 1 in the same manner, do you?
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<Laibsch> I don't even know what to answer to that
<Laibsch> apples and oranges doesn't even come close
<Laibsch> I also don't think that bug hasn't had anybody make an addition for 3,5 years
<Laibsch> that bug 1 ...
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<Riddell> asac: http://people.canonical.com/~jriddell/kde-4.3/
<asac> Riddell: http://tinyvid.tv/ ... those should work
<asac> Riddell: http://www.mozilla.com/firefox/video/
<ArneGoetje> Riddell: do you need anything from me?
<Riddell> ArneGoetje: are .pdf files preferred modifiable form?
<Riddell> hmm, typo
<ArneGoetje> Riddell: ?
<Riddell> ArneGoetje: are .odf files preferred modifiable form?
<Riddell> no, still wrong
<Riddell> ArneGoetje: are .otf files preferred modifiable form?
<ArneGoetje> Riddell: for what purpose?
<Riddell> for making fonts
<ArneGoetje> Riddell: wait a moment, I'm coming over...
<ArneGoetje> Riddell: where are you?
<Riddell> ArneGoetje: desktop room,
<Riddell> o'connel
<TheMuso> cjwatson: Ok, so after further processing of the dependencies of pulseaudio needing bi-arch packages to allow pulse libs to be bi-arch, we have a total of 13 packages. Some were trimmed, but some have been added since then. Here is the list of source packages: http://paste.ubuntu.com/247292/
<TheMuso> Question is, whether this is worth pursuing.
<TheMuso> If so, then while I can help with some, I certainly don't think I have the time to help with all, at least not till after feature freeze.
<cjwatson> with that sort of number, I guess it's a question of whether slangasek thinks multiarch will be ready enough in time to cover this much
<cjwatson> this is a regression from jaunty, I'm told, and therefore it's ipso facto worth pursuing
<ogra> cjwatson, can you merge https://code.launchpad.net/~ogra/debian-cd/ubuntu once again ?
<TheMuso> cjwatson: Ok I think we could ask various teams who maintain some of those packages to help us out, and I could certainly get some of the others done, however I still have a fair bit of code to write before feature freeze, so maybe the community can help with the rest, of which I'd be happy to sponsor.
<cjwatson> ogra: done, thanks
<slangasek> cjwatson: mutter, mumble, <hack hack>
<ogra> cjwatson, thanks as well :)
<TheMuso> slangasek: Heh I am not so pleased as to the not so elligant solution.
<TheMuso> either
<liw`> doko, are you working on the eglibc resolver bug?
<slangasek> TheMuso: sorry, I mean "pardon me while I hack on multiarch instead of answering"
<TheMuso> slangasek: ah ok. :)
<doko> liw`: no, currently in a breakout session :-/
<doko> liw`: same with the debian package, so no compiler difference with 4.3/4.4
<liw`> doko, ack
<TheMuso> Well I'll start working on packages locally, and wont' upload them till an answer is given. :)
<Tronic> Why does a bug search for "performous" find a lot of bugs (that apparently don't contain that term)?
<Tronic> => how do I search for bugs related to this package?
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/performous/+bugs
<Tronic> Is it possible to access this from UI or do I need to edit the URL?
<Pici> Tronic: Find the package in Ubuntu on Launchpad and then click on the bugs tab
<cjwatson> (launchpad.net/ubuntu -> Find a Package)
<AnAnt> Hello, is it possible for a python app using notify OSD (pynotify) to disable a certain capability ( which is truncation) ?
<Tronic> Thanks, that helps :)
<Tronic> I still wonder why performous would find so many bugs, though.
<cjwatson> fuzzy matching? somebody's username? dunno
<superm1> pitti, i was just running jockey and came across bug 403925 and noticed you fixed it in rev# 364 if you want to add information to debian/changelog to close it on next upload
<ubottu> Launchpad bug 403925 in jockey "jockey-text crashed with OSError in _execute_child()" [Undecided,New] https://launchpad.net/bugs/403925
<pitti> superm1: thanks! done
<bigon> does anyone use cowbuilder-dist on karmic for building sid pkg?
<bigon> because it doesn't work here for me
<Daviey> bigon: I just cowbuilder-dist on jaunty for building sid packages, if that helps?
<bigon> it is working for me too on jaunty, ok I will investigate
<bigon> thx
<ebroder> Has anybody ever managed to install grub onto a loop device?
<directhex> can't say i've ever felt the need to try
<dschulz> hi all
<dschulz> just upgraded the kernel to 2.6.31-5-generic #24 and it seems there's a regression
<dschulz> inotify is missing events
<azeem> dschulz: sounds like something you should investigate upstream
<azeem> judd: kernel versions
<azeem> hrm, wrong window, sorrrrry :)
<ebroder> directhex: I'm working on a VM installer
<dschulz> azeem: ok
<directhex> doko, irritating contentless ping
<dupondje> https://bugs.launchpad.net/ubuntu/+source/dutch/+bug/407951 <- somebody want to check this ?
<ubottu> Launchpad bug 407951 in dutch "Sync dutch 1:1.10-1 (main) from Debian unstable (main)." [Wishlist,New]
<soren> Do I need to file a bug to get a package synced or can a friendly archive-admin sync poldi from Debian for me?
<StevenK> soren: There's no Ubuntu changes, but it builds and installs fine?
<soren> StevenK: Yes.
<StevenK> soren: Synced.
<soren> StevenK: Thanks very much.
<TheMuso> cjwatson: I think we need to get bi-arch pulse solved ASAP, as I am already receiving bug reports from users that skype/insert app here are not working due to the pulse alsa plugin missing from /usr/lib32/alsa-lib
#ubuntu-devel 2009-08-05
<mneptok> anyone here have an Intel Atom platform running Jaunty with all updates applied?
<mneptok> (netbook owners? anyone? Bueller?)
<krisives> Nope :(
<directhex> mneptok, wifey, it might not be 100% updated tho. why?
<mneptok> directhex: Totem and VLC are failing miserably on 2 Atom platforms here. with multiple codec types, including Theora.
<directhex> hm
<directhex> remind me tomorrow
<nenolod> hmm.  when trying to generate a jaunty or karmic chroot with debootstrap, i get a hang at "I: Configuring console-setup..."
<nenolod> did something change today?
<vimpulse> Sarvatt:  hey.  Could you please forward me your mail to the Xorg nv maintainer about nv-2.1.12-gf7025-gf7050.patch?
<pitti> Good morning
<RampagePS> good morning
<TheMuso> dtchen: There have actually been discussions here at the sprint this week about making bi-arch pulse libs available. It requires touching a lot of  dependencies, but I think cjwatson's aim was to clean up ia32-libs somewhat. He may be able to fill you in more about what the foundations team plan is.
<davmor2> bryce_away: bug 403175 the issue I have is that with the fglrx driver enabled I get no terminals etc at all, so I can't run any commands to help track down the issue.  If there is a way around that then I might be able to help you out more.  With the fglrx driver disabled in any manner the system works fine.  I'll hopefully be running some tests latter today so I'll see a) if it's still and issue and b)If I can acce
<ubottu> Launchpad bug 403175 in fglrx-installer "New GDM doesn't play well with ati fglrx" [Undecided,Invalid] https://launchpad.net/bugs/403175
<cjwatson> nenolod: maybe in karmic, but certainly not in jaunty ...
<nenolod> cjwatson: i'm seeing it on jaunty since this evening
<nenolod> cjwatson: i think it may be a bug in debootstrap failing to suppress debconf prompts correctly though
<dupondje> https://bugs.launchpad.net/ubuntu/+source/dutch/+bug/407951 <- somebody want to check this ?
<ubottu> Launchpad bug 407951 in dutch "Sync dutch 1:1.10-1 (main) from Debian unstable (main)." [Wishlist,New]
<cjwatson> nenolod: sure, but nothing relevant has changed in jaunty that recently, so I wonder if it's some other environmental difference triggering it
<nenolod> not sure.  i'll investigate more and open a bug where appropriate.
<AnAnt> Hello, is it possible for an app using notify-OSD to disable "truncation" capability from notification daemon ?
 * dupondje hopes somebody can sync dutch package from unstable, cause it fixes a quite annoying bug !
<tseliot> pitti: can you remove the dontzap package from Karmic, please?
<StevenK> tseliot: It's broken?
<tseliot> StevenK: no, it's just that zapping can be enabled/disabled with setxkbmap and there are UIs (in Gnome and KDE) to do that in Karmic
<tseliot> StevenK: actually, yes, it's broken ;)
<StevenK> tseliot: Oh, where's the UI in Gnome?
<StevenK> tseliot: This was being complained about in the -devel ML
<tseliot> StevenK: System/Preferences/Keyboard then select the layouts tab and click the layout options button
 * tseliot should write a tutorial about this in GNOME and KDE...
<Riddell> I was about to ask, where's the GUI in KDE
<tseliot> Riddell: System Settings -> Region & Language. Then select Keyboard layout in the treeview, select the Advanced tab and you will find the "Key sequence to kill the X server"
<tseliot> Riddell: this means that you can drop my patch for zapping from kdebase
<Riddell> tseliot: so it is, not very discoverable but it's in there
<Riddell> tseliot: yes the patch has gone
<tseliot> Riddell: something worth mentioning in the release notes, no?
<pitti> tseliot: hey; sure, done
<tseliot> pitti: thanks a lot :-)
<mathiaz> kees: bug 408333
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/408333/+text)
<mathiaz> kees: https://wiki.ubuntu.com/MIRmysql-5.1
<jml> hey
<jml> the design for the new soyuz build page is online at the launchpad wiki, might be worth looking at & commenting on: https://dev.launchpad.net/SoyuzBuildIndexPage
<iulian> Tap-to-click doesn't work anymore in Karmic.  Who took it away? :-(
<iulian> Is there any bug reported regarding this regression?
<ogra> iulian, just check the checkbox
<iulian> ogra: Ah, cool!
<iulian> Thanks.
<ogra> ;)
<dupondje> https://bugs.launchpad.net/ubuntu/+source/dutch/+bug/407951 <- somebody want to check this ?
<ubottu> Launchpad bug 407951 in dutch "Sync dutch 1:1.10-1 (main) from Debian unstable (main)." [Wishlist,New]
<seb128> dupondje, subscribe the ubuntu-main-sponsors to the bug
<dupondje> they are subscribed :)
<seb128> dupondje, so what are you asking for exactly?
<dupondje> if it could be synced, cause it removes a crappy bug in the 'dutch' package :)
<seb128> it probably could and it will when somebody will have looked at it
<seb128> if nobody did is that because people are either on holiday or busy usually
<seb128> the IRC pings are not really useful usually, see http://people.canonical.com/~dholbach/sponsoring/index.html for all the bugs waiting
<bryce> seb128, bug 397839 and bug 387529
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/397839/+text)
<ubottu> Launchpad bug 387529 in gnome-power-manager "screen goes black after a while even when typing" [Undecided,Incomplete] https://launchpad.net/bugs/387529
<bryce> seb128, refiled 397839 to gnome-power-manager
<StevenK> I've seen that on Karmic UNR too
<bryce> the other bug could be duped to that one I guess
<seb128> bryce: thanks
<asac> tkamppeter: 282235
<plars> bryce: did bug #378391 regress again, or is it broken again now for different reasons?
<ubottu> Launchpad bug 378391 in xserver-xorg-input-synaptics "Source rename clobbered local changes (so tapping not working in Karmic)" [High,Fix released] https://launchpad.net/bugs/378391
<plars> bryce: iirc, it worked ok in alpha3, but is now broken again in the dailies
<bryce> plars, well it wouldn't be for the same reason since the source package hasn't been re-renamed ;-)
<bryce> plars, file a new bug
<plars> bryce: will do, thanks
<bryce> plars, 105_correct_multifinger_click.patch was dropped due to a different issue it caused; you could try building the driver with it enabled and see if it helps
<bryce> reboot time again
<Sarvatt> plars: whats your problem? tapping not working?
<Sarvatt> or multi finger tapping not working?
<plars> Sarvatt: tap not working at all, seems to be disabled by default
<Sarvatt> can you pastebin the output of synclient -l?
<Sarvatt> i'm getting a problem where the ubuntu kernel detects my touchpad as a generic mouse about 1/10 boots
<Sarvatt> (so tapping isnt working in that case)
<Sarvatt> but a sudo rmmod psmouse && sudo modprobe psmouse fixes that
<plars> Sarvatt: http://pastebin.ubuntu.com/248009
<Sarvatt> ah yep your tapping is disabled
<plars> Sarvatt: I know, I can manually enable it and it all starts working
<Sarvatt> do you have it enabled in system - preferences - mouse - touchpad?
<plars> Sarvatt: no, but enabling it there causes it to work
<Sarvatt> if it was the generic mouse instead of touchpad problem i have synclient wouldnt show anything so it isnt that at least
<Sarvatt> ah yeah if you have it disabled there it turns all the TapButton options off when the session loads
<Sarvatt> it should remember it on reboot and work fine now that you set it
<Sarvatt> it loads with tapbuttons enabled when x starts, then when your gnome session starts gnome-settings-daemon disables the tap buttons if you have it turned off in there
<plars> Sarvatt: but apparently the default is for it to be turned off
<Sarvatt> yep thats intended. /desktop/gnome/peripherals/touchpad/tap_to_click <default>FALSE</default>
<plars> Sarvatt: why is it intentional for tap to click to be turned off?
<Sarvatt> its only turned on by default for people that have touchpads without physical buttons, i'm not the one who decides that just saying what I see :D
<plars> Sarvatt: ok... confusing, but ok :)
 * ogra hugs kirkland 
<kirkland> ogra: ;-)
<kirkland> ogra: it's a moderately long build
<kirkland> ogra: ping me if you see the build complete, as i need it too ;-)
<ogra> will do
<bryce> Sarvatt, btw asac ran into a problem with ppa-purge; it resulted in wanting to remove a bunch of extra packages
<pitti> tkamppeter: so perhaps cups init script should do something like
<pitti> udevadm trigger --subsystem-match=usb --attr-match=bInterfaceClass=07 --verbose
<pitti> tkamppeter: oops, without the --verbose
<pitti> tkamppeter: if you run it on a machine with a printer (with --verbose), it should show the device(s)
<Sarvatt> asac: ping :) curious what problem you had, i could see it trying to remove multiple PPAs with certain combinations on the 0.2.1 version that should be fixed in 0.2.2
<bryce> Sarvatt, asac was thinking he may have built the packages against xorg-edgers
<Sarvatt> got me curious what it tried to remove, guessing it was an aptitude proposed solution for something
<Sarvatt> bryce: btw intel could use a no change rebuild now so it builds with all the new dri2proto 2.1 features since xserver was upgraded
<c_korn> geser: hello. the bug about schroedinger has been fixed in debian. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539843 where can I get the diff.gz and try on ubuntu?
<ubottu> Debian bug 539843 in schroedinger "schroedinger: FTBFS because of headers moved to gst-plugins-base" [Serious,Closed]
<bryce> Sarvatt, on it
<geser> c_korn: wait a few hours, as it's now between incoming.d.o and ftp.d.o
<c_korn> ok
<ogra> kirkland, whoops, sorry, didnt monitor the build to closely, seems it finished about 40min ago
<hdon> can anyone tell me if they have blksize_t on jaunty?
<hdon> i have been trying for about *twenty* minutes to no avail to get blksize_t
<hdon> donny@pacemates:~/gpsee/src3$ gcc -c -Wall -Werror test.c || cat test.c
<hdon> test.c:3: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âtestâ
<hdon> #include <sys/types.h>
<hdon> #include <sys/stat.h>
<hdon> blksize_t test() {return 0;}
<jml> james_w, the fix for the setBranch bug is on edge.
<james_w> jml: thanks, I'll work on the script now
<jml> james_w, np.
<hdon> oh i needed -D_GNU_SOURCE
<cjwatson> hdon: you need to put '#define _XOPEN_SOURCE 500' at the very top. See the "Feature Test Macros" node in 'info libc'
<cjwatson> (or yes, _GNU_SOURCE will do as well)
<cjwatson> defining _XOPEN_SOURCE 500 is the surgical thing that gets you just what you want; _GNU_SOURCE is the great big sledgehammer.
<hdon> cjwatson: i don't suppose you know the feature test macro that will give me struct passwd::pw_age et al
<hdon> oh i see. pw_age doesn't seem to exist on linux
<hdon> or maybe this is a glibc thing
<slangasek> "age" is not POSIX
<hdon> slangasek: yeah i just figured that out
<hdon> thanks :)
<cjwatson> hdon: I don't see pw_age in the header files at all
<hdon> cjwatson: it's not POSIX. sorry
<hdon> cjwatson: it's not GNU either
<hdon> cjwatson: it's an AT&T thing, apparently also supported on Solaris, which is where the code i'm working with comes from
<hdon> also pw_comment is an AT&T thing on Solaris as well
<hdon> according to google codesearch (because i can't find real documentation on it) i can rely on the ATT_COMMENT and ATT_AGE macros
<cjwatson> tried just looking at the header files on Solaris to see if they check any definitions before including pw_age?
<james_w> jml: script is running. slowly.
<jml> james_w, I wonder how long it'll take
<james_w> hmm, perhaps a DB query is better
<james_w> jml: 10s a branch would make it take 100 days
<superm1> cjwatson, ping. i was talking to mvo about a problem with mythbuntu tasks last week and he identified it to be that the machine generating the task headers is running germinate on universe, restricted, and main, but not multiverse.  he had wanted to discuss it with you though due to any unexpected repercussions of enabling tasks for multiverse
<asac> Sarvatt: does the ppa-purge run autoremove or something?
<asac> Sarvatt: it kind of removed a similar package list that autoremove would have removed. installing ubuntu-desktop explicitly helped to keep the packages on my system ... so now i think i am on pure karmic again :/
<asac> at least i hope
<Sarvatt> nope it only does an apt-get install package/distro
<Sarvatt> then an aptitude install package/distro if that fails because the package doesnt exist in the distro
<kukukk> hello
<kukukk> Can somebody help me, how to find that a package with which configure options was created?
<kukukk> I need the ./configure options for pyclutter to install a newer version...
<cjwatson> superm1: I think I said when asked that it was fine to enable multiverse too; that may or may not have been in your hearing
<superm1> cjwatson, ah, mvo had just said to ask you when you returned.  who can make the appropriate changes then on this machine generating the headers?
<cjwatson> superm1: needs a bug filed on Soyuz, although I already told the LP people it was OK to make that change so it may already be in progress ...
<Riddell> ccheney: can you remind me again the status of KDE 4 patches for openoffice?  Are they in upstrem (which one)? and when is that likely to come back to us?
<cjwatson> superm1: (that code's in Launchpad, lp:launchpad cronscripts/publishing/cron.germinate)
<cjwatson> man, I love being able to just point people to that code
<Sarvatt> thank you thank you _thank you_ for all of the ubuntu-meta changes in the past few months, was pleasantly surprised that I could remove alot of stuff I dont want that resulted in removing ubuntu-desktop before like brltty apparmor and xsane :D
<Ahmuck-Jr> hi.  we run a mixed environment pc lab with *untu on the machines, however users are having problems adjusting because the menu's are not the same across the *untu distros
<ccheney> Riddell: they are in ooo-build for 3.1.1 which should be in karmic in late august (3.1.1 is not released yet)
<Riddell> ccheney: do you know if the oxygen icon theme is also there?
<ccheney> Riddell: i believe so
<timboy> if you right click and create a share from the gnome gui where does the config go?
<hyperair> timboy: you mean from the file manager?
<hyperair> timboy: it's in /var/lib/samba/usershares/
<timboy> hyperair, excellent thx!
<hyperair> timboy: the command line interface to mess around with it is "net"
<hyperair> "net usershare" specifically
<timboy> cool
<hyperair> nautilus-share is just a plugin for the file manager which provides a front end for that
<timboy> thx for the help hyperair !
<dtchen> TheMuso: ok, thanks
<dtchen> cjwatson: what are the plans for biarch (specifically, alsa-plugins and pulseaudio) and ia32-libs?
<directhex> woo, mono 2.4.2.3 in sid. well in time for FF
<Varox> hey all
<Varox> after asking in 3 ubuntu-channels before, i show up here :)
<Varox> i just posted this thread, does anyone know how to fix this? http://ubuntuforums.org/showthread.php?t=1232503
<dtchen> Varox: #kubuntu-devel, please
<Varox> dtchen, thanks
<TheMuso> c
<ebroder> Can I use /dev/disk/by-uuid/foo in /etc/fstab on Dapper?
<dtchen> TheMuso: WRT rtkit: it's still useful for SCHED_RR, no?
<dtchen> TheMuso: ah, n/m, i see the SCHED_RESET_ON_FORK mask
<superm1> cjwatson, thanks
#ubuntu-devel 2009-08-06
<Sarvatt> was madwifi bundled up in anything in jaunty (like restricted extras?) i've noticed alot of people having problems with wifi after upgrading to karmic because they had things like madwifi installed which were blacklisting the kernel modules but theres no transitionary package to remove the blacklists
<Sarvatt> same deal with the old broadcom packages not removing the blacklists right
<Hobbsee> wasn't in restricted extras, but may have been in the restricted kernel packages
<spotter> it appears latest poppler has broken pdftex/pdflatex
<spotter> trying to test w/ older version
<spotter> yea
<spotter> downgraded
<spotter> works
<spotter> bug filed
<pitti> Good morning
<mdke> morning pitti
<Hobbsee> hey pitti!
 * pitti hugs Hobbsee and mdke, how are you?
<Hobbsee> :D
<Hobbsee> pretty good - first week of uni again here
 * Hobbsee heads off to find some food before the next lecture
<mdke> pitti: well thanks, hope you are too
<mdz> cjwatson, should we unseed acpid? it's still depended upon by acpi-support, but once that's gone, I think we want it to pass out of main
<directhex> when's the next alpha due?
<cjwatson> slangasek: ^- acpid is your call I think; I'm happy to remove the explicit seed
<liw> directhex, https://wiki.ubuntu.com/KarmicReleaseSchedule
<cjwatson> the installer explicitly installs acpi, acpid, acpi-support-base if it can - I assume I should remove that?
<cjwatson> (that's from Debian)
<directhex> liw, alpha 4 soon, then.
<mdz> cjwatson, I think so, yes
<cjwatson> removed in my working tree
<mdz> pitti, what would you think about making the apport fields in the bug description into a table, lining up the columns so they were easier to scan visually?
<slangasek> cjwatson: acpid shouldn't be seeded explicitly, right
<slangasek> it's only wanted as an acpi-support dep
<StevenK> But acpi-support is only a Recommend
<slangasek> StevenK: you're reading it upside-down
<doko> seb128: looks like some gtk/gnome -dev package did drop the dependency on libgtk2.0-dev?
<seb128> doko, where?
<doko> seb128: I just see openjdk-6 failing to build because gtk isn't available anymore. did work for the last upload
<seb128> is openjdk using gtk directly?
<seb128> in which case it should depends on it
<seb128> or rather build-depends
<seb128> doko, the configure check for gtk you should list it in the build-depends and not rely on other packages to pull it there
<cjwatson> mdz: unseeded
<mdz> cjwatson, thanks
<ogra> seb128, any idea why my gconfd is eating about 25% CPU constantly ?
<ogra> since yesterday already
<seb128> ogra, try running compiz --replace and ctrl-C directly
<seb128> there is some weird wm things going on sometime that workaround it
<ogra> well, nw my compiz is gone and doesnt come back
<ogra> *now
<ogra> but gconfd is silent again
<seb128> hum
<seb128> ok so that was it
<seb128> restart compiz ;-)
<ogra> it doesnt want to :)
<seb128> what does it say?
<ogra> at least not through the UI
<ogra> works in terminal, but the fan starts spinning again
<ogra> yup, and gconfd is bak at the top of my processlist
<ogra> *back
<ogra> nothing special in the terminal output
<liw> hmm... it's as if launchpad has some javascript now that affects pageup/pagedown keys in the browser
<ogra> liw, i think its related to the "subscribers" list
<ogra> but its massively annoying
<liw> yes, it is
<mdz> jdstrand: I experienced the same symptoms described in bug 399446 and noticed you marked it invalid
<ubottu> Launchpad bug 399446 in telepathy-mission-control "mission-control crashed with SIGSEGV in g_datalist_foreach()" [Undecided,Invalid] https://launchpad.net/bugs/399446
<mdz> jdstrand: maybe an error on the part of an automated tool?  the bug report looks good to me, complete with debug symbols
<jdstrand> mdz: hmm.. looking
<jdstrand> mdz: yeah, best I can tell it was a mistake
<jdstrand> mdz: I updated the bug to Confirmed
<mdz> jdstrand: thanks
<mdz> jdstrand: was that a script?
<jdstrand> mdz: a script generated the text, but it was a human that call the script on that bug. I'll need to find him and thrash him :)
<mdz> jdstrand: :-)
<zul> james_w: ping can you add samba to your distributed development thing?
<james_w> zul: done
<zul> thanks
<james_w> may take a little while to import that one
<zul> k
<mdz> pitti, I noticed that apport bugpatterns don't seem to use re.MULTILINE. don't you think they should?
<pitti> mdz: I guess we just didn't need it so far, but I don't mind enabling it
<ogasawara> mdz: bug 390256
<ubottu> Launchpad bug 390256 in initramfs-tools "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: underprosessen post-installation script returnerte feilstatus 2" [Undecided,New] https://launchpad.net/bugs/390256
<Riddell> lool: https://wiki.kubuntu.org/MainInclusionReportGpsd
<sebner> pitti: about this usb bug, Should I just upgrade gvfs and devicekit again and run the 2 commands or do I have to go through the whole list of commands posted the last days?
<pitti> sebner: just the two last ones should be enough
<pitti> sebner: also, you can keep the current versions, you just need to move 95-devkit-disks.rules to the side
<sebner> pitti: can't find 95-devkit-disks.rules. In what package is that? At least upgrade devicekit?!
<pitti> sebner: /lib/udev/rules.d/95-devkit-disks.rules
<pitti> sebner: it's in devicekit-disks
<pitti> sebner: if you uninstalled that, you won't have it of course
<sebner> pitti: it's 98 and not 95 though
<pitti> sebner: no, 95
<pitti> sebner: what file are you looking at?
<evand> Does anyone know what sets XDG_CONFIG_HOME, or how to get the xdg-user-dirs information for a different user?
<sebner> pitti: http://paste.ubuntu.com/248637/
<pitti> sebner: 98-devkit is totally obsolete, devicekit isn't needed/installed any more
<sebner> pitti: ah you are right, sry
<sebner> pitti: hmm I would run the commands but my harddrive isn't recognised *cough*
<pitti> sebner: just talked to upstream, he'll do a newer version today
<pitti> it's worth testing that
<sebner> pitti: sounds nice, btw .. when I plug my USB harddrive in -> http://img199.imageshack.us/i/90367185.png/
<pitti> sebner: mmm, haven't seen that' is that with current gvfs/devkit, or with the downgrade?
<sebner> pitti: gvfs is downgraded, devkit is current. dmesg still shows me the -71 errors though
<sebner> I gues after installing libatasmart*
<pitti> sebner: right, as I said you need to move aside 95-devkit-disks.rules
<sebner> pitti: I did
<sebner> pitti: I hope naming it 95-devkit-disks.rules.backup is enough?
<pitti> should be
<sebner> well, then this is the result ^^. anyways, waiting for new upstream version is always good :)
<Laney> damn
<Laney> CDBS now FTBFS due to a test failur
<Laney> e
<Laney> and I need the new release for some syncs
<mdz> pitti, I've pushed to ubuntu/apport some patches to redirect bugs from the kernel to grub and initramfs-tools when the failure was in those tools
<mdz> pitti, could you have a look and review it?
<Laney> whatever it is broke between 2009-07-23 (last successful build) and now
<seb128> Laney, what error do you get?
<Laney> seb128: one of the tests failed
<Laney> bug 409863
<seb128> --verbose?
<ubottu> Launchpad bug 409863 in cdbs "FTBFS: FAIL: recursive.sh" [Undecided,New] https://launchpad.net/bugs/409863
<lool> \
<lool> \
<lool> \
<lool> \\
<lool> \
<lool> 
<lool> \
<lool> \
<lool> \
<lool> \
<lool> \
<lool> \
<lool> \\[6~\\\
<lool> [6~\
<lool> \
<lool> \
<lool> Crap sorry folks
<Laney> modern art?
<lool> This is what happens when you carry your laptop with a single hand with the keyboard hitting your belly
<jussi01> heh
<lool> Riddell: Ah I see it the gpsd MIR was assigned to asac just before lunch  :-)
<highvoltage> lool: nice belly art.
<mdz> ogasawara, I added an apport patch for the update-initramfs failures as well
<mdz> ogasawara, are you using bughelper? clue files might help to clear out the old ones
<Gh0sty> anyone here knows if gnome-keyring in the new version will have pam support?
<Gh0sty> just reading up on some stuff that bothers me for quite a while: if you use fingerprint reader on your laptop you still need to login with a password to gnome-keyring :/
 * mdz wonders if anyone has looked at unifying bughelper clue files with apport bugpatterns
<liw> fingerprints are good for identification, but not authentication; using them for authentication encourages people to cut off your fingers
<pitti> Gh0sty: right, because your fingerprint usually doesn't have your password engraved, and the keyring is encrypted with your password as a key
<ogasawara> mdz: yup, I've used bughelper in the past so I'll use it to help clean up the existing bugs.
<mdz> ogasawara, it must take a long time for bughelper to download all the kernel bug data!
<cjwatson> Gh0sty: somebody demonstrated quite convincingly recently why using fingerprints as passwords would be a spectacularly bad plan
<cjwatson> Gh0sty: they lifted the fingerprints of the German Interior Minister off a glass he'd handled
<cjwatson> Gh0sty: so we regard a fingerprint as more analogous to entering a username
<Gh0sty> pff
<mdz> unique-ish, but not secret
<Gh0sty> still its not like i work for the secret service but it still would be fun to auth with fingerprint :p
<pitti> no, every computer and keyboard has them spread all over the place
<pitti> Gh0sty: it works, libpam-thinkfinger does that
<Gh0sty> yes but how can it interact with gnome-keyring?
<pitti> it can't
<pitti> for decryption you need a secret key
<Gh0sty> as far as i saw there is talks about libpam_keyring.so in the past
<pitti> so you'd need to keep your keyring unencrypted
<Gh0sty> but even though the lib is installed i don't find the file
<Gh0sty> lol thats security wise good? nope ... :p
<Gh0sty> why can't it just store the session like "you're logged in ... ok you have also access to your keyring"
<mdz> james_w, have you talked with mvo about turning the ubuntu apt branch into a source package branch?
<Gh0sty> i see it's similar with people who do auto login, they just save their keyring unencrypted :/
<james_w> mdz: I have not
<mdz> james_w, see any reason not to just do it?
<james_w> I don't think so
<james_w> I would just want to ensure that an appropriate revision is tagged with the latest version
<Gh0sty> and anyway as a guy also said: if it's not for fingerprints ... gnome-keyring should still use pam, you can have auth through usb stick or cardreaders or otp
<Gh0sty> so this would mean that those auth methods do not work for gnome-keyring either :)
<cjwatson> james_w: likewise ubiquity, BTW
<cjwatson> james_w: is that just a matter of setting the official branch, or do we need to also re-push the current branch to lp:~ubuntu-installer/ubuntu/karmic/ubiquity/trunk ?
<james_w> we need a couple of code changes to support that
<james_w> I'll bump that task up in my list
<cjwatson> so presumably those same changes would apply to apt too
<mdz> james_w, it looks like he has not-yet-uploaded changes in the branch at the moment
<cjwatson> mdz: (from a meatspace conversation with james_w) so either apt gets pushed to ~ubuntu-branches and that's set as the official branch, in which case mvo loses the ability to commit to it until jml lands a codehosting change; or else the official branch link is set to mvo's current ~ubuntu-core-dev branch, which requires an importer tweak to avoid continuing to update the spurious ~ubuntu-branches branch
<cjwatson> the importer tweak is pending resolution of an RT ticket to cherry-pick a launchpadlib fix onto jubany
 * jml is working on said change atm.
<mdz> cjwatson, so in short, we should leave it alone for the moment?
<james_w> yeah, but should be a short while until we can change things around
<cjwatson> I've been waiting for one of those two things to get fixed before doing anything with my many bzr package branches, put it that way :-)
<cjwatson> setting the official branch link to something else is apparently mostly harmless, it just leaves some junk lying around which might be confusing
<cjwatson> so perhaps we should start doing that for selected branches, to get a jump on any issues that might arise?
<cjwatson> since the junk can be cleaned up later
<cjwatson> of course eventually we want all source package branches to be owned by ~ubuntu-branches
<cjwatson> because that means that magic permissions resolution can apply, once it works
<jml> umm
 * mdz reboots to check out linux-crashdump
<jml> it's only for official branches
<jml> wgrant mentioned in a bug report that it'd be nice to turn it on somehow for your own branches
<jml> maybe it should be the celebrity -- seems kind of hacky though
<cody-somerville> pitti, Does postgresql8.4 not bind to the same port as postgresql8.3?
<ogra> cjwatson, i have another merge for debian-cd on https://code.launchpad.net/~ogra/debian-cd/ubuntu ... lp:~ogra/debian-cd/ubuntu could you pull that in ?
<pitti> cody-somerville: it does (5432)
<pitti> cody-somerville: if you have several versions installed in parallel, you can just have one cluster on 5432, of course
<cody-somerville> pitti, update-manager installed 8.4 and removed 8.3
<directhex> kees, would you object to me requestsyncing a new mono version from sid which does not include your patch, then?
<directhex> if i sync now, we should be able to shrink the next alpha a little
<cody-somerville> pitti, my connection just dropped. Did you get that update-manager installed 8.4 and removed 8.3?
<pitti> cody-somerville: I got it (sorry, in discussion here)
<pitti> cody-somerville: it really should keep 8.3, though
<pitti> I thought that was already fixed in update-manager
<pitti> cody-somerville: can you please report this as a major bug against update-manager? should be easy to fix
<cody-somerville> pitti, even if update-manager doesn't remove it, sudo apt-get autoremove will
<cody-somerville> pitti, and theres still the fact that I have just postgresql8.4 installed and it starts but I can't connect to it via the standard port nor the unix domain socket.
<kees> directhex: yeah, please do, I was about to upload a revsion, but a merge would be better.
<StevenK> cody-somerville: -p 5433 ?
<directhex> kees, well, excluding your patch, we're in sync town. 2.4.2-5ubuntu1 was rendered obsolete by -6, so...
 * directhex fires up a console
<mdz> cjwatson, I didn't spot any code where depmod would exit nonzero without an error message
<pitti> cody-somerville: what does pg_lsclusters say?
<mdz> my best guess is that it didn't manage to exec depmod at all
<kees> directhex: was ogra's reversion a reversion of an ubuntu change?
<pitti> cody-somerville: if you just have one cluster, it should pick the port of that one, even if it's not the default port
 * ogra looks up 
<mdz> the kernel postinst doesn't attempt to catch that error
<ogra> what did i reverse ?
<cody-somerville> pitti, It appears I have a cluster for 8.3 and one for 8.4 and that 8.4 is indeed running on 5433 like StevenK suggested.
<kees> ogra: "revert dropping of --with-tls=pthread on armel to fix FTBFS
<kees> " in mono
<directhex> kees, ogra's revision was adding back some hacks. -5 assumed upstream's build system was sane, -6 did the same thing as ogra's patch (although possibly not in the same way, i'd need to check)
<ogra> oh, directhex said he would push that to debian or get it fixed upstream
<kees> directhex: ah-ha!  perfect then.  rock on.  :)
<mdz> IIRC dpkg enforces a sane PATH, so that wouldn't be it
<directhex> kees, it's built on arm in debian, if that counts!
<kees> sounds good to me.  :)
<ogra> not really
<ogra> we use gcc 4.4 they dont ...
<ogra> and a different toolchain, but just push it up, i need to test it anyway, if there are arm issues i'll care
<directhex> mono (2.4+dfsg-6) unstable; urgency=low
<directhex>   * debian/rules:
<directhex>     + Force pthread for armel as __thread FTBFS.
<directhex> i think 2.4.2.3 may well be what we release with. unless upstream push out another important bugfix in the 2.4 branch
<directhex> there we go, #409920 filed. i'm feeling pretty good about karmic
<cody-somerville> pitti, here is a pastebin out the output: http://pastebin.ubuntu.com/248703/
<cody-somerville> pitti, I assume I have to upgrade the cluster but that doesn't seem possible since the original cluster isn't running anymore with 8.3 removed.
<pitti> cody-somerville: right, you need to reinstall postgresql-8.3
<cody-somerville> pitti, Should I file a bug against postgresql-8.4? - this doesn't seem like a very good transition experience
<mdz> pitti, do you see any issue with one apport package hook invoking another one's add_info function?
<pitti> mdz: should work fine, but I think it's cleaner for the hook to call add_hooks_info(otherpackage)
<mdz> pitti, oh, I didn't know about that
<pitti> mdz: now, you can't specify "otherpackage" yet, I've been meaning to add that
<pitti> mdz: in the meantime you can temporarily change report['Package']
<cody-somerville> pitti, thanks. worked like a charm.
<pitti> seb128 asked me about this as well, I'll add it right now
<pitti> cody-somerville: still an awkward upgrade, needs fixing in u-m
<pitti> seb128, mdz: committed that to trunk now, FYI
<seb128> pitti, thanks!
<mdz> pitti, ok, I'll stop working on it now ;-)
<pitti> mdz: you can still change report['Package'], that'll work
<mdz> pitti, in this case I can just use hookutils.attach_alsa(), but I had been wondering if this was possible
<MacSlow> anybody with an idea how to pass any of the multimedia-key into the system runnung under VirtualBox?
<mdz> seb128,
<mdz>   [ Matt Zimmerman ]
<mdz>   * apt-pkg/deb/dpkgpm.cc:
<mdz>     - Suppress apport reports on dpkg short reads (these I/O errors are not
<mdz>       generally indicative of a bug in the packaging)
<seb128> mdz, excellent, thanks!
<liw> MacSlow, I'm not convinced it's possible, at all; multimedia keys tend to be different on each kind of hardware
<soren> james_w: Have you thought about adding a few lines of code to apt-cache to fake a vcs-bzr header if it's not explicitly set?
<sladen> (since the Microsoft extended keyboard, the mediamedia keys have had defacto standard keycodes, and the kernel now also uses these internall)
<MacSlow> liw, I'll guess pykey/crikey (using xtst & co) is what I'm looking for... thanks to soeren for the hint
<soren> liw: They (at least used to) get mapped to a specific keysym, so they're easily catchable.
<liw> I seem to be wrong, then; good
<sladen> however, as to how to ensure they get passed through to virtualbox, no idea
<sladen> probably kill -9 whatever bit of magic (gnome-settings-daemon?) is catching them
<ogra> kees, "mmap: No such device or address" .... i still see mmap issues with qemu even with setting cap_sys_rawio
<kees> ogra: oh, hrm.  let me check something...
<pitti> mdz: hm, no new revisions in lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/, did you push?
<kees> ogra: well, to get that working asap, use the method that wine and dosemu currently use (but set it to 32k instead of 0).  I need to test the fscaps stuff more, it seems.
<ogra> kees, hmm k
<mdz> pitti, Using saved push location: bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/apport/karmic/
<mdz> pitti, is that the wrong place?
<mdz> I did bzr branch lp:ubuntu/apport
<mdz> jml, ^^
<pitti> mdz: Vcs-Bzr: should point to ~ubuntu-core-dev
<pitti> it seems that we got a package import into bzr although an official branch already exists?
<pitti> so it seems we should abandon ~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/ then
<mdz> james_w, help?
 * pitti checks out lp:ubuntu/apport
<pitti> mdz: ah, I wouldn't like to use that one; it's just a dsc import, and lost all the individual history, and you can't merge from trunk
<pitti> I don't think we should use the auto-imported package branches for anything that has a Vcs-Bzr: right now
<pitti> (this question keeps coming up..)
<cjwatson> mdz: I couldn't figure it out either, that's why I punted to the submitter
<cjwatson> mdz: yes, dpkg enforces a sane PATH
<cjwatson> mdz: well, although it doesn't exclude *extra* weird shit from being on PATH
<cjwatson> ogra: merged, thanks
<james_w> mdz: I have no idea why your revisions aren't showing up in that branch
<ogra> cjwatson, thanks
<linuxdude> ubuntu alpha 3
<linuxdude> sweet
<linuxdude> is it any good?
<mdz> james_w, it looks like I pushed to the wrong branch (the ~ubuntu-branches one)
<james_w> ah
<linuxdude> gotta go
<mdz> james_w, I assumed that pitti's ubuntu branch had been imported as the source package branch
<cjwatson> mdz: you could probably only push there because you're a Launchpad admin
<mdz> james_w, can you help me rip the patches out of there and put them into the right branch?
<james_w> yeah, I think so
<spotter> seb128, I think you misunderstand my latex bug
<spotter> the usage.pdf works fine (generated by gnuplot as eps converted to pdf)
<spotter> it's pdflatex can't include it in the document I provided
<spotter> wont build
<pitti> james_w: is it possible to somehow make lp:ubuntu/foo point to Vcs-Bzr: if it exists?
<seb128> spotter, oh, that's a pdflatex bug then
<spotter> seb128, except it works w/ old poppler
<james_w> pitti: technically, yes.
<spotter> I've downgraded poppler and I can build
<spotter> it would appear that new poppler lib isn't the same abi
<pitti> james_w: but it wouldn't be a good idea?
<james_w> pitti: (if it's on LP and exists etc.)
<seb128> spotter, right, which doesn't mean that poppler changed and pdflatex need to be updated to use poppler correctly
<seb128> though soname should have changed if they broke abi
<seb128> will check
<james_w> not currently (c.f. discussion a couple of hours ago), but perhaps in a couple of weeks
<spotter> right.
<spotter> that's my only point
<pitti> james_w: ok, thanks
<seb128> spotter, sorry the bug was not really clear, it makes easier to give the command you run and an example is such cases
<spotter> I thought I did
<spotter> included the 2 files and said run "pdflatex test.tex"
<spotter> sorry if i wasnt' clear
<james_w> pitti: we could create a list of eligible packages then and review it when it is possible
<spotter> a bit rushed due to paper deadline
<seb128> spotter, you did in the update but I misunderstood the bug from the initial description
<seb128> spotter, and I just read the update quickly
<seb128> spotter, will look at that now thanks
<james_w> jcastro: gnonlin synced
<jcastro> \o/
<seb128> jcastro, so you run from people to people asking to sync different things? ;-)
<james_w> jcastro: it's just a .3 update, is that what we need?
<seb128> jcastro, new pitivi synced
<jcastro> no I told him I would talk to you
<jcastro> but he's james_w and he's awesome
<jcastro> james_w, I believe so yes
<seb128> jcastro, and I'm seb128 and I suck right? ;-)
<jcastro> seb128, I'm sure next time you will win.
<seb128> right ;-)
<mdz> robbiew, kernel crash dumps work great, nice work on mvo's part
<robbiew> mdz: I wouldn't expect anything less from him ;)....I'll pass it along
 * jml back, catching up
<lool> kees: Hey I'm happy to promote python-oauth unless you'd like to do a security review; it's relatively small and trivial python lib but it's parsing data from the net https://bugs.launchpad.net/bugs/408878
<ubottu> Launchpad bug 408878 in python-oauth "[MIR] python-oauth" [Undecided,In progress]
<james_w> lool, kees: python-oauth implement OAuth 1.0, not 1.0a, so is vulnerable to what can be a very serious session fixation attack
<james_w> it's not really a "full of buffer overflows" problem, but something to consider
<kees> james_w: sounds like a reason to reject it to me.
<kees> lool: what needs it?
<james_w> kees: Ubuntu One, the new python-launchpadlib
<james_w> (the old one embeds a copy :-/)
<bdrung> bryce: did the kms for karmic work also on r6xx/7xx?
<bryce> bdrung, haven't tested it
<kees> james_w: so, ubuntu one is vulnerable to a serious session fixation attack currently?
<james_w> kees: depends how they use it
<bryce> kees, what was your graphics card?  lspci | grep VGA
<kees> bryce: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
<james_w> I haven't looked in to their use of it
<bdrung> bryce: ok, then i will try it today (if i have time for it)
<james_w> I believe Launchpad is
<james_w> it's more of a server-side fix, but clients need to roll out the change
<james_w> in addition, LP doesn't really do "full" OAuth, so the impact is mitigated I think
<hoban> I'm having trouble finding an existing bug report about this and maybe it's because it's by design. Maybe someone can shed some light? With any other Linux distro I've used, when you enter the GRUB command-line interface at boot, setting the root device (e.g. root=(hd0,0)), kernel (e.g. kernel /vmlinuz-2.6.22), or initrd (e.g. initrd /initrd-2.6.22) will cause the command line to indicate whether or not the action was successful. Ubuntu's
<hoban>  grub does not. It just prints a blank line. This can make it hard to manually boot the system using GRUB if the menu.lst is incorrect or missing.
<lool> james_w, kees: Wow ok thanks for feedback; I'm happy I pinged on that security review!
<lool> kees: Do you want a bug or something for the python-oauth issue?
<lool> kees: I just Incompleted the MIR for now
<TheMuso> lool: Thanks for making those fixes, I would have been happy to chase them up myself. I'll keep an ee on the Debian package to get them into Ubuntu.
<kees> lool: feel free to subscribe me to it
<cjwatson> hoban: I think that's accidental, perhaps a consequence of having 'quiet' in the menu?
<cjwatson> hoban: unless you mean in karmic in which case it could be a difference between grub and grub2 ...
<hoban> cjwatson, I'm actually referring to 8.04 LTS
<cjwatson> ok, so grub 1
<hoban> cjwatson, I'll take a look to see if it's related to the quiet option and return shortly
<hoban> cjwatson, I removed the quiet option and there is no difference in behaviour
<hoban> recall also that I'm referring to the grub command-line, so configuration in /boot/grub/menu.lst isn't being used at that time anyway. Perhaps there is a difference in the way grub is being compiled?
<cjwatson> hoban: ok, every distro has massive patches to grub legacy so that's entirely possible; afraid I can't hunt through it right now
<hoban> cjwatson, not a problem. Is this something I should create a bug report for or just ignore until grub2 is in use? (I'm fine with either)
<cjwatson> could be a consequence of the patch to quieten boot in general
<cjwatson> go ahead and file a bug of course, although I should warn that we aren't putting a whole lot of effort into grub any more
<cjwatson> but no harm in having it recorded
<hoban> will do. Thank you cjwatson!
<lool> hoban: If I recall correctly the default value for the quiet option might be one
<cjwatson> I don't think there's actually any way to set it to zero
<hoban> lool: which quiet option (grub's quiet option or the kernel quiet option) and where is that configurable?
<lool> hoban: The grub quiet command is supposed to set a quiet flag in grub
<lool> hoban: This is all added by a patch in the packaging
<lool> But the deafult value of the flag is 1 anyway (IIRC)
<hoban> lool: I see. thanks
<lool> hoban: See debian/patches/quiet.diff in http://archive.ubuntu.com/ubuntu/pool/main/g/grub/grub_0.97-29ubuntu56.dsc
<lool> +/* Whether to quiet boot messages or not. */
<lool> +int quiet_boot = 1;
<hoban> lool: I'll take a look at that, and if removing that diff changes the behaviour in the way I'm wanting, I'll include that information in the bug report
<MisterN> i discovered sysfsutils today, and i think maybe ubuntu could itself use it for initialising sysfs variables in a standardised place. just a suggestion :)
<stefanlsd> pitti: i made a new diff.gz for 0.6.5 of calibre. are you ok if i upload or do you have other plans for it?  bug #410046
<ubottu> Launchpad bug 410046 in calibre "Upgrade Calibre to new upstream 0.6.5" [Wishlist,Confirmed] https://launchpad.net/bugs/410046
<goldins> Hello, where do I voice my opposition to multisearch being enabled by default on firefox 3.5?
<dtchen> here (or) #ubuntu-mozillateam (or) preferrably, ubuntu-devel-discuss@lists
<dtchen> i can't speel today, apparently
<goldins> I hate it. I think it's really annoying and limits the awesomebar's coolest features. If there was a vote on default addons for firefox, I would vote for absolutely anything else
<dtchen> i think that while your enthusiasm may be appreciated, documenting impartially (or as close to that as one may be) the use case regressions with detailed screenshots is likely a far more productive method of "protest"
<goldins> I mean, I think if you're going to ship firefox with addons, the burden of proof is on you to prove those addons are great for everybody
<goldins> it behaves a particular way, it behaves that way on all of my computers and every computer I use. My users are going to be confused when it behaves differently on their linux machines than their windows machines than the CentOS machines etc
<eimann_> morning
<eimann_> anyone here who knows why dvb/webcam modules are missing in 2.6.31-rc5 mainline kernels from ppa repository?
<dtchen> which, specifically?
<eimann_> the "official" one ;-) -- http://kernel.ubuntu.com/~kernel-ppa/mainline/
<dtchen> no, which .ko?
<eimann_> dvb-usb-umt-010.ko and uvcvideo.ko
<dtchen> config skew. you could ask apw nicely if there's a more specific reason.
<eimann_> ok, thx :)
<eimann_> apw: Could you please explain if there is a reason for not including video/dvb modules in the 2.6.31-rcX Packages? ;-)
#ubuntu-devel 2009-08-07
<lfaraone> Hey, is it intentional that typing a query in the address bar or in the search box in Karmic uses Google's Custom Search, and if so, why may I ask?
<dtchen> yes. see query.
<ghindo> Does anybody know when gnome-zeitgeist will be available in the Karmic repos?
<lfaraone> !query
<ubottu> Sorry, I don't know anything about query
<lfaraone> dtchen: Sorry, not sure what you're refering to.
<dtchen> lfaraone: see your private message.
<lfaraone> dtchen: Ah.
<StevenK> Heh, that has to be an old situation. The i386 ISO is oversized by 1MB, and amd64 is undersized by 29.
<pitti> Good morning
<pitti> StevenK: I can easily do that from my bzr branch, but go ahead
<StevenK> pitti: Er, do what? I've completly lost context
<pitti> oops, I meant stefanlsd
<freeflying> are we about to use blueman to replace gnome-bluetooth in karmic?
<bryce> mdz, mind adding that gpu lockup script to wiki.ubuntu.com/X/Troubleshooting/Freeze
<mdz> bryce: it's on my other laptop up in my room. sorry I didn't send it to you earlier; I thought I had
<pitti> mbiebl: hi! doing the libatasmart package update FYI
<pitti> I need that for some debugging
<sebner> pitti: good to know =)
<mathiaz> sbeattie: http://launchpadlibrarian.net/24728388/mysql-server-5.0.py
<mathiaz> sbeattie: bug 354188
<ubottu> Launchpad bug 354188 in mysql-dfsg-5.0 "Add apport hook to gather relevant information" [Wishlist,Triaged] https://launchpad.net/bugs/354188
<mathiaz> sbeattie: https://wiki.ubuntu.com/DebuggingMySQL
<ogasawara> MacSlow: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<MacSlow> ogasawara, thanks
<daniele_982> it's Italian or English language?
<daniele_982> same good guide to configuring and starting a git server??
<pitti> that involves sacrificing at least a chicken and a dance with some dinosaur tooth
<sebner> pitti: I'm wondering how this will work out since libatasmart0 != libatasmart4 and former isn't uninstallable.
<sebner> rebuild orgy?
<pitti> sebner: I'm currently preparing a devkit-disks rebuild
<pitti> sebner: but you can install both in parallel
<sebner> done :)
<pitti> any better?
<sebner> pitti: I thought waiting for the devkit-disks rebuild to see any results?!
<pitti> you can test it with /lib/udev/devkit-disks-probe-ata-smart /dev/sd...
<pitti> that should cause the resets with the old version at least
<pitti> if not, it's not the bug I'm talking about all the time
<pitti> I'm tracking down bug 387161
<ubottu> Launchpad bug 387161 in libatasmart "External SATA->USB Drive gives lots of USB resets on ATA smart probing" [Undecided,Confirmed] https://launchpad.net/bugs/387161
<sebner> pitti: dito ;)
<sebner> pitti: LOOOOL. Harddrive working now xD
<pitti> \o/
<pitti> sebner: you grabbed the .debs straight from LP?
<sebner> pitti: sure
<pitti> yay, thanks for testing
<pitti> can you please comment on the bug?
<sebner> pitti: folder created under media now is named "/media/4777707B117F74F2" but nvm ^^
<pitti> I'll ask the other submitters as well with some further instructions
<pitti> sebner: that's a different problem
<sebner> pitti: at least it's working. I'll comment on LP
<pitti> sebner: many thanks for testing
<sebner> pitti: many thanks for fixing ;)
<pitti> meh, current dk-disks doesn't build against libatasmart 0.14
<mathiaz> sbeattie: http://paste.ubuntu.com/249136/
<gp_will_be_back> hey guys pl help me ...............my ubuntu has crashed ...........while boot it says : unable to mount /dev/disk/by-uid/d125634 blah blah  does not exits ...droping to shell
<gp_will_be_back> i thought ubuntu never crashed
<sebner> pitti: interesting thing! I renamed the 95-devkit rules file back and the harddrive is again not working with the -71 error
<gp_will_be_back> in ubuntu supprt chanel ...they are advicing to re-install
<gp_will_be_back> looks like windows isnt it
<gp_will_be_back> even pointer to some article would be helpful
<gp_will_be_back> u guys are my last home
<gp_will_be_back> ^hope
<mdz> bryce: er, I didn't forget to send that script to you. :-)
<gp_will_be_back> my research paper and data was on the disk :-(
<mdz> bryce: I filed it in a bug report and blogged about it at http://mdzlog.alcor.net/2009/06/17/collecting-debug-information-when-your-gpu-hangs/
<pitti> sebner: but calling d-probe-ata-smart manually doesn't cause this?
<bryce> mdz, okay, then it's probably buried in my todo list somewhere
<sebner> pitti: I'll check later. I have to leave now
<bryce> mdz, I talked with jbarnes about adding a better in-server way to catch these freezes and either reset the gpu or raise an apport-triggerable cue, and code to implement this has been written and is somewhere on the conveyor belt coming towards us
<mdz> bryce: ok, let me know if I can do anything to help
<bryce> thanks
<pitti> sebner: oh, I know why
<pitti> sebner: the dk-prober still uses the old libatasmart library
<pitti> sebner: I fixed dk-disks, uploading now (building against new library)
<bryce> Sarvatt: http://www2.bryceharrington.org:8080/drupal/node/84#comment-5344
<gp_will_be_back> can anyone help
<gp_will_be_back> my roomates are making fun of ubuntu :-(
<bryce> gp_will_be_back, just smile and drink their beer when they're not looking
<gp_will_be_back> hmmm ....is there any way to fix the my system
<gp_will_be_back> ...........while boot it says : unable to mount /dev/disk/by-uid/d125634 blah blah  does not exits ...droping to shell
<gp_will_be_back> it just came out of the blue
<gp_will_be_back> i though journaling file system like ext3 was better
<slangasek> gp_will_be_back: journaling filesystems are better than non-journaling filesystems, as a general rule.  If you're saying that you recently changed your filesystem type, then that may account for the boot being unable to find your disk, since the UUID of a partition is part of the filesystem metadata.
<slangasek> gp_will_be_back: when it drops you to the shell, run 'ls /dev/disk/by-uuid' to confirm that the kernel can still see /some/ disk
<slangasek> this is not a help channel, however, and you haven't really given much of the information that would be needed to help you (what version of Ubuntu you're running, what kind of disk you're booting from, etc).  If you're not finding help in the correct channels on IRC (#ubuntu), you're probably better off trying the Ubuntu Forums
<gp_will_be_back> ls ls /dev/disk/by-uuid is getting listed
<gp_will_be_back> i can see one file
<gp_will_be_back> i am using jaunty
<gp_will_be_back> tried ubuntu nobody could help with uid issue there ................since my laptop is down ....my friend has lended me his system ....i cant wait forums to reply
<slangasek> what is the one file?
<gp_will_be_back> please help me
<slangasek> what does 'ls /dev/disk/by-id' show?
<gp_will_be_back> c1b5187-f0aa-8aca-a5f7663e9238
<slangasek> you might want to consider getting an Ubuntu liveCD and booting your system from that - that should a) give you access to your disk, b) give you time to reach the forums to fully debug this problem
<StevenK> That isn't close to the error message you typed earlier
<gp_will_be_back> ...........while boot it says : unable to mount /dev/disk/by-uid/d125634 blah blah  does not exits ...droping to shell :--->>> this file is not there
<slangasek> ok, and 'ls /dev/disk/by-id'?
<gp_will_be_back> c1b5187-f0aa-8aca-a5f7663e9238
<slangasek> that's under by-id, not under by-uuid?
<gp_will_be_back> sorry its by-uuid
<gp_will_be_back> by-id there 8 files
<slangasek> do they appear to show the names of your hard drive?
<gp_will_be_back> some thing like scsi ata for each id
<slangasek> so it sounds like your disk is seen, but the uuid has changed.  Hopefully you haven't somehow managed to delete the partition table, and you just need to get the UUID in your boot config fixed
<gp_will_be_back> its scsi-1ata_st960... ata_960
<slangasek> again, I would suggest doing this by getting a liveCD to use for recovery
<gp_will_be_back> well i recovered the data by running ........sudo e2fsck /dev/sda1 and then mounting
<gp_will_be_back> in live cd
<slangasek> why did you need to run e2fsck?
<gp_will_be_back> bcos fsck3 was giving errors
<slangasek> so you were having other errors /before/ you had this current boot problem?
<gp_will_be_back> no
<gp_will_be_back> it was running fine as horse
<slangasek> then why did you run any fsck command?
<gp_will_be_back> bcos it was mounting the system
<gp_will_be_back> so i went into live cd ....tried mounting and failed
<gp_will_be_back> then fsk3
<gp_will_be_back> then e2fsk
<gp_will_be_back> then i rebooted
<gp_will_be_back> thats after taking backup
<gp_will_be_back> after i saw same uid error
<slangasek> if you already have backups of your data, I think you'll find it much more straightforward to reinstall, then restore your data.
<slangasek> if you don't want to do that, I think booting from a liveCD and seeking help in the forums is your better option
<gp_will_be_back> just like windoZ
<gp_will_be_back> thanks
<slangasek> IRC is usually not a very effective medium for walking through complex problems of this nature, and this is not a help channel...
<gp_will_be_back> what filesystem is more stable and wont crash again ex3 or ext4 ?
<liw> all filesystems are complicated enough that no implementation of them is totally bug-free, so any filesystem may some day crash, if you are unlucky
<liw> (sorry if that is unhelpful)
<slangasek> what you're describing here was not a filesystem crash.  A filesystem crash would not have caused the UUID of your partition to change.
<gp_will_be_back> which one should i use
<liw> (also, what slangasek said)
<slangasek> the default and recommended filesystem in Ubuntu 9.04 is ext3
<Riddell> asac: Lucas Nussbaum
<pitti> kirkland: so, GNOME checks the devkit-poper property
<pitti> kirkland: see devkit-power --dump
<pitti> can-hibernate    yes
<pitti> kirkland: i. e. it'd need to grow a d-bus API to inhibit hibernation (ATM the property is read-only)
<pitti> sice you want to control it on a per-user/per-login basis
 * cjwatson would appreciate an archive admin having a look at partman-iscsi
<pitti> kirkland: I advice you to open an upstream bug against devicekit-power and discuss it with Richard there, he's very responsive
<kirkland> pitti: cool, thanks.
<zul> james_w: have you see this before? http://pastebin.ubuntu.com/249163/
<ojwb> [
<james_w> zul: looks like you did a "bzr checkout http://..."?
<james_w> ah, no, I see it
<james_w> "bzr unbind" should allow you to work
<zul> thanks
<mathiaz> sbeattie: http://paste.ubuntu.com/249177/
<bluefoxicy> brasero needs a "burn to CD as MP3 files" option
 * bluefoxicy burns 75min to an 80min CD and brasero reports it's going to be 735mb for a 700mb cd
<bluefoxicy> and it just went ahead and wrote 766mb o.o
<s0u][ight> hello
<s0u][ight> i have a suggestion/question
<hyperair> !ask | s0u][ight
<ubottu> s0u][ight: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<s0u][ight> since most common laptops (and pc's) nowadays have a rescue partition in stead of an install cd, and since these can only be used by calling a restore application which will somehow interact with the windows bootloader and make it boot into the rescue partition
<s0u][ight> installing grub kills this feature
<s0u][ight> i have tryed to boot into this partition using grub, it failed
<s0u][ight> reinstalled the windows bootloader (don't ask me how i did it, spend all day to get my original bootloader back)
<s0u][ight> and tryed it again and it worked
<s0u][ight> is it normal that actually installing ubuntu is killing this capability, shouldn't you guys prevent this from happening, and now the real question: is there a way to boot into linux using the windows bootloader
<Hobbsee> to the latter, yes, iirc
<s0u][ight> Hobbsee do you also know how?
 * Hobbsee is looking for info on it
<s0u][ight> i managed to fix the issue, i can now always reinstall the windows bootloader, but i don't think that will be the case for a lot of users
<Hobbsee> s0u][ight: it's alluded to in https://help.ubuntu.com/community/WindowsDualBoot  - iirc, tha tpage used to have more info on it in the past, but  would have been for XP
<Hobbsee> a google search may provide more info, though
<s0u][ight> Hobbsee found a lot about xp and stuff
<s0u][ight> bot nothin' i consider up to date
<cjwatson> s0u][ight: I consider it a bug that the installer didn't detect your recovery partition and add a boot entry to the grub configuration to let you boot insinto it
<cjwatson> s0u][ight: not that I necessarily know how to do this in your case
<cjwatson> but I know we do this in some cases
<cjwatson> so be careful about generalising from the failure in your case to say that it breaks for everyone, because I don't think that's true :)
<s0u][ight> cjwatson no it detects but the rescue partition doesn't work that way
<s0u][ight> first an application in the windows vista environment has to know that you want to recover
<cjwatson> if the windows bootloader can boot into the recovery partition, so could grub
<cjwatson> we just need to figure out how
<s0u][ight> cjwatson booting isn't a problem
<s0u][ight> it boots into the rescue partition fine
<s0u][ight> the app that makes the boot crashes
<s0u][ight> telling rescue fails
<cjwatson> the fact that they happen to implement this by way of an application doesn't mean that that application is required
<s0u][ight> hmm, actually i only tryed booting into 1 rescue partition
<s0u][ight> but i have 2 partitions that work together afaik
<s0u][ight> never tryed booting into the other one
<s0u][ight> maybe that way it'll work
<s0u][ight> but got to go now, (friday prayer) laters all ;)
<sbeattie> cjwatson: is there a reason the zsync files didn't show for the ubuntu-server daily images?
<cjwatson> sbeattie: not intentional ...
<cjwatson> sbeattie: the log *says* it made one
<bwright> Where can I find documentation on initialize_main() and other functions used in coreutils?
<arand> Validation of a pkg upload to -proposed, how long does that normally take? And is it especially busy currently with 9.10 in parallell?
<cjwatson> bwright: that's just part of coreutils itself - it's not a system facility
<cjwatson> bwright: at least not on our system. I think it might be a VMS function or something used for compatibility
<cjwatson> bwright: see src/system.h
<bwright> cjwatson, Thanks.
<cjwatson> the comments suggest that it handled redirection and wildcard expansion on VMS, where the program had to take care of that itself rather than having the shell do it
<tseliot> cjwatson: do transitional packages need to have Section: oldlibs in debian/control or does that affect only libraries?
<tseliot> just to be sure
<slangasek> tseliot: it's normally only used for actual libraries, not arbitrary transitional packages
<slangasek> "oldlibs" implies "libs we keep around because third-party software needs it", not "transitional packages"
<tseliot> slangasek: aah, ok. Thanks for the explanation
<sebner> pitti: also with new devicekit-disks the issue is *not* fixed when having the rules file normally named!
<sebner> pitti: I also can't execute your posted commands .. No such file or directory :(
<pitti> sebner: apt-get install libatasmart-bin ?
<pitti> sebner: hm, if these commands don't reproduce the crash, it must be something else entirely
<sebner> pitti: already installed
<mbiebl> pitti: thanks
<pitti> sebner: and you don't have skdump?
<sebner> pitti: sebner@ubuntu:~$ sudo skdump /dev/sdb1
<sebner> Failed to open disk /dev/sdb1: No such file or directory
<sebner> no sdb* represent in /dev
<cjwatson> seb128: are you doing syncs just at the moment?
<cjwatson> tseliot: it's sensible for transitional packages too, although not mandatory
<pitti> sebner: ah
<seb128> cjwatson, I just did a quick one for kenvandine
<pitti> sebner: well, whatever the hard disk is which has the problem
<seb128> cjwatson, need to do some or do you want me to do another one?
<cjwatson> sla	hmm, we disagree apparently :)
<pitti> seb128: also, not '1', but the raw device
<sebner> pitti: hm?
<seb128> pitti, what?
<pitti> sorry, "sebner"
<tseliot> cjwatson: ah, good to know. Thanks
<sebner> pitti: my external harddrive usually is on sdb1 but I'm not that dumb and of course tried pure sdb .. I told you no sdb* present ;)
<cjwatson> seb128: ok, I just wanted to give muharem some archive training
<seb128> cjwatson, it's all yours
<seb128> I did the one I wanted to do
<pitti> sebner: sure; can you check dmesg about what's the actual device?
<maco> sebner: remembering that external is sdb is very important. i still havent re-ripped all my music from the time i forgot that and did an install
<sebner> pitti: [21183.928940]  sdb: sdb1
<sebner> maco: hmm? I know that  external is sdb ;)
<maco> just dont forget it midway through install :P
<sebner> maco: I'm using ubuntu for 3 years now .. don't worry ;)
<Riddell> evand: usb-creator merge for you
<maco> sebner: mistakes happen :P
<sebner> maco: well .. true but be more afraid that I don't break any packages you use (I'm MOTU) ;)
<iulian> We're all breaking something, someday.
<sebner> iulian: Breaking stuff is fun \o/
<sebner> well except hardware maybe ^^
<evand> Riddell: Merged, thanks!
<evand> Riddell: Feel free to commit such things directly in the future.  (~core-dev is in ~usb-creator-hackers)
<evand> I'm equally happy to take merges though
<Riddell> evand: right, so it is
<sebner> pitti: as I can remember with this -71 error my harddrive never appears in /dev O_o
<mathiaz> james_w: could you import schroot pkg in LP?
<beuno> pitti, hi. Let's say I wanted to know what version of gnome karmic is shipping, just by looking at Launchpad. Where would I look>
<beuno> ?
<beuno> I defaulted to: https://edge.launchpad.net/ubuntu/+source/meta-gnome2
<beuno> but 2.22 doesn't sound right
<pitti> beuno: I'd use "rmadison gnome-panel"
<pitti> beuno: at launchpad, use https://edge.launchpad.net/ubuntu/+source/gnome-session
<pitti> beuno: no, we aren't using meta-gnome
<beuno> pitti, so, basically, "find a key gnome package, and use that?"
<pitti> right
<beuno> I'm trying to automate something
<pitti> gnome-session is probably representative
<beuno> ok, that complicates things for me quite a bit
<beuno> but I guess it's no fun otherwise, right?   :)
<beuno> thanks pitti
<james_w> mathiaz: thought I did that one the other day!
 * directhex links cve 2009-0217 to bug #409920
<ubottu> Launchpad bug 409920 in mono "Sync mono 2.4.2.3+dfsg-1 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/409920
<james_w> mathiaz: spurious failure, I've retried it
<liw> the printing dialog that firefox, epiphany, and other gnome apps use, probably comes from some shared package -- I need to file a bug against it, what's the packag ename?
<liw> libgnomeprintui2.2-0 ?
<beuno> pitti, one more question. Is there anywhere on Launchpad (or elsewhere if not) that I can see all the packages shipped in the default installation?
<davmor2> pitti: Jockey seems to be refusing to install the fglrx drivers on my ati box with todays iso
<directhex> davmor2, is dkms present & correct?
<davmor2> directhex: ii dkms 2.0.21.1-ubun~
<davmor2> directhex: ii dkms 2.0.21.1-ubuntu3 to be complete
<Riddell> asac: svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
<Riddell> asac: svn co svn://anonsvn.kde.org/home/kde/trunk/playground/base/plasma/applets/networkmanager
<Riddell> asac: also need   libknotificationitem-dev  build-dep for that  and may as well install  kdebase-workspace-dev too so you don't have to compile the whole thing
<Riddell> asac: mkdir build; cd build; cmake -DCMAKE_INSTALL_PREFIX=/usr ..; cd <what you want to compile>; make
<papa_> hi guys
<Gadi> is there a way for me to build the linux-backports-modules source package for a single arch?
<gigabytes> hello
<gigabytes> I saw the wiki pages about the hardware support for macbooks. Specifically for my model there are some piece of hardware that need manual configuration, or to install additional packages from the external mactel repository. Are those packages planned to be included in the next ubuntu release?
<loic-m> gigabytes: you can check if some packages are in good way to be included in next release by checking if there's at least a needs-packaging bug open in launchpad, and see how far it has gone (including checking on REVU if the package has been submitted, and if the submitter has been responsive to input, and if not take charge yourself for the packages you're interested in)
<loic-m> If there's no bug in Launchpad and the package isn't in Karmic yet, it's your responsibility to at least fill a needs-packaging bug, else nobody knows what's needed ;)
<gigabytes> ok
<gigabytes> loic-m: so I file this bug on launchpad, the community "knows" that the package is needed to make ubuntu work on that hardware model, and then if the package is stable and actively mainteined by someone, it will be included?
<loic-m> gigabytes: you first check nobody's working on it by checking if a bug is open in Launchpad, and if not you fill the bug. You can also check in Debian and fill another bug in Debian (RFP - request for packaging)
<gigabytes> loic-m: other than packages, there are some manual workarounds to do, like adding entries in /etc/modules or in the modules blacklist. Another manual setting to do is the synaptic trackpad configuration. How can I help to make those things done automatically?
<loic-m> gigabytes: then considering the huge number of progrrams people would like packaged and the really low number of people actually willing to package them, it might be faster to learn how to do it yourself and start working on it ;) else it can take years
<gigabytes> loic-m: maybe you didn't understand. The packages already exist
<gigabytes> they're on launchpad
<gigabytes> I don't have to package anything
<loic-m> gigabytes: for configurations and tweaks, you'll want to checks there's at least bug reports for the bugs, else nobody will know about them, fill them yourself if needed, see on #ubuntu-bugs
<gigabytes> https://help.ubuntu.com/community/MacBookPro5-5/Jaunty this is the page
<gigabytes> loic-m: ok
<loic-m> gigabytes: the fact some packages are on launchpad doesn't mean the packager is doing any work to see them included, nor that they are good enough to be included in their actual state
<gigabytes> ok
<loic-m> (copyright issues, bad packaging, etc...)
<gigabytes> loic-m: can't I simply file a bug like "those things are not automatically recognized by the default ubuntu install" and point to that wiki page?
<loic-m> then for configuration issues and tweaks, the easiest is if the bug is reported upstream and the fix gets included upstream, else you can get involved with the respective teams (kernel, ubuntu-x, etc..)
<loic-m> gigabytes: no, because there's thousands of wiki pages and only like 2 or 3 people actually able to fix the bugs on each team (and they already have enough work with bugs people care enough to fill properly and help them for testing, etc)
<gigabytes> ok
<gigabytes> it makes sense :D
<gigabytes> loic-m: thank you
<loic-m> gigabytes: you're welcome. The idea is that there's about zero chance anything gets fixed unless it gets reported properly, and then there's so much already to do that doing a good job communicating and pre-processing the info can help reduce the delay it gets fixed from a few years to one or two years only ;)
<gigabytes> eheh
<gigabytes> I hope It won't take two years to fix those things
<gigabytes> I hope I could cleanly install ubuntu on my laptop at least in 10.4
<gigabytes> thank you
<loic-m> gigabytes: and don't forget to nicely ask Apple if they could be nicer with Linux by using less proprietary hardware and working with distributions/upstreams so their hardware can actually work in Linux
<StevenK> loic-m: HA HA
<loic-m> StevenK: I was actually tempted by MBP 13' before I read that page on the wiki ;D
<loic-m> That and their obstination to put mirrors where you'd expect a screen
<gigabytes> loic-m: well that's another point
<gigabytes> apple doesn't gain anything from linux working well on their machines
<gigabytes> so i don't think they'll change their strategy in this area..
<loic-m> gigabytes: as long as Linux users keep buying their hw they won't gain anything working with Linux :P
<loic-m> gigabytes: but even if you send the letter after you've bought it, it's still better than nothing. Tell them your laptop is as usefull as a brick, even though it's an nice looking brick.
<gigabytes> loic-m: the point is that its untrue, at least for me..
<gigabytes> I use OSX for the daily work
<gigabytes> so my laptop is a lot useful
<gigabytes> linux is more an hobby...
<gigabytes> so I can't send those kind of letters..
 * directhex uses a 24" imac as his office desktop - it's been running ubuntu since day 1, and rarely sees osx
<directhex> new f-spot!
<chrisccoulson> directhex - yay \o/
<directhex> Laney can package it. he loves f-spot packaging!
<chrisccoulson> its quite a significant update isn't it?
<directhex> AFAIK
<directhex> it should also have some build system fixes which should eliminate needless deps
<chrisccoulson> i keep having a look in git every now and again, and i see a lot is changing
<chrisccoulson> i can't wait to use it :)
#ubuntu-devel 2009-08-08
<Laney> wicked
<Laney> I will package that bad boy!
<ScottK> directhex: Would you please have a look at getting mono building correctly on powerpc?  It's currently blocking KDE builds.
<ebroder> Is there a way to force udev to reset the permissions/ownership on a specific device node? udevadm trigger...something?
<cwillu_clone> Who could I poke about a patch I've written for libwnck to fix up the vertical task-list brokenness?
<stbuehler> hi; i fear that some of my ppa builds are hanging (and blocking other builds): https://launchpad.net/builders/lemon
<stbuehler> infinity: *ping* - you are listed as owner
<stbuehler> looks like still no one cares that my ppa builds are blocking 6 servers now... 3 for >1h, 3 since 30min
<stbuehler> and no, they are not doing anything useful like compiling, they just hang while trying to do "make check" (and i have no f**** clue how to turn that check off)
<kklimonda> stbuehler: give them some slack, it's saturday morning for some and still middle of the night for the others ;)
<geser> stbuehler: you might have better chances in #launchpad but as it's weekend the persons who can do something about it are not there
<stbuehler> i guess i should just increment the version and upload it again until all servers are blocked... perhaps that helps :p
<cwillu_> stbuehler, it's called the soft freeze :p
<cwillu_> oh, ya
<cwillu_> just in case anyone has some morbid curiousity, here's the original version of that patch :p http://launchpadlibrarian.net/30046252/vertical.patch
<cwillu_> ... wrong channel, kinda
<stbuehler> as it looks like i can't do anything to cancel the builds i will leave this channel - if someone needs to contact me i'm still on freenode :)
<stbuehler> cya
<Yoe> so, whom do I nudge to look at an nbd update again?
<Yoe> there's been quite some changes since the version that's in ubuntu currently, I'd like to think they'd be worth the while of the update :)
<Yoe> (amongst others, a change that makes modprobe not break the initscript, which is rather crucial if you want it to actually work)
<geser> Yoe: see bug 399707, looks like the merge needs to be reviewed and sponsored by a core-dev
<ubottu> Launchpad bug 399707 in nbd "Please merge nbd 1:2.9.13-2(main) from debian unstable(main)" [Wishlist,Confirmed] https://launchpad.net/bugs/399707
<Yoe> geser: okay, thanks. Looks like it's being worked on already, then -- so I'll leave it at that.
<YokoZar> Is there an easy way to get the source archive for an obsoleted package?
<YokoZar> I want to backport a slightly older version (-ubuntu4 instead of ubuntu6)
<directhex> YokoZar, should be on launchpad
<directhex> click "see full publishing history" then click on the desired version
<directhex> e.g. https://launchpad.net/ubuntu/jaunty/+source/wine/1.0.1-0ubuntu4
<YokoZar> ah hah ;)
<YokoZar> how'd you guess it was Wine ;)
<directhex> somehow, scott, i doubted you were busy backportin' python
<tgpraveen1> asac: why was gnome-bluetooth chosen over blueman
<tgpraveen1> any specific reasons?
<azeem_> tgpraveen1: isn't gnome-bluetooth part of GNOME?
<tgpraveen1> azeem_: so? epiphany is also
<tgpraveen1> asac: any reasons feature wise?
<kklimonda> help
<kklimonda> heh, not here
<pochu> tgpraveen1: blueman bugs
<pochu> and it being written in python
<tgpraveen1> pochu: any specific bugs in question?
<tgpraveen1> and lan shouldnt matter imho
<tgpraveen1> lang
<pochu> why not?
<pochu> I don't know what bugs they are
<tgpraveen1> why should? we have apps in so many various lang
<tgpraveen1> c,c#,etc
<pochu> 13:06 <      asac> we did details tests and blueman has quite a few bugs we cannot fix
<pochu> 13:07 <      asac> at least i have no time ;) (though its easier to fix becaues its python)
<pochu> 13:07 <      asac> but also python is too heavy weight for an applet
<tgpraveen1> k
<dhillon-v10> Hello everyone
<Aquina> hy
<dhillon-v10> how are you?
<dhillon-v10> Acuina are you still there
<dhillon-v10> hey is anyone there
<Aquina> yes
<bluefoxicy> malone 408153 is still marked incomplete
<ubottu> Launchpad bug 408153 in evolution ""Send an email" alarm option grayed out" [Low,Incomplete] https://launchpad.net/bugs/408153
<bluefoxicy> whate else is needed?
#ubuntu-devel 2009-08-09
<damo221> what are the essential build lib packages? i get errors like strncmp not defined
<Hobbsee> they're dependancies of a package called build-essential
<damo221> i installed build-essential, but i still dont have all the cpp libs
<damo221> im running on a 9.04 livecd... just want to compile something
<Hobbsee> hm
<RAOF> strncmp is in libc6-dev; you'll have problems doing almost anything if that's not installed :)
<damo221> thanks
<hunger> Any idea why my webcam won't work in karmic? It uses uvcvideo.
<damo221> libc6-dev is already the newest version.
<damo221> http://pastebin.com/m698db6de can someone see if im missing something really basic here
<jetienne> q. i am writting a fuse fs and everytime i mount it, there is an external process doing getattr+statfs every second on it, this is desktop application as it occurs only when under X, anybody got an idea of which program is doing this ?
<AnAnt> Hello, could someone sponsor this merge: LP 406890
<ubottu> Launchpad bug 406890 in irssi "Please merge irssi 0.8.14-1(main) from debian unstable(main)" [Undecided,Confirmed] https://launchpad.net/bugs/406890
<ebroder> jetienne: If you want to find the program yourself, there's the getContext call (or whatever it's called in your langauge's API) to get the PID of the caller
<ebroder> Although if you're mounting the filesystem in your homedir, I'd guess beagle
<jetienne> ebroder: thanks. i will look. im a beginner at fuse
<ebroder> jetienne: What language are you programming in?
<jetienne> ebroder: in python
<ebroder> Ok. Then you want to call fuse.FuseGetContext()
<ebroder> From within your getattr or statfs methods
<Laney> irssi is in main?!
<jetienne> ebroder: thx
<AnAnt> Laney: yup
<Laney> I wonder why
<Laney> is it seeded or something?
<pochu> no, but any real developers use it! ;)
<pochu> there are packages not seeded that are in main
<Laney> huh
 * Laney shrugs
<AnAnt> I just noticed that this merge bug was confirmed by the same person who filed it, no wonder it hasn't been looked at by a main-sponsor for a while
<pochu> liferea is another example
<AnAnt> it should be confirmed by a main-sponsor right ?
<pochu> it should be sponsored by a main sponsor :)
<AnAnt> ok, I set it back to new
<pochu> I don't think who confirmed it matters in any way
<pochu> (it does for sync requests though)
<AnAnt> ok, I set it back to new
<Laney> I always confirm bugs when I ask for sponsorship on them
<AnAnt> ok, so can a main-sponsor confirm/sponsor it ?
<jetienne>  /usr/lib/gnome-applets/multiload-applet-2 <- ebroder it was it. thanks for your help
<loic-m> AnAnt: Why do you set to new merge bugs that are already set to Confirmed? It will just mess up the process
<loic-m> AnAnt: see https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue and please revert what you have already done
<loic-m> AnAnt: "The Status should be "Confirmed" for bugs that represent a new candidate revision (e.g. bugfix uploads, merges.) In other words, use Status "Confirmed" when you have uploaded a debdiff that requires attention from a sponsor."
<AnAnt> loic-m: oh, I thought it should be confirmed by main sponsor, sorry about that & thanks for the info
<AnAnt> loic-m: fixed
<loic-m> AnAnt: no pb, it wasn't one of my bugs :D but remember nobody takes it kindly when they've done work on a bug and this happens... Wiki is really good source of info, every MOTU-related pages and the like
<loic-m> AnAnt: any reason you touched that bug when Bhavani Shankar had already done the job?
<AnAnt> loic-m: actually, I thought that it wasn't sponsored because it wasn't cofirmed by a main-sponsor
<loic-m> AnAnt: then unless you're a main-sponsor you've got no reason to touch those bugs - next time please ask the developper that worked on the bug directly first before touching anything
<AnAnt> loic-m: ok, thanks
<loic-m> np
<AnAnt> by touch you mean changing status & so ?
<AnAnt> loic-m: or even comments ?
<AnAnt> loic-m: I added the merge changelog entry in a comment to that bug because I saw that sponsors usually prefer to see that in the bug report
<loic-m> No, you're free to comment any bugs, and modify status of bugs nobody cares for. But please don't modify status/etc.. when someone has already set them (and obviously worked on the bug).
<AnAnt> ok
<loic-m> AnAnt: Wasn't the changelog already in the description (unless you added it)? If so, you can repeat stuff in comments without much harm, except the spam it generates for those subscribed of course
<AnAnt> loic-m: that wasn't merge changelog entry, that was debian's last changelog entry
<jetienne> ebroder: as you are clearly experienced in fuse, do you know if there is a channel about it ?
<eddel> What is the Ubuntu equivalent of   "Section: non-free/foo"   in debian/control?   I have something that cannot be in universe, so would I map this out to non-free just like in Debian?
<elmo> eddel: multiverse is Ubuntu's non-free
<eddel> so     Section: multiverse/foo   eg   multiverse/math   or whatever the section is?
<elmo> eddel: yep
<eddel> elmo: Thanks a bunch!  ppa upload will follow shortly
<genii> Hi, trying to pin the kernel here on a 9.04 box with an /etc/apt preferences file like here: http://pastebin.com/m5a450885   The 3rd stanza would be to prevent the kernel being downgraded to packages with names like linux-image-2.6.28-6-386 ... however wildcards seem not to work here. Is there another way?
<Laney> Try #ubuntu for support
<genii> Laney: Will do.
<Laney> or your loco
<arand> How long can I expect validation of upload to -proposed to take? And should I poke someone after a week or so?
<Laney> there's a sru-verification team, not sure how they work
<Laney> try #ubuntu-quality
<Laney> or just ask someone you know to test it ;)
<arand> Laney: I guess it's in the stage of being validated by admin, to get into -proposed... I'm not really sure of anything though, with it being my first ever patch in the system.
<Laney> oh, you mean like that
<Laney> you need to subscribe motu-sru or ubuntu-sru
<arand> Laney: yea, that's already done (LP #316502) is the one in question
<ubottu> Launchpad bug 316502 in goffice "cannot release a graph in gnumeric after click and drag" [Medium,In progress] https://launchpad.net/bugs/316502
<Laney> ok so you just have to wait
<Laney> https://launchpad.net/ubuntu/jaunty/+queue?queue_state=1&queue_text= it's right there
<arand> Laney: ah, thanks, I was looking for that queue :D
<lucazade> 0.000000000..
<dhillon-v10> hi everyone
<dhillon-v10> hi everyone
<jpds> dhillon-v10: Hi.
<dhillon-v10> jpds: how are you?
<jpds> !ot
<ubottu> #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics. Thanks!
<dhillon-v10> jpds: Alright well I have a question
#ubuntu-devel 2010-08-09
<pitti> Good morning
<ajmitch> morning pitti
<dholbach> good morning
<didrocks> good morning dholbach, how are you?
<dholbach> didrocks: good good - how are you?
<didrocks> dholbach: I'm good too. Having nice time in the Alpes :)
<dholbach> oh wow - are you on holidays there?
<didrocks> dholbach: not this week, from next week, I'll :)
<dholbach> didrocks: awesome - hope you'll enjoy it
<didrocks> dholbach: always going back where you are born is a joy. thanks! :)
<didrocks> (and now, there is a decent Internet connexion ;))
<mvo> didrocks: nice! what area are you in?
<didrocks> mvo: near Annecy (which is one hour away from GenÃ¨ve), a little village called Thorens-GliÃ¨res :) Do you know the surroundings?
<mvo> didrocks: not that well, but I want to spend my next vacation in the alpes, chamonix is not that far, right?
<didrocks> mvo: something like 70 kms, not very far, no. A little bit higher and colder though :)
<didrocks> mvo: when will you have your next vacation, btw?
<mvo> didrocks: I will have a short one next week, but the alpes will have to wait until next year
<mvo> didrocks: I will ask you for good recommendations of places etc, great to know that you are faimilar with the area :)
<didrocks> mvo: sure, do not hesitate :)
<maco> didrocks, mvo: possibly a silly question, but do you two ski?
<maco> my brain's going "alps.....SKIING!"
<didrocks> maco: not on that period (at least for me), rather in winter :)
<maco> well yes i realise not this week :P
<didrocks> heh :)
<geser> mvo: what's the status of bug #608747? In the last comment you mentioned that you uploaded it but maverick still has 0.3 (and not 0.4).
<ubottu> Launchpad bug 608747 in goplay (Ubuntu) "Please merge goplay 0.4-1 (universe) from debian (unstable)" [Undecided,In progress] https://launchpad.net/bugs/608747
<hrw> rebuilding eglibc again...
<hrw> hope that this time it will not end in build loop
<mvo> geser: yeah, sorry. I meant to upload. let me look again
<mvo> geser: tbh some of the changes are a bit dubios so I was hoping for clarification from david
<geser> mvo: I'll contact David and ask about the status, as I'd like to get this merge gone before FF as the package currently FTBFS
<mvo> geser: thanks, I just looked over the diff again and afaics the only think needed is the change in src/pkgbrowser.cpp to make it work with fortify, that will probably taken upstream if we submit it. I will comment in the bug
<ara> pitti, hello
<jibel> mvo, hello
<jibel> mvo, I was trying to reproduce an update-manager issue for an lts to lts upgrade but can't because there is no record for lucid in http://changelogs.ubuntu.com/meta-release-lts
<mvo> jibel: can you use update-manager --proposed?
<pitti> hey ara, how are you?
<ara> pitti, good thanks, yourself?
<pitti> ara: I'm great, thanks
<mvo> jibel: and thanks for your mail about dbus, I shall reply today (sorry that I haven't already :(
<ara> pitti, I have a question related to apport-symptoms
<ara> pitti, (I am writing a new one)
<jibel> mvo, --proposed works because it downloads the -development meta-release
<ara> pitti, if a sympton leads to a package that it is not xorg, but it is useful to attach xorg information as well, is there a way to attach it?
<mvo> jibel: right, not yet, we will add it this week when 10.04.1 is officially released. do you need it in order to verify the upgrade issue?
<mvo> jibel: I mean, do you need it now?
<jibel> mvo, ok, no I don't need it, I added the record by hand to the local meta-release file
<mvo> jibel: thanks! what issue is it? there is still (a bit) of time to fix package failures before the upgrade becomes enabled by default
<mvo> jibel: when that happens the users will see the upgrade button on hardy
<jibel> mvo, that was an SRU uploaded few weeks ago. pitti uploaded it to -updates this morning, so everything is fine.
<mvo> jibel: great, thanks
<pitti> ara: hm, let me look
<pitti> ara: so, not directly; if you only need the noninteractive part, you could just copy the attach_hardware() and other bits
<pitti> ara: if you really want the full thing, you could import /usr/share/apport/package-hooks/source_xorg.py and call its add_info()
<ara> pitti, OK, thanks
<pitti> ara: i. e. either temporarily add that to sys.path and import, or use execfile()
<ara> pitti, I won't need everything, I'll just copy the necessary bits
<ara> thanks again
<hyperair> are there any archive admins around here to feel up to looking into a source new package?
<hyperair> s/to/who/
<hyperair> http://launchpadlibrarian.net/53247690/ctpl_0.2.2-0ubuntu1_source.changes <-- this package is currently needed by the new geany-plugins package, which FTBFS.
<dholbach> davmor2: HAPPY BIRTHDAY! :)
<davmor2> dholbach: thanks
<Laney> ftbfs, not depwait?
<tjaalton> unpacking packages in lucid is veeery slow, is this the ext4/dpkg issue still?
<hyperair> Laney: i thought it'd depwait, but it ended up being marked ftbfs. weird, eh?
<Laney> weird
<Laney> indeedy
<soren> Laney, hyperair: bug #615286 perhaps?
<ubottu> Launchpad bug 615286 in Launchpad Auto Build System "DEPWAIT not recognized from build log" [Undecided,New] https://launchpad.net/bugs/615286
<hyperair> ah, i see.
<pitti> tjaalton: should be better with the lucid-updates version of dpkg
<tjaalton> pitti: i think this time it was due to hung nfs mounts
<tjaalton> will test in a bit
<debarshi> Is there any Ubiquity developers here? The #ubuntu-installer channel is full of people but has been too quiet for the last 3 days.
<soren> debarshi: It's called weekend.
<debarshi> soren: I have been there on Fri and Mon too. :-)
<alf__> Hi! for a package that build-depends on python 2.x >= 2.4, is "Build-Depends: python (>= 2.4), python (<< 3.0)" a reasonable way to to express this?
<pitti> that would stop working once we switch the default pyhton to 3.x, but still support 2.x
<alf__> pitti: so, what is the recommended way of expressing this dependency?
<pitti> alf__: I don't know; I'd start with python2.6 | python2.7 | python 2.5 | python2.4, but for now python (<< 3) should work as well
<alf__> pitti: ok, thanks!
<free> pitti: hi! do you have some time today to look at https://bugs.launchpad.net/landscape-client/+bug/610744 and possibly let the packages into -proposed?
<ubottu> Launchpad bug 610744 in Ubuntu Karmic "Update jaunty, karmic, lucid and maverick to landscape-client 1.5.4" [Undecided,New]
<pitti> free: probably not today, sorry; also, lucid is frozen right now for the point release
<free> pitti: oh I see, when do you think we could reasonablt get them in?
<pitti> next week hopefully
<free> pitti: that's fine, thank you
<asac> stgraber: will revu get support for source format 3.0 soon?
<ScottK> pitti and alf__: You don't need to specify python (<< 3.0).  Python3 is (and will remain) a separate runtime.  All python versions will remain less than 3.  Note there is a python3 package for those things that need/support it.
<smoser> pitti, ping.
<pitti> smoser: pong
<smoser> I'm following up on a ping earlier from free.  The landscape-client fix that they're wanting into -proposed/-updates reasonably blocks 10.04.1 UEC images from being respun.
<smoser> i'm wondering if we could get that into -proposed early after release on thursday or friday ? so we could at least pick that and roll a images refresh sometime next week ? (ie, 19th ish)
<pitti> smoser: sounds fine
<smoser> (image builds only pull from -updates, not -proposed, and the client needs to be baked in to really suffice for them).
<pitti> we don't have a RM for 10.04.1 yet, though
<smoser> RM as in Manager or Milestone
<pitti> manager
<smoser> ok. so, free, you need to start begging pitti soon after release announcement is made on thursday.
<free> smoser: okay :)
<smoser> thank you pitti
<free> pitti: btw is lucid-proposed frozen as well? if we could get the packages into -proposed even before the release we could squeeze some days
<pitti> free: yes, that's the main target of the freeze
<pitti> we build test CDs out of -proposed
<free> pitti: fair enough
<Sarvatt> heads up in case anyone missed the emails, the new xserver release has been uploaded and upgrades are going to be messed up for a bit while all of the drivers build - https://lists.ubuntu.com/archives/ubuntu-x/2010-August/000931.html
<Laney> would be nice to cc -devel on those
<sebner> w000T! Breakage ftw!
<pitti> Laney: it was, even -discuss
<Laney> pitti: oh, don't routinely read discuss
<ogra> PingJocky, who reads discuss :P
<Sarvatt> it's in moderation
<ogra> err
<ogra> pitti, indeed
<ScottK> Sarvatt: Might have been worth a mail to ubuntu-devel-announce.  I think it's fair to assume all developers read that one.
<Sarvatt> it's in moderation for ubuntu-devel-announce I meant, sorry
<ScottK> Ah.  Good.
<njin> ara: around ?
<ara> njin, I am
<njin> hello, i've some time, and i want to test, but now the alpha 3 has released
<njin> ara: have sense report on iso tracker ?
<ara> njin, I have seen that some people reported, but I haven't had time yet to look to all the reports
<ara> njin, anything in particular that you want to discuss?
<njin> no, i'm waiting of daily test reporting
<njin> ara: or better when i've free time testing
<LucidFox> dholbach, you here by any chance?
<dholbach> LucidFox: yes
<LucidFox> Good, good! We're discussing the rebranding of Behind MOTU with nigelb, I was wondering if it would make sense to get into a separate channel for this
<dholbach>  /j #behindmotu
<tim> hi, i've been trying to backport gcc-4.5.1 to lucid (from the lp:ubuntu/gcc-4.5 repository). it compiles, but when generating the man pages, it stops with this error: http://pastebin.com/FVRaBeM3. any idea, why?
<jono> hmmm, has a recent maverick update caused problems with people starting X?
<sebner> jono:  https://lists.ubuntu.com/archives/ubuntu-x/2010-August/000931.html  :)
<jono> sebner, erk
<jono> I picked possibly the worst time to upgrade
<sebner> heh
<sebner> indeed
<bilalakhtar> Can anyone get https://edge.launchpad.net/ubuntu/+source/qcake/0.7.2-2 rebuilt ?
<nigelb> bilalakhtar: you're MOTU?
<bilalakhtar> nigelb: nope, but trying to become one
<nigelb> ok, somone with at least motu should press that "big red" button
<bilalakhtar> nigelb: yup
<bilalakhtar> nigelb: Aren't you one?
<nigelb> not yet
<bilalakhtar> nigelb: Atleast, we should be able to get packages rebuilt
 * stalcup looks
<stalcup> bilalakhtar: why did it fail?
<bilalakhtar> stalcup: For some 'not going to be installed' problem
<bilalakhtar> stalcup: some wierd problem, it succeeds in my pbuilder
<stalcup> ah, ok
<stalcup> looks like a dependacy problem to me
<stalcup> dependancy too
<bilalakhtar> stalcup: but, Rhonda ACKed it. It is a temporary problem
<stalcup> so the libreadline5-dev problem has been resolved?
 * stalcup retries the builds
<stalcup> bilalakhtar: ok, they are in queue
<bilalakhtar> stalcup: Thanks@
<strycore> Hi
<strycore> I thought it would be a good idea to drop by and ask if I can press 'Y' and watch my xorg go in oblivion on my Ubuntu Maverick install
<strycore> I know I read somewhere something like "watch out for the next xorg update"
<geser> strycore: depends if you want to use X till the transition is finished or not; and #ubuntu+1 is the better place for maverick support
<strycore> well yeah , I'd rather have X ;)  thanks for the tip
<smoser> Daviey, around ?
<SpamapS> hrm, if I need to run a step in debian/rules as a non-root user, how should I do that? su? sudo?
<micahg> I think the better question is why
<SpamapS> I need to create a postgres database to run some tests with a postgres client library
<micahg> why does that need to be non-root?
<micahg> from the system perspective, not postgres
<SpamapS> because postgres insists. :-P
<SpamapS> /bin/sh debian/test_postgres.sh
<SpamapS> initdb: cannot be run as root
<SpamapS> micahg: I have no problems with these tests running as root, since the rest of the build does as well.. but postgres is being stubborn, so I need to give it a different uid.
<Laney> patch the tests?
<micahg> ok, I'm not familiar with postgres, so I can't help
<SpamapS> Laney: I'd have to patch postgresql
<SpamapS> kind of annoying.. there just seems to be no good way to reliably make sure something you're running does not have root privileges. :-/
<aruna> hello, quickly package puts my app/data directory under usr/share any ideas as how to resolve this please ?
<SpamapS> aruna: thats where static shared data should go
<aruna> yes I know the thing is I have my data files under /data and need the SAME directory structure
<SpamapS> aruna: if it is runtime-data (meaning generated after program start) it should be in /var/lib or /var/run, and if it is user-owned data, somewhere under $HOME
<SpamapS> aruna: /data is an invalid directory under the filesystem hierarchy standard
<aruna> ok understood but how does one resolve an issue such as this ?
<SpamapS> resolve what issue?
<aruna> am trying to build a shoutcast front-end in quickly oki ? Works fine on my box but when the deb is installed file paths are out of sync
<SpamapS> Ok, the issue is that your program is making assumptions about the system filesystem that it should not.
<SpamapS> what data is this?
<SpamapS> some kind of static table or something that the program downloads, or updates all the time?
<aruna> am sorry am very new to linux and just getting familair with python and quickly please tell me how to do thinsg the correct way
<SpamapS> right, think of it another way, you really need to figure out how to let the system do it the right way for you. ;)
<aruna> it's on my launchpad ppa - there is a python tutorial and the shoutcast. Both have the same prob
<SpamapS> aruna: its probably data that should be going into the user's home dir. I'm not familiar with the conventions of quickly, but I'd bet it has a module for doing this already.
<SpamapS> aruna: this being, putting data into a user's home directory
<SpamapS> ugh
<SpamapS> somebody should rename quickly
<SpamapS> such a common adverb!
<aruna> no noo in the quickly tutorial it specifically tells you that when developing the code will be under /data and the deb will have usr/share and quickly IS a very useful tool makes life a lot simpler :-)
<aruna> see all I need to understand is HOW to create a /data directory under usr/share through my code
<SpamapS> Well I think I'll step back from this because I haven't done the quickly tutorial, nor do I have time to unfortunately. :-/
<aruna> thank you very much for trying to help though...
<ebroder> aruna: This channel is more for development of Ubuntu than development of apps on Ubuntu. I don't know where it is, but I'd guess there's a better channel to get quickly help. (There isn't a #quickly, is there?)
<Laney> #ubuntu-app-devel I think
<aruna> ummm... yes your right I was there just now but seems very silent
<ebroder> aruna: That unfortunately doesn't really change that it's a better place to ask quickly questions
<aruna> thank'x will try there once more and apologies if I was in the wrong topic
<SpamapS> oh weird.. postgresql-8.4 actually *is* patched to allow initdb to run as root
<SpamapS> bah.. only in the test build
#ubuntu-devel 2010-08-10
<wgrant> [A10
<SpamapS> hrm, fakeroot needs a "--deactivate" mode for bits of a package build where it breaks stuf
<ebroder> fakeroot breaks stuff?
<ebroder> Err, you know, besides the obvious, I guess :-P
<ebroder> I've never seen it break a package build, though
<SpamapS> It makes it very difficult to run things like automated tests as a non-root user.
<SpamapS> have to unset LD_PRELOAD ..
<ebroder> Why aren't you running them in the build stage?
<SpamapS> I am
<ebroder> The build stage isn't run under fakeroot, only the binary stage is
<SpamapS> Not with pbuilder and debuild
<ebroder> Uh, definitely with debuild
<SpamapS> actually I should say I'm only testing w/ bzr-buildpackage
<SpamapS> which runs debuild
<ebroder> It does `debian/rules build`, then `fakeroot debian/rules binary`
<SpamapS> or, I think it runs debuild
<SpamapS> yeah, it runs debuild
<TheMuso> SpamapS: Use sbuild, which doesn't use fakeroot for the build stage.
<ebroder> Uh, guys, unless something's changed in Maverick debuild *definitely* doesn't use fakeroot for the build stage
<Laney> it shouldn't do
<Laney> per debian policy, builds must not require root
<ebroder> Laney: Right, that's why we have fakeroot, but I'm saying that even fakeroot doesn't get used for the *build* stage, just the *binary* stage
<SpamapS> I'm aware of the policy, but what there is no plicy on, is whether you can drop root privileges and how to do it.
<Laney> no, if your build requires fakeroot then it's broken
<Laney> it's quite deliberate: " 5. It calls debian/rules build followed by fakeroot debian/rules binary-target (unless a source-only build has been requested with -S)"
<wgrant> And if your build requires an absence of fakeroot, it's also probably broken.
<Laney> yes
<ebroder> SpamapS: Can you post a build log somewhere?
<ebroder> SpamapS: I stand by my insistance that if you run your tests during the *build* (not *binary*) stage, you should be running unprivileged
<SpamapS> http://paste.ubuntu.com/475671/
<SpamapS> Thats the shell code I've used that always ends up with a non-root user, but it seems pretty *lame*
<SpamapS> ebroder: sure..
<ion> Not commenting on the rest of it, but $0 $* should be replaced with "$0" "$@"
<SpamapS> ion: I always confused that part of shell scripting. Can you ellaborate why?
<ion> Say, $2 is "foo bar". $2 without quotes, as well as $*, would expand it to foo bar which means the two parameters "foo" "bar". "$2" would work, and "$@" has a special meaning of expanding to "$1" "$2" "$3" etc. (up to the number of arguments).
<SpamapS> cool thanks. :)
<SpamapS> Ok I have to run, if you guys want to critique the branch, lp:~clint-fewbar/ubuntu/maverick/libdbi-drivers/merge-upstream-release-0.8.3-1
<SpamapS> the tests are run at the end of the build: step
<SpamapS> and in a few minutes, there should be a build log here https://launchpad.net/~clint-fewbar/+archive/fixes/+build/1911663
<ebroder> No, you've got your dependencies backwards
<ebroder> *install* is the step that depends on test
<ebroder> So test will get run when install gets run when binary-{indep,arch} gets run under fakeroot
<SpamapS> Oh I just put them in as part of the build step
<ion> spamaps: sh -c 'foo() { printf "%s, " $*; printf "\n"; printf "%s, " "$@"; printf "\n"; }; foo bar "value with spaces" "/bin/l[ns]"'
<ebroder> SpamapS: You probably want line 38 to be "test: build-stamp" and line 30 to be "build: build-stamp test"
<SpamapS> well I'll be damned. ;)
<ebroder> All that "test: build" says is that build has to be done before test. It doesn't say anything about when test happens
<SpamapS> heh, for some reason I thought I had just thrown it in at the end of build:
<SpamapS> ebroder: sweeeet it works without the fakeroot hack
<ebroder> Also, you probably want a test-stamp target that actually touches a test-stamp file or something like that
<SpamapS> I was thinking of throwing all the test output into a test.log
<ebroder> (Otherwise if you depend on test in the install target, it can't tell that test has already been run because the test target doesn't output anything)
<SpamapS> and putting that in the doc dir
<SpamapS> ebroder: thanks for the close look... I think it works now...
 * SpamapS waits for starbucks' slow connection to push so he can hit the road
<stanley_robertso> hi all
<hallyn> I'm trying to follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for bug 595438, but when i hit 'nominate for release' all i see for options is 'Trunk'
<ubottu> Launchpad bug 595438 in KVM "KVM segmentation fault, using SCSI+writeback and linux 2.4 guest" [Undecided,Confirmed] https://launchpad.net/bugs/595438
<hallyn> is this a consequence of the freeze?
<hallyn> or am i doing somethign stupid?
<ebroder> hallyn: That bug is filed against upstream QEMU/KVM/qemu-kvm, not Ubuntu
<micahg> hallyn: no, you have to be on the ubuntu task to nominate
<micahg> and there isn't one
<hallyn> oh, so i should hit 'also affects distribution'?
<ebroder> hallyn: Correct
<hallyn> cool, thanks!
<ebroder> Hmm...any ~ubuntu-sponsors admins around who could add me?
<pitti> Good morning
<dholbach> good morning
<ion> rning
<El_Presidente> i want to trace a bug that is maybe in the lucid kernel but not in the karmic, is there a way to do a bisect?
<diwic> El_Presidente, you can also try a mainline kernel
<diwic> El_Presidente, I'll answer in bug #572146
<ubottu> Launchpad bug 572146 in alsa-driver (Ubuntu) "crackling sound from microphone with 2.6.32-21 kernel" [Undecided,Incomplete] https://launchpad.net/bugs/572146
<El_Presidente> ;)
<El_Presidente> ok
<diwic> El_Presidente, you've got an answer, thanks for helping out and your willingness to spend time on resolving this issue
<El_Presidente> diwic, i already tried a mainline kernel a month ago or so, now i remember the link
<El_Presidente> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/
<El_Presidente> but same error
<diwic> El_Presidente, right. Happy bisecting then :-)
<El_Presidente> well my problem is where is the "good" one
<diwic> El_Presidente, it should be the commit with the 2.6.31 tag
<El_Presidente> i mean where shall i set the git bisect good
<El_Presidente> ah ok
<El_Presidente> i downloaded the git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git there is also a 2.6.31 in?
<diwic> El_Presidente, hmm, I don't know, I'm suggesting you do the bisecting on the mainline/upstream kernel
<El_Presidente> ok
<diwic> El_Presidente, it's easy to find out though, just run "git tag"
<El_Presidente> ty
<smb> pitti, Hi just wanted to let you know (probably the obvious as you might have already seen) that we uploaded an update to Lucid kernel which should get accepted into proposed as soon as you can do, given the pending 10.04.1
<diwic> El_Presidente, so it has the v2.6.31.6 tag which should be okay as "good"
<diwic> El_Presidente, and the v.2.6.32 as "bad"
<diwic> or something
<El_Presidente> kk
<pitti> smb: right, thanks; I'll go through the SRU queue as soon as we have good lucid.1 images
<smb> pitti, Ok. Thanks a lot
<mvo> wgrant: hey! I vaguely remember you had some interesst in providing changelogs for PPAs so that u-m can display them. is my memory correct?
<cnd> dholbach, do you know if a per-package uploader automatically becomes an ubuntu member?
<cnd> or does one have to go through the ubuntu membership process as well/
<cnd> ?
<tumbleweed> cnd: automatic
<tumbleweed> cnd: https://wiki.ubuntu.com/UbuntuDevelopers
<cnd> tumbleweed, ahh, thanks
<cnd> now, how do I get the membership privileges that I should have as a ppu :)?
<cnd> is it just a matter of getting onto the right teams in launchpad
<Laney> you need to be in ~ubuntu-dev
<apw> cnd, you probabally need to approach whoever implemented your addition as a PPU and ask them about it
<apw> they likely missed a step
<LucidFox> https://edge.launchpad.net/ubuntu/+source/canonical-census <-- erm, what is this?
<LucidFox> Just found it on Slashdot
<mr_pouit> it sends a ping to canonical apparently
<LucidFox> pitti, is it going to be used on some kind of OEM installations?
<mr_pouit> it's for oem systems
<LucidFox> seeing how it's in partner, I presume it's not in the default install
<mr_pouit> (juts looking at the package description)
<LucidFox> I think it's better to send Slashdot a message clarifying the use of the package, otherwise people are going to think that Canonical is playing Big Brother with Ubuntu users without their consent
<LucidFox> the wording of the article, in particular, is making it sound like it's going to be used by default
<pitti> LucidFox: yes, it's only in the partner repo, and it doesn't do anything for normal Ubuntnu installs right now
<pitti> LucidFox: just sent a comment to the slashdot article
<LucidFox> "right now"? That doesn't sound assuring
<pitti> LucidFox: well, who knows; this hasn't been discussed with the community at all yet
<pitti> at some point we as a community might want it, too
<pitti> but so far it's only for OEM installations as an opt-in
<gord> for what its worth, the original article mentions that its for oem installs several times, its just that the slashdot article chooses to.. omit that from the summery it has
<LucidFox> gord> For drama, presumably
<pitti> also, it doesn't send all the DMI information
<LucidFox> What I find amusing is how they apparently analyzed network traffic generated by the package instead of looking at its source code to see what it does
<pitti> "Previously there haven't been such Ubuntu tracking measures attempted by Canonical"
<pitti> well
<pitti> nothing that woudl be a valid metric anyway :)
<pitti> you can always do wild guesses based on how many CDs you ship, how many machines fetch apt indexes, etc., but none of those are reliable
<gord> i like picking numbers out of a hat myself, seems as valid as the rest
<pitti> LucidFox: right, because it's such a complicated shell script :)
<bilalakhtar> good morning pitti
<pitti> hello bilalakhtar, how are you?
<pitti> ..
<lool> mvo: Hey, wanted to check whether you saw https://bugs.launchpad.net/ubuntu/+source/apt/+bug/613211 it seems a recent regression
<ubottu> Launchpad bug 613211 in apt (Ubuntu) "apt-ftparchive fails to rename Packages.gz files" [Undecided,New]
<bdrung> psurbhi: ping
<mvo> lool: checking
<mvo> lool: that should be fixed soon
<mvo> lool: juliank commited a fix to bzr (thanks!)
<lool> mvo: awesome, thankjs
<Keybuk> ah, MeegoCon ;-)
<sladen> Pidgin Engrish is da futer
<pitti> hello Keybuk, how are you?
<Keybuk> pitti: I'm a whole boat of meh - how are you?
 * pitti ponders what that means
<pitti> Keybuk: quite fine, wrestling with xfce again :)
<Keybuk> ah, xfce :p
<pitti> Keybuk: btw, are there any news on udev? or is the latest version still unbootable?
<pitti> Keybuk: in the latter case, would you mind updating the upstream bzr import? I might do some testing tomorrow in the train
<Keybuk> I've been effectively away for a while at conferences and such
<Keybuk> so haven't had a chance to look into it
 * dholbach hugs mvo
<mvo> :)
<Keybuk> The following packages will be REMOVED:
<Keybuk>   libsyncdaemon-1.0-1* libubuntuone-1.0-1* python-ubuntuone*
<Keybuk>   rhythmbox-ubuntuone-music-store* ubuntuone-client* ubuntuone-client-gnome*
<Keybuk> muahahah! BE GONE!
<ion> :-)
<Keybuk> my machine kept blacking out
<Keybuk> guess what was doing it ;-)
<pitti> Keybuk: you accidentally clicked the ridiculously large "sync me" button in nautilus in your video directory? :-)
<Keybuk> pitti: no, I think I _started_ nautilus once
<Keybuk> which apparently means I want ubuntuone running at all times, and randomly going into fits
<ogra> pitti, nah, he clicked the hidded "buy all" button in the music store ;)
<ogra> RB is still busy sending his credit card details ;)
<ogra> *hidden
<quadrispro> ehya guys! any archive admin around?
<kklimonda> pitti: is canonical-census planned for all new Ubuntu installations or is it stricte OEM stuff?
<pitti> quadrispro: might be better to just state what you need :)
<pitti> kklimonda: it hasn't been discussed with the community at all; it's not on the plan for maverick
<pitti> kklimonda: for now this is an opt-in for OEM installs
<quadrispro> pitti, right, I push'd font-manager to maverick's NEW, it's a sync from Debian unstable
<nxvl> cjwatson: ping
<nxvl> cjwatson: i didn't noticed and just got expired from MOTU, as in today
<pitti> quadrispro: the package was synced by an archive admin?
<nxvl> cjwatson: can you please re-activate me or do i need to present myself again
<quadrispro> pitti, no, it wasn't, I uploaded it by hand (syncpackage + dput)
<pitti> nxvl: (CC: cjwatson): I put you back into MOTU
<quadrispro> ScottK, I'm here, getting some help from pitti :)
<quadrispro> thank you anyway
<ScottK> OK.
<pitti> ok, it's in Debian now, accepted
<nxvl> pitti: thanks
<quadrispro> pitti, many thanks!
<mdz> pitti: I declined the calendar invite for TB; I guess nobody checks that :-)
<pitti> mdz: too much high-tech
<pitti> :)
<asac> jdong: ping
<asac> jdong: can you please add a sticky note to the ubuntuzilla forums that says in big bold letters that "ubuntuzilla is officially discouraged by ubuntu devs" ?
<asac> chrisccoulson: ^^
<asac> jdong: i sent this guy a few mails to better work with us a few years back and never go anything back and now i found that he refers to our forums as his official support  forum, which explains why other ubuntu users always think thats a good way to go
<asac> jdong: or can you sent him a mail to use the sourceforge forums as his "official" support forums maybe?
<asac> thanks!
<ricotz> stgraber, hello
<superm1> pitti, slangasek: still seeing constant hash sum mismatches on daily isos for mythbuntu now that the livefs problem is fixed.  could you help move it to a different time, maybe a few minutes off to stop conflicting with the job causing that?  http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/maverick/daily-live-20100810.log
<superm1> cjwatson, i was just looking at the daily for une and didn't see any support for booting in EFI, are you going to be tracking this still for after FF instead?  also, what about worries for inclusion of grub-efi and efibootmgr in the appropriate places on the disk?
<SpamapS> mathiaz_: hey, have you had a chance to read the rest of the rubygems proposal?
<mathiaz> james_w: hi!
<james_w> hi mathiaz
<mathiaz> james_w: could you kick off an import of openldap in lucid-updates?
<mathiaz> james_w: a security update has been published and I need to update the SRU
<james_w> mathiaz: started, but no guarantee it will work
<mathiaz> james_w: great - thanks for trying out!
<kirkland> geser: howdy :-)
<geser> Hi kirkland
<kirkland> geser: would you mind reviewing https://code.edge.launchpad.net/~kirkland/ubuntu-dev-tools/612267/+merge/32216 ?
<kirkland> geser: looks like you're the gatekeeper of ubuntu-dev-tools :-)
<tumbleweed> kirkland: all ubuntu devs can commit to it. There's also python's errno library, btw
<kirkland> tumbleweed: understood
<tumbleweed> kirkland: although I assume you knew the first bit :)
<kirkland> tumbleweed: aware of both
<tumbleweed> heh
<geser> kirkland: "./errno: 21: gcc: not found" and then it hangs (I guess grep is waiting on input)
<kirkland> tumbleweed: the python library doesn't quite get us all 3 (error name, error number, and error description), though, as far as I'm aware
<kirkland> geser: oh, hmm, i figured gcc would be pulled by ubuntu-dev-tools
<tumbleweed> yeah you can only get the descriptions via the os library
<geser> let me check
<kirkland> tumbleweed: right;  i just tried something in C as well -- same limitation
<geser> kirkland: hmm, u-d-t depends on dpkg-dev which recommends build-essential which depends on gcc. I guess that is good enough.
<kirkland> geser: alternatively, headers="/usr/include/asm-generic/errno*.h"
<kirkland> geser: could do that if gcc is not found
<kirkland> geser: the gcc hack from kees is "smarter" though
<geser> I guess the chances to have the header file but not gcc are small
<Laney> cjwatson: Shouldn't ubuntu-cli-mono-dev be a member of ubuntu-dev?
<Laney> (or other DMB person I guess)
<kirkland> geser: i just pushed r698, which fails over to errno*h
<Laney> is it via DMB?
<pitti> superm1: I moved it from 10:19 to 10:29 now; let me know if that helps
<kirkland> geser: would like to do the commit/push/upload, or may I?
<geser> kirkland: when I try the examples, I get the whole header file? I'm doing something wrong?
<geser> kirkland: and you can commit/push/merge
<kirkland> geser: let me check
<kirkland> geser: fixed in r699 (copy-n-paste fail)
<geser> kirkland: and please add the the script to the list of those with GPL3+ at the end of debian/copyright
<kirkland> geser: done
<pitti> mathiaz: can you please merge the openldap SRU with -security and reupload? I'll fast-process it
<james_w> mathiaz: done
<mathiaz> pitti: working on it right now
<pitti> mathiaz: cheers
<mathiaz> pitti: I'm building the source package
<mathiaz> pitti: I'm building with nocheck to avoid running the test suite (it takes > 2 hours)
<mathiaz> pitti: once I've tested in builds correctly I'll uploaded to -proposed
<pitti> mathiaz: ok, should be fine; the patch was already tested, after all, and it's just changing maintainer scripts, right?
<pitti> mathiaz: thanks; please ping me after you uploaded, then I'll review/accept right away
<mathiaz> pitti: and I'll verify the package once it's been accepted and built and available in -proposed
<pitti> cheers
<mathiaz> pitti: correct
<mathiaz> pitti: same patch as the one already accepted in -proposed last week
<mathiaz> pitti: and that I verified yesterday
<superm1> thanks pitti, that's 10:29 GMT right?
<pitti> superm1: British time, i. e. BST right now (GMT+1)
<superm1> okay, thanks
<mathiaz> pitti: openldap_2.4.21-0ubuntu5.3_source.changes uploaded to LP
<pitti> \o/
<pitti> ScottK: any chance you can test bug 569879?
<ubottu> Launchpad bug 569879 in xorg-server (Ubuntu Lucid) "Non-admin user logout fails on Lucid" [High,Fix committed] https://launchpad.net/bugs/569879
<pitti> mathiaz: accepted, should build soon (just checked the queues)
<mathiaz> pitti: great thanks!
<mathiaz> pitti: it should take a couple of hours to build
<Riddell> ScottK: python2.7 in main?
<superm1> Riddell, ScottK is python 2.7 going to be by default superceding 2.6 for maverick?  i know certainly there are some problems with python-mysqldb and 2.7
<pitti> hm, two days before FF?
<Riddell> superm1: I'm pretty sure not
<superm1> phew :)
<pitti> holy sh..; I mistyped (autofingers) and looked at https://code.edge.launchpad.net/ubuntu
<pitti> "1  â 100  of 197216 results"
<pitti> now I know why launchpadlibrarian piles up TB after TB :)
<slangasek> pitti: are these newly-accepted lucid SRUs all orthogonal to 10.04.1 (because they're not seeded)?
<ScottK> pitti: I've tested it on the one machine I still have access to that had the problem before I uploaded it.  I believe it to be safe.
<ScottK> Riddell: yes.
<ScottK> superm1: It will be an additional supported version, not default.
<Riddell> ScottK: why?  don't we only want one version in main at any time?
<ScottK> Riddell: It'll be needed in build depends.
<ScottK> We only want one runtime on the CDs, but we need all supported versions in Main.
<ScottK> Riddell: Same (ish) reason python3.1 is in Main.
<Riddell> mm, right
<ScottK> barry has promised to make it wonderful, so I'm not worried.
<Riddell> he's good like that
<Riddell> ScottK: well I think I put them into universe and it won't let me change it just now, remind me to look at it again in a bit if I don't remember
<ScottK> I'll be offline most of the rest of the day, so probably tomorrow.
<pitti> slangasek: right; well, openldap is, but that's on the .1 list
<pitti> slangasek: but we already had that in v-done, but a security update came in between; so we can waive the 7 days there
<pitti> slangasek: I cleaned up the other bugs, https://edge.launchpad.net/ubuntu/+milestone/ubuntu-10.04.1 looks quite reasonable now
<pitti> slangasek: seb128 agreed that he can test bug 553759 (affects French)
<ubottu> Launchpad bug 553759 in gnome-keyring (Ubuntu Lucid) "ubuntuone-preferences crashed with NoSuchKeyringError in __init__()" [High,Fix committed] https://launchpad.net/bugs/553759
<pitti> ScottK: ok, thanks; does that machine have the actual lucid-proposed package, or a local build?
<slangasek> pitti: indeed - thanks for that!
<hrw> slangasek: hi
<slangasek> hrw: hi there
<hrw> slangasek: how things go?
<slangasek> hrw: ok :)
<pitti> slangasek: I'll be on vac tomorrow, so perhaps you could move openldap to -updates once mathiaz finishes testing (if it's urgent; otherwise I'll do it on Thu)
<slangasek> pitti: yes, I'll have a look at it
 * hrw loves 1000 chars long gcc invocations...
<hrw> slangasek: I be offline on friday - us visa meeting in embassy
<slangasek> hrw: ok
<hrw> slangasek: this week my binutils/eglibc/gcc changes may finally be merged - I have a discuss/review of them tomorrow with doko
<hrw> slangasek: so at least debian/sid will have nearly everything in place (as debian/linux kernel package needs 2 patches from ubuntu one - but thats beyond my blueprint for now)
<slangasek> hrw: have you had a chance to test whether my multiarch patches to gcc merge cleanly with yours?
<hrw> sorry, forgot about those
<free> pitti: hey, since the 10.04.1 release has apparently been delayed, smoser and I were wondering if it would be possible to accept landscape-client in -proposed as freeze exception or something, as otherwise things would delay even further on our side
<hrw> slangasek: today I had to rewrite my patchset due to recent changes
<mathiaz> Riddell: hi
<mathiaz> Riddell: could you promote libdbi to main?
<mathiaz> Riddell: see bug 608552
<ubottu> Launchpad bug 608552 in libdbi (Ubuntu) "[MIR] libdbi" [Undecided,In progress] https://launchpad.net/bugs/608552
<dupondje> https://bugs.launchpad.net/ubuntu/+source/libutempter/+bug/589103
<ubottu> Launchpad bug 589103 in libutempter (Ubuntu) "[MIR] libutempter" [Undecided,Fix committed]
<dupondje> when is this going to change ?!
<Riddell> ScottK: python2.7 binaries in main now
<Riddell> dupondje: promoted, next time subscribe ubuntu-archive
<micahg> Riddell: MIR approver apparently forgot
<SpamapS> https://merges.ubuntu.com/main.html
<SpamapS> something terribly wrong with that server right now. :(
<SpamapS> Riddell: is that process documented somewhere btw?
<SpamapS> Riddell: the MIR process I follow just says "its your responsibility to add the package to a seed or make it a dependency of a package already in main"
<Riddell> SpamapS: yes that would be another way of doing it, then hoping an archive admin is looking at the component mismatches output (which I usually don't)
<SpamapS> https://wiki.ubuntu.com/MainInclusionProcess
<SpamapS> I always thought it felt a bit.. magical
<SpamapS> like.. and then the archive administrator fairy comes in the middle of the night, takes your package, and leaves a shiny quarter!
<lifeless> hehe
<dupondje> thx Riddell
<SpamapS> http://package-import.ubuntu.com/status/moin.html#2010-02-22 01:26:04.345632
<SpamapS> Anybody have any ideas what would cause those errors?
<dupondje> I tought the MIR approver did the correct work :) seems he was a bit asleep :p
<SpamapS> I'm trying to get moin merged.. I think they changed the source format of the package
<Riddell> SpamapS: other way round works better, you have to pay us a quarter :)
<ebroder> Riddell: Wait, we can get packages in main for a quarter?
<Riddell> only with a valid approved MIR
<Riddell> bribing the MIR people probably costs a lot more
<mathiaz> RoAkSoAx: hi!
<mathiaz> RoAkSoAx: what's the state of drbd in maverick?
<geser> Riddell: shouldn't be a problem with those million $ from africa offered in emails :)
<SpamapS> james_w: are you around by chance? I'm having some issues merging moin ... http://package-import.ubuntu.com/status/moin.html#2010-02-22 01:26:04.345632
<SpamapS> mathiaz: is there any way to manually merge using the UDD methods if the debian import part is broken?
<SpamapS> mathiaz: I tried branching the debian portion, importing the debian package manually, and then using merge-package, but I get this:
<SpamapS> clint@ubuntu:~/pkg/moin/bzr/maverick$ bzr merge-package ../debian
<SpamapS> bzr: ERROR: No such tag: upstream-1.9.3
<SpamapS> so I assume there's some more magic that the importer does. :-P
<mathiaz> SpamapS: hm - right
<mathiaz> SpamapS: I guess that what's missing here is merge-upstream
<SpamapS> mathiaz: ah, the importer actually treates the two differently? (that would be awesome btw ;)
<dupondje> grold1: you there ?
<grold1> yes
<dupondje> you can eventually make a new revision of xterm
<dupondje> without the libutempter change ... :)
<dupondje> its now in main ;)
<grold1> dupondje, sorry, don't understood about libutempter
<dupondje> its you that did the xterm merge :)
<grold1> yes
<dupondje> well there you have a delta that removes libutempter dependency right ?
<grold1> yes, becouse it was removed in previous ubuntu
<dupondje> you can leave that out now ... as libutempter is now in main, so no reason anymore for the delta
<grold1> ok
<grold1> thanks for the notice
<RoAkSoAx> mathiaz: I prepared a new upstream release (8.3.8) which ttx uploaded, right after I requested jjohansen to please enable the kernel module, since DRBD is now in mainline kernel
<RoAkSoAx> mathiaz: and as far as my tests go, it's working as it should. I'll likely to be preparing a backport for Lucid in the next few days
<mathiaz> RoAkSoAx: so the drbd8-source doesn't exist/is not needed anymore in maverick?
<RoAkSoAx> mathiaz: Nope not anymore. However I didn't drop the changes in the new package to be able to backport. I just commented them out!
#ubuntu-devel 2010-08-11
<ScottK> Riddell: Thanks.
<ScottK> I'll remember not to harass you about it tomorrow then.
<maco> Riddell: quarter? do you have quarters over there?
<Laney> a 20p and a 5p!
<Riddell> maco: that's the size my slice of cake needs to be :)
<maco> Riddell: ahhhh
<maco> Riddell: how many cm should the total cake be?
<maco> because a quarter of a cupcake and a quarter of a sheet cake are a bit different
<maco> hmm how many cmÂ³ i mean?
<Riddell> lots :)
<SpamapS> am I crazy or is bug 610975 just a simple noop rebuild?
<ubottu> Launchpad bug 610975 in pgadmin3 (Ubuntu Maverick) "Can not start pgadmin3" [High,Triaged] https://launchpad.net/bugs/610975
<RAOF> It does indeed look like a no-change rebuild.
<RAOF> Also, it looks like wxwidgets needs to be hit with the SONAME bat.
<SpamapS> indeed, there's a bug in the way wxwidgets does its own linking IIRC
<SpamapS> the debian bug that is linked to mentions it
<ScottK> WX doing insane things is not surprising.
<SpamapS> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540060#105
<ubottu> Debian bug 540060 in libwxgtk2.8-0 "error in pgadmin3" [Serious,Open]
<mfilipe> hi! where is the ubuntu reviewboard? I want suggest the ubuntu-10.10 uses v86d+uvesafb
<mfilipe> or... how do I suggest change in ubuntu?
<dholbach> good morning
 * dholbach hugs warp10 back
<dholbach> warp10: happy birthday :)
 * warp10 hugs dholbach
<warp10> dholbach: Thank you Daniel! :D
<dholbach> :-D
 * DktrKranz tells happy bd to warp10, let's hope he reply back tomorrow for DktrKranz's one :)
<warp10> DktrKranz: Thank you! BTW: I will definitely reply: Facebook reminder is my friend :P
<dholbach> pitti, bdrung, mvo, seb128, tjaalton, Riddell, didrocks: thanks a lot for all the sponsoring you did
<bdrung> dholbach: yw
<didrocks> dholbach: yw :)
<mvo> dholbach: cheers
<dholbach> tumbleweed: ^ you too
<bdrung> dholbach: you sponsored quite a lot, too
<bdrung> dholbach: did you played with syncpackage?
<bdrung> s/did/have/
<dholbach> bdrung: there's others who thanked me for it already, so I didn't need to thank myself ;-)
<dholbach> bdrung: no, didn't take a look at it yet
<tumbleweed> dholbach: thanks
<seb128> dholbach, you're welcome
<didrocks> bdrung: syncpackage working well here (played with it three/four times, in the week-end, mostly)
<bdrung> didrocks: great to hear
<baptistemm> hello, why http://packages.ubuntu.com/search?searchon=sourcenames&keywords=bluez doesn't list maverick ?
<baptistemm> hmmm -> http://packages.ubuntu.com/maverick/
<geser> baptistemm: it's still waiting on a fix
<dholbach> https://launchpad.net/ubuntu/+source/bluez should have it though
<dholbach> baptistemm: can you update that merge proposal again? there's a merge conflict
<ara> pitti, morning
<bdrung> dholbach: can you have a look at bug #378240?
<ubottu> Launchpad bug 378240 in xen-3.3 (Ubuntu) "Please merge xen-3.4 (3.4.0-2) from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/378240
<dholbach> bdrung: I'd prefer if I didn't have to
<dholbach> bdrung: can somebody of the server team help out?
<bdrung> dholbach: whom of the server team could i ask?
<dholbach> I dunno, somebody in #ubuntu-server maybe
<dholbach> I have no idea about xen, how to test it, etc.
<dholbach> and need to get some other stuff sorted out :)
 * ajmitch would suggest zul, perhaps
<ajmitch> or he'd at least know who to talk to
<bdrung> he's not online
<bdrung> tumbleweed: ack-sync avoids duplicate work. i saw that you took the bugs that i would have taken. :)
<psurbhi> hie! On choosing encrypted disk and lvm during Lucid installation, ext2 is chosen by default for /boot. Is there a particular reason for doing that?
<bdrung> tumbleweed: you didn't reload bug #616190
<ubottu> Launchpad bug 616190 in plexus-component-metadata (Ubuntu) "Please sync plexus-component-metadata 1.0~beta3.0.7-4 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/616190
<tumbleweed> bdrung: it was already in my ack-sync queue
<tumbleweed> I think mine took it when you'd already unassigned yourself
<bdrung> yes
<bdrung> tumbleweed: maybe ack-sync should check if ubuntu-sponsors is subscribed
<tumbleweed> how about setting fix-committed at upload?
<tumbleweed> (before unsubscribing)
<tumbleweed> of course, there's another race there, because if the upload is processed before the fix-committed has set, we'll go confirmed -> released -> committed
<bdrung> tumbleweed: yes, we have to do the upload as last step
<tumbleweed> committed, unassign, upload?
<bdrung> yes
<bdrung> and fixing this bug before: task = list(bug.bug_tasks)[0]
<bdrung> it's not always the first
<hyperair> kirkland: ping.
<hyperair> kirkland: if i stuff ecryptfs-add-passphrase into initramfs, what else does it need?
<baptistemm> dholbach: I doubt I will, I will suppress the merge request
<dholbach> baptistemm: ok :/
<Riddell> ev: ping
<sebner> RAOF: hola! Do you happen to know if the nvidia binary 3D driver is new xserver ready? :)
<RAOF> sebner: Yes - it is, as long as you add IgnoreABI to xorg.conf.  It shouldn't be installable, but it is because of a packaging bug.
<sebner> RAOF: lol, thx for the info :) I'm already using maverick, was just wondering if I can install the xserver upgrades :)
<RAOF> You can, and it'll break nvidia unless you add IgnoreABI.
<sebner> RAOF: fine, good to know. thanks again!
<bdrung> Riddell: can you have a look at bug #607483?
<ubottu> Launchpad bug 607483 in packagekit (Ubuntu) "[debdiff] packagekit_0.6.5-0ubuntu2" [Undecided,Fix committed] https://launchpad.net/bugs/607483
<Riddell> bdrung: have you checked what is still relevant in the current packagekit?
<Riddell> should the "Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" error in dpkg-source be changes to allow linaro as well?
<Freeaqingme> Hi folks. Kde 4.5 has been released today (or something real close to that), what would be a realistic eta to see that in ubuntu's repos?
<Riddell> Freeaqingme: yesterday
<Freeaqingme> I meant the stable repo
<Riddell> see kubuntu.org
<Freeaqingme> hmm, tnx. Wasn't meant to bother you for support though, sorry
<megabraker> hi everybody, i have downloaded ubuntu lynx 10,01 i tried so hard to boot the live CD , erors occur i have runned it from vmx it works as  dream ,i have really a bad connection and sufer from windows XD , is there any tutorial describing how to ceate my one ubun lynx iso file or create live usb and thanks
<megabraker> *create
<megabraker> btw happy ramadam to erbody
<diwic> megabraker, please use #ubuntu for support
<megabraker> diwic i don think ubutnu would provide advenced live usb creation manual
<diwic> megabraker, the "#ubuntu" irc channel
<Riddell> seb128: is there some transition going on?  running ubiquity-gtk I get "RepositoryError: Failed to load typelib file '/usr/lib/girepository-1.0/GObject-2.0.typelib' for namespace 'GObject': Typelib version mismatch; expected 3, found 2
<seb128> urg
<seb128> Riddell, what version of gir1.0-glib-2.0 do you have?
<seb128> do you get the issue with other pygtk softwares?
<seb128> ie gdebi-gtk or update-manager
<Riddell> gir1.0-glib-2.0: Installed: 0.6.14-1ubuntu2 Candidate: 0.9.3-0ubuntu2
<mvo> Riddell: I had this as well, but upgrading cured it
<Riddell> yes upgrading gir1.0-glib-2.0 fixed it
<Riddell> guess something needs a tighter depend
<Riddell> thanks
<seb128> hum
<seb128> is ubiquity using gobject introspection?
<seb128> Riddell, I guess python-gobject should have an updated depends
<tkamppeter> Does the build process in the buildds run as root or as a normal user?
<sistpoty|work> tkamppeter: guessing from a build log on amd64 as a normal user + fakeroot: /usr/bin/fakeroot debian/rules clean
<tkamppeter> How can I make pbuilder run the build process as non-root?
<geser> doesn't pbuilder do it by default?
<sistpoty|work> If I recall correctly: yes
<tkamppeter> I have done a build and inside pbuiler python ignore PYTHONPATH, this is a behavior of python which it shows when one runs it as root.
<tkamppeter> What I want to do is to run a Python program with some modules during a package build, but I do not want to install the program, to avoid creating a new package in main one day before FF.
<sistpoty|work> hm... arch:all package then? I think there's a switch for pbuilder to call the -indep targets, maybe that's the problem? (geser: do you recall that switch)?
<sebner> huhu sistpoty|work :)
<tkamppeter> Yes, the binary package for which I run Python is arch:all, so the Python call is in the -indep target. The package is HPLIP.
<sistpoty|work> hi sebner
<geser> --binary-arch IIRC (it's mentioned in the pbuilder manpage)
<tkamppeter> sistpoty|work, geser, which --binary-arch seeting do I have to use with pbuilder?
<sistpoty|work> tkamppeter: actually I think it's not --binary-arch, but should be --debbuildopts -A to build (only) the arch:all package
<sistpoty|work> (though I thougth there was a specific switch that does the same... *shrug*)
<sistpoty|work> tkamppeter_: read the last statement?
<dupondje> bdrung: https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/616100 quite wrong patch :(
<ubottu> Launchpad bug 616100 in xterm (Ubuntu) "enable libutempter-dev in debian/control file" [Undecided,Fix released]
<superm1> pitti, unfortunately same hash sum mismatch from the job running 10 min later :( http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/maverick/daily-live-20100811.log
<tkamppeter> sistpoty|work, yes, I am trying now.
<sistpoty|work> ah, k :)
<tkamppeter> sistpoty|work, with
<tkamppeter> sudo pbuilder build ../build-area/hplip_3.10.6-1ubuntu2.dsc --debbuildopts -A
<tkamppeter> the PYTHONPATH still gets ignored.
<sistpoty|work> tkamppeter: hm... in which rule do you use it? in clean/install or during build-*? (as afaict bulid will be called as a normal user, whereas install and clean has to be called as root or using fakeroot)
<tkamppeter> sistpoty|work, in install-indep
<sistpoty|work> tkamppeter: ah, that'll still be called with root (or fakeroot)...
<tkamppeter> sistpoty|work, seems that already fakeroot triggers the security functionality of Python.
<sistpoty|work> most probably, if python uses the c library and checks for the uid, then it won't see a difference between fakeroot and root
<tkamppeter> sistpoty|work, but
<tkamppeter> PYTHONPATH=. fakeroot python bin/pyppd /usr/share/ppd/splix/
<tkamppeter> directly entered on the command line works.
<tkamppeter> sistpoty|work, now I have simply uploaded the HPLIP package to see whether the buildds behaves different, but it also does not allow PYTHONPATH=. in that stage.
<tkamppeter> sistpoty|work, is there a possibility to override this in Python?
<sistpoty|work> tkamppeter: hm... no idea actually, I'm not a python expert
<sistpoty|work> tkamppeter: maybe it's a different problem? PYTHONPATH=. bin/pyppd doesn't seem to work for me here (though I'm on debian/stable here at work)
<sistpoty|work> tkamppeter: do you have got a __init__.py in the directory that contains the module files? even an empty one seems to suffice for me that PYTHONPATH works
 * ogra misses slangasek as release manager, isnt it FF tomorrow ? nobody sent a reminder mail to u-d-announce
<nigelb> ogra: heh :)
<tkamppeter> sistpoty|work, there is an __init__.py.
<tkamppeter> sistpoty|work, strange is also that the same Python script works in the foomatic-db build, but that package is quilt-style.
<sistpoty|work> tkamppeter: hplip (3.10.6-1ubuntu2)? if I extract that, there's no __init__.py in debian/local/pyppd/pyppd
<dupondje> https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/616100 => added good patch :)
<ubottu> Launchpad bug 616100 in xterm (Ubuntu) "enable libutempter-dev in debian/control file" [Undecided,New]
<sistpoty|work> tkamppeter: aha, empty files aren't part of the unified diff, so __init__.py probably got removed since it was empty... that also explains why it works for a quilt-style package
 * dupondje slaps grold  :)
<tkamppeter> sistpoty|work, great, currently I am trying with an alternative command line:
<tkamppeter> python -c 'import sys; sys.path[0] = "'`pwd`'"; from pyppd import runner; runner.run()' $(CURDIR)/debian/hplip-data/usr/share/ppd/hplip
<tkamppeter> sistpoty|work, so the simplest fix had been a "touch pyppd/__init__.py" before the Python call.
<sistpoty|work> tkamppeter: yes, or just add a newline to __init__.py so that it'll be part of the .diff.gz
<grold> dupondje, I did't saw that you did the patch :) - almost a the same time
<sistpoty|work> (or other whitespace, or change debian source format to 3.0 version that can copy with empty files)
<dupondje> well the slap was for the bad fix :P
<grold> is's the case for using "assigned to" function :)
<grold> yes, my mistake
<dupondje> as long it gets fixed :)
<tkamppeter> sistpoty|work, alternative command line does not work, doing fill with whitespace approach.
<tkamppeter> sistpoty|work, using the touch approach, to keep the pyppd stuff identical to upstream.
<tkamppeter> sistpoty|work, thanks for the help, now the PPD compressor is working under pbuilder.
<tkamppeter> sistpoty|work, fixed HPLIP package is uploaded now.
<sistpoty|work> tkamppeter: yw :)
<didrocks> bzr-builddeb: " * Fixed a logic error that stops -r working in merge-upstream"
 * didrocks hugs james_w
<james_w> didrocks: it was a stupid issue, sorry
<james_w> didrocks: and it never worked :-)
<didrocks> james_w: no worry, having this fixed will make my life soooo easier :-)
<james_w> didrocks: I'll sync it today
 * didrocks removes his <foo>-release branch ;)
<didrocks> james_w: great! thanks
<SpamapS> james_w: did you see my question about package-import ?
<james_w> SpamapS: I did, and it's a bug lower in the stack than I was willing to deal with last night
<james_w> SpamapS: if it's blocking you then I can dig around
<SpamapS> james_w: I'm concerned that we won't be able to ship moin-1.9.3 in maverick, which has some XSS bugfixes
<SpamapS> james_w: I can certainly hand-merge .. but it seems the MoM is also broken for moin. :-/
<bilalakhtar> Hey, M-O-M is down!
<SpamapS> james_w: james_w that said, its not crazy urgent.. just seems like a lot of packages are stuck and unmergeable by old or new methods. :-/
<ScottK> SpamapS: They can be merged by hand.  This is painful, but may be the best move for something that needs to get in before feature freeze.
<SpamapS> ScottK: yeah thats what I'm doing. The actual delta we're retaining is really small, so its not that hard actually.
<ScottK> debian/changelog is usually the most painful.
<SpamapS> ScottK: its like taking the bus because your lamborghini is in the shop tho. :-/
<micahg> lamont: you rock :)
<lamont> micahg: well, there was this deadline, you seee...
<micahg> lamont: heh, I'm trying to do the same for a few things :)
 * lamont wanders off for a while
<[reed]> how does one request that a package get rebuilt to fix dependency problems?
<lamont> [reed]: one uploads a new version that differs from the previous only in that the version has been bumped in debian/changelog
<lamont> [reed]: if it's synced from debian, then 1.2-3 would become 1.2-3build1
 * lamont wanders
<[reed]> hmm
<[reed]> wonder if there are directions for this somewhere ;)
<micahg> [reed]: man dch?
<[reed]> micahg: I meant the whole process ;)
<micahg> :)
<[reed]> never uploaded a new package before
<asac> [reed]: did the package fail before?
<asac> if so you need to ask someone to retry/give back who has the powers
<[reed]> asac: it's libetpan-dev
<[reed]> trying to install it complains about libdb4.7-dev
<[reed]> because that's deprecated... it should be using libdb4.8-dev
<[reed]> however, it's not hardcoded... rebuilding the package (which I've done locally) correctly adds libdb4.8-dev as a dependency
<[reed]> (rather than libdb4.7-dev)
<asac> [reed]: sure you mean -dev package? not the non-dev lib packages?
<asac> let me look ;)
<[reed]> asac: https://bugs.edge.launchpad.net/ubuntu/+source/libetpan/+bug/616474
<ubottu> Launchpad bug 616474 in libetpan (Ubuntu) "libetpan-dev depends on libdb4.7-dev while libdb4.8-dev is current recommended version" [Undecided,New]
<[reed]> that's the bug I filed
<asac> [reed]: yes, needs a build1
<[reed]> wanna walk me through that or point me to some guide that tells me how to do that? :)
<asac> [reed]: apt-get source libepan .... dch -i: here you replace the ubuntu1 with build1 in the top most line, then add a sane comment that contains "LP:BUGID" somehow to auto close the bug on upload
<asac> produce the new source pieces: debuild -S (if you have devscripts installed) ... and make a debdiff *.dsc (old and new .dsc) to get a patch to attach to bug
<asac> and ask for sponsor ship ;)
<asac> in the dch -i step remember to check that your email isnt too bad ;)
<[reed]> oke
<asac> you can set NAME and DEBEMAIL in env to change whatever it picks
<[reed]> yeah, pretty sure my env already has those set
<asac> right. then you just need dch -i which is in devscripts package too
<asac> [reed]: as comment you could use something along the line: "* fix LP:XXXXX - no change rebuild to pick up libdb4.8-dev in maverick"
<[reed]> asac: ok, attaching debdiff now
<[reed]> asac: attached
<[reed]> asac: want to sponsor me? :p
<bdrung> Riddell: no. you gave the last comment and according to your comment the bug could be closed. you should know best what you did.
<bdrung> dupondje: not my fault, it's dholbach's fault (because he sponsored it) ;)
<asac> [reed]: one mistake ... since you are on lucid dch -i generated "lucid" rather than maverick ;)
<asac> i will fix that
<[reed]> well, lucid needs to be fixed, too
<[reed]> :p
<asac> rsajdok: uploaded
<asac> [reed]:
<asac> [reed]: for lucid you need to make a SRU ;)
<[reed]> how do I do that?
<highvoltage> [reed]: https://wiki.ubuntu.com/StableReleaseUpdates
<[reed]> highvoltage: thanks
<asac> [reed]: complicated ... err ... easy. instead of build1 you use build0.10.4.1 ;) ... and instead of maverick lucid-proposed
<asac> then attach debdiff ... nominate bug for lucid
<[reed]> ok
<asac> whoever sponsors it should probably do the right subscription of teams etc.
<seb128> kees, there?
<kees> seb128: hi! (at linuxcon)
<seb128> kees, hey
<seb128> kees, when you give +1 on mir does that means it can be promoted or does it still need some other review?
<kees> seb128: means it can be promoted
<seb128> ok thanks
<kees> np
<seb128> kees, what about -1, what do we need to solve the issue?
<seb128> kees, our default photo mananager fail to build right now because your nacked bug #607757
<kees> seb128: usually I say, but it's not always a very specific thing to be fixed. which one in particular?
<ubottu> Launchpad bug 607757 in libraw (Ubuntu) "[MIR] libraw" [Wishlist,Incomplete] https://launchpad.net/bugs/607757
<seb128> kees, I'm not sure how to solve that
<kees> oh yeah, libraw looks to be _really_ poor code quality.
<seb128> I don't think we want to go f-spot because of that one lib though
<seb128> go back rather
<kees> if it was already in main, that's scary, but i guess it kind of invalidates my nack
<seb128> no it was not
<seb128> it's new
<seb128> but the code it's based on is in main it seems yes
<kees> right, that's what I meant.
<seb128> what would you suggest we do next?
<seb128> we need our default photo manager to build by some way
<seb128> so either we need to go back to f-spot or try to drop that requirement or to promote the lib
<kees> right. so, it seems like libraw is a library version of dcraw?
<seb128> seems so
<seb128> I've not checked myself but robert_ancell suggests that
<seb128> reading his comment
<kees> well, my nack is based on code quality, so if it's already in main, it's nonsense to nack it out now
<kees> things could already call out of dcraw, so the library may not be worse.
<ajmitch> just how nasty is the code?
<kees> ajmitch: lack of bounds checking at the very least, didn't look to hard for integer overflows, though.
<ajmitch> probably my fault that dcraw got into main a few years ago anyway :)
<kees> seb128: so, if it's really the same code as dcraw, then I'm forced to un-nack, but if it's new, I would want to find a new RAW library.
<seb128> kees, ok, so let's say we can promote it for now, I'm still interested to get better quality though so we might still want to fix obvious issue on the lib
<kees> seb128: are there any others?
<seb128> kees, libopenraw it seems
<seb128> kees, not sure if it's any better though
<seb128> kees, can we promote the lib for now so we get shotwell to build and can test it and take a work item to investigate alternatives to this lib?
<kees> seb128: it looks to be C++, and a quick check seems to show it has at least some kind of stream management instead of crazy array poking
<hrw> hi
<hrw> what is a procedure to get package from Debian to be available in Ubuntu?
<hrw> other then "compile it by yourself and keep it locally"
<ajmitch> generally just a sync request is needed to get it into the development release, though we're pretty much at feature freeze
<sladen> hrw: sync request
<sladen> hrw: but you've got about 2 hours left to make it during this release cycle :)
<ajmitch> once it's in the development release a backport to stable releases can be requested
<hrw> ajmitch: I do not care about lucid
<kees> seb128: I've +1'd it now
<sladen> hrw: what is the package?
<maco> which reminds me... any archive admins around?
<seb128> kees, thank you
<hrw> sladen: bluedevil + libbluedevil
<kees> seb128: sure thing, thanks
<hrw> sladen: Bluetooth integration for KDE 4
<ajmitch> kde bluetooth stack? yeah, that looks useful
<seb128> maco, why?
<maco> seb128: new queue request with a cupcake as a bribe?
<hrw> builds fine with fresh maverick - just finishing rebuild
<seb128> maco, what in new?
<maco> seb128: gally
<sladen> Riddell: ^^ bluedevil+libbluedevil for Qt/KDE.  Would have be something sensible to have synched from Debian?
<sladen> s/have/that/
<maco> i told Riddell that if he did it id get him a cupcake during UDS
<maco> but he's afk so... who wants a cupcake at uds? :P
<ajmitch> maco: I do! :)
<maco> i think seb128's interest means he's going to win the cupcake
<seb128> I might ;-)
<ajmitch> bah
<ebroder> Where is the next UDS?
<hrw> what should I use as 'consumer' in manage-credentials?
<ajmitch> hrw: ubuntu-dev-tools, iirc
<ajmitch> the manpage gives an example of it
<hrw> thx
<hrw> o. looks like someone added it (bluedevil) but it not got to archive
<hrw> 11 hours ago
<hrw> ;D
<ajmitch> even better
<hrw> yep
<maco> ebroder: florida
<ebroder> Oh, cool. I wonder if I can make that one
<micahg> is Feature freeze at midnight UTC or morning EU time?
 * micahg wanted to put stuff in later tonight
<Laney> is it tomorrow already? :O
<ajmitch> it's thursday here :)
<chrisccoulson> i don't know what day it is here, my days all blur in to 1 ;)
<ajmitch> stay away from strong drink & sleep deprivation :)
<micahg> as in I was hoping to get stuff in w/in the next 9 hrs
<sladen> micahg: more uploading and less asking :)
<micahg> sladen: i'm at $WORK for another 3 hrs :)
<directhex> mono 2.6.7 is Real Soon Now(tm), and is upstream's enterprise release.
<directhex> i should push xsp and libgdiplus up
<directhex> maybe when i feel less tired
<sladen> directhex: wonder if that'll fix the non-ASCII rendered as squares issue I never tracked down
<sladen> directhex: although upstream Mono reckoned that was a distro issue
<directhex> sladen, maybe, cairo does dodgy things sometimes. i like blaming cairo for stuff
<directhex> sladen, i wouldn't worry much about problems with winforms apps, they're not important to ubuntu
<sladen> directhex: it's still a bug.  And quite a major one for any !English users
<sladen> directhex: as in /every/ accented or CJK glyph is drawn as a square box in Winforms
<directhex> i agree it's a bug, but i wouldn't say it's a priority one. winforms is for compatibility only, really. it's a garbage toolkit
<directhex> i'd sooner use xaw3d
<ScottK> sladen: bluedevil is already sync'ed a few days ago.
<sladen> hrw: ^^ seems it was already done...
#ubuntu-devel 2010-08-12
<SpamapS> mathiaz: ping! - hoping that we can upload moin 1.9.3 before FF tomorrow, if you can take a look at the merge here that would be great: https://bugs.launchpad.net/ubuntu/+source/moin/+bug/586518
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/586518)
<mathiaz> SpamapS: ^^ that's not good ;)
<SpamapS> ttx: I added you to the merge proposal too, since you did the last merge just before lucid release
<SpamapS> haha
<SpamapS> bug 586518
<ubottu> Launchpad bug 586518 in moin (Ubuntu) "Please merge moin 1.9.3-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/586518
<SpamapS> ubottu: I knew you could do it
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Guest76764> ...
<hlieberman> Better.  Question: What is ubuntu policy on shipping .pc files (for pkg-config)?
<hlieberman> It appears that very few packages use them anymore.
<TheMuso> hlieberman: Actually, a lot of packages use them. .pc files are shipped in a packages -dev package. So if you have a library, you have libname0 for example, and libname-dev, the .pc pkg-config file goes in libname-dev
<micahg> hlieberman: they're fairly common (2114 files in Lucid), is there a specific package missing one
<hlieberman> Hm.
<hlieberman> One second, let me check why...
<hlieberman> Ah, got it. Thanks. :)
<tle> I'm looking for an open source project to join and contribute to as a developer. Preferably a smaller project that I can help grow. Does anyone have any suggestions?
<RAOF> tle: I'd suggest finding a program that does most of what you want, but has some niggles, and then go on to fix those niggles.
<tle> RAOF: thanks
<seif> tle, we started a very new small project
<seif> tle, do u use python
<tle> seif: I have very little experience. mostly C, C++, Objective-C, Java, C#
<seif> tle, u can learn python
<seif> it is very easy
<seif> hi RAOF
<tle> seif: so I hear
<RAOF> seif: Howdie.
<RAOF> Banshee's fun to hack on :)
<seif> RAOF, +1
<seif> RAOF, banshee seem like it is going to get an extension
<seif> did u vote already
<seif> ?
<seif> for a zeitgeist extension
<RAOF> seif: Yeah, I did.
<seif> RAOF, AWESOME
<kirkland> pitti: howdy!  can you please accept https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=screen for lucid-proposed?
<pitti> Good morning
<pitti> kirkland: sorry, lucid is still in 10.04.1 freeze
<ajmitch> morning pitti
<baptistemm> hi there
<micahg> if I'm getting unused substitution warnings, but I ran lesspipe and everything looks ok, should I ignorethem/
<pitti> cjwatson: good morning! can you please move d-i/lucid-proposed to -updates? (this requires some extra magic)
* spm changed the topic of #ubuntu-devel to: LP Down/RO for Updates 0800-0930 UTC | Alpha-3 released! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<tjaalton> hey, I see dpkg with the sync() patch is still in lucid-proposed since June 28th, are there issues with it or will it get in updates soon?
<micahg> tjaalton: was there verifiication in -proposed?
<tjaalton> noticed that installing with ext3 took 35min while ext4 made it double
<tjaalton> micahg: the bug shows verification done
<tjaalton> oh wait
<tjaalton> duh, it is in updates
<tjaalton> so the slowdown is something different
<dholbach> good morning
<dholbach> mvo: bug 586790!
<ubottu> Launchpad bug 586790 in software-properties (Ubuntu) "Typo in --help of apt-add-repository" [Low,Triaged] https://launchpad.net/bugs/586790
<dholbach> mvo: slacker! :-P
<mvo> hey dholbach
 * dholbach hugs mvo
<dholbach> hey slomo
<mvo> weeehhh â¦ the sponsoring police
 * mvo tries to hide
<dholbach> haha
<mvo> dholbach: *cough* but you got me, big indanereherenwort to sponsor it today
<dholbach> haha
<dholbach> just merge it in and upload whenever - I forgot about it myself
<dholbach> somebody who was at the session at the time just reminded me
<slomo> hi dholbach
<garet> hello, I am having trouble with an upstart job that isn't running on boot (works well once booted) and I can't find clues on where it's failing
<garet> does anyone know where are traces of the init process ? or how I can make a more detail debug session
<dholbach> pitti, lool: to get bug 525512 fixed, I just need to sponsor the diff of bug 525395?
<ubottu> Launchpad bug 525512 in libtime-modules-perl (Ubuntu) "[MIR] libtime-modules-perl" [Undecided,Fix committed] https://launchpad.net/bugs/525512
<ubottu> Launchpad bug 525395 in backuppc (Ubuntu) "Missing dependency to libtime-modules-perl" [Medium,Triaged] https://launchpad.net/bugs/525395
<dholbach> DktrKranz: HAPPY BIRTHDAY!
<pitti> dholbach: I'll just move the package to main; but the backuppc (525395) one needs sponsoring as it seems?
<dholbach> pitti: ok, I'm happy to sponsor it
<pitti> dholbach: moved to main, I'll update the bug
<dholbach> ROCK
<dholbach> pitti: muchas gracias
<pitti> de nada
<DktrKranz> dholbach: THANKS!
<dholbach> pitti, lool: what about python-werkzeug, parsedatetime, libapache2-mod-wsgi and python-xappy? did those MIRs make it?
<dholbach> (just looking at the moin merge)
<lool> I have not been active on MIRs this cycle
<lool> asac/pitti/kees/doko did most of the work I think
<lool> (sorry for the highlights)
<dholbach> lool: slacker! :-P
<Laney> is the sync queue going to be processed before FF?
<dholbach> "LP will go down for maintenace in 30 seconds."
<Laney> good timing
<soren> Whuh.... If recvfrom returns 0, am I the only one who'd be surprised to find the message buffer actually populated with data?
<dholbach> Laney: nice reply on the motu list
<Laney> dholbach: Cheers. I feel like I'm forever redirecting people ;)
<dholbach> Laney: don't underestimate the service you're doing with that :)
<bilalakhtar> I just used requestsync. Later, I noticed that lp is down for maintainence. What will happen in such a case?
<tkamppeter> The upload server is down. "dput" (to main) gives a "[Errno 111] Connection refused".
<tkamppeter> I can ping upload.ubuntu.com though.
<ttx> nothing like LP maintenance on FeatureFreeze day.
 * asac will do MIRs for 1h+ today
<tkamppeter> dput server is back.
<tkamppeter> Will Thunderbird 3.1 make it into Maverick?
* spm changed the topic of #ubuntu-devel to: Alpha-3 released! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<jibel> mvo, Hey, bug 615923 . a keystroke error I guess.
<ubottu> Launchpad bug 615923 in update-manager (Ubuntu) "Syntax Error - UpdateManager/Core/utils.py" [High,Triaged] https://launchpad.net/bugs/615923
<mvo> jibel: *gar* thanks, I have a look
<dholbach> MIR people: what about python-werkzeug, parsedatetime, libapache2-mod-wsgi and python-xappy? did those MIRs make it?
<pitti> tkamppeter: my hero! *hug* :)
<dholbach> ttx: can you or somebody have a second look over the moin merge? it'd be nice to go in, I'm just not sure if all the MIRs made it
<mvo> jibel: fix uploaded
<ttx> dholbach: I'm on it
<dholbach> yeeehaw
<tkamppeter> pitti, should we add the pt_BR langpack to the CD as the guy who has written the PPD compression is Brazilian?
<ion> tkamppeter: Shouldnât openprinting-ppds depend on python, btw?
<ttx> dholbach: done
 * ttx lunches
<pitti> tkamppeter: right now pt is on i386 only, but after those savings we can put it back on amd64 as well perhaps :)
<tkamppeter> pitti, I have added ${python:Depends} to all binary packages which contain PPD archives.
<tkamppeter> ion, ^^
<pitti> tkamppeter: oh, why? (those only work if you call dh_pysupport)
<pitti> tkamppeter: ah, so the .ppd files are now being generated by a Python module?
<tkamppeter> ion, pitti, "dpkg -p openprinting.ppds" gives "Depends: python, xz-utils", does this not come from "${python:Depends}"?
<pitti> tkamppeter: seems to be alright
<tkamppeter> pitti, yes, the self-extracting archives in /usr/lib/cups/driver/ are Python programs. They only use standard modules and the xz command line utility.
 * dholbach hugs ttx
<SpamapS> ttx: ^5!
<ttx> SpamapS: âµ
<kirkland> pitti: dang, even for -proposed?
<Kano> why is isohybrid not called on the iso image? then it would be hybrid
<Kano> any specific problem to do so
<ogra> Kano, file a but ?
<ogra> *bug
<ogra> Kano, we just upgraded to a new syslinux and looking at bug 553581 isohybrid wasnt even included in the syslinux package until the 14th
<ubottu> Launchpad bug 553581 in syslinux (Ubuntu) "isohybrid command not found" [Undecided,Fix released] https://launchpad.net/bugs/553581
<Kano> ogra: the bug was filed last year
<ogra> Kano, last year we still used an old syslinux version and i dont think that had any hybrid support, the new syslinux only eneterd ubuntu in maverick
<Kano> i know thats why i reported a bug, now syslinux is new enough but no isohybrid script was called on the iso image
<Kano> you have to do that on your build-box
<ogra> against what is the bug filed ?
<ogra> if it needs to happen on the builder, add a task for debian-cd then the cdimage team will see it
<Kano> https://bugs.launchpad.net/ubuntu-cdimage/+bug/524803
<ubottu> Launchpad bug 524803 in Ubuntu CD Images "isolinux hybrid mode should be used - all other major distributions do so since last year" [Undecided,New]
<ogra> that has an answer from colin with an explanation why its not done yet
<Kano> that was 4 weeks ago and nothing changed
<ogra> (who in turn is on vacation)
<ogra> just be patient
<Kano> it is still the case that all other distos which i test / create can do that since last year
<ogra> we are not "other distros"
<Kano> yes u is special, not always in a good way ;)
<ogra> cdimage team is obviously aware and the person working on it is on holiday
<Kano> why does the kubuntu installer not ask for a bootloader target?
<Kano> also it seems the installer ist broken anyway...
<sladen> Kano: the person who looks after cdimage/syslinux build is on holiday.  If you want them to get your feedback, can you post it on the bug report
<Kano> i got that already, what about the kubuntu installer
<sladen> Kano: alot of the install process is about automation---eg. if there is only one answer, not to ask the question
<sladen> Kano: is that what you're seeing?
<sladen> Kano: if there /is/ a bug, it would be good to get it fixed
<Kano> first of all there is not only 1 option, not only mbr is a target, also the partition
<Kano> but it just does not install any bootloader - i used manual partition mode without swap partition
<sladen> Kano: btw, all of the installer logic is in the back-end;  the only difference between K/Ubuntu installers is in the frontend GUI
<Kano> and selected one partition with ext4 / format
<sladen> Kano: if you're doing things /manually/;  do you have a bootable partition selected (eg. the root one)
<Kano> when i only select / then this is the partition
<Kano> the initrd is not copied nor recreated
<Kano> boot/grub empty
<Kano> i booted from a hybrid usb stick of course
<sladen> the initramfs is updated by  sudo update-initramfs;  in-turn called by  sudo update-grub
<Kano> you can be sure i know how to update/create an initrd
<sladen> Kano: here in Ubuntu we try to be open and helpful to everyone regardless of prior knowledge, so I hope you'll forgive me for going through all the options
<Kano> it is part of the installer to do that
<Kano> and that part was skipped
<sladen> Kano: yes, and generally the installer manages to create working installations
<sladen> Kano: but in this case you appear to have managed to create a situation where something has not worked as expected
<Kano> maybe somebody should test it...
<sladen> Kano: however, I'm unclear /what/ you sequence you've done, so I'm trying to ask questions to find out
<ogra_cmpc> it has been tested extensively for alpha3 last week
<Kano> i used the daily build
<sladen> Kano: so far, all I've understood is that on the machine in question, it was booted from an USB image, manually partitioned and then has failed to boot
<ogra_cmpc> if you want a tested image, use that one, if you want to use the daily, file a bug
<Kano> because no initrd was created and no grub installed
<sladen> Kano: right, so if it's a bug, please could you assist the development of Ubuntu by filing it at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug
<ogra_cmpc> or use ubuntu-bug if your test install is networked
<Kano> i think there is a much bigger problem, because the domain is not set, no autologin used, no user created...
<Kano> will try the alpha3...
<Kano> a3 shows a summary screen where to select the bootloader
<sladen> Kano: so the exact same sequence of keypresses between alpha3 and daily produces a different sequence of output
<Kano> yes
<Kano> well i missed to change the keyboard to no dead keys this time i think
<sladen> Kano: in which case that clearly is a bug.  Please file it at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug (or just type 'ubuntu-bug' at the command line and follow the isntructions)
<sladen> Kano: can you try again with the exact same sequence please---(although it probably a bug either way)
<sladen> Kano: but bugs can only be followed up and *fixed* when they are tracked the bug tracker (otherwise they just scroll off the top of IRC...)
<dholbach> kenvandine: I marked 577486 as patch-forwarded-upstream :)
<rsavoye> how can I unsubscribe to a launchpad bug email list ? It's obvious how to subcribe, but not to get off
<JFo> rsavoye, there should be something by your name or at the top of the list on the bug if you are logged in that would allow you to unsubscribe
<rsavoye> that's what I thought, but couldn't find it
<rsavoye> I'd just rather read the bugs via the web page, than overflowing my inbox
<kenvandine> dholbach, thx
<rsavoye> JFo: I still don't see it. All I get us a "subscribe to bug mail", and no "unsubscribe"
<JFo> huh, let me look into it a bit rsavoye
<rsavoye> I thought this should be simple! :-)
<JFo> it seems to be though I wonder why you can't see it :)
<JFo> I juswt checked a bug I am subbed on
<JFo> at the top of the list of subscribers I see a red circle with a minus and the word unsubscribe
<JFo> but then
<JFo> I have also had instances where the edit tag pencil was invisible
<rsavoye> where is the list of subscribers ? This is for linaro-toolchain
<JFo> so anything is possible
<JFo> should be on the right side of the screen
<rsavoye> I'm obviously not very used to launchpad
<JFo> heh
<JFo> no problem
<rsavoye> so I'm here: https://bugs.launchpad.net/linaro-toolchain
 * JFo looks
<rsavoye> it's just that right now I get more bug reports than spam...
<JFo> ah, I see what you mean
<JFo> one sec
<rsavoye> whew :-)
<JFo> let me check something
<JFo> rsavoye, let me ask someone. seems dumb that there is no unsubscribe
<rsavoye> thanks, now I feel less like a total idiot
<JFo> rsavoye, no one could call you any kind of idiot :)
<rsavoye> hey, it's good to feel stupid once in a while... :-)
<JFo> heh
<JFo> are you on a mailing list for the linaro-toolchain?
<rsavoye> yes, since I'm interested
<JFo> I just wonder if that is where the mail is coming from
<JFo> on the bugs
<rsavoye> got me...
<rsavoye> the bug email only lists the bug report URL
<JFo> seems like there should be an unsubscribe for you if you are subscribed
<JFo> hmmm
 * JFo tries something
<rsavoye> sounds like the borg... once assimilated, you never get out...
<JFo> heh, yes it does
<JFo> I may have found you an answer though
<seb128> Riddell, jdstrand, james_w: does any of you has some time for binary new today?
 * directhex has one teeny tiny thing in binary new
<JFo> rsavoye, I guess maybe I don't
<JFo> let me ask someone else
<JFo> rsavoye, if you go here: https://edge.launchpad.net/linaro-toolchain/+subscribe
<JFo> are the items checked?
<james_w> seb128: I shall do some
<seb128> james_w, thanks
<rsavoye> JFo: whre, thanks that did it.
<JFo> excellent :)
<rsavoye> maybe this should be more obvious to do for us launchpad newbies
<JFo> heh, yeah
<JFo> it wasn't obvious to me either
<JFo> and I should have known
<rsavoye> it makes about as much sense as clicking "Start" to shut down a windoze machine...
<JFo> hah! indeed
<highvoltage> that's not completely senseless at least, it's like saying "start the shutdown sequence"
<seb128> james_w, don't new grail binaries if you do, they are brokenly named
<james_w> seb128: thanks
<RenatoSilva> There was any recent change in behavior of /var/log/auth.log? It seems the system hopefully won't log wrong passowords in this file anymore.
* sistpoty|work changed the topic of #ubuntu-devel to: FeatureFreeze in effect! | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ogasawara> StevenK: are you on archive admin duty today by chance?  If/when you have a moment, could I get the linux (2.6.35-15.21) packages in the New queue accepted?
<seb128> doko, could you get https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/autoconf2.64/lp600991/+merge/29328 in debian?
<seb128> lool, is somebody still going to review bug #599874?
<ubottu> Launchpad bug 599874 in kpackagekit (Ubuntu) "kpackagekit makes apt-get upgrade fail while running" [Undecided,Invalid] https://launchpad.net/bugs/599874
<seb128> kirkland, hey, could you review the change on bug #591610?
<ubottu> Launchpad bug 591610 in qemu-kvm (Ubuntu) "memory leak" [Undecided,Triaged] https://launchpad.net/bugs/591610
<seb128> hallyn, ^ if that bug still revelent?
<seb128> it seems there was another sru since
<ScottK> nhandler: Would you please fix the fridge freeze announcement to just refer to ubuntu-release and not motu-release per robbiew's followup mail.
<lool> seb128: Sorry, I'm not very active on the MIR team this cycle
<lool> seb128: Would be best to ping the other reviewers
<fabrice_sp> Hi. Any reason why sync in bug #605774 didn't happen? I can't see any..
<ubottu> Launchpad bug 605774 in Ubuntu "Please sync mozc 0.12.410.102-2 (universe) from Debian unstable(main)" [Undecided,Confirmed] https://launchpad.net/bugs/605774
<mathiaz> pitti: do apport hooks require a FFe?
<hallyn> seb128: checking (on bug #591610)
<ubottu> Launchpad bug 591610 in qemu-kvm (Ubuntu) "memory leak" [Undecided,Triaged] https://launchpad.net/bugs/591610
<hallyn> tbh i'm confused, i thought that had gone in
<mathiaz> james_w: hi
<james_w> hi mathiaz
<mathiaz> james_w: could you look at apache2 pkg branches?
<mathiaz> james_w: it seems that they haven't been imported for a while now
<seb128> hallyn, could you close it if the recent update fixed the issue?
<mathiaz> james_w: BTW who should I report these problems to nowadays?
<james_w> mathiaz: unsure
<hallyn> seb128: close the bug you mean?  or somehow close the merge request?
<hallyn> seb128: I'm afraid I can't verify muchof anything right now - getting 12kb/s...
<seb128> hallyn, right, close the bug and delete the request
<pitti> mathiaz: not from my side; please go ahead and add them
<mathiaz> pitti: great - thanks!
<hallyn> seb128: ok, thanks, will do (after verifying)
<mathiaz> pitti: BTW - how do you test apport hooks?
<pitti> mathiaz: ubuntu-bug mypkg, and then check the details expander
<mathiaz> pitti: ie making sure that the hook is working correctly (eg no python syntax error)
<pitti> mathiaz: or, write a small __main__ method which initializes a dict, pass that to your add_info(), and print it
<mathiaz> pitti: cool - thnaks!
<pitti> (you can leave that in production)
<djzn> any info on 10.04.1
<ngenen> Hi there
<jason_> hello, I have an OpenGL related question. Anyone know of the correct channel?
<megabraker> jason_ what about #opengl?
<jason_> well I worked with Frame Buffer Objects in OpenGL, which required the use of Render Context's. But this was under Windows
<jason_> What I'm trying to figure out is how to set up Render Context's under linux
<jason_> the sample I found (under Windows) used wglCreateContext, which I looked at the header and found it was from Microsoft
<jason_> so I assume that that will not be present under linux
<megabraker> jason_ honestly i dont have any idea but are you working with 3d design?
<jason_> well I'm working with real-time 3d rendering
<megabraker> game dev?
<jason_> yeah, eventually
<megabraker> with what language ?
<jason_> c++
<megabraker> ah is it easy to learn 3d dev?
<megabraker> i heared that c++ is a lil bit hard
<ngenen> jason_, this is not the place but.. what do you want to do ?
<jason_> well, for me, I am able to go back and forth between c++/c#/vb.net like they are the same thing
<megabraker> ok thanks
<ngenen> ok, from the beginning do not under any circunstance compare cpp with vb.net
<ngenen> -.-
<jason_> ngnen, I am actually working cross-platform here, trying to make it so my game is easily portable from windows, linux, and mac OS
<ngenen> jason_, ogre3d is for you
<jason_> hehe, I might use that at some time....but hmmm, you must be suggesting don't try and do it from scratch
<ngenen> jason_, well.. it's normal start with something "easy" and go depper..
<ngenen> not the inverse way..
<ngenen> you can't do kernel hacks if you don't know bash..
<ngenen> you know what I mean ?
<jason_> heh....true
<ngenen> Ogre3D has Direct3D and OpenGL inside, and its abstracted to work with objects
<ngenen> so you don't need to lidiate with internal stuff
<jason_> btw, this is what I've done in 3d so far
<jason_> http://www.youtube.com/user/jviper2004
<ngenen> it's better develop in the way "put a light here" than "in the angle 50Âº looking to the angle 120Âº, with a refraction of 40% and it ligthing of 80% respect viewport2"
<ngenen> jason_, doing that on ogre3d would take.. like a day if you're "learning"
<ngenen> once you know it, it took like.. 15, 20min. of code
<jason_> yep
<ngenen> seriously, go for ogre3d
<ngenen> you'll thank me
<jason_> I'll probably take a look at it, thanks
<ngenen> :) u welcome
<Laney> yay for syncs
<Keybuk> Android scares me
<alkisg> The gr.archive.ubuntu.com server has been down for about 10 days causing a lot of grief for non-sources.list-savvy people here, can I report that somewhere?
<JFo> Keybuk, how so? :)
<alkisg> (i.e. a temporary dns change to map to another greek server)
<Pici> alkisg: I believe that the sysadmins already know about it, but #canonical-sysadmin would the place to report it.
<alkisg> Thank you
<strycore> Hello everyone
<strycore> Got a tricky question here, it's been bugging me for ages. Here it is : In any GTK program that has text edition capabilities, there is the most annoying behavior with  Ctrl+ Delete
<Keybuk> JFo: using Java as an Operating System
<JFo> ah, yes...
<strycore> Ctrl + Delete should erase whitespace until a word is found, and stop but GTK deletes the first word found
<cody-somerville> Keybuk, I think this might be scarier: http://en.wikipedia.org/wiki/JNode
<strycore> An example of good behaviour is Netbeans btw
<Keybuk> heh
<Keybuk> that is scary
<Keybuk> at least Android don't write their kernel in Java
<strycore>  /*  Damn it, I've been writing on the wrong channel all along -_- */
<Keybuk> strace -ff pbuilder pbuild ...
<Keybuk> *sigh*
<neeraj> If i use debcheckout on a certain package, then it will only download the source of the specific package from the VCS repository maintianed in debian.. right?
<Laney> It'll check out whatever is in control
<Keybuk> pbuilder-build.8033:execve("/usr/X11R6/bin/dbus-daemon", ... ) = -1 ENOENT (No such file or directory)
<Keybuk> err
<Keybuk> WTF
<neeraj> Can i download the source code of a latest released version of a certain package without using dget command on the dsc file?
<neeraj> Laney: what if I don't have the package with me right now. I just want to quickly download source code of latest release of xyz package in Maverick.
<Laney> neeraj: If you have a maverick deb-src line, apt-get source package
<Laney> â¦or pull-lp-source package if you have ubuntu-dev-tools installed, or bzr branch lp:ubuntu/package
<Laney> many ways
<neeraj> Laney: ok Thanks for the pointers. Last question. If I have lucid and wants to download the source code of xyz package from Maverick, then what flag i should use.
<Keybuk> huh
<Keybuk> pitti: there?
<Laney> do any of the others than apt-get source, or add a maverick deb-src line
<neeraj> Ok. thanks :)
<Keybuk> so, we no longer install Recommends by default?
<ari-tczew> james_w: ping
<james_w> hi ari-tczew
<ari-tczew> james_w: hello, are all OK with syncs?
<ari-tczew> because I see that you uploaded packages, but there are no new uploads in launchpad
<james_w> excuse me?
<Laney> I think he's asking about flushing the syncs
<james_w> ah, yeah, just done that
<SpamapS> dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 7.4.20ubuntu6)
<SpamapS> hrm...
<SpamapS> mysql-5.1 depends on a version of debhelper that doesn't exist on my archive mirror.. :(
<nhandler> ScottK: Done
<mathiaz> pitti: is there any integration between scripts found in /usr/share/bug/ and apport?
<ScottK> nhandler: Thanks.
<Laney> Were recommends of Build-Depends ever installed?
<ScottK> Laney: No.
<nhandler> ScottK: You are welcome. He sent the follow-up shortly after I did the Fridge post
<ScottK> (AFAIK)
<Laney> I didn't think so
<Laney> Keybuk: ^^^
<Keybuk> Laney: upstart has built before ;-)
<Keybuk> though I could well believe dbus got installed for some other reason
<Keybuk> and something else changed
<soren> SpamapS: Maverick has 8.0.0something.
<ScottK> That's a recent change.  Probably just mirror lag.
<SpamapS> Yeah my mirror seems to not update daily for maverick
#ubuntu-devel 2010-08-13
<lanoxx>  #ubuntu+1
<lanoxx> im wondering what is necessary to approve a pending merge request for bzr? If I have read the code changes and think they are ok, can i approve a merge or do i need to part of some special group to do such a thing?
<lanoxx> In Launchpad I can choose approve Approve and enter a "review type" what should i enter there?
<lanoxx> does that have any effect?
<micahg> lanoxx: for Ubuntu, it's ubuntu-dev, you can help test by joining the reviews team
<lanoxx> the particular packet is update-notifier
<lanoxx> Do I need to show that I have programming experience or anything to be in the review team?
<RAOF> Note that approving the merge is purely metadata - it's not going to actually merge the code.
<RAOF> If you're familiar with kernel or X development, consider it the same as a Reviewed-By: tag.
<ajmitch> maybe some time in the future, approving a merge on LP will do the merge, and automagically create a package from that. But not now
<micahg> lanoxx: I don't think so, you can get more information in #ubuntu-reviews, do you have a link to the merge in question?
<lanoxx> yes i post the link, one moment
<lanoxx> https://code.launchpad.net/~cristiklein/update-notifier/use-xdg-folders/+merge/15038
<LucidFox> E: light-themes: debian-changelog-file-contains-invalid-email-address james@james-laptop
<LucidFox> o_O
<ion> Seems valid to me.
<ion> Perhaps a bit difficult to reach, but valid nevertheless.
<TheMuso> There is no dot in that address.
<TheMuso> Which is why its claiming invalidity.
<ion> Non-compliant to the policy, sure, but not invalid. :-P </nitpick>
<TheMuso> ion: Hense saying it claims invalidity.
<TheMuso> ion: I am not saying that it is invalid.
<StevenK> I *think* the RFC says it's invalid
<SpamapS> which RFC?
<StevenK> Damn it, I knew someone was going to ask that
<StevenK> 822 is what my brain is prompting
<SpamapS>    An addr-spec is a specific Internet identifier that contains a
<SpamapS>    locally interpreted string followed by the at-sign character ("@",
<SpamapS>    ASCII value 64) followed by an Internet domain
<SpamapS> thats 2822
<ion> http://www.mythic-beasts.com/~pdw/cgi-bin/emailvalidate
<SpamapS> My whois client says james-laptop isn't found. Maybe james just forgot to renew?
<StevenK> Hah
<StevenK> I wonder how much it costs for a GTLD
<ion> . would be even cooler to own.
<pitti> Good morning
<pitti> Keybuk: I'm now
<pitti> tkamppeter: ah, seems the "cups does not start" problem was now fixed in lucid-proposed
<pitti> tkamppeter: bug 554172  FYU
<ubottu> Launchpad bug 554172 in linux (Ubuntu Lucid) "system services not starting at boot" [Critical,Confirmed] https://launchpad.net/bugs/554172
<hamish> Hi - Is anyone actively on line?
<pitti> !ask | hamish
<ubottu> hamish: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<hamish> Ok - I have downloaded 10.1 Maverick - has anyone got mono-develop running and using C# development IDE?
<tseliot> hamish: doesn't it work?
<hamish> nope
<tseliot> hamish: maybe file a bug report with the following command? "ubuntu-bug monodevelop"
<hamish> just thought I'd pick someones brains - but I will maybe get back to it :-)
<tseliot> you may also find a bug report with the same problem
<hamish> 10nx
<tseliot> np
<directhex> what specifically sin't working?
<directhex> oh...
<hyperair> anyone using reprepro here? i'm wondering if there's a more elegant solution than sed -i -e '/ddeb/d' when using reprepro in the presence of pkg-create-dbgsym
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<directhex> i guess hamish was having trouble due to mono being in NEW on i386 but not amd64, so it's uninstallable on all arches other than i386
<pitti> didrocks: right, it gets held back here
<didrocks> directhex: ^^
<directhex> which is due to upstream sticking a new library in their minor bugfix update. which isn't new behaviour for them, really
<RAOF> Or to switch âlong-term-supportâ to a 2.6 release? :)
<directhex> RAOF, i understand the reasons for that... i wish they were a bit more honest up front though
<directhex> 2.6.7 is definitely where it's at though, it aligns us with novell's enterprise products
<pitti> directhex: mono NEWed
<directhex> pitti, thanks!
<pitti> and new kernel with it, while I was at it
<directhex> you're a queue-mangling superstar
<jibel> mvo, Hey, could you have a look at bug 606150 , it was fixed in bug 571743 but this time the problem is with mythbuntu-desktop
<ubottu> Launchpad bug 606150 in update-manager (Ubuntu) "mythbuntu 10.04 fails to upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/606150
<ubottu> Launchpad bug 571743 in update-manager (Ubuntu) "system upgrade 9.10 --> 10.04 could not calculate upgrade when both xubuntu-desktop and ubuntu-desktop are installed" [Medium,In progress] https://launchpad.net/bugs/571743
<mvo> jibel: yes
<jibel> mvo, thank you
<tkamppeter> pitti, I have seen it in my e-mail. Great.
<tkamppeter> pitti, only problem is that this has somehow distracted us from switching CUPS over to native upstart.
<jdstrand> mdeslaur: hey. at some time convenient for you would you mind giving virt-manager a workout with the new libvirt I uploaded? I tested it for several things but not super-extensively
<mdeslaur> jdong_: yeah, sure
<mdeslaur> jdong_: sorry, not you
<mdeslaur> jdstrand: yes, sure
<jdstrand> mdeslaur: thanks
<robbiew> superm1: ping
<superm1> robbiew, pong
<robbiew> superm1: looks like bluetooth is busted in maverick...have you noticed this?
<superm1> robbiew, i've only been testing installer stuff in maverick, so no i haven't.  how busted is it?
<robbiew> doesn't work
<robbiew> :/
<robbiew> but it's recent
<robbiew> could just be a desktop issue, i.e. the underlying plumbing stuff could be fine
<robbiew> I haven't looked into it yet
<superm1> robbiew, well plumbing stuff looks quite suspect, it was just updated 18 hours ago
<robbiew> heh
<robbiew> ok...hadn't checked that
 * robbiew only found out today
<mathiaz> pitti: hi!
<LucidFox> How does one add a screenshot to software-center?
<mathiaz> pitti: while reviewing the apache2 apport hook I noticed that there is already a apache2 .bug-script for reportbug
<mathiaz> pitti: I wonder if there is any integration in apport to automatically support all of these scripts?
<robbiew> LucidFox: ask mvo
<mvo> LucidFox: go to screenshots.ubuntu.com and upload it there
<mvo> (hello btw :)
<LucidFox> Oh!
<LucidFox> Didn't even know it existed
<mvo> LucidFox: yeah, we need to make more noise about it
<pitti> hey mathiaz
<pitti> mathiaz: no, there isn't; I had a look at them some time ago, and most of them weren't very useful
<mathiaz> pitti: ok
<pitti> mathiaz: and they don't have a predictable structure, so we could only put the entire blob as one attachment
<mathiaz> pitti: for apache2 the hook was doing the same thing as the script
<mathiaz> pitti: right - that's what I'd suggest
<pitti> mathiaz: but if the apache one is useful in particular and does nontrivial stuff, of course feel free to include it using command_output()
<mathiaz> pitti: cool - thanks for the advice
<pitti> mathiaz: but the bug scripts are geared towards email inclusion in reportbug
<pitti> mathiaz: i. e. they could (and some do) also ask questions on stdin, etc.
<mathiaz> pitti: and it seems that they can also prompt the user
<pitti> those are better done with the interactive apport hooks
 * mathiaz nods
<mathiaz> pitti: it's probably a case-by-case basis then
<mathiaz> pitti: and for the non-interatice ones, command_output() is enough
<kees__> pitti: sent you some email...
<pitti> asac, seb128: argh, I just fixed a bug in the WI tracker cron job which would prevent team membership updates; that'll explain the problems that you saw
<pitti> silly thing
<pitti>      # stuff that we do daily only
<pitti> -    if [ `date +%H` = 0 ]; then
 * seb128 hugs pitti
<pitti> +    if [ `date +%H` = 00 ]; then
<asac> wow. very good
<asac> now i can pick up 1000 new WI for all the newcomers ;)
<asac> and make them feel bad :-P
<pitti> asac, seb128: I run a refresh now
<pitti> but unfortunately these days the bloody thing runs for 1.5 hours
<seb128> pitti, thanks
<pitti> SpamapS: ^ help
<asac> thanks. i will go hunting for the expected WI increase in a bit then ;)
<pitti> SpamapS: didn't you say you'd enable per-user charts for some teams only?
<asac> pitti: how long does a run take nowadays?
<asac> 1h ?
<pitti> asac: 1.5
<pitti> ish
<asac> wow
<pitti> it produces nearly 2000 files each run now
<pitti> http://people.canonical.com/~pitti/workitems/maverick/u/
<asac> might make sense to parallelize it in the cloud to put more pressure on launchpad ;)
<asac> i guess most time its talking to launchpad? or is it really pure processing?
<pitti> asac: pure processing
<pitti> http://people.canonical.com/~pitti/workitems/maverick/u/pitti-ubuntu-10.10-beta.html
<pitti> now I can watch my one WI for beta with very high granularity :)
<asac> you are lagging ;) ... by 1 item for beta
<asac> guess you can easily catch up though ;) ... ok i will check in 2h then
<pitti> so, good night and have a nice weekend everyone
<asac> enjoy your weekend!
<SpamapS> pitti: they're generated for everybody
<pitti> SpamapS: ah, I thought I remember limiting it to some teams
<SpamapS> pitti: but there's a bug, WI's are selected for any specs you're assigned to
<pitti> but that might have been for one of jiboumans' features
<SpamapS> pitti: inprogress is limited to teams
<SpamapS> we didn't want to mess with peoples' numbers
<SpamapS> in case they're graphing the todo somewhere, inprogress might confuse that
<pitti> SpamapS: maybe it would be enough to produce the per-user charts for the current milestone or the entire cycle only?
<SpamapS> pitti: it takes 1.5 hours for the whole thing?
<pitti> as it is right now, lillypilly constantly runs 100% cpu for this thing
<pitti> SpamapS: yes
<SpamapS> pitti: how much of that is waiting on launchpad? ;)
<pitti> I had to decrease the cronjob from being hourly to 2-hourly
<pitti> SpamapS: maybe 10 mins
<pitti> SpamapS: collect doesn't take any more time
<pitti> SpamapS: it's just generate-all
<SpamapS> pitti: maybe the indexes had some unexpected side effects?
<SpamapS> or is it just that the box is fairly limited?
<pitti> SpamapS: no, it's just the sheer quantity, I think; it has to calculate and create over 1800 files, after all
<pitti> of which 1/3 is pychart
<SpamapS> on my macbook pro it takes 40 minutes to do the whole thing, but 25 of that is querying launchpad
<pitti> LP is fast, it's in the DC after all; maybe 10 mins
<SpamapS> right, for me LP is halfway around the world
<pitti> SpamapS: lillypilly is a 8-core 2.4 GHz
<pitti> but of course we don't parallelize
<SpamapS> pitti: might be worth profiling it again.. I used the python profiler and found right away that it was spending all of its time on the selects in report_tools
<SpamapS> if nothing else, make sure sqlite is using the indexes.
<SpamapS> pitti: on your other point, I think it makes perfect sense to skip generation of past milestones.
<pitti> SpamapS: right, that would already help a lot; could you do that?
<pitti> or just the currently active milestone
 * pitti waves, have to run now
<SpamapS> pitti: will take a look at it
<SpamapS> have fun board breaking. :)
<jdstrand> slangasek: hey, so qt4-qws is massive (and coming from alexandros.frantzis@linaro.org). could you tell me (or point me to a page stating) the end goal of this package?
<ScottK> jdstrand: It's in New?
<jdstrand> ScottK: yes
<ScottK> Oh my.
<ScottK> Nothing like a "small" code copy.
<jdstrand> my thoughts exactly
<jdstrand> Estimated lines of source: 1831032
<slangasek> jdstrand: sorry, not familiar with it.  Is it actually a code copy, or is it a fork of the upstream code?
<slangasek> jdstrand: I assume it's qt building for a non-X target, but I don't know why that should be a fork
<slangasek> jdstrand: looks like https://blueprints.launchpad.net/ubuntu/+spec/arm-m-qt-on-embedded is the thing
<jdstrand> slangasek: it seems like he took Riddell's package and updated a few debian/* files, changing references to qt4 to qt4-qws... :\
<jdstrand> and there is no bug
<jdstrand> without looking at it super closely, it seems these things could just be integrated...
<Riddell> not without making it much harder to maintain the qt4-x11 package
<slangasek> why would it make it harder to maintain?
<slangasek> increased build time?
<jdstrand> I am really leery of an almost 2 million line cody copy that is sure to diverge
<jdstrand> regardless, this should be tracked in a bug
<slangasek> what should be?
<Riddell> you'd have to build it and package it twice, that's going to make the packaging much harder to maintain (currently we don't have much diff from debian) as well as the increased build time
<jdstrand> is this destined for main?
<Riddell> no
<slangasek> Riddell: as far as I'm concerned, that's an argument for coordinating this change with Debian, not for pushing it out into a separate source package containing identical sources
<SpamapS> Riddell: we do that for a lot of server side packages that are pretty big.. mysql.. php.. its common to need several configurations of a single code base
<jdstrand> Riddell: perhaps you should be the one accepting it, but it make me really uncomfortable. I have a debdiff in /tmp/jdstrand between what is in maverick and the package. if it were left to me, I would reject it, asking the submitter to file a bug so that people could comment on how to best get it included
<jdstrand> in fact, I think I am going to reject it saying just that
<Riddell> alf__: best defend yourself quickly :)
<Riddell> or asac
<alf__> alf: what?
<alf__> Riddell: what?
<Riddell> alf__: see above conversation about qt4-qws
<slangasek> alf__: archive admin concerns about not shipping two nearly-identical source packages of qt4 in maverick
<slangasek> alf__: do you know of reasons why this shouldn't be built from the same source package?
<jdstrand> nearly identical with almost 2 million lines of source, that are sure to diverge at some point, making a maintenance nightmare
 * Riddell notes that having 36 hour long builds is also a maintenance nightmare
<jdstrand> it seems clear this is contentious at best
<jdstrand> it needs to be discussed somewhere and tracked outside of irc
<slangasek> I would have expected that everything outside the core gui bits could be shared between the builds, making the total build time significantly less than 2x the current built time, no?
<Riddell> slangasek: no
<alf__> jdstrand: agree with riddell + the complexity of having multiple build runs for the same source package
<superm1> is it only building again for non-X for arm though?
<slangasek> Riddell: why not?  e.g, libqt4-network has no GUI dependencies
<jdstrand> we have 36 hour or longer builds for other packages due to arm. why should this be different, assuming slangasek's comments don't apply
<Riddell> superm1: it's for any arch
<Riddell> slangasek: it's a different ABI
<slangasek> Riddell: really? why?
<Riddell> jdstrand: mostly because that makes it my problem whereas this way it's nicely kept as linaro's problem :)
<Riddell> slangasek: dunno
<jdstrand> but linaro will surely not be keen on that as soon as there is a security or bug fix update
<didrocks> jdstrand: can you bin new utouch, please?
<slangasek> Riddell: it's not just linaro's problem; if the packages are completely disjoint, that's going to start leaking across into dependencies of packages that use qt and can run with either variant
<slangasek> which is much less elegant
<jdstrand> to me, it seems like a code copy is that absolute last resort, after demonstrating why doing it other ways doesn't work
<Riddell> slangasek: being a different ABI packages can only run with one variant
<slangasek> Riddell: do you have a pointer to more information about how the ABI is different?
<jdstrand> didrocks: ok
<didrocks> jdstrand: thanks a lot :)
<Riddell> slangasek: nope
<jdstrand> ok, well, I am going to reject, asking for more information as to why this is the way it must be
<slangasek> alf__: do you know anything about ABI differences when building for X11 vs. QWS?
<alf__> slangasek: I will forward you an email with upstream
<slangasek> alf__: thanks
<alf__> slangasek: anyone to CC to?
<slangasek> alf__: you could cc: it to jamie@ubuntu.com
<ScottK> slangasek: shouldn't it go to ubuntu-archive?
<slangasek> alf__: ^^ you can send it there too
<slangasek> ScottK: I'm not subscribed to ubuntu-archive, so I generally neglect that list for anything other than archival of information :)
<ScottK> Oh.  OK.
<ScottK> Actually I'm not either.  I just read the web archive sometimes.
<neeraj> Hi, I have copied my .gnupg folder from lucid to my maverick, but my keys aren't getting synced. I am also not seeing password and keys manager in applications->accessories.
<alf__> slangasek: sent (not to ubuntu-archive though, you were not fast enough :))
<slangasek> smoser, mathiaz: do we need 10.04.1 builds of EC2/UEC, or is this already covered by the regular image refreshes?
<mathiaz> slangasek: we don't need to publish EC2/UEC images for 10.04.1
<mathiaz> slangasek: EC2/UEC images are taken care of independently
<slangasek> thought so, but wanted to double-check
<slangasek> thanks
<smoser> slangasek, yeah, there are a couple bugs that i want to have in before there would be a 10.04.1 refresh. we're hoping (with landscape team) to have something soon ish after that.
<mathiaz> slangasek: 10.04.1 deliverables for the server team are the two -server isos (amd64, i386)
<slangasek> smoser: ok
<slangasek> mathiaz: server up, http://iso.qa.ubuntu.com/qatracker/build/all
<mathiaz> slangasek: great - thanks
<slangasek> ogasawara: are you still maintaining http://qa.ubuntu.com/reports/ogasawara/weatherreport.html ? can we get that switched to point at lucid for 10.04.1?
<ogasawara> slangasek: http://qa.ubuntu.com/reports/ogasawara/weatherreport-10.04.html, but gimme a sec to make sure the scripts are pointing at the right data
<slangasek> ogasawara: I guess not, a lot of 'manifest not found' there :-)
<ogasawara> slangasek: indeed
<slangasek> paths should be lucid/daily-live/current, kubuntu/lucid/daily-live/current, ubuntu-server/lucid/ [...]
<slangasek> alf__: thanks for that mail!  I'm going to give it a ponder, but I suppose he's right and we have to have completely disjoint sets of binaries :(
<ogasawara> slangasek: do you know the paths for the DVD's?
<slangasek> ogasawara: would be lucid/dvd/ if we had any, but I had no plans for publishing those
<ogasawara> slangasek: ok, I'll just comment them out from the script
<slangasek> (whoever turned lucid on in the cronjob didn't include DVDs, and we've certainly foregone them in the past)
<SpamapS> slangasek: when you said "server up", did you mean its coming, or its already up? I get a 404 on http://cdimage.ubuntu.com/ubuntu-server/daily/20100813.2/lucid-server-i386.iso
<slangasek> SpamapS: http://cdimage.ubuntu.com/ubuntu-server/lucid/daily/20100813.2/lucid-server-i386.iso - the ISO tracker doesn't do the best at handling point release URLs
<mathiaz> SpamapS: are you planning to do some iso testing for 10.04.1?
<mathiaz> SpamapS: if so - I'd suggest to start by doing the raid1 test case
<mathiaz> SpamapS: that would be very helpful
 * slangasek stares at bug #617516
<ubottu> Launchpad bug 617516 in plymouth (Ubuntu) "Audio mutes moments before boot finishes" [Undecided,New] https://launchpad.net/bugs/617516
<slangasek> could people please stop using the plymouth package as a dumping ground for everything that doesn't work at boot?
<ion> and go back to using the upstart package for that
<SpamapS> mathiaz: yes I had planned to do that test again
<mathiaz> SpamapS: great - I'm going through the other tests first
<slangasek> ion: exactly :)
<mathiaz> SpamapS: so if you start by raid1 we'll meet up at some point
<SpamapS> mathiaz: I may not get to it for 1 or 2 hours.
<mathiaz> SpamapS: that's ok - any help in this area is appreciated
<SpamapS> mathiaz: to me, the lvm/raid1 stuff is the only really important part of the ISO's anyway. ;)
<mathiaz> SpamapS: :)
<slangasek> ogasawara: kubuntu netbook is also included in the .1, btw - could you pull it into the report?
<ogasawara> slangasek: yep
<slangasek> thanks!
<ogasawara> slangasek: I assume some of the packages in the images are being pulled from -proposed correct?
<slangasek> yes, they are
<ogasawara> slangasek: I've added it to the report, currently showing "Manifest NOT found"
<ogasawara> slangasek: once it's there, the report should show it
 * ogasawara skips out for a quick bite to eat
<slangasek> ogasawara: ack
<rickspencer3> tedg, we had a community process for picking featured apps!
<tedg> rickspencer3, Oh, what is it?
<rickspencer3> we had a wiki page where community members nominated apps
<rickspencer3> then we had some criteria, discussed in a meeting, etc...
<rickspencer3> I forget it exactly
<rickspencer3> I guess we need to think about starting it again for maverick :/
<tedg> rickspencer3, Yeah, I guess I was thinking something formalized, etc.
<tedg> rickspencer3, i.e. who gets the "final call"
<rickspencer3> tedg, that was me
<rickspencer3> but I didn't have to make any "calls"
<tedg> rickspencer3, I know, and I love you rick, but you're still not elected :)
<rickspencer3> the community sorted it out without needing any interventions
<rickspencer3> well, elected or not, it was still my responsibility :)
<tedg> rickspencer3, Yes, I guess I would worry about someone half as cool getting the responsibility -- and how do we deal with that.  Not as much that what we have is broken, but how do we make it better.
<rickspencer3> tedg, I think hear you volunteering
 * rickspencer3 writes blueprint, assigns to tedg
<rickspencer3> j/k
<tedg> rickspencer3, heh, sure.  saacfl (self appointed application chooser for life) ;)
<tedg> All in all, I thought that's what jono's post was about -- and I thought it was a good idea :)  Now, the fact that I read it wrong is a different problem :)
<tedg> Heh
<saacfl> not sure I like having a nick that is pronounced "sack full"
<tedg> rickspencer3, I think it just means you throw big parties: http://www.lyricsdomain.com/1/acdc/big_balls.html
<rickspencer3> I'm not even going there
<lool> Was sparc dropped already?!
<lool> Hmm I guess I need to poke someone to build glib2.0/sparc by hand or so
 * lool mailed lamont
<rsavoye> I thought sparc was stil being supported
 * micahg saw a post on -devel that it's being discussed at the next TB meeting
<rsavoye> we talked about it at UDS
<micahg> rsavoye: right, but the decision was to evaluate at Feature freeze if anyone has committed to maintain which they'll do at the next meeting
<rsavoye> ah
<ScottK> lool: sparc is not dropped, but glib2.0 was eating buildds.  That's why it was banned.
<ScottK> rsavoye: So far no on has appeared, so it'll be dropped shortly.
<ScottK> (barring last minute maintainers from nowhere)
<rsavoye> sounds fair, if nobody wants to support it, why bother...
<rsavoye> especially if it causes problems
<ScottK> That last sparc installer that worked was in Gutsy.  It doesn't run on Karmic or Lucid as I understand it.
<ScottK> It may compile stuff, but it's really quite dead already.
<rsavoye> I think with Oracle, Sparc is dead anyway
 * ScottK nods
<lamont> lool: still around?
#ubuntu-devel 2010-08-14
<lamont> rsavoye: g'afternoon
<rsavoye> howdy
<rsavoye> wow, somebody in my own timezone :-)
 * lamont is about to go to sleep... it's just after 1AM here. :p
<lamont> weather in madrid is kind of hot this week
<rsavoye> I bet, I've been there...
<rsavoye> it;s gorgeous back here in Colorado :-)
<lamont> I'll be home this weekend though
<lamont> looking forward to it like you can't imagine.
<rsavoye> I bet. 78F, and a nice breeze, no humidity now
<ebroder> So...I have a live image that I stripped *way* down, and as a result, compiz isn't passing settings back and forth to gconf
<ebroder> My compiz process loaded libccp, which I thought should be enough. Any thoughts on where to look?
<ebroder> (I have compizconfig-backend-gconf installed)
<ebroder> I tried simulating installing ubuntu-desktop to see what it would add, but I didn't see anything relevant
<ebroder> And looking in /proc/$(pgrep compiz)/maps, it's mapped /usr/lib/compizconfig/backends/libgconf.so and /usr/lib/libgconf-2.so.4.1.5
<micahg> rickspencer3: hi, around?
<rickspencer3> hi micahg
<rickspencer3> for a bit, yeah
<rickspencer3> 'sup?
<micahg> rickspencer3: PM?
<cody-somerville> Hobbsee, are you around?
<ebroder> Seriously? REVU is hosted on a sparc box? And nobody's...fixed that?
<bilalakhtar> bdrung: Thanks for uploading that qgo !
<bdrung> bilalakhtar: you are too early!
<bilalakhtar> bdrung: I know, you are still dputting it!
<bdrung> bilalakhtar: now you can thank me. :)
<bilalakhtar> bdrung: Thanks!
<bdrung> bilalakhtar: it was not the dputting part, but the 'press enter to upload' part.
<bilalakhtar> bdrung: press enter ? Does dput ask for confirmation before uploading!
<bdrung> bilalakhtar: nope, but ack-sync asks
<bilalakhtar> bdrung: ok
<bilalakhtar> bdrung: Are you an AA ? What's ack-sync ?
<bilalakhtar> bdrung: got ack-sync
<bdrung> bilalakhtar: nope, i am not an AA. ack-sync is a script in ubuntu-dev-tools
<bilalakhtar> bdrung: Ack-sync is NOT in ubuntu-dev-tools. Probably it is in maverick
<bdrung> bilalakhtar: it's in the bzr branch and it the tarball in maverick
<bilalakhtar> bdrung: aha
<bdrung> bilalakhtar: the package needs some lintian love: http://paste.debian.net/83213/
<bilalakhtar> bdrung: Not our problem, since package is maintained in debian
<bilalakhtar> bdrung: but the number of lintian W/I/P Tags are HUGE
<bdrung> bilalakhtar: it's maintained in debian doesn't mean that it's not our problem. if it's maintained in debian i create a patch and send it to the bts. after getting it accepted, i do the sync
<bilalakhtar> bdrung: Well, so, fine
<bilalakhtar> bdrung: I shall do that
<bilalakhtar> no problem with it
<bdrung> it depends how much you care about the package :)
<LucidFox> https://edge.launchpad.net/ubuntu/+source/wine1.2
<LucidFox> Why is this even on other architectures anyway?
<LucidFox> Shouldn't it be limited to [amd64, i386]?
<LucidFox> it fails to build on every other architecture
<mycae> Hello. I am a DM who has uploaded a new package into debian. However I am unfamiliar with the sync process for packages that are not currently in ubuntu, particularly in light of the debian testing and ubuntu feature freezes.
<mycae> After reading the wiki page DebianImportFreeze and SyncRequestProcess, I am still somewhat mystified as to whether or not I should request a sync.
<Laney> mycae: For a (source) NEW package you'll need to file a feature freeze exception
<Laney> !ffe
<ubottu> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<mycae> Is that still the case even though testing migration has stopped?
<Laney> it's nothing to do with Debian's freeze. :)
<mycae> so asking for a pull from unstable is OK?
<Laney> sure, providing that the freeze break is granted
<mycae> So, last question, "The ubuntu-release team will consider exceptions, where additions of packages are worthwhile"; what are the guidelines for "worthwhile". My packages is for specialist scientific purposes.
<sabdfl> mycae: should be no problem, just ask for the sync
<mycae> ok
<Laney> Yeah new application packages usually aren't trouble
<sabdfl> hi Laney
<Laney> hiya sabdfl
<Laney> you ok?
<sabdfl> all good here, sunny in the IoM, long hike planned for the w/e
<sabdfl> a nice announcement queued up for Monday, too ;-)
<Laney> you tease
<Laney> ...and I'll be away!
 * warp10 draws a red circle around "16" on his calendar
<MattJ> What's currently the best way (as an application) to detect when a new device is plugged in?
 * sebner is wondering what sabdfl means with "nice", nice for whom :P
<lool> directhex: LP #617782 > oo.o fails to build due to changes in the .pc file of mono, which stopped Requiring glib while still including the glib headers
<ubottu> Launchpad bug 617782 in mono (Ubuntu) "openoffice.org FTBFS in maverick - /usr/include/mono-1.0/mono/metadata/assembly.h:4: fatal error: glib.h: No such file or directory" [High,New] https://launchpad.net/bugs/617782
<Laney> lool: will you patch or should one of us?
<directhex> lool, i'll commit the fix from novell bugzilla to git.debian.org, but i'm not on the right system to build/upload a quick fix to ubuntu right now - if it's urgent, can you ubuntu2 mono with the fix?
<directhex> or Laney could take care... hang on, Laney can't write to mono.git :/
<Laney> no big deal
<directhex> still busted in mono-2-6 branch. bah @ upstream
<directhex> it's just uncommenting, but still
<Laney> do you have the commit?
<directhex> there's no useful upstream commit
<Laney> thought it was Fixed In Trunkâ¢
<directhex> totally changed how it's done in trunk
<Laney> awesome
<Laney> let's just revert
<directhex> make sure meebey knows about it, before rene goes on the warpath
<Laney> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
 * Laney eyes directhex 
<directhex> meh.
<Laney> teehee
<directhex> not gonna lose sleep over a package maintained by a team not having the global ubuntu address there
<Laney> building the diffgz takes ages
<Laney> directhex: err wait, did 2.6.7 ever get pushed?
<directhex> yeah
<directhex> i think so anyway...
 * Laney eyeballs
<sebner> maverick has 2.6.7 yes
<Laney> ah yes
<Laney> no, to git
<sebner> oh, or do you mean git?
<sebner> ah
<lool> Laney, directhex: Sorry, was away for lunch, I can upload to Ubuntu if you like me to
<lool> I pinged you ASAP because I saw it's close to Debian and kept in git
<Laney> lool: no worries, just building now
<lool> Laney: Oh perfect thanks
<Laney> seems serious enough for an Ubuntu upload to me
<lool> Laney: So there's a Vcs-Git, is the Ubuntu packaging also in git?
<lool> If not, would be a pain to have these changed to XS-Debian-Vcs-* when uploading to Ubuntu?
<Laney> I don't think there's a branch, but that is a good idea
<lool> Having a branch and keeping the fields verbatim is ok, albeit it makes it hard for Ubuntu devs to honor the Vcs (commit before upload)
<lool> Perhaps using collab-maint would grant access to more people too
<Laney> access is quite tightly controlled
<Laney> Ubuntu people could use the UDD branch I guess
<Laney> I've not really worried about it to be honest
<lool> Laney: there's also 9b59c568255ea4f6935287d4aacaf1ddcfcedde9
<lool> Laney: (same change to mono-2.pc)
<lool> http://paste.ubuntu.com/477895/
<lool> Laney: Apparently, this is caused by the move to eglib
<Laney> lool: I don't think we install that one
<Laney> ah, it's not in 2.6
<lool> Laney: So the correct fix is in 2.8
<Laney> right
<lool> Laney: You might want to add a note in the patch, as it's likely to apply in 2.8 still
<Laney> Is it? I thought they'd fixed in trunk/2.8
<Laney> I see no Requires: there though indeed
<lool> The mono.pc wont apply because they kept the requires as comments and these are missing in 2.8, but the mono-2 one might apply
<Laney> mono-2 doesn't apply to 2.6
<lool> Ok, good then
 * Laney debuild -S
 * Laney dput
 * Laney done. /me leaves
<Laney> thanks for pointing it out, lool
<lool> Laney: thanks for the upload
<shadeslayer> asac: ive poked Riddell about the linphone MIR, still awaiting his reply... kdenetwork which requires linphone was uploaded with linphone deps yesterday
<asac> shadeslayer: thanks for the update
<teja> i hav a problem in hearing sound in ubuntu 10.04
<teja> any one please help
<ktovie_kto> hello, where can I report bugs regarding themes? Can it be ubuntu-artwork@Launchpad ?
<jpds> ktovie_kto: light-themes.
<bdrung> zul: ping
<bdrung> zul: you have touched apache2 many times. can you have a look at bug #609177 and decide what to do?
<ubottu> Launchpad bug 609177 in apache2 (Ubuntu) "Apport Hook" [Wishlist,Triaged] https://launchpad.net/bugs/609177
<megabraker> why GTK2 scrue up with nautilus?
<geser> cnd: I just noticed that we have gesturetest and utouch-gesturetest in the archive. It looks like the later is the correct source package name we want to keep, right? If yes, could you please request the removal of the wrong one.
#ubuntu-devel 2010-08-15
<bilalakhtar> good morning
<megabraker> hi everyone, am a python dev using tkinter , is it possible to insert flash animations in a tkinter canvas ? is gif animmation would be aother choice? and thanks
<megabraker> *animation *another
<megabraker> sory
<megabraker> i thought my self in tcl chanel
<megabraker> XD
<zaytsev> Ahoj
<zaytsev> Could someone please tell me what would be the procedure to claim ownership of pre-created LP projects, such as this one: https://launchpad.net/mc
<zaytsev> I dropped a message to the owner, but didn't get any response at all after few months
<sladen> zaytsev: I'm not sure, and chances are that they aren't around at the weekend anyway.  If you file something on:  https://launchpad.net/launchpad/+filebug  hopefully it'll get answered during the week
<zaytsev> sladen, thanks, filed https://bugs.launchpad.net/launchpad/+bug/618198 .
<ubottu> Launchpad bug 618198 in Launchpad itself "Pre-created LP Midnight Commander project seems to be unmaintained" [Undecided,New]
<sladen> zaytsev: thanks!  If you haven't got it solved during this week, come back to me and I'll try and find somebody directly
<sladen> zaytsev: (but hopefully you will have!)
<zaytsev> sladen, thanks again :) let's see
#ubuntu-devel 2011-08-08
<poolie> hi all
<RAOF> Hey poolie
<siretart> ScottK: s/CODEC_TYPE_VIDEO/AVMEDIA_TYPE_VIDEO/, and similar for audio
<pitti> Good morning everyone
<hrw> hello
<Daviey> Is anyone able to fix the sponsorship queue?
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> pitti, it is about the color management Blueprint.
<tkamppeter> pitti, I have done the needed packaging and MIR work as far as I could in the moment.
<pitti> we currently have some trouble syncing colord from Debian, as we don't support tar.xz tarballs yet; but we can just reupload that as tar.bz2 or tar.gz for ubuntu
<tkamppeter> pitti, I have updated argyll and libiccc, now with one source package (argyll), but it is still in the NEW queue due to the new binary packages. To get also the MIR (still TODO) done before FF we need to get it through the NEW queue quickly.
<tkamppeter> pitti, does this mean that we do not get colord in in time? Or do we need to have our own independent package for one cycle until we get a new dpkg in the next cycle?
<pitti> tkamppeter: it's a launchpad issue, not dpkg; RAOF can just reupload it in time for FF
<tkamppeter> pitti, we also need to sync in the new package icc-profiles from Debian non-free to Multiverse and then MIR it into Restricted.
<tkamppeter> pitti, is it a problem to do the MIRs and rebuild CUPS, Foomatic, Ghostscript, and g-c-c with colord support after FF?
<pitti> this is a new feature, so it'll need a FFE, yes
<seb128> well we should be able to land that before ff
<seb128> like the package is ready, I will ping mterry and didrocks for review
<tkamppeter> pitti, can there be done one FFE bug report for the whole color management stack?
<pitti> tkamppeter: icc-profiles is already in oneiric/multiverse
<seb128> then rebuilds are easy to di
<seb128> do
<pitti> tkamppeter: yes, with individual tasks for the affected sources
<tkamppeter> pitti, so icc-profiles is ready for a MIR?
<pitti> seb128: well, you probably need an additional configure switch, new build dep, and testing
<pitti> tkamppeter: yes
<seb128> pitti, right, well for g-c-c that seems doable
<seb128> not speaking about the other part of the stack
<pitti> yes
<tkamppeter> pitti, bug 821861 did not get an answer yet.
<ubottu> Launchpad bug 821861 in Ubuntu "Please sync icc-profiles from debian unstable" [High,Confirmed] https://launchpad.net/bugs/821861
<pitti> tkamppeter: closed
<tjaalton> seems like oneiric fails to mount ntfs partitions on boot
<tkamppeter> pitti, also closed.
<pitti> meh, LP is timeout-o-rama today
<pitti> every other bug operation times out
<tjaalton> "serious errors were found while checking the disk drive..", though it mounts just fine later on
<RAOF> pitti: Launchpad *can't* handle .tar.xz when syncing, but will happily accept PPA uploads with .tar.xz?  Strange.
<pitti> RAOF: hm, bug 619152 sas it's still pending in LP
<ubottu> Launchpad bug 619152 in Launchpad itself "Add data.tar.xz support" [Low,Triaged] https://launchpad.net/bugs/619152
<pitti> RAOF: did you try it with a PPA?
<RAOF> pitti: Yeah.  Well, Laney did.  Let me see... yeah, bug #742408 is the relevant one.  619152 is for debs with xz compression, not orig.tar.xz
<ubottu> Launchpad bug 742408 in Launchpad itself "Support xz compression in source packages" [Low,Fix released] https://launchpad.net/bugs/742408
<RAOF> Have you tried syncing it across, and it failed?
<RAOF> Time to make dinner!
<pitti> RAOF: yes, see #u-desktop
<tkamppeter> pitti, MIR for icc-profiles posted.
<Laney> don't confuse .data.tar.gz with .orig.tar.gz
<Laney> the latter works, the former does not
<Laney> I can manually upload colord if you want?
<tkamppeter> pitti, as bug 822587
<ubottu> Launchpad bug 822587 in icc-profiles (Ubuntu) "[MIR] icc-profiles" [High,Confirmed] https://launchpad.net/bugs/822587
<pitti> Laney: perhaps the internal sync tool has an extra check for that still, so it's worth a try
<Laney> ok
<cjwatson> Laney: wait please?
<Laney> ok
<cjwatson> Laney: I want to investigate this
<Laney> /just/ in time
<Laney> I was hovering over enter :-)
<cjwatson> it's good news that Debian supports .orig.tar.xz now though
<cjwatson> pitti: what was your sync-source command line, please?
<pitti> cjwatson: sync-source.py -b raof colord
<tkamppeter> pitti, there is also a small, trivial printer driver package in the NEW queue, rastertosag-gdi (bug 700141), which I want to get into main and two other printer driver MIRs: c2esp for Kodak inkjets (bug 821940) and ptouch-driver for Brother label printers (bug 821943). All rather small and simple packages, consuming nearly no CD space. Would be great to have them on the Oneiric CDs.
<ubottu> Launchpad bug 700141 in Ubuntu "[needs-packaging] rastertosag-gdi - Ricoh Aficio SP1100s is Windows-only (GDI) printer" [Medium,Fix committed] https://launchpad.net/bugs/700141
<ubottu> Launchpad bug 821940 in c2esp (Ubuntu) "[MIR] c2esp" [Medium,Confirmed] https://launchpad.net/bugs/821940
<ubottu> Launchpad bug 821943 in ptouch-driver (Ubuntu) "[MIR] ptouch-driver" [Medium,Confirmed] https://launchpad.net/bugs/821943
<cjwatson> heh, that's easy, it's a flush-syncs bug :-
<cjwatson> )
<cjwatson> shonky script that it is
<cjwatson> synced
<Laney> woop
<pitti> \o/ thanks cjwatson
<Laney> I think that's the first .orig.tar.xz package in Debian
<Laney> go RAOF!
<CoreStyx> hello, read a lot, but what is the truth: Bug, Feature, etc. ? mdadm -> RAID -> /dev/md0 ->on top lvm volume -> udevd-work : inotify_add_watch(6, /dev/md0,10)failed, No such file or directory
<cjwatson> that sounds like you should file a bug
<cjwatson> I don't see how it could possibly be a feature
<cjwatson> RAID on LVM is fairly unusual (though not unheard of; I do know of somebody else using it, although not on a current Ubuntu system), so I expect it's simply poorly tested
<CoreStyx> some people say itÂ´s a bug, but if it would be possilbe to instruct udev to leave /dev/md0 alone instead install the watcher on /dev/mapper/lvofmd0
<CoreStyx> but I canÂ´t try it because I donÂ´t know where to start on this
<cjwatson> I don't know what the proper fix is, and wouldn't like to guess on the fly
<cjwatson> as I say, I recommend you file a bug
<CoreStyx> ok ... because a bug need to be proofed as a bug... and as i try to say... if somebody can tell me where to start remapping udev it would be a fix/workaround without having a developer look into it
<CoreStyx> but ... no problem... where do I file a bug
<cjwatson> https://help.ubuntu.com/community/ReportingBugs
<CoreStyx> thx
<cjwatson> in this case I have a suspicion that providing a workaround is about as difficult as providing a fix
<debfx> cjwatson: is there a way to avoid having xterm pulled onto the kubuntu cd? I think the problem is that xorg (seeded in desktop-common) depends on xterm | x-terminal-emulator
<debfx> and konsole (which provides x-terminal-emulator) is seeded in kubuntu-common
<cjwatson> debfx: can't answer without investigating, but I'll have a look
<cjwatson> debfx: is this a new problem?
<debfx> cjwatson: no, I just noticed it because xterm gained a .desktop file
<cjwatson> I expect fixing it would require xorg to be moved to each of the flavour-specific desktop/kubuntu-common/whatever seeds
<cjwatson> doesn't the fallback X session make some specific use of xterm though?
 * cjwatson is reluctant to rearrange that himself rather than letting the X people do it
<RAOF> cjwatson: I'm not as familiar with failsafeX as bryceh is, but I don't *think* it uses xterm.
<tjaalton> the dependency comes from debian
<tjaalton> xorg is just a convenience metapackage
<debfx> xinit also pulls in xterm
<RAOF> Because _that_ has a default behaviour of starting an xterm, yes.
<tjaalton> debfx: so you don't want to see {u,}xterm in kde menus?
<debfx> tjaalton: I want to drop the package from the cd unless there is a good reason not to
<cjwatson> I don't think I meant failsafeX; I think I meant one of the sessions that gdm or something used to offer
<cjwatson> perhaps not relevant any more
<tjaalton> gdm ships xsessions/xterm.desktop
<tjaalton> though it doesn't depend on xterm..
<tjaalton> debfx: that's hard :)
<cjwatson> of course there's nothing wrong with seeding xterm in ubuntu.oneiric/desktop or something if we want
<cjwatson> the basic problem here is that germinate doesn't (and can't be allowed to) know about what's in kubuntu-common when it's processing desktop-common
<cjwatson> it will process dependencies in desktop-common as if kubuntu-common didn't exist; if that means that xterm is the most obvious package to select to satisfy xorg's dependency, it will do so
<jayvee> you wouldn't think that a debian-based distro should have its dev channel suffixied with -devel
 * jayvee shrugs
<jayvee> I'm trying to debug a segfaulting totem but having trouble generating a stack trace (gnome 3 ppa I know, but this is a generic question)
<jayvee> ulimit -c unlimited
<jayvee> totem
<jayvee> gdb totem core
<jayvee> bt
<jayvee> produces nothing but ?????'s
<jayvee> however, totem-dbg is installed
<jayvee> you'd think at least *some* of the trace would be filled
<cjwatson> jayvee: dev channel> huh?  Debian's development channel follows the same naming pattern
<jayvee> cjwatson: I jest, I jest
<cjwatson> I see
<cjwatson> perhaps https://wiki.ubuntu.com/DebuggingProgramCrash will help you
<jayvee> okay well now I have a backtrace
<jayvee> but now I realise I don't have nearly enough knowledge to debug the problem
<jayvee> before I get kicked out of the channel for running unsupported software, can somebody recommend a place where I won't get my head bitten off if I ask for help debugging this gnome3 ppa issue?
<cjwatson> jayvee: I don't know if it's the correct channel, but perhaps #ubuntu-desktop is at least a more targeted place to ask
<jayvee> thanks
<jayvee> interestingly enough, the problem has mysteriously vanished
<berdario> hello
<berdario> I tried to join ubuntu-iso and ubuntu-boot
<berdario> but it seem that nobody's around there
<berdario> I'm trying to look into information into an ubuntu bug
<berdario> I'm not into #ubuntu-bugs because this has already been reported and confirmed (for the wrong package, actually...)
<berdario> https://bugs.launchpad.net/ubuntu-release-notes/+bug/774089?comments=all
<ubottu> Ubuntu bug 774089 in grub2 (Ubuntu) "Booting fails 3 times, works every fourth time after new install of Natty Narwhal amd64 on Macbook Pro" [Undecided,Confirmed]
<berdario> basically, I'm interested in this, since a friend of mine got this, and I was trying to help him
<berdario> it seems that at least 21 people (surely more) got their macbooks half-bricked by installing ubuntu
<berdario> (there're also some youtube videos that document this problem)
<berdario> basically... I'm here for 2 things:
<berdario> get in contact with whoever decided to integrate efibootmgr into ubuntu, understand why, and eventually... if possible... try to fix the bug (I don't have the hardware here, but maybe I could arrange to meet my friend quite soon)
<berdario> and the 2nd thing, especially if it isn't possible to fix... prompt someone to look into the bug
<berdario> because people are requesting that the release notes should be updated with it, and to warn people, it seems a quite reasonable request
<berdario> about efibootmgr:
<berdario> it's a software developed by dell's Matt Domsch
<berdario> apparently it leverages upon elilo
<berdario> this alone, seems strange to me
<berdario> I mean: ubuntu has always used grub by default (I even tried to use grub-efi and it was working fine)
<berdario> mixing elilo and grub seems like asking for trouble imho, but maybe I'm missing something
<berdario> on top of that, the last update to efibootmgr
<berdario> has been on 2008
<berdario> the strange thing is that efibootmgr has been included in ubuntu (and only the 64bit cd) right now
<berdario> it's present in the 11.04 disc
<berdario> but it's absent from the 10.04.3 disc
<berdario> so, I guess the decision to integrate it has been taken quite recently
<ScottK> siretart: Thanks.  I now remember you had to tell me that before.  Maybe I'll manage to remember it this time.
<berdario> ScottK: sorry if I bother you, but since you're here
<berdario> do you know who I can refer to for decisions concerning mac support?
<ScottK> For EFI install issues, probably in #ubuntu-installer.
<ScottK> And IIRC, you're right.  11.04 was the first release to support EFI for boot on Macs.
<berdario> ok, thanks... I'll look there
<kelemengabor> hi pitti, do you have a few minutes? dpm uploaded some updated langpacks to natty-proposed, but my update-manager can't see them. could you check what happened to them?
<jml> Hello, I've just submitted a very simple patch â https://code.launchpad.net/~jml/ubuntu/oneiric/python-defaults/swallow-stderr-812960/+merge/70744. Not really sure what happens now.
<nigelb> it shows up on the sponsorship page and someone picks it to be sponsored.
<geser> btw: is the sponsoring page broken or does my link point to the wrong location?
<Laney> looks broken to me
<nigelb> geser: strange. I was just about to ask the same question
<Laney> uh oh, and bdrung and dholbach are both away
<nigelb> I'm using pre-beta browser, so I thought it was just me.
<geser> Laney: you know, as usual such bugs only happen when everybody who knows how to fix them is on vacation
<infinity> jml: You might also want to poke doko and/or ScottK about getting your patch into Debian.
<infinity> jml: (The patch itself looks good and obviously correct to me, if I wasn't running to breakfast, I'd sponsor it to Ubuntu for you, but it may as well go to Debian anyway)
<jml> infinity: thanks. I'll do that.
<ipc> howdyâ¦ can someone point me to more information re: https://wiki.ubuntu.com/Core ?
<ScottK> jml: I've asked the dh_python2 developer (POX) to look at it.  Assuming he agrees (I'd be surprised if he didn't), I'll commit it to the Debian VCS for the package.
<ipc> the procedure mentions unpacking 'Ubuntu Core' but not where to download the archive
<nigelb> geser: heh
<nigelb> geser: "knowing" how to fix isn't a problem. Access to fix it is differnt ;)
<nigelb> I could probably spend a fe minutes and understand it.
<Laney> i'm sure you can find someone to deploy it for you
<Laney> dunno where the code is though
<nigelb> yeah, I'm looking around for that.
<infinity> ipc: http://cdimage.ubuntu.com/ubuntu-core/
<ipc> beautiful
<ipc> thanks!
 * infinity was not aware persia had written that wiki page...
<infinity> ipc: His page doesn't, for instance, mention that we only ship -core tarballs for armel right now.  So, hopefully that's what you want. ;)
<geser> nigelb: https://code.launchpad.net/~ubuntu-dev/ubuntu-sponsoring/trunk
<nigelb> Just got there.
<nigelb> So, ~ubuntu-dev can commit to it, so someone can merge changes in.
<nigelb> Now to find the fix.
<ogra_> infinity, 35M ? we should really lose some fat here :P
<ipc> infinity: I'm just eager to get a peek :)  I really like the whole idea
<ogra_> seems the release subdir is lacking the manifest
<infinity> ogra_: I know, I know.
<infinity> I have a TODO about fixing the release scripts to love -core correctly.
<infinity> But it's also a day off today, so.  Later. ;)
<ipc> thanks, take care!
<ogra_> yeah, cure your jetlag !
<infinity> Syrup and waffles cure everything.
<ogra_> not without coffee though
<ScottK> jml: Committed to bzr in Debian.  Thanks.
<ScottK> jml: http://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-debian/revision/261?start_revid=261
<nigelb> Loggerhead? Interesting.
<nigelb> Didn't know it was a separate project till now :)
<cjwatson> always has been
<jml> ScottK: thanks
<jml> ScottK: is there stuff I should (could?) have done to make that easier for you? Work that you did that I could have done myself?
<cjwatson> hallyn: does http://paste.ubuntu.com/661171/ look right to you?  I have a sync from Debian I'd like to do (for WPA support in d-i) that requires libnl3, and it seems like least paperwork if we just convert everything in main to libnl3 in one go ...
<cjwatson> hallyn: I can't really test that, but it does at least build
<ScottK> jml: If the branch had been against the current python-defaults head in Debian, that would have made it easier, but it's a bit unreasonable for me to expect you to know that.  Including a proposed debian/changelog entry would have been good.
<ScottK> Personally I like using diff and patch better than VCS merges, but eventually I'll get over it, I'm sure.
<jml> ScottK: you would have had to change the 'who' bit of the changelog if I had provided such an entry, right?
<ScottK> jml: If you had, I probably would have left your name on it rather than mentioning you in the text of the entry.
<ScottK> dch makes it trivially easy to change it in any case.
<jml> ScottK: ok, thanks.
<hallyn> cjwatson: (at a sprint this week, sorry for slow responses) : i don't know what that lib is offhand.
<cjwatson> hallyn: the netlink socket handling library
<cjwatson> you were just last uploader, maybe I should be asking somebody else
<hallyn> cjwatson: is there an open bug for this?
<cjwatson> no
<cjwatson> just from discussion here and on #ubuntu-desktop today
<jtaylor> barry: hi, you did you get my argparse message?
<barry> jtaylor: i did, but i'm just back from a week off so still catching up
<Laney> would appreciate a moderation on u-d-a, providing the mail is alright
<cjwatson> Laney: done
<Laney> ty
<pitti> kelemengabor: hm, they are not in the unapproved queue
<kelemengabor> pitti: dpm swears he uploaded... to somewhere
<kelemengabor> but as he is now on holiday, we cannot ask :(
<pitti> kelemengabor: https://launchpad.net/ubuntu/+source/language-pack-es/+changelog
<pitti> kelemengabor: seems someone actually accepted them
<cjwatson> I did
<cjwatson> was that OK?
<pitti> they should be fine, yes
<cjwatson> skaet was asking about them
<pitti> thank you
<kelemengabor> cjwatson: thanks!
<pitti> kelemengabor: so you can send out the call for testing
<cjwatson> that was only about an hour ago though, so they may not quite be on mirrors yet
<kelemengabor> sure, in a moment
<kelemengabor> hm, not yet on the main server, I'll wait a bit
<pitti> kelemengabor: they'll also need a couple of hours to build
<pitti> kelemengabor: see https://launchpad.net/builders
<kelemengabor> oh... I thought these are already the binaries :(
<jtaylor> is a MIR planed for underscore? it would be needed for a new python-sphinx version which has the very useful dh_sphinxdoc debhelper
<jtaylor> uglifyjs is also needed for it
<tkamppeter> pitti, ping
<mdeslaur> Is it a known issue that nothing is setting XAUTHORITY on oneiric alpha3?
<micahg> can someone give synaptic back please
<mdeslaur> Is there no way to add rights to a user using "User Accounts" in oneiric anymore?
<cyphermox> micahg: doing it now
<micahg> cyphermox: thanks
<roadmr> hey folks! gconf{video,audio}sink are no longer in gstreamer0.10-plugins-good, and the replacement gsettings{audio,video}sink are in gstreamer0.10-plugins-bad, are there plans to move this to -good?
<ScottK> doko: Could you re-run your dh_python2 conversion script against the Kubuntu desktop manifest so I can find out if there are any additional packages we need to convert for Kubuntu (I think they are all done).
<doko> ScottK: it's just running grep-dctrl for the status file from the image
<doko> barry: ^^^
<ScottK> So you're going to make me have to think about it ...
<ScottK> OK.
<barry> ;)
<doko> trying to catch up on things, so this is not my priority
<doko> no, I didn't save the command
<micahg> ScottK: you could also look at the germinate output for the kubuntu seeds
<dupondje> aptitude broke down ? :)
<micahg> no, there's an apt transition in progress
<dupondje> hehe ok, lets hope apt-get keeps working to upgrade ^^
<slangasek> cyphermox: is there a transition plan for libnl3?  there are a number of other packages besides NM using libnl1 in main
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: open for business | Development of Ubuntu (not support, not app development) | #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: bryceh
<bryceh> http://reports.qa.ubuntu.com/reports/sponsoring/ seems to be busted
<dupondje> yea
<dupondje> since some days
<bryceh> jeez the UbuntuDevelopment/CodeReviews wiki page is wordy...
<tormod> bryceh, can you please sync #808679 ?
<bryceh> tormod, hmm not sure I have rights for doing syncs
<tormod> bryceh, as a dev you can ack it and sub u-a
<bryceh> tormod, well I can do that, although I think you need someone with archive rights to actually sync it
<bryceh> tormod, sound good?
<tormod> bryceh, yes thanks, it will surely help
<bryceh> hmm, this makes me curious why sync requests go through ubuntu-sponsors?  wouldn't it make more sense for them to go directly to ubuntu-archive?
<Laney> because they are the same as any other upload
<micahg> bryceh: the syncs aren't always appropriate/buildable
<Laney> and need to be checked for sanity
<tormod> bryceh, I guess it is to spare the u-a people from all kinds of requests from non-devs
<bryceh> couldn't someone with ill intentions just sub ubuntu-archive directly?
<Laney> i suppose archive admins check that syncs have been properly acked
<micahg> it's to spare the AAs from having to verify the syncs
<bryceh> hmm interesting *shrug*
<bryceh> seems like a loosey goosey process to me but whatever :-)
<micahg> when people subscribe AAs directly, it usually gets kicked back to the sponsor queue unless the AA is feeling benevolent
<micahg> s/AAs/u-a/
<natschil> Good day. Is there an easy way of making a script/ubuntu package for ubuntu that will make changes to a script that is in /lib persistent even if the script is updated by the package system?
<RAOF> natschil: It sounds like you're after dpkg-divert
<bryceh> micahg_, how about sync requests that are pulling new packages into ubuntu?  Do those just get passed on to -archive or do they need further processing/review?
<natschil> RAOF: cool. but doesn't that simply lock a file completely for any updates? though maybe that is what I want.
<bryceh> micahg_, e.g. #821550
<micahg_> bryceh: same deal, make sure the package is something we want in this cycle and make sure it's buildable
<micahg_> bryceh: and that's already in oneiric :)
<ajmitch> I think the point of that sync is just so that it autosyncs next time
<bryceh> ajmitch, won't it require a fakesync?
<micahg_> yep, but most of those aren't worth doing at this point
<ajmitch> bryceh: only if the orig.tar.gz is different
<micahg_> i.e. explicitly filing bugs for those syncs, not processing existing ones filed
<micahg_> unless there's something else interesting in the Debian upload
<bryceh> micahg_, ok so you think these types of sync requests (with no functional changes other than the version number) should be wontfixed?
<micahg_> bryceh: no, you can process them, but inform the requestor that efforts are best spent elsewhere (the time to do them are before DIF since they have no affect afterwards)
<Laney> you might as well ack them if someone has taken the time to check, but advise the submitter that it could have waited until next cycle (and if they want they can put a note on mom to indicate they have checked)
<ajmitch> hopefully by then they'll be syncable via the LP UI/API
<micahg_> it took a while for me to understand the reasoning, but now I agree with it
<bryceh> alrighty, thanks
<natschil> RAOF: thanks for the help, I think I'll use dpkg-divert
<ion> Cool, aptitude segfaults now. :-)
<RAOF> Oh, it's missing appropriate dependencies for the apt transition?
<ion> It seems libapt-something was updated but apt was held back. aptitude segfaulted after that upgrade. When i upgraded apt with âapt-get install aptâ, that removed aptitude.
<slangasek> so a no-longer-installed package segfaults?
<ion> aptitude safe-upgrade: apt was held back, libapt-something was updated, aptitude stayed installed. After that: aptitude segfaulted. apt-get install apt: apt was updated and aptitude was removed.
<slangasek> ah
<cjwatson> slangasek: all the libnl reverse-build-deps are in progress
<cjwatson> slangasek: I asked for that change because WPA support in netcfg depends on a new wpasupplicant version which switched to libnl3, and that's a pretty high-value thing
<cjwatson> I think we can manage it
<slangasek> cjwatson: ok, no worries - just hadn't heard anything prior to seeing it show up in the components-mismatches list, and it was worrying to see that it was a separate source package
<cjwatson> slangasek: libnl3 ought to supersede libnl in main; I'm not sure why it's separate in Debian, but there were only eight reverse build-deps so I'm working to make sure we can just swap it
<cjwatson> (presumably because there are some API changes as well as just ABI)
 * slangasek nods
#ubuntu-devel 2011-08-09
<kees> any archive admins around to fix busted components on linux-lts-backport-maverick in lucid? most of it is incorrectly in universe.
<kees> jdstrand, slangasek: ^^ ?
<kees> I should clarify: most of the udebs are in the wrong place...
<kees> http://security.ubuntu.com/ubuntu/pool/main/l/linux-lts-backport-maverick/ vs http://security.ubuntu.com/ubuntu/pool/universe/l/linux-lts-backport-maverick/
<azop> Is there a WIKI article that goes into detail on extending the installation process?  I need to install some packages during CD installation, but also ask the user for database authenication (this is handled during installation of the package)
<slangasek> kees: updated
<kees> slangasek: thanks
<dupondje> https://launchpad.net/ubuntu/+source/libgphoto2/2.4.11-3 => failed on i386 & armel with  graphviz : Depends: libgvc5 but it is not going to be installed
<dupondje> but locally it builds just fine ... maby retry build ?
<RAOF> dupondje: Checking, then I'll hit the rebuild button.
<dupondje> thx
<dupondje> RAOF: fixed i386 it seems, but armel has same issue again :)
<RAOF> dupondje: Bah.  So, we need to wait until that dependency chain is fixed.
<dupondje> what was wrong exactly ? :)
<tkamppeter> RAOF, any news about colord?
<RAOF> dupondje: Presumably the archive is inconsistent, waiting for something to be published.
<RAOF> tkamppeter: It was successfully syncd yesterday; it's now in Ubuntu.
<tkamppeter> RAOF, great, thanks for working on getting it in. I will MIR it then ...
<tkamppeter> RAOF, I see the entry in LP now, only it seems to be still waiting in the NEW queue.
<tkamppeter> Does anyone know whether one can already post a MIR for a package which is still waiting in NEW?
<RAOF> Yes, absolutely.
<tkamppeter> RAOF, so I will do the MIR soon ...
<tkamppeter> RAOF, I have set bug 741448 to "Fix committed" now.
<ubottu> Launchpad bug 741448 in Ubuntu "[needs-packaging] colord" [High,Fix committed] https://launchpad.net/bugs/741448
<RAOF> Ta.
<RAOF> It shouldn't take long through NEW.
<pitti> Good morning
<pitti> tkamppeter: hello, pong
<tkamppeter> pitti, hi
<tkamppeter> pitti, I pinged you yesterday as I have fixed a bug in libjpeg6b which I cannot upload by myself. It is bug 777670. dbdiff is attached. Can you upload it for me? Thanks.
<ubottu> Launchpad bug 777670 in libjpeg6b (Ubuntu) "wrong colors on HPCLJ 3500/3600 printer after switching to 11.04" [Medium,Fix committed] https://launchpad.net/bugs/777670
<pitti> tkamppeter: hm, how does that affect the linking of other programs?
<pitti> sounds like it could affect dependency generation if you build packages against that new libjpeg
<pitti> tkamppeter: can you please send this patch as a debian bug as well?
<tjaalton> sweet, color management getting in the distro while I'm looking for a decent photo printer :)
<tkamppeter> pitti, does Debian use the same LDFLAGS default?
<tkamppeter> pitti, if Debian and/or Ubuntu cannot accept the patch, how should we fix HPLIP then?
<pitti> I wasn't saying that we cannot accept it, just that I don't understand the impact
<pitti> and that it should be done in Debian as well to avoid a divergence of behaviour on such a central package
<pitti> tkamppeter: no, we don't have an LDFLAGS delta, just the multiarch build
<doko_> seb128, didrocks: https://launchpadlibrarian.net/76875081/buildlog_ubuntu-oneiric-armel.openjdk-6_6b23~pre4-2ubuntu1_FAILEDTOBUILD.txt.gz
<doko_> do you already know what's th guilty package?
<chrisccoulson> doko_, hmmm, i had some weird failures like that overnight too
<chrisccoulson> will take a look
<seb128> re
<seb128> doko_, no
<seb128>  the apt logs don't make it easy to figure what the issue is
<seb128>  somebody with access to an armel install needs to run an apt-get install by hand
<tkamppeter> pitti, I have committed the fix of bug 780935 to the BZR, can you upload to Debian and Ubuntu? Thanks.
<ubottu> Launchpad bug 780935 in cups (Ubuntu) "ps2pdf mangles document (breaks font)" [High,Fix committed] https://launchpad.net/bugs/780935
<pitti> tkamppeter: is that very urgent?
<pitti> tkamppeter: bandwidth sucks here, so if next week is enough, I'll do that then
<dupondje> https://launchpad.net/ubuntu/+source/eiciel/0.9.8.1-2 => seems to have failed also due to broken depends. But it builds fine here ... could anyone check and eventually hit the rebuild button :)
<tkamppeter> pitti, OK. pitti, you are not at home?
<pitti> tkamppeter: no, I'm on the desktop summit in Berlin
<tkamppeter> pitti, then we can meet tomorrow. I am in the BoFs of Color Management and Common Printing Dialog.
<tkamppeter> pitti, and so also on the Summit some time before and after these meetings and during lunch.
<nigelb> Trying to unbork sponsor queue.
<nigelb> FYI.
<nigelb> ok, so it works locally.
<nigelb> *goes* to set cron somewhere accessible.
<tkamppeter> pitti, Debian bug is submitted now. You are CCed.
<tkamppeter> pitti, Debian bug 637184
<ubottu> Debian bug 637184 in libjpeg6b "libjpeg6b linked with "-Bsymbolic-functions", causing problems with HPLIP and pxljr" [Normal,Open] http://bugs.debian.org/637184
<nigelb> Hi, can someone in ~ubuntu-dev, please help review and merge https://code.launchpad.net/~nigelbabu/ubuntu-sponsoring/remove-subprocess/+merge/70835
<nigelb> Trying to unbork sponsorship overview
<nigelb> Laney: around?
<Laney> in 30 mins?
<nigelb> sure :)
<brendand> all of a sudden add-apt-repository is not found in Oneiric
<brendand> did this happen to anyone else?
<tkamppeter> RAOF, MIR for colord posted as bug 823185
<ubottu> Launchpad bug 823185 in colord (Ubuntu) "[MIR] colord" [High,New] https://launchpad.net/bugs/823185
<cjwatson> colord binary NEWed
<Daviey> Please can an AA promote ipxe, it's causing us upset. (shows in components mismatch, has a valid MIR).  Currently it's causing xen to depwait.
<jtaylor> is a MIR planed for underscore and uglifyjs? it would be needed for a new python-sphinx version which has the very useful dh_sphinxdoc debhelper
<cjwatson> Daviey: done
<Daviey> cjwatson: Thanks!
<tkamppeter> cjwatson, thanks for passing through colord, and also for fixing LP for it.
<Laney> nigelb: er whoops that took longer than expected
<nigelb> Laney: np :)
<nigelb> There seems to be deeper problems with the machine anyway.
<nigelb> I've got a temporary stop-gap page up
<nigelb> http://nigelb.me/sponsoring/
<nigelb> and here's the merge https://code.launchpad.net/~nigelbabu/ubuntu-sponsoring/remove-subprocess
<Laney> have IS looked at it?
<Laney> the machine that is
<nigelb> yeah
<nigelb> I was working with IS on triaging the problem
<nigelb> Still not sure, keeps throwing out OOM errors.
<tumbleweed> is it ulmitied?
<nigelb> tumbleweed: ulimited?
<tumbleweed> yes
<nigelb> I don't know what that means.
<nigelb> this is the traceback http://pastebin.ubuntu.com/661786/
<nigelb> ah, user limited
<nigelb> tumbleweed: < Spads> ulimit says unlimited
<Spads> nigelb: it's actually strict overcommit
<nigelb> Spads: so, is that the cause of the OOM?
<Spads> I wouldn't call it the *cause*
<tumbleweed> ubuntu-sponsoring is quite a beast, but I'm suprised it's OOMing
<Spads> the cause is people using up all the RAM :)
<nigelb> heh
<Spads> strict overcommit just causes malloc() to error out instead of dragging us down into swap thrashing
<nigelb> ah
<nigelb> makes sense.
<tumbleweed> we could try and improve its memory use
<Spads> and it seems that modern apps don't report that situation as gracefully as I'd like
<Spads> we're looking to rebalance allocation of resources
<nigelb> my merge was to sort of improve it
<tumbleweed> python is particularly bad, because it can't free memory easily
<nigelb> use a python fucntion instead of using subprocess
<Spads> partly to try and identify which apps are consuming how much
<Spads> nigelb: yeah, that sounds promising
<Spads> if it happens a lot
<Spads> who knows
<nigelb> I'm trying to run it on my box. I just haven't gotten the cron working
<Spads> but if you have test environments, you may want to do some profiling
<cjwatson> nigelb: while it's probably a good idea, that isn't in a tight loop or anything so it will make only a negligible difference to resource allocation
<Laney> is this supposed to take ages to run?
<nigelb> cjwatson: yeah :(
<nigelb> Laney: the first time, yes. where ages  = ~ 5 minutes
<nigelb> I have a report up on http://nigelb.me/sponsoring/
<nigelb> hm, why does something work as my user but not in cron.
<cjwatson> locale variables?
<cjwatson> or something else in the environment
<Laney> I'm getting KEyError from lp.distributions['ubuntu']
<nigelb> its a (. /home/nigel/.bashrc && path/to/script)
<nigelb> but launchpadlib keeps wanting to authenticate
<nigelb> Laney: that's interesting.
<cjwatson> presumably for use from cron launchpadlib's credentials will need to be in an unencrypted store rather than (say) gnome-keyring; it has options for this kind of thing
<nigelb> indeed, I can see the credentials saved in the lp_data folder
<tumbleweed> cjwatson: ubuntu-sponsoring doesn't need credentialed access, IIRC
<nigelb> hm, why does it keeping ask me then :|
<Laney> it should probably use login_anonymously
 * tumbleweed wonders why it doesn't already
<tkamppeter> cjwatson, can you also pass argyll (new binary packages), rastertosag-gdi, and cloudprint through NEW?
 * cjwatson swaps over libnl and libnl3 source (libnl -> universe, libnl3 -> main)
<cjwatson> tkamppeter: when I get a moment, sure
<Daviey> cjwatson: Hmm, ipxe is still showing in universe for me?
<cjwatson> Daviey: mirroring delay
<cjwatson> it's in main on the master archive
<Daviey> cjwatson: thanks
<Laney> nigelb: tumbleweed: want to look at lp:~laney/ubuntu-sponsoring/anonymous ? small change â seems to work for me
<Laney> got distracted by an epic journey that culminated in an NMU to ssmtp on the way to producing that branch :P
<nigelb> heh
<nigelb> trying it out
<tumbleweed> Laney: The only reason I can think of that it would need to be non-anonymous is private security bugs. But those shouldn't be appearing on the sponsorship list anyway, right?
<Laney> right
<Laney> i doubt it was using any privileged credentials anyway
<nigelb> .
<nigelb> ~.
<tumbleweed> Laney: I'd probably have used __file__ instead of sys.argv, but LGTM
<nigelb> Laney: it works
<nigelb> btw, something funny
<nigelb> ~/laney/ubuntu-sponsoring/anonymous... ubuntu sponsoring anonymous? :P
<cjwatson> tkamppeter: it's not grounds for rejection (although it will probably be grounds for stalling the MIR), but please convert cloudprint from python-support to dh_python2, as python-support is deprecated.  http://wiki.debian.org/Python/TransitionToDHPython2
<cjwatson> tkamppeter: all three of those belatedly accepted now, anyway
<nigelb> tumbleweed: probably easier to just merge Laney's branch than mine :)
 * tumbleweed merges them both
<cjwatson> mvo: FYI bug 823277 looks fairly urgent
<ubottu> Launchpad bug 823277 in apt (Ubuntu Oneiric) "Ubuntu 64bit failed to install with d-i : apt-get[26978] trap divide error ip:7fc64730d4ee sp:7fffa066b2a0 error:0 in libapt-pkg.so.4.11.0[7fc64729b000+114000]" [Critical,Confirmed] https://launchpad.net/bugs/823277
<mvo> cjwatson: thanks, I saw it, I have one potential fix in bzr, but need to figure out if its the fix or not, hard to say without a crash file or a backtrace, but I suspect I know what is going on
<dupondje> mvo: cjwatson: wasn't that because apt transition ?
<mvo> dupondje: the issue in the i386 version should, but this one looks different, I suspect its a divide by zero, but its a bit funny since that code is there since the dawn of time unchanged
<Laney> tumbleweed: mine contains nigelb's
<Laney> probably as you found
<cjwatson> dupondje: random trap crashes aren't due to transitions
<cjwatson> (in general)
<dupondje> cjwatson: aptitude was crashing here also yesterday for some odd reason, after upgrades it was fixed :)
<dupondje> so thats why I tought about this
<cjwatson> dupondje: I wuld advise against just chalking things up to transitions unless they are dependency problems
<brendand> hi - i really want to use sdptool in one of my scripts, but since the output is progressive, it seems impossible to capture the output to a variable in a bash script
<brendand> has anyone here seen anything like that before/know how to deal with it?
<cjwatson> normally you need to get the maintainer of the program in question to add an output format that's friendlier to machine parsing
<cjwatson> unless I'm misunderstanding you
<brendand> cjwatson - maybe that's it
 * brendand asks in #bluez
<dupondje> https://launchpad.net/ubuntu/+source/eiciel/0.9.8.1-2 => can somebody hit the rebuild button ?
<dupondje> thanks :)
<barry> dupondje: done
<ricotz> mvo, hello, it might be useful to change the Recommends of python-apt from python2.6 to python2.7
<barry> btw, are we still in an apt transition?
<dupondje> barry: could you kick https://launchpad.net/ubuntu/+source/libgphoto2/2.4.11-3 also ? ;)
<barry> dupondje: done
<yofel> hey, need some DSO linking help: digikam fails with http://paste.ubuntu.com/661962/ but as you can see on http://paste.ubuntu.com/661963/ it links against "-L/usr/lib -lgphoto2_port -L/usr/lib -lgphoto2 -lgphoto2_port -lm" so... what the hell is wrong?
<mvo> ricotz: indeed
<ricotz> mvo, perhaps even "python", but anyhow it would prevent pulling in python2.6 ;)
<ScottK> Since there will not be a python2.8, python2.7 is pretty safe.
<tkamppeter> mterry, hi
<mterry> tkamppeter, hello
<mvo> ricotz: fixed in bzr
<tkamppeter> lcms2 seems to be synced from Debian currently, should I introduce a Ubuntu delta for getting a symbols file?
<tkamppeter> mterry, ^^
<mterry> tkamppeter, for such things, I usually add a delta and submit the patch back to Debian.  I've never had someone reject a symbols file additions, so usually we can sync later
<mvo> barry: do you know about the state of python3 oauth? I was doing some research on what it takes to port software-center to python3 and the dependencies look actually pretty good, but for oauth there seems to be nothing there currently
<barry> mvo: hi.  i'm not aware of any py3 oauth work being done.  iirc, the oauth package isn't that big, so maybe that's a port we can take on?
<mvo> barry: indeed, I will do some research on this next
<barry> mvo: awesome.  let me know if i can help
<tkamppeter> mterry, I will add it.
<ricotz> mvo, thanks
<tkamppeter> mterry, symbols file added to lcms2 now, bug 823180.
<ubottu> Launchpad bug 823180 in lcms2 (Ubuntu) "[MIR] lcms2" [High,New] https://launchpad.net/bugs/823180
<mterry> tkamppeter, awesome, thanks.  I marked approved then
<barry> mvo: is apt still busted?
<mvo> barry: is it?
<mvo> barry: what kind of issue do you see?
<tkamppeter> mterry, can you have a look at argyll (bug 821883). didrocks rejected it due to its size, and now I am in doubt whether we can continue with adding color management support (argyll delivers the support for calibration devices).
<ubottu> Launchpad bug 821883 in argyll (Ubuntu) "[MIR] argyll" [High,Invalid] https://launchpad.net/bugs/821883
<tkamppeter> mterry, I have updated argyll and merged argyll with libicc as they come from the same upstream project. Should we perhaps do as alternative, if we cannot take argyll this cycle, the source package of argyll into main, so that it pulls libicc into main but leave the binary package argyll in Universe (or perhaps in main but not on CD)?
<mterry> tkamppeter, I'm not terribly familiar with argyll, but if the profiles can be split out so the size isn't a problem without killing functionality, then that would be good.  But didrocks can help with this, he's doing the argyll MIR
<tkamppeter> mterry, problem is also that I do not see any .icc files in argyll.
<tkamppeter> mterry, and of the stuff in /usr/bin I do not know what to split out.
<barry> mvo: http://pastebin.ubuntu.com/662020/
<jml> apt-file seems to be looking in the wrong place for Contents files.
<mvo> barry: oh, what mirror are you using? is it maybe lacking behind?
<jml> Ignoring source without Contents File:
<jml>   http://archive.ubuntu.com/ubuntu/dists/oneiric/main/Contents-amd64.gz
<jml> rather than, say, http://archive.ubuntu.com/ubuntu/dists/oneiric/Contents-amd64.gz
<barry> mvo: us.  cool, i'm about to head out for lunch, so hopefully it'll catch up by then :)
<barry> thanks
<tjaalton> cjwatson: I'm preparing an SRU for grub-gfxpayload-lists in natty, is '0.2~natty1' a valid version number for it?
<geser> jml: where does Debian put those files? perhaps LP has to adopt to the new location where apt-file expects them
<cjwatson> tjaalton: let's get out of the habit of using codenames; we're halfway to the point where they won't sort correctly when we wrap round the alphabet
<tjaalton> cjwatson: heh, right. so '0.2.1' would be ok then?
<cjwatson> 0.2.1 would be fine, yes
<cjwatson> 0.2~natty1 would be rejected due to being lower than the version in the archive anyway :)
<tjaalton> yeah I was wondering about that..
<cjwatson> geser,jml: yeah, I think Debian may have recently moved to per-component Contents files
<cjwatson> fun :-/
<debfx> mterry: there is a typo in the libsigsegv2 symbols file which causes gawk to be uninstallable
<mterry> debfx, oh man, k.  what's the typo?
<debfx> libsigsev2 instead of libsigsegv2
<mterry> doh
<mterry> I'll fix it
<cjwatson> hah, I wondered about that but hadn't looked yet
<tjaalton> cjwatson: doesn't this look ok to you?-) http://bazaar.launchpad.net/~tjaalton/ubuntu/natty/grub-gfxpayload-lists/bug-777212/revision/6
<ubottu> Ubuntu bug 6 in Launchpad itself ""next 10 entries" at bottom of page" [Medium,Invalid]
<tjaalton> hah
<Pici> weird.
<tjaalton> cjwatson: duh, should've used -proposed
<cjwatson> tjaalton: looks good to me
<tjaalton> cjwatson: thanks, I'll push the version with natty-proposed to the natty branch, and upload it to the archive
<mvo> barry: for when you are back, https://code.launchpad.net/~mvo/+junk/python3-oauth contains my fiddling, python3 oauth/example/server3.py and in a different terminal oauth/example/client3.py work except the last step (but you first need to bzr-buildpackage and install the python3 debs). looks like some craziness with the str/bytes in the hash, I'm not sure yet what the best approch for this is
<mvo> but dinner first :)
<zyga> mvo, ping me after dinner please
<tjaalton> cjwatson: looks like I can't push the branch to the proper place, so I've updated my own branch and uploaded it to natty-proposed
<bdmurray> Could I get kerneloops uploaded? http://people.canonical.com/~brian/tmp/kerneloops_0.12+git20090217-1ubuntu14.debdiff
<mvo> zyga: its probably going to take a while, best is if you just msg me
<zyga> mvo, quick feedback: c-n-f has some patches coming, trunk was in a bad shape, I just created a new branch from the core-dev branch you maintained, created a development team with you and me in the initial set
<zyga> mvo, the goal is to get those bugs fixed and landed in trunk, invite more people to the -developers team and move the project
<mvo> zyga: wooooh, awsome!
<zyga> mvo, :-)
<bdmurray> SpamapS: did you sort out how to create an apport package failure?
<SpamapS> bdmurray: yes
<bdmurray> SpamapS: and the answer is?  I'd like to try one now
<SpamapS> bdmurray: Oh I just made a postinst that intentionally crashes.
<SpamapS> bdmurray: for iterating it was easier to just  use 'apport-bug pacagename' tho
<bdmurray> SpamapS: right I was sure if you were trying to create a ProblemType of Package or just Bug
<bdmurray> er wasn't sure
<SpamapS> bdmurray: I thought it mattered but it didn't. :)
<debfx> could someone please upload a no-change rebuild of gawk to make it installable again
<debfx> there was a typo in libsigsegv which has been fixed now
<infinity> debfx: Has nothing else built against that broken libsigsegv?
<debfx> infinity: nope
<debfx> oh, there is one
<debfx> gnu-smalltalk
<debfx> I'll fix that one
<infinity> Alright.  I'll bounce gawk.
<infinity> Just double-checked on ftpmaster, and gawk and libgst7 are definitely the only two broken on all 4 arches.
<debfx> infinity: thanks
<infinity> debfx: NP.
<infinity> https://launchpad.net/ubuntu/+source/gawk/1:3.1.8+dfsg-0.1build1
<davmor2> tremolux: hey dude, just clocked this on my netbook. https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/823534
<ubottu> Ubuntu bug 823534 in software-center (Ubuntu) "USC gtk3 banner seems over size on a netbook" [Undecided,New]
<davmor2> tremolux: I've added a screenshot for you, display size is 1024x576
<lifeless> urgh
<lifeless> could someone reland my fix for https://bugs.launchpad.net/ubuntu/+source/apt/+bug/816606
<ubottu> Ubuntu bug 816606 in apt (Ubuntu) "apt postinst failure if ubuntu-keyring not installed" [Critical,Triaged]
<infinity> erk.
<infinity> lifeless: Re-applied.
<lifeless> infinity: thanks
<slangasek> infinity: will you poke mvo to figure out how it got dropped?  maybe he's using a bzr branch not listed in the Vcs-Bzr field?
<infinity> slangasek: Yeah, I will.
<slangasek> ta
<infinity> (Though, I do consider "this isn't in my VCS" to be a copout for not checking changes on a merge)
<infinity> But in this case, I suspect it was just him switching between sid and experimental and not really being fully awake.
<lifeless> he had the changelog for the change
<lifeless> so it wasn't an overwrite.
<slangasek> ah
<slangasek> infinity: if you're doing the merge *via* the VCS, and the VCS is documented in debian/control, I think it's a perfectly reasonable position :)
<lifeless> possibly a mistaken conflict resolution, or even a merge that was confused
<infinity> slangasek: The VCS is not the authoritative source, the archive is.  So, I'd be inclined to disagree that people shouldn't at least do a cursory check to see if they match.
<infinity> slangasek: But I realise there are forces at work that insist my position should be invalidated.
<infinity> slangasek: (Either way, in this case, I'm pretty sure it was just the violent sid->experimental merge that made him drop a few bits on the floor)
<jamespage> any archive admins around?  if so please could the NEW binary packages for maven-stapler-plugin and stapler-adjunct-timeline be accepted into oneiric - thanks
<slangasek> jamespage: looking
<slangasek> jamespage: maven-red-swingline-stapler accepted
<jamespage> slangasek: thankyou!
<soren> Hm... When I try to get my proxy settings in Chrome or Chromium after upgrading to Oneiric, it gives me the GNOME proxy settings page rather than Chrome's (or Chromium's) own and the proceeds to ignore what I've set in there.. I've no clue where to start debugging that. Any ideas?
<seb128> soren, is chromium reading the gconf database and GNOME3 writting to gsettings?
<seb128> soren, the second part is not a question but I don't know if chromium try gsettings before gconf
<seb128> soren, which is likely to be the issue there
<soren> seb128: I'm trying to work out how it decides where to look.
<seb128> soren, set the gconf key using gconf-editor and see if it makes it work?
<soren> seb128: I see support for both, but it somehow decides which to use.
<soren> seb128: Hm... Maybe I'm not setting the right values in gconf.
<soren> Or it's ignoring both.
<soren> Weird.
<soren> seb128: Good suggestion, though. :-/
<soren> Is there an equivalent to gconf-editor for gsettings?
<Daviey> soren: dconf-editor ?
<soren> Daviey: I thought dconf and gsettings where different things?
<Daviey> soren: try it, i might be way off base tho.
<Daviey> <-- not Desktop :)
<soren> Daviey: Hmm...
<soren> dconf-editor is from dconf-utils..
<Daviey> jah
<soren> which depends on a bunch of stuff, including:
<soren> dconf-gsettings-backend | gsettings-backend
<soren> So there's certainly some connection.
<soren> Oh!
<Daviey> soren: We are 10meters away, why are we talking on irc?
<soren> dconf is a low-level configuration system. Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems.
<soren> Daviey: Shouting would be rude?
<Daviey> true.
<soren> And futile, I imagine. The sound proofing job on this room is uncanny.
<soren> Daviey: I stand corrected.
<TheMuso> d/c
#ubuntu-devel 2011-08-10
<ion> foomatic-filters (main) seems to recommend colord (universe).
<RAOF> colord's MIR is in progress.
<ion> alright
<RAOF> ion: It's bug #823185 if you're interested.
<ubottu> Launchpad bug 823185 in colord (Ubuntu) "[MIR] colord" [High,New] https://launchpad.net/bugs/823185
<ion> raof: Thanks, had already found it.
 * slangasek wonders where the 300K for the new packages is supposed to come from
<RAOF> I think the plan was to upload a sentient virus to change all the CD burning software in the world to allow an extra 300K overburn.
<lifeless> slangasek: -Os ?
<ion> Write the note âplease send a terminator back in time to change the CD standard to be 300 kilobytes largerâ and put it into a time capsule titled âto be opened when we have terminators and time travel technologyâ.
<slangasek> lifeless: I'll get right on that :)
<RAOF> We'll actually get some space back once we switch off the cairo-gl backend, since that's pulling in an EGL stack.
<micahg> cjwatson: MoM seems to be broke again
<mvo> micahg: it appears its having trouble with tar.xz
<micahg> mvo: ok, anything I can do to help fix it?
<lifeless> mvo: good morning
<lifeless> mvo: we noticed a regression in your merge of apt from experimental; that one was fixed but there may be others - just a heads up
<mvo> micahg: I ask the admins to install xz-utils, that may be enough already
<mvo> lifeless: what kinds of issus exactly?
<micahg> mvo: thanks
<mvo> lifeless: the install crash regression is fixed I believe?
<lifeless> mvo: the fix for bug 816606 was backed out, but the changelog entry for it kept.
<ubottu> Launchpad bug 816606 in apt (Ubuntu) "apt postinst failure if ubuntu-keyring not installed" [Critical,Fix released] https://launchpad.net/bugs/816606
<lifeless> mvo: and yes, the fix has been reapplied; just letting you know in case whatever caused that has affected other things we had
<mvo> lifeless: uhh, ok, I check it out, this looks like it was not merged into the ubuntu bzr branch ? and thus got lost on the upload :/
<lifeless> mvo: well the debian/changelog entry for it was kept.
<lifeless> mvo: which is really weird :)
<mvo> indeed
<lifeless> at least according to LP
 * mvo checks his code
<mvo> lifeless: hrm, so bzr log lp:ubuntu/apt|head gives me 0.8.15.1ubuntu2, and the vcs-bzr header of the upload points to the debian branch, so infinity could not know that there is actually a lp:~ubuntu-core-dev/apt/ubuntu branch. I fixed the vcs header now and will manually merge the upload into this branch now
<mvo> lifeless: thanks for the heads up
<lifeless> no worries
<micahg> cjwatson: unping, mvo filed a ticket
<slangasek> does anyone here understand this warning from g-ir-scanner?:
<slangasek> peas-extension.c:190: Warning: Peas: peas_extension_callv: argument args: Unresolved type: 'GIArgument*'
<slangasek> (I'm trying to resolve totem consistently segfaulting on amd64; looks like a failure to pass arguments in a 64-bit-clean fashion, and that's one of the few warnings in any build logs that look promising)
<micahg> sounds like an --as-needed failure
<slangasek> micahg: how would --as-needed be involved?  This is gobject-introspection...
<slangasek> and it's a failure to resolve a type, not a symbol
<slangasek> (you could be right, I just don't understand how - gobject-introspection is pretty opaque to me)
<micahg> well, does the linker do the same thing with types as it does symbols?
 * micahg apologizes if the question is silly
<slangasek> micahg: no, because the linker doesn't have visibility to anything that's not a symbol
<slangasek> note that this is the output of running g-ir-scanner on the source; doesn't actually invoke binutils or gcc at all
<micahg> ah, ok, well, then I should probably be quiet as I don't know how g-ir-scanner works
<slangasek> AIUI, g-ir-scanner is part of the toolchain that outputs a language-neutral description of the interfaces, including details like argument types, sizes etc
<slangasek> that description gets compiled into an architecture dependent 'typelib' file
<slangasek> you'd think it would still figure out the right thing to do with a generic pointer argument... but who knows
<micahg> is there a missing include somewhere?
<slangasek> probably :)
<slangasek> oh, the problem is much simpler
<slangasek> GPOINTER_TO_UINT
<slangasek> stab
<slangasek> why does that macro even exist
<slomo> slangasek: because of the inverse macro... GUINT_TO_POINTER
<slomo> slangasek: http://developer.gnome.org/glib/unstable/glib-Type-Conversion-Macros.html has an explanation why this macro is necessary at all
<slangasek> slomo: right - so where do people get the idea that this is the right thing to use for casting to GType?
<slangasek> this is the single most common 64-bit error I find in GNOME software over the past few years
<slangasek> so someone is perpetuating stupid-broken code, and I'd like to get to the bottom of where that's coming from
<slomo> slangasek: i don't know, i never saw this error and the docs of these macros have warnings everywhere to prevent people from doing stupid things like this :)
<slangasek> sigh
<slangasek> slomo: ok, thanks :/
<slangasek> I think part of the problem is that GType is deliberately set up as an opaque integer type
<slangasek> so it's not obvious to the novice that it shouldn't be treated as a uint
<pitti> Good morning
<micahg> hi Pici
<micahg> oops
<micahg> hi pitti
<ajmitch> morning pitti
<euroford> good afternoon -:)
<micahg> is it ok to close bugs in a meta upload?  I know the changelog isn't usually modified manually
<pitti> micahg: sure
<pitti> micahg: it's totally fine to adjust the changelog
<micahg> pitti: ok, thanks, and thanks for fixing cups in the common seed
<micahg> I was going to ask about foomatic, but I noticed that cups is now a recommends on all those packages instead of a depends
<kural> How is it decided that X version of Ubuntu will be LTS ? Any info folks
<micahg> kural: discussion at UDS generally
<kural> micahg : thanks
<kural> I was porting some personal app , was wondering whether oneric would be LTS ?
<StevenK> kural: Oneiric will not be an LTS
<kural> StevenK: thanks . So i guess i should stick to 10.04
<micahg> kural: maybe I misunderstood the question, there's an LTS release every 2 years, 12.04 will be the next one
<kural> most likely my question was not asked properly. But you gave me the answer. Thanks . Thanks all.
<matttbe> Hello,
<matttbe> I'm looking for a sponsor in order to upload 3 packages before the feature freeze (sorry to be a bit late :-/) in universe: cairo-dock, cairo-dock-plug-ins and latexila.
<matttbe> All these 3 packages are beta versions (they are almost stable but perfectly usable!) and their stable versions are expected for September.
<matttbe> I've opened 3 bug reports linked to 3 bzr branches with 3 merge proposals:
<matttbe> LP: #823513
<matttbe> https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/823513
<ubottu> Ubuntu bug 823513 in cairo-dock (Ubuntu) "Please update Cairo-Dock to 2.4.0~0beta2 version (before the FF)" [Undecided,New]
<matttbe> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/823514
<ubottu> Ubuntu bug 823514 in cairo-dock-plug-ins (Ubuntu) "Please update Cairo-Dock Plug-Ins to 2.4.0~0beta2 version (before the FF)" [Undecided,New]
<matttbe> https://bugs.launchpad.net/ubuntu/+source/latexila/+bug/823566
<ubottu> Ubuntu bug 823566 in latexila (Ubuntu) "Please update LaTeXila to 2.1.1 (= 2.2.0 beta) version (before the FF)" [Undecided,New]
<matttbe> 'bzr merge-upstream' has been used to commit these revisions on these bzr branches and they should be ready to be uploaded on universe.
<matttbe> I've compiled them with pbuilder and test it on Ubuntu Oneiric with a liveUSB
<jamespage> good morning
<jamespage> if there is an archive admin around please could the NEW binary packages for maven-hpi-plugin be accepted into oneiric.
<jml> cjwatson: btw, re that apt-file Contents location thing. Should I file a bug somewhere? (If so, where?)
<cjwatson> jml: I guess apt-file to start with, since we probably don't have time to fix this in LP before beta
<cjwatson> jml: it'd be good to track down the relevant bit of apt-file changelog, as well as the exact change made to dak
<jml> cjwatson: ok. thanks.
<dupondje> jml: whats the issue with apt-file ?
<jml> dupondje: it seems to be looking for Contents files underneath component directories, but they don't exist in the Ubuntu archive.
<dupondje> that got fixed ?
<jml> when?
<jml> it's possible I'm running days-old code
<dupondje> https://launchpad.net/ubuntu/+source/apt-file/+changelog last change :)
<jml> dupondje: right. I guess I am running days old code :)
<jml> dupondje: thanks for the fix
<dupondje> np
<dupondje> it went wrong after the last accidential sync :)
<dupondje> reported a bug in debian also to make a patch so it has a fallback in debian, so we can sync again
<jjardon> Hi, in oneiric, gconf is compiled with or without orbit support?
<pitti> jjardon: without, I think, it's using dbus now
<jjardon> pitti: great, do you detect any special bug?
<jjardon> I'd like to propose dbus by default upstream
<pitti> jjardon: not that I noticed
<pitti> it largely went unnoticed, I'd say
<jjardon> those are good news, thanks pitti !
<chrisccoulson> jjardon, yeah, i switched on dbus support a few weeks ago
<chrisccoulson> i don't think anybody really noticed ;)
<dupondje> mmm cjwatson, you synced 'pino', but it seems still not visible on launchpad? Wasn't the delay quite minimal ?
<cjwatson> mterry: do you think I might be able to go ahead and promote ndisc6 for bug 806723?  I've uploaded a fix to address Kees' concerns
<ubottu> Launchpad bug 806723 in ndisc6 (Ubuntu) "[MIR] ndisc6" [Undecided,Incomplete] https://launchpad.net/bugs/806723
<cjwatson> dupondje: flushing the syncs is a separate step and sometimes it takes me a while to come back to the relevant window
<dupondje> ah ok :)
<cjwatson> I'll do so in a moment, there's just one of the syncs I want to check
<dupondje> btw, little remark, for pino there was a sync requested of 0.2.11-7 , but now in debian there is 0.2.11-9, so this got synced. This isn't an issue now, but could be for some other syncs.
<cjwatson> yes *shrug*
<cjwatson> I looked at it and verified that it was OK
<cjwatson> I can't easily sync non-current versions
<cjwatson> and I also can't go back in time and arrange to have done the sync run earlier
<dupondje> hÃ©hÃ© ok :)
<cjwatson> flushing the syncs now
<dupondje> thanks for the work :)
<mterry> cjwatson, let me look
<mterry> cjwatson, sure
<cjwatson> mterry: great, thanks
<zyga> mvo, could we somehow split c-n-f bugs from c-n-f database inaccuracy bugs?
<mterry> doko, ping, got a MIR reasonability question to bounce off you
<mterry> kees, oh you're here too
<mterry> kees, doko: it seems like a giant red flag to me, but just to make sure I'm not being too harsh, wanted to know what ya'll thought of a package embedding its own (apparently modified) copy of libusb instead of using the system one
<mterry> I can't find any security history for libusb, so it doesn't seem like a particularly dangerous library, but still.  I imagine it could have problems
<baltix-linux> ev: hi, could you tell me how you build wubi executables for windows? It seems you are building wubi, I found wubi.exe at your page - http://people.canonical.com/~evand/wubi/lucid
<ev> baltix-linux: bzr branch lp:wubi; cd wubi; make
<baltix-linux> I need to build wubi for Lucid based distro, I do bzr branch lp:~ubuntu-installer/wubi/lucid , right?
<doko> mterry: as long as it's not used for the build ...
<baltix-linux> ev: I need to build wubi for Lucid based distro, I do bzr branch lp:~ubuntu-installer/wubi/lucid , right?
<ev> yes
<baltix-linux> ev: I  get lots of Wine dialogs, I should just press next and finish ?
<infinity> mterry: If it's in the source, that's no big deal, if it's being statically linked in the build, then yes, that's a big no-no.
<mterry> doko, it is used for the build
<mterry> infinity, that's what I thought
<infinity> A big no-no that's probably easily fixed, but they should fix it before we move it to main, not after. :P
<baltix-linux> ev: hehe, wubi buiding doesn't work if LANG=lt_LT.UTF-8 but when I set LANG to en_US then make works almost without errors :)
<baltix-linux> ev: I get only one error:   File "Z:\home\mantas\Atsiuntimai\wubi\build\version.py", line 2
<baltix-linux>    revision =                ^ SyntaxError: invalid syntax
<ev> did you edit that by hand?
<baltix-linux> ev: no, I just changed max_iso_size=3900000000 and min_disk_space_mb=4000 in data/isolist.ini
<baltix-linux> ev: sorry, I understand where is the problem - I've copied sources to another folder and didn't copied hidded .bzr folder ;)
<ev> ah, yeah, it needs to be in a bzr branch to determine the version number
<baltix-linux> ev: thanks for helping, I tried dpkg-buildpackage command and this didn't work :)
<ScottK> slangasek: I needed exactly your hplip fix on scribus today.  Thanks for making it easy.
<slangasek> ScottK: sure :)
<ev> baltix-linux: sure thing
<SpamapS> slangasek: If you have a moment some time today, the upstart package branch needs, I think, some love..  I'm not sure if we can keep the current one .. may need to back up and start over with import-dsc's.
<zyga> how can I aggregated my blog on planet.ubuntu.com
<highvoltage> zyga: instructions are on https://wiki.ubuntu.com/PlanetUbuntu
<zyga> highvoltage, thanks
<ogra_> cjwatson, another livecd-rootfs question, my build fails with "ls: cannot access vmlinu?-*: no such file or directory" ... looking at the code, you added:
<ogra_> KVERS="$( (cd "binary/$INITFS"; ls vmlinu?-*) | sed -n "s/^vmlinu.-\\([^-]*-[^-]*-$FLAVOUR\\)$/\\1/p" )"
<ogra_> to me that looks like it searchs for the versioned vmlinuz file in /
<ogra_> or do i misread that code ?
<hallyn> micahg: hey, regarding kvm-pxe and ipxe.  If it's meant to replace kvm-pxe, then should we (a) mark it as conflicting with kvm-pxe, and then (b) copy the roms into the same places where kvm-pxe puts them?
 * ogra_ would expect /boot somewhere in either the cd or the ls
<cjwatson> all I can tell you is it worked at the time :)
<hallyn> (Then we can mark qemu-kvm as depending on ipxe;  right now, you have to manually specify the option rom location on kvm command line for it to work)
<ogra_> heh, k
<cjwatson> feel free to extend as long as you keep x86 working
<cjwatson> maybe it needs to check /boot on some architectures, indeed
<ogra_> ah, infinity just educated me, seems $INITFS is supposed to contain boot/
<hallyn> rsalveti: hey, on bug 823711, what do you mean by repo out of sync?  do you think a rebuild will succeed?
<ubottu> Launchpad bug 823711 in libvirt (Ubuntu) "libvirt version 0.9.2-4ubuntu8 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/823711
<kirkland> barry: ping
<rsalveti> hallyn: yeah, I'll try to rebuild it in a few hours once my panda is up, will post the result at the bug
<hallyn> rsalveti: cool, thanks
<kirkland> doko: barry: could one of you guys look at: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/816169 ?
<ubottu> Ubuntu bug 816169 in ensemble (Ubuntu) "When using Ensemble, add-apt-repository no longer functions properly" [Critical,Confirmed]
<kirkland> doko: barry: this is blocking some other work in a strange way
<barry> kirkland: that sure looks weird.  my plate's a bit full, but i can look at this later today
<kirkland> barry: thanks
<kirkland> barry: it's affecting iamfuzz and adam_g;  I'm playing triage/go-between here
<kirkland> barry: can you just do one quick thing ... crack open /usr/lib/python2.7/encodings/__init__.py and look at lines 123-133 ... do you see any syntactical errors there?
<barry> kirkland: it looks ugly, but legal, and...
<barry> % python2.7 -c 'import encodings; print encodings.__file__'
<barry> /usr/lib/python2.7/encodings/__init__.pyc
<kirkland> barry: okay ... thanks
<barry> oh, that may not be a good test, but yeah, it looks legal to me
<ogra_> cjwatson, hmm somehow the merge of alisons usb image seeds makes greminate explode for me with a key error 'usb-langsupport'
<ogra_> *germinate
<cjwatson> ogra_: yes, I just fixed that
<cjwatson> er
<cjwatson> for real this time.  try again
<ogra_> heh, k
<ogra_> nope
<ogra_> not on sycamore at least
<ogra_> same key error
<cjwatson> it might take a few minutes to sync
<ogra_> (dunno, it seems to pull from internal)
<ogra_> yeah, thats what i thought
<cjwatson> try now, it looks like it's synced
<ogra_> i'll give it 10min
<ogra_> ok
<cjwatson> it pulls from http://people.canonical.com/~ubuntu-archive/seeds/, which is on a */5 cron job
<ogra_> oh, new error now
<ogra_> grr, why cant i copy/paste from w3m
<ogra_> Germinate.tsort.GraphCycleError: Cycle in graph .... hmm, thats cut off
<cjwatson> wow
<cjwatson> been a while since I saw that error
<cjwatson> I'll get the failure mail and will look at it
<ogra_> well, i'm playing with ubuntu-server-ac100 on sycamore if you want to see the whole traceback
<ogra_> ah, indeed
<cjwatson> copy/paste from w3m> it has mouse support of its own; hold shift for c/p
<ogra_> forgot the mails
<cyphermox> bryceh_: around?
<ogra_> oh
 * ogra_ hugs cjwatson, you just filled a 10 year old gap !
<cyphermox> someone care to sponsor/review https://code.launchpad.net/~mathieu-tl/ubuntu/oneiric/ntrack/libnl3-build/+merge/70978 ?
<cyphermox> (please) ;)
<micahg> hallyn: well, I did check what Debian has done on the ipxe side, I just noticed the removal request
<micahg> s/did/didn't/
<hallyn> micahg: but as far as you're concerned, yo uwouldn't mind if we did that?
<micahg> hallyn: I honestly don't know enough about it to say, I never touched etherboot, just noticed that it needed merging and found out it was going to be removed
<hallyn> micahg: thx
<jtaylor> mterry: the soya sru you sponsored on 1. Aug has not reached proposed yet, is there something wrong?
<mterry> jtaylor, looking
<SpamapS> we're behind on SRU reviews
<SpamapS> I'll be doing a bunch shortly.. nearly done with my pre  FF stuff for the day. :)
<ahasenack> I guys, I have a question about an upload failure error: "File convoy_0.2.0~bzr14-0landscape2~bzr7~lucid1.tar.gz already exists in LDS Trunk, but uploaded version has different contents."
<Daviey> SpamapS: That sounded like an invitation for some more pre-FF work you need?
<ahasenack> it's from a launchpad recipe build: https://code.launchpad.net/~landscape/+recipe/convoy-lds-daily
<ahasenack> there were no changes to either branch (lp:convoy and lp:~landscape/convoy/debian-packaging
<ahasenack> )
<ahasenack> I'm thinking the changelog got included in the tarball, and that has an automatically generated entry by the recipe, so that could explain why the tarball has different contents
<SpamapS> Daviey: I'd be more than happy to stuff MySQL 5.5 into the NEW queue before tomorrow.. :-D
<mterry> jtaylor, yeah, as SpamapS says, it was uploaded and is just waiting on approval
<jtaylor> k
<tgardner> is 'apt-get trap divide error' a known problem with the oneiric installer? it happens consistently in base-installer/kernel
<azop> tgardner: looks that way
<azop> fixed in apt 0.18.16-exp5ubuntu3 according to #8232777
<slangasek> SpamapS: import-dsc> are there inconsistencies in the contents wrt what's been uploaded, or is it just the pristine-tar data missing for 1.3 that you're concerned about?
<slangasek> SpamapS: currently attempting another merge-upstream null-merge, which should be enough to get on with I think
<tkamppeter> mterry, hi
<achiang> when does debian import freeze normally occur within a release cycle?
<achiang> oh, i found it -- https://wiki.ubuntu.com/OneiricReleaseSchedule
<mterry> tkamppeter, hi.  I saw your libicc request.  I'm getting to it
<tkamppeter> mterry, OK.
<bryceh_> @pilot out
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: open for business | Development of Ubuntu (not support, not app development) | #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:
<mdeslaur> pitti: so, does anything still use gksu on the desktop cd?
<mdeslaur> pitti: I just noticed software-properties doesn't anymore
<brendand> hi
<brendand> anyone else not able to login on oneiric?
<micahg> mdeslaur: gparted?
<mdeslaur> micahg: hmm...that's on the cd?
 * micahg thought it was
<kees> hallyn: hi! do you mind if I build qemu-kvm with PIE?
<hallyn> kees: will it break?  :)
<kees> hallyn: I don't think so -- testing now
<mdeslaur> hallyn: well, it'll be secure :P
<hallyn> bullocks :)
<mdeslaur> lol
 * hallyn points to that big ugly graphics driver over thar
<hallyn> kees: i've got no objection, thx.  i'm curious if it'll slow anything down
<ara> barry, we are preparing a checkbox upload, will you be able to sponsor it?
<barry> hi ara; i could do it
<ara> thanks barry!
<ara> barry, I will let you know when it is ready
<barry> sounds good!
<kees> lamont: say, can you get dnssec validation into bind9? it'd be nice to have that in oneiric by default...
<kees> lamont: (i.e. by tomorrow...)
<micahg> mdeslaur: checkbox is also using gksu
<mdeslaur> micahg: ah, thanks
<bdmurray> so looking at bug 450347 we can see 'pycentral pkginstall: not overwriting local files' - that's not really our (Ubuntu's) fault is it?
<ubottu> Launchpad bug 450347 in twisted-web (Ubuntu) "package python-twisted-web 0.7.0-1build1 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/450347
<lamont> kees: by tomorrow?
<lamont> sigh
<kees> lamont: hehe
<lamont> hate you all
<kees> lamont: it's just one small stanza :)
<lamont> kees: got a diff for me?
<kees> lamont: yeah, it's in the debian bug that has been open for 8 months. ;)
<lamont> cool
<lamont> I should read that
<kees> hehe
<kees> lamont: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516979
<ubottu> Debian bug 516979 in bind9 "bind9: Enable dnssec by default." [Wishlist,Open]
<kees> lamont: s/8 mon/2.5 years/ ;)
<lamont> those are nearly equal, no?
<ara> sorry barry, it is taking a bit longer than expected (fails to build), we are fixing it
<barry> no problem ara
<ara> just to have everything prepared, as lp:ubuntu/checkbox is sync with lp:checkbox, once we have lp:checkbox ready to be merge, do we need to open a sync bug?
<ara> or just tell you that it is good to go?
<barry> ara: once those two branches are sync'd, i think we're good to go
<ara> OK, thanks
<mdeslaur> pitti: gaaah...you can't launch a setuid binary from a .desktop file...pkexec won't run :P
<mdeslaur> pitti: I guess I need a wrapper
<cr3> when requesting a candidate for upload in main, should reporting a bug against the ubuntu project and requesting a merge request be sufficient, or should I also subscribe ubuntu-sponsors to the bug?
<micahg> cr3: merge proposal against an ubuntu branch is a sponsorship request, as long as the branch is linked to the bug, no need to subscribe sponsors to it
<slangasek> cr3: more details: https://wiki.ubuntu.com/SponsorshipProcess
<SpamapS> slangasek: I'm not sure I understand what a null merge is..
<SpamapS> slangasek: but it would be nice if there were a documented way to resolve the missing pristine-tar bit
<slangasek> SpamapS: stitching in the upstream tarball without (in theory) changing the current branch state.  In this case, since the upstream bzr branch had also been merged and only the pristine-tar was missing, the command looks like this: bzr merge-upstream --last-version=0.9.7 --version 1.3 /mirror/ubuntu/pool/main/u/upstart/upstart_1.3.orig.tar.gz
<cr3> thanks folks!
<SpamapS> slangasek: *OH*
<SpamapS> slangasek: thats quite useful information.. I always wondered how to do that. :)
<slangasek> SpamapS: I say in theory because the batch of merge conflicts it spit out led me to accidentally commit something that didn't quite match what should've been, so there are two commits where there should've been one :P
<lifeless> bdmurray: ping
<lifeless> bdmurray: whats the test for 'filed by apport' ?
<bdmurray> lifeless: tag = apport-bug or apport-package or apport-crash
<lifeless> bdmurray: any of ?
<bdmurray> lifeless: so searchTasks with tags 'apport-crash' and 'natty'
<bdmurray>             tasks = ubuntu.searchTasks(status=STATI, tags=search_tags,
<bdmurray>                 tags_combinator='All', created_since=release_date)
<lifeless> ok, hang a sec
<bdmurray> I've actually got to run soon
<bdmurray> and STATI = any status
<lifeless> ah, they are tags not series tasks ?
<lifeless> do you need up to minute, or will staging data be ok ?
<bdmurray> staging would be fine, thanks
<lifeless> bdmurray: sent to the list.
<ScottK> lamont: FYI there was whining about no multi-instance support in Debian/Ubuntu on postfix-users today.  You know which release team member to ask about an exception, right?
<lamont> ScottK: you?
<ScottK> If you want it approved, yes.
<ScottK> ;-)
<ScottK> It would be nice to get in and making it reasonably regression safe ought to be doable.
<ScottK> Alternately upload before 1800 UTC tomorrow and then bugfix as needed ...
<matttbe> Hello,
<matttbe> I'm looking for a sponsor in order to upload 3 packages before the feature freeze (sorry to be a bit late :-/) in universe: cairo-dock, cairo-dock-plug-ins and latexila.
<matttbe> 3 bzr branches have been created. 'bzr merge-upstream' has been used to commit these revisions on these bzr branches and they should be ready to be uploaded on Universe.
<lamont> ScottK: I have bind9 tonight, and will look at postfix either tonight or sunday
<micahg> matttbe: it's in the sponsorship queue, asking in multiple channels per hour, I don't know how helpful that is
<ScottK> lamont: Very cool.  Thanks.
<matttbe> micahg: ok sorry for that
<slangasek> wendar: I'm surprised to see component mismatches in connection with the new USB seed (audacity, anjuta, frozen-bubble, wesnoth) - and don't remember those having been part of the discussion at UDS... can I drop those from the seed in the short term so we have something testable?
<cjwatson> FWIW the CD builder will just ignore stuff that's out of the components it's been told to look at
<slangasek> ah
<slangasek> ok, then I'm just left wondering about the rationale for the packages being promoted to main and put on the image :)
<RAOF> slangasek: Are you having problems installing libc6:i386?  Apt refuses to install it, and I find the debug messages inscrutable.
<slangasek> RAOF: it's a regression, doko accidentally dropped the M-A: same field in the latest merge from Debian
<slangasek> RAOF: we basically should just revert that part of the merge
<RAOF> Aha.
<slangasek> (Debian has dropped it over concerns about certain biarch+multiarch collisions causing libs in /lib to be overwritten... no one has reported this problem yet in Ubuntu, and the fix is known, so we should just roll with it)
<slangasek> RAOF: if you want to fix eglibc up for this, you have my blessing; otherwise it probably has to wait for doko's morning
<RAOF> slangasek: I'm happy to remain not TIL on eglibc.  It's not urgent.
<slangasek> ok :-)
<slangasek> barry: btw, how do you feel about me making libpython2.7 multi-arch: same this cycle ;P
#ubuntu-devel 2011-08-11
<poolie> is there some trick necessary to make pbuilder use a mirror when creating the chroot?
<poolie> other than putting it in pbuilderrc
<lifeless> IIRC yes, patch it to not splat over the variables
<lifeless> I *think* I filed the bug about it
<poolie> i don't see one in https://bugs.launchpad.net/ubuntu/+source/pbuilder
<poolie> maybe it's only in debian?
<lifeless> huh, maybe my memory is on the fritz
<StevenK> What? That is madness
<SpamapS> poolie: its dead simple to make sbuild use a mirror
<SpamapS> poolie: mk-sbuild --debootstrap-mirror=URL
<poolie> so you're suggesting i should avoid it by using sbuild instead?
<StevenK> I thought there was a --mirror option for pbuilder
<poolie> i have that set but it seems to only set the mirror inside the chroot, not the one that will be used by debootstrap
<poolie> imbw
<StevenK> --debootstrap-mirror, IIRC
<lifeless> export MIRRORSITE=http://mirror.internode.on.net/pub/debian/
<poolie> yes i have that in pbuilderrc
<lifeless> looks like the bug was fixed - thats what I have currently [in a pbuilder script I haven't used in since moving ...]
<poolie> ok, pbuilder works, but pbuilder-dist clobbers it
<hyperair> poolie: ping
<hyperair> poolie: regarding the banshee --debug log you posted, did it start working after you tried the patch, or without the patch?
<poolie> hello
<hyperair> https://bugs.launchpad.net/bugs/823723 <-- this oen
<ubottu> Ubuntu bug 823723 in banshee (Ubuntu) "banshee interface becomes unresponsive while playing radio stream" [Undecided,Incomplete]
<hyperair> although the bug for the --debug crash is https://bugs.launchpad.net/bugs/823956
<ubottu> Ubuntu bug 823956 in mono-addins (Ubuntu) "banshee --debug crashes with "Could not read add-in description"" [Undecided,New]
<poolie> sorry which patch?
<hyperair> the patch provided in the latter bug
<hyperair> on mono-addins?
<poolie> no, i' hadn't applied that, so apparently the crash is intermittent or environment dependent
<poolie> or something
<hyperair> ah, i see.
<hyperair> i'll post that in the bug
<poolie> could i get a review on https://code.launchpad.net/~mbp/ubuntu/oneiric/gnupg2/815190-assertion/+merge/71140
<RAOF> cjwatson: Should your debian-installer SRU to lucid have a bug report associated with it?  It looks sane apart from that.  Is there a different policy for d-i?
<SpamapS> heh
<SpamapS> I was just getting around to looking at it ;)
<SpamapS> and was going to ask the same thing. :-P
<SpamapS> RAOF: since you're just near EOD .. but I'm near EO-ability-to-keep-eyes-open .. I'll let you take it from here. :)
 * SpamapS passes out
<RAOF> Have fun in your exhausted dreams!
<hyperair> does anyone know how apport.hookutils.attach_gconf(pkg) works?
<hyperair> does it just look at /apps/<pkg>?
<pitti> Good morning
<hyperair> morning, pitti
<hyperair> do you know if apport looks into /apps/<pkg> or into any given schemas installed by a package <pkg>?
<pitti> mdeslaur: seems we still have some rdepends: gnome-codec-install, checkbox-gtk, update-notifier, gnome-system-log
<pitti> mdeslaur: weird that a suid binary needs gksu or pkexec in the first place?
<chrisccoulson> hi pitti
<pitti> hyperair: which schemas?
<pitti> hyperair: oh, I think we don't have a gsettings equivalent of "changed gconf keys" yet
<hyperair> pitti: i was actually looking into https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/823726
<ubottu> Ubuntu bug 823726 in banshee (Ubuntu) "apport hook fails: "package does not exist"" [Undecided,In progress]
<hyperair> which is a little tricky, because banshee's package name is banshee, but gconf key is /apps/banshee-1.
<pitti> hyperair: "ubuntu-bug 17978"?
<ubottu> Launchpad bug 17978 in linux-source-2.6.15 (Ubuntu) "ipw2200 kernel module working erratically in linux-image-2.6.10-5-686 version 2.6.10-34.2" [Medium,Fix released] https://launchpad.net/bugs/17978
<pitti> that package indeed doesn't exist :)
<hyperair> eh?
<hyperair> what?
<pitti> that's what the description says
<hyperair> ._.
<hyperair> it's that simple?
<RAOF> Morning pitti, chrisccoulson :)
<hyperair> pitti: no wait, you can ubuntu-bug a pid.
<hyperair> pitti: it could very well be banshee's pid
<chrisccoulson> hi RAOF
<pitti> hyperair: ah, right
<pitti> hyperair: apport.hookutils.attach_gconf(report, 'banshee-1')
<pitti> hyperair: so I suppose the banshee package hook calls that, which fails
<pitti> (sorry, don't have it installed ATM)
<RAOF> pitti: Just to confirm again - the packages we accept into foo-proposed should have a changes file containing all the entries from the current package in foo-updates/foo (depending on whether there's a foo-updates package yet or not), right?
<pitti> RAOF: correct
<infinity> Wait, what?
<infinity> Why would it need a changes file detailing changes from pervious versions?
<pitti> so that people who have only -updates actually see all the changes in the .changes, update-notifier, etc.
<pitti> and for a more technical reason, that the current .changes refers to all bugs which need verification in -proposed
<pitti> i. e. if you stack a -proposed upload on top of a previous -proposed upload, the second one needs to have both
<pitti> ... changelogs
<infinity> But that's now what he said.
<pitti> "from the last -updates upload on"
<infinity> He said it should have all the changes from previous -updates uploads.
<pitti> oh, I mis-attributed the "on"
<pitti> RAOF: right, so see above
<infinity> Okay, with the "on" tacked on the end, it makes more sense. :P
<pitti> RAOF: it shold only include pending stuff in -proposed, not stuff which is already in -updates
<pitti> or s/from/since/
<RAOF> pitti was reading it as I intended.
<RAOF> I just didn't ask the question properly :)
<infinity> RAOF: As for the d-i case you mention above, d-i rebuilds don't necessarily address bugs directly (at least, not one that bumps a kernel ABI, like the recent one), think of them like linux-meta uploads, which also don't need bugs associated with them.
<infinity> Alternately, I suppose they could reference every bug that the underlying d-i and/or kernel bits fixed, but that seems a bit redundant.
<RAOF> They therefore also need no verification?
<pitti> *nod*, d-i rebuilds are usually accepted without much of a changelog
<pitti> they just usually don't get tested
<pitti> and thus tend to stay aroud in -proposed forever
<RAOF> How do we track whether they are tested or not if there's no associated bug?
<infinity> They stick around in proposed often until we get around to testing them for a point release.
<infinity> RAOF: They get tested with image testing for point releases, often not until then.
<infinity> (And we move them up -updates as part of the release process, if required)
<brendand> how can i get a list of all packages that *should* be installed in oneiric?
<brendand> i say this because i recently found that i mysteriously had a ton of packages missing
<brendand> g-c-c, update-manager, command-not-found and several more
<brendand> and now i can't login and i'm wondering if it's because i'm missing something important
<RAOF> ubuntu-desktop should pull in basically everything you'd have.
<mvo> brendand: you can run "sudo apt-get install --fix-policy" to ensure you have all recommends installed
<mvo> brendand: especially during the devel release it may happen that recommends get missing
<brendand> mvo - you wouldn't happen to be having problems logging in on an up-to-date oneiric system?
<brendand> did both those steps, still no luck
<wendar> slangasek: the non-main packages added are the ones requested in the ubuntu-devel mailing list
<wendar> slangasek: I figure we'll do another round of discussion on the list with the question "do we care about these enough to promote them to main?"
<tjaalton> alpha3 installer crashed, does the daily image work?
<tjaalton> that would be a no, since only oversized  powerpc image exists
<Quintasan> Is anyone aware that flashplugin-installer update brok flash?
<Quintasan> hmmm
<Quintasan> Few users report flash missing after update, but when I reinstalled it, it worked
<cjwatson> RAOF: I haven't normally bothered for d-i updates, since they're so formulaic and generally just go with kernel ABI changes
<cjwatson> SpamapS: ^-
<cjwatson> ah, now I read more of scrollback ...
<ev> anyone mind terribly if I split camerabin{,2} out of gstreamer0.10-plugins-bad?
<ev> I'd like it for ubiquity without the mountain of deps that come with the rest of the package
<directhex> is that the package which pulls in DECnet support, for all loyal PDP11 users?
<ev> directhex: the very same!
<directhex> but what about the pdp11 port of ubuntu?
<ev> I'm afraid I'm too busy porting Ubuntu to the AS/400 to deal with any PDP11 concerns.
<sbte> Hi, I was just asked to sign the Canonical contributor agreement. Do I really have to print it and scan it back, or can i just type it out and copy my signature in?
<jjardon> Hi, Is evolution compiled with gnome-online-account support in oneiric?
<seb128> jjardon, no, but thanks for pointing it, we will fix that
<jjardon> seb128: ok, thanks!
<jjardon> seb128: also, seems that gnome-contacts is still not packaged
<seb128> jjardon, right, it's on our list, do you know if it's going to be part of GNOME 3.2?
<seb128> jjardon, it got only 2 tarballs and no update for over 5 weeks
<jjardon> seb128: thats probably because alex was in holidays
<jjardon> seb128: the plan is that It will be part of 3.2, yes : https://live.gnome.org/ThreePointOne/Features/Contacts
<seb128> ok
<seb128> jjardon, well I know if was listed there, but a new components which only got 2 tarball when we are close from freeze times doesn't give confidence to be shipped
<seb128> jjardon, it's also that it required vala 0.13 and we were still on 0.12 until recently
<seb128> jjardon, but I will have a look to it
<jjardon> seb128: I'll try to ask alex about the current status
<seb128> jjardon, thanks
<seb128> ev, doing a separate camerabin gst binary will not solve your issue
<ev> seb128: oh?
<seb128> ev, you will not get that codec set source promoted
<seb128> well you can try
<ev> set source promoted? I don't follow.
<seb128> but it's a pack of unmaintained and buggy codecs, I doubt mir will ack it
<ev> oh
<seb128> ev, you can't have a binary in main for a source in universe
<seb128> if you need that binary you will need to promote the source
<seb128> the way to go is to distro patch that code to good as we do for some of the stuff empathy video call needs
<seb128> it's annoying to maintain though
<ev> what code? To be clear, I'm layering on top of camerabin2, skipping the Cheese stuff entirely.
<ev> ah
<seb128> ev, well what we need is camerabin to be in the good source
<ev> right
<ev> okay
<ev> thanks for the spot
<seb128> yw
<mdeslaur> pitti: pkexec is the suid binary...
<mdeslaur> pitti: hrm...apport also still uses gksu
<pitti> mdeslaur: oh, for the root_command_output() stuff, right
<ttx> wendar: http://tlohg.com/building-a-consistent-hashing-ring-part-1 (and subsequent parts)
<doko> tkamppeter, about the icc-profiles MIR. you know that this package is in multiverse?
<pitti> doko: he mentioned he wants it promoted to restricted
<doko> pitti: not in the report. and do we want to have it in restricted? my guess is that it maybe would be better to split it into a free and non-free package. ubuntu doesn't have the absolute requirement of shipping in the preferred form or editing, afaik
<pitti> doko: I think it's meant to be installed on demand, so it doesn't matter much whether it's in restricted or multiverse
<pitti> doko: oh, it's missing source? depends on the library then
<pitti> s/library/license/
<pitti> if it's GPL and doesn't have preferred form of modification, it's a license violation, and we can't ship it at all in theory
<pitti> multiverse vs. restricted doesn't matter much there
<pitti> tseliot: I still have a WI "In jockey, display new X drivers from x-updates ppa"
<pitti> tseliot: I understand you want to upload the -updates stub packages to proper ubuntu now
<pitti> tseliot: so I suppose this WI shold be changed to "display new X drivers in -updates packages"?
<johnt> hello folks, can anyone help with a quick preseed question?
<cjwatson> johnt: probably
<tkamppeter> doko, yes, does it not go from Multiverse to Restricted with a MIR then?
<johnt> cjwatson: cool, thanks! im basically just trying to make the security update server bit match the server it is pointed at. as in, when i install the machine the lines in the sources.list dont seem to match the dir structure of the server i am pointing at...
<cjwatson> johnt: apt-setup/security_host and apt-setup/security_path are the usual things to tweak
<cjwatson> the former defaults to security.ubuntu.com and the latter defaults to /ubuntu
<tseliot> pitti: where's the code? In the ubuntu branch in bzr?
<tkamppeter> doko, as pitti says that icc-profiles is for optional installation anyway, we could leave it in Multiverse.
<doko> pitti, tkamppeter: some of the profiles have a rstriction on modification
<johnt> cjwatson: yeah, thats what im working on. just not sure what they should look like by looking at the mirror, if that makes sense. presumably the first one is literally just the name of the mirror with nothing appended?
<cjwatson> johnt: literally just the host name, yes
<doko> tkamppeter, pitti: is there already other printer stuff in restricted?
<cjwatson> johnt: which mirror?
<johnt> cjwatson: ok cool, so for the second one i just had "...security_path string /ubuntu" but that doesnt seem to have worked
<pitti> doko: not according to grep ^Package: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_oneiric_restricted_binary-amd64_Packages
<tkamppeter> doko, as far as I know, not.
<johnt> cjwatson: internal mirror :S
<pitti> doko: but as it's not a "real" driver, I agree with you that it's probably better to split it into a free and non-free part, and leave it in multiverse for now
<cjwatson> fair enough
<johnt> cjwatson: so, is there a way to work out what the path should be by looking at the dir structure on the mirror?
<doko> pitti: the reason that debian doesn't have color profiles in main, is that there is hardly any free editor to edit these
<cjwatson> johnt: there'll be a dists directory somewhere; use the path for its parent directory
<cjwatson> johnt: e.g. if you have http://mirror.example.com/foo/bar/baz/dists/natty/..., then 'd-i apt-setup/security_host string mirror.example.com' and 'd-i apt-setup/security_path string /foo/bar/baz'
<doko> tkamppeter, gets ptouch-driver seeded somewhere?
<tseliot> pitti: also what do you mean by "WI"?
<tkamppeter> doko, not yet. I have opend bug 823545,
<ubottu> Launchpad bug 823545 in ubuntu-meta (Ubuntu) "New printer drivers need to get seeded: rastertosag-gdi, c2esp, ptouch-driver" [Medium,New] https://launchpad.net/bugs/823545
<pitti> tseliot: "work iem", sorry
<pitti> tseliot: there's no code yet, it's a todo item assigned to me
<pitti> tseliot: it's blocked on actually having the packages available
<doko> tkamppeter, why don't you use the ubuntu-printing group when subscribing to these packages?
<tseliot> pitti: ok, so the answer to that question would be "yes" then ;)
<pitti> tseliot: thanks, updating
<johnt> cjwatson: strange, thats what i had. its basically: host.domain.com/ubuntu/dists/ so i had "security_path string /ubuntu" and the updates seem to work during the install but the security lines in sources.list are all messed up - does that make sense?
<tkamppeter> doko, done, ubuntu-printing is now subscribed to the new driver packages.
<johnt> cjwatson: any idea what might cause that?
<cjwatson> johnt: can I see the exact preseed file (with passwords removed, of course) and the exact resulting sources.list?
<cjwatson> paste.ubuntu.com may be helpful
<johnt> cjwatson: sure, ill have to run the build again which could take 40 mins...
<cjwatson> johnt: you could show me the preseed file before that
<johnt> cjwatson: one question before i do that: what is the "d-i apt-setup/services-select multiselect security" line for?
<cjwatson> johnt: you shouldn't need that
<cjwatson> johnt: seeing as it's the default
<slangasek> wendar: aha, I guess I missed that part of the mailing list discussion, ok
<johnt> cjwatson: could possibly be the cause of my problem?
<cjwatson> johnt: no, it's a no-op
<cjwatson> irrelevant to this
<johnt> cjwatson: ok 1 sec and ill de-password this preseed for you... :D
<johnt> cjwatson: does a trailing / make any difference on that security_path line?
<cjwatson> johnt: it would result in a trailing / in the sources.list lines, but that should never matter
<cjwatson> johnt: it would help in all this if you could tell me at least roughly *how* the security lines in sources.list are messed up
<cjwatson> it's a bit vague so far ...
<johnt> cjwatson: ill have to build the machine again to get the exact lines but they dont appear to match the directory structure of the mirror...
<johnt> cjwatson: http://paste.ubuntu.com/663429/
<cjwatson> johnt: I don't see anything obviously wrong, so let me know when you can show me the resulting sources.list and point out the problemin it
<cjwatson> *problem in it
<johnt> cjwatson: cool, thanks!
<doko> seb128: could you upload poppler to build with jpeg8?
<seb128> doko, I can have a look, do we transition to the new version?
<seb128> or is that to see if that fixes the openjpeg issue?
<envygeeks> Can somebody link a document or explain to me package naming in backports? Is it fine to use the original package name when backporting?
<Laney> envygeeks: append ~release1
<Laney> https://help.ubuntu.com/community/UbuntuBackports#Source%20Change%20Backports
<envygeeks> Laney: Thank you, I guess I missed that >.<
<doko> jamespage, about fop, should 0.95 be used, or 1.0?
<jamespage> doko: 0.95 - 1.0 is still not build-able  without bundled libraries
<doko> thanks
<jamespage> np
<ricotz> doko, hello, i hope you can have a short look, this happens on natty i386 (build for amd64 works fine), could this be a compiler issue? http://paste.debian.net/plain/125903
<mvo> hm, so cups in maverick depends on cups-ppdc that is in universe? that does not look right. it got added via a maverick-proposed upload
<johnt> cjwatson: hey, still there?
 * infinity looks at all the bundled libs in likewise-open and wonders how this got into main like this...
<slangasek> huh, it's in main?
<directhex> so..... i guess feature freeze is today?
<Laney> 21:00
<directhex> we get a dinstall run before then, surely
<infinity> slangasek: It looks like it's in main to me...
<slangasek> infinity: what a strange thing :)
<Laney> spank mhy a lot and one will fall out
<cjwatson> johnt: yes
<directhex> Laney, i already owe him beer!
<johnt> cjwatson: i have the sources.list for you...
<cjwatson> johnt: shoot
<Laney> upgrade that to rum and all will be well
<Laney> directhex: alternatively, file the request manually; I doubt anyone will get round to it before it dinstalls
<matttbe> Hello,
<matttbe> I know I'm sorry to annoy you with that... Sorry to resend this request and sorry to be a bit late but I'm still looking for a sponsor in order to upload 3 packages to universe repositories before the feature freeze.3 bzr branches have been created. 'bzr merge-upstream' has been used to commit these new revisions and they should be ready to be uploaded. bug #823513 ; bug #823514 ; bug #823566
<ubottu> Launchpad bug 823513 in cairo-dock (Ubuntu) "Please update Cairo-Dock to 2.4.0~0beta2 version (before the FF)" [Undecided,New] https://launchpad.net/bugs/823513
<ubottu> Launchpad bug 823514 in cairo-dock-plug-ins (Ubuntu) "Please update Cairo-Dock Plug-Ins to 2.4.0~0beta2 version (before the FF)" [Undecided,New] https://launchpad.net/bugs/823514
<Laney> to the climbing centre!
<ubottu> Launchpad bug 823566 in latexila (Ubuntu) "Please update LaTeXila to 2.1.1 (= 2.2.0 beta) version (before the FF)" [Undecided,New] https://launchpad.net/bugs/823566
<matttbe> I hope it's not too late (21:00 UTC or something else? not 16:00 or 18:00 UTC?) or maybe should I already send a request for an exception to 'FeatureFreeze'. But sorry if we still have some time.
<Laney> matttbe: how long have you been maintaining these packages for now? Have you considered applying for upload rights for them?
<johnt> cjwatson: http://paste.ubuntu.com/663503/
<matttbe> Laney: since Karmic release. Yes, I should do that...
<matttbe> (I forgot to do that...)
<cjwatson> johnt: so what should the URL be instead of http://lcsiupd.domain.com/ubuntu ?
<johnt> cjwatson: thats correct except "domain" is our domain name...
<cjwatson> johnt: I can't help you if you can't tell me what's wrong
<cjwatson> I can see that apt-get is telling you that some of the URLs don't work, but since I don't have access to your mirror I have no idea what they should be
<johnt> cjwatson: the apt-get update error is in that paste at the top - can you see it?
<cjwatson> the installer is doing what you told it to do in your preseed file
<johnt> cjwatson: 1 sec... phone... :|
<cjwatson> yes, I can see the apt-get errors, but I cannot tell you what the fix should be since I don't have access to your mirror
<cjwatson> if you could *be precise* about what the offending sources.list lines should look like, then I can help; otherwise I cannot
<infinity> If I had to guess, I'd say the fix is "mirror sources"...
<juliank> Everything looks totally correct as far as I can see on the client side.
<cjwatson> sure, that's possible
<cjwatson> does anyone who is not in techboard or ubuntu-release have a bug task they'd like to nominate for a stable release?
<cjwatson> right now you can just do it; I want to make a change to the stable release ownership in LP and would like to make sure that doing so does not break it
<cjwatson> anyone> I mean somebody in ubuntu-core-dev
<geser> can't MOTU after this change open task for SRU anymore?
<cjwatson> you ought to be able to, but I am more interested in the test for ubuntu-core-dev
<cjwatson> because right now the series owner is ubuntu-core-dev and I want to change it to ubuntu-release
<cjwatson> I'm not intending to break MOTU, but it is not relevant to the test I am trying to perform
<geser> ok
<geser> I asked because you asked for a core-dev
<slangasek> jdstrand: you know a lot about thinkfan, right?
<slangasek> jdstrand: in oneiric, setting 'level disengaged' doesn't take... even when thinkfan isn't running, something resets me to 'auto' after a few seconds :P
<slangasek> hmm... in fact, it seems to reset to auto right when /proc/acpi/ibm/thermal reaches 90
<slangasek> which is great, since the whole reason I'm setting it to 'disengaged' is because the other levels fail to bring the fan up to full speed when the system is overheating :P
<micahg> slangasek: he's on vacation :)
<slangasek> micahg: answers to the problem gratefully accepted from people who are not :)
<victorp> akgraner, hi
<akgraner> victorp, hi!
<doko> seb128, TheMuso: ibus-pinyin is dep-wait on a new ibus, how safe would be the sync?
<cjwatson> I have now changed the driver for all stable releases to ubuntu-release, and verified that this does not regress the ability of a core-dev to target tasks to a stable release
<seb128> doko, I've no clue about ibus but we have a diff so it's a merge in any case
<seb128> the new version is in debian unstable for some weeks without rc bugs
<seb128> so I guess it should be fine
<tkamppeter> mterry, doko: I have split the icc-profiles package into free and non-free now, see bug 822587.
<ubottu> Launchpad bug 822587 in icc-profiles (Ubuntu) "[MIR] icc-profiles" [High,New] https://launchpad.net/bugs/822587
<doko> barry, you did touch ibus last ;p
<barry> doko: probably
<johnt> cjwatson: hey, sorry about that, people keep calling me and trying to make me do work :(
<johnt> cjwatson: would it help if i could show you the dir structure of the mirror?
<cjwatson> sure
<cjwatson> but I think infinity is likely correct
<cjwatson> your mirror doesn't appear to have source code on it
<johnt> im sorry, i dont understand - does that mean that the mirror was set up incorrectly?
<cjwatson> arguably incorrectly
<cjwatson> right now we don't support binary-only mirrors particularly gracefully (none of our standard mirrors are binary-only), although something like   d-i preseed/late_command sed -i 's/^deb-src/#deb-src/' /target/etc/apt/sources.list   would work around it
<cjwatson> it might well be easier to get the mirror fixed though
<sladen> 2100 UTC eh
<johnt> cjwatson: http://paste.ubuntu.com/663554/
<johnt> cjwatson: i didnt fill it all in - just enought so that you can see the structure...
<directhex> Laney, filed. i even remembered the changelog.
<cjwatson> johnt: right, so your mirror has no source code on it
<cjwatson> johnt: either get the mirror admin to mirror source packages too, or use the preseed/late_command workaround I suggested above
<doko> pitti, barry: ibus-pinyin is dep-wait on a new ibus, please merge
<johnt> cjwatson: yeah i noticed that
<johnt> cjwatson: so, its just the fact that the mirror is binary only thats causing the problem?
<cjwatson> looks like it
<cjwatson> all your errors are on Sources.gz files
<johnt> cjwatson: thats fantastic :D thanks so much for all your help!
<johnt> cjwatson: time to send a strongly worded email to the mirror admin :P
<tkamppeter> pitti, hi
<tkamppeter> pitti, can you pass icc-profiles-free through NEW?
<tkamppeter> pitti, bug 822587
<ubottu> Launchpad bug 822587 in icc-profiles (Ubuntu) "[MIR] icc-profiles" [High,New] https://launchpad.net/bugs/822587
<slangasek> anyone around that understands alsa .conf files in all their horror? :)
<tseliot> bdmurray: can you renew my membership of ubuntu-bugcontrol please? (I'm albertomilone on launchpad)
<bdmurray> tseliot: as a developer your direct membership is unnecessary
<tseliot> bdmurray: oh, I didn't know. Thanks
<kees> hi, can an archive admin please sync apparmor from Debian for me?
<bdmurray> tseliot: oh by the way I think I've noticed some weird blank debconf prompts when installing nvidia-common
<tseliot> bdmurray: blank? How did it happen?
<bdmurray> tseliot: it was a wee bit ago but I seem to recall running update-manager and briefly seeing a debconf window title that would disappear right away
<bdmurray> tseliot: I thought I'd tracked it down to /etc/kernel.d/postinst.d/nvidia-common
<tseliot> bdmurray: ok but nothing else (as in "bad") happened, right?
<bdmurray> tseliot: right it was just a strange popup that disappeared right away
<cjwatson> kees: could you requestsync it?
<cjwatson> it has a bunch of Ubuntu changes
<cjwatson> not saying I won't do it, it's just easier with the tools ...
<kees> cjwatson: yup already done. let me figure out wherr LP put the bug number
<tseliot> bdmurray: ok, I'll have a look at the package and see what's going on. Thanks for reporting
<kees> lp: #824681
<cjwatson> kees: oh, if it's done, I'll just do a queue run
<kees> cjwatson: cool, thanks
<cjwatson> sabdfl: available for TB?
<blueyed> Can somebody hint me at a command line tool which ubuntu uses to setup the system wide proxy? (I want to setup/remove proxies from a guessnet-enhanced interfaces file), and would like to avoid writing an own script for handling *_proxy in /etc/environment (+ the gnome config).
<dobey> how does one override the "python setup.py build" bit, when using dh_python2 w/cdbs?
<dobey> just override binary/foo::?
<kees> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: open for business | Development of Ubuntu (not support, not app development) | #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: kees
<dobey> hi kees
<dobey> barry: surely you know the answer to my question ^^ :)
<broder> dobey: you probably want something like override_dh_auto_build:\n\tdh_auto_build -- --my-extra-params
<broder> oh, cdbs
<barry> cdbs hurts my brain
<barry> sorry, not you cdbs :)
<kees> heya dobey
<broder> dobey: what do you want to change it to?
<dobey> yeah, cdbs. i need to work around a bug in distutils extra, by runnin python setup.py build using xvfb-run :(
<broder> you can set DEB_PYTHON_BUILD_ARGS_my-package to pass additional args
<dobey> i don't need to change the args, i need to change the "python" command
<broder> dobey: that doesn't look possible without digging into cdbs in ways that seem pretty fragile
<dobey> :(
<slangasek> step 1) stop using cdbs
<slangasek> step 2) profit
<dobey> stop using python :)
<slangasek> nah, python is great.  cdbs is not
<dobey> ok, so how would i change the "python" command itself, without using cdbs?
<seb128> jelmer, james_w, others: how do I tell bzr-builddeb to stop commiting using the changelog diff as a commit message without letting me edit it?
<dobey> seb128: that's odd. it's always let me edit the message in $EDITOR
<seb128> it was doing that until I upgraded yesterday for me
<dobey> seb128: new bzr?
<seb128> well that's specific to packaging vcs-es
<seb128> new bzr-builddeb
<dobey> weird
<seb128> it used to open $EDITOR with the diff ready to edit
<slangasek> dobey: if you were using dh, it would be override_dh_auto_build:\n\txvfb-run python setup.py --install-layout=deb + $options
<seb128> now it seems to think it doesn't need to ask for edit
<slangasek> dobey: (more or less - season to taste)
<dobey> ugh :)
 * dobey sticks with being a pythanthrope
<seb128> grrrr bzr-builddeb
<dobey> or pythonthrope
<slangasek> dobey: <shrug> sometimes you have to override the defaults of the debian/rules build system... I don't think that's python's fault :)
<dobey> slangasek: no, but cdbs generally makes this somewhat nice. it just happens to be less nice with python
<dobey> slangasek: and i also already do not like python :)
<slangasek> no, cdbs doesn't make anything nice
<slangasek> cdbs is only nice when you *don't* have to override things
<dobey> DEB_CONFIGURE_SCRIPT = $(CURDIR)/$(DEB_SRCDIR)/autogen.sh
<dobey> that is pretty nice
<infinity> cdbs is the past.  dh7+ is the future.
<dobey> don't have to copy all the default --prefix=/ --blah=/foo crap
 * infinity passes the Kool-Aid.
<slangasek> except for the part where all the variable names are undiscoverable :)
<dobey> all i want to change is the python being run, not the arguments
<broder> dobey: don't you just use dh_autoreconf for that?
<dobey> eh, grep DEB_ works well :)
<dobey> broder: no
<dobey> autoreconf != autogen.sh
<juliank> dobey: You should use dh-autoreconf to autogen.sh
<juliank> or cleanup manually.
<dobey> again, autoreconf != autogen.sh
<slangasek> who's to say autogen.sh has anything to do with autotools :)
<slangasek> OTOH, if it *is* autotools, running autoreconf is almost always more reliable than an upstream-provided autogen.sh
<juliank> If it changes something and you do not know what, you can use dh-autoreconf.
<dobey> almost always less reliable, rather :)
<slangasek> er, no
<juliank> Whether you use autotools or something else is not important
<juliank> dh-autoreconf can run anything you want it to run.
<dobey> does dh_autoreconf handle all the third party extensions stuff on top of autotools now?
<dobey> i doubt it.
<slangasek> I don't know what you mean by "third party extensions"
<juliank> dobey: You can run the autogen.sh script using dh_autoreconf ./autogen.sh
<dobey> i mean gnome-autogen.sh with intltool and other such stuff, which are run through autogen.sh
<dobey> juliank: and that uses all the default arguments without me having to pass them again in rules?
<juliank> You just should suppress running configure in autogen.sh, otherwise things may get strange.
<slangasek> yeah, doesn't look like the intltool bits are supported by autoreconf, unfortunately
<dobey> and in another 6-12 months, dh will be the past, and something else will be the future. so whatever :)
<dobey> i'll stick with what works
<slangasek> no
<infinity> dobey: debhelper seems unlikely to be the past. :P
<juliank> dobey: You're thing does not work. It does not clean up afterwards, as you're required to.
<dobey> juliank: what are you talking about?
<dobey> *my* things works perfectly.
<juliank> dobey: Changes to upstream files, the generated Makefile.in, etc.
<juliank> They need to be removed in clean
<juliank> That's why I wrote dh-autoreconf.
<dobey> juliank: there is no Makefile.in; this is from straight vcs checkout.
<dobey> if it was from a tarball, i wouldn't be running autogen.sh
<dobey> i would be running configure
<dobey> and preferrably, not patching the build system
<slangasek> dobey: you can continue to use cdbs if you wish, but it enjoys near universal disdain, and you were asking here how to do something cdbs isn't letting you do; the consensus answer is "use dh"
<juliank> dobey: You still have to remove them anyway, otherwise they get in your .debian.*/.diff.gz
<seb128> slangasek, stop trolling cdbs ;-)
<dobey> slangasek: right. and dh doesn't let me do *exactly* what i want either
<dobey> juliank: if there is no .orig.tar.gz, they don't end up in the .diff.gz
<slangasek> seb128: is it trolling?  I thought you guys had finally gotten all the gnomey package bits ported to dh :)
<juliank> dobey: Then they end up in the tarball.
<dobey> juliank: yes. which is where they belong
<seb128> slangasek, hehe, I don't think we ported a single one ;-)
<chrisccoulson> i like cdbs!
<seb128> see!
<juliank> dobey: No, then you wouldn't do it during build, but before.
<slangasek> seb128: right, I thought they were "ported" to dh by moving them to pkg-mangler? :)
<dobey> juliank: i don't make nightly builds by making tarballs all the time, and then using them as orig.tar.gz
<dobey> anyway
<juliank> If you run autoreconf or similar during the build, and then recreate the source package later on, the source package might be different, as the auto* on the host changed.
<dobey> juliank: and i don't much care. because they are unstable nightlies for a reason :)
<seb128> slangasek, no trolling there, right? ;-) Though I would admit with dh-translations and gnome-pkg-tools having a --with gnome now I think dh is somewhat usuable ;-)
<juliank> dobey: OK. But it's nothing that should be done in the official archive(s)
<juliank> that is, in official Ubuntu or Debian packages.
<james_w> seb128, bug 812749
<ubottu> Launchpad bug 812749 in bzr-builddeb "Misuses bzr 2.4's new set_commit_message hook to disable editor prompting for a commit message entirely" [High,Triaged] https://launchpad.net/bugs/812749
<seb128> james_w, thanks
<ScottK> slangasek: Maybe it was KDE you were thinking of.  ~all the KDE packages use DH now.
<seb128> I downgraded for now so I can commit my work
<slangasek> ScottK: nah, I remembered seeing the dh-translations work related to getting dh usable for GNOME packages
<ajmitch> ScottK: a good reason for me to switch to kde then
<dobey> juliank: agreed. and for there i prefer to avoid touching build system at all, and keeping pure upstream source as close as possible
<ScottK> As if there were a shortage ....
<seb128> slangasek, right, we got dh-translations and a --with gnome in gnome-pkg-tools
<seb128> slangasek, so technically we can use dh ;-)
<infinity> ScottK: I thought the usual argument was just that people like blue.
<slangasek> seb128: but you prefer to stick with cdbs?  I thought the tooling was the only blocker, and that there was a consensus for the GNOME team to move to dh once that was done
<seb128> slangasek, no, cdbs just works fine enough that I can't be bothered converting sources ;-)
<slangasek> ok, sure
<seb128> slangasek, we tend to do new sources using dh though
 * slangasek nods
<dobey> also, requiring man pages for graphical programs, feels a bit like requiring graphical help for 'less' with screenshots and everything.
<slangasek> dobey: "requiring" :)
<slangasek> it's an unenforced bit of policy
<dobey> right
<dobey> but seeing the lint warning is annoying
 * dobey wonders why dh on oneiric doesn't just default to using dh_python2 instead of pysupport.
<slangasek> I think the remaining reason is that it's an incompatible change in debhelper behavior, so requires a new debhelper compat level
<dobey> lovely. :-/
<dobey> and now gpg suddenly won't accept my passphrase, and the seahorse/keyring gui agent integration bits aren't working. :(
<dobey> guess i'll have to reboot and see if it works then
<bdmurray> kees: hello mr patch pilot
<bdmurray> kees: could you review https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/unreportable-pkg-conflict/+merge/71264
<ScottK> bdmurray: If you have a moment, I'd like to discuss Bug 702283 being "Wishlist".
<ubottu> Launchpad bug 702283 in usb-creator (Ubuntu) "usb-creator doesn't create EFI-bootable USB sticks" [Wishlist,Triaged] https://launchpad.net/bugs/702283
<bdmurray> ScottK: Why don't you just change it and I promise not to get in a reversion war with you
<ScottK> bdmurray: Works for me.  Thanks.
<KaiserClaudius> Have the daily live images moved? Wanted to get a zsync refresh for testing today, but on the usual location ( http://cdimages.ubuntu.com/daily-live/ ) there suddenly seem to be only images for PowerPC o.O
<charlie-tca> KaiserClaudius: they are broken
<charlie-tca> maybe tomorrow we will have new images
<KaiserClaudius> ah ok, thanks :)
<kees> bdmurray: sure, one sec. working on cairo-dock atm
<dobey> kees: could you reivew https://bugs.launchpad.net/ubuntu/+bug/817133 for me? we'll need an MIR for it later, but would like to get it in universe before FF if possible. thanks :)
<ubottu> Ubuntu bug 817133 in Ubuntu "[needspackaging] ubuntuone-installer needs packaged" [High,In progress]
<broder> ScottK: Wait, I'm confused. In the usb-creator case (as opposed to the "dd the iso onto the USB drive" case), I thought all you needed is a /efi/boot/bootx64.efi file, which the natty CD at least has
<broder> (i.e. you don't need any special partition table mangling or anything like that)
<ScottK> Dunno.
<ScottK> I don't have a mac, but if you can't get a bootable image on the stick, I think that's not wishlist
<kees> dobey: sure
<broder> ScottK: I'll take a look at it later, but I believe the actual scope of that bug is more narrow than the description suggests (i.e. only affects older Macs, and not non-Mac UEFI machines)
<kees> dobey: oh, heh, this needs MIR, deNEW also? not sure that can happen in the next hour
<ScottK> broder: We were unable to test Kubuntu amd64+mac due to it not working in Alpha3.  If that bug doesn't cover that, then the dupe needs to be unduped.
<dobey> kees: well, MIR doesn't need to happen in the hour. NEWed to universe would be a nice start :)
<kees> dobey: I can review and sponsor, deNEW will have to be an archive admin. I'll get started; have to wait for cairo-dock to build in archive anyway :)
<dobey> kees: ah ok. i thought you were an archive admin too. but that is fine, as long as it's approved/uploaded i'm happy :)
<kees> oop, being forced to lunch. will continue shift when I'm back
<kees> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: open for business | Development of Ubuntu (not support, not app development) | #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:
<kees> dobey: since nothing depends on it yet, it'll be an easy FFe. I'll keep looking at it
<micahg_> kees: dobey: deNEWing can happen after FF as long as it's uploaded
<dobey> micahg: right. i'm just trying to avoid the FFe :)
<slangasek> ScottK: hey, can I multiarch qt4-x11? :)
<ScottK> Can you finish in 19 minutes?
<slangasek> it'll be fun to try
<ScottK> For the next 18 minutes, I've got no opinion on the matter.
<slangasek> ok cool
<slangasek> bdmurray: "Refusing bug filing if the conflicting package isn't an Ubuntu package" - <hug>
<slangasek> that should take out about a quarter of the ongoing plymouth bug reports...
<bdmurray> slangasek: really?  I queried the local ones here and didn't find many
<slangasek> bdmurray: I've been whacking them with a hammer each time
<bdmurray> slangasek: oh right I'm only looking at the open bugs ;-)
<slangasek> this is the "broken Malaysian Ubuntu derivative with no English language contact link on their website" case
<ScottK> It would be nice to have a sekrit developer override for the "I know, but it'd be really nice to throw this a the apport retracers" case.
<ajmitch> APPORT_ME_HARDER environment variable?
<ScottK> Nice.
* Laney changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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:
<Laney> :-)
<iulian> Enjoy and don't break things. :)
<slangasek> ScottK: "Can I finish in 19 minutes" - whoops, timestamp says it was 20, I didn't look closely enough at the clock before dputting ;P
<ScottK> I'll live as long as you clean up any resulting messes.
<slangasek> yep
<Laney> OMG freeze break
<barry> pitti: any chance you're still around?
<micahg> barry: summit dinner unless he's back from it
<barry> micahg: ah, okay.  i have a merge if ibus i'm mostly looking for a review of (if my local build succeeds)
<dobey> kees: thanks for the sponsoring!
<seb128> barry, kees is patch pilot maybe he can sponsor it for you ;-)
<dobey> ok, am off now. cheers all!
<doko> barry: just point me to it, if your test build succeeds
<barry> seb128: don't need a sponsor, but maybe he can review it.  i just need another pair of eyes since i'm not very familiar with the code
<seb128> oh ok
<barry> doko: fab!  will ping you when it completes
<seb128> barry, I don't think pitti is familiar with the ibus code either
<seb128> barry, just upload, we will deal with issues ;-)
<seb128> barry, oh, doko said he would look at it, great
<barry> seb128: he did the last merge :)
<seb128> yeah because the new version was needed and somebody needed to do it ;-)
<barry> seb128: ;)
<barry> doko: lp:~barry/ubuntu/oneiric/ibus/sid-merge
<barry> doko: thanks!
<jelmer> seb128: that's bug 812749
<ubottu> Launchpad bug 812749 in bzr-builddeb "Misuses bzr 2.4's new set_commit_message hook to disable editor prompting for a commit message entirely" [High,Triaged] https://launchpad.net/bugs/812749
<seb128> jelmer, thanks, james_w pointed it to me before
<jelmer> ah, sorry
<barry> doko: i have to run out to pick up guido, who's in town for a visit.  if i see your feedback when i get back, cool, otherwise, i'll just upload it and we'll deal with any fallout after ff.  cheers!
<directhex> soooooooo, time for another requestsync!
<tkamppeter> mterry, doko: icc-profiles source package is split now into icc-profiles and icc-profiles-free. Latter needs to be NEWed, see bug 822587.
<ubottu> Launchpad bug 822587 in icc-profiles (Ubuntu) "[MIR] icc-profiles-free" [High,New] https://launchpad.net/bugs/822587
<barry> doko: uploaded
<mterry> tkamppeter, ok, will look
<mterry> eh, i'll wait until it's through new
<matttbe> kees: thanks for the sponsoring! ;) (cairo-dock packages)
#ubuntu-devel 2011-08-12
<kees> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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: kees
<lucidfox> How do I reconfigure the redirection of my ubuntu.com address?
<micahg> lucidfox: change your default address in LP
<lucidfox> Ah. Danke
<lucidfox> ...but my default email on LP *is* my @ubuntu.com address >_>
<micahg> lucidfox: it shouldn't be unless it was grandfathered in
<lucidfox> micahg, I changed my contact address on LP, but mail sent to sikon@ubuntu.com is still routed to my old mailbox
<micahg> lucidfox: I think it might take a bit to sync up
<jbicha> it may take a few days
<lucidfox> Ouch
<kees> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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:
<didrocks> good morning
<merlot> mornin' didrocks
<ScottK> slangasek: Wouldn't want to you to be disappointed and have nothing to do.  Looks like a few rough edges on Qt.
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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: didrocks
<slangasek> ScottK: yep; I understand what's wrong, I'm just doing a local build here first to try to catch all the remaining issues in one go
<pitti> Good morning
<pitti> barry: yeah, did the last merge because we had to, but I barely know how this thing works :/
<pitti> barry: thanks for merging
<doko> ev, is the b-d on cheese in ubuquity wanted? MIR is missing
<ev> doko: no
<ev> we're using gstreamer directly now
<pitti> seb128: ^ FYI
<pitti> ev: nice! cheese grew so many new dependencies, and a lot of stuff we don't really want
<seb128> pitti, thanks, we discussed it yesterday ;-)
<ev> pitti: yeah, seb128 and I discussed that
<seb128> we still need to solve the camerabin issue though
<ev> I'm trying to pull camerabin out of -bad into -good, per seb128's advice
<ev> but it's a very large patch
<ev> will finish that today with any luck
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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:
<hyperair> lucidfox: ping. regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628194, does libgpod4-nogtk suit your needs?
<ubottu> Debian bug 628194 in libgpod "libgpod should only depend on libgdk-pixbuf2.0-dev, not libgtk2.0-dev" [Normal,Open]
<doko> Daviey, component-mismatches ping
<hyperair> lucidfox: no wait, sorry, ignore me
<Daviey> doko: o/
<doko> Daviey, see my email, could you walk through the list for the server component-mismatches?
<Daviey> doko: I'm doing that at the moment, and commenting in -release :)
<doko> cool, thanks!
<seb128> doko, indicator-me is deprecated, it has been merged in indicator-session
<doko> seb128, then please extend the bug report and/or remove it from the archive
<seb128> will check with kenvandine one he's online
<doko> thanks
 * ogra_ grumbles about the combination of lightdm and apport that make logins take 10mins here
<tkamppeter> Something changed with time.h in Ubuntu? Can someone have a look at bug 825054?
<ubottu> Launchpad bug 825054 in ghostscript (Ubuntu Oneiric) "[powerpc] ghostscript ftbfs on the buildd" [High,Confirmed] https://launchpad.net/bugs/825054
<tkamppeter> Is it correct that /usr/include/sys is empty now? In Natty it was full of *.h files of libc6-dev.
<cjwatson> it's not empty here; but you may well find that they've moved to /usr/include/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/sys
<cjwatson> (ah, I'm slightly out of date)
<cjwatson> they should still be on the compiler's default include path.  it's possible that your configure script or similar may need to be fixed if it brokenly looks in /usr/include directly.
<tkamppeter> cjwatson, thanks.
<tkamppeter> cjwatson, for me /usr/include/x86_64-linux-gnu has only an asm subdirectory, no sys and no time.h.
<cjwatson> perhaps it's busted on amd64
<cjwatson> $ dpkg -c /home/lp_archive/ubuntu/pool/main/e/eglibc/libc6-dev_2.13-16ubuntu2_amd64.deb | grep sys/time
<cjwatson> -rw-r--r-- root/root      6825 2011-08-11 18:04 ./usr/include/x86_64-linux-gnu/sys/time.h
<cjwatson> nope, looks fine to me
<tkamppeter> cjwatson, reinstalled libc6-dev and now the files are there.
<tkamppeter> cjwatson, thanks.
<doko> looks like we have an upgrade bug, which is exposed on the buildds too
<tkamppeter> doko, cjwatson, looks like powerpc got updated a little bit earlier than the others so that Ghostscript still built on the others and failed on PowerPC.
<pobara> hi everyone, I have question: I need to programatically detect if os runs Unity based on gtk2 or gtk3; can this be achieved with gsettings?
<pobara> On Ubuntu 11.10 $ gsettings get org.gnome.desktop.session session-name
<pobara> says 'ubuntu'
<pobara> what does it say on Ubuntu 11.04?
<pobara> I asked same question on #ubuntu and #ubuntu-desktop, but noone seems to be able to run gsettings
<mdeslaur> pobara: it says "gnome" for me on 11.04
<mdeslaur> pobara: but, I'm not quite sure that's a good test for that
<tkamppeter> pitti, doko, can you upload c2esp 18-2ubuntu1 for me? See bug 821940. c2esp is not yet in my per-package upload list.
<ubottu> Launchpad bug 821940 in c2esp (Ubuntu) "[MIR] c2esp" [Medium,Fix released] https://launchpad.net/bugs/821940
<doko> tkamppeter, package location?
<tkamppeter> doko, debdiff is attached to the bug.
<doko> ahh
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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: kenvandine
<tkamppeter> I have a problem with building Ghostscript: devlibs error: There is no package matching [liblcms2-2-dev] and noone provides it, please report bug to d-shlibs maintainer. The correct name of the -dev package is liblcms2-dev. What do I have to do?
<janimo> doko, is there a way to make the linker output why certain objects end up in the output? --verbose is not enough, it only prints the object paths it tries. A trace of symbol lookups of sorts
<doko> janimo, -y ?
<janimo> doko, hmm thanks, I was probably too vague, did not know symbol tracing exists and is named as such. I want to know why a file ends up in the output, even if no symbols are used from it. I'll try with as-needed again
<janimo> doko, an object in the linker command line ends up in the result even if it is not. Only on ARM, x86 drops it
<janimo> libvirt.so FTBFS, gets linked to libnl-route even if it should not
<doko> hmm
<janimo> doko, https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/823711
<ubottu> Ubuntu bug 823711 in libvirt (Ubuntu) "libvirt version 0.9.2-4ubuntu8 failed to build on armel" [Medium,Confirmed]
<doko> janimo, is it different to revert the order of libnl-route and libnl?
<janimo> doko, no, tried that too
<janimo> only if I remove nl-route does it go away
<doko> does gold do the job?
<janimo> as-needed is default right?
<doko> yes
<janimo> I'll try to change to gold. Can I tell gcc the path to the linker or shall I just do that in the system?
<doko> and changing the order on x86 doesn't expose the bug?
<doko> -B/usr/lib/gold-ld/
<janimo> doko, will try that too just to be sure - I symlinked ld to ld.gold and same reuslt
<janimo> same with telling gcc to use gold. will try on x86
<janimo> doko, on x86 only the intersection of what is in the command line and what is used gets in the output. So libnl only, andonly when it is put there
<janimo> there are 5 symbols from libnl used in libvirt, and none of the other nl libs' symbols
<janimo> could be a combination of the recent switch to libnl3 and some toolchain issue
<janimo> doko, shall I subscribe linaro-gcc ?
<doko> janimo, maybe. does it work with 2.21.1? (see the ubuntu-toolchain-r ppa)
<janimo> doko, I'll try
<mterry> kees, do you have time for some of your MIRs today?  We're looking to get component mismatches down
<doko> janimo, and avoiding the not using libnl-* libs on the command line?
<janimo> doko, that works. but those are filled in (all of them) by pkg-config
<doko> $(filter-out -lnl-%, ...)
<janimo> doko, well sure, but I was hoping to find the bug. Otherwise turning off tests on armel is a workaround as well :)
<janimo> this ppa has an older binutils right?
<doko> yes, 2.21.1
<doko> but I assume it doesn't change, if gold shows the same behaviour
<tseliot> pitti: I'm thinking of disabling nvidia-common's debconf interface as I guess we don't need it any more
<janimo> doko, same with 2.21.1
<doko> smells like relying on some undefined behaviour?
<barry> doko: did you do a sync of python-sphinx?
<doko> barry: no
<doko> at least I can't remember =)
<barry> :)  odd that i got offered an update this morning
<tumbleweed> barry: I also noticed that, it was synced 2 weeks ago, but only built 20 hours ago
<barry> tumbleweed: wussup widdat? :)
<tumbleweed> dunno, launchpad throws away failed build logs
<tumbleweed> (when tehy are retried)
<barry> i bet there in the db somewhere.  i guess it's not that critical.  by request, i was going to do a sync of that today, but looks like i don't need to now
<doko> barry, tumbleweed: yes, see my emails from today
<barry> doko: which one? :)
<barry> doko: component-mismatches/dep-waits?
<doko> yes
<barry> doko: saw it but haven't followed the link yet.  my ibus upload failed so i need to try again
<robtow> I'm trying to build Ubuntu for Beagleboard under Ubuntu 1.10, and rootstock hangs with 100% cpu while "setting up xrulrunner-1.9.2 (1.9.2.10+build1+nobinonly-0unbuntu1)"
<robtow> Any advice?
<barry> doko: do i need an ffe to re-upload ibus?
<doko> no
<barry> cool, thanks
<didrocks> ev: FYI, I'm pushing an updated usb-creator-gtk dep on the new unity gir. Tested locally and works
<ev> didrocks: awesome, thanks!
<didrocks> yw ;)
<slangasek> ScottK: qt4-x11 reuploaded
<ScottK> slangasek: Thanks.
<RoAkSoAx> cjwatson: howdy! I have a quick question about preseed. Should debconf values for specific packages be set before telling pkgsel to include the package, or should be done after or it doesn't really matter: http://pastebin.ubuntu.com/664357/
<ev> mmm, is PyGI broken for anyone else?
<slangasek> ScottK: fwiw I've regression-tested Qt plugin resolution with both native (amd64) and cross (i386) builds, so I expect this to be pretty smooth; do you know anything else I should worry about testing besides a regular QCoreApplication-based plugin load?
<ScottK> Probably not.  I'd feel better if you fired up at least one KDE application and it didn't explode.
<ScottK> My expectation is it will be fine and it would either be OK for all of KDE or immediately crash and burn.
<slangasek> ScottK: recommendation of something to test?  I don't seem to have any KDE apps installed here currently
<ScottK> slangasek: kate should be reasonable.
<ScottK> I don't think it should pull in too awful much.
<slangasek> ok, installing
<slangasek> ScottK: Works For Meâ¢
<slangasek> ScottK: though I am unsure if the UI theming is what it's supposed to be
<ScottK> slangasek: It probably doesn't pull in everything that would make it 'nice' as that would be a LOT.
<kees> mterry: yeah, going to be spending all day on MIRs, I think. ran out of time yesterday (got a few done)
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Alpha 3 released | Archive: Feature Freeze | Development of Ubuntu (not support, not app development) | #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:
<cjwatson> RoAkSoAx: preseed files aren't ordered the way you think they are.  what you're doing is setting a load of entries in a database and then setting the whole thing off
<cjwatson> RoAkSoAx: so in short, order doesn't matter
<cjwatson> RoAkSoAx: though you should make sure to put only a single space or tab between the type ("string") and the value, as mentioned in the installation guide
<cjwatson> (can't see from your pastebin whether that's two spaces or a tab)
<RoAkSoAx> cjwatson: cool
<RoAkSoAx> cjwatson: thanks tfor the info
<RoAkSoAx> cjwatson: and it is a tab ;)
<cjwatson> ok
<tgardner> I've had several lockups with the chromium browser on lucid since a recent update. has anyone else complained? chromium-browser 13.0.782.107~r94237-0ubuntu0.10.04.1
<micahg> tgardner: no, I haven't pushed it out yet, is it reproducible?
<tgardner> micahg, you haven't pushed what out yet? thats the version that I'm running, likely from -proposed
<tgardner> and its quite reproducible
<micahg> tgardner: yes, it's in proposed ATM, was going to push out in a bit, but if it's crashing, I'll hold off
<tgardner> micahg, try a google search on 'apparmor dfa'
<micahg> tgardner: it's with the apparmor profile?  that's not even shipped with it ATM, idk if I"d block on that, but can you file a bug
<tgardner> micahg, no, its just a simple search.
<tgardner> no apparmor involved. I was trying to figure out what a dfa is
<micahg> ah, I see, that's the test case :), let me fire up a vm
<micahg> tgardner: are you searching in the URL bar or on google.com?
<tgardner> micahg, on google.com
<micahg> hmm, maverick isn't broke, let me fire up a lucid vm agaain
<micahg> tgardner: i386 or amd64?
<tgardner> amd64
<tgardner> micahg, how about if I revert to 12.0.742.112~r90304-0ubuntu0.10.04.1 just to make sure its not happening with that version.
<micahg> tgardner: that works too :)
<tgardner> micahg, reverting appears to fix that particular lockup.
<micahg> tgardner: :(, let me try in the i386 instance I just fired up
<micahg> it works, but I haven't upgraded the kernel, let me try that
<tgardner> micahg, yeah, I'm running full -proposed
<tgardner> except for chromium now
<micahg> i386 is fine
 * micahg tries amd64
<hyper_ch> hi there, I run into a statd problem with updates today and I wonder if it's the same bug (which says it has a fix released) or not
<tgardner> hyper_ch, statd bug in the browser, or something external ?
<hyper_ch> here's the bug I found  https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154   and my problem looks like this   http://pastebin.com/wYkBciWv
<ubottu> Ubuntu bug 525154 in nfs-utils (Ubuntu Natty) "mountall for /var or other nfs mount races with rpc.statd" [High,Fix released]
<hyper_ch> tgardner: statd error so that I can't mount nfs
<hyper_ch> manual (re)starting worked
<tgardner> hyper_ch, well, I'm not using nfs, and reverting chromium fixed my problem.
<hyper_ch> tgardner: statd is related also to browsers?
<tgardner> hyper_ch, I dunno.
<debfx> tgardner: the firmware-free package has been synced from Debian. I guess it should be removed since we have linux-firmware in Ubuntu?
<hyper_ch> maybe I was sent into the wrong channel and should go to #ubuntu-bugs?
<tgardner> debfx, yeah, I'd think there would be collisions.
<micahg> tgardner: no crash for me, do you have any extensions in chromium?
<debfx> ok, I'll file a removal bug
<tgardner> micahg, not that I remember.
<tgardner> I'm cranking up a Lucid VM to see if I can reproduce it. if not I'll look to see what extensions I might have.
<slangasek> ScottK: qt4-x11 is also published on amd64 now, so the screaming should start soon if there's to be any
<ScottK> Excellent.
<tkamppeter> I have a problem with building Ghostscript: devlibs error: There is no package matching [liblcms2-2-dev] and noone provides it, please report bug to d-shlibs maintainer. The correct name of the -dev package is liblcms2-dev. What do I have to do?
<tkamppeter> doko, thanks for the upload of c2esp.
<tgardner> micahg, hmm, an amd64 VM seems to work OK. as far as I can tell I've no extensions installed.
<tkamppeter> pitti, hi
<micahg> tgardner: can you get a backtrace?
<tgardner> micahg, you'll have to tell me how. its not crashing as  far as I can tell. it simply locks up.
<micahg> tgardner: ah, can you attach strace to it when it locks up?
<tgardner> micahg, ok, gimme a bit to upgrade again.
<tgardner> micahg, I'm beginning to think this is kernel related. I'm running bleeding edge with a bunch of stable updates. I rebooted with the kernel in -proposed and all seems well.
<tgardner> when chromium-browser gets wedged its always at an mmap() call, which I find highly suspicious.
<micahg> tgardner: ok, thanks, I was getting worried, I just found a regression in maverick, but lucid looked clean, so good to know, I guess I should push lucid out
<tgardner> micahg, yeah, I'm guessing my problem is self induced, but better to catch it now...
<micahg> tgardner: indeed :)
<tgardner> micahg, here is a very suspicious stable update to the kernel: 'mm: prevent concurrent unmap_mapping_range() on the same inode'
<dobey> no patch pilot right now?
<micahg> dobey: kenvandine is scheduled, but idk when/if he plans to pilot
<dobey> ah. i pinged him on -desktop too, but no response yet. maybe the swamp fire is blocking his view of the screen or something :)
<kenvandine> micahg, i did already :)
<kenvandine> dobey, you pinged me?
<dobey> kenvandine: i did. was wondering if you could sponsor a branch for me. https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-control-panel/fix-823648/+merge/71413
<kenvandine> sure
<dobey> thanks
<micahg> kenvandine: wow, stealth pilot :)
<micahg> oh, I saw it now :)
<sgnb> it looks like because of bug 810402, everything compiled with ocaml should be recompiled on armel... what about upgrading to 3.12.1 at the same time?
<ubottu> Launchpad bug 810402 in ocaml (Ubuntu Oneiric) "all native ocaml programs segfault on armel" [High,Confirmed] https://launchpad.net/bugs/810402
<sgnb> cjwatson, doko: ^^^
<cjwatson> sgnb: we're after feature freeze - if we have to recompile, I'd rather just recompile what we currently have, unless there is a strong justification
<infinity> We kinda need a fixed ocaml first anyway before we can talk about recompiling things.
<sgnb> I've uploaded a fixed ocaml 3.12.1 to my PPA, the relevant patch is http://www.glondu.net/tmp/0013-ocamlopt-arm-add-.type-directive-for-code-symbols.patch and can be applied as is to the version currently in Ubuntu
<sgnb> (it is also in the git repos at git.debian.org, which seems down right now)
<kenvandine> dobey, uploaded
<dobey> kenvandine: cheers! thanks!
<infinity> sgnb: While I'd certainly be happy to discuss 3.12.1 if it's "nothing but bugfixes", or mostly so, I'll be more than happy to just apply the patch to our current sources for now. :)
<kenvandine> dobey, any eta when ubuntuone-client-gnome will be installable again?
<infinity> sgnb: Also, glondu.net seems to be grumpy with me currently.
<sgnb> infinity: with www?
<infinity> sgnb: As you typed above.
<dobey> kenvandine: it isn't now?
<infinity> sgnb: ICMP is fine, I get nothing on TCP 80.
<cjwatson> nothing but bugfixes> right, that would help
<cjwatson> sgnb's URL works for me
<infinity> Weird...
<cjwatson> although I expect that I'm hitting it on IPv6
<infinity> Could be.
<infinity> I'm still living in the dark ages.
<sgnb> ah, my IPv4 NAT rule must be broken (the server has only IPv6)
<kenvandine> dobey, not for me
<cjwatson> w3m -4 doesn't answer, so yes, that's it
<dobey> kenvandine: oh? what is the error?
<cjwatson> sgnb: hey, we need more IPv6-only services anyway ;-)
<kenvandine>  ubuntuone-client-gnome : Depends: ubuntuone-client (= 1.7.0-0ubuntu2) but 1.7.1-0ubuntu2 is to be installed
<cjwatson> ubuntuone-client-gnome is sitting in binary NEW at the moment
<kenvandine> ah
<dobey> oh right, because of the -dbg package
<cjwatson> also the i386 binaries appear to have been rejected
<infinity> Always a good sign.
<dobey> oh, by didrocks?
<cjwatson> I'm not actually clear why
<cjwatson> manual maybe?
<cjwatson> did he contact you about t?
<cjwatson> *it
<sgnb> infinity: should be fixed now
<cjwatson> there's nothing in my ubuntu-archive mailbox about it
<sgnb> (somehow, it seems that some delay is needed before setting routes with linux 3.0)
<dobey> cjwatson: i think something about la files lintian
<infinity> sgnb: It is indeed; thanks.
<kenvandine> great... and now didrocks is away for 2 weeks :)
<kenvandine> dobey, oh, you need to clean those
<dobey> which is odd
<cjwatson> well, if he gave clear feedback, any other archive admin can process them
<cjwatson> .la handling is documented quite clearly in the policy manual
<kenvandine> indeed
<dobey> i'm not arguing with that :)
<cjwatson> and it's there to avoid problems when libraries move around between paths, or when indirect linkage changes
<dobey> but i don't know how it would be an issue given that we have a find/rm on the .la and .a files in the rules file
<dobey> hence my "that is odd" :)
<cjwatson> well, I assume he was going off how the actual binaries looked?
<dobey> right. i'm just wondering how the .la files ended up in the binaries if the rules file has the bits to remove them...
<infinity> adconrad@cthulhu:~/foo$ dpkg-deb -c ubuntuone-client-gnome_1.7.1-0ubuntu1_i386.deb | grep libub
<infinity> -rw-r--r-- root/root      9600 2011-08-11 15:19 ./usr/lib/gnome-settings-daemon-3.0/libubuntuone.so
<infinity> -rw-r--r-- root/root      5508 2011-08-11 15:19 ./usr/lib/gnome-settings-daemon-3.0/libubuntuone.a
<infinity> -rw-r--r-- root/root      1292 2011-08-11 15:19 ./usr/lib/gnome-settings-daemon-3.0/libubuntuone.la
<infinity> They're definitely in the package.
<dobey> yes, i see that. but *why*
<infinity> I assume because they dislike you for some reason? :)
<infinity> (More likely, some helpful helper is installing them after you think you've removed them)
<dobey> probably
<infinity> If you remove them from your build-tree during the build target, then there's no way anything in binary-arch can operate on them.
<infinity> Since they'll be, y'know, not there at all.
<infinity> That would be my purge-with-fire method of tha day.
<infinity> s/tha/the/
<dobey> well we're removing them in binary-post-install
<dobey> but i suppose for some reason that is no longer working correctly in the split package for some reason
<dobey> wow, brain fail there
<kenvandine> 	find debian/tmp/usr/lib -name \*.la -delete
<kenvandine> 	find debian/tmp/usr/lib -name \*.a -delete
<kenvandine> works
<micahg> kenvandine: why are you removing the .a files?
<cjwatson> may need to be debian/ubuntuone-client-gnome instead given that this is a multi-binary package
<infinity> micahg: Because it's an internal library/plugin, not something meant to be linked statically against, I assume.
<kenvandine> +common-install-arch::
<kenvandine> +	find debian/tmp -name \*.la -delete
<kenvandine> +	find debian/tmp -name \*.a -delete
<kenvandine> that'll work
<kenvandine> not sure if we need anything to use it statically linked
<kenvandine> that was already three
<sgnb> cjwatson, infinity: for ocaml, as you wish... all packages providing an -dev binary package (and maybe a few more) should be recompiled (at least on armel) in topological order (as in http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html) with ocaml + the patch above
<kenvandine> there
<infinity> sgnb: *nod*... I'll get on that as soon as the patch and I have spent some quality time.
<infinity> sgnb: I'm not against the idea of the ocaml microrelease, if an argument can be made for it, but I have no idea if it's featurey, or just bugfixey, etc.
<sgnb> infinity: in the link above, lwt, oasis, js-of-ocaml, obrowser, ocaml-usb and ocsigen should be fixed by that
<infinity> sgnb: You're my personal hero.
<infinity> sgnb: For this week, anyway. ;)
<sgnb> (after recompiling their dependencies)
<dobey> kenvandine: https://code.launchpad.net/~dobey/ubuntu/oneiric/ubuntuone-client-gnome/fix-824821/+merge/71424
<kenvandine> dobey, great
<kenvandine> dobey, my way was simpler :)
<kenvandine> dobey, uploaded
<dobey> thanks again
<kenvandine> anytime!
<dobey> now hopefully archive admin can approve it
<kenvandine> yeah
<kenvandine> woot :)
 * kenvandine calls it a day... later!
<ScottK> slangasek: I missed one dh_python2 change.  I'd appreciate if you'd approve Bug #825536
<ubottu> Launchpad bug 825536 in kdeadmin (Ubuntu) "FFe: Switch from pysupport to dh_python2" [Medium,New] https://launchpad.net/bugs/825536
<slangasek> ScottK: acked
<ScottK> slangasek: Thanks.
<slangasek> ScottK: sure thing. btw, I missed a library on alsa-libs too... can I multiarch libjson0 as well? :) (bug #825342)
<ubottu> Launchpad bug 825342 in json-c (Ubuntu) "FFe: multiarch support of alsa-plugins dependencies" [Low,Incomplete] https://launchpad.net/bugs/825342
<alkisg> http://packages.ubuntu.com/lucid/linux-headers-2.6.35-30-generic-pae is broken currently, it depends on linux-headers-2.6.35-30 which is not available
<slangasek> alkisg: please raise a bug on the linux-lts-backport-maverick package for this; it seems to be a regression between the previous version (which did have the package) and the one that actually got published to lucid-updates
<alkisg> slangasek: ok, will do so tomorrow (kinda late here). Thank you. :)
<slangasek> thank you for reporting it
<slangasek> kees: have you seen bug #800853?
<ubottu> Launchpad bug 800853 in heimdal (Ubuntu) "[MIR] heimdal" [Undecided,Confirmed] https://launchpad.net/bugs/800853
<kees> slangasek: yeah, I have a long list I've been working on. it's coming up :)
<slangasek> ok
<slangasek> that one would be particularly helpful to get sorted, blocking as it does both libpam-krb5 and cyrus-sasl2
<kees> slangasek: okay, noted.
<infinity> Did we switch krb5 providers for main?
<infinity> Or, we're going to ship MIT and heimdal?
<infinity> I guess...
<slangasek> infinity: yeah, too many packages now build-depend on both krb5 implementations :/
<infinity> slangasek: Feels a bit ugly, but whatever.
<slangasek> does anyone know where my other metacity workspaces will have gone after my most recent upgrade?
<slangasek> ... or even where the option to configure workspaces is
<infinity> I gave up this morning and switched to xfce...
<infinity> Is that a helpful answer?
<slangasek> not terribly :)
<slangasek> ah, apparently I just needed to run 'metacity --replace' (eh?)
<infinity> Of... Course?
#ubuntu-devel 2011-08-13
<alkisg> Ah ok the missing headers bug I mentioned yesterday is already reported in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux-lts-backport-maverick/+bug/824080
<ubottu> Ubuntu bug 824080 in linux-lts-backport-maverick (Ubuntu) "missing binary package linux-headers-2.6.35-30" [Undecided,Confirmed]
<AnAnt> Hello, is there any info about making themes for lightdm ?
<AnAnt> are GTK2 themes compatible with GTK3 ?
<doko> ev, fyi, accepted the gst upload
<bluefoxicy> 1570 bluefox   20   0 1818m 929m 4436 S    3 25.1 228:10.18 compiz
<bluefoxicy> lol compiz using 2 gig
<AnAnt> Hello, are GTK2 themes compatible with GTK3 ?
<flecha> Hello! I am developing an App Indicator for Unity (those that appear in the menu bar). How do I make it binded to a hotkey?
<cjwatson> slangasek,jelmer: do either of you have a clue what's going on with the cyrus-sasl2/i386 build failure?  configure is failing to include gssapi/gssapi_ext.h, and there appear to be conflicts between /usr/include/gssapi/gssapi_ext.h and /usr/include/heimdal/gssapi/gssapi.h; I don't know whether that's the root cause
<jelmer> cjwatson: looking..
<flecha> is there a way to map a key to open a hidden gtk window?
<infinity> sgnb: Do you feel like convincing me to upgrade ocaml to 3.12.1 today?  I feel like listening. :P
<jelmer> cjwatson: sorry, got distracted. Found the issue - cyrus-sasl2 is hardcoding the library path rather than using krb5-config, which broke now heimdal switched to multi-arch.
<sgnb> infinity: are you aware that doko has uploaded a fixed (3.12.0) ocaml? (thanks, btw)
<sgnb> infinity: with the switch to 3.12.1, (almost) everything will have to be recompiled, too... and it will happen soon in Debian, too
<sgnb> infinity: it is mostly a bugfix release, and (almost) everything from testing compiles with no changes
<sgnb> it will also be easier to track, too, via http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html
<sgnb> (everything is currently uselessly green)
<sgnb> infinity: the updated ocaml package is in my ppa, I can also provide ocamlduce... and everything else (except jocaml, mingw32-ocaml, janest-core) will be recompilation with no changes (or sync with Debian)
<sgnb> it would probably be too intrusive for a Debian freeze, but I don't know what is acceptable for Ubuntu feature freeze
<cjwatson> jelmer: aha - are you fixing, or do you need sponsorship / other help?
<cjwatson> jelmer: (distracted> no problem, it's kind of a weekend)
<jelmer> cjwatson, sponsorship would be great
<jelmer> cjwatson, https://code.launchpad.net/~jelmer/ubuntu/oneiric/cyrus-sasl2/ftbfs-825872/+merge/71456
<infinity> sgnb: I'm not concerned about compilation time (since the slowest arch we have has to recompile everything anywa), I'm just concerned about potential impact and breakage.  If it really is "mostly bugfixes", that would be convincing enough, I think.
<cjwatson> hm, wonder why I didn't already get mail about that
<infinity> sgnb: Well, if you can define what isn't bugfixes that makes us say "mostly" instead of "entirely". :P
<cjwatson> oh, "4 minutes ago"
<cjwatson> jelmer: will review once bzr co gets round to giving me a useful working tree (modulo baking in progress)
<jelmer> cjwatson: great, thanks :)
<cjwatson> done, thank you
<sgnb> infinity: http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/ocaml.git;a=blob;f=Changes;hb=HEAD
<sgnb> upstream is very careful about not breaking stuff in minor releases
<blueyed> wow.. cannot believe bug 658865 is still there.. (been hit by it on the second machine now)
<ubottu> Launchpad bug 658865 in ubiquity (Ubuntu) "Install from USB fails: "An attempt to configure apt to install additional packages from the CD failed"" [High,Triaged] https://launchpad.net/bugs/658865
<doko> how can you that compiz is broken?
<doko>   ... you are able to see the lower right character in a terminal ;-P
<infinity> sgnb: That does, indeed, look fairly conservative.
<infinity> cjwatson: Care to give the changelog that sgnb referenced above a once-over and give me a second opinion on FFeing a new ocaml before I have to reupload/retransition/rebuild the ocaml world (which I have to do anyway, regardless...)
<infinity> cjwatson: The few small non-bugfix changes look pretty conservative and isolated to me (well, isolated in functionality, at least), and he seems confident in them.
<infinity> sgnb: If we give this a go-ahead, when would I be able to steal your time and expertise to help with any speedbumps and get it done quickly?
<sgnb> infinity: I'm available during the next 8 days
<sgnb> FWIW, I recompile everything in < 6 hours on my (amd64) own machine...
<sgnb> infinity: packaging for jocaml and mingw32-ocaml are not updated and most likely broken, is that a problem?
<sgnb> (I don't take care of those myself)
<sgnb> (no rdeps)
<jelmer> cjwatson, still there?
<infinity> sgnb: It would be nice if we could get those fixed too.
<sgnb> well... I would shamelessly have them removed from testing if they are not fixed by the time the transition is done in Debian
<sgnb> I would understand if this is a blocker for Ubuntu
<sgnb> infinity: ^^^
<infinity> Yeah, intentionally breaking other software at this point in our release cycle would be bad.  So, we either need to have a clear plan about how to make sure everything works, or not do it at all. :P
<sgnb> infinity: ok, let's recompile everything as it is, then
<sgnb> infinity: after looking, in a first round, you should start with: camlidl camlp5 camlzip cothreads cryptokit facile findlib lablgl llvm-2.7 llvm-2.8 llvm-2.9 menhir mlgmp ocamlagrep ocamlduce ocamlpam perl4caml pycaml react uuidm xml-light graphviz jocaml
<sgnb> infinity: actually, jocaml might need the same patch
<sveinse> When changing runlevels in with upstart, how is start and stop ordering handled? E.g. if I'm in runlevel 2 and enters level 3, will the "stop on runlevel [!2]" services stop before the "start on runlevel [3]" are started?
<cjwatson> jelmer: kind of, best to leave a message :-)
<penguin42> Does anyone else find the 'not directly subscribed to this bug's notification' that lp has these days to be entirely non-obvious when you look at it?
<mdeslaur> penguin42: yes, it had me confused as well when I saw it the first time
 * penguin42 finds it takes him a few seconds to read it each time
#ubuntu-devel 2011-08-14
<hyperair> cyphermox: ping.
<hyperair> cyphermox: it looks like networkmanager's somehow screwing up wpa adhoc connections.
<hyperair> cyphermox: using ifupdown, the same configuration (based on what networkmanager says in syslog) provided in a wpa_supplicant.conf works.
<hyperair> judging by iwlist output, it looks like networkmanager's slapping on an extra wep key.
<hyperair> removing the wepkey on the machines suddenly allow them to connect, but iwlist wlan2 scan seems to show an unencrypted adhoc connection available.
 * ejat pokes hyperair 
<ejat> hyperair : in natty ? oneiric ?
<ejat> or the latest built â¦
<hyperair> ejat: natty.
<hyperair> ejat: does it work for you?
<hyperair> ejat: it seems that wpa on adhoc is a rather strange beast.
<ejat> havent try adhoc wpa yet
<hyperair> yeah well wpa for everything else appears to work, just not wpa adhoc.
<ejat> owh .. file the bugs already ?
<hyperair> ejat: there seem to be some bugs lying around
<hyperair> without much attention paid to it
<ejat> u mean .. got related bugs with it
<hyperair> yeah
<hyperair> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/322902 like this one
<ubottu> Ubuntu bug 322902 in network-manager (Ubuntu) "incorrect encryption detected when logging on to WPA ad-hoc wireless network" [Medium,Confirmed]
<hyperair> i think i'll file a new bug.
<hyperair> and maybe test with oneiric's networkmanager
<debfx> slangasek: the multiarch Qt causes some fallout
<debfx> many projects use the QT_INSTALL_LIBS and QT_INSTALL_PLUGINS qmake variables
<debfx> so now they use multiarch paths but the packages don't expect that so they FTBFS
<debfx> KDE's FindQt4 script expects all Qt modules to live in the same path
<sveinse> Can I override (replace) a faulty file from another package with update-alternatives?
<sveinse> The /usr/share/initramfs-tools/hooks/plymouth on natty misbehaves, it needs files which are not present and the package doesn't depend on them. Nor do I want them, so I'd rather replace this file with my own for now
<infinity> sveinse: dpkg-divert is what you want to replace random files and not have them updated on upgrade.
<sveinse> infinity: Yes of course. Thanks
<micahg> Laney: or directhex  bug 824858 could use sponsoring (mono upgrade broke)
<ubottu> Launchpad bug 824858 in mono (Ubuntu) "package libmono-webbrowser4.0-cil (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/mono/4.0/Mono.WebBrowser.dll', which is also in package libmono-webbrowser0.5-cil 2.10.1-4ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/824858
<directhex> micahg, it's a known issue, fixed in 2.10.4-2 which was being tested by Laney last i checked
<micahg> directhex: ah, I saw that version in Debian, but it seemed to be on the wrong package according to the changelog
<Laney> micahg: it is on both
<micahg> Laney: ah ,ok
<Laney> 2.0 for upgrades from 2.6 releases, 4.0 for 2.10 ones
<Laney> but cheers for the patch
<Laney> you could dupe that bug to my sync request
<Laney> infact /me does that
<Laney> so, if someone has time to sync -2 from exp ;-) (#826226)
<hyperair> syncpackage!
<micahg> hyperair: that's frowned upon by the archive admins
<hyperair> o noes.
<micahg> unless it's a fakesync
<hyperair> what were the issues?
<micahg> I can't seem to find anything except e-mails about hard freezes, ISTR general usage frowned upon
<slangasek> debfx: qt multiarch ftbfses - ok.  How do you think we should deal with this?  My preference would certainly be to push forward, converting all the reverse-dependencies to build for the multiarch path; have you quantified the set of affected packages?
<debfx> slangasek: it's hard to identify the affected packages. I suspect most libraries that use qmake ftbfs
<tumbleweed> hyperair, micahg: We documented it in the manpage. An archive-admin (can't remember who) told me on IRC that they didn't approve of it because the procedure was not idential to their tool, and in general they didn't think we should do round-trips through developer's machines for syncs.
<tumbleweed> also, the sync button is due any day now â¢
<debfx> slangasek: are you aware that cmake stores absolute paths of the linked libraries in configs, e.g. /usr/share/qzeitgeist/cmake/QZeitgeistExport-noconfig.cmake from libqzeitgeist-dev?
<slangasek> debfx: <sigh> is that "cmake stores", or "some libraries that use cmake store"?
<debfx> slangasek: it seems to be a cmake feature that libraries can use
<slangasek> well, it's not a feature that distro packages /should/ be using... just like they shouldn't be shipping .la files with hard-coded references to files from other -dev packages
<slangasek> debfx: if there is a consensus among the Kubuntu team that qt4 multiarch support should be reverted, I'll go along with that; but I'm also willing to put in effort to fix these packages up, and much prefer that as an outcome
<directhex> tumbleweed, it does a round-trip through my machine anyway, since generally i syncpackage things i dput to debian myself
<slangasek> debfx: I count only 22 candidate packages which build-depend on qt4-qmake and ship files in /usr/lib; that seems manageable
<slangasek> debfx: what was the package you ran into this on? (so I can confirm it's in my list)
<tumbleweed> directhex: I know. I don't completly agree with their argument, but I understand the viewpoint, and respect their wishes
<tumbleweed> directhex: syncpackage also doesn't modify any tarball / diff contents, unless it's fakesyncing
<debfx> slangasek: that cmake feature generally is useful as it allows something like pkgconfig for cmake. though I'm not sure why it needs to save the absolute path of linked libs
<slangasek> debfx: yeah, it's not like pkgconfig *because* it's hard-coding paths to unrelated libraries
<debfx> slangasek: libqt4-dev depends on qt4-qmake so most packages won't explicitly depend on qt4-qmake
<slangasek> debfx: ok, will check libqt4-dev also
<slangasek> yeah, that's a little longer list
<debfx> I know that these need to be converted: qtwebkit-source, qt-assistant-compat and qscintilla2
<SpamapS> slangasek: are you familiar with the perl transition that went on earlier this cycle, or was that all cjwatson? collectd is FTBFS because it can't find libperl..
<SpamapS> bug 796571
<ubottu> Launchpad bug 796571 in collectd (Ubuntu) "ftbfs in oneiric (can't find libperl)" [High,Confirmed] https://launchpad.net/bugs/796571
<debfx> slangasek: I guess the only way to identify the affected packages is to test build them
<slangasek> debfx: libqt4-dev|qt4-qmake looks to give a bit over 300 candidates, but many of these are definitely false-positives (including the first package I picked from the list and tried to build, appmenu-qt).  So that's too many candidates for me to try to go through by hand, but I'm confident that the number of resulting build failures should still be manageable for the cycle and think we should just work them via the archive rebuild tests
<slangasek> SpamapS: sorry, don't know anything about the perl transition details
<debfx> slangasek: is there one scheduled soon?
<slangasek> debfx: yes, doko is planning on starting it ASAP
<slangasek> debfx: and there hasn't been any runtime breakage reported, right?
<debfx> there is some runtime breakage but I think it can be fixed by rebuilding pykde4
<slangasek> oh, what's broken there?
<slangasek> akonadi also builds fine; so there are my first two test cases
<debfx> bug #826321
<ubottu> Launchpad bug 826321 in pykde4 (Ubuntu) "[Oneiric] the PyQt4.QtCore module is version 1 but the PyKDE4.kdeui module requires version -1" [Undecided,Confirmed] https://launchpad.net/bugs/826321
<SpamapS> slangasek: alright I'll ping cjwatson about it
<debfx> I'm not 100% sure it's caused by the multiarch Qt, the error message is somewhat obscure
<debfx> appmenu-qt probably works fine because it doesn't have an install file (single binary package)
<slangasek> debfx: ah, amarok FTBFS, because the build system gets confused and tries to link against -lQt4::QtWebKit; maybe fixable by rebuilding qtwebkit-source?
<debfx> slangasek: yeah, that's the next package that needs to be converted for multiarch since it's a main Qt module anyway
 * slangasek nods
#ubuntu-devel 2012-08-06
<infinity> TheMuso: Ahh, indeed, thanks for the pointer.  Re-promoting it, then.
<alessio> hi all
<surak> I have a question about the bug reports submitted by apport. Every time I send such reports, my bugs are automatically marked as "invalid", as apport is aparrently unable to extract enough debug information, and the stack trace, for instance, always comes out blank. What to do?
<infinity> surak: Upgrade.
<surak> It is upgraded daily
<infinity> Well, generally, the retracers only have a hissy fit if they can't find the debug symbols for your binaries.
<surak> indeed. Are quantal's packages  compiled with debug symbols? Are there two versions of the repositories?
<surak> This happens since 12.04
<infinity> Example bug?
<surak> 1033478
<infinity> There's only one "version" of the archive, but if you're using a really laggy mirror, this could happen.
<surak> deb http://archive.ubuntu.com/ubuntu quantal main restricted
<infinity> Or, in this case, looks like the issue is the inverse.
<surak> 1029420 and 1028863 too
<surak> pardon?
<infinity> The retracer is failing to find new symbols.  Perhaps ddebs.u.c is having problems.
<surak> The oldest I still have here is the 1028863, 2 weeks ago - but it surely happened before that.
<infinity> I know it ran out of disk space recently.
<infinity> And there's been work on fixing that.
<infinity> So, it could just be a temporary gap in coverage.
<surak> Well... It has been like that for quite a while (more than quantal, for sure)
<infinity> "like that" doesn't mean much.
<infinity> It hasn't been just like this particular error at all times, I'm sure.
<surak> Ok - it has been invaliding apport submissions for as long as I can remember
<infinity> In this case, the ddebs are outdated compared to the packages on your system.
<debfx> hm why do the lp buildds don't consider installing libsocket-perl when the package build-deps on "libsocket-perl (>= 1.95) | perl (>= 5.15.6)"?
<debfx> https://launchpadlibrarian.net/112033772/buildlog_ubuntu-quantal-i386.libio-async-perl_0.51-2_MANUALDEPWAIT.txt.gz
<Chipzz> infinity: sounds to me like the bug being marked invalid is a bug; shouldn't the retracer try again later?
<infinity> debfx: There's a bug open for that.  sbuild misfeature.
<seb128> surak, infinity: the versions you are using are weird
<debfx> ok
<seb128> surak, looking at bug #1029420
<ubottu> Error: Launchpad bug 1029420 could not be found
<seb128>  Package: unity-2d-shell 5.12.0-0ubuntu2
<surak> seb128: it was the version of the day.
<yaffs> !ops
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<infinity> unity-2d-shell | 5.12.0-0ubuntu3 |       quantal | amd64, armel, armhf, i386, powerpc
<yaffs> !ops
<Pici> yaffs: ?
<infinity> ^-- seb128 What's weird about bug 1033478
<ubottu> Error: Launchpad bug 1033478 could not be found
<infinity> seb128: He has 5.12.0-0ubuntu3 (the latest) installed, ddebs.ubuntu.com is just lagging horribly, probably due to ENOSPC issues, and pitti's scripts falling over.
<seb128> infinity, surak: seems like those unity-2d versions got bitten by the ddeb ENOSPACE
<seb128> infinity, well, I think pitti told me last week at GUADEC that he made space
<seb128> but it's likely part of the ddebs got lost
<infinity> seb128: Yeah, IS cleared up some space for us.
<Laney> ..
<Laney> Funny looking terminal, this.
<infinity> seb128: But this unity-2d build is a week old, so could have just been at the wrong time.
<seb128> yeah
<infinity> I guess we really need to look at moving this all to the librarian ASAP, so we stop losing things. :/
<surak> Probably a bad time for upgrade. Last friday somehow the dist-upgrade ate my xorg.
<infinity> debfx: sbuild misfeature aside, it's probably easier to just fix the build-dep for now.  The only reason that's a valid build-dep in Debian is pure fluke (because perl just happens to be in the buildd chroots, despite only transitively being build-essential)
<infinity> surak: Are you running quantal-proposed...?
<infinity> surak: Cause that's where all the xorg mangling has been happening.  And you really shouldn't have proposed enabled for a devel release, unless you expect/want it to break. :P
<surak> yep - I like reporting bugs :)
<infinity> Well, we use proposed specifically to break things.
<infinity> I really wouldn't recommend running it.
<infinity> Seriously.
<surak> ok
<tjaalton_> surak: probably lost the nvidia blob there, since -proposed doesn't have it yet
<surak> This machine uses some onboard intel crap
<surak> that's why unity-2d
<tjaalton_> intel should work fine
<surak> it always fails when I switch ports on the external screen
<surak> but I never managed to make apport send this bug correctly
<debfx> infinity: why would the build-dependency be invalid otherwise?
<infinity> debfx: Because Debian ignores alternate build-deps unless they're already installed.  So, it only works in experimental (where it was meant to work) because perl happens to be there.
<infinity> debfx: I'm not saying this isn't a bug in Ubuntu (it is, because our buildds don't ignore alternates, so they're clearly misbehaving here), but it's not a widespread issue either.
<infinity> debfx: Anyhow, we do have a bug filed about it, and if I believe mterry was meant to be testing a fix.
<infinity> debfx: It still might be faster to just alter the build-deps on that one package, though. :P
<debfx> there are two packages with that build-dep ;)
<infinity> (The other "solution" would be to force a perl transition... *cough*)
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: stgraber
<mpt> ev, is bug 1033471 related to bug 989800?
<ubottu> Launchpad bug 1033471 in apport (Ubuntu) "Turn off rate-limiting of error reports" [Undecided,New] https://launchpad.net/bugs/1033471
<ubottu> Launchpad bug 989800 in apport (Ubuntu) "Error alert stops appearing for the same crash after a while" [Undecided,Confirmed] https://launchpad.net/bugs/989800
<ev> mpt: ah, they are the same issue
<ev> apologies
<ev> I didn't think to look for an existing bug first
<ogra_> stgraber, you clearly need more CPU for apport :P
<stgraber> ogra_: hehe, yeah ;) it's not too bad on my laptop, but it's a huge pain when happening on the panda or my netbook...
<ogra_> yeah, same for me on the ac100
<ogra_> on my desktop i dont notice apoport in the bg at all
<ogra_> only the annoying popups that steal focus in the middle of typing a sentence
<stgraber> I think what I'd actually love in my case would be some kind of "internal" whoopsie server on my network. Have all the machines always collect any needed data, shoot the result to my whoopsie server, then let me get a nice view of all the crashes on my network on a per day/machine view and then let me forward stuff to the public whoopsie
<stgraber> that way no machine that I manage would ever prompt the user, I'd get more data on what's going on on the machines I care about and would be able to forward more crashes to the main whoopsie server
<ogra_> yeah, but my mom wouldnt like me to set up an additional machine in her wlan to collect the crashes from the laptop :)
<stgraber> ogra_: that's what VPNs are for ;)
<ogra_> haha
<ogra_> i would actually vote for leaving whoopsie on and getting seb128 30 new team members to deal with it ;)
<seb128> ogra_, I would sign for that
<infinity> stgraber: I wouldn't be against a tickbox for "silently report all errors; don't include sensitive data".
<infinity> stgraber: Then I'd never see a dialog again, and never care.
<infinity> stgraber: (This would have to be on the apport "report a problem" dialog, mind you, with a "how do you want to treat further errors?" heading, since if it's in some deep, dark settings thing somewhere, normal people will never know there's a "stop bugging me" option)
<stgraber> infinity: yeah, I think it'd be a reasonable way to get all the data we want with a clear opt-in system that people would likely prefer to just not sending anything
<infinity> stgraber: It's been a long time since I've used Windows and seen a drwtsn32 popup, but don't they do a similar "just automatically report shit after this one, please" thing?
<infinity> stgraber: I honestly think that's the only way you can get a decent flow of data wihtout pissing off and/or confusing "regular people".
 * ogra_ thought you couldnt disable drwatson
<ogra_> iirc that annoyed the hell out of me with win 2000 ... though i havent touched win much afterwards
<infinity> ogra_: Well, if Dr Watson annoyed the hell out of you, welcome to us having reinvented your pain. ;)
<ogra_> yeah, i thought of it recently actually ...
<infinity> (I'd have to go find a Windows desktop and force a page fault, but I'm fairly sure that even if you can't "disable" it completely, you can make it silent, which is really what we want here)
<ogra_> though i really could live with the popups if they wouldnt just blkindly steal focus
<ogra_> i find their behavior  way worse than their frequency
<infinity> Yes, but you know what they mean.
<ogra_> yes
<infinity> Every time my parents get ANY sort of popup on their computer, they phone me.
<ogra_> lol
<infinity> Or when their mail client says something they've never seen.
<infinity> Or, or, or...
<ogra_> my mom still runs lucid :)
<infinity> My parents run Win7, for irritating reasons.
<ogra_> i only get occasional calls ... because she cant find the icon anymore or some such
<infinity> But this isn't OS-specific, by any means.
<ogra_> indeed
<LoT> is there a determination between "core" and "non-core" packages used by the devel team(s)?
<LoT> we're trying to figure out in Bug Squad how we got "core" and "non-core" determinations for importance, and I'm wondering if we're inheriting that from some devel-related thing.
<micahg> LoT: I don't think those 2 are compatible
<LoT> micahg: any idea where the terms came from then?  (see bugsquad emails)
<LoT> actually... *disappears back to -bugs*
<cjwatson> LoT: That sounds very vague.
<LoT> cjwatson: if you're in -bugs, micah and i moved the discussion there
<cjwatson> LoT: We have a few definitions of "core" depending on context, but who knows what it means in bugsquad terms :-)
<cjwatson> I'm not
<LoT> cjwatson: https://wiki.ubuntu.com/Bugs/Importance defines "core" and "non-core"
<micahg> I jumped a little here, it could be compatible, I was conflating core and minimal
<LoT> the issue here is that that documentation we use doesnt point to any definition of core or non-core
<LoT> so part of this is finding out *where* we get those from, and if they don't exist already, well..
<LoT> either define it or remove that distinction for BugSquad
<cjwatson> LoT: That could mean anything - hard to tell.
 * LoT wasnt sure if we get that from the dev team's distinction of what is core.
<cjwatson> I doubt it.
<LoT> indeed, that's what micahg and i determined during UDS
<cjwatson> It certainly doesn't correspond to e.g. ubuntu-core.
<cjwatson> Because most desktop applications aren't in that.
<LoT> so if we don't get that from the dev team's definition of "core", then BugSquad needs to have a clear definition.
<cjwatson> Sorry, I mean: no desktop applications are in that.
<cjwatson> It's probably a deliberately vague term intended to allow judgement ...
<cjwatson> But you might consider things like: applications that are installed by default; applications that are in main; applications that are popular
<brendand> LoT - i'm pretty sure 'core' refers to being in the base installation (i.e. on the CD)
<brendand> LoT - non-core means something installed later by the user
<brendand> LoT - e.g. Shotwell = core, Skype = non-core
<micahg> brendand: core is highly ambiguous with different definitions per-context
<brendand> micahg, i'm 99% sure this is what it means in this case. it's meant to give precedence to the applications users are more likely to use
<brendand> micahg, though certainly it could be clarified on the page
<brendand> micahg, and even though i'm pretty sure that's what the definition was intended to be, it might be that we want to revisit it
<slangasek> seb128: hmm, your new fontconfig is very spammy on stderr
<seb128> slangasek, is it? :-(
<slangasek> seb128: at least on my system, it is... http://paste.ubuntu.com/1133039/
<Laney> me too: http://paste.debian.net/182434/
<slangasek> checking those files, at least some of them appear to still be part of the default install in quantal
<seb128> slangasek, Laney: thanks, I don't have those installed but my install is not a recent one, I might have uninstalled stuff over time
<micahg> as well as grammatical issues :)
<seb128> but it doesn't seem like a but in the fontconfig update
<seb128> but->bug
<Laney> I suspect it's a new warning and the wrongness was always wrong
<seb128> rather a bug in the config shipped by those which triggers a warning in the new fontconfig
<slangasek> yep, that may be the case
<seb128> I will have a look at fixing those
<slangasek> seb128: thanks much!
<seb128> slangasek, Laney: thanks for pointing them!
<lifeless> bug 974509
<ubottu> Launchpad bug 974509 in cloud-init (Ubuntu Precise) "cloud-init selects wrong mirror with dns server redirection" [Medium,Triaged] https://launchpad.net/bugs/974509
<seb128> slangasek, http://launchpadlibrarian.net/84736369/popt_1.16-1_1.16-1ubuntu1.diff.gz
<seb128> slangasek, "* Build-depend on gettext:any instead of just gettext, for cross-compilation support." ... do you know if that has been sent to Debian and if not if there is a reason to not to? that's the only diff we have
<slangasek> seb128: the reason not to is the Debian autobuilders don't support it.
<seb128> slangasek, ok, so we need to keep a delta for that? :-(
<slangasek> yes
<seb128> thanks
<seb128> slangasek, it would be nice to put some rational in the changelog in those case, glad that you replied, it was not obvious from the diff
<slangasek> seb128: sorry, I disagree, I'm not going to put rationale in the changelog explaining why any given change isn't in Debian yet
<seb128> slangasek, I guess the merges should be let to be done by those who have the knowledge of the changes then...
<slangasek> that's an option :)
<seb128> it's not optimal though
<seb128> I'm not against it, but it practice those merges just don't get done apparently
<slangasek> well, merging new Debian revisions of libraries is a low priority as far as I'm concerned.  There's not many ways that a Debian maintainer *can* improve such a package that matter to us
<slangasek> this one looks like it's potentially relevant because of hardening, at least
<soren> mdz, kees, pitti, stgraber, cjwatson: TB meeting in 2Â½ minutes.
<seb128> soren, pitti is on holidays so I doubt he will be around (just for info)
<soren> seb128: Thanks!
<mdz> soren, hi
<cjwatson> ack
<ScottK> superm1: I think you're wanted in #ubuntu-meetings.
<ScottK>  -meeting
<superm1> ScottK: sure i can pop in there
<stgraber> ScottK: thanks
<ScottK> You're welcome.
<roaksoax> jbicha: thanks for filing the bug report on rhcs
<roaksoax> jbicha: i was just about to sync it myself
<roaksoax> jbicha: but i;ll make sure it gets removed from the blacklist before syncing it
<SpamapS> ScottK: so, how far behind are you guys on precise-backports?
#ubuntu-devel 2012-08-07
<micahg> SpamapS: need something approved?
<SpamapS> micahg: not urgently
<micahg> there are quite a few items that need attention, I'm happy to push something through so it's available for 12.04.1 though
<SpamapS> micahg: no its not for 12.04.1 .. just some stuff to make things better for juju users.
<micahg> well, it obviously wouldn't be in the point release, but I'm saying to have it available when LTS users upgrade
<micahg> anyways, feel free to file the requests, poke if they're not addressed within a reasonable amount of time
<SpamapS> https://bugs.launchpad.net/ubuntu/precise/+source/txaws/+bug/945176
<ubottu> Launchpad bug 945176 in Precise Backports "Support privateIpAddress and ipAddress" [Undecided,Confirmed]
<SpamapS> micahg: testing is all done, it should be in good shape
<micahg> SpamapS: ok, looks good, in the future, it might be easier to use the requestbackport script so that you can clearly mark things as tested
<SpamapS> micahg: sure, this was a case where I already had a bug report that is really a feature request so just felt it was easier to open a task
<micahg> SpamapS: one quick question, did you test build juju against the backported txaws?
<SpamapS> micahg: thats the last thing I uploaded
<SpamapS> https://launchpadlibrarian.net/112145340/buildlog-juju-precise-backported-txaws.txt
<micahg> SpamapS: ah, sorry, indeed, BTW, are you full AA enough to accept (it's sitting in unapproved)
<SpamapS> micahg: I've never been officially blessed for full AA work, so I'll let it be. But thanks!
<ScottK> Looks like someone else got it.
<slangasek> hallyn: ping
<hallyn> slangasek: hey
<hallyn> good night
<slangasek> hallyn: bah, sorry I missed you
<slangasek> hallyn: this was regarding /dev/console being a symlink to /dev/lxc/console... when you say /dev/lxc/console is a bind mount from devpts, you mean the (major,minor) will be those of a pty (136,n) rather than (5,1)?
<slangasek> stgraber: ^^ if you're around and know the answer :)
<sveinse> building protobuf (2.4.1-1ubuntu2) from precise  failed when I run dpkg-buildpackage -b -uc -us. I got "Makefile.am:84: Libtool library used but `LIBTOOL' is undefined" when make check-local is run
<Sweetshark> bug 1017125 just got a lot more sexy title ...
<ubottu> Launchpad bug 1017125 in libreoffice (Ubuntu) "boost::unordered_multimap<>::erase(iterator, iterator) broken on quantal" [Undecided,New] https://launchpad.net/bugs/1017125
<Sweetshark> ^^ are you maintaining a C++ package? fearzorz this bug!
<stgraber> slangasek: that's correct, /dev/lxc/console is a pty (136, n)
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<ogra_> NCommander, did you ever fix the broken flash-kernel upload to -proposed where you broke my changelog entry by omitting -v ? or do i need to dig up my bug and close it by hand now ?
<zyga> doko, ping
<hallyn> slangasek: right.  So neither /dev/console nor /dev/lxc/console will be (5,1), unfortunately
<stokachu> hi, could i get some multi-arch clarification wrt libgnomevfs2-bin and whether Multi-Arch: foreign or Multi-Arch: same is the correct syntax? https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258
<jamespage> infinity, nudge re bug 1028038
<ubottu> Launchpad bug 1028038 in eglibc (Ubuntu Precise) "sscanf always calls realloc/causes deadlock in google-perftools" [High,Triaged] https://launchpad.net/bugs/1028038
<jamespage> any eta on when you might get to it?
<stokachu> apw: pinGGG
<seb128>  $ fakeroot dbus-launch dbus-monitor
<seb128>  Failed to open connection to session bus: Did not receive a reply.
<seb128>   
<seb128>  does anyone know how to workaround that?
<apw> seb128, hi
<seb128> apw, hey
<apw> seb128, bah got all distracted, wanted someone else, soz
<apw> stokachu, hi
<seb128> no worry ;-)
<stokachu> apw: hey there.. wrt to https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Basics, i set a squid-deb-proxy but will it be used in chroots that weren't built with the proxy prepended?
<apw> stokachu, you either need to use http_proxy= when you build it or do the equivalent of installing squid-deb-proxy-client within it
<stokachu> apw: gotcha
<doko> zyga, pong
<zyga> doko, https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1026723
<ubottu> Launchpad bug 1026723 in python-defaults (Ubuntu) "Disagreement between pkg-config python and python-config" [Medium,New]
<zyga> doko, would you mind weighting in on that issue?
<zyga> doko, I've pinged barry about it a while ago and he sent me to you
<jodh> hallyn: I've just tested with lxc and Upstart attempts to mount /dev due to /dev/console, but it's non-fatal. Are there any options for handling this aside from an extra check to see if /dev/console exists with major 136?
<jamespage> stokachu, you should be able todo that pretty easily - if you drop this - http://paste.ubuntu.com/1134352/
<jamespage> into /etc/apt/apt.conf.d in the source schroot it will use squid-deb-proxy locally
<stokachu> jamespage: ah awesome, thanks!
<jamespage> stokachu, note you can also use the --debootstrap-proxy= argument to mk-sbuild to specify a proxy
<hallyn> jodh: well, a devices namespace :)  which would map 5,1 in containet to 136,X on host
<hallyn> jodh: if it's non-fatal, that's great.  actually that might be bc apparmor refsued the mount
<hallyn> so a container with lxc.aa_profile = unconfined might mess up
<hallyn> jodh: what is the exact requirement?  You want devtmpfs mounted if any core device is messed up?  It just seems draconian and system-D ish right now
<hallyn> oh, also i guess a boot argument (nodevtmpfs) could work
<jodh> hallyn: this all started when we added job logging; that requires /dev/pts and /dev/ptmx.
<jodh> hallyn: no problem, until users started to boot without an initramfs ;)
<hallyn> jodh: so /dev/console could just be ignored?
<hallyn> jodh: also, have you checked that /dev/ptmx as a file bind-mounted from /dev/pts/ptmx works? a nd as a symlink?
<hallyn> bc those are all valid.  i don't think you were using lstat
<jodh> hallyn: as slangasek noted, we're trying to avoid this bug fix blossoming into a monster. However, we are attempting to ensure a minimally sane environment in the initramfs-less case.
<hallyn> jodh: how does 'nodevtmpfs' upstart cmdline option sound?
<hallyn> or, it could check for the established 'container=' env variable
<jodh> hallyn: I guess a new cmdline option would make sense - could you raise a bug on this please?
<hallyn> jodh: i'll just wait to see if it breaks when it hits the archive?  :)
<hallyn> you say it worked for you, so mayb ei'm making noise over nothing
<hallyn> jodh: then again i'll raise a bug now
<hallyn> slangasek: I have a qemu-linaro package in ppa:serge-hallyn/virt which is built to enable virtfs (for 9pfs) in kvm-spice.  If/when you get a chance could you take a look and see if you're ok with it for quantal?
<slangasek> jodh: if /dev/console isn't guaranteed to have that major,minor in a container, we should back out the checks except for pts/ptmx.
<hallyn> jodh: bug 1034023
<ubottu> Launchpad bug 1034023 in upstart (Ubuntu) "add a nodevtmpfs option" [Undecided,New] https://launchpad.net/bugs/1034023
<jodh> slangasek: ok.
<hallyn> slangasek: /dev/tty doesn't (afaik) ever get messed with
<jodh> hallyn: thanks
<hallyn> but yeah if that gets backed out we don't need new options :)
<hallyn> thanks, ttyl
<slangasek> hallyn: I have a bunch of work to do on qemu-linaro, which I'm going to try to get done this week
<jodh> slangasek/hallyn: what about the mknods? remove the mknod(/dev/console) for lxc and keep the rest?
<slangasek> jodh: yep
<hallyn> slangasek: ok, my patch is tiny so trivially portable.  I jsut wanted to test-build it to make sure it sufficed.  thanks
<jodh> slangasek/hallyn: https://code.launchpad.net/~jamesodhunt/upstart/bug-980917-the-bug-that-would-not-die/+merge/118579
<ubottu> Launchpad bug 118579 in evolution (Ubuntu) "Unable to receive mail" [Medium,Invalid]
<jodh> ubottu: fail! ;)
<tkamppeter> Someone know how one generates the Release and Release.gpg files in a deb package archive?
<TJ-> tkamppeter: I was reading about this earlier. apt-ftparchive release
<TJ-> tkamppeter: I found it here: http://wiki.debian.org/SecureApt#Setting_up_a_secure_apt_repository
<seb128> Riddell, hi, can you update the lightdm packaging vcs with the diff of your update?
<seb128> Riddell, there was a change pending upload there as well, any reason you didn't include it?
<Riddell> seb128: mm sorry, I didn't notice it had a vcs branch, that was silly of me
<seb128> Riddell, no worry, thanks for fixing it ;-)
<tkamppeter> TJ, thank you very much.
<ev> mpt: how should errors with individual reports be handled in the multiple reports dialog?
<mpt> ev, you mean the process names, stacktraces etc?
<ev> mpt: for example: "this problem report is damaged and cannot be processed", "the report belongs to a package that is not installed", or the generic "an error occurred while attempting to process this problem report"
<mpt> oh, errors in the reports themselves
<ev> yes
<mpt> ev, so after you click either "Show Details" or "Continue", whoopsie discovers that sending the report will not be useful. Right?
<ev> yes
<ev> exactly at that point
<mpt> ev, do you still want to send "something happened, but we don't know what" to the server for accounting purposes?
<mpt> e.g. to measure the percentage of malformed reports over time
<ev> you know what, I'm just going to walk around this desk
<mpt> (Summary of desk conversation: we'll explain that the crash report was unreadable inside the details pane itself.)
<mpt> ev, https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=89&rev1=88
<infinity> tjaalton: What's the status of the xserver transition in -proposed?
<ev> mpt: excellent, thanks
<ev> mpt: if there's only one report and it's corrupted, should that "send an error report" checkbox disappear?
<tjaalton> infinity: there'll be a fixed nvidia upload tomorrow, then maybe xserver 1.13rc3 and another round of quick tests
<infinity> tjaalton: Alright.  Are all the drivers (including universe ones) transitioned?
<mpt> ev, I don't think so, because (a) that would shrink the alert possibly several seconds after you last clicked anything, and (b) you may eventually be sending as much as you know anyway
<ev> good points
<ev> thanks
<tjaalton> infinity: well, all the ones that xserver-video-all depends on it. I'll file an archive removal request for the rest, and check if there are others missing (like virtualbox..)
<infinity> tjaalton: I don't see the ARM-specific ones there...
<infinity> tjaalton: omap, msm-whateveritis, for instance.
<tjaalton> infinity: ahh, duh
<tjaalton> infinity: hmm actually, they probably need changes for the new abi, but I've no idea where to look for them
 * infinity sees at least:
<infinity> xserver-xorg-video-msm
<infinity> xserver-xorg-video-omap
<infinity> xserver-xorg-video-omap3
<infinity> xserver-xorg-video-omapfb
<infinity> For binary packages depending on xorg-video-abi-12
<infinity> tjaalton: http://paste.ubuntu.com/1134575/
<infinity> tjaalton: ^-- Might prove helpful?
<tjaalton> infinity: maybe, if I knew how to read it :)
<tjaalton> I know which ones to get rid of
<tjaalton> ok
<infinity> tjaalton: Those are just strict binary dependencies on the old ABI on each arch and in each component.
<tjaalton> yeah
<infinity> (-ivtv in multiverse seems to be another one I don't see in proposed)
<infinity> Unless that's on the list of removals.
<tjaalton> infinity: yeah, good point.. I do remember there being some issues with forgetting some of the drivers, so will be careful this time :)
<blitzkrieg3> cyphermox: ping
<ogra_> http://de.archive.ubuntu.com/ubuntu/pool/main/f/flash-kernel/flash-kernel_3.0~rc.4ubuntu15.dsc  416  Requested Range Not Satisfiable [IP: 141.30.13.10 80]
<ogra_> wow
<cyphermox> blitzkrieg3: pong.
<cyphermox> sorry, I was out to lunch
<blitzkrieg3> cyphermox: no problem at all
<blitzkrieg3> cyphermox: I was wondering what our options are with the wpa enterprise bug
<blitzkrieg3> bug 969343
<ubottu> Launchpad bug 969343 in OEM Priority Project "Unable to connect to WPA enterprise wireless" [High,In progress] https://launchpad.net/bugs/969343
<jocarter> jono: so how is it that the next UDS is 4 days?
<blitzkrieg3> cyphermox: I understand why you don't want to change the library in an LTS, but it seems like you can make it work if you disable the TICKET functionality in openssl
<cyphermox> blitzkrieg3: I've had a lot of trouble verifying that
<blitzkrieg3> hmm, so you've been testing with enterprise wireless and everything works?
<cyphermox> that said, I can give it a shot this afternoon again, just means I need to change locations
<cyphermox> blitzkrieg3: yeah, with my university network
<blitzkrieg3> cyphermox: okay, that changes things
<cyphermox> it was WPA-PEAP, with MSCHAPv2
<blitzkrieg3> maybe we can get the same device that the OEM is using and verify
<cyphermox> yeah
<blitzkrieg3> I don't doubt that it's a problem with the device, not with ubuntu, but either way it looks like a regression from a user point of view
<cyphermox> that might help, but I suspect it won't change a think, the encryption shouldn't be hardware-specific, since it's done in openssl
<cyphermox> yup
<blitzkrieg3> sounds like the hardware doesn't work well with new features, maybe it fails to account for stuff it doesn't know about
<blitzkrieg3> cyphermox: I'll talk to the guy experiencing the issue, thanks for your help
<cyphermox> but it's wifi hardware -- it doesn't need to know about encryption, just about pushing packets over the air and scanning
<blitzkrieg3> so it's should be the software behind the AP that doesn't work?
<cyphermox> blitzkrieg3: it's more likely to be an issue with the hardware used as an AP / the authentication server, which possibly uses a very different, very old version of SSL
<cyphermox> yes
<blitzkrieg3> got it, well we'll have to get those details then
<cyphermox> that's been seen before -- I'm not against fixing it with changing the way wpasupplicant speaks to openssl, but I can't test this, so I'd rather not change things blindly
<cyphermox> cool
<blitzkrieg3> cyphermox: of course, I'll get all the info/HW we need to reproduce it in house
<cyphermox> blitzkrieg3: great
<kalxas> hi all
<kalxas> I am trying to customize a xubuntu iso based on this https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations
<kalxas> I was able to rebuild the initrd.lz file
<kalxas> so that I have username and password set for the live session user
<kalxas> but I am not succeeding in changing the background image
<kalxas> can please someone give a hint on that?
<stgraber> superm1: ping
<superm1> hi stgraber
<stgraber> superm1: you probably noticed that slangasek rejected your mythtv upload. He commented in bug 1029522 about it. Would be good if you could fix and re-upload soonish so we can have it in the point release.
<ubottu> Launchpad bug 1029522 in mythtv (Ubuntu Precise) "Newer version of MythTV fixing some major bugs needs an SRU" [Undecided,Triaged] https://launchpad.net/bugs/1029522
<superm1> stgraber: ah okay sure
<slangasek> superm1: oh, you are around, just not on #-release - sorry, was lookin' for ya :)
<mterry> zul, this is a pile of MIRs!  :-/
<zul> mterry: sorry yeah i know
<zul> mterry: on the good side most should be trivial :)
<mterry> zul, haven't been bad so far
<zul> mterry: all the new packages have been done with MIR in mind to make your life easier at least
<mterry> zul, it's not relevant for these MIRs, but I notice you using debhelper 8 mode, instead of 9.  9's benefits are mostly cflags and multiarch related, so python doesn't care, but still.  Latest and greatest!
<zul> mterry: yeah ill have a look again
<mterry> zul, no reason to change unless you happen to be in the packages already.  Just something I noted, in case you missed compat mode 9 coming out  :)
<zul> mterry: yeah thanks
<slangasek> mterry, dupondje: have you seen the user comments in bug #1000356 that the bug isn't fixed?
<ubottu> Launchpad bug 1000356 in freerdp (Ubuntu Precise) "remmina/xfreerdp crashes while trying to use 'remote control'" [High,Fix committed] https://launchpad.net/bugs/1000356
<slangasek> mterry, dupondje: unless there's something else I've overlooked, I believe this SRU should be removed from precise-proposed
<mterry> slangasek, fair enough.  users certainly suggest it's not fixed
<slangasek> mterry: yep.  libfreedp1 is the right binary package they need to upgrade for the fix, right?
<slangasek> libfreerdp1
<mterry> slangasek, I'm actually not sure off the top in which of the freerdp packages the fixed code lives.  But the same source package as libfreerdp1 yes
<slangasek> mterry: well, I'm trying to pin it down to a binary package because there was some ambiguity on the part of the tester wrt which binaries they tested
<mterry> slangasek, ok, let me see
<slangasek> remmina-plugin-rdp only depends on libfreerdp1, so in the absence of other information to the contrary...
<mterry> slangasek, yeah that's the package
<slangasek> ok
<slangasek> verification-failed, then
<slangasek> too bad the test case requires windows :P
<dupondje> hmz, highlight didn't work
<dupondje> anyway slangasek
<dupondje> it seems indeed its not completely fixed yet indeed. But the feedback is more then yes/no
<dupondje> remmina 1024x768 -> rdesktop 1024x768 - seems to work fine now
<dupondje> remmina 1024x768 -> rdesktop 800x600 - seems to work fine too
<dupondje> in comment #12
<dupondje> so it seems to fix some cases, but not all
<slangasek> dupondje: oh, somehow I overlooked that.  Do you want to follow up to the bug pointing this out, and set the tag to verification-done instead?
<dupondje> slangasek: done
<slangasek> cheers
<dupondje> still freerdp should release a new version :( tons of things fixed/improved, but no new release yet
<anveo> Is this the correct channel for help with packaging?
<ScottK> anveo: There are several possibilities depending on exactly what you're after.  This is one of them.
<anveo> Well I'm trying to package the latest version of monit and put it in my ppa (which I just created) and I'm a little confused about the version string I'm supposed to use
<anveo> I'm basically just taking the package which has been created for quantal, and making it work in lucid
<ScottK> anveo: The best channel for that is #ubuntu-packaging.
<anveo> oh, perfect. Thanks!
<bdrung> here's a partial sponsors queue: http://people.ubuntu.com/~bdrung/sponsoring/
<bdrung> (the sponsors queue is hit by bug #1031764)
<ubottu> Launchpad bug 1031764 in Launchpad itself "timeout on code.launchpad.net/~ubuntu-branches" [Critical,Triaged] https://launchpad.net/bugs/1031764
<stgraber> mterry: just saw your comment on the watch file in ltsp-docs, it's indeed quite pointless when we're in sync with Debian, though in the past it was quite useful for all the other LTSP packages
<mterry> stgraber, yar, I figured it was for backporting ubuntu updates and such
<stgraber> mterry: LTSP doesn't do real "upstream" releases, instead whenever a distro wants a tarball, they tag it upstream. So the only place where you can find an "upstream" tarball is in the distros.
<mterry> stgraber, just not a construction I've seen before  :)
<stgraber> mterry: that's why we typically watch the Debian and Fedora package archive in Ubuntu and the Ubuntu and Fedora archive in Debian
<stgraber> so uscan can try to see if there's a newer tarball "somewhere"
<mterry> zul, is there a missing MIR for python-quantumclient
<mterry> ?
<zul> mterry: im thinking python-cliff ill get to it tonight
<mterry> zul, I'll pre-review it after python-clif
<zul> mterry: k
<mterry> zul, ah, I found the quantumclient MIR bug.  I just didn't see that didrocks had already commented on it
<zul> mterry: ah k
<ikepanhc> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: ikepanhc
#ubuntu-devel 2012-08-08
<zul> mterry: ping
<mterry> zul, hi
<zul> mterry, do you think a seperate package in python-cinderclient is really necessary? i packaged it like that so its conforming with the other openstack client packages (ex: python-keystoneclient)
<mterry> zul, not necessary no, just a suggestion.  I thought it was policy to keep only modules in python-* packages, but I'm not 100% on that
<zul> mterry: ok im going to leave it as it is the
<zul> er..then
<superm1> stgraber: i uploaded again earlier today, didn't mention
<OdyX> Hi. Could one with a recent Ubuntu test the proposed patch on the Debian bug #682032 (init_is_upstart behaviour in lsb_base's init-functions) ?
<ubottu> Debian bug 682032 in lsb-base "init_is_upstart warnings if upstart installed but not running" [Normal,Open] http://bugs.debian.org/682032
<alkisg> Hi, what's the best way to maintain a localized (greek) ubuntu iso with also a few more packages from main preinstalled?
<alkisg> I think I once saw a wiki mentioning an "official" method, but now all I can find is https://help.ubuntu.com/community/LiveCDCustomization which mainly suggests using uck...
<alkisg> Nothing that I can use locally with seeds etc? Maybe live-build is the way to go?
<lynxman> hey everyone o/ I have pbuilder for several dists installed on my precise desktop, I'd like to be able to use previously built packages that are in the pbuilder results dir to do the next builds per pbuild machine, any doc on how to setup pbuilderrc to do that?
<jamespage> lynxman, I do something similar with sbuild
<jamespage> I use reprepro to manage a local archive which the schroots that sbuild uses pickup
<jamespage> I install the results of each build into the archive - and they then get picked up by subseqent builds
<lynxman> jamespage: oh excellent, I needed to migrate to sbuild at some point anyway, could you send me some example configs for that?
<jamespage> lynxman, sure
<lynxman> jamespage: can't be grateful enough :) beer++
<geser> lynxman: you could bindmount the results dir into pbuilder and use this as an additional repository (or use reprepro with pbuilder)
<maxb> jamespage: Mind copying me on those too? _@maxb.eu
<maxb> I've done the bindmount thing with pbuilder in the past too, it works ok
<jamespage> maxb, I basically use the fact that sbuild bindmounts my home directory into the schroot to pickup the reprepro archive
<lynxman> geser: would that be possible just modifying my local .pbuilderrc
<jamespage> maxb, then I add "deb [arch=amd64] file:///home/jamespage/ubuntu-archive quantal main" to the sources.list in my schroot
<maxb> By just modifying the sources.list in the base chroot? Or any more interesting way?
<maxb> lynxman: Well, you'd have to get the results dir to actually have an apt index first
<maxb> http://paste.ubuntu.com/1135760/ <-- something to do that, from the depths of my ~/bin :-)
<lynxman> maxb: that shouldn't be an issue :)
<lynxman> maxb: can easily build a trigger there
<geser> lynxman: yes, through BINDMOUNTS in .pbuilderrc should work
<lynxman> geser: lovely, thanks :)
<cjwatson> zul: separate package in python-cinderclient> not vital for right now, but you might want to consider a separate package by way of planning for the future, because it'll make your life easier when switching to Python 3 - much the same reason why policy says we don't put binaries in C library packages, because the soname might change and then it'll be trouble.  We ran into this with software-properties ...
<cjwatson> alkisg: have you tried ubuntu-defaults-builder?
<alkisg> cjwatson: no, thanks, googling...
<tjaalton> how do I add a bug to the 12.04.1 queue, to make sure it's fixed in the release?
<cjwatson> alkisg: it was designed for the needs of localised ISO builders
<tjaalton> oh, by adding the milestone
<alkisg> cjwatson: thank you, reading the man page, will install and test it :)
<alkisg> Ah right that was the page when I first saw it being mentioned: https://wiki.edubuntu.org/DesktopTeam/Specs/Oneiric/LocalizedCDImageTools
<ikepanhc> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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:
<Laney> ev: mpt: Do you know when the new errors.u.c deployment is happening? I want to file a couple of bugs but they're kind of obvious so maybe you fixed them already.
<ev> Laney: we're somewhat stuck fighting dak at the moment. Not sure, but hopefully today/tomorrow.
<Laney> dak?!?!
 * Laney will wait a couple of days then
<cjwatson> Laney: the canonical-admin-team archive
<cjwatson> Laney: which I suspect is about 80% inertia and about 20% "it might not be the wisest thing ever to make the archive that Launchpad's own deployment relies on be hosted on Launchpad"
<jamespage> jbicha, OK if I merge eclispe? new rc in debian
<jbicha> jamespage: sure, the only reason I didn't was because I was hoping http://bugs.debian.org/679328 would have been fixed soon
<ubottu> Debian bug 679328 in eclipse "eclipse: FTBFS with glib 2.32+" [Normal,Open]
<jamespage> jbicha, it might make it "<nthykier> I believe we already picked up the ubuntu patch (see #679328), but it is currently not uploaded yet due to the freeze"
<Laibsch> I'm having a problem with a lucid pbuilder here. I keep getting "E: Failed to fetch http://ppa.launchpad.net/r0lf/stable/ubuntu/pool/main/a/autotools-dev/autotools-dev_20100122.1_all.deb: Size mismatch" even though size and md5sum match
<Laibsch> the information in /var/lib/apt/lists/ppa.launchpad.net_r0lf_stable_ubuntu_dists_lucid_main_binary-i386_Packages perfectly. :-/
<jbicha> yeah, it's not an RC bug for Debian
<jamespage> jbicha, hmm - so unlikely then
<jamespage> I guess it depends on whether 3.8.0 releases in time
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for 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: mdeslaur
<OdyX> Hi. Could one with a recent Ubuntu test the proposed patch on the Debian bug #682032 (init_is_upstart behaviour in lsb_base's init-functions) ?
<ubottu> Debian bug 682032 in lsb-base "init_is_upstart warnings if upstart installed but not running" [Normal,Open] http://bugs.debian.org/682032
<jodh> OdyX: by patch, do you mean the '/sbin/initctl version 2>/dev/null |grep upstart' ?
<jodh> OdyX: if so, yes it contains that string: http://paste.ubuntu.com/1136045/
<jodh> OdyX: bug updated.
<OdyX> jodh: many thanks !
<jodh> OdyX: np
<shogunri1k> hi, can I ask were to report a bug
<smoser> shogunri1k, http://bugs.launchpad.net/ubuntu/+filebug will work, but if you have an ubuntu system, the preferred way is to run 'ubuntu-bug'
<shogunri1k> how do I run ubuntu-bug?
<jocarter> shogunri1k: https://help.ubuntu.com/community/ReportingBugs/ - there's also an #ubuntu-bugs channel that could help you out
<shogunri1k> Thanks
<smoser> if you have a desktop, system you can hit alt-f2 and then type 'ubuntu-bug'
<smagoun> Maybe a dumb question, shouldn't the 'build failures' link in /topic point to http://qa.ubuntuwire.com/ftbfs/ instead of an out-of-date page?
<smoser> smagoun, you would seem to be correct. i dont know who here can change the topic.
<smoser> but now i have a dumb question of my own.
<smoser> i'm working on overlayroot. and i'd like to have the cloud -images carry a change to the default configuration file (/etc/overlayroot.conf)
<smoser> what is the preferred/correct way to make that change such that future package changes to that file do not force prompts on upgrade?
<smoser> the use of /etc/overlayroot.conf.local which is not installed by the package seems one option.
<smoser> but i'm certain this is a known problem.
<hallyn> slangasek: 'apt-get install qemu-user-static:i386 on x86_64 kills the system.  Is there any reason not to check the arch and not install binfmts on different arch?
* Himmagery changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: mdeslaur
<mdeslaur> smoser: anyone can change the topic in this channel IIRC
<smoser> well, that wasn't my question :) that was smagoun
<smoser> but good answer
<mdeslaur> smoser: d'oh :)
<mdeslaur> smoser: FAIL :)
<mdeslaur> smoser: one sec, adjusting eyeglasses
<smagoun> it's ok, we're both from michigan
<mdeslaur> smoser: so, you want to modify another package's conf file?
<smoser> well, its not "another package"
<smoser> i want the cloud image build process to modify that config
<smoser> to change the default behavior for that package for cloud images.
<mdeslaur> ah, I see
<smoser> i guess http://wiki.debian.org/ConfigPackages (dpkg-divert) is one solution.
<mdeslaur> smoser: hehe, I was just looking at that page :)
<smoser> or ucf (which i just want to avoid if i can)
<mdeslaur> smoser: I honestly don't know what the preferred way would be... cjwatson?
<smoser> i just dont like to bother him :)
<cjwatson> I don't know the answer to your question
<cjwatson> This has always been under "avoid at all costs because all of the known methods are unsafe" for me
<Laney> can overlayroot support a .d directory for config?
<cjwatson> Yeah, keeping the overrides in a separate file is in general better
<smoser> Laney, yeah, thats the other solution. but basically along the same lines as the .local file.
<smoser> i think that is what i'll probably end up doing. but if there was an overall better solution, i wanted to use it.
<Laney> Indeed. I don't think it's a bad solution. Having a directory offers more flexibility.
<Laney> For example you'll run into similar problems if admins have provided their own .local files already.
<Laney> How bad is it to have a source package which only ships a single transitional binary package?
 * cjwatson tries to remember how he reproduced bug 926340 last time
<ubottu> Launchpad bug 926340 in aptdaemon (Ubuntu Precise) "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Triaged] https://launchpad.net/bugs/926340
<smoser> Laney, yeah, i agree on .d format being nice. i'll see if i can do that.
<xnox> Laney: i do it all the time locally to satisfy dependencies when I have stuff installed from source, e.g. texlive
<Laney> I'm talking about the archive here :-)
<xnox> Laney: in the archive.... not sure. you will get lintian yelling 'empty package' =)
<Laney> I doubt it emits that for transitional packages
<xnox> Laney: why a separate source package and not build by the transition target source package, as it is usually done?
<xnox> or is in main -> universe movement and hence you need a transitional package in main?
<Laney> versioning hax would be required and it would make the package diverge
<mpt> xnox! I've missed you
<xnox> mpt: =)))
<xnox> well I am off to Olympics for 5:30pm until midnight. I am in tomorrow ;-)
<xnox> but will be busy.
<Laney> uploaded
<jocarter> have fun
<mpt> xnox, did you get a chance to review <https://wiki.ubuntu.com/DiskWarnings>?
<xnox> mpt: reading. Why 5GB limit on the 5% & 1%? the minimal desktop installation is 8GB
<xnox> mpt: "The disk is no longer nearly full. The alert closes by itself." Generally what can often happen: you have 10% of disk space
<xnox> you start the upgrade: download packages, unpack, install, clean up.
<xnox> during this process you run out of disk space, the upgrade fails, cleans up, and recovers some of the disk space.
<mpt> xnox, those numbers are straw-man proposals for you to tweak, but I don't see 5 GB anywhere. Where is it?
<xnox> although the disk space is now fine, it actually is not enough to complete the upgrade.
<xnox> mpt: 1% or less than 50MB -> assumes that 100% is 5 000 or ~ 5GB (as in small install); similarly 5% or less than 250MB -> assumes that 100% is again 5GB
<mpt> xnox, no, it says "both less than 1 percent *and* less than 50 MB"
<xnox> so upgrade fails due to disk space -> trying to upgrade again will fail again.
<mpt> xnox, combining relative and absolute is to avoid being nagged that you have, for example, "only" 100 GB left on a 10 TB drive
<xnox> i see.
<mpt> But like I say, the numbers are tweakable
<xnox> ok.
<xnox> what about the upgrade case.
<mpt> For the upgrade case, does apt take care of that already?
<xnox> "You attempted to upgrade or install new packages, which failed due to running out of disk space. Before attempting again you should prepare more free space!"
<xnox> no it doesn't.
<mpt> Why not?
<xnox> it just gives you
<xnox> "I/O Write Error" somewhere in the logs, fails with a cryptic "dpkg post-inst of $PACKAGE failed with error 254" and quits =)
<xnox> mpt: but potentially that type of thing should be in apt, update-manager or somewhere there.
<cjwatson> Ah, gotcha (aptdaemon)
<mpt> xnox, yes, that way it would help people using apt-get upgrade, or USC, or update-manager, or Synaptic
<xnox> cjwatson: mpt: sure or simply in aptdaemon
<cjwatson> Er, I was talking to myself :)
<cjwatson> About something else
<mpt> doing it in aptdaemon alone would help all of those except for those using apt-get
<xnox> cjwatson: your comment was applicable to two conversations ;-) simultaneously
<cjwatson> Talented that way, apparently
<mpt> cjwatson is just that good.
<mpt> But even if fixed in apt, aptdaemon should still catch that specific error and turn it into a nice alert.
<xnox> hmmm... true
<xnox> mpt: "you have recently created: 10GB AllPixarsMovies.zip and attempted to upgrade your system (3GB) which caused you to run out of disk space"
<mpt> "It's all your fault"
<mpt> I suppose it's too much to hope for, but it would be nice if there was a general API for "I'm about to need this amount of disk space, don't try to use it for anything else" ... like the disk equivalent of malloc
<mpt> So if you were doing an apt-get upgrade and a Firefox download and a torrent download at the same time, you wouldn't get contention for the remaining disk space.
<xnox> mpt: did you know about sparse file systems? =) they say they are 10TB big, but actually they are backed by a lot of zeros and a 100MB disk drive
<xnox> anyway....
<mpt> That sounds like <http://www.engadget.com/2011/04/11/rogue-modder-rips-off-stingy-consumer-puzzles-repairmen-all/>
<xnox> torrents usually do pre-allocation of the disk space. apt-get doesn't
<TJ-> Sparse files are great for pre-allocating large files... been using sparse allocation for a long time
<xnox> mpt: in Russia the disk drive saves you!
<xnox> =)
<TJ-> I used to use this kind of construct to create sparse images for VMs: dd if=/dev/zero of=sparse-file bs=1 count=1 seek=1024k
<mpt> nifty
<TJ-> See also cp --sparse
<TJ-> tar, cpio and rsync also support it
<mpt> I wonder if, say, Nautilus does
<slangasek> hallyn: as I recall, there was a reason not to; this has been discussed a couple of times, I don't remember if there's an open bug report though
<TJ-> mpt: I think not, there's a bug report for GIO https://bugzilla.gnome.org/show_bug.cgi?id=530094
<ubottu> Gnome bug 530094 in gio "Nautilus (gio/gnomevfs) performs unneccessary copying of sparse files" [Enhancement,New]
<mpt> TJ-, that's not quite what I was thinking of -- I was thinking more, if it's about to copy a 1 GB file, create a 1 GB sparse file first and then steadily fill it up with the data
<mpt> so that other programs don't try to use the space
<mpt> (if it's about to copy a file that isn't sparse to begin with, I mean)
<TJ-> mpt: Ahhh... I think the answer would be the same... since it can't create a sparse even for a sparse
<mpt> probably
<TJ-> That might be an easy patch to add... I may play around with that in the next week or so
<Diziet> gema: Hello.  I wanted to talk to you about our xen.org automatic testing.  Lars Kurth has been trying to introduce us.
<hallyn> slangasek: bug 1033964 was the one prompting me this time
<ubottu> Launchpad bug 917660 in binfmt-support (Ubuntu) "duplicate for #1033964 Installing qemu-user-static in an i386 lxc container applies the binfmt changes to the host, breaking execution in that host" [Medium,Confirmed] https://launchpad.net/bugs/917660
<slangasek> right
<hallyn> slangasek: they're not  a problem in containers as they don't have permissions to cause trouble, but you can brick a host pretty trivially...
<Diziet> (What an exciting-sounding bug.  Surely a security bug in the lxc containers?)
<hallyn> Diziet: no.
<slangasek> but you can do this in a chroot, and, how can we tell what the host architecture is then?
<hallyn> slangasek: I don't know, /proc/cpuinfo?
<cjwatson> IMO that's a bug in the kernel - binfmt_misc should be per-filesystem-context.
<hallyn> what do you mean by a fs context?
<cjwatson> It's enormously painful to work around this in binfmt-support, and I'm not sure it's even possible to do correctly.
<hallyn> cjwatson: i'm not either.
<hallyn> but postinst is pretty dangerous there
<cjwatson> Good question :-)  I'm not sure how to do it in the kernel, but what I actually want is for each chroot to have its own independent notion of what binary formats are associated with what executables, and for those executables to be executed within the same context as the binary that provoked binfmt_misc.
<cjwatson> Where by context in this case I mean /proc/self/root.
<hallyn> so a binfmt namespace really :)
<cjwatson> Yes.
<hallyn> do we have anyone going to ksummit who could bring this up?
<stgraber> hallyn: add it to the list after user, device and syslog ;)
<hallyn> stgraber: that puts it around 2018
<stgraber> hallyn: I'm attending half of the last day of the kernel summit, maybe some of the kernel folks actually attend all of it
<rbasak> mpt: TJ-: not sure if this is relevant, but fallocate(2) with FALLOC_FL_KEEP_SIZE would be nice too. This would mean that on ext4 the filesystem can allocate space too, so large files will end up less fragmented
<cjwatson> The only thing I can imagine being able to do in binfmt-support is to attempt to totally disable it in anything like a chroot, an lxc container, etc.  And I'm not convinced that wouldn't break things for other people who have come to rely on its current behaviour of constructing a sort of fuzzy union of all the binary formats anyone might care about.
<hallyn> cjwatson: containers aren't a problem here, apparmor protects the host from them
<hallyn> cjwatson: the bot just quoted the title from the dup'd bug, but the original bug i quoted is more worrisome
<cjwatson> Well, OK, but that in turn means that binfmt doesn't work properly inside a container for anyone who might actually want to use it.
<hallyn> just 'apt-get install qemu-user-static:i386' on any x86-64 host bricks it
<stgraber> well, my understanding is that there's nothing you can do in a chroot to add an extra binary format/architecture to binfmt, all you can do from a chroot is break things really badly
<hallyn> cjwatson: then they can tweak their apparmor profile
<cjwatson> Not really very out-of-the-box.
<hallyn> all i'm saying is that containers aren't the problem.
<cjwatson> Which was kind of the point of binfmt-support.
<hallyn> ok, i'll add binfmt namespacing (or somesuch) to the list of uds blueprints to raise.  maybe we can discuss this on halloween
<cjwatson> For the original bug: removing binfmt-support entirely would be incorrect, but perhaps qemu-user-static:i386 should stop delivering the particular binfmt entry for x86-64, or make that conditional on the running kernel, or something.
<cjwatson> It's Multi-Arch: none, so I assume something like a chroot must be going on ...
<hallyn> cjwatson: what i was thinking this morning was just having qemu-user-static.postinst not install the entries depending on (somethingorother)
<hallyn> no,
<hallyn> i don't need to be in a chroot... not sure what you mean
<cjwatson> Sure, you can manually install qemu-user-static:i386, but you have to be trying.
<cjwatson> For it to happen accidentally, a chroot is more likely.
<hallyn> have to be trying, or have to be confused about multiarch.
<hallyn> 'sure, i want the 32-bit qemu user binaries'
<cjwatson> I'd suggest that if [ "$(uname -m)" = x86_64 ], qemu-user-static.postinst should drop the x86_64 target.
<cjwatson> Perhaps even just it should drop any target from that list that matches uname -m.
<cjwatson> Likewise in prerm.
<hallyn> oh, is that the problem?  i thought it wsa the inverse :)
<hallyn> it sounds worth doing to me
<cjwatson> I believe so.
<cjwatson> I have a similar problem with qemu-user-static, although for me it isn't fatal.
<hallyn> and woudl this solve that?
<cjwatson> I run a 64-bit kernel with 32-bit userspace, in order that I can conveniently have 64-bit chroots without having to migrate the 32-bit filesystem I've had for ages.
<cjwatson> (And run 64-bit VMs, for that matter.)
<cjwatson> In order to make this work, I have to remember to disable qemu-user-static's x86_64 emulation.
<cjwatson> Actually, I have a temporary hack in /etc/init/binfmt-support.conf to do that.
<cjwatson> And yes, this fix would solve that problem too.
<hallyn> and uname -m shows x86_64 for you of course
<cjwatson> Indeed.
<cjwatson> Basically you want to avoid anything that matches either current userspace or the running kernel, I guess.
<cjwatson> Or anything that the running kernel can do without help.
<cjwatson> Which I guess must include current userspace (or else it's already being handled), so drop that bit.
<stgraber> is there an easy way of knowing "anything the running kernel can do without help"?
<stgraber> I'd be interested in that for a few other scripts ;)
<stgraber> (for example i386 can be run natively on some ia64, so it's not as simple as amd64/i386 on amd64)
<cjwatson> I was hoping nobody would notice the handwaving
<hallyn> ('a miracle occurs')
<cjwatson> Ideally the kernel would export this somewhere; otherwise I guess special-casing a few known ones would be fine really
<mpt> xnox, anyway, the errors I didn't cover were the Raid ones, because I didn't know what kind of errors there are
<mpt> Can you enlighten me?
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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:
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: herton
<slangasek> stgraber: nothing you can do in a chroot> you certainly can register binfmts from inside a chroot, and the paths are always resolved relative to the current root
<cjwatson> Unfortunately when you do that the results are visible outside the chroot too.
<cjwatson> It's good that resolution is relative to the current chroot; I can never remember, but of course it wouldn't generally work if they weren't
<stgraber> slangasek: oh, I missed the fact that the paths would be resolved relative to the chroot, I somehow assumed it wasn't
<slangasek> stgraber: they are - but the problem then is that you want to be able to actually register different ones inside vs. outside the chroot
<slangasek> (I think it should inherit though... otherwise you can't bootstrap a pure-foreign chroot)
<slangasek> i.e., if you set one up outside the chroot, then chroot, you want the settings to carry over
<game2> micahg: thanks for explanation.  I was hoping 12.04.1 would be a good rescue disk.  :-)
<micahg> game2: well, we don't include -backports packages on any images
<game2> micahg: yep :-(
<micahg> game2: you'd have to use quantal for something like that as it would have the newer version
<micahg> game2: anyways, WRT the backport, xnox will have to give you an update, I'm happy to review/approve/upload before the point release goes out though if it's ready
<iamfuzz> cjwatson, do you have time for a Partner push for old time's sake?
<game2> micahg: thanks.  I'm guessing it will not get much attention at the moment with 12.0.4.1 & q.  But I can always build it here if I need it.
<micahg> game2: if you're willing to do the testing, you can update the backport request and do all the tests it asks for
<game2> micahg:  That's a very reasonable suggestion :-/  I'll do what I can..
<seb128> hum
<seb128> does anyone has an issue with syncing make 2.82 from Debian experimental?
<micahg> seb128: there's no make source...
<seb128> make-dfsg
<seb128> http://packages.qa.debian.org/m/make-dfsg/news/20110718T091906Z.html
<seb128> fedora is using that version for 2 years
<micahg> seb128: ah, you're asking policy wise, not functionally :)
<seb128> I'm not a big fan of touching make but webkit fails to build with our version
<seb128> no, it's rather I'm asking in case somebody knows better than me and has a reason why we should stay on .81
<micahg> seb128: I hope you're not planning on updating to 1.9.6, it breaks API
<micahg> err...ABI
<seb128> micahg, https://bugs.webkit.org/show_bug.cgi?id=93477 you mean?
<ubottu> bugs.webkit.org bug 93477 in WebKit API "1.9.6 drops symbols, breaking compatibility" [Normal,Unconfirmed]
<micahg> yeah
<seb128> micahg, I opened that bug, and I ran into it while doing the update
<seb128> .symbols for the win
<micahg> sorry, I didn't notice you were the one who submitted it :)
<seb128> micahg, and do plan to update webkit eventually though, we can't stay on 1.9.2 for ever, I'm working with upstream to resolve build issues and abi compat issues
<micahg> seb128: ok, I'm hoping they'll have 1.10 in time for quantal's release?
<seb128> they will, they follow the GNOME release schedule
<seb128> they will have 1.10 in septembre
<micahg> cool
<micahg> seb128: is webkit part of the GNOME MRE?
<seb128> I doubt it is
<seb128> it has no reason to be
<seb128> they follow a similar schedule but that's about it, they don't have the same freezes, processes, release team, etc
<micahg> seb128: well, we need to make sure we end up with a stable version in our releases
<seb128> well, freeze are about features
<seb128> the Ubuntu freeze doesn't prevent you to take bug fix updates
<seb128> by the time we are in ff they will be as well
<micahg> is it usually feature frozen then before our feature freeze such that we don't need to worry?
<seb128> so 1.9.10 to 1.10 is a bug fix update
<seb128> around the same time
<seb128> I will ask for a ffe for 1 update if needed
<seb128> but has not been an issue so far
<micahg> ok, thansk
<stokachu> stgraber: could you have a look at my mp https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258
<stokachu> stgraber: i think its ready
<stokachu> herton: or if you got a second to review my mp
<stokachu> either way
<herton> stokachu, I can't check other packages, I just work/take kernel patches
<stgraber> stokachu: so that one needs to get into quantal + precise-proposed right
<stokachu> stgraber: yea
<stgraber> stokachu: can you add that rebuild list to the bug?
<stokachu> sure thing
<stokachu> done
<stgraber> stokachu: the breaks/replaces probably should be mentioned in the changelog entry too
<stokachu> stgraber: you mind adding that comment ot the mp so i can remember to do it?
<stokachu> stgraber: ive got some other builds running right now
<micahg> seb128: I guess the big question WRT make is why it's in experimental still after 1 year...
<seb128> micahg, it has a rc bug but upstream argued it's not a bug
<seb128> I will email ubuntu-devel about it
<SpamapS> err.. am I crazy for thinking its crazy to let the GPG key agent thing in quantal just leave keys loaded forever?
<seb128> SpamapS, it's a bug and will be fixed before release
<SpamapS> seb128: \o/
<seb128> SpamapS, I guess you refer to https://bugzilla.gnome.org/show_bug.cgi?id=681081 ?
<ubottu> Gnome bug 681081 in gpg-agent "gpg passphrase cached forever" [Major,Resolved: fixed]
<slangasek> superm1: has this mythtv upload been build-tested?  There's still a reference to debian/30-mythtv-sysctl.conf in debian/mythtv-common.install, which I would expect to cause a build failure
<rvr_> Hi
<rvr_> I'm trying to build a package using pbuilder. I created the base using sudo DIST=quantal pbuilder create. Nothing special (I have it running for precise). However, when compiling a package, I get this error: "dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native"
<SpamapS> rvr_: I've forgotten everything about pbuilder, but now might be a good time to give sbuild a try. Try 'mk-sbuild' in particular :)
<rvr_> SpamapS, I would prefer to "fix" the pbuilder :-/
<stgraber> stokachu: commented
<TJ-> rvr_: I wrote an article about using Pbuilder some time ago with some supporting scripts... maybe it will help you  http://tjworld.net/wiki/Linux/Ubuntu/Packages/CreatingPbuilderVariations
<SpamapS> Is there any reason to use pbuilder over sbuild (not trying to be argumentative, I'm truly curious)
<SpamapS> sbuild is whats used on the buildds.. so it seems logical to want to use sbuild over pbuilder
<TJ-> http://askubuntu.com/questions/53014/why-use-sbuild-over-pbuilder
<rvr_> SpamapS, The builds I manage have been running with pbuilder + precise for a while, and I'm just trying to make them run in quantal with the minimal amount of changes possible
<SpamapS> rvr_: sure. Just wondering why people choose pbuilder.
<SpamapS> I did use pbuilder just during the 10.10 dev cycle... but sbuild seemed to pull ahead for me in the end.
<rvr_> Someone spotted this problem weeks ago http://irclogs.ubuntu.com/2012/07/06/%23ubuntu-devel.txt (search for "build-essential:native")
<rvr_> jamespage, ping
<TJ-> rvr_: Looking at the man-page for pbuilder, --extrapackages claims the build-essential is installed by default
<SpamapS> rvr_: he's UK Time zone and likely AFK until UTC 0900
<TJ-> rvr_: Have you logged into the pbuilder and checked what is installed ?
<rvr_> TJ-, build-essential is installed, the problem is the ":native" architecture
<rvr_> that I don't know why it wants to install
<superm1> slangasek: doh, i was just trying to rapidly pull out the simple stuff, you're right.  i build tested the original, not the updated
<superm1> will sort it out later and do an actual build test with the changes
<TJ-> rvr_: commit 40d51dc36b23 introduced :native parsing to the scripts to fix debian bug 558095
<ubottu> Debian bug 558095 in dpkg-dev "dpkg: please accept ":native" multiarch qualifier in build dependencies" [Wishlist,Fixed] http://bugs.debian.org/558095
<rvr_> TJ-, Yeah, but that doesn't explain why pbuilder wants to install build-essential:native. And neither it is currently supported by apt in Quantal ATM
<TJ-> rvr_: what package is it you're trying to build?
<TJ-> rvr_: From reading the dpkg code, it looks like this will happen if the host and package arch are different
<slangasek> superm1: ok cheers
<TJ-> unless (defined($bd_value) or defined($bc_value)) {
<TJ->     $bd_value = 'build-essential:native';
<TJ->     $bd_value .= ", " . $fields->{"Build-Depends"} if defined $fields->{"Build-Depends"};
<rvr_> AFAIK, both are amd64
<TJ-> I think you've been hit by code that wasn't thoroughly thought through
<TJ-> The patch has this clue:
<TJ-> +=item build_dep (defaults to 0)
<TJ-> +
<TJ-> +If set to 1, allow build-dep only arch qualifiers, that is â:nativeâ.
<TJ-> +This should be set whenever working with build-deps.
<rvr_> :-/
<jamespage> rvr_, pong
<rvr_> jamespage, Did you resolve your issue with build-essential:native?
 * jamespage tries to remember
<jamespage> was that with hsqldb?
<rvr_> jamespage, Yes
<jamespage> I worked around it by dropping the native package
<jamespage> the combination of archs was confusing the buildd's
<rvr_> Were you building in different archs?
<jamespage> rvr_, hold on - I need to check again
<infinity> jamespage: Hrm?  What does that have to do with build-essential:native?
<infinity> jamespage: The hsqldb/buildd issue was parsing the Arch: line in the source.
<jamespage> infinity, trying to remember - rrd has overwritten that bit of my short term memory
<infinity> jamespage: Well, if you've seen something involving build-essential in some way, I'd like to know, cause it's like a dpkg bug I should fix. :P
<infinity> jamespage: But, AFAIK, it should all be sane now.
<jamespage> infinity, actually it was - I remember now
<TJ-> infinity: rvr_ has hit it today, and we found your discussion with Colin about it with a note you would revert or investigate
<infinity> TJ-: I did revert, and fixed build-essential instead, this was weeks ago.
<infinity> TJ-: Where's the breakage that was hit today?
<TJ-> rvr_ will tell you ... he hit it... I've been diving into the source to understand it
<infinity> rvr_: ?
<infinity> (Also, before we continue, is this on a native build, or a cross-build?  Cause if it's a cross-build, it's intentional that we expect build-essential:native to be installed)
<rvr_> infinity, Yeah, I'm trying to compile a package in pbuilder, and I get "dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native". Just tried pbuilder-dist and same issue.
<infinity> rvr_: Which version of dpkg-dev?
<infinity> rvr_: And, uhm, is build-essential installed?
<rvr_> Yes, it is installed
<infinity> rvr_: And is this a cross-build, or a native build?
<rvr_> Native, amd64
<infinity> (Also, while it shouldn't relate, pbuilder sucks, learn to love sbuild)
<TJ-> In my quantal pbuilder the dpkg-dev version is 1.16.7ubuntu3 ... and it has the  $bd_value = 'build-essential:native'; line in checkbuilddeps
<infinity> TJ-: Yes, as it should.
<infinity> rvr_: What version of build-essential is installed?
<TJ-> infinity: OK ... when you said revert I thought you were referring to the commit in the dpkg git
<rvr_> Let me check, but it's a quantal base created some hours ago
<infinity> TJ-: No, I reverted my workaround.
<TJ-> infinity: Ahh!!
<infinity> Again, though, this was all weeks ago, and the buildds would be broken if the above was actually happening for everyone.
<infinity> So...
<infinity> There's something bizarre specifically with your setup.
<TJ-> In my quantal pbuilder its build-essential 11.5ubuntu3
<rvr_> dpkg-dev                    1.16.7ubuntu3      all
<rvr_> build-essential             11.5ubuntu2        amd64
<infinity> Bingo.
<infinity> rvr_: That needs to be 11.5ubuntu3
<TJ-> rvr_: you need to update the pbuilder image
<infinity> rvr_: Your chroot is out of date.
<infinity> Way out of date.
<rvr_> It was created hours ago, how can it be?
<infinity> build-essential (11.5ubuntu3) quantal; urgency=low
<infinity>   * Revert the previous change, build-essential shouldn't be foreign.
<infinity>  -- Adam Conrad <adconrad@ubuntu.com>  Sun, 08 Jul 2012 15:43:24 -0600
<infinity> Don't ask me.
<infinity> Stale mirror?
<infinity> Very stale...
<slangasek> perhaps you built it from an out-of-date mirror?  or you built it from precise
<rvr_> Setting up build-essential (11.5ubuntu3)
<infinity> slangasek: Speaking of, I suspect we should still SRU the dropping of the M-A header from precise's build-essential.
<infinity> slangasek: Not that it has any wildly negative effect as-is, but the first time someone decides to play with a backported dpkg or something, we get the above drama. :P
<slangasek> infinity: go for it
<rvr_> Issue is gone! :)
<rvr_> infinity, TJ- Thanks for your help
<infinity> rvr_: NP.  You might want to find a mirror that isn't a month out of date. ;)
<rvr_> lol
<cjwatson> iamfuzz: not really around right now, but send me mail with the details, I guess?
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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:
<xnox> micahg: game2: what was the context for "WRT the backport, xnox will have to give you an update" What package is that about?
<micahg> xnox: from -release, btrfs-tools
<xnox> micahg: ah... well quantal is ok. precise is funny: kernel is way ahead the btrfs-tools
<xnox> micahg: and too late for .1
<micahg> xnox: for backports, .1 is irrelevant :)
<xnox> micahg: i am very busy at the moment. I will be doing some btrfs-tools work after the Q feature freeze
<xnox> micahg: it's on my todo list.... =)
<micahg> xnox: right, so I suggested that game2 pursue it until you have time :)
<xnox> micahg: good =) I am happy to sponsor
#ubuntu-devel 2012-08-09
<xnox> micahg: ah, catched up on my scroll back. Got the #-release now as well ;-)
<micahg> xnox: unless you suddenly got a backports hat, that won't be possible :)
<xnox> micahg: hmm... i am sure tumbleweed will resign my changes files...
<xnox> tumbleweed: is in backports team, right?!
<micahg> xnox: nope
<xnox> hmmm....
<micahg> xnox: but in that case, you're being sponsored
<micahg> xnox: but I appreciate the sentiment
<xnox> micahg: ah found it =) you! =)
<xnox> ;-)
 * Bluefoxicy tries to Ctrl+a to switch windows in gnome-shell
 * Bluefoxicy dumb.
<xnox> Bluefoxicy: It's M-x C-c C-c C-a   emacs people said it is consistent with frame, window and pointer navigation and does not conflict with GPS key bindings
<smoser> anyone know or able to enable logging of #maas to http://irclogs.ubuntu.com/2012/08/08/ ?
<smoser> s/know/know of how to/
<micahg> smoser: file a ticket?
<smoser> as in canonical rt?
<micahg> either should be fine I think
<wzssyqa> qemu-kvm depends ipxe (<< 1.0.0+git-20120202.f6840ba-2), while ipxe has version ipxe (<< 1.0.0+git-20120202.f6840ba-3)
<wzssyqa> why qemu-kvm can still be installed?
<wzssyqa> has version 1.0.0+git-20120202.f6840ba-3
<leo_> hello
<leo_> i have a problem with my tbuntu 12.10 alpha3 since yesterday after a update
<micahg> leo_: support in #ubuntu+1
<leo_> ok micahg
 * leo_ thx
<dholbach> good morning
<didrocks> hey dholbach \o/ welcome back (not sure when your holidays ended)
<dholbach> didrocks, today they ended - thanks :)
<didrocks> dholbach: good luck with the email catchup then! (and nice photos ;))
<dholbach> thanks :-)
 * dholbach hugs didrocks
 * didrocks hugs dholbach. Good to see you back! :)
<sladen>  dholbach
<sladen> morning dholbach
<mpt> ev, https://bugs.launchpad.net/ubuntu/+source/apport/+bugs?field.tag=classification
<seb128> ev, hey, I've some issues with errors.ubuntu.com, want to discuss it there or should I reply to your email for those?
<ev> seb128: apols for the delayed reply. I've just seen your email. I'll work on getting those fixed today.
<seb128> ev, I'm concerned that all detailed graphs have a 80% drop on 05/17/12, do you know what's up with that
<ev> seb128: not sure offhand - I'm going to look into it
<seb128> ev, thanks
<ev> damn you unicode
<ev> (that would be the month option not displaying)
<seb128> oh
<seb128> I though it would be timeouting ;-)
<ev> nope, but it is taking longer than I would expect
<ev> I have an open ticket to land some stuff I built around jmxtrans, so we can get graphite plotting cassandra usage
<ev> right now we're stuck with either assembling a twisted maze of tunnels or running cassandra's nodetool manually
<ev> and then when graphite lands, dormant code on errors.ubuntu.com will start plotting api calls too
<gema> Diziet: pong
<sladen> ScottK: did you work out a solution to your /opt ?
<sladen> YokoZar: did you work out a solution to your /opt ?
<seb128> ev, I can't select "12.10" in the version combo on errors.ubuntu.com as well ... I guess it's the same issue than selecting "for the month"?
<ogra_> seb128, wrt your thunderbird complaints yesterday, did we consider shipping postler ? or does that add massive amounts of deps ?
<seb128> is that the elementary stuff?
<ogra_> yep, the mail app is pretty slick
<seb128> I doubt anything gets close from tb in support, userbase, features, etc
<ogra_> yeah, it only can do mail via pop, imap, and gmail , no nifty extra features
<seb128> ogra_, it's also that tb brand,name is known, it's cross platform, and we can trust mozilla to deal with security issues and have a reliable schedule
<ogra_> well, i know the pro args for tb :)
<mpt> xnox, so ... Raid failures?
<xnox> mpt: yeah...
<xnox> mpt: there are three things about Raid:
<xnox> * individual disk failures (same as all of them) e.g. bad blocks, failure to read/write, etc
<xnox> * disk space warnings (as you already did)
<xnox> * and the only one Raid specific is: RAID is healthy; out of sync / syncing; degraded; destroyed; metadata out of sync;
<xnox> the first two will be done / sorted with other 'drive failures'
<xnox> notifications.
<xnox> the last one is special
<xnox> if a drive failed: (i) raid array is now degraded (ii) a drive needs replacement. After (ii) is done, it will be out of sync, and it will need (iii) syncing at which point the RAID array will be healthy once again (iv)
<xnox> for a very large array (e.g. 10TB) the sync can take day(s)
<xnox> then periodically raids are checked for consistency
<xnox> in this case the raid array can have: (i) healthy & clean (ii) dirty (iii) dirty and check in progress
<xnox> and there is a cron job that does this.
<xnox> (this, i.e. the checking)
<mpt> ok
<xnox> mpt: good, simples =) any questions? or can I run out for lunch ;-)
<mpt> xnox, two questions
<mpt> First, what do you mean by "degraded"?
<mpt> if it doesn't mean a disk block/read/write problem, and it doesn't mean out of sync
<xnox> mpt: the performance and reliability is now below, what is expected of the created RAID level. Hence the reality is less/degraded than the figures in the calculated table for example.
<mpt> xnox, what might cause that?
<mpt> and what can you do about it?
<xnox> for example removing one of the two harddrives which are part of RAID1 array
<xnox> or the harddrive silently failing to power-up
<mpt> ok, "One of the drives is missing" is fairly major
<xnox> well, not really =) it's just degraded =) you may have unplugged it on purpose
<mpt> Second question: Is there, and if not should there be, a UI for inspecting a Raid array's status? Whether it's out of sync, or syncing, or being checked, etc
<xnox> and if I have RAID1 with 2 drives + 1 spare (3 in total). I can unplug 2 drives from the running system and i am still fine.
<mpt> and how much longer it's going to take to do that
<xnox> mpt: yes there should be. I belive it should part of the current "Disks" utility
<mpt> xnox, is that installed by default in Q?
<xnox> which already does: disks, partitions, checking/restoring/wiping filesystems, doing S.M.A.R.T. checks, etc
<xnox> yes, it is part of gnome and has been since natty (memory fuzzy, it is in precise and quantal for sure)
<xnox> I do not know if it does RAID currently.
<mpt> Is it called "Disks" in 12.04? I don't see it on my machine
<xnox> If it doesn't, than it will be a spec/feature into that app.
<xnox> mpt: try "Disk"
<mpt> oh, "Disk Utility"
<xnox> I belive in precise it's, yeah "Disk Utility" but in Quantal it's "Disks"
<mpt> eww scrollbars
<mpt> ok, thanks xnox
<xnox> mpt: it has theming issues. It's uses white text on light gray background and similar low contrast combinations.
<xnox> s/ It's / It /
<xnox> oh one more question I missed. To come back to healthly from degraded mode: you need to (re-)add a harddrive & sync it.
<mpt> sure
<mpt> which is important but not urgent
<xnox> correct
<xnox> there are cases where "all is lost"
<xnox> e.g. RAID10 and two drives failes
<mpt> oh crikey
<xnox> e.g. RAID10 and two drives failed
<mpt> That error message will be fun to write
<directhex> the wrong 2 drives
<xnox> that means you lost 50% or less of your data
<directhex> you can lose 2 disks in raid10
<directhex> if they're the right 2
<xnox> directhex: mpt: ok. If two drives fail in RAID10 there is 1/3 chance that "all is lost" =)
<xnox> mpt: if 1 drive fails you are good to go, but you are half way to the game of Russian roulette =)
<mpt> Clearly the icon for the alert box should be a pair of dice
<xnox> mpt: to be honest the desktop may fail to show the alert if it is the "lucky" two drives =)
<xnox> so you can assume we are still fine, e.g. degraded but no data lost just yet.
<xnox> right, off to lunch
<jibel> stgraber, networkless upgrade from lucid to precise is still failing with todays alternate (bug 1029531)
<ubottu> Launchpad bug 1029531 in update-manager (Ubuntu Precise) "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,Fix committed] https://launchpad.net/bugs/1029531
<jibel> stgraber, the packages are the version from proposed excepted openoffice.org which is not on the CD and update-manager which is the version from precise-release
<jibel> stgraber, similar error, upgrade is blocked by launchpad-integration
<stgraber> jibel: that's expected, none of my uploads have been accepted to -proposed yet
<xnox> stgraber: hmm?! slangasek accepted them ~7hours ago
<xnox> or do I need an eye sight check =)
<jibel> stgraber, the packages (launchpad-integration, nspr, and update-notifier) on the CD are from proposed excepted update-manager and openoffice
<stgraber> oh ;)
<stgraber> I'm still half way through my e-mails, so I probably didn't see the accepts yet :)
<jibel> stgraber, update-mananager shouldn't make a difference in the resolver since it's a change in the blacklist
<stgraber> jibel: looking at the logs, openoffice is still in new, so that's certainly a problem (+ I need to seed the right packages after that)
<stgraber> jibel: without the new update-manager, the upgrader will still show a resolver issue but at least log it properly
<stgraber> I'll refresh my VM here and run a test in the background during the 12.04.1 meeting
<cjwatson> Anyone happen to have a recipe for referring to Fedora's equivalent of native packages in a watch file?
<cjwatson> http://pkgs.fedoraproject.org/repo/pkgs/lorax/lorax-18.12.tar.gz/523ff86ccdf0931d65aa29a9b0b89740/lorax-18.12.tar.gz is an awkward thing to link to
<jibel> stgraber, ack, I'll wait for openoffice
<cjwatson> Never mind; as it happens I think it isn't going to be worth it.  There're only a few dozen lines of code in there that are actually tricky.
<ogra_> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: ogra_
<stgraber> seb128: 12.04.1 meeting
<seb128> stgraber, thanks, I somewhat lost calendar integration with quantal
 * dholbach hugs ogra_
<ogra_> :)
<smoser> other people seeing broken dnsmasq or resolvconf?
<smoser> all i'm getting in dnsmasq's reslv.conf (/run/dnsmasq/resolv.conf) is 127.0.0.1 via network manager.  even adding my name server there didn't work. i've resorted to putting it in /etc/resolv.conf
<stgraber> smoser: IIRC resolvconf discards all other entries if one is 127.0.0.1
<smoser> why would one be 127.0.0.1?
<smoser> where would it be getting that. i'm 'certain my dhcp server is not saying 127.0.0.1
<stgraber> well, 127.0.0.1 would be the dnsmasq server started by network-manager
<smoser> ah. yeah. i gave the wrong file.
<smoser>  /run/dnsmasq/resolv.conf had that
<ion> I seem to have no such file. But i do have /run/nm-dns-dnsmasq.conf which refers dnsmasq to the right server.
<smoser> i have no such file like that.
<smoser> interesting.
<ion> What are the parameters to the dnsmasq process that is running?
<ion> 19914 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec
<smoser> well, i have 3
<mpt> huh
<mpt> xnox, a colleague just ran low on disk space, and the error message that came up turned out to be one I'd designed four years ago: <https://live.gnome.org/LowDiskSpaceWarning>
<smoser> i hit this too
<smoser> mpt, ^ running quantal, yesterday. space was being eaten by something.
<mpt> xnox, so why did you include it on your list? Are you planning to move the implementation somewhere else?
<xnox> mpt: good. Just one? or many?
<mpt> xnox, just one.
<xnox> mpt: ok. but there was no terminal  / server notification, etc.
<mpt> ok, that's a good reason
<mpt> xnox, but do you include in your plan getting rid of the old one?
<xnox> mpt: reusing as much as possible and/or improving.
<mpt> ok
<xnox> for example it does not come up if you run out of inodes.
<mpt> Just as long as we don't end up with 2009-era-mpt and 2012-era-mpt alerts appearing simultaneously
<smoser> mpt, i'm curious, was your colleague that saw that running quantal ?
<mpt> smoser, 12.04
<smoser> something ate 44G of space for me yesterday on quantal. after reboot i have 44G free, and i had maybe 1.5 free prior.
<smoser> mpt, so unrelated.
<mpt> (oops, 2009 was three years ago, not four)
<xnox> mpt: are you sure the 2009-era-mpt is not the 2014-era-went-back-in-time-mpt ?
<xnox> =)
<smoser> ion, stgraber this is reproducible for me
<smoser>  http://paste.ubuntu.com/1137879/
<smoser> any ideas?
<smoser> i honestly do not think i've changed anything in my resolvconf and dnsmasq on this system.
<stgraber> smoser: well, why do you have "dnsmasq" installed to start with (instead of just "dnsmasq-base")?
<smoser> stgraber, i probably installed some long time ago before dnsmasq-base was installed by desktop
<smoser> and, silly me, i've probably done that other places too
<stgraber> smoser: there's a known race between the dnsmasq init script in dnsmasq and the one spawned by network-manager that could explain what you're seeing
<smoser> would it be 100% reproducible?
<stgraber> "race", so no
<smoser> i'm not restarting dnsmasq each time i disconnect from the wireless and reconnect
<smoser> so i wouldn't have thought it would be in the picture
<stgraber> NM ships a workaround for that bug in quantal and I believe it's somewhere in the SRU pipeline for 12.04 too
<smoser> i am plugged in to a wired network and have known wireless available also. and NM is managing them both (its often buggy about that).
<smoser> i'm on quantal
<stgraber> hmm
<smoser> updated this morning. rebooted. no dns
<stgraber> cyphermox: ^
<cyphermox> yeah, that's the system dnsmasq started, no?
<cyphermox> NM's instance isn't started -- don't know why, or when it was tried; we'd need syslog
<smoser> cyphermox, you want /var/log/syslog or dmesg?
<cyphermox> syslog
<smoser> http://paste.ubuntu.com/1137901/
<smoser> kirkland, tyhicks . its a fun day on quantal.
<smoser> http://paste.ubuntu.com/1137902/ <-- kirkland and tyhicks.  i started seeing those ecryptfs issues yesterday again.
<smoser> they'd been away for quite some time.
<kirkland> smoser: I saw some chatter in #ubuntu-kernel yesterday about uploading a new kernel with ecryptfs patches
<smoser> joy.
<kirkland> smoser: I don't see cking or rtg around now
<kirkland> smoser: might be a little while before ogasawara comes online?
<cyphermox> also check if you have /etc/dnsmasq.d/network-manager
<smoser> yes.
<smoser> http://paste.ubuntu.com/1137905/
<kirkland> smoser: do you have a new kernel?
<smoser> i updated quantal this morning and rebooted. but i had seen some of those messages yesterday.
<smoser> but yesterday i was in low-disk-space scenario for some other bug. i'm not sure what bug it was that ate 44G of my home, but reboot gave it back.
<smoser> cyphermox, i realize i inadvertantly pasted dmesg.
<smoser> http://paste.ubuntu.com/1137909/ is syslog
<cyphermox> thanks
<cyphermox> smoser: your /etc/dnsmasq.conf probably contains enable-dbus?
<cyphermox> or some other such config, maybe in /etc/dnsmasq.d?
<smoser> GAH. and why do i hear a dog barking  every time i page down npaste the bottom of firefox, or hit tab in my gnome-terminal
<cyphermox> haha
<smoser> (the dog barking isn't the neighbors, its coming from my speakers)
<smoser> cyphermox, that would be a yes.
<cyphermox> awesome.
<smoser> i've used that before
<smoser> and likely i did add /etc/dnsmasq.d/enable-dbus
<cyphermox> right
<cyphermox> there's only one dbus name dnsmasq uses (for now)
<cyphermox> so if there's another instance started with it NM gets confused
<smoser> ok. thi smakes sense.
<cyphermox> I was about to start writing a patch to support setting a different dbus name
<smoser> also, i couldn't even get to the dnsmasq tha taws running on 127.0.0.1
<cyphermox> guess it just got bumped up the priority list :)
<smoser> (ie, 'host foo 127.0.0.1' would hang)
<cyphermox> yeah, because there isn't one being started :)
<smoser> well i have one running.
<cyphermox> on 127.0.0.1?
<smoser> i assumed the system one was.
<smoser> 6844 ?        S      0:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new
<cyphermox> no, it can't be
<cyphermox> because of /etc/dnsmassq.d/network-manager
<cyphermox> (bind-interfaces / except-interface=lo)
<smoser> ah. except-interfaces
<smoser> ok.
<smoser> ok. cyphermox yo uwant a bug opened?
<cyphermox> sorry, I realise it gets crazy with so many instances now
<cyphermox> smoser: yes, that would help a lot
<cyphermox> or anyway, can't hurt, at least we can track progress
<smoser> and i'm guessing the solution here is for me to remov ednsmasq (i'm not sure why I need it other than what NetworkManager's would provide)
<cyphermox> smoser: if you just remove the enable-dbus from your dnsmasq.conf or file in /etc/dnsmasq.d, it would be sufficient for things to work
<smoser> i'm guessing if i do that, then my 'enable-dbus' file is not going to be relevant.
<cyphermox> (plus restart network-manager)
<cyphermox> right
<smoser> ok.
<smoser> bug against ?
<smoser> what package
<cyphermox> network-manager
<smoser> k.
<cyphermox> I'll add a task to dnsmasq, but NM should start its instance on a custom bus name
<smoser> gah. does nyone know about this barking dog?
<smoser> i disabled terminal bell in gnome-terminal and that brought some sanity.
<smoser> but now firefox is doing it to me.
<mpt> xnox, so in summary, I think there are three kinds of Raid error to present: (1) missing component (2) non-dataloss component failure (3) dataloss component failure.
<mpt> At least that's what I understand from what you said
<cjwatson> smoser: System Settings -> Sound -> Sound Effects perhaps
<cjwatson> there's a "Bark" alert sound as one of the choices there
<cjwatson> (may be the default, not sure)
<mpt> xnox, with low-disk and Smart errors being presented as they would for a non-Raid disk.
<xnox> mpt: sounds good in theory. I wonder if I will be able to distinguish between them when implementing them =)
<smoser> cjwatson, well... yeah, but i didn't change anything :)
<smoser> maybe my low disk issues wreaked havoc
<smoser> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1034946
<ubottu> Launchpad bug 1034946 in network-manager (Ubuntu) "dnsmasq and network manager broken if dnsmasq package has 'enable-dbus'" [Undecided,New]
<smoser> ok. so its likely that i *did* change the sound to a bar.
<smoser> bark.
<smoser> but changing it back to "default" doesn't do anything. i'm guessing i have to log out and back in to have that take affect. and i probably changed it a week ago and just logged out and back in today.
<xnox> i think i got caught in unfortunate wost case scenario waiting time for the ppa publisher....
 * xnox fiddles thumbs
<Laney> https://xkcd.com/303/ s/compiling/publishing/g
 * xnox yeah! done
 * xnox juju deploy!!!!
<xnox> https://bugs.launchpad.net/ubuntu/precise/+source/python-boto/+bug/1034963
<ubottu> Launchpad bug 1034963 in python-boto (Ubuntu Precise) "shouldn't ship public module tests" [Undecided,New]
<xnox> no longer affects:	 python-boto (Ubuntu Quantal)
<xnox> no longer affects:	 python-boto (Ubuntu)
<xnox> but still
<xnox> affects precise series....
<xnox> interesting UI
<Laney> xnox: you know your buildd charm thing?
<xnox> Laney: yes.
<Laney> how easy would it be to turn it to mass no-change rebuilds?
<xnox> Laney: well it's an sbuild charm + parallel-ssh package and you have your mass no-change rebuilder =)
<Laney> like take list of packages, test, if build then rev revision and drop somewhere for signing
<xnox> Laney: with an extra script, sure.
<xnox> Laney: what for? =)
<Laney> http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<xnox> Laney: do you want it to run continiously as well?
<Laney> the more automatable the better i suppose
<Laney> but in the real world cloud burns cash
<micahg> I think that might not be a good idea to run continuously (unless it's for testing purposes and not uploading)
<xnox> Laney: let me finish full archive rebuild. and then ghc's will emerge from that
<Laney> I already have a rebuild.sh
<Laney> think I'll just put that on a 2xlarge :P
<infinity> Laney: Am I old skool in that I just do it with a shell for loop? :P
<Laney> I do it with parallel from moreutils
<Laney> but I thought xnox's thing might be more the shiny
<xnox> Laney: it may be shiny, but it still has no juice =)
<Laney> euca-run-instances -k laney --user-data-file ~/.hpcloud/buildd.sh -t standard.2xlarge ami-0000269b
<Laney> go go go
<shadeslayer> hmmm
<shadeslayer> cjwatson: I think I'll need a even newer live build package
<shadeslayer> because the current lb package assumes the initrd is compressed with gzip, whereas it's actually compressed with gzip
<shadeslayer> hacked around that by calling lzcat instead of zcat
<cjwatson> Might be an outstanding bug in quantal
 * dholbach hugs mterry
<mterry> dholbach, is this a reminder to patch pilot?  :)
<mterry> dholbach, ah this is for the UDW
<dholbach> no, thanks a bunch for your UDW session :)
 * mterry has learned to associate dholbach hugs with piloting
<mterry> You've Pavloved me
<dholbach> haha
 * dholbach hugs mterry
 * dholbach hugs mterry
 * dholbach hugs mterry
<mterry> heh
<tyhicks> smoser: what kernel version are you running?
<mterry> Am super busy today, but will either pilot later today or another day
<shadeslayer> cjwatson: it is, it's fixed in debian
<shadeslayer> debian bug 637979
<ubottu> Debian bug 637979 in live-build "wrongly assumes gzip initrd on ubuntu" [Normal,Fixed] http://bugs.debian.org/637979
<xnox> dholbach: i missed my last piloting due to holiday, but i did do some sponsoring today, need to write a report about it =)
<shadeslayer> cjwatson: the other issue being, when using lzcat it expects a initrd file that ends in .lzma
<cjwatson> shadeslayer: Probably just apply that locally for now then
<shadeslayer> cjwatson: already did
<cjwatson> lzcat -S '' or some such IIRC
<shadeslayer> ../binary/casper/initrd.img-3.5.0-8-generic:  unknown suffix -- unchanged
<dholbach> xnox, feel free to move it to whatever day suits you and use the "@ pilot" thing
<shadeslayer> hmm
 * shadeslayer looks
<cjwatson> I forget, read the manual :)
<smoser> tyhicks, it probably says in my dmesg :)
<cjwatson> You might need to pass it on stdin using a redirection rather than as a filename
<smoser> $ dpkg -S /boot/vmlinuz-$(uname -r)
<smoser> linux-image-3.5.0-8-generic: /boot/vmlinuz-3.5.0-8-generic
<tyhicks> smoser: 3.5.0-9.9, which is in -proposed, has my fixes for handling empty lower files
<smoser> tyhicks, thinks.
<xnox> dholbach: cool.
<smoser> thanks
<smoser> i'll try that.
<shadeslayer> lol
<shadeslayer> cat pictures on Debian patch tracker
<SpamapS> bdmurray: hey, I missed my SRU rotation yesterday with some other stuff. Lets try to coordinate so we don't stomp on eachother today
<smoser> tyhicks, http://paste.ubuntu.com/1138071/
<tyhicks> smoser: Sorry, not sure what's going on there. I just write the upstream patches. Don't really know anything about the Ubuntu kernel packaging.
<SpamapS> Aug  9 09:43:52 clint-MacBookPro kernel: [114490.088106] unregister_netdevice: waiting for lo to become free. Usage count = 1
<SpamapS> anybody ever see this on quantal?
<SpamapS> every 10 seconds
<smoser> tyhicks, the kernel is not in proposed
<smoser> only the metapackage
<tyhicks> smoser: This page says it is 2 hours old, so maybe it needs a little more time before everything shows up? https://launchpad.net/ubuntu/+source/linux
<smoser> its still buiding some arch.
<smoser> annoying that they'd put the metapackage up first.
<smoser> but yeah, it seems like it will get there eventually
<bdmurray> SpamapS: I was planning on this afternoon
<SpamapS> bdmurray: ok I'll wrap mine up this morning then
<ogra_> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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:
<infinity> smoser: Firing and forgetting linux+linux-meta to proposed is fine, since we don't expect people to run proposed in dev releases anyway. :P
<slangasek> rather, we insist that people not run proposed in -dev releases :-P
<mhall119> slangasek: is there a URL or API where I can get a list of patches we currently apply to a package's original sourcecode?
<mhall119> meaning, Ubuntu patches and Debian patches
<mhall119> achuni told me there was something on Launchpad that would show me that
<slangasek> mhall119: well, for any package, https://launchpad.net/ubuntu/+source/<src_pkg>/<ver>/ will include a download link to either the .diff.gz or the .debian.tar.gz
<infinity> mhall119: Not all packages use the same (or any) patch system, so "list of patches" isn't gonna happen, but yes, the source is always available, as slangasek points out.
<slangasek> right
<Laney> Depending on what you want, there is http://ubuntudiff.debian.net and http://patches.ubuntu.com
<slangasek> you get the monolithic delta against upstream, and this may be in a format that you can easily break out the list of patches from debian/patches/series
<slangasek> but it may not
<infinity> Laney: That's just deltas between Ubuntu and Debian, though.  Ish.
<zumbi> doko_: ayt?
<infinity> mhall119: Anyhow, anything that isn't the orig is, essentially, "the Debian and Ubuntu patches".  Except in cases where there are multiple upstream tarballs. ;)
<Laney> yep. then combine with patch-tracker.debian.org :P
<mhall119> is there any consistent way I could get this info?
<Laney> oh, there is also the census stuff from pabs
<mhall119> or are there a bunch of different ways and I'll have to detect which one to use
<zumbi> doko_: just wondering if you saw gcc package split patch we talked about
<slangasek> mhall119: the latter
<mhall119> darn
<slangasek> the majority of packages will have debian/patches/series
<slangasek> but the corner cases are myriad and ugly
<infinity> The "corner cases" are probably half the archive.
<Laney> it's a big corner.
<infinity> And there are plenty of people who prefer v1-style packaging (without any patch systems at all) because that's inherently more VCS-import-friendly.
<slangasek> infinity: nah, http://upsilon.cc/~zack/stuff/dpkg-v3/ shows over half the archive is 3.0 (quilt)
 * Laney heats up the BDs for a while
<slangasek> 2/3 even
<Laney> er, buildds
<infinity> So, again.  Breaking it out into "individual patches" is a goal I think you'll just fall flat on.  But if you just want to know "what's our delta from upstream", that's easy.
<infinity> slangasek: There's a shocking number of v3(quilt) that uses --single-debian-patch.
<slangasek> hahaha
<infinity> slangasek: And by "shocking number", I mean "more than one", which shocks me.
<mhall119> infinity: I like easy ways, what is it?
<slangasek> infinity: in which case, the list of patches has 1 element in it
<Laney> there's more to 3.0 (quilt) than quilt
<slangasek> mhall119: that's what I pointed you to already
<slangasek> the debian.tar.gz or diff.gz for the package (whichever exists)
<infinity> slangasek: Sure, but it's not quite what mhall119 was asking for, I suspect.   If he's happy to just know "the delta", rather than individual fixes, that's, like I said, much simpler.
 * Laney feels slightly responsible for mono's use of it.
<infinity> Laney: Bad.
<shadeslayer> cjwatson: W: Bootloader on your architecture not yet supported by live-build.
<shadeslayer> W: This will produce a most likely not bootable image (Continuing in 5 seconds).
<shadeslayer> any ideas on how to fix that?
<mhall119> infinity: I'd rather a list of patches,  but if a single large diff would be easier and more consistent across packages, I'd take that
<infinity> mhall119: Basically, a source package is a .dsc that describes the source files.  It'll point to a .orig.tar.$compress, and a bunch of other files.
<infinity> mhall119: In most cases, those other files (diff.gz, debian.tar.gz, etc) are "the delta".
<infinity> mhall119: The rare corner case (see libreoffice) is where it references a ton of tarballs that are all part of the upstream source.
<mhall119> ok
<zumbi> is doko still in vacs?
<infinity> zumbi: Nope.
<infinity> zumbi: It is past the old man's bedtime, though.
<shadeslayer> maybe because I'm building the i386 CD on a amd64 machine
<zumbi> infinity: ok, thanks, we'll try to catch him tomorrow
<Laney> mhall119: What's the goal here, out of interest?
<mhall119> Laney: to be able to tell upstreams what exactly we have that is different from their source
<infinity> Did the community team just volunteer to forward all my patches, so I don't have to?
<infinity> This is how I prefer to read the above.
<mhall119> A list of patches would be nice in that case, since they can choose which individual changes make sense to apply to their source
<mhall119> infinity: nope :)
<mhall119> infinity: but if the upstream wants to get their latest version into Ubuntu, we are working on a way to tell them what exactly we've done differently
<infinity> mhall119: Well, in MOST cases, debian.tar.gz or diff.gz will really all just be packaging fluff anyway.
<infinity> mhall119: While we do patch a lot of packages (and some quite heavily), most of the deltas are things upstreams shouldn't care about in the first place.
<infinity> And when the delta is somehting that should be upstreamed, we're failing if we're not doing it through proper channels.
<Laney> powerpc  2 41 jobs (9 hours 30 minutes) :(
<infinity> (And the proper channel isn't a dump of "here's our changes, have a look")
<infinity> Laney: It'll catch up.
<infinity> Laney: Did you have something specific you were waiting on?
<Laney> Haha. I don't doubt that.
<Laney> Just haskell.
<infinity> Oh.  Yeah, that can wait.
<infinity> Sounds like weekend fun anyway.
 * Laney pays tribute to sulfur
<Laney> (also sulphur)
<infinity> Laney: sulfur ain't coming back, unless someone does something heroic.  The photo I saw seems to imply that the OF image is wedged and needs fixing.
<infinity> That said.  Hrm.  All my IBM PPC kit has a backup firmware switch.
<infinity> Maybe I should walk IS through that.
 * infinity completely forgot about that when he was shown the "hahaha, sux 2 b u lolz" photo of the console.
<Laney> jcastro: Is there any limit to usage on this HP cloud trial?
<Laney> ie can I leave this 2xlarge running because I'm too lazy to set it up again next time or even to script its setup?
 * DebolazW is impressed at how little memory compiz is using nowadays.
<DebolazW> It used to be an all-devouring beast.
<mhall119> Laney: careful, if you let on that the setup can be scripted he'll want you to write a juju charm
<Laney> the world's least charming charm
<shadeslayer> hah
<infinity> slomo: gstreamer1.0 seems to have universally hung on all 5 arches in quantal (while building just fine on all arches in experimental... fun)
<infinity> slomo: Any interest in sorting out WTF?
<dobey> oh noes. no barry
<infinity> slomo: /build/buildd/gstreamer1.0-0.11.93/tests/check/libs/.libs/lt-gstnetclientclock appears to be the hanging culprit.
<infinity> slomo: Based on the filename (I haven't looked at the actual test), could this relate to the fact that the Ubuntu buildds can't see the outside world?
<slomo> infinity: can they communicate with 127.0.0.1 on port 1234 via udp?
<infinity> slomo: Yes.
<infinity> Nothing on 127.0.0.1 is restricted.
<slomo> ok, then it must be something else :) i don't see much in that test that could cause it to hang *forever*
<slomo> after some minutes it should just fail with a timeout from the test runner
<infinity> You'd think, right? ;)
<slomo> (some == 2 minutes iirc)
<infinity> Defintely forever here, though.
<infinity> On all 5 arches, no less.
<infinity> Which is special.
<infinity> But comforting that it's not arch-specific.
<slomo> the test itself is forked from the test runner, and after the timeout it kills the process
<slomo> so there must be something really weird going on here :)
<infinity> slomo: Let me spin it up quickly in a quantal sbuild here and see if it reproduces.
<infinity> slomo: In other news, that build doesn't fail when the testsuite fails. >:(
<infinity> slomo: Had to do some heroic post-kill killing to stop it from completing blindly on two buildds after killing the hung test. :P
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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: mterry
<slomo> infinity: yes, that's intentional. the testsuite runs only for informational purposes and fixing things later, not to fail the build :) i'm looking at the build logs afterwards
<infinity> slomo: Kay, reproduced locally, so it's nothing to do with the buildd's network setup.
<infinity> [pid 16939] futex(0x2b10ec0015c0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
<infinity> [pid 16938] futex(0x2b10eb4939d0, FUTEX_WAIT, 16939, NULL
<slomo> infinity: ok, so it's something that is different between debian and ubuntu... yay
<infinity> ^-- Just sitting there.
<slomo> infinity: you don't have backtraces of both processes i guess?
<infinity> I just killed them.  :P
 * infinity redoes the build.
 * xnox is recompressing the archive using none, gzip, bzip2, lzma, xz & xz-extreme
<xnox> 19.56% done
<micahg> I was thinking to see if there's an easy way to see on the ISO what's compressed with which algorithm
 * micahg figures recompression might save xubuntu's ISOs from being oversized
<xnox> alternative cd?
<xnox> or live? or both?
<micahg> well, ATM everything is oversized, the alternate less so, and the funny thing is, that's where compression will help the most
<xnox> micahg: i happen to have a hadoop cluster optimised for this type of job =)
<xnox> micahg: but my results are for each package, so we could compare it, once it's finished.
<xnox> it is not analysing compression method at the moment
<infinity> slomo: http://paste.ubuntu.com/1138419/  <-- Backtraces of the two processes.
<xnox> and it is running against precise archives
<micahg> xnox: right, that + a list of what's compressed with what on the ISOs would do it
<xnox> ok.
<xnox> so we are good =)
<xnox> 23% in half an hour.
<xnox> maybe i should have added more nodes =)
<xnox> too late now
<slomo> infinity: and the other threads, especially of the second process?
<Laney> xnox: main+universe?
<infinity> slomo: http://paste.ubuntu.com/1138429/
<infinity> slomo: (It only has two threads)
<xnox> Laney: 42813 binary debs, yes main+universe
<slomo> infinity: thanks, i'll try to understand that tomorrow... doesn't make much sense right now how this can happen :)
<Laney> nice
<Laney> what is this cluster of which you speak?
<xnox> Laney: hpclud - 54 instances: one juju minion, one master minion, and 52 worker minions
<xnox> it's hadoop
<xnox> with dumbo (python api, to write mappers & reducers in python ;-) )
<Laney> oh ok
<xnox> with settings tweaked and bugs solved until it works =)
<shadeslayer> cjwatson: what's LB_BOOTLOADER for building the CD?
<shadeslayer> grub? syslinux?
<slangasek> jamespage: I just dropped a comment in bug #1014864; would like to see the latest fix from quantal included in the SRU
<ubottu> Launchpad bug 1014864 in walinuxagent (Ubuntu Precise) "[MIR] New package - walinuxagent" [High,Incomplete] https://launchpad.net/bugs/1014864
<bdmurray> SpamapS: Did you get through all the pending-sru.html for precise?
<jamespage> slangasek, sure - I did request it be rejected for that reason (only noticed that was an issue yesterday I think)
<slangasek> jamespage: ok :)
<jamespage> slangasek, fresh backport in the NEW queue....
<Bluefoxicy> does fstrim ever do anything bad?
<Bluefoxicy> I'm thinking it may be wise to have a cron job that runs fstrim every day
<Bluefoxicy> but detecting trim-enabled disks is semi-reliable
<Bluefoxicy> options are either detect trim-enabled disks and trim them OR just trim everything
<Bluefoxicy> also it's good to see that a question about general UI design on the mailing list immediately turns into a long-running flamewar about whether Unity sucks or not.
<Bluefoxicy> People got their priorities straight.
<Bluefoxicy> Figuring out how to make things better should never come before bashing the things you like least.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for 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:
<mterry> will be back!
<cjwatson> shadeslayer: I expect you need to pass the --bootloader option with some argument that isn't "none".  See 'man lb config'.
<cjwatson> shadeslayer: We use syslinux for BIOS-booting our CDs at the moment.
<shadeslayer> cjwatson: right, I know, I just wanted to confirm which bootloader does ubuntu use with the livefs, and I believe it wasa syslinux
<shadeslayer> right
<shadeslayer> that's what I'm using :)
<shadeslayer> cjwatson: thanks for all the help
<shadeslayer> cjwatson: I owe you a beer at UDS :P
<cjwatson> ISO building - as opposed to plain squashfs building which is what we use in production - is a bit rough :-/
<shadeslayer> right
<UndiFineD> hmmm, how would that work in the near future, with uefi ? maintain both syslinux or grub on iso
<shadeslayer> cjwatson: plus live build seems to lag behind the packages in debian
<shadeslayer> which also causes issues
<ScottK> Is there an easy way to remove all packages not needed for ubuntu-standard?
#ubuntu-devel 2012-08-10
<infinity> ScottK: Use deborphan, and tell it to keep ubuntu-standard, perhaps?
<tjaalton> any sru-team members around?
<dholbach> good morning
<slomo> infinity: gstreamer1.0 should build fine now (just uploaded -2)
<infinity> slomo: Thanks!
<rbasak> How does one switch a package conffile from conffile to manually managed in maintainer scripts? Just doing it makes dpkg think that the file is obsolete after upgrade. dpkg-maintscript-helper seems relevant and mentions this case, but it doesn't seem to fit "removing a conffile" nor "moving a conffile" which seem to be the only two cases documented.
<Sweetshark> seb128: for bug 1034558 and bug 1034560 we need to prepare an LO upload soon.
<ubottu> Launchpad bug 1034558 in pentaho-reporting-flow-engine (Ubuntu) "[MIR] libbase-java, libsac-java, libxml-java, libflute-java, libpentaho-reporting-flow-engine-java, liblayout-java" [Undecided,New] https://launchpad.net/bugs/1034558
<ubottu> Launchpad bug 1034560 in libserializer (Ubuntu) "[MIR] libloader-java, libformula-java, librepository-java, libfonts-java, libserializer-java " [Undecided,New] https://launchpad.net/bugs/1034560
<seb128> Sweetshark, don't you plan to upload 3.6 soon anyway? :-)
<Sweetshark> seb128: yes, I have that one ready. Should I just give you one for uploading? the components mismatch will go crazy, but better now than two days before ff, right?
<seb128> Sweetshark, how come we won those depends between rc3 and stable?
<Sweetshark> seb128: bug 992232
<ubottu> Launchpad bug 992232 in libreoffice (Ubuntu) "no libreoffice-report-builder in precise" [Undecided,Fix released] https://launchpad.net/bugs/992232
<seb128> Sweetshark, seems like we could do longer without it and should not block 3.6 on that?
<Sweetshark> seb128: you mean no reportbuilder in quantal main?
<seb128> Sweetshark, was it in precise main?
<Sweetshark> seb128: no but they bitched me in doing an extra ppa rebuilding full LibreOffice only for this small extension
<seb128> Sweetshark, well, it's not a regression then, I would recommend you keep it off until the MIRs are resolved
<seb128> or check with the MIR team if they can review,approve that stack soon
<Sweetshark> IIRC there was at least on of those packages needlessly using crappy maven ...
<seb128> Sweetshark, so please keep that off
<Sweetshark> seb128: k
<Sweetshark> seb128: I dropped a note in the bug.
<seb128> Sweetshark, thanks
<stokachu> stgraber: i got that mp updated with changelog and posted rdeps testing to bug, if you get a chance today could you give it a lookover?
<xnox> micahg: http://people.canonical.com/~ubuntu-archive/transitions/sqlite.html
<xnox> micahg: 37 packages should drop build-deps? 245 are still to fix?
<stgraber> stokachu: can you paste me that URL again?
<stokachu> sure
<stokachu> stgraber: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258
<rbasak> How does one switch a package conffile from conffile to manually managed in maintainer scripts? Just doing it makes dpkg think that the file is obsolete after upgrade. dpkg-maintscript-helper seems relevant and mentions this case, but it doesn't seem to fit "removing a conffile" nor "moving a conffile" which seem to be the only two cases documented.
<Peace-> hi
<Peace-> why in the world if i install ffmpeg i get ffmpeg from libav that is deprecated?
<rbasak> ogra_: ping
<Peace-> my software are all messed up
<ogra_> rbasak, on the phone atm ...
<rbasak> ogra_: ok, np
<rbasak> ogra_: for when you're done... I think your recent flash-kernel changes might have caused a regression
<infinity> Peace-: Since when is libav deprecated...?
<Peace-> infinity:
<Peace-> ffmpeg version 0.8.3-4:0.8.3-0ubuntu3, Copyright (c) 2000-2012 the Libav developers
<Peace->   built on Jul 30 2012 22:10:17 with gcc 4.7.1
<Peace-> *** THIS PROGRAM IS DEPRECATED ***
<Peace-> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
<infinity> Peace-: Yes... And?
<Peace-> infinity: and it doesnt work at all
<infinity> Peace-: ffmpeg is deprecated, not libav.
<Peace-> infinity: really ? i can compile ffmpeg
<Peace-> why i have to be forced to use avconv?
<rbasak> ogra_: I've filed bug 1035269 - please could you take a look when you can?
<ubottu> Launchpad bug 1035269 in flash-kernel (Ubuntu) "highbank quantal installer regression" [Undecided,New] https://launchpad.net/bugs/1035269
<Peace-> i think the guys i have made this shit is very stupid , if you like use avconv but you should not force people to use it instead of ffmpeg that is currently developed
<Peace-> then when yoi install ffmpeg
<Peace-> you get that is not ffmpeg
<infinity> Peace-: Take it up with libav/ffmpeg upstream.  And please keep the anger and profanity to a minimum.
<Peace-> infinity: ffmpeg is developed
<Peace-> so it's not a ffmpeg issue
<Peace-> but a distro issue
<Peace-> and there is no way to get the real ffmpeg on ubuntu right now
<Peace-> you have to git clone and compile it
<rbasak> Isn't that decision made by debian and not ubuntu?
<Peace-> debian is ubuntu  ?
<Peace-> at least someone should provide a ffmpeg version on ubuntu
<rbasak> ubuntu is derived from debian.
<Peace-> so it's not debian
<Peace-> i use ubuntu , so i ask in the ubuntu channel
<Peace-> really i use kubuntu but this is a shell program btw
<rbasak> Your request to do something different in Ubuntu than Debian is valid, but I'm not sure it's worth maintaining such a big difference from Debian over this.
<ScottK> Peace-: When I suggested you ask here, I was anticipating you'd do it more politely and productively.
<rbasak> Since any difference needs to be supported and maintained.
<Peace-> ScottK: i have lost hours to do my software
<ScottK> And since the people who do the maintenance work on both distros are the same people, it'd be really odd for them to change.
<Peace-> and now i find out that there is no way for users to get the ffmpeg
<Peace-> and here they are saying to ask to debian ?
<Peace-> bah
<ScottK> Peace-: I understand frustration, but incivility is not productive.  It doesn't help solve your problem.
<rbasak> You'd need to achieve consensus about this kind of change before it'll happen. The people with the biggest voices are the people who actually do the maintenance work.
<ScottK> Peace-: I think what you ought to do is figure out how to support both libav and ffmpeg.  The reason I suggested talking to siretart is he might have a suggestion on how to go about that.
<Peace-> ScottK: incivility is to say it's not an ubuntu issue
<Peace-> or if i have a problem i should ask to debian devel
<ScottK> It's not an area we're likely to diverge from Debian on.
<rbasak> I did not say that it's not an Ubuntu issue. I said that the primary decision is made on Debian, and for Ubuntu to diverge is exceptional.
<rbasak> (and unlikely)
<Peace-> you have not to diverge , there is ffmpeg => install ffmpeg , you wann avconv install avconv
<Peace-> but here if you install ffmpeg you get avconv 0_0
<infinity> It's not that simple, with the switch to libav as a backend provider.
<infinity> Though, I'm sure there are ways to make ffmpeg and libav coexist in peaceful harmony, no one's put that work in, that I know of.
<Chipzz> Peace-: from the looks of it you get a malfunctioning ffmpeg, but you don't get avconv?
<rbasak> I understand your frustration, but the primary place to fix it on Debian, since most changes on Debian propogate to Ubuntu (and I think this would), and we try to stay as close to what Debian do as possible.
<siretart> Peace-: the 'ffmpeg' package in ubuntu exists only for transitional to help programs that are already in ubuntu. it will go away in the near future
<Chipzz> siretart: was there a transitional period were ffmpeg simply emitted a warning instead of not working? or is that what it currently does?
<Peace-> rbasak: i don't think i can get any support in debian btw
<Peace-> Chipzz: it works but doesn't recognize some options
<Peace-> it's a complete mess
<siretart> Chipzz: no, it does not.
<Chipzz> Peace-: I don't know how it was lately, but ffmpeg has never been known for their stable API. maybe this is a problem with upstream instead of with ubuntu?
<siretart> Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs break
<Chipzz> siretart: wait, am I reading this right? you want to ENSURE breakage?
<vibhav> Are there any *easy* "C oriented" bugs that one can help in Ubuntu?
<siretart> Chipzz: the ffmpeg program nowadays received a number of command line updates that requires changes to existing programs that we package. it's all about compatibility
<siretart> sorry
<Peace-> siretart:  Chipzz [mpeg2video @ 0x8558e60] Unable to parse option value "mv0"
<siretart> Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs *do not* break
<Peace-> and that string worked before
<Chipzz> ah, ensuring breakage would be quite baffling
<Peace-> anyway
<siretart> Peace-: this is not the best place to discuss individual bugs.
<Chipzz> Peace-: the ffmpeg maintainers were infamous for breaking stuff in the past. who's to say the problem isn't upstream?
<Peace-> Chipzz: the main stuff has always worked
<Chipzz> Peace-: from what I understand of this discussion, there's 2 issues: a) ffmpeg breaking some command line options and b) ffmpeg being deprecated and ubuntu *WARNING* about that
<mpt> vibhav, <https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize> is a list of bugs that have been marked as easy. I don't know of any simple way of telling which packages are written in C and which aren't.
<Peace-> no the issue it's that i want ffmpeg instead i get another stuff
<Chipzz> Peace-: not 100% sure I'm getting this right, but I don't think the warning causes the breakage
<Chipzz> Peace-: no you didn't. you got a version of ffmpeg where a couple of options have been broken
<Peace-> you can joke as you want
<vibhav> mpt: let me see
<Chipzz> I'm not joking. you however are misstating the facts
<Peace-> but the stuff it's this change in this section is a very mess
<mpt> vibhav, but once you have bzr installed, "bzr branch lp:ubuntu/name-of-package" will get you a copy of the package to look for yourself.
<vibhav> mpt: yeah, I know that :)
<mpt> ok :-)
<ogra_> rbasak, hrm, you dont use normal server images i guess ... good catch, the diversion should actually only show up when live installer is used ... seems it doesnt
<rbasak> ogra_: thanks, shall I leave it with you?
<rbasak> ogra_: you can reproduce on highbank in our lab
<rbasak> ogra_: or me or mahmoh can test for you if you like
<ogra_> rbasak, err, wait, flash-kernel-installer actually removes the diversion before running
<cjwatson> ogra_: the diversion ought to work with or without live-installer - that was certainly my intention when I suggested this approach
<ogra_> (and i see it doing that properly in your syslog
<ogra_> )
<rbasak> I can't figure out why update-initramfs does nothing, or whether the kernel postinst ends up not calling it
<ogra_> cjwatson, yeah, i was mislead, its all fine on the flash-kernel side
<rbasak> Either way, it doesn't seem to end up running
<ogra_> Aug 10 14:34:06 in-target: Can't find /boot/vmlinuz-3.5.0-9-highbank or /boot/initrd.img-3.5.0-9-highbank
<ogra_> Aug 10 14:34:06 flash-kernel-installer: error: flash-kernel failed
<cjwatson> rbasak: the intention is for it to do nothing until the installer is ready for it to do something
<ogra_> i would assume this is the reason
<rbasak> ogra_: the reason is far above that
<cjwatson> rbasak: no
<rbasak> no?
<rbasak> At the stage that flash-kernel runs, the initrd doesn't exist
<cjwatson> rbasak: the behaviour at the base system installation step is intentional
<cjwatson> the initramfs is supposed to be generated later
<rbasak> cjwatson: ok, understood
<rbasak> at what point should it be generated?
<ogra_> i guess f-k-i should run update-initramfs before running flash-kernel here
<cjwatson> right about the point that it's failing
<ogra_> (or not run f-k at all and just raly on the trigger)
<ogra_> *rely
<cjwatson> ogra_: agreed, it should run update-initramfs I think
<rbasak> So it's still a bug in flash-kernel?
<cjwatson> rbasak: yes
<ogra_> rbasak, right, just in a different place
<cjwatson> ogra_: well, it may need to think a bit to work out which kernel to run u-i for
<cjwatson> since I suspect -u won't work, as there's no initramfs yet
<ogra_> right, but there will only be one kernel
<rbasak> Yes - I tried -u manually after the install failed, IIRC.
<ogra_> and it has version detection code
<cjwatson> ah, of course, I had seen
<cjwatson>                 in-target update-initramfs -u || true
<ogra_> update-initramfs -c && flash-kernel i guess ...
<cjwatson> and forgotten that that would now be insufficient
<cjwatson> I think you should amend that line to check for the no-initramfs-yet case
<ogra_> (-c doesnt call the hook (upstream decision))
<rbasak> I'm at the failure point now, I can easily test something
<rbasak> One question: can I get in-target to print output to the console? It redirects to syslog it seems right now
<cjwatson> flash-kernel-installer.postinst already takes care of running flash-kernel later, so I don't think you need to worry about whether the hook is called or not
<ogra_> ah, yeah
<cjwatson> rbasak: for all the stuff here, you can just run chroot /target ...
<ogra_> (the above was from top of my head)
<rbasak> cjwatson: that's what I did but then it complains about /sys, so I had to bind mount that
<rbasak> I'll do that :)
<cjwatson> rbasak: although you can use in-target --pass-stdout
<cjwatson> which is the direct answer to your question
<rbasak> in-target --pass-stdout update-initramfs -u returns nothing
<rbasak> but doesn't create the initrd
<cjwatson> I wouldn't expect it to
<ogra_> you need -c and the version
<rbasak> right
<ogra_> in-target --pass-stdout update-initramfs -c $(uname -r)
<cjwatson> With -v, it would say "Nothing to do, exiting."
<mahmoh> well, a link to the non-existent initrd is created
<rbasak> http://paste.ubuntu.com/1139416/
<arges> micahg, hello. I think I have a backport bug properly formatted, was wondering if you could take a look at pad.lv/943502 to see if this can be put into the queue. thanks
<ogra_> rbasak, try -c -v
<rbasak> ogra_: no joy: http://paste.ubuntu.com/1139424/
<cjwatson> think you need -k $(uname -r)
<ogra_> oh ... yeah
<ogra_> or -k all
<rbasak> in-target --pass-stdout update-initramfs -c -v -k $(uname -r) worked
<ogra_> -k all should actually be fine so we dont need to rely on versions in that call and leave it to u-i
<rbasak> Agreed - but to test I'll want to redo the test from scratch
<ogra_> do that :)
<rbasak> I'm on it :)
<ogra_> though its really intresting that apparently -u behavior changed
<ogra_> in the past it just created one as if you had called -c
<rbasak> It was news to me that -u even existed, but I might be misremembering
<ogra_> -u is used since forever
<rbasak> IIRC I just ran update-initramfs and it updated it as per the name
<cjwatson> update-initramfs -u has been there forever, and I'm not sure I agree with ogra_'s recollection :)
<ogra_> cjwatson, i know i could use it with just -u in lucid at least
<ogra_> it behaved like -c -k all
 * rbasak clearly doesn't run update-initramfs very often
<ogra_> (that was always my workaround for upstream refusing to call triggers from -c)
<cjwatson> just looking at the oldest version I can find and I don't see this
<cjwatson> are you absolutely sure that in such cases an initramfs didn't exist already?
<ogra_> not absolutely, no
<cjwatson> update-initramfs -u has always picked one of the currently-existing initramfses to update if not told explicitly (exactly which one it picks has changed), but I don't see that it ever updated all of them
<mahmoh> cjwatson: quick ?: do you know of a way to force patman's last partition to a fixed size - avoid filling the disk?
<cjwatson> mahmoh: you must create a dummy partition at the end, and then remove it in a manner of your choice at the end of install (preseed/late_command or whatever)
<cjwatson> there is no way to do this natively in partman, I'm afraid
<cjwatson> I mean, without such a hack
<ogra_> cjwatson, oh, i didnt say that, i said it created one if there wasnt one
<cjwatson> ogra_: I looked at the version in lucid and don't see that :)
<mahmoh> cjwatson: thx, just confirming the hack I guess :) :(
<ogra_> cjwatson, hmm, that one has set_initramfs() ?
<cjwatson> ogra_: after the [ -z "${version}" ]
<ogra_> it might have been a bug that it did create them but i'm pretty sure i used -u to create one for ac100
 * ogra_ also remembers that he was wondering for years why -c exists 
<mahmoh> cjwatson: what's a reliable way to remove a partition from the installer env?
<rbasak> parted /dev/sda rm 4? But it's not in the installer and I'm not sure sfdisk is either
<cjwatson> yeah it is
<cjwatson> anna-install parted-udeb
<cjwatson> and then, yes, you probably want to use parted for this; it will involve accurately predicting the disk name and partition number I'm afraid
<mahmoh> cjwatson: thx
<rbasak> parse /target/etc/fstab, perhaps?
<rbasak> But a bit horrible to detect UUID= and LABEL= and I have no idea if /dev/disk/by-uuid will exist
<cjwatson> You probably don't want the dummy partition to be in /target/etc/fstab
<cjwatson> Since you wouldn't want to give it a mountpoint
<rbasak> I was going to look for another partition that is mounted on the same target disk
<cjwatson> Ah, yeah, could do.  /dev/disk/by-uuid/ will exist
<cjwatson> Might be easier to just df /target or something
<rbasak> Good point
<cjwatson> Or grep ' /target ' /proc/mounts
<mahmoh> if by-label exists I can just use that
<cjwatson> Whatever the syntax is
<cjwatson> by-label exists
<mahmoh> sweet
<cjwatson> Er, I'm not sure partman lets you assign labels though?
<mahmoh> it does
<mahmoh> label{ DELETEME }
<cjwatson> Ah yes
<cjwatson> Hidden off in the per-fs code so I didn't notice it
<rbasak> Good news, everyone! http://paste.ubuntu.com/1139467/ - "in-target --pass-stdout update-initramfs -c -k all" works as expected.
<cjwatson> Lose the --pass-stdout for production code of course
<cjwatson> Is it intentional that there's no suffix on the initramfs there?
 * cjwatson doesn't know the subarch configuration here
<rbasak> I'm not sure what you mean. But something didn't work. I see an initrd in /target/boot, but the installer still fails, which it didn't do last time
<rbasak> Err, no it didn't create an initrd. I saw the vmlinuz-... and assumed
<rbasak> It does return exit status 0 though
<arges> hello. whats the process to get a new package added? looking to get a version of libhugetlbfs in lucid. i see its in natty onwards (and it cleanly can be built with backportpackage)
<rbasak> With -v, "Nothing to do, exiting."
<rbasak> So the only known way right now is with -k $(uname -r)
<rbasak> "The use of "all" for the version string specifies update-initramfs to execute the  chosen  action  for all kernel versions, that are already known to update-initramfs.". I suppose update-initramfs doesn't yet know about this kernel, so we do need to use -k $(uname -r)?
<rbasak> arges: do you know about https://wiki.ubuntu.com/UbuntuBackports?
<arges> rbasak, yea I was going to do a backport... but the package doesn't exist in lucid at all... wasn't sure of the right path
<arges> looks like the code hasn't changed in a while, as all version from natty->quantal are the same
<rbasak> I think that's OK but I'm not sure
<stgraber> stokachu: your branch is based on the wrong bzr branch. As that's a desktop package, the base is lp:~ubuntu-desktop/gnome-vfs/ubuntu
<stgraber> stokachu: the diff applies cleanly on it, so I'm just going to merge it into that one for you
<rbasak> ogra_: ^^
<ogra_> rbasak, hmpf, i just uploaded with -k all
<rbasak> ogra_: sorry
<ogra_> rbasak, did you start the install from scratch fixing f-k-i before you did hit the error ?
<ogra_> i know sometimes there are bindmounts of dev sys and proc in /target after an error occured that can make the installer fall over
<rbasak> ogra_: I reinstalled from scratch, hit the error, and then -k all doesn't create the initrd even though I said it did earlier because I didn't look carefully (sorry).
<rbasak> I did only in-target --pass-stdout update-initramfs -c -k all
<rbasak> Last time, it did work with -k $(uname -r)
<rbasak> I can reinstall from scratch again if you like to verify and make certain? It's all scripted so isn't any trouble, just takes half an hour
<ogra_> rbasak, if you could inject the fix before it errors, that would be good
<rbasak> ogra_: at what stage exactly?
<ogra_> i dont see a reason why all wouldnt work
<rbasak> We did just enable ssh so I can do that
<ogra_> any stage before f-k-i gets called
<ogra_> just to avoid it hitting the error
<rbasak> OK but after the kernel gets installed I presume
<rbasak> We have remote syslog working too so I should be able to manage that
<ogra_> indeed :)
<rbasak> Just to be sure, you mean to ssh and try "in-target update-initramfs -c -k all" after kernel install and before f-k-i?
<ogra_> well, you will just edit f-k-i.postinst i guess
<ogra_> you shoudl be able to do that at any time once the f-k-i.udeb is in place
<rbasak> With -k all or -k $(uname -r)?
<stgraber> stokachu: uploaded to quantal
<ogra_> doesnt matter if teher is a kernel already ... as long as the fix and kernel are there if it gets executred :)
<ogra_> rbasak, -k all please
<rbasak> ogra_: any particular place in the postinst?
<ogra_> we know that $(uname -r) works, but update-initramfs has its own version detection logic i would like to use instead of hardcoding for the boot kernel d-i uses
<stokachu> stgraber: thanks
<ogra_> rbasak, http://paste.ubuntu.com/1139494/
<rbasak> ogra_: right
<ogra_> rbasak, in the fs you will find it in /var/lib/dpkg/info/flash-kernel-installer.postinst
<rbasak> ogra_: thanks
<ogra_> (and you have to use nano, no vi in d-i)
<rbasak> aargh
<rbasak> That might be tricky
 * rbasak will see what he can do :-)
<ogra_> haha, nano isnt that bad :)
<ogra_> (i agree its not fun either)
<stokachu> stgraber: https://bugs.launchpad.net/ubuntu/precise/+source/libart-lgpl/+bug/977964 i think this one is ready to go as well
<ubottu> Launchpad bug 977964 in libart-lgpl (Ubuntu Precise) "Please transition libart-lgpl to multi-arch" [Medium,In progress]
 * rbasak considers submitting a vi udeb
<stgraber> stokachu: ok. I'll push gnome-vfs and that one to precise-proposed then
<stgraber> stokachu: gnome-vfs should be identical to the quantal upload I just did right? (except for the release and pocket)
<stokachu> stgraber: exactly
<stgraber> stokachu: ok, gnome-vfs uploaded to precise-proposed then
<ogra_> rbasak, i would be surprised if cjwatson didnt acutally have a vi.udeb given he is an extensive user ;)
<stokachu> stgraber: sweet :D
<cjwatson> ogra_: you'd be surprised, then :)
<cjwatson> I do use vi extensively but I have to cope with minimal environments often enough that I've learned to (barely) tolerate nano
<ogra_> heh
<rbasak> So my first nano problem isi that I didn't know how to jump to line 71, so I hope I've applied ogra's patch in the right place :)
 * rbasak grepped the file afterwards to make sure
<rbasak> Change injected, now waiting for the install to finish
<ogra_> there is only one actual update-initramfs call in the script
<ogra_> (the second mentioning is a comment)
<ogra_> as long as the line you changed ends in || true ... all is fine
<rbasak> Yeah that what the grep was for - to check :)
<rbasak> http://paste.ubuntu.com/1139512/
<cjwatson> I occasionally use extremely obscure sed invocations instead of nano
 * rbasak did consider that just now
<rbasak> I wonder if there's a patch to sed converter
<stgraber> stokachu: debdiff in the libart bug isn't up to date. Can you attach one with the bug reference?
<stokachu> stgraber: instead of the MP?
<stokachu> ill do whatever you prefer
<stgraber> stokachu: oh, I missed that it had a MP
<stgraber> stokachu: sorry, will use that then
<stokachu> stgraber: thats cool i just linked the related branch a min ago into the bug
<ScottK> cyphermox: re Bug #1030316 - Postfix upstream has already decided it's the client's responsibility to convert the domain to punycode, so if it stays a postfix but, I'll have to mark it wontfix.  I think it should stay with evolution, but didn't want to just revert your change without discussing.
<ubottu> Launchpad bug 1030316 in postfix (Ubuntu) "evolution don't hadle IDN-Mail adresses" [Undecided,New] https://launchpad.net/bugs/1030316
<ogra_> rbasak, heh so instead of changing the existing call you added an update-initramfs call
<ogra_> shouldnt do any harm though
<rbasak> ogra_: really?
<rbasak> ogra_: I don't see it
<ogra_> you seem to have edited around line 30
<stokachu> stgraber: shit i didnt update my maintainer email for that changelog
<stokachu> lol
<ogra_> the actual call is around line 74
<stgraber> stokachu: that's fine, I fixed it ;)
<stgraber> stokachu: you also forgot to run update-maintainer and the version should have been ubuntu0.1
<ogra_> or your serial output simply messed it up or so
<stokachu> stgraber: or update-maintainer
<stokachu> stgraber: err yea you got it faster than me
<rbasak> I did it via ssh
<rbasak> http://paste.ubuntu.com/1139512/
<stgraber> stokachu: resulting debdiff, let me know if that looks good: http://paste.ubuntu.com/1139518/
<stokachu> stgraber: lol thanks i rushed it
<stokachu> stgraber: looks good
<stgraber> uploaded
<stokachu> you da man
<stokachu> stgraber: do these MP's automatically get flagged as uploaded
<stokachu> or is it still a manual process
<rbasak> ogra_: AFAICT the edit I intended is consistent with the grep output
<rbasak> Though I admit I have no idea what line number I edited since I presume ^G doesn't work in nano!
<cjwatson> ^C
<rbasak> thanks
<rbasak> Line 74 then
<ogra_> oh
<stgraber> stokachu: hmm, nope. Let me mark it as merged
<ogra_> sorry, blind me i didnt get thats a grep
<ogra_> i cought that was a copy/paste from your nano session
<rbasak> Ah
<stgraber> stokachu: they get marked as merged automatically when they are actually merged. Which isn't the case for these ubuntu-desktop branches or for SRUs
<ogra_> so it looked pretty weird how the functions were suddenly merged into one :P
<rbasak> No - I just did the grep to make sure there weren't any other similar occurrences because I didn't know what line number I was on
<rbasak> tell you what:
<rbasak> f5cbd5a8ff6202eca1a28187138d9e96  flash-kernel-installer.postinst
<rbasak> :)
<ogra_> heh
<rbasak> "Making the system bootable"
<ogra_> ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu18$ md5sum debian/flash-kernel-installer.postinst
<ogra_> f5cbd5a8ff6202eca1a28187138d9e96  debian/flash-kernel-installer.postinst
<ogra_> :)
<rbasak> 33%
<rbasak> !! ERROR: Installation step failed
<ubottu> rbasak: I am only a bot, please don't think I'm intelligent :)
<rbasak> :-(
<ogra_> rbasak, syslog please
<rbasak> on its way
<ogra_> thx
<stokachu> stgraber: ok cool
<rbasak> ogra_: http://paste.ubuntu.com/1139531/
<bkerensa> bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
<bkerensa> No branches have diverged?
<ogra_> rbasak, i dont see it running at all
<rbasak> ogra_: line 3017?
<ogra_> thats the fallout
<rbasak> well with -k all, it doesn't produce any output
<rbasak> since it considers there to be nothing to do
<rbasak> which we see if we add -v. Is this what you mean?
<ogra_> hmpf, ok, i'll switch to $(uname -r)
<rbasak> ok
<ogra_> uploaded
<rbasak> ogra_: thanks! sorry for the extra upload
<ogra_> well, i still would like to have -k all working ... but thats for later :)
<stokachu> cjwatson: any feedback on latest comment on https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/904014
<ubottu> Launchpad bug 904014 in netcf (Ubuntu Quantal) "[MIR] netcf" [Medium,Fix released]
<rbasak> OK :)
<rbasak> EOD
<cjwatson> stokachu: I've followed up
<cjwatson> stokachu: make sense?
<stokachu> cjwatson: i think so :)
<stokachu> cjwatson: i think there is a huge user base that would benefit from having precise updated , at least by this bug https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386
<ubottu> Launchpad bug 520386 in libvirt (Ubuntu Quantal) "libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge" [High,Fix released]
<cjwatson> stokachu: although I'm on ubuntu-sru, I don't do a whole lot of SRU processing in practice, so in this case I'm probably not the one you need to convince
<cjwatson> stokachu: for the purpose of this bug I'm basically the archive robot
<cjwatson> stokachu: have a look through https://wiki.ubuntu.com/StableReleaseUpdates and see if you can come up with a justification that matches the "When" section there
<cyphermox> ScottK: np.
<ScottK> cyphermox: I'll switch it back then.
<cyphermox> I'll ship that upstream
<ScottK> Upstream evolution, right?
<cyphermox> yeah
<ScottK> cyphermox: Here's a reference: http://tech.groups.yahoo.com/group/postfix-users/message/266018
<ScottK> The poster is one of the two main postfix devs.
<cyphermox> alright
<ScottK> Thanks.
<cyphermox> ScottK: are you switching it back to evolution?
<ScottK> I will.
<ScottK> cyphermox: Done
<stokachu> cjwatson: ok will do, thanks for the tip
<micahg> arges: you can't backport from quantal straight to oneiric, you can to backport through precise
<micahg> arges: requestbackport in ubuntu-dev-tools will tell you what you need to do if you pass it the proper options
<arges> micahg, ok with this particular package i had to fix something with the debian/rules file upstream. that was fixed and put into quantal
<arges> micahg, so do I need to apply that fix to precise, then backport to oneiric?
<micahg> arges: you can backport to precise and then oneiric, or SRU to precise if appropriate and backport that to oneiric
<arges> micahg, the change, btw, is to debian/rules because this package likes to check the version string and fail if it doesn't match. so I 'm guessing this is an SRU to precise to fix debain/rules rather than a backport
<micahg> arges: right, I remember that
<micahg> arges: so, the package currently in precise won't build if updated without this fix?
<arges> micahg, we can only backport from quantal because that version has the proper debian/rules version regexp
<micahg> arges: right, but for oneiric, you can only backport from a pocket in precise, so, you have to get it there one way or another
<arges> micahg, ok so if i backport from quantal to precise. then i can backport the backport? : )
<micahg> right :)
<arges> okey dokey
<micahg> arges: well, it ends up a no change backport from quantal, but you have to keep the upgrade path, that's the concept
<arges> should i make a new bug for this? or just use the existing one?
<micahg> arges: 'requestbackport -d oneiric -s quantal whois'  might make it clearer what work needs to be done
<arges> micahg, also. the version string is 'whois_5.0.17' in quantal. the backportpackage appends ~series1  but shouldn't it append -ubuntu1~series1 ?
<micahg> arges: it'll now be ~ubuntuXX.XX
<arges> micahg, ok i'll get that going then. thanks
<micahg> arges: you can use backportpackage to test what the version will be
<micahg> arges: actually, quantal has 5.0.18
<arges> micahg,  whois_5.0.18~precise1 is what it does
<micahg> arges: you have an old version :)
<arges> micahg, i'm on my precise desktop... will move to quantal laptop
<micahg> arges: I use the u-d-t PPA
 * micahg is still on precise
<arges> micahg, cool adding ppa now thanks
<arges> micahg, so there is a new naming convention for backports? the version regex i changed assumed the form -ubuntuX~series1  vs ~ubuntu12.04.1 ... so should I ask upstream guy to change the version string again (or ask that it be removed)? or is there a way I can patch debian/rules for  ubuntu?
<cjwatson> the new naming convention is ~ubuntu12.04.1 tc.
<cjwatson> *etc.
<micahg> arges: I thought we discussed making it more generic...
<cjwatson> use quantal's requestbackport
<cjwatson> or backportpackage or whatever it is
<micahg> arges: if it's that fragile, it's still broke IMHO
<arges> cjwatson, yes normally it would work, but for this particular package it has a regex that checks for the version string
<arges> micahg, yea I agree
<arges> time to submit a patch
<cjwatson> what I mean is that if it's assuming the form ~ubuntu12.04.1 then it's correct (modulo fragility)
<cjwatson> it's not clear which side of your "versus" is which :)
 * cjwatson -> dinner
<Sweetshark> cjwatson: what was that magic source again I needed for async binary package copies?
<cjwatson> Sweetshark: join the ~launchpad-beta-testers team and you can do it in the web UI
<cjwatson> Sweetshark: https://blog.launchpad.net/general/beta-test-asynchronous-ppa-package-copies
<Sweetshark> cjwatson: done, thanks!
<cjwatson> just another couple of bugs to fix (which shouldn't affect you) and I think we can roll that out to everyone
<Sweetshark> cjwatson: /me mumbles the inofficial libreoffice motto: "LibreOffice -- based on code breaking your toolchain since 1985"
<Sweetshark> cjwatson: lets see what injuries we can do to launchpad with this ultimate testcase.
<cjwatson> the bugs I know about only happen if the copies fail for some other reason :)
<shadeslayer> cjwatson: kudos to the guys who implemented async copy
<cjwatson> shadeslayer: does it work well for you then
<cjwatson> ?
<shadeslayer> cjwatson: yep
<shadeslayer> I need to try copying the entire kde binaries though ...
<cjwatson> oh good.  now if only I could reproduce the last bit of bug 1031092 in the test suite
<ubottu> Launchpad bug 1031092 in Launchpad itself "OOPSing PPA async copy shows no failure reason in web UI" [Critical,In progress] https://launchpad.net/bugs/1031092
<cjwatson> I can make it happen in production, but ...
<shadeslayer> cjwatson: before async copying, the kubuntu team wrote scripts to copy entire releases from one ppa to another
<shadeslayer> just because lp went, "No, you're doing that wrong, it's 5 packages at a time"
<cjwatson> yeah
<cjwatson> you can still use copy-package in lp:ubuntu-archive-tools if you prefer scripting to the web
<cjwatson> or indeed the Archive.copyPackage API call directly
<shadeslayer> uh ok, I don't think anyone of us knew about copy-package ....
 * shadeslayer looks
<cjwatson> it's relatively new
<shadeslayer> probably why
<cjwatson> in fact part of the work in exposing this was to make Archive.copyPackage / copy-package work when the target archive is a PPA - that was previously disabled
<shadeslayer> we've had kcopypackage for about a year now I think
<shadeslayer> ah
<cjwatson> does it use Archive.syncSource then?
<shadeslayer> don't know, I'll have to look
<cjwatson> no google hits for kcopypackage
<shadeslayer> it's in kubuntu-dev-tools
<shadeslayer> ah it's kopypackages
<shadeslayer> cjwatson: http://paste.kde.org/532178
<cjwatson> Right, syncSource.  That used to be the only option
<shadeslayer>  target.syncSource, yeah, syncSource it is
<cjwatson> That's the old synchronous interface
<shadeslayer> ah
<shadeslayer> I guess we should just use copy-packages now
<cjwatson> You can basically s/syncSource/copyPackage/ to get the async version of the API, though if you're happy with the web UI / other tools then you may not want to bother maintaining that script
<cjwatson> syncSource is vulnerable to timeouts on large packages, which you've probably noticed
<cjwatson> or possibly uploads that close lots of bugs, I forget
<lifeless> the latter
<shadeslayer> cjwatson: the problem with the web ui is that it's not viable when you want to copy an entire PPA
<shadeslayer> so if the webui has a "Copy everything from this ppa to target ppa"
<shadeslayer> that would be awesome
<shadeslayer> ( that usually happens for every KDE release that we test build and backport )
<cjwatson> yeah, it would; I suggest filing a bug, as my work on this has largely been because it was getting in my way for other work :)
<cjwatson> in the meantime, that's totally scriptable
<shadeslayer> we just scripted it because we didn't expect it to be fixed soon enough
<shadeslayer> for that matter, querying lp for recipes times out as well
<cjwatson> I don't think anyone's filed this bug, so it's not on anyone's to-do list afai
<cjwatson> k
<shadeslayer> ( and a bug was filed for that as well )
<cjwatson> perhaps because the mere notion of copying an entire PPA was utterly blocked on bug 575450
<shadeslayer> hmm .. will do tomorrow, too tired to do right now :)
<ubottu> Launchpad bug 575450 in Launchpad itself "Archive:+copy-packages nearly unusable due to timeouts" [Critical,In progress] https://launchpad.net/bugs/575450
<shadeslayer> :D
<shadeslayer> "This bug affects you and 13 other people "
<shadeslayer> xD
<cjwatson> the recipes timeout is presumably bug 1009787
<ubottu> Launchpad bug 1009787 in Launchpad itself "timeout querying archives for recipes via API" [Critical,Triaged] https://launchpad.net/bugs/1009787
<shadeslayer> yep, that's the one
<cjwatson> which is probably beyond my SQL ability
<sveinse> When preparing a new patch with quilt, do I always have to pre-declare (quilt add) which files I am about to change? It just feels so... cumbersome. I'd rather make quilt discover what I've done. (I'm a complete quilt noob)
<cjwatson> sveinse: 'quilt shell'
<jtaylor> sveinse: use a proper vcs for that
<jtaylor> or that
<jtaylor> I always forget quilt has that command
<cjwatson> quilt fold is handy too if you're integrating a patch from elsewhere
<sveinse> jtaylor: yeah, I'm preparing a patch for an existing package, so vcs isn't really an option here
<cjwatson> but quilt shell is the swiss army knife
<sveinse> and I can emacs in it I guess then :P
<cjwatson> if your perversions lie in that direction
<sveinse> lol, yeah
<sveinse> Are there any resources available to determine if a command name is available? Beyond apt-file which lists everything?
<roadmr> Hello! I need my application to somehow get notified when the user logs out, so it can clean up appropriately. What's the recommended way to do this?
<infinity> roadmr: Trap SIGTERM and exit cleanly?
<roadmr> infinity: oh so I *do* get SIGTERM on logout? that's what I was expecting but a quick experiment (trap the signal, write a file) didn't turn out anything. I must be doing it wrong...
 * roadmr goes back to the drawing board
<infinity> roadmr: Well, I don't know a ton about session management in the wonderful GUI world, but I assume all your children get a TERM, I can't see any other sensible way to do it.
<slangasek> it depends
<slangasek> you might get TERM, you might get HUP
<slangasek> you certainly get a signal
<infinity> slangasek: Randomly? :P
<slangasek> *however*, if it's a shutdown, you might not get the opportunity to fully *process* that signal before the system cuts out from under you
<infinity> There's that, yes.
<infinity> Depending on how many milisecond you need to sort out your business.
<slangasek> (I'm not sure how good the handling here is in e.g., lightdm)
<roadmr> slangasek: I'm less concerned about shutdowns (the app dies anyway) than about logout/login by the same user (app doesn't shut down, then complains it's already running, confused user)
<roadmr> slangasek: btw thanks for the SIGHUP clue, I guess I should have looked at other signals before asking :/
<slangasek> infinity: "randomly" - depends on whether you're a child process of a shell for testing? :)
<infinity> slangasek: If I am, my mother's been lying to me.
<roadmr> ok so I registered a handler for all signals, then closed the session, and the handler seemingly didn't get called :/ so I wonder if maybe the applications get KILLed altogether :/
<dobey> if your application is a gui app, you probably get a SIGPIPE when X goes away
<roadmr> dobey: ok, I'll try that
<slangasek> roadmr: nothing should be using SIGKILL here
<slangasek> ... except the shutdown scripts at the very end
<roadmr> slangasek: ok, good to know, that'd be a bit hard to handle :/
<slangasek> SpamapS: heh, so systemd has its own version of bug #711635.  http://lists.fedoraproject.org/pipermail/devel/2012-June/169365.html
<ubottu> Launchpad bug 711635 in mysql-5.1 (Ubuntu Oneiric) "init: post-start can cause respawn to hang" [High,Triaged] https://launchpad.net/bugs/711635
<roadmr> slangasek, dobey: oh, I'm an idiot, my signal handler was wrong. The application got SIGHUP when I closed the session. Sorry :/ now I know what i need to handle
<SpamapS> slangasek: yeah looks identical really. I think the workaround we came up with is pretty decent considering.
 * slangasek nods
<xnox> micahg: thanks for fixing up the sqlite tracker
<micahg> xnox: no problem, that list scared me :)
<xnox> micahg: yeah it was scary to me as well. So did the regexp catch sqlite3 as well as sqlite, before you changed it?
<micahg> xnox: yes
<xnox> micahg: nice to know....
<micahg> ~ /sqlite/   matches anything with sqlite in it
 * micahg guesses his python-sqlite entry is redundant then :)
<micahg> I'm glad to know negative lookaheads work :)
 * xnox 's head takes a few human seconds to parse lookaheads though
<micahg> xnox: there's a performance penalty in general with them, but it seemed to make sense here
<xnox> micahg: it's only a tracker =) but the green ones - means that it's spurious dependencies that can/should/must be dropped
<xnox> ?
<xnox> (which verb do you choose?)
<micahg> xnox: green is because good == true
<xnox> micahg: but the package is affected.
<xnox> micahg: so why is it still listing sqlite2 build-deps
<micahg> no, most likely if it's green, it means it's an alternate build dependency or not built on that arch
<xnox> ok
<micahg> xnox: hrm?  not understanding the question...
<xnox> it needs checking, in case if it's not an alternate build-dep, and we want to remove sqlite2 from the archive
<xnox> it will need fixing.
<micahg> let me make it not show green...
<micahg> xnox: ok, the next refresh should get rid of the green
<xnox> micahg: great it will be unknown instead, perfect =)
<micahg> grr...silly redundancy, we
<micahg> *we'll just call it clarity :)
<cjwatson> Sweetshark: so did your libreoffice copies work out?  I'm not seeing a record of them in the logs ...
<xnox> micahg: but now we have a split between green and unknown! more information =)
<micahg> xnox: hrm? looks fine to me
<micahg> xnox: unknown stuff means no binary bad stuff, but possible build-depends bad
<xnox> micahg: well gentle has alternative build deps and ends up build against sqlite3
<xnox> micahg: the rest, yes as you said
<micahg> xnox: which is why it's good :)
<xnox> previously we had 6 green =) now we have 1 green and 5 investigations ;-)
<xnox> hence the comment "more information!" =)
<micahg> which probably just means that --as-needed is doing its job and the build dependencies need to be updated
 * micahg -> off now until Sat night
<jocarter> have a good weekend micahg
#ubuntu-devel 2012-08-11
<Bluefoxicy> tar xzf ale.tar.gz
<Bluefoxicy> cd ale
<Bluefoxicy> make beer
<xnox> recompression finished.
<xnox> one data result got lost in hdfs
<xnox> results here: http://people.canonical.com/~xnox/hadoopresults/
<xnox> will analyse later
<pcarrier> he
<pcarrier> it might be obvious, but I'm new to launchpad. I'd like to try to add my patch on top of precise's php5, and I cannot find the precise maintenance branch for a package
<pcarrier> not sure if there's a generic way to do that at all actually, but I hop so
<pcarrier> it happens to be for php5 ( https://launchpad.net/ubuntu/precise/+source/php5 ), but that's a one-off
<pcarrier> does somebody know where I can find such bzr branch (or git repo, or whatever is used?)
<pcarrier> I'm more interested in how to find it, rather than being given the URI
<arand> pcarrier: It tends to be lp:ubuntu/packagename for the development branch (currently quantal) and lp:ubuntu/distroseries/packagename for stable Ubuntu versions, though if there have been updates or security fixes there will be lp:ubuntu/distroseries-security/packagename branches which may be the latest.
<pcarrier> arand++ thanks a lot
<pcarrier> I need to note that down somewhere :)
<pcarrier> oh, the classical debian mess. this package uses quilt.
<arand> php5 has most of them, you can look at it from https://code.launchpad.net/ubuntu/+source/php5
<arand> Um, isn't 3.0 (quilt) the standard format in Ubuntu as well?
 * pcarrier has an issue with the mix of upstream git, distro bzr storing packaging quilt
 * pcarrier dreams of a world where everything is just git, and everybody just uses branches and tags
<pcarrier> you end up using bzr branch, git format-patch, quilt import, quilt refresh, dch -l, just to try out a simple change to a package
<melodie_> hi
<JoseeAntonioR> /mode #ubuntu-ops +b *!*@@ubuntu/member/jbicha$##fix_your_connection if you want to copy-paste
<JoseeAntonioR> oops
<JoseeAntonioR> wrong channel, guys, ignore that please
<mneptok> err
<JoseeAntonioR> mneptok: I think it should be a forwardban, to make sure once the connection prob is solved
<mneptok> JoseeAntonioR: unable to set one. hence my "err"
<JoseeAntonioR> :P
<mneptok> ah, and now i know why
<Debolaz> http://ihaveapc.com/2011/05/how-to-fix-problem-with-mergelist-varlibaptlists-error-in-ubuntu-11-04/ <- Stuff like this really shouldn't be an issue imho, is there any particular reason why it's not dealt with automatically by the system?
<infinity> Debolaz: Errors like that only happen if your apt lists are replaced by junk (can sometimes happen behind a captive portal, for instance).  We have open bugs about it, and a variety of proposed solutions, if I recall.
<Debolaz> infinity: It just happened to me and I'm not behind a captive portal.
<infinity> Debolaz: What was the exact error?  And did you save the contents of /var/lib/apt/lists before blowing it away?
<infinity> Debolaz: Not all bugs that look "similar" are actually the same, so having real data instead of pointing at a third-party blog post is kinda helpful. :/
<Debolaz> infinity: No, it wiped and I've just rebooted the system. The problem was some translation thing from the official ubuntu repositiory (I say official, because I have some nonofficial repositories as well, just to clarify that it wasnt those causing it). It was that exact error though, just a different file. Wiping and redownloading solved the problem.
<infinity> Knowing the contents of the file would be somewhat helpful, that's all.
<infinity> To perhaps determine HOW this happened.
<infinity> I won't disagree that perhaps apt could deal more gracefully with file corruption in some cases, but we really shouldn't be landing corrupted/broken files on disk in the first place.
<Debolaz> infinity: If redownloading solved the issue, it seems to me that the problem wasn't serverside. The solution also seems easy: Have a file with hashes of the various other files downloaded, if a hash doesn't match, try to redownload it once.
<infinity> (And the suggestion that apt should "just delete it and try again" is obviously a non-starter, because the original could actually be broken at the source, causing you to just loop through trying to "fix" it infinitely)
<Debolaz> infinity: You don't have to loop, just try once, and if it doesn't work, report the error. This fixes the problem and avoids any issues.
<infinity> Debolaz: That doesn't actually fix it for 99% of the use-cases where this breaks. :)
<Debolaz> infinity: In the case of captive portals, it doesn't fix it no. But it doesn't make things worse, and it solves it for the rest of us.
<Debolaz> infinity: I agree that it's relatively rare that it happens without someone intentionally messing with the data transferred like a captive portal would. But the solution to dealing with the non-intentional cases is very simple and doesn't do any damage.
<infinity> Debolaz: It doesn't help in the case of broken transparent proxies of any sort, which is generally how the content gets "corrupt".
<infinity> Debolaz: I think forcing the large majority of people who see this error to re-transmit, on the off chance that they're the tiny minority that would benefit from it, is entirely the wrong answer.
<infinity> (We do, however, need to do a better job with invalidating broken content in general, though, which isn't about forcing a re-download, but just not using it at all)
<Debolaz> infinity: Ok, let me ask you this question: Do you understand that no matter if the cause is a captive portal, or just a bad network, leaving the system in a state where it cannot update unless the user goes in and does something exceedingly technical from a newbie point of view, is a very bad thing?
<infinity> Debolaz: No need to be condescending.  I acknowledge that it's something we need to fix, and we're looking into it.  I disagree with the proposed solution, that's all.
<Debolaz> It just seems you are being intentionally dense about this, and that frustrates me a bit.
<infinity> And now you're being insulting, along with the condescension.  Thanks.
<Debolaz> Followup question of curiosity then: If this happens, lets say due to a captive portal or something similar, which is the likely cause of this error, will the system eventually recover over time without user interaction?
<infinity> Probably not and, yes, we could look at a stop-gap to sort that out.
<infinity> There are lots of nasty bugs out there.  This is one we're looking at.  Being insulting and condescending about it assumes that this is the *only* important bug, and we're clearly irresponsible for not having dedicated our lives to fixing it.
<Debolaz> Hmmmâ¦. This wouldn't really be a permanent solution to the problem, but at least it provides a simpler one than what seems to currently be the case: Have a program that removes all the files from the apt cache that aren't required to make it run. Possibly also calls other commands to repair things, basically just tries to reset the update system as much as possible.
<Debolaz> Does this seem like something worthwhile to implement if someone was to volunteer?
<infinity> If one was to try to do an automated tidy thing, I'd just piggyback it on the cron job that apt already has, and test for the known error conditions, wipe, retry, and give up after one retry, assuming the world is broke and it'll fix itself tomorrow.
<infinity> But yeah, a hideous hack, and has nothing to do with fixing the bug, just an attempt to deal with the symptoms.  I certainly have no issues with reviewing a proposed patch to do that sort of thing, mind you.
<mdeslaur> Debolaz: out of curiosity, that version of ubuntu was that on?
<Debolaz> The specific error I got today was the first time I've ever gotten that specific error in Ubuntu. But I have had similar problems with the update system before that has required manual intervention. A program that attempts to fix everything that can be fixed automatically would had been convenient to have, since almost all of these errors does seem to be of the trivial kind to fix if you just know how.
<Debolaz> mdeslaur: 12.04
<mdeslaur> hrm, that was LP: #346386...and I thought it had been fixed already
<mdeslaur> ah, yes, there's a new fix in #80 in that bug
<mdeslaur> I've added an rls-q-incoming to that bug so foundations will take a look at mvo's proposed patch
<mdeslaur> if it's the exact issue, mind you
<Debolaz> infinity: I agree that it's not a solution in the same sense we were talking about above. Just a "less ugly" way to deal with symptoms, because I think it's going to be difficult to really deal with all the possible causes of these symptoms.
<infinity> Debolaz: Well, no, we can't fix the root *cause*, as that's asking us to control teh internets, but we should be able to make sure corrupt data never hits disk at all.  The fact that it is hitting disk is the real bug here.
<vitaly> Hello guys, does anyone know how does 12.04 LiveCD boot on Apple Macbooks? I noticed that same ISO dd-ed to the USB stick can boot both on PC and Mac. How is that possible? I haven't seen that in previous versions of LiveCD. Any ideas?
<vitaly> ping anyone
<vitalylook> Ii #ubuntu-iso chan alive?
<penguin42> I don't know the way Ubuntu's boot setup does it; there's a scary post at http://mjg59.dreamwidth.org/#entry-12037   on the way Fedora does it
<vitalylook> Well, it looks really scary. some more details here: http://mjg59.dreamwidth.org/11285.html
<vitalylook> has anyone played with isohybrid tool?
#ubuntu-devel 2012-08-12
<tomreyn> hi
<tomreyn> we have a package in Ubuntu called megaglest (and megaglest-data/-dbg). now i'm wondering where reports on crashes on Ubuntu go and how we can get access to those?
<tomreyn> also your /topic seems to be cut off
<penguin42> tomreyn: https://bugs.launchpad.net/ubuntu/+source/megaglest  should be the bugs if there were any
<tomreyn> penguin42: does this include crashes? my understanding is that they are handled differently since 12.04
<tomreyn> i.e. users will no longer end up on launchpad when reporting them
<penguin42> ah, I think I know what you're talking about, but I've not seen where that goes
<tomreyn> there is supposed to be some "crashdb" somewhere
<penguin42> yeh not sure where
<penguin42> tomreyn: http://askubuntu.com/questions/140379/how-can-i-track-a-bug-that-caused-a-crash-and-was-reported-via-apport-whoopsie
<penguin42> a lot of the links there seem to be broken, not sure if it's just a perms issue
<tomreyn> so the crash reports are centrally collected and there are (very limited) publically accessible statistics based on them
<tomreyn> and then there is a link to (supposedly) detailed crash reports. Where the average mortal get's an "Either you have not been granted access to this resource or your entitlement has timed out. Please try again."
<penguin42> tomreyn: Looks like it, I'm not sure if that's supposed to work or not
<penguin42> tomreyn: Those links have lots of /'s in them - I wonder if that's not intended
<tomreyn> i guess that could have become a nice system. after spending more time on developing it, and finishing developing it /before/ rolling it out.
<penguin42> tomreyn: I guess maybe it already provides a good indication if there are lots of crashes of the same type suddenly occuring
<penguin42> tomreyn: I guess someone can get to the detail
<tomreyn> and at the same time the hooks it uses prevent the user from gathering crash dumps the way the application developer may like them.
<penguin42> I assume there is a way to stop that
<tomreyn> probably, but default matter.
<tomreyn> *defaults
<tomreyn> anyway, we don't know enough, let's see if someone who knows something about this scarcely documented system is able to provide more insight.
<penguin42> nod - I suspect all the docs are there somewhere if we knew where to look
 * penguin42 must make a note to ensure that's disabled on his work machines
<smartboyhw> Hi!
<green7> hello
<green7> Need some help!
<ogra_> green7, for support try #ubuntu
<green7> Well, someone redirected me here
<smartboyhw> ogra_, he meant support on developing, help him to start on his way to development
<green7> right
<ogra_> then probably #ubuntu-app-devel or #ubuntu-motu
<green7> all right.
<green7> seems like they're busy!
<smartboyhw> Yep!
<shnatsel> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<shnatsel> bug #1035384
<ubottu> Launchpad bug 1035384 in linux (Ubuntu) "kernel panics on boot if ulatencyd is installed" [Undecided,Incomplete] https://launchpad.net/bugs/1035384
<shnatsel> ulatencyd is a daemon that organizes processes in cgroups, sets nice and ionice per cgroups and processes, etc
<smartboyhw_away> shnatsel: Help green7
<micahg> smartboyhw_away: no, he's reporting a regression
<smartboyhw_away> OK, so someone please help green7, he wants to develop for ubuntu
<shnatsel> the latest kernel in -updates panics on boot if ulatencyd is installed; this has never happened before in the ~6 months I'm using ulatencyd
<shnatsel> the panic seems to be confirmed on a wide range of systems, seems to happen on every boot but I don
<shnatsel> I don't have all the details because I'm on a vacation with an older kernel, sorry\
<shnatsel> people in #elementary-dev can explain the problem in more detail
<shnatsel> elementary ships ulatencyd by default so all systems suddenky got bricked :)
<ogra_> micahg, though ifind it doubtful to call out an IRC regession alert fo a universe package on a sunday
<micahg> ogra_: the regression is possibly in the kernel, it's just manifesting itself with a universe package installed
<ogra_> sure but really not a super duper emergency that required to remove or blacklist a package from the archive
<micahg> ogra_: I would think that depends on what the root cause is
<ogra_> (since you can easily avoid it by removing dais universe package)
<micahg> yeah, I guess if that's the only symptom ATM, it's probably not worth pulling
 * ogra_ glares at his dyslexic fingers 
<ogra_> s/dais/said/
<green7> hello
<smartboyhw> Hi!
<SectorX8> Hi there. I may be interested in contribution and membership.
<smartboyhw> SectorX8: What membership? Contribute BEFORE membership
<SectorX8> But... My field doesn't seems to mentioned in the contribution site.
<SectorX8> Page*
<SectorX8> smartboyhw: I know. I'm not asking for it.
<SectorX8> I'm just telling you that I'm interested.
<SectorX8> So... My field is security. Such as pentesting, cloud security, forensics etc. How can I contribute with this?
<SectorX8> The topic is not mentioned here: https://wiki.ubuntu.com/ContributeToUbuntu
<cjwatson> #ubuntu-security and http://wiki.ubuntu.com/SecurityTeam might be able to help.
<SectorX8> Thanks. I'll be moving to next channel.
<SectorX8> Have a nice day.
<cjwatson> I wouldn't worry overly much about whether all the is are dotted and ts crossed on the contributions page.  If you do good work on security it will be fairly obvious.
<cjwatson> Have fun.
<SectorX8> Thanks again. I'll. =)
<cjwatson> (I don't know how active -security is outside typical working hours, mind.)
<SectorX8> OK good to know.
<SectorX8> Typical security specialists btw. I'm active in digital forensics lab at a university. My mate in the lab, a Ph D is quite much night gibbing. And we're working way too much. Like politicans. Just to mention.
<hallyn> infinity: hey - do you happen to know if there's an ubuntu image i can run (newer than maverick) on efika mx smarttop?  would it use the same procedure i followed a year ago on that fujitsu arm netbook?
<infinity> hallyn: Genesi never got around to getting us a current kernel, so we never did images for newer releases.
<infinity> hallyn: But you could always take one of their old images/kernels, and do a sketchy debootstrap / static shell / pivot root reinstall from their old maverick/armel to a precise/armhf.
<infinity> hallyn: You'd just be stuck with their ancient kernel. :/
<hallyn> infinity: that's a shame
<hallyn> i wonder if i can find a kernel delta to port to build my own
<infinity> hallyn: Yeah, I spent two release cycles asking them for a kernel we could ship in the archive, and gave up.
<hallyn> would i need to do anything more than back up /boot and /lib/modules; update; copy content back; update-initramfs and grub-update?
<hallyn> well i suppose the kernel .debs shouldn't depend on anything else old
<infinity> grub? :P
<infinity> In theory, just jiggering the kenrel around from old root to new root would make it all work.  I should probably do so with my smarttop before I give you advice on bricking yours, though.
<infinity> You'd end up losing any of their binary codecs, X drivers, etc, but I suspect that's not a big deal for your use-case?
<hallyn> haha.  right :)  (no grub)
<infinity> Actually, wait, their image was lacking binary X acceleration fanciness anyway, if I recall.  So, that situation wouldn't regress any.
<hallyn> infinity: yeah, this will be headless.  i'd like wireless to work (though not required)< that's about it
<hallyn> anyway i sent an email to the guy who'd said "thank you for your purchase' last year asking about updates.  assume i'll hear nothing...
<hallyn> interestingly the 2.6.31 kernel in their git tree does have recent updates
<hallyn> heh, last commit in its ipc/ dir is by me.  two years ago.  sucks.
<hallyn> shucks i meant
<hallyn> alright asked one of their kernel devs about their github tree.  will hope for the best.
<Mikeulus> Hello all. What exactly does "unity --replace" do?
<Mikeulus> I have built unity 6.0, and am interested in switching back and forth between the system's version of unity and the one I have built.
#ubuntu-devel 2013-08-05
<Taggg> hi, can anyone tell me how long a bug fix bzr branch typically takes to get merged into the current development series?
<ScottK> It would be nice if someone could look at what's up with python-qt4 and autopkgtests.  It's been running them for about a day now.
<lifeless> ScottK: it's aiming for completeness :P
<ScottK> I'm not in a particular rush for it, as long as it's progressing.
<dholbach> good morning
<didrocks> thanks cjwatson for promoting some parts (not sure what triggered you looking into it as Mir was in universe)
<JackYu> dholbach, morning:)
<cjwatson> didrocks: dep-wait from mesa.  Am I good to finish the promotion now that you're around?
<didrocks> cjwatson: I've finished it, just need a publisher run I think
<cjwatson> ok, cool
<didrocks> cjwatson: you can unblock xorg-server and mesa that Laney should have pinned
<dholbach> hi JackYu
<didrocks> (it was to avoid promotion during the week-end and nobody around to look)
<cjwatson> didrocks: it was just xorg-server.  Done
<didrocks> thanks
<cjwatson> there'll be a publisher run starting in two minutes
<didrocks> excellent ;)
<didrocks> cjwatson: FYI, one those are migrated, we'll make unity-system-compositor (depending on this xorg-server + driver patches) entering the archive but staying in universe
<didrocks> basically, it's installing this package that toggles Mir on/off
<cjwatson> ok
<didrocks> so, hopefully, nobody will notice the difference right now, with that additional build-dep without u-s-c
<dholbach> does anyone know why there's "syncpackage: Error: Debian version 1.11-2 has not been picked up by LP yet. Please try again later."?
<dholbach> according to mitya57: "I don't know what to do about that, given that the package was uploaded > two weeks ago."
<cjwatson> I already answered that on #launchpad a while back
<cjwatson> And filed a bug on the broken Debian package that failed import
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718605
<ubottu> Debian bug 718605 in xalan "xalan: fails to unpack with old dpkg-source" [Normal,Open]
<dholbach> ah ok cool - thanks
<seb128> doko, hey, can you commit your gtk+ changes to the packaging vcs?
<doko> otp
<seb128> jibel, hey
<seb128> jibel, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is blocking poppler because libreoffice tests failed, hitting a disk space issue ... can you do something about it?
<jdoles> cjwatson: I don't know, but it only worked when I did LC_ALL=C pwdx
<cjwatson> As opposed to what other locale?
<cjwatson> And did you get strace output?
<cjwatson> Mind you its strtol calling sequence looks broken
<jdoles> cjwatson: this is broken for example: LC_ALL=en_US.UTF-8 pwdx 23879
<jdoles> Even if the locale would not exist, it should still fall back to C.
<cjwatson> jdoles: please could I see strace output?
<cjwatson> And does the locale not exist in this case?
<cjwatson> aha, never mind, reproduced it
<jdoles> cjwatson: http://paste.kde.org/p7354a5b2/
<jdoles> cjwatson: this is my strace.
<jibel> cjwatson, does something need to be done for poppler blocked on libreoffice or it will be considered anyway because libreoffice is hinted?
<cjwatson> jibel: the autopkgtest needs to be unstuck
<cjwatson> or forced
<cjwatson> jibel: ah, I have a force at an old version.  I'll update it
<cjwatson> seb128: ^-
<seb128> cjwatson, jibel: thanks
<jdoles> cjwatson: I think a tool like pwdx probably also shouldn't be implemented in C in the first place.
<cjwatson> jdoles: Nonsense
<cjwatson> It's in procps, it's perfectly reasonable to be in C
<cjwatson> jdoles: It's a one-line fix, I think.  I'll test shortly and file a Debian bug with the patch
<jdoles> cjwatson: sure, everything can be written in C, but nobody is going to run pwdx in an inner loop and shell would be fast enough.
<cjwatson> It's a system utility, it's not that complex in C
<cjwatson> Shell has its own gotchas
<cjwatson> This is a pointless discussion since I'm not going to reimplement it anyway
<cjwatson> Seeing as I'm not procps upstream
<jdoles> cjwatson: I thought the idea of having your own OS was that you could replace everything you didn't agree on :)
<cjwatson> Eh, that doesn't mean doing work for the sake of it
<cjwatson> This is also a collaborative OS
<jdoles> The way I see it is that a bug was introduced because of premature optimization.
<cjwatson> I'm not going to continue this
<cjwatson> I'm going to fix the bug instead
<jdoles> cjwatson: ok, let'
<jdoles> s just end the discussion there.
<didrocks> cjwatson: just noted a funny thing, RAOF has xorg-server depending on mir on powerpc where Mir doesn't build on powerpc
<didrocks> so I guess it will get block on proposed, I think xorg-server should treat powerpc as mir-less
<cjwatson> didrocks: Agreed
<cjwatson> Presumably that's easy enough
<didrocks> cjwatson: the drivers are patched to use some xorg - xmir API, they need to #ifdef to return false on powerpc I guess
<RAOF> BAh.
<cjwatson> I suppose so
<RAOF> Well, they (should) build and work against a non-XMir server, so it's a simple matter of arch-restriction.
<didrocks> RAOF: as the drivers have some xorg-xmir api call, does the #ifdef thing make sense to unblock them? (and so, removing the mir build-dep on powerpc)?
<didrocks> ah nice, you already have that detection when building
<didrocks> (xorg)
<RAOF> Yup.
<RAOF> Less well tested, but *should* work.
<didrocks> RAOF: want to try that upload? ;)
<RAOF> The life of ppc
<didrocks> heh, indeed :)
<RAOF> What's the arch string for ppc? ppc?
<RAOF> Ah, powerpc.
<cjwatson> Debian architecture or GCC?
<RAOF> Debian arch; I see it's powerpc.
<cjwatson> Indeed
<cjwatson> jdoles: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718766
<ubottu> Debian bug 718766 in procps "pwdx: fails with "invalid process id" when run in a nonexistent locale" [Normal,Open]
<chrisccoulson> hmmm, any idea what might have caused https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4848763 ? (and should i just retry it?)
<lifeless> cjwatson: in case you missed scrollback - I've finally files bug 1208268 about my grub issue on 3TB GPT disks... any pointers on moving forward will be much appreciated
<ubottu> bug 1208268 in grub2 (Ubuntu) "grub not recognising my GPT+mdadm+lvm layout" [Undecided,New] https://launchpad.net/bugs/1208268
<ogra_> chrisccoulson, i'd ask in #launchpad ... probably there is a way to prevent you from having to rebuild
<maxb> I do not think there is
<RAOF> didrocks: Enjoy your PPC upload.
<ogra_> RAOF, oh, should XMir work on armhf ?
<didrocks> RAOF: I'll surely enjoy it deeply! Thanks :)
<cjwatson> lifeless: Ah, not sure I'm going to have time to have a look for some time unfortunately - got a lot to do before debconf next week
 * ogra_ ponders to trash his chromebook for a try :)
<didrocks> ogra_: you will need to install unity-system-compositor once available to trash it properly though :)
<ogra_> hehe
<RAOF> ogra_: Yes, as long as your armhf system has an nvidia, radeon, or intel GPU :)
<cjwatson> lifeless: I guess grub-probe -vv is always useful
<ogra_> well, i'm not sure Mir itself will work yet
<lifeless> cjwatson: thats ok, I have a workaround (USB key ;))
<lifeless> cjwatson: attaching that now
<ogra_> RAOF, mali ... same board as the nexus 10 (manta)
<cjwatson> (with whatever grub-probe call is actually failing)
<lifeless> cjwatson: it installs fine, the error is when you reboot
<RAOF> ogra_: No dice, at least until we do a generic egl-based XMir driver.
<ogra_> yeah, i feared that
<cjwatson> lifeless: oh dear, that's unusual
<cjwatson> lifeless: Might be worth trying installing with --debug-image=all and seeing what the last screenful of output is
<cjwatson> (Though I appreciate this may be a pain to iterate on)
<lifeless> cjwatson: last screenful of output from the install, or from booting ?
<cjwatson> lifeless: install
<cjwatson> err
<cjwatson> sorry, misunderstood
<cjwatson> lifeless: booting :)
<lifeless> cjwatson: when I previously mentioned this to you you suggested getting some disk sectors might let you reproduce? I will capture a photo of the boot shortly...
<didrocks> RAOF: seems you have to do a .install file dance
<didrocks> https://launchpadlibrarian.net/146820236/buildlog_ubuntu-saucy-powerpc.xorg-server_2%3A1.14.2-0ubuntu5_FAILEDTOBUILD.txt.gz
<lifeless> right now... for dev in /dev/sdb /dev/sdc /dev/sdd /dev/sde; do ....
<RAOF> didrocks: Whoops. Oh, no, I just need to be less stupid
<cjwatson> seb128: so the remaining poppler blocker is that docvert-libreoffice depends on python-uno, which has been removed in the latest libreoffice in favour of python3-uno
<seb128> cjwatson, I was *just* looking at that as well/building the python-uno rdepends list
<cjwatson> seb128: the actual Python code in question is (confusingly) in docvert rather than docvert-libreoffice, but it does otherwise seem like a real problem
<cjwatson> core/lib/pyodconverter/pyodconverter.py
<cjwatson> Do you know if there was a particular reason to aggressively remove python-uno in advance of Debian?
<seb128> cjwatson, I don't, trying to have a look
<cjwatson> I would have expected Sweetshark to use grep-dctrl or similar to search for reverse-dependencies before dropping the binary ...
<seb128> cjwatson, not explanations with the commit: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=a2d74f4a43949da2710a29e63fd3a9d87f679ecf
<cjwatson> Indeed
<seb128> cjwatson, and Sweetshark is off on holidays this week :/
<cjwatson> (What on earth was that Conflicts doing there ...)
<cjwatson> Oh, I suppose it actually ships stuff in /usr/lib/libreoffice/ as well
<cjwatson> seb128: So, I could demote docvert to -proposed for now, if you could make sure to get Sweetshark to sort this out when he gets back
<seb128> cjwatson, that would be great, thanks
<lifeless> cjwatson: output in a photo linked on https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1208268
<ubottu> Launchpad bug 1208268 in grub2 (Ubuntu) "grub not recognising my GPT+mdadm+lvm layout" [Undecided,New]
<lifeless> cjwatson: let me know if you can't access it and I'll shuffle it into LP itself
<cjwatson> lifeless: thanks, yes I can.  FWIW GRUB thinks your drive doesn't have LBA extensions
<cjwatson> Apparently
<lifeless> cjwatson: interesting... it is a 3TB drive on a fairly old machine, but linux handles the entire drive just peachy
<lifeless> cjwatson: and the bios boot partitions are at the front, deliberately.
<cjwatson> Not saying it's necessarily right, but that's why it's failing
<cjwatson> I suspect there's RAID metadata or something at the back
<lifeless> sure; just erring on the side of verbal diarrhea
<cjwatson> All hail --debug-image=all for making this clear in a single screenshot though :)
<lifeless> :>
<mlankhorst> ever since sweetshark has left on vacation I've been hearing a lot less about libreoffice!
<cjwatson> Linux will be using a proper driver rather than going through the BIOS
<lifeless> cjwatson: yeah - 2007 motherboard :)
<cjwatson> Really shouldn't be lacking LBA
<lifeless> definitely has some LBA support; previous drives were 1TB's, which IIRC were also in the LBA only world.
<cjwatson> Though of course it's the BIOS version that matters, not the motherboard, but even so
<cjwatson> Either GRUB thinks that INT 13h extensions aren't present at all, or it tried one of them and got the impression they were broken
<cjwatson> seb128: Demoted - https://launchpad.net/ubuntu/+source/docvert/+publishinghistory
<cjwatson> lifeless: Oh, I had a factor of two error, I had the limit in my head as 4TB not 2TB
<lifeless> cjwatson: googling is suggesting that LBA has a 2.1GB limit of some sort.
<cjwatson> lifeless: Traditional BIOS can't reliably read from over 2TB
<doko> RAOF, xorg-server, please do the same for arm64 (as for powerpc)
<lifeless> cjwatson: so, understood. But grub shouldn't need to to bring this up.
<cjwatson> lifeless: In theory the call is 64-bit-capable (https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D42h:_Extended_Read_Sectors_From_Drive), but in practice my understanding is that you're hosed without UEFI
<lifeless> cjwatson: it's not showing the mdadm filter being invoked at all, for instance.
<cjwatson> lifeless: So is - look at the mentions of diskfilter in that screenshot
<cjwatson> grub's raid module is a layer on top of diskfilter
<lifeless> ok.
<cjwatson> There's one remaining way I can think of in which this might be GRUB's fault
<cjwatson> What RAID version are you using on this array?
<cjwatson> metadata version, I mean
<lifeless>         Version : 1.2
<cjwatson> So that stores the metadata 4K from the start of the device
<lifeless> thats my understanding :)
<cjwatson> It's possible that GRUB tries to read from the end of the partition when checking for the presence of some other metadata version, and then incorrectly thinks LBA is completely broken and falls back to CHS
<lifeless> that sounds plausible to me
<lifeless> this is a problem that will self solve itself eventually
<cjwatson> If that is the case, then http://paste.ubuntu.com/5950617/ should help
<cjwatson> (Could doubtless be tighter as the addressable CHS range is smaller than that)
<lifeless> I'll try rolling a custom package with that , but not tonight
<cjwatson> Also that code has wrong error handling, so isn't applicable as-is
<lifeless> oh, I shouldn't try the patch?
<lifeless> of course, content in /boot/ could be too high up the disk, but thats a different discussion; I can make a vg and shuffle it to the front once we get far enough up the stack
<cjwatson> lifeless: Perhaps http://paste.ubuntu.com/5950640/ instead
<lifeless> linked in the bug.
<lifeless> Thanks for making the time to eyeball this.
<cjwatson> ta
<smartboyhw> How long does a uploaded package wait in the queue before it gets approved into -proposed?
<cjwatson> smartboyhw: Which queue?
<smartboyhw> cjwatson, raring
<cjwatson> Which queue in raring?
<smartboyhw> cjwatson, SRU ofc
<cjwatson> (new, unapproved, ...)
<smartboyhw> unapproved
<cjwatson> can't give you a particular time period, depends on SRU team members having time to review
<ogra_> shouldnt promotion to -proposed be immediately ?
<cjwatson> ogra_: no, not for unapproved
<smartboyhw> ogra_, obviously, it needs a SRU team member to approve it in...
<ogra_> ah
<cjwatson> this is ibus-cangjie I presume
<smartboyhw> cjwatson, yeah...
<smartboyhw> Stuck for 25 days
<cjwatson> I'll have a look now
<smartboyhw> cjwatson, many thanks!
<cjwatson> smartboyhw: seems fine, apologies for the delay.  accepted
<smartboyhw> cjwatson, great! Thanks
<seb128> doko,  lp:~ubuntu-desktop/gtk/ubuntugtk3 for the gtk packaging vcs btw
<ev> seb128: do you happen to know if there's plans for a first use screen on Touch?
<ev> or who would know the answer to that? :)
<seb128> ev: there is, Cimi is working on it
<ev> seb128: how convenient. He often sits next to me.
<ev> cheers
<seb128> yw
<Cimi> ev, see you friday :P
<ev> is there a blueprint/google doc that you're aware of?
<ev> Cimi: :D
<Cimi> ev, shared
<ev> thanks!
<wizard_A> how to get the callback function that is called when someone right clicks on a file..
<didrocks> RAOF: I think I'll do another xorg-server upload, there is an extra build-dep on powerpc from the -dev package
<seb128> cjwatson, seems like docvert still makes libreoffice unhappy?
<seb128> cjwatson, or does it need another publisher cycle?
<cjwatson> Oh, damn, I forgot to block it
<wizard_A> which portion of the code does get executed when someone right clicks on a file in ubuntu??
<cjwatson> seb128: should work next run
<seb128> cjwatson, thanks
<seb128> cjwatson, great, it migrated this time ;-)
 * seb128 just got a bunch of archive emails about the poppler stack hitting saucy
<wizard_A> i want to work on feature of ubuntu, please help me get started
<cjwatson> wizard_A: there's no single answer to that question; it depends on the context where you're right-clicking
<wizard_A> yes
<cjwatson> like, is it on the desktop, or the open dialog in some application (which?), or ...
<wizard_A> a file icon within the directory browser
<cjwatson> the directory browser, as in nautilus?
<wizard_A> what is nautilus??
<wizard_A> yes
<cjwatson> nautilus is the file manager from GNOME
<wizard_A> yes thats where i was meaning.......
<wizard_A> sorry i am just begining to develop so i stumble upon many things... sorry for that
<seb128> wizard_A, what are you trying to achieve? add a menu item to that right click menu?
<wizard_A> yes
<cjwatson> Right, so this is why you need to know which application you're right-clicking in.  The widget toolkit (usually GTK+ or Qt - GTK+ in the case of nautilus) implements a lot of generic behaviour, but nautilus does its own context menus
<cjwatson> It connects to the "button-press-event" signal on its view and detects right button presses
<cjwatson> (well, button 3)
<cjwatson> I believe that the contents of the context menu are defined in src/nautilus-directory-view-ui.xml
<seb128> you can add items through libnautilus-extension
<seb128> look at ubuntuone-client-gnome or file-roller for examples
<cjwatson> Yeah, that would normally be better
<seb128> e.g file-roller add "extract here..." items when you right click on an archive
<seb128> wizard_A, e.g https://git.gnome.org/browse/file-roller/tree/nautilus/nautilus-fileroller.c
<cjwatson> seb128: oops, I may have been wrong in asking you to patch shared-mime-info - looks like I should have shipped my own .xml file in click (according to upstream)
<cjwatson> so I'll do that and revert the shared-mime-info change
<seb128> cjwatson, ok, works for me. What's the rational? that the number of handlers for that type is mostly going to be low?
<wizard_A> what i am trying to achieve is: when someone already has vlc installed onto system then any .mp3, .avi, .mkv etc files right click option should contain a menu as "Add to vlc media playlist".
<cjwatson> seb128: that it's basically specific to a single package
<seb128> cjwatson, I never understood where they draw the line, seems to depends of the maintainer of the day, they include e.g the deb and rpm types
<cjwatson> https://bugs.freedesktop.org/show_bug.cgi?id=66689
<ubottu> Freedesktop bug 66689 in freedesktop.org.xml "Add application/x-click type" [Enhancement,New]
<seb128> ok, that makes sense
<cjwatson> meh, I'm happy to go with the flow for now rather than fight upstream about it
<cjwatson> save energy for more useful fights :)
<cjwatson> There's python-nautilus too
<seb128> indeed
<wizard_A> cjw: does the patch mean that its already done??
<cjwatson> wizard_A: what patch?
<wizard_A> patch for bug66689
<cjwatson> wizard_A: that was one suggested patch which I'm now going to do in a different way
<cjwatson> wizard_A: but it was unrelated to the conversation with you
<wizard_A> oh i see
<wizard_A> so how do i get started with my idea, i really want to learn contributing to ubuntu..
<seb128> wizard_A, look at https://git.gnome.org/browse/file-roller/tree/nautilus/nautilus-fileroller.c they don't something similar to archive types
<seb128> cjwatson, btw, did you see my ping about click packages/install size on friday evening?
<cjwatson> seb128: I did but you'd logged off by the time I could respond
<cjwatson> seb128: I don't think I agree that owned data should be the responsibility of click itself to figure out, because (longer-term) click wants to be independent of things like Ubuntu Touch and details of where an app stores its user data seem to be rather specific to the environment
<cjwatson> seb128: So I agree we should only implement this once, but my instinct is to say that it should be one layer up from click
<seb128> ok
<seb128> so you would add a new service/library to do that? or do you see a place in our current stack where it would make sense to add the feature?
<seb128> lool, ^ fyi
<cjwatson> seb128: I'm not sure what the right location is.  Putting it in the Click PackageKit plugin would have the same convergence problem
<seb128> cjwatson, ok ... do you think that's something worth discussing on a mailing list (which one)?
<cjwatson> seb128: ubuntu-appstore-devel I suppose
<seb128> cjwatson, ok, I will do that, thanks
<cr3> how can I do something like a mount of an image when building a package? the build process seems to be done in a fakeroot, so I can't just use mount nor can I use sudo
<brendand> cr3, baguette
<ogra_> cr3, fakechroot ... but not sure that will allow mounts ... have a look at the ubuntu-touch-generic-initrd package i'm using fakechroot in there to gain (virtual) root access
<stokachu> doko: could i bother you to take a look at a couple of bugs?
<doko> stokachu, I'll try
<stokachu> doko: bug 1121874 and bug 1207123
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu Raring) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<ubottu> bug 1207123 in gnutls26 (Ubuntu Precise) "Key usage violation in certificate has been detected" [Undecided,New] https://launchpad.net/bugs/1207123
<stokachu> was hoping to get these uploaded to start the sru process
<doko> didrocks, seb128, RAOF: please would disable MIR related things for arm64 too? The ones you do disable for powerpc
<didrocks> doko: I saw your upload, will do in the following upload when we have something to push
<didrocks> (we'll be needed anyway for -ati and -nouveau)
<doko> ok, thanks
<jono> who is taking care of audio?
<jono> Skype audio no longer worksin Saucy
<seb128> doko, thanks for commiting the gtk changes to the vcs ;-)
<seb128> jono, diwic and TheMuso
<jono> thanks se
<jono> seb128,
<jono> diwic, TheMuso are you aware of this issue?
<seb128> jono, btw, is there still a vUDS planned for this month (or next one)?
<jono> seb128, yep, end of month
<seb128> jono, I still didn't see an announce for it (hint: list user here)
<jono> email about schedulinggoing out this week
<seb128> jono, would be nice to announce it...
<jono> seb128, will go out this week
<seb128> thanks
<jono> np
<broder> cjwatson: sorry for not getting this up sooner - the shell i was setting things up in died - but first lintian run for saucy is up (http://lintian.ubuntuwire.org/saucy/), and the cronjobs should have it caught up the rest of the way soon
<cjwatson> Lovely, thanks
<jono> diwic, TheMuso see https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1208485 for the Skype audio bug report
<ubottu> Launchpad bug 1208485 in pulseaudio (Ubuntu) "Skype audio in Saucy broken" [Undecided,New]
<diwic> jono, are you using skype from the partner repository ?
<diwic> jono, there is a workaround since ~ a week back or so
<diwic> jono, at least for one bug, not exactly sure if this is the same.
<diwic> jono, also have you confirmed with others if this is a generic problem or hardware specific?
<jono> diwic, I am using Skype from skype.com
<jono> I haven't confirmed with others
<jono> diwic, what is the workaround?
<diwic> jono, start skype from the terminal like this: "PULSE_LATENCY_MSEC=50 skype"
<diwic> jono, start skype from the terminal like this: "PULSE_LATENCY_MSEC=50 skype"
<jono> diwic, didnt work
<jono> removing this version of skype and installing the partner one
<diwic> jono, so I tested here. Skype works fine here, the second time. echo123 hang up on me the first time, but I doubt that was PulseAudio related.
<cr3> ogra_: sorry for the lag, I ended up build-depending on p7zip-full to extract what I need from an ISO with the 7z command.
<ogra_> ah, cool solution
<jodh> jibel, pitti, slangasek: FYI, having issues using nested kvm on openstack: 200% cpu usage with occasional dashes of kernel panics (bug 1208455).
<ubottu> bug 1208455 in linux (Ubuntu) "general protection fault running apt-get inside nested kvm VM on OpenStack" [Undecided,Incomplete] https://launchpad.net/bugs/1208455
<slangasek> hmm
<doko> seb128, which one was the package we had issues with one gcc-linaro merge?
<seb128> doko, gtk+3.0
<seb128> doko, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1194123
<ubottu> Launchpad bug 1194123 in Linaro GCC "[gcc-linaro wrong-code regression] gcc 4.8.1-2ubuntu1 to 4.8.1-3ubuntu1 breaks gtk on armhf" [Undecided,Confirmed]
<doko> seb128, could you recheck this with the gcc-4.8 from the ubuntu-toolchain-r/test ppa?
<dkessel> hello, i have sent a mail to the ubuntu-devel-discuss ML three days ago. I only got an automatic response that my mail is pending approval by a moderator. what can i do?
<dkessel> should i just ask/present the problem here or should i wait?
<rbasak> dkessel: I don't think ubuntu-devel-discuss is moderated for subscribers. Are you sure it's ubuntu-devel-discuss (and not ubuntu-devel) that you sent the message to, and that you sent the email from your subscription address?
<dkessel> rbasak, hm. the response did not state that i have to subscribe...
<dkessel> i have not subscribed
<rbasak> dkessel: it's pretty common to require subscription to avoid moderation. Most mailing lists do it to avoid spam.
<rbasak> dkessel: easiest way to get it through is to subscribe, then send from your subscription address. You can even disable delivery once subscribed if you don't want to actually "subscribe".
<dkessel> rbasak. ok, thank you.
<rbasak> dkessel: I suggest that you subscribe, cancel the original message (a link to do that is in the "awaiting moderation" email, and then re-send. That way you don't need to wait on a moderator (I'm not sure who that is).
<rbasak> None of this applies to the ubuntu-devel list, which is moderated for non-Ubuntu-developers.
<rbasak> )
<dkessel> rbasak, i am afraid i have already deleted the automated response...
<dkessel> ok, mail is out
<darkxst> is there some way I can generate apt source lines from LP-PPA-* tags (LP-PPA-gnome3-team-gnome3)
<darkxst> Software properties api wants ppa:x/y style input
<darkxst> cjwatson, ^
#ubuntu-devel 2013-08-06
<mwhudson> hm
<mwhudson> it seems that building eglibc does not respect DEB_CFLAGS_APPEND
<mwhudson> am i on crack?
<infinity> It very much doesn't use dpkg-buildflags, no.  It can't.
<infinity> What were you hoping to do?
<mwhudson> infinity: i guessed it might be special
<mwhudson> infinity: build with -fno-omit-frame-pointer
<infinity> On which arch?
<mwhudson> infinity: armhf
<infinity> mwhudson: debian/sysdeps/armhf.mk
<infinity> mwhudson: libc_CC = $(CC) -fno-omit-frame-pointer
<infinity> mwhudson: Something like that should do.
<mwhudson> infinity: add that line?
<infinity> mwhudson: Yeah.
<infinity> mwhudson: I thought that was the default on all but ix86 anyway?
<mwhudson> trying
<mwhudson> nope
<infinity> Then the manpage lies. :P
<mwhudson> heh
<infinity> Or, misleads.
<infinity> Though, I'm curious what you're trying to solve.
<mwhudson> infinity: i want perf record -g to do something useful
<mwhudson> if frame pointers were mandatory on arm then stack unwinding would be a LOT less full of crack :)
<infinity> Ahh.
<mwhudson> (they are mandatory on arm64 i hear)
<mwhudson> infinity: seems to be working, thanks:
<mwhudson> $ grep no-omit-frame-pointer -c eglibc_2.17-0ubuntu5_armhf.build
<mwhudson> 143
<mwhudson> now, i have a benchmark running that's going to take a few hours, this build is going to take a few hours
<mwhudson> and it's 2pm
<mwhudson> too early to start drinking?
<infinity> I dunno, but it's 3am here, might be bedtime.
<mwhudson> it's possible
<Taggg> hello, is branch merging officially discussed anywhere other than launchpad? e.g. mailing lists?
<ScottK> Taggg: You may want https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
<Taggg> ScottK: that list looks pretty low volume
<ScottK> It is.
<Taggg> https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2013-July/thread.html
<ScottK> UDD is essentially unmaintained.
<Taggg> ScottK: is that another way of saying that if i fix a bug and propose a merge, it will likely not be merged?
<ScottK> No, as long as the branch isn't out of date, it'll probably be sponsored.  What it means is that it's unlikely that if a branch isn't imported because of a bug, it'll get fixed anytime soon.
<Taggg> ScottK: cool, any way for me to gauge how long a fix would take to be merged?
<ScottK> Not really.
<ScottK> Alternately, you can make a debdiff of the fix, attach it to the relevant bug in LP and subscribe ubuntu-sponsors to the bug.
<Taggg> ScottK: what's the advantage of a debdiff over a fixed branch?
<Taggg> ScottK: the fix is a fast-forward from the dev branch
<ScottK> Not everyone deals with merge proposals.
<ScottK> There may be people who don't deal with debdiffs when sponsoring, but I don't know of it.
<Taggg> ScottK: alright thanks
<dholbach> good morning
<dpm> good morning seb128, didrocks. Could one of you help me with this? -> https://lists.ubuntu.com/archives/ubuntu-archive/2013-July/046578.html
<didrocks> dpm: opening a tab, will get to it before EOD if seb128 doesn't beat me :)
<dpm> thanks didrocks!
<didrocks> yw ;)
<seb128> didrocks, thanks, I probably won't, I still have some desktopish review to do in the queue ... I was hopping infinity or others would pick up a bit of NEW review but that doesn't seem to happen
<didrocks> seb128: yeah, we are NEWing a lot between you and me this cycle :)
<cjwatson> darkxst: LP-PPA-* sounds ambiguous; either the owner or the PPA name might contain "-".  I'd suggest finding some different source of input ...
<darkxst> cjwatson, I know, but there is no other source (this is from the Dependencies.txt on crash reports)
<darkxst> right now I am just trying all the options until I find a valid combo
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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: ev
<ev> apw: did we ever come up with a signature for suspend/resume failures? Would what apport is using for the title field here (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1117792) be sufficient, or do you think there's a better set of concatenated fields we can key against?
<ubottu> Launchpad bug 1117792 in linux (Ubuntu) "[Hewlett-Packard HP EliteBook 8460p] suspend/resume failure" [Medium,Incomplete]
<ev> apw: we should be seeing other types of kernel OOPSes (ones with OopsText set) with RT 63730, but looking at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=apport-kerneloops&orderby=-id there don't appear to be many of those.
<ev> jodh: does this look vaguely sensible: http://paste.ubuntu.com/5954467/ ? I presume I cannot use the setuid stanza because I need to first obtain the uid from stat'ing the crash file.
<ev> jodh: trying to mimic what apport does in /usr/share/upstart/sessions/update-notifier-crash.conf, only running apport with elevated privileges if we're dealing with a report from a "system" user (uid < 500)
<pete-woods> didrocks: hi! I've forgotten who I'm supposed to talk to to get launchpad projects into CI - something tells me it's you, but then maybe my brain is broken?
<ev> though perhaps we could just always run it as the user, never running as root
<didrocks> pete-woods: for upstream merge, it's fginther
<didrocks> pete-woods: for getting to distro, it's me :)
<pete-woods> didrocks: I'd like to get into distro :)
<didrocks> pete-woods: is upstream merger already configured?
<pete-woods> didrocks: I could only say no, as I don't really know what that is
<pete-woods> guessing it pushes stuff into debian somehow
<pete-woods> basically I've set up 3 new launchpad projects, and checked they build with a recipe in my own private PPA
<didrocks> pete-woods: no, it's what is taking a MP and merging to trunk
<pete-woods> ahh
<pete-woods> didrocks: then no, I've literally just created projects and branches myself
<didrocks> pete-woods: ok, can you get that done first? then, we can talk about distro ;)
<pete-woods> didrocks: is that something I can set up myself? or do I ping someone else?
<didrocks> pete-woods: you need to ping fginther
<pete-woods> okay, cool, will do that then - thanks! :)
<didrocks> pete-woods: do you have the project links so that I can already prepare what's needed?
<pete-woods> didrocks: https://launchpad.net/libqtdbustest https://launchpad.net/libqtdbusmock https://launchpad.net/indicator-network-prompt
<pete-woods> didrocks: they depend on each other in that order, too
<didrocks> pete-woods: thanks!
<jodh> ev: looks ok. I'd be tempted to quote all occurences of $MATCH though. If the stat fails, the job will exit too, but I guess that's probably desirable behaviour anyway.
<ev> jodh: ah, good catch. Will do
<doko> didrocks, seb128, sil2100: ping
<didrocks> (context would be great)
<pete-woods> fginther: good morning! - when you get chance, would you be able to set some more projects up to do CI for me?
<fginther> pete-woods, morning! No problem. Can you ping me again in 30 minutes if I don't get back to you first?
<pete-woods> fginther: of course! :)
<tseliot> stgraber: are you around?
<stgraber> tseliot: yep
<fginther> pete-woods, I have some time now
<pete-woods> fginther: cool, basically it's 3 new launchpad projects
<pete-woods> fginther: https://launchpad.net/libqtdbustest https://launchpad.net/libqtdbusmock https://launchpad.net/indicator-network-prompt
<pete-woods> fginther: I've set up recipies that build to my own PPA to verify the first two should build already
<fginther> pete-woods, are all three indictor related?
<pete-woods> fginther: only the last one, the first two are general purpose for anyone using at and dbus who wants to write tests
<pete-woods> *at -> qt
<fginther> pete-woods, thanks. I'll ping you when I have them setup
<pete-woods> fginther: awesome, thanks :)
<fginther> pete-woods, has indicator-network-prompt been reviewed by the integration team for daily-release?
<pete-woods> fginther: no reviews have been done yet, I just wanted to have my tests running on Jenkins for that really
<fginther> pete-woods, not a problem,
<pete-woods> fginther: at the moment it won't even produce a deb file most likely :p
<fginther> pete-woods, ack
<seb128> diwic, hey
<tedg> cjwatson, Is there any issue with the main inclusion of click, or is it just a TODO and paperwork?
<cjwatson> Just paperwork I think
<cjwatson> tedg: I don't think there'll be any particular issue; jdstrand et al might want to take the opportunity to do an updated code review, I suppose
<tedg> cjwatson, Okay, cool.  I was just being asked by the Unity team about it, making sure there wasn't any blockers.
<tedg> I need to update to click 0.3 as well.
<cjwatson> Are you OK with that extension I added?  I realise it's not quite everything you asked for, but I think it should do the job ...
<tedg> Yes, I think that it's fine.  I'm still a bit worried about having a section called "hooks" in the manifest, but it's a semantic argument at this point not a technical one.
<cjwatson> Yeah, I thought you might mention that.  I might rename that at some point, but backward-compatibly
<jdstrand> cjwatson: does click-apparmor need to be adjusted to use Hook-Name?
<jdstrand> cjwatson: or changed in some other way for 0.3.0
<cjwatson> jdstrand: Not if you're already calling it apparmor.hook; and AFAIK there's only really one consumer of apparmor so I don't see the point
<jdstrand> /usr/share/click/hooks/apparmor.hook
<jdstrand> ok
<diwic> seb128, oh sh* missed the meeting :-(
<diwic> seb128, terribly sorry
<diwic> seb128, it fell out of my head completely :-(
<seb128> diwic, no worry, we settled for doing things the simple way in a first iteration
<seb128> diwic, lool took notes and updated https://blueprints.launchpad.net/ubuntu/+spec/touch-silent-mode
<seb128> diwic, we are going to just teach the phone/messaging/notification services to respect a gsettings key at first
<seb128> diwic, then we can work on a better solution later as resources permit
<seb128> diwic, we can have another meeting about the better solution later if needed
<diwic> seb128, okay, that sounds reasonable
<lool> diwic: Ah, and I looked for you on another irc channel, I should have checked here too
<seb128> lool, I pinged him here at the start of the meeting, he just replied
<seb128> lool, e.g wouldn't have make a difference
<seb128> lool, so don't blame yourself about it ;-)
<diwic> all blame on me
<lool> can do!
<tseliot> slangasek: sorry to bother you again, are you back for the sprint and up for reviewing an SRU?
<slangasek> tseliot: I am back - which SRU, the fglrx one still?
<tseliot> slangasek: bug 1198942
<ubottu> bug 1198942 in nvidia-prime (Ubuntu) "Hybrid Graphics and general enablement for fglrx and nvidia in Precise for 12.04.3" [High,In progress] https://launchpad.net/bugs/1198942
<slangasek> tseliot: right
<tseliot> slangasek: thanks
<jamespage> doko, any plans around re-merging distribute/setuptools?
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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:
<doko> jamespage, go ahead if you want =)
<doko> maybe the delta can be dropped now. didn't check
<jamespage> doko, I guess thats a 'no plans' then
<jamespage> doko, distribute re-merged into setuptools AFAICT
<doko> jamespage, yes, that too. didn't find time for that. just updated debian to the last distribute version
<jamespage> doko, I'll take a look and see then
<doko> thanks
<mitya57> jamespage: you may want to coordinate that with barry â he posted some thoughts about that @ https://lists.debian.org/debian-python/2013/05/msg00104.html
<jamespage> mitya57, thanks for the pointer -will do
<doko> mitya57, jamespage: well, I would like to see the current one first in testing / saucy, then update
<slangasek> YokoZar: can you rebuild your ppa wine packages for the gphoto transition?
<slangasek> YokoZar: also, why is saucy still at wine1.4?
<Ghoul_> Hi. I built a custom 3.8.0 kernel because I need to use my own DSDT. I followed instructions for copying the config over from the stock kernel and then built the kernel using `make deb-pkg` and installed it. When I boot I get dropped into grub shell and theres no drive devices under /dev/. The command line params being passed to the custom kernel are the
<Ghoul_> same as the stock kernel. Stock kernel continues to boot fine.
<Ghoul_> Any ideas?
<sarnold> Ghoul_: did you make / update the initramfs / initrd?
<Ghoul_> I tried to, but I may not have done it correctly
<Ghoul_> I certainly did the initramfs but I don't remember doing initrd
<sarnold> two different names and technologies for what's essentially the same thing. if you did one, you're probably fine..
<Ghoul_> ok
<Ghoul_> I just ran it again, I'll quickly reboot and see if that fixes anything
#ubuntu-devel 2013-08-07
<YokoZar> slangasek: Will do.  I've been considering migrating it (and not having "wine1.4" but rather just "wine", as I think Wine unstable releases are never again going to go into Ubuntu archive)
<skellat> I've done what I can with this and need to hand it off to a patch pilot for further care: https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1207493
<ubottu> Launchpad bug 1207493 in xubuntu-docs (Ubuntu) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Confirmed]
<goddard> anyone else have a qt app that uses the system tray?
<dholbach> good morning
<doko> Laney, what is the trick with the signature check in db?
<seb128> doko, he's on holidays this week
<doko> meh
<doko> xnox, cjwatson:
<doko> $ sudo apt-get install libboost-dev:armhf
<doko> Reading package lists... Done
<doko> Building dependency tree
<doko> Reading state information... Done
<doko> Some packages could not be installed. This may mean that you have
<doko> requested an impossible situation or if you are using the unstable
<doko> distribution that some required packages have not yet been created
<doko> or been moved out of Incoming.
<doko> The following information may help to resolve the situation:
<doko> The following packages have unmet dependencies:
<doko>  libboost-dev:armhf : Depends: libboost1.53-dev:armhf but it is not going to be installed
<doko> E: Unable to correct problems, you have held broken packages.
<doko> however installing libboost1.53-dev:armhf directly works
<cjwatson> try libboost-dev:armhf and libboost1.53-dev:armhf simultaneously
<cjwatson> and/or -o Debug::pkgProblemResolver=true
<yofel> is there an error tracker handbook somewhere? I was looking at the error reports for a package and I'm clueless what that graph is trying to tell me
<dobey> yofel: the graph is to help visualize timeframe, to help identify if a new upload greatly increased number of crash reports happening. (iow, introduced a regression or new crash)
<yofel> dobey: hm, that's what I thought, but it doesn't say what the timeframe is, nor do I understand what the numers at the left are, nor why a graph can start somewhere in the middle. (ok, full graph timeframe is probably the one I select below it)
<yofel> about the numbers at the left: is 0.0 good or bad?
<dobey> yofel: lower is better. numbers on left are some factor of reports/hr or something
<dobey> yofel: 0.0 would mean no reports
<yofel> ok, thanks
<dobey> (i don't know if it's reports/hr or second or what, but it's something regarding number of reports over some time period)
<dobey> and yeah, i wonder where the X axis labels went
<dobey> it used to have day of month numbers iirc
<ev> jodh: thanks for the spot on using syslog. So is the general sentiment that we should move away from per-daemon log files, or to use rsyslog's matching facility to split them out if need be?
<purezen> Hey guys ! I recently purchased an EVDO data card, Teracom T-U500.. It's working perfectly fine under Windows but doesn't work in Linux.. The modem does not get detected at all.. Seemingly, it can't perform a successful 'usb_modeswitch' operation.. Please help..!
<dobey> purezen: #ubuntu is the help channel.
<purezen> dobey: Ok..:-)
<xnox> doko: i guess libbost1.53-dev should not depend on libstdc++6-4.4-dev
<xnox>  | libstdc++-dev
<xnox> but rather something modern...
<pete-woods> robru: hi!
<robru> pete-woods, hey!
<robru> hello from GUADEC actually!
<pete-woods> robru: :D
<pete-woods> robru: do you have any idea why all those jobs you've been looking at fail with missing dependency "build-essential:native" ?
<pete-woods> am I doing something stupid with my debian/control file?
<robru> errrr... build-essential? didn't see that error
<robru> I thought they were failing because they depended on each other.
<pete-woods> robru: http://s-jenkins:8080/job/libqtdbustest-saucy-amd64-ci/5/console
<pete-woods> that's at the bottom of the dependency chain
<pete-woods> robru: there's also a weird bit earlier in the log, saying it wants to remove g++, build-essential and a bunch of other packages
<robru> pete-woods, can you pastebin? I can't get on the VPN due to crappy wifi here.
<pete-woods> robru: https://pastebin.canonical.com/95595/
<robru> thx
<dobey> jibel, cjwatson: do either of you know if autopkgtest (adt-run) has issues with not applying newly added patches for some reason?
<pete-woods> robru: hmm, there's a gpg error too
<robru> pete-woods, actually, I also forgot to bring my yubikey :-( anyway you can publicly pastebin it? or I guess email it to me if you insist on it's privacy
<cjwatson> dobey: I wouldn't expect that to be something autopkgtest deals with directly at all
<pete-woods> robru: http://pastebin.ubuntu.com/5959241/
<pete-woods> I always forget the canonical one is private
<cjwatson> It just unpacks the source package with dpkg-source -x
<robru> pete-woods, thx ;-)
<dobey> cjwatson: ok. i'm using the tools in lp:auto-package-testing to run the tests under qemu, from a bzr tree where i've added a new patch to debian/patches/ and am adding autopkgtest config in debian/tests/. the tests/control has build-needed, and the build is failing before it even runs the tests, due to the patch not being applied
<dobey> cjwatson: i guess in this case, patches which aren't pre-applied in the dpkg source are not getting applied?
<dpm> cjwatson, or dholbach, could you approve the e-mail I just sent to ubuntu-devel regarding the app competition announcement? Thanks!
<cjwatson> if you're running from a working tree, it would probably have to go to special lengths to apply them.  I don't see any reason you wouldn't just push your way up to the top of the patch stack first though
<robru> pete-woods, at first glance that actually looks like a bug in libc6-dev package (it depends on something that doesn't exist). it's possible that perhaps there's been a new upload of libc6, however the build system only got the newer version of libc6 but didn't get libc6-dev. not sure how to fix that though
<cjwatson> dpm: I don't think dholbach is an ubuntu-devel moderator?
<robru> pete-woods, it could even be a race condition, maybe just try it again without any changes?
<cjwatson> dpm: There's nothing from you in the queue, anyhow
<pete-woods> robru: I've tried it several times, it's (un)fortunately consistent
<dpm> cjwatson, oh, I thought he was, in that case, consider the question directed to you only. Oh, perhaps I'm whitelisted?
<cjwatson> dpm: Dunno, but nothing for me to do :)
<cjwatson> dpm: https://lists.ubuntu.com/archives/ubuntu-devel/2013-August/037561.html
<pete-woods> I'm surprised more builds aren't failing - maybe there's something about the specific selection of packages I've gone for
<robru> pete-woods, what package is doing this?
<pete-woods> robru: libqtdbustest
<dpm> yep, it's there. thanks cjwatson nevertheless :)
<cjwatson> pete-woods: That looks like some weird inconsistent set of sources in sources.list
<cjwatson> pete-woods: saucy consistently has -91ubuntu1
<robru> cjwatson, yeah, that's what I was thinking, somehow it has one version of libc6 and a different version of -dev.
<cjwatson> pete-woods: And its libc6-dev has Depends: libc6 (= 2.17-91ubuntu1)
<robru> pete-woods, I don't see anything in debian/control that could cause that. it looks pretty normal.
<cjwatson> pete-woods: Perhaps upgrading the chroot would help
<cjwatson> pete-woods: It probably has libc6-dev preinstalled and maybe it's failing to resolve the upgrade correctly for some reason
<dobey> cjwatson: because i don't normally apply the patches in places, because i'm not using vcs-bzr:. i'm just using the imported branch to merge in new upstream release, and make necessary changes, then bzr bd -S, do test builds, and dput the source.changes; so in that whole cycle of updating a package, new patches don't get applied in-tree
<robru> http://paste.ubuntu.com/5959280/ versions look fine on my system
<cjwatson> dobey: try bzr bd -S and then run tests based on the source package instead?
<cjwatson> the .dsc
<cjwatson> pete-woods: I suspect there's actually some other flaw, and that once the chroot is upgraded you'll get a more sensible error
<robru> fginther, didrocks: can you take a look at pete-woods' issue? I'm stumped ^^^
 * didrocks is in urgency mode right now on Mir + hangout
<dobey> cjwatson: well, just did a quilt push to test with. didn't think of that before. thanks. hitting another issue now though, so trying to figure out what it is :)
<fginther> robru, pete-woods, I can take a look, but it would be in a couple hours
<pete-woods> fginther: that's not a problem, it's out of my depth - I think cjwatson is onto something with the chroot upgrade
<fginther> pete-woods, ack. I can start with that when I get to it
<robru> fginther, great, thanks.
<ogra_> cjwatson, does click have any concept for installying something like an audio codec ? (ie. something system wide)
<cjwatson> ogra_: Only if there is a system-level hook that can consume it
<cjwatson> ogra_: But consider the enormous difficulty of AppArmor-confining a codec separately from the program using it
<ogra_> so its at least technically possible
<ogra_> hmm, yeah
<cjwatson> I would not consider that to be a wise thing to deliver in a click package
<ogra_> thats bad, since we most likely cant ship mp3 support in the free images
<cjwatson> Feel free to discuss the confinement issues with the security team ...
<cjwatson> Also isn't mp3 going out of patent really soon?
<ogra_> oh ? already ?
<xnox> cjwatson: i thought it got extended via extension / followon patents.
 * xnox needs to check
<cjwatson> WP thinks "patents required to implement MP3 expired in most countries by December 2012, 21 years after the publication of ISO CD 11172" but that in the US it might run up as late as 2017
<cjwatson> (I try not to actually read patents though)
<smartboyhw> kirkland, roaksoax ping
<fginther> pete-woods, robru. I'm updating the builders. will have an idea if this helps soon
<robru> fginther, great, thanks.
<slangasek> jodh: so do you think we should further discuss the VM wiring?
<slangasek> jodh: again, if you've already got the current harness working I don't think you need to replace it right now... but I do expect we'll want to replace it at the first sign of reliability trouble
<jodh> slangasek: I think I've got enough now. However, will focus on overcoming this kernel panic first.
<slangasek> right-o
<jodh> slangasek: sure. I actually started out by running the tests as jobs but then got swayed by the "autopkgtest way" :)
<slangasek> hmm
<slangasek> from my perspective, one VM spin-up per "test" is the logical breakdown
<slangasek> jodh: oh, do you have reboot tests in there?
<slangasek> can't very well keep an ssh connection open across reboots, either
<jodh> slangasek: not formally, but we do have to reboot prior to the test run.
<slangasek> you aren't able to manipulate the VM's disk contents to pre-stage it?
<jodh> slangasek: I started out doing the pre-test config using nbd but it gets nasty and overly-complex so now do it via ssh. Also, it doesn't help to use nbd after the tests to pull the results off since if the vm crashes, mounting the dirty disks results in carnage
<slangasek> ok
<doko> xnox, just remove the libstdc++-dev dependency? that's always guaranteed by build-essential
<hallyn> so, bugs saying 'FTBFS on sparc' - are those deemed invalid?  we have no sparc builders at all still right?
<slangasek> hallyn: is hardy still supported? I've lost track
<slangasek> hallyn: oh right, it is not
<slangasek> so yeah, no more supported sparc releases
<slangasek> oh, correction, sparc still shows up in lucid
<hallyn> ok.  checking the debian package just to make sure there's no trivial fix...
<slangasek> though I'm not sure it was usable
<hallyn> hm
<hallyn> so are we building all of lucid using qemu-sparc?
<hallyn> wonder if a debianimport of acpica-unix would be worthwhile.
<hallyn> looks like al stone has been doing a lot there
<slangasek> hallyn: if there are no more sparc builders, then I guess we're not building it at all ;)
<slangasek> https://launchpad.net/builders shows one sparc buildd, though
<hallyn> slangasek: i'm not sure how to check, but the whole problemw ith building a sparc bios was that (i thought) we had no builder at all
<hallyn> hm
<slangasek> the problem was that you needed to build it as an arch: all package
<hallyn> well no, we coudl at least buidl an arch:sparc package and have users manually download it
<hallyn> as opposed to having them download the debian pkg :)
<hallyn> so yeah, he's using the lucid version.  valid i recon'.
<hallyn> thx
<fginther> pete-woods, https://jenkins.qa.ubuntu.com/job/libqtdbusmock-saucy-amd64-ci/4/console
<fginther> pete-woods, libc issue is gone, but there is a new dependency issue
<xnox> doko: oh, it is? excellent.
<doko> xnox, hmm, Provides: libstdc++-dev
<doko> in libstdc++-4.8-dev
<xnox> doko: for me locally i rebuild the package locally to depend on libstdc++-4.8-dev instead of 4.4 and it installed fine. So I was going to upload that.
<pete-woods> fginther: I don't expect that one to build yet, as it depends on libqtdbustest
<fginther> pete-woods, ack, let me see if I can resolve that
<fginther> pete-woods, sorry, looks like I had things in the wrong order
<pete-woods> fginther: looks like you fixed it - that failure is something I should be fixing
<fginther> pete-woods, cool (at least for me :-) )
<mdeslaur> stokachu: are you planning a libgcrypt11 merge soon?
<mdeslaur> stokachu: else, I'll upload the security fix we did to raring
<cjwatson> jdstrand: Anything I can do to help the click MIR?  Not to rush the review, but Ted's Upstart work will have trouble landing until that's done
<jdstrand> cjwatson: no, will do it in a bit. tedg pinged me already
<cjwatson> Cool
<infinity> hallyn: We still build lucid/sparc, yes. :P
<hallyn> infinity: there's one sparc in the buidl farm - we don't ahve a sparc porter though right?
<infinity> hallyn: We do.  faure.
<infinity> hallyn: And there's only one buildd because the other is being used for some kernel experimentation, it's not dead.
<dobey> is it just me, or does autopkgtest *always* do "debian/rules build" even when build-needed is not specified in debian/tests/control?
<dobey> or is that only when building from a working tree?
<hallyn> infinity: thanks, faure noted
<infinity> hallyn: porter-$arch.canonical.com is easier to remember.
<hallyn> thx
<slangasek> unless that arch is powerpc
<infinity> Alright, so we have 23 highbank nodes building armhf now.
<infinity> doko: Time for a rebuild test?
<doko> infinity, no will wait for the next gcc-4.8
<doko> next week
<infinity> doko: Sure.  Just figured it would be a good burn test for the highbank nodes.  But no huge rush.
<doko> are the other nodes available as development boxes?
<infinity> doko: There are no other nodes.
<infinity> doko: (rbasak has a plan to make a pool of nodes available on a take-it-and-abuse-it dev basis, you should poke him about that)
<ogra_> infinity, we do what ?!?
<ogra_> infinity, that message needs to be in CAPS !
<cjwatson> infinity: oarsome
<cjwatson> infinity: maybe we should give back pypy?
<slangasek> infinity: w00t
<cjwatson> slangasek: porter-ppc> that's what .ssh/config is for
<infinity> cjwatson: Oh, yeah.  Please do.  Curious to see if it works.
<cjwatson> infinity: done
<slangasek> cjwatson: to locally work around glaring inconsistencies? ;)
<infinity> cjwatson: I assume he meant "because davis is down", not "because IS can't spell 'powerpc'".
<infinity> Oh, or maybe he meant the spelling thing. :P
<slangasek> yep
<cjwatson> Oh, could be.  I've had
<cjwatson> Host porter-powerpc
<cjwatson>         HostName porter-ppc.canonical.com
<cjwatson> in .ssh/config for ages
<cjwatson> because Debian architecture names ftw
<cjwatson> infinity: is number 24 in that list going to be the livefs builder?
<infinity> cjwatson: 00, but yes.
<cjwatson> You and your zero-based numbering
<infinity> cjwatson: Matches the internal fabric node numbering.  *shrug*
<cjwatson> How much RAM per node?
<infinity> 4G
<cjwatson> That should help
<infinity> Yeah.  Should do.
<infinity> 4 cores instead of 2, slightly faster per-core.
<infinity> And the SATA throughput is about 4x that of the USB on the Pandas.
<cjwatson> A mass give-back might be worthwhile.
<infinity> So, all in all, not an awful upgrade.
<infinity> When they work.
<infinity> Yeah, I'll do that now.
<infinity> Let's see if any nodes explode, and how creatively.
<cjwatson> infinity: Looks like the mass give-back script retries both release and -proposed.  I suppose that kind of makes sense.  Ish
<cjwatson> Compare https://launchpad.net/ubuntu/+source/qtwebkit-source/2.3.1-0ubuntu3 and https://launchpad.net/ubuntu/+source/qtwebkit-source/2.3.2-0ubuntu1
<infinity> cjwatson: Hrm.  I said -s saucy-proposed, but I imagine that ends up being "where the build was created", rather than "where the source now lives".
<cjwatson> Yeah, could be
<infinity> cjwatson: There's some oddities like that with build records.
<infinity> Also, these machines are remarkably good at kernels.
<cjwatson> How fast?
<infinity> I retried a failed linux-ti-omap4 SRU.  3:55 to fail on the last Panda that tried it, 1:05 to fail on the highbank node.
<rsalveti> \o/
<cjwatson> Last linux/armhf build was 17:36.  Wonder what we'll get from highbank
<infinity> A smaller number.
<infinity> I hope. :)
<stgraber> yay, finally decent buildds!
<infinity> stgraber: Something about chickens and counting them comes to mind.  "faster" is a good adjectuve.  "decent" is yet to be seen.
<infinity> If we don't bump half of them offline in the first week, I'll be happy.
<stgraber> infinity: well, 4GB DDR3 ECC
<infinity> Anyhow, Rob has promised me that he'll fix every single kernel bug we run into, and I'm holding him to that.
<infinity> So, as long as the firmware/fabric doesn't melt, we're in good shape.
<stgraber> infinity: cardboard is cheap so improving the existing air flow is easy to do if needed ;)
<infinity> stgraber: *snicker*
<rsalveti> we can test with qtwebkit hehe
<infinity> Anyhow.  That was the last thing I had to do in London.  Flying through the air all magic-like tomorrow, I'll see everyone in a day or two.
<cjwatson> Safe travels and well done
 * infinity packs up his laptop to go find a pub that wants all of his money,
<cjwatson> infinity: Before you go, is the livefs builder installable by ops now?
<infinity> cjwatson: Yeahp, we did the base system install, and puppeted it as a dak/livefs buildd (same puppet profile as cadejo), so it just needs chroots.
<cjwatson> infinity: OK, if you want I can try to move that along tomorrow
<infinity> cjwatson: Sure thing.  kishi00.buildd is the host.
<cjwatson> Righto
 * cjwatson -> dinner
<mhall119> can someone help me?  I'm trying to dput a package to a PPA, and I get the following:
<mhall119> Rejected:
<mhall119> qtdeclarative5-poppler-qml-plugin_0.1.1-0ubuntu1.dsc: Unknown section '-'
<mhall119> qtdeclarative5-poppler-qml-plugin_0.1.1-0ubuntu1.tar.gz: Unknown section '-'
<mhall119> Further error processing not possible because of a critical previous error.
<mhall119> the debian/control file is http://paste.ubuntu.com/5959919/
<mhall119> Section: libs is valid as far as I can tell, not sure why Launchpad thinks section is '-'
<mhall119> http://paste.ubuntu.com/5959927/ is the .dsc I get from debuild -S
<slangasek> mhall119: is the Section: field missing from the source stanza of debian/control?
<slangasek> mhall119: the .dsc doesn't list a section at all; having it missing from debian/control is the only thing I can think of that might cause that
<mhall119> slangasek: ah, the Section: field is in the binary package section, not the source package section, is that my problem?
<slangasek> mhall119: yes; needs to be in the source stanza
<mhall119> too, or only?
<slangasek> it's mandatory for the source stanza; it's optional for the binary stanza, with a fallback to the value from the source stanza
<mhall119> thanks slangasek
<mhall119> that did the trick
<dobey> kenvandine: is the QML UOA UI apt-get installable? or where is it on lp if not?
<kenvandine> dobey, ubuntu-system-settings-online-accounts
<dobey> kenvandine: thanks. is that embedded within unity8 directly on the phone, or it's always inside the system-settings app?
<kenvandine> dobey, always in system-settings
<dobey> ok
<stokachu> mdeslaur: i didnt have any plans too
<stokachu> re: libgcrypt
<mdeslaur> stokachu: ok, thanks
<bschaefer> hey, question about xserver-xorg-video-ati in saucy main. Any one know what it seems to be using a git snap shot vs whats in saucy proposed?
<bschaefer> vs say intel: http://paste.ubuntu.com/5960140/
<dobey> bschaefer: what's in -proposed?
<dobey> also, there's no reason why ati and intel would be the same in that respect. they aren't from the same source tree
<bschaefer> dobey, http://paste.ubuntu.com/5960152/
<bschaefer> dobey, right but both are in git, and use a launchpad branch as well
<bschaefer> and its seems in proposed the package looks right, along with nouveau
<dobey> bschaefer: yes, but the snapshot version is the upstream git, not the packaging branch.
<dobey> bschaefer: there's nothing "wrong" aobut that
<dobey> and the -proposed version will eventually go into release
<bschaefer> dobey, alright cool :), just wanted to check as it just seemed a bit different
<bschaefer> thanks!
<Noskcaj> kirkland, roaksoax: Can one of you review/merge my branch for testdrive. It's the last changes that have to happen before the hackfest
#ubuntu-devel 2013-08-08
<saschagehlich> hey, my first attempt on running a manually compiled kernel failed hard. any hints on what could've gone wrong? http://ubuntuforums.org/showthread.php?t=2166046
<didrocks> doko_: I'm going to revert partially your dep on qtchooser:any
<didrocks> the syntax isn't working at all, things are getting blocked in proposed for now
<didrocks> http://launchpadlibrarian.net/147002014/qtbase-opensource-src_5.0.2%2Bdfsg1-7ubuntu3_5.0.2%2Bdfsg1-7ubuntu4.diff.gz
 * didrocks never saw this dep: package:any
<didrocks> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<didrocks> qt5-default/i386 unsatisfiable Depends: qtchooser:any
<didrocks> doko_: as everything in daily release is blocked and FTBFS because of that, reverting for now
<dholbach> good morning
<doko> didrocks, ok
<Whoopie> sladen: Hi, did you find the time to look into the dell special keys issue? Or do we need some other support?
<kirkland> Noskcaj: done
<Noskcaj> kirkland, awesome
<Ghoul_> needless to say, the other day when I said I'd build that kernel and brb, it didn't work.
<Ghoul_> im punting to having the grub dsdt ovveride put back, because its such a PITA to have to rebuild the kernel to do a simple thing like that
<Ghoul_> (especially because ubuntu doesn't support custom_method which is the ideal /easiest/ way of fixing dsdt issues)
<ev> xnox: found the source of my problems from yesterday: http://c-faq.com/stdio/undofreopen.html
<xnox> ev: brilliant. but it worries me that in addition to dup() & dup2() there is also dup3() now.... avoiding freopen in the first place sounds better.
<ev> xnox: I ended up with http://bazaar.launchpad.net/~ev/whoopsie/be-more-verbose/revision/573
<xnox> ev: looks good.
<lifeless> xnox: really need a dupN right ? :)
<xnox> ev: passes as well, i take it? =)
<ev> of course :)
<xnox> excellent
<jcastro_> ev: congrats on the phased updates! \o/
<Noskcaj> kirkland, your testdrive release script broken again. setup.py thinks it's 3.22
<ev> jcastro_: pretty much all the credit goes to bdmurray and cjwatson. I was of minimal help :)
<ev> jcastro: so excited for it though
<ev> we've got some tuning to do, it seems, but this will be massive
<Noskcaj> kirkland, I've fixed that and put it  on pypi
<ev> hm, adb does not like reset (1)
<cjwatson> tumbleweed: If you didn't see, pypy/armhf finally managed to build \o/
<ev> cjwatson: WIN!
<ev> cjwatson: is this thanks to the new buildds?
<cjwatson> ev: yep
<ev> wonderful
<ev> any idea if someone is tasked with looking at what we can move off cpython onto it as a stop-gap for presumed performance issues on Touch?
<cjwatson> nope
<cjwatson> nor whether anyone knows about the policy-level consequences
<ev> policy-level consequences?
<cjwatson> whether we need a load of pypy-* binary packages, whether there's a different byte-compilation scheme / file locations, etc.
<ev> oh yes, we had briefly discussed this when you were in the office, if memory serves
<pete-woods> good morning didrocks! The launchpad projects I mentioned the other day now have autolanding - when you have the chance, it'd be great to have them pushed to distro :)
<cjwatson> yes.  I don't know whether these things are true but they're possible and the questions need to be asked
<didrocks> pete-woods: the 3 of them? robru is working on them AFAIK :)
<didrocks> pete-woods: can you sync up with him? (I see there are some packaging changes pending, I don't have time to review them though)
<robru> pete-woods, yes, it looks like the CI is now working and I'm just about to start setting up the autolanding.
<robru> pete-woods, if you could help me resolve this test failure: http://paste.ubuntu.com/5961984/ it would help us move forward
<pete-woods> didrocks: okay, thanks for the info :)
<pete-woods> robru: I've fixed that failure for the moment
<robru> pete-woods, is your fix in trunk yet?
<pete-woods> robru: should be
<robru> pete-woods, great
<robru> I'm enabling daily release as we speak
<pete-woods> :D
<tumbleweed> cjwatson: \o/
<tumbleweed> now if I could just beat the debian kfreebsd maintainers over the head, and get it to migrate to testing, I could do another upload... :P
<pete-woods> robru: are you able to enable the hooks for google test reporting and gcov coverage?
<pete-woods> as they should be working on all 3 of those projects I believe
<robru> pete-woods, I'm not sure what that means...
<robru> pete-woods, there is a way to get junit test results displayed in jenkings but my understanding is that that requires autopilot.
<robru> or at least I've only ever seen it used in conjunction with autopilot.
<pete-woods> robru: there is a hook that causes google test to output junit xml, and another that enables code coverage reports
<pete-woods> robru: they've been enabled for many of the other projects in Jenkins
<robru> pete-woods, can you name one specifically that does this? I'll take a look at it and try to set it up the same way.
<pete-woods> robru: I know the libusermetrics does, as that's another one that was set up for me
<robru> k
<robru> pete-woods, ahhhh, I see. ok, shouldn't be hard.
<robru> pete-woods, ok, it should all be set up now. I'll run the stack shortly and then we'll see if it explodes or if everything is working ;-)
<pete-woods> robru: awesome, thanks!
<spanner3003> hi I'm having  a problem compiling, I'm trying to port cm10.1 to my padfone 2(A68) and i get this error http://pastebin.com/LNmKyFF1
<robru> spanner3003, maybe try #ubuntu-touch? I don't know anything about that stuff.
<spanner3003> ok thanks
<robru> didrocks, fginther: do you guys see anything wrong with this? https://code.launchpad.net/~robru/cupstream2distro-config/add-indicators/+merge/179139
<didrocks> robru: the 3 were preNEWed?
<robru> uhhhh
<robru> I thought you did that?
<didrocks> robru: when?
<didrocks> you were the one cleaning up the packaging, right?
<robru> didrocks, when you assigned me this on tuesday, didn't you say you prenewed a bunch of stuff?
<didrocks> robru: I prenewed a bunch of stuff, not those. I assign you those on tuesday so that you clean the packaging
<didrocks> and then ask me for preNEWing
<robru> didrocks, oh, ok, well it's ready for prenewing.
<didrocks> robru: ok, so need to take trunk and check those?
<robru> didrocks, yeah, pete landed all my packaging work into trunk
<didrocks> robru:  This package contains the indicator-network-prompt support for Unity.
<didrocks> that doesn't really inform what it's doing :)
<robru> ;-)
<didrocks> can you be more precise in a MP?
<didrocks> (not blocking of course)
<robru> didrocks, well, I don't really know what this package even does. Maybe pete-woods should expand on that description.
<didrocks> pete-woods: please? ^
<didrocks> robru: would have been better to ask upstream before adding it :p
<didrocks> #override_dh_auto_configure:
<didrocks> #   dh_auto_configure -- -DENABLE_MEMCHECK_OPTION=YES
<didrocks> this can be removed rather than commented without any explanation? ^
<pete-woods> didrocks: I want to turn that back on - I'll add a TODO comment
<robru> didrocks, yeah, it was uncommented when I merged. pete commented it after the fact
<didrocks> robru: no COPYING file :(
<didrocks> pete-woods: adding a comment please in debian/rules?
<didrocks> robru: copyright is canonical in the files
<didrocks> debian/copyright says david calle
<robru> didrocks, whoops, that might be a copy&paste error
<didrocks> robru: before I'm doing the others, can you check for those first? ^
<pete-woods> robru: yes
<didrocks> and ping me back
<robru> didrocks, ok, sorry
<didrocks> robru: no worry, I wonder if the mocks shouldn't be in the QA stack rather
<didrocks> robru: wdyt?
<didrocks> libqtdbustest and libqtdbusmock
<robru> didrocks, I dunno. are they only used by indicators?
<didrocks> robru: I think they are going to be used by more in the end
<didrocks> pete-woods: thoughts? ^
<robru> they were already in indicator stack from before, I don't see any compelling reason to move them unless they are used by other things.
<pete-woods> didrocks: I hope they're used be more in the end - they are general purpose libraries for testing Qt based apps that are using DBus
<didrocks> robru: seems it is a compelling reason to move them :)
<didrocks> robru: ah, also, AP tests? at least, please add the indicator to the list of installed packages when testing
<robru> ok
<robru> pete-woods, can you write two sentences describing what indicator-network-prompt does?
<pete-woods> robru: of course - where do you want them?
<robru> pete-woods, just in IRC here and then I'll submit an MP with them how I want them.
<pete-woods> robru: okay
<robru> pete-woods, ... ?
<pete-woods> robru: The indicator-network-prompt project provides the service implementation for prompted connections to wireless networks.
<pete-woods> Essentially, when an attempt to access the internet fails, and available wireless networks have been detected, this service will prompt the user to connect to one of them.
<pete-woods> See <https://wiki.ubuntu.com/Networking#Connecting_to_wi-fi.2C_prompted> for more details.
<robru> thanks
<robru> didrocks, is it ok to have that URL in the package description? ^^
<didrocks> robru: no need for the url I guess
<didrocks> the description is enough
<robru> didrocks, ok, thx
<robru> pete-woods, what's the deal with licensing in libqtdbus*? There's a mixture of GPL and LGPL? Any way we can unify that?
<pete-woods> robru: if there is, it's a mistake
<robru> so should it all be LGPL?
<pete-woods> it should all be LGPL - I thought I'd fixed it all
<robru> there's a few you missed it seems. I'll fix them right now.
<pete-woods> robru: thanks!
<robru> pete-woods, ok, should be fixed, now we'll see if jenkins agrees ;-)
<pete-woods> :)
<robru> didrocks, ok, things are looking good! prenew now? ;-)
<didrocks> robru: did you fix/rereview the other packages?
<robru> didrocks, which others? I did the three indicator ones of pete's
<didrocks> ok, that's the "others"
<didrocks> robru: so moving them to the QA stack as well?
<robru> didrocks, I haven't done the cu2d side. just packaged them for prenewing. will do cu2d next.
<didrocks> ok
<didrocks> robru: hum, still no comment in debian/rules for indicator-network-prompt telling that override_dh_auto_configure comment is temporary
<robru> didrocks, sorry, i thought pete was doing that
<robru> I'll add it.
<robru> didrocks, ok now, and also I MP'd cu2d: https://code.launchpad.net/~robru/cupstream2distro-config/qtdbus-in-qa/+merge/179159
<didrocks> robru: ./usr/include/libqtdbusmock-1/libqtdbusmock/DBusMock.h
<didrocks> all .h are in a libqtdbusmock subdir
<robru> hmmm
<didrocks> shouldn't it be rather: ./usr/include/libqtdbusmock/DBusMock.h
<robru> I guess?
<robru> pete-woods, ^^
<didrocks> robru: on the MP: looks good to me, but please, as discussed, install the indicator-network package (and its dep) for at least having them install while running indicator AP tests
<didrocks> indicator-network-prompt*
<pete-woods> robru: that's intentional - this way when the API changes you can have the old version, too, e.g. /usr/include/Unity-6.0/
<robru> didrocks, oh yeah
<robru> didrocks, ok, so it's supposed to be that way ;-)
<didrocks> pete-woods: how can you? no source will be able to build it
<pete-woods> didrocks: well to be honest, I was really just copying how many other packages seem to ship their devel packages
<didrocks> robru: http://paste.ubuntu.com/5962253/
<robru> fuck
<robru> didrocks, I have to go for lunch, I guess I will fix this all when I get back.
<didrocks> ok, thanks
<mdeslaur> didrocks: any progress on LP: #1200173?
<ubottu> Launchpad bug 1200173 in libecap (Ubuntu) "[MIR] libecap" [Undecided,New] https://launchpad.net/bugs/1200173
<didrocks> mdeslaur: opened, was initially planned to look at it today, but ETOOMANYSTUFF
<didrocks> the Qt issue screwed my day in addition to all the backlog I have :/
<didrocks> mdeslaur: if any MIR team member want to take it, please propose :)
<didrocks> jdstrand, dokoâ¦
<didrocks> (seems that only mterry and I are processing MIRs nowadays)
<didrocks> same for NEWing, people pings me because stuff are blocked in the queue for months
<mdeslaur> didrocks: you'll have to hire an assistant :)
<didrocks> mdeslaur: or having other team members taking some parts? ;)
<doko> didrocks, I'm doing my share for MIR, and I'm not a regular archive admin
<didrocks> doko: can you look at this libecap? ^
<doko> doing
<didrocks> I'm still on the Qt issue
<didrocks> thanks!
<mdeslaur> doko, didrocks: thanks
<didrocks> at least, armhf builders speedup is really appreciated
<doko> didrocks, yes, sorry about that
<didrocks> doko: no worry, it's just unfortunate that this chained on the hybris issue that tackle us back
<doko> mdeslaur, but will need a security review anyway?
<mdeslaur> doko: I don't really know what it is, I'm just trying to get squid3 unblocked...if you think it does, then subscribe the security team
<doko>  eCAP is a software interface that allows a network application,
<doko>  such as an HTTP proxy or an ICAP server, to outsource content
<doko>  analysis and adaptation to a loadable module.
<mdeslaur> hrm
<mdeslaur> isn't it just a bunch of stubs though?
<mdeslaur> doko: there doesn't seem to be any actual auditable code in there...I don't think it needs a security review
<doko> Currently, eCAP support is being added to Squid proxy cache and Spicer ICAP server.
<doko> ok
 * xnox doh!
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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
<xnox> Sweetsha1k: libreoffice precise SRU - bug 1194740, is it time or still waiting on feedback?
<ubottu> bug 1194740 in libreoffice (Ubuntu Precise) "[precise] Saving xls files originally created in Excel 2003 causes considerable increase of file size" [Medium,In progress] https://launchpad.net/bugs/1194740
<rbasak> xnox: FYI, I'm doing the nginx packaging fix that's in the queue at the moment.
<xnox> rbasak: ack =)
<rbasak> xnox: could you please unsubscribe ~ubuntu-sponsors from bug 1160177 and also from bug 1160177? I can't do it.
<ubottu> bug 1160177 in guake (Ubuntu Raring) "guake starts with abnormal indentation" [Undecided,Fix committed] https://launchpad.net/bugs/1160177
<rbasak> uh, bug 1206878
<ubottu> bug 1206878 in nginx (Ubuntu Precise) "[SRU] Configuration should be purged only in nginx-common" [Critical,Triaged] https://launchpad.net/bugs/1206878
<rbasak> Those two :)
<xnox> rbasak: apply / ask dholbach to add you to the https://launchpad.net/~ubuntu-sponsors team. It's open to people with upload rights.
<xnox> rbasak: done.
<rbasak> Thanks!
<rbasak> dholbach isn't here right now but I'll ask - thanks.
<xnox> rbasak: there is a lot of uploaded stuff in the report =) i'm struggling to find things to upload so far ;-)
 * xnox looks into gnome-keyring multiarch patch deja-vu
<rbasak> xnox: what do we do for patches which need to be turned into quilt patches and MPs/debdiffs? Eg. bug 1198882 where the submitter needs help preparing the fix in packaging even though he's found a patch. I subscribed ~ubuntu-reviewers when I triaged that bug, but I'm not sure that team is active.
<ubottu> bug 1198882 in php5 (Ubuntu) "__toString() which stores $this reference triggers segfault" [Medium,Triaged] https://launchpad.net/bugs/1198882
<rbasak> AIUI, doing this kind of work is the definition of "patch piloting", but it tends to not hit the sponsorship queue (as I guess it's not ready for sponsoring)
<xnox> rbasak: at your discretion. at the end of the day we do take pure patches, and should be uploading them as well.
<rbasak> xnox: right, so that is on my "keep an eye/when I can get round to it" list. But what about the general case when I triage them? I'm just bothered that we're losing contributors by not guiding them.
<smartboyhw> dholbach, I think rbasak wants you when you left.
<dholbach> rbasak, can I help with anything?
<dholbach> smartboyhw, thanks
<xnox> dholbach: rbasak wants to join https://launchpad.net/~ubuntu-sponsors
<dholbach> rbasak, done
<dholbach> thanks xnox
<rbasak> dholbach: thanks!
<sergiusens> cjwatson: hey, not sure you are thinking about this, but is there a strategy for ubuntu-bug and click?
<cjwatson> nope
<cjwatson> I'm hoping somebody else will come up with one
<cjwatson> well, except that I have a work item to support separated debug symbols, which is related
<sergiusens> ok, I'll bring it up next week and think about it until then
<ogra_> it kind of works via cmdline
<ogra_> i filed a bug with it today
<steveire> Is collect2 part of binutils?
<steveire> Seems it's part of gcc
<dobey> kenvandine, mardy: is there an architecture overview of signon/uoa stuff?
<sergiusens> ogra_: for a click package?
<ogra_> sergiusens, eh, no :)
<sergiusens> ogra_: that's what we would need to think about solving/addressing :-)
<ogra_> yeah, sorry, my brain kind of cut click out of the sentence :)
<sergiusens> ogra_: or with click you thought mouse click, which lead you to think of you so you mentioned cli.
<ogra_> heh
<ogra_> right :)
<sergiusens> ogra_: just noticed my typo s/you/UI/ :-)
<sergiusens> in the last one
<ogra_> heh
<ev> mpt: would you agree that if an apport package hook crashed, we should still send the report?
<mpt> ev, absolutely
<ev> cool, cc'ing you on a mail to pitti about this then
<mpt> ev, we've encountered other cases where a report isn't useful for debugging purposes but we (do/should) send it for statistical purposes
 * ev nods
<ev> Launchpad bugs is just a very different model
<ev> and supporting both in the code is a bit tricky
<stgraber> ev: hey, do you know why the average Ubuntu system tries to resolve daisy.ubuntu.com every 30s and often much more frequently than that?
<ev> stgraber: I suspect that's a bug in gnetworkmonitor
<stgraber> ev: I just noticed that on a network of around 100 devices here with mixed Ubuntu/android/... almost 25% of the DNS queries are for daisy.ubuntu.com which seems rather insane
<ev> we had something like that ages ago that I thought we fixed
<ev> stgraber: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/connectivity.c#L266 if you want to instrument it a bit to find out exactly what's going on
<stgraber> ev: ah, I think I now what's happening, though that's going to be an interesting problem in the future :)
<ev> oh?
<stgraber> ev: basically network-changed is emited every time I get a new router advertissement for my IPv6 connectivty, which I get a lot of as I have a ton of devices on the network each triggering some of those every few seconds
<ev> ah right
<stgraber> ev: so on an IPv6-enabled network that'll cause an Ubuntu machine to resolve (and possibly contact) daisy.ubuntu.com at least every 30s
<stgraber> more often depending on other machines joining/leaving the network with a minimum interval of 3s (at least with radvd)
<ev> maybe we should just do away with the connectivity check and always try to send the reports
<ev> I just wonder if that will play well with captive portals (though that's not to say the current approach does)
<stgraber> assuming no captive portals will return the data you expect on a successive push, you should be fine, no?
<tseliot> slangasek: are you around?
<ev> stgraber: unfortunately, we just expect a 200 back
<ev> I should probably change that :)
<stgraber> ev: ah, that'd be a problem then
<ev> added to the todo list
<jodh> cjwatson, infinity: are you guys aware of any recent updates that might sever an ssh connection? (with todays server image). I noticed a libc update flash by then my ssh connection died.
<jodh> cjwatson, infinity: may be unrelated though. alas the vm is now gone so trying to recreate...
<cjwatson> not I
<slangasek> there was an eglibc update earlier in the month
<cjwatson> I would bet on something lower-level without much to do with ssh
<slangasek> so if the upgrade code there has gone wrong, it could be breaking ssh connections
<cjwatson> you would have to be really trying to get an update to break existing ssh connections ...
 * slangasek nods
<cjwatson> eglibc uses invoke-rc.d to restart services
<cjwatson> I'm not actually sure how that isn't broken as it stands (won't it fail to restart upstart-based services?) but for ssh in saucy the worst it will do is fail
<cjwatson> (without restarting sshd)
<spanner3003> hi I'm having  a problem compiling, I'm trying to port cm10.1 to my padfone 2(A68) and i get this error http://pastebin.com/LNmKyFF1
<jodh> cjwatson, infinity: panic over - it appeared to be apt-get that was causing the problem but was in fact debootstrap failing due to 'Invalid Release signature' later on.
<cjwatson> that reminds me, I could productively go and verify the lucid debootstrap sru ...
<slangasek> cjwatson: invoke-rc.d knows about upstart
<slangasek> invoke-rc.d is the standard interface in policy, so it's been made upstart-smart
<cjwatson> oh of course
<cjwatson> I knew that
<cjwatson> so it'll just do 'restart ssh', and I'm pretty confident that hasn't broken
<jodh> cjwatson: yup - confirmed that restarting ssh (even stop+start) is fine.
<slangasek> ok
<slangasek> so probably not a real bug in eglibc or ssh
<slangasek> good to have confirmed :)
<slangasek> meh, what has changed that my schroots now have SHLVL=1 in the environment?
<slangasek> (causing my terminal to be needlessly cleared on every exit)
<dobey> kenvandine, mardy: are there any apps that actually use UOA accounts, other than friends?
<seb128> dobey, unity dash, shotwell, empathy
<seb128> dobey, e-d-s
<dobey> seb128: i'm guessing dash itself doesn't, but some of the scopes/lenses might (like the social lens via friends)
<seb128> right
<seb128> the gdrive scope as well
<seb128> iirc
<dobey> right
<dobey> but e-d-s?
<seb128> yes, for calendar
<seb128> google calendars
<dobey> huh. i have google calendars in my evolution, but no accounts for them in UOA. i guess they were never automatically "migrated" into UOA, and they don't get added to UOA if you add them from within evolution?
<seb128> right, it's the other way around
<seb128> if you add a uoa google account, eds will pick it
<dobey> shotwell is the same way?
<seb128> no
<seb128> shotwell doesn't add accounts, it brings you to the uoa panel to add those
<dobey> ok
<jbicha> google calendar integration is a bit broken with UOA, you'll want to install evolution-data-server-goa until the packaging is straightened out
<seb128> jbicha, how broken?
<jbicha> seb128: see bug 1187707 which links to the 2 other bugs with more info
<ubottu> bug 1187707 in evolution-data-server (Ubuntu) "When a Google account is configured, indicator-datetime doesn't display anything" [Undecided,Confirmed] https://launchpad.net/bugs/1187707
<seb128> jbicha, does it work if goa is turned off at build time?
<dobey> well it works fine if you use evolution and add stuff from within evolution, i guess
<dobey> at least, my clock shows events, and so does evolution
<dobey> gnome-shell does do a bit better job of showing them, than indicator-datetime did though
<jbicha> seb128: I've not looked at it closely yet but I think it's just the packaging that needs fixed
<seb128> jbicha, ok, we might end up having to do a double build with conflicting packages
<jbicha> seb128: can you remind me what you did to fix the dependency problem on mobile?
<seb128> jbicha, nothing, it's still high on my todolist, I was pondering just disable goa on arm
<seb128> but the double build could be a better idea there
<dobey> so i guess every app that uses a service has to reimplementing URL signing and parsing of REST responses and such
<dobey> why is online-accounts so complex? :(
<Ampelbein> Is there a preferred way to report out-of-date branches in ubuntu? https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/tboot/saucy has 1.7.1-0ubuntu2 as latest upload, https://launchpad.net/ubuntu/saucy/+source/tboot says 1.7.3-0ubuntu1 as latest.
<dobey> Ampelbein: standard way is report bugs against https://launchpad.net/udd , iirc
<dobey> Ampelbein: but i don't know that they will get looked at ever, if you do :-/
<xnox> Ampelbein: https://bugs.launchpad.net/udd/+bug/653320
<xnox>   A version which the importer believes is has previously imported is not or no longer tagged in the branch. Something has been changed or gone wrong, and further imports have been ceased pending manual review.
<ubottu> Launchpad bug 653320 in Ubuntu Distributed Development "Import fails with "marked but not imported"" [High,Triaged]
<dobey> and probability that the branch will break again in the future is pretty high
<xnox> Ampelbein: http://package-import.ubuntu.com/status/tboot.html#2012-07-05 09:48:07.707637
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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:
<dobey> xnox: sometimes, i have to wonder if you ever sleep :)
<xnox> dobey: i just woke up again =) i had a nap, but having a dinner till 1am with colleagues from the office did throw my clock a bit off today. Went to sleep straight after work =)
<Ampelbein> xnox, dobey: Thanks. I guess it's no use to report then, I assume the package-import.ubuntu.com failure page will get looked at from time to time. Back to using apt-get source.
<xnox> Ampelbein: yeah, I can requeue it at the moment. But it results in launchpad denying udd the right to push the branches back for stable releases =/ and then it's a 401 denied error.
 * xnox need to find lp wizard to figure it out
<dobey> because stable branches are set to read-only
<dobey> well, stable release branch is anyway
<dobey> -updates obviously not. so yeah, you'll probably have to get an ops to help you fix a release pocket branch if it's busted
<kirkland> is there an archive admin around?
<seb128> kirkland, sort of, why?
<kirkland> seb128: sorry, nevermind, bdmurray is helping me out
<seb128> ok
<xnox> cjwatson: is it ok for me to steal trivial automake1.13? there is new point release in debian.
<xnox> cjwatson: actually it can be synced now.
<xnox> hmm http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714452
<ubottu> Debian bug 714452 in automake1.13 "automake1.13: FTBFS: There seems to be no Makefile in this directory." [Serious,Open]
<cjwatson> xnox: Yeah, there are no Ubuntu changes left, I was just worried that the increased test coverage at the same time would result in build failures ... but feel free to take it and deal with the results
<xnox> cjwatson: well trying to fix FTBFS in debian at the moment... it's still running the testsuite. Surprisingly for automake defaulting to parallel testsuite, it doesn't use it itself =)
<xnox> harness that is.
<slangasek> ScottK: hey, so I'm not quite sure of a sane way to query which packages had autopkgtests that would have run against python-qt4; you don't happen to remember which packages were the bottleneck?
<cjwatson> It's pretty likely that it was due to bugs rather than actual test slowness.
<cjwatson> We've had some problems with results not being collected properly.
<slangasek> cjwatson: the python-qt4 sync happened this week; I thought the test collection problems were resolved last week?
<slangasek> maybe my jetlagged brain is getting confused though
<cjwatson> Not sure.  Hopefully the logs have enough information to work it out ...
<cjwatson> My brain is beerlogged so I'm of limited use
<slangasek> the libusbx stuff was a week ago
<slangasek> dunno if there were lingering issues
<ScottK> slangasek: I don't recall which packages.  Sorry.  I was mostly resisting the temptation of abusing my -release powers to override everything and wait to see how long it would take.
<ScottK> Are there logs of what tests ran when?
<slangasek> well, there are logs in jenkins for each test
<slangasek> possibly the front page is sortable by run date
<ScottK> So I could look at the list of logs and see what's a python-qt4 rdepend?
<slangasek> sure - https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/, scroll down to "Jenkins jobs list", sort by "last success"
<slangasek> but none of the tests that ran 2-4 days ago took longer than 20 min, with the exception of eglibc
<ScottK> Yeah, I don't see anything that looks likely, but it was moved to release the day after it landed in proposed.
<ScottK> https://launchpad.net/ubuntu/saucy/+source/python-qt4/4.10.2-2
<ScottK> So I'm no hallucinating.
<ScottK> Maybe it was just backlog.
<xnox> slangasek: ScottK: there are logs from britney, which should list which tests it was waiting on and when.
<cjwatson> If you're lucky
<xnox> =)
<ScottK> Where?
<cjwatson> No, they don't tell you which rdeps it was waiting for
<xnox> ScottK: i thought http://people.canonical.com/~ubuntu-archive/proposed-migration/log but it doesn't show excuses.
<ScottK> It would be nice if it did ...
<cjwatson> Tempting to cat it in
<cjwatson> I need to pack but you have write access to the relevant branch :)
<xnox> it's html thought =/ or can we have txt excuses as well
<cjwatson> html would be fine here
<cjwatson> I mean whatever
<cjwatson> Could probably just cat it out somewhere in lp:~ubuntu-release/britney/britney1-ubuntu
<cjwatson> You could w3m -dump it if you really want
<xnox> right. Well. kernel & automake is still building locally & I'll go back to sleep =)
#ubuntu-devel 2013-08-09
<noaXess> hello
<noaXess> am i at the correct place to ask about package upgade/install problems? it's about mysql-server, maysql-server-5.5 http://paste.ubuntu.com/5965187/
<noaXess> more information after purging mysql-server-5.5 and remove /etc/mysql and /var/lib/mysql and reinstall mysql-server: http://paste.ubuntu.com/5965242/
<sarnold> noaXess: can you run dmesg | grep user.frm   ? I'm curious if the AppArmor policy needs to be extended (errno 13 is "Permission denied")
<noaXess> sarnold: sure.. wait
<noaXess> sarnold: no output
<dholbach> good morning
<noaXess> dholbach: morning
<dholbach> hi noaXess
<noaXess> is it a package problem?
<sarnold> noaXess: well, that's probably for the best for everyone else :) but it does mean I'm not sure what step to take next. maybe try to find that user.frm file and check permissions on it?
<noaXess> sarnold: have you installed mysql-server?
<noaXess> here are perms to root:root sudo ls -l /var/lib/mysql/mysql which i think it should be on mysql:mysql
<noaXess> does the package upgrade/install make wrong perms?
<noaXess> strange: http://paste.ubuntu.com/5965336/
<dholbach> davmor2, happy birthday! :)
<geser> noaXess: see bug 1210380, this seems to be an update regression in -proposed
<ubottu> bug 1210380 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.32-0ubuntu0.12.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1210380
<noaXess> geser: that means? workaround or wait? can't wait.. i'm developing each day on mysql..
<geser> the workaround for now seems to be to downgrade to 5.5.32-0ubuntu0.13.04.1 from -updates/-security
<noaXess> geser: so install an older version..
<noaXess> ok.. hm.. purge first all, recover data
<noaXess> geser: how do i downgrade to that package versino? do i need first purge all mysql-* packages?
<sladen> geser: apt-get install abcdef=1.2.3.4ubuntu1  http://askubuntu.com/questions/138284/how-to-downgrade-a-package-via-apt-get
<geser> sladen: I guess that was meant for noaXess
<noaXess> sladen: yeah.. but that shows dep errors.. so i think i need this: sudo apt-get -s install mysql-server=5.5.32-0ubuntu0.13.04.1 mysql-server-5.5=5.5.32-0ubuntu0.13.04.1 mysql-server-core-5.5=5.5.32-0ubuntu0.13.04.1 mysql-common=5.5.32-0ubuntu0.13.04.1 mysql-client=5.5.32-0ubuntu0.13.04.1 mysql-client-5.5=5.5.32-0ubuntu0.13.04.1 mysql-client-core-5.5=5.5.32-0ubuntu0.13.04.1 libdbd-mysql-perl libmysqlclient18=5.5.32-0ubuntu0.13.04.1
<geser> yes you need to downgrade all mysql 5.5 packages together
<noaXess> can't get it running.. same error then before.. also if i use verinos 5.5.29-0ubuntu1
<noaXess> always on setting up mysql-server-5.5: http://paste.ubuntu.com/5965500/
<noaXess> :'(
<noaXess> what happens if i purge all mysql-* packages? will it break system?
<noaXess> cause purge mysql-common will purge also http://paste.ubuntu.com/5965518/
<seb128> cjwatson, hey, do you still plan to add the icon info the click manifest soon? (I'm waiting on that to make system settings use the manifest instead of the fake datas)
<cjwatson> seb128: It's on my list for this month - will try to get it done over DebConf
<seb128> cjwatson, thanks
<noaXess> geser, sarnold: got my mysql-server running, read bug comments... https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1210380 YESSSSS
<ubottu> Launchpad bug 1210380 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.32-0ubuntu0.12.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed]
<noaXess> 5h later
<rbasak> stokachu, doko_: mysql-5.5 5.5.32-0ubuntu2 is stuck in saucy-proposed. Is this related to verification-failed in bug 1121874?
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<rbasak> Could you see if you can sort it out, please?
<xnox> rbasak: mysql-5.5 autopkgtest fail http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html but it looks like it never passed, thus each time it was probably "adt ignored" manually by release team.
<rbasak> Ah I see. I did get confused by that.
<xnox> rbasak: thus it's waiting for an override.
<rbasak> We'll need to fix 5.5.32-0ubuntu2 anyway, as I presume it's broken the same way as the others.
<rbasak> jamespage: what do you think about changing pull-lp-source to pull from -proposed instead?
<rbasak> AIUI, the point is to get the latest version, so perhaps it should.
<rbasak> (it'd have to fall back though I guess)
<jamespage> rbasak, might be a good idea actually - would stop some of the confusion I have seen
<xnox> cjwatson: so some of the new build-deps for automake's testsuite are in universe. I've dropped those build-deps, and instead added autopkgtest to run the fuller testsuite.
<xnox> rbasak: pull-lp-source already pulls from -proposed. there are timing issues, but you can do $ pull-lp-source package saucy-proposed
<xnox> rbasak: or specify version explicitely, if you notice it pull out of date.
<xnox> rbasak: similarly one can use: $dist-updates $dist-proposed $dist-security
<cyphermox> infinity: hey
<jdstrand> tedg: hey-- so I approved the click MIR yesterday. it is my understanding you were blocked on that. it is still in universe-- is there something you need me to do to unblock you?
<jdstrand> tedg: I should also point out that click-apparmor doesn't have a MIR yet, but I plan to create on today. are you blocked on that too?
<tedg> jdstrand, Yeah, I noticed I was talking with fginther on how to move that forward.  My understanding is that I need to dep on it to get it pulled in.
<tedg> jdstrand, No, I just need the click-dev dependency to be allowed.
<tedg> jdstrand, Obviously that'll make things not work, but they'll build, etc.
<stgraber> tedg: yeah, you need to dep on it or have it seeded then it'll show up in component-mismatches and an archive admin will override it to main
<tedg> jdstrand, Thanks for getting to that!
<jdstrand> tedg: ok. I could seed it, but that seems like a a weird seed for desktop since
<tedg> stgraber, Yeah, the issue is how to convince Jenkins it is okay.  It errors on deps that aren't in main.
<jdstrand> tedg: but if it would help you, let me know
<tedg> (which is reasonable, but need to figure out this case)
<ogra_> jdstrand, put it in supported
<jdstrand> ogra_: yeah, that would work
<jdstrand> tedg: shall I just do that ^
<ogra_> though i'm not sure that actually pulls it in, hmm
<jdstrand> I think it does
<tedg> I don't know what that is.  But if you think it would work, I'm happy with it :-)
<ogra_> trying wont hurt i guess
<ogra_> sadly ubuntu-touch seeds still live in universe
<jdstrand> tedg: I'll do the override
<ogra_> else you could just seed it there
<jdstrand> it should be seeded on the touch images
<ogra_> right
<ogra_> but they build from universe atm
<jdstrand> oh I see what you mean
<ogra_> until all PPAs are gone from the build
<jdstrand> tedg: ok, added click and click-dev to the supported seed and adjusted the overrides. let me know if you need any more help
<tedg> jdstrand, Cool, thanks!
 * jdstrand will keep an eye on component mismatches
<infinity> cyphermox: 'sup?
<cyphermox> infinity: ah, I wanted to ask about colord blocking systemd. I noticed you unblocked the test failure for chromium-browser, and the colord failure seems unrelated to systemd, just the same usual reason it fails
<cyphermox> ^ re: transition from proposed to release
<infinity> cyphermox: Had nothing to do with systemd, I foced skipping tests on colord/1.0.1-1ubuntu2
<infinity> cyphermox: The hope was that the next version would fix the broken tests, not that I'd have to keep hinting forever. :P
<cyphermox> right. the next version of colord.
<infinity> cyphermox: Yes, but clearly that didn't happen.  Can someone fix the test? :P
<infinity> RAOF: I'm looking at you.
<cyphermox> infinity: I don't know, perhaps someone could. ;)
<infinity> cyphermox: Anyhow, yes, it looks like the same failure as last version, so I'll bump the hint for now. :/
 * cyphermox grabs the colord branch
<dholbach> mitya57, do you have an idea what can be done about https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/1205797?
<ubottu> Launchpad bug 1205797 in Ubuntu Packaging Guide "Cannot open file `/usr/share/doc-base/ubuntu-packaging-guide-html-single' for reading: No such file or directory." [High,New]
<mitya57> dholbach: looks like a regression from my last commit â will take a look
<dholbach> super, thanks!
 * mitya57 wonders why he didn't receive a notification about that bug
<alkisg> slangasek: hi, we're interested in using samba 4 for LTSP 6, edubuntu 14.04 etc, but currently it's postinst scripts are broken etc, would you have some ETA for when it'll be properly working in Ubuntu?
<rbasak> stokachu: what's the news on mysql?
<stokachu> rbasak: heres what i can do -- re-do the debdiffs with the fix and re-test the installation. but i wont be able to get to until until tonight (EST)
<rbasak> stokachu: OK no problem. I can look at it again on Monday.
<stokachu> rbasak: perfect! ill have it ready for you by then
<rbasak> Thank you!
<stokachu> rbasak: will you be able to do the upload too?
<rbasak> Sure
<stokachu> rbasak: ok cool ill ping you on monday then :)
<slangasek> alkisg: I'm not working on samba4 in Ubuntu (or hardly much in Debian), no
<bdmurray> seb128: I'm looking into an issue with libgksu and sudo-mode being set to false on a default install of raring.  It looks to me like the alternative is set correctly but running gconftool-2 -g /apps/gksu/sudo-mode I see false
<bdmurray> seb128: how might I find out more about how the gconf key was set?
<alkisg> slangasek: sorry, ogra_ pointed you to me, thanks :)
<ogra_> slangasek, oh, did you give up on it ?
<slangasek> ogra_: "give up"?
<ogra_> werent you the samba debian maintainer ?
<slangasek> I'm still a comaintainer
<ogra_> ah
<slangasek> but I haven't been involved in the samba4 packages, and I don't know anything about their status in Ubuntu
<seb128> bdmurray, no real way to see what set the value, same as trying to figure what created a file...
<bdmurray> seb128: do you have any ideas how I might dig into it further?
 * mitya57 giggles at a branch named "tyops" in the sponsoring queue
<seb128> bdmurray, no, sorry, I've not looked at gksu in years, I though we stopped using it a year ago
<bdmurray> gdebi seems to still use it
<jbicha> alkisg: Debian experimental now has the "samba" package providing samba4 http://packages.qa.debian.org/samba
<alkisg> 4.0.6, thank you jbicha - and also thanks for the gnome flashback work ;)
<jbicha> so I'm guessing samba as samba4 is doable for 14.04
<xnox> mitya57: i call that informative branch naming
<xnox> =))))
<xnox> mitya57: was the qt / icons fix properly re-fixed in saucy?
<xnox> mitya57: and is now safe for SRU once again?
<mitya57> xnox: I thought you fixed it in saucy :)
<xnox> mitya57: correct!
<xnox> mitya57: and it's the same one for sru or different?
 * xnox looks like a fool now!
<mitya57> it's functionally identical (Â± some comments & whitespace)
<xnox> ack.
<xnox> mitya57: will into it later.
<mitya57> great, thanks!
<doko_>  * New upstream release
<doko_>      - Ghostscript 9.08rc1.
<doko_>      - We are using the system's liblcms2 and libopenjpeg now.
<doko_> tkamppeter, seb128: openjpeg not in main. can you convince me that it needs to be there?
<doko_> please by email
<tkamppeter> doko, see your e-mail.
<crankharder> sorry if offtopic.. looking for an upstart config that can manage a process that is expected to have its PPID change.  not fork, not daemonize... it'll actually spawn a replacement process.
<infinity> crankharder: That would be different from forking how?
<xnox> crankharder: can you strace that process? using establishing pid count recipe from upstart cookbook
<sarnold> crankharder: so, say, over a few weeks, it'll cycle pids through the entire pid space?
<crankharder> infinity: it forks itself and then kills the original... but that's expected, and i dont want upstart to start a new process
<infinity> crankharder: That's the definition of daemonizing.
<crankharder> except this happens repeatedly when it receives USR2
<infinity> Oh.
<infinity> Ew. :)
<crankharder> :)
<infinity> I'm not convinced any sane process tracking system is prepared to deal with that scenario.
<infinity> How did one do it in the sysvinit world?  Does it keep updating a pidfile with its current mystery PID?
<crankharder> it maintains its own PID file
<infinity> Hah.  Jinx.
<crankharder> haven't seen a config for upstart to specify a pid file though
<sarnold> it almost seems like a task designed solely to run from systemd.
<infinity> sarnold: Or sysvinit, to be fair.
<crankharder> ya'll lost me there ;)
<sarnold> infinity: the pid file does help sysvinit a lot, yes..
<infinity> crankharder: Anyhow, I'd say the answer right now is "upstart can't do that", and you want a legacy sysvinit script in /etc/init.d instead of an upstart job.
<crankharder> yea, i have one of those, but sysvinit won't restart it if it dies completely
<crankharder> upstart in theory could do that
<infinity> Sure.  If upstart could even remotely sort out how to track it.
<crankharder> I was thinking of a wrapper bash script that would just loop and check the pid file and die if the pid in the pid didn't exist
<infinity> We've discussed allowing "expect fork" to take an argument to specify number of forks, but "expect fork infinite" would never seem like a good idea.
<crankharder> hah
<crankharder> so, nginx works this way - kinda a big one, so hopefully someone else is thinking about this
<crankharder> i'm not trying to solve for that though
<infinity> nginx doesn't have a control process like... Everyone else who uses this sort of worker model?
<infinity> (apache, spamassassin, etc)
<crankharder> i dunno, you tell me
<crankharder> https://gist.github.com/crankharder/93a68a060329d8446ede
 * TheLordOfTime heard nginx mentioned
<crankharder> ...and that's supposed to be a transparent restart
<infinity> Looks like a master process there to me.
<crankharder> yea, but the pid changed?
<infinity> Yes, because it was restarted...
<TheLordOfTime> what infinity said, when nginx restarts the master process PID changed
<crankharder> okay, fair, nvm
<infinity> crankharder: You could file a wishlist bug for this sort of bizarre tracking.  Something like "expect pidfile /var/run/daemon.pid" could put an inotify watch on the pidfile and force it to update its ptrace when the pidfile changes.
<infinity> crankharder: Seems like it would be a bit fragile to get right, but theoretically doable.
<infinity> (Or rewrite the daemon in question to have a control process :P)
<crankharder> think i'm gonna try to hacktogether some bashfu control process and have upstart monitor that... and see where that gets me
#ubuntu-devel 2013-08-10
<goddard> do you guys think it is a good idea when creating an open source project to say you cannot use this on OSX or Windows?
<Ampelbein> goddard: That goes against everything open source stands for in my opinion.
<penguin42> yeh I don't think that quite qualifies as open source
<slangasek> goddard: restrictions on use are incompatible with Open Source, by definition
<penguin42> is it possible to ask for a rebuild of the coccinelle package on saucy - for bug 1210855
<ubottu> bug 1210855 in coccinelle (Ubuntu) "Coccinelle needs rebuild against newer ocaml" [Undecided,New] https://launchpad.net/bugs/1210855
<penguin42> I'm not sure if this is a build-dep dependency or something magical about ocaml
<goddard> it sucks making an open source project but then windows and mac guys just use it
<goddard> and dont give anything to us
<goddard> you if you used a closed source operating system you cannot use open source software
<goddard> that should be like a rule
<penguin42> goddard: Not necessarily
<goddard> otherwise all the free work people do is just benifiting them
<penguin42> goddard: There are a lot of users of things like openoffice on windows/mac and people who contribute changes to it back
<goddard> Linux users have given so much but it is always a hassle to get larger companies to do small amounts of work to give their products to us
<goddard> yet they use a lot of the open source tools and those guys dont care about ethics or morality or community
<penguin42> goddard: Rather offtopic!  But not necessarily
<goddard> It seems like unless that was put into place really all open source is ... is a tool for these larger companies to exploit while you believe your doing something good
<penguin42> goddard: It's like getting people to switch their servers to Linux - if you can get them first to switch their servers it can be good, but to get them to do that you have to make sure it works well for their windows clients
<goddard> penguin42: so far that method hasn't served us well
<goddard> has it?
<penguin42> goddard: Or the one I've personally had the experience of is a company with mostly Linux users but where the guys in the suit and the finance guys use Windows, so you have to cater for them
<goddard> Why do we have to cater to them?
<goddard> makes no sense
<goddard> I think now is the perfect time for us to diverge away from helping them at all
<penguin42> goddard: Because it's easier to get Linux systems in if the few WIndows users don't actually realise you're using something else in the back
<goddard> at least that way we seem competitive which is what businesses want to see
<goddard> we dont want to be in the back we want to be in the front
<penguin42> goddard: Right but read what I said!
<penguin42> goddard: In a situation where most users are Linux users if you also have to support a few Windows users, unless you can do that then you end up with Linux being pushed out
<goddard> maybe that was true in the past
<goddard> but not any more
<penguin42> it might be easier now with a lot of web based stuff
<goddard> linux only sucks in the graphics deparment i think nowadays
<penguin42> goddard: But I know lots and lots of companies where devs can use Linux or Macs or whatever - but they're required to have a Windows VM to run Outlook; so they're still stuck with Windows!
<goddard> hopefully GPU manufactuers can fix that with steam
<penguin42> anyway, we're very offtopic and will get flame-grilled if we carry on
<goddard> penguin42: outlook is going to the "cloud" so they might shot themselves in the foot
<goddard> haha
<goddard> alright but i wanted to talk about this with actual developers
#ubuntu-devel 2013-08-11
<rkalff> Can someone explain to me how you would normally create a patch for a package?
<rkalff> I branched a ppa with bzr branch ubuntu:somepackage
<rkalff> And tried to create a patch with edit-patch as in de ubuntu packaging manual
<rkalff> But that doesn't work, saying things like "no series file found"
<JViz> i made a pcap.pc file for libpcap, is there somewhere I can submit it?
<sergiusens> cjwatson: hey, if you are around, can you tell me for whom is the Path entry intended in the desktop click hook?
<JViz> er, libpcap 1.1.1
<jtaylor> JViz: the best place is the libpcap developers
<fossterer> hi ! I'm trying to understand what goes into bug fixing.. got a simple bug which was recently resolved..
<Ampelbein> fossterer: What do you mean? You want to know how to fix a bug?
<fossterer> Ampelbein: Heyy I saw the debdiff.. and I would like to see the changes it brings
<fossterer> I've not updated my system so as to apply that myself
<fossterer> and check
<Ampelbein> fossterer: You can open a debdiff in any editor, it's basically just a patch file.
<fossterer> ok.. thhen
<fossterer> ?
<Ampelbein> fossterer: Then you can see the changes made. This topic is more appropriate for #ubuntu-packaging or #ubuntu-motu though.
<fossterer> Ampelbein: Please don't get me wrong... My aim is to not accept the updates pushed to my system; rather implement those code changes (10 lines) myself and see it working
<Ampelbein> fossterer: You can see in the debdiff what was changed, apply those changes to the source and build the software.
<Ampelbein> fossterer: http://developer.ubuntu.com/packaging/html/traditional-packaging.html#applying-a-debdiff
<fossterer> Ampelbein: Cool.. thanks. The bug was related to 'gnome-screenshot'.. So should I download its source first?
<fossterer> and apply this debdiff to see the changes?
<Ampelbein> fossterer: Yes. But as I said earlier, that topic is borderline OT here and should be better discussed in #ubuntu-packaging.
<fossterer> Ampelbein: I'm sorry for that.. Is this channel about any core development?
<fossterer> In that case could you suggest someone to ask in #ubuntu-packaging?
<fossterer> *somene for me to approach
<Ampelbein> fossterer: Just ask your questions in the channel. Someone will answer.
<Ampelbein> !packaging | fossterer
<ubottu> fossterer: The packaging guide is at http://developer.ubuntu.com/packaging/html/  - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports and !sponsoring
<Ampelbein> fossterer: But read that first.
<fossterer> Ampelbein: thank you
<cjwatson> sergiusens: sort of required to make the click package work at all; since click packages don't have a fixed unpack path, the app inside them needs to be executed with its current working directory set to the unpack directory so that it knows where to find its own assets; and of course qtubuntu needs to know where to execute it from too
<sergiusens> cjwatson: ok, so something is missing, I had to add the full path to the qml (for qmlscene) in the desktop file http://paste.ubuntu.com/5974964/
<cjwatson> sergiusens: You shouldn't have had to hardcode the path in Icon either
<cjwatson> sergiusens: bug 1204596
<ubottu> bug 1204596 in qtubuntu (Ubuntu) "Unity 8 does not honor Path= in desktop files" [Undecided,In progress] https://launchpad.net/bugs/1204596
<sergiusens> cjwatson: let me look at that bug. thanks!
<sergiusens> cjwatson: I didn't hardcode the Icon path btw....
<cjwatson> sergiusens: Oh, that's right, click desktophook currently does that
<cjwatson> Never mind that comment then
<sergiusens> yup, I'm looking at it now, was going to paste the snippet
<sergiusens> let me see if I can fix the qtubuntu bug
<cjwatson> The bug already has a branch attached
<sergiusens> ah, yeah, I'll review/test
<lifeless> so why does ubuntu installer create subvolumes for /home ?
#ubuntu-devel 2014-08-04
<deitarion> Does anyone know where I could get some debugging symbols for the `notification-daemon` package on 14.04? There's no `-dbg` package for it and it's crashing when it tries to hide a notification.
<deitarion> Also, if you know that it's a thorny thing to debug, please warn me  so I can just give up without wasting my time and spend a few hours cobbling together a basic notification daemon with "missed notifications" log using PyGTK. I have almost no experience with C.
<Laney> deitarion: https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
<deitarion> Laney: Thanks. I'm getting a bit dozy, but that looks like what I want so I'll check it out tomorrow morning.
<Laney> 'kay, good luck
<pitti> Good morning
<pitti> Noskcaj, slangasek: indicator-power needs porting too, for the signals; it builds and starts, but never updates the UI
<pitti> Noskcaj: how do you mean, progress with python-dbusmock upower? that was fixed weeks ago for upower 0.99
<Noskcaj> pitti, i hadn't realised you fixed it. could you close the "upstream" bug?
<pitti> Noskcaj: it's fixed in bug 1330037, is there another one?
<ubottu> bug 1330037 in xfce4-settings (Ubuntu) "upower 0.99 transition" [Undecided,In progress] https://launchpad.net/bugs/1330037
<pitti> Noskcaj: ah, I seee it, will do
<Noskcaj> bug 1324791
<ubottu> bug 1324791 in python-dbusmock "FTBFS with upower 0.99.0" [Undecided,New] https://launchpad.net/bugs/1324791
<dholbach> good morning
<Tribaal> hi dholbach
<Tribaal> :)
<dholbach> hi Tribaal
<dholbach> Noskcaj, did you get anywhere with python-wsme?
<sarnold> infinity,stgraber, could you guys add a mention to the release announcements for the point releases with HWE stacks that those stacks will EOL before the rest of the software? A friend of mine is very frustrated that his 12.04.x HWE stack isn't as LTS as the rest of the system, and the trusty HWE stack breaks the precise virtualbox dkms packages
<sarnold> infinity,stgraber, it'd be nice if the annoucements were clear about just how long the HWE stacks will live on to help reduce the surprise and confusion
<infinity> sarnold: I've never done a point release with an HWE stack, but in the future, sure.
<infinity> cjwatson: ^
<infinity> At least, I don't think I have.
<sarnold> infinity: oh, sorry :) I assumed since you've been kind enough to reap our releases that you'd sometimes announce them to the world, too :) sorry
<infinity> sarnold: I tend to do final releases.  I also just did 14.04.1, but that didn't have an HWE stack.
<infinity> sarnold: I agree that the initial communication around HWE stacks was poor, it's been a work in progress.
<infinity> sarnold: I still (personally) think it's poor form to give people a "14.04.2 LTS" CD with fine print that says "except half of this isn't supported beyond 16.04".
<infinity> And I'm not sure how best to address that.
<sarnold> infinity: yeah, I know the feeling. I still don't know how to best get my pal up and running again with his cruddy virtualbox problem :( if it were in my hands I'd be a bit more cavalier about trying things to fix it, but I can understand his reluctance to try a wholescale downgrade to original precise stack.
<infinity> sarnold: Are there bugs about this virtualbox issue?  Can we fix it?
<infinity> sarnold: I know some DKMS stuff is best-effort, but vbox has enough users that I assume someone cares.
<zyga> offtopic: can anyone on 14.10 run cheese and tell me if their webcams work?
<zyga> I get a still frame and then a ton of gstreamer errors
<sarnold> infinity: so please count that as encouragement towards finding a nice solution; maintaining a dozen simultaneous HWE stacks doesn't sound like a good use of resources but hopefully we can find something in the middle that makes it less surprising
<sarnold> infinity: there's a pile of bug reports kinda like this one: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1343305
<ubottu> Ubuntu bug 1292118 in virtualbox (Ubuntu) "duplicate for #1343305 virtualbox-dkms 4.1.12-dfsg-2ubuntu0.6: virtualbox kernel module failed to build [error: incompatible types when returning type âkuid_tâ but âRTUIDâ was expected]" [High,Triaged]
<sarnold> infinity: there's at least some overlap or mess here, since it fails in different ways for the different stacks, but the end result is the same, the module isn't updated for the kernels
<Noskcaj> dholbach, Those depends are needed it seems, i'll try and get the MIRs done, but i've got a heap of school work ATM
<dholbach> Noskcaj, hum... it looks like we didn't need them before, right?
<infinity> sarnold: I'd love for the right answer to be to tell people "don't use virtualbox" and, indeed, to stop shipping the stupid dkms module.  But...
<dholbach> Noskcaj, I'm just asking because the package is stuck for now - I just thought it'd be good to finish this before you start working on other stuff
<dholbach> doko pinged me about it too
<sarnold> infinity: heh, yeah, oracle for the loss :/
<sarnold> infinity: thanks :) good night
<darkxst> virtualbox was a mess before oracle!
<directhex> i don't know how much virtualbox sucks due to bad packaging, and how much virtualbox sucks due to bad software. but either way, i disrecommend it to people
<darkxst> directhex, the 3D drivers are just plain rubbish
<directhex> darkxst: are they *capable* of running 32-bit apps in a 64-bit guest os? i know as-packaged that's not possible
<darkxst> directhex, not sure about that, would seem silly if they can't though
<directhex> darkxst: they certainly can't in deb/buntu
<directhex> darkxst: the gl stuff is only in the virtualbox-guest-x11 package, which is not remotely multiarch
<darkxst> directhex, I traited and switched to vmware a couple of years ago
<infinity> directhex: Packaging might make it worse, but the general non-freeness and awfulness of upstream makes it a poor choice even before packaging might hinder you further.
<darkxst> note how a proprietry company has mainline kernel drives and vbox doesnt!
<directhex> despite non-Freeness, vmware is an excellent product & has excellent opengl support in linux guests
<infinity> directhex: The vmware drivers are free, as pointed out above, which is a huge help (and very smart on their part).
<darkxst> directhex, exactly why I have never looked back
<darkxst> infinity, vbox drivers would never be accepted into the kernel in their current state
<infinity> Not that I recommend vmware either, but if forced to choose the lesser of weavils.
<infinity> weevils...
<directhex> i use kvm fine for any jobs that don't require uefi or opengl in the guest os
<infinity> darkxst: Obviously not, but "our software is crap" is never an excuse to not submit upstream, it's an excuse to not improve your software.
<infinity> directhex: EFI on qemu should work now.  So I hear.  I don't use it in such a setup.
<Noskcaj> dholbach, The code uses both of those packages, so i'm assuming it just never got noticed
<darkxst> infinity, that would just result in a linus rant towards oracles way ;)
<dholbach> Noskcaj, probably - I haven't looked that closely yet - maybe it'd make sense to have a chat with the folks who uploaded the package before?
<directhex> infinity: it "works" - ovmf has a few teeny tiny missing features. e.g. it has no persistent storage of uefi variables so after rebooting your VM doesn't know which bootable OSes are installed. it also lacks drivers for most of qemu's storage controllers
<infinity> darkxst: What I meant was that the solution to "too crap to submit" is "make it less crap", not "don't submit".
<slangasek> dholbach: hi, you've cc:ed me on this mail about click frameworks... was this related to my upload for dropping friends?
<slangasek> dholbach: or are you cc:ing me because you think I know something? :/
<darkxst> infinity, except it was crap before, and its still crap now oracle have taken over
<dholbach> slangasek, yeah, I guess, it looked like your update to ubuntu-touch-meta was the last one changing the frameworks - one ot the questions which came up is why we have -qml-dev3 and not -dev3
<infinity> darkxst: Preaching to the choir.
<doko> xnox, can you have a look at the lvm2 merge? pitti doesn't want to do it, and you are the last uploader then
<Noskcaj> dholbach, will do
<pitti> doko: well, this should be done by someone who actually uses lvm2
<pitti> err, xnox
<dholbach> thanks Noskcaj
<pitti> I mean, I can look into it, but I have no real-world test setup
<xnox> pitti: doko: yeah, it's on my list to do this week.
<slangasek> dholbach: ok; so the only framework that changed was the qml one because dropping friends was a qml-only API change, TTBOMK
<slangasek> dholbach: and IIRC
<slangasek> dholbach: and there's no reason to rev the -dev numbers in lockstep, AFAIK
<slangasek> dholbach: but I think jdstrand is the expert on this
<dholbach> slangasek, ok - thanks a bunch!
<dholbach> popey, ^ did you see what Steve said above?
<dholbach> popey, I'm wondering if the general process for an app developer could be easier, maybe to the point, where they just select the framework from a drop-down box in the SDK?
<LocutusOfBorg1> seb128, I'm also here if you want
<LocutusOfBorg1> for bug 1349385
<ubottu> bug 1349385 in libidl (Ubuntu) "please merge libidl from debian" [Undecided,New] https://launchpad.net/bugs/1349385
<pitti> xnox: oh, thanks for the upstart-core split! I'm making good progress on bug 1351306
<ubottu> bug 1351306 in sysvinit (Ubuntu) "Cannot uninstall upstart and install systemd-sysv" [Undecided,In progress] https://launchpad.net/bugs/1351306
<pitti> xnox: although I suppose slangasek might not get to reviewing sysvinit this week at the sprint
<xnox> pitti: he did agree to a split with my on a 1-on-1 on friday.
<xnox> pitti: he said, we do need "upstart" & "initctl" (stop, start, restart, status...) to e.g. run user session in a separate package that does not conflict with systmed-*
<pitti> xnox: although I wonder whether splitting out upstart-sysv might have been easier
<pitti> xnox: as upstart has a gazillion conffiles, migrating them will be a pain
<pitti> (argh upstart jobs being conffiles)
<xnox> pitti: which i have now done. But i've also split out the telinit, to do clean shutdown with systemd-sysv installed.
<xnox> pitti: i've pondered about that. Ultimately, while upstart-sysv is easier split, it's a painful upgrade.
<pitti> xnox: oh right, got confused; "upstart" would continue to have the actual jobs, upstart-core just the binaries for session init; gotcha
<xnox> pitti: let me check that =)
<xnox> pitti: yes, "upstart" should have the system jobs.
<saiarcot895> Ubuntu armhf only supports OpenGL ES and not OpenGL, right?
<xnox> pitti: well, some conffiles are moved. E.g. etc/X11/Xsession.d and etc/upstart-xsessions will be part of core now.
<ogra_> saiarcot895, while no precisely right in that formulation ... yes ...
<ogra_> (the drivers that exist for armhf usually only support GLES ... not ubuntu specific )
<pitti> xnox: reviewed; thanks for the first iteration!
<xnox> pitti: cool. let me push update that moves the system etc/init/ back to upstart package though.
 * pitti toddles off for lunch
<jdstrand> dholbach: I too agree there is no reason to rev the numbers in lockstep, however, there is probably a reason to rev the main one to whatever the highest one is
<jdstrand> dholbach: ie, right now there is ubuntu-sdk-14.10-qml-dev3 but there is only ubuntu-sdk-14.10-dev2
<dholbach> jdstrand, maybe we could document this somewhere on the wiki and cross-reference it in the code
<jdstrand> dholbach: that is probably a lool question ^
<dholbach> just so we always keep everyting up to date everywhere - even if that's now two separate parts of the discussion
 * jdstrand wasn't part of the discussions for adding -dev3 this time
<jdstrand> dholbach: which code?
<dholbach> jdstrand, for now probably just somewhere in ubuntu-touch-meta and click-reviewers-tools
<dholbach> we could refer to some wiki page, which explains how to do click framework changes and what to bear in mind, ie where else to update it :)
<xnox> pitti: would you be able to write a systemd unit for ubiquity?
<pitti> xnox: yes, I can certainly look into that
<lool> jdstrand: Yes, I agree with your idea that the main one ought to be bumped too
<lool> I guess this could go to the Click frameworks wiki page
<pitti> xnox: looks like most of debian/ubiquity.ubiquity.upstart shoudl be refactored into a script; the startup condition is quite straightforward
<xnox> pitti: sure. startup conditions are quite straightforward, but it should block starting lightdm until the job completes.
<xnox> cause it's a task in ubuntu.
<xnox> (well block any/all display managers and reaching multi user target)
<pitti> xnox: yes, that can be done with Before=
<pitti> xnox: in fact, I just did something similar for friendly-recovery
<saiarcot895> If I'm doing a merge for a (existing) bug, does the bug need to have ubuntu-sponsors subscribed as well?
<rbasak> saiarcot895: if you're doing a merge proposal on Launchpad (UDD), then no, since that MP causes it to appear in the sponsorship queue.
<saiarcot895> rbasak: ok, thought so. Thank you.
<rbasak> saiarcot895: maybe best to check on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html. If your work doesn't show up on there (update timestamp at bottom of table), then certainly subscribe ~ubuntu-sponsors to something.
<saiarcot895> rbasak: yup, appeared there just now.
<rbasak> saiarcot895: great! Though, that MP seems to include multiple unresolved merge conflicts. You probably want to resolve those.
<rbasak> saiarcot895: I'm also a little dubious about fixing something if it still FTBFS. I appreciate your efforts in working this all out, but what's the point in uploading something that will still fail?
<rbasak> saiarcot895: also, there some special special sauce to do with GL/GLES on armhf, and I don't recall the details. Maybe ogra_ can confirm the build dep changes for you?
<rbasak> (ogra_: https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openscenegraph/armhf-support/+merge/229440)
<saiarcot895> rbasak: ah, my bad. I think I checked out the trusty version instead of the utopic version.
<saiarcot895> rbasak: The hope is that when freeglut 3.0 is released, everything else (well, at last this package) will be ready to go, and that the source of the problem shifts away from openscenegraph
<rbasak> saiarcot895: sure, I get that, and I appreciate your work on this.
<rbasak> saiarcot895: I just wonder what the benefit is in uploading these changes now, rather than maintaining a branch until everything is in place, and *then* uploading.
<rbasak> I think this question might have been raised before a year or two back, probably in some other package. I don't remember what the conclusion was.
<stgraber> sarnold: we'll need to keep that in mind for 14.04.2, 12.04.5 which we are about to release won't have that problem since it'll have the trusty kernel and so will be supported until precise EOL
<pitti> bonjour stgraber
<pitti> jdstrand: just to avoid misunderstanding -- bug 1341083 is in your pipeline now, and you'd like to review before I upload, right?
<ubottu> bug 1341083 in ufw (Ubuntu) "ufw needs systemd unit or init.d script" [Medium,In progress] https://launchpad.net/bugs/1341083
<pitti> stgraber: anything else you need for the lxc systemd patches?
<jdstrand> pitti: it is
<stgraber> pitti: time :)
<pitti> stgraber: right, that :) I meant further testing, sign-offs, questions, etc.
<pitti> stgraber: IOW, anything on my plate, or anything I can help with
<stgraber> nope, I think I just need time to look at them and apply them :)
<pitti> stgraber: ack, thanks!
<saiarcot895> New merge proposal is at https://code.launchpad.net/~saiarcot895/ubuntu/utopic/openscenegraph/armhf-support/+merge/229453
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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: barry
<xnox> pitti: more systemd code review requests =)))) https://code.launchpad.net/~xnox/upstart/exec-systemctl/+merge/229467
<xnox> i think you will like that one ;-)
<pitti> xnox: heh, nice one!
<LocutusOfBorg1> thanks barry :)
<barry> LocutusOfBorg1: yw! :)
<LocutusOfBorg1> barry, do you think you can sponsor also busybox?
<LocutusOfBorg1> I can send you the debdiff
<barry> LocutusOfBorg1: can you file a bug and attach the debdiff?  i'll try to get to it
<LocutusOfBorg1> here we are https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1352413
<ubottu> Ubuntu bug 1352413 in busybox (Ubuntu) "please merge busybox from debian" [Undecided,New]
<cjwatson> rolling builder downtime for launchpad-buildd upgrades
<shadeslayer> pitti: btw can the nvidia-*-updates package get better one line descriptions?
<shadeslayer> that differentiate them from the regular nvidia-* packages
<shadeslayer> same for fglrx
<shadeslayer> pitti: because the UI shows the same string to the user, and that's confusing
<barry> LocutusOfBorg1: cool
<kentb> Hi.  I've got a fix for Trusty that needs to be reviewed, please.  Utopic was fixed automatically, but, an SRU for Trusty needs to be pushed out as well.  A debdiff for Trusty is here:   https://bugs.launchpad.net/ubuntu/+source/ledmon/+bug/1349920/comments/6    Thanks in advance.
<ubottu> Ubuntu bug 1349920 in The Dell-poweredge project "ledmon does not work in Ubuntu 14.04" [High,In progress]
<pitti> shadeslayer: yes, I suppose so
<Riddell> jdstrand: security love needed on an upload on bug 1352421
<ubottu> bug 1352421 in krfb (Ubuntu Trusty) "possible denial of service or code execution via integer overflow" [Undecided,New] https://launchpad.net/bugs/1352421
<Riddell> debdiff is attached
<jdstrand> Riddell: ack, mdeslaur is on community this week, so he can look at it/delegate it. thanks!
 * jdstrand subcribes ubuntu-security-sponsors
<mdeslaur> Riddell: thanks, I'll sponsor it this afternoon
<sarnold> stgraber: thank you (re lts hwe early eols) -- I eventually did find a nice wiki documting it all, but someone who just reads the Obvious News might easily overlook it... (I learned about it on irc, forexample..)
<doko> dobey, ubuntu-sso-client ping
<barry> LocutusOfBorg1: don't think i'm going to get to busybox unfortunately.  maybe the next pp
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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:
<sarnold> Trevinho,mdeslaur: 1351616 -- multitouch / gestures / etc. killing X enough to unlock a locked session
<mdeslaur> sarnold: looks like a dupe of 1121379
<sarnold> mdeslaur: could be. but because that got duped to an N7 xorg bug I'm afraid the whole thing has been forgotten.
<mdeslaur> sarnold: I'd undupe 1121379, and dupe the new one to it
<hallyn> question: cgmanager-utils currently provides only the script 'cgm'.  That's been turned into a compiled program and will moe to the cgmangaer package;  should cgmanager Breaks/Replaces cgmanager-utils, or Conflicts/Replace it, or just Replace it?
<sarnold> mdeslaur: hrm, 1121379 may be about that specific hardware device..
<mdeslaur> sarnold: same backtrace
 * mdeslaur shrugs
<sarnold> mdeslaur: the Xorg error may be the same but if the core 'fix' is to a kernel driver the root cause of the bug might be elsewhere
<mdeslaur> sarnold: well, I have no idea, just mark it as confirmed, and leave it rot
<sarnold> mdeslaur: hehe
<mdeslaur> sarnold: I've changed to to xorg, since that is where the crash is
<sarnold> mdeslaur: thanks
<hallyn> answering my own questions, looks like provides/conflicts/replaces works best
<stgraber> pitti: your changes are now upstream, I'll wait a couple of days for things to settle down before tagging alpha2
<hallyn> slangasek: hi, so moving cgm from cgmanager-utils to cgmanager does cause cgmanger to have new libdbus-1-dev and libnih-dbus-dev dependencies.  Any objections to that?
<barry> bdmurray, slangasek do you still need me to spend time on LP: #1351018?  looks like it's since been marked incomplete
<ubottu> Launchpad bug 1351018 in gdb (Ubuntu) "issues debugging program threads on 12.04" [Undecided,Incomplete] https://launchpad.net/bugs/1351018
<hallyn> slangasek: in case not i've pushed cgmanager 0.30-1 to mentors
<bdmurray> barry: no, not right now. I've a got a handle of sorts on it.
<bdmurray> barry: thanks for checking
<barry> bdmurray: sure.  sorry i ran out of time on friday, but glad it's not blocking you now
<bdmurray> barry: well there is still some issue but it doesn't look like its gdb but apport or the error tracker retracers somehow
<barry> bdmurray: ack.  ping me if needed
<jdstrand> slangasek: hey, if I use 'schroot -c click-ubuntu-sdk-14.10-armhf ...' on my amd64 and want to build armhf binaries with g++ using that schroot, do I have to specify some special flags to g++?
<xnox> jdstrand: well, g++ is native compiler, by default dpkg-architecture -aarmhf variables are pre-exported, such that ./debian/rules build will be cross-compiling.
<jdstrand> xnox: right, but I am not building a package, I just want to compile a .cpp file for armhf using that click armhf chroot
<xnox> jdstrand: arm-linux-gnueabihf-g++ is the compiler you want, which is just $(DEB_HOST_MULTIARCH)-g++ i believe.
<jdstrand> ah
<jdstrand> nice
<jdstrand> let me try that
<xnox> jdstrand: or use cmake =) which will be cross-compiling by default again... due to all the env vars we export.
<xnox> jdstrand: generally $(DEB_HOST_MULTIARCH)-g++ should work for native compilations as well, since native toolchain provides those symlinks as well.
<jdstrand> right, this is literally a one off compile
<jdstrand> I have a .cpp file. I want a binary
<jdstrand> :)
<slangasek> hallyn: why would cgmanager depending on dbus+nih be a problem?  Those are pretty core dependencies on most systems already, certainly so on anything booting with upstart
<hallyn> slangasek: yeah not sure what i was thinking :)
<slangasek> ok :)
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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: TheMuso
<ScottK> pitti: Do you have suggestions on trouble shooting https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-release-upgrader/lastBuild/ARCH=amd64,label=adt/console ?
<ScottK> It seems pretty unrelated to pykde4, which is being held back by the failure.
#ubuntu-devel 2014-08-05
<hyperair> did ssh-agent just go missing?
<hyperair> s/ssh-agent/seahorse-agent
<TheMuso> hyperair: Seems to be working for GPG and ssh here for me.
<hyperair> whoops, looks like it's gnome-keyring-daemon, not seahorse-agent
 * hyperair forgot the command required to reinitialize it after it crashes
<hyperair> gnome-keyring-start, and then stuff the environment variables into compiz via gdb
<hyperair> :D
<hyperair> er gnome-keyring-daemon --start
<TheMuso> 6@pilot out
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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:
<obiwandk> hello
<pitti> Good morning
<pitti> stgraber: \o/ thanks for reviewing
<Unit193> Howdy.
<pitti> ScottK: I don't know this very well, but it's plausible that its test needs to be updated to use a current release
<tjaalton> shouldn't normal upgrades remove ubuntuone from trusty?
<pitti> tjaalton: ubuntu-release-upgrader ought to, in the cleanup stage
<tjaalton> guess it doesn't work when upgrading trusty->trusty
<LocutusOfBorg1> no problem barry :)
<tvoss> doko_, good morning :)
<tvoss> doko_, I just tried to install C++ pretty printers in gdb without luck. Do we have some instructions online how to enable them?
<dholbach> good morning
<doko> tvoss, just what is available in the standard docs
<tvoss> doko, ack
<doko> tvoss, have a look at libstdc++6, a pretty printer just has to be found in some location with a specific name
<tvoss> doko, ack
<doko> pitti, jibel: I demoted libcursesada to -proposed, however the failing autopkg test still seems to block ncurses. same for libaunit. any idea how to proceed?
<pitti> doko: ah, still uninstallable due to missing gnat-4.6 -> 4.9 transitino?
<doko> pitti, well, gnat wants to migrate too ...
<pitti> so the release team could certainly set an override for ncurses to migrate
<pitti> as it's clearly the "ada" part, not the "ncurses" one which is the problem :)
<pitti> doko: oh, a solution is in sight: https://ftp-master.debian.org/new/libncursesada_5.9.20140726-1.html
<pitti> seems gnat itself will still take a while: https://release.debian.org/migration/testing.pl?package=gnat
<pitti> (but we don't really care about ada, do we?)
<pitti> ScottK: I had a look at release-upgrader's tests, but they don't mention "quantal" explicitly; I suppose they download some meta-data from archive.u.c., but I'm not familiar with that; I'm afraid we need to wait for mvo for that, and in the meantime you could add a release team override?
 * pitti mails him in the meantime
<cjwatson> psivaa: Is there any way I can get hold of /var/log/partman for https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1352252 ?  It's the best log to have for this, but unfortunately it doesn't seem to be attached as an artifact to the job
<ubottu> Ubuntu bug 1352252 in parted (Ubuntu) "Exception during partitioning whilst utopic server installations" [High,Confirmed]
<cjwatson> psivaa: I've tried reproducing this locally and so far have been unable to, even with something that's as close as I can manage to the same disk size, so I need the partman log in order to have byte-identical configuration
<psivaa> cjwatson: let me take a look, if i can somehow find the log on a manual install
<Unit193> cjwatson: Hellos, I would guess now would be a bad time to remind about tasksel?
<cjwatson> Unit193: possibly OK, will have a look shortly
<Unit193> Great, thanks!
<cjwatson> psivaa: Ideally we'd change the utah config to attach that file on all future installations, both d-i and ubiquity
<cjwatson> psivaa: It never hurts to have it
<psivaa> cjwatson: yes, let me see if i can do this. probably this week.
<psivaa> cjwatson: http://pastebin.ubuntu.com/7959356/ is the partman.log
<psivaa> cjwatson: i'll attach to the bug too
<cjwatson> psivaa: Excellent, thanks
<psivaa> yw :)
<doko> jamespage, java component mismatch ping ...
<LocutusOfBorg1> sil2100, I changed the lucene++ debian/* license to be LGPL-2+ instead of LGPL-3+
<LocutusOfBorg1> it should fix the lintian warning
<sil2100> LocutusOfBorg1: ok, LGPL-3+ was anyway only a habit, I'm fine with 2 - thanks!
<LocutusOfBorg1> I don't know, it fixes this issue
<LocutusOfBorg1>  I unused-license-paragraph-in-dep5-copyright
<LocutusOfBorg1>     lgpl-2+ (paragraph at line 89)
<LocutusOfBorg1> anyway they say it is good for debian files to have the same license as the upstream sources
<LocutusOfBorg1> to make it easier to send patches
<LocutusOfBorg1> anyway who cares? lintian is happy and if it is fine with you I'm happy too ;D
<pitti> dpm: FYI, fresh langpacks (touch and desktop) are in utopic now
<dpm> \o/
<jibel> could anyone have a look at bug 1351262 it's blocking 12.04.5
<ubottu> bug 1351262 in xorg-lts-transitional (Ubuntu) "precise alternate installations fail with unmet deps due to the conflict ' xserver-xorg-lts-trusty : Conflicts: libgl1-mesa-dri (>= 0~)'" [Critical,Confirmed] https://launchpad.net/bugs/1351262
<doko> tvoss, which team to use for phablet issues?
<doko> tvoss, ev, slangasek: looks like the CI train is bypassing our normal build rules ... see LP: #1349834
<ubottu> Launchpad bug 1349834 in libjsoncpp (Ubuntu) "[MIR] flask-script and libjsoncpp (b-d's for net-cpp)" [Critical,Incomplete] https://launchpad.net/bugs/1349834
<tvoss> doko, still on my list
<slangasek> doko: what rules are you referring to?
<slangasek> ah, component-mismatches
<slangasek> there's no way to enforce that in ppas, AFAIK
<cjwatson> Right, not fixable there, we just have to clean up afterwards as necessary and try to be vigilant
<doko> barry, https://launchpad.net/ubuntu/+source/python-keyring/4.0-1  can you have a look at a MIR, or removal of the new build deps?
<doko> pitti, jibel: the status of the autopkg tests for libgcrypt11 seem to be out of date
<jibel> doko, looking
<jibel> doko, results will be synced on next run of britney
<barry> doko: will look
<michagogo> Hm, am I misunderstanding https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools?
<michagogo> pitti sponsored the package for bug 1314616, but it's not listed on https://launchpad.net/ubuntu/precise/+queue?queue_state=1 nor  http://people.canonical.com/~ubuntu-archive/pending-sru
<ubottu> bug 1314616 in bitcoin (Ubuntu Precise) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,In progress] https://launchpad.net/bugs/1314616
<pitti> michagogo: it's in NEW, due to a Launchpad bug
<pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<michagogo> What does that mean?
<pitti> michagogo: mostly just that the SRU team needs to check there instead of UNAPPROVED (state=1)
<michagogo> Ah. (do they know that?)
<pitti> michagogo: I was pinging #ubuntu-release when I sponsored it, and wgrant looked into why it got into the wrong queue, but usually the SRU team wouldn't know
<pitti> I was going to ping around every couple of days
<michagogo> Is there a way to put it in the right place?
<pitti> that's a question for wgrant ^ (but I expect him to be tight asleep right now)
 * michagogo goes to read -release backlog
<pitti> michagogo: not much to worry about for you though
<pitti> bdmurray, RAOF, infinity, ScottK: when you process SRU the next time, please look into precise/NEW for the bitcoin one (not actually NEW, just an LP bug)
<michagogo> pitti: Okay, thanks.
<wgrant> pitti: I'm in NÃ¼rnberg, actually.
<pitti> wgrant: oh, welcome to Bavaria!
<wgrant> michagogo, pitti: Rejecting and reuploading that package which stick it in unapproved. The bug is fixed, but it's not possible to get it from new to unapproved without a fresh upload.
<wgrant> s/which/will/
 * michagogo hopes (and assumes) pitti knows what that means
<pitti> wgrant: ah, fixed? nice; I can do that
<wgrant> pitti: Oh yeah, it was fixed on prod like 6 hours after you reported it, sorry.
<pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
<pitti> and there it goes
<pitti> michagogo: ^
<pitti> wgrant: thanks!
<michagogo> Awesome, thanks pitti and wgrant!
<pitti> bdmurray, RAOF, infinity, ScottK: OK, bitcoin is in unapproved, unping
<doko> Mirv, ok to NMU malaga, fixing #755915?
<pitti> rbasak: oh, no comments on http://www.justgohome.co.uk/blog/2014/08/ubuntu-git-merge-workflow.html?
<Mirv> doko: ok, I've had it highlighted in my personal inbox but haven't got to it
<doko> barry, a lot of packages start building modules for pypy. any opinion about having it in main? currently we just disabled these
<barry> doko: hmm.  haven't thought about it too much, but i like that folks are starting to support pypy better, and i don't like carrying deltas just to manage this distinction.  maybe we should MIR pypy...
<doko> barry, after this week you'll be a MIR expert ;-P
<barry> doko: that was my hope and dream!
<barry> doko: LP: #1352900
<ubottu> Launchpad bug 1352900 in pypy (Ubuntu) "[MIR] pypy" [Undecided,New] https://launchpad.net/bugs/1352900
<ricotz> pitti, hi, please cherry pick https://git.gnome.org/browse/libwnck/commit/?id=063cc9281372815e0bf0a6b2e63f9b07e1769448
<pitti> ricotz: you tell me that 10 seconds after I hit dput..
<pitti> ricotz: but I can do another upload, if you need it for anything in particular
<ricotz> pitti, i just noticed the packaging commits :\
<ricotz> this fixes the reported geometry for gtk csd windows
<pitti> ricotz: sure, doing
<ricotz> pitti, sorry, i was hoping Trevinho would do an actual release ;)
<pitti> ricotz: heh, no problem
<ricotz> pitti, thanks!
 * pitti fights with a svn assert when tagging the recent upload
<pitti> subversion, go away!
<pitti> ricotz: uploaded
<pitti> ricotz: I'll sync tomorrow morning when it got imported
<rbasak> pitti: I don't do blog comments. I get one legitimate comment a year, and many many spam messages. Not worth it IMHO.
<rbasak> pitti: reply to ubuntu-devel maybe?
<pitti> rbasak: that's what I did :)
<rbasak> Oh. Thanks!
 * rbasak looks
<pitti> rbasak: nothing fancy, hence I'd have written it as blog comment, but ML is fine too
<ricotz> pitti, great!
<bdmurray> pitti: is bug 1352591 clear enough?
<ubottu> bug 1352591 in apport (Ubuntu) "apport-retrace does not update libraries in a sandbox" [Undecided,New] https://launchpad.net/bugs/1352591
<pitti> bdmurray: ah yes, it is
<pitti> bdmurray: so this needs to keep track of which version of a package is installed, instead of merely checking for existence of the lib
<pitti> bdmurray: it's on my todo list
<bdmurray> pitti: okay, thanks!
<ScottK> pitti: Thanks.
<xnox> bdmurray: release-upgrader failing autopkgtests, anything obvious to you ? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-release-upgrader/38/ARCH=amd64,label=adt/artifact/results/nose-tests-stdout/*view*/
<xnox> (why is it using quantal?!)
<bdmurray> xnox: I believe quantal to saucy was a supported upgrade path because raring became EoL before Quantal
<xnox> bdmurray: not any more, since both quantal and saucy are EOL now.
<xnox> (it was interimish)
<xnox> and the files are gone from the archive repository and moved to old-releases by now.
<bdmurray> xnox: the issue is with "get_new_dist()" in test_dist_upgrade_fecther_core.py
<pitti> xnox: I mailed mvo about it; I loked into the tests, and they don't hardcode quantal anywhere
<bdmurray> pitti: I found the issue, see my last comment.
<pitti> mdeslaur, infinity: reminder: TB in 50 mins, and you wanted to review the juju policy
<mdeslaur> pitti: yes, thanks for the reminder
<hallyn> cjwatson: for bug 1350435, if you'd like me to apply the patch in the archive until a proper fix hits upstream, let me know
<ubottu> bug 1350435 in launchpad-buildd "tcg.c:1693: tcg fatal error" [High,Triaged] https://launchpad.net/bugs/1350435
<cjwatson> hallyn: well, I think that's up to you and I'm not going to make you apply something over upstream's wishes, but (if it made it to trusty-updates) I understand it would make a pretty massive dent in the failure rate of non-x86 virt PPAs
 * cjwatson follows up to the bug
<Mirv> might some core-dev be able to give a packaging ack to https://ci-train.ubuntu.com/job/landing-015-2-publish/lastSuccessfulBuild/artifact/packaging_changes_messaging-app_0.1+14.10.20140805-0ubuntu1.diff ?
<hallyn> cjwatson: I'm surprised by just how hostile he is toward it, but i think that's just bc he thinks we're whining to get it upstream;  unless he feels that papering over it in the distros will lower priority of a proper fix causing upper linaro management to not ack the work...
<cjwatson> I'm certainly not whining to get it upstream; maybe he's inferring that from the upstream bug task
<hallyn> right
<hallyn> I'm debating whether to drop that part.  Though it does need to also be tracked there.
<hallyn> I don't even know how to mark it in lp if I push the patch - 'fix released' wouldn't be right as it's not going to always work :)
<cjwatson> hallyn: re testing, while LocutusOfBorg1 can't supply an alternate qemu in their PPA, it's certainly possible to do testing of this kind of thing on staging by way of the (new) ~canonical-is-sa/ubuntu/buildd-staging PPA
<hallyn> cjwatson: are you saying a qemu pkg with that patch would go in that ppa, or that that ppa would be using the new qemu as a test?
<cjwatson> which we can ask IS nicely to copy stuff into and rebuild the scalingstack staging image
<cjwatson> the former
<hallyn> cjwatson: and you'd want this ofr utopic, or trusty, ot be useful?
<hallyn> I'm going to go off and merge qemu 2.1-rc1 into utopic right now;  then i'll push something with that patch to a ppa.  (then i need to keep testing precise-to-trusty migration using Alex's patch)
<cjwatson> hallyn: trusty
<cjwatson> scalingstack is all trusty.  p.s. DIE HARDY DIE
<hallyn> :)
<cjwatson> obviously we use per-distroarchseries chroots but qemu-user-static comes from the base
<hallyn> so should i hadn you the pkg source?
<hallyn> s/hadn/hand/
<cjwatson> stick it in a PPA somewhere
<cjwatson> ideally just that patch on top of trusty-updates
<hallyn> will do.  yup, it will.  bbl
<cjwatson> (I'm probably not going to be able to organise it this week though; already maxing out IS's tolerance of my requests, I think)
<hallyn> my kingdom for tiling support in unity!
<hallyn> cjwatson: ok, i'll just hand it to you so you'r enot blocked on me
<hallyn> unless you're saying i should make the request
<LocutusOfBorg1> cjwatson, if you want that I upload qemu in my ppa is fine, I can do it
<LocutusOfBorg1> just ask
<hallyn> cjwatson: actualy i'm doing it on top of trusty-proposed;  shout if that seems irresponsible
<cjwatson> LocutusOfBorg1: no thanks
<cjwatson> won't help anyway
<cjwatson> hallyn: should be ok
<cjwatson> LocutusOfBorg1: (it's going to need to go through hallyn in any event, so he might as well do it ...)
<LocutusOfBorg1> I'm here if needed ;)
<hallyn> trial pkg pushed to ppa:serge-hallyn/qemu-user-thread
<rbasak> pitti, infinity, mdeslaur: would it help if I could get Juju upstream to today's meeting?
<rbasak> Particularly for QA questions
<mdeslaur> rbasak: it certainly wouldn't hurt
<pitti> rbasak: yeah, Curtis' reply was promising, I'm mostly interested in how much it can/will be exercised for SRU testing
<rbasak> pitti, mdeslaur: Curtis is unavailable. I can talk about SRU testing though - I've been working with Curtis on a plan for this.
<pitti> kees, infinity: #ubuntu-meeting-2 for TB, s'il vous plaÃ®t ?
<elopio> Hello
<elopio> can I get a review to the debian packaging changes here?
<elopio> https://code.launchpad.net/~autopilot/autopilot/trunk/+merge/228235
<pitti> elopio: err, I was just looking, but I realize that like 90% of the packaging changes are my fault
<pitti> so that would be some kind of self-approval (not wrong in principle, as core devs do that all the time when uploading), just mentioning :)
<elopio> pitti: :) we can wait a little for somebody else to do the review if you prefer.
<elopio> I won't mind.
<pitti> elopio: MP updated
<elopio> thanks pitti. Mirv: do we need something else?
<pitti> elopio: and FWIW, the earlier that lands, the better
<elopio> agree. I really need it.
<Mirv> elopio: pitti doing the packaging (and review) is quite enough, he could upload it anyhow
<Mirv> but does it need a rebuild now?
<Mirv> no, just commented, great
<elopio> Mirv: nothing has changed, just the approvals.
<Mirv> pitti: elopio: umm. 12h ago slangasek directly uploaded this https://launchpad.net/ubuntu/+source/autopilot/1.5.0+14.10.20140716-0ubuntu2
<Mirv> which is a problem for publishing this new branch
<slangasek> which new branch is this?
<pitti> ah, so I guess slangasek's upload needs to be re-folded into trunk first?
<slangasek> yes it does
<Mirv> slangasek: https://code.launchpad.net/~autopilot/autopilot/trunk/+merge/228235
<Mirv> so update trunk, update merge, rinse and repeat
 * slangasek nods
<Mirv> you can get it done still today easily, but not my today :)
<slangasek> Mirv: I'm in Germany at the moment and am also EOD
<elopio> ack. Thanks Mirv and pitti.
<elopio> I think I'll better leave it to veebers. He will know if we need to do more testing after the merge.
<Mirv> elopio: can you give him a note? the patch to fit in (including changelog entry) is http://launchpadlibrarian.net/181532211/autopilot_1.5.0%2B14.10.20140716-0ubuntu1_1.5.0%2B14.10.20140716-0ubuntu2.diff.gz
<elopio> Mirv: I'll wait for him and ping him as soon as he wakes up.
<Mirv> alright
<elopio> he loves me for getting him new things to do while having breakfast :)
<pitti> elopio: FWIW, slangasek's dep changes are unrelated to anything I've seen in the MP, and merging that upload should be a no-brainer given that it's already in utopic?
<elopio> pitti: you are right. We already got results running with that version.
<elopio> I'll do the merges.
<elopio> I was scared to break the dashboard somehow.
<michagogo> arges: okay, I did as you asked
<elopio> pitti, Mirv: there's another entry on the changelog that is not in trunk
<elopio> 1.5.0+14.10.20140716-0ubuntu1
<pitti> elopio: hm, process fail? https://launchpad.net/ubuntu/+source/autopilot/1.5.0+14.10.20140716-0ubuntu1 was clearly an auto-land CI train thing
<rsalveti> pitti: mterry: getting http://paste.ubuntu.com/7962615/ on latest image (emulator), wonder if that is expected
<elopio> I'm a little confused. I think I need to get the diff from 1.5.0+14.10.20140716-0ubuntu2 into the 1.5 branch, not into trunk.
<elopio> but I'll just wait for veebers. I might make a mess that's harder to fix.
<pitti> elopio: to both, presumably
<pitti> the 1.5 branch == utopic, trunk is the actual trunk
<pitti> (AFAIUI)
<pitti> anyway, way past EOD time, cu tomorrow!
<mterry> rsalveti, I'm not sure if they are expected or not.  I've not noticed such errors before, but maybe they were there
<jtaylor> doko: any hint how to get a --no-as-needed into gccs hidden commandline for a specific gcc library?
<jtaylor> the thing it prints when running gcc -v <file>
<jtaylor> in ubuntu gcc nicely strips away -l{a,t,ub}san due to as-needed
<asomething> Anyone from Canonical IS around  that I can chat with? elmo?
<Unit193> Might be better served in -sysadmin?
<asomething> Oh there's, a #canonical-sysadmin Didn't know, thanks Unit193
<Unit193> Sure thing.
<ScottK> Anyone merging the reportbug security fix?
<rww> Is there a timeline or todo list for enabling 12.04 to 14.04 updates? Getting quite a few support questions about when it'll happen.
<ScottK> "When infinity feels like it" is the answer, AFAIK.
<sarnold> ScottK: mdeslaur said he was going to prepare updates
<ScottK> No reason people have to wait if they don't want to though.
<rww> ScottK: *nod* Last I heard there was a bugfix update pending for update-manager-core, but I think that got sorted. Not sure.
<rww> What's the preferred method for updating now? do-release-upgrade -p ?
<rww> (since trusty is in meta-release-lts-proposed )
 * ScottK does reportbug
<mdeslaur> ScottK: you're doing utopic?
<ScottK> mdeslaur: Yes.  I was going to do a trusty debdiff too.
<ScottK> If you want it, go for it though.
<mdeslaur> ScottK: they're the same, so I'll let you handle trusty
<mdeslaur> I'll do precise
<ScottK> OK.
<ScottK> mdeslaur: Did you put a bug in LP yet?
<mdeslaur> ScottK: not yet, one sec, I'll create one
<ScottK> mdeslaur: Thanks.  Please ping me the # and I'll start uploading.
<ScottK> (and give you a debdiff)
<mdeslaur> ScottK: bug 1353046
<ubottu> bug 1353046 in reportbug (Ubuntu Utopic) "arbitrary code execution in compare_versions" [Undecided,Confirmed] https://launchpad.net/bugs/1353046
<ScottK> Thanks.
<ScottK> mdeslaur: Utopic is uploaded and Trusty debdiff is in the bug.
<mdeslaur> ScottK: thanks!
<ScottK> Well, I'm motivated.  I read the DSN and went "Wait, I use that package!".
<ScottK> yw in any case.
<ScottK> mdeslaur: Missed a spot.
<mdeslaur> ScottK: hrm?
<ScottK> My utopic upload failed.
<mdeslaur> ah, yes, trusty FTBFS too
<mdeslaur> hrm, that's odd
<ScottK> Very.
<ScottK> python -c "import reportbug; print reportbug.VERSION_NUMBER" in the source works fine locally.
<mdeslaur> that's not the one that's weird, it's the other one that specifically excludes the +nmu* part
<mdeslaur> $(shell dpkg-parsechangelog | egrep '^Distribution:' | sed 's/^Distrib
<mdeslaur> ution: \([^+]*\).*/\1/')
<ScottK> Ah.
<mdeslaur> that one...so 6.5.0+nmu1ubuntu0.1 becomes 6.5.0
<mdeslaur> I'm wondering if we're better to change the regexp and get the real version
<ScottK> I think that's more divergence from Debian, so let's not.
<mdeslaur> so all ubuntu versions will report as 1.5.0 from now on?
<mdeslaur> er...6.5.0
<ScottK> Until there's a non-NMU.
<mdeslaur> ok
<ScottK> Confirmed that works
<ScottK> Do you want another debdiff?
<mdeslaur> nah, I'm good
<mdeslaur> I just changed it to 6.5.0
<ScottK> Same here on Utopic.
<hallyn> pitti: hi, would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.30-1.dsc ?  I'm hoping this'll be it for some time.
<hallyn> (next step will be working on getting what we need from systemd itself)
<highvoltage> win 24
<sarnold> a user in #ubuntu-hardened is complaining about hash-sum mismatches in http://ddebs.ubuntu.com/dists/trusty-security
<sn33zy> any devs need someone to help them? im bored and need something to do (and the bugs.launchpad.net is beyond me)
<jtaylor> sn33zy: fancy digging around in the gcc-4.9 package? :)
<Noskcaj> jtaylor, That is mean
<sn33zy> jtaylor, Noskcaj  if its easy task and I know what im looking for I will do it :)
<Noskcaj> sn33zy, You could try making an app for ubuntu touch. http://developer.ubuntu.com/
<jtaylor> its probably not easy if your unfamiliar with the package :/
<sn33zy> ok :(
<Noskcaj> Or fixing bugs in the ubuntu phone core apps
<Noskcaj> I have to go to school now, bye
<sn33zy> bye Noskcaj
#ubuntu-devel 2014-08-06
<sn33zy> im having a hard time finding the package to satisfy aclocal-1.13
<sarnold> sn33zy: the saucy automake package offered one http://packages.ubuntu.com/search?searchon=contents&keywords=aclocal-1.13&mode=exactfilename&suite=saucy&arch=any
<sn33zy> sarnold, yeah i later realized i have aclocal 1.14 installed and wondering why it DESIRES the 1.13 version for the build instead
<sarnold> sn33zy: auto* stuff sometimes doesn't work with newer versions; you can try with 1.14 and if it works fine, hooray :)
<sn33zy> gah
<sn33zy> ./configure: line 22834: GNOME_DEBUG_CHECK: command not found
<sn33zy> ./configure: line 22835: syntax error near unexpected token `maximum'
<sn33zy> ./configure: line 22835: `GNOME_COMPILE_WARNINGS(maximum)'
<lamont> is utopic currently safe to do-release-upgrade to?
<lamont> for developer values of safe, that is.
<ScottK> It's certainly safe for me if you do it.
<stgraber> lamont: I did it this morning on my laptop and outside of some compiz packaging mess which has been reasonably easy to fix (remove the mess, install ubuntu-desktop^), things went fine and the machine still boots
<pitti> Good morning
<pitti> hallyn: sure
<pitti> hallyn: uploaded; and yay that we can sync now
<LocutusOfBorg1> can anybody please retry this build? https://launchpad.net/ubuntu/+source/aegisub/3.1.2-1/+build/5939512
<LocutusOfBorg1> it is a really old ICE
<pitti> LocutusOfBorg1: done
<LocutusOfBorg1> 10x
<dholbach> good morning
<ion> that
<dholbach> Noskcaj, did you have any luck with python-wsme?
<dholbach> Noskcaj, I'd really appreciate if you could take a look at it and fix it some time soon, or let folks know on the mailing list of elsewhere, that you need some help
<LocutusOfBorg1> wxpython3.0 fails to build on ubuntu because of a missing dependency on mesa-common-dev
<LocutusOfBorg1> dragged in by gtk2.0-dev in debian, but NOT in ubuntu
<LocutusOfBorg1> some substvars is not working
<LocutusOfBorg1> pitti, failing :(
<doko> tkamppeter, system-config-printer python3 \o/, what is left, hplip?
<pitti> oh wow, it did happen? nice!
<pitti> err, how would that work? system-config-printer-gnome is still pulling in python-gtk2 and all the python 2 bits?
<pitti> tkamppeter: ^ ah, it actually does use python3-gi and various gir1.2-* now, seems you just didn't update the Depends: for python3 and GI?
<pitti> awesome, this was a really tough one
 * xnox ponders who maintains system-config- et.al and friends
<LocutusOfBorg1> pitti did you read the mesa-common-dev problem?
<LocutusOfBorg1> seems that pango in debian needs it, while in ubuntu doesn't
<LocutusOfBorg1> and this is (one) of the cause of the build failures
<pitti> LocutusOfBorg1: sounds like a missing build dep in wxpython then?
<LocutusOfBorg1> sound like a missing wl,as-needed in debian/pango? :)
<LocutusOfBorg1> I wonder why pango drags unneeded dependencies
<LocutusOfBorg1> anyway your solution seems the right one ;)
<LocutusOfBorg1> seb128, you there?
<LocutusOfBorg1> sorry for bothering
<seb128> LocutusOfBorg1, sort of, not really, in a meeting
<seb128> why?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1353362
<ubottu> Ubuntu bug 1353362 in cairo (Ubuntu) "cairo needs merge from debian" [Undecided,New]
<LocutusOfBorg1> ^^^
<seb128> I can have a look to that next week
<seb128> I'm travelling this week/in meetings until friday
<seb128> but anyone can do that
<LocutusOfBorg1> can I just copy the debian packaging, look at the ubuntu1 delta and ask for a sponsor?
<seb128> well, you can do the merge if you want yes
<seb128> if that's the question
<LocutusOfBorg1> yes, I don't know too much about cairo, I don't want to prepare a stupid debdiff
<LocutusOfBorg1> this is why I asked you ;)
<LocutusOfBorg1> I don't know how big is the delta from debian
<Noskcaj> dholbach, transaction is not actively maintained in debian, and turbogears use python-support and many universe depends :(
<dholbach> Noskcaj, yep, doko mentioned something like that - might be worth trying to workaround the new (build-)dep
<Noskcaj> the debian maintainer seems to think it's needed, but i'll branch the code and have a look
<dholbach> great
<doko> Noskcaj, can can see this here: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
 * Noskcaj cries
<Noskcaj> dholbach, Crappy patch for turbogears made, transaction maintainer contacted
<Noskcaj> I'll push my fixes on i work transaction out
<tkamppeter> pitti, principally, I have switched over to the Python-3-based s-c-p 1.5.0 now. If something in the packaging is still missing/wrong, please tell me (or patches welcome). Thanks.
<pitti> tkamppeter: yes, the build deps are py3 now, but not the binary deps
<doko> Noskcaj, transaction seems to be unproblematic, turbogears2 is the problematic one
<tkamppeter> pitti, following python3 packages do not exist: python3-gtk2, python3-notify, python3-libxml2, python3-gnomekeyring, python3-pycurl. What are the replacements for them?
<tkamppeter> pitti, is it correct that python-gobject is replaced by python3-gi?
<pitti> tkamppeter: yes, python-gobject -> python3-gi
<pitti> tkamppeter: python-gtk2 etc. are replaced with gir1.2-*-*
<pitti> tkamppeter: you need to grep for "from gi.repository import" (e. g. Gtk, Pango, etc.) and map these to the gir1.2-* names
<pitti> tkamppeter: python3-pycurl does exist
<pitti> tkamppeter: supposedly python3-lxml is the corresponding replacement for python3-libxml2, but I'm not 100% sure
<slangasek> xnox: so lp:~xnox/ubuntu/utopic/upstart/core-split says it's been merged, does that mean you no longer need my review?
<xnox> slangasek: pitti has battled it out =)
<xnox> slangasek: it typically request multiple reviews, but await at least one extensive review.
<pitti> oh right, it's already in NEW; thanks xnox
<xnox> slangasek: where is, is xnox =)
<xnox> slangasek: where it, is xnox =)
 * xnox can't type today
<xnox> upgrades & operation tested on phone, desktop and server as well.
<xnox> slangasek: you of course, as an archive admin, may choose to review NEW =)
<tkamppeter> pitti, thanks. I did all the changes, but did not find a gdk and a gobject in the gir1.2 collection. All the rest seems to be solved.
<pitti> tkamppeter: Gdk is part of gir1.2-gtk-3.0
<pitti> tkamppeter: GObject is part of gir1.2-glib-2.0
<tkamppeter> pitti, OK, thanks.
<tkamppeter> pitti, as the whole thing is running with python3 now and depends only on python3 packages, do I have to rename the python-cupshelpers package into python3-cupshelpers (or simply let it provide python3-cupshelpers so that both python2 and python3 apps can use it)?
<pitti> tkamppeter: err yes, it needs to be renamed to python3-cupshelpers
<pitti> tkamppeter: in fact, the current python-cupshelpers is broken as it only provides a Python 2 package
<pitti> tkamppeter: fortunately the only reverse dependencies are system-config-printer itself
<pitti> so it didn't break anything
<pitti> tkamppeter: but the rename needs to be done
<tkamppeter> pitti, ho do I get a python3 package then?
<pitti> tkamppeter: look at its contents, it already is a python3 package
<pitti> tkamppeter: /usr/lib/python3/dist-packages/cupshelpers
<pitti> tkamppeter: it just needs to be renamed
<pitti> tkamppeter: and ${python:Depends} changed to ${python3:Depends}, and similar
<pitti> tkamppeter: I suppose you updated its python-pycurl dep already
<tkamppeter> yes I did so.
<tkamppeter> pitti, all ${python:Depends} I replaced by ${python3:Depends} in the control file, all python-cupshelpers by python3-cupshelpers.
<pitti> tkamppeter: great, thanks
<tkamppeter> pitti, no "python-" any more, all "python3-" now.
<pitti> \o/
<tkamppeter> pitti, all "gir"ified in system-config-printer-gnome
<LocutusOfBorg1> dholbach, do you have time for looking for a package?
<tkamppeter> pitti, anything to do with the old python-cupshelpers binary package? Or will it simply go away by "apt-get autoremove"?
<LocutusOfBorg1> or pitti maybe ;)
<dholbach> LocutusOfBorg1, is it on http://reqorts.qa.ubuntu.com/reports/sponsoring/? :)
<pitti> tkamppeter: yes, it'll be removed semi-automatically as it doesn't have remainin reverse dependencies
<pitti> tkamppeter: so don't worry about it
<dholbach> LocutusOfBorg1, I'm just asking because that's usually the best place to put something which needs uploading :)
<LocutusOfBorg1> not right now
<LocutusOfBorg1> yes I know
<dholbach> ok good :)
<LocutusOfBorg1> ;)
<LocutusOfBorg1> (I just would like to see the problem fixed asap
<dholbach> ok, which package is it?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1353362
<ubottu> Ubuntu bug 1353362 in cairo (Ubuntu) "cairo needs merge from debian" [Undecided,New]
<LocutusOfBorg1> sorry for the long time, I needed to prepare the debdiff
<tkamppeter> pitti, thank you very much, the package is on the way.
<LocutusOfBorg1> and to check every change in debian if was merging with ubunut
<slangasek> xnox: only the binary packages get into the new queue, no sane diffs from there ;P
<LocutusOfBorg1>  /s/ubunut/ubuntu
<slangasek> but yeah, I can look at it if no one beats me to it
<LocutusOfBorg1> I checked every git commit since the last merge from debian and cherry picked them in ubuntu
<LocutusOfBorg1> and for the shlib file I built it locally and double checked if symbols were still there in .13 release
<LocutusOfBorg1> everything was good so far
<dholbach> LocutusOfBorg1, maybe I'm not the best person to review this, but instead somebody from the desktop team could take a look at it?
<LocutusOfBorg1> I still don't know if this is needed
<LocutusOfBorg1> +  * debian/patches/server_side_gradients.patch:
<LocutusOfBorg1> +    - Don't use server side gradients, most drivers don't handle those and
<LocutusOfBorg1> +      are really slow
<LocutusOfBorg1> seb128 has quit
<dholbach> I mentioned this in #ubuntu-desktop
<dholbach> LocutusOfBorg1, SÃ©b is in China, where it's 20:46 right now :)
<LocutusOfBorg1> wonderful :)
<LocutusOfBorg1> time for VAC ;)
<LocutusOfBorg1> anyway this is something that worries me a little bit, since the last 10 debian release fixed a lot of problems in the package
<tjaalton> LocutusOfBorg1: can't enable gl backend
<tjaalton> because of bug #725434
<ubottu> bug 725434 in cairo (Ubuntu Natty) "Nvidia drivers lead to extra memory usage for each process using libGL" [High,Fix released] https://launchpad.net/bugs/725434
<xnox> slangasek: well the diff is already generated for the source package by launchpad http://launchpadlibrarian.net/181650696/upstart_1.13.1-0ubuntu2_1.13.1-0ubuntu3.diff.gz
<dholbach> LocutusOfBorg1, no vac though
<xnox> slangasek: maybe queudiff simply needs to be taught how to fetch those?
<slangasek> not particularly; the binary NEW review is for reviewing the binary delta
<LocutusOfBorg1> tjaalton, do you think it is still the case? why debian doesn't have this problem?
<tjaalton> i don't know
<LocutusOfBorg1> anyway disabling again might be trivial
<tkamppeter> pitti, the new python3-cupshelpers 1.5.0...0ubuntu3 conflicts with python-cupshelpers 1.5.0...0ubuntu1 and python-cupshelpers 1.5.0...0ubuntu2, but not with python-cupshelpers 1.4.x and older. How do I the breaks/conflicts/replaces with correct versioning?
<pitti> tkamppeter: ah, for upgrades within utopic from the past few days
<pitti> tkamppeter: hmm, tricky; but I suppose if you just do Replaces:/Breaks: python-cupshelpers (<< 1.5.0...0ubuntu3) it'll do
<pitti> tkamppeter: you can drop these after a few weeks or so
<tkamppeter> pitti, I get paste.ubuntu.com/7970474/  Anytjing missing?
<tkamppeter> pitti, do I also needs Conflicts: or Provides:
<pitti> tkamppeter: use --auto-deconfigure as advertised, or dpkg -P python-cupshelpers first and run it a few times
<pitti> tkamppeter: with dpkg alone it's hard to upgrade over breaks: and package renames; apt will figure it out
<pitti> tkamppeter: no, Provides: would be entirely wrong; Breaks:/Replaces: is correct and sufficient, no Conflcits: necessary
<tkamppeter> pitti, thanks. So then all is correct and I can upload it?
<doko> xnox, did you recently touch mpi? https://launchpadlibrarian.net/181599384/buildlog_ubuntu-utopic-amd64.dolfin_1.3.0%2Bdfsg-2build2_FAILEDTOBUILD.txt.gz
<pitti> tkamppeter: did you manage to install the packages now?
<pitti> tkamppeter: if that works (with removing python-cupshelpers manually), and s-c-p still runs, it's fine
<tkamppeter> pitti, all works now. Thank you. I will upload now.
<pitti> tkamppeter: cool, danke!
<xnox> doko: i did touch a lot of mpi.... =(
<xnox> doko: fun, we did do libpetsc3.4.2-dev transition as part of the mega transition.
<xnox> doko: i like how ppc64el is green =) so perfect - ship it. Everyone has switched to ppc64el by now, haven't they? =)
<mlankhorst> can xserver-xorg-video-s3 be removed? it's no longer in debian
<doko> xnox, no, blacs-mpi wasn't built there. now fixed
<hallyn> pitti: \o/  thanks
<pitti> hallyn: ah, it's imported, want me to sync, or are you at it?
<hallyn> what does imported mean?
<pitti> hallyn: into Launchpad, so it's syncable
<hallyn> ok - please go ahead, else i'll do it after bfast
<hallyn> "you people" had a busy night, 236 unread since 8 hrs ago
<pitti> hallyn: synced
<hallyn> thx
<LocutusOfBorg1> tjaalton, I'm checking right now
<zyga> cjwatson: hi, I'm trying to convert pyotherside packaging from SVN to git and move it to collab-maint, I got the git tree by following https://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git but I'm unsure about a few things. Do you have a moment for a few questions here on IRC?
<cjwatson> zyga: probably not today; though in general I'd recommend asking rather than asking to ask :)
<xnox> current utopic (without proposed) is trying to remove unity and compiz on upgrade and hold-back unity8
<xnox> =(
<zyga> cjwatson: excellent advice: should I try to integrate upstream git repository into the packaging repository? should I (do I have to?) do the same for pristine upstream tarballs
<zyga> cjwatson: and lastly (most importantly perhaps) where do I put the repository to? various alioth docs are kind of fuzzy about that, links end up 404, etc
<xnox> actually, i had a broken unity installed locally, downgrading to utopic fixed everything.
<cjwatson> zyga: my opinion (not shared by everyone, apparently, but what the hell) is that if upstream git exists or is easily synthesisable, then there's no excuse for not integrating it into the packaging repository
<cjwatson> zyga: pristine tarballs are really easy to handle in git using pristine-tar
<cjwatson> zyga: I've been converting all my packages to git-dpm, and love it; it makes both the above things pretty straightforward.  I've gone on about it fairly recently on debian-devel
<zyga> cjwatson: do you have an example package that I could look at?
<zyga> cjwatson: branch/tag/etc arrangement
<cjwatson> zyga: openssh, parted, grub2
<zyga> cjwatson: where can I find them?
 * zyga looks at grub2 control file
<cjwatson> apt-cache showsrc has the vcs-* headers
<zyga> right, thanks
<cjwatson> zyga: or smaller-scale: man-db, putty, six, trn4
<cjwatson> zyga: if you don't already have a suitable alioth group, you can push packages under users/; e.g. I have this in ~/.gitconfig:
<cjwatson> [url "git+ssh://git.debian.org/git/"]
<cjwatson>         insteadof = debian:
<zyga> users/ ?
<cjwatson> then I push to e.g. debian:users/cjwatson/libpipeline.git, and that shows up as git://anonscm.debian.org/users/cjwatson/libpipeline.git and http://anonscm.debian.org/cgit/users/cjwatson/libpipeline/
<zyga> ah
<zyga> do you co-maintain any of your packages?
<cjwatson> yes, e.g. six is under collab-maint
<zyga> ok, I'll start with that, thanks for your time!
<cjwatson> so that's debian:collab-maint/six, git://anonscm.debian.org/collab-maint/six.git, http://anonscm.debian.org/gitweb/?p=collab-maint/six.git
<cjwatson> or indeed http://anonscm.debian.org/cgit/collab-maint/six.git
<cjwatson> zyga: http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html may be helpful too
<zyga> cjwatson: thanks!
<cjwatson> zyga: oh, my last comment, for converting existing packages I always like to keep as much history as possible, and http://www.catb.org/~esr/reposurgeon/ was the first tool I found that would let me convert my svn/bzr/etc. history into git without ridiculous amounts of effort
<cjwatson> so I can recommend that as a good building block
<zyga> cjwatson: git-svn got the history I wanted
<zyga> cjwatson: though, that's a bare debian repo history
<zyga> cjwatson: so I'm not sure if I shoud reply that on top of upstream releases or not
<cjwatson> ah, you would want to stitch that into something better
<cjwatson> if that were me, I would use reposurgeon to stitch it in on top of upstream so that I could pretend it was always that way
<cjwatson> but your call :)
<zyga> cjwatson: I guess a plain rebase will do in this case
<zyga> cjwatson: rebase the packaging on top of each release
 * zyga is still unclear about branches though
<cjwatson> A plain rebase is unlikely to be at all straightforward with more than one branch point like that
<cjwatson> Branches: if they're ones I want to generally advertise, I create them at the top level and push them, for random personal experimentation in shared repositories I tend to call them people/cjwatson/foo
<cjwatson> if I want to push them
<cjwatson> Not much more needed really.  If you're using git properly you'll likely have lots of short-term branches locally that you never push anywhere
<zyga> cjwatson: I need to look at your code to have more meaningful questions now
<cjwatson> Most of my packaging branches have master, upstream, pristine-tar at a minimum
<cjwatson> *packaging repositories
<zyga> I meant the upstream vs debianized branches
<cjwatson> That's upstream vs. master
<cjwatson> git-dpm puts the upstream ref in the right place when you import a new upstream version
<cjwatson> Which in best practice is a commit whose parent is the upstream tag and which contains the delta between the upstream tag and the released tarball (if any)
<gQuigs> I was wondering why bootchart2 hasn't been automatically synced from debian?  (https://bugs.launchpad.net/ubuntu/+source/bootchart/+bug/1035385)
<ubottu> Ubuntu bug 1035385 in bootchart (Ubuntu) "[ Request ] Missing bootchart2, please sync it from Debian Sid" [High,Triaged]
<gQuigs> ^the bug is now out of date as bootchart2 has made it all the way to stable (I'm not sure the best place to sync from right now...)
<cjwatson> gQuigs: overwrites binaries from bootchart; when I last checked I heard there wasn't much point as our bootchart had most of the relevant stuff anyway
<cjwatson> Actually binaries from pybootchartgui
<cjwatson> anyway it's in the sync blacklist
<cjwatson> bootchart # keybuk, entirely separate packaging
<cjwatson> bootchart2 # cjwatson, ditto; our bootchart source has many of the improvements here, and the pybootchartgui binary clashes
<gQuigs> cjwatson: oh.. in that case should I guess I should file a separate request to pull the systemd units out of boothchart2?
<cjwatson> That might be a good idea, yeah
<tedg> pitti, Saviq and I are looking at some PPA build issues, which might be from systemd needing a new sysvinit in proposed. Do you know about that?
<gQuigs> cjwatson: will do, thanks
<xnox> gQuigs: the problem with bootchart2 was that it was systemd only and doesn't support upstart boot. Kind of worthless for comparing bootspeed on ubuntu then, isn't it.
<gQuigs> xnox: oh, right, that would make it very useless..
<gQuigs> so I believe that bug could be marked "Won't Fix"
<LocutusOfBorg1> tjaalton, please let me know if something else is needed
<LocutusOfBorg1> right now I'm testing my package ;)
<pitti> tedg: err no, I don't -- what's up with that?
<tedg> pitti, It seems to be causing some failure in proposed
<tedg> pitti, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
<pitti> tedg: oh argh -- I have a new sysvinit installed locally for a week or so, waiting for slangasek's go ahead
<doko> tkamppeter, pitti: no way for foo2zjs to use lcms1 again ...
<pitti> tedg: I uploaded another systemd with lower initscripts dep; thanks
<pitti> Saviq: ^
<pitti> stgraber: https://github.com/lxc/lxc/commit/281b843 > whoops, thanks!
<stgraber> np :)
<tedg> xnox, stgraber, so I'm trying to use the cgroup feature in Upstart. But it seems on the N4 there is no cpuset or even an upstart dir in /sys/fs/cgroup
<tedg> Is there something I need to do to get those?
<stgraber> tedg: no and they don't need to be there so long as cgmanager is running
<tedg> stgraber, Then what should my cgroup line be in my upstart job? I was using "cpuset" before because that seemed to work on my desktop.
<tedg> stgraber, So it was just "cgroup cpuset"
<stgraber> tedg: just had a quick look at what cgroups are enabled in the mako kernel
<stgraber> tedg: it looks like you can only use: debug, cpu, cpuacct and freezer
<stgraber> tedg: if you need memory, cpuset or any of the others, you'll have to talk to the kernel team
<tedg> stgraber, Well, what should I use? :-)  I really just want a bag of PIDs.
<tedg> I tried cpu on my desktop, but that didn't seem to work.
<tedg> Changing to cpuset fixed things
<stgraber> tedg: did you try freezer? seems like this one is available everywhere
<tedg> stgraber, No, I didn't. I can.
<tedg> stgraber, freezer gets me much further, thanks!
<hallyn> you can also just mount -o name=bag , if you only want to collect pids
<stgraber> hallyn: you'd need to do that before cgmanager starts if you want to use it with upstart
<hallyn> stgraber: /etc/default/cgmanager
<hallyn> (add it to the list of options)
<tkamppeter> doko, what do you mean? What is broken with foo2zjs?
#ubuntu-devel 2014-08-07
<hallyn> sarnold: jdstrand sadly, i'm getting the qcow corruption you do.  since i'm on a buggy thinkpad i haven't disproven that it's a thinkpad-only bug
<sarnold> hallyn: yay?
<sarnold> hallyn: sorry it hit you too, but hopefully that'll make recreating it easier..
<sarnold> I'd really hope qcow2 is pretty boring and not care about the hardware it's running on; it doesn't feel like a special-enough snowflake to care, you know?
<jdstrand> hallyn: I would hope it wasn't thinkpad specific like you said, but yeah, 'yay'?
<jdstrand> hallyn: is this on utopic or trusty?
<jdstrand> hallyn: I'm on utopic now, but haven't tried 2.1 since I've been needing my VMs lately
<hallyn> i'm on utopic
<hallyn> unfortunately it's interfering with my attempts to test qemu live migration through libvirt
<hallyn> i wasn't (yet) looking to reproduce it :)
<Unit193> After the upstart upgrade, the following files are considered obsolete: /etc/X11/Xsession.d/00upstart /etc/X11/Xsession.d/99upstart /etc/cron.daily/upstart /etc/bash_completion.d/upstart /etc/upstart-xsessions
<pitti> xnox: I did an initial cleanup of the "uncategorized" ones in http://pad.ubuntu.com/missing-systemd-units
<pitti> slangase`, xnox: ^ what Unit193 said: that's what I meant by "needs dpkg-maintscript for migration" (same for conffile questions)
<dholbach> good morning
<doko> tvoss, please don't close MIR issues in changelog entries
<doko> tvoss: lp: #1338587 is incomplete
<ubottu> Launchpad bug 1338587 in qtquick1-opensource-src (Ubuntu) "[MIR] trust-store" [Undecided,Incomplete] https://launchpad.net/bugs/1338587
<tvoss> doko, I can get rid of gcovr for the package
<tvoss> doko, and I thought all of qt is in main?
<doko> tkamppeter, pitti: foo2zjs build-depends on lcms which is in universe. only lcms2 is in main, you need to port to lcms2 if you want to have  foo2zjs built
<doko> tvoss, wishfull thinking =)
<doko> Mirv, ^^^
<Mirv> tvoss: um, why is trust-store using qtquick1-5-dev, nothing we use should be using it?
<tvoss> Mirv, just patching it out
<Mirv> tvoss: maybe an accidental build dependency?
<Mirv> tvoss: ok, thanks!
<Mirv> Qt upstream indeed has some funky naming that can cause confusion
<tvoss> Mirv, yup
<Mirv> ("qtquick1" source package provides "libqtdeclarative" library, while "qtdeclarative" source package provides "libqtquick" and "libqtqml")
<Mirv> the explanation is something along the lines that Qt4 also had declarative, so for the version 1 they stuck with that source package name, even though Qt 5 has the new version 2 declarative too
<Mirv> s/source package name/library name/. see, the confusion.
<tvoss> Mirv, https://code.launchpad.net/~thomas-voss/trust-store/remove-unneeded-build-dependencies/+merge/229907
<tvoss> doko, ^
<darkxst> pitti, so 214 seems to be working well with both upstart and systemd boot, although I am getting very occasional, races on upstart boot where gdm/X fails to start (pretty sure that has happend on 208 as well though
<pitti> darkxst: ah, great to hear!
<tkamppeter> doko, pitti, the lcms1 build dependency in foo2zjs is bogus, it actually does not depend on any lcms library (any more). I will remove it.
<tkamppeter> doko, pitti, OdYX, has freshly introduced this dependency to the obsolete library, as there was some utility program copied from lcms1 in the source code of foo2zjs. I will ask him whether there is a way he can solve it with lcms2. If we do not get a quick solution I will put up an out-of-sync vesion simply taking the newest upstream source but not changing anything else.
<xnox> jdstrand: ping bug #1341083 will you upload that, or shall i?
<ubottu> bug 1341083 in ufw (Ubuntu) "ufw needs systemd unit or init.d script" [Medium,In progress] https://launchpad.net/bugs/1341083
<xnox> ogra_`: do you agree that ubuntu-defaults-nexus7 can be removed? bug #1353922
<ubottu> bug 1353922 in ubuntu-defaults-nexus7 (Ubuntu) "RM: ubuntu-defaults-nexus7 obsolete product" [Medium,Confirmed] https://launchpad.net/bugs/1353922
<mlankhorst> xnox: I can't even get it to work on raring or later
<ogra_`> xnox, yeah,, burn it with fire
 * mlankhorst tried
<xnox> excellent, mark it as "ported to systemd by means of removal"
<pitti> and *swoosh* gone it is, updated bug
<pitti> xnox: very nice, systemd-sysv is now installable in an utopic-proposed chroot (and upstart can be removed)
<pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt still complains about systemd-sysv, so I figure before britney is happy we'll need to fix *all* dependencies to upstart (and we don't actually want that..)
<xnox> pitti: hm. but systemd-sysv does declare conflicts and replaces upstart right?
<xnox> something is odd, we do know they are not co-installable. and plenty of other packages/providers act the same way.
<xnox> pitti: latest upload 208-7ubuntu4 ?
<pitti> xnox: no, not replaces: (that would be wrong), just conflicts:
<pitti> skipped: systemd (20 <- 270)
<pitti>     got: 40+0: i-40
<pitti>     * i386: systemd-sysv
<pitti> it's not very verbose, but I take it it's complaining about it being uninstallable
<pitti> xnox: or perhaps it didn't yet take the new sysvinit into account (that's not yet in _output, as mysql-5.6 is still running)
<xnox> wait and see i guess.
<cjwatson> pitti: that'll mean it's uninstallable in isolation
<cjwatson> when considering release pocket + whatever set of uploads it's considering at that point
<pitti> cjwatson: "in isolation" means "just on a debootstrapped env", i. e. just essential+required packages?
<xnox> i thought it was just recursive depends
<pitti> anyway, seems it's happy now
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt doesn't have systemd-sysv any more, so it was just lagging behind the sysvinit publication
<pitti> final: systemd,sysvinit,trust-store
<pitti> all good now and accepted
<xnox> \o/
<cjwatson> pitti: this is pure dependency analysis, no debootstrap or anything like that
<cjwatson> pitti: take release's Packages files, take the set of sources that are being considered, remove all old entries corresponding to those sources, add new entries ditto, see if anything new is uninstallable
<cjwatson> or strictly, see if the uninstallable count increases
<mpt> ev, do you remember where the usb-creator a.k.a. Startup Disk Creator design spec is? Iâve gone through a dozen wiki pages and havenât found it
<mpt> https://wiki.ubuntu.com/USBInstallationImages has early Ascii art, but I remember doing proper sketches afterward :)
<ev> mpt: not sure - I'll dig through my email
<tvoss> doko, build-deps are patched out of trust-store
<doko> tvoss, great! any update on net-cpp?
<tvoss> doko, next on my list
<tvoss> doko, but likely not today
<xubincs>  #ubuntu-mir
<jdstrand> pitti: hey, is there a wiki page on how to change init systems? (testing the ufw change)
<jdstrand> xnox: ^
<jdstrand> wiki page or similar
<pitti> jdstrand: boot with init=/bin/systemd in the grub shell
<pitti> jdstrand: there's https://wiki.ubuntu.com/systemd with that too (but slightly out of date)
<xnox> jdstrand: init=/lib/systemd/systemd (init=/bin/systemd requires new enough initramfs, thus may fail)
<xnox> on kernel boot params.
<pitti> right, init=/lib/systemd/systemd has worked since utopic's early days
<jdstrand> I have an up to date utopic vm
<pitti> jdstrand: yep, that'll do; once booted, check with "systemctl" that you get a lot of output, instead of an error message that you can't connect
<pitti> jdstrand: in particular, "systemctl status ufw"
<pitti> jdstrand: should look something like http://paste.ubuntu.com/7979840/
<tedg> Now that I'm using libmir-client I can't build on powerpc or ppc64el. What's the recommend way of showing that?
<tedg> Just list the arch in the control file?
<tedg> Can I say "everything that mir builds on" ?
<pitti> tedg: kind of, if you build-dep on mir, it will just fail to build on ppc*
<pitti> which is fine
<xnox> tedg: no need for arch restrictions, just build-deps on things you need. FTBFS are not blockers, regressions in FTBFS across arches are but can be cleaned up by archive admins when intentional.
<jdstrand> pitti: oh heh, I guess I need to install systemd :)
<xnox> (e.g. previous version build everywhere, new one depends on libmir-client and hence need binaries removed to migrate in britney)
<pitti> jdstrand: it's pretty hard to not have it installed..
<xnox> jdstrand: =)
<pitti> tedg: right, we need to remove the ppc binaries of the previous version, then it'll propagate
<pitti> jdstrand: is that a minimal server-like VM or so? on a desktop it's a very firm dependency (since saucy)
<jdstrand> pitti: no, full desktop. been upgrading for a while. I was guessing it didn't have it installed-- it didn't come up. still diagnosing
<pitti> jdstrand: verify in /proc/cmdline?
<jdstrand> I didn't get that far
<jdstrand> pitti: I'm just updating /etc/default/grub to have:
<jdstrand> GRUB_CMDLINE_LINUX_DEFAULT="init=/lib/systemd/systemd"
<jdstrand> then doing 'sudo update-grub'
<tedg> pitti, xnox, okay, cool. So how do I request the binaries to be deleted?
<jdstrand> huh, weird, it came up this time
<pitti> jdstrand: hm, that sounds right; what happened then?
<jdstrand> I did install systemd-ui before rebooting
<pitti> jdstrand: ah, I never tried -ui
<jdstrand> pitti: I missed the early boot-- it was just a blck screen
<jdstrand> when I looked
<xnox> tedg: you don't have to, unless it's already stuck in proposed-migration.
<jdstrand> might be unrelated and a kvm issue
<xnox> tedg: what packages are you talking about?
<tedg> xnox, pay-service, my issue is that ci-train doesn't think it's built, figure it's checking the same thing.
<jdstrand> pitti: it appears to be working :)
<jdstrand> pitti, xnox: thanks for your help!
<xnox> tedg: i don't know what ci-train looks for. I'm only talking about general ubuntu archive rules.
<jdstrand> pitti: I need to do a little more testing, then will just sponsor your changes
<jdstrand> pitti: thanks again for your work on this!
<xnox> robru:  sil2100: pay-service will be regressing in supported architectures due to new build-dependencies, does ci-train handle that sensibly? or is something needed to be done there.
<pitti> jdstrand: great, you're welcome!
<sil2100> xnox: you mean, it will now not build for some architectures?
<xnox> sil2100: correct.
<xnox> sil2100: well, it will rather FTBFS on some.
<sil2100> xnox: so, sadly CI Train might have some problems with that, as long as the archive still provides binaries for the packages in the archive
<xnox> sil2100: well, dep-wait on libmirclient-dev.
<sil2100> But if those will be dropped from the archive, CI Train will work ok
<xnox> sil2100: horum.
<sil2100> I guess we could also just ignore the failing architectures, which is possible but a bit dirrrty, as build failures will have to be ignored
<xnox> tedg: so you need an archive-admin to review the diff and request removal of binaries by an archive admin.
 * tedg looks for an archive admin to delete powerpc
<tedg> ;-)
<pitti> tedg: i. e. all powerpc binaries of the "mir" source?
<pitti> ah no, that already doesn't exist on ppc
<tedg> Heh, no I was joking about the architecture
<pitti> tedg: what does "I" expand to?
<pitti> in "Now that I'm using libmir-client I can't build on powerpc"
<tedg> Probably easiest way to see the diff is the one that is generated by the PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008
<tedg> pitti, pay-service source package
<tedg> pitti, Generates libpay* pay-service
<pitti> unity-scope-click and unity8 also build-dep on libpay2-dev, so these would need to go as well
<pitti> ah, they don't build on ppc, so that's fine
<tedg> Are they there? I believe the click scope is not.
<tedg> Not having Mir on PPC is resulting a large set of packages not building there.
<pitti> tedg: so to be completely clear, you are going to upload a new pay-service source which is going to build-dep on Mir?
<pitti> because, if you are not going to, then the next upload of pay-service will just bring them back
<tedg> pitti, Yes, I'd like to publish silo 8, which depends on mir.
<pitti> tedg: usually I'd only remove the binaries from utopic if there was a new version waiting in -proposed, but I suppose the CI airline doesn't work that way
<tedg> You can rest assured that *I* won't upload anything :-)
 * pitti turns the LP crank, go faster!
<pitti> tedg, sil2100: go wild: http://paste.ubuntu.com/7980028/
<tedg> pitti, awesome, thanks pitti
<sil2100> \o/
<cjwatson> tedg: Can the package in question build without mir?  If so, the correct answer is mir [amd64 arm64 armhf i386].  If not, removing the binaries was correct.
<tedg> cjwatson, No, it needs Mir now.
<cjwatson> Right.
<tedg> The trusted prompt support specifically.
<bdmurray> pitti: is there something wrong with ddebs.ubuntu.com? all the -security pockets seem empty
<bdmurray> http://ddebs.ubuntu.com/dists/saucy-security/
<xnox> bdmurray: better that than publishing them before USN notices & unembargo go out
<pitti> bdmurray: yes, I removed them as they were horribly outdated
<pitti> bdmurray: they aren't really needed either
<pitti> people were complaining about hash sum mismatches, etc.
<pitti> -security is just a subset of -updates these days anyway; I haven't yet taught ddeb-retriever about building -security properly (that'll again double all the special cases of emulating soyuz)
<bdmurray> pitti: some notification about that would have been nice as the retracers have been failing since that happened
<pitti> bdmurray: oh, if they use them, how did they not fail before?
<pitti> as their Packages could never be authenticated through the Release files
<pitti> bdmurray: anyway, it's probably possible to build them properly, but it'll again take a while to sort that out
<pitti> jdstrand: traincon? ufw is on the touch images?
<bdmurray> pitti: http://pastebin.ubuntu.com/7980482/
<jdstrand> pitti: yes, it is and its part of the smoke image tests
<pitti> bdmurray: argh, sorry about that
<slangasek> pitti: do you have a handle on this, or do you want me to look into it?  I'm not sure if it just needs recreating the files?
<pitti> slangasek: we can copy the old (and broken) files, if that helps any
<pitti> but frankly it might be just better to drop the -security ddeb apt sources from the retracers
<bdmurray> pitti: well I can just disable the -security pocket in the sources.list files for the retracers but it would have helped to do that before they were removed
<pitti> bdmurray: well, want me to put the old ones back?
<pitti> well, that still wouldn't update the Release files, but apparently that didn't stop the retracers
<bdmurray> pitti: how long would it take to put the old ones back?
<slangasek> pitti: I think the point here is that ddebs.u.c, for all its bodgery, is a critical dependency of errors.u.c; so if you need to make changes to it, however innocuous, could you please keep bdmurray in the loop so he doesn't have to root-cause from the other end?
<pitti> slangasek: ack, will do next time
<pitti> bdmurray: a few minutes
<bdmurray> pitti: that is probably faster than submitting an RT and finding a webop
<pitti> bdmurray: done
<bdmurray> pitti: thanks!
<bdmurray> pitti: so I should still remove -security though?
<pitti> bdmurray: yeah, please; they are useless and not updated anyway
<doko> barry, any update on the MIR fron?
<doko> front even
<barry> doko: not much.  been busy with other things. :(
<rbasak> I'm flipping some binary packages from being generated by mysql-5.5 to being generated by mysql.5.6.
<rbasak> Just to check, I don't need to do anything special, do I, except to upload both to migrate from utopic-proposed together?
<rbasak> They should be ABI compatible, and will have a higher packaging version number.
<rbasak> This will create some component mismatches too, but I presume that this will just be flipped afterwards by archive admins?
<rbasak> (to demote 5.5 and promote 5.6)
<pitti> rbasak: binary overrides won't change due to an upload, so yes, it'll appear in component-mismatches afterwards
<pitti> would be nice to fix mysql-5.6's autopkgtest if it wants to become the new default version (5.5's work)
<rbasak> pitti: yeah, I get dep8 failures here. I've asked upstream to take a look.
<rbasak> infinity: there's some confusion about HWE EOL prompts before 14.04.1 is recommended by update-manager, which I think is fair.
<rbasak> infinity: users are asking if the block is for some reason that might mean they should delay forcing an update.
<rbasak> infinity: http://irclogs.ubuntu.com/2014/08/07/%23ubuntu-server.html#t15:24
<rbasak> infinity: do we have an answer for that question please, until 14.04.1 is recommended?
<hallyn> zul: so yeah.  feh!  systemd-shim is now being used by libvirtd, and not quite doing the right thing bc it only expected logind to talk to it
<hallyn> SUCCESS
<hallyn> zul: I'm going to push http://paste.ubuntu.com/7982242/ to utopic to fix standard migration;  then I will probably push http://paste.ubuntu.com/7982241/ to support migration from precise, as well as push Alex Bligh's qemu patch (also required)
<Elv1313> Hello, we have build issues on our PPA since a few day because of an upstream package change that seem to conflict with its own dependencies. Can someone take a quick look and revert that chnage? https://launchpadlibrarian.net/181543532/buildlog_ubuntu-utopic-amd64.sflphone-daemon_1.4.1-rc20140804~ppa1~utopic_FAILEDTOBUILD.txt.gz
<hallyn> just running qrt first...
<hallyn> xnox: :(
<hallyn> (#server)
<sarnold> :(
<xnox> i've kept -devel, -desktop (cause seb128 is funny when he is trolling), -dmb, -installer, -motu, -uk
<xnox> and #upstart, #lxcontainers and #cgmanager.
<xnox> undecided about a few others.
<xnox> hallyn: sarnold: such is life =)
<hallyn> \o see you at plumbers :)
<xnox> hallyn: yeah, need to register and organize travel there.
<sarnold> xnox: heh, if you're at plumbers and at debconf, I might actually see you more -after- you've left ...
<xnox> sarnold: *giggle* true
<hallyn> zul: ok, if you could take a look at the qemu and libvirt pkgs in ppa:serge-hallyn/virt, each has 2 extra packages in it, i intend to push them to utopic tomorrow
<sarnold> (i'm not actually doing much for debconf, but some of the debian folks interested in apparmor want to get together, sounds like fun...)
<hallyn> never been to debconf myself
<xnox> sarnold: oh, that does sound like fun!
<xnox> sarnold: hallyn: this one looks busy. Best one was in Nicaragua. Excellent location, cheap bear, 8 talks per day across 2 rooms, breakfast / lunch / dinner / hack labs, 1 full day sightseeing day trip.
<xnox> it's very laidback.
 * hallyn jealous
<shadeslayer_> xnox: did you have a look at the ubiquity bug I pinged you about?
<xnox> shadeslayer_: nope, been testing/fighting to push out 12.04.5. Let me look at it.
 * shadeslayer_ is pondering about coming to conf week
<xnox> shadeslayer_: conf week? DebConf that is?
<shadeslayer_> no, the large conference week at DÃ¼sseldorf
<shadeslayer_> with linux plumbers conf and couple of other ones
<stgraber> I know quite a few Ubuntu folks will be there, we'll be a bunch from Foundations and there will be all the kernel team too I think
<shadeslayer_> Embedded Linux Conference was the one I was thinking about
<shadeslayer_> there's also Cloud Open Europe and the KVM forum that happens the same week
<shadeslayer_> mental ^_^
<shadeslayer_> xnox: re ubiquity, its something to do with privilege escalation
<xnox> shadeslayer_: hm.
<shadeslayer_> it complains about not being able to run commands as a different user, and works fine when using sudo, which sounds like a privilege escalation issue to me
#ubuntu-devel 2014-08-08
<shadeslayer_> xnox: I'm sad you left #kubuntu-devel :(
<shadeslayer_> are we not kool enough for you?
<xnox> https://launchpad.net/~xnox - Not Canonical - Joined 8 hours ago
<xnox> shadeslayer_: ^
<shadeslayer_> that is ... news to me
<Laney> ~not-kubuntu-community?
<xnox> shadeslayer_: Laney: well most of my discussions on #kubuntu-devel were about ubiquity, which well should be taken to #ubuntu-installer or here =)
<Laney> :P
<pitti> Good morning
<Laney> hey pitti
<pitti> Laney: err, are you already aware or still?
<pitti> Laney: oh, you're in China I suppose/hope :)
<Laney> pitti: æ¯çï¼æå¨ä¸­å½
<pitti> Laney: bless you
<Laney> ä»å¤©æ¯æåä¸å¤©
<Laney> :)
<seb128> pitti, nihao
<seb128> pitti, ä½ å¥½
<Laney> this guy can type Chinese
<Laney> I just copy and pasted
<pitti> compose key? or with google translate?
<seb128> yeah, I just keep forgetting to press space before enter
<Laney> he's set up the input method
<seb128> pitti, pinyin input method
<happyaron> pitti: next time you don't need to ask me about that anymore, :)
<seb128> pitti, but you can ask happyaron about security
<pitti> happyaron: heh; well, I'd expect *you* to be familiar with pinyin, nice to see that seb128 picked up some of it!
<Laney> ä½ å¥½å°ç«
<happyaron> pitti: I'm familiar with that, but seb128 is good now
<happyaron> seb128: oh yeah let's ask stephan about security.
<seb128> happyaron, yeah, you need to learn for next time :-)
<happyaron> yes
<happyaron> LOL
<TheMuso> c
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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: dholbach
<sarnold> xnox: probably they just removed that feature in 2012 :D
<xnox> sarnold: darn, time to switch to hexchat
<pitti> dpm, wgrant: didn't LP translations have some functionality to search for a string?
<pitti> I see some untranslated ones for current touch images, and wanted to add them, but I'm not sure which template they are from
<dpm> morning pitti, there's no cross-template search functionality, unfortunately
<dpm> pitti, which strings are they?
<pitti> dpm: for now, the bubble dialog when you connect to a wlan in the wizard
<pitti> dpm: I just started testing the current images for German (now that we have fresh langpacks)
<pitti> dpm: and it seems easiest to just fix stuff rather than filing bugs for everything (unless they aren't translatable, of course)
<pitti> dpm: I suppose it's indicator-network or something, but I seemed to remember that someone showed a "search" thing
<dpm> pitti, my hunch would be either ubuntu-system-settings (where the other wizard strings are) or indicator-network
<pitti> dpm: right, but there doesn't seem to be a *system-settings* template
<pitti> I have https://translations.launchpad.net/ubuntu/utopic/+lang/de?batch=250 and https://translations.launchpad.net/ubuntu/utopic/+lang/de/+index?batch=250&memo=250&start=250
<dpm> pitti, the only search you can do is on an individual template basis. It's ubuntu-system-settings ^
<pitti> so that I see all domains on two pages
<dpm> pitti, you can try http://projects.davidplanella.org/stats/utopic/de - that'll give you the phone domains only
<pitti> dpm: ah, https://translations.launchpad.net/ubuntu/utopic/+source/ubuntu-system-settings/+translations doesn't have templates
<pitti> dpm: which might explain why it's not on the list above
<dpm> pitti, ah, it does, but on the upstream project. It's not on the list above because I only show untranslated templates
<dpm> it might need the x-ubuntu-langpack thing
<pitti> dpm: I mean on the two URLs I posted
<dpm> pitti, yeah, you'll have to look at upstream, but we should add u-s-s to the langpacks at some point - https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/de/+translate?show=untranslated
<pitti> dpm: ah, so these are from packages which still didn't enable the X-Langpack thingy
<dpm> exactly
<pitti> dpm: ok, so we generally use the upstream translations, not the ubuntu ones
<pitti> dpm: http://projects.davidplanella.org/stats/utopic/de looks nice!
<pitti> dpm: that means that system-settings is already fully translated, so the thingy I see is either not from system-settings, or the strings aren't translatable
<pitti> dpm: ignore me, it says "System settings"; I'm blind :)
<dpm> pitti, it's not, the page updates daily and there were new strings added yesterday
<dpm> let me refresh the stats...
<pitti> yay timeout errors
<pitti> and I keep getting them :/
<pitti> https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/de/+translate?show=untranslated&memo=10&start=10
<pitti> dpm: hm, so pretty much every page times out, but at least it seems most of my updated translations come through
<cjwatson> Oh for new database serves
<cjwatson> *servers
<pitti> wgrant: is there some DB or HW update in progress, or some regression in the code?
<dpm> pitti, yeah, the timeouts are really horrible, so I'm looking forward to the new SSDs in LP to mitigate them
<cjwatson> The machines actually have an operating system on them ...
<cjwatson> pitti: There's a large update in progress as part of widening a librarian-related column to 64 bits
<cjwatson> But translations was just over the edge of doom anyway
<pitti> also, the English original strings are sometimes really horrible
<pitti> cjwatson: ah, thanks
<cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=67926
<wgrant> pitti: Translation searhc is absolutely dreadful, but as Colin says we have hardware coming up to fix that, and it's worse than usual for the next few hours while we performance some unrelated database migrations.
<pitti> wgrant: search actually works fine, I'm talking about https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/de/+translate?show=untranslated&memo=10&start=10
<pitti> wgrant: these time out in almost all cases
<pitti> wgrant: but thanks for the heads-up, no worries! as long as there's something known that slows it down :)
<wgrant> Ah, that's suggestions being terrible.
<wgrant> SSDs should resolve that, fingers crossed.
 * xnox uses all ppa builders for a little bit =) it's nice that there are a few of them, and they are fast
<cjwatson> xnox: And should be more soon ...
<slangasek> also, that they have a post-hardy kernel
<cjwatson> (Well, the capacity for more, at least)
<pitti> dpm: ok, fun like https://code.launchpad.net/~pitti/ubuntu-system-settings/i18n/+merge/230062 :)
<dpm> pitti, ah, nice! That was bug 1350921
<ubottu> bug 1350921 in Ubuntu Translations "Developer mode translations are cut off" [Low,Triaged] https://launchpad.net/bugs/1350921
<pitti> dpm: oh thanks, you linked the MP?
<dpm> yep
<pitti> dpm: I'm glad that I asked you
<jpds_> pitti: Hey.
<pitti> hey jpds_
<Guest15370> pitti: How goes?
<pitti> Guest15370: pretty well, thanks! and you? (I liked your previous nick better)
<Guest15370> Yeah, Freenode happened.
<jpds_> pitti: I was wondering if you could push https://www.libreoffice.org/bugzilla/show_bug.cgi?id=33461 upstream.
<ubottu> bugs.freedesktop.org bug 33461 in general "Allow extra mount options from udev rules" [Enhancement,New]
<pitti> jpds_: I add it to my TODO list (NB I'm on holiday next week)
<slangasek> bdmurray, pitti: so I'm chasing the reasons why my whoopsie smoke test isn't working correctly on the CI infrastructure, and have just filed bug #1354318 after talking with ev; feel free to double-check my reasoning
<ubottu> bug 1354318 in apport (Ubuntu) "whoopsie-upload-all has a wrong check for whether the upload is done" [Undecided,New] https://launchpad.net/bugs/1354318
<jpds_> panda|z: Excellent, thank you.
<slangasek> bdmurray: and fwiw, from bug #1235436, it looks like this is something of an about-face on my part, sorry about that ;)
<ubottu> bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,Fix released] https://launchpad.net/bugs/1235436
<shadeslayer_> xnox: any luck with ubiquity?
<Saviq> pitti, hey, re: unity8 .pot, that won't get pulled in to trunk, so won't end up in translations.lp anyway, will it?
<pitti> Saviq: it will for the Ubuntu package translations (not upstream)
<pitti> Saviq: but that way you can at least translate missing strings somewhere, and translation sharing will also copy them to upstream
<Saviq> pitti, right, but will make us even less careful about pot updates
<Saviq> pitti, we don't have https://translations.launchpad.net/ubuntu/+source/unity8 configured though, should it show up there?
<pitti> Saviq: ah, if we don't use it, I'm happy to revert that part
<Saviq> pitti, one thing we were planning to do for a few generated things is to have a pre-push hook that would warn you in case your .pot is out of date
<pitti> Saviq: I see out of date pots pretty much everywhere :(
<pitti> Saviq: ah, that'd be great
<Saviq> pitti, just never got around to it
<Saviq> pitti, obviously CI could warn, too
<Saviq> pitti, so what we could do now is have a test that fails if .pot is outdated
<Saviq> and then the -ci run would complain
<pitti> Saviq: ok, I deleted that commit and updated the MP
<pitti> Saviq: so it's just the .pot update now
<Saviq> pitti, k, thanks
<pitti> Saviq: ATM there doesn't even seem to be a standardized way to update the pot?
<Saviq> pitti, indeed, is there such a convention in Ubuntu?
<pitti> Saviq: yes, dh_translations usually figures it out
<pitti> but that won't help for upstream projects/branches
<Saviq> pitti, I just now thought I'd quite like the train to have a hook system where we could tell it to do that before building
<Saviq> pitti, this way each release would get an updated .pot pushed to trunk
<Saviq> and all would be golden
<pitti> Saviq: autotools with intltool and also cmake have some standard invocations, though
<Saviq> pitti, yeah, we're using cmake's gettext support, but it's far from ideal
<pitti> Saviq: right, but that still needs an automatic way to build the pot, before you can check for a diff?
<Saviq> pitti, oh well, we have the target
<Saviq> pitti, make pot_file
<Saviq> pitti, the hook we'd maintain
<Saviq> pitti, we had to do http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/po/CMakeLists.txt to get it to work with cmake's gettext support
<Saviq> ultimately ended up invoking the commands ourselves...
<Saviq> pitti, so I'm thinking scripts in citrain/ or so that would get run at certain points in the build process on the train / airline
<Saviq> without special knowledge of the train, just executables
<xnox> infinity: want to merge openldap per chance? =)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | 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:
<shadeslayer_> xnox: no need to look at that ubiquity bug, I've fixed it, it was a issue in sddm
<doko> xnox, no openldap merge?
<xnox> doko: nah, i want to drop gnutls26 from main (as promised to security team by debian import freeze....)
<xnox> so didn't look into merging openldap proper.
 * mdeslaur hugs xnox
<xnox> mdeslaur: i think rtm branching is in progress, not sure if rtm will end up with gnutls26 however =/
<xnox> & gnutls28
<mdeslaur> xnox: I don't support rtm, so I don't really care :P
<cjwatson> ubuntu-archive@snakefruit:~$ grep gnutls derive-ubuntu-rtm.script
<cjwatson>         gnutls26        2.12.23-15ubuntu2
<cjwatson>         gnutls28        3.2.16-1
<cjwatson> sorry :)
<mdeslaur> hehe
<cjwatson> pitti: Around?  ubuntu-rtm is initialising on production now, so it would be a good time to flush the ubuntu-rtm ddebs stuff from dogfood and repoint it at production.
<cjwatson> pitti: IIRC I gave you the necessary URLs, but let me know if you can't find them
<cjwatson> stgraber: Heads-up: we'll want to configure system-image for ubuntu-rtm on production a bit later today
<ogra_> pitti, sergiusens rsalveti and i are looking at SD card mounting on phones ... i know there is an easy way to query udisks2 to know if a disk is removable ... is there anything like that for udev too (i cant see anything in the env vars)
<sergiusens> ogra_: oh, you want to forward up only the removable ones? i c now :)
<ogra_> yeah
<ogra_> dont fire up stuff for HW we dont want to touch anyway
<sergiusens> pitti: and to follow on to that mediascanner uses GVolumeMonitor but /media/$USER doesn't exist on startup (or potentially doesn't) so mediascanner just gives up
<xnox> cjwatson: looks like rtm is a full blown distro =) it has auctex -> so it must have both emacs and texlive \o/
<xnox> also thanks for accept spam =)
<xnox> ah, I see email is already reported in #ubuntu-release
<ogra_> xnox, wait, emacs ? we need to drop that for vim-full-blown :)
<cjwatson> xnox: Yeah, sorry about the accept spam, it only covered the first few dozen packages before we noticed
<jono> ogra_, I leave you for one month
<jono> emacs?
<cjwatson> I'm pretty sure it's just a build-dep somewhere :)
<ogra_> heh
<ogra_> yeah, we definitely dont ship it
<cjwatson> it really doesn't take a lot of runtime to pull in a thousand packages in the full build-dependency closure
<pitti> cjwatson: hey
<pitti> cjwatson: what was the archive URL again? I only have derived-archive.dogfood in my browser history
<pitti> sergiusens: /media/$user is created by udisks, but perhaps /media is readonly?
<cjwatson> pitti: http://derived.archive.canonical.com/ubuntu-rtm/
<pitti> sergiusens: the upstream mode of udisks2 is to use /run/media/user/ which would work much better for the phone; but there were objections to breaking LSB compatibility, so we patched it for /meida/
<sergiusens> pitti: yeah, sorted the issue, /media was fine, was missing /var/lib/udisks2 and starting mediascanner a lot further in the boot process
<sergiusens> thanks!
<sergiusens>  /run would be easier
<sergiusens> less mounts
<pitti> cjwatson: hm, did we build any package there today? I just ran it, and it didn't see anything
<pitti> cjwatson: so it didn't build any indexes either
<cjwatson> pitti: We haven't built anything, just copied
<pitti> cjwatson: ah, ok
<cjwatson> pitti: There are indexes though
<pitti> cjwatson: yeah, by default it only rebuilds the indexes of pockets that it got ddebs for
<cjwatson> pitti: Do we need to link ddebs over from ubuntu or something?
<pitti> cjwatson: gee, I hope not; IMHO this should stay an overlay archive
<pitti> oh wait, you said there was no guarantee of version non-clash
<pitti> it also comes in handy that I need to disappear in about 20 minutes..
<pitti> cjwatson: anyway, I'll let it run like that for now, so it won't lose anything; we can switch from overlay to "full copy" in a week, too
<cjwatson> pitti: It's explicitly not an overlay archive, because it has to be disconnected from ongoing development in Ubuntu
<cjwatson> pitti: That's the entire reason we're doing a derived distribution rather than a PPA
<pitti> ack
<cjwatson> pitti: We'll *probably* be OK for version non-clash provided that direct uploaders don't do anything stupid
<cjwatson> pitti: Since CI Train generates package versions based on the series version, and that happens to differ right now
<pitti> for one week, anyway
<cjwatson> For the lifetime of this series
<pitti> no, I mean not having a full copy should last for the next week
<cjwatson> But yeah, it's not guaranteed.  And maybe we will have prodstack4 and unicorns soon
<cjwatson> Oh, err
<cjwatson> Would you mind if I got slangasek to link things around next week?
<cjwatson> I'm a bit worried about losing things
<pitti> no, of course not
<cjwatson> OK, cool.  A hardlink farm would be OK?
<pitti> yes, I guess so
<pitti> I think we need to make a cp -al of www/pool/ to www/ubuntu-rtm/pool/
<pitti> then run it once with building indexes, and let the archive cleanup take care of throwing out anything that's not needed
<pitti> that'll probably runs for a few hours
<cjwatson> Hm, OK
<cjwatson> slangasek: ^- for early next week
<GunnarHj> pitti: Hi Martin, did you see the last comment at bug #1090288?
<ubottu> bug 1090288 in langpack-locales (Ubuntu) "The locale file for en_ZA appears to have an error" [Undecided,Confirmed] https://launchpad.net/bugs/1090288
<pitti> cjwatson: cp -al running now
<pitti> today is a good day for that
 * pitti packs in the meantime
<cjwatson> Oh marvellous, thanks
<cjwatson> I'll remind slangasek next week to check on it
<cjwatson> Maybe eventually the derived archive publisher will finish
<pitti> cjwatson: http://ddebs.ubuntu.com/ubuntu-rtm/pool/ is a full copy now
<pitti> INFO: Building indexes for 14.09
<ogra_> pitti, /medis is explicitly writable now
<pitti> GunnarHj: sorry, -ENOTIME
<GunnarHj> pitti: Ok, it can wait.
<cjwatson> pitti: Great, thanks
<ogra_> pitti, our prob is that there can be android partitions (firmware etc) that are vfat and udisks tries to mount ... we'd like to make sure we only mount removable devices
<pitti> ogra_: udisks doesn't try anything; that'd be the gvfs monitor
<ogra_> (additionally to the mediascanner issues)
<pitti> ogra_: we could change the polkit policy to disallow non-removable devices
<ogra_> pitti, no, thats a new tool from sergio
<ogra_> pitti, ciborium is our SD card only - phone- mount manager
<pitti> cjwatson, slangasek: crontabs for ubuntu-rtm are set up, there you can see the full command (it's also in .bash_history, of course, with --verbose instead of --quiet)
<cjwatson> pitti: thanks a lot
<pitti> cjwatson: argh, re-running; forgot to copy the apt-ftparchive cache
<Saviq> dpm, hey, we encountered a thought today: we seem to be missing a convention on when/how/where to run .pot updates
<Saviq> dpm, KDE has a messages.sh script in the root of all projects, so tooling automagically runs those to update the templates
<Saviq> dpm, very many of our projects lack updated templates due to it being an easily forgotten step
<pitti> cjwatson: screw it, db copy didn't help
<pitti> cjwatson: presumably because the paths are differnet
<pitti> cjwatson: so this will run for looong
<dpm> Saviq, +1000, I was having a conversation about it yesterday with some folks in a bug thread
<pitti> cjwatson: I'll check on Sunday
 * pitti waves good bye, gotta run
<Saviq> dpm, can you come up with a convention and start forcing people to use it? :D
<dpm> Saviq, I think the only challenge here is do do only updates if the contents of the .pot file changes, and ignore changes that just update the date field
<Saviq> dpm, then we can make the train run that after merging all branches
<Saviq> dpm, yeah, I agree we shouldn't run on every MP, it's just wasteful
<Saviq> dpm, but then line numers in comments do make sense
<stgraber> cjwatson: ok
<dpm> Saviq, sure, I'll think of something and I'll run it past you and other folks. It will save me a lot of work filing bugs and chasing devs :)
<Saviq> dpm, so I'm thinking that if we left it to whatever actually releases the code (train in our case)
<Saviq> dpm, runs it before creating the tarball
<Saviq> dpm, I think at that point it doesn't even matter if only the date changed
<Saviq> dpm, most of the time a lot of line numbers will change as well
<cjwatson> stgraber: May be a bit later, still waiting for the publisher to finish and I'll need to sort out image building after that
<cjwatson> stgraber: So I'll leave you a message
<dpm> Saviq, sounds sensible and doable
<Saviq> dpm, loop in sil2100 so he knows what to run :)
<stgraber> cjwatson: ok, sounds fine, I'm around for another 6 hours and 30 minutes :)
<dpm> Saviq, ack, thanks. Another somehow related question I've not found the answer for yet: do you know which project in LP shows the reboot/shutdown dialog after the on/off button longpress? I'm trying to find out where to file the bug to flag that it needs internationalization
<Saviq> dpm, unity8
<dpm> aha
<Saviq> dpm, indeed, they're not i18n'd, let me fix that quickly
<sil2100> What where?
<dpm> Saviq, ok, cool
<dpm> sil2100, let's catch up on Monday on how to automate translation template updates with the ci train
<sil2100> dpm: ah, ok, sure :)
<Saviq> dpm, another reason to only do it on tarball creation... conflicts
<Saviq> it's basically a sure way to get yourself fooked if you update the template on every MP
<dpm> ack
<Saviq> dpm, actually that's the reason why i18n'ing the dialog will have to wait a moment as we have a branch updating the .pot, and another updating the dialog itself, so we're screwed like that if we don't start prerequisiting branches ;)
<Saviq> dpm, this branch https://code.launchpad.net/~paulliu/unity8/reboot_140728/+merge/228485 will include the i18n changes needed
<dpm> perfect
<dpm> Saviq, and I've got another unrelated question. Normally I'd ask mterry, but he doesn't seem to be around. We've got some tests failing on Jenkins (i.e they're run on a desktop, not a device) in file manager because they expect (I think) a .service file that is missing. Would you happen to know which package contains it? -> http://pastebin.ubuntu.com/7989673/
<Saviq> dpm, that service is provided by unity8
<dpm> oh, so we'd have to install the unity8 package on jenkins to make the tests runnable
<Saviq> dpm, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/LightDM/DBusGreeter.h
<dpm> Saviq, if we just add a dependency to install unity8 for the tests to run, will that interfere with the regular session in any way?
<Saviq> dpm, that might not be a great solution, though
<Saviq> dpm, the service will not work unless unity8 is running
<dpm> bummer
<Saviq> dpm, we should probably rather remove the dependency of those tests on UnityGreeter
<dpm> I'm not very familiar with the code, so I don't know if that'd be a big task or if there is an alternative
<Saviq> dpm, yeah, unless there's a unity8 session going, nothing should depend on that service, please throw anyone who knows what's happening there our way on Monday
<dpm> ok, thanks Saviq
<infinity> rbasak: HWE upgrades and full series upgrades really don't relate.
<rbasak> infinity: except that the HWE EOL notification advises a full series upgrade.
<infinity> rbasak: Ahh, fair point.  Well, we should be flipping the switch soon anyway.
<rbasak> infinity: OOI, is there a particular reason why users shouldn't update to 14.04 anyway, other than the switch not being flipped? They keep asking.
<infinity> bdmurray: I've lost track over the last few days, are we still tracking a potential blocker for adding trusty to meta-release-lts?
<infinity> rbasak: There were a few update-manager bugs that made the upgrade explode.  Those should be fixed.
<rbasak> infinity: OK, thanks.
<infinity> rbasak: But there's no reason people shouldn't be running 14.04.
<infinity> rbasak: And the majority of the more explody bugs probably also shouldn't affect server users, whose upgrades tend to be much simpler and smoother.
<arrrghhh> infinity, agreed - I was able to 'force' the update on a VM without any issue.  I also upgraded my 12.04 system to the trusty kernel so that HWE message would go away :)
<infinity> rbasak: Anyhow, if people are worried that there's something wrong with trusty, or the lts-trusty HWE stack, you can put their minds at ease.  The real problems are/were latent bugs in precise that make the upgrade to trusty have a sad.  Trusty itself is mostly awesome.
<arrrghhh> infinity, for me, it was the meta-release-lts page not being updated... and no real explanation, but I wasn't really sure where to look for an explanation...
<bdmurray> infinity: I still need to double check those couple of bugs I found. Some recent error tracker changes took longer than I thought they would.
<infinity> bdmurray: Right, well we probably don't want to flip it on a Friday anyway, but if all looks good for Monday, let's do it.
<infinity> arrrghhh: I've had more than few nearly hysterical complaints about it, sadly, but there was a reason I put the word "soon" in the release announcement instead of "now".
<arrrghhh> infinity, trying to not be hysterical lol.  just was curious why the drop didn't happen at the prescribed date... I just posted a comment in a launchpad bug
<arrrghhh> https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1344762
<ubottu> Launchpad bug 1344762 in update-notifier (Ubuntu) "update-notifier tells me to upgrade from 12.04.4 LTS to 14.04 LTS (because of HWE), but that release is not found" [Undecided,Confirmed]
<arrrghhh> I actually ended up hosing my 12.04 system up pretty badly, which I am still scratching my head on... so I just clean installed 14.04.  Working well :)
<bdmurray> xnox: You'd talked about some race condition and Contents.gz before right?
<xnox> bdmurray: yes. i wanted to fix it by (a) cutting down the time to generate contents.gz (patch sent to mvo) (b) make launchpad use it (no patch sent) (c) make publisher copy new contents.gz in place from contents-generation, instead of the other way around - contents-generation dropping new contents into place hopefully before publisher decides that old one is obsolete one.
<bdmurray> xnox: okay, thanks for the update
<bdmurray> infinity: upgrades look fine to me but you want to hold off until Monday correct?
<infinity> bdmurray: Yeah, Monday morning is fine.  Just want to have people around to deal with panic if we're wrong about being ready.
<bdmurray> infinity: got it
<bdmurray> barry: still around?
<barry> bdmurray: yep!
<bdmurray> barry: I've a gdb (I think) question. So apport retrace calls gdb like so http://pastebin.ubuntu.com/7991534/ and I clearly see a warning from gdb about the core file size. Do you know how I can get to generate that warning?
<bdmurray> I ask because apport-retrace just writes a new crash report without any information about that warning.
<barry> bdmurray: probably ran out of disk space while writing the core file, or there's a ulimit that truncated it.
<bdmurray> barry: right, I understand that. I just want to log / record this warning / error somehow.
<barry> bdmurray: ah, i see.  off the top of my head, i'm not sure how you can capture that, other than stdout/stderr grepping.
<barry> bdmurray: there's probably a way to mimic the inspection that gdb does, but not sure how to do that off the top of my head
<bdmurray> barry: okay, I was hoping for some show or info command that might help
<barry> bdmurray: let me poke around on the gdb docs for a few minutes.  i'm running some long tests. :)
<barry> bdmurray: nothing obvious that i can tell
<bdmurray> barry: thanks for looking, I found where apport throws away the Warnings
<barry> cool
<cjwatson> stgraber: OK - what will happen to system-image if I delete the current ubuntu-rtm tree and start again?
<stgraber> cjwatson: so wiping all entries in /srv/cdimage.ubuntu.com/www/full/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/ and then publishing some new ones?
<cjwatson> Right
<stgraber> it'll do fine
<cjwatson> Actually just the whole ubuntu-touch/ubuntu-rtm tree
<stgraber> assuming the new one will have a version number higher than the current latest one
<cjwatson> stgraber: We should make sure it restarts in a fresh channel, I think
<stgraber> yeah, I can wipe the rtm channel too, that's easy
<cjwatson> stgraber: I know you had Opinions on naming and such, I'll leave it to your judgement
<cjwatson> We shouldn
<cjwatson> 't need the dry-run staging channel any more
<cjwatson> Wasn't meant to stick around :)
<stgraber> ah right, I can kill stable-staging-proposed
<cjwatson> stgraber: OK, so I'll wipe that now and kick a fresh build
<stgraber> ok, I'll destroy the s-i channel now too
<stgraber> so IIRC what I suggested was to import ubuntu-rtm/14.09/ into a rtm-14.09-proposed channel, which can then feed an rtm-14.09 channel once testing has passed which can then feed the stable channel (or if we are confident enough, we can just make stable an alias of rtm-14.09)
<cjwatson> Running, fingers crossed
<cjwatson> I don't think we need to have two layers of feeding there, one should do
<cjwatson> An alias makes sense
<stgraber> yeah, the two layers always felt weird to me but that was a request from asac, so I'll leave that up to him
<stgraber> turning stable into an alias channel again should be trivial anyway
<stgraber> cjwatson: what device images should I expect with the new cdimage build? still the same set for now? (flo, generic, grouper, mako, manta, generic_x86)
<cjwatson> Believe so
<stgraber> ok, going with that for now then
<cjwatson> OK, please argue the feeding out with asac when he's back
<stgraber> hmm, actually I'll drop grouper from that list, for some reason we still build the android bits, but that's not supported at the moment
<cjwatson> stgraber: OK, that's actually building now that I've fixed it.  We should possibly configure an iso.qa target ...
<stgraber> cjwatson: what's the cdimage incantation for it?
<cjwatson> For the build?
<stgraber> yeah
<cjwatson> DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live
<cjwatson> Except I need to upload a suitable keyring to ubuntu-rtm
<stgraber> ok, so we'll need a series called ubuntu-rtm/14.09 on the tracker and then triggering the usual touch product from there should work
<stgraber> actually, let me also redo the system-image config to match what we're doing on cdimage and the tracker, that is, use ubuntu-touch/ubuntu-rtm/14.09-proposed as the channel name
<cjwatson> stgraber: Could you also set "Redirect release pocket uploads" to True and "Alias for development series" to "devel" on ubuntu-rtm?  I think it's on https://launchpad.net/ubuntu-rtm/+edit
<cjwatson> Failing that it should be on the API
<stgraber> not visible in the web UI, using the API then
<cjwatson> stgraber: The series might be mangled on the way through to the tracker - I don't quite recall
<cjwatson> I had to fix a lot of things there
<stgraber> >>> rtm.redirect_release_uploads
<stgraber> False
<stgraber> >>> rtm.redirect_release_uploads = True
<stgraber> >>> rtm.development_series_alias
<stgraber> >>> rtm.development_series_alias = "devel"
<stgraber> >>> rtm.lp_save()
<cjwatson> Hm, it uses config.series, but I think that ought to be config.full_series, otherwise it's potentially ambiguous
 * cjwatson fixes
<cjwatson> OK, should be ubuntu-rtm/14.09 for the tracker now
<cjwatson> stgraber: thanks
<stgraber> cjwatson: I'm EOD now and doubt I'll have enough spare time to look into getting RTM published properly on system-image until Monday though ping me anyway once you have a build. In theory the system-image config should be right and it should auto-import but it may still need some tweaking.
#ubuntu-devel 2014-08-09
<cjwatson> stgraber: Right.  It *looks* like it's auto-imported, but it would be good if you could check it over if you get a moment.
<almostevery> hello, is this the ubuntu dev channel?
<almostevery> hello, can anyone help please? I have a problem with 14.04. keyring program
<kklimonda> almostevery: it's not really the best channel for asking support questions (especially on weekends), it's for discussing development of ubuntu itself.
<kklimonda> almostevery: you'll have more luck on #ubuntu probably
<almostevery> kklimonda, it is where I'm coming from, as it is beyond a support matter. and my question is precisely about a problem related to design-development of the keyring program on 14.04.
<almostevery> I just started using 14.04., and saw that the new design of the keyring program doesn't 'forget' the keyring passwords. that is, across restarts of computer or re-insertions of hardware, it doesn't ask the password again, but instead it suffices to right-click on unlock to access the keyring.
<almostevery> that is, it suffices to access desktop to access a keyring, if it is once decrypted via its respective password
<almostevery> which wasnt the case in 12.04. I dont know 13.04. or 13.10. as I didnt use them
<kklimonda> you may have more luck asking during the working week, right now most people aren't around
<almostevery> well, maybe I have. let's see..
<mdeslaur> almostevery: the keyring is automatically unlocked with your login password when you log in
<mdeslaur> almostevery: that's how it always worked
<almostevery> mdeslaur, yes, for the 'login' keyring it is true. but login keyring is not my only keyring, and until now it wasn't the case that all other keyrings were 'kept open' forever in the way I described above. this is the novel problem.
<mdeslaur> almostevery: if you don't want it to use your login password to unlock automatically, you can change it in the Passwords and Keys tool by right-clicking the "Login" section and selecting "Change password"
<mdeslaur> almostevery: are you using the same password for the other keyrings?
<almostevery> mdeslaur, even there, it is not the same thing as before. it never was the case that accessing desktop released access to all keyrings that have been unlocked before.
<mdeslaur> almostevery: I'm guessing people thought that was a bug that needed fixing :)
<mdeslaur> almostevery: perhaps open a bug with the upstream gnome-keyring project?
<almostevery> mdeslaur, yes. this was what I heard in the support channel
<almostevery> mdeslaur, I have installed 14.04. only now, and promptly noticed this. hasn't this been reported as a problem until now?
<mdeslaur> almostevery: nope
<almostevery> since April?
<mdeslaur> almostevery: most people are happy that the bug is finally fixed and it automatically unlocks all keyrings I guess
<almostevery> mdeslaur, 'bug is finally fixed'? which bug was there?
<mdeslaur> almostevery: please file a bug with "ubuntu-bug gnome-keyring", then file an upstream bug here: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring
<mdeslaur> almostevery: people used to complain that the other keyrings wouldn't unlock automatically at login
<almostevery> mdeslaur, and you call this a 'bug'?
<almostevery> it is a feature.
<mdeslaur> almostevery: that's why you should file a bug upstream, and explain your point of vue and see if they agree and will change t
<mdeslaur> it
<mdeslaur> s/vue/view/
<mdeslaur> almostevery: oh, are the passwords for your other keyrings actually stored in the login keyring?
<almostevery> the bug is what we have now. devices and keyrings auto-decrypting across restarts and reconnects..I should think ubuntu users -and by all means devs- know way better than offering a facebookization of the OS.
<almostevery> mdeslaur, in the present 'transparent' state of the keyrings, I fear I cant answer such a question publicly, sorry.
<mdeslaur> almostevery: well, if they are, then that's your problem, you didn't uncheck the "automatically unlock this keyring when I log in" option when you unlocked them
<mdeslaur> so they got atored
<mdeslaur> stored
<mdeslaur> almostevery: if you click on the "Login" keyring and you have an entry called "Unlock password for:keyringname" then that's why
<mdeslaur> right click on that and delete it
<almostevery> mdeslaur, you mean I delete the login keyring?
<almostevery> mdeslaur, sorry, I got it
<almostevery> yes, I see such entries
<mdeslaur> ok, so delete those entries, and then lock and unlock your other keyrings
<mdeslaur> when it asks for your password, UNCHECK the box marked "Automatically unlock this keyring whenever I'm logged in"
<almostevery> mdeslaur, I deleted them. now I will uncheck the box, and hope the keyrings wont be kept open afterwards. in the login keyring, I see also password used in a client application. if I deleted it, would I have to reenter the password each time I open the client?
<mdeslaur> almostevery: depends how the application stores the password. Either it stores it unconditionally, or it has a checkbox that asks you whether or not it should be stored
<almostevery> mdeslaur, I will just try it, then. thank you for your help, it seems to have solved the auto-access problem. thanks for the links to bug reporting, too. I would anyway consider contacting them to know more.
<almostevery> and to get clear about it
<almostevery> mdeslaur, have a good weekend!
<hjd> The package haskell-data-lens-template is in the FTBFS list for Utopic (due to unmet dependencies). However, I was able to build it on an up to date utopic system without any problems, atleast on i386. Could someone please trigger a rebuild of this package? :)
<rbasak> hjd: apt-get can't install libghc-data-lens-dev for me on utopic-proposed on amd64. Are you sure you have utopic-proposed enabled in your build environment?
 * hjd checks
<hjd> rbasak: No, I don't have -proposed enabled.
<hjd> ...and I get the same unmet dependencies error after enabling -proposed. Nevermind then :)
<cjwatson> rbasak: I recommend leaving it alone.  I'm on top of the Haskell transition, but there are a number of layers.
<cjwatson> (hjd has left.)
<cjwatson> It's always "fun" when people think they can parachute into the middle of that :-/
<cjwatson> Well-meaning, but ...
 * xnox irc disconnected again.....
 * cjwatson uploads rebuilds of another layer of the above
<rbasak> cjwatson: yeah, I assumed it wasn't as simple as that :)
<Guest67794> Hello, I need help compiling a non-pae Kernel
<Guest67794> I found out what to change in the .config flies, but the rules script keeps overwriting what I put in there
<directhex> Guest12249, why do you need a non-pae kernel?
#ubuntu-devel 2014-08-10
<cjwatson> hjd: Regarding your question yesterday, thanks for your effort, but you can disregard the stack of haskell-* failures; I'm on top of that transition, but there are a number of layers involved.  It's likely to just be a waste of time to parachute into the middle of it.
<cjwatson> hjd: I'm working through http://people.canonical.com/~ubuntu-archive/transitions/ghc.html; currently stalled on fixing haskell-quickcheck so that agda can build on powerpc, which I've fixed in Debian and will be able to sync to Ubuntu later today.
<cjwatson> hjd: Basically this happens because every time a Haskell package changes its ABI you have to go around rebuilding everything on top of it, and there's a very deep graph.  This is usually best done in batches to avoid wasting too much builder time.
<cjwatson> haskell-data-lens-template is quite far down the graph.
<cjwatson> Though only a handful of layers away now.
<hjd> cjwatson: Ok, I see. :) I wasn't aware the underlying issue was affecting the whole stack.
<hjd> cjwatson: I'm just skimming the FTBFS from time to time looking for low-hanging fruit.
<hjd> *page
#ubuntu-devel 2015-08-03
<codepython777> has anyone recently bought a laptop here? I'm looking to buy a good ubuntu laptop. Had my eye on dell xps 13 - but that has been discontinued for now.
<pitti> Good morning
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&amp;gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&amp;gt; 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
<seb128> hey dholbach, enjoy ;-)
<dholbach> thanks
<Noskcaj> dholbach, 3.8.3 is the newest non-bluez5 version
<dholbach> ah ok
<Noskcaj> It just brings in a few bug fixes, but it would be nice to have
<dholbach> right
<Noskcaj> We're discussing bluez5 in -desktop now, it will happen later this cycle if we can get the manpower finally
<dholbach> Noskcaj, do you have a link to the source package of 3.8.0-2?
<Noskcaj> I thought i got the merge up to 3.8.3-1
<Noskcaj> https://download.gnome.org/sources/gnome-user-share/3.8/gnome-user-share-3.8.3.tar.xz
<Noskcaj> https://download.gnome.org/sources/gnome-user-share/3.8/gnome-user-share-3.8.0.tar.xz if not
<dholbach> the source package
<dholbach> like the .dsc file and everything
<Noskcaj> oh, no. I just got it from the pkg-gnome tags
<dholbach> mh
<dholbach> nevermind... http://snapshot.debian.org/package/gnome-user-share/3.8.0-2/
<doko> seb128, I saw you didn't forward libproxy to debian. are there other uploads which are not yet forwarded?
<seb128> doko, yes, I didn't manage to go through all the diffs on thursday and I was on friday, I'm going to do the remaining ones after lunch
<doko> thanks
<hron85> Hi, anyone can help me with working with quilt? I made an upgrade for a package and now I have a non-applying patch. However, I cannot refresh it, since it does not apply and quilt do not want to move to this patch until it does not apply
<hron85> quilt refresh <patchname> does not work
<pitti> Laney: in case you had some config or other files: I just redeployed the entire autopkgtest cloud stuff from scratch
<Laney> pitti: nope, maybe stuff in shell history that'll be gone though. :P
<pitti> Laney: I did some work this morning to add basenode/ksplice/landscape/two nova configs, and wanted to re-test the whole thing before we switch to production
<Laney> what is basenode?
 * Laney can't quite google it up
<cjwatson> hron85: quilt push -f, resolve conflicts (it should tell you about where they are, and IIRC there'll be the usual patch-conflict <<< === >>> markers in the conflicted files), quilt refresh
<cjwatson> hron85: assuming that your starting point is a consistent tree whose quilt state is at the patch immediately below the non-applying one
<hron85> cjwatson: yep, it solved my problem, thanks
<hron85> cjwatson: yes, I knew the not-applying patch will be the next, but i did not found any way to move to it, since quilt refresh <patchname> rejects to work if the mentioned patch is not applied yet.
<jhenke> does anybody know if someone is working on the proposed gnupg 2.1.x as default? I did not see anything since the original message and I wondering if I missed some message
<ricotz> StevenK, hi, a gcc5 rebuild of aptitude please :)
<ricotz> ah sorry, slangasek ^
<cjwatson> hron85: right, in general I think it's best to avoid quilt refresh's mode where it takes a patch name - it's conceptually very confusing
<Laney> seb128: doko: do you want help with rebuilds/uploads? if so, where?
<doko> ricotz, current ftbfs
<doko> Laney, see slangasek's message on -release
<Laney> hmm, I don't have one
<Laney> nor on the archive
<Laney> link?
<doko> Laney, #ubuntu-release
<Laney> still unclear
<Laney> I see the individual transitions - should I take one and work on it?
<Laney> + checking your build logs for ABI changes
<ricotz> doko, oh, I see
<alkisg> mitya57: hi, I'm trying to look into the gnome-flashback keyboard layout applet issue, is the problem there that the existing applet doesn't respond to layout changes reported by xorg?
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&amp;gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&amp;gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> seb128, Laney: just updated to wily. the handles for the terminals don't exist. is this expected?
<doko> also when trying to update to wily-proposed:
<doko> The following packages will be REMOVED:
<doko>   aptitude compiz compiz-gnome compizconfig-settings-manager libasprintf0c2 libcompizconfig0 libdouble-conversion1 libllvm3.6 libmirclient8 libprotobuf9 libproxy1 libtag1-vanilla libxapian22
<doko>   mumble python-compizconfig python-xapian signon-ui signon-ui-x11 software-center tasksel tasksel-data ubuntu-desktop unity unity-control-center-signon unity-tweak-tool
<doko>   webaccounts-extension-common xul-ext-webaccounts
<seb128> doko, the scrollbar issue is known I think, Laney has the details
<seb128> doko, compiz/unity rebuild/fixes for gcc5 are in silo43 it seems, check with bregma when he plans to land it I guess
<seb128> dunno about aptitude mumble etc
<doko> bregma, ^^^ ???
<bregma> doko, there's an issue with one of the branches landing that still needs to be retested, then I'm landing that silo as soon as I can
<doko> ta
<bregma> it's been a game of whack-a-mole getting everything to build
<doko> bregma, are there any other silos needed?
<bregma> doko, that silo installs OK as long as -proposed is enabled, so not for the Unity stack as far as I know
<pitti> Laney: FYI: https://code.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud (moved from ~pitti)
<doko> jamespage, zul, roaksoax, smoser: there doesn't seem to be any progress on the ruby dep-waits ...
<pitti> apw: not sure if you actually still need this, but http://autopkgtest.ubuntu.com/data/packages/wily/amd64/l/linux/latest.json (and all other JSONs) have URLs to the swift artifacts nwo
<apw> that looks useful, even if i don't use it, though i suspect i will
<cjwatson> doko: which ruby dep-waits are those, the ones on gem2deb?
<cjwatson> doko: because if so (and they quite probably involve gem2deb somewhere), don't hassle the server team about it, needs the next launchpad-buildd rollout because gem2deb started making use of build profiles
<doko> cjwatson, ruby-hashie, ruby-rspec, ruby-safe-yaml, ruby-test-unit
<doko> ahh, ok
<cjwatson> doko: there might be some MIRs buried in there too
<doko> dpkg-gencontrol: warning: can't parse dependency libxapian22 (>= 1.2.21)v5
<doko> hrm,
<cjwatson> ah, no, just misleadingly wrong dep-waits I think
<cjwatson> doko: certainly at least ruby-hashie and ruby-rspec will be ultimately fixed by new buildd, haven't checked them all
<cjwatson> hopefully I'll get a review of https://code.launchpad.net/~cjwatson/launchpad-buildd/snapcraft/+merge/266541 soon and then I can start the release process
<doko> ok, good to know ... still we should address the dep-waits too
<cjwatson> doko: what kind of addressing are you talking about?
<doko> writing MIR's, dropping b-d's etc
<cjwatson> doko: well, some of the dep-waits you see are bogus
<cjwatson> so it's probably not worth chasing any of that down until the buildds are fixed
<doko> sure, but I doubt that the perl team uses these too
<cjwatson> doko: ruby-test-unit -> ruby-power-assert looks like a real MIR case
<cjwatson> doko: perl example?
<doko> see http://qa.ubuntuwire.com/ftbfs/
<cjwatson> ok, sure, there's probably a bunch of MIR handling to be done there
<Laney> doko: handles? we changed the scrollbars and there's a problem with the terminal's widget but the thumb is gone if that's what you mean
<Laney> you can still scroll it but it's annoying to make it go big
<Laney> pitti: ah, cool
<Laney> pitti: do you plan to document the architecture? :)
<pitti> Laney: yes, of course
<doko> Laney, indeed very ugly
<Laney> pitti: great - I'm currently still a bit sketchy and would be scared if I had to (e.g.) redeploy it :P
<Laney> doko: we will try to tweak more before release
<pitti> Laney: heh, sure; indeed there is one remaining bug for complete re-deployment
<pitti> (bug 1480962)
<ubottu> Error: Could not gather data from Launchpad for bug #1480962 (https://launchpad.net/bugs/1480962). The error has been logged
<pitti> Laney: once that's fixed, it will become really simple; I'll write documentation of all of that once it's all in place
<Laney> yay
<pitti> tseliot: hmm, seems something broke the fglrx driver? http://autopkgtest.ubuntu.com/packages/u/ubuntu-drivers-common/wily/amd64/
<tseliot> pitti: having an actual build log would help. I'll try it here, thanks
<pitti> tseliot: yeah, we should fix those tests to cat the build log on failure
<tseliot> pitti: that would be nice
<smoser> bdmurray, i gues you're not awake...
<smoser> https://code.launchpad.net/~smoser/ubuntu-reports/trunk.fix-server-merges/+merge/266745
<bdmurray> smoser: I am actually and in a meeting. I'll have a look shortly.
 * pitti waves good night
<smoser> bdmurray, ok. thanks. and then kick the report generation if you could.
<tseliot> pitti: the module built but I see two architectures in my chroot: dkms status
<tseliot> fglrx-core, 15.200.1, 4.1.0-3-generic, amd64: installed
<tseliot> fglrx-core, 15.200.1, 4.1.0-3-generic, x86_64: installed
<pitti> tseliot: did you enable -proposed?
<tseliot> pitti: not really
<tseliot> pitti: this is all I have http://paste.ubuntu.com/11993942/
<pitti> tseliot: i. e. it's plausible that it fails due to gcc 5; /me tries in a chroot with -proposed
<tseliot> pitti: gcc -v reports "gcc version 4.9.2 (Ubuntu 4.9.2-17ubuntu1)"
<pitti> tseliot: right, and in -proposed we switched to 5.
<tseliot> pitti: right, but I don't have -proposed enabled
<tseliot> so it must be something else
<tseliot> or maybe the failure is a separate issue and/or a false positive
<pitti> (wily-amd64)root@donald:/home/martin# modprobe fglrx
<pitti> modprobe: ERROR: could not insert 'fglrx': Unknown symbol in module, or unknown parameter (see dmesg)
<pitti> [  404.772855] fglrx: Unknown symbol amd_iommu_bind_pasid (err 0)
<pitti> [  404.772925] fglrx: Unknown symbol amd_iommu_set_invalid_ppr_cb (err 0)
<pitti> [  404.773082] fglrx: Unknown symbol amd_iommu_set_invalidate_ctx_cb (err 0)
<pitti> [  404.773170] fglrx: Unknown symbol amd_iommu_unbind_pasid (err 0)
<pitti> [  404.773265] fglrx: Unknown symbol amd_iommu_init_device (err 0)
<pitti> [  404.773372] fglrx: Unknown symbol amd_iommu_free_device (err 0)
<pitti> tseliot: ^ I get that with -proposed
<tseliot> pitti: ok, so it's not a build error. It looks like fun. I'll fix it, thanks
<pitti> tseliot: hm, I get the same without -proposed
<pitti> it started failing on Aug 1
<tseliot> maybe the ABI broke somehow?
<pitti> tseliot: hm, maybe this is normal in a chroot; that's not what the test fails on
<pitti> so this needs a closer look
<mitya57> slangasek, ScottK is right â only the plugin(s?) are built against default python3, everything else is built against all supported versions
<mitya57> (sorry for the delay btw)
<tseliot> pitti: yes, I'll test it on a real system
<pitti> tseliot: cheers
<mitya57> alkisg, hi, if by "existing applet" you mean indicator-keyboard, then it doesn't support xkb switching. It listens to gsettings changes on org.gnome.input-sources (that are done by g-s-d or u-s-d).
<mitya57> And that should work fine in Ubuntu (unlike Debian or upstream).
<alkisg> mitya57: it works here in 14.04, but not in 15.10
<alkisg> I can use indicator-keyboard with the mouse to change the language, but I can't use any keyboard shortcut to change it
<alkisg> Even though gsettings are the same as in 14.04 when it worked
<alkisg> mitya57: so the plan is for someone to write such an applet, and then use it in all variants, upstream, debian and ubuntu?
<alkisg> Or ubuntu will keep using indicator-keyboard?
<mitya57> alkisg, it's in our "patches welcome" list upstream :)
<mitya57> let me look at the code a bit
<alkisg> If you accept one that listens for *xkb* changes as well, instead of only for gsettings changes, it would be interesting... :)
<mitya57> alkisg, why do you still need xkb changes? GNOME upstream deprecated that and gsettings is much easier to use.
<mitya57> alkisg, also, do you have gnome-settings-daemon or unity-settings-daemon running?
<alkisg> mitya57: unity-settings
<mitya57> that should work fineâ¦
<alkisg> It doesn't... clean 15.10 installation
<alkisg> That was basically what I was worried about, I thought that it would be broken in ubuntu 15.10+, 16.04 etc like it is upstream...
<mitya57> Are you using modifiers-only keybinding or not?
<alkisg> The defaults, win+space
<alkisg> I also tried alt+shift which worked in 14.04, it doesn't work either
<mitya57> Does it list in gsettings get org.gnome.desktop.wm.keybindings switch-input-source?
<alkisg> <Super>space
<mitya57> Looks fine.
<mitya57> Is there a bug open in LP for it, and if no, can you please file one?
<alkisg> I'll check + file a bug, thanks,
<alkisg> about xkb changes, unfortunately gnome upstream breaks sdl apps, and we're trying to make things work as they were with xorg without gnome breaking them...
<mitya57> Can you also attach "gsettings list-recursively org.gnome.desktop.input-sources" to the bug, please?
<alkisg> E.g. in tuxpaint, tuxtype, we cannot type greek at all now with recent gnome versions, the last one to work fine for us was 12.04
<alkisg> mitya57: another issue that might need resolving,
<alkisg> I install ubuntu with greek layout in ubiquity etc. Then I create a user, and /home/user is empty
<andol> There is something off with the http://releases.ubuntu.com/vivid/ FOOSUMS files, and their corresponding FOOSUMS.gpg - http://paste.ubuntu.com/11994117/. In addition to gpg reporting BAD signatures there is also the oddness that the FOOSUMS files appear to have newer mtimes than their corresponding FOOFUMS.gpg.
<alkisg> If that user logs in, he has nothing in the layouts list, while it should be "us,gr"
<andol> (No idea where the proper place to report such an issue is)
<alkisg> So all users need to go to keyboard settings and add the layouts manually
<alkisg> I think this happens in all ubuntu gnome variants, while it doesn't happen in e.g. fedora... or of course in ubuntu <= 12.04
<mitya57> alkisg, please report that against the installer (i.e. if you use the graphic one, then it's ubiquity)
<alkisg> mitya57: I think the problem is that gnome doesn't respect the global xorg settings anymore
<alkisg> It's not about ubiquity... e.g. when one run `adduser x` after the installation, that "x" user doesn't get the xorg system default layout
<alkisg> *runs
<mitya57> alkisg, are you installing Ubuntu GNOME?
<alkisg> No, plain ubuntu and then gnome-flashback
<alkisg> It's been that way since 14.04. It was working in 12.04
<alkisg> I've been filling a lot of bug reports about these issues, but they didn't draw much attention...
<mitya57> This is first time I hear about this issue.
<mitya57> :)
<alkisg> :)
<mitya57> It looks like it's not specific to GNOME Flashback, so try sending a mail to ubuntu-desktop@lists.ubuntu.com
<mitya57> There are people who should know what component to blame
<alkisg> The long story is that ubiquity, lightdm, accountsservice, gnome-settings-daemon, unity-settings-daemon, and a couple of other applications don't work with multiple keyboard layouts since 13.04 or so
<alkisg> Let me try the indicator with unity...
<alkisg> mitya57: I think that the "indicator doesn't change on layout changes by keyboard shortcuts" is specific to flashback, in unity it's working fine
<alkisg> And it broke after 14.04
<alkisg> The 10+ rest issues about layouts are not specific to flashback, but they are specific to ubuntu though... :-/
 * alkisg checks + files a bug for that one...
<mitya57> alkisg, does the gsettings key (i.e. org.gnome.desktop.input-sources current) change when you toggle the keybinding?
<alkisg> unity => yes, moment for flashback...
<alkisg> metacity => no, moment for compiz...
<infinity> pitti: Did I ever get those trusty langpacks?
<alkisg> mitya57: gnome-flashback (compiz) gives me unity without the top panel... go figure :)
<mitya57> alkisg, metacity is enough, that indicates that the problem is not in the indicator, but in unity-settings-daemon
<mitya57> the fix for compiz will be in next compiz upload :)
<alkisg> mitya57: hope you don't mind me asking, are you using the flashback+metacity session yourself in production?
<alkisg> We're using gnome-flashback in 1000+ schools here, but I was wondering if mate would be more appropriate, considering the old hardware...
<alkisg> gnome-flashback feels like the best choice, considering it's closer to upstream gnome, but it also feels understaffed... :)
<mitya57> Yes, we are quite lacking resources
<mitya57> Actually I do just packaging (don't have time for anything else), all upstream work is done by 1.5 people :)
<alkisg> Yes fortunately Alberts is doing the bulk of the work... but mitya57, are you using it in production somewhere? Or is it just your preferred DE?
<mitya57> Many my friends use it :)
<alkisg> Nice :)
<mitya57> Also I set it up in a school some time ago, not sure if they are still using it
 * mitya57 keeps accidentally pressing Ctrl+Q
 * alkisg wonders where "ibus" fits in all this... it's preinstalled, and previously it was not running by default, and now it is...
 * mitya57 doesn't know anything about ibus
<alkisg> mitya57: should I file the bug against indicator-keyboard (Ubuntu), or against unity-settings-daemon?
<alkisg> I.e. that it works in unity but not in flashback
<mitya57> alkisg, unity-settings-daemon, and also add https://launchpad.net/ubuntu-gnome-flashback as a subtask
<alkisg> Thanks, trying...
<doko> why is xapian-bindings ftbfs on the buildds ...
<doko> bregma, so even with your landing PPA enabled, I can't upgrade
<alkisg> mitya57: I've filed LP #1481025
<ubottu> Launchpad bug 1481025 in unity-settings-daemon (Ubuntu) "Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback" [Undecided,New] https://launchpad.net/bugs/1481025
<Mirv> cyphermox: thanks for the new wpa! fwiw it does not seem there is stated delta anymore to Debian's debian/config/wpasupplicant/linux, other than the fact that Ubuntu has the settings specified twice + there is unmentioned Android config delta
<cyphermox> Mirv: are you saying I forgot to re-add the android crap in changelog?
<cyphermox> looks to me like it's there
<mitya57> alkisg: thanks
<alkisg> Tthank _you_ :)
<doko> Noskcaj, qqwing accepted in -proposed
<hjd> cyphermox: Thanks for packaging. :) I suppose it's too late to mention it in the changelog, but would you mind leaving a comment on bug 1370245?
<ubottu> bug 1370245 in wpasupplicant (Ubuntu) "wpa_supplicant version 2.2 available" [Undecided,Confirmed] https://launchpad.net/bugs/1370245
<Mirv> cyphermox: the section stating remaining changes in debian/config/wpasupplicant/linux from Debian mentions the two options that are double stated in that file but does not mention the CONFIG_ANDROID_HAL=y which is the only actual delta in that config
<cyphermox>   - debian/config/wpasupplicant/linux: enable CONFIG_ANDROID_HAL.
<Mirv> cyphermox: I mean, oh, right, it's up there. then the later mention is just unneeded + the config file should be cleaned since the delta is actually now this http://paste.ubuntu.com/11994721/
<cyphermox> nah
<cyphermox> *bah
<Mirv> so CONFIG_P2P and CONFIG_AP are repeated in Ubuntu's version
<cyphermox> Mirv: how about that. Feel free to clean it up if you want to
<hjd> jjohansen: Hi :)
<jjohansen> hjd: hello
<hjd> jjohansen: Sorry for the random ping, but I saw bug 1481039 and wondered whether the linux-lts-backport-maverick and -natty tasks are included for completeness, since they don't seem to be part of any current Ubuntu release.
<ubottu> bug 1481039 in linux-manta (Ubuntu Wily) "CVE-2015-5697" [Low,New] https://launchpad.net/bugs/1481039
<jjohansen> hjd: its actually because I need to do some updates to the tooling we use so we can drop those
<hjd> ok :)
<doko_> desktop updated to wily-proposed + landing-043. seems to work again \o/
<infinity> doko_: Impressive.
<Laney> oh, they fixed the arm64 FTBFS of $package
<Laney> SHIP IT.
<doko_> apt-get dist-upgrade removes gnome-control-center, but you can install it again. only thing missing is aptitude
<Noskcaj> Logan, Would you mind checking the sponsors queue for stuff before you merge? I had a finished merge for light-locker waiting, so there was a bit of an overlap of work. That said, i should have asked you if i could merge it
<Laney> doko_: If you can get an easily understandable list of work to be done then I can help out tomorrow
<Laney> like 'rename these packages' or 'rebuild/fix for these transitions'
<doko_> I'm trying, need to prepare for travel tomorrow as well
<doko_> I mean, you could starting to rebuild stuff for icu and boost in main
<Laney> I also don't want to clash/duplicate
<Laney> so some pad/wiki would be nice
<doko_> Laney, coordinate with slangasek; I think I won't do much tomorrow
<ari-tczew> cjwatson: shouldn't the fakesyncs be synced automatically?
<ari-tczew> cjwatson: nvm, due to mismatch tarballs isn't possible, but I think fakesyncs should be on MoM visible...
<ari-tczew> correct me if I'm wrong
<doko_> cyphermox, you still involved with libcolumbus?  could you have a look at the ftbfs?
<doko> Noskcaj, pyicu 1.8 ftbfs with ICU 55. updated to 1.9.2
<Noskcaj> doko, I'll update it in debian python svn today
<doko> ta
<infinity> robert_ancell: Hey, do you know of anyone (perhaps you?) who could verify the SRU for https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1410801 ?
<ubottu> Launchpad bug 1410801 in HWE Next "[AMD Richland + Topaz XT ] gpu-manager generated xorg.conf is not compatible with switchable graphics" [Medium,Confirmed]
<robert_ancell> infinity, I don't have any AMD hardware, sorry
<mwhudson> go 1.5 prep feels like http://media.giphy.com/media/MRUj8R8SMWlIk/giphy.gif today
<infinity> mwhudson: You keep getting attacked by a vicious cat?
<mwhudson> not entirely what i was trying to convey, no
#ubuntu-devel 2015-08-04
<cyphermox> doko: yes, was going to
<cyphermox> I was never really involved in it though ;)
<mwhudson> Setting up golang-go (2:1.5~snap~upstream201508020934gitc2db5f4ubuntu3) ...
<mwhudson> update-alternatives: using /usr/lib/go/bin/go to provide /usr/bin/go (go) in auto mode
<mwhudson> update-alternatives: warning: not replacing /usr/bin/go with a link
<mwhudson> sounds bad
<lifeless> win 31
<infinity> mwhudson: You can't use alternatives unless all the packages particpating play along.
<mwhudson> yeah
<infinity> mwhudson: As in, no one can ship the actual path. :P
<mwhudson> i'm just wondering which package isn't playing along
<infinity> mwhudson: dpkg -S /usr/bin/go ?
<mwhudson> infinity: on a builder? :-)
<infinity> Well, install all the build-deps, then dpkg -S?
<mwhudson> i think i know which package it must be though
<infinity> But it's probably gccgo, or some wrapper.
<mwhudson> nah not this time, i think it's my golang-x-tools package
<mwhudson> yeah that's completely messed up
<Logan> Noskcaj: you're frustrated that I did a merge for a package where I TIL and didn't realize that you had proposed a merge without asking me first? :P
<Logan> (that was awkwardly phrased)
<mwhudson> so my earlier hilarity was caused by a bit of rules that did approximately "cd directory; find -exec install \{} $(CURDIR)/debian/tmp/usr/bin/\{} \;"
<mwhudson> and directory not existing
<sarnold> owwwwwwww
<pitti> Good morning
<pitti> infinity: langpacks> erk, no -- still no full export on https://translations.launchpad.net/ubuntu/trusty/+language-packs
<pitti> wgrant: ^ can you run this manually?
<pitti> (I asked last Thursday, but it apparently fell through the cracks; shouldn't have used IRC, sorry)
<wgrant> pitti: Sure, will get that kicked off.
<pitti> wgrant: thanks
<wgrant> pitti: It's running.
<pitti> wgrant: yay; should be a handful of hours?
<wgrant> pitti: I think so.
<pitti> I'll check https://translations.launchpad.net/ubuntu/trusty/+language-packs every hour or so and then build new trusty langpacks
<pitti> infinity: oops, this Thu already? do you still actually want the new packs?
<Guest28692> Hi..
<Guest28692> I was trying to join the ubuntu development team.. and I went to the link https://wiki.ubuntu.com/BeginnersTeam/Membership
<Guest28692> It says that this page is deprecated it gave a link to https://lists.ubuntu.com/archives/ubuntu-beginners/2013-August/002541.html
<Guest28692> and this link is broken..
<Guest28692> am I going to the right link??
<sarnold> Guest28692: looks like it, archive.org has a copy: https://web.archive.org/web/20140817091812/https://lists.ubuntu.com/archives/ubuntu-beginners/2013-August/002541.html
<Guest28692> oh!!
<Guest28692> it says the community is dead..
<Guest28692> what should I do then??
<Guest28692> It says it should check ##ubt-survivors
<sarnold> it dpends on what you want to work on :)
<Guest28692> I want start with testing packages..
<Noskcaj> Logan, well now you say it like that...
<Guest28692> I am C++ developer .. socket programming , system prgramming..
<Guest28692> etc..
<sarnold> Guest28692: aha :) cool
<Guest28692> I am joining the ##ubt-survivors chat room and let's see what comes out of it
<sarnold> Guest28692: there's a few different types of tests, tests during package builds (usually just upstream's tests), autopkgtest (which are more distribution-oriented..), doing stable release update tests to get updated packages into the archives...
<sarnold> Guest28692: check this out http://packaging.ubuntu.com/html/auto-pkg-test.html
<sarnold> Guest28692: and this https://wiki.ubuntu.com/StableReleaseUpdates
<Guest28692> Hmm..
<Guest28692> sarnold: One of my mentors suggested me to go this way.. what would you suggest me to do.. to have a head start..
<infinity> pitti: Might be a bit late now.  I was expecting them Friday, so we could spot-check over the weekend.
<sarnold> Guest28692: do whatever is fun enough that you'll want to work on it, and challenging enough so that you still enjoy it in a few months or years..
<pitti> infinity: ok; if you don't have troubles with overflown images, it's not such a big deal -- we can SRU them after .2
<infinity> pitti: But you know langpacks better than I.  If we can test them in any meaningful way before I inevitably have to respin images in a day or two, I'm all for fresh strings.  If not, let's not risk breaking the world.
<infinity> pitti: Image size isn't really a concern, it's just nice to have better installer coverage.
<infinity> pitti: Though, I guess that updates from the interwebs anyway if you're online when isntalling.
<pitti> infinity: we can't test them automatically aside from me looking at binary debdiff and string diffs (but that won't be meaningful for most languages)
<pitti> we have some manual test plan, but that'll get too tight as it depends on lots of community help
<infinity> pitti: Kay, let's skip it.  I'd rather a few out of date strings than a catastrophe due to lack of timely testing.
<pitti> ack
<pitti> sorry for the bad timing
<infinity> pitti: Life goes on.
<infinity> pitti: I will quit ~we-love-pitti for two days before I rejoin.
 * pitti breaks out in tears
<infinity> Oh man, too much QA + dyslexia for tonight's hilarious misreading.
<infinity> I saw "* pitti breaks out in tests"
<pitti> oh, I'm breaking these too :)
<sarnold> poor poor infinity
 * pitti is currently rolling out britney, take II
<pitti> this time with better preparation
<infinity> tjaalton: This bug is all over the map, do you have any input (hah, input!) on the matter? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics-lts-vivid/+bug/1481104
<ubottu> Launchpad bug 1481104 in xserver-xorg-input-synaptics-lts-vivid (Ubuntu) "synaptics does not load in live session for my laptop " [Undecided,New]
 * pitti drops the "Would be considered, but pitti disabled promotion for one run" local hack from britney.py and dives in fully
<dholbach> good morning
<tjaalton> infinity: can't check before my evening..
<tjaalton> sounds weird though
<tjaalton> no xserver log to show if the driver is loaded
<tjaalton> and it should fall back to evdev
<Laney> pitti: is this the big switch?
<pitti> Laney: yes, it was
<Laney> \o/!
<pitti> and seems I didn't flunk it this time
<Laney> I'll miss you, d-jenkins.ubuntu-ci
<pitti> it still runs boottests :)
<Laney> yeesh, those
<pitti> we need to find someone who owns them these days and make them install the new worker
<Laney> try f_ginther
<Laney> They also need some improvements like unpacking/upgrading/repacking the image instead of trying to use apt on it directly
<cjwatson> ari-tczew: not useful to have them on mom; they're in auto-sync output
<ari-tczew> cjwatson: I had a case, there was a package with versioning -1fakesync1 and Debian released -2. In this case we don't know that package needs to be fakesynced. (someone just subscribed me to the bug report on LP)
 * ari-tczew needs to go out
<doko> seb128, Laney: is SweetShark available?
<seb128> doko, he should be yes
<seb128> having libreoffice/gcc5 issues?
<Laney> don't see him on IRC
<doko> yes, libcmis test failures
<seb128> he might not be up yet
<seb128> or there is an IRC split...
<ochosi> doko: now he's around ;)
<doko> ochosi, where?
<ochosi> at least in #u-desktop
 * doko thinks slangasek would make a perfect fit as a debian-med, debian-science and debian-chem maintainer =)
<cjwatson> those sound like fighting words :-)
<Laney> bdmurray: seems http://reqorts.qa.ubuntu.com/reports/rls-mgr/?C=M;O=D has stopped updating
<Laney> (is that yours?)
<Daviey> Laney / bdmurray: Seems that machine was upgraded to Trusty, as it broke one of the ubuntu-server reports that used a changed interface of python-apt. Could be related.
<Laney> Daviey: Ah, good clue
<Laney> ha
<Laney> was just about to run slangasek's script, noticed dput at the end
<pitti> Laney: I dia'ed together an initial overview on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure ; I'll flesh this out with description of every component in the next days
<Laney> pitti: nice, thanks!
<Laney> seb128: any tips before I start trying to upload renames?
 * Laney has a big directory of source packages now
<Laney> I guess test build, manually check the diff
<Laney> but anything special about ordering?
<Laney> or doko ^
<doko> Laney, I think slangasek did test builds before upload
<Laney> right
<Laney> I'm just wondering if there is anything else I need to be aware of
 * Laney wants a "build these packages in the cloud" script
<Laney> submit request, go away, come back to lovely emails and SSHable instances for failure cases
<Odd_Bloke> I've just emailed ubuntu-devel with a request for help validating an SRU; if someone could ACK it, it'd be appreciated.
<Laney> Odd_Bloke: Approved, & note that you are allowed to self-verify SRUs
<Odd_Bloke> Laney: Yeah, we don't have access to an appropriate environment :(; the person who helped us validate the upstream cloud-init fix has disappeared.
<Odd_Bloke> Laney: (And thank you!)
<Laney> icu seems to be stuck in haskhell
<pitti> apw: wow, that initramfs-tools delta reads scary :)
<Laney> that's a nice merge!
<pitti> I'm quite some some delta is unnecessary now, but scary as this was let's land this first :)
<pitti> apw: ah, so 0.119 runs fsck on the root fs by itself already, and thus /run/initramfs/fsck-root exists, and thus systemd-fsck-root.service doesn't get run
<pitti> that's actually intended
<pitti> so it seems the autopkgtest needs to be adjusted
<doko> jamespage, python3-linecache2 - backports of the linecache module - Python 3.x
<doko> seriously?
<doko> same for python3-traceback
<doko> d-shlibmove(1):
<doko>        --c102
<doko>               Add c102 suffix to package names, for C++ ABI transition.
<doko>               Added in version 0.8
<doko>        --ldbl
<doko>               Add dbl suffix to package names.
<doko>               Added in version 0.35
<doko> \o/
<doko> die, die, die ...
<seb128> Laney, not really no
<Laney> ok
<Laney> I have a big sbuild making my computer cry atm
<seb128> is there many renames remaning?
<Laney> I have 86 dscs here
<Laney> the script skipped packages with .symbols files
<Laney> http://paste.ubuntu.com/11999484/
<seb128> crazyness
<Laney> those are ones people could help with
<seb128> k
<Laney> flac was just done in Debian
<Laney> I see doko pinging about some others in #debian-ftp
<Laney> doko: got a list so I can avoid uploading those?
<seb128> I keep a note about that, but still fighting device issues and I want to deal with bluez5 this week
<Laney> ok
<doko> Laney, sorry, don't have one
<doko> Laney, slangasek: skip llvm-toolchain-snapshot, we don't care, and it's -proposed only. qtwebkit-opensource-src and qttools-opensource-src were already done by Mirv. not sure about qt-gstreamer
<doko> kdepimlibs is hopefully handled by Riddell / Kubuntu
 * Mirv is not familiar with qt-gstreamer, not used by phone either
<Laney> doko: edit http://pad.ubuntu.com/gcc-5-transition ?
<Laney> delete/mark those lines or something
<Laney> http://paste.ubuntu.com/11999517/ <- that's what the script gave me to upload
<doko> Laney, projectm is already in experimental
<Laney> ok thanks, deleting that one
<pitti> apw: hm, new initramfs-tools doesn't provide the plymouth-y fsck integration we used to have
<doko> maybe check the others too
<Noskcaj> doko, I didn't get to pyicu today, will get it first thing tomorrow. It is just a version bump though AFAIK
<pitti> apw: difficult thing that -- OTOH this is a rather obnoxiously difficult thing to do especially in initramfs, for an ever-waning benefit
<pitti> apw: ext stopped doing regular fscks long ago (on new installs), and xfs, btrfs etc. don't do these either; so the more interesting question is what happens if the check fails
<Laney> doko: what can I check? Depends "libstdc++6 (>= 5"?
 * Laney will grep-dctrl
<pitti> apw: we still need to keep the userspace fsck stuff for non-root partitions, but it seems with the "check root fs from initramfs" approahc we need to duplicate it?
<Laney> bah, and NEW too
<doko> Laney, maybe just if the package builds a binary ending with v5 ...
<Laney> might not catch where transitions happened anwyay
<Laney> qpdf is the only one in NEW that I have there, /me deletes that
<Laney> and ScottK accepted that one (thanks)
<ScottK> Actuall it wasn't me, we had a race condition on the FTP team and someone else accepted it while I was busy filing an RC bug for missing debian/copyright stuff.
<Laney> OK, no thanks for you then. :P
<ricotz> doko, do you have a log of your libreoffice ftbfs?
<doko> ricotz, still ftbfs because of not yet rebuilt b-d's.  Ask Sweet5hark on #ubuntu-desktop, this guy doesn't want to cooperate here on this channel :-/
<doko> ricotz, and I'm told that libcmis tests are failing, so if you want to have something for fixing ...
<ricotz> doko, i pushed a rebuild to my ppa
<ricotz> https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+build/7756288
<doko> ricotz, waste of resources ...
<ricotz> doko, did you changed the packaging?
<doko> ricotz, -> Sweet5hark
<pitti> apw: ah, debian bug 783291 causes the "intra-OS" fsck to run again, that's why the test fails there
<ubottu> Debian bug 783291 in initramfs-tools "/bin/touch is missing if built with BUSYBOX=n or busybox package not installed" [Important,Open] http://bugs.debian.org/783291
<ricotz> doko, I am asking you, so you did a no-change rebuild?
<ricotz> of 1:4.4.4~rc3-0ubuntu1
<ricotz> (fyi the ppa build is 4.4.5~rc2)
<doko> ricotz, no, I did not, because I trust the person telling me that b-d's aren't yet rebuilt
<ricotz> doko, ok
<jamespage> doko, this got discussed on the debian python ML - https://lists.debian.org/debian-python/2015/07/msg00006.html
<jamespage> doko, I'm not sure I can read a consensus decision on whether the python3 versions of backports have a place or not; but as they use a different namespace, there are come compelling arguments both ways :-)
<doko> jamespage, sure they have a different namespace, but in the past this was handled conditionally in the using code
<apw> pitti, ahh ok, is there a fix on that one already ?
<apw> pitti, and thanks
<apw> pitti, ahh yes, there is a proposed work-around in there which i'll give a go
<Laney> doko: http://paste.ubuntu.com/11999715/ <- should be packages needing rebuild/transition that are fixed in debian
<doko> infinity, were you working on shellcheck?
<Laney> i.e. sync/merge these
<doko> Laney, ahh, csound is done
<doko> and see slangasek rants^Bcomments on hdf5
<Laney> heh
<Laney> ahh, we don't have Source: for all binaries in our Packages files
<cjwatson> Source defaults to Package if missing
<Laney> Yeah, need to tweak the logic to know that
<Laney> Know an easy way to do that with grep-dctrl?
<Laney> or does grep-dctrl do it already?
<Laney> -S
<doko> cjwatson, shellcheck is maintained by the Debian Haskell group =) now wanted by d-shlibs and dh-exec
<doko> do you want to write a MIR?
<cjwatson> doko: no
<doko> i feared that
<cjwatson> doko: it's not my problem if somebody starts pulling it in :)
<cjwatson> Laney: as you say
<doko> ohh, and written in haskell, so I'll disable running the tests for these
<Laney> no, that's for selecting input fields, not output
<cjwatson> doko: disable tests for which packages?
<doko> d-shlibs and dh-exec
<cjwatson> right, that makes sense
<cjwatson> Laney: -sSource:Package
<cjwatson> "A field specification can contain a colon.  In such a case, the part up to the colon is taken as the name of the field to be shown, and the part after the colon is taken as the name of the field whose content is to be used if the field to be shown is empty."
<Laney> Yeah, I think this works
<doko> infinity, ohh, no that was bats
<ricotz> I assume if a rebuild generates a hard-dep on "libstdc++6 (>= 5.2)" it requires a package-rename
<ricotz> Laney, if you like you can add libixion
<Laney> looks to be done in debian
<sbeattie> pitti: do you know what's up with https://jenkins.qa.ubuntu.com/job/wily-boottest-apparmor/lastBuild/artifact/results/log/*view*/ ? Looks like a test infrastructure issue to me, can you re-run?
<pitti> sbeattie: yes, I can re-run; besides keep hitting the retry button I don't know much about these boottests, I'm afraid
<pitti> sbeattie: I'm working on the systemd test regression BTW
<pitti> sbeattie: if it's urgent, I can ignore that and let apparmor propagate
<pitti> it's the new initramfs-tools which breaks it, not apparmor
<sbeattie> not urgent, just wanting to know if it's a legit failure.
<pitti> sbeattie: the bootest just looks like a glitch; let's see if it works now
<sbeattie> pitti: okay, thanks.
<doko> kenvandine, just curious, why were the no-change rebuilds for platform-api necessary?
<kenvandine> doko, it had a depends on libubuntu-location-service2
<kenvandine> it was built before the transition to libubuntu-location-service3
<kenvandine> doko, i think that's the culprit causing stuff to get removed in the boottests
<doko> kenvandine, yes, but the problem that these two packages have direct cyclic build-dependency
<kenvandine> doko, oh... that's not cool
<doko> told tvoss about it
<tvoss> doko, yup, wasn't aware that this is causing problems like this, sorry
<tvoss> kenvandine, so does a rebuild of platform-api fix the issue?
<kenvandine> i thought it would fix the depends issue
<kenvandine> at least i thought it was simple :)
<pitti> apw: fix for the "touch not found" bug? yes, it's attached to that bug and very simple; doesn't affect our cloud images as (I suppose) they have busybox, or something else which gets "/bin/touch" into the initramfs
<pitti> apw: anyway, as far as the systemd-fsckd test goes, I'll just skip it iff /run/initramfs/fsck-root exists
<pitti> sbeattie, apw: adjusted systemd fsckd test uploaded, so autopkgtest should succeed again
<apw> pitti, ok, i'll get that fix applied as well when i am done fixing casper
<pitti> apw: it's not urgent raelly
<pitti> apw: I think the more "interesting" discussion is what we want to do with fsck and plymouht
<apw> pitti, yeah, surely it is all perfect after all systemd is doing it now ...
<pitti> apw: ?
<pitti> (that's the point -- with current initramfs systemd can't do it any more :) )
<pitti> sbeattie: that helped, re-run succeeded
<ricotz> doko, https://paste.debian.net/plain/289042
<apw> pitti, yeah, ok, so ... so we have a plan, or do we need to make one up
<pitti> apw: I don't have a plan/good idea right now
<pitti> apw: technically, fsck'ing the root fs in initramfs is a much more sensible thing to do than checking it from within an already mounted (although r/o) file system
<pitti> but of course the initramfs env is very limited, so you can't do much fancy stuff
<apw> but one needs a lot of heavy things hten, yeah that
<pitti> unless you have cryptsetup or similar, we don't currently even have plymouht in the initramfs
<pitti> I wouldn't mind putting it always there
<pitti> but all the fsck <-> initramfs plumbing isn't there
<doko> ricotz, thanks, uploaded
<pitti> Debian never bothered about it, but apparently we do (or at least did) wrt. pretty boot
 * pitti nods to didrocks
<doko> ricotz, hmm, shlibs file was wrong. fixed
<ricotz> doko, ah sorry
<Laney> doko: why no bug for movit?
<doko> Laney, forgot it? not sure, why I forgot some ...
<Laney> dunno
<Laney> and why no log for libcmis indicating that it needed fixing? :)
<Laney> about to upload first batch anyway
<doko> maybe it failed to build at this time?
<Laney> just worried about missing things
<bdmurray> Laney: I'm aware of the issue and it has to do with python-launchlib authorization tokens.
<dannf> hallyn: i told infinity i'd look at an SRU'ing the qemu-kvm support for arm64/ppc64el/etc back to trusty (LP: #1389897), and i finally got around to preparing one. wanted to get your opinion it...
<ubottu> Launchpad bug 1389897 in qemu (Ubuntu Trusty) "no way to install "enough qemu for kvm" in a cross platform way" [Undecided,Confirmed] https://launchpad.net/bugs/1389897
<Laney> bdmurray: ack!
<hallyn> dannf: will take a look, thx
<hallyn> guess infinity gave up on me :)
<dannf> hallyn: oh, heh. want me to push my patch and/or packages somewhere? it's just a cherry pick of the change in vivid
<ricotz> Laney, was libwpg on your list?
<Laney> ricotz: see http://pad.ubuntu.com/gcc-5-transition (no)
<Laney> and that is because https://launchpad.net/ubuntu/+source/libwps/0.4.0-2ubuntu1
<ricotz> Laney, alright
<slangasek> doko, Laney: test builds before upload> hahano.  The script checks for symbols files, everything else is uploading and letting the builders sort it out.  For that, the build failure rate is fairly low ;P
<bdmurray> cjwatson: I've forgotten how to create a token for launchpadlib that doesn't use "DESKTOP_INTEGRATION". Do you know?
<Laney> slangasek: I feel overly worried about hitting dput ...
<slangasek> Laney: the worst thing that can happen is that you're TIL
<Laney> getting close to doing it
<slangasek> Laney: do you have the last blacklist I posted on #-release?
<Laney> slangasek: yep, and I added some more that the script cried about
<slangasek> Laney: ok.  I should also post an updated version of the script
<Laney> http://paste.ubuntu.com/12000702/
<Laney> I've wrangled it a bit anyway
<slangasek> well, http://paste.ubuntu.com/12000707/ regardless - I think the only change missing vs. the last I posted was handling the case of an unknown source package
 * Laney nods
<Laney> that's why I added those blacklist entries
<hallyn> dannf: sure, either post a debdiff or whatever.  or if you're happy with it, i trust you, just push - up to you
<dannf> hallyn: posted a debdiff
<dannf> hallyn: i didn't see any regression fixes since the initial upload (though i did see some consolidation/rework) - that sound right to you?
<hallyn> not understanding what you mean
<hallyn> why did you remov ekvm-ipxe-precise from Suggests?
<hallyn> doesn't exist on the other arches?
<hallyn> oh, weird, that's only in contrl, not control-in
<dannf> hallyn: ah - prepared the source package before i built it, probably should prepare a post-build one
<hallyn> hm, apparently that debian/control has been out of date wrt the control-in for a bit;  i dont' see ipxe listd at all in control-in
<dannf> hallyn: what i meant by my question was, do you recall any fixes that had to go in after the first patch you adapted from mwhudson/etc
<hallyn> hm, yeah
 * hallyn checks
<dannf> i know that the patch went through iterations, but didn't notice any changes after it got uploaded
<dannf> well, bugfix changes
<hallyn> dannf: yeah kvm.powerpc can't use awk
<hallyn> see 1:2.2+dfsg-5expubuntu4
<dannf> ah, ok
<hallyn> man there were a lot of uploads to vivid
<hallyn> dannf: now, do you *not* need to also port init scripts to load a module at boot?
<hallyn> no, we only need that for x86 for precise + cloud-archive, which doesn't make sense for ppc
<dannf> it's not needed for arm64 - kvm can't be a module there
<dannf> i dont' remember armhf - i think the same thing, but i'll doublecheck
<hallyn> i don't htink anyone's gonna care there
<hallyn> i wouldn't worry about it.  just remove awk from the powerpc kvm script, then all looks good to me - thanks!
<pitti> doko, Laney: you use http://pad.ubuntu.com/gcc-5-transition with attaching your name to the thing your're working on? I plan to look at some FTBFSes tomorrow morning
<Laney> pitti: yeah, I'm going to upload the chunk at the bottom
<Laney> didn't look at any FTBFS ones yet
<Laney> actually I did look at one which was libtool not found but I can't remember which package that was now :)
<arges> infinity: mind if I take openldap merge
<pitti> Laney: ack (and would you mind adding your name to the pad? lots of "unnamed")
<pitti> Laney: you are purple?
<Laney> I am purple and toothpaste green
<pitti> :)
 * pitti switches to yellow then
<pitti> ack, 'nuff work for me to do tmw morning then
<pitti> Laney: the symbols mangling stuff is mostly just build/patch/test rebuild, upload, i. e. just annoying, but not technically hard
<pitti> Laney: or am I missing something tehre?
 * pitti <- C++ n00b
<pitti> Laney: did you already do the A-K batch? or pure coincidence that they all start with >= M?
<kirkland> pitti: howdy!
<kirkland> pitti: I applied and pushed your ecryptfs patches, thanks!
<pitti> hey kirkland, how are you?
<kirkland> pitti: I have a related question
<pitti> kirkland: I saw your mail (and responded), thanks!
<kirkland> pitti: well, thanks :-)
<pitti> slangasek, kees, infinity, stgraber: TB meeting reminder
<Laney> pitti: I would guess slangasek did those
<Laney> and/or seb128
<Laney> I've only done a couple but indeed I just updated the symbols file
<Laney> and package names, etc
<pitti> Laney: I meant in your "Test builds" section at the bottom
<Laney> I responded to your questions in reverse order, sorry
<pitti> Laney: oh, are these another batch of libs to rename, not just rebuilds against the renamed libs?
<pitti> Laney: reverse order> ah, makes more sense now :)
<Laney> and those test builds are all renames, yes
<pitti> Laney: ah, I though all renames were in the PPA already
<slangasek> pitti: no; no more ppa, this is all in wily-proposed
<Laney> I don't think all the renames were ever in there
<pitti> slangasek: right; I meant I thought we prepared *all* renames in the PPA
<slangasek> correct, the ppa only included the phone stack renames
<pitti> ah, ok
<Laney> right, well, here goes debsign *_source.changes
<kees> infinity: meeting?
<pitti> apw, infinity: do you know what the linux_uefi thingy is about in https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text= ?
<pitti> it seems our kernel is already way past that, can it just be rejected?
<apw> pitti, cirtianly that is the contents of the linux-signed package, being signed with the efi key, if the in pocket version is later than that it is not clear there is any value in it, i can only assme that there was no linux-signed for that level
<pitti> apw: yeah, we are at 4.1.0-3.3, and this one is for 4.1.0-2.2
<apw> so i would assume the bits it is about to drop into dists would then be reaped
<pitti> Laney: ack, so I'll watch out for a lot of binNEW tomorrow morning, to mop up what the American folks don't see any more during their day
<Laney> pitti: there's going to be a zillion rebuilds to do too; check http://people.canonical.com/~ubuntu-archive/transitions/
<Laney> I want to upload some haskell as a lot of icu seems to be haskellish stuff (unless cjwatson is going to?)
<pitti> Laney: ah, thanks; added that link to the pad
<Laney> thanks!
<kirkland> pitti: are these patches supposed to solve the problem where people are repeatedly asked for their encrypted swap passphrase during an apt-get?
<pitti> kirkland: not the upstream patches, but the post-install fixups I crowbared into the postinst
<pitti> they shoudl clean up fstab/crypttab
<pitti> but we had three different cases now, I woudln't be totally surprised (just really annoyed) if there's a fourth
<slangasek> Laney: what's the section in the pad without a header listing packages like csound, geos, ...?
<kirkland> pitti: hmm, can you drop me a patch for that?
<Laney> slangasek: Things which are fixed (or at least rebuilt) in Debian but not Ubuntu
<pitti> kirkland: it's all in wily
 * kirkland extracts
 * pitti waves good night
<pitti> slangasek: ah, I would have interpreted it as the results of the above commands, i. e. stuff being transitioned in Debian?
<kirkland> pitti: ah, https://launchpadlibrarian.net/211231394/ecryptfs-utils_107-0ubuntu1.1_107-0ubuntu3.diff.gz
<slangasek> ah
<pitti> kirkland: ah right, that also had an ages-old soname packaging fix
<Laney> I saw that dok_o was pinging the FTP team to accept stuff
<Laney> which meant that maintainers were uploading things and we shouldn't duplicate that work
<slangasek> Laney: sure.  Any chance you could show unstable vs. experimental there?
<pitti> i. e. ideally auto-sync will catch some of these?
 * pitti waves good night for real
<slangasek> Laney: I guess csound (which doko worked on yesterday) and hdf5 (which after working on the package yesterday I don't trust the maintainer's fix for) are via experimental only
<slangasek> hdf5 is a new upstream soname in experimental-only
<slangasek> I think I'll stick with my change for now
<Laney> can you annotate the pad?
<Laney> can look to split the list if that's useful
<slangasek> done
<Laney> haha
<Laney> after all that I accidently uploaded the packages I knew would fail anyway :(
<kirkland> pitti: okay, applied, now I'll do some testing
<infinity> apw: there was a signed for -2.2, that is from the proposed->release copy.
<infinity> apw: Which is supposed to happen without intervention, but breaks when the origin was a PPA. :/
<apw> what a mess ;)
<infinity> Yeah.  A bit.
<cjwatson> bdmurray: pass a consumer_name
<cjwatson> Laney: I was in the middle of working my way up that stack ...
<cjwatson> having noticed that it was entangled with icu
<Laney> well I don't want to step on your toes
<Laney> I've just (hopefully) got agda out of the way
<Laney> so feel free
<cjwatson> Laney: ah, great.  I think the only direct entanglement was haskell-text-icu, which I uploaded earlier, and then it's just syncing the stack
<Laney> [276 of 278] Compiling Agda.Interaction.InteractionTop ( src/full/Agda/Interaction/InteractionTop.hs, dist-ghc/build/Agda/Interaction/InteractionTop.o )
<Laney> ghc: out of memory (requested 1048576 bytes)
<Laney> oh no
<cjwatson> Laney: it did that last version on armhf too
<cjwatson> so that won't block anything
<Laney> oh right
<Laney> I thought it had built everywhere
<Laney> nope
<Laney> fair enough
<cjwatson> I probably used some kind of hammer
<Laney> I see depwait and then FTBFS
<cjwatson> there we go, haskell-publicsuffixlist is happier now, which was the earlier failure
<bdmurray> cjwatson: I've tried that and I still get a DESKTOP_INTEGRATION url when authorizing the token for the first time.
<cjwatson> bdmurray: hm, you might need a credentials store
<cjwatson> I'm not very familiar with this corner
<ricotz> doko, jfyi https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+sourcepub/5277318/+listing-archive-extra
<bdmurray> Okay
<slangasek> Laney: looks like packages got uploaded, thanks!  you'll track the build failures and record them in the pad for further divvying up?
<Laney> slangasek: yup, already fixed a couple
<slangasek> Laney, cjwatson: so is icu in hand and I shouldn't touch it?
<slangasek> it jumped out at me as a main lib we probably wanted transitioned soon that looks like it needs some mass rebuilding
<slangasek> umm why is xbmc-pvr-addons dep-wait on xbmc-addons-dev (>= 2:13.1~beta2+dfsg1~) when 2:13.2+dfsg1-4ubuntu1 is in wily? https://launchpad.net/ubuntu/+source/xbmc-pvr-addons/13.0+git20140512+g91cc731+dfsg1-2build1/+build/7758289
<slangasek> (both packages in universe)
<slangasek> ah, looks like it's a heuristic on the build log error message
<slangasek> or... not?
<slangasek> oh, it's only in *vivid*
<hallyn> dannf: were you going to push the trusty qemu to archive yourself?
<dannf> hallyn: yeah, unless you'd rather
<dannf> hallyn: i've got a source package w/ the ppc/awk fix i'm about to push - let me know if i should wait
<hallyn> dannf: nope, no reason to wait - thx much
<hallyn> dannf: did you happen to run lp:qa-regression-testing test-qemu.py against it?
<dannf> hallyn: nope, but i can
<cjwatson> slangasek: the haskell bits are in hand anyway, yes
<cjwatson> which I think is all of it
<cjwatson> it's just tedious waiting for repeated layers to build
<bdmurray> cjwatson: Oh, regarding consumer_name bug 755313
<ubottu> bug 755313 in launchpadlib "Launchpad.login_with *ignores* its consumer_name argument" [Low,Triaged] https://launchpad.net/bugs/755313
<cjwatson> Heh, OK
#ubuntu-devel 2015-08-05
<pitti> Good morning
<pitti> infinity: ah, so the linux -2.2 efi thing could just be rejected? thanks for cleaning up
<infinity> pitti: if by rejected, you mean accepted, then yes.
<pitti> infinity: ok
<Mirv> would there be a core dev around to ack UITK packaging changes? it seems mainly using more default Qt build options and some more documentation/examples. https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff
<pitti> +export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags --get CPPFLAGS)
<pitti> is that actually necessary? this looks redundant
<pitti> or does the build system not respect CPPFLAGS?
<pitti> moving the mkdir/cp stuff from dh_install to dh_build seems wrong
<pitti> this is installation, thus happening under fakeroot; it's only to debian/tmp/, but it still feels like the wrong direction
<pitti> --fail-missing is now specified twice
<pitti> Mirv: ^ so, I don't see anything which I'd consider a blocker, just several things which look odd
<infinity> pitti: The point of the core-dev review is to block on odd. :)
<infinity> pitti: Don't let 'em be sloppy.
<pitti> Mirv: oh, and don't call dh_auto_build in override_dh_install (not a change from this version, but that's most definitively wrong)
<pitti> this might all "work" by chance, but it's utterly confusing and unnecessarily hard to maintain and understand
<Mirv> pitti: thanks for all the input, I'll bring them to bzoltan/zbenjamin and discuss
<Mirv> pitti: I'm sure their next question would be "but it was QA granted, can we publish it and fix the issues later by filing a bug now?"
<Mirv> so I'm just saving time by asking at this point
<pitti> I'm actually more concerned why this was moved around without giving a rationale in the changelog
<pitti> building docs in dh_install and installing docs in dh_build is just wrong
<pitti> so, we know how the "we'll fix it later" goes, but if there's a way to file a bug that will actually stick (milestoning, or assigning to someone, or what not), ok for me
<Mirv> ok. I'll get answers but file and assign the bug already now for all those question marks.
<pitti> Mirv: thanks
<Mirv> thanks to you.
<Mirv> bug #1481584 filed
<ubottu> bug 1481584 in ubuntu-ui-toolkit (Ubuntu) "Fix reported packaging question marks / issues in UITK" [High,New] https://launchpad.net/bugs/1481584
<infinity> pitti: Did autopkgtest chroots used to have deb-src URIs in sources.list?
<infinity> pitti: Trying to figure out if the apport regression in vivid is an infrastructure regression or test regression.
<pitti> infinity: where "used to have" == pre-cloud or the ancient stuff that we had in saucy/trusty?
<pitti> ah, vivid; hang on
<infinity> pitti: Although, it passed on cloud infra on Jul 14, started failing on Jul 17...
<pitti> we used to have deb-src, but this test is for a "sandbox" with its own apt sources, so it shouldn't even matter
<pitti> infinity: I'll have a closer look
<infinity> pitti: Not so sure about that.  The logs show deb-src being the difference here, I think.
<infinity> pitti: The successful logs have Source in the initial update, the failures don't.
<infinity> pitti: Still arguably a broken test, mind you, but yeah.
<pitti> infinity: ah, so that sounds like a plausible reason then
<infinity> pitti: Not sure if the spec gives any reason to assume deb-src would be available, but I've not read it end-to-end.
<pitti> I added this to userdata some weeks ago:
<pitti> apt_sources:
<pitti> - source: deb \$MIRROR \$RELEASE restricted multiverse
<pitti> - source: deb-src \$MIRROR \$RELEASE restricted multiverse
<pitti> apparently that dropped the main apt sources
<pitti> (which is supposed to add additional ones only)
<infinity> pitti: Actually, weirder still, the succesful logs show an apt-get update to start, the newer logs don't.
<infinity> pitti: So even if deb-src was in sources.list, the lists wouldn't have been downloaded.  Unless that's happening before the log starts now.
<infinity> pitti: Oh.  But an update happens way later, and does include Sources.  Now I'm just confused.
<infinity> pitti: and too tired to make sense.
<infinity> pitti: So I'll go to bed instead. :P
<pitti> infinity: so e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid/vivid/amd64/a/apport/20150730_003039@/log.gz
<pitti> Sources is part of apt-get update at the very top, and that's the only update that I see
<pitti> so, not that
 * pitti queues for investigation
<pitti> wah wah cmake
<dholbach> good morning
<pitti> infinity, slangasek: hm, are you binNEWing stuff before builds on all arches are done? (e. g. I was waiting for gmsh/armhf before newing them)
<om26er> pitti, Hi! is there a way to include and install pypy package along with debs for autopkg test run ?
<pitti> om26er: your test can do whatever it wants to, including calling pypy or pip install
<pitti> (not sure what a "pypy package" is)
<om26er> pypi
<pitti> ah, ok
<pitti> om26er: pypy is an actual thing (compiled python), hence my confusion :)
<om26er> pitti, so the way you temporary install packages on the phone in /tmp ? I was hoping if I could do the same for a source that is not in ubuntu yet.
<pitti> om26er: pip has a mode to install to $HOME/.local, doesn't it?
<om26er> pitti, I didn't look into that. Will take a look.
<ochosi> dpm: ping
<doko> pitti, when you reassign to release, please set the severity to normal as well
<pitti> doko: oh, ok; I'll adjust the ones I sent today
<doko> do you upload these too to unstable?
<doko> also: block <this issue> by 790756
<pitti> doko: no, so far I'm just sending patches and tagging
<pitti> doko: I included the "block" thingy
<pitti> doko: I could upload them as 2-day NMUs I figure
<doko> pitti, but then please don't yet reassign ... the release team wonders what happens, and the package owner doesn't see things anymore
<pitti> doko: right, I don't reassign (as per our IRC chat a few days ago)
<doko> yep doing the NMUs would be nice, if all other b-d's are ready
<pitti> tag 791079 confirmed patch
<pitti> user release.debian.org@packages.debian.org
<pitti> usertag 791079 + transition
<pitti> block 791079 by 790756
<pitti> that's what I'm doing right now
<doko> ahh, I see
<dpm> hi ochosi, please feel free to ping questions directly
<pitti> doko: ack, I'll NMU the 6 I did so far; but it's all delayed/2, so I think we should still upload them directly to wily?
<doko> sure
<pitti> doko: (and sync them back later) to avoid another 3 days delay
<ochosi> dpm: sure, just wanted to make sure i don't disturb you doing anything else, also i wanted to quickly pm you if you don't mind (since it's not really a u-dev matter)
<dpm> ochosi, sure, no need to ask permission to pm, feel free to go ahead :)
<doko> seb128, Laney: please tell LazyShark that libreoffice is done (armhf build pending)
<seb128> doko, k
<Laney> doko: can you please note in the pad when you see things fixed in debian/NEW?
<Laney> no point us working on them then
<doko> Laney, will try, but will be away 'til Monday
<doko> pitti, Laney: so all transitions were at least tried once until now?
<pitti> "all transitions"?
<Laney> I uploaded the rest of the ones from your debian build logs that didn't have symbols files
<Laney> but we saw yesterday that some things were missing from there
<Laney> so I can't say it is "all"
<doko> yeah, but it should be safe, to remove the block-proposed from gcc-5 and see what happens. everything else should be blocked by the new packages
<pitti> doko: oops, my important->normal change was probably wrong -- this should only be done when reassinging to release@, but we don't do that?
<Laney> I've been reassigning to release
<doko> pitti, yep, sorry for the confusion
<Laney> because the bug told me to
<Laney> is that not good?
<doko> if you NMU yes
<Laney> haven't been
<pitti> I just NMUed libvsqplitepp (and about to do some others)
<Laney> and didn't forward the scripted deltas that I uploaded yesterday
<Laney> doing that individually seems quite daunting :/
<pitti> should the bugs be reassigned now? and why? (still sounds a bit strange)
<Laney> might save that as a debconf task or something
<pitti> Laney: yeah, I'm only forwarding patches after I fixed the FTBFS, i. e. package specific changes; forwaring a thousand scripted patches seems a bit pointless
<Laney> NMUing them to speed the transition along in Debian feels like it would be useful though
<Laney> but there's a risk of false positives without analysis
<doko> you are allowed to do 2day delayed NMUs. so NMUing and reassigning would be the best
<doko> be sure that all b-d's are ready
<pitti> doko: OOI, why reassign in this case?
<Laney> did someone prune the "appear to be transitioned in Debian" list?
<pitti> Laney: yes, for the bits that I synced/built/NEWed
<Laney> ah, great
<pitti> Laney: there's 3 left which we can't do yet
<pitti> I left a comment
<pitti> two of them should be syncable this afternoon
<Laney> yeah, I see those, just wondered about the rest
<pitti> well, it's a TODO list -- stuff that's done should just disappear
<Laney> 05/08 08:35:57 <doko> GCC 5 stuff in NEW: rtmidi rtaudio tinyxml guichan
<pitti> I'm also pruning the FTBFS and others
<willcooke> Laney, sladen - hi, did you manage to get that font zip file sorted?
<pitti> doko: this (ipe) does not look like an ABI break to me: http://paste.ubuntu.com/12005903/ - WDYT?
<pitti> doko: or is that the __cxx114 thingy?
<pitti> doko: I was wondering because a rebuild in sid still generates libstdc++6 (>= 4.6) only, not >= 5
<Laney> willcooke: not yet I'm afraid, still standing by
<doko> pitti: the bumped dependency on libstdc++ only appears if you reference any of the new symbols in libstdc++.
<doko> but the library defines some cxx11 symbols on its own, so yes, I'd say an ABI break
<pitti> doko: ok, thanks for checking
<willcooke> Laney, thanks.
 * pitti goes on with NMUing then
<sladen> willcooke: no, was prioritising other actual _potential to block_ stuff
<willcooke> sladen, nw, any idea of an ETA, or if you can let me or Laney know what needs doing we can have a stab at it
<doko> wtf, onboard manually depends on every single shared library???
<pitti> some build systems just outsmart themselves
<sidi> Is this the right channel for Unity development?
<Laney> sidi: #ubuntu-unity
<sidi> thanks Laney
<pitti> ah, d-shlibmove -- apparently that needs a --suffix=v5 or so, /me tries
<doko> pitti, I fixed d-shlibmove, needs --v5
<pitti> doko: ah, I used --suffix=v5
<doko> hmm, I tried that too ... anyway
<pitti> /usr/bin/d-shlibmove: [--suffix=v5] is not a valid shared library file name
<pitti> meh
<seb128> hum
<seb128> grub-efi-amd64 fails to configure on my wily test laptop
<seb128> it bails out on
<seb128> "ERROR: cannot determine partition label for rootfs"
<seb128> does anyone has an idea how to solve it?.
<pitti> doko: ah, --v5 is in wily only; I'm trying to fix sid too
<doko> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794561
<ubottu> Debian bug 794561 in src:d-shlibs "d-shlibmove could use a --v5 option" [Normal,Open]
<seb128> hum
<seb128> it's upgrade-gru
<seb128> it's upgrade-grub which fails on that error
<pitti> doko: ah, thanks; reading the code, --suffix should work as well; maybe only "--suffix v5", not "--suffix=v5", trying with the former
<pitti> doko: ah! --suffix v5 works! \o/
<doko> I love Jonas too
<pitti> debian/control.in.in, yummy ;)
<doko> rbasak, https://bugs.launchpad.net/bugs/1481333 is this seen in -proposed as well?
<ubottu> Launchpad bug 1481333 in gcc-5 (Ubuntu) "internal compiler error: in final_scan_insn, at final.c:3020" [Undecided,Incomplete]
<doko> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794587
<ubottu> Debian bug 794587 in libvpb1 "man page is part of both libvbp0 and libvbp1" [Serious,Open]
 * Laney sees d-shlibmove for the first time
<doko> don't take a second look
<Laney> heh
<Laney> hm, control.in.in too - pitti, were you talking about ucommon?
<pitti> Laney: no, libsass
<pitti> doko: argh, thanks; I'll upload a Conflicts:/Replaces:
<doko> pitti, as a break to the library uploads, could we walk throught the failing autopkg tests triggered by gcc-5?
<doko> Laney, pitti: http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/  this was triggered before the GCC change. could you have a look?
<pitti> doko: looks "just" flaky at first sight, I'll retry a few times
<pitti> doko: uploaded C/R for vpb-driver, thanks for pointing out
<pitti> Laney, doko: BTW, do you know whether it's normal that ftp://ftp-master.debian.org/pub/UploadQueue/DELAYED/2-day/ is empty?
<pitti> dput -e 2 ftp-master succeeded, but I never got any kind of mail from ftpmaster
<doko> pitti, beware, exiv2 in debian NEW with a different library name. maybe we should merge that (new upstream)
<pitti> doko: ah yes, quite a bunch of rdepends
<pitti> doko: we can't download stuff from Debian new, but I can piece it together from packaging svn
<doko> pitti, please update rdeps in main too after that
<pitti> ack
<doko> I'm already running a wily-proposed desktop
<pitti> added to pad
<pitti> doko: meh -- they didn't commit 0.25-1 to svn :(
<pitti> doko: so I guess we'll have to wait for Debian NEW
<doko> pitti, will appear in incoming soonish
<pitti> we might get a few rebuilds against v5 by then, so we'll just have to do it again
<pitti> *shrug*
<pitti> doko: oh, was it just NEWed?
<doko> yes
<pitti> nice
<pitti> ok, postponing that until it hits incoming, and continuing FTBFS fixing by then
<pitti> Laney: ok, you stole my color, I switched to red now :)
<bzoltan_> pitti: infinity: refering to the UITK packaging issues -> I have addressed all your comments in this MR -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/packaging_fixes_lp1481584/+merge/267012 The  CFLAGS exports I used straight from the Qt packages. It is like that in all debian packages too.
<pitti> bzoltan_: ah, that looks nicer already, thanks
<pitti> bzoltan_: I still don't understand why this CFLAGS dance is necessary, though
<bzoltan_> pitti:  thank you for point out ... The CFLAGS I do not get either.
<Laney> pitti: no mail from DELAYED - I just check https://ftp-master.debian.org/deferred.html after a bit
<Laney> don't know where the files end up living
<pitti> Laney: aah! that's what replaces https://people.debian.org/~djpig/delayed.html, thanks!
<Laney> showing your age there :P
<pitti> Laney: great timing! at the very second you say that I asked in #debian-release :)
<Laney> ha
<pitti> Laney: libdynamicedt3d1.6 wasn't renamed in the octomap source; on purpose, or doesn't the script get along multiple libs?
<seb128> slangasek, cjwatson, cyphermox, hey, who is looking after grub issues nowadays?
<Laney> pitti: The script tries to rename only the packages with changed symbols
<pitti> Laney: ah, cool
<pitti> Laney: I'll verify in the (fixed) builds, but good to know
<Laney> if the test rebuild is to be believed then this looks right
<Laney> (octomap & octovis)
<cjwatson> seb128: cyphermox
<cjwatson> (afaik)
<seb128> cjwatson, thanks
<pitti> Laney: ah! all tmpfails fixed :)
<Laney> :-O
<Laney> even n-m/vivid?
<pitti> Laney: this morning we had tmpfails for all packages with "network" in the name
<pitti> Laney: *all*
<pitti> Laney: well, vivid is just a "real" failure now
<pitti> (it needs the same "disable 80211.a" change that cyphermox applied to wily)
<pitti> Laney: that was a funny parsing bug of "nova show" (for finding the IP)
<doko> pitti, http://incoming.debian.org/debian-buildd/pool/main/e/exiv2/
<pitti> I wish nova had some --machine-readable thingy instead of having to parse ascii art tables
<pitti> doko: yay, fake-syncing
<pitti> doko: I'll upload rebuilds after it published
<doko> slangasek, Laney, pitti: so geos, spatialite, postgis, gdal have a build-dependency cycle now ...
<doko> was looking at these to fix autopkg test failures for gcc-5, but running out of time now
<pitti> doko: geos built fine, WDYM?
<pitti> oh, you mean the latter 3 have not co-installable build-deps now?
<doko> yes
<Laney> doko: looks like you can turn off spatialiate in gdal
<pitti> meh, exiv2 FTBFS on 32 bit arches
<pitti> ah, just symbols madness
<rbasak> doko: that bug doesn't affect MySQL in Ubuntu yet (AFAIK). Upstream reported it - we'll need to wait for them to reply I think.
<doko> Laney, thanks. and found: https://launchpad.net/ubuntu/+source/opencv/2.4.9+dfsg-1ubuntu5
<doko> rbasak, thanks for checking
<Laney> joyous
<doko> rbasak, is anybody checking for image installability using wily-proposed?
<rbasak> doko: I don't think so, no.
<doko> rbasak, I asked smoser in the past, but never got a reply
<pitti> Laney: do you happen to know how to untangle a C++ per-arch symbols mismatch like https://launchpadlibrarian.net/213670636/buildlog_ubuntu-wily-armhf.exiv2_0.25-1_BUILDING.txt.gz ?
<pitti> Laney: if so, quick tutorial appreciated (I've never done this)
<pitti> or anyone C++ savvy ^
<rbasak> doko: matsubara is the QA contact on our team. Maybe he knows? He'd be the person to speak to about it anyway but I don't see him online right now.
<Laney> pitti: ah, is that size_t?
<pitti> Laney: it's in some "string" class obviously, but apart from that this is just gobbledigok to me :(
<pitti> Laney: size_t in a string class sounds plausible, though
<pitti> at least it fails on the three 32 bit arches and succeeds on the three 64
 * Laney runs it through c++filt
<Laney> GET https://launchpadlibrarian.net/213670636/buildlog_ubuntu-wily-armhf.exiv2_0.25-1_BUILDING.txt.gz | zcat | c++filt | vim - # or so
 * pitti uploads the next FTBFS fix in teh meantime
<pitti> Laney: do you need a hand with ucommon? (that hasn't changed in a while)
<Laney> I got confused about it
<Laney> now d-shlibmove is failing and I didn't get to the bottom of why yet
<Laney> yeah these look like size_t
<Laney> I think the state of the art, unless it changed while I wasn't looking, is to use pkgkde-symbolshelper for those
<Laney> you can do some subst thing so it substitutes the right type per-arch with that
<Laney> or you can include two versions with the right arch= for each one
<Laney> (which is obviously more brittle but easier to get going now)
<pitti> Laney: the .symbols doesn't have any arch=, nor size_t, I wonder how previous versions did that
<pitti> oh! all symbols say "0.25", so apparently they just added that
<pitti> isn't there some sane way to put demangled symbols into *.symbols instead of this arch specific mess?
<Laney> it still demangles to the actual type and not size_t
<Laney> but yes, you can c++filt them
<Laney> (c++)"<c++filted thing>"
<pitti> ah, so that wouldn't even help
<pitti> Laney: as this is totally new in 0.25-1, would it be okay to drop it temporarily for us and let the DD sort out the symbols?
<pitti> "this" -> the .symbols file
<Laney> I saw an example yesterday or so where doko split 32/64 bit specific symbols out into different files and included them
<Laney> but I can't find it now :(
<doko> pitti, look if this is managed with the kde symbols helper
 * pitti looks at omnievents -- no reverse deps, last upload 2011, obsolete stuff -- shouldn't we rather just remove this?
<pitti> (I fixed it in wily, wondering whether to NMU or not)
<pitti> doko: I'd say no, nothing "kde"ish in debian/rules or control
<pitti> they just added the .symbols file without any changes to debian/rules
<Laney> pitti: meh, new d-shlibs breaks ucommon
<Laney> it's added some new and wrong quoting
<pitti> Laney: new in Ubuntu or new in Debian?
<pitti> Laney: I tried "--suffix v5" (which works in Debian, for NMUing), and that works; I didn't try the ubuntu specific --v5
<Laney> it's a call to objdump which dies
<Laney> and doesn't with 0.58
<hallyn> dannf: when you ran test-qemu.py ,did you first go into the scripts/qemu and scripts/libvirt subdirectories and wget the files the readmes say to get?
<hallyn> maybe i'll post a MR to do that automatically
<dannf> hallyn: yeah.
<hallyn> hm
<hallyn> not good
<Laney> xnox: did you fix the moc/BOOST_JOIN thing?
<dannf> its weird - it complained the file wasn't there - but it was
<dannf> and then the tests ran
<dannf> w/o the file they didn't
<dannf> hallyn: i also think its funny that it downloads the key insecurely, the tarball insecurely, then verifies the tarball w/ the key... but i guess it doesn' tmake things *worse* :)
<hallyn> i assume someone had intended to embed a public key into the bzr tree and neve got around to it
<dannf> yeah, i guess i could MP that instead of whining
<hallyn> dannf: fwiw i wont' be able to look at that today i don't think;  if you still have trouble tomorrow pls shout
<dannf> hallyn: ok
<pitti> doko, Laney: just in case you wonder, removing libsass from wily-proposed; the DD does not want this transitioned, and there are no rdepends
<pitti> (also cancelled the NMU)
<doko> rbasak, please could you merge libecap? background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791117
<ubottu> Debian bug 791117 in src:libecap "libecap: library transition may be needed when GCC 5 is the default" [Important,Open]
<rbasak> Should logrotate scripts be using invoke-rc.d? Or is the service wrapper acceptable?
<rbasak> doko: looking
<doko> soonish would be good, then we don't need to rename the library package
<rbasak> kickinz1: Blocking fix for 794536: squid3: FTBS on GCC-5
<rbasak> doko: arges is taking it.
<doko> ta
<kickinz1> rbasak, thanks
<doko> slangasek, Laney, pitti: so renaming all libs first, without rebuilding all rdeps is a good way to find cyclic dependencies ;-P
<doko> now coming to a solution for postgis/spatialite/gdal
<doko> Laney, did you make progress with opencv?
<rbasak> In case it got missed: should logrotate scripts be using invoke-rc.d? Or is the service wrapper acceptable?
<rbasak> infinity: ^^ any opinion on that please?
<rbasak> I'm leaning towards invoke-rc.d but am wondering if there's any existing best practice on that
<infinity> rbasak: Not sure there's a policy or even established best practice, but in my mind, anything a *maintainer* does should use invoke-rc.d, so a sysadmin can override with policy-rc.d
<infinity> rbasak: So, that's not just dpkg maintainer scripts, but any script you ship that wants to fiddle with services, including logrotate.
<infinity> rbasak: Policy might say something sort of like that somewhere, but I don't recall seeing it.
<infinity> rbasak: /etc/network/if-up.d/ntpdate seems to follow this, for instance.
<infinity> And openssh-server.
<rbasak> infinity: understood, with the reasoning. Thanks!
<infinity> rbasak: So, yeah.  invoke away.
<arges> cyphermox: i see you are having a productive SRU day
<arges> cyphermox: reviewing a lot of your packages now
<infinity> rbasak: So, on my system, that would make the logrotate scripts for samba and rsyslog buggy.  And probably rightfully so.
<infinity> rbasak: Eww, and speech-dispatched double-buggy, it calls /etc/init.d/foo directly.
<infinity> Gross.
<infinity> rbasak: Thanks, I didn't want to know this.
<cyphermox> arges: yeah, those are all special magic, don't hesitate to include infinity, he was delegating to me ;)
<infinity> cyphermox: Half the reason to delegate to you was so I could do the reviews.
<infinity> arges: So, yeah, if you're not comfy reviewing ppc64-diag, I'll hit it up after breakfast.
<rbasak> infinity: well, I didn't ask you to look :)
<rbasak> infinity: rcj is just fixing this kind of thing in freeradius and so I just wanted to make sure that we fix it the right way.
<infinity> rbasak: I can't help looking.
<infinity> rbasak: And now I know the world is a little bit less shiny than I hoped.
<barry> infinity: ping re python-apt and apt (since mvo isn't around and you did the last upload to apt in wily)
<infinity> barry: I feel like your ping lacks content.
<barry> infinity: python-apt b-d's on apt (>= 1.0.10) but 1.0.9.10ubuntu6 is in w-p
<barry> infinity: what's the eta for 1.0.10 in wily?
<barry> infinity: (sorry, was clicking around ;)
<infinity> barry: Man, David only uploaded it to unstable two days ago!
<barry> infinity: it == apt?
<arges> infinity: ok either way I was just about to look at ppc64-diag
<infinity> barry: I hadn't had any intention of taking over the merges there, so no ETA.  Why did we merge python-apt?
<arges> infinity: in fact i'll just handle that
<barry> infinity: dunno!  i just started looking at this, and mvo isn't around
<barry> infinity: ok, no worries, i'll figure something out
<infinity> barry: Huh.  That's fishy.  We had a delta, so the sync would have been forced, but I see no mail to -changes telling me who did it. :/
<infinity> barry: If it was mvo, I'd expect he plans to do apt as well.
<barry> infinity: probably/hopefully so
<infinity> barry: Oh, the delta might be tiny anyway.
<infinity> barry: Lemme look at it after I (finally) eat breakfast.
<barry> infinity: ack, thx
<infinity> barry: Based on David's changelog, 1.0.10 might just be the C++ transition, no scary.  Unless his changelog is a lie.
<barry> infinity: and there's a changelog in pyapt for the gcc transition too
<infinity> barry: Right.  I'll poke this bear with a stick in ~1h.
<infinity> When my stomach stops with the hate.
<barry> infinity: i'll wait for the tonal change from stomach roar to bear roar
<doko> rbasak, arges: accepted libecap. please schedule building the rdepends once the package is published
<arges> ok
<doko> infinity, mvo comes back next week. this should have time
<arges> doko: just to confirm, I need to no-change rebuild on any libecap rdepends
<doko> arges, yes, but only once you see/can install the package in your own chroot
<barry> infinity: fwiw, i bump the bd's down to 1.0.9 and python-apt built locally just fine
<infinity> barry: Yeah, I assumed it would, but may as well keep the sync if merging apt isn't too painful.
<barry> infinity: +1
<infinity> barry: If apt thwarts my efforts, I'll just introduce a python-apt delta.
<infinity> ypwong: You around?
<infinity> ypwong: cyphermox and I are considering respinning ubuntukylin 14.04.3 ISOs to fix https://bugs.launchpad.net/ubuntukylin/+bug/1380981 but only if you guys are happy with another build.
<ubottu> Launchpad bug 1380981 in Ubuntu Kylin "In UEFI mode, default langauge in Ubiquity language chooser is not Simplified Chinese" [Critical,New]
<Laney> doko: didn't look at opencv
<doko> Laney, I did =) openexr wasn't rebuilt. took the new upstream from experimental
<Laney> nice
<rbasak> infinity: logrotate postrotate script: silently ignore failure on sending reload signal? Logic: if daemon isn't running, failure to send re-open signal isn't a problem.
<rbasak> infinity: some logrotate scripts do this, but the logrotate manpage examples don't seem to.
<infinity> rbasak: Been a while since I wrote logrotate stuff, but it really depends on what cron spam you think is justified.
<infinity> rbasak: If a failed reload could actually be a failure, the admin might like to know that his daemon died overnight.
<infinity> rbasak: So, sort of depends on the init setup and what you do or don't know about state.
<rbasak> infinity: for freeradius then, I think the answer is to not fail silently. Though if the sysadmin deliberately wants the service to remain stopped, then he'll get spam. I think that's OK.
<infinity> rbasak: The canonical example of this from my years in the trenches was fighting with apache logrotate scripts that had to stop/start because of $reasons (reload/graceful didn't DTRT and close all the logs), but because it can take several months to stop a heavily-loaded apache, it might fail to start again.
<infinity> rbasak: In that case, having the cron spam was invaluable, both to frustrated sysadmins who needed to fix it, and to us because we got notified that our packages sucked. :P
<Laney> LocutusOfBorg1: You want to use your new powers to transition lucene++ for GCC5? :)
 * Laney cooks up a diff anyways
<hallyn> dannf: fwiw on my system all tests passed with your debdiff
<hallyn> something funky going on with your vm probably
#ubuntu-devel 2015-08-06
<dannf> hallyn: hm... i probably did something wrong
<infinity> ypwong: *poke*
<sarnold> pitti: hey, about this new cloudy autopkgtest stuff, the "simple" way to run a specific package's tests looks pretty easy for the security team to use; but the proposed-migration stuff recently caught an apparmor packaging bug, and I'm curious if there's an easy way that we can use britney with local packages of some sort
<sarnold> pitti: .. whether that's copying them out of a private ppa, or normal ppa, or a directory with packages, or something similar
<sarnold> pitti: I know you're oing to be working on it in the next couple of weeks, and I thought it'd be nice to ask for a potentially different usecase than you might have thoght of so far :)
<sarnold> pitti: thanks :)
<pitti> Good morning
<pitti> sarnold: my idea was to add extra arguments to the AMQP requests, like "enable this PPA for this test run"
<pitti> sarnold: so, I don't plan to set up a gazillion britney instances for PPAs centrally (maybe we can provide that as a service for PPAs some day)
<pitti> sarnold: but at least it gives you the machinery to run tests for yourself (even automatically, as sending AMQP requests is trivial to script from any language)
<pitti> Laney: FYI, simple but effective: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=96c375841da
<pitti> Laney: with that you can just run "killall worker" on the worker controller, and they will all restart cleanly after finishing their current test
<pitti> Laney: i. e. to roll out new code or config
<pitti> (I'll also add this to the documentation, but FYI)
<pitti> Riddell: hi!
<pitti> Riddell: do you know what to do with the armhf symbol mismatch on https://launchpad.net/ubuntu/+source/kjs/5.12.0-0ubuntu2 ? (it's blocking quite a few more things)
<infinity> pitti: Just a bug in the symbols file.
<infinity> pitti: He tried to fix it in the last upload, but ended up with a duplicate line.
<infinity> Though, why the symbol was dropped on armhf in the first place is a curious question.
<pitti> + (arch=!armhf)_ZTVN3KJS7JSValueE@Base 5.12.0
<pitti>   _ZTVN3KJS7JSValueE@Base 4.96.0
<pitti> ah, I see
<pitti> ack, will fix
<pitti> Riddell, infinity: fixed, thanks for pointin gout
<infinity> pitti: Not that I agree with the fix, mind you, but it would have happened unnoticed if Riddell hadn't fat-fingered the change, and I think my carefactor about ABI breaks on 32-bit ARM on random KDE libraries is low.
<infinity> pitti: Oh, and happily, it doesn't matter, since the ABI broke anyway for the C++ transition.
<infinity> pitti: So, I guess it doesn't matter.
<infinity> I said that twice.
<infinity> I need to sleep.
<pitti> infinity: and that *does* matter :)
<dholbach> good morning
<infinity> pitti: Hahaha.
<infinity> pitti: Fix one, blow up the next library. ;)
<pitti> infinity: yeah, currently at it :/
<pitti> fortunately there's "only" two symbols files
<infinity> pitti: Based on the symbols missing from the second library, it looks like it's linked to the first, and exporting its symbols.  Ick.
<pitti> hate hate hate C++
<infinity> Also, I shouldn't be able to read mangled symbols.
<infinity> I hate myself a little bit for that.
<pitti> all this just can't be right -- rebuilding unchanged source with a new compiler breaks ABI, WTF
<pitti> </rant> sorry -- but really
<infinity> pitti: Part of that is that we suck at filtering only-sorta-public symbols.  Which is kinda C++'s fault, and kinda our tooling.
<pitti> well, but it also breaks symbols from the actual API
<infinity> pitti: If you take away templates that change on rebuild, but don't "really" break ABI, it's less scary.
<infinity> pitti: But, of course, there are also real ABI breaks to contend with, which muddies the waters.
<infinity> So, whee.
<infinity> pitti: I'm no great defender of C++.  Gimme C any day.
<infinity> pitti: In this case, though, I suspect the armhf dropped symbols have nothing at all to do with the C++ transition, and we're just super lucky it's happening at the same time. :P
<infinity> So we can pretend not to care.
<LocutusOfBorg1> Laney, wilco!
<LocutusOfBorg1> :)
<flexiondotorg> pitti, I'm running 15.10 and see you've been updating policykit recently.
<flexiondotorg> pitti, I think I may have encountered a regression in pkexec.
<flexiondotorg> pitti, But I'd like to just double check here because it maybe the behaviour change is intended.
<flexiondotorg> pitti, I have a python application that runs another small helper python script using pkexec.
<flexiondotorg> pitti, Where that once worked, now I get the following output:
<flexiondotorg> The value for the SHELL variable was not found the /etc/shells file
<flexiondotorg> This incident has been reported.
<flexiondotorg> pitti, Ignore the above. The issue is with fish shell which doesn't update /etc/shells.
<LocutusOfBorg1> Laney, question: how do I generate an symbols file?
 * LocutusOfBorg1 found https://wiki.debian.org/UsingSymbolsFiles
<Laney> LocutusOfBorg1: Running off now, but the first commands there look good and then the c++ bit a little way further down
 * Laney waves
<LocutusOfBorg1> I read that symbols file for c++ projects were mostly useless.... but adding one anyway
<Laney> Depends how good the upstream is at controlling what they export
<Laney> really ttyl :)
<LocutusOfBorg1> bye! :D
<pitti> flexiondotorg: yes, pk didn't change behaviour in ages really, except for a security fix which isn't related to what you describe
<doko> Laney, pitti: please could one of you do no-change uploads for openexr and libvigraimpex (after the next publisher run). I'll be on the train soonish
<doko> I mean, for the rdeps
<pitti> doko: yep, will do
<flexiondotorg> pitti, Thanks for replying. I confirm it is not a policykit regression.
<pitti> doko: added to the pad; I started transitions of exiv2 and libxapian, wading through the build failures now
<pitti> anyone C++ savvy: how can a no-change rebuild against a new lib ABI succeed but change exported symbols? https://launchpadlibrarian.net/213741568/buildlog_ubuntu-wily-amd64.libkexiv2_4%3A15.04.2-0ubuntu2_BUILDING.txt.gz
<pitti> do C++ libs do such massive leaking of private symbols, or how is that being handled?
<pitti> doko: ^ (perhaps you know)
<hyperair> there's -fvisibility
<hyperair> but a lot of libs don't use it
<hyperair> and there are still a lot of leaked std:: symbols that i typically ignore using (optional)
<pitti> but this isn't "standard" symbols
<pitti> +#MISSING: 4:15.04.2-0ubuntu2# _ZN11KExiv2Iface11SubjectDataD1Ev@Base 4:4.10.3
<pitti> that's clearly from KExiv
<hyperair> hang on lemme pipe that through c++filt
<hyperair> - KExiv2Iface::KExiv2::Private::detectEncodingAndDecode(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const@Base 4:4.9.80
<hyperair> std::string has changed type
<hyperair> + KExiv2Iface::KExiv2::Private::detectEncodingAndDecode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const@Base 4:15.04.2-0ubuntu2
<hyperair> which means that all functions which have std::string in their argument list will change signature
<pitti> hyperair: ah, so that means we need to rename libkexiv2-11 to libkexiv2-11v5 and do another transition?
<hyperair> which consequently changes their mangled symbol
<hyperair> yes
<pitti> this is just plain crazy
<hyperair> yeah well, it doesn't happen often.
<hyperair> it's probably because of the std change
<hyperair> there were a couple of struct size changes between c++98 and c++11
<pitti> hyperair: ack, doing lib transition then, thanks
<hyperair> np
<mwhudson> so given that docker has a static binary, do we have any clever way of knowing which libs are built into it?
<mwhudson> so we can do a rebuild when any of those libs are updated?
<pitti> mwhudson: looking at it's Build-Depends:?
<cjwatson> mwhudson: Built-Using would be the right tool for the job, even though it won't be a complete answer as yet (because nothing's set up to specifically scan it)
<cjwatson> mwhudson: I thought dh-golang had something to emit that?
<mwhudson> oh right
<mwhudson> yeah, it does
<mwhudson> docker doesn't use it though :-)
<mwhudson> Our goal is to release the final version of Go 1.5 on August 20, 2015.
<mwhudson> mm that date looks familiar :-)
<pitti> Laney, infinity: how can http://people.canonical.com/~ubuntu-archive/transitions/html/exiv2-g++5.html be fixed to check for libexiv2-14?
 * pitti NBSes it from wily-proposed (no further rdepends), maybe that'll help
<mwhudson> today's basket of ugh: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1481994
<ubottu> Launchpad bug 1481994 in libguestfs (Ubuntu) "ftbfs in wily" [Undecided,New]
<mwhudson> contrary to the bug title, i think ocaml-gettext was broken by the update to gcc 5
<pitti> cjwatson: do you still know where the transition tracker lives?
<pitti> apparently not on snakefruit, and lillypilly lost the ~ubuntu-archive role account
<cjwatson> pitti: it's on snakefruit
<cjwatson> pitti: start from ~ubuntu-archive/bin/update-transitions
<cjwatson> (called from archive-reports)
<pitti> cjwatson: ah, thanks
<cjwatson> it's just cunningly hidden in an schroot
<pitti> cjwatson: I'd like to see whether I can convince it to fix http://people.canonical.com/~ubuntu-archive/transitions/html/exiv2-g++5.html
<cjwatson> pitti: the configs are in lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/
<pitti> cjwatson: thanks! updating that
<cjwatson> pitti: actual code, I think it just uses the ben package from trusty
<cjwatson> and there's a 'go' script buried in the schroot
<smb> Where would be the best channel trying to get hints about why i386 desktop isos fail to start a proper live session when running in a KVM VM. The obvious part is because compiz does not start, I just completely fail to find any log that would explain why that is. Maybe #ubuntu-desktop?
<seb128> smb, is that wily?
<smb> seb128, also, but basically all since and including Trusty
<seb128> weird
<seb128> it's rather an issue with the vm graphic drivers than with the iso then I guess
<smb> Yeah, it is something with KVM/Qemu because Xen (while using the exactly same graphics emulation) does work (except Vivid which seems to be specially broken)
<seb128> I doubt -desktop can help you
<seb128> it's not an issue with the desktop in the image
<seb128> but rather with the vm
<smb> Right, I am mainly interested on whether there is any way to extract reasons on why compiz does not start. The X.org.logs of both Xen working and KVM not working seem to be the same and neither has any hard errors in them
<seb128> on < vivid look into .cache/upstart/gnome-session-Unity.log
<seb128> or >= vivid sudo journalctl
<seb128> like the 3d rendering or software emulation not working
<smb> seb128, I got the wily iso booted on Xen and KVM right now. So journalctl shows some warning level and above, but nothing that strikes as errors related to X up to a point where there seem follow up errors because of that (X resources unavailable). The X.org.log seems ok enough. At least the sw renderer seems to come up and visually you see background and the two icons (install and examples) rendered. Just nothing e
<smb> lse (which I would say is because of compiz not running)
<smb> There just seems to be no reason given anywhere why it did not get started (or failed to start)
<seb128> smb, go to a vt and start DISPLAY=:0 compiz --replace and see what it goes?
<smb> seb128, Interesting. Hm, so it starts and keeps running, but still no unity. Certainly because startup is screwed. Is there a similar magic for the unity part?
<seb128> smb, unity is a plugin, you can try to run "unity" from the vt
<smb> seb128, Ah thanks. That at least sheds a bit of light... Though cryptic. So I was guessing that "DISPLAY=:0 unity --replace" might be what I should try. Which seems to be okayish up to the point where LLVM tells me: "ERROR: Do not know how to split the result of this operator!"
<seb128> smb, that's like your issue
<seb128> smb, seems like bug #1360241 but that got fixed
<ubottu> bug 1360241 in llvm-toolchain-3.5 (Ubuntu) "[Regression] "LLVM ERROR: Do not know how to split the result of this operator!" in executing Ubuntu UI Toolkit tests on x86" [Undecided,Confirmed] https://launchpad.net/bugs/1360241
<smb> seb128, Yeah, if only I would know how to parse this error message. :) But ok, at least something I can look for
<seb128> https://llvm.org/bugs/show_bug.cgi?id=21641
<ubottu> llvm.org bug 21641 in LLVM assembly language parser "LLVM ERROR: Do not know how to split the result of this operator!" [Normal,New]
<smb> Hmmm, ok, so maybe there is a subtle difference in the cpu flags between KVM and Xen which sound like the only reasonable explanation to this. So llvm potentially runs different optimizations...
<smb> seb128, Thanks, I think that got me somewhere
<seb128> smb, yw!
<smb> Yay! It _is_ the cpu type that llvmpipe(i386) does not like
<davmor2> smb: I hit the same issue there is a bug in lp for it. I386 hates llvmpipe on the kvm cpu, I used -cpu host to get around it and then is works a charm
<smb> davmor2, Yeah if I knew about that one before... :-P It also works with -cpu core2duo. So with some other data gathered it may be either the model/stepping info or maybe one of PAT or VME that make i386 llvmpipe to go on strike
<davmor2> smb: https://bugs.launchpad.net/bugs/1481294
<ubottu> Launchpad bug 1481294 in qemu (Ubuntu) "14.04.3: in kvm install full disk from the i386 install when you go to login it returns you to the login page" [Undecided,New]
<smb> davmor2, ah thanks. There is also the more generic bug 1448985 which I was looking at
<ubottu> bug 1448985 in qemu (Ubuntu) "Ubuntu 14.04 LTS, 14.10, 15.04, 15.10 guests do not boot to Unity from QEMU-KVM Ubuntu 14.04 LTS, 14.10, 15.04 hosts" [High,Confirmed] https://launchpad.net/bugs/1448985
<davmor2> smb: nice
<smb> Now who do we talk to about go... err llvmpipe
<Odd_Bloke> What installs the symlinks in /etc/systemd/system/multi-user.target.wants/?
<Odd_Bloke> Or, to ask my actual question, how can I get a service to start on boot when it's installed?
<pitti> Odd_Bloke: dh_installinit, or if there's no corresponding init script to the .service, dh_install_{enable,start}
<pitti> (see their manpages)
<pitti> Odd_Bloke: sorry, dh_systemd_{enable,start}
<pitti> Odd_Bloke: dh_systemd_enable will call systemctl enable, which creates that .wants/ symlink
<pitti> Odd_Bloke: and d_s_start will start it immediately after package install
<Odd_Bloke> pitti: Excellent, thanks!
<Odd_Bloke> pitti: dh_systemd_enable isn't run by default?  So to enable all installed init things I need just 'override_dh_systemd_enable:\n dh_systemd_enable' in debian/rules?
<pitti> Odd_Bloke: then you don't need to override it at all :) (if you don't want to supply options)
<pitti> Odd_Bloke: usually, if you have a debian/foo.init and debian/foo.service, it'll just work
<Odd_Bloke> Ah, I don't have a foo.init.
<pitti> Odd_Bloke: but you need a dh-systemd build dep and "--with systemd", perhaps that's missing?
<pitti> Odd_Bloke: .init isn't strictly required, it is just necessary if you want sysvinit scripts to be able to depend on your service
<Odd_Bloke> Aha, no dh-systemd build dep.
<pitti> cjwatson: did you happen to run across a case where builds/tests were randomly SIGTERMed? https://launchpad.net/ubuntu/+source/notmuch/0.20.2-1build1
<pitti> cjwatson: I can't reproduce this in a local sbuild, but it seems repeatable on the LP build
<cjwatson> pitti: I'm only aware of LP buildds doing that in the case of idle-for-too-long, which doesn't seem to be true here.
<pitti> cjwatson: does that use alarm() or so? (the test might set that), or does it time it out from "outside"?
<cjwatson> pitti: This test suite has its own timeout, though; could it be that?
<cjwatson> pitti: It does use alarm(), but several layers of process out from anything the test suite should care about directly
<pitti> cjwatson: ah, looks like the previous few builds all FTBFSed too
<pitti> so this is not a recent thing, sorry for the noise
<pitti> last built in trusty
<cjwatson> pitti: Also, it would say "Build killed with signal <something> after <something> minutes of inactivity" if it were sbuild
<cjwatson> pitti: np
<cjwatson> pitti: Maybe your machine is just faster than the buildds ...
<cjwatson> Though the buildds aren't exactly slow.
<pitti> they must have a helluva precisely calibrated timeout :)
<cjwatson> The build log says the test suite has a two-minute timeout
<cjwatson> Maybe genuinely stalling for some reason, anyway
<pitti> right, /me stops worrying
<pitti> Riddell: wrt. https://launchpadlibrarian.net/213757621/buildlog_ubuntu-wily-amd64.k3d_0.8.0.3-7build3_BUILDING.txt.gz it seems test.hpp is gone from libboost1.58-dev; do you happen to know its replacement?
<pitti> this thing has rather little google juice, except https://svn.boost.org/trac/boost/ticket/10965 which doesn't really give a solution
<pitti> "For future reference, this stuff is in libs/math/include_private now. "
<pitti> but I don't see where that would be
<Riddell> pitti: I've no idea I'm afraid, it's a gnomey application ask a gnomey person
<pitti> Riddell: ah, thanks; just thought you might have stumbled over this before
<pitti> slangasek: OOI, as you mentioned in the meeting: is there a particular reason why the transitions tracker is like 6 hours behind? is that looking at a lagging mirror instead of ftpmaster perhaps?
<cjwatson> pitti: it's not?
<cjwatson> I mean, where are you seeing six hours?  http://people.canonical.com/~ubuntu-archive/transitions/ghc.html is a bit under an hour back, and the state it's referring to is reasonably recent
<cjwatson> Definitely well under six hours since I've done a couple of layers of that transition today
<pitti> cjwatson: e. g. https://launchpad.net/ubuntu/+source/libkexiv2/4:15.04.2-0ubuntu4 built 5 hours ago, but http://people.canonical.com/~ubuntu-archive/transitions/html/exiv2-g++5.html has all Xes
<pitti> https://launchpad.net/ubuntu/+source/strigi/0.7.8-1ubuntu5 even built 9 h ago
<cjwatson> That must be something else
<cjwatson> Not just staleness
<pitti> https://launchpad.net/ubuntu/+source/openimageio/1.5.17~dfsg0-1ubuntu2/+build/7766665 built 4 hours ago
<cjwatson> I'm not sure what; strigi should be unknown there, I'd have thought
<pitti> so yeah, bit weird
<cjwatson> The Xes don't mean "unbuilt", in any case
<slangasek> pitti: the tracker gets the answer wrong when the binary package names have changed.
<slangasek> (see discussion on #ubuntu-release yesterday w/ Laney)
<cjwatson> Ah right, it probably doesn't do a proper merge
<pitti> slangasek: ah! yeah, the bits that are stale look library-ish
<slangasek> it apparently goes "oh, this is the most recent version of this binary package from that source, and it has a wrong dependency, therefore the source package is 'bad'" and never looks at the fact that there's a newer source, with binaries built, none of which depend on the bad package name
<slangasek> and it's ben so I'm not going to try to debug it
<cjwatson> It would be simpler to do a merge out of band with the same logic we use in proposed-migration
<pitti> ack, thanks for the heads-up
<cjwatson> That is, discard would-be-NBS binaries from the old source if there's evidence of a newer build for that arch
<cjwatson> But you don't have to make the tracker green, anyway, it's just a convenience
 * pitti waves
<slangasek> cjwatson: not making the tracker green makes it very hard to use the tracker to coordinate work
<slangasek> so maybe I'll try to look at what p-m is doing
<cjwatson> slangasek: agreed
<cjwatson> "partial_upgrade" is probably the horrifying keyword to search for
<slangasek> ok, thanks :)
<sarnold> pitti: that's awesome news, re ampq tooling; thanks. (something we could run locally would also work, but canonical has more computers than I do :)
<infinity> sarnold: And whose fault is that?  Buy more computers!
<sarnold> infinity: sarnistack is gonna be awesome!
<slangasek> cjwatson: so I'm failing to find anything in proposed-migration matching partial_upgrade
<slangasek> cjwatson: is it 'partial_unstable'?
<cjwatson> slangasek: oh yes that
<cjwatson> brain failure, sorry
<cjwatson> the massive bodge I added for Ubuntu's suite layout, anyway :P
<slangasek> tdaitx: ^^ ok, this is what we're looking for, in lp:~ubuntu-release/britney/britney2-ubuntu
<slangasek> right :)
<tdaitx> slangasek, thanks =)
<slangasek> I assume this will mostly be illustrative of the concept rather than providing any code we can cut'n'paste ;)
<sl1rpy> okay, i was talkiing to someone in the main #ubuntu channel and supposedly paid apps show up in ubuntu 14.04 but i havent seen them show up in 15.04
<tdaitx> that works fine
<sl1rpy> i thought i saw them in 14.10 just fine
<slangasek> sl1rpy: not really the channel for this fwiw, but I believe that apps show up as available for each given Ubuntu release only after they've been tested for compatibility with it and marked as available?
<sl1rpy> ah.. because of newer libraries
<sl1rpy> makes sense now
<cjwatson> slangasek,tdaitx: right - the basic idea is just to try to work out whether binaries have been superseded by a newer build for the same arch even if the actual binary in question has gone away in the newer version, but this is complicated by things like binary versions not necessarily matching source versions, binaries changing from arch-dependent to arch-independent between versions, and other such things
<cjwatson> slangasek,tdaitx: I'm pretty sure proposed-migration gets it right now, but it took me several goes!  indeed you probably won't be able to cut-and-paste actual code, but it might be a good idea to make sure you have every step of the algorithm ...
<infinity> Is this an attempt to teach ben about partial suites and disappearing binaries?
<infinity> If so, wow.
<infinity> tdaitx: I don't know what you said in your interview, but I'm pretty sure you offended slangasek.
<slangasek> <snort>
<tdaitx> infinity, lol
<tdaitx> infinity, it is probably because I only mentioned IDL and php _after_ being hired =P
<cjwatson> infinity: It only needs to go in the wrapper, which is a lot less scary :-)
<cjwatson> Though also, I think, not in revision control anywhere
<cjwatson> http://paste.ubuntu.com/12016775/
<smoser> hey...
<smoser> i'm wanting to put mdadm into the cloud image
<smoser> but am not overly thrilled about pulling in
<smoser>  Recommends: default-mta
<smoser> anyone have thoughts on that?
<infinity> smoser: It likes to mail people when your raid is degraded.  It's a fairly valid thing, I'd say.
<infinity> smoser: One could take the opposite stance that anything without a hard dep on an MTA shouldn't have a recommends either, because admins know if they do or don't want one and are aware of the consequences.  But are they? :P
<smoser> i agree that it has good reason to use an mta
<smoser> but if i apt-get install... its unlikely that i'm going to configure my mta
<smoser> and if i expect you to later on decide to configure your mta in order to be told of failing disks, then you would probably realize you didnt have one when you went to configure it.
<smoser> probably would :)
<smoser> does that seem sane ? ie, we're Recommending you install an mta, but really we're Recommending that you install and configure your mta.
<infinity> smoser: I wouldn't object strenuously to dropping the recommends to a suggests, though it might be nice to convince the Debian maintainer(s) of that too, so we're not carrying a (nearly) pointless delta.
<smoser> i guess though if you already had one installed and then you install mdadm, the world is a happy place.
<smoser> ok. i think i'llf ile ubuntu and debian bugs and then maybe pick up a delta.
<smoser> thanks infinity
<ScottK> smoser: on a normal installation postfix will pop up via debconf and ask to be configured.
<infinity> ScottK: Yeah, but not if preinstalled in a cloud image.
<ScottK> Right, but I think that makes is a personal problem for cloudy things.
<infinity> ScottK: So, then he's entering "do I force this as a first-boot-config thing on users, leave it broken until they run dpkg-reconfigure, or not install at all".
<ScottK> On regular systems it works exactly as one would hope.
<ScottK> Sure, but I'm arguing don't screw up a working thing because cloud.
<infinity> ScottK: I'm pretty fence-sitty wishy-washy about anything that "recommends" an MTA, though.
<infinity> ScottK: Hard dependency, sure, go for it, you need /usr/sbin/sendmail, have at 'er, and I get to keep the broken bits when I configure it wrong.
<infinity> ScottK: But for optional functionality, I'm less convinced that it should ever be the default to install an MTA (at least in Ubuntu, where we tried to hard to get it out of the standard install in the first place).
<infinity> s/tried to/tried so/
<infinity> In Debian, it was more traditional to always have an MTA, so the recommends tended to be no-ops.
<ScottK> Is mdadm in the default install?
<infinity> No, but he's wanting to put it in the default cloud install.
<infinity> It also ends up in the "default" server install iff you install to raid.
<infinity> Not even sure what happens there, now that I think about it.
<infinity> d-i might install it without recommends.
<infinity> Or you might get a broken MTA.
<infinity> Or you might be forced to configure an MTA during install.
<infinity> I don't test that path often enough, clearly.
<ScottK> Also, postfix isn't a particularly heavy thing to install.
<infinity> ScottK: I'm sure mjt will have opinions.  He tends to have those.
<ScottK> So it'd probably be better, at least for now, to leave it be and smoser can preseed a no-op configuration if he doesn't want people to have to configure during install.
<infinity> ScottK: Most MTAs aren't heavy, but misconfigured MTAs are crap, and even after all the handholding exim and postfix gave people, they're still super good at doing it wrong.
<infinity> ScottK: Honestly, though, I think the recommends fails the test for what makes a recommends not a suggests.
<smoser> ScottK, i dont care so much about the configuration
<smoser> as the install will occur in the cloud image build process.
<ScottK> I see.
<smoser> i'd rather not have the mta installed. as it carries with it some megabytes i think are most likely not needed.
<ScottK> If not configured, postfix is safe.  Won't cause any problems.
<smoser> other than the megabytes
<infinity> Which matters when you're spamming images at N compute nodes, yes.
<ScottK> Installed-Size: 3568 seems like not much, but meh.
<infinity> smoser: Another option is to not add it to your usual packageset/seed/whatever, but to install it in a chroot hook with --no-install-recommends.
<infinity> ScottK: It all adds up.
<infinity> (But size is a stupid argument for avoiding a dep, the right argument is "is the dep level correct?")
<smoser> infinity, right. that could definitely be done, but that breaks "recommends by default". which we've not done up until this point
<infinity> If there's a significant reduction in functionality without an MTA, it's a recommends.
<smoser> (admittedly we're side-stepping that :)
<ScottK> I think that degradation notifications are pretty essential for mdadm.
<infinity> mdadm doesn't have a significant loss in functionality without an MTA, it just loses the spam feature.
<ScottK> The only way I think you don't want the mail is if you have nagios or something else letting you know.
<ScottK> I don't recall.  Does our mdadm continue through the boot process or not when degraded?
<ScottK> It's been yes or no at different time.
<ScottK> If the answer's no, then not knowing about the degradation would be bad.
<infinity> We used to boot degraded by default.
<infinity> We bloody well better still.
<smoser> so per apt , in cloud-image with recommends :
<smoser>  4,904 kB of additional disk space will be used.
<infinity> Cause it's a nightmare when not.
<smoser> without:
<smoser>  1,191 kB of additional disk space will be used.
<smoser> so that is 3.7M that it costs me in space, which is admittedly not a lot, but i'm trying to make images smaller as a general goal.
<infinity> smoser: And then shrink by zlib compression rate or whatever, cause unpacked rootfs size doesn't matter, it's size of the image you shove across the wire (AMIs, glance images, etc)
<infinity> smoser: Which are all compressed formats, I assume.
<smoser> well, yes. the size of the compressed transferrable image matters. but so does the size of the space taken up.
<smoser> when booted.
<infinity> smoser: Not nearly as much, though.
<infinity> Anyhow, like I said, size is the wrong argument.
<smoser> i dont know.
<infinity> If it's a legit recommends, don't cut corners because cloud is special.
<infinity> If it's not legit, downgrade to suggests.
<infinity> Argue until conclusion reached.
<infinity> smoser: Are cloud instances backed by multiple disks a really common use-case anyway?  Seems kinda entirely against the point of how cloud things are meant to work.
<infinity> "It's ephemeral, but I want RAID for redundancy" is just weird.  And "It's ephemeral, but I want RAID0 for speed" ignores the fact that you usually have zero control over your backing devices, and would have no way of knowing if you just slowed it all down by striping across two unknowns.
<smoser> people use raid on ec2 for performance
<infinity> Those people are weird.  But okay.
<smoser> the other motivating factor ..
<smoser> is that cloud images become maas images
<smoser> and maas images want to use raid (for hardware)
<smoser> and i want cloud images and maas images *more* the same
<infinity> And curtin can't "apt-get install mdadm" if it installed to raid?
<infinity> *cough*d-i*cough*
<infinity> Anyhow, I can argue both sides of this argument until I'm blue in the face.
<infinity> But you have to evaluate this on the merit of the dep, not your specific goal.
<ScottK> infinity: http://web.archive.org/web/20130313083303/http://netsplit.com/2012/10/30/goodbye-ubuntu was what had me wondering about what we did on degraded raid.
<ScottK> (yes, I did remember a three year old blog post)
<infinity> ScottK: Yes, I too remember that post.  I also remember the complete lack of bug reports or reference to what actually went wrong.
<infinity> ScottK: "It broke because my magic wasn't there."
<ScottK> You don't generally get those in the "I give up" blog post.
<infinity> ScottK: Yeah, but it also makes the rant entirely useless as a data point except "Scott hates us", which we already knew by that point. :P
<ScottK> It was mostly the mention of the didn't boot degraded event.
<infinity> ScottK: Yeah, but even that was wishy-washy enough to not know what actually happened, or what it was telling him.
<ScottK> True.
<infinity> ScottK: Anyhow, I remember having long arguments with people that booting degraded was the only sane thing on headless servers.  And I think that's the current state of things.  But maybe I should test that. :P
<ScottK> May be.
<infinity> But what I really need is someone to sell me pie.
<infinity> I failed to breakfast correctly, and lunched even more poorly, and now all I want is pie.  I think something broke me today.
<smoser> i do like pie
<infinity> smoser: An interesting ubuntu-specific compromise to the mdadm/mta argument might be to drop it to a suggests *and* make the cronjob spit out an angry update-motd snippet.
<infinity> smoser: That's slightly less visible than an angry email, but way more visible than a missed email in a blackhole of an unconfigured MTA.
<infinity> ScottK: ^-- thoughts?
<ScottK> Since we already have a diff, that might be OK.
<infinity> smoser: I think if my motd told me with intense anger on every login that my raid array was FUBAR, I might notice.
#ubuntu-devel 2015-08-07
<JanC> I think whatever "default MTA" gets installed should still be able to mail root even without manual configuration
<JanC> which is not the same as a "black hole"  :)
<JanC> maybe there can be a fake mail-transport-agent package on the cloud images that satisfies the dependency but doesn't actually do anything?
<JanC> lsb-invalid-mta seems to be exactly that
<infinity> JanC: Mailing root locally is no more useful than an motd, mind you.  You'll never noticed either one without logging in.
<JanC> infinity: that's mostly true (local mail would be kept, while a MOTD would probably be overwritten); maybe lsb-invalid-mta is better then, assuming (I didn't test) that mdadm would log a failed attempt to send mail
<infinity> JanC: motd would be overwritten by what?  We relay other messages via update-motd too (pending updates, required reboots, etc)'
<infinity> JanC: And I'm not suggesting removing the mail-sending part of mdadm.  If you have an mta installed and configured, it'll mail, yay.
<JanC> if there is an MTA that can do local delivery, all mails sent by mdadm would be stored locally (but I guess all that should be in the logs too anyway)
<infinity> JanC: I'm suggesting that an motd update is more useful than an mta you didn't want and thus didn't configure (or a null mta, or a local only mta, whose only indication that something's up is a "new mail in /var/mail/root" message, which you get on every login because of $random_cron_spam)
<infinity> JanC: Anyhow, there are lots of local-only mta options.  From my exposure to UNIX/Linux admins >= 10 years younger than me, no one will read that mail. :P
<infinity> YMMV.
<infinity> I grew up in the era of massive shared machines and local mail, most younger folks I see blindly ignore local mail spools for months.
<sarnold> besides, you set up nagios to check on your storage systems anyhow, right? right?
<infinity> sarnold: Ideally, yes.
<infinity> sarnold: Not sure there's such a thing as too many ways to be told a disk died. :)
<sarnold> infinity: hehe :)
<infinity> Although, the way I last found out a disk died was update-grub complaining it couldn't write to one of them...
<JanC> lsb-invalid-mta would possibly result in extra error messages showing up in nagios too  ;)
<infinity> (I got mail from mdadm shortly after, it was just entertaining timing)
<infinity> JanC: I honestly don't think lsb-invalid-mta is a reasonably solution to anything, ever.
<infinity> Either have a working MTA (local, smarthost, or full), or don't have one at all.
<infinity> One that returns an error on every invocation is worse than not having the binary.
<JanC> well, it would alert people who read logs about he fact that they could get mail
<infinity> But, y'know, yay LSB.
<infinity> JanC: You have pretty high confidence in people doing strange things like "reading logs for fun".
<infinity> I read logs when there's a problem.
<infinity> Not to see if there's a problem.
<infinity> Big difference.
<JanC> but then they will know they could have gotten a mail for the next time  :)
<sarnold> i've long wanted some smart tool to read my logs for me and let me know when there's a problem before I find it :)
<JanC> well, such tools exist...
<infinity> sarnold: I'm assuming that was facetious, since you mentioned that very tool a few lines up. :)
<sarnold> I used to use one of those log summary tools but it just turned into one more email that I mostly ignored each day. :)
<sarnold> infinity: do as I say, not as I do
<sarnold> infinity: (it actually comes back to that "not enough computers" problem; a laptop and an irc box aren't really enough to bring out nagios..)
<JanC> the trick is to not make them report useless stuff, of course
<JanC> sarnold: meaning that you just have to look at your IRC window to know both are up?  :)
<sarnold> JanC: exactly :)
<infinity> pitti: Which systemd package is it that keeps locking my unity session when it upgrades? :P
<infinity> pitti: Rather annoying.
<dholbach> good morning
<LocutusOfBorg1> Laney, hi, do you mind a syncpackage lucene++?
<LocutusOfBorg1> or dholbach maybe :) ^^^
<dholbach> taking a look in a bit
<LocutusOfBorg1> I merged the ubuntu v5 rename in Debian
<LocutusOfBorg1> as is :)
 * LocutusOfBorg1 I wish I could upload my packages directly to ubuntu :)
<dholbach> LocutusOfBorg1, synced
<LocutusOfBorg1> ta
<wgrant> chrisccoulson: Hi, you've just reverted my firefox arm64 FTBFS fix for the second time.
<n4176> hhh
<n4176> heell
<Laney> LocutusOfBorg1: thanks!
<LocutusOfBorg1> thanks to you for caring :)
<doko> barry, https://launchpadlibrarian.net/213724887/buildlog_ubuntu-wily-amd64.plinth_0.5-1_BUILDING.txt.gz
<barry> yep, django is the next big stack on the failure list to look at
<jcastro>  
<dobey> doko: hmm, can you upload a no-change rebuild of the "step" package? seems it wasn't in the gcc5 ppa and needed to be, and it's one of the transition blockers
<rbasak> smb, arges: add yourself to https://launchpad.net/~ubuntu-server please
<rbasak> smb, arges: then use https://code.launchpad.net/~ubuntu-server/+git/
<dobey> doko: or do you know if anyone from kubuntu team is working on getting the gcc5 issues in all the kde libs/apps fixed up?
<dobey> seems a lot there that needs simple rebuilds, and library package renames/symbols fixes
<doko> Riddell, ^^^
<doko> dobey, please ask the Kubuntu guys directly. I'm currently travelling
<dobey> doko: ok, thanks
<jtaylor> whats the reasoning for the ubuntu lvm install giving you a 200mb boot partition?
<jtaylor> thats maybe 6 kernels
<jtaylor> everytime a install a machine and forget it until the upgrades break :(
<ScottK> Set your grub to only keep 5 then.
<jtaylor> they to pile up in autoremove but I never run that
<jtaylor> I'm wondering what advantage does a boot partition even have?
<jtaylor> I usually just put it in root
<TJ-> jtaylor encrypted rootfs
<jtaylor> ah that makes sense
<TJ-> now when /boot/ is encrypted as well... :)
<melodie> hello
<melodie> does someone know about a good documentation to get started with pool and dist directories in ISO images? What they are meant for, how they are used, how to manage them? that kind of thing?
<melodie> never mind, I got my answers.
<melodie> gn
<asantos3> uhm, hi
<asantos3> I'm having a problem with an package update
<asantos3> thermald from 1.1~rc2-11 to 1.4.3-2
<asantos3> the problem happens when playing games
<asantos3> it drops my fps by a lot, can any dev help me or something?
<infinity> asantos3: Please file a bug ('ubuntu-bug thermald') and I'm sure the maintainer (cking) will poke at it on Monday.
<asantos3> infinity, should I file the debug on the ubuntu repo then?
<asantos3> because I don't know if it's ubuntu specific
<infinity> asantos3: As I said, type "ubuntu-bug thermald"
<infinity> asantos3: It's probably an upstream bug, but starting with us is still reasonable.
<infinity> asantos3: And our maintainer is also the Debian maintainer, and he contributes upstream.
<asantos3> ok, thanks
#ubuntu-devel 2015-08-08
<LocutusOfBorg1> Unit193, virtualbox-ext-additions accepted :)
<Unit193> LocutusOfBorg1: So it did, that was fast.
<LocutusOfBorg1> nowadays the new queue is processed so fast
#ubuntu-devel 2015-08-09
<doko> ScottK, could you update clamav to a version using llvm3.6?
<ScottK> doko: is this for Debian too?
<doko> ScottK, I don't care if debian wants to keep llvm3.5
<ScottK> I do because the person whose been adapting clamav to newer llvm releases really only cares about Debian.
<doko> well, why do lurk on this channel to ask about debian
<ScottK> Then I guess the answer to your original question is no.
<ricotz> slangasek, hi, could you take another look at coinutils -- https://launchpadlibrarian.net/213501143/coinutils_2.9.15-3_2.9.15-3ubuntu1.diff.gz -- there are e.g. "Provides: libcoinutils3" which likely needs tweaking
<ricotz> doko, ^
<slangasek> ricotz: does something somewhere depend on libcoinutils3?  I agree this is a bug but it seems to be very low-impact
<ricotz> slangasek, it is dependency of libreoffice which is switched to use its internal copy due it being in universe
<ricotz> so it is optional
<ricotz> besides that more important are audacity, scribus, vlc, kodi
#ubuntu-devel 2016-08-08
<cpaelzer> good morning
<sam_yan> HI,which program is related with the "kernel/ima/"
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<Laney> pkern: I can do, or we can re-backport from a later series
<Laney> pkern: (but I would have just been executing the backport for somebody else - in Ubuntu the actual backports team always ends up in Changed-By)
<LocutusOfBorg> hi doko how do you feel about a cython sync?
<LocutusOfBorg> or xnox
<LocutusOfBorg> little bit worried about s390x
<LocutusOfBorg> mmm segfault (ICE) on ppc64el
<LocutusOfBorg> I can't test s390x
<alf_> Hi all! I am seeing unexpected behavior with a systemd service we have for the repowerd package. The repowerd.service file 'Requires' another service which is missing on the desktop and thus repowerd.service correctly fails when trying to start it manually. However (this is the unexpected part), on system start-up the repowerd service actually starts without error, it seems like this dependency is ignored. Any idea what could be going on?
<LocutusOfBorg> hi, how can I programmatically retry all the builds of a particular package? I admit the web interface is not the best one to retrigger builds
<cjwatson> LocutusOfBorg: ubuntu-build --batch --retry <package> (from ubuntu-dev-tools)
<cjwatson> slightly weird CLI, not my fault :)
<Laney> Should probably make a release of ubuntu-dev-tools
<Laney> For https://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/1449
<xnox> my LED screens flicker
<xnox> is that a property of 16.04 LTS, or my dodge screens / graphics card?
<cjwatson> I would not be sad, I just didn't have effort for a release
 * xnox ponders if I am suffering from cross-talk
<cjwatson> probably
<LocutusOfBorg> thanks cjwatson :) that ubuntu-dev-tools impresses me each time more
<mwhudson> xnox: i have that a bit, intel graphics?
<xnox> mwhudson, yeap
<mwhudson> xnox: much more noticeable on displayport but i think it still happens on hdmi
<mwhudson> nothing in dmesg when it happens
<LocutusOfBorg> bad ubuntu-build! why you don't give back s390x?
 * LocutusOfBorg pulls the new ubuntu-dev-tools
<cjwatson> LocutusOfBorg: Oh yeah, possibly should have warned you about that
<Laney> LocutusOfBorg: I could have highlighted you then, sorry
<LocutusOfBorg> no need to be sorry! I like to learn :)
<Laney> i'll make a note to upload that to Debian (or you can)
<LocutusOfBorg> and the code is pretty obvious
<LocutusOfBorg> http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/1449
<LocutusOfBorg> found (damn why I didn't read above?)
<dholbach> didrocks, one for your: https://code.launchpad.net/~jbicha/ubuntu-make/autopkgtest-depend-on-debounce/+merge/301355 :-)
<didrocks> dholbach: oh, thanks!
<dholbach> anytime :)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> apw, linux needs a rebuild against binutil 2.27 once it's built on all archs
<doko> LocutusOfBorg, dholbach: gnutls28 ftbfs
<jtaylor> hm there seems to be a problem in boot ordering with iscsi in 16.04
<jtaylor> it tries to mount the disk before starting the iscsi daemon
<LocutusOfBorg> I know
<jtaylor> though it seems to still work as it times out and tries again later
<Mirv> doko: any news on the --secure-plt problem on powerpc? it does not seem to be specified on the g++ line, so it's coming from some defaults.
<doko> Mirv, yes, gcc is configured with --enable-secureplt
<Mirv> doko: so it should be disabled for powerpc? is there ETA for a fixed build or a workaround to get a package to build on powerpc meanwhile?
<doko> Mirv, what are you trying to "fix"?
<Mirv> doko: getting the "/usr/bin/ld.gold: --secure-plt: unknown option" on powerpc
<doko> Mirv, don't use gold on powerpc
<Mirv> doko: ok, so something like -Wl,-fuse-ld=ld could work before finding where to remove gold usabe more generally on powerpc?
<dholbach> doko, I commented on the bug
<doko> Mirv, well, where do you enable gold, it's not enabled by default
<doko> dholbach, ta
<Mirv> doko: yes, I'll find the core place too, but right now I'm trying to get one package built. probably qtbase's mkspecs.
<Mirv> doko: anyway, if you don't have a workaround to suggest, thanks anyway for suggesting to disable gold on powerpc so that I can find that place
<doko> Mirv, passing -Wl,-fuse-ld=ld doesn't guarantee that it is passed in the correct order ...
<LocutusOfBorg> dholbach, any idea for gnutls28? I can't really reproduce locally
<LocutusOfBorg> retrying with parallel builds
<dholbach> LocutusOfBorg, no, me neither
<dholbach> did this test fail anywhere else before?
<xnox> doko, working with smr and google-mock maintainer to package new google-test for updated (non-segfaulting) gtest and gmock
<xnox> i see some build failures with segfaults due to gtest
<Laney> xnox: even with the alleged fix?
<LocutusOfBorg> dholbach, never saw it
<xnox> hm, i shall re-check if it has already been retried with updated gtest. i thought it was.
<LocutusOfBorg> let me triple check something
<dholbach> LocutusOfBorg, I was wondering if it came up in any other bug report before
<LocutusOfBorg> I got probably the failure
<LocutusOfBorg> let me see
<doko> xnox, seen in more than one package?
<xnox> yes, gtest itself and one of its reverse deps
<xnox> so far i'm not much help
<xnox> fixed dbus-cpp & that should fix biometryd
<LocutusOfBorg> hi arm*, do you want pretty please start building stuff?
<hjd> https://launchpadlibrarian.net/276634687/buildlog_ubuntu-yakkety-amd64.openhft-lang_6.7.6-1_BUILDING.txt.gz is a build failure with an odd failing test.
<hjd> It might be a flaky test, because I've rebuilt locally because while I have been able to trigger it, when I tried to investigate more, it built successfully.
<hjd> Any suggestions?
<jbicha> yeah I saw that test, now is not now
<jbicha> I don't have any advice on it though
#ubuntu-devel 2016-08-09
<cpaelzer> good morning
<mardy> Mirv: about QTBUG-55087, Tiago didn't reply, but I think I got a fix
<mardy> Mirv: I'm going to write a unit test, then submit a patch
<Mirv> mardy: ok, sounds really great! maybe he's working weird hours, and he'll probably then comment on the code review request then.
<mardy> Mirv: bad news, I didn't actually fix it :-/
<Mirv> ok :(
<happyaron> anyone can look at the SRU queue of xenial for network-manager?
<LocutusOfBorg> maybe on #-release? :)
<happyaron> yeah..
<rtg> doko, apw - Yakkety linux-4.4.0-34.53 is building in ppa:canonical-kernel-team/bootstrap using gcc 6.x and binutils 2.27-2ubuntu2
<juliank> https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule still says "DRAFT RELEASE SCHEDULE, UNOFFICIAL UNTIL RATIFIED BY THE RELEASE TEAM AFTER AN RFC" - what's up with that?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1610714 => How to get this SRU'ed ? :)
<ubottu> Launchpad bug 1610714 in poppler (Ubuntu) "Evince crashes with _cairo_gstate_set_dash" [Medium,Confirmed]
<seb128> dupondje, get somebody with upload right to upload?
 * juliank just noticed he forgot to nominate the APT SRU bug for xenial and did it
<dupondje> seb128: don't you have that? :D
<seb128> dupondje, right, nice try
<seb128> I would perhaps if I didn't have a meeting in 7 minutes and stack of other things to do
<seb128> you can maybe try didrocks or kenvandine who are on pilot shift today
<Laney> xnox: can you test build vlc on some s390x box you have access to with the current yakkety toolchain and then give d_oko what he needs to get the ICE fixed please? :-)
<juliank> dupondje: Let's at least nominate the bug for xenial first
<juliank> Having some time outs
<juliank> These launchpad timeouts are really annoying
<juliank> Meh, I'm only getting timeouts when trying to nominate this for xenial
<juliank> I might retry later
<dupondje> hÃ©hÃ© :(
<xnox> Laney, sure.
<Laney> thankee
<didrocks> seb128: I don't have any official time allowed for piloting
<seb128> didrocks, yeah,most people seem to have no time for it nowadays anyway (even less than it used to be)
<mterry> I'm getting "At least one invalid signature was encountered" when trying to apt update from yakkety...  is that expected?
<mterry> (from archive.ubuntu.com)
<juliank> dupondje: I updated your SRU bug with the xenial target
 * juliank is not going to upload it though - SRUing GUI apps is to scary for him
<juliank> dupondje: Screw that. Did not seem to scary
<juliank> dupondje: That is, I verified that it fixes the bug and uploaded it.
<juliank> Hmm, somebody else did already
<juliank> dupondje: Ah no, the version is wrong
<juliank> What do we want for that? 0
<juliank> 0.41.0-0ubuntu1 => 0.41.0-0ubuntu1.1 it seems
<dupondje> juliank: err crap, missed that.. Been to long ago I did some bugfixing ;)
<dupondje> thx :)
<Beret> 1
<Unit193> 2
<tsimonq2> 3
#ubuntu-devel 2016-08-10
<cpaelzer> good morning
<Mirv> cjwatson: would https://code.launchpad.net/~timo-jyrinki/click/dont_use_@_in_testscontrol/+merge/302514 fix the autopkgtest failure?
<jtaylor> LocutusOfBorg: I figured out why clang is not working in 16.04
<jtaylor> having gccgo-6 installed breaks it
<jtaylor> it selects gcc6 then but that installation is incomplete
<xnox> mwhudson, doko, see jtaylor ^ sounds like fun
<jtaylor> bug 1611676
<ubottu> bug 1611676 in llvm-toolchain-3.8 (Ubuntu) "clang++ does not work with gccgo-6 installed" [Undecided,New] https://launchpad.net/bugs/1611676
<doko> jtaylor, well, fix that silly clang ... there are absolutely no c++ headers
<cjwatson> Mirv: approved, feel free to try it :)
<Mirv> thanks!
<cjwatson> seems plausible at least
<doko> cjwatson, cyphermox: filed https://bugs.launchpad.net/ubuntu/+source/grub/+bug/1611740  I think I talked with cyphermox about it at the last sprint. do you can think of anything which still uses it?
<ubottu> Launchpad bug 1611740 in grub (Ubuntu) "remove grub, superseded by grub2" [Undecided,New]
<showaz> ubuntu â clamav-unofficial-sigs v3.7.2 (updated 2013-08-25)
<showaz> https://github.com/extremeshok/clamav-unofficial-sigs - 20 July 2016 (5.4.1)
<Mirv> cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#click :( now the configure is searching for packagekit-plugin, when the test rebuild runs
<cjwatson> doko: pass
<cjwatson> doko: trace paths through grub-installer I guess
<cjwatson> Mirv: debian/tests/run-tests.sh needs to do the same thing that debian/rules does - run debian/packagekit-check and if it says "no" then add the --disable-packagekit option to configure
<cjwatson> Mirv: actually, TBH it could probably just pass --disable-packagekit - the integration tests don't need it
<doko> cjwatson, so recursively look at all dependencies for a grub dependency?
<cjwatson> Mirv: (unconditionally, I mean)
<cjwatson> doko: no, I mean the code.
<doko> ahh
<cjwatson> doko: grub-installer is the d-i component that installs the actual grub package needed for the system
<cjwatson> it probably still has some paths where it installs grub or grub-legacy, rather than some grub2ish grub-whatever package
<cjwatson> so if you want to remove grub you need to work out whether those paths are still relevant
<cjwatson> and you probably also need to work out what to do about upgrades which I think we may have punted on in Ubuntu
<cjwatson> you cannot just say "no dependencies left, it doesn't matter"
<doko> ok
<jtaylor> hm wasn'T clang in xenial patched to support gccs abi tags?
<jtaylor> still get linking errors with boost
<showaz> jtaylor: ? http://apt.llvm.org/
<Mirv> cjwatson: ok, thanks
<jtaylor> showaz: I'm refering to the 1:3.8-2ubuntu4 update
<showaz> ubuntu too old upstream software
<doko> showaz, there is no newer release
<showaz> 3.9
<showaz> 4.0
<doko> no, there is no release
<showaz> 4.9-prelease/rc
<showaz> 3.9*
<ginggs> jtaylor: llvm 3.8 in xenial is still not quite right, see LP: #1610957 - i'm currently using a backport of 3.81 in yakkety
<ubottu> Launchpad bug 1610957 in llvm-toolchain-3.8 (Ubuntu Xenial) "LLVM CMake files broken by Debian packaging" [Undecided,New] https://launchpad.net/bugs/1610957
<showaz> ubuntu-llvm used "ninja" for build/deploy?
<cyphermox> doko: cjwatson: the only way you install grub (legacy) with grub-installer is if you were about to install grub-pc and someone preseeded grub-installer/grub2_instead_of_grub_legacy=false
<seb128> hum
<seb128> is pad.ubuntu.com working for others?
<seb128> it gives me a "Failed to discover an OpenID server"
<Laney> there is something going on
<Pici> looks like launchpad is down.
<Laney> I just got pagerduty calling me
<seb128> launchpad wfm
<Laney> about some kind of socket timeout
 * Laney screams
<seb128> Laney, is #is the right channel for that?
<seb128> or is there a #is-something for services
<Laney> seb128: they should know I guess
<seb128> I asked there
<seb128> let's see
<Laney> seb128: #is-outage has some activity, guessing it's known
<juliank> APT master has completed the switch to CMake. I specifically wrote the translation part so that we generate per-domain templates with headers now (build/po/libapt-pkg5.0.pot, build/po/apt.po, etc), so Launchpad can import them correctly. I hope it works...
<juliank> In case you're wondering: Yes, launchpad has not imported apt translations for quite some time.
<juliank> This should mean that langpacks can ship updated translations for apt again
<seb128> juliank, great ;-)
<cjwatson> LP> there was/is a switchover to a new firewall system which seems to have gone a bit wrong, not sure yet whether it's been totally fixed / rolled back
<solarce> any chance anyone here has a contact with whomever at Canonical is involved in building and
<solarce>  publishing the Ubuntu GCE images?
<cyphermox> solarce: what problem are you seeing? maybe we can solve it right here, otherwise we can get you in contact with the right people
<solarce> cyphermox: it seems like the setting to disable ipv6 by default in the GCE VMs was lost in an update to the images, at least for Trusty. But I'm not sure which because we just went from a 2015 release toa 2016 release yesterday
<solarce> cyphermox: we were based on ubuntu-1404-trusty-v20150909a before and now we're based on ubuntu-1404-trusty-v20160627
<solarce> cyphermox: https://github.com/travis-ci/packer-templates/commit/94f32ea4a6bb8c56c9dd3677a5c4708678b6ae8b#diff-8ed6e32f5d271c8bce697243861ea28aL31
<solarce> cyphermox: we (travisci) because our build environment GCE images off the official Ubuntu ones, we do a packer + chef build process to customize it
<solarce> cyphermox: is the tooling that's used to build the images for GCE public?
<cyphermox> solarce: ok
<solarce> i've been digging around, http://blog.utlemming.org/2014/11/gce-anyone.html indicates three people to reach out to in #ubuntu-server, so i've taken my question there
<juliank> solarce: Did you guys also notice some network/port issues on trusty travis? The apt tests cannot seem to connect to ports on localhost they opened before. I'm not entirely sure what the cause of that is, but it used to work until yesterday
<solarce> juliank: yes, it seems to be a side effect of ipv6 being enabled
<solarce> juliank: we're building new trusty images with ipv6 disabled via sysctl.conf and should have that live in an hour or two
<juliank> solarce: Great.
<solarce> it took a long time to notice because most of the user bug reports where things like selenium failing to bind a port, etc
<solarce> life in the cloud
<solarce> cyphermox: thanks for the help
<cyphermox> solarce: yeah, you'd want Odd_Bloke to respond to questions I guess
<solarce> we got in touch in #ubuntu-server
<cyphermox> ok good :)
<infinity> GunnarHj: You around?
<Unit193> I am.
<GunnarHj> infinity: Yep
<infinity> GunnarHj: Looks like https://sourceware.org/bugzilla/show_bug.cgi?id=9809 (and the patch we carry for it) needs updating for 2.24
<ubottu> sourceware.org bug 9809 in localedata "ckb_IQ: new Kurdish Sorani locale" [Enhancement,Waiting]
<infinity> GunnarHj: That's just the first failure I hit, I suspect most of our out-of-tree locales will need updating (because of Unicode 8.0)
<infinity> GunnarHj: See, eg https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/10596201
<infinity> GunnarHj: Side-note, I really wish we didn't have out-of-tree locales. :P
<infinity> (Backported ones from trunk, sure, but not random locales from wherever)
<GunnarHj> infinity: I'll take a closer look. Are you saying they fail to build in next glibc version? As regards new locales, once in a while it's justified to be fast for motivational purposes. When a group of people wants to establish a new language, they shouldn't need to wait for months/years IMO. (But those situtations don't happen very often.)
<GunnarHj> infinity: Will compare the patches which bring additional locales, and compare them with one of the 'established' ones. Getting back to you.
#ubuntu-devel 2016-08-11
<tgm4883> Can SRUs include the removal of features?
<RAOF> tgm4883: Under extreme circumstances, yes.
<tgm4883> RAOF: hmm, ok. I'll take a look at fixing this
<mwhudson> sigh, michael wait for the accepted mail before going to lunch
<noalternative> I am trying to compile fifth browser into a deb.  I am inexperienced, and I am trying to follow the hithear instructions & I am getting errors.  I have successfully compiled hithear, but I am trying to apply lessons to fifth browser.  Here are the hithear instruction.  I am at debuild -us -uc  https://wiki.debian.org/Packaging/Intro
<noalternative> now the errors http://pastebin.com/Ph5QPcWX
<sarnold> noalternative: your first message was cut off mid-way through the URL
<sarnold> noalternative: what does 'file' report on the fifth_0.4.orig.tar.gz file?
<noalternative> https://wiki.debian.org/Packaging/Intro?action=show&redirect=IntroDebianPackaging
<noalternative> I am not sure what you mean.
<noalternative> maybe I named it wrong?  I downloaded this from source forge, not github
<noalternative> tried to rename the file according to instructions.
<noalternative> https://sourceforge.net/projects/fifth-browser/files/v0.4/
<noalternative> admttedly the original was not a tar.gz
<noalternative> so I simply renamed it
<noalternative> is that what your getting at?
<noalternative> I just wanted to complie the browser for my personal use not as a package maintainer
<tgm4883> noalternative: you can't just rename it
<noalternative> ok
<tgm4883> what was it previously?
<noalternative> fifth-0.4.txz
<sarnold> try something like fifth-_0.4_orig.tar.xz
<tgm4883> sarnold: with the dash in there?
<sarnold> I wanted to see what 'file' thought the file is. it might be empty. (that happens). it might be an HTML error page from some stupid download site. or, it might be an xz'd file rather than gzipped file :)
<sarnold> tgm4883: nah, probaly better withuo the dash
<sarnold> wow
<sarnold> how long until tab-complete can just type my thinking for me.. not soon enough
<noalternative> http://pastebin.com/KA1nVLzY
<noalternative> It liked the original name I think.
<tgm4883> noalternative: you should name it fifth_0.4.orig.tar.xz
<sarnold> I detest the "rename the tarball" step. so. annoying.
<tgm4883> I agree
<sarnold> because I can never guess the name to use correctly on the first try, I always wind up having to copy-and-paste the demanded name from this error message :)
<sarnold> (you've seen my typing, this shouldn't be a surprise :)
<noalternative> We made some headway, but it ultimaely retruned errors.  I can't cut and paste all of it from my terminal because my terminal stops before the command was given.
<noalternative> Is there a log I can paste?
<noalternative> or maybe a specific part of the terminal like the part about errors.
<noalternative> Here are errors from a file called fifth_0.4-1_amd64.build
<noalternative> http://pastebin.com/TeCS4BWC
<infinity> tgm4883: You absolutely can just rename orig tarballs.
<tgm4883> infinity: you can just rename an orig tarball from a .tar.xz to .tar.gz?
<infinity> tgm4883: Oh.  No.  I missed the context, I guess. ;)
<tgm4883> infinity: hah yea, I didn't think you could do that. I guess I should have said can't just change the extension
<tgm4883> although you kinda can, if you know what you're doing
<infinity> tgm4883: Not in a way that keeps dpkg happy and the file unchanged. :P
<infinity> Pick one.
<tgm4883> infinity: well in this case, we had to change .txz to .tar.xz
<infinity> 'tar xf' autoguesses these days, but dpkg-source ain't having none of that modern nonsense.
<tgm4883> although maybe we didn't need to do that and just rename it to the proper format
<infinity> tgm4883: Oh, sure, tgz == tar.gz, etc, though.
<tgm4883> yep
<Laney> Mirv: trying a test build of ffmpeg ...
<Laney> cross your toes
 * sil2100 crosses his toes too
 * Mirv crorres toes and fingers
<cjwatson> Mirv: so ... would you be sad if I just fixed that click test rather than approving your hack, given that I know how to do it and it's fairly easy having spotted the problem?
<cjwatson> Mirv: https://code.launchpad.net/~cjwatson/click/new-debsig-policy-url/+merge/302652
<Mirv> cjwatson: terrible! (thank you)
<Mirv> replacing the silo MP with that
<Laney> 'k, that built
 * Laney copies
<cjwatson> Mirv: thanks; I tested it enough locally that I think it's good
<Mirv> Laney: \o/
<Laney> gizza builder, launchpad
<seb128> hum, does anyone has an idea what's wrong on bug #1611256?
<ubottu> bug 1611256 in ubuntu-release-upgrader (Ubuntu) "X to Y upgrade fails with gconf2 depends on python3:any; however: Package python3 is not configured yet." [Critical,Confirmed] https://launchpad.net/bugs/1611256
<seb128> xenial to yakkety upgrades are hitting that
<seb128> "dpkg: dependency problems prevent processing triggers for gconf2:
<seb128>  gconf2 depends on python3:any; however:
<seb128>   Package python3 is not configured yet."
<doko> apw, when do you plan to upload the updated kernel to y?
<xnox> doko, in two weeks when he is back from vac?
<xnox> =)
<ogra_> they allowed him vac ?!?
<ogra_> carzy kernel team ...
<ogra_> *crazy too
<doko> LocutusOfBorg, what are you saying in 1608129? build it once without the tests, and then reenable the tests?
<LocutusOfBorg> or build-conflict with itself
<LocutusOfBorg> your solution seems good too
<LocutusOfBorg> BTW I already asked ginggs but you might want to upload this patch http://paste.ubuntu.com/23021246/
<loladiro> Hi folks, hope this is the right channel. Iâve been looking for the `dash` debug symbol package, but been unable to find it. Any pointers?
<xnox> loladiro, https://wiki.ubuntu.com/Debug%20Symbol%20Packages did not help?
<loladiro> Nope, tried that, but neither dash-dbg nor dash-dbgsym seemed to exist
<xnox> loladiro, yeah weird.
<xnox> pitti would be the person to ask, but I don't see him online atm (holidays?!)
<cjwatson> dash has a very old-fashioned debian/rules that doesn't use debhelper, so that'll be why
<xnox> ah
<xnox> tru, dh_strip is not called.
<loladiro> So, no debug symbols for me then :(?
<cjwatson> it should be pretty easy and quick to build locally
<cjwatson> not a complex package
<loladiro> Yeah, absolutely
<loladiro> Iâm not really interested in dash actually, but was just using it as a test case for some automation - guess I picked the wrong thing ;)
<loladiro> Should I file some sort of bug report so this doesnât get forgotten for future versions, or is this known and will be fixed anyway
<cjwatson> I think it would be reasonable to file a bug asking for debug symbols (though a solution-neutral bug - it may be easier to just bodge the one or two necessary lines into debian/rules than to convert the whole thing to debhelper, as a downstream)
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/dash/+filebug
<LocutusOfBorg> I would open a bug in Debian
<cjwatson> that's only a good idea if you can come up with a reasonable way to make it applicable to Debian
<loladiro> Alright, bug filed. Appreciate the quick response folks.
<cjwatson> http://debug.mirrors.debian.org/debian-debug/pool/main/d/dash/ similarly doesn't exist, so that may be such an argument
<LocutusOfBorg> yes, the strip is done in a really obscure way
<LocutusOfBorg> https://sources.debian.net/src/dash/0.5.8-2.3/debian/rules/
<LocutusOfBorg> converting into some new format will fix the issue for both OS
 * xnox moved IRC from a US vps to the one in docklands, so much better =)
<xnox> http://memesvault.com/wp-content/uploads/Dog-Meme-Wow-Wallpaper-03.jpg
<rbasak> stgraber: https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1612116
<ubottu> Launchpad bug 1612116 in juju-mongodb (Ubuntu) "please remove juju-core-1 and juju-mongodb packages from yakkety" [Undecided,New]
<xnox> rbasak, whilst juju-2 is still saying that it may not be used for production use?!
<xnox> how does one connect and/or deploy things with juju in yakkety then?
<stgraber> xnox: I just commented in the bug that I don't think we should do this until Juju 2.0 is released and stable
 * xnox hits F5
<rbasak> xnox: don't ask me!
<setuid> If I've pulled a package 'bar' with a BD on foo, which then uses 'import foo' in its code, but there's no RD on 'foo', removing 'foo' will break 'bar'. Does a BD incorporate foo.py into bar? Or did I just find a bug?
<LocutusOfBorg> b-d don't incorporate runtime dependencies for python packages
<LocutusOfBorg> usually they are listed in setup.py install_requires
<LocutusOfBorg> and the parses and replaced with debian dependencies into python:Depends substvar that is evaluated during build by dh_python2 and replaces the dependencies with some runtime stuff
<LocutusOfBorg> but if install_requires is not available... the maintainer has to list them in runtime-Depends
<LocutusOfBorg> for libraries is easier
<setuid> LocutusOfBorg, So sanity check this for me; python-keystone has a BD on python-ldappool, and keystone/core/core.py does an 'import ldappool', but installing python-keystone doesn't install python-ldappool
<setuid> So installing python-ldappool on its own will satisfy that r-d, but will break when removed (no deps depend on it)
<setuid> sorry, keystone/common/ldap/core.py
<setuid> imports ldappool
<setuid> there's a changelog entry showing the b-d being added, but they missed the r-d
<mterry> seb128: can you reject a lightdm upload I just made to vivid accidentally?  Got my dput arguments in the wrong order and for some reason haven't disabled 'ubuntu' as the default location
<mterry> Or any archive-admin I guess really  :)
<infinity> mterry: Done.
<mterry> infinity: thanks -- I've now fixed my dput too
<LocutusOfBorg> setuid, you seems to be right, setup.py has no install_requires keyword, so the dependencies are not picked up (and nor explictly listed on Depends: of the runtime package)
<ahoneybun> cyphermox: you work on the slideshow right?
<ahoneybun> for the installer
<cyphermox> ahoneybun: yes
<ahoneybun> are the sizes in the slideshow.conf strict?
<ahoneybun> like it HAS to be that size?
<ahoneybun> reason I'm asking is because QtWebkit is broken in Qt4 or something and we are making our slideshow in qml
<ahoneybun> not html
<bdmurray> jbicha: for bug 1063019 you could use the Errors bucket for the crash as a test case
<ubottu> bug 1063019 in gnome-contacts (Ubuntu Xenial) "gnome-contacts-search-provider crashed with signal 5 in contacts_ensure_eds_accounts()" [Medium,In progress] https://launchpad.net/bugs/1063019
<ahoneybun> heyo our installer slideshow is broken with 1 week before freeze
<juliank> Would be nice if the apt 1.2.14 SRU in the queue would be processed at some point :)
<bdmurray> juliank: which release is that for?
<juliank> bdmurray: xenial, the 1.2.X series is the stable APT series for xenial
<juliank> bdmurray: In case you're wondering: The release is from Jun 22; it was supposed to be synced a month ago or so, but getting the new APT with the same bugfixes into yakkety was a bit complicated, so it was delayed some time.
<juliank> There will be a 1.2.15 update at some point in the future merging bugfixes from the 1.3~pre1, 1.3~pre2, 1.3~pre3, 1.3~rc1 releases; but not in the immediate future.
<juliank> 1.2.14 basically  brings us up to 1.3~exp2 in terms of important bug fixes
<juliank> oops, ~exp3
<juliank> 1.2.15 will then fix the issues with ZFS module stuff not allowing you to autoremove kernels, amongst other things
<juliank> (That will be an awful release to do, so many changes to look at and see what should be backported/cherry-picked)
<juliank> Also need to wait for pitti so we can set up autopkgtests for that stuff before we upload it...
<juliank> Oh dear, I also have to update the 1.0.9.8 series for Debian stable ...
<jbicha> bdmurray: thanks, I see that there's a lot of errors on trusty for that gnome-contacts bug, so do you want to accept the sru for trusty too now (just uploaded)?
<Term1nal> Question: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5696.html
<ubottu> net/ipv4/tcp_input.c in the Linux kernel before 4.7 does not properly determine the rate of challenge ACK segments, which makes it easier for man-in-the-middle attackers to hijack TCP sessions via a blind in-window attack. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696)
<Term1nal> What does DNE stand for in that listing?
<sarnold> Term1nal: does not exist
<sarnold> Term1nal: it means that package doesn't exist in that release
<Term1nal> Ah.
<Term1nal> So... DNE is saying, what... patch not needed for that specific issue?
<sarnold> right; for example, the linx-lts-trusty package doesn't exist in trusty, 16.04, 16.10, etc..
<Term1nal> So is this page effectively saying that there's no fix needed for 16.04?
<sarnold> Term1nal: the 'linux' package on 16.04 is marked 'needed'
<Term1nal> ah
<sarnold> Term1nal: the linux ones are far more complicated than the other packages.. you've got to know which source package generated the kernels you're using in order to really read the page
<Term1nal> Can't wait until the DDoS kiddies figure out how to exploit this and sell it as a service O.O
<sarnold> hey great business idea!
<sarnold> I mean
<Term1nal> :P
<sarnold> yeah that'll be trouble...
<Term1nal> I guess what I'm trying to figure out.. is a currently up-to-date patched 16.04 machine vulnerable to this CVE still or?
<Term1nal> Cause, sure, it's fixed in 4.7 kernel. But obviously we're not using 4.7 out of the box.
<sarnold> it's certainly forced to to think about TCP slightly differently; 2^32 gaurantees are ...  not impressive. with so many machines on the internet moving so many packets of data each second, 1/2^32 happens all the time..
<sarnold> Term1nal: you're affected. We expect the fix to land around august 27
<Term1nal> Neato, that's a nice specific timing.
<sarnold> the kernel team works on a three-week cadence; patches in one portion, testing in another portion, publish on a date; it normally works out pretty predictably
<Term1nal> Let's just hope PoCs aren't released before then and used to start the next poodlecorp
<Term1nal> Odd though, isn't it typical to have these sorts of CVEs announced once a patch is ready to go?
<sarnold> we do, we release USNs, e.g. http://www.ubuntu.com/usn/usn-3055-1/
<sarnold> this issue came out at an inconvenient time to fit into the release that was released last week, so it's in the current cycle, which should be released in ~two weeks..
<sarnold> we also mail our USNs to a moderate-traffic mail list https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
<Term1nal> I get those USNs through RSS
<juliank> Hmm, I messed up the apt 1.3~rc1 a bit - I did not consider the ubuntu-specific config file in the packaging. I'll fix this tomorrow.
<juliank> And what's going on with all those dlsym(acl_set_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_set_file?
<juliank> Well, the config stuff kind of happens when you switch to a new build system and rewrite the packaging rules.
<TheMuso> c
<TheMuso> whoops
<Term1nal> Oh, please package latest Golang toolchain for 16.04, thanks! <3
<Term1nal> Have fun you hard workin' folks
#ubuntu-devel 2016-08-12
<juliank> Seriously? My upload was rejected with "Symbolic link for debian/copyright not allowed", but it syncs fine from Debian?
 * juliank is annoyed
<juliank> I guess I go back to no debian/copyright at all
<juliank> (No, it's not required to have one. apt never had one, it installed COPYING instead. Now I made copyright a symlink to that)
<juliank> I mean: Why? I don't want to have that file twice in the package, and a symlink is better than just installing the file in the upstream part.
 * juliank uploaded a fixed build now, tomorrow we'll see if something breaks
 * juliank goes to bed
<cyphermox> ahoneybun: I don't think it *has* to be that size, but the aspect ratio for things matter, since they really should show in that panel size -- the size of the slideshow shouldn't vary from slide to slide, or from flavor to flavor
<ahoneybun> cyphermox: at the moment ours is broken since Qt4 dropped Webkit
<cpaelzer> good morning
<doko> juliank, apt test failures on ppc64el
 * xnox only 16 more merges to go....
<juliank> doko: Thanks, I'm about to look into this
<doko> juliank, this is likely LP: #1473674. but at this time, we couldn't distill a test case.  maybe you see the same when building with -O3 on amd64
<ubottu> Launchpad bug 1473674 in apt (Ubuntu Wily) "apt fails a test from the testsuite on ppc64el when built with gcc-5 and -O3" [High,Confirmed] https://launchpad.net/bugs/1473674
<juliank> doko: Probably. There's also a real bug in the stringview tests, though (comparing data() with to_string(), where data() might not be nul-terminted). I accidentally turned the test suite to actually fail the build at build time with the cmake switch; I think I'm going to revert this. Too much inexplicable noise on exotic platforms
<juliank> Well, I can also switch ppc64el to -O2 in addition
<juliank> doko: Oh, your -O2 rebuild even hid the real test failure
<doko> juliank, a test case would be nice. still not convinced that this is a compiler issue
<juliank> doko: Well, there are only two previous returns in the function called before it sets the InfoDir variable. and I don't see how those could fail. I guess I'd have to look at the binaries, but I don't really speak much ppc64el
<juliank> Well, and we don't have any, obviously, because the -O3 build failed due to the test suite ...
<doko> The following tests FAILED:
<doko>           1 - AptTests (Failed)
<doko> juliank, ^^^ on amd64 with -O3
<juliank> doko: Same failure? (MIght need to set CTEST_OUTPUT_ON_FAILURE=1 if you're running manually)
<juliank> I'm letting it build at -O3 now too
<juliank> doko: I cannot reproduce this on Debian at least (with gcc 6.1.1-11), still have to try in my yakkety env.
<juliank> doko: In the Ubuntu env (with gcc -10ubuntu11), I see test failures with -O3, but not in CDROM. Basically the string_view thing I already mentioned, and some weird random failures I don't know what to think about
<doko> juliank, the only difference should be PIE turned on by default. ok, so the CDROM thing is ppc64el specific, as it was already before
<LocutusOfBorg> please somebody ignore systemd/ppc64el autopkgtestsuite, for gnutls30, and retry the network-manager one
<juliank> doko: I had a DSL reconnect, what was the last line that arrived?
<Unit193> < juliank> doko: In the Ubuntu env.....
<juliank> Ah OK
<Unit193> (And he responded.)
<juliank> I can say with -11ubuntu12 things look a bit better even
<juliank> Unit193: anything interesting in the response?
<ginggs> [10:50:28] <juliank> doko: In the Ubuntu env (with gcc -10ubuntu11), I see test failures with -O3, but not in CDROM. Basically the string_view thing I already mentioned, and some weird random failures I don't know what to think about
<ginggs> [10:51:16] <doko> juliank, the only difference should be PIE turned on by default. ok, so the CDROM thing is ppc64el specific, as it was already before
<juliank> Thanks ginggs
<Unit193> Sorry.
<ogra_> any archive admins around ? i need the score bumped on https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/2796
<xnox> they all are cleaning, looks suspicious.
<ogra_> xnox, the arm arches are slow since last friday ... (and often lie in the estimated time ... telling you "starts in 20min" for multiple hours)
<xnox> ogra_, i'm not sure why, i've just uploaded a package and it started to build on armhf....
<xnox> i guess i jumped the queue somehow?
<xnox> Build score:2510 (What's this?)
<xnox> Start in 8 minutes (2505) What's this? -> that's you
 * xnox ponders why you are 5 points lower
<ogra_> because i'm a snap perhaps
<ogra_> or because i build against a PPA
<cjwatson> snaps are all 2505 + <relative_build_score of archive>
<cjwatson> maybe it would be fairer to have the baseline be 2510 these days, because most uploads are priority: medium
<cjwatson> urgency=medium I mean
<xnox> yeah
<cjwatson> so the effect ogra_ is seeing is probably mainly that the queue of .dsc builds to perform is rarely empty, and that snaps effectively only get to build after all of those
<cjwatson> ditto recipes and livefses
<cjwatson> ogra_: I've bumped that build's score and I'll look at making the defaults a bit fairer
<ogra_> can https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux/+build/2797 be bumped too please ?
<ogra_> cjwatson, thanks !
<cjwatson> ogra_: done
<ogra_> merci :)
<ogra_> uhm, oh
<ogra_> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~ogra/+junk/canonical-snapdragon-linux-snap": no supported schemes
<ogra_> (https://code.launchpad.net/~snappy-dev/+snap/canonical-snapdragon-linux)
<ogra_> i assume the team cant use my personal branch here ?
<ogra_> so lets try that again with me as the snap owner
<xnox> ogra_, +git, not +junk
<ogra_> :P
 * xnox trolling
<ogra_> yeah, i'll switdh all that stuff to git eventually ...
<cjwatson> it should be fine with +junk branches; but you deleted that snap before I could look at what the problem was
<dbarth> hey guys, i'm trying to get an SRU for account-plugins to -proposed
<ogra_> cjwatson, i only switched the name ...
<dbarth> it's sitting in the UNAPPROVED queue, as silo 062
<ogra_> cjwatson, https://launchpad.net/~ogra/+snap/canonical-snapdragon-linux/+build/2797
<dbarth> the reference bug is: https://bugs.launchpad.net/gnome-control-center-signon/+bug/1565772
<ubottu> Launchpad bug 1565772 in gnome-control-center-signon (Ubuntu Xenial) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,Confirmed]
<cjwatson> ogra_: that looks like either a transient failure or a firewall bug
<ogra_> oh+
<cjwatson> I doubt that the path has anything to do with it
<ogra_> well, the bzr login stuff above the error made me thing the account is related
<cjwatson> I suspect you thought wrong
<cjwatson> buildds obviously don't have an actual Launchpad login to use
<ogra_> for that snap it isnt that important who owns it, it will be re-named once we get a proper name ... and will then get its own project ... new buuild is triggered, lets see if it was transient
<cjwatson> so you should generally expect to see that warning
<ogra_> ok
<cjwatson> (well, perhaps that isn't obvious, but it's nevertheless true)
<doko> seb128, Laney: are you planning a gedit merge? if not then we need a no-change upload for nbs
<ogra_> cjwatson, worked the second time
<cjwatson> ok, must be terrible presentation by bzr of a transient error, I guess
<juliank> Can we please fix the upload queue thing to allow packages where debian/copyright is a symlink? It works for syncs, I really don't want to cp my target to debian/copyright before doing an ubuntu-specific upload. And no, I neither want to ship copyright information twice in apt, nor do I only want it in debian/. We previously had no debian/copyright at all and that produced less issues than this symlink :(
<juliank> That is, apt ships it's copyright info in the top-level COPYING file
<juliank> (aka upstream part, if we ever get non-native)
<cjwatson> juliank: can't do straight away, please file a bug against Launchpad; at the time we wrote it I'm pretty sure our check matched Debian ftpmaster so we need to check what the current one is
<juliank> cjwatson: Sure https://bugs.launchpad.net/launchpad/+bug/1612612
<ubottu> Launchpad bug 1612612 in Launchpad itself "Should not reject packages where debian/copyright is symlink" [Undecided,New]
<seb128> doko, jbicha is looking at it but he's blocked by gspell test issues
<sitter> mvo: yo. python-apt changes I mentioned in Heidelberg, was wondering if you have some thoughts on the direction https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release also I have no clue how one would propose them for inclusion in the debian repo :S
<juliank> sitter: Basically just say something and mvo or I will merge them
<sitter> that's easy then. thanks
<juliank> I really need to get a 1.1 release out at some point, apt is already at 1.3 ...
<juliank> It's just fairly annoying work to port this away from the deprecated API to the new one, so we end up with the "beta" (aka still using deprecated stuff) releases
<mvo> sitter: what juliank said
<mvo> sitter: from a quick look looks fine, there is a debug print() in there still
<mvo> sitter: (but I guess you know that :)
<sitter> yeah. it's basically the working tree I abandoned in favor of the simpler workaround ;)
<juliank> doko: I revised your apt workaround a bit to take care of noopt, and prepend instead of append, and arrived at https://github.com/Debian/apt/compare/master...julian-klode:bugfix/gcc?expand=1
<juliank> Probably going to merge this for RC2
<juliank> sitter: Should probably use the official VERSION_CODENAME instead of / in addition to UBUNTU_CODENAME
<juliank> see bug #1598212
<ubottu> bug 1598212 in base-files (Ubuntu) "/etc/os-release: Please specify VERSION_CODENAME" [Undecided,New] https://launchpad.net/bugs/1598212
<sitter> *nod*
<juliank> Someone needs to fix fakeroot? dlsym(acl_get_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_get_file
<juliank> This breaks a lot of the APT test suite in the glibc migration
<juliank> I have no clue what's going on there.
<juliank> I already saw this in the build logs that night
<juliank> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830912
<ubottu> Debian bug 830912 in fakeroot "fakeroot complains about missing acl_* symbols" [Normal,Open]
<juliank> glibc fixes "Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]"
<juliank> meh, I guess I'll take a look at it. Most apt bugs are fixed now anyway, so I have time
<juliank> Well, it was a good idea, but it hang up my system
 * juliank hopes schroot will use cgroups at some point, so the chroot processes can be grouped and killed reliably
<sitter> juliank: I did some minor polishing, should be good for merge now https://github.com/apachelogger/python-apt/commits/aptsources-distro-os-release
<sitter> mvo: FWIW, that's what the software-properties side of things will look like http://bazaar.launchpad.net/~apachelogger/software-properties/python-apt-is-like/revision/970 (basically restricting the match further by requiring that the the local distro `is_like` the distro of the PPA)
<mvo> sitter: thanks
<juliank> sitter: Can you squash those commits together?
<juliank> I cannot reproduce the fakeroot warning issue in my yakkety system, but it seems like that should work around it: https://paste.ubuntu.com/23049438/
<sitter> juliank: done
<juliank> sitter: Some more stuff, use line.split("=", 1) in case there are multiple = - Your ID_LIKE use does not match the spec/manpage: ID_LIKE should be ID_LIKE="ubuntu debian", not unquoted.
<juliank> Relevant quotes: (1) Variable assignment values must be enclosed in double or single quotes if they include spaces
<juliank> (2) Example: for an operating system with "ID=centos", an assignment of "ID_LIKE="rhel fedora"" would be appropriate
<sitter> hm
<juliank> I know, right?
<sitter> worse yet, that is actually the production os-release file from kde neon, so it is actually broken there ^^
<cjwatson> ogra_: https://code.launchpad.net/~cjwatson/launchpad/fairer-build-scores/+merge/302807 FYI
<juliank> I uploaded a work around for the tons of fakeroot warnings now
<ogra_> cjwatson, yay, thanks !
<juliank> It's not optimal as it just hides the errors again, but better than having them printed in every build and test log (and making the apt testsuite fail)
<sitter> juliank: I pushed fixes for both
<juliank> sitter: Fails on Debian unstable: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for debian/None
<juliank> Probably because VERSION_* is not specified
<sitter> juliank: yes
<sitter> probably should fall back to LSB if a field is None
<sitter> juliank: http://paste.ubuntu.com/23049533/ any objections to this solution? reads both, then gets os-release value unless it is None, in which case it gets the value from lsb_release
<juliank> doko: <DonKult> juliank: so, I tried building apt on the pcc64el porterboxâ¦ and I can reproduce the -O3 thing there. And I can fix itâ¦ e.g. by adding "CD = CD;" in apt-pkg/cdrom.cc at line 68 (<- right after we might have set InfoDir). Haven't played much more yet, but if that isn't screaming compiler bug I don't know what is.
<juliank> sitter: You can use this.get(key) or that.get(key) instead of this.get(key) if this.get(key) else that.get(key)
<sitter> juliank: cool. pushed
<cyphermox> juliank: did the way apt reports progress on Status-Fd change recently?
<juliank> cyphermox: Well, rc1 in proposed might report some more stuff
<juliank> But apart from that, I'm not sure
<juliank> sitter: Still fails, though - not sure why: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for debian/sid
<sitter> juliank: template's are case sensitive, ID supposedly is lowercase in os-release. so it should be Debian/sid but is debian/sid
<juliank> Ah, right
<sitter> I am thinking either the template system should be case indepdnent or os-release on debian needs changing. former sounds more appropriate xD
<juliank> hmm, that's work :(
<sitter> ID actually is specified as lower case, so yeah, template lookup needs changing :/
<sitter> hm
<sitter> juliank: http://paste.ubuntu.com/23049655/ should be as trivial as this if I am understanding the code correctly
<juliank> sitter: Well, try it out. Run PYTHONPATH=$PWD ./tests/test_all.py (or ./tests/test_aptsources.py)
<juliank> same problem should happen on Ubuntu too
 * juliank did not check that yet :D
 * juliank is about to start cooking and also fixing apt bugs or at least merging the commits he did earlier
<cyphermox> juliank: ok, because it looks like progress percentage is now reported on Status-Fd is localized
<cyphermox> ie. percentage may be 33.333 or 33,333
<cyphermox> hrm, maybe it's not apt
<doko> juliank, yes, but trying to reduce this to a simple reproducer doesn't look that easy. Can you come up with a test case which doesn't involve the library?
<juliank> doko: DonKult is looking into it
<doko> infinity, fakeroot probably needs an update for dropped (?) glibc symbols?
<juliank> doko: I updated fakeroot to silence the warning
<juliank> doko: glibc now added error reporting to dlsym() which was not there before
<juliank> The acl symbols mentioned were never in libc in the first place
 * juliank is not sure what the right course of action for this is longer term
<juliank> This at least brings is back to the 2.23 state.
 * juliank mostly cares because it breaks the apt tests ...
<doko> juliank, one more thing: https://bugs.launchpad.net/bugs/1584118  how is a package selected when I only install the virtual name?
<ubottu> Launchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Incomplete]
<sitter> juliank: lower on both sides makes test_aptsources pass with ID=ubuntu. That's however not actually useful at all. e.g. I also noticed the if-wall in get_distro() is comparing with "Ubuntu" etc.. So I am thinking this either needs a concious API compatibility break in that distro ids get downcased consistently and file mapping/matching ignores case, or we do a weird hack and use os-release NAME instead of ID (which IMO would defeat the purpose
<sitter> and require random splitting), or we change the patch to only grab is_like out of os-release and continue to take the rest from lsb (least invasive)
<sitter> If we assume os-release is the long-term target I doubt a compatibility break will be avoidable
<juliank> doko: I don't really know in detail. I guess it just fits the first package it sees
<doko> ok
<doko> mvo, ^^^
<juliank> doko: I'd simply create a real package with the virtual name and let it depend on the preferred one. This has guaranteed semantics
<juliank> Relying on APT's implementation details is not such a good idea.
<infinity> doko: IIRC, it picks the virtual provider with the highest sort order (cf: the time when libfooN-dev used to provide libfoo-dev, and we wanted "Build-Depends: libfoo-dev" to usually pick the highest)
<infinity> doko: But, as juliank says, relying on even that is a poor substitute for forcing the issue.
<infinity> juliank: You referenced the Debian bug in your fakeroot upload, but didn't forward the patch to the Debian bug? :P
<juliank> infinity: Not yet at least, but the idea was mentioned in that bug
<infinity> juliank: Yeah.  But a quick "submittodebian" turning Aurelien's suggestion into an actual patch is always nice. :)
<juliank> infinity: Right. Later on. I just wonder: Did I really leave the Bug-Ubuntu field with <bugnumber> int it?
<juliank> I have no idea how that happened
<infinity> juliank: Yes, you really did. ;)
<infinity> juliank: I wasn't going to point that out. :P
<juliank> I have to cook now, but I'll try to send the patch out
<juliank> infinity: done
<tyhicks> bdmurray: hey - are you ok with me re-adding the verification-done tag to bug 1528230 after the last two comments that I left?
<ubottu> bug 1528230 in apparmor (Ubuntu Xenial) "[ADT test failure] linux: ubuntu_qrt_apparmor.test-apparmor.py -- ONEXEC - check current 'unconfined' != expected" [Medium,Fix committed] https://launchpad.net/bugs/1528230
<juliank> doko: that seems to be the culprit: https://paste.debian.net/788746/
<juliank> For whatever reasons DirectoryExists() had __attribute__((const))
<juliank> Still not sure how the compiler completely optimises that away, though
<juliank> It must think that DirectoryExists(<string constant ".disk">) always is false
<juliank> or rather, that it must be false at some point
<juliank> I think because it is a string literal, the compiler assumes that because we cannot know the address of the literal, we cannot make a defined choice in DirectoryExists(), and thus drops the whole part
<dobey> sigh
<juliank> Apparently the code is not dropped, but the input is some garbage instead of the actual value.
<juliank> Which makes sense: If the function is const and takes a reference, and you pass it one constant, it must have the same result if I replace the constant with garbage.
<juliank> s/constant/literal/
<juliank> Did something change on the autopkgtest systems? It seems as if  acquire::https::proxy is set to "direct" - APT does not understand this, only "DIRECT".
<juliank> The apport tests thus fail with Unsupported proxy configured: direct:
<juliank> Nevermind, apport test suite is broken and we now added a check for invalid proxy methods...
<juliank> Will upload fixed apport in a few minutes
<juliank> should be fixed in -0ubuntu6
<slangasek> mterry: hrm, why is /etc/lightdm/lightdm.conf.d/90-phablet.conf being injected by livecd-rootfs, instead of being shipped in the lxc-android-config package?
<mterry> slangasek: I'm not sure; I likely made it originally though.  It should probably move
<slangasek> ah, I see, this file is 3 years old already, I thought it was added in the latest upload :)
<slangasek> but yes, your name is on the original commit also :)
<bdmurray> tyhicks: yes, that makes sense to me
<tyhicks> bdmurray: ok, thank you
#ubuntu-devel 2016-08-13
<tdaitx> slangasek, is there something I can run in a command line that will tell me how a given "Depends:" field will be resolved by apt? I can always build a dummy package and see how it goes, but I suspect there should be a smarter way to go about it
<xnox> tdaitx, there isn't...
<xnox> and apt & aptitude do things differently.
<xnox> tdaitx, what is the magic Depends stanza you are trying to use?
<tdaitx> xnox, k, thanks... yeah, I think I remember something about apt/aptitude behaving differently (do you have pointers on that? it would be good to know exactly how they differ)
<xnox> tdaitx, just try things out. But even for a simple field, things can be resolved differently in an overall / upgrade transaction.
<tdaitx> xnox, it's a simple one, I just want to make sure I won't be misleading users on a bug report
<xnox> tdaitx, so what are you trying to test =) what's your stanza?
<xnox> which bug?
<tdaitx> xnox, just some combinations of javaX-runtime and openjdk-X-jre
<tdaitx> xnox, lp: #1584118
<ubottu> Launchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Incomplete] https://launchpad.net/bugs/1584118
<xnox> multiarch / virtual packages / other fields / alternates resolutions / other installed packages / priorities / pinning -> all have funny corner cases.
<xnox> tdaitx, look at this -
<xnox> http://paste.ubuntu.com/23050611/
<xnox> if someone depends on "java-runtime-headless" in a package Depends, an arbitrary one can be selected including opnjdk-9-jre-headless
<xnox> ditto "java-runtime"
<xnox> ditto java8-runtime.
<tdaitx> xnox, I assumed there was a "right" order for that selection
<tdaitx> like, comparing the available versions
<xnox> in the metadata, these days one can do versioned provides.
<xnox> but the metadata on e.g. openjdk-9-jre has version-less provides
<xnox> which defaults to the package version itself
<xnox> and thus openjdk 9 has the highest version.
<jbicha> xnox: I'm not sure that versioned provides work though
<xnox> jbicha, it works when there is a versioned depends on a virtual package
<jbicha> ok
<tdaitx> xnox, "these days" -> do you recall when that started being supported?
<xnox> tdaitx, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7330
<ubottu> Debian bug 7330 in dpkg "dpkg: support versioned Provides" [Wishlist,Fixed]
<xnox> tdaitx, but what worries me is the actual bug report of brekage in java9
<xnox> "We are not compatible with Java 9 because there is a change in
<xnox>    command line argument order and the JVM fails to start."
<xnox> --> is there one that is compatible and is correct across 8 & 9?
<xnox> was that intentional to use jdk9 as jdk8 provider by default?
<tdaitx> xnox, I don't know what their particular problem is because they didn't provide examples for that
<tdaitx> xnox, yes, openjdk 9 was supposed to be released somewhere around xenial/yakkety release, but then it got postponed
<xnox> is it still intentional for jdk9 to provide jdk8 in xenial then?
<xnox> maybe that provides should be dropped?
<xnox> their depends is wrong as well.
<tdaitx> yep, I have been thinking about this for a while
<xnox> imho they should be doing "Depends: java8-runtime (<< 9~)"
<xnox> but that needs to be tested first.
<tdaitx> I'm not sure openjdk-9 should be marked as providing a jdk8, given that we don't even have an official openjdk-9 and - worse - it is badly broken right now
<xnox> yeah, those that need/want openjdk-9 can have it.
<xnox> but i don't think it should be forced on others.
<xnox> however, I am not a release / sru team to judge a revert of jdk8 from being provided 9 back to 8.
<xnox> infinity, slangasek ^
<tdaitx> xnox, and doko should be involved as well
<tdaitx> xnox, unfortunately it seems that "Depends: java8-runtime (<< 9~)" does not work as expected... installing a dummy package with that dependency and then trying apt-get -f install get's the package removed
<tdaitx> I was trying a few combinations before, unfortunately versioning it does not help
<xnox> btw, tdaitx did you know about http://eric.lubow.org/2010/system-administration/creating-dummy-packages-on-debian/ for quickly building fake packages?
<xnox> tdaitx, =(
<tdaitx> hmm, no, I didn't
<tdaitx> I have a package called "dumb" that I use for those tests, just debuild it and then install on a chroot/lcx instance for tests
<tdaitx> I keep that skeleton around just for those cases
<tdaitx> but equivs seems much better
<xnox> but then |apt-ftparchive packages ."
<xnox> should be run as well, and add a "source" to a directory with fake packages too.
<xnox> beacause "apt-get install" is one thing and "dpkg -i & apt-get install -f" are two different beasts =)
<tdaitx> hmm
<xnox> argh
<xnox> Updating from such a repository can't be done securely, and is therefore disabled by default.
<tdaitx> xnox, you probably know this, but just use "deb [trusted=yes] file:///"
<xnox> ah [trusted=yes] -> did not know that trick =)
 * xnox quickly signed the repository and imported the key
<tdaitx> so asking for a version on "Depends:" only works when the control file has a "Provides:" that is versioned as well, otherwise unversioned "Provides:" are ignored... thus right now "Depends: java8-runtime (<< 9~)" will not work because no openjdk package versions its "Provides: java8-runtime" field
<tdaitx> according to the debian bug #7330
<ubottu> Debian bug 7330 in dpkg "dpkg: support versioned Provides" [Wishlist,Fixed] http://bugs.debian.org/7330
<infinity> xnox: The versioned dep would only work if it was a versioned provides, which it isn't.
<infinity> xnox: And dropping the provides entirely also won't work because the version in the release pocket will still have it.
<infinity> tdaitx: ^
<infinity> tdaitx: The only fix is a real package called java8-runtime, as real packages always take precedence over virtuals if you have none installed.
<tdaitx> infinity, updating openjdk-9 and removing the provides wouldn't fix it, is that what you mean?
<infinity> tdaitx: Right.
<infinity> tdaitx: Since the version in the release pocket will always be there, and will always have the provides.
<infinity> tdaitx: (In xenial, that is)
<tdaitx> oh, sure
<infinity> tdaitx: Removing it would absolutely fix yakkety.
<tdaitx> that makes sense
<tdaitx> got it
<doko> juliank, thanks for finally tracking that down
<juliank> doko: David did all the work, I'm just the messenger :D
#ubuntu-devel 2016-08-14
<tgm4883> Are packages released from yakkety-proposed automatically? I uploaded 2 packages a few days ago and 1 is still sitting in proposed
<tgm4883> or at least it's not showing updated on packages.ubuntu.com
<jbicha> tgm4883: https://wiki.ubuntu.com/ProposedMigration
<jbicha> tgm4883: did you look at the update excuses page?
<tgm4883> jbicha: thanks
<jbicha> do you see the unsatisfiable depends?
<tgm4883> jbicha: no, is there another page I should be looking at?
<tgm4883> Some status page for each package maybe?
<jbicha> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<tgm4883> jbicha: I don't see my package on there, although my phone doesn't really like that page. I'm assuming it's in alphabetical order
<jbicha> tgm4883: oh it's a very large page, here's an excerpt: https://paste.fedoraproject.org/408096/raw/
<tgm4883> jbicha: thanks. Not sure why that can't be satisfiable
<jbicha> mythbuntu-bare is in universe but mythtv-common is in multiverse
<tgm4883> Ah
<jbicha> you'll need to file a bug against mythbuntu-bare asking for it to be moved to multiverse and subscribe ~ubuntu-archive
<tgm4883> jbicha: still not 100% sure why that is though. Wouldn't that have been an issue when they were first uploaded?
<jbicha> I'm guessing Ubuntu didn't have an automated check for that then
<jbicha> I have 2 mythbuntu related merge proposals
<jbicha> https://code.launchpad.net/~jbicha/mythbuntu/drop-gconf-override/+merge/301017
<jbicha> https://code.launchpad.net/~jbicha/mythbuntu/dont-depend-on-gtk-engines/+merge/301016
<tgm4883> I can take a look at those of superm1 isn't around
<jbicha> I'm not sure about the gconf one, see the attached bug for it
<tgm4883> jbicha: if I'm reading that correctly, you're setting a new way to not pop up the update notifier dialog?
<tgm4883> ah ok, just read the bug report
<jbicha> I'm not sure what that does since I didn't test it, but what you have now doesn't work at all
<tgm4883> jbicha: for this other one, is there any way to merge from this page?
<tgm4883> Or do I need to checkout/merge/push
<jbicha> you have to use bzr
<tgm4883> jbicha: ok
#ubuntu-devel 2017-08-07
<weasel> moo.
<weasel> On Debian, I'm dropping my tor-dbg package in favour of having the toolchain auto-build the -dbgsym package.
<weasel> I notice that the toolchain on Ubuntu builds dbgsym ddebs when pkg-create-dbgsym is installed.
<weasel> Are packages supposed to build-depend on that?
<weasel> (/me is also building binaries for all the ubuntus for deb.torproject.org)
<Unit193> weasel: They are not supposed to build-depend on that, and in artful and above Ubuntu is using a slightly modified debhelper to build dbgsym packages with a 'ddeb' extension.
<weasel> ok.  So for my backport builds, the build environment is supposed to just have pkg-create-dbgsym installed?
<weasel> how do I avoid getting almost empty .ddeb packages that aren't good for anything (and shouldn't exist) when building things that still do classic -dbg packages?
<Unit193> Depending on the version of debhelper, you can force Debian style dbgsym packages without pkg-create-dbgsym by setting DH_BUILD_DDEBS=1, in eg .pbuilderrc.  But yes, pkg-create-dbgsym in the build-env would be fairly normal I *think*.  As far as dbgsym packages that only depend on the -dbg packages, I don't know how to skip ehtm, never looked into it.
<weasel> ah
<weasel> it has a dependency on the -dbg.
<Unit193> (For reference: https://launchpad.net/ubuntu/+source/debhelper/10.2.5ubuntu2)
<weasel> that makes it actually useful.
<Unit193> debhelper has also been backported to Xenial, so one could technically use the DH_BUILD_DDEBS=1 trick, but not sure that's what you're going for.)
<weasel> well, I want to build binaries for precise, trusty, wily, xenial, yakkety, and zesty.  with the minimal amount of fuss and ugly :)
<weasel> thanks, I think I'll figure something out.
<Unit193> Very understandable, thanks for doing that too!
<Unit193> You can also wait for someone that knows the subject better.
<weasel> I guess the thing to do is make pkg-create-dbgsym be installed in anything pre-artful,
<Unit193> Sounds like a plan.
<weasel> and use the debian sid package unmodified.  (at least when it comes to the dbg stuff)
<weasel> (source package, that is)
<Unit193> The fun part may be if you mess with --dbgsym-migration..
<weasel> I'm not sure I want to bother.
<weasel> but yes, it's something I have thought of.
<f_g> anybody else getting Timeout Errors when filing bugs @ LP?
<Unit193> LocutusOfBorg: Thanks, also random:  < Unit193> I know you're no longer here, but just chef holding ruby-net-ssh back in proposed, either just a bump to allow newer, or the bump and https://github.com/chef/chef/pull/5726/commits/24d230b09a68c8b6857d060b398e779a23ba80bc would fix it.
<LocutusOfBorg> Unit193, .
<LocutusOfBorg> why you no MOTU?
<Unit193> I've got a packageset...Also, I should do that one in Debian since specinfra is in. >_>
<Unit193> (Though that has Ubuntu delta anyway, so will have to do both..)
<LocutusOfBorg> Unit193, I can give you dm for debian, just give me a list of packages
<LocutusOfBorg> but please apply for MOTU
<Unit193> Will go through the normal pkg-ruby process for it, but I should look into MOTU again it seems.
<mwhudson> omg python3-defaults migrated
<LocutusOfBorg> mwhudson, congrats!
<LocutusOfBorg> Unit193, https://launchpad.net/ubuntu/+source/chef/12.14.60-2ubuntu4/+build/13210735
<Unit193> LocutusOfBorg: There's no ruby-net-ssh bump as is needed for the version in -proposed.
<LocutusOfBorg> patch?
 * mwhudson glares at the pytest in -proposed
<mwhudson> lol @ http://autopkgtest.ubuntu.com/packages/p/python-ltfatpy/artful/armhf
<mwhudson> i presume the version without the build1 is marked badtest
<mwhudson> hmm nope
<LocutusOfBorg> Unit193, ^^ do you have a patch?
<LocutusOfBorg> wrt ruby
<Unit193> LocutusOfBorg: Yep, just testing now.
<mwhudson> sil2100: hey ubuntu-image autopkgtests fail now that py35 is not supported
<mwhudson> Test-Command: tox -e py35-nocov,py36-nocov
<mwhudson> sil2100: just s/py35-nocov//?
<LocutusOfBorg> thanks
<sil2100> mwhudson: yeah, that should do it - although we'd have to create a delta for the stable series
<mwhudson> sil2100: i don't suppose the py36-nocov tests pass on xenial either?
<mwhudson> i guess you can do something involving py3versions -vs
<sil2100> mwhudson: well, if the given interpreter is not available then the test is skipped
<mwhudson> ah
<sil2100> So py36-nocov doesn't cause a failure on xenial at least ;)
<mwhudson> well that will start working again in artful sooner or later
<sil2100> But yeah, this could be done better
<mwhudson> but not quite yet
<Unit193> LocutusOfBorg: Testsuite takes a bit...
<sil2100> mwhudson: you need this to be unblocked? I guess it'll be fine for you to do that change as a manual upload for now
<sil2100> I'll overwrite it with our next bigger release, which will probably take a while, I expect then the interpreter will be gone
<mwhudson> sil2100: it's not blocking anything i'm super desperately waiting on but sure
<Unit193> LocutusOfBorg: Gift wrapped: https://deb.li/3hIXF
<fossfreedom_> anyone from the DMB around?  The agenda dates are need updating and there appears to be 3 candidates for the next meeting.  True? https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
<LocutusOfBorg> uploaded thanks
<mwhudson> sil2100: https://launchpad.net/ubuntu/+source/ubuntu-image/1.1+17.10ubuntu4
<Unit193> LocutusOfBorg: FYI, all Ubuntu delta is actually committed in the chef git repo. \o/
<LocutusOfBorg> so upload in debian?
<Unit193> Already pinged someone, yep! :D
<sil2100> mwhudson: looks good, thanks!
<Unit193> LocutusOfBorg: BTW, ruby-net-ssh-gateway and ruby-net-ssh-multi are held up on net-ssh, if they are re-tried with 4.0+, they'll pass.
<Unit193> http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#ruby-net-ssh-gateway
<LocutusOfBorg> I think I did them
<Unit193> Ran against old net-ssh still.
<Unit193> http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=amd64&package=ruby-net-ssh-gateway&trigger=ruby-net-ssh-gateway/2.0.0-1&trigger=ruby-net-ssh/1:4.1.0-1
<Unit193> \o/
<Unit193> As always, thanks muchly.
<ouroumov> Hello, it's my opinion that there is something currently wrong with the instructions to sign the Ubuntu code of conduct. I followed to the letter the procedure to do that on launchpad, used seahorse to create the key, then attempted to gpg --clearsign with --default-key option, which according to google would clear a "gpg: no default secret key: secret key not available" error. Thing is, nothing worked, until I used "gpg2" instead of "gpg".
<LocutusOfBorg> :)
<sil2100> jamespage: hey! One final thing I'd like to have before formally accepting the MRE for openstack is: could you provide me with a list of openstack packages this exception would cover? Since the openstack packageset is quite big - are all of these needed for the exception? Are all of those updated to new upstream releases frequently?
<sil2100> jamespage: (e.g. http://people.canonical.com/~ubuntu-archive/packagesets/artful/openstack )
<jamespage> sil2100: its a subset of that list
<jamespage> sil2100: do you just want me to add a list to the wiki page?
<sil2100> jamespage: yeah, would be perfect, once you have a moment just add it to https://wiki.ubuntu.com/OpenStackUpdates somewhere at the beginning
<Unit193> LocutusOfBorg: Do you know if http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=amd64&package=chef&trigger=ruby-net-ssh/1%3A4.1.0-1 needs re-run, or if it's good due to the latest run?
 * Unit193 is learning the autopkgtests infra.
<LocutusOfBorg> Unit193, I'm waiting for the update excuses to refresh :p
<jamespage> cpaelzer: morning - are you planning an update for dpdk -> 17.05.1 ?  Prepping the ovs-2.8 branch snapshot and tripping over some build failures
<cpaelzer> jamespage: hi
<cpaelzer> jamespage: I expected you to have a public holidy today
<cpaelzer> jamespage: first of all thanks for the work on the arm specific character console
 * jamespage checks he should be working...
<jamespage> nah I don't live in scotland
<cpaelzer> jamespage: I updated the bug, last status is that I hope (diminishing) to make 3.6 happen and that would mean fixed in artful, otherwise I fall back to the backports for artful
<cpaelzer> jamespage: yes we are working on dpdk 17.05.1 already
<jamespage> cpaelzer: awesome
<cpaelzer> jamespage: there is a OVS patch actually blocking this
<cpaelzer> but I'm just back from PTO I need to check if it was accepted in the meantime
<cpaelzer> jamespage: will you be on the september sprint to sync on this and so much more?
<jamespage> cpaelzer: ovs 2.8 advertises 17.05.1 support (infact it ftbfs with the current version in artful)
<jamespage> cpaelzer: if you can stage 17.05.1 in a bileto ppa, I'll upload what I have and we'll see if it works :-)
<jamespage> cpaelzer: hope you had a nice break btw
<cpaelzer> nice until I saw my inbox, but that was expected :-)
<cpaelzer> jamespage: still waiting for https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/334891.html to be accepted
<cpaelzer> jamespage: but if I upload the latest packaging as it is prepared (but not yet released) it will need that
<jamespage> cpaelzer: I can pick that and then poke upstream to get that into the 2.8 branch (hopefully)
<cpaelzer> jamespage: let me sort that out and provide you something in a ppa with all but the change that requires this, so you can then try OVS-2.8
<jamespage> cpaelzer: ta
<cpaelzer> oh yeah, another "pro" voice would be nice
<jamespage> cpaelzer: "o make 3.6 happen and that would mean fixed in artful" - libvirt bits right?
<cpaelzer> Let me sort out how complex things are, I might provide two ppa's
<cpaelzer> jamespage: yes  that comment was on libvirt
<cpaelzer> jamespage: I'll ping you on a dpdk 17.05.1 once I have something usable
<cpaelzer> jamespage: we have already uploaded 17.05.1 in Debian-experimental and in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2889 you'll find that building for Artful so you can test it
<cpaelzer> jamespage: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2888 OTOH has further changes to fix multiarch but that needs the mentioned OVS patch to not FTBFS
<cpaelzer> jamespage: You can find the OVS fix and would be welcome to chime in at https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336913.html
<cpaelzer> I'm leaving for lunch, and will fix build errors if any after that
<cpaelzer> jamespage: let me know if I can help more
<jamespage> cpaelzer: are you ok for me to upload to the same ppa?
<jamespage> or I can depend on that one elsewhere
<cpaelzer> the ppas are all yours
<cpaelzer> if you want
<cpaelzer> I added you to the notified IRC nicks, so you'll get a ping on the successful build (or error)
<cpaelzer> jamespage: also saw your update on the arm console bug, thanks now we are on one page there - I'll update that bug once I got to libvirt 3.6 (or the backports)
<jamespage> cpaelzer: great - thanks
<jamespage> cpaelzer: re the libvirt issue
 * jamespage digs for another bug
<jamespage> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1706630
<ubottu> Launchpad bug 1706630 in libvirt (Ubuntu) "aarch64: MSI is not supported by interrupt controller" [Undecided,New]
<cpaelzer> That is still unread atm
<jamespage> having discussed with some folks at linaro I think that's a qemu 2.9 fixed issue but I've not tested yet
<cpaelzer> That at leasts sounds like a plan, I'll tag it so I know to ping for retests once I have a newer qemu
<LocutusOfBorg> Unit193, migrated! :D
<cpaelzer> jamespage: if you can test that on artful instead of Xneial + UCA you could verify with https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream
<cpaelzer> if that is iteresting to you
<cpaelzer> otherwise I'll ping once a newer qemu to try is around
<acheronuk> LocutusOfBorg: landing Qt any closer?
<cpaelzer> jamespage: the dpdk builds are both good now
<cpaelzer> jamespage: feel free to use the ppas as you need them to check on OVS 2.8
<LocutusOfBorg> acheronuk, silo is sad when I click publish
<LocutusOfBorg> I need an archive admin
<doko> jamespage, coreycb, rbasak: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  cmd2 and python-cryptography pull in new packages into main
<sil2100> slangasek, stgraber: techboard/DMB related question - we have 2 vacancies in our DMB and only 2 candidates, are we thinking correctly that the two nominees get the seats without the need for a public vote?
<ogra> mdeslaur, cyphermox https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291140.html ... looking at trusty it seems that n-m actually depends on "libnl-3-200 (>= 3.2.7)" ?
<ogra> (though that makes no sense, how would n-m have been installed before the security update)
<mdeslaur> ogra: no idea why that would happen to him
<ogra> mdeslaur, well, is there a 3.2.7 anywhere in the trusty archive ? (i dont see it)
<mdeslaur> ogra: I don't understand what you mean
<mdeslaur> ogra: 3.2.21 is higher than 3.2.7
<ogra> uh, oh
<ogra> ignore me :P
<stgraber> sil2100: correct, they do need TB approval though
<ogra> (pretty please)
<mdeslaur> hehe
<sil2100> stgraber: is there any formal process for that?
<stgraber> sil2100: nope, just send the election results to the TB mailing-list, if nobody is opposed to the new candidates, we'll add them
<stgraber> IIRC that's what we've usually done for the DMB
<sil2100> stgraber: thanks! I'll guess I'll send out a final note just now, wait until EOW and send out the request to the mailing-list, since I'd like us to have 7 people for the meeting on Monday
<doko> juliank: https://launchpad.net/ubuntu/+source/apt/1.5~beta1build1/+build/13212358
<chiluk> so I'm trying to do my first sponsorship, and I have a feeling I'm doing something wrong.. I'm trying to use sponsor-patch, but of course it's trying to sign the package with the sponsee's keys... is there another tool?  or are people just not using sponsor-patch any more?
<chiluk> sil2100: ^^ ??
<nacc> chiluk: -k option
<nacc> chiluk: and/or debsign -k after
<chiluk> .. thanks..  knew I'd feel dumb after getting the answer.
<chiluk> thanks ..
<juliank> doko: Something changed in rounding floats
<juliank> So it expected it to round one way and it now rounds the other
<jbicha> chiluk: I have DEBSIGN_KEYID and DEBSIGN_MAINT set in my ~/.devscript so that I can just build source packages like normal regardless of who is listed in the changelog
<jbicha> ~/.devscripts
<doko> right, most likely the GCC 7 change, as it appears to be on i386 only
<juliank> doko: yeah, it expects int(floor(float(0.9) * int(12-2)))=int(floor(float(0.9) * int(10))) to be 9 in the test, but now it's 8
<juliank> Maybe we should use 0.9001 in install_progress_test.cc:19
<juliank> Long term we should switch from float fractions to an integer
<juliank> You know, n out of 255 instead of a float <= 1.0
<juliank> Hmm or not
<juliank> doko: It did not fail in our testing on Debian, though, people successfully built with gcc 7 on amd64, i386, and armhf IIRC
<juliank> Oh, I guess we should not use 0..1 but 0..100 that should work better. Then 0.9 would be 90 and 90*10 would be 900, divide by 100 and you get 9
<juliank> So instead of floor(0..1 * width), use floor(0..100 * width) / 100
<juliank> Does that make sense?
<juliank> floor(0.891 * 10) = 8 , float(89.1 * 10) / 100 = 891 / 100
<juliank> uhm, 891.0 / 100.0
<chiluk> so what's the process when you get upload collisions in the devel release?  in this case seb128 just uploaded bluez into artful-proposed ... can I just do the upload for 1674680 anyway?
<chiluk> fixing versions as appropriate?
<juliank> rebase on top of his upload?
<chiluk> yeah is that ok?
<chiluk> wasn't sure if we had a any sort of cool-down time in devel like there is with SRU releases..
<juliank> I guess it would be nice to wait until it is out of proposed or stuck
<juliank> So you don't accidentally make it wait longer due to your change (if that one is borken)
<chiluk> just reviewed that change... looks like it's pretty small..
<chiluk> and the upload I want to sponsor is mostly just code cleanup and upstart removal.
<chiluk> upstart script removal.
<chiluk> that and his upload was only a few minutes ago so the additional time is negligible.
<seb128> xnox, hey, is using persistent journal for systemd something you are still looking at doing?
<cjwatson> stgraber: Is installing snaps inside a nested LXD container (i.e. lxd -> lxd -> snapd) known to work or known to not work?  I'm getting EACCES on "apparmor_parser --replace --write-cache -O no-expr-simplify --cache-loc=/var/cache/apparmor /var/lib/snapd/apparmor/profiles/snap.core.hook.configure" here in the inner container
<stgraber> cjwatson: won't work, apparmor can only do a single level of namespacing unfortunately
<stgraber> cjwatson: so you can't load apparmor profiles in your nested container
<cjwatson> right, sucks to be me then since I won't be able to test launchpad-buildd snap-in-lxd with my usual setup
<cjwatson> is that something that might change in the future?
<tyhicks> cjwatson: yeah, it might be possible in the future
<tyhicks> cjwatson: it'll require coordination with other LSMs and the namespace folks to put the right hooks in place when namespaces are created
<cjwatson> good to know I'm not permanently doomed :)  but in that case I probably want to select the backend dynamically
<cjwatson> "lxd unless already running in lxd"
<tyhicks> this is something that we'll likely discuss at the Linux Security Summit next month
<cjwatson> thanks.  count me as a(n admittedly abstruse) use case ...
<slangasek> sil2100, stgraber: I do find it weird that the voting system doesn't allow the developers to express a vote of no confidence in a candidate (i.e., ranking them below "none of the above" on a ballot); but seems that's the system we have
<jbicha> does "none of the above" ever win anything?
<jbicha> I guess it does for decisions but when we're voting on people?
<Faux> There's a whole load of politic science about why you shouldn't have that as an option. (I do not understand it.)
<slangasek> jbicha: I believe there have been DPL candidates who lost to NOTA in the past
#ubuntu-devel 2017-08-08
<nacc> tjaalton: in 16.04, libgles1-mesa is present but not installable because it depends on an old libglapi-mesa. I think that's because the xenial-updates version of mesa dropped libgles1 altogether? Should there be a dummy binary package to make libgles1-mesa not be broken? Or something to resolve that? User in #ubuntu is hitting it
<nacc> tjaalton: i guess this is all from the 16.04.3 update for mesa?
<Unit193> cyphermox: In regards to LP 1636666, http://lkml.iu.edu/hypermail/linux/kernel/1708.0/03653.html suggests git move from pcre1 to pcre2. " As the"
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Incomplete] https://launchpad.net/bugs/1636666
<Unit193> upstream PCRE maintainer has abandoned v1 maintenance for all but
<Unit193> the most critical bug fixes, use of v2 is recommended.
<jbicha> Unit193: for artful, we probably want to build 'git' with pcre3 (which confusingly is older than pcre2)
<jbicha> git is only the 2nd main package to want to use pcre2
<jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html
<Unit193> http://repo.or.cz/git/debian.git/commit/89a26f94004eb5bf76b012f64394cec0bc508d68
<Unit193> jbicha: Personally, I'd rather get vte2.91 out of main, but meh.
<jbicha> Unit193: do you prefer xterm or what??
<Unit193> Nope.
<jbicha> no terminal?
<Unit193> xfce4-terminal, which is in universe, and dropping vte2 to universe would allow it to build against pcre2.
<jbicha> ok
<jbicha> Debian's pcre2 is a pain to do security updates for, the only patch system it uses is dgit
<Unit193> Esh..
<jbicha> https://browse.dgit.debian.org/pcre2.git/
<Unit193> Wow, that looks fun, but tbh I haven't looked into dgit really at all.
<Unit193> (Still would be very nice if vte2 wasn't in main. :/ )
<tjaalton> nacc: i'd like to know what depends on it, as nothing in the archive does
<tjaalton> I wonder what might cause some package builds fail on sbuild when tests are enabled, while they build fine on a ppa.. reproduced with a debian host too
<tjaalton> tried on stock xenial/debian and OOTB mk-sbuild
<Unit193> lutostag: G'morning.
<Unit193> Erm, LocutusOfBorg.
 * LocutusOfBorg waves
<Unit193> I have nothing specific to bother you with this morning. \o/
<LocutusOfBorg> :)
<cpaelzer> LocutusOfBorg: sorry for the wall of text in the qemu armhf bug you opened
<cpaelzer> LocutusOfBorg: but it seems debugging went on and on and I couldn't decide which info to drop
 * cpaelzer is providing replacement-bothering of LocutusOfBorg for Unit193 :-)
<LocutusOfBorg> cpaelzer, thanks, I answered and I'll give another try
<Unit193> cpaelzer: Oh btw, does that mean I can poke you for things, then? ;)
<cpaelzer> Unit193: you can always poke as long as I can always ignore :-)
<Unit193> Meh, got enough of that one, thanks though.
<cpaelzer> don't get that wrong, honestly feel free to poke if you have something I can help
<cpaelzer> LocutusOfBorg: I think for now you'd want to get the if armhf then test || true back
<acheronuk> mitya57 LocutusOfBorg et al. http://paste.ubuntu.com/25269337/ seems to fix the FTBFS in QtwebEngine 5.7.1 that slangasek was trying to sort for his rebuild against libevent-2.1-6. Have you any objections to me uploading that while we wait for Qt 5.9?
<mitya57> acheronuk, no objections from me
<acheronuk> mitya57: thanks. could not see a problem, but had to ask so not to step on toes
<sary> Salutations!
<sary> please #see https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1709306
<ubottu> Launchpad bug 1709306 in grub-installer (Ubuntu) "Xubuntu installer with usb in UEFI BIOS mode ubiquity GRUB Installer crashed with "grub-efi-amd64-signed" package." [Undecided,New]
<sary> and
<sary> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1629348
<ubottu> Launchpad bug 1629348 in grub-installer (Ubuntu) "installer crash (grub2) during installation in UEFI mode" [Critical,Invalid]
<sary> additional informations i should add to the bug report
<sary> .. before leaving the live-session!
<sary> I don't have all day , and i need to fix this broken system..
<sary> I hope that am in the proper channel.
<sary> O' boy when you search the web with "ubuntu bugs launchpad xubuntu 17.04" ...
<sary> anway , i was point it to address this to cyphermox.
<LocutusOfBorg> jbicha, eta for gnome-settings-daemon in Debian? xmonad is uploaded
<LocutusOfBorg> lol uploaded now
<LocutusOfBorg> I had a cached page
<Unit193> LocutusOfBorg: Somehow got sucked into looking at dput, seems to mostly match except manpages. >_<
<cyphermox> sary: got your links
<cyphermox> sary: is that an upgrade or a new install? it looks like if you're doing partitioning, you're missing an EFI partition (which the installer creates for you if you used guided partitioning)
<sary> cyphermox: thanks, am in the live session trying to install in legacy mode .. well now the installtion is done. i've ran apport-collect but there was nothing to collect.
<sary> well it started as a new install , then tried to reinstall ..
<cyphermox> are you trying to do "Something else" to choose your partitions yourself?
<sary> nope.
<sary> anyhing you'd like me to collect to attach to the bug report! cyphermox
<cyphermox> maybe 'sudo fdisk -l' and 'archdetect' from the live session, but it's not going to help all that much
<cyphermox> looks like your CD didn't boot in "legacy mode"
<cyphermox> or USB
<sary> well it did now the installtion is done whilst bootin within legacy mode.
<cyphermox> ok..
<cyphermox> you didn't run into that crash this time?
<sary> correct.
<cyphermox> did you do anything different to boot the live session? because there isn't much else that deals this
<sary> maybe a few shutdowns , ive wanted to tty resetting the BIOS , but i couldn't find that option.
<sary> cyphermox: thanks for the love and support.. i shall reboot now!
<nacc> tjaalton: possibly nothing in the archive, but, it would appear, the verison of the intel updater for 16.04 seems to depend on libgles1 still -- and it's still a package that exists and is now uninstallable, which seems like something we should avoid
<tdaitx> https://packages.ubuntu.com/ still defaults to yakkety, shouldn't it default to zesty now?
<nacc> tdaitx: yeah, i think someone was going to file a bug
<tdaitx> nacc, tks, haven't found one open about that, so I did it. LP: #1709378
<ubottu> Launchpad bug 1709378 in pkg-website "packages.u.c defaults to yakkety, should default to zesty instead" [Undecided,New] https://launchpad.net/bugs/1709378
<nacc> tdaitx: thanks
<nacc> slangasek: fyi, django-compat needs an upstream update for python-django to migrate (django-compat 1.0.13 only supports up to 1.10 and 1.0.14 supports up to 1.11 which is the version in a-p). Do you want me to do the uupdate?
<slangasek> nacc: yes please! :)
<nacc> slangasek: will do, thanks
<doko> coreycb: https://launchpadlibrarian.net/332460548/buildlog_ubuntu-artful-amd64.skimage_0.13.0-0ubuntu3_BUILDING.txt.gz
<doko> please could you address these sphinx related issues? I think syncing sphinx ahead of time from experimental is a bad idea anyway ...
<coreycb> doko: yeah i agree, i think i made a mistake there
<coreycb> doko: can we reject it at this point?
<doko> not my call. you should address this with the releae team
<coreycb> doko: i will
<slangasek> this was a sync from experimental? yeah we can totally nuke that from orbit
<slangasek> coreycb, doko: sphinx/1.6.3-1 nuked from -proposed
<doko> ta
<coreycb> slangasek: thank you
<ilmaisin> slashd: hello, i read your message to the cups bug
<slangasek> coreycb: for your awareness, the ongoing perl transition is a bit of a mess, and updating packages deep in the stack is likely to make more work for the team right now as we try to shepherd that transition through; it's a good idea to avoid syncs from experimental for the next little whie
<slangasek> while
<ilmaisin> slashd: do you still have the vm you used for the experiment? what will happen if you run "apt upgrade" now?
<coreycb> slangasek: ok will do
<slangasek> coreycb: and also, in general, uploading new versions of packages that are currently in -proposed, and are candidates, will slow down getting them into artful
<coreycb> slangasek: do you mean packages that are stuck in proposed?
<coreycb> and uploading new versions on top of them?
<nacc> coreycb: i think slangasek means the ones that are not stuck, but those that are valid candidates and would migrate if a new upload wasn't placed on top?
<slangasek> coreycb: packages currently listed as 'Valid candidate' on http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html but have not migrated
<coreycb> nacc: slangasek: i see what you're saying.  it'll be hard for me to wait on proposed migrations at least for now, with final release of pike at end of august.
<coreycb> for openstack packages, that is
<slangasek> coreycb: yeah, but the reality is, any uploads now of the related packages will only make it slower
<nacc> coreycb: yeah, i can understand that -- you're just caught between your deadline and a maze of other transitions :)
<coreycb> slangasek: nacc: yeah, well and we do  still get ahead from an openstack pov even if pkgs are stuck in proposed because they get backported to the cloud archive from proposed where we do most of our initial testing.
<coreycb> but duly noted, thank you
<slangasek> coreycb: you backport from -proposed? ugh :)
<slangasek> which means your incentivized to upload it to devel even if it's not migratable
<coreycb> slangasek: well, it goes to a staging ppa, then once that checks out it goes to the proposed pocket of the cloud archive, then to updates later
<coreycb> slangasek: but yes we're incentivized to do that
<slangasek> if all goes well this will be sorted in a couple more days
<tsimonq2> Could I please get a review of https://bugs.launchpad.net/ubuntu/zesty/+source/indicator-sound-gtk2/+bug/1708619 from someone on the SRU Team? Lubuntu would like the fix and it's sitting in the Zesty Unapproved queue (I got it sponsored).
<ubottu> Launchpad bug 1708619 in indicator-sound-gtk2 (Ubuntu Zesty) "[SRU] sound settings does nothing - sound menu of the indicator applet" [Undecided,In progress]
<nacc> slangasek: uploaded (django-compat 1.0.14), fyi\
<slangasek> nacc: great, thankS!
<nacc> slangasek: np
<rbasak> Am I right in thinking I can skip the orig tarball in an SRU upload if the orig tarball already exists in the development release?
<nacc> rbasak: um, i *think* dput will reject it -- but I'm trying to recall, let me see in my e-mails
<nacc> rbasak: i'm not sure, not finding it in my own e-mails. I have this vague recollection I had to include the orig tarball for the php7.0 MREs. I guess I will be able to tell you shortly :)
<rbasak> nacc: I'll just -sa to be sure then. Thanks!
<nacc> slangasek: django-compat migrated, i'll retrigger the python-django tests
<nacc> slangasek: alright, looks like they all pass, once the update_excuses picks up the new results, python-django should migrate now
<slangasek> nacc: migrated. fancy!
<nacc> slangasek: nice -- it was on my todo to see if we had to add code, as when i last checked django-compat upstream hadn't yet updated. So it was just good timing :0
<nacc> xnox: i spent some time looking at the test, and smoser is out for a while. I don't see a trivial way to run more tests in the nested guests (currently only files are pulled out). So I think the correct short-term fix is to remove that test that can't succeed with the new systemd unit.
<nacc> mdeslaur: i sent you a couple MPs to review (and gave instructions to obtain the equivalent debdiff) for php7.0
<mdeslaur> nacc: thanks! will take a look first thing tomorrow
<nacc> mdeslaur: np, let me know if you have any questions
#ubuntu-devel 2017-08-09
<sarnold> What could cause this? https://gist.github.com/11619c37f334005d1681295aa940d8dd a guy in #ubuntu-server got "Processing triggers for systemd (229-4ubuntu19) ... dpkg: error: dpkg status database is locked by another process" from an apt-get install
<tsimonq2> sarnold: first thought that comes to mind (just a theory) is unattended-upgrades being triggered and it steals the lock
<tsimonq2> I would consider that a bug if unattended-upgrades actually did that, but you never know...
<juliank> tsimonq2: Yes, that can happen.
<juliank> see https://lists.debian.org/debian-dpkg/2017/01/msg00044.html
<tsimonq2> juliank: Oh ok, so I'm not far off ;)
<tsimonq2> That's interesting
<tsimonq2> Thanks for the link!
<sarnold> juliank: thanks
<sarnold> I'm reminded of https://deadlockempire.github.io
<tsimonq2> sarnold: hahahahahahaha
<seb128> hum, in artful when I use "debuild clean" I get
<seb128> "dpkg-buildpackage: error: unknown option or argument clean"
<seb128> is that me using tools wrong or a bug?
<sary> reporting bugs in 17.10 concerns #ubuntu+1 , -devel , or both!
<mbiebl> I got an issue with ibus under 17.04
<seb128> hum, python packaging question
<seb128> if a package is shipping python files to a private dir, is it useful to byte compile those and if so is that something the tools can do for you or that you need a postinst/rm for?
<mbiebl> when I log out, I still have an ibus-daemon (+ ibus-dconf and ibus-engine-simple) process
<mbiebl> which don't want to exit
<mbiebl> so the logind session is not stopped
<seb128> or asked differently is there a better way to do what https://github.com/fossfreedom/alternative-toolbar/blob/debian/debian/postinst is doing? (that was raised as weird in a review)
<mbiebl> unfortunately, ibus can't easily be uninstalled
<seb128> mbiebl, is that https://bugzilla.gnome.org/show_bug.cgi?id=764029 ?
<ubottu> Gnome bug 764029 in general "goa-daemon (and most other D-Bus services) not stopped when the user session goes away" [Critical,New]
<mbiebl> seb128: those are systemd user services
<mbiebl> as long as a session scope is still active, those services are not stopped
<sary> well, this just happened , https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/1709572
<ubottu> Launchpad bug 1709572 in system-config-printer (Ubuntu) "system-config-printer.py crashed with ValueError in require_version(): Namespace Secret not available" [Medium,New]
<seb128> sary, launchpad is the right place to report bugs, no need to ping about them on IRC as well
<mbiebl> so the problem is, that a process from the session does not want to die on logout
<sary> seb128: Noted. thank you!
<mbiebl> seb128: couldn't find a but about this ibus issue in the debian bts or launchpad
<mbiebl> a bug...
<seb128> that's the first time I saw it mentioned I think
<mbiebl> seb128: it's an ibus bug i'd say
<seb128> happyaron might know
<rbasak> juliank: opinion on bug 1709603 please? This is in response to a few people in Canonical agreeing and asking what we can do to make it happen.
<ubottu> bug 1709603 in apt (Ubuntu) "apt {upgrade,install} require an update call first" [Wishlist,New] https://launchpad.net/bugs/1709603
<rbasak> (and I haven't yet heard any dissenting opinions apart from yours)
<Unit193> There's already a freaking timer, why on earth would...OOh nevermind, as long as it's easy to disable it's not the end of the world anyway.  Just another thing to fix...
<Unit193> rbasak: Thanks for the LE srus.
<rbasak> Unit193: you're welcome. Are you suggest some improvement to adding the systemd timer in the SRU?
<rbasak> *suggesting
<Unit193> rbasak: No, unrelated topics.  Apt does pretty well now of keeping the indexes up to date, an 'automatic' call to 'update' is excessive.
<rbasak> Unit193: how so?
<juliank> rbasak: It's really one of the things that annoys me the most when using yum and friends. We update the indices automatically once per day any way; the only time this would really have any effect is after a new installation (or on systems not using unattended-upgrades).
<rbasak> Unit193: my main issue is the call of "apt install ..." on a fresh instance, such as a container. It's a very common case (anyone doing "cloud" anything, really).
<rbasak> juliank: right, but that's a very common case.
<persia> Perhaps the sensible solution is to add an `apt update` call to the installer, after the archive mirrors are selected?
<Unit193> rbasak: Ah, well if the recommendation is to ship an apt config snippet in one of the cloud packages, fine by me.
<rbasak> juliank: what if --is-necessary did not update if less than a day old? Then my proposal wouldn't introduce any functional change except in the failure case.
<rbasak> persia: that unnecessarily slows down the boot of cloud instances.
<rbasak> persia: or introduces a race in the system being ready to accept an "apt install", which is immediately necessary in this use case.
<rbasak> Unit193: I think the config snippet would need to be Ubuntu-universal. We don't want a behaviour difference between Ubuntu on cloud and not-cloud by default. That's be infuriatingly confusing.
<persia> rbasak: I thought the issue was that `apt install` didn't work on first install because the indecies were out of date.  I leave you to your previously planned work.
<juliank> I don't really see how spawning a new cloud instance and then immediately having to run apt manually is a common thing to do. I'd expect people to script their cloud building, and then it's easy to add an update command first
<Unit193> Better than the proposed option..
<rbasak> persia: I want 1) if I start a container for development, it starts straight away; 2) if I subsequently run "apt install", it does the necessary things. It's not possible to have both if cloud-init blocks on updating apt first.
<rbasak> juliank: it's a common thing to do when developing or debugging any automation.
<persia> rbasak: So, automatically update the indices if they are too old or something?
<rbasak> persia: correct. Automatically on "apt install" or "apt upgrade".
<rbasak> That's what I want.
<mdeslaur> I'd really hate for 4 apt installs in a row to download the indices each time
<persia> For folk running production series, it oughtn't matter: the non-updated versions should be self-consistent for installation, even without a refresh of the updates.  Updates would become available at first time check.
<rbasak> Folks running production expect the initial deployment to include all security updates.
<persia> Perhaps, for the short-lived use case, it would be appropriate to check for updated packages a few minutes after boot, or similar.
<rbasak> This requires a local index update.
<juliank> I think that having an option like -u but disabled is a better choice. That's how paca
<juliank> *pacman works
<persia> rbasak: If the initial install is to have the security updates, the solution is to A) have the installer do the updates or B) if using image-based instantiation, update the image on every publisher run.
<juliank> and automatically do the update if there are *no* lists
<persia> Anything else means that the deployed instance has a security problem most of the time.
<juliank> So apt install foo will run update on first apt use; and apt install -u foo will run update unconditionally
<rbasak> juliank: that may be sufficient for my failure cases.
<persia> That implies the deployed image has a window of vulnerability (between deployment and update), which may not be very useful for short-lived images.
<rbasak> Though it depends on unattended-upgrades not being configured away from the default, and that dependency is IMHO surprising to users.
<juliank> I'm not sure how to make that no lists part work best with cdrom:// though
<rbasak> juliank: perhaps disable all of this if cdrom:// is present?
<persia> That makes use of cdrom:// inherently less secure.
<rbasak> So deprecate it.
<juliank> rbasak: Maybe this, or maybe we should just ignore cdrom:// URIs and check if "all (other) sources are missing"
<rbasak> That'd work fine for my case I think.
<rbasak> juliank, persia, Unit193, mdeslaur: thank you for the discussion. Some good ideas on adjustments.
<nacc> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: nacc
<slangasek> nacc: were the build profile patches for php-directory-scanner sent upstream to Debian?
<nacc> slangasek: hrm, it looks like I didn't send it, but all of the infra for building the php* has been adjusted to be better capable of handling the upgrades (or building with two different versions). I expect it'd be ok to sync if you want -- or I can submit those to Debian
<slangasek> nacc: your call
<nacc> slangasek: go ahead and sync it
<slangasek> done
<nacc> slangasek: if i'm reading the update_output.txt correctly, does php7.1 getting skipped mean that cacti-spine and php7.1-snmp become uninstallable with the binaries from src:php7.1 on s390x? but php7.1-snmp is from src:php7.1 itself
<slangasek> nacc: on update_excuses, Depends: php7.1 net-snmp
<slangasek> nacc: so php7.1 and net-snmp have to go in together; if there's a relevant 'Trying easy from autohinter' in the update_output, that will be more instructive
<slangasek> nacc: and I see that net-snmp is in the big hint
<slangasek> nacc: so doko's gcc-7 is blocking you ;)
<slangasek> oSoMoN: hi, I see that libreoffice amd64 autopkgtest fails with gcc-7 because of new warnings (and stderr output considered a failure).  I will be overriding this test for the toolchain transition, which means libreoffice/amd64 autopkgtests will be failing in the meantime.  Would you be the person to fix this failure?
<bdmurray> slangasek: Any ideas about why test_is_child_of_process_name in update-manager would fail on !amd64 or !i386? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/u/update-manager/20170808_003647_cf6bd@/log.gz
<slangasek> bdmurray: !amd64 !i386, or !s390x !armhf?
<slangasek> bdmurray: it might be that pid1's name is different inside of a container
<bdmurray> slangasek: it fails on s390x too
<slangasek> bdmurray: sorry, I meant "!amd64 !i386, or s390x armhf" - yes, I checked the ppc64el failure and it seems unrelated; so this test fails on the two container archs so I guess that's the difference
<slangasek> bdmurray: http://paste.ubuntu.com/25277940/
<nacc> slangasek: got it, thanks, would that also cover cacti-spine?
<slangasek> nacc: I imagine so
<nacc> slangasek: ok, i'll let that sit for a bit, then
<bdmurray> slangasek: hrm, these tests test function in update-manager's utils.py but update-manager doesn't use them ubuntu-release-upgrader does.
<slangasek> bdmurray: should they be moved to python3-distupgrade, then?
<bdmurray> slangasek: I think they should be moved because I was thinking about removing the functions and the tests but I don't know if its a priority.
<slangasek> bdmurray: at the very least, I don't think a test testing the name of pid1 is a good test
<bdmurray> slangasek: sorry, could you elaborate?
<slangasek> bdmurray: sorry, now reading the test and code and need to re-collect my thoughts, because my pid1 on zesty host is also /sbin/init so why would it be have differently
<slangasek> bdmurray: but generally, the point I'm trying to make is that the test is asserting things about the system, not about the correctness of the code under test
<slangasek> bdmurray: a proper test of this code would mock /proc
<bdmurray> slangasek: okay
<oSoMoN> slangasek, yes, that would be me
<oSoMoN> putting that on my list
<slangasek> oSoMoN: thanks
<slashd> Is there any coredev who have some cycle atm to sponsor a patch for logrotate in devel release (artful) ? then I'll be able to proceed with the upload myself for stable release.
<nacc> slashd: yeah, do you have a bug open?
<nacc> slashd: i'm piloting right now anyways (see /topic)
<slashd> nacc, https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1709670
<ubottu> Launchpad bug 1709670 in logrotate (Ubuntu Artful) "logrotate never recovers if the statefile is corrupted" [Medium,In progress]
<nacc> slashd: ok, i'll do that one next
<slashd> nacc, thanks much appreciated
<slashd> nacc, I'll take care of the SRU afterward
<nacc> slashd: sounds good
<nacc> slashd: iiuc, then, you don't need sponsorship to the sru series, right?
<slashd> nacc, right I can sponsor myself on sru series
<nacc> slashd: ack, unsubbing sponsors thanks!
<slashd> nacc, thanks
<nacc> slangasek: question re: src:numactl. I thnk we can technically sync it, except that debian dropped the arch-specication for the binary packages in favor of linux-any in 2.0.11-2.1. It specifically says 'armel and armhf are still not supported'. We don't currently build numactl on armhf anyways, but I assume for our purposes that will show up as  FTBFS?
<nacc> slangasek: and so we do need to keep delta that switches from linux-any to the explicit list of architectures we know it builds on?
<nacc> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<slangasek> nacc: it's fine for the package to be FTBFS on those archs; it wastes some builder time to try to build it and fail, but that's not usually worth carrying a delta
<Unit193> nacc: Thanks!
<nacc> slangasek: ok, good to know, thanks!
<kyoder> when I report a crash in ubuntu, is it better to turn that off after one report, or do the stats increase when I keep sending the same report?
<tyhicks> bdmurray: hey! I'm curious about the answer to kyoder's question and I suspect that you may know it ^
<bdmurray> kyoder: If you are using a stable release of Ubuntu (e.g. 16.04, 17.04) then the stats do increase, if you are using a development release of Ubuntu (Artful Aardvark) then the stats, in Launchpad, do not increase
<tyhicks> thanks
<kyoder> thanks bdmurray
<kyoder> and tyhicks
<tsimonq2> nacc_: yay patch pilot \o/
<nacc_> tsimonq2: i might do some more later today, just stopping for lunch
<tsimonq2> :D
<bdmurray> jdstrand: what release did you discover bug 1707645 on?
<ubottu> bug 1707645 in util-linux (Ubuntu) "system with high numbered uids has huge sparse /var/log/lastlog" [Undecided,New] https://launchpad.net/bugs/1707645
<slangasek> hmm, if it's sparse, why is that a problem?
<slangasek> oh, non-sparse rsync
<slangasek> doesn't seem like something we'd try to fix in util-linux; the format of /var/log/lastlog is fossilized
<Unit193> cpaelzer: Oh, g'luck on core-dev!
<ahasenack> just checking, but a package in main cannot have a build-depends on something that is in universe, right?
<sarnold> ahasenack: it was changed to be more nuanced; it's okay if it is strictly build-time, but if it results in binary package .. dependencies? changes? .. then the dep should be dropped or the universe package brought nito main
<Unit193> IIRC, it can if it's only a *buildtime* depend, eg doesn't link to it.  I may be wrong.
<ahasenack> hm
<ahasenack> ok, good
<ahasenack> I'll check that
<ahasenack> what about if it's for DEP8 tests?
<sarnold> ahasenack: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html
<Unit193> Of course, sarnold beats me and says it better. \o/
<ahasenack> try apt autoremove
<ahasenack> it should do the right thing. But double check
<ahasenack> I think it will even leave one kernel behind installed, in case you need to downgrade
<sarnold> ahasenack: heh, I think you meant for those to go to #ubuntu-server instead? :)
<ahasenack> oh, wow
<ahasenack> it must be late :)
<valorie> persia: looooooooooooooooooong time, no see! o/
<ahasenack> ok, I think thid builddep that debian added (libcmocka-dev) is used only for tests
<ahasenack> but I have to check for real. grep shows it only being used in test files
<ahasenack> but I'll want to check the final build with ldd and the Depends header of the built package
<jdstrand> bdmurray: artful
#ubuntu-devel 2017-08-10
<tsimonq2> rbasak: Hey there! You're probably EOD a while ago, but when you have a chance, could you take a look at bug 1641912? It's been verification-done for more than a week. ;)
<ubottu> bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,Fix committed] https://launchpad.net/bugs/1641912
<tsimonq2> (or any other member of the SRU team for that matter ^^^^^^)
<slangasek> tsimonq2: there's an autopkgtest regression listed on http://people.canonical.com/~ubuntu-archive/pending-sru.html which should be resolved
<acheronuk> doku: with latest GCC7 I am getting failures building 2 packages against hunspell. e.g. http://paste.ubuntu.com/25282312/
<ackk> hi, is this the right place to ask about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1697450 ?
<ubottu> Launchpad bug 1697450 in ubiquity (Ubuntu) "Installer freezes at session startup" [Undecided,New]
<LocutusOfBorg> jbicha, can you please ping upstream about geary/s390x?
<LocutusOfBorg> it seems a showstopper for gmime
<Mirv> tsimonq2: I'll be available for Qt excuses retry dance when I'm around, since it doesn't distract me from work really much to click those buttons :) but you'll need probably release team again to ignore bunch of KDE packages as usual. anyway, congrats on the proposed upload!
<Mirv> didrocks: dear one of the just four memebers of ubuntu-mir, if you have time before feature freeze please check bug #1708428 MIR request - the HFST, Giellatekno etc people would be happy to get the spell-checking support into next Ubuntu LTS too similar to Debian 9.0, and 17.10 would be good time for it to be enabled
<ubottu> bug 1708428 in hfst-ospell (Ubuntu) "[MIR] hfst-ospell" [Undecided,New] https://launchpad.net/bugs/1708428
<didrocks> Mirv: unsure I'll have time before FF but I'll have a look afterwards if nobody beats me to it! Thanks for looking into this :)
<Mirv> no problem, and thanks for trying! ;)
<didrocks> yw! :-)
<acheronuk> enchant will FTBFS against new hspell 1.4-1 if it is rebuilt http://paste.ubuntu.com/25283249/
<acheronuk> seeded on most desktops AFAIK
<acheronuk> KDE's sonnet and and kde4libs also fail in the same way if built with it
<acheronuk> doko: apologies. thought that was GCC7, bit seems not
<jbicha> LocutusOfBorg: I filed https://bugzilla.gnome.org/show_bug.cgi?id=783882
<ubottu> Gnome bug 783882 in build "geary fails to build on s390x" [Normal,New]
<LocutusOfBorg> thanks!
<jbicha> but sometimes we just remove desktop apps on s390xâ¦
<LocutusOfBorg> so will you ask to remove it?
<jbicha> LocutusOfBorg: since you're working on that transition, could you? the bug I filed upstream is ~2 months old
<LocutusOfBorg> I'm wondering about adding a cast
<didrocks> xnox: hey, are you looking at systemd migrating to the release pocket? It seems you fixed some tests that will help glib migrating as well (and others depending on it)
<LocutusOfBorg> and also some testsuite hangs :)
<didrocks> indeed
<LocutusOfBorg> well, systemd fails testsuite against itself
<tseliot> Desktop team, willcooke: is this a mistake? "Ubuntu 16.04.3 LTS will be supported for 5 years for Ubuntu Desktop". It's the .3 bit that I'm asking about, as it should be 6 months for each backported stack https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
<tseliot> ... and I used the wrong room
<willcooke> tseliot, just looks like an over-zealous search and replace
<tseliot> willcooke: yes, that's what I thought too, thanks
<willcooke> checking the logs
<tseliot> ok, I'll wait
<willcooke> tseliot, hrm, I cant seem to log in for some reason... bear with me
<willcooke> tseliot, something not right his sso login to the wiki by the looks of things.  If you are able to edit, please do, otherwise I'll try again later
<willcooke> s/his/this
<willcooke> er, with even.  meh
<tseliot> willcooke: ok, let me try that
<tseliot> willcooke: shall I just replace 16.04.3 with 16.04, or shall I say it will be supported for 6 months?
<mdeslaur> 16.04.3 is the point release version, it has nothing to do with the HWE stack
<mdeslaur> it's supported by updating to the next stack
<tseliot> mdeslaur: but then, when you get a newer stack, it won't be 16.04.3 any more, it will be .4
<mdeslaur> I'm running 16.04.3 and I don't have the HWE stack
<tseliot> mdeslaur: what is it that makes it 16.04.3 then?
<mdeslaur> new installation media that includes the latest updates, that's all
<jbicha> LocutusOfBorg: thanks for fixing geary :)
<mdeslaur> I don't think it's important to note that certain packages will only get supported for 6 months if they will be automatically replaced without anything special the user needs to do
 * mdeslaur shrugs
<mdeslaur> the blurb can certainly be changed to "16.04" instead of "16.04.3"
<tseliot> mdeslaur: it's all fine, except for people running or developing binary drivers. If the X ABI changes, or the kernel breaks, the binaries won't work any more, and avoiding to upgrade to the new stack will lead to a dead end (security issues, etc.)
<tseliot> this was my main point
<tseliot> it's a bit misleading in that specific case
<tseliot> I corrected that
<tsimonq2> slangasek: I've already asked about it ;) https://irclogs.ubuntu.com/2017/08/03/%23ubuntu-release.html#t10:15
<tsimonq2> Mirv: ok :D
<LocutusOfBorg> tsimonq2, please fix qtwebengine
<LocutusOfBorg> jbicha, I hope to have fixed it
<LocutusOfBorg> I'm not sure
<tsimonq2> LocutusOfBorg: sure
<tsimonq2> LocutusOfBorg: Although didn't slangasek say to hold off on 5.9 for QtWebEngine until the GCC transition was done or something?
<LocutusOfBorg> i386 and amd64 were fine
<LocutusOfBorg> tsimonq2, perl, gcc, binutils, kernel and so on migrated 10 hours ago
<tsimonq2> LocutusOfBorg: :D
<LocutusOfBorg> the excuses file went from 11Mb to ~5
 * LocutusOfBorg my firefox is happier
<tsimonq2> hahahahahahahahahahahaha seriously? :D
 * tsimonq2 's firefox is also quite a bit happier <3
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.1+dfsg-2build1/+build/13223030
<LocutusOfBorg> please also take the ball to fix arm64
<LocutusOfBorg> even if the build went successful at the end, not sure why
<LocutusOfBorg> well, please also fix amd64 and i386
<LocutusOfBorg> you have logs for everything, and they match with the ongoing build2 build
<LocutusOfBorg> because they were on the same toolchain (removed for other reasons)
<tsimonq2> ic
<tsimonq2> ok
<tsimonq2> LocutusOfBorg: side note, while I'm getting my coffee, could you help me look into why ben isn't migrating? I think it depends on something that needs a piuparts pass but doesn't have one
<LocutusOfBorg> forget about ben
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/ocaml.html
<LocutusOfBorg> this is why
<LocutusOfBorg> maybe xnox slangasek ^^
<LocutusOfBorg> there is some ocaml arm64 regression out there
<tsimonq2> LocutusOfBorg: ack
 * tsimonq2 is caffeinated
<acheronuk> LocutusOfBorg tsimonq2 what is wrong with? https://launchpad.net/ubuntu/+source/qtwebengine-opensource-src/5.9.1+dfsg-2build2
<tsimonq2> acheronuk: symbols
<tsimonq2> acheronuk: working on it atm
<acheronuk> ah
<tsimonq2> LocutusOfBorg: Your fixed qtwebengine: http://people.ubuntu.com/~tsimonq2/packages/qtwebengine-opensource-src_5.9.1+dfsg-2ubuntu1.dsc :D (should be done uploading in a couple of mins)
<tsimonq2> RIP my connection :P
<LocutusOfBorg> tsimonq2, dpkg-buildpackage -S -d
<LocutusOfBorg> not -sa
<tsimonq2> ok
<tsimonq2> Lintian takes a looooooooong time with this large of a package...
<LocutusOfBorg> no need to run lintian
<tsimonq2> LocutusOfBorg: debuild does it automatically
<LocutusOfBorg> they are just symbols
<tsimonq2> LocutusOfBorg: And it's uploaded already, same URL
<tsimonq2> I know
<LocutusOfBorg> it does *after* having generated the tarballs I guess
<LocutusOfBorg> so you can ctrl+c it
<tsimonq2> ok well it's done now :P
<LocutusOfBorg> also uploaded :p
<tsimonq2> :D
<tsimonq2> Thanks!
<LocutusOfBorg> jbicha, do you feel openbox syncy?
<LocutusOfBorg> it is not really a no-change sync, you added some newer split?
<LocutusOfBorg> I'm talking about "org.gnome.SettingsDaemon.XRANDR"
<jbicha> LocutusOfBorg: go ahead and sync, I want the 3.26 compatibility in Ubuntu
<LocutusOfBorg> syncd!
<LocutusOfBorg> ta
<mitya57> tsimonq2, thanks for qtwebengine upload, looks like it should fix some autopkgtest failures
<LocutusOfBorg> hopefully
<LocutusOfBorg> I also retried some of them
<LocutusOfBorg> due to network failures
<tsimonq2> mitya57: You're welcome :)
<mitya57> LocutusOfBorg, thanks to you too :)
<LocutusOfBorg> we will have a clear picture in 24h
<LocutusOfBorg> but at least 20 packages seems to need fixes
<tsimonq2> LocutusOfBorg: Mhhhh, KDE packages just like to break their autopkgtests :P
<tsimonq2> acheronuk: ^
<tsimonq2> He knows :P
<LocutusOfBorg> yep, some of k* and libk* needs fixes
<acheronuk> they do!
<LocutusOfBorg> I'm worried about the failures on some-arch-but-not-others
<LocutusOfBorg> for now, I don't see arch-specific regressions in qt
<LocutusOfBorg> e.g. armhf needs udev/systemd fixes
<LocutusOfBorg> or retried
<LocutusOfBorg> *s, while some amd64 were just faster and failed because of qtwebengine
<LocutusOfBorg> once it is in place we might do a retry of all of them
<tsimonq2> LocutusOfBorg: we can just completely ignore packages that depend on qtwebengine that fail on s390x or ppc64el because QtWebEgnine simply will not build on those arches (not something we can control, upstream thing)
<tsimonq2> We should fix the failures on the other arches, but that's a special case
<LocutusOfBorg> (probably against proposed, since this seems to be a lock-in transition that is not always retro-compatible)
<tsimonq2> LocutusOfBorg: It is
<LocutusOfBorg> tsimonq2, yes, we should get them removed into artful, and testsuite will be ignore automagically IIRC
<acheronuk> yes, tests run without that are doomed for trouble
<tsimonq2> Yeahp.
<LocutusOfBorg> maybe we can rerun all the tests against a fast architecture, like ppc64el and elsewhere in case we see it "fixes"the issue
 * acheronuk peers at QtWebEngine
<LocutusOfBorg> to avoid bothering the infra with uselesss rebuilds
<acheronuk> building.......
<jbicha> LocutusOfBorg: you're going to have lots of autopkgtest failures from dh-acc, see my comments in #ubuntu-release
<LocutusOfBorg> lol I answered that some seconds ago
<slangasek> tsimonq2: ah, so infinity had told you we didn't need to hint the autopkgtest regressions for gtk+2.0... he and I have a vigorous difference of opinion there, then :)  they should be hinted so that you don't have to chase multiple SRU team members around with copies of IRC logs ;)
<tsimonq2> slangasek: fair :)
<tsimonq2> jbicha: Mind if I steal your yelp-tools merge?
<LocutusOfBorg> jbicha, abi should be fixed
<tsimonq2> oooooooooooooh, LocutusOfBorg and acheronuk, looks like QtWebEngine might be done building!
<tsimonq2> Just needs an Archive Admin now to approve binaries.
<LocutusOfBorg> not so fast
<acheronuk> arm* is still building (no surprise)
<LocutusOfBorg> still needs arm*
<LocutusOfBorg> exactly
<tsimonq2> ah ok
<kward> need some advice on what to do with LP: #1706284 At the moment i've got it at "In Progress" , but no-one else has had the chance to reproduce it, and I've attached all the debdiffs and patches to it that fixes the issue, so what status do i set it to?
<ubottu> Launchpad bug 1706284 in sssd (Ubuntu) "sssd fails to Update PTR if any A record update fails." [Undecided,In progress] https://launchpad.net/bugs/1706284
<tjaalton> nacc: ok, uploaded a new mesa to xenial that adds the dummy libgles1-mesa
<nacc> tjaalton: thanks! i think it makes sense to do that, just for self-consistency, right?
<tjaalton> sure
<tjaalton> didn't think of 3rd party packages actually depending on it..
<tjaalton> silly intel
<nacc> yeah :)
<tjaalton> now to fix libxfont1..
<nacc> slashd: are you going to merge nagios-nrpe? You TIL
<nacc> slashd: i might just do it myself
<nacc> slashd: just uploaded (fyi) so you're off the hook :)
<nacc> mdeslaur: looks like src:nspr can be synced right? you did an artful update to bump to 4.13.1 but debian now has 4.15
<mdeslaur> probably, it usually goes with nss, but they're pretty good about not breaking abi
<mdeslaur> nacc: ^
<nacc> mdeslaur: ack, i'm looking at nss too
<nacc> mdeslaur: i think, if i'm reading it right, nss can be synced too (need to check on the ubuntu2 upload to see if it's an upstream fix or not)
<mdeslaur> nothing in the nss release notes strikes me at being particularly problematic
<nacc> mdeslaur: ack, i'll review our delta more closely tmrw, but i'll probably submit the syncs tmrw
<nacc> mdeslaur: thanks!
#ubuntu-devel 2017-08-11
<mdeslaur> np, thanks!
<EvanCarroll> Any chance to get a ppa removed if it's unmaintained? Is there a procedure for that?
<EvanCarroll> delisting or the like?
<EvanCarroll> reason why: this is confusing a lot of people. It's been broke almost as long as it has worked and every package in the repo has failed.
<EvanCarroll> https://launchpad.net/~videolan/+archive/ubuntu/master-daily
<EvanCarroll> https://launchpad.net/~videolan/+archive/ubuntu/master-daily/+packages
<seb128> hey there
<seb128> could somebody remind me how to trigger autopkgtests to use proposed package versions
<sil2100> seb128: IIRC adding &all-proposed=1 to the request was the trick, if that's what you're looking for
<seb128> sil2100, thanks
<seb128> I don't need full proposed though
<seb128> I just want to use abi-compliance-checker from there
<seb128> but I guess all-proposed would work as well
<sil2100> seb128: I guess you can use multiple 'trigger' entries too
<seb128> that's what https://wiki.ubuntu.com/ProposedMigration#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket suggests
<seb128> I wonder if I need to encode version
<seb128> or just use &trigger=abi-compliance-checker
<sil2100> seb128: e.g. add something like trigger=abi-compliance-checker/version-from-proposed
<seb128> sil2100, I tried, let's see if I got it right
<seb128> sil2100, thanks
<seb128> sil2100, oh, and hey, how are you? ;-)
<LocutusOfBorg> tsimonq2, "kf5-messagelib" has symbols sadness... do you have an hint/patch?
<LocutusOfBorg> I see acheronuk told me most of them are fixed in git, but I don't know where to look/fix
<LocutusOfBorg> e.g. is this ok to upload? https://launchpad.net/ubuntu/+source/kf5-messagelib/4:16.12.3-0ubuntu1
<LocutusOfBorg> I mean the fixes on git
<LocutusOfBorg> https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/messagelib I don't even know the right branch
<acheronuk> LocutusOfBorg: They are fixed in git on the artful_archive branch, but for apps 17.04.3 which we have been getting ready to upload once transitions have calmed. So really have to look at symbols fixes and pick out what applies, or do a rebuild in a ppa of the 16.12.3 version and use pkgkde-symbolshelper to patch symbols and do some manual corrections
<acheronuk> I will have time to do these later, but maybe not until this evening
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mdeslaur
<sdeziel> mdeslaur: good day
<sdeziel> I've seen that you updated LP: #1709193, thanks. I just noticed that I had not use "-proposed" for any of the debdiffs, please let me know if that is a problem
<ubottu> Launchpad bug 1709193 in gnutls28 (Ubuntu Artful) "Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer" [Undecided,Confirmed] https://launchpad.net/bugs/1709193
<mdeslaur> sdeziel: nope, we don't do that anymore
<mdeslaur> sdeziel: would you mind if I added Bug-Debian and Bug-Ubuntu links to the patch and remove the debian bug number form the changelog?
<mdeslaur> minor OCD nitpicks
<sdeziel> not at all, go ahead
<mdeslaur> thanks
<sdeziel> I wasn't sure if I should leave the debian bug number in there
<mdeslaur> I usually stick it in the patch itself, others may do differently
<sdeziel> makes sense
<mdeslaur> sdeziel: could you please update the gnutls bug description with the SRU template: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<mdeslaur> sdeziel: I'm about to upload the packages for processing
<sdeziel> mdeslaur: yes, on it
<mdeslaur> awesome, thanks
<tsimonq2> Yayyyyyyy patch pilot \o/
<sdeziel> I will clap my hands when those patches land safely in -updates ;)
<tsimonq2> LocutusOfBorg: I see acheronuk took care of it :)
<sdeziel> mdeslaur: let me know if the SRU justification is good enough
<tomreyn> EvanCarroll: did this get sorted, yet?
<tomreyn> i notice LocutusOfBorg is amongst the "newset members" of this PPA and s/he was active here not too long after you posted.
<tomreyn> in case it did not: the generic answer is probably 'no' (however, this is just a guess of someone not formally involved in ubuntu or launchpad). PPAs are generally unsupported and extra care needs to be taken before one decides to trust them (and one should re-check occasionally). did you contact the owners, yet?
<mdeslaur> sdeziel: I think it's ok, let's see what the sru team says
<EvanCarroll> tomreyn: no
<EvanCarroll> tomreyn: I have contacted the owners
<EvanCarroll> tomreyn: they're unresponsive.
<tomreyn> every single one of them?
<EvanCarroll> tomreyn: Also, in it's infinite Wisdom you can file an bug on a PPA. So essentially the only visual indicator is the failure to build, but because it's unsupported it's just fails all the time, it's wasting resources building (knowing it will fail), and it's confusing users as old questions point to it from when it worked.
<EvanCarroll> tomreyn: yes, iirc, and multiple times.
<EvanCarroll> There should be a method of delisting, especially in this case. The situaion with VLC and Ubuntu is really poor right now
<tomreyn> EvanCarroll: PPAs are not part of ubuntu
<tomreyn> are you referring to other issues?
<tomreyn> may i ask about your motivation, just out of interest?
<tomreyn> (as a reminder, i'm just anothe rubuntu user, no one special)
<tomreyn> EvanCarroll: also did you try this? https://help.launchpad.net/Feedback
<EvanCarroll> tomreyn: s/ubuntu/launchpad/ whereever it makes a difference.
<EvanCarroll> motivation: eliminating confusion with official but unmaintained ppas.
<EvanCarroll> I suppose I could join the right channel
<tomreyn> EvanCarroll: i'm just wondering what makes you care, i bet there are a LOT of other PPAs which create failing builds on a regular schedule.
<EvanCarroll> I didn't realize there was a launchpad channel
<nacc> EvanCarroll: to be clear, not s/ubuntu/launchpad/. tomreyn's point is that PPAs are not part of ubuntu
<EvanCarroll> tomreyn: that's not the right description of the domain, there are a lot of other ppas which are offiical with an upstream project or where at one point in time but are entirely unmaintained now?
<EvanCarroll> this isn't a failure to build this is problem for the past year that's confusing 83,000+ people.
<EvanCarroll> just going by askubuntu view counts.
<tomreyn> EvanCarroll: declared official by an upstream does not make it part of supported ubuntu
<EvanCarroll> no one said it was officially support by anything
<EvanCarroll> it's clearly not /supported/ at all.
<slangase`> it's not against launchpad policy for someone to have a ppa that produces broken / out of date contents; it's also not something that the Ubuntu community can fix by fiat if someone is giving directions to a bad ppa.  This is a social problem
<tomreyn> sure, upstream might decide to support some PPA, but that's nothing ubuntu folks could be held responsible for
<EvanCarroll> the problem is the launchpad confuses people and makes them /think/ it is.
<slangase`> if there is documentation on any official Ubuntu sites directing users to the ppa, that's something we could fix
<EvanCarroll> ok, so that's the problem then the launchpad policy supports confusing users.
<EvanCarroll> that's not a good policy.
<tomreyn> "You can update your system with unsupported packages from this untrusted PPA by adding ppa:videolan/master-daily to your system's Software Sources. (Read about installing) "
<EvanCarroll> it's not the packages.
<EvanCarroll> it's the page.
<tomreyn> this sentence i just quoted is pronted on every PPA page
<tomreyn> *printed
<slangasek> EvanCarroll: sorry, what other policy would you expect?  Launchpad is a platform; do you want the Launchpad team to be deciding whose ppas are supported "well enough"?
<nacc> EvanCarroll: what page are you referring to?
<tomreyn> if people cannot read or decide not to read they will probbalky make a lot fo bad choices in life
<slangasek> fwiw, I don't expect most users to ever browse to the ppa in a web browser before enabling it, but here is the banner you get for this particular ppa in add-apt-repository: http://paste.ubuntu.com/25291536/
<EvanCarroll> slangasek: I would expect the policy of "repositories that are unmaintained and cease to function with all supported version of Ubuntu will be delisted."
<EvanCarroll> slangasek: good question though.
<nacc> what is 'maintained'? 'cease to function'? delisted by whom?
<slangasek> The issue here is not "there is a ppa".  The issue is "someone thought it was a good idea to tell other people to use a ppa that says right on its cover that it's only for testing purposes"
<EvanCarroll> cease to function = cease to build.
<EvanCarroll> unmatained = no intention to maintan, not working for any use case.
<EvanCarroll> Delisted by whom = delisted by launchpad.net
<slangasek> why not ask upstream to delete the ppa?
<slangasek> last successful build in that ppa was 17 hours ago for xenial (https://launchpad.net/~videolan/+archive/ubuntu/master-daily/+builds?build_text=&build_state=all)
<EvanCarroll> slangasek: I have. Multiple. Multiple times.
<EvanCarroll> https://launchpad.net/~videolan/+contactuser
<EvanCarroll> no one responds slangasek where do you see that?
<slangasek> EvanCarroll: ok.  then you certainly can ask the Launchpad Team to intervene; I'm just not sure why they would
<EvanCarroll> slangasek: that's the xenial build start that succeeded, the build fails.
<EvanCarroll> actually wait, I'm looking into this. I didn't think it was still building on Xenial
<slangasek> EvanCarroll: ah, heh; I've never noticed before that the "build start" shows as a different record, ahwell
<EvanCarroll> Yea, I think this is just build start record.
<slangasek> ok, last successful build was precisely a year ago :) https://launchpad.net/~videolan/+archive/ubuntu/master-daily/+builds?build_text=vlc&build_state=built
<EvanCarroll> slangasek: there ya go
<EvanCarroll> that's about when the confusion started.
<slangasek> that's certainly an argument that it should be sunset. Maybe the launchpad team would care because it wastes build resources? :)
<EvanCarroll> I would hope the confusion it's causing is more of an issue. But, at this point whatever.
<EvanCarroll> It's a very common question people want vlc 3.x, and they the ppa just isn't there and the snap is broken and doesn't do h.265, and building vlc isn't exactly a walk in the park
<slangasek> EvanCarroll: so are you following up with the Launchpad team about this?  again, Ubuntu has no authority here
<slangasek> "and the snap is broken"> oh?  that's a different matter entirely; I certainly had the impression the snap was working well
<EvanCarroll> slangasek: yes, I'm in the wrong channel I'll admit
<EvanCarroll> slangasek: the snap is pretty borked too. I don't know where to view the change logs on that or the build options, but the meta data is wrong on the snap
<EvanCarroll> `snap info vlc` should tell me the git/version not just "daily" https://askubuntu.com/a/915164/29097 I don't think the snap is being updated either though
<EvanCarroll> it's certainly not updated daily
<EvanCarroll> win 3
<nacc> EvanCarroll: that's a choice made by the snap's owner
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<Unit193> Bah, creating build chroots still failing for me.
#ubuntu-devel 2017-08-12
<karstensrage> i am trying to package a libnss library i wrote and trying to figure out how best to package it
<karstensrage> all the libnss libraries in /lib/{arch} have a particular version like /lib/x86_64-linux-gnu/libnss_compat-2.19.so
<karstensrage> and then a symbolic link named /lib/x86_64-linux-gnu/libnss_compat.so.2 to that file
<karstensrage> so for my package should i try to mimic that? and then for different distributions, 14.04, 16.04, etc. whats a good way to pick that stuff up?
<sarnold> iirc ldconfig is in charge of creating those symlinks based on maps files
<sarnold> or perhaps on sonames..
<sarnold> check out ulrich drepper's paper on creating DSOs for linux, I expect that will describe it
<rbasak> cyphermox: seen bug 1681513 ?
<ubottu> bug 1681513 in network-manager (Ubuntu) "Ubuntu 17.04/17.10: New feature in NetworkManager stops several WiFi adapters from working (MAC Address Randomization issue)" [High,Confirmed] https://launchpad.net/bugs/1681513
<LocutusOfBorg> slangasek, the problem of vlc and ppa is this one: https://github.com/google/protobuf/issues/206
<LocutusOfBorg> I care about vlc nightly, but I failed to fix it
<LocutusOfBorg> I think this will become a serious issue in artful too
<LocutusOfBorg> vlc team is trying to avoid protobuf on that file, so eventually stuff will sort out
<tomreyn> could someone with bug tirage experience please take a look at https://bugs.launchpad.net/ubuntu/+bug/1689825 - it needs cleaning up
<ubottu> Launchpad bug 1689825 in lightdm (Ubuntu) "gnome-keyring not unlocked on boot" [Undecided,Confirmed]
<LocutusOfBorg> jbicha, hello, tsimonq2 would like to steal some merges from your hat, I hope you don't mind
<LocutusOfBorg> specially because tomorrow he will likely be a MOTU, so he will be able to steal them anyway :)
<jbicha> rbasak: I think ideally we'd have a setting for the MAC randomization feature in gnome-control-center but there might not be anyone to work on that this cycle
<rbasak> jbicha: what's your opinion on the default, given that some hardware apparently doesn't work with it? See the number of affected users in that bug.
<rbasak> jbicha: and it seemed that upstream have changed their minds about defaulting to on? I wasn't very clear on this though.
<acheronuk> LocutusOfBorg: could you copy the latest archive QtWebEngine back into the landing PPA? helps me with installability for testing and our CI if can get it from there, instead of -proposed or copying in into other testing PPAs
<jbicha> rbasak: I don't have much of an opinion on it, except that we need to have an easy option to disable (or enable) it
<jbicha> rbasak: could you email -desktop or -devel about it so that we can decide how we want to handle that for artful (and then for zesty maybe)?
<rbasak> jbicha: done
<jbicha> thanks :)
<LocutusOfBorg> acheronuk, sure!
<LocutusOfBorg> let me understand how
<LocutusOfBorg> ./copy-package --from=ubuntu --from-suite=artful-proposed --include-binaries qtwebengine-opensource-src --to=ppa:ci-train-ppa-service/ubuntu/2819 --to-suite=artful
<LocutusOfBorg> not sure if the world will explode or not
<LocutusOfBorg> it should be good in some minutes
<LocutusOfBorg> copyrights for the above command go to tsimonq2 :)
<acheronuk> LocutusOfBorg: or? https://launchpad.net/ubuntu/+archive/primary/+copy-packages?field.name_filter=qtwebengine&field.status_filter=published&field.series_filter=artful
<LocutusOfBorg> ctrl+R, find the latest copy-package invocation and run it swapping "to" and "from" :)
<LocutusOfBorg> as sooon as I don't have to open a browser I'm happy :p
<acheronuk> ok. fair enough. :P
<acheronuk> thanks :)
<LocutusOfBorg> you no core-dev?
<acheronuk> me? lol. no
<LocutusOfBorg> oh sad me
<LocutusOfBorg> this is why you asked
<LocutusOfBorg> meh
<LocutusOfBorg> in debian every developer is happy to have access to everything and possibility to break stuff
<acheronuk> indeed. permissions are hard to come by this side though
<LocutusOfBorg> anyhow, thanks for the nice and clean work! it is becoming really green the tracker
<LocutusOfBorg> I'm doing the cmake side of things
<jbicha> if you become a DD, it should be fairly easy to become a MOTU or maybe even Core Dev
<LocutusOfBorg> this is why I became a DD lol :)
<LocutusOfBorg> armhf YYSOSLOW
<juliank> cjwatson: Apparently the binary-pcc64el and some other architecture directory vanished for trusty-security, see https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1710399
<ubottu> Launchpad bug 1710399 in apt (Ubuntu) "Unable to install packages" [Undecided,New]
<juliank> cjwatson: The release file lists "Architectures: amd64 arm64 armhf i386 powerpc ppc64el", but there are only binary-amd64 and binary-i386
<juliank> infinity: ^
<cyphermox> rbasak: I had not, but I'm not so involved in NM anymore
<cyphermox> seems pretty weird that they'd enable something like that by default
<cyphermox> furthermore, it's not exactly a new feature...
#ubuntu-devel 2017-08-13
<willdeberry> Hello all! I was curious if this would be the correct location to get help with bzr and launchpad. I was attempting to tackle some things listed under one hundred papercuts. was following this guide: http://packaging.ubuntu.com/html/fixing-a-bug.html and this one as well, http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching.  No matter the syntax I try, i can't seem to check out the project. In this
<willdeberry> case the ticket was specific to pidgin
<tsimonq2> willdeberry: Hey there!
<tsimonq2> willdeberry: Why don't you meet me in #ubuntu-motu, we can take it from there :)
<Unit193> LocutusOfBorg: (Pinging you directly due to time running out) Have you or anyone else seen bug 1709733?
<ubottu> bug 1709733 in Ubuntu "[needs-packaging] xfce4-statusnotifier-plugin" [Wishlist,New] https://launchpad.net/bugs/1709733
<LocutusOfBorg> Unit193, why not in Debian^
<Unit193> LocutusOfBorg: As noted, it's in pkg-xfce's svn repo, not uploaded yet.
<LocutusOfBorg> so, when they upload it, it will get autosyncd?
<Unit193> Well we'd have to manually sync it, but chances are.
<Unit193> Would very likely want to include https://git.xfce.org/panel-plugins/xfce4-statusnotifier-plugin/commit/?id=21760d00c8e255f4bf83ddce1f387b1c034599f4 though. :P
<Unit193> LocutusOfBorg: Hrm, OK.  Well thanks anyway.
<LocutusOfBorg> I can manually sync it
<LocutusOfBorg> just make sure it goes in debian
<Unit193> It won't before FF.
<LocutusOfBorg> isn't it a leaf package?
<Unit193> LocutusOfBorg: Either this cycle or next we'll likely move from indicator-application+xfce4-indicator-plugin to this.
<Unit193> It's late, so likely next.
<mitya57> LocutusOfBorg, hi! thanks for abi-compliance-checker upload! do you have any idea why those KDE autopkgtests still fail on armhf?
<mitya57> Also, any idea why abi-compliance-checker's own autopkgtests fail?
<mitya57> LocutusOfBorg, re own tests: I made a new upload https://launchpad.net/ubuntu/+source/abi-compliance-checker/1.99.22-1ubuntu2, it should help
<tsimonq2> o/ mitya57
<mitya57> hi tsimonq2!
<LocutusOfBorg> <3 mitya57 :)
<LocutusOfBorg> I saw the upload, thanks
<LocutusOfBorg> for armhf don't know
<LocutusOfBorg> systemd is sad (can't install udev), and xnox is aware/looking at it already
<LocutusOfBorg> but meh, I'll have a look once queues go empty
<acheronuk> armhf mostly needs a retry against --all-proposed, but holding off doing most of that until the queue clear to minimise spamming it with duplicates
<acheronuk> and/or many of them failed for armhf on their 1st try, as they ran when QtWebEngine was lagging on it's armhf build, but was there for the other architectures
<LocutusOfBorg> we should be mostly good with this transition
<LocutusOfBorg> just worried about ubuntu-system-settings-online-accounts and ubuntu-settings-components
<LocutusOfBorg> maybe they just need a test rerun
<LocutusOfBorg> pytest-qt needs fixes
<LocutusOfBorg> (Debian suggests to just disable the testsuite)
<acheronuk> http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/artful/amd64
<acheronuk> blame: ubuntu-system-settings-online-accounts
<acheronuk> badpkg: Test dependencies are unsatisfiable.
<LocutusOfBorg> yep I see
 * acheronuk shrugs
<LocutusOfBorg> not sure which one
<LocutusOfBorg> we need qtbase-opensource-src, qtwebengine and qtdeclarative candidate for migration
<LocutusOfBorg> so I can parse britney's output
<LocutusOfBorg> but meh, late here, have a good night :)
 * LocutusOfBorg goes to sleep
<jbicha> I'd like for us to remove all the UOA stuff LP: #1695928
<ubottu> Launchpad bug 1695928 in gnome-control-center-signon (Ubuntu) "Please remove obsolete UOA packages" [Undecided,New] https://launchpad.net/bugs/1695928
<acheronuk> LocutusOfBorg: qml-module-ubuntu-components ?
<acheronuk> urgh! from src:ubuntu-ui-toolkit-gles
<Unit193> Hrm, looks like kicking up a i386 artful chroot isn't going so hot for me still: http://paste.openstack.org/show/cGj8uRFD3nm0PKN3D9T8/
#ubuntu-devel 2018-08-06
<cpaelzer> hi, when having autopkgtest run for the kernel I face something that surely isn't from my packages change
<cpaelzer> it is listed as
<cpaelzer> autopkgtest for linux/unknown: amd64: Regression â» , ppc64el: Regression â»
<cpaelzer> and the TL;DR is broken dependencies like
<cpaelzer> linux-generic : Depends: linux-image-generic (= 4.17.0.7.10) but 4.17.0.6.9 is to be installed
<cpaelzer> is that a kernel in flight to be released - or anything else that often happens and the way to get around it being clear?
<smb> sforshee, ^ maybe you know?
<sforshee> cpaelzer: that's because there's a window when linux-meta has been built but linux-signed has not yet, during that window you could end up with something like that
<sforshee> and in some cases that window can be long if there are signed bits waiting in the unapproved queue, which linux-signed needs to build
<cpaelzer> sforshee: so what is my todo on this - wait an retry daily/hourly/...
<cpaelzer> sforshee: or is there something I can look at to realize I'm unblocked and hit retry juts once?
<cpaelzer> the transition of most recent linxu-signed or so I guess
<cpaelzer> sforshee: so when https://launchpad.net/ubuntu/+source/linux-signed/4.17.0-7.8 hits c-release maybe?
<sforshee> cpaelzer: yeah that would be the thing to watch for
<sforshee> cpaelzer: or c-proposed rather
<cpaelzer> in c-proposed it is sforshee
<cpaelzer> maybe I need a combined trigger to pull it from there for the test
<Saviq> hi all, I'm trying to boot ubuntu-minimal in KVM and both 16.04 and 18.04 fail to go past the bootloader, complaining about missing root or hanging with no info, any suggestions?
<ahasenack> Saviq: you mean you are trying to boot the installed system, which you installed from the iso and selected "minimal installation"?
<Saviq> ahasenack: no, trying to boot ubuntu-minimal http://cloud-images.ubuntu.com/minimal/releases/
<ahasenack> oh, I didn't know about that, I thought it was just an installation target
<ahasenack> those files are not isos
<ahasenack> they are cloud images if I'm not mistaken
<ahasenack> "The Ubuntu Minimal Cloud image can be run on your personal Ubuntu Cloud, or on public clouds that provide Ubuntu Certified Images."
<ahasenack> there is a note about kvm: "When launching the download image from KVM, you will need to specify the virtio network driver."
<ahasenack> but that sounds like something that would create problems only after it found the root device
<Saviq> ahasenack: yeah, they're qcow2 images that should at least try and boot (and fail to find the networking adapter if virtio wasn't used)
<Saviq> it seems like something's wrong with how grub is set up there
<cpaelzer> sforshee: I just found linux-signed in proposed is 4.17.0-7.8 but the linux-meta is 4.17.0-7.10
<cpaelzer> so while something is in proposed it is not what I waited for :-/
<cpaelzer> I've added a linux-meta trigger on 4.17.0-7.10 and will see if that is enough
<sforshee> cpaelzer: no that's fine, it's the 4.17.0-7 that's important
<smoser> xnox: around ?
<smoser> looking at update excuses for software-properties
<smoser> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<sforshee> cpaelzer: though note that for linux-meta it's 4.17.0.7.10
<sforshee> but that last bit, the upload number, doesn't have to match between the two
<cpaelzer> ok
<cpaelzer> the autopkgtest cgi complains anyway if the version is bad, so I certainly specified a good one (with .10)
<Odd_Bloke> Saviq: Could you file a bug in the cloud-images project on Launchpad, please?
<Saviq> Odd_Bloke: ack
<Saviq> Odd_Bloke: https://bugs.launchpad.net/cloud-images/+bug/1785633
<ubottu> Launchpad bug 1785633 in cloud-images "Can't boot minimal images in QEMU" [Undecided,New]
<Odd_Bloke> Thanks!
<Odd_Bloke> Saviq: I've added an update to https://bugs.launchpad.net/cloud-images/+bug/1785633
<ubottu> Launchpad bug 1785633 in cloud-images "Can't boot minimal images in QEMU" [High,Confirmed]
<Saviq> Odd_Bloke: ack!
<kyrofa> Laney, do I remember correctly that you're the autopkgtest master these days?
<Laney> kyrofa: There's a few of us - which is handy, because I'm going in 2 minutes. :P
<kyrofa> Laney, ah! Good then. I can't seem to install snaps in armhf autopkgtests, do you (or anyone) know anything about that?
<Laney> what happens?
<Laney> I don't think we do anything specifically to prevent that working
<kyrofa> Laney, "error: cannot communicate with server: Post http://localhost/v2/snaps/go: dial unix /run/snapd.socket: connect: connection refused"
<Laney> dunno - is it running?
<Laney> You can use autopkgtest-build-lxd to make a container on your system, that might help
<kyrofa> Honestly I'm not sure. This same test works on other architectures fine
<kyrofa> It's just armhf that has that issue
<kyrofa> If I could only get a shell :P
<Laney> this one runs in lxd and the others are VMs, that's the main difference
<kyrofa> Oh interesting
 * Laney hands you over to slangasek (if he's here)
<kyrofa> When developing this test I ran with autopkgtest-virt-lxd, so I know it works there at least in amd64
<kyrofa> Thanks Laney :)
<slangasek> kyrofa: so at a glance, it appears the snapd package is not installed in the armhf autopkgtest containers by default.  That may be something we want to fix, but perhaps you want an explicit test dependency on snapd?
<slangasek> kyrofa: which autopkgtest is failing?
<kyrofa> slangasek, we have one, actually
<slangasek> ok
<kyrofa> slangasek, it's a new one we're adding, you can see a log here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20180804_011910_96ebe@/log.gz
<kyrofa> The test is integrationtests-spread
<slangasek> kyrofa: where do I see the source for the version of the package under test?
<kyrofa> slangasek, it's in a pull request at the moment: https://github.com/snapcore/snapcraft/pull/2188
<kyrofa> You'll want to skip the latest commit though, it's skipping the tests that install snaps on armhf
<slangasek> kyrofa: https://paste.ubuntu.com/p/wmjKV3q5vc/
<slangasek> is this related to the squashfs fuse stuff not being installed by default?
<kyrofa> slangasek, ah, interesting, I don't need that in lxd anymore since snapd started bundling something that made it work
<kyrofa> Where is that bug...
<kyrofa> bug #1628289
<ubottu> bug 1628289 in snapd (Ubuntu) "snapd should depend on squashfuse (for use in containers)" [Medium,Incomplete] https://launchpad.net/bugs/1628289
<kyrofa> Oh yeah, fuse.snapfuse, that sounds bundled
<slangasek> kyrofa: there is no 'fuse.squashfuse' command in either the snapd or squashfuse packages in xenial (at least on armhf).  So I don't know how this is supposed to be wired up.
<kyrofa> Yeah, me neither. mvo, are you around?
<mvo> kyrofa: sort of - I hear ./usr/bin/snapfuse ?
<kyrofa> mvo, having trouble installing snaps in armhf autopkgtests, slangasek was able to produce https://paste.ubuntu.com/p/wmjKV3q5vc/
<slangasek> mvo, kyrofa: 'ln -s /usr/bin/squashfuse /sbin/mount.fuse.squashfuse' works around it
<slangasek> not sure if /usr/bin/snapfuse works the same
<slangasek> signs point to yes
<mvo> slangasek: oh, interessting. I wonder what is going on there, fwiw, we have a automatic test that runs snaps inside lxd without squashfs-fuse or any other modifications
<mvo> kyrofa: looking
<mvo> kyrofa: what do I need to do to reproduce this?
<kyrofa> mvo, indeed, this same test runs fine in amd64 lxd
<slangasek> kyrofa: on xenial?
<kyrofa> mvo, you need the magical shell slangasek got :P
<kyrofa> slangasek, yes
<slangasek> k
<kyrofa> slangasek, to clarify, I'm running bionic, but I developed the test using `autopkgtest . -U -- lxd ubuntu:xenial`
<slangasek> right
<mvo> oh, so this is lxd inside armhf?
<slangasek> well, the host is arm64
<slangasek> the container is armhf
<kyrofa> And Laney mentioned that this is the only arch that works that way-- the others are VMs
<mvo> I can try this on my pi3 tomorrow
<slangasek> yes, and "the host is arm64" is precisely why we do armhf in containers
<slangasek> anyway, seems like a strange error message, hopefully that points to something
<kyrofa> mvo, thank you for looking into it!
<kyrofa> slangasek, thanks very much for your help. It sounds like I can work around this for now by symlinking /usr/bin/snapfuse to /sbin/mount.fuse.snapfuse ?
<slangasek> kyrofa: yes, it appears that works around it
<slangasek> at least as far as letting snapd start
<kyrofa> slangasek, alright, I'll take a crack at it for the whole test, let's see
<mvo> kyrofa, slangasek fwiw, the squashfuse deb also only ships./usr/bin/squashfuse  and no fuse.squashfsuse symlinks or anything like this afaict
<kyrofa> Very interesting
<slangasek> yeah, I have no idea how this works on !armhf
<dami0> hi, how do i change the default command line options when respining an iso? i tried grub.cfg in /boot/grub, tried gfxboot.cfg in isolinux, searched on google and only got advice to change grub.cfg
<TJ-> dami0: which options, for booting the ISO live, or for installing the OS?
<dami0> installing the os
<dami0> what i want to accomplish in the end is have a few custom entries in the boot menu for installing with different ks.cfg files predefined on the menu options
<TJ-> I recall that you achieve that by editing the kernel command-line of the ISO boot loader (GRUB and isolinux/syslinux) and add the entries you want the installer to add to the installed system after a "--" ... e.g. for GRUB "linux vmlinuz-$VERSION param1=one param2=two -- param1=three" will boot the installer with param1=one but set the installed command-line to param1=three
<kyrofa> slangasek, beyond copyright and docs, squashfuse indeed only includes the /usr/bin/squashfuse binary. No symlinks, as mvo said. However, something knows that all it needs is the squashfuse command: sudo mount -t fuse.squashfuse hello_20.snap foo
<kyrofa> /bin/sh: 1: squashfuse: not found
<kyrofa> (I removed both snapd and squashfuse for testing)
<slangasek> interesting
<mvo> slangasek: https://github.com/libfuse/libfuse/blob/master/util/mount.fuse.c#L103 is how the mount works, I wonder why this is different on armhf, it just strips the leading fuse. and tries to run the binary
<mvo> kyrofa: -^
<mvo> I mean, this is why it does not need the fuse.snapfuse
<kyrofa> mvo, which explains what I just found
<mvo> ups, wrong line: https://github.com/libfuse/libfuse/blob/master/util/mount.fuse.c#L137
<mvo> this is the right one
<mvo> kyrofa: yeah
<slangasek> mvo, kyrofa: ok, and does something ensure mount.fuse is installed?
<slangasek> it's only 'standard'
<slangasek> and wasn't present in the container I was looking at
<slangasek> so if 'mount' can't resolve either mount.fuse.squashfuse or mount.fuse, I don't expect it knows what to do here
<kyrofa> slangasek, wait, /sbin/mount.fuse wasn't present in the container you were looking at?
<slangasek> correct
<kyrofa> Huh, it's here on amd64
<slangasek> our containers use a different image
<slangasek> autopkgtests shouldn't assume ubuntu-standard
<slangasek> should snapd depend on fuse?
<slangasek> or should it just install its own mount.imasnap ?
<kyrofa> Great question
<kyrofa> slangasek, does that mean that running `autopkgtest . -U -- lxd ubuntu:xenial` is not actually giving me a representative image?
<mvo> slangasek: aha, nice catch!
<mvo> slangasek: I guess we could recomment fuse - otoh we don't really need it most of the time if in-kernel squashfs is available
<GunnarHj> infinity: Want to mention that I failed to verify the fix of bug #1762952. There seems to be more into it. It looks like the place where you dropped "grp:alt_shift_toggle" is for new installs where /etc/default/keyboard not yet exists. It's still set when you upgrade.
<ubottu> bug 1762952 in console-setup (Ubuntu) "Alternative shortcut for layout switching Alt+Shift unexpectedly set by default" [High,Confirmed] https://launchpad.net/bugs/1762952
<slangasek> kyrofa: appears so.  sorry, this seems to be under-documented on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_administration.  I'm trying to track down where the image generation actually happens
<slangasek> kyrofa: https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/development/tree/tools/autopkgtest-build-lxd
<slangasek> kyrofa: but this just does setup on top of the generic images that have already been published; we derive from images:ubuntu/xenial/armhf which also does not have ubuntu-standard
<slangasek> kyrofa: so I'm altogether unclear why we are using the images.linuxcontainers.org remote for these instead of cloud-images.u.c.  Laney ?
<kyrofa> mvo, slangasek recommends aren't actually installed in the tests, right? We can just add fuse to our debian/tests/control
<kyrofa> slangasek, thanks for digging into the lxc question, curious to know the outcome of that as well
<Laney> slangasek: Dunno.
<Laney> But it's always been autopkgtest-build-lxd, never using plain upstream images. Please document that in whatever appropriate place.
<ehashman> slangasek: ping
<ehashman> slangasek: do you have time to chat about https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863
<ubottu> Launchpad bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress]
#ubuntu-devel 2018-08-07
<mwhudson> why would i be getting messages like
<mwhudson> qemu-system-x86_64: failed to initialize KVM: Cannot allocate memory
<mwhudson> more often in cosmic?
<mwhudson> i have a lot of ram free now
<tsimonq2> mwhudson: What really grinds my gears about that is that when I go back and adjust the RAM but don't touch anything else, it won't let me install because of the storage being incorrect...
<tsimonq2> ^_^
<mwhudson> tsimonq2: hmm?
<tsimonq2> mwhudson: I've encountered that before, but for me it's always been faulty.
<cpaelzer> mwhudson: I'd not know of a particular reason why you'd fail more often to allocate memory
<cpaelzer> mwhudson: for me - personally - I had to realize that new chrome and KDE seems to hog a bit more ram than in the past
<Laney> looks like mariadb-server-10.1 is hanging somewhere in postinst on the arm64 autopkgtests
<Laney> LocutusOfBorg: that's your upload - bug #1785767
<ubottu> bug 1785767 in mariadb-10.1 (Ubuntu) "1:10.1.34-1 hanging in postinst of mariadb-server-10.1 on arm64" [Undecided,New] https://launchpad.net/bugs/1785767
<Laney> I'm going to try to do something to make it fail instead of going around forever
<scientes> kvm doesn't bring up a display anymore
<scientes> sudo kvm -m 4096M -drive format=raw,file=/dev/sdd -boot menu=on -cdrom /home/shawn/Downloads/debian-testing-amd64-DVD-1.iso
<scientes> [sudo] password for shawn:
<scientes> No protocol specified
<scientes> Unable to init server: Could not connect: Connection refused
<scientes> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
<scientes> gtk initialization failed
<TJ-> scientes: check the host's /proc/cpuinfo flags: field for vmx
<TJ-> scientes: has it got flipped off in the PC firmware setup?
<scientes> TJ-, no it works, it worked before i upgraded
<scientes> and i'm running amd
<TJ-> scientes: what does "kvm-ok" report?
<scientes> $ kvm-ok
<scientes> INFO: /dev/kvm exists
<scientes> KVM acceleration can be used
<TJ-> which kernel is this with?
<scientes> 4.17.0-6-generic
<scientes> amd64
<scientes> i think kvm works
<scientes> the problem is bringing up the graphics
<scientes> like qemu-system-x86_64 changed its defaults
<TJ-> scientes: ahh, OK, the vmx might be just a warning since it's not an Intel CPU... weird though, you'd think it's know the difference between Intel and AMD
<TJ-> scientes: "connection refused" - check /var/log/auth.log
<TJ-> scientes: I wonder if it's an apparmor profile issue, dmesg/kern.log/syslog might give a clue
<scientes> nothing in dmesg
<scientes> journalctl -f => nothing
<TJ-> scientes: the mention of "protocol" makes me think it may simply not know how to connect to the hypervisor.
<TJ-> scientes: I get a different warning but the GUI console starts "qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]"
<TJ-> scientes: try runinng it under strace, as in sudo strace -fe trace=file qemu-system-x86_64 ... |& tee /tmp/kvm.log
<scientes> virt-manager seems to work
<scientes> so again I think its a graphics issue
<TJ-> scientes: try "-display sdl" (I think the default is "-display gtk"
<scientes> qemu-system-x86_64: Display 'sdl' is not available.
<scientes> yeah i tried that earlier
<scientes> i managed to work around the problem with virt-manager
<TJ-> scientes: does "-display gtk" cause the same issue?
<scientes> yes
<TJ-> scientes: ahhh, apparently this is because you're running as root (sudo) and the root user doesn't have access to the display any more. Is this a wayland session by any chance?
<scientes> yes
<scientes> but it worked in wayland before
<scientes> maybe cause it was dsl
<scientes> *sdl
<scientes> it worked in Bionic
<TJ-> scientes: possibly it needs the xhost workaround
<scientes> hmm guess i need that the virt-manager workaround didn't work cause i had to forward the usb stick
<scientes> which must be buggy
<scientes> instead of just the raw /dev/sdd
<scientes> or maybe Ill just install normally
<cpaelzer> TJ as you found vmx/svm warnings are just not-the-cpu
<cpaelzer> yes it could detect a lot, but then users would need to set one or the other
<cpaelzer> the current form has the annoying warning but works without touching the cpu definitions
<cpaelzer> and yes sdl->gtk is a cosmic and later thing
<scientes> cpaelzer, how do i install sdl for qemu?
<scientes> do i need to build from source?
<cpaelzer> it was a switch from sdl to gtk backend
<cpaelzer> so sdl isn't configured anymore atm
<cpaelzer> sdl1 is supposed to fade out
<scientes> but it worked!
<cpaelzer> and sdl2 had too much issues
<TJ-> cpaelzer: is there a workaround for this running-as-root issue? or should the user be member of an additional group like "disks" to ensure kvm can operate unprivileged?
<cpaelzer> I need to read the backlog what your problem is, juts a sec ...
<TJ-> I recall in the dim distant past for kvm unprivileged adding groups disk plugdev cdrom dialout
<cpaelzer> that depends on what you are expecteing to have qemu do for you
<cpaelzer> at the very least kvm to use HW virt
<cpaelzer> cdrom obviously if you want to install from CD and so on ...
<TJ-> cpaelzer: of course, in this case scientes is accessing raw /dev/sdd so the process would need r/w access to that
<cpaelzer> yep
<cpaelzer> but in general if sudo is wanted, it is not stripping the DISPLAY
<cpaelzer> "sudo xeyes" (major Prod workload :-) ) - works fine
<scientes> I'm just installing =nographic like a caveman
<scientes> nah that doesn't seem to work
<scientes> with the debian testing cd
<scientes> virt-manager won't load /dev/sdd either
<cpaelzer> grml - no graphical Cosmic around to try
<cpaelzer> :-/
<cpaelzer> still maybe just needs xhost tweaks or such
<cpaelzer> but without retry I can't say for sure
<TJ-> scientes: is the user a member of the libvirtd group?
<scientes> i don't have that group
<scientes> libvirt:x:130:shawn
<scientes> libvirt-qemu:x:64055:libvirt-qemu
<cpaelzer> in new installs the group is only libvirt I think
<cpaelzer> and on upgrades it is libvirtd and libvirt on the same GID
<kyrofa> Hey slangasek, continuing our discussion from yesterday (snaps in armhf autopkgtest), adding fuse got us further, but now we have apparmor issues: https://pastebin.ubuntu.com/p/pVtNGPnfpq/ . Do you know what the host OS is for these tests?
<kyrofa> slangasek, also, https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/development/tree/tools/autopkgtest-build-lxd doesn't look like it, but any chance this is a privileged container?
<kyrofa> Or confined in some other way?
<slangasek> kyrofa: host OS is an LTS, it's probably still xenial rather than bionic; I don't know how privileged the containers are, that's something I would have to look at - I don't think we're doing any handling of lxd profiles the way launchpad does
<kyrofa> slangasek, huh, xenial should be fine. If they're unprivileged that should also be fine, but sounds like their being privileged would be an issue
<slangasek> oh interesting
<kyrofa> slangasek, I'll try to see if I can duplicate on my rpi
<jamespage> slangasek: hullo - do you think it might be possible to get the python 3.7 in bionic universe to a more maintained status?  there is a bit of a thread going on upstream in openstack about python 3.7 gating for changes, but the  gates always stick on our LTS'es - which currently means python 3.6
<jamespage> that would also help our interim release work up until 20.04 which I guess we would like to not include python 3.6 :-0
<slangasek> jamespage: er, I think that's square peg, round hole; we should figure out how to get openstack to where it's able to CI against latest python3 without having to SRU newer pythons into an LTS
<slangasek> I expect python3.8 will happen in 20.04 kind of timeframe, and we don't want to be SRUing that back to 18.04 either
<ahasenack> any idea what is going on here? https://pastebin.ubuntu.com/p/CBvNgDmp9d/
<ahasenack> the python3-sss.install file specifies certain directories and files
<ahasenack> but what ends up in the package is something else, mangled
<ahasenack> usr/lib/python3*/site-packages/pysss.so becomse usr/lib/python3/dist-packages/pysss.cpython-36m-x86_64-linux-gnu.so
<ahasenack> and the build doesn't fail, not even due to the different directory (site-packages vs dist-packages)
<ahasenack> we have a delta with debian (this is the sssd package) that changes {site,dist}-packages/ in *.install files to *-packages/
<ahasenack> but without that delta, the build still works, and both packages (with and without the delta) end up with the mangled .so file
<TJ-> ahasenack: "36m" looks like a shell ANSI colour code, and the rest is an arch triplet
<TJ-> ahasenack: someone typed a [ or ] instead of { or }
<ahasenack> it's the same in bionic
<ahasenack> import pysss and pysss_murmur works, so that mangling is expected
<ahasenack> or rather, coped with
<TJ-> ahasenack: interestingly: ./build/ltmain.sh:498:        tc_blue='';  tc_cyan='36m'
<ahasenack> odd
<TJ-> might be a red-herring but I suspect there's a shell script/Makefile with a typo
<TJ-> because Makefiles use @TRIPLET@ as a replacable for the postinst scripts, as well
<ahasenack> run this and you will likely find tons of such files: find /usr/lib/python3/ -name '*.so'
<TJ-> ahasenack: none... on Bionic
<ahasenack> I have a ton
<ahasenack> like
<ahasenack> python3-systemd: /usr/lib/python3/dist-packages/systemd/_journal.cpython-36m-x86_64-linux-gnu.so
<TJ-> ahaha,I mistyped as .do not .so, yes I see some now :)
<ahasenack> ok :)
<TJ-> is there a bug in the python build tooling? that really looks strange
<ahasenack> don't know
<ahasenack> I've heard the term "colouring" related to architectures before
<ahasenack> hardware details, that kind of thing
<ahasenack> I have to run, will check back later
<TJ-> ahhh, makes sense, but can't find the 36m part documented
<TJ-> ahasenack: solved! read the README.rst for the dh-python package, the output of pybuild apparently when set to site-packages is translated to dist-packages
<TJ-> ahasenack: also it sets the cpython-36m-$TRIPLET into the name
<kyrofa> slangasek, at long last, I found my rpi, got ubuntu core on there, installed lxd, created an instance... and snaps work fine on it
<kyrofa> I can't seem to duplicate what we see in autopkgtests
<kyrofa> slangasek, if I create a privileged container, snaps don't install but with different errors: https://pastebin.ubuntu.com/p/3QZkty2chS/
<kyrofa> slangasek, I'm out of ideas regarding what's wrong without shell access. Something is odd with apparmor in the armhf autopkgtest runners
<slangasek> kyrofa: do you want a dump of the container config, to try to replicate?
<kyrofa> slangasek, wouldn't hurt
<kyrofa> slangasek, while we continue digging into this, I'd like to land that test suite. It runs everywhere except armhf, and I'd obviously like to get it running there. Is that worth setting up an ignore, you think? Or should I disable those tests for armhf?
<slangasek> kyrofa: short-term, I think the best approach that doesn't require us to use a huge hammer on the Ubuntu side and cause you to lose all CI gating for armhf, nor require you to hard-code an architecture exclusion list, is to mark that particular test as isolation-machine
<slangasek> kyrofa: and then either it'll start to work at some future point when armhf stops using containers for autopkgtests, or we figure out what's incompatible and fix it, then drop that constraint from the control
<kyrofa> slangasek, oh wait, that would run this in a VM?
<slangasek> kyrofa: no, it would cause the test to be skipped because there is no VM available
<kyrofa> Ah, gotcha
<kyrofa> slangasek, but the other architectures would continue working, as they're VMs anyway?
<slangasek> kyrofa: https://paste.ubuntu.com/p/W7VX2SB5Fr/
<slangasek> kyrofa: correct
<kyrofa> slangasek, that must be lxd 2.something?
<slangasek> kyrofa: appears to be 2.21 on xenial
<kyrofa> slangasek, the raw.lxc looks interesting, but I've got 3.3 from the snap, changing tracks now
<kyrofa> slangasek, heeey exact same error message, that's it! https://pastebin.ubuntu.com/p/mVBKB7ZSHn/
<kyrofa> slangasek, do we know the reasoning behind that raw.lxc snippet?
<kyrofa> slangasek, snaps work without it, and are broken with it
<slangasek> kyrofa: not offhand.  I'll check vcs history
<kyrofa> Thank you
<slangasek> kyrofa: nope, it's part of the original VCS import by pitti in 2016
<slangasek> ohwait, that's a file rename
<kyrofa> Oh. Darn, less helpful
 * slangasek looks further
<kyrofa> Ah
<slangasek> kyrofa: 94e64ec7287b5e8597037666f1e31223b02a0b4d "- "lxc.aa_profile=unconfined" to allow tests like pbuilder to mount /proc and other virtual file systems. Unprivileged containers can't do seriously bad things anyway, so AppArmor is just a backup line of defence. But that's too strict for several tests."
<slangasek> so it's been that way since 2015 and it appears we're now in the state that either direction we flip it, some tests will be unhappy
<kyrofa> slangasek, huh, interesting. Do you see any path toward changing that, or allowing tests to somehow request normal unprivileged containers?
<slangasek> I would rather we figure out what privileges are missing to let snapd be happy having privileges
<kyrofa> mvo is long EOD, zyga any chance you're around?
<kyrofa> jdstrand could probably help us understand what's happening here, as well
<kyrofa> Assuming they're all EOD, we can reconvene in the morning slangasek :) . Good progress hunting this down today, thank you!
#ubuntu-devel 2018-08-08
<Saviq> Odd_Bloke: hey, re: minimal again, do you know if /dev/tty0 and friends are possible to re-enable at all?
<Saviq> Odd_Bloke: just realized CONFIG_VT is disabled in there, so that probably says 'no'...
<ahasenack> doko: hi, around? Do you recall what you were trying to fix with https://git.launchpad.net/ubuntu/+source/sssd/commit/?id=39e4993bf605d89aaa8aaafc562838ed3422d7ef ?
<ahasenack> never mind the initscript, or the /usr/local bit, just the site-packages -> *-packages bit bit
<ahasenack> the build works without it, and it's a delta we are carrying, I'm wondering if we still have to carry this delta
<ahasenack> and the paths in the *.install files don't seem to mean much for what ends up in the package: https://pastebin.ubuntu.com/p/CBvNgDmp9d/
<TJ-> ahasenack: did you see my replies last night after you left/
<ahasenack> TJ-: yep
<ginggs> ahasenack: see the build failures here https://launchpad.net/ubuntu/+source/sssd/1.16.1-1ubuntu2
<ahasenack> so maybe dh-install or dh-python changed in cosmic since then?
<ahasenack> but good to have a link now, thanks ginggs
<ginggs> ahasenack: yw, i guess they could have changed.  maybe try rebuilding 1.16.1-1ubuntu2 now and see what happens
<ahasenack> it worked, but let me try in a proper ppa, without universe, etc
<ahasenack> TJ-: where did you see the bit about the cpython-36m in the module name? readme.rst?
<TJ-> ahasenack: I think I grep-ed for it in the package
<Odd_Bloke> Saviq: I don't know, no; could you file a bug that I can point some (hopefully) more knowledgeable people at?
<rbasak> seb128: why did you remove the tag from bug 1606828? It does look like it should be Fix Released now though?
<ubottu> bug 1606828 in bind9 (Ubuntu) "BIND Stable Version 9.10.4" [Wishlist,Triaged] https://launchpad.net/bugs/1606828
<seb128> rbasak, because bionic has 9.11 so that's not an update needed
<seb128> rbasak, but yeah, closing would work as well, I just wanted to get the bug out of one of our reports since it was boggus
<rbasak> I see, OK. I favour Fix Released as that status line is for the development release, and it's done there now.
 * rbasak does so
<seb128> rbasak, wfm, I was unsure if 9.11 was a new version or serie and if the current version included all the fixes from 9.10.4 so I didn't want to take the decision to close it
<jamespage> slangasek: I think the desire is to always test on the latest Ubuntu LTS which is ok - the primary gate would still be python 3.6, but if we can figure out a way to supply newer python versions (3.7, 3.8) onto 18.04, then we're less likely to see specific issues with those versions appearing as we move towards 20.04
<jamespage> (context was python 3.7 in bionic)
<TJ-> Could someone take a look at Bug #1686084 which affects Bionic, multiple users poked me about in IRC. Originally started in Zesty. Doesn't exist in Cosmic.
<ubottu> bug 1686084 in x11vnc (Ubuntu) "x11vnc terminates with **stack smashing detected** error" [High,Confirmed] https://launchpad.net/bugs/1686084
<kyrofa> Hey mvo, yesterday we tracked down why the armhf autopkgtest runner can't install snaps. Take a look at the profile being used: https://paste.ubuntu.com/p/W7VX2SB5Fr/
<kyrofa> mvo, take note of the raw.lxc section
<mvo> kyrofa: hm, hm, this indicates this should work I guess?
<kyrofa> mvo, this profile works without the raw.lxc, and gives these types of errors when it's present: https://pastebin.ubuntu.com/p/mVBKB7ZSHn/
<mvo> kyrofa: so if you make the profile *unrestricted* it gives you permission denied errors but if you use the default (which I assume is restricted) it works? did I get this right?
<kyrofa> mvo, rather than change the profile (which according to git was done to make pbuilder useful), slangasek was hoping to learn what was missing to make snapd happy having more privilege
<mvo> kyrofa: maybe stgraber can help? I find this deeply confusing. I don't know why it works with more confinement and stops working when unconfined
<mvo> kyrofa: I will set it on the todo list to investigate though, I pressume htis is reproducible on x86 as well(?)
<kyrofa> mvo, I haven't tried, I installed lxd from the 2.0 track on my rpi (that lxc.raw bit is invalid for 3.0, it seems)
<kyrofa> That's how I was able to duplicate
<kyrofa> But yes, I wouldn't be surprised
<kyrofa> If it _doesn't_ break on x86 I'll be quite confused indeed :P
<mvo> jdstrand: do you have any idea why lxd could start failing to install snaps with the setting:    lxc.aa_profile=unconfined
<mvo> kyrofa: yeah, a "fun" problem - a deep rabithole
<mvo> kyrofa: on the bright side, if we solve this, maybe we can even run our autopkgtests inside lxd in armhf :)
<kyrofa> mvo, exactly! Would be very nice to solve
<stgraber> because lxc.aa_profile=unconfined means that there is no apparmor at all so snapd in the container would modify the host's apparmor which also normally means we won't give the container cap_mac_admin/cap_mac_override
<stgraber> what snapd needs is an apparmor namespace
<mvo> stgraber: so we can fix this on our side? do we need to detect if we run inside an unconfined container
<stgraber> mvo: you should be able to detect a lack of mac_admin/mac_override capabilities which would mean you can't interact with apparmor
<mvo> stgraber: ok, so if we don't have mac_admin, what should we do then, can we create the apparmor namespace ourselfs (pardon my ignorance) or should we just display some sensible message
<stgraber> nope, if you don't have mac_admin you won't be able to do anything apparmor-related
<stgraber> so you could treat the system as if it had apparmor disabled
<mvo> stgraber: that sounds sensible, let me try to figure out how to detect this
<rbasak> seb128: that makes sense. I was looking at it from the opposite perspective of it being a general version bump request rather than for any specific bugs, which is why I tagged it. But either way it's gone now :)
<seb128> rbasak, good :)
<kyrofa> mvo, that would be excellent, please let me know if I can help test, my rpi is still setup
<mvo> kyrofa: still trying to figure that out
<kyrofa> I've gotten a few autopkgtest failures today that I can't quite reason out, can I get some help? Here's an example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/amd64/s/snapcraft/20180808_180049_8e0aa@/log.gz
<kyrofa> The pkgProblemResolver bit seemed odd
<kyrofa> I thought maybe it was temporary archive flux, but it's happened twice now
 * jdstrand reads backscroll and see that the conversation resolved itself
<jdstrand> sees*
<infinity> GunnarHj: Ah-ha.  Found why I can validate and you can't. :P
<infinity> GunnarHj: My package works on upgrade from xenial to bionic-proposed.  However, if you upgrade to bionic in between, then delete XKBOPTIONS from the config file, the upgrade to bionic-proposed, it pulls options from debconf.  Fixing.
<GunnarHj> infinity: Great, thanks!
<infinity> GunnarHj: Well, fixing when I wrap my head around it.  For the record, this bug has existed forever, it's just that until now (I guess) no one hand-edited /etc/default/keyboard, deleted XKBOPTIONS, and expected that to work. :P
<infinity> GunnarHj: The problem is that we load all the options from debconf, then overwrite them by sourcing /etc/default/keyboard
<infinity> GunnarHj: So, if XKBOPTIONS is gone entirely, instead of registering that as "the user has no xkboptions", we still have the old debconf answers.
<infinity> GunnarHj: Which means, I guess, I need to replace sourcing the file with an actual file parser that treats missing vars as empty.
<infinity> (ick)
<GunnarHj> infinity: I agree on your background description. The increased importance of the issue is the combination of the GNOME behavior and the fact that GNOME is now the default desktop.
<GunnarHj> infinity: GNOME and Debian don't play well together in this respect.
<infinity> GunnarHj: Yeah, whatever file parsing madness I come up with here, I'll push to Debian too.  It's clearly a bug that we're ignoring user preferences in the case of deleted vars.
<infinity> GunnarHj: It's just that, I suspect, no one really noticed until now.
<mwhudson> infinity: so i got assigned this bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1777900 -- without thinking about it at all hard do you have any intuition where the problem might be?
<ubottu> Launchpad bug 1777900 in ubiquity (Ubuntu) "oem-config breaks the systemd resolved link for /etc/resolv.conf in 18.04 server " [Undecided,Confirmed]
<infinity> ubiquity$ rgrep -l resolv\.conf | egrep -v '^debian|^d-i'
<infinity> bin/oem-config-remaster
<infinity> scripts/plugininstall.py
<infinity> mwhudson: ^--- I'd guess one of those two files. :P
<mwhudson> heh
<mwhudson> i think oem-config-remaster is ancient cruft
<infinity> It seems so.
<infinity> And the pluginstall bit starts with:
<infinity>         if self.target != '/':
<infinity>             for path in ('/etc/network/interfaces', '/etc/resolv.conf'):
<infinity> Which means it shouldn't run during oem-config.
<infinity> But maybe that's the very problem.
<mwhudson> i think i'm going to mark /etc/resolv.conf immutable before running oem-config and see what breaks
<mwhudson> which might not be terribly revealing but maybe worth a go
#ubuntu-devel 2018-08-09
<mwhudson> oh apart from the fact that you can't chattr a symlink
<mwhudson> oh well
<sarnold> bummer. I liked that idea.
<sarnold> are you at a point that you could install auditd and use auditctl to add a file watch?
<mwhudson> it also appears that there is no debug shell on tty2 during oem-config
<mwhudson> which makes everything else harder
<sarnold> ow
<mwhudson> i'm sure i fix that by mounting the image and screwing around in /lib/systemd though
<mwhudson> +can
<infinity> mwhudson: is_resolved_used() in netcfg-common.c is suspect, IMO.
<infinity> char *path = realpath(RESOLV_FILE, NULL);
<infinity> resolved_used = !strcmp(path, RESOLVED_FILE);
<infinity> RESOLVED_FILE   "/run/systemd/resolve/stub-resolv.conf"
<mwhudson> yeah i saw some stuff in there that didn't quite make sense
<infinity> Oh, no.  That should work.
<infinity> realpath() should resolve ../run to /run
<infinity> mwhudson: I think it's something more subtle.  Like maybe it's being put in static config mode halfway through.
<infinity> mwhudson: In mine, I noticed that after DHCP, it then asked me for a nameserver (which is very suspect).  Did you get the same there?
<infinity> And I just hit enter, so then it had nothing to write to resolv.conf, thus giving me a blank one.
<mwhudson> yeah istr that
<mwhudson> er
<infinity> Okay, I've stopped caring for today.
<mwhudson> infinity: is the fact that /etc/resolv.conf is a _broken_ symlink when oem-config comes up likely to be relevant?
<mwhudson> is it just that systemd-resolved isn't running, i wonder
<infinity> mwhudson: Yeah, that's potentially relevant.
<mwhudson> yeah that seems to have stopped it asking for a nameserver
<mwhudson> (running systemctl start systemd-resolved in another tty)
<infinity> Oh, is it just a unit ordering issue?
<infinity> I imagine the oem-config systemd integration isn't heavily tested.
<mwhudson> yeah
<mwhudson> not so much an ordering as just nothing causing it to be started
<mwhudson> afaict anyway
<infinity> Well, yeah.  Same thing.
<infinity> As in, the target needs some more stuff in Wants, probably.
<mwhudson> yeah
<infinity> If that's all it is, easy fix.
<mwhudson> infinity: https://code.launchpad.net/~mwhudson/ubiquity/+git/ubiquity/+merge/352792 ?
<infinity> mwhudson: Tested and works?
<mwhudson> infinity: no
<mwhudson> infinity: lunch has a higher priority than that
<mwhudson> infinity: but if it looks ok in spirit i can get onto that
<infinity> mwhudson: Heh.  I'm in the middle of a fresh test install ehre.  I'll test it.
<mwhudson> infinity: ok thanks!
 * mwhudson lunches
<mwhudson> oh ffs
<sarnold> quick go grab a second lunch
 * tsimonq2 passes mwhudson a Lunchâ¢
<mwhudson> heh
<infinity> Oh FFS is right.  Apparently, one shouldn't reboot after installing oem-config if you don't prepare first..
<infinity> Or maybe there's some other reason my boot is stalling...
<infinity> Man, I hate computers.
<infinity> Especially fake ones.
<ehashman> my xubuntu VM is very confused by virtualbox display settings
<ehashman> which apparently fails to set a display size so every time I log into it I get a System Error
<infinity> I'm very confused by people using virtualbox.
<ehashman> well, when your employer is like "plz install this rootkit to connect to the corporate VPN" and you're like "no", it's an option
<mwhudson> infinity: earlier on, i installed, ran oem-prepare, shut the instance down.. and then promptly deleted the image
<mwhudson> infinity: are you getting anywhere or is it worth me trying to test too?
<infinity> mwhudson: I'm redoing an install (nearly done) to figure out why my last one decided it didn't like booting anymore.
<mwhudson> uh ubiquity git tip ftbfs
<infinity> mwhudson: Excellent.
<mwhudson> because of lint
<mwhudson> the best kind of ftbfs
<infinity> That moment when you've set your VM's login to ubuntu/ubuntu and it takes you FOUR FRIGGIN TRIES TO TYPE IT CORRECTLY.
<infinity> mwhudson: Pastebin the linty sadness?
<mwhudson> ./tests/run-pyflakes
<mwhudson> bin/ubiquity:100: 'termios' imported but unused
<mwhudson> bin/ubiquity:100: 'termios' imported but unused
<sarnold> man these ken thompson attacks are getting annoying.. time was you only got the extra prompts once
<infinity> mwhudson: That's not tip.
<infinity> mwhudson: Get current.
<mwhudson> infinity: best is when you typo ubuntu twice the same way in the installer
<infinity> ubnutu is how I usually (mis)type it.
<infinity> In fact, the last commit to ubiquity is a fix of that. :P
<mwhudson> ah wait
<mwhudson> i'm on the bionic branch
<infinity> Oh gross, was that committed to bionic too?
<mwhudson> yeah and not reverted from there
 * mwhudson has read git log now
<tsimonq2> infinity: I was going to say... :P
<infinity> mwhudson: Confirmed that the fix is full of tasty fixy goodness.  Merging.
<mwhudson> infinity: thanks
<mwhudson> infinity: how are ubiquity SRUs handled?
<infinity> mwhudson: Expand that question?
<mwhudson> infinity: well we want this fixed in bionic i presume
<infinity> mwhudson: We do indeed.
<mwhudson> do i need to do things to the bionic branch in git (like reverting that suspect commit?) or do i just get the source package from bionic, splat the fix in and upload it to unapproved?
<mwhudson> and fiddle with the bug
<infinity> mwhudson: Or submit an MP.
<infinity> mwhudson: But I'm doing that revert first.
<mwhudson> ah ok
<infinity> mwhudson: There, bionic branch should look less poop now.
<mwhudson> indeed
<mwhudson> infinity: https://code.launchpad.net/~mwhudson/ubiquity/+git/ubiquity/+merge/352793
<infinity> mwhudson: Ta.
<infinity> mwhudson: Was there some sense of OMG urgency when this card landed in your lap, or can we let it sit there while we roll up a few more fixes?
<mwhudson> infinity: that sounds like a question for someone who is on vacation or someone who is sick
<infinity> mwhudson: Right, I'm going to call it not super urgent, then.
<mwhudson> infinity: seems fair
<infinity> mwhudson: iz merged, though.
<mwhudson> infinity: thanks
<seb128> is launchpad rendering weirdly/without images/formatting for others or is it just me?
<infinity> seb128: Rollout issue, Colin's on the job.
<seb128> k, thanks infinity
<cjwatson> I forgot about the weird way that code and DB deployments both use the same intermediate tree so doing both at the same time results in bdaness
<cjwatson> *badness
<infinity> Ouch.
<cjwatson> LP fixed
<seb128> cjwatson, thanks!
<Lord-Kamina> Hi. where does if_link.h come from?
<stgraber> stgraber@castiana:~$ find /usr/include/ | grep if_link.h
<stgraber> /usr/include/linux/if_link.h
<stgraber> stgraber@castiana:~$ dpkg -S /usr/include/linux/if_link.h
<stgraber> linux-libc-dev:amd64: /usr/include/linux/if_link.h
<Lord-Kamina> Thank you.
<Lord-Kamina> Can I just backport those headers or do I need to backport something else for them to work properly?
<Lord-Kamina> Nevermind, thought they were a source package on their own.
<seb128> xnox, can libzstd be synced now? looks like the delta you added was only for xenial upgrades?
#ubuntu-devel 2018-08-10
<ginggs> seb128: note libzstd was merged from 1.3.3+dfsg-2 in Debian NEW queue, which was rejected, and a different 1.3.3+dfsg-2 was uploaded. missing at least the udeb stuff
<seb128> ginggs, k, then a merge or dropping those changes from Ubuntu as well?
<ginggs> seb128: hmm, depends how attached xnox is to those udebs
<cpaelzer> Skuggen: sil2100: hiho
<Skuggen> o/
<cpaelzer> sil2100: I'd want for Skuggen to be able to use bileto
<cpaelzer> I know the bileto-users LP group
<cpaelzer> but there was something else that my brain doesn't want to remember
<cpaelzer> sil2100: do you know what else he'd need to fully use it?
<rbasak> For background, Skuggen works for MySQL upstream at Oracle. He generally looks after MySQL packaging in Debian and Ubuntu. He's not an uploader currently but I hope he'll get MySQL PPU soon.
<sil2100> Hey! Give me a minute guys
<sil2100> cpaelzer: sorry it took so long - so, I guess Skuggen would need to do manual uploads to Bileto, right?
<sil2100> Skuggen: do you have any upload rights to the archive right now? Could I get your LP id?
<sil2100> Since it's a bit tricky right now, we don't have any hard-written policies who should be able to use Bileto, but we have some rules of the thumb - I actually wanted to bring up the topic of Bileto for a while, but we're still not really certain about its fate
<sil2100> Maybe it's time for me to start the topic anyway
<sil2100> For general Bileto MP-based usage we mostly only require ubuntu membership, but for manual uploads - well, those we usually only gave to people with at least any upload rights to the archive
<sil2100> I think Bileto membership should be also reviewed and decided by the DMB, IMO, and that's also one thing I wanted to discuss
<cpaelzer> sil2100: yes he'd want to upload to the bileto ppas then
<sil2100> But since Bileto is still in bare maintenance mode, well, I guess we'd first have to decide if we want to invest the DMB's time in Bileto membership control
<cpaelzer> rbasak: do you know the current state of Skuggen 's upload permissions
<cpaelzer> I know more are about to come, but what does he have like now?
<sil2100> In case he has no upload permissions, if he really wants to have Bileto upload rights ASAP then I'd recommend attending a DMB meeting for this
<sil2100> And maybe actually following the procedures as per any other upload rights
<cpaelzer> sil2100: he might have some, but no core-dev or anything similar wide-reaching
<cpaelzer> sil2100: this is mostly to allow him to quickly iterate on uploads and trigger dep8 tests
<cpaelzer> sil2100: would there be any alternative way to get the "LP base autopkgtest exec of all deps" that Bileto provides to a non Bileto ppa?
<rbasak> He currently has no upload access.
<rbasak> He intends to apply for MySQL PPU imminently.
<rbasak> https://launchpad.net/~lars-tangvald
<sil2100> rbasak, cpaelzer: ok, I think in this case I'd defer to the DMB, I think we'd actually need a normal, formal review as for any other PPU access
<rbasak> What are the implications of Bileto access in terms of the Ubuntu archive?
<sil2100> rbasak: first of all, the user gains access to devirt builders
<sil2100> rbasak: also, since there is no ticket-specific ACL in Bileto, having upload access to Bileto PPAs means anyone can affect any other people's ongoing tickets
<rbasak> access to devirt builders> I'd say that's more of a matter for infrastructure maintainers - Canonical and therefore Launchpad admins maybe, rather than the DMB?
<sil2100> Meaning a melavolent user could upload something to someone's other PPA, which (even though audited) could go unnoticed and therefore get uploaded to the archive
<rbasak> That's a bit tricker.
<rbasak> trikier
<rbasak> trickier
<rbasak> \o/
<tkamppeter> cyphermox, hi
<Skuggen> I don't think it's very urgent, so maybe try to get MySQL PPU access first
<rbasak> Yeah that seems the easiest.
<sil2100> The unwritten rule so far was that anyone that has at least PPU access is 'trustworthy' enough to use Bileto
<rbasak> We would still need to decide if PPU uploaders are permitted to upload to Bileto in general.
<rbasak> OK
<rbasak> Then we can just do that.
<rbasak> Thanks
<Skuggen> Right. Thanks :)
<sil2100> Skuggen: sorry about that, hope to see your PPU application soon!
<tkamppeter> I have a problem with ppc64el. The build of ghostscript gets stuck on it and the build server kills the process after 2 hours, see https://launchpad.net/ubuntu/+source/ghostscript/9.23~dfsg+1-0ubuntu1
<tkamppeter> slangasek, could you help on this?
<acheronuk> tkamppeter: ah. was just asking in #ubuntu-release about that
<acheronuk> being retried, though I am not sure that will help
<slangasek> in any event, it means the logs are gone now so I can't guess at the problem
<ginggs> tkamppeter: ppc64el in ubuntu defaults to building with -O3, I suggest you try building in your PPA forcing -O2 and seeing what happens
<acheronuk> slangasek: drat. build currently hung at the same point, which is then killed at the 150 min timeout without much diagnostic to be honest
<acheronuk> slangasek: I have the last log open in a browser tab if you want it?
<ginggs> acheronuk: the URL might help
<ginggs> i don't think they are removed right away
<acheronuk> https://launchpadlibrarian.net/382631754/buildlog_ubuntu-cosmic-ppc64el.ghostscript_9.23~dfsg+1-0ubuntu1_BUILDING.txt.gz
<Laney> It'd already failed at least one retry, so this one is quite optimistic.
<acheronuk> :/
<Laney> "10/08 15:33:54 <ubottu> Review: quiet '$~a' set on Wed Aug  1 14:41:29 2018 in #ubuntu-meeting, link: https://ubottu.com/bans.cgi?log=78631"
<Laney> Why did the bot just PM me that?
<Laney> Oh, it's asking me to review a channel mode change since I'm an op?
<Laney> Yes, I approve of this change â
<tkamppeter> ginggs, I had used PPAs for some tests some years ago, but they only built for amd64 and i386. how can one make them build for ppc64el?
<ahasenack> tkamppeter: it's a checkbox in the details page
<ginggs> tkamppeter: go to your PPA in launchpad, click on 'Change details', scroll down to Processors and click on the checkboxes
<ahasenack> sil2100: hi, I saw the conversation about bileto earlier, and I would also like bileto rights. I have PPU for landscaoe-client, and ubuntu server packageset. my lp id is ~ahasenack
<tkamppeter> ahasenack, ginggs, thanks.
<sil2100> ahasenack: hey! Ok, I guess I can work with that, one moment
<blackboxsw> hrm, anyone know why I might be getting Error checking signature  during a dput operation for a package upload (line 24) https://pastebin.ubuntu.com/p/Wq3jqvTmgx/?    This is my first time trying to upload with this key (well and a cloud-init upload attempt yesterday)
<smoser> blackboxsw: i think it is probalby the local portion of 'dput' that is complaining there.
<smoser> it *does* seem to upload.
<smoser> blackboxsw: what happens if you just 'gpg --verify ../out/<that-dsc-file>'
<blackboxsw> ahhh
<blackboxsw> gpg: Good signature from "Chad Smith <chad.smith@canonical.com>" [unknown]
<blackboxsw> gpg: WARNING: This key is not certified with a trusted signature!
<blackboxsw> gpg:          There is no indication that the signature belongs to the owner
<smoser> right. you dont trust yourself.
<blackboxsw> I bet I need to edit my signature and add trust
<smoser> thats something maybe elizabot can help you with :)
<smoser> but if that was the only issue with your cloud-init upload yesterday, i would have expected it to go through
<smoser> and it did not seem to.
<smoser> curtin did
<smoser> https://launchpad.net/ubuntu/+source/curtin/18.1-44-g2b12b8fc-0ubuntu1
<blackboxsw> hrm ok just cloud-init didn't then
<blackboxsw> https://launchpad.net/ubuntu/+source/cloud-init/18.3-24-gf6249277-0ubuntu1
<blackboxsw> which was prior to me associating by new key with my launchpad account
<blackboxsw> ok so I might be able to upload a new version of cloud-init to check
<smoser> yeah. that makes sense. but id' have thoguht you'd have gotten a rejection or something.
<tkamppeter> ginggs, I have compared the end of the log of the ppc64el build of ghostscript with the log of the build on my amd64 machine. It does not hang on a compiler action biut on an action of creation of simple text files (./soobj/aux/echogs call, echogs source is ./base/echogs.c), so -O3/-O2 replacement on gcc calls is most probably not the solution.
<ginggs> tkamppeter: so is echogs.c compiled with -O3 or -O2?
<cjwatson> blackboxsw,smoser: you don't get a rejection if the key isn't registered in Launchpad
<cjwatson> I mean, not a rejection email
<tkamppeter> ginggs, this I have to see when the full log gets released and I succeed to catch it before someone else hits the retry button.
<blackboxsw> cjwatson: thanks that explains why I didn't see any email about it
<tkamppeter> ginggs, slangasek, ahasenack: The ghostscript build finished and I downloaded the log now. Compilation of base/echogs.c (the first compailation at all) uses BOTH -O2 and -O3, what is actually used then?
<tkamppeter> Example gcc command line:
<tkamppeter> gcc   -fPIC  -O2 -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE
<tkamppeter> _UNIX98=1  -g -O3 -fdebug-prefix-map=/<<BUILDDIR>>/ghostscript-9.23~dfsg+1=. -fstack-protector-strong -Wformat -Werror=format-security -DUSE_LIBPAPER -I/usr/include/powerpc64le-linux-gnu -fno-strict-aliasing -Wl,-Bsymbolic-functions -Wl,-z,relro -DHAVE_POPEN_PROTO=1 -DHAVE_POPEN_PROTO=1  -I./base -o ./soobj/aux/echogs ./base/echogs.c  -lm -ldl  -lidn -lpaper -ltiff -rdynamic -lfontconfig -lfreetype -lfreetype   -lz
<ahasenack> is that what is failing?
<slangasek> tkamppeter: later -O option wins
<cjwatson>  If you use multiple '-O' options, with or without level numbers, the
<cjwatson> last such option is the one that is effective.
<cjwatson> says info gcc
<ginggs> tkamppeter: i think the second one overrides the first
<tkamppeter> Thanks all, so it is actually -O3.
<tkamppeter> ahasenack, the shown gcc command line is not failing. It is the one which builds ./sobin/aux/echogs and what is failing is a call of ./sobin/aux/echogs.
<tkamppeter> ahasenack, ginggs, slangasek, the failing echogs line is
<tkamppeter> ./soobj/aux/echogs -e .dev -a-  ./soobj/xpswrite -include ./soobj/vector -includ
<tkamppeter> e ./soobj/libtiff
<tkamppeter> It is always this one, which simply hangs indefinitely and gets killed after one and a half hour by the build server.
<tkamppeter> There are tons of other echogs lines before which do not fail.
<ginggs> tkamppeter: so what happens if echogs is built with -O2 ?
<tkamppeter> ginggs, yes, this I could test via PPA. Need to find out now how to override the system-injected -O3 ...
<Laney> tkamppeter: export DEB_CFLAGS_MAINT_APPEND = -O2 in debian/rules probably does it
<tkamppeter> Laney, thanks.
<tsimonq2> Hah, I'm guessing the advice above can help with what I was just about to ask about...
<tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905868
<ubottu> Debian bug 905868 in gcc-8 "gcc-8: miscompiles vec_sl at -O3 with -fwrapv on ppc64el" [Normal,Open]
<tsimonq2> First time but probably not the last I'm going to have to set that flag...
#ubuntu-devel 2018-08-11
<Lord-Kamina> So... probably a dumb question, is it theoretically/technically possible to backport the linux package or is it essentially just the same as upgrading?
#ubuntu-devel 2018-08-12
<scientes> Lord-Kamina, generally you can just install it without rebuilding (building the linux kernel with all the modules takes a while)
<scientes> Lord-Kamina, and linux have very good binary compatibility, so yes
<scientes> oh, that was a long time ago
<Lord-Kamina> scientes, thanks anyway. In the end it didn't really work out beh eh.
<scientes> Lord-Kamina, why do you need a newer kernel?
<scientes> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<tomreyn> how would i report a bug against the 18.04(.1) release notes? It should mention that Xorg logs may now go to ~/.local/share/xorg/ and under which circumstancers they will (not). i think some other processes - gdm, lightdm, sddm (i think?), maybe this is only with UMS, or with KMS, please clarify - which used to log to /var/log may also log to the users' home now. this would be quite relevant for people migrating / upgrading from 16.04.
<tomreyn> x.org vs wayland may also matter for the log location, and if so, this should be discussed, too.
<rbasak> tomreyn: https://launchpad.net/ubuntu-release-notes -> Report a bug
<rbasak> tomreyn: though you might need to raise it with the desktop team to get it agreed/actioned
<rbasak> tomreyn: but by all means file the bug, since that will give everyone a coordination point. Then ask #ubuntu-desktop and/or the ubuntu-desktop mailing list.
<rbasak> (Since we can't put _every_ change in the release notes, we should probably defer to the desktop team to decide what should go in from the desktop side)
<tomreyn> rbasak: how would i "raise it with the desktop team (to get it agreed/actioned)"?
<tomreyn> oh, you said so
<tomreyn> thanks#
<tomreyn> this is bug 1786701
<ubottu> bug 1786701 in Release Notes for Ubuntu "Changed log locations for graphical services" [Undecided,New] https://launchpad.net/bugs/1786701
<Lord-Kamina> scientes, it was mostly a futile effort really... I had backported some packages from bionic over to trusty and in the process hit some Breaks and was trying to get them to work, but hit a wall when I realized one of the things I needed to port required a newer linux-libc-dev
#ubuntu-devel 2019-08-05
<amurray> bigon: (qa-regression-testing) QRT is a separate test framework, generally used by the Ubuntu Security Team - https://code.launchpad.net/~ubuntu-security/qa-regression-testing/+git/qa-regression-testing - I'm not familiar with the dep8 + QRT intersection but I am guessing it is so dep8 tests can reuse the QRT tests
<bigon> amurray: thx
<maks_piechota> Hi, I'm new in Ubuntu Development. I've found a little bug reported in subiquity that is actually a string modification. My question is if it is installer - how should I build it and test? Shall I modify somehow installer on live CD? Maybe you have some sites with instructions for that to recommend? I would appreciate your help.
<rbasak> maks_piechota: mwhudson might be able to help you, but he's in UTC+12 so you may have to wait a while.
<dreamcat4> having an issue whilst testing my debian package, --force-confold is not being respected
<dreamcat4> $ sudo DEBIAN_FRONTEND=noninteractive dpkg --force-confold -i teleport_4.0.0-rc.4-42-5_amd64_41633__expires-14.49pm-mon-05-aug-2019.deb
<dreamcat4> "Installing new version of config file /etc/teleport.yaml ..."
<dreamcat4> but the whole point of specifying the "--force-confold" flag is so that it doesn't do that !!!!
<sahid> jamespage, LocutusOfBorg o/ - I updated sphinxcontrib-pecanwsme to 0.10.0 that is required by the ironic project
<sahid> https://salsa.debian.org/sahid-guest/sphinxcontrib-pecanwsme/tree/debian/unstable
<sahid> if one of you can have a look whn a moment
<sahid> coreycb: ^
<rbasak> dreamcat4: is /etc/teleport.yaml a conffile or is the package using ucf?
<LocutusOfBorg> sahid, do you want it on Debian, right?
<LocutusOfBorg> you can ask zigo, send him a merge request directly on salsa.d.o
<LocutusOfBorg> he is on OFTC/#debian-devel
<sahid> LocutusOfBorg: yes then we could just copy the packages in ubuntu i guess
<sahid> ok thanks i will do that
<LocutusOfBorg> that will be the best and easiest solution
<dreamcat4> rbasak: its specified to be a conf file, i checked here:
<dreamcat4> https://www.irccloud.com/pastebin/n1Ml8oUY/
<dreamcat4> created the package with fpm, its not using ucf
<rbasak> Oh
<rbasak> You're not developing Ubuntu itself then?
<dreamcat4> trying to find a -Dxxxx debug level to get some detailed trace of what is happening. but it's not clear which -D flag i should specify. they dont seem to add anything more relevant to the log output
<rbasak> This channel is for development of Ubuntu itself.
<rbasak> We don't do fpm here.
<dreamcat4> so where do i go for my issue ?
<rbasak> I'm not sure.
<rbasak> We understand it's really painful for third parties to make packages outside the distribution that integrate properly. That's why we made snaps.
<rbasak> Maybe look for fpm community support?
<rbasak> That's a community that does exactly what you're doing, right?
<rbasak> There's also #ubuntu-packaging, for making packages _for_ Ubuntu.
<dreamcat4> ok thanks
<dreamcat4> maybe i should also check the control file too
<dreamcat4> but it's kindda beyond me why this isn't some bug in dpkg
<dreamcat4> according to its man page anyhow
<rbasak> I'm pretty sure that we'd have noticed a bug like that in dpkg by now.]
<dreamcat4> yeah
<rbasak> But if you really think there is one, please file it with full steps to reproduce.
<rbasak> Without using fpm or other unsupported stuff.
<dreamcat4> ok then. thanks for your help here today
<dreamcat4> bye then
<dreamcat4> turned out everything was fine. dpkg just was not logging / saying the decision was when it detected the previous version of the config file had not been edited from the default the old config file
<dreamcat4> i guess i can file a bug / enhancement for that
<cjwatson> dreamcat4: I don't think it would be a bug, since it's (IMO) clearly documented to behave that way.  Maybe could have clearer logging.
<cjwatson> (I mean, not a bug in the sense of "incorrect behaviour", though maybe an entry in the bug database.)(
<dreamcat4> yeah that's what i meant cjwatson - have now filed a request in debian bug tracker for "clearer logging" as you put it
<dreamcat4> enhancement / whatever. they can ignore it if they want to
<cjwatson> Sounds reasonable
<infinity> tjaalton: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel-hwe-18.04/+bug/1838698
<ubottu> Launchpad bug 1838698 in xserver-xorg-video-intel-hwe-18.04 (Ubuntu) "Cannot boot ISO unless using nomodeset" [Undecided,New]
<tjaalton> infinity: 64bit works, not too worried.. fossfreedom, attach logs, at least dmesg
<fossfreedom> tjaalton: k ... will boot to live session with nomodeset and attach anything I can find ... unless there is a specific way to collect the most useful logs?
<tjaalton> uh
<tjaalton> sorry
<tjaalton> no use for logs with nomodeset
<tjaalton> and with nomodeset you get software emulation, meaning llvmpipe
<fossfreedom> Umm ... how do I collect logs during the middle of the boot sequence?
<tjaalton> you'd need to install it, then boot without nomodeset and collect logs from the bad boot afterwards
<fossfreedom> Ok will do. Will have to be tomorrow since I am travelling. Thx
<mwhudson> maks_piechota: hi
<mwhudson> maks_piechota: i have this terrible command line for testing changes, one sec
<mwhudson> git diff --no-ext-diff --exit-code && git diff --no-ext-diff --exit-code --cached  && sudo ls && git clean -ffdx && snapcraft snap && sudo ~/src/subiquity/scripts/inject-subiquity-snap.sh ~/isos/bionic-live-server-amd64.iso  ~/src/subiquity/subiquity*.snap ~/isos/custom.iso && kvm -m 1024 -boot d -cdrom ~/isos/custom.iso -hda ~/images/root.img
<mwhudson> ah this is mostly bundled up into ./scripts/test-this-branch.sh
<mwhudson> er what's the best way to test a change to ubiquity
<mwhudson> i guess i can build it in a ppa, run a live session, add the ppa, upgrade ubiquity from my ppa and then run it?
#ubuntu-devel 2019-08-06
<rbasak> mwhudson, waveform: https://github.com/snapcore/core/pull/96 might be relevant to your current problem
<mwhudson> rbasak: ah very likely
<rbasak> I thought it was fixed a long time ago though
<rbasak> Fundamentally though when bundling an environment (like snaps do, but same with any other bundling) and the app needs to also see the host system, things get confused as to where they are running things from
<rbasak> git-ubuntu shouldn't run anything in the host system, but it happens by accident sometimes. It is a bug if it happens but I don't know of a good way to test for it.
<rbasak> Perhaps an AppArmor profile should be used to prevent it actually.
<rbasak> That might be a feature request for classic snaps!
<rafaeldtinoco> morning o/
<juliank> RikMills: heya, are you looking into the kdeconnect autopkgtest failures on bionic?
<juliank> does it maybe need a rebuild against openssl 1.1.1?
<RikMills> juliank: no, as upstream KDE don't care
<RikMills> no, just a racy test AFAIK
<juliank> given that it is constantly failing, and worked fine before openssl 1.1.1...
<juliank> We gotta get this thing fixed
<juliank> or remove the test
<juliank> I don't care if KDE cares or not, this is super annoying
<juliank> It causes autopkgtest regressions for even dpkg
<RikMills> juliank: oh, 1.1.1 is recent?
<RikMills> could be it then
<juliank> RikMills: Jun 10
<juliank> RikMills: Last working test was Jun 3
<juliank> RikMills: Next test after that one was Jul 4
<RikMills> sounds likely cause then
<juliank> RikMills: I'm running a test and a rebuild+test now
<RikMills> juliank: thank you!
<LocutusOfBorg> smb, hello, permission to steal iproute2 merge?
<LocutusOfBorg> I'm trying to debug firewalld testsuite failures...
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10393698/+listing-archive-extra
<LocutusOfBorg> if you want to take it
<juliank> RikMills: Ah, so cosmic fails as well, but disco passes
<juliank> RikMills: and the rebuild also fails
<juliank> RikMills: But I see 1.3.5 has patches for that, probably they are in disco too, and just need backporting to bionic
<smb> LocutusOfBorg, for Eoan? Will you do it using the git ubuntu trees?
<juliank> So I guess the question is whether you'd just want 1.3.4 in bionic and get some actual bugfixes in
<juliank> ah, that's the disable the patch thing
<juliank> Although debian does have a fix the tests patch in there too
<juliank> how odd
<smb> LocutusOfBorg, usually I have to get things sponsored too (cpaelzer / ahasenack, would there be a problem taking a merge that ^ way)
<RikMills> juliank: yeah, that test has always been 'racy'
<juliank> ah I see
<RikMills> juliank: that debian patch fixed it on their CI, but not our infra for some reason
<RikMills> so I lost patience when even upstream went "so what"
<juliank> In any case, I'd kind of like to see this skipped rather than just ignoring autopkgtest regressions for that altogether or having to re-check that it's not a regression on every SRU that riggers it
<RikMills> skipping on bionic sounds reasonable
<juliank> It just seems a bit pointless to upload an SRU without user-visible changes :/
<RikMills> juliank: not sure I will have time this week to prepare a more 'meaningful' SRU
<RikMills> probably a job for after Eoan feature freeze for me
<juliank> RikMills: I guess that's OK, but we should get it done eventually for future SRUs :)
<RikMills> juliank: agreed. please remind me if I seem to forget!
<juliank> ack
<cpaelzer> smb: both ways (debdiff from ppa) or MP can be sponsored (obviously) but you (SMB) will loose the split commits for the next merge
<smb> LocutusOfBorg, in that case, if you preserve the individual commits and do a merge proposal, I would be ok with you doing it, otherwise I rather would do it myself
<LocutusOfBorg> smb, if you commit on git I'm happy to sponsor :)
<LocutusOfBorg> I dind't realize you don't have permissions to upload...
<smb> LocutusOfBorg, Something I'd like to fix at some point, and I'll try to somehow squeeze this in. But cannot promise it to be quick.
<LocutusOfBorg> I mean, if you like the work I did, can you please just commit? otherwise I'll be happy to be pinged back if you want to take care
<LocutusOfBorg> or even, I can try to commit myself if I don't screw things
<LocutusOfBorg> not sure where the git repo is located
<smb> LocutusOfBorg, just commit from debdiff, no, because the point is to have per-delta item commits. The tree is launchpad and the simplest setup would be via git ubuntu, that is a (classic) snap only, though
<smb> LocutusOfBorg,  https://git.launchpad.net/~usd-import-team/ubuntu/+source/iproute2
<smb> LocutusOfBorg, the workflow I try to follow is to push that to a personal git repo on lp and create a merge proposal from that
<LocutusOfBorg> ok so I leave it...
<LocutusOfBorg> the risk of messing up is huge :)
<rbasak> ?
<rbasak> git diff whats_in_ubuntu your_merge_proposal
<rbasak> If you can review a debdiff, you can review that.
<rbasak> The cost of messing up therefore cannot be any higher.
<rbasak> (separately, almost everyone using the git ubuntu package merge workflow has found mistakes that other uploaders have been carrying forward for years using merge-o-matic)
<tomreyn> thanks for your post on the file-roller bug, seb128!
<seb128> tomreyn, yw!
<smb> rbasak, I guess the hurdle might be git in general if one only did deb based merges before. Most people are really scared of git. Maybe it helps to point out that this way one fetches but has no ability to mess anything up directly beyond ones own copy. And the personal tree also is completely seperate. And until the merge proposal gets accepted no harm is done
<rbasak> Yes, it certainly seems very complicated to start with.
<rbasak> My argument is that Ubuntu package merges are inherently complicated. git-ubuntu's merge workflow makes this clear up front. Or you can blunder through using merge-o-matic without realising.
<rbasak> (which is fine for trivial package merges)
<smb> rbasak, Yep, just mentioned it as I suspected that scared LocutusOfBorg. But might be good for me if I am forced to get that next merge done in the end. So maybe one day I can upload it, too. :)
<LocutusOfBorg> rbasak, smb my merges are done this way: grab-merge (DoM), look at *ubuntu*patch, see what is missing, see if it applies again and needed, update, dpkg-buildpackage -S -d, debdiff of the result, compare with the previous diff from Debian, upload
<LocutusOfBorg> with git, should I import the debian version in some way?
<smb> LocutusOfBorg, that importer git tree already has the debian remotes, so one can rebase the ubuntu branch onto the next debian
<rbasak> LocutusOfBorg: you need to be checking that the entire Ubuntu delta is still applicable against the new Debian.
<LocutusOfBorg> rbasak, I do check that, yes
<rbasak> LocutusOfBorg: and, if any of the delta has disappeared (eg. if Debian adopted it), you need to be aware of it so you can adjust the documentation in debian/changelog accordingly.
<rbasak> OK :)
<LocutusOfBorg> rbasak, in case it disappears, doing meld between the new diff and the *ubuntu*patch will make them visible
<rbasak> Like smb says, the relevant bits you need are already all imported into the git-ubuntu trees.
<rbasak> Essentially all you need to do is git rebase the old ubuntu tip onto the new Debian tip.
<LocutusOfBorg> I do that for gstreamer packages, but I always have the feeling that I'm not doing stuff right
<rbasak> If you can do this with git directly yourself, you don't need the git-ubuntu tooling yourself.
<rbasak> The tooling just makes some common repetitive edge cases around that work easier, such as the handling debian/changelog correctly.
<smb> LocutusOfBorg, but again, if you do not dare to start doing things that way with iproute2, I can handle it. Just maybe not that quickly
<tkamppeter> LocutusOfBorg, hi
<tkamppeter> LocutusOfBorg, you know that the firewalld 0.7.x (on arm64 only) is blocking network-manager 1.18.0-1ubuntu6 to get out of -proposed in Eoan?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1839154
<ubottu> Launchpad bug 1839154 in linux (Ubuntu) "please backport upstream patch to kernel 5.2" [Critical,Confirmed]
<LocutusOfBorg> tkamppeter,
 * smb feels the matrix is resetting itself into a loop
<smb> sforshee, cascardo ^
<tkamppeter> LocutusOfBorg, thank you very much.
<LocutusOfBorg> tkamppeter, I can probably hack upload the firewalld workaround
<LocutusOfBorg> but this is a kernel bug.
<seb128> LocutusOfBorg, tkamppeter, you could probably ask for the test result to be skipped one time to have things migrating also as an option?
<LocutusOfBorg> seb128, I'm adding a modprobe in the test suite, to see if the test is good
<seb128> k
<seb128> bah, I never can figure out how to make git mps on launchpad work :/
<seb128> I'm trying to mp https://code.launchpad.net/~seb128/wslu/+git/wslu/+ref/ubuntu/master
<seb128> the default target is lp:wslu is that right for https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/wslu/+git/wslu ?
<seb128> and if so why is target branch ubuntu/master of ref/heads/ubuntu/master not working?
<seb128> I'm sure I screwed something again, either pushed to the wrong location or the target is wrong but I can't figure out what I should do differently :-/
<cjwatson> You need to push to lp:~seb128/ubuntu/+source/wslu, not to lp:~seb128/wslu/+git/wslu
<cjwatson> Your source repository is in a different namespace from the target so MPs are forbidden
<cjwatson> The "ubuntu/+source/wslu" bit is the namespace
<rbasak> seb128: I think you could use this bug fixed https://bugs.launchpad.net/launchpad/+bug/1813778 :)
<ubottu> Launchpad bug 1813778 in Launchpad itself ""Personal" push URLs not displayed on code pages" [Low,Triaged]
<cjwatson> If you know anyone good to point at the open job advert for a Launchpad developer (https://boards.greenhouse.io/canonical/jobs/1709248), that would be a great way to improve the likelihood of this being fixed :-)
<seb128> cjwatson, thx, I get confused by that every time :/
<seb128> rbasak, right
<niedbalski> bdmurray: hey :-), any chance for you to check the verified SRU on LP: #1835581? which is also holding LP: #1668771
<ubottu> Launchpad bug 1835581 in systemd (Ubuntu Eoan) "networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes" [Medium,Fix committed] https://launchpad.net/bugs/1835581
<ubottu> Launchpad bug 1668771 in systemd "[SRU] systemd-resolved negative caching for extended period of time" [Unknown,New] https://launchpad.net/bugs/1668771
<niedbalski> or RAOF ^^ if you are able to, please :-)
<bdmurray> niedbalski: By "check the verified SRU" do you mean you want me to look at releasing it from -proposed to -updates?
<niedbalski> bdmurray: that's right.
<niedbalski> bdmurray: thank you, i think you might have missed disco (which is also in -proposed and verified)
#ubuntu-devel 2019-08-07
<sahid> jamespage, coreycb: about Train, head-dahsboard does not support python3-django > 2, in eoan we well have 1:1.11, but in eoan-proposed we have 2:2.2.4
<LocutusOfBorg> Unit193, hello, what is your feeling about a assaultcube sync?
<sahid> how are we going to handle that?
<Unit193> LocutusOfBorg: Hah!  I happened to voice that in -motu just earlier today. :P
<LocutusOfBorg> aaand? sync?
<LocutusOfBorg> we will loose some bits by syncing
<Unit193> LocutusOfBorg: tl;dr: No benefit now, Debian version is *weird* for a couple reasons.
<LocutusOfBorg> so, forward patches to Debian?
<Unit193> (For the longer description, perhaps check logs)
<LocutusOfBorg> mwhudson, hello, should golang-1.11-race-detector-runtime move to 1.12?
<EoflaOE> Hello, can someone explain to me what is this channel? For requesting updated versions or what?
<jamespage> sahid: does horizon support django >= 2 ?
<sahid> jamespage: yes it looks like since the build success
<jamespage> sahid: that might not be much of a guide - I don't think we run any testing for horizon during the build
<jamespage> sahid: indeed "Django<2.1,>=1.11;python_version>='3.0'  # BSD"
<mwhudson> LocutusOfBorg: yes, need to check which revision 1.12 was built with i guess
<mwhudson> LocutusOfBorg: oh, looks like the same revision as 1.11 so it's just upload with a new package name it seems
<LocutusOfBorg> mwhudson, shouldn't this one go in Debian?
<LocutusOfBorg> the freeze is now over :(
<LocutusOfBorg> :)
<mwhudson> LocutusOfBorg: yes but i never had the energy to go through the itp process
<mwhudson> LocutusOfBorg: if you do, go for it!
<LocutusOfBorg> mwhudson, what does it need? the packaging is already there, right?
<LocutusOfBorg> just open a bug and I can sponsor it
<LocutusOfBorg> lamont, hello, can you please do an inspircd merge? did you never upstreamed the patches? the new version is quite a lot different, and I don't know how to check if your patches are still needed or not...
<rbasak> sil2100: I like your block-proposed handling in pending-sru :)
<sil2100> rbasak: thanks, glad you like it! Although it was Brian's idea to use the blockade emoji ;)
<rbasak> bionic-security has distro-info-data 0.37ubuntu0.5 that Breaks: distro-info (<< 0.18ubuntu0.18.04.1~).
<rbasak> distro-info >> 0.18ubuntu0.18.04.1~ only exists in bionic-updates.
<rbasak> Therefore, distro-info in bionic-security has become uninstallable on bionic-security only systems.
<rbasak> infinity: you TIL ^
<rbasak> Wanna bug?
<rbasak> Looks like the Breaks was introduced in 0.37ubuntu0.3
<infinity> Oh fun.
<infinity> rbasak: Lemme just sanity check the distro-info build and copy it to security if it's clean.
<rbasak> Looks like it's been like that for a while. Does the lack of report mean that nobody actually does security-only installs any more?
<infinity> I've asked that question every time something like this comes up three months after we break it. :P
<infinity> https://launchpad.net/ubuntu/+source/distro-info/0.18ubuntu0.18.04.1/+publishinghistory
<infinity> rbasak: ^-- It'll fix itself shortly.
<rbasak> Thank you!
<infinity> rbasak: Anyhow, I think I've expressed in the past that I feel the updates/security thing is a mess, and if we could come up with a clever way to tag updates as security-or-not, we should collapse them to one pocket and be done with it.
<rbasak> Some kind of metadata that an apt pin can pick up perhaps
<infinity> Which sounds simple on the surface ("Just add it to the control data!"), until you realise a user could be two revisions out of date, and the current one in Packages.gz *isn't* tagged security, but the previous was.
<rbasak> Good point :)
<rbasak> It'd have to be control metadata with a version string stating when it was last updated for security
<infinity> So, indeed, another set of stream data that's just package:version pairs of every security update ever, and we fuzzy match between installed and available, or some such.
<infinity> Or maybe what you say.
<rbasak> Have fun implementing that in Launchpad :)
<infinity> Anyhow, if anyone felt like coming up with an elegant solution to that for LP->apt->unattended-upgrades/update-manager, I'd love to ditch the split pockets that aren't really split anyway.
<rbasak> (or, actually, maybe just in the source package, and Launchpad then wouldn't need to care?)
<infinity> If security was actually forked from release, that would be one thing, but we always FFWD against updates anyway to save the pain and horror of maintaining forks.
<infinity> And yeah, LP doesn't necessarily need to know anything here.  It could well be implemented at the package level.
<infinity> It's an extra step for the security team to get right, though.
<rbasak> What does Debian do on the fast forwarding point?
<rbasak> The security team would merely need to flag every upload they do as a security update. Tooling could do that.
<infinity> Whereas something more automated that tags things coming into a specific queue would get it more right more often, maybe.
<infinity> Debian doesn't FFWD until point releases, where they FFWD literally the whole archive.
<infinity> As in, stable is replaced with the merge of stable+stable-proposed-updates+stable-security.
<infinity> Then a new empty spu and ss begin.
<rbasak> So before a point release, they maintain two forks of each package - spu + security?
<infinity> Yep.
<infinity> But there's not much software in spu, compared to what we ship in updates.
<infinity> So it's not that onerous.
<rbasak> Yep
<rbasak> rafaeldtinoco: in https://salsa.debian.org/debian/dbconfig-common/merge_requests/4, did you miss my comment about the changelog?
<cjwatson> If you're trying to tag updates as security or not, Launchpad would probably have to care because it would have to keep more than one version live in a single pocket.
<infinity> At any rate, I think it's a cross-team discussion worth (re)having.  Maybe even having it in earnest well before 20.04, in case we decide to stop the insanity.
<infinity> cjwatson: Why?
<infinity> cjwatson: My take is "if a version between your installed one and the available one was a security update, you get the new one, HTH, HAND."
<rbasak> cjwatson: I had assumed that the only option available to a user after having missed the security upload in the archive would be to update to an even newer SRU
<rbasak> Yeah what infinity said
<cjwatson> Oh, I see.  Maybe
<infinity> People who want to install current-1 to obtusely get only the security update aren't people we really want to cater to.
<rbasak> Because security already fast forwards so users get arbitrary SRUs
<cjwatson> That "version between" bit skates over tricky implementation though
<rbasak> The only current benefit to following only security updates is less regression-risk disruption
<rbasak> In terms of numbers of updates
<rbasak> And we'd be maintaining that
<infinity> cjwatson: I mean, it's a simple dpkg version compare on the client side.
<cjwatson> Depends on how the tagging is
<cjwatson> done
<infinity> Wouldn't get a rollback right, but we shouldn't ever be counting backwards.
<cjwatson> If client has 2, 3 was tagged security, 4 wasn't tagged security and is current, the client needs some way to know about the tag on 3
<rbasak> Hypothetically, a "Last-Security-Update: <version string>" in the binary control file is what I was thinking.
<rbasak> Though perhaps that's not generic enough for apt
<infinity> Robie's suggestion of "Last-Security-Update: ${version}" in binary control would DTRT.
<cjwatson> Sounds fiddly to maintain
<infinity> Jinx.
<cjwatson> And easy to get wrong
<rbasak> I don't think it'd be that fiddly.
<cjwatson> I do :)
<infinity> I think it's totally fiddly if it's up to the uploader to get right.
<rbasak> Mostly it's just security bumping it, and nobody else bumping it.
<infinity> If it could be injected via security coming in from another queue, or having a more generic tag on it, that's less fiddly.
<rbasak> Tooling can do that.
<rbasak> Not sure about release upgrades though.
<cjwatson> I think we should try to do better than something that requires uploader-side tooling
<rbasak> Maybe it can be completely ignored for those, since apt is upgrading everything anyway.
<infinity> rbasak: It's ignored in those situations today, so...
<rbasak> Get security to continue uploading to the securit pocket.
<cjwatson> We have plenty of stuff that does already, but that's not a reason not to put thought into doing better when designing a new thing
<rbasak> And have automation in the upload processing check that it was bumped.
<infinity> The only reason to "know" about security updates right now is (a) people who pick "sec only" in unattended-upgrades, and (b) so update-manager can highlight "important updates".
<infinity> Neither of those apply to full dist upgrades.
<rbasak> cjwatson: I don't really see this as a hack. The source package seems like the appropriate canonical source of this information to me.
<rbasak> It's already effectively done in debian/changelog
<rbasak> We'd just be making it machine readable.
<infinity> Any time you carry a version in more than one place in a source package, the odds of getting it wrong are high.
<cjwatson> Your proposal is totally a hack compared to having something automatically scan it and work it out centrally
<infinity> Without explicit tooling and very disciplined uploaders.
<cjwatson> And I don't quite understand why you're pushing it :)
<rbasak> It's only a weak suggestion :)
<infinity> I'd definitely prefer *either* security tagged in changelog (ie: urgency=security), or a queue/target to upload to, but either way, LP would then figure it out.
<cjwatson> (Not that I'm immediately volunteering; this feels like quite an early stage of discussion ...)
<rbasak> Working it out centrally seems like a hack to me, because the actual source of the information must come from the uploader in the first place.
<infinity> I actually prefer just setting a new imaginary urgency, I think.
<rbasak> Oh
<infinity> Or declaring that one of the existing ones is now the security team's, so we don't break existing parsers.
<rbasak> If the canonical location of the information is in debian/changelog, then sure.
<cjwatson> It's better for the source of information to be "this thing that I'm uploading right now is a security upload" rather than "the last version that was a security upload was <foo>"
<rbasak> That fits.
<cjwatson> is what I'm trying to say
<infinity> cjwatson: Fully agreed.
<rbasak> Then the control field could be automatically generated from debian/changelog
<rbasak> Either by Launchpad or at package build time.
<cjwatson> FWIW the changelog format does already permit multiple tags as well as urgency
<cjwatson> Whether existing parsers handle it I don't exactly know, but if they don't they're buggy per policy :)
<rbasak> https://tracker.debian.org/news/1041443/accepted-mysql-57-5726-1-source-into-unstable/
<rbasak>  mysql-5.7 (5.7.26-1) unstable; urgency=high (security fixes)
<rbasak> That works fine FWIW
<cjwatson> now I think that isn't pedantically correct even though it might work
<rbasak> IIRC it's documented and specified somewhere
<cjwatson> AFAICS the spec says "multiple keyword=value pairs separated by commas"
<rbasak> IIRC it's a separate free form comment field
<cjwatson> https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
<coreycb> jamespage: sahid: i just checked with amotoki and django 2.2 support is planned upstream for the openstack "U" release (ubuntu 20.04 cycle)
<cjwatson> Ah, there's https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-urgency
<cjwatson> Dunno whether that's better.  As a matter of principle I'd prefer using a new tag over imposing new mechanical interpretation on a free-form field
<coreycb> jamespage: sahid: so not quite sure how to move forward on this one for eoan
<infinity> Ahh, so urgency=high (security) would get the job done.
<cjwatson> Unless it's already very widespread practice
<cjwatson> e.g. urgency=high, security=yes
<cjwatson> feels better
<coreycb> beisner: fyi django ^
<infinity> I'd be fine with inventing urgency=security (but ick, might break tools) or just deciding that "emergency" or "critical" now mean something.
<rbasak> cjwatson: over imposing new mechanical interpretation> agreed
<rbasak> I was just pointing out that this is a form that might be useful and doesn't currently break anything
<cjwatson> I'd prefer not overloading urgency
<cjwatson> Yep
<rbasak> How about Last-Critical-Urgency: <date>?
<rbasak> Would you consider that overloading?
<infinity> I don't like gratuitously breaking format like your example just did. :)
<cjwatson> infinity: how does my example gratuitously break format?
<cjwatson> it matches the spec
<infinity> But also, I'm wondering if urgency=[current-values] might be what we really want anyway.
<cjwatson> I mean, for once we have a format that already supports multiple key/value pairs, and then we try to ram everything into one key?
<cjwatson> doesn't seem right
<infinity> That is, maybe what "security only" people really want is "only urgent SRUs".
<infinity> urgency=critical because it corrupts data is just as important as urgency=critical because it's remote root.
<infinity> cjwatson: I don't see it matching the spec?  Maybe I'm reading a different part of policy.
<sahid> coreycb: hum yeah, several -dashboard packages are in cause
<rbasak> infinity: that's sort of what I mean, yes.
<infinity> cjwatson: I mean, okay, it's alluded to as maybe being okay "commas are used to separate..."
<infinity> cjwatson: But the bit in parens pretty much immediately invalidates that.
<rbasak> We get to define what urgency means exactly for our stable releases
<coreycb> sahid: yes something we're very unlikely to be taking on ourselves
<rbasak> And it isn't overloading the field for us (Ubuntu) to have a policy on that.
<rbasak> And then users can follow that policy if we publish the "Last-" in a control field.
<rbasak> Assuming that urgency has an understood ordering.
<coreycb> sahid: fwiw nobody will likely deploy horizon on eoan but of course we still want a solution here
<cjwatson> infinity: the bit in parens is part of the urgency key's value
<cjwatson> infinity: so urgency=foo (bar), some-other-tag=some-value is valid
<infinity> cjwatson: I meant the parens at the end of the sentence I was quoting.
<cjwatson> infinity: that's just a matter of the keys that are currently defined; it doesn't preclude defining new ones
<infinity> cjwatson: Given that there's only ever been one key=pair value of any note, the odds that tools are robust enough to assume more would be naive.
<infinity> key=value pair, even.
<cjwatson> there aren't that many such relevant tools; easy enough to check
 * infinity shrugs.
<rbasak> We'd notice at build time
<infinity> I still maintain that this is an opportunity to revisit what we (and users) really mean with "security-only".
<rbasak> We could start doing it well in advance of any implementation
<cjwatson> In fact there used to be closes=
<cjwatson> many many years ago
<infinity> Because, for my money, what I mean is "I want high urgency stuff NOW, and I can wait on other stuff until I've read the changelogs."
<rbasak> git-ubuntu has had fun with parsing old changelog formats
<infinity> Not strictly security.
<infinity> But security-only is the only approximation we have of "high urgency" today.
<infinity> Note that MS has a similar urgency setting hidden in their updates.
<rbasak> With urgency in heavy use in Debian's testing migration, I wonder if there's any potential for future conflict with that
<cjwatson> If what we actually want is semantically urgency, then I don't mind overloading that
<infinity> Which gives you everything from "won't touch it until a user clicks a button" to "will install in the background when the machine isn't busy" to "will install now, but maybe not take hold until reboot" and ultimately "will install NOW and reboot NOW, and also fuck you slightly, but this is important."
<rbasak> There's nice separation in that this would only be for our stable releases
<infinity> They've backed off a lot on using the last one, thankfully.
<rbasak> But what if Debian start wanting to do something with their stable releases and also use the urgency field?
<infinity> rbasak: What if?
<cjwatson> dpkg-parsechangelog parses "urgency=medium, security=yes" fine, although it issues a couple of warnings because it doesn't know about that particular field name
<cjwatson> FWIW
<infinity> Yeah, I didn't assume dpkg would have any issues.
<rbasak> infinity: it might result in tooling changes that affect our use of the field, perhaps?
<infinity> I'm willing to bet there are people out there that have their own changelog reading madness, though.
<infinity> To do crazy things like feed into RT for sysadmins to look at incoming updates, and who knows what other crazy.
<infinity> rbasak: I kinda doubt it?
<infinity> rbasak: urgency has always had more meaning in Debian than in Ubuntu.  If we started using it, we'd be aligning, not diverging.
<infinity> rbasak: Assuming we did so with a bit of thought behind it.
<infinity> Anyhow, I think this is a good start for a baseline cross-team discussion for another time.
<infinity> I definitely think the changelog would be the right place for this magical data to live and be extracted from.
<infinity> We also didn't posit the idea of free-forming another bug syntax, which would skip some of the potential "we might break tools" issues.
<infinity> LP-SEC: #123455
<infinity> Or whatever.
<rbasak> own weird changelog reading madness> oh you mean like this: https://git.launchpad.net/usd-importer/tree/gitubuntu/git_repository.py#n434
<infinity> Has the downside of requiring a bug for every security upload, but honestly, we probably should have anyway.
<cjwatson> I think the only good reason for bugs to be annotated the way they are is to allow them to go alongside the prose description of their fix.  It wouldn't make sense for something that's essentially a flag on the version.
<infinity> Probaby true, was just giving a less invasive (from a formatting POV) option.
<cjwatson> (There's a non-trivial amount of hairy stuff associated with bug closures in LP.)
<infinity> Anyhow, I think the base level discussion (should we collapse pockets, and why, and what would be the end goal of flagging versions (security, or urgency, or some combination of both)) needs to happen before we bikeshed anymore about how to flag versions. :)
<cjwatson> Yeah, agreed
<cjwatson> End goal before anything else :)
<santa_> ddstreet, rbalint: good evening, systemd >= 242 fixed my autopkgtest hangs, thank you. but I found yesterday a new issue with latest 243 from -proposed:
<santa_> udisks2 fails to install in a LXD container because the postinst script fails
<santa_> udisks2 postinst executes "udevadm trigger --subsystem-match=block --action=change", and this command fails like this (inside an LXD container):
<santa_> m
<santa_> https://paste.ubuntu.com/p/5shmRgGRy3/
<santa_> udisks2 installation inside an LXD container (with -proposed enabled):
<santa_> https://paste.ubuntu.com/p/jTmJNpVwkY/
<santa_> ... and last but not least, syncing udisks2 from debian wouldn't solve the problem
<santa_> (I've just tested that with this package here: https://launchpad.net/~panfaust/+archive/ubuntu/kde-test-good)
<rbalint> santa_, there are other issues with 243, hopefully we can resolve those as well soonish
<mwhudson> good morning #ubuntu-devel
<connor_k> o/
<genii> Hi, just wondering if someone could clarify what video mode is being set in OEM install mode which may differ from regular install video mode. In regular install for instance, I can see the entire window but in OEM mode the bottom is cropped off ( on a netbook screen which is 1024x600 it seems like the windows are a non-resizable fixed at maybe 1024x768)
<santa_> rbalint: ack, thanks
#ubuntu-devel 2019-08-08
<cpaelzer> jamespage: coreycb: I don't see qemu 4.0 / libvirt 5.4 in train-staging - intentional?
<cpaelzer> as usuall people would be happy to mis-use UCA for newer versions of that :-)
<cpaelzer> and you'd get some more months base distro and security support from Eoan compared to Disco
<smb> cpaelzer, LocutusOfBorg, I managed to make some time and do an iproute2 merge preserving the individual commits. I am about to submit a MP, who would be best put in as reviewer?
<cpaelzer> smb: I'm fine taking a review
<smb> cpaelzer, ok, thanks... submitting (hopefully remembering things right)
<cpaelzer> this package in the past always merged rather straight forward, we will find odd elements ratehr quick I guess
<smb> Usually it was details like the wrong target but I think I remembered that right
<LocutusOfBorg> smb, do you care to update VCS fields?
<LocutusOfBorg> btw the delta can be easily upstreamed to debian
<smb> LocutusOfBorg, probably should care but forgot to. Not in that form I think. As it is for something only ubuntu has, so would need to be done in a way which makes it invisible on a debian build
<LocutusOfBorg> seems legit then :)
<LocutusOfBorg> smb,
<LocutusOfBorg> ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes)) patch -p1 < foobar
<LocutusOfBorg> something like that
<smb> LocutusOfBorg, maybe. I am still a bit torn between that approach and just keeping them as delta. occasionally things need a refresh which both ways. and it really is a delta. In iproute and the kernel.
<smb> which will be required ...
<smb> LocutusOfBorg, I think cpaelzer had been talking to me about this, too. Just that "life" usually does not leave enough time to think about it
<coreycb> cpaelzer: thanks for the ping. they just need some TLC to fix up backport failures. i will hopefully get to that today or tomorrow. jamespage: side note, for some reason i'm not getting emails about failing train backports the last few days.
<jamespage> coreycb: hmm
<cpaelzer> thanks coreycb, good to know
<rbalint> santa_, i'm preparing next systemd upload in ppa:rbalint/scratch, that should work ok with lxd
<santa_> rbalint: thanks, it seems is still fails here even after rebooting the container
<santa_> same error message for "udevadm trigger --subsystem-match=block --action=change"
<rbalint> :-\ i keep looking at it then
<santa_> FYI the LXD I'm using to test is 3.0.3 from *.deb packages @ bionic
<santa_> https://github.com/systemd/systemd/blob/master/NEWS
<santa_> "Downstream production distributions might want to"
<santa_>           continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
<santa_>           their builds as unfortunately the popular container managers have not
<santa_>           caught up with the kernel API changes.s
<rbalint> santa_, yes, i changed that
<santa_> so what about "legacy"?
<rbalint> santa_, i think reverting to the previous default should be enough and this is probably a different issue
<santa_> aha
<santa_> one of these days I should try to learn a bit about systemd & co.
<santa_> right now most of these things sound like chinese to me
<tjaalton> ahasenack: hi, do you know what's the holdup for python3-samba on debian?
<ahasenack> tjaalton: hm, not really, I assume it's just lack of time
<tjaalton> ok
<tjaalton> ahasenack: was there a merge request for it?
<ahasenack> not that I know of
<tjaalton> ok, that'd explain it then :)
<tjaalton> oh, it's not just that but talloc, ldb too :/
<tjaalton> talloc is in experimental
<Unit193> bryce: Thanks for all your help with the ruby2.5/openssl issue!
<bryce> Unit193, certainly!  happy to see it get resolved
<bryce> Unit193, thanks for quick responses on testing and such, it helped a lot
<Unit193> Came out with a better solution than just removing the patch too, which is nice. \o/
<bryce> having the test case really helped in isolating the faulty line
<Unit193> Eh, crappy testcase, but it works I guess.
<mwhudson> er what do i have to do after a mkfs to get /dev/disk/by-label to appear?
<mwhudson> (in the initramfs so that might matter)
<vorlon> udevadm trigger?
<mwhudson> vorlon: yes, and not udevadm triger, it turns out
<sarnold> mwhudson: how so?
<Unit193> I dunno, but I can't get playing with ISOs in Eoan to work either, I always get dropped in the initramfs. :/
#ubuntu-devel 2019-08-09
<chiluk> pulseaudio is not building on eoan
<chiluk> 33%: Checks: 3, Failures: 2, Errors: 0
<chiluk> tests/cpu-volume-test.c:81:F:svolume:svolume_mmx_test:0: Failed
<chiluk> tests/cpu-volume-test.c:81:F:svolume:svolume_sse_test:0: Failed
<chiluk> FAIL cpu-volume-test (exit status: 1)
<chiluk> Also I miss you folks...  This is what I've been busy with lately... https://lkml.org/lkml/2019/7/23/673
<RikMills> oSoMoN: hi. does the libreoffice smoketest fail here against kconfig look an issue to you, or just a random glitch? http://autopkgtest.ubuntu.com/packages/libr/libreoffice/eoan/armhf
<RikMills> I am retrying, but will a long while to get result of that
<oSoMoN> RikMills, that's a question for marcustomlinson ^
<seb128> RikMills, marcustomlinson is the new libreoffice maintainer
<seb128> lol, sorry oSoMoN :)
<RikMills> oh, sorry. I must have missed that change!
<marcustomlinson> RikMills: hey, looks random to me. At least, I haven't seen that before
<RikMills> marcustomlinson: ok. thanks. I won't spend any more time looking then, and just see what result of the test retry is
<seb128> marcustomlinson, speaking about libreoffice, do you have an eoan upload coming? I want to update poppler before ff, as usual that inludes a soname change and require to rebuild (and often adjust) rdepends including libreoffice
<marcustomlinson> seb128: yes 6.3.0 needs to be uploaded soon. I'm running autopkgtests now on the build in my ppa, if all is well I should have it in today. but... that may be hopeful
<seb128> marcustomlinson, I will probably try to do that transition next week, I will put poppler first in a ppa and kick a no change rebuild there to see if libreoffice needs changes but I just wanted to give you some forward notice
<seb128> marcustomlinson, k, feels like we should get 6.3 in before, which is better
<seb128> it means I'm not public the update and it gives a newer version to test which has more chance to work with the current poppler :)
<marcustomlinson> seb128: yeah I aim to have it uploaded soon soon. Worst case Mon/Tues
<seb128> marcustomlinson, k, good, well let's talk again next week then, hopefully by then 6.3 is in eoan and I've test build results
<ricotz> marcustomlinson, hi, could push your current ubuntu-eoan-6.3 branch, so I can take a look?
<ricotz> *could you
<marcustomlinson> ricotz: WIP at the moment
<marcustomlinson> ricotz: will push sometime today, I'll ping you, sorry
<ricotz> marcustomlinson, I know the current one look like WIP already, you can force-push it later
<ricotz> marcustomlinson, e.g. the nss tarball can be filtered out
<marcustomlinson> ricotz: ok I've pushed. You'll see I'm pretty aggressively trying to reduce diff between Debian and Ubuntu
<marcustomlinson> ricotz: it builds as is, but I got a few weird autopkgtest failures on armhf I'm still looking at
<ricotz> marcustomlinson, oh dear
<ricotz> marcustomlinson, this is aggressive indeed, at least merge the revert and apply to preserve the history for those changes
<ricotz> marcustomlinson, did you confirm with infra that all builders provide the required diskspace? e.g. like 50G
<marcustomlinson> ricotz: as I said it is building
<marcustomlinson> https://launchpad.net/~marcustomlinson/+archive/ubuntu/libreoffice/+packages
<ricotz> ok, but this is not what I asked
<ricotz> the split was made to deal with launchpad's deficiencies
<marcustomlinson> yeah legacy deficiencies
<cjwatson> All builders have 60G of disk
<ricotz> marcustomlinson, please squash revert and reapply
<ricotz> cjwatson, this sounds sufficient at this point
<marcustomlinson> ok
<ricotz> marcustomlinson, could you rebase on libreoffice_6.3.0-1 tag
<ricotz> I mean "merge"
<ricotz> sorry, need to go and will be back in a few hours
<rbasak> src:magnus isn't autosyncing
<rbasak> No mention in the log and it's not blacklisted
<rbasak> However it previously existed in Debian with a higher version string
<rbasak> Launchpad has it in publishing history with that. This might explain it.
<rbasak> Is a manual sync acceptable, or would that fail due to the version?
<rbasak> Is it correct in Debian for the version to have gone backwards, or should it have an epoch bump in Debian?
<juliank> rbasak: I'd say it's OK to not have an epoch because it was not part of a stable release anymore, so no upgrades broke
<juliank> but I mean you can always ask for an epoch
<juliank> rbasak: FWIW, syncpackage does not do anything
<juliank> wonder if uploading the dsc does
<juliank> Ah no the sync went through
<coreycb> rbasak: do you know if backportpackage is broken with openstack-dev-tools 0.170? i could very possibly be mis-using it but the new signature checking is failing to  verify signatures on .dsc files.
<rbasak> I don't know about that, sorry
<coreycb> rbasak: ok i'll check with mattia
<tarzeau> after the featurefreeze (22nd august) how hard is it to continue importing leaf packages? or is that the last date?
<rbasak> tarzeau: feature change uploads require an exception from the release team
<rbasak> tarzeau: https://wiki.ubuntu.com/FeatureFreeze
<rbasak> tarzeau: and https://wiki.ubuntu.com/FreezeExceptionProcess
<tarzeau> rbasak: ok thanks
<rbasak> bryce has the PHP transition ready
<rbasak> The MySQL 8.0 transition is still in progress.
<rbasak> Any implications for entangling them intentionally, apart from that we'll need both PHP related and MySQL related FTBFS fixed before both can migrate?
<rbasak> Since feature freeze is coming up, delaying PHP doesn't seem like a great idea.
<rbasak> bryce already has all FTBFS resolved in a trial PPA
<rbasak> And most (but not all) FTBFS are resolved in a trial MySQL 8 transition PPA too.
<bryce> https://launchpad.net/~bryce/+archive/ubuntu/php7.3-transition.4/+packages
<rbasak> vorlon: ^ advice please? Can you see any issues with going for both transitions at once?
<Locutusofborg> rbasak, I have one
<Locutusofborg> mythtv is entangling libvpx and mysql-8.0
<Locutusofborg> if anybody can kick it out to proposed for some days... we can at least have libvpx migrate
<rbasak> Locutusofborg: kick what out to proposed
<rbasak> ?
<Locutusofborg> mythtv
<Locutusofborg> so they are not entangled anymore
<Locutusofborg> vpx and mysql
<Locutusofborg> fixing xpra will make vpx migrate
<rbasak> I'm not sure I follow
<rbasak> But anyway, I'm fine with it as long as we don't hold up progress on MySQL or PHP :)
<Locutusofborg> vorlon, please please please kick deal.ii out from arm64
<Locutusofborg> so we can make slepc/petsc/hypre/ufl/sundials/mshr/ffc/fenix/dolfin/dijitso transition migrate
<Locutusofborg> it fails, I tried old gcc, still fails
<Locutusofborg> will be fixed in Debian by ginggs eventually, in debian fails on ppc64el
<vorlon> rbasak: the risk of letting mysql and php transitions get entangled is random other uploads of leaf packages resetting the transition; the risk of this is higher the more such leaf packages there are.  I think you will find it better to finish the mysql transition first
<vorlon> Locutusofborg: so deal.ii is broken on arm64 in Ubuntu but not in Debian?
<ginggs> vorlon: yes, deal.ii FTBFS on arm64 with gcc9, builds in debian where gcc8 is still default
<coreycb> vorlon: is there any chance we can stick with python3-django 1:1.11.22-1 and sync 2:2.2.4-1 next cycle? upstream openstack doesn't plan to add any django 2.2 support until next cycle.
<vorlon> ginggs: so has anyone tried building deal.ii with gcc-8 in Ubuntu to work around this?
<vorlon> coreycb: django 2:2.2.4-1 is currently stalled in eoan-proposed and will stay there until all the packages which depend on it are happy with the new version, so I think you're fine
<vorlon> coreycb: also, at present there's a pile of unresolved autopkgtest regressions for the reverse-dependencies
<coreycb> vorlon: ok thanks
<ginggs> vorlon: Locutusofborg is trying here https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10402252/+listing-archive-extra
<Locutusofborg> vorlon, I failed...
<Locutusofborg> lets see if gfortran is to blame
#ubuntu-devel 2019-08-11
<mwhudson> how do you edit a patch with git-dpm?
<mwhudson> oh rebase
<anon^_^> hi, had a question about a really nasty upstream bug
<anon^_^> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898085#36
<ubottu> Debian bug 898085 in dirmngr "gnupg: gpg --search-keys and parcimonie don't work: Tor misconfigured/keyserver EPERM" [Important,Fixed]
<anon^_^> if tor is installed in 18.04, it breaks gpg add key functions
<anon^_^> not documented very well at all
<rbasak> !ask | anon^_^
<ubottu> anon^_^: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<anon^_^> dirmngr by default passes all key lookups through tor, the key lookup process fails completely even if adding "SocksPort 53 IPv6Traffic" to /etc/tor/torrc then restarting tor
<anon^_^> create $HOME/.gnupg/dirmngr.conf, add "no-use-tor" parameter to .conf, save, then reload dirmngr
<anon^_^> results in the following
#ubuntu-devel 2020-08-03
<mwhudson> yeech there are a lot of armhf regressions currently
<doko> mwhudson: the release team likes to call those "flaky tests" ;p
<doko> just retry those when the autopkg testers are idle
<mwhudson> https://paste.ubuntu.com/p/yP6vFw8TMy/ well ok then?
<Pinchiukas> Are the pipelines that build images for vagrant, etc public?
<nibbon_> o/
<nibbon_> question: debian/control is possible to specify Depends: for a specific version?
<nibbon_> for instance i have a package that depends from libvirt-bin but that one isn't available in focal anymore
<nibbon_> and I need to build that package for both
<cjwatson> I mean, you can put a particular version there, but it won't cause that version to magically become available to clients
<cjwatson> So it's normally useless to try that
<nibbon_> I mean, I would like to have bionic: debian/control Depends: libvirt-bin
<nibbon_> focal: debian/control Depends: libvirt-daemons
<cjwatson> Oh.  Simplest way is to just branch the packaging for each series.
<cjwatson> If you really insist on not branching the packaging, then you can use the substvars mechanism to do that kind of thing
<cjwatson> See "man deb-substvars"
 * nibbon_ reading
<cjwatson> Also a little confused because there's no libvirt-daemons in focal, but there is a libvirt-daemon in both bionic and focal
<cjwatson> But if for example you wanted a dependency that would be satisfied by libvirt-daemon in focal and newer releases but libvirt-bin in older releases, you could also write something like "Depends: libvirt-daemon | libvirt-bin (<< 6.0.0)" (I made up the version number, you'd need to pick something actually appropriate
<nibbon_> yeah, I made a typo sorry that was the one
<cjwatson> )
<cjwatson> The last approach there is the simplest and you should probably use it unless you have a good reason not to
<nibbon_> cjwatson: yeah, the latter seems a valid solution for my issue
<cjwatson> Good good
<cpaelzer> nibbon_: libvirt-bin has gone away looong ago
<cpaelzer> we have kept it thorugh bionic just for compat, and Focal finally let go
<cpaelzer> it was replaced by libvirt-daemon-system (the server) and libvirt-clients (obviously the clients)
<cpaelzer> just so you know what to replace dependencies with
<cpaelzer> but I have to admit even though this should be clear since a long time it seems it isn't
<cpaelzer> I've got the same question just recently
<cpaelzer> I think I'll add a note to the release notes to explain better
<nibbon_> cpaelzer: so I can safely replace libvirt-bin with libvirt-daemon-system in the bionic version too?
<nibbon_> libvirt-daemon-system installs libvirt-clients too so it seems the right candidate :)
<nibbon_> and yeah, a remark about this in the release note would clarify things I guess
<cpaelzer> nibbon_: yes this was already the case in bionic and can be used there
<cpaelzer> nibbon_: there are sub-packages now if you only want the daemon for example
<cpaelzer> nibbon_: but for your case libvirt-daemon-system should be the right thing
<nibbon_> cpaelzer: you mentioned libvirt-bion has been kept for bionic just for compat: is it a package?
<nibbon_> *libvirt-bin
<ahasenack> vorlon: hi, there is this trusty sru that is lingering, probably because it's for trusty: https://bugs.launchpad.net/bugs/1881632
<ubottu> Launchpad bug 1881632 in update-notifier (Ubuntu Trusty) "esm security updates not reported by apt update-notifier" [Undecided,In progress]
<ahasenack> can you help there, or clarify if the sru team can proceed as usual with a trusty sru, given it's under esm now?
<mwhudson> i would like to nominate src:frr for the worst autopkgtest i've seen in a while
<mwhudson> can https://launchpadlibrarian.net/491020170/buildlog_ubuntu-groovy-riscv64.libyang_1.0.184-1_BUILDING.txt.gz be summarised as "don't use symbols files for c++"
#ubuntu-devel 2020-08-04
<RAOF> mwhudson: Yeah, symbols files for C++ projects that don't actively curate their exported symbols is a recipe for frustration.
<seb128> rbalint_, hey, is there any chance you could have a look at why systemd autopkgtests don't like the new plymouth?
<rbalint> seb128, it is on my TODO list
<seb128> rbalint, great, I would have poked at it but I'm not familiar enough with the systemd package to know how to  just run that specific test easily
<seb128> plymouth didn't change much so it's a bit weird :/
<mwhudson> *** Test killed: ran too long (1h31m0s).
<mwhudson> FAIL	runtime/pprof	5465.034s
<mwhudson> um
<juliank> I uploaded a new apt with http changes, please watch out for hanging builds
<juliank> (once it is published in proposed :D)
<juliank> or autopkgtests for that matter
<niub> o/ question: has python-raven been replaced by python3-sentry-sdk in ubuntu focal?
<Laney> juliank: can you fix this at some point https://people.canonical.com/~laney/weird-things/whitespace.png ? at least I assume it's whitespace :D
<juliank> Laney: seems like meh
<juliank> Laney: this is progress output with \r and stuff
<Trevinho> sil2100: hey, could you please accept the mutter SRU for focal? It contains a further fix fixing a regression in the SRU currently under verification
<Laney> oh good, you can chain transactions in aptdaemon
 * Laney hopes this works
<Laney> hmm
<Laney> how to show progress of the chain though, looks like you have to handle those separately
<Laney> juliank: ^- right?
<juliank> I don't know, I just barely keep aptdaemon working
<juliank> Um, passing it's Testsuite on one arch
<Laney> ok, I thought you knew it
<juliank> The answer I assume is yes
<juliank> But also why use aptdaemon?
<Laney> update-manager
<juliank> What's it for?
<juliank> I sed
<juliank> see
<Laney> you want me to first port it to packagekit? :p
<juliank> I gotta add another upgrade mode to package kit for that
<juliank> But hughsie does not want it
<Laney> hmm
<Laney> I don't remember if you can have chained PkTransactions either
<Laney> i.e. if doing that would even help
<Laney> not that there's any chance I will do that :-)
 * Laney wibbles
<Laney> what to do what to do
<sil2100> Trevinho: I can take a look at it today finally
<Trevinho> sil2100: thanks
<sil2100> Trevinho: btw. which reminds me: the bionic mutter SRU FTBFS on all arches from what I see
<Trevinho> mhmhm weird
<niub> fwiw https://github.com/getsentry/raven-python/blob/master/README.rst#L36 states python-raven has been phased out for Sentry-Python
<Trevinho> not sure what changed, let me see
<oSoMoN> what's the process to request a package be removed from the archive? file a bug (is there a template), or just ping a friendly AA ?
<cjwatson> oSoMoN: file a bug with rationale, subscribe ~ubuntu-archive.  I don't think there's a template
<oSoMoN> ok, thanks
<oSoMoN> done: bug #1890319
<ubottu> bug 1890319 in tinyjsd (Ubuntu) "Please remove tinyjsd from the archive" [Undecided,New] https://launchpad.net/bugs/1890319
<vorlon> ahasenack: hi, so yes, trusty queues get zero attention from the standard SRU process - pings required :)
<ahasenack> vorlon: @archive-admins pings?
<vorlon> ahasenack: sru team pings really.  anyway, looking no
<vorlon> w
<ahasenack> I pinged one, but he said he had no idea how to process trusty srus
<vorlon> ahasenack: and where is this SRU supposed to go?  Is it going to go in the security pocket in trusty?
<ahasenack> I don't know, I assumed updates
<vorlon> ahasenack: in which case the package you need in order to ensure esm updates are automatically installed by default, will not be automatically installed by default
<ahasenack> well, it's definitely not going into esm
<ahasenack> because of what you said
<vorlon> oh wait this is update-notifier, not unattended-upgrades
<ahasenack> right
<sergiodj> hi there.  since we're talking about "pings required", I'd like someone to take a look at https://code.launchpad.net/~sergiodj/britney/hints-ubuntu-xenial/+merge/388495 , please :)
<vorlon> ahasenack: I actually think this should go to esm instead
<sergiodj> I wasn't sure if I should subscribe someone else directly as a reviewer.  I just subscribed the SRU team because that's what I saw other MPs doing
<vorlon> because it's cosmetic, and only impacts the motd output aiui
<ahasenack> vorlon: but that output is an incentive to enable esm
<ahasenack> that's why I thought it should go into updates, so people without esm get that
<ahasenack> and can see what esm would give
<vorlon> ahasenack: but this only matters for the newer version of ubuntu-advantage-tools, which wasn't published when trusty standard support ended... if users were running trusty unsupported from april 2019 to january 2020 without enabling esm, does it matter now?
<ahasenack> vorlon: who know, it might convince some reluctant users to enable esm? Once they start seeing the security updates they are missing?
<ahasenack> s/know/knows/
<vorlon> ahasenack: I'm afraid I still don't think we should do this in trusty-updates and would like to see it go to esm instead
<ahasenack> vorlon: that's fine, do I need to change anything in the packaging?
<vorlon> ahasenack: I don't believe so, you just need to work with the security team to get it uploaded to the right place
<ahasenack> can they fetch it from wherever it is now?
<vorlon> ahasenack: technically, yes :)
<ahasenack> the "limbo"
<ahasenack> https://launchpad.net/ubuntu/trusty/+queue?queue_state=4&queue_text=update-notifier right
<vorlon> yep
<ahasenack> ok, thanks, I pinged them
#ubuntu-devel 2020-08-05
<RAOF> oSoMoN: The tinyjsd removal wants to be a removal + sync blacklist (to prevent it coming back from Debian), right?
<doko> cpaelzer, coreycb: please could you pick up these in your team: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#ubuntu-server
<doko> seb128, Wimpress: same for desktop: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#desktop-packages
<doko> jamespage: openstack: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#ubuntu-openstack
<doko> mdeslaur, sbeattie: and security: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#ubuntu-security
<doko> apw, sforshee: and kernel: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#kernel-packages
<apw> doko, what is that rebuilding against?
<seb128> doko, yes
<apw> (is that just gcc-10 or somethign else)
<amurray> doko: thanks for the heads up - we'll take a look
<cpaelzer> doko: we have already started on it
<cpaelzer> is that a different link than the one in your mail?
<cpaelzer> no, seems to be the same - so yes we already started
<cpaelzer> doko: what is the source for your team mapping?
<cpaelzer> doko: some openstack bits ended up in ur bucket - e.g. nfs-ganesha
<cpaelzer> this mapping looks correct
<cpaelzer> hence I'm asking what your script is based on
<cpaelzer> doko: I have recently seen "internal compiler error: Segmentation fault" on armhf a few times (groovy)
<cpaelzer> doko: is there a known bug around that in progress already?
<cpaelzer> could be 1887557
<doko> apw: see u-d-a, -release
<doko> cpaelzer: I saw only one which succeeded on a retry. package?
<cpaelzer> doko: qemu 2/5 armhf builds failed - no build log that shows it currently
<cpaelzer> doko: I filed 1890435 to ahve something to dump further insights to
<cpaelzer> one ongoing build which might or might not fail at https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu4/+build/19773244
<cpaelzer> and this issue seems (from 10.000 feet) similar https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1887557
<ubottu> Launchpad bug 1887557 in gcc-10 (Ubuntu) "GCC 10 is crashing with an internal compiler error when compiling Mesa" [Undecided,New]
<cpaelzer> I attached a failing build log that I still had on disk
<apw> doko, most of the kernel ones look to be genuinly detected double definitions; which i assume is a new fatal warning
<cjwatson> Sounds like the -fno-common change
<doko> cpaelzer: that is focal only, fixed in groovy
<cpaelzer> thanks doko
<cpaelzer> doko: in that case I'll keep an eye open and report on that bug I filed if I see it happen more often
<cpaelzer> or if I get to a reproducible state
<doko> the one I saw for llvm-11 goes away with a rebuild too
<tafb2> When is Ubuntu going to have Intel Optane support? Trying to install it on my new laptop, no go. Acer A515-55-56HH, no bios options to disable Optane, UEFI mode only, etc. Secure boot is disabled.
<tjaalton> ask intel
<xnox> tafb2:  hi, we currently do not support RST and we also give instructions to users on how to disable it, if we detect it is on.
<xnox> tafb2:  the url for instructions is at https://help.ubuntu.com/rst
<xnox> tafb2:  which effectively asks to diable Optate.
<xnox> tafb2:  you say you have no option to disable it however =( i'm not sure that's possible to support then. Because Intel Optane support is not available on linux at all.
<xnox> tafb2: if not possible from Bios, you should be able to disable it after booting into windows too
<xnox> i.e. https://support.cyberpowerpc.com/hc/en-us/articles/360014775073-How-do-I-disable-Intel-Optane- seems to be relevant too
<tafb2> xnox: neat, never figured you could disable from Windows, I'll give that a try, thanks so much.
<tafb2> xnox: In installed Intel RST but when I open it and go into settings it says "your system is not Intel Optane ready" lol :( I go into the bios, under SATA Mode: Optane (no raid), but you can't change it. Hmmm. Maybe i'll put a call into Acer, see if they know how to disable it.
<xnox> tafb2:  that sounds very odd, or new, or very restrictive.
<xnox> tafb2:  if you do figure out how to do it, please comment on https://help.ubuntu.com/rst such that we can improve instructions there.
<xnox> tafb2:  and hopefully next person (or you with next laptop ;-) ) will have that readily available to lookup
<tafb2> xnox: just got off the phone with acer, level 2 support, no way to disable Optane on that laptop. He put a suggestion into the firmware department to put a setting in the bios to disable Optane in the next bios update (if ever).
<tafb2> xnox: the instructions for rufus are pretty messy, just use the "reply" button at the bottom to suggest changes?
<xnox> tafb2: Yeap, just reply.
<tafb2> "new users are temporarily limited to 3 replies in the same topic" so much for that, lol. I'll try again in a few days.
<mwhudson> wait how does optane relate to rst
<arnatious> ahasenack looking at the logs I'm a little confused
<ahasenack> link? and bug number
<arnatious> https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1883175
<ubottu> Launchpad bug 1883175 in python-flake8 (Ubuntu Focal) "missing support for python3.8 language features" [Low,Fix committed]
<arnatious> https://autopkgtest.ubuntu.com/packages/u/update-manager/focal/amd64
<ahasenack> arnatious: ok, so it's elpy that failed
<arnatious> The bug was fixed by a version bump to 3 related packages, it looks like the tests were triggered multiple times, is it safe to assume in each of those triggered tests all 3 packages were at their latest version?
<ahasenack> arnatious: by clicking on amd64 (the test with a red), you get to https://autopkgtest.ubuntu.com/packages/e/elpy/focal/amd64
<ahasenack> that shows which packages were used in the test
<ahasenack> it also shows that it was passing before
<ahasenack> same version
<ahasenack> I have no idea what elpy is, but this is the test that failed:
<ahasenack> 1 unexpected results:
<ahasenack>    FAILED  elpy-profile-buffer-or-region-test-indir-failed
<arnatious> Looks like the failed test case was elpy-profile-buffer-or-region-test-indir-failed
<ahasenack> and that needs investigation
<ahasenack> right
<arnatious> Yeah this looks like python language support for emacs
<arnatious> Judging by the lisp code
<arnatious> It might need a version bump as well to support python 3.8
<ahasenack> ok, good luck, that's how troubleshooting goes
<arnatious> I'll work on testing that theory, in the meanwhile, the other failure cases are interesting
<arnatious> Update-manager and release-manager both failed, then passed
<arnatious> They had two separate triggered tests for the containing packages
<ahasenack> it can be a maze tracking these down
<ahasenack> I have to go, it's end of day for me, good luck
<arnatious> As a ROS dev, all I can say is better than no testing
<arnatious> Thanks ahasenack
<ahasenack> indeed
<xnox> tafb2: mwhudson:  i think one implied the other, and optane is now end of life?! unless got resurrected? https://www.intel.co.uk/content/www/uk/en/support/articles/000055419/technologies.html
<xnox> tafb2:  mwhudson: unless i am very confused, one uses optane tech, to effectively bcache the drive, which requires the drive to be in the raid / RSTe mode.
#ubuntu-devel 2020-08-06
<mwhudson> i guess that makes some amount of sense
<icey> repeating a request from coreycb from a few weeks ago: please can an archive admin take a look at accepting intervals from the groovy new queue? it's a new build dependency for python-sqlalchemy-utils.
<RAOF> icey: You can highlight us with ubuntu-archive, if you need an AA.p
<icey> RAOF: good to know, thanks!
<RAOF> I don't think I've got time to review it today before EOD, but feel free to ping tomorrow if no one else has picked it up.
<icey> RAOF: thanks :)
<ddstreet> rbasak could you check git-ubuntu import of software-properties? it seems to not yet have picked up the version in groovy-proposed
<rbasak> ddstreet: that's known blocked, sorry.
<ddstreet> ah ok
<rbasak> ddstreet: if you need to, you can run the importer locally and it should work
<ddstreet> ok yep, thnx
<rbasak> ddstreet: "git ubuntu import -v --no-push -d software-properties software-properties"
<rbasak> There's an MP up for that so a fix is well underway
<juliank> tafb2: In Acer BIOS, at least some models, this is a hidden shortcut in main menu of bios - press Ctrl+S to disable optane; but that will break windows
<juliank> (Ctrl+S enables the enablement of AHCI mode on some Acer laptops)
<juliank> Before that, you'd need to get windows ready for it, though, making it boot in safe mode using bcdedit /set {current} safeboot minimal before switching SSD to ahci
<juliank> and then after booting safe mode in ahci, do bcdedit /deletevalue {current} safeboot to disable safe mode again
<juliank> As Windows outside safe mode gets confused if you switch from optane to ahci
<juliank> but in safe mode, it will configure ssd ahci, and then it works normally after reboot
<juliank> Good luck!
<juliank> (source: https://community.acer.com/de/discussion/comment/865318/#Comment_865318 - german, for an a315)
<juliank> more here in EN: https://community.acer.com/en/discussion/583248/change-sata-mode-to-ahci-acer-aspire-3-a315-54k-59nz
<ahasenack> sil2100: hi, what do you think about disabling risc64 for bileto ppas by default? Leave it for the user to enable it in the ppa directly if he/she wants?
<ahasenack> or make bileto not wait for risc64
<ahasenack> otherwise it's really sloooooooooooow
<sil2100> ahasenack: hm, I think I like the not-wait-for-risc64 solution, let me look into that
<ahasenack> sil2100: thanks
<ahasenack> sil2100: I tried asking in #is do disable risc64 after the ppa is created (regular users cannot touch that setting), but it always comes back
<Laney> In proposed-migration we trigger tests for arches as soon as they are ready (as long as arch:all aka amd64 is built)
<Laney> so if the concern is tests not being run, it could be that bileto should run p-m earlier
<ahasenack> bileto doesn't start anything if an arch is still building
<ahasenack> which ends up being risc64
<ahasenack> hours become days
<Laney> yeah, no need for special casing any arches though, it's a matter of running p-m earlier / more frequently
<Laney> build finished -> run p-m
<icey> Laney: looking at https://bugs.launchpad.net/ubuntu/+source/intervals/+bug/1890561 - do you mean python3-infinity rather than python3-intervals? On the same topic, does `python3:Depends` also pull in things from setup.py, as the intervals package doesn't have any requirements.txt type config
<ubottu> Launchpad bug 1890561 in intervals (Ubuntu) "Explicit dependency on python3-intervals isn't needed" [Undecided,New]
<Laney> icey: yeah infinity
<icey> (updated the bug)
<Laney> The verbose output there shows the requires.txt that it's using to calculate that
<Laney> merci
<icey> cool :)
<icey> I'll propoise an update for that shortly, and then beg for jamespage to accept it :-D
<Laney> you could stage that in git if you wanted to go along with the next upload, it's not a huge deal
<icey> well, I can ask to stage it in git, I don't have the permissions yet to actually do things for realz ;-p
<Laney> aha
<icey> but I figure it's a decent time to knock out some of these easier bugs with a new package :)
<icey> also, thanks for taking a look :)
<seb128> is it expected that gcc10 leads to some symbol changes on s390x only?
<xnox> seb128:  i did not expect that, but it is possible, can you show me which? to try to figure out if that's expected or not?
<seb128> xnox, from https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html#desktop-packages
<seb128> https://launchpadlibrarian.net/491645678/buildlog_ubuntu-groovy-s390x.poppler_0.86.1-0ubuntu1_BUILDING.txt.gz
<seb128> https://launchpadlibrarian.net/491669293/buildlog_ubuntu-groovy-s390x.lightdm_1.30.0-0ubuntu3.1_BUILDING.txt.gz
<seb128> xnox, sorry lightdm is not, poppler stands
<arunpyasi> xnox, Hi there, How can we sign a thirdparty dkms module so that on installing shim-signed, no user interaction is required ?
<xnox> seb128:  missing gccinternal ones are fine, and are optional.
<xnox> addition of the parsed string is odd
<xnox> seb128:  and "missing _Z.* regex is odd, but also i don't what it was / should have been.
<xnox> seb128:  using ccp0v5 ABI still today is odd
<xnox> seb128:  using c++14 abi is odd, given we have moved on to c++17
<xnox> i wonder if _Z symbols are missing because it's zlib stuff and it's optimized on s390x now
<xnox> seb128:  i think it is worth opening a bug report about it, and like assigning for me to poke it.
<seb128> xnox, ok, thanks, against which package?
<arunpyasi> xnox, Did I miss your msg due to network disconnection ?
<xnox> seb128:  just poppler with ftbfs tag. It may or may not be poppler, but it's a place for it to start.
<seb128> xnox, ack
<seb128> xnox, https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1890619
<xnox> arunpyasi:  hi, i don't recognise your nicknam. I'm not sure what you are asking about, and why you are asking me =)
<ubottu> Launchpad bug 1890619 in poppler (Ubuntu) "poppler fails to build on s390x with gcc10 due to symbols changes" [High,New]
<arunpyasi> arunpyasi, I work on the remix UbuntuDDE and was having issue with a dkms module and secure boot.
<arunpyasi> On installing shim-signed, I was asked to sign the dkms module with a new Key. How can we sign a thirdparty dkms module so that on installing shim-signed, no user interaction is required ?
<xnox> which modules is it?
<xnox> still not sure why are you pinging me about it
<arunpyasi> xnox, Its not in Debian/Ubuntu yet, Its called deepin-anything-dkms
<xnox> by design, dkms modules are to be self-signed.
<arunpyasi> xnox, I was referred to you by Wimpress :D
<xnox> arunpyasi:  the only kernel modules that are presigned, are the ones that shipped in the linux kernel itself.
<doko> seb128, xnox: C++ symbols changes should be dropped, and replaced by a proper ABI check ...
<xnox> arunpyasi:  so submit that module to be included in the mainline.
<xnox> Wimpress:  arunpyasi: i don't know what you expected, but we don't sign any dkms modules, ever.....
<xnox> and especially not third party ones, that are not upstream / debian / ubuntu....
* sil2100 changed the topic of #ubuntu-devel to: Archive: Open | 20.04.1 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: rafaeldtinoco
<rafaeldtinoco> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<rafaeldtinoco> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04.1 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<mwhudson> /<<BUILDDIR>>/syslinux-legacy-3.63+dfsg/memdisk/setup.c:712: undefined reference to `strlen'
<mwhudson> special
<xnox> mwhudson:  RM bugs is the best way to fix FTBFS
<mwhudson> * usb-creator-common            (for syslinux-legacy)
<mwhudson> transitive RM?
<mwhudson> or does usb-creator still work, i forget
<mwhudson>   * Resurrect syslinux 3.63 as syslinux-legacy, so that we can write
<mwhudson>     10.04 and earlier Ubuntu images in later versions (LP: #645818).
<ubottu> Launchpad bug 645818 in usb-creator (Ubuntu Precise) "Unknown keyword in configuration file: gfxboot" [High,Confirmed] https://launchpad.net/bugs/645818
<mwhudson> yeah ok we probably don't need this any more
<xnox> mwhudson:  usb-creator still works......
<xnox> mwhudson:  but yeah, not sure if we still want syslinux-legacy or not
<mwhudson> xnox: probably doesn't need to depend on syslinux-legacy any more though
<mwhudson> oh right i think it was the adding persistence partition bit of usb-creator that had bitrotted
<mwhudson> not the whole thing
<seb128> ahasenack, hey, when you have some free cycle could you check if gnunet can be synced or need to be merged? It's unclear to me in the mysql8 bool change was a temp thing or not
<ahasenack> gnunet? What is that?
<ahasenack> did I TIL it?
<ahasenack> mybool, hmmm, memories
<seb128> ahasenack, https://launchpad.net/ubuntu/+source/gnunet/0.10.1-5.1ubuntu1
<ahasenack> heh, that would be me
<seb128> :-)
<ahasenack> wilco
<seb128> there is a new version in debian that uses python3
<seb128> so it's only the mysql question
<seb128> ahasenack, thanks!
<ahasenack> I'll check
#ubuntu-devel 2020-08-07
<oSoMoN> I spent some time looking into the node-sha.js autopkgtest failures on ppc64el, which (along with other test failures in various node-* packages) prevent the migration of nodejs
<oSoMoN> it turns out it's a nasty bug in V8 that incorrectly optimizes a function on ppc64el only (https://github.com/nodejs/node/issues/34666)
<oSoMoN> this requires further investigation upstream, and I'm not sure what the best approach would be to get this moving forward in Ubuntu
<oSoMoN> (nodejs in turns is blocking firefox and thunderbird)
<oSoMoN> s/turns/turn/
<oSoMoN> suggestions welcome
<seb128> oSoMoN, would building with a lower -O workaround the optimization problem?
<oSoMoN> seb128, IÂ don't know, I'm not familiar with how V8 optimizes code, but IÂ can certainly try
<seb128> oSoMoN, I'm just random suggesting, let's see if maybe doko or xnox can help there
<icey> oSoMoN: feel free to ignore me but I'm kind of a fan of the minimal `eval('')` patch you mention in the bug report
<oSoMoN> icey, that would just hide one symptom of the problem, but V8 would potentially incorrectly optimize other functions in other packages
<icey> fair enough
<oSoMoN> sil2100, hey, I just commented on bug #1889106, if you're still around and have some time for it, would you mind accepting chromium-browser 84.0.4147.105-0ubuntu0.20.04.1 into focal-proposed?
<ubottu> bug 1889106 in chromium-browser (Ubuntu Focal) "[SRU] Upgrading from 18.04 to 20.04 will keep the 18.04 chromium-browser due to a higher version than the transitional deb in 20.04" [High,Fix committed] https://launchpad.net/bugs/1889106
<oSoMoN> that would fix the deb->snap upgrade path for users upgrading from bionic to focal
<ahasenack> seb128: I have a merge ready for gnunet, but the my_bool change is still needed
<ahasenack> I opened a bug upstream this time
<ahasenack> that's our only delta
<seb128> ahasenack, right, thank you!
<ahasenack> seb128: it doesn't have dep8 tests, and I really don't know much about the pkg
<ahasenack> seb128: was it blocking/breaking something else, something I could test with this new version?
<ahasenack> otherwise, I'll jut get a quick review and upload
<seb128> ahasenack, something was depwaiting on it on the proposed report but I forgot what ... the delta is minimal and that could be an autosynced update, I would trust Debian and not spent too much effort trying to test it
<ahasenack> ok
<ahasenack> I just got a build failure, taking a quick look
<ahasenack> might be gcc10 fun
<ahasenack> seb128: ah, gnunet-fuse perhaps
<ahasenack> and all the other gnunet-* src packages looks like
<ahasenack> which are syncs
<seb128> ahasenack, right
<ahasenack> ok, I ll handle it
<ahasenack> ok, ftbfs resolved
<Pinchiukas> Are the pipelines that build images for vagrant, etc public? As I understand, people in ubuntu build them.
<ahasenack> vorlon: hi, good morning/afternoon. While reviewing the base-files changes regarding motd-news-config, cpaelzer came across one case which we are wondering if it's worth addressing
<ahasenack> vorlon: basically the scenario is you have the current base-files and ubuntu-server installed, and the user removes /etc/default/motd-news (instead of editing it)
<ahasenack> in that scenario, when you do the upgrade, /etc/default/motd-news is reinstalled when the new motd-news-config package is installed
<ahasenack> you start with base-files/ubuntu-server, upgrade, and end up with base-files, ubuntu-server, and motd-news-config, as expected. But with the config file back, as it's now part of motd-news-config, and before, when the user removed it, it was part of base-files
<ahasenack> is this worth addressing? If yes, how?
<ahasenack> his comment, for reference: https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388835/comments/1022645
<Pinchiukas> Anyone?
<xnox> ahasenack: I think it's impossible to migrate conffile between packages.
<ahasenack> I'm doing it for the case of a modified conf file, when there is a backup
<ahasenack> but a removed one... that's another story
<xnox> ahasenack: at most you can check if the file doesn't exist in preinst and re-remove it.
<xnox> ahasenack: backups and modified ones, also hard.
